Example Bank Deployment Information

This section describes the architecture and technical requirements of Example Bank, the company in this case study. It also lists the Identity Synchronization for Windows features that are used in this case study.

Example Bank’s Existing Architecture

Example Bank’s infrastructure includes a Windows NT domain (EXBANK), an Active Directory domain (eb.com) with two domain controllers , and a two-way MMR Sun Java System Directory Server (dc=eb,dc=com) deployment. Example Bank has two main sites: one located in New York City and one in Los Angeles.

The following figure describes Example Bank’s deployment of its directory resources.

Figure 2-1 Example Bank Architecture

Directory Server Information

Sun Java System Directory Server is the corporate directory server that is used to control access to all web-based applications. Pluggable Authentication Module (PAM) for LDAP authenticates and manages passwords on the Solaris Operating System (Solaris OS) against Directory Server passwords. The two preferred Directory Servers manage a single root suffix, dc=eb,dc=com, and all users are stored in the ou=people,dc=eb,dc=com container with uid as the naming attribute. The directory servers, installed on Solaris systems, are running on separate machines: master-east.eb.com and master-west.eb.com.

Windows NT Information

The single Windows NT domain is called EXBANK. The Primary Domain Controller (PDC) runs on a pdc-east.eb.com machine in New York City. A backup domain controller (bdc-west.eb.com) runs on a machine located in Los Angles. All Windows NT user accounts have a Directory Server account with the exception of the built-in Windows NT accounts. The Windows NT USER_NAME attribute is the same as the Directory Server uid attribute.

Active Directory Information

The Active Directory deployment has a single domain, eb.com, with two domain controllers:

ad-east.eb.com (in New York City)
ad-west.eb.com (in Los Angeles)

In this deployment, ad-west.eb.com is the PDC Flexible Single-Master Operation (FSMO) role owner.

Users are stored in two separate organizations corresponding to the two sites:

ou=east,dc=example,dc=com
ou=west,dc=example,dc=com

Example Bank is in the process of migrating users from Windows NT to Active Directory. Each employee has a Windows NT or Active Directory account. The migration of the users is based (in phases) on the employees’ last names. Every week Example Bank moves users whose last name begins with the next letter of the alphabet. Currently, the company has migrated employees whose last names begin with letters A through F.

For users who have Directory Server accounts, the Active Directory samaccountname attribute stores the uid. When a user account is migrated from Windows NT, the user keeps the same login. That is, the Active Directory samaccountname attribute of the new user is the same as the Windows NT USER_NAME attribute.

Example Bank’s Technical Requirements

The following table describes Example Bank’s technical requirements.

Table 2-1 Technical Requirements for Example Bank

Requirement	Comments
Users’ Windows passwords should be synchronized with their Directory Server passwords.	Identity Synchronization for Windows can synchronize a user’s existing Directory Server password with the user's Active Directory password.
Users must be able to continue to change passwords using native mechanisms in Windows NT or Active Directory. That is, use the `CTRL+ALT+DEL` key sequence on Windows systems and the `passwd` command on Solaris systems.	Identity Synchronization for Windows supports capturing native password changes in Directory Server, Active Directory, and Windows NT. Users can continue to change their passwords. They are not required to change passwords at a central location (for example, a web form). For native Solaris OS password changes to be propagated to Active Directory, Solaris must be configured to use PAM for LDAP. This feature is discussed in detail in Appendix A, Pluggable Authentication Modules. Note: You can set passwords in Directory Server by passing in a pre-hashed password value. However, Identity Synchronization for Windows cannot synchronize passwords from Directory Server to Windows if the password is pre-hashed. Thus, do not use a pre-hashed password value because it circumvents password policy and password history.
Contractors might have accounts on Active Directory, Windows NT, or Directory Server but their accounts should not be synchronized. Contractors can be identified using their login name, which starts with `c-`. The `uid`, `samaccountname`, and `USER_NAME` attributes start with `c-` for contractors only.	The Synchronization User List (SUL) feature of Identity Synchronization for Windows can be used to eliminate user accounts that must not be synchronized. Part of an SUL’s configuration includes an LDAP-like filter. A contractor’s login name begins with a `c-`. To exclude contractors use filters: Active Directory SUL filter is `(!(samaccountname=c-))` Windows NT SUL filter is `(!(USER_NAME=c-))` Directory Server SULs include `(!(uid=c-*))` as a part of their filters. Directory Server SUL filters specify whether the user is using Windows NT or Active Directory.
Changes to login IDs (`USER_NAME`, `samaccountname`, and `uid`) and full names (`USER_FULL_NAME`, `cn`, and `cn`) should be synchronized when they change.	Identity Synchronization for Windows synchronizes other attributes between Windows and Directory Server. It uses a unique Globally Unique Identifier (GUID) stored in the Directory Server entry to correlate users. It can synchronize attributes, such as `uid` and `cn`, that are otherwise used as keys. Note: The SUL filter applies to all operations, and no other changes for contractors are synchronized.
When a new user is created in Active Directory (except for contractors), a corresponding user should be created in Directory Server.	Using Identity Synchronization for Windows, you can choose how creations of new users will be synchronized. Identity Synchronization for Windows can synchronize new user entries from Windows to Directory Server, from Directory Server to Windows, both ways, or not at all. The same SUL filter also excludes contractors from being created in Directory Server.
New users created in Directory Server must not have an Active Directory account created automatically.	Identity Synchronization for Windows can synchronize new user accounts from Windows to Directory Server, Directory Server to Windows, or not at all.
Entries deleted in Directory Server or Active Directory must not be deleted in the corresponding data source.	Identity Synchronization for Windows can synchronize account deletions from Active Directory to Directory Server, Directory Server to Active Directory, both ways, or not at all. Identity Synchronization for Windows does not synchronize bidirectional account deletions, that is, from Active Directory to Directory Server and from Directory Server to Active Directory. Note: Identity Synchronization for Windows does not synchronize account deletions with Windows NT.
Accounts that are made inactive (disabled) in Directory Server or Active Directory should be deactivated in the corresponding data source.	Identity Synchronization for Windows can synchronize deactivated accounts from Active Directory to Directory Server, Directory Server to Active Directory, both ways, or not at all. You can configure how Identity Synchronization for Windows detects account inactivations in Directory Server. Example Bank is not using a third-party application such as Sun Java System Access Manager to control access to its directory server, so the default account deactivation setting for interoperating with the Directory Server tools suffices. Note: Identity Synchronization for Windows does not synchronize account inactivations with Windows NT.
After a user has been migrated from Windows NT to Active Directory, changes should be synchronized with the Active Directory account but not the Windows NT account.	Identity Synchronization for Windows stores a GUID in each Directory Server entry that it synchronizes (in the `dspswuserlink` attribute), to synchronize changes made in Directory Server to Active Directory and Windows NT. If an account is moved from Windows NT to Active Directory, the `dspswuserlink` attribute in the corresponding Directory Server entry should be updated. To update the entry in Directory Server, remove the attribute and then run the `idsync resync -f <linking-file\>` command again.
Users should continue to synchronize even when one preferred Directory Server fails.	The failover feature in Identity Synchronization for Windows happens seamlessly when the preferred Directory Server fails during synchronization between Active Directory and Directory Server.
Account lockout synchronization must happen between Directory Server and Active Directory sources.	In Identity Synchronization for Windows, the accounts locked in Directory Server are also locked automatically in Active Directory. The reverse is also true.
The users under various groups, such as employee, supervisor, manager, and contractor, should be synchronized across Directory Server and Active Directory with their group memberships intact.	The static group synchronization in Identity Synchronization for Windows synchronizes the users across the directory servers with their group memberships intact.

Identity Synchronization for Windows Features in This Case Study

The following Identity Synchronization for Windows features are used in this case study:

Synchronizing with multiple Windows domains
Synchronizing in a two-way MMR environment
Synchronizing multiple object classes
Deploying over a wide area network (WAN)
Integration with PAM LDAP
Migrating users between Windows domains, (from Windows NT to Active Directory)
Excluding users from synchronization using an SUL filter
Synchronizing a hierarchical directory information tree (DIT) with a flat DIT
Creating attribute default values
Failover support across multiple preferred Directory Servers in a replicated environment
Account lockout synchronization
Static group synchronization

Skip Navigation Links
Exit Print View
	Oracle Identity Synchronization for Windows 6.0 Deployment Planning Guide