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/

Reply via email to