Problem in LDAP-setup

Friends is there any way to authenticate users using LDAP ,i am working on luntbuild(a build automation tool) which is build using spring framework,i need help in resolving how to configure the authentication properties as i need to authenticate users from luntbuild,any help would be appreciated
Thanks

Hi,

I've recently been working on an updated LDAP authentication provider which we're looking for feedback on prior to the next release. The code is in CVS (in the package org.acegisecurity.providers.ldap) and there is an LDAP version of the contacts sample application which you can take a look at. It's lacking an LDAP server at the moment, but that will be included later. It should give you an idea of how to set up the configuration.

The relevant code packages are:

http://acegisecurity.sourceforge.net...e-summary.html
http://acegisecurity.sourceforge.net...e-summary.html
http://acegisecurity.sourceforge.net...e-summary.html
http://acegisecurity.sourceforge.net...e-summary.html

Let us know how you get on.

Luke.

Hello Luke,

I managed to authenticate my users to our Lotus Domino servers. The configuration is much easier than in previous versions.

I'll try Active Directory and Oracle Internet Directory, too.

:)

Great. Please let us know how you get on as we'd like to iron out any potential problems in advance. I think we may require an extra configuration parameter for Active Directory login using Windows domain-style usernames.

Thanks for the feedback.

Luke.

Code:

---

    <bean
        id="initialDirContextFactory"
        class="org.acegisecurity.providers.ldap.DefaultInitialDirContextFactory">
        <constructor-arg value="ldap://myserver:389" />
    </bean>

    <bean
        id="ldapAuthenticationProvider"
        class="org.acegisecurity.providers.ldap.LdapAuthenticationProvider">
        <constructor-arg>
            <bean class="org.acegisecurity.providers.ldap.authenticator.BindAuthenticator">
                <constructor-arg>
                    <ref local="initialDirContextFactory" />
                </constructor-arg>
                <property name="userDnPatterns">
                    <list>
                        <value>cn={0}</value>
                    </list>
                </property>
            </bean>
        </constructor-arg>
        <constructor-arg>
            <bean class="org.acegisecurity.providers.ldap.populator.DefaultLdapAuthoritiesPopulator">
                <constructor-arg>
                    <ref local="initialDirContextFactory" />
                </constructor-arg>
                <constructor-arg>
                    <value>o=groups</value>
                </constructor-arg>
                <property name="convertToUpperCase">
                    <value>true</value>
                </property>
                <property name="rolePrefix">
                    <value></value>
                </property>
            </bean>
        </constructor-arg>
    </bean>

---

The groups have the form
APPNAME_ROLE/Groups

where APPNAME is the name off the application (obviously) and ROLE is something like ADMIN, EDITOR or READER. This makes rolePrefix unneccessary.

Web user names are NOT hierarchical (Flat names unlike Notes names.) but it'd be easy to add something like /USERS in userDnPatterns.

Next will be Oracle Internet Directory (OID).

Code:

---

    <bean
        id="initialDirContextFactory"
        class="org.acegisecurity.providers.ldap.DefaultInitialDirContextFactory">
        <constructor-arg value="ldap://myoracle.server:389/dc=company,dc=com" />
    </bean>

    <bean
        id="ldapAuthenticationProvider"
        class="org.acegisecurity.providers.ldap.LdapAuthenticationProvider">
        <constructor-arg>
            <bean
                class="org.acegisecurity.providers.ldap.authenticator.BindAuthenticator">
                <constructor-arg>
                    <ref local="initialDirContextFactory" />
                </constructor-arg>
                <property name="userDnPatterns">
                    <list>
                        <value>cn={0},cn=Users</value>
                    </list>
                </property>
            </bean>
        </constructor-arg>
        <constructor-arg>
            <bean
                class="org.acegisecurity.providers.ldap.populator.DefaultLdapAuthoritiesPopulator">
                <constructor-arg>
                    <ref local="initialDirContextFactory" />
                </constructor-arg>
                <constructor-arg>
                    <value>cn=groups</value>
                </constructor-arg>
                <property name="convertToUpperCase">
                    <value>true</value>
                </property>
                <property name="groupSearchFilter">
                    <value>(uniquemember={0})</value>
                </property>
                <property name="groupRoleAttribute">
                    <value>cn</value>
                </property>
                <property name="rolePrefix">
                    <value></value>
                </property>
            </bean>
        </constructor-arg>
    </bean>

---

The DN of a group is like cn=APPNAME_ROLE,cn=GROUPS,dc=company,dc=com.
Again rolePrefix is unneccessary in this context.
You can refine the groupSearchFilter e.g. (&(objectclass=groupOfUniqueNames)(uniqueMember={0 }))

Again configuration was easy and works flawlessly.

@Luke
MS AD is a different beast. I don't think the current implementation is able to use it. (Or did I miss something.)
My problem was that in our domain user and group dns are very deep. Something like cn=Mickey Mouse,ou=FunDepartment,ou=Paderborn,ou=Germany,ou= Europe,dc=Disney,dc=com.
We have about 500+ ous, so listing them all in userDnPatterns is no option, unfortunatelly.

Just an idea:
Extend AbstractLdapAuthenticator (anyone for a good name?)
authenticate should then first bind with managerDn/managerPassword and search for an entry where sAMAccountName matches username. (sAMAccountName should be variable.)
This would give an array of DNs.
Last step is trying to bind all DNs with password. The first that binds without an error is the valid account.

As far as I can see you can also use this to authenticate against Oracle or Domino when anonymous binding is disabled on these plattforms.

Are you working on something like this? Or do you have other ideas/plans? If you need help, I could write some code and test it against our Active Directory domain.

ok, Acegi can even use MS Active Directory when you read the javadocs.

First it binds using ldapuser/paderborn/germany/company/com, does the search for the username, re-binds with the found dn and then reads the attribute memberOf. (So it is possible! Forget what I said earlier.)

Code:

---

    <bean
        id="initialDirContextFactory"
        class="org.acegisecurity.providers.ldap.DefaultInitialDirContextFactory">
        <constructor-arg value="ldap://myserver:389/dc=company,dc=com" />
        <property name="managerDn">
            <value><![CDATA[cn=ldapuser,ou=paderborn,ou=germany,dc=company,dc=com]]></value>
        </property>
        <property name="managerPassword">
            <value>some password</value>
        </property>
        <property name="extraEnvVars">
            <map>
                <entry>
                    <key>
                        <value>java.naming.referral</value>
                    </key>
                    <value>follow</value>
                </entry>
            </map>
        </property>
    </bean>

    <bean
        id="userSearch"
        class="org.acegisecurity.providers.ldap.search.FilterBasedLdapUserSearch">
        <property name="searchSubtree">
            <value>true</value>
        </property>
        <property name="initialDirContextFactory">
            <ref local="initialDirContextFactory" />
        </property>
        <property name="searchFilter">
            <value>(sAMAccountName={0})</value>
        </property>
    </bean>

    <bean
        id="ldapAuthenticationProvider"
        class="org.acegisecurity.providers.ldap.LdapAuthenticationProvider">
        <constructor-arg>
            <bean
                class="org.acegisecurity.providers.ldap.authenticator.BindAuthenticator">
                <constructor-arg>
                    <ref local="initialDirContextFactory" />
                </constructor-arg>
                <property name="userSearch">
                    <ref local="userSearch" />
                </property>
            </bean>
        </constructor-arg>
        <constructor-arg>
            <bean
                class="org.acegisecurity.providers.ldap.populator.DefaultLdapAuthoritiesPopulator">
                <property name="userRoleAttributes">
                  <value>memberOf</value>
                </property>
                <property name="convertToUpperCase">
                    <value>true</value>
                </property>
                <property name="rolePrefix">
                    <value></value>
                </property>
            </bean>
        </constructor-arg>
    </bean>

---

The only problem with this solution is that you get the DN of the group, i.e.
cn=APPNAME_ROLE,ou=groups,ou=paderborn,ou=germany, dc=company,dc=com. This is not very nice in the taglib.

Doing a groupsearch for member={0} and using cn as the result will fix this.

Unfortunatelly in our configuration ou=groups is the second entry in the hierarchy and not the last before dc=company,dc=com.
Maybe creating another initialDirFactory with root DN dc=com and groupSearchBase dc=company will fix this.

Has anyone tried this yet?

btw, setting java.naming.referral to follow got rid of the nasty javax.naming.PartialResultException.

Ok, this is it. A working configuration for Acegi Security and Microsoft Active Directory 2003.

Only one issue remains:
I don't know how to configure groupSearchBase for groups in multiple different OUs (e.g. ou=Germany and ou=India).

Code:

---

    <bean
        id="initialDirContextFactory"
        class="org.acegisecurity.providers.ldap.DefaultInitialDirContextFactory">
        <constructor-arg value="ldap://myserver:389/dc=company,dc=com" />
        <property name="managerDn">
            <value>cn=ldapuser,ou=paderborn,ou=germany,dc=company,dc=com></value>
        </property>
        <property name="managerPassword">
            <value>some password</value>
        </property>
        <property name="extraEnvVars">
            <map>
                <entry>
                    <key>
                        <value>java.naming.referral</value>
                    </key>
                    <value>follow</value>
                </entry>
            </map>
        </property>
    </bean>

    <bean
        id="userSearch"
        class="org.acegisecurity.providers.ldap.search.FilterBasedLdapUserSearch">
        <property name="searchSubtree">
            <value>true</value>
        </property>
        <property name="initialDirContextFactory">
            <ref local="initialDirContextFactory" />
        </property>
        <property name="searchFilter">
            <value>(sAMAccountName={0})</value>
        </property>
    </bean>

    <bean
        id="ldapAuthenticationProvider"
        class="org.acegisecurity.providers.ldap.LdapAuthenticationProvider">
        <constructor-arg>
            <bean
                class="org.acegisecurity.providers.ldap.authenticator.BindAuthenticator">
                <constructor-arg>
                    <ref local="initialDirContextFactory" />
                </constructor-arg>
                <property name="userSearch">
                    <ref local="userSearch" />
                </property>
            </bean>
        </constructor-arg>
        <constructor-arg>
            <bean
                class="org.acegisecurity.providers.ldap.populator.DefaultLdapAuthoritiesPopulator">
                <constructor-arg>
                    <ref local="initialDirContextFactory" />
                </constructor-arg>
                <constructor-arg>
                    <value>ou=germany</value>
                </constructor-arg>
                <property name="convertToUpperCase">
                    <value>true</value>
                </property>
                <property name="rolePrefix">
                    <value></value>
                </property>
                <property name="searchSubtree">
                    <value>true</value>
                </property>
                <property name="groupSearchFilter">
                    <value>member={0}</value>
                </property>
                <property name="groupRoleAttribute">
                    <value>cn</value>
                </property>
            </bean>
        </constructor-arg>
    </bean>

---

Hi,

Thanks a lot for your feedback and testing!

On the groupSearchBase issue, can't you just specify the context above your ou's for germany, india etc?

Alternatively, I can change the code to take an array of DNs and perform the search within each. Or you can extend DefaultAuthoritiesPopulator. I'll have a look at it and see if I can make some improvements.

cheers,

Luke.