Ldap Howto

[Chrystalsky]

Moin,

wie einige mitbekommen haben, hatte ich gewisse Probleme mit Ldap. Jetzt habe ich mit der Hilfe von euch alles soweit geschafft und habe mir gedacht ich schreibe ein kleines tutorial bzw. einen Erfahrungsbericht, was ich gemacht habe und wie ich das ganze zum laufen gebracht habe. Das Tutorial ist für SuSE 9.0, dürfte aber auch bei anderen Systemen laufen (Pfad anpassen)

Ldap

Installation

Mit Yast das LdapV2-Server, Ldap-devel, nss_ldap und pam_ldap installieren und folgende Änderungen an der Config vornehmen:



/etc/openldap/slapd.conf #Server-Konfigurationsdatei

include /etc/openldap/schema/core.schema
include /etc/openldap/schema/cosine.schema
include /etc/openldap/schema/nis.schema
include /etc/openldap/schema/inetorgperson.schema
include /etc/openldap/schema/samba.schema
include /etc/openldap/schema/openldap.schema
pidfile /var/run/slapd.pid
argsfile /var/run/slapd.args
database ldbm #bestimmt die Datenbank.
suffix "dc=omeco,dc=de" #bestimmt Base DN (Name des directory)
rootdn "cn=Manager,dc=omeco,dc=de" #bestimmt Admin (root) Namen, Base DN muss dabeistehen
rootpw secret #root Passwort, auch eine Verschlüsselung ist möglich
directory /var/lib/ldap
index objectClass eq



/etc/openldap/ldap.conf #Client-Konfigurationsdatei

host 192.168.1.15 #bestimmt den Ldap-Server
base o=omeco.de #bestimmt Base DN wobei o für organization steht



/etc/ldap.conf #Konfigurationsdatei für Ldap-Namenservice, Pam-Modul, Shadow Paket und NSS

host: 192.168.1.15 #Ldap-Server
base: dc=omeco,dc=de #Anfang der Search Base
ldap_version 3 #Ldap Version die zu verwenden ist
pam_password crypt #aktiviert Unix-Crypt hash mechanism, ansonsten NT Synchronization Service
ssl no #deaktiviert SSL-Unterstützung

nss_base_passwd dc=omeco,dc=de #gibt an, wo sich die einzelnen Werte direkt befinden
nss_base_shadow dc=omeco,dc=de #laut Doku erst ab einer Datenbank von ca 5000 Einträgen
nss_base_group dc=omeco,dc=de #nötig, verringert dann die Suchzeit



/etc/nsswitch.conf #Konfigurationsdatei wo sich Pam auch die Einstellungen holt

passwd: compat ldap #Nur diese zwei Einträge müssen geändert werden
group: compat ldap #wobei "fast" immer SuSE bzw. Yast dies erledigt




Ldap starten, am besten direkt im RunLevel eintragen.


org.ldif anlegen und folgendes eintragen:

dn: dc=omeco,dc=de
objectclass: organization
o: omeco.de

ldapadd -D cn=Manager,dc=omeco,dc=de -x -W -f\ org.ldif

Hier haben wir den Hauptcontainer erstellt.

Der Befehl zum eintragen, ändert sich nicht und wird auch für die nachfolgenden Ldif-Dateien verwendet.

root.ldif anlegen und folgendes eintragen:

dn: cn=Manager,dc=omeco,dc=de
objectClass: organizationalRole
objectClass: top
objectClass: simpleSecurityObject
cn: Manager
description: Root User
userPassword: {crypt}e0tn415VzByrY

dies ist nun der Hauptuser. Das passwort ist unverschlüsselt secret.


groups.ldif anlegen und folgendes eintragen:

dn: ou=groups,dc=omeco,dc=de
objectClass: organizationalUnit
objectClass: top
ou: groups
description: Gruppen

dies ist die Standartgruppe, in der neue User eingetragen werden. Weitere Eintragungen, wie Standartpasswort sind noch möglich


user.ldif anlegen und folgendes eintragen:

dn: ou=people,dc=omeco,dc=de
objectClass: organizationalUnit
objectClass: top
ou: people

dn: cn=Michael B,ou=people,dc=omeco,dc=de
userPassword: 12345
cn: Michael B
gecos: Michael B
gidNumber: 100
homeDirectory: /home/michael
loginShell: /bin/bash
objectClass: top
objectClass: person
objectClass: posixAccount
objectClass: shadowAccount
shadowExpire: -1
shadowFlag: 0
shadowInactive: -1
shadowLastChange: 10877
shadowMax: 999999
shadowMin: 0
shadowWarning: 7
sn: B
uid: michael
uidNumber: 1001

Somit hätten wir unseren ersten User angelegt. Bevor man restartet, sollte man noch die gid (Gruppen ID) nachprüfen, ob diese auch wirklich noch frei ist, bei uid natürlich auch. Dann steht einem ersten Loginversuch nichts mehr im Weg.

Der Restart ist nicht notwendig, man kann auch über die Konsole die einzelnen Dienste neustarten, ich habe die Methode des Neustarts gewählt, um sicher zu sein, dass ich nichts vergesse und weil es einfacher ist/war.


Samba und Ldap

Seit dem Release 2.2.3a von Samba, wird Ldap unterstützt. Leider ist es immernoch notwendig, Samba neu zu kompilieren, damit es mit Ldap lauffähig ist.

Syntax:

./configure -with-ldapsam
make
make install

libldap-dev und libsldapd-dev werden aber dazu benötigt, achtung sind die beiden Dateien nicht vorhanden, so meldet Samba keine Fehlermeldung, mit:

./configure --with-ldapsam | grep ldap

meldet er ldap.h failed, wenn die beiden Dateien nicht vorhanden sind. Dann sollte man nachinstallieren und make clean vor der Neuinstallation durchführen.

Ab Version 3 unter SuSE ist dies nicht mehr notwendig. Bei mir lokal wurden die RPM-Pakete gleich mit ldap-Unterstützung installiert, dies ist aber erst seit SuSE Version 9.0 der Fall.

In der Datei SMB.conf sollten dann folgende Einträge hinzugekommen sein:


/etc/samba/smb.conf

[global]
ldap server = 127.0.0.1
ldap admin dn = cn=Manager,dc=omeco,dc=de





Übernahme der bestehenden User

unter: http://www.padl.com/OSS/MigrationTools.html findet man Shell-Skripte, welche die Übernahme bestehender User in Ldap übernehmen.

Ich hoffe es ist leicht verständlich. Würde mich über ein kleines Feedback freuen.


*greetz*

[fons]

2. fragen:

für was nimmst du den ldap her? nur samba, oder auch ftp,squid oder ähnliches

welches tool nimmst du zur benutzerverwaltung?


per web administration find ich http://phpldapadmin.sourceforge.net/ nicht schlecht

[switch]

Chrystalsky, grossartig dass du deine Erfahrungen mit ldap veröffentlicht hast. Ich werde mich demnächst damit beschäftigen. Vielen Dank im Voraus.
Gruss

[switch]

Chrystalsky, ich habe noch eine Frage:

wieso hast du SAMBA 2.x eingesetzt und nicht SAMBA 3.x?

Gruss

[Chrystalsky]

@fons

ich habe nur Samba vorerst eingesetzt, da es sich um ein grösseres privates Netzwerk handelt und ftp usw nicht benötigt wird. Evtl. aber noch ssh, aber dafür lass ich mir noch etwas Zeit, im moment habe ich genug von Ldap =)

Zur Verwaltung habe ich eigenltich direkt per Konsole gearbeitet, bis zu dem Punkt, wo das Tutorial aufhört. Danach habe ich GQ benutzt um durch die Struktur zu browsen und um neue User anzulegen/ändern.

Auch unter Webmin habe ich es eingerichtet, scheint auch ganz gut zu sein, habs mir aber nicht weiter angeschaut.

@switch

Ich habe Samba 3.x benutzt. Das mit dem kompilieren sollte nur als Hinweis gelten


*greetz*

[zylinder]

hi

verdammt geil das du deine erfahrungen dokumentiert hast,
hilft mir noob schon ziemlich..

aber habe da eine fehlermeldung bekommen als ich den hauptcontainer erstellen wollte:

linux:/etc/openldap # ldapadd -D "cn=Manager,dc=omeco,dc=de" -x -W -f org.ldif
Enter LDAP Password:
adding new entry "dc=omeco,dc=de"
ldapadd: update failed: dc=omeco,dc=de
ldap_add: Naming violation (64)
additional info: naming attribute 'dc' is not present in entry


hab leider keine ahnung was ich nun tun soll.. jemand ne idee wiso er motzt?

[CYP]

hi

linux:/etc/openldap # ldapadd -D "cn=Manager,dc=omeco,dc=de" -x -W -f org.ldif
Enter LDAP Password:
adding new entry "dc=omeco,dc=de"
ldapadd: update failed: dc=omeco,dc=de
ldap_add: Naming violation (64)
additional info: naming attribute 'dc' is not present in entry


hab leider keine ahnung was ich nun tun soll.. jemand ne idee wiso er motzt?

ich denke mal du hast noch eine leere datenbank dann musst du bevor du
dc=omeco,dc=de erstellen kannst erst mal
dc=de erstellen -> also in deine ldif datei:

dn: dc=de
objectclass: organization
o: de

dn: dc=omeco,dc=de
objectclass: organization
o: omeco.de

[Technikman]

mhh....

irgendwas hab ich noch falsch gemacht... hab noch ne leere Datenbank, aber wenn ich das so mach dann kommt bei mir

ldap_add: Server is unwilling to perform (53)
additional info: referral missing



find nur leider nix was mir wirklich helfen würde...

[mamue]

Moin,
/etc/openldap/ldap.conf #Client-Konfigurationsdatei

host 192.168.1.15 #bestimmt den Ldap-Server
base o=omeco.de #bestimmt Base DN wobei o für organization steht


*greetz*

Wenn in der slapd.conf schon dc=omeco,dc=de steht, sollte das in der ldap.conf auch so drin stehen, also
base dc=omeco,dc=de
Die LDIF-Einträge müssen natürlich auch dementsprechend sein.

mamue

[steam]

hab kleines Prob. Habe das die Authentifikation über nss_ldap über LDAP gelöst.
Das ganze läuft wunderbar und hollt sich die benutzer aus dem LDAP, nur aber...
Sobal das LDAP-server down ist, dauert das root-login ewig.
Normaleweise soll das root-account über files gezogen werden. Dem nss_ldap ist es egal, ob root im LDAP-tree existiert, er will auf jeden fall erst da nachschauen und erst dann in den files. Und es nervt. Ich will es umgekehrt haben.
Habe in /etc/nsswitch.conf die reihenfolge der backends geändert - hilft aber nicht.

Weis jemand, wie ich es dem nss_ldap abgewöhnen kann?

[emba]

NSS muss die reihenfolge files ldap haben
das ist die halbe miete - dann wär da noch PAM
in der login hast du sicherlich erst pam_ldap.so und dann pam_unix.so oder?

greez

[steam]

Hehe, wenn nur alles so einfach wäre. Wie ich schon beschrieben habe, die Reihenfolge macht es nicht aus, habe schon ausprobiert. Ob da
files ldap
oder
ldap files
oder
compat ldap
steht, nützt mir nicht. Der schaut sowieso erst im ldap, versucht da zu zuchen, und falls nichts findet, schaut dann in die files.

Pam ist für mich nicht relevant, da slackware.

[mamue]

Bei Experimenten mit dem ldap unbedingt sicherstellen, dass der nscd _nicht_ läuft, am besten auch danach ausgeschaltet lassen ;-). Im übrigen hat emba schlicht recht, der NSS muß die Reihenfolge files ldap haben. Unter umständen INIT mal ein SIGHUP schicken (kill -SIGHUP 1 )
Das hat soweit erst einmal noch nichts mit pam zu tun.

mamue

[steam]

nscd läuft bei mir nicht
kill -SIGHUP 1 hat nichts gebracht

ich habe irgendwie den Eindruck, dass ich chinesisch schreibe/spreche, oder die Leute das was ich schreibe nicht lesen.

Ich sage es nochmalls ganz deutlich:

Die Reihenfolge im /etc/nsswitch.conf scheint bei mir keine Rolle zu spielen. Sobald das ldap nicht on ist, dauert das root-login eine ewigkeit. Sobalt ich den ldap wieder hochfahre, geht es ratz-fatz-schnell, obwohl solchen user wie root im ldap-baum nicht gibt.
Daraus schliesse ich, dass nss_ldap fieberhaft doch nach dem ldap sucht, sogar eine Weile, und dann, wenn nicht finden, schaut in die files. Wenn LDAP da ist, schaut nss_ldap sofort rein, findet den user nicht und schaut in die files.
Habe schon alle reihenfolgen ausprobiert - hilft nicht.

[emba]

du könntest natürlich mal schauen, ob deine implementation von NSS fehlerhaft ist unter slack. desweiteren kannst du prüfen, in welcher reihenfolge aufgelöst wird, wenn du getent passwd eingibst. werden dort immer zuerst die lokalen accounts angezeigt und dann die ldap accounts, bin ich ziemlich sicher, dass es nicht am NSS liegt.

gibt es unter slack kein PAM?

greez