The Best Damn Windows Server 2003 Book Period- P48 ppsx

to comply with the new policy, you can set the User must change password at next logon
option in the properties of the user accounts you administer.
Applying an Account Lockout Policy
In addition to setting password policies, you can configure your network so that user accounts will
be locked out after a certain number of incorrect logon attempts.This can be a soft lockout, in which
the account will be re-enabled after an administrator-specified period of time.Alternatively, it can be
a hard lockout in which user accounts can only be re-enabled by the manual intervention of an
administrator. Before implementing an account lockout policy, you need to understand the potential
implications for your network.
Create an account lockout policy
1. From the Windows Server 2003 desktop, click Start | Administrative Tools | Active
Directory Users and Computers.
2. Right-click the domain you want to administer, and then select Properties.
3. Select the Default Domain Policy, and click the Edit button.
4. Navigate to the account lockout policy by clicking Computer Configuration |
Windows Settings | Security Settings | Account Policies | Account Lockout
Policy. You’ll see the screen shown in Figure 11.4.
Using Account Lockout Policy, you can configure the following settings:
■
Account lockout duration This option determines the amount of time that a
locked-out account will remain inaccessible. Setting this option to 0 means that
the account will remain locked out until an administrator manually unlocks it.
■
Account lockout threshold This option determines the number of invalid
logon attempts that can occur before an account will be locked out. Setting this
option to 0 means that accounts on your network will never be locked out.
436 Chapter 11 • Creating User and Group Strategies
Figure 11.4 Account Lockout Policy Objects
301_BD_W2k3_11.qxd 5/12/04 12:30 PM Page 436
■
Reset account lockout counter after This option defines the amount of time

in minutes after a bad logon attempt that the “counter” will reset.
5. For each item that you want to configure, right-click the item and select Properties.To
illustrate, we create an Account lockout threshold of three invalid logon attempts. In the
screen shown in Figure 11.5, place a check mark next to Define this policy setting, and
then enter the appropriate value.
Creating User Authentication Strategies
Any well-formed security model needs to address the following three topics: authentication, autho-
rization, and accounting (or auditing). Authentication deals with who a person is, authorization centers
around what an authenticated user is permitted to do, and accounting/auditing is concerned with
tracking who did what to a file, service, or other resource. Windows Server 2003 addresses all three
facets of this security model.
Regardless of which protocol or technical mechanism is used, all authentication schemes need
to meet the same basic requirement of verifying that a user or other network object is in fact who
or what it claims to be. Windows Server 2003 offers several protocols and mechanisms to perform
this verification, including (but not limited to) the following:
■
Kerberos
■
NT LAN Manager (NTLM)
■
Secure Sockets Layer/Transport Security Layer (SSL/TLS)
■
Digest authentication
■
Smart cards
The following sections cover the details of each authentication mechanism available with
Windows Server 2003, and the appropriate use for each.The most common authentication mechanism
dates back to mainframe computing, password authentication. Concerns regarding password authentica-
tion have largely been connected with ensuring that user passwords are not transmitted in an easily
intercepted and decipherable form over a network connection. In fact, many modern password

authentication schemes, such as NTLM and Kerberos, never transmit the actual user password at all.
Creating User and Group Strategies • Chapter 11 437
Figure 11.5 Configuring the Account Lockout Threshold
301_BD_W2k3_11.qxd 5/12/04 12:30 PM Page 437
Need for Authentication
User authentication is a necessary first step within any network security infrastructure because it
establishes the identity of the user. Keep in mind as we go along that a fully functional authentica-
tion strategy will almost certainly involve a combination of the methods and protocols.Your goal as
a network administrator is to create an authentication strategy that provides the optimum security
for your users while allowing you to administer the network as efficiently as possible.
Single Sign-On
A key feature of Windows Server 2003 is support for single sign-on, an authentication mechanism
that allows your domain users to authenticate with any computer in the domain, while only pro-
viding their logon credentials one time. Whether your network authentication relies on single sign-
on or not, any authentication scheme is a two-step process. At the very least, the user must perform
an interactive logon in order to access the local computer. If network access is required, network authen-
tication will allow the user to access needed network services and resources. In this section, we’ll
review both of these processes briefly.
Interactive Logon
A network user performs an interactive logon when presenting valid network credentials to the
operating system of the physical computer the user is attempting to logon to—usually a desktop
workstation.The logon name and password can either be a local user account or a domain account.
Accounts stored in a SAM database can only be used for access to that specific computer.
When using a domain account, the user’s logon information is authenticated against the Active
Directory database.This allows the user to gain access to not only the local workstation but also to
all resources he or she has been granted permission to use in the domain and any trusting domains.
Network Authentication
Once a user has gained access to a physical workstation, it’s almost inevitable that the user will
require access to files, applications, or services hosted by other machines on the LAN or WAN.
Network authentication is the mechanism that confirms the user’s identity to whatever network

resource the user attempts to access. Windows Server 2003 provides several mechanisms to enable
this type of authentication, including Kerberos and NTLM.
The mechanism used depends on the configuration of the network and the operating systems
involved. Because this happens in the background, the network authentication process is transparent
to users in an Active Directory environment.The network operating system handles everything
behind the scenes without the need for user intervention.This feature provides the foundations for
single sign-on in a Windows Server 2003 environment by allowing users to access resources in their
own domains as well as other trusted domains.
438 Chapter 11 • Creating User and Group Strategies
301_BD_W2k3_11.qxd 5/12/04 12:30 PM Page 438
Authentication Types
Windows Server 2003 offers several different authentication types to meet the needs of a diverse
user base.The default authentication protocol for a homogeneous Windows 2000 or later environ-
ment is Kerberos version 5.This protocol relies on a system of tickets to verify the identity of net-
work users, services, and devices. For Web applications and users, you can rely on the
standards-based encryption offered by the SSL/TLS security protocols as well as Microsoft Digest.
To provide backward compatibility for earlier versions of Microsoft operating systems, Windows
Server 2003 provides support for the NTLM protocol. In this section, we examine the various
authentication options available to you as a Windows administrator.
Kerberos
Within a Windows Server 2003 domain, the primary authentication protocol is Kerberos version 5.
Kerberos provides thorough authentication by verifying not only the identity of network users but
also the validity of the network services themselves.This latter feature was designed to prevent users
from attaching to “dummy” services created by malicious network attackers to trick users into
revealing their passwords or other sensitive information.The process of verifying both the user and
the service that the user is attempting to use is referred to as mutual authentication. Only network
clients and servers that are running the Windows 2000, Windows Server 2003, or Windows XP
Professional operating system will be able to use the Kerberos authentication protocol. When these
operating systems are members of a domain, Kerberos will be enabled as their default authentication
mechanism for domain-based resources. In a Windows 2000 or later Active Directory environment,

pre-Windows 2000 computers that attempt to access a “Kerberized” resource will be directed to use
NTLM authentication.
The Kerberos authentication mechanism relies on a Key Distribution Center (KDC) to issue
tickets that allow client access to network resources. Each domain controller in a Windows Server
2003 domain functions as a KDC. Network clients use DNS to locate the nearest available KDC so
that they can acquire a ticket. Kerberos tickets contain cryptographic information that confirms the
user’s identity to the requested service.
These tickets remain resident on the client computer system for a specific amount of time, usu-
ally 10 hours.This ticket lifetime keeps the Kerberos system from being overwhelmed, and is config-
urable by an administrator. If you set the threshold lower, you must ensure that your domain
controllers can handle the additional load that will be placed on them. It is also important, however,
not to set them too high. A ticket is good until it expires, which means that if it becomes compro-
mised it will be valid until expiration.
Understanding the Kerberos Authentication Process
When a user enters his or her network credentials on a Kerberos-enabled system, the following steps
take place.These transactions occur entirely behind the scenes.The user is only aware that he or she
has entered the password or PIN number (if using a smart card) as part of a normal logon process.
The following steps occur in a single domain environment:
Creating User and Group Strategies • Chapter 11 439
301_BD_W2k3_11.qxd 5/12/04 12:30 PM Page 439
1. Using a smart card or a username/password combination, a user authenticates to the KDC.
The KDC issues a ticket-granting ticket (TGT) to the client system.The client retains this
TGT in memory until needed.
2. When the client attempts to access a network resource, it presents its TGT to the ticket-
granting service (TGS) on the nearest available Windows Server 2003 KDC.
3. If the user is authorized to access the service that it is requesting, the TGS issues a service
ticket to the client.
4. The client presents the service ticket to the requested network service.Through mutual
authentication, the service ticket proves the identity of the user as well as the identity of
the service.

The Windows Server 2003 Kerberos authentication system can also interact with non-Microsoft
Kerberos implementations such as UNIX-based Kerberos realms. In Kerberos, a realm is similar to
the concept of a domain.This “realm trust” feature allows a client in a Kerberos realm to authenti-
cate against Active Directory to access resources, and vice versa.This interoperability allows
Windows Server 2003 domain controllers to provide authentication for client systems running other
types of Kerberos, including clients that are running operating systems other than Windows. It also
allows Windows-based clients to access resources within a non-Windows Kerberos realm.
Secure Sockets Layer/Transport Layer Security
Any time you visit a Web site that uses an https:// prefix instead of http://, you’re seeing Secure
Sockets Layer (SSL) encryption in action. SSL provides encryption for other protocols such as HTTP,
LDAP, and IMAP, which operate at higher layers of the protocol stack. SSL provides three major
functions in encrypting TCP/IP-based traffic:
■
Server authentication Allows a user to confirm that an Internet server is really the
machine that it is claiming to be. It’s difficult to think of anyone who wouldn’t like the
assurance of knowing that he or she is looking at the genuine Amazon.com site, and not a
duplicate created by a hacker, before entering any credit card information.
■
Client authentication Allows a server to confirm a client’s identity during the exchange
of data. For example, this might be important for a bank that needs to transmit sensitive
financial information to a server belonging to a subsidiary office. Combining server and
client authentication provides a means of mutual authentication.
■
Encrypted connections Allow all data that is sent between a client and server to be
encrypted and decrypted, allowing for a high degree of confidentiality.This function also
allows both parties to confirm that the data was not altered during transmission.
The Transport Layer Security (TLS) protocol is currently under development by the Internet
Engineering Task Force (IETF). It will eventually replace SSL as a standard for securing Internet
traffic while remaining backward compatible with earlier versions of SSL. RFC 2712 describes the
way to add Kerberos functionality to the TLS suite, which will potentially allow Microsoft and other

vendors to extend its use beyond LAN/WAN authentication, to use on the Internet as a whole.
440 Chapter 11 • Creating User and Group Strategies
301_BD_W2k3_11.qxd 5/12/04 12:30 PM Page 440
SSL and TLS can use a wide range of ciphers (authentication, encryption, and/or integrity
mechanisms) to allow connections with a diverse client base.You can edit the Registry in Windows
Server 2003 to restrict the ciphers allowed. Within the Registry Editor on the server, browse to the
following key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANN
EL\Ciphers, as shown in Figure 11.6. Each available cipher has two potential values:
■
0xffffffff (enabled)
■
0x0 (disabled)
NT LAN Manager
Versions of Windows earlier than Windows 2000 used NT LAN Manager (NTLM) to provide net-
work authentication. In a Windows Server 2003 environment, NTLM is used to communicate
between two computers when one or both of them is running a pre-Windows 2000 operating
system. NTLM will also be used by Windows Server 2003 computers that are not members of a
domain. NTLM encrypts user logon information by applying a mathematical function (or hash) to
the user’s password. A user’s password isn’t stored in the SAM or Active Directory database. Rather,
the value of a hash that is generated when the user’s account is first created or the user’s password is
changed, is stored. If the password is less than 15 characters long, two hashes are actually stored: an
NT hash and a LM hash.The LM (or LAN Manager) hash is weak and can easily be broken by
password crackers. Because of this it is recommended that you configure the Network security:
Do not store LAN Manager hash value on next password change Group Policy setting.
During logon, the domain controller sends a challenge to the client.This is a simple string of
characters that the client mathematically applies to the hash value of the user’s password.The result
of this mathematical algorithm is a new hash that is then transmitted to the domain controller. In
this way, the user’s password is never actually transmitted across the network.
Creating User and Group Strategies • Chapter 11 441

Figure 11.6 Editing SSL/TLS Ciphers
301_BD_W2k3_11.qxd 5/12/04 12:30 PM Page 441
The domain controller also has the hash for the user’s password. Moreover, it knows the chal-
lenge it sent, so it is able to perform the same calculation. It compares the hash that it mathemati-
cally calculated with the one received from the client. If they match, logon is permitted.
The NTLM hash function only exists in Windows Server 2003 for backward compatibility with
earlier operating systems. Windows Server 2003 domains support both NTLM and NTLM version
2. If your network environment is exclusively running Windows 2000 or later, you might want to
consider standardizing on a stronger form of authentication such as Kerberos. Using NTLM is
preferable to sending authentication information using no encryption whatsoever, but NTLM has
several known vulnerabilities that do not make it the best choice for network authentication if your
operating system supports more advanced schemes.
Digest Authentication
Microsoft provides digest authentication as a means of authenticating Web applications that are running
on IIS. Digest authentication uses the Digest Access Protocol, which is a simple challenge-response mech-
anism for applications that are using HTTP or Simple Authentication Security Layer (SASL) based com-
munications. When Microsoft Digest authenticates a client, it creates a session key that is stored on the
Web server and used to authenticate subsequent authentication requests without needing to contact a
domain controller for each authentication request. Similar to NTLM, digest authentication sends user
credentials across the network as an encrypted hash so that the actual password information cannot be
extracted in case a malicious attacker is attempting to “sniff ” the network connection.
Passport Authentication
Any business that wants to provide the convenience of single sign-on to its customers can license
and use Microsoft Passport authentication. Passport authentication enables your company to provide
a convenient means for customers to access and transact business on a given Web site. Sites that rely
on Passport authentication use a centralized Passport server to authenticate users, rather than hosting
and maintaining their own authentication systems. From a technical perspective, Passport authenti-
cation relies on standards-based Web technologies, including SSL, HTTP redirects, and cookies.
Educating Users
The more highly publicized network security incidents always seem to center on a technical flaw:

an overlooked patch that led to a global denial-of-service (DoS) attack, a flaw that led to the world-
wide propagation of an e-mail virus, or something similar. However, many network intrusions are
caused by a lack of knowledge among corporate employees. For this reason, user education is a crit-
ical component of any security plan. Make sure that your users understand the potential dangers of
sharing their logon credentials with anyone else or leaving that information in a location where
others could take note of it.Your users will be far more likely to cooperate and comply with corpo-
rate security standards if they understand the reasons behind the policies and the damage that they
can cause by ignoring security measures. By combining user education with technical measures,
such as password policies and strong network authentication, you will be well on your way to cre-
ating multiple layers of protection for your network and the data it contains.
442 Chapter 11 • Creating User and Group Strategies
301_BD_W2k3_11.qxd 5/12/04 12:30 PM Page 442
Smart Card Authentication
Smart cards provide a portable method of providing security on a network for tasks like client authen-
tication and securing user data. Smart cards and smart card authentication are discussed in detail in the
chapter “Planning, Implementing, Maintaining Public Key Infrastructure, later in this book.
Using a smart card for network logons provides extremely strong authentication because it
requires two factors: something the user knows (the PIN), and something the user has (the smart card
itself ).This system provides stronger authentication than a password alone, since a malicious user
would need to have access to both the smart card and the PIN in order to impersonate a legitimate
user. It’s also difficult for an attacker to perform a smart card attack undetected, because the user
would notice that his or her smart card was physically missing.
Planning a Security Group Strategy
As discussed in Chapter 10, a set of default groups is created during the installation of Windows
Server 2003 on a computer.These groups reside in the local SAM database of the stand-alone or
member server, and can only be granted rights and permissions on that computer. Domain con-
trollers also have a set of default groups.These groups reside within the Active Directory database
structure and can be used throughout the domain.
You aren’t limited to using the default groups. Windows Server 2003 allows you to create your
own groups both at the SAM and Active Directory database levels.This book deals with Active

Directory, so we will assume that you are working in a Windows Server 2003 Active Directory
environment when we discuss planning group strategy.
Security Group Best Practices
Microsoft has a number of different recommended methods for using groups in a domain environ-
ment.You should expect to be asked a number of complex questions about the appropriate use of
groups. Most of their recommendations fall into one of two models:
■
A single domain forest
■
A multiple domain forest
Designing a Group Strategy for a Single Domain Forest
AGDLP.This simple acronym sums up everything you need to remember for the use of groups in a
single domain forest environment. Each of the letters has a specific meaning:
■
A Accounts
■
G Global groups
■
DL Domain local groups
■
P Permissions
Creating User and Group Strategies • Chapter 11 443
301_BD_W2k3_11.qxd 5/12/04 12:30 PM Page 443
The acronym can be read as: Accounts (user and computer objects) are placed into Global
groups, which are placed into Domain Local groups, which are added to ACLs and granted
Permissions to a resource.
Consider this scenario:You have a new employee who is joining the benefits team within a
company.The new user needs to access to both benefits-related resources and all general HR
resources.Therefore, you add the user into both the Benefits and HR global groups.These global
groups are themselves members of domain local groups, one of which is illustrated in Figure 11.7.

The HR global group is a member of the HR_Print domain local group.This group is used to
grant access to the general printers that all members of the HR department are allowed to use.
When the domain functional level is elevated to Windows 2000 native or Windows Server
2003, Microsoft specifies a new group model, AGGDLP.The meaning of the letters does not
change.Therefore, this model means: Accounts are placed into Global groups that can be placed
into other Global groups and/or Domain Local groups, which are added to ACLs and granted
Permissions to resources.This can make a huge difference, because it allows you to potentially
reduce the number of groups that you have to add a new user to.
Consider the example used previously. If you nest the Benefits global group into the HR global
group, you gain a tremendous advantage. When a new user joins the benefits team, you only have to
add that user’s account to a single user group, Benefits. Because this group is also a member of the
HR global group, the user will receive all of the permissions and rights assignments associated with
both groups. Figure 11. 8 shows the AGGDLP model.
444 Chapter 11 • Creating User and Group Strategies
Figure 11.7 AGDLP in a Single Domain Forest
Syngress.com
HR
global
group
Benefits
global
group
New User
HR_Print
domain
local
group
Printer
301_BD_W2k3_11.qxd 5/12/04 12:30 PM Page 444
Designing a Group Strategy for a Multiple Domain Forest

These existing models can also be extended to a multiple domain forest. In a Windows 2000 mixed
functional level domain, it takes quite a few resource assignments to grant permissions across
domains. Extending the previous example, two additional domains will be added. Each domain is for
a different region of the world, and each has an HR department.The company needs all HR
employees to be able to access files that are located in the North America office. Because the
domain is at the Windows 2000 mixed functional level, the AGDLP model is used.
Again, a new user joins the benefits team, this time in the Europe domain.The user is added to
the Benefits and HR global groups in the Europe domain.The HR global group in each domain
has also been added to the Global_HR_Resources domain local group in the North America
Domain.The Global_HR_Resources DLG has been granted the necessary permissions on the ACL
for the files. Because all HR employees are (directly or indirectly) members of the HR global group
in their domain, and each HR global group is a member of the Global_HR_Resources domain
local group, they all have permission to access the required files.These complex relationships are
shown in Figure 11.9.
Creating User and Group Strategies • Chapter 11 445
Figure 11.8 AGGDLP in a Single Domain Forest
Syngress.com
HR
global
group
Benefits
global
group
New User
HR_Print
domain
local
group
Printer
301_BD_W2k3_11.qxd 5/12/04 12:30 PM Page 445