LDAP import users from multiple DNs

As we transition to the new Hyland Community, some post links may be temporarily disrupted as we finalize redirects. We apologize for the inconvenience and are working to resolve this as quickly as possible. Details.

fo1337

Hi all. I'm using Labs 3.1 Stable. I finally got the LDAP (AD) import working… Now I'm trying to find a way to import users from multiple locations, and I have 2 ideas but not sure how to implement this:

#1 idea: I think I could change my "ldap.synchronisation.personSearchBase" property in order to look at the root of the AD, and use the "ldap.synchronisation.personQuery" property to filter in the wanted users. The issue I have with this, is that I've heard the AD import from a single location was limited to 1000 users only. We have a *very* large user base and 1000 is really not enough. Is this limitation still in place as of 3.1 Stable?

#2 idea: The "ldap-synchronisation-context.xml" file makes mention of "stacking beans" in order to import users from multiple DNs. I'm not sure how to "stack beans". I can certainly copy and paste the bean and keep the same ID, is this what that means? Probably not, as 2 beans with the same name would clash. I'm not very familiar with these Java concepts, so I'm stuck. It looks like a nice solution tho.

Please help!

Thank you.

tvaughan77

I'm on labs 3/d, so I can't answer your first question, but I think I can help with your second.

A "stack" of beans is a series of Spring XML bean definitions (as found in the ldap-synchronization-context.xml) such that the beans usually refer to one another.  For example, the "ldapPeopleTrigger" bean references the "ldapPeopleImport" which references the "ldapPeopleExportService" bean. . . that's a "stack"

What you can do (without any code, I think) to import users from multiple DNs is something like the following:

1) Assume you have 2 search bases: ou=alpha,dc=foo,dc=com and ou=omega,dc=foo,dc=com

2) Set up the ldapPeopleExportSource to pull in users from the alpha base.  Either hard-code the searchBase, or use the properties file's ldap.synchronisation.personSearchBase (preferred).

3) Copy & pase the alphaLdapPeopleExportSource and rename it "omegaLdapPeopleExportSource".  Configure that bean to import from the omega search base (add another property to the properties file and just make sure the ${xxx} in the context file matches up)

4) Now copy & paste the ldapPeopleImport bean to be the omegaLdapPeopleImport

5) Scroll down to the ldapPeopleTrigger and add a new map entry to the "jobDataAsMap" section that references your omegaLdapPeopleImport.  The current map has a single (key,value) pair like this:

                <property name="jobDataAsMap">
                    <map>
                        <entry key="bean">
                            <ref bean="ldapPeopleImport"/>
                        </entry>
                    </map>
                </property>
‍‍‍‍‍‍‍‍‍

I'm pretty sure the String "bean" is arbitrary (at least, that's what these javadocs lead me to believe):
http://static.springframework.org/spring/docs/1.1.5/api/org/springframework/scheduling/quartz/JobDetailBean.html#setJobDataAsMap(java.util.Map)

So you can probably just do this:

                <property name="jobDataAsMap">
                    <map>
                        <entry key="bean">
                            <ref bean="ldapPeopleImport"/>
                        </entry>
                        <entry key="omegaBean">    <!–   I don't think this key matters. . . –>
                            <ref bean="omegaLdapPeopleImport"/>
                        </entry>
                    </map>
                </property>
‍‍‍‍‍‍‍‍‍‍‍‍

Now, if that works (and it's a big if), I would go back through that file and use Spring's configuration inheritance mechanism to clean up all that nasty copy & paste stuff you just did.  You'll probably end up copying 150 lines of XML and only changing 3, so to make it more maintainable, you can define abstract beans with all the common configuration options and then just override the stuff that's different in the concrete beans.  That's a subject for a different thread, though 😉