[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Difference in handling SPNEGO tokens between heimdal 0.7.2 ,0.8.1 and 1.0.1
On Sun, 18 Nov 2007 13:36:18 -0000
"Markus Moeller" <huaraz@moeller.plus.com> wrote:
> It fails at the below step in verify_checksum with the following call order:
>
> authenticateUser
> gss_accept_sec_context
> _gss_spnego_accept_sec_context
> acceptor_start
> gss_accept_sec_context
> _gsskrb5_acceptor_start
> krb5_rd_req_ctx
> krb5_pac_verify
> verify_checksum
> krb5_verify_checksum
> verify_checksum
>
>
> (*ct->checksum)(context, dkey, data, len, usage, &c);
>
> if(c.checksum.length != cksum->checksum.length ||
> memcmp(c.checksum.data, cksum->checksum.data, c.checksum.length)) {
> krb5_clear_error_string (context);
> ret = KRB5KRB_AP_ERR_BAD_INTEGRITY;
> } else {
> ret = 0;
> }
>
> with (*ct->checksum) = HMAC_MD5_checksum
>
> memcmp(c.checksum.data, cksum->checksum.data, c.checksum.length) is != 0
> and therefore KRB5KRB_AP_ERR_BAD_INTEGRITY is returned.
>
> Does anybody ( Love ? ) know if a timestamp is part of the checksum as
> Michael indicates ?
Hi Marcus,
I was just giving the timestamp story as an example of how difficult
it was to get the PAC verification right. I doubt it's the same exact
problem. I think it's more likely to be something as simple as the wrong
hashing algorithm is being used.
Note that there are two checksums that can be verified:
PAC_SERVER_CHECKSUM and PAC_PRIVSVR_CHECKSUM. The later is optional. Also,
even though PAC_SERVER_CHECKSUM is required to verify that a client
has not done something dishonest like insert her own SIDs, you don't
need to do any verification to actually proceed. You might look for an
option that disableds the PAC verification code in part or in whole so
that you can simply move on.
Sometimes moving on yields solutions to previously unsolved mysteries.
Mike
> "Michael B Allen" <miallen@ioplex.com> wrote in message
> 20071117202009.ce99f275.miallen@ioplex.com">news:20071117202009.ce99f275.miallen@ioplex.com...
> >I know nothing of that code but IIRC the Samba guys had a little trouble
> > trying to figure out how to validate the PAC correctly. After some very
> > careful network analysis they traced it to some timestamp that had to
> > be just so or the checksum would be wrong.
> >
> > Just my 2c,
> > Mike
> >
> > On Sat, 17 Nov 2007 23:20:07 -0000
> > "Markus Moeller" <huaraz@moeller.plus.com> wrote:
> >
> >> What could be the reason for a checksum failure on the pac data as it
> >> seems
> >> to be my main issue ?
> >>
> >> Thank you
> >> Markus
> >>
> >> "Markus Moeller" <huaraz@moeller.plus.com> wrote in message
> >> fh54c5$ncb$1@ger.gmane.org">news:fh54c5$ncb$1@ger.gmane.org...
> >> > Further debugging shows the integrity check fails because
> >> > krb5_pac_verify
> >> > fails to verify the checksum. This happens only when using a Browser
> >> > from
> >> > a Windows platform as the pac content only exists in MS kerberos
> >> > tickets.
> >> >
> >> > Markus
> >> >
> >> >
> >> > "Markus Moeller" <huaraz@moeller.plus.com> wrote in message
> >> > fh4no2$l87$1@ger.gmane.org">news:fh4no2$l87$1@ger.gmane.org...
> >> >>
> >> >> When I use in case 4) instead of GSS_C_NO_NAME HTTP/fqdn I get the
> >> >> following error:
> >> >>
> >> >> [Sat Nov 10 16:37:54 2007] [error] [client 192.168.1.10] mod_spnego:
> >> >> gss_accept_sec_context failed; GSS-API: Miscellaneous failure (see
> >> >> text))
> >> >> [Sat Nov 10 16:37:54 2007] [error] [client 192.168.1.10] mod_spnego:
> >> >> gss_accept_sec_context failed; GSS-API mechanism: Decrypt integrity
> >> >> check
> >> >> failedxt))
> >> >>
> >> >> It seems gss_acquire_creds needs a desired name != GSS_C_NO_NAME to
> >> >> accept kerberos 5 as a mechanism.
> >> >> e.g. In acquire_acceptor_cred
> >> >>
> >> >> ret = GSS_S_FAILURE;
> >> >> .
> >> >> .
> >> >> /* check that the requested principal exists in the keytab */
> >> >> if (handle->principal) {
> >> >> .
> >> >> .
> >> >> ret = GSS_S_COMPLETE;
> >> >> }
> >> >>
> >> >> Markus
> >> >>
> >> >> "Markus Moeller" <huaraz@moeller.plus.com> wrote in message
> >> >> fh4jdr$p46$1@ger.gmane.org">news:fh4jdr$p46$1@ger.gmane.org...
> >> >>>I did some further testing. I get the following:
> >> >>>
> >> >>> 1) mod_spnego with heimdal 0.7.2 and HAVE_SPNEGO (meaning heimdal
> >> >>> takes
> >> >>> care of the spnego unpacking) works
> >> >>> 2) mod_spnego with heimdal 0.7.2 w/o HAVE_SPNEGO (meaning mod_spnego
> >> >>> uses fbopenssl for spnego unpacking) works
> >> >>> 3) mod_spnego with heimdal 1.01 and HAVE_SPNEGO (meaning heimdal
> >> >>> takes
> >> >>> care of the spnego unpacking)
> >> >>> I get the following error:
> >> >>> [Thu Nov 08 23:31:04 2007] [error] [client 192.168.1.10]
> >> >>> mod_spnego:
> >> >>> gss_accept_sec_context failed; GSS-API: continuation call to routine
> >> >>> required)
> >> >>> [Thu Nov 08 23:31:04 2007] [error] [client 192.168.1.10] mod_spnego:
> >> >>> gss_accept_sec_context failed; GSS-API mechanism: unknown mech-code 0
> >> >>> for mech unknown)
> >> >>>
> >> >>> 4) mod_spnego with heimdal 1.0.1 w/o HAVE_SPNEGO (meaning mod_spnego
> >> >>> uses fbopenssl for spnego unpacking)
> >> >>> I get the following error:
> >> >>> [Sat Nov 10 15:14:44 2007] [error] [client 192.168.1.10]
> >> >>> mod_spnego:
> >> >>> gss_accept_sec_context failed; GSS-API: An unsupported mechanism was
> >> >>> requested)
> >> >>> [Sat Nov 10 15:14:44 2007] [error] [client 192.168.1.10] mod_spnego:
> >> >>> gss_accept_sec_context failed; GSS-API mechanism: unknown mech-code 0
> >> >>> for mech unknown)
> >> >>>
> >> >>> Looking more into 4) I see acquire_cred fills creds with a list of
> >> >>> mechanism 3 initially (kerberos 5, spnego, ? ), but when it reaches
> >> >>> spnego it calls gss_spnego_acquire_creds and overwrites the list of
> >> >>> mechanism with 2 (spnego and ntlm). When I now use the acquired
> >> >>> credentials in gss_accept_sec_context it fails since kerberos 5 is
> >> >>> not
> >> >>> anymore in the list of mechanisms.
> >> >>>
> >> >>> Is that a correct analysis for case 4 ? Do I need to provide a
> >> >>> mechanism
> >> >>> to acquire_creds instead of using GSS_NULL_OID_SET ?
> >> >>>
> >> >>> BTW mod_spnego works fine with MIT and I noticed the heimdal problems
> >> >>> from 0.8 onwards.
> >> >>>
> >> >>> Thank you
> >> >>> Markus
> >> >>>
> >> >>>
> >> >>> "Markus Moeller" <huaraz@moeller.plus.com> wrote in message
> >> >>> fh08tb$qk5$1@ger.gmane.org">news:fh08tb$qk5$1@ger.gmane.org...
> >> >>>>I used mod_spnego for some time successfully with heimdall 0.7.2.
> >> >>>>After
> >> >>>>upgrading to heimdal 1.0.1 I get the following error:
> >> >>>>
> >> >>>> [Thu Nov 08 23:31:04 2007] [error] [client 192.168.1.10] mod_spnego:
> >> >>>> gss_accept_sec_context failed; GSS-API: continuation call to routine
> >> >>>> required)
> >> >>>> [Thu Nov 08 23:31:04 2007] [error] [client 192.168.1.10] mod_spnego:
> >> >>>> gss_accept_sec_context failed; GSS-API mechanism: unknown mech-code
> >> >>>> 0
> >> >>>> for mech unknown)
> >> >>>>
> >> >>>>
> >> >>>> Why does gss_accept_sec_context now require a continuation ?
> >> >>>>
--
Michael B Allen
PHP Active Directory SPNEGO SSO
http://www.ioplex.com/