When you configure an ADMA in your environment, you need to provide an account that is used by your management agent to connect to your Active Directory. The following picture shows an example for the related configuration page in the Management Agent Designer:
In FIM, there is no need to use an Active Directory user account that is a member of any of the administrative security groups such as “Domain Admins”. As a best practice, you should use a regular user account. However, the account must have sufficient rights for the identity data exchange between FIM and Active Directory.
There are two separate data exchange directions between FIM and Active Directory
In your management agent configuration, you can limit the scope of containers that are part of this data exchange by configuring a partition and container filter.
During an import from Active Directory, the ADMA does not get the related information by querying the containers that are configured to be included directly. Instead, the ADMA requests the related information from the Active Directory directory synchronization (DirSync) control. The DirSync control is a Lightweight Directory Access Protocol (LDAP) server extension that enables a program to search an Active Directory partition for objects that have changed. This is especially useful in case of a delta import, when the ADMA only requests the changes that were applied since the last import. In simple terms, the ADMA keeps track of a watermark that indicates the value of the most recent change value the ADMA is aware of. In case of a full import, this value is reset. In case of a delta import, this value is used to indicate the last known state of changes.
To enable your ADMA account to query data from the DirSync control, the account must have “Replicating Directory Changes permission” permission on the domain object (e.g.: "Fabrikam.com"):
If your account doesn’t have this right, you get a “Replication access was denied” error during an import from Active Directory:
Granting “Replicating Directory Changes permission” is sufficient as long as you only import identity data from Active Directory. If your ADMA exports identity data to Active Directory, you must grant full control to your ADMA account on all organizational units the account needs to manage. If the account doesn’t have sufficient rights, you will get “permission-issue” errors during an export operation:
If you look at the error details of one of the affected objects, you will see that “Access is denied”:
When configuring permissions for your organizational unit, please make sure that you apply them to "this object and all descendant objects":
When you configure an ADMA, you need an account that is used by the ADMA to exchange identity data with Active Directory.
You should use the following guidelines for the configuration of this account:
Maheshkumar S Tiwari edited Revision 6. Comment: Added Tag
Maheshkumar S Tiwari edited Revision 5. Comment: Added tags
Ed Price MSFT edited Revision 2. Comment: Updated title to standards.
No. You don't need "Full Control" on containers that you export to.
Is it really true that you need to grant "full control" to containers you may export to? I dont think this is a good practice and since FIM is a security product the article should be updated accordingly.