C H A P T E R
1 4
Designing an
Authentication Strategy
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.
658 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.
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.
Overview of the Authentication Strategy Design Process 659
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
660 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.
Overview of the Authentication Strategy Design Process 661
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.
662 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.
Creating a Foundation for Authentication 663
Figure 14.2 Creating a Foundation for Authentication
664 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.
Creating a Foundation for Authentication 665

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.
666 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.
Creating a Foundation for Authentication 667
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.
668 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.
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.
Creating a Foundation for Authentication 669
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.
670 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.
Creating a Foundation for Authentication 671
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.
672 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
Securing the Authentication Process 673
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.
674 Chapter 14 Designing an Authentication Strategy
Figure 14.4 Securing Authentication
Securing the Authentication Process 675
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.
676 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.
Securing the Authentication Process 677
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.
678 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.
Securing the Authentication Process 679
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.
680 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.
Securing the Authentication Process 681
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.
682 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.
Securing the Authentication Process 683

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.
684 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).
Securing the Authentication Process 685
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.
686 Chapter 14 Designing an Authentication Strategy
Figure 14.5 Example of an Authentication Security Worksheet
Extending Your Authentication Framework 687
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.
688 Chapter 14 Designing an Authentication Strategy
Figure 14.6 Extending Your Authentication Framework
Extending Your Authentication Framework 689
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 oneway 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.
690 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.
Extending Your Authentication Framework 691
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.
692 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.
Extending Your Authentication Framework 693
Figure 14.7 Organization Logical Structure
694 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
Enabling Supplemental Authentication Strategies 695
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
696 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.
Enabling Supplemental Authentication Strategies 697
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.
698 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
Educating Users 699
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
700 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 701
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.
702 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).