The SUL_AD_WEST settings are identical to the settings in SUL_AD_EAST.
When the configuration is saved, this error message is displayed:
“Synchronization User Lists: SUL_AD_EAST and SUL_AD_WEST contain duplicate directory source, dc=eb,dc=com, location, ou=people,dc=eb,dc=com, and filter, (&(!(uid=c-*)(destinationindicator=eb.com)).”
When there are multiple SULs, Identity Synchronization for Windows requires that the base DN or the filter is unique. When Identity Synchronization for Windows detects a change to a user, it iterates through the list of SULs until it matches a user. The user entry is compared first with SUL_NT. If it fails to match, it is compared with SUL_AD_WEST. If it fails to match again, it is compared with SUL_AD_EAST.
For summary information about the three defined SULs, click Resolve Domain Overlap.
The following table shows examples of user entries and SUL matches.
Table 2–2 Example User Entries-SUL Matches
User Entry |
Matched SUL |
---|---|
dn: uid=someuser,ou=people,dc=eb,dc=com destinationindicator: EXBANK |
SUL_NT |
dn: uid=someuser,ou=people,dc=eb,dc=com destinationindicator: eb.com |
SUL_AD_WEST |
dn: uid=c-somecontractor,ou=people,dc=eb,dc=com destinationindicator: eb.com |
<none\>Because uid=c-* |
dn: uid=someuser,ou=people,dc=eb,dc=com destinationindicator: |
<none\>Because no destinationindicator attribute |
dn: uid=someuser,ou=otherpeople,dc=eb,dc=com |
<none\>Because it does not match any base DNs |
The program will not find a match for the SUL_AD_EAST entry because SULs are evaluated from top to bottom. The program will encounter and evaluate the base DN and filter for the SUL_AD_WEST entry first, which is located immediately before the SUL_AD_EAST entry. Consequently, Console requires SULs to have different base DNs or filters.
A SUL is used primarily when a change to a user is detected. Evaluating the SUL in which the user resides determines the remote Windows domain or Directory Server the user should be synchronized with. When a change is detected to a user, it must be sent to the appropriate place. The information in an SUL is used in two instances at the destination resource where the change is applied:
When the idsync resync -f command is executed to establish links between existing users, by default Identity Synchronization for Windows will only link to a Directory Server user that is in the same SUL as the Active Directory user. This behavior can be overridden as described in Running idsync resync.
Before a new entry can be synchronized to Directory Server or Active Directory, its DN is constructed using the creation expression, which is specific to each SUL.
The default behavior of idsync resync can be overridden if Example Bank wants to synchronize user creations from Directory Server to Active Directory, that is, the SUL_AD_WEST and SUL_AD_EAST can have the same base DN and filter.
Thus, you can ignore the previous warning message and, as a workaround, rearrange the filters. Change the (&(!(uid=c-*))(destinationindicator=eb.com)) filter to be equivalent to(&(destinationindicator=eb.com)(!(uid=c-*))). This rearrangement passes the console’s validations because the console only performs the string comparisons to determine if the two filters are equivalent.
If there is no SUL filter or it has only a single component, an SUL filter (or filter component) is added. This SUL filter component is different for each SUL but always evaluates to true.
For example, the SUL definitions for SUL_AD_WEST and SUL_AD_EAST could also be defined as follows:
(&(!(uid=c-*)(destinationindicator=eb.com) (!(bogusAttr=SUL_AD_WEST)))
(&(!(uid=c-*)(destinationindicator=eb.com) (!(bogusAttr=SUL_AD_EAST)))
The new definition of SUL_AD_EAST passes the Console’s validation.
After the configuration is saved successfully, you install the connectors and the Directory Server plug-ins.