Begrenzter Domänenzugriff per Managed Service Account
Minimalprinzip
Veröffentlicht in Ausgabe 03/2022 - PRAXIS
Es ist allgemein bekannt, dass Linux-Systeme Teil einer Active-Directory-(AD)-Domäne sein können und somit eine Anmeldung am Linux-System mit einem Benutzerkonto aus dem AD erfolgen kann. Der System Security Services Daemon (SSSD) [1] stellt mit dem AD-Provider [2] ein eigenes Modul für diesen Zugriff zur Verfügung.
Unterschiedliche Vertrauensstellungen
Existiert für das Linux-System ein Computerkonto in einer AD-Domäne, können Benutzer aus der lokalen Domäne, in der das Konto erzeugt wurde, auf Ressourcen des Linux-Systems zurückgreifen. Existieren in der Gesamtstruktur weitere Domänen, ist standardmäßig eine Vertrauensstellung zwischen diesen Domänen vorhanden, sodass Benutzer aus Domäne A auf Ressourcen der Domäne B zurückgreifen können und umgekehrt (two-way-trust). Diese Art von Vertrauensstellung wird auch als "transitive trust" bezeichnet.
Etwas komplizierter wird es allerdings, wenn eine Vertrauensstellung nur in eine Richtung existiert. Als Beispiel sollen die beiden AD-Domänen "prod.example.com" und "dev.example.com" dienen. Hier existiert lediglich eine einseitige Vertrauensstellung, wobei die dev-Domäne der prod-Domäne vertraut, die prod-Domäne allerdings der dev-Domäne nicht. Somit können Benutzer der prod-Domäne auf Ressourcen der dev-Domäne zurückgreifen, umgekehrt ist dies nicht der Fall. Ist nun ein Linux-System Teil der dev-Domäne, bleibt dieses System bei Ressourcen der prod-Domäne außen vor. Das gleiche Problem tritt natürlich auch dann auf, wenn lediglich eine einseitige Vertrauensstellung zwischen zwei Gesamtstrukturen einer AD-Landschaft existiert.
Es ist allgemein bekannt, dass Linux-Systeme Teil einer Active-Directory-(AD)-Domäne sein können und somit eine Anmeldung am Linux-System mit einem Benutzerkonto aus dem AD erfolgen kann. Der System Security Services Daemon (SSSD) [1] stellt mit dem AD-Provider [2] ein eigenes Modul für diesen Zugriff zur Verfügung.
Unterschiedliche Vertrauensstellungen
Existiert für das Linux-System ein Computerkonto in einer AD-Domäne, können Benutzer aus der lokalen Domäne, in der das Konto erzeugt wurde, auf Ressourcen des Linux-Systems zurückgreifen. Existieren in der Gesamtstruktur weitere Domänen, ist standardmäßig eine Vertrauensstellung zwischen diesen Domänen vorhanden, sodass Benutzer aus Domäne A auf Ressourcen der Domäne B zurückgreifen können und umgekehrt (two-way-trust). Diese Art von Vertrauensstellung wird auch als "transitive trust" bezeichnet.
Etwas komplizierter wird es allerdings, wenn eine Vertrauensstellung nur in eine Richtung existiert. Als Beispiel sollen die beiden AD-Domänen "prod.example.com" und "dev.example.com" dienen. Hier existiert lediglich eine einseitige Vertrauensstellung, wobei die dev-Domäne der prod-Domäne vertraut, die prod-Domäne allerdings der dev-Domäne nicht. Somit können Benutzer der prod-Domäne auf Ressourcen der dev-Domäne zurückgreifen, umgekehrt ist dies nicht der Fall. Ist nun ein Linux-System Teil der dev-Domäne, bleibt dieses System bei Ressourcen der prod-Domäne außen vor. Das gleiche Problem tritt natürlich auch dann auf, wenn lediglich eine einseitige Vertrauensstellung zwischen zwei Gesamtstrukturen einer AD-Landschaft existiert.
Das zu lösende Problem besteht primär darin, dass der Linux-Host einen sicheren Zugriff auf den Domänencontroller der vertrauten Domäne benötigt. Dies ist deshalb notwendig, da der Verzeichnisdienst des Domänencontrollers sämtliche Objekte, also auch die Benutzer-, Gruppen- und Host-Objekte, der AD-Domäne vorhält. Der System Security Services Daemon verwendet für diesen Zugriff den Kerberos-Principal-Namen des Hosts.
Dieser ist zusammen mit dem Passwort lokal in einer Keytab-Datei gespeichert und natürlich auch dem Domänencontroller der lokalen Domäne bekannt. Wenn sich der Linux-Host nun aber in einer nicht vertrauten (trusted) Domäne befindet, wird eine Authentifizierung mit dem Host Principal am Domänencontroller der vertrauten Domäne nicht erfolgreich sein, und somit eine Abfrage des Verzeichnisdienstes fehlschlagen.
Um dies zu adressieren, scheint es ein einfacher Ansatz zu sein, Linux-Systeme einfach auch in die vertraute Domäne aufzunehmen. Dies ist allerdings aus mehreren Gründen nicht empfehlenswert – unter anderem auch deshalb, weil Microsoft eindeutige Hostnamen innerhalb einer Gesamtstruktur empfiehlt, wenn zwischen den Domänen dieser Struktur Vertrauensstellungen existieren.
AD Managed Service Accounts
Tatsächlich besteht die eigentliche Lösung darin, in der gewünschten Domäne einen Service-Account anzulegen, mit dessen Hilfe ein Zugriff vom Linux-System auf den Verzeichnisdienst der Domäne erfolgen kann. Natürlich muss dieser ebenfalls lokal auf dem System in einer Keytab-Datei zur Verfügung stehen.
An dieser Stelle ist es wichtig zu erwähnen, dass jedoch kein regulärer Service-Account zum Einsatz kommen sollte, der dann mit dem Linux-System verknüpft wird, da dieser Ansatz nicht wirklich sicher wäre. Zum einen wäre ein großes Problem, dass das Passwort von solchen Accounts oftmals nicht regelmäßig geändert wird, und zum anderen ist es auch sehr leicht möglich, das Passwort für so einen Service-Account aus der Registry auszulesen.
Stattdessen sollte also besser ein sogenannter Managed Service Account (MSA) zum Einsatz kommen [3]. Für diese Art von Konto werden die Passwörter standardmässig alle 30 Tage automatisch neu generiert und es ist auch nicht möglich, diese aus der Registry auszulesen.
Mit adcli einen MSA erzeugen
Das Tool adcli [4] kommt gerne auf Linux-Systemen zum Einsatz, um bestimmte Operationen auf einem AD-System durchzuführen. Beispielsweise können Sie hiermit Benutzer oder Gruppen anlegen oder auch wieder löschen. Seit der Version 0.9.1 [5] unterstützt das Tool nun ebenfalls das Setup von Managed Service Accounts. Um also einen MSA in der Domäne "prod.example.com" anzulegen, verwenden Sie den folgenden Befehl:
adcli create-msa --domain=prod.example.com --login-user Administrator
Das Tool erzeugt dann den gewünschten Account in der angegebenen Domäne und speichert das Passwort lokal in einer Keytab-Datei. Diese lesen Sie bei Bedarf mit dem folgenden Kommando aus:
klist -k /etc/krb5.keytab.prod.example.com
Der Kerberos Principal Name des Managed Service Account ist identisch mit dem Hostnamen. Dieser wird allerdings um einen zufälligen Suffix erweitert. Somit ist die Eindeutigkeit von Hostnamen innerhalb einer AD-Gesamtstruktur sichergestellt. Weitere Informationen zu adcli und welche Optionen im Zusammenhang mit MSAs zur Verfügung stehen, finden Sie in der Hilfeseite von adcli unter [6].
SSSD-Konfiguration
An dieser Stelle gehen wir davon aus, dass das Linux-System bereits Teil der Domäne "dev.example.com" ist. Sollte dies nicht der Fall sein, können Sie mit Hilfe des Tools realmd [7] das System ganz einfach in die gewünschte Domäne aufnehmen.
In der SSSD-Konfigurationsdatei müssen Sie dann nur noch den soeben erzeugten MSA hinterlegen, sodass eine Anmeldung am Domänencontroller der Domäne "prod.example.com" stattfinden kann. Wie diese im Detail auszusehen hat, hängt davon ab, ob die Domäne, in der Sie den MSA erzeugt haben, sich in der lokalen Gesamtstruktur befindet oder Teil einer Struktur ist, zu der lediglich eine einseitige Vertrauensstellung existiert.
Listing 1: SSSD-Setup innerhalb der Gesamtstruktur
SSSD-Setup für einen Managed Service Account aus einer Domäne innerhalb einer entfernten Gesamtstruktur.
[domain/lab.example.com/prod.example.com]
ldap_sasl_authid = CLIENT!Z1B$@PROD.EXAMPLE.COM
ldap_krb5_keytab = /etc/krb5.keytab.prod.example.com
krb5_keytab = /etc/krb5.keytab.prod.example.com
ad_domain = prod.example.com
krb5_realm = PROD.EXAMPLE.COM
access_provider = ad
Für den ersten Fall müsste die zusätzliche Konfiguration wie in Listing 1 dargestellt aussehen. Listing 2 zeigt die korrekten Anweisung für den Fall, dass die Domäne nicht Teil der lokalen Gesamtstruktur ist.
Listing 2: SSSD-Setup außerhalb der Gesamtstruktur
SSSD-Setup für einen Managed Service Account aus einer Domäne außerhalb einer entfernten Gesamtstruktur.
[domain/prod.example.com]
ldap_sasl_authid = CLIENT!Z1B$@PROD.EXAMPLE.COM
ldap_krb5_keytab = /etc/krb5.keytab.prod.example.com
krb5_keytab = /etc/krb5.keytab.prod.example.com
ad_domain = prod.example.com
krb5_realm = PROD.EXAMPLE.COM
access_provider = ad
Fazit
Mithilfe von Managed Service Accounts erhält der SSSD Zugriff auf Ressourcen von Domänen, in denen Sie kein Computerkonto für ein Linux-System anlegen können oder wenn der Zugriff auf Domänen notwendig ist, zu denen lediglich eine einseitige Vertrauensstellung besteht. Anders als reguläre Service Accounts bietet ein MSA eine wesentlich höhere Sicherheit. So können die Passwörter nicht aus der Registry ausgelesen werden
(dr)
Link-Codes
[1] SSSD Projektseite: https://sssd.io/
[2] SSSD AD-Provider: https://sssd.io/docs/ad/ad-provider.html/
[3] Managed Service Accounts: https://docs.microsoft.com/de-de/windows-server/security/group-managed-service-accounts/getting-started-with-group-managed-service-accounts/
[4] adcli Projektseite: https://www.freedesktop.org/software/realmd/adcli/adcli.html/
[5] adcli release 0.9.1: https://gitlab.freedesktop.org/realmd/adcli/-/releases#0.9.1/
[6] adcli man page: https://gitlab.freedesktop.org/realmd/adcli/-/blob/master/doc/adcli.xml
[7] realmd Projektseite: https://www.freedesktop.org/software/realmd/docs/guide-active-directory.html/