Linux im Active-Directory [ACHTUNG: Diese Anleitung ist noch nicht fertiggestellt!]

Unser konkretes Ziel ist das Bereitstellen eines Linux-Terminal-Servers auf dem sich Nutzer in einer bestehenden Active-Directory Domäne grafisch mit ihren normalen AD-Accounts von Windows-AD-Clients aus einloggen können.

Der erste Schritt dazu ist die Integration des Linux-Servers als AD-Client in die bestehende Active-Directory-Infrastruktur, so dass AD-Accounts auch gleichzeitig Benutzer-Accounts auf dem Linux-Server sind. Diese Integration eines Linux-Rechners ins Active-Directory wird hier beschrieben. Das Vorgehen dabei ist nicht spezifisch für den oben genannten Einsatzzweck als Terminal-Server -- auf ebensolche Weise lässt sich z.B. auch ein Linux-Desktop-Rechner als Client ins AD einbinden.

Die Einrichtung des Linux-Rechners untergliedert sich dabei in folgende Schritte:

• Zeit- und Nameserver einstellen
• Authentifizierung gegen AD einrichten (Winbind, nsswitch, PAM, optional: Kerberos)
• Optional: einhängen der AD-Shares und SSH-Login mit Kerberos-Tickets ermöglichen
• Probleme und Lösungen

Diese Anleitung wurde anhand eines Debian Lenny (5.0) erstellt und auch mit einem Ubuntu Jaunty Jackalope (9.04) getestet. Auf Unterschiede in der Konfiguration wird gegebenenfalls explizit hingewiesen.

Ergänzend zu den hier vorliegenden Ausführungen könnten die Vortragsunterlagen zu dem Vortrag zu diesem Thema bei den Sicherheitstagen im Januar 2010 von Interesse sein.

Wir verwenden folgende Bezeichnungen:

DNS-Server

Die Authentifizierung im Active-Directory basiert auf dem Kerberos-Protokoll. Dieses ist darauf angewiesen, dass die Namensauflösung auch für AD-interne Namen wie dc1.adtest.intern korrekt funktioniert. Deshalb werden als DNS-Server im Linuxrechner die AD-DNS-Server eingetragen. Diese liefern außerdem noch einige Service-Recource-Records (DNS SRV RRs) mit Informationen für Kerberos aus, so dass sich dessen Einrichtung später aus ein Minimum beschränkt.

In unserem Fall dienen die AD-Domain-Controller auch gleichtzeitig als AD-DNS-Server, so wie das in kleinen bis mittelgroßen AD-Domänen häufig der Fall ist.

Wenn man das Programm resolvconf verwendet, so genügt eine zusätzliche dns-nameservers-Option in /etc/network/interfaces:

iface eth0 inet static
     address 192.0.2.31
     netmask 255.255.255.0
     gateway 192.0.2.1
     # dns-* options are implemented by the resolvconf package, if installed
     dns-nameservers 192.0.2.21 192.0.2.22
     dns-search adtest.example.com

Selbstverständlich sollte man sicherheitshalber die Datei /etc/resolv.conf überprüfen:

search adtest.example.com
nameserver 192.0.2.21
nameserver 192.0.2.22

NTP-Server

Für das Kerberos-Protokoll ist es weiterhin wichtig, dass die Zeit auf allen beteiligten Rechnern übereinstimmt. Die maximal zulässige Abweichung ist konfigurierbar und im Allgemeinen auf fünf Minuten eingestellt. Daher ist es notwendig die Zeit des Linux-Rechners mit der des AD-NTP-Servers zu syncronisieren (als AD-NTP-Server dienen auch hier wieder die beiden AD-DCs). Am einfachsten gelingt dies mittels eines Cron-Jobs, der stündlich das Programm ntpdate aufruft.

Dazu die Datei /etc/cron.hourly/ntpdate mit folgendem Inhalt anlegen und ausführbar machen:

#!/bin/sh
/usr/sbin/ntpdate dc1.adtest.intern dc2.adtest.intern > /dev/null

Für die Anbindung des Linux-Rechners an die Benutzerverwaltung im Active Directory nutzen wir den Winbind-Dämon (winbindd) des Samba-Projektes. Dieser ist im Paket winbind enthalten. Eine von uns bisher nicht untersuchte freie Alternative wäre möglicherweise Likewise Open.

Von Winbindd nutzen wir zum einen das PAM-Modul pam_winbind.so für die Abbildung der Benutzer-IDs im AD (SID) auf lokale Unix-Benutzer-IDs (uid). Konkret verwenden wir das Idmap-Backend RID (vgl. man idmap_rid) welches die uid direkt aus der SID berechnet , so dass die uid auch auf verschiedenen Linux-Rechnern für denselben Nutzer gleich ist. Näheres dazu findet sich in der Samba-Dokumentation.

Zum anderen stellt Winbindd Name Service Switch-Dienste für group und passwd und darin Default-Werte für Shell und Home-Directory zur Verfügung.

Die Konfiguration von winbindd erfolgt in der Konfigurationsdatei /etc/samba/smb.conf von Samba. Die vom Samba-Kommando testparam auf das Wesentliche reduzierte Ausgabe dieser Datei sieht hier wie folgt aus (für Samba ab Version 3.3.0):

/etc/samba/smb.conf

[global]
realm = ADTEST.INTERN
workgroup = ADTEST
security = ADS

ntlm auth = No
winbind rpc only = Yes

template shell = /bin/bash
allow trusted domains = No
idmap backend = rid:ADTEST.INTERN=100000-199999
idmap uid = 100000 - 199999
idmap gid = 100000 - 199999
winbind enum users = Yes
winbind enum groups = Yes
winbind use default domain = Yes

winbind refresh tickets = Yes

syslog = 5
log file = /var/log/samba/log.%m
max log size = 1000
panic action = /usr/share/samba/panic-action %d

In Samba 3.0.25 wurde eine neue, jedoch mit Version 3.3.0 wieder verworfene Syntax idmap config eingeführt. Näheres dazu findet sich unter anderem in den Release Notes for Samba 3.3.0. In einem alten Samba aus diesem Zeitraum (wie z.B. in Debian Lenny) sollte die oben genutzte und damals als deprecated gekennzeichnete Syntax zwar eigentlich auch funktionieren, jedoch verhindert die damals neue Syntax Fehlermeldungen:

# idmap backend = rid:ADTEST.INTERN=100000-199999
# idmap uid = 100000 - 199999
# idmap gid = 100000 - 199999
idmap domains = ADTEST.INTERN
idmap config ADTEST.INTERN:backend = rid
idmap config ADTEST.INTERN:range = 100000-199999

Wichtig: Nach Änderungen an der smb.conf immer mit testparm überprüfen, ob alle Änderungen auch korrekt eingelesen werden!

Nun kann der Rechner in die Domäne aufgenommen werden. Als root auf dem Rechner führen wir folgendes aus:

net ads join -U <Domänenadministrator>

Dabei wird Hinter -U der Name eines Nutzers in der Domäne angegeben, der zum Hinzufügen neuer Rechner berechtigt ist.
Ob alles geklappt hat, können wir nun mittels

net ads testjoin

und wbinfo mit verschiedenen Optionen dazu überprüfen.

Der Name Sevice Switch (NSS) ermöglicht es Unix-Konfigurationsdateien und -datenbanken wie zum Beispiel /etc/passwd und /etc/group durch verschiedene Quellen zur Verfügung zu stellen. Hier sollen durch Winbind zusätzlich Einträge für die Nutzer aus dem AD bereitgestellt werden. Das benötigte Modul /lib/libnss_winbind.so.2 ist schon im Paket winbind enthalten. Es muss lediglich in der NSS-Konfigurationsdatei /etc/nsswitch.conf jeweils für passwd und group das Modul winbind hinzugefügt werden.

/etc/nsswitch.conf:

...
passwd: compat winbind
group:  compat winbind
shadow: compat
...

Bei dieser Reihenfolge der Module (winbind compat) werden Nutzer stets zuerst im AD gesucht. Daher muss man auf ein Timeout warten, wenn Winbind nicht verfügbar ist und man sich als lokaler Nutzer einloggen will. In der Testphase kann es deshalb sinnvoll sein die Reihenfolge tauschen

Die in vielen älteren Anleitungen zu findende zusätzliche Option wins für hosts ist meines Erachtens nicht sinnvoll, da in aktuellen Windows-Umgebungen NETBIOS nicht mehr genutzt wird und zumindest bei Windows Server 2008 auch standardmäßig nicht mehr aktiviert ist.

Die Linux Pluggable Authentication Modules (PAM) sind ein flexibler Mechanismus zur Benutzerauthentifizierung. Sie werden über die Dateien in /etc/pam.d/ und und /etc/pam.conf konfiguriert. Hinweise zur Konfiguration finden sich in den Manpages (man pam.conf) und Linux-PAM System Administrators' Guide.

Beim Bearbeiten der PAM-Konfiguration immer größte Vorsicht walten lassen: immer Backups anlegen und an mindestens einer Stelle als root eingeloggt bleiben bis sichergestellt (getestet) ist, dass man sich auch wieder als root einloggen kann!

Nun wird PAM so eingerichtet, dass bei jeder Anmeldung am System die Authorisierung und Sitzungsverwaltung versucht winbind zu nutzen. Das dazu benötigte Modul /lib/security/pam_winbind.so ist schon im winbind Paket enthalten. Unter Debian und Ubuntu genügt es in /etc/pam.d/ lediglich die Dateien common-account, common-auth, common-password und common-session zu bearbeiten. Diese werden von allen anderen eingebunden. In diesem Punkt dürften die größten Unterschiede zwischen verschiedenen Linux-Distributionen liegen. Zu beachten ist insbesondere die zusätzliche option use_first_pass für pam_unix.so in /etc/pam.d/common-auth. Hier der Inhalte dieser Dateien unter Debian und Ubuntu:

Debian

Unter Debian ist in diesen Dateien außer (den hier weggelassenen) Kommentaren am Anfang nur relativ wenig enthalten.

/etc/pam.d/common-account

account sufficient pam_winbind.so
account required pam_unix.so

/etc/pam.d/common-auth

auth sufficient pam_winbind.so krb5_auth krb5_ccache_type=FILE
auth required pam_unix.so nullok_secure use_first_pass

/etc/pam.d/common-password

password sufficient pam_winbind.so
password required pam_unix.so nullok obscure md5

/etc/pam.d/common-session

session required pam_mkhomedir.so skel=/etc/skel/ umask=0077
session required pam_unix.so

Ubunbtu

Unter Ubuntu werden diese Dateien mit pam-auth-update administriert und enthalten deshalb außer einem entsprechenden Kommentar am Anfang noch einen größeren Default-Block am Ende:

# here are the per-package modules (the "Primary" block)
[..]
# end of pam-auth-update config

Vor diesem Block werden die im Folgenden genannten Zeilen eingefügt.

/etc/pam.d/common-account

account [success=2 new_authtok_reqd=done default=ignore] pam_winbind.so

# here are the per-package modules (the "Primary" block)
[..]

# end of pam-auth-update config

/etc/pam.d/common-auth Achtung: hier muss im Primary block die Option use_first_pass eingefügt werden ansonsten ist eine normale Anmeldung am System nicht mehr möglich!

auth [success=2 default=ignore] pam_winbind.so krb5_auth krb5_ccache_type=FILE

# here are the per-package modules (the "Primary" block)
auth [success=1 default=ignore] pam_unix.so nullok_secure use_first_pass
# here's the fallback if no module succeeds
[..]

# end of pam-auth-update config

/etc/pam.d/common-password

password [success=2 default=ignore] pam_winbind.so

# here are the per-package modules (the "Primary" block)
[..]
# end of pam-auth-update config

/etc/pam.d/common-session

session required pam_mkhomedir.so skel=/etc/skel/ umask=0077

# here are the per-package modules (the "Primary" block)
[..]
# end of pam-auth-update config

Erläuterungen

• krb5_auth: Kerberos benutzen
• krb5_ccache_type=FILE: TGT holen und speichern für spätere Nutzung
• use_first_pass: das beim vorhergehenden Modul eingegebene Passwort verwenden (für Nutzer, die nicht im AD sind)
• pam_mkhomedir.so: dieses PAM-Modul bewirkt, dass ein noch nicht vorhandenes Home-Verzeichnis bei der Anmeldung automatisch angelegt wird.

Besser nicht einen Windows-Share direkt als Homeverzeichnis nutzen, da:

• darauf keine Unix-Domain-Sockets angelegt werden können, diese werden aber von einigen Anwendungen benötigt (z.B. KDE)
• Konfigurationsdateien unter Linux im Homeverzeichnis liegen (Sie beginnen mit einem Punkt, also unter Linux „versteckt“). Diese sollten unter Windows nicht im Homeverzeichnus, sondern im Profil-Verzeichnis liegen.

Die Konfiguration von Kerberos ist eigentlich nicht notwendig, jedoch kann es zur Fehlersuche hilfreich sein, da man dann auch ohne Winbind testen kann, ob prinzipiell die Authentifizierung gegen das AD via Kerberos funktioniert. Des weiteren kann es für einige Anwendungen hilfreich sein, wenn man sich mit kinit direkt ein Kerberos-Ticket holen kann.

Wir nutzen Kerberos um mit kinit für Nutzer, die sich mittels SSH-Key (also nicht über Winbind) eingeloggt haben, ein TicketGrantingTicket zu holen, welches dann wiederum zum Einhängen der Windows-Shares genutzt wird.

Die notwendigen Dateien, damit der Rechner Kerberos (als User) benutzen kann sind im Paket krb5-user enthalten. Die bei dessen Installation abgefragten Parameter sind egal, da ohnehin keine für unseren Einsatzzweck brauchbare Konfigurationsdatei erstellt wird. Diese wird mit folgendem Inhalt neu erstellt:

/etc/krb5.conf

[libdefaults]
default_realm = ADTEST.INTERN

Den in vielen älteren Anleitungen erwähnten Abschnitt [realms] muss man heutzutage nicht mehr eintragen, da dies automatisch über den AD-DNS-Server mit SRV-RRs gesetzt wird. (Diesen haben wir ja oben als Nameserver eingetragen.) Auch der Abschnitt [appdefaults] pam ist in unserem Fall nicht relevant, da dieser nur von pam_krb5.so benutzt wird, wir jedoch winbind.so in PAM einbinden.

Zum Testen versucht man mit kinit ein TicketGrantingTicket zu holen und überprüft danach mit klist, ob man es auch bekommen hat. Danach kann es mit kdestroy wieder entfernt werden:

user@adtest:~$ kinit aduser@ADTEST.INTERN
Password for aduser@ADTEST.INTERN:
user@adtest:~$ klist -5
Ticket cache: FILE:/tmp/krb5cc_1000
Default principal: aduser@ADTEST.INTERN

Valid starting Expires Service principal
08/18/09 15:30:20 08/19/09 01:30:51 krbtgt/ADTEST.INTERN@ADTEST.INTERN
renew until 08/19/09 15:30:20
user@adtest:~$ kdestroy
user@adtest:~$ klist -5
klist: No credentials cache found (ticket cache FILE:/tmp/krb5cc_1000)

Da ADTEST.INTERN als default_realm gesetzt ist, würde auch ein kinit aduser ausreichen.

mount.cifs

Damit die Nutzer nach erfolgreichem Login die Windows-Shares einhängen können, ohne noch einmal ihr Passwort einzugeben, muss mount.cifs in der Lage sein, sich mit Hilfe der Keyutils mit dem TicketGrantingTicket des Nutzers ein Ticket für den Dateiserver zu holen. Die Pakete smbfs und keyutils stellen alles Notwendige zur Verfügung. Zum Einhängen der Shares aus dem AD werden folgende Pakete benötigt:

• smbfs: enthält das Mount-Programm mount.cifs und Hilfsprogramm cifs.upcall für Kerberos-Tickets
• keyutils: ist der Werkzeugsatz für die kernelinterne Schlüsselverwaltung, die von Dateisystemen und anderen genutzt werden kann

Außerdem muss in /etc/request-key.conf folgendes angefügt werden:

/etc/request-key.conf

create cifs.spnego * * /usr/sbin/cifs.upcall %k %d
create dns_resolver * * /usr/sbin/cifs.upcall %k

Nun kann z.B. ein Share \\dc1.adtest.intern\homes vom Nutzer ohne Passworteingabe wie folgt eingehängt werden:

/sbin/mount.cifs //dc1.adtest.intern//homes/ ~/adhomes/ -o krb5i,guest,directio

(directio deaktiviert Caching, sonst Probleme bei paralleler Nutzung)

SSH-Login

Um sich auch mit ssh mit einem Kerberos-Ticket anmelden zu können, muss man die Authentifizierung mittels GSSAPI erlauben (das Protokoll, welches auch von Windows verwendet wird, um die Kerberos-Tickets etc. auszutauschen)

/etc/sshd_conf auf dem Server:

# GSSAPI options
GSSAPIAuthentication yes
GSSAPIKeyExchange yes

GSSAPICleanupCredentials yes

/etc/ssh/ssh_config auf dem Client:

# GSSAPI options
GSSAPIAuthentication yes
GSSAPIDelegateCredentials yes

Aber: leider ist das im Moment noch nicht wirklich nützlich, da der NX-Client das noch nicht kann. Ein gepatchtes Putty für Textmodus geht aber.

In diesem Abschnitt werden aufgetretene Probleme und Lösungen oder Wege, diese zum umgehen beschrieben.

Problem: Winbind stürzt ab oder funktioniert nicht richtig

Ab und zu kommt es vor, dass Winbind komplett abstürzt (Mail mit dem Inhalt "Panic or segfault in Samba" an den Admin) oder aber dass die NSSwitch-Aufläsung nicht mehr funktioniert ("I have no name!" wird statt des Benutzernamens angezeigt, getent passwd liefert nur die lokalen Nutzer, id aduser findet den Nutzer nicht).

Umgehung: die Eigentliche Ursache für diese Problem konnte bisher nicht lokalisiert werden. Deshalb wird derzeit einfach der Winbind-Dienst nach einem Crash neu gestartet. Das ist zwar nicht schön, ermöglicht aber vorerst eine relativ reibungslose Nutzung.

in /usr/share/samba/panic-action wird unten folgende Zeile angefügt:

echo "/etc/init.d/winbind restart" | at now + 1 minute

Damit bekommt man jedoch so derzeit noch Fehlermeldungen, vermutlich wegen Umgebungsvariablen; es funktioniert aber.

Problem: Winbind (und Samba) in Debian Lenny sind sehr alt

Daher sind eher mehr Probleme mit Windows 2008 Server zu erwarten

Lösung: Winbind aus Lenny-Backports benutzen: http://www.backports.org

Für diesen Tipp / die Software bzw. Skripte leistet das RRZN keinen Support.