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
 
 
