Direkte Verknüpfung von RHEL- oder anderen Linux-Rechnern mit Microsoft Active Directory

4. August 2023Jason Nagin8 Minuten (Lesedauer)

Die Verwaltung des Zugriffs auf Systeme in Ihrem Netzwerk kann eine Herausforderung darstellen. Dabei können Administratorinnen und Administratoren unterschiedlich vorgehen: Einige erstellen alle Benutzer auf allen Rechnern, andere geben Konten mit SSH-Schlüsseln oder sogar Passwörtern frei, und wieder andere verwenden die LDAP-Bindung (manchmal unter Verwendung der vorhandenen Active Directory-Infrastruktur, manchmal unter Verwendung einer separaten Domain), wobei sie LDAP-Abfragen zum Filtern des Zugriffs schreiben müssen.

Diese verschiedenen Methoden erschweren die Verwaltung des Zugriffs auf die Rechner und erfordern, dass die Admins informiert werden, wenn eine Person ein Team verlassen hat oder neu dazu gekommen ist. Bei geteilten Konten kann das Logging größtenteils nutzlos werden, da alle den gleichen Benutzernamen haben. Ich bin wahrscheinlich nicht der Einzige, der schlechte Erfahrungen damit gemacht hat, dass die Personalabteilung technische Teams informiert, wenn sich ein Team ändert. Für diese Probleme gibt es allerdings eine Lösung, die gut funktioniert und sich in gängige Unternehmens-Setups integrieren lässt.

Die meisten Unternehmen, die ich kenne, haben ein ERP-System, das Benutzerkonten automatisch in Microsoft Active Directory (AD) erstellt, deaktiviert oder löscht. So kann man von der Arbeit anderer profitieren. Beispielsweise kann SSSD eine direkte Verbindung zu AD herstellen.

Wenn Sie jemals einen Authentifizierungsserver für Linux eingerichtet haben, der einen Trust zu AD hatte, wissen Sie, wie SSSD mit Ihren AD-Servern kommuniziert. Wenn Sie sich ansehen wie ein Trust funktioniert, gibt der von Ihnen eingerichtete Authentifizierungsserver einen Verweis an die AD-Server zurück, was dazu führt, dass SSSD Ihre AD-Server direkt abfragt. Im folgenden Setup ist kein zusätzlicher Authentifizierungsserver erforderlich, und SSSD wird so konfiguriert, dass es zuerst direkt mit AD verbunden ist.

Die nächste Frage ist in der Regel, wie der Zugriff kontrolliert wird. Hier kommt Role-Based Access Control (RBAC) ins Spiel. Mit RBAC können Sie die Zuweisung des Zugriffs an Benutzer beenden und mit der Zuweisung des Zugriffs an Rollen beginnen. Nachdem Sie die Gruppen angelegt haben, können Sie einem Team ein neues Teammitglied zuweisen, das bereits Teil der Rolle mit entsprechendem Zugriff auf eine Gruppe von Servern ist. Anfragen vom Typ „Ich wurde gerade eingestellt und benötige denselben Zugriff wie X“, die auf eine Person verweisen, die das Unternehmen vor Monaten eingestellt hat und deren gesamte Zugriffsrechte gelöscht wurden, werden dabei entfernt.

Sobald Sie den neuen Nutzenden zur Gruppe seines Teams hinzufügen, hat er den erforderlichen Zugriff. Auch die Entdeckung, dass jemand, der das Unternehmen vor über einem Jahr verlassen hat, immer noch Zugang zu allen Servern hat, weil niemand dem Administrationsteam mitgeteilt hat, dass diese Person das Unternehmen verlassen hat, ist damit vom Tisch. Wenn das ERP-System das entsprechende AD-Konto automatisch aktualisiert, verlieren sie sämtlichen Zugriff.

Die Verwaltung von AD mit anderen Betriebssystemen als Windows war früher eine Herausforderung. Microsoft hat jedoch das Windows Admin Center veröffentlicht, sodass Sie direkt über einen Browser, der auf einem beliebigen Betriebssystem ausgeführt wird, auf Active Directory-Nutzende und -Computer zugreifen können. Darüber hinaus gewährt es Zugriff auf verschiedene andere Windows-Managementtools. Wenn Sie es auf einem Windows-Server installieren, müssen Sie sich keine Gedanken über Session-Limits oder Probleme mit RemoteApp machen. Sie starten einfach einen Browser und greifen auf die Weboberfläche zu.

Konfigurieren von AD-Gruppen für Role-Based Access Control

Das Benennungsschema Ihres Unternehmens kann von den Beispielen in diesem Artikel abweichen. Die Gruppennamen sind nicht wichtig. Der wesentliche Teil ist der Verwendungszweck der einzelnen Gruppen.

Da SSSD keine AD-Gruppen synchronisiert, sondern nur eine Liste von Gruppen abruft, in denen der Nutzende während des Anmeldevorgangs Mitglied ist, verhindern fehlende Gruppen nicht, dass dieses Setup funktioniert. Wenn Sie jedoch mehrere Teams mit delegierten Berechtigungen innerhalb von AD haben, sollten Sie alle Gruppen erstellen. So können Sie verhindern, dass sie in der falschen Organisationseinheit (OE) erstellt werden und die Zugriffskontrolle an das falsche Team weitergegeben wird.

Zugriff auf bestimmte Rechner

Erstellen Sie 2 Gruppen in Active Directory für jeden Rechner. Beide Gruppen müssen den Kurznamen des Rechners enthalten.

Eine Gruppe ist für den rechnerspezifischen SSH-Zugriff (im Folgenden als Machine_SSH_Access bezeichnet).

Die andere Gruppe bietet rechnerspezifischen sudo-Zugriff (im Folgenden als Machine_SUDO_Access bezeichnet).

Beispiele für Gruppenformate:

<DOMAIN> Linux <hostname> ssh access
<DOMAIN> Linux <hostname> sudo access

<hostname> ist der Kurzname des Rechners.
<DOMAIN> ist der Kurzname Ihrer Domain und ist optional.

Zugriff auf alle Rechner

Erstellen Sie 2 Gruppen in Active Directory für den globalen Rechnerzugriff.

Eine der Gruppen ist für den SSH-Zugriff (im Folgenden als Global_SSH_Access bezeichnet) auf alle Rechner vorgesehen.

Die andere ist für den sudo-Zugriff (im Folgenden als Global_SUDO_Access bezeichnet) auf alle Rechner.

Beispiele für Gruppenformate:

<DOMAIN> Linux ssh access
<DOMAIN> Linux sudo access

<DOMAIN> ist der Kurzname Ihrer Domain und ist optional.

Verschachtelung

Eine Verschachtelung innerhalb der AD-Gruppen ist zulässig. Wenn Sie eine Gruppe mit Zugriff auf mehrere Rechner erstellen möchten, müssen Sie die Konfiguration auf den RHEL-Rechnern nicht ändern. Stattdessen können Sie die neue Gruppe zu einem Mitglied der Zugriffsgruppe für die jeweiligen Rechner machen. Mit diesem Ansatz können Sie den Zugriff direkt in AD steuern.

Beispiel für Verschachtelung:

CONTOSO Linux Webserver1 ssh access
- CONTOSO Linux Webservers ssh access
  - CONTOSO Web Developers
    - User1
    - User2

Mit dieser Verschachtelung können Sie Gruppen von Rechnern (CONTOSO Linux Webservers ssh access) statt Nutzenden bestimmter Systeme Rollen (CONTOSO Web Developers) zuweisen.

Verbindung Ihres Linux-Rechners mit einer Domain

Wenn in Ihrer Umgebung derzeit RC4 aktiviert ist, befolgen Sie die Sicherheitshinweise von Microsoft, und deaktivieren Sie es jetzt.

So verbinden Sie einen Linux-Rechner mit einer Domain:

Installieren Sie die erforderlichen Pakete:

$ sudo dnf install -y chrony krb5-workstation \
samba-common-tools oddjob-mkhomedir samba-common \
sssd authselect

Fügen Sie die CA-Kette Ihrer Domain hinzu, indem Sie /etc/sssd/pki/sssd_auth_ca_db.pem erstellen und die CA-Kette Ihrer Domain schreiben. Das Zertifikat für die Domain Controller (DC) selbst muss jedoch nicht eingeschlossen werden. Es kann mit dem Zertifikat beginnen, das ihre Zertifikate signiert hat.
Fügen Sie den Vertrauensankern des Systems die CA-Kette hinzu:

$ sudo trust anchor /etc/sssd/pki/sssd_auth_ca_db.pem

Konfigurieren Sie SSSD, indem Sie /etc/sssd/sssd.conf oder /etc/sssd/conf.d/<DOMAIN>.conf bearbeiten und die folgenden Zeilen abgleichen.

Das Bearbeiten von /etc/sssd/conf.d/<DOMAIN>.conf ist die moderne und bevorzugte Methode, aber das Bearbeiten von /etc/sssd/sssd.conf funktioniert auch.

[domain/<DOMAIN>]
access_provider = simple
auth_provider = ad
chpass_provider = ad
id_provider = ad
dyndns_update = true
override_homedir = /home/%u
override_shell = /bin/bash
default_shell = /bin/bash
ldap_idmap_range_size = 4000000
cache_credentials = true
simple_allow_groups = Global_SSH_Access, Global_SUDO_Access, Machine_SSH_Access, Machine_SUDO_Access
ignore_group_members = true
ad_gpo_access_control = disabled
ad_enable_gc = false
ad_use_ldaps = true
[sssd]
services = nss, pam
config_file_version = 2
domains = <DOMAIN>

<DOMAIN>ist der FQDN Ihrer Domain in GROSSBUCHSTABEN. Wenn Sie nicht ausschließlich Großbuchstaben verwenden, können Authentifizierungsprobleme auftreten.
ldap_idmap_range_size ist optional. Dies ist bei einer großen AD-Umgebung erforderlich. Wenn Sie diesen Wert ändern, ändert sich der UID-Hash. Sie sollten ihn daher nicht ändern, nachdem der Rechner der Domain beigetreten ist, und sicherstellen, dass auf allen Rechnern derselbe Wert verwendet wird.
Global_SSH_Access, Global_SUDO_Access, Machine_SSH_Access und Machine_SUDO_Access sind die AD-Gruppen, die Sie oben für RBAC erstellt haben.

Legen Sie die Berechtigungen für die soeben erstellte Datei fest: /etc/sssd/sssd.conf oder /etc/sssd/conf.d/<DOMAIN>.conf:

$ sudo chmod 400 /etc/sssd/sssd.conf

oder

$ sudo chmod 400 /etc/sssd/conf.d/*.conf

Konfigurieren Sie KRB5, indem Sie /etc/krb5.conf bearbeiten und diese Zeilen abgleichen:

[logging]
default = FILE:/var/log/krb5libs.log
kdc = FILE:/var/log/krb5kdc.log
admin_server = FILE:/var/log/kadmind.log
[libdefaults]
dns_lookup_realm = true
dns_lookup_kdc = true
ticket_lifetime = 24h
renew_lifetime = 7d
forwardable = true
rdns = true
default_ccache_name = KEYRING:persistent:%{uid}
default_realm = <DOMAIN>
[realms]
[domain_realm]

Sie müssen keine Angaben unter [realms] oder [domain_realm] machen. SSSD ermittelt diese Informationen automatisch aus dem DNS.

Konfigurieren Sie den SUDO-Zugriff, indem Sie eine -Datei in /etc/sudoers.d

$ sudo visudo -f /etc/sudoers.d/<DOMAIN>

Legen Sie den standardmäßigen sudo-Zugriff für Mitglieder der sudo-Gruppen von AD fest. Der Dateiname kann beliebig gewählt werden und muss nicht DOMAIN heißen.

Sie müssen alle Leerzeichen mit einem umgekehrten Schrägstrich (\) maskieren. Beispielsweise muss „Linux sudo access“ als „Linux\ sudo\ access“ geschrieben werden.

%Global_SUDO_Access  ALL=(ALL) ALL
%Machine_SUDO_Access  ALL=(ALL) ALL

Global_SUDO_Access und Machine_SUDO_Access sind die AD-Gruppen, die Sie für RBAC erstellt haben. Das Prozentzeichen (%) vor dem Gruppennamen gibt an, dass es sich um eine Gruppe handelt.

Jeder andere sudo-Zugriff, den Sie AD-Gruppen gewähren möchten, kann auf dieselbe Weise in separaten Dateien oder in derselben Datei definiert werden.

Stellen Sie sicher, dass der Hostname des Rechners auf den FQDN festgelegt ist. Der Hostname des Rechners darf nicht der Kurzname sein:

$ sudo hostnamectl set-hostname $(hostname -f)

Verbinden Sie den Rechner mit einem der folgenden Befehle (adcli ist kompatibel mit SMBv1 und SMBv2). Verwenden Sie den folgenden Befehl, um die Betriebssysteminformationen in AD während des Beitritts festzulegen:

$ source /etc/os-release
$ sudo adcli join -U <join_user> --os-name="${NAME}" \
--os-version="${VERSION}" --os-service-pack="${VERSION_ID}"

Alternativ können Sie beitreten, ohne die Betriebssysteminformationen festzulegen:

$ sudo adcli join -U <join_user>

<join_user> ist das AD-Konto, das verwendet wird, um den Rechner mit der Domain zu verbinden. Das von adcli angeforderte Passwort wird nicht gespeichert. Delegated Permissions beschreibt die für den Beitritt erforderlichen Berechtigungen.

Aktivieren und starten Sie SSSD und oddjobd:

$ sudo systemctl enable sssd oddjobd
$ sudo systemctl restart sssd oddjobd

Aktivieren Sie die Anmeldung mit AD:

$ sudo authselect select sssd with-mkhomedir --force

Solange Ihr Konto Mitglied einer der von Ihnen erstellten Gruppen ist, können Sie sich jetzt beim Rechner anmelden. Sie müssen die Domain nicht angeben. Die als default_realm in /etc/krb5.conf angegebene Domain wird verwendet. GNOME erfordert möglicherweise einen Neustart, aber sshd akzeptiert die Änderungen normalerweise ohne Neustart.

Aktualisieren der Betriebssysteminformationen

Standardmäßig ist das Objekt „computer“ nicht berechtigt, die eigenen Betriebssysteminformationen zu aktualisieren. Gehen Sie zu Active Directory Users and Computers (ADUAC) und gewähren Sie SELF die Möglichkeit, alle Betriebssystemfelder der Computerobjekte zu schreiben (dies ist auf OU-Ebene möglich). Aktualisieren Sie das AD-Objekt nach dem Hinzufügen mit den neuesten Betriebssysteminformationen:

$ source /etc/os-release
$ sudo /usr/sbin/adcli update --os-name="${NAME}" \
--os-version="${VERSION}" --os-service-pack="${VERSION_ID}"

Dies kann als ein Cron-Job oder als ein systemd-Service hinzugefügt werden. Beispiel:

[Unit]
Description=Updates AD with current OS information
After=sssd.service
[Service]
Type=oneshot
EnvironmentFile=/etc/os-release
ExecStart=/usr/sbin/adcli update --os-name="${NAME}" --os-version="${VERSION}" --os-service-pack="${VERSION_ID}"
[Install]
WantedBy=multi-user.target

Aktivieren der Smartcard-Authentifizierung

In diesem Abschnitt wird davon ausgegangen, dass auf Ihren Windows-Rechnern die Smartcard-Authentifizierung funktioniert. Konfigurieren Sie andernfalls die Smartcard-Authentifizierung auf einem Windows-Rechner, bevor Sie fortfahren.

Schreiben Sie die Zertifikatskette für Ihre Domain in /etc/sssd/pki/sssd_auth_ca_db.pem. Das Zertifikat für die Domain Controller (DC) selbst muss jedoch nicht eingeschlossen werden. Es kann mit dem Zertifikat beginnen, das ihre Zertifikate signiert hat.
Fügen Sie das Zertifikat zur Liste der vertrauenswürdigen Zertifizierungsstellen des Rechners hinzu:

$ sudo trust anchor /etc/sssd/pki/sssd_auth_ca_db.pem

Bearbeiten Sie /etc/sssd/sssd.conf oder /etc/sssd/conf.d/<DOMAIN>.conf, je nachdem, welche Datei Sie verwendet haben, als Ihre Domain Ihrem System beigetreten ist, und fügen Sie die folgende Zeile im Abschnitt [domain/<DOMAIN>] ein. Dieser Eintrag teilt SSSD mit, wo nach dem Benutzerzertifikat gesucht werden soll. Windows verwendet das Attribut userCertificate. Wenn wir also dasselbe Attribut verwenden, funktioniert dieselbe Smartcard unter Linux und Windows.

ldap_user_certificate = userCertificate;binary

Fügen Sie diese Zeilen am Ende derselben Konfigurationsdatei hinzu:

[pam]
pam_cert_auth = true

Bearbeiten Sie /etc/krb5.conf, und fügen Sie die folgenden Zeilen unter [realms] hinzu. Ersetzen Sie dabei <DOMAIN> durch den FQDN Ihrer Domain in GROSSUCHSTABEN. Hiermit soll eine Abweichung behoben werden, die auftreten kann, weil Windows im Gegensatz zu Linux die Groß-/Kleinschreibung nicht beachtet.

<DOMAIN> = {
pkinit_anchors = DIR:/etc/sssd/pki
  pkinit_kdc_hostname = <DOMAIN>
}

Verwenden Sie einen der folgenden Befehle, um die Smartcard-Authentifizierung in PAM zu aktivieren:

authselect enable-feature with-smartcard: Smartcard-Authentifizierung als Option zulassen.
authselect enable-feature with-smartcard-required: Erfordert Smartcard-Authentifizierung. Bei der Authentifizierung mit SSH-Schlüsseln ruft sshd standardmäßig keine PAM auf.
authselect enable-feature with-smartcard-lock-on-removal: Erfordert die Smartcard-Authentifizierung und sperrt das System, wenn die Smartcard entfernt wird.

Aktivieren des SSH-Zugriffs mit dem Smartcard-Zertifikat

Bei RHEL 8 und höher können Sie den SSH-Zugriff mit einer Smartcard aktivieren.

Überprüfen Sie, ob das Smartcard-Zertifikat ordnungsgemäß von AD gelesen wurde:

sss_ssh_authorizedkeys ${USER}

Wenn kein Public Key zurückgegeben wird, überprüfen Sie, ob die Smartcard-Authentifizierung ordnungsgemäß konfiguriert ist.

Bearbeiten Sie /etc/ssh/sshd_config, um diese Zeilen hinzuzufügen:

AuthorizedKeysCommand /usr/bin/sss_ssh_authorizedkeys
AuthorizedKeysCommandUser nobody

Starten Sie sshd neu:

$ sudo systemctl restart sshd

Verwenden Sie die Option PKCS11Provider=/usr/lib64/opensc-pkcs11.so, um sich über einen Client mit SSH anzumelden. Solange die Smartcard mit einem Public Key für den Benutzer übereinstimmt, werden Sie aufgefordert, die Smartcard-PIN oder das Passwort einzugeben:

$ ssh -o PKCS11Provider=/usr/lib64/opensc-pkcs11.so <host>

Weitere Informationen

Sie haben jetzt einen Rechner, der mit einer Domain verbunden ist und mit Role-based Access Control kontrolliert, wer sich anmelden oder privilegierte Befehle ausführen kann. Das Management wird in kurzer Zeit einfacher, weil man sich die Arbeit zunutze machen kann, die andere bereits leisten. Beachten Sie Folgendes:

Durch das Deaktivieren eines Nutzenden in AD wird der Zugriff auf den Rechner sofort gesperrt. Genau wie bei Windows bleibt jeder, der bereits angemeldet ist, angemeldet.
Änderungen an den Gruppen des Nutzenden werden genau wie bei Windows während der Anmeldung aktualisiert. Dies geschieht, bevor geprüft wird, ob sie sich anmelden dürfen.
SSSD ist standortabhängig. Wenn Sie Sites innerhalb von AD Sites and Services konfigurieren, stellt SSSD eine Verbindung zum entsprechenden DC her.
SSSD rotiert das Rechnerpasswort automatisch.
Solange dynamische Updates (sicher oder unsicher) aktiviert sind, erstellt und verwaltet SSSD automatisch DNS-Einträge für einen Rechner.

Normalerweise rate ich davon ab, Windows-Tools zur Verwaltung von Linux-Systemen und Linux-Tools zur Verwaltung von Windows zu verwenden, da dabei normalerweise wichtige Funktionen verloren gehen, Sicherheit fehlt oder viel einfachere Möglichkeiten bestehen, dieselbe Aufgabe mit einem nativen Tool zu erledigen. Mit AD ist das allerdings anders. Die Entwicklerinnen und Entwickler von SSSD haben viele Anstrengungen unternommen, um die Kompatibilität mit AD zu gewährleisten, was Ihre Arbeit um einiges einfacher macht.