AD provisioning in a specific OU

[Former Member]

Hi Experts,

Is it possible to change the provisioning for the Plugin "Create AD User" so that I can provision 'in a specific OU?

For example:

User X should I be added in the AD domain under "OU = Internal". Is it possible to target the user-provisioning to the OU structures of the AD?

By dedault the defined "starting point" and the MSKEYVALUE is used for the "dn".

What are your experiences?

Thank You!

Gerhard

[Former Member · Accepted solution]

I found it useful to load the OU's from AD into a separate entry type, alongside other AD thingys. During provisioning, using own plugin tasks, the DN is generated from firstname, lastname (or sometimes even the mskeyvalue) and the selected OU.

The OU of a user can be selected / calculated in several ways though. According to a department/company or selected in the approvals of requests by the AD administration are only two of the possibilites I have implemented so far.

[Former Member · Accepted solution]

Hi Domink

Thanks for your earlier reply to me.

Could you please guide me the steps so that users can be provisioned to specif OU's in Active Directory.

We have a specific attribute in HR system for each employee which is Branch for Employee.

I am planning to bring this attribute in IDM  so that mapping can be done in IDM like

EMPLOYEE- BRANCH.

There are multiple OU's based on that branches in Organisation and Employee needs to be provisioned in specific OU where he belongs to.

Regards

Deepak

[Former Member · Accepted solution]

Hi Deepak,

I would suggest you to do the following way.

1. Create a table in IDM and maintain the Bracnh to OU mapping, say in the table tblBranchtoOU.   Ex:

Branch     OU

------           --

Branch-A   OU1

Branch-B   OU2

Branch-C   OU3

2. Create an attribute  MX_Branch which lists the available branches. to list the available branches from this table. configure the MX_Branch attribute as below.

3. Configure your UI task for user creation such that, it lists the Branch values to select the branch during the user creation.

4. Write a script that accepts the Branch as input and do a look up on the table that is created in step 1 and return the corresponding OU.

5. Add this script to the plugin task for AD, "SAP Create ADS User"

6. In the destination tab of this pass, for the AD attribute dn, change the value based on your requirement according to the script. something like in   

   below    screenshot.

In IDM, you can achieve a solution in multiple  ways it depends on you, which logic you want to use.

Thanks,

Krishna.

[Former Member]

Hi guys!

I've got a quite similar question.

When a user is disabled in the active directory, my Customer wants to move this user from the OU where it has been created to another OU (ex : OU=disableUser,...).

Is it possible to do it directly into disableADSUser pass?

The unique identifiant is the DN, can I put a new DN Under it such as a classic attribute to update?

[former_member2987]

Guillaume.

Yes, this is possible, it's done via a ModRDN operation.  Take a look at this blog entry:

http://scn.sap.com/community/netweaver-idm/blog/2012/09/11/using-modrdn-with-sap-nw-idm

Matt

[Former Member]

Hi Gerhard

Hundreds of ways of doing it.  As long as you end up with a valid DN going out you're fine.

How you generate it depends on the business.  Some businesses change AD structure on a weekly basis (and deserve to be beaten for it), others once in a blue moon.

It also depends on whether the data you're using can be consistently mapped to the AD structure.

For a simple option (Contractors in OU=Contractors, Employees in OU=Employees) you can just use global constants and match the incoming data to the constant (eg: ZCONTRACTOR_OU).  I cannot stress enough how much you need a default in this scenario. If the user doesn't have the right data, you may end up with errors or it could go somewhere unexpected.  Always make sure that you have a default OU where the errors go.

If you have an 'organisational' structure in AD, you might want to look at something more dynamic. EG: CN=User,OU=Branch,OU=Department.

This will require a bit of error checking - if the HR department changes the structure but the AD team doesn't, users will fail to be provisioned.  You can, of course, set things up so that it creates the OU if it doesn't exist, taking complete ownership of the creation of AD users.

You also need to be careful in this scenario of users who move.  Being moved from one location to another can cause all sorts of issues - do you move them in AD? If they are moved in AD, how do you resolve the user to IDM?

The short answer is yes.  The long answer is 'Really?  OK but have you thought about...'

Peter

[former_member190695]

Hi Gerhard,

My best practice is to create a custom table and maintain all locations, not just countries with their corresponding OU's and SAP Personnel Area Text or ID (TEXT_P0001_WERKS or P0001-WERKS), etc.. The location name or ID should match the value in SAP HR or any other HR system.

Create a custom attribute that can accommodate Employees and Non-Employees and look up the OU while creating the user in IdM, so before provisioning. In my case I am not saving just the OU in the custom attribute but the user full DN. So in ADS provisioning tasks I just have to refer to this attribute without putting e.g. CN=%MSKEYVALUE%,%CUSTOM_AD_USER_DN%

When you create a Non-Employee the same locations should be available, this depends on how and where you create Non-Employees.

Regards,

Ridouan

[Former Member]

This message was moderated.

[former_member2987]

Hello, Aishwarya,

Sorry, this forum is for using IDM only.  You will need to check with your AD Admin team for best practices for your organization.

Regards,

Matt

[Former Member]

Hi Gerhard,

Yes, it's absolutely possible. I have implemented this at my site.

The requirement at our site was IDM to provision AD users into different OUs(named by country) based on which country the user is from. The country is determined by the MX_FS_COMPANY_CODE_ID attribute.

I just wrote a function which determines the OU path based MX_FS_COMPANY_CODE_ID.

Once the function is written, call the function as shown in the following in CreateADSUser pass:

Also note that you have to update the Update user ACCOUNT attribute pass as well so the Account attribute is updated.

Let me know how you go. Thank you,

KV

[bxiv]

I would imagine you would add the OU path, using proper LDAP syntax, and the system would place the DN object there.