LDAP login incorrectly triggers admin revocation

[foxing-quietly]

Just had some weird issues when trying to log into my new Tuwunel installation with Element X. When authenticating via LDAP, the login flow incorrectly triggers admin room membership changes, revoking the user's admin status and removing them from the admin room.

Environment

• Tuwunel version: 1.4.7
• LDAP provider: Authentik LDAP outpost
• Clients tested: Element X (Android/iOS), Element Desktop

With a single admin user

Login fails entirely with the following error in logs:

2025-12-10T14:47:10.278949Z ERROR tuwunel_service::rooms::timeline::build: Last admin cannot leave the admins room.
  at src/service/rooms/timeline/build.rs:218 on tuwunel:worker ThreadId(3)
  in tuwunel_api::client::session::ldap::ldap with user_id=@dark:nether.im
  in tuwunel_api::client::session::login with client=2605:a601:a6dd:c400:95c7:54f5:d4fb:10bf body.login_info=Password { identifier: Some(UserIdOrLocalpart("dark")), user: None, address: None, medium: None, .. }

The client receives "wrong username or password" despite credentials being correct.

With multiple admin users

Login succeeds, but the authenticating user is removed from the admin room with the message:

You were removed from nether.im Admin Room by @conduit:nether.im
Reason: Admin Revoked

The user must be manually re-added as admin via !admin users make_user_admin <username> after each LDAP login.

Element Desktop

Element Desktop does not exhibit this behavior - LDAP login works correctly without affecting admin status. This suggests Element X may be using a different authentication code path that triggers the bug.

Steps to reproduce

1. Configure Tuwunel with LDAP authentication (Authentik LDAP outpost in my case)
2. Have an admin user authenticate via LDAP
3. Attempt to log in with Element X

Expected behavior

LDAP authentication should validate credentials and create a session without modifying admin room membership.

Actual behavior

The LDAP login code path at tuwunel_api::client::session::ldap::ldap calls into rooms/timeline/build which attempts to remove the user from the admin room.

Workaround

Create a second admin user before attempting LDAP login with Element X. After login, re-add the affected user as admin using:

!admin users make_user_admin <username>

[jevolk]

Thank you, this is an exemplary report ❣️

[jevolk]

I reviewed the code for this, though I'm not experienced with LDAP so you might have to fill in the blanks where my understanding ends.

• Admin access is only revoked when an LDAP login occurs for a user which LDAP does not recognize as admin.
• LDAP admins are determined by the configuration of admin_base_dn which falls back to base_dn if unset.

I am not familiar with how consistent or inconsistent different LDAP implementations are and what "admin" means, if it's an arbitrary attribute, etc. The example given in the config file is "ou=admins,dc=example,dc=org". If you determine admin some other way and it doesn't match, Tuwunel admin will be revoked to remain consistent.

If this is a configuration issue let me know, but if there is no real "admin" in LDAP and everyone's attributes are different: I can add new configuration to not revoke admin in this case, which would allow manually setting Tuwunel admins independent of LDAP.

Let me know if any of that makes sense.

[kuhnchris]

Hi, i just accidentally tripped over this during my inital setup.

First I tried to set my actual admin permission, which in our environment is dictated by the filter (memberOf=cn=admins,cn=groups,cn=accounts,dc=...) - ldapsearch is finding my user just fine - but running tuwunel actually never assigned me the admin role.

No problem, I read up the config file again and saw here (

tuwunel/tuwunel-example.toml

Line 2016 in 3af78ac

# If left blank, administrative state must be configured manually for each

) that if I do not specify the admin_filter, it should be fine if I define my user by hand. Causes a bit of manual labor adding the admins, but the organization is flat enough for it to not be a big issue.

So first I went and made myself admin by running docker compose run -it homeserver --execute "users make_user_admin kuhnc" - which succeeded - afterwards I removed the admin_filter line from the toml config, and started the server again - but now, despite having no admin_filter set, it tries to remove my admin right on login (via Element):

homeserver-1  | 2026-01-06T19:20:41.270042Z  INFO tuwunel_router::serve::plain: Listening on [0.0.0.0:6167]
homeserver-1  |   2026-01-06T19:20:44.685399Z ERROR tuwunel_service::rooms::timeline::build: Last admin cannot leave the admins room.
homeserver-1  |     at src/service/rooms/timeline/build.rs:218 on tuwunel:worker ThreadId(3)
homeserver-1  |     in tuwunel_api::client::session::ldap::ldap with user_id=@kuhnc:...
homeserver-1  |     in tuwunel_api::client::session::login with client=1.2.3.4 body.login_info=Password { identifier: Some(UserIdOrLocalpart("kuhnc")), user: None, address: None, medium: None, .. }
homeserver-1  |

Maybe I misunderstood the documentation?
I do use the templated bind_dn tho, maybe this helps.

bind_dn = "uid={username},cn=users,cn=accounts,dc=..."

The LDAP server is a FreeIPA server, incase it matters.
If I should provide you with any more infos, please let me know!

Thanks
Chris

[kuhnchris]

Sorry for the double post, but I investigated this a little bit further.
As a preface, I barely have any rust experience yet, and I only followed the code logic, but from my understanding:
We come in through https://github.com/matrix-construct/tuwunel/blob/main/src/api/client/session/ldap.rs - there we have
https://github.com/matrix-construct/tuwunel/blob/bd0a0acf4a996146ff1e73614c847accdf8e179d/src/api/client/session/ldap.rs#L25C29-L25C40
which basically identifies if we are a valid user and if we have admin permissions, guarded by the config check

tuwunel/src/service/users/ldap.rs

Line 79 in bd0a0ac

if !config.admin_filter.is_empty() {

yet when the code returns to the session/ldap.rs we do not check against this guard, and basically, if that filter is not set, we do not have the is_admin flag within us (i.e. it's false).
https://github.com/matrix-construct/tuwunel/blob/bd0a0acf4a996146ff1e73614c847accdf8e179d/src/api/client/session/ldap.rs#L68-79

So, wouldn't we simply need to guard this add/removal of admin role with an additional check against the config as in the service/users/ldap.rs ? I sadly have no idea if we have access to the config object at that particular location.

Maybe this helps a little bit!

Cheers!
Chris

[x86pup]

I'm no expert in LDAP by any means, but I think I do agree with this that adding another check of the "admin_filter is not empty" to prevent LDAP login flow session management (src/api/session) of admin users could fix this, based on following the flow of the code as well. I didn't write the code for this though so I'll let Jason make the final judgement on that.

And yes config options can be checked against anywhere in src/api so there shouldn't be issues accessing it. It would be services.config.ldap.admin_filter here just like earlier above match services.config.ldap.bind_dn.as_ref() is checked.

[kuhnchris]

Additionally we could also introduce another flag called "ldap_admin_removal_on_nogroup" which could trigger this - as I do get the sentiment, for example, that there is an configuration issue, and somehow the filter ends up giving admin permissions to everyone, and the admin wants to rectify this (albeit I assume this is usually during setup) - so this would also be a way to "mass-remove" a "incorrect given admin role based on a misconfiguration" - alternatively we could provide a admin command "!admin ldap sync_admin_group" that could be run on-demand to fix this potential issue.

But for the core of the issue, guarding the add/removal of admin on an empty filter seems to be a wise choice regardless.

Also thanks x86pup for looking over it aswell :-)

[jevolk]

Resolved by #254. Thank you!