HR sync to LDAP - specify destination OU?

[darren_hague]

Hi all,

<b>Note</b>: We are not using NetWeaver IdM on my project, so the following refers only to tools available in NetWeaver ABAP+Java 7.0. The HR - LDAP sync I talk about has been around since R/3 4.7.

I am configuring a scenario to synchronise employees from HR to LDAP (Active Directory in this case). The company's AD instance has several top-level OUs containing users, and I want new users to be created in another top-level OU (e.g. OU=NewUsers,dc=company,dc=com).

As standard in transaction LDAP, I can specify the LDAP server to use OU=NewUsers, but then existing users only get synchronised if they are underneath OU=NewUsers (i.e. users in other top-level OUs fdo not get synced).

I need existing users to be synchronised if they exist anywhere in the directory, and currently the only way to do this is to specify the LDAP server as dc=company,dc=com, which means that all new users get put in the top of the directory tree instead of in OU=NewUsers.

Can anyone tell me how to set up HR-LDAP sync so that new users get put in OU=NewUsers but all users in other OUs still get synced?

Best regards,

Darren

[c_c2]

Darren,

8 years later, did you managed to get what you needed?

[Frank_Buchholz]

Are you moving entries from "OU=NewUsers,dc=company,dc=com" to other locations in the directory? Well, then it will be difficoult to sync. these entries avter you have moved them.

If HR knows the location of every entry in the directory, that means HR knows the complete dn of every employee, then you can try to set up several LDAP sync jobs with different selection of the employees. These jobs are using different LDAP servers pointing to different base entries.

Kind regards

Frank Buchholz

[darren_hague]

Hi Frank,

Yes, we are moving the users to other locations afterwards. The NewUsers OU is the place where IT look for newly created users - once the users are given email addresses etc by IT then they are moved to the correct OU. Synching after the move is no problem in principle because the SAP sync job does a search based on user ID over the whole subtree first.

Unfortunately there is no connection between the HR org structure (hierarchical) and the AD OU structure, which is geographical in our case.

It looks like we may have to go with the option of creating new users at the top of the AD tree so that the subtree search for synching will work. This is a shame, because we would rather put new users tidily away in their own OU.

Cheers,

Darren

[Frank_Buchholz]

Hi Darren,

what about using two sync jobs with two different LDAP servers?

One to create new entries in OU=NewUsers,dc=company,dc=com

This job is executed for the new employees only.

And another one to update existing entries which are located somewhere in the whole subtree.

This job is executed for all changed employees.

Cheers

Frank

[darren_hague]

The problem is, how to tell if it is a new employee?

The first job finds no existing employees (it is searching only the sub-tree) and would therefore create all the employees as new users, even though they exist elsewhere in the LDAP.

I like the idea of the 2 jobs, I just can't quite see how it would work in practice...

- Darren

[Frank_Buchholz]

The question is: How can we tell the first RPLDAP_EXTRACT job, to select new employees only? (Then, no check against entries in the directory is neccessary.)

Is it possible to use "Action Type=01" and "Employee status=3" somehow?

Maybe using a new starter report which submits RPLDAP_EXTRACT with the list of new employees.

Cherrs

Frank

[darren_hague]

Interesting idea - I like the thinking. Since we are pulling users back from AD into CUA and then linking them to employees, the list of "new employees" is essentially the list of employees that do not have infotype 0105 populated, so we could use that to drive the creation job...

I will try this out next week and let you know how we did - thanks for the inspiration.

Cheers,

Darren

P.S. Could you feed back to the development team that adding a "CREATION_DN" parameter to SPLDAP_RECEIVE_ATTRIBUTES would be a really nice idea? This parameter would specify the DN in which to create new users.