OpenLDAP in der Version 2.1.21 erfordert eine Berkeley Datenbank in der Version 4.x!
Weitergehende Informationen sind bereits im Abschnitt sendmail als MTA behandelt worden und gelten auch hier!

Download

aktuelle OpenSSL Version von der Webseite laden,compilieren und installieren. Die momentan genutze Version kann mit

	[wwilhelm@mulder ~]# openssl version
	OpenSSL 0.9.6l 04 Nov 2003
      

gefunden werden. Mit Distributionen die auf Paketmanagern basieren die entsprechenden devel und/oder lib Pakete einspielen.
Die Hersteller bieten oft gepatchte Versionen, die nicht durch eine Erhöhung der Versionsnummer zu erkennen sind, am besten auf der Webseite nachschauen.

Ich habe aus den aktuellen Quellen selbst RPM Pakete gebaut, diese heissen (um Abgängigkeiten zu erfüllen) unter Linux Mandrake:

	libopenssl0-0.9.6l-1mdk
	libopenssl0-devel-0.9.6l-1mdk
	openssl-0.9.6l-1mdk
      

*Note: Im aktuellen Quellcode ist bereits eine .spec Datei enthalten mit der bequem RPM Pakete gebaut werden können. (Die Paketnamen sehen nach SuSE Linux aus). Mit einem Minorupdate musste ich nur OpenSSH neukompilieren, bei einem Major Upgrade müssen wohl alle Programme die die alten OpenSSL shared libaries nutzen neu übersetzt werden.

sendmail und SASL müssen gegen dieselbe BerkeleyDB gebaut werden.

Download * SASLv2 von ftp.andrew.cmu.edu/pub/cyrus-mail/
Durch die Migration zu Cyrus IMAP 2.1.15 verwende ich nun SASL in der Version 2.
Das Archiv entpacken und SASL bauen:

	[mulder cyrus-sasl-2.1.15]# LDFLAGS=-L/usr/local/BerkeleyDB.4.3/lib/ CPPFLAGS=-I/usr/local/BerkeleyDB.4.3/include/ ./configure --prefix=/usr --enable-login=yes --enable-krb4=no --sysconfdir=/etc --enable-pam
      

Die Methode LOGIN muss explizit angegeben werden wenn M$ Ausblick Clienten eingesetzt werden sollen,
alle anderen sind als default gesetzt, aus diesem Grund wurde in diesem Beispiel auch KERBEROS deaktiviert.
Zu beachten ist das auf dem System die nötigen *-devel Pakete installiert sind, dies gilt bsp. für PAM.

	[...]
	checking for PAM support... yes
	checking for db.h... yes
	checking for db_create in -ldb-4.1... yes
	checking DB library to use... berkeley
	checking CRAM-MD5... enabled
	checking DIGEST-MD5... enabled
	checking KERBEROS_V4... disabled
	checking PLAIN... enabled
	checking ANONYMOUS... enabled
	checking LOGIN... enabled
	checking NTLM... disabled
	[...]
      

	make && make install
      

	[mulder cyrus-sasl-1.5.28]# ll /usr/lib/sasl2/
	-rwxr-xr-x    1 root     root          736 Jun  2 09:32 libanonymous.la*
	lrwxrwxrwx    1 root     root           22 Jun  2 09:42 libanonymous.so -> libanonymous.so.2.0.13*
	lrwxrwxrwx    1 root     root           22 Jun  2 09:42 libanonymous.so.2 -> libanonymous.so.2.0.13*
	-rwxr-xr-x    1 root     root        83258 Jun  2 09:32 libanonymous.so.2.0.13*
	-rwxr-xr-x    1 root     root          724 Jun  2 09:31 libcrammd5.la*
	lrwxrwxrwx    1 root     root           20 Jun  2 09:42 libcrammd5.so -> libcrammd5.so.2.0.13*
	lrwxrwxrwx    1 root     root           20 Jun  2 09:42 libcrammd5.so.2 -> libcrammd5.so.2.0.13*
	-rwxr-xr-x    1 root     root        87366 Jun  2 09:31 libcrammd5.so.2.0.13*
	-rwxr-xr-x    1 root     root          754 Jun  2 09:31 libdigestmd5.la*
	lrwxrwxrwx    1 root     root           22 Jun  2 09:42 libdigestmd5.so -> libdigestmd5.so.2.0.13*
	lrwxrwxrwx    1 root     root           22 Jun  2 09:42 libdigestmd5.so.2 -> libdigestmd5.so.2.0.13*
	-rwxr-xr-x    1 root     root       134404 Jun  2 09:31 libdigestmd5.so.2.0.13*
	-rwxr-xr-x    1 root     root          727 Jun  2 09:31 libotp.la*
	lrwxrwxrwx    1 root     root           16 Jun  2 09:42 libotp.so -> libotp.so.2.0.13*
	lrwxrwxrwx    1 root     root           16 Jun  2 09:42 libotp.so.2 -> libotp.so.2.0.13*
	-rwxr-xr-x    1 root     root       209260 Jun  2 09:31 libotp.so.2.0.13*
	-rwxr-xr-x    1 root     root          720 Jun  2 09:32 libplain.la*
	lrwxrwxrwx    1 root     root           18 Jun  2 09:42 libplain.so -> libplain.so.2.0.13*
	lrwxrwxrwx    1 root     root           18 Jun  2 09:42 libplain.so.2 -> libplain.so.2.0.13*
	-rwxr-xr-x    1 root     root        82468 Jun  2 09:32 libplain.so.2.0.13*
	-rwxr-xr-x    1 root     root          736 Jun  2 09:31 libsasldb.la*
	lrwxrwxrwx    1 root     root           19 Jun  2 09:42 libsasldb.so -> libsasldb.so.2.0.13*
	lrwxrwxrwx    1 root     root           19 Jun  2 09:42 libsasldb.so.2 -> libsasldb.so.2.0.13*
	-rwxr-xr-x    1 root     root       138550 Jun  2 09:31 libsasldb.so.2.0.13*
      

LDAP ist eine Datenbank zum Ablegen von strukturierten Objekten und jedes kann mit einer Menge von Attributen ausgestattet sein. Die für ein Objekt notwendigen/erlaubten Attribute legt eine Schemadatei fest. Für eine UNIX oder Samba Benutzerverwaltung liegen den Quellpaketen bereits fertige Schemate bei. in Objekt kann mehreren Klassen angehören, um unterschiedliche Eigenschaften auszudrücken. So können die Unix und/oder Samba Attribute (uid,gid,sambaAcctFlags etc.) in einem zentralen Verzeichnis abgelegt und von jedem Klienten genutzt werden. Wichtig ist diese Art der Verwaltung für den Aufbau einer Windows NT4 Domänenstruktur, da in diesem Szenario die Benutzerdatenbank SAM auf den beteiligen PDC/BDC Rechner konsistent sein muss.

Installation

	LDFLAGS=-L/usr/local/BerkeleyDB.4.3/lib CPPFLAGS=-I/usr/local/BerkeleyDB.4.3/include \
	./configure --enable-spasswd --enable-crypt --with-tls --enable-ipv6=no --sysconfdir=/etc
	...
	make depend
	make test
	make install
      

übersetzt. Für weitere Informationen dienen die OpenLDAP Webseiten sowie die FAQ

Konfiguration

Um UNIX Benutzer im LDAP zu verwalten werden sog. POSIX Schemata in der Serverkonfiguration /etc/openldap/slapd.conf eingetragen

      include		/etc/openldap/schema/core.schema
      include		/etc/openldap/schema/cosine.schema
      include		/etc/openldap/schema/nis.schema
      include		/etc/openldap/schema/inetorgperson.schema
      

Um später eine verschlüsselte Verbindung (sensible Daten sollten nicht im Klartext über das Netz gesendet werden) wird der Dienst noch für SSL/START_TLS konfiguriert:

      TLSCACertificateFile    /etc/openldap/ssl/cacert.pem
      TLSCertificateFile      /etc/openldap/ssl/ldap.cert
      TLSCertificateKeyFile   /etc/openldap/ssl/ldap.key
      

Wie die nötigen Zertifikate (CA,SChlüssel,Zertifikat) zu erzeugen sind wurde bereits erläutert.

einfacher Datenbestand

	database        bdb
	suffix          "dc=my-domain,dc=com"
	rootdn          "cn=Manager,dc=my-domain,dc=com"
	rootpw          very_secret
	directory       /usr/local/var/openldap-data
	index   objectClass     eq
      

	rootpw {SSHA}oy8NdXUvuM8WRKzIBO83U6TcSA8cIj59
      

/etc/ldap.conf	UNIX LDAP Konfigurationsdatei, wird benötigt um UNIX Benutzer im Verzeichnis zu finden. Am besten setzt man einen symbolischen Link auf /etc/openldap/ldap.conf, um nicht zwei Dateien zu pflegen.
/etc/ldap.secret	UNIX Passwort Datei für LDAP Verzeichnis
/etc/openldap/ldap.conf	LDAP eigene Klientenkonfiguration (ldapsearch,ldapmodify etc.)
/etc/openldap/slapd.conf	LDAP Serverkonfiguration

OpenLDAP test

Die im LDAP abgelegten Objekte werden via ldapsearch abfragen. Damit ldapsearch mit Verschlüsselung funktionieren kann muss in den Konfigurationsdateien der FQDN eingetragen sein auf den auch das Zertifikat ausgestellt ist! Um vernünftig mit dem Kommando zu arbeiten sollten in /etc/openldap/ldap.conf ein paar Standartwerte gesetzt werden.

	ldapsearch -x -b "" -s base supportedSASLMechanisms
	dn:
	supportedSASLMechanisms: OTP
	supportedSASLMechanisms: DIGEST-MD5
	supportedSASLMechanisms: CRAM-MD5
      

	ldapsearch -x -b "" -s base -Z supportedSASLMechanisms
	dn:
	supportedSASLMechanisms: OTP
	supportedSASLMechanisms: DIGEST-MD5
	supportedSASLMechanisms: CRAM-MD5
      

	ldapsearch -x -D "cn=manager,dc=my-domain,dc=com" -W -b "" -s base -Z supportedSASLMechanisms
	Enter LDAP Password: 
	dn:
	supportedSASLMechanisms: OTP
	supportedSASLMechanisms: DIGEST-MD5
	supportedSASLMechanisms: CRAM-MD5
      

Verzeichnis vorbereiten

Nach dem Hochfahren von OpenLDAP ist das LDAP-Verzeichnis leer. Ojekte unterhalb des verantwortlichen Teilbaums des LDAP muss man manuell anlegen, insbesondere den Container, der die Wurzel des Teilbaums aufnimmt. Für diesen wird Objektklasse organization genutzt, einziges zwingendes Attribut ist der Name der Organisation o:

initial.ldif

	dn: dc=my-domain,dc=com
	objectClass: organization
	objectClass: dcObject
	dc: MY-DOMAIN
	o: MY-DOMAIN
      

	ldapadd -D "cn=manager,dc=my-domain,dc=com" -x -W -f initial.ldif
      

Die Option '-D' gibt den Namen an, mit dem man sich gegenüber dem LDAP-Server authentifiziert.

Name Service Switch

Die libnss ldap ermöglicht es die notwendigen UNIX Accountdaten wie Uid, Gid etc. aus einem LDAP Verzeichnis zu holen.Dies hat noch den Vorteil einer zentralen Anmeldestelle für UNIX Benutzer.
Um Samba als PDC mit LDAP-Anbindung betreiben zu können, muss Linux seine Benutzerinformationen ebenfalls aus dem LDAP-Baum beziehen. Dazu dient der nsswitch-Mechanismus der Glibc, der sämtliche Anfragen auf den Dateien /etc/passwd und /etc/group an dynamische Bibliotheken weiterleitet. Zum Paket nss_ldap gehört eine solche Bibliothek, die die Anfragen an einen LDAP-Server weiterleitet.

	  ./configure && make && make install
	

Sollte sich der Prozess über fehlende Programme/Dateien beschweren, einfach im Quellverzeichniss mal ./missing --help eingeben, damit kann die ein oder andere Klippe umschifft werden, ohne direkt wieder aktuelle Software einspielen zu müssen.
Mit den in /etc/ldap.conf konfigurierten Standardwerten ist auch nss_ldap fast fertig konfiguriert, es fehlt in /etc/nsswitch.conf lediglich der Eintag zum LDAP Verzeichniszugriff:

	  passwd: files ldap
	  group:  files ldap
	

Somit wird bei einer Benutzer/gruppenabfrage erst die lokale Dateie ausgewertet und dann der Verzeichnisserver. Damit sind die in LDAP angelegten posixAccount-Objekte unter Unix als Benutzer sichtbar, wovon man sich mit dem Aufruf getent passwd überzeugen kann. Erscheinen die Benutzer aus dem LDAP nicht in der Liste, könnte die Ursache im Name Service Caching Daemon nscd liegen, mit killall nscd beendet man seine Tätigkeiten.

Zu diesem Zeitpunkt sind noch keine Benutzer/Gruppen im LDAP Verzeichnis abgelegt, damit warte ich bis wir auf die smbldap Werkzeuge zu sprechen kommen, diese ermöglichen eine relativ einfache Organisation im LDAP-Baum.

Plugable Authentication Module (PAM) for Linux

Existiert das Benutzerpasswort im LDAP (Attribut userPassword), können sich Anwender über das PAM-Modul für LDAP pam_ldap authentifizieren. Es erfordert keine weitere Konfiguration, es greift genau wie nss_ldap auf /etc/ldap.conf zu. Lediglich die nur für die Verwendung der LDAP-Module vorgesehenen Dienste sind entsprechend einzurichten. Ein kurzes Beispiel wie dies für den sshd aussehen kann:

	  #%PAM-1.0
	  auth     required      pam_nologin.so
	  auth     sufficient    pam_ldap.so
	  auth     required      pam_unix.so      use_first_pass # set_secrpc
	  account  required      pam_unix.so
	  password required      pam_pwcheck.so
	  password required      pam_ldap.so      use_authtok
	  password required      pam_unix.so      use_first_pass use_authtok
	  session  required      pam_unix.so
	  session  required      pam_limits.so
	  session  required      pam_env.so
	

Mit dieser Konfiguration können normale Benutzer sich bei der LDAP-kontrollierten Maschine anmelden. PAM sollte auf allen aktuellen Distributionen zu finden sein, ein hervorragendes Howto findet sich auf kernel.org

Samba Domain Controller

Dieses Howto basiert auf der Samba Version 3.x und wurde mit Windows NT SP6a / Windows 2000 SP4 / Windows XP SP1 als Klienten getestet.
Seit der Einführung von OpenLDAP 2.x (Protokollversion 3) wird eine leicht modifizierte Schemacodierung (OID) verwendet, Samba in der Version 3.x trägt diesem Rechnung. Im Quellbaum der Sambadistribution sit ein Skript enthalten, welches LDIF Dateien mit sambaAccount Einträgen zu den neuen sambaSamAccount ObjektKlassen konvertiert.

Dokumentation

Die aktuellsten Versionen sind wie immer im Quellbaum zu finden!

• samba/docs/htmldocs/samba-ldap-howto.html (a must read!)
• samba/docs/Samba-HOWTO-Collection.pdf (a must read!)

Samba gewährt Zugriff auf eine Freigabe anhand eines Benutzername/Passwort Pärchens welches der Klient bei der Anfrage sendet. Die UNIX Passwortdatenbank ist aber inkompatibel zu den Windows Verschlüsselungsmechanismen, daher wird eine eigene Kennwortdatei verwaltet. Allerdings wird auch ein UNIX Account benötigt, dieser wird normalerweise über /etc/passwd realisiert. Wird nun die SMB Benuterverwaltung auf LDAP portiert tritt ein Problem auf: Die fehlenden POSIX Accounts!

Um es noch einmal hervorzuheben:
Samba nutzt zwei Arten der Benutzerverwaltung: sambaSAMAccount (lokal oder über Netzwerk) UND POSIX Accounts (lokal oder Netzwerk)

Samba mit LDAP Funktionalität

Wurden die LDAP Bibliotheken direkt aus dem Quelltext erzeugt (wie beschrieben), befinden sich die Dateien nicht im Standardsuchpfad der Konfigurationswerzeuge. Der Linker wird mit einem beherzten

	echo "/usr/local/lib" >> /etc/ld.so.conf && /sbin/ldconfig
      

	LDFLAGS=-L/usr/local/lib CPPFLAGS=-I/usr/local/include/ ./configure --with-smbmount=yes	
	[...]
	Using libraries:
	LIBS = -lcrypt -lresolv -lnsl -ldl 
	LDAP_LIBS = -lldap -llber 
	AUTH_LIBS = -lcrypt 
	[...]
	make && make install