Diagnosing Kerberos credentials cache problems is difficult. The first thing to try is to set LogLevel to debug in /etc/httpd/conf/httpd.conf and restart Apache. Look in /var/log/httpd/error_log for any problems. Also check out /var/log/krb5kdc.log To simplify things and test just Kerberos ticket forwarding: The first test is with a CGI: - copy test.py /var/www/cgi-bin - chmod +x /var/www/cgi-bin/test.py - kinit admin (or some other existing user) - curl -u : --negotiate http://yourhost.fqdn/cgi-bin/test.py For yourhost.fqdn use the fully-qualified hostname of your webserver. The output should look something like: KRB5CCNAME is FILE:/tmp/krb5cc_apache_TiMAbq Sucessfully bound to LDAP using SASL mechanism GSSAPI This CGI uses the forwarded credentials to make an authenticated LDAP connection. If this fails it means that Apache is not properly storing the kerberos credentials. If that works, the second test more closely models the way that IPA works. - mkdir /usr/share/ipa/ipatest - cp test_mod_python.py /usr/share/ipa/ipatest - uncomment the entries for ipatest in /etc/httpd/conf.d/ipa.conf. There are entries for ProxyPass and ProxyReversePass, an Alias and a Directory - restart Apache - curl -u : --negotiate http://yourhost.fqdn/ipatest/ For yourhost.fqdn use the fully-qualified hostname of your webserver. The output should look something like: KRB5CCNAME: FILE:/tmp/krb5cc_apache_c0MU9o
GATEWAY_INTERFACE: CGI/1.1
... SCRIPT_FILENAME: /usr/share/ipa/ipaserver/
REMOTE_PORT: 45691
REMOTE_USER: rcrit@GREYOAK.COM
AUTH_TYPE: Negotiate
KRB5CCNAME is FILE:/tmp/krb5cc_apache_c0MU9o
Sucessfully bound to LDAP using SASL mechanism GSSAPI
It should print all of the environment variables available to mod_python and do a GSSAPI LDAP connection. A final test, which lists the capabilities of the XML-RPC server is test_methods.py. This is more a sanity check that new functions added to the server work as expected. Note that opts is added by the server itself and is not passed in by the user.