[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
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 ?
Thank you
Markus
"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 ?
>> >>>>
>> >>>> Markus
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>
>> >>>
>> >>>
>> >>>
>> >>
>> >>
>> >>
>> >>
>> >
>> >
>> >
>> >
>>
>>
>>
>
>
> --
> Michael B Allen
> PHP Active Directory SPNEGO SSO
> http://www.ioplex.com/
>