🐛: Secret attribute binding still required even with Bind auth and "Secret changed" attribute

[DodoLeDev]

What happened?

From what I have seen here, using Bind Auth on an LDAP directory should allow us not to fill the Secret attribute binding, and just use the "Secret changed" one.

However, by doing this, I am facing an authentication error: Account does not contain secrets, just like the following issue.

By digging further, I found that Stalwart does not actually request this "Secret changed" attribute:

Log of LDAP requests:

conn=1 op=0 BIND dn="uid=stalwart,cn=users,cn=accounts,dc=example,dc=org" method=128 version=3
conn=1 op=2 SRCH base="dc=example,dc=org" scope=2 filter="(&(|(objectClass=posixaccount)(objectClass=posixgroup))(uid=johndoe))" attrs="objectClass uid objectClass displayName memberOf mail"

You can also see objectClass requested twice

How can we reproduce the problem?

I can reproduce the problem by doing the following steps:

• Add an LDAP directory
• Enable Bind Auth
• Do not fill the "Secret" attribute binding
• Fill the "Secret changed" attribute binding
• Login with an LDAP account
• "Unauthorized"

Version

v0.11.x

What database are you using?

RocksDB

What blob storage are you using?

RocksDB

Where is your directory located?

SQL

What operating system are you using?

Docker

Relevant log output

#=== Stalwart log ===#
ERROR Authentication error (auth.error) listenerId = "http", localPort = 8080, remoteIp = 1.2.3.4, remotePort = 1234, details = Authentication error (auth.error) { details = Account does not contain secrets, causedBy = crates/common/src/auth/oauth/token.rs:239, causedBy = crates/common/src/auth/oauth/token.rs:53 }, causedBy = crates/jmap/src/auth/oauth/token.rs:129

#=== LDAP requests log ===#
conn=1 op=0 BIND dn="uid=stalwart,cn=users,cn=accounts,dc=example,dc=org" method=128 version=3
conn=1 op=2 SRCH base="dc=example,dc=org" scope=2 filter="(&(|(objectClass=posixaccount)(objectClass=posixgroup))(uid=johndoe))" attrs="objectClass uid objectClass displayName memberOf mail"

Code of Conduct

• I agree to follow this project's Code of Conduct

[mdecimus]

Set the log level to trace and make sure that your LDAP server is actually returning a value for the password changed attribute.

[aksdb]

In my case the TRACE log line shows that only a few attributes are returned (mail, mailAlias, uid), and a lot other attributes that are in the directory (cn, givenName, password_changed, etc.) are not included. I can see all the other attributes though, if I query ldap directly (with the same bind as stalwart). That also seems to fit with the log output in the ticket, where the attribute isn't even included in the query; so it looks like Stalwart doesn't actually request the value in the first place.

Regarding "secret changed": https://stalw.art/docs/auth/backend/ldap/ doesn't document this attribute at all, btw.

Couldn't this attribute be optional in general? As long as the bind-call succeeds for the user credentials, logging them in should work. Having the option to invalidate their sessions could be nice, but I think that is somewhat unusual (at least I haven't seen such a requirement in all other LDAP integrations I use. None of them require access to the password hash or a change timestamp; they simply perform the bind and then go with the result.)

[aksdb]

Ah, looks like the secret-changed attribute is indeed not requested:
https://github.com/stalwartlabs/mail-server/blob/main/crates/directory/src/backend/ldap/config.rs#L94-L105