Einen Account unter Linux, Windows und anderen Plattformen nutzen: Mit LDAP als Basis sowie NSS, PAM und Samba als Helfer gelingt die zentrale Benutzerverwaltung.

Zentrale Benutzerverwaltung – das klingt trocken und bürokratisch, ist aber sehr praktisch: Der Admin verwaltet seine User zentral an einer Stelle und trägt dort alle Daten samt Telefonnummer und E-Mail-Adresse ein. Der Benutzer kann seinen Account auf allen Plattformen nutzen und im LDAP-Verzeichnis nach Telefonnummern suchen.[1]

Ohne Zentralisierung wird die Benutzerverwaltung in großen Netzen mit vielen unterschiedlichen Plattformen zum Problem. Die Admins müssen Accounts und Passwörter an vielen verschiedenen Stellen pflegen – eine lästige und monotone Tätigkeit. Auch für den User ist es lästig, sich für verschiedene Server und Services unterschiedlich zu anzumelden. Das regelmäßige Ändern der Passwörter bleibt dabei ebenso auf der Strecke wie deren Qualität. Stattdessen sind Zettel neben dem Bildschirm zu finden, die Geheimnisse sind einfach zu erraten.

Abhilfe schafft eine Benutzerdatenbank, mit der die User ihren Account auf allen Systemen verwenden können, unabhängig davon, ob es Linux, ein anderes Unix oder ein Windows-PC ist. Für diese Zentralisierung kommt unter Linux und bei vielen Unix-Systemen derzeit am häufigsten NIS (Network Information Service) zum Einsatz. Im Hintergrund sorgen der Name Service Switch (NSS) und die Pluggable Authentication Modules (PAM) dafür, dass die authentifizierenden Programme auf die richtige Benutzerdatenbank zugreifen (siehe Kasten “NSS und PAM”).

Samba und LDAP ersetzen das Active Directory

Unter Windows übernimmt der Primary Domain Controller (PDC) die zentrale Benutzerverwaltung. Wer bisher die Authentifizierung zwischen Unix und Windows vereinheitlichen wollte ohne sich dabei in die Abhängigkeit von einem Microsoft-Produkt zu bringen, war auf wackelige Kompromisslösungen oder teure Produkte von anderen Herstellern angewiesen. Die moderne Alternative ist ein (Open-)LDAP-Verzeichnisdienst.

Ein LDAP-Server hat im Vergleich zu NIS klare Vorteile, er ist sicherer, flexibler und besser strukturiert. Die Umstellung von NIS auf LDAP lässt sich technisch einfach realisieren: Ein PAM-Modul bezieht die typischen Datensätze von »/etc /passwd« und »/etc/group« nun aus den Objekten im Verzeichnisserver.

Obwohl Microsoft die Methoden und Protokolle von LDAP für seinen Active Directory Server nutzt, lässt sich die Windows-Welt nicht so einfach an einen Server aus der Unix-Welt anbinden. Als Brückenglied dient hier der Samba-Server, der in seiner aktuellen Version 2.2.3a als PDC für die Windows-Seite arbeitet und die Benutzerdaten andererseits in einem LDAP-Server verwalten kann (siehe Abbildung 1).

Diese Funktionalität ist in Samba zwar nicht neu, sie wird in der Praxis jedoch eher selten genutzt. Der Schritt in diese Art der Benutzerverwaltung ist aber nicht schwer. Die folgende Beschreibung zeigt, wie ein Samba-Sign-On-Server eingerichtet wird.

Samba Sign On in der Praxis

Als Beispiel dient ein Labornetzwerk »labnet« mit einem Linux-Server »lxserver.labnet« und einem Windows-2000-Client »w2kclient.labnet«. Die genaue Linux-Distribution spielt keine Rolle, sie muss nur aktuell sein. Windows 2000 wurde mit Service Pack 2 installiert.

Die LDAP-Anbindung des Linux-Servers klappt mit »nss_ldap-183« und »pam_ ldap-137« von PADL Software[2] sowie »openldap-2.0.21«[3] und »samba-2.2.3a«[4]. Als LDAP-Browser dient »gq-0.4.0«[5]. Bei Samba ist die aktuelle Version entscheidend, bei den anderen spielt die Versionsnummer keine große Rolle.

OpenLDAP, »nss_ldap« und »pam_ldap« unterstützen als Sicherungsschicht SSL (Secure Sockets Layer) und SASL (Simple Authentication and Security Layer). Samba kennt derzeit nur SSL, das Beispiel verzichtet daher auf SASL. Wer sich für Kerberos interessiert, sollte sich mit SASL näher beschäftigen[11]. Die GSSAPI (Generic Security Services API) ermöglicht Kerberos-Authentifizierung mit SASL und damit eine sanfte Umstellung auf echtes Single Sign On.

Sollte die Software noch nicht installiert sein (oder nur eine zu alte Version), empfiehlt es sich, anhand des vom Distributor gelieferten Source-Pakets (etwa SRPM) ein neues Installationspaket zu bauen. Der Mehraufwand lohnt sich, da der Paketmanager die Kontrolle über die installierte Software behält.

Bei Samba ist eine eigene Installation auch dann nötig, wenn bereits die aktuelle Version 2.2.3a vorliegt. Diese macht nämlich ein paar kleine Fehler beim Binden an den LDAP-Server. Damit »pam_smbpass« am Ende auch so funktioniert wie hier beschrieben sind einige Patches nötig[6]. Bei »./configure« sind neben den vom Distributor oder aus eigener Überzeugung gewählten Optionen auch »–with-pam –with-pam_smbpass –with-ldapsam –with-ssl« erforderlich.

Abbildung 1: Der LDAP-Server kann Accounts für Windows- und Linux-Rechner zentral verwalten. Während Linux direkt auf die LDAP-Daten zugreifen kann, benötigt Windows einen Samba-Server als Zwischenstufe.

OpenLDAP-Server einrichten

Jetzt beginnt die eigentliche Arbeit: die Konfiguration der Services. Als Dreh- und Angelpunkt ist zuerst der OpenLDAP-Server einzurichten. Die Beispieldatei »/etc/openldap/slapd.conf« zeigt, wie die wesentlichen Einstellungen dort aussehen können (siehe Listing 1; die Datei ist auch online[7] verfügbar).

Das in der Schemaliste aufgeführte »samba.schema« stammt aus der Samba-Distribution, es liegt im Quellpaket unter »examples/LDAP/samba.schema«. Diese Datei muss in die OpenLDAP-Konfigurationsverzeichnisse kopiert werden: »/etc /openldap/schemas«.

01 # /etc/openldap/slapd.conf
02 # Siehe Manpage slapd.conf(5) und
03 # http://www.openldap.org/doc/admin/
04 
05 ### Schemadaten einbinden ###
06 
07 include /etc/openldap/schema/core.schema
08 include /etc/openldap/schema/cosine.schema
09 include /etc/openldap/schema/inetorgperson.schema
10 include /etc/openldap/schema/nis.schema
11 include /etc/openldap/schema/qmail.schema
12 include /etc/openldap/schema/samba.schema
13 
14 ### SSL-Zertifikat laden ###
15 
16 TLSCertificateFile    /etc/openldap/server.pem
17 TLSCertificateKeyFile /etc/openldap/server.pem
18 TLSCACertificateFile  /etc/openldap/server.pem
19 
20 ### Definition für die Datenbank ###
21 
22 database        ldbm
23 suffix          "dc=labnet,dc=de"
24 
25 # Der privilegierte Account darf in dieser
26 # Datenbank alles lesen und schreiben. Nicht
27 # zu verwechseln mit dem Sysuser root, der im
28 # Verzeichnis eingetragen ist und dem mit ACL
29 # seine Rechte zugewiesen werden
30 rootdn  "cn=Root,dc=labnet,dc=de"
31 rootpw  {SSHA}TVD1dvaqvtSnfyZX/7nnl26pOuteFXh3
32 
33 # Das Verzeichnis *muss* existieren, bevor slapd
34 # gestartet wird und sollte nur für slapd
35 # lesbar sein
36 directory       /var/lib/ldap
37 
38 # Index-Definition
39 index   objectClass     eq
40 
41 ### Definition der Access Control List (ACL) ###
42 
43 # Default Policy:
44 # authentifizierte User dürfen lesen
45 # und alle anderen sehen nichts.
46 access to * by dn="uid=Admin,ou=Sysusers, ou=NSS,dc=labnet,dc=de" write
47         by users read
48         by * none

01 dn: uid=root,ou=Sysusers,ou=NSS,dc=labnet,dc=de
02 objectClass: sambaAccount
03 uidNumber: 0
04 gidNumber: 0
05 uid: root
06 rid: 1000
07 primaryGroupID: 1001
08 lmPassword: 193130B61A7F81C0AAD3B435B51404EE
09 ntPassword: FA4942AF3BB92B0C5DDAA88F0C2A95A2
10 acctFlags: [U          ]
11 
12 dn: uid=Admin,ou=Sysusers,ou=NSS,dc=labnet,dc=de
13 objectClass: posixAccount
14 uid: Admin
15 cn: Admin
16 userid: Admin
17 uidNumber: 20000
18 gidNumber: 20000
19 homeDirectory: /etc/openldap
20 userPassword: {SSHA}Ub+F/ONg76DNppk94FUKp9lGz+z2U8fu
21 
22 dn: uid=W2KCLIENT$,ou=Samba,ou=NSS, dc=labnet,dc=de
23 objectClass: sambaAccount
24 objectClass: posixAccount
25 uid: W2KCLIENT$
26 uidNumber: 21001
27 gidNumber: 20002
28 homeDirectory: /tmp
29 cn: Windows 2000 Client
30 
31 dn: uid=emu,ou=Mitarbeiter,o=Demofirma, dc=labnet,dc=de
32 objectClass: posixAccount
33 objectClass: inetOrgPerson
34 objectClass: sambaAccount
35 uidNumber: 26001
36 gidNumber: 26000
37 homeDirectory: /home/emu
38 userPassword: {SSHA}MTZJJ9ldbDbYeWinQMh6u2tjr/qNnuPa
39 loginShell: /bin/bash
40 gecos: Erich Mustermann
41 mail: emu@demofirma.de
42 uid: emu
43 displayName: Erich Mustermann
44 cn: Erich Mustermann
45 description: Testuser fuer NSS/PAM/LDAP/Samba
46 rid: 5002
47 primaryGroupID: 5003
48 lmPassword: 193130B61A7F81C0AAD3B435B51404EE
49 ntPassword: FA4942AF3BB92B0C5DDAA88F0C2A95A2
50 acctFlags: [U          ]

SSL aktivieren

Um Fehlerquellen auszuschließen und das Debugging zu erleichtern, kann man während der Testphase noch auf SSL verzichten (einfach die TLS-Einträge auskommentieren). Um mit SSL zu arbeiten ist zunächst ein Zertifikat erforderlich. Das geschieht durch den Aufruf folgender Kommandozeile:

openssl req -new -x509 -nodes -days 730 
  -out server.pem -keyout server.pem

Bei den Zertifikatsfeldern ist der Common Name entscheidend. Er bezeichnet den Rechner, für den das Zertifikat bestimmt ist, und zwar mit dem vollständige Namen (FQDN), der im Reverse Lookup erscheint.

Samba kann zurzeit nur mit einfacher Authentifizierung (ohne SASL) arbeiten, daher muss die »slapd.conf« als »rootdn« einen eindeutigen Bezeichner für ein LDAP-Objekt (Distinguished Name, DN) enthalten. Der Passwort-Hash »rootpw« wird unmittelbar in der Konfigurationsdatei abgelegt. Ein korrekt kodierter String kann mit »slappasswd« erzeugt werden. Das Passwort in allen Beispielen lautet übrigens »Geheim«.

Damit der LDAP-Server Anfragen mit und ohne SSL-Verschlüsselung beantworten kann, muss er (»slapd«) mit der Kommandozeilenoption »-h “ldap://0.0.0.0:389/ ldaps://0.0.0.0:639/”« gestartet werden – der Aufruf ist in der Regel im Startskript »/etc/init.d/ldap« zu finden. Die Anführungszeichen sind für den Erfolg entscheidend, beide URLs gehören zum Parameter »-h«. Sobald der Server läuft, sollten die ersten Anfragen mit »ldapsearch« möglich sein:

ldapsearch -H ldaps://lxserver.labnet/ 
  -x -b "" -s base

Wenn alles funktioniert, liefert dieser Aufruf ein Objekt der Klasse »OpenLDAProotDSE« mit leerem Namen. Bevor er nähere Anfragen beantworten kann, benötigt der LDAP-Server Daten. Listing 2 zeigt einen Auszug aus einer funktionstüchtigen Grundausstattung.

Abbildung 2: Der LDAP-Browser GQ stellt die Struktur des LDAP-Verzeichnisses übersichtlich dar: links die Baumstruktur der LDAP-Hierarchie, rechts den Benutzer Erich Mustermann mit seinem Account »emu«. LDAP kann auch weitere Daten aufnehmen, etwa die Telefonnummer.

LDAP-Server mit Daten füllen und mit GQ anzeigen

Die Datei enthält Erich Mustermann (»emu«) mit seinem Posix- und Samba-Account. Die Felder der Passwortdatei wie »uidNumber«, »homeDirectory« und das »gecos«-Feld sind enthalten, zusätzlich zum Beispiel die E-Mail-Adresse. Die vollständige Datei »basisdaten.ldif« steht auf [7] zum Download bereit. Folgendes Kommando lädt die Daten in den Server:

ldapadd -x -f basisdaten.ldif -w Geheim 
  -D cn=Root,dc=labnet,dc=de

Damit ist der Grundstein für die zentrale Benutzerverwaltung mit LDAP gelegt. Ein LDAP-Browser hilft beim Verständnis der eben installierten Daten, er stellt die hierarchischen Daten übersichtlich in einer Baumstruktur dar.

Bei GQ[5] startet der Menüpunkt »File | Preferences« einen Dialog, der in der Karteikarte »Server« die Verbindungsdaten für den LDAP-Server entgegennimmt. Für unser Beispiel lauten die relevanten Optionen:

• Name: »lxserver«
• LDAP-Host: »lxserver.labnet«
• LDAP-Port: »389«
• Base-DN: »dc=labnet,dc=de«
• Bind-DN: »uid=Admin,ou=Sysusers,ou=NSS,dc=labnet,dc=de«
• Bind-Password: »Geheim«

Beim Laden der Basisdaten mit dem Kommando »ldapadd« kam ein anderer »rootdn« zum Einsatz (»cn=Root,dc= labnet,dc=de«) als hier bei der Konfiguration von GQ. Der Unterschied ist, dass für den normalen Bind-DN die Access Control Lists des LDAP-Servers gelten. Der Root-DN sollte für normale Anwendungen ebenso vermieden werden wie das ständige Arbeiten mit dem Root-Account unter Linux.

Mit dieser Konfiguration zeigt der Reiter »Browse« (Abbildung 2) im GQ-Hauptfenster die Struktur der Daten aus »basisdaten.ldif«. Das Bild gibt einen ersten Eindruck davon, welche Möglichkeiten LDAP bietet.

In einer einzigen Abfrage können Clients wie »pam_ldap«, Netscape oder Qmail sämtliche Objekte einer bestimmten Klasse (»posixAccount«, »inetOrgPerson« oder »qmailAccount«) aus dem kompletten Verzeichnisbaum oder nur aus einem bestimmten Ast erhalten. Der Kasten “Adressen aus dem LDAP-Server” zeigt, dass es dabei um mehr geht als nur um die Authentifikation.

Mit GQ lassen sich auch neue Benutzer anlegen, am einfachsten, indem man die Struktur eines bestehenden Users (etwa »uid=emu«) kopiert und die Felder entsprechend ausfüllt. Das Kopieren klappt über das Kontextmenü eines Eintrags: rechte Maustaste über einem User-Eintrag drücken und dann »New | use current Entry« wählen. Speziell für die Benutzerverwaltung angepasste Formulare können mit einer Skriptsprache wie zum Beispiel Perl, Python oder PHP programmiert werden.

LDAP-Accounts unter Linux nutzen

Damit Linux den neu angelegten Benutzer auch sehen kann, muss der Name Service Switch (NSS) entsprechend konfiguriert werden. Wie der Kasten “NSS und PAM” erklärt, legt die Datei »/etc/nsswitch.conf« fest, woher Linux seine Accounts kennt. Folgende Einträge sorgen dafür, dass erst die lokalen Dateien und danach LDAP zum Zuge kommen:

passwd: files ldap
shadow: files ldap
group:  files ldap

Zusätzlich sind die LDAP-Clients zu konfigurieren. Je nach Bezugsquelle des Pakets und je nach Compileroptionen erwarten »nss_ldap« und »pam_ldap« ihre Parameter in »/etc/ldap.conf« oder in »/etc /openldap/ldap.conf«.

Das Beispiel in Listing 3 zeigt eine solche Datei. Die Einträge »binddn« und »bindpw« bewirken, dass die Namensdienste dem LDAP-Server gegenüber als authentifizierte Benutzer auftreten. Dadurch können ACLs die Zugriffsrechte einschränken. Weil auch andere Clients »ldap .conf« nutzen, sollte die Datei für alle lesbar sein.

Das Resultat wird sofort sichtbar, wenn der Name Service Cache ausgeschaltet ist (»/etc/init.d/nscd stop«). Jetzt zeigt »getent passwd« neben den Einträgen aus der klassischen Passwortdatei auch die »posixAccount«-Einträge aus dem LDAP-Verzeichnis.

Um den neuen Account auch zum Einloggen zu nutzen, ist PAM anzupassen. Listing 4 zeigt, welche Änderungen dazu in »/etc/pam.d/login« nötig sind. Analog können die Authentifizierungsverfahren für alle Services in »/etc/pam .d« angepasst werden. Das PAM-LDAP-Modul bezieht das Passwort aus dem Attribut »userPassword«.

Durch einen Samba-Server können auch Windows-Clients die Accounts im LDAP-Verzeichnis nutzen. Der Samba-Server muss dazu zunächst als PDC konfiguriert sein.[8]

01 # /etc/openldap/ldap.conf
02 
03 # Wurzel für die Suchanfragen der Clients
04 base dc=labnet,dc=de
05 
06 # LDAP-Server, SSL-verschlüsselt
07 uri ldaps://192.168.100.1/
08 
09 # ID, mit der sich Clients am Server anmelden
10 binddn ou=nss,dc=labnet,dc=de
11 
12 # Passwort in Klartext
13 bindpw Geheim
14 
15 # wenn ein Client mit Rootrechten läuft,
16 # wird diese ID zur Anmeldung beim Server
17 # verwendet. Das Passwort steht in der
18 # Datei /etc/ldap.secret (mode 600)
19 rootbinddn cn=Admin,dc=labnet,dc=de
20 
21 # Passwort-Updates mit der OpenLDAP
22 # password change extended operation
23 pam_password exop
24 
25 # OpenLDAP SSL
26 ssl on

01 #%PAM-1.0
02 # /etc/pam.d/login
03 auth     required   pam_securetty.so
04 auth     required   pam_nologin.so
05 auth     sufficient pam_ldap.so
06 auth     required   pam_unix.so    nullok try_first_pass #set_secrpc
07 account  sufficient pam_ldap.so
08 account  required   pam_unix.so
09 password required   pam_pwcheck.so nullok
10 password required   pam_ldap.so    use_first_pass use_authok
11 password required   pam_unix.so    nullok use_first_pass use_authtok
12 session  required   pam_unix.so    none # debug or trace
13 session  required   pam_limits.so
14 session  required   pam_env.so
15 session  optional   pam_mail.so

01 #%PAM-1.0
02 # /etc/pam.d/login
03 auth     required   pam_securetty.so
04 auth     required   pam_nologin.so
05 auth     sufficient pam_smbpass.so try_first_pass audit
06 auth     required   pam_unix.so
07 account  sufficient pam_ldap.so
08 account  required   pam_unix.so
09 password required   pam_pwcheck.so
10 password required   pam_smbpass.so debug use_first_pass use_authok
11 password required   pam_unix.so    use_first_pass use_authtok
12 session  required   pam_unix.so    none # debug or trace
13 session  required   pam_limits.so
14 session  required   pam_env.so
15 session  optional   pam_mail.so

01 #%PAM-1.0
02 # /etc/pam.d/passwd
03 auth     sufficient pam_ldap.so
04 auth     required   pam_unix.so    nullok use_first_pass
05 account  sufficient pam_ldap.so
06 account  required   pam_unix.so
07 password required   pam_pwcheck.so nullok
08 password required   pam_ldap.so    use_first_pass use_authtok
09 password sufficient pam_smbpass.so audit use_first_pass
10 password required   pam_unix.so    nullok use_first_pass use_authtok
11 session  required   pam_unix.so

Samba greift auf LDAP zu

In »/etc/smb.conf« sind die bekannten Basisparameter für die Abfrage des LDAP-Servers zu ergänzen, und zwar im Global-Bereich:

ldap server = lxserver.labnet
ldap suffix = dc=labnet,dc=de
ldap admin dn = "uid=Admin,ou=Sysusers,
ou=NSS,dc=labnet,dc=de"

Das Passwort, das die Änderung von Passwort-Hashes im LDAP-Verzeichnis schützt, kann und muss anschließend mit »smbpasswd« festgelegt werden:

smbpasswd -w Geheim -D 255 uid=Admin,
ou=Sysusers,ou=NSS,dc=labnet,dc=de

Die Option »-w Geheim« setzt das Passwort des Admin-Accounts. Der Parameter »uid=Admin,ou=Sysusers,ou=NSS,dc=labnet,dc=de« bezeichnet den Admin-User, der zum Lesen und Aktualisieren der Objektklasse »sambaAccount« berechtigt ist. Die Option »-D 255« schaltet ordentlich viel Debugging ein.

Die Windows-Clients können jetzt über den Samba-Server mit den im LDAP-Verzeichnis angelegten Benutzern arbeiten. Durch eine weitere Änderung in der PAM-Konfiguration (siehe Listing 5) kann auch Linux die Passwort-Hashes aus »lmPassword« oder »ntPassword« für die Authentifizierung verwenden, um praktischerweise für beide Welten nicht nur denselben Account, sondern auch dasselbe Passwort zu nutzen.

Um einen Windows-Rechner an den Samba-Server anzubinden, benötigt der Client jetzt noch einen Maschinen-Account im LDAP-Verzeichnis.

Abbildung 3: Das Adressbuch des Netscape Messengers kann direkt auf den LDAP-Server zugreifen. Dadurch lohnt sich die zentrale Verwaltung der Benutzerdaten doppelt.

Windows an Samba binden

Den Maschinen-Account anlegen klappt zum Beispiel mit GQ durch Kopieren des Accounts »ou=NSS | ou=Samba | uid=W2KCLIENT$«. Der neue Verzeichniseintrag muss den Objektklassen »sambaAccount« und »posixAccount« angehören und die folgenden Attribute müssen gesetzt sein: »uid«, »uidNumber«, »gidNumber«, »cn« und »homeDirectory«.

Der Aufruf »smbpasswd -m -a “CLIENTNAME$”« initialisiert den neuen Verzeichniseintrag für den Windows-Client mit der »uid« »CLIENTNAME$«. Auf Windows-Seite kann der Client nun wie üblich der Domain hinzugefügt werden. Der einzige User, der auf Samba-Seite das Recht zum Hinzufügen eines Clients in die Domain hat, ist der Superuser »root«.

Passwörter ändern

Wenn ein Windows-Benutzer sein Passwort ändert, greift der Client jetzt über den Samba-Server direkt auf das LDAP-Verzeichnis zu und ändert die entsprechenden Attribute des Objekts »sambaAccount«. Unter Linux ändert das »passwd«-Kommando die Felder von »sambaAccount« und »posixAccount«, wenn die beiden Module »pam_ldap« und »pam_smbpass« in »/etc/pam.d/ passwd« entsprechend gestapelt sind (siehe Listing 6).

Der umgekehrte Weg erfordert einige Experimente: Damit Änderungen des Windows-Passworts auch den Passwort-Hash in »posixAccount« ändern, sind in »/etc/samba/smb.conf« die Einträge »unix password sync«, »passwd chat« und »passwd program« anzupassen (»ldappasswd«).

Damit ist Linux als Samba-Sign-On- Server eingerichtet. An der Universität von Navarra hat sich dieses Modell mit mehr als 500 Clients und 15000 Benutzern seit zwei Jahren bewährt.

LDAP für alle

LDAP eignet sich auch bestens für die Authentifizierung von Apache und anderen Servern[9],[10]. Zusammen mit dem ebenfalls von OpenLDAP unterstützten Simple Authentication and Security Layer (SASL)[11] ergibt sich ein sanfter Migrationspfad zu echtem Single Sign On in einer heterogenen Netzwelt inklusive Microsoft-Clients.

Mit dem Gespann NSS, PAM, LDAP und Samba bietet sich Linux bereits heute für die zentrale Benutzerverwaltung an. Mit dem Ausbau von Samba zum Active Directory Server und der Anbindung an eine Kerberos-Realm in der kommenden Samba-Release 3.0 (TNG) wird die Stellung der Unix-Server im heterogenen Netz weiter gestärkt. (fjl)