Lade Inhalt...

Zentrale Benutzerverwaltung für heterogene Netzwerkumgebungen mit LDAP und Samba

©2004 Diplomarbeit 82 Seiten

Zusammenfassung

Inhaltsangabe:Einleitung:
In grossen Firmen und Institutionen müssen Tausende Arbeitsstationen mit Zehntausenden Benutzerkonten verwaltet werden. Es werden verschiedene Betriebsysteme eingesetzt, oft müssen die Benutzer sich an beliebigen Rechnern anmelden können (z.B. in Universitäten). Hier entsteht das Problem effektiver Benutzerverwaltung. Im Idealfall müssen alle Benutzerkonten zentral verwaltet werden, was bei heterogenen Umgebungen sich immer noch als schwierig erweist. Windows-Systeme haben eigene Besonderheiten, die sich mit Solaris- bzw. Linuxsystemen nur schwer koppeln lassen. Es wird noch zusätzlich dadurch erschwert, dass mehrere Ansätze für Benutzerverwaltung existieren, die zu einander nicht kompatibel sind. Grundsätzlich haben sich 3 Systeme für zentralisierte Benutzerverwaltung durchgesetzt:
- Microsoft Active Directory (als Nachfolger von Domain-Konzept).
- NIS, NIS+.
- Novells NDS und eDirectory.
Die ersten zwei verkörpern zwei unterschiedliche Welten im Desktop- bzw. Serverbereich, nämlich Windows- und Unixwelt. Die Techniken, die von diesen Systemen für zentralisierte Benutzerverwaltung eingesetzt werden, sind zueinander nicht kompatibel. Sie lassen sich gemeinsam mit einem einzigen Daten bestand nicht verwenden. Die Lösung von Microsoft funktioniert nur mit Microsoft-Produkten (Windows95/98/ME/2000/XP/2003). Im Gegensatz dazu wurde NIS aber für viele Unix-ähnliche Systeme implementiert. Novell dagegen hat schon immer plattformübergreifende Lösungen entworfen. Zum größten Teil setzte man Novells NetWare ein, um zentralisierte Benutzerverwaltung in einem Netzwerk bestehend aus DOS/Windows3.11/Windows95/Windows98 Systemen zu realisieren. Später wurde auch Clientsoftware für andere Betriebsysteme (nicht aus dem Hause Microsoft) entwickelt (z.B. MacOS, Linux). Für den Einsatz in anspruchsvollen heterogenen Umgebungen hat Novell spätere Directory entworfen. Mit eDirectory versucht Novell-, Microsoft- und Unixwelt unter ein Dach zu bringen. Dabei setzt Novell auf transparente Technologien. Es wird ein LDAP-Server für zentralisierte Benutzerverwaltung in heterogenen Netzwerken verwendet. EDirectory verfügt über offene Schnittstellen zum SOAP, XML und viele anderen Standards.

Inhaltsverzeichnis:Inhaltsverzeichnis:
1.Einleitung5
1.1Beschreibung der Thematik5
1.2Zielsetzung der Arbeit5
1.3Software6
1.4Beschreibung der Testumgebung7
1.4.1Testumgebung I – Labor7
1.4.2Testumgebung II – […]

Leseprobe

Inhaltsverzeichnis


ID 8156
Wischnewski, Markus: Zentrale Benutzerverwaltung für heterogene Netzwerkumgebungen
mit LDAP und Samba
Hamburg: Diplomica GmbH, 2004
Zugl.: Fachhochschule Fulda, Diplomarbeit, 2004
Dieses Werk ist urheberrechtlich geschützt. Die dadurch begründeten Rechte,
insbesondere die der Übersetzung, des Nachdrucks, des Vortrags, der Entnahme von
Abbildungen und Tabellen, der Funksendung, der Mikroverfilmung oder der
Vervielfältigung auf anderen Wegen und der Speicherung in Datenverarbeitungsanlagen,
bleiben, auch bei nur auszugsweiser Verwertung, vorbehalten. Eine Vervielfältigung
dieses Werkes oder von Teilen dieses Werkes ist auch im Einzelfall nur in den Grenzen
der gesetzlichen Bestimmungen des Urheberrechtsgesetzes der Bundesrepublik
Deutschland in der jeweils geltenden Fassung zulässig. Sie ist grundsätzlich
vergütungspflichtig. Zuwiderhandlungen unterliegen den Strafbestimmungen des
Urheberrechtes.
Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. in
diesem Werk berechtigt auch ohne besondere Kennzeichnung nicht zu der Annahme,
dass solche Namen im Sinne der Warenzeichen- und Markenschutz-Gesetzgebung als frei
zu betrachten wären und daher von jedermann benutzt werden dürften.
Die Informationen in diesem Werk wurden mit Sorgfalt erarbeitet. Dennoch können
Fehler nicht vollständig ausgeschlossen werden, und die Diplomarbeiten Agentur, die
Autoren oder Übersetzer übernehmen keine juristische Verantwortung oder irgendeine
Haftung für evtl. verbliebene fehlerhafte Angaben und deren Folgen.
Diplomica GmbH
http://www.diplom.de, Hamburg 2004
Printed in Germany

Inhaltsverzeichnis
1. Einleitung
5
1.1. Beschreibung der Thematik . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
1.2. Zielsetzung der Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
1.3. Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6
1.4. Beschreibung der Testumgebung
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
1.4.1. Testumgebung I - Labor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
1.4.2. Testumgebung II - VMWare . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8
2. Benutzerverwaltung
9
2.1. Benutzerverwaltung unter Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
2.1.1. Workstation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
2.1.2. Primary Domain Controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10
2.1.3. Active Directory Server
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10
2.2. Benutzerverwaltung unter Unix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11
2.2.1. shadow-System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11
2.2.2. NIS
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12
2.2.3. NIS+
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12
2.3. Benutzerverwaltung unter Novell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
14
2.3.1. NDS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
14
2.3.2. eDirectory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
14
2.4. Wichtige Anforderungen an die zentralisierte Benutzerverwaltung in heterogenen Netz-
werkumgebungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15
2.4.1. Punkt 1 - keine redundant gespeicherte Benutzerdaten . . . . . . . . . . . . . .
16
2.4.2. Punkt 2 - keine Inkonsistenzen . . . . . . . . . . . . . . . . . . . . . . . . . . .
16
2.4.3. Punkt 3 - ein einziges Heimatverzeichnis . . . . . . . . . . . . . . . . . . . . . .
16
2.4.4. Punkt 4 - offene und verbreitete Technologien . . . . . . . . . . . . . . . . . . .
16
2.4.5. Punkt 5 - Verwendbarkeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16
2.4.6. LDAP und SAMBA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16
3. SSL
18
3.1. Zertifikate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18
3.2. RSA - Verschlüsselung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18
4. Verzeichnisdienste
19
4.1. eDirectory und Active Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
19
4.2. X.500 und LDAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
19
4.2.1. Aufbau
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
19

Inhaltsverzeichnis
3
4.2.2. Master-Slave Konzept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
21
4.2.3. Replizierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
21
4.2.4. Die Partitionierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
22
4.2.5. Sicherheit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
22
4.2.6. Administrator und Passwortkodierung . . . . . . . . . . . . . . . . . . . . . . .
23
5. SAMBA
25
5.1. SMB-Protokoll . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
25
5.1.1. NetBIOS
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
25
5.1.2. WINS-Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
27
5.2. Benutzerverwaltung
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
27
5.2.1. Mögliche Einsatzszenarien für Benutzerverwaltung . . . . . . . . . . . . . . . .
28
5.3. Sicherheitsmodelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
28
5.3.1. share-Modus
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
28
5.3.2. user-Modus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
28
5.3.3. server-Modus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
29
5.4. LDAP-Unterstützung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
29
5.5. SAMBA und Dateifreigaben . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
29
5.6. SAMBA und Druckerfreigaben
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
29
5.6.1. CUPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
29
5.7. ACLs
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
30
5.7.1. Kernel-Patch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
30
5.7.2. Dateisysteme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
30
5.7.3. Samba und ACLs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
30
5.8. Samba 3.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
31
5.8.1. Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
31
6. Praxis
32
6.1. Arbeisplan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
32
6.2. SuSE 9.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
33
6.2.1. Yast . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
33
6.2.2. apt-get . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
33
6.2.3. Checkconfig . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
34
6.3. Einrichtung des LDAP-Servers
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
35
6.3.1. LDAP-Server installieren
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
35
6.3.2. SSL-Verschlüsselung, das Erstellen von Zertifikaten . . . . . . . . . . . . . . . .
35
6.3.3. Konfiguration des LDAP-Servers . . . . . . . . . . . . . . . . . . . . . . . . . .
37
6.4. Hilfsprogramme und Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
39
6.4.1. smbldap-tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
39
6.4.2. Perl-Bibliotheken . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
41
6.5. smbldap-tools benutzen
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
43
6.6. mkntpwd
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
48
6.7. Einrichtung des Samba-Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
48
6.7.1. Samba kompilieren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
48
6.8. Linux/Unix Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
50
6.8.1. Automatische Einrichtung mit Yast unter SuSE Linux 9.0 . . . . . . . . . . . .
50

Inhaltsverzeichnis
4
6.8.2. nsswitch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
53
6.8.3. pam-Schnittstelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
55
6.8.4. NFS-Server-Einrichtung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
55
6.9. Windows Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
56
6.9.1. Registry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
56
6.9.2. Automatisches Anmelden von Arbeitsstationen . . . . . . . . . . . . . . . . . .
56
7. Diskussion
60
7.1. Produktiver Einsatz
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
60
7.1.1. Passwortänderung
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
60
7.1.2. Profiles
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
61
7.2. Zusammenfassung und Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
61
7.2.1. Samba als PDC-Killer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
61
7.3. Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
62
A. Quellen aus dem Internet
65
B. Softwareverzeichniss
66
C. Dateilistings
67
C.1. smbldap.conf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
67
C.2. smbldapbind.conf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
71
C.3. /etc/nsswitch.conf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
71
C.4. /etc/ldap.conf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
72
C.5. smb.conf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
73

1. Einleitung
1.1. Beschreibung der Thematik
In grossen Firmen und Institutionen müssen Tausende Arbeitsstationen mit Zehntausenden Benutzer-
konten verwaltet werden. Es werden verschiedene Betriebsysteme eingesetzt, oft müssen die Benutzer
sich an beliebigen Rechnern anmelden können (z.B. in Universitäten). Hier entsteht das Problem ef-
fektiver Benutzerverwaltung. Im Idealfall müssen alle Benutzerkonten zentral verwaltet werden, was
bei heterogenen Umgebungen sich immer noch als schwierig erweist. Windows-Systeme haben eigene
Besonderheiten, die sich mit Solaris- bzw. Linuxsystemen nur schwer koppeln lassen. Es wird noch
zusätzlich dadurch erschwert, dass mehrere Ansätze für Benutzerverwaltung existieren, die zueinan-
der nicht kompatibel sind. Grundsätzlich haben sich 3 Systeme für zentralisierte Benutzerverwaltung
durchgesetzt:
· Microsoft Active Directory (als Nachfolger von Domain-Konzept)
· NIS, NIS+
· Novells NDS und eDirectory
Die ersten zwei verkörpern zwei unterschiedliche Welten im Desktop- bzw. Serverbereich, nämlich
Windows- und Unixwelt. Die Techniken, die von diesen Systemen für zentralisierte Benutzerverwal-
tung eingesetzt werden, sind zueinander nicht kompatibel. Sie lassen sich gemeinsam mit einem einzigen
Datenbestand nicht verwenden. Die Lösung von Microsoft funktioniert nur mit Microsoft-Produkten
(Windows 95/98/ME/2000/XP/2003). Im Gegensatz dazu wurde NIS aber für viele Unix-ähnliche
Systeme implementiert. Novell dagegen hat schon immer plattformübergreifende Lösungen entworfen.
Zum größten Teil setzte man Novells NetWare ein, um zentralisierte Benutzerverwaltung in einem
Netzwerk bestehend aus DOS/Windows 3.11/Windows95/Windows98 Systemen zu realisieren. Später
wurde auch Clientsoftware für andere Betriebsysteme (nicht aus dem Hause Microsoft) entwickelt (z.B.
MacOS, Linux). Für den Einsatz in anspruchsvollen heterogenen Umgebungen hat Novell später eDi-
rectory entworfen. Mit eDirectory versucht Novell-, Microsoft- und Unixwelt unter ein Dach zu bringen.
Dabei setzt Novell auf transparente Technologien. Es wird ein LDAP-Server für zentralisierte Benut-
zerverwaltung in heterogenen Netzwerken verwendet. eDirectory verfügt über offene Schnittstellen zum
SOAP, XML und viele anderen Standards.
1.2. Zielsetzung der Arbeit
Ziel dieser Diplomarbeit ist eine zentralisierte Benutzerverwaltung in heterogenen Netzwerken mit Hilfe
von Open Source Lösungen zu realisieren und zu dokumentieren. Es wird openldap als Benutzerdaten-
bank für beide großen Betriebsystemfamilien (Windows und Linux) verwendet. Die Kommunikation

1 Einleitung
6
zwischen Linux-System und Openldap erfolgt direkt über pam-Modul (pam_ldap) und nsswitsch. Die
Windows-Systeme müssen den Umweg über Samba nehmen (Windows besitzt keine eingebaute Un-
terstützung für die LDAP-Authentifizierung). Diese Diplomarbeit ist nicht als eine Versuchsstudie zu
betrachten, da über einen erfolgreichen Einsatz von openldap und Samba in heterogenen Netzwerken
im Internet bereits berichtet wird. Die Einrichtung von openldap und Samba für zentralisierte Benut-
zerverwaltung erscheint immer noch als äußerst schwierig und zeitaufwendig. Mit dieser Diplomarbeit
soll der Umstieg auf Open-Source Lösungen für die zentralisierte Benutzerverwaltung erleichtert wer-
den.
Bild 1.1.: Zentralisierte Benutzerverwaltung
In der Abbildung 1.1 sieht man, wie die Benutzer zentralisiert in einer LDAP-Datenbank gespeichert
werden. Verschiedene Betriebsysteme können auf diese Art und Weise die Benutzerinformationen wie
Login, Passwort etc. teilen. Es entsteht keine Redundanz. Das Netzwerk bleibt übersichtlich und er-
weiterungsfähig. Es können verschiedenste LDAP-fähige Applikationen verwendet werden, um z.B.
Email-Verzeichnisse oder Adressbücher zu generieren oder man verwendet gleiche Login-Daten um
LDAP-fähige Content-Management-Systeme einzubinden.
1.3. Software
Das Betriebsystem SuSE 9.0 wird als Server- und auch als Clientbetriebsystem verwendet. Der openldap
wird als LDAP-Server eingesetzt.(Standard-rpm von SuSE-CD) Die Software Samba muss neu kompi-

1 Einleitung
7
liert werden, weil die Standardversion keine LDAP-Unterstützung zur Verfügung stellt. LDAP-Server
und Samba sind zwei zentrale Bestandteile unserer Umgebung. Es werden aber zusätzlich Hilfspro-
gramme wie smbldap-tools oder Webmin verwendet.
1.4. Beschreibung der Testumgebung
1.4.1. Testumgebung I - Labor
Als erste Testumgebung dienen Arbeitsrechner im Datenbanklabor, die mit wechselbaren Festplatten
ausgestattet sind. Es sind Dual Xeons mit 1GB Arbeitsspeicher und Gigabit Netzwerkkarten von 3Com.
Die Rechner sind über eine Netzwerkschnittstelle mit dem Internet verbunden. Die IP-Adresse wird
per DHCP beim Neustart zugewiesen. Die IP-Adressen und Rechnernamen werden von dem DHCP-
Server anhand der MAC-Adresse verteilt. Dadurch bekommen die Rechner immer gleiche IP-Adresse
und Name zugewiesen. Folgende Betriebsysteme wurden eingesetzt:
· 3 x Suse Linux 9.1 Professional (LDAP-Server, SAMBA-Server, Testclient)
· 1 x Windows 2000 (Testclient)
· 1 x Windows XP (Testclient)
Wie aus der Abbildung ersichtlich ist, laufen LDAP und Samba auf unterschiedlichen Maschinen. Um
eine sichere Verbindung zwischen beiden Systemen garantieren zu können, wird SSL verwendet.
Bild 1.2.: Testumgebung 1

1 Einleitung
8
1.4.2. Testumgebung II - VMWare
Als zweite Testumgebung dient ein persönliche PC mit 768MB Speicher, der mit VMWare GSX Server
2.5 ausgestattet ist. Durch Einsatz von VMWare GSX wird ermöglicht, mehrere Betriebsysteme auf
einem Rechner gleichzeitig zu betreiben. Es wurden folgende Betriebsysteme beim Testen eingesetzt:
· Windows 2000 Professional (Wirtsystem für VMWare und Testclient gleichzeitig)
· SuSE Linux 9.0 (LDAP und SAMBA Server)
· Windows XP Professional (Testclient)
· Windows 2003 Advanced Server (Testclient)
In dieser Testumgebung kann die Kommunikation zwischen LDAP-Server und SAMBA ohne Ver-
schlüsselung erfolgen, weil die Server auf gleicher Maschine laufen und keine empfindliche Daten über
das Netzwerk unverschlüsselt verschickt werden müssen.
Bild 1.3.: Testumgebung 2

2. Benutzerverwaltung
Das Ziel der Diplomarbeit ist, verschiedene Betriebsysteme für die zentralisierte Benutzerverwaltung
mittels LDAP einzurichten un alle Vorgänge zu dokumentieren. Zuerst muss aber die Frage geklärt
werden, wie die lokale Benutzerverwaltung bei diesen Betriebsystemen organisiert ist. Wenn zum Bei-
spiel bei Unix das Mehrbenutzerkonzept schon von Anfang an in das Betriebsystem integriert war,
wurde es bei Windows mehr oder weniger nachgerüstet.
2.1. Benutzerverwaltung unter Windows
2.1.1. Workstation
Dateisystem
Benutzerverwaltung war für Windows 3.11 noch ein Fremdwort. Das System wurde nicht für mehrere
Benutzer konzipiert. Mit Windows 95 hat Microsoft das Mehrbenutzerkonzept eingeführt. Die Kompa-
tibilität mit älterer Windows-Version lies aber keine großen Kompromisse zu. Die größte Hürde war hier
das Dateisystem FAT16, das keine Zugriffsrechte für Dateien vorsah. Mit der Einführung von FAT32
wurde das Konzept auch nicht verbessert. Es konnte immer noch keine "richtige" Benutzertrennung
hergestellt werden. Ein Benutzer konnte die Dateien von den anderen ansehen, ändern oder löschen.
FAT32 unterstützte die korrekten Dateirechte immer noch nicht. Es blieb bei der Loginmaske, die man
mit ESC-Taste umgehen konnte und volle Administrator-Rechte auf dem Rechner hatte. Es war nur
möglich die Desktop-Einstellungen und die Einstellungen für einige Programmpakete für verschiedene
Benutzer getrennt zu speichern und beim Einloggen zur Verfügung zu stellen. In neueren Versionen
von Windows (Windows 98, Windows ME) gab es diesbezüglich keine gravierende Veränderungen.
Erst mit der Entwicklung von NTFS wurde es ermöglicht, eine "echte" Trennung zwischen Benutzern
zu schaffen. NTFS unterstützt alle Dateiberechtigungen, die man aus Unix-Welt auch kennt, und ist
in manchen Disziplinen sogar deutlich überlegen. NTFS blieb zuerst Serverdateisystem und wurde
nur mit NT-Serversystemen ausgeliefert. Später wurde es auch in die Clientbetriebsysteme wie Win-
dows 2000/XP integriert. Für Windows 95/98/ME gibt es immer noch keine NTFS-Unterstützung. Im
Praxisteil wurde deswegen gezielt auf die älteren Windowsversionen verzichtet, weil diese Versionen
nur halbherzige Lösungen bezüglich der Benutzerverwaltung anbieten.
Benutzerdaten
Bei der Anmeldung unterscheidet Windows zwischen einer lokalen Anmeldung und einer Netzwerkan-
meldung. In diesem Abschnitt wird die lokale Anmeldung beschrieben. Die Netzwerkanmeldung wird
unter Primary Domain Controller und Active Directory Server beschrieben. Die Benutzerdaten werden
bei Windows binär gespeichert. Die Passwörter werden dabei mit der Hilfe einer One-Way-Funktion

2 Benutzerverwaltung
10
kodiert. Bei der Anmeldung kodiert Windows das eingegebene Passwort und vergleicht es mit dem
gespeicherten Wert. Stimmen die beiden überein, ist die Anmeldung erfolgreich. Diese Art von Ko-
dierung liefert bei der Entschlüsselung keine eindeutige Werte, so ist es unmöglich, das Passwort zu
entschlüsseln. Die Passwort-Dateien haben unter Windows die Dateiendung .PWL. Es werden für
unterschiedliche Zwecke und Benutzer unterschiedliche Dateien angelegt (extra Passwortdateien für
DFÜ-Netzwerk, Freigaben).
2.1.2. Primary Domain Controller
Für Einsatz in großen Netzwerken wurde "Primary Domain Controller"-Konzept entworfen und zum
ersten Mal mit Windows NT eingeführt. Eine Domäne ist wie ein Zusammenschluss aus vielen ver-
schiedenen Ressourcen (z.B. PCs, Drucker). Diese Ressourcen teilen sich eine gemeinsame Authen-
tifizierungsdatenbank. Da die Verwaltung zentral aufgebaut ist, melden sich alle Benutzer an einem
einzigen Server (Domain Controller) an. Alle Änderungen werden an einer einzigen zentralen Stelle
durchgeführt und treten so spätestens bei nächster Anmeldung in Kraft. Ein Benutzer kann zwei oder
mehreren Domänen angehören und kann bei der Netzwerkanmeldung die Domäne frei wählen. Für
die Verteilung von Informationen steht hier NTDS - Windows NT Directory Service zur Verfügung.
Microsoft kündigte schon zu NT-Zeiten das NTDS als vielseitigen Verzechnisdienst an. NTDS verfügt
tatsächlich über einige Merkmale von modernen Verzeichnisdiensten (z.B. Replizierung, Benutzerver-
waltung, Workstationverwaltung). Die Funktionalitäten von NTDS reichen aber nicht aus, um einen
ausgereiften Verzeichnisdienst zu bilden.
2.1.3. Active Directory Server
Mit der Einführung von ADS (Active Directory Server) reagierte Microsoft auf die gestiegenen Anforde-
rungen und das breitere Anwendungsspektrum von Verzeichnisdiensten, die auf dem Markt herrschen.
Microsoft's Active Directory ist der Nachfolger von Windows NT Directory Service. Active Directory
unterstützt im Gegensatz zum NTDS die Abbildung von im Netzwerk angebotenen Diensten und An-
wendungen. Active Directory wurde zu ersten Mal mit Microsoft Windows 2000 Server ausgeliefert. Bei
der Entwicklung lehnte sich Microsoft stark an X.500 - Standard an. Wie es oft bei Microsoft üblich ist,
wurde an einigen Stellen vom Standard abgewichen. So ist z.B. die Replizierung von Active Directory
anders als bei X.500 implementiert. Der Objektbaum in Active Directory weist viele Erweiterungen
und Änderungen auf. Es ist möglich die Software-Konfiguration direkt auf dem ADS zu hinterlegen.
Obwohl von vielen Herstellern eine breite Unterstützung für Active Directory angekündigt war, blieb
diese größtenteils aus. Das einzige Produkt, das vollständig in Active Directory Umgebung integriert
war, war nur der Microsoft Exchange Server 2000. Hier sind die wichtigsten Merkmale von Active
Directory Server aufgelistet:
· Domänen-Konzept
· Access Control Lists
· Unterstützung für Netzwerkdienste und Applikationen
· PDC-Emulator (Rückwärtskompatibilität)

2 Benutzerverwaltung
11
2.2. Benutzerverwaltung unter Unix
Unix wurde ursprünglich als Serverbetriebsystem entwickelt. Die Benutzerinformationen werden bei
unixähnlichen Systemen in den Dateien /etc/passwd und /etc/group abgelegt.
2.2.1. shadow-System
Das Abspeichern von unverschlüsselten Passwörtern in einfachen Textdateien ist ein Sicherheitsrisiko.
Der Einsatz von Verschlüsselungsverfahren erhöht den Datenschutz und wird heutzutage bei den meis-
ten unixähnlichen Systemen verwendet. Shadow-Password-System wird bei allen Linux-Systemen be-
nutzt. Das Abspeichern von Benutzer- bzw. Gruppeninformationen wird in gewöhnlichen Text-Dateien
durchgeführt. Die Passwörter werden aber in besonderer Datei (/etc/shadow) in verschlüsselter Form
abgelegt. Die Datei /etc/shadow enthält nicht nur Name und Kennwort des Benutzers, sondern auch
weitere Informationen wie:
· Der Benutzername
· Das verschlüsselte Kennwort.
· Die Anzahl von Tagen zwischen dem 01.01.1970 und der letzten Kennwortänderung.
· Die Zeit in Tagen, die zwischen zwei Kennwortänderungen liegen muß.
· Die Zeit in Tagen, wie lange ein Kennwort gültig ist.
· Die Zeit in Tagen, wie lange der Benutzer vor dem Auslaufen des Kennworts gewarnt wird.
· Die Zeit in Tagen, bis das Konto nach dem Auslaufen der Anforderung der Kennwortänderung
gesperrt wird.
· Ablaufen des Kontos in Tagen seit dem 01.01.1970.
Die Gruppenkennwörter werden in /etc/gshadow abgelegt, dadurch werden die Gruppenkennwör-
ter auch in verschlüsselter Form sicher aufbewahrt. Die Kennwortfelder in den /etc/group und
/etc/passwd werden dabei mit "x" ausgefüllt. Beide Dateien (/etc/shadow und /etc/gshadow) sol-
len auf keinen Fall manuell editiert werden. Für die Änderungen an den Benutzerprofilen sollen dafür
vorgesehene Werkzeuge eingesetzt werden.
Werkzeuge für Benutzerverwaltung
Hier werden in Kürze einige Wekzeuge für Benuzerverwaltung beschrieben:
· passwd - ändert das Benutzerpasswort
· useradd - fügt einen Benutzer hinzu
· userdel - löscht einen Benutzer
· usermod - modifiziert einen Benutzer

2 Benutzerverwaltung
12
· newgrp - erstellt eine neue Gruppe
· groupmod - modifiziert eine Gruppe
· groupdel - löscht eine Gruppe
· pwconv - erzeugt /etc/shadow Datei aus /usr/passwd
· grpconv - erzeugt /etc/gshadow Datei aus /usr/group
· grpck - prüft Integrität der group-Dateien
· pwunconv - deaktivier das Shadow-Password System
Natürlich handelt es sich um eine lokale Benutzerverwaltung. Der Einsatz von Dateien für das Abspei-
chern von Passwörtern macht eine effektive Benutzerverwaltung in Netzwerkumgebungen sehr schwer,
der Verwaltungsaufwand ist hier nicht vertretbar.
2.2.2. NIS
Bei einer großen Anzahl von Benutzern müssen viele Accounts auf einzelnen Rechnern sehr aufwendig
verwaltet werden. Aus diesem Grund hat Sun-Microsystems NIS (Network Information Service) ent-
wickelt. Mit NIS kann man die Benuzerinformationen zentral verwalten. NIS hieß früher Yellow Pages
(YP), wurde aber wegen Auseinandersetzungen mit Britisch Telekom in NIS umbenannt. NIS ist ein
Informationssystem, das aus einer Datenbank und Service-Daemonen besteht. In der NIS-Datenbank
können die Informationen wie Benutzerkonten, Gruppenkonten sowie die Informationen zu einzelnen
Rechnern gespeichert werden. Auf den Clients läuft NIS-Clientsoftware. Die Anmeldungsanfragen an
das lokale System werden dabei mit Hilfe dieser Software an NIS Server umgeleitet. Dadurch wird zum
Beispiel das Passwort, das von einem Benutzer gerade geändert wurde, für alle anderen Clients sofort
sichtbar. NIS ist aber nicht für eine große Benutzerzahl ausgelegt (>5000), deshalb existiert bereits
eine Weiterentwicklung von NIS - nämlich NIS+.
2.2.3. NIS+
NIS+ kann in großen (bis zu 10.000 Rechner) Client-Server Netzwerken eingesetzt werden. Bei der
Weiterentwicklug hat man großen Wert auf die Skalierbarkeit gelegt. NIS+ ist im Gegensatz zu sei-
nem Vorgänger NIS viel sicherer. Gleichzeitiger Einsatz von NIS und NIS+ kompatiblen Systemen
ist möglich. NIS+ speichert alle Konteninformationen in einer Datenbank, genauso wie sein Vorgän-
ger NIS. Der NIS-Daemon beantwortet die Anfragen anhand von Zugriffsrechten einzelner Benutzer.
Als eine Datenbank dienen einfache Text-Dateien, die beim Einrichten des NIS+ Servers angelegt
werden.(nissetup) Folgende Befehle sind beim Einrichten und Betreiben des NIS+ Server wichtig:
· nisaddcred - Erzeugt die Kennungen für NIS-Administratoren
· nisaddent - fügt Informationen aus den /etc-Dateien in die NIS-Tabellen
· niscachemgr - NIS+ Cachemanager. Muss auf dem NIS+ Client gestartet sein
· niscat - zeigt den Inhalt von NIS-Tabellen

2 Benutzerverwaltung
13
· nischgr - ändert den Gruppeneigentümer eines Objektes
· nischmod - wie chmod, aber für NIS
· nischown - wie chown, aber für NIS
· nischttl - liefert Verfallsdatum eines NIS-Objekts
· nisdefaults - liefert die Standard-Werte eines NIS-Objektes wie:
­ Domain Name
­ Gruppenname
­ Rechnername
­ NIS+ Principal Name
­ Zugriffsberechtigungen
­ Verfallsdatum
· nisgrep - sucht in einer Tabelle nach den Einträgen
· nisgrpadm - Anzeigen, Erzeugen, Ändern und Löschen einer Gruppe
· nisinit - initialisiert ein NIS-Server oder Client
· nisln - erzeugt symbolische Verbindung zwischen zwei NIS-Objekten (ähnlich ln)
· nisls - zeigt Inhalt eines NIS-Verzeichnisses
· nismatch - durchsucht Tabellen nach den Einträgen
· nismkdir - erzeugt ein Verzeichnis
· nismkuser - erzeugt einen Benutzer
· nispasswd - ändert NIS-Passwort
· nisrm - löscht ein NIS-Objekt
· nisrmdir - löscht ein NIS-Verzeichnis
· nisrmuser - löscht einen NIS-Benutzer
· nissetup - erzeugt NIS-Dateistruktur
· nisshowcache - zeigt den Cacheinhalt an
· nistbladm - erzeugt und löscht NIS-Tabellen
· nisupdkey - aktualisiert öffentliche Schlüssel von einem NIS+ Objekt
Aus dieser Liste wird deutlich, dass NIS+ sehr stark an Unix-Benutzerverwaltungssystem angelehnt
ist. Der gemeinsame Einsatz mit Windows-Systemen ist hier ausgeschlossen. NIS und NIS+ können
jedoch verschiedene Betriebsysteme, wie Linux, Solaris, FreeBSD zusammenbringen und sind so für
heterogene Umgebungen mit Ausschluss von Windows durchaus nutzbar.

2 Benutzerverwaltung
14
2.3. Benutzerverwaltung unter Novell
2.3.1. NDS
Novells NetWare Directory Service (NDS) ähnelt NIS. Die Benutzer werden bei Novell an einer zentra-
ler Stelle administriert. NDS unterstützt Gruppen, es sind aber eher Klassen. Die Eigenschaften werden
nach unten "vererbt", so ist es möglich, mehrere verschachtelte Profile zu benutzen. Dies ermöglicht, die
Benutzerverwaltung bei Novells NDS flexibler zu gestalten. Man spricht auch an dieser Stelle von Con-
tainern (übergeordnete Klassen) und Objekten (z.B. Benutzer). Die Objektdatenbank besitzt dement-
sprechend hierarchische Struktur (NDS-Tree). Für jeden Benutzer in der NDS-Datenbank wird festge-
legt, welche Rechte er für andere Objekte in der NDS-Datenbank besitzt. In der Novell-Terminologie ist
man "Trust" des entsprechenden Objekts, wenn man die Rechte für dieses Objekt besitzt. Objekte be-
sitzen unterschiedliche Eigenschaften. Jede Eigenschaft, die zur Charakterisierung eines Objekts dient,
ist mit einem bestimmten Wert verbunden. Novells NetWare übernimmt die Verwaltung des Netzwer-
kes. Die Clients greifen auf die von NetWare aufgebaute Struktur mittels Clientsoftware zu. Es existiert
Clientsoftware für Betriebsysteme wie DOS, Windows, OS2, Mac. Unix-basierte Systeme mussten bis-
her auf die NDS-Umgebung verzichten, es existierte keine Portierung für Linux oder FreeBSD. Seit
kurzem existiert SourceForge-Projekt namens novelclient, welcher NetWare Unterstützung für Linux
verspricht.
2.3.2. eDirectory
Im Jahr 1994 hat Novell eDirectory auf den Markt gebracht. Bei eDirectory handelt es sich um einen
LDAP-basierten Verzeichnisdienst . Es existiert Clientsoftware für Linux, Solaris, Windows, AIX. Die
LDAP-Kompatibilität lässt die Zugriffe von verschiedenen externen Umgebungen und Tools zu (wie
z.B. von Netscape ). Die Vorteile von eDirectory sind:
· offene Architektur
· bessere Erweiterbarkeit
· Ankopplung an existierende Systeme
· bessere Anpassungsfähigkeit
· bessere Netzwerkintegration
Alle diese Vorteile von eDirectory gegenüber NDS sind durch Einsatz von offenen Architekturen ent-
standen. Novell benutzt von Open LDAP Group zertifizierte LDAP-Umgebung (LDAP v3). Es werden
außerdem XML, SOAP, DSML und viele andere offene Standards unterstützt. Durch diese breite
Unterstützung bietet eDirectory vielseitige Möglichkeiten den Verzeichnisdienst optimal auszunutzen.
eDirectory ist ist für den Einsatz in heterogenen Umgebungen und großen Netzwerken ausgelegt. Laut
Novell unterstützt eDirectory bis 1.000.000.000 Identitäten (Objekten). Unix-Systeme können sich mit
Hilfe von pam ohne zusätzliche Software über LDAP auf dem eDirectory Server anmelden.
Wie man in der Abbildung 2.1 sieht, besitzt e-Directory die Möglichkeit für XML-Export und lässt
sich so mit mächtigen Software-Paketen wie SAP oder Lotus koppeln. Da XML-Standard inzwischen

2 Benutzerverwaltung
15
Bild 2.1.: e-Directory (Novell's e-Directory Info-Flyer)
sehr verbreitet ist, kann die Liste von eventuellen Einsatzmöglichkeiten und Erweiterungen sehr lang
werden. In späteren Kapiteln wird es deutlich, dass dieses Modell (allerdings ohne XML-Export) mit
Open-Source Software realisiert werden kann.
2.4. Wichtige Anforderungen an die zentralisierte Benutzerverwaltung
in heterogenen Netzwerkumgebungen
Für heterogene Umgebungen waren die systemübergreifenden Lösungen lange Zeit nicht in Sicht. Der
Einsatz von Windows und Unix war nur mit einer einzigen Benutzerdatenbank nicht möglich gewesen.
Dies war auf nicht kompatible Benutzerverwaltung von beiden großen Betriebsystemfamilien zurück-
zuführen. Außerdem waren die Ansätze sehr unterschiedlich. Unixwelt konnte mit NIS+ auskommen,
Windows forderte dagegen die vollständige NETBIOS- und SMB-Unterstützung. Die Benutzerverwal-
tung für heterogenen Umgebungen muss ausserdem gewisse Anforderungen erfüllen:
1. Alle Benutzerkennungen sind in einer einziger Datenbank gespeichert
2. Passwortkonsistenz muss gewährleistet werden (keine doppelte Passwortvergabe)
3. ein einziges Heimat- bzw. Benutzerverzeichnis für beide Betriebsystemfamilien
4. Transparenz und Erweiterbarkeit
5. Möglichkeit für den Einsatz mit existierenden Systemen ohne tiefe Eingriffe in das Client-
Betriebsystem

2 Benutzerverwaltung
16
2.4.1. Punkt 1 - keine redundant gespeicherte Benutzerdaten
Dies kann mit verschiedenen Mitteln erreicht werden. Technische Möglichkeiten lassen es zu, beliebige
Datenbanken zu verwenden. Es bleibt aber die Frage der Anbindung, die Clients müssen schließlich auf
diese Datenbanken zugreifen können. Von der Unix-Seite gibt es hier keine großen Einschränkungen.
Die glibc-Bibliotheken sind so konzipiert, dass man mit einigen wenigen zusätzlichen Modulen und
Einstellungen alle Authentifizierungsanfragen an eine Datenbank oder X.500 Server umleiten kann.
Schwieriger wird es bei Windows, weil es dort keine Möglichkeit gibt, auf externe Benutzerdatenbanken
(außer NTDS oder AS) zuzugreifen. Dies kann aber vernachlässigt werden, weil es für Windows sowieso
NETBIOS- und SMB-Protokoll nachgebildet werden müssen. Punkt 1. erfordert beim Einsatz von
Windows-Betriebsystemen die Nachbildung des SMB-Protokolls.
2.4.2. Punkt 2 - keine Inkonsistenzen
Punkt 2 ist eigentlich ganz einfach zu erfüllen. Es muss nur ein einziges Benutzerkonto für beide Betrieb-
systeme existieren. Wir werden sehen, dass man hier trotzdem zwei Felder für Passwörter verwenden
muss.
2.4.3. Punkt 3 - ein einziges Heimatverzeichnis
Hier wird ebenfalls die SMB-Nachbildung erforderlich, um z.B. Verzeichnisse anzubinden oder freizu-
geben. Verzeichisse unter /home können so als Netzwerklaufwerke unter Windows angebunden werden.
2.4.4. Punkt 4 - offene und verbreitete Technologien
Hier gilt das Prinzip "auf richtige Technologien" zu setzen, damit das System in der Zukunft erweiterbar
bleibt. Der Einsatz von relationalen Datenbanken ist hier möglich, aber nicht erwünscht, weil wir hier
mehr mit Objekten als mit Relationen zu tun haben. X.500 oder LDAP sind an dieser Stelle durchaus
einsetzbar. X.500 und LDAP unterstützen die baumförmigen Strukturen und sind sehr flexibel.
2.4.5. Punkt 5 - Verwendbarkeit
Dieser Punkt setzt ebenfalls eine SMB-Nachbildung für die Unix-Welt voraus, da Linux-Server und
Windows-Clients miteinander kommunizieren sollen.
2.4.6. LDAP und SAMBA
Diese Überlegungen zeigen, dass wir ohne SMB-Implementierung für Unix/Linux keine heterogene
Benutzerverwaltung schaffen können. Für Unix existiert zur Zeit nur das SAMBA-Projekt und wird
bereits seit mehr als 10 Jahren weiterentwickelt. Als Datenbank kommt hier auch nur LDAP in Fra-
ge. Schließlich wurde LDAP genau dafür entwickelt
1
und ist inzwischen weit verbreitet. LDAP lässt
1
LDAP entstand als "abgespeckte" Version von X.500. Das X.500-Protokoll wollte man erst als globales Benutzer-
verzeichnis einführen

2 Benutzerverwaltung
17
sich leicht mit Unix-Systemen koppeln (pam_ldap), für Windows-Umgebung muss Samba die LDAP-
Fähigkeit zur Verfügung stellen (ist ab Version 2.0.x der Fall)

Details

Seiten
Erscheinungsform
Originalausgabe
Jahr
2004
ISBN (eBook)
9783832481568
ISBN (Paperback)
9783838681566
DOI
10.3239/9783832481568
Dateigröße
2.9 MB
Sprache
Deutsch
Institution / Hochschule
Hochschule Fulda – angewandte Informatik
Erscheinungsdatum
2004 (Juli)
Note
2,0
Schlagworte
netzwerk linux windows administration server
Zurück

Titel: Zentrale Benutzerverwaltung für heterogene Netzwerkumgebungen mit LDAP und Samba
book preview page numper 1
book preview page numper 2
book preview page numper 3
book preview page numper 4
book preview page numper 5
book preview page numper 6
book preview page numper 7
book preview page numper 8
book preview page numper 9
book preview page numper 10
book preview page numper 11
book preview page numper 12
book preview page numper 13
book preview page numper 14
book preview page numper 15
book preview page numper 16
book preview page numper 17
book preview page numper 18
82 Seiten
Cookie-Einstellungen