krbdev Digest, Vol 186, Issue 4

[Joshua Acosta]

Good morning,

We are developing a software authentification based in the software "leash"
downloaded with kerberos for Windows. Our KDC is located in an IBM ZOS.

The problem that we have is when we demand a ticket TGT of a user that is
in "renewal state", the function leash_kinit doesn't inform about this
situacion, that has a return code KRB5KDC_ERR_KEY_EXP, instead of this
value the code returned is KRB5KDC_ERR_PREAUTH_FAILED.

We are "sniffing" the conversation between client and Host IBM and can see
that the error of key expired is fired, but is hiding by the next error:
preauth fail.

How ZOS can't desactivated the preauthentificacion, how can we detect the
renewal situation?.

Thanks in advance,
Josep Maria

Send krbdev mailing list submissions to
To subscribe or unsubscribe via the World Wide Web, visit
https://mailman.mit.edu/mailman/listinfo/krbdev
or, via email, send a message with subject or body 'help' to
You can reach the person managing the list at
When replying, please edit your Subject line so it is more specific
than "Re: Contents of krbdev digest..."
1. Re: MIT Kerberos 1.14 : gssint_get_mechanism_cred crash
(Vipul Mehta)
----------------------------------------------------------------------
Message: 1
Date: Fri, 15 Jun 2018 23:27:54 +0530
Subject: Re: MIT Kerberos 1.14 : gssint_get_mechanism_cred crash
<CAMeQEL-X_0JN2CJ3V=
Content-Type: text/plain; charset="UTF-8"
Thanks Greg. If i have anything more related to mit kerberos i will share.
For now we are also suspecting and investigating possible internal bug in
our code only.

We are facing crash in our application while kerberos security context
initialization inside gssint_get_mechanism_cred function.

[...]

Looks like memcmp is causing the issue.
&union_cred->mechs_array[i]->length is 9
mech_type->length is 9
mech_type->elements is not NULL
(&union_cred->mechs_array[i])->elements is also not NULL
Is anyone aware of such issue. Any possible fix ? Let me know if you

need

more information.

I am not aware of any such issue. You should double-check that the cred
handle you are passing is a valid cred handle and was not previously

freed

(although the usual method of releasing a cred handle should also set the
pointer to NULL, unless you made a copy of the cred handle before

releasing

it). If there is a memory corruption issue in the application, you might
be able to use valgrind to find it.

--
Regards,
Vipul
------------------------------
_______________________________________________
krbdev mailing list
https://mailman.mit.edu/mailman/listinfo/krbdev
End of krbdev Digest, Vol 186, Issue 4
**************************************

_______________________________________________
krbdev mailing list ***@mit.edu
https://mailman.m

[Greg Hudson]

Post by Joshua Acosta
The problem that we have is when we demand a ticket TGT of a user that is
in "renewal state", the function leash_kinit doesn't inform about this
situacion, that has a return code KRB5KDC_ERR_KEY_EXP, instead of this
value the code returned is KRB5KDC_ERR_PREAUTH_FAILED.
We are "sniffing" the conversation between client and Host IBM and can see
preauth fail.

Can you share more details of the packet trace? I do not know
immediately know why the exchange would not end at the
KRB5KDC_ERR_KEY_EXP response and yield that error code.
_______________________________________________
krbdev mailing list ***@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev