SSSD + AD in der Uni Bielefeld

Integration von Linux-Systemen im ActiveDirectory

Besonderheiten bei der Installation

in Linux-System an ein ActiveDirectory anzubinden, bedeutet nicht nur die Bekanntgabe des Computers in diesem Verwaltungssysten, es sollen vornehmlich alle im AD bekannten Benutzerkonten auf diesen Rechner übertragen werden. Darüber hinaus soll es auch möglich sein, Ressourcen des ADs von der betroffenen Station zu nutzen. Dabei muss allerdings beachtet werden, dass die Philosophie der Ressourcennutzung in Windows und UNIX/Linux unterschiedlich ist:
Während UNIX (externe) Ressourcen Systemweit zur Verfügung stellt, koppelt Windows diese an Eine Session. Daraus ergeben sich einige „Unstimmigkeiten“, die im laufenden Betrieb beachtet werden müssen. Bei der AD-Integration werden vornehmlich diese Aufgaben wahrgenommen:

• Mapping der Benutzerkonten in das lokale System
• Authentifizierung des Benutzers gegen das AD-System
• Integration entfernter Ressourcen.

Um diese Aufgaben zu lösen werden die folgenden Pakete benötigt:

• samba
  Der Samba-Server stellt die Grundfunktionalität bereit und ist somit das Kernstück der AD-Integration.
• krb5, pam_krb5
  Die Authentifizierung der Windows-User geschieht über das Kerberos-Verfahren. Daher wird dieses Paket nötig.
• sssd sssd-ad sssd-tools
  Das Paket SSSD stellt mehrere unterschiedlich Module für die Authentifizierung und Sessionverwaltung zur Verfügung, unter anderem auch einen Connector oder nach sssd-Terminologie einen Provider, der die Verbindung zum ActiveDirectory aufnimmt. SSSD kann die im AD hinterlegten Benutzerkonten in das UNIX/Linux-System integrieren (analog zum rcpbind).
• cifs_mount (smbfs)
  Um eine Methode zu haben, an die Windows-Shares heran kommt muss das CIFS (und/oder SMB) Filesystem im System bekannt sein.
• pam_mount
  Dieses Modul ermöglicht die automatisierte Ausführung eines Mount-Befehlsbei der Öffnung einer Session.

Achtung: Sind die Domain Controller mit Windows 2008R2 ausgestattet, wird für die korrekte Anbindung an das AD-System eine Samba-Version von >= 3.2 benötigt; die AD-Provider des sssd sind darüber hinaus erst seit der Version 1.8.11 verfügbar.

Mit diesen Voraussetzungen kann der Linux-Rechner in das System integriert werden.

In dem vorliegenden Beispiel Wird die Umgebung der Universität Bielefeld verwendet, in der die folgenden Vorgaben verwendet wurden:

• Name des AD: AD.UNI-BIELEFELD.DE
• AD-Domaincontroller: dc4, dc5 und dc6, jeweils in der Domäne ad.uni-bielefeld.de
• Name des AD-Kontos mit (Teil-) Aministrationsrechten: sub-admin1
• Name des zu integrierenden Rechners: gimli
• Name des verwendeten AD-Logins: ffeuer

Anpassung des Samba-Servers

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

/etc/samba/smb.conf

[global]
workgroup = AD
realm = AD.UNI-BIELEFELD.DE
client signing = yes
client use spnego = yes
kerberos method = secrets and keytab
password server = dc6.ad.uni-bielefeld.de
security = ads
server string = %h server (Samba, Ubuntu)
map to guest = Bad User
obey pam restrictions = Yes
pam password change = Yes
passwd program = /usr/bin/passwd %u
passwd chat = *Enter\snew\s*\spassword:* %n\n *Retype\snew\s*\spassword:* %n\n *password\supdated\ssuccessfully* .
unix password sync = Yes
syslog = 0
log file = /var/log/samba/log.%m
max log size = 1000
dns proxy = No
usershare allow guests = Yes
panic action = /usr/share/samba/panic-action %d
idmap config * : backend = tdb

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.

Achtung: die Domain-Namen werden im Kerberos-Umfeld immer einheitlich GROSS geschrieben!

Die Domain Controller finden sich hier als Key Server (kdc) wieder:

/etc/krb5.conf

[libdefaults]
default_realm = AD.UNI-BIELEFELD.DE
dns_lookup_realm = true
dns_lookup_kdc = true
ticket_lifetime = 24h
nenew_lifetime = 7d
rdns = false
forwarable = yes

...
[realms]
AD.UNI-BIELEFELD.DE = {
   kdc = dc4.ad.uni-bielefeld.de
   kdc = dc5.ad.uni-bielefeld.de
   kdc = dc6.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.

Zunächst wird ein Rechner-Kontos in die passende OU im AD; das muss manuell passieren, weil die Automagische Erzeugung eines Computer- Kontos in der OU "Computers" in der Uni Bielefeld nicht erlaubt ist. Als Name wird der Hostname des eigenen PCs verwendet, den Kerberos und Samba verwenden (Hier:"gimli").

Der Join ins AD erfolgt in 2 Schritten: Erst wird ein gültiges Kerberos-Ticket (kinit) erzeugt, anschließend mit net join der Domäne beigetreten. Ersteres muss mit einem Benutzerkonto passieren, das die entsprechenden Rechte in der OU hat (hier:"sub-admin1").

# kinit -V sub-admin1
Using default cache: /tmp/krb5cc_0
Using principal: Diese E-Mail-Adresse ist vor Spambots geschützt! Zur Anzeige muss JavaScript eingeschaltet sein.
Password for Diese E-Mail-Adresse ist vor Spambots geschützt! Zur Anzeige muss JavaScript eingeschaltet sein.:
Authenticated to Kerberos v5

# net ads join -k -U sub-admin1
Enter sub-admin1's password:
Using short domain name -- AD
Joined 'GIMLI' to realm 'ad.uni-bielefeld.de'
No DNS domain configured for gimli. Unable to perform DNS Update.
DNS update failed!

Der Hinweis, dass das DNS nicht verändert werden kann, ist an dieser Stelle irrelevant, da letzteres ohnehin aus dem dhcp Server und nicht aus dem AD "gespeist" wird.

Der verwendete Account muss entsprechende Rechte zum Hinzufügen des Rechnerkontos in das ADS besitzen. Im AD-System sollte nach dieser Aktion bereits der Name des Rechners auftauchen.

Nach dem "join" -Befehl sollte eine neue /etc/krb5.keytab erzeugt werden. Der Inhalt kann überprüft werden durch:

# klist -k
Keytab name: FILE:/etc/krb5.keytab
KVNO Principal
---- --------------------------------------------------------------------------
  21 host/Diese E-Mail-Adresse ist vor Spambots geschützt! Zur Anzeige muss JavaScript eingeschaltet sein.
  21 host/Diese E-Mail-Adresse ist vor Spambots geschützt! Zur Anzeige muss JavaScript eingeschaltet sein.
  21 host/Diese E-Mail-Adresse ist vor Spambots geschützt! Zur Anzeige muss JavaScript eingeschaltet sein.
  21 host/Diese E-Mail-Adresse ist vor Spambots geschützt! Zur Anzeige muss JavaScript eingeschaltet sein.
  21 host/Diese E-Mail-Adresse ist vor Spambots geschützt! Zur Anzeige muss JavaScript eingeschaltet sein.
  21 host/Diese E-Mail-Adresse ist vor Spambots geschützt! Zur Anzeige muss JavaScript eingeschaltet sein.
  21 GIMLI$@AD.UNI-BIELEFELD.DE
  21 GIMLI$@AD.UNI-BIELEFELD.DE
  21 GIMLI$@AD.UNI-BIELEFELD.DE

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 sssd-Daemon ebenfalls eine Quelle für Benutzereinträge ist.

In Versionen vor 1.8.11 war dieses nur mit Hilfe des SfU und einem aufwändigen Kerberos/LDAP-Providers von sssd möglich, seit es den AD-Provider gibt, gestaltet sich die Einrichtung deutlich einfacher

Konfiguration des SSSD

Der SSSD Daemon über nimmt die eigentliche Anbindung an das Authentifizierungssystem und Sessionmanagement des AD.

Im Gegensatz zum winbind arbeitet der sssd mit einem flachen accounting-Modell, also ohne den Zusatz der Domäne. Je nach Konfiguration des entsprechenden PAM-Moduls sucht das Betriebssystem erst in der /etc/passwd und erst dann über den sssd, so dass ein lokaler Account Priorität hat, oder umgekehrt.

/etc/sssd/sssd.conf

[sssd]
config_file_version = 2
reconnection_retries = 3
services = nss, pam
domains = AD.UNI-BIELEFELD.DE

[domain/AD.UNI-BIELEFELD.DE]
id_provider = ad
; ad_server = dc4.ad.uni-bielefeld.de, dc5.ad.uni-bielefeld.de,
dc6.ad.uni-bielefeld.de
override_homedir = /home/AD/%u
default_shell = /bin/bash
create_homedir = true
remove_homedir = true

Anpassung des NSS

Die Name Services müssen ebenfalls Kenntnis von der Existenz der SSSD Konfiguration bekommen. Die Konfiguration und die Priotität findet sich in der Datei:

/etc/nsswitch.conf

...
passwd:         compat sss
group:          compat sss
shadow:         compat sss
...

Der Rechner sucht somit erst in den lokalen Dateien, und anschließend über den sssd im AD-System. Sofern der sssd-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 existieren Hilfsmittel, um dieses zu konfigurieren, so auch unter Ubuntu oder Debian über den Befehl

/usr/sbin/pam-auth-update

der die Integration der Module interaktiv abfragt. Sollte ein Automatismus fehlen, sind üblicherseise diese Einträge in den folgenden Dateien notwendig:

/etc/pam.d/common-auth

...
auth required pam_mount.so
auth sufficient pam_sss.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_sss.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_sss.so
session required pam_unix.so

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

Ein File- oder Printserver auf Linux-Basis ist somit vollständig in die AD-Domain eingebunden. Jegliche Änderung an Konten und deren Berechtigungen wird transparent an den Linux-Rechner weiter gereicht.

Nach einem Restart sollte es per gentent möglich sein, einen AD-Benutzer zu finden:

# getent passwd ffeuer
ffeuer:*:821053701:821000513:ffeuer:/:

# su - ffeuer
$ id
uid=821053701(ffeuer) gid=821000513(domänen-benutzer) Gruppen=821000513(domänen-benutzer),821023282(verwaltung_users),821027654(s-1-5-21-283016044-3387516373-1648638545-27654)

Einbindung der Shares

Wenn der Linux-Rechner als Arbeitsstation eingesetzt werden soll, muss dafür gesorgt werden, dass die benötigten Shares für Fileserver auch zugänglich gemacht werden. Die Windows-typischen Logonskripten können dabei mangels Kompatibilität nicht verwendet werden, statt dessen kann jedoch der Automatismus des Moduls „pam-mount“ verwendet werden.

Dieses Modul wird quasi zwischen Eingabe des Passwortes durch den Benutzer und Authentifizierung durch den sssd geschaltet und mountet nach Vorgabe durch die Konfigurationsdatei die Windows-Shares unter Angabe der Benutzerkennung. Welche Shares wie in das System eingehängt werden, legt die Datei „/etc/security/pam_mount.conf.xml“ fest. Sie liegt im XML-Format vor und orientiert sich Syntax-seitig am "mount"-Befehl. Im Gegensatz zur /etc/fstab hat sie den Vorteil, dass sie auch mit Variablen arbeiten und in benutzerdefinierte Skripten verzweigen kann. Somit stellt sie ein Äquivalent zu den Logon-Skripten unter Windows her und übernimmt die automatische Anbindung an (Windows-) Fileserver beim Anmeldevorgang.

Im Folgenden Beispiel wird der Share shared_uver des Servers fs-home in das Unterverzeichnis U im Homedirectory des anzumeldenden Benutzers gemountet.

/etc/security/pam_mount.conf.xml

...
<mkmountpoint enable="1" remove="true" />
<volume options="dir_mode=0775,workgroup=AD,iocharset=utf8" user="*" mountpoint="/home/AD/%(USER)/U" path="shared_uver" server="fs-home.uni-bielefeld.de" fstype="cifs" />
...

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. Durch die Session-basierte Verbindung wird jeglicher Zugriff auf den eingebundenen Share mit den Rechten des Benutzers ausgeführt, unter dessen Namen die Verbindung aufgebaut wurde. Daher erscheinen in diesem Share aus Linux-Sicht ausschließlich User- und Gruppen-Zugehörigkeit des Anmelde-Kontos. Die real vergebenen ACLs bleiben verborgen.

Für Terminal-Server ist diese Form bedingt geeignet, da nach dem Mount jeder auf diesem PC angemeldete Benutzer auf diesen Share zugreifen kann. In diesem Fall sollte darauf geachtet werden, dass der Mounpoint jeweils in dem eigenen Homedirectory liegt. Mehrfache Mounts auf denselben Share mit unterschiedlichen Credentials und Mountpoints funktionieren problemlos.

Anpassung des AD

Aus Windows-Sicht erscheint ein so konfiguriertes Linux-System im AD wie eine Windows-Workstation, außer, dass das Betriebssystem –korrekterweise – sich nicht als „Windows XP“, sondern als „Samba“ ausgibt. Die Integration ist dabei so umfassend, dass aus AD-Sicht keinerlei Unterschied zwischen Linux- und Windows-Computer zu sehen ist.

Ein zu beachtendes Detail ist allerdings die DNS-Auflösung: Wenn die Benutzerkonten bezüglich der Arbeitsstationen reglementiert sind, reicht es nicht aus, den DNS-Namen als zulässige Station anzugeben, es muss zusätzlich die IP-Adresse angegeben werden.

Sofern jedoch ohnehin keine Beschränkung besteht, so besteht keine Änderungsnotwendigkeit.