Designing an Authentication Strategy

C H A P T E R 1 4 Most organizations need to support seamless access to the network for multiple types of users, such as workers

in offices, employees who are traveling, and perhaps even business partners and customers. At the same time, organizations need to protect network resources from potential intruders. A well-designed authentication strategy can help you achieve this complex balance between providing reliable access for users and strong network security for your organization. In This Chapter Overview of the Authentication Strategy Design Process...... 658 Creating a Foundation for Authentication...... 662 Securing the Authentication Process...... 673 Extending Your Authentication Framework...... 687 Enabling Supplemental Authentication Strategies...... 695 Educating Users...... 699 Additional Resources...... 701 Related Information  For more information about the Kerberos version 5 authentication protocol, see the Distributed Services Guide of the Microsoft® Windows® Server 2003 Resource Kit (or see the Distributed Services Guide on the Web at http://www.microsoft.com/reskit).

 For more information about the Active Directory® directory service logical structure, see “Designing the Active Directory Logical Structure” in this book.

 For more information about upgrading from the Microsoft® Windows NT® version 4.0 operating system to the Microsoft® Windows® Server 2003 operating system, see “Upgrading Windows NT 4.0 Domains to Windows Server 2003 Active Directory” in this book. 146 Chapter 14 Designing an Authentication Strategy

Overview of the Authentication Strategy Design Process One of the most fundamental elements of an organization’s security strategy is verifying the identity of clients and granting them appropriate access to system resources based on their identity. By creating an authentication strategy for your organization, you can prevent attackers and malicious users from accessing and tampering with sensitive information, consuming computing power or other system resources, and impersonating users in order to send misleading or incorrect information.

Authentication technology in the Microsoft® Windows® Server 2003, Standard Edition; Windows® Server 2003, Enterprise Edition; and Windows® Server 2003, Datacenter Edition operating systems allows you to implement a variety of authentication strategies based on the complexity of your organization, the quality of a user’s credentials, the means by which users access the network, and the clients they use to gain access. In addition, Windows Server 2003 authentication technology allows you to establish a foundation for more efficient management of users, computers, and services on the network. Additional Resources 147

Note For a list of the job aids that are available to assist you in designing an authentication strategy, see “Additional Resources” later in this chapter. Process for Designing an Authentication Strategy Designing an authentication strategy involves evaluating your existing infrastructure and creating accounts, establishing a means to secure the authentication process, and establishing standards for network authentication and time synchronization. You might also need to extend your authentication model to allow authentication between forests or between other Kerberos realms, and to enable delegated authentication in order to facilitate user access to system resources. Figure 14.1 shows the process for designing an authentication strategy. Figure 14.1 Designing an Authentication Strategy 148 Chapter 14 Designing an Authentication Strategy

Authentication Background Information Windows Server 2003 authentication technology includes a number of features that provide solutions for a wide variety of business needs. Central administration of accounts Administrators can create a single account for each user that allows the user to access the appropriate network resources. Users can log on at different desktops, workstations, or notebooks in the domain by using the same user name and a password or smart card. Single sign-on environment Users are required to enter a user name and password or smart card only when first logging on to a Windows Server 2003–based computer. The Windows Server 2003 operating system automatically authenticates the user to the local computer, to the Active Directory domain, and to any other application or resource server in the forest that requires authentication prior to access. When users change passwords, the updates are made to the user accounts in Active Directory. The password changes apply automatically to all resources in the domain or forest. Computer accounts in Active Directory Computer accounts in Active Directory for all of the computers within a domain allow many of the Windows Server 2003 security features that are designed for users to be applied to computers as well. Computer accounts in Active Directory also allow you to add application servers as member servers within your trusted domains and to demand authentication from the users and other services that access these resource servers. Service accounts in Active Directory The services running on resource servers are authenticated automatically if the servers are members of a domain that trusts the user’s account domain. In Windows Server 2003, all of the domains in a forest automatically have two-way transitive trust. Windows Server 2003 also supports transitive trust relationships between forests. In this way, when organizations add application servers to their domains, only authenticated users and services can access them. Smart card support Windows Server 2003 supports optional smart card authentication. A smart card contains a processor chip that stores the user’s private key and public key certificate. The user inserts the card into a smart card reader attached to the computer. The user then types in a personal identification number (PIN) when requested, to enable access to the keys stored on the smart card. Authentication proceeds when the correct PIN enables access to the private key and the certificate on the card, allowing the Active Directory authentication service to verify the user’s identity. In this way, computers that store highly sensitive data can be secured from attack without the need to store them in locked rooms. At the same time, authorized users can access information stored on high-security computers. Additional Resources 149

Certification for Microsoft Windows Windows Server 2003 authentication interoperates with third-party applications designed according to the Application Specification for Windows 2000. The Application Specification defines the technical requirements for applications to earn the Certified for Microsoft Windows logo. Applications can carry the Certified for Microsoft Windows logo when they have passed compliance testing and have executed a logo license agreement with Microsoft. To pass compliance testing, a server application must operate within the appropriate security context, reducing the risk posed by successful attacks, and perform Kerberos-based mutual authentication for all client requests, ensuring that clients know that the servers with which they are communicating are the intended parties, and not attackers posing as the server. Auditing authentication Windows Server 2003 provides security audit information to track attempts to log on to servers and workstations. This gives organizations the ability to detect unauthorized attempts to access the system. Kerberos V5 authentication protocol When a client attempts to connect to a resource server, the Kerberos Key Distribution Center (KDC), running on a domain controller, provides the client with a ticket to verify the user’s identity to the server, and a shared secret key. The ticket allows the server to validate the user immediately and can be used multiple times. The shared secret key is passed to the server in encrypted form, allowing both computers to use the shared secret key to encrypt any network data they exchange. The Microsoft implementation of the Kerberos authentication protocol is based on industry standard specifications defined by the Internet Engineering Task Force (IETF). The Kerberos V5 authentication protocol provides the following advantages:  Efficient authentication to servers. Because authentication takes place quickly, users do not lose productive work time. Clients can obtain a ticket for a particular server one time and reuse the ticket for multiple network sessions.  Mutual authentication. By means of the shared secret key, parties at both ends of a network connection can verify each other’s identities. This is a change from NTLM, which allows only servers to verify the identities of their clients.  Delegated authentication. A service can impersonate a client when connecting to a network service, such as a database. Delegated authentication is not available in NTLM.  Interoperability. Kerberos authentication in Windows Server 2003 can interoperate with the implementation of Kerberos authentication in other operating systems. 150 Chapter 14 Designing an Authentication Strategy

Tools for Deploying Authentication The following tools are available to assist you in deploying authentication:  Active Directory Users and Computers. A Microsoft Management Console (MMC) snap-in that allows you to create user and computer accounts in the Active Directory.  Group Policy. An MMC snap-in that allows you to apply authentication Group Policy, including Kerberos, auditing, and NTLM authentication behavior.  Certificate Services. An MMC snap-in used to establish the certification authorities (CAs) and issue the certificates used in public key authentication. For more information about these tools, see the Distributed Services Guide of the Windows Server 2003 Resource Kit (or see the Distributed Services Guide on the Web at http://www.microsoft.com/reskit). Creating a Foundation for Authentication When you deploy Windows Server 2003, you can create a foundation for secure authentication of users, computers, and services in your organization by creating accounts in Active Directory for all entities that require authenticated access to resources. Because a number of factors impact the authentication strategy that you deploy, you must evaluate the structure of your existing environment before you create the foundation for your authentication strategy. For a worksheet to assist you in creating a foundation for authentication, see “Authentication Strategy Planning” (DSSAUT_1.doc) on the Microsoft® Windows® Server 2003 Deployment Kit companion CD (or see “Authentication Strategy Planning” on the Web at http://www.microsoft.com/reskit). Figure 14.2 shows the process for creating a foundation for authentication. Additional Resources 151

Figure 14.2 Creating a Foundation for Authentication 152 Chapter 14 Designing an Authentication Strategy

Evaluating Your Environment Before you establish an authentication strategy for your organization, you must become familiar with your current environment, including the structure of your organization; the users, computers, and services in your organization that require authentication; and the applications and services that are in use. Specifically, identify the following:  The number of domain controllers in your organization. Ensure that you have enough domain controllers in your environment to accommodate your users’ authentication requests. If the number of domain controllers is insufficient, a large volume of client requests can result in failed authentication attempts. If you determine that you have an insufficient number of domain controllers, deploy more domain controllers to meet the logon needs of your users.  The type of network connectivity between site locations in your organization. Domain controllers must be well connected to users to ensure reliable access for authentication. Clients that do not have access to local domain controllers might be unable to access resources if the network connection is unavailable. If the connectivity between domain controllers in remote sites is insufficient, deploy more domain controllers in those sites or improve the connectivity between the sites.  The number of CAs that are available in your organization and their locations. As with domain controllers, a sufficient number of CAs must be available to handle client requests and they must be well connected in order to provide timely responses. For information about creating a CA infrastructure, see “Designing a Public Key Infrastructure” in this book.  The number of users, groups, and computers in your organization and where computers are located. This impacts the number of domain controllers and CAs that are required to ensure consistent authentication.  The number and locations of users who access the network by means of RADIUS and RAS servers.

Note Windows Server 2003 provides for remote user authentication by means of RADIUS and RAS servers. For more information about using RADIUS servers, see “Deploying IAS” in Deploying Network Services of this kit. For more information about using RAS servers, see “Deploying Dial-Up and VPN Remote Access Servers” in Deploying Network Services. Additional Resources 153

 Whether your organization includes clients running versions of Windows earlier than the Microsoft® Windows® 2000 operating system or other non-native operating systems, or applications that require authentication protocols other than the Kerberos V5 authentication protocol or require special configuration to interoperate with the Kerberos authentication protocol. The operating systems and applications in use in your environment impact the authentication protocols that you can enable by means of authentication policy. For example, versions of Windows earlier than Windows 2000 require NTLM authentication or anonymous access. If clients in your environment are running these operating systems, you must configure the LAN Manager authentication level policy to enable those clients to access resources in your system.

Note When you enable LAN Manager authentication, you cannot take advantage of all of the security benefits that are available in Windows Server 2003. Therefore, if you do not need to support versions of Windows earlier than Windows 2000, it is best to use the Kerberos authentication protocol.

 The number and location of smart card users in your organization, if applicable, and any security-sensitive tasks or users, such as administrators, that might require smart cards in the future. The number of current and planned future smart card users in your organization impacts the number of CAs that you require. Creating User Accounts User accounts are required for authentication. Assign users the appropriate permissions to access resources by creating user accounts in Active Directory and adding the accounts to the appropriate groups. Adding accounts to security groups and applying access control settings to resources allows users to utilize their authenticated identity to access resources, and facilitates account management. It is best to grant users and groups access to only those resources that are required for them to complete their job tasks. In this way, if any user account is compromised by a malicious user, he or she has limited access to resources, and therefore can cause only minimal damage. For more information about user accounts and security groups, see “Designing a Resource Authorization Strategy” in this book.

Note Do not allow users to share accounts or passwords or to use weak passwords. Shared accounts and weak passwords compromise the security of your environment. For more information about creating password policies, see “Creating a Strong Password Policy” later in this chapter.

Creating user accounts involves creating a plan for user account management in your organization. 154 Chapter 14 Designing an Authentication Strategy

Creating a User Account Management Plan When you deploy Windows Server 2003 and establish the appropriate user accounts in Active Directory, you need to create a plan for user account management. Creating a user account management plan involves determining which individuals in your organization have the right to create new user accounts, and establishing a plan for the disabling of and resetting of user accounts. Assign the User Account Creation Right Assigning the right to create new user accounts involves carefully balancing strong security and timely response to requests to create new accounts. Because misuse of the user account creation right presents a security risk to your organization, assign this right to trusted administrators only. For many organizations, it is sufficient to limit the ability to create new user accounts to the members of the Domain Administrators group. In large organizations or in situations where administrators need to delegate tasks, you might need to assign the right to create new user accounts to another group, such as the IT staff or the Human Resources group. Whoever you designate to create user accounts, a general guideline is to assign one individual the right to create new user accounts for every 100 employees. However, you might need to adjust this number based on the expected growth of your organization. For example, if your organization regularly adds new divisions, acquires companies, or expands into other markets, you need to plan for the creation of new user accounts by assigning the right to create new user accounts to the appropriate number of individuals to meet the requirements for your anticipated growth. Establish a Plan for the Disabling of User Accounts Because unused but active user accounts are a common target for security attacks, you must establish a clear, consistent policy for disabling user accounts. You can choose one of the following solutions for disabling active unused user accounts in your organization:  Include disabling user accounts as part of the employee departure procedure. Establish a policy by which user accounts are deleted from Active Directory when employees leave your organization.  Create scripts that search for user accounts that have not been logged on to for a period of time or have not had their password changed, and delete the accounts that the script identifies. For example, you might decide to create a script that identifies accounts that have not been logged on to for six weeks, or that have not had their passwords changed for twice the password lifetime prescribed by domain Group Policy, and delete those accounts. Additional Resources 155

Establish a Plan for Resetting User Accounts When a user forgets his or her password, the account must be reset before it can be used. An effective way to enable the resetting of user accounts in your organization is to grant help desk staff the right to reset passwords. Delegate the right to reset passwords to help desk staff so that members of the Domain Administrators group are not required to reset user account passwords. Creating a Computer Account Management Plan Windows 2000 and Windows Server 2003 computers have accounts in Active Directory and are authenticated in a separate process that is transparent to the user. You can use computer authentication to apply uniform security policies to groups of computers, such as computers contained in a domain, a site, or an organizational unit (OU) based on how the computers are grouped and which rights and policies are granted and applied to each group. For example, you can configure an OU for computers that are public kiosks on a retail floor and apply limited permissions to users. You can configure another OU for a computer stored in a locked office and allow users greater access to resources. Evaluate the security needs for different types of computers in your organization. Determine which computers are more vulnerable to compromise and therefore require stronger security settings, and then apply policies to the domains, sites, and OUs as appropriate to your security needs. For more information about applying security policies, see “Deploying Security Policy” in Designing a Managed Environment in this kit. Managing Computer Accounts You also need to establish a plan for managing computer accounts, including:  The creation of new accounts  The deletion of old accounts  Resetting of computer account passwords. Because new computer accounts are created automatically whenever a computer is added to a domain, you need to decide who has the right to add computers to domains. You can delegate this responsibility to an individual or group in your organization by adding them to the Add workstations to domain Group Policy. 156 Chapter 14 Designing an Authentication Strategy

You can choose to manage new computer account creation in your organization in one of the following ways:  Allow authenticated users to create new computer accounts. This approach might be desirable in organizations where users can be largely trusted. However, if you only want to trust a limited group of users, such as developers, for example, to create new computer accounts, you can control this by using the Security Configuration Manager to either assign or deny this right to users. By default, authenticated users are assigned the Add workstations to domain user right on the Group Policy object on domain controllers. This enables them to create up to 10 computer accounts in the domain by using the Network Identification Wizard. The wizard requests information about the computer name, the domain or workgroup that the computer is joining, and the domain users that are to be added to the local groups for local computer access, and uses this information and the credentials of the authenticated user to create a new account in Active Directory.

Note After a computer account is created, administrators must ensure that the account is a member of the appropriate groups, so that the appropriate Group Policies are applied.

 IT staff joins each new computer to the domain individually during installation. Although this approach can work for small organizations in which computer account creation occurs infrequently, it is impractical for large organizations with a high volume of new computer accounts.  IT staff uses scripts to create new accounts ahead of time, and assigns new computers to existing accounts during installation. You can use an Active Directory Service Interfaces (ADSI) script to create computer accounts in advance of installing new computers. As new computers are brought online, their computer names must match the names that you have specified in the script. This approach works well for organizations in which many similar computers need to be added to a domain simultaneously, such as in a training lab or server farm. For more information about using scripts to create new computer accounts, see Windows Deployment and Resource Kits at http://www.microsoft.com/reskit, or see the MSDN Scripting Clinic link on the Web Resources page at http://www.microsoft.com/windows/reskits/webresources. Additional Resources 157

Note It is more secure to create new computer accounts from the computer itself, rather than creating the accounts remotely or by using scripts. An attacker who gains access to some part of a domain can use existing scripts or remote account creation processes to create accounts to further compromise the system. Requiring that new accounts be created from the new computer protects against such attacks.

You can choose to delete computer accounts in your organization in one of the following ways:  Include deleting users’ computer accounts as part of the employee departure procedure. When employees leave your organization, establish a policy by which their computer accounts are deleted from Active Directory.  Create scripts that search for computer accounts that have not been logged on to for a period of time or have not had their password changed, and delete those computer accounts. For example, you might create a script that identifies accounts that have not been logged on to for six weeks or that have not had their passwords changed for twice the password lifetime as prescribed by domain Group Policy, and delete those accounts. If a computer is unable to contact a domain controller to initiate a password change, the account might become unsynchronized with the domain and require a password reset. An effective way to enable the resetting of computer accounts in your organization is to assign help desk staff the right to reset passwords. Delegate the right to reset computer passwords to help desk staff so that members of the Domain Administrators group are not required to reset computer account passwords.

Important If you are migrating from Windows NT 4.0 domains, you must create a plan for the creation of new computer accounts. Computers running Windows NT 4.0 do not have computer accounts. Creating Service Accounts Like users, services have accounts and authenticate to the network operating system. This ensures that only authorized services are able to complete tasks, and protects against attackers who create unauthorized services to infiltrate network systems. Most service accounts are created automatically when a service is installed. Similarly, applications that act as services, such as print spoolers or messaging services, create accounts automatically to complete their tasks. Therefore, in general, you do not need to create or modify service accounts. However, if service accounts are deleted accidentally, you must recreate them manually. Creating service accounts is similar to creating user accounts. The only additional configuration step that is needed is to set the service principal name (SPN) for the account. This needs to be done to ensure mutual authentication. For example, in the case of a web server, a SPN of http/hostname might need to be set for the service account. The SPN can be set for the account by using the Setspn utility. For more information about Setspn, in Help and Support Center for Windows .NET Server 2003, click Tools, and then click Windows Support Tools. 158 Chapter 14 Designing an Authentication Strategy

There are also built-in service accounts that use the computer account credentials by default for network authentication. These include the LocalSystem account, which was already present in Windows 2000. However, LocalSystem is a privileged account and should be used only when required. Windows Server 2003 includes the following new security contexts to provide a means by which you can further secure network service accounts:  LocalService. This context is intended for services that run with limited access on local computers and do not require network authentication. In this way, a compromised service can do limited damage to the local computer and no damage to network computers.  NetworkService. This context is intended for services that need to complete tasks on the network, but require only restricted local capabilities.

Securing Service Accounts Most services have specific functions, so it is best to grant them only those rights that are required for the services to perform those functions. In this way, if attackers compromise a service account, they have limited access and can do only a limited amount of damage. If a service account has rights that extend beyond its specific function, an attacker who compromises the account can do extensive damage. To ensure maximum security, avoid running services on domain controllers. For example, do not make your domain controller a mail server, Web server, and file and print server. Adding multiple services on a critical link such as the domain controller is risky, because it increases the complexity of the system and therefore increases the potential for compromise. A problem with a print server that might otherwise only give an attacker the ability to create unauthorized print jobs can instead grant the attacker access to Active Directory, a critical data repository. The security benefits of using separate computers for services outweigh the initial investment in hardware equipment. Also, you might need to reset service account passwords. Do not modify service accounts unless a problem occurs that interferes with the functioning of a service. To reset service account passwords 1. In Active Directory Users and Computers, right-click the user’s account. 2. Click Reset Password. 3. Enter and confirm the new password. You must ensure that the service uses the newly selected password before the service can take advantage of the reset password. Ensure that the password that the service uses and the password that you reset the service account to have are the same. Additional Resources 159

Applying Authentication Policies to Groups You can manage authentication in your organization by adding user, computer, and service accounts to groups and then applying authentication policies to those groups. For example, you can apply the following policies to groups, based on their function in the organization:  Log on locally  Access this computer from the network  Log on over network  Reset accounts  Create accounts If you want to make a computer less accessible to others, including both legitimate users and attackers, you can use policies in the following ways to restrict access for less trusted groups (such as Anonymous):  Assign the Deny access to this computer from the network policy.  Assign the Deny logon locally policy.  Remove the Remove computer from docking station policy. Other policies that you might assign or deny to users can also increase security or maximize flexibility, such as Deny logon as batch job or Log on as service. For more information about Group Policies that impact authentication, see “Deploying Security Policy” in Designing a Managed Environment of this kit. Example: Creating a Foundation for Authentication An organization that includes 2,100 users and 3,700 computers created an authentication strategy when they deployed Windows Server 2003 in their environment. Because computers in their environment are running versions of the Windows operating system earlier than Windows 2000, they need to support LAN Manager authentication. They decided to make members of the help desk staff and the Administrators group responsible for user account management, and delegated computer account management to the help desk staff. The organization secured their service accounts by running only required services on domain controllers and restricting the number of individuals who are able to administer services. They assigned the Log on locally, Access this computer from the network, and Log on over network rights to Domain Admins and Domain Users, but not to Guest accounts, to protect the security of their system. They granted the Reset accounts and Create account policies to help desk staff to reduce the administrative burden on domain administrators. 160 Chapter 14 Designing an Authentication Strategy

Figure 14.3 shows the worksheet that the organization created to document their authentication strategy plan. Figure 14.3 Example of an Authentication Strategy Planning Worksheet Additional Resources 161

Securing the Authentication Process It is important to secure your authentication process to protect your system against various types of security threats, such as password-cracking tools, brute-force or dictionary attacks, abuse of system access rights, impersonation of authenticated users, and replay attacks. In addition, if you share resources on your network with other organizations, you must ensure that your authentication policies interoperate with the authentication policies that are in place on other systems. For a worksheet to use in documenting authentication security policies, see “Authentication Security” (DSSAUT_2.doc) on the Windows Server 2003 Deployment Kit companion CD (or see “Authentication Security” on the Web at http://www.microsoft.com/reskit). Figure 14.4 shows the process for securing authentication. 162 Chapter 14 Designing an Authentication Strategy

Figure 14.4 Securing Authentication Additional Resources 163

Creating a Strong Password Policy Given enough encrypted data, time, and computing power, attackers can compromise almost any cryptographic system. You can prevent such attackers from succeeding by making the task of cracking the password as difficult as possible. Two key strategies to accomplish this are to require users to set complex passwords and to require users to change their passwords periodically, so that attackers do not have sufficient time to crack the complex encryption code. Complex Passwords You should set password policy to require complex passwords, which contain a combination of uppercase and lowercase letters, numbers, and symbols, and are typically a minimum of six characters long or more for all accounts, including administrative accounts, such as local administrator, domain administrator, and enterprise administrator. In this way, when users submit a new password, Windows Server 2003 password policy determines whether the password meets established complexity requirements. You can set more complex password requirements; however, such password policies can increase costs to the organization if they obligate users to select passwords that are difficult to remember. Users might be forced to call the help desk if they forget their passwords, or they might write down their passwords, thus making them vulnerable to discovery. For this reason, when you establish password policies, you need to balance the need for strong security against the need to make the password policy easy for users to follow. Older Client Operating Systems Versions of the operating system earlier than Windows Server 2003 cannot handle passwords that contain more than 14 characters. For example:  Attempts to log on to a Windows 2000–based computer running Terminal Services by using automatic logon settings configured in Client Connection Manager fail if your password is more than 14 characters long. Client Connection Manager has a 14- character limitation for passwords used for automatic logon. To work around this problem, you must manually enter a password to be used for the connection when prompted. You can prevent this by modifying the password used in Client Connection Manager and on your domain to be no more than 14 characters long.

 In versions 3.5 and 3.51 of the Microsoft® Windows® operating system, Run.exe allows users to start utilities. When users start utilities, they can specify a user account and password to be used to start the application. When the password parameter is used, Run.exe stores the values in buffers limited to 14 characters. Passwords longer than 14 characters are truncated for storage and then passed to domain controllers in truncated form, causing authentication failures. You can solve many of these problems by applying the latest service packs for operating systems. If your organization includes clients running versions of the operating system earlier than Windows Server 2003 that do not support longer passwords, be sure to account for this when you set your password policies. 164 Chapter 14 Designing an Authentication Strategy

Selecting Password Policy Options Windows Server 2003 provides security policies that ensure that all users select strong passwords. Creating a password policy involves setting the following options in the Default Domain Group Policy object. These policies, with the exception of those settings related to password lifetime, are enforced on all users in a domain. Maximum password age This setting determines the period of time (in days) that a password can be used before the system requires the user to change it. The best defense against impersonation is to require that users change their passwords regularly. This reduces the amount of time available for attackers to crack unknown passwords, and it periodically invalidates any password that has been stolen by other means. The default value of 42 days is generally appropriate; however, some IT departments shorten this to 30 days. Enforce password history This setting determines the number of unique new passwords that have to be associated with a user account before an old password can be reused. It also rejects new passwords that are too similar to previous passwords. This feature prevents users from circumventing password lifetime restrictions by reusing their old password. The default value is 1. Most IT departments choose a value greater than 10. Minimum password age This setting determines the number of days that must pass before a user can change his or her password. Defining a minimum password age prevents users from circumventing the password history policy by defining multiple passwords in rapid succession until they can use their old password again. The default value is 0, but it is recommended that this be reset. A value of a few days discourages rapid password recycling while still permitting users to change their own passwords if desired. Note that setting this parameter to a value higher than the maximum password age forces users to call the IT department to change their passwords, which increases costs to the organization. Minimum password length The setting determines the minimum number of characters that a user’s password must contain. It is recommended that you change this setting from the default value of 0. A minimum password length of seven characters is considered standard. Additional Resources 165

Passwords must meet complexity requirements This setting enables Windows Server 2003 to verify that new passwords meet complexity requirements. The default password filter (Passfilt.dll) included with Windows Server 2003 requires that a password:  Is not based on the user’s account name.  Contains at least six characters.  Contains characters from three of the following four categories:  Uppercase alphabet characters (A–Z)  Lowercase alphabet characters (a–z)  Arabic numerals (0–9)  Nonalphanumeric characters (for example, !$#,%) This policy is disabled by default. Enable it to secure your passwords against cracking. Establishing an Account Lockout Policy You need to establish an account lockout policy at the same time that you establish a password security policy. Account lockout policies protect your environment against brute-force or dictionary attacks. Given enough tries, even complex passwords can be guessed. Account lockout policies reduce the number of guesses that an attacker can make. It is best to establish an account lockout policy that is restrictive enough to prevent attacks, while still allowing for the occasional user error. An account lockout policy that is too strict might increase the number of support calls in your organization as users who type their passwords incorrectly are mistakenly locked out. Creating an account lockout policy involves setting the following options in the Default Domain Group Policy object. Account lockout threshold The account lockout threshold limits the number of times that anyone can attempt to log on to a computer from a remote location. This prevents attackers from trying all possible passwords over the network. This setting is disabled by default in the Default Domain Group Policy object. You can turn it on by setting the value to a number within the accepted range of 1 through 999. Set the value high enough to ensure that occasional errors do not result in account lockout. Note that this setting does not apply to attempts to log on at the console of a locked workstation or to attempts to unlock a screensaver. Locked workstations cannot be forced to run password-cracking programs. 166 Chapter 14 Designing an Authentication Strategy

Account lockout duration The account lockout duration determines how long, in minutes, an account that has exceeded the account lockout threshold remains locked before it is automatically unlocked. Valid settings range from 0 through 99,999 minutes, or about 10 weeks. When the value is set to 0, an administrator must manually unlock the account. Because account lockout policies are designed to protect against brute-force attacks, setting even a low value for the account lockout duration reduces the number of possible attacks considerably. Note that setting a high value for the account lockout duration can increase help desk calls when legitimate users are mistakenly locked out, and aside from indicating that an attack was attempted, provides little additional protection. By default, this policy is not defined, because it is only applicable when an account lockout threshold is specified. Reset account lockout counter after This setting determines the number of minutes that must elapse after a failed logon attempt before the counter is reset to 0 bad logon attempts. The range is 1 through 99,999 minutes. This value must be less than or equal to the account lockout duration. Enforce user logon restrictions When this option is enabled, the KDC validates every request for a session ticket by examining the user rights policy on the target computer. The user requesting the session ticket must be assigned the Log on locally policy (if the requested service is running on the same computer) or the Access this computer from the network policy (if the requested service is on a remote computer) to receive a session ticket. This option also serves as a means to ensure that the requesting account is still valid. Verification is optional because the extra step takes time and might slow network access to services, but if account rights have changed or user accounts have been disabled between the time when the initial ticket was issued and the time when a service ticket was requested, these changes do not take effect. By default, the policy is enabled in the Default Domain Group Policy object. If the policy is disabled, this check is not performed. For greater security in an environment in which user accounts change frequently, enable this setting. For faster performance, particularly in a more stable user account environment, disable this setting. Additional Resources 167

Assigning Logon Hours You can assign logon hours as a means to ensure that employees are using computers only during specified hours. This setting applies both to interactive logon, in which a user unlocks a computer and has access to the local computer, and network logon, in which a user obtains credentials that allow him or her to access resources on the network. Assigning logon hours is useful for organizations in which some users are less trustworthy than others or require supervision. For example, you might want to restrict logon hours when:  Logon hours are a condition for security certification, such as in a government network.  Your organization includes shift workers. In this case, allow shift workers to log on only during their scheduled hours.  Your organization includes temporary employees. The logon schedule is enforced by the Kerberos Group Policy setting Enforce User Logon Restrictions, which is enabled by default in Windows Server 2003. Whether users are forced to log off when their logon hours expire is determined by the Automatically log off users setting. By default, all domain users can log on at any time. You can use the following procedure to limit the logon hours of an individual domain user. To restrict the logon hours of a domain user 1. In Active Directory Users and Computers, right-click the user’s account. 2. Click Properties, and click the Account tab. 3. Click Logon Hours. In the Logon Hours dialog box, indicate the hours and/or days of the week in which you are restricting the user from logging on. When you have set the logon hours for an individual, you can copy that account to apply the same settings to a new user in the same department. To restrict the logon hours for multiple users in the same OU 1. In Active Directory Users and Computers, select the user accounts, and then right- click any of the selected items. 2. Use the Properties of Multiple Objects dialog box to alter the properties for all of the selected users. When you restrict logon hours, you might also want to force users to log off after a certain point. If you apply this policy, users cannot log on to a new computer, but they can stay logged on even during restricted logon hours. To force users to log off when logon hours expire for their account, apply the Network security: Force logoff when logon hours expire policy. 168 Chapter 14 Designing an Authentication Strategy

Creating a Ticket Expiration Policy It is important to establish reasonable lifetimes for tickets in your organization. Ticket lifetimes must be short enough to prevent attackers from cracking the cryptography that protects the ticket’s stored credentials. However, ticket lifetimes must also be long enough to be convenient for users and to ensure that requests for new tickets do not overload the network. Creating a ticket expiration policy involves setting the following options in the Default Domain Group Policy object. Maximum lifetime for user ticket This setting indicates the amount of time for which a ticket is valid before it expires. Generally, it is best if the Maximum Lifetime for User Ticket setting reflects the average amount of time that users access their computers in one day. This is set to 10 hours in the Default Domain Group Policy object. At the end of the ticket lifetime, the user either obtains a new ticket or renews the existing ticket. This process is performed transparently by the computer, but each ticket request or renewal produces network traffic and domain controller loading. A short maximum ticket lifetime provides greater security but also increases network traffic. A long maximum ticket lifetime decreases network traffic but does not provide the same level of security. Maximum lifetime for service ticket This setting usually matches the established user ticket lifetime. It might be shorter, however, if there is a need in your organization for secure authentication to services beyond what is required for user authentication. It might be longer if users require uninterrupted access to services for long periods of time. For example, you might need to extend the ticket lifetime if your users run jobs that have a duration that is longer than the duration of the user ticket lifetime. If you do not have any special requirements for service ticket lifetime, do not extend the lifetime of the ticket. The maximum service ticket lifetime must be greater than 10 minutes and less than or equal to the Maximum Lifetime for User Ticket setting. By default, this value is set to 600 minutes (10 hours) in the Default Domain Group Policy object (GPO). Ongoing operations are not interrupted if the session ticket used to authenticate the connection expires before the operation is complete. Maximum lifetime for user ticket renewal This setting determines the period of time (in days) during which a user’s ticket-granting ticket (TGT) can be renewed. By default, this is set to seven days in the Default Domain GPO. Shorter renewal times make it easier to require users to reauthenticate in the event that you suspect that there has been a security breach. An attacker with a renewable user ticket can continue to renew that ticket for as long as the policy allows. Shortening renewal times makes an attacker’s task more difficult, but it also increases the authentication load on domain controllers. Additional Resources 169

Establishing Network Authentication Standards Windows Server 2003 allows for interoperability with earlier versions of Windows and other operating systems. Interoperating with other operating systems, however, can negatively impact your network security. It is important, therefore, to establish standards for network authentication to minimize the effect that this interoperability has on your organization’s security. You can do this by restricting LAN Manager authentication and by restricting anonymous access. You must also establish a plan for upgrading Windows NT 4.0 domain controllers to balance the Kerberos authentication load in Windows Server 2003 and Windows 2000 domains.

Restricting LAN Manager Authentication Due to advances in cracking tools and hardware capabilities, LAN Manager authentication encryption is more vulnerable to attack than newer forms of encryption. For this reason, it is important to restrict the use of LAN Manager authentication whenever possible. Windows Server 2003 supports all versions of LAN Manager authentication, including LM, NTLM, and NTLM version 2 (NTLMv2), to allow for compatibility with clients that do not support newer authentication protocols. If it is necessary in your organization to support LAN Manager authentication, you can increase security by enabling support of NTLMv2 whenever possible. Reducing or eliminating the use of LAN Manager authentication and NTLM version 1 (NTLMv1) removes password hash values from the network, and therefore increases network security. You can enable NTLMv2 support by doing the following:  Upgrading to at least Service Pack 4 (SP4) on all Windows NT 4.0–based clients. You can download the service pack from the Microsoft Web site at http://www.microsoft.com.  Installing the directory services client on all client computers that are running the Microsoft® Windows® 95 or Windows® 98 operating system You can install the directory services client from the Windows Server 2003 operating system CD.  Tightening LAN Manager authentication policies. If all clients support NTLMv2, set Domain Group Policy for LAN Manager Authentication Level to Send NTLMv2 response only\refuse LM & NTLM. This policy is under Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options\. If some clients exist that do not support NTLMv2, set the LAN Manager Authentication Level to Send NTLM response only. This reduces the amount of ciphertext available to attackers.

Note Clients that do not typically support NTLMv2 include Macintosh and Windows Services for UNIX. 170 Chapter 14 Designing an Authentication Strategy

Restricting Anonymous Access In Windows Server 2003, access that was available to Anonymous users in Windows NT 4.0 is available only to Everyone and Guest accounts. However, in some of the following situations you might still need to allow Anonymous access to portions of your network. Some of the services running versions of Windows earlier than Windows 2000 use anonymous access to request user account information from domain controllers and to list network shares on file servers and workstations. You also might need to allow Anonymous access when an administrator in the trusting domain of a one-way cross-forest trust relationship needs to list users and shares in the trusted domain of another forest. In addition, the Windows NT Remote Access Service (RAS) uses anonymous logon to determine whether a user has permission to establish a RAS connection. Anonymous access to Active Directory is used to change passwords from earlier systems. This form of anonymous access is enabled by the Pre-Windows 2000 compatible access security group, which is a local group found only on Windows 2000 and Windows Server 2003 domain controllers. By default, this group has read access to user and group objects in Active Directory. If you need to support networks containing a mix of Windows NT 4.0, Windows 2000, and Windows Server 2003 desktops and servers, you must take into account the new restrictions on anonymous access by doing the following:  First determine which services and applications require anonymous access to network resources, and identify the servers to which anonymous access is needed.  Then decide whether to add the Anonymous Logon identity to specific access control lists (ACLs), or to make security policy changes that relax the restrictions that Windows Server 2003 places on anonymous access. You can regulate anonymous access by doing the following:  Edit the ACLs of the resources, adding the Anonymous Logon identity to the list of authorized users. This approach is the most secure, but requires editing the ACLs of each resource, which might be difficult to manage or troubleshoot.  Use the Do not allow anonymous enumeration of SAM accounts and shares policy Group Policy object, which can be found in Computer Configuration/Windows Settings/Security Settings/Local Policies/Security Options, to prevent attackers from using anonymous connections to obtain information about accounts and shares on a computer. Preventing Security Accounts Manager (SAM) account enumeration can help thwart attacks, but also prevents legitimate users in other domains from obtaining this information. Additional Resources 171

 Disable or do not configure this policy if your domain includes computers running versions of Windows earlier than Windows 2000 or if it has an outbound, one-way trust relationship with a domain in another forest. The browser service on computers running Windows NT 4.0 and earlier requires the ability to enumerate shares anonymously when it connects to backup browsers, master browsers, and domain master browsers to retrieve server lists and domain lists. Users on the trusting side of a one-way trust relationship need the ability to enumerate SAM accounts anonymously when they add domain accounts and groups on the trusted side of the relationship to security groups in the trusting domain. For more information about domain and forest trust relationships, see the Distributed Services Guide of the Windows Server 2003 Resource Kit (or see the Distributed Services Guide on the Web at http://www.microsoft.com/reskit).  Use the Let Everyone permissions apply to anonymous users policy to extend anonymous access to match the Windows NT 4.0 model. If this policy is enabled, Anonymous users can access any resource that Everyone is allowed to access. Do not enable this policy unless there is a compelling business reason to compromise the security provided by requiring some form of authentication. If you do enable this policy, work to disable it by editing the ACLs of specific resources to allow anonymous access, as required in particular cases.  If you need to permit clients running versions of Windows earlier than Windows 2000 to change their passwords, add the Everyone and Anonymous Logon groups to the Pre-Windows 2000 compatible access group, enabling anonymous access to the accounts. The membership of this group is determined by a user option during the installation of the first domain controller in the domain. You can change the group membership if necessary.

Creating a Plan for Windows NT 4.0 Domain Controller Upgrade Workstations running the Microsoft® Windows® XP operating system that are joined to an existing Windows NT 4.0 domain use NTLM to authenticate to the Windows NT 4.0 domain controllers. When you add a Windows Server 2003– or Windows 2000–based domain controller to a domain, all clients running the Microsoft® Windows® XP, or Windows® 2000 Professional operating system and all servers running Windows Server 2003 or Windows 2000 automatically use Kerberos authentication when users log on interactively. Users at these computers therefore cannot log on by using the Windows NT backup domain controllers. This shifts the Windows Server 2003 and Windows 2000 user authentication load to the existing Windows Server 2003– or Windows 2000–based domain controllers. If the primary domain controller becomes overloaded or fails for any reason, users cannot log on to computers running Windows Server 2003 or Windows 2000. 172 Chapter 14 Designing an Authentication Strategy

For this reason, when you add Windows Server 2003– or Windows 2000–based domain controllers to a domain, you must continue to add Windows Server 2003– or Windows 2000–based domain controllers to keep pace with client demands. You can do this by installing new domain controllers or by upgrading existing Windows NT 4.0–based domain controllers. Review your organization’s plans for domain upgrade and consolidation and for the deployment of new Windows Server 2003–based workstations, and ensure that workstation upgrade does not proceed more rapidly than the domain controller upgrade. Add Windows Server 2003– or Windows 2000–based domain controllers to a domain only when you are certain that the domain controllers have the capacity to meet the authentication needs of all Windows Server 2003–based workstations in the domain. For more information about upgrading Windows NT 4.0 domains to Windows Server 2003 Active Directory, see “Upgrading Windows NT 4.0 Domains to Windows Server 2003 Active Directory” in this book. Setting Clock Synchronization Tolerance to Prevent Replay Attacks You can use the Maximum tolerance for clock synchronization Group Policy to protect your organization against replay attacks, in which attackers replay authentic network exchanges that they capture off the wire to cause the server to allow them access to the system. If your clock synchronization tolerance setting is low, the server rejects replayed messages for which the allowable time skew has passed. The Maximum tolerance for computer clock synchronization Group Policy is set to 5 minutes by default. In most cases, this provides an acceptable level of security. You can increase protection against replay attacks by shortening the maximum tolerance for clock synchronization. Tighter synchronization requirements, however, might result in increased authentication traffic. Shortening the maximum tolerance reduces replay attacks because the Kerberos V5 authentication protocol uses authenticators based on time to establish user identities. A shorter tolerance makes a replay attack more difficult. The Maximum tolerance for computer clock synchronization Group Policy can be found in the Default Domain Policy object under Computer Configuration\Windows Settings\Security Settings\Account Policies\Kerberos Policy. In general these settings should be changed only if there is a strong reason to believe you might be vulnerable to this type of attack. For more information about time synchronization in Windows Server 2003, see the Distributed Services Guide of the Windows Server 2003 Resource Kit (or see the Distributed Services Guide on the Web at http://www.microsoft.com/reskit). Additional Resources 173

Example: Securing Authentication An organization developed an authentication strategy to strengthen the default security that Windows Server 2003 provides. This is to protect data from attackers whose activity has been noted in audit logs and because management has made increasing the security of the system a top priority. To meet these security demands, administrators created password policies to ensure strong passwords, applied account lockout policies to prevent brute-force attacks, assigned logon hours to prevent users from working during unsupervised times, and established a ticket expiration policy to enforce logon hours for several groups, excluding batch jobs. The organization chose to eliminate LAN Manager authentication by setting the Restrict LanMan Authentication policy to Not supported to prevent the use of authentication methods that are vulnerable to attack. They chose to eliminate anonymous logon by enabling Restrict Anonymous Access to limit the number of resources that attackers can access by impersonating anonymous users. In order to enable these policies, the organization chose to retire their Windows NT 4.0–based domain controllers, and replaced them with new Windows Server 2003–based computers. Administrators in the organization accepted the default clock synchronization tolerance of five minutes. This setting protects the system against replay attacks while keeping authentication traffic to a minimum. Figure 14.5 shows the worksheet that the organization created to document their authentication security plan. 174 Chapter 14 Designing an Authentication Strategy

Figure 14.5 Example of an Authentication Security Worksheet Additional Resources 175

Extending Your Authentication Framework If your environment includes more than one forest, or your organization needs to exchange information with other Kerberos clients and servers, you need to extend your authentication framework to accommodate those relationships and resources. You do this by establishing trust relationships and by creating Active Directory accounts as appropriate. For a worksheet to assist you in documenting your plan for extending your authentication framework, see “Extended Authentication Framework” (DSSAUT_3.doc) on the Windows Server 2003 Deployment Kit companion CD (or see “Extended Authentication Framework” on the Web at http://www.microsoft.com/reskit). Figure 14.6 shows the process for extending your authentication framework. 176 Chapter 14 Designing an Authentication Strategy

Figure 14.6 Extending Your Authentication Framework Additional Resources 177

Establishing Interforest Authentication If your organization includes more than one forest, you need to enable the forests to allow authentication and resource sharing. You can do this by establishing trust relationships between some or all of the domains in the forests. The types of trust relationships that you establish will depend on the versions of the operating system that are running in each forest. For more information about establishing trust relationships, see “Understanding Trusts” in Help and Support Center for Windows Server 2003. Authentication between Windows Server 2003 forests When all domains in two forests trust each other and need to authenticate users, establish a forest trust between the forests. When only some of the domains in two Windows Server 2003 forests trust each other, establish one- way or two-way external trusts between the domains that require interforest authentication. Authentication between Windows Server 2003 and Windows 2000 forests It is not possible to establish transitive forest trusts between Windows Server 2003 and Windows 2000 forests. To enable authentication with Windows 2000 forests, establish one-way or two-way external trusts between the domains that need to share resources. Authentication between Windows Server 2003 and Windows NT 4.0 forests It is not possible to establish transitive forest trusts between Windows Server 2003 and Windows NT 4.0 domains. Establish one-way or two-way external trusts between the domains that need to share resources. In each of these cases you should consider whether the selective authentication option needs to be enabled. Selective authentication should only be enabled when the trusted domain is located in the extranet or in a different corporation, and therefore only requires access to a very limited set of resources. The Kerberos V5 authentication protocol does not work across forests in Windows 2000 or Windows NT environments. In these situations, Windows Server 2003 relies on the NTLM protocol for cross-forest authentication. A direct trust relationship between two domains in separate forests enables NTLM authentication; however, NTLM enables client authentication only, and not mutual authentication. Therefore, if you must authenticate across forest boundaries, you need to ensure that all computers running versions of Windows earlier than Windows 2000 have been upgraded to use NTLMv2. 178 Chapter 14 Designing an Authentication Strategy

Enabling Interoperability with Kerberos Clients and Servers Running Other Operating Systems Some organizations have clients running UNIX or other operating systems. To allow for the secure exchange of information with other clients, you can configure the clients to authenticate to Windows Server 2003 domain controllers in order to obtain the required credentials. Similarly, Windows clients can be configured to authenticate to other KDCs. To enable interoperability with UNIX or other clients, you must:  Establish a Realm trust, a particular type of external trust with a UNIX realm. This enables an authentication that is completed in one realm or domain to be trusted by another realm or domain.  Create account mappings so that other clients have mapped accounts in Active Directory. This enables other clients to access resources that are secured in a Windows environment. Establishing Trusts with Kerberos Realms To enable authentication between Windows domains and UNIX realms or other clients, you must establish a one-way or two-way trust between the two so that tickets generated in one are recognized and accepted by resources in the other. For example, a one-way trust relationship in which a Kerberos realm trusts a Windows Server 2003 domain allows Windows Server 2003 users to log on to the Kerberos realm; in other words, the UNIX server accepts or trusts the authentication performed by the Windows Server 2003 KDC. Another trust can be created so that users logged on to the Kerberos realm can access resources in the Windows Server 2003 domain. Configuring Accounts for Kerberos Clients Running Other Operating Systems After you have established trusts between a UNIX or other realm and a Windows domain, you must coordinate accounts, enabling users to authenticate and access resources. User accounts You must configure clients to authenticate to the appropriate KDC. For example, you might configure a Linux desktop to authenticate to a Windows Server 2003–based KDC at logon. Most Kerberos clients allow for the specification of a KDC for authentication as part of the logon to the local computer. Windows Server 2003 provides the Kerberos KDC services as part of the domain controller, so the clients log on to the domain controller itself. The domain controller locates the KDC by means of service location records in the DNS. This frees the administrator from having to maintain explicit Kerberos configuration data for each client. Additional Resources 179

Service accounts Windows Server 2003 supports the authentication of other Kerberos services in a Windows Server 2003 domain. If you require services to access resources across the domain or realm, you must create service accounts in Active Directory to represent those services. For example, you can make a UNIX-based telnet service accessible to Kerberos clients in a Windows domain by creating a service account in Active Directory for that service. In this case, the telnet service is part of the Windows domain, rather than the other Kerberos realm, as is the case with trust relationships established between Windows and other Kerberos realms. Account mappings When a Windows Server 2003 domain trusts a Kerberos realm, the principals in the Kerberos realm do not contain the group associations that are used for access control in the Windows Server 2003 environment. You can use account mapping in the Windows Server 2003 domain to provide authorization information for Kerberos principals from trusted realms. You can either map accounts one-to-one, by mapping each account in a realm to a corresponding account in the Windows Server 2003 domain, or you can use one-to-many mapping, by which multiple individual accounts in a realm are mapped to one account in the Windows Server 2003 domain. For more information about account mapping, see the Distributed Services Guide of the Windows Server 2003 Resource Kit (or see the Distributed Services Guide on the Web at http://www.microsoft.com/reskit). To ensure seamless interoperability, you must keep the accounts in the Kerberos realm and the Windows Server 2003 domain synchronized. You can use ADSI and Lightweight Directory Access Protocol (LDAP) in Active Directory to synchronize accounts, or use metadirectory technology such as Zoomit Via. 180 Chapter 14 Designing an Authentication Strategy

Deploying Smart Cards If your organization requires a more secure form of authentication, you can use certificates and smart cards for user logon. Smart cards provide additional security because they require both a password and a physical smart card for a user to log on. The smart card contains a public key certificate, and to unlock the certificate, the user must supply a password, or PIN. It is much more difficult for an attacker to obtain both a physical smart card and the PIN number that is used to unlock it in order to gain access to network resources. In order to decide whether smart card authentication is appropriate for your organizations, evaluate the potential benefits against the following consideration:  Costs. Deploying smart cards entails initial equipment costs for the purchase of smart cards and smart card readers, as well as administrative costs for preparing and distributing smart cards.  Infrastructure. A public key infrastructure (PKI) is required for smart card authentication. For more information about establishing a PKI, see “Designing a Public Key Infrastructure” in this book.  Ongoing administration. Unlike card keys, smart cards cannot be replaced easily if lost or forgotten. This introduces the potential for lost productivity if a user forgets or loses his or her card. Because of the potential costs and administrative burden, many organizations choose to deploy smart cards only to certain groups of users, such as administrators or users who have access to extremely sensitive data. For more information about deploying smart cards, see “Deploying Smart Cards” in this book. Example: Extending the Authentication Framework An organization that is based on an Active Directory logical structure that includes four forests, forest A, forest B, forest C, and forest D, must extend its authentication framework in order to facilitate resource access for its clients in all locations. The organization needs to share resources with a Windows NT 4.0 domain, Domain E, and Kerberos clients running Unix in Unix realm F. Figure 14.7 shows the logical structure of the organization. Additional Resources 181

Figure 14.7 Organization Logical Structure 182 Chapter 14 Designing an Authentication Strategy

To enable the sharing of resources, administrators establish the following trust relationships:  A forest trust between forests A and B  External trusts from domains in forests A and B to domains in forests C, D, and E  External trusts between domains in forests C, D, and E  Realm trusts between all domains and realm F The organization chooses to deploy smart cards to domain administrators, as these accounts are more sensitive to security attacks. Figure 14.8 shows the worksheet that the organization created to document their extended authentication framework. Figure 14.8 Example of an Extended Authentication Framework Worksheet Additional Resources 183

Enabling Supplemental Authentication Strategies Some organizations require more complex authentication solutions to meet their user access needs. For example, if your organization includes Web-based clients that use applications such as Microsoft® Internet Explorer to access data stored on back-end servers, you must enable complex authentication strategies, such as delegation, constrained delegation, and protocol transfer, to allow those clients to access the requested services in a secure manner. For a worksheet to assist you in documenting your plan for enabling supplemental authentication strategies, see “Supplemental Authentication Strategies” (DSSAUT_4.doc) on the Windows Server 2003 Deployment Kit companion CD (or see “Supplemental Authentication Strategies” on the Web at http://www.microsoft.com/reskit). Figure 14.9 shows the process for enabling supplemental authentication strategies. Figure 14.9 Enabling Supplemental Authentication Strategies 184 Chapter 14 Designing an Authentication Strategy

Enabling Delegated Authentication Delegated authentication occurs when a network service accepts a request from a user and assumes that user’s identity in order to initiate a new connection to a second network service. To enable delegated authentication, you must establish front-end or first-tier servers, such as Web servers, that are responsible for handling client requests, and back-end or n-tier servers, such as large databases, that are responsible for storing information. You can delegate the right to enable delegated authentication to users in your organization in order to reduce the administrative load on your administrators. To delegate this right, assign the Enable computer and user accounts to be trusted for delegation user right to the selected individuals. Users who are assigned the right to enable delegated authentication can assign the Trusted for delegation right to computer and service accounts that are used to serve users information that is stored on back-end servers and must be accessed securely. The user account that is requesting the resource must not be marked as sensitive; marking an account as sensitive explicitly denies the right to delegation. By establishing a service or computer as trusted for delegation, you enable that service or computer to complete delegated authentication, receive a ticket for the user who is making the request, and then access information for that user. Delegated authentication prevents an attacker who gains control of a front-end server, such as a Web server, from also gaining access to data stored on a back-end server. By requiring that all data be accessed by means of credentials that are delegated to the server for use on the client’s behalf, you ensure that the server cannot be compromised and then used to gain access to sensitive information on other servers. Delegated authentication is useful for multitier applications that are designed to use single sign-on capabilities across multiple computers. For example, domain controllers are automatically trusted for delegation. If this property is disabled on a domain controller, the Message Queuing service cannot run. Also, if you enable the Encrypting File System on a file server, the server must be trusted for delegation in order to store encrypted files on behalf of users. Delegated authentication is also useful on applications where Internet Information Services (IIS) supports a Web interface to a database running on another computer, such as Outlook Web Access in Exchange, or Web Enrollment Support pages for an enterprise certification authority, if the pages are installed on a separate Web server. It is recommended that you deny the right to participate in delegated authentication to the computer accounts in Active Directory for computers that are not physically secure, and to domain administrator accounts. Domain administrator accounts have access to sensitive resources and, if compromised, poses a higher risk to your organization. Additional Resources 185

When computers that are trusted for delegation are compromised by an attacker, the attacker can use them to access data stored on other servers by using the delegated credentials of an authenticated user. Ensure that only secure computers are trusted for delegation, and do not allow the delegation of powerful user accounts, such as administrator accounts. Also, consider applying constrained delegation to computers that are trusted for delegation, to limit the ways in which delegated credentials can be used. In this way, an attacker who has access to the computer has access to only limited services. For more information about enabling constrained delegation, see “Enabling Constrained Delegation” later in this chapter. To restrict delegated authentication 1. In Active Directory Users and Computers, right-click the computer or user account and select Properties. 2. On the Account tab, under Account Options, select the Account is sensitive and cannot be delegated check box, and click OK. 3. You can also restrict delegated authentication to prevent the delegation of sensitive user accounts by marking the account as not enabled for delegation. Restrict delegated authentication for accounts that are less secure or that are particularly powerful. Enabling Constrained Delegation Constrained delegation allows administrators to specify particular services from which a computer that is trusted for delegation can request resources. By using constrained delegation, you can prevent attackers who compromise a server from accessing resources beyond the limited scope of that server’s range. Before you enable constrained delegation, isolate critical data that you must keep secure from data to which users require frequent access. For example, if your organization maintains an e-commerce Web site, you might choose to isolate customer credit cards numbers, internal accounting, or human resources information from order status information that customers access frequently. To enable constrained delegation 1. In Active Directory Users and Computers, right-click the computer account and select Properties. 2. On the Delegation tab, click Trust this computer for delegation to specified services only. 3. Select Use Kerberos only, or select Use any authentication protocol. 4. Click Add and, in Add Services, click Users and Computers. 5. In Add Services, select the service or services that are trusted for delegation, and click OK. You can further restrict the scope of delegation that is permitted, for example to disable delegation for highly sensitive accounts such as administrator accounts. 186 Chapter 14 Designing an Authentication Strategy

To restrict delegation 1. In Active Directory Users and Computers, right-click the user account and select Properties. 2. Select the Sensitive attribute check box for the user account, and click OK. Example: Supplementary Authentication Strategies An organization chose to extend its authentication framework by enabling delegation and constrained delegation. To achieve this, they assigned the right to enable delegated authentication to specific user accounts, identified the computer accounts that are to be trusted for delegation, and established who is responsible for applying these policies. This allowed them to strengthen the security of their system by limiting the resources to which computers that are trusted for delegation have access. For example, they enabled the Web interface human resources database to access confidential data stored in databases in other servers, assigned the trusted for delegation right to workstations, and restricted delegation on the domain administrator user account. Figure 14.10 shows the worksheet that the organization created to document their supplementary authentication strategies. Figure 14.10 Example of a Supplementary Authentication Strategies Worksheet Additional Resources 187

Educating Users Ensuring that users understand their role in the authentication process is an important step in establishing an authentication strategy. By giving users clear guidelines and explaining the justification behind the guidelines, you reduce the chances that users will fail to comply with the procedures that you put into place. Figure 14.11 shows the process for educating users. Figure 14.11 Educating Users 188 Chapter 14 Designing an Authentication Strategy

Increasing Awareness of Social Engineering Attacks Users must be cautioned against sharing their passwords with others. All legitimate users have their own accounts, and any administrator who needs to complete a task for a user can do so by using his or her own account, without knowledge of the user’s password. Tasks such as the resetting of a user’s password or the unlocking of a user’s account do not require the use of a password. One effective and simple way that an attacker can compromise the security of a system is to call users, claiming to be from the help desk, and request their passwords. Because users feel compelled to help solve problems, they are not motivated to question the authenticity of the caller. Caution users to beware of such calls and assure them that it is appropriate to be skeptical of requests for their passwords. Establish a procedure by which users who receive calls of this type request the caller’s name and number and call them back. In this way, they can ensure that the call is legitimate before they reveal sensitive information. Communicating Password Creation Guidelines Educate your users about how to create strong passwords and how to keep them secret to help to protect your system from compromise as a result of simple carelessness. Users must understand that their passwords must meet your organization’s complexity guidelines. Incorporating uppercase and lowercase letters, numbers, and symbols into a password makes the password much more difficult to crack. Suggest to users that they insert numbers and characters into common phrases to protect against dictionary attacks. For example, the phrase “iamhappy” is easy to remember, but is hard to guess if some characters are changed so that the phrase appears as “1AmH@ppy!”. Caution users against writing their passwords down and leaving them in an accessible place. Be sure that users understand the danger of leaving their passwords in places where they can be discovered by an attacker. Although the need to remember complex passwords and reset them frequently might cause some inconvenience, the benefits of protecting your organization’s resources far outweigh the costs. Additional Resources 189

Additional Resources The following resources contain additional information and tools related to the chapter. Related Information  The Distributed Services Guide of the Windows Server 2003 Resource Kit (or see the Distributed Services Guide on the Web at http://www.microsoft.com/reskit) for more information about the Kerberos V5 authentication protocol and trust relationships.  “Designing the Active Directory Logical Structure” in this book for more information about the Active Directory logical structure.  “Upgrading Windows NT 4.0 Domains to Windows Server 2003 Active Directory” in this book for more information about domain migration.  “Designing a Public Key Infrastructure” in this book for more information about designing a public key infrastructure.  “Deploying IAS” in Deploying Network Services of this kit for more information about using RADIUS servers.  “Deploying Dial-Up and VPN Remote Access Servers” in Deploying Network Services for more information about using RAS servers.  “Designing a Resource Authorization Strategy” in this book for more information about user accounts and security groups.  The Distributed Services Guide of the Windows Server 2003 Resource Kit (or see the Distributed Services Guide on the Web at http://www.microsoft.com/reskit) for more information about time synchronization in Windows Server 2003.  “Deploying Smart Cards” in this book for more information about deploying smart cards.  “Deploying Security Policy” in Designing a Managed Environment of this kit for more information about Group Policies that impact authentication. Related Help Topics For best results in identifying Help topics by title, in Help and Support Center, under the Search box, click Set search options. Under Help Topics, select the Search in title only check box.  “Understanding Trusts” in Help and Support Center for Windows Server 2003 for more information about establishing trust relationships. 190 Chapter 14 Designing an Authentication Strategy

Related Job Aids  “Authentication Strategy Planning” (DSSAUT_1.doc) “Authentication Strategy Planning” on the Web at http://www.microsoft.com/reskit).  “Authentication Security” (DSSAUT_2.doc) on the Windows Server 2003 Deployment Kit companion CD (or see “Authentication Security” on the Web at http://www.microsoft.com/reskit).  “Extended Authentication Framework” (DSSAUT_3.doc) on the Windows Server 2003 Deployment Kit companion CD (or see “Extended Authentication Framework” on the Web at http://www.microsoft.com/reskit).  “Supplemental Authentication Strategies” (DSSAUT_4.doc) on the Windows Server 2003 Deployment Kit companion CD (or see “Supplemental Authentication Strategies” on the Web at http://www.microsoft.com/reskit).