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.

Administrator steckt ein Netzwerkkabel in einen Serverschrank
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

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.

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.

Zuletzt geprüft am 26. Juli 2026.

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.

Norbert Jansen

Norbert Jansen

Beratung & Inhouse

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

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.