Zentrale Benutzerverwaltung mit LDAP, PAM und NSS
Jochen Wiedmann
Am Eisteich 9
72555 Metzingen
joe@ispsoft.de
1.) Klassische Benutzerverwaltung
1.1) Beurteilung der klassischen Benutzerdatenbank:
Positiv:
-
Transparenz
-
Schnell
-
Betriebssicher
Negativ:
-
Synchronisationsprobleme
-
Pflegeaufwand nahezu linear zur Anzahl der Maschinen
-
Fehlende Erweiterbarkeit
-
Unix-Spezifisch
Fazit: Ideal für Gebrauch auf Standalone-Servern
2.) Lösungsansatz: NIS (Network Information Service) = YP (Yellow
Pages)

2.1) Beurteilung der NIS-Benutzerdatenbank:
Positiv:
-
Transparenz (ypcat)
-
Pflegeaufwand (Nur NIS-Server)
-
Betriebssicherheit (Backup-Server)
-
Geht über /etc/passwd hinaus (/etc/hosts, /etc/networks, ...)
Negativ:
-
Langsam (Flaschenhals Netzwerk und Ineffiziente Datenbank)
-
Synchronisationsprobleme (kein integriertes Replikationsschema)
-
Fehlende Erweiterbarkeit
-
Unix-Spezifisch
Fazit: Gut für Gebrauch in reinen Unix-Netzwerken
3.) Moderne Lösungsansätze:
3.1) LDAP (Lightweight Directory Access Protocol)
-
Directory-Service
-
Offenes Protokoll (Netscape Directory Server, Novell 5, Lotus Notes 5,
Windows 2000, OpenLDAP, ...)
-
Für heterogene Netzwerke
-
Hierarchische Struktur
-
Flexible Objekte (Schemata):
objectclass posixAccount
requires
objectClass, uid,
userPassword, uidnumber,
gidnumber, cn, homedirectory,
loginshell, gecos,
description, mail, status
allows
mailForward, mailDrop,
mailForwardType
-
Keine festgelegte Datenbankstruktur, sondern reines Client-Server-Protokoll
-
Gut zugänglich durch Skriptsprachen, insbesondere Perl (Net::LDAP)
3.2) PAM (Pluggable Authentication Modules)

3.3) PAM im Detail
-
Reines C-API
-
Implementiert durch Shared-Libraries (pam_pwdb, pam_ldap, pam_smb, pam_nis,
pam_radius, ...)
-
Kombination verschiedener Libraries (z.B. pam_pwdb und pam_smb)
-
Benötigt Unterstützung auf Anwendungsebene
-
Erlaubt Änderungen von Paßworten und Accounting
-
Anwendung rein auf Benutzerdaten
-
Struktur nicht flexibel
-
Ursprünglich in Solaris 2.5, anwendbar seit Solaris 2.6
-
Red Hat Linux seit RH 4.0
-
Debian seit ?
-
SuSE-Linux seit 6.2
3.4) Beispiel: Login mit pam
Auszug aus /etc/pam.d/login:
#%PAM-1.0
auth required /lib/security/pam_securetty.so
auth required /lib/security/pam_nologin.so
auth sufficient /lib/security/pam_ldap.so
auth required /lib/security/pam_pwdb.so
shadow nullok
account required /lib/security/pam_pwdb.so
password required /lib/security/pam_crack.so
password required /lib/security/pam_pwdb.so
shadow nullok use_authtok
3.5) NSS (Name Service Switch)
-
Reines C-API
-
Implementiert durch Shared-Libraries (nss_ldap, ...)
-
Ursprünglich in Solaris 2.5
-
Implementiert in glibc2, daher keine Änderung der C-Quelltexte
-
Keine Änderungen von Paßworten, kein Accounting
-
Anwendung auf weitere Daten durch /etc/nsswitch.conf
-
Red Hat Linux seit RH 5.0
-
Debian seit 3.0
-
SuSE seit 6.0, soweit mit glibc 2 compiliert
3.6) NSS-Konfiguration: /etc/nsswitch.conf
passwd: files ldap
shadow: files ldap
hosts: files dns
Bedeutung des Eintrags "ldap": Statt direktem Zugriff auf die entsprechende
Datei (/etc/passwd, /etc/shadow) wird
/usr/lib/libnss_ldap.so
geladen und durch entsprechende C-Calls verwendet.
Schlecht: Fehlende Parametrisierung in der Konfigurationsdatei
3.7) Der LDAP-Server als Herzstück der Benutzerverwaltung
Konsequente Umsetzung des Prinzips der zentralen Benutzerverwaltung
mit LDAP, PAM und NIS
