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