Connecting multiple AD domains with IDM

[anujkhator]

Hello,

I am working with a customer which has multiple AD domains (One Parent,mutliple child domains). Each domain has a different domain controller.Before proceeding with the configuration, I need your suggestion on the below queries:

1. Can multiple AD domains be connected to IDM using a single Repository or One repository per domain?
2. Microsoft provides ADMT (Active Directory Migration Tool) to migrate users between domain. Can SAP IDM has a pass/task to perform similar action? Can modRDN be used to move users across domains?   

Thanks,

Anuj Khator

[bxiv · Accepted solution]

I would think you would want a 1 to 1 setup for the multiple domains, as the domains may have similar values for certain things and may cause some heart ache with random changes on IdM if you were to setup just 1 repository.

As for question 2, I don't think IdM would migrate the account it would be more of a copy and disable the old one...interested in seeing what others might have to say about this one!

[Former Member · Accepted solution]

1.

One repository per domain plus a separate entry type for the OU's. Best thing I can imagine. Using only one repository will mess everything up at some point.

2.

At a customer we used to migrate the users using an IdM job in which the original samaccountname's and UPN's were renamed to "_old" and the creation of new users was triggered, also some mails were sent to the users or local admins. The groups were "copied" aka reprovisioned (in the same job) to the new user afterwards. It worked, somehow, but it was very risky and resulted in many problems.

Now we are switching the migration process back to ADMT and the nigthly scheduled (or manually started if wanted) jobs sets/deletes the (TEMP)ACCOUNT, (TEMP)DN and the customer AD OU attributes; good old 7.1 though. In 7.2 you have to set the two privileges, too.

Triggering the ADMT from the command line started from the IdM would be possible though (googled it ).

My thoughts on ModRDN:

Actually, I never tried that out between parent and child domains, so there is still hope for you. You could use a testuser and try it out in some minutes using a job (no system/only privs, no IdM identity, just a user created in a domain and plain hard coded values in the IdM pass). The connection user for such actions has to be on the level of an enterprise admin, a domain admin simply shouldn't be able to do this.

[Former Member]

I know this thread is kind of old, but attempting to do something similar.

I have a situation where the client has a forest with 6 different domains. There is a main domain and some 5 other domains that are separate companies but still apart of the same forest.  A user is created in AD based upon the company they will be in, but their AD ID needs to be added to groups in another domain.  So they are created in their primary domain, and are added groups in the secondary domain.  So I had all the groups in the AD forest switched to universal instead of Global so this can happen and I created some jobs and scripts to provision the user in their own primary domain and assign some local groups as well as be placed in distribution groups in the secondary domain; the secondary domain is always the the same for all users. I did this by first DIRECT assigning the ONLY priv of the secondary domain then assigning the value in their primary ACCOUNTAD1 attribute to the ACCOUNTAD2 attribute, then provisioning the groups (priv:groups in a role), then doing everything in reverse (unassigning the ACCOUNTAD1 attribute from ACCOUNTAD2 attribute), then DIRECT unassigning the ONLY priv of the secondary domain.  Works great.

Now here is my issue.  I get a request to automate the transfer of a user from one domain to another based upon a trigger from HR.  Because I DIRECTLY added then DIRECTLY removed the secondary domains ONLY priv.  I redid that process to remove the distribution groups from the secondary domain, but before I can DIRECTLY reassign the secondary domains ONLY priv, the modify AD User plug in kicks off and fails.  This is baffling me.  Why is the secondary domain triggering anything when the ONLY Priv is not even assigned? I know I am missing something small?  Would the fact that the secondary AD's groups are still assigned cause the trigger?

[Former Member]

Got it working.

In my Direct Assignment and Direct Unassignment of ONLY Priv, I have to also Direct Assign and Direct Unassign the SYSTEM priv. (and ensure I give the passes time to complete their tasks via uSleep)

Thanks to Anu Biju (a True IdM Guru) for the tip.

[former_member2987]

Anuj ,

Yes, you can do modRDN via IDM.  Take a look here.

As others had mentioned, you'll want to set up one repository per domain. 

You could move users from one domain to another, but I think you would need to design a workflow for that.

Matt

[anujkhator]

Thanks Matt for the blog

If I set up one repository per domain, then I will not be able to use modRDN operation for moving the users from one domain to another.Since, modRDN change works only movement within a domain.Will the user's password remain same after modRDN operation?

The customer wants the user's password to remain same after the movement from one domain to the other, so I believe the workflows will not be of help. Using workflows I can only delete and recreate user in another domain. I will recommend manual operation for cross-domain movement.

[former_member2987]

Anuj,

I don't even know if you can modRDN between different domains.

The password should not be changed unless you specify it in the workflow as they are stored in IDM as attributes.  So you could do something like the following assuming that you are using a user and referencing the same MSKEYVALUE.

1. Remove / disable / Move old Account connected to Repository A

2, Create new account using Repository B.

You'd need to do some relatively fancy footwork, but it could be done.

Any interest in seeing something like this as a Blog / Document?

Matt

[anujkhator]

Matt,

Using modRDN the password for the user will not remain the same because of the below reason:

1. User's current password is stored in Active Directory not in IDM
2. modRDN task copies a AD account to new RDN and deletes it. I believe it doesn't copy the password attribute from one AD accoun to another

Please correct me if I am wrong .

Yes, a blog or document on this would be definitely helpful.  I ncase the password changes after modRDN operation,  you may add a statement in the blog 'that after modRDN the password for the user account doesn't remain same'.

Thanks,

Anuj

[former_member2987]

Anuj,

I've never known modRDN to change the password.  You're modifying the DN only not recreating the whole entry.

Take a look at my existing modRDN blog.  I'll look into moving a user from one domain to another.

Matt

[former_member2987]

I did some thinking about this and it should be relatively easy.

To do this, you'll need to set up two repositories, one for the first domain, another for the second.

Next, create initial load jobs and run for both repositories

Then your workflow is simple, you can drop Domain A repository and then add Domain B Repository.

If you have people editing the user directly in AD, then you might need to do a quick reconciliation to update that user.

Does this help? If you need help with the user Recon, I will focus on that next.

Matt

[anujkhator]

Thanks Matt

The comments were helpful. I believe I will need some manual tasks to retaing the passwords while changing the user's domain.

Regards,

Anuj

[former_member2987]

Anuj,

You can use MX_ENCRYPTED_PASSWORD (you'll need to decrypt it first, there's a script already created for that) and then pass it to the new domain.  Note that you'll need SSL configured to set the password using a ToLDAP pass.

Matt