[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



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