Sun Java System Identity Synchronization for Windows 6.0 Deployment Planning Guide

Resolving Issues With Multiple SULs

The SUL_AD_WEST settings are identical to the settings in SUL_AD_EAST.

Directory Server Criteria Options for Synchronization
User List

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.

Figure 2–3 A List of SUL Parameters for Directory Server

A List of SUL Parameters for Directory Server

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:


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:


The new definition of SUL_AD_EAST passes the Console’s validation.

Validating SUL_AD_EAST

After the configuration is saved successfully, you install the connectors and the Directory Server plug-ins.

To Do List Dialog