LDAP: error code 50

[bparis]

Hi,

if you need to authenticate against an ldap server in the situation where the uid is not in the DN, alfresco will search the DN making a query filterde with (&(objectclass=inetOrgPerson)(uid=entered_username))

To make this query succeeding, your ldap server has to permit the "principal" user in alfresco to query ALL attributes.  In a welldown ldap environment, only the attributes you really need should be available, so you get

javax.naming.NoPermissionException: [LDAP: error code 50 - Search not permitted for any attribute]; remaining name 'o=organization, c=be'

i think the code in LDAPUserRegistry.java should be modify to avoid this:

line 874 in method resolveDistinguishedName(String userId)

        userSearchCtls.setReturningAttributes(new String[] {});

should replaced with

        userSearchCtls.setReturningAttributes(new String[] {"uid"});

Bernard

[dward]

userSearchCtls.setReturningAttributes(new String[] {});

states that we don't want any attributes in our search result. We don't need the uid - we already have it.

[bparis]

I know we already have the uid….  the idea is simply to ask an attribute we can read (anyone, but uid is certainly readable) instead of ALL attributes.

I just tested that we even could simply comment out the line
userSearchCtls.setReturningAttributes(new String[] {});

to avoid the ldap -50 error

B

[dward]

The javadoc for SearchControls says this

    /**
     * Specifies the attributes that will be returned as part of the search.
     *<p>
     * null indicates that all attributes will be returned.
     * An empty array indicates no attributes are returned.
     *
     * @param attrs An array of attribute ids identifying the attributes that
     *           will be returned. Can be null.
     * @see #getReturningAttributes
     */
‍‍‍‍‍‍‍‍‍‍‍‍

What LDAP server are you using?

[bparis]

well, … strange !

Our server is Sun Directory Server (version 5.2p6)

b

[dward]

Well it looks like maybe the bug is in Sun Directory Server. But if your workaround helps us interoperate better with it we should probably add it. I don't see how it could break other directory servers. I have logged http://issues.alfresco.com/jira/browse/ALF-3868 .

[bparis]

from strange to very strange:

doing this
userSearchCtls.setReturningAttributes(null);

makes the search successfull !

b