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.
Kategorien: Linux

Schroeffu

Der Autor ist Schweizer, verheiratet, war 7 Jahre in DE und nun allesamt zurück in die CH. Als Vater von inzwischen zwei Kindern stellt sich die Frage: Wann bekommen die Kids ein eigenes Linux Laptop? ;-D

23 Kommentare

Hans · 4. November 2019 um 14:08

Hallo,

gutes Tutorial, hat mir sehr geholfen. Für die umask in der /etc/pam.d/common-session empfehle ich aber eher 0077, damit a) kein Fremder die Inhalte des Homedir lese kann und b) aus diesen Gründen ssh den Login über einen Key nicht ablehnt.

    Schroeffu · 23. Januar 2020 um 23:41

    Danke. Da hast du wohl Recht mit der sichereren chmod bzw umask Einstellung, ich werde es selbst die Tage nochmal genauer anschauen und bestenfalls im Blogpost anpassen.

    Schroeffu · 12. Mai 2020 um 14:34

    Danke nochmal, habe es auf 0077 nun auch in meiner Anleitung übernommen. Macht selbstverständlich total Sinn 😉

Steffen Rohde · 6. November 2019 um 14:03

Hallo,

danke für das tolle Tutorial, es war sehr hilfreich.

Mit Spannung warte ich auf die Fortsetzung bezüglich sshPublicKey.

    Schroeffu · 23. Januar 2020 um 23:37

    Danke für das positive Feedback 🙂

    Ich habe heute erfolgreich die Umstellung auf sshPrivateKey AD Attribut umgestellt. Die Screenshots bezüglich AD Schema Erweiterung liegen bereit zu verbloggen. Also, Teil 2 „sshPrivateKey“ kommt die Tage sobald ich etwas Zeit habe.

Kay · 22. Januar 2020 um 09:58

Moin,

ich habe mich gerade durch das tut gearbeitet. Geht!

Aber erst nach einer kleinen anpassung. Ich musste adcli in der version 9 installieren.
Das klappte nur mit den Sourcen von Debian. Keine Idee warum.
Die Fehler meldung hat besagt das ich falsche encryption nutzen.

Falls es wem anders auch so gehen sollte!

Gruß Kay!

    Schroeffu · 23. Januar 2020 um 23:44

    Hey Kay,

    die exakte Fehlermeldung hast du nicht mehr? Würde mich interessieren. Debian 10? Oder älter?

    So oder so Danke für den Tipp, hilft bestimmt den Debian’ern unter uns.

Karsten · 3. Februar 2020 um 11:31

Servus Schroeffu,

wirklich hilfreicher Blog. Zum Thema sshPublicKey bin ich schon sehr auf deinen Blog gespannt. Die Erweiterung des AD Schema hab ich bereits. Leider fehlt mir der richtige Ansatz was linux-seitig zu konfigurieren ist.

Grüße, Karsten 🙂

    Schroeffu · 4. Februar 2020 um 16:23

    Hey Karsten, wenn du das AD Attribut „sshPublicKey“ schon hast, ist dein SSSD schon PublicKey-Login fähig. SSSD sucht automatisch im AD nach dem Attribut „sshPublicKey“, falls das Attribut einen anderen Namen hat kann man das in sssd.conf nachtragen mit: ldap_user_ssh_public_key = sshPublicKeyExtraAttributXYZ

    Als erste Prüfung, obs klappen sollte, kannst du mit dem Command Line Befehl „sss_ssh_authorizedkeys ADUSERNAME“ auf einem Server mit SSSD nach dem Public Key des jeweiligen Accounts abfragen. Die Antwort darauf ist der jeweilige Public Key aus dem Attribut dieses AD-Users.

    Wenn keine Antwort kommt, hat der User a) kein Public Key hinterlegt, b) das Attribut (Schema Attribut Editieren) > Eigenschaften fehlt noch „[x] Attribut in den globalen Katalog replizieren“. Bei letzterem hilft es den lokalen SSSD AD Cache löschen mit „sss_cache -E“. Aber der 2. Login klappt dann wieder nicht mehr. Daher ist es am Einfachsten, gleich das Attribut in den globalen Katalog zu replizieren.

    Als letztes nur noch in /etc/ssh/sshd_config nachtragen, dass jetzt auch ein PublicKey notwendig ist:

    PubkeyAuthentication yes

    oder AD PW + Key:

    AuthenticationMethods publickey,password

    That’s all.

Christian · 24. Februar 2020 um 16:21

Hallo,
erstmal danke für den tollen Artikel.

Ich hab mal eine grundsätzliche Frage (hoffe hab das nicht überlesen):
Kann sssd einzeln nur für den Auth (von z.b. Ubuntu Desktop) an das AD auch genutzt werden ? oder ist ein join in die Domain immer notwendig?

Aendu · 6. November 2020 um 22:19

Was muss den in der sshd_config bei Kerberos und GSSAPI konfiguriert sein?

Hans · 22. Dezember 2020 um 08:33

Hallo,

ich bins wieder, Hans. Das Setup anhand dieses Tutorials steht weiterhin und funktioniert zuverlässig. Ich wollte nun darauf aufbauen und per Samba einige Webshares an AD-User einrichten. Leider funktioniert das nicht wie gedacht. Ich kann problemlos per „net ads“ AD-User und Gruppen aus dem AD abfragen, richte ich aber Shares für User ein, erhalte ich im Log nur Fehlermeldungen wie NT_STATUS_TRUSTED_RELATIONSHIP_FAILURE oder NT_STATUS_NO_LOGON_SERVERS
Angeblich haben das manche geschafft es so einzurichten(https://serverfault.com/questions/614171/share-folder-with-realmd-sssd-and-ad-integration). Denkst du hier wäre ein weiteres Aufbaututorial möglich oder denkst du dies ist ein Fall, der nur per Winbind zu lösen wäre? Danke für deine Meinung.

Danke,
Hans

Kai · 15. Februar 2021 um 11:30

Toller Artikel und ein funktionales Setup.

Wie verhält es sich mit im AD deaktivierten Benutzern, die einen PublicKey hinterlegt haben.
Können sich diese immer noch über den Key authentifizieren und haben weiterhin Zugriff auf den Server?

VG Kai

    Schroeffu · 18. Februar 2021 um 14:43

    Hi Kai,

    sssd cachet die Benutzer einige Stunden, wie lange kann man einstellen. Spätestens nach dem Ende des Cachings wird der Zugriff für deaktivierte Benutzer nicht mehr möglich sein. Damit es nicht nur theoretisch so wäre würde ich das empfehlen einmal selbst zu testen. mit „sss_cache -u user1“ kann man den Cache des benutzers vorzeitig weglöschen. Alternativ alle User im Cache putzen mit „sss_cache -E“

    Viele Grüsse!

Claudio · 18. Februar 2021 um 07:46

Hi Schroeffu, tolles tutorial, hat bei mir ohne Weiteres auf ubuntu 20.04 klasse funktioniert.
Du ahnst gar nicht, wie lange ich nach einer solchen Anleitung gesucht habe, die ohne weitere Recherchen/Änderungen klappt -DANKE!

    Schroeffu · 18. Februar 2021 um 14:45

    Gerne 🙂 Danke fürs Feedback. Leider bin ich bei Google auch zu Linux-Themen kaum noch höher gerankt, da ich sehr wenig blogge in letzter Zeit. Das mag Google irgendwie gar nicht 🙂

Tommy · 12. März 2021 um 15:00

Moin Schroeffu,
danke für den Tipp mit deinem Tutorial! Als alter Windows-Admin brauche ich solche HowTos, die man auch nachvollziehen kann, wenn man kein Linux-Admin ist.

Was bei mir jedoch nicht funktionierte, war der Eintrag computer-ou in der realmd.conf. Angeblich nicht auffindbar gewesen. Als ich das Computerkonto per Hand angelegt habe, hieß es, es sei woanders als gedacht. Naja, der Hinweis, dass man das Setting auch weglassen könne, war Gold wert! Server ging direkt in die Standard-OU computers und alles war gut! 🙂 Evtl. gibt es für das setting ja eine Zeichenbegrenzung? Der LDAP-Pfad in den der Server sollte, ist bei uns (aktuell noch) leider ziemlich lang.

Danke nochmal und bis danach dann!

MfG
Tommy

Matthias · 1. Juli 2021 um 11:20

Hallo Schroeffu,

danke für die super Anleitung, manuell habe ich die Anbindung problemlos durchführen können. Ich musste nur einen zusätzlichen LDAP Search Filter für die Gruppen hinzufügen, da es sonst bei der Anmeldung zu Performanceproblemen aufgrund der Anzahl unserer AD-Gruppen kam.

Nachdem du die Anleitung aus Ansible abgeleitet hast … Hast du eine Möglichkeit das Playbook zur Verfügung zu stellen? Dann müsste ich das Rad nicht neu erfinden 😉

    Claudio · 1. Juli 2021 um 12:14

    Hi Matthias,
    kannst Du bitte die Syntax für Deinen LDAP search filter mit angeben?
    Danke Claudio

      Matthias · 2. Juli 2021 um 14:18

      Hi Claudio,
      relativ einfach, in der sssd.conf
      ldap_group_search_base = OU=Global,OU=Groups,DC=example,DC=com?sub?(|(cn=linux_admin)(cn=linux_admin_sudo))

        Claudio · 2. Juli 2021 um 14:38

        Danke Matthias, direkt erfolgreich getestet 🙂

    Schroeffu · 7. Juli 2021 um 17:44

    Hi Matthias,

    hier eine Kopie meines produktiven Playbooks, einige Einträge sind natürlich um Namen/Bezeichnungen neutralisiert worden. Voilà: https://seafile.schroeffu.ch/d/2d51829bf48249848775/

    have fun 🙂

    all the best
    Schroeffu

Schreibe einen Kommentar

Avatar-Platzhalter

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert