kerberized OpenLDAP

[Wolf-Agathon Schaly]

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: ***@PRIVAT.NET

Valid starting Expires Service principal
03/28/10 21:19:51 03/29/10 21:19:51 krbtgt/***@PRIVAT.NET
renew until 04/04/10 21:19:51
03/28/10 21:20:11 03/29/10 21:19:51 ldap/***@PRIVAT.NET
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 ***@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

[Andy Cobaugh]

Post by Wolf-Agathon Schaly
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.

/etc/openldap/ldap.conf is the ldap.conf file used by client tools
(ldapsearch, ldapadd, etc). That has nothing to do with the server, whose
configuration file is /etc/openldap/slapd.conf

--andy

[Guillaume Rousse]

Post by Wolf-Agathon Schaly
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.

It seems like a name canonicalisation error for me, as you have a
multihomed setup, and result varies with the IP adress you're using.

You have to ensure the principal used in LDAP server keytab (its SPN)
matches both the ones used by client when they ask a service ticket (DNS
hostname for the IP adress used in their /etc/openldap/ldap.conf files),
and the one used by the server itself (by default, the one returned by
gethostname(), otherwise, the one specified with sasl_hostname directive
in its configuration file).

You may also check in the KDC logs what are the principal requested by
clients.