ubuntuusers.de

Dovecot 2.4 / Samba-DC LDAP: userdb Lookup schlägt fehl (Wechsel von OpenLDAP)

Status: Ungelöst | Ubuntu-Version: Server 24.04 (Noble Numbat)
Antworten |

supernicky

Anmeldungsdatum:
10. Juni 2026

Beiträge: 1

Hallo zusammen,

ich stehe aktuell vor einer Herausforderung bei der Migration meines Dovecot-Authentifizierungs-Backends von OpenLDAP zu einem Samba-DC (Active Directory).

Da es sich bei beiden Systemen um LDAP-basierte Verzeichnisse handelt, dachte ich eigentlich, dass die Migration unkompliziert verläuft – das hat sich jedoch als Irrtum herausgestellt. Ich bin mir ziemlich sicher, dass es sich nur um ein kleines Konfigurationsdetail handelt, aber ich suche nun schon seit drei Tagen erfolglos nach der Lösung.

Zuerst möchte ich meine aktuelle Konfiguration teilen, die mit OpenLDAP absolut fehlerfrei funktioniert.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
# extended LDIF
# LDAPv3
# base <dc=domain1,dc=tld> with scope subtree
# filter: (mail=user@domain3.tld)
# requesting: ALL
#

# user.surname, users, domain1.tld
dn: uid=user.surname,ou=users,dc=domain1,dc=tld
uid: user.surname
sn: surname
givenName: user
cn: user surname
displayName: user surname
mail: user@domain1.tld
mail: user@domain2.tld
mail: user@domain3.tld
uidNumber: 13113
gidNumber: 13000
homeDirectory: /home/user.surname
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
objectClass: posixAccount
objectClass: sambaSamAccount
sambaSID: S-1-5-21-2286081015-3344157248-104006538-1009
sambaNTPassword: [REDACTED]
sambaPasswordHistory: [REDACTED]
sambaPwdLastSet: 1753387770
sambaAcctFlags: [U          ]
initials: 10000G

Meine Dovecot auth-ldap.conf.ext Konfiguration für dieses OpenLDAP-Setup sieht wie folgt aus:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
# Globale LDAP-Verbindungseinstellungen
ldap_version = 3
ldap_uris = ldap://[SERVER_IP]
ldap_auth_dn = cn=admin,dc=domain1,dc=tld
ldap_auth_dn_password = [PASSWORD]
ldap_base = dc=domain1,dc=tld

# --- Password Database (passdb) ---
# Überprüft das Passwort (Authentication Bind)
passdb ldap {
  ldap_bind = yes
  uid=%{user},ou=users,dc=domain1,dc=tld
  ldap_filter = (&(objectClass=posixAccount)(mail=%{user}))
}

# --- User Database (userdb) ---
# Holt die Benutzerdetails für den Speicherort der Mailbox und Zugriffsrechte
userdb ldap {
  ldap_filter = (&(objectClass=posixAccount)(mail=%{user}))

  fields {
    home = /srv/vmail/%{user|domain|lower}/%{user|username|lower}
    uid = vmail
    gid = vmail
    quota_rule = *:storage=%{ldap:initials}
    quota_rule2 = Trash:storage=500G
    quota_rule3 = Spam:storage=50M
    quota_storage_size = %{ldap:initials}
    quota_mailbox_message_count = 30000
    quota_mailbox_message_count = 5000
  }
}

Dieses Setup ist einfach aufgebaut und läuft perfekt. Das mail-Attribut ist mehrwertig (multivalued) und enthält die drei E-Mail-Adressen, die zu meinen drei Domains gehören. Der Benutzername bleibt dabei über alle Domains hinweg identisch.

Hier ist nun zum Vergleich der entsprechende Verzeichniseintrag aus meinem Samba-DC (Active Directory):

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
# extended LDIF
#
# LDAPv3
# base <dc=domain1,dc=tld> with scope subtree
# filter: (mail=user@domain1.tld)
# requesting: ALL
#

# User Name, Users, domain1.tld
dn: CN=User Name,OU=Users,DC=domain1,DC=tld
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: user
cn: User Name
sn: Surname
givenName: User
instanceType: 4
whenCreated: 20260510123059.0Z
displayName: User Name
uSNCreated: 4168
name: User Name
objectGUID:: [REDACTED]
badPwdCount: 0
codePage: 0
countryCode: 0
badPasswordTime: 0
lastLogoff: 0
primaryGroupID: 513
objectSid:: [REDACTED]
accountExpires: 9223372036854775807
sAMAccountName: username
sAMAccountType: 805306368
userPrincipalName: user@domain1.tld
objectCategory: CN=Person,CN=Schema,CN=Configuration,DC=domain1,DC=tld
mail: user@domain1.tld
pwdLastSet: 134228898599390930
userAccountControl: 512
memberOf: CN=MailUsers,CN=Users,DC=domain1,DC=tld
lastLogonTimestamp: 134250693872343440
logonCount: 9
msDS-cloudExtensionAttribute1: 10000G
proxyAddresses: user@domain2.tld
proxyAddresses: user@domain3.tld
proxyAddresses: user@domain1.tld
msDS-cloudExtensionAttribute2: user@domain2.tld
msDS-cloudExtensionAttribute3: user@domain3.tld
msDS-cloudExtensionAttribute4: user@domain1.tld
whenChanged: 20260609104109.0Z
uSNChanged: 5875
distinguishedName: CN=User Name,OU=Users,DC=domain1,DC=tld

Zu Testzwecken habe ich hier sowohl proxyAddresses als mehrwertiges Feld verwendet, als auch die Attribute msDS-cloudExtensionAttribute2 bis msDS-cloudExtensionAttribute4.

Meine aktuelle Dovecot auth-ldap.conf.ext Konfiguration für den Samba-DC sieht so aus:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
# Globale LDAP-Verbindungseinstellungen
ldap_version = 3
ldap_uris = ldaps://dc1.domain1.tld
ldap_auth_dn = "administrator@domain1.tld"
ldap_auth_dn_password = [PASSWORD]
ldap_base = dc=domain1,dc=tld

# WICHTIG: Samba DC / AD verlangt oft das Deaktivieren von Referrals
# referral = no

# --- Password Database (passdb) ---
passdb ldap {
  driver = ldap
  
  # Suchfilter
  ldap_filter = (&(objectClass=user)(|(msDS-cloudExtensionAttribute4=%{user|username|lower}@%{user|domain|lower})(msDS-cloudExtensionAttribute3=%{user|username|lower}@%{user|domain|lower})(msDS-cloudExtensionAttribute2=%{user|username|lower}@%{user|domain|lower})))
  
  # AD/Samba erlaubt den Direkt-Bind mit der Mailadresse des Users
  bind_userdn = %{user|username|lower}@domain1.tld
  bind = yes

  fields {
    user = %{user|username}@domain1.tld
  }
}

# --- User Database (userdb) ---
userdb ldap {
  driver = ldap
  
  ldap_filter = (&(objectClass=user)(|(mail=%{user})(userPrincipalName=%{user})))

  fields {
    home = /srv/vmail/%{original_user|domain|lower}/%{original_user|username|lower}
    uid = vmail
    gid = vmail
    quota_rule = *:storage=%{ldap:msDS-cloudExtensionAttribute1}
    quota_rule2 = Trash:storage=500G
    quota_rule3 = Spam:storage=50M
    quota_storage_size = %{ldap:msDS-cloudExtensionAttribute1}
    quota_message_count = 30000
    quota_mailbox_message_count = 5000
  }
}

Die Passwort-Authentifizierung (passdb) funktioniert absolut tadellos. Allerdings werden im Anschluss keine Attribute aus dem fields-Block zurückgegeben, wodurch der gesamte Verbindungsaufbau fehlschlägt.

Hier sind die relevanten Zeilen aus dem Debug-Log:

Jun 09 17:49:44 auth: Debug: Loading modules from directory: /usr/lib/dovecot/modules/auth
Jun 09 17:49:44 auth: Debug: Loading modules from directory: /usr/lib/dovecot/modules/auth
Jun 09 17:49:44 auth: Debug: Module loaded: /usr/lib/dovecot/modules/auth/libauthdb_ldap.so
Jun 09 17:49:44 auth: Debug: Read auth token secret from /run/auth-token-secret.dat
Jun 09 17:49:44 auth: Debug: ldap(ldaps://dc1.domain1.tld:636): initialization took 15 msecs
Jun 09 17:49:44 auth: Debug: conn unix:/run/auth-userdb (pid=20421,uid=0): Server accepted connection (fd=20)
Jun 09 17:49:44 auth: Debug: master in: USER    1      user1@domain1.tld protocol=doveadm        debug
Jun 09 17:49:44 auth(user1@domain1.tld): Debug: ldap: Performing userdb lookup
Jun 09 17:49:44 auth(user1@domain1.tld): Debug: ldap: userdb cache miss
Jun 09 17:49:44 auth(user1@domain1.tld): Debug: ldap: user search: base=dc=domain1,dc=tld scope=subtree filter=(&(objectClass=user)(|(mail=user1@domain1.tld)(msDS-cloudExtensionAttribute2=user1@domain1.tld)(msDS-cloudExtensionAttribute3=user1@domain1.tld)(msDS-cloudExtensionAttribute4=user1@domain1.tld)))
Jun 09 17:51:01 auth: Debug: conn unix:/run/auth-userdb (pid=20432,uid=0): Server accepted connection (fd=22)
Jun 09 17:51:01 auth: Debug: master in: USER    1      user2@domain2.tld   protocol=doveadm
Jun 09 17:51:01 auth(user2@domain2.tld): Debug: ldap: Performing userdb lookup
Jun 09 17:51:01 auth(user2@domain2.tld): Debug: ldap: userdb cache miss
Jun 09 17:51:01 auth(user2@domain2.tld): Debug: ldap: user search: base=dc=domain1,dc=tld scope=subtree filter=(&(objectClass=user)(|(mail=user2@domain2.tld)(msDS-cloudExtensionAttribute2=user2@domain2.tld)(msDS-cloudExtensionAttribute3=user2@domain2.tld)(msDS-cloudExtensionAttribute4=user2@domain2.tld)))
Jun 09 17:51:01 auth(user1@domain1.tld): Debug: ldap: Finished userdb lookup
Jun 09 17:51:01 auth(user1@domain1.tld): Debug: ldap: userdb cache miss
Jun 09 17:51:01 auth: Debug: ldap(ldaps://dc1.domain1.tld:636): initialization took 6 msecs
Jun 09 17:51:03 auth: Debug: userdb out: FAIL   1
Jun 09 17:51:03 auth: Debug: conn unix:/run/auth-userdb (pid=20421,uid=0): auth-master client: Disconnected: Connection closed (fd=20)

Falls jemand bereits Erfahrungen mit diesem spezifischen Mapping-Problem oder dem Verhalten von Samba-LDAP-Suchen hat, wäre ich für jeden Hinweis extrem dankbar. Das System läuft auf Ubuntu Server mit Dovecot Version 2.4.

Vielen Dank im Voraus! Nicky

Moderiert von schwarzheit:

Dem Spamfilter entrissen.

Bearbeitet von schwarzheit:

Bitte verwende in Zukunft Codeblöcke, um die Lesbarkeit zu verbessern! Und benutze bitte den Vorschaubutton. Danke.

leidenlinux27

Anmeldungsdatum:
25. Mai 2026

Beiträge: 30

Ich würde den userdb-Teil erst einmal komplett außerhalb von Dovecot nachstellen: mit exakt demselben Bind-DN und demselben Filter ein ldapsearch machen und dabei auch msDS-cloudExtensionAttribute1 explizit anfordern. Wenn der Search dort schon nichts oder das Attribut nicht liefert, liegt es nicht am fields-Block, sondern an Filter/ACL. Auffällig ist auch, dass dein gezeigter userdb-Filter nicht zu den Logzeilen passt; zum Eingrenzen würde ich vorübergehend nur auf mail=%{user} testen und danach erst die weiteren Alias-Attribute wieder ergänzen.

Antworten |