On Thu, Apr 28, 2011 at 11:27 AM, Anders Mydland <[email protected]> wrote: > I probably misinterpreted XX-8657, so please disregard that comment. > > I do also understand the fallback mechanism itself. > > Can you comment on the actual login procedure in the LDAP layer? I realize > that an external library is being used, but I believe this is what should > happen: > > 1. Do a search for the username given in the login form to find the user's > full DN > 2. Attempt to bind to LDAP using the specified DN and the given password. > 3. The authenticator will grant or deny access > > I will be looking more thoroughly into this later today (European time), but > it would appear that this is what actually happens in my case: > > 1. The authenticator will do an LDAP search for "<ROOT>" (same as "empty"??) > according to Wireshark, and not for the username specified. > 2. No valid results are returned. > 3. The authenticator will then try to bind to LDAP using the user DN used by > sipXecs for importing users, along with the password given by the end user > in the login form! > 4. LDAP login always fails - because the authenticator never attempts to > bind with the username given in the login form. >
I took a pcap and after step 4 authenticator tries to bind to LDAP with credentials provided in login form. However in my tests there are users that can bind with the given password and users that cannot do this (you can check if badPwdCount attribute increments after portal login failure). Not clearly yet why some users cannot bind (maybe AD authentication is not using the password specified but another one) but if badPwdCount increments then sipXecs binds with correct user / password and there is something wrong in AD. Will keep looking and come back with findings George _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev/
