Sun Java System Identity Synchronization for Windows 6.0 Deployment Planning Guide

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.