User authentication not working after password change
andreimirt opened this issue · 3 comments
I am using the wrapper for some months now, and it works great. Now it's the first time a password for a user has been changed. The way I imagined it works is that when trying to authenticate using LDAP (via web, as initially necessary), if the password provided doesn't match the cached hash, then it checks against Azure servers and caches the new hash.
Unfortunately, software works how it was programmed, not how I imagine it.
I can authenticate in windows using the new password, but on the web interface, or on samba, I can only use the old password. To be more specific, LDAP fails to authenticate the user with the new password (valid in Azure).
The Azure-AD-LDAP-wrapper is set to sync at the default interval, every 30 minutes. But I believe this refers only to users and groups, not passwords, or changing password flags.
The maximum cache time for passwords is infinity, as it is by default. I considered changing it to something shorter, like 1 day, but then I would have to login via the interface daily, just to be able to access mapped drives in windows, if I am understanding things correctly.
How should I handle changing passwords? Should I specifically and manually delete the cache for a user in case of a password change? How?
I believe I was thorough reading the documentation, but sometimes I read something, and then I understand how I imagine it works, so my apologies if this is already clear somewhere in the documentation and I missed it.
I assume you are using the latest version, v2.0.1?
After setting a new password, you need to log in to the web GUI (DSM) with your new password (or with another tool that uses the direct ldap bind approach). If this fails, you need to look in the Docker log. Is it mentioned there why it fails?
Sorry, I jumped the gun. I should have troubleshooted the user more before troubleshooting the software.
The problem was trying to use the windows PIN, instead of the actual password, which hasn't changed. The PIN was the "new password".
I updated the internal documentation to prevent this issue from reoccurring.
Nevertheless, at least I found out about the new (2.0.1) version (currently on 1.8.2), which I now plan to upgrade to at the end of the week.
Thanks for your prompt support. This (non-)issue can be closed. I see I can close it myself as well, but I'm not sure if it's appropriate for me to close it. I wouldn't want to be over-hasty again.
Glad to hear that "only" that was the problem :)