# Identity Management on SUSE: Lokale User und Enterprise Verzeichnisse

TL;DR / Management Summary In kleinen Umgebungen reichen lokale Benutzer in /etc/passwd. In Enterprise-Netzwerken ist die Anbindung an Active Directory (AD) oder LDAP Pflicht. SUSE nutzt hierfür standardmäßig den System Security Services Dämon (SSSD). In Kombination mit YaST erlaubt dies ein nahtloses Login mit Domain-Credentials und eine zentrale Steuerung von Sudo-Berechtigungen.

# 1. Einführung & Architektur

Die Identitäts-Kette.

Der Kernel fragt nicht direkt bei Windows nach dem Passwort. Er nutzt eine Kette von Abstraktionen.

# Der Auth-Stack (Mermaid)

graph LR
    A[Login Prompt / SSH] --> B[PAM: Pluggable Auth Modules]
    B --> C[SSSD: System Security Services Daemon]
    C -->|Offline Cache| D[Local TDB Database]
    C -->|Query| E[Active Directory / LDAP]
    F[NSS: Name Service Switch] --> C
    F -->|Local| G[/etc/passwd]

• SSSD: Der Vermittler. Er merkt sich Passwörter (Offline Cache), falls der Domain Controller nicht erreichbar ist.
• NSS: Sagt dem System, wo es nach User-Informationen (UID, Shell) suchen soll.

# 2. Lokale Benutzerverwaltung (Expert Level)

Sicherheit in /etc/passwd.

# Passwort-Policys erzwingen

Datei: /etc/login.defs (Global) und /etc/security/pwquality.conf (Komplexität).

# In login.defs
PASS_MAX_DAYS   90
PASS_MIN_DAYS   1
PASS_WARN_AGE   7

# Sudo-Rechte via YaST

Anstatt visudo zu nutzen, was fehleranfällig ist:

sudo yast2 sudo

Hier können Sie Gruppen oder Usern spezifische Befehle ohne Passwort-Abfrage erlauben.

# 3. Active Directory Integration

Den Server in die Domain aufnehmen.

SUSE macht dies über das Paket realmd sehr einfach.

# Schritt 1: Pakete installieren

sudo zypper install realmd sssd adcli samba-client

# Schritt 2: Domain beitreten

sudo realm join company.local -U 'admin_user'

# Schritt 3: Zugriff einschränken

Verhindern Sie, dass sich jeder Domain-User einloggen darf:

sudo realm permit -g "LinuxAdmins@company.local"

# 4. Day-2 Operations: SSSD Management

Fehlersuche und Caching.

# Cache leeren

Wenn ein User die Gruppe gewechselt hat, SLES das aber noch nicht sieht:

sudo sss_cache -E

# UID/GID Mapping

Standardmäßig generiert SSSD die Linux-UIDs aus der Windows-SID. Stellen Sie sicher, dass dies auf allen Servern konsistent ist, indem Sie id_provider = ad in der /etc/sssd/sssd.conf nutzen.

# 5. Troubleshooting & “War Stories”

Wenn der Login scheitert.

# Story 1: “Der Offline-Login Fail”

Symptom: Ein Admin kann sich am Laptop/Server nicht einloggen, wenn das Netzwerkkabel gezogen ist, obwohl Offline-Caching aktiv sein sollte. Ursache: Der SSSD Cache wurde nie befüllt, da der User sich noch nie erfolgreich eingeloggt hatte, während das Netzwerk da war. Lösung: Loggen Sie sich einmalig via SSH/Konsole ein, solange der Server online ist. Prüfen Sie cache_credentials = True in der sssd.conf.

# Story 2: “UID Konflikt mit lokalen Usern”

Symptom: Ein Domain-User bekommt die UID 1000, die bereits einem lokalen User gehört. Massive Berechtigungsprobleme. Ursache: Überlappende ID-Ranges. Lösung: Setzen Sie in der sssd.conf eine hohe min_id (z.B. 10000), damit Domain-User niemals mit lokalen System-Accounts kollidieren.

# 6. Fazit & Empfehlung

• Zentralisierung: Nutzen Sie SSSD für alle Anbindungen. Es ist moderner und stabiler als pam_ldap.
• Sicherheit: Nutzen Sie LDAPS (Port 636) oder STARTTLS, um Passwörter auf dem Weg zum DC zu verschlüsseln.
• Wartung: Überwachen Sie die Logdatei /var/log/sssd/sssd_<domain>.log auf Timeouts.

# Anhang: Cheatsheet