 |
History
| Log In
|
|
|
|
[
Permlink
| « Hide
]
Robin Shen [16/Jun/25 01:30 AM]
Are they login via web UI? If so, please make sure the password takes effect, as the error is reported by AD.
They are attempting to log into QuickBuild through the web UI, but the new credentials are not working. However, since they can successfully log into their desktops using the same credentials, it confirms that the passwords have taken effect.
I am not sure what happens at AD side, as QB simply sends user credential to AD to be authenticated. You may test with some LDAP tool (https://jxplorer.org/) to bind as user DN and password, and I guess it won't work also.
Is there any cache that needs to be cleaned on user or server side?
I will download the tool and test it. Thanks I logged into QuickBuild using my domain user credentials and went to the 'My' tab to update the password to something like temp123. I confirmed that the 'Authenticator' was set to Active Directory, as specified in the Security Settings. After logging out, I was able to log back in with the new password.
However, it appears that my domain user account is now being treated as a local QuickBuild user, and authentication is no longer being routed through Active Directory. If you specified password for your account, you can login with both passwords. If input new password, local database will be used to authenticate user, and for old password, AD will be used. However once you login via AD, your specified password will be overriden with AD password in local database (password hash actually stored in local database).
We figured out the issue. It was with the bind user specifically its alias domain. Thank you for your help!
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Bug
Closed
Major
An issue with authenticating users through Active Directory