When integrating Dovecot with LDAP authentication, a common stumbling block appears in the logs:

imap(user): Error: user user: Couldn't drop privileges: User is missing UID (see mail_uid setting)

From your logs, we can see the authentication attempt follows this sequence:

1. PAM authentication fails (password mismatch)
2. System passwd lookup fails (unknown user)
3. LDAP authentication succeeds but fails at privilege dropping

The error occurs because Dovecot cannot determine which system UID to use for the LDAP-authenticated user. While your LDAP configuration specifies uid=1001,gid=1001 in user_attrs, several factors prevent this from working:

First, verify your LDAP user actually has these attributes by running:

ldapsearch -x -H ldap://192.168.128.45:3268 \
-D "cn=Administrator,cn=Users,dc=company,dc=example,dc=com" \
-w passwd -b "dc=company,dc=example,dc=com" \
"(sAMAccountName=charyorde)" uidNumber gidNumber

Then modify your dovecot-ldap.conf.ext:

# Use numeric UID/GID from LDAP
user_attrs = \
  sAMAccountName=home=/var/vmail/example.com/%$, \
  uidNumber=uid, \
  gidNumber=gid

# If LDAP doesn't contain numeric IDs, map to static values
user_attrs = \
  sAMAccountName=home=/var/vmail/example.com/%$, \
  =uid=1001, \
  =gid=1001

Ensure the UID/GID exists on your system:

# Create vmail user if not exists
getent passwd 1001 || sudo groupadd -g 1001 vmail
getent passwd 1001 || sudo useradd -u 1001 -g vmail -d /var/vmail -s /usr/sbin/nologin vmail

# Set permissions
sudo chown -R 1001:1001 /var/vmail
sudo chmod -R 770 /var/vmail

Add these critical settings to dovecot.conf:

# Define default UID/GID for mail access
first_valid_uid = 1000
last_valid_uid = 2000
mail_uid = 1001
mail_gid = 1001

service imap {
  # Drop privileges to this user
  user = $default_internal_user
}

After configuration changes:

sudo doveconf -n | grep -E 'uid|gid|user_attrs'
sudo systemctl restart dovecot
tail -f /var/log/mail.log

Successful authentication should now show:

imap(user): Logged in uid=1001 user=user@example.com

If issues persist, enable debug logging:

# In dovecot.conf
auth_debug = yes
auth_debug_passwords = yes
auth_verbose = yes
mail_debug = yes

Check for these common pitfalls:

• LDAP schema differences (Active Directory vs OpenLDAP)
• Multiple userdb/passdb declarations causing conflicts
• SELinux/apparmor restrictions on mail directories

---

When integrating Dovecot with LDAP authentication, a common roadblock developers encounter is the error message:

Couldn't drop privileges: User is missing UID (see mail_uid setting)

This occurs when Dovecot successfully authenticates against LDAP but fails to map the user properly to system permissions.

Looking at your dovecot-ldap.conf.ext configuration, the key issue lies in the user_attrs mapping:

user_attrs = sAMAccountName=home=/var/vmail/example.com/%$,uid=1001,gid=1001

The fixed UID/GID assignment (1001) might not match your system's actual user mapping. Let's examine better approaches.

For proper LDAP integration, you need either:

# Option 1: Static mapping (if uidNumber exists in LDAP)
user_attrs = sAMAccountName=home=/var/vmail/example.com/%$,uidNumber=uid,gidNumber=gid

# Option 2: Dynamic fallback
user_attrs = sAMAccountName=home=/var/vmail/example.com/%$,=uid=vmail,=gid=vmail

Here's a tested configuration that resolves the UID issue:

# /etc/dovecot/dovecot-ldap.conf.ext
hosts = 192.168.128.45:3268
dn = cn=Administrator,cn=Users,dc=company,dc=example,dc=com
dnpass = "passwd"
auth_bind = yes
ldap_version = 3
base = dc=company, dc=example, dc=com

# Improved attribute mapping
user_attrs = \
  sAMAccountName=home=/var/vmail/%d/%n, \
  uidNumber=uid, \
  gidNumber=gid, \
  =mail=maildir:/var/vmail/%d/%n

user_filter = (&(sAMAccountName=%Ln))
pass_filter = (&(ObjectClass=person)(sAMAccountName=%u))

Ensure your system has the vmail user/group created:

sudo groupadd -g 5000 vmail
sudo useradd -g vmail -u 5000 vmail -d /var/vmail -m

After configuration changes, test with:

doveadm user username@example.com
doveadm auth test username@example.com password

If issues persist, enable debug logging:

auth_debug = yes
auth_debug_passwords = yes
auth_verbose = yes

If your LDAP doesn't contain uidNumber/gidNumber attributes, consider using a static mapping:

userdb {
  driver = static
  args = uid=vmail gid=vmail home=/var/vmail/%d/%n
}