Wer heterogenen IT-Massenbetrieb administriert, will auch bei der Benutzerverwaltung unnötige Doppelarbeit vermeiden: Liegen die Daten schon im Active Directory eines Windows-2003-Servers, dann soll sich Linux daraus bedienen. Mit einigen Kniffen gelingt das auch.

In einer idealen Welt gibt es nur offene Standards und Systeme, die sich strikt daran halten. In diesem Umfeld könnte jeder Client alle Serverdienste nutzen, unabhängig vom Betriebssystem. In der Realität beherrschen aber oft Windows-Server die IT-Infrastruktur. Wer dort Linux als Client einführt, wird zunächst mit doppelter Benutzerverwaltung arbeiten. Das bedeutet aber doppelten Administrationsaufwand und setzt Kenntnisse beider Server voraus.

Doch es geht einfacher. Selbst wer das proprietäre Windows nicht durch Linux und Samba ersetzen darf, kann beide Systemwelten integrieren. Zu den Linux-Zutaten gehört OpenLDAP[1] als Client, das seit August 2000 auch LDAP v3 beherrscht[2]. Diese Version nutzt Microsoft seit Windows 2000 in seinen Server-Editionen, sie bildet damit den Kern des Active Directory. Zudem löste ein leicht modifiziertes Kerberos v5[9] die bisherige Windows-NT-Authentifizierungsmethode NTLM ab. Auch für Linux gibt es Kerberos-Implementierungen.

Einen weiteren Baustein entwickelte Luke Howard. Der ehemalige Apple-Mitarbeiter gründete 1999 die Firma PADL[12] und zeichnet für RFC 2307[5] verantwortlich (aktuell: Draft »rfc2307bis«,[6]). Howards Vorstoß beschreibt den Einsatz von LDAP als Network Information Service. Während die herkömmliche, auch als Yellow Pages bekannte NIS-Variante auf Textdateien mit Benutzer-, Gruppen- und/oder Host-Informationen basiert, liegen bei RFC 2307 die Daten in einem LDAP-Server (Näheres dazu im Kasten “Schema im LDAP”).

Baukastenprinzip

Allerdings muss Linux erst wissen, dass es die Userdaten aus einem LDAP-Verzeichnis beziehen soll. Dank Name Service Switch (NSS,[11]) mit seinen Modulen und Konfigurationsdateien ist es möglich, das komplette System darauf umzustellen. Wie die Elemente zusammenarbeiten, steht im Kasten “Das NSS-Prinzip”.

Während NSS die Bibliotheken für NIS und für Files mitbringt und damit ein Eintrag in »/etc/nsswitch.conf« genügt, hat es der Admin bei LDAP als Datenquelle schwerer. Die passende Bibliothek »/lib/libnss_ldap.so.2« fehlt den meisten Standardinstallationen, sie ist ein Produkt der bereits genannten PADL- Software[12]. Nss_ldap leistet die Kernarbeit bei der Verbindung von Linux und Active Directory. Wer die Library selbst übersetzt, sollte folgende Configure-Optionen angeben:

--enable-rfc2307bis
--with-ldap-lib=openldap
--enable-schema-mapping
--enable-paged-results
--enable-configurable-krb5-ccname-gssapi

Gentoo-User modifizieren das Ebuild in »/usr/portage/net-libs/nss_ldap«. Wie RFC 2307[5] beschreibt, zapft Nss_ldap die Benutzerobjekte innerhalb des Active Directory an (siehe Abbildung 2). Benutzerobjekte sind über Attribute definiert, die zu Objektklassen gehören. Das LDAP-Schema bestimmt, welche Attribute und Klassen es gibt (siehe Kasten “Schema im LDAP”).

Weil LDAP keine starren Strukturen vorgibt, muss Nss_ldap erst erfahren, wie die Linux-spezifischen Attribute im Active Directory heißen. Diese Information steht – zusammen mit grundlegenden Einstellungen für die Verbindung mit dem Active Directory – als Schema-Mapping in der Nss_ldap-Konfigurationsdatei (passend zum vorliegenden Beispiel in Listing 1). Zu finden ist sie unter »/etc/ldap.conf« (nicht zu verwechseln mit der OpenLDAP-Konfiguration in »/etc/openldap/ldap.conf«).

Das bei Nss_ldap mitgelieferte Konfigurationsfile ist sehr gut dokumentiert und mit vielen Vorlagen gefüllt. Um das passende Schema-Mapping für verschiedene Schema-Erweiterungen zu aktivieren, muss der Admin lediglich einige Kommentarzeichen entfernen (Listing 1 ab Zeile 14). Das Beispiel in diesem Artikel verwendet die Services for Unix 3.5, also gilt das Mapping für dieses Schema.

Das NSS-Prinzip

Der Name Service Switch erlaubt es, an zentraler Stelle zu konfigurieren, auf welchem Weg ein Linux-System die Namen von Benutzern oder Rechnern in ihre numerischen Varianten übersetzt (und umgekehrt zu Nummern passende Namen findet). Will etwa das Kommando »ls -la« ausführlich den Inhalt des aktuellen Verzeichnisses auflisten, muss es User-IDs auf Benutzernamen abbilden. Dazu ruft es die C-Funktion »getpwuid()« aus der Libc auf. Das Kommando »getent passwd« hingegen nutzt die Funktion »getpwnam()« und gibt eine Liste von Benutzern im Passwd-Format aus. Die Herkunft der Daten bestimmt der Admin mit Hilfe der NSS-Konfigurationsdatei »/etc/nsswitch.conf«: passwd: files ldap group: files ldap NSS generiert aus diesen Einträgen die Namen von Bibliotheken. Aus »files« wird »libnss_files.so.2«, zu finden ist sie in »/lib«. Diese Bibliothek reagiert auf »getpwnam()«, indem sie die Einträge in »/etc/passwd« in die Struktur »struct passwd« schreibt. Den Zeiger auf diese Struktur übergibt NSS an die Libc und diese weiter zur aufrufenden Applikation, hier »getent«. Diese gibt die Benutzerdaten auf Stdout aus. Abbildung 1 stellt den gesamten Ablauf vom Aufruf der Applikation bis zur Ausgabe der Ergebnisse grafisch dar: 1 Eine Applikation sendet eine Anfrage über den Aufruf einer Libc-Funktion. 2 Die Funktion sucht in »/etc/nsswitch.conf« nach verfügbaren Quellen. 3 Im Beispiel passen zwei Quellen. 4 Die Funktion spricht die Bibliotheken der Reihe nach an. 5 Das Ergebnis geht an die Libc. 6 Die Funktion gibt das Ergebnis als Zeiger zurück an die Applikation. Abbildung 1: Der Name Service Switch gestaltet das Hinzufügen eigener Quellen für Benutzerdaten recht einfach. Ein Eintrag in »/etc/nsswitch.conf« und eine dazu passende Bibliothek genügen.

Schema-Erweiterung

Windows 2003 kennt ohne Nachhilfe weder UID noch GID. Als Nachhilfelehrer dient eine Schema-Erweiterung: Sie kombiniert die Attribute »uidNumber« und »gidNumber« in der Objektklasse »posixAccount«. Schema-Erweiterungen sind allerdings ausschließlich dem Enterprise-Admin vorbehalten. Dahinter verbirgt sich etwa der »Administrator«-Account von Windows 2003.

Abbildung 2: Der Name Service Switch zapft das Active Directory mit Hilfe von Nss_ldap an. Aus ihm liest er die Werte von Attributen, die der Admin mit Schema-erweiternder Software nachträglich hinzugefügt hat. Die SASL-Schicht ergänzt LDAP-Anfragen um Kerberos-Schutz.

Als Schema-erweiternde Software hat sich das von PADL[12] entwickelte Plugin bewährt. Zusätzlich fügt es dem Eigenschaftendialog eines Benutzers das Tab »Unix settings« hinzu (siehe Abbildung 3). Für zentrale Einstellungen ist das GUI das Plugins selbst zuständig; hier darf der Admin vorgeben, welches Homeverzeichnis, welche GID und welche UID die PADL-Software standardmäßig auswählen soll (Abbildung 4).

Allerdings funktioniert die Schema-Erweiterung des PADL-Plugins nur mit Windows 2000. Windows 2003 braucht Microsofts Services for Unix (SFU,[16], siehe Abbildung 5). Eine Schema-Erweiterung ist irreversibel; Einträge können nachträglich nicht mehr entfernt, nur modifiziert werden. Deshalb: Wer die SFU nicht anderweitig benötigt, kann sie getrost gleich wieder deinstallieren. <@99 L_Dreieck (E)>E

01 host              dc.nwtraders.msft
02 base              dc=nwtraders,dc=msft
03 ldap_version 3
04 
05 use_sasl on
06 sasl start_tls
07 scope sub
08 
09 nss_base_passwd   ou=user,dc=nwtraders,dc=msft?sub
10 nss_base_shadow   ou=user,dc=nwtraders,dc=msft?sub
11 nss_base_group    ou=group,dc=nwtraders,dc=msft?one
12 
13 # Services for UNIX 3.5 mappings
14 nss_map_objectclass posixAccount User
15 nss_map_objectclass shadowAccount User
16 nss_map_attribute uid msSFU30Name
17 nss_map_attribute uniqueMember msSFU30PosixMember
18 nss_map_attribute homeDirectory msSFU30HomeDirectory
19 #nss_map_attribute homeDirectory msSFUHomeDirectory
20 nss_map_objectclass posixGroup Group
21 pam_login_attribute msSFU30Name
22 pam_filter objectclass=User
23 
24 sasl_secprops maxssf=0
25 krb5_ccname FILE:/etc/.ldapcache

Das PADL-Plugin erfüllt aber auch unter Windows 2003 sinnvolle Aufgaben. Gerade im plattformübergreifenden Betrieb erweist es sich als sehr praktisch. Bei einer hohen Anzahl an Linux-Benutzern im Active Directory ist es jedoch meist einfacher, Attribute über Windows-Skripte zu setzen (die zum Beispiel CSV-Files zusammen mit »dsmod« oder »csvde« nutzen).

Abbildung 3: Das Tab »Unix settings« fehlt bei einer Standardinstallation von Windows 2003 noch, das PADL-Plugin »AD4Unix« ergänzt es. Hier tippt der Admin die Einträge ein, die Nss_ldap für seine Linux-Benutzer braucht.

Abbildung 4: Praktisch am PADL-Plugin: Der Admin kann viele Vorgaben zentral für alle User einstellen. Leider sind die UIDs hart kodiert. Für mehr Flexibilität ist Skripting gefragt.

Abbildung 5: Während der Installation der SFU 3.5 (Services for Unix) führt Windows 2003 eine Schema-Erweiterung durch. Erst danach können Linux-Clients das Active Directory sinnvoll nutzen.

Erster Kontakt

Für den ersten Linux-Kontakt zum AD braucht das freie System Hilfe von OpenLDAP. Binary-Distributionen wie Suse oder Red Hat bieten für eine Clientversion Fertigkompilate an; bei Gentoo-Linux sind einige Anpassungen nötig (siehe Kasten “Gentoo-Pakete”). Sollte es mit vorkompilierten Paketen Probleme geben, kann das an fehlenden Optionen beim Übersetzen liegen. In diesem Fall hilft es, die Installation aus den Quellen vorzunehmen.

Wie Abbildung 6 zeigt, funktionieren nun erste Suchoperationen im Active Directory. Leider verläuft dieser Erstkontakt zwischen Linux und Windows weder verschlüsselt noch Kerberos-geschützt. Den Aufbau der sicheren Kommunikation übernimmt seit LDAP v3 das SASL-Framework (Simple Authentication and Security Layer). Unter Linux hat sich die Cyrus-SASL-Implementierung der Carnegie-Mellon-Universität (CMU,[8]) etabliert. Auch OpenLDAP nutzt auf Wunsch diese Bibliothek.

SASL lässt sich in beliebige TCP-Protokolle einbinden und dient als einheitliche Schnittstelle für verschiedene Übertragungsmechanismen und Authentifizierungsmethoden. Für Verschlüsselung mit SSL oder seinem Nachfolger TLS (Secure Sockets Layer, Transport Layer Security) verlangt OpenLDAP aber ein gültiges Zertifikat. Wer allein auf die Kerberos-Authentifizierung vertraut und SSL/TLS nur zur Verschlüsselung nutzt, stellt mit »TLS_REQCERT never« in »/etc/ openldap/ldap.conf« den Zertifikatswunsch ab. Zudem braucht OpenLDAP das OpenSSL-Paket, an dem immerhin keine weiteren Arbeiten nötig sind.

Authentifiziert mit Kerberos

Nach der Installation des Authentifizierungsdienstes Kerberos muss der Admin den Client noch einrichten. Wie das geht, beschreibt ein Linux-Magazin-Artikel in einer früheren Ausgabe[10]. Als Authentication-Server dient der Windows-2003-Server.

Sind die Grundlagen für eine verschlüsselte und kerberisierte Anfrage gelegt, holt sich der Linux-Admin mit »kinit Administrator« ein Ticket. Die folgende Suchoperation im Active Directory verläuft wie die in Abbildung 6, diesmal allerdings verschlüsselt und kerberisiert:

ldapsearch -Hldaps://dc.nwtraders.msft 
  -b "ou=user,dc=nwtraders,dc=msft" 
  "(uidnumber=2307)" -Omaxssf=0

Sie erzielt das gleiche Resultat, jedoch verschlüsselt über »ldaps« (LDAP mit SSL/TLS). Die Benutzer-Authentizität zieht OpenLDAP dabei aus dem Credential Cache des anfragenden Users. Die Option »-Omaxssf=0« (SSF, Security Strength Enforced) schaltet die SASL-Sicherheit für diesen Aufruf wieder ab. Das ist gelegentlich nötig, um Fehler im Active Directory zu umgehen.

Die oben gezeigte Suche funktioniert nur, wenn sich der Benutzer auf dem Client einloggen kann, sich also bei Kerberos authentifiziert und im LDAP-Verzeichnis bekannt ist. Der Clientrechner muss die Authentizität des Benutzers aber schon vor dessen Login prüfen und dazu Daten aus dem AD abfragen. Dafür braucht er ein eigenes Kerberos-Ticket, das er in einem Kerberos-Cache speichert. Nur mit diesem Ticket darf der Clientrechner Anfragen an das Active Directory stellen.

attributetype ( 1.3.6.1.1.1.1.0
   NAME 'uidNumber'
   DESC 'An integer uniquely identifying 
         a user in an administrative 
         domain'
   EQUALITY integerMatch
   SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
   SINGLE-VALUE )

objectclass ( 1.3.6.1.1.1.2.0
   NAME 'posixAccount'
   SUP top
   AUXILIARY
   DESC 'Abstraction of an account with 
         POSIX attributes'
   MUST ( cn $ uid $ uidNumber 
          $ gidNumber $ homeDirectory )
   MAY ( userPassword $ loginShell 
         $ gecos $ description ) )

Schlüsselkasten

Für solche Jobs stellt Kerberos so genannte Keytabs zur Verfügung. Der Windows-Admin legt einen Benutzer im Active Directory an, für den der Keytab-Eintrag gilt. Am besten in einer eigenen Organisationseinheit wie beispielsweise »Unix Services«.

Keytabs enthalten Principals und Keys in unverschlüsselter Form. Ein Host oder ein Service greift auf die Keytab-Datei »/etc/krb5.keytab« zu und liest aus dieser den zum Principal passenden Schlüssel. Damit authentifiziert er sich gegen einen anderen kerberisierten Host oder Service. Da sie im Klartext auf der Platte liegen, sind Keytabs zwar sicherheitskritisch, aber oft unvermeidbar.

Abbildung 6: Mehr als die Installation von OpenLDAP ist nicht erforderlich, um erste Suchoperationen im AD durchzuführen. Die laufen aber noch unverschlüsselt und ohne Kerberos-Schutz.

Einer für alle

Viele Dokumentationen behaupten, dass beim Einsatz von Windows 2003 als Kerberos-Server für jeden Kerberos-Client ein Benutzer existieren müsse. Da der Keytab-Eintrag in diesem Fall aber servicebasiert ist, genügt ein User im Active Directory. Den Service-Eintrag im Server nimmt »ktpass.exe« vor. Der Service-Name ist an keine Vorgaben des Kerberos-Servers gebunden, sondern eher als Freitext zu verstehen, zum Beispiel »nssldap«. Ein Service, der die Keytab nutzt, muss das gleiche Service-Principal verwenden, sonst findet er den passende Key nicht.

Der passende »ktpass.exe«-Aufruf ist in Abbildung 7 zu sehen. Das Windows-2003-Server-Programm generiert Keytabs im MIT-Kerberos-Format. Das Tool ist in keiner Standardinstallation enthalten, es gehört zum Reskit-Paket[17]. Die Optionen bedeuten:

• »/princ«: Das Service-Principal im
  Kerberos-Format.
• »/mapuser«: Der im Active Directory erzeugte
  Benutzer, auf den Kerberos die Keytab abbildet.
• »/pass«: Das Passwort für den Schlüssel.
  Ist als Wert »*« angegeben, fordert
  »ktpass.exe« den Admin an einem Prompt dazu auf, das
  Passwort einzutippen.
• »/out«: Name der auszugebenden Keytab-Datei.

Vorsicht: Kann ein Angreifer die Keytab beim Kopieren abfangen, erhält er Zugriff auf das Active Directory. Es ist daher zu empfehlen, die Keytab sicher per »scp« oder »sftp« auf den Linux-Client zu kopieren. Dort nimmt sich der Linux-Admin der Keytab an:

ktutil
> rkt service.keytab
> wkt /etc/krb5.keytab

Die »ktutil«-Kommandos pflegen die neue Keytab in die vorhandenen Keytabs des Clientsystems ein. Der Erfolg ist auf der Linux-Konsole leicht zu überprüfen:

kinit -k nssldap/dc.nwtraders.msft

Dabei sollte der Client ein Ticket erhalten, ohne dass der Admin ein Passwort eintippt. Die Option »-k« besagt, dass der Schlüssel für das Service-Principal »nssldap/dc.nwtraders.msft« in der Keytab liegt. Befindet sich die Keytab nicht im Standardpfad von Kerberos, übergibt der Admin diesen mit »-t Pfad«.

Es ist also ein valides Session-Ticket nötig, um Anfragen an das Active Directory stellen zu dürfen. Dummerweise haben Tickets aber gewöhnlich nur eine begrenzte Laufzeit.

Abbildung 7: Damit die Linux-Clients schon vor dem ersten eingeloggten Benutzer Zugriff auf den AD erhalten, brauchen sie ein Keytab-File, das der Windows-Admin mit »ktpass.exe« erzeugt.

01 auth      required    /lib/security/pam_env.so
02 auth      required    /lib/security/pam_mount.so
03 auth      sufficient  /lib/security/pam_unix.so
04 auth      sufficient  /lib/security/pam_krb5.so use_first_pass likeauth
05 auth      required    /lib/security/pam_deny.so
06 
07 account   sufficient  /lib/security/pam_unix.so
08 
09 password  required    /lib/security/pam_cracklib.so retry=3 type=
10 password  sufficient  /lib/security/pam_unix.so nullok md5 shadow use_authtok
11 password  sufficient  /lib/security/pam_krb5.so use_first_pass
12 password  required    /lib/security/pam_deny.so
13 
14 session   required    /lib/security/pam_mkhomedir.so silent skel=/usr/local/etc/skel umask=0022
15 session   required    /lib/security/pam_limits.so
16 session   required    /lib/security/pam_unix.so
17 session   optional    /lib/security/pam_krb5.so
18 session   optional    /lib/security/pam_mount.so

Credential Caching

Um sich das manuelle Erneuern zu sparen, nutzt der Linux-Admin einen zeitgesteuerten Cron-Auftrag. Wieder ist die Keytab nötig, die das Principal samt Key enthält:

kinit -k -c /etc/.ldapcache nssldap/dc.
nwtraders.msft@NWTRADERS.MSFT

Dieses Kommando, als Root ausgeführt, besorgt ohne Passwortnachfragen ein neues Ticket vom KDC (Key Distribution Center). Der Eintrag für den »krb5_ ccname« in »/etc/ldap.conf« (am Ende von Listing 1) erlaubt Nss_ldap das Überschreiben des Default-Cache (in »/tmp«). Die Kinit-Option »-c« wählt den gewünschten Cache aus. Kinit setzt die Zugriffsrechte auf den Cache so, dass ihn nur Root lesen darf.

Mit diesen Vorbereitungen listet »getent passwd« nicht nur die Benutzer in »/etc/passwd«, sondern nach einer kurzen Pause auch jene User aus dem Active Directory (Abbildung 2), deren Unix-Attribute im Schema gesetzt sind.

Anmelden bitte

Für die erfolgreiche Authentifizierung fehlt nun noch die Kerberos-Anbindung des Linux-Login-Verfahrens. Hierfür sind die Pluggable Authentication Modules (PAM) verantwortlich[13]. Die zentrale Vergabestelle für Tickets ist »/etc/pam.d/system-auth«, sie muss das Modul »pam_krb5« enthalten[14].

Listing 2 zeigt eine mögliche Variante der »system-auth«. Das System erlaubt weiterhin lokale Benutzer (»pam_unix.so«), zum Beispiel für Root-Logins. Findet PAM den Benutzer nicht in »/etc/passwd«, reicht es den Namen weiter an das Kerberos-Modul (»use_first_pass«). Das Modul baut eine Verbindung zum Windows-2003-KDC auf, der den Benutzer in der Kerberos-Datenbank sucht. Findet der KDC den User, fragt Linux nach einem Passwort. Stimmt der aus dem Passwort generierte Schlüssel mit dem in der Kerberos-Datenbank überein, ist der Benutzer erfolgreich angemeldet.

Neue Heimat

Die nächste Hürde ist das Homeverzeichnis. Ohne Home schickt Linux einen Benutzer entweder in das Wurzelverzeichnis »/« oder lässt ihn erst gar nicht ins System. Bei zentral verwalteten Accounts liegt meist auch das Homeverzeichnis auf einem zentralen Fileserver. Die klassische Verteiltechnik heißt NFS (Network Filesystem,[19]). Die Verzeichnisstruktur kann variieren: Während es in kleinen Umgebungen genügt, alle Benutzer in ein Verzeichnis zu stopfen, sortieren größere Sites ihre User in verschiedene Unterverzeichnisse, meist entsprechend der primären Gruppe.

Meldet sich ein bisher unter Windows arbeitender User erstmals auf einem Linux-Client an, braucht er dafür ein neues Home. Das kann der Admin manuell anlegen oder er automatisiert diesen Vorgang. In NFS-verteilten Umgebungen eignet sich dazu »pam_mkhomedir« aus der PAM-Standardinstallation. Zeile 14 in Listing 2 zeigt, wie der entsprechende Eintrag in »/etc/pam.d/system-auth« auszusehen hat. Die Option »silent« ist wichtig, da das Modul sonst jeden Kopiervorgang der Skeletons bestätigt haben will.

Das Verfahren hat zwei Nachteile: Zum einen braucht der Linux-Client das ungewöhnliche Recht, neue Homeverzeichnisse auf dem Server anzulegen. Zweitens nutzen Windows und Linux fortan getrennte Fileserver. Letzteres muss dank Samba nicht sein. Seit Version 3 ist es sogar möglich, einen Samba-Server in der Rolle eines Domain-Member-Servers in eine Windows-2003-Domäne zu integrieren (ADS Security Mode,[18]). Zum vollwertigen Mitglied fehlen eigentlich nur Gruppenrichtlinien, die funktionieren unter Samba nicht.

01 [global]
02   workgroup = NWTRADERS
03   realm = NWTRADERS.MSFT
04   server string = Samba 3.0.9
05   security = ADS
06   password server = 192.168.100.2, 192.168.100.3
07   hosts allow = 192.168.100 127.
08   log level = 2
09   log file = /var/log/samba3/log.%m
10   idmap uid = 1000-5000
11   idmap gid = 1000-2000
12 
13 [homes]
14   valid users = %S
15   read only = No
16   browseable = No
17   nt acl support = No
18   root preexec = /usr/sbin/mkhomedir %u %g

01 # Einige Optionen
02 debug     0
03 mkmountpoint 1
04 fsckloop  /dev/loop7
05 options_require nosuid,nodev
06 
07 # Tools zum Mounten von Verzeichnissen
08 lsof      /usr/sbin/lsof
09 fsck      /sbin/fsck
10 losetup   /sbin/losetup
11 unlosetup /sbin/losetup -d
12 #smbmount /bin/mount -t cifs
13 smbmount  /bin/mount -t smbfs
14 ncpmount  /bin/mount -t ncpfs
15 umount    /bin/umount
16 lclmount  /bin/mount -p0
17 nfsmount  /bin/mount
18 mntagain  /bin/mount --bind
19 mntcheck  /bin/mount
20 
21 # Beispiele
22 volume *    smb   filer &         /home/&/data uid=&,workgroup=NWTRADERS - -
23 volume ruth nfs   filer ruth      /shared/ruth hard,intr,nfsvers=3,wsize=8192, rsize=8192 - -
24 volume root local -     /dev/sde1 /backup      noatime,acl,nodev,nosuid,noexec - -
25 volume root local -     /backup   -            - - -

Samba einbinden

Im ADS Security Mode nimmt Samba an der Kerberos-Authentifizierung teil. Eine passende Konfigurationsdatei »/etc/samba/smb.conf« ist in Listing 3 abgedruckt. Folgendes Kommando nimmt Linux in die Windows-2003-Domäne auf:

net ads join -U Administrator

Es legt gleichzeitig ein Computerkonto im Active Directory an, in der Organisationseinheit »Computers« (siehe Abbildung 8). ACL-Unterstützung für Homeverzeichnisse ist unnötig, da diese Directories ausschließlich für ihren Eigner zugänglich sein sollen. Folglich ist im Beispiel kein ACL-Support aktiviert.

Abbildung 8: Wird Samba Mitglied in einer Windows-2003-Domäne, erhält es ein Computerkonto im Active Directory. Die Zeile »server string« in »/etc/samba/smb.conf« (Listing 3, Zeile 4) geht in diesen AD-Eintrag ein.

Wieder ist Linux dafür zuständig, die Homeverzeichnisse authentifizierter User bei Bedarf automatisch anzulegen. Während bei NFS der Client das Directory generieren und mit Inhalt füllen muss, beherrscht der Samba-Server dieses Aufgabe selbst. Beim Ein- und Aushängen von Freigaben führt er Skripte aus, in Listing 3 aktiviert die letzte Zeile diese Aktion. Samba ruft »/usr/sbin/mkhomedir« mit Root-Rechten auf und übergibt mit »%u« und »%g« den Benutzer- und den Gruppennamen des Users, der die Freigabe einhängen will.

In der NFS-Welt mounten Linux-Systeme die Exporte meist mit Automounter oder einem festen Eintrag in »/etc/fstab«. Für Samba ist es sinnvoller, die Freigaben erst beim Login einzuhängen. Mit dem PAM-Modul »pam_mount«[15] ist auch das realisierbar. Neben SMB/CIFS, NFS, NCP (von Netware- oder Mars-NWE-Servern) und lokalen Dateisystemen betreibt es auch verschlüsselte Filesysteme über das Loopback-Device.

Pam_mount ist eines der wenigen PAM-Module, die eine eigene Konfigurationsdatei besitzen. Ein Beispiel für die »/etc/security/pam_mount.conf« zeigt Listing 4. Die PAM-Konfiguration in Listing 2 aktiviert Pam_mount bereits. Interessant sind vor allem die letzten vier Zeilen von Listing 4. Sie binden verschiedene Shares dynamisch ein. Nach dem Schlüsselwort »volume« folgt der Benutzer, unter dessen Kennung der Mount erfolgt. Dabei steht »*« für den eingeloggten User.

Ist »*« als User angegeben, dient »&« als Wildcard für seinen Namen (Zeile 22 nutzt dies). Nach dem Usernamen folgen die Mountvariante, der Fileserver und dessen Export beziehungsweise Freigabe, der lokale Mountpunkt, die Mountoptionen und zuletzt zwei Felder mit Daten für verschlüsselte Filesysteme.

Verständigungsprobleme

Für Admins die nahe liegende Variante wäre, das Homeverzeichnis der User immer über SMB/CIFS einzubinden, sowohl unter Linux als auch Windows. Leider stößt das Vorhaben derzeit auf Probleme: Während NFS mit Named Pipes und Sockets problemlos umgeht, fehlt SMB/CIFS dafür entweder das grundlegende Verständnis oder es gibt Inkompatibilitäten. Ein über SMB/CIFS transportiertes Homeverzeichnis unter Linux bringt beispielsweise KDE in Schwierigkeiten. KDE legt Sockets zur Kommunikation an, die SMB/CIFS nicht versteht.

Eine Lösung besteht darin, die Benutzer- von den Profildaten zu entkoppeln und Letztere nur im lokalen Client zu sammeln. Der Client könnte diese Profildaten zwar mit einem zentralen Server synchronisieren und damit quasi nebenbei Offline-Dateien einführen. Allerdings führt das unter Umständen zu widersprüchlichen Einstellungen in den Profil-Files, wenn sich ein User gleichzeitig auf mehreren Clients anmeldet.

Die Freigaben über zwei Protokolle zu verteilen ist der bessere Weg. Für einen Fileserver unter Linux heißt das, Samba für Freigaben an Windows einzusetzen. An OS-kompatible Clients exportiert er das Homeverzeichnis mit NFS, AFS oder Coda (Abbildung 9). Dabei könnten Linux-Clients sogar ein eigenes Home erhalten, auf das Windows-Rechner keinen Zugriff haben. Ein Vorteil: Die nur für Linux relevanten Files (speziell die Punkt-Dateien) würden Windows-User nicht irritieren. Um dennoch Zugriff auf die gemeinsamen Dateien zu erhalten, bindet Zeile 22 in Listing 4 kurzerhand das Windows-Home in Linux unter »/home/ Name/data/« ein. Dazu nutzt es wiederum Samba.

Abbildung 9: Der ADS dient für Windows- und Linux-Clients sowie für Samba als Authentifizierungsserver (rote Pfeile). Die Windows-Clients holen die Dateien ihrer Benutzer per SMB/CIFS vom Samba-Server, während Linux das bewährte NFS nutzt, um die Homeverzeichnisse zu mounten (grüne Pfeile).

In vielen Firmen haben Linux-Freunde gar keine Chance, eine eigene Benutzerverwaltung nach offenen Standards zu betreiben. Sie müssen mit Microsofts Active Directory vorlieb nehmen. Dank der Kombination aus OpenLDAP, SASL, Kerberos, diversen PAM-Plugins und einem Samba- und NFS-Fileserver gelingt es trotzdem, Linux-Clients einzuführen und sie eng in die bestehenden Windows-Systeme einzubinden. (fjl)