blob: 6816221620fd3d34b639261fee13b315a0d77588 (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
|
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.
- copy test_mod_python.py /usr/share/ipa/ipaserver
- 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<br>
GATEWAY_INTERFACE: CGI/1.1<br>
...
SCRIPT_FILENAME: /usr/share/ipa/ipaserver/<br>
REMOTE_PORT: 45691<br>
REMOTE_USER: rcrit@GREYOAK.COM<br>
AUTH_TYPE: Negotiate<br>
KRB5CCNAME is FILE:/tmp/krb5cc_apache_c0MU9o<br>
Sucessfully bound to LDAP using SASL mechanism GSSAPI<br>
It should print all of the environment variables available to mod_python
and do a GSSAPI LDAP connection.
|
