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 mod_auth_kerb code.
Created attachment 212781 [details] Fix kerberos ticket forwarding I tested this with: <Directory /var/www/cgi-bin> AuthType Kerberos AuthName "Kerberos Login" KrbMethodNegotiate on KrbMethodK5Passwd off KrbServiceName HTTP KrbAuthRealms MYREALM Krb5KeyTab /etc/httpd/conf/ipa.keytab KrbSaveCredentials on Require valid-user ErrorDocument 401 /errors/unauthorized.html </Directory> And a CGI that looks something like: #!/bin/sh echo Content-type: text/plain echo if [ -z "$KRB5CCNAME" ]; then echo 'Kerberos credential cache name $KRB5CCNAME does not exist.' exit 1 fi /usr/kerberos/bin/klist 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 implementation.
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 cached: [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.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 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 credentials.
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 a release.