Linux Active Directory/LDAP SSH Login mit sssd und realmd

Linux Server in heterogenen Systemlandschaften zu betreiben – also neben Windows und einer Active Directory oder LDAP – läuft auch 2019 ein Stück einfacher. Lokale SSH Logins waren gestern, LDAP/AD Login auf Linux Server ist heute.

Das Ziel ist einfach definiert: SSH Logins sollen über Active Directory (AD) Accounts geschehen. Wird ein Account in der AD deaktiviert, deaktiviert sich dementsprechend ebenso der SSH Login.

State-of-the-Art um das zu realisieren erscheint mir das Tool SSSD von RedHat. Und um SSSD noch leichter zu konfigurieren gibt es das Tool Realmd. Damit ist der SSH AD/LDAP Login unter Linux fast schon zu einfach geworden 😉 .

Übersicht

Der Konfigurationsablauf beim Einsatz mit SSSD und Realmd grob betrachtet:

• Man installiere realmd mit einigen Abhängigkeiten
• Man konfiguriere /etc/realmd.conf mit ein paar Werten
• Man führe den Befehl aus um der Active Directory zu joinen: realm --verbose join MYDOM.XY -U Administrator
• Man ernenne AD-Gruppen als SSH-Zugangsberechtigt
• Fertig. SSH mit deinem AD/LDAP Account ist jetzt möglich.

Optional und empfehlenswert zudem:

• Man verwalte die sudo-Berechtigungen mit SSSD aus AD/LDAP oder direkt in /etc/sudoers.d
• Man korrigiere /etc/pam.d/common-session damit das Home-Directory beim ersten SSH-Login automatisch erstellt wird, z.B.: /home/DOMAIN.XY/meinuser

Installation & Konfiguration

Ich benutze Ansible um die Installation & Konfiguration von Realmd und SSSD zu automatisieren, nachfolgend jedoch die daraus abgeleiteten Bash Commands zur Handinstallation. Meine Anleitung bezieht sich auf Ubuntu 18.04 Server, mit wenigen Änderungen beim Copy-Pasten lässt sich daraus problemlos aber auch Debian oder CentOS/RHEL bestücken.

apt install realmd sssd sssd-tools samba-common krb5-user packagekit samba-common-bin samba-libs adcli chrony

Die Pakete installieren sich ohne irgendwelche Rückfragen. Eine Anmerkung zu chrony/ntp: Ab Ubuntu 18.04 Server sollte man chrony anstatt ntp für die Zeitsynchronisation nutzen. Die korrekte Uhrzeit ist wichtig weil Kerberos eine korrekte Uhrzeit bedingt. Optimal wäre chrony/ntp so eingestellt, dass es beim Domänencontroller die Uhrzeit abholt.

/etc/realmd.conf anlegen:

[users]
default-home = /home/%d/%U
default-shell = /bin/bash
[active-directory]
default-client = sssd
os-name = {{ ansible_distribution }} Server
os-version = {{ ansible_distribution_version }}
[service]
automatic-install = no
[mydom.xy]
fully-qualified-names = no
automatic-id-mapping = yes
user-principal = yes
manage-system = no
computer-ou={{ ou_to_join_servers }}

• default-home und default-shell ist selbsterklärend.
• default-client kann auch winbind sein, wobei sssd zu empfehlen ist.
• os-name und os-version sind die typischen Objektfelder im AD, wie man sieht befülle ich diese Angabe automatisch mit Ansible. Diese Werte sollten natürlich auf das eigene System angepasst werden.
• automatic-install kann auf yes geändert werden. Dann würde sich zum Beispiel libpam-winbind automatisch nachinstallieren, falls default-client=winbind konfiguriert ist. Ich habe diese Option bisher auf no.
• fully-qualified-names wird zwar yes empfohlen, weil sonst ein lokaler Username in Konflikt gerät wenn er auf der AD ebenso existiert. Steht hier yes, muss der SSH Login mit user@MEINEDOMAIN@server durchgeführt werden. Da unsere AD-Accounts garantiert lokal auf Linux nicht gleich heissen, steht es auf no.
• automatic-id-mapping wird bei AD (nicht LDAP) yes empfohlen.
• user-principal = yes Damit wird das Attribut userPrincipalName in Form von host/computer@REALM erstellt.
• manage-system Damit könnte SSSD die Policies aus der Active Directory für das Linux System ziehen und anwenden. Die Manpage dazu ist viel zu wenig dokumentiert. Meint man hier GPO/Gruppenrichtlinien? Da mir dies noch suspekt vorkommt, setzte ich es auf no.
• computer-ou könnte zum Beispiel lauten: computer-ou="OU=Linux Server,DC=domain,DC=intra". Wenn nicht angegeben wird die zu joinende Maschine in der AD dort angelegt, wo alle neuen Rechner standardmäßig angelegt werden.

Join AD now!

Jetzt kann der AD gejoined werden: realm --verbose join -U Administrator oder wenn die Domäne nicht automatisch erkannt wird, alternativ realm --verbose join MYDOM.XY -U Administrator

Ab diesem Command geschieht alles blitzschnell.

1. Realmd sucht per DNS die Domänencontroller,
2. realmd nutzt das Tool adcli und fügt damit den Server mittels Kerberos KeyTab /etc/krb5.keytab in die Windows Domäne ein,
3. es konfiguriert /etc/krb5.conf und /etc/sssd/sssd.conf. Realmd ist sogar so schlau,
4. es kürzt den netbios Name auf 15 Stellen und fügt diese Information in sssd.conf ein, falls der Servername länger als 15 Stellen sein sollte.

AD/LDAP Gruppen für SSH berechtigen

Jetzt werden die AD Gruppen berechtigt, die SSH Zugriff haben sollen. Bisher haben wir ja nichts angegeben, daher gehe ich davon aus „keiner“ hat  Zugriff. Jedoch ist die Dokumentation darüber nicht ganz klar. Daher empfehle ich zwei Befehle: 1. Die SSSD (SSH) Rechte grundsätzlich verbieten, danach einzelne Gruppen berechtigen:

realm -v deny --all && realm -v permit -g 'ADGruppe1' 'AD-Gruppe-2'

Fertisch!

Und was ist mit Sudo-Berechtigungen? Zugegeben ich bin selbst noch nicht so modern, diese Sudo-Regeln aus der AD zu ziehen, was aber mit SSSD möglich sein sollte. In meinem Fall lege ich unter /etc/sudoers.d/realmd ein File mit den sudo Berechtigungen hin:

%Server-Administratoren-Linux ALL=(ALL:ALL) NOPASSWD:ALL

Dank dem % Prozentzeichen zu Beginn der Zeile bezieht sich dieser Eintrag auf die AD-Beispielgruppe „Server-Administratoren-Linux“.

Weitere Optimierungen

Home Directory: Nach dem SSH Login mit einem AD/LDAP Account wird das OS vermutlich meckern, dass das /home/domain/user-directory nicht erstellt werden konnte. Leider übernimmt realmd oder sssd diese Berechtigungsfrage (noch) nicht. Umgehungslösung: In der /etc/pam.d/common-session unterhalb pam_unix.so folgende Zeile einfügen:

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

sshPublicKey: SSSD kann auch den PublicKey aus der Active Directory ziehen und den AD-Account mit Private Key authentifizieren. Diese Einstellung wird Gegenstand eines nächsten Blogposts, denn hierzu muss das Active Directory Schema um das Feld sshPublicKey erweitert werden. Mehr dazu später.

/etc/krb5.conf: Wenn man nicht möchte, dass realmd keine generische /etc/krb5.conf anlegt kann die Datei vorher erstellt & befüllt werden. Realmd übernimmt dann die dortigen Einstellungen und das ist besser, als wenn es darin Unfug treibt.

Gibt es Alternativen zu realmd/sssd? Ist SSSD die Zukunft?

Es lohnt sich meines Erachtens realmd für sssd zu nutzen. Sssd kann aber auch manuell mit der AD verbunden werden, wie RedHat an dieser Stelle erklärt.

Samba, Winbind: In Vergangenheit konfigurierte man Logins auf Linux mit einem AD/LDAP Account i.d.R. mit Samba, Winbind und PAM, wobei man mit Samba & Winbind in die AD joint und danach in /etc/pam.d gewisse pam_winbind.so Regeln definiert um nur gewisse AD Gruppen den SSH Zugang zu gewähren. Eigentlich dasselbe was SSSD auch macht, aber Winbind bringt einen ganzen Brocken Komplexität mit sich, den SSSD nicht im Schlepptau hat beziehungsweise vereinfacht.

Es gibt leider auch Szenarien, wo SSSD weniger in Frage kommt. Wenn aktive Services auf Samba, Winbind bzw NTLM bereits aufbauen. Zum Beispiel unsere Squid Proxies. Diese sind bereits in der AD per NTLM gejoined und Squid nutzt NTLM für die User-Authentifzierung. Ich könnte den Spass zwar auf SSSD umbauen, dann unterstützt der Proxy aber nur noch Kerberos-Authentifizierung und keine NTLM-Authentifizierung mehr – zumindest so mein derzeitiges Verständnis. Das ist ein Problem, denn wenn Kerberos fehlschlägt kann ich kein Username/Passwort im Browser als Basic NTLM Auth angeben, komme also nicht ins Internet. Zudem kann z.B. ITunes kein Kerberos (angeblich), genau dort ploppt dann ein Username/Passwortfeld auf wenn der Proxy NTLM verwendet.

Fazit: SSSD ist gut für Server die kein Samba+Winbind+NTLM benötigen.

Übrigens beantwortet RedHat die Frage, ob Winbind „deprecated“ sei, selbst mit nein. Man solle im Kommentarfeld erzählen, wo die eigene Arbeitsumgebung Samba+Winbind anstatt SSSD benötigt, nur blöd hat dieser RedHat Blog inzwischen gar kein Kommentarfeld mehr. Hmpf“§$!!! 😀

Update 07/2021: Ansible Playbook

Hier findet sich mein Ansible Playbook, geschrieben für Ubuntu Server 18.04/20.04: https://seafile.schroeffu.ch/d/2d51829bf48249848775/

Ansible Playbook Inhalt grob umrissen:

• SSSD + Abhängigkeiten installieren
• Join AD durchführen
• AD Gruppe(n) berechtigen
• Sudo-Berechtigungen hinterlegen
• Home-Verzeichnis bei LDAP/AD Login münzen auf /home/DOMAIN.INTAR/Username
• Mind. 1 Fix damit Postfix aufhört Mailbomben zu versenden wenn man sudo ausführt, im Zusammenspielmit nss/sssd.