Chapter 2 Case Study: Deploying in a Multimaster Replication Environment

The case study provided in this chapter explains how the company “Example Bank” implemented Identity Synchronization for Windows in a multimaster replication (MMR) environment. This case study includes information about the business imperatives, the technical requirements, and the implementation of Identity Synchronization for Windows.

This chapter covers the following topics:

• Example Bank Deployment Information

• Deploying the Solution

Example Bank Deployment Information

This section describes the architecture and technical requirements of Example Bank, the company in this case study. It also lists the Identity Synchronization for Windows features that are used in this case study.

Example Bank’s Existing Architecture

Example Bank’s infrastructure includes a Windows NT domain (EXBANK), an Active Directory domain (eb.com) with two domain controllers, and a two-way MMR Sun Java System Directory Server (dc=eb,dc=com) deployment. Example Bank has two main sites: one located in New York City and one in Los Angeles.

The following figure describes Example Bank’s deployment of its directory resources.

Figure 2–1 Example Bank Architecture

Directory Server Information

Sun Java System Directory Server is the corporate directory server that is used to control access to all web-based applications. Pluggable Authentication Module (PAM) for LDAP authenticates and manages passwords on the Solaris^TM Operating System (Solaris OS) against Directory Server passwords. The two preferred Directory Servers manage a single root suffix, dc=eb,dc=com, and all users are stored in the ou=people,dc=eb,dc=com container with uid as the naming attribute. The directory servers, installed on Solaris systems, are running on separate machines: master-east.eb.com and master-west.eb.com.

Windows NT Information

The single Windows NT domain is called EXBANK. The Primary Domain Controller (PDC) runs on a pdc-east.eb.com machine in New York City. A backup domain controller (bdc-west.eb.com) runs on a machine located in Los Angles. All Windows NT user accounts have a Directory Server account with the exception of the built-in Windows NT accounts. The Windows NT USER_NAME attribute is the same as the Directory Server uid attribute.

Active Directory Information

The Active Directory deployment has a single domain, eb.com, with two domain controllers:

• ad-east.eb.com (in New York City)

• ad-west.eb.com (in Los Angeles)

In this deployment, ad-west.eb.com is the PDC Flexible Single-Master Operation (FSMO) role owner.

Users are stored in two separate organizations corresponding to the two sites:

• ou=east,dc=example,dc=com

• ou=west,dc=example,dc=com

Example Bank is in the process of migrating users from Windows NT to Active Directory. Each employee has a Windows NT or Active Directory account. The migration of the users is based (in phases) on the employees’ last names. Every week Example Bank moves users whose last name begins with the next letter of the alphabet. Currently, the company has migrated employees whose last names begin with letters A through F.

For users who have Directory Server accounts, the Active Directory samaccountname attribute stores the uid. When a user account is migrated from Windows NT, the user keeps the same login. That is, the Active Directory samaccountname attribute of the new user is the same as the Windows NT USER_NAME attribute.

Example Bank’s Technical Requirements

The following table describes Example Bank’s technical requirements.

Identity Synchronization for Windows Features in This Case Study

The following Identity Synchronization for Windows features are used in this case study:

• Synchronizing with multiple Windows domains

• Synchronizing in a two-way MMR environment

• Synchronizing multiple object classes

• Deploying over a wide area network (WAN)

• Integration with PAM LDAP

• Migrating users between Windows domains, (from Windows NT to Active Directory)

• Excluding users from synchronization using an SUL filter

• Synchronizing a hierarchical directory information tree (DIT) with a flat DIT

• Creating attribute default values

• Failover support across multiple preferred Directory Servers in a replicated environment

• Account lockout synchronization

• Static group synchronization

Deploying the Solution

This section provides instructions for the following tasks:

• Creating a Special Active Directory User for Identity Synchronization for Windows

• Configuring the Identity Synchronization for Windows Core

• Migrating Users From Windows NT to Active Directory

Creating a Special Active Directory User for Identity Synchronization for Windows

Example Bank creates a special user that Identity Synchronization for Windows uses when connecting to Active Directory. This user is created in the cn=Users container in the eb.com domain. After the user is created, a minimum set of administration rights is assigned to this user.

Identity Synchronization for Windows automatically creates a similar user with limited privileges in Directory Server. This user is created as the uid=PSWConnector,<synchronized suffix\> user.

To Assign Administration Rights to the Special User

1. In the Tree pane of the Active Directory Users and Computers window, right-click the eb.com container icon.

2. From the All Tasks menu, choose Delegate Control.

   The Delegation of Control Wizard is displayed.

3. In the Selected User and Groups list, select the special user and click Next.

4. In the Tasks to Delegate window, select Create a Custom Tasks to Delegate, and click Next.

5. In the Only the Following Objects in the Folder section, select User Objects.

   Identity Synchronization for Windows manages only User objects, so it is sufficient to delegate control of these objects.

6. In the Show These Permissions list of the Permissions window, select these options:

   • General

   • Property-Specific

   • Full Control

     Because Example Bank requires the synchronization of users from Directory Server to Active Directory, the special user is given full control of user objects in the eb.com domain.

   ---

   Note –

   If you specify a user with default Active Directory permissions, some operations will succeed, for example, an idsync resync operation from Active Directory to Directory Server. Other operations, such as detecting and applying changes in Active Directory, can fail abruptly.

   If Example Bank is synchronizing the deletions from Active Directory to Directory Server, even Full Control is insufficient. You must use a Domain Administrator account to detect account deletions in Active Directory.

   ---

Configuring the Identity Synchronization for Windows Core

The Identity Synchronization for Windows Core components are installed on master-east.eb.com, the machine on which the preferred Directory Server is running. After the Core components are installed, complete the following configuration procedures:

• Configuring Directory Sources

• Configuring the Synchronization Settings

• SUL_NT

• Installing the Connectors and Directory Server Plug-Ins

• Running idsync resync

• Configuration and Installation Summary

Configuring Directory Sources

This section explains how to configure the following directory sources:

• Configuring the Sun Java System Directory Server Source

• Configuring the Active Directory Source

• Configuring the Windows NT Source

Configuring the Sun Java System Directory Server Source

When configuring the Directory Server source, the preferred Directory Server is set to master-east.eb.com. The Directory Server Connector uses this Directory Server to detect and update changes that require synchronization with Active Directory and Windows NT. Alternatively, the master-west.eb.com domain could have been selected. However, Directory Server Connector performance is better when connecting to a local Directory Server instead of a Directory Server located over a wide area network (WAN).

When the password modification settings are changed, the Console automatically enables the SSL option, which is required while synchronizing from Directory Server to Active Directory.

To Specify the Preferred and Secondary Directory Servers

1. In the Directory Sources window of the Identity Synchronization for Windows Console (Console), click New Sun Directory.

2. In the Define Sun Java System Directory Source dialog box, select Specify a Preferred Server.

   

3. Select Choose a Known Server and then choose a preferred Directory Server from the drop-down menu, in this case, master-east.eb.com.

4. (Optional) Select Specify Secondary Servers to select a secondary Directory Server, in this case, master-west.eb.com.

   If master-east.eb.com is unavailable, the Directory Server Connector synchronizes changes made at Active Directory to master-west.eb.com.

   

Configuring the Active Directory Source

The Active Directory global catalog information enables the Identity Synchronization for Windows Console to learn the Active Directory configuration. In this case study, the global catalog is running on ad-west.eb.com. By default, the Console auto-populates the User DN field with the Administrator DN, cn=Administrator,cn=user,dc=eb,dc=com. However, you need to change this field to the special Identity Synchronization for Windows user that was created earlier, cn=iswUser,cn=Users,dc=eb,dc=com.

To Specify Information in the Global Catalog and for the Active Directory Domain

1. In the Console, in the Directory Sources window, click New Active Directory Source.

   The Windows Global Catalog dialog box is displayed.

2. Type the fully qualified name in the Host field, in this example, ad-west.ed.com.

3. Change the default User DN (cn=Administrator) to the DN cn=iswUser,cn=Users,dc=eb,dc=com.

4. Type the password and click OK.

   

5. Provide credentials for the Active Directory domain, then click Next.

   The Active Directory Connector uses the same Identity Synchronization for Windows special user credentials to connect to Active Directory that you provided when connecting to the global catalog.

   

6. Specify the PDC FSMO role owner domain controller.

   The ad-west.eb.com domain controller is the PDC FSMO role owner. Certain changes (for example, password modifications) made at other domain controllers are replicated immediately to this domain controller. The Active Directory Connector communicates with this domain controller so that changes made at any Active Directory domain controller can be synchronized immediately to Directory Server. This Active Directory replication can take several minutes.

   The Active Directory Connector for this domain is installed on the same machine where Identity Synchronization for Windows Core is installed, on master-east.eb.com. The connector communicates over the WAN with ad-west.eb.com. Active Directory Connector performs better across WAN than the Directory Server Connector because Active Directory Connector performs fewer directory searches to detect changes.

   

7. Specify one or more failover domain controllers for on-demand password synchronization, in this case, ad-east.eb.com.

   If ad-west.eb.com is unavailable, the Directory Server plug-in performs on-demand password synchronization against ad-east.eb.com.

   

Configuring the Windows NT Source

After the Directory Server and the Active Directory sources are configured, configure the Windows NT domain.

To Specify the Windows NT Domain

1. In the Console, in the Directory Sources window, click New Windows NT Directory Source.

   The Define a Windows NT Directory Source dialog box is displayed.

   

2. Select Specify the Windows NT Domain, type the Windows NT domain, in this case, EXBANK, and click Next.

3. Type the Primary Domain Controller of the EXBANK domain.

   The NETBOIS name of the Primary Domain Controller is pdc-east. The fully qualified name of this host is pdc-east.eb.com.

Configuring the Synchronization Settings

After each directory source is configured, the synchronization parameters are configured to match Example Bank’s requirements as explained in these section:

• Configuring the Attributes Settings

• Configuring the Attribute Modification Settings

• Configuring the Object Creation Settings

• Configuring the Group Synchronization Settings

• Configuring the Account Lockout Synchronization Settings

Configuring the Attributes Settings

The Attributes settings reflect Example Bank’s requirement to synchronize changes to a user’s password, full name, and login. The destinationindicator <-\> activedirectorydomainname <-\> user_nt_domain_name mapping displays because it synchronizes multiple Windows domains.

To Configure the Attribute Settings

1. In the Console, click the Configuration tab, then click the Attributes tab.

2. Under Synchronized Attributes, enter the attributes that Example Bank requires to synchronize with Directory Server.

   

   ---

   Note –

   Mapping an attribute to the synthetic activedirectorydomainname or user_nt_domain_name attribute is not unique to deployments that have both Active Directory and Windows NT domains. The same approach is taken in homogeneous Windows environments that have multiple Active Directory or Windows NT domains, where the destinationindicator attribute is mapped to activedirectorydomainname or user_nt_domain_name.

   ---

Configuring the Attribute Modification Settings

The Attribute Modification settings reflect Example Bank’s requirements to synchronize the attribute changes and account deactivations, bidirectionally, between the Active Directory and Directory Server sources.

To Configure the Attribute Modification settings

1. In the Identity Synchronization for Windows Console, click the Configuration tab, then click the Attribute Modification tab.

2. Select Attribute Modifications Flow in Both Directions.

3. Select the Synchronize Object Activation/Inactivation with Active Directory check box and select Interoperate With Directory Server Tools.

   

Configuring the Object Creation Settings

The Object Creation settings reflect Example Bank’s requirement to only synchronize user creations from Active Directory to Directory Server.

The Object Creation settings apply to both Active Directory and Windows NT because Example Bank has an environment with both the systems. New users in Active Directory and Windows NT are synchronized with Directory Server. Example Bank is migrating all Windows NT users to Active Directory; so no new users will be created in Windows NT.

To Configure the Object Creation Settings

1. In the Console, click the Configuration tab, then click the Object Creation tab.

2. Select the Object Creations Flow From Windows to Sun Java System Directory Server check box.

   

   ---

   Note –

   To synchronize object deletions, click the Object Deletion tab and select Object Deletions Flow From Windows to Sun Java System Directory Server check box.

   ---

Configuring the Group Synchronization Settings

You can create or delete a group, and associate or disassociate users with that group in a directory environment. If Group Synchronization is enabled, the changes that you make in one directory environment automatically propagate to the other directory environment. All the users are synchronized across the directory servers with their group membership intact.

When Group Synchronization is enabled, the uniquemember Directory Server attribute and the member attribute Active Directory attribute are internally mapped.

To Configure the Group synchronization Settings

1. In the Console, click the Configuration tab, then click the Groups tab.

2. Select the Enable Group Synchronization check box.

   

3. From the drop-down menu, choose Domain Global Security or Domain Global Distribution to propagate groups from Sun Directory Server to Active Directory.

Configuring the Account Lockout Synchronization Settings

In Identity Synchronization for Windows, account lockout and unlockout are synchronized between the Directory Server and Active Directory sources.

To Configure the Account Lockout Synchronization Settings

1. In the Console, click the Configuration tab, then click the Account Lockout tab.

2. Select the Enable Account Lockout Synchronization check box.

   

Adding the shadowAccount Object Class

When configuring Identity Synchronization for Windows to interoperate with PAM LDAP on Solaris systems, select and then add the shadowAccount object class as an auxiliary object class for synchronization. When a new user is created in Active Directory, and that user is synchronized to Directory Server, the user entry includes the shadowAccount object class, which is required by PAM LDAP.

Figure 2–2 shadowAccount Object Class

Configuring the Creation Attributes

Use the Creation Attribute Mappings and Values dialog box to configure additional attributes to be synchronized when an entry is created.

To Configure the Creation Attributes

1. Click Creation Attributes under the Object Creation tab.

2. Provide a mapping or default value for sn, a mandatory attribute for the inetOrgPerson object class.

   Active Directory has a corresponding attribute sn. However, Windows NT does not have an equivalent attribute, so the special ** NO VALUE ** value is provided. Because Example Bank’s requirements do not include creating users in Windows NT, this value does not appear in any of the user entries. This value is only provided to conform to the Console’s validations.

   Configure the shadowmin, shadowmax, and shadowwarning attributes, which are used for PAM LDAP.

   • A shadowmin value of 7 implies that a user must wait seven days from the time the password has changed before changing it again.

   • A shadowmax value of 30 implies that the user must change the password at least every 30 days.

   • A shadowwarning value of 4 implies that the user is warned that the password must be changed four days before the password expires.

   Directory Server attributes that are grayed-out are mandatory creation attributes. The inetOrgPerson object class has cn and sn as mandatory attributes, and the shadowAccount object class has uid as a mandatory attribute.

   

Configuring the Synchronization User Lists

Example Bank requires at least two Synchronization User Lists (SULs) for each of the Windows domains (Windows NT and Active Directory). However, Example Bank wants to synchronize two disjoint organizational units in Active Directory (ou=east and ou=west), so two SULs are configured for the Active Directory domain.

SUL_NT

This SUL provides details required to synchronize users between Windows NT and Directory Server.

When detecting changes in Windows NT, contractors are excluded from synchronization by the (!(USER_NAME=c-*)) filter because each contractor USER_NAME value starts with c-.

The base DN of all synchronized users is, ou=people,dc=eb,dc=com. The Creation Expression, uid=%uid%,ou=people,dc=eb,dc=com, implies that new users will be created in the same container with uid as the naming attribute.

The filter for this SUL includes two components:

• (!(uid=c-*)) excludes contractors from synchronization.

• (destinationindicator=EXBANK) allows the Directory Server Connector to determine the Windows domain where the user resides. (when it detects a change to the user)

SUL_AD_EAST

This SUL provides details required to synchronize users between the Active Directory ou=east,dc=eb,dc=com container and Directory Server.

The SUL settings imply that all users under ou=east,dc=eb,dc=com will be synchronized from Active Directory to Directory Server except users whose samaccountname starts with c- (contractors).

For the SUL_AD_EAST list, only users under the ou=east,dc=eb,dc=com organizational unit will be synchronized. The filter for this SUL includes two components:

• (!(uid=c-*)) excludes contractors from synchronization

• destinationindicator=eb.comallows the Connector to determine the Windows domain where the user resides.

SUL_AD_WEST

This SUL provides details required to synchronize users between the Active Directory ou=west,dc=eb,dc=com container and Directory Server.

The SUL settings imply that all users under ou=west,dc=eb,dc=com will be synchronized from Active Directory to Directory Server except users whose samaccountname starts with c- (contractors).

Resolving Issues With Multiple SULs

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.

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

The following table shows examples of user entries and SUL matches.

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.

Installing the Connectors and Directory Server Plug-Ins

The Active Directory and Directory Server connectors are installed on master-east.eb.com. The Windows NT Connector is installed on the Primary Domain Controller pdc-east.eb.com. The Directory Server plug-ins are installed on the two preferred Directory Servers, that is, master-east.eb.com and master-west.eb.com.

Perform the idsync resync procedure to link all the existing users as there are no other preferred Directory Servers or read-only replicas in this environment.

Running idsync resync

In Example Bank’s deployment, users already have accounts in Directory Server and in Windows. You must run idsync resync to establish links between equivalent users before starting synchronization. Use the -f <linking-file\> resync option to link the users. For detailed information about the idsync resync command, see “Using idsync resync in Sun Java System Directory Server Enterprise Edition 6.1 Installation Guide,” in Sun Java System Directory Server Enterprise Edition 6.3 Installation Guide.

Running idsync resync initializes the destinationindicator attribute in each Directory Server entry, which ensures that the existing users in Directory Server match their SUL filter. If this attribute is not initialized with each user’s Windows domain, changes to Directory Server users do not propagate back to Windows because the entry does not match the destinationindicator part of the SUL filter. In situations where the destinationindicator attribute is not populated, running the idsync resync command without the -k option establishes links between the users.

All users with Active Directory accounts have a Directory Server password that is synchronized with their Active Directory password, using the -i NEW_LINKED_USERS option.

For example, the process of linking a single user “John Test” is described here. This user has an Active Directory account in the ou=east organizational unit. The user entry is as follows:

bash-2.05# ./ldapsearch -h ad-west.eb.com -b "dc=eb,dc=com" -D 
"cn=Administrator,cn=users,dc=eb,dc=com" -w < password omitted\> 
"samaccountname=jtest" version: 1
dn: CN=John Test,OU=east,DC=eb,DC=com
accountExpires: 9223372036854775807
badPasswordTime: 0
badPwdCount: 0
codePage: 0
cn: John Test
countryCode: 0
displayName: John Test
givenName: John
instanceType: 4
lastLogoff: 0
lastLogon: 0
logonCount: 0
distinguishedName: CN=John Test,OU=east,DC=eb,DC=com
objectCategory: CN=Person,CN=Schema,CN=Configuration,DC=eb,DC=com
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: user
objectGUID:: dYGjjEBYukyXXMJ//08KNw==
objectSid:: AQUAAAAAAAUVAAAAFSWvR+sleSxDFwoyUwQAAA==
primaryGroupID: 513
pwdLastSet: 127426694450768912
name: John Test
sAMAccountName: jtest
sAMAccountType: 805306368
sn: Test
userAccountControl: 512
userPrincipalName: jtest@eb.com
uSNChanged: 7043
uSNCreated: 7039
whenChanged: 20041019142405.0Z
whenCreated: 20041019142404.0Z

The user’s password in Active Directory is abc:

bash-2.05# ./ldapsearch -h ad-west.eb.com 
-b "dc=eb,dc=com" 
-D "cn=John Test,ou=east,dc=eb,dc=com"
 -w abc "samaccountname=jtest" version: 1
dn: CN=John Test,OU=east,DC=eb,DC=com
cn: John Test

The user’s Directory Server account is as follows:

bash-2.05# ./ldapsearch -h master-east.eb.com 
-b "dc=eb,dc=com" -D "cn=Directory Manager" 
-w <password omitted\> "uid=jtest" version: 1
dn: uid=jtest,ou=People, dc=eb,dc=com
uid: jtest
givenName: John
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetorgperson
sn: Test
cn: John Test
userPassword: {SSHA}CwM7vTIJUEN+aahj1kUH/1/CruIKJ1Vw1hN0eA==

The user’s password in Directory Server is 123:

bash-2.05# ./ldapsearch -h master-east.eb.com 
-b "dc=eb,dc=com" -D "uid=jtest,ou=people,dc=eb,dc=com" 
-w 123 "uid=jtest" cn version: 1
dn: uid=jtest,ou=People, dc=eb,dc=com
cn: John Test

The following file is used to link Active Directory users and Windows NT users to the equivalent Directory Server users.

For information on the syntax used in this example, see Sun Java System Directory Server Enterprise Edition6.3 Installation Guide. Samples are available in the samples/ directory where Core is installed.

A separate section is provided for each SUL. Active Directory and Directory Server users are linked if their Active Directory samaccountname attribute matches their Directory Server uid attribute. Windows NT and Directory Server users are linked if their Windows NT USER_NAME attribute matches their Directory Server uid attribute.

<?xml version="1.0" encoding="UTF-8"?\>
<UserLinkingOperationList\>
  <UserLinkingOperation parent.attr="UserLinkingOperation"
                        sulid="SUL_AD_EAST"\>
    <UserMatchingCriteria parent.attr="UserMatchingCriteria"\>
      <AttributeMap parent.attr="AttributeMap"\>
        <AttributeDescription parent.attr="SunAttribute" name="uid"/\>
        <AttributeDescription parent.attr="WindowsAttribute"
                              name="samaccountname"/\>
      </AttributeMap\>
    </UserMatchingCriteria\>
  </UserLinkingOperation\>
  <UserLinkingOperation parent.attr="UserLinkingOperation"
                        sulid="SUL_AD_WEST"\>
    <UserMatchingCriteria parent.attr="UserMatchingCriteria"\>
      <AttributeMap parent.attr="AttributeMap"\>
        <AttributeDescription parent.attr="SunAttribute" name="uid"/\>
        <AttributeDescription parent.attr="WindowsAttribute" name="samaccountname"/\>
      </AttributeMap\>
    </UserMatchingCriteria\>
  </UserLinkingOperation\>
  <UserLinkingOperation parent.attr="UserLinkingOperation" sulid="SUL_NT"\>
    <UserMatchingCriteria parent.attr="UserMatchingCriteria"\>
      <AttributeMap parent.attr="AttributeMap"\>
        <AttributeDescription parent.attr="SunAttribute" name="uid"/\>
        <AttributeDescription parent.attr="WindowsAttribute" name="USER_NAME"/\>
      </AttributeMap\>
    </UserMatchingCriteria\>
  </UserLinkingOperation\>
</UserLinkingOperationList\>

When the idsync resync command with the linkusers.cfg file is executed, a message that the -i option is not supported for Windows NT SULs is displayed:

bash-2.05# ./idsync resync -w <omitted password\> -q 
<omitted password\> -f linkusers.cfg -i NEW_LINKED_USERS
Validating and starting refresh operation ”1098189761942’. 
Hit CTRL+C to cancel.The operation cannot be started because 
passwords cannot be reset from Windows NT Synchronization User 
Lists. The resync operation must not include the ”SUL_NT’ 
Synchronization User List. Please remove this option or 
explicitly specify non-Windows NT Synchronization User Lists
using the -l option.

Split the linkusers.cfg file into a file that has only the Windows NT SUL, and the following file, linkusers-ad-only.cfg, that has both Active Directory SULs:

<?xml version="1.0" encoding="UTF-8"?\>
<UserLinkingOperationList\>
  <UserLinkingOperation parent.attr="UserLinkingOperation"
                        sulid="SUL_AD_EAST"\>
    <UserMatchingCriteria parent.attr="UserMatchingCriteria"\>
      <AttributeMap parent.attr="AttributeMap"\>
        <AttributeDescription parent.attr="SunAttribute" name="uid"/\>
        <AttributeDescription parent.attr="WindowsAttribute" name="samaccountname"/\>
      </AttributeMap\>
    </UserMatchingCriteria\>
  </UserLinkingOperation\>
  <UserLinkingOperation parent.attr="UserLinkingOperation"
                        sulid="SUL_AD_WEST"\>
    <UserMatchingCriteria parent.attr="UserMatchingCriteria"\>
      <AttributeMap parent.attr="AttributeMap"\>
        <AttributeDescription parent.attr="SunAttribute" name="uid"/\>
        <AttributeDescription parent.attr="WindowsAttribute" name="samaccountname"/\>
      </AttributeMap\>
    </UserMatchingCriteria\>
  </UserLinkingOperation\>
</UserLinkingOperationList\>
                  

The idsync resync command is run again by using the new linkusers-ad-only.cfg file and the -a option to run the command for the test user John Test. However, a message is displayed indicating that one entry matched a user in Directory Server, but the Directory Server user was not found in any SUL.

The Directory Server users do not have their destinationindicator attributes populated with the correct Windows domain names. Therefore, the test user did not match any of the SUL filters.

bash-2.05# ./idsync resync -w <omitted password\> 
-q <omitted password\> -f linkusers-ad-only.cfg 
-i NEW_LINKED_USERS -a "(samaccountname=jtest)"
Validating and starting refresh operation ”1098193309618’.
Hit CTRL+C to cancel.
User progress:
# Entries sent: 1
User progress:
# Entries sent: 1
# Entries that matched a user that is in no SUL: 1
SUCCESS

To address this issue, the allowLinkingOutOfScope="true" parameter is added to the linkusers-ad-only.cfg file:

Whenever a configuration has multiple SULs, use the allowLinkingOutOfScope=true parameter.

<?xml version="1.0" encoding="UTF-8"?\>
<UserLinkingOperationList allowLinkingOutOfScope="true"\>
  <UserLinkingOperation parent.attr="UserLinkingOperation"
                        sulid="SUL_AD_EAST"\>
    <UserMatchingCriteria parent.attr="UserMatchingCriteria"\>
      <AttributeMap parent.attr="AttributeMap"\>
        <AttributeDescription parent.attr="SunAttribute" name="uid"/\>
        <AttributeDescription parent.attr="WindowsAttribute"
                              name="samaccountname"/\>
      </AttributeMap\>
    </UserMatchingCriteria\>
  </UserLinkingOperation\>
  <UserLinkingOperation parent.attr="UserLinkingOperation" sulid="SUL_AD_WEST"\>
    <UserMatchingCriteria parent.attr="UserMatchingCriteria"\>
      <AttributeMap parent.attr="AttributeMap"\>
        <AttributeDescription parent.attr="SunAttribute" name="uid"/\>
        <AttributeDescription parent.attr="WindowsAttribute" name="samaccountname"/\>
      </AttributeMap\>
    </UserMatchingCriteria\>
  </UserLinkingOperation\>
</UserLinkingOperationList\>
                        

When the idsync resync command is executed again, the test user is successfully linked and updated with the destinationindicator attribute value.

bash-2.05# ./idsync resync -w <omitted password\> 
-q <omitted password\> -f linkusers-ad-only.cfg 
-i NEW_LINKED_USERS -a "(samaccountname=jtest)"
Validating and starting refresh operation ”1098191329451’. 
Hit CTRL+C to cancel.
User progress:
# Entries sent: 1
User progress:# Entries sent: 1
# Entries successfully linked: 1
# Entries that were modified: 1
SUCCESS

The following changes occur in the Directory Server entry:

• The dspswuserlink attribute is set to match the objectguid attribute in the Active Directory entry.

• The destinationindicator attribute is set to match the Active Directory domain name (eb.com).

• The dspswvalidate operation attribute is set to true, which implies that the Directory Server password is stale and the user requires on-demand password synchronization.

• The value does not change until the user logs in to Directory Server using the Active Directory password, triggering on-demand password synchronization. Although the Directory Server password was reset to the Active Directory value, the userPassword attribute has not changed.

• The user now has the dspswuser auxiliary object class, which allows the use of Identity Synchronization for Windows specific attributes in the user entry (for example, dspswuserlink).

bash-2.05# ./ldapsearch -h master-west.eb.com 
-b "dc=eb,dc=com" -D "cn=Directory Manager" 
-w <omitted password>\> "uid=jtest" "*" 
dspswvalidate version: 1 dn: uid=jtest,ou=People, dc=eb,dc=com
dspswvalidate: true
dspswuserlink:: dYGjjEBYukyXXMJ//08KNw==
destinationindicator: eb.com
cn: John Test
userPassword: {SSHA}sTpxX8RQcz4GjqJOttSauXNjWcnaR/hC1X7gPA==
uid: jtest
givenName: John
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetorgperson
objectClass: dspswuser
sn: Test

Verify that John Test can log in to Directory Server using the Active Directory password (abc):

bash-2.05# ./ldapsearch -h master-east.eb.com 
-b "dc=eb,dc=com" -D "uid=jtest,ou=people,dc=eb,dc=com" 
-w abc "uid=jtest" cn version: 1
dn: uid=jtest,ou=People, dc=eb,dc=com
cn: John Test

After the user has logged into Directory Server and when an ldapsearch is executed, the on-demand password synchronization has removed the dspswvalidate attribute and updated the userPassword attribute:

bash-2.05# ./ldapsearch -h master-west.eb.com 
-b "dc=eb,dc=com" -D "cn=Directory Manager" 
-w <omitted password\> "uid=jtest" "*" 
dspswvalidate version: 1
dn: uid=jtest,ou=People, dc=eb,dc=com
userPassword: {SSHA}8wmyeFe2bLrOkwM/SUStqmx63CeIHCASLFujUQ==
dspswuserlink:: dYGjjEBYukyXXMJ//08KNw==
destinationindicator: eb.com
cn: John Test
uid: jtest
givenName: John
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetorgperson
objectClass: dspswuser
sn: Test

To link all of the Active Directory users, the same idsync resync command is executed without the -a option:

bash-2.05# ./idsync resync -w <omitted password\> 
-q <omitted password\> -f linkusers-ad-only.cfg 
-i NEW_LINKED_USERS

To link all of the Windows NT users, the idsync resync command is run on the linkusers-nt-only.cfg file, which contains information about SUL_NT: (without the -i NEW_LINKED_USERS option)

bash-2.05# ./idsync resync -w <omitted password\> 
-q <omitted password\> -f linkusers-nt-only.cfg

When Example Bank links all of its users by running idsync resync, most of the users are linked successfully, but some users cannot be linked due to data inconsistencies. After these inconsistencies are manually corrected, idsync resync is run again to link the remaining users.

The next section discusses how to resolve an issue when users are migrated from Windows NT to Active Directory.

Running the Resynchronization Procedure When Directory Server Is Authoritative

When idsync resync is run without the -k option, which only links users, all synchronized attributes in the user entry are updated. In the previous examples in this overall section, the destinationindicator attribute is automatically populated with the correct Windows domain name. The cn and uid (Directory Server attributes) are also updated because they are synchronized.

The users are linked based on uid. The uid is already in sync, but the cn in Directory Server might be replaced with a value from Active Directory. This process might not be appropriate when Directory Server has the authority of these attributes.

To Synchronize Attribute Values in Active Directory With the Values in Directory Server After Linking Entries

1. Change the configuration so the only synchronized attributes are userPassword and destinationindicator.

2. Execute the idsync resync -f <linking file\> command to link the entries and populate the destinationindicator attribute.

3. Change the configuration to include all the synchronized attributes. For example, add cn and uid.

4. Execute the idsync resync -o Sun command to synchronize the Active Directory attributes with their Directory Server values.

   ---

   Note –

   If the destinationindicator attribute does not need to be populated, execute the idsync resync -f <linking file\> -k command to only link the entries. Then execute the idsync resync -o Sun command to synchronize the Directory Server attribute values from Directory Server to Active Directory.

   ---

Configuration and Installation Summary

This section summarizes the configuration tasks based on the main requirements of Example Bank.

Multiple Domains

Configuring Identity Synchronization for Windows to support multiple domains involves the following:

• Setting up destinationindicator <-\> activedirectorydomainname <-\> user_nt_domain_name as a synchronized attribute

• Using destinationindicator in the SUL filters so that entries modified in Directory Server can be located in the proper Active Directory domain

• When linking users by using the idsync resync command, specifying allowLinkingOutOfScope="true" in the input file.

  Do not specify the -k option because you want the destinationindicator attribute to be primed.

PAM LDAP

Configuring Identity Synchronization for Windows to support PAM LDAP involves the following:

• Adding shadowAccount as an auxiliary object class for Directory Server

• Adding the creation attribute default values for various shadowAccount attributes

  For information about the prerequisites and how to conform to PAM LDAP on the Solaris OS, see Appendix A, Pluggable Authentication Modules.

WAN Deployment

Identity Synchronization for Windows has limited support for WAN deployments and can be synchronized with the Directory Server or Active Directory domain controllers that are only available over the WAN. However, the Identity Synchronization for Windows Core and all the connectors must be installed on the same LAN.

The setup in this scenario was achieved by installing the following:

• Identity Synchronization for Windows Core.

• Directory Server Connector.

• Active Directory Connector on the same machine where Identity Synchronization for Windows Core and Directory Server Connector are installed.

• Windows NT Connector on a machine in the same LAN.

In this case study, the Active Directory Connector communicates across the WAN with the Active Directory domain controller on the west coast. A domain controller is available on the east coast, but because it is not the PDC FSMO role owner, synchronization would be significantly delayed if it was selected.

When the Directory Server domain controller and Active Directory domain controller are separated by a WAN, you have the option of installing Identity Synchronization for Windows in one of the following:

• On the same LAN as Directory Server

• On the same LAN as Active Directory

• Somewhere in between

  In general, the best performance is achieved when Identity Synchronization for Windows is installed on the same LAN as Directory Server.

  Identity Synchronization for Windows has been tested in a variety of WAN environments, but it requires minimum a link with at least T1 (1.44 Mb/sec) speeds and a round-trip latency of no more than 300 milliseconds.

Migrating Users From Windows NT to Active Directory

This section explains how to migrate users between Windows domains, which involves the following:

• Moving user accounts from Windows NT to Active Directory

• Unlinking migrated Windows NT entries

• Linking migrated Active Directory entries

Example Bank wants to migrate users each week from Windows NT to Active Directory based on each user's last name. Example Bank has already migrated users whose last name starts with A-F.

After the accounts have been migrated to Active Directory, changes made to migrated users in Directory Server or Active Directory will not be synchronized:

• Changes made in Directory Server are detected. However, each entry will still be linked to a Windows NT entry. The entry is processed by the Windows NT Connector, but the user no longer exists in Windows NT.

• Changes made in Active Directory are also detected but the entry does not match a Directory Server entry because it has not been linked.

To establish links between the migrated Active Directory accounts and the Directory Server entries, the links are removed from the migrated Windows NT accounts. Then, the Active Directory accounts are linked to their corresponding Directory Server entries.

To avoid losing too many changes, perform the full migration when the load on Directory Server is light. The idsync resync command can be run to recover any changes except changes to the passwords.

In this scenario, the users are moved from a Windows NT domain to an Active Directory domain, but the same procedure can be followed when moving users are between Windows NT domains or Active Directory domains.

Unlinking Migrated Windows NT Entries

To unlink migrated users, the dspswuserlink attribute is removed from each Directory Server entry that is affected. The following sample script can be used to remove this attribute from a large number of users. The script accepts ldapsearch arguments for the users that should be unlinked.

#! /usr/bin/perl
# This script is used to break the link between Directory Server
# entries and the corresponding Windows entries.  Provide
# complete ldapsearch arguments for the users to unlink.
# If many users are unlinked, use -D "cn=Directory Manager" to
# avoid search results limits imposed by the directory server.
# ldapsearch and ldapmodify must be in the path, and the
# current directory must be writable.
#
# Modify these variables to point to the ldapsearch and
# ldapmodify commands that ship with the Sun Directory Server.
# The versions that ship with Solaris will not work in this script.
die "Edit this script to modify these variables and then remove this
line.\\n";
my $LDAPSEARCH_EXE = "/opt/mps/serverroot/shared/bin/ldapsearch";
my $LDAPMODIFY_EXE = "/opt/mps/serverroot/shared/bin/ldapmodify";
my $USAGE = "Usage: unlink.pl <ldapsearch args for users to unlink\>\\n";
# Valid ldapsearch options that don’t apply to ldapmodify
my %INVALID_LDAPMODIFY_OPTS = ("-b" =\> 1, "-s" =\> 1);
# Valid ldapsearch options that have arguments and don’t apply
# to ldapmodify
my %INVALID_LDAPMODIFY_OPTS_WITH_ARG = ("-b" =\> 1, "-s" =\> 1);
# The file name for the file to hold the unlink ldif
my $UNLINK_LDIF_FILE = "unlink.ldif";
#
# SCRIPT BEGIN
#
scalar(@ARGV) \> 0 or die "$USAGE";
# Run ldapsearch to find the users to unlink.
my $ldapsearchArgs = getLdapsearchArgs(@ARGV);
my $ldapsearchCmd = "$LDAPSEARCH_EXE $ldapsearchArgs";
my $matchedUsersLdif = ”$ldapsearchCmd”;
lastCommandSucceeded() or die "Failed when running “. “$ldapsearchCmd.\\n$USAGE";
# Construct ldif to unlink each matched user.
my @userDns = parseDnsFromLdif($matchedUsersLdif);
print "Matched ".scalar(@userDns)." linked entries.\\n";
my $unlinkLdif = constructUnlinkLdif(@userDns); my $fileName =
writeLdifToFile($unlinkLdif);
# Run ldapmodify to unlink the users.
my $ldapmodifyArgs = getLdapmodifyArgs($fileName, @ARGV);
my $ldapmodifyCmd = "$LDAPMODIFY_EXE $ldapmodifyArgs";
”$ldapmodifyCmd”;
print "Unlinked ".scalar(@userDns)." entries.\\n";
lastCommandSucceeded() or die "Failed when running “.  “$ldapmodifyCmd.\\n$USAGE";
exit 0;
#
# SCRIPT END
# Return true iff the last command succeeded.
#
sub lastCommandSucceeded {
    return ($? \>\> 8) == 0;
}
#
# Return the dns in the ldif.
#
sub parseDnsFromLdif { my $ldif = shift @_; my @dns = ();
# Note that DNs can span multiple lines.
while ($ldif =~ /(^dn:.*(\\n^[ ]+\\S+.*)*)/gmi) {
push @dns, $1;
}
return @dns;
}
#
# Return ldif for all users to unlink
#
sub constructUnlinkLdif {
    my $ldif = "";
    for my $dn (@_) {
        $ldif .=
            "$dn\\n" .
            "changetype: modify\\n" .
            "replace: dspswuserlink\\n" .
            "-\\n" .
            "\\n";
    }
    return $ldif;
}
#
# Writes ldif to a file and returns the name of the file.
#
sub writeLdifToFile {
    my $ldif = shift @_;
    open(LDIF, "\>$UNLINK_LDIF_FILE") or
         die "Could not open $UNLINK_LDIF_FILE for writing.\\n";
    print LDIF $ldif;
    close(LDIF);
    return $UNLINK_LDIF_FILE;
}
#
# Return the arguments to use for ldapsearch as a single string
#
sub getLdapsearchArgs {
# Always use -L because Solaris’s ldapsearch doesn’t
# return ldif by default.
my $ldapsearchArgs = "";
# Modify the last argument to include the search filter
    my $lastIndex = $#_;
    $_[$lastIndex] = getLinkedSearchFilter($_[$lastIndex]);
    for my $arg (@_) {
        $ldapsearchArgs .= " '$arg'";
    }
    return $ldapsearchArgs;
}
#
# Construct an ldapfilter that only matches linked users.
#
sub getLinkedSearchFilter {
    my $filter = shift @_;
    if (!($filter =~ /^</)) {
        $filter = "($filter)";
    }
    return "(&(dspswuserlink=*)$filter)";
}
#
# Return the arguments to use for ldapmodify as a single string.
#
sub getLdapmodifyArgs {
    my $ldifFile = shift @_;
    my $ldapmodifyArgs = "-f '$ldifFile'";
    my $prevArg = "";
    # Iterate through all args, skipping ones that don’t
    # apply and the last one.
    for my $i (0..($#_ - 1)) {
        my $arg = $_[$i];
        if (!$INVALID_LDAPMODIFY_OPTS{$arg} &&
            !$INVALID_LDAPMODIFY_OPTS_WITH_ARG{$prevArg}) {
            $ldapmodifyArgs .= " '$arg'";
        }
        $prevArg = $arg;
    }
    return $ldapmodifyArgs;
}
            

The next batch of Example Bank users to be migrated from Windows NT to Active Directory have a last name that starts with the letter G. After these users have been migrated, the following unlink.pl script is executed to unlink these entries in Directory Server.

bash-2.05# ./unlink.pl -h master-east.eb.com 
-b "dc=eb,dc=com" -D "cn=Directory Manager" 
-w <omitted password\> "(sn=G*)"
Matched 1346 linked entries.
Unlinked 1346 entries.

In this example, 1346 entries were migrated and thus unlinked. The Directory Manager dn is provided to avoid search results limits in the Directory Server. If other accounts are used, make sure that their search capabilities are not limited, to avoid unlinking only subsets of users.

Linking Migrated Active Directory Entries

After the links in the Directory Server entries are removed, new links are established with the Active Directory entries by using the idsync resync command. Use the -a option with the (sn=G*) filter to link only the users that have been migrated.

According to Microsoft’s documentation, user passwords will be migrated when users are moved from Windows NT to Active Directory. However, if users change their passwords in Active Directory before they are relinked to the Directory Server entries, these password changes will not be synchronized to the Directory Server.

You can use the -i NEW_LINKED_USERS option with the idsync resync command to synchronize Directory Server passwords with their Active Directory values.

If any of the users’ passwords are modified in Directory Server during the migration process, these password changes will be lost.

bash-2.05# ./idsync resync -w <omitted password\> 
-q <omitted password\> -f linkusers-ad-only.cfg 
-i NEW_LINKED_USERS -a "(sn=G*)"
Validating and starting refresh operation ’1098238348483’.
Hit CTRL+C to cancel.
User progress:
# Entries sent: 1346
# Entries successfully linked: 1346
# Entries that were modified: 1346
SUCCESS

Moving Users Between Active Directory Organizational Units

When a user is moved from one Active Directory container to another (for example, from ou=west to ou=east), no action needs to be taken for this user to continue to be synchronized by Identity Synchronization for Windows.

When Contractors Become Full-Time Employees

When a contractor becomes a full-time employee, the special c- prefix is removed from the person's login name. The new full-time employee is now in SUL for the first time, and the entry will be interpreted as being new even though it was not recently created. If the contractor has an Active Directory entry that is modified, Identity Synchronization for Windows will attempt to create the entry in Directory Server.

The following table provides the guidelines for handling contractor accounts when they become full-time employees.