Red Hat Bugzilla – Bug 301061
credential caching does not work with the MIT spnego code but does with the included mod_auth_kerb version
Last modified: 2012-08-31 11:43:15 EDT
Description of problem:
trying to use forwarded tickets with the standard module result in the
application behind it being unable to retrieve the cache with the TGT
This happens with the default compiled MIT libgssapi provide spnego.
mod works fine when compiled using the implementation included whithin the
Created attachment 212781 [details]
Fix kerberos ticket forwarding
I tested this with:
AuthName "Kerberos Login"
ErrorDocument 401 /errors/unauthorized.html
And a CGI that looks something like:
echo Content-type: text/plain
if [ -z "$KRB5CCNAME" ]; then
echo 'Kerberos credential cache name $KRB5CCNAME does not exist.'
You should receive a page back that lists the forwarded ticket.
Crud, didn't read the bug closely. I tested this against the Fedora 7 kerberos
Created attachment 212861 [details]
Patch against correct version.
Created attachment 212911 [details]
like Rob's patch, but also checks for GSS_C_DELEG_FLAG in the returned flags set
I did all my testing with curl and a python kerberos implementation (PyKerberos
from the Apple calendar project). Testing with Firefox results in no credentials
[Thu Oct 04 13:57:02 2007] [debug] src/mod_auth_kerb.c(1406): [client
192.168.0.1] kerb_authenticate_user entered with user (NULL) and auth_type Kerberos
[Thu Oct 04 13:57:02 2007] [debug] src/mod_auth_kerb.c(1148): [client
192.168.0.1] Acquiring creds for HTTP@test.example.com
[Thu Oct 04 13:57:02 2007] [debug] src/mod_auth_kerb.c(1241): [client
192.168.0.1] Verifying client data using KRB5 GSS-API
[Thu Oct 04 13:57:02 2007] [debug] src/mod_auth_kerb.c(1257): [client
192.168.0.1] Verification returned code 0
[Thu Oct 04 13:57:02 2007] [debug] src/mod_auth_kerb.c(1275): [client
192.168.0.1] GSS-API token of length 22 bytes will be sent back
[Thu Oct 04 13:57:02 2007] [debug] src/mod_auth_kerb.c(1322): [client
192.168.0.1] set cached name admin@EXAMPLE.COM for connection
[Thu Oct 04 13:57:02 2007] [error] [client 192.168.x.x] Cannot store delegated
credential (gss_krb5_copy_ccache: Invalid credential was supplied (No error))
So the Kerberos connection succeeds but the caching fails.
It does cache the ticket with the mod_auth_kerb internal SPNEGO code.
Hmm, I was actually using elinks. You're sure that firefox has delegation
enabled in addition to negotiate ("network.negotiate-auth.delegation-uris")?
And just to be sure, that your credentials are forwardable ("klist -f" lists the
"F" flag for the TGT)?
Nope, that's a bug alright. Firefox is sending for-real spnego client packets,
and the gssapi library's getting a little confused trying to save delegated
This request was evaluated by Red Hat Product Management for
inclusion, but this component is not scheduled to be updated in
the current Red Hat Enterprise Linux release. This request will
be reviewed for a future Red Hat Enterprise Linux release.
This request was evaluated by Red Hat Product Management for inclusion
in a Red Hat Enterprise Linux release. Product Management has
requested further review of this request by Red Hat Engineering, for
potential inclusion in a Red Hat Enterprise Linux release for currently
deployed products. This request is not yet committed for inclusion in