0800 71 20000
Kontakt
...
Server-Administration

Linux-Server ins Active Directory einbinden: Anmeldung mit AD-Konten

Für die meisten Umgebungen ist SSSD mit realmd der kürzeste Weg zur AD-Anmeldung, inklusive Kerberos und zwischengespeicherter Anmeldedaten. Winbind brauchst du nur noch in Sonderfällen, etwa bei engen Samba-Verzahnungen.

6 Kapitel mit allen Befehlen
Passende Kurse ansehen Persönlich beraten lassen
Administrator steckt ein Netzwerkkabel in einen Serverschrank
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Seit 1997 am Markt Präsenz & Live-Online 4,9 aus 503 Google-Bewertungen Auch Inhouse für dein Team
Worum es geht

Zwei Welten, eine Identität

Lokale Benutzerkonten auf Linux-Servern skalieren nicht. Sobald mehr als eine Handvoll Maschinen im Spiel ist, driften /etc/passwd und /etc/shadow auseinander, ausgeschiedene Mitarbeiter behalten Zugänge und das Passwort-Handling entzieht sich jeder zentralen Richtlinie. Das Active Directory ist in vielen Häusern die einzige Quelle, die Personalprozesse und Gruppenzugehörigkeiten sauber abbildet, also soll Linux dort andocken statt eine zweite Identitätsinsel aufzubauen.

Technisch ist der Beitritt kein Hexenwerk, aber er berührt mehrere Schichten gleichzeitig. Kerberos übernimmt die Authentifizierung, LDAP liefert die Kontodaten und die Auflösung von UID und GID, NSS und PAM binden das Ergebnis in die Anmeldung ein, und DNS entscheidet darüber, ob die Domänencontroller überhaupt gefunden werden. Fällt eine dieser Schichten aus, wirkt der Fehler oft an einer ganz anderen Stelle: Ein Zeitversatz von mehr als fünf Minuten sieht am Prompt schlicht wie ein falsches Passwort aus.

Typische Fehler wiederholen sich. Der Join wird per realm join gemacht, ohne vorher zu klären, wie UIDs entstehen, und beim zweiten Server bekommen dieselben Benutzer andere Nummern, was NFS-Freigaben unbrauchbar macht. Oder es wird kein ID-Mapping-Schema festgelegt, obwohl im AD bereits POSIX-Attribute gepflegt sind. Häufig fehlt außerdem eine Zugriffsbeschränkung, sodass nach dem Beitritt jedes Domänenkonto eine Shell auf dem Produktivsystem bekommt, und die sudo-Rechte bleiben weiter lokal in Dateien verstreut.

Miniatur-Szene: geöffneter Serverschrank mit Werkzeug, Patchpanel und grünem Uptime-Balken
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt

Vom Vorcheck zum produktiven AD-Login

  1. 01 Zeit, DNS und Kerberos prüfen
  2. 02 SSSD oder Winbind entscheiden
  3. 03 Domänenbeitritt per realm join
  4. 04 ID-Mapping vereinheitlichen
  5. 05 Login-Gruppen und sudo begrenzen
  6. 06 Offline-Betrieb und Notfallzugang testen
Was du mitnimmst

Der Weg zum sauberen Domänenbeitritt

Ein belastbarer Aufbau entsteht in einer festen Reihenfolge. Erst die Grundlagen prüfen, dann bewusst zwischen SSSD und Winbind entscheiden, danach Zugriff und Rechte einschränken und zum Schluss den Ausfall des Domänencontrollers durchspielen.

Grundlagen vor dem Join prüfen

Zeitsynchronisation über chrony gegen die Domänencontroller, korrekte DNS-Server im Resolver, saubere Vorwärts- und Rückwärtsauflösung sowie ein passender Hostname. Mit dig -t SRV _ldap._tcp.dc._msdcs.deine.domain und kinit benutzer@DEINE.DOMAIN siehst du in zwei Befehlen, ob Kerberos und DNS bereitstehen.

SSSD oder Samba-Winbind bewusst wählen

SSSD ist auf RHEL, Debian und SLES der Standard für reine Anmeldung, bringt Offline-Caching mit und lässt sich über realmd bequem beitreten. Winbind ist die richtige Wahl, wenn dieselbe Maschine auch als Samba-Fileserver mit NTFS-ACLs arbeitet, weil dort Domänen-SIDs und Dateirechte konsistent zusammenpassen müssen.

ID-Mapping planen statt dem Zufall überlassen

Entweder du nutzt POSIX-Attribute aus dem AD, dann liefert das Verzeichnis die verbindlichen UIDs und GIDs, oder du setzt auf den algorithmischen Bereich in sssd.conf beziehungsweise die idmap-Konfiguration von Winbind. Wichtig ist nur, dass alle Hosts dasselbe Verfahren mit identischen Bereichen verwenden, sonst brechen NFS und rsync über Systemgrenzen hinweg.

Zugriff und Rechte eingrenzen

Nach dem Beitritt schränkst du die Anmeldung über simple_allow_groups oder eine LDAP-Filterregel auf die tatsächlich berechtigten Gruppen ein. Die Administrationsrechte kommen über sudo-Regeln, die an AD-Gruppen hängen, idealerweise zentral verteilt über Ansible oder über die sudo-Integration von SSSD.

Home-Verzeichnisse und Anmeldekomfort regeln

pam_mkhomedir legt Verzeichnisse beim ersten Login an, alternativ kommen sie per NFS oder Autofs vom Fileserver. Über Kerberos-Tickets funktionieren Single Sign-on per SSH mit GSSAPI und der Zugriff auf CIFS-Freigaben ohne erneute Passworteingabe.

Ausfall und Fehlersuche üben

Prüfe mit deaktiviertem Netzwerk, ob die zwischengespeicherten Anmeldedaten greifen, und leg dir einen Notfallzugang mit lokalem Konto an. Für die Diagnose sind id, getent passwd, klist, realm list und die erhöhten debug_level in sssd.conf die Werkzeuge, mit denen du Namensauflösung, Ticket und Richtlinie einzeln durchmisst.

Tutorial

Vom DNS-Check bis zum getesteten Ausfall

Die Reihenfolge ist entscheidend: DNS und Uhrzeit zuerst, dann der Join, danach ID-Mapping und Zugriffsregeln. Wer den Join vorzieht, sucht anschließend Fehler an der falschen Stelle. Am Ende steht der Test, der wirklich zählt, nämlich der abgeschaltete Domänencontroller.

01

DNS, Uhrzeit und Hostname klären

Kerberos ist gnadenlos gegenüber falscher Zeit und falscher Namensauflösung. Fast jeder gescheiterte Join hat hier seine Ursache.

Voraussetzungen prüfen
sudo hostnamectl set-hostname srv01.intern.example.com

# Der Resolver muss auf die Domänencontroller zeigen, nicht auf einen Provider-DNS
dig +short -t SRV _ldap._tcp.intern.example.com
dig +short -t SRV _kerberos._udp.intern.example.com

# Zeitquelle: der Domänencontroller, nicht ein öffentlicher Pool
# In /etc/chrony.conf: 'pool ...' entfernen, 'server dc01.intern.example.com iburst' eintragen
sudo systemctl restart chronyd   # RHEL/Rocky/Alma, auf Debian/Ubuntu heißt der Dienst chrony
chronyc sources -v
chronyc tracking

Kommen die SRV-Einträge nicht zurück, brauchst du mit dem Join gar nicht anzufangen. realmd findet die Domäne ausschließlich über diese Einträge.

Domäne erkennen lassen
sudo realm discover intern.example.com

Die Ausgabe nennt den Domänentyp, den Server-Software-Typ und unter required-package genau die Pakete, die auf dieser Distribution fehlen. Das ist deine Installationsliste.

02

Pakete installieren und beitreten

Der Join legt ein Computerkonto in AD an, holt ein Keytab und schreibt eine erste sssd.conf. Zwei Details entscheiden darüber, ob du später Ärger bekommst: das verwendete Konto und die Ziel-OU.

Pakete und Join
# RHEL/Rocky/Alma
sudo dnf install -y realmd sssd sssd-tools adcli oddjob oddjob-mkhomedir \
  samba-common-tools krb5-workstation

# Debian/Ubuntu
sudo apt install -y realmd sssd sssd-tools adcli oddjob oddjob-mkhomedir \
  packagekit libnss-sss libpam-sss krb5-user

sudo realm join --user=svc-linuxjoin \
  --computer-ou="OU=Linux,OU=Server,DC=intern,DC=example,DC=com" \
  intern.example.com

realm list
id administrator@intern.example.com

Das Join-Konto braucht nur das Recht, Computerobjekte in dieser einen OU anzulegen. Ein Domänen-Admin-Konto ist unnötig und hinterlässt sein Passwort im Kommandozeilenverlauf. Ohne --computer-ou landet der Server im Standardcontainer, an dem oft weder die richtigen Gruppenrichtlinien noch die Aufräumregeln hängen.

03

ID-Mapping festlegen, bevor der zweite Server dazukommt

AD kennt SIDs, Linux kennt UIDs. Wie die Umrechnung passiert, ist die wichtigste Entscheidung der ganzen Anbindung, denn sie lässt sich später kaum noch ändern.

Zwei Verfahren, ein Unterschied

VerfahrenWoher kommen UID und GIDWann du es nimmst
Algorithmisch, ldap_id_mapping = TrueAus der SID berechnet, deterministisch bei identischer KonfigurationStandardfall, wenn in AD keine POSIX-Attribute gepflegt sind
POSIX-Attribute, ldap_id_mapping = FalseuidNumber und gidNumber direkt aus ADWenn NFS im Spiel ist, bestehende Unix-IDs übernommen werden oder mehrere Domänen über Trusts zusammenkommen
/etc/sssd/sssd.conf
[sssd]
domains = intern.example.com
services = nss, pam

[domain/intern.example.com]
id_provider = ad
auth_provider = ad
access_provider = ad

ldap_id_mapping = True
ldap_idmap_range_min = 200000
ldap_idmap_range_max = 2000200000
ldap_idmap_range_size = 200000

use_fully_qualified_names = False
fallback_homedir = /home/%u
default_shell = /bin/bash

cache_credentials = True
krb5_store_password_if_offline = True

Die drei ldap_idmap_*-Werte müssen auf allen Servern identisch sein. Sonst bekommt derselbe AD-Benutzer auf Server A und Server B unterschiedliche UIDs, und auf gemeinsam genutzten NFS-Freigaben gehören die Dateien plötzlich jemand anderem.

Übernehmen und prüfen
sudo chown root:root /etc/sssd/sssd.conf
sudo chmod 0600 /etc/sssd/sssd.conf
sudo systemctl restart sssd

id max.mustermann
getent passwd max.mustermann
getent group linux-admins

sssd verweigert den Start, wenn die Konfigurationsdatei nicht root gehört und nicht auf 0600 steht. Die Meldung im Journal ist eindeutig, wird aber gern übersehen, weil man den Fehler bei der Domäne sucht.

04

Zugriff und sudo eingrenzen

Nach dem Join kann sich zunächst jedes Domänenkonto anmelden, auch das Konto aus der Buchhaltung. Das ist selten gewollt.

Erst alles verbieten, dann gezielt erlauben
sudo realm deny --all
sudo realm permit -g 'Linux-Admins@intern.example.com'
sudo realm permit max.mustermann@intern.example.com

realm list          # zeigt login-policy und die zugelassenen Konten

realm permit schreibt die Regeln als simple_allow_groups in die sssd.conf. Für feinere Bedingungen setzt du stattdessen ad_access_filter mit einem memberOf-Ausdruck, zum Beispiel um zusätzlich ein Attribut auszuwerten.

/etc/sudoers.d/10-linux-admins
# Datei mit visudo anlegen, Modus 0440, Name ohne Punkt und ohne Tilde
sudo visudo -f /etc/sudoers.d/10-linux-admins

# Inhalt:
%linux-admins@intern.example.com ALL=(ALL) ALL

# Syntax gegenprüfen
sudo visudo -cf /etc/sudoers.d/10-linux-admins

Gruppennamen mit Leerzeichen brauchen einen Backslash vor dem Leerzeichen. Dateien mit einem Punkt oder einer Tilde im Namen ignoriert sudo kommentarlos, deshalb funktionieren Sicherungskopien wie 10-linux-admins.bak nie und stören auch nicht.

Bevor der Server produktiv geht

  • Ein lokales Notfallkonto mit sudo-Recht und starkem Passwort existiert.Ist der Domänencontroller weg und gleichzeitig der sssd-Cache leer, kommt sonst niemand mehr auf die Maschine. Konsolenzugang über die Virtualisierung nützt ohne gültiges lokales Konto nichts.
  • Die Anmeldung ist auf eine AD-Gruppe begrenzt, nicht auf einzelne Konten.Einzelrechte werden beim Ausscheiden von Personen vergessen. Über die Gruppe erledigt die Personalabteilung den Entzug automatisch mit.
  • sudo-Rechte kommen über eine eigene AD-Gruppe, nicht über die Domänen-Admins.Sonst hat jedes Konto mit Windows-Administrationsrechten automatisch root auf allen Linux-Servern. Das ist genau die Querverbindung, die ein Angriff sucht.
  • Das Computerkonto erneuert sein Passwort regelmäßig und du weißt, wie du es von Hand erneuerst.Läuft das Maschinenpasswort ab, scheitert jede Anmeldung mit Kerberos-Fehlern. adcli update setzt es neu, ohne den Server erneut beitreten zu lassen.
05

Home-Verzeichnisse und PAM einrichten

Ohne automatisch angelegtes Home landet die Anmeldung im Wurzelverzeichnis, und grafische Sitzungen scheitern ganz.

mkhomedir aktivieren, je nach Distribution unterschiedlich
# RHEL/Rocky/Alma: authselect verwaltet die PAM-Konfiguration
sudo authselect select sssd with-mkhomedir --force
sudo systemctl enable --now oddjobd
authselect current

# Debian/Ubuntu
sudo pam-auth-update --enable mkhomedir
grep -r pam_mkhomedir /etc/pam.d/

authconfig gibt es seit RHEL 8 nicht mehr. Wer PAM-Dateien dort von Hand editiert, verliert die Änderungen beim nächsten authselect-Aufruf. Eigene Ergänzungen gehören in ein eigenes Profil.

Für Heimatverzeichnisse vom Fileserver setzt du statt fallback_homedir das Attribut aus AD ein und mountest per autofs. Achte darauf, dass beide Seiten dieselben IDs sehen, sonst schreibt der Benutzer in ein Verzeichnis, das ihm auf dem Server nicht gehört.

06

Ausfall simulieren und Fehler schnell finden

Der wichtigste Test ist der, den niemand macht: Domänencontroller blockieren und schauen, ob die Anmeldung noch funktioniert.

Diagnosewerkzeuge, die du kennen solltest
sssctl domain-status intern.example.com
sssctl user-checks max.mustermann -s sshd
sudo klist -k /etc/krb5.keytab | head

# Kerberos-Ablauf im Klartext mitlesen, Realm in GROSSBUCHSTABEN
KRB5_TRACE=/dev/stderr kinit max.mustermann@INTERN.EXAMPLE.COM
klist

sudo journalctl -u sssd -f

sssctl user-checks zeigt getrennt, ob die Namensauflösung, die Authentifizierung und die Zugriffsregel greifen. Damit unterscheidest du in Sekunden zwischen falschem Passwort und fehlender Gruppenmitgliedschaft.

Cache leeren, vom Sanften zum Harten
# Zuerst: Cache nur als ungültig markieren, Dienst läuft weiter
sudo sss_cache -E

# Nur wenn das nicht hilft: kompletter Reset
sudo systemctl stop sssd
sudo rm -f /var/lib/sss/db/*
sudo systemctl start sssd
getent passwd max.mustermann

Für dauerhaft mehr Details setzt du debug_level = 6 im betroffenen Abschnitt der sssd.conf und nimmst den Eintrag danach wieder heraus. Höhere Stufen füllen das Journal schneller, als du lesen kannst.

Den Ernstfall probst du am besten kontrolliert: blockiere die Domänencontroller vorübergehend per Firewallregel, melde dich mit einem AD-Konto an, das sich vorher schon einmal angemeldet hat, und hebe die Regel danach wieder auf. Erst dieser Test zeigt, ob cache_credentials wirklich greift.

Passende Kurse

Kurse zu AD-Anbindung von Linux-Servern bei cmt

Diese Kurse vertiefen genau das, an echten Systemen statt nur an Folien. Als Präsenz oder Live-Online, auf Wunsch auch Inhouse für dein Team.

Linux Samba und Windows Netzwerke 2 Tage Präsenz nächster Termin 22.10.2026 Zum Kurs Linux als Datei- und Druckserver (Samba, NFS und mehr) 2 Tage Präsenz nächster Termin 19.11.2026 Zum Kurs Linux Infrastrukturdienste (INFS) 3 Tage Präsenz nächster Termin 26.08.2026 Garantietermin Zum Kurs Linux Netzwerkadministration Advanced Training (NADM) 3 Tage Präsenz nächster Termin 21.09.2026 Zum Kurs Linux Migration - Von Windows zu Linux 2 Tage Präsenz nächster Termin 07.12.2026 Zum Kurs
Unverbindlich beraten lassen Alle LPI-Kurse ansehen
Gut zu wissen

Häufige Fragen zu AD-Anbindung von Linux-Servern

Noch etwas offen? Wir sind ohne Warteschleife für dich da.

Frag uns direkt
Was ist der Unterschied zwischen SSSD und Samba-Winbind?
SSSD ist ein allgemeiner Identity-Dienst, der Konten aus AD oder LDAP für PAM und NSS bereitstellt, Anmeldedaten zwischenspeichert und damit auch offline funktioniert. Winbind gehört zur Samba-Suite und übersetzt zusätzlich Domänen-SIDs auf lokale UIDs, was du brauchst, wenn der Server selbst Freigaben mit Windows-ACLs anbietet. Für einen reinen Anmeldeserver ist SSSD der einfachere Weg, für einen Fileserver mit Samba führt an Winbind meist kein Weg vorbei.
Reicht realm join aus oder muss ich SSSD von Hand konfigurieren?
realmd erledigt Paketinstallation, Erzeugung der Keytab und eine funktionsfähige Basiskonfiguration in wenigen Sekunden, und für einen Testaufbau genügt das. Für den Produktivbetrieb wirst du sssd.conf trotzdem nachbearbeiten, etwa für Zugriffsfilter, ID-Bereiche, das Format der Benutzernamen ohne Domänensuffix und die Cache-Laufzeiten.
Warum bekommt derselbe AD-Benutzer auf zwei Servern verschiedene UIDs?
Beim algorithmischen ID-Mapping berechnet SSSD oder Winbind die UID aus der Domänen-SID und einem konfigurierten Bereich. Weichen die Bereiche oder die Zahl der Slices zwischen den Hosts ab, entstehen unterschiedliche Nummern. Entweder du gleichst die Mapping-Parameter überall an oder du pflegst POSIX-Attribute im AD, dann liefert das Verzeichnis die UID verbindlich.
Können sich Benutzer noch anmelden, wenn der Domänencontroller nicht erreichbar ist?
Ja, sofern das Credential-Caching in SSSD aktiviert ist und der Benutzer sich vorher mindestens einmal an diesem Host angemeldet hat. Die Gültigkeitsdauer legst du über die Cache-Parameter fest. Neue Konten und Passwortänderungen kommen offline allerdings nicht an, deshalb gehört ein lokaler Notfallzugang trotzdem auf jedes System.
Funktioniert die Anbindung auch gegen Entra ID statt gegen ein lokales Active Directory?
Nicht auf demselben Weg. Der klassische Domänenbeitritt setzt Kerberos und LDAP eines Domänencontrollers voraus, die Entra ID in dieser Form nicht anbietet. In reinen Cloud-Umgebungen arbeitest du entweder mit Microsoft Entra Domain Services, mit einem hybriden Aufbau samt lokalem Controller oder mit einer eigenen Identitätsebene für Anwendungen, wie sie unser Keycloak-Kurs behandelt.

Quellen

Zuletzt geprüft am 26. Juli 2026.

Weiterlesen

Verwandte Linux-Themen

Alle Linux-Themen im Überblick
Server-Administration Linux Backup-Strategie: Was du sicherst, wohin du sicherst und wie du zurückkommst Ansehen Server-Administration Linux Patchmanagement automatisieren, ohne den Betrieb zu stoppen Ansehen Server-Administration systemd verstehen: So steuerst du Dienste auf modernen Linux-Servern Ansehen Server-Administration ZFS oder Btrfs: Welches Dateisystem zu deinem Linux-Server passt Ansehen
Das sagen Teilnehmer

Echte Stimmen aus unseren IT-Kursen

“
Es war eine sehr gute Lernatmosphäre und der Trainer verstand sein Thema sehr gut.
Rückmeldung aus dem Kurs „SELinux Training: Grundlagen und Administration (SEL1)“
“
Sehr kompetenter Dozent der gut auf alle Fragen eingegangen ist.
Rückmeldung aus dem Kurs „Kubernetes Grundkurs“
Persönlich für dich da

Deine Ansprechpartner

Du bist dir nicht sicher, welcher Kurs oder welches Level zu dir passt? Wir beraten dich persönlich und kostenlos.

Yves Hoppe

Yves Hoppe

Weiterbildung & Beratung

Hilft dir, aus dem Linux-Programm den passenden Kurs oder Lernpfad zu finden.

0800 71 20000 E-Mail
Norbert Jansen

Norbert Jansen

Beratung & Inhouse

Plant mit dir Inhouse-Trainings, die exakt auf eure Systemlandschaft und Distributionen zugeschnitten sind.

0800 71 20000 E-Mail
Nächster Schritt

Identity im heterogenen Netz sauber aufsetzen

Wenn du die Anbindung nicht nur nachbauen, sondern verstehen und im Betrieb absichern willst, arbeitest du im Seminar "Linux Samba und Windows Netzwerke" mit Kerberos, Winbind und Domänenbeitritt an echten Systemen. Geht es dir stärker um Datei- und Druckdienste im Mischbetrieb, passt "Linux als Datei- und Druckserver" besser, und für den Gesamtblick auf zentrale Dienste ist "Linux Infrastrukturdienste" der richtige Kurs. Alle Termine gibt es Live-Online und vor Ort, und wenn du unsicher bist, welcher Weg zu deiner Umgebung passt, sprich uns einfach an.

Beratung anfragen 0800 71 20000