Best Practices for Password Synchronization

• Install Password Synchronization on appropriate domain controllers  To ensure consistent synchronization of domain passwords with UNIX passwords, Password Synchronization must be installed on the primary domain controller and, in the case of a Windows 2000 domain, all domain controllers in a domain.
  
  
  • If you add a domain controller to a domain, you should install Password Synchronization on the new domain controller as soon as possible and configure it to match the other domain controllers.
    
    
  • If you need to remove Password Synchronization from any domain controller, you should demote the server to a member server before uninstalling Password Synchronization.
    
    
• Ensure consistent password policies   If you are providing only for one-way password synchronization, make sure that the password policy on the computer from which passwords will be synchronized is at least as restrictive in all areas as the policy on the computer to which passwords are synchronized. For example, if you configure Windows-to-UNIX synchronization, the Windows password policy must be at least as restrictive as the policy of the UNIX computers with which it synchronizes passwords. If you are supporting two-way synchronization, the password policies must be equally restrictive on both systems. Inconsistent password policies can result in synchronization failure when a user changes a password on the less restrictive system; or the password might be changed on the more restrictive system, even if it does not conform to the system's policies.
  
  Make sure that Windows users are aware of any special password restrictions on the UNIX systems with which their passwords will be synchronized. For example, some versions of UNIX support a maximum password length of eight characters. For maximum compatibility with the default Windows password policy and these UNIX limitations, passwords should be seven or eight characters long unless you are sure that all UNIX systems can support longer passwords.
  
  
• Configure Password Synchronization to provide the maximum protection for your users' passwords
  
  Follow these recommendations to maintain optimal security:
  
  
  • Explicitly list the users whose passwords are to be synchronized  To provide maximum control over which users can synchronize passwords, do not use the ALL keyword with the SYNC_USERS list in sso.conf on the UNIX host. Instead, you should explicitly list each user for whom password synchronization is allowed or blocked. On the Windows-based computer running Password Synchronization, create the PasswordPropAllow group and add the accounts of users whose passwords you want to synchronize. For more information, see Controlling password synchronization for user accounts.
    
    
  • Do not synchronize passwords for disabled UNIX accounts  On some versions of UNIX, changing the password of a disabled user account activates that account. Consequently, if a user has a disabled account on a UNIX computer that is configured to synchronize passwords with a Windows-based computer, the user or an administrator can activate the UNIX account by changing the user's Windows password. To prevent this, use the PasswordPropDeny group to block synchronization for disabled UNIX accounts.
    
    Also, when an administrator disables a UNIX account, the administrator should use the SYNC_USERS entry in sso.conf to block password synchronization for the account.
    
    
  • Avoid synchronizing administrator passwords  Do not synchronize passwords for members of the Windows Administrators groups or the passwords of UNIX superuser or root accounts.
    
    
  • Perform the Windows Server 2003 Service Pack 1 (SP1) compatibility check  when you enable Windows to NIS (Active Directory) password synchronization in the Password Synchronization Properties dialog box, Configuration tab. To protect the security of user account passwords in your enterprise, it is strongly recommended that you allow Password Synchronization to identify all domain controllers in the forest that are not running Windows Server 2003 SP1 or later releases.
    
    Password Synchronization prompts you to allow the compatibility check when you select Enable in the Windows to NIS (Active Directory) password synchronization area. With Windows Server 2003 SP1, or a later release installed on all the domain controllers in a forest, the risk of exposing user password hashes to unauthorized viewers is greatly reduced. When Windows Server 2003 SP1 is not the minimum functional level of all the domain controllers in a forest, it is possible for any authenticated user on the domain to view the password hash for any UNIX user whose account has been migrated to Active Directory Domain Services (AD DS).
    
    In the event an unauthorized user breaks the password hash for a UNIX-based user account in AD DS, the Windows-based password for the account is no longer secure.
    
    

When Password Synchronization is installed, members of the local Administrators group and the Domain Administrators group are added to the PasswordPropDeny group, which prevents their passwords from being synchronized. If you add a user to either the Administrators or Domain Administrators group, be sure to add the user to the PasswordPropDeny group as well.

Modify the SYNC_USERS statement in the sso.conf file on all UNIX-based systems to prevent the passwords of superusers from being synchronized.

• Do not use the default port number and encryption key  Preserving the default port number and encryption key makes it possible for an attacker to set up a spoofing UNIX host to capture passwords. You should protect the port number and encryption keys used to synchronize passwords as carefully as the passwords themselves.
  
  
• Secure the sso.conf file  The sso.conf file on each UNIX host contains important configuration information that could be used to compromise security. It is recommended that you set the mode bit mask of the file to 600.
  
  
• Ensure that the directory identified by TEMP_FILE_PATH is properly protected  The temporary files created on UNIX hosts by Password Synchronization contain information that could be used by an attacker to compromise system security. For this reason, you should ensure that any directory referenced by TEMP_FILE_PATH in sso.conf has read access only for the root account and cannot be accessed by any other users.
  
  
• Ensure log files are appropriately protected  On the UNIX host, Password Synchronization uses the syslogd daemon to log messages that result from synchronization operations. The resulting logs contain such information as the names of users whose passwords are being synchronized and with which computers, propagation errors, and so on. These log files should be protected to ensure that only administrators can view them.
  
  
• Restart the Password Synchronization daemon after changing its configuration  When you make changes to the Password Synchronization daemon configuration file (sso.conf), you must stop and restart the daemon for configuration changes to take effect.
  
  
• Configure systems to handle user name case sensitivity correctly  Unless you rigorously enforce a policy to ensure that Windows and UNIX user names match in both spelling and case, verify that the CASE_IGNORE_NAME option in the sso.conf file is set to 1 (the default). UNIX user names are case sensitive; therefore, passwords might not synchronize properly if the user names do not match exactly, because the Password Synchronization daemon is unable to associate the Windows user name with the corresponding UNIX user name.
  
  
• Make sure that password file type and name are consistent  When you configure the Password Synchronization daemon, verify that the password file type (specified by USE_SHADOW) and path name (set by FILE_PATH) are appropriate for each other. For example, on most systems, if USE_SHADOW is set to 0 (to indicate that the passwd file is used for synchronization), then the FILE_PATH option should be set to /etc/passwd. However, if USE_SHADOW is set to 1 (to indicate that the shadow file is used instead), then the FILE_PATH option should be set to /etc/shadow. (On IBM AIX systems, the path and name of the shadow file is /etc/security/passwd.)