LDAP groups created in Active Directory get an auto-generated sAMAccountName

[Ramalama2]

Environment

• defguard core 2.1.0, installed from the APT repository on Ubuntu 26.04
• Business license, LDAP sync against Active Directory (ldap_uses_ad = true)
• ldap_is_authoritative = true, group search base OU=Defguard,...
• ldap_groupname_attr = cn, ldap_group_obj_class = group

Problem

When defguard creates a group in Active Directory it sends only objectClass, cn and member
(crates/defguard_core/src/enterprise/ldap/mod.rs, add_group_with_members, ~line 895).
No sAMAccountName is sent, so AD generates a placeholder such as $V31000-U46U2D83SO25.

For users defguard already handles this: in AD mode it sets sAMAccountName explicitly
(enterprise/ldap/model.rs, ~line 177). Groups are not covered.

Renaming a group from defguard (PUT /api/v1/group/{id} → modify_group, modrdn) changes cn
but leaves the old sAMAccountName in place, so the two drift further apart with every rename.

Why it matters

cn is what defguard matches on, so the sync itself works. Everything on the Windows side that
addresses a group by its pre-Windows 2000 name breaks or becomes unreadable:

• whoami /groups on a client shows DOMAIN\$V31000-U46U2D83SO25 instead of DOMAIN\DG-FiBu
• Get-ADGroup -Identity DG-FiBu and net group DG-FiBu fail (they resolve via sAMAccountName)
• GPO security filtering, scripts and logon troubleshooting all show the placeholder

Groups created by hand in ADUC do not have this problem, because ADUC fills the field from cn.

Steps to reproduce

1. Configure LDAP sync against AD with a group search base.
2. In defguard, add a synced user to a group that does not exist in AD yet, e.g. DG-Test.
3. Defguard creates CN=DG-Test,OU=... in AD.
4. Inspect the object: Get-ADGroup -LDAPFilter "(cn=DG-Test)" | Select Name, SamAccountName.

Expected result

SamAccountName equals DG-Test, the same way ADUC and New-ADGroup behave.

Actual result

SamAccountName is $<random>.

Suggested fix

When ldap_uses_ad is true, derive sAMAccountName from the group name instead of leaving it to AD:

• strip the characters AD does not accept (" / \ [ ] : ; | = , + * ? < >) and any trailing period
  (length is not an issue: cn is limited to 64, sAMAccountName for groups allows 256);
• add_group_with_members: send the result as sAMAccountName; if AD still rejects the add
  (the value must be unique per domain, cn only per container), retry once without the
  attribute so AD falls back to the generated name;
• modify_group (rename): replace sAMAccountName the same way.

This keeps the current behaviour as a fallback and does not add any validation that would reject
group names users can create today.

Workaround

Fix the attribute once from PowerShell (the groups cannot be addressed by -Identity):

Get-ADGroup -LDAPFilter "(cn=DG-*)" -SearchBase "OU=Defguard,..." |
  ForEach-Object { Set-ADGroup $_ -SamAccountName $_.Name }

This has to be repeated after every rename done from defguard.