[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Never Mind, was: Difference in handling SPNEGO tokens between heimdal 0.7.2 , 0.8.1 and 1.0.1
The below error was caused by a bad configuration of mod_auth_kerb,
not a Heimdal bug. Sorry about the noise. Doesn't explain the
problem with mod_spnego, but it's not generic to Heimdal.
On Nov 12, 2007, at 6:17 PM, Henry B. Hotz wrote:
> 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