Rahul Chaturvedi wrote: > But, in our application we have all our passwords stored in another LDAP > attribute named as "displayName".
Ouch! Why are you doing this? This is very bad practice! The standard attribute 'displayName' has a very specific semantics. You should at least use a custom attribute for storing your proprietary password. If some LDAP client can read it I'd suspect that it gets displayed. Because that's what it's for. > Now after integrating CAS with LDAP we are not able to get the users > authenticated. Because, CAS by default search for value userPassword > attribte of LDAP. CAS does not search for the password. CAS correctly searches for the accompanying bind-DN by applying the configured search filter to the user-ID entered in the login form by the user. After finding the LDAP user entry it then sends a BindRequest with the password to authenticate the user (verify the password). So you have to implement a custom authc handler class which sends a CompareRequest instead of the BindRequest. Maybe there's already one. I don't know. > Pointers around how can we make CAS to pick up the password from > "displayName" instead of "userPassword" LDAP attribute. CAS should never pickup the password from the LDAP directory. In fact attributes containing passwords should not be readable by CAS. A CompareRequest should be sufficient. Ciao, Michael. -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
