LDAP Server with three OU definitions retrieving same data on all
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎11-05-2018 03:22 AM
I've got an LDAP server configured which I'm able to browse and load records from.
The LDAP server has three different OU Definitions, with three different RDN's. All of them use "sAMAccountName" as Query field and they are pointing to the sys_user table.
If I navigate to the OU Definitions and select "Browse" from the Related links I'm able to view the matching data from each OU. But if I go to the related Data Source and select "Load All Records" I get the same result using all three data sources.
How come I am able to view the correct data when browsing the different OU definitions, but when actually loading records to an import table all three data sources (that are using those OU definitions) load the exact same records?
Any help is much appreciated.
- Labels:
-
Instance Configuration
-
Integrations
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎11-05-2018 11:57 AM
The issue seems to happen whenever I specify multiple OU definitions with different RDN.
It seems to somehow get stuck using the RDN from one of the OU definitions no matter which one is specified.
If I disable OU definition A, and then try to use OU definition B as the LDAP target for a Data source, I get an error message saying that OU definition A is disabled.
MID Server reported error: java.lang.Exception: LDAP Target OU=xx,OU=xx is not active for Server xx
If I enable OU definition A, and then try to use OU definition B as the LDAP target for a Data source, I get records from the RDN specified in OU definition A.

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎11-05-2018 12:53 PM
On your LDAP server, can you add OU=Users to the starting search directory so your OU definition just contains OU=x? Not sure if you are syncing over items like groups that you can't do this.
If you can't do that, try removing the OU=Users and just limit what's in the RDN field.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎11-06-2018 01:42 AM
Unfortunately that's not the way the structure is built.
The different OU definitions are looking for users in a structure like this:
Starting Dir
|--Country A
| |--Users
|--Country B
| |--Users
|--Country C
|--Users
So I need the RDN to be something like "OU=Users,OU=Country A" for each OU definition.

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎11-06-2018 04:40 AM
Ok. Just set your RDN to OU=Country A. Your filter - (&(objectClass=person)(sn=*)(!(objectClass=computer)) - will limit the results to users.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎11-06-2018 05:06 AM
Yes, that works fine, as long as I only have one OU Definition. But when I add a second OU definition with RDN for Country B the issue will return.
If I try to use the second OU Definition as the LDAP Target for a Data source, it will return data from the first OU Definition. This is where I think there is some kind of bug in the current version.
So far the only workaround I've found for this is to remove all OU definitions except one. I use that OU definition as the LDAP Target for all Data sources. In between importing data from each Data source I have to go and edit the RDN in the OU definition and set it to the correct OU.
I'm hoping this is a bug in the current release and patch, and that it will be fixed in the future.
The instance I'm working with is running Kingston patch 7.
The issue is preventing scheduled imports because the OU definition has to be manually updated for each Data source.