The following resource provides further security best practice information about how to harden servers running the Active Directory Domain Controller role service:
Active Directory Domain Services.
AD DS: Fine-Grained Password Policies.
Appendix D: Active Directory Extended Rights.
Best Practices for Delegating Active Directory.
BitLocker Drive Encryption.
BitLocker Drive Encryption Configuration Guide.
BitLocker Drive Encryption Step-by-Step Guide.
IT Showcase: Optimizing Client Security by Using Windows Vista.
Managing Active Directory From the Command Line.
RODC Administration.
"RODC filtered attribute set" on the RODC Features page.
Server Core.
Set computer-specific synchronization properties.
Identity Management for UNIX Role Service
With the Identity Management for UNIX role service, you can authenticate credentials in Active Directory using the Network Information Services (NIS) protocol, and you can synchronize account passwords stored in Active Directory with account passwords stored in NIS servers running UNIX. The Identity Management for UNIX role service comprises the following sub-element role services:
Server for Network Information Services
Password Synchronization
Each of these sub-element role services are discussed in subsequent sections. For more information about the Identity Management for UNIX role service, see the "Overview of Identity Management for UNIX" in the Help and Support for Windows Server 2008.
Server for Network Information Services
The Server for NIS sub-element integrates Microsoft Windows® and NIS networks by providing a Windows–based AD DS domain controller with the ability to act as a master NIS server for one or more NIS domains.
Server for NIS stores both standard and nonstandard NIS map data in AD DS, and creates a single name space for the Windows and NIS domains that a Windows administrator can manage using a single set of tools. The administrator can easily create, modify, and delete user accounts for Windows and NIS-enabled UNIX domains at the same time. A user who has accounts in both Windows and UNIX environments can be managed by AD DS with all of the attributes necessary for the respective domain and name space.
Server for NIS is typically used in conjunction with Server for Network File System (NFS). NFS provides shared network file services for NFS clients, which are typically found on computers running UNIX. For more information about the Network Information Services role service, see the "Server for NIS" section in the Help and Support for Windows Server 2008.
Attack Surface
The Server for Network Information Services (NIS) role service is susceptible to the same security attacks as any NIS server. To identify the attack surface for this role service, you need to identify the following:
Installed files. The files that are installed as part of the Server for NIS role service.
Running services. The services that run as part of the Server for NIS role service.
Note You can use the RootkitRevealer and Sigcheck utilities that are part of Windows Sysinternals to verify the integrity of the installed files and the files that the services run.
Firewall rules. The Windows Firewall rules that the Server for NIS role service uses.
Role dependencies. These are dependencies for the Server for NIS role service.
The details of the attack surface for the Server for NIS role service are included in the Windows Server 2008 Attack Surface Reference workbook that accompanies this Solution Accelerator. To view the attack surface for this server role, on the AD DS tab of the workbook, view the sections that correspond to each of the items in the previous list.
Security Measures
This section describes the security measures that you can incorporate into your Server for NIS role service configuration to protect the server against malicious attacks. The recommendations that follow assume that you have only selected the Server for Network Information Services role service option on the Select Role Services page of the Add Roles Wizard. Recommendations for other role services are not included.
The following table summarizes the recommended security configuration tasks to harden servers that perform the Server for NIS role service. If you need help to complete any of the checklist items, see the following sections in this chapter for additional details and recommendations.
Table 3.3 Configuration Checklist
|
Configuration tasks
|
|
Configure the computer to run Server for NIS in master mode.
|
|
Require users to change their Windows passwords.
|
Note The Server for Network Information Services role service is not available on Server Core installations of Windows Server 2008.
Configure the Computer to Run Server for NIS in Master Mode
To operate Network Information Services (NIS), a computer can run these services in master mode or subordinate mode. The primary difference between the two modes is that both subordinate and master servers can read map data, while only the master server can update maps. In addition, the master NIS server provides periodic updates of the maps to subordinate servers.
Configure one of the computers running Server for NIS to be the master NIS server. This ensures that the Windows-based master NIS server will receive updates from the other NIS servers running in subordinate mode. Because the data is stored in Active Directory, the security for the data is stronger than is typically available by storing it in a file on UNIX.
For more information about master mode, subordinate mode, and the interaction between computers running these modes, see "Master and subordinate server modes" in the Help and Support for Windows Server 2008.
Require Users to Change Their Windows Passwords
Typically, users running UNIX or LINUX operating systems change their NIS passwords by running the yppasswd command. This command is used to update the user's password in NIS. The yppasswd command sends the old password to the NIS server in plaintext. For this reason, this command might expose the user's Windows password.
Instead of using this command, users should change their NIS password by changing their Windows passwords. The server running Network Information Services will then synchronize the password change with the subordinate NIS servers.
Relevant Group Policy Settings
There are no Group Policy settings available for the Server for NIS role service.
More Information
For more security best practice information about how to harden server computers running the Server for NIS role service, see "Server for NIS" in the Help and Support for Windows Server 2008.
Password Synchronization
The Password Synchronization role service helps you integrate Windows and UNIX networks by simplifying the process of maintaining secure passwords in both environments. This reduces the effort required to maintain separate passwords for Windows and UNIX accounts and change the password in both systems. With the Password Synchronization role service, whenever users change their passwords on a Windows-based computer in a domain, the passwords are automatically changed on every UNIX host on which the users have an account. You also can configure the Password Synchronization role service to change Windows-based user passwords automatically whenever users change their UNIX passwords.
For more information about the Password Synchronization role service, see "Password Synchronization" in the Help and Support for Windows Server 2008.
Attack Surface
The Password Synchronization role service is susceptible to the same security attacks as any AD DS domain controller. To identify the attack surface for this role service, you need to identify the following:
Installed files. The files that are installed as part of the Password Synchronization role service.
Running services. The services that run as part of the Password Synchronization role service.
Note You can use the RootkitRevealer and Sigcheck utilities that are part of Windows Sysinternals to verify the integrity of the installed files and the files that the services run.
Firewall rules. The Windows Firewall rules that the Password Synchronization role service uses.
Role dependencies. The dependencies for the Password Synchronization role service.
The details of the attack surface for the Password Synchronization role service are included in the Windows Server 2008 Attack Surface Reference workbook that accompanies this Solution Accelerator. To view the attack surface for this server role, on the AD DS tab of the workbook, view the sections that correspond to each of the items in the previous list.
Security Measures
This section describes the security measures that you can incorporate into your Password Synchronization role service configuration to protect the server against malicious attacks. The recommendations that follow assume that you have only selected the Password Synchronization role service option on the Select Role Services page of the Add Roles Wizard. Recommendations for other role services are not included.
Configuration Checklist
The following table summarizes the recommended security configuration tasks for hardening servers that perform the Password Synchronization role service. If you need help to complete any of the checklist items, see the following sections in this chapter for additional details and recommendations.
Table 3.4 Configuration Checklist
|
Configuration tasks
|
|
Ensure the Windows and UNIX password policies are consistent.
|
|
Specify a computer-specific password encryption key.
|
|
Explicitly list users allowed or blocked from password synchronization.
|
|
Block password synchronization of disabled UNIX user accounts.
|
|
Avoid synchronizing passwords for user accounts with elevated privileges.
|
|
Do not use the default port number and encryption key.
|
|
Secure the sso.conf file.
|
|
Ensure that the directory identified by TEMP_FILE_PATH on the UNIX host is properly protected.
|
|
Ensure that log files are appropriately protected on the UNIX host.
|
Note The Password Synchronization role service is not available on Server Core installations of Windows Server 2008.
Ensure the Windows and UNIX Password Policies Are Consistent
If you are providing only one-way password synchronization, ensure that the password policy on the computer from which passwords will be synchronized is at least as restrictive as the policy on the computer to which it will synchronize passwords. 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 will synchronize passwords.
If you are supporting two-way synchronization, the password policies must be equally restrictive on both systems. Failure to ensure that password policies are consistent 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 though it does not conform to the system's policies.
Also ensure that Windows users are aware of any special password restrictions on UNIX systems with which they will synchronize their passwords. 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, limit passwords to seven or eight characters in length unless you are sure that all of the UNIX systems in your environment can support longer passwords.
Specify a Computer-Specific Password Encryption Key
A Windows-based computer can send and receive updated passwords from a UNIX-based computer as encrypted text only. The Password Synchronization single sign-on daemon (SSOD) receives the encrypted password and decrypts it before requesting the password change on the UNIX host.
Similarly, if you configure Password Synchronization to support UNIX-to-Windows synchronization, the pluggable authentication module (PAM) encrypts the password before sending it to Password Synchronization on the Windows-based computer, which then decrypts the password before requesting the password change on the Windows-based computer.
For added security, you can specify an encryption key for use only between a specific Windows-based computer and a UNIX host. This helps ensure that only specific computers can decrypt passwords from each other. For more information, see Set computer-specific synchronization properties.
Explicitly List Users Allowed or Blocked From Password Synchronization
To provide maximum control over which users can synchronize passwords, do not use the ALL keyword with the SYNC_USERS list in the sso.conf file on the UNIX host. Instead, explicitly list each user who you want to allow or block from password synchronization.
On the Windows-based computer running Password Synchronization, create the PasswordPropAllow group, and then add the accounts of users whose passwords you want to synchronize to this group. For more information about this topic, see Controlling password synchronization for user accounts.
Block Password Synchronization of Disabled UNIX Accounts
In 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 you disable a UNIX account, ensure that you use the SYNC_USERS entry in the sso.conf file to block password synchronization for the account.
Avoid Synchronizing Passwords for User Accounts with Elevated Privileges
Do not synchronize passwords for members of Windows groups with elevated privileges or the owners of the UNIX superuser or root accounts, because these accounts do not have elevated permissions on the other system. For example, members of the Domain Admins group have no elevated permissions on computers running UNIX by default.
Do Not Use the Default Port Number and Encryption Key
If you use the default port number and encryption key, you make it possible for an attacker to set up an impostor UNIX host to capture passwords. To help prevent imposter UNIX hosts from capturing passwords, change the value of the port and the default password encryption key used by password synchronization.
Note Protect the port number and encryption keys that you use to synchronize passwords as carefully as the passwords themselves.
For more information about these topics, see the following sections in the Help and Support for Windows Server 2008:
"Setting the default port."
"Setting the password encryption key."
Secure the sso.conf File
The sso.conf file on each UNIX host contains important configuration information that an attacker could use to compromise security. Microsoft recommends setting the mode bit mask of this file to 600 to better secure it.
Ensure That the Directory Identified by TEMP_FILE_PATH on the UNIX Host is Properly Protected
The temporary files created on UNIX hosts by Password Synchronization contain information that an attacker could use to compromise system security. For this reason, ensure that any directory referenced by TEMP_FILE_PATH in the sso.conf file has read access only for the root account, and that no other users access this account.
Ensure That 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 synchronized with which computers, propagation errors, and so on. Ensure that only the root account can read the log files and that no other users can access the files by granting only the root account access to the directory where the logs files are stored. Check the configuration of the syslogd daemon to determine the directory where the log files are stored.
|
