Delta aggregation into IdentityIQ from an Active Directory application has historically been managed using objects' uSNChanged attribute. This attribute is automatically set by AD when the object is modified, so each time a delta aggregation was performed, only objects whose uSNChanged attribute had changed since the last delta aggregation were read into IdentityIQ.
However, when the same data could be aggregated from multiple different domain controllers (e.g. when there is a load balancer involved which can direct the aggregation process to different domain controllers each time or when failover is configured in the IdentityIQ application (6.3+)), problems may arise since the uSNChanged attribute is not replicated between domain controllers. Consequently, IdentityIQ version 6.3 introduced support for managing delta aggregation through the DirSync control.
Using DirSync
The DirSync control lets an external system (like IdentityIQ) search an Active Directory partition for objects which have changed using a cookie that identifies the directory state at the time of the previous DirSync query. This brings in all changes that occurred across the whole domain, so it does not matter which domain controller is queried to retrieve the data.
Note: IdentityIQ stores separate cookies for accounts and groups. When the AD application represents multiple domains (as is supported in version 6.3+), it stores separate sets of cookies for each domain. These cookies are stored in the AD application definition.
To enable IdentityIQ delta aggregation with DirSync, choose DirSync as the Delta Aggregation Mode in the Application Configuration page or add a "DeltaIterationMode" attribute to the AD application definition XML, setting its value to “DirSync”.
<entry key="DeltaIterationMode" value="DirSync"/>
DirSync limitations
The two drawbacks to the DirSync option, vs. the uSNChanged option are the level of permission required to run it and its inability to scope the search to a limited area of AD.
DirSync must be run from a user account that has the Replicating Directory Changes permission on the domain naming context. (By contrast, the uSNChanged option only requires the user to have List and Read permissions for every container and leaf object in the subtree searched.) This permission should be added to the user account used for other IdentityIQ operations in the AD environment (i.e. the account specified in IdentityIQ's application definition for AD).
A DirSync search cannot be limited to a specific area of Active Directory (e.g. a subtree). However, the AD connector in IdentityIQ filters objects based on searchDNs configured for the AD application as it receives the data. Note that it will not apply any search filters specified within each searchDN.
Choosing between uSNChanged and DirSync
DirSync must be used for delta aggregation from a multi-domain AD application configured as a single application in IdentityIQ (6.3+ configuration option). Additionally, when a single-domain AD application has multiple domain controllers which can all respond to IdentityIQ's aggregation requests, the DirSync option should be used. uSNChanged is only appropriate if the IdentityIQ installation is always querying the same AD domain controller for each defined AD application. In practice, binding IdentityIQ to a single domain controller host where multiple domain controllers are available is not a good idea and should not often be done, so most installations will want to use the DirSync option for delta aggregation from Active Directory.
Note: For either mode, the Enable Delta Aggregation option must be selected in the task used to drive the aggregation process in order for delta aggregation to occur. When that option is not selected in the task, IdentityIQ performs a full aggregation from the target resource.
Please ask this project specific question in the IdentityIQ Forums and @mention this document. The comments are meant for feedback on this document, not for specific project help.
