| << Back to previous view |
|
[QB-166] Change in LDAP Bind User's password temporarily prevents logins
|
|
| Status: | Resolved |
| Project: | QuickBuild |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major |
| Reporter: | Tom McGlynn | Assigned To: | Robin Shen |
| Resolution: | Fixed | Votes: | 1 |
| Remaining Estimate: | Unknown | Time Spent: | Unknown |
| Original Estimate: | Unknown | ||
| Description |
|
When the LDAP Bind User changes password in LDAP, other users are locked out until the password is changed in the QuickBuild. The delay depends on whether the LDAP in use is replicated. It also depends on whether the Bind User's account was locked due to forced password changes. Here is the best case scenario: 1. Bind User changes password in LDAP - users can no longer login to QuickBuild. 2. Bind User immediately logs in to QuickBuild and changes password to match. 3. Users can now login again. Here is the worst case: 1. Bind User ignores notices that password will expire. Users are required to change their LDAP password every 90 days. 2. Bind User's password is disabled. Users cannot log in to QuickBuild. 3. Someone finally figures it out and yells at Bind User who then resets LDAP password, then synchronizes password in QuickBuild. 4. Now, after a day or so of lockout, users can login again. Suggestion to fix this is to allow self-binding. Login user is the Bind User. I made this same change to BuildForge and it works fine. I believe that users logging in generally have the same access as the Bind User. Many companies require periodic password changes. |
| Comments |
| Comment by Matthew Inger [ 05/Jan/07 10:13 AM ] |
|
I've looked at the code for this, and there is some reasoning behind why there is a specific bind user. Specifically, Active Directory typically requires a user@domain style login to bind to the server, so just inputting a username like "foo" will not get you logged in (even with the correct password). In this case, you need to bind to the directory, and search for a user with a given sAMAccountName: (&(sAMAccountName={0})(objectclass=user)) Once you have the LDAP entry, you can use it's context name and rebind using that. With active directory, this seems to be the only way to properly check the password. So, if your windows name in the domain "foo.com" is "foo", we would first bind to the controller, and lookup the entry with the following filter: (&(sAMAccountName=foo)(objectclass=user)) It would return an LDAP entry whose context name is "[email protected]". Then it can bind using that name and the entered password. Binding as "foo" does not work. That being said, the real solution is to have a specific ActiveDirectory authenticator which would have a setting which indicated the domain, and this could be tacked onto the end of the user name. This would eliminate the need for all the search conditions as needed a central bind user. I could write this authenticator rather easily, but how to plug it into the UI would be another story (tapestry has always kind of baffled me, and last i looked at the qb source code, it's not easy to add an authenticator). |
| Comment by Robin Shen [ 05/Jan/07 05:55 PM ] |
|
Matt, Thanks for this comment. In version 1.2, a separate LDAP authenticator will be added to provide the self-binding functionality. So it should not hurt the existing functionality connecting to AD. Thanks. Robin |