Actually, my problems seem to have been resolved by XX-9626 "LDAP: Additional search filter should not be accounted for authentication". The search filter didn't _seem_ to be the problem in my case, but it might still be the underlying factor...
As long as it works, I'm happy :) Best regards, Anders Mydland 2011/5/26 George Niculae <[email protected]> > > On Thu, May 26, 2011 at 3:17 AM, George Niculae <[email protected]> wrote: > > 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 > > > > OK, here is what it happened in my case: I added 10 users using Apache > Directory Studio and specified password for. None of them were able to > bind so I went in AD admin interface and noticed that all were > disabled. I enabled accounts, reset passwords (with security policy > enforced by system), then I was able to log bind / login in sipXecs > user portal with all the newly added users. > Not sure this is also your case, but it worth double checking... > > George > _______________________________________________ > sipx-dev mailing list > [email protected] > List Archive: http://list.sipfoundry.org/archive/sipx-dev/ _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev/
