Best Practices for AD Import into FIM MV

 I'm working on a project which will require AD users to be imported into FIM and then be shown in the FIM portal. I know I could import users from a specific OU, but what I'm not sure about is how FIM and the MV keeps track of users.

For example:

I configure "john.doe" in OU "London" and then import the account into the MV.
john.doe is moved into the Hong Kong OU and I run a delta sync - can FIM track this change?

Would I be better off using an anchor on objectsid to deal with user account moves and users changing names\logons?

Thanks

January 13th, 2014 1:07pm

When you are configuring AD MA you are selecting OUs in which you are managing object through MA. As long as you will keep user in selected OUs FIM will "see" this user and will import changes on object.

FIM is using objectGUID as anchor internally (I assume this - never looked into agent code :) ) but presents DN as an anchor for you. You can't change this. When user will be moved between OUs you will see it as rename operation and you will see it as DN change.

Free Windows Admin Tool Kit Click here and download it now
January 13th, 2014 4:12pm

I'd also add that in your example, if the London OU has been selected and the Hong Kong OU has not been selected in FIM, the import would register as a delete operation because all FIM can see is that the account is no longer there.
January 16th, 2014 1:48am

Thanks, that's good to know - saves a lot of effort having to account for user moves\name changes.

Given that you don't necessarily know which OU within AD an account will move to (even if pre-agreed with the customer), do you normally allow FIM to see the "entire" AD to account for moves?

Free Windows Admin Tool Kit Click here and download it now
January 16th, 2014 10:53am

It highly depends on your AD configuration, regulations and business needs.

In most situations it never hurts to have a full overview of AD forest, to be aware of extra objects, though not necessary to manage all of them.

For example, you could have a user which causes uniqueness conflict, but if it is beyond the scope of discovery, that can cause frustration.

January 17th, 2014 2:35am

Normally there are requirements that mean you shouldn't import the whole directory. There's sometimes privileged accounts that you don't want to be managed by FIM or there can be internal on boarding and off boarding processes that the business doesn't want FIM interfering with. Ideally you do want to import the whole directory because it can make provisioning simpler.
Free Windows Admin Tool Kit Click here and download it now
January 17th, 2014 4:38am

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics