desktop/temp/LDAP_DIREKT_SETUP.md

LDAP Direkt-Setup

Damit die Freigabe direkt ins LDAP schreiben kann, muss auf dem Zielsystem Folgendes vorhanden sein:

PHP-Erweiterung

• php-ldap

Lokal in meiner aktuellen Umgebung ist diese Erweiterung nicht geladen. Deshalb ist der Verbindungsweg hier nicht live getestet, nur die Syntax.

Erforderliche Umgebungsvariablen

• REGISTRATION_PASSWORD_KEY
• LDAP_HOST
• LDAP_PORT
• LDAP_BIND_DN
• LDAP_BIND_PASSWORD
• LDAP_USE_STARTTLS
• optional LDAP_GROUP_ASSIGNMENT_MODE
• optional LDAP_GROUP_MEMBER_ATTRIBUTE

Beispiel

REGISTRATION_PASSWORD_KEY=bitte-einen-langen-zufallswert-oder-base64-key-verwenden
LDAP_HOST=ldap.example.internal
LDAP_PORT=389
LDAP_BIND_DN=uid=serviceaccount,cn=users,dc=nas,dc=kusche,dc=berlin
LDAP_BIND_PASSWORD=supersecret
LDAP_USE_STARTTLS=true
LDAP_GROUP_ASSIGNMENT_MODE=group_memberuid
LDAP_GROUP_MEMBER_ATTRIBUTE=memberUid

Aktuelles Verhalten

• Registrierung speichert das gewünschte Passwort verschlüsselt zwischen
• Admin-Freigabe schreibt den Benutzer direkt ins LDAP
• dabei werden userPassword und sambaNTPassword gesetzt
• der Benutzer wird zunächst mit inaktivem shadowExpire angelegt
• zusätzlich wird weiter ein LDIF-Fallback erzeugt

Wichtige offene Punkte

• Ob shadowExpire=1 für Keycloak-Logins wirklich blockierend wirkt, hängt vom LDAP-/NAS-Verhalten ab.
• Falls Keycloak trotzdem Login zulässt, brauchen wir als Nächstes noch einen expliziten Aktivierungsstatus oder eine Gruppen-/Attributprüfung im Loginflow.