tomiondrums
n00b
Joined: 02 Feb 2007
Posts: 54
Location: Unterleinleiter
|
 Posted: Sun Jun 21, 2009 9:19 pm Post subject: LDAP-Server findet keine Benutzer im Verzeichnis |
 |
|
Hallo,
Ich bin jetzt schon seit Tagen dran, einen LDAP-Server aufzusetzen und meine Clients auch entsprechend umzustellen. Verwendet hab ich dafür den folgenden Leitfaden, weil er eigentlich nen ganz passablen Eindruck gemacht hat: http://www.gentoo.de/doc/de/ldap-howto.xml?style=printable
Der Server lässt sich auch fehlerfrei Starten und ich bin nach langem Probieren auch schon in der Lage, einige Daten von meinem alten Nis-Server ins Verzeichnis zu migrieren, wenngleich auch die empfohlenen Skripte ungefähr beim Übertragen der RPC-Einstellungen abbrechen (die brauch ich eh nicht). Jedenfalls hat der Baum (ich betrachte ihn mit phpldapadmin) eine Wurzel dc=dwunder und einige Äste wie zB. ou=Group, ou=People, ou=Aliases, ou=Hosts etc. an denen wiederum die ganzen Gruppen bzw. Hosts bzw Benutzer mit den jeweiligen korrekt von meinem alten NIS-Server übertragenen Daten hängen. Soweit so toll.
Die Clients hab ich auch entsprechend dem Leitfaden eingerichtet und beim Versuch eines Logins auf selbigen nach vollständigem Einrichten passiert dann folgendes:
- Ich bekomme "Login Incorrect" als Antwort
- PAM schreibt mir folgendes in die /var/log/messages:
| Code: |
Jun 21 22:58:30 pcnote login[3751]: pam_tally(login:auth): pam_get_uid; no such user
Jun 21 22:58:31 pcnote login[3751]: pam_unix(login:auth): check pass; user unknown
Jun 21 22:58:31 pcnote login[3751]: pam_unix(login:auth): authentication failure; logname=LOGIN uid=0 euid=0 tty=tty2 ruser= rhost=
Jun 21 22:58:34 pcnote login[3751]: FAILED LOGIN (1) on 'tty2' FOR `UNKNOWN', User not known to the underlying authentication module
|
Auf dem Server (die Uhren sind nicht 100%ig synchron) passiert das:
| Code: |
Jun 21 22:59:40 mainsrv slapd[29665]: conn=95 fd=22 ACCEPT from IP=192.168.10.74:52154 (IP=0.0.0.0:389)
Jun 21 22:59:40 mainsrv slapd[29665]: conn=95 op=0 BIND dn="" method=128
Jun 21 22:59:40 mainsrv slapd[29665]: conn=95 op=0 RESULT tag=97 err=0 text=
Jun 21 22:59:40 mainsrv slapd[29665]: conn=95 op=1 SRCH base="ou=People,dc=dwunder" scope=1 deref=0 filter="(&(objectClass=posixAccount)(uid=tomi))"
Jun 21 22:59:40 mainsrv slapd[29665]: conn=95 op=1 SRCH attr=uid userPassword uidNumber gidNumber cn homeDirectory loginShell gecos description objectClass
Jun 21 22:59:40 mainsrv slapd[29665]: <= bdb_equality_candidates: (uid) not indexed
Jun 21 22:59:40 mainsrv slapd[29665]: conn=95 op=1 SEARCH RESULT tag=101 err=0 nentries=0 text=
Jun 21 22:59:40 mainsrv slapd[29665]: conn=95 op=2 SRCH base="ou=People,dc=dwunder" scope=1 deref=0 filter="(&(objectClass=posixAccount)(uid=tomi))"
Jun 21 22:59:40 mainsrv slapd[29665]: conn=95 op=2 SRCH attr=uid userPassword uidNumber gidNumber cn homeDirectory loginShell gecos description objectClass
Jun 21 22:59:40 mainsrv slapd[29665]: <= bdb_equality_candidates: (uid) not indexed
Jun 21 22:59:40 mainsrv slapd[29665]: conn=95 op=2 SEARCH RESULT tag=101 err=0 nentries=0 text=
Jun 21 22:59:40 mainsrv slapd[29665]: conn=95 op=3 SRCH base="ou=People,dc=dwunder" scope=1 deref=0 filter="(&(objectClass=posixAccount)(uid=tomi))"
Jun 21 22:59:40 mainsrv slapd[29665]: conn=95 op=3 SRCH attr=uid userPassword uidNumber gidNumber cn homeDirectory loginShell gecos description objectClass
Jun 21 22:59:40 mainsrv slapd[29665]: <= bdb_equality_candidates: (uid) not indexed
Jun 21 22:59:40 mainsrv slapd[29665]: conn=95 op=3 SEARCH RESULT tag=101 err=0 nentries=0 text=
Jun 21 22:59:40 mainsrv slapd[29665]: conn=95 op=4 SRCH base="ou=People,dc=dwunder" scope=1 deref=0 filter="(&(objectClass=posixAccount)(uid=tomi))"
Jun 21 22:59:40 mainsrv slapd[29665]: conn=95 op=4 SRCH attr=uid userPassword uidNumber gidNumber cn homeDirectory loginShell gecos description objectClass
Jun 21 22:59:40 mainsrv slapd[29665]: <= bdb_equality_candidates: (uid) not indexed
Jun 21 22:59:40 mainsrv slapd[29665]: conn=95 op=4 SEARCH RESULT tag=101 err=0 nentries=0 text=
Jun 21 22:59:41 mainsrv slapd[29665]: conn=95 op=5 SRCH base="ou=People,dc=dwunder" scope=1 deref=0 filter="(&(objectClass=posixAccount)(uid=tomi))"
Jun 21 22:59:41 mainsrv slapd[29665]: conn=95 op=5 SRCH attr=uid userPassword uidNumber gidNumber cn homeDirectory loginShell gecos description objectClass
Jun 21 22:59:41 mainsrv slapd[29665]: <= bdb_equality_candidates: (uid) not indexed
Jun 21 22:59:41 mainsrv slapd[29665]: conn=95 op=5 SEARCH RESULT tag=101 err=0 nentries=0 text=
Jun 21 22:59:41 mainsrv slapd[29665]: conn=96 fd=24 ACCEPT from IP=192.168.10.74:52155 (IP=0.0.0.0:389)
Jun 21 22:59:41 mainsrv slapd[29665]: conn=96 op=0 BIND dn="" method=128
Jun 21 22:59:41 mainsrv slapd[29665]: conn=96 op=0 RESULT tag=97 err=0 text=
Jun 21 22:59:41 mainsrv slapd[29665]: conn=96 op=1 SRCH base="ou=People,dc=dwunder" scope=2 deref=0 filter="(&(objectClass=posixAccount)(uid=tomi))"
Jun 21 22:59:41 mainsrv slapd[29665]: <= bdb_equality_candidates: (uid) not indexed
Jun 21 22:59:41 mainsrv slapd[29665]: conn=96 op=1 SEARCH RESULT tag=101 err=0 nentries=0 text=
Jun 21 22:59:44 mainsrv slapd[29665]: conn=95 op=6 SRCH base="ou=People,dc=dwunder" scope=1 deref=0 filter="(&(objectClass=posixAccount)(uid=tomi))"
Jun 21 22:59:44 mainsrv slapd[29665]: conn=95 op=6 SRCH attr=uid userPassword uidNumber gidNumber cn homeDirectory loginShell gecos description objectClass
Jun 21 22:59:44 mainsrv slapd[29665]: <= bdb_equality_candidates: (uid) not indexed
Jun 21 22:59:44 mainsrv slapd[29665]: conn=95 op=6 SEARCH RESULT tag=101 err=0 nentries=0 text=
|
Ganz offenbar sucht der Server also ernsthaft nach dem Benutzer 'tomi' und findet ihn aber nicht (nentries=0), obwohl es ihn nachweislich im Verzeichnis unter ou=People gibt. Ich fürchte das liegt an der Option 'deref=0', weil wenn ich exakt dieselbe Suchanfrage vom Client aus über phpldapadmin starte, also mit dem filter="(&(objectClass=posixAccount)(uid=tomi))" attr=uid userPassword uidNumber gidNumber cn homeDirectory loginShell gecos description objectClass und scope=one, dann findet er nämlich den gewünschten Benutzereintrag 'tomi' tadellos. Der Punkt ist nur daß man das deref-Attribut mit phpldapadmin nicht angeben kann und er automatisch 3 (ich schätze das wäre dann 'always') dafür nimmt - es steht dann zumindest im Log (welches wie oben aussieht, aber halt mit dem Unterschied, daß deref=3 ist).
Nun kann man ja auf die Idee kommen und sagen DEREF kann ja in der ldap.conf eingestellt werden. Dummerweise hab ich das jetzt bis zum Erbrechen probiert (sowohl auf dem Server als auch auf dem Client), nur schert sich die Suchanfrage, die beim Login-Versuch gestellt wird, wenig drum und nimmt immer automatisch deref=0.
Was kann ich tun? Deref bezieht sich ja auf die Auflösung von Aliasen, nur weiß ich leider nicht wie ich solche erkenne und was ich konkret unternehmen kann, damit es keine mehr im Baum gibt. Kann es auch sein, daß in meinem Verzeichnis noch irgendwas fehlt und die Sache deswegen nicht geht?
Vielen Dank schonmal an alle dies bis hierher gelesen haben und helfen wollen!
MfG
Tom |
|
Deutsches Forum (German)
