starred/lldap-lldap

Fork 0

mirror of https://github.com/lldap/lldap.git synced 2026-04-25 16:25:55 +03:00

[GH-ISSUE #875] [BUG] `lldap_password_manager` role does not see other users in the web UI #314

New issue

Open

opened 2026-02-27 08:16:36 +03:00 by kerem · 6 comments

kerem commented

2026-02-27 08:16:36 +03:00

Owner

Originally created by @jrbarronumd on GitHub (Mar 20, 2024).
Original GitHub issue: https://github.com/lldap/lldap/issues/875

Describe the bug
The lldap_password_manager role does not have permissions to manage any passwords

To Reproduce
Steps to reproduce the behavior:

Create user with lldap_password_manager role
Log in to LLDAP as that user
User permissions only allow viewing of that single account

Expected behavior
I would expect the lldap_password_manager role to be able to manage passwords of its own account and others.

Logs

2024-03-20T01:17:11.939297603+00:00  INFO     LDAP session [ 74.0ms | 0.10% / 100.00% ]
2024-03-20T01:17:12.056962837+00:00  INFO     ┕━ LDAP request [ 126µs | 0.05% / 0.17% ]
2024-03-20T01:17:12.056967597+00:00  DEBUG       ┝━ 🐛 [debug]:  | msg: LdapMsg { msgid: 3, op: ExtendedRequest(LdapExtendedRequest { name: "1.3.6.1.4.1.4203.1.11.1", value: Some("vec![...]") }), ctrl: [] }
2024-03-20T01:17:12.056973567+00:00  DEBUG       ┝━ get_user_groups [ 86.7µs | 0.12% ] user_id: "admin_user"
2024-03-20T01:17:12.057128688+00:00  DEBUG       │  ┕━ 🐛 [debug]:  | return: {GroupDetails { group_id: GroupId(5), display_name: GroupName("admins"), creation_date: 2024-03-18T20:45:10.271245499, uuid: Uuid("bunch of characters"), attributes: [] }, GroupDetails { group_id: GroupId(1), display_name: GroupName("lldap_admin"), creation_date: 2024-03-18T19:02:27.073584197, uuid: Uuid("bunch of characters"), attributes: [] }, GroupDetails { group_id: GroupId(4), display_name: GroupName("family"), creation_date: 2024-03-18T20:42:17.073042073, uuid: Uuid("bunch of characters"), attributes: [] }}
2024-03-20T01:17:12.057134948+00:00  DEBUG       ┕━ 🐛 [debug]:  | response: ExtendedResponse(LdapExtendedResponse { result: LdapResult { code: InsufficentAccessRights, matcheddn: "", message: "User `authelia_bind_user` cannot modify the password of user `admin_user`", referral: [] }, name: None, value: "vec![...]" })

Additional context
I hope I'm not missing something here, but I know that's very possible. Is the role in question configurable and I've not set it up right?

Originally created by @jrbarronumd on GitHub (Mar 20, 2024). Original GitHub issue: https://github.com/lldap/lldap/issues/875 **Describe the bug** The `lldap_password_manager` role does not have permissions to manage any passwords **To Reproduce** Steps to reproduce the behavior: 1. Create user with `lldap_password_manager` role 2. Log in to LLDAP as that user 3. User permissions only allow viewing of that single account **Expected behavior** I would expect the `lldap_password_manager` role to be able to manage passwords of its own account and others. **Logs** ``` 2024-03-20T01:17:11.939297603+00:00 INFO LDAP session [ 74.0ms | 0.10% / 100.00% ] 2024-03-20T01:17:12.056962837+00:00 INFO ┕━ LDAP request [ 126µs | 0.05% / 0.17% ] 2024-03-20T01:17:12.056967597+00:00 DEBUG ┝━ 🐛 [debug]: | msg: LdapMsg { msgid: 3, op: ExtendedRequest(LdapExtendedRequest { name: "1.3.6.1.4.1.4203.1.11.1", value: Some("vec![...]") }), ctrl: [] } 2024-03-20T01:17:12.056973567+00:00 DEBUG ┝━ get_user_groups [ 86.7µs | 0.12% ] user_id: "admin_user" 2024-03-20T01:17:12.057128688+00:00 DEBUG │ ┕━ 🐛 [debug]: | return: {GroupDetails { group_id: GroupId(5), display_name: GroupName("admins"), creation_date: 2024-03-18T20:45:10.271245499, uuid: Uuid("bunch of characters"), attributes: [] }, GroupDetails { group_id: GroupId(1), display_name: GroupName("lldap_admin"), creation_date: 2024-03-18T19:02:27.073584197, uuid: Uuid("bunch of characters"), attributes: [] }, GroupDetails { group_id: GroupId(4), display_name: GroupName("family"), creation_date: 2024-03-18T20:42:17.073042073, uuid: Uuid("bunch of characters"), attributes: [] }} 2024-03-20T01:17:12.057134948+00:00 DEBUG ┕━ 🐛 [debug]: | response: ExtendedResponse(LdapExtendedResponse { result: LdapResult { code: InsufficentAccessRights, matcheddn: "", message: "User `authelia_bind_user` cannot modify the password of user `admin_user`", referral: [] }, name: None, value: "vec![...]" }) ``` **Additional context** I hope I'm not missing something here, but I know that's very possible. Is the role in question configurable and I've not set it up right?

kerem added the

bug

frontend

labels

2026-02-27 08:16:36 +03:00

kerem commented

2026-02-27 08:16:36 +03:00

Author

Owner

@nitnelave commented on GitHub (Mar 20, 2024):

From the logs, it seems you're trying to modify the password of an admin account. Only admins can modify the password of admins, otherwise you would get a privilege escalation from password manager to admin.

Try with a regular user.

@nitnelave commented on GitHub (Mar 20, 2024): From the logs, it seems you're trying to modify the password of an admin account. Only admins can modify the password of admins, otherwise you would get a privilege escalation from password manager to admin. Try with a regular user.

kerem commented

2026-02-27 08:16:36 +03:00

Author

Owner

@jrbarronumd commented on GitHub (Mar 20, 2024):

Yeah, that was it. I was able to use Authelia's service to change a password for a non admin account. So the web UI does not allow users with that role to do anything, it's just for API access?

Thanks for the quick response. Sorry for the wasted time. I knew it would be something stupid on my end...

@jrbarronumd commented on GitHub (Mar 20, 2024): Yeah, that was it. I was able to use Authelia's service to change a password for a non admin account. So the web UI does not allow users with that role to do anything, it's just for API access? Thanks for the quick response. Sorry for the wasted time. I knew it would be something stupid on my end...

kerem commented

2026-02-27 08:16:36 +03:00

Author

Owner

@nitnelave commented on GitHub (Mar 20, 2024):

From the web UI, with that role you should be able to see all users (i.e. all the a read-only account can do), change your own details (that's the case for every user) and set non-admins' passwords (including other password manager accounts)

@nitnelave commented on GitHub (Mar 20, 2024): From the web UI, with that role you should be able to see all users (i.e. all the a read-only account can do), change your own details (that's the case for every user) and set non-admins' passwords (including other password manager accounts)

kerem commented

2026-02-27 08:16:36 +03:00

Author

Owner

@jrbarronumd commented on GitHub (Mar 20, 2024):

Ok, that's what I expected. When I log in as my Authelia bind user I can only see that account. I can edit email and display name, but the password field is not there. There are no navigation links to go to other pages in the UI, but I did just realize that if I manually type in the my.domain/users url, I can see the other users and edit names and emails. By default, when logging in, or clicking the LLDAP in the top left, it goes to my.domain/user/[active_user] as shown in the image below.

I don't necessarily care about the UI for this use case, since it will only ever need API access. And it seems that the API access performs as expected in my limited testing.

@jrbarronumd commented on GitHub (Mar 20, 2024): Ok, that's what I expected. When I log in as my Authelia bind user I can only see that account. I can edit email and display name, but the password field is not there. There are no navigation links to go to other pages in the UI, but I did just realize that if I manually type in the `my.domain/users` url, I can see the other users and edit names and emails. By default, when logging in, or clicking the `LLDAP` in the top left, it goes to `my.domain/user/[active_user]` as shown in the image below. I don't necessarily care about the UI for this use case, since it will only ever need API access. And it seems that the API access performs as expected in my limited testing. ![image](https://github.com/lldap/lldap/assets/39811147/fb5bdc22-b690-44cc-8a4e-e11c14d729be)

kerem commented

2026-02-27 08:16:36 +03:00

Author

Owner

@nitnelave commented on GitHub (Mar 20, 2024):

Oh, it might be a frontend outdated check that only checks if the user is admin or not. More generally, we don't really check the different permission levels and what they should see very well.

@nitnelave commented on GitHub (Mar 20, 2024): Oh, it might be a frontend outdated check that only checks if the user is admin or not. More generally, we don't really check the different permission levels and what they should see very well.

kerem commented

2026-02-27 08:16:37 +03:00

Author

Owner

@steverweber commented on GitHub (Apr 14, 2025):

when using user in lldap_password_manager the user is missing heading: "[Users]"
however the user can directly enter url "/users" and then manage user passwords.

@steverweber commented on GitHub (Apr 14, 2025): when using user in lldap_password_manager the user is missing heading: "[Users]" however the user can directly enter url "/users" and then manage user passwords.

kerem referenced this issue

2026-02-27 08:18:24 +03:00

[PR #314] [MERGED] build(deps): bump actions/checkout from 2 to 3.1.0 #672