Before installing Identity Synchronization for Windows 6.0 or before migrating from Sun Java System Identity Synchronization for Windows 1 2004Q3 SP1 to version 6.0, familiarize yourself with the installation and configuration process.
For information about the Identity Synchronization for Windows installation requirements, see Chapter 6, Identity Synchronization for Windows Bugs Fixed and Known Problems, in Sun Directory Server Enterprise Edition 7.0 Release Notes.
Identity Synchronization for Windows can also be installed in French, German, Spanish, Japanese, Korean, Simplified Chinese, and Traditional Chinese languages. All the languages are bundled in the same distribution.
For multilingual support for Identity Synchronization for Windows, use the UTF-8 encoding.
This chapter covers the following topics:
This section illustrates a single-host installation procedure for Identity Synchronization for Windows.
Some components must be installed in a particular order, so be sure to read all installation instructions carefully.
Identity Synchronization for Windows provides a “To Do” list, which is displayed throughout the installation and configuration process. This information panel lists all of the steps that you must follow to successfully install and configure the product.
As you go through the installation and configuration process, all completed steps in the list are grayed-out as shown in Figure 6–2.
The rest of this section provides an overview of the installation and configuration process.
When you install Core, you will be installing the following components:
Sun Java System Administration Server. Configures the Directory Server Plug-in and provides the administration framework.
Console. Provides a centralized location for performing all of the product’s component configuration and administration tasks.
Central logger. Centralizes all audit and error logging information in a central location.
System manager. Delivers configuration updates to connectors dynamically and maintains the status of each connector.
Instructions for installing Core are provided in Chapter 3, Installing Core
After installing Core, use Console to initially configure the directory sources to be synchronized and other characteristics of the deployment, all from a centralized location.
Instructions for configuring directory resources are provided in Chapter 4, Configuring Core Resources.
Before you can install Directory Server Connectors, you must prepare a Sun Java System Directory Server source for every preferred and secondary Directory Server that is being synchronized.
You can perform this task from the Console, or from the command line by using the idsync prepds subcommand.
Instructions for preparing Directory Server are provided in Preparing Sun Directory Source.
You can install any number of connectors depending on the number of configured directories in your topology. Both the Console and the installation program use the directory label to associate a connector with the directory that is synchronized. The following table describes the label naming conventions.
Table 2–1 Label Naming ConventionsTable 2–2 Label Naming Examples
Connector Name |
Directory Source |
CNN100 |
SunDS1 on ou=isw_data1 |
CNN101 |
AD1 |
CNN102 |
SunDS1 on ou-isw_data2 |
CNN103 |
SunDS2 |
Instructions for installing and configuring Connectors are provided in Chapter 3, Installing Core
After installing the connectors, plug-ins, and subcomponents, you must run the idsync resync command-line utility to bootstrap deployments with existing users. This command uses administrator-specified matching rules to do the following:
Link existing entries (for more information about linking users , see Linking Users)
Populate an empty directory with the contents of a remote directory
Bulk-synchronize attribute values (including passwords) between two existing user populations, where entries in both the Windows and Directory Server directories are uniquely identified and linked to each other
Instructions for synchronizing existing users in your deployment are provided in Chapter 6, Synchronizing Existing Users and User Groups.
After installing the product, you must configure the product deployment, which includes doing the following:
Configuring the directories and global catalogs to be synchronized
Specifying synchronization settings for attribute modifications and object activations/inactivations
Specifying settings for group synchronization
Specifying settings for account lockout and unlockout synchronization
(optional) Specifying synchronization settings for user entry creations and deletions between the configured directories
This section provides an overview of the following configuration element concepts:
Directories
Synchronization Settings
Object classes
Attributes and Attribute Mapping
Synchronization User Lists
Some related configuration instructions appear in Chapter 4, Configuring Core Resources.
A directory represents the following:
A single root suffix (suffix/database) in one or more Sun Java System Directory Servers
A single Active Directory domain in a Windows 2000 or Windows 2003 Server Active Directory forest
A single Windows NT domain
You can configure any number of each directory type.
You use synchronization settings to control the direction in which object creations, object deletions, passwords and other attribute modifications are propagated between Directory Server and Windows directories. Synchronization flow options are as follows:
From Directory Server to Active directory/Windows NT
From Active directory/Windows NT to Directory Server
Bidirectionally
In a configuration that includes Active Directory and Windows NT, it is not possible to save a configuration that specifies different synchronization settings for creations or modifications between Windows NT and Directory Server, and between Active Directory and Directory Server.
When you configure resources, you will specify which entries to synchronize based on their object class. Object classes determine which attributes will be available to synchronize for both Directory Server and Active Directory.
Object classes are not applicable for Windows NT.
Identity Synchronization for Windows supports two types of object classes:
Structural object classes. Every entry that’s created or synchronized from the selected Directory Server must have at least one structural object class. Choose a structural object class from the drop-down menu. (Defaults to inetorgperson on Directory Server and to User on Active Directory.)
Auxiliary object classes.
Directory Server allows you to select one or more object classes from the Available Auxiliary Object Classes list to augment the selected structural class. The structural class provides additional attributes for synchronization.
Active Directory is more restrictive with the auxiliary object class. Attributes on all valid auxiliary object classes for the selected structural object class will be available for synchronization.
For instructions on configuring object classes and attributes, see Chapter 4, Configuring Core Resources
Attributes hold descriptive information about a user entry. Every attribute has a label and one or more values, and follows a standard syntax for the type of information that can be stored as the attribute value.
You can define attributes from the Console. See Chapter 4, Configuring Core Resources.
Identity Synchronization for Windows synchronizes significant and creation user attributes, as follows:
Significant attributes. Synchronized between Directory Server and Windows directories whenever the attributes are modified according to specified modification synchronization settings.
Creation attributes. Synchronized between Directory Server and Windows directories whenever a new user is created, according to specified object creation synchronization settings.
Mandatory creation attributes are attributes that are considered “mandatory” to successfully complete a creation action in the target directory. For example, Active Directory expects that both cn and samaccountname have valid values upon creation. On the Directory Server side, if you are configuring inetorgperson of a user object class, Identity Synchronization for Windows will expect cn and sn as mandatory attributes for a creation.
A creation attribute default updates the target directory creation attribute with a default value only when there is no value in the attribute propagated from the originating directory. (Creation attribute defaults can be based on other attribute values. See Parameterized Attribute Default Values)
Significant attributes are automatically synchronized as creation attributes but not the other way around. Creation attributes are only synchronized during user creations.
Identity Synchronization for Windows allows you to create parameterized default values for creation attributes using other creation or significant attributes.
To create a parameterized default attribute value, you embed an existing creation or significant attribute name, preceded and followed by percent symbols (%attribute_name%), in an expression string. For example, homedir=/home/%uid% or cn=%givenName%. %sn%.
When you create these attribute default values, follow these guidelines:
You can use multiple attributes in a creation expression (cn=%givenName% %sn%), but the attributes in % attribute_name% must have single values.
If A=0, B can have one default value only.
You can use the backslash symbol (\\) for quoting (for example, diskUsage=0\\%).
Do not use expressions that have cyclic substitution conditions (for example, sn=%uid% and uid= %sn%).
After you define the attributes to synchronize, map the attribute names between the Directory Server and Active Directory/Windows NT systems to synchronize them to each other. For example, you must map the Sun inetorgperson attribute to the Active Directory user attribute.
You use attribute maps for both significant and creation attributes, and you must configure attribute maps for all “mandatory creation attributes” in each directory type.
You create Synchronization User Lists (SULs) to define specific users in both the Directory Server and Windows directories to be synchronized. These definitions enable synchronization of a flat Directory Information Tree (DIT) to a hierarchical directory tree.
The following concepts are used to define a Synchronization User List:
Base DN(not applicable to Windows NT). Includes all users in that DN unless another SUL is more specific or unless excluded by a filter.
Filter. Uses attributes in the user’s entry to exclude users from synchronization or to separate users with the same base DN into multiple SULs. This filter uses LDAP filter syntax.
Creation expression (not applicable to Windows NT). Constructs the DN where new users are created, for example, cn=%cn%,ou=sales,dc=example, dc=com, where %cn% is replaced with the value of cn from the existing user entry. A creation expression must end with the base DN.
An SUL includes two definitions; where each definition identifies the group of users to be synchronized in the topology terms of the directory type.
One definition identifies which Directory Server users to synchronize (for example, ou=people, dc=example, dc=com).
The other definition identifies the Windows users to synchronize (for example, cn=users, dc=example, dc=com).
When you are preparing to create SULs, ask yourself the following questions:
Which users will be synchronized?
Which users are excluded from synchronization?
Where should new users be created?
See Appendix D, Defining and Configuring Synchronization User Lists for Identity Synchronization for Windows for detailed information about creating SULs.
The default password policy on Windows 2000 was changed on Windows 2003 to enforce strict passwords by default.
Identity Synchronization for Windows services must occasionally create entries that do not have passwords, for example, during a resync -c from Directory Server to Active Directory. Consequently, if password policies are enabled on Active Directory (on Windows 2000 or 2003) or on Directory Server, user creation errors can result.
Although you do not have to disable password policies on Active Directory or Directory Server, you need to understand the issues associated with enforcing their password policies.
The following installation information is important if you will be synchronizing passwords with Active Directory on Windows 2003 Server Standard or Enterprise Edition:
If you are installing on Windows, you can install the Active Directory Connector on the Solaris OS, Red Hat Linux, or Windows.
Active Directory Connectors will work with Active Directory on both Windows 2000 and Windows 2003 Server.
You use the same procedures to create directory sources, global catalogs, and Synchronization User Lists for Windows 2003 Server that you used for Active Directory on Windows 2000.
On Windows 2003 Server, the default password policy enforces strict passwords, which is not the default password policy on Windows 2000.
This section explains how the password policies for Active Directory on Windows 2000, Windows 2003 Server, and Sun Java System Directory Server can affect synchronization results.
If you create users on Active Directory (or Directory Server) that meet the required password policies for that topology, the users may be created and synchronized properly between the two systems. If you have password policies enabled on both directory sources, the passwords must meet the policies of both directory sources or the synchronized user creations will fail.
If you enable the password policy features on Active Directory, you should enable a similarly configured or matched password policy on Directory Server.
If you cannot create a consistent password policy in both Active Directory and Directory Server, you should enable password policies in the directory source that you consider to be the authoritative source for passwords and user creations. However, user creations will not work as expected in some cases because of certain password policy configurations.
Identity Synchronization for Windows does not synchronize password expiration.
This section discusses the following:
If you create users in Active Directory with passwords that violate the Directory Server password policy, those users will be created and synchronized in Directory Server, but the entries will be created without a password. The password will not be set until the new user logs in to Directory Server, which triggers on-demand password synchronization. At this time the login will fail because the password violates the Directory Server password policy.
To recover from this situation, do one of the following:
Force users to change their password the next time they log in to Active Directory.
Change the user password in Active Directory, making sure that the new password meets Directory Server password policy requirements.
If you create users in Active Directory that do not match the Active Directory password policy, those users will be created in Directory Server.
Active Directory actually creates users “temporarily” and then deletes the entries if the password does not meet the password policy requirements. Consequently, the Active Directory Connector sees this temporary ADD and creates users in Directory Server. The users will not have a password in Directory Server, so no one will be able to log in as those users. In addition, these entries will not be linked to a valid entry in Active Directory. If deletions are synchronized from Active Directory to Directory Server, the temporarily created users will be deleted automatically.
Users are created without a password in Directory Server. Directory Server does not enforce the password policy for user creations unless the entries contain a password.
The preferred method from recovering this situation is to synchronize deletions from Active Directory to Directory Server. Alternatively, you can remove the users from Directory Server and then add them to Active Directory with a password that follows Active Directory password policies. This method ensures that the users are created in Directory Server and are properly linked. Directory Server users will have their password invalidated when they log in to Active Directory for the first time and change it.
If you do not delete the user from Directory Server, and then try to add the Active Directory user again with a new password, the ADD to Directory Server will fail because the user already exists in Directory Server. The entries will not be linked, and you will have to run the idsync resync command to link the two separate accounts.
If you run the idsync resync command, you must reset the passwords for the accounts in Active Directory that were linked to entries in Directory Server. Resetting the passwords invalidates those passwords in Directory Server, which then forces on-demand synchronization to update the Directory Server passwords the next time users authenticate to Directory Server with their new Active Directory password.
In certain circumstances, such as resynchronization, Identity Synchronization for Windows must create accounts without passwords.
When Identity Synchronization for Windows creates entries in Directory Server without a password, it sets the userpassword attribute to {PSWSYNC}*INVALID*PASSWORD*. The user will not be able to log in to Directory Server until you reset the password. One exception is when you run resync with the -i NEW_USERS or NEW_LINKED_USERS option. In this case, resync will invalidate the new user’s password, triggering on-demand password synchronization the next time the user logs in.
When Identity Synchronization for Windows creates entries in Active Directory without a password, it sets the user’s password to a randomly chosen, strong password that meets Active Directory password policies. In this case, a warning message is logged, and the user will not be able to log in to Active Directory until you reset the password.
The following tables show some scenarios that you might encounter as you work with Identity Synchronization for Windows.
This section describes how password policies affect synchronization and resynchronization.
These tables do not attempt to describe all possible configuration scenarios because system configurations differ. Use this information as a guideline to help ensure that passwords will remain synchronized.
Table 2–3 How Password Policies Affect Synchronization Behavior
Scenario |
Results |
||||
---|---|---|---|---|---|
User Originally Created In |
User Meets Password Policy In |
User Created In |
|||
Directory Server |
Active Directory |
Directory Server |
Active Directory |
Comments |
|
Active Directory |
Yes |
Yes |
Yes |
Yes | |
Yes |
No |
Yes (see Comments) |
No |
User will be created in Directory Server. However, if deletions are synchronized from Active Directory to Directory Server, this user will be deleted immediately. See Active Directory Password Policies information. |
|
No |
Yes |
Yes |
Yes |
See Active Directory Password Policies information. |
|
No |
No |
Yes (see Comments) |
No |
Users will be created in Directory Server. However, if deletions are synchronized from Active Directory to Directory Server, this user will be deleted immediately. See Active Directory Password Policies information. |
|
Directory Server |
Yes |
Yes |
Yes |
Yes | |
Yes |
No |
Yes |
No | ||
No |
Yes |
No |
No | ||
No |
No |
No |
No |
Table 2–4 How Password Policies Affect Resynchronization Behavior
Scenario |
Result |
||
---|---|---|---|
Resync Command |
User Meets Password Policy In |
||
Directory Server |
Active Directory |
||
resync -c -o Sun |
N/A |
Yes |
User will be created in Active Directory but will not be able to log in. |
N/A |
No |
User will be created in Active Directory but will not be able to log in. |
|
resync -c -i NEW_USERS | NEW_LINKED_USERS |
Yes |
N/A |
User will be created in Directory Server, and the user's passwords will be set when the user first logs in. |
No |
N/A |
User will be created in Directory Server but cannot log in because the password violates the Directory Server password policy. |
|
resync -c |
Yes |
N/A |
User will be created in Directory Server but cannot log in until a new password value is set in Active Directory or Directory Server. |
No |
N/A |
User will be created in Directory Server but cannot log in until a new password value is set in Active Directory or Directory Server. |
This section states example password policies for Active Directory and Directory Server.
User must change password after reset
User may change password
Keep 20 passwords in history
Password expires in 30 days
Send warning 5 days before password expires
Check password syntax: Password minimum length is 7 characters
Enforce Password History: 20 days
Maximum Password Age: 30 days
Minimum Password Age: 0 days
Minimum Password Length: 7 characters
Passwords must meet complexity requirements: Enabled
Check the central logger audit.log file on the Core system for the following error message:
Unable to update password on DS due to password policy during on-demand synchronization: |
WARNING 125 CNN100 hostname "DS Plugin (SUBC100): unable to update password of entry ’cn=John Doe,ou=people,o=sun’, reason: possible conflict with local password policy" |
For more information about password policies for Windows 2003, see http://technet.microsoft.com/en-us/library/cc782657(WS.10).aspx
For more information about password policies for Sun Java System Directory Server , see Chapter 7, Directory Server Password Policy, in Sun Directory Server Enterprise Edition 7.0 Administration Guide.
If you are planning to propagate password changes from Directory Server to Windows Active Directory, you must configure each Active Directory to use SSL and install the high-encryption pack.
The Identity Synchronization for Windows Active Directory Connector installer can automatically setup SSL in the Active Directory Connector if you enable LDAP over SSL in Active Directory. You can automatically obtain a certificate from a Microsoft Certificate Services Enterprise Root certificate authority as described in
http://support.microsoft.com/default.aspx?scid=kb;en-us;q247078
However, LDAP over SSL can more easily be configured, as described in the technical note at http://support.microsoft.com/default.aspx?scid=kb;en-us;321051
In this case, if you decided to require trusted certificates for SSL communication, you must manually install the certificate in the Connector’s certificate database as described in Enabling SSL in the Active Directory Connector.
This section provides installation and configuration summaries and details the choices you make when deploying Identity Synchronization for Windows. Read all of the information in this section, and complete the installation checklists before you begin the installation process.
You must provide the following information when you install Core:
Configuration directory host and port. Specify the configuration directory host and port for the Directory Server instance on which Identity Synchronization for Windows configuration information will be stored.
You can specify an SSL port as the configuration directory port. If you do, you must identify the port as an SSL port during the installation process.
Root suffix. Specify the root suffix for the configuration directory. All configuration information is stored under this suffix.
Administrator’s name and password. Specify credentials for accessing the configuration Directory Server.
Configuration password. Specify a secure password to protect sensitive configuration information.
File system directory. Specify the location in which to install Identity Synchronization for Windows. You must install Core in the same directory as a Directory Server Administration Server.
Unused port number. Specify an available port number for the Message Queue instance.
Administration Server. Specify administration server administrator's user name and password if it already exists on Directory Server.
You must provide the following information when you configure Core:
Sun Java System Directory schema. Specify the Directory Server data that you want to load from the configuration directory.
User object class (for Directory Server only). Specify the user object class that will be used to determine user types. Identity Synchronization for Windows derives a list of attributes (including password attributes) based on this object class. This list is populated from the schema.
Synchronized attributes. Specify user entry attributes to be synchronized between the Directory Server and Windows directory sources.
Modifications, creations, and deletions flow. Specify how you want modifications, creations, and deletions to be propagated between Directory Server and Windows directory sources.
From Active directory/Windows NT to Directory Server
Bidirectionally
Specify whether to synchronize object activations and inactivations if they are propagated between Directory Server and Windows directory sources, and specify a method for synchronizing these objects.
Global catalogs. Specify global catalogs (repositories for Active Directory topological and schema information).
Active Directory schema controller. Specify the fully qualified domain name (FQDN) of the Active Directory schema source to be retrieved from the Windows global catalog.
Configuration Directory. Specify the Directory Server that stores the Identity Synchronization for Windows configuration.
Active Directory source. Specify the sources used to synchronize Active Directory domains.
Windows NT Primary Domain Controller. Specify the Windows NT domains to be synchronized and the name of the Primary Domain Controller for each domain.
Synchronization User Lists. Use LDAP DIT and filter information to specify the users to be synchronized on Directory Server, Active Directory, and Windows NT.
Sun Java System Directory Servers. Specify Directory Server instances that store users to be synchronized.
You must provide the following information when you install the connectors and the Directory Server Plug-in:
Configuration directory host and port. Specify the configuration directory host and port for the Directory Server instance on which Identity Synchronization for Windows configuration information will be stored.
Root suffix. Specify the root suffix for the configuration directory. Use the root suffix specified during Core installation.
Administrator’s name and password. Specify credentials for accessing the configuration Directory Server.
Configuration password. Specify a secure password to protect sensitive configuration information.
File system directory. Specify the location in which to install Identity Synchronization for Windows. All components installed on the same machine must have the same installation path.
Directory sources: Specify the directory source for which you want to install the connector or plug-in.
When you are installing Directory Server and Windows NT Connectors, you must specify an unused port.
When you are installing the Directory Server Connector and Plug-in, you must specify the host, port, and credentials for the Directory Server that corresponds to that Connector and Plugin.
Identity Synchronization for Windows enables you to perform a variety of tasks from the command line using the idsync script with the following subcommands:
certinfo — Displays certificate information based on your configuration and SSL settings.
changepw — Changes the Identity Synchronization for Windows configuration password.
prepds — Prepares a Sun Java System Directory Server source for use by Identity Synchronization for Windows.
printstat — Prints the status of installed connectors, the system manager, and Message Queue.
You can also use the printstat command to display a list of the remaining installation and configuration steps you have to perform to complete the installation process.
resetconn — Resets connector states in the configuration directory to uninstalled only in cases of hardware or uninstaller failure.
resync — Resynchronizes and links existing users, and pre-populates directories as part of the installation process.
dspluginconfig — Configures or unconfigures the Directory Server Plug-in.
groupsync — Enables or disables group synchronization.
accountlockout — Enables or disables account lockout feature.
stopsync — Stops synchronization.
See Appendix A, Using the Identity Synchronization for Windows Command Line Utilities for detailed information about these utilities.
Use these checklists to prepare for the installation process. Print the checklists and record the appropriate information before installing Identity Synchronization for Windows.
Table 2–5 Core Installation Checklist
Required Information |
Entry |
---|---|
Configuration directory host and port | |
Root suffix for the configuration directory (such as dc=example,dc=com) | |
File system directory in which to install Identity Synchronization for Windows | |
Configuration directory server administrator’s name and password | |
Secure configuration password to protect sensitive configuration information | |
Port number for the Message Queue instance | |
User name and password for the Administration Server |
Table 2–6 Core Configuration Checklist
Required Information |
Entry |
---|---|
Directory Server schema server | |
Directory Server user structural and auxiliary object classes | |
Synchronized attributes | |
Flow for user entry creations | |
Flow for user entry modifications | |
Flow for user entry activations and inactivations | |
Flow for user entry deletions | |
Sun Java System Directory Server directory sources | |
Active Directory | |
Synchronization User Lists | |
Windows source filter creation expression | |
Sun Java System source filter creation expression | |
User name and password for the Administration Server |
Connector and Directory Server Plug-in Installation Checklist
Required Information |
Entry |
---|---|
Configuration directory host and port | |
Root suffix for the configuration directory | |
File system directory in which to install the connector | |
Configuration Directory Server administrator’s name and password | |
Secure configuration password to protect sensitive configuration information | |
Directory sources | |
Unused port for Directory Server and Windows NT | |
Host, port, and credentials for the Directory Server corresponding to the Connector and Plug-in |
Linking Users Checklist
Required Information |
Entry |
---|---|
Synchronization User Lists to be linked. | |
Attributes used to match equivalent users | |
Resynchronization Checklist