<< Back to previous view |
![]() |
[QB-128] LDAP Authentication password cannot be changed
|
|
Status: | Resolved |
Project: | QuickBuild |
Component/s: | None |
Affects Version/s: | None |
Fix Version/s: | None |
Type: | Bug | Priority: | Blocker |
Reporter: | Matthew Inger | Assigned To: | Robin Shen |
Resolution: | Fixed | Votes: | 0 |
Remaining Estimate: | Unknown | Time Spent: | Unknown |
Original Estimate: | Unknown |
Description |
I have configured an instance of quickbuild to connect to an OpenLDAP server. I login as one of the users from the LDAP server, and everything works fine, provided the user was not manully created. I then change the password in the ldap entry, and clear the credentials cache in the administration tab. If I then try to login as the new users, there are two big problems: 1. I get an error: ava.lang.NullPointerException com.pmease.quickbuild.security.ApplicationAuthenticationProvider.retrieveUser(ApplicationAuthenticationProvider.java:70) org.acegisecurity.providers.dao.AbstractUserDetailsAuthenticationProvider.authenticate(AbstractUserDetailsAuthenticationProvider.java:115) org.acegisecurity.providers.ProviderManager.doAuthentication(ProviderManager.java:183) org.acegisecurity.AbstractAuthenticationManager.authenticate(AbstractAuthenticationManager.java:45) org.acegisecurity.ui.webapp.AuthenticationProcessingFilter.attemptAuthentication(AuthenticationProcessingFilter.java:71) org.acegisecurity.ui.AbstractProcessingFilter.doFilter(AbstractProcessingFilter.java:199) .... 2. The typed in password is displayed in the URL bar (i've obfuscated it here manually> http://localhost:8080/j_acegi_security_check.do?j_username=minger&j_password=<xxxxxx> To me, this is a showstopper, as it basically stops the user from being able to change their password in the ldap. In general, it seems the user record in the database has to have the same password as the one in the ldap. I've verified this by creating a user manually with the same password as the ldap, and updating the authenticator in the database column for that user, and then logging in succesfully. If i do the same steps, but have different passwords, i get the exception above. Finally, i've also noticed that any user which is created manually, cannot change to being authenticated against the LDAP through the user interface (provided the matching password problem is solved). This would be a nice feature to have. Perhaps a select box on the user page which would allow the administrator to determine where a user's authentication is performed against. That way, if a user is manually created, an admin can just edit the user record, and change their authenticator to hook them up to the LDAP. |
Comments |
Comment by Tom McGlynn [ 21/Nov/06 08:51 AM ] |
This is a show stopper for us. We are required to change our passwords every three months. We want to use LDAP to avoid maintenance headaches. |
Comment by Robin Shen [ 21/Nov/06 06:17 PM ] |
Tom, This bug has been fixed. Have you tried with the latest version? Thanks. Robin |