Before installing Identity Synchronization for Windows 6.0 or before you migrate from Sun Java SystemIdentity Synchronization for Windows 1 2004Q3 SP1 to version 6.0, you should familiarize yourself with the installation and configuration process.
For information on the Identity Synchronization for Windows installation requirements, see Chapter 5, Identity Synchronization for Windows Bugs Fixed and Known Problems, in Sun Java System Directory Server Enterprise Edition 6.0 Release Notes
This chapter describes these processes and provides other information you may find helpful as you prepare to install the product. This information is organized into the following sections:
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 you must follow to successfully install and configure the product.
As you go through the installation and configuration process, the program greys-out all completed steps in the list (as you can see in Installation Overview).
The rest of this section provides an overview of the installation and configuration process, and is organized as follows:
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 5, Installing Core
After installing Core, you use the 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 6, Configuring Core Resources
Directory Server Connectors support the Sun Java System Directory Server 6.0.
Before you can install Directory Server Connectors, you must prepare a Sun Java System Directory Server source for every configured Directory Server master (both preferred and secondary masters) being synchronized.
You can perform this task from the Console or from the command line 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 available in your system. Both the Console and the installation program use the directory label to associate a connector with the directory that is synchronized.
Table 4–1 Label Naming ConventionsTable 4–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 5, 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
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.
For more information about synchronizing existing users, see Chapter 8, Synchronizing Existing Users and User Groups.
After installing the product, you must configure the product deployment, which includes:
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
Specifying synchronization settings for (optional) user entry creations and deletions between the configured directories
This section provides an overview of the following configuration element concepts:
For more information about configuration instructions, see Chapter 6, Configuring Core Resources.
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, password 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 objectclass. Object class(es) determine which attributes will be available to synchronize for both Directory Server and Active Directory.
Objectclasses are not applicable for Windows NT
Identity Synchronization for Windows supports two types of objectclasses:
Structural Objectclasses: Every entry that’s created or synchronized from the selected Directory Server must have at least one structural objectclass. Select a structural objectclass from the drop-down list. (Defaults to inetorgperson on Directory Server and User on Active Directory)
Auxiliary Objectclasses:
Directory Server allows you to select one or more objectclasses from the Available Auxiliary Object Classes list pane to augment the selected structural class, which provides additional attributes for synchronization.
Active Directory is more restrictive with the auxiliary objectclass. Attributes on all valid auxiliary objectclasses for the selected structural objectclass will be available for synchronization.
For detailed information about configuring objectclasses and attributes, see Chapter 6, Configuring Core Resources
Attributes hold descriptive information about a user entry. Every attribute has a label, one or more values, and follows a standard syntax for the type of information that can be stored as the attribute value(s).
You can define attributes from the Console. Instructions for defining attributes are provided in Chapter 6, Configuring Core Resources.
Identity Synchronization for Windows synchronizes significant and creation user attributes, as follows:
Significant Attributes: Synchronized between Sun and Windows directories whenever the attributes are modified according to specified modification synchronization settings.
Creation Attributes: Synchronized between Sun 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” in order 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 Sun side, if you are configuring inetorgperson of a user objectclass, 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:
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, then 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, 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 Sun 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 you have password policies 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 should understand the issues associated with enforcing password policies on the different systems.
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 Solaris, 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 2003 Server, Windows 2000, and Sun Java System Directory Server 6.0 can affect synchronization results.
The information is organized as follows:
If you create users on Active Directory (or Directory Server) that meet the required password policies for that system, the users may be created and synchronized properly between the two systems. If you have password policies enabled on both systems, the passwords must meet the policies of both systems 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 on both Active Directory and Directory Server, you should enable password policies on the side that you consider the authoritative source for passwords and user creations. However, there are some cases in which user creations will not work as expected because of certain password policy configurations.
The following sections provide important information about password policies:
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 into Directory Server, which triggers on-demand password synchronization. At this time the login will fail because the password violates the Directory Server password policy.
There are several ways to recover from this situation:
Force the user to change their password the next time they log on to Active Directory
Change the user password on Active Directory, and be sure the new password meets Directory Server password policy requirements
You may want to review whether the password policy set on Active Directory and on Directory Server are equivalent (or as similar as possible).
If you create users on Active Directory that do not match the Active Directory password policy, those users will be created on 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 on the Directory Server side. The users will not have a password in Directory Server, so no one will be able to log in as the user. 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, then the temporarily created users will be deleted automatically.
Users are created without a password on Directory Server. Directory Server does not enforce the password policy for user creations unless the entries contain a password.
There are several ways to recover from this situation. The preferred method is to synchronize deletions from Active Directory to Directory Server. Alternatively, you can remove the user from Directory Server and then add them to Active Directory with a valid password for the Active Directory password policies. This method ensures that the users are created on Directory Server and linked properly. Users on Directory Server will have their password invalidated when they log into Active Directory for the first time and change their passwords.
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 on Directory Server. The entries will not be linked together and you will have to run a idsync resync command to link the two separate accounts.
If you run the idsync resync command, you must be sure to reset the passwords for the accounts on Active Directory that were linked to entries on Directory Server. Resetting the passwords invalidates those passwords on Directory Server, which then forces on-demand synchronization to update the Directory Server password the next time the user authenticates to Directory Server with their new Active Directory password.
In certain circumstances, such as resynchronization, Identity Synchronization for Windows must create accounts without passwords.
Directory Server
WhenIdentity Synchronization for Windows creates entries in the Directory Server, without a password, it sets the userpassword attribute to {PSWSYNC}*INVALID*PASSWORD*. The user will not be able to log into Directory Server until you reset the password. One exception to this 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.
Active Directory
When Identity Synchronization for Windows creates entries in the Active Directory, without a password, it sets the user’s password to a randomly chosen, strong password that meets Active Directory password policy requirements. In this case, a warning message is logged and the user will not be able to log into Active Directory until you reset the password.
The following tables describe some different scenarios you might encounter as you work with Identity Synchronization for Windows:
This section describes how password policies affect synchronization and resynchronization.
Use this information as a guideline to help ensure that passwords will remain synchronized. (These tables do not attempt to describe all possible configuration scenarios because system configurations differ.)
Table 4–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 |
Users will be created in Directory Server. However, if deletes are synchronized from Active Directory to Directory Server then this user will be deleted immediately. See Active Directory Password Policies information. |
|
No |
Yes |
Yes |
Yes |
See Important Notes for more information. |
|
No |
No |
Yes (see Comments) |
No |
Users are created in Directory Server. However, if deletes are synchronized from Active Directory to Directory Server then 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 4–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 their password will be set when the user first logs in. |
No |
N/A |
User will be created in Directory Server but they cannot log in because their password violates the Directory Server password policy. See Important Notes and Creating Accounts Without Passwords more information. |
|
resync -c |
Yes |
N/A |
User will be created in Directory Server but they cannot log on until a new password value is set in Active Directory or Directory Server. |
No |
N/A |
User will be created in Directory Server but they cannot log on until a new password value is set in Active Directory or Directory Server. |
This section describes different scenarios for Active Directory and Directory Server password policy examples using the following specifications:
For Active Directory:
Enforce Password History: 20 days
Max Password Age: 30 days
Min Password Age: 0 days
Min Password Length: 7 characters
Passwords must meet complexity requirements: Enabled
For 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 min length is 7 characters
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://www.microsoft.com/resources/documentation/WindowsServ/2003/
For more information about Directory Server password policies, see Chapter 7, Directory Server Password Policy, in Sun Java System Directory Server Enterprise Edition 6.0 Administration Guide
If you are planning to propagate password changes from Directory Server to Windows Active Directory servers you must configure each Active Directory server to use SSL and install the high-encryption pack.
The Identity Synchronization for Windows Active Directory Connector installer can automatically set-up SSL in the Active Directory Connector if you enable LDAP over SSL in Active Directory by automatically obtaining 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 this MSDN tech note:
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 gives installation and configuration summaries and details the choices you make in deploying Identity Synchronization for Windows. Have this information available before you begin the installation process. This section contains:
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; and 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 you want loaded 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 the Windows environment.
Modifications, Creations, and Deletions flow : Specify how you want modifications, creations, and deletions to be propagated between the Sun and Windows systems. Your options are:
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 storing 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 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 (in cases of hardware or uninstaller failure only)
resync: Resynchronizes and links existing users, and pre-populates directories as part of the installation process
dspluginconfig: Configures or unconfigures the Directory Server plugin.
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.
These checklists are intended to aid in the installation process. Print them out and record the following information prior to installing Identity Synchronization for Windows.
Table 4–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 4–6 Core Configuration Checklist
Required Information |
Entry |
---|---|
Directory Server schema server | |
Directory Server User structural and auxiliary object class(es) | |
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 directory sources | |
Synchronization User Lists | |
Windows source filter creation expression | |
Sun Java System source filter creation expression | |
User name and password for the Administration Server | |
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 | |
A secure configuration password to protect sensitive configuration information | |
Directory sources | |
An 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