Kapitel 16 Clients, Groupware & CLI Admin: #pIdentity

Identitätsquellen: Active Directory, LDAP, Entra ID, Keycloak und SCIM

Unter Admin > Identitätsquellen hängen Sie einen Mandanten oder einzelne Domains an ein Active Directory bzw. LDAP (Anmeldung per Bind, Abgleich von Benutzern, verschachtelten Gruppen und Kontakten) oder an Microsoft Entra ID, Keycloak und andere OpenID-Connect-Anbieter (Anmeldung per SSO, Provisionierung per SCIM 2.0). Lokale Konten bleiben daneben voll nutzbar (Mischbetrieb). Jedes Konto hat genau eine Quelle; die Zuordnung läuft über die ExternalId (AD objectGUID, Entra objectId, LDAP entryUUID), nie nur über die Mailadresse. Felder, die die Quelle verwaltet, sind im Admin und in "Mein Konto" schreibgeschützt.

Praxis-Tipp & Architektur-Hinweis

Behalten Sie mindestens einen lokalen Server-Admin ohne Quelle als Notfall-Zugang. Er wird nie aus AD übernommen, meldet sich nie per SSO-Mailabgleich an und funktioniert auch, wenn AD oder Entra nicht erreichbar sind. Stellen Sie die nextxch-Sperrschwelle (Standard 5 Fehlversuche) unter die AD-Kontosperrschwelle: dann sperren Angreifer nie ein AD-Konto, weil nextxch vor dem Bind abbricht.

Entra ID: App-Registrierung für Anmeldung und SCIM

Anmeldung: eigene App-Registrierung (Web-Plattform) mit der Redirect-URI aus Admin > Identitätsquellen. Provisionierung: Enterprise-App "Non-gallery" mit Provisioning-Modus "Automatic", Tenant-URL und Secret Token aus nextxch.

Referenz / Konfiguration

1. Entra admin center > App-Registrierungen > Neue Registrierung
   Name:            nextxch Webmail
   Kontotypen:      Nur Konten in diesem Organisationsverzeichnis (Single Tenant)
   Redirect-URI:    Web  https://mail.firma.de/api/auth/sso/callback
2. Zertifikate & Geheimnisse > Neuer geheimer Clientschlüssel  -> in nextxch als Client-Secret eintragen
3. Token-Konfiguration > Optionalen Anspruch hinzufügen: ID-Token "email" (sonst gilt preferred_username = UPN)
4. App-Rollen (optional): z. B. "Nextxch.TenantAdmins" anlegen, Benutzern zuweisen,
   in nextxch: Claim "roles", Wert "Nextxch.TenantAdmins" -> Rolle TenantAdmin
5. nextxch Admin > Identitätsquellen > Entra ID / OIDC hinzufügen
   Authority:  https://login.microsoftonline.com/<Verzeichnis-ID>/v2.0
   Client-ID:  <Anwendungs-ID>
6. SCIM: Enterprise-Anwendungen > Neue Anwendung > Eigene Anwendung (Non-gallery)
   Bereitstellung > Automatisch
   Mandanten-URL:   https://mail.firma.de/scim/v2
   Geheimes Token:  nxscim_...   (Admin > Identitätsquellen > SCIM-Token erzeugen)
   Zuordnungen: userName <- userPrincipalName, emails[type eq "work"].value <- mail,
                externalId <- objectId (empfohlen) oder mailNickname

Einstellungen, Standardwerte & Best Practices

Einstellung / Ort	Funktion	Standardwert	Best Practice im Betrieb
`Active Directory: Dienstkonto`	Normales Domänenbenutzerkonto ohne Adminrechte, nur Lesen (Standard "Authentifizierte Benutzer" genügt). Kennwort läuft nicht ab. Wird verschlüsselt gespeichert und nie angezeigt.	`CN=svc-nextxch,OU=Service,...`	Kein Domänen-Admin. Für Fotos und proxyAddresses reicht Lesen. Optional "Anmelden nur an" auf die DCs beschränken.
`LDAPS 636 / StartTLS 389`	Verschlüsselte Verbindung zu den Domänencontrollern. Mehrere DCs werden der Reihe nach probiert (Failover), Zeitlimit pro DC einstellbar.	`LDAPS, 10 s`	DC-Zertifikat (oder die interne CA) auf dem nextxch-Server vertrauen. "Zertifikat nicht prüfen" nur kurz zur Einrichtung.
`Anmeldung (alle Protokolle)`	Webmail, Admin, IMAP, SMTP, POP3, ActiveSync, EWS, MAPI und DAV prüfen das AD-Passwort per Bind. Anmeldenamen: Mailadresse, userPrincipalName, sAMAccountName oder DOMAIN\benutzer.	`Cache 15 min (Hash)`	Der kurze Anmelde-Cache speichert nur einen HMAC, nie das Passwort, und hält die Anmeldung bei kurzem DC-Ausfall aufrecht. 0 schaltet ihn ab.
`Abgleich: Benutzer, Gruppen, Kontakte`	mail und proxyAddresses (SMTP: = Hauptadresse, smtp: = Alias), displayName, givenName, sn, telephoneNumber, mobile, title, department, company, physicalDeliveryOfficeName, manager, thumbnailPhoto; userAccountControl und accountExpires sperren das Postfach. Gruppen mit Mailadresse werden Verteiler (verschachtelt per LDAP_MATCHING_RULE_IN_CHAIN), Kontakte erscheinen im Adressbuch.	`Delta 15 min, voll 02:00`	Vor dem ersten Lauf "Vorschau" nutzen: zeigt, welche Konten angelegt, übernommen oder gesperrt würden, ohne etwas zu ändern. Filter auf eine Gruppe "Mail-Benutzer" setzen.
`Gelöschte Objekte`	Fehlt ein Objekt im AD (oder in Entra per SCIM DELETE), wird das Postfach sofort gesperrt. Nach der Frist entscheidet der Admin: löschen, als freigegebenes Postfach behalten oder gesperrt lassen.	`30 Tage`	Umbenennungen sind kein Löschen: die alte Hauptadresse bleibt als Alias erhalten.
`Vorlagen`	Attribut-Zuordnung für Microsoft AD, Samba AD, OpenLDAP, Univention Corporate Server und FreeIPA; jedes Feld kann überschrieben oder mit "-" abgeschaltet werden.	`Active Directory`	OpenLDAP braucht das memberOf-Overlay für den Gruppenfilter; verschachtelte Gruppen löst nextxch dort selbst auf.
`OIDC (Entra ID, Keycloak)`	Authorization Code Flow mit PKCE auf dem Server, Discovery und JWKS mit automatischem Schlüsseltausch, RS256/ES256, Prüfung von iss, aud, exp, nonce und beim Entra-Mandanten tid. Gruppen- oder App-Rollen-Claims werden auf User, TenantAdmin und ServerAdmin abgebildet.	`Knopf auf der Anmeldeseite`	Keycloak: Authority https://kc.firma.de/realms/<realm>, Client "confidential" mit Standard Flow, Redirect-URI wie oben; Rollen über Claim realm_access.roles.
`Lokale Passwörter pro Domain`	Webmail/Admin und Protokolle getrennt abschaltbar. Entra-Passwörter erreichen nextxch nie: Mail-Programme (Outlook, iPhone, Thunderbird) nutzen App-Passwörter, das Webmail führt mit einem Assistenten durch die Einrichtung.	`An`	Pro Protokoll lässt sich zusätzlich "Nur OAuth / Kerberos" erzwingen (siehe Kapitel 16a und 16b). AD-Benutzer können ihr Kennwort im Webmail ändern, wenn die Quelle das erlaubt.
`Kennwort ändern (AD / LDAP)`	Mit "Benutzer dürfen ihr Kennwort ändern" erscheint im Webmail unter Einstellungen > Sicherheit ein Formular (aktuelles und neues Kennwort). AD: unicodePwd über LDAPS mit dem alten Kennwort, sodass Komplexität, Kennwortchronik und Mindestalter des AD gelten; andere Verzeichnisse: RFC 3062. Admins setzen Kennwörter im Kontodialog zurück (optional "bei nächster Anmeldung ändern").	`Aus`	Für den Admin-Reset dem Dienstkonto nur auf der Benutzer-OU das Recht "Kennwort zurücksetzen" delegieren. Kennwörter werden nie protokolliert.