starred/lldap-lldap

Fork 0

mirror of https://github.com/lldap/lldap.git synced 2026-04-25 08:15:52 +03:00

[GH-ISSUE #1189] [FEATURE REQUEST] Generate password reset link via web UI #423

New issue

Open

opened 2026-02-27 08:17:13 +03:00 by kerem · 6 comments

kerem commented

2026-02-27 08:17:13 +03:00

Owner

Originally created by @MrDrMcCoy on GitHub (Jun 8, 2025).
Original GitHub issue: https://github.com/lldap/lldap/issues/1189

Motivation

This is to better support deployments that have no access to a valid SMTP server and cannot reset via email.

New user accounts and accounts where users have forgotten their password currently require the domain administrator to reset the password and send the new password to the user. This presents the following problems:

The domain administrator knows the password and can impersonate the account without the user's knowledge.
The available means of transmission may be insecure.
The user may fail to reset the password, leaving the temporary password and its exposure intact.

Describe the solution you'd like

Admins should be able to navigate to a user's account details and click a button to generate a reset URL for the user. This prevents the potential issues described above.

The button should be located beneath the existing " Change password" button. On pressing it, it should present a form modal with the following:

A TTL field with a default value of 24H, editable to any supported value. Some descriptive text for syntax and limits should be adjacent.
A text area with advice on disabling the account.
A submit button.

This should be followed by a replacement modal that contains the following:

A success or failure message.
The date/time stamp showing when the reset URL becomes invalid.
The URL for the reset in a copyable text field.
A close button.

Describe alternatives you've considered

Password resets via email are not possible in environments that cannot reasonably accommodate an email server and wish to avoid trusting cloud-hosted email.

Additional context
Add any other context or screenshots about the feature request here.

Originally created by @MrDrMcCoy on GitHub (Jun 8, 2025). Original GitHub issue: https://github.com/lldap/lldap/issues/1189 **Motivation** This is to better support deployments that have no access to a valid SMTP server and cannot reset via email. New user accounts and accounts where users have forgotten their password currently require the domain administrator to reset the password and send the new password to the user. This presents the following problems: 1. The domain administrator knows the password and can impersonate the account without the user's knowledge. 2. The available means of transmission may be insecure. 3. The user may fail to reset the password, leaving the temporary password and its exposure intact. **Describe the solution you'd like** Admins should be able to navigate to a user's account details and click a button to generate a reset URL for the user. This prevents the potential issues described above. The button should be located beneath the existing " Change password" button. On pressing it, it should present a form modal with the following: 1. A TTL field with a default value of 24H, editable to any supported value. Some descriptive text for syntax and limits should be adjacent. 2. A text area with advice on disabling the account. 3. A submit button. This should be followed by a replacement modal that contains the following: 1. A success or failure message. 2. The date/time stamp showing when the reset URL becomes invalid. 3. The URL for the reset in a copyable text field. 4. A close button. **Describe alternatives you've considered** Password resets via email are not possible in environments that cannot reasonably accommodate an email server and wish to avoid trusting cloud-hosted email. **Additional context** Add any other context or screenshots about the feature request here.

kerem added the

enhancement

label

2026-02-27 08:17:13 +03:00

kerem commented

2026-02-27 08:17:13 +03:00

Author

Owner

@nitnelave commented on GitHub (Jun 8, 2025):

I want to understand something: how would that be more secure than setting a random password for the user and sending it to them? What's the attack scenario where this would help?

If someone can intercept the password, they can intercept the password reset link. As long as the user changes their password on first login, these solutions seem equivalent to me.

There's also the assumption that the admin doesn't keep track of the password themselves to impersonate the user, but... They're the admin, they can change the password if they want to do that.

@nitnelave commented on GitHub (Jun 8, 2025): I want to understand something: how would that be more secure than setting a random password for the user and sending it to them? What's the attack scenario where this would help? If someone can intercept the password, they can intercept the password reset link. As long as the user changes their password on first login, these solutions seem equivalent to me. There's also the assumption that the admin doesn't keep track of the password themselves to impersonate the user, but... They're the admin, they can change the password if they want to do that.

kerem commented

2026-02-27 08:17:13 +03:00

Author

Owner

@MrDrMcCoy commented on GitHub (Jun 8, 2025):

@nitnelave

Apologies. I am a pretty new user, trying to get a handle on the provided user management process. In my previous testing, there didn't appear to be any way for users to change their own passwords. After trying again today, I now see that users, if they know their password, can log in and change their own account info. I must have made some mistake earlier, as this was something I attempted.

The ability to generate a password reset link would still be an improvement in reducing the steps involved for resetting passwords in environments where email servers and SMS are functionally not possible. Additionally, it prevents the case where the user fails to change the temporary password, leaving it exposed to the admin and any interceptors in transit.

There's also the assumption that the admin doesn't keep track of the password themselves to impersonate the user, but... They're the admin, they can change the password if they want to do that.

Changing the password is something the user would notice. Not knowing the user's password is the only way to ensure accountability in this regard. Sure, there are other ways for admins to access data and impersonate users, but the fewer avenues there are for that, the better.

Going beyond all this, some scheme for users to autonomously reset forgotten passwords without email or SMS would be ideal, but that would require a careful design doc and is out of scope for this suggestion.

@MrDrMcCoy commented on GitHub (Jun 8, 2025): @nitnelave Apologies. I am a pretty new user, trying to get a handle on the provided user management process. In my previous testing, there didn't appear to be any way for users to change their own passwords. After trying again today, I now see that users, if they know their password, can log in and change their own account info. I must have made some mistake earlier, as this was something I attempted. The ability to generate a password reset link would still be an improvement in reducing the steps involved for resetting passwords in environments where email servers and SMS are functionally not possible. Additionally, it prevents the case where the user fails to change the temporary password, leaving it exposed to the admin and any interceptors in transit. > There's also the assumption that the admin doesn't keep track of the password themselves to impersonate the user, but... They're the admin, they can change the password if they want to do that. Changing the password is something the user would notice. Not knowing the user's password is the only way to ensure accountability in this regard. Sure, there are other ways for admins to access data and impersonate users, but the fewer avenues there are for that, the better. Going beyond all this, some scheme for users to autonomously reset forgotten passwords without email or SMS would be ideal, but that would require a careful design doc and is out of scope for this suggestion.

kerem commented

2026-02-27 08:17:13 +03:00

Author

Owner

@nitnelave commented on GitHub (Jun 15, 2025):

That seems like an exceedingly niche feature, that I don't think really belongs in LLDAP. However, given that the implementation would likely be fairly low impact (generate the link and display it instead of sending it by email, increase the TTL of the link), I could be convinced by a well-written PR.

@nitnelave commented on GitHub (Jun 15, 2025): That seems like an exceedingly niche feature, that I don't think really belongs in LLDAP. However, given that the implementation would likely be fairly low impact (generate the link and display it instead of sending it by email, increase the TTL of the link), I could be convinced by a well-written PR.

kerem commented

2026-02-27 08:17:13 +03:00

Author

Owner

@MrDrMcCoy commented on GitHub (Jun 15, 2025):

Are deployments in homelabs behind residential ISPs that uncommon? We cannot self-host email, and many of us do not trust public cloud providers to maintain privacy.

As for a PR, I sadly do not know Rust, much less to the degree one would hope to maintain security in an authentication system. I have updated the initial issue text to be more descriptive.

@MrDrMcCoy commented on GitHub (Jun 15, 2025): Are deployments in homelabs behind residential ISPs that uncommon? We cannot self-host email, and many of us do not trust public cloud providers to maintain privacy. As for a PR, I sadly do not know Rust, much less to the degree one would hope to maintain security in an authentication system. I have updated the initial issue text to be more descriptive.

kerem commented

2026-02-27 08:17:14 +03:00

Author

Owner

@nitnelave commented on GitHub (Jun 16, 2025):

I think most people, even self hosters, tend to trust email. They sometimes choose a non free email provider that advertises privacy guarantees, or that self host on a provider's bare metal server, or they believe that e.g. Google stands more to lose by breaking the users trust than they stand to gain by exploiting the information in the email. Regardless, navigating this connected world without trusting email is a complex endeavour.

I can understand that you want to avoid it, but at that point sharing a temporary password by whatever means you consider secure should be enough. If it isn't, please understand that I don't have the time to implement such a niche use case.

@nitnelave commented on GitHub (Jun 16, 2025): I think most people, even self hosters, tend to trust email. They sometimes choose a non free email provider that advertises privacy guarantees, or that self host on a provider's bare metal server, or they believe that e.g. Google stands more to lose by breaking the users trust than they stand to gain by exploiting the information in the email. Regardless, navigating this connected world without trusting email is a complex endeavour. I can understand that you want to avoid it, but at that point sharing a temporary password by whatever means you consider secure should be enough. If it isn't, please understand that I don't have the time to implement such a niche use case.

kerem commented

2026-02-27 08:17:14 +03:00

Author

Owner

@thielj commented on GitHub (Sep 4, 2025):

The primary advantage of passing a user a link (with a longer expiration than 5 minutes, obviously) is that it enforces a password change before the user can login. This is typically what I want as well.

@thielj commented on GitHub (Sep 4, 2025): The primary advantage of passing a user a link (with a longer expiration than 5 minutes, obviously) is that it enforces a password change before the user can login. This is typically what I want as well.

kerem referenced this issue

2026-02-27 09:09:32 +03:00

[PR #423] [MERGED] add option to use insecure SMTP connection #732