Sun Java logo     Previous      Contents      Index      Next     

Sun logo
Sun Java System Identity Synchronization for Windows 1 2004Q3 Deployment Planning Guide 

Chapter 2
Case Study: Deploying in an Multi-Master Replication Environment

The case study provided in this chapter explains how Example Bank implemented Identity Synchronization for Windows in an Multi-Master Replication (MMR) environment. The case study includes information about the business imperatives, the technical requirements, and the Identity Synchronization for Windows implementation.

This chapter contains these sections:

Overview

This section provides an overview of the architecture and technical requirements for “Example Bank” and the Identity Synchronization for Windows features used in this case study. The information is organized as follows:

Existing Example Bank’s 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 Systems Directory Server (dc=eb,dc=com) deployment. They have two main sites; one located in New York city and other in Los Angeles.

The following figure describes Example Bank’s deployment of their 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. Authentication and password management on Solaris is done against Directory Server using the Pluggable Authentication Module (PAM) for LDAP. The two directory server masters 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 9 machines, 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 PDC runs on pdc-east.eb.com machine which is located in New York (NY). A back-up domain controller (bdc-west.eb.com) runs on a machine located in Los Angles (LA). All Windows NT users 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 Directory Server’s 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-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, consequently, each employee has either a Windows NT or an Active Directory account. The migration of the users is based (in phases) on the employees’ last names; each week they move users whose last name begins with the next letter of the alphabet. Currently, they have migrated employees whose last names begin with letters A through F.

For users that have Directory Server accounts, the Active Directory samaccountname attribute stores the uid. When a user 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.

Understanding Example Bank’s Technical Requirements

The following table describes Example Bank’s technical requirements:

Table 2-1  List of Requirements

Requirement

Comments

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

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

Users must be able to continue to change passwords using native mechanisms made in either environment.

That is, using the CTRL+ALT+DEL options on Windows and the passwd command on Solaris.

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 password changes to be propagated to Active Directory, Solaris must be configured to use the Pluggable Authentication Module for LDAP. This is discussed in detail in Appendix A, "Pluggable Authentication Modules".

Note: Passwords can be set in the Sun Directory Server by passing in a pre-hashed password value. Identity Synchronization for Windows cannot synchronize passwords from Directory Server to Windows if the password is pre-hashed. This is normally prevented because it circumvents password policy and password history.

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

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

Synchronization User Lists (SUL) feature of Identity Synchronization for Windows can be used to eliminate user accounts that should 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:

  • Active Directory SUL filter will be (!(samaccountname=c-*))
  • Windows NT SUL filter will be (!(USER_NAME=c-*))
  • Directory Server SULs will include(!(uid=c-*)) as part of their filter. Directory Server SUL filters also include information about whether the user is on 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 even synchronize attributes that are otherwise used as keys such as uid and cn.

Note: The SUL filter applies to all operations, so all other changes for contractors will not be synchronized either.

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 should not have an Active Directory account created automatically.

Identity Synchronization for Windows can synchronize new user accounts in either direction from Windows to Directory Server or Directory Server to Windows (or not all).

Entries deleted in either Directory Server or Active Directory should 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 all. For this requirement, Identity Synchronization for Windows will not synchronize account deletions bi-directionally, 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 inactived (disabled) in either Directory Server or Active Directory should be inactivated in the corresponding data source.

Identity Synchronization for Windows can synchronize inactivated accounts from Active Directory to Directory Server, Directory Server to Active Directory, both ways, or not all. For this requirement, Identity Synchronization for Windows synchronizes inactivated accounts bi-directionally, that is, from Active Directory to Directory Server and from Directory Server to Active Directory.

How Identity Synchronization for Windows detects account inactivations in Directory Server can be configured, Example Bank is not using a third-party application such as Sun Java System Access Manager to control access to their directory server, so the default account inactivation setting of inter-operating with the directory server tools suffices.

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

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

Identity Synchronization for Windows stores a Globally Unique Identifier (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. By manually removing the attribute and then re-running the idsync resync -f <linking-file> command, the entry is updated in Directory Server.

Users can move between ou=east and ou=west.

Identity Synchronization for Windows can move users between the Synchronization User Lists (SUL), and these changes are performed automatically without any administrator intervention.

Identity Synchronization for Windows Features Discussed in this Case Study

The following Identity Synchronization for Windows features are used for 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 first creates a special user that Identity Synchronization for Windows uses when connecting to Active Directory. This user is first created in the cn=Users container in the eb.com domain. Once 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.

    To assign administration rights to this special user
  1. In the Active Directory Users and Computers domain, from the Tree pane, right-click on the eb.com container icon.
  2. Select All Tasks > Delegate Control from the list.

    3. The Delegation of Control Wizard displays.

    Figure 2-2  Delegating User Control List Options

  3. Select the special user from the “Selected user and groups” list, and click Next.

    4. Figure 2-3  Selecting the Special User from the User and Group List

  4. Choose the Create a custom tasks to delegate option from the “Tasks to Delegate” window, and click Next.

    5. Figure 2-4  Tasks to Delegate Window Options

  5. Select the User Objects option from the list in the Only the following objects in the folder section.

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

    Figure 2-5  Objects to Delegate Control Wizard Options

  6. In the Permissions window, from the Show these permissions list, ensure that you select these options:
    • General
    • Property-Specific
    • Full Control

      • Because Example Bank wants to synchronize 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 (such as an idsync resync operation from Active Directory to Directory Server) will succeed, but other operations (such as detecting and applying changes in Active Directory) can fail abruptly.

      If Example Bank is synchronizing deletes from Active Directory to Directory Server, then even Full Control is insufficient. You must Identity Synchronization for Windows to use a Domain Administrator account to detect account deletions in Active Directory.

      Figure 2-6  Setting Permissions for the Special User Options

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 Directory Server master is running). Once the Core is installed, complete the following configuration procedure.

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 instance is set to master-east.eb.com. The Directory Server Connector uses this instance for detecting changes that require synchronization with the Active Directory and Windows NT, and also for updating the changes that are detected in the Active Directory and Windows NT. Alternatively, the master-west.eb.com domain could have been selected; however, the Directory Server Connector performance improves when connecting to a local directory server instead of a Directory Server located over a wide area network (WAN).

Note

Although SSL is not selected originally, it is required because Example Bank is synchronizing from Directory Server to Active Directory. The console will automatically enable this option when the password modification settings are changed.

    To specify a preferred directory source
  1. In the Console, from the Directory Sources window, click New Sun Directory.

    2. In the Specify a Preferred server, from the Define Sun Java System Directory Source dialog, select the appropriate Directory Source. In this case, master-east.eb.com

    Figure 2-7  Preferred Directory Server Instance Dialog

  2. In the Specify a Secondary Server, select the secondary Directory Server instance. In this case, master-west.eb.com.

    3. A secondary Directory Server instance can be specified to ensure availability when the preferred master, master-east.eb.com, is unavailable. The Secondary Directory Server instance, master-west.eb.com is selected as the secondary master directory server.

    If master-east.eb.com is unavailable, then the Directory Server Connector synchronizes changes made at the Active Directory to master-west.eb.com. Configuring a secondary directory source is optional.

    Figure 2-8  Specifying the Secondary Master Directory Server

Configuring the Active Directory Source

The Active Directory Global Catalog information is provided to allow the Identity Synchronization for Windows console to discover 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=users,dc=eb,dc=com, but this is changed 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
  1. In the Console, from the Directory Sources window, click New Active Directory Source button.

    2. The Windows Global Catalog dialog displays.

  2. Enter the fully qualified name in the Host field. In this example, it’s ad-west.ed.com.
  3. Change the default User DN (cn=Administrator) to the DN shown below as described earlier.
  4. Enter the password and click OK.

    5. Figure 2-9  Windows Global Catalog Dialog Options

  5. Provide credentials for the Active Directory domain.

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

    Figure 2-10  Credentials for the Active Directory Domain

  6. Specify the PDC FSMO role owner domain controller.

    7. The ad-west.eb.com domain controller is the PDC FSMO role owner and certain changes (for example, password modifications) made at other domain controllers are replicated immediately to it. The 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. Because the Active Directory Connector does fewer directory searches during change detection, the Active Directory Connector performs better across the WAN than the Directory Server Connector.

    Figure 2-11  PDC FSMO Role Owner Domain Controller Dialog

  7. Specify the failover domain controller for on-demand password synchronization.

    8. The ad-east.eb.com domain controller is selected as a failover domain controller for on-demand password synchronization. If ad-west.eb.com is unavailable, then the Directory Server Plugin performs on-demand password synchronization against ad-east.eb.com.

    Figure 2-12  Failover Domain Controller Dialog Options

Configuring the Windows NT Source

After the Directory Server and the Active Directory sources are configured, information is provided for the Windows NT domain.

Figure 2-13  Windows NT Directory Source Selection Dialog Options

These details are specified for the Windows NT directory source:

Configuring the Synchronization Settings

Once each directory source is configured, the synchronization parameters are configured to match Example Bank’s requirements.

Configuring the Attribute Modification Settings

These Attribute Modification settings reflect that Example Bank’s requirements to synchronize attribute changes and account inactivations, bi-directionally, between the Active Directory and Directory Server sources.

    To configure the attribute mappings
  1. In the Console, select the Configuration tab.
  2. Select the Attribute Modification tab.
  3. Select the “Attribute modifications in both directions” option.
  4. Select the “Synchronize Object Activation/Inactivation with Active Directory” option and, also ensure you select the “Interoperate with Directory Server tools” options.

    5. Figure 2-14  Attribute Mappings Window Options

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, select the Configuration tab.
  2. Select the Attributes tab.
  3. In the Synchronized Attributes list, enter the attributes that Example Bank’s requires synchronization with Directory Server.

    4. Figure 2-15  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 Object Creation Settings

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

Because Example Bank has an environment with both Active Directory and Windows NT, these settings apply to both systems. Not only will new users in Active Directory be synchronized to Directory Server, but also any new user created in Windows NT will also be synchronized. Because Example Bank is migrating all Windows NT users to Active Directory, no new users will be created in Windows NT, and this does not present a problem.

    To configure the attribute mappings
  1. In the Console, select the Configuration tab.
  2. Select the Object Creation tab.
  3. Select the “Object Creations flow from Windows to Sun Java System Directory Server” option.

    4. Figure 2-16  Object Creation Settings Window Options

Adding the ShadowAccount Objectclass

When configuring Identity Synchronization for Windows to interoperate with Solaris PAM LDAP, the shadowAccount object class is chosen 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-17  shadowAccount Object Class

Configuring the Creation Attributes

Use the Creation Attributes Mappings and values dialog box to configure additional attributes to be synchronized when an entry is created. Because sn is a mandatory attribute for the inetOrgPerson objectclass, you must provide a mapping or default value for sn. 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 and is only provided to conform to the Console’s validations.

The shadowmin, shadowmax, and shadowwarning attributes are used for PAM LDAP. A shadowmin value of 7 implies that a user must wait seven days once 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 shown in grey are mandatory creation attributes.The inetorgperson objectclass has cn and sn as mandatory attributes, and the shadowaccount objectclass has uid as a mandatory attribute.

Figure 2-18  Creation Attributes Dialog Options

Configuring the Synchronization User Lists

Because Example Bank has two Windows domains (one for Windows NT and one for Active Directory), at least two Synchronization User Lists (SUL) are required; one for Active Directory and one for Windows NT. However, Example Bank wants to synchronize two disjoint organizational units in Active Directory (ou=east and ou=west), and 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 contractors and only contractors’ USER_NAME value starts with c-.

Figure 2-19  Synchronization User List Dialog Options

The base DN of all synchronized users is “ou=people,dc=eb,dc=com” and 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:

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.

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

Figure 2-21  Synchronization User List Dialog Box Options

For SUL_NT list, only users under the ou=people,dc=eb,dc=com organizational unit will be synchronized. The filter for this SUL includes two components: (!(uid=c-*)) excludes contractors from synchronization, and (destinationindicator=eb.com) allows the connector to determine the Windows domain where the user resides.

Figure 2-22  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.

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

Figure 2-23  Synchronization User List Dialog Options

These settings are identical to the SUL_AD_EAST synchronization user list, which causes the following error.

Figure 2-24  Directory Server Criteria Options for Synchronization User List

When the configuration is saved, this 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)).”

Figure 2-25  Configuration Validity Status Dialog

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.

For summary information about the three defined SULs, click the Resolve Domain Overlap button.

When a change to a user is detected, that user entry is compared first with SUL_NT, if it fails to match, it’s compared with SUL_AD_WEST, and if it fails to match again, it’s compared with SUL_AD_EAST.

Figure 2-26  A List of SUL Parameters for Directory Server

For example:

Table 2-2  Example User Entry-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

Because SULs are evaluated from top to bottom, the program will not find a match for the SUL_AD_EAST entry. The program will encounter and evaluate the base dn and filter for the SUL_AD_WEST entry first, which is located immediately before SUL_AD_EAST entry. Consequently, the Console requires SULs to have different base DNs or filters.

An SUL is used primarily when a change to a user is detected. Evaluating which SUL the user resides in determines which 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:

Because the default behavior of idsync resync can be overridden and because Example Bank does want to synchronize user creations from Directory Server to Active Directory, the SUL_AD_WEST and SUL_AD_EAST can have the same base dn and filter.

You can ignore this warning message and, as a workaround, you can rearrange the filters. Change the (&(!(uid=c-*))(destinationindicator=eb.com)) filter to be equivalent to(&(destinationindicator=eb.com)(!(uid=c-*))). Because the Console only does string comparisons to determine if two filters are equivalent, this rearrangement passes the console’s validations.

Note

If there is no SUL filter or it only has a single component, then 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:

(&(!(uid=c-*)(destinationIndicator=eb.com)
  (!(bogusAttr=SUL_AD_WEST)))

(&(!(uid=c-*)(destinationIndicator=eb.com)
  (!(bogusAttr=SUL_AD_EAST)))

Figure 2-27  Validating SUL_AD_EAST

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

TODO List

Once the configuration is saved successfully, the following list of pending installation steps should be completed.

Figure 2-28  To Do List Dialog

Installing the Connectors and Directory Server Plugin

The Active Directory and Directory Server connectors are installed on master-east.eb.com. The Windows NT Connector is installed on the PDC pdc-east.eb.com. The Directory Server Plugins are installed on the two masters master-east.eb.com and master-west.eb.com.

Figure 2-29  Installation Steps Pending

Because there are no other directory server masters or read-only replicas in this environment, the next step is to perform the idsync resync procedure to link all existing users.

Running idsync resync

In Example Bank’s deployment, users already have accounts in Directory Server and in Windows, so you must run idsync resync to establish links between equivalent users before starting synchronization. Linking the users is done using the -f <linking-file> option to resync. For detailed information on the idsync resync command, see the Sun Java System Identity Synchronization for Windows Installation and Configuration Guide.

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

For all users with Active Directory accounts, their Directory Server password 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:

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:

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

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

For information on the syntax used in this example, see the Sun Java System Identity Synchronization for Windows Installation and Configuration 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 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 executed again with the new linkusers-ad-only.cfg linking file and the -a option to run the command for our test user John Test only. However, a message is displayed that indicates one entry matched a user in Directory Server but the Directory Server user was not 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" option to the is added to the linkusers-ad-only.cfg file:

Note

Whenever a configuration has multiple SULs, the allowLinkingOutOfScope=true parameter should be used.

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

Verify that John Test can log onto 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 with linkusers-nt-only.cfg, 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 their users by running idsync resync, most of the users are linked successfully, but some users cannot be linked due to data inconsistencies. Once these inconsistencies are manually repaired, 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 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 above examples, the destinationIndicator attribute is automatically populated with the correct Windows domain name. Because they are synchronized attributes, the Directory Server attributes cn and uid are also updated.

The users are linked based on uid, the uid is already in sync but the cn in Directory Server may be replaced with a value from Active Directory. This may be not be appropriate when Directory Server is the authoritative for these attributes.

The following procedure describes synchronization of attribute values in Active Directory with the values in Directory Server after linking the entries.

Configuration and Installation Summary

This section summarizes the configuration procedure as determined by the main requirements of Example Bank.

Multiple Domains

When configuring Identity Synchronization for Windows to support multiple domains:

PAM LDAP

This section describes the procedure necessary to configure Identity Synchronization for Windows to support PAM LDAP.

For information on the prerequisites and details on the procedure to conform to PAM LDAP on the Solaris side, see Appendix A.

WAN Deployment

Identity Synchronization for Windows has limited support for WAN deployments. It can synchronize with the Directory Server or the 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.

This was achieved in this scenario by installing the Identity Synchronization for Windows Core, Directory Server Connector, and the Active Directory Connector on the same machine, and the 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 will be significantly delayed if it was selected.

Note

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

  • On the same LAN as Directory Server
  • Or on the same LAN as Active Directory
  • Or 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 requires at least 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 discuses the procedure to migrate users from Windows NT to Active Directory (moving a user between Windows domains).

Example Bank wants to migrate users each week from Windows NT to Active Directory based on their last name and that they have migrated users whose last names start with A-F.

Once 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 for the migrated Windows NT accounts, and then the Active Directory accounts are linked to their corresponding Directory Server entries.

Note

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

In this example, the users are moved from a Windows NT domain to a Windows 2000 domain, but the same procedure can be followed when moving users are between Windows NT domains or Windows 2000 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. It 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. Once these users have been migrated, the following unlink.pl script invocation 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 subset of users.

Linking Migrated Active Directory Entries

Once the links in the Directory Server entries are removed, new links are established with the Active Directory entries. The idsync resync command is executed to achieve this. 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 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), nothing needs to be done for this user to continue to be synchronized by Identity Synchronization for Windows.

When Contractors Change to Full-Time Employees

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

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

Table 2-3  Guidelines for Handling Contractor Accounts 

Active Directory

Directory Server

Creating Linked Entries in Active Directory and Directory Server

No

No

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

No

Yes

  1. Remove the c- prefix from the Directory Server entry’s uid
  2. Create a new entry in Active Directory for the contractor
  3. Run idsync resync to establish a link between the new full-time employee. The -a option can be used to limit the scope of the resync to a single user

Or if there is nothing important in the Directory Server entry:

  1. Delete the Directory Server entry for the contractor if there was one already
  2. Create a new entry in Active Directory
  3. Identity Synchronization for Windows will create the corresponding new user in Directory Server

Yes

No

  1. Remove the c- prefix from the Active Directory entry’s samaccountname
  2. Identity Synchronization for Windows will interpret the change as a new user and will create the corresponding new user in Directory Server

Yes

Yes

  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 was modified before the Directory Server entry, then the contractor would 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 between the new full-time employee.
    The -a option can be used to limit the scope of the resync to a single user

Or if there is nothing important in the Directory Server entry:

  1. Delete the Directory Server entry for the contractor if there was one already
  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



Previous      Contents      Index      Next     

Part No: 817-6200.   Copyright 2004 Sun Microsystems, Inc. All rights reserved.