Sun Java System Identity Synchronization for Windows 6.0 Deployment Planning Guide

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

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

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 SolarisTM 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:

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:

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.

Table 2–1 Technical Requirements for Example Bank

Requirement 

Comments 

Users’ Windows passwords should be synchronized with their Directory Server passwords.

Identity Synchronization for Windows can synchronize a user’s existing Directory Server password with the user's Active Directory password.

Users must be able to continue to change passwords using native mechanisms in Windows NT or Active Directory. 

That is, use the CTRL+ALT+DEL key sequence on Windows systems and the passwd command on Solaris systems.

Identity Synchronization for Windows supports capturing native password changes in Directory Server, Active Directory, and Windows NT. Users can continue to change their passwords. They are not required to change passwords at a central location (for example, a web form). 

For native Solaris OS password changes to be propagated to Active Directory, Solaris must be configured to use PAM for LDAP. This feature is discussed in detail in Appendix A, Pluggable Authentication Modules.

Note: You can set passwords in Directory Server by passing in a pre-hashed password value. However, Identity Synchronization for Windows cannot synchronize passwords from Directory Server to Windows if the password is pre-hashed. Thus, do not use a pre-hashed password value because it circumvents password policy and password history.

Contractors might have accounts on Active Directory, Windows NT, or Directory Server but their accounts should not be synchronized.

Contractors can be identified using their login name, which starts with c-. The uid, samaccountname, and USER_NAME attributes start with c- for contractors only.

The Synchronization User List (SUL) feature of Identity Synchronization for Windows can be used to eliminate user accounts that must not be synchronized. Part of an SUL’s configuration includes an LDAP-like filter.

A contractor’s login name begins with a c-.

To exclude contractors use filters: 

  • Active Directory SUL filter is (!(samaccountname=c-*))

  • Windows NT SUL filter is (!(USER_NAME=c-*))

  • Directory Server SULs include (!(uid=c-*)) as a part of their filters. Directory Server SUL filters specify whether the user is using Windows NT or Active Directory.

Changes to login IDs (USER_NAME, samaccountname, and uid) and full names (USER_FULL_NAME, cn, and cn) should be synchronized when they change.

Identity Synchronization for Windows synchronizes other attributes between Windows and Directory Server. It uses a unique Globally Unique Identifier (GUID) stored in the Directory Server entry to correlate users. It can synchronize attributes, such as uid and cn, that are otherwise used as keys.

Note: The SUL filter applies to all operations, and no other changes for contractors are synchronized.

When a new user is created in Active Directory (except for contractors), a corresponding user should be created in Directory Server.

Using Identity Synchronization for Windows, you can choose how creations of new users will be synchronized. Identity Synchronization for Windows can synchronize new user entries from Windows to Directory Server, from Directory Server to Windows, both ways, or not at all. The same SUL filter also excludes contractors from being created in Directory Server.

New users created in Directory Server must not have an Active Directory account created automatically.

Identity Synchronization for Windows can synchronize new user accounts from Windows to Directory Server, Directory Server to Windows, or not at all. 

Entries deleted in Directory Server or Active Directory must not be deleted in the corresponding data source.

Identity Synchronization for Windows can synchronize account deletions from Active Directory to Directory Server, Directory Server to Active Directory, both ways, or not at all. Identity Synchronization for Windows does not synchronize bidirectional account deletions, that is, from Active Directory to Directory Server and from Directory Server to Active Directory.

Note: Identity Synchronization for Windows does not synchronize account deletions with Windows NT.

Accounts that are made inactive (disabled) in Directory Server or Active Directory should be deactivated in the corresponding data source.

Identity Synchronization for Windows can synchronize deactivated accounts from Active Directory to Directory Server, Directory Server to Active Directory, both ways, or not at all.

You can configure how Identity Synchronization for Windows detects account inactivations in Directory Server. Example Bank is not using a third-party application such as Sun Java System Access Manager to control access to its directory server, so the default account deactivation setting for interoperating with the Directory Server tools suffices. 

Note: Identity Synchronization for Windows does not synchronize account inactivations with Windows NT.

After a user has been migrated from Windows NT to Active Directory, changes should be synchronized with the Active Directory account but not the Windows NT account. 

Identity Synchronization for Windows stores a GUID in each Directory Server entry that it synchronizes (in the dspswuserlink attribute), to synchronize changes made in Directory Server to Active Directory and Windows NT. If an account is moved from Windows NT to Active Directory, the dspswuserlink attribute in the corresponding Directory Server entry should be updated. To update the entry in Directory Server, remove the attribute and then run the idsync resync -f <linking-file\> command again.

Users should continue to synchronize even when one preferred Directory Server fails. 

The failover feature in Identity Synchronization for Windows happens seamlessly when the preferred Directory Server fails during synchronization between Active Directory and Directory Server.  

Account lockout synchronization must happen between Directory Server and Active Directory sources.  

In Identity Synchronization for Windows, the accounts locked in Directory Server are also locked automatically in Active Directory. The reverse is also true. 

The users under various groups, such as employee, supervisor, manager, and contractor, should be synchronized across Directory Server and Active Directory with their group memberships intact. 

The static group synchronization in Identity Synchronization for Windows synchronizes the users across the directory servers with their group memberships intact. 

Identity Synchronization for Windows Features in This Case Study

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

Deploying the Solution

This section provides instructions for the following tasks:

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.


Note –

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.


ProcedureTo 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

This section explains how to configure the following directory sources:

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


Note –

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.


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

    Preferred Directory Server Instance Dialog
  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.

    Specifying the Secondary Master Directory Server

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.

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

    Windows Global Catalog Dialog Options
  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.

    Credentials for the Active Directory Domain
  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.

    PDC FSMO Role Owner Domain Controller Dialog
  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.

    Failover Domain Controller Dialog Options

Configuring the Windows NT Source

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

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

    Windows NT Directory Source Selection Dialog Options
  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

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.

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

    Attribute Settings Window Options
    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.

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

    Attribute Mappings Window Options

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.

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

    Object Creation Settings Window Options
    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.


Note –

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


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

    Enabling Group Synchronization
  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.

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

    Enabling Account Lockout Synchronization

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

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.

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

    Creation Attributes Dialog Options

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

Synchronization User List Dialog Options

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:

Directory Server Criteria Options for Synchronization
User List

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

Synchronization User List Dialog Box Options

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:

Directory Server Criteria Options for Synchronization
User List

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

Synchronization User List Dialog Options

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

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.

Installation Steps Pending

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:


Note –

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:

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.

ProcedureTo 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:

PAM LDAP

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

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:

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.


Note –

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:


Migrating Users From Windows NT to Active Directory

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

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:

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.


Note –

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.


Note –

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.

Table 2–3 Guidelines for Transitioning Contractor to Employee Accounts

Active Directory Account 

Directory Server Account 

Creating Linked Entries in Active Directory and Directory Server 

No account 

No account 

This kind of situation should not occur because contractors have either an Active Directory or Directory Server account. If it does occur, create a new entry in Active Directory, and Identity Synchronization for Windows automatically creates a new user in Directory Server. 

No account 

Account 

  1. Remove the c- prefix from the Directory Server entry’s uid.

  2. Create a new entry in Active Directory for the new full-time employee.

  3. Run idsync resync to establish a link for the new full-time employee. Use the -a option to limit the scope of the resync command to a single user.

If a contractor's Directory Server entry is not important, do the following: 

  1. Delete the Directory Server entry for the contractor, if there is one.

  2. Create a new entry in Active Directory.

  3. Identity Synchronization for Windows will create the corresponding new user in Directory Server.

Account 

No account 

Remove the c- prefix from the Active Directory entry’s samaccountname.

Identity Synchronization for Windows will interpret the change as a new user and create the corresponding new user in Directory Server. 

Account 

Account 

  1. Remove the c- prefix from the Directory Server entry’s uid.

  2. Remove the c- prefix from the Active Directory entry’s uid.


    Note –

    If this entry is modified before the Directory Server entry, the contractor will have two Directory Server accounts (the original one and a new one with a uid without the c- prefix)


  3. Run idsync resync to establish a link for the new full-time employee. Use the -a option to limit the scope of the resync command to a single user.

    If a contractor's Directory Server entry is not important, do the following:

  1. Delete the Directory Server entry for the contractor, if there is one.

  2. Remove the -c prefix from the Active Directory entry’s samaccountname.

  3. Identity Synchronization for Windows will create the corresponding new user in Directory Server.