LDAP group filter breaks login + Question / UX issue

[d4rkbl00d]

Environment:

• Defguard version: 2.0.2
• LDAP server: Synology Directory Server (Samba-based Active Directory)
• Deployment: Docker on Synology NAS

Bug 1: Group filter breaks LDAP login

When setting "Limit synchronization to these groups" to Defguard (the CN of the AD group), login fails for users who are verified members of that group.
Without the group filter → login works fine with AD credentials.
With group filter Defguard → login fails with:

LDAP bind test for user CN=testuser,CN=Users,DC=lab,DC=local successful
User testuser is not in LDAP sync groups, not allowing to login through LDAP.

Verified via ldapsearch that the user is correctly listed as member:

# Defguard, Users, lab.local
dn: CN=Defguard,CN=Users,DC=lab,DC=local
member: CN=testuser,CN=Users,DC=lab,DC=local

And memberOf on the user object contains:
memberOf: CN=Defguard,CN=Users,DC=lab,DC=local
Additionally the sync log shows Defguard parsing the group name incorrectly:
filter = (&(objectClass=group)(cn=DC=local))
It searches for cn=DC=local instead of cn=Defguard, suggesting the group CN is being parsed incorrectly from the DN.

Question / UX issue: Enrollment requires setting a password for LDAP users

When starting the enrollment process for an LDAP-synced user, the enrollment wizard requires setting a new password.
After testing: login to the web UI works with both the enrollment password and the AD/LDAP password. So functionally it works, but the UX is confusing — it is unclear why an LDAP user needs to set a password during enrollment at all, since they already have AD credentials.
Is this by design? If so, what is the purpose of the enrollment password for LDAP users?

[yhay81]

There are two separate things here.

1. The cn=DC=local log points to the value stored in ldap_sync_groups

In 2.0.2 the sync-group field is a comma-separated list of group names, not a list of full DNs. The web form literally splits the field on commas before saving it: SettingsLdapPage.tsx. Therefore entering:

CN=Defguard,CN=Users,DC=lab,DC=local

creates four configured group names, the last of which is DC=local; that produces exactly the cn=DC=local search you saw.

For Synology/Samba AD, save these values instead:

Limit synchronization to these groups: Defguard
Group search base: CN=Users,DC=lab,DC=local
Group object class: group
Group name attribute: cn
Group member attribute: member
User member attribute: memberOf

After saving, the expected group lookup is (&(objectClass=group)(cn=Defguard)). Defguard 2.0.2 includes #3028, which searches that name under the group search base and then uses the actual returned DN for membership filtering. The v2.0.2 implementation is here: resolve_group_dns().

If the UI really contains only Defguard but a fresh sync still logs cn=DC=local, the running backend has stale settings or is not the 2.0.2 core image you think it is. Re-save the field, restart the core container, and verify the image digest/version plus the settings returned by the API. The backend cannot derive DC=local from the name Defguard in this code path.

2. The enrollment password is a Defguard-local password

The current enrollment flow unconditionally strength-checks the submitted password and calls user.set_password(...) in Defguard's database, even when user.from_ldap is true: activate_user() in v2.0.2. It then marks LDAP remote enrollment complete. For an already-existing LDAP user, the LDAP helper detects that the LDAP account exists and skips creating/changing it, so the original AD password remains valid as well.

That is why both passwords work: one authenticates against Defguard's local hash and the other through LDAP. It is current behavior, not evidence that the two passwords were synchronized. I agree the UX is unclear; if the intended policy is strictly LDAP-only, requiring and retaining a second local credential should be treated as a product/security UX request because 2.0.2 does not special-case the password step for LDAP-origin users.