LDAP-Server läuft halbwegs

[pixel]

Hi@all,

nach einer halben Ewigkeit bin ich zumindest ein Stück weiter mit meinem LDAP-Server. Der LDAP-Server läuft un ich kann von einem Client aus lesend und schreibend darauf zugreifen. Klingt völlig unspektakulär, wenn jedoch so lange daran rumgemacht hat, freut man sich auch über derartige Kleinigkeiten. Nun möchte ich mich den server testweise so einrichten das ein User-Login möglich ist. Im Moment habe ich lediglich das Hauptobjekt sowie root in der Datenbank.

Nun möchte ich einen einfachen Test machen mit lediglich einem Usern. Welche Objekte brauche ich hierzu zwingend? Ich denke ein Container für die User und eine für die Gruppen, richtig?

Füge ich dann alle Linux-Gruppen in den LDAP hinzu?

Und zu guter letzt, welche Objekteigenschaften (Attribute) sind für die OU der Gruppen bzw. User (also die Container-Objecte) sowie für die Blattobjekte der User bzw. Gruppen mindestens! notwendig um einen Login hinzubekommen?

Gruß Pixel

[mamue]

Original geschrieben von pixel
Hi@all,
Nun möchte ich einen einfachen Test machen mit lediglich einem Usern.
1.: Welche Objekte brauche ich hierzu zwingend?
2.: Ich denke ein Container für die User und eine für die Gruppen, richtig?
3.: Füge ich dann alle Linux-Gruppen in den LDAP hinzu?
4.: Und zu guter letzt, welche Objekteigenschaften (Attribute) sind für die OU der Gruppen bzw. User (also die Container-Objecte) sowie für die
5.: Blattobjekte der User bzw.
6.: Gruppen mindestens! notwendig um
7.: einen Login hinzubekommen?

Gruß Pixel

1.: posixAccount und Account ab openldap2.1 Bei führen Versionen ist account nicht zwingend, verstösst aber gegen Grundregeln.
2.: Kannst Du, musst Du aber nicht. Du kannst auf vielerlei Arten aufteilen, nach Funktionen (verwaltung, erste-etage, vorstand), nach region (brd, ddr, amiland), oder eben auch nach logischen Einheiten (people, accounts, groups, hardware) es bleiben lassen, oder auch mischen.
3.: Kannst Du machen, musst Du nicht. Denke daran, dass Du Dich sicher noch als root anmelden können möchtest auch wenn der ldap nicht läuft. In der nsswitch.conf steht ja auch die Liste der Auth.-quellen.
4.:


dn: ou=accounts,dc=my-org,dc=my-toplevel
objectClass: organizationalunit
ou: accounts
description: Benutzer

5.:


dn: uid=testuser4,ou=accounts,dc=my-org,dc=my-toplevel
objectClass: posixAccount
objectClass: account
uid: testuser4
uidNumber: 1003
cn: testuser4
loginShell: /bin/bash
gidNumber: 100
homeDirectory: /home/users/testuser4

6.:


dn: cn=daus,ou=groups,dc=my-org,dc=my-toplevel
cn: daus
objectClass: posixGroup
gidNumber: 4711

7.: Die Einträge in der nsswitch fehlen noch. Suche nach nsswitch.conf.
Daneben noch die Einträge nach Bedarf in den pam.d/serviceXY, etwa sshd, imap etc.

mamue

[pixel]

Hi,

ich habe im LDAP mal eine kleine 'Teststruktur' angelegt. Das heißt unterhalb des Hauptobjektes habe ich einen Container 'accounts' für die Benutzer und einen 'groups' für die Gruppen. Anschließend habe ich in diesen Containern einen User 'test' und die Gruppe 'testgrp' angelegt. Das hat alles ohne Probleme geklappt.

Mit der nsswitch bzw. ../pam.d habe ich noch so meine Verständnisprobleme. Meine /etc/nsswitch:

passwd: compat ldap
group: compat ldap

hosts: files dns
networks: files dns

services: files
protocols: files
rpc: files
ethers: files
netmasks: files
netgroup: files
publickey: files

bootparams: files
automount: files nis
aliases: files

ich denke mal die passt. Und in /etc/pam.d/ gibt es eine Datei 'sshd' mit dem Inhalt:

#%PAM-1.0
auth required pam_unix2.so # set_secrpc
auth required pam_nologin.so
auth required pam_env.so
account required pam_unix2.so
account required pam_nologin.so
password required pam_pwcheck.so
password required pam_unix2.so use_first_pass use_authtok
session required pam_unix2.so none # trace or debug
session required pam_limits.so
# Enable the following line to get resmgr support for
# ssh sessions (see /usr/share/doc/packages/resmgr/README.SuSE)
#session optional pam_resmgr.so fake_ttyname

Hier habe ich keine Ahnung was hier anzupassen ist.


Denke daran, dass Du Dich sicher noch als root anmelden können möchtest auch wenn der ldap nicht läuft. In der nsswitch.conf steht ja auch die Liste der Auth.-quellenHeist das ich packe alle Linux-Gruppen außer root in den LDAP? Mit den Linux-Systemusern (außer root) mache ich das gleiche? Welches System hat sich hier in der Praxis bewährt?

Wenn ich mich nun vom Client aus mit dem User 'test' per ssh einloogen möchte erhalte ich nach der Passworteingabe die Meldung:

Permission denied (publickey,keyboard-interactive).
Gruß Pixel

[[WCM]Manx]

Hi!

Meine /etc/pam.d/ssh => cracklib enabled ;)


#%PAM-1.0
auth required pam_nologin.so
auth sufficient pam_ldap.so
auth required pam_unix.so
auth required pam_env.so

account sufficient pam_ldap.so
account required pam_unix.so

session required pam_unix.so
session optional pam_lastlog.so
session optional pam_motd.so
session optional pam_mail.so standard noenv
session required pam_limits.so

# Alternate strength checking for password. Note that this
# requires the libpam-cracklib package to be installed.
# You will need to comment out the password line above and
# uncomment the next two in order to use this.

password required pam_cracklib.so retry=3 minlen=8 difok=3
password sufficient pam_ldap.so use_authtok
password required pam_unix.so use_authtok nullok md5

... da ist sicher einiges Unnötiges drin, aber es funktioniert.
PAM wirklich gut zu verstehen, ist heftig; etwas Hilfe:
http://www.kernel.org/pub/linux/libs/pam/Linux-PAM-html/pam.html
http://www.metaconsultancy.com/whitepapers/ldap-linux.htm

Grüße

Manx

[pixel]

Hi,

ich habe mir das Kapitel über PAM nochmal durchgelesen. Hier werden zuächst die Änderungen in /etc/nsswitch.conf besprochen. In dieser Datei wird immer zuerst der Service eingetragen gefolgt von der Art(en) wie er aufgelöst werden soll. In meiner Konfiguration sind im Moment die Eintragungen (Auszug) enthalten:

[...]
passwd: compat ldap
group: compat ldap
[...]Für 'compat' steht im Kommentar:

# compat Use compatibility setup

Was bedeutet dieser Eintrag? In den ganzen Beispielen steht anstelle von compat immer files drin gefolgt z.B. von LDAP. Wenn die Eintragungen nun:

[...]
passwd: files ldap
group: files ldap
[...]lauten würden wäre die Interpretaion klar. Wird ein Passwort zur Überprüfung angefordert wird zunächst in der Datei nachgesehen und wenn hier nichts gefunden wird, wird im LDAP-Server nachgeschaut. Nur 'compat' sagt mir recht wenig.

Als nächstens stellt sich für mich die Frage was der Service 'shadow' macht? Stehen in shadow nicht die verschlüsselten Passwörter? und müßte dann nicht der Eintrag:

shadow: files ldap
bzw.
shadow: compat ldapangefügt werden?

Nun noch zu ../pam.d/..

Hier betrachte ich zunächst die Zeilen 'auth ....' In deiner Datei hast du hier die Zeilen:


auth required pam_nologin.so
auth sufficient pam_ldap.so
auth required pam_unix.so
auth required pam_env.soBei mir ist lediglich eine Zeile vorhanden (siehe Fett gedrucktes). Hinter 'auth' folgt immer zuerst eine, ich nenne es mal Eigenschaft, die entweder required oder sufficient lautet. Wenn ich das mal so frei übersetze bedeutet das erste 'es ist zwingend erforderlich' und das zweite 'es ist aussreichend'
Im Handbuch finde ich als Hinweis zu den beiden Zeilen:

auth sufficient pam_ldap.so
auth required pam_unix.sofolgenden Hinweis:

Durch diesen Eintrag wird erreicht, dass ein Eintrag im Verzeichnisdienst, sofern vorhanden, zur Authentifizierung genügt, aber in jedem Fall ein Eintrag in 'passwd' vorhanden sein muß

Dies verwirrt mich ein wenig denn iin meiner derzeitigen Testkonfiguration existiert der Testuser nur in LDAP jedoch nicht in passwd somit könnte das doch gar nicht funktionieren. Oder habe ich etwas falsch verstanden?

Einen noch zum Schluß. Wenn ich an den Dateien /etc/nsswitch.conf bzw. den Dateinen in /etc/pam.d/ Änderungen vornehme, muß ich anschließend einen Daemon/Server wie z.B. sshd neu starten oder sind diese Änderungen sofort wirksam?

Gruß Pixel

[[WCM]Manx]

Hi!

Das sind ja viele Fragen auf einmal ;)
Zur Info, ich beschäftige mich auch erst seit kurzem mit der Materie, also wenn ich da Blödsinn verzapfe, sei's mir verziehen.

ad compat:
Das war bei mir auch so, ich hab's gegen "files" getauscht und noch keine Probleme beobachten können. Vielleicht mal in "man nsswitch.conf" reinschauen bzw:
Zitat: http://www.oreilly.com/catalog/linag2/book/ch13.html
compat - Be compatible with older file formats. This option can be used when either NYS or glibc 2.x is used for NIS or NIS+ lookups. While these versions normally can't interpret older NIS entries in passwd and group files, compat option allows them to work with those formats.

ad shadow: (das ist jetzt meine EIGENE Interpretation!)
/etc/shadow zu benutzen hat lokal IMHO nur den Sinn, dass die shadow-Datei nicht world-readable ist (im Gegensatz zu passwd), aus Sicherheitsgründen, damit nicht jeder an die Hashes kommt. In LDAP musst Du ja mit AccessLists arbeiten, und da mit viel Bedachtsamkeit vorgehen;
sprich die Passworthashes und vor allem für Samba die NTLM-Hashes, dürfen auf keinem Fall einsehbar sein (außer für Auth-Zwecke und Passwortänderungen)! "man slapd.access"
Es gibt aber auch eine objectClass "shadowAccount", die zusätzlich zum posixAccount weitere Attribute bietet (aber frag mich nicht ;) )


> Durch diesen Eintrag wird erreicht, dass ein Eintrag im Verzeichnisdienst, sofern vorhanden, zur Authentifizierung genügt, aber in jedem Fall ein Eintrag in 'passwd' vorhanden sein muß

Erklärung wieder mit IMHO ;)
Die Dateien in /etc/pam.d werden zeilenweise abgearbeitet, deshalb ist auch deren Reihenfolge bedeutend (Du kannst ja experimentieren).
Bei "sufficient" steigt er in dieser Zeile aus und führt keine weiteren Module dieses Typs (Typ= auth, account usw.), aus. Bei "required" wird weiter vorgegangen und erst am Ende gibt's ein o.k wenn alle erfolgreich gewesen sind.

... ich glaub die Änderungen greifen sofort, da sie ja bei jedem Login abgearbeitet werden.

Grüße

Manx

@Profis Korrekturen und Kritik erwünscht

[pixel]

Hi,

ok ich habe in der Datei /etc/pam.d/sshd die beiden Zeilen:


auth sufficient pam_ldap.so
[...]
account sufficient pam_ldap.so

eingefügt. Wenn ich mich nun als Testuser vom Client mit 'ssh -l test [Servername]' verbinden möchte erhalte ich noch immer die Meldung:

Permission denied (publickey,keyboard-interactive).

Noch jemand eine Idee?

Gruß Pixel

[[WCM]Manx]

Hi!

IHMO wirst Du ...

password sufficient pam_ldap.so
password required pam_unix.so

... auch brauchen:

Manx

[pixel]

Hi,

auch nachdem ich die beiden Zeilen noch eingefügt habe klappt der Login nicht. Immernoch die gleiche Meldung :confused:

Gruß Pixel

[pixel]

Hi,

ich habe mal am Server wärend dem Loginversuch vom Client aus (ssh) den Syslog überwacht. Dieser gibt folgendes aus:

sshd[14607]: Failed keyboard-interactive/pam for illegal user sven from ::ffff:192.168.0.131 port 32773 ssh2
sshd[14607]: error: PAM: System error
sshd[14607]: Failed keyboard-interactive for illegal user sven from ::ffff:192.168.0.131 port 32773 ssh2
sshd[14607]: error: PAM: System error
sshd[14607]: Failed keyboard-interactive for illegal user sven from ::ffff:192.168.0.131 port 32773 ssh2
sshd[14607]: Connection closed by ::ffff:192.168.0.131
Irgendetwas an meiner PAM-Konfiguration schein noch nicht zu passen, ich werde noch wahnsinnig.

Gruß Pixel

[pixel]

Hi,

ich habe mich mal weiter durch die Dokus gekämpft und einen Hinweis gefunden wie ich die /etc/ldap.conf anpassen soll

rootbinddn cn=root,dc=dreampixel
pam_login_attribute uid
pam_filter objecrclass=posixaccount
pam_mamber_attribut memberUid
pam_password exop

Anschließend soll ich unter /etc ein Datei ldap.secrets erzeugen welche das Passwort im Klartext enthält und sie anschließend auf chmod 400 setzen.

Was mir jetzt nicht klar ist. Wo muß ich die Datei anpassen? Am Server oder am Client?

Und stimmt die hier angegeben Groß/Klein - Schreibung?

Gruß Pixel

[[WCM]Manx]

Hi!

Welche Distributionen auf Server bzw. Client?
Unter Debian sind die Dateien /etc/pam_ldap.conf bzw. /etc/libnss-ldap.conf interessant.

Manx

[mamue]

Original geschrieben von pixel
Hi,

ich habe mich mal weiter durch die Dokus gekämpft und einen Hinweis gefunden wie ich die /etc/ldap.conf anpassen soll

rootbinddn cn=root,dc=dreampixel
pam_login_attribute uid
pam_filter objecrclass=posixaccount
pam_mamber_attribut memberUid
pam_password exop

Anschließend soll ich unter /etc ein Datei ldap.secrets erzeugen welche das Passwort im Klartext enthält und sie anschließend auf chmod 400 setzen.

Was mir jetzt nicht klar ist. Wo muß ich die Datei anpassen? Am Server oder am Client?


Die rootbinddn brauchst Du AFAIK nur, wenn dieser host sich an einem Verzeichniss authentifizieren soll und zwar an dem ldap.conf->URI, der keine anonymous binds versteht (ungenau, aber was soll's).
Für Openldap brauchst Du das nicht.
Somit auch nicht pam_password und auch keine ldap.secrets, in der im übrigen einfach das das Passwort drinsteht (exop).
Über die kleinen ungenauigkeiten bist Du Dir im klaren, nehme ich an: "pam_mamber...", "pam_filter objecrclass".

Gibt Dir denn getent passwd die Benutzer aus?

[pixel]

Hi,

sowohl der Server wie auch der Client sind SuSE-9.0

Die rootbinddn brauchst Du AFAIK nur, wenn dieser host sich an einem Verzeichniss authentifizieren soll und zwar an dem ldap.conf->URI, der keine anonymous binds versteht (ungenau, aber was soll's). Für Openldap brauchst Du das nicht.
ir ist nun nich ganz klar welche Anpassungen ich am Client vornehem soll. Ich habe den LDAP-Client einfach mit Yast konfiguriert.

Über die kleinen ungenauigkeiten bist Du Dir im klaren, nehme ich an: "pam_mamber...", "pam_filter objecrclass"
Wie meinst du das mit den Ungenauigkeiten? Mir wird die Sache immer unklarer :confused:

Gibt Dir denn getent passwd die Benutzer aus?Am Client oder am Server aufrufen?

Als ich vor kurzem zum ersten mal nach langer Zeit vom Client aus lesend und auch schreibend auf den LDAP-Server zugreifen konnte dachte ich wirklich das wäre der Durchbruch. Ich glaube ich habe mich da getäuscht und habe noch einen langen Weg vor mir.

Gruß Pixel

[mamue]

Original geschrieben von pixel
Hi,

sowohl der Server wie auch der Client sind SuSE-9.0

1.: ir ist nun nich ganz klar welche Anpassungen ich am Client vornehem soll. Ich habe den LDAP-Client einfach mit Yast konfiguriert.

2.: Wie meinst du das mit den Ungenauigkeiten? Mir wird die Sache immer unklarer :confused:
Am Client oder am Server aufrufen?

3.: Als ich vor kurzem zum ersten mal nach langer Zeit vom Client aus lesend und auch schreibend auf den LDAP-Server zugreifen konnte dachte ich wirklich das wäre der Durchbruch. Ich glaube ich habe mich da getäuscht und habe noch einen langen Weg vor mir.

Gruß Pixel
3.: Ist schon mal prima. Das ist kurz vorm Erfolg. ldapsearch ohne Agabe der Basis, also etwa ldapsearch -x objectclass=* sollte etwas bringen, das auf dem server gespeichert ist. Lokal wird ja sicher ohnehin kein ldap-server laufen, richtig?
2.: Du hattest einige Tippfuhler drin: pam_mamber, statt pam_member.
1.: Du solltest in der /etc/ldap.conf stehen haben:
die URI
URI ldap://ldap-server:389/
den BASE:
BASE dc=foo,dc=my-toplevel
pam_filter, pam_login_attribute, nss_base_passwd und nss_base_group, bei mir:
pam_filter objectclass=posixAccount
pam_login_attribute uid
nss_base_passwd ou=accounts,dc=foo,dc=my-toplevel?sub #später one
nss_base_group ou=groups,dc....

Die /etc/openldap/ldap.conf:
BASE siehe oben
URI siehe oben

Die /etc/nsswitch.conf
----snip----
passwd: files ldap
group: files ldap
----snap----

rcnscd stop
kill -SIGHUP 1
getent passwd
Jetzt sollten einige user aus dem server-ldap erscheinen.
Dort, wo sich user per IMAP, ssh etc anmelden sollen, musst Du noch die jeweiligen pam-conf anpassen /etc/pam.d/<DIENST>.

Viel Spass,
mamue

[pixel]

Hi@all,

wenn ich am Client 'ldapsearch -x objectclass=*' eingebe erhalte ich:

# extended LDIF
#
# LDAPv3
# base <> with scope sub
# filter: objectclass=*
# requesting: ALL
#

# search result
search: 2
result: 0 Success

# numResponses: 1

sieht irgendwie nicht so aus als ob das funktioniert. Nun habe ich am Client die von dir genannten Änderungen in /etc/ldap.conf, diese sieht nun wie folgt aus:

URI ldap://darwin:389/
host darwin
base dc=dreampixel
ldap_version 3
pam_filter
pam_filter objectclass=account
pam_login_attribute uid
pam_password crypt (war schon drin. Ich habe beide Systeme auf MD5 eingestellt??)
nss_base_passwd ou=accounts,dc=dreampixel?one
nss_base_group ou=groups,dc=dreampixel?one
ssl no

bzw. /etc/openldap/ldap.conf die nun so aussieht:

URI ldap://drarwin:389/
host darwin
base dc=dreampixel

Anschließend habe ich die Befehle:

Die nsswitch habe ich ebenfalls wie gesagt ergänzt und anschließend:
rcnscd stop
kill -SIGHUP 1

ausführe sowie 'getent passwd' bekomme ich zwar User angezeigt, das sind jedoch die vom Client. Das erkenne ich daran das der User 'sven' mit uid 500 angezeigt wird. Am Server gibt es den User 'sven' nicht in der /etc/passwd. Er existiert zwar im LDAP-Server unter ou=accounts hat dort jedoch die uid 1000.
Ich denke das ein meiner PAM-Konfiguration noch etwas nicht passt. Die oben genannten Anpassungen an den Dateien unterhalb von /etc/pam.d habe ich zu Anfang alle am LDAP-Server vorgenommen. Ich vermute mal das ich die Änderungen am Client ebenfalls durchführen muß. Waren die Anpassungen am Server überhaupt notwendig?

Gruß Pixel

[mamue]

Original geschrieben von pixel
Hi@all,

wenn ich am Client 'ldapsearch -x objectclass=*' eingebe erhalte ich:

# extended LDIF
#
# LDAPv3
# base <> with scope sub
# filter: objectclass=*
# requesting: ALL
#

# search result
search: 2
result: 0 Success

# numResponses: 1

1.: sieht irgendwie nicht so aus als ob das funktioniert. Nun habe ich am Client die von dir genannten Änderungen in /etc/ldap.conf, diese sieht nun wie folgt aus:

2.: Ich denke das ein meiner PAM-Konfiguration noch etwas nicht passt. Die oben genannten Anpassungen an den Dateien unterhalb von /etc/pam.d habe ich zu Anfang alle am LDAP-Server vorgenommen. Ich vermute mal das ich die Änderungen am Client ebenfalls durchführen muß. Waren die Anpassungen am Server überhaupt notwendig?

Gruß Pixel

2.: Die Änderungen betrafen natürlich den client.
Du authentifizierst dich ja zunächst mal am client, damit der weiss, wo das Passwort liegt, siehe oben.
Beim server wirst Du vielleicht ähnliches eintragen wollen.

1.: Nein, sieht nicht gut aus. Der ldapserver wird zwar gefunden (Du hast das doch vom client aus gemacht, oder?), aber es müssten _alle_ Einträge angezeigt werden, bis size-limit-exceeded. Meist deutet das darauf hin, dass die base nicht richtig ist, oder die Einträge dort nicht liegen.
Bekommst Du die gleiche Ergebnissmenge, wenn Du das auf dem Server machst? Du kannst mit ldapsearch -b dc=your,dc=sonstwat -x objectclass=* testen.
Ansonsten poste doch bitte mal den ldif eines users, damit wir BASE abgleichen können.

mamue

[[WCM]Manx]

... an den Slapd "access lists" kann's auch liegen. Wenn anonyme binds nicht erlaubt sind (so wie bei mir z.B) bekommst Du mit "ldapsearch -x" genau das gleiche wie pixel.

Grüße

Manx

PS: wenn Du in die slapd.conf ganz am Ende reinschreibst:
"access by * to * read" sollte ldapsearch -x Ergebnisse liefern.

[mamue]

Stimmt. Wär ich so nicht drauf gekommen, ich lasse anonyme reads auf alles bis auf die Passwörter zu. Warum auch nicht, schliesslich könnte das ja auch mal ein gemeinsames Adressbuch werden.

mamue