Das Problem

Nach 3 Stunden Troubleshooting einer DC-Migration von dc-obiwan auf dc-yoda sind deine User ausgesperrt.

Die Groupware zeigt nur:

Login fehlgeschlagen. Überprüfen Sie Ihren Benutzernamen und/oder Ihr Passwort.

Das Passwort ist korrekt. Du hast es gerade mit ldapsearch verifiziert. Trotzdem schlägt jeder Login fehl.

Die Server-Logs sagen:

LDAP (simple) bind on uid=c3po,cn=users,dc=darkside,dc=local failed: Invalid credentials

Warum funktioniert LDAP-Auth nicht mehr, obwohl das Passwort stimmt?

Du versuchst das Passwort neu zu setzen:

ldappasswd -H ldapi:/// -D "cn=admin,dc=darkside,dc=local" \
  -s "neuespasswort" "uid=c3po,cn=users,dc=darkside,dc=local"

Resultat:

Result: Server is unwilling to perform (53)
Additional info: shadow context; no update referral

Was zum…? “Shadow context”? Der Server verweigert Schreiboperationen, obwohl er der einzige DC im Netz ist.

Die Diagnose

Schritt 1: LDAP-Verbindung testen

ldapsearch -x -H ldaps://dc-yoda:7636 \
  -D "uid=c3po,cn=users,dc=darkside,dc=local" \
  -w "daspasswort" \
  -b "dc=darkside,dc=local" "(uid=c3po)"

Ergebnis: ldap_bind: Invalid credentials (49)

Das Passwort stimmte aber - ich hatte es gerade erst verifiziert. Also versuchte ich, es neu zu setzen:

ldappasswd -H ldapi:/// -D "cn=admin,dc=darkside,dc=local" -y /etc/ldap.secret \
  -s "neuespasswort" "uid=c3po,cn=users,dc=darkside,dc=local"

Ergebnis:

Result: Server is unwilling to perform (53)
Additional info: shadow context; no update referral

Schritt 2: Die Erkenntnis

“Shadow context” - der Server betrachtete sich selbst als Replica (Slave), nicht als Master. Er verweigerte Schreiboperationen, weil er dachte, diese müssten an einen Master weitergeleitet werden.

Eine schnelle Prüfung bestätigte den Verdacht:

ucr get server/role
# Ausgabe: domaincontroller_backup

ucr get ldap/server/type
# Ausgabe: slave

Der Backup-DC war noch als Backup konfiguriert - obwohl der alte Master (dc-obiwan) längst demoted und aus dem AD entfernt war!

Die Ursache

Bei einer UCS DC-Migration werden die Samba AD FSMO-Rollen korrekt transferiert, aber die UCS/OpenLDAP-Konfiguration wird nicht automatisch angepasst.

Das bedeutet:

  • samba-tool fsmo show zeigt korrekt den neuen Master
  • Aber OpenLDAP (Port 7389/7636) ist noch im Slave-Modus
  • LDAP-Schreiboperationen werden an den nicht-existenten Master weitergeleitet

Zusätzlich hatte OpenLDAP noch ein olcUpdateRef in der Konfiguration:

ldapsearch -H ldapi:/// -Y EXTERNAL -b "olcDatabase={1}mdb,cn=config" olcUpdateRef
# Ausgabe: olcUpdateRef: ldap://dc-obiwan.darkside.local:7389

Diese Referral-URL zeigte auf den alten, nicht mehr existierenden DC.

Das perfide

Samba AD denkt du bist Master. OpenLDAP denkt du bist Slave. Sie reden nicht miteinander.

Das ist das Problem bei UCS: Es laufen zwei getrennte Verzeichnisdienste parallel:

  1. Samba AD (Port 389/636) - für Windows-Integration, Kerberos, FSMO-Rollen
  2. OpenLDAP (Port 7389/7636) - für Linux-Auth, UCS-Verwaltung, Groupware

Die DC-Migration transferiert FSMO-Rollen in Samba AD korrekt:

samba-tool fsmo show
# ✅ Alle Rollen zeigen auf dc-yoda

Aber OpenLDAP weiß nichts davon:

ucr get ldap/server/type
# ❌ Immer noch "slave"

Die Konsequenz: Samba AD funktioniert, aber Linux-Tools (ldapsearch, ldappasswd, Groupware-Logins) schlagen fehl mit “shadow context” oder “Invalid credentials”.

Das ist nicht ein Bug - es ist das Design von UCS. Die beiden Systeme sind bewusst getrennt. Aber die Dokumentation erwähnt nicht, dass du nach einer DC-Migration manuell die OpenLDAP-Config anpassen musst.

Die Lösung

1. olcUpdateRef entfernen

cat > /tmp/fix.ldif << 'EOF'
dn: olcDatabase={1}mdb,cn=config
changetype: modify
delete: olcUpdateRef
EOF

ldapmodify -H ldapi:/// -Y EXTERNAL -f /tmp/fix.ldif

2. UCR-Variablen auf Master setzen

ucr set server/role=domaincontroller_master ldap/server/type=master

3. slapd neu starten

systemctl restart slapd

4. Passwort setzen und Dienste neu starten

# Jetzt funktioniert es!
ldappasswd -H ldapi:/// -D "cn=admin,dc=darkside,dc=local" -y /etc/ldap.secret \
  -s "daspasswort" "uid=c3po,cn=users,dc=darkside,dc=local"

# Groupware auf dem anderen Host neu starten
ssh root@dc-obiwan 'systemctl restart kopano-server'

Lessons Learned

  1. FSMO-Transfer ≠ vollständige DC-Promotion: Samba AD und UCS/OpenLDAP sind zwei getrennte Welten. Der FSMO-Transfer betrifft nur Samba AD.

  2. UCR-Variablen nach DC-Wechsel prüfen: Nach jeder DC-Migration müssen server/role UND ldap/server/type auf dem neuen Master kontrolliert werden.

  3. olcUpdateRef manuell entfernen: Die LDAP-Konfiguration enthält möglicherweise noch Referenzen auf den alten Master, die manuell entfernt werden müssen.

  4. “Invalid credentials” kann Infrastruktur bedeuten: Nicht jeder “Invalid credentials” Fehler ist ein falsches Passwort. Es kann auch bedeuten, dass der LDAP-Server keine Authentifizierung durchführen kann, weil er sich selbst als Slave betrachtet.

Checkliste: Nach UCS DC-Migration

  • FSMO-Rollen transferiert: samba-tool fsmo show
  • UCR server/role: ucr set server/role=domaincontroller_master
  • UCR ldap/server/type: ucr set ldap/server/type=master
  • olcUpdateRef entfernt: ldapsearch ... olcUpdateRef
  • slapd neu gestartet: systemctl restart slapd
  • LDAP-Schreibtest: ldappasswd ...
  • Abhängige Dienste neu gestartet (Groupware, etc.)

Dieses Problem trat auf nach einer DC-Migration von UCS 5.0, bei der der alte Master demoted und der Backup-DC zum neuen Master promoted wurde. Die Symptome können bei jeder UCS DC-Migration auftreten, bei der der Backup-DC zum Master wird.