[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



Hej Markus,

Can you check in gdb what failes in krb5_verify_pac(), are you using  
arcfour(rc4) enctypes or AES ?

Love


10 nov 2007 kl. 12.29 skrev Markus Moeller:

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