Stalwart doesn't assign users to groups with LDAP directory

Issues
1

Issue Description

I am having an issue concerning group membership: when a user is logged in Stalwart fetches all the attributes, including “memberOf” listing their memberships (the logs state that), the groups tab shows those groups but they has no members, is there a way i can retrieve and sync memberships also? it would drastically simplify mailing administration.

Method for authentication is “Bind authentication after lookup” (that is what works at least at my setup)
Filter Name is (&(|(objectClass=user)(objectClass=group))(sAMAccountName=?))
Filter Email is (&(|(objectClass=user)(objectClass=group))(|(mail=?)(mailAlias=?)))

Groups attribute is set to “memberOf”

Is there anything else that could help targeting the issue?

Stalwart Version

v0.15.x

Installation Method

Binary (Linux)

Database Backend

PostgreSQL

Blob Storage

PostgreSQL

Search Engine

PostgreSQL

Directory Backend

LDAP

I have reviewed the documentation and FAQ and confirm that my issue is NOT addressed there.

on

I have searched this support forum (open and closed topics) and confirm this is not a duplicate.

on

I understand that topics in this category are triaged by a bot first but a human reply will follow up. If I’d prefer a human-only reply, I’ll add the no-ai tag to my topic.

on

2

The core issue is that Stalwart shows the groups a user belongs to (via memberOf on the user entry), but the groups themselves show no members because Stalwart needs to be able to look up group entries and identify their groupClass. There are two related problems to check in your Active Directory setup:

1. groupClass mismatch

By default Stalwart identifies LDAP entries as groups when their objectClass is groupOfNames. Active Directory uses group instead. You need to set groupClass to "group" in your Directory object so that Stalwart recognises AD group entries correctly.

2. Your filterLogin covers both users and groups but may not resolve group entries correctly

Your current filter (&(|(objectClass=user)(objectClass=group))(sAMAccountName=?)) is fine for lookup, but Stalwart needs to be able to fetch a group entry and know it is a group via the groupClass setting above.

3. filterMemberOf for reverse lookup

When Stalwart needs to know which groups a user belongs to, it can use either:

  • attrMemberOf – reads the memberOf attribute directly off the user entry (your current approach, default ["memberOf"]), OR
  • filterMemberOf – performs a separate LDAP search for groups that contain the user as a member. Default: (&(objectClass=groupOfNames)(member=?)).

For Active Directory, if you want to go via a reverse search, you’d set filterMemberOf to something like:

(&(objectClass=group)(member=?))

where ? is replaced with the user’s DN at runtime.

Summary of recommended changes to your Directory object:

{
  "@type": "Ldap",
  "groupClass": "group",
  "filterMemberOf": "(&(objectClass=group)(member=?))"
}

Set groupClass to "group" (matching AD’s object class) and optionally configure filterMemberOf with the AD-appropriate filter so Stalwart can also look up group membership from the group side.

Relevant docs:

This is an automated reply from the Stalwart Help Bot. Other community members may follow up if this answer is incomplete or wrong.

3

Group membership in Stalwart is stored per user and resolved lazily: it’s populated when each user authenticates or is reconciled, and there’s no bulk “pull all members of this group” sync from LDAP. So a group can exist (synced via someone’s memberOf) while its member list looks empty until the individual users have logged in. The list fills in over time.

One thing to check with AD specifically: when Stalwart resolves a memberOf group DN it replaces it with the group’s email from the attrEmail attribute (default mail), and AD group objects often don’t have a mail attribute, in which case the link is dropped. Confirm your group objects carry whatever you’ve set attrEmail to. See stalw.art/docs/auth/backend/ldap.

4

Exactly that happens - when user logs in the list of groups they are the member of are populated and shown in Groups tab but neither the logged user itself or other users that are members of the same groups has that group membership it has 0 members any way.

It has no difference if a group has different type Universal or Security group or has it or doesn’t have a mail address set.
The interesting part is that many of these groups cannot be edited or deleted giving an error “GROUP_NAME was not found”.
The mail address is not populated in those added groups however.

When logged in as test user the trace log finds user memberships:
2026-06-18T12:44:05Z TRACE LDAP query executed (store.ldap-query) details = “(&(|(objectClass=user)(objectClass=group))(sAMAccountName=check))”, result = [[“objectClass”, “top, person, organizationalPerson, us
er”], [“sAMAccountName”, “check”], [“memberOf”, “CN=SOME_GROUP_ONE,OU=PATH,OU=PATH,OU=PATH,DC=domain,DC=local, CN=SOME_GROUP_TWO,OU=PATH,OU=PATH,OU=PATH
,DC=domain,DC=local”], [“pwdLastSet”, “134262466972912005”], [“mail”, “[email protected]”], “CN=check,OU=TEST,OU=Users,OU=Accounts,OU=PATH,DC=domain,DC=local”]

The LDAP directory has the following attributes set:
directory.ldap.attributes.class = “objectClass”
directory.ldap.attributes.description = “displayName”
directory.ldap.attributes.email = “mail”
directory.ldap.attributes.groups = “memberOf”
directory.ldap.attributes.name = “sAMAccountName”
directory.ldap.attributes.quota = “diskQuota”
directory.ldap.attributes.secret-changed = “pwdLastSet”
directory.ldap.base-dn = “ou=PATH,dc=domain,dc=local”
directory.ldap.bind.auth.method = “lookup”
directory.ldap.bind.dn = “cn=ldap_binder,ou=PATH,ou=PATH,ou=PATH,ou=PATH,dc=domain,dc=local”
directory.ldap.bind.secret = “PASSWORD”
directory.ldap.cache.size = 157286400
directory.ldap.cache.ttl.negative = “1h”
directory.ldap.cache.ttl.positive = “8h”
directory.ldap.filter.email = “(&(|(objectClass=user)(objectClass=group))(|(mail=?)))”
directory.ldap.filter.name = “(&(|(objectClass=user)(objectClass=group))(sAMAccountName=?))”
directory.ldap.timeout = “15s”
directory.ldap.tls.allow-invalid-certs = false
directory.ldap.tls.enable = false
directory.ldap.type = “ldap”
directory.ldap.url = “ldap://AD_DC_IP:389”

Directory path are correct and point to OUs that contains appropriate objects.
We’re unfortunately still running AD DC Windows Server 2008 R2, could the problem be in LDAP connection/attributes details in our outdated schema?
I hope the provided info would be helpful somehow at least, thank you.

5

Two things are going on here. Stalwart doesn’t pull a group’s member list from LDAP; each user’s memberOf entries are resolved at that user’s login, so a group only fills with members as its members sign in. There’s no reverse “members of this group” sync, which is why a group can show zero members for a while.

The decisive part for you: when Stalwart resolves a memberOf DN it reads the group’s email attribute (attrEmail, default mail) and identifies the group by that email, using the local part as the group’s name. If a group object has no mail value it can resolve, that membership is dropped right there and the user is never recorded in the group, which is why even the logged-in user shows as not a member. So the mail attribute on the group objects themselves is effectively required, not optional. Can you confirm the AD group objects actually carry a mail value that’s an address in a domain you’ve configured in Stalwart? Your filter.email also only matches on mail, which lines up with this.

The “GROUP_NAME was not found” on edit/delete is the other side of the same coin: those are orphaned group principals from earlier syncs whose stored name no longer maps to a live, email-bearing AD group, so the UI can’t resolve them. Once mail is set correctly on the groups, remove the orphans and re-authenticate a member to re-sync. Docs are at stalw.art/docs/auth/backend/ldap; I’ll get the email-keyed group behavior written up there, since it isn’t spelled out today.

6

It seems that I generally understand the sync mechanism - those aspects concerning the individual user group memberships resolution when user logs in.

Yes, I can confirm those groups I am testing at the moment have an email attribute set, the mail domain is set to the domain that is the primary domain configured in Stalwart.

The LDAP query retrieve the following attributes for a “check” user:

[
    [
        "pwdLastSet",
        "134262466972912005"
    ],
    [
        "objectClass",
        "top, person, organizationalPerson, user"
    ],
    [
        "memberOf",
        "CN=GROUP_FROM_AD,OU=PATH,OU=PATH,OU=PATH,DC=domain,DC=local, (FEW OTHER GROUP INSTANCES SYNCED)"
    ],
    [
        "sAMAccountName",
        "check"
    ],
    [
        "mail",
        "[email protected]"
    ],
    "CN=check,OU=PATH,OU=PATH,OU=PATH,OU=PATH,DC=domain,DC=local"
]

The synced groups have the following attributes after the member “check” user logged in:

            {
                "id": 51,
                "type": "group",
                "name": "GROUP_FROM_AD_1"
            },
            {
                "id": 50,
                "type": "group",
                "name": "GROUP_FROM_AD_2"
            },
            {
                "id": 52,
                "type": "group",
                "name": "GROUP_FROM_AD_3"
            },

When the groups with the email attribute set are synced they become editable (without “Was not found” error) and deletable but no mail address is bound to the synced groups just the name

So the groups themselves are synced but have no mail address and no members listed (even the logged in users)

Are there any other things I can test or check in order to debug groups sync further?

7

I just realized that you’re on v0.15.x, the provided advise was for v0.16.x. Please upgrade to v0.16.x as many issues with groups have been fixed on the latest release.

8

Is it worth it waiting for a v1.0.0 release? I have planned to migrate on a first release version not to perform any other additional in-between migrations as well

9

This recent blog post may be helpful Zero open bug reports: The road to Stalwart 1.0 | Stalwart