D Defining and Configuring Synchronization User Lists for Identity Synchronization for Windows

This appendix provides supplemental information about Synchronization User List (SUL) definitions and explains how to configure multiple domains. The information is organized as follows:

Understanding Synchronization User List Definitions
Configuring Multiple Windows Domains

D.1 Understanding Synchronization User List Definitions

Every Synchronization User List (SUL) contains two definitions — one to identify which Directory Server users to synchronize and the other to identify which Windows users to synchronize.

Each definition identifies which users in a directory to synchronize, which users to exclude from synchronization, and where to create new users.

Note:

The objectclasses you select using the Identity Synchronization for Windows Console also determine which users will be synchronized. The program synchronizes only those users that have the selected objectclass, which includes any users that have a subclass of the selected objectclass.

For example, if you select the organizationalPerson objectclass, then Identity Synchronization for Windows will synchronize users with the inetorgperson objectclass because it is a subclass of the organizationalPerson objectclass.

Understanding Synchronization User List Definitions describes the components of an SUL definition:

Table D-1 SUL Definition Components

Component	Definition	Applicable
		Sun	AD	NT
Base DN	Defines the parent LDAP node of all users to be synchronized. A Synchronization User List base DN includes all users in that DN — unless the users are excluded by the Synchronization User List's filter or the user's DN is matched in a more specific Synchronization User List. For example, `ou=sales,dc=example,dc=com`.	Yes	Yes	No
Filter	Defines an LDAP-like filter used to include or exclude users from a Synchronization User List. The filter can include the `&`, `\|`, `!`, `=`, and `*` operators. The `\>=` and `<=` operators are not supported. All comparisons are done using case-insensitive string comparisons. For example, `(& (employeeType=manager)(st=CA))` will include managers in California only.	Yes	Yes	Yes
Creation Expression	Defines the parent DN and naming attribute of newly created users (applicable only when you enable creates). The creation expression must include the base DN of the Synchronization User List. For example, `cn=%cn%,ou=sales,dc=example,dc=com`. (Where the `%cn%` token is replaced with a value from the user entry being created.)	Yes	Yes	No

Note:

To synchronize users in a Sun Java System Directory Server with multiple Active Directory domains, you must define at least one SUL for each Active Directory domain.

When Group Synchronization is enabled, the following are important:

The creation expression supported at Active Directory is cn=%cn%.
The creation expression must contain valid attribute names belonging to the group objectclass since the creation expression is common to both user as well as group.

For example:

The attribute sn is not part of the groupofuniquenames objectclass at the Directory Server. Hence the following creation expression would be invalid for a group object. (Though it would work fine for user.)
```
cn=%cn%.%sn%
```
The attribute used in the creation expression must be provided with a value for every user/group entry created. If the value is not provided then the user/group object will not synchronize and an appropriate message will be logged in the central log.

When you define multiple SULs, Identity Synchronization for Windows determines membership in an SUL by iteratively matching each SUL definition. The program examines the SUL definitions with more-specific base DNs first. For example, the program tests a match against ou=sales,dc=example,dc=com before testing dc=example,dc=com.

If two SUL definitions have the same base DN and different filters, then Identity Synchronization for Windows cannot determine automatically which filter should be tested first, so you must use the Resolve Domain Overlap feature to order the two SUL definitions. If a user matches the base DN of an SUL definition but does not match any filters for that base DN, then the program will exclude that user from synchronization — even if that user matches the filter for a less-specific base DN.

D.2 Configuring Multiple Windows Domains

To support synchronizing multiple Windows domains to the same Directory Server container (such as ou=people,dc=example,dc=com), Identity Synchronization for Windows uses "synthetic" Windows attributes that contain domain information.

For Active Directory domains, Identity Synchronization for Windows sets the activedirectorydomainname attribute to the Active Directory domain name (such as east.example.com ) before synchronizing the entry to the Directory Server.
For Windows NT domains, Identity Synchronization for Windows sets the user_nt_domain_name attribute to the Windows NT domain name (such as NTEXAMPLE) before synchronizing the entry to the Directory Server.

While these attributes do not actually appear in the Windows user entries, they are available for synchronization in the Identity Synchronization for Windows Console and can be mapped to a Directory Server user attribute. Once Identity Synchronization for Windows maps the domain attributes, they will be set in the Directory Server entries during synchronization and can be used in Synchronization User List (SUL) filters.

The following example illustrates how Identity Synchronization for Windows uses these attributes. This example assumes that three Windows domains (two Active Directory domains and one Windows NT domain) will be synchronized with a single Directory Server instance.

D.2.1 To Configure Multiple Windows Domains

Users in the Active Directory east.example.com domain will be synchronized to the Directory Server in ou=people,dc=example,dc=com.
Users in the Active Directory west.example.com domain will be synchronized to the Directory Server in ou=people,dc=example,dc=com.
Users in the Windows NT NTEXAMPLE domain will be synchronized to the Directory Server in ou=people,dc=example,dc=com.

When you create or modify a Directory Server user, the program uses the SUL filters to determine in which Windows domain to synchronize the user (because each Directory Server SUL has the same base DN, ou=people,dc=example,dc=com ). The activedirectorydomainname and user_nt_domain_name attributes make constructing these filters easy.

To construct a filter from the Attributes tab on the Console:
Map the Directory Server destinationindicator attribute to the Active Directory activedirectorydomainname attribute and to the Windows NT user_nt_domain_name attribute.

Configure one SUL for each Windows domain as follows:

EAST_SUL

Sun Java System Directory Server definition 
        Base DN:    ou=people,dc=example,dc=com
        Filter:    destinationindicator=east.example.com
        Creation Expression:  cn=%cn%,ou=people,dc=example,dc=com

Active Directory definition (east.example.com)
        Base DN:    cn=users,dc=east,dc=example,dc=com
        Filter:     <none\>
        Creation Expression:  cn=%cn%,cn=users,dc=east,dc=example,dc=com

WEST_SUL

Sun Java System Directory Server definition
        Base DN:ou=people,dc=example,dc=com
        Filter:  destinationindicator=west.example.com
        Creation Expression: cn=%cn%,ou=people,dc=example,dc=com

Active Directory definition (west.example.com)
        Base DN:  cn=users,dc=west,dc=example,dc=com
        Filter:<none\>
        Creation Expression:  cn=%cn%,cn=users,dc=west,dc=example,dc=com

NT_SUL

Sun Java System Directory Server definition
        Base DN:  ou=people,dc=example,dc=com
        Filter:  destinationindicator=NTEXAMPLE
        Creation Expression:  cn=%cn%,
        ou=people,dc=example,dc=com

Windows NT definition (NTEXAMPLE)
        Base DN:  NA
        Filter:  <none\>
        Creation Expression:  NA

Notice that each Directory Server SUL definition has the same base DN and creation expression, but the filters indicate the domain of the corresponding Windows user entry.

To further illustrate how these settings allow Directory Server user entries to synchronize with separate Windows domains, consider this test case:

Create cn=Jane Test,cn=users,dc=east,dc=example,dc=com in the Active Directory east.example.com domain.
Identity Synchronization for Windows creates the user entry cn=Jane Test,ou=people,dc=example,dc=comin the Directory Server with destinationindicator=east.example.com.
Modify thecn=Jane Test,ou=people,dc=example,dc=com entry in the Directory Server.
Because Jane Test's destinationindicator attribute is east.example.com, her entry will match the EAST_SUL Synchronization User List filter, and the modification will be synchronized to the east.example.com Active Directory domain.

This example assumes that Identity Synchronization for Windows is synchronizing user creations from Windows to the Directory Server. If this is not the case, you can run the idsync resync command to set the destinationindicator attribute.

Note:

When you use idsync resync -f in a deployment with multiple SULs, you probably will have to set the allowLinkingOutOfScope option to true in the linking configuration file. See Appendix B, "Identity Synchronization for Windows LinkUsers XML Document Sample"

The example uses an existing attribute in inetorgperson, destinationIndicator, which might be used for other purposes. If this attribute is already in use or a you select a different objectclass, you must map some attribute in the user's Directory Server entry to the user_nt_domain_name and/or the activedirectorydomainname attribute(s). The Directory Server attribute you choose to hold this value must be in the objectclass you are using for the rest of the attribute mapping configuration.

If there are no unused attributes to hold this domain information, you must create a new objectclass to include a new domain attribute and all other attributes you will be using with Identity Synchronization for Windows.