# 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

```env
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.