| Key: |
QB-166
|
| Type: |
Bug
|
| Status: |
Resolved
|
| Resolution: |
Fixed
|
| Priority: |
Major
|
| Assignee: |
Robin Shen
|
| Reporter: |
Tom McGlynn
|
| Votes: |
1
|
| Watchers: |
0
|
|
If you were logged in you would be able to see more operations.
|
|
|
QuickBuild
Created: 21/Nov/06 09:10 AM
Updated: 23/Jan/07 04:27 AM
|
|
| Component/s: |
None
|
| Affects Version/s: |
None
|
| Fix Version/s: |
None
|
|
|
Original Estimate:
|
Unknown
|
Remaining Estimate:
|
Unknown
|
Time Spent:
|
Unknown
|
|
|
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.
|
|
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. |
Show » |
|
Change in LDAP Bind User's password temporarily prevents logins
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).