Folks Since a few days I'm stuck in kerberized LDAP configuration. Let me first explain my environmental configuration
Two hosts are involved. first host Name: declips.privat.net NICs: eth0 10.1.1.1 eth1 192.168.178.22 (interface to the outside world) Services: LDAP server (OpenLDAP 2.4.19) Kerberos server (MIT Kerberos) krb5-config --version returns 1.7.1 DNS (bind) server named-sdb with LDAP stored data LDAP: base "o=privat,c=de" second host Name: levante.privat.net NICs: eth0 10.1.1.5 eth1 192.168.178.24 (interface to the outside world) At first I configured the hosts (declips) LDAP for simple bind. Everything worked as expected. ldapsearch -x -LLL -W -D "cn=someuser,ou=users,o=privat,c=de" uid=someuser returned the correct record on both of the servers Second I configured the Kerberos service for beeing able to do a strong bind. After a while and solving some issues I've got Kerberos to run. Kerberized telnet from declips to levante and vice versa (on the 10.1.1.0 net) - Yepp Whooohooo :-) Now my issue ldapsearch -Y GSSAPI -LLL uid=someuser returns on declips exacly what is expected ... cooool The same command on levante end up in the error message SASL/GSSAPI authentication started ldap_sasl_interactive_bind_s: Invalid credentials (49) additional info: SASL(-13): authentication failure: GSSAPI Failure: gss_accept_sec_context The weird thing is that the client (with a valid TGT) requests and gets the ldap Service Ticket Ticket cache: FILE:/home/someuser/tmp/krb5cc_500 Default principal: [email protected] Valid starting Expires Service principal 03/28/10 21:19:51 03/29/10 21:19:51 krbtgt/[email protected] renew until 04/04/10 21:19:51 03/28/10 21:20:11 03/29/10 21:19:51 ldap/[email protected] renew until 04/04/10 21:19:51 If I leave the LDAP server listening on the TCP address of localhost (127.0.0.1) declips is cool. If I change the entry in /etc/openldap/ldap.conf from URI=ldap://127.0.0.1/ to URI=ldap://10.1.1.1/ I'm facing the same issue (gss_accept_sec_context) as on levante. Is there somebody out there who can lead me to a solution. cheers Wolf-A. ________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
