authelia: Resetting password using AD shows error message: "There was an issue resetting the password"
After successfully config Authelia with Active Directory and using it for several testing sites. We’re trying to reset password through it, but after use the link send to the user’s email, only shows the next error message: "“There was an issue resetting the password” and the password isn’t reset.
In the Authelia logs find this:
level=error msg="Unable to update password: Unable to update password.
Cause: LDAP Result Code 53 \"Unwilling To Perform\": 00002035: LdapErr: DSID-0C090F22,
comment: Operation not allowed through GC port, data 0, v3839\x00"
method=POST path=/api/reset-password remote_ip=1.1.1.1 stack="github.com/authelia/authelia/internal/middlewares/authelia_context.go:64
(*AutheliaCtx).Error\ngithub.com/authelia/authelia/internal/handlers/handler_reset_password_step2.go:32
ResetPasswordPost\ngithub.com/authelia/authelia/internal/middlewares/authelia_context.go:49
AutheliaMiddleware.func1.1\ngithub.com/fasthttp/router@v1.2.2/router.go:348
(*Router).Handler\ngithub.com/authelia/authelia/internal/middlewares/log_request.go:14
LogRequestMiddleware.func1\ngithub.com/valyala/fasthttp@v1.14.0/server.go:2162
(*Server).serveConn\ngithub.com/valyala/fasthttp@v1.14.0/workerpool.go:223
(*workerPool).workerFunc\ngithub.com/valyala/fasthttp@v1.14.0/workerpool.go:195
(*workerPool).getCh.func1\nruntime/asm_amd64.s:1373
goexit"
Actually I’m using the Administrator account for the connection between Authelia and AD, and doesn’t seem to be an permissions issue. But don’t know if perhaps is a config mistake.
Thanks
About this issue
- Original URL
- State: closed
- Created 4 years ago
- Comments: 24 (14 by maintainers)
@daurpam you can set that up relatively easily by configuring a ADCS role, and allowing auto enrollment my DC’s. On their next GPUPDATE they will get a cert.
Hi @daurpam,
looks like you are connecting via an unsecured ldap connection rather than connecting via ldaps (ldap over ssl). The Microsoft Active Directory does not allow changing the password via an unsecured ldap connection.
https://support.microsoft.com/en-us/help/264480/description-of-password-change-protocols-in-windows
https://support.microsoft.com/en-us/help/269190/how-to-change-a-windows-active-directory-and-lds-user-password-through
So to be able to change the users password via the password reset link you should switch to ldaps. To do this change the connection scheme in your configuration from ldap to ldaps:
Please do not use ‘skip_verify: true’ for production use. Avoid this by adding the ad controller certificate to your trusted certificates store in your authelia docker container or bare metal host OS.
For more details on configuring ldap and ldaps have a look in the docs: https://www.authelia.com/docs/configuration/authentication/ldap.html
Best Regards Alex
@daurpam looks like your error is related too with
0000052D. Keep in mind that Authelia isn’t aware of any password history/complexity settings you may have configured.Generally I agree with the points @james-d-elliott has made, we’ll look into the first one and see what we can do.
I’ll think a little more the other points too and report back accordingly.
The possible issue here is different implementations return differing errors. MSAD error is slightly different, but we may be able to utilize 0000052D which is ERROR_PASSWORD_RESTRICTION.
I think the proper way to handle this is in your filter, as you don’t want to allow users with disabled or locked accounts to sign in either. Doing this should prevent them changing the password all together. Maybe we should add some more examples that show how to do this with MSAD/Samba (I have it setup like this in MSAD, not sure how to go about it in Samba). I could see in the future adding more complex control flows for expired passwords (a feature that would allow someone already signed in or with a 2FA method to reset their expired password via the web). Also maybe a control flow for disabled accounts to reenable them (both opt in features).
I think the maximum we should be doing is returning a generic error “Failed to handle your request” when something in the password reset process fails, as if we display something along the lines of “this is an invalid user” it will allow username enumeration which is bad for security.
See what @nightah thinks.
Hello, I can confirm that Authelia writes password to userPassword attribute leaving the password visible in plaintext and not having effect for password change. For modern AD deployment you should write double quoted password in utf-16 encoding to unicodePwd attribute. Tested behaviour with Samba 4.x over LDAPS which is pretty much what AD does.
For more info see Microsoft page: https://www.google.com/url?sa=t&source=web&rct=j&url=https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-adts/6e803168-f140-4d23-b2d3-c3a8ab5917d2&ved=2ahUKEwiNmLLZ7L3sAhWBlIsKHcmaBOkQFjAAegQIAxAB&usg=AOvVaw1rY7AjrflCMcM6mrnEjIUI
At best you have users disable password reset in Authelia, at worst you have bunch of Authelia instances live where users have attempted to change pass, concluded it doesnt work and now they have their password visible in plaintext…
Next time please add proper integration tests instead of mocking incorrect interfaces. Samba is free option to test correct behaviour with AD…