[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
I meant NTLMSSP not NTLM.
Markus
"Markus Moeller" <huaraz@moeller.plus.com> wrote in message
fh7hi5$6bb$1@ger.gmane.org">news:fh7hi5$6bb$1@ger.gmane.org...
> Changing mod_spnego so that it returns data to the client when
> continuation is required I see the following reply showing heimdals(1.0.1)
> authentication reply (w.g. authentication is incomplete and the only
> supported mechanism is NTLM). The client responds then with an NTLM token
> and heimdal comes back with:
>
> [Sun Nov 11 18:11:44 2007] [error] [client 192.168.1.10] mod_spnego:
> gss_accept_sec_context failed; GSS-API: An unsupported mechanism was
> requested
> [Sun Nov 11 18:11: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
>
> Heimdal 1.0.1 reply to Windows SPNEGO token:
>
> Frame 408 (376 bytes on wire, 376 bytes captured)
> Ethernet II, Src: Vmware_02:d5:f5 (00:0c:29:02:d5:f5), Dst:
> Vmware_be:25:5d (00:0c:29:be:25:5d)
> Internet Protocol, Src: opensuse.suse.home (192.168.1.7), Dst:
> winxp.windows2003.home (192.168.1.10)
> Transmission Control Protocol, Src Port: http (80), Dst Port: 3439 (3439),
> Seq: 3211, Ack: 2412, Len: 322
> [Reassembled TCP Segments (1782 bytes): #407(1460), #408(42), #408(1),
> #408(1), #408(1), #408(1), #408(1), #408(1), #408(2), #408(2), #408(36),
> #408(1), #408(1), #408(1), #408(1), #408(1), #408(1), #408(2), #408(2),
> #408(13), #408(1), #408(]
> Hypertext Transfer Protocol
> HTTP/1.1 401 Authorization Required\r\n
> Request Version: HTTP/1.1
> Response Code: 401
> Date: Sun, 11 Nov 2007 18:11:42 GMT\r\n
> Server: Apache/2.2.3 (Linux/SUSE)\r\n
> WWW-Authenticate: Negotiate oRUwE6ADCgEBoQwGCisGAQQBgjcCAgo=\r\n
> GSS-API Generic Security Service Application Program Interface
> SPNEGO
> negTokenTarg
> negResult: accept-incomplete (1)
> supportedMech: 1.3.6.1.4.1.311.2.2.10 (NTLMSSP -
> Microsoft NTLM Security Support Provider)
> Vary: accept-language,accept-charset\r\n
> Accept-Ranges: bytes\r\n
> Keep-Alive: timeout=15, max=99\r\n
> Connection: Keep-Alive\r\n
> Transfer-Encoding: chunked\r\n
> Content-Type: text/html; charset=iso-8859-1\r\n
> Content-Language: en\r\n
> \r\n
>
>
> Has anybody mod_spnego or mod_auth_kerb working with heimdal 1.0.1 ?
>
> Thank you
> 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
>>>
>>>
>>>
>>>
>>
>>
>>
>>
>
>
>
>