Einbindung eines Linux-Clients in das Active Directory

1.1 Motivation

Warum sollte ein Linux-Rechner an das AD angeschlossen werden? Schließlich können sämtliche Funktionen auch ohne dies genutzt werden.

Nun auch hier zählt die Administrierbarkeit: Schließlich ist es nicht von 3 Personen zu leisten, alle Benutzer mit gleichen Passwörtern auf 200 PCs einzurichten. So wird das AD als zentrale Benutzerverwaltung heran gezogen und auch die Ressourcen des Fileservers genutzt. Für den Benutzer ergeben sich somit kaum noch Unterschiede zwischen Microsoft und Linux-Welt

1.2 Benötigte Komponenten

Um es vorweg zu schicken: Es gibt von Microsoft tatsächlich das SfU, die „Services for UNIX“, mit denen die Microsoft-Welt UNX-freundlich mit NIS/NFS ausgestattet werden kann, aber das bedeutet eine Veränderung der zentralen AD-Controller.

Da nun die AD-Controller nicht verändert werden sollen oder können, bietet sich nicht der Weg an, die Linux-Workstation an die AD-Umgebung anzupassen. Die Linux-Systeme erscheinen der Windows-Welt dabei als Windows-Workstation. Zu diesem Zweck sind 3 Komponenten nötig:

1. Samba zusammen mit pam-mount zur Anbindung an die Windows-Shares und damit die bereitgestellten Laufwerke
2. Winbind um die Objektdatenbank des AD abfragen zu können
3. Kerberos-PAM um die Benutzerauthentifizierung des AD transparent in die Linux-Umgebung einzubinden

Diese Komponenten müssen aufeinander abgestimmt und an die existierende AD-Umgebung angepasst werden, was zwangsläufig mehr Aufwand bedeutet als eine native Verbindung über NFS zu realisieren. Allerdings bleibt so die administrative Sicht unverändert, so dass die Windows-Umgebung nicht verändert werden muss. Inkonsistenzen der Benutzerverwaltung können auf diesem Weg nicht entstehen.

In der folgenden Beschreibung werden beispielhaft Konfigurationen abgebildet, die jeweils auf die reale Konfiguration angepasst werden müssen. Um die Systemabhängigen Teile besser erkennen zu können, wurden diese fett und kursiv hervorgehoben.

In diesem Beispiel werden diese Eigenschaften verwendet:

• Master Domain Controller: dc6.ad.uni-bielefeld.de
• Domain Controller: dc6.ad.uni-bielefeld.de
• Domäne: AD
• AD-Domäne: ad.uni-bielefeld.de

1.3 Anpassung des Samba-Servers

Der erste Schritt besteht darin, dem Samba-System mitzuteilen, wie die AD-Umgebung konfiguritert ist. Insbesondere ist der Eintrag für den „ADS-Realm“ und die „Workgroup“ wichtig. Befindet sich der Domain Conroller nicht imselben Subnetz, so muss dieser auch mit seiner Adresse oder seinem Namen angegeben werden, sonst genügt ein"*", um Samba automatisch suchen zu lassen.

Die Winbind-Einträge legen fest, in welchem Zahlenintervall die AD-Benutzer und –Gruppen abgebildet werden. Das Intervall muss daher groß genug sein, um alle Objekte (Benutzer, Gruppen, Computer) aufnehmen zu können. Sollte der Zahlenbereich jemals verändert werden, müssen auch die Berechtigungen im Home-Directory des Benutzers angepasst werden.

/etc/samba/smb.conf

security = ads
realm = ad.uni-bielefeld.de
password server = dc6.ad.uni-bielefeld.de

workgroup = AD

server string = %h workstation
encrypt passwords = true
passdb backend = smbpasswd guest
wins support = no
os level = 0
domain master = no
preferred master = no
name resolve order = lmhosts host wins bcast
winbind uid = 10000-50000
winbind gid = 10000-50000
winbind use default domain = yes
template homedir = /home/AD/%U
template shell = /bin/bash
; set character to ISOLATIN1 with euro sign
unix charset = iso-8859-15
display charset = iso-8859-15
dos charset = 850

Da nun das AD mit Kerberos-Tickets arbeitet, muss der Kerberos-Client im Linux-System entsprechend eingerichtet werden. Analog zu der smb.conf müssen hier Realm und Rechnername des Controllers hinterlegt werden, damit die Authentifizierung stattfinden kann. Die Domain Controller finden sich hier als Key Server (kdc) wieder:

/etc/krb5.conf

[libdefaults]
# default_realm = AD.UNI-BIELEFELD.DE

[realms]
AD.UNI-BIELEFELD.DE = {
kdc = dc6.ad.uni-bielefeld.de
kdc = dc5.ad.uni-bielefeld.de
admin_server = dc6.ad.uni-bielefeld.de
}

Wenn diese Einträge vorhanden sind, kann der Rechner in die Domäne integriert werden, was mit dem folgenden Befehl geschieht:

net ads join –S dc6.ad.uni-bielefeld.de –U <user-mit-admin-recht>

Der Benutzername muss nicht zwangsläufig Administrator lauten, der Account muss lediglich entsprechende Rechte zum Hinzufügen des Rechnerkontos in das ADS besitzen. Im AD-System sollte nach dieser Aktion bereits der Name des Rechners auftauchen.

1.4 Anpassung der Benutzerauthentifikation

Um nun die Authentifizierung eines Benutzers zu ermöglichen, der sich über den xdm oder kdm anmeldet, muss zunächst dem System bekannt gegeben werden, dass der winbind-Daemon ebenfalls eine Quelle für Benutzereinträge ist. Das geschieht in dieser Datei:

/etc/nsswitch.conf

...
passwd: files winbind
group: files winbind
shadow: files winbind
...

Der Rechner sucht somit erst in den lokalen Dateien, und anschließend über den winbind im AD-System. Sofern der winbind-Daemon läuft, müsste ein „getent passwd“ bereits die AD-Benutzer zusätzlich anzeigen.

Da die Anmeldung über das „Pluggable Authentification Module“-System erfolgt, muss diese ebenfalls angepasst werden. In den meisten Distributionen sind die Einträge in den folgenden Dateien notwendig:

/etc/pam.d/common-auth

auth required pam_mount.so
auth sufficient pam_winbind.so use_first_pass
auth required pam_unix.so nullok_secure use_first_pass

In dieser Datei wird sichergestellt, dass bei einer Anmeldung eines Benutzers erst das AD nach dem Benutzernamen gefragt wird. Schlägt die Überprüfung fehl, wird nicht abgebrochen ("sufficient"), sondern die Authentifikation in der Benutzerdatenbank im Linux-System mit demselben Passwort (use_first_pass) fortgesetzt. Allen Prüfungen vorangestellt ist pam_mount, um das - jetzt noch - bekannte Passwort zu speichern, damit im "session"-Bereich die Windows-Shares gemountet werden können.

/etc/pam.d/common-account

account sufficient pam_winbind.so
account required pam_unix.so

Analog zur Anmeldung wird bei der Accountierung (Rechteprüfung) erst das AD gefragt und nur bei einem Fehlschlag in der Linux-Umgebung weiter geprüft.

/etc/pam.d/common-session

session optional pam_mount.so
session sufficient pam_winbind.so
session required pam_unix.so

Bei der Zusammenstellung der Session wird "pam_mount" wieder verwendet, um die benötigten Shares zu mounten.

1.5 Einbindung der Shares

Wie bereits erwähnt wird für den Automatismus zum Mount der Windows-Shares das Modul „pam-mount“ verwendet. Diese wird quasi zwischen Eingabe des Passwortes durch den Benutzer und Authentifizierung durch den winbind geschaltet und mountet nach Vorgabe durch die Konfigurationsdatei die Wondows-Shares unter Angabe der Benutzerkennung. Welche Shares wie in das System eingehängt werden, legt die folgende Datei „/etc/security/pam_mount.conf“ fest. Die Syntax dieser Datei orientiert sich am "mount"-Befehl und hat den Vorteil, dass sie im Gegensatz zur allgemeinen „/etc/fstab“ auch mit Variablen arbeiten kann, wie auch in Benutzerdefinierte Skripten verzweigen kann. Somit kann ein Äquivalent zu den Logon-Skripten unter Windows hergestellt werden, das die automatische Anbindung an (Windows-) Fileserver beim Anmeldevorgang übernimmt.

Im Folgenden Beispiel wird der Share /shared_uver/dez_1 des Servers nonus in das Unterverzeichnis U des anzumeldenden Benutzers so gemountet, wobei die Zugehörigkeit der Dateien zum Angemeldeten Benutzerkonto geordnet werden. Das gleiche passiert mit dem Share forum, der in das Unterverzeichnis X eingehängt wird.

/etc/security/pam_mount.conf

...
# volume <user> <type> <server> <volume> <mount point>
# <mount options> <fs key cipher> <fs key path>

volume * smbfs fs-home shared_uver/dez_1 /home/AD/&/U uid=&,gid=&,dmask=0775,workgroup=AD,iocharset=iso8859-15,codepage=cp850 - -
volume * smbfs fs-home shared_uver/forum /home/AD/&/X uid=&,gid=&,dmask=0775,workgroup=AD,iocharset=iso8859-15,codepage=cp850 - -
...

In den neueren Versionen wird statt des einfachen Text-Formates das XML-Format verwendet. Die Konfigurations-Datei lautet dann
/etc/security/pam_mount.conf

...
<volume options="dir_mode=0775,domain=AD,iocharset=utf8,uid=%(USER),sec=ntlmssp" user="*" mountpoint="/home/AD/%(USER)/shared_uhrz" path="shared_uhrz" server="fs-home.uni-bielefeld.de" fstype="cifs" /> 
...

Achtet bitte hier auf die Option "sec=ntlmssp", die verhindert, dass die alte und unsichere NTLM1 Verbindungsvariante verwendet wird.

Da dieses Modul ebenfalls die Session überwacht, werden die Verbindungen automatisch wieder getrennt, sobald die Session beendet wird (Abmeldung).

Allerdings ist diese Form des Mounts nur sinnvoll, wenn der betroffene Rechner als Einzelarbeitsplatz genutzt wird. Für Server ist diese Form ungeeignet, da nach dem Mount jeder auf diesem PC angemeldete Benutzer und der ersten Benutzerrechten auf diesen zugreifen kann.