On Fri, Sep 17, 2010 at 4:25 AM, Douglas Hubler <[email protected]> wrote:
> On Thu, Sep 16, 2010 at 6:58 PM, Josh M. Patten <[email protected]> > wrote: > > Regarding 4.3 LDAP, I just upgraded my test install to the latest 4.3 > version and blew away the database, starting fresh. I am still seeing the > bind issue I reported before where when a user is trying to log in with > their AD credentials sipXconfig, instead of searching for their account > based on the username they input and authenticating with the DN of the user > found in the search, is trying to bind as the user that is defined to > perform the LDAP lookups under LDAP/AD but is using the password the user > entered. > > > Mircea, > > Here is the patch you submitted to try to fix this and I think this > not right. You're using the BIND creds. explicitly, right? We need > to make an LDAP api call to check the params.getSecret() back to the > LDAP server if I understand this correctly. > > > protected void additionalAuthenticationChecks(UserDetails > userDetails, > > UsernamePasswordAuthenticationToken authentication) { > // passwords are checked in ldap layer > + //make sure that LDAP bind password is rejected > + LdapConnectionParams params = > m_ldapManager.getConnectionParams(); > + if (ObjectUtils.equals(authentication.getCredentials(), > params.getSecret())) { > + throw new BadCredentialsException(messages.getMessage( > + > "AbstractUserDetailsAuthenticationProvider.badCredentials", > + "Bad credentials"), userDetails.getUsername()); > + } > return; > The method: additionalAuthenticationChecks is authomatically called in LDAP security model after the authenticator successfully verifies the existence of the user. By default, the LDAP authenticator accepts users with BIND password AND users with LDAP password. For example if we have the user mirceac defined in LDAP with LDAP password "1234" and imported in sipXconfig, and lets assume that the LDAP BIND password is "qwert", then, by default BOTH mirceac/1234 and mirceac/qwert would be accepted But we don't want to accept mirceac/qwert, because the BIND password should be used only by the administrator when he configures the LDAP server. No user should get authenticated with this password Given this behaviour, what I did was only to add functionality - as an additional authentication check - to reject user/LDAP bind password Please let me know if my understanding is wrong... some concrete examples that does not fit in the current authenticator functionality would help me a lot Thanks! Mircea > _______________________________________________ > sipx-users mailing list > [email protected] > List Archive: http://list.sipfoundry.org/archive/sipx-users/ >
_______________________________________________ sipx-users mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-users/
