lldap only uses groups for accounts

[dereulenspiegel]

So currently I am trying to setup Stalwart Mailserver with lldap as the LDAP directory. Stalwart is able to connect and I seem to be able to authenticate as the admin user. The problem is that when I list all the accounts from the stalwart-cli I only see my account and all other accounts are the groups my user belongs to. I think I am missing something, but I don't know what.
Here is the relevant part of my configuration:

[directory."ldap".filter]
name = "(&(|(objectClass=posixAccount))(uid=?))"
email = "(&(|(objectClass=posixAccount))(|(mail=?)(mailAlias=?)(mailList=?)))"
verify = "(&(|(objectClass=posixAccount))(|(mail=*?*)(mailAlias=*?*)))"
expand = "(&(|(objectClass=posixAccount))(mailList=?))"
domains = "(&(|(objectClass=posixAccount))(|(mail=*@?)(mailAlias=*@?)))"

[directory."ldap".attributes]
name = "uid"
type = "accounttype"
# description = ["principalName", "description"]
# secret = "userPassword"
groups = "memberOf"
email = "mail"
# email-alias = "mailAlias"
# quota = "diskQuota"

Maybe notable is, that I modified the type attribute so that it selects the admin user based on a custom attribute I created in lldap, because lldap does not support adding objectClasses to single users.

Any help and hints are appreciated.

Thanks in advance :)

[mdecimus]

Hi, the CLI can only be used with the internal directory. If you use an external directory the only information displayed is whatever is available on the Stalwart database.

[dereulenspiegel]

Thanks for the quick response. So I can try if I can authenticate against the IMAP or SMTP component with my ldap users?
But why do users named after the groups my user belongs to end up in the database? I can display and delete these accounts, but they reappear latest after a restart. I would expect to see no accounts at all then.

[mdecimus]

But why do users named after the groups my user belongs to end up in the database?

Stalwart stores in the database a mapping between account/group names to internal ids. You should not delete these accounts unless you're also deleting them on your LDAP directory.

[snailzrus]

I'm having the exact same problem with ldap authentication via Authentik's OpenLDAP with Stalwart, though I'm fairly sure it's Stalwart and the Rust ldap3 library, not Authentik.

When I sign-in via POP or IMAP, triggering Stalwart to query Authentik's LDAP Provider, Stalwart successfully authenticates with Authentik and grabs the LDAP directory. Once Stalwart has the directory, is dumps out this garbage into the trace log:

2024-09-19T02:50:27Z TRACE LDAP query executed (store.ldap-query) details = "(&(|(objectClass=posixAccount)(objectClass=user))(cn={redacted_userName}))", result = ["ResultEntry(StructureTag { class: Application, id: 4, payload: C([StructureTag { class: Universal, id: 4, payload: P([99, 110, 61, 108, 105, 97, 109, 46, 109, 99, 99, 108, 97, 117, 103, 104, 114, 121, 44, 111, 117, 61, 117, 115, 101, 114, 115, 44, 100, 99, 61, 108, 100, 97, 112, 44, 100, 99, 61, 103, 111, 97, 117, 116, 104, 101, 110, 116, 105, 107, 44, 100, 99, 61, 105, 111]) }, StructureTag { class: Universal, id: 16, payload: C([StructureTag { class: Universal, id: 16, payload: C([StructureTag { class: Universal, id: 4, payload: P([109, 97, 105, 108]) }, StructureTag { class: Universal, id: 17, payload: C([StructureTag { class: Universal, id: 4, payload: P([108, 105, 97, 109, 64, 115, 97, 108, 105, 101, 110, 116, 108, 97, 98, 115, 46, 99, 97]) }]) }]) }, StructureTag { class: Universal, id: 16, payload: C([StructureTag { class: Universal, id: 4, payload: P([109, 101, 109, 98, 101, 114, 79, 102]) }, StructureTag { class: Universal, id: 17, payload: C([StructureTag { class: Universal, id: 4, payload: P([99, 110, 61, 97, 117, 116, 104, 101, 110, 116, 105, 107, 32, 65, 100, 109, 105, 110, 115, 44, 111, 117, 61, 103, 114, 111, 117, 112, 115, 44, 100, 99, 61, 108, 100, 97, 112, 44, 100, 99, 61, 103, 111, 97, 117, 116, 104, 101, 110, 116, 105, 107, 44, 100, 99, 61, 105, 111]) }, StructureTag { class: Universal, id: 4, payload: P([99, 110, 61, 115, 116, 97, 108, 119, 97, 114, 116, 45, 101, 110, 97, 98, 108, 101, 100, 45, 117, 115, 101, 114, 115, 44, 111, 117, 61, 103, 114, 111, 117, 112, 115, 44, 100, 99, 61, 108, 100, 97, 112, 44, 100, 99, 61, 103, 111, 97, 117, 116, 104, 101, 110, 116, 105, 107, 44, 100, 99, 61, 105, 111]) }]) }]) }, StructureTag { class: Universal, id: 16, payload: C([StructureTag { class: Universal, id: 4, payload: P([99, 110]) }, StructureTag { class: Universal, id: 17, payload: C([StructureTag { class: Universal, id: 4, payload: P([108, 105, 97, 109, 46, 109, 99, 99, 108, 97, 117, 103, 104, 114, 121]) }]) }]) }, StructureTag { class: Universal, id: 16, payload: C([StructureTag { class: Universal, id: 4, payload: P([111, 98, 106, 101, 99, 116, 67, 108, 97, 115, 115]) }, StructureTag { class: Universal, id: 17, payload: C([StructureTag { class: Universal, id: 4, payload: P([116, 111, 112]) }, StructureTag { class: Universal, id: 4, payload: P([112, 101, 114, 115, 111, 110]) }, StructureTag { class: Universal, id: 4, payload: P([111, 114, 103, 97, 110, 105, 122, 97, 116, 105, 111, 110, 97, 108, 80, 101, 114, 115, 111, 110]) }, StructureTag { class: Universal, id: 4, payload: P([105, 110, 101, 116, 79, 114, 103, 80, 101, 114, 115, 111, 110]) }, StructureTag { class: Universal, id: 4, payload: P([117, 115, 101, 114]) }, StructureTag { class: Universal, id: 4, payload: P([112, 111, 115, 105, 120, 65, 99, 99, 111, 117, 110, 116]) }, StructureTag { class: Universal, id: 4, payload: P([103, 111, 97, 117, 116, 104, 101, 110, 116, 105, 107, 46, 105, 111, 47, 108, 100, 97, 112, 47, 117, 115, 101, 114]) }]) }]) }]) }]) }, [])"]

Typically this result is human readable, not just a bunch of nonsense. I think this is the Rust ldap3 library that's producing this non-standard LDAP query result. Testing an LDAP query with the ldapsearch util on the Stalwart linux host produces expected human readable results, so it's not what's being sent by Authentik, rather how Stalwart/Rust's ldap3 is taking/parsing it.

The problem that @dereulenspiegel and I are both having appears to be that Stalwart is parsing groups as users. Now, this may be because of how the Rust ldap3 library is behaving, or it may be a problem with Stalwart's parsing of the LDAP directory results, I'm not sure.

To show what we're experiencing, when my account is located by the LDAP query, it's also yielding all of the groups that I am a memberOf (an attribute we cannot lookup filter against with Stalwart for some reason). These groups appear inside the Accounts tab in the Stalwart Web GUI as an account, not a group in the Groups tab.

Further to this, none of the account attributes that should be collected from LDAP Object Attributes are appearing for the accounts. This includes the basics, such as the Account's email address from the 'Mail' Object Attribute not appearing within the Account listing.

I'm getting the sense that the Object Attributes not appearing is a visual bug because mail works, both incoming and outgoing, so obviously Stalwart knows my email address, but it does make it hard to know what Stalwart using when it's doing things like setting the Mailbox Quota.

[mdecimus]

Try upgrading to v0.10.0, now the information retrieved from the LDAP store is kept locally also.