Deployment Example: A Two-Machine Configuration

This section describes a deployment scenario in which Identity Synchronization for Windows is used to synchronize user object creation and bidirectional password modification operations between Sun and Windows directories.

The deployment scenario consists of two systems:

• A system running a Sun Java System Directory Server (host name: corp.example.com)

• A system running Active Directory on a Windows 2000 server (host name: sales.example.com )

Though NT is not used in this scenario, it is important to note that Identity Synchronization for Windows also supports synchronization with NT domains.

This example illustrates the synchronization requirements (node structures with associated attribute values) used for this deployment scenario.

Figure 3–9 Synchronization Requirements

There are two goals for this scenario:

• To synchronize user passwords bidirectionally between the user subtrees (ou=people in Directory Server and cn=users in Active Directory), which means that whenever a user password changes in either directory, the password change is synchronized to the associated user in the other directory.

  For example, if you change the password for uid=JSmith in the ou=people container on the Directory Server, then the new password should automatically be synchronized to cn=Joe Smith in the cn=users container on the Active Directory server.

• To synchronize user object creation operations from the Directory Server people subtree to the Active Directory user subtree only.

  For example, if you create a new user (uid=WThompson in the ou=People container) with a specified set of attributes, then Identity Synchronization for Windows will create a new account for WThompson (cn=William Thompson in the cn=Users container) with the same set of attributes on Active Directory.

Identity Synchronization for Windows supports multiple synchronization sources of the same type (for example, you can have more than one Directory Server in a deployment or multiple Active Directory domains).

Creation, modification, and deletion synchronization settings are global for the entire set of directories, and cannot be specified for individual directory sources. If you synchronize user object creations from Directory Server to Windows directories, then user object creations will propagate from all Directory Servers to all Active Directory domains and Windows NT domains configured in the installation.

Physical Deployment

This section illustrates how all the product’s components are physically deployed on a single Solaris box, while the Active Directory domain resides in a separate Active Directory domain controller where no components have been installed.

Figure 3–10 Directory Server and Active Directory Scenario

Component Distribution

Host corp.example.com is a Directory Server installed in a Solaris operating system. The root suffix for the Directory Server being synchronized is dc=corp,dc=example,dc=com.

This machine contains:

• Identity Synchronization for Windows Core components

• Identity Synchronization for Windows Directory Server Connector

• Identity Synchronization for Windows Directory Server Plug-in

• Identity Synchronization for Windows configuration directory (located in a different Directory Server instance than the one being synchronized)

  Host sales.example.com is the Active Directory domain being synchronized.