Matt, All I can say is some additional search request parameter might be causing this. We can do two things. We can turn on debugging and get a boat load of output from ADS and analyze that or we can capture the traffic using ethereal (etherape now I guess) and look at that.
What I want to do is figure out the exact set of parameters supplied to ADS by Sugar. Then go about reproducing the problem so we can get you a workaround or just fix the bug fast. Alex On 4/20/07, Matthew Schmidt <[EMAIL PROTECTED]> wrote:
Hi guys. Thanks for the reply. We're using 1.5.0. There are no entries in the ADS log that are useful. The ldif is attached. Unfortunately, the log I sent you was the debug log. I have no idea how the PHP ldap library does searches, so I assume search_filter:(uid=jimmy) on the ldap_rdn_lookup call would be the basic query. Thanks, Matt Alex Karasulu wrote: > On 4/20/07, Emmanuel Lecharny <[EMAIL PROTECTED]> wrote: >> >> Hi Matthew, >> >> I'm sorry, but the log you provided are really not suffisant for us to >> tell >> you what happened. We need more : >> 1) which ADS version are you using ? >> 2) do you have some ADS logs ? >> 3) can you provide a ldif wher we can see the uid=jimmy entry? > > > 4) Does SugarCRM have a detailed debug log that will show us the search > filter used? > 5) What do you have in your ApacheDS directory? > > Thanks ! >> >> >> On 4/20/07, Matthew Schmidt <[EMAIL PROTECTED]> wrote: >> > >> > Hi guys. I know this is a bit of a specific question, but I have been >> > able to successfully search and load users from two other Java >> > products. We use SugarCRM and it has an LDAP option. We've set the >> > baseDN and the authenticated user to bind as to do the search. The >> > initial bind of the authenticated user appears to be working fine, but >> > it seems that the search fails for the user. In Apache LDAP >> Studio, I'm >> > able to do a search with the same parameter and it seems to come back >> > fine. Can anyone shed any light on what error code 80 means to >> > ApacheDS? The error log follows from SugarCRM: >> > >> > DEBUG SugarCRM - Starting user load for jimmy >> > Fri 20 Apr 2007 02:10:56 PM EDT,249 [26544] DEBUG SugarCRM - ldapauth: >> > Connecting to LDAP server: rr.dzone.com >> > Fri 20 Apr 2007 02:10:56 PM EDT,430 [26544] INFO SugarCRM - >> > ldapauth.ldap_rdn_lookup: Bind succeeded, searching for uid=jimmy >> > Fri 20 Apr 2007 02:10:56 PM EDT,430 [26544] DEBUG SugarCRM - >> > ldapauth.ldap_rdn_lookup: base_dn:o=TwoBrokeGuys , >> > search_filter:(uid=jimmy) >> > *Fri 20 Apr 2007 02:10:56 PM EDT,514 [26544] FATAL SugarCRM - [LDAP >> > ERROR][80]Internal (implementation specific) error* >> > Fri 20 Apr 2007 02:10:56 PM EDT,514 [26544] DEBUG SugarCRM - >> > ldapauth.ldap_authenticate_user: ldap_rdn_lookup returned bind_user= >> > Fri 20 Apr 2007 02:10:56 PM EDT,515 [26544] FATAL SugarCRM - SECURITY: >> > ldapauth: failed LDAP bind (login) by jimmy, could not construct >> bind_user >> > Fri 20 Apr 2007 02:10:56 PM EDT,515 [26544] FATAL SugarCRM - SECURITY: >> > User authentication for jimmy failed >> > >> > >> > Thanks in advance, >> > Matt >> > >> >> >> >> -- >> Regards, >> Cordialement, >> Emmanuel Lécharny >> www.iktek.com >> > dn: cn=Jimmy Sellsmore,ou=Staff,ou=IncredibleMedia,o=TwoBrokeGuys objectClass: organizationalPerson objectClass: person objectClass: mozillaAbPersonObsolete objectClass: inetOrgPerson objectClass: top cn: Jimmy Sellsmore givenname: Jimmy mail: [EMAIL PROTECTED] sn: Sellsmore uid: jimmy userpassword:: bm90c2VjdXJl
