Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

We're using SugarCRM community edition 5.2.0f (Build 5688 running on OpenSuSE 11.1), and have the LDAP stuff set up so that users can log in with their AD credentials by contacting our DC (Server 2008).

We're having an issue with a couple of users; they've recently (a week or so ago) changed their AD passwords, and now can't log in to Sugar. Other users can still do LDAP logins, and if I set the problem users' passwords manually then they can log in too, but LDAP just doesn't want to know about them. I get the following in the log when they try:

Mon Sep 21 16:16:16 2009 [17854][-none-][FATAL] [LDAP ERROR][1]Operations error
Mon Sep 21 16:16:16 2009 [17854][-none-][FATAL] SECURITY: ldapauth: failed LDAP bind (login) by user@domain, could not construct bind_user
Mon Sep 21 16:16:16 2009 [17854][-none-][FATAL] SECURITY: User authentication for user@domain failed
Mon Sep 21 16:16:16 2009 [17854][-none-][FATAL] SECURITY: User authentication for user@domain failed
Mon Sep 21 16:16:16 2009 [17854][-none-][FATAL] FAILED LOGIN:attempts[1] - user@domain

Does anyone have any idea what might be going on here? Are there any restrictions on the allowable password - length, presence of special characters, etc? I know the user's new password ends with a single-quote, which is a SQL delimiter, but I assumed that the login code would correctly escape that.

share|improve this question
up vote 2 down vote accepted

Never mind, I worked it out; it's the user's password that's the problem. A tcpdump of LDAP data reveals that the single quote is being escaped to "'", and the DC is quite rightly saying "no". Given the choice of getting the user to change his password or learning enough PHP to debug the login script, I think I'll go for the former.

Also, I just found out that this is known bug - #24923, if anyone's interested.

share|improve this answer

Solution I used was to set the server as ldap:// and use port 3268 ..

Server: ldap://
Port: 3268
Base DN: ou=People,dc=example,dc=com
Bind Attribute: uid
Login Attribute: sAMAccountName
Auth User: serviceaccount
Auth Pass: serviceaccountpassword

Hope that is helpful to someone.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.