Re: krbdev Digest, Vol 186, Issue 4

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: 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

El sáb., 16 jun. 2018 a las 18:00, <[hidden email]> escribió:

> Send krbdev mailing list submissions to
>         [hidden email]
>
> 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
>         [hidden email]
>
> You can reach the person managing the list at
>         [hidden email]
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of krbdev digest..."
>
>
> Today's Topics:
>
>    1. Re: MIT Kerberos 1.14 : gssint_get_mechanism_cred crash
>       (Vipul Mehta)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Fri, 15 Jun 2018 23:27:54 +0530
> From: Vipul Mehta <[hidden email]>
> Subject: Re: MIT Kerberos 1.14 : gssint_get_mechanism_cred crash
> To: Greg Hudson <[hidden email]>
> Cc: [hidden email]
> Message-ID:
>         <CAMeQEL-X_0JN2CJ3V=
> [hidden email]>
> 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.
>
> On Thu, Jun 14, 2018 at 8:33 PM, Greg Hudson <[hidden email]> wrote:
>
> > On 06/14/2018 07:05 AM, Vipul Mehta wrote:
> >
> >> 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
> [hidden email]
> https://mailman.mit.edu/mailman/listinfo/krbdev
>
>
> End of krbdev Digest, Vol 186, Issue 4
> **************************************
>
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: obscured error code (was Re: krbdev Digest, Vol 186, Issue 4)

Greg Hudson
On 06/18/2018 07:21 AM, Joshua Acosta wrote:
> 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.

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             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev