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 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.

Note –

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: