[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
Hmmm. Looks like I just hit something similar with mod_auth_kerb and
Heimdal 1.0.1 on Solaris 9, Apache 2.2.
> [Mon Nov 12 18:09:56 2007] [info] Initial (No.1) HTTPS request
> received for child 1 (server redhotz.jpl.nasa.gov:443)
> [Mon Nov 12 18:09:56 2007] [debug] src/mod_auth_kerb.c(1572):
> [client 137.78.61.96] kerb_authenticate_user entered with user
> (NULL) and auth_type Kerberos
> [Mon Nov 12 18:09:56 2007] [debug] src/mod_auth_kerb.c(1194):
> [client 137.78.61.96] Acquiring creds for HTTP@redhotz.jpl.nasa.gov
> [Mon Nov 12 18:09:56 2007] [debug] src/mod_auth_kerb.c(1338):
> [client 137.78.61.96] Verifying client data using KRB5 GSS-API
> [Mon Nov 12 18:09:56 2007] [debug] src/mod_auth_kerb.c(1354):
> [client 137.78.61.96] Verification returned code 1
> [Mon Nov 12 18:09:56 2007] [debug] src/mod_auth_kerb.c(1372):
> [client 137.78.61.96] GSS-API token of length 22 bytes will be sent
> back
> [Mon Nov 12 18:09:56 2007] [error] [client 137.78.61.96]
> gss_display_name() failed: An invalid name was supplied (unknown
> mech-code 0 for mech unknown)
Have to look into this some more.
On Nov 11, 2007, at 10:27 AM, Markus Moeller wrote:
> 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
------------------------------------------------------------------------
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu