This section provides instructions for the following tasks:
Example Bank creates a special user that Identity Synchronization for Windows uses when connecting to Active Directory. This user is created in the cn=Users container in the eb.com domain. After the user is created, a minimum set of administration rights is assigned to this user.
Identity Synchronization for Windows automatically creates a similar user with limited privileges in Directory Server. This user is created as the uid=PSWConnector,<synchronized suffix\> user.
In the Tree pane of the Active Directory Users and Computers window, right-click the eb.com container icon.
From the All Tasks menu, choose Delegate Control.
In the Selected User and Groups list, select the special user and click Next.
In the Tasks to Delegate window, select Create a Custom Tasks to Delegate, and click Next.
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.
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.
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.
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:
This section explains how to configure the following directory sources:
When configuring the Directory Server source, the preferred Directory Server is set to master-east.eb.com. The Directory Server Connector uses this Directory Server to detect and update changes that require synchronization with Active Directory and Windows NT. Alternatively, the master-west.eb.com domain could have been selected. However, Directory Server Connector performance is better when connecting to a local Directory Server instead of a Directory Server located over a wide area network (WAN).
When the password modification settings are changed, the Console automatically enables the SSL option, which is required while synchronizing from Directory Server to Active Directory.
In the Directory Sources window of the Identity Synchronization for Windows Console (Console), click New Sun Directory.
In the Define Sun Java System Directory Source dialog box, select Specify a Preferred Server.
Select Choose a Known Server and then choose a preferred Directory Server from the drop-down menu, in this case, master-east.eb.com.
(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.
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.
In the Console, in the Directory Sources window, click New Active Directory Source.
Type the fully qualified name in the Host field, in this example, ad-west.ed.com.
Change the default User DN (cn=Administrator) to the DN cn=iswUser,cn=Users,dc=eb,dc=com.
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.
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.
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.
After the Directory Server and the Active Directory sources are configured, configure the Windows NT domain.
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.
Select Specify the Windows NT Domain, type the Windows NT domain, in this case, EXBANK, and click Next.
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.
After each directory source is configured, the synchronization parameters are configured to match Example Bank’s requirements as explained in these section:
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.
In the Console, click the Configuration tab, then click the Attributes tab.
Under Synchronized Attributes, enter the attributes that Example Bank requires to synchronize with Directory Server.
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.
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.
In the Identity Synchronization for Windows Console, click the Configuration tab, then click the Attribute Modification tab.
Select Attribute Modifications Flow in Both Directions.
Select the Synchronize Object Activation/Inactivation with Active Directory check box and select Interoperate With Directory Server Tools.
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.
In the Console, click the Configuration tab, then click the Object Creation tab.
Select the Object Creations Flow From Windows to Sun Java System Directory Server check box.
To synchronize object deletions, click the Object Deletion tab and select Object Deletions Flow From Windows to Sun Java System Directory Server check box.
You can create or delete a group, and associate or disassociate users with that group in a directory environment. If Group Synchronization is enabled, the changes that you make in one directory environment automatically propagate to the other directory environment. All the users are synchronized across the directory servers with their group membership intact.
When Group Synchronization is enabled, the uniquemember Directory Server attribute and the member attribute Active Directory attribute are internally mapped.
In the Console, click the Configuration tab, then click the Groups tab.
Select the Enable Group Synchronization check box.
From the drop-down menu, choose Domain Global Security or Domain Global Distribution to propagate groups from Sun Directory Server to Active Directory.
In Identity Synchronization for Windows, account lockout and unlockout are synchronized between the Directory Server and Active Directory sources.
In the Console, click the Configuration tab, then click the Account Lockout tab.
Select the Enable Account Lockout Synchronization check box.
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.
Use the Creation Attribute Mappings and Values dialog box to configure additional attributes to be synchronized when an entry is created.
Click Creation Attributes under the Object Creation tab.
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.
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.
This SUL provides details required to synchronize users between Windows NT and Directory Server.
When detecting changes in Windows NT, contractors are excluded from synchronization by the (!(USER_NAME=c-*)) filter because each contractor USER_NAME value starts with c-.
The base DN of all synchronized users is, ou=people,dc=eb,dc=com. The Creation Expression, uid=%uid%,ou=people,dc=eb,dc=com, implies that new users will be created in the same container with uid as the naming attribute.
The filter for this SUL includes two components:
(!(uid=c-*)) excludes contractors from synchronization.
(destinationindicator=EXBANK) allows the Directory Server Connector to determine the Windows domain where the user resides. (when it detects a change to the user)
This SUL provides details required to synchronize users between the Active Directory ou=east,dc=eb,dc=com container and Directory Server.
The SUL settings imply that all users under ou=east,dc=eb,dc=com will be synchronized from Active Directory to Directory Server except users whose samaccountname starts with c- (contractors).
For the SUL_AD_EAST list, only users under the ou=east,dc=eb,dc=com organizational unit will be synchronized. The filter for this SUL includes two components:
(!(uid=c-*)) excludes contractors from synchronization
destinationindicator=eb.comallows the Connector to determine the Windows domain where the user resides.
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).
The SUL_AD_WEST settings are identical to the settings in SUL_AD_EAST.
When the configuration is saved, this error message is displayed:
“Synchronization User Lists: SUL_AD_EAST and SUL_AD_WEST contain duplicate directory source, dc=eb,dc=com, location, ou=people,dc=eb,dc=com, and filter, (&(!(uid=c-*)(destinationindicator=eb.com)).”
When there are multiple SULs, Identity Synchronization for Windows requires that the base DN or the filter is unique. When Identity Synchronization for Windows detects a change to a user, it iterates through the list of SULs until it matches a user. The user entry is compared first with SUL_NT. If it fails to match, it is compared with SUL_AD_WEST. If it fails to match again, it is compared with SUL_AD_EAST.
For summary information about the three defined SULs, click Resolve Domain Overlap.
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:
When the idsync resync -f command is executed to establish links between existing users, by default Identity Synchronization for Windows will only link to a Directory Server user that is in the same SUL as the Active Directory user. This behavior can be overridden as described in Running idsync resync.
Before a new entry can be synchronized to Directory Server or Active Directory, its DN is constructed using the creation expression, which is specific to each SUL.
The default behavior of idsync resync can be overridden if Example Bank wants to synchronize user creations from Directory Server to Active Directory, that is, the SUL_AD_WEST and SUL_AD_EAST can have the same base DN and filter.
Thus, you can ignore the previous warning message and, as a workaround, rearrange the filters. Change the (&(!(uid=c-*))(destinationindicator=eb.com)) filter to be equivalent to(&(destinationindicator=eb.com)(!(uid=c-*))). This rearrangement passes the console’s validations because the console only performs the string comparisons to determine if the two filters are equivalent.
If there is no SUL filter or it has only a single component, an SUL filter (or filter component) is added. This SUL filter component is different for each SUL but always evaluates to true.
For example, the SUL definitions for SUL_AD_WEST and SUL_AD_EAST could also be defined as follows:
(&(!(uid=c-*)(destinationindicator=eb.com) (!(bogusAttr=SUL_AD_WEST)))
(&(!(uid=c-*)(destinationindicator=eb.com) (!(bogusAttr=SUL_AD_EAST)))
The new definition of SUL_AD_EAST passes the Console’s validation.
After the configuration is saved successfully, you install the connectors and the Directory Server plug-ins.
The Active Directory and Directory Server connectors are installed on master-east.eb.com. The Windows NT Connector is installed on the Primary Domain Controller pdc-east.eb.com. The Directory Server plug-ins are installed on the two preferred Directory Servers, that is, master-east.eb.com and master-west.eb.com.
Perform the idsync resync procedure to link all the existing users as there are no other preferred Directory Servers or read-only replicas in this environment.
In Example Bank’s deployment, users already have accounts in Directory Server and in Windows. You must run idsync resync to establish links between equivalent users before starting synchronization. Use the -f <linking-file\> resync option to link the users. For detailed information about the idsync resync command, see “Using idsync resync in Sun Java System Directory Server Enterprise Edition 6.1 Installation Guide,” in Sun Java System Directory Server Enterprise Edition 6.3 Installation Guide.
Running idsync resync initializes the destinationindicator attribute in each Directory Server entry, which ensures that the existing users in Directory Server match their SUL filter. If this attribute is not initialized with each user’s Windows domain, changes to Directory Server users do not propagate back to Windows because the entry does not match the destinationindicator part of the SUL filter. In situations where the destinationindicator attribute is not populated, running the idsync resync command without the -k option establishes links between the users.
All users with Active Directory accounts have a Directory Server password that is synchronized with their Active Directory password, using the -i NEW_LINKED_USERS option.
For example, the process of linking a single user “John Test” is described here. This user has an Active Directory account in the ou=east organizational unit. The user entry is as follows:
bash-2.05# ./ldapsearch -h ad-west.eb.com -b "dc=eb,dc=com" -D "cn=Administrator,cn=users,dc=eb,dc=com" -w < password omitted\> "samaccountname=jtest" version: 1 dn: CN=John Test,OU=east,DC=eb,DC=com accountExpires: 9223372036854775807 badPasswordTime: 0 badPwdCount: 0 codePage: 0 cn: John Test countryCode: 0 displayName: John Test givenName: John instanceType: 4 lastLogoff: 0 lastLogon: 0 logonCount: 0 distinguishedName: CN=John Test,OU=east,DC=eb,DC=com objectCategory: CN=Person,CN=Schema,CN=Configuration,DC=eb,DC=com objectClass: top objectClass: person objectClass: organizationalPerson objectClass: user objectGUID:: dYGjjEBYukyXXMJ//08KNw== objectSid:: AQUAAAAAAAUVAAAAFSWvR+sleSxDFwoyUwQAAA== primaryGroupID: 513 pwdLastSet: 127426694450768912 name: John Test sAMAccountName: jtest sAMAccountType: 805306368 sn: Test userAccountControl: 512 userPrincipalName: jtest@eb.com uSNChanged: 7043 uSNCreated: 7039 whenChanged: 20041019142405.0Z whenCreated: 20041019142404.0Z
The user’s password in Active Directory is abc:
bash-2.05# ./ldapsearch -h ad-west.eb.com -b "dc=eb,dc=com" -D "cn=John Test,ou=east,dc=eb,dc=com" -w abc "samaccountname=jtest" version: 1 dn: CN=John Test,OU=east,DC=eb,DC=com cn: John Test
The user’s Directory Server account is as follows:
bash-2.05# ./ldapsearch -h master-east.eb.com -b "dc=eb,dc=com" -D "cn=Directory Manager" -w <password omitted\> "uid=jtest" version: 1 dn: uid=jtest,ou=People, dc=eb,dc=com uid: jtest givenName: John objectClass: top objectClass: person objectClass: organizationalPerson objectClass: inetorgperson sn: Test cn: John Test userPassword: {SSHA}CwM7vTIJUEN+aahj1kUH/1/CruIKJ1Vw1hN0eA==
The user’s password in Directory Server is 123:
bash-2.05# ./ldapsearch -h master-east.eb.com -b "dc=eb,dc=com" -D "uid=jtest,ou=people,dc=eb,dc=com" -w 123 "uid=jtest" cn version: 1 dn: uid=jtest,ou=People, dc=eb,dc=com cn: John Test
The following file is used to link Active Directory users and Windows NT users to the equivalent Directory Server users.
For information on the syntax used in this example, see Sun Java System Directory Server Enterprise Edition6.3 Installation Guide. Samples are available in the samples/ directory where Core is installed.
A separate section is provided for each SUL. Active Directory and Directory Server users are linked if their Active Directory samaccountname attribute matches their Directory Server uid attribute. Windows NT and Directory Server users are linked if their Windows NT USER_NAME attribute matches their Directory Server uid attribute.
<?xml version="1.0" encoding="UTF-8"?\> <UserLinkingOperationList\> <UserLinkingOperation parent.attr="UserLinkingOperation" sulid="SUL_AD_EAST"\> <UserMatchingCriteria parent.attr="UserMatchingCriteria"\> <AttributeMap parent.attr="AttributeMap"\> <AttributeDescription parent.attr="SunAttribute" name="uid"/\> <AttributeDescription parent.attr="WindowsAttribute" name="samaccountname"/\> </AttributeMap\> </UserMatchingCriteria\> </UserLinkingOperation\> <UserLinkingOperation parent.attr="UserLinkingOperation" sulid="SUL_AD_WEST"\> <UserMatchingCriteria parent.attr="UserMatchingCriteria"\> <AttributeMap parent.attr="AttributeMap"\> <AttributeDescription parent.attr="SunAttribute" name="uid"/\> <AttributeDescription parent.attr="WindowsAttribute" name="samaccountname"/\> </AttributeMap\> </UserMatchingCriteria\> </UserLinkingOperation\> <UserLinkingOperation parent.attr="UserLinkingOperation" sulid="SUL_NT"\> <UserMatchingCriteria parent.attr="UserMatchingCriteria"\> <AttributeMap parent.attr="AttributeMap"\> <AttributeDescription parent.attr="SunAttribute" name="uid"/\> <AttributeDescription parent.attr="WindowsAttribute" name="USER_NAME"/\> </AttributeMap\> </UserMatchingCriteria\> </UserLinkingOperation\> </UserLinkingOperationList\> |
When the idsync resync command with the linkusers.cfg file is executed, a message that the -i option is not supported for Windows NT SULs is displayed:
bash-2.05# ./idsync resync -w <omitted password\> -q <omitted password\> -f linkusers.cfg -i NEW_LINKED_USERS Validating and starting refresh operation ”1098189761942’. Hit CTRL+C to cancel.The operation cannot be started because passwords cannot be reset from Windows NT Synchronization User Lists. The resync operation must not include the ”SUL_NT’ Synchronization User List. Please remove this option or explicitly specify non-Windows NT Synchronization User Lists using the -l option.
Split the linkusers.cfg file into a file that has only the Windows NT SUL, and the following file, linkusers-ad-only.cfg, that has both Active Directory SULs:
<?xml version="1.0" encoding="UTF-8"?\> <UserLinkingOperationList\> <UserLinkingOperation parent.attr="UserLinkingOperation" sulid="SUL_AD_EAST"\> <UserMatchingCriteria parent.attr="UserMatchingCriteria"\> <AttributeMap parent.attr="AttributeMap"\> <AttributeDescription parent.attr="SunAttribute" name="uid"/\> <AttributeDescription parent.attr="WindowsAttribute" name="samaccountname"/\> </AttributeMap\> </UserMatchingCriteria\> </UserLinkingOperation\> <UserLinkingOperation parent.attr="UserLinkingOperation" sulid="SUL_AD_WEST"\> <UserMatchingCriteria parent.attr="UserMatchingCriteria"\> <AttributeMap parent.attr="AttributeMap"\> <AttributeDescription parent.attr="SunAttribute" name="uid"/\> <AttributeDescription parent.attr="WindowsAttribute" name="samaccountname"/\> </AttributeMap\> </UserMatchingCriteria\> </UserLinkingOperation\> </UserLinkingOperationList\> |
The idsync resync command is run again by using the new linkusers-ad-only.cfg file and the -a option to run the command for the test user John Test. However, a message is displayed indicating that one entry matched a user in Directory Server, but the Directory Server user was not found in any SUL.
The Directory Server users do not have their destinationindicator attributes populated with the correct Windows domain names. Therefore, the test user did not match any of the SUL filters.
bash-2.05# ./idsync resync -w <omitted password\> -q <omitted password\> -f linkusers-ad-only.cfg -i NEW_LINKED_USERS -a "(samaccountname=jtest)" Validating and starting refresh operation ”1098193309618’. Hit CTRL+C to cancel. User progress: # Entries sent: 1 User progress: # Entries sent: 1 # Entries that matched a user that is in no SUL: 1 SUCCESS
To address this issue, the allowLinkingOutOfScope="true" parameter is added to the linkusers-ad-only.cfg file:
Whenever a configuration has multiple SULs, use the allowLinkingOutOfScope=true parameter.
<?xml version="1.0" encoding="UTF-8"?\> <UserLinkingOperationList allowLinkingOutOfScope="true"\> <UserLinkingOperation parent.attr="UserLinkingOperation" sulid="SUL_AD_EAST"\> <UserMatchingCriteria parent.attr="UserMatchingCriteria"\> <AttributeMap parent.attr="AttributeMap"\> <AttributeDescription parent.attr="SunAttribute" name="uid"/\> <AttributeDescription parent.attr="WindowsAttribute" name="samaccountname"/\> </AttributeMap\> </UserMatchingCriteria\> </UserLinkingOperation\> <UserLinkingOperation parent.attr="UserLinkingOperation" sulid="SUL_AD_WEST"\> <UserMatchingCriteria parent.attr="UserMatchingCriteria"\> <AttributeMap parent.attr="AttributeMap"\> <AttributeDescription parent.attr="SunAttribute" name="uid"/\> <AttributeDescription parent.attr="WindowsAttribute" name="samaccountname"/\> </AttributeMap\> </UserMatchingCriteria\> </UserLinkingOperation\> </UserLinkingOperationList\> |
When the idsync resync command is executed again, the test user is successfully linked and updated with the destinationindicator attribute value.
bash-2.05# ./idsync resync -w <omitted password\> -q <omitted password\> -f linkusers-ad-only.cfg -i NEW_LINKED_USERS -a "(samaccountname=jtest)" Validating and starting refresh operation ”1098191329451’. Hit CTRL+C to cancel. User progress: # Entries sent: 1 User progress:# Entries sent: 1 # Entries successfully linked: 1 # Entries that were modified: 1 SUCCESS
The following changes occur in the Directory Server entry:
The dspswuserlink attribute is set to match the objectguid attribute in the Active Directory entry.
The destinationindicator attribute is set to match the Active Directory domain name (eb.com).
The dspswvalidate operation attribute is set to true, which implies that the Directory Server password is stale and the user requires on-demand password synchronization.
The value does not change until the user logs in to Directory Server using the Active Directory password, triggering on-demand password synchronization. Although the Directory Server password was reset to the Active Directory value, the userPassword attribute has not changed.
The user now has the dspswuser auxiliary object class, which allows the use of Identity Synchronization for Windows specific attributes in the user entry (for example, dspswuserlink).
bash-2.05# ./ldapsearch -h master-west.eb.com -b "dc=eb,dc=com" -D "cn=Directory Manager" -w <omitted password>\> "uid=jtest" "*" dspswvalidate version: 1 dn: uid=jtest,ou=People, dc=eb,dc=com dspswvalidate: true dspswuserlink:: dYGjjEBYukyXXMJ//08KNw== destinationindicator: eb.com cn: John Test userPassword: {SSHA}sTpxX8RQcz4GjqJOttSauXNjWcnaR/hC1X7gPA== uid: jtest givenName: John objectClass: top objectClass: person objectClass: organizationalPerson objectClass: inetorgperson objectClass: dspswuser sn: Test
Verify that John Test can log in to Directory Server using the Active Directory password (abc):
bash-2.05# ./ldapsearch -h master-east.eb.com -b "dc=eb,dc=com" -D "uid=jtest,ou=people,dc=eb,dc=com" -w abc "uid=jtest" cn version: 1 dn: uid=jtest,ou=People, dc=eb,dc=com cn: John Test
After the user has logged into Directory Server and when an ldapsearch is executed, the on-demand password synchronization has removed the dspswvalidate attribute and updated the userPassword attribute:
bash-2.05# ./ldapsearch -h master-west.eb.com -b "dc=eb,dc=com" -D "cn=Directory Manager" -w <omitted password\> "uid=jtest" "*" dspswvalidate version: 1 dn: uid=jtest,ou=People, dc=eb,dc=com userPassword: {SSHA}8wmyeFe2bLrOkwM/SUStqmx63CeIHCASLFujUQ== dspswuserlink:: dYGjjEBYukyXXMJ//08KNw== destinationindicator: eb.com cn: John Test uid: jtest givenName: John objectClass: top objectClass: person objectClass: organizationalPerson objectClass: inetorgperson objectClass: dspswuser sn: Test
To link all of the Active Directory users, the same idsync resync command is executed without the -a option:
bash-2.05# ./idsync resync -w <omitted password\> -q <omitted password\> -f linkusers-ad-only.cfg -i NEW_LINKED_USERS
To link all of the Windows NT users, the idsync resync command is run on the linkusers-nt-only.cfg file, which contains information about SUL_NT: (without the -i NEW_LINKED_USERS option)
bash-2.05# ./idsync resync -w <omitted password\> -q <omitted password\> -f linkusers-nt-only.cfg
When Example Bank links all of its users by running idsync resync, most of the users are linked successfully, but some users cannot be linked due to data inconsistencies. After these inconsistencies are manually corrected, idsync resync is run again to link the remaining users.
The next section discusses how to resolve an issue when users are migrated from Windows NT to Active Directory.
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.
Change the configuration so the only synchronized attributes are userPassword and destinationindicator.
Execute the idsync resync -f <linking file\> command to link the entries and populate the destinationindicator attribute.
Change the configuration to include all the synchronized attributes. For example, add cn and uid.
Execute the idsync resync -o Sun command to synchronize the Active Directory attributes with their Directory Server values.
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.
This section summarizes the configuration tasks based on the main requirements of Example Bank.
Configuring Identity Synchronization for Windows to support multiple domains involves the following:
Setting up destinationindicator <-\> activedirectorydomainname <-\> user_nt_domain_name as a synchronized attribute
Using destinationindicator in the SUL filters so that entries modified in Directory Server can be located in the proper Active Directory domain
When linking users by using the idsync resync command, specifying allowLinkingOutOfScope="true" in the input file.
Do not specify the -k option because you want the destinationindicator attribute to be primed.
Configuring Identity Synchronization for Windows to support PAM LDAP involves the following:
Adding shadowAccount as an auxiliary object class for Directory Server
Adding the creation attribute default values for various shadowAccount attributes
For information about the prerequisites and how to conform to PAM LDAP on the Solaris OS, see Appendix A, Pluggable Authentication Modules.
Identity Synchronization for Windows has limited support for WAN deployments and can be synchronized with the Directory Server or Active Directory domain controllers that are only available over the WAN. However, the Identity Synchronization for Windows Core and all the connectors must be installed on the same LAN.
The setup in this scenario was achieved by installing the following:
Identity Synchronization for Windows Core.
Directory Server Connector.
Active Directory Connector on the same machine where Identity Synchronization for Windows Core and Directory Server Connector are installed.
Windows NT Connector on a machine in the same LAN.
In this case study, the Active Directory Connector communicates across the WAN with the Active Directory domain controller on the west coast. A domain controller is available on the east coast, but because it is not the PDC FSMO role owner, synchronization would be significantly delayed if it was selected.
When the Directory Server domain controller and Active Directory domain controller are separated by a WAN, you have the option of installing Identity Synchronization for Windows in one of the following:
On the same LAN as Directory Server
On the same LAN as Active Directory
Somewhere in between
In general, the best performance is achieved when Identity Synchronization for Windows is installed on the same LAN as Directory Server.
Identity Synchronization for Windows has been tested in a variety of WAN environments, but it requires minimum a link with at least T1 (1.44 Mb/sec) speeds and a round-trip latency of no more than 300 milliseconds.
This section explains how to migrate users between Windows domains, which involves the following:
Moving user accounts from Windows NT to Active Directory
Unlinking migrated Windows NT entries
Linking migrated Active Directory entries
Example Bank wants to migrate users each week from Windows NT to Active Directory based on each user's last name. Example Bank has already migrated users whose last name starts with A-F.
After the accounts have been migrated to Active Directory, changes made to migrated users in Directory Server or Active Directory will not be synchronized:
Changes made in Directory Server are detected. However, each entry will still be linked to a Windows NT entry. The entry is processed by the Windows NT Connector, but the user no longer exists in Windows NT.
Changes made in Active Directory are also detected but the entry does not match a Directory Server entry because it has not been linked.
To establish links between the migrated Active Directory accounts and the Directory Server entries, the links are removed from the migrated Windows NT accounts. Then, the Active Directory accounts are linked to their corresponding Directory Server entries.
To avoid losing too many changes, perform the full migration when the load on Directory Server is light. The idsync resync command can be run to recover any changes except changes to the passwords.
In this scenario, the users are moved from a Windows NT domain to an Active Directory domain, but the same procedure can be followed when moving users are between Windows NT domains or Active Directory domains.
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.
After the links in the Directory Server entries are removed, new links are established with the Active Directory entries by using the idsync resync command. Use the -a option with the (sn=G*) filter to link only the users that have been migrated.
According to Microsoft’s documentation, user passwords will be migrated when users are moved from Windows NT to Active Directory. However, if users change their passwords in Active Directory before they are relinked to the Directory Server entries, these password changes will not be synchronized to the Directory Server.
You can use the -i NEW_LINKED_USERS option with the idsync resync command to synchronize Directory Server passwords with their Active Directory values.
If any of the users’ passwords are modified in Directory Server during the migration process, these password changes will be lost.
bash-2.05# ./idsync resync -w <omitted password\> -q <omitted password\> -f linkusers-ad-only.cfg -i NEW_LINKED_USERS -a "(sn=G*)" Validating and starting refresh operation ’1098238348483’. Hit CTRL+C to cancel. User progress: # Entries sent: 1346 # Entries successfully linked: 1346 # Entries that were modified: 1346 SUCCESS
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 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