Sun Java System Identity Synchronization for Windows 6.0 Deployment Planning Guide

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.