tm

The Definitive Guide To

Windows 2000
Security
Paul Cooke

Introduction

Introduction
By Sean Daily, Series Editor
Welcome to The Definitive Guide to Windows 2000 Security!
The book you are about to read represents an entirely new modality of book publishing and a
major first in the publishing industry. The founding concept behind Realtimepublishers.com is
the idea of providing readers with high-quality books about todays most critical IT topicsat no
cost to the reader. Although this may sound like a somewhat impossible feat to achieve, it is
made possible through the vision and generosity of corporate sponsors who agree to bear the
books production expenses and host the book on their Web sites for the benefit of their Web site
visitors.
It should be pointed out that the free nature of these books does not in any way diminish their
quality. Without reservation, I can tell you that this book is the equivalent of any similar printed
book you might find at your local bookstore (with the notable exception that it wont cost you
$30 to $80). In addition to the free nature of the books, this publishing model provides other
significant benefits. For example, the electronic nature of this eBook makes events such as
chapter updates and additions, or the release of a new edition of the book possible to achieve in a
far shorter timeframe than is possible with printed books. Because we publish our titles in realtimethat is, as chapters are written or revised by the authoryou benefit from receiving the
information immediately rather than having to wait months or years to receive a complete
product.
Finally, Id like to note that although it is true that the sponsors Web site is the exclusive online
location of the book, this book is by no means a paid advertisement. Realtimepublishers is an
independent publishing company and maintains, by written agreement with the sponsor, 100%
editorial control over the content of our titles. However, by hosting this information, the sponsor
sets itself apart from its competitors by providing real value to its customers and transforming its
site into a true technical resource librarynot just a place to learn about its company and
products. It is my opinion that this system of content delivery is not only of immeasurable value
to readers, but represents the future of book publishing.
As series editor, it is my raison dtre to locate and work only with the industrys leading authors
and editors, and publish books that help IT personnel, IT managers, and users to do their
everyday jobs. To that end, I encourage and welcome your feedback on this or any other book in
the Realtimepublishers.com series. If you would like to submit a comment, question, or
suggestion, please do so by sending an email to feedback@realtimepublishers.com, leaving
feedback on our Web site at www.realtimepublishers.com, or calling us at (707) 539-5280.
Thanks for reading, and enjoy!
Sean Daily
Series Editor

Table of Contents
Introduction...................................................................................................................................... i
Chapter 1: Overview of Windows 2000 and Security .....................................................................1
My Mission ......................................................................................................................................1
What Is Windows 2000?..................................................................................................................2
What Is New in Windows 2000? .....................................................................................................3
Active Directory...................................................................................................................4
Security in Active Directory ....................................................................................6
Domain Controllers..............................................................................................................7
Public Key Infrastructure.....................................................................................................7
Certificate Authority ................................................................................................8
Broad Certificate Use...............................................................................................8
Group Policy ........................................................................................................................9
Security Groups .................................................................................................................10
Kerberos.............................................................................................................................11
Encrypting File System......................................................................................................12
Routing & Remote Access Service....................................................................................12
Smart Cards........................................................................................................................13
Pure TCP/IP .......................................................................................................................13
Security Primer ..............................................................................................................................14
Security Framework...........................................................................................................14
Organizational Factors ...........................................................................................15
Security Objectives ................................................................................................16
Security Mechanisms .............................................................................................16
Relating to the Security Framework ......................................................................17
Philosophy of Protection....................................................................................................17
Security Is Embedded (Security Is Everywhere, but Nowhere to Be Seen)..........17
Security Is Centralized Logically but Distributed Globally ..................................17
Security Is Applied to Multiple Layers..................................................................18
Security Is an Enabler, Not a Roadblock ...............................................................18
Security Concepts ..............................................................................................................18
Need-to-Protect ......................................................................................................18
Least Privilege .......................................................................................................19
Separation of Duties...............................................................................................19

ii

Table of Contents
Defense in Depth....................................................................................................19
Role-Based Access Control ...................................................................................19
Identification ..........................................................................................................19
Authentication........................................................................................................20
Authorization .........................................................................................................20
Access Control .......................................................................................................20
Non-Repudiation....................................................................................................20
Security Principles .............................................................................................................20
What Does This All Mean?................................................................................................21
Summary ........................................................................................................................................21
Chapter 2: Managing Active Directory Security ...........................................................................22
Directory Services Primer..............................................................................................................22
What Is a Directory Service? .............................................................................................22
Why Do We Need a Directory Service? ............................................................................23
Why Active Directory? ......................................................................................................23
Windows 2000 Architecture ..........................................................................................................24
System Architecture...........................................................................................................24
Security Subsystem............................................................................................................26
Object Manager......................................................................................................27
Security Reference Monitor...................................................................................27
Event Logger..........................................................................................................28
Local Security Authority........................................................................................28
Active Directory Architecture........................................................................................................31
Lightweight Directory Access Protocol.............................................................................32
Domain Name Service .......................................................................................................32
Relationship with Active Directory .......................................................................33
Service Location Resource Records ......................................................................34
DHCP and Dynamic DNS .....................................................................................35
Domain Controllers............................................................................................................35
Objects ...............................................................................................................................36
Domains .............................................................................................................................37
Mixed-Mode versus Native-Mode Domains .........................................................38
Domain Trees and Forests .....................................................................................39

iii

Table of Contents
Domain Trusts........................................................................................................41
Organizational Units ..............................................................................................43
Administrative Privileges...................................................................................................43
Sites....................................................................................................................................45
Multimaster Replication.....................................................................................................45
Data Partitions........................................................................................................45
How It Works.........................................................................................................46
The Global Catalog ................................................................................................47
Operational Roles...................................................................................................48
Active Directory Tools and Troubleshooting ................................................................................49
Administration Tools .........................................................................................................49
Delegation of Control Wizard............................................................................................49
Backup, Restore, and Disaster Recovery...........................................................................50
Basic Troubleshooting .......................................................................................................51
Active Directory Best Practices .....................................................................................................52
Native-Mode Domains.......................................................................................................52
Domain Forests ..................................................................................................................53
Domains and Domain Trees...............................................................................................53
Organizational Units ..........................................................................................................54
Overall Design ...................................................................................................................54
Delegated Administration ..................................................................................................57
Securing DHCP and DNS..................................................................................................58
Active Directory Security Vulnerabilities .....................................................................................59
Summary ........................................................................................................................................60
Chapter 3: Managing Group Policy Security.................................................................................61
How Did Group Policy Come About? ...........................................................................................62
Starting with the System Policy Editor..............................................................................62
Developing into Group Policy Objects ..............................................................................63
How Does Group Policy Work? ....................................................................................................63
The Globally Unique Identifier..........................................................................................64
Group Policy Containers....................................................................................................64
Group Policy Templates ....................................................................................................64
Group Policy Processing on the Clients.............................................................................66

iv

Table of Contents
Group Policy and Active Directory ...............................................................................................66
Group Policy Assignment ..................................................................................................67
Group Policy Processing and Inheritance ..........................................................................67
Blocking Group Policy Inheritance .......................................................................70
Stopping a GPO from Overriding Settings ............................................................71
Filtering Group Policy Using Security Groups......................................................72
Ignoring Certain Group Policy Settings.............................................................................73
Group Policy Access Control Lists....................................................................................74
What Can I Configure Using Group Policy? .................................................................................75
Security Settings ................................................................................................................76
Account Policies | Password Policies ....................................................................76
Account Policies | Account Lockout Policy ..........................................................77
Account Policies | Kerberos Policy........................................................................78
Local Policies | Audit Policy..................................................................................78
Local Policies | User Rights Assignments .............................................................79
Local Policies | Security Options...........................................................................80
Event Log | Settings for Event Logs ......................................................................83
Applying Group Policy to Stand-Alone Computers ......................................................................84
Using Local Group Policy versus AD-Based Group Policy..............................................84
Overriding Local Group Policy .........................................................................................85
Using Local Group Policy with NT 4.0 Domain Controllers ............................................85
Extending Group Policy.................................................................................................................85
Group Policy Tools and Troubleshooting......................................................................................86
Group Policy Editor ...........................................................................................................87
Group Policy Resultant Set of Policies Tool .....................................................................88
Group Policy Object Verification Tool..............................................................................90
Group Policy Best Practices...........................................................................................................91
Group Policy Considerations .............................................................................................91
Discontinuing Using NT 4.0 System Policy ..........................................................91
Designing the Active Directory Structure..............................................................91
Blocking Policy Inheritance...................................................................................92
Forcing Policy Inheritance.....................................................................................92
Restricting the Number of GPOs ...........................................................................92

Table of Contents
Filtering GPOs Using Security Groups..................................................................92
Applying User-Based versus Computer-Based GPO Settings...............................92
Assigning GPOs Across Domains .........................................................................92
Administering GPOs..............................................................................................93
Using a Top-Down Approach............................................................................................93
Understanding Resultant Policies ......................................................................................93
Defining Local GPOs for Stand-Alone Computers Only ......................................93
Using Site GPOs for Items Dependent on Network Location ...............................93
Using Domain GPOs for Major Items ...................................................................93
Using OU GPOs to Refine Domain GPOs ............................................................94
Creating Security-Specific GPOs ..........................................................................94
Defining Security GPOs Based on Roles...............................................................94
Restricting Administrative Access to Security GPOs............................................94
Giving Up Registry Editors ...................................................................................94
Summary ........................................................................................................................................95
Chapter 4: Understanding Authentication .....................................................................................96
What It Is........................................................................................................................................96
Authenticating Users..........................................................................................................96
Authenticating in Windows 2000 ......................................................................................97
Using Kerberos V5: The New Authentication Scheme .................................................................97
Advantages over NTLM ....................................................................................................99
High-Level Overview ......................................................................................................100
What Makes It Work........................................................................................................101
Authenticators Provide Mutual Authentication ...................................................102
Distributing Keysthe Issues .............................................................................104
Distributing Keys Using Session Tickets ............................................................105
Using Ticket-Granting Tickets ............................................................................107
Understanding the Key Distribution Center ....................................................................108
Authentication Service and Ticket-Granting Service ..........................................108
Account Database ................................................................................................108
Its Three Sub-Protocols....................................................................................................109
Authentication Service Exchange ........................................................................109
Ticket-Granting Service Exchange ......................................................................110

vi

Table of Contents
Client/Server Exchange .......................................................................................111
Inter-Domain Authentication ...........................................................................................112
In a Forest with Two Domains.............................................................................112
In a Forest with More Than Two Domains..........................................................113
Everything You Wanted to Know about Tickets.............................................................114
Calculating Their Lifespan ..................................................................................115
Delegating Authentication with Kerberos ...........................................................116
Configuring Kerberos ......................................................................................................117
Using NTLM: Down-Level Compatibility ..................................................................................119
Configuring LAN Manager Authentication.....................................................................120
Using Secondary Authentication .................................................................................................121
Starting the Runas Command ..........................................................................................121
In Windows Explorer...........................................................................................121
From the Command Line .....................................................................................122
Command-Line Syntax ....................................................................................................123
Taking Advantage of Runas.............................................................................................123
Using Smart Card Authentication................................................................................................124
Logging On Using a Smart Card .....................................................................................125
Before You Deploy Smart Cards .....................................................................................126
Using Other Authentication Schemes..........................................................................................126
Biometric Authentication.................................................................................................126
Internet Information Services ..........................................................................................127
Authentication Tools and Troubleshooting .................................................................................127
Kerberos Ticket Tool .......................................................................................................127
Network Domain Manager ..............................................................................................128
Domain Monitor...............................................................................................................129
Common Kerberos Errors ................................................................................................130
Authentication Best Practices ......................................................................................................131
Summary ......................................................................................................................................131
Chapter 5: Configuring Access Control.......................................................................................132
The Windows 2000 Access Control Model .................................................................................132
The Five Principles of Access Control ............................................................................132
User-Based Authorizations ..................................................................................133

vii

Table of Contents
Discretionary Access Control ..............................................................................133
Inheritance of Permissions...................................................................................134
Administrative Privileges.....................................................................................134
Auditing of System Events ..................................................................................134
How Access Control Works.........................................................................................................134
SIDs..............................................................................................................................................137
SIDs versus GUIDs..........................................................................................................137
Where Win2K Uses SIDs ................................................................................................139
The Structure of a SID .....................................................................................................139
RIDs and the RID Master Role............................................................................141
Well-Known SIDs............................................................................................................142
Access Rights...............................................................................................................................143
Access Permissions..........................................................................................................143
NTFS Permissions ...............................................................................................144
AD Permissions ...................................................................................................146
Miscellaneous Permissions ..................................................................................150
User Rights.......................................................................................................................150
Permissions versus Privileges ..........................................................................................152
Security Groups ...........................................................................................................................152
Additional Distribution Groups .......................................................................................152
Additional Group Scopes.................................................................................................153
Nesting Groups ................................................................................................................153
ACLs ............................................................................................................................................154
Structure of an ACL.........................................................................................................154
Access Control Entries.....................................................................................................155
The Structure of an ACE......................................................................................155
ACE Inheritance...................................................................................................157
Security Descriptors.....................................................................................................................159
Access Tokens .............................................................................................................................161
Impersonation ..................................................................................................................162
Impersonation Access Tokens .........................................................................................162
Restricted Access Tokens ................................................................................................163
Tying It All Together ...................................................................................................................164

viii

Table of Contents
Access Control Best Practices .....................................................................................................165
Group Considerations ......................................................................................................166
Group Best Practices........................................................................................................167
User Rights Assignments.................................................................................................167
Summary ......................................................................................................................................168
Chapter 6: Managing Auditing ....................................................................................................169
Developing an Effective Auditing Strategy.................................................................................170
Identifying the Three Types of Auditing .........................................................................170
Preparing to Audit............................................................................................................171
Making Auditing Consistent with Security Policy ..............................................171
Trading Off Information against System Performance........................................171
Using the Event Logging Service ................................................................................................173
The Six Audit Logs..........................................................................................................173
Application Log ...................................................................................................174
System Log ..........................................................................................................174
Security Log.........................................................................................................175
Directory Service Log..........................................................................................175
DNS Server Log...................................................................................................176
File Replication Service Log ...............................................................................176
Reading the Event Log Files............................................................................................176
Configuring the Event Logs.............................................................................................178
Filtering the Event Logs...................................................................................................180
Event Record Format .......................................................................................................181
Event Types .....................................................................................................................183
Backing Up Event Logs ...................................................................................................183
Controlling Access to Event Logs ...................................................................................185
Setting a Basic Audit Policy ........................................................................................................186
Auditing Objects ..........................................................................................................................188
Files and Folders ..............................................................................................................188
Printers .............................................................................................................................189
The Registry.....................................................................................................................190
Directory Services............................................................................................................191
Examining Security Event Records .............................................................................................192

ix

Table of Contents
Recommended Auditing Configurations .....................................................................................193
Event Log Properties........................................................................................................193
System Audit Policy ........................................................................................................194
File System Object Auditing............................................................................................194
Printer Object Auditing....................................................................................................195
Registry Object Auditing .................................................................................................195
Directory Services Object Auditing.................................................................................196
Summary ......................................................................................................................................196
Chapter 7: Managing Security Configuration..............................................................................197
Understanding the Security Configuration Tool Set....................................................................197
SCTS Background ...........................................................................................................197
SCTS Features .................................................................................................................198
SCTS Architecture ...........................................................................................................198
Using Security Templates ............................................................................................................200
Predefined Security Templates ........................................................................................201
Default Security Templates..................................................................................202
Basic Security Templates.....................................................................................202
Incremental Security Templates ..........................................................................203
Miscellaneous Security Templates ......................................................................204
A Word of Caution...............................................................................................204
How Security Templates Relate to Security Databases and Policies ..............................204
Using the Security Templates MMC Snap-In..............................................................................205
Configuring Security Settings..........................................................................................206
Account Policies ..................................................................................................206
Local Policies.......................................................................................................207
Event Log Settings...............................................................................................208
Restricted Groups.................................................................................................209
System Services ...................................................................................................210
Registry Security..................................................................................................211
File System Security ............................................................................................213
Using the Security Configuration and Analysis MMC Snap-In ..................................................213
Analyzing the Security of a Computer.............................................................................215
Configuring the Security of a Computer..........................................................................217

Table of Contents
Using the Security Editor.............................................................................................................218
Advantages Over the Security Configuration and Analysis Snap-In...............................219
Analyzing Security in Your Environment .......................................................................219
Implementing Security Configuration .........................................................................................220
Identifying the Four Basic Roles of Computers ..............................................................220
Domain Controllers..............................................................................................221
Member Servers ...................................................................................................221
Workstations ........................................................................................................221
Restructuring Roles..........................................................................................................222
Identifying the Fourth RoleOverall Domain Security .................................................222
Defining Security Settings ...............................................................................................222
For Account Policy ..............................................................................................223
For Local Policies ................................................................................................223
For the Event Log ................................................................................................226
For Restricted Groups ..........................................................................................227
For System Services.............................................................................................228
For the Registry and File System.........................................................................228
Using Group Policy..............................................................................................228
Summary ......................................................................................................................................229
Chapter 8: Public Key InfrastructurePart 1..............................................................................230
Recognizing Security Issues ........................................................................................................230
How PKI Addresses These Issues................................................................................................231
Understanding Cryptography.......................................................................................................232
Secret Key Cryptography.................................................................................................232
Public Key Cryptography ................................................................................................233
Hash Functions.................................................................................................................235
Digital Signatures.............................................................................................................235
Putting Cryptography into Practice..................................................................................236
Understanding PKI.......................................................................................................................237
Certificates .......................................................................................................................238
Certificate Authority ........................................................................................................239
Certificate Repository ......................................................................................................240
PKI Applications..............................................................................................................240

xi

Table of Contents
Certificate Trust Models ..............................................................................................................240
Cross-Certification...........................................................................................................241
Bilateral Cross-Certification ................................................................................241
Certificate Trust Lists ..........................................................................................242
Disadvantages ......................................................................................................242
Certificate Hierarchies .....................................................................................................242
Advantages...........................................................................................................243
Disadvantages ......................................................................................................243
Communities of Interest...................................................................................................244
Recommended Trust Relationships .................................................................................245
Validating and Revoking Certificates..........................................................................................246
Validating.........................................................................................................................246
Revoking ..........................................................................................................................248
Certificate Life Cycles .................................................................................................................248
Choosing Certificate Life Cycles.....................................................................................249
The Legal Ramifications of PKI ..................................................................................................250
The Certificate Practice Statement...................................................................................250
Creating a CPS.....................................................................................................251
The E-Sign Act ................................................................................................................252
The Windows 2000 PKI...............................................................................................................252
Certificate Services ..........................................................................................................253
Certificate Templates .......................................................................................................254
Configuring Certificate Templates ......................................................................255
Certificate Services Policy and Exit Modules .................................................................256
Policy Modules ....................................................................................................257
Exit Modules........................................................................................................257
Installing Certificate Services ..........................................................................................257
Having the Required Access................................................................................258
Using the Windows Components Wizard............................................................258
Describing the CA................................................................................................259
Specifying the Lifespan of the CA Certificate.....................................................259
Specifying Other Information ..............................................................................259
Administering Certificate Services ..................................................................................260

xii

Table of Contents
Hardware Protection of Private Keys ..........................................................................................260
Summary ......................................................................................................................................261
Chapter 9: Public Key InfrastructurePart 2..............................................................................262
Managing Certificates..................................................................................................................262
Configuring Group Policy Settings..................................................................................263
Encrypted Data Recovery Agents........................................................................264
Automatic Certificate Request Settings ...............................................................264
Trusted Root Certification Authorities and Enterprise Trust...............................264
Using the Certificates MMC Snap-In ..............................................................................265
Using the Certificate Services Web Pages.......................................................................266
Using CertReq.exe ...........................................................................................................268
Sending and Receiving Secure Email ..........................................................................................269
Configuring Outlook Express ..........................................................................................270
Sending S/MIME Messages.............................................................................................272
How the EFS Works ....................................................................................................................273
Encrypting Files ...............................................................................................................273
Recovering Files ..............................................................................................................274
Using EFS ........................................................................................................................275
With Windows Explorer ......................................................................................276
With Cipher.exe ...................................................................................................277
With Efsinfo.exe ..................................................................................................277
Recovering Encrypted Files.............................................................................................278
Keeping Protected Files Protected ...................................................................................279
EFS Limitations ...............................................................................................................280
Issuing Smart Cards .....................................................................................................................280
Using Software Signing and Authenticode..................................................................................282
Applying Internet Protocol Security ............................................................................................282
Why You Need It .............................................................................................................283
IPSec Services..................................................................................................................284
The Four Modes of Operation..........................................................................................285
Using Predefined Configurations.....................................................................................285
Creating an IPSec Policy .................................................................................................287
Configuring Rules................................................................................................288

xiii

Table of Contents
Configuring Filters...............................................................................................288
Configuring Filter Actions...................................................................................289
Using Virtual Private Networks...................................................................................................289
Summary ......................................................................................................................................290
Chapter 10: Internet Information Services...................................................................................291
Authentication..............................................................................................................................291
Anonymous Authentication .............................................................................................292
Basic Authentication........................................................................................................292
Digest Authentication ......................................................................................................292
Integrated Windows Authentication ................................................................................293
Certificate Authentication................................................................................................293
Access Control .............................................................................................................................293
Network Address Access Control....................................................................................295
IIS Access Control ...........................................................................................................296
NTFS Access Control ......................................................................................................297
Permissions Wizard .........................................................................................................297
Auditing .......................................................................................................................................298
IIS Auditing .....................................................................................................................298
Administrative Security ...............................................................................................................301
Web Administration.........................................................................................................302
SSL...............................................................................................................................................302
Protocol Basics.................................................................................................................303
SSL Cryptographic Algorithms .......................................................................................304
SSL Handshake Subprotocol ...........................................................................................305
Server Authentication Process .........................................................................................306
Client Authentication Process..........................................................................................308
Enabling SSL ...................................................................................................................310
SSL Configuration ...........................................................................................................311
Client Certificate Mappings.............................................................................................313
SSL Summary ..................................................................................................................316
Best Practices ...............................................................................................................................316
Software Installation ........................................................................................................317
Remove Unnecessary Subsystems...................................................................................319

xiv

Table of Contents
Configure the Logon Screen and Desktop .......................................................................320
Configure the Account and Audit Policies ......................................................................320
Configure User Rights .....................................................................................................321
Configure System Services ..............................................................................................323
Configuring the Network .................................................................................................325
Move System Binaries .....................................................................................................326
Miscellaneous Configurations .........................................................................................328
Secure IIS.........................................................................................................................330
Alternative Best Practices ................................................................................................331
Summary ......................................................................................................................................332

xv

Copyright Statement

Copyright Statement
2004 Realtimepublishers.com, Inc. All rights reserved. This site contains materials that
have been created, developed, or commissioned by, and published with the permission
of, Realtimepublishers.com, Inc. (the Materials) and this site and any such Materials are
protected by international copyright and trademark laws.
THE MATERIALS ARE PROVIDED AS IS WITHOUT WARRANTY OF ANY KIND,
EITHER EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO, THE IMPLIED
WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE,
TITLE AND NON-INFRINGEMENT. The Materials are subject to change without notice
and do not represent a commitment on the part of Realtimepublishers.com, Inc or its web
site sponsors. In no event shall Realtimepublishers.com, Inc. or its web site sponsors be
held liable for technical or editorial errors or omissions contained in the Materials,
including without limitation, for any direct, indirect, incidental, special, exemplary or
consequential damages whatsoever resulting from the use of any information contained
in the Materials.
The Materials (including but not limited to the text, images, audio, and/or video) may not
be copied, reproduced, republished, uploaded, posted, transmitted, or distributed in any
way, in whole or in part, except that one copy may be downloaded for your personal, noncommercial use on a single computer. In connection with such use, you may not modify
or obscure any copyright or other proprietary notice.
The Materials may contain trademarks, services marks and logos that are the property of
third parties. You are not permitted to use these trademarks, services marks or logos
without prior written consent of such third parties.
Realtimepublishers.com and the Realtimepublishers logo are registered in the US Patent
& Trademark Office. All other product or service names are the property of their
respective owners.
If you have any questions about these terms, or if you would like information about
licensing materials from Realtimepublishers.com, please contact us via e-mail at
info@realtimepublishers.com.

xvi

Chapter 1

Chapter 1: Overview of Windows 2000 and Security

It wasnt that long ago that security was an afterthought to almost anything that happened in the
field of computer science. Although computer security was important in government circles, the
business world paid little attention to it. The advent and explosive growth of the Internet has
dramatically changed all that. It seems that security has evolved from something that system
administrators thought about from time to time into something that dedicated professionals in an
enterprise devote themselves to.
With security taking on such a prominent role in many organizations, interest in the security field
has increased dramatically. Consequently, this is a book about securitymore specifically, about
Windows 2000 (Win2K) security. In this book, Ill concentrate on the security issues that
surround Win2K and discuss generic security fundamentals and concepts. When Im finished, I
hope that youll have gained a thorough understanding of Win2K, its security features, and how
to deploy Win2K securely throughout your enterprise. I also hope that youll have adopted the
attitude of a security professional.

My Mission
When setting out to write this book, I asked myself what my motivations were and what I hoped
you, the readers, would get out of it. I had to have a mission and a game plan, decide what to talk
about and what not to talk about. I needed to determine how to filter out the information you
didnt need from the topics that I thought were most important for you to be successful in
providing security for your Win2K environment. That really is the key to this bookhelping you
become successful. My goal, then, is that when youve finished reading this book, youll have
acquired the following skills and knowledge:

A basic understanding of security concepts and terminology

The realization that security should be treated as an attitude rather than a set of checklists

A solid understanding of how Win2K implements security

The ability to design a suitable Win2K environment to maximize security administration

and reduce the probability that youll experience a security breach

The ability to implement and configure the security features of Win2K.

On the surface, these goals seem pretty simple and obtainable. However, Win2K is so large and
complex that Ill undoubtedly not be able to cover it all. Thus, my major focus will be showing
you how to secure Win2K for your internal enterprise environment. The skills and knowledge
you learn will allow you to quickly pick up any of the security concepts and mechanisms that I
dont cover.

Chapter 1

What Is Windows 2000?

The Microsoft Windows 2000 family of products is the next generation of the Windows NT
series of operating systems (OSs). In fact, Win2K is the fifth generation of the OS since its 1993
debut. With Win2K, Microsoft is delivering several kinds of systems.

Windows 2000 Professionalfor the desktop

Windows 2000 Serverfor the workgroup and department servers

Windows 2000 Advanced Serverfor application and more robust department servers

Windows 2000 Datacenter Serverfor mission-critical servers.

Win2K builds on the strengths of NT 4.0 by providing a platform that Microsoft touts as faster,
more reliable, and easier to manage. Win2K is designed to be a multipurpose OS that supports
file and print, application, Web, and communications server functions in addition to workstation
functions. What is perhaps most important, Win2K delivers a comprehensive set of distributed
infrastructure services based on Active Directory (AD).
In my experience, Win2K is a better-performing and more reliable OS than its predecessor NT 4.0.
However, while its easier to manage, the addition of AD is a double-edged sword: the ease of
management is somewhat offset by the complexity of its implementation.

AD is the centerpiece of the new capabilities integrated into Win2K. Its a multipurpose
directory service that is scalable, built from the ground up using Internet-standard technologies,
and fully integrated at the OS level. AD provides the interoperability to unify and manage the
multiple namespaces that exist in the heterogeneous software and hardware environments of
enterprise networks.
By combining the best of the Domain Name System (DNS) and X.500 naming standards,
Lightweight Directory Access Protocol (LDAP), other key protocols, and a set of application
programming interfaces (APIs), AD allows for a single point of administration for all resources,
including files, peripheral devices, host connections, databases, Web access, users, arbitrary
other objects, services, and network resources. AD supports a hierarchical namespace for user,
group, and computer account information, and it can subsume and manage other directories to
provide a general-purpose directory service that can reduce the administrative burdens and costs
associated with maintaining multiple namespaces.
The inclusion of AD in the Win2K OS provides a number of benefits, including integration with
DNS, flexible querying, extensibility, scalability, information replication, interoperability,
policy-based administration, and information security. While these new capabilities will increase
reliability and scalability, reduce costs by improving end-to-end management capabilities, and
provide comprehensive Internet and applications support, its the last two items (policy-based
administration and information security) that are the most interesting for security professionals.
So while there are a lot of things to discuss on the topic of Win2K, my focus is really twofold.
First, Ill cover the fundamentals of NT/Win2K security that are relatively unchanged from
previous versions of the OS. Then Ill focus on the new security features that have been added to
the OS and how they enable policy-based administration and information security. Lets take a
quick tour of the new security features implemented in Win2K.

Chapter 1

What Is New in Windows 2000?

Perhaps its just my own personal slant on things, but from where I sit, many of Win2Ks new
features relate to security in one way or another. So when you start looking at some of the bigger
features such as Kerberos, AD, and integrated support for public key infrastructure (PKI), you
might be tempted to think that when Microsoft implemented Win2K, it replaced most of the
security architecture of NT. In fact, it exploited many of those features. Even with Kerberos, AD,
and PKI, the core of Win2K security builds on NT 4.0s infrastructure. Ill examine the
similarities and differences in later chapters of this book. For now, lets take a quick look at what
is new in Win2K and what these features provide.
In this section, I introduce many concepts and terminology without a lot of explanation. For those of
you already familiar with them, this shouldnt cause a problem. For the rest of you, later chapters of
this book will provide more in-depth discussions.

Before discussing the new security features, its important to understand where Microsoft was
coming from when it approached security in Win2K. We can ask, What thought processes
guided Microsoft in designing Win2K and the new security features? The answer is: Microsoft
used just a few simple design goals.

Integrate AD

Provide for a single logon

Simplify administration

Rely on standards

Enable new types of applications

Build security in, not on

These design goals were undertaken to help address the security shortcomings of NT 4.0 and
position Win2K as a true enabler for the burgeoning e-commerce environments that are the
promise of the Internet revolution. As a result, a number of features take advantage of the
integrated AD. Many others take advantage of the flexibility of the Windows security
architecture to integrate a number of Internet security standards.
Now that Ive talked about what drove Microsoft in developing Win2K, it seems natural to jump
right into the new security features available in Win2K.

AD provides a single storage mechanism for all domain security policy and account
information.

AD provides a hierarchical namespace for all user, group, and computer account
information. This allows these entities to be grouped by Organizational Units (OUs).

Administrator rights can be delegated to the level of OUs for creating and managing user,
group, and computer account information. In addition, rights can be granted to individual
properties of objects.

ADs use of multimaster replication techniques allows domain controllers to act as peers.
This allows updates to be made to any domain controller, not just the primary domain
controller (PDC).

Chapter 1

Although updates can technically be made to any domain controller in a Win2K environment, a bug in
the implementation keeps this from being a reality. Ill discuss this situation in detail when I discuss
AD security vulnerabilities in Chapter 2.

AD uses a new domain model that supports a hierarchical tree of domains. This
simplifies trust management among domains because trust is automatic and transitive
throughout the domain tree.

The adoption of Internet standard security protocols, including Kerberos V5 and

Transport Layer Security (TLS), improve authentication of users and computers.

Credential mapping of public-key certificates to user accounts allows strong client

authentication to PKI-enabled applications.

Smart card support for interactive logon.

The inclusion of a certificate server that integrates the issuance of X.509 V3 certificates
into the operating environment. Combined with AD, this provides a scalable and
seamless foundation for an enterprise PKI.

Simplified administrative dialog boxes to manage the private- and public-key pairs and
certificates.

Integrated encryption technology.

The inclusion of the encrypting file system (EFS) to support the transparent encryption
and decryption of user files and folders.

The inclusion of the Internet Protocol Security Protocol (IPSec). Integrating IPSec into
AD greatly simplifies administering IPSec because AD provides centralized management
of network security policy.

Virtual private network (VPN) solutions that are integrated into AD provide unified
account access and management.

While you can see that the prevalent themes of Win2K center on AD, other additions and
advantages that come with adopting Win2K can strengthen the security of your computing
infrastructure. First and foremost, AD and its security services are fundamentally integrated into
the Win2K OS. Win2K also integrates smart card technology. Finally, Win2K is designed to run
in a pure Transmission Control Protocol/Internet Protocol (TCP/IP) environment; a
homogeneous Win2K environment eliminates legacy protocols that pose serious security
concerns.
Active Directory
NT 4.0 used a secure portion of the Registry as its repository for account information. In Win2K,
this functionality is replaced by AD, which significantly improves both performance and
scalability. AD also offers more administrative capabilities than NT 4.0. The advantages of
integrating security account management with AD are listed below.

Chapter 1

Directory containers known as OUs can organize accounts for users, groups, and
computers in a domain. Each domain supports multiple OUs, which can be organized in a
hierarchical fashion. For example, the namespace for account information in a domain
can be structured to represent departments and organizations in a company. In addition,
user accounts and OUs are directory objects that can be renamed in the domain tree as the
organization changes.

AD easily supports over 1 million objects with better performance than the Registry;
therefore, domain size is no longer limited by the performance of the old Registry-based
security account repository.

Win2K domains can be organized into a hierarchical tree with two-way transitive trust
among domains that are part of the same Win2K domain tree. These trust relationships
allow users with accounts defined in one domain to be authenticated by resource servers
in another domain.

For many large organizations, the new AD-integrated domain model of Win2K enables a
large number of account and resource domains to be consolidated into as few as one. This
eliminates the complicated web of trust that tends to exist in many large NT 4.0
deployments and can replace it with a simplified trust model with only a few automatic
inter-domain trusts. Figure 1.1 shows a sample AD domain hierarchy.

Figure 1.1: A sample AD domain hierarchy.

Storing the security account information in AD means that users, computers, and groups are
represented as objects in the directory. As a result, standard capabilities that are integral to AD
are available to security account information. In particular, AD supports:

Delegation of administrationCan confine the security administration capabilities of a

user to defined subsets of an entire domain. For example, an administrator can manage a
set of users, computers, and groups within his or her area of responsibility and, at the
same time, not give permissions to manage accounts in other parts of the organization.

Chapter 1

Fine-grained access rightsMake it possible to grant access rights for specific

operations. For example, an organization can grant administrative capabilities such as
resetting user passwords or disabling accounts to specific groups without also granting
permission to create new accounts or change other properties of user accounts.

Inheritance of access rightsMakes it possible to grant access to a higher-level

container of the directory and have the rights flow down to the sub-containers and leaf
objects. For example, administrative capabilities can be modified on entire portions of the
directory tree by making changes to a specific container; these changes can automatically
affect all sub-containers and leaf objects.

These three AD capabilities will allow you to grant administrators the requisite privileges to do
their job without granting them more privileges than they actually need. In NT 4.0 environments,
an administrator must be a domain administrator even if the only right he or she needs is
resetting user passwords for a pool of 25 users. Using ADs delegation of administration and
fine-grained access rights, you can configure Win2K to enable an administrator to reset user
passwords for these 25 users without allocating any other administrative privileges; therefore,
you can assign and manage administrative privileges without the all-or-nothing paradigm of NT
4.0. This privilege-delegation capability can greatly reduce the number of Win2K domain
administrators required to administer your environment compared to the number in NT 4.0
environments.
Security in Active Directory
Before exploring more of ADs integrated security services, I want to first talk about the security
of AD itself. AD stores domain security policy information, such as domain-wide password
restrictions and system access privileges, which directly affects how you use the system. Because
security-related objects in AD must be securely managed to avoid unauthorized changes that
affect overall system security, Win2K implements an object-based security model and access
control. All objects in AD are protected by access control lists. ACLs determine who can see an
object and what actions each user can perform on it; therefore, the existence of an object is never
revealed to a user who isnt allowed to see it.
An ACL is a list of access control entries (ACEs) stored with the object it protects. In Win2K, an
ACL is stored as a binary value called a security descriptor. Each ACE contains a security
identifier (SID), which identifies the user or group to which the ACE applies and information on
what type of access the ACE grants or denies. ACLs on directory objects contain ACEs that
apply to the object as a whole and ACEs that apply to the individual attributes of the object. This
design allows an administrator to control not just which users can see an object, but what
properties those users can see. Because every object in AD has a unique SID, AD uses
impersonation and Win2K access verification to determine if an AD client can read or update the
desired object; therefore, the OS enforces the appropriate access control for LDAP client
requests to the directory.
As you can see, there is a fundamental relationship between AD and the security services that are
integrated into the Win2K OS. The relationship between security and AD extends well beyond
the integration of security account management. In particular, the following security services are
all tightly integrated with AD: account management, PKI, Group Policy, security groups,
Kerberos, EFS, and Routing & Remote Access Service (RRAS). This integration is illustrated in
Figure 1.2.
6

Chapter 1

Figure 1.2: The integration of Win2Ks security services with AD.

Domain Controllers
With the introduction of AD, Win2K domain controllers function as peers. This is a change from
the superior/subordinate roles played by Windows NT 4.0 Server PDCs and backup domain
controllers (BDCs). Peer domain controllers support multimaster replication, replicating AD
information among all domain controllers. The introduction of multimaster replication means
that administrators can make updates to AD on any Win2K domain controller in the domain. (In
the Windows NT 4.0 Server OS, only the PDC has a read-and-write copy of the directory; the
PDC replicates a read-only copy of directory information to the BDCs.)
This change in Win2K has security consequences for any organization that uses a lot of BDCs in
environments that arent physically secure. Because BDCs are read-only replicas, many
organizations think that a less secure physical environment is acceptable from a risk perspective.
Unfortunately, the possibility of an attacker gaining access to the physical computer that acts as a
domain controller in the Win2K environment represents an unacceptable risk. This is because all
Win2K domain controllers allow updates, and the updates are propagated throughout the domain.
If an attacker has physical access to a domain controller, he or she can take the computer offline,
make changes to AD that give the attacker access to any domain resource he or she wants, then
bring the computer back online. Once online, the illicit modifications are replicated throughout
the environment, effectively destroying the security integrity of the entire domain.
Public Key Infrastructure
After the integration of AD, the other major architectural security addition to Win2K is PKI
support. For security-minded professionals, this is an exciting addition that can finally help your
organization deploy a PKI. Microsofts PKI support in Win2K is not only well integrated with
the OS, it also shares a high level of integration with AD. Thus, PKI support in Win2K has two
major dimensions: a built-in certificate authority and support for the broad use of certificates.

Chapter 1
Certificate Authority
The Microsoft certificate server included with Win2K provides customizable services for issuing
and managing X.509 V3 public-key certificates. It achieves this level of customization using a
combination of AD entries and loadable policy modules that affect the processing of certificate
requests.
AD integration is achieved by using certificate templates and publishing certificates. Certificate
templates prespecify the format and content of certificates, based on their intended usage, by
controlling the X.509 V3 extensions. Because certificate templates are stored in AD, ACLs
specify a users right to retrieve a particular type of certificate. This capability allows you to
centrally control what type of certificates you issue and who can retrieve specific types of
certificates for the entire company. In addition, certificates can be optionally published in AD,
giving clients ready access to another users public credentials.
The policy modules allow you to customize certificate services by verifying identities from
multiple sources, include information from additional data stores, and insert additional certificate
attributes as necessary. This last capability allows you to insert custom attributes based on
internal authoritative sources of information to provide specific-use certificates for internal
business processes. For example, you can insert an individuals job title and a signing limit into
certificates and use them in Web-based purchasing forms to determine the authorization and
spending limit for purchase requisitions.
Broad Certificate Use
Win2K contains many built-in certificate-based applications and protocols, including support for
Web security, secure e-mail, digitally signed content, EFS, smart card logon, and IPSec. Figure
1.3 illustrates the major PKI components of Win2K. Some of these Ill touch on below; the rest
Ill discuss in later chapters of this book.

Figure 1.3: The major PKI components of Win2K.

Win2K PKI integrates support for secure Web traffic as a standard feature of Internet
Information Server (IIS). User certificates can be mapped on a one-to-one or many-to-one basis
against security user objects in AD. This certificate mapping allows a security token for the
8

Chapter 1
client to be automatically synthesized so that Windows ACL mechanisms are used to enforce
access control to resources behind the Web server. The use of standard ACL mechanisms is
advantageous for services because they can use the identical access-control mechanism
independent of the client-authentication mechanism used (PKI or Kerberos). For example,
certificates and/or Kerberos can be used to seamlessly authenticate your users to internal Web
applications without your users having to re-enter their user names and passwords.
Win2K also provides a foundation for secure e-mail using Secure Multipurpose Internet Mail
Extensions (S/MIME). E-mail clients such as Outlook Express, Outlook 98, and Outlook 2000
can take advantage of the integrated PKI to provide digital signatures for and encryption of mail.
For example, digital signatures can prove origin and authenticity of an e-mail message, while
bulk encryption can provide confidentiality among e-mail correspondents.
Win2K also includes support for IPSec, which defines protocols for network encryption at the IP
layer. While IPSec doesnt require certificate-based technology and can use shared secret keys,
certificate-based technology offers a practical solution for creating scalable distributed trust
architectures for IPSec. In particular, it can set up a trust architecture in which IPSec devices can
mutually authenticate each other and agree on encryption keys without relying on prearranged
shared secrets. This arrangement can protect sensitive corporate information sent on your
internal and external networks. Thus, it can be used as a standard mechanism to secure network
sessions with business partners, remote offices, remote employees, and any other group that
requires a network infrastructure not owned by the enterprise.
Certificate-based applications can be used in an enterprise-wide Win2K environment using
roaming profiles and smart cards. When using Microsoft cryptographic service providers (CSPs),
keys and certificates are carried along with a users roaming profile, so users always have access
to their credentials. Hardware tokens, such as smart cards, support roaming using the physical
certificate store on the token device, so credentials are physically carried to new locations. Of the
two methods, hardware tokens are far superior from a security perspective; roaming profiles can
leave vulnerable private-key material on workstations that can be readily accessed during offhours or in semiprivate locations.
Group Policy
While not exclusively a security capability, Group Policy extends and takes advantage of AD
service. Group Policy settings are contained in Group Policy Objects (GPOs), which are in turn
associated with the following AD containers: sites, domains, and OUs. At the root of the Group
Policy namespace are the following two parent nodes:

Computer ConfigurationIncludes all computer-related policies that specify OS

behavior, desktop behavior, application settings, security settings, assigned applications
options, and computer startup and shutdown scripts. Computer-related policy settings are
applied when the OS initializes.

User ConfigurationIncludes all user-related policies that specify OS behavior,

desktop settings, application settings, security settings, assigned and published
applications options, user logon and logoff scripts, and Folder Redirection options. Userrelated policy settings are applied when users log on to the computer.

Chapter 1
Specific security-related policy settings are broadly delineated in Win2K as follows:

Account policiesPassword policies, account lockout policies, and Kerberos policies

Local policiesAudit policy, user rights assignment, and security options

Event log settingsApplication, system, and security event log settings

Restricted groupMembership in security-sensitive groups

System servicesStartup and permission for system services

RegistryPermissions for Registry keys

File systemPermissions for folders and files.

Group Policy will allow you to uniformly enforce defined security policies throughout your
computing infrastructure by creating domain-level GPOs that define the most critical securityrelated settings. These settings will then be enforced on each and every computer in the domain.
No longer will security settings have to be managed on individual computers.
Security Groups
Not unlike NT 4.0, Win2K allows you to organize users and other domain objects into groups for
easy administration of access permissions. Security groups let you assign the same security
permissions to large numbers of users in one operation. This ensures consistent security
permissions across all members of a group. Using security groups to assign permissions means
that the access control on resources remains fairly static and easy to control and audit. When
users need access, you can add them to the appropriate security groups as needed (and remove
them when they no longer need access), and the ACLs on resources change infrequently. Win2K
enhances the security groups provided by NT 4.0 using:

Four types of security groupsWin2K supports four types of security groups, which
are differentiated by their scope. Domain local groups grant access to resources in a
domain. Global groups combine users who share a common access profile. Universal
groups grant access to similar groups of accounts defined in multiple domains. Computer
local groups grant access on local computers without granting access across an entire
domain.

Nested groupsWin2K allows you to create groups within groups. Unfortunately, this
capability is only available in an environment with no legacy NT 4.0 domain controllers.

Of these two new enhancements, the ability to nest security groups may provide the bigger
benefit. Group nesting makes it easier for you to manage group membership for large groups.
For example, you can create a company-wide security group without having to list every
employee individually. You can then make this whole-company group easier to administer by
defining it as the group that contains the enterprise groups. Each enterprise group then contains
the departmental groups. This hierarchical nesting of security groups allows resource owners to
define their own local groups based on their required access permissions and to delegate the
ability to manage group membership. This allows resource owners themselves to manage access
by updating the appropriate groups.

10

Chapter 1
Kerberos
Win2K has adopted Kerberos V5 as its default protocol for network authentication and identity
propagation. Kerberos replaces NT LAN Manager (NTLM); a high-level view of it is shown in
Figure 1.4. This is an important change in Win2K because NTLM has been one of the primary
sources of hacker exploits in previous versions of NT.

Figure 1.4: A high-level view of the Kerberos protocol.

Kerberos is an authentication protocol that provides a mechanism for mutual authentication

between a client and a server, or between one server and another, before a network connection is
opened between them. Kerberos provides a means of verifying the identities of principals (users,
applications, and computers) on an open network and acts as the foundation of a single sign-on
solution. By fully integrating the Kerberos model into Win2K and its domain structure,
Microsoft has created the logical beginnings of a standards-based heterogeneous single sign-on
that is structured around Win2K. For you and your organization, single sign-on can provide the
following real cost benefits:

It reduces the time it takes for users to sign on and the number of failed sign-on attempts
that occur because of user error

It improves security by reducing the user name/password combinations that users need to
remember

It reduces the amount of time that system administrators spend adding, removing, and
modifying user information, thereby allowing them to concentrate on other value-add
activities

It improves security by enhancing the ability to maintain the integrity of user account
configurations.

11

Chapter 1
Encrypting File System
The Encrypting File System (EFS) gives users the ability to encrypt individual NT file system
(NTFS) files, as well as entire folders, using a strong public-keybased cryptographic scheme.
Fully integrated into the OS, EFS works transparently from the users perspective by encrypting
and decrypting on file reads and writes to disk. To provide a robust solution, EFS allows you to
set up data recovery policies (a subset of Group Policy) so that data encrypted using EFS can be
recovered when required. Data recovery in EFS is a contained operation in that it only discloses
the recovered data, not the individual users private key that was used to encrypt the file. In
addition, EFS supports export and import features, which allow encrypted files to be backed up,
restored, and transferred without decrypting protected data.
EFS also protects unauthorized access to sensitive information by allowing users to encrypt
folders and files on their computers. This is especially vital for your laptop users. If someone
steals one of your organizations laptops, its a trivial matter for the hacker to gain access to files
and folders stored on the hard drive. Using the strong cryptography provided by EFS, sensitive
information is well protected.
Routing & Remote Access Service
While still supporting traditional dial-up Remote Access Service (RAS), Win2K includes
extensive support for VPN technology. VPN technology leverages the IP connectivity of the
Internet to connect remote clients and remote offices to an enterprises corporate network.
Win2K integrates IPSec with AD to consolidate remote-access policy with standard security
account management; thus, all user account management is centralized, providing policy-based
security administration.
In addition to adopting VPN technology, Win2K has extended the integrated service that
provides both remote access and MultiProtocol Routing (MPR), known as Routing and Remote
Access Service (RRAS). The combination of routing and VPN-based remote-access services on
the same computer creates a Win2K remote-access router. An advantage of RRAS is its
integration with the Windows 2000 Server OS so that service works with a wide variety of
hardware platforms and hundreds of network adapters; the result can be a lower-cost solution
than many mid-range, dedicated router or remote-access server products. In addition, RRAS is
extensible, providing APIs that third-party developers can use to create custom networking
solutions.
Most organizations can benefit greatly from integrating RRAS capabilities into Win2K by using
AD for remote-access account management and providing the single sign-on experience for
remote users. By having a central repository for all account management functions (that is, AD),
its much easier for security administrators to gain a full understanding of the authorizations
granted to a user. The single sign-on experience allows remote users to authenticate once to the
VPN device, then access all of their normal resources, just as if they were on their internal
network. This is probably the biggest advantage of using the Win2K VPN solution. Solutions
provided by other vendors typically require remote users to authenticate once to the VPN device,
then authenticate again to every Windows-based resource they access in the computing
infrastructure.

12

Chapter 1
Smart Cards
While most of the security services in Win2K are tightly integrated with AD, one notable
exception deserves mention, and that is smart cards. Smart card technology is attractive from a
security perspective because it:

Provides tamper-resistant storage for protecting private keys and other forms of personal
information, such as passwords

Isolates security-critical computations involving authentication, digital signatures, and

key exchange from other parts of the system that dont have a need to know

Enables portability of credentials and other private information among computers at

work, at home, or on the road using a small, convenient form factor.

The integration of smart card technology into Win2K is based on the Personal Computer/Smart
Card (PC/SC) 1.0 specification that was designed to solve the interoperability problems that exist
with the myriad of standards that exist today. This specification provides a standard model for
interfacing smart card readers and cards with computers, device-independent APIs for enabling
smart cardaware applications, and complete integration with the OS.
The integration of smart card technology into Win2K gives your organization an opportunity to
deploy a solution that doesnt come with the hardware and software incompatibilities that have
been evident in many of the smart card solutions of the past. While you can move PKI
applications and digital certificates forward without using smart cards, I believe that smart cards
significantly raise the information-security bar in any computing infrastructure. In addition,
smart cards provide users with a solution that is easier to use than a number of the current, tokenbased strong-authentication solutions used today (such as SecurID).
Pure TCP/IP
Win2K is designed to run in a pure Transmission Control Protocol/Internet Protocol (TCP/IP)
environment. A homogeneous Win2K environment eliminates legacy protocols that pose serious
security concerns to your enterprise. It does this because in addition to the new AD-based
protocols, Win2K retains backward compatibility with legacy NT 4.0 protocolsfor example,
NetBIOS over TCP (NBT), Windows Internet Name Service (WINS), NTLM authentication, and
LAN Manager authentication. These legacy protocols are considerably weaker than their Win2K
counterparts and are vulnerable to many well-known attacks. Unfortunately, they cannot be
eliminated until your entire Windows infrastructure is upgraded to Win2K. As long as there are
legacy Windows (Win9x, NT 3.51, and NT 4.0) computers in your computing environment, you
cannot reap the benefits of the enhanced security provided by Win2K, and your environment will
remain vulnerable to simple, yet effective, attacks.
Overall, Win2K provides a security environment that is considerably improved over NT 4.0, but
backward compatibility leaves unwanted security exposures. So while the new security
capabilities of Win2K will strengthen many aspects of your Windows infrastructure, until you
can upgrade to a homogeneous Win2K environment, the weaker security of Windows 95, 98,
and NT 4.0 will degrade the security of your computing infrastructure.

13

Chapter 1

Security Primer
While a number of you have some background in the security profession, Im willing to wager
that more of you dont. For those of you with a security background, this section will likely just
be a simple refresher. For those of you who are new to security, it will give you a grounding in
the art of being a security professional.
No matter what your background, this section will convey what I think is an appropriate vantage
point from which to view security. In particular, it discusses the security philosophies, concepts,
and fundamentals you need to build a secure and robust enterprise-computing infrastructure.
Security Framework
When I evaluate the security of an enterprise, I start by stepping back and taking a look at the big
picture. I try to view things in the context of an overall security framework. Deciding what
elements constitute an appropriate security framework can keep your organization busy for
months, but I believe that establishing an appropriate framework goes a long way toward helping
you establish a reasonable framework for analyzing security and shape an effective informationsecurity program. Even if your organization cannot formalize a security framework, you can still
use one to help structure how you approach security in your enterprise.
An appropriate security framework is made up of three tiersorganizational factors, security
objectives, and security mechanismsas shown in Figure 1.5.
Organizational Factors
Risk Analysis

Policy

Culture

Security Objectives
Confidentiality

Integrity

Availability

Accountability

Identification

Authentication

Authorization

Encryption

Virus Protection

PKI

Audit

Monitoring

Security Mechanisms

Figure 1.5: A three-tiered security framework.

14

Chapter 1

Organizational Factors
The top tier of our security framework takes into account the organizational factors that you must
consider when planning for enterprise-wide security. These organizational factors perpetuate a
number of issues that are no easier to solve than the technical issues surrounding an effective
security program. Paramount to the success of an enterprise security program are the
relationships among risk analysis, the organizations culture, and security policy.
Risk analysis is traditionally looked at as a process to ensure that security controls prescribed for
a system are fully commensurate with its exposed risks. An effective risk-assessment program
benefits an organization in many ways. For example, it:

Generates justifications for security recommendations in business terms

Relates security directly to business issues

Enables security to become part of an organizations culture

Helps increase security awareness within an organization

Promotes far better targeting of security resources and facilitates related decisions

Enables you to rapidly identify systems that dont meet established security baselines

Aids communication and facilitates decision-making.

An organizations culture is often overlooked in this context, but it has a tremendous bearing on
the acceptance of security controls. For example, a stringent password policy that might be
perfectly acceptable in my organization could cause outright revolt in yours. You must take the
beliefs, attitudes, and actions of your organization into account when you formulate an effective
security program; otherwise, the security controls that you establish will be subverted or ignored
outright.
A security policy should communicate to everyone in your organization the simple principle that
information is a valuable asset and everyone is responsible for protecting it. A security policy is
the tangible representation of the high-level security considerations, requirements, priorities,
assumptions, and responsibilities that provide the appropriate balance between business
requirements and security needs for your enterprise. An effective security policy provides a
number of benefits, including the following. It:

Clearly states what corporate information must be protected

Establishes unambiguous responsibilities for protecting information assets

Sets clear expectations of privacy in the workplace

Defines acceptable behavior

Limits the organizations exposure to liability

Guides the selection of information technology and facilitates proper implementation

Facilitates establishing security-incident prevention and response programs.

As you can clearly see, organizational factors play a significant role in developing a sound
security program.

15

Chapter 1

Security Objectives
The middle tier of our security framework enumerates the specific security objectives that I
believe are paramount to successfully implementing security services in an enterprise:
confidentiality, integrity, availability, and accountability. These are the core things that I care
about when designing and implementing security for an enterprise.
For those of you with a security background, this list looks a lot like the traditional CIA
(confidentiality, integrity, availability) model of security, with an A appended to it. I used to use
the CIA model, but I do appreciate others security objectives, so Ive spent considerable time
thinking about some of the alternative views being offered in the security community nowadays.
Reaching consensus on the correct set of objectives and their precise definitions can be difficult
at best. In fact, in the course of writing this chapter, I was tempted to change my mind a couple
of times. In the end, I ended up right where I startedwith the same four security objectives.
While your organizations security policy may embody all of these objectives, I dont believe
that excluding them from formal policy diminishes their importance. To provide a common point
of understanding, these objectives are defined briefly below.

ConfidentialityKeeping information and resources from being disclosed to someone

who hasnt been explicitly granted access.

IntegrityEnsuring that information and resources remain complete and unchanged

from a previous state.

AvailabilityEnsuring that information and resources can be used whenever theyre

needed.

Availability is an important component of a good security program, but other than describing the basic
issues of backup, redundancy, and so on, I wont talk much more about it in the rest of this book. On
the other hand, Ill devote individual chapters to the other three objectives.

AccountabilityAssigning and tracking responsibility for the actions of users and

resources.

Accountability includes auditing, which in some circles is considered a paramount security objective in
its own right.

Security Mechanisms
The bottom tier of the security framework shown in Figure 1.5 above lists specific security
mechanisms used to implement the security services for an enterprise. This list is by no means
complete. It includes the most recognizable and, arguably, the most important security
mechanisms, but any that arent listed are nevertheless important.
While you need to pay attention to all three tiers of your security framework, its typically at this
bottom tier where youll spend most of your time, deciding how to best deploy, configure, and
maintain the security mechanisms at your disposal. In addition, the Win2K security features that
I discussed earlier in this chapter are security mechanisms that are available to you.

16

Chapter 1
Relating to the Security Framework
When you define security architecture, design, and implementation, you must take into account
all three tiers of your security framework. As I mentioned above, however, many of us focus on
the bottom tier and how we can bring together fundamental security mechanisms to provide the
top two tiers of our security framework. In the next few sections, Ill articulate the constraints,
foundations, and concepts that I believe are the keys to putting together a strong, effective
security implementation and linking together a vast array of security mechanisms.
Philosophy of Protection
An organizations attitude to providing security services should be based on a small number of
tenets. These tenets provide an organizations basic values for protecting its computer systems
and information from damage or abuse. I call it a Philosophy of Protection, or PoP, and it
lays the foundation for understanding the security services of an environment. In my experience,
the following tenets constitute an appropriate PoP for most organizations:

Security is embedded

Security is logically centralized but distributed globally

Security is applied to multiple layers

Security is an enabler, not a roadblock.

These four tenets capture my view of how an organization can best design, implement, and treat
security. Ill explain each of them in the following sections.
Security Is Embedded (Security Is Everywhere, but Nowhere to Be Seen)
Security services need to be built into the infrastructure of the enterprise. Whenever possible, an
organization must provide security services that are transparent to applications, services, and end
users. If you cant achieve true transparency, provide the appropriate hooks into the security
infrastructure to minimize the impact on the enterprise. The more transparent the security
services are, the more easily theyll be adopted. Thus, transparent and/or translucent security
services will ensure easier, more widespread deployment of security throughout the enterprise.
Security Is Centralized Logically but Distributed Globally
You need to manage security services logically from a central store, then replicate and install the
security configuration appropriately in the instantiated security services throughout your
enterprise. While you dont need a single security store, you do need to prudently consolidate
security information stores to reduce complexity, provide fewer security audit points, and allow a
more cohesive view of the rights and privileges of a security principal. (For our purposes, a
security principal is anything that wants to access the information or services of another entity.)
At the same time, you need to distribute security configurations and policies securely to make
appropriately configured security services available. You need to propagate configuration and
policy in a timely manner and deliver them to security services both within the physical walls of
the enterprise and outside the extended enterprise.

17

Chapter 1
Security Is Applied to Multiple Layers
You need to apply security services in such a way that a single failure doesnt jeopardize the
enterprises computer systems and information. To do this, you need to provide security services
and controls for networks, hosts, middleware applications, and end-use applications. This tenet
doesnt imply that security services and controls are required at each of these layers; but you do
need to use multiple controls, whether at the same layer or at multiple layers, to provide the
appropriate level of security services.
Security Is an Enabler, Not a Roadblock
Security in my mind is really about mitigating risk, and it must be instantiated so that your
business can take intelligent risks. Thus, security is most effective when you view it as a service
that is based on an assessment of threat, vulnerability, and customer needs; its most effective
when it becomes a part of the way you think and act, not about rules that define what you can
and cannot do. Valuing the spirit of security over formal security policy and standards makes
security a more positive undertaking. Security is fundamentally a partnership between security
practitioners and computer operations; it balances the need to provide security services with the
need to provide a meaningful service to your customers.
Security Concepts
While PoP defines my approach to security, my designs and implementations are typically based
on a set of usable security concepts. These security concepts must have their foundations in
traditional computer security nomenclature to eliminate ambiguity in how theyre used. In my
experience, the following security concepts are the most important for almost all organizations:
need-to-protect, least privilege, separation of duties, defense in depth, role-based access control,
authentication, authorization, access control, and non-repudiation. These security concepts
provide a frame of reference that Ill refer to in later chapters of this book.
The following sections often refer to security principals. Remember that a security principal is
anything that wants to access the information or services of another entity.
Need-to-Protect
The need-to-protect concept grants everyone in an organization access to all information and
resources except what must be protected. It restricts access to, among other things, marketsensitive information, proprietary information, financials, trade secrets, process-technology
information, human resources and payroll information, customer information, information
restricted by laws and/or regulations, and security information. (This concept is diametrically
opposed to the concept of need-to-know. While need-to-know is necessary in organizations
whose objective is security at any cost, such as the military, it can have a negative impact on
operations whose key objectives are profit and productivity.)
Using the concept of need-to-protect is important, but it doesnt affect what information needs to
be protected. It affects end-user perception, attitude toward security, and potentially the methods
you use to protect information.

18

Chapter 1
Least Privilege
The least privilege concept asserts that security principals should have the minimum set of rights
and privileges necessary to perform their assigned function(s). Some definitions also assert that
these rights and privileges should be active only for the duration of their use, not while theyre
not being used. Ive found that this additional constraint is highly desirable, although not
required, so I recommend that when circumstances allow, you strive to enable a security service
to carry out additional constraint.
Separation of Duties
The separation of duties concept asserts that security principals shouldnt have access to all of
the necessary security services because this subverts their effectiveness. This concept is based on
the assumption that the more people who are required to collude in an act of fraud or deceit, the
greater the chance that theyll be caught. A classic example of separation of duties is that of
accounts payable and accounts receivable. If someone has unmitigated access to both systems, he
or she can perpetuate financial fraud relatively easily. By applying separation of duties and
defense in depth (described below), you can create tiers of security that are difficult to bypass
without the collusion of multiple individuals or groups.
Defense in Depth
The defense in depth concept asserts that deploying security services at multiple levels, where
each level handles the threats most appropriate for its level, creates an aggregate effect of
security services throughout all levels that is greater than the sum of the parts. This concept is
based on the assumption that its harder to break multiple, simple security mechanisms, deployed
throughout the layers of an enterprise, than it is to break a single, monolithic mechanism
designed to protect everything. By applying defense in depth and separation of duties (described
above), you can create tiers of security that are difficult to bypass without the collusion of
multiple individuals or groups.
Role-Based Access Control
The concept of role-based access control asserts that access decisions are based on the roles that
individual security principals play as part of their duties in an enterprise. This concept requires
that security principals be granted membership in roles based on their competencies and
responsibilities; in other words, the operations that a security principal is permitted to perform
are based on his or her role. Although originally designed for end users, this concept also
provides an effective means for developing and enforcing enterprise-wide security policies and
streamlining the security management process.
Identification
The concept of identification allows you to uniquely distinguish each and every security
principal, whether user, computer, or application. Identifying security principals separately
makes all actions in a computing infrastructure fully accountable. Identification doesnt have to
be complicated, and its typically a user name or computer name. Regardless of this simplicity,
however, identification is the building block for all other pieces of security implementation.

19

Chapter 1
Authentication
The concept of authentication provides the ability to positively prove that a security principal is
who or what it claims to be. Although this concept is usually associated with users, it means
making sure that all your security principalsusers, computers, or applicationsare
authenticated before being allowed to access the resources of another security principal.
Otherwise, you may not be able to meet your key security objectives.
Authorization
The concept of authorization gives a security principal the ability or privilege to perform an
action or access an information resource. A lot of people confuse this concept with access
control, but its fundamentally different. Authorization grants a security principal access to a
resource. For example, when you add a security principal to the ACL of a Web page, youre
authorizing it to view the page.
Access Control
The concept of access control provides the logical or physical controls that prevent unauthorized
access to information resources. Building on the example above, if a security principal requests
access to a Web page, the Web server carries out access control to decide if access should be
granted. If access to the resource is controlled and a security principal isnt a member of an
appropriate ACL, it wont be able to view the page.
Non-Repudiation
The concept of non-repudiation provides the ability to prove that a specific security principal is
the one that performed an action, even if the security principal later denies it. In todays security
world, non-repudiation has become almost synonymous with digital signatures. There is a
distinction between the two, however: non-repudiation is a concept, and digital signatures are
more of a technology or process.
Security Principles
PoP and security concepts provide the framework necessary to ensure that your approach to
security provides a meaningful security posture for your enterprise. But they dont recommend
any particular actions. The following list of security principles will help you put PoP and security
concepts into action and drive the rationale for your design and implementation. In my
experience, this list provides an appropriate set of security principles for an enterprise.

The less access a security principal has, the less damage it can do

The fewer privileges a security principal has, the less likely it is to do something it isnt
supposed to do

The fewer privileges a security principal has, the less opportunity it has to abuse them

The easier it is to administer security services, the more likely theyll be configured
correctly

If something goes wrong, security services should have a way of recording it

If something goes wrong, security services should be capable of warning you

20

Chapter 1

If something goes wrong, security services should have a method of detecting and
correcting unwanted changes

Security services should be designed to protect against accidental as well as intentional

losses

The fewer security services you provide, the fewer potential failures you need to worry
about

The fewer security services you provide, the fewer audit points you need to worry about.

What Does This All Mean?

Now that Ive defined a set of core security tenets, concepts, and principles, what do they really
mean? Each one has some meaning of its own, but together, they provide a common direction for
all of the security services in your environment. In addition, they can bring some consistency to
your security implementations. Will certain implementations that you build go against some of
what has been described here? Most certainly, but just remember that these tenets, concepts, and
principles are your guides, not your shackles.
To end this security primer, Id like to point make one final point. I believe security is more of an
attitude than a set of checklists. In the rest of this book, Ill share my experiences in securing
Win2K. More times than not, these discussions will include my opinion of how security should
be configured. But while Ill share my opinions and checklists with you, I hope to also convey
my attitude toward security. When Im finished, youll have your checklists. I also hope that
youll have a fundamental understanding of security and be able to incorporate it into your
thought processes as you perform your daily job functions.

Summary
In this chapter, I covered a lot of diverse territory. I gave a short overview of Win2K, introduced
many of its new security features, and took a brief look at the foundations of security. Obviously,
this roller-coaster ride of topics didnt allow me to cover everything in its entirety. The rest of the
chapters in this book will be a little more focused and will expand on the concepts and security
features introduced here to give you an in-depth look at Win2K.

21

Chapter 2

Chapter 2: Managing Active Directory Security

The most significant new feature of Win2K (Win2K) is quite simply Active Directory (AD).
Although I like to think that the security enhancements made to Win2K were the most significant
introductions to the operating system (OS), most of them couldnt have been so cleanly
integrated without AD. This holds true for many of the other OS services as well; Microsoft
spent a considerable amount of effort to ensure that AD was well integrated into the OS.
At first glance, one might assume that AD is just a simple replacement for the Security Account
Manager (SAM). Although its true that SAM is no longer the repository for domain objects, AD
assumes a much larger role in this version of the OS than SAM did in previous incarnations.
So if AD isnt just a SAM replacement, what is it? Well, AD is Microsofts implementation of a
directory service. Like most directory services, AD is designed to be a mechanism to allow the
location of network resources without having to be aware of physical connection or location.
Before AD was introduced, the best-known network OS directory service was the Netware
Directory Service (NDS), typically found on Novell Netwarebased networks. Make no mistake,
AD was designed to compete directly against NDS, and its Microsofts first real attempt at an
enterprise-wide, scalable directory service. Consequently, AD looks to be at the heart of
Microsofts future enterprise-wide strategy. Not only is AD the centerpiece of Win2K, its also
the major integration point for other Microsoft products. Most notably, Exchange 2000 (E2K) no
longer uses its own directory for storing e-mail addresses and the like; instead, it uses AD.
In this chapter, Ill walk through AD and describe how it provides the foundations of security
and security management in Win2K. I should point out that AD is a large and complicated
service, and there are a lot of intricacies that I cant cover. As a result, Ill walk through AD from
the inside out, concentrating on the pieces that are relevant for the security services of Win2K.
At the end of this chapter, I hope youll have gained a thorough understanding of AD and how it
provides security in Win2K.

Directory Services Primer

Before getting to AD, I want to take a step back and spend a little time discussing what a
directory service is and why we need it. When Ive given you this background, Ill go on to
discuss why Microsoft moved away from SAM and replaced it with AD.
What Is a Directory Service?
Webopedia (http://www.webopedia.com) defines directory services as A network service that
identifies all resources on a network and makes them accessible to users and applications.
Resources include e-mail addresses, computers, and peripheral devices such as printers. Ideally,
the directory service should make the physical network topology and protocols transparent so
that a user on a network can access any resource without knowing where or how it is physically
connected.
While technically correct, this definition doesnt really help one understand what a directory
service is. A simpler description is that a directory service is like a database in that you can put
information in and later retrieve it. But a directory service is more specialized than a standard
database because its designed for reading rather than writing, offers a static view of the data,

22

Chapter 2
and provides simple updates without transactions. Todays directory services also typically
provide a network protocol to access the directory, a replication scheme, and a data-distribution
scheme. These last two elements usually allow the directory service to be distributed across the
enterprise or globally, so that data is spread across many computers, all of which cooperate to
provide the directory service.
Typically, a directory service is an information-storage mechanism, one that stores information
about objects. In this way, its a lot like a telephone book or a file system directory. Like these
other familiar directories, a directory service provides order and structure to large amounts of
data, thereby making them easy to manage.
Why Do We Need a Directory Service?
There are many reasons why one would want a directory service. One of the simplest and most
obvious reasons is to allow users and administrators to find objects on their enterprise network.
For example, how many of you have needed to locate a printer on your network so that you can
print an important document for your boss? Ill guess that either you ask a colleague the name of
that printer a couple of cubes over or you walk over and hope that the name is easily found on
the front of the printer itself. Neither way is very efficient. A directory is perfect for answering
this type of question and is very adept at answering queries like, Where are all of the color
printers on Floor 7 of Building 311?
Beyond allowing users and administrators to easily find objects in their enterprise, a directory
service can provide many other benefits as well. First and foremost from the viewpoint of
security, a directory service can itself enforce security in the environment. It can ensure that
users are authenticated and that access is authorized to information it contains. A directory
service can also distribute and replicate data to provide high availability of the information store.
It typically supports a very large number of objects (millions) and provides a single point of
administration for an enterprise. Last, a directory service can be integral to providing single signon to all directory-aware systems and applications.
Why Active Directory?
While Im sure that Microsoft had a laundry list of reasons for implementing AD, two stand out:
SAM limitations and the multiple information stores that have evolved in Microsoft products.
SAM has many limitations, including the maximum number of objects that it can support and its
lack of extensibility. Because SAM is limited to around 40,000 objects, many organizations have
been forced to implement multiple domains just to ensure that they never approach this
maximum. For example, lets say that your company has 18,000 employees. Assuming that
everyone has their own computer, and factoring in some servers for infrastructure services, you
probably have about 37,000 users and computers in your organization. If youre using a single
domain, you only have room for around 3,000 more objects. It would be easier in the long run to
divide your NT 4.0 environment into multiple domains to ensure that you never approach the
object limit in SAM.
In conjunction with these size limitations, and maybe because of them, multiple information
stores had appeared in the Microsoft product sets. The most obvious multiple information stores
could be seen in NT 4.0s SAM and the Exchange Global Address List (GAL). Obviously, a
single repository would simplify things greatly.

23

Chapter 2
So Microsoft designed AD to address these two issues and many others. Consequently, AD can
be viewed as a multi-purpose directory service designed using Internet-standard technologies.
Its fully integrated into the OS, is positioned to provide the single point of administration for all
enterprise resources, and integrates security account management. As I discussed in Chapter 1,
the advantages of AD over the legacy SAM can be roughly categorized as follows:

AD easily supports over 1 million objects with better performance than the Registry;
therefore, domain size is no longer limited by the performance of the old Registry-based
security account repository.

AD allows domain controllers to act as peers because it uses multimaster replication

techniques. As a result, updates can now be made to any domain controller, not just the
primary domain controller (PDC).

Win2K domains can be organized into a hierarchical tree with two-way transitive trust
among domains that are part of the same Win2K domain tree. These trust relationships
allow users with accounts defined in one domain to be authenticated by resource servers
in another domain.

Directory containers known as organizational units (OUs) can organize accounts for
users, groups, and machines in a domain. Each domain supports multiple OUs, which can
be organized in a hierarchical fashion. For example, the namespace for account
information in a domain can be structured to represent departments and organizations in a
company. In addition, user accounts and OUs are directory objects that can be renamed in
the domain tree as the organization changes.

Ill talk about these advantages throughout this chapter and discuss how you can use them to
provide information security in your enterprise.

Windows 2000 Architecture

Tightly integrated into the OS, AD leverages the system architecture of Win2K to provide a
secure foundation for its services. Thus, before I discuss what AD looks and feels like from the
outside, Ill describe its underpinnings. Its important for you to understand how Win2K in
general, and AD specifically, implement security. As a result, this section will focus on the
overall system architecture of Win2K, its security components, and where AD is implemented.
System Architecture
Like its predecessors, Win2K offers many important features that are highly desirable in todays
computing infrastructureobject orientation, multithreading, multitasking, preemptive
scheduling, multiprocessing, microkernel-based, processor architecture independence, integrated
networking, and multi-OS environments. As shown in Figure 2.1, the Win2K system architecture
is modular and composed of many separate subsystems. Its this overall system architecture that
provides the core feature set of the OS.
One of the unique features of the Win2K OS is its notion of objects. The kernel and the rest of
the OS were designed from the beginning to treat every resource as an objectfiles, folders,
processes, threads, and so on. As a result, almost every facet of the OS was built in an objectoriented fashion.

24

Chapter 2

Figure 2.1: The Win2K system architecture.

The multithreading nature of Win2K allows user applications to be executed as processes. Each
of these processes has its own logical address space and cannot interact with the address space of
other processes. This prevents an application from unintentionally or maliciously altering the
execution of another process. Each process owns all of its resources and may contain multiple
threads. Only the resources available for the OS limit the number of threads. While applications
are executed as processes, the unit of execution and scheduling in Win2K is the thread. Each
thread has no special status and has its own priority setting.
Not unlike other modern OSs, Win2K supports two modes of code execution: user mode and kernel
mode. When code executes in user mode, its subject to the address space restriction mentioned
above. Specifically, it can access only the address space and resources of its own process. When
code executes in kernel mode, it has access to the entire address space and all of the resources
managed by the OS.

Win2K provides multitasking using preemptive scheduling of each thread according to its
individual scheduling priority. Win2K uses 32 thread priorities; the higher the number, the
higher the priority. Of these 32 priorities, there are essentially two types: Dynamic and RealTime. Dynamic priorities range from 0 to 15, and Real-time priorities range from 16 to 31. Most
user processes run with a priority of 7 to 9. Once scheduled, each thread is set to run for a length
of time referred to as a quantum. A new thread is scheduled when the quantum expires or when
the currently running thread is blocked or forced to wait for another event to occur.

25

Chapter 2
Although seemingly not as important as in the past, the system architecture of the OS allows
Win2K to continue to support many types of processor architectures. It achieves this using a
combination of the Hardware Abstraction Layer (HAL) and the kernel, both of which are written
in the C programming language. However, while earlier versions of the OS took advantage of
this capability and supported several processor architectures the Intel, MIPS, Alpha, and Power
PC processor architectures -- Win2K supports only Intel.
Although we take it for granted nowadays, it wasnt that long ago that support for networking
wasnt built into the OS. In much the same way that support for multiple processor architectures
has dwindled with newer versions of the OS, so built-in networking support has changed. While
earlier versions of the OS continue to support for Internetwork Packet Exchange (IPX)/
Sequenced Packet Exchange (SPX)/Network Basic Input/Output System (NetBIOS), NetBIOS
Extended User Interface (NetBEUI), and Data Link Control (DLC) for connecting to legacy
environments, Win2K is designed to run in a pure Transmission Control Protocol/Internet
Protocol (TCP/IP) networking environment. Using pure TCP/IP, organizations can upgrade to a
homogeneous Win2K infrastructure to rid themselves of legacy network protocols and services
that have been repeatedly shown to be vulnerable to security attacks.
Another of the features that seems to have taken a back seat over the years is the OSs ability to
support multiple OS flavors. While weve all grown accustomed to the applications that are built
on the Win32 subsystem, Win2K also supports Portable Operating System Interface for UNIX
(POSIX) and OS/2. Unfortunately, the attention to security-related matters has traditionally
focused on the Win32 subsystem. As a result, the security of the other subsystems is not very
well understood or tested, and when you want to provide a secure installation of Win2K, these
subsystems are typically removed.
As I hope you see, the Win2K system architecture really does provide the main features that are
required of todays modern OS. Its from this system architecture foundation that Win2K
implements its core security subsystems. And that is our next topic.
Security Subsystem
The heart and soul of security in the Win2K OS comes from what is known as the security
subsystem. Its in the security subsystem that all of the security decisions are made. While the
name might lead you to believe that its one component, the security subsystem is really a
combination of kernel and user-space components, as depicted by the blue-colored components
in Figure 2.2. The kernel components of the security subsystem are the Object Manager and the
Security Reference Monitor. The user-mode components of the security subsystem are
fundamentally the Event Logger, WinLogon, and the Local Security Authority (LSA).

26

Chapter 2

Figure 2.2: The security components of the Win2K system architecture.

Object Manager
The Object Manager is a kernel-mode component that maintains a single namespace for all
system objects, including files, folders, ports, processes, and threads. Its responsible not only for
naming, allocating, and deleting objects but also for maintaining their security. It supports access
validation of objects using security information supplied by the Security Reference Monitor and
the Local Security Authority. By concentrating the core access-validation methods in the Object
Manager, Win2K essentially implements an object-based security model.
Security Reference Monitor
The Security Reference Monitor (SRM) is responsible for validating access rights. It does this by
implementing Access Control Lists (ACLs) and security identifiers (SIDs) and by maintaining a
unique security profile for each and every thread allocated in the OS. The SRM compares the
access rights of a thread against an objects ACL and determines whether to grant or deny access
to the object. For example, every time you attempt to open a file, the SRM evaluates the ACLs
associated with the object that represents the file to determine whether you should be allowed to
open the file. While this functionality is implemented in the SRM, the Object Manager uses the
functionality to maintain the security of objects, as I discussed above.
27

Chapter 2
Before moving on, its important to note that the LSA cannot access the SRM in user mode.
Instead, it uses the Object Manager, which in turn uses the SRM. This prevents any user or
process from obtaining direct access to an object. While this approach may not be intuitively
obvious, it greatly simplifies the validation of security in the OS because it consolidates all
access-control decisions into a single, small subsystem.
Event Logger
The Event Logging Service is a user-mode process that mediates all access to the three event logs
maintained by the OS: the application log, the security log, and the system log. Implemented in
service.exe, the event logs are opened as soon as the service is started and are protected from
unauthorized access or copying. The files remain open as long as the service is active and are
locked for writing so that no other process can write directly to them. The service also sets some
of the file-header bits so that if another process attempts to copy the file, the Event Log file will
appear to be corrupt; thus causing the copy to fail. Keep in mind, too, that once its started, the
service cannot be stopped or paused. As a test, open up the Services MMC snap-in and try to
manipulate the service yourself!
If access to the event logs is mediated through the Event Logging Service, how do events get
written to the logs? In the case of user-mode programs, applications have access to an application
programming interface (API) that allows writing to the event logs. Kernel-mode programs
register events in the logs by communicating through the input/output (I/O) Manager to the
service. Note that the SRM generates native user-account audit data and file-system audit data in
the kernel. However, this data is still written to the event logs using the user-space service.
Local Security Authority
The Local Security Authority (LSA) is the centerpiece of the user-mode security subsystem
components of Win2K. The LSA is responsible for the local system security policy,
authenticating users, generating access tokens, and sending security audit messages to the Event
Log. Like the security subsystem, the LSA is really multiple components. One of the more
visible actions of the LSA is the user logon process. But behind the scenes, the LSA is also
responsible for network logons, network authentication, and SAM. And like SAM, AD is
implemented as part of the LSA.
If you were wondering how I was ever going to get to AD when I started talking about system
architecture, now you know. So Ill finish up my discussion of the LSA, its functions, and
components, then get down to a discussion of AD.
Secure Logon Process

The first step toward providing security for any OS is to mandate that all users log on to the
system through a process of identification and authentication. Without accurate identification and
authentication of all users of a system, its impossible to control access to objects, user rights and
privileges cannot be enforced, and accountability cannot be maintained.
Were all familiar with the three-finger salute that initiates a user logon to a system. Pressing
CTRL+ALT+DEL initiates what is known as the Secure Attention Sequence (SAS). But how
does this sequence provide security in Win2K? The answer starts with the first process that is
launched when a Win2K system starts up, the process known as WINLOGON.EXE
(WinLogon). This process registers the SAS key sequence with the OS and protects against
28

Chapter 2
Trojan horse programs, which masquerade as the real logon screen and trick users into entering
their user names and passwords. Because WinLogon is the first process to run and register SAS,
users are assured that when they use SAS to initiate a logon event, theyre actually interacting
with the OS.
WinLogon is also responsible for starting, among other things, the LSA and a set of desktops that
are used to interact with the keyboard, mouse, and physical screen of the computer. These
desktops are the WinLogon Desktop, the Application Desktop, and the Screen Saver Desktop.
The WinLogon Desktop is activated whenever SAS is activated and provides interactive
identification and authorization and other secure dialog boxes. The Application Desktop is
created each time a user successfully logs onto the system and exists only for the duration of a
user logon session. The Screen Saver Desktop is pretty much what youd expectthe active
desktop whenever a screen saver is running.
The one piece of the secure logon process that I havent talked about so far is the Graphical
Identification and Authentication (GINA) module. The GINA is a component of the WinLogon
process that is responsible for gathering logon data from a user who initiates SAS. Most people
are familiar with the default GINA, MSGINA.DLL. But what many fail to realize is that they can
replace GINA with other authentication mechanisms such as biometrics, smart cards, and
countless others.
While GINA replacements and additions are sometimes unavoidable, Im not a fan of them. Many of
the third-party GINAs that Ive installed over the years have been poorly implemented, with visible
bugs. If I notice visible bugs in a product, I become immediately paranoid about the quality of all of
the code especially when that code affects something as critical as the logon process. On several
occasions, Ive seen some major deployment and support problems arise in situations where thirdparty GINAs were involved.
LSA Subcomponents

Now that Ive told you that the LSA is started by the initial process of the system, WinLogon, Ill
discuss the other components of the LSA and what services they provide the OS. The LSA is
implemented by LSASS.EXE and a set of dynamic link libraries (DLLs) that implement the
variety of components that make up the LSA. The holdover components from NT 4.0 include
SECUR32.DLL, LSASRV.DLL, NETLOGON.DLL, MSV1_0.DLL, SAMSRV.DLL, and
SCHANNEL.DLL. The new components include KDCSVC.DLL, KERBEROS.DLL, and
NTDSA.DLL. Table 2.1 below summarizes the functionality of these components.

29

Chapter 2

LSA Subcomponent

Description

SECUR32.DLL

The multi-authentication provider that holds the other components together.

LSASRV.DLL

A library that enforces the security policy of the local computer.

Netlogon.DLL

A library that maintains a secure channel with a domain controller.

MSV1_0.DLL

A library responsible for the legacy implementations of LAN Managerbased

authentication protocols.

SAMSRV.DLL

A library responsible for implementing the local SAM repository and support for
the legacy APIs.

SCHANNEL.DLL

A library responsible for implementing the Secure Sockets Layer (SSL).

KDCSVC.DLL

A library responsible for implementing the Kerberos Key Distribution Center

(KDC). This library is only active on domain controllers.

KERBEROS.DLL

A library responsible for implementing the client-side portions of the Kerberos

protocol.

NTDSA.DLL

A library responsible for implementing AD.

Table 2.1: LSA subcomponents.

Before diving into the architecture of AD, Ill talk a little more about security in AD itself. AD
stores domain security-policy information, such as domain-wide password restrictions and
system access privileges, which directly affect how the system is used. Because security-related
objects in AD must be securely managed to avoid unauthorized changes that affect overall
system security, Win2K implements an object-based security model and access control for all
objects in AD. All objects in AD are protected by ACLs. As I discussed briefly earlier, ACLs
determine who can see an object and what actions each user can perform on it; therefore, the
existence of an object is never revealed to a user who isnt allowed to see it.
An ACL is a list of Access Control Entries (ACEs) stored with the object it protects. In Win2K,
ACLs are stored as binary values called security descriptors. Each ACE contains a SID, which
identifies the user or group to whom the ACE applies, and information on what type of access
the ACE grants or denies. ACLs on directory objects contain ACEs that apply to the object as a
whole and ACEs that apply to its individual attributes. This allows control over not just which
users can see an object, but what properties those users can see. Because every object in AD has
a unique SID, AD can use impersonation and Win2K access verification to determine whether an
AD client can read or update an object. As I discussed earlier, the Object Manager mediates this
object access with input from the SRM and LSA; therefore, the OS itself controls access of client
requests to the directory. This clean design and implementation had to make no modifications to
the core authorization mechanisms in the OS.
Directory Service Module

The Directory Service Module (DSM) is the core implementation of AD functionality. As shown
in Figure 2.3, it consists of three layers of primary functionality and one layer of system
interfaces. The interesting thing to note is that AD isnt really a standards-based directory
service. Although it supports a Lightweight Directory Access Protocol (LDAP) interface and
seems to be a traditional directory service, its really a proprietary database. So while it has the
look and feel of a traditional X.500- or LDAP-based directory service, the back end is far from
standards-based.

30

Chapter 2

Figure 2.3: The AD implementation.

The Directory Service Agent (DSA), sometimes known as the Directory System Agent, is the
interface to the AD store and is responsible for creating the hierarchical namespace for AD from
the flat namespace provided by the lower layers of the DSM. Also implemented at this layer is
support for replication, enforcement of the directory schema, and policy information. The DSA
also updates rules and security information.
The Database Layer is an abstraction layer that provides access to the lower-layer storage and
search functionality supplied by the Extensible Storage Engine. All access to the database is
routed through the Database Layer.
The Extensible Storage Engine (ESE) is an updated version of the Jet database engine that has
been used in Microsoft Exchange Server. The ESE is responsible for all AD objects and has a
physical limit of 16 terabytes. This translates roughly to a theoretical limit of over 10 million
objects, but ESE only allocates storage for the space it needs. So if an object can have 42
attributes but just five are used, space is only allocated for the five attributes that are populated.
Four modules provide the front-end interface to ADSAM, Messaging Application
Programming Interface (MAPI), REPL, and LDAP. Legacy NT communications for clients that
arent AD-enabled occur using the SAM interface. Microsoft Outlook and other mail clients use
the MAPI interface. AD replication protocols use the REPL interface, and LDAP and Active
Directory Service Interfaces (ADSI) clients use the LDAP interface.

Active Directory Architecture

Now that Ive discussed the system architecture of Win2K and how AD fits into the larger
picture, its time to discuss the AD architecture itself. AD supports and integrates standards such
as LDAP and Domain Name System (DNS). It modifies the notion of domains and trust
relationships, and it introduces a number of new concepts such as trees, forests, OUs, and others.
These are some of the important concepts that Ill be discussing in this section.

31

Chapter 2
While these features are important to the overall architecture of AD, the primary concepts behind
security in AD are object protection, delegation of administration, inheritance, and transitive
trust relationships. This section will show how the architecture of AD supports these concepts.
Lightweight Directory Access Protocol
The Lightweight Directory Access Protocol (LDAP) is a standard that defines, among other
things:

A network protocol for accessing information in a directory

An information model for defining the form and character of information

A namespace that defines how information is referenced and organized

A model for defining how data is distributed and referenced.

LDAP provides a protocol and an information model, both of which are extensible.
As I discussed earlier, AD isnt really an LDAP directory as defined by the standards. But the
LDAP protocol is the mechanism for accessing AD. So while the back end is proprietary, the
main feature of the full set of LDAP standards that is supported by AD is the access protocol. In
particular, AD supports LDAP v2 and LDAP v3 access from any LDAP-enabled client.
The LDAP protocol provides a number of important features, but I want to cover just a couple of
them here. First, LDAP defines the set of operations that can be used to access ADoperations
such as search, add, delete, modify, and so on. The LDAP access protocol also defines how
operations and data are conveyed. Second, LDAP names use the X.500 standard naming
convention known as attribute naming, so you can use LDAP Uniform Resource Locator (URL)
names to access information contained in AD. For example, the following URL names a server
that supports AD and the attribute name of the object that youre interested in fetching:
LDAP://dcserver1.sheabear.com/CN=Joe.User,OU=Finance,OU=HQ,
DC=sheabear,DC=com

Obviously, there is more to LDAP than what Ive presented here, but the important thing to
remember is that AD supports LDAP only for directory services access. Its not a true LDAP
implementation at the information-storage level. While this really has no real ramification, its an
interesting point to know.
Domain Name Service
Most of us are familiar with the Domain Name Service (DNS) and its operation. But because
DNS is such an integral part of AD and how it functions, its worth spending just a little time
recapping what DNS is, how it works, and what service it provides.
From 20,000 feet, you can look at DNS as a distributed database system that creates a
hierarchical namespace for identifying computers on the Internet. The top-level domain
namespace of DNS (shown in Figure 2.4) represents the generic domains that all of us have
become familiar with, such as edu, com, gov, net, and org. Each of these top-level domains is
actually contained in a root container domain. Although it exists logically, the container domain
isnt used when we specify a computer on the Internet. For example, wed never specify a DNS
domain name as bindview.com.root; instead, we specify it as bindview.com.

32

Chapter 2

Figure 2.4: Some top-level DNS domain names.

DNS uses a simple set of conventions to create the entire tree structure that makes up its
hierarchical nature. The domain names are expressed from the child domain up through the tree
to the top-level domain, traversing each of the parent domains in-between. Each level of the
domain hierarchy is separated by a period and allows each DNS name to be expressed as a
combination of one or more domain components.
Typically, a DNS name is made up of four major components. The component furthest to the
right is the top-level domain name. The next component to the left is a formally registered
domain that allows an individual or an organization to be located on the Internet. Moving left
one more position, there can be zero or more subdomains that subdivide the registered domain.
Finally, the component furthest to the left is a host name that identifies a computer on the
network. So for example, the host jessie in the sheabear.com subdomain would have a fully
qualified domain name of jessie.us.northamerica.sheabear.com.
Relationship with Active Directory
By this point, its probably clear that AD provides a hierarchical namespace. The question that
remains is: how? Based on the title of this section, youve probably already figured it out. AD
uses the hierarchical naming structure of DNS to create AD domain names.
But why tightly integrate AD and DNS? It actually makes a lot of sense. Logically, DNS is just
an example of a global directory service with the following traits: its distributed across many
computers, it has a uniform namespace, and you get the same view of the data no matter where
you are. Viewed like this, its natural that AD would use DNS to provide its namespace; there is
no reason to re-invent the wheel. In fact, AD services are even located using queries to DNS.
Microsoft also took DNS integration with AD to another level using an enhanced version of
DNS known as AD-Integrated DNS. AD-Integrated DNS actually replicates DNS data among
Win2K DNS servers using AD replication, not the traditional zone transfers. This allows DNS
zones to be created once in an environment and eliminates the single point of failure that is
inherent in standard DNS replication.
AD-Integrated DNS requires that your DNS servers run on the domain controllers in your
environment. While it makes sense in light of the fact that AD-Integrated DNS uses AD replication, its
an important point that is often overlooked.

33

Chapter 2

Service Location Resource Records

As mentioned above, DNS queries are used to locate AD services. This is accomplished using
DNS service location resource (SRV) records. SRV records specify the TCP/IP services that are
accessible on the network in the local DNS zone. They allow networked clients to query for the
names of available servers that offer a certain protocol or service in the DNS zone. So, for
example, you could use SRV records to locate things like the Web services available in the
web.sheabear.com DNS domain.
Using SRV records is also much more efficient than the traditional method of finding services on
a network. Without the capabilities of something like SRV records, clients are typically forced to
send out a broadcast message on the network to locate the desired protocol or service.
One of the primary uses of SRV records in Win2K is to locate domain controllers that provide
logon capabilities to the AD domain. Domain controllers register several SRV records so that
other AD clients and servers can find the services offered by AD. In effect, each domain
controller dynamically registers the set of services that it provides to DNS so that they can be
located by AD-aware clients using simple DNS queries. Table 2.2 lists a subset of the SRV
records that are registered in Win2K.
This SRV Record

Allows Clients to Locate This

_ldap._tcp.sheabear.com

The domain controllers in the sheabear.com

domain. Each domain controller registers a record
of this type.

_ldap._tcp.SiteName._sites.sheabear.com

A domain controller that is part of the

sheabear.com domain and part of the SiteName
site. Each domain controller registers a record of
this type.

_ldap._tcp.dc._msdcs.sheabear.com

A domain controller in the sheabear.com domain

that holds a modifiable replica of AD.

_ldap._tcp.SiteName._sites.dc._msdcs.sheabear.com

A domain controller in the sheabear.com domain

and part of the SiteName site that holds a
modifiable replica of AD.

_ldap._tcp.pdc._msdcs.sheabear.com

The PDC role holder in the sheabear.com domain.

This is provided for down-level computers using
the domain and is registered only by the domain
controller that holds the role.

_ldap.gc._msdcs.sheabear.com

The Global Catalog (GC) for the domain tree

beginning with sheabear.com. Only domain
controllers that have a replica of the GC register
this record.

_ldap.rcp.SiteName._sites.gc._msdcs.sheabear.com

The GC for the domain tree beginning with

sheabear.com and in the SiteName site. Only
domain controllers that have a replica of the GC
register this record.

Table 2.2: The subset of SRV records that Win2K registers with DNS.

34

Chapter 2
DHCP and Dynamic DNS
The Dynamic Host Configuration Protocol (DHCP) has greatly simplified the lives of countless
network administrators. No longer do they have to assign and maintain host-name tables for all
of the networked computers in their environments. Thats because DHCP was designed to
automatically assign TCP/IP addresses and settings to networked computers. The DHCP
implementation in Win2K is much the same as in NT 4.0 Service Pack 5 and higher, but with the
additional awareness of Dynamic DNS (DDNS). This enhancement allows clients to directly
register their DHCP-assigned addresses with DDNS.
DHCP registers down-level clients in DNS automatically for each of the address leases it allows.
This facilitates the coordination between DHCP and DNS to keep clients Internet Protocol (IP)
addresses updated in the appropriate DNS zone. Unfortunately, no real standards existed to cover
this type of interaction, so Microsoft built its own mechanism, which has been posted to the
IETF for review as an Internet draft. Well talk more about the integration between DHCP and
DNS and discuss some of the security measures you should take with both services a little later
in the chapter.
Although I recommend using Win2Ks DNS implementation, you dont have to. Bind 8.2.2 and later
supports all of the capabilities that are required, but you forgo things like AD-Integrated DNS and the
interoperability Microsoft has built between their implementations of DNS and DHCP. If you already
have an implementation of BIND in your environment for your Unix hosts, you could use it for your
Win2K hosts. However, itd probably be easier for all the Unix and Win2K administrators alike if you
just added the Microsoft DNS servers as a sub-domain and use this for your Win2K hosts.

Domain Controllers
With the introduction of AD, the concept of a domain controller has changed slightly. In Win2K,
domain controllers know function as full on as peers. This is a change from the
superior/subordinate roles played by NT 4.0 Primary Domain Controllers (PDCs) and Backup
Domain Controllers (BDCs). The new peer domain controllers in Win2K support multimaster
replication, allowing full replication of all AD information amongst all domain controllers in the
domain. Multimaster replication means that administrators can now make updates to AD on any
Win2K domain controller in the domain. Remember, in the NT 4.0 OS, only the PDC has a readand-write copy of the SAM and the PDC replicates a read-only copy of SAM information to the
BDCs.
This change in the behavior of Win2K domain controllers has security consequences for any
organization that has any BDCs in environments that arent physically secure. Because BDCs are
read-only replicas, many organizations felt that a less secure physical environment was
acceptable from a risk perspective. Unfortunately, the risk of an attacker gaining access to the
physical computer that acts as a domain controller in the Win2K environment represents an unacceptable risk to an organization. This is a direct consequence of the fact that all Win2K domain
controllers now allow updates, and the updates are automatically propagated throughout the
domain. If an attacker has physical access to a domain controller, its conceivable to bring the
computer off-line, make changes to AD giving the attacker access to any domain resource they
desire, and then bring the computer back online. Once online, the illicit modifications would be
replicated throughout the environment, effectively destroying the security integrity of the entire
domain.

35

Chapter 2

Its worth pointing out that the act of promoting a server to the role of a domain controller using the
dcpromo.exe command will automatically install AD. In fact, that is the only method for installing AD
on a computer. Consequently, the AD service exists on every domain controller and only on every
domain controller.

Another change in the behavior of a Win2K domain controller, is the addition of a service known
as the Global Catalog (GC). The GC is automatically created on the first domain controller of
each domain. Well cover the GC in a little more detail a little later on in the chapter, but I
wanted to mention it here for completeness.
Objects
All AD information is stored as objects. I talked earlier about how the Win2K system
architecture and security architecture are predicated on controlling access to objects, but I didnt
define what an object is. In the context of AD, an object can be viewed as a unique, named set of
attributes that describes something, such as a user, a group, or a computer. The attributes of an
object hold the actual data that describes the thing identified by the AD object, such as a users
name, e-mail address, phone number, and so on.
While Ive talked quite a bit about AD and in general terms about the objects it stores, it may not
be clear what kinds of objects a standard Win2K AD supports. Table 2.3 lists a number of
standard objects that are created by default when AD is installed as well as some of the objects
that you can create in AD.

36

Chapter 2

Table 2.3: A sampling of Win2K AD objects.

Domains
While a number of things have changed since NT 4.0, the domain is still the core logical
grouping of objects in AD. So although there are many similarities between the domains of today
and the domains of the past, a domain in Win2K functions quite a bit differently than in previous
versions of the OS. So what does a Win2K domain provide? Fundamentally, it has the following
characteristics:

Provides object-grouping functionality for users, groups, computers, and (OUs)

This allows an organization to partition domains as required and can be used to reflect the
companys organization at a macro level.

Stores information about objects in the domainThe partitioning of AD information

into domains allows for greater scalability than a single monolithic domain.

Acts as a boundary for securitySecurity policies and settings can be enforced in one
domain without affecting other domains, where the required policies could be quite
different.

37

Chapter 2

Acts as an administrative boundaryLike the security boundary, an administrative

boundary can be established, allowing an organization with diverse administrative
practices to ensure that one group of administrators cannot affect the administration of
AD objects in another domain.

Can span multiple physical locationsWhile they provide some tangible benefits,
domains are just logical ways to partition the directory. A domain can span multiple
physical and geographical locations, and the existence of a domain doesnt force any
requirements on the physical placement of servers.

Tied to a DNS namespaceAs I discussed earlier in Relationship between AD and

DNS, domains are now tied to the DNS namespace to provide a convenient and familiar
naming convention.

Automatic and transitive-trust relationshipsAlthough really a result of the Kerberos

protocol, its worth mentioning that Win2K domains in a hierarchy are linked by
automatic and transitive two-way trusts. Ill talk a lot more about this when I discuss
domain trees and forests.

Overall, the AD-integrated domain model of Win2K should enable a large number of account
and resource domains to be consolidated into as little as one domain. This can eliminate the
complicated web of trust that tends to exist in many large NT 4.0 deployments. The resulting
trust model is both simplified and automatic.
Mixed-Mode versus Native-Mode Domains
While the goal of any Win2K deployment should be a homogeneous environment consisting of
only Win2K workstations and servers, the reality is that legacy computers will exist for some
time. Thus, Win2K supports interoperability with NT 4.0 workstations and servers in a Win2K
domain. When a domain contains a mix of NT 4.0 and Win2K servers, domain controllers can be
handled in one of two ways.

Native-mode domainAll of the domain controllers run Win2K.

Mixed-mode domainBoth Win2K and NT 4.0 computers function as domain

controllers.

By default, Win2K assumes that all domains are mixed-mode domains. So to take advantage of
the extra features provided by native mode, you must manually convert a domain to native mode.
The term mixed mode really only refers to the authentication infrastructure of a domain and is a
reflection of the makeup of the domain controllers. A native-mode domain can still support legacy
clients and servers running NT 4.0 or even one of the Win9X/Me clients. So while many people
mistakenly refer to this latter case of legacy clients in a native-mode domain as mixed mode, its more
properly referred to as a mixed environment.

38

Chapter 2
Win2K supports mixed mode to provide the greatest level of backward compatibility with NT
4.0 domain controllers, but its only really necessary in three circumstances.

You cannot upgrade your current BDCs to Win2K, and you cannot demote them to
simple member servers. While I find this somewhat of a rare occurrence, it could apply to
your environment.

The physical security of your BDCs cannot be adequately assured and can lead to
problems with illicit modifications to AD, as I touched on earlier. This can often be the
case for satellite remote offices.

The organization requires a fallback position of reverting to NT 4.0 if things go terribly

wrong during migration to Win2K. This is a valid reason for remaining in mixed mode,
but the sooner you switch to native mode, the more secure your infrastructure can
become.

So once you switch a domain from mixed mode into native mode, what are the benefits? First,
legacy domain-replication protocols are retired, and the domain begins to operate with true
multimaster replication among all of the domain controllers and updates can be made to any
domain controller. Consequently, you can no longer add BDCs to the domain. The other major
benefit is that it enables some Win2K-specific groups. Not only are the new group types
Universal- and domain localenabled, but also you become able to nest groups within other
groups. Ill talk more about these group changes in Chapter 5 when I talk about access control.
Domain Trees and Forests
While its certainly possible for an organization to have a single domain, only the smallest of
organizations will want to deploy Win2K in this manner. For the rest of us, multiple domains are
normal. Multiple domains that are organized in a hierarchical fashion that share the same
configuration information, schema, and GC information are known as domain trees, or more
simply, trees.

39

Chapter 2
The domains in a tree are automatically linked by transitive and two-way trust relationships. AD
establishes these trust relationships among the domains using the Kerberos authentication
protocol. Figure 2.5 shows a simple domain tree and the trusts that exist among the domains.

Figure 2.5: A Win2K domain tree showing trust relationships.

In this figure, if the sheabear.com domain trusts the northamerica.sheabear.com domain, and if
northamerica.sheabear.com trusts us.northamerica.sheabear.com, sheabear.com trusts
us.northamerica.sheabear.com. Using transitive trusts minimizes the number of required trusts
among domains as opposed to what would be required without transitive trusts.
Perhaps the best thing about these trust relationships is that theyre automatically created for you
when you join a domain to an existing tree. To prove the point, check out the differences in the
number of trust relationships that are required in an NT 4.0 environment as compared to a fivedomain Win2K environment, as shown below in Figure 2.6.

Figure 2.6: The reduced complexity of Win2K domain trusts.

40

Chapter 2
While trees form a contiguous namespace and form a single hierarchy, a forest is composed of
one or more domain trees, as shown in Figure 2.7 below. A forest with a single tree has a single
root, such as sheabear.com (see Figure 2.5 above). As is evident in Figure 2.7, the individual
trees in a multi-tree forest dont share a common root. However, theyre automatically linked at
the root of each tree using the same transitive and two-way trusts.

Figure 2.7: A Win2K domain forest.

You typically need to use multiple trees to support contiguous and non-contiguous naming
conventions. This tends to occur in larger organizations, where acquisitions bring multiple
naming conventions into a single, larger organization.
Domain Trusts
While transitive and two-way trusts are default trusts, you should be familiar with a couple of
other domain trusts available to you in Win2K. Theyre external trusts and shortcut trusts.
Shortcut trusts are a performance optimization that allows you to create an explicit trust
relationship between two non-adjacent domains in a single forest. Unlike the default trusts,
shortcut trusts arent two-way, and they behave like NT 4.0 domain trusts. If you need two-way
shortcut trusts between domains, you must create a pair of trusts. Figure 2.8 shows an example of
a shortcut trust.

41

Chapter 2

Figure 2.8: A Win2K shortcut trust.

Why would you want to create a shortcut trust? Using Figure 2.8, lets pretend that a number of
users in the Congo domain need to access resources in the US domain on a regular, reoccurring
basis. Without this trust relationship in place, when a user from the Congo attempted to access a
resource in the US, Win2K would have to compute the full trust path between the Congo and the
US. This path would traverse all the way up one tree, across to the other, then back down again.
Because of the number of hops that must be traversed, this could take a bit of time.
Using the shortcut trust, however, the trust path from the Congo to the US becomes a single hop.
Obviously, traversing a single hop is faster than traversing the five hops that would be required
without the shortcut trust in place.
External trusts are necessary when you need to create trust relationships with domains that exist
in another Win2K forest or with a non-Win2K domain such as an NT 4.0 domain. External trusts
operate in the same fashion as domain trusts in NT 4.0 in that theyre one-way and nontransitive. If you need two-way external trusts, you must create a pair of one-way trusts. An
example of an external trust is shown in Figure 2.9.

42

Chapter 2

Figure 2.9: A Win2K external trust.

Organizational Units
While an organizational unit (OU) is but one of many types of objects that you can create in a
domain, its perhaps one of the most important objects to understand. The concept of an OU is
important because it allows you to create another logical structure of objects in a domain. As I
said when I talked about objects earlier in this chapter, OUs are simple container objects that can
contain other objects. The fact that OUs are containers allows you to create a logical, hierarchical
namespace within the confines of the more physical namespace of a domain.
One of the nice features of an OU is that its relatively simple to create logical groupings of
users, computers, groups, and other OUs. These groupings can be easily created, deleted, or
moved without disturbing the domain trust relationships that exist in your environment. This
allows the logical structure that you use to model your organization to be flexible and scalable,
while benefiting from a small number of domains. Other nice features of an OU are that it can be
used to delegate administration and that it can limit the scope of policy enforcement.
From a security perspective, perhaps the most useful feature of an OU isnt the OU itself but how
it can be used in conjunction with Group Policy Objects (GPOs). Ill talk a lot more about GPOs
in the next chapter. For now, just think of a GPO as a security and configuration template, or
policy, that can be applied to a domain, an OU, or an individual computer.
Administrative Privileges
One of the more frustrating features of NT 4.0 was the all-or-nothing model of administrative
privilege, where even the most mundane tasks required the administrator to be a member of the
all-powerful Domain Administrators group. Thankfully, with the implementation of Win2K,
things have changed.

43

Chapter 2

Dont confuse administrative rights in AD with local rights on a local computer. While you may have
an account that has full administrative privilege over a computer object in AD, your account may not
be a member of the computers Administrators group. There is no correlation between privileges in
AD for a computer object and local rights on the physical computer. For example, lets say that youre
delegated full control over a number of computer objects in AD. This allows you to make changes to
the computer object in AD. Unfortunately, this delegated control doesnt automatically extend to the
computers themselves. To gain administrative control of the actual computers, your account has to be
added to the local Administrators group; this doesnt happen automatically.

Using AD as the storage repository for all security account information allows users, computers,
and groups to be instantiated as objects in AD. As a result, standard capabilities that are part of
the AD architecture are available to security account information. In particular, three capabilities
greatly enhance the ability of an organization to control administrative access to security account
information.

Delegation of administrationCan confine the security administration capabilities of a

user to apply only to defined subsets of an entire domain. For example, this allows an
administrator to manage a set of users, computers, or groups within his or her area of
responsibility and, at the same time, not give permissions to manage accounts in other
parts of the organization.

Fine-grained access rightsAllow you to grant access rights for specific operations.
For example, you can grant administrative capabilities, such as resetting user passwords
or disabling accounts, to specific groups without also granting permission to create new
accounts or change other properties of user accounts.

Inheritance of access rightsAllows you to grant access to a higher-level container of

the directory and have the rights flow down to the sub-containers and leaf objects. For
example, you can modify administrative capabilities on entire portions of the directory
tree by making changes to a specific container; this automatically affects all subcontainers and leaf objects.

These three AD capabilities allow you to grant administrators the requisite privileges to do their
jobs without granting them more privileges than they actually require. So while in NT 4.0
environments, administrators must be domain administrators even if the only right they require is
to reset user passwords for a pool of 25 users, ADs delegation of administration and finegrained access rights allow you to configure Win2K to enable administrators to reset users
passwords for the pool of 25 users without allocating any other administrative privileges.
Thus AD allows you to assign and manage administrative privileges without the all-or-nothing
paradigm of NT 4.0. This capability to delegate privileges can greatly reduce the number of
Win2K domain administrators required to administer your environment compared to the number
that exist in current NT 4.0 environments.

44

Chapter 2

Sites
When I talked about DNS SRV records earlier in this chapter, Table 2.2 mentioned the notion of
a site. A site is nothing more than one or more TCP/IP subnets that are connected by a highspeed link. (Typically, a high-speed link is considered to be a T-1 connection or higher; failure to
follow this guideline could result in AD replication problems.) While a site typically has the
same boundaries as your LAN, there are no rules that limit a site to a geographic region. As long
as the subnets are well connected, they can belong to the same site.
A site is primarily used to determine the replication topology among the domain controllers in a
domain. In a site, intra-site replication is conducted strictly using Remote Procedure Calls
(RPCs). Among sites, inter-site replication can be conducted using either RPCs or a messaging
protocol.
Computers also use a site to find a domain controller that is logically closest to it. Typically,
when a user logs onto a workstation, the computer will want to authenticate using a domain
controller in the same site. Because the workstation knows what subnet its on, it begins its
search for a domain controller in its own site; only when the client cannot find the needed service
in its own site will it search outside its site for the service.
Multimaster Replication
The term multimaster replication has been used a few times throughout this chapter, and youre
probably wondering what the heck it is. While you know that AD uses multimaster replication
and you know its benefits, this is where Ill finally describe how it works.
Data Partitions
First and foremost, the data stored in AD is partitioned into three distinct categories.

Domain data partitionContains all of the objects for a domain and is replicated to all
of the domain controllers only in its own domain, never to other domains.

Schema data partitionContains all of the definitions for all the objects that can be
created in AD and is replicated to all of the domain controllers in its forest.

Configuration data partitionContains the replication topology and other

miscellaneous information that is replicated amongst all of the domain controllers in a
forest.

On a GC server, a fourth type of partitioned data existspartial data. The partial data partition
contains a partial set of attributes for all of the objects in a forest. Its a read-only data partition
that is automatically created from all the objects in the forest.
These data partitions are replicated transparently and automatically whenever an update is made
to one of the domain controllers. Its known as multimaster replication because any of the
domain controllers can receive an update and replicate it to the other domain controllers. This is
a significant difference when compared to the masterslave model of single-master replication
that existed in NT 4.0.

45

Chapter 2
Replication of these data partitions occurs over what are known as replication transport
protocols. AD supports two main protocols: RPC and Simple Mail Transport Protocol (SMTP)
over TCP/IP. The RPC protocol is really the better protocol to use for intra-site and inter-site
replication, but you can also use SMTP for inter-site replication.
The SMTP protocol is limited to inter-site replication, and it cannot replicate the domain data
partition, so even if you have reason to use SMTP, you also have to use the RPC transport.
Therefore, while you can choose one or the other protocol for specific replication purposes, its
probably best to stick with RPC for all replication traffic unless you have specific instances
where slow links warrant using the lower-bandwidth SMTP protocol.
How It Works
Multimaster replication sounds great, but what happens when two administrators try to update
the same object at the same time? Take a very simple case of a domain with two domain
controllers. You make a change to the CEOs phone number on one domain controller, and I
make a different change to the number on the other domain controller at almost exactly the same
time. Now each domain controller has a different value for the CEOs phone number, and youll
retrieve different results depending on which AD server you query. Not to worry, you say,
replication will fix it all up.
But what if both domain controllers replicated their changes to each other at exactly the same
time? There are still two different values for the CEOs phone number, but now theyve switched
places! Microsoft understood this problem and devised a scheme to avoid synchronization
problems that uses a combination of time stamps, Update Sequence Numbers (USNs), and
Property Version Numbers (PVNs).
The concept of using a time stamp to mark when a change has occurred is pretty well
understood, but what value does the USN add? Well, the USN is a simple 64-bit number that is
maintained by each domain controller in a domain. So if there are 10 domain controllers in your
domain, there are 10 USNs, one held by each domain controller. For each write that a domain
controller carries out to its local replica of AD, it increments its USN and stores this value with
the property, which was written as a single atomic operation. Using an atomic operation ensures
that the USN is never incremented and isnt stored with the property in the case of a catastrophic
computer failure after the USN is incremented and before its written.
While each domain controller has its own USN, it also keeps a table of all the USNs that are
received from other domain controllers during replication operations. When two domain
controllers decide that replication is required, each can compare its current USN with the USN of
the other. All USN values that are greater than the last USN received need to be replicated to
bring the two AD replicas into synchronization.
This comparison of USN values also makes it easy to recover from any interrupted replication
cycles. To restart a replication, a domain controller only needs to ask its peer for all of the
updates with USNs greater than the last USN it wrote in its table.

46

Chapter 2
While the USN is used extensively to ensure that updates are properly replicated, the PVN
carries the heavier burden by ensuring that when a change is made to the same object attribute on
multiple domain controllers at about the same time, AD holds a consistent value across all of the
separate replicas. This occurrence of an object attribute being updated on multiple domain
controllers before the first change is fully propagated is known as a replication collision. Its the
function of the PVN to sort out replication collisions.
Unlike a USN, which is a domain controllerspecific value, a PVN is an object attributespecific
value. Every object attribute has its own PVN, which is initialized when the attribute is first
written to AD. Whenever a write to the object attribute is carried out on the system that is
initiating the change, the PVN is incremented. This means that object attribute writes that occur
during a replication operation dont result in an update of the PVN.
A replication collision occurs whenever a change is received using replication that has the same
PVN for the incoming update as exists in the local object attribute. Whenever this situation
arises, the value that has the later time stamp is the one that is written. When the received PVN is
lower than the local PVN, the update is considered stale and discarded. But when the received
PVN is higher than the local PVN, the update is written to the local AD replica.
I ended up spending quite a bit of time talking about replication, but thats fine. Without it, AD
and Win2K wouldnt be as robust an OS platform as it is. Besides, replication-collision detection
and dampening are pretty cool.
The Global Catalog
As I just discussed, domain data is replicated among all of the domain controllers in a domain,
but its not replicated with other domains. Inter-domain replication of domain data does occur for
every object in a domains data partition, but with a limited subset of attributes. These interdomainreplicated objects are stored in the Global Catalog (GC) on a subset of the domain
controllers in your environment. By default, the first domain controller of a new domain is also a
GC server. But youre not stuck with this configuration, and you can move the GC at a later date
or add more if required.
Now that you know you have a GC in your Win2K environment, what is it used for? Quite
simply, the GC speeds up LDAP searches that need to occur across your entire forest. Because
all of the GC data is contained in a single data partition replica, queries are much faster than the
alternatives. Without the GC, either each domain would have to keep a complete copy of every
other domains domain data partition or queries across the entire forest would have to search
multiple physical data partitions in each domain in your forest.
Neither case sounds very attractive. Thus, using the GC greatly simplifies searches across the
entire forest when you know only a couple of the attributes of what youre looking for and you
have no idea which domain stores the object.

47

Chapter 2

Operational Roles
Ive covered a lot of territory, but there is one caveat to the design of Win2K that allows writes
to all of the domain controllers in a domain. Specifically, some of the changes that need to be
made to AD have implications for the entire forest and/or for some very important domain
properties. For these types of AD updates, a single domain controller is required to control
replication and ensure that critical changes are correctly propagated before the next set of critical
changes begins. In effect, a single domain controller must lock out all other domain controllers in
the domain from making certain types of updates to AD. The lockout mechanism for critical AD
updates is the Flexible Single Master Operation (FSMO, often pronounced fizmo) roles.
The scope of a FSMO role is either a single domain or the entire forest. As a result, only a single
domain controller in the appropriate domain or forest scope can serve as the FSMO role holder at
any one time. However, different domain controllers can take on the role if required. So if a
domain controller that is serving as a FSMO role holder fails, you can manually assign the
operational role to a different domain controller. Table 2.4 shows the five FSMO variants
supported by Win2K.
This Role

Does This

Relative Identification (RID)

master

Allocates the sequences of relative IDs (RIDs) to each domain

controller in its domain. When a domain controller creates a security
principal, the domain controller assigns the object a unique SID. The
SID consists of a combination of a domain ID and this RID. Only one
RID master can be active in a domain at any time.

Schema master

Assigned to the only domain controller that is allowed to perform writes

to the AD schema. The schema updates are replicated from this
domain controller to all of the other domain controllers in the forest.
Only one schema master can be active in a forest at a time.

PDC emulator

Assigned to the only domain controller that can act as a Windows NT

PDC in a domain. This domain controller services network clients that
arent AD-aware and handles replication to NT BDCs for the domain if
its still in mixed mode. When the domain is in native mode, the
domain controller assigned this role receives preferential replication of
password updates that occur on other domain controllers in the
domain. This allows it to handle any password authentication requests
that have failed at another domain controller. Only one PDC emulator
can be active in a domain at any time.

Infrastructure master

Assigned to the only domain controller that can update cross-domain

group-to-user references to reflect changes in a users name. The
domain controller assigned this role updates these references locally
first, then replicates them to the other domain controllers in the
domain. Only one infrastructure master can be active in a domain at
any time.

Domain naming master

Assigned to the domain controller that can add new domains to the
forest, remove existing domains from the forest, and add or remove
cross-reference objects to directories external to its forest. Only one
domain naming master can be active in a forest at any time.

Table 2.4: Win2K FSMO roles.

48

Chapter 2
By default, the first domain controller in a forest is assigned the forest-wide roles, and the first
domain controller in a domain is assigned the domain-wide roles. As a result, the first domain
controller in your forest will by default hold all five roles simultaneously.

Active Directory Tools and Troubleshooting

A pure security professional may not have to solve AD replication and schema problems, but
most of us end up wearing many hats. As a result, even a hard-core security person needs to be
able to jump in when required and understand the implications of the problems. The security pro
definitely needs to know a number of things, both about the standard administration tools of AD
and the tools required to troubleshoot problems with AD when they arise.
For more detailed information on how to administer AD, I recommend that you check out another free
eBook, The Definitive Guide to Windows 2000 Administration, which you can find at
http://www.realtimepublishers.com.

Administration Tools
To adequately ensure the security of your Win2K infrastructure, its helpful to understand the
core MMC snap-ins that are used to manipulate, configure, populate, and maintain AD. My goal
here isnt to teach you how to navigate all of the intricacies of each snap-in; instead, its to make
you aware of these tools so that you can spend some time familiarizing yourself with them in
your own environment. Table 2.5 below lists the main MMC snap-ins that you should become
very familiar with to administer AD.
This MMC Snap-in

Does This

AD Domains and Trusts

Administers the domains and trusts in a Win2K forest.

AD Sites and Services

Administers sites and some of the additional services in a Win2K

environment. This snap-in doesnt administer services such as DNS
and DHCP; they have management snap-ins of their own.

AD Users and Computers

Administers users, computers, groups, OUs, and other domain objects

in a domain.

Table 2.5: Core MMC snap-ins for administering AD.

Delegation of Control Wizard

One of the tools that youll probably want to become familiar with is the Delegation of Control
(DoC) wizard. Using the wizard allows you to quickly delegate the administration of prespecified tasks to security groups. What does the wizard do for you? It modifies the ACLs on AD
objects according to the options you select.
Be careful how you use the DoC wizard. One of its drawbacks is that its designed to grant access to
AD objects, but it cannot remove or deny access to AD objects. In addition, when it modifies an ACL,
it tends to create an exorbitant number of ACEs. More than likely, youll want to use the wizard when
youre first playing with the security of an AD object just to get a feel for things.

49

Chapter 2
Backup, Restore, and Disaster Recovery
One of the primary security objectives that I laid out in Chapter 1 was availability. While
everyone knows its important, some of the most overlooked aspects of an organizations
availability program are still backup, restore, and disaster recovery procedures.
The easiest way to back up your AD is to use NTBACKUP.EXE, the Win2K backup and restore
tool. You can use the NT Backup (or simply Backup) tool to back up and restore AD and many
other services running on your Win2K systems. The Backup tool backs up and restores an entire
system, just selected files, or the System State data.
Its in the category of System State data that AD resides. In fact, AD and all of the other system
components and services that it depends on are considered part of the System State data. On a
domain controller, the System State data includes the system startup files, the Registry, the File
Replication service (FRS), the SYSVOL directory, a few other important services if theyre
installed, and of course AD. When the Backup tool creates an archive of AD, it includes the
following files (typically stored in the C:\WINNT\NTDS directory): NTDIS.DIT, EDB.CHK,
EDB*.LOG, RES1.LOG, and RES2.LOG. The NTDIS.DIT file is the actual AD database, the
CHK file is used to checkpoint updates to the AD database, and the logs keep a record of each
transaction that has occurred in AD.
While all of this is fun information to have, the Backup tool contains wizards that guide you in
backing up and restoring your AD. But to ensure that you have a complete copy of your
computer and the System State data, you need to skip the wizard and go right to the Backup tab.
Make sure that you select every local drive and the System State check box to ensure that you
have a complete copy of the computer and AD.
Unfortunately, you must perform a backup on every domain controller in the enterprise to
entirely back up AD. This is because the Backup tool cannot back up a remote computer and can
only back up a local computer. While this is a known limitation of the Win2K Backup tool,
many third-party backup tools can remotely back up and restore AD. How much of an issue is
this really? As usual, it depends.
The simplest way to restore a damaged domain controller is to just start over using a fresh
installation of the OS. Once youve installed the server, you can promote it to a domain
controller and follow standard replication procedures to repopulate the local contents of AD. For
this technique to be successful, you obviously need to still have functioning domain controllers
in your environment. This method is useful when you experience a simple hardware failure and
you want to get the domain controller back in service.
While the first method of restoring AD will get the local AD back in synchronization with the
other domain controllers in your environment, what happens when your AD becomes corrupted,
or worseyou lose all of your domain controllers because of a catastrophic failure, and you need
to invoke disaster recovery procedures? The answer is to use the last known good backup that
youve created, one that contains all of the system drives of one of your domain controllers and
the System State data.

50

Chapter 2
Known as an authoritative restore, all of the restored objects can take precedence over any other
instances of those objects on other domain controllers. The first step is to perform a standard
restore of the domain controller, the System State data, and all of the system drives. Then use the
NTDSUTIL.EXE tool to mark restored objects as authoritative. Objects that are marked as
authoritative are propagated using standard replication mechanisms and update any existing
copies of the objects.
An authoritative restore has no affect on objects that were created after the backup, from which
youre restoring, was created.

Basic Troubleshooting
While you may never have to help troubleshoot AD problems, its useful to have a basic
understanding of AD troubleshooting techniques. Overall, problems with AD can be broadly
organized into five categories.

Network connectivity troubleshooting

Name resolution troubleshooting

Domain controller troubleshooting

Authentication troubleshooting

Access control troubleshooting.

While I wont discuss these troubleshooting categories at length, the discussion should help you
understand how to deal with AD when problems arise.
The first thing you should always check when youre experiencing problems with AD is your
network connectivity. Run the IPCONFIG /ALL command to retrieve the TCP/IP network
settings of your computer. If you have a valid IP address and default gateway, your network
settings are probably valid, especially if they were retrieved from DHCP. If everything looks
good here, next ping the default gateway to ensure that the network itself is working. If
everything looks correct and youre still experiencing problems, it may be worthwhile running
the NLTEST and NETDIAG tools from the Win2K Resource Kit.
If everything looks good at the network level, the next course of action is seeing whether DNS is
operating properly. Ping each of the DNS servers that were listed after running your previous
IPCONFIG command. If they all appear to be alive, try a couple of NSLOOKUP commands to
ensure that your DNS services are actually running. Once again, other tools that might be useful
include NBTSTAT and the Resource Kit tool DNSCMD.
Next check the domain controllers themselves by running the DCDIAG tool to get a look at the
state of all of the domain controllers in your forest. Another tool that you can use is NTDSUTIL.
It checks domain controller data-consistency issues and allows you to do things like remove
orphaned domain controllers and domains, view directory partitions, and manage FSMO roles.
Another tool that can be useful is the DSASTAT tool, which you can use to examine the
differences among objects on two different domain controllers.

51

Chapter 2
If your computer cannot be joined to a domain or is experiencing other authentication difficulties
in talking to other domain computers, you need to investigate potential authentication problems.
Tools such as NLTEST, NETDOM, NET USE, and LDP can help you get to the bottom of many
of the authentication issues you may be facing.
Finally, when you try to use other resources on the network, you may run into problems with
access control. Once again, NETDOM may be of some help, as well as tools such as DSACLS
and SDCHECK. The DSACLS tool is interesting in that it lets you display and modify the ACLs
of an AD object. While you should probably not play with AD ACLs too much, its very
informative to just poke around and see what you can find.
As usual, some of the best tools and information that you need to keep your AD infrastructure up and
running is contained in the Win2K Resource Kit. If you dont have a copy of this indispensable
collection, I highly recommend that you get yourself a copy.

Active Directory Best Practices

Win2K has been around for well over a year now, but there isnt a lot of consensus about how to
best provide security in AD. This can be partly attributed to the fact that AD is actually quite
complicated and not as well understood as it should be. Ive even heard that Microsoft has
problems trying to fully understand the complexities of AD. Another reason is the lack of AD
implementations that are out there.
Sure, Microsoft and a few other large organizations have implemented AD in their environments,
but most organizations have taken a wait-and-see attitude toward AD; theyve deployed Win2K
to their desktops and server infrastructures while leaving their NT 4.0 domain infrastructure fully
intact. Nevertheless, there are some basic best practices when it comes to AD that I dont think
many people would argue with. This will be the focus of this section.
Native-Mode Domains
A homogeneous Win2K environment provides the optimum security capabilities for your
enterprise. Unfortunately, many organizations find this a lot harder to achieve than youd first
anticipate. All too often, applications that are critical to the success of your business are running
on a legacy version of NT, and management is afraid to touch them, or the applications just
wont run on Win2K for some reason. Even worse, you may run into the stubborn vice president
who just cant live without his trusty old Pentium 90 running Windows 95. So while your goal is
to have all your computers running Win2K, it may not be feasible to achieve it immediately.
If you cant update your entire environment to Win2K, I suggest that you at least run your
domain infrastructure as a homogeneous Win2K environment in native mode. Using the PDC
emulator role, your domain infrastructure can still support down-level, non-ADaware
applications while experiencing the benefits of running in native mode.

52

Chapter 2

Domain Forests
When you first deploy AD in your enterprise, youre best off starting with a single forest design.
This design is the simplest to create and maintain. It also benefits from the fact that all of your
domain trusts will be automatic, two-way, and transitive in nature. Your users will also benefit
because they only have to search a single forest to find resources in the environment.
Im a strong believer in a single-forest implementation, but situations do arise that necessitate
creating more than a single forest. Typically, a multiple-forest deployment becomes necessary
because of trust issues and the need to isolate a domain in one forest from other domains in other
forests. These issues of trust tend to arise when different parts of an organization want control
over the ability to add and delete domains from the environment, control over schema
modifications and change procedures, and tighter control over who accesses their resources.
While I strongly urge a single production forest for all of your users, you might want to keep a
separate forest for integration testing with your environment. This will allow you to design
solutions for your enterprise without disturbing your core business.
Domains and Domain Trees
I lean heavily toward a single forest for most organizations, but I dont think its necessarily the
best approach for all organizations with regard to domain trees. If your organization is relatively
small and located in a single geographic region, maybe a single domain is best for you.
Microsoft, and others, urge adopters of AD to start their designs with a single domain, and they
seem to believe that there are only three reasons to use more than a single domain: to preserve
any existing Windows NT domains, to create administrative partitioning, and/or to create
physical partitioning.
While I understand the rationale behind the first reason, I dont really buy it. Many deployments
of NT 4.0 domains suffer because of the limitations of SAM. There is no reason to carry this
baggage with you as you build your Win2K infrastructure. Its the second two reasons that I
think should drive all but the smallest organizations to consider at least two domains.
You also need to consider multiple domains if a variety of security policies exist for user and
password policies. Although Ill talk about this more in the section on Group Policy, Id like to
point out now that there is a small set of security policies that can only be applied on a domain
basis. These policies apply to domain user accounts as follows: password policy, account lockout
policy, and Kerberos policy.
There is also another reason why you might consider multiple domains, and that is if your
organization uses multiple DNS domain names. This often occurs when one company is acquired
by another, but there are many other situations in which you may need to support multiple
domain trees. Its also hard to predict what future mergers and acquisitions your organization
may be involved in, so even if you do end up with a single domain implementation of AD, you
need to have a plan for incorporating more in the future.

53

Chapter 2

Organizational Units
The first thing that everyone is tempted to do when they start designing their OU structure is to
model it after the structure of their organization. I have one thing to say about this: Dont do it.
Creating an OU structure that mirrors your business structure will prove very difficult to
maintain. Sure, OUs are much easier to create, delete, move, and manage than, say, a domain,
but it isnt wise to follow this path.
In my opinion, Microsoft made a mistake when they called this container an organizational unit.
From my perspective and in my experience, it should have been called an administrative unit.
This is where OUs are really at their best. OUs should be used for delegating administration, not
creating some pretty hierarchical tree in your Active Directory Users and Computers MMC snapin. When youre designing the OU structure for each of your domains, I believe that you should
only create OUs when you want to delegate administration. Ive heard others suggest that you
should also create OUs to apply Group Policy or to hide objects. Ultimately, I believe in keeping
it simple and only creating an OU to help delegate administrative functions.
Overall Design
You may be wondering how I would design your AD infrastructure. The answer is difficult
without knowing an awful lot about your organization, your existing infrastructure, the current
challenges with your NT domains, and so on. But I can discuss in general how Id set up my
fictitious company SheaBear Inc. You saw the finished domain model earlier, but how did I get
there? As with all examples, this one is a little contrived. But hopefully when Im through, youll
understand why I think that this sort of structure is best. Ive included the figure again below (see
Figure 2.10).
Lets suppose that SheaBear Inc. is a multinational company with a large presence throughout
North America, Europe, and Asia. As a result, it has three distributed IT departmentsone for
the US and Canada, another for Europe, and a third for Asia. Now lets walk through how the
company arrived at the final design for its AD infrastructure.

Figure 2.10: The forest structure for SheaBear Inc.

54

Chapter 2
The first thing to notice in this example is that there is a single forest. While individual IT
departments throughout the world wanted control of their own schema and basic configuration
information, they quickly realized that this would create an unnecessary burden on their user
population and affect the overall performance of their Win2K infrastructure. They decided that a
single GC was advantageous so that searches in AD would have a reasonable response time. If
theyd built multiple forests, with a lot of trust links, user performance and ease of use could
have suffered.
The IT departments still wanted control of the schema, so they decided that no single IT
organization should have full responsibility for updating the schema. Someone suggested that a
committee with representatives from each IT department be formed to control the forests
schema. Even with this suggestion, each IT department was leery of letting one of the others
have the schema master FSMO role in their own domain.
Finally, the departments decided that if they created one domain providing only infrastructure
services, they could share responsibility for administering it. As a result, they decided to create a
simple container domain that would hold nothing but domain controllers and infrastructure
services (for example, DNS, DHCP, and Certificate Services) and be tightly controlled with no
users or standard computers. This became the internal.sheabear.com domain in my example.
Another point worth making about this initial container domain is that its not the companys
registered domain name. Instead, its a subdomain of its registered name. This allows the internal
(and hence the container domain name) environment of the company to be logically, and
administratively, separated from any of the public services that the company provides over the
Internet.
While the container domain was a great compromise, the IT departments still wanted to be the
masters of their own domains. So they quickly decided that beneath the root container domain,
theyd create three domains, one for each of their respective organizationsNorthAmerica,
Europe, and Asia. All in all, they were feeling pretty good that this would be their final domain
structure.
As the IT departments were getting ready to publish their two-tier domain model to the rest of
the company, someone familiar with local security practices and national regulatory
requirements realized that Japan had much stricter requirements on certain things. As a result, it
was decided to break Japan out of the Asia domain and create a third hierarchical level in the
domain structure. On further thought, it was decided to separate the United States and Canada
out of the NorthAmerica domain for similar reasons. But because of the unified nature of the
European Union, the IT department in Europe felt comfortable keeping a single domain.
With the design of the forest and the domain tree decided on, each IT department had to then
decide how to use OUs to further refine its delegation of administration. To simplify things quite
a bit, only the OU design of the US domain is shown below in Figure 2.11.

55

Chapter 2

Figure 2.11: OU design of the US domain of SheaBear Inc.

By default, each domain starts with a Domain Controllers, Computers, and Users OU. As the
names imply, these are the default locations for these types of AD objects. All domain
controllers are automatically put into the Domain Controllers OU, all other computer objects are
automatically put into the Computers OU, and users are automatically put into the Users OU.
While these defaults are adequate for a small organization, in which a single group handles the
administration of the domain, it wasnt a good fit for SheaBear Inc.
The North Americabased IT department was organized into specialized teams to maintain and
administer the US-based computing infrastructure. One administration team was responsible for
all of the servers, a second for all of the desktops, a third for all user administration including
creation, deletion, and password reset type duties, and a fourth for administering SheaBears
world headquarters.
The headquarters administration team was actually made up of two specialized administration
teams, which were wholly responsible for the Finance and Human Resources departments. These
two teams were kept small and separate to ensure that very few individuals had access to the
sensitive data these departments kept.

56

Chapter 2
Based on its structure and the OUs that were created by default, the US IT group decided to
create just four OUs. The team that traditionally had responsibility for all of the servers in the
environment took administrative control of the Domain Controllers OU and the newly created
Servers OU. All member servers in the infrastructure would be administered using this new OU.
The desktop administration group took control of the Computers group because it would now
only contain desktop machines. The user administration group took control of the Users group so
that it could continue to service the user accounts throughout the US. Finally, the headquarters
administration group created the final three new OUs to mirror its administrative structure.
When I think about the best designs for AD, I try to keep the following principles in mind:

Always use a top-level container domain to segregate the administration of enterprisewide functions like schema modifications and core infrastructure services. Never put
users or standard servers or workstations in this container domain.

Base your second- and possibly third-level domains on geographic regions. But never go
more than two or three levels deep; otherwise, the depth of your domain hierarchy will
start having adverse affects on the performance of your infrastructure.

Build OUs in domains to reflect the administrative structure in your organization and
create a simple model for delegated administration.

Simple is best. Resist the urge to construct OUs based on your business hierarchy, which
will be changed by mergers, acquisitions, and reorganizations. This constant change
would have you constantly modifying your OU structure.

Delegated Administration
One of the great promises of AD was its ability to provide delegated administration. As I
discussed earlier in this chapter, the Delegation of Control wizard is the primary tool provided by
Win2K for delegating administrative functionality.
In Chapter 1, I talked briefly about role-based authorizations. When it comes time to delegate
administrative tasks, role-based authorizations are the best approach. The first step in creating a
role-based authorization is to create a new security group, then use the Delegation of Control
wizard to delegate the appropriate AD rights to the group. As people need to perform this role,
you can add them to the appropriate security group.
Never assign rights, privileges, or ACLs to an individual computer or user object. Instead, create a
security group, assign the appropriate permissions to it, then add computer or user objects to it. For
example, say you found out that your Help Desk needed permissions to perform another task.
Changing permissions or privileges on a single group is far preferable to modifying a couple of
hundred individual user objects.

57

Chapter 2
While its tempting to create a few dozen administrative roles right from the start, I strongly
caution you against it. AD is so complicated that Ive seen entire Win2K domains dismantled
because delegated administration groups were missing key rights or privileges in AD that kept
them from functioning. I recommend that you strive initially for three to four levels of
administration delegation, as follows:

Help-Desk AdministratorsPrimarily to troubleshoot and reset passwords

AD AdministratorsTo add and delete users, groups, and computers but not reset
passwords

Domain AdministratorsBuilt-in group with control over an entire domain

Enterprise AdministratorsBuilt-in group with control over an entire forest.

While this is better than what NT 4.0 provided right out of the box, its probably a lot less than
you expected after hearing all the hype about Win2Ks delegation of administration capabilities.
If you want more than three or four roles (and who doesnt), I strongly urge you to consider
using a third-party tool to manage administrative roles.
One of the rumors on the street is that even Microsoft figured out that administering AD with its
own tools wasnt going to work, so it uses a third-party product. But in its defense, it seems to
have been very clear during the development of Win2K and AD that Microsoft actively
encouraged third-parties to fill in the administration gaps left behind in the OS.
If youre interested in third-party administration tools for Win2K, here are three products that you can
evaluate:
bv-Admin for Active Directory from BindView Corporation (www.bindview.com)
ActiveRoles from FastLane Technologies (www.fastlane.com)
Enterprise Delegation Manager from Aelita Software Corporation (www.aelita.com)

Securing DHCP and DNS

If youve ever experienced a rogue DHCP server, you know what a mess it can cause. In a
standard DNS environment, you could end up with duplicate IP addresses and communications
among computers being interfered with. In a DDNS environment, requests for name resolution
can be given incorrect addresses and further confound your users. Win2K does provide some
limited protection against rogue DHCP servers, but only if theyre also running on Win2K.
By default, a DHCP server running on the first domain controller of a forest is authorized to
dispense IP addresses, but any other installed DHCP server must first be authorized in AD. To do
this, choose Action>Authorize in the DHCP MMC snap-in. Keep in mind, though, that to
authorize new DHCP servers, you must be a member of the Enterprise Administrators group.
(This is discussed in Chapter 5.)
Authorizing a DHCP server before it allocates addresses wont keep someone from installing a DHCP
service on a computer. But if its installed on a Win2K domain member server or domain controller, itll
keep the service from running. To ensure that your environment is devoid of non-Win2K, rogue DHCP
servers, youll have to perform regular network audits.

58

Chapter 2
Once your DHCP servers are all running on Win2K and authorized in AD, turn your attention to
securing your Win2K DNS servers. You can easily secure DDNS by configuring it for secure
updates. This requires that your DNS zones are AD-integrated zones, that you modify zones to
allow Only Secure Updates, and that you specify which users and groups can modify zones and
resource records using ACLs.
Once youve configured DDNS, only computers with domain accounts can create DNS records,
only the computer that created a record can update it, and zone updates are accepted only from
the DNS servers you specify in your ACLs. If you still have legacy clients, dont be concerned;
if they use the secured DHCP server, it will add and own the DNS record for the client.

Active Directory Security Vulnerabilities

Like most Microsoft products, you can bet that Win2K and AD have received some pretty
intense scrutiny. Nevertheless, two significant security-vulnerability claims have been made
against AD explicitly. Although neither one is really a vulnerability, both underscore the fact that
if youre going to successfully deploy AD in a large enterprise, you must do your homework and
understand it from top to bottom.
Novell made the first security-vulnerability claim just as Win2K was hitting the marketplace.
Novell asserted that AD was flawed because it was possible for someone to believe that they had
complete, private control over an object in AD when in fact someone else could also have access.
Novell based its argument on a scenario in which a manager of an OU wants to have sole
ownership of the information contained in the OU. Novell asserted that because someone else
could own the OU, the manager couldnt be assured of having sole ownership of the OU.
Novells belief that AD contained security vulnerability either stemmed from a misunderstanding
of how AD works or was an attempt to exploit the fact that its directory service operated in a
different fashion. In either case, there was no real security vulnerability because every object in
AD has both an owner and an ACL. While the ACL determines who is allowed to access the
object, the owner of the object retains ultimate control of the object.
The other security-vulnerability claim centered on the replication of Multi-Value Attributes
(MVAs). While I covered replication earlier in the chapter, I didnt talk explicitly about MVAs.
MVAs are object attributes that contain multiple values. In particular, security groups are one of
the biggest users of MVAs because all the members in a particular security group are stored in an
MVA of the security group object.
How does this problem show up? It goes back to the scenario where two administrators make a
change to an object before the replication for the first change completes. For example, lets say
that two administrators want to change the Domain Administrators security group. One
administrator on a domain controller adds the user Bob, while the other administrator on another
domain controller removes the user Alice at about the same time.
Ive talked about how AD resolves replication collisions, but when an MVA is involved, things
can go wrong. Because any change in an MVA causes the entire attribute to be replicated, two
group members attributes are now being replicated on the two domain controllers. One update
has the original contents of the Domain Administrators group plus Bob; the other has the original
contents of the Domain Administrators group minus Alice.

59

Chapter 2
No matter what the replication collision decision, one of these updates is going to be lost. But it
becomes a security vulnerability only if the change that removed Alice is discarded and
overwritten by the update that added Bob. Thats because an unauthorized user, Alice in this
case, is still a member of a security group that she was supposedly removed from.
Is this a security vulnerability? I may not get agreement from a lot of other folks, but yes, I think
it is. Is it a big deal? No, its not. Microsoft has known about this problem since before it
released the product to manufacturing, and if you do your homework and read up on AD, youll
find that the problem is reasonably well documented. In fact, the workaround for this problem is
relatively simple. Remembering the FSMO roles, just treat updates to security groups as though
there were a Security Group Update Master role and create the right policies and procedures so
that all administrative changes to security groups happen on a single computer in each domain.

Summary
The consensus throughout the industry seems to be that AD is the most significant new feature of
Win2K. Clearly, its the centerpiece of Win2K, and it provides the foundation for many of the
new features and benefits of the OS. So although Ive not really done AD justice in this short
space, Ive talked about the key features and services that AD provides, how theyre
implemented, and how to use and administer them. You must understand these features and
services if youre going to successfully secure your Win2K infrastructure.

60

Chapter 3

Chapter 3: Managing Group Policy Security

Group Policy is part of Microsofts effort to reduce the amount of administrative overhead that is
required in Windows 2000 (Win2K), and its part of a larger technology collection known as
IntelliMirror. In fact, Group Policy acts as the foundation of IntelliMirror technologies and
requires both Active Directory (AD) and Win2K client computers. While the IntelliMirror
technology umbrella is quite interesting, however, this chapter is all about Group Policyhow it
works, what it can do for you, and how to use it to your organizations best advantage to provide
a secure Win2K infrastructure.
So what is Group Policy? Quite simply, Group Policy is a new capability in Win2K that centrally
defines, manages, and enforces the environment settings for both computer and user objects.
Once set up, Group Policy maintains the state of computer and user settings throughout your
environment without administrator intervention; its all handled for you auto-magically. Group
Policy integrates tightly with AD and can be assigned to AD sites, domains, and organizational
units (OUs) to help you manage your Win2K domain environments.
You can also use Group Policy on stand-alone computers when circumstances dictate that they
not be joined to a domain. And you can filter the application of Group Policy on computer and
user objects in your domain infrastructure by using the long-available security groups. You can
use Group Policy to configure and maintain a number of things, as shown in Table 3.1.
This Capability

Does This

Administrative Templates

Sets Registry-based policies, much like System Policy in Windows NT

Server 4.0.

Folder Redirection

Redirects user folders and files to computers on the network.

Scripts

Runs the necessary scripts when a computer starts up and shuts down,
including logon and logoff scripts.

Software Installation

Assigns and publishes applications. Published applications are optional

and can be installed on demand, while assigned applications are
installed automatically.

Security Settings

Manages security settings for domains, computers, and users.

Table 3.1: The capabilities of Group Policy.

Although I put Security Settings at the bottom of the table, its the ability to centrally manage
these that makes Group Policy such an important tool. Group Policy is the mechanism that youll
use to ensure that the security configurations of your Win2K infrastructure are applied
consistently and without fail.
As Im sure youve already guessed, setting security will be a major focus of this chapter. Ill
also describe how Group Policy is implemented and give you a basic understanding of how
Win2K implements Group Policy. By the time Im done, I hope youll have reached the same
conclusion I havethat Group Policy is probably the most exciting and effective tool for
managing the security of your Win2K infrastructure.
Dont confuse Group Policy with the concept of profiles. While a profile contains user environment
settings that users can modify, Group Policy is managed and maintained by you, the administrator,
not end users.

61

Chapter 3

How Did Group Policy Come About?

The ability to centrally manage a large number of users and computers is something that both
security professionals and system administrators alike have wanted for quite a while. Microsoft
has understood this and has worked toward providing centralized administration for quite some
time. In fact, Microsoft introduced the System Policy Editor (POLEDIT.EXE) in Windows NT
4.0 as a tool to help administrators centrally specify user and computer configuration settings.
Starting with the System Policy Editor
The System Policy Editor allows administrators to control a users work environment and
enforce system configuration settings for all of the computers in a domain. The System Policy
Editor functioned by simply setting Registry values on all the computers of the domain, thus
defining the operational characteristics of the users desktop environment.
While the System Policy Editor provided administrators with a useful capability that was
otherwise lacking, if you were hoping to use it to manage security, its without a doubt somewhat
of a mixed bag. On the bright side of things, its settings are applied to domains and can be
further controlled using security groups. But it suffers from a number of issues that limit how
well it manages the security of your infrastructure.

Its settings arent secure. Simply using a Registry editor can undo many of the Registry
settings that youve applied.

Registry changes made by the System Policy Editor can persist long after the policy
settings are removed from the domain. For example, lets say that someone once decided
that it was a good idea to remove the Network Neighborhood icon from the desktops of
all the users in your domain. Now lets say that this was later seen as a mistake, and it
was decided to put the icon back on everyones desktop. Obviously, the easiest way
would be to simply remove the policy, and poof, the icon would be back. Unfortunately,
however, the setting to remove the icon persists until you reverse it with yet another
System Policy Editor setting or until you edit the Registry by hand on all of the
computers in your environment.

System Policy Editor settings are limited to behaviors that are based on Registry settings,
and then only a specific set of Registry settings. While Microsoft released a Software
Development Kit (SDK) to extend the capabilities of the System Policy Editor, few third
parties seem to have embraced these extensions.

While the System Policy Editor has been extremely useful in centralizing many configuration
settings in an NT 4.0 environment, its shortcomings were significant enough that Microsoft
realized that it had to build a better mechanism for Win2K. As a result, Group Policy builds on
the strengths of the System Policy Editor while tightly integrating it with AD.
Group Policy is explicitly related to Win2K; it offers no legacy support for the NT 4.0, Windows 9x, or
Windows Me operating system (OS). Therefore, to take full advantage of Group Policy, you need a
homogeneous Win2K environment that encompasses all your servers and workstations.

62

Chapter 3
Developing into Group Policy Objects
As shown in Table 3.1 above, Group Policy allows you to centrally manage Registry-based
policy settings, Folder Redirection, scripts, Software Installation, and Security Settings. These
settings are stored in Group Policy Objects (GPOs). Ill talk much more about GPOs and how
theyre stored, manipulated, and applied a bit later, but for now, I want to talk briefly about the
capabilities inherent in GPOs to show you why theyre an improvement over System Policy.
First, GPOs can be applied to AD sites, domains, and OUs and can therefore affect all the
computer and user objects contained in these AD containers. In all fairness to System Policy
Editor settings, this is really not a big difference because sites and OUs didnt exist in the NT 4.0
world. And like System Policy, GPOs can be further controlled using security groups. These core
features of GPOs build on the strengths of the System Policy Editor.
But unlike System Policy Editor settings, GPOs are secure, and they can be fully managed.
These are important distinctions for managing the security of your infrastructure because GPOs
provide a mechanism that you can count on to do the right thing. GPOs are secure because only
administrators can modify them. You do this by writing the GPOs to a secure portion of the
Registry, then applying the appropriate settings contained in the GPO when a computer starts up,
when a user logs on, and at regular time intervals. This allows you to remove and rewrite Group
Policy settings whenever policy changes without leaving settings behind.
Finally, you can extend GPOs to encompass applications and functionality that arent part of the
initial Win2K installation. This is a powerful capability that unfortunately seems to have gone
mostly unnoticed to date by software developers. Ill talk about how to extend the behavior of
GPOs later in this chapter, but here Ill talk about why the ability to extend a GPO is so neat.
Lets say that your company uses an off-the-shelf application that comes with a ton of bells,
whistles, and configuration options. However, not all of its defaults are appropriate for your
environment, so every time you install the application, you have to spend 10 minutes configuring
it to function properly. After a while, maybe you build a Registry file to import all of the settings
in one swoop, but your user population has a tendency to reconfigure the application. By
extending and applying a GPO to cover all of the configuration settings, you can centrally
manage these settings for all of your users and save countless hours of configuring and
reconfiguring the application in your environment.

How Does Group Policy Work?

Group Policy is implemented as a combination of containers and templates that store
configuration settings. As I mentioned earlier, physically creating these containers and templates
creates a GPO; thus, a GPO provides the physical storage area for Group Policy. These GPOs are
then linked to specific AD containers such as sites, domains, and/or OUs so that the settings can
be applied to computer and user objects throughout your environment.
It all starts with the two main components of a GPOthe Group Policy Container (GPC) and the
Group Policy Template (GPT). The GPC and GPT are named using something known as a
globally unique identifier (GUID). The GUID ensures that the components are unique and helps
keep them synchronized throughout your environment. These three elements are described in the
sections below.

63

Chapter 3
The Globally Unique Identifier
A globally unique identifier (GUID) is a 128-bit identifier that is unique to a particular object;
its generated from a unique identifier on a device, the current date and time, and a sequence
number. The GUID uniquely identifies any object because once its issued, its never changed,
even if the object is renamed or moved.
GUIDs are unique in a single namespace (like an AD forest), but theyre not guaranteed to be unique
across all namespaces. The probability of ever seeing two identical GUIDs is so low that its highly
unlikely to ever happen, but even if it did, there is absolutely no risk to your Win2K environment
because youll always manage a single namespace at a time. So you can file this information as a
technical tidbit that is interesting but irrelevant to what you need to know to properly administer your
Win2K forests.

Group Policy Containers

A Group Policy Container (GPC) stores the main properties of a GPO in an AD objectversion
information, status information, extensions, and policy settings. (The AD object is stored in the
System | Policy container of the domain where the GPO is defined.) Version information ensures
that information is synchronized between the GPC and its associated GPT. Status information
indicates whether the GPO is enabled or disabled. The GPC also holds a list of policy extensions
that have settings defined in the GPO and any settings that are defined by extensions to Group
Policy. Overall, the GPC stores policy data that is small and that changes infrequently.
While you can take a look at the physical implementation of a GPO, dont ever edit the GPC or GPT
directly. Instead, use the Group Policy Editor Microsoft Management Console (MMC) snap-in. In fact,
the only way to create a GPO is using this snap-in; there are no command-line tools for doing it.

Group Policy Templates

A Group Policy Template (GPT) stores the rest of a GPO in a folder structure that is part of the
SYSVOL folder on all of the domain controllers. More specifically, its stored in the
\%SYSTEMROOT%\sysvol\sysvol\<domain name>\Policies folder. As a result of where its
stored, each GPT is replicated as part of standard AD replication to all of the domain controllers
in the domain where the GPO is defined. For example, a GPT folder might be named as follows:
%systemroot%\sysvol\sysvol\internal.sheabear.com\Policies\
{47636583-af69-10da-91fe-090036612345}

The GPT stores information for all of the policy, script, file, and software-installation settings for
the GPO in a number of subfolders that may or may not exist based on the specifics of the GPO,
as follows:

ADMThe set of administrative templates for the GPO.

MACHINEThe Registry settings that are to be applied to computer objects as well as

a REGISTRY.POL file. This folder also contains a number of subfolders, including:

ApplicationsFiles used by the Windows Installer service to publish and assign

applications to computer objects.

ScriptsThe startup and shutdown scripts plus their related files for computer objects.
64

Chapter 3

USERThe Registry settings that are to be applied to user objects as well as a

REGISTRY.POL file. This folder also contains a number of subfolders, including:

ApplicationsFiles used by the Windows Installer service to publish and assign

applications to user objects.

ScriptsThe logon and logoff scripts plus their related files for user objects.

In addition to all of the other files and folders, every GPT contains a GPT.INI file. This file is
located in the root folder of the GPT and contains the version number of the GPT.
A Group Policy Editor MMC snap-in is allowed to store data outside the GPC and GPT. For this to
work, though, a link to the GPO data must be stored in either the GPC or GPT. Without this link, the
data isnt accessible. For more information on GPO data-storage schemes, search for the Microsoft
Platform SDK at www.msdn.microsoft.com.

The relationships between the GPO and its related GPC and GPT are summarized in Figure 3.1.

Figure 3.1: The relationships between the GPO and its related GPC and GPT.

65

Chapter 3
Keep in mind that because the GPC and GPT are stored and replicated separately, they can get
out of sync. Thus, in order for the GPO to be applied, the version numbers of the GPC and GPT
must match. If a situation arises where they dont, an error is logged, and the GPO isnt applied.
You can check the consistency of your GPOs using the Group Policy Object Verification tool from the
Windows 2000 Resource Kit. This tool, discussed later in this chapter, can alert you to any
synchronization problems that may exist with your deployed GPOs.

Group Policy Processing on the Clients

Now that you have a basic understanding of how Group Policy is implemented on the server side
of things, Ill describe what happens on the client side of GPO application. The key to delivering
and applying GPOs are dynamic link libraries (DLLs), which are installed by default on Win2K
computers. These DLLs are known as client-side extensions (CSEs) because they process
information from the GPC and GPT and apply it to the client system.
For each portion of a GPO, there is a corresponding CSE that does the actual configuration work
on a workstation or server. A CSE receives the configuration information of a GPO from the
appropriate GPC and GPT configuration containers, then applies it to the appropriate computer
or user object. Each CSE is listed in the Registry under the following key:
HKLM\Software\Microsoft\Windows NT\
CurrentVersion\Winlogon\Gpextensions

and is stored in the %systemroot%\system32 folder of each Win2K computer.

Heres an example of how CSEs function as the client-side portion of a GPO. Lets say that you
have a GPO that is responsible for implementing the user Registry settings for the computers in
your domain. When the user logon event occurs, the Winlogon process checks AD to find out
whether any GPOs are to be applied to the user. Then each CSE queries the appropriate GPCs for
each of the relevant GPOs to determine whether the policy is currently enabled and makes any
other checks to ensure that the GPO should be applied.
Once the GPO is validated for the user, the CSE checks its unique Registry key to determine
whether the GPO has ever been processed and, if so, what the last version number was that was
applied. If the GPO has never been applied, or if the version number has changed since it was
last applied, the CSE retrieves the GPT and executes the required policy settings for the user.

Group Policy and Active Directory

There is a fundamental relationship between Group Policy and AD. In fact, Group Policy extends
and takes advantage of the AD service to provide its functionality. As I mentioned earlier, Group
Policy settings are stored in a GPO, and GPOs in turn can be associated with the following AD
containers: sites, domains, and OUs. GPO assignment isnt singular in nature, so multiple GPOs
can be assigned to a single AD container. (In this case, you can specify the order of GPO
processing to provide further flexibility and control of the application of policy.) On the flip side,
a single GPO can be applied to multiple AD containers.

66

Chapter 3

When you create the first domain controller of a new domain, two default GPOs are automatically
created: the Default Domain Policy and the Default Domain Controllers Policy. The Default Domain
Policy is linked directly to the domain and specifies some generic security settings for the entire
domain. The Default Domain Controllers Policy is linked to the Domain Controllers OU and sets a
small handful of security settings for all of the domain controllers in the domain.

Group Policy Assignment

While I mentioned it above, its worth repeating that you can apply a GPO to sites, domains,
and/or OUs. You apply a GPO using a GPO link. This information is important because if you
dont link a GPO to an AD container, the GPO will have absolutely no effect on any user or
computer object in your environment. At the same time, GPOs are stored in the specific domain
in which they were created. This is typically referred to as the storage domain for a GPO and
shouldnt be confused with the domain(s) to which the GPO is actually linked and thus applied.
You may be wondering why GPOs are applied using links. Its really about conserving GPOs.
By using links, you can apply a single GPO to multiple sites, domains, and OUs regardless of
where the actual GPO is stored. On the flip side, you can also link multiple GPOs to a single site,
domain, or OU.
This all sounds very nice, but you need to be aware that you cant link a GPO to a generic AD
container, such as the default Users and Computers containers. You can tell a generic container
from an OU in the Active Directory Users and Computers MMC snap-in by whether a small
book icon is superimposed on the main folder icon. A folder without the book is a generic
container, while a folder with the book is an OU. While generic AD containers cannot have
GPOs linked directly to them, they can receive GPO settings using inheritance.
Group Policy Processing and Inheritance
Now that weve established that you can have multiple GPOs linked throughout your AD
hierarchy and multiple GPOs linked to the same AD container, its helpful to understand how
Win2K processes GPOs. First, local GPOs are applied first, followed by site GPOs, domain
GPOs, and finally OU GPOs. Because each site, domain, and OU can have multiple GPOs, you
can prioritize the processing of each of the links, as shown in Figure 3.2. GPOs that are higher in
the list have higher priority; in other words, GPOs are processed from top to bottom.

67

Chapter 3

Figure 3.2: Prioritizing Group Policy for a domain object.

The default behavior of Win2K is to have the application of GPOs be inherited and cumulative
throughout an entire AD branch. This inheritance starts with the AD container furthest from the
appropriate computer or user object and moves back toward the object in question. This allows
GPOs that are defined closer to the object to take precedence over GPOs that are linked higher in
the AD hierarchy. While GPOs are inherited down an AD branch, the one exception to this rule
is that GPOs arent inherited across domain boundaries.
What do these rules mean? They mean that processing of GPOs is applied in the following order:
1. Local GPOEach Win2K computer has a local GPO that is always applied.
2. Site GPOsAny linked site GPOs are applied in administratively specified order.
3. Domain GPOsAny linked domain GPOs are applied in administratively specified

order.
4. OU GPOsAny linked OU GPOs are processed starting at the highest-level OU down

to the OU that contains the object in a strict parent-child fashion. For each OU in the
hierarchy, GPOs are applied in administratively specified order.
While the descriptions above are technically accurate, using examples will bring the inheritance
and processing of GPOs into focus. Lets take a look at Figure 3.3 below and decide what GPO
links will be applied by default to a couple of objects. Because the local GPO for each computer
68

Chapter 3
is always applied first, I wont talk about the application of the local GPO in our examples; just
dont forget about it as we walk through them.

Figure 3.3: Group Policy assignment and processing.

Lets start with objects in OU X2. The first thing to decide is whether any GPOs are linked to the
site that contains OU X2. Youll notice that site Z has GPO X3 linked to it; therefore, this is the
first GPO to be applied. Next, look at the domain container, and youll find GPO X1 and GPO
X2 linked to the domain. Because there are multiple GPOs defined in the container, assume that
the GPOs should be applied in ascending order. Finally, see what GPOs are linked to the OU
itself, and youll find one, X4. Now that youve found all of the relevant GPOs, you determine
their application order. In this example, the GPOs will be applied to objects in the OU in the
following order: local, X3, X1, X2, and X4.
Now that you have a feel for how this works, take a look at what GPOs are applied to OU Y2
and their application order. In the case of OU X2, there are no site GPOs, and there is a single
domain GPO and a single OU GPO. But what about inheritance of GPOs from domain X?
Simply, GPOs arent inherited across domain boundaries. In fact, if you play with things and
really take notice, youll find that in reality, the only GPOs that can be inherited are those that
are defined in OUs! So in the final analysis, the following GPOs are applied in order to OU Y2:
local, Y1, and Y2.

69

Chapter 3
Now that you know the order in which GPOs are processed, what happens to the actual GPO
settings? First, all settings in a GPO that arent configured are ignored because they obviously
cannot have an effect on inheritance and precedence. On the other hand, configured settings do
have an effect on inheritance and precedence of GPO settings. When evaluating configured GPO
settings, there are three possible scenarios:
1. Parent value is set, child value isnt setThe child inherits the policy setting from the

parent.
2. Parent value is set, child has a non-conflicting valueThe parent setting is applied,

then the child setting is applied.

3. Parent value is set, child has conflicting valueThe parent setting isnt inherited, and

the child value takes precedence.

Overall, the default processing of GPOs is relatively straightforward but can lead to some
unfortunate scenarios without other mechanisms to further refine it. Thankfully, Win2K allows
you to modify the default processing of GPOs by:

Blocking the inheritance of GPO settings

Stopping another GPO from overriding your GPO settings

Filtering the application of GPO settings.

Blocking Group Policy Inheritance

The first mechanism for modifying the default processing of GPOs is blocking the inheritance of
a GPO. Known as Blocking Group Policy Inheritance, its applied to an AD domain or OU
container and prevents any GPOs linked to parental AD containers from being applied. This is
shown in Figure 3.4.

70

Chapter 3

Figure 3.4: The effect of Blocking Group Policy Inheritance.

Using Figure 3.4 as an example, lets say that you wanted to create a domain policy that took
care of the core security settings for your domain. Unfortunately, some administrator in your
environment has set the Block Group Policy Inheritance option on the HQ OU. As a result, the
domain policy is not only not applied to the HQ OU but is also not applied to the Finance or HR
OUs.
Stopping a GPO from Overriding Settings
The second mechanism for modifying the default processing of GPOs is stopping one GPO from
overriding the settings of another. Known as No Override, this capability is actually applied to a
GPO link. Consequently, No Override applies to a particular GPO at the particular site, domain,
or OU to which the GPO is linked, as shown in Figure 3.5.

71

Chapter 3

Figure 3.5: The effect of No Override on Group Policy application.

Using Figure 3.5 as an example, lets say that you want to create a domain policy that takes care
of the core security settings for your domain, but the Block Policy Inheritance option is still set
on the HQ OU. Because security settings are extremely important for your organization, you go
ahead and set the No Override option on the GPO link to the internal.sheabear.com domain
container. As a result, your domain policy is now applied to all of the OUs in your environment.
This example brings up an important point about GPO processing precedence. Whenever the two are
in conflict, No Override takes precedence over Block Policy Inheritance.

While the Block Policy Inheritance and No Override features of Group Policy can affect whether a
GPO shows up in the list of objects that need to be processed, they dont affect the order in which
theyre processed.

Filtering Group Policy Using Security Groups

The final mechanism for modifying the default processing of GPOs is filtering a GPO using
security groups. Like all other objects in Win2K, GPOs have access control lists (ACLs) that you
can use to limit access. In particular, each GPO has a specialized permission known as Apply
Group Policy that you can use to limit the objects that a GPO is applied to. By default, all GPOs
grant Apply Group Policy to the Authenticated Users group. You can change the default
permissions by highlighting the name of a particular GPO in the Group Policy Editor MMC
snap-in, right clicking it, then clicking the Security tab, shown in Figure 3.6.

72

Chapter 3

Figure 3.6: The security settings on a GPO.

Ignoring Certain Group Policy Settings

As youll see when I talk about what you can configure with a GPO in the next section, two basic
types of settings are available in a GPO: computer and user. If you build a GPO that contains
only one of these two types of settings, you can disable the portion of the GPO that isnt in use.
Disabling a portion of the GPO allows Win2K to skip over the disabled settings when its trying
to figure out what GPO settings to apply. This is yet another way in which you can reduce the
time that it takes to read and apply all of the assigned GPOs for a particular computer or user
object.
For example, you might create a GPO that is responsible for just enforcing the password policy
for your enterprise. In this scenario, the only settings that need to be configured are contained in
the computer portion of the GPO. Because of this, it just makes good sense to disable the user
portion of the GPO so that Win2K never wastes time trying to apply the non-existent settings. To
do this, highlight the name of a particular GPO in the Group Policy Editor MMC snap-in, rightclick it, then choose Properties from the shortcut menu. On the General tab, select the
appropriate check box, as shown in Figure 3.7.

73

Chapter 3

Figure 3.7: Disabling a configuration setting on a GPO.

Group Policy Access Control Lists

As I mentioned earlier, all objects in Win2K can have ACLs associated with them, including
GPOs. The default settings for a GPO are shown in Table 3.2. One of the interesting things to
notice is the use of Apply Group Policy, which is given to the Authenticated Users group. As a
result of this setting, all GPOs are by default processed by all computers and all users for which
the GPO is in scope (assuming that no other inheritance-modifying features are used). While this
isnt necessarily a bad thing, youd probably want to minimize the number of GPOs that have to
be processed by being more specific about who can read and apply GPOs in your environment.
This Security Group

Has These ACL Settings

Authenticated Users

Read, Apply Group Policy

Domain Admins

Read, Write, Create All Child Objects, Delete All Child Objects

Enterprise Admins

Read, Write, Create All Child Objects, Delete All Child Objects

SYSTEM

Read, Write, Create All Child Objects, Delete All Child Objects

Table 3.2: The default security settings on a GPO.

Another thing to notice about the Authenticated Users group is that, by default, it doesnt have
Write permissions. This is a good thing because you dont want just anyone modifying your

74

Chapter 3
GPO settings. But you might expect that because they have Read access, your Authenticated
Users can open the GPO using the Group Policy Editor snap-in. However, if youve ever tried to
look at a GPO as an Authenticated User, you know that the snap-in doesnt display the GPO.
This is because each of the Group Policy extensions assumes that it has Write access to the
storage locations of the GPO; therefore, when the user doesnt have Write access, the Group
Policy Editor snap-in doesnt open the GPO.

What Can I Configure Using Group Policy?

The quick answer is a lot! You can configure well over 1,000 options using a GPO. Even in the
section that Microsoft has identified as Security Settings, you can manipulate over 100 settings.
Obviously, I cant describe all 1,000-plus GPO settings here, but Ill go over the identified
security settings so that you have a thorough understanding of what they do. Before diving into
the specifics of certain settings, Ill take a quick step back and discuss a couple of other items.
The first thing that you should be aware of is that GPOs are broadly separated into two
namespaces, which are applied at different operational times: Computer Configuration and User
Configuration. This separation fits perfectly with how GPOs are implemented, as I described
earlier. Basically, the Computer Configuration container includes all computer-related policies
that specify OS behavior, desktop behavior, application settings, security settings, assigned
applications options, and computer startup and shutdown scripts. Computer-related policy
settings are applied when the OS initializes.
On the other hand, the User Configuration container includes all user-related policies that specify
OS behavior, desktop settings, application settings, security settings, assigned and published
applications options, user logon and logoff scripts, and Folder Redirection options. User-related
policy settings are applied when users log on to their computers.
If computer settings and user settings come into conflict, the computer configuration settings override
the user configuration settings.

The Computer Configuration container stores the core security-relevant Group Policy settings.
You can locate these security settings by traversing the following path through the Group Policy
Editor MMC snap-in: Computer Settings | Windows Settings | Security Settings. From this
location, youll notice that the following nine main containers hold security settings:

Account PoliciesDefines the security settings that affect password policy, account
lockout policy, and Kerberos policy in the computer configuration namespace.

Local PoliciesDefines the security settings that affect audit policy, user rights
assignment, and security options in the computer configuration namespace.

Event Log PoliciesDefines the security settings that affect the use of the application,
security, and system logs in the computer configuration namespace.

Restricted GroupsDefines properties for security-sensitive groups (that is, restricted

groups) in the computer configuration namespace.

System ServicesDefines the startup mode (Manual, Automatic, or Disabled) as well as

access permissions for all system services in the computer configuration namespace.

75

Chapter 3

RegistryDefines access permissions (discretionary access control lists, or DACLs) and

audit settings (system access control lists, or SACLs) for Registry keys in the computer
configuration namespace.

File SystemDefines DACLs and SACLs for file-system objects in the computer
configuration namespace.

Public Key PoliciesDefines the security settings that affect the behavior of the public
key infrastructure (PKI) built into Win2K and have applicable settings in the user and
computer configuration namespaces.

IP Security PoliciesDefines the security settings that affect the use of Internet Protocol
Security Protocol (IPSec) implementation built into Win2K and have applicable settings
in the computer configuration namespace.

Security Settings
In these nine containers, there are just over 100 security options that you can set in a single GPO.
While it may become a little tedious for some, I think that its important that I talk briefly about
what many of these security configurations do. In some cases, Ill provide some guidance on
how these settings should be configured. Just remember, my bias is toward security!
Account Policies | Password Policies

Enforce password historyA value between 0 and 24 that determines the number of
unique new passwords that must be used before users can start recycling old passwords.
It defaults to 1 in the Default Domain Policy. The more security-conscious your
environment is, the larger the value you should choose.

Maximum password ageA value between 1 and 999 that determines the number of
days that a password can be used until it expires. A value of 0 specifies that passwords in
your environment never expire. The setting defaults to 42 in the Default Domain Policy
and should probably be set to a value between 30 and 120, depending on the security
policy of your environment.

Minimum password ageA value between 1 and 999 that determines the number of
days that a password must be used until it can be changed. A value of 0 specifies that
passwords can be changed immediately. The setting defaults to 0 in the Default Domain
Policy. While it might be tempting to set this value to 1 or more, it can cause problems
for your users because whenever an administrator sets users passwords and marks them,
users must change them the next time they log on. But if users cannot change their
passwords immediately, they cant log on!

Minimum password lengthA value between 1 and 14 that determines the lowest
number of characters that users passwords must contain. A value of 0 specifies that users
arent even required to have passwords! The setting is unfortunately set to 0 in the
Default Domain Policy and should be changed immediately. A value of 7 is probably
most appropriate for user accounts and a value of 14 for administrator accounts.

76

Chapter 3

Passwords must meet complexity requirementsDetermines whether to use a

password filter (PASSFILG.DLL). Using PASSFILT.DLL requires user passwords to
meet more stringent complexity requirements. I highly recommend using the password
filter, and if youre truly worried about the password quality of your environment, you
may want to invest in a third-party password-filter program.

Store passwords using reversible encryptionThis policy is such a terrible idea that
Microsoft should just eliminate it! Under no circumstance should you ever enable this
policy. Thankfully, this setting is disabled in the Default Domain Policy.

User must log on to change the password Determines whether users have to log on
before they can change their passwords. When this policy is enabled, users have to log on
before changing their passwords. When a users password is expired, this creates an
interesting predicament because the user cant log on to change the password and an
administrator has to reset it. The setting is disabled in the Default Domain Policy and
should probably remain disabled for all but highly secure organizations.

Account Policies | Account Lockout Policy

Account lockout thresholdA value between 1 and 999 that determines how many
failed logon attempts it takes to lock out a users account. A value of 0 specifies that
accounts never get locked out, and I recommend against using it. A value between 3 and
5 should be appropriate for most organizations.

Account lockout durationA value between 1 and 99999 minutes that determines how
long an account remains locked out before automatically being unlocked. A value of 0
specifies that an account remains locked out until an administrator unlocks it. For highly
secure implementations, I recommend a value of 0; for a less secure environment, I
recommend a value between 10 and 60. If youve defined an account lockout threshold,
this value has to be greater than or equal to the reset time.

Reset account lockout counter afterA value between 1 and 99999 minutes that
determines how many minutes must pass before the failed logon count is reset to 0. If an
account lockout threshold is defined, the value must be less than or equal to the account
lockout duration.

77

Chapter 3

Account Policies | Kerberos Policy

Keep in mind that Kerberos policy affects the entire domain, so you must define it at the domain
level.

Enforce user logon restrictionsDetermines whether validation of a session ticket

occurs against the user rights policy of the target computer. This policy is enabled in the
Default Domain Policy and should remain enabled in all environments.

Maximum lifetime for service ticketDetermines the number of minutes that a session
ticket can be used to access a service. The value must be greater than 10 and less than or
equal to the Maximum Lifetime for a User Ticket setting. A value of 600 is set in the
Default Domain Policy, and most organizations should probably keep this value to
minimize issuing session tickets. For highly secure installations, this value could be set as
low as 10, but a value between 60 and 240 is probably sufficient for all but the most
paranoid organizations.

Maximum lifetime for user ticketDetermines the number of hours that a users ticketgranting ticket can be used. A value of 10 is set in the Default Domain Policy and should
be sufficient for most organizations. For highly secure installations, a value between 1
and 4 is probably sufficient.

Maximum lifetime for user ticket renewalDetermines the number of days that a
ticket-granting ticket can be renewed for. A value of 7 is set in the Default Domain
Policy and should be sufficient for most organizations. For highly secure installations, a
value of 1 should be sufficient.

Maximum tolerance for computer clock synchronizationDetermines the maximum

clock skew in minutes that Kerberos allows to function properly. A value of 5 is set in the
Default Domain Policy and should be sufficient for most organizations.

Local Policies | Audit Policy

One of the first things youll probably notice about these auditing settings is that I believe in
auditing a lot of stuff. Thankfully, disk space isnt the issue it used to be, and most of the audit
settings I recommend below shouldnt kill the performance of your domain.

Audit account logon eventsDetermines whether to audit the logon and logoff events
of another computer on which the local computer is used to validate the account. The
Default Domain Controllers Policy defines this setting but has its value set to No
Auditing. I suggest changing this setting to audit both success and failure events.

Audit account managementDetermines whether to audit all account-management

operations on a computer. The Default Domain Controllers Policy defines this setting but
has its value set to No Auditing. I suggest changing this setting to audit both success and
failure events.

Audit directory service accessDetermines whether to audit user access of an AD

object that has an SACL defined on it. The Default Domain Controllers Policy defines
this setting but has its value set to No Auditing. I suggest changing this setting to audit
just failure events.

78

Chapter 3

Audit logon eventsDetermines whether to audit every logon, logoff, and network
connection event on a computer. The Default Domain Controllers Policy defines this
setting but has its value set to No Auditing. I suggest changing this setting to audit both
success and failure events.

Audit object accessDetermines whether to audit every object access that has an SACL
defined on it. The Default Domain Controllers Policy defines this setting but has its value
set to No Auditing. I suggest changing this setting to audit just failure events.

Audit policy changeDetermines whether to audit every change of policy, including

user rights assignment policies, audit policies, and trust policies. The Default Domain
Controllers Policy defines this setting but has its value set to No Auditing. I suggest
changing this setting to audit both success and failure events.

Audit privilege useDetermines whether to audit the use of a user right. The Default
Domain Controllers Policy defines this setting but has its value set to No Auditing. I
suggest changing this setting to audit just failure events.

Audit process trackingDetermines whether to audit tracking information for

application processes. The Default Domain Controllers Policy defines this setting but has
its value set to No Auditing. While it might be shocking, I suggest leaving this one alone
because itll generate a huge volume of information that from a security perspective is
mostly meaningless.

Audit system eventsDetermines whether to audit events that might affect the systems
security or its security log. The Default Domain Controllers Policy defines this setting but
has its value set to No Auditing. I suggest changing this setting to audit both success and
failure events.

Local Policies | User Rights Assignments

User rights assignments can be a tricky thing because its hard to determine if the user rights that
most applications say they require are truly required. In addition, the sheer number of
applications and their required rights makes it impossible for me to really help you decide what
user rights are truly appropriate in your environment. One thing I can do, though, is tell you that
you should never assign the following user rights to any user or group:

Act as part of the operating systemAllows a process to authenticate as any user.

Create a token objectDetermines which accounts can create a token object that can be
used to gain access to any local resource or object.

Create permanent shared objectsDetermines which accounts can create a folder in

the kernels object manager.

Debug programsDetermines which accounts can attach a debugger to any process.

Generate security auditsDetermines which accounts can add entries to the security
log.

Lock pages in memoryIs obsolete and shouldnt be used.

Manage auditing and security logDetermines which accounts can configure object
access auditing for resources and objects.
79

Chapter 3

Modify firmware environment variablesDetermines which accounts can modify

system-wide environment variables.

Replace a process level tokenDetermines which accounts can replace the token of a
sub-process.

Synchronize directory service dataIsnt implemented and shouldnt be used.

Local Policies | Security Options

While I fully understand that many of your environments arent yet pure Win2K environments,
the recommendations below assume that you have a homogeneous Win2K environment. Those
of you with mixed environments need to be careful about signing and encrypting network traffic
as well as the Windows NT LAN Manager (NTLM) authentication options.

Additional restrictions for anonymous connectionsDetermines what, if any,

additional restrictions should be placed on anonymous connections. I recommend setting
this to No Access without Explicit Anonymous Permissions.

Allow server operators to schedule tasks (domain controllers only)Determines

whether server operators can schedule AT jobs. If enabled, server operators as well as
administrators are allowed to schedule AT jobs. Your administrative procedures will
dictate how to set this policy.

Allow system to be shut down without having to log onDetermines whether

computers can be shut down from the Windows Logon dialog box. If this policy is
enabled, the Shutdown button is available. I recommend that you enable this policy only
for workstations in your environment and disable it for all servers.

Allowed to eject removable NTFS mediaDetermines which users are allowed to eject
removable NT file system (NTFS) media. I recommend that interactive users have this
capability on all workstations and that all servers be restricted to administrators.

Amount of idle time required before disconnecting a sessionA value between 0 and
0xFFFFFFFF that determines the amount of idle time before an SMB session is
disconnected because of inactivity. A value between 10 and 20 minutes is appropriate for
most organizations.

Audit the access of global system objectsDetermines whether global system objects
with SACLs defined are audited. While you can enable this policy, it doesnt add enough
value to warrant putting up with all the additional audit events unless youre looking for
something specific.

Audit use of Backup and Restore privilegeDetermines whether to audit every use of
the backup and restore privileges. Once again, if you enable this policy, its doubtful that
youll get enough value from all of the additional audit events to make it worthwhile.

Automatically log off users when logon time expiresDetermines whether to log off
users automatically when their logon time for SMB connections expires. I recommend
enabling this policy setting.

80

Chapter 3

Automatically log off user when logon time expires (local) Determines whether to
automatically log off users when their logon time for local connections expires. I
recommend enabling this policy setting.

Clear virtual memory pagefile when system shuts downDetermines whether to

automatically clear the pagefile when the system shuts down. I highly recommend
enabling this policy on all computers in your environment. If this sounds a little too
much, at least make sure that this policy setting is enabled on all of your servers.

Digitally sign client communications (always)Determines whether SMB client

communications are always digitally signed. I recommend enabling this policy even
though it uses more system central processing unit (CPU) cycles.

Digitally sign client communications (when possible)Determines whether SMB

client communications are digitally signed when possible. I also recommend enabling this
policy.

Digitally sign server communications (always)Determines whether SMB server

communications are always digitally signed. I recommend enabling this policy even
though it uses more system CPU cycles.

Digitally sign server communications (when possible)Determines whether SMB

server communications are digitally signed when possible. I also recommend enabling
this policy.

Disable CTRL+ALT+DEL requirement for logonDetermines whether the

CRTL+ALT+DEL key combination is required before a user logs on. If enabled, the key
combination isnt required. However, from a security perspective, using the secure
attention sequence is important, and I recommend disabling this policy for all computers
in your organization.

Do not display last user name in logon screenDetermines whether the name of the
last successfully logged-on user is displayed in the Windows Logon dialog box. If the
policy is enabled, the last user name isnt displayed. I recommend enabling this policy for
all of the servers in your environment but am reluctant to recommend doing so for all of
the workstations.

LAN Manager Authentication LevelDetermines which versions of the LAN

Manager authentication protocol are accepted. If your environment is free of Windows
9x, Windows Me, and preWindows NT Service Pack 4 machines, I recommend that you
configure this policy to Send NTLMv2 Response Only\Refuse LM & NTLM; otherwise,
youll have to pick a less secure option.

Message text for users attempting to log on; Message title for users attempting to log
onSet the message text and title that are displayed to users before the Windows Logon
dialog box appears. I recommend that you use these settings and provide some
information about the consequences of misusing the computers resources and/or data.

Number of previous logons to cache (in case domain controller is not available)
Determines how many cached successful logons the computer keeps in case a domain
controller isnt available. I recommend setting this value to between 3 and 10.

81

Chapter 3

Prevent system maintenance of computer account passwordDetermines whether a

computer account password is updated every week. If this policy is enabled, the password
isnt updated. I recommend disabling this policy throughout your environment.

Prevent users from installing printer driversDetermines whether regular users can
install print drivers. If enabled, this policy prevents users from installing print drivers. I
recommend enabling this policy for all of the servers in your environment (even though
regular users should never log on to a server), and I recommend disabling it for all
workstations.

Prompt user to change password before expirationDetermines how far in advance

users should be advised that their password is about to expire. I recommend setting this
value to 7 days; any more than that, and it gets annoying; any less, and you may not be
giving users enough warning.

Recovery console: Allow automatic administrative logon; Recovery console: Allow

floppy copy and access to all drives and all foldersDetermine how easy it is to gain
access to a system and its drives and folders from the Win2K recovery console. I
recommend disabling both of these policies throughout your environment.

Rename administrator account; Rename guest accountDetermine whether the

administrator and/or guest account is renamed. I know its a hassle for administrators, but
I recommend enabling these policies throughout your environment and renaming both
accounts.

Restrict CD-ROM access to locally logged-on user; Restrict floppy access to locally
logged-on userDetermine whether CD-ROM and/or floppy devices are accessible to
only the locally logged-on user. If enabled, these policies allow access to the specified
devices only by the locally logged-on user. Even when enabled, if there isnt an
interactive user, the media is accessible over the network. I recommend enabling these
policies throughout your environment.

Secure channel: Digitally encrypt or sign secure channel data (always) Determines
whether secure channel communications are always digitally signed or encrypted (but not
necessarily both). I recommend enabling this policy even though it uses a few more
system CPU cycles.

Secure channel: Digitally encrypt secure channel data (when possible) Determines
whether secure channel communications are encrypted when possible. I also recommend
enabling this policy.

Secure channel: Digitally sign secure channel data (when possible)Determines

whether secure channel communications are digitally signed when possible. I also
recommend enabling this policy.

Secure channel: Require strong (Windows 2000 or later) session keyDetermines

whether all secure channel communications require strong session key encryption. Until
youve upgraded all of the domain controllers in your environment, I recommend
disabling this policy. Once all of your domain controllers are running Win2K, you should
enable this policy.

82

Chapter 3

Send unencrypted password to connect to third-party SMB serversDetermines

whether clear-text passwords can be sent to third-party SMB servers that dont support
password encryption during authentication. If this policy is enabled, clear-text passwords
are allowed. I recommend disabling this policy for all computers in your environment.

Shut down system immediately if unable to log security auditsDetermines whether

the system should shut down if security events cannot be logged. If enabled, this policy
causes the system to stop whenever a security event cannot be logged. I recommend
disabling this policy.

Smart card removal behaviorDetermines what should occur when a smart card is
removed from the system. The default behavior is to do nothing, but I recommend that
you set this policy to Lock Workstation for all of the smart cardenabled computers in
your environment.

Strengthen default permissions of global system objects (such as Symbolic links)

Determines the strength of the default ACLs for global system objects. If enabled, this
policy modifies the default access to prevent non-administrator users from modifying
objects that they didnt create. I recommend enabling this policy for all computers in your
environment.

Unsigned driver installation behaviorDetermines what should happen when a device

driver that isnt digitally signed is installed on the computer. The default is to Warn but
Allow Installation, and this behavior is probably sufficient for all but the strictest
environments.

Unsigned non-driver installation behaviorDetermines what should happen when a

non-device driver that isnt digitally signed is installed on the computer. The default is to
Silently Succeed, and this behavior is sufficient for all but the strictest environments.

Event Log | Settings for Event Logs

Maximum application log size; Maximum security log size; Maximum system log
sizeDetermine the size in kilobytes (K) of the event logs. While the default is 512K
and the maximum is 4 gigabytes, I recommend using settings somewhere between 10 and
100 megabytes (MB) based on the size of your system disk.

Restrict guest access to application log; Restrict guest access to security log; Restrict
guest access to system logDetermine whether guest access is allowed to the logs. If
these policies are enabled, guests cannot access the logs. I recommend that this policy be
enabled for all your logs.

Retain application log; Retain security log; Retain system logDetermine the
number of days to keep in the specified audit logs. These policies are meaningful only if
the Retention Method for <logname> Log is set to Overwrite Events by Days.

83

Chapter 3

Retention method for application log; Retention method for security log; Retention
method for system logDetermine the wrapping mechanism for each of the specified
audit logs. For most environments, setting these policies to Overwrite Events As Needed
is sufficient. If your organization archives its logs, you may want to use the Overwrite
Events by Days setting.

Shut down the computer when the security audit log is fullSuperseded by Shut
Down System Immediately if Unable to Log Security Audits and shouldnt be used.

Applying Group Policy to Stand-Alone Computers

While you most often think of Group Policy in the context of a computer that is a member of a
domain, you can also use Group Policy to configure settings on stand-alone and workgroup
computers. You can configure the local GPO of a computer in much the same way that you
configure a GPO in a domainusing the Group Policy Editor MMC snap-in. The only
difference is that you run the snap-in on the computer that you want to configure and just target
the snap-in on the local computer. Ill cover GPEDIT.EXE later in this chapter (under Group
Policy Editor), so for now, just remember that you can configure the local GPO of a computer
using the same tool that you use to configure a domain GPO.
Using Local Group Policy versus AD-Based Group Policy
While you use the same tool to edit both a local GPO and an AD-based GPO, the behavior of the
Group Policy Editor MMC snap-in is slightly different. When you use GPEDIT to edit a local
GPO, the extensions that support Software Installation, Remote Installation Services, and Folder
Redirection arent loaded because each of them requires AD to function properly. In addition, the
following portions of the security extension arent available for a local GPO:

Security Settings | Account Policies | Kerberos Policy

Security Settings | Restricted Groups

Security Settings | System Services

Security Settings | Registry

Security Settings | File System

Security Settings | Public Key Policies | Automatic Certificate Request Settings

Security Settings | Public Key Policies | Trusted Root Certification Authorities

Security Settings | Public Key Policies | Enterprise Trust

Another thing to remember about a local GPO is that in a Win2K domain environment, its
always processed and always processed first. A local GPO is always processed even if no ADbased GPOs apply to the local computer or user and even if AD-based GPOs have been set to
block policy inheritance.

84

Chapter 3

Overriding Local Group Policy

As I discussed earlier, if a conflict occurs between the local GPO computer policy and an ADbased GPO, the non-local policy takes precedence and overwrites the local policy. In effect,
when a computer is part of a Win2K domain, there is no way to set the No Override option on a
local GPO. However, when you remove a computer from a Win2K domain, an interesting
phenomenon occurs. The local GPO settings are applied as if a No Override option did exist on
the local GPO, and any residual GPO setting has no effect on the computer.
You may be wondering if its possible to circumvent domain security settings by removing a computer
from the domain. The answer is an emphatic yes! A computer that isnt a member of a domain cannot
be controlled using Domain Group Policy, and only the local computer Group Policy will be in effect.
To be sure that your domain group policies are being used, perform regular security audits of your
environment to make sure that all of the computers in your organization are members of your domain
structure.

Using Local Group Policy with NT 4.0 Domain Controllers

While I hope that all of you can operate a homogeneous Win2K environment, one of the more
common deployment scenarios of Win2K has been to install the Professional version on an
organizations desktops and leave the domain infrastructure on Windows NT 4.0. In the situation
where the computer and user accounts are managed only by NT 4.0 domain controllers and
arent part of an AD infrastructure, the local GPO isnt processed at all. Thats rightthe local
GPO is totally ignored, and the only policy settings that are applied are Windows NT 4.0 System
Policies.

Extending Group Policy

One of the underused features of Group Policy is the ability to extend what a GPO can be used to
configure. Basically, Microsoft has given software developers and administrators alike two
simple ways to extend Group Policy:

Template file (.adm)The simpler method of extending a GPO, but you can use it only
to make changes to Registry-based information

Group Policy Editor snap-in extensionA bit more complicated, but it allows you to
manipulate both Registry- and file-based information settings.

Because describing the syntax of an administrative template file is beyond the scope of this
chapter, I encourage you to take a look at the syntax of the ones installed on the domain
controllers in your environment so that you can get an idea of what one looks like. I also
recommend that if you need to develop your own administrative template file, you check out the
online Help on one of your Win2K servers. Just remember to build your template files on the
understanding that computer and user settings are applied separately.

85

Chapter 3
Once youve created an administrative template file, you can add it to either the Computer
Configuration or the User Configuration node of the Group Policy Editor MMC snap-in. To do
this is relatively simple. Select the Administrative Templates container in either the Computer or
User container, right-click it, then select Add/Remove Templates from the shortcut menu. The
Add/Remove Templates dialog box appears, as shown below in Figure 3.8, displaying the
currently active templates. You can then add your new template to the list, and youve
successfully extended Group Policy.

Figure 3.8: The Group Policy Editor Add/Remove Templates dialog box.

While templates are pretty straightforward and can be created using only a simple text editor,
Group Policy Editor snap-ins require some programming. Not only will you have to create the
snap-in for the graphical user interface (GUI), youll also have to build your own CSE for the
snap-in. For those of you who need to build a snap-in or just want to learn more, take a look at
the Microsoft Platform SDK to get a better idea of what is required. (Go to the Microsoft site at
www.msdn.microsoft.com.)

Group Policy Tools and Troubleshooting

By this point, I hope you see that Group Policy is the most efficient way to look after the security
settings of your environment. If you do, and the better you understand both AD and GPO
implementations, tools, and troubleshooting techniques, the better youll be able to provide
security for your infrastructure. This section will describe three of the most important tools for
managing your GPOs:

Group Policy Editor

Group Policy Resultant Set of Policies tool

Group Policy Object Verification tool.

86

Chapter 3
Group Policy Editor
You can use the Group Policy Editor MMC snap-in either as an extension to one of the other AD
administrative snap-ins or as a stand-alone MMC console. Typically, you launch the Group
Policy Editor from within the Active Directory Users and Computers or Active Directory Sites
and Services MMC snap-in. You view the properties of a site, domain, or OU container, click the
Group Policy tab, then double-click a GPO. Figure 3.9 shows what the Group Policy Editor
looks like when you start it up.

Figure 3.9: The Group Policy Editor MMC snap-in.

In case youre wondering, you should install the Group Policy Editor by default on all of your
domain controllers. Many times, though, youll want to start it from your desktop Windows 2000
Professional computer. To ensure that you have this and the other administrative MMC snap-ins,
youre best off running the ADMINPAK.MSI package, which is located in the i386 folder on the
Windows 2000 Server CD.
While you can start the Group Policy Editor using the other AD administrative snap-ins, you
should also become familiar with loading it using the MMC console directly and from the
command line. To start the Group Policy Editor from the command line, use the command:
gpedit.msc

When you load a GPO into the Group Policy Editor using any mechanism, the GPO is said to be
in focus. You cant change the focus of the Group Policy Editor once the console is in use, and
you must select the focus when the extension is added to MMC or as a command-line parameter.

87

Chapter 3
If you start the Group Policy Editor from the command line without parameters, the local policy
of the computer youre using is displayed in the console. To modify this behavior,
GPEDIT.MSC supports two command-line switches to modify the default focus of the console:

For a specific computer:

/gpcomputer:<machinename>

where <machinename> can be either a NetBIOS or a DNS-style namefor example:

gpedit.msc /gpcomputer:"dc01")

For a specific Active Directory Service Interfaces (ADSI) path:

/gpobject:<ADSI path>

For example:
gpedit.msc /gpobject:"LDAP://CN={31B2F340-016D-11D2-945F00C04FB984F9},CN=Policies,CN=System,DC=internal,DC=sheabear,DC=co
m"

Group Policy Resultant Set of Policies Tool

When youre initially deploying GPOs in your environment, youll run into circumstances where
certain settings arent being applied the way you think they should be. The best way to
troubleshoot this is to look at what GPOs are actually being applied to a specific computer or
user object and determine what the resultant set of policies are after all of the inheritance,
blocking, no overriding, and filtering has occurred.
Thankfully, Microsoft provides a tool in the Windows 2000 Resource Kit for the express purpose
of examining resultant set of policiesnamely, the Group Policy Resultant Set of Policies tool,
or GPRESULT.EXE. Listing 3.1 shows sample output from GPRESULT for just the computer
settings of the applied GPOs. (I removed a number of superfluous blank lines to save a little
space, so your output may be spaced slightly differently.)

88

Chapter 3

C:\>gpresult /C
Microsoft (R) Windows (R) 2000 Operating System Group Policy Result
tool
Copyright (C) Microsoft Corp. 1981-1999
Created on Sunday, May 20, 2001 at 12:39:49 PM
Operating System Information:
Operating System Type:
Domain Controller
Operating System Version:
5.0.2195.Service Pack 1
Terminal Server Mode:
Remote Administration
###############################################################
Computer Group Policy results for:
CN=DC01,OU=Domain Controllers,DC=internal,DC=sheabear,DC=com
Domain Name:
Domain Type:
Site Name:

INTERNAL
Windows 2000
Default-First-Site-Name

The computer is a member of the following security groups:

BUILTIN\Administrators
\Everyone
BUILTIN\Users
INTERNAL\DC01$
INTERNAL\Domain Controllers
NT AUTHORITY\ENTERPRISE DOMAIN CONTROLLERS
NT AUTHORITY\NETWORK
NT AUTHORITY\Authenticated Users
###############################################################
Last time Group Policy was applied: Sunday, May 20, 2001 at 12:34:59 PM
Group Policy was applied from: dc01.internal.sheabear.com
===============================================================
The computer received "Registry" settings from these GPOs:
Local Group Policy
Default Domain Policy
===============================================================
The computer received "Security" settings from these GPOs:
Default Domain Policy
Default Domain Controllers Policy
===============================================================
The computer received "EFS recovery" settings from these GPOs:
Local Group Policy
Default Domain Policy
Listing 3.1: Sample output using the Group Policy Resultant Set of Policies tool.

GPRESULT is actually a pretty simple tool to understand, and it comes with only four
meaningful command-line options:

/vProvides verbose output

/sProvides super-verbose output

/cDisplays only the computer settings

/uDisplays only the user settings.

89

Chapter 3
Become familiar with these options, play with the command, and understand its output. Only by
using the GPRESULT tool frequently will you ever really understand how Group Policy is
applied and be able to troubleshoot when you need to.
Group Policy Object Verification Tool
The last tool that Im going to describe is another Windows 2000 Resource Kit application. This
command-line tool allows you to verify the health of all of the GPOs on your domain controllers.
The Group Policy Object Verification tool (GPOTOOL.EXE) can perform a number of functions
that let you assess how well your GPOs are functioning. A sample output from GPOTOOL is
shown in Listing 3.2.
C:\>gpotool.exe
Validating DCs...
Available DCs:
dc01.internal.sheabear.com
dc02.internal.sheabear.com
Searching for policies...
Found 7 policies
============================================================
Policy {20BB65CB-9384-48F6-B8E6-7F528E75C3CF}
Policy OK
============================================================
Policy {31B2F340-016D-11D2-945F-00C04FB984F9}
Policy OK
============================================================
Policy {333A9570-0381-43F3-94A3-3C712EDF88B5}
Policy OK
============================================================
Policy {6AC1786C-016F-11D2-945F-00C04FB984F9}
Policy OK
============================================================
Policy {895F56E1-DE2D-4E97-978B-9E5838DF9BDF}
Policy OK
============================================================
Policy {A5924BB3-57B8-48BF-ADDD-FE3973ECA7F6}
Policy OK
============================================================
Policy {E749E1F9-A5BC-4BAE-A54F-E12681B5B97A}
Policy OK
Policies OK
Listing 3.2: Sample output from the Group Policy Object Verification tool.

This listing shows just a small fraction of the information that can be revealed using GPOTOOL.
In particular, GPOTOOL can:

Check the consistency of your GPOs

Check the replication of your GPOs, including select GPC properties and entire GPTs

Display extended information for a particular GPO, including properties that cant be
accessed using the Group Policy Editor, such as functionality version and extension
GUIDs

90

Chapter 3

Browse GPOs based on friendly name or GUID

Check GPOs in different domains

Provide verbose information in the case of GPO errors, including information about
corrupted policies.

Compared to GPRESULT, the syntax and switches available in GPOTOOL are a bit more
complicated. But the same advice holds here as well. Spend some time playing with GPOTOOL,
become familiar with how it works, become familiar with all of its nuances, and youll be
prepared if you run into problems with your GPOs and need to spend time troubleshooting.

Group Policy Best Practices

When Microsoft released Win2K, there was obviously not a lot of industry consensus on how to
best use Group Policy. But if youd read through all of the documentation that Microsoft
published, youd have found that it recommended seven ways to approach GPO deploymenta
rather short list of Group Policy best practices.
With a lack of strong recommendations from Microsoft, many of us in the industry had to go it
alone and work within our companies and among other organizations to learn all we could about
how to best deploy Group Policy. As a result, Ive built on Microsofts original best practices to
create a set of considerations and deployment goals that will help you implement Security Group
Policy in your environment.
Notice that I said Security Group Policy. Some of the recommendations that I make are geared
explicitly to deploying a set of GPOs that provide security for your environment. That is the
overall focus of this section. But rest assuredmuch of what I talk about will also apply to GPO
deployment in general.
Group Policy Considerations
First, Ill discuss a number of issues that you need to keep in mind when designing your Group
Policy infrastructure. These issues are generic and encompass most of Microsofts initial
recommendations.
Discontinuing Using NT 4.0 System Policy
Group Policy was designed to supersede the functionality provided by the NT 4.0 System Policy
Editor. As I discussed at the beginning of this chapter, the System Policy Editor suffers from a
number of deficiencies, including the fact that the settings are really not very secure. Unless you
have a really strong rationale for using them, you should migrate all of your NT 4.0 System
Policy Editor settings to GPOs and discontinue using System Policy.
Designing the Active Directory Structure
Deploying Group Policy is a key consideration when designing the structure of AD. This is
crucial because Group Policy application is directly tied to the AD structure. Because of this
symbiotic relationship, AD and GPO deployment should be designed in tandem and by the same
group of people.

91

Chapter 3
Blocking Policy Inheritance
As I discussed earlier in this chapter (see Blocking Group Policy Inheritance), you can prevent
GPO settings of parent AD containers from affecting users and computers in lower-level AD
containers. Use this powerful and useful feature only when a particular situation requires it so
that troubleshooting policy doesnt become overly complicated.
Forcing Policy Inheritance
Just as you should use blocking policy inheritance judiciously, so you should ensure that policy
settings in a given GPO on a higher-level AD container are enforced on a lower-level AD
container. Once again, overusing this feature can complicate troubleshooting policy.
Restricting the Number of GPOs
While you can assign multiple GPOs to a particular AD container, the number of GPOs you
assign can affect logon-processing time. Remember, when a user logs on, each GPO associated
with an AD container is processed; thus, the greater the number of associated GPOs, the longer
the logon will take to process. If circumstances allow, you can also collapse multiple GPOs into
a single GPO.
Filtering GPOs Using Security Groups
Another effective method for minimizing the number of GPOs that needs to be processed is to
use security groups and ACLs to filter the GPOs that arent required for a particular user or
computer object. When you filter a GPO, make sure that the Read and Apply Group Policy
access control entries (ACEs) are used in tandem.
Applying User-Based versus Computer-Based GPO Settings
As I mentioned earlier in this chapter, computer-based settings take precedence over user-based
settings when a conflict occurs between them. The only time you should take advantage of this
behavior is when you need the desktop configuration to be the same regardless of which user
logs on.
Assigning GPOs Across Domains
Although GPOs from different domains can be assigned to a single AD container, processing a
GPO from another domain is significantly slower because domain boundaries are being crossed.
To avoid performance degradation, you must evaluate considerations to duplicate some GPOs
across multiple domains. Although this will increase your administrative overhead, the reduced
processing time can be worth the added complexity.

92

Chapter 3

Administering GPOs
Delegation of authority, separation of administrative duties, centralized administration, and
flexibility are important factors to consider in designing Group Policy. An essential
consideration is who has Read/Write access to a GPO. Such access allows all aspects of a GPO
to be controlled and modified. Giving careful consideration to who has Read/Write access on
security GPOs, as opposed to just Read access, is an important part of the overall security of
your Win2K environment.
Using a Top-Down Approach
While the considerations above give you something to think about, I recommend that the best
way to create a worthwhile Security Group Policy implementation for your enterprise is to
approach the design of your GPOs from the top down. As a result, try to mirror your
organizations security policy as closely as is practical. Put its broadest security policies at the
highest positions in your AD hierarchy. As you move down the AD hierarchy, make the GPO
settings more specific to implement your organizations security policy in a meaningful way.
Understanding Resultant Policies
As you design your GPO infrastructure, carefully consider where you need to apply security
policy in the AD hierarchy. At the same time, keep in mind the desired GPO settings that are to
be applied above and below the GPO in consideration. This should allow you to determine what
the resultant set of policies is at each level in your AD hierarchy.
Defining Local GPOs for Stand-Alone Computers Only
While you should without a doubt define a local GPO for any of your stand-alone or workgroup
computers, dont worry about defining a local GPO for your AD-integrated computers. Local
policy will be overwritten anyway and doesnt scale anywhere, so dont waste time on it for
computers that are members of one of your domains.
Using Site GPOs for Items Dependent on Network Location
It sounds kind of trite, but only use site-linked GPOs for site-related settings. While none of the
security-related settings are really site-dependent, go ahead and use a site GPO for things like
network options, software installation, printers, and other items that really do depend on network
location.
Using Domain GPOs for Major Items
Once again, it sounds simple, but only use domain-linked GPOs to configure settings that are
intended to affect the entire domain. This is one of the best places to specify security-related
GPO settings such as logon restrictions, password policies, and so on that are related to the
overall administration and configuration of the domain. This makes sense when you consider that
the domain is the largest administrative boundary in Win2K, so you might as well implement
GPO settings that affect everyone in administrative control in a single place.

93

Chapter 3
Using OU GPOs to Refine Domain GPOs
Use GPOs that are linked to OUs to refine your domain-level GPOs and provide more specific
settings where appropriate. These policies should rarely be used for GPO security settings but
should instead be used to do things like deploy specialized applications for a group or change
desktop behavior. Overall, GPOs linked to your domains should set most of your policies, and
GPOs linked to your OUs should be just specialized and required tweaks to your environment.
Creating Security-Specific GPOs
Create specific GPOs for the security settings in your environment. These GPOs should specify
the security-related settings, as Ive mentioned above and as defined by Microsoft. They should
also encompass any GPO settings that you feel are crucial to the security of your environment. In
addition to segregating your security GPOs, make sure that the settings defined in your security
GPOs arent defined in any other non-security GPO in your environment. It makes no sense to
set a particular security setting to the same value in multiple GPOs, and it makes even less sense
to have conflicting values set on an object.
Defining Security GPOs Based on Roles
Not only should security GPOs be segregated, they should also be specific and defined based on
the expected roles of the computers in your environment. For example, consider defining
multiple security GPOs, such as Workstation Security Policy, Domain Controller Security
Policy, File Server Security Policy, and Internet Information Server (IIS) Security Policy.
Evaluate your environment and decide how to best build GPOs based on these computer roles.
Whatever you decide, create a security group (for example, Domain IIS Servers) to contain all
the computer objects of the same kind. Then assign only the Read and Apply Group Policy
ACEs to the Domain IIS Servers security group and manage the application of the GPO using
membership in that security group.
Restricting Administrative Access to Security GPOs
This sounds simple, but you need to remember to do it and stay vigilant in restricting
administrative access to the security GPOs in your environment. Create a security group (such as
Security GPO Admins) explicitly to contain the administrators of your security GPOs. Then
assign Read and Write ACEs to only this security group and manage the administration of the
GPO using membership in the group.
Giving Up Registry Editors
For years, Microsoft has told us not to go into the Registry and make modifications by hand. We
all know Microsoft has to take this stance, as such we typically ignore this advice and use tools
like REGEDT32.EXE every chance we get. While you may still need to use a Registry editor
from time to time, I recommend that you dont make modifications to the Registry that you
intend to be permanent. Instead, let GPOs do the work for you. Only use a Registry editor as a
last resort or as a test to ensure that a setting works in your environment. Then make sure that
you put the Registry settings into a GPO and apply it that way.

94

Chapter 3

Summary
Group Policy allows an administrator to centrally define, manage, and enforce environment
settings for both computer objects and user objects. Group Policy maintains the state of computer
and user settings without the need for administrative intervention and is handled automatically.
The capabilities of Group Policy wouldnt be possible without the tight integration that has been
achieved between it and AD. This integration is summarized for you in Figure 3.10.

Figure 3.10: The integration of Group Policy and AD.

While Group Policy has many capabilities, its the ability to centrally manage security settings
that makes it such an important tool. Group Policy is the mechanism youll use to ensure that the
security configurations of your Win2K infrastructure are applied consistently and without fail. I
hope youll agree that Group Policy is an exciting and effective tool for managing the security of
your Win2K infrastructure.

95

Chapter 4

Chapter 4: Understanding Authentication

As I discussed in Chapter 1, authentication provides the ability to positively prove that a security
principal is who or what it claims to be. Although authentication is usually associated with users,
it applies equally to all security principalsusers, computers, and applications. The security of
your environment is only as strong as the authentication of your security principals. Without
proper authentication, other security mechanisms in your environment, such as access control
and auditing, have no credibility.

What It Is
Authentication is simply a process that verifies someones or somethings identity. For example,
think about what happens when you cash a check. When you present the check, youre typically
asked for your drivers license. Your drivers license is used to authenticate you. It ensures that
the picture on the ID looks like you, that the ID appears to be authentic and not tampered with,
and that the ID was issued by a valid authority. It isnt a perfect form of authentication, but its
one of the most predominant ones in use today.
Back in the realm of computer science, there are typically two types of authentication:

Single-entity authenticationAuthentication occurs in a single direction. In some

cases, a client proves its identity to a server; in other cases, the reverse occurs, and a
server proves its identity to a client.

Mutual authenticationBoth client and server prove their identity to the other.

While I mention clients and servers, dont think of only computers. Whenever I talk about
authentication, think of clients and servers as users, computers, and applications.
Authenticating Users
Now that you have a basic understanding of authentication, lets take a quick look at the four
typical ways that users can be authenticated. Youre typically authenticated by:

Something you knowTypically, a secret piece of information that you need to

remember. While its typically a simple password or Personal Identification Number
(PIN), it can also be something like a digital private key.

Something you haveTypically, a security token or a key that you carry around with
you. It can be a smart card or a security token such as the SecurID token from RSA Data
Security.

Something you areTypically, a biometric measurement of some part of you.

Biometric authentication can use fingerprints, voiceprints, retinal scans, and many other
measurements of your physical attributes.

A combination of the aboveTypically, a combination of two of the first three methods

and usually called two-factor authentication. A typical example of two-factor
authentication is using a smart card and a PIN. Using two-factor authentication provides
greater assurance of the authenticated identity of a user than a single method.

96

Chapter 4
Authenticating in Windows 2000
Windows 2000 (Win2K) uses a number of authentication protocols, primarily Kerberos and NT
LAN Manager (NTLM). Kerberos is a new protocol for Microsoft, and NTLM remains
unchanged from the version that was introduced in Service Pack 4 for NT 4.0. Win2K supports a
few additional authentication protocols in its Web server and File Transfer Protocol (FTP)
implementations, both of which are part of Internet Information Services (IIS). IIS also supports
the Basic authentication method, the Digest authentication method, and Secure Sockets Layer
(SSL) authentication. Table 4.1 lists these authentication methods and the authentication
protocols they use in Win2K.
This Authentication Method

Uses These Authentication Protocols

Interactive logon

Kerberos (using both passwords and smart cards)

and NTLM.

Non-interactive logons, including Server

Message Block (SMB)/Common Internet File
System (CIFS) network share access, network
printer access, authenticated Remote Procedure
Calls (RPCs), and Active Directory (AD) access

Kerberos and NTLM.

Internet Protocol Security Protocol (IPSec)

Kerberos, shared secrets, and digital certificates.

IIS when used with Internet Explorer (IE)

Basic, Digest, SSL, and integrated Windows

authentication (that is, Kerberos and NTLM).

Table 4.1: The authentication protocols used in Win2K.

In this chapter, Ill look at each of these authentication protocols. When Im finished, I hope
youll have gained an in-depth understanding of them and are better prepared to maximize their
use in your Win2K infrastructure.

Using Kerberos V5: The New Authentication Scheme

Kerberos; also spelled Cerberus. n. The watchdog of Hades, whose
duty it was to guard the entranceagainst whom or what does not
clearly appear; . . . it is known to have had three heads . . .
Ambrose Bierce, The Enlarged Devils Dictionary
In earlier versions of NT, NTLM was the default protocol for network authentication and identity
propagation. Unfortunately for Microsoft, NTLM was also the vehicle for a number of hacker
exploits against these versions of NT. As a result, Win2K has adopted Kerberos V5 as its default
protocol for network authentication and identity propagation.
Originally created at the Massachusetts Institute of Technology (MIT) as part of Project Athena,
Kerberos was designed on the assumption that initial communications between a client and a
server would take place on an unsecured network. Thus, the protocol ensures that it can prove the
identity of both client and server without passing credentials in the clear or in a format that is
easily compromised (like initial versions of NTLM).
Installing Kerberos in your environment is pretty painless; all you have to do is install a Win2K
domain controller. From then on, all of the Win2K computers in your domain automatically use
Kerberos as their default authentication protocol.

97

Chapter 4
As an authentication protocol, Kerberos provides a way for two entities to mutually authenticate
each other before a network connection is opened and used. It works not only between a client
and a server but also between one server and another. Kerberos provides the means to verify the
identities of user, application, and computer security principals on an unsecured network. As a
network authentication protocol, Kerberos uses symmetric key cryptography to provide strong,
mutual authentication between two entities on a network. As I said above, mutual authentication
is established before the parties use their network connection. (For more details on symmetric
key cryptography, see What Makes It Work later in this chapter.)
A Review of Encryption
The word cryptography has its origins in Greek words meaning secret and writing; translated literally,
this becomes secret writing. Today, cryptography often refers to information being rewritten in an
unintelligible form so that others outside the conversation cannot understand what is being said. Kerberos
needs to use cryptography to function properly. For our purposes, Ill describe the three basic kinds of
modern cryptography functions: secret key functions, which use one key; public key functions, which use
two keys; and hash functions, which use no keys.
Secret-key cryptography uses a single key to encrypt and decrypt information. Often referred to as
symmetric encryption, secret key cryptography converts plaintext to ciphertext and back again using the
same key for both operations. When you want to exchange information with someone else using secret
key cryptography, you must both have a copy of the same key. Your friend uses the key to encrypt
messages and send them to you. When you receive a message, you decrypt it using your copy of the
key. Probably the most well-known secret key encryption function is the Data Encryption Standard (DES).
Win2K uses symmetric key encryption extensively in the Kerberos protocol.
Public-key cryptography uses two keys to encrypt and decrypt information. These keys are typically
referred to as a private key and a public key. The private key is for you to hold on to and not share with
anyone else, while the public key is meant to be shared with anyone and everyone. To receive a public
keyencrypted message from someone else, that person uses your public key and encrypts the plaintext
into ciphertext. Because of the relationship between a public/privatekey pair, anything encrypted with
one key can be decrypted only with the other key. As a result, the only person who can decrypt a
message sent to you with your public key is you (assuming that you kept your private key private like you
were supposed to). The Rivest-Shamir-Adleman (RSA) algorithm is a good example of a public key
cryptography function. Win2K uses public key cryptography in a number of areas, including smart cards,
IPSec, secure e-mail, and the encrypting file system (EFS).
Hash functions are interesting because they dont really use keys, and they can take a message of any
arbitrary length and produce a short, fixed-length, unique numerical value. Hash functions have some
pretty unique properties, and they show that its computationally not feasible to find messages that will
hash to the same numerical value. Typically, hash functions are used to do things like protect the integrity
of a message. Two of the most well-known hash functions are MD5 and SHA-1. Win2K can use both of
these functions to ensure that, among other things, secure e-mail messages havent been tampered with
and that IPSec network packets havent been modified in transit.

For those of you who run a heterogeneous environment, Kerberos can also act as the foundation
for a single sign-on solution. The full integration of the Kerberos authentication model into
Win2K and its domain structure has led Microsoft to create the logical beginnings of a standardsbased, heterogeneous, single sign-on environment that is structured around Win2K. Single signon can provide a number of cost benefits to you and your organization.

It reduces the time it takes for users to sign on and reduces the number of failed sign-on
attempts that occur because of user error

It reduces the time that system administrators spend adding, removing, and modifying
user information, thereby allowing them to concentrate on other value-add activities

98

Chapter 4

It improves security by reducing the number of user name/password combinations that

users need to remember

It improves security by enhancing an administrators ability to maintain the integrity of

user-account configurations.

If your organization is currently running a homogeneous NT environment, you already reap all
of these single sign-on benefits. For organizations with a healthy mix of Windows and UNIX
hosts, you now have a network authentication solution in Kerberos that can allow you to
integrate your UNIX and Win2K environments and provide single sign-on between them.
(Discussing how to achieve this seamless interoperability is well beyond the scope of this
chapter. For those of you who need this capability, check out the Win2K Technical Resources on
Microsofts Web site at www.microsoft.com/windows2000/techinfo/default.asp.)
Advantages over NTLM
Why did Microsoft go with Kerberos instead of just fixing the security issues in NTLM? Simply
put, Kerberos is a more flexible, efficient, and secure protocol than NTLM could ever be without
a major overhaul. More specifically, compared to NTLM, Kerberos provides the following
benefits to you and your organization:

Better performanceServers using NTLM must validate every access to a resource

against a domain controller. On the other hand, Kerberos servers can authenticate a client
directly by verifying its presented credentials; it doesnt have to consult a domain
controller. In addition, Kerberos clients can obtain credentials for a server once per logon
session, cache them, then reuse them as needed for subsequent logon attempts.

Mutual authenticationNTLM provides only single-entity authentication, where the

servers authenticate the clients. Kerberos, on the other hand, uses mutual authentication,
thereby allowing both parties to authenticate each other.

More robust authentication delegationNTLM and Kerberos both allow a service to

impersonate a client on the local computer. Kerberos has the additional capability to use a
proxy mechanism to allow a service to impersonate a client when it communicates with a
service on another computer.

Two-way, transitive trustAs I discussed in Chapter 2, Win2K domains use Kerberos

trust relationships that are two-way and transitive. Remember that this allows for a
simplified domain-trust model, in which all domains in a forest automatically trust each
other. It also eliminates the complex trust relationships required to set up the multiple
master-account domains and resource domains that so many of us have had to contend
with in our NT 4.0 infrastructures.

InteroperabilityAlthough a lot of noise has been made about its implementation,

Kerberos sets the stage for interoperability with other operating systems (OSs) running
Kerberos V5 implementations. Interoperability can allow a single set of logon credentials
to be used across a multitude of platforms and can reduce the number of times your users
sign on. In the best of cases, you can create a single sign-on environment across your
entire infrastructure, as I discussed above.

99

Chapter 4
High-Level Overview
Before going into all of the intricacies of the Kerberos protocol and concepts, I want to give you
a high-level look at Kerberos and grounding in how it works. As Figure 4.1 shows, the Kerberos
protocol revolves around the Key Distribution Center (KDC). The KDC provides the core
mechanisms for clients and servers to prove their identities to one another. These mechanisms
rely on the secret keys that Kerberos generates and maintains for each user and service in a
Win2K domain. These secret keys are shared between the KDC and each of these users and
services to prove their identities.

Figure 4.1: A high-level view of the Kerberos protocol.

To understand how these secret keys are used and how they provide truly authenticated
identities, Ill present a high-level look at what happens when you log on to a Win2K domain
and need to access a network resource. This occurs in seven basic steps.
1. You log on to a domain workstation by entering your user name and password. Kerberos

takes this information and converts your password to a secret key. This secret key and
your user name form the basis of an authenticator, which is submitted to the KDC for
authentication.
2. The KDC extracts the authenticator and compares your secret key against password

information stored in AD to verify your identity. If the information matches, the logon
information that you supplied is correct, and youre now authenticated.
3. The client computer automatically requests a ticket-granting ticket (TGT) for you. This

ticket proves that youve successfully authenticated to the domain, and its used in
subsequent communications with the KDC to prove your authentic identity. Ill discuss
the TGT later in this chapter (see Ticket-Granting Tickets), so for now, Ill say that it
contains a key shared between you and the KDC and is encrypted with your secret key.
4. Now its time to access a domain resource. Kerberos requests another ticket, a session

ticket. (I describe these in more detail later in Distributing Keys Using Session Tickets,
but suffice to say that its encrypted with the network resources secret key and contains,
amongst other things, a session key.) To obtain a session ticket, the Kerberos client
submits your TGT as proof that an authentic security principal is requesting this session
ticket.
5. The KDC returns the session ticket and a copy of the session key, encrypted with your

shared secret key, for your use.

100

Chapter 4
6. Kerberos uses the session key returned from the KDC to create an authenticator, which

will be presented to the network resource that you want to access. For now, think of the
authenticator as the current time encrypted with the session key; Ill talk more about it
later (see Authenticators Provide Mutual Authentication). The authenticator and KDCencrypted session ticket are then submitted to the network resource for access.
7. The network resource uses the secret key that it shares with the KDC to decrypt the

session ticket. This reveals the session key, which is shared between you and the network
resource. In turn, the resource uses the session key to decrypt and validate the
authenticator. Youre now successfully authenticated to the network resource for which
youve requested access.
One of the first things to note about the Kerberos protocol is that the network resource doesnt
have to go to the domain controller to validate the clients credentials. Instead, validation is
handled transparently by the protocol when the session ticket is encrypted by the KDC with the
secret key it shares with the network resource. When the network resource validates the session
ticket, it knows that the KDC has vouched for your identity. This process accounts for a big
portion of the performance advantage that Kerberos has over the NTLM protocol.
The other portion of the performance advantage of Kerberos is accounted for by caching. Once
you have a session ticket to access a network resource, Kerberos caches it for future use. The
next time you try to access the network resource, Kerberos only has to execute steps 5 and 6
again. Eventually, however, your session ticket will expire, and Kerberos will need to execute
Step 4 again to obtain a new one.
What Makes It Work
Now that you have an idea of how the Kerberos protocol functions, Ill describe what makes
Kerberos work and what core concepts are rolled into these functions. First off, Kerberos is
predicated on the use of shared secrets. This works well because if only two parties know a
secret, either one of them can authenticate the other one by verifying that it knows the secret.
The concept is simple, and it works really well for secrets shared by two parties.
For example, lets suppose that two parties, A and B, want to communicate with each other. In
addition, Party B wants to be 100 percent sure that its communicating with Party A whenever it
receives a message from it. To do this, parties A and B can agree on a secret and not share this
secret with anyone else; Ill say that they use something simple like a password.
The shared secret can be effective only if Party A can prove that it knows the password
whenever it sends a message to Party B. A simple way to do this is for Party A to include the
password in its message. When Party B reads the message, it verifies that the password is
included as part of the message.
While this might work in some situations, it doesnt take into account the possibility of a third
party intercepting the message and stealing the secret shared between parties A and B. Herein
lies one of the cool problems in modern authentication schemes: To keep the password truly
secret, Party A must prove that it knows the secret without revealing it to Party B or any other
party that might be snooping around.

101

Chapter 4
How do you prove you know something without revealing it? A popular way to solve this
problem, and the way Kerberos solves it, is by using symmetric key cryptography. Symmetric
key cryptography allows parties A and B to share a single cryptographic key and use it to
authenticate each others identity without revealing the shared key. This works because a
symmetric key can both encrypt and decrypt information. As a result, one party can prove that it
knows the shared secret by encrypting some piece of information and letting the other party
decrypt it.
Authenticating with secret keys is the fundamental building block of the Kerberos protocol.
Kerberos builds on this using a few key concepts that make Kerberos work. These concepts are:

Authenticators

Symmetric key distribution

Session tickets

TGTs.

Authenticators Provide Mutual Authentication

In the high-level overview of the Kerberos protocol above, I mentioned something called an
authenticator. To understand how Kerberos works, this is the first concept to understand.
In the Kerberos protocol, an authenticator is information encrypted with a shared secret key.
Each time an authenticator is constructed, it must use a different piece of information. If
authenticators didnt use different information, an eavesdropper could reuse any captured
authenticator to impersonate the authenticators real identity. For example, if you were to always
use just your first name as the value in an encrypted authenticator, every message you sent to
another party would contain an identical authenticator. Obviously, this isnt desirable because
any captured authenticators that were replayed by an eavesdropper couldnt be differentiated
from a valid authenticator that you constructed.
Using authenticators allows one party to authenticate another without revealing their shared
secret. To better understand how authenticators actually help provide authentication, lets walk
through a simple example. Going back to parties A and B, lets see how their agreement on a
shared secret key can authenticate each other without either party having to reveal the actual
secret and thus protecting the shared secret from being stolen by any eavesdroppers. This is
shown in Figure 4.2.

Figure 4.2: Mutual authentication using authenticators.

To authenticate each other, parties A & B can use the following simple, three-step protocol:

102

Chapter 4
1. Party A sends a message to Party B that consists of two parts: the actual message and an

authenticator. The authenticator consists of two pieces of information encrypted with the
shared secret key. For the purpose of our example and one that relates to how Kerberos is
implemented, lets say that these two pieces of encrypted information are the name of
Party A and the current time.
2. When Party B receives the message from Party A, it uses its knowledge of the shared

secret key to decrypt the authenticator and retrieve the two pieces of information. Then it
must verify them. It first verifies that the unencrypted name in the authenticator matches
the name of Party A. If the names dont match, the message mustnt have been encrypted
with the correct shared secret, and hence the party couldnt possibly be Party A, as its
claiming to be.
Party B then validates the time contained in the authenticatorfor example, by
comparing this time with the current time. If the difference is greater than an agreed-on
value (say, five minutes), Party B can reject the authenticator as old and not valid. Of
course, this works only if the time sources used by both parties are reasonably
synchronized. In fact, the Kerberos protocol requires that system clocks are reasonably
well synchronized. Lets assume that the time sources for parties A and B are perfectly
synchronized.
But what does it really mean if the time in the decrypted authenticator is in the agreed-on
five-minute window? It means that the authenticator was constructed by Party A, but it
doesnt necessarily prove that it was sent from Party A. Consider the possibility that our
eavesdropper has intercepted a previous message and attached an old authenticator to a
new message that it constructed.
Party B can protect itself from this pretty easily; all it has to do is keep track of the last
time contained in an authenticator received from Party A during the past five minutes. In
this fashion, Party B can protect itself from reply attacks from an eavesdropper by
rejecting all messages that come in with a time that is the same as, or earlier than, the
time contained in the last authenticator it received. Now, if the time retrieved from the
authenticator is later than the time of the last received authenticator, the message must
have come from Party A. Party B has now verified the identity of Party A, and one-way,
single-entity authentication has been achieved.
3. Now Party A needs to authenticate the identity of Party B. Party B takes just the original

time information from the first authenticator and encrypts it with the shared secret. If
Party B sent the original information back as the authenticator, Party A wouldnt be able
to differentiate it from a valid authenticator or a replay of the original authenticator from
our eavesdropper. By sending back just the unique portion of the original authenticator,
Party B proves that it was able to decrypt the original authenticator and use the
information it contained.
When Party A receives the reply, it decrypts the new authenticator and validates that the
time it contains is the same time that was contained in the original authenticator. By
validating the times, Party A knows that its original authenticator reached a party that
knows the shared secret key required to decrypt the authenticator and extract the time
value from it. Because Party A shares this secret key only with Party B, it must have been
Party B that received the original message and replied.

103

Chapter 4
This simple protocol shows how using a shared secret key can allow two parties to mutually
authenticate each other. Its a concept crucial to understanding how Kerberos works.
Distributing Keysthe Issues
If all you ever have to do is keep track of a shared secret key with one other party, its pretty
easy. But keeping track of shared secrets with a thousand parties is a different story. This is the
Achilles heel of using authenticators as a method for providing mutual authentication. How do
you agree on a shared secret key with a number of different parties, and how do you remember
them all? Think about it for a second. If the parties were you and I, we could talk on the phone,
or meet in person somewhere, to agree on a secret key. We might even be able to do this with a
handful of other individuals. But this method obviously has serious scalability problems.
Now lets consider the reality that parties A and B arent usually two people, but a client
application and a server application somewhere in our Win2K infrastructure. How is a client
application going to set up a shared secret key with a server application out on the network? To
compound matters further, a single client may need to talk to multiple servers, and a single server
may need to talk with multiple clients. If each client needs to share a secret with every possible
server, and if each server needs to share a secret with every possible client, how in the world can
they securely set up, keep track of, and use that many shared secret keys?
Those of you who read the definition of Kerberos at the beginning of this section may have
wondered what a three-headed dog had to do with a network authentication protocol. The
decision to name the protocol after such a creature was based on the method chosen to solve the
problem of distributing shared secret keys. Like the mythological figure with its three heads,
Kerberos involves three entities: the client, the server, and a trusted third party. This trusted third
party is the KDC, which I mentioned earlier in the high-level overview of Kerberos.
In the Kerberos protocol, the KDC is the entity that keeps track of all of the parties in a realm
that might need to communicate with each other. Kerberos uses the term realm, which is a
concept analogous to a domain in Win2K. To not confuse matters, when I refer to a Kerberos
realm, Ill use the term domain to remain consistent with the Win2K nomenclature.
Ill discuss what the KDC does in detail later in this chapter (see Understanding the Key
Distribution Center), but for now, Ill say that the KDC stores a shared secret key with each and
every security principal it keeps track of. This shared secret key is used between the KDC and
the appropriate security principal as necessary when they exchange communication. Now each
party needs to remember only one shared secret keythe key it shares with the KDC.
This key is often referred to as a long-term key because it changes only infrequently. For user
accounts, its typically derived from the users password. For non-user accounts, its typically
generated when the account is added to the KDC, and its maintained automatically.

104

Chapter 4
How do we go from sharing a secret key with only the KDC to sharing a secret with everyone
else in the domain? The answer lies in using a short-term session key. Before a client can
communicate with a server, it sends a request to the KDC, announcing its intentions. The KDC
generates a unique session key that the client and server will use to authenticate each other. The
KDC distributes this key to the client by encrypting the session key with the long-term key that it
shares with the client. The KDC then distributes this key to the server by encrypting another
copy of the session key with the long-term key that it shares with the server as shown in Figure
4.3.

Figure 4.3: The theoretical scheme for distributing keys.

Unfortunately, distributing keys in the manner shown in this figure would be problematic at best
and at worst impossible. Sending encrypted session keys directly to each party would be a
problem for two reasons. First, the server would have to keep a copy of the session key around
while it waited for the client. Not only would it have to remember this one session key, but it
would have to remember all of the session keys that it was sent from the KDC because, as I
discussed earlier, clients cache these session keys. Second, if the client was able to communicate
with the server before the server received the session key from the KDC, the connection
wouldnt complete, and users would find the protocol flaky and somewhat unpredictable.
Thankfully, Kerberos implemented a different protocol to distribute the shared session key
between a client and a server.
Distributing Keys Using Session Tickets
Kerberos finishes the task of distributing shared session keys, thereby allowing a client and a
server to authenticate one another, using a method called a session ticket. A session ticket is
constructed by the KDC and given only to the client, which in turn uses it to communicate with
the server. The session ticket includes a number of pieces of information, but its the inclusion of
the servers copy of the encrypted session key that makes the session ticket interesting. Along
with the session ticket, the KDC returns the session key encrypted with the long-term secret key
shared with the client. This process is shown in Figure 4.4.

105

Chapter 4

Figure 4.4: Using a session ticket to distribute keys.

Using this scheme, no one other than the client needs to keep track of all of these session keys.
All that the KDC needs to do is generate session keys, create tickets, and send them to the
clients. It doesnt need to keep track of anything else. If an eavesdropper happens to get hold of
one of these replies, it cant do anything nefarious with it. The only entity that can recover the
session key is the client, and the only entity that can decrypt the ticket and recover the other copy
of the session key is the server. Using a session ticket is actually quite ingenious, and it keeps the
protocol simple.
Figure 4.5 below shows how both parties authenticate each other. The client decrypts the session
key and creates an authenticator, which, as discussed above (see Authenticators Provide Mutual
Authentication), contains the clients name and the current time. The authenticator is bundled
with the session ticket and sent to the server. These two values are then encrypted with the
session key that was retrieved using the long-term shared secret between the client and the KDC.

Figure 4.5: The client and server mutual authentication protocol.

When a server receives an authentication attempt from a client, the server goes about using the
long-term shared secret that it shares with the KDC to decrypt the session ticket. In the session
ticket, the server finds its copy of the session key. It then uses the session key to decrypt the
clients authenticator. If everything decrypts correctly and all of the information is validated, the
server knows that the session ticket was issued by the KDC and that the KDC vouches for the
identity of the client. To finish the mutual authentication process, the server uses its copy of the
session key to encrypt the time value it received in the clients authenticator, as I described
above.

106

Chapter 4
Using session tickets has two main advantages:

The server doesnt need to keep track of session keysIts the clients responsibility
to keep track of session tickets and the shared secret between the client and server. The
only key that the server needs to keep track of is the long-term secret key it shares with
the KDC. When the server is done using a session key, it can just discard it.

The client doesnt need to consult the KDC every time it accesses the server
Session tickets are cached on the client and can be reused. As long as the client creates a
new authenticator each time it accesses the server, the session ticket can be reused until it
expires. (For more information on ticket expiry, see Calculating Their Lifespan later in
this chapter.)

Using Ticket-Granting Tickets

Up to this point, Ive talked about how a users long-term secret is derived from his or her
password. Typically, a user password is converted to a cryptographic key by running it through
some sort of one-way hashing function. The resulting cryptographic key is the long-term secret
that the user shares with the KDC. Using such a scheme, the KDC needs to keep a copy of this
long-term key in its account database and retrieve it whenever a user needs to communicate with
the KDC.
While the KDC could retrieve a clients long-term key for each communication session between
a client and the KDC, it actually happens only once: when the client initially authenticates to the
KDC. After the initial authentication, which uses the long-term key derived from the clients
password, the Kerberos client actually makes a request for a session ticket of its own. The KDC
returns a special session ticket called the ticket-granting ticket (TGT). (The TGT was discussed
in the high-level overview earlier in this chapter.)
The TGT is like any other session ticket in that it contains a copy of a session key that it uses to
communicate with the KDC. Obviously, the client also receives a copy of the session key that it
will use. But what keys are used to encrypt the clients copy of the session key and the TGT
itself? The clients copy of the session key is encrypted with the users long-term key and
decrypted on receipt for later use. The TGT, on the other hand, is encrypted with the long-term
key of the KDC.
The TGT is just another ticket as far as the client is concerned, and its used just like any other
ticket. If a client doesnt have a cached copy of a session ticket for a service that it wants to
access, it just uses the TGT to access the KDC and requests a new session ticket. On the other
hand, the TGT allows the KDC to have its own long-term key and relieves it of the need to look
up the clients long-term key for each and every client access.

107

Chapter 4

Understanding the Key Distribution Center

As Ive discussed, Kerberos includes three main components: the client, the server, and the
KDC. Of these, the KDC is the key to the success of the Kerberos protocol. Its actually
composed of more than what Ive discussed so farthree subcomponents, in fact.

Authentication Service (AS)

Ticket-Granting Service (TGS)

Account database.

Authentication Service and Ticket-Granting Service

Like most every other implementation of Kerberos, the KDC in Win2K is composed of a single
process. Nevertheless, the KDC provides two services for Kerberos:

Authentication Service (AS)Performs initial client authentications and issues TGTs

Ticket-Granting Service (TGS)Issues session tickets for access to domain resources.

While Ive mentioned it before, its worth repeating that the KDC runs on every domain
controller. Both the AS and the TGS are started automatically and run in the context of the Local
Security Authority. (For a review of the LSA, see Chapter 2.) Because these services are part of
the LSA on a domain controller, they cannot be stopped or removed.
For those of you who are interested in details, the security principal name that is used for the
KDC in Win2K is krbtgt. This name is actually specified in RFC 1510, and the account is
created automatically whenever a new domain is created. Like other built-in security principals,
the account cannot be deleted. But unlike other built-in security principals, you cannot even
change the name! Another thing to note about this account is that an initial password is created
when the account is created, and it automatically changes on a regular basis. All in all, there is
nothing you can do with the account, but its useful to know that it exists in your AD.
Account Database
Although I discussed AD in depth in Chapter 2, I cannot finish this discussion about the main
components of Kerberos in Win2K without discussing AD. Thats because AD is the account
database used by Kerberos. Each party, or principal, is represented by an account object in AD.
In fact, the long-term encryption key that I keep talking about is stored in an attribute of the
account object of a user, computer, or service principal.
The long-term encryption key is, as I described above, derived from a password. So while its
not the actual password, access to this attribute of an account object must be limited
appropriately to ensure that it isnt compromised. As a result, read access to this password
attribute is granted only to the account holder itself. No other accounts, not even administrator
accounts, have access to this attribute. In fact, only the processes that run in the context of the
LSA are allowed to read or change this attribute.

108

Chapter 4

For those of you familiar with other Kerberos implementations, the Win2K implementation doesnt use
the Kerberos replication protocol to keep the account database up to date on each of the domain
controllers. Like all other information that is housed in AD, the standard multimaster-replication
protocol updates any necessary Kerberos information amongst domain controllers.

Its Three Sub-Protocols

By this point, Ive touched on most of the characteristics of the Kerberos protocol. The
discussion started at a high level, and Ive been working steadily down to some of the nitty-gritty
details. In this section, Ill describe how Kerberos works in a domain environment by discussing
the three sub-protocols that make up the overall Kerberos network authentication protocol. These
three sub-protocols are:

AS ExchangeUsed between a client logon and the KDC to retrieve a TGT

TGS ExchangeRetrieves a session ticket from the KDC

Client/Server (CS) ExchangeAuthenticates a client to a service.

To put these sub-protocols into context, Ill use example like the one in the high-level overview
earlier in this chapter, where a client gains access to the domain, then accesses a network service.
Ive discussed all of this in one form or another so far, so Ill move quickly through it.
Authentication Service Exchange
It all begins when you log into the domain and enter your user name and password. The Kerberos
client runs your password through a cryptographic hash, amongst other things, and creates your
long-term encryption key. This encryption key is saved for you in the computers credentials
cache in the LSA for later use.
The Kerberos client then begins AS Exchange by sending a Kerberos Authentication Service
Request (KRB_AS_REQ) message to the KDCs authentication service, as shown below in
Figure 4.6. The first part of the request identifies you, the user, and the name of the service to
which youre requesting access. In this case, youre requesting access to the TGS. The other part
of the request contains what is known as pre-authentication data. This data is typically a simple
authenticator; it contains a time stamp encrypted with your long-term encryption key, which is
tucked away in the computers credentials cache.

Figure 4.6: Sending messages using AS Exchange.

109

Chapter 4
When the KDC receives the KRB_AS_REQ message, it retrieves its copy of your long-term key
from AD. It then decrypts your supplied authenticator and evaluates the time stamp it contains. If
the time stamp is within allowable tolerance, the KDC assumes that the authenticator was
encrypted with your long-term key and that you must have entered your password correctly.
The KDC now goes about creating the set of credentials that your Kerberos client will use for the
rest of your logon session. To build these credentials, which will give you access to the TGS, the
KDC generates a random, unique logon session key for you. First, it encrypts this logon session
key with its copy of your long-term key, then deletes its copy of your logon session key because
it wont need it again.
Then the KDC uses a second copy of the logon session key as the basis for your TGT. In
addition to the logon session key, the KDC places other information about you, such as your
authorization data, in the TGT. Once the TGT is fully populated, the KDC encrypts the TGT
with its long-term key. It then packages up both the encrypted logon session key and the TGT
and sends them back to your client workstation using a Kerberos Authentication Service Reply
(KRB_AS_REP) message.
When your client workstation receives the KRB_AS_REP message, it places the TGT directly
into the credentials cache. It once again uses the cached copy of your long-term key to decrypt
the logon session key that was returned. The logon session key is also inserted into the
credentials cache of your workstation. Youre now authenticated to the domain and ready to start
accessing network resources.
Ticket-Granting Service Exchange
Once youre authenticated, the Kerberos client on your workstation starts by sending a Kerberos
Ticket-Granting Service Request (KRB_TGS_REQ) to the KDC, as shown below in Figure 4.7.
This request includes your name, an authenticator encrypted with your logon session key, the
cached TGT, and the name of the service that you want to access.

Figure 4.7: Sending messages using TGS Exchange.

110

Chapter 4
When the KDC receives the KRB_TGS_REQ message, it decrypts the supplied TGT with its
long-term key. The KDC extracts your logon session key from the TGT and uses it to decrypt the
supplied authenticator. If the authenticator is within the allowed tolerance, the KDC generates
another random, unique service session key that will be shared between your client and the
service that youre trying to access. Much like before, this session key is first encrypted with
your logon session key. Then a second copy of the service session key forms the basis of the
session ticket. The KDC then extracts your authentication data from your TGT and puts it, along
with other necessary information, in the session ticket.
Once the session ticket is fully populated, the KDC encrypts the service session ticket with the
long-term key that it shares with the service youre trying to access. The KDC packages up both
the encrypted service session key and the service session ticket, and sends them back to your
client workstation using a Kerberos Ticket-Granting Service Reply (KRB_TGS_REP) message.
When your client workstation receives the KRB_TGS_REP message, it places the service
session ticket directly into the credentials cache. The Kerberos client then uses the cached copy
of your logon session key to decrypt the service session key that was also returned. The service
session key is also inserted into the credentials cache of your workstation. Now you can actually
access the network resource.
Client/Server Exchange
Now that youre all set to access that network resource, the Kerberos client on your workstation
sends a Kerberos Application Request (KRB_AP_REQ) message to the computer that hosts the
network service that you want to access. (This is shown in Figure 4.8.) This request contains the
session ticket for the service, an authenticator encrypted with the service session key, and a
simple flag that indicates whether the client wants mutual authentication to be performed. Lets
assume that were requesting mutual authentication.

Figure 4.8: Sending messages using C/S Exchange.

When the remote computer receives the KRB_AP_REQ message, it uses its long-term secret key
to decrypt the service session ticket. From the service session key, the remote computer extracts
both your authorization information and the service session key. It uses the service session key to
decrypt your supplied authenticator. If the authenticator is within the allowed tolerance, the
remote computer considers you authenticated.

111

Chapter 4
Because we assumed that the mutual authentication flag was set within the request, the remote
computer uses the session key to encrypt the time it received within your authenticator to provide
an authenticator of its own. The remote computer returns the remote server authenticator to your
workstation using a Kerberos Application Reply (KRB_AP_REP) message.
When your client workstation receives the KRB_AP_REP message, it uses the cached service
session key to decrypt the authenticator from the remote computer. If the time stamp in the
returned authenticator exactly matches the time stamp in the original authenticator, the client
considers the remote service to be authenticated. During the rest of the connection, the service
session key can be used to encrypt the application data passed between the client and the server.
Of course, the client and server can share another key for this purpose.
Inter-Domain Authentication
Everything Ive talked about so far has concerned authentication in a domain. Now Ill discuss
how inter-domain authentication functions in a Win2K forest. Its a simple referral process.
As for intra-domain access to a network resource, you need a ticket to access any network
resource. The same holds true for network services that reside in another domain. When you
want to access a network service in another domain, the process starts with the same TGS
Exchange protocol that I discussed above. (See Ticket-Granting Service Exchange.) When the
KDC sees that youre trying to access a resource in another domain, it begins a referral process
that ends with you talking to the TGS in the network resources account domain.
In a Forest with Two Domains
The best way to describe how this works is to walk through a simple example in which a Win2K
forest has only two domains. When these two domains were created, the TGS of each domain
was registered as a security principal in the other domains KDC. This allows the TGS in each
domain to treat the TGS of the other domain as just a generic service. As a result, you can
request session tickets for the other domains TGS just as if you were trying to access any other
network resource in your domain.
When you want to access a network service in the other domain, your workstation starts by
sending a TGS Exchange request to the TGS in your account domain, specifying the network
resource in the other domain. When the TGS receives your request, it sees that the resource that
youre trying to access isnt a service in its domain. As a result, it sends you what is known as a
referral ticket. This referral ticket is just another TGT that is encrypted with an inter-domain key,
which your KDC shares with the KDC in the other domain.
Now you have two TGTs, one for your own domain and one for the other domain. Your
workstation uses the referral ticket to send a new TGS Exchange request directly to the TGS in
the other domain. Once the TGS in the other domain receives your request, it uses its copy of the
inter-domain key that it shares with your KDC to validate the TGT that you presented. If
everything verifies, the TGS sends back a regular session ticket, which gives you access to the
requested service in the other domain.

112

Chapter 4
In a Forest with More Than Two Domains
The referral process works pretty much the same in a Win2K forest with more than two domains;
it just takes more referrals! Ill clarify how the process works using an example. While this
example uses three domains, you can extrapolate it to n domains in the same fashion.
Lets say that three domainsDomain A, Domain B, and Domain C are all in a single tree,
and domains B and C are children of Domain A. (This is shown below in Figure 4.9.) Youre in
Domain B, and you want to access a network resource in Domain C.

Figure 4.9: Using Kerberos referrals for inter-domain authentication.

The referral path starts with the KDC in your Domain B, traverses a trust to Domain A, and ends
at the KDC in Domain C. To handle all of these referrals, your client workstation must send
three TGS Exchange requests to three different KDCs, as follows:
1. Your client sends a TGS Exchange request to the KDC in Domain B. When the KDC

receives your request, it sees that its for another domain and looks for the appropriate
domain to forward it to. There is only one place to send itDomain A. So your client
receives a TGT for Domain A that is encrypted with the inter-domain key that is shared
between domains A and B.
2. Your client sends a second TGS Exchange request to the KDC in Domain A. When the

KDC receives your request, it sees that its for another domain and looks for the
appropriate domain to forward it to. There is only one place to send itDomain C. So
your client receives a TGT for Domain C that is encrypted with the inter-domain key that
is shared between domains A and C.
3. Your client now sends a third TGS Exchange request to the KDC in Domain C. When the

KDC receives your request, it sees that its for a network resource in its domain. It
responds with a session ticket for the network resource, which your client can then use to
give you access to the resource you want.

113

Chapter 4

Everything You Wanted to Know about Tickets

In the last few sections, Ive discussed the notion of tickets, both TGTs and session tickets. As
youll recall, these ticket types are essentially the same; there are just some differences in the
data they hold. Table 4.2 below looks at what is in a ticket. One of the first things youll notice is
that only part of the ticket is actually encrypted. So far, Ive talked about how tickets get
encrypted with long-term secrets, but the reality is a little different because Kerberos clients must
be able to tell the difference between one ticket and another!
This Field

Is Encrypted

And Stores This

tkt-vno

No

The version number of the ticket format. Win2K implements

Kerberos V5, so this value is always set to 5.

Realm

No

The name of the Win2K domain that issued the ticket.

Sname

No

The name of the service that this ticket is issued for.

Flags

Yes

All of the different options for the ticket.

Key

Yes

The session key.

Crealm

Yes

The name of the client (your Win2K domain).

Cname

Yes

The name of the client (your name).

Transited

Yes

In inter-domain authentication, the name of all of the domains that

were traversed to get from you to the service.

Authtime

Yes

A time stamp of your initial authentication. The KDC fills this value
when it issues a TGT. However, when the KDC issues a session
ticket, it copies the time stamp from your TGT and places a copy of it
in the session ticket.

Starttime

Yes

A time stamp that indicates when the ticket becomes valid.

Endtime

Yes

A time stamp that indicates when the ticket expires.

renew-till

Yes

A time stamp that indicates the maximum expiration time for a ticket
that has its RENEWABLE flag set. An optional value.

Caddr

Yes

The client addresses that are authorized to use this ticket. If the
value isnt present, the ticket isnt restricted and can be used from
any network address. An optional value.

Authorizationdata

Yes

Your account authorization values. For Win2K, this is a collection of

security identifiers (SIDs) that represents your group memberships.
Ill discuss this field in more detail in Chapter 5 when I discuss
authorization. An optional value.

Table 4.2: Overview of Kerberos ticket fields.

The Flags field in this table is like most other Flags fields that youre familiar with and has only
a few fields that are worth talking about. These are shown below in Table 4.3. For those of you
who are interested in all of the flags, however, check out the kerbtray.exe Resource Kit tool. (I
also discuss it later in this chapter; see Kerberos Ticket Tool.)

114

Chapter 4

This Ticket Flag

Indicates This

FORWARDABLE

The TGS can issue another TGT with different network addresses based on the
original TGT. This flag is valid only for a TGT.

FORWARDED

One of two things: either the ticket has been forwarded, or it was issued from a
forwarded TGT.

PROXIABLE

The TGS can issue session tickets with a different network address than the one
contained in the original TGT.

PROXY

The network address contained in the ticket is different than the network
address.

RENEWABLE

The ticket can be renewed periodically. This flag is used in conjunction with the
Endtime and Renew-till fields in the ticket.

INITIAL

The ticket is a TGT.

Table 4.3: Overview of Kerberos ticket flags.

Calculating Their Lifespan

Taking a look at ticket fields and flags, you can see that renewing a ticket extends its lifespan.
Using renewable tickets allows the KDC to refresh session keys without having to go through all
of the hassle of generating an entirely new ticket. But tickets flagged as renewable cannot be
updated forever; theyre governed by the two expiration times that the KDC sets in the ticket.

EndtimeLimits the life of the current ticket

Renew-tillLimits the cumulative lifespan of all incarnations of the ticket.

The way in which Kerberos uses these ticket fields is pretty straightforward and much as youd
expect. First, the value in the Endtime field is the result of adding the value in the Starttime field
to the value for Maximum Lifetime for [User|Service] Ticket specified in the Group Policy
settings in effect for the domain. Any renewable ticket must be submitted to the KDC for
renewal before the value in the Endtime field; after that time has passed, the ticket cannot be
renewed, and a new one must be issued.
When a ticket is submitted for renewal, the KDC validates both the Endtime field and the
Renew-till field to ensure that neither value has passed. If the Renew-till time hasnt yet
occurred, the KDC renews the ticket by updating the session key and modifying the Endtime
field as appropriate.
Another thing you may have noticed when looking at the structure of a ticket is that it can get old
and expire. Not only that, it also has a Starttime field. This field controls when a client can
present the ticket and authenticate to a network service. If the current time is between the
Starttime and Endtime fields, an issued ticket can provide you with access to a service, no matter
how many times the ticket has been used.
The interesting thing is that a client can ask for a specific start time when it requests a ticket. If
the time isnt specified or if it occurs sometime in the past, the KDC defaults the value to the
current time. Start times arent something you need to worry about, but its interesting to note
that they can be used, even if its not often.

115

Chapter 4
The expiration time is a little more involved, so lets look at how to compute the end time of a
ticket. As I mentioned above, the Endtime value is determined by adding the ticket lifetime, as
specified in the appropriate Group Policy setting, to the Starttime value of the ticket. The result is
then compared to the requested expiration time of the ticket. As youd expect, the earlier time is
chosen and becomes the tickets Endtime value.
Now lets look at what happens when a ticket expires. The client finds out that a session ticket
has expired when it tries to use the ticket to access a network resource. The resource returns an
error, and the client has to go back to the KDC and request a new session ticket for the resource.
The ticket is validated only when a new connection is established with the network resource. If you
connect to a resource with a valid ticket, even if the ticket expires one second later, the connection
remains viable until its closed.

When a TGT is expired, the client again finds out when it tries to communicate with the KDC,
and an error is returned. Now the client must request a new TGT. If the client still has your longterm key cached, it can automatically receive your new TGT; otherwise, the client is forced to
once again ask you for your password so that it can derive your long-term key.
Delegating Authentication with Kerberos
Another interesting set of flags deals with the ability to delegate authentication with the Kerberos
protocol. For example, you as a client may want to access a server to gain access to some
resource, but instead of being able to fulfill your request itself, the service has to ask another
service to do so. Thus, the first server must have some sort of ticket to the second server. You
probably want the second server to know that it is you who is logically accessing the resource,
even though its the first server that is physically accessing the service. This scenario is shown
below in Figure 4.10.

Figure 4.10: Delegating authentication.

Thankfully, the Kerberos protocol has made provisions for just this kind of scenario, where you
delegate your authentication credentials to another entity so that it can carry out some action on
your behalf. For those of you who are familiar with impersonation, the concept of delegated
authentication is quite similar, but the mechanics are different.

116

Chapter 4
To delegate authentication, Kerberos can use one of two methods.

Proxy ticketsYou can obtain a ticket for the secondary server and give it to the
primary server. However, you need to know ahead of time the name of the resource on
the second server.
Proxy tickets are denoted by setting the PROXY flag in the ticket and are obtained by
requesting a ticket to the back-end resource with a special flag indicating that you want
this to be a proxy ticket. In addition to presenting your TGT and specifying the name of
the back-end resource, the client must also specify the name of the network resource that
will be representing you in the authentication.

Forwarded ticketsCreate a TGT for the first server, which can then request tickets on
your behalf as needed to access back-end resources. (In other words, the initial TGT is
forwarded.) This form of delegated authentication eliminates the need to know the name
of the back-end resource.
Forwarded tickets are slightly more involved because there are actually two flags that can
be set: the FORWARDABLE flag and the FORWARDED flag. The process of using
forwarded tickets begins when you want to delegate the ability for a front-end resource to
request tickets to back-end resources on your behalf. In this case, you need to request a
forwardable ticket from the KDC.
The ticket request must indicate that you want this to be a forwardable ticket and must
specify the name of the front-end resource. When the KDC receives your valid TGT, it
creates a new TGT for the front-end resource that is in your name and has the
FORWARDABLE flag set in the ticket. Your client then uses this TGT to access the
front-end resource.
Whenever the front-end resource needs access to any back-end resource to carry out one
of your requests, the front-end server can present your forwarded TGT to the KDC to
obtain appropriate session tickets. The KDC sees that the TGT is a forwardable ticket
because the FORWARDABLE flag is set, and it issues a session ticket with the
FORWARDED flag set.

Configuring Kerberos
In Chapter 3, I talked about the security configuration options that are available using Group
Policy. You may have noticed that there were only a few settings available for Kerberos. This is
a function of how well Kerberos is integrated into Win2K and how the protocol works. Overall,
Kerberos requires very little care and feeding, and Table 4.4 below recaps the configuration
options available in Group Policy.

117

Chapter 4

This Kerberos Setting

Establishes This

Enforce User Logon Restrictions

Whether the KDC makes explicit checks against the user rights
policy of the target computer each time a user requests a session
ticket.

Maximum Lifetime for Service

Ticket

The maximum amount of time that a session ticket can be used for
access to a service.

Maximum Lifetime for User Ticket

The maximum amount of time that a TGT is valid.

Maximum Lifetime for Ticket

Renewal

The maximum amount of time during which a TGT can be

renewed.

Maximum Tolerance for Computer

Clock Synchronization

The maximum clock skew allowed between a client and a server

to consider them synchronized.

Table 4.4: Configuration options for Kerberos in Group Policy.

While these Kerberos configuration options are available in Group Policy, theyre not really
available in Group Policy Objects (GPOs) that are linked to sites, Organizational Units (OUs), or
local GPOs. Theyre available only from GPOs that are associated with the domain. If you think
about this for a second, it makes sense. The function of the KDC is to provide authentication
services for the entire domain; therefore, the configuration options should apply only to the
entire domain.
In addition to these GPO-based configuration options, three configuration options associated
with individual user accounts also affect how Kerberos operates. These are described below and
shown in Figure 4.11.

Account Is Trusted for DelegationIt should never be required of an individual user

account, but there are instances when a service account needs to perform actions on
behalf of other users. In these cases, you can enable this capability by selecting this check
box.

Account Is Sensitive and Cannot Be DelegatedWhile Kerberos permits delegated

authentication, you can disable this capability for individual users by selecting this check
box. The default behavior for a Win2K KDC is to require that all accounts use preauthentication data.

Do Not Require Kerberos PreauthenticationNot all versions of Kerberos support

pre-authentication data, so for interoperability with other implementations of the
Kerberos protocol, you may need to select this check box. However, just about all of the
newer Kerberos implementations support pre-authentication data.

118

Chapter 4

Figure 4.11: Account configuration options that affect Kerberos.

Using NTLM: Down-Level Compatibility

As Ive shown, Kerberos is the default network authentication protocol for Win2K. But that
doesnt mean that NTLM is dead. In fact, NTLM has been retained in Win2K to provide some
very necessary functionality. This is because NTLM:

Allows users to log on to stand-alone Win2K computersYou cannot use Kerberos

because its a network authentication protocol and not well suited for local logons

Allows backward compatibility between Win2K and older versions of Windows

This feature allows native Windows 3.11, 9x, and NT 4.0 computers to authenticate to
Win2K domains. It also enables Win2K computers to access resources in your legacy NT
4.0 domains.

119

Chapter 4

Configuring LAN Manager Authentication

One Group Policy setting that is available in Win2K is the LAN Manager Authentication Level
policy. (I touched on it briefly in Chapter 3.) This policy can be found in the Windows
Settings|Security Settings|Local Policies|Security Options section under Computer Settings in a
GPO. This policy determines which of the LM challenge/response protocols is used for network
logons when Kerberos authentication isnt available. This setting affects which version(s) of the
LM protocols is used by clients, the protocol version negotiated, and the protocol accepted by
servers. This is outlined in Table 4.5 below.
This LM Authentication Setting

Allows the Client To Use This Type of Authentication

Send LM & NTLM responses

LM and NTLM, but never NTLM v2. However, domain controllers

accept LM, NTLM, and NTLM v2. This is the default setting for
Win2K servers.

Send LM & NTLM - use NTLMv2

session security if negotiated

LM and NTLM, also NTLM v2 if the server supports it. Domain

controllers accept LM, NTLM, and NTLM v2.

Send NTLM response only

NTLM only, also NTLM v2 if the server supports it. Domain

controllers accept LM, NTLM, and NTLM v2.

Send NTLMv2 response only

NTLM v2 only, also NTLMv2 if the server supports it. Domain

controllers accept LM, NTLM, and NTLM v2.

Send NTLMv2 response

only\refuse LM

NTLM v2 only, also NTLMv2 if the server supports it. Domain

controllers accept only NTLM and NTLM v2 and refuse LM.

Send NTLMv2 response

only\refuse LM & NTLM

NTLM v2 only, also NTLM v2 if the server supports it. Domain

controllers accept only NTLM v2 and refuse LM and NTLM.

Table 4.5: LM authentication policy settings.

As is typically the case for Microsoft default settings, the default setting of this policy is slanted
heavily toward backward compatibility and not toward better security. As you move down the
list in the table above, you increase the strength of authentications that cannot use Kerberos.
Obviously, you want to achieve the most secure LM-based authentications possible in your
environment, so you want to strive for that final setting.
Be careful how you set this Group Policy setting. If you have something other than Win2K in your
environment, this setting can adversely affect how your Win2K computers authenticate with downlevel clients. Windows NT 4.0 computers earlier than SP4 dont support NTLM v2, and Windows 9x
and Windows Me computers dont even support NTLM!

One of the interesting things about LM policy is that there is no setting to turn off LM
authentication altogether! Considering the bad security history of LM-based protocols, you might
very well want to completely turn off LM authentication once youve upgraded your entire
environment to Win2K. Unfortunately, it isnt an option. However, if you successfully upgrade
your entire environment to Win2K, its worth investing a little time to use an intrusion detection
system to identify how LM-based authentication is used on your network.

120

Chapter 4

Using Secondary Authentication

System administrators have been told forever to use two accounts: an unprivileged account for
reading mail and performing standard non-administrative functions and a privileged account for
performing their administrative duties. This has long been touted as good security practice, but
its been somewhat of a pain. To use two accounts, administrators are forced to either log in and
out of their two accounts all day or set themselves up with two computers. Unfortunately, the
demands placed on system administrators to always react quickly to administrative needs has led
many, if not most, of you to forgo two accounts and use just one to perform all of your job
functionsthe privileged account!
For many of you who are familiar with UNIX, the su command probably sounds like the way out
of this sort of situation. Up to now, however, such a command hasnt been available in the
Windows family of products. Thankfully, Win2K finally provides a service known as the
Secondary Logon Service (SLS). It allows administrators to use a normal non-privileged account
to log on as well as a privileged account for running administrative tasks when necessary without
the need for a second computer or the need to log off and log back on.
You access the SLS using the Runas (runas.exe) command. While it might make sense to talk
about this command when discussing authentication tools later in this chapter, Runas is such an
exciting and long-overdue component that it deserves a section all to itself.
While Ive said that the Runas command allows non-privileged users to run a command as
privileged users, it really is a much more generic tool than that. It allows users to run other tools
and programs with a different set of permissions than their current logon provides. Put more
simply, it allows you to run another tool or program as any another user.
Starting the Runas Command
Win2K gives you two ways to start the Runas command: in Windows Explorer and on the
command line. Lets take a quick look at these methods.
In Windows Explorer
To start the Runas command in Windows Explorer, hold down the Shift key and right-click the
icon for an administrative tool or application. The Run As command appears on the shortcut
menu, as shown in Figure 4.12. When you choose the Run As command, a dialog box appears,
where you can type the authentication information for the user for whom you want to run the tool
or application.

121

Chapter 4

Figure 4.12: Choosing the Run As command from the shortcut menu.

From the Command Line

You can also start the Runas command from the command line. To do so, execute this command:
runas

A number of options are available; theyre shown in Figure 4.13 and described in the next
section.

Figure 4.13: Starting the Runas command from the command line.

122

Chapter 4
In this figure, note the title bar of the console window. Youd expect to see the title
C:\WINNT\System32\cmd.exe, but its actually cmd (running as merion\administrator). Thats
because when you start cmd.exe from Runas, you get a visual cue that youre running under
another security context. Unfortunately, this visual cue occurs only when you execute cmd.exe
with Runas and not any of the other commands available in Win2K.
Command-Line Syntax
To effectively use Runas on the command line, you need to understand its syntax. Here is a
quick look at the commands syntax and options.
runas[/profile][/env][/netonly]/user:UserAccountName program

/profileLoad the new users profile

/envUse the current network environment, not the new users local environment

/netonlyUse the user for remote access only, not for local access to resources

/user:UserAccountNameSpecifies the user account under which to run the program,

using the format user@domain or domain\user/

programThe only required argument; it specifies the program or command to run.

There is no provision for entering the password for the new user on the command line. No matter how
you start Runas, whether from Windows Explorer or from the command line, youre prompted for the
password of the new user.

Taking Advantage of Runas

The Runas command is a powerful tool. To take complete advantage of it, you need to better
understand how to use it. Here are a number of ways in which you can take maximum advantage
of the Runas command:

Although its commonly used to run commands as an administrator, you can use it to run
a program in the context of any other user

To run a command using the credentials of a local user, type:

/user:localuser@computername

or
/user:computername\localuser

To run a command using domain credentials, type:

/user:domainuser@domainname

or
/user:domainname\domainuser

It lets you run any executable program (*.exe), saved Microsoft Management Console
(MMC) snap-ins (*.msc), shortcuts to programs and saved MMC snap-ins, and Control
Panel (*.cpl) items

123

Chapter 4

You still need to use the appropriate user account name and password information; it
doesnt give you a magical ability to circumvent user authentication

You can use it to administer resources in other domains and even forests (if youre away
from your normal computer, this is a pretty cool feature)!

Because you cant open things like Windows Explorer, the Printers folder, Desktop
items, and so on directly in Win2K, you cant use Runas to start them

If Runas fails and you know you entered the user name and password correctly, check
that the RunAs Service is actually running and that the account isnt locked out.

I suggest that you spend a bit of time using the Runas command to understand how to put it to
best use in your environment. Now that its available, no system administrators in your
environment should ever again read their mail and compose simple documents while running as
a member of the Domain Administrators group!

Using Smart Card Authentication

Another of the features built into Win2K is its embedded support for smart cards. While weve
all heard of smart cards and some of us may even have used one, what is it about smart cards that
have security professionals all excited? Well, smart card technology is attractive from a security
perspective because it provides three characteristics that, together, offer an attractive security
solution. These three characteristics are:

Tamper-resistant storageSmart cards protect users private keys and other forms of
personal information, including passwords

Isolation of security-sensitive computations from other parts of the system that have no
need to knowThese computations include authentication, digital signatures, and key
exchange operations

Portability of authentication credentials and other private information among multiple

systemsUses a small and convenient form factor familiar to most people.

Microsoft based the integration of smart card technology on the Personal Computer/Smart Card
(PC/SC) 1.0 specification. This specification was designed to eliminate the interoperability
problems with the myriad of standards that were available when the specification was created.
The specification provides a standard model for interfacing smart card readers and cards with
computers and with device-independent application programming interfaces (APIs) to enable
smart cardaware applications. The specification also allows complete integration with the OS.

124

Chapter 4

Logging On Using a Smart Card

As I talked about at length in Using Kerberos V5: The New Authentication Scheme earlier in
the chapter, standard Kerberos logons use a secret key that is shared between the user and the
KDC. This shared secret is derived from your password, which is converted to a cryptographic
key and used only during the initial AS Exchange when you log on to the domain.
When you use a smart card to log on to Win2K, though, things happen a little differently. To
support smart card logons, Win2K had to implement a standard public key extension to the
Kerberos protocols AS Exchange. When you log on to the domain, a private/publickey pair
that is stored in your smart card is substituted for the shared secret key that is normally derived
from your password. The public key extension to the AS Exchange is modified so that the KDC
encrypts your TGT with the public key portion of your key pair. The KDC retrieves your public
key from your user object in AD.
To give you a better idea of how smart card logon functions, Ill describe a typical scenario. (The
process is also shown in Figure 4.14.) The logon process starts when you insert your smart card
into a configured smart card reader connected to your workstation. If the smart card reader is
properly installed, inserting the smart card triggers the Secure Attention Sequence. (This is akin
to pressing CTRL+ALT+DEL.) Just like with a regular logon, Win2K launches the MSGINA
(see Chapter 2 for a description of the MSGINA), which displays the Authentication dialog box
that requests just a single piece of informationthe PIN that unlocks the smart card.

Figure 4.14: Logging on in Win2K using a smart card.

The MSGINA collects your PIN and passes it to the LSA, just like it would if youd entered a
user name and password. The LSA uses the PIN to unlock your smart card. The LSA then has
access to the operations of the smart card, where your private key and public key certificate are
stored.
All operations that require the private key material occur in the smart card itself.

125

Chapter 4
The Kerberos client on the computer sends a KRB_AS_REQ message to the KDC. But instead
of using an encrypted time stamp as pre-authentication data, the client sends your public key
certificate. When the KDC receives the request, it first validates the certificate to ensure that it
trusts it and that its still valid. If the KDC successfully validates the certificate, it extracts the
public key and uses it to encrypt your logon session key. When your client receives the
KRB_AS_REP message from the KDC, it submits the encrypted logon session key to the smart
card for decryption with your private key. Once you have the unencrypted logon session key,
youve successfully logged on.
Before You Deploy Smart Cards
Using smart cards seems simple, but there are some issues that you need to be aware of before
embarking on a full-scale deployment of smart cards in your environment.

Smart cards can be used only for initial authentications. This means that you cannot use
them for secondary authentications, such as to start the Runas command (discussed in
Starting the Runas Command earlier in this chapter) or use the Authentication dialog
box to add a computer to the domain.

While the price has come down significantly in the past few years, smart cards havent
yet reached commodity status. However, it looks as if built-in smart card readers will
become a standard option on many major brand-name computers in the near future,
maybe even by the time you read this.

A full smart card implementation can be quite complex. As with all rollouts, I urge you to
test, test, and test again. Make sure you understand how to use smart cards not only for
authentication but also for all of the administration endeavors that ensure that a rollout is
successful.

Test your potential solutions using the maximum number of keys that you think your
users will need to do their jobs. If you generate a couple of large 2048-bit keys, you can
quickly fill up a small 8-kilobyte (K) smart card once the keys and associated certificates
are installed in it. Make sure that any smart cards you deploy have enough space to hold
all of the user credentials you foresee over their expected lifetime.

Using Other Authentication Schemes

Other authentication schemes that Ill touch on very briefly are biometric authentication and IIS.
Biometric Authentication
When I was discussing all of the authentication protocols available in Win2K earlier in this
chapter (see Authenticating in Windows 2000), you may have noticed that I didnt list
biometric authentication in Table 4.1. This is because biometric authentication isnt really
supported natively by Win2K. This fact notwithstanding, biometric authentication may be
something that youre extremely interested in, so I thought it important to at least mention it.

126

Chapter 4
However, mention it is all Im going to do because Im not a very big believer in biometric
authentication on the desktop. While I think its very beneficial for things like physical access to
a data center environment, its not something that in my opinion is ready for the desktop. I know
that biometric vendors have sprung up everywhere in the last couple of years, and many of you
may swear by them, but Im not ready to embrace the technology just yet. Until the technology is
easier to use, easier to manage, and cheaper to deploy, all the while being implemented in a
secure fashion, I cannot advocate the widespread using of biometric devices.
Internet Information Services
Back in Table 4.1, I introduced the main authentication protocols that are available in Win2K.
Up to now, Ive spent a lot of time talking about Kerberos and, to a lesser extent, NTLM, smart
cards, and secondary authentication. In this section, Im going to spend absolutely no time
discussing the other three authentication mechanisms listed in that table: basic authentication,
digest authentication, and SSL authentication. While these authentication methods are important,
theyre all relatively specific to IIS. As a result, Im going to defer discussing them until Chapter
10, where Ill explore IIS from a security perspective.

Authentication Tools and Troubleshooting

Unlike other aspects of security configuration, when it comes to tuning the performance of either
Kerberos or NTLM, there just arent a lot of options. Kerberos is fully integrated into the Win2K
domain model and doesnt require much maintenance or troubleshooting. That said, however,
there are three Win2K authentication tools that you need to become familiar with:

Kerberos Ticket Tool (kerbtray.exe)

Network Domain Manager (NDM, or netdom.exe)

Domain Monitor (dommon.exe).

Kerberos Ticket Tool

Although you wont ever really use Kerberos directly, its sometimes useful to keep an eye on all
of the tickets that youve been granted. Arent you curious to see what TGTs and session tickets
you have? I know I am! Thankfully, the Win2K Resource Kit provides the Kerberos Ticket Tool
(kerbtray.exe), which lets you do exactly this.
Kerbtray creates an icon in the status area of the taskbar that you can use to check Kerberos
tickets. If you hover your mouse over the Kerbtray icon, youll see the time left until your TGT
expires. Clicking the icon displays the Kerberos Tickets dialog box, where you can view all of
the tickets that youve obtained since you logged on (see Figure 4.15). While you can use this
dialog box to purge all of your acquired tickets, youll probably have to log on again to obtain
access to resources on the network. This tool is mostly just fun to play with to get a better feel
for how Kerberos works in the Win2K environment.

127

Chapter 4

Figure 4.15: Using the Kerberos Ticket Tool.

Network Domain Manager

While Win2K has plenty of MMC snap-ins where you can work, but every once in a while, its
nice to use a simple command-line utility to get something done. The Network Domain Manager
(NDM, or netdom.exe) is just such a tool. (Its shown below in Figure 4.16.) NDM lets you
manage the Win2K domains and domain trust relationships in your environment. Overall, the
tool is pretty darn handy and lets you do a number of things, for example:

Join a computer to a domain

Manage computer accounts

Establish trust relationships among domains

Verify and reset secure-channel relationships

Manage the trust relationships among your domains.

128

Chapter 4

Figure 4.16: Using the Network Domain Manager.

For those of you whod rather use a graphical user interface (GUI) to carry out these tasks, the
Active Directory Users and Computers and Active Directory Domains and Trusts MMC snap-ins
are probably the tools youll use.
Domain Monitor
You GUI fans will like Domain Monitor (dommon.exe). To a certain extent, its a GUI
implementation of the command-line Network Domain Monitor, minus some functionality. The
Domain Monitor keeps track of the domain controllers and their secure-channel status for
domains in your environment. It displays the domains that youve selected along with trust
relationships and other status assessments of your domains and trusts (see Figure 4.17).

Figure 4.17: The Domain Monitor tool.

129

Chapter 4

Common Kerberos Errors

Like most every other service that is well integrated into the Win2K OS, Kerberos logs all of its
errors to the Event Log. To be proactive, you need to take a look at your logs periodically and
look for some of the particular error messages that Kerberos might have logged. Table 4.6 below
lists some of the more common Kerberos error messages that you may find in your Event Log.
This Code

And Description

Occur When

0x06

Clients name not found

(principal unknown)

0x07

Servers name not

found (principal
unknown)

The domain controller cannot find the specified name in AD.

The account for the principal may have expired. Or the
account exists in AD but hasnt been replicated to the domain
controller where the check is being performed. If the principal
was just added to the domain, it probably has just not
replicated yet; however, if the principal was added a while
back, there may be domain controllerreplication problems in
your environment.

0x17

Password has expired.

Change password to
reset

A users password has expired and has been changed, but it

still has a valid TGT cached. Logging off, then logging on
again will clear up this problem.

0x1A

Requested server and

ticket do not match

A server receives a ticket that was issued to another server.

This error typically indicates that there are problems in your
name-resolution environment. If you see this error, take a
good look at DNS and make sure that all of the right
addresses for servers are being passed out.

0x1F

Integrity check on
decrypted field failed

0x29

Message stream
modified

There is an integrity issue with a decrypted ticket field or data

stream. While the problem may be a result of simple network
noise, this error could indicate that something bad is going
on in your network and that network traffic is being maliciously
altered. If you see a lot of these codes and your network is in
good shape, keep your eyes out for other signs that hackers
have infiltrated your network.

0x20

Ticket has expired

A ticket has expired. Because it should renew automatically,

there isnt really anything to do besides notice that these
messages are in your logs.

0x22

Session request is a
replay

A specific authenticator is being used more than once to

access a network resource. You could have something as
simple as a bad network card in your environment, or you
could have those nefarious hackers in your network. Either
way, keep an eye out for this error message.

0x25

Clock skew too great

An authenticator has a time stamp that is different than the

servers clock setting by more than the configured allowable
clock skew. If you see a number of these errors in your
environment, consider increasing the value a little and/or
making sure that the times on all of the computer clocks in
your environment are properly synchronized.

Table 4.6: Typical Kerberos error codes.

130

Chapter 4

Authentication Best Practices

Microsoft doesnt give you a lot of options for configuring the authentication protocols for a
Win2K environment. Combine this lack of options with the AD best practices I discussed in
Chapter 2, and your authentication infrastructure just kind of flows out of your AD design. Here
are a few authentication best practices to keep in mind.

Use a homogeneous Win2K environmentThe best thing you can do for your
authentication environment is get rid of all legacy clients and standardize on Kerberos. If
you need legacy clients, do everything you can to set the LM authentication setting to
Send NTLMv2 Response Only\Refuse LM & NTLM.

Use the Runas commandThe secondary authentication capabilities of Win2K are a

great thing from a security perspective.

Use multiple accountsNow that you can use the Runas command, there is no excuse
not to use two accounts for each of your administrators: one non-privileged and one
privileged.

Use the Kerberos defaultsThe Kerberos defaults are geared to a pretty typical office
environment, one in which you work five days a week and eight hours a day. If this is the
environment you have, the default Kerberos settings are probably just fine for you.

Smart cardsThe support for smart cards in Win2K isnt perfect, but its available and
may be worth a look. Even if youre not quite ready to roll out smart cards, I advise you
to at least run a small pilot so that you can acquaint yourself with deploying them, using
them, maintaining themand the toughest issue of them allwhat to do when a user
comes to work one day without it!

Summary
Remember that authentication provides the ability to positively prove that a security principal is
who or what it claims to be and that the security of your environment is only as strong as the
authentication of your security principals. Thankfully, Win2K has adopted the Kerberos protocol
as its default protocol for network authentication.
Because Kerberos is new to many of you, Ive spent a great deal of time discussing it and the
mechanisms that make it work. Hopefully this chapter has taken a lot of the mystery out of the
Kerberos protocol for you. If it has, Ive accomplished what I set out to do.

131

Chapter 5

Chapter 5: Configuring Access Control

As I discussed in Chapter 1, access control provides the logical, or physical, controls that prevent
unauthorized access to information resources. I want to emphasize unauthorized because access
control has no real function without the concept of authorization. Remember from Chapter 1 that
authorization gives a security principal the capability or privilege to perform an action or access
an information resource. Thus, Win2K uses authorizations to make access control decisions. The
word unauthorized also implies that if you havent explicitly been granted access to some
resource, youll be denied access.
But is that all there is to the concept of access control? Not entirely. Obviously, a third piece in
this equation is missing: the concept of authentication. In addition to authorization, Win2K uses
authentication to make access control decisions. I discussed authentication in Chapter 4, and
although this chapter is about access control, Ill spend a bit of time discussing authorization in
Windows 2000 (Win2K). Ill discuss authorization and access control together to create a
complete description of how these two concepts collectively work within Win2K.

The Windows 2000 Access Control Model

Before delving in, I want to point out that Win2Ks access control model isnt a whole lot
different than the model implemented in Windows NT 4.0. As a result, you might already have a
basic comprehension of how to do things such as assign user privileges and set permissions. But
do you really know what the difference is between a privilege and permission, how the operating
system (OS) uses them, or even why theyre necessary?
If you answered no to any of these questions, read on; by the time youve finished this chapter,
you should know the answer to these and many other questions. In addition, youll have a
thorough understanding of how Win2K uses both authorization and access control. Even if you
answered yes to all three questions, I encourage you to read on because Ill provide the answers
to many more questions about the Win2K access control model.
The Five Principles of Access Control
To understand how Win2K performs access control, youll benefit from looking at the five
overriding principles that Microsoft used to design the access control mechanisms in Win2K.
Combined, these principles provide an overview of the basic characteristics of Win2Ks access
control model. Figure 5.1 illustrates the following principles:

User-based authorizations

Discretionary access control

Inheritance of permissions

Administrative privileges

Auditing of system events.

132

Chapter 5

Figure 5.1: The access control model of Win2K.

In this chapter, Ill delve well past these principles into many of the constructs that implement
this access control model. No matter how complicated some of the details may seem the basic
model of access control is predicated on these five simple concepts, which you can always go
back to.
User-Based Authorizations
The access control model in Win2K begins with user-based authorizations. Thus, applications
that run on your behalf run with the same set of permissions, authorizations, and privileges that
youve been granted. As a result, these applications can do only what youre allowed to do.
Think for a second about what happens when you run an application such as the Windows
Explorer shell. You can access only those files on the system that youre authorized to access,
and other users can access only the files on the system that theyre authorized to access. Access
to an application is controlled by the permissions of the user who is running the application, not
the application itself. This setup is advantageous because we know that the OS is in control of
enforcing authorizations rather than each and every application developer out there!
Discretionary Access Control
The next aspect of the Win2K access control model is the use of discretionary access control
(DAC). DAC lets users control the permissions on objects that they own. This concept should be
pretty familiar to anyone who has ever changed the permissions on a file that he or she wanted to
share with someone else. With DAC, you control who has access to the folders, files, and other
objects that you own.

133

Chapter 5
Inheritance of Permissions
Maybe the most powerful of Win2Ks access control model principles is inheritance of
permissions. When you create a new object, you can control the permissions on it by allowing
inheritable permissions on the container object. While the previous sentence sounds a little
vague, think about what naturally happens when you create a new file in your My Documents
folder: The new file takes on the permissions of the folder, and anyone who can access your My
Documents folder can also access the new file. This access is possible because by default new
objects inherit the permissions of their parents. (Ill talk more about how inheritances are
propagated; see ACE Inheritance.)
Administrative Privileges
Another aspect of the Win2K access control model is the concept of administrative privileges.
Win2K allows control over which users and/or groups have the right to perform a number of
administrative functions or take actions that affect all of a systems resources. Using
administrative privileges, you can give one group of users the ability to back up a system and
give another group the ability to restore folders and files. If you think this process sounds a lot
like user rights assignment, youre correct; Win2K implements administrative privileges as user
rights. (Ill cover this aspect of access control in User Rights Assignments later in this
chapter.)
Auditing of System Events
Auditing of system events is the final aspect of Win2Ks access control model. It allows you to
monitor for attempts to circumvent authorizations on resources in your environment and perform
actions such as create an audit trail of actions taken by administrators. Microsoft considers the
auditing of system events part of the access control model, and I agree. However, its really a
topic unto itself. So although Ill touch on auditing in this chapter when necessary, Ill save the
bulk of the discussion until Chapter 6, which Ill devote entirely to auditing.

How Access Control Works

The access control model describes the core principles behind Win2Ks access control; however,
more important than understanding this model is understanding what access control really does.
Quite simply, access control strives to answer the fairly simple question: Can [security
principal] perform [specified action] on [specified object]? The question doesnt seem so simple
in those terms, so let me change the question to read as Figure 5.2 shows: Can Bob open the
file? The grammar of the two questions is the same, but the second one provides a more
understandable context.

134

Chapter 5

Figure 5.2: The simple goal of access control.

While access control is geared to answer a question as simple as, Can Bob open the file? the
realities are a lot more complicated. First and foremost, you and I know that Bob cannot actually
open a file; some process running on his behalf has to do it. If you recall from the discussion in
Chapter 2, a process is a collection of threads of execution. So the reality is that a specific thread
is actually going to open the file for the process that is running on Bobs behalf.
Win2K uses access tokens to know that a specific thread is running on behalf of a user. When
you log on to a system, Win2K authenticates you and automatically creates a unique access
token that is associated with you and your logon session. Each thread that a process launches on
your behalf during your logon session receives a copy of this access token. As a result, Win2K
can always look at the access token of a thread and know which security principal its running on
behalf of. Because each thread has one, and only one, associated access token, Win2K can use
the thread as the security principal for access control decisions.
Now that the subject of our basic question is defined, lets define the other portions of the
question. Just as there is a level of indirection between Bob and his access token, so too is there a
level of indirection between Bob and the action. When Bob takes an action such as using a
process to open a file, program instructions are executed that interact with Win2K to actually
open the file. These program instructions use one of the standard application programming
interfaces (APIs) provided by Win2K that were created just for this type of action.
As a result of calling a system API to open a file, the action Bob wants to perform (open) and the
object he wants to perform the action on (a file) are both defined. If youre not all that familiar
with application programming, this description of events may seem a bit odd. But remember that
neither you nor Bob can physically reach into a computer and open a file on the hard drive; the
action all happens on your behalf inside the code of the computer.
At this point, a thread running on Bobs behalf has made a system call to open a specified file.
Now its time for the access control decision to be made. As I discussed in Chapter 2, this
decision is made by the Security Reference Monitor (SRM), which is responsible for validating
access rights throughout Win2K.
To perform the access control check to determine whether Bob can open the file, the SRM
compares information stored in the threads access token (remember, its a copy of Bobs access
token) with the information stored in the files security descriptor. This process is shown in
Figure 5.3. In the access token are Bobs security identifier (SID) and a SID for every group that
he is a member of. In the files security descriptor is an access control list (ACL) that specifies
who is explicitly allowed or denied access to the file on a user and/or group basis.

135

Chapter 5
The SRM walks through the ACL of the file object looking for any access control entries (ACEs)
that apply directly to Bob or to any groups that Bob is a member of. If the SRM finds an ACE
that explicitly denies access to the file, the SRM denies the thread access to the file. If the SRM
finds an ACE that explicitly grants access to the file, it grants the thread access to the file. If it
finds no explicit ACE that matches Bobs SID or any of the group SIDs for groups that Bob is a
member of, the SRM denies the thread access to the file.

Figure 5.3: The process of comparing access control.

This quick overview of access control gives you a good look at how things are done in Win2K,
but it probably generates more questions than it answers, such as: What is really in an access
token? What are user rights and privileges? What is a security descriptor? and Is there more than
one kind of ACL? You probably have other questions as well.
To answer these questions, Ill walk through all the components that make up the access control
implementation of Win2K. After Im done, the example of how Bob opens a file should make
complete sense to you.

136

Chapter 5

SIDs
Just as in NT 4.0, Win2K uses a construct known as a SID to uniquely identify all security
principals and security groups. SIDs are very important in this respect because theyre Win2Ks
internal representation of security principals and security groups. So although you think of a
domain user account as being identifiable by the human-readable string somedomain\someuser,
Win2K thinks of a domain user account as a simple SID. Because Win2K cares quite a bit about
the SIDs that it uses, you should know three important things about SIDs: theyre generated by
the system, not by you or me; theyre unique; and theyre never reused.
Whenever a new account or security group is created, Win2K generates a unique SID to
associate with the new object. In cases in which the new account or security group is local to a
particular computer, the Local Security Authority (LSA) on the local computer actually
generates the SID. The LSA then stores the SID with the newly created object in the Security
Accounts Manager (SAM) database in a secure portion of the systems Registry. In cases in
which the domain account or security group is new, the LSA on the targeted domain controller
actually generates the SID and stores it in an attribute of the new object in Active Directory
(AD).
When the LSA creates a SID, its guaranteed to be unique within its own scope. So the SID for
each local account or group is unique to the computer on which the SID was created. As a result,
no two accounts, no two security groups, and no account and security group combination will
ever have the same SID on that computer. In the same way, the SID for each domain account or
security group is unique to the domain in which it was created. This uniqueness is carried
through your enterprise so that the SID for an account or security group created in one domain is
different than any of the SIDs in any other domains.
Not only are SIDs unique across your enterprise, theyre also kept unique for all time because the
LSA never issues the same SID twice and never recycles a SID. For example, lets say that you
have an account on a standalone Win2K computer somewhere in your enterprise. For whatever
reason, you no longer need access to this computer, so you delete your account. A couple of
months go by, and something else happens that requires you to regain access to this standalone
Win2K computer, so you create a new account. You then receive a new SID, guaranteed. Your
old account isnt reassigned to youor to anyone else, for that matter! As far as Win2K is
concerned, youre two different security principals, even if your logon name is still the same as it
used to be.
SIDs versus GUIDs
So far, Ive talked a lot about the uniqueness of a SID. If you recall from Chapter 3 what a
globally unique identifier (GUID) is, it might seem to be the same thing. In a sense it is the same
thing, all in the name of backward compatibility. Of course, the details behind this simple
explanation are a little more complicated.
As I just mentioned, when a domain account or security group is created, Win2K generates a SID
and stores it in an attribute of the new object. In addition to the SID, another type of attribute is
set for the objectits GUID.

137

Chapter 5
As youll recall, a GUID is a 128-bit identifier that is unique to a particular object and is
generated from a unique identifier on a device, the current date and time, and a sequence
number. The GUID lets any object be uniquely identified because once Win2K issues a GUID,
the GUID never changes, even when the object is renamed or moved. As a result, every object
stored in AD is assigned a GUID. So while other attributes can change throughout the lifetime of
an object, the GUID always stays the same.
However, the SID is one of those object attributes that can sometimes change. For example, lets
say that you work for a large international company that has Win2K domains for all of North
America and another Win2K domain for the Pacific Rim. After years of dedicated service and
hard work, you get your dream transfer from Smallville, USA, to Hong Kong. Instead of being
replaced by an all-new account, your account can simply be moved from the NorthAmerica
domain into the PacificRim domain. When your account moves into a new domain, it receives a
new SID. The rationale for the new SID will make sense when I talk about the structure of a SID
in the next section, but for now, just keep in mind that when you move domains, you get a new
SID.
After you have a new SID, you need a mechanism to access all the resources that you used to
access with your old SID. The mechanism is a SID-History attribute. When your account is
moved, Win2K makes a copy of your old SID and stores it in another attribute of your user
object before it generates your new SID. In fact, the SID-History attribute can hold multiple
values so that no matter how many times your account is moved among domains, your user
account object will contain all your old SIDs. Whenever you log on, your access token will hold
not only your current SID and the SIDs for all the groups youre a member of but also all your
old SIDs. When you access a resource, Win2K will use all of these SIDs to make the necessary
access control decision.
Be sure you understand the implications of the SID-History attribute and how it affects the way you
grant access to users in your environment. If you directly grant a user access to an object, rather than
grant access to a security group to which that user is a member, you may introduce some security
issues when you move a user from one Win2K domain to another in the same forest. For example,
when you move the user to the new domain, you may not want them to retain access to objects in
their original domain. If you routinely granted access to the user explicitly, youd have to search every
resource of the original domain for instances where the user is explicitly used in ACLs. This process
is probably not something youd ever want to do, so be safe and always use security groups for
access control, not individual user accounts.

To summarize, Ill relate all of this back to SIDs versus GUIDs. NT 4.0 and earlier use SIDs to
uniquely identify accounts and security groups, not GUIDs. So although SIDs seem to be a pain
because they can change over time, you shouldnt abandon using them just because GUIDs
appear to be (and are) superior. If you abandoned SIDs in Win2K in favor of GUIDs to make
access control decisions, youd be forced to modify all the ACLs on all the resources throughout
your entire enterprise! That process would be reason enough to not upgrade to Win2K. Thus,
although GUIDs would be preferable to SIDs when making access control decisions and would
eliminate the concept of SID-History, dont expect Microsoft to make that mistake anytime soon.

138

Chapter 5
Where Win2K Uses SIDs
Now that youre becoming familiar with SIDs and recognize that Ill be dealing with them for
quite some time, youre probably getting curious about all the places where SIDs are used.
Maybe surprisingly, Win2K uses SIDs in only three major access control structures.

Access tokensTwo types of SIDs are used in an access token: One SID identifies who
the token represents, and the other SID identifies the security groups that the user is a
member of.

Security DescriptorsTwo types of SIDs are used in a security descriptor: The first
SID identifies an objects owner, and the second SID identifies the owners primary
security group affiliation.

ACEsA SID is used in every ACE to identify the accounts or security groups for
which access is allowed, denied, or audited.

Ill discuss the details of each of these structures in later sections of this chapter; for now, its
enough to know where Win2K uses SIDs.
The Structure of a SID
As far as Win2K is concerned, a SID is a simple binary data structure that contains a variable
number of fields, as shown in Figure 5.4. The first field of the SID defines how large the
structure is, while the remaining fields contain the values that make up the SID.

Figure 5.4: The structure of a SID.

139

Chapter 5
Lets take a quick look at each of these fields.
Subauthority CountIndicates how many subauthority values are contained in the SID.
RevisionIndicates the version of the SID structure. Because the SID structure doesnt change
after its created, the value is always 1.
Identifier AuthorityIndicates the highest level of authority that can generate SIDs for the
type of security principal. You should see only the values 0 through 5, where the valid authorities
in ascending order are: null authority, world authority, local authority, creator authority, nonunique authority, and NT authority. For example, the SID for any account or security group in
Win2K has an identifier authority value of 5 (NT authority), and the SID for the Everyone group
has a value of 1 (world authority).
Subauthority fieldsContain the really important pieces of the SID. Each subauthority value,
up to but not including the last value, identifies the domain from which the SID was issued or, if
its not part of a domain, the local computer. Regardless of whether it identifies a domain or a
standalone computer, these subauthority values are known collectively as the domain identifier.
The last subauthority value identifies a unique account or security group relative to the domain
(or local computer) and is known as the relative identifier (RID).
While Win2K is most comfortable using SIDs in the form of a simple binary data structure, we
humans like to see things in a simple string format so that we can more easily recognize them.
As a result, you and I never see SIDs in their native format but instead see things like S-1-5-11.
This example is the well-known SID for the Authenticated Users security group, and its
presented in a standard string notation, as follows:
S-R-X-Y1-Y2...-Yn-1-Yn
The format of this string-ized SID breaks down as follows:

SThe string is a SID.

RThe revision level.

XThe identifier authority value.

Y1-Yn-1The series of subauthority values that make up the domain identifier. For all
SIDs issued by the same security authority, all the values in this field are the same. On
the flip side, the domain identifier differentiates SIDs issued by different domains in your
enterprise because no two domains share the same domain identifier. An example of a
well-known domain identifier is the value 32, which Win2K uses for all the built-in
groups such as Administrators, Power Users, and Users.

YnThe RID. Remember that this value is what distinguishes one account or security
group from all the others issued by the same security authority. For example, the static
RID for the Administrators group is always 544, and the RID for the Everyone group is
actually NULL.

140

Chapter 5
To better understand how a SID is typically represented in its string format, take a look at the
following two SIDs:

S-1-5-32-549This is the well-known SID for the built-in Server Operators security
group. The string identifies this value as a SID because the string starts with an S and has
a revision level of 1, an identifier authority value of 5, a domain identifier of 32, and a
RID of 549.

S-1-5-12-7723811915-3361004348-033306820-515The first three values of this SID

are the same as the one above. The domain identifier is a four-part value, and the RID has
a value of 515. The value of the RID is fixed and will never be generated; its hard-coded
and wont be repeated. This is the well-known SID for the Domain Computers security
group. .

RIDs and the RID Master Role

While some RIDs are hard-coded to create what is known as well-known SIDs, Win2K needs to
keep track of all RIDs to guarantee their uniqueness. For a standalone computer on which
accounts and security groups are stored in the SAM database, SAM keeps track of all the RIDs
that its used before and makes sure that it never uses them again. Unfortunately, the situation
isnt quite so simple for a Win2K domain infrastructure.
Because a Win2K domain can have several domain controllers, the ability to keep track of which
RIDs have already been generated gets a bit more complicated. Remember that in Win2K, each
domain controller can accept requests to create a new account or security group, and each has a
replica of AD.
Lets say that Win2K generates RIDs in a domain environment just like it does in a standalone
environment except that instead of looking at the local SAM, it looks to AD to determine which
RIDs have already been allocated. You and another administrator both want to create a new
security group, but you do it on two different domain controllers. When your requests is
processed, the domain controller does a quick search and decides that the new RID will have the
value 42. At about the same time, the other administrators request is processed, and another
domain controller also searches its copy of AD and sees that the value 42 has yet to be used and
decides to use it. Now there are two security groups, in the same domain, with the same RID;
thus, there are two security groups with the exact same SID. What happened? Arent SIDs
asupposed to be unique within their scope?
The problem lies in the delay in searching AD, picking a new RID, writing the RID, and
replicating the change to all AD instances. If you remember the discussions in earlier chapters,
this problem sounds like a situation in which a Flexible Single Master Operation (FSMO) role
can be used. (For those of you who missed it, I covered FSMO roles in Chapter 2.) In fact, this
situation is exactly the type in which an FSMO role, specifically the RID Master role, is used.
This role is responsible for allocating sequences of RIDs to each domain controller in its domain.
When a new account or security group is created in a domain controllers instance of AD, the
domain controller pulls a RID from its allocation of RIDs to construct the new objects SID. As
the domain controller uses up its allocation of RIDs, it has to request another block of values
from the RID Master.

141

Chapter 5
The RID Master role greatly simplifies things because each domain controller only has to make
sure that once it uses a RID from its allocated block, it never uses that value again. Similarly, the
RID Master only has to make sure that once it allocates a block of RIDs, it never allocates those
values again. This coordination between the RID Master and each domain controller in a domain
ensures that each account and security group created in the domain has a unique RID, and
therefore a unique SID.
Well-Known SIDs
As youre probably already aware, a number of SIDs identify generic users and generic groups
that dont change. These constant SIDs are typically referred to as well-known SIDs, and theyre
recognized on every Win2K system. There are over 40 types of well-known SIDs; some
examples are shown in Table 5.1.
Well-Known SID
Value

Well-Known SID
Name

Description

S-1-1-0

Everyone

A security group that includes all users, even anonymous

users and guests.

S-1-3-0

Creator Owner

A placeholder for an inheritable ACE. When the ACE is

inherited, this SID is replaced on the fly with the SID for the
objects current owner.

S-1-5-2

Network

A security group that includes all users who are logged on

using a network connection. Win2K controls the membership
of this group.

S-1-5-11

Authenticated
Users

A security group that includes all users who were

authenticated when they logged on. Win2K controls the
membership of this group.

S-1-5-<domain>502

Domain Admins

A global security group whose members are authorized to

administer the entire domain. The Domain Admins group is a
default member of the Administrators group on all computers
that have joined a domain, including the domain controllers.

S-1-5-<domain>515

Domain
Computers

A global security group that includes all computers that have

joined the domain but not domain controllers, which get their
own security group.

S-1-5-32-544

Administrators

A built-in security group that gives its members full control

over the system. After the OS is installed, the only member
of this group is the Administrator account; when a computer
joins a domain, the Domain Admins group is added to this
group on the local computer.

S-1-5-32-545

Users

A built-in security group that lets typical users perform tasks

such as running applications, using local and network
printers, shutting down the computer, and locking the
computer. After the OS is installed, the only member of this
group is the Authenticated Users group. When a computer
joins a domain, the Domain Users group is added to this
group on the local computer.

S-1-5-32-546

Guests

A built-in security group that lets occasional or one-time

users log on with limited privileges. By default, the only
member of this security group is the Guest account.

Table 5.1: Some well-known SIDs.

142

Chapter 5
One of the interesting things to note about these well-known SIDs is that some of them arent
fully qualified and have a variable component. Two examples are the Domain Admins and
Domain Computers security groups. Although these security groups are well-known and
universally recognized by Win2K systems, groups in different domains wont have the same
effective SIDs.

Access Rights
When you look at Win2K, there is only one right that is universally true: The right to either
allow or deny access to any resource that you own. This truth is the essence of DAC, as I
explained in Discretionary Access Control earlier in this chapter. Although DAC makes sense,
I havent really addressed the basic issue of what a right is. For our purposes, a right is the
authorization to perform some operation. If youll recall from my initial discussion of access
control in Win2K, authorization is an integral part of providing access control, so the concept of
access rights is very important. In Win2K, two types of access rights are implemented: access
permissions and user rights.
Access Permissions
A permission is a specific right that gives a security principal the authorization to perform some
operation on an object. You can set permissions on, for example, files, folders, and AD objects.
One of the more important things to realize about permissions is that if access isnt explicitly
granted, its automatically denied. (From a security perspective, this arrangement is the way you
want things to work. Think what would happen if the opposite was true, and access was
automatically granted unless it was explicitly denied. Youd have to spend all your time
modifying authorizations for your resources, trying to prevent certain people from accessing the
resources you own!) Win2K also lets you explicitly deny access to a resource.
Permissions are implemented in Win2K as one or more ACEs. For each securable object, the
ACEs are collected into what is known as an ACL. Ill describe both ACEs and ACLs in detail a
little later in this chapter (see ACLs), but here, its important to link the concept of permissions
with the implementation of ACLs and ACEs.
Before talking in more detail about some of the different kinds of permissions, I want to talk
briefly about the three types of permissions youll encounter as you manipulate authorizations in
Win2K:

InheritedFlow from higher-level objects to lower-level objects. Inherited permissions

are so important that Ill cover them later in this chapter (see ACE Inheritance).

ExplicitAugment or replace inherited permissions on an object.

ProtectedCannot be inherited by child objects; only explicit permissions exist. Child

objects that have permissions that arent consistent with permissions inherited from a
parent are protected by explicit permissions, and the inherited permissions arent applied.

One last generic point: The granularity of authorizations has been greatly extended in Win2K to
cover not only an object but also the attributes of an object. As a result, you can allow a group of
administrators to do nothing but reset user passwords. This granularity works because each
attribute of an AD object can have its own ACL; there isnt just a single ACL for the entire
object.
143

Chapter 5
NTFS Permissions
There are many advantages to using the NT File System (NTFS) over file systems based on the
old-style File Allocation Table (FAT). For example, NTFS can track permissions and provide
ownership of files and folders. As a result, file and folder permissions are probably the most
common form of authorization that youll manipulate as you work with Win2K. Youre probably
already familiar with managing file and folder permissions in NT, and you wont find things a
whole lot different in Win2K. Although there are some cosmetic changes to the user interface
(UI), the only noticeable change is a few new permissions.
The permissions that you can set on folders and files depend on how an object is being accessed.
On one hand, folders and files that are on the local NTFS volume are only constrained by the
permissions on the object. On the other hand, folders and files that are accessed over the network
are subject to the assigned NTFS permissions as well as any share-level permissions. Share-level
permissions are important, but if you understand how permissions work on local folders and
files, youll understand how they work on your network shares too.
You modify permissions on folders and files in the same fashion as in NT 4.0: Right-click a file
or folder, choose Properties from the shortcut menu, then click the Security tab. The basic
permissions dialog box appears, as shown in Figure 5.5.

Figure 5.5: The basic NTFS permissions dialog box.

One of the first things to notice about the NTFS permissions dialog box in Win2K is that it now
handles both folders and files. As a result, administering folder and file permissions in Win2K is
quite a bit easier because once you know how to modify permissions on one NTFS object, you
can modify permissions on the other. Another thing to notice is that Win2K provides five basic
permissions for folders and files: Full Control, Modify, Read & Execute, Read, and Write.
Folders also have a List Folder permission.
In addition to these basic permissions, you can access the full set of file and folder permissions
by clicking Advanced in the basic NTFS permissions dialog box, then clicking View/Edit. The
full permissions dialog box appears, as shown in Figure 5.6.
144

Chapter 5

Figure 5.6: The advanced NTFS permissions dialog box.

One of the things to note from this figure is that the set of NTFS permissions is more complete in
Win2K than in NT. Thankfully, the name of each permission is pretty self-explanatory, so you
can usually make a good guess about what authorization a permission provides just by looking at
its name. However, the thing that isnt all that intuitive is how the advanced permissions map to
the basic file permissions that youll typically manipulate. The mapping between these two sets
of permissions is shown in Table 5.2.

145

Chapter 5

Advanced Permission

Enables
Basic
Full
Control
Permiss
ion

Enables
Basic
Modify
Permiss
ion

Enables
Basic
Read &
Execute
Permiss
ion

Enables
Basic List
Folder
Contents
Permissio
n

Enables
Basic
Read
Permis
sion

Enabls
Basic
Write
Permis
sion

Traverse Folder / Execute File

List Folder / Read Data
Read Attributes
Read Extended Attributes
Create Files / Write Data
Create Folders / Append Data
Write Attributes
Write Extended Attributes
Delete Subfolders and Files
Delete
Read Permissions
Change Permissions
Take Ownership
Table 5.2: Mapping basic NTFS permissions to advanced NTFS permissions.

Ive touched on the concept of an objects owner a number of times so far, but I havent really
talked about object ownership. Just like every other object, folders and files must have an owner,
and by default, its the user who created it. Remember that as an owner of a folder or file, you
can use permissions to grant authorizations to others and have a great deal of control over who
and how you allow others to access your NTFS resources. Included in these permissions is Take
Ownership, which grants authorization on a folder or file. If youve been granted the Take
Ownership permission on another users NTFS resource, you can take ownership of it from the
Advanced Permissions dialog box using the Owner tab.
AD Permissions
Just as you can set permissions on NTFS objects, you can also set permissions on objects in AD.
You access the permissions on an AD object in pretty much the same way as for any other
object: Right-click the object, choose Properties from the shortcut menu, then click the Security
tab. The basic permissions on a user object are shown in Figure 5.7.

146

Chapter 5

Figure 5.7: The basic AD permissions dialog box for a user object.

When you administer AD, youll often use the Microsoft Management Console (MMC) Active Directory
Users and Computers snap-in. If you find that when you view the properties of an object, the Security
tab isnt present, youll need to make a quick configuration change to the snap-in. This change is
required because Win2K considers viewing the security settings of an AD object to be an advanced
feature. To enable the Security tab and the other advanced features of the snap-in, choose View,
Advanced Features.

Like the basic NTFS permissions dialog box, the basic AD permissions dialog boxs Security tab
shows you only the basic permissions that are available to control access to AD objects. Again,
to access all the permissions for an AD object, click Advanced in the basic permissions dialog
box, then click View/Edit. A list appears of permissions that can apply to a number of objects, as
shown in Figure 5.8. If the object is a container, the list includes permissions that apply to the
object (the container), child objects (objects in the container), and a subset of child objects (for
example, only User objects).

147

Chapter 5

Figure 5.8: The full AD permissions dialog box for a user object.

The fact that a container shows you the permissions that can apply to a number of different
objects is one of the big differences between permissions on an NTFS volume and permissions in
AD. When you own a folder on an NTFS volume and can set permissions on it, they also apply
to all the objects (such as files) in the folder. For example, lets say that you give the GoodFellas
security group Read permission on a folder. When you apply the permission, on the advanced
NTFS permissions dialog box, you select This folder, subfolders and files from the Apply onto
text box so that the permission propagates to all the objects in the folder. The GoodFellas group
now has access to the complete tree of objects that starts with the folder that you originally set
the permission on.
Propagating permissions doesnt work in quite the same manner for objects in AD. When you
own a container in AD, you can allow certain types of access to objects in the container without
granting access to other child objects. Think about owning an organizational unit (OU). You can
add permissions to an OU that let the GoodFellas group read its contents and apply particular
permissions to certain types of child objects. For example, if you set a permission on a User
object, it will flow down only to other User objects, not to other objects such as other OUs,
group objects, or contact objects. This feature allows permissions in AD to be object-specific; it
isnt a capability that is shared with the permissions on an NTFS volume.

148

Chapter 5
In addition to setting permissions on objects in AD, you can set them at the attribute level. When
you set permissions to allow or deny access at the object level, they apply to the entire object.
For example, you can set object-level permissions on an OU to allow the GoodFellas group to
create child objects in the OU. When you set permissions to allow or deny access at the attribute
level, they apply only to the specific attribute of the object. An example is setting attribute-level
permissions on the Home Phone property of a User object so that only you can change the value
of the attribute.
You can set attribute-level permissions on an AD object by right-clicking the object, selecting
Properties, clicking Advanced on the resulting dialog box, selecting one of the permissions, then
clicking View/Edit. Figure 5.9 shows the resulting Properties tab (remember that properties and
attributes are synonyms).

Figure 5.9: Modifying the attribute-level permissions on a User object.

Even with the grand list of permissions shown in this dialog box, the dialog box doesnt list
every attribute, only the commonly used attributes that Microsoft thinks youll want to control
access to. That this list is abridged is actually a desirable quality because the number of attributes
that an object can have can be very large, so the UI filters out object types and attributes to keep
things easier to manage.
You can control the behavior of object and attribute filtering by modifying the Dssec.dat file, which is
in the %Systemroot%/System32 folder on every domain controller. By adding or removing items from
the list, you can control the filtering action of AD objects and attributes by the Win2K UI.

149

Chapter 5
Miscellaneous Permissions
While Ive taken a quick look at the two predominant types of permissions that youll work with
in Win2K, there are obviously many more securable objects available in Win2K. So although
Ive only talked about the securable objects on an NTFS volume and in AD, you should have a
good understanding at this point of what permissions are and how you can manipulate them.
But lets talk very briefly about securable objects and what the term means. Simply put, if an
object is securable, you can set permissions on it. Thats all there is to it, really, so if you
encounter an object and youre not sure whether its securable, see if it has a permission that you
can set.
User Rights
If youve dealt with NT at all, youre already familiar with the concepts of user rights and
extended rights. Win2K redefines both of these terms and calls them logon rights and privileges,
respectively. Overall, the rights in Win2K are the same; they just have different names. Win2K
also offers a few more user rights than was previously available.
While permissions are designed to affect one or more objects, a user right is an authorization that
lets a security principal perform an operation across an entire computer. As I just mentioned,
user rights and extended rights in Win2K come in two distinct flavors: logon rights and
privileges. Logon rights allow you to control the authorizations that govern how your users and
other security principals access a computer. Privileges allow you to control the authorizations
that govern how users are allowed to manipulate system resources. The logon rights and
privileges available in Win2K are listed in Table 5.3.
User Right

Type

Description

Access this computer from

the network

Logon right

Determines which accounts can connect to the computer

over the network.

Act as part of the OS

Privilege

Allows a process to authenticate as any user.

Add workstations to the

domain

Privilege

Determines which accounts can add computers to the

domain.

Back up files and directories

Privilege

Determines which accounts can back up folders and files.

Bypass traverse checking

Privilege

Determines which accounts can bypass folder traverse

checking.

Change the system time

Privilege

Determines which accounts can change the computers

time.

Create a pagefile

Privilege

Determines which accounts can create or modify the

pagefile settings of a computer.

Create a token object

Privilege

Determines which accounts can create a token object that

can be used to gain access to any local resource or
object.

Create permanent shared

objects

Privilege

Determines which accounts can create a folder in the

kernels object manager.

Debug programs

Privilege

Determines which accounts can attach a debugger to any

process.

Deny access to this computer

from the network

Logon right

Determines which accounts cannot connect to the

computer over the network.

Deny logon as batch job

Logon right

Determines which accounts cannot log on to the

150

Chapter 5
User Right

Type

Description
computer as a batch job.

Deny logon as service

Logon right

Determines which accounts cannot log on to the

computer as a service account.

Deny logon locally

Logon right

Determines which accounts cannot log on to the

computer from the console.

Enable computer and user

accounts to be trusted for
delegation

Privilege

Determines which accounts can set the Trusted for

Delegation setting on user and computer accounts.

Force shutdown from a

remote system

Privilege

Determines which accounts can shut down a computer

from a remote location on the network.

Generate security audits

Privilege

Determines which accounts can add entries to the

security log.

Increase quotas

Privilege

Determines which accounts can increase the operating

quotas of a process.

Increase scheduling priority

Privilege

Determines which accounts can increase the scheduling

priority of a thread.

Load and unload device

drivers

Privilege

Determines which accounts can load and unload system

device drivers.

Lock pages in memory

Privilege

Is obsolete and shouldnt be used.

Log on as a batch job

Logon right

Determines which accounts can log on to the computer

as a batch job.

Log on as a service

Logon right

Determines which accounts can log on to the computer

as a service account.

Log on locally

Logon right

Determines which accounts can log on to the computer

from the console.

Manage auditing and security

log

Privilege

Determines which accounts can configure object access

auditing for resources and objects.

Modify firmware environment

variables

Privilege

Determines which accounts can modify system-wide

environment variables.

Profile single process

Privilege

Determines which accounts can profile the execution of a

single process.

Remove computer from

docking station

Privilege

Determines which accounts can remove a laptop from a

docking station.

Replace a process-level
token

Privilege

Determines which accounts can replace the token of a

sub-process.

Restore files and directories

Privilege

Determines which accounts can restore folders and files.

Shut down the system

Privilege

Determines which accounts can shut down the computer.

Synchronize directory service

data

Privilege

Isnt implemented and shouldnt be used.

Take ownership of files or

other objects

Privilege

Determines which accounts can take ownership of files or

other objects without regard to object permissions.

Table 5.3: Logon rights and privileges in Win2K.

151

Chapter 5

You use Group Policy to control both logon rights and privileges in your Win2K environment. If you
need to change the user rights of a local or standalone computer, you can use the local Group Policy
Object (GPO); otherwise, use a domain-level GPO to affect sets of computers.

Permissions versus Privileges

Generally speaking, permissions and privileges collide when the privileges required to perform
some administrative action conflict or overlap with the permissions of a resource. Whenever a
conflict arises between a permission and a privilege, the privilege always wins. To show why,
Ill give you a quick example of the process of backing up the folders and files on a computer.
If you need to back up a complete volume, your backup software needs to be able to traverse all
the folders on the NTFS volume, read the folder contents, read the attributes of every file, and
read the data of every file. Obviously, you dont want to ask every one of your users to grant you
access to perform your backup. To get around this situation, you use the Back Up Files and
Directories privilege to access the account from which you perform backups. This privilege
allows you to back up the necessary folders and files on the system because it overrides the
permissions on the NTFS volume.

Security Groups
Not unlike NT 4.0, Win2K allows you to organize users and other domain objects into groups for
easy administration of access permissions. Win2K enhances the groups provided by NT 4.0 in
three important ways:

Win2K adds distribution groups to the native OS.

Win2K adds new group scopes that correlate to AD implementation.

Win2K allows group nesting.

Additional Distribution Groups

There are two types of distribution groups in Win2K: distribution and security. A distribution
group isnt a security principal and has no corresponding SID. Members of a distribution group
cannot be used in ACLs. Distribution groups exist solely for sending bulk e-mail and are
mentioned here just for completeness.
A security group is a security principal and thus has a SID. Through ACLs, members of a
security group can be granted access to resources. In addition, ACLs allow administrators to
assign the same security permissions to large numbers of users in one operation. This ability
ensures consistent security permissions across all members of a group. Using security groups to
assign permissions means that access control on resources remains fairly static and easy to
control and audit. Users who need access are added or removed from the appropriate security
groups as needed, and the ACLs on resources dont change very often.

152

Chapter 5
You can mail-enable security groups by adding a Simple Mail Transfer Protocol (SMTP)
address, thus letting security groups also function as distribution groups. Additionally, Exchange
2000 (E2K) controls access to public folders using AD security groups. The addition of
distribution groups and the ability to mail-enable security groups allows AD to become the single
repository for group membership across the enterprise. Unfortunately, using AD groups for email distribution lists requires an AD-enabled mail server such as E2K.
Additional Group Scopes
There are four group scopes in Win2K: computer local, domain local, global, and universal.
Computer local groupsGrant access on local computers without granting access across an
entire domain. If the computer participates in a domain, the computer local group may contain
user accounts and global groups from its own domain and trusted domains. The group object is
stored on the local computer and isnt present in AD.
Domain local groupsGrant access to resources in a domain. A domain local group can
contain membership from universal groups, global groups, and accounts from any domain in the
AD forest. If the domain is in native mode, a domain local group can also contain other domain
local groups from its own domain. A domain local group can be used only to assign rights and
permissions in the domain containing the group. The group object is present in the Global
Catalog (GC), although the membership isnt published to the GC.
Global groupsCombine users who share a common access profile. A global group can contain
membership from user accounts from the same domain. If the domain is in native mode, global
groups can also contain global groups from the same domain. Global groups can be used in any
domain in a forest, and they provide a mechanism for creating sets of users from inside a domain
that are available for use both in and outside the domain. If a global group isnt a member of any
other global group, it can be converted to a universal group in a native-mode domain. The group
object is present in the GC, although the membership isnt published to the GC.
Universal groupsGrant access to similar groups of accounts defined in multiple domains and
can be used anywhere in the forest. A universal group can contain members from any domain in
a forest and can include other universal groups, global groups, and accounts from any domain in
the forest. While universal groups of type distribution can be used in mixed-mode domains,
universal groups of type security can be used only in native-mode domains. A universal group
cannot be converted to any other group scope, and the group object and membership is published
in the GC.
Nesting Groups
The final enhancement in relation to groups is that Win2K allows nesting of groups within
groups. Full functionality of nesting is only available in native-mode domains, so there are some
restrictions, as Ive noted above, on nesting groups in a mixed-mode domain.
When attempting to create a new group in a mixed-mode domain, Win2K by default configures the
group as type security with domain local scope. A new group in a native-mode domain is configured
by default as type security with global group scope. In addition, in mixed-mode domains, you cannot
modify a groups scope after creating it.

153

Chapter 5

ACLs
An ACL defines the permissions that apply to an object and its properties. Although this chapter
is concerned with the type of ACL that you use to allow or deny access to resources, there are
really two types of ACLs in Win2K: DACLs and system access control lists (SACLs). The
DACL allows or denies access to objects, while the SACL controls how access to objects is
audited. (Ill talk more about auditing in Chapter 6.)
Structure of an ACL
While there are a couple of bookkeeping entries at the beginning of the ACL structure, it consists
primarily of ACEs, as shown in Figure 5.10. Each ACE is responsible for identifying a security
principal and providing the security principals with rights that are allowed, denied, and/or
audited.

Figure 5.10: The structure of an ACL.

Looking at the structure of an ACL, we see that the bookkeeping entries are the ACL Size, ACL
Revision, and ACE Count values.

ACL SizeIndicates the total number of bytes that the ACL uses.

ACL RevisionIndicates the revision number for the ACLs structure. The interesting
thing to note here is that this value really indicates the structure of the ACEs contained in
the ACL because the structure of an ACL is always the same, but the structure of the
ACEs it contains can be different. While most objects in Win2K use a revision value of 2,
ACL entries for AD objects carry a revision value of 4.

ACE CountIndicates the number of ACEs that are contained in the ACL; this value
can be zero. The remainder of the structure is dedicated to the ACEs.

154

Chapter 5

Access Control Entries

While the ACL is the overall structure for providing permissions in Win2K, its really the ACEs
that carry all the real access control information. Although there are different types of ACE
structures, as I mentioned earlier, all ACEs include a SID, an access mask, flags to determine
inheritance of the ACE, and the ACE type.
All ACEs are somewhat similar, but Win2K supports six ACE types, as shown in Table 5.4. Of
these six ACE types, three are generic and can be used in ACLs for any securable object. The
other three are object-specific and can be used only in ACLs for AD objects.
ACE

Type

Description

Access-denied

Generic

Denies access to an object in a DACL.

Object-specific

Denies access in a DACL to a property or property set or to limit

inheritance to a specified type of child object.

Generic

Allows access to an object in a DACL.

Object-specific

Allows access in a DACL to a property or property set or to limit

inheritance to a specified type of child object.

Generic

Logs attempts to access an object in a DACL.

Object-specific

Logs attempts in a SACL to access a property or property set or

to limit inheritance to a specified type of child object.

Access-allowed

System-audit

Table 5.4: The six types of ACEs.

While generic and object-specific ACEs are extremely similar, there are a couple of differences
between them. The differences can be categorized primarily by the granularity of access control
that they provide for ACE inheritance and object access. Generic ACEs can distinguish between
container and non-container objects only when theyre inherited, and they can only apply to an
entire object. Object-specific ACEs can distinguish between which child objects can inherit them
and can be used on a single attribute, or a set of attributes, of an object.
Whether ACEs are generic or object-specific isnt something that you need to concern yourself
with every day. Whenever you modify an ACL, Win2K automatically constructs the appropriate
ACE and takes care of all the implementation details. However, knowing a little bit about what is
going on under the hood is useful.
The Structure of an ACE
To stay behind the scenes, lets take a quick look at the basic structure of Win2Ks generic and
object-specific ACE types. All three generic ACE types share the same structure, which Figure
5.11 shows.

155

Chapter 5

Figure 5.11: The structure of a generic ACE.

ACE SizeSpecifies the size of the entire ACE in bytes.

ACE TypeSpecifies whether the ACE allows, denies, or monitors access to an object.

Inheritance and Audit FlagsControl the auditing and inheritance aspects of the ACE.

Access MaskIs an ACE type-specific value composed of 32 bits that correspond to the
access rights of the object.

SIDIdentifies the account or group that the ACE should be applied to.

The three object-specific ACE types use the structure that Figure 5.12 shows.

Figure 5.12: The structure of an object-specific ACE.

156

Chapter 5
The fields for ACE Size, ACE Type, Inheritance and Audit Flags, Access Mask, and SID are
identical to those of the generic ACE structure. The real differences between the generic and
object-specific ACE structure lie in the Object Type, Inherited Object Type, and Object Flags
fields.

Object TypeIf present, contains a GUID that is used to represent a type of child
object, an attribute or attribute set, or an extended right

Inherited Object TypeIf present, contains a GUID that specifies which child objects
can inherit the ACE

Object FlagsIndicate whether the Object Type or Inherited Object Type field is
actually present in the ACE structure.

ACE Inheritance
Ive talked a bit about the inheritance of ACEs, but not about how this process actually occurs.
ACE inheritance is the process by which the ACEs in the ACL of a parent object are propagated
to the ACL of a child object. Inherited ACEs arent always recomputed but are instead
propagated from the parent object to the child object in the following circumstances:

When a new child object is created.

When the DACL of the parent object is modified.

When the SACL of the parent object is modified.

Whenever one of these events happens, Win2K must re-evaluate the inheritance of ACEs. One of
the things that you need to be aware of when this re-evaluation occurs is that a container object
may carry an ACL that isnt effective on the container itself but is there only to be inherited
down the chain. When this configuration occurs, the ACEs are inherited down the object
hierarchy until they can be applied to a non-container object. They then become effective ACEs
for that object.

157

Chapter 5
Because an object can inherit ACEs and have explicit ACEs applied directly to it, the specific
order that ACEs are processed becomes important. Win2K manages the order of ACEs by
putting them into what is known as canonical order, as shown in Figure 5.13.

Figure 5.13: The canonical order of ACEs.

Although this figure gives you an idea of what canonical order is, its best described by these
three simple rules:
1. Explicit ACEs are grouped before any inherited ACEs.
2. Within a group of explicit ACEs, access-denied ACEs are placed before access-allowed

ACEs.
3. Inherited ACEs are ordered in the same way in which theyre inherited. Inherited parent

ACEs come first, followed by grandparent ACEs, and so on.

By placing ACEs in canonical order, you can be assured of two things.

Explicit ACEs are evaluated before inherited ACEsThe owner of a child object
really has control over the objects access, rather the objects parent having control. Thus,
you can define permissions on an object that modify the effects of inherited permissions.

Access-denied ACEs are evaluated before access-allowed ACEsYou can allow

access to a large number of users while denying access to a subset of the group.

158

Chapter 5

Security Descriptors
While you now know that ACEs are contained in an ACL, its time to talk about where ACLs are
used. You might think that ACLs are applied directly to an object, but in reality, all access
control information for an object is encapsulated in a data structure known as a security
descriptor. As Win2K manipulates an object, its security descriptor determines whether to allow
or deny access. While the exact makeup of a security descriptor depends on the type of object
that its associated with, a security descriptors contents follow a general formula:

The owner of the object

The users and groups that are allowed or denied access to the object

The users and groups that should have their access to the object audited

The rules for how objects in a container inherit access control information from the
container

In addition to this general information, Figure 5.14 depicts what the variable-length binary data
structure looks like.

Figure 5.14: The structure of a security descriptor.

As you can see, a security descriptor has five major sections.

HeaderContains both a revision number for the structure and a set of flags that
indicate which structure elements are present, where the elements are located relative to
the beginning of the structure, and other general characteristics of the overall data
structure.

Owner SIDAs it sounds, the SID of the security principal that owns the object.

Group SIDIs included only for use by Portable Operating Systems Interface for UNIX
(POSIX) subsystems and is totally ignored by the rest of Win2K.

SACLContains the ACL for the accounts and groups that should be audited when they
access the object.

DACLHolds the ACL for the accounts and groups that can access the object.

159

Chapter 5
Ive pretty much covered the rest of the fields contained in a security descriptor, so I want to take
a quick look at the most important portion of the header, the control flags. The control flags are
important to a security descriptor because they control how ACEs from this security descriptor
will be propagated using inheritance to a child objects security descriptor. Flags are stored as
simple bit fields and are shown in Table 5.5 along with Microsofts definitions.
Control Flag

Definition

SE_DACL_AUTO_INHERITED

Inheritable ACEs in this object's DACL have been propagated to

existing child objects.

SE_DACL_DEFAULTED

The DACL was provided by a default mechanism.

SE_DACL_PRESENT

The security descriptor has a DACL.

SE_DACL_PROTECTED

The security descriptor's DACL cannot be modified by inheritable

ACEs.

SE_GROUP_DEFAULTED

The primary group SID was provided by a default mechanism.

SE_OWNER_DEFAULTED

The owner SID was provided by a default mechanism.

SE_SACL_AUTO_INHERITED

Inheritable ACEs in this object's SACL have been propagated to

existing child objects.

SE_SACL_DEFAULTED

The SACL was provided by a default mechanism.

SE_SACL_PRESENT

The security descriptor has a SACL.

SE_SACL_PROTECTED

The security descriptor's SACL cannot be modified by inheritable

ACEs.

SE_SELF_RELATIVE

The security descriptor is in self-relative format with all information in

a contiguous block of memory. If this flag isnt set, the security
descriptor is in absolute format.

Table 5.5: Security descriptor control flags.

When an object is created, its security descriptor is populated with values and can of course be
modified later. But no matter when the information is put into the security descriptor, the
information can only come from one of three sources: the owner/creator, a parent object, or the
object manager. When an object is being created, these three sources of information are applied
in this order. For example, when a new object is created, the owner can explicitly assign a
security descriptor to the object but doesnt have to. If the owner doesnt supply a security
descriptor, Win2K tries to build one using values inherited from parent objects. If no access
control information is inherited down to the new object, Win2K turns to the object manager to
supply the default access control information for the object, based on the objects type.
After the object is created, the access control information it contains can be modified by the
objects owner or someone whos been granted permission to change the security descriptor
information. The security descriptor can also be modified when the security descriptor of a
parent object is modified. So each time a parents security descriptor is modified, the object
manager is responsible for propagating inheritable changes to all the objects in the container;
these changes will in turn cascade down the next level of children.

160

Chapter 5
The last important thing to say about security descriptors is that security descriptors is where,
and why, every object gets its owner. As I discussed earlier in this chapter, each and every object
must have an owner; therefore, the Owner SID field of a security descriptor is never blank. The
owner of an object can never be denied the right to allow or deny other users permission to
access the object. So even if you lose the ability to read one of your own files, as long as youre
the owner, you can always recover your ability to access the file.

Access Tokens
The final piece in Win2Ks access control puzzle is the access token. As I explained earlier, each
thread that is launched on your behalf during your logon session receives a copy of your logon
session access token. As a result, Win2K can always look at the access token of a thread and
know which security principal its running on behalf of. A Win2K access token consists of the
following information:

User SIDThe SID for the user that is assigned this access token.

Group SIDsThe list of SIDs for every security group that contains the user; includes
the list of SIDs from the users SID-History attribute, if present.

PrivilegesThe list of privileges that the user has been granted on the local computer.

Owner SIDThe SID for the user who becomes the default owner of an object that is
either newly created or has been taken ownership of (typically the same as the User SID
value).

Primary GroupThe SID for the users primary group (remember, its only used for
the POSIX subsystem).

DACLA default set of permissions that Win2K applies to objects that are created by
the user if no other access control information is available.

SourceThe authenticating entity that caused the access token to be created.

TypeA flag that indicates whether this access token is a primary access token or an
impersonation access token.

Impersonation LevelThe extent to which a service can assume the security context of
a client that is represented by this access token.

StatisticsSome statistical information about this access token.

Restricting SIDsA list of SIDs added to the token to create a restricted token.

Session IDAn indication of whether the access token is associated with a Terminal
Services user session.

Most of these values make sense, at least until you get to the Type field. The Type,
Impersonation Level, and Restricting SIDs fields are all involved in creating impersonation
access tokens and restricted access tokens. These are the topics of the next two sections.

161

Chapter 5
Impersonation
Before discussing impersonation access tokens, I want to go over the concept of impersonation.
Win2K supports the notion of impersonation, which is the ability to execute a thread with a
different security context than that of the threads owner. The need for impersonation is driven
by the proliferation of client/server applications that predominate todays computing
environments. When a client contacts a server, the server typically runs with the security context
of some service account that has access to every resource that it might possibly need to carry out
a request.
For example, if Alice contacts a service to retrieve an electronic copy of her pay stub, the service
must have permission to access her pay stub. If Bob contacts the service, the service must have
permission to access his pay stub. The level of access holds true for all the employees in an
enterprise. However, what if the service had a bug and Alice was able to tell the service to get
her a copy of Bobs pay stub? From a security perspective, this level of access is obviously
something that we dont want.
Impersonation overcomes the problems inherent in allowing a service to access all resources by
allowing access checks to be performed against the requestor of the service, not the service itself.
Thus, the service performs access control checks against the identity of the client. Going back to
the pay stub example, if impersonation is used and Alice once again tries to retrieve a copy of
Bobs pay stub, the service takes on the entity of Alice, then tries to access the pay stub. Win2K
uses the identity of Alice and (hopefully) determines that she isnt authorized to view Bobs pay
stub.
Impersonation Access Tokens
The ability of a process to impersonate another user is implemented using impersonation access
tokens. The service runs with its usual primary token, one that is associated with the primary
control thread of the service process. This token makes access checks when the service needs to
access objects of its own accord.
When a service accepts a client request to perform a function, the service needs to create a thread
to do the work on your behalf and associate your access token to this thread. This association is
carried out using the impersonation access token, whereby your access token is copied into the
impersonation token of the thread. The impersonation token is used whenever the service
requests access to an object on your behalf. Once the service is done being you, the thread goes
back to using its primary token and runs in the services own security context. The notion of
primary and impersonation access tokens is depicted in Figure 5.15.

162

Chapter 5

Figure 5.15: Primary and impersonation access tokens.

When impersonation is used, it signifies that a client has agreed to let the service act on the
clients behalf, as if the service actually were the client. The client process controls to what
extent a service can act on the clients behalf by selecting an impersonation level. The choice is
in the hands of the client and not the service. To a certain extent, the concept of impersonation is
similar to granting someone power of attorney over your affairs. Four levels of impersonation are
available:

AnonymousThe client is anonymous to the service.

IdentifyThe service can use the identity of the client in its own security mechanism but
cannot impersonate the client.

ImpersonateThe service can impersonate the client but cannot pass on the clients
identity to another service.

DelegateThe service can impersonate the client not only when it accesses resources on
the services computer but also when it accesses services on other computers.

Restricted Access Tokens

Win2K allows an application to create a child process that has a reduced level of access rights
than the current thread has available to it. This functionality allows applications to create
restricted security contexts for child processes and impersonation threads that are run in a sort of
sandbox environment. Its not a sandbox environment like you find in Java, but it is to the extent
that the rights for the running thread/process have been limited during their execution to a level
that is less than those afforded to the user. This limited access is accomplished using a restricted
access token. A restricted access token can be created in three ways: by removing privileges, by
applying a deny-only attribute to the access tokens SIDs, or by adding restricting SIDs to the
access token.

163

Chapter 5
Restricted access tokens arent something that you get automatically; they have to be explicitly
created for you by an application to reduce the risk that a new process or thread may do
something bad. For example, Microsofts Internet Explorer (IE) 5.5 and higher uses a restricted
access token to launch a Web page that is part of your untrusted security zone. This setup allows
code from an untrusted Web site to execute with less permission than is assigned to you and
reduces the risk that the downloaded Web pages will be successful at doing something malicious
to your system. For those of you who are Win2K application developers, I implore you to use
this feature whenever you can to limit the access you give each of your application threads.

Tying It All Together

Ive now covered all the pieces that go into making an access control decision in Win2K.
Remember, the single goal of an access control decision is to determine whether a security
principal is authorized to perform some action on some object. Win2K handles access control
decisions by considering the following three pieces of information:

The security principals access token.

The security principals desired access mask.

The objects security descriptor.

Ive talked very briefly about access masks as they relate to ACEs. Well, the security principals
desired access mask is pretty much the same thing. The desired access mask is a simple 32-bit
flag structure in which bits are turned on for rights that the security principal wants and turned
off for rights that the security principal doesnt want. The SRM manipulates this desired access
mask to compute whether access will be allowed or denied. The requested access mask is used to
generate a granted access mask.
Initially, the granted access mask is set to all zeros (no access granted). Each requested access
right bit is evaluated; if access is allowed, the corresponding bit is set in the granted access mask.
If access is allowed or denied, the bit is turned off in the requested access mask. Once all the
desired access mask bits are turned off, the granting access mask is returned for use. The bits that
are left on in the granted access mask determine which rights the security principal is actually
authorized to use.
The complete process for determining a security principals authorizations is summarized in the
following five steps:
1. If there is no DACL in the objects security descriptor, the security principal receives all

access to the object that the security principal has requested.

2. If no access bits are set in the desired access mask, the security principal receives no

access to the object.

3. If the right to access the SACL is set in the desired access mask, the security principals

access token is consulted to see whether the Manage Auditing and Security Log privilege
is present. If it is, the bit for the SACL is set in the granted access mask; otherwise, its
not set.

164

Chapter 5
4. If the desired access mask indicates that the security principal wants access to Read

Permissions, Change Permissions, or Modify Owner, the security descriptor is used to

compare the Owner SID of the object with one of the SIDs in the security principals
access tokens User SID or Group SIDs fields. If a match is found, the security principal
is granted access; otherwise, the bits in the granted access mask arent set.
5. The objects DACL examines each ACE in the objects security descriptor using the

following rules:
a. If the inheritance flags of the ACE are marked INHERIT_ONLY, the ACE is
skipped.
b. If the SID in the subjects access token doesnt match the SID in the ACE, the
ACE is skipped.
c. If the ACE type is access-denied, the rights in the security principals desired
access mask are compared with the ACEs access mask. If there are any matches,
the security principal gets no access to the object.
d. If the ACE type is access-allowed, the rights in the security principals desired
access mask are compared with the ACEs access mask. If there are any matches,
access in the granted access mask is turned on.
e. If there are any bits still turned on in the desired access mask, access checking
continues with the next ACE.
f. If all the ACEs are processed and there are any bits remaining in the desired
access mask that havent been turned off, access is implicitly denied. As a result,
all the bits in the granted access mask are turned off, and the security principal
gets no access to the object.

Access Control Best Practices

I cannot tell you how to actually handle granting permissions and user rights in your
environment because every environment is different and every company culture is different. The
most important thing to remember when youre setting up access control in your Win2K
environment is to give people the minimum number of rights they need to do their jobs. If Alice
needs to reset the passwords for people in Hong Kong, grant her the necessary permissions on
the AD objects to allow her to do so. If Bob needs access to all of the Human Resources files on
the network, grant him the access he needs.
However, there is one universal rule that I believe you should always follow, no matter how silly
it might seem at the time: Never give permissions to individual users; always use security
groups. I cannot stress this point enough. If you use security groups to grant permissions, you
can use AD to centrally control group memberships. You have to set the ACL only once; then
you can control permissions using membership in the group. Believe me, adding and removing
people from groups of users is much easier than modifying ACLs across your enterprise.

165

Chapter 5

Group Considerations
The type and scope of the group that you need to use is driven by both business and user
requirements. For maximum flexibility, you need to tend toward deploying universal groups of
type security. These groups can be mail-enabled to provide access control and distribution list
functionality. However, as I noted earlier in this chapter, you can create universal groups of type
security only in native-mode domains.
Another consideration for deploying universal security groups is that membership of universal
groups is published to the GC, so any membership changes that you make will cause replication
traffic. This replication is exacerbated by the fact that group membership is held in a single
multi-valued attribute of the group object; therefore, a large group can generate a significant
amount of replication traffic.
The simplest strategy for mitigating replication traffic is to use group nesting. Look toward
creating large universal groupsumbrella groups that contain just other universal or global
groups. While using nested universal groups allows client applications to view the full
membership of the umbrella group and its subgroups, using global groups may affect the ability
of your client applications to view group membership because global groups dont have their
membership published in the GC.
As Ive just discussed, the ability to expand and view the membership of a group depends on the
scope of your group object. If a group object is a domain local or global group defined in the
local domain, the membership list can be obtained from any local domain controller. And if a
group object is a universal group and users appear directly in the list (not something that should
be done), the membership can be obtained from any local GC.
But if a group object is a domain local or global group that has been created in another domain,
or if a universal group contains global groups that are in other domains, client applications must
make direct Lightweight Directory Access Protocol (LDAP) calls to a domain controller in the
remote domain to retrieve the membership. Depending on the speed of the network, remote
retrieval may take some time. There are no hard-and-fast rules, but be aware of the different
tradeoffs that youll have to make when youre deciding how to deal with large universal groups
and how to nest them.
A final point to be aware of is that Microsoft recommends that the number of members in any
type of group be limited to 5000. If a group needs to contain more than 5000 users, use nesting.
Microsoft further recommends that for reasons of efficiency and scalability, nesting groups be
limited to no more than 500 members. You can of course exceed these values, but if you do,
keep a close eye on things.

166

Chapter 5

Group Best Practices

Table 5.6 presents guidelines for determining whether a group type should be a security or
distribution group.
Create This Group

When

Security

The group requires specific access to network resources.

There is a possibility that the group will require specific access to network
resources in the future.
There is a possibility that the group will require specific access to public
folders in E2K.

Distribution

There is no foreseeable need for specific access to network resources or to

public folders in E2K now or in the future.

Table 5.6: Guidelines for determining group type.

Table 5.7 provides guidelines for determining group scope.

Create This Group

When

Computer local

You need to grant specific access on a local computer without granting

access across an entire domain.

Domain local

The group doesnt require users to see full membership from any domain,
AND
group membership needs to cross domain boundaries, AND
the group is only used to grant access in a single domain.

Global

The group doesnt require users to see full membership from any domain,
AND
group membership doesnt need to cross domain boundaries.

Universal

The group requires users to see full membership from any domain, OR
domain local and global groups wont meet the requirements for the use of the
group.

Table 5.7: Guidelines for determining group scope.

User Rights Assignments

As I mentioned in Chapter 3, user rights assignments can be tricky; determining whether the user
rights that most applications say they require are truly required is a difficult task. In addition, the
sheer number of applications and their required rights makes it impossible for me to really help
you decide which user rights are truly appropriate in your environment. One thing I can do,
though, is tell you never to assign the following user rights to any user or group:

Act as part of the OS

Create a token object

Create permanent shared objects

Debug programs

Generate security audits

167

Chapter 5

Lock pages in memory

Manage auditing and security log

Modify firmware environment variables

Replace a process level token

Synchronize directory service data

Summary
As Ive described in this chapter, access control provides the logical controls that prevent you
from accessing information resources that you arent authorized to access. And because Win2Ks
access control model isnt a lot different than the model implemented in NT 4.0, you might have
come into this chapter with a good comprehension of how to do things such as assign user
privileges and/or set permissions.
Now that Im finished, I hope that you can manipulate basic permissions and user rights. I also
hope that you truly understand what they are, how they work, and how they differ. In addition,
you should have a thorough understanding of how both authorization and access control are used
in Win2K and how the overall access control model works. Armed with all this information, you
should be able to ensure that access control is properly used to protect the information assets of
your enterprise.

168

Chapter 6

Chapter 6: Managing Auditing

Time and time again, Ive seen organizations that otherwise seem to take security seriously
almost totally ignore the last of the four security objectives that I talked about back in Chapter 1.
To review, these four security objectives were:

Confidentiality

Integrity

Availability

Accountability

In that chapter, I defined accountability as assigning and tracking responsibility for the actions of
users and resources. Accountability includes auditing, considered by many a paramount security
objective in its own right, and the topic of this chapter.
Ill say it right up front: Auditing is hard. It takes time to implement and can use a lot of your
systems resources. It takes quite a lot of effort to review the audit logs that your systems create.
If youve ever reviewed audit logs by hand, you know how much fun that can be! After
reviewing audit logs manually, many of you have probably tried to automate your reviews, either
with in-house scripts or programs or by purchasing a security product to do it for you.
Perhaps you didnt really know what you wanted to watch for, so you set up your system to page
you on every little thing. But after incessant paging, many of you probably uninstalled your
automated review software or just ignored all of the pages you were getting. Maybe you havent
experienced these things yourself but have heard of someone who has. As a result, many of you
probably dont even turn auditing on in your Windows 2000 (Win2K) environments. Others of
you may audit events but never review the logs.
Instead of looking at auditing as a tiresome, thankless pain in the neck, you need to recognize
that audit logs are a valuable tool. They go a long way toward supporting individual
accountability of the actions of users in your environment. They can also provide much-needed
evidence in fraud and security investigations. In addition, they can be an effective measure of
just how well your overall security implementations are working.
This chapter describes the auditing system built into Win2K. Before going any further, lets be
clear about what auditing is. Auditing tracks the activities of users and processes by logging
selected system events. To keep things simple, think of an event as something significant that
occurs in your Win2K systems that could require notification.
In this chapter, Ill explain how Win2K provides auditing of significant system events. Along the
way, Ill discuss familiar things such as the Event Viewer and some new things like the Active
Directory (AD) audit log. By the end of this chapter, I hope that youll have a newfound
enthusiasm for and a thorough understanding of the Win2K auditing system.

169

Chapter 6

Developing an Effective Auditing Strategy

Win2K ships with a default audit policy that collects absolutely no information. As a result, no
audit data is collected until you or I go into a system and configure something. Win2K isnt
alone in its default approachmost other operating systems (OSs) also come configured with
little or no auditing out of the box. Those of us who are a bit more security-conscious definitely
want to turn on some level of auditing as soon as we install a new computer in our environment.
But before rushing in to configure a potentially haphazard audit policy, its worth your while to
analyze how and why you want to configure your new Win2K system to perform auditing. To
help you, Ill talk briefly about some of the things you need to keep in mind when developing
your auditing strategy.
Security in any organization really starts with a comprehensive set of security policies and
standards (referred to collectively as security policies, or more simply, security policy). Only
with a defined security policy can you build an effective security-management program for your
Win2K infrastructure. As I alluded to in Chapter 1, the security controls that you deploy must fit
into the overall security objectives of your organization.
Identifying the Three Types of Auditing
One of the most effective ways to measure and understand whether your security controls are
working to support your security policy is to audit things in your enterprise. But auditing can
have different meanings for different people, all depending on their vantage point. While we
might assign them slightly different names, most security professionals would agree that there
are three basic types of system auditing.

Managing configurationValidating that the configuration of a computer matches a

known baseline. Hopefully, this known baseline meets or exceeds current industrystandard best-practice recommendations.

Preventing and detecting intrusionIdentifying, in real time, threats to your

environment that may lead to an intrusion or detecting an actual intrusion.

Auditing eventsCollecting and analyzing selected system events to identify both the
legitimate and abusive use of resources in an environment.

As one would expect, all of these types of system auditing are important for a strong security
program, and they work in an interrelated way. Validating your Win2K systems configurations
can reveal computers that dont comply with your established baselines. Identifying new threats
to your environment by keeping track of the latest and greatest vulnerabilities allow you to take
action to protect your enterprise. These two types of system auditing allow you to not only
identify a threat but also check to see whether your computers are vulnerable to the threat.

170

Chapter 6

Preparing to Audit
When an actual intrusion has occurred, having properly audited system and user events can go a
long way toward helping you unravel how someone gained unauthorized access to one of your
computers. Its this last type of auditingauditing eventsthat this chapter is concerned with.
On the surface, auditing events might seem to be a simple and straightforward affair; however,
before configuring the auditing of your Win2K systems, there are a number of factors that you
need to consider.
Making Auditing Consistent with Security Policy
The auditing that you do needs to be consistent with your organizations security policy. If your
organization doesnt have a security policy, I strongly suggest that you convince management to
create one that is appropriate for your environment. Whether you have a well-defined security
policy or not, however, you need to be aware of both the positive and the negative ramifications
that collecting and retaining system and user audit data can have on your environment.
Overall, you want to ensure that any audit data that you generate in your environment helps you
maintain a secure computing environment and troubleshoot the problems that are bound to occur.
Unfortunately, this noble use of audit data isnt the only use that it may be subject to. For
example, audit data could be subpoenaed during a criminal or civil investigation that relates to
your organization. Attackers could also use audit data to identify users in your environment who
have elevated privileges. Its also not out of the question that business competitors could use
your audit logs to determine who your customers and suppliers are. Your security policy needs to
take all of these potential uses of audit data into account.
Because auditing events produces information that is relevant to both normal system use as well
as system abuse, its important that you know what to do with audit logs in case a security
incident occurs in your environment. Your security policy should be very clear about what
actions need to be taken to ensure that you capture and retain the correct audit information.
While this is important for any security incident, its doubly important in situations where you
need to use audit events to support legal action. As a result, you need to preserve evidence of not
only the system configuration but also the integrity of the audit logs.
Trading Off Information against System Performance
Another aspect to consider before configuring the auditing of your Win2K systems is the tradeoff between information and system performance. Auditing doesnt come for free, and it
consumes both processor and disk resources in your environment. The more auditing you enable,
the more of each of these precious commodities is consumed. On the one hand, if you dont
enable enough auditing, you may not capture the events required to fulfill your security policy.
On the other hand, enabling too much auditing can cause your systems performance to
significantly degrade. Too much auditing can also hide significant audit events in a sea of noise.

171

Chapter 6
I cant tell you exactly how to audit everything in your environment, nor can I even really tell
you what your overall auditing strategy should be. However, you can develop your strategy by
answering the following questions, which you need to ask yourself when devising the security
policy for your environment and choosing an appropriate strategy for auditing events:

Why are you auditing?

What are you auditing?

What do you expect to find?

Is it acceptable to lose some audit information, or must it all be retained?

How long do audit logs need to be retained?

Who is responsible for retaining the logs?

Who is responsible for reviewing the logs?

How often should logs be reviewed?

Who needs access to the logs?

Do logs need to be collected in a central location?

Should different types of systems have different auditing enabled?

Who needs to do what if a review of an audit log turns up something suspicious?

While its important to know the answers to each of these questions, the answer to What are you
auditing? may be one of the more interesting. Based on your security policy, you need to know
what events you need to audit and how they relate to the security threats that youre trying to
protect yourself from. Table 6.1 below gives you a partial list of the types of things you need to
look at and why. Ill give specific recommendations to get you started later in the chapter in
Recommended Auditing Configurations.

172

Chapter 6

This Audit Event

Monitors for This

Audit account logon events

Failure

Brute-force attacks against passwords in your environment. If you see

a dramatic increase in the number of failures, someone may be
systematically walking through your users, trying to find easy-to-guess
passwords.

Audit account logon events

Success

Stolen passwords in your environment. If you see a successful logon

by a user who is on vacation or known to be away from the office,
someone may be inappropriately using the users account.

Audit account management

Success

The misuse of privilege. If you see a user being added to the Domain
Admins group, you can validate that the action was correct and
required for the user to do their job. One of the last things you want is
a rogue Domain Administrator in your environment.

File read accessFailure

An attacker trying to gain access to sensitive corporate files. By

creating a system access control list (SACL) on highly confidential files
in your environment, you can keep track of people who are
inappropriately trying to access the files.

File write access

Failure/Success

Inappropriate changes, or attempted changes, to program files in your

environment. Changes to .exe and .dll files could signal a potential
virus or an attacker modifying the system for their illicit purposes.

Table 6.1: Reasons for capturing certain audit events.

Using the Event Logging Service

The Win2K auditing system revolves around the Event Log Service. By configuring things
appropriately, you can specify that audit entries be written to the Event Log Service whenever
certain events occur in your environment. Each audit entry records what action occurred, the user
who was responsible for the action, the date and time of the action, and any information specific
to the audit event. Not only can you keep track of successfully attempted actions, but you can
also keep track of unsuccessful actions that are attempted in your environment. The Event Log
Service isnt an active subsystem because it doesnt go out and look for the occurrence of events
itself. Instead, its a passive system with the job of collecting information from other objects in
the OS.
The Six Audit Logs
Overall, Win2K can generate a large number of audit events, including account logon/logoff,
account management, directory service access, object access, policy change, privilege use,
process tracking, and other system events. Because of the large number of possible events,
Win2K divides the audit information into six separate logs, as shown below in Figure 6.1.

173

Chapter 6

Figure 6.1: The six logs of the Event Log Service.

Three of these logs are the standard Application, System, and Security logs that most of us are
familiar with. Theyre available on every Win2K system in your environment. The other three
are the Directory Service, File Replication Service (FRS), and DNS Server logs. These are more
specialized logs, and they only exist on servers in your environment that have the appropriate
service installed.
Application Log
The Application Log records errors, warnings, and informational messages generated by
application software. This log can be used by any application to record events that it thinks are
important. Consequently, the quantity and quality of the events in this log depend entirely on the
applications that are installed on your systems. For example, when you install the Windows 2000
Resource Kit, the following event is registered in the Application Log:
Product: Microsoft Windows 2000 Resource KitInstallation operation
completed successfully.
Listing 6.1: The event registered in the System Log when you install the Win2K Resource Kit.

While this is one use of the Application Log, just about any event that an application believes is
important can be written to it. By default, the Application Log can be written to and read by any
user in your environment.
System Log
The System Log records errors, warnings, and informational messages generated by the OS. This
log is used by Win2K and any system-level components, such as device drivers. For example,
when Win2K starts, the following event is registered in the System Log:
Microsoft (R) Windows 2000 (R) 5.0 2195 Service Pack 2 Uniprocessor
Free.
Listing 6.2: The event registered in the System Log when Win2K starts.

174

Chapter 6
By default, the System Log can be written to and read by any user in your environment. What
differentiates the System Log from the Application Log is the context in which the code that
registers the event is running. Events that are written by system code that is running in kernelmode are written to the System Log, while events that are written by applications that are
running in user-mode are written to the Application Log.
Security Log
The Security Log records errors, warnings, and informational messages about security events.
Things like valid and invalid logon attempts and events relating to resource use or modification
are written to the Security Log. For example, when you log on to a computer in your
environment, Win2K records the following event in the Security Log:
Successful Logon:
User Name: paul
Domain:
SHEABEAR
Logon ID:
(0x0,0x9337)
Logon Type: 2
Logon Process:
User32
Authentication Package: Negotiate
Workstation Name: PINEVALLEY
Listing 6.3: The event registered in the Security Log when you log on to a computer.

Unlike the other logs Ive discussed, not just anyone and everyone can read and write to the
Security Log. Instead, only members of the local Administrators group have read access.
Similarly, write access is limited to processes that are running in the security context of the
LocalSystem or an to Administrator. Additional users can be granted the privilege to read and
manage the Security Log by granting them the Manage Auditing and Security Log user right or
the SE_AUDIT_NAME privilege.
Directory Service Log
The Directory Service Log records errors, warnings, and informational messages about the
operation of AD. By default, this log can be read by any user in your environment, and it only
exists on domain controllers. Some of the events that are written to this log include information
about authentication problems with Lightweight Directory Access Protocol (LDAP),
unavailability of LDAP over Secure Sockets Layer (SSL) because of a missing or invalid
certificate, inter-site messaging problems, and problems contacting a Global Catalog (GC). For
example, when AD finishes decrementing its database, it records the following event in the
Directory Service Log:
NTDS (284) Online defragmentation has completed a full pass on database
'C:\WINNT\NTDS\ntds.dit'.
Listing 6.4: The event recorded in the Directory Service Log when AD finishes decrementing its database.

175

Chapter 6

DNS Server Log

The DNS Server Log records errors, warnings, and informational messages about the operation
of an installed DNS server. By default, this log can be read by any user in your environment, and
it only exists on Win2K servers in your environment that are running the DNS service. This log
contains notifications of events such as the service starting or stopping, zone transfers that have
been completed, and excessive replication traffic. For example, when the DNS service has
problems opening a zone for which its been configured, the following event is written to the
DNS Server Log:
The DNS server was unable to open zone 1.168.192.in-addr.arpa in AD.
This DNS Server is configured to obtain and use information from the
directory for this zone and is unable to load the zone without it.
Check that AD is functioning properly and reload the zone. The event
data is the error code.
Listing 6.5: The event recorded in the DNS Server Log when the DNS service cannot open a zone.

File Replication Service Log

The FRS Log records errors, warnings, and informational messages about the operation of the
FRS. Once again, this log can be read by any user in your environment and only exists on
Win2K servers in your environment that are running the FRS. This log contains events that
include information that the service has started or stopped, replication has begun, and replication
has completed. For example, when the FRS successfully overcomes replication issues with other
domain controllers that are preventing the computer from becoming a domain controller, the
following event is written to the FRS Log:
The File Replication Service is no longer preventing the computer
AUGUSTA from becoming a domain controller. The system volume has been
successfully initialized and the Netlogon service has been notified
that the system volume is now ready to be shared as SYSVOL. Type "net
share" to check for the SYSVOL share.
Listing 6.6: The event recorded in the FRS Log when FRS overcomes replication issues.

Reading the Event Log Files

Contrary to what you might think, Win2K doesnt store the event logs as simple text files.
Instead, it stores them in a binary format in an .evt file. This format provides the most compact
method of storing event log information because not all of the information is stored in the saved
record. While efficiency of storage is a valid reason for using a proprietary format, it really has
more to do with a desire on Microsofts part to explain events in multiple languages. As a result,
when an application or the system writes an event to a log, it stores a numerical value that
represents the event.
Programmers who are responsible for writing code that places events in a log are also
responsible for creating event-message-string files for each language that they intend to support.
Every application-and-event-number combination that is written to a log can be mapped to a
single string to accurately reflect the recorded event.

176

Chapter 6
Because the event logs use a proprietary format, its not a simple thing to read them directly. To
reconstruct the human-readable format of the logs, Win2K needs to combine information from a
number of sources, as shown below in Figure 6.2.

Figure 6.2: How Win2K reconstructs event records.

The primary mechanism for reading the event logs is using the Event Viewer Microsoft
Management Console (MMC) snap-in. For those of you familiar with the Event Viewer in
previous versions of the OS, not a lot has changed except that its now an MMC snap-in as
opposed to a stand-alone application. You can even find the Event Viewer in a (somewhat)
familiar spot by choosing Start>Programs>Administrative Tools>Event Viewer.
The process is actually pretty simple. It requires that the Event Viewer combine information
from the Registry, a message table (which translates numerical audit records into a textual
representation), and the event log itself. This process follows these four steps:
1. The Event Viewer uses the Event Log Service to read the contents of an event log.
2. Depending on the event log opened, the Event Viewer queries the Registry for the name

of the corresponding message-table text file. Each application that uses the Event Log
Service must register the location of the file(s) that hold the messages required to
complete the audit events that it writes. The names of these files are stored under the
Registry key
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\EventLog. If you pull
up this Registry key on a computer, youll see the subkeys for each event log that is
supported on your computer.

177

Chapter 6
3. The Event Viewer uses the information it obtained from the Registry to open the

appropriate message-table file to translate events from numerical values into humanreadable format. These files are typically executable (.exe) or dynamic-link library (.dll)
files. For example, the three standard event logs use %SystemRoot%/System32/Els.dll as
the display-name file for translating numerical event identifiers into text strings.
4. The Event Viewer combines the information from the event log with the text retrieved

from the display-name file to present the human-readable form of the event.
Configuring the Event Logs
While you can use Group Policy to control the settings of the standard Application, Security, and
System logs, you can only use the Event Viewer to configure all of the event log settings. If you
right-click any of the logs shown in the Event Viewer, then select Properties from the shortcut
menu, the logs Properties dialog box appears. The System Log Properties dialog box is shown
below in Figure 6.3.

Figure 6.3: General properties for the System Log.

178

Chapter 6
The General tab of the Properties dialog box allows you to control how the log file is configured.
As you can see from the figure above, some information is configurable by an administrator, and
some is read-only. While you can change the display name of the log, I advise against it because
someone who can no longer find the Security Log might panic! Below the display name are a
number of read-only variables that display information about the physical event log. By default,
all of the event logs are stored in the %SystemRoot%\System32\Config folder.
While you cannot use Group Policy to configure the Directory Service, DNS Server, or File
Replication Service logs, you can use it to configure the standard three logs. You can find the settings
for these standard logs in a Group Policy Object (GPO) under Computer Configuration|Windows
Settings|Security Settings|Event Log|Settings for Event Logs. I highly recommend that you use Group
Policy to configure the standard event logs of your domain-based computers and only use the event
log Properties dialog box for stand-alone computers and to configure the three non-standard event
logs.

While I advise against changing the display name, you definitely want to configure the options
that let you manipulate the behavior of the event logs size. You can change the size of the log in
64-kilobyte increments, with a minimum value of 64K; therefore, you cannot turn off the log by
setting its size to zero bytes. In general, set the size of the log file to reflect the log-overwriting
option you choose and the amount of data the event logs collect.
While disk space used to be a valid consideration when selecting the size of event logs, the
availability of cheap storage now renders this consideration moot. You want to set the overwrite
option on your event logs to ensure that you retain an appropriate amount of audit data for your
environment. You can choose from three options, described below in Table 6.2.
This Overwrite Option

Does This

Overwrite events as
needed

Causes each new audit event to overwrite the oldest existing audit event
when the log has reached its maximum size. If you choose this option, you
risk losing events for logs that havent been backed up before their
maximum size is reached.

Overwrite events older

than X days

Causes each new audit event to overwrite the oldest existing audit event
when the log has reached its maximum size, providing that the oldest
event is more than X days old. If you choose this option, you also risk
losing events for logs that havent been backed up before their maximum
size is reached. In addition, if no events can be overwritten, no more
events are logged, and auditing essentially ceases to function until the
oldest event has aged sufficiently so that it can be overwritten.

Do not overwrite events

(clear log manually)

Never allows new audit events to overwrite older audit events. Once the
log reaches its maximum size, auditing for this log ceases until the log is
explicitly cleared by an administrator. This is probably the most secure of
the three options, provided that youve put appropriate operational
procedures in place to ensure that the log is backed up and cleared before
it reaches its configured maximum size.

Table 6.2: Event log overwrite options.

You can manually clear an event log by right-clicking it and choosing Clear All Events from the
shortcut menu. Youre then asked if you want to save the log before clearing it. When you clear a log,
I recommend that you always save a copy.

179

Chapter 6
As youve seen, you can configure the event logs of a Win2K system in such a way that audit
events are being generated but not stored in the event log. While this is an undesirable situation
for any of the logs, it can be unacceptable for the Security Log. Consequently, if Win2K cannot
continue auditing events to the Security Log, it has an option to actually halt the system. Known
as CrashOnAuditFail, this option will crash a computer if it cannot continue auditing security
events. While a crash sounds pretty drastic, its really the only recourse for this setting because
shutting down gracefully might require it to write security events to the event log, something it
cannot do! The settings to enable this option are shown below in Table 6.3.
Registry key component

CrashOnAuditFail setting

Hive

HKEY_LOCAL_MACHINE

Key

\CurrentControlSet\Control\LSA

Name

CrashOnAuditFail

Type

REG_DWORD

Value

Table 6.3: CrashOnAuditFail settings.

When the system crashes as a result of this setting, the Registry key is set to 2 and the key type to
REG_NONE. With the computer in this state, the only person who is allowed to log on is the
local administrator. When you do, you need to clear the Security Log; in addition, remember to
save a backup copy of the log. You also need to reset the value of the Registry key to 1 and
reconfigure the key type to REG_DWORD. Once youve done this, you can safely restart the
system, and it will resume normal operations.
The CrashOnAuditFail option is also available in Group Policy. You can find it under Computer
Configuration|Windows Settings|Security Settings|Event Log|Settings for Event Logs as the Shut
Down the Computer When the Security Log is Full configuration option.

Filtering the Event Logs

From the Log Properties dialog box, you can control how the information in the Event Viewer is
displayed. This comes in very handy, for example, when you have a 20-megabyte event log and
youre looking for something specific instead of just browsing the event log for fun. (Keep in
mind that this feature only affects how the information in the event log is displayed; it has no
effect on its actual contents.) In the event log Properties dialog box, click the Filter tab; the Filter
page is displayed, as shown in Figure 6.4.

180

Chapter 6

Figure 6.4: Event Log filtering options.

The filtering mechanism for the event logs allows you to filter events in, not filter them out. It lets you
choose the conditions that an event must satisfy to be displayed. By default, the event logs are
configured to filter in all of the events they contain.

As you can see, you can set a number of options to filter the display of the event logs. At the top
of the Filter page are options to filter in events based on their type. (For more information on
event types, see Event Types later in this chapter.) You can select one or more event types to
include only those types of events that youre interested in. In the middle of the Filter page are
more detailed filtering configuration options that allow you to filter in events that are relevant to
a specific user, computer, event, or source. The last portion of the Filter page allows you to view
log information between certain date and time combinations.
As a result of these powerful filtering options, you can narrow down your search for events to the
time that a particular security incident occurred in your environment. You can also easily
monitor what is occurring on a specific computer or even what a specific user is up to. Whenever
you need to go into a large event log file, I encourage you to use the filtering options to greatly
reduce the amount of data that youd have to sift through to find what youre looking for.
Event Record Format
Each event record generated by the Event Log Service is written to the relevant event log. While
each event record stores some type of specific information, all have a common format. That is,
each record is composed of two distinct portions: the event header and the event description. The
event record header is static and contains eight fields, as described below in Table 6.4.

181

Chapter 6
This Field

Records This

Date

The date the event occurred.

Time

The time the event occurred in local timethat is, not in Universal Time Coordinate
(UTC) or any other time.

Type

The classification of the severity of the generated event.

User

The name of the user on whose behalf the event occurred.

Computer

The computer on which the event occurred.

Source

The software that generated the event.

Category

The classification of the generated event.

Event ID

The numerical ID of the generated event.

Table 6.4: Event record header information.

The event record description contains information that is specific to the event, as shown below in
Figure 6.5. As you can see, there is not only a Description text box but also a Data text box; both
are available as part of the variable portion of an event record. The Description text box is
typically human-readable, while the Data text box, if its specified, contains application-specific
data, which can be displayed as either bytes or words. You can display the details of each event
record by simply double-clicking an event in the Event Viewer.

Figure 6.5: The Event Properties dialog box.

182

Chapter 6
Event Types
Five types of audit events can be placed in the event logs, as shown below in Table 6.5. All event
types can be stored in each event log.
This Event
Type

Uses This
Icon

And Represents This

Error

A significant event. Loss of functionality is typically categorized as an

error event type. For example, if a service fails to successfully start, it
typically logs an error event before exiting.

Warning

Something that may not be immediately significant but that could

foreshadow problems. For example, applications that run into execution
problems but can continue processing without (significant) loss of
functionality log warning events, then move on.

Information

Something that occurred successfully as part of normal operation. This

is typically a major Win2K service, which uses the information event
type to indicate that its started. In fact, when Win2K starts, it places an
information event to mark the initialization of the system.

Success Audit

An audit event that was successfully carried out. For example, if

logon/logoff success auditing is enabled, a success audit event is
generated each time a user successfully logs on to or off the system.

Failure Audit

An audit event that failed. For example, if you set an object to audit
failed access attempts, a failure audit event is generated each time a
user tries unsuccessfully to access the object.

Table 6.5: Event log event types.

Backing Up Event Logs

No matter how you configure event logs, there will be times when you want to retain them for
future reference. Depending on your environments security policy, you may need to back up the
log files every day, or you may need to only create backup copies to document some security
incident. Just remember that each log is truly a different log; thus, the strategy you use to back up
the Security Log can be very different from how you back up the Application Log. Because
hackers target the event logs and typically alter or delete them to cover their tracks, I suggest you
set up a standard method of retaining your event logs.
Whatever your reason for retaining event logs, you can retain them in three primary formats:

Event log format (.evt)

Tab-delimited text format (.txt)

Comma-separated values (CSV) format (.csv).

As weve seen, the event log format is the most economical of the three. However, you can only
view this format with the Event Viewer, as shown below in Figure 6.6. If you decide to retain
logs in this format, you need to also retain the proper supporting files and Registry information
so that you can view the information again.

183

Chapter 6

Figure 6.6: Viewing a Security Log in event log format.

Although theyre not as storage friendly, you can also retain event logs in tab-delimited text or
CSV format (shown below in Figure 6.7). Saving your logs in these formats frees you from
having to remember to save all of the proper supporting files and Registry information to view
the logs again. It also allows you to easily view the event logs directly in a simple text editor or
import them directly into a database for later querying. The downside to these formats, though, is
that theyre more susceptible to malicious or unintended alteration. If youre creating backups for
evidential reasons, I recommend that you use the standard event log format.

Figure 6.7: Viewing a DNS Server Log in CSV format.

No matter which format you choose, the Event Viewer is the only built-in mechanism for
backing up event logs. To back up an event log, open the Event Viewer, right-click the event log
you want to save, then choose Save Log File As from the shortcut menu. In the standard Save As
dialog box, specify the name and location of the backup.

184

Chapter 6

Controlling Access to Event Logs

As with all other objects in Win2K, access to the event logs is controlled to prevent someone
without authorization from viewing or modifying them. Access to event logs is determined by
the account under which the application is running. For example, if you run the Event Viewer as
a standard user, you have different access rights than running it as a local administrator. In
determining access to the event logs, Win2K only cares about four types of accounts:
LocalSystem, Administrators, ServerOperators, and Everyone. This access is described below in
Table 6.6.
This Event Log

Runs Under These Accounts

And Has This Access

Application

LocalSystem

Read, Write, Clear

Administrators

Read, Write, Clear

ServerOperators

Read, Write, Clear

Everyone

Read, Write

LocalSystem

Read, Write, Clear

Administrators

Read, Clear

Everyone

None

LocalSystem

Read, Write, Clear

Administrators

Read, Write, Clear

ServerOperators

Read, Clear

Everyone

Read

LocalSystem

Read, Write, Clear

Administrators

Read, Write, Clear

Everyone

Read

LocalSystem

Read, Write, Clear

Administrators

Read, Write, Clear

Everyone

Read

LocalSystem

Read, Write, Clear

Administrators

Read, Write, Clear

Everyone

Read

Security

System

Directory Service

DNS Server

File Replication Service

Table 6.6: Event log access control settings.

As you can see, the Security Log is the most tightly controlled of the six event logs. By
restricting write access to the LocalSystem account, its highly unlikely that an intruder can fill
up your Security Log. As I mentioned earlier in Configuring the Event Logs, if you have the
CrashOnAuditFail option turned on and the Security Log fills up, the system crashes. By limiting
who can write to the Security Log, you dont eliminate the possibility of a crash, but you
significantly decrease the likelihood that an intruder can crash your system and cause a simple
denial of service (DoS) attack on the computers in your environment.

185

Chapter 6
Another way to control access to the Application, Security, and System logs is to use the
Registry key shown below in Table 6.7. Setting each key to a value of 1 prevents guest accounts
and null logon sessions from viewing these event logs. Be sure to set this key for each of the
three logs.
Registry key component

RestrictGuestAccess setting

Hive

HKEY_LOCAL_MACHINE

Key

\CurrentControlSet\Services\EventLog\[Application|Security|System]

Name

RestrictGuestAccess

Type

REG_DWORD

Value

Table 6.7: Restricting guest access to the Application, Security, and System logs.

While you can configure these settings by hand, its once again much more effective to use Group
Policy to configure this option for your domain-based computers. You can find the settings for the
standard three logs in a GPO under Computer Configuration|Windows Settings|Security
Settings|Event Log|Settings for Event Logs. Obviously, you need to modify stand-alone computers by
configuring these Registry values explicitly.

Setting a Basic Audit Policy

Now that you know where audit information in Win2K is written to, its time to look at how to
get audit information into the event logs. While you may think of auditing as a single set of
configurations, Win2K treats it as two levels. The first level has to do with setting a basic audit
policy, and this is the focus of this section. The second level entails setting audit options on
specific objects in your environment. Ill describe this second level in Auditing Objects below.
The best way to enable high-level audit policy is to use either Local Security Policy or domainbased Group Policy. In either case, the configuration settings available are shown below in
Figure 6.8. These settings represent the standard, out-of-the box defaults of not only this domain
but your domain as well!

186

Chapter 6

Figure 6.8: Standard audit policy settings.

As you can see, there are nine categories that you can configure to implement basic audit policy.
These nine categories are listed below in Table 6.8; they track system-level events that are
recorded in the Security Log.
This Audit Policy

Records This

Audit account logon events

The success and/or failure of a user to authenticate across the network

to the local computer.

Audit account management

The creation, modification, or deletion of any user account (including

computer accounts) or groups. In addition, it records any success or
failure of a change to a users password.

Audit directory service access

Successful and/or unsuccessful attempts to access AD. While this

policy can be set on any computer, it only affects domain controllers.

Audit logon events

The success and/or failure of a user to log on interactively to the local

computer.

Audit object access

The success and/or failure of a users attempt to access an object. For

our purposes, an object includes files, folders, printers, and any other
object that supports a SACL.

Audit policy change

Successful and/or unsuccessful attempts to change the basic security

policy. This includes changes to both audit policy and privilege
assignments (which I discussed in Chapter 5).

Audit privilege use

The success and/or failure of a users attempt to use a system privilege.

Audit process tracking

The success and/or failure of a process to perform certain detailed

events. These events include but arent limited to process activation,
handle duplication, indirect object access, and process deletion.

Audit system level events

The successful and/or unsuccessful events that can have a direct effect
on the security of the system.

Table 6.8: Audit policy settings and what they control.

187

Chapter 6

Auditing Objects
While many of the audit policy settings described above enable the standard auditing functions
all by themselves, two configuration options only enable a class of auditing.

Audit Object AccessAllows you to use the individual properties of an object to enable
auditing of different permissions available to users in your environment. Examples of
individual object types are files, folders, printers, and the Registry, and theyre discussed
below.

Audit Directory Service AccessAllows you to use the individual properties of AD

objects to enable auditing of different permissions available to users in your environment.

To set audit policy on any of these objects, you must have the Manage Auditing and Security
Log privilege. This privilege allows users to specify the Audit Object Access configuration
options of things like files, folders, printers, the Registry, and the objects contained in AD. So
while you can enable your environment to collect object access and directory service access
events with your system policy, you cannot audit individual objects without granting this
privilege.
You may recall that in Chapter 5, I recommended to never assign this privilege to anyone in your
environment. This obviously causes an interesting problem: How do you set up auditing of
objects if you dont assign this privilege to any users? Well, I recommend that under normal
circumstances, you dont assign the privilege to anyone. When youre setting up the audit
configurations of sensitive objects in your environment, assign this privilege to one or more
users. Once the audit configuration is complete, remove this privilege from the users. This form
of least privilege requires some effort, but I believe its warranted because it ensures that you
have complete control over how auditing is implemented in your environment.
Files and Folders
While basic system auditing gives you a great overall picture of what is occurring in your Win2K
environment, nothing keeps track of what is happening to the files and folders on individual
computers like auditing files and folders. File system auditing gives you a granular view of how
resources are being accessed. This type of auditing is granular because you can choose to keep
track of specific types of access to the object as well as the specific users you want to track. The
types of access that you can audit for file system objects are described below in Table 6.9.
This Audit Access

Audits Attempts To Do This

Traverse Folder/Execute File

Traverse a folder or execute a file.

List Folder/Read Data

List the contents of a folder or read the contents of a file.

Read Attributes

Read the attributes of a file.

Read Extended Attributes

Read the extended attributes of a file.

Create Files/Write Data

Create a file or write data to a file.

Create Folders/Append Data

Create a folder or append data to a file.

Write Attributes

Modify the attributes of a folder or file.

Write Extended Attributes

Modify the extended attributes of a folder or file.

Delete Subfolders and Files

Delete subfolders or files within a folder.

Delete

Delete a folder or file.

188

Chapter 6
This Audit Access

Audits Attempts To Do This

Read Permissions

Read the permissions of a folder or file.

Change Permissions

Change the permissions of a folder or file.

Take Ownership

Take ownership of a folder or file.

Table 6.9: Options for auditing files and folders.

As with all of the other auditing capabilities of Win2K, you need to be careful about what you
choose to audit. This is especially true for auditing files and folders because there are a lot of
files on each of your systems, some of which, in the course of normal operation, are accessed
often. If you were to audit the successful access of your computers system DLLs, youd quickly
overrun the Security Log. However, auditing files and folders allows you to keep track of critical
files in your environment. Overall, you want to set file system auditing to track someone who
might be probing around for things and to identify users who are destroying information.
You can configure file and folder policy settings in Windows Explorer. Right-click the file or
folder you want, then choose Properties from the shortcut menu. In the Properties dialog box that
appears, click the Security tab, then click Advanced, and select the Auditing tab. On the Auditing
page, shown below in Figure 6.9, you can add, remove, and modify the audit settings of the
selected object. Configuring file and folder policy on more than a few computers is tedious at
best, so I highly recommend that you use Group Policy to set the audit properties of domainbased computers.

Figure 6.9: Using the Access Control Settings dialog box to configure file and folder policy settings.

Printers
While many of you may not be aware that you can audit printers, you definitely can. Overall,
auditing printers isnt a common practice because it fills up your Security Log with information
that has negligible value. However, if you have a printer or two in your environment that you
consider sensitive, it can be very useful. For example, a printer used by Human Resources to
print performance reviews or the Payroll printer used for cutting employee paychecks could be
considered sensitive and thus worthy of auditing.
189

Chapter 6
The audit configuration settings that are available for printers in a Win2K environment are
shown below in Table 6.10. You can access the audit setting of a printer by selecting it and
following the same procedure as described above for auditing files and folders.
This Audit Access

Audits This

Print

Printing documents.

Manage Printers

Changes to printer settings.

Manage Documents

Changes to printing such as pausing, restarting, and deleting jobs.

Read Permissions

Reading the permissions of a printer.

Change Permissions

Changing the permissions of a printer.

Take Ownership

When the ownership of a printer is taken.

Table 6.10: Options for auditing printers.

The Registry
The Registry holds just about all of the important configuration information for Win2K. As a
result, its important that you consider auditing changes to the Registry settings of the computers
in your environment. You need to be concerned about changes that are made to specific Registry
keys and use auditing to track who has made them. Unfortunately, you once again cannot audit
everything; otherwise, youd quickly fill up the Security Log. The audit options that are available
for Registry objects are shown below in Table 6.11.
This Audit Access

Audits Attempts To Do This

Query Value

Read the value of a subkey.

Set Value

Set the value of a subkey.

Create Subkey

Create a new key or subkey.

Enumerate Subkeys

Enumerate all subkeys of a key or subkey.

Notify

Receive generated audit notifications.

Create Link

Create symbolic links.

Delete

Delete the key or subkey.

Write DAC

Modify the access control list (ACL) for a key or subkey.

Write Owner

Modify the owner of a key or subkey.

Read Control

Read the security information of the key.

Table 6.11: Options for auditing the Registry.

You can configure auditing settings for the Registry using Regedt32.exe. Select the item you
want, then choose the Permissions option from the Security menu, click Advanced, then choose
the Auditing tab to display the Auditing page. However, as with auditing files and folders,
configuring audit policy for the Registry on more than a few computers is tedious at best, so I
once again highly recommend that you use Group Policy to set the Registry audit settings of your
domain-based computers.

190

Chapter 6

To audit files and folders, printers, and/or the Registry, you need to set the auditing options for the
objects you care to collect access information from. In addition, you also must ensure that the Audit
Object Access system auditing option is enabled.

Directory Services
While the Registry is key to individual computers in your environment, AD is undoubtedly the
most important information store for your entire Win2K infrastructure. Thus, its a good idea to
keep an eye on the changes that are occurring in your AD infrastructure. Much like the Registry,
you need to be concerned about changes that are made to specific AD objects and their
properties, and you should use auditing to track who has made them. As in other areas, you
cannot audit everything; otherwise, youd quickly fill up the Directory Service Log.
Unlike other objects whose audit options you can control, the audit options available for objects
in AD depend solely on the object itself. As a result, different objects have different options
available. Table 6.12 below shows a subset of audit options available for user objects in AD.
This Audit Access

Audits Attempts to Do This

List Contents

List the contents of the object.

Read All Properties

Read the properties of the object.

Write All Properties

Write the properties of the object.

Delete

Delete the object.

Read Permissions

Read the permissions of the object.

Modify Permissions

Modify the permissions of the object.

Modify Owner

Modify the owner of the object.

All Validated Writes

Perform validated writes to the object.

Change Password

Change the password of the object.

Table 6.12: Some of the options for auditing user objects.

You might recall from the discussion of setting access control on AD objects in Chapter 5 that
you can set access control permissions directly on an object as well as on each attribute of an AD
object. Once again, the audit options available for the properties of an object depend on the type
of object that youre setting auditing for.
To audit access to AD objects, you need to set the auditing options for the objects you care to collect
access information from. In addition, you must ensure that the Audit Directory Service Access system
auditing option is enabled.

You can configure audit settings for AD objects much like you set auditing for files and folders.
In Windows Explorer, select the AD object you want, right-click it, then choose Properties from
the shortcut menu. In the dialog box that appears, click Security, Advanced, then the Auditing
tab to display the Auditing page. If you do this for your own user object, one of the things that
should quickly jump out at you is that some default audit settings already exist!

191

Chapter 6
While Win2K ships out of the box with no other object audit settings configured, AD comes preconfigured for you. AD contains too many objects and properties to list here, so Ill describe a
standard user object. By default, an AD user object audits all successful and failed attempts to
both change and reset a users password. In addition, audit settings are pre-configured to audit
successful and failed attempts to write to all of the properties of a user object. As a gross
oversimplification, you can look at AD auditing as being pre-configured to audit any addition,
deletion, and modification of AD objects and their properties.

Examining Security Event Records

There are well over 100 event records that may appear in the Win2K Security Log. Listing all of
them here is beyond the scope of this chapter, but I want to list about 20 to give you an idea of
the types of security event records you can find in your environment. These security event
records are listed below in Table 6.13.
Event ID

Event Type

Description

512

Success

Win2K is starting.

513

Success

Win2K is shutting down.

517

Success

The audit log has been cleared.

528

Success

A successful logon has occurred.

529

Failure

A logon failure has occurred because of an incorrect password or

unknown user account.

530

Failure

A logon failure has occurred because the user didnt log on within the
specified amount of time.

531

Failure

A logon failure has occurred because the account is disabled.

538

Success

A user has logged off.

539

Failure

A logon failure has occurred and the account is locked as a result of the
account lockout policy settings.

608

Success

A user right has been assigned to a user.

609

Success

A user right has been removed from a user.

610

Success

A trust relationship has been established with the specified domain.

611

Success

A trust relationship has been removed from the specified domain.

612

Success

The audit policy has been changed.

617

Success

The Kerberos policy has been changed.

618

Success

The encrypted data recovery policy has been changed.

624

Success

A new user account has been created.

628

Success

A user password has been reset.

645

Success

A new computer account has been created.

669

Success

A SID-history was added to a user account.

670

Failure

An attempt to add a SID-history to a user account has failed.

Table 6.13: A partial list of security event records.

192

Chapter 6
While there could be many more event records in your Security Log, the ones above are a
reasonable subset to keep an eye on. Each event record affects the security of your environment.
For example, lets say that you find an Event ID of 608 in the Security Log of one of your
domain controllers. It could be a harmless, normal thing for your environment. On the other
hand, if you see that its assigning the Act As Part of the Operating System right, you should get
very suspicious! Likewise, an Event ID of 670 could be an honest mistake, or it could indicate
that someone is trying to maliciously add your security identifier (SID) to their account so that
they can have access to all of the same resources you do!
If you run across an event log entry that doesnt make immediate sense from the description, youll
find a more detailed description in the Error and Event Messages Help file in the Win2K Resource Kit.
This Help file doesnt list all of the event IDs that you might run across because some of the
application or system entries might be generated by third-party software that youve installed on your
computer.

Recommended Auditing Configurations

I recommend the following auditing configurations for your Win2K environment.
Event Log Properties
Event log properties control how the computers in your environment maintain their audit logs.
You need to find an appropriate balance among three factors: the format in which you retain your
logs, what you put in them, and how large youre willing to configure them.
Its prudent for you to keep logs for at least two to three months. Because logs can become quite
large, its a good idea to clear them from time to time. Whenever you clear an event log, I
recommend that you also save a copy of it. In general, its probably a good idea to save and clear
each event log once a month. Try to keep backups of these logs on hand for a minimum of three
months and probably a maximum of six months. Believe me, theyll come in very handy when
you need to look at logs that are four or five months old to unravel some security incident in your
environment. The event log configurations that I recommend are listed below in Table 6.14.
For This Event Log Property

Use This Setting

Maximum log size

Greater than 10240K. Disk space is cheap today, and there is no

valid reason to skimp on the size of event logs. Configure each log
to handle enough events that it doesnt fill up for about 45 days. Ive
seen event logs configured up to 128 MB!

Retain log

45 days. Ideally, youll make backups of the event logs and clear the
logs every 30 days. However, in case you miss a month, give
yourself some slack.

Retention method for log

Overwrite events by days. For those of you who are paranoid about
security, you might consider never overwriting events in your event
logs. But Id personally rather lose audit events that are 45 days old
than events that are current!

Shut down the computer when

the security audit log is full

Disabled. Security is important, but Id only be tempted to enable this

setting in environments where security is more important than
availability.

Table 6.14: Recommended settings for event logs.

193

Chapter 6
System Audit Policy
The system audit policy configuration options control the overall system-level audit policy of
your Win2K computers. The security community almost universally recommends the system
audit policy configurations shown below in Table 6.15. I suggest that you use these settings as
the starting point for your environment and only modify them as necessary to support the
security policy of your organization.
For This Audit Policy

Use This Setting

Audit account logon events

Success, Failure

Audit account management

Success, Failure

Audit directory service access

Failure

Audit logon events

Success, Failure

Audit object access

Failure

Audit policy change

Success, Failure

Audit privilege use

Failure

Audit process tracking

No auditing

Audit system level events

Success, Failure

Table 6.15: Recommended settings for system audit policy.

File System Object Auditing

Use the recommendations in Table 6.16 below as a guideline and carefully plan how youll audit
the sensitive folders and files in your environment. In general, you want to set file system
auditing to track someone who might be probing around for things and to identify users who are
destroying information.
For This Audit Access

Use This Setting

Traverse Folder/Execute File

Failure

List Folder/Read Data

Failure

Read Attributes

Failure

Read Extended Attributes

Failure

Create Files/Write Data

No auditing

Create Folders/Append Data

No auditing

Write Attributes

Failure

Write Extended Attributes

Failure

Delete Subfolders and Files

Success, Failure

Delete

Success, Failure

Read Permissions

Failure

Change Permissions

Failure

Take Ownership

Success, Failure

Table 6.16: Recommended settings for auditing files and folders.

194

Chapter 6
Printer Object Auditing
Use the recommendations in Table 6.17 below as a guideline and carefully plan how youll audit
the sensitive printers in your environment. Your general strategy should be to track any
suspicious use or modification of a printer. And remember that for this strategy to really work,
you need to set access control on who is authorized to use the printer. Then its worthwhile to
audit failures to print to your sensitive printers.
For This Audit Access

Use This Setting

Print

Failure

Manage Printers

Success, Failure

Manage Documents

Success, Failure

Read Permissions

No auditing

Change Permissions

Success, Failure

Take Ownership

Success, Failure

Table 6.17: Recommended settings for auditing printers.

Registry Object Auditing

Use the recommendations in Table 6.18 below as a guideline and carefully plan how youll audit
the Registry. As I mentioned earlier, the strategy is to track not only the unsuccessful attempts to
modify Registry keys but also the successful changes. This strategy will allow you to trace any
problems back to the user who caused them.
For This Audit Access

Use This Setting

Query Value

No auditing

Set Value

Success, Failure

Create Subkey

Success, Failure

Enumerate Subkeys

No auditing

Notify

No auditing

Create Link

Success, Failure

Delete

Success, Failure

Write DAC

Success, Failure

Write Owner

Success, Failure

Read Control

No auditing

Table 6.18: Recommended settings for auditing the Registry.

In general, you need to be most concerned about changes to the Registry that adversely affect the
system. At a minimum, audit only the following keys and their subkeys:

HKEY_LOCAL_MACHINE\System

HKEY_LOCAL_MACHINE\Software

HKEY_CLASSES_ROOT.

195

Chapter 6
Directory Services Object Auditing
Win2K enables a number of default audit settings on AD objects and their properties, and most
of them keep security in mind. In addition, AD can be a large and complicated beast, and
changing it by hand could cause unrecoverable problems for your Win2K environment. As a
result, I dont recommend that you change any of the default audit settings of the AD objects in
your production forests.
If for some reason you feel compelled to modify theWin2K defaults, I highly recommend that
you do extensive testing in a lab environment before carrying over the changes to your
production environments. Im paranoid of unnecessary modifications to AD because the industry
hasnt developed a full set of best practices for it, and Ive seen more than one AD forest
chopped down because AD became unrecoverable after someone made untested modifications!

Summary
In this chapter, Ive attempted to show that audit logs are a valuable tool. They support
individual accountability of a users actions, can provide evidence for investigations, and can
reveal just how well your overall security implementations are working.
While the Event Log Service in Win2K hasnt changed much from its implementation in
previous versions of the OS, I hope that you now have a much more thorough understanding of
how auditing works in Win2K. In addition, you should have a good foundation for mapping your
organizations security policy to the required auditing settings. This will ensure that you capture
the right kinds of auditing information to make your overall security program effective!

196

Chapter 7

Chapter 7: Managing Security Configuration

In previous chapters, I presented quite a bit of theory, along with some practical advice and howtos to help you secure your Windows 2000 (Win2K) infrastructure. While this approach has been
necessary to adequately cover the material, this chapter will be a little different.
In this chapter, Im going to spend less time on theory and more time on practical things like
how to accomplish specific tasks and how to organize and configure security in your
environment. This new approach is partially in response to the material itself; its also because I
think that the best way to learn how to manage the security of your environment is to get in there
and just do it. As a result, you might find it beneficial to read this chapter while youre sitting in
front of your Win2K computer so that you can use the concepts and tools as I introduce them.
Because this chapter discusses managing security, Ill start by talking about the Security
Configuration Tool Set (SCTS)the single best practical tool for configuring the security of
your environmentand explain how to put it to best use in your enterprise.

Understanding the Security Configuration Tool Set

The SCTS is both a set of Microsoft Management Console (MMC) snap-ins and a command-line
tool, and it provides a centralized interface for configuring the core security of your Win2K
computers. It allows you to simplify managing security in your enterprise and perform basic
security audits as required.
SCTS Background
While the SCTS feels like a brand-new component introduced with Win2K, it really has its roots
in the Security Configuration Manager (SCM), which was released as an add-on in Windows NT
4.0 Service Pack 4 (SP4).
NT 4.0 provides an adequate number of tools for a security administrator to configure the
multitude of security settings available for a computer. You can use tools like the registry
editors, Windows Explorer, and the User Manager to configure different facets of a computers
security. While these and other applications do the job, theyre cumbersome because you must
open three, four, or even more tools to configure the security settings you want on a single
computer. In addition to being cumbersome, security configuration in NT 4.0 doesnt allow you
to perform any real security audit or analysis. Realistically, the only tool you can use to monitor
the security of your environment was the Event Viewer.
Recognizing these security-administration issues, Microsoft designed one mechanism that pulled
together the diverse functionality required to appropriately configure and analyze the security
configurations of a Win2K computer. Microsoft also ensured that the SCTS was comprehensive,
flexible, extensible, and easy to use.

197

Chapter 7

SCTS Features
The SCTS is designed to handle security settings for individual security services directly. Instead
of using command-line tools and other security-configuration mechanisms, you can use one selfcontained set of tools that provides an infrastructure for configuring and analyzing the security
settings for a diverse set of security services. But what really sets the SCTS apart from its
predecessor is its ability to combine its functionality with Group Policy Objects (GPOs) to
centrally define and automatically apply security policies throughout your enterprise.
The SCTS isnt a silver bullet that will help you manage all of the security configurations of your
enterprise. However, it does allow you to configure and analyze the more critical security areas
of your Win2K infrastructure:

Account policiesAllows you to configure password policy, account lockout policy,

and Kerberos policy.

Local policiesAllows you to configure audit policy, user rights assignments, and
security options.

Event logsAllows you to configure the settings for the main Event Viewer logs
(Application, System, and Security).

Restricted groupsAllows you to explicitly define the membership of security groups

that you consider sensitive.

System servicesAllows you to specify the configuration of installed services on the

computers in your environment, including access control and startup options.

RegistryAllows you to specify security and audit configurations for registry values.

File systemAllows you to specify security and audit configurations for folders and
files.

SCTS Architecture
As shown below in Figure 7.1, the SCTS is made up of six major components.

198

Chapter 7

Figure 7.1: The architecture of SCTS.

The core of the architecture is the configuration and analysis engine. This engine carries out the
real work of the SCTS, and you can extend it by writing custom service attachment engines. The
engine uses both security-configuration templates and security database files to specify the
security configurations that are to be configured or analyzed.
On top of the core engine, an MMC snap-in provides a graphical user interface (GUI) for
administrators. This GUI can be extended using extension snap-ins for the service attachment
engines. These extensions provide the flexibility and extensibility of this architecture. If a third
party writes an application for Win2K, it can write a pair of extensions that plug into the SCTS.
The service attachment engine interprets configuration information and makes the actual
security-configuration changes; the extension snap-in provides the MMC GUI that you use to
configure things.
The SCTS wasnt designed to replace all of the system tools that you might use to address different
aspects of system securitysuch as the Active Directory Users and Computers MMC snap-in,
Services snap-in, Access Control List (ACL) editor, and so forth. Instead, it complements these other
tools by defining a singular engine that can interpret a standard configuration file and automatically
perform the required security-configuration operations. As a result, you can use the other tools to
change individual security settings whenever necessary.

199

Chapter 7

Using Security Templates

As Ive described, the SCTS is predicated on using something known as security templates.
Security templates are one of the most practical additions to Win2K and one that you need to
fully understand to manage a uniform security deployment in your environment. Think of a
security template as a collection of canned security settings. You can import security templates
into a GPO for simplified deployment throughout your environment, or you can use them to
configure and examine the security policy of one of your local computers.
Security templates are implemented as text-based files that carry the .inf extension. They allow
you to configure all the security attributes of a GPO except public key and IP security policies.
(In this chapter, Ill discuss the appropriate settings for these configuration options. If you have
any questions about what a configuration option does, refer to Chapter 3, in which I talked about
the available security settings of a GPO.) A portion of a security template is shown below in
Listing 7.1.
[version]
signature="$CHICAGO$"
revision=1
[System Access]
MinimumPasswordAge = 2
MaximumPasswordAge = 42
MinimumPasswordLength = 8
PasswordComplexity = 1
PasswordHistorySize = 24
RequireLogonToChangePassword = 0
ClearTextPassword = 0
[Registry Values]
MACHINE\System\CurrentControlSet\Control\Lsa\AuditBaseObjects=4,0
MACHINE\System\CurrentControlSet\Control\Lsa\CrashOnAuditFail=4,0
MACHINE\System\CurrentControlSet\Control\Lsa\FullPrivilegeAuditing=3,0
MACHINE\System\CurrentControlSet\Control\Lsa\LmCompatibilityLevel=4,2
MACHINE\System\CurrentControlSet\Control\Lsa\RestrictAnonymous=4,1
[Group Membership]
Power Users__Memberof =
Power Users__Members =
[Service General Setting]
Browser,2,"D:(A;;CCLCSWLOCRRC;;;AU)(A;;CCLCSWRPLOCRRC;;;PU)(A;;CCDCLCSW
RPWPDTLOCRSDRCWDWO;;;BA)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;SO)(A;;CCLCSWR
PWPDTLOCRRC;;;SY)S:(AU;FA;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;WD)"
[Registry Keys]
"MACHINE\Software",2,"D:P(A;CI;GR;;;BU)(A;CI;GRGWSD;;;PU)(A;CI;GA;;;BA)
(A;CI;GA;;;SY)(A;CI;GA;;;CO)(A;CI;GRGWSD;;;S-1-5-13)"
[File Security]
"c:\boot.ini",2,"D:P(A;;GRGX;;;PU)(A;;GA;;;BA)(A;;GA;;;SY)"

Listing 7.1: A sample security template.

200

Chapter 7
As you can see from this listing, portions of a security template are straightforward and easy to
read, while others are quite a bit more complicated. To ease the burden of maintaining security
templates, Win2K ships with the Security Templates MMC snap-in. Ill discuss this snap-in later
(see Using the Security Templates MMC Snap-In), but for now, just keep in mind that while
you can use a text editor with security templates, there is a better way.
Predefined Security Templates
Win2K ships with a number of predefined security templates, which fall into four categories.

DefaultUsed during a clean installation of Win2K.

BasicUpdate the security of computers upgraded to Win2K.

IncrementalProvide different examples of how security can be configured on your

computers.

MiscellaneousDont fit into the other categories.

The first three types build on one another, while the fourth rounds out the useful templates, as
shown in Figure 7.2.

Figure 7.2: The four types of predefined security templates and how they relate to one another.

Lets take a closer look at these templates and how you might use them in your environment.

201

Chapter 7

Default Security Templates

The first type of predefined templates are default security templates, and theyre used when you
install and configure Win2K. For example, theyre used automatically on new Win2K systems
that are clean-installed on an NT file system (NTFS) partition. Its important to understand that
default templates are applied only to fresh NTFS installs because security templates arent
applied when you upgrade a computer from an NT 4.0 (or earlier) system or format the system
partition as a file allocation table (FAT) volume. In addition to setting up the default security of a
freshly installed computer, a predefined template modifies the security configuration of a
computer that is promoted to a domain controller.
You can look at which templates were used during installation and domain controller promotion
by analyzing the setup security log files that are stored in %Systemroot%\Security\Logs. After
you install a new Win2K computer, you should see the Scesetup.log file; it documents which
security template was used when the computer was installed. You should also see the
Scedcpro.log file, which documents which security template was used when the computer was
promoted. Looking at these logs across your workstations, servers, and promoted domain
controllers will show you that there are three default security templates that ship with Win2K.
Installed in the %Systemroot%\Inf folder, they are:

Defltwk.infThe default workstation security template.

Defltsv.infThe default server security template.

Defltdc.infThe default domain controller promotion security template.

Basic Security Templates

The second type of predefined template is basic security templates. They provide the basic
security settings that can be applied to upgraded Win2K computers to achieve a security posture
similar to that of a clean-installed Win2K computer. These security templates are identical to
default security templates except that they dont modify the existing user rights and group
memberships of the computer. Installed in the %Systemroot%\Security\Templates folder, the
three basic security templates are:

Basicwk.infThe basic workstation security template.

Basicsv.infThe default server security template.

Basicdc.infThe default domain controller promotion security template.

Because default security settings arent applied to computers that you upgrade, I highly recommend
that you perform a wipe and load for all computers that you plan to upgrade to Win2K. In instances
where this isnt practical or even possible, apply the appropriate basic predefined security template to
the newly upgraded computer to ensure that its security settings are consistent with the other
computers in your environment. For upgraded domain controllers, you need to apply two basic
security templates to achieve the same result as if you were to install the domain controller fresh and
promote itnamely, the Basicsv.inf and Basicdc.inf security templates, in that order.

202

Chapter 7
Incremental Security Templates
The third type of predefined template is incremental security templates. Theyre incremental in
the sense that they were designed to be applied only to Win2K computers that have already been
configured with the default security settings (which are applied on a fresh install). These security
templates provide incremental security changes to the default base security and dont include the
default security settings plus the new modifications. The five incremental security templates are
installed in the %Systemroot%\Security\Templates folder along with the basic security templates
and are:

Compatws.infRelaxes the ACLs for the Users security group so that theyre
compatible with those of NT 4.0 workstations. Because the default permissions of Win2K
have been considerably tightened over those configured in NT 4.0, many non-certified,
legacy applications may not function properly when installed under Win2K and run by a
normal, non-privileged user.
In order for these types of applications to function properly, you may need to place your
users in the Power Users group or relax the permissions of your installation. Relaxing
permissions is exactly what this compatibility security template accomplishes, and it has
been provided for administrators who dont want to put their end users in the Power
Users security group. Using this security template isnt secure, however, and I highly
recommend that you dont use it.

Securedc.inf and Securews.infIncrease the security of a computer by strengthening

certain settings that werent tightened by the default security templates. Securedc.inf is
intended to be applied to domain controllers, while Securews.inf is intended for use on
both workstations and member servers. This template modifies things like account
policies, auditing, and some security-minded Registry settings, but it doesnt modify
ACLs because theyre assumed to be properly set by the default security templates
applied during installation.

Hisecdc.inf and Hisecws.infIncrease the security of a computer beyond the settings of

the Securedc.inf and Securews.inf templates to a level that inhibits communication with
legacy operating systems (OSs). The security changes made by these templates configure
network communications to be digitally signed and encrypted at a level that is available
only to Win2K computers. As a result, you should use these security templates only in a
pure Win2K environment and apply them to all of the computers in your enterprise.
These templates also change the permissions assigned to the Power Users group to be
consistent with those assigned to the Users security group. Thus, using these templates
leaves you with only two types of end users: Users and Administrators.

203

Chapter 7

Miscellaneous Security Templates

The final type of predefined template doesnt fit into any of the other categories, and its aptly
grouped together as miscellaneous security templates. Once again, you can find the following
security templates in the %Systemroot%\Security\Templates folder:

Ocfiless.inf and Ocfilesw.infDefine security settings for all of the files associated with
the optional components that might be installed on a Win2K server (Ocfiless.inf) or
workstation (Ocfilesw.inf). These settings are stored separately because the optional
component files specified in these templates may or may not be installed during or after a
Win2K computer has been set up. Using these templates in your environment may
generate a large number of warning messages. The reason for this is that depending on
the optional components installed, many of the files that have security settings specified
may not exist on the computer.

Setup security.infDefines all of the security settings found in the default security
settings for the computer.

A Word of Caution
Predefined security templates can provide a basis for creating an appropriate security
configuration for your environment. Ill talk more about how to do this later in this chapter (see
Implementing Security Configuration), but because these templates modify the security
settings of your computers, I caution against blindly applying them to your environment. Before
using them, I recommend that you test them in an appropriate test environment to ensure that
they dont adversely affect your production environment. This is especially important if you
want to use the high-security templates. They configure many operational settings to extreme
values without regard for performance, operational ease of use, or connectivity with clients using
third-party or earlier versions of NT LAN Manager (NTLM).
How Security Templates Relate to Security Databases and Policies
As youll recall from my discussion of the overall SCTS architecture (see Its Architecture
earlier in this chapter), the configuration and analysis engine uses both security templates and
security databases. When you want to manipulate the security-configuration information used by
the SCTS, you interact with the security templates. When the SCTS needs to configure or
analyze the security of a computer, it interacts with a security database (.sdb file). This is
because the configuration and analysis engine is driven from a security database and not the
security templates that you and I manipulate.
As a result, to use the security configurations defined in a security template, you must have
imported them into a security database. You can use the Security Editor command-line tool and
the Security Configuration and Analysis MMC snap-in to create a security database and import
one or more security templates. Using the snap-in, you can manipulate a security database
directly, then export the complete database into a security template.

204

Chapter 7
The notion of a security database really starts to make sense once you know that there is one
special database on each and every system. The local security policy of each Win2K computer is
stored in a security database called %Systemroot%\Security\Database\Secedit.sdb. As you can
see, security templates are used to create security databases; security databases are in turn used to
implement security policy for the local computer.

Using the Security Templates MMC Snap-In

Because security templates are implemented as text files, you can easily copy, paste, import, and
export template attributes using your favorite text editor. Editing them using a text editor like the
Security Editor can become tedious, however, so doing anything more than simple cut-and-paste
operations is prone to error, and you could find yourself with an inoperative security template.
As a result, youll probably find it much easier to use the Security Templates MMC snap-in to
create and edit security templates. Its shown below in Figure 7.3.

Figure 7.3: Using the Security Templates snap-in.

Unlike many MMC snap-ins that you can run by choosing Start>Programs>Administrative
Tools, you have to load the Security Templates snap-in directly from MMC. To load the Security
Templates snap-in:
1. Choose Start>Run. In the Run dialog box, type MMC.
2. In MMC, choose Console>Add/Remove Snap-In.
3. In the Add/Remove Snap-In dialog box, click Add.
4. In the Add Standalone Snap-In dialog box, select the Security Templates option and click

Add to select the snap-in. Then click Close.

5. Click OK to close the Add/Remove Snap-In dialog box.

205

Chapter 7
By default, the Security Templates snap-in lists all of the security templates defined in the
%Systemroot%\Security\Templates folder. You can enumerate these templates by expanding the
Security Templates node, then expanding the folder path node. You can add other folders to the
list of shown security templates by right-clicking the Security Templates node and choosing New
Menu Search Path from the shortcut menu. This allows you to more easily manage your custom
security templates and store them in a folder distinct from the predefined security templates.
To create a new template in one of your security template search paths, right-click the folder
node where you want to create the new template, then choose New Template from the shortcut
menu. You can save or delete a template in a similar fashion: Right-click the security template
name node, then choose the appropriate option from the shortcut menu.
Configuring Security Settings
Using the Security Templates snap-in, you can configure security settings for account policies,
local policies, the Event Log, restricted groups, system services, Registry security, and file
system security.
Account Policies
Configuring account policies in a security template is pretty straightforward. First expand the
Account Policies node of the security template you want to configure. This gives you access to
the security templates Password Policy, Account Lockout Policy, and Kerberos Policy settings.
Select a node, then double-click the configuration setting you want. For example, selecting
Password Policy displays six security-configuration options. When you double-click Minimum
Password Length, its configuration dialog box appears, as shown below in Figure 7.4.

Figure 7.4: Configuring minimum password length.

206

Chapter 7

Local Policies
You configure local policy settings in a security template in the same manner as you configure
account policies. You first expand the Local Policies node of the security template that you want
to configure. This gives you access to the Audit Policy, User Rights Assignment, and Security
Options settings of the security template. Select a node, then double-click the configuration
setting you want to modify. For example, selecting User Rights Assignment displays all of the
available user rights. Double-clicking Create a Pagefile displays its configuration dialog box,
shown below in Figure 7.5.

Figure 7.5: Configuring the Create a Pagefile user right.

This example illustrates something that may not be obvious at first glance. When you modify the
configuration options of a security template, youre restricted to items that are available on the
computer where the security template is being managed. In the example above, you can assign
user rights to users and security groups. When you click Add, you can select the user accounts
and security groups to which you have access.
As a result, you need to configure options such as this to only include well-known security
identifiers (SIDs)or you have to construct the security template in the environment that holds
the users and groups you want to use. This means that if you want to use some of the security
groups that are defined in your production forest, you have to create the security template on a
computer in the forest to ensure that the correct user and group SIDs are contained in the security
template.

207

Chapter 7
Event Log Settings
You configure Event Log settings in a security template in the same way as the settings
discussed above. When you expand the Event Log node, you have access to the Event Log
settings of the security template. Select a setting, then double-click the configuration setting you
want to modify. One is the Retention Method for Application Log, whose configuration dialog
box is shown below in Figure 7.6.

Figure 7.6: Configuring the Retention Method for Application Log.

Configuring this Event Log setting brings up another aspect of configuring security templates
using the Security Templates snap-in. For example, lets say that you create a new, and hence
blank, security template for editing, then define the security setting for Retention Method for
Application Log as shown aboveOverwrite Events by Days. If you havent configured any
other Event Log setting in the security template, when you click OK, the snap-in evaluates the
value you specified and determines whether it has any dependencies on, or from, other settings.
In this example, the snap-in recognizes that to overwrite events by days, you must also configure
how many days to retain the Event Log. As a result, the snap-in displays the Suggested Value
Changes dialog box (shown below in Figure 7.7), where you can specify the number of days.

208

Chapter 7

Figure 7.7: Configuring how many days to retain the Event Log.

Restricted Groups
Configuring restricted groups in a security template allows you to define the members of a
security group. By defining who should be a member of a group, you inherently define that
everyone else isnt a member of the group. To configure restricted groups, you right-click the
Restricted Groups node, then choose Add Group from the shortcut menu. From here, you can
select the group whose membership you want to restrict. This adds that group to the list of
groups whose membership is managed by this security setting. You can define both the members
of the group and the groups to which the restricted security group belongs. This is shown below
in Figure 7.8.

Figure 7.8: Configuring restricted groups.

209

Chapter 7
The restricted group policy shown in this figure allows only the computer-local Administrator
account (PINEVALLEY\Administrator) and the domain-level Workstation Administrators
security group (CYBER\Workstation Administrators) to be members of the local Administrators
security group. If this template were applied to a computer, the SCTS would remove all of the
other users that belong to the local Administrators security group that arent defined above. In
addition, if any of the specified group members arent yet members of the Administrators
security group, theyre automatically added.
Typically, you use restricted groups for security groups that have greater privileges than standard
users. For example, you can use restricted groups to restrict membership in your Domain
Administrators, Backup Users, and other privileged security groups so that you can ensure who
has, and thus doesnt have, access to elevated security privileges.
System Services
Configuring the system services settings in a security template allows you to define the startup
mode and access control settings for system services such as Server, Workstation, and Internet
Information Services (IIS). To configure system services, click the System Services node and
select from the list of services that can be configured. Figure 7.9 below shows configuring the
startup option and the access control settings for Telnet.

Figure 7.9: Configuring the Telnet service.

As mentioned earlier, the configuration of the computer on which you create a template affects
which items are available for configuration. For example, if you want to configure the startup
options for the DNS Server service, you need to ensure that the DNS Server service is running on
the computer on which youre modifying the security template.

210

Chapter 7

If you need to configure a system service in a security template that isnt available on your local
computer, either you need access to a computer that is running the service, or you need to edit the
security template using a text editor. While the latter is fine in simple situations, I recommend using
the former to ensure that your security template is correct and has the desired behavior.

Registry Security
Configuring Registry security in a security template allows you to define the access control,
audit, and owner settings for Registry keys. To configure Registry security, right-click the
Registry node and choose Add Key from the shortcut menu. In the Select Registry Key dialog
box, shown below in Figure 7.10, select the Registry key whose security settings you want to
configure.

Figure 7.10: Selecting a Registry key to configure.

For each key you add to the security template, you can specify the access control, audit, and
owner settings using the standard Win2K ACL editor. (If you need a refresher, I discussed
configuring these settings in Chapters 5 and 6.) Once you do, the Template Security Policy
Setting dialog box appears, shown below in Figure 7.11. It allows you to configure inheritance
on the configured objects children based on the security settings youve selected.

211

Chapter 7

Figure 7.11: Configuring the inheritance and replacement of permissions.

Here is an explanation of these three options and what they allow you to specify.

Propagate Inheritable Permissions to All SubkeysPropagates inheritable

permissions as normal. This option uses the standard Win2K ACL inheritance rules:
Child objects modify their security settings according to the inherited permissions from
the specified object (that is, the parent object). In addition, any explicit ACEs that are
explicitly defined on child objects arent modified.

Replace Existing Permissions on All Subkeys with Inheritable Permissions

Removes explicit ACEs and propagates inheritable permissions. This option removes the
explicit ACEs that are explicitly defined on child objects. All of the child objects are then
reconfigured to inherit the inheritable permissions as defined on the specified object.

Do Not Allow Permissions on This Key to Be ReplacedDont inherit permissions

from a parent object. This option allows you to add a Registry key whose security
settings you dont want to change. As a result of applying the security template, the
objects inheritance mode and the entries of its explicit ACEs remain unchanged. You
configure an object in this manner only if a parent object is configured to overwrite the
settings of its children. If the object has no parent configured in the template, this option
wont affect the final security settings. If a parent does exist in the template but is
configured to only propagate inheritable permissions, this option also has no effect.

212

Chapter 7

File System Security

By configuring file system security in a security template, you can define the access control,
audit, and owner settings for the files and folders of a system. To configure file system security,
right-click the File System node and choose Add File from the shortcut menu. In the Add a File
or Folder dialog box, shown below in Figure 7.12, select the file or folder whose security settings
you want to configure.

Figure 7.12: Configuring security for a file or folder.

Once you select the file or folder you want, the procedure and options are the same as for
configuring Registry key security settings. (See Registry Security above.) You can set the
access control, audit, and owner settings using the standard Win2K ACL dialog editor, and you
can set the inheritance options for the file or folder security settings.

Using the Security Configuration and Analysis MMC Snap-In

The Security Configuration and Analysis MMC snap-in allows you to import, analyze, configure,
and export the security configurations for the computers in your environment. Although its
implemented as a snap-in, the console tool actually performs no processing and acts only as a
GUI to the SCTS configuration and analysis engine. Like the Security Templates snap-in, you
cant open the snap-in by choosing Start>Programs>Administrative Tools. Instead, you have to
load the console from within MMC. (Follow the instructions in Using the Security Templates
MMC Snap-In earlier in this chapter.) The console is shown below in Figure 7.13.

213

Chapter 7

Figure 7.13: Using the Security Configuration and Analysis snap-in.

The main purpose of the Security Configuration and Analysis snap-in is to give administrators a
simple mechanism for loading security configurations into a computer and analyzing the system
for discrepancies between the loaded security configurations and the actual system settings. By
analyzing the security on your computers, you can identify three important things:

Configuration weaknesses in your current security policies

Current deviations in the security configuration of your environment before deploying a

new security policy

Unauthorized changes to the security of previously configured systems.

Because the SCTS is driven from the contents of a security database, the first thing you need to
do is open or create a security database. As shown in the figure above, the console gives you
instructions on how to proceed. Overall, creating a security database is pretty simple. One thing
to note, though, is that by default, its created in the \Security\Database subfolder of your home
directory. When you create a new security database, youre asked to specify the security template
to be used to initialize the security database.
Once you open or create a security database, you can either configure or analyze the security
settings of the computer. Once again, the console provides the necessary instructions; this is
shown below in Figure 7.14.

214

Chapter 7

Figure 7.14: Instructions for configuring and analyzing the security settings of a computer.

Analyzing the Security of a Computer

To begin, I highly recommend that you get acquainted with the console by analyzing the
computers security. This security analysis compares the current state of the computer against the
contents of the security database. The console runs the SCTS configuration and analysis engine
to query each security setting that the tool set covers. If the current settings of the computer are
identical to those contained in the security database, the security settings are assumed to be
correct. If there is a mismatch, however, the settings are flagged as problems that need your
attention.
To analyze the computers security, right-click the Security Configuration and Analysis node,
then choose Analyze Security Now from the shortcut menu. Youre then prompted to provide the
location for a log file that the analysis will create. This log file is the same as the log file created
when you use the Security Editor. (See Using the Security Editor later in this chapter.)
Once you provide the location of the log file, a dialog box like that shown below in Figure 7.15
displays the progress of the security analysis.

215

Chapter 7

Figure 7.15: Viewing the progress of the security analysis.

When the security analysis is completed, the security areas are displayed, as seen below in
Figure 7.16. These are the same security areas that you saw in the discussion of the Security
Templates snap-in. As you drill down through the configurations to the leaf nodes, youll notice
that for each security configuration, youre given three pieces of information:

A visual clue to the conformance of the security setting

The security setting contained in the database

The current security setting on the computer.

Figure 7.16: Viewing the results of the security analysis.

216

Chapter 7
To indicate how the security settings on the computer equate with the security settings defined in
the security database, the right-hand pane of the console uses three icons, superimposed over the
security setting icon. These three icons are explained below (and examples are shown in the
figure above).

Small, green check markThe value of the security setting on the computer matches
the value in the security database.

Small, red circle with a white crossThe value of the security setting on the computer
doesnt match the value in the security database.

No iconThere is no security setting in the security database.

The right-hand pane of the console also displays the security settings in the security database and
the settings on the computer. This information is important because it gives you a complete view
of not only what settings arent in conformance with your security policy but also what they are
and should be set to. You wont find this information in the log file created after analyzing the
security on the computer (although it lists the configuration mismatches) or in the log file created
when you use the Security Editor. As a result, the Security Configuration and Analysis snap-in
can be a better tool when youre first preparing the security templates for your environment.
Configuring the Security of a Computer
Once you have a good handle on how the console works and have analyzed the security of a
computer in your environment, its time to configure security. This configures a computer with
the security settings contained in the security database. The console starts up the SCTS
configuration and analysis engine to perform the work, while the console GUI provides a
shortcut menu, similar to the analysis shortcut menu, which shows you the tools progress.
Just as you did to analyze security, right-click the Security Configuration and Analysis node.
Choose Configure Computer Now from the shortcut menu, then type the name of a log file for
the operation.
The changes made to the local computer are actually made to the local security policy. This is
important to understand. For example, lets say that youre configuring the security settings for a
stand-alone computer using the Security Configuration and Analysis snap-in. Because the tool
modifies the local security policy, your new settings will be used by the computer.
Now consider what happens when the computer is part of a domain and is subject to the
application of GPOs. Your changes to the local security policy may be overridden by security
settings that are applied as a result of a GPO being assigned to the computer. As a result, just
because you configure a computer using this console tool, the settings may not become effective.
If this doesnt make sense, I highly recommend that you reread the section of Chapter 3 in which
I discuss GPOs and how theyre processed in a domain environment.

217

Chapter 7

Using the Security Editor

You can use the Security Editor (secedit.exe), a command-line tool, to analyze, configure,
refresh, export, and validate security configurations for computers in your environment. In this
manner, its a lot like the Security Configuration and Analysis snap-in, but it offers a couple of
extra features that enhance your ability to manage the security of your environment. This tool is
extremely beneficial as you develop and troubleshoot the security-configuration settings in your
infrastructure, so its important that you get to know it well. The options that the command uses,
and its syntax, are listed below in Table 7.1.
This Option

Does This

Using This Syntax

/analyze

Analyzes the active

system security settings.

secedit /analyze [/DB filename] [/CFG

filename] [/log logpath] [/verbose]
[/quiet]

/configure

Configures system
security by applying a
stored security template.

secedit /configure /DB filename [/CFG

filename] [/overwrite] [/areas area1
area2] [/log logpath] [/verbose]
[/quiet]

/refreshpolicy

Refreshes security
settings by reapplying the
relevant GPOs.

secedit /refreshpolicy {machinepolicy

| user_policy} [/enforce]

/export

Exports the settings from

a security database into a
security template file.

secedit /export /CFG filename

[/mergedPolicy] [/DB filename] [/areas
area1 area2] [/log logpath] [/verbose]
[/quiet]

/validate

Validates the syntax of a

security template.

secedit /validate filename

Table 7.1: The options and syntax used by the Secedit command.

When you either configure security or export a computers security configuration, you can use
the Areas flag to specify which security areas you want to affect, as shown below in Table 7.2.
By default, the Security Editor configures and exports security settings for all areas, but you can
target these operations to a limited number of security template settings. When you use the Areas
flag, remember to separate each area you specify with a single space.
This Area

Maps to This Snap-In

SECURITYPOLICY

Account Policies
Local Policies\Audit Policy
Local Policies\Security Options
Event Log

USER_RIGHTS

Login Policies\User Rights Assignments

GROUP_MGMT

Restricted Groups

SERVICES

System Services

REGKEYS

Registry

FILESTORE

File System

Table 7.2: Mapping areas of the Security Editor to settings in the security template.

218

Chapter 7
Advantages Over the Security Configuration and Analysis Snap-In
While the Security Editor performs the same analysis and configuration functions as the Security
Configuration and Analysis snap-in, its command-line implementation and added features make
it more versatile and useful. For example, lets say you want to analyze the security settings of a
large number of computers. While you can do this using either tool on each computer, the
Security Editor is easier to use because you can call it from a batch file or an automatic task
scheduler to automatically create a security analysis log for each computer.
The Security Editors extra features also make it more useful than the Security Configuration and
Analysis snap-in. In particular, the ability to export and validate security templates is an
extremely valuable feature when youre in the midst of developing the appropriate set of security
settings for your environment. For example, you may have spent some time getting the security
configuration of a computer just the way you want it. Using the Security Editors Export
command, you can extract the security configuration from that configured computer and apply it
to other computers in your environment.
Another useful feature of the Security Editor is its ability to force a refresh of all GPOs that are
appropriate for a computer. By default, GPO propagation occurs whenever the computer starts
up, then every 60 to 90 minutes after that.
Analyzing Security in Your Environment
You can also use the Security Editor to analyze computers for settings that violate your security
policy. By taking advantage of the tools command-line functionality, you can easily run a script
to search for security violations across your entire enterprise. I wont discuss how to best run a
script across a number of computers because thats outside the scope of this section, but Ill
discuss very quickly how you can automate your security analysis.
To effectively analyze a computer for discrepancies in its security configuration, you must first
make sure that you know what the correct security configuration is. You can then implement this
configuration into a security template. For example, lets assume that there should be only two
members of the Administrators security group on the workstations in your enterprisethe local
Administrator account and the domain-level Workstation Administrators security group. Lets
assume, too, that youve appropriately implemented the template that sets the Administrators
security membership and named it SecureGroup.inf. Then type the following command:
secedit /configure /db SecureGroup.sdb /cfg SecureGroup.inf
/overwrite

When you run this command, you can be assured that the membership of the Administrators
group is as its set in the security template. In addition, running this command produces a
security database file that you can use during the analysis stage to come. But before analyzing
the security that you know is correct, type the following command to alter the membership of the
local Administrators security group:
net localgroup administrators everyone /add

219

Chapter 7
This command adds the Everyone group to the local Administrators security group. Clearly, this
is something that you wouldnt ever want to happen in your environment! To catch this security
policy violation, you need to perform a security analysis using the security database you just
created. To do this, type the following command:
secedit /analyze /db SecureGroup.sdb /log SecurityResults.log
/verbose

The analysis results are placed in the log file created by the previous command. The best way to
find them is using the Grep command-line tool. If you dont have this tool on your computer,
youll find it in the Resource Kit for the UNIX tools. (These tools are located in the Apps\Posix
directory of the Resource Kit CD-ROM.) You can parse the log file to find all of the security
policy violations using the following command:
grep Mismatch SecurityResults.log

After you run this command, the Administrators group should be flagged as having a mismatch.
There may also be a number of mismatches on some Registry values, but theyre no cause for
concern.
Running the Grep command highlights one of the differences between the Security Configuration and
Analysis snap-in and the Security Editor: While the Security Editor flags Registry values that are
configured on the computer but not in the security database, the snap-in doesnt.

Implementing Security Configuration

Its probably safe to assume that you need to implement Windows 2000 Server and Windows
2000 Professional in a number of different fashions throughout your enterprise. Its also safe to
assume that the Win2K environments that I look after are implemented differently than the ones
you look after. As a result, its impossible to tell you exactly how to implement the security
configurations for your environments. Thus, in this section, Ill present a solution for ensuring
the security configurations of a generic Win2K implementation.
Identifying the Four Basic Roles of Computers
Different Win2K installations require different security features or security controls to
adequately protect themselves from accidental or malicious breaches of security policy. While
each Win2K environment has different specific security challenges, there are a few fundamental
roles that the computers in the environment must play. For our purposes, I propose that a generic
view of your environment will show that you have four basic types of computers, each requiring
different levels of security configuration.

Domain controllers

Member servers

Web servers

Workstations.

220

Chapter 7
One could argue that a Web server is a specialized function of a member server, but I think that
the security risks involved in running IIS on a computer warrant a special classification. I wont
discuss the security configuration of a Web server here; I devote all of Chapter 10 to the topic.
Lets take a look at the other three basic roles.
Domain Controllers
Domain controllers in a Win2K environment play two basic roles:

They authenticate security principals

They grant security principals access to resources in the domain.

As a result, domain controllers are responsible for hosting both Active Directory (AD) and the
Kerberos Key Distribution Center (KDC). As a general rule, domain controllers shouldnt be
running any other services except those explicitly required to allow the server to fulfill its role in
the infrastructure. Domain controllers contain the most sensitive information for your Win2K
environment and shouldnt be carelessly compromised by a security vulnerability in an
unnecessary service or application. Access to domain controllers should be restricted to the
fewest number of administrators that your organization can tolerate.
Member Servers
Member servers are the workhorses of any Win2K environment. Theyre called on to host
applications, provide file and print services, host databases, host mail services, and provide a
multitude of other infrastructure services. As a result, member servers by definition have to run a
variety of disparate services and applications to function in your environment. However, to
ensure that your environment is kept secure, they should share a common set of security
configurations. Your typical users should never need to use member servers in an interactive
fashion, and console access should be restricted to administrative personnel. In addition, member
servers should be restricted from using local computer accounts and use domain accounts
whenever possible.
Workstations
Workstations in a Win2K environment are the standard computers running the Windows 2000
Professional version of the OS on the desktops of all of the users in your environment. To take
advantage of domain authentication, all workstations should be members of a domain in your
Win2K forest. As a result, user authentication from all workstations should occur on your
domain controllers. Once users are authenticated to the domain, access to the local computer
should be severely restricted, and no local user accounts should be created beyond the built-in
administrators and guest accounts. In addition, your users should never be added to the local
Administrators security group.

221

Chapter 7

Restructuring Roles
While the three basic roles played by the computers in your environmentdomain controllers,
member servers, and workstationssuffice for our purposes, you may find that you need to
restructure them. For example, to adequately model the security configurations for your
computers, you may need to break apart the member servers role into a variety of roles
servers, file servers, database servers, mail servers, and remote access servers.
There are a number of ways that you can slice the functionality of your Win2K environment. But
the idea is to break out the functionality on computers based on common security and
functionality concerns. Obviously, operational issues and cost constraints will sometimes require
you to combine the roles of two sets of functionality onto a single computer, but the notion of
separate roles for separate computers can make security configuration in your environment much
easier to deploy.
Identifying the Fourth RoleOverall Domain Security
Regardless of the other roles you require in your environment, there will always be a core set of
security settings that is constant on all of the computers in your environment. It doesnt make
sense to replicate these common settings across multiple security-configuration mechanisms. As
a result, in addition to the three roles above, its valuable to create a fourth roleoverall domain
security.
Defining Security Settings
Identifying the roles of the computers in your Win2K environment greatly simplifies the exercise
of determining their security configurations. Based on the discussion so far, Ive identified four
sets of configuration settings that need to be defined.

Domain security policy

Domain controller security policy

Member server security policy

Workstation security policy.

By defining the roles in this fashion, if a security setting is configured in the domain security
policy, it isnt necessary to configure it in one of the computer-role policies. However, if the
setting isnt configured in the domain security policy, you need in most circumstances to
configure it in each computer-role policy.
The settings specified in the following subsections assume a homogeneous Win2K environment and
a strict security posture. As a result, they may not be the best security settings for your environment. I
strongly urge you to thoroughly test these and any other potential security settings that youre
contemplating in a development Win2K forest before deploying them in your production
environments.

222

Chapter 7

For Account Policy

I recommend that you start with the account policy settings shown below in Table 7.3.
Security Setting

Domain
Security
Policy

Domain
Controller
Security
Policy

Member
Server
Security
Policy

Workstation
Security
Policy

Password Policy\Enforce password history

18

N/A

N/A

N/A

Password Policy\Maximum password age

42

N/A

N/A

N/A

Password Policy\Minimum password age

N/A

N/A

N/A

Password Policy\Minimum password length

N/A

N/A

N/A

Password Policy\Passwords must meet

complexity requirements

Enabled

N/A

N/A

N/A

Password Policy\Store password using

reversible encryption for all users in the
domain

Disabled

N/A

N/A

N/A

Account Lockout Policy\Account lockout

duration

N/A

N/A

N/A

Account Lockout Policy\Account lockout

threshold

N/A

N/A

N/A

Account Lockout Policy\Reset account

lockout counter after

30

N/A

N/A

N/A

Kerberos Policy\Enforce user logon

restrictions

N/A

Enabled

N/A

N/A

Kerberos Policy\Maximum lifetime for service

ticket

N/A

60

N/A

N/A

Kerberos Policy\Maximum lifetime for user

ticket

N/A

N/A

N/A

Kerberos Policy\Maximum lifetime for user

ticket renewal

N/A

10

N/A

N/A

Kerberos Policy\Maximum tolerance for

computer clock synchronization

N/A

N/A

N/A

Table 7.3: Recommended account policy settings by computer role.

For Local Policies

I recommend that you start with the local policy settings shown below in Table 7.4. An obvious
omission from the table are settings for user rights assignments. While Ive made some
recommendations in previous chapters, you must be very careful how you assign these privileges
in your environment. Ive seen user rights assignments built into security templates and applied
to computers with great success, but the exact assignments depend too much on your specific
environment for me to make generalized recommendations here.

223

Chapter 7
Security Setting

Domain
Security
Policy

Domain
Controller
Security
Policy

Member
Server
Security
Policy

Workstation
Security
Policy

Audit Policy\Audit account logon events

Success,
Failure

N/A

N/A

N/A

Audit Policy\Audit account management

Success,
Failure

N/A

N/A

N/A

Audit Policy\Audit directory services

access

N/A

Failure

N/A

N/A

Audit Policy\Audit logon events

Success,
Failure

N/A

N/A

N/A

Audit Policy\Audit object access

Failure

N/A

N/A

N/A

Audit Policy\Audit policy change

Success,
Failure

N/A

N/A

N/A

Audit Policy\Audit privilege use

Failure

N/A

N/A

N/A

Audit Policy\Audit process tracking

No auditing

N/A

N/A

N/A

Audit Policy\Audit system events

Success,
Failure

N/A

N/A

N/A

Security Options\Additional restrictions

for anonymous connections

No access
without explicit
anonymous
permissions

N/A

N/A

N/A

Security Options\Allow server operators

to schedule tasks

N/A

Disabled

N/A

N/A

Security Options\Allow system to be shut

down without having to log on

N/A

Disabled

Disabled

Enabled

Security Options\Allowed to eject

removable NTFS media

Administrators
and Interactive
Users

N/A

N/A

N/A

Security Options\Amount of idle time

required before disconnecting session

N/A

N/A

N/A

Security Options\Audit the access of

global system objects

Enabled

N/A

N/A

N/A

Security Options\Audit use of Backup

and Restore privilege

N/A

Enabled

Disabled

Disabled

Security Options\Automatically log users

off when logon time expires

Enabled

N/A

N/A

N/A

Security Options\Automatically log users

off when logon time expires (local)

Enabled

N/A

N/A

N/A

Security Options\Clear virtual memory

pagefile when system shuts down

Enabled

N/A

N/A

N/A

Security Options\Digitally sign client

communications (always)

Enabled

N/A

N/A

N/A

Security Options\ Digitally sign client

communications (when possible)

Enabled

N/A

N/A

N/A

Security Options\Digitally sign server

communications (always)

Enabled

N/A

N/A

N/A

224

Chapter 7
Security Setting

Domain
Security
Policy

Domain
Controller
Security
Policy

Member
Server
Security
Policy

Workstation
Security
Policy

Security Options\Digitally sign server

communications (when possible)

Enabled

N/A

N/A

N/A

Security Options\Disable
CTRL+ALT+DEL requirement for logon

Disabled

N/A

N/A

N/A

Security Options\Do not display last user

name in logon screen

N/A

Enabled

Enabled

Disabled

Security Options\LAN Manager

Authentication Level

Send NTLMv2
only/refuse LM
& NTLM

N/A

N/A

N/A

Security Options\Message text for users

attempting to log on

<your legal
message here>

N/A

N/A

N/A

Security Options\Message title for users

attempting to log on

<*WARNING*>

N/A

N/A

N/A

Security Options\Number of previous

logons to cache (in case domain
controller isnt available)

N/A

Security Options\Prevent system

maintenance of computer account
password

Disabled

N/A

N/A

N/A

Security Options\Prevent users from

installing printer drivers

N/A

Enabled

Enabled

Disabled

Security Options\Prompt user to change

password before expiration

N/A

N/A

N/A

Security Options\Recovery Console:

Allow automatic administrative logon

Disabled

N/A

N/A

N/A

Security Options\Recovery Console:

Allow floppy copy and access to all
drives and folders

Disabled

N/A

N/A

N/A

Security Options\Rename administrator

account

<renamed
administrator>

N/A

N/A

N/A

Security Options\Rename guest account

<renamed
guest>

N/A

N/A

N/A

Security Options\Restrict CD-ROM

access to locally logged-on user only

Enabled

N/A

N/A

N/A

Security Options\Restrict floppy access

to locally logged-on user

Enabled

N/A

N/A

N/A

Security Options\Secure channel:

Digitally encrypt or sign secure channel
data (always)

Enabled

N/A

N/A

N/A

Security Options\Secure channel:

Digitally encrypt secure channel data
(when possible)

Enabled

N/A

N/A

N/A

Security Options\Secure channel:

Digitally sign secure channel data (when
possible)

Enabled

N/A

N/A

N/A

225

Chapter 7
Security Setting

Domain
Security
Policy

Domain
Controller
Security
Policy

Member
Server
Security
Policy

Workstation
Security
Policy

Security Options\Secure channel:

Require strong (Win2K or later) session
key

Enabled

N/A

N/A

N/A

Security Options\Secure system partition

(for RISC platforms only)

Enabled

N/A

N/A

N/A

Security Options\Send unencrypted

password to connect to third-party SMB
servers

Disabled

N/A

N/A

N/A

Security Options\Shut down system

immediately if unable to log security
audits

Disabled

N/A

N/A

N/A

Security Options\Smart card removal

behavior

Lock
Workstation

N/A

N/A

N/A

Security Options\Strengthen default

permissions of global system objects

Enabled

N/A

N/A

N/A

Security Options\Unsigned driver

installation behavior

N/A

Do not
allow
installation

Do not
allow
installation

Warn but
allow
installation

Security Options\Unsigned non-driver

installation behavior

N/A

Do not
allow
installation

Warn but
allow
installation

Silently
succeed

Table 7.4: Recommended local policy settings by computer role.

For the Event Log

I recommend that you start with the Event Log settings shown below in Table 7.5.
Security Setting

Domain
Security
Policy

Domain
Controller
Security
Policy

Member
Server
Security
Policy

Workstation
Security
Policy

Settings for Event Logs\Maximum application

log size

N/A

10240

20480

10240

Settings for Event Logs\Maximum security

log size

N/A

20480

20480

10240

Settings for Event Logs\Maximum system log

size

N/A

20480

20480

10240

Settings for Event Logs\Restrict guest access

to application log

Enabled

N/A

N/A

N/A

Settings for Event Logs\Restrict guest access

to security log

Enabled

N/A

N/A

N/A

Settings for Event Logs\Restrict guest access

to system log

Enabled

N/A

N/A

N/A

Settings for Event Logs\Retain application

log

N/A

42

42

N/A

226

Chapter 7
Security Setting

Domain
Security
Policy

Domain
Controller
Security
Policy

Member
Server
Security
Policy

Workstation
Security
Policy

Settings for Event Logs\Retain security log

N/A

N/A

42

42

Settings for Event Logs\Retain system log

N/A

42

42

N/A

Settings for Event Logs\Retention method for

application log

N/A

By days

By days

As needed

Settings for Event Logs\Retention method for

security log

N/A

Manually

By days

By days

Settings for Event Logs\Retention method for

system log

N/A

By days

By days

As needed

Settings for Event Logs\Shut down the

computer when the security audit log is full

Disabled

N/A

N/A

N/A

Table 7.5: Recommended Event Log settings by computer role.

For Restricted Groups

Whenever possible, try to use restricted groups to ensure that the group memberships of some of
your more sensitive security groups are configured appropriately. While every environment
creates its administrative model differently, I offer the following general guidelines:

Domain controllersControl membership in the Domain Administrators, Enterprise

Administrators, DNS Admins, Schema Admins, and other privileged security groups that
have far-reaching access throughout your domains and forest. This will ensure that no unauthorized users creep into one of your privileged security groups.

WorkstationsControl membership in the local Administrators security group. This

will ensure that neither local computer accounts nor domain user accounts creep into this
privileged security group.

227

Chapter 7

For System Services

As a general rule, dont run any service on a computer that isnt crucial to the computer fulfilling
its role in the environment. At the same time, every enterprise needs to run services that are
unique to its environment, and a set of hard-and-fast rules is impossible to construct. However,
the following are some general guidelines:

Domain controllersNever run IIS, Indexing, Mail, and other services on domain
controllers. Of all the computers in your environment, domain controllers are the most
sensitive and must run the bare minimum of services. If youre in doubt about a service,
turn it off and validate that the functionality of the domain controllers is still available.
However, if you use Dynamic DNS (DDNS) in your environment, I advise against
turning off the Dynamic Host Configuration Protocol (DHCP) client. It registers the
service resource records in Domain Name System (DNS) so that computers can locate
their domain controllers!

WorkstationsNever run IIS, Indexing, and other such server services on workstations.
Remember that theyre workstations, not servers; they dont need to be all things to all
people.

For the Registry and File System

Win2K provides considerably better ACLs on both the Registry and the file system. Apart from
ensuring that the defaults dont get modified, its hard to make any general recommendations. To
ensure that things stay as they were originally installed, I suggest that you use the Registry and
file system settings from the default predefined security templates that I talked about earlier in
this chapter. (See Predefined Security Templates.)
Using Group Policy
Now that Ive recommended many of the security settings for your environment, Ill turn the
discussion to how to apply them. The answer that is most in line with the themes of this chapter
is to use either the Security Configuration and Analysis snap-in or the Security Editor. While you
could visit each and every computer and use the console tool, scripting with the command-line
tool is probably a better way to go.
An even better way to deploy these security settings is using Group Policy. I purposefully
constructed the roles above so that its relatively simple to deploy the security configurations
using GPOs. For each of the four roles that Ive defined, I recommend that you create a security
template that reflects the required settings in each of the roles. You can then create four separate
GPOs to house the settings and use security groups to filter the appropriate GPOs to the correct
computers in the environment. Once again, a complete discussion of GPOs is outside the scope
of this chapter, but if you need a refresher, I suggest you reread Chapter 3.

228

Chapter 7

Summary
The SCTS is both a set of MMC snap-ins and a command-line tool. It provides a centralized
interface for the core security configurations of your Win2K computers. It allows you to simplify
the security management of your enterprise and perform basic security audits as required. It isnt
a silver bullet that will help you manage all of the security configurations of your enterprise, but
it does allow you to configure and analyze the more critical security areas of your Win2K
infrastructure.

Account policiesAllows you to configure password policy, account lockout policy,

and Kerberos policy.

Local policiesAllows you to configure audit policy, user rights assignments, and
security options.

Event LogAllows you to configure the settings for the main Event Viewer logs
(application, system, and security).

Restricted groupsAllows you to explicitly define the membership of security groups

that you consider sensitive.

System servicesAllows you to specify the configuration of installed services on the

computers in your environment, including access control and startup options.

RegistryAllows you to specify security and audit configurations for Registry values.

File systemAllows you to specify security and audit configurations for folders and
files.

Understanding the capabilities of the SCTS and how to use it to your best advantage will go a
long way to ensuring that the security configuration of your enterprise remains not only
consistent but also just as you expect!

229

Chapter 8

Chapter 8: Public Key InfrastructurePart 1

Many organizationshopefully yours is among themhave enthusiastically embraced the
concept of the Internet as well as those of intranets and extranets. We now view these concepts
as indispensable assets for effectively conducting internal and external business. However, this
business must be conducted in a secure and trusted environment. Using public key infrastructure
(PKI), organizations can create and use a secure intranet that can be extended as necessary
outside the traditional corporate boundaries to the Internet. Well get to the specifics of a PKI
later on, but for now think of it as a digital mechanism for establishing online identities.

Recognizing Security Issues

Unfortunately, were all faced with the fundamental issue of how to secure and trust electronic
communications in an increasingly hostile information technology (IT) landscape. At the same
time, the threats to our information infrastructures continue to increase. Even using properly
deployed firewalls and access control, many of todays security issues are left unaddressed. Here
are a few examples.

An unauthorized person, such as a contractor or visitor, might gain access to a companys

computer system.

An employee or supplier authorized to use the system for one purpose might use it for
another. For example, an engineer might break into the Human Resources database to
obtain confidential salary information.

Confidential information might be intercepted as its being sent to an authorized user. For
example, an intruder might attach a network-sniffing device to the network. While
sniffers are normally used to diagnose networks, they also intercept data coming over the
wire.

Users may share documents among geographically separated offices over the Internet or
corporate extranet, or telecommuters accessing the corporate intranet from their home
computers may expose sensitive data as its sent over the wire.

Electronic mail may be intercepted in transitor even worse, be out-and-out spoofed.

These arent merely theoretical concerns but real security risks. Not only are hackers breaking
into corporate computer systems over the Internet, but corporate insiderssuch as employees,
former employees, contractors working on-site, and other suppliersare also attacking them
from within. In 1998, the Computer Security Institute of San Francisco, with the participation of
the Federal Bureau of Investigation (FBI), surveyed 520 security practitioners in American
corporations and other institutions; 44 percent reported unauthorized access by employees; 24
percent reported system penetration from the outside.

230

Chapter 8

How PKI Addresses These Issues

The security risks described above reveal the need for an information infrastructure that achieves
high levels of connectivity, communication, collaboration, and commerce in a secure fashion.
PKI addresses these vulnerabilities by providing the following security mechanisms:

AuthenticationEnsures that entities sending messages, receiving messages, and

accessing systems are who they say they are

ConfidentialityEnsures that only intended recipients can access messages

IntegrityEnsures that messages havent been altered by other parties since they were
sent

Non-repudiationEnsures the source of a message so that the sender cannot later claim
that they didnt send it.

PKI is based on the use of digital certificates. It handles the issuance and ongoing maintenance
of digital certificates and enables a wide variety of digital certificatebased applications to be
used. The following types of PKI-enabled applications provide the required security mechanisms
listed above:

Secure e-mailEnables confidential information to be shared among enterprises,

customers, employees, and partners over private and public networks

Web browsersPrevent electronic fraud such as data tampering, eavesdropping, and

masquerading

File encryptionRestricts sensitive information from unauthorized individuals using

automatic encryption and decryption of files and folders

Virtual private networks (VPNs)Exchange information over internal and public

networks with complete privacy, integrity, and user authentication for Internet remote
access, branch office internetworking (intranets), and communication with business
partners (extranets).

Microsoft understands the potential of PKI, and as a result, Windows 2000 (Win2K) provides the
foundation for you and your organization to implement a full-blown PKI solution. Not only does
Win2K come with the required software for you to be your own certificate authority (CA) and
issue digital certificates, it also includes a number of PKI-enabled security features to provide
enhanced security solutions for your enterprise.
Win2Ks built-in PKI technologies are so numerous that its impractical to talk about all of them
in a single chapter. As a result, this chapter will focus on the things you need to know to
understand the fundamentals of PKI and how to use Win2K to create your own CA
infrastructure. Chapter 9 will discuss all of the PKI-enabled applications built into Win2K.

231

Chapter 8

Understanding Cryptography
Key to understanding how PKI functions is understanding the basic cryptographic techniques
that the infrastructure is based on, namely:

Secret key cryptography

Public key cryptography

Hash functions

Digital signatures.

An in-depth discussion of these techniques is well beyond the scope of this chapter, so Ill focus
on their general properties and operation.
For a more in-depth discussion of cryptography, I recommend Applied Cryptography: Protocols,
Algorithms, and Source Code in C, 2nd Edition, by Bruce Schneier. While other books have been
written on cryptography, this one became an instant classic and is a must-read for any serious
security professional.

Secret Key Cryptography

Secret key cryptography (also known as symmetric key cryptography) is the oldest form of
cryptography; its been traced back 4,000 years to the ancient Egyptians. Using secret key
cryptography, parties involved in communications share a single secretnamely, a key that they
use to encrypt and decrypt messages. To agree on this key, the parties must obviously have an
out-of-band method of communication that they consider secure. A large number of secret key
cryptography systems are used today, but probably the best known is the Data Encryption
Standard (DES); it will soon be superseded by the Advanced Encryption Standard (AES).
To give you a better idea of how secret key cryptography can be used to protect data as it travels
over a network, lets look at an example. Lets say that Alice and Bob can communicate without
Eve being able to read their messages. First, Alice and Bob need to agree on two things: What
single, shared key theyll use to encrypt all of the messages they send to each other and which
secret key cryptographic method theyll use. This is illustrated in Figure 8.1 below.

232

Chapter 8

Figure 8.1: Using secret key cryptography to protect data as it travels over a network.

To keep matters simple, lets say that Alice and Bob agree on key K and the XYZ algorithm.
Here is how communication occurs between them.
1. When Alice wants to send a message to Bob, she runs the plaintext message M through

the XYZ encryption routine using her copy of key K. This produces the unintelligible
message S, which is known as ciphertext. Alice can then send the encrypted message S to
Bob over an unsecured network without fear that an eavesdropper such as Eve will be
able to read the message. Eve wont be able to recover the original plaintext because she
(hopefully) doesnt have a copy of the shared key K.
2. Bob runs the ciphertext message S through the XYZ decryption routine using his copy of

the single, shared key K. This recovers the original plaintext message composed by Alice.
As I mentioned in the discussion of Kerberos in Chapter 4, its possible to construct systems for
securely communicating over public networks that only use secret key cryptography.
Unfortunately, such systems typically run into scalability issues and must rely on storing many
secret keys on a centralized server. But dont discount secret key cryptography just yet; its much
faster than public key cryptography and definitely has its place in PKI.
Public Key Cryptography
While secret key cryptography has been around for many centuries, public key cryptography
(also known as asymmetric key cryptography) is only a few decades old. Public key
cryptography was first conceived by Whitfield Diffie and Martin Hellman back in 1976, and in
1977, Ron Rivest, Adi Shamir, and Len Adleman took the concept one step further by producing
the first practical realization of a public key system; today its known as the RSA cryptosystem.
A number of public key cryptography schemes have since been proposed, including the ElGamal
cryptosystem and a whole slew of elliptic curve cryptosystems.

233

Chapter 8
While all of the public key cryptosystems are technically unique, they share a simple property:
Using an encryption key, its computationally infeasible to determine the decryption key (and
vice versa). This property allows an individual to publish his or her encryption key and let
anyone use this public key to encrypt a message; this message can only be decrypted using the
original individuals private key. As you can see, public key cryptography uses not one, but two
keys to encrypt and decrypt messages.
To give you a better idea of how public key cryptography can be used to protect data as it travels
over a network, lets go back to Alice and Bob. Unlike in the previous example, in which they
needed to agree on two things, here they only need to agree on the public key method theyll
both use. Lets say that they agree on the ABC algorithm, as shown below in Figure 8.2.

Figure 8.2: Using public key cryptography to protect data as it travels over a network.

Here is how their communication occurs this time.

1. When Alice wants to send a message to Bob, she needs to retrieve a copy of Bobs public

key KB2. She then runs the plaintext message M through the ABC encryption routine
using her copy of Bobs public key KB2. This produces an unintelligible, ciphertext
message S. Alice can then send the encrypted message S to Bob over an unsecured
network without fear that an eavesdropper such as Eve will be able to read the message.
Eve cant recover the original plaintext message because she (hopefully) doesnt have a
copy of Bobs private key KB1.
2. Bob runs the ciphertext message S through the ABC decryption routine using his private

key KB1. This recovers the original plaintext message composed by Alice.
As I touched on above, computing a public key cryptographic system takes a lot longer than
encoding the same message using a secret key cryptographic system. This has led to the practice
of encrypting messages using a secret key system, then encoding the secret key itself using a
public key system. Using this technique, the public key system transports the secret key. And
because the secret key is typically much shorter than the message, this technique is significantly
faster than using only public key cryptography.

234

Chapter 8

Hash Functions
While public key cryptography uses two keys and secret key cryptography uses one key,
cryptographic hash functions use no keys. A cryptographic hash function converts an arbitrarylength message to a fixed number of bits using cryptography techniques. This is shown below in
Figure 8.3.

Figure 8.3: Using a hash function to encrypt a message.

Hash functions are also called message digest or fingerprint algorithms, and some of the betterknown examples are Message Digest Five (MD5) and Secure Hash Algorithm (SHA)-1. Hash
functions have the following properties:

Collision FreeIts computationally infeasible to find two different messages that

compute to the same hash value

One WayGiven a message hash value, its computationally infeasible to find any other
message that has the same hash value.

As a result of these two properties, we can be sure that if two messages have the same hash
value, they must be identical. If we need to compare two pieces of data, therefore, we can just
compare their hash values.
Digital Signatures
The fundamental properties of public key cryptography allow a form of message signing called
digital signatures. Lets suppose that Alice publishes her decryption key and keeps her
encryption key secret. Whenever Alice encrypts a message, anyone can decrypt it using her
public decryption key, knowing that only Alice could have encrypted the message because she is
the only one who knows the encryption key. In effect, Alice has signed the message.
While this encryption method works in theory, in practice it isnt used. Because public key
cryptography is relatively slow from a computational standpoint, its impractical to encrypt large
messages such as Microsoft PowerPoint presentation files just to sign them. As a result, digital
signatures typically use a combination of a hash function plus public key cryptography, as shown
below in Figure 8.4.

235

Chapter 8

Figure 8.4: Using a digital signature to encrypt a message.

As you can see from this figure, sending the digitally signed message M from Alice to Bob using
hashes is a two-step process.
1. Alice runs message M through an agreed-on hash function to produce the hash value HA.

Alice then encrypts the hash using her private key and sends both the message and the
encrypted hash to Bob. Bob can then verify the signature on the message by running the
message through the same hash function that Alice used; this creates HB.
2. Bob uses Alices public key to decrypt the transmitted hash value and re-create the

original HA. If these two hashes are identical, the signature is considered valid; otherwise,
either Alice didnt sign the message, or it was somehow altered in transit.
Putting Cryptography into Practice
When public key cryptography is used in the real world, messages are encrypted and digitally
signed using a combination of the techniques discussed above. Three basic methods are used.

An encrypted messageA symmetric key encrypts the message, and a public key
encrypts the symmetric key. This method ensures that the message is confidential.

A signed messageA message is hashed, and the hash is encrypted using the private key
of the sender. This method provides authentication of the sender, integrity of the
message, and non-repudiation of the message.

A signed and encrypted messageA message is signed using the private key of the
sender, then the signed message is encrypted using the public key of the recipient. This
method provides authentication, confidentiality, integrity, and non-repudiation of the
message.

236

Chapter 8

Understanding PKI
Public key infrastructure (PKI) is intended to provide an online environment for establishing the
trust of identities and to manage the related cryptographic keys that form the basis of an online
identity. As a result, each user, application, server, or online security principal has a unique pair
of keysasymmetric keys. Each principal keeps one of these keys private and doesnt share it
with anyone while making the other key, the public key, freely available to any and all others.
This isnt all there is to it, though, because think about this: If you and I both create a pair of
keys, then publish our public keys and keep our private keys private, how will we communicate?
If its just the two of us and we already have an existing relationship and are comfortable with
each others identities, this can work. But lets say that you collect the public keys for twenty
other people; how will you keep them straight? And what if someone youve never met needs to
communicate securely with you; how will you be sure that they are who they claim to be?
The solution to both of these problems is to use a CA. A CA is a trusted third party that vouches
for the identity of a user and electronically binds a user to their public key. This binding is
accomplished using a digital certificate (or, simply, certificate). A certificate is an un-forgeable
data file that the CA creates by signing a principals public key using its private key. Before
signing, the CA also loads the certificate using information that identifies the principal.
Even using a CA, there is one more problem: How do you locate and retrieve the certificates of
principals with whom you want to communicate? While you can trade certificates with them,
how do you know if their certificates are superseded or revoked? To alleviate the administrative
overhead of retrieving certificates manually, PKI generally includes a central repository for
certificates. This is typically a Lightweight Directory Access Protocol (LDAP)accessible
directory server that makes certificates, and thus public keys, widely available.
To sum up, think of PKI as a set of services for managing the public keys of security principals.
Figure 8.5 shows the basic components of PKI.

Figure 8.5: The basic components of PKI.

237

Chapter 8
Certificates
A certificate is a digital binding of a public key to an individual, computer, application, or other
security principal, combined with some other information. A certificates basic function is to
verify that a public key belongs to a specific principal. At a minimum, a certificate contains a
public key and a name, and it also typically contains things like a serial number, an expiration
date, and the name of the CA that issued the certificate. To prove that the certificate really was
issued by the CA, the CA also digitally signs the certificate.
Think of a certificate as similar to your passport or drivers license. When you request one of
these forms of identification (ID), its issued by a recognized authority, typically a government
agency. The agency verifies that you meet the specified requirements of the ID, verifies that
youre in fact you, and issues the ID. For example, a drivers license typically contains the
following types of information:

Personal information to help identify you, such as your height, weight, eye color, and hair
color

Your photograph and signature

The issuing authority.

In addition, a drivers license is designed to be tamper-resistant. When you present it to others,

they can use it to verify your identity.
Just like a drivers license, a certificate is issued by a trusted third partynamely, a CA. The CA
provides the proof required to verify your online identity. A certificate cannot contain things like
your signature, photograph, or physical characteristics. Instead, its a virtual indication of who
you are; this can be verified in the digital signature that the CA places on the certificate.
The overall structure of a certificate has been standardized to ensure that your virtual ID card can
be correctly interpreted anywhere and by anyone. X.509v3 certificates are the current standard
for all interoperable PKI implementations. Their format is shown below in Figure 8.6.

Figure 8.6: The format of an X.509v3 certificate.

238

Chapter 8
Some of the more important fields in the standard certificate format are listed below in Table 8.1.
This Field

Stores This Value

Version

The version of the certificate format.

Certificate Serial Number

The unique serial number that is assigned by the issuing CA to

easily track issued certificates.

Certificate Algorithm Identifier

The public key cryptography and hash algorithms that are used by
the issuing CA to digitally sign the certificate.

Issuer

The name of the issuing CA.

Validity Period

The certificates start and expiration dates.

Subject

The name of the owner of the certificate.

Subject Public Key Information

The public key and a list of the public key cryptography algorithms
that the certificate can be used for.

Issuer Unique Identifier

Optional information for uniquely identifying the issuer.

Subject Unique Identifier

Optional information for uniquely identifying the subject.

Optional Fields

Additional information that can be specified for optional use by PKIs,

such as Secure Multipurpose Internet Mail Extensions (S/MIME)
secure mail or Internet Protocol Security (IPSec) authentication.
These optional fields are commonly referred to as extensions.

Certification Authoritys Digital

Signature

The CAs digital signature of the rest of the certificate.

Table 8.1: Some of the fields in the X.509v3 certificate.

Certificate Authority
Because of its importance in PKI, its easy to assume that a certificate authority (CA) is a
complicated thing. However, its functions are actually pretty simple. While each CA tries to add
bells and whistles to differentiate its product from all of the others on the market, a CA performs
only a few basic services to manage a certificates life cycle. It:

Processes certificate requests

Verifies the identity of the requester of a certificate request

Issues certificates that are prepared according to the policy for the CA

Manages the certificate audit trail, including enrollment, expiration, and revocation

Renews certificates before they expire

Revokes certificates as required by the policy for the CA

Maintains and publishes certificate revocation lists (CRLs)

Publishes issued certificates (optional).

Technically, this is all a CA needs to do to be useful to you and your organization. Ill talk more
about the role of the CA in your environment when I discuss the Win2K CA later in this chapter.
(See Windows 2000 PKI.)

239

Chapter 8
Certificate Repository
While from a technology perspective the job of a CA is simple, the role of a certificate
repository is even simpler. Most PKI implementations today publish both issued certificates and
CRLs into LDAP-accessible directory servers. This allows certificates and CRLs to be widely
disseminated so that the consumers of your PKI can retrieve the information they need to
validate certificates in your environment. In Win2K, Active Directory (AD) is the PKI certificate
repository.
PKI Applications
PKI is more than just a CA and its associated necessities; it also includes a wide variety of
information and network-security applications and solutions that can take advantage of digital
certificates. Although Ill discuss all of the Win2K PKI-enabled applications in depth in Chapter
9, Ill introduce them here to help you understand just how far-reaching and important PKI can
be for your organization. PKI can provide the following:

Smart card authentication and storage of certificates and private keys

Secure e-mail using S/MIME clients and optional secure mail servers

Secure Web communication with Internet Information Services (IIS) using Secure
Sockets Layer (SSL), and/or Transport Layer Security (TLS)

Secure access to Web site resources with IIS using certificate mapping to network user
accounts

Digitally signed software that ensures the authenticity and integrity of the software you
distribute on an intranet or the Internet

Protection of folders and files with encrypting file system (EFS) using file encryption,
including the protection of portable computers for mobile users

Optional authentication for IPSec communication that is based on certificates

Custom applications and certificate services that meet the special security needs of your
organization.

Certificate Trust Models

Deploying PKI invariably entails creating trust relationships among multiple CA systems. Such
trust relationships may either remain private to an organization or extend outside the corporate
walls. To date, three important trust models have evolved:

Cross-certification

Certificate hierarchies

Communities of interest.

Ill look at each of these trust models, briefly discuss their advantages and disadvantages, and
present a realistic picture of how you might construct the appropriate chains of trust by
deploying PKI-based technologies.

240

Chapter 8
Cross-Certification
Cross-certification is arguably the simplest trust model, and its the model that most customers
use today. The reason its been so widely adopted is that it was really the first mechanism used to
build trust relationships among issuing CAs. While there are several cross-certification
mechanisms, bilateral cross-certification and the newer certificate trust lists (CTLs) are the most
prevalent and interesting.
Bilateral Cross-Certification
In a bilateral cross-certification operation, CAs cross-certify each other by signing each others
public keys. This creates a cross-certified trust relationship, or cross-certificate, as shown in
Figure 8.7 below.

Figure 8.7: In bilateral cross-certification, CAs cross-certify each other by signing each others public keys.

CAs can unilaterally certify other CAs, but most trust relationships use bilateral cross-certification.

Creating a cross-certificate allows client software to verify the authenticity and integrity of a
certificate that has been signed by a cross-certified CA. This certificate-path processing is more
commonly referred to as walking the chain of trust because the client software follows the line of
trust that the cross-certificate creates.
For example, suppose Alice and Bob want to strongly authenticate to each other using digital
certificates. The key to this operation is allowing Bob to trust Alices credentials and vice versa.
Because Bobs CA has signed the certificate containing the public key of Alices CA, Bob can
trust Alices CA and hence Alices certificate. And because a bilateral cross-certification trust
relationship has been set up, Alice can also validate Bobs digital credentials.
Intermediate CAs may destroy a trust relationship by revoking cross-certificates, so its important for
clients to check each cross-certificate. This ensures that each cross-certificate is still a trusted part of
the chain being traversed.

241

Chapter 8
Certificate Trust Lists
Cross-certification can also take the form of a certificate trust list (CTL). A CTL is simply a list
of trusted certificates or CAs. While individual client applications can store CTLs, its preferable
for them to be stored in a central directory service, where they can be centrally managed and
digitally signed. To validate a certificate, a client checks the CTL to ensure that the issuing CA
of the certificate is present. CTLs are best thought of as unilateral cross-certification of multiple
CAs by a CA that wants its user community to trust certificates issued by those authorities.
Overall, CTLs are easier to implement and use than traditional bilateral cross-certification.
Disadvantages
Cross-certification best matches the way companies do business: one-on-one with trusted
partners. It eliminates the need for hierarchies and lets an organization establish trust when no
suitable third-party is available to facilitate the relationship. Unfortunately, when crosscertification establishes trust among many CAs, it creates overhead and management headaches.
For example, security complications occur if one organization that relies on a higher level of
trust cross-certifies the CA of another organization that has less stringent security policies.
Cross-certification also raises interoperability issues. For example, CAs from different vendors
cross-certify each other in different ways, so not all clients and CAs can walk the chain of trust.
In addition, there are problems defining, expressing, and interpreting the policies associated with
certificates, their use, and the practices of a CA. Lack of policy agreement is especially
problematic for determining whether trust should be transitive between users and CAs that have
cross-certified each other. (That is, if A trusts B and B trusts C, should C trust A?)
Certificate Hierarchies
Certificate hierarchies were proposed to create a more scalable trust model among a large
number of CAs. Not unlike cross-certification, a certificate hierarchy creates a chain of trust in a
vertical fashion; it allows two users to find a CA they both trust, then use the CA certificates to
validate each others public keys. This process is shown in Figure 8.8.

Figure 8.8: A certificate hierarchy creates a chain of trust in a vertical fashion.

242

Chapter 8
A hierarchy contains multiple CAs with clearly defined parent-child relationships. The chain of
trust is created by having a CA create a certificate containing the certified public keys of other
CAs. The resulting certificate points up a hierarchy to create a certification path between two
users. The top-most CA in a hierarchy is called the root CA because it provides the root of the
trust relationships in the hierarchy.
Going back to the example in Bilateral Cross-Certification above, lets say that Bob needs to
trust Alices credentials and vice versa. As illustrated in Figure 8.8, Alice trusts CA A, while
Bob trusts CA B. If Alice and Bob are to authenticate each other, they must establish a chain of
trust that links the certificate authorities they trust. Using the reverse certificates maintained by A
and B, Alice and Bob can construct a chain of trust to CA C, which they both trust. This common
authority (in this case, the root CA) provides the mechanism that allows Bob and Alice to trust
each others digital certificates.
Advantages
The fundamental advantage of this model is that it allows verifying certificates to trust only a
relatively small number of root CAs. At the same time, the model allows the number of issuing
CAs to be flexible. Practical reasons for supporting multiple issuing CAs include:

UseCertificates may be issued for a number of purposes (for example, to provide

secure e-mail, network authentication, and so on). Multiple issuing CAs allow the issuing
policy for these uses to be distinct, and separation provides a basis for administering
these policies.

Organizational divisionsDifferent divisions in an organization may require different

policies for issuing certificates. Again, multiple issuing CAs can be used to separate and
administer these policies.

Geographic divisionsDivisions of an organization may be located at multiple physical

sites. To meet usability requirements, network connectivity among these sites may
require multiple issuing CAs.

Such a CA hierarchy also provides administrative benefits, including:

Flexible configuration of the CA security environment (key strength, physical protection,

protection against network attacks, and so on) to tailor the balance between security and
usability

Fairly frequent updating of issuing CA keys and/or certificates, which are the most
exposed to compromise, without requiring a change in established trust relationships

The ability to turn off a specific portion of the CA hierarchy without affecting the
established trust relationships.

Disadvantages
Even when hierarchical certification authorities provide such benefits, some people believe that
they should be avoided because of their complexity. They believe that its unreasonable to
assume that everyone needing a certificate will trust one authority. And compromising the root
CA key puts the entire hierarchy at potential risk.

243

Chapter 8
Communities of Interest
In communities of interest, a hub CA provides centralized trust management for members of the
community; this is shown in Figure 8.9. Instead of creating a large number of bilateral
agreements with each other, organizations in the community create bilateral agreements with the
hub CA. Because everyone trusts the hub CA, the chain of trust in the community is relatively
short; everyone is one trust relationship away from everyone else.

Figure 8.9: In a community of interest, a hub CA manages centralized trust relationships.

The community-of-interest model leverages the benefits of cross-certification and hierarchical

trust, while trying to mitigate many of the disadvantages of both. Everyone in the community has
an interest in doing business with each other and thus has an interest in creating relationships.
They use bilateral cross-certification with the hub CA to create those relationships, allowing trust
to be business-driven and relatively simple. The chain of trust begins in an organization and
extends to third parties within the community. Using the hub CA as the root, the community also
creates a limited hierarchy that offloads the complexity of maintaining multiple relationships;
hence, trust becomes more scalable.
Unfortunately, this trust model is still relatively new and isnt immune to the interoperability
problems associated with cross-certification and certificate hierarchies. Issues also abound with
the applicability of the meshed trust network created by the hub CA. For example, does
extending the trust also dilute it? Despite the unknowns, organizations such as the Automobile
Network Exchange (ANX), ABAecom (a subsidiary of the American Bankers Association, or
ABA), and the Securities Industry Root Certificate Authority (SIRCA) are examples of early
efforts to use this trust model.

244

Chapter 8

Recommended Trust Relationships

As should be evident by now, trust relationships arent a one-size-fits-all proposition. Business
needs have to drive the trust relationships that you use in your organization; therefore, youll
likely use a combination of trust models and relationships. For internal business processes, I
recommend that you consider a closed certificate hierarchy to provide trust relationships within
your corporate boundaries.
Outside the corporate walls, initial trust relationships with customer segments will more than
likely take a hierarchical form. Youll probably need to use cross-certification with your closest
business partners because they may have their own CA infrastructure. As long as these business
relationships remain strategic and healthy, its advantageous to maintain the high levels of trust
that only one-on-one relationships can create.
As your company uses digital certificates, the advantages of joining a community of interest will
likely outweigh the disadvantages, and you can consider linking to an exponentially larger group
of trust relationships. This will allow your company to leverage the communitys relationships
with other communities and organizations and join other communities and hierarchies.
Simply put, how a company builds trust relationships is closely related to how it does business.
Over time, its conceivable that your organization will issue certificates to employees, suppliers,
business partners and retail customers, creating a secure foundation for all internal and external
business transactions. Figure 8.10 illustrates how such a future deployment may look.

Figure 8.10: How your company may deploy future trust relationships.

245

Chapter 8
Even if your organizations trust relationships dont end up looking like this, a couple of things
are worth pointing out. The first is the complete separation between intranet and Internet PKIs,
with no trust relationships between them. I believe that such a configuration is desirable. It
reduces risk, and it allows digital certificates to be introduced into an intranet environment
without having to contend with the legal and compliance issues that will undoubtedly be a major
factor in an Internet PKI deployment.
The second interesting thing is the mix of trust models used in an Internet PKI. This mix is
inevitable, and any Internet PKI that your organization uses will need to contend with it. Thus,
any Internet PKI effort must be more flexible in its capabilities than an intranet deployment so
that it can adapt to any trust relationship your organization needs to conduct its business.
This description of trust models is really just the tip of the iceberg, and the issues that surround
establishing trust relationships among CAs are many and complex. Hopefully, Ive made you
aware of some of the high-level technical issues that you must consider when you create such
trust relationships. While I havent talked about policy, legal, or compliance issues, I hope Ive
made it clear that your organization must carefully consider the domino effect that creating trust
relationships can have on your PKI infrastructure.

Validating and Revoking Certificates

Just because someone presents you with a certificate doesnt necessarily mean that you should
trust it. The certificate may be a forgery, may come from someone you dont trust, could be
expired, or could be revoked. Ill use the drivers license analogy again. Just as we all know that
fake drivers licenses are available, so there are fake certificates. We know that drivers licenses
expire and must be renewed and that they can be revoked when motor vehicle regulations are
violated; the same holds true for certificates.
Validating
The first thing that PKI users need to do after receiving a certificate is perform a validation check
to ensure that any certificates involved in a transaction have a valid certification path. Figure
8.11 shows a number of checks carried out to validate a certificate. A certificate might be invalid
or not trusted for a number of reasons; these include, but arent limited to, the following:

The users name has changed

The start and expiration dates are improper or expired

The certificate format isnt correct

The information contained in the certificate is incorrect or incomplete

The certificates digital thumbprint and signature fail integrity checks

The certificate is listed as revoked in a published CRL

The issuing CA isnt part of a trusted certification hierarchy or contained in a CTL

The root CA for the certification path isnt a trusted root CA

The certificate isnt permitted to be put to the use specified in the certificate.

246

Chapter 8

Figure 8.11: Some of the checks carried out to validate a certificate.

Keep in mind that in Win2Ks PKI, a certification path can be valid as long as the CA certificate
was valid at the time the certificate was issued. In other words, an expired CA certificate in the
certification path doesnt invalidate the entire path. For example, a third-party CA might issue a
certificate that specifies a lifetime that extends beyond the CA certificates expiration date. When
the CAs certificate expires, as long as all of the other validation criteria are met, the certification
path for the certificate is still valid, and the certificate is considered trusted.

247

Chapter 8

While a third-party CA might issue a certificate that specifies a lifetime beyond the expiration date of
the CAs certificate, a Win2K CA never does this. For example, if a CAs certificate is set to expire 10
days from now and you request a certificate that you want to expire a year from now, a Win2K CA will
issue you a certificate that expires in 10 days!

Revoking
After performing a validation check, PKI users need to ensure that any certificates involved in a
transaction havent been revoked. For example, a certificate is revoked when a user has left an
organization or when a users private key has been compromised. Certificates are revoked by the
issuing CA.
To let others know that a certificate should no longer be trusted, CAs routinely publish CRLs.
Certificates that are contained in a CRL should no longer be trusted by any entity. As you can
imagine, an organization with a high turnover of employees could have some very large CRLs.
Thankfully, once a revoked certificate expires, it no longer needs to be published in the CRL.
CRLs are digitally signed with the private key of the issuing CA so that consumers of the CRL
can ensure that its genuine and hasnt been tampered with. Most CAs can be configured to
periodically publish CRLs; or you can publish them manually. CRLs are typically distributed in
LDAP-accessible directories, Web pages, and public folders. Consumers of a certificate can
usually check a specific field in an X.509v3 certificate to find the distribution points for the
CRLs published by the issuing CA.

Certificate Life Cycles

In a typical PKI, certificate lifetimes are nested within each other. As a result, an issued
certificate expires before the CA certificate expires. As I discussed above, Win2K CAs explicitly
enforce nesting and dont issue a certificate beyond the expiration date of the CAs certificate.
For example, if the end date of a root CAs certificate is January 1, 2010, no child CA can issue a
certificate with a date later than January 1, 2010. Similarly, if the end date of an intermediate
CAs certificate is January 1, 2006, no child CA can issue certificates with an end date later than
January 1, 2006. If the end date of an issuing CAs certificate is January 1, 2002, no certificate
issued by the CA can have an end date later than January 1, 2002.
If a CAs certificate has an end date of January 1, 2002 and it receives a request to issue a oneyear certificate on August 1, 2000, the CA issues the one-year certificate with an end date of July
31, 2001. However, if the CA receives a request to issue a one-year certificate on August 1,
2001, the CA issues the certificate with an end date of January 1, 2002.
As a result of this strict nesting, a CA with a certificate lifetime of five years expiring on January
1, 2005, can issue one-year certificates until January 1, 2004, or two-year certificates until
January 1, 2003. After January 1, 2003, the CA no longer issues two-year certificates; instead, it
truncates the end date to January 1, 2005. Likewise, after January 1, 2004, the CA truncates the
end date of both one-year and two-year certificates to January 1, 2005.
You typically want to renew CAs with new CA certificates before theyre bound by the
constraints imposed by nested validity dates. As a result, look at your CA hierarchies regularly
and ensure that you arent needlessly limiting the lifetimes of any of your issued certificates.

248

Chapter 8
Choosing Certificate Life Cycles
There are a number of things that you need to consider when choosing the lifespan of certificates
in your environment. Unfortunately, there is no magic formula, but when you choose the
maximum lifetime, there are a number of risk factors to consider.

Length of user and CA private keysLonger keys are harder to brute force; therefore,
they support longer key lifetimes.

Storing private keysThe stronger the security provided for private keys, the longer
you can set the lifetime. In general, storing private keys in specialized hardware devices
gives them longer key lifetimes than storing private keys on disk.

CA securityThe higher the security of the CA computer, the longer you can set the
certificate lifetimes. Things like keeping the CA off the network and keeping it in a
physically secure data-center environment can allow you to choose longer certificate
lifetimes.

Cryptographic strengthSome cryptographic technologies provide stronger security as

well as support for stronger cryptographic algorithms. In general, stronger cryptographic
technology supports longer key lifetimes.

Administrative effortThe shorter the certificate lifetimes, the more often you have to
renew certificates.

Nesting certificate lifetimesThe deeper the nesting you deploy, the more careful and
restrained youre going to be in choosing certificate lifetimes.

Overall, choosing certificate lifetimes becomes a tradeoff between the risks youre willing to
take and the amount of administrative overhead youre willing to put into your PKI. While there
are no hard-and-fast rules, Table 8.2 below offers reasonable suggestions for choosing key
lengths and certificate lifetimes for a typical organization.
This Certificate
Purpose

Has This Lifetime

And This Renewal Policy

Root CA
(4096-bit keys)

20 years

Renew the CA every 9.5 years to ensure that you can

issue 10-year certificates. Renew with a new key pair
every 20 years.

Intermediate CA
(3072-bit keys)

10 years

Renew the CA every 4.5 years to ensure that you can

issue 5-year certificates. Renew with a new key pair
every 10 years.

Issuing CA
(2048-but keys)

5 years

Renew the CA every 2.5 years to ensure that you can

issue 2-year certificates. Renew with a new key pair
every 5 years.

User
(1024-bit keys)

1 year

Renew with a new key pair every year.

Administrator
(1024-bit keys)

6 months

Renew with a new key pair every 6 months.

Computer
(1024-bit keys)

2 years

Renew with a new key pair every 2 years.

Table 8.2: Suggestions for choosing certificate lifetimes.

249

Chapter 8
No matter what certificate lifetimes you decide on, be sure to do at least two things:

Work through all possible expiration and nesting scenarios to ensure that you (or
someone else) dont run into any unexpected surprises 15 years from now!

Document, document, and document all of the decisions you make.

No one can be sure how PKI technologies will progress over the entire lifetime of your issued
certificates. Its entirely possible that the technology will become outdated and be no longer
used; on the other hand, it may become the de facto standard and replace all occurrences of
passwords for authentication. No matter which scenario occurs, its wise to carry out the two
tasks above to ensure that youre prepared down the road.

The Legal Ramifications of PKI

Using PKI has certain legal ramifications. These are discussed below.
The Certificate Practice Statement
Most of you are familiar with the company VeriSign, Inc. This is a commercial CA that issues
digital certificates for both enterprises and individuals. As a result, it follows very formalized
practices and processes to verify claimed identities before it issues a certificate.
For example, VeriSign legally regulates the use of issued certificates using a Certificate Practice
Statement (CPS). A CPS does the following:

Specifies the practices and processes that the CA uses to issue and manage certificates

Describes a CAs criteria and process for validating and approving certificate requests,
revoking certificates, publishing CRLs, and liabilities if an issued certificate is misused.

Commercial CAs commonly publish their CPS on their Web sites. As a result, you can read the
CPS to find out what practices the CA follows to issue various types of certificates, for what use
they authorize their issued certificates, and their liability when a certificate is compromised or a
transaction involving a certificate occurs.
If you want to see all of the built-in commercial CAs that are bundled with Win2K, run the Certificates
Microsoft Management Console (MMC) snap-in and check the Trusted Root Certification Authorities
list. Ill discuss this snap-in in some detail in the next chapter, but this gives you an idea of all of the
commercial CAs that are out there.

250

Chapter 8

Creating a CPS
A CPS for your organization states the requirements for certificates, such as public key lengths,
certificate lifetimes, and uses for certificates. To create a CPS, you need to start with a simple
certificate policy, which can include any or all of the following types of information:

The purposes for which the certificate can be used

The requirements for managing private keys

Whether the private key can be exported

The requirements for users of the certificates

The requirements for enrolling and renewing the certificates

The certificate lifetimes

The cryptographic algorithms to be used

The minimum length of the public key and private key set.

Once you have a handle on your certificate policy, you can create a CPS that includes the
following types of information:

Positive identification of the CA

The certificate policies that are implemented by the CA and the types of certificates that
are issued

The policies, procedures, and processes for issuing and renewing certificates

The cryptographic algorithms and key length used for the CA certificate

The lifetime of the CA certificate

The physical, network, and procedural security of the CA

The certificate lifetime of each certificate issued by the CA

The policies for revoking certificates, including conditions for revocation

The policies for CRLs, including distribution points and publishing intervals

The policy for renewing the CAs certificate before it expires.

Im not a lawyer, dont play one on TV, and never play one when Im ensuring the security of
the organizations I work for. Although the things Ive listed above seem technical, dont be
fooled: A CPS is all about limiting corporate liability if something goes awry, so its therefore
more the work of lawyers than security professionals. This is especially true for those of you
who work in larger, multinational corporations.

251

Chapter 8

The E-Sign Act

Another legal issue you may need to grapple with are the effects of the Electronic Signatures in
Global and National Commerce Act (also known as the E-Signature Bill), which took effect in
October 2000. The E-Signature Bill gives digital signatures legal status at the federal level in the
United States. It supersedes more than 50 laws at the state level as well as laws in other
countries. But it doesnt address issues of liability, and it doesnt even mention PKI or define
digital signature in the manner Im discussing.
So we still dont know how courts will apply the law in situations where an organization or
individual is affected by PKI-related frauds. For example, we dont know wholl be held liable
when a VeriSign-issued certificate is used to perpetuate fraud: VeriSign or the entity to whom
the certificate was issued. In the interim, youll have to rely on contracts to explicitly spell out
your organizations expectations.

The Windows 2000 PKI

Now that Ive covered some of the basics of PKI and how it works, its time to talk about more
specifically about the PKI offered in Win2K. The components of the Win2K PKI are shown in
Figure 8.12 and described below.

Figure 8.12: The components of the Win2K PKI.

Applications and servicesMost of the PKI applications and services will be deployed across
both your desktop and server environments. Outlook, Outlook Express, Internet Explorer (IE),
EFS, and IIS are all examples of applications and services that can benefit from the added
security of PKI. Theyre designed to interact with each other and make use of the basic
cryptographic services provided by the operating system (OS).

252

Chapter 8
Certificate storesAll of the keys and certificates are stored on behalf of the users, computers,
and services in your environment in a cryptographic service provider supplied by either Win2K
or a third party. These certificate stores also include all of the trusted CAs. Certificate stores are
used by the PKI-enabled applications and services to store and retrieve the required keys and
certificates.
Security administrationThe PKI security administrator has access to a number of MMC
snap-ins and command-line tools to browse the certificate stores, export private keys and
certificates, request certificates, renew certificates, and configure the overall PKI policies for
your enterprise.
Security policyNot only do you have the administrative tools you need to implement PKI
policies, you also have the ability to control which CA certificates can be issued and trusted in
your enterprise. In addition, you can control automatic certificate issuance for the computers in
your environment and some basic PKI-related policies using Group Policy Objects (GPOs).
Certificate serverWin2K implements the functions of a CA using a built-in certificate server.
More specifically, Microsoft Certificate Services allows you to implement your own CA.
Certificate Services support two modes of operation: enterprise CA and standalone CA. (For
more information, see Certificate Services below.)
ADAD is the certificate publication point for users and computers, and it publishes CRLs. For
enterprise CAs, these publications can happen automatically, but standalone CAs require manual
intervention to publish certificates or CRLs.
Certificate Services
You can run Certificate Services on Windows 2000 Server, but not on Windows 2000
Professional. You run Certificate Services in one of two modes.

Enterprise CAIs fully integrated with AD and can publish certificates and CRLs
directly to AD. It can also use other information in AD to control its operation. More
specifically, it can use information on templates, users, computers, and security groups
that is stored in AD to automatically approve or deny certificate requests for users in your
environment. For a certificate enrollment request to be approved, the requesting principal
must have the Enroll permission granted on a certificate template stored in AD. When
certificates are automatically issued, an enterprise CA uses information in the certificate
template to generate an appropriately formatted certificate type.

Standalone CAStands apart from the rest of your enterprise to perform generic CA
functions. A standalone CA doesnt use certificate templates and doesnt integrate with
AD. It requires that a requesting principal supply all of the necessary information to
create an appropriately formatted certificate type. Certificate enrollment requests to a
standalone CA must be handled manually. As a result, theyre placed in a queue of
pending requests that must be manually approved by a CA administrator.

Although you can configure a standalone CA to automatically issue certificates on a certificate

enrollment request, I strongly recommend that you not do this. Blindly issuing certificates without
some sort of control mechanism can add significant security risk to your environment.

253

Chapter 8
Standalone CAs arent your best bet for creating any real number of certificates because the
manual intervention required to review and either approve or deny every certificate request
incurs a high administrative cost. Microsoft seems to recommend standalone CAs for use when
users dont have Windows 2000 accounts and the volume of certificates to be issued and
managed is relatively low. I agree with this; a root CA and any subordinate CAs that dont issue
certificates directly are great candidates for a standalone CA. This type of configuration allows
you to keep these CAs offline and protect them from potential attack from within your
environment.
Microsoft also recommends that you install most issuing CAs as enterprise CAs to gain the
benefits of integration with AD, including automated certificate approval and automatic
computer certificate enrollment. I couldnt agree more because being able to control certificate
issuance using access control lists (ACLs) on certificate templates within AD creates an easy-toadminister environment.
Enterprise CAs are more complicated than standalone CAs, so in the rest of this section on the
Win2K PKI, Ill discuss how to run and administer them. Once you know how an enterprise CA
works, a standalone CA is pretty easy to figure out.
Certificate Templates
Certificate templates are nothing more than profiles that define what fields will be contained in
certificates issued by an enterprise CA. Certificate templates contain fields that can be pulled
from AD, such as Requestor Name and E-mail Address. They can also contain information such
as Expiration Time and Certificate Use. In fact, each certificate template is really defined by its
intended use. For example, the certificate template for standard users is called User and is
intended to be used for S/MIME e-mail, EFS, and user authentication. Table 8.3 below shows a
partial list of available certificate templates.
This Certificate Template

Is Intended to Be Used for This

Administrator

Authenticating clients, EFS, secure e-mail, CTL signing, code signing.

Basic EFS

EFS operations.

Computer

Authenticating clients and servers.

Domain Controller

Authenticating domain controllers.

EFS Recovery Agent

EFS-encrypted data-recovery operations.

IPSec

IPSec authentication.

User

Client authentication, EFS, and secure e-mail.

Web Server

Web server authentication (offline requests only).

Table 8.3: A partial list of certificate templates.

Certificate templates are stored in AD, and its easy to access them using the Active Directory
Sites and Services MMC snap-in. Open the snap-in and choose View>Show Services. Expand
the Services node, expand the Public Key Services node, then select the Certificate Templates
node. A list appears of certificate templates for your environment; see Figure 8.13 below.

254

Chapter 8

Figure 8.13: Viewing the certificate templates for your environment.

Configuring Certificate Templates

Using the MMC snap-in, you can configure the ACLs for each certificate template. This is
possible because, like everything else stored in AD, certificate templates are just AD objects.
Right-click a template and choose Properties from the shortcut menu. In the Administrator
Properties dialog box, click the Security tab. The Security page appears, as shown below in
Figure 8.14.

255

Chapter 8

Figure 8.14: Setting security on certificate templates.

The most important thing to notice about the Security page are the types of permissions that are
available on certificate templates. In addition to permissions youre already familiar with, like
Full Control, Read, and Write, you can grant the Enroll permission. If you want to allow
principals to successfully retrieve certificates of a specific type, grant them the Read and Enroll
permissions on the applicable certificate templates.
Certificate Services Policy and Exit Modules
The Certificate Services module of Win2K is controlled using policy modules and exit modules.
Policy modules determine whether a certificate request should be approved, denied, or queued
for action by the administrator. Exit modules control how and where certificates are published
after theyre issued.

256

Chapter 8

Policy Modules
An enterprise CA policy module always issues a certificate, or denies a request, immediately.
Enterprise CA policy uses the native Win2K authentication mechanismsKerberos and NT
LAN Manager (NTLM)to determine the identity of the requester. It then automatically
determines whether the requester has security permissions to receive the type of certificate being
requested by consulting the certificate template ACLs. If a certificate template has both Read and
Enroll permissions for the requestor, the certificate is immediately issued; otherwise, the request
is immediately denied.
For each certificate the policy module issues, it also adds a couple of X.509v3 extensions: CRL
Distribution Point (CDP) and Authority Information Access (AIA) records. A CDP record
contains pointers to where the CA publishes its CRLs, whereas an AIA record points to where
the CAs certificate is published. Each of these records includes one or more URLs, which can
specify an LDAP location in AD, an HTTP location on a Web server, or a Universal Naming
Convention (UNC) name on a file server. These URLs provide a replaceable syntax that allows
you to substitute parameters for CA server variables, as shown below in Table 8.4.
This Variable

Takes This Value

%1

The DNS name of the CA server.

%2

The NetBIOS name of the CA server.

%3

The name of the CA.

%4

The renewal extension of the CA.

%5

The location of the domain root in AD.

%6

The location of the configuration container in AD.

%7

A sanitized name of the CA.

Table 8.4: The parameters of the CA policy module.

Exit Modules
Exit modules are used by the CA after certificates are issued. Their main job is to publish the
certificate in the appropriate location. Certificate requests can optionally specify the distribution
of a certificate to AD, the local file system, or a URL. Exit modules also deliver CRLs to CRL
distribution points. The default exit module for enterprise CAs publishes both certificates and
CRLs to AD.
Installing Certificate Services
Before you install Certificate Services, you first need to make sure that you have the required
access to AD. You use the Windows Components Wizard to do the installation. You then need to
describe the CA and specify the lifespan of the CA certificate.

257

Chapter 8

Having the Required Access

While a local administrator has the required permissions to install Certificate Services in a
standalone CA configuration, installing an enterprise CA requires Write permission to ADin
particular, Write permission on the Public Key Services node in the Active Directory Sites and
Services MMC snap-in. As a result, its often easiest to install an enterprise CA as an Enterprise
Administrator. However, your organization may not want to assign Enterprise Administrator
rights to administrators who are responsible for installing and administering your enterprise CAs.
As a result, youll have to assign Write permission to the Public Key Services portion of AD to
your enterprise CA administrators.
Using the Windows Components Wizard
Once you have the required access, install your enterprise CA using Add/Remove Programs in
the Control Panel. Open the Add/Remove Programs dialog box, then select Add/Remove
Windows Components. Select the Certificate Services check box, then click Next to launch the
Windows Components Wizard. Use the Certification Authority Type dialog box (see Figure 8.15
below) to specify the enterprise CA type for your particular installation.

Figure 8.15: Using the Windows Components Wizard to select an enterprise CA type.

258

Chapter 8
The key to installing Certificate Services is to select Advanced Options in this dialog box, then
configure the following items:

The Cryptographic Service Provider (CSP) that the CA will use for its cryptographic
operations

The hash algorithm to use in signing certificates (I recommend that you use the default
value, which is SHA-1)

An existing key pair to use when youre restoring a CA from backups

The length of the public and private keys.

Describing the CA
As you configure Certificate Services, youre prompted for information to identify the CA. This
includes, but isnt limited to, the following:

CA NameThe name of the CA (for example, ABC Company root CA)

OrganizationThe legal name of your company (for example, ABC Company)

Organizational UnitThe department responsible for the CA (for example, Information

Security)

LocalityThe city where the CA is deployed

State or ProvinceThe state or province where the CA is deployed

CountryThe two-character code for the country where the CA is deployed.

Specifying the Lifespan of the CA Certificate

If youre installing a root CA, you need to specify the lifespan of the CA certificate. Make sure
that this value is appropriate for your situation. When you install a subordinate CA, you cannot
specify the lifespan of the certificate youre requesting. In fact, the lifespan of a subordinate CA
is determined by the remaining lifespan of its parent CA. For example, if the parent CA expires
in seven years, the lifespan of a subordinate CA will be set to expire in seven years. This can
obviously play havoc with setting expiry dates for appropriately nested certificate lifespans.
You can use the CAPolicy.inf file to configure alternative certificate lifespan settings for a CA, define
an Issuer Statement (consider this a CPS), or set CSP or AIA records. The file should be located in
the %Systemroot% folder on your Win2K server before you install Certificate Services. For more
information on the CAPolicy.inf file and its format, check the server Help files.

Specifying Other Information

Along with installing Certificate Services, youre asked to specify the locations of the local
certificate database and the log file. The default values should be sufficient for your organization.
If this is a subordinate CA, youre also asked for a parent CA. If the parent CA is online, you can
point your CA to the parent CA and automatically request the certificate; otherwise, you have to
generate the request to a file and type it manually into the parent CA.

259

Chapter 8
Administering Certificate Services
To administer Certificate Services in Windows 2000 Server, Microsoft provides three tools.

Certificate Services MMC Snap-inAllows you to view and manage certificate

requests, configure the CA, and manually publish CRLs. You can view and revoke issued
certificates, view and deny pending certificate requests, view failed certificate requests,
modify the policy module settings, revoke certificates, and manually publish the CRL.

CertReqAllows you to request certificates from CAs.

CertUtilAllows you to back up and restore the CA keys and databases, shut down the
CA server, revoke certificates, retrieve the CA signing certificate, and verify a privatepublic key pair. If youre responsible for administering Certificate Services, you need to
become very familiar with this tool.

There is a fourth tool that you can manipulate, CertSrv. It allows you to run the CA as a stand-alone
application and display its actions on the console so that you can diagnose certificate-issuance
problems. Its meant to be run only by developers and extremely knowledgeable Certificate Services
administrators.

Hardware Protection of Private Keys

You can create a high-assurance PKI environment using hardware protection of private keys.
The question is, where do you need it? You can use smart cards to generate and store private
keys, but protecting the private keys of your CAs is more important. Think about it this way: The
consequences of compromising a users key are nowhere near as severe as compromising the
private key of one of your CAs. Compromising a users private key affects only one user; but
compromising your root CA private key compromises your entire PKI. It affects everyone in
your certificate hierarchyyour users, computers, and potentially your suppliers and partners!
Hardware security modules are tamper-resistant devices that generate secure keys, store keys,
archive keys, and manage keys. They provide a more secure solution for storing private keys
than standard storage on a computers disk drive. For example, a private key stored on a disk
drive could be attacked by a virus or worm. In addition, if an attacker ever gained physical
access to a CA computer storing a private key, they could locate and misuse the private key. In
banking or other financial services environments, this could result in the theft of company assets,
including money and/or confidential information.
Hardware security modules were built to overcome the drawbacks of storing private keys on
computer disk drives. They provide the security services required to protect sensitive private
keys from attack and compromise.
If you think that you might need hardware protection of private keys in your PKI, I suggest that you
find a Federal Information Processing Standard (FIPS) 140-1 Level-3 certified device. For more
information on hardware security modules, check out the following products:
CryptoSwift Hardware Security Module (HSM) from Rainbow Technologies (www.rainbow.com)
Luna CA3 from Chrysalis-ITS (www.chrysalis-its.com)
nShield from nCipher (www.ncipher.com)
SureWare Keyper from Baltimore Technologies (www.baltimore.com)

260

Chapter 8

Summary
The first step in understanding how PKI functions is understanding the basic cryptographic
techniques that the infrastructure is based onnamely, secret key encryption, public key
cryptography, hash functions, and digital signatures. As youve learned, PKI is intended to
provide an online environment that establishes the trust of identities and to manage the related
cryptographic keys that form the basis of an online identity. CAs, CRLs, and trust relationships
are just some of the components required to build a fully functional PKI.
In this chapter, Ive concentrated on describing the core principles of PKI and how Win2K
implements Certificate Services to fulfill the role of a CA. Youve learned how to install,
configure, and maintain an enterprise CA so that you can create a PKI for your organization that
is easy to administer and fully integrated into your AD infrastructure.
I hope that you feel comfortable enough to create a PKI for your organization and that youll
come back to read Chapter 9, where Ill discuss Win2K PKI components in detail.

261

Chapter 9

Chapter 9: Public Key InfrastructurePart 2

Back in Chapter 8, I discussed the key components of public key infrastructure (PKI) and how
they work. I described the basic cryptographic techniques that the infrastructure is based on
secret key encryption, public key cryptography, hash functions, and digital signatures. I said that
PKI is intended to provide an online environment for establishing the trust of identities and to
manage the related cryptographic keys that form the basis of an online identity.
In that chapter, I also said that components such as certificate authorities (CAs), certificate
revocation lists (CRLs), and trust relationships were just some of the things required to build a
fully functional PKI. I concentrated on the core principles of PKI and how Microsoft
implemented its Certificate Services to fulfill the role of a CA. You learned how to install,
configure, and maintain an enterprise CA so that you can create a PKI for your organization that
is easy to administer and fully integrated with your Active Directory (AD) infrastructure.
But there is more to PKI than just theory and CAs. What I didnt discuss in Chapter 8 was how
certificates are issued to users, computers, and applications in your environment and how users
go about using them. These topics are the focus of this chapter. Ill describe how to successfully
issue and use certificates in your environment. Ill cover issuance mechanisms, and Ill describe
the applications and protocols available to youhow they work and how to deploy them to be
successful and avoid problems down the road. When Im done, you should understand how to
successfully manage and deploy the PKI solutions delivered as part of Win2K.

Managing Certificates
Once youve installed a CA or two in your environment, you need to be able to issue certificates
to users, computers, and applications. In this section, Ill talk about the main mechanisms that
Microsoft has supplied for issuing certificates as well as for managing and validating certificates
in your environment.
Windows 2000 (Win2K) includes three mechanisms for issuing certificates.

Group Policy

Certificates Microsoft Management Console (MMC) snap-in

Certificate Services Web pages

CertReq.exe.

Once youve issued certificates appropriately, your users can take advantage of a wide variety of
digital certificatebased applications and protocols built into Win2K, including Outlook Express,
Internet Explorer (IE), the encrypting file system (EFS), and Internet Protocol Security (IPSec).

262

Chapter 9

Configuring Group Policy Settings

In a Group Policy Object (GPO), there are a number of public key security policy settings that
you can configure to help manage certificate use in your environment. They exist under the
Computer Configuration node, as shown below in Figure 9.1. Because these settings are
computer policies, you can only use them to define policy for computers in your environment
and not users or applications. In the configurable public key policies, you can configure:

Encrypted Data Recovery Agents

Automatic Certificate Request Settings

Trusted Root Certification Authorities

Enterprise Trust.

Each of these four policies is important to effectively manage the certificates that you can use
and trust in your environment.

Figure 9.1: The public key settings of Group Policy.

263

Chapter 9
Encrypted Data Recovery Agents
The Encrypted Data Recovery Agents policy isnt really a specific policy for the Win2K PKI;
instead, its a policy about a specific client of Win2K that relies on digital certificates: EFS. This
policy controls how EFS is used in your environment. If the policy is defined using one or more
certificates for your recovery agents, EFS is enabled and can be used on computers within the
scope of the GPO. If the policy is defined but empty, EFS is disabled on the computers within
the scope of the GPO. Ill talk more about this policy and the use of EFS later in this chapter.
Automatic Certificate Request Settings
The Automatic Certificate Request Settings policy allows computers in your environment to
automatically enroll for certificates. In addition, when this policy is defined, you can define
which enterprise CAs the computers can contact to issue digital certificates. Keep in mind that
this policy only allows computers to request certificates that are related to the operation of a
computer, such as IPSec, Web, and client authentication. This policy cannot be used in any way
to issue any certificate type that the users in your environment will use.
Using the Automatic Certificate Request Settings policy is the easiest way to issue certificates to
all of the computers in your environment; otherwise, youd have to manually request certificates
for each one. If you have more than a handful of computers, that might take a while.
You may notice that soon after you install an enterprise CA in your environment, all of your domain
controllers have retrieved certificates for themselves. This is something that domain controllers
automatically do, and contrary to what you might think, it isnt controlled using this GPO setting. Once
domain controllers have their certificates, they can use public key techniques to communicate with
each other.

Trusted Root Certification Authorities and Enterprise Trust

The Trusted Root Certification Authorities and Enterprise Trust policies define three types of
certificate trust issues in your environment.

Which root CAs are trusted (remember, if you dont trust a root CA, you wont be able to
verify the certificate as authentic and wont trust it)

Whether users are allowed to add CAs of their own choosing to their list of trusted CAs

The acceptable key usage for the certificates for each of the defined CAs.

When you install an enterprise CA, youll notice that its automatically added as a trusted CA
throughout your environment. As a result, your own Microsoft enterprise CAs are automatically
trusted. However, if you need to distribute certificates in your environment from a non-Microsoft
CA, you need to add the root CA certificate to the Trusted Root CAs policy so that your users,
computers, and applications can validate certificates issued from these CAs.
While you should use the Trusted Root CAs policy for CAs in your environment, youll probably
want to use the Enterprise Trust policy to validate certificates from any non-Microsoft CAs. The
Enterprise Trust policy is nothing more than a collection of certificate trust lists (CTLs) that need
to be digitally signed. These CTLs allow you to specify how certificates can be used in your
environment.

264

Chapter 9

To understand the difference between a Trusted Root CA and an Enterprise Trust policy, think of who
controls which key usages are allowed. In the case of a Trusted Root CA, the CA controls how the
key is used; in the case of an Enterprise Trust policy, you control how the key is used. For example,
lets suppose that your organization needs to trust a CA that issues certificates for all sorts of
purposes. If you were to put the CA in the Trusted Root CA, youd trust certificates for all uses that
the CA intended. However, you may want to trust only the other CA to send secure mail. In this case,
youll want to put the CA into an Enterprise Trust policy and appropriately limit the use of keys to
secure mail.

Using the Certificates MMC Snap-In

The Certificates MMC snap-in allows you to request certificates and manage existing
certificates. While users in your environment are only allowed to manage certificates for
themselves, administrators can manage certificates for themselves and for other users,
computers, and applications. The Certificates MMC snap-in is shown below in Figure 9.2.

Figure 9.2:The Certificates MMC snap-in.

The Certificates MMC snap-in displays the certificates that are contained in the various
certificate stores available in Win2K. For example, I have one certificate in my personal store
that was issued by Root CA. You can see what other CAs are considered valid in your
environment by looking at the other three certificate stores: Trusted Root Certification
Authorities, Enterprise Trust, and Intermediate Certification Authorities. You can also use the
Certificates MMC snap-in to interrogate the certificates that are stored for a user in the AD.
You can also use the Certificates MMC snap-in to access the Certificate Request Wizard to
request a new certificate or renew an existing one. To request a new certificate, right-click the
Personal certificate store, choose All Tasks from the shortcut menu, then select Request New
Certificate. This starts up the Certificate Request Wizard, as shown below in Figure 9.3.

265

Chapter 9

Figure 9.3: The Certificate Request Wizard.

Like most Win2K wizards, the Certificate Request Wizard is relatively painless to use. It guides
you through the steps required to request a certificate from one of the enterprise CAs installed in
your environment. Keep in mind, though, that this wizard only works with enterprise CAs; it
isnt available to make certificate requests from standalone CAs.
The wizard allows you to make a number of choices as it guides you through the request process.
You select the enterprise CA to which you want to submit the request as well as the appropriate
certificate template for the type of certificate you want. You can also select some of the
advanced options, like the cryptographic service provider (CSP) and whether you want to enable
strong private-key protection. And you can give the certificate a friendly name and a description.
You can use the same type of wizard functionality to renew and export certificates. To perform
one of these tasks, right-click the appropriate certificate, choose All Tasks from the shortcut
menu, then choose the corresponding menu option. This starts the appropriate certificate wizard.
Using the Certificate Services Web Pages
One of the by-products of installing Certificate Services on a Win2K server is automatically
configuring a set of the Certificate Services Web pages. These Web pages provide a convenient
mechanism for users to interact with the CA, allowing them to request and retrieve certificates
using nothing more than a simple Web browser. By default, the Web pages are installed at
http://<servername>/certserv, where <servername> is the host name of the Win2K server where
the CA is located. When you go to this location, youll see a page similar to the one shown
below in Figure 9.4.

266

Chapter 9

Figure 9.4: The Certificate Services main Web page.

While the Certificate Services Web pages are the only real interface for a standalone CA, theyre
also the most feature-rich mechanism for retrieving certificates from an enterprise CA. The Web
interface allows you to set optional request features that arent available using mechanisms like
the Certificate Request Wizard. For example, you can mark keys as exportable, set the key
length, and create a certificate request file instead of actually requesting a certificate.
Overall, using the Certificate Services Web pages is pretty simple and self-explanatory.
However, I want to go over the basic tasks that you can perform using this interface so that you
have some understanding of the capabilities available to you. You can perform the following
tasks:

Submit a basic certificate requestSubmit a simple user certificate request over the
Web. This type of request provides default values for all of the certificate fields and
formats and uses information from AD to populate the required fields in the issued
certificate.

Submit an advanced certificate requestSubmit an advanced certificate request over

the Web by specifying some of the options yourself instead of using default values.
Examples of some of these options include: the CSP to be used, key length, strong
protection of keys, marking keys as exportable, setting specific X.509v3 certificate
extensions, and saving the request to a PKCS #10 file.

Check on a pending requestWhile an enterprise CA will issue or deny a certificate

immediately, users need to check the status of a pending request that has been submitted
to a standalone CA. If the certificate has been issued by the authority, users can download
and install it.

267

Chapter 9

Retrieve the CAs certificateRetrieve the certificate of the CA itself.

Submit a request using a fileMake certificate requests using existing PKCS #10 and
PKCS #7 files. These methods are typically used when requesting a certificate from a
standalone CA rather than an enterprise CA.

Request a smart card certificateRequest a certificate for a smart card on behalf of

another user. Ill talk more about this when I talk about logging on using smart cards (see
Issuing Smart Cards) later in this chapter.

While other mechanisms to request certificates are built into Win2K, the Certificate Services
Web pages will probably be used most often in your environment. Consequently, if youre
serious about deploying Microsofts Certificate Services, I urge you to become familiar with how
these Web pages function. I also urge you to consider modifying the pages to eliminate functions
that your user base doesnt requirefor example, so that you give your users only one option for
requesting a certificate.
Using CertReq.exe
The final mechanism that you can use to request certificates from the Microsoft-based CAs in
your environment is CertReq.exe, the command-line certificate request tool. It allows you to
request as well as retrieve a certificate from a CA. You can see the syntax of the tool, and how
the tool is used, in Listing 9.1 below.
C:\>certreq /?
Usage:
CertReq -?
CertReq [-rpc] [-binary] [-config ConfigString] [-attrib
AttributeString] [RequestFile [CertFile [CertChainFile]]]
CertReq -retrieve [-rpc] [-binary] [-config ConfigString] RequestId
[CertFile [CertChainFile]]
-attrib AttributeString - Named attribute string
-binary

- Output files in binary format instead of

Base64-encoded

-config ConfigString

- Server\CertificationAuthority config
string or use a single minus sign (-) as
config string to choose the default

-rpc

- Use RPC instead of DCOM server connection

-?

- Display this usage message

RequestFile

- Base64-encoded or binary input file name:

PKCS10 certificate request,
PKCS7 certificate renewal request, or
KeyGen tag format certificate request

CertFile
CertChainFile

- Base64-encoded X-509 output file name

- Base64-encoded PKCS7 output file name

268

Chapter 9
ConfigString

- Backslash separated Server Name and

Certification Authority Name

AttributeString

- Colon separated Name and Value string

pairs Each pair separated by a backslash
and "n"

C:\>

Example: "Name1: Value1\n Name2: Value2"

Listing 9.1: The syntax of the Certificate Request Tool and how the tool is used.

Using this command is pretty straightforward, but one of the more interesting things you can do
with it is retrieve any certificate that has ever been issued by a CA. Not only can you retrieve a
certificate for a valid user, but you can also retrieve revoked or expired certificates. To do this,
you need the RequestID of the certificate that you want to retrieve.
One of the things youll notice as you play with Certificate Services is that RequestIDs are sequential,
starting with a value of 2. (RequestID 1 belongs to the CAs certificate!)

Sending and Receiving Secure Email

PKI-enabled secure email clients have been available for a number of years now, but theyve yet
to really catch on. Clients such as Qualcomms Eudora, Microsoft Outlook Express, and
Microsoft Outlook all allow you to send and receive security-enhanced email messages. These
clients depend on PKI technologies for both digital signatures and bulk encryption of email
messages. In the context of secure email, digital signatures verify the sender of the message and
ensure that the message hasnt been modified in transit; encryption ensures that only the intended
recipient(s) have the ability to read a message.
While a number of proprietary secure email solutions have appeared over the years, the
Secure/Multipurpose Internet Mail Extensions (S/MIME) standard has become the mostsupported secure mail standard in the industry. So while secure email solutions like Pretty Good
Privacy (PGP) are available and widely used in the UNIX and free-software communities,
S/MIME is the industry standard built into the Outlook Express email client that is part of
Win2K installations.
As you can deduce, S/MIME uses digital certificates and PKI technologies to provide secure
message capabilities for email communications. Using an S/MIME-based client, the sender of an
email message can digitally sign it to provide data integrity and non-repudiation. A sender can
also encrypt email messages to ensure that they remain private and cannot be read by others. On
the other side of the communications, email recipients can verify who sent a message and
validate that it hasnt been modified in transit. Recipients can also decrypt encrypted email
messages that were destined for them, but not those intended for others.

269

Chapter 9

Configuring Outlook Express

Before explaining how to send security-enhanced email messages from Outlook Express, I want
to step back and take a look at its configuration options. Configuring Outlook Express to send
S/MIME email messages is actually pretty easy. First, Ill assume that you already have Outlook
Express appropriately configured to send and receive email. Ill also assume that youve already
used one of the methods described above to retrieve a digital certificate whose key usage allows
it to be used for secure email messages. If these assumptions are true, youre all set to send
secure email messages!
To configure Outlook Express to send S/MIME email messages, run the application, then choose
Tools>Options. In the Options dialog box, click the Security tab. The Security page appears, as
shown below in Figure 9.5.

Figure 9.5: Configuring Outlook Express to send S/MIME email messages.

270

Chapter 9
Under Secure Mail, you can set three configuration options.

Tell Me MoreDisplays some basic Help information about how to use the secure
email capabilities of Outlook Express.

Digital IDsDisplays the Certificates dialog box, which is used throughout Win2K.
This dialog box provides some similar functionality to that of the Certificates MMC
snap-in; however, it only allows you to import certificates into the appropriate certificate
store, not request a new one.

Get Digital IDTakes you to a Web site hosted by Microsoft that points the way to
third-party CAs, where you can obtain digital certificates if you dont already have your
own internal CAs.

Also included under Secure Mail are two options to set how security should be applied to all
outgoing email messages.
Clicking Advanced on the Security page displays the Advanced Security Settings dialog box,
where you can configure how Outlook Express should deal with S/MIME-based secure email
messages. You can specify:

The encryption strength for all encrypted messages

How digitally signed messages are processed

When revocation checking occurs during certificate validations.

Figure 9.6 shows that Ive selected to digitally sign all of my email messages but encrypt
outgoing messages on a case-by-case basis.

Figure 9.6: Configuring advanced S/MIME security in Outlook Express.

271

Chapter 9
Sending S/MIME Messages
After youve configured Outlook Express to your liking, sending a security-enhanced email
message is a pretty simple proposition, as shown below in Figure 9.7. To digitally sign the
outbound message, click the Sign tool on the toolbar. To encrypt the outbound message, click the
Encrypt tool on the toolbar. As youll recall, to digitally sign a message, all you need is your own
digital certificate. However, to send an encrypted message, you need a copy of the digital
certificate of your intended recipient.

Figure 9.7: Sending a security-enhanced message in Outlook Express.

Unfortunately, Outlook Express requires that you have a copy of the recipients digital certificate
stored in your Contacts folder. If you already have the certificates for all of your intended
recipients, youre all set; otherwise, you have to obtain them. To obtain a digital certificate:

Have an intended recipient send you a digitally signed message.

When you receive the message, right-click the name of the sender and choose Add to
Address Book from the shortcut menu. Then add the user and their digital certificate to
the Outlook Express Contacts folder.

Once you have your intended recipients digital certificates, youre ready to send them both
signed and encrypted email!
While the specifics are a little different, the same types of configurations and options are available in
the Microsoft Outlook line of products, starting with Outlook 98.

272

Chapter 9

How the EFS Works

The EFS is a personal file-encryption mechanism that is embedded in the Win2K kernel. EFS
uses PKI technologies to enable users to encrypt individual NT file system (NTFS) files as well
as entire folders, including all subfolders. (From now on, when I say files, I mean files and
folders.) From your perspective as a user, EFS works transparently by encrypting and decrypting
file reads and writes to NTFS volumes. As youve seen, you can establish data recovery policies
using the functionality of GPOs. (See Encrypted Data Recovery Agents earlier in this chapter.)
A data recovery policy allows you to recover encrypted files when necessary. Finally, EFS
allows you to back up, restore, and transfer encrypted files without decrypting the protected data.
The data recovery feature of EFS only recovers encrypted files. It doesnt disclose the users private
key that was originally used to encrypt the files. As a result, there is no requirement to escrow a
users private keys!

Encrypting Files
Now that you know something about EFS, Ill dive in and discuss how it operates. As mentioned
above, EFS is based on PKI technologies to encrypt files. As you might recall from the
discussion of cryptography back in Chapter 8, one of the major disadvantages of public key
encryption is that its very CPU-intensive. Consequently, EFS uses a combination of both
private- and public-key cryptography to increase overall responsiveness.
Like other combinations of private- and public-key cryptography, EFS generates a unique,
random encryption key for every encrypted file that you mark for encryption. This random
encryption key is known as the file encryption key (FEK). The FEK is a symmetric key that is
used to encrypt the contents of each file.
To keep the FEK with the encrypted file, EFS adds a header to each file. This header is
composed of two sections.

Data Decryption Field (DDF)Nothing more than the FEK for the file that has been
encrypted using your public key

Data Recovery Field (DRF)Like the DDF, but instead of encrypting the FEK using
your public key, it encrypts it using the public key of each specified recovery agent. If
multiple recovery agents are specified, the header of the file contains multiple DRFs.

To understand how all of this really works, take a look at Figure 9.8 below, and Ill step through
the process.

273

Chapter 9

Figure 9.8: How EFS encrypts files.

Once you select to encrypt the contents of a file, EFS generates a unique FEK for the file using
the Data Encryption Standard (DESX) algorithm. The FEK in turn is used to symmetrically
encrypt the plaintext contents of the file to produce a ciphertext version of the file. To protect the
FEK and allow it to be used when the file needs to be decrypted, EFS encrypts the FEK using not
only your public key but also the public key of each recovery agent. The public key encryption
of the private key creates the required entries for the DDF and DRF. Once all of the encryption is
complete, EFS stores the DDF and DRF headers with the ciphertext version of the original file.
Recovering Files
While the concept of a recovery agent has been touched on many times, why is one needed?
What is it? How do you use it? When a file is protected using EFS, there is always the risk that
you wont be able to decrypt it when you need it. For example, you could lose your private key,
you may need to recover the file of someone who has left the company, or someone else may
mistakenly encrypt one of your critical files! These are just a few of many possible ways that you
may lose access to a file after its been encrypted using EFS. To work around the problem, you
can either escrow the encryption keys, or you can use recovery agents.
Obviously, Microsoft decided to use recovery agents in EFS to recover encrypted files whenever
the private key of the user who encrypted the file is unavailable. To do this, EFS uses standard
user accounts that are whose key usage is specified as an EFS recovery agent. Youll need to
create one or more user accounts that you want to act as EFS recovery agents and issue them the
appropriate certificates.
Once youve decided on your recovery agents and issued them the appropriate certificates, you
can use a GPO to establish these recovery agents for your environment. Although Ive discussed
it before, it bears repeating that to configure the recovery agent policy for your environment, you
access the appropriate GPO(s). In Group Policy, select Computer Configuration, Windows
Settings, Security Settings, Public Key Policies, then click Encrypted Data Recovery Agents.
This is shown below in Figure 9.9.

274

Chapter 9

Figure 9.9: Configuring EFS recovery agent policy.

Having the recovery agent information stored as part of Group Policy ensures that all computers
within the scope of the configured GPO enforce the configured recovery policy. As you can see
above, for computers that are members of a domain, the default recovery policy configures the
local Administrator account of the initial domain controller to act as the recovery agent for the
domain. For standalone computers, the local Administrator account is configured to act as the
recovery agent for the computer. In either event, you dont want any Administrator account
acting as an EFS recovery agent, so you should reconfigure this setting as soon as possible.
Choosing to configure the recovery policy using no recovery agents disables EFS for all computers
under the influence of the configured GPO.

Using EFS
Once you have a valid EFS user certificate and have established an appropriate recovery policy
for your environment, you can begin using EFS. If you dont have a valid EFS certificate, EFS
attempts to obtain one from an available enterprise CA in your environment. When an enterprise
CA isnt available, or when the computer isnt a domain member, EFS generates a self-signed
certificate on your behalf. This self-signed certificate is a single-purpose certificate that can only
be used for EFS; it isnt automatically trusted by others. As a result, its not going to have the
universal use of a standard user certificate issued by an enterprise CA.

275

Chapter 9
With Windows Explorer
When you encrypt a file, EFS keeps track of this using an attribute associated with the file. You
can use the graphical user interface (GUI) supplied by Windows Explorer to check whether a
selected file is encrypted. See Figure 9.10 below.

Figure 9.10: Using Windows Explorer to view the encryption status of a file.

The easiest way to encrypt a file is using Windows Explorer. Right-click the file, then select
Properties from the shortcut menu. On the General page of the Properties dialog box, click
Advanced to display the advanced attributes for the file, then select the Encrypt Contents to
Secure Data check box.
While that is all you do to encrypt a file, encrypting a folder requires making an additional
decision. When you encrypt a folder, youre asked whether you want to also encrypt all of its
files and subfolders. This is what the alternatives mean.

Encrypting the files and subfolders encrypts the current folder and its contents as well as
any files and folders you later add to the folder

Encrypting just the folder doesnt encrypt any of its files or subfolders, but it does
encrypt all future files and subfolders that you add to the folder!

As you can see, depending on how you choose to encrypt a folder, things can get a little
confusing. I recommend that you always encrypt all files and subfolders. This keeps things
simple and ensures that all of the files and folders in your encrypted folders are in fact encrypted.

276

Chapter 9

With Cipher.exe
Win2K also supplies cipher.exe, a command-line tool that allows you to view files encryption
status and to encrypt and decrypt files. The cipher command is a standard Win2K command, and
you dont need to install the Windows 2000 Resource Kit to use it.
When you use the cipher command without options, it displays the current encryption state of the
current folder and any files that it contains; this is shown below in Listing 9.2. To the left of each
entry is a designation for the encryption status of the files. The letter E means that a file is
encrypted, and the letter U means that its unencrypted.
C:\Encrypted Folder>cipher
Listing C:\Encrypted Folder\
New files added to this directory will be encrypted.
E
E
E
E
E

Image.bmp
Worksheet.xls
File.txt
Document.doc
Zipped.zip

C:\Encrypted Folder>
Listing 9.2: Using cipher.exe to display the encryption status of the current folder and its files.

You can also use the cipher command to encrypt and decrypt files. For example, to encrypt, then
decrypt, all of the files with a .doc extension, enter the following commands:
cipher.exe /e /a *.doc
cipher.exe /d /a *.doc

The cipher command is one command-line tool that you should become familiar with, even if
you use Windows Explorer to display or alter the encryption status of files in your environment.
With Efsinfo.exe
You should also get to know efsinfo.exe, the Windows 2000 Resource Kit tool designed to allow
you to view specific information about EFS files. Running the efsinfo tool displays information
about the EFS user account and the recovery agent accounts that have been used to protect a file,
as shown in Listing 9.3.
C:\Encrypted Folder>efsinfo.exe /u /c /r /i /y *.doc
Your current EFS certificate thumbnail information on the PC named
Merion is:
0CDA F155 9F39 4D70 7A41 0EE5 568D AFA0 F8EC CAA5
C:\Encrypted Folder\
Document.doc: Encrypted
Users who can decrypt:
CyberDomain\Paul.Cooke (OU=EFS File Encryption Certificate, L=EFS,
CN=Paul.Cooke)

277

Chapter 9
Certificate thumbprint: CAA5 0CDA F155 9F39 4D70 7A41 0EE5 568D AFA0
F8EC
Recovery Agents:
CyberDomain\Recovery.Agent (OU=EFS File Encryption Certificate, L=EFS,
CN=Recovery.Agent)
Certificate thumbprint: 17CF 3FE3 3497 236C CC6F 5005 F407 C5B7 B2BA
08C9
C:\Encrypted Folder>
Listing 9.3: Using efsinfo.exe to view specific information about EFS files.

One of the most important things that the efsinfo tool tells you is which certificates are required
to decrypt a file. The information that is listed is the information contained in the DDF and the
DRFnamely, the EFS header information. In addition, pay attention to the Certificate
thumbprint field. If you have many certificates, you can use the thumbprint to identify which
certificate is required to recover the ciphertext portion of the file.
Recovering Encrypted Files
To recover an encrypted file, your recovery agent needs to gain access to it. For small
organizations in one physical location, it might be easiest to have the recovery agent bring its
private key to the users computer. The recovery agent can install its private key on the
computer, recover the file(s), then remove its private key from the computer.
If it isnt practical for the recovery agent to travel to the computer, the file(s) have to be moved
to the recovery agents computer. Its been suggested, even by Microsoft, that this is easily done
by having the poor user who has lost their ability to decrypt their files use a secure protocol such
as S/MIME to email their files to the recovery agent. This may not be all that practical because if
a user has lost their EFS private key, theyve probably also lost their S/MIME private key!
Once youve resolved the issues of getting the private key of one of your recovery agents and the
files that need to be recovered onto the same computer, you use the cipher command to recover
the files. Once the files have been recovered, they should be returned to their owner with a
secure protocol to maintain their confidentiality.
Whenever youre recovering another users files, I recommend that you never do it alone; always
have a second recovery agent or even the user themselves present. Its a good idea to have a
witness to ensure that the data is kept confidential.

You should also ensure that when you return recovered files to your users, they have a way to
protect them once again. Consequently, when you develop EFS recovery procedures for your
environment, make sure that users retrieve a new EFS certificate before returning their recovered
files to them.

278

Chapter 9

Keeping Protected Files Protected

Its reasonable to assume that files protected by EFS have been protected for a reason. As an
administrator, your job is to ensure that protected files arent left unintentionally unencrypted.
Consequently, you need to do a number of things to ensure that files that have been protected
using EFS remain protected.

Always encrypt folders, not individual filesThis is important because when you edit
files, some applications create temporary files in the same folder as the original files. If
you encrypt individual files, these temporary files wont be encrypted, and when you
save your edits, the applications may substitute the temporary files for the originals. If
you always encrypt at the folder level, youll ensure that files arent left inadvertently
unencrypted.

Encrypt users My Documents and Temp foldersMost applications store users

documents in their personal folders, so encrypting the My Documents folder safeguards
each users personal documents. Encrypting the Temp folder helps you avoid potential
information leaks that may occur when applications create temporary files.

Ensure that the recovery agents private keys are handled properlyPoor handling
of private keys by individual users may expose their own files, but poor handling of a
recovery agents private keys can compromise many users files. For this reason, its
important to securely store all recovery agents private keys. At the very least, export the
private keys for recovery accounts, remove them from the computer where theyre
located, and store them in a safe place. This ensures that someone logged in as a recovery
agent cannot read files that others have encrypted.

Archive the private keys and certificates for your organizations recovery agents
You need to do this so that you can recover encrypted files that were created under a
recovery policy that is no longer enforced. Establish a two-tier archive methodology: The
first tier is located on site to recover files as required by your users; the second tier is
stored in an offsite location in case disaster strikes.

Clear the paging file when the computer shuts downAlthough EFS ensures that
FEKs are never written to disk in unencrypted form, the plaintext contents of a file can
reside in the paging file of an operating system (OS). A simple solution might be to
encrypt the paging file, but you cant do this because paging files are marked as system
files. Unfortunately, if paging space isnt heavily used, a plaintext representation of an
encrypted file could spend a considerable amount of time being written to disk. To
protect against this possible information leak, use Group Policy to configure all of the
computers that have an EFS recovery policy defined for them to clear the paging files
when they shut down.

Remove the default recovery agents immediately from all domainsThe default
recovery agent is the Administrator account of the first domain controller installed.
Although you have other problems to deal with, this helps protect your users data if the
Administrator account is compromised. In addition, using an explicit account for
recovery operations increases the ability to audit the actions of your recovery agents.

279

Chapter 9
EFS Limitations
While EFS sounds like a great thing, it does have some limitations. If youre aware of them, you
can deploy EFS and deal with a minimum of operational issues.

EFS-protected files cannot be sharedOnly the user who encrypted a file can open it
(recovery agents excluded)

Only Win2K NTFS volumes support EFSAs a result, encrypted files become
decrypted when you copy or move them to a drive that isnt a Win2K NTFS volume

Moving a file or folder into an encrypted folder doesnt automatically encrypt it You
need to drag and drop the file into the folder

You cant both encrypt and compress files and foldersIf you need to encrypt files
and folders stored on a compressed volume, uncompress them before encrypting them

Files and folders that have the system bit set cannot be encryptedThis ensures that
a computer can start up. EFS wasnt designed to encrypt your entire hard drive

Encrypted files and folders are still controlled by access control lists (ACLs)
Therefore, anyone who has permission to delete an encrypted file or folder, and tries to
do so, will be successful

Encrypted files and folders that are accessed over the network using a share arent
protected as they pass over the networkTo protect the confidentiality of a file as it
passes over your network, consider implementing IPSec

Including an encrypted file in an email message as an attachment removes the encryption

property from the fileTo protect the confidentiality of the file, you need to use
S/MIME encryption.

Issuing Smart Cards

I described smart cards back in Chapter 4 as part of Win2K authentication. As a result, there
isnt a whole lot to discuss here other than how to issue smart cards to your users. As a result, Ill
talk quickly about the three major steps you need to take to issue smart cards that your users can
use to log on to the computers in your environment. These steps are: set up a Smart Card
Enrollment Station, obtain an enrollment agent certificate, and issue the smart cards.
You can set up an enrollment station on any Win2K computer in your environment, including a
Windows 2000 Professional installation. The only requirements for the station are that a smart
card reader is installed and operational on the computer and that it has network access to the
Certificate Services Web pages for one of your enterprise CAs.
Once the enrollment station is set up, you need to obtain an enrollment agent certificate from one
of your enterprise CAs. Possessing such a certificate allows you to generate smart card certificate
requests on behalf of other users. By default, only domain administratorshave the permission
required to obtain this type of certificate, so you may want to modify the ACLs on the
appropriate certificate template to a group of smart card administrators.

280

Chapter 9

You may be tempted to use a smart card to store your enrollment agent certificate, but dont. Using
multiple smart card readers on a single computer is problematic at best, and youll avoid a lot of
hassle if you just request an enrollment certificate and store it on the local hard drive.

Once youve obtained an enrollment agent certificate, you use the Certificate Services Web
pages to install a certificate on another users smart card. As you go through the Web pages,
select the following options: Request a Certificate, Advanced Request, then Request a Certificate
for a Smart Card on Behalf of Another User Using the Smart Card Enrollment Station. This last
option is shown in Figure 9.11 below.

Figure 9.11: Using the Certificate Services Web pages to install a certificate on another users smart card.

As you begin issuing smart cards to users, youll be contending with a mixed environment in
which some folks are logging in using their smart cards and others are logging in using their user
names and passwords. As a result, you need to allow your users to use both smart card
authentication and the CTRL+ALT+DEL secure logon sequence. This mix of strong and weak
authentication schemes weakens the overall security stance of your Win2K infrastructure;
therefore, you need to configure the user account policy to require smart cards to log on
interactively for each of the users whove been issued smart cards.

281

Chapter 9

Using Software Signing and Authenticode

Authenticode is Microsofts implementation of a code-signing mechanism that can be used to
verify that:

The software was truly released by the claimed authors

It hasnt been tampered with since it was released.

Authenticode allows software vendors and developers to digitally sign code using standard
digital signatures. As a result, you can verify the publisher of a digitally signed software package
and the fact that it hasnt been tampered with before its installed or executed.
Using Certificate Services, you can issue digital certificates to developers in your organization.
You can have all internally developed code signed before its distributed in your Intranet
environment. Only if the code was signed by one of your trusted CAs is it installed and/or
executed.
Software signing and Authenticode technology are used not only in IE but also to help you
control the behavior of software installation. Ive discussed this before, but remember that in
Group Policy, you can set policies for:

Unsigned driver installation behavior

Unsigned non-driver installation behavior.

These two policies let you control how youre going to react to software that isnt digitally
signed. Your options are to silently succeed, warn but allow installation, and dont allow
installation. No matter which option you choose today, in the future, all software will be digitally
signed in one fashion or another.

Applying Internet Protocol Security

The Internet Protocol Security (IPSec) standard is clearly poised to be the long-term solution for
securing network communications. The key here is securing network communications because
IPSec is really targeted at providing two key services.

Protecting IP network packets

Providing defense against network attacks.

IPSec provides these two services using end-to-end encryption at the network layer of the Open
Systems Interconnection model (OSI).
The Win2K implementation of IPSec is based on the work done by the Internet Engineering
Task Force (IETF) IPSec working group. IPSec implements an end-to-end security model for
network communications whereby each computer at the end points of a network communications
channel must handle the security at its end. This allows computers engaged in IPSec
communications to handle the security of the network channel, and they can assume that the
actual physical medium isnt secure.

282

Chapter 9
Why You Need It
So far, Ive described a number of the security mechanisms built into Win2K. Unfortunately,
they all revolve around providing appropriate security controls for information and data that
resides on or is being processed by a Win2K host. I havent talked about any generic mechanism
to protect data as it travels over your network.
For example, I just talked about EFS and how it protects information that is stored on the disk
drives of your Win2K computers. Unfortunately, if youre accessing an EFS-protected file that
resides on a remote network share, its decrypted as it passes up through the Win2K kernel; by
the time it reaches the network, its passed in clear-text. So you went to all this trouble to protect
the persistent storage, but you didnt protect the file from undesired tampering or disclosure as it
passed over your network.
Obviously, you may have faith in the physical security of your network infrastructure. But in
reality, you probably dont have really tight physical security. For example, youre not running
all your cables within metal conduit, youre not restricting access to all network jacks, and
youre not appropriately restricting access to your network wiring closets. Even if you can ensure
all of these things, what about communications with remote office locations, where you dont
physically oversee the network infrastructure? What about communications with partners and
suppliers?
In the final analysis, physically securing the network isnt really practical in your environment,
and you cant assume its being done elsewhere. As a result, your corporate data is susceptible to
a number of security compromises as it passes through your network.

EavesdroppingIf an attacker gains access to the data paths of your network, they can
eavesdrop on communications that pass through the data paths theyve gained access to.

Modifying dataIf an attacker can eavesdrop, who is to say that they wont take the
next step and alter the data as it passes through your network?

Spoofing IP addressesAn attacker can construct IP packets to appear as if they

originated from within your network and trick your network security controls into
allowing the packets to pass. The attacker can then modify, reroute, or destroy data on
your network.

Grabbing passwordsMany legacy applications and even some poorly designed new
ones send user names and passwords over the network in either clear-text format or a
format that is easily compromised. If an attacker has gained access to your network, they
can capture user name and password combinations of the legitimate users in your
environment and steal their identities.

Denying serviceAn attacker can either send invalid network traffic to your computers
to try to crash them or flood your computers with legitimate traffic in the hope of
exhausting your systems resources. In either case, the attacker is trying to occupy your
computers with network traffic of no legitimate consequence to try to disrupt valid traffic.

283

Chapter 9

Man in the middleAn attacker can pose as a legitimate entity to not one, but two,
parties in the hope of monitoring, controlling, or altering communications between two
computers on your network. For example, computers A and B may want to communicate,
but if computer C successfully pretends to computer B that its computer A and viceversa, computer C can sit in the middle!

Compromising applicationsAn attacker can target applications in your environment

and exploit known vulnerabilities to compromise your applications. This compromise can
give the attacker access to either part of, or in the worst case the entire, OS.

IPSec Services
IPSec was designed to secure network communications by encrypting individual IP packets
before theyre sent out onto your physical network. As a result, IPSec can protect against the
attacks discussed above as well as many others. It does this by encrypting IP packets at the
network layer for all outgoing packets, no matter which applications are responsible for sending
the packets. This provides transparent network-level security for any application and provides a
mechanism that you can deploy without modifying applications.
While encryption is the main component that many think about when discussing IPSec, IPSec
also provides a number of services to you and your environment.

Anti-replayCryptographic techniques allow IPSec to ensure that an attacker cannot

reuse or replay captured IP packets. As a result, an attacker cannot intercept a network
packet and replay it to gain illicit access to your network resources.

AuthenticationIPSec uses multiple techniques to establish the identities of other

computers and thus ensure that communications are taking place among the appropriate
computers. IPSec in Win2K can use pre-shared keys, digital certificates, or Kerberos as
an authentication mechanism.

ConfidentialityEncryption allows IPSec to ensure that data sent across a network isnt
disclosed to attackers. Because encryption key(s) are only held by the sender and receiver
of the network packets, confidentiality of data can be assured, and others cannot read the
data even if its eavesdropped or intercepted.

IntegrityIPSec uses cryptographic hash message authentication codes (HMACs),

which prevent unauthorized modification of IP packets as they traverse your network.
This is accomplished using a unique key, shared by the sender and receiver of an IP
packet, that calculates the HMAC value for each packet. As a result, an attacker cannot
modify a packet in transit without the receiver detecting the modification and discarding
the packet.

Non-repudiationDigital signatures allow IPSec to verify that a network packet

actually originated from the purported sender and not from an imposter. As a result, the
sender cannot deny having sent the message.

IPSec provides these services in a few different ways, but its encryption services are optional and
may not be applied to every conversation that uses the protocol. Whether or not each packet is
encrypted is a matter of the IPSec policy, which Ill discuss later in this chapter. (See Creating
an IPSec Policy.)

284

Chapter 9
The Four Modes of Operation
The IPSec protocol provides its security services by modifying the original structure of each IP
packet. For our purposes, IPSec provides two types of security services: Authentication Header
(AH) mode and Encapsulating Security Payload (ESP) mode. IPSec can also provide tunneling
for each of these modes, thereby providing four basic types of operation. When an IP packet is
tunneled, its encapsulated inside a new packet, and the tunnel provides the logical data path
through which encapsulated packets travel to their final destinations.
These four modes are described below.

AH modeProvides authentication, integrity, and anti-replay for an entire IP packet.

This includes both the IP header and the data portions of the packet. Because AH mode
doesnt ensure that the data remains confidential, the data is readable to an attacker, who
can obtain an AH-protected packet. However, the HMAC signing of this mode ensures
that an attacker cannot modify the data. You can use AH mode by itself or in conjunction
with ESP mode.

ESP modeProvides the same services as AH mode, but with two differences: It adds
confidentiality, but it protects only the data portion of an IP packet, not the entire packet.
It signs just the IP data payload of a packet, not the IP header information.

ESP tunnel modeEncapsulates the entire original IP packet and adds new header and
footer information to the packet. The original packet header carries the ultimate source
and destination addresses of the packet, while the outer IP header contains the address of
an appropriate gateway to carry the packet to its final destination. The outer header
ensures that the packet is routed to the IP address of a tunnel server for the receiving
network. The tunnel server is responsible for decrypting the packet, throwing away the
ESP header, and routing the packet to the final destination indicated in the original IP
header.

AH tunnel modeEssentially the same as ESP tunnel mode, except that the original
packet is encapsulated in a different manner. While AH tunnel mode signs the entire
packet to ensure its integrity, just as in regular AH mode, the data payload of the packet
isnt encrypted.
Just like regular AH and ESP modes, you can combine the tunnel modes of these
protocols to ensure the integrity of the entire packet as well as the confidentiality of the
original data portion of the packet.

Using Predefined Configurations

You need to face one fact early on: If you start from scratch without much of an idea of how to
make things work, configuring IPSec can be a little tricky. Realizing this, Microsoft built three
predefined configurations into Win2K: Client, Server, and Secure Server. These configurations
provide canned policies that you can use to understand the different behaviors that are possible
using the IPSec policy settings that are available to you.

285

Chapter 9
The key portion of this last statement is to understand. That is because these predefined
configurations arent really intended for deployment in your environment. Instead, theyre
included for deployment-testing purposes and to help educate users about how IPSec can work in
an environment. These predefined policies can be found in a Group Policy Object (GPO), as
shown below in Figure 9.12. Thus, youll find that IPSec policy is best maintained using ADbased GPOs and not individual local GPOs.

Figure 9.12: Viewing predefined IPSec policies.

Each policy provides the following:

ClientA mechanism to negotiate IPSec communications as requested by other

computers. By default, it initiates all network communications without using IPSec but
can use the network security protocol when requested by another party.

ServerA mechanism whereby all outgoing network communications use IPSec, but the
computer is allowed to accept unsecured network sessions. Thus, this policy allows
communications to be unsecured if the other computer isnt able to use IPSec.

Secure ServerA mechanism that requires all communications, outgoing and incoming,
to be secured using IPSec. As a result, this policy wont allow a computer to talk to a
non-IPSecenabled computer.

286

Chapter 9
While these predefined policies were intended as guides, in a homogenous Win2K environment,
its possible to roll them out without a whole lot of trouble. However, there is one pitfall that I
caution you to think about before going wild and deploying the Secure Server policy across your
entire environment. The dilemma arises when youve set up all of your servers to require IPSec
network communications, but you want to add a new computer to the domain.
Because the computer isnt yet part of the domain, you cannot use Kerberos authentication, nor
can you easily use certificate-based authentication if youre using enterprise CAs. Your only real
option is to use the shared secretbased mechanism to authenticate the new computer and
establish the appropriate network connections so that the computer can join the domain.
Unfortunately, you also have to configure the client by hand because its not a member of the
domain, so it cant have IPSec policy applied to it from AD.
As you see, this problem spirals quickly into the murky depths. There are a number of ways to
get around it; the easiest is to only use the Server policy as a starting point and not lock all of
your network communications down securely. If your organization uses an Intrusion Detection
product, you can monitor for non-IPSec traffic and follow up if it looks suspicious.
Creating an IPSec Policy
Like a number of other configuration tasks in Win2K, creating an IPSec policy is handled using
a configuration wizardin this case, the IP Security Policy Wizard. To start the wizard, open the
appropriate GPO, right-click the IP Security Policies node of the MMC snap-in console, then
choose Create IP Security Policy from the shortcut menu.
The wizard guides you through creating an IPSec policy. In addition to giving it a name and
description, you choose the authentication option, as shown below in Figure 9.13. While the
default authentication mechanism for an IPSec policy is Kerberos, you can select certificates or
pre-shared keys instead. This figure also shows that if you want to create multiple authentication
options, you need to edit the default response rule after youve completed the wizard.

Figure 9.13: Using the IP Security Policy Wizard to choose the authentication option for a new IPSec policy.

When youve created the IPSec policy, you can configure its rules, filters, and filter actions.

287

Chapter 9
Configuring Rules
Once youve created an IPSec policy, you can add rules to it. In the MMC snap-in console, rightclick the policy, then choose Properties from the shortcut menu. In the policys Properties dialog
box, click Add. This displays the Security Rule Wizard, which walks you through the steps
required to create an IPSec rule. If the rule will apply to an IPSec tunnel, you have to specify the
IP address where the tunnel will be terminated. Next, you specify which network connections the
rule will apply to. As the wizard progresses, you select one or more IPSec filter actions that
should be applied to the rule.
You can create as many IPSec rules in a policy as necessary. You can then toggle which rules are
active for a policy using a set of check boxes in the policys rules list. You can also apply
different security rules to different network connections by enabling multiple rules at a time.
Configuring Filters
You can configure each IPSec rule that you create. In the policys Properties dialog box, select
the rule you want and click Edit. In the Edit Rule Properties dialog box, click the IP Filter List
tab. On the IP Filter List page, you can configure the parameters that control how the rule is
applied, as shown below in Figure 9.14. This page allows you to define which communications
the rule will apply to, and it always contains two default filters: All ICMP Traffic and All IP
Traffic. While these filters apply in many situations, if you dont want either of them to apply to
all of your computers IP or Internet Control Message Protocol (ICMP) network connections,
you need to create new filters.

Figure 9.14: Using the Edit Rule Properties dialog box to specify filters for a rule.

288

Chapter 9
You can add new filters by, you guessed it, using the Add Filter Wizard. In the Edit Rule
Properties dialog box, click Add. As before, the wizard guides you through the steps required to
create an IP filter list, which you can apply to your IPSec rules. One of the things you need to be
aware of is that when you create a filter, the wizard actually creates a pair of filters so that
network traffic can flow in both directions. If you dont want a symmetric rule, you need to
delete the extra filter when you finish the wizard.
Configuring Filter Actions
After you create a filter, you finish configuring your IPSec policy by creating the appropriate
IPSec filter actions. Filter actions specify the type of security that the rule should apply to when
the filter list applies. Again, to configure filter actions, you use a wizard, this time the IP Security
Filter Action Wizard.
In the Edit Rule Properties dialog box, click Add The wizard walks you through the steps
necessary to configure and apply filter actions. You specify one of three basic security options
for these filter actions: permit the communications, block the communications, or negotiate the
security of the communications. You also choose to allow either unsecured communications
using non-IPSec enabled computers or all communications using only computers that support
IPSec. Then you select the security method for the filter action.

High securityUses IPSec in ESP mode

Medium securityUses IPSec in AH mode.

If you want to specify both ESP and AH modes, you need to click Custom instead of selecting a
single IPSec mode.
Keeping an Eye on IPSec
Thankfully, Win2K provides IPSec Monitor (ipsecmon.exe), a tool that you can use to confirm that
your network security policies are being applied successfully. Using this tool, you can display the
active IPSec communication channels that are open and gain useful information about how IPSec is
really working in your environment.

Using Virtual Private Networks

A Virtual Private Network (VPN) may or may not have anything to do with your PKI, but if you
use IPSec as a basis for your VPN solutions, using certificates is one authentication method that
is available to you.
The Point to Point Tunneling Protocol (PPTP) is available in Win2K and can be used as a VPN,
but I dont recommend it. Its true that the implementation security issues that existed in earlier
versions of PPTP have been fixed in Win2Ks version of PPTP, but I see no reason to use the
protocol when IPSec is available.

289

Chapter 9
There is, however, another protocol that you can pair with IPSec to strengthen your Win2K VPN
solution: the Layer 2 Tunneling Protocol (L2TP). Using L2TP over IPSec is arguably the most
secure way to allow users to connect to your environment over the Internet. Remember, IPSec
authenticates connection end points of secure network connection and ensures the integrity and
confidentiality (amongst other things) of network traffic. While this is a good thing, it does
ignore an important factorauthenticating the user!
This is one of the ways in which L2TP adds value: It allows you to authenticate the user on the
other end of the IPSec connection. L2TP can perform user authentication by using a user name
and password, a smart card, a certificate, or a token card that uses the Extensible Authentication
Protocol (EAP). The easiest way to look at this is that L2TP provides the tunnel for the data, and
IPSec secures the tunnel.
Explaining how to set up a VPN in your environment is beyond the scope of discussing the PKIenabled features of Win2K. I suggest that you read up on the Routing and Remote Access (RRAS)
service to become familiar with the native VPN capabilities embedded in Win2K.

Summary
As you can see, the PKI features embedded in Win2K go well beyond issuing certificates and
including the Certificate Services CA functionality. Rich features such as EFS, S/MIME, IPSec,
and Authenticodeas well as management features such as the Certificate Services Web pages
and the Certificate Managerround out the CA functionality. All of these features show that
Win2K has a very strong collection of native, built-in, and free PKI tools that you can use to
strengthen the overall security posture of your environment. You hopefully now have the desire
to go beyond what Ive talked about here and make PKI a reality for your organization!

290

Chapter 10

Chapter 10: Internet Information Services

The security of Microsofts Internet Information Services (IIS) has come to the forefront after a
security analyst at Gartner Group urged companies to drop IIS because of viruses such as Code
Red and Nimda. These viruses were aimed at unpatched vulnerabilities, and they infected
hundreds of thousands of computer systems running IIS. As a result of the bad press, the Netcraft
Web Server Survey of Web server software usage of Internet-connected computers estimated
that more than 300,000 IIS servers were removed from the Internet during October 2001.
However, all is not lost, for in this chapter you are going to learn about the security mechanisms
that are available to you within IIS, and how to configure them to ensure the security of your IIS
Web sites. We will cover the authentication mechanisms, access-control mechanisms, and
auditing mechanisms that you can utilize. In addition, we will cover Secure Sockets Layer (SSL)
in depth, and the steps you should take to make sure that your IIS installations are secure.

Authentication
It may not be intuitively obvious, but all users that utilize an IIS server must be authenticated
before they can gain access to the resource they are requesting. This authentication is done to
ensure that each and every HTTP request that the server responds to is done within the security
context of a user account. Even though the core functions of IIS run under the System account,
each response to a client request is accomplished within the context of another user account. As a
result, the specific operations that can be performed in response to an HTTP request are limited
by the rights and privileges afforded to the user account whose context is utilized. As a result, IIS
supports five separate authentication models: anonymous, basic, digest, integrated, and
certificate. Four out of the five authentication methods can be configured in the Authentication
Methods dialog box, which Figure 10.1 shows.

Figure 10.1: Configuring four of the five IIS authentication methods.

291

Chapter 10
The fifth authentication method, certificates, can be configured only when IIS is configured to
support secure communications. We will talk about how to set up IIS to take advantage of secure
communications, and well go into more detail about certificate-based authentication later in the
chapter. In the meantime, we will use the next few sections to take a brief look at each of the five
authentication models.
Anonymous Authentication
When anonymous authentication is used, IIS actually performs no authentication at all! When a
client requests access to an IIS resource that is configured for anonymous authentication, IIS
simply maps the user to a local account on the system. You may have run across the
IUSR_computername user account in the past and not known what it is used for. That user
account is the default user context under which all anonymous authentication Web requests are
run under IIS. As a result, Windows 2000 (Win2K) uses the IUSR_computername account
whenever IIS uses anonymous authentication so that a legitimate user account is actually used
for all non-trusted anonymous access to IIS resources.
Basic Authentication
Basic authentication is one of the earliest standard mechanisms that allowed users to type in their
username and password. With this authentication method, IIS will cause users Web browsers to
prompt for a username and password that are collected, Base-64 encoded, and sent back to the
Web server. IIS uses this information to authenticate the identity of users and run requests on the
users behalf. When users enter their usernames, they can optionally include a domain name in
the standard form domain\username. If the domain name is not specified, IIS assumes a default
domain that you must configure. If the user does not specify the domain name and IIS does not
have a default domain set, only the local computer accounts can be authenticated.
Basic authentication transmits the username and password essentially in the clearBase-64
encoding does nothing to protect the password while the password is sent over the network. I
recommend against ever using basic authentication by itself. However, running basic authentication
over SSL is a secure method commonly utilized to authenticate a user.

Digest Authentication
Digest authentication proves users knowledge of their passwords without transmitting the
passwords in the clear. This authentication is accomplished using a challenge-response
mechanism that is defined by the Internet Engineering Task Forces (IETFs) Request for
Comments (RFC) 2069. Digest authentication is carried out in five simple steps:
1. The server sends a challenge to the browser. The challenge includes the client computers
identity, the domain/realm, and the current time.
2. The browser prompts the user for his or her username and password.
3. The browser hashes the password with the challenge, creating a thumbprint, and sends
both the original challenge and the thumbprint.
4. The server hashes its copy of the users password with the challenge, creating its own
thumbprint.
5. The server compares the two thumbprints; if they are identical, the user is authenticated.
292

Chapter 10

As you can see from Step 4, for digest authentication to work, the server must have access to a plaintext copy of the users password. An additional constraint of digest authentication is that it requires
that the user accounts reside within a domain. Put together, this means that youre required to store
the passwords in a reversibly encrypted form within Active Directory (AD)! This would be a very bad
idea indeed. As a result, I recommend never using digest authentication in any form or fashion!

Integrated Windows Authentication

Integrated Windows authentication is what I look at as authentication for free in a homogenous
Win2K environment. It essentially uses either Kerberos or NT LAN Manager (NTLMfor
downlevel clients) to automatically authenticate a user to IIS over standard HTTP. When using
integrated Windows authentication, a users browser will use the users domain credentials if the
user is logged onto a domain and the user presents the credentials to IIS. These credentials will
take the form of either a Kerberos ticket or an NTLM hash.
Integrated Windows authentication is available only in Internet Explorer (IE) 2.0 and later. Kerberos is
available only in IE 5.0 and later; it does not work through proxies, and works only if both the client
and server participate in Win2K domains with established trust relationships. As a result, I
recommend using this authentication method only for your intranet environments.

Certificate Authentication
Certificate authentication allows users to establish their identities by using a digital certificate.
To use certificate authentication, IIS must be configured to utilize the SSL protocol. An entire
section of this chapter is devoted to SSL, so we will talk more about SSL and certificate
authentication a bit later on.

Access Control
The access control of IIS resources is accomplished through a combination of core Win2K
mechanisms and IIS-specific mechanisms. Logically speaking, there are four basic accesscontrol mechanisms, as Figure 10.2 shows, that combine to determine whether a user has access
to an IIS resource.

293

Chapter 10

Figure 10.2: Access control within IIS.

The access-control flow is tied to the authentication mechanisms to function together in the
simple process outlined in Figure 10.2. IIS receives a request for some Web resource. IIS may or
may not have to explicitly authenticate the user, but IIS determines which user context the
request will be satisfied under. IIS then validates that the IP address/DNS name of the client is
allowed access, and responds with a 403 Access Forbidden message if access is denied. IIS can
then validate the user credentials from the previous step, and responds with a 403 Access
Forbidden message if access is denied. Then IIS validates that the Web access method is
allowed, and responds with a 403 Access Forbidden message if access is denied. Finally, IIS
validates that the NTFS permissions of the resource allow the requested access method, and
responds with a 401 Access Denied message if access is denied. If all access-control checks pass,
the request will be serviced.

294

Chapter 10

Network Address Access Control

IIS allows you to restrict service to certain IP addresses, ranges of IP addresses, hosts, and DNS
domains through the use of network address access-control mechanisms, as Figure 10.3 shows.
You can pull up the IP Address and Domain Name Restrictions dialog box for a particular Web
site through the IIS MMC snap-in by right-clicking the appropriate Web server resource,
selecting Properties from the pop-up menu, clicking the Directory Security tab, then clicking
Edit in the center of the tab.

Figure 10.3: IIS network address access control.

As you can see from the dialog box that Figure 10.3 shows, there are three main ways for
entering exceptions to who has or does not have default access to the Web site: single computer,
group of computers, or DNS domain name. A single computer is defined by a single IP address,
as Figure 10.3 shows with the entry 10.0.0.1. A group of computers is defined by an IP address
and a standard subnet mask, represented in the figure as 192.168.0.0 (255.255.0.0). A domain
name entry is defined either by the Fully Qualified Domain Name (FQDN) of a single computer,
or a subdomain with a preceding wildcard (*), as shown with *.microsoft.com.

295

Chapter 10
IIS Access Control
IIS comes with a few of its own access controls that allow you to restrict how resources are
accessed, control execute permissions, and provide some application-control settings as Figure
10.4 shows. You can access the settings for a particular Web resource through the IIS MMC
snap-in by right-clicking the appropriate Web server resource, selecting Properties from the popup menu, and selecting the Home Directory, Virtual Directory, Directory, or File tab (the tab is
dependent upon the resource you are modifying).

Figure 10.4: IIS access-control settings.

As you can see, there are six settings that you can utilize to control access to Web resources
through IIS: script source access, read, write, directory browsing, log visits, and index this
resource. Script source access allows users to access the source code of scripts and such if either
Read or Write permissions are also set. Read access allows users to read or download folders or
files. Write access allows users to upload files into a folder or change the content of an NTFS
write-enabled file. Directory browsing access allows a user to see listings of all the folders and
files in the virtual directory. Log visits controls whether visits to the folder are logged. Index this
resource allows the Indexing Service to include this directory in a full-text index of your Web
site.

296

Chapter 10
Additionally, you can control the level of program execution that is allowed for resources within
your Web sites with three options: none, scripts only, and scripts and executables. A value of
none will allow only static content such as HTML or image files to be accessed. A value of
scripts will allow only scripts such as Active Server Pages (ASP) to be accessed. A value of
scripts and executables will allow all file types to be accessed or executed.
Although it might not truly be an access-control setting, there is one other security-related setting
that Figure 10.4 shows that you should take notice of: Application Protection. This setting
determines whether applications are run in the same process as Web services (low), in an isolated
pooled process in which other applications are also run (medium), or in an isolated process
separate from other processes (high).
NTFS Access Control
The NTFS access control that IIS takes advantage of is nothing more than the same old accesscontrol mechanism built into Win2K itself. However, you should keep in mind the following
NTFS issues: A FAT file system provides no access-control mechanism, so always utilize NTFS;
control access through security groups not through individual user accounts; and use the standard
Windows Explorer interface to modify any permission on folders and files that IIS utilizes.
Permissions Wizard
The Permissions Wizard is a tool that is included as part of IIS. The wizard allows you to quickly
set the authentication methods, IP address restrictions, NTFS permissions for the folders and
files that make up your Web sites, and the IIS access-control settings we talked about earlier.
You can invoke the Permissions Wizard by right-clicking a Web resource within the Internet
Services Manager MMC snap-in, selecting All Tasks from the pop-up menu, then selecting the
Permissions Wizard menu item. Figure 10.5 shows one of the steps that the wizard walks you
through.

Figure 10.5: The IIS Permissions Wizard.

297

Chapter 10
The wizard will walk you through whether you want to inherit properties from existing IIS
settings or apply an access-control template. In addition to these options, you will be asked to
select how you want to deal with NTFS permissions as follows:

Replace directory and file permissions with the templateThis option resets all the
NTFS permissions in accordance with the selected template.

Leave the current permissions intact, and add the templateThis option does not modify
the NTFS permissions and overlays the access-control settings from the template.

Leave the current permissions intact, and do not apply the template permissionsThis
option makes no modifications to the current NTFS permissions and adds nothing based
upon the selected template.

Like most of the Win2K wizards, the Permissions Wizard is pretty intuitive to utilize and
provides you with a reasonable configuration on its own. However, I recommend that after you
configure everything for your Web site and run the wizard, go back through and check and tweak
the settings that it made. Although the wizard does a pretty good job on its own, human
understanding of how things should be optimally configured can still be better than the static
rules of the wizard.

Auditing
Chapter 6 was all about auditing, so there is no need to go into the details of why auditing is an
important security service that you can utilize to not only hold your users accountable for their
actions but to also help troubleshoot systems. Like it does with access control, IIS layers some
custom auditing services on top of auditing services provided by Win2K. As a result, you end up
with three real auditing options available to you when you deploy IIS: auditing access to folders
and files, auditing server-wide events such as logon attempts to the OS, and auditing of IISspecific resources. You already know how to configure auditing on folders, files, and the system,
so we will concentrate on the auditing provided by IIS.
IIS Auditing
IIS allows for three types of auditing/logging that you can use to track what is going on with
your Web servers: the National Center for Supercomputing Applications (NCSA) Common Log
File Format, Open Database Connectivity (ODBC) Logging, and World Wide Web Consortium
(W3C) Extended Log File Format (which Figure 10.6 shows). You can access the audit settings
for a particular Web server through the IIS MMC snap-in by right-clicking the appropriate Web
server, selecting Properties from the pop-up menu, and clicking the Web Site tab. From this tab,
you can enable and disable auditing and select the type of log file that you want to write to.

298

Chapter 10

Figure 10.6: The IIS W3C Extended Log File Format properties.

Although three log formats are available, the most popular and the default format is the W3C
Extended Log File Format. As you can see in Figure 10.6, you can select how often your logs
rotate, whether to use your local time of GMT for file naming and rollover, and the location to
which the logs will be written. All of these options are available on the General Properties tab of
the Extended Logging Properties dialog box.
In addition to the general properties, you can also set the extended properties of the W3C
Extended Log File Format. Table 10.1 shows the options that are available under the Extended
Properties tab. You can choose the fields and actions that you want to be recorded in the log, but
you should include only fields and actions that you truly care about to keep the size of the log
file down.
Event to Log

Description

Date

The date on which the activity occurred.

Time

The time the activity occurred.

Extended Properties
Client IP Address

The IP address of the client that accessed your server.

User Name

The name of the user who accessed your server.

Service Name

The Internet service that was running on the client computer.

Server Name

The name of the server on which the log entry was generated.

Server IP

The IP address of the server on which the log entry was generated.

Server Port

The port number that the client is connected to.

299

Chapter 10
Method

The action the client was trying to perform (for example, a GET
command).

URI Stem

The resource accessed (for example, an HTML page, a CGI program,

or a script).

URI Query

The query, if any, the client was trying to perform (that is, one or more
search strings for which the client was seeking a match).

HTTP Status

The status of the action, in HTTP terms.

Win32 Status

The status of the action, in terms used by Windows.

Bytes Sent

The number of bytes sent by the server.

Bytes Received

The number of bytes received by the server.

Time Taken

The length of time the action took.

Protocol Version

The protocol (HTTP, FTP) version used by the client. For HTTP this
will be either HTTP 1.0 or HTTP 1.1.

User Agent

The browser used on the client.

Cookie

The content of the cookie sent or received, if any.

Referrer

The site that directed the user to the current site.

Process Accounting
Process Event

The type of process that triggered the event, either CGI or out-ofprocess application. The type can be CGI, Application, or All.

Process Type

What event was triggered:

Site-Stop: The Web site was stopped.
Site-Start: The Web site was started or re-started.
Site-Pause: The Web site was paused.
Periodic-Log: This is a regularly defined log entry whose
interval was specified by the administrator.
Reset Interval-Start: The Reset Interval has begun.
Reset Interval-End: The Reset Interval has been reached and
reset.
Reset Interval-Change: The Web site administrator changed
the value for the Reset Interval.
Eventlog-Limit: An event log was made for the Web site
because its CPU resource usage for CGI and out-of-process
application reached the event log limit set by the administrator.
Priority-Limit: The Web site had a CGI or out-of-process
application set to low priority because it reached the low
priority limit set by the administrator.
Process-Stop-Limit: The Web site had a CGI or out-of-process
application stopped because it reached the process stopping
limit set by the administrator.
Site-Pause-Limit: The Web site was paused because it had a
CGI or out-of-process application reach the site pause limit set
by the administrator.
Eventlog-Limit-Reset: The Reset Interval was reached or the
Eventlog-Limit was manually changed.
Priority-Limit-Reset: The Reset Interval was reached or the
Priority-Limit was manually changed.
Process-Stop-Limit-Reset: The Reset Interval was reached or
the Process-Stop-Limit was manually changed.

300

Chapter 10

Site-Pause-Limit: The Reset Interval was reached or the SitePause-Limit was manually reset.

Total User Time

The total accumulated User Mode processor time, in seconds, that the
site has used during the current interval.

Total Kernel Time

The total accumulated Kernel Mode processor time, in seconds, that

the site has used during the current interval.

Total Page Faults

The total number of memory references that resulted in memory page

faults.

Total Processes

The total number of CGI and out-of-process applications created

during the current interval.

Active Processes

The total number of CGI and out-of-process applications running when

the log was recorded.

Total Terminated Processes

The total number of CGI and out-of-process applications stopped due

to Process Throttling during the current interval.

Table 10.1: IIS W3C Extended Log File Format field options.

Administrative Security
As we have seen, you can administer IIS using the Internet Services Manager MMC snap-in.
You have the option of using it locally, remotely, or remotely through Windows Terminal
Services. By default, the only users that can fully administer IIS are the local Administrators
group. However, you can configure Web operators to a specific Web server as Figure 10.7
shows. You can add Web operators to a particular Web server through the IIS MMC snap-in by
right-clicking the appropriate Web server, selecting Properties from the pop-up menu, and
clicking the Operators tab.

Figure 10.7: IIS Web site operators.

301

Chapter 10
When a security group (adding individual users is possible, but please use only security groups)
is added to the list of Web Site Operators, the following is true for each of the group members:

They are the Web server administrators and can change and reconfigure the Web server
as required.

They are not permitted to change the identification of the Web servers, modify the
anonymous username or password, modify server bandwidth settings, create virtual
directories, or change application isolation settings.

Their privileges are more limited than Web site administrators; therefore, they cannot
remotely browse the file system of the Web sever or set permissions on folders and files.

Web Administration
In addition to the Internet Services Manager MMC snap-in, you have the option of administering
IIS through a set of Web pages. When IIS is initially installed, the IIS Administration Web Site
is assigned a random high-number port, configured with IP restrictions that allow access only
from the IIS server computer itself using the loopback address 127.0.0.1, and authentication is
set to integrated Windows. With this default configuration, I see no reason to use the Web
interface to administer IIS because you still have to log onto the local computer, and the
administrative Web interface offers only similar functionality to the MMC snap-in, not all of the
functionality of the MMC snap-in!
I recommend that you do not use the Web administration site and remove it from your system.
To do so, you will need to disable the IIS Admin Service and delete the IISAdmin virtual
directory from the Default Web Site. However, if you have a real need for remote administration
of your IIS servers, make sure that you enable SSL and require it, as Ill discuss later in this
chapter. You should also make sure that the IP address and domain name restrictions for the site
allow only a set of trusted hosts and not just anyone to connect.

SSL
One of the key security mechanisms of IIS is the utilization of the SSL protocol. Although
Netscape Communications originally developed it, SSL has become a de facto standard for
server authentication and encrypted communications between clients and servers on the Internet.
Although originally slated as a security protocol for Web transactions, SSL has become a widely
utilized mechanism for securing other application-layer protocols. For example, SSL was
originally applied to HTTP, creating the protocol we have come to know as HTTPS. SSL is also
utilized today to protect the Lightweight Directory Access Protocol (LDAP) and the Internet
Messaging Access Protocol (IMAP).
SSL first came into prominence with the release of SSL 2.0. This version of the protocol
encrypts the communications between a client and a server and authenticates a server to a client.
It cannot, however, authenticate a client to a server. SSL 3.0 offers the capability to authenticate
a client to a server and includes some minor changes to the inner workings to strengthen the
overall protocol. Finally, the IETF based its Transport Layer Security (TLS) 1.0 protocol on
SSL.

302

Chapter 10
For our purposes, we are not going to differentiate much between the SSL 2.0, SSL 3.0, and TLS
1.0 protocols and instead concentrate on a general discussion of how these protocols work to
provide security for your IIS-based Web traffic. In fact, we will refer to all three of these
protocols collectively as SSL for succinctness.
Protocol Basics
Although network communications on the Internet is based upon the Transmission Control
Protocol/Internet Protocol (TCP/IP), many of the other protocols that we typically use such as
HTTP, LDAP, and IMAP all run on top of TCP/IP. The SSL protocol is logically sandwiched
between TCP/IP and these application-layer protocols, as Figure 10.8 shows. As such, SSL
utilizes the services of TCP/IP on behalf of the higher-level, application-layer protocols. In fact,
SSL is typically implemented as a library that is utilized by and runs within the context of an
application binary.

Figure 10.8: SSL sandwiched between the application and TCP/IP layers.

Applications that take advantage of the SSL protocol provide for three basic security services:

Server AuthenticationSSL provides a mechanism that allows a user to confirm the

identity of an SSL-enabled server. An SSL-enabled client application can utilize publickey cryptography techniques to validate that a servers certificate has been issued by a
certificate authority (CA) that is in the clients list of trusted CAs and to validate that the
ID contained within the certificate matches the FQDN of the server.

Client AuthenticationSSL provides a mechanism to allow a server to confirm the

identity of a user. Using the same basic public-key cryptographic techniques, an SSLenabled server can request and validate that the users certificate has been issued by a CA
that is trusted by the server and to validate that the ID contained within the certificate
matches the ID of the user (typically an email address).

Secure CommunicationsSSL requires that all information transmitted between a client

and a server is encrypted by the sending application and decrypted by the receiving
application. This encryption of all SSL connection traffic provides for the confidentiality
of the communications between an SSL-enabled client application and an SSL-enabled
server application.

303

Chapter 10
To provide these three basic services, the SSL protocol is logically divided into two basic
subprotocols: the SSL record protocol and the SSL handshake protocol. The SSL record protocol
provides the definitions for the format used to transmit data. Understanding the SSL record
protocol is not really going to help you understand how SSL functions, so we will not cover it
here. The SSL handshake protocol, however, defines the series of messages that must be
exchanged between an SSL-enabled server and SSL-enabled client to establish an SSL
communications connection. In a nutshell, the SSL handshake protocol provides for five basic
functions:

Authenticate the server to the client.

Negotiate the cryptographic algorithms that the client and server both support.

Authenticate the client to the server (optional).

Generate shared secret keys.

Establish the encrypted SSL communications channel.

SSL Cryptographic Algorithms

The authors of the SSL protocol understood that client and server applications might need to
support a variety of cryptographic algorithms, or ciphers. As a result, the SSL handshake
protocol must negotiate which ciphers that both the client and server will utilize to authenticate
each other, to exchange certificates, and to establish session keys. Although the SSL protocol is
really cipher agnostic, there are a number of algorithms that you will run across that you should
be familiar with:

Data Encryption Standard (DES)A block-encryption algorithm

Digital Signature Algorithm (DSA)A digital authentication standard

Key Exchange Algorithm (KEA)An algorithm used for key exchange

Message Digest Number Five (MD5)A hashing algorithm

RC2 and RC4Stream encryption ciphers

RSAPublic-key algorithm for both encryption and authentication

RSA key exchangeKey-exchange algorithm based on the RSA algorithm

Secure Hash Algorithm (SHA-1)A hashing algorithm

Triple-DES (3DES)The DES algorithm applied three times

During an SSL handshake, a client and server exchange information that allows both of them to
identify the strongest available cipher suite (group of algorithms) that they have in common.
Identifying the strongest cipher suite is important; the one key piece of information that we did
not cover when we listed some of the more common ciphers was their relative strength. SSL
typically utilizes two levels of cryptographic strength: 128-bit and 40-bit. For our purposes, the
more bits involved in a cryptographic cipher, the stronger the algorithm. As a result, a 128-bit
cipher is significantly stronger than a 40-bit cipher.

304

Chapter 10

You should use 128-bit ciphers whenever possible because 40-bit ciphers are fairly easy to break. By
default, Win2K installs with only 40-bit ciphers. To upgrade to 128-bit ciphers, you should install
Service Pack 2 (SP2), which includes the original Win2K High-Encryption Pack update.

SSL Handshake Subprotocol

Each SSL session begins with a series of messages that are known as the SSL handshake. This
handshake authenticates the server to the client, negotiates the cryptographic algorithms that the
client and server both support, optionally authenticates the client to the server, generates shared
secret keys, and establishes the encrypted SSL communications channel. The nitty-gritty details
of the subprotocol are beyond the scope of what you need to know to understand how SSL really
functions. Basically, the handshake protocol process consists of the following steps:
1. The client application sends a message to the server application that contains the client's

SSL version number, cipher settings, some randomly generated data, and some other
miscellaneous information that the server will need to communicate with the client using
SSL.
2. The server application responds to the client with the server's SSL version number, cipher

settings, some randomly generated data, and other miscellaneous information that the
client will need to communicate with the server over SSL. In addition, the server sends its
own certificate to the client. If the server requires SSL client authentication, the server
will also request a copy of the client's certificate.
3. The client application uses the information received from the server to authenticate the

servers identity. We will talk more about the details of server authentication later, for
now, just accept that the client has a mechanism to validate the identity of the server. If
the server can be successfully authenticated, the protocol continues; otherwise, the SSL
connection cannot be established.
4. The client application creates a seed secret for the session, encrypts it with the servers

public key, and sends the encrypted seed secret to the server application.
5. If the server application requests the optional client authentication, the client application

digitally signs another piece of data that is known by both the client and server
applications and sends it to the server. The server application uses this digitally signed
data to authenticate the client. We will talk more about the details of client authentication
later; for now, just accept that the server has a mechanism to validate the identity of the
client. If the client can be successfully authenticated, the protocol continues; otherwise,
the SSL connection cannot be established.
6. The server application uses its private key to decrypt the seed secret. Then both the client

application and server application perform a series of cryptographic steps on the seed
secret to create a master secret.
7. The client application and the server application use the master secret to generate a

session key. The session key is utilized to perform symmetric key encryption and
decryption on data exchanged during the SSL session.

305

Chapter 10
8. The client application sends a message to the server application saying that it is ready to

encrypt the remainder of the communications with the session key. The client application
follows up with a separate, encrypted message to let the server application know that the
handshake is finished from the client applications perspective.
9. The server application sends a message to the client application saying that the server

application is ready to encrypt the remainder of the communications with the session key.
The sever application follows up with a separate, encrypted message to let the client
application know that the handshake is finished from the server applications perspective.
At the completion of these steps, the instantiation of the SSL session is complete, and the SSL
session has begun. As a result, the client and the server applications will utilize the session keys
to encrypt and decrypt all the data sent between them.
Server Authentication Process
An SSL-enabled client application will always authenticate the server that it is communicating
with when the SSL protocol is being utilized. As we discussed earlier, a server application will
always send a copy of its certificate to the client application. The certificate is utilized by the
client application to authenticate the identity being claimed by the server application. As we can
see in Figure 10.9, an SSL-enabled client application needs to answer four simple questions to
authenticate a server application.

Figure 10.9: Questions used to authenticate the server in an SSL handshake.

306

Chapter 10
The client must answer each of these four questions in the affirmative to authenticate the identity
of the server application with which the client is trying to establish an SSL communications
channel:

Is the certificate within its validity period? The client application validates that the
current date and time are within the range of the server certificates validity period. If the
current date and time are outside the range of the certificates validity period, the server is
not authenticated; otherwise, the client proceeds to the next step.

Is the issuing CA trusted? An SSL-enabled application must maintain or have access to a

list of trusted CA certificates. The client application pulls the distinguished name (DN) of
the CA that issued the servers certificate from within the servers certificate. The client
application then utilizes the DN to search for a match of a CA from within the list of
trusted CAs. If the issuing CA is not found within the list of trusted CAs, the server is not
authenticated; otherwise, the client proceeds to the next step. If the issuing CA is not
found on the list of trusted CAs, all is not necessarily lost. If the client can validate that
the issuing CA is contained within a CA hierarchy that ends in a CA that is trusted, the
server is authenticated and the client proceeds to the next step.

Does the issuing CA's public key validate the issuer's digital signature? The client
application utilizes the public key from the issuing CAs certificate to validate that the
digital signature of the servers certificate is authentic. If for some reason the server
certificate has been altered since it was signed by the issuing CA, or if the public key you
have in your trusted CA list does not correspond to the private key that signed the
servers certificate, the server is not authenticated; otherwise, the client proceeds to the
next step.

Does the domain name in the server's certificate match the domain name of the server
itself? The client application validates that the server application with which the client
application is communicating actually resides at the same network address as is specified
within the servers certificate. Although this validation could be done with IP addresses,
it is almost universally done using the FQDN of the server. If the FQDN of the server
does not match the FQDN contained in the servers certificate, the server is not
authenticated; otherwise, the server is authenticated.

At this point, the server is authenticated and the client application goes about finishing the SSL
handshake. If any of these client checks fail, you would think that the SSL connection cannot
continue; however, you may have noticed that most Web clients tend to carry out all four steps
and give the user a little dialog box of those things that failed, as Figure 10.10 shows. At this
point, you can choose to override the decision-making process of your browser and choose to
accept the credentials of the server you are establishing communications with.

307

Chapter 10

Figure 10.10: Server certificate validation failure dialog box.

Unfortunately, there are some major sites out there that cause this type of dialog box to show up.
From a pure security standpoint, handing this decision to a user is probably not the best thing to
do. The fact that you are reading this book indicates that you are interested in information about
security, and you can probably make reasonable sense of the dialog box you are being presented,
but think about the grandmother test. If your grandmother cannot figure out the right thing to do
intuitively, is the dialog box doing its job? I would propose that most users would just blindly
accept the identity of the server without really being able to understand that the site just might be
an imposter site on the Web! Obviously, Figure 10.10 does not look quite so nefarious, but do
you really want to do business with someone who cannot even take care of security basics such
as keeping valid certificates on their Web site?
Client Authentication Process
Although a client application always authenticates the server in an SSL communication, the
reverse is not necessarily true. The authentication of the client by the server application is an
optional feature of SSL that not everyone knows about. When a server application is configured
to utilize client authentication, the client application is responsible for supplying two pieces of
information to the server: the clients certificate and a digitally signed piece of data. The server
can utilize the digitally signed data to validate the public key in the certificate and to authenticate
the clients identity.
The key is in the digital signature. The client application creates a digital signature by hashing
data that is randomly generated during the handshake and that is known only to the client and the
server. The client finishes off the digital signature by encrypting the hash of the random data
with its private key. As we can see in Figure 10.11, an SSL-enabled server application needs to
answer four simple questions to authenticate the client.

308

Chapter 10

Figure 10.11: The SSL client authentication process.

The server must answer each of these four questions in the affirmative to authenticate the
identity of the client with which the server application is trying to establish an SSL
communications channel:

Does the client's public key validate the digital signature? The server application ensures
that the digital signature supplied by the client can be validated with the public key
contained within the certificate. If the digital signature is authentic, the server knows that
the client is in possession of the private key that is associated with the public key
contained within the presented certificate; however, the server cannot trust the binding
between the public key and the DN specified in the certificate without completing the
following steps.

Is the certificate within its validity period? The server application validates that the
current date and time are within the range of the client certificates validity period. If the
current date and time are outside the range of the certificates validity period, the client is
not authenticated; otherwise, the server proceeds to the next step.

309

Chapter 10

Is the issuing CA trusted? An SSL-enabled application must maintain or have access to a

list of trusted CA certificates. The server application pulls the DN of the CA that issued
the clients certificate from within the clients certificate. It then utilizes the DN to search
for a match of a CA from within the list of trusted CAs. If the issuing CA is not found
within the list of trusted CAs, the client is not authenticated; otherwise, the server
proceeds to the next step. If the issuing CA is not found on the list of trusted CAs, all is
not necessarily lost. If the server can validate that the issuing CA is contained within a
CA hierarchy that ends in a CA that is trusted, the client is authenticated and the server
proceeds to the next step.

Does the issuing CA's public key validate the issuer's digital signature? The server
application utilizes the public key from the issuing CAs certificate to validate that the
digital signature of the clients certificate is authentic. If for some reason the client
certificate has been altered since it was signed by the issuing CA, or if the public key you
have in your trusted CA list does not correspond to the private key that signed the clients
certificate, the client is not authenticated; otherwise, the client is authenticated.

At this point, the client is authenticated, and the server application goes about finishing the SSL
handshake. If any of these server checks fail, the SSL connection cannot continue, and the server
will close the TCP/IP communications channel.
Enabling SSL
Now that we know how SSL functions, the next logical discussion is about how you go about
enabling SSL on your IIS Web servers. The first step is to request a certificate for your Web site.
This request is done via the Internet Services Manager MMC snap-in by right-clicking the Web
server instance on which you want to enable SSL, selecting Properties, then selecting the
Directory Security tab. Doing such will pull up the main security settings for the Web site, as
Figure 10.12 shows, from which you can click Server Certificate to invoke the Web Server
Certificate Wizard. This wizard is similar to the other certificate wizards that we covered in the
chapters on PKI; therefore, you should be able to move quickly through the wizard to request the
certificate.

310

Chapter 10

Figure 10.12: The Directory Security tab of the default Web site properties dialog box.

For IIS servers in your internal network, the utilization of an Enterprise CA makes the request,
issuance, and installation steps seamless and extremely simple to manage. For IIS servers that you
have deployed in DMZ environments to service customers on the Internet, you will probably want to
save the request to a file and submit it to Verisign (or some other well-known CA service).

SSL Configuration
Once you have acquired a certificate for your IIS server, you will want to configure the SSL
setting that the server is going to utilize. From the same Directory Security tab that you used to
request a certificate, you can click Edit within the Secure communications portion of the tab to
pull up the Secure Communications dialog box, which Figure 10.13 shows. This dialog box will
allow you to configure the SSL communications for visitors to your Web site that have a browser
that supports SSL and URLs starting with https:// (which is just about all browsers these days).

311

Chapter 10
The first thing to realize is that just because you have installed a certificate in your Web server,
SLL is not automatically enabled. You will need to make sure that the Require secure channel
(SSL) check box is selected to actually turn on the SSL protocol. When you require SSL, you
will automatically cause your Web server to start listening on port 443 and only process HTTPS
connections. The other option that you have is to require 128-bit encryption. 128-bit browsers
used to be uncommon, but nowadays they seem to be the de facto standard. In any event, I highly
recommend that you require 128-bit encryption for any of the Web servers that you have
connected to the Internet, especially those that involve e-commerce activities. For those of you
outside of the United States, you might not yet have that option. But if you have the option,
always move up to 128-bits to better protect the Internet communications between your
organization and your customers.

Figure 10.13: The SSL Secure Communications dialog box.

312

Chapter 10
The other major configuration available to you from the Secure Communications dialog box
centers on how SSL will deal with the client certificates that it may need to process. As you can
see from the dialog box, the first thing you can do is decide whether you want to deal with client
certificates. If you select the Ignore client certificates option, none of the other settings will
really matter because you will not process client-submitted certificates. If you elect to Accept
client certificates, you will process them if they are submitted. Whether a Web browser will offer
a client certificate without being asked is really a function of the browser. If you want to process
client certificates, choose to Require client certificates. This option will ensure that all clients
offer up a certificate, and if they do not have a certificate, they will not be able to establish an
SSL connection with your server.
The next option available to you in relation to how your SSL-enabled Web server processes
client certificates is the Enable client certificate mapping. This option allows client certificates to
be mapped to Windows user accounts, allowing you to specify access control to resources using
client certificates. This option is so complicated that we will talk about it in detail in the next
section. However, I will say now that if you are going to use this option, I highly recommend
that you make sure that you require client certificates for the Web site. If you do not require
client certificates, some of your Web users may have valid certificates but their Web browser
may not automatically offer your certificate for authentication without explicitly being asked to
do so.
The final option concerns your ability to utilize a Certificate Trust List (CTL) to control who can
connect to your SSL-enabled Web server with a client certificate. By default, the Web server will
search the complete list of Trusted Root Certification Authorities that is stored within the
certificate store of the local computer account. This list is that huge list of all the commercial
CAs that have convinced Microsoft that their root CAs should be baked into Win2K. However,
do you really want to trust ALL of those CAs? I would not. As a result, you can utilize a CTL to
limit which root CAs that your Web server will trust when processing client certificates. I
suggest that you use this option if you are going to require client certificates for the Web site so
that you have a little more control over who can access your site.
Client Certificate Mappings
As we talked about earlier, you can configure your Web server to authenticate users who log on
with a valid client certificate. This configuration allows you to map information contained in a
clients certificate against Windows user account information. Sounds pretty simple, and it is to
an extent. When you select the Enable client certificate mapping option, you have the ability to
perform two types of mappings: one-to-one and many-to-one. Both of these options are available
by clicking Edit next to the selected Enable client certificate mapping check box.
The easier of the two types of mapping to configure and understand is the one-to-one mapping.
One-to-one account mappings of certificates require that you to have access to an ASCII copy of
the users client certificate. The mapping is created by selecting the option to add a new mapping
and selecting the users client certificate. Once you have done so, you will be asked to provide
information regarding the Win2K account that the certificate should be mapped to, as Figure
10.14 illustrates. As you can see, you unfortunately have to enter in the password for the users
account for the mapping to be utilized.

313

Chapter 10

Figure 10.14: A one-to-one account mapping of a certificate.

You can map multiple certificates to a single account, but you must define a one-to-one mapping
for each client certificate. If there is any correlation between each of these users client
certificates, it may be easier to use a one-to-many mapping.
Although not as straightforward as a one-to-one mapping, the many-to-one account mapping
functionality is still not that difficult to set up and administer. It does, however, require you to
know a little about how to use commonalities in issued client certificates to your advantage. For
example, you might want to take advantage of the OU field contained within the certificates that
you utilize in your organization to aggregate all of your Human Resources staff down to a single
account to perform some basic Web function. You really do not care who does it, just as long as
they are part of the Human Resources department. This situation is easily handled with a manyto-one account mapping of the Human Resource users client certificates, as Figure 10.15 shows.
As you can see, we have stated that if the subject of the client certificate has a DN that contains
OU=Human Resources, we will map them to a specific Win2K account. Like a one-to-one
mapping, when you create a many-to-one account mapping, you must again enter the password
for the users account for the mapping to be utilized.

314

Chapter 10

Figure 10.15: A certificate to account mapping rule construction.

The Edit Rule Element dialog box is part of a quazi-wizard that you work though when you
decide to create a many-to-one account mapping. As you know, users client certificates can
contain several forms of identification information (for example, company name and locality).
You can have IIS utilize these pieces of certificate identification information to make decisions
about mapping client certificates to Win2K user accounts. Its really pretty straightforward, but
lets cover the basic options just to make sure things are well understood:

Match CapitalizationThis check box controls whether the rule you are creating is case
sensitive or not. This requirement really applies to the contents of the criteria section of
the dialog box.

Certificate FieldThis drop-down box allows you to choose whether you want to
compare against the client (the Subject) or the Issuer of the client certificate.

Sub FieldThis drop-down box allows you to select which certificate sub field that you
want to use as the basis for selecting certificates to map. The most common are: O)
Organizationtop-level organization or company name, (OU) Organizational Unita
department within a company (for example, Human Resources), (CN) Common Name
name of the client (for example, George W. Bush), (C) Countrytwo-letter country
designation (for example, US, FR, AU, UK), (S) State/Provincethe full name of the
state or province (for example, California, Alberta), and (L) Localitythe full name of
the city (for example, San Francisco, Toronto).
315

Chapter 10
In addition to the common subfields found in a certificate, the rule editor supports several
non-standard subfield categories, including (C) Countrytwo-letter country designation
(for example, US, FR, AU, UK), (I) Initialsinitials of the certificate owner, (GN) Given
Namegiven name of the certificate owner, (T) Titletitle of the certificate owner,
(Email) Emailemail address of the certificate owner.

CriteriaThis text box allows you to specify the criteria for matching field and sub field
information. As we saw in Figure 10.15, we used the sub field OU and the criteria
Human Resources to tell the matching rule which organizational unit to match to. In
addition to full, specific matches, you can use the wildcard character (*) to partially
specify the text of your mapping criteria.

Although we have talked about how you can utilize certificate mappings in IIS, the truth of the
matter is that you probably will not get a chance to use this feature all that often, if at all.
Unfortunately, the instances of users having client certificates is just not that high out on the
Internet. The only real penetration of client certificates on the Web is a result of credit cards such
as American Express Blue Card. As a result, the old stand-by username/password combination
remains the predominate way that users are authenticated over the Internet, and the utilization of
client certificates remains an afterthought. Now you may figure that if certificate mappings are
not all that useful on the Internet, what about within my organization on our intranet?
Unfortunately, it is really not all that useful there either. If you have a homogenous Win2K
environment, the IIS server can utilize Kerberos to ascertain the identity of the user
automatically, without the need for client-side certificates. Dont despair though, the capability is
very handy, you will just need to find the right opportunity within your organization to use it.
SSL Summary
We have spent a great deal of time on SSL. It has become one of the most important security
protocols used on the Internet. In addition to Web servers such as IIS using the protocol to
provide for authenticated, secure communications over the Internet, many other application-level
protocols, such as LDAP and IMAP, are taking advantage of the protocol to better protect
information as it traverses the largely unsecured Internet. Now that our discussion is over, I hope
you have a better understanding of both the protocol, and how to utilize it within IIS.

Best Practices
A lot goes into configuring a Win2K-based system and running IIS in a DMZ environment, but
the configuration process is really not that difficult. It takes patience, a methodical approach, and
an understanding of what is required. I cannot help you with your patience or approach, but this
section is all about helping you understand what is required to secure your Internet-facing
deployments of Win2K and IIS.
What follows are the steps you need to carry out to create the most secure IIS installation that I
know how to create. However, if you take every action specified, some of your applications or
enterprise-wide tools might not work. Some understanding of your environment and applications
is required to make sure that you skip the configuration steps that might cause you problems in
your environment. As a result, after you complete the following software-installation steps and
can verify that your applications work, you should re-verify that everything is functional at the
conclusion of each of the configuration steps.

316

Chapter 10
Software Installation
The installation of Win2K Server, IIS, and your Web applications provide the basis for a secure
installation. The requirements for software installation have been chosen to minimize the
probability that an intruder will be successful in penetrating the deployed system. Secure
installation is accomplished by installing only the software required for proper operation of the
system, installing the software into non-default locations, and properly sequencing the
installation to ensure that all system files are updated properly.
The first step in configuring the system is to plan and understand the layout of the system disk to
support the hardened configuration. This plan entails utilizing multiple NTFS volumes, each with
a specific function and each being only large enough to comfortably hold the required software.
The boot partition should contain only the OS and no application software or data. In stall a
second partition that contains only the application. A third, and final, partition should be utilized
for the paging file. The isolation of these functions on separate volumes ensures that an attacker
cannot cause the OS to crash by filling up a single system disk. An advisable measure, although
not required for security purposes, is to create all volumes on disks that are mirrored to ensure
system availability if a disk failure occurs. Table 10.2 lists a typical configuration for a DMZ
system.
Drive

Format

Purpose

NTFS

OS files

NTFS

Application and
temporary storage

NTFS

Paging file

Table 10.2: Disk configuration guidelines.

Volume sizes should be tailored to the specific requirements of each application installation that
you need to deploy. After planning the disk layout of the installation, the next step is to install
the required software, properly sequenced to ensure proper configuration of the system. The
installation of software should follow these high-level procedures:
1. Install Win2K Server. Ensure you are using valid, original media. As described earlier,

utilize only NTFS volumes; FAT volumes must never be utilized. In addition, do not
install any of the following optional components unless specific circumstances dictate:

Accessories and utilities

Certificate services

Indexing Service

Management and monitoring tools

Message queuing services (unless needed by an application)

Other network file and print services

Remote Installation Services (RIS)

Remote storage (unless operational procedures require)

Script Debugger

317

Chapter 10

Terminal Services (unless using administration mode Terminal Services)

Terminal Services Licensing Service

Windows Media services

2. Installation of IIS should consist of only the core subcomponents required to operate the

Web service:

Common Files

IIS MMC snap-in

World Wide Web Server

The following IIS subcomponents should not be utilized:

Documentation

File Transfer Protocol (FTP) Server

FrontPage 2000 Server Extensions

Internet Services Manager (HTML)

NNTP Service

SMTP Service

Visual InterDev RAD Remote Deployment Support

3. Install only the TCP/IP network protocol, which is the only supported protocol for a

DMZ system.
4. Do not use DHCP, and statically assign an IP address to your network interface.
5. Configure the system as part of a workgroup, not as a member in a domain.
6. Create an Emergency Repair Disk (ERD) and store it in a safe location.
7. Create additional disk partitions: Create a 512MB partition (E:\) for applications (or

whatever size you previously determined), and create a 512MB partition (F:\) for the
Windows swap file (or whatever size you determined earlier).
8. Move the swap file to the F:\ partition with a fixed size. To do so, set the minimum and

maximum to the same value.

9. Install IE 5.5 SP2 with minimal components if possible.
10. Install Win2K SP2. Ensure that you are using valid, original media, and do not create an

uninstall directory because it will leave vulnerable executables on disk.

11. The installation of SP2 will upgrade the computer to domestic-grade, 128-bit encryption.
12. Install post-SP2 hotfixes. (Install all relevant hotfixes available from Microsoft.)
13. Even the most securely configured system might still be vulnerable if hotfixes are not

kept up to date.
14. Install a server-based antivirus software product.
15. Install a server-based intrusion detection software product if your organization uses one.

318

Chapter 10
16. Install applications in a directory of your choosing on the E:\ drive (for example,

E:\webapp).
17. You should not install tools such as the Win2K resource kit and support tools on DMZ

systems unless absolutely necessary. If they are installed, they should be installed in an
alternative location. Preferably, they will be installed somewhere on the system disk, not
on the application disk (for example, C:\tools\reskit and C:\tools\support).
Remove Unnecessary Subsystems
Win2K was designed in a modular fashion and is capable of supporting multiple application
paradigms. Nearly every application utilizes the Win32 interface for interacting with the OS. In
addition to the Win32 interface, the standard Win2K installation installs interfaces for Posix- and
OS/2-style applications. These application environments should be removed so that attack tools
that rely on these interfaces are nullified. To remove these application environments, delete the
following:

Registry Key
Hive: HKEY_LOCAL_MACHINE\SYSTEM
Key: \CurrentControlSet\Control\Session Manager\SubSystems
Name1: Os2
Name2: Posix

Registry Key Values

Hive: HKEY_LOCAL_MACHINE\SYSTEM
Key: \CurrentControlSet\Control\Session Manager\SubSystems
Name: Optional
Values: Os2, Posix

Folder
%systemroot%\system32\os2

Files
%systemroot%\system32\os2*.*
%systemroot%\system32\posix.exe
%systemroot%\system32\psx*.*

319

Chapter 10

Configure the Logon Screen and Desktop

The default configuration of the Win2K logon screen does not provide a warning as to the
prospective users rights once they logon, gives out too much information, and contains too
much privilege. In addition, administrators sometimes leave the system console unattended while
their accounts are active, allowing potentially unauthorized access to the machine. Also, security
is gained by not utilizing the Recycle Bin. As a result, you should carry out the following
actions:

Hide the last username to log on.

Remove the Shutdown button from the logon screen.

Customize the logon screen caption and message.

Configure the screen saver for 15 minutes.

Set the Recycle Bin properties to delete files immediately. (The option to do so is found
on the Recycle Bin properties sheet.)

Configure the Account and Audit Policies

The default configuration supplied by Win2K does not adequately protect against password
guessing and door knocking penetration of accounts. Configuration of the logon settings in a
fashion that requires strong passwords that change on a regular basis will stop all but the luckiest
of password guessers. You can also rename the Administrator account and create a dummy
account that contains no privileges to afford additional protection against script kiddies.
Additionally, the default audit settings are not strong enough to hinder an intruder from
manipulating the audit logs to hide evidence of his or her actions. To provide sufficient security,
use the following guidelines to configure account and audit policies:

Set password policies to

Maximum Password Age: 42 days
Minimum Password Age: 2 days
Minimum Password Length: 12 characters
Password Uniqueness: 13
Lockout After Bad Logon Attempts: 5 attempts
Reset Counter: 99999 minutes (never)
Lockout Duration: Forever
User Must Logon To Change: Selected

Rename the guest account to another name.

Rename the Administrator account to another name.

Create a dummy Administrator account with no group memberships, and use the same
description as the real administrator account.

Delete the description for the real administrator account.

320

Chapter 10

Disable the locally created guest accounts.

Enforce that passwords must meet complexity requirements.

Set WinLogon to not cache any passwords.

Set password expiration warning to 14 days.

Require the use of Ctrl+Alt+Del to logon to system.

Ensure that the group Power Users is empty and contains no members.

Set Audit Policies as follows:

Audit account logon events: Success & Failure
Audit account management: Success &Failure
Audit directory services access: *
Audit logon events: Success & Failure
Audit object access: Success & Failure
Audit policy change: Success & Failure
Audit privilege use: Failure
Audit process tracking: *
Audit system events: Success & Failure

Set each of the audit logs as follows:

Maximum Log Size: 20480KB
Event Log Wrapping: Overwrite Events Older than 42 days

Restrict anonymous access to the audit logs (this is three registry settings).

Disable the crash on audit fail option.

Configure User Rights

A DMZ-deployed Win2K system should be tightly managed by a small set of administrators and
should not contain spurious user and operator accounts. As such, the user rights should be
significantly restricted to allow access only to privileged operations by the administrators group.
You should set the User Rights as follows (note that both the IUSR and IWAM accounts may not
exist on all installations and are for proper operation of IIS):

Access this computer from network: Administrators

Act as part of the OS: *

Add workstations to domain: *

Backup files and directories: Administrators

Bypass traverse checking: *

Change the system time: Administrators

321

Chapter 10

Create a pagefile: Administrators

Create a token object: *

Create a permanent shared object: *

Debug programs: *

Deny access to this computer from the network: *

Deny logon as a batch job: *

Deny logon as a service: *

Deny logon locally: *

Enable computer and user accounts to be trusted for delegation: *

Force shutdown from a remote system: Administrators

Generate security audits: *

Increase quotas: Administrators

Increase scheduling priority: Administrators

Load and unload device drivers: Administrators

Lock pages in memory: *

Log on as batch job: *

Log on as service: *

Log on locally: Administrators

IUSR_<machine name>
IWAM_<machine name>

Manage auditing and security logs: Administrators

Modify firmware environment variables: *

Profile single process: *

Profile system performance: Administrators

Remove computer from docking station: *

Replace a process level token: *

Restore files and directories: Administrators

Shut down system: Administrators

Synchronize directory service data: *

Take ownership of files or other objects: Administrators

322

Chapter 10
Configure System Services
With the increased risk of an NT system exposed to the Internet, minimizing the services that are
in use and available for an intruder to attack is an important task. The actual services required for
proper operation of a DMZ-based system are limited, and removing services that are not required
can dramatically decrease the probability that the system can be compromised. As a result, you
should disable all unnecessary system services. Services marked below with an asterisk (*) are
the additional services that will be required if youre running a domain within the DMZ. Disable
the following services and never use them:

Application Management

ClipBook

DHCP Server

Dfs

Distributed Link Tracking Client

Distributed Link Tracking Server

Fax Service

Indexing Service

Internet Authentication Service

Internet Connection Sharing (ICS)

Intersite Messaging

License Logging Service

NetMeeting Remote Desktop Sharing

Network DDE

Network DDE DSDM

QoS RSVP

Print Spooler

Remote Access Auto Connection Manager

Remote Access Connection Manager

Routing and Remote Access Service (RRAS)

Simple TCP/IP Services

Site Server ILS Service

Telnet

Utility Manager

Windows Installer

Windows Internet Naming Service (WINS)

323

Chapter 10
The following services may be used if required:

Alerter

COM+ Event Viewer

Computer Browser

DHCP Client

Distributed Transaction Coordinator (DTC)

DNS Server

File Replication *

Kerberos Key Distribution Center *

Logical Disk Manager Administrative Service

Messenger

Net Logon *

NTLM Security Support Provider *

Performance Logs and Alerts

Removable Storage

Remote Procedure Call (RPC) Locator *

Server * (when sharing resources or for AD)

Smart Card

Smart Card Helper

System Event Notification

Task Scheduler

TCP/IP NetBIOS Helper Service

Telephony

Terminal Services

Uninterruptible Power Supply (UPS)

Windows Management Instrumentation (WMI)

Windows Management Instrumentation Driver Extensions

Workstation * (when connecting to resources)

Windows Time *

324

Chapter 10
The following services should NOT be disabled:

DNS Client

Event Logs

IIS Admin Service (disable if not using)

IPSEC Policy Agent

Logical Disk Manager

Network Connections

Plug and Play (PnP)

Protected Storage

RPC

Remote Registry Service

RunAs Service

Security Accounts Manager (SAM)

World Wide Web Publishing Service

Configuring the Network

The default configuration of Win2K allows for quick and easy access to an intranet environment,
but lacks sufficient security controls to be placed in a DMZ environment. Tightening the network
configurations ensure that only the functionality required by IIS is available and that all other
services, bindings, and protocols are eliminated; thus, eliminating several potential Win2K
vulnerabilities. As a result, you should take the following actions:

Uninstall the File and Printer Sharing for Microsoft Networks and the Client for
Microsoft Networks components.

Disable the NetBIOS network bindings in TCP/IP for all network interfaces.

Disable the use of the LMHOSTS file for all network interfaces.

Clear the option to register the IP connections address in DNS because we are utilizing
static IP addresses.

Disable the server and workstation bindings from the Internet-facing network interface if
there is more than one interface on the computer.

Configure TCP/IP filtering rules on the Internet-facing network interface to

TCP: 80, 443 (only configure as utilized)
UDP: * (do not accept UDP on Internet connections)
Protocols: 6

325

Chapter 10

The TCP/IP filter setting in Win2K applies to ALL network adapters. This may be OK dependent upon
the server installation, the number of network interfaces, and the way the server is administered. In
cases in which this setting is not sufficient, IPSec filters will have to be utilized.

Configure the HKEY_LOCAL_MACHINE\SYSTEM registry values (all values are of

type REG_DWORD) as Table 10.3 shows to fortify the network stack against a DOS
attack.

Key

Name

Value

\CurrentControlSet\Control\Services\Tcpip\Paramaters

EnableICMPRedirect

EnableSecurityFilters

SynAttackProtect

EnableDeadGWDetect

EnablePMUDiscovery

KeepALiveTime

300000

DisableIPSourceRouting

TcpMaxConnectResponseRetransmissions

TcpMaxDataRetransmissions

\CurrentControlSet\Control\Services\NetBT\Paramaters

ReleaseOnDemand

\CurrentControlSet\Control\Services\AFD\Paramaters

DynamicBacklogGrowthDelta

10

EnableDynamixBacklog

MinimumDynamicBacklog

20

MaximumDynamicBacklog

20000

Table 10.3: HKEY_LOCAL_SYSTEM secure registry value settings.

Move System Binaries

Many scripted attacks try to invoke sensitive binaries to gain more information about the
operational environment of the system being probed. As a result, you should move sensitive
binaries to a non-path directory as follows
1. Create a directory for the tools that is not part of the path (for example, C:\tools).
2. Move the following executables to the newly created directory:

arp.exe

at.exe

atrib.exe

atsvc.exe

cacls.exe

clipsrv.exe

cmd.exe

command.com
326

Chapter 10

cscript.exe

debug.exe

dialer.exe

edit.com

edlin.exe

finger.exe

ftp.exe

hypertrm.exe

ipconfig.exe

nbtstat.exe

net.exe

netstat.exe

nslookup.exe

ping.exe

qbasic.exe

rcp.exe

rdisk.exe

regedit.exe

regedt32.exe

rexec.exe

route.exe

rsh.exe

runonce.exe

secfixup.exe

sysedit.exe

syskey.exe

telnet.exe

tftp.exe

tracert.exe

wscript.exe

xcopy.exe

327

Chapter 10
Miscellaneous Configurations
The default configurations of some registry values are not sufficiently restrictive within a DMZ
environment. As a result, you should add or modify the following registry values using
regedt32.exe:

To wipe the page file clean at system shutdown:

Hive: HKEY_LOCAL_MACHINE\SYSTEM
Key 1: \CurrentControlSet\Control\Session Manager\Memory Manager
Name: ClearPageFileAtShutdown
Type: REG_DWORD
Value: 1

This value will increase the shutdown time for the systems, especially if the page file is large.
However, it provides more security benefit than the additional few seconds it takes to power down a
system.

To strengthen the default permissions of global system objects:

Hive: HKEY_LOCAL_MACHINE\SYSTEM
Key 1: \CurrentControlSet\Control\Session Manager
Name: ProtectionMode
Type: REG_DWORD
Value: 1

To turn off NTFS 8.3 name generation:

Hive: HKEY_LOCAL_MACHINE\SYSTEM
Key: \CurrentControlSet\Control\Filesystem
Name: NtfsDisable8dot3NameCreation
Type: REG_DWORD
Value: 1

To secure print driver installation:

Hive: HKEY_LOCAL_MACHINE\SYSTEM
Key: \CurrentControlSet\Control\Print\Providers\LanMan Print Services\Servers
Name: AddPrintDrivers
Type: REG_DWORD
Value: 1

To disable Web-based printing:

Hive: HKEY_LOCAL_MACHINE\SYSTEM
Key: \CurrentControlSet\Software\Policies\Microsoft\Windows NT\Printers
328

Chapter 10
Name: DisableWebPrinting
Type: REG_SZ
Value: 1

To secure recovery console access:

Hive: HKEY_LOCAL_MACHINE\SOFTWARE
Key: \Microsoft\Windows NT\CurrentVersion\Setup\RecoveryConsole
Name 1: SecurityLevel
Name 2: SetCommand
Type: REG_DWORD
Value: 0

To secure the driver software signing policy:

Hive: HKEY_LOCAL_MACHINE\SOFTWARE
Key: \Microsoft\Driver Signing
Name: Policy
Type: REG_BINARY
Value: 1

To secure the non-driver software signing policy:

Hive: HKEY_LOCAL_MACHINE\SOFTWARE
Key: \Microsoft\Non-Driver Signing
Name: Policy
Type: REG_BINARY
Value: 1

329

Chapter 10

Secure IIS
Even with a minimal installation, IIS installs with many samples and applications that have been
found to contain vulnerabilities that might be utilized by an intruder to gain access to the system.
As a result, you should eliminate all applications installed by default and reconfigure IIS to
utilize the installed Web application with the following actions:

Utilize the Internet Service Manager to delete the entire default Web site.

Delete the entire C:\inetpub tree.

Utilize Internet Service Manager to create a new Web site targeted at the deployed Web
application, making sure that none of the original virtual sites are available: Choose a
name for the new Web site. Bind the Web server to the specific IP address connected to
the Internet. Target the Web site to the Web application directory (for example,
E:\webapp). Do not select Writes or Browse, select the others as they apply to the
specifics of the application. Do not utilize the default Web pages of default.asp,
default.htm, index.asp, and index.htm within the new Web site. Choose a default page
such as main.asp or main.htm.

Remove the C: inetpub directory.

Utilize the Internet Services Manager to configure the new Web site as follows: Remove
unneeded script mappings from sites by navigating to Properties, Home Directory,
Configuration, App Mappings. Most installations should only need ASP. If you think you
need any other mappings, please double check that they are truly needed by the
applications. Under no circumstances should you utilize the following application
mappings because these mappings have a history of containing security vulnerabilities,
and I would not trust them: .ida, .idc, .idq, .htr, .htw, .htx, .printer. For those script
mappings that remain, enable the Check that file exists option as found by editing the
remaining application extension mappings.

Disable sending of detailed error messages for your new default Web site by navigating
to Properties, Home Directory, Configuration, App Debugging.

Change W3C log to audit the following:

Date

Time

Client IP

Username

Server IP

Server Port

Method

URI Stem

URI Query

Protocol Status
330

Chapter 10

Win32 Status

Protocol Version

User Agent

Cookie

Change log settings to create a new log every day.

Disable Parent Paths by clearing the following check box from your new default Web
site: Properties, Home Directory, Configuration, App Options, Enable Parent Paths.

Update the root CA certificates utilized by the IIS Server. All unnecessary Root
Certificates should be removed utilizing the Certificates MMC snap-in directed at the
local computer. This should include all root certificates except those belonging to
Microsoft, VeriSign, and any commercial CA that your organization utilizes.

Configure the file system access-control lists (ACLs) for all files served up by IIS. Readonly content such as .gif, .jpg, .htm, and .html files should be set as follows:
Authenticated Users, Read. Execute capable content such as .exe, .dll, .inc, and .asp files
should be set as follows: Authenticated Users, Execute.

Alternative Best Practices

Now that you have seen all that goes into securing a Win2K system running IIS, you might be
wondering whether there is a better way. Microsoft released a security tool that makes securing
an IIS Web server simplethe IIS Lockdown Tool. This tool lets you quickly and easily
configure Web servers with a much more secure configuration than what comes out of the box.
Although this tool might not do absolutely everything we have covered, you can use it to
instantly protect your systems against security threats that target Web servers.
The IIS Lockdown Tool provides two operating modes: Express Lockdown and Advanced
Lockdown. The default mode of operation is known as Express Lockdown. With a single mouse
click, this mode configures the server in a highly secure fashion that is appropriate for most
basic, HTML-based Web servers. For those who need to pick and choose the technologies that
will be enabled on the server, the tool offers an Advanced Lockdown mode of operation. The
tool provides information and recommendations for selecting the best configuration, and an undo
facility allows the most recent lockdown to be reversed.
How good is the tool? Like the configuration I discussed earlier, the tool protects your IIS
servers against most known security vulnerabilities afflicting IIS without the patches installed.
Obviously, you should keep your servers up to date from a hotfix perspective, but you never
know when a new vulnerability might show up.
The IIS Lockdown Tool is available for download at
http://www.microsoft.com/Downloads/Release.asp?ReleaseID=32362.
HTU

UTH

A good configuration guide for hardening Win2K can be found at http://www.sysexp.com/win2k/HardenWin2K.html.

HTU

UHT

HTU

As always, make sure you check out what Microsoft is recommending for IIS configurations at
http://www.microsoft.com/security.
UTH

331

Chapter 10

Summary
In this chapter, we talked at length about the security mechanisms that are available to you
within IIS and how to configure them. We covered the authentication, access-control, and
auditing mechanisms that you can utilize. We also discussed SSL in depth, and looked at how
you can utilize digital certificates to not only protect your Web server network traffic but also to
authenticate users to your Web sites. We ended with the steps you should take to make sure that
your IIS installations are secure. Using all of this knowledge, you should be able to ensure the
security of your IIS Web servers and keep the hackers at bay.

332