Hier will ich anhand von ein paar Beispielen zeigen wie vertrackt die Fehlersuche bei OpenLDAP sein kann. Das Problem liegt oft in einer Kombination von nichtssagende Fehlermeldungen, gepaart mit einem nur unvollständigen Verständnis dafür, was eigentlich geschieht.

Aber beginnen wir mit einem netten Beispiel:

Beispiel 1: Anlegen einer Gruppe im LDAP-Server schlägt fehl

Ausgangslage:

OpenLDAP wurde korrekt installiert, und läuft. Der Server kann von aussen angesprochen werden, und verhält sich auch alle Test entsprechend. So weit so gut. Man installiert lam, und loggt sich via Webinterface auf dem LDAP Server ein.

Hier lässt man von LDAP dann die Einheiten (ou) People, Groups, Machines, und Samba erstellen. Das alles funktioniert anscheinend reibungslos. Zum Beweis lassen wir uns das ganze noch mal anzeigen mit dem Befehl:

itoko# ldapsearch -x -b dc=calmar,dc=net -LLL

ergibt folgendes Ergebnis: Ausgabe ldapsearch Beispiel Fehlersuche

Wie man sehen kann hat der lam die Einheiten (ou) korrekt gesetzt. Jetzt erstellt man eine neue Gruppe, in der Gruppenansicht. Wenn man nach der Eingabe der Parameter das Ganze abspeichern will bekommt man folgende Fehlermeldung

Kann Gruppe test nicht anlegen "cn=test,ou=group,dc=calmar,dc=net" - Invalid Syntax

Nun die Fehlermeldung ist gelinde gesagt unglücklich. Die Syntax ist nämlich richtig. Wir haben uns vorher ja vergewissert, das die Einheit group existiert. Dementsprechend muss der Fehler wo anders liegen.

Zum Verständnis:

Wir wollen eine neue Gruppe anlegen.Diese Gruppe gehört zur Oberklasse group und beinhaltet diverse Parameter. Hier ein Beispiel für einen Datensatz der eine solche Gruppe beschreibt: OpenLDAP Fehlersuche Gruppe Datensatz

Dieser Datensatz soll nun in den Verzeichnis dienst eingefügt werden. Der LDAP Account Manager (lam) bricht mit der obigen Fehlermeldung ab. Also versuchen wir das ganze per Hand einzupflegen. Dafür übertragen wir den Datensatz in eine Textdatei gruppe.ldif und übertragen das Ganze in LDAP mit.

itoko# /usr/local/bin/ldapadd -f /usr/home/bic/gruppe.ldif -x -D "cn=Manager,dc=calmar,dc=net" -W
Enter LDAP Password: 
adding new entry "cn=user,ou=group,dc=calmar,dc=net"
ldap_add: Invalid syntax (21)
        additional info: objectClass: value #0 invalid per syntax

ha ..... Man beachte die Fehlermeldung. Der erste Teil ist der gleiche missverständliche Mist den schon der lam abgeliefert hat, aber im zweiten Teil heisst es

additional info: objectClass: value #0 invalid per syntax

Übersetzt soll das wohl heissen, daß er bei der Objektklasse keine 0 als Wert erlaubt. Allerdings heisst es in unseren Beispiel:

dn: cn=user,ou=group,dc=calmar,dc=net
objectClass: posixGroup
............

Nach einigem rumsuchen komme ich darauf, daß die Fehlermeldung bedeuten soll, daß er die ObjectClass posixGroup gar nicht kennt ! Und diese ist normalerweise in einem Schema definiert. Eine genaue Analyse bringt, das das Schema nis.schema nicht vorhanden ist.

Es genügt in der slapd.conf folgende Zeile nachzutragen

include         /usr/local/etc/openldap/schema/nis.schema (FreeBSD)

Damit wird jetzt das Schema nis.schema beim nächsten Start integriert, und alles funktioniert wieder.

Beispiel 2: Kein Login per XDM (PAM - Clientseitig) möglich

Ausgangslage:

OpenLDAP wurde korrekt installiert, und läuft. Der Server kann von aussen angesprochen werden, und verhält sich auch alle Test entsprechend. Der Client hat alle PAM Module instaliert.

Der Client kann eine Verbindung zum Server aufbauen und bekommt die Benutzerinformationen:

bic@haruka:~$ gentent passwd
................... 
schoener:*:10003:10000:schoener:/home/schoener:/bin/bash
bic@haruka:~$ 

Es ist sogar möglich sich per ssh mit einem LDAP-User auf der Maschine einzuloggen.

bic@misato:~$ ssh -l schoener 10.128.1.124 
schoener@10.128.1.124's password: 
Linux haruka 2.6.32-30-generic #59-Ubuntu SMP Tue Mar 1 21:30:21 UTC 2011 i686 GNU/Linux
Ubuntu 10.04.2 LTS

Welcome to Ubuntu!
 * Documentation:  https://help.ubuntu.com/

Last login: Tue Mar 29 09:13:37 2011 from misato.local
schoener@haruka:~$ 

Versucht man das Ganze jetzt mit dem grafischen LOGIN (XDM) so bricht dieser den Login-Vorgang ab.

Diagnose: Das Problme liegt beim XDM. Aber wo.

Auflösung:

Das Homeverzeichnis hatte die nachfolgenden Parameter

drwxr-xr-x 21 schoener schoener   4,0K 2011-03-29 09:08 schoener

Allerdings gibt es im LDAP Server zwar einen User schoener, allerdings keine Gruppe schoener. Und das scheint der XDM im Gegensatz zum login per ssh gar nicht zu mögen.

sudo chown schoener:user /home/schoener 

behebt das Problem, und lässt einen Login der XDM zu.

Beispiel 3: Keine Abfragen mehr per ldapsearch möglich

Ausgangslage:

OpenLDAP wurde korrekt installiert, und läuft. Der Server kann von aussen angesprochen werden. Der Client hat alle PAM Module installiert.

Der Client kann eine Verbindung zum Server aufbauen und bekommt die Benutzerinformationen:

bic@haruka:~$ gentent passwd
................... 
schoener:*:10003:10000:schoener:/home/schoener:/bin/bash
bic@haruka:~$ 

Allerdings sind plötzliche keine Abfragen mehr per ldapsearch mehr möglich.

bic@misato:~$ ldapsearch -h itoko -Y DIGEST-MD5 -b uid=schoener,ou=people,dc=calmar,dc=net 
SASL/DIGEST-MD5 authentication started
Please enter your password: 
ldap_sasl_interactive_bind_s: Invalid credentials (49)
        additional info: SASL(-13): user not found: no secret in database

Das gilt für alle User. Ldapsearch bildet sich ein, das es keine User mehr gibt. Im Ldap Account Manager allerdings sehen wir die User und auch die Passwörter sind korrekt. Das Einloggen per pam funktiniert einwandfrei.

Auflösung.

Fehler im Mapping in der /usr/local/etc/openldap/slapd.conf

Folgender Eintrag ist aus der slapd.conf verschwunden:

# SASL DIGEST-MD5 authorisation replacement directive
# This parameter is in the format of:
# uid=<username>,cn=<realm>,cn=<mech>,cn=auth
# The username is taken from sasl and inserted into the ldap search 
# string in the place of $1. Your realm is supposed to be your FQDN 
# (fully qualified domain name)
authz-regexp uid=admin,cn=[^,]*,cn=auth cn=admin,dc=calmar,dc=net 
authz-regexp uid=([^,]*),cn=[^,]*,cn=auth uid=$1,ou=people,dc=calmar,dc=net 
authz-policy      to

Ohne dieses "Mapping" kann er die DIGEST-MD5 Anfragen nicht richtig zuordnen. Interresanterweise scheint das nicht die Funktion der pam Module auf dem Client zu beinträchtigen.

(V1.02)