Keycloak Passwort-Reset mit Active Directory

Ein Keycloak Passwort-Reset mit Active Directory als führendem System wirft eine Frage auf: Wie viel Schreibzugriff braucht Keycloak dafür wirklich? Meist soll Keycloak über die LDAP-Föderation nur lesend angebunden sein. Sobald Benutzer ihr Passwort aber über Keycloak zurücksetzen sollen, reicht das nicht mehr aus.

WRITABLE ist kein Vollzugriff

Für den Passwort-Reset musst du den Edit Mode der LDAP-Föderation in Keycloak auf WRITABLE setzen. Das wirkt zunächst widersprüchlich, wenn Keycloak eigentlich nicht ins AD schreiben soll.

WRITABLE aktiviert aber nur die Schreibfähigkeit innerhalb der Keycloak-LDAP-Föderation. Ob eine Änderung tatsächlich durchgeht, entscheidet das AD anhand der Berechtigungen des Bind-Accounts. Die eigentliche Sicherheitsgrenze legst du also im AD fest.

Anforderungen an den Service-Account

Der Bind-Account für Keycloak sollte:

• ein gewöhnliches Domänenbenutzerkonto sein
• keine administrativen Gruppenmitgliedschaften haben
• Leserechte auf die benötigten LDAP-Attribute haben
• die Berechtigung Reset Password auf die betroffenen Benutzerobjekte haben

Entscheidend ist Reset Password und nicht Change Password. Keycloak setzt das Passwort neu, ohne das bisherige zu kennen, und genau dafür braucht es Reset Password.

Zusätzliche Rechte beim MSAD User Account Mapper

Wenn du den Standard-Mapper MSAD User Account verwendest, schreibt Keycloak nach jeder erfolgreichen Passwortänderung zusätzlich die Attribute pwdLastSet und userAccountControl ins AD. Der Service-Account braucht deshalb außerdem:

• Write pwdLastSet
• Write userAccountControl

Fehlen diese Rechte, wird das Passwort zwar geändert, Keycloak meldet anschließend aber Could not modify attribute. Das sieht dann leicht wie ein fehlgeschlagener Reset aus, obwohl das neue Passwort bereits gesetzt ist.

Wichtig: Schreibrechte auf userAccountControl sind nicht trivial. Damit lassen sich unter anderem deaktivierte Konten wieder aktivieren oder sicherheitsrelevante Flags setzen. Zusammen mit Reset Password hat der Service-Account damit weitreichende Kontrolle über alle Benutzer in der delegierten OU. Beschränke die Delegierung deshalb auf die OU, in der die betroffenen Benutzer wirklich liegen, und behandle den Account wie ein privilegiertes Konto: starkes Passwort, keine interaktive Anmeldung, Überwachung der Anmeldungen. Konten in geschützten Gruppen wie Domain Admins sind über AdminSDHolder ohnehin ausgenommen.

Rechte im Active Directory für den Keycloak Passwort-Reset delegieren

Die Berechtigungen vergibst du am besten über eine benutzerdefinierte Delegierung auf der OU, in der die betroffenen Benutzer liegen:

1. Rechtsklick auf die OU → Delegate Control…
2. Den Keycloak-Service-Account hinzufügen
3. Create a custom task to delegate wählen
4. Only the following objects in the folder → User objects auswählen, Create und Delete nicht aktivieren
5. Unter Permissions die Ansichten General und Property-specific einblenden und folgende Rechte auswählen:
   • Read All Properties
   • Reset password
   • Write pwdLastSet
   • Write userAccountControl

Zur Kontrolle sollten die delegierten Berechtigungen im Reiter Security (erweiterte Ansicht) für den Service-Account erscheinen, jeweils gültig für Descendant User objects:

Was nicht delegiert werden muss

Allgemeine oder weitreichende Berechtigungen sind nicht erforderlich und sollten auch nicht vergeben werden:

• Create, delete, and manage user accounts
• Create/Delete selected objects in this folder
• Create/Delete User Objects
• Create/Delete All Child Objects
• Write bzw. Write All Properties
• Full Control

Konfiguration in Keycloak

Verbindungs-URL: Verwende ldaps://. Das AD akzeptiert Passwortänderungen nur über eine verschlüsselte Verbindung, unverschlüsseltes LDAP reicht also nicht. StartTLS wäre technisch ebenfalls möglich.

Edit Mode: WRITABLE. Welche Änderungen tatsächlich möglich sind, bestimmen die AD-Berechtigungen des Bind-Accounts.

Hinweis: Im Modus WRITABLE versucht Keycloak unter Umständen auch andere Attribute ins AD zurückzuschreiben, etwa wenn ein Benutzer im Account-Portal Namen oder E-Mail-Adresse ändert. Ohne passende Rechte schlägt das fehl. Damit Keycloak diese Schreibversuche gar nicht erst unternimmt, stellst du die betroffenen Attribut-Mapper am besten auf Read Only, z.B.:

Außerdem lohnt es sich, die Attribute auch im User Profile schreibzuschützen. Du findest es in den Realm Settings. Wähle dort in den Berechtigungen der betroffenen Attribute unter Who can edit nichts aus und aktiviere nur Who can view. So sehen Benutzer ihre Daten weiterhin, können sie aber in Keycloak nicht mehr bearbeiten. Dadurch entstehen gar nicht erst Änderungen, die Keycloak ins AD schreiben wollen würde.

Fazit

Ein Passwort-Reset über Keycloak ist auch dann möglich, wenn AD das führende System bleibt und Keycloak keinen allgemeinen Schreibzugriff bekommen soll. In Keycloak stellst du den Edit Mode auf WRITABLE. Im AD bekommt der Bind-Account per Delegierung auf der passenden OU nur Leserechte, Reset Password und, falls nötig, Schreibrechte auf pwdLastSet und userAccountControl.

Ein Wort zu KI in diesem Beitrag