windows 2000 security
DESCRIPTION
The book you are about to read represents an entirely new modality of book publishing and amajor first in the publishing industry.TRANSCRIPT
The Definitive Guide Totm
The Definitive Guide Totm
Windows 2000Security
Paul Cooke
Introduction
i
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 today’s most critical IT topics—at 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 book’s 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 won’t 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 “real-time”—that is, as chapters are written or revised by the author—you benefit from receiving the information immediately rather than having to wait months or years to receive a complete product.
Finally, I’d like to note that although it is true that the sponsor’s 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 library—not 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 d’être to locate and work only with the industry’s 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 [email protected], 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
ii
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
Table of Contents
iii
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
Table of Contents
iv
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
Table of Contents
v
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
vi
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 Keys—the 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
Table of Contents
vii
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
Table of Contents
viii
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
Table of Contents
ix
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
Table of Contents
x
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
xi
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 Role—Overall 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 Infrastructure—Part 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
Table of Contents
xii
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
Table of Contents
xiii
Hardware Protection of Private Keys ..........................................................................................260
Summary ......................................................................................................................................261
Chapter 9: Public Key Infrastructure—Part 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
Table of Contents
xiv
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
Table of Contents
xv
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
Copyright Statement
xvi
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, non-commercial 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 [email protected].
Chapter 1
1
Chapter 1: Overview of Windows 2000 and Security
It wasn’t 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 security—more specifically, about Windows 2000 (Win2K) security. In this book, I’ll concentrate on the security issues that surround Win2K and discuss generic security fundamentals and concepts. When I’m finished, I hope that you’ll have gained a thorough understanding of Win2K, its security features, and how to deploy Win2K securely throughout your enterprise. I also hope that you’ll 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 didn’t 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 book—helping you become successful. My goal, then, is that when you’ve finished reading this book, you’ll 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 you’ll 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 I’ll 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 don’t cover.
Chapter 1
2
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 Professional—for the desktop
• Windows 2000 Server—for the workgroup and department servers
• Windows 2000 Advanced Server—for application and more robust department servers
• Windows 2000 Datacenter Server—for 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 it’s 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. It’s 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, it’s 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, I’ll cover the fundamentals of NT/Win2K security that are relatively unchanged from previous versions of the OS. Then I’ll focus on the new security features that have been added to the OS and how they enable policy-based administration and information security. Let’s take a quick tour of the new security features implemented in Win2K.
Chapter 1
3
What Is New in Windows 2000? Perhaps it’s just my own personal slant on things, but from where I sit, many of Win2K’s 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.0’s infrastructure. I’ll examine the similarities and differences in later chapters of this book. For now, let’s 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 shouldn’t 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, it’s 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 I’ve 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.
• AD’s 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
4
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. I’ll 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.
Figu
Storingrepreseare ava
.
re 1.1: A sample AD domain hierarchy.
the security account information in AD means that users, computers, and groups are nted as objects in the directory. As a result, standard capabilities that are integral to AD ilable to security account information. In particular, AD supports:
• Delegation of administration—Can 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
5
Chapter 1
6
• Fine-grained access rights—Make it possible to grant access rights for specific operations. For example, an organization can grant administrative capabilities such resetting user passwords or disabling accounts to specific groups without also grantinpermiss
as g
ion to create new accounts or change other properties of user accounts.
• Inheritance of access rights—Makes it possible to grant access to a higher-level nd have the rights flow down to the sub-containers and leaf
ally
o ,
in2K to enable an administrator to reset user
NT
d cess privileges, which directly affects how you use the system. Because
never
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.
container of the directory aobjects. For example, administrative capabilities can be modified on entire portions of the directory tree by making changes to a specific container; these changes can automaticaffect all sub-containers and leaf objects.
These three AD capabilities will allow you to grant administrators the requisite privileges to dtheir job without granting them more privileges than they actually need. In NT 4.0 environmentsan 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 AD’s delegation of administration and fine-grained access rights, you can configure Wpasswords for these 25 users without allocating any other administrative privileges; therefore, you can assign and manage administrative privileges without the all-or-nothing paradigm of4.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 AD’s integrated security services, I want to first talk about the security of AD itself. AD stores domain security policy information, such as domain-wide passworrestrictions and system acsecurity-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 isrevealed to a user who isn’t allowed to see it.
An ACL is a
Chapter 1
Figure 1.2: The integration of Win2K’s 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 aren’t 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. Microsoft’s 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.
7
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 user’s 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 user’s 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 individual’s 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 I’ll touch on below; the rest I’ll 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
9
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 200can take advantage of the integrated PKI to provide digital sign
0 atures for and encryption of mail.
e
an protect sensitive corporate information sent on your
internal and external networks. Thus, it can be used as a standard mechanism to secure network iness partners, remote offices, remote employees, and any other group that
, ming profile, so users always have access
to t r al certific two meleave v workstations that can be readily accessed during off-hours or in sem
GroupWhile vantage 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 Configuration—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.
• User Configuration—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 the computer.
For example, digital signatures can prove origin and authenticity of an e-mail message, whilbulk 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 doesn’t 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 prearrangedshared secrets. This arrangement c
sessions with busrequires 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 user’s roa
hei credentials. Hardware tokens, such as smart cards, support roaming using the physicate store on the token device, so credentials are physically carried to new locations. Of thethods, hardware tokens are far superior from a security perspective; roaming profiles can ulnerable private-key material on
iprivate locations.
Policy not exclusively a security capability, Group Policy extends and takes ad
Chapter 1
10
Specific security-related policy settings are broadly delineated in Win2K as follows:
• Account policies—Password policies, account lockout policies, and Kerberos policies
• Local policies—Audit policy, user rights assignment, and security options
• Event log settings—Application, system, and security event log settings
• Restricted group—Membership in security-sensitive groups
• System services—Startup and permission for system services
• Registry—Permissions for Registry keys
• File system—Permissions 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 security-related 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 groups—Win2K 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 groups—Win2K 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.
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
12
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-key–based cryptographic scheme. Fully integrated into the OS, EFS works transparently from the user’s 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 user’s 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 organization’s laptops, it’s 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 enterprise’s 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), it’s 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.
Chapter 1
13
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 don’t 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 card–aware 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 doesn’t 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, token-based 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 protocols–—for 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.
Chapter 1
Security Primer While a number of you have some background in the security profession, I’m willing to wager that more of you don’t. 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 information-security 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 tiers—organizational factors, security objectives, and security mechanisms—as shown in Figure 1.5.
Organizational Factors
Security Objectives
Security Mechanisms
Risk Analysis Policy Culture
Integrity AvailabilityConfidentiality Accountability
AuthenticationIdentification
PKI
Authorization Encryption
MonitoringAuditVirus Protection
Figure 1.5: A three-tiered security framework.
14
Chapter 1
15
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 organization’s 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 organization’s 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 don’t meet established security baselines
• Aids communication and facilitates decision-making.
An organization’s 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 organization’s 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.
Chapter 1
16
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 I’ve 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 started—with the same four security objectives. While your organization’s security policy may embody all of these objectives, I don’t believe that excluding them from formal policy diminishes their importance. To provide a common point of understanding, these objectives are defined briefly below.
• Confidentiality—Keeping information and resources from being disclosed to someone who hasn’t been explicitly granted access.
• Integrity—Ensuring that information and resources remain complete and unchanged from a previous state.
• Availability—Ensuring that information and resources can be used whenever they’re 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 won’t talk much more about it in the rest of this book. On the other hand, I’ll devote individual chapters to the other three objectives.
• Accountability—Assigning 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 aren’t listed are nevertheless important.
While you need to pay attention to all three tiers of your security framework, it’s typically at this bottom tier where you’ll 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.
Chapter 1
17
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, I’ll 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 organization’s attitude to providing security services should be based on a small number of tenets. These tenets provide an organization’s 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. I’ll 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 can’t 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 they’ll 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 don’t 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.
Chapter 1
18
Security Is Applied to Multiple Layers You need to apply security services in such a way that a single failure doesn’t jeopardize the enterprise’s 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 doesn’t 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; it’s 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 they’re 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 I’ll 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, market-sensitive 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 doesn’t affect what information needs to be protected. It affects end-user perception, attitude toward security, and potentially the methods you use to protect information.
Chapter 1
19
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 they’re not being used. I’ve 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 shouldn’t 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 they’ll 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 it’s 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 doesn’t have to be complicated, and it’s typically a user name or computer name. Regardless of this simplicity, however, identification is the building block for all other pieces of security implementation.
Chapter 1
20
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 principals—users, computers, or applications—are 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 it’s 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, you’re 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 isn’t a member of an appropriate ACL, it won’t 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 today’s 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 don’t 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 isn’t 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 they’ll 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
Chapter 1
21
• 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 I’ve 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, I’d 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, I’ll share my experiences in securing Win2K. More times than not, these discussions will include my opinion of how security should be configured. But while I’ll share my opinions and “checklists” with you, I hope to also convey my attitude toward security. When I’m finished, you’ll have your checklists. I also hope that you’ll 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 didn’t 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.
Chapter 2
22
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 couldn’t 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 it’s 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 isn’t just a SAM replacement, what is it? Well, AD is Microsoft’s 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 Netware–based networks. Make no mistake, AD was designed to compete directly against NDS, and it’s Microsoft’s first real attempt at an enterprise-wide, scalable directory service. Consequently, AD looks to be at the heart of Microsoft’s future enterprise-wide strategy. Not only is AD the centerpiece of Win2K, it’s 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, I’ll 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 can’t cover. As a result, I’ll 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 you’ll 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 I’ve given you this background, I’ll 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 doesn’t 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 it’s designed for reading rather than writing, offers a static view of the data,
Chapter 2
23
and provides simple updates without transactions. Today’s 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, it’s 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? I’ll 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 sign-on to all directory-aware systems and applications.
Why Active Directory? While I’m 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, let’s 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 you’re 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.0’s SAM and the Exchange Global Address List (GAL). Obviously, a single repository would simplify things greatly.
Chapter 2
24
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. It’s 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.
I’ll 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, I’ll describe its underpinnings. It’s 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 today’s computing infrastructure—object 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. It’s 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 object—files, folders, processes, threads, and so on. As a result, almost every facet of the OS was built in an object-oriented fashion.
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, it’s 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 Real-Time. 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
26
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 wasn’t that long ago that support for networking wasn’t 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 OS’s ability to support multiple OS flavors. While we’ve 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 today’s modern OS. It’s 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. It’s in the security subsystem that all of the security decisions are made. While the name might lead you to believe that it’s 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).
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. It’s responsible not only for naming, allocating, and deleting objects but also for maintaining their security. It supports acvalidation 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.
cess
or s by
cess Ls
ed to lity is implemented in the SRM, the Object Manager uses the
functionality to maintain the security of objects, as I discussed above.
Security Reference MonitThe Security Reference Monitor (SRM) is responsible for validating access rights. It does thiimplementing 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 object’s ACL and determines whether to grant or deny acto the object. For example, every time you attempt to open a file, the SRM evaluates the ACassociated with the object that represents the file to determine whether you should be allowopen the file. While this functiona
27
Chapter 2
28
Before moving on, it’s 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 orprocess from obtaining direct access to an object. W
hile this approach may not be intuitively
obvious, it greatly simplifies the validation of security in the OS because it consolidates all into a single, small subsystem.
s to the three event logs
e
e event logs is mediated through the Event Logging Service, how do events get
n
terpiece of the user-mode security subsystem
If you were wondering how I was ever going to get to AD when I started talking about system
com
SecThe 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
sers of a system, it’s impossible to control access to objects, user rights and
(WinLogon). This process registers the SAS key sequence with the OS and protects against
access-control decisions
Event Logger The Event Logging Service is a user-mode process that mediates all accesmaintained 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 somof 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 it’s 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 thwritten 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 ithe 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 cencomponents 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.
architecture, now you know. So I’ll finish up my discussion of the LSA, its functions, and ponents, then get down to a discussion of AD.
ure Logon Process
authentication of all uprivileges cannot be enforced, and accountability cannot be maintained.
We’re all familiar with the “three-finger salute” that initiates a user logon to a system. PressingCTRL+ALT+DEL initiates what is known as the Secure Attention Sequence (SAS). But howdoes 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
Chapter 2
29
Trojan horse programs, which masquerade as the real logon screen and trick users into entetheir user names and passwords. Because WinLogon is the first process to run and r
ring egister SAS,
users are assured that when they use SAS to initiate a logon event, they’re 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 you’d expect—the active desktop whenever a screen saver is running.
The one piece of the secure logon process that I haven’t 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, I’m not a fan of them. Many of the third-party GINAs that I’ve 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, I’ve seen some major deployment and support problems arise in situations where third-party GINAs were involved.
LSA Subcomponents Now that I’ve told you that the LSA is started by the initial process of the system, WinLogon, I’ll 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.
Chapter 2
30
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 Manager–based
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, I’ll 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 isn’t 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 isn’t really a standards-based directory service. Although it supports a Lightweight Directory Access Protocol (LDAP) interface and seems to be a traditional directory service, it’s 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.
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 AD—SAM, Messaging Application Programming Interface (MAPI), REPL, and LDAP. Legacy NT communications for clients that aren’t 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 I’ve discussed the system architecture of Win2K and how AD fits into the larger picture, it’s 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 I’ll be discussing in this section.
31
Chapter 2
32
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 isn’t 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 AD—operations 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 you’re 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 I’ve presented here, but the important thing to remember is that AD supports LDAP only for directory services access. It’s not a true LDAP implementation at the information-storage level. While this really has no real ramification, it’s 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, it’s 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 isn’t used when we specify a computer on the Internet. For example, we’d never specify a DNS domain name as bindview.com.root; instead, we specify it as bindview.com.
Chapter 2
Typically, a DNS name is made up of four major components. The component furthest to the xt component to the left is a formally registered
ld have a fully
espace; there is DNS.
MicDN egrated 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.
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.
right is the top-level domain name. The nedomain 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 wouqualified domain name of jessie.us.northamerica.sheabear.com.
Relationship with Active Directory By this point, it’s probably clear that AD provides a hierarchical namespace. The question that remains is: how? Based on the title of this section, you’ve 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 justan example of a global directory service with the following traits: it’s 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, it’s natural that AD would use DNS to provide its namno reason to re-invent the wheel. In fact, AD services are even located using queries to
rosoft also took DNS integration with AD to another level using an enhanced version of S known as AD-Integrated DNS. AD-Int
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, it’s an important point that is often overlooked.
33
Chapter 2
34
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.
Chapter 2
35
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. That’s 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. We’ll 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 Win2K’s DNS implementation, you don’t 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, it’d 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 read-and-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 aren’t 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 un-acceptable 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, it’s 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.
Chapter 2
36
It’s 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. We’ll 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 didn’t 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 user’s name, e-mail address, phone number, and so on.
While I’ve 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.
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 company’s organization at a macro level.
• Stores information about objects in the domain—The partitioning of AD information into domains allows for greater scalability than a single monolithic domain.
• Acts as a boundary for security—Security policies and settings can be enforced in one domain without affecting other domains, where the required policies could be quite different.
37
Chapter 2
38
• Acts as an administrative boundary—Like 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 locations—While 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 doesn’t force any requirements on the physical placement of servers.
• Tied to a DNS namespace—As 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 relationships—Although really a result of the Kerberos protocol, it’s worth mentioning that Win2K domains in a hierarchy are linked by automatic and transitive two-way trusts. I’ll 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 domain—All of the domain controllers run Win2K.
• Mixed-mode domain—Both 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, it’s more properly referred to as a mixed environment.
Chapter 2
39
Win2K supports mixed mode to provide the greatest level of backward compatibility with NT 4.0 domain controllers, but it’s 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 local–enabled, but also you become able to nest groups within other groups. I’ll talk more about these group changes in Chapter 5 when I talk about access control.
Domain Trees and Forests While it’s 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.
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 they’re 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 five-
e 2.6. domain Win2K environment, as shown below in Figur
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 don’t share a common root. However, they’re 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. They’re 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 aren’t 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
the Congo and the in.
.
Figure 2.8: A Win2K shortcut trust.
Why would you want to create a shortcut trust? Using Figure 2.8, let’s 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 betweenUS. This path would traverse all the way up one tree, across to the other, then back down agaBecause 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 hopObviously, 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 they’re one-way and non-transitive. 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
.9: A Win2K external trust. Figure 2
Or nWhile domainimporta ture of objects in a domain. As I said h con n l namesp
One of of users, c OUs. These groupings can be easily created, deleted, or
t how GPOs
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.
ga izational Units an organizational unit (OU) is but one of many types of objects that you can create in a , it’s perhaps one of the most important objects to understand. The concept of an OU is nt because it allows you to create another logical struc
w en I talked about objects earlier in this chapter, OUs are simple container objects that cantai other objects. The fact that OUs are containers allows you to create a logical, hierarchica
ace within the confines of the more physical namespace of a domain.
the nice features of an OU is that it’s relatively simple to create logical groupingsomputers, groups, and other
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 isn’t the OU itself buit can be used in conjunction with Group Policy Objects (GPOs). I’ll talk a lot more about 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
43
Chapter 2
44
Don’t 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 computer’s Administrators group. There is no correlation between privileges in AD for a computer object and local rights on the physical computer. For example, let’s say that you’re 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 doesn’t 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 doesn’t 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 parthe AD architecture are available to security account information. In particular, three capabilitiesgreatly enh
t of
ance the ability of an organization to control administrative access to security account
of a
sions to manage accounts in other parts of the organization.
ights—Allow you to grant access rights for specific operations.
• Inheritance of access rights—Allows you to grant access to a higher-level container of y and have the rights flow down to the sub-containers and leaf objects. For
irectory
These three AD capabilities allow yojob ienviron hey require is to r t fine-grainedpasswords for the pool of 25 users without allocating any other administrative privileges.
ironment compared to the number
information.
• Delegation of administration—Can confine the security administration capabilities user to apply only to defined subsets of an entire domain. For example, this allows anadministrator to manage a set of users, computers, or groups within his or her area of responsibility and, at the same time, not give permis
• Fine-grained access rFor 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.
the directorexample, you can modify administrative capabilities on entire portions of the dtree by making changes to a specific container; this automatically affects all sub-containers and leaf objects.
u to grant administrators the requisite privileges to do their s w thout granting them more privileges than they actually require. So while in NT 4.0
ments, administrators must be domain administrators even if the only right tese user passwords for a pool of 25 users, AD’s delegation of administration and
access rights allow you to configure Win2K to enable administrators to reset users
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 envthat exist in current NT 4.0 environments.
Chapter 2
45
Sites When I talked about DNS SRV records earlier in this chapter, Table 2.2 mentioned the notiona site. A site is nothing more than one or more TCP/IP subnets tha
of t are connected by a high-
to
e domain controllers in a domain. In a site, intra-site replication is conducted strictly using Remote Procedure Calls
ites, inter-site replication can be conducted using either RPCs or a messaging
ly,
ion
ain controllers. This is a significant difference when compared to the master–slave model of single-master replication that existed in NT 4.0.
speed link. (Typically, a high-speed link is considered to be a T-1 connection or higher; failurefollow 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 longas the subnets are well connected, they can belong to the same site.
A site is primarily used to determine the replication topology among th
(RPCs). Among sprotocol.
Computers also use a site to find a domain controller that is logically closest to it. Typicalwhen 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 it’s on, it begins its search for a domain controller in its own site; only when the client cannot find the needed servicein 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 you’re probably wondering what the heck it is. While you know that AD uses multimaster replicatand you know its benefits, this is where I’ll finally describe how it works.
Data Partitions First and foremost, the data stored in AD is partitioned into three distinct categories.
• Domain data partition—Contains 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 partition—Contains 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 partition—Contains the replication topology and other miscellaneous information that is replicated amongst all of the domain controllers in aforest.
On a GC server, a fourth type of partitioned data exists—partial data. The partial data partition contains a partial set of attributes for all of the objects in a forest. It’s 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. It’s known as multimaster replication because any of the domain controllers can receive an update and replicate it to the other dom
Chapter 2
46
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.
e ber, and you’ll
eir changes to each other at exactly the same time? There are still two different values for the CEO’s phone number, but now they’ve switched
stood this problem and devised a scheme to avoid synchronization
t is
s local replica of AD, it increments its USN and stores this value with ures
its current USN with the USN of
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.
Therefore, while you can choose one or the other protocol for specific replication purposes, it’s 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 CEO’s phone number on one domain controller, and I make a different change to the number on the other domain controller at almost exactly the samtime. Now each domain controller has a different value for the CEO’s phone numretrieve 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 th
places! Microsoft underproblems 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 thamaintained 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 itthe property, which was written as a single atomic operation. Using an atomic operation ensthat the USN is never incremented and isn’t stored with the property in the case of a catastrophiccomputer failure after the USN is incremented and before it’s 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 comparethe 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
Chapter 2
47
While the USN is used extensively to ensure that updates are properly replicated, the PVN en by ensuring that when a change is made to the same object attribute on
he
cur
VN is ved
local PVN, the update is written to the local AD replica.
spending quite a bit ing about replication, but that’s fine. Without it, AD rob tection
cool.
The Global Catalog ed, domain dat
but it’s not replicated with othe ur for every object in a domain’s datadomain–replicated objects are ain
our environmen a GC server. But you’re not stuc or add more if required.
Now that you know you have asimply, the GC speeds up LDAall of the GC data is contained alternatives. Without the GC, e p a complete copy of every
in data pamultiple physical data partition
Neither case sounds very attracentire forest when you know o have no idea which domain sto ject.
carries the heavier burdmultiple domain controllers at about the same time, AD holds a consistent value across all of theseparate 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. It’s tfunction of the PVN to sort out replication collisions.
Unlike a USN, which is a domain controller–specific value, a PVN is an object attribute–specific 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 ocduring a replication operation don’t 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 Plower than the local PVN, the update is considered stale and discarded. But when the receiPVN is higher than the
I ended up of time talkand Win2K wouldn’t be asand dampening are pretty
ust an OS platform as it is. Besides, replication-collision de
As I just discuss a is replicated among all of the domain controllers in a domain, r domains. Inter-domain replication of domain data does occ partition, but with a limited subset of attributes. These inter-
stored in the Global Catalog (GC) on a subset of the domcontrollers in y t. By default, the first domain controller of a new domain is also
k with this configuration, and you can move the GC at a later date
GC in your Win2K environment, what is it used for? Quite P searches that need to occur across your entire forest. Because in a single data partition replica, queries are much faster than the ither each domain would have to kee
other domain’s doma rtition or queries across the entire forest would have to search s in each domain in your forest.
tive. Thus, using the GC greatly simplifies searches across the nly a couple of the attributes of what you’re looking for and youres the ob
Chapter 2
48
Operational Roles I’ve 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
ome very important domain troller is required to control
cal n
a result, only a single dom
domoperational role to a different domain controller. Table 2.4 shows the five FSMO variants supported by Win2K.
made to AD have implications for the entire forest and/or for sproperties. For these types of AD updates, a single domain conreplication and ensure that critical changes are correctly propagated before the next set of critichanges begins. In effect, a single domain controller must lock out all other domain controllers ithe 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. Asain 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 ain controller that is serving as a FSMO role holder fails, you can manually assign the
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 oneRID 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
troller to all of the other domain controllers in the forest. time.
domain conOnly one schema master can be active in a forest at a
PDC emulator Assigned to the only domain controller that can act as a Windows PDC in a domain. This domain controller services network clients thaaren’t AD-aware and handles replication to NT BDCs for the domain i
NT t f
ccur on other domain controllers in the domain. This allows it to handle any password authentication requests
another domain controller. Only one PDC emulator can be active in a domain at any time.
it’s still in mixed mode. When the domain is in native mode, the domain controller assigned this role receives preferential replication of password updates that o
that have failed at
Infrastructure master Assigned to the only domain controller that can update cross-domain group-to-user references to reflect changes in a user’s 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.
Chapter 2
49
By default, the first domain controller in a forest is assigned the forest-wide roles, and the first ain
plications of the problems. The security pro
domain controller in a domain is assigned the domain-wide roles. As a result, the first domcontroller 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 imdefinitely 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, it’s helpful to understand the core MMC snap-ins that are used to manipulate, configure, populate, and maintain AD. My goahere isn’t to teach you how to navigate all of the intricacies of each snap-in; instead, it’s 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.
l
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 doesn’t 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 oin a domain.
bjects
Table 2.5: Core MMC snap-ins for administering AD.
Delegation of Control Wizard One of the tools that you’ll probably want to become familiar with is the Delegation of Control(DoC) wizard. Using the wizard allows you to quickly delegate the administration of pre-specified 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 it’s 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, you’ll want to use the wizard when you’re first playing with the security of an AD object just to get a feel for things.
Chapter 2
50
Backup, Restore, and Disaster Recovery One of the primary security objectives that I laid out in Chapter 1 was availability. While everyone knows it’s important, some of the most overlooked aspects of an organization’s 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
tire sys System State data.
It’s in the category of System State data that AD resides. In fact, AD and all of the other system t it depends on are considered part of the System State data. On a m State data includes the system startup files, the Registry, the File
re
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 e logs keep a record of each tran c
Wh a 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. Ma s ve and the System State check box to ensure that you
ain controller in the enterprise to an
s
h
the local contents of AD. For
s when your AD becomes corrupted,
other services running on your Win2K systems. The Backup tool backs up and restores an entem, just selected files, or the
components and services thadomain controller, the SysteReplication service (FRS), the SYSVOL directory, a few other important services if they’installed, and of course AD. When the Backup tool creates an archive of AD, it includes the following files (typically stored
updates to the AD database, and thsa tion that has occurred in AD.
ile ll of this is fun information to have,
ke ure that you select every local drihave a complete copy of the computer and AD.
Unfortunately, you must perform a backup on every domentirely back up AD. This is because the Backup tool cannot back up a remote computer and conly 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 ithis really? As usual, it depends.
The simplest way to restore a damaged domain controller is to just start over using a fresinstallation of the OS. Once you’ve installed the server, you can promote it to a domain controller and follow standard replication procedures to repopulate 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 happenor worse—you lose all of your domain controllers because of a catastrophic failure, and you needto invoke disaster recovery procedures? The answer is to use the last known good backup that you’ve created, one that contains all of the system drives of one of your domain controllers and the System State data.
Chapter 2
51
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 you’re restoring, was created.
Basic Troubleshooting ile you may never have to help troubleshoot AD problemWh s, it’s useful to have a basic
understanding of AD troubleshooting techniques. Overall, problems with AD can be broadly organized into five categories.
the TCP/IP network settings of your computer. If you have a valid IP address and default gateway, your network
especially if they were retrieved from DHCP. If everything looks
S is
ul
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.
• Network connectivity troubleshooting
• Name resolution troubleshooting
• Domain controller troubleshooting
• Authentication troubleshooting
• Access control troubleshooting.
While I won’t 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 you’re experiencing problems with AD is your network connectivity. Run the IPCONFIG /ALL command to retrieve
settings are probably valid, good here, next ping the default gateway to ensure that the network itself is working. If everything looks correct and you’re 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 DNoperating 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 usefinclude NBTSTAT and the Resource Kit tool DNSCMD.
Next check the domain controllers themselves by running the DCDIAG tool to get a look at thestate 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
Chapter 2
52
If your computer cannot be joined to a domain or is experiencing other authentication difficulties main computers, you need to investigate potential authentication problems.
SACLS s
in talking to other doTools 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 Dand SDCHECK. The DSACLS tool is interesting in that it lets you display and modify the ACLof an AD object. While you should probably not play with AD ACLs too much, it’s 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 don’t 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 isn’t a lot of consensus about how to
ts, in2K
erver infrastructures while leaving their NT 4.0 domain infrastructure fully
reason. Even worse, you may run into the stubborn vice president
native mode.
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. I’ve 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 environmenbut most organizations have taken a wait-and-see attitude toward AD; they’ve deployed Wto their desktops and sintact. Nevertheless, there are some basic best practices when it comes to AD that I don’t 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 you’d first anticipate. All too often, applications that are critical to the success of your business are runningon a legacy version of NT, and management is afraid to touch them, or the applications just won’t run on Win2K for somewho just can’t 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 can’t 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-AD–aware applications while experiencing the benefits of running in
Chapter 2
53
Domain Forests When you first deploy AD in your enterprise, you’re 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 bebecause they only have to search a single forest to find resources in the environment.
I’m a strong believer in a single-fore
nefit
st implementation, but situations do arise that necessitate
er
ioning.
t two domains.
You also need to consider multiple domains if a variety of security policies exist for user and password policies. Although I’ll talk about this more in the section on Group Policy, I’d 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. It’s 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.
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 othforests. 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 don’t think it’s necessarily thebest approach for all organizations with regard to domain trees. If your organization is relativelysmall 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 partit
While I understand the rationale behind the first reason, I don’t really buy it. Many deploymentsof 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. It’s the second two reasons that I think should drive all but the smallest organizations to consider at leas
Chapter 2
Organizational Units The first thing that everyone is tempted to do when they start designing their OU structure is tmodel it after the structure of their organization. I have one thing to say about this: Don’t 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 isn’t wise
o
to follow this path.
al unit.
n, not ap-
ur domains, I believe that you should
with all examples, this one is a little contrived. But hopefully when I’m through, you’ll
Canada, another for Europe, and a third for Asia. Now let’s walk through how the
In my opinion, Microsoft made a mistake when they called this container an organizationFrom 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 administratiocreating some pretty hierarchical tree in your Active Directory Users and Computers MMC snin. When you’re designing the OU structure for each of yoonly create OUs when you want to delegate administration. I’ve 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 I’d set up my fictitious company SheaBear Inc. You saw the finished domain model earlier, but how did I getthere? Asunderstand why I think that this sort of structure is best. I’ve included the figure again below (see Figure 2.10).
Let’s 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 departments—one for the US andcompany arrived at the final design for its AD infrastructure.
Figure 2.10: The forest structure for SheaBear Inc.
54
Chapter 2
55
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
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 it’s not the company’s registered domain name. Instead, it’s 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, they’d create three domains, one for each of their respective organizations—NorthAmerica, 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.
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 they’d 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 forest’s schema. Even with this suggestion, each IT department was leery of letting one of the others have the schema master FSMO role in
Chapter 2
.11: OU design of the US domain of SheaBear Inc. Figure 2
By default, each domain starts with a Domain Controllers, Computers, and Users OU. As the ult locations for these types of AD objects. All domain
ts are
SheaBear Inc.
team e two e sen
names imply, these are the defacontrollers are automatically put into the Domain Controllers OU, all other computer objecautomatically 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 wasn’t a good fit for
The North America–based 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 SheaBear’s world headquarters.
The headquarters administration team was actually made up of two specialized administration s, which were wholly responsible for the Finance and Human Resources departments. Thes
teams were kept small and separate to ensure that very few individuals had access to thsitive data these departments kept.
56
Chapter 2
57
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 The desktop administration group took
new OU. control of the Computers group because it would now
onl o rs group so that c dquarters adm
When I think about the best designs for AD, I try to keep the following principles in mind:
erprise- put
f your infrastructure.
, which tant change
egated administration. As I
In Chapter 1, I talked briefly about role-based authorizations. When it comes time to delegate authorizations are the best approach. The first step in creating a
l
y c ntain desktop machines. The user administration group took control of the Use it ould continue to service the user accounts throughout the US. Finally, the heainistration group created the final three new OUs to mirror its administrative structure.
• Always use a top-level container domain to segregate the administration of entwide functions like schema modifications and core infrastructure services. Neverusers 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 o
• 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 hierarchywill be changed by mergers, acquisitions, and reorganizations. This conswould have you constantly modifying your OU structure.
Delegated Administration One of the great promises of AD was its ability to provide deldiscussed earlier in this chapter, the Delegation of Control wizard is the primary tool provided by Win2K for delegating administrative functionality.
administrative tasks, role-basedrole-based authorization is to create a new security group, then use the Delegation of Controwizard 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.
Chapter 2
58
While it’s tempting to create a few dozen administrative roles right from the start, I strongly caution you against it. AD is so complicated that I’ve 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:
• Domain Administrators—Built-in group with control over an entire domain
control over an entire forest.
han es.
hat even Microsoft figured out that administering AD with its
• Help-Desk Administrators—Primarily to troubleshoot and reset passwords
• AD Administrators—To add and delete users, groups, and computers but not reset passwords
• Enterprise Administrators—Built-in group with
While this is better than what NT 4.0 provided right out of the box, it’s probably a lot less tyou expected after hearing all the hype about Win2K’s delegation of administration capabilitiIf you want more than three or four roles (and who doesn’t), I strongly urge you to consider using a third-party tool to manage administrative roles.
One of the rumors on the street is town tools wasn’t 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 you’re 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 you’ve 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 they’re also running on Win2K.
o 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 dthis, 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 won’t keep someone from installing a DHCP service on a computer. But if it’s installed on a Win2K domain member server or domain controller, it’ll keep the service from running. To ensure that your environment is devoid of non-Win2K, rogue DHCP servers, you’ll have to perform regular network audits.
Chapter 2
59
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 seupdates. This requires that your DNS zones are AD-integrated zones, that you modify zones tallow Only Secure Updates, and that you specify which users and groups can modi
cure o
fy zones and
cords,
Active Directory Security Vulnerabilities rosoft products, you can bet that Win2K and AD have received some pretty y. Nevertheless, two significant security-vulnerability claims have been made
d
. had
ould 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 couldn’t be assured of having sole ownership of the OU.
Novell’s 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 didn’t 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, let’s 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.
I’ve 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.
resource records using ACLs.
Once you’ve configured DDNS, only computers with domain accounts can create DNS reonly 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, don’t be concerned; if they use the secured DHCP server, it will add and own the DNS record for the client.
Like most Micintense scrutinagainst AD explicitly. Although neither one is really a vulnerability, both underscore the fact that if you’re going to successfully deploy AD in a large enterprise, you must do your homework anunderstand it from top to bottom.
Novell made the first security-vulnerability claim just as Win2K was hitting the marketplaceNovell asserted that AD was flawed because it was possible for someone to believe that theycomplete, private control over an object in AD when in fact someone else c
Chapter 2
60
No matter what the replication collision decision, one of these updatesbecomes a security vulnerability only if the change that removed Alice
is going to be lost. But it is discarded and
hink
the FSMO roles, just treat updates to security groups as though
st significant new feature of
overwritten by the update that added Bob. That’s 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 tit is. Is it a big deal? No, it’s 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, you’ll find that the problem is reasonably well documented. In fact, the workaround for this problem is relatively simple. Rememberingthere 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 moWin2K. Clearly, it’s the centerpiece of Win2K, and it provides the foundation for many of the new features and benefits of the OS. So although I’ve not really done AD justice in this short space, I’ve talked about the key features and services that AD provides, how they’re implemented, and how to use and administer them. You must understand these features and services if you’re going to successfully secure your Win2K infrastructure.
Chapter 3
61
Chapter 3: Managing Group Policy Security
s
technology umbrella is quite interesting, however, this chapter is all about Group Policy—how it it to your organization’s best advantage to provide
ly
use o
Thi a
Group Policy is part of Microsoft’s effort to reduce the amount of administrative overhead that irequired in Windows 2000 (Win2K), and it’s 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
works, what it can do for you, and how to use a secure Win2K infrastructure.
So what is Group Policy? Quite simply, Group Policy is a new capability in Win2K that centraldefines, 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; it’s 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 theynot 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
Gr up Policy to configure and maintain a number of things, as shown in Table 3.1.
s C pability 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. Softwar al e Installation Assigns and publishes applications. Published applications are option
and can be installed on demand, while assigned applications are installed automatically.
Security Settings curity settings for domains, computers, and users. Manages se
Table 3.
Althou , it’s the ability to centrally manage
is chapter. I’ll also describe how Group Policy is implemented and give you a basic understanding of how
man
1: The capabilities of Group Policy.
gh I put Security Settings at the bottom of the tablethese that makes Group Policy such an important tool. Group Policy is the mechanism that you’ll use to ensure that the security configurations of your Win2K infrastructure are applied consistently and without fail.
As I’m sure you’ve already guessed, setting security will be a major focus of th
Win2K implements Group Policy. By the time I’m done, I hope you’ll have reached the same conclusion I have—that Group Policy is probably the most exciting and effective tool for
aging the security of your Win2K infrastructure.
Don’t 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.
Chapter 3
62
How Did Group Policy Come About?
ers of the domain, thus
t
ed f
d on Registry settings, and then only a specific set of Registry settings. While Microsoft released a Software
e capabilities of the System Policy Editor, few third extensions.
uration
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. Microsofthas 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 user’s 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 computdefining 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, it’s without a doubt somewhaof 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 aren’t secure. Simply using a Registry editor can undo many of the Registry settings that you’ve applied.
• Registry changes made by the System Policy Editor can persist long after the policy settings are removed from the domain. For example, let’s say that someone once decidthat it was a good idea to remove the Network Neighborhood icon from the desktops oall the users in your domain. Now let’s say that this was later seen as a mistake, and itwas decided to put the icon back on everyone’s 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 base
Development Kit (SDK) to extend thparties seem to have embraced these
While the System Policy Editor has been extremely useful in centralizing many configsettings 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.
Chapter 3
63
Developing into Group Policy Objects
a bit later, but for now, I want to talk briefly about the hy they’re an improvement over System Policy.
comEdi .0 wor e feat
But unlike System Policy Editor settings, GPOs are secure, and they can be fully managed. for managing the security of your infrastructure because GPOs
can count on to do the right thing. GPOs are secure because only
,
ior of
Letwhienvironment, so every time you install the application, you have to spend 10 minutes configuring
while, maybe you build a Registry file to import all of the settings
How Group nd templates that store
o specific AD containers such as sites, domains, and/or OUs so that the settings can
be a l ent.
It a t Gro globall lps kee h in the section
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. Thesesettings are stored in Group Policy Objects (GPOs). I’ll talk much more about GPOs and how they’re stored, manipulated, and applied capabilities inherent in GPOs to show you w
First, GPOs can be applied to AD sites, domains, and OUs and can therefore affect all the puter and user objects contained in these AD containers. In all fairness to System Policy
tor settings, this is really not a big difference because sites and OUs didn’t exist in the NT 4ld. And like System Policy, GPOs can be further controlled using security groups. These corures of GPOs build on the strengths of the System Policy Editor.
These are important distinctions provide a mechanism that you 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 upwhen 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 aren’t part of the initial Win2K installation. This is a powerful capability that unfortunately seems to have gone mostly unnoticed to date by software developers. I’ll talk about how to extend the behavGPOs later in this chapter, but here I’ll talk about why the ability to extend a GPO is so neat.
’s say that your company uses an off-the-shelf application that comes with a ton of bells, stles, and configuration options. However, not all of its defaults are appropriate for your
it to function properly. After ain 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.
Does Group Policy Work? Policy is implemented as a combination of containers a
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 arethen linked t
pp ied to computer and user objects throughout your environm
ll s arts with the two main components of a GPO—the Group Policy Container (GPC) and theup Policy Template (GPT). The GPC and GPT are named using something known as a
y unique identifier (GUID). The GUID ensures that the components are unique and hep t em synchronized throughout your environment. These three elements are described
s below.
Chapter 3
64
TheA globa ct; it’s n ce num ereven if the object is renam
Globally Unique Identifier lly unique identifier (GUID) is a 128-bit identifier that is unique to a particular obje
ge erated from a unique identifier on a device, the current date and time, and a sequenb . The GUID uniquely identifies any object because once it’s issued, it’s never changed,
ed or moved.
GUIDs are unique in a single namespace (like an AD forest), but they’re not guaranteed to be unique across all namespaces. The probability of ever seeing two identical GUIDs is so low that it’s highly unlikely to ever happen, but even if it did, there is absolutely no risk to your Win2K environment because you’ll 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 object—version 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, don’t 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, it’s stored in the \%SYSTEMROOT%\sysvol\sysvol\<domain name>\Policies folder. As a result of where it’s 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:
• ADM—The set of administrative templates for the GPO.
• MACHINE—The 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:
publish and assign applications to computer objects.
• Scripts—The startup and shutdown scripts plus their related files for computer objects.
• Applications—Files used by the Windows Installer service to
Chapter 3
• USER—The 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:
• Applications—Files used by the Windows Installer service to publish and assign applications to user objects.
• Scripts—The 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 isn’t 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
66
Keep in mout of sync. Thus, in order for the GPO to be applied, the version numbers of the GPC and GPT
st match. If a situation arises where they don’t, an error is logged, and the GPO isn’t applied.
ind that because the GPC and GPT are stored and replicated separately, they can get
mu
ification tool from the You can check the consistency of your GPOs using the Group Policy Object VerWindows 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 sidof things, I’ll 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 Win2Kcomputers. These DLLs are known as client-side extensions (CSEs) because they process
e
rk
and GPT configuration containers, then applies it to the appropriate computer
ou e computers in
your domain. When the user logon event occurs, the Winlogon process checks AD to find out en each CSE queries the appropriate GPCs for
any
e user.
There is a fundamental relationship between Group Policy and AD. In fact, Group Policy extends
,
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 woon a workstation or server. A CSE receives the configuration information of a GPO from the appropriate GPCor 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.
Here’s an example of how CSEs function as the client-side portion of a GPO. Let’s say that yhave a GPO that is responsible for implementing the user Registry settings for th
whether any GPOs are to be applied to the user. Theach of the relevant GPOs to determine whether the policy is currently enabled and makesother 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 th
Group Policy and Active Directory
and takes advantage of the AD service to provide its functionality. As I mentioned earlier, GroupPolicy settings are stored in a GPO, and GPOs in turn can be associated with the following AD containers: sites, domains, and OUs. GPO assignment isn’t 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 sidea single GPO can be applied to multiple AD containers.
Chapter 3
67
When you create the first domain controller of a new domain, two default GPOs are automatically cre ted: the Default Domain Policy and the Default Domain Controllers Policy. The Default Domaia n Policy is linked directly to the domain and specifies some generic security settings for the entire do ain. The Default Domain Controllers Policy is linked to the Domain Controllers OU and sets a msmall handful of security settings for all of the domain controllers in the domain.
Group Policy Assignment While I mentioned it above, it’s 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 don’t 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 shouldn’t 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. It’s 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 can’t 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 we’ve established that you can have multiple GPOs linked throughout your AD hierarchy and multiple GPOs linked to the same AD container, it’s 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.
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 aren’t inherited across domain boundaries.
What do these rules mean? They mean that processing of GPOs is applied in the following order:
1. Local GPO—Each Win2K computer has a local GPO that is always applied.
2. Site GPOs—Any linked site GPOs are applied in administratively specified order.
3. Domain GPOs—Any linked domain GPOs are applied in administratively specified order.
4. OU GPOs—Any 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. Let’s 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 won’t talk about the application of the local GPO in our examples; judon’t forget about it as we walk through them.
st
Figure 3.3: Group Policy assignment and processing.
Let’s start with objects in OU X2. The first thing to decide is whether any GPOs are linked to the si that contains OU X2. You’ll notice that site Z has GPO X3 linked to it; therefore, this is the
find GPO X1 and GPO POs defined in the container, assume that
hat 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
t inheritance of GPOs from domain X?
tefirst GPO to be applied. Next, look at the domain container, and you’ll X2 linked to the domain. Because there are multiple Gthe GPOs should be applied in ascending order. Finally, see what GPOs are linked to the OU itself, and you’ll find one, X4. Now that you’ve found all of the relevant GPOs, you determinetheir 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 t
domain GPO and a single OU GPO. But what abouSimply, GPOs aren’t inherited across domain boundaries. In fact, if you play with things and really take notice, you’ll 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
70
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 aren’t 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 isn’t set—The child inherits the policy setting from the parent.
2. Parent value is set, child has a non-conflicting value—The parent setting is applied, then the child setting is applied.
3. Parent value is set, child has conflicting value—The parent setting isn’t 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, it’s 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.
Chapter 3
Figure 3.4: The effect of Blocking Group Policy Inheritance.
Using Figure 3.4 as an example, let’s 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, let’s say that you want to create a domain policy that takes caof the core security settings for your domain,
re 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
all of the OUs in your environment. container. As a result, your domain policy is now applied to
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 don’t affect the order in which they’re processed.
Filtering Group Policy Using Security Groups The final mechanism for modifying the default processing of GPOs is filtering a GPO using
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.
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 ApplyGroup 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
72
Chapter 3
Figu
Ignoring Certain Group Policy Settings As utyp oonly onDisabli kip over the disabled settings when it’s trying to figure out what GPO settings to apply. This is yet another way in which you can reduce the
ad and apply all of the assigned GPOs for a particular computer or user
in the user
portion of the GPO so that Win2K never wastes time trying to apply the non-existent settings. To in the Group Policy Editor MMC snap-in, right-
clic tapp
re 3.6: The security settings on a GPO.
yo ’ll see when I talk about what you can configure with a GPO in the next section, two basic es f settings are available in a GPO: computer and user. If you build a GPO that contains
e of these two types of settings, you can disable the portion of the GPO that isn’t in use. ng a portion of the GPO allows Win2K to s
time that it takes to reobject.
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 the computer portion of the GPO. Because of this, it just makes good sense to disable
do this, highlight the name of a particular GPOk i , then choose Properties from the shortcut menu. On the General tab, select the ropriate check box, as shown in Figure 3.7.
73
Chapter 3
.7: Disabling a configuration setting on a GPO. Figure 3
Gro pAs I mGPOs. notice a result o h the GPO is in scope (assum ). While this
minimize the number of GPOs that have to ent.
This e
u Policy Access Control Lists entioned earlier, all objects in Win2K can have ACLs associated with them, including The default settings for a GPO are shown in Table 3.2. One of the interesting things tois the use of Apply Group Policy, which is given to the Authenticated Users group. As f this setting, all GPOs are by default processed by all computers and all users for whic
ing that no other inheritance-modifying features are usedisn’t necessarily a bad thing, you’d probably want tobe processed by being more specific about who can read and apply GPOs in your environm
S curity Group Has These ACL Settings
Authenticated Users Read, Apply Group Policy Domain bjects, Delete All Child Objects Admins Read, Write, Create All Child OEnt rerp ise Admins Read, Write, Create All Child Objects, Delete All Child Objects SYSTEM Read, Write, Create All Child Objects, Delete All Child Objects
Table 3.
AnotheWrite p st anyone modifying your
2: The default security settings on a GPO.
r thing to notice about the Authenticated Users group is that, by default, it doesn’t have ermissions. This is a good thing because you don’t want ju
74
Chapter 3
75
GP e Users clook atThis 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 doesn’t have Write access, the Group Policy Editor snap-in doesn’t 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 can’t describe all 1,000-plus GPO settings here, but I’ll 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, I’ll 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.
O s ttings. But you might expect that because they have Read access, your Authenticatedan open the GPO using the Group Policy Editor snap-in. However, if you’ve ever tried to a GPO as an Authenticated User, you know that the snap-in doesn’t display the GPO.
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, you’ll notice that the following nine main containers hold security settings:
• Account Policies—Defines the security settings that affect password policy, account lockout policy, and Kerberos policy in the computer configuration namespace.
• Local Policies—Defines the security settings that affect audit policy, user rights assignment, and security options in the computer configuration namespace.
• Event Log Policies—Defines the security settings that affect the use of the application, security, and system logs in the computer configuration namespace.
• Restricted Groups—Defines properties for security-sensitive groups (that is, “restricted” groups) in the computer configuration namespace.
• System Services—Defines the startup mode (Manual, Automatic, or Disabled) as well as access permissions for all system services in the computer configuration namespace.
Chapter 3
76
• Registry—Defines access permissions (discretionary access control lists, or DACLs) and l lists, or SACLs) for Registry keys in the computer
File System—Defines DACLs and SACLs for file-system objects in the computer
• the user and
• gs
SecurIn these e just over 100 security options that you can set in a single GPO. Wh iwhat mhow th
Ac u• of
main Policy. The more security-conscious your
• at passwords in
your environment never expire. The setting defaults to 42 in the Default Domain Policy to a value between 30 and 120, depending on the security
0 specifies that
m,
Policy and should be changed immediately. A value of 7 is probably
audit settings (system access controconfiguration namespace.
• configuration namespace.
Public Key Policies—Defines the security settings that affect the behavior of the public key infrastructure (PKI) built into Win2K and have applicable settings incomputer configuration namespaces.
IP Security Policies—Defines the security settings that affect the use of Internet ProtocolSecurity Protocol (IPSec) implementation built into Win2K and have applicable settinin the computer configuration namespace.
ity Settings nine containers, there ar
ile t may become a little tedious for some, I think that it’s important that I talk briefly about any of these security configurations do. In some cases, I’ll provide some guidance on ese settings should be configured. Just remember, my bias is toward security!
co nt Policies | Password Policies Enforce password history—A value between 0 and 24 that determines the number unique new passwords that must be used before users can start recycling old passwords. It defaults to 1 in the Default Doenvironment is, the larger the value you should choose.
Maximum password age—A 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 th
and should probably be setpolicy of your environment.
• Minimum password age—A value between 1 and 999 that determines the number of days that a password must be used until it can be changed. A value ofpasswords 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 theusers must change them the next time they log on. But if users cannot change theirpasswords immediately, they can’t log on!
• Minimum password length—A value between 1 and 14 that determines the lowest number of characters that users’ passwords must contain. A value of 0 specifies that users aren’t even required to have passwords! The setting is unfortunately set to 0 in the Default Domainmost appropriate for user accounts and a value of 14 for administrator accounts.
Chapter 3
77
• Passwords must meet complexity requirements—Determines whether to use a password filter (PASSFILG.DLL). Using PASSFILT.DLL requires user passwords tomeet more stringent complexity requirements. I highly recommend using the password filter, and if you’re truly wo
rried about the password quality of your environment, you
• ble this
• g on
pired, this creates an
Ac u•
ked out, and I recommend against using it. A value between 3 and
•
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
ou’ve defined an account lockout threshold, the reset time.
may want to invest in a third-party password-filter program.
Store passwords using reversible encryption—This policy is such a terrible idea that Microsoft should just eliminate it! Under no circumstance should you ever enapolicy. Thankfully, this setting is disabled in the Default Domain Policy.
User must log on to change the password— Determines whether users have to log onbefore they can change their passwords. When this policy is enabled, users have to lobefore changing their passwords. When a user’s password is exinteresting predicament because the user can’t 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.
co nt Policies | Account Lockout Policy Account lockout threshold—A value between 1 and 999 that determines how many failed logon attempts it takes to lock out a user’s account. A value of 0 specifies that accounts never get loc5 should be appropriate for most organizations.
Account lockout duration—A 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
recommend a value between 10 and 60. If ythis value has to be greater than or equal to
• Reset account lockout counter after—A 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.
Chapter 3
78
AccouKee in level.
et occurs against the user rights policy of the target computer. This policy is enabled in the
ld remain enabled in all environments.
this value to e set as
ket-ld
t a
Lo l One ofauditinsettings I recomm kill the performance of your domain.
audit both success and failure events.
• 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.
nt Policies | Kerberos Policy p mind that Kerberos policy affects the entire domain, so you must define it at the domain
• Enforce user logon restrictions—Determines whether validation of a session tick
Default Domain Policy and shou
• Maximum lifetime for service ticket—Determines the number of minutes that a sessionticket 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 keepminimize issuing session tickets. For highly secure installations, this value could blow as 10, but a value between 60 and 240 is probably sufficient for all but the most paranoid organizations.
• Maximum lifetime for user ticket—Determines the number of hours that a user’s ticgranting ticket can be used. A value of 10 is set in the Default Domain Policy and shoube sufficient for most organizations. For highly secure installations, a value between 1 and 4 is probably sufficient.
• Maximum lifetime for user ticket renewal—Determines the number of days thaticket-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 synchronization—Determines 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.
ca Policies | Audit Policy the first things you’ll probably notice about these auditing settings is that I believe in g a lot of stuff. Thankfully, disk space isn’t the issue it used to be, and most of the audit
end below shouldn’t
• Audit account logon events—Determines 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 account management—Determines 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 access—Determines whether to audit user access of an AD object that has an SACL defined on it. The
Chapter 3
79
• Audit logon events—Determines whether to audit every logon, logoff, and network connection event on a computer. The Default Domain Controllers Policy defines tsetting but has its value set to No Auditin
his g. I suggest changing this setting to audit both
• SACL alue
g
uditing. I suggest
• Controllers Policy defines this setting but has its value set to No Auditing. I
• in Controllers Policy defines this setting but has
ne
system’s
Local Policies | User Rights Assignments User i at most apapplicauser rights are truly appropriate in your enviyou should never assign the following
•
•
•
•
•
•
• access auditing for resources and objects.
success and failure events.
Audit object access—Determines whether to audit every object access that has an defined on it. The Default Domain Controllers Policy defines this setting but has its vset to No Auditing. I suggest changing this setting to audit just failure events.
• Audit policy change—Determines whether to audit every change of policy, includinuser rights assignment policies, audit policies, and trust policies. The Default DomainControllers Policy defines this setting but has its value set to No Achanging this setting to audit both success and failure events.
Audit privilege use—Determines whether to audit the use of a user right. The Default Domainsuggest changing this setting to audit just failure events.
Audit process tracking—Determines whether to audit tracking information for application processes. The Default Domaits value set to No Auditing. While it might be shocking, I suggest leaving this one alobecause it’ll generate a huge volume of information that from a security perspective is mostly meaningless.
• Audit system events—Determines whether to audit events that might affect the security or its security log. The Default Domain Controllers Policy defines this setting buthas its value set to No Auditing. I suggest changing this setting to audit both success and failure events.
r ghts assignments can be a tricky thing because it’s hard to determine if the user rights thplications say they require are truly required. In addition, the sheer number of tions and their required rights makes it impossible for me to really help you decide what
ronment. One thing I can do, though, is tell you that user rights to any user or group:
Act as part of the operating system—Allows a process to authenticate as any user.
Create a token object—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—Determines which accounts can create a folder in the kernel’s object manager.
Debug programs—Determines which accounts can attach a debugger to any process.
Generate security audits—Determines which accounts can add entries to the security log.
Lock pages in memory—Is obsolete and shouldn’t be used.
Manage auditing and security log—Determines which accounts can configure object
Chapter 3
80
• Modify firmware environment variables—Determines which accounts can modify system-wide environment variables.
Replace a process level token—Determines which accounts can replace the tok• en of a
•
Local Policies | Security Options Wh Ithe recoof you c as well
g
• termines
• em to be shut down without having to log on—Determines whether
• d to eject
ll servers be restricted to administrators.
e for
ng up with all the additional audit events unless you’re looking for
• se of Once again, if you enable this policy, it’s doubtful that
•
sub-process.
Synchronize directory service data—Isn’t implemented and shouldn’t be used.
ile fully understand that many of your environments aren’t yet pure Win2K environments, mmendations below assume that you have a homogeneous Win2K environment. Those
with mixed environments need to be careful about signing and encrypting network traffi as the Windows NT LAN Manager (NTLM) authentication options.
• Additional restrictions for anonymous connections—Determines what, if any, additional restrictions should be placed on anonymous connections. I recommend settinthis to No Access without Explicit Anonymous Permissions.
Allow server operators to schedule tasks (domain controllers only)—Dewhether server operators can schedule AT jobs. If enabled, server operators as well asadministrators are allowed to schedule AT jobs. Your administrative procedures will dictate how to set this policy.
Allow systcomputers 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 media—Determines which users are alloweremovable NT file system (NTFS) media. I recommend that interactive users have this capability on all workstations and that a
• Amount of idle time required before disconnecting a session—A 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 appropriatmost organizations.
• Audit the access of global system objects—Determines whether global system objects with SACLs defined are audited. While you can enable this policy, it doesn’t add enough value to warrant puttisomething specific.
Audit use of Backup and Restore privilege—Determines whether to audit every uthe backup and restore privileges. you’ll get enough value from all of the additional audit events to make it worthwhile.
Automatically log off users when logon time expires—Determines whether to log off users automatically when their logon time for SMB connections expires. I recommend enabling this policy setting.
Chapter 3
81
• Automatically log off user when logon time expires (local) —Determines whether toautomatically log off users when their logon time for local connections expires. I recommend enabling this policy setting.
Clear virtual memory pagefile when system shuts down—Determines whether to
•
• ommunications (always)—Determines whether SMB client
• ns are digitally signed when possible. I also recommend enabling this
•
• +ALT+DEL requirement for logon—Determines whether the
gon screen—Determines whether the name of the isplayed in the Windows Logon dialog box. If the
or f
•
u
ecure option.
to log
information about the consequences of misusing the computer’s 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 isn’t available. I recommend setting this value to between 3 and 10.
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 ccommunications 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 communicatiopolicy.
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 CTRLCRTL+ALT+DEL key combination is required before a user logs on. If enabled, the keycombination isn’t 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 lolast successfully logged-on user is dpolicy is enabled, the last user name isn’t displayed. I recommend enabling this policy fall of the servers in your environment but am reluctant to recommend doing so for all othe workstations.
LAN Manager Authentication Level—Determines which versions of the LAN Manager authentication protocol are accepted. If your environment is free of Windows 9x, Windows Me, and pre–Windows NT Service Pack 4 machines, I recommend that yoconfigure this policy to Send NTLMv2 Response Only\Refuse LM & NTLM; otherwise, you’ll have to pick a less s
• Message text for users attempting to log on; Message title for users attemptingon—Set 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
Chapter 3
82
• Prevent system maintenance of computer account password—Determines whether a computer account password is updated every week. If this policy is enabled, the passworisn’t updated. I recommend disabling this policy throughout your environment.
Prevent users from installing printer drivers—Determines whether regular users caninstall print drivers. If en
d
• abled, this policy prevents users from installing print drivers. I
h
workstations.
ines how far in advance recommend setting this
unt—Determine whether the administrator and/or guest account is renamed. I know it’s a hassle for administrators, but
ment and renaming both
e isn’t an rk. I recommend enabling these
sign secure channel data (always) —Determines ions are always digitally signed or encrypted (but not
nd enabling this policy even though it uses a few more
t secure channel data (when possible) —Determines mmend
Determines
ain controllers in your environment, I recommend disabling this policy. Once all of your domain controllers are running Win2K, you should enable this policy.
recommend enabling this policy for all of the servers in your environment (even thougregular users should never log on to a server), and I recommend disabling it for all
• Prompt user to change password before expiration—Determusers should be advised that their password is about to expire. Ivalue 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 folders—Determine 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 acco
I recommend enabling these policies throughout your environaccounts.
• Restrict CD-ROM access to locally logged-on user; Restrict floppy access to locallylogged-on user—Determine 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 therinteractive user, the media is accessible over the netwopolicies throughout your environment.
• Secure channel: Digitally encrypt or whether secure channel communicatnecessarily both). I recommesystem CPU cycles.
• Secure channel: Digitally encrypwhether secure channel communications are encrypted when possible. I also recoenabling this policy.
• Secure channel: Digitally sign secure channel data (when possible)—whether secure channel communications are digitally signed when possible. I also recommend enabling this policy.
• Secure channel: Require strong (Windows 2000 or later) session key—Determines whether all secure channel communications require strong session key encryption. Until you’ve upgraded all of the dom
Chapter 3
83
• Send unencrypted password to connect to third-party SMB servers—Determines can be sent to third-party SMB servers that don’t support
s .
gthen default permissions of global system objects (such as Symbolic links) —Determines the strength of the default ACLs for global system objects. If enabled, this
r users from modifying
ut
signed non-driver installation behavior—Determines what should happen when a non-device driver that isn’t digitally signed is installed on the computer. The default is to
ehavior is sufficient for all but the strictest environments.
the event logs. While the default is 512K
ystem disk.
t allowed to the logs. If
y be
whether clear-text passwords password encryption during authentication. If this policy is enabled, clear-text passwordare allowed. I recommend disabling this policy for all computers in your environment
• Shut down system immediately if unable to log security audits—Determines 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 behavior—Determines 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 card–enabled computers in your environment.
• Stren
policy modifies the default access to prevent non-administratoobjects that they didn’t create. I recommend enabling this policy for all computers in your environment.
• Unsigned driver installation behavior—Determines what should happen when a device driver that isn’t digitally signed is installed on the computer. The default is to Warn bAllow Installation, and this behavior is probably sufficient for all but the strictest environments.
• Un
Silently Succeed, and this b
Event Log | Settings for Event Logs • Maximum application log size; Maximum security log size; Maximum system log
size—Determine the size in kilobytes (K) of and the maximum is 4 gigabytes, I recommend using settings somewhere between 10 and 100 megabytes (MB) based on the size of your s
• Restrict guest access to application log; Restrict guest access to security log; Restricguest access to system log—Determine whether guest access isthese policies are enabled, guests cannot access the logs. I recommend that this policenabled for all your logs.
• Retain application log; Retain security log; Retain system log—Determine 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.
Chapter 3
84
• Retention method for application log; Retention method for security log; Retenmethod for system log—Determine 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 full—Superseded by Down System Immediately if
tion
Shut Unable to Log Security Audits and shouldn’t be used.
ers
just remember that you can configure the local GPO of a computer using the same tool that you use to configure a domain GPO.
al r
ion aren’t available for a local GPO:
Policies | Kerberos Policy
•
| Registry
Another thing to remember about a local GPO is that in a Win2K domain environment, it’s always processed and always processed first. A local GPO is always processed even if no AD-based GPOs apply to the local computer or user and even if AD-based GPOs have been set to block policy inheritance.
Applying Group Policy to Stand-Alone ComputWhile you most often think of Group Policy in the context of a computer that is a member of adomain, 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 domain—using 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. I’ll cover GPEDIT.EXE later in this chapter (under “Group Policy Editor”), so for now,
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 locGPO, the extensions that support Software Installation, Remote Installation Services, and FoldeRedirection aren’t loaded because each of them requires AD to function properly. In addition, the following portions of the security extens
• Security Settings | Account
• Security Settings | Restricted Groups
Security Settings | System Services
• Security Settings
• 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
Chapter 3
85
Overriding Local Group Policy As I discussed earlier, if a conflict occurs between the local GPO computer policy and an AD-based 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 it’s possible to circumvent domain security settings by removing a computer from the domain. The answer is an emphatic yes! A computer that isn’t 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 organization’s 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
PO isn’t processed at all. That’s right—the local
e ability to extend what a GPO can be used to
s to Registry-based information
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.
aren’t part of an AD infrastructure, the local GGPO 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 thconfigure. Basically, Microsoft has given software developers and administrators alike two simple ways to extend Group Policy:
• —The simpler method of extending a GPO, but you can use it only Template file (.adm)to make change
• Group Policy Editor snap-in extension—A bit more complicated, but it allows you to manipulate both Registry- and file-based information settings.
Chapter 3
Once you’ve 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 snathis is relatively simple. Select the Administrative Templates container in either the Computer or
p-in. To do
User container, right-click it, then select Add/Remove Templates from the shortcut menu. The Add/Re ox appears, as shown below in Figure 3.8, displaying the current your new template to the list, and you’ve success
move Templates dialog bly active templates. You can then addfully extended Group Policy.
e ave 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
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 thsnap-in for the graphical user interface (GUI), you’ll also h
.)
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 you’ll 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 up Policy Editor MMC snap-in either as an extension to one of the other AD
roup Active Directory Sites
te, domain, or OU container, click the s what the Group Policy Editor
You can use the Groadministrative snap-ins or as a stand-alone MMC console. Typically, you launch the GPolicy Editor from within the Active Directory Users and Computers or and Services MMC snap-in. You view the properties of a si
GPO. Figure 3.9 showGroup Policy tab, then double-click alooks like when you start it up.
Figure 3.9: The Group Policy Editor MMC snap-in.
In case you’re wondering, you should install the Group Policy Editor by default op
on all of your Windows 2000
e MMC snap-ins, K.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 he
licy Editor from the command line, use the command:
When you load a GPO into the Group Policy Editor using any mechanism, the GPO is said to be in focus e console is in use, and you mu dded to MMC or as a command-line parameter.
domain controllers. Many times, though, you’ll want to start it from your deskt that you have this and the other administrativProfessional computer. To ensure
you’re best off running the ADMINPA
should also become familiar with loading it using the MMC console directly and from tcommand line. To start the Group Po
gpedit.msc
. You can’t change the focus of the Group Policy Editor once thst select the focus when the extension is a
87
Chapter 3
88
If you start the Group Policy Editor from the command line without parameters, the local policy of the computer you’re 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:
“<ADSI path>”
:"LDAP://CN={31B2F340-016D-11D2-945F-icies,CN=System,DC=internal,DC=sheabear,DC=co
stances where est way to
g applied to a specific computer or inheritance,
the express purpose et of Policies tool,
GPRESULT for just the computer to save a little
/gpcomputer:<machinename>
where <machinename> can be either a NetBIOS or a DNS-style name—for example: gpedit.msc /gpcomputer:"dc01")
• For a specific Active Directory Service Interfaces (ADSI) path: /gpobject:
For example: gpedit.msc /gpobject00C04FB984F9},CN=Polm"
Group Policy Resultant Set of Policies Tool initially deploying GPOs in your environment, you’ll run into circumWhen you’re
certain settings aren’t being applied the way you think they should be. The btroubleshoot this is to look at what GPOs are actually beinuser object and determine what the resultant set of policies are after all of theblocking, no overriding, and filtering has occurred.
Thankfully, Microsoft provides a tool in the Windows 2000 Resource Kit for Policy Resultant Sof examining resultant set of policies—namely, the Group
T.EXE. Listing 3.1 shows sample output fromor GPRESULsettings of the applied GPOs. (I removed a number of superfluous blank linesspace, so your output may be spaced slightly differently.)
Chapter 3
89
C:\ p>g result /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: INTERNAL Domain Type: Windows 2000 Site Name: 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:
• /v—Provides verbose output
• /s—Provides super-verbose output
• /c—Displays only the computer settings
• /u—Displays only the user settings.
Chapter 3
90
Become familiar with these options, play with the command, and understand its output. Only by
The last tool that I’m going to describe is another Windows 2000 Resource Kit application. This verify the health of all of the GPOs on your domain controllers.
C:\>gpotool.exe
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
command-line tool allows you toThe 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.
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 GPOTOOLIn 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 can’t be accessed using the Group Policy Editor, such as functionality version and extension GUIDs
Chapter 3
91
• Browse GPOs based on friendly name or GUID
about
L, t works, become familiar with all of its nuances, and you’ll be
prepared if you run into problems with your GPOs and need to spend time troubleshooting.
on how to
a
With a lack of strong recommendations from Microsoft, many of us in the industry had to go it among other organizations to learn all we could about
to
dations that I make are geared explicitly to deploying a set of GPOs that provide security for your environment. That is the
k about will also apply to GPO
eep in mind when designing your Group Policy infrastructure. These issues are generic and encompass most of Microsoft’s initial
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
, you should migrate all of your NT 4.0 System
m and by the same group of people.
• Check GPOs in different domains
• Provide verbose information in the case of GPO errors, including informationcorrupted 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 GPOTOObecome familiar with how i
Group Policy Best Practices When Microsoft released Win2K, there was obviously not a lot of industry consensusbest use Group Policy. But if you’d read through all of the documentation that Microsoft published, you’d have found that it recommended seven ways to approach GPO deployment—rather short list of Group Policy best practices.
alone and work within our companies andhow to best deploy Group Policy. As a result, I’ve built on Microsoft’s original best practicescreate a set of considerations and deployment goals that will help you implement Security GroupPolicy in your environment.
Notice that I said “Security Group Policy.” Some of the recommen
overall focus of this section. But rest assured—much of what I taldeployment in general.
Group Policy Considerations First, I’ll discuss a number of issues that you need to k
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
have a really strong rationale for using themPolicy 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 tande
Chapter 3
92
Blocking Policy Inheritance As I discussed earlier in this chapter (see “Blocking Group Policy Inheritance”), you can prevenGPO 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 doesn’t become overly complicated.
t
Forcing Policy Inheritance nheritance judiciously, so you should ensure that policy
eater the number of associated GPOs, the longer llow, you can also collapse multiple GPOs into
s to
omputer-Based GPO Settings As I mentioned earlier in this chapter, computer-based settings take precedence over user-based
u should take advantage of this h user
s can be assigned to a single AD container, processing a GPO from another domain is significantly slower because domain boundaries are being crossed.
n, you must evaluate considerations to duplicate some GPOs
Just as you should use blocking policy isettings 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 grthe logon will take to process. If circumstances aa single GPO.
Filtering GPOs Using Security Groups Another effective method for minimizing the number of GPOs that needs to be processed iuse security groups and ACLs to filter the GPOs that aren’t 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 C
settings when a conflict occurs between them. The only time yobehavior is when you need the desktop configuration to be the same regardless of whiclogs on.
Assigning GPOs Across Domains Although GPOs from different domain
To avoid performance degradatioacross multiple domains. Although this will increase your administrative overhead, the reduced processing time can be worth the added complexity.
Chapter 3
93
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 yo r Win2K environment.
hierarchy. As you move down the AD hierarchy, make the GPO settings more specific to implement your organization’s 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, don’t worry about defining a local GPO for your AD-integrated computers. Local policy will be overwritten anyway and doesn’t scale anywhere, so don’t 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.
u
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 organization’s security policy as closely as is practical. Put its broadest security policies at the highest positions in your AD
Chapter 3
94
Using OU GPOs to Refine Domain GPOs Use GPOs that are linked to OUs to refine your domain-level GPOs and provide more specific
.
Os Create specific GPOs for the security settings in your environment. These GPOs should specify
lated settings, as I’ve mentioned above and as defined by Microsoft. They should
the pmultiplPolicy, net Information Server (IIS) Security Policy. Eva a oles.
GPO using membership in that security group.
ting adm such as Securitassign age the administration of the GP s
Giving Up Registry Editors For a and. We all knolike RE you may still need to use a Registry editor from tim ke modifications to the Registry that you inte last resyou pu
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 GP
the security-realso 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 aren’t 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 senseto 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
ex ected roles of the computers in your environment. For example, consider defining e security GPOs, such as Workstation Security Policy, Domain Controller Security File Server Security Policy, and Inter
lu te your environment and decide how to best build GPOs based on these computer rWhatever 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
Restricting Administrative Access to Security GPOs This sounds simple, but you need to remember to do it and stay vigilant in restric
inistrative access to the security GPOs in your environment. Create a security group (y GPO Admins) explicitly to contain the administrators of your security GPOs. Then Read and Write ACEs to only this security group and man
O u ing membership in the group.
ye rs, Microsoft has told us not to go into the Registry and make modifications by hw Microsoft has to take this stance, as such we typically ignore this advice and use tools GEDT32.EXE every chance we get. Whilee to time, I recommend that you don’t ma
nd to be permanent. Instead, let GPOs do the work for you. Only use a Registry editor as a ort or as a test to ensure that a setting works in your environment. Then make sure that t the Registry settings into a GPO and apply it that way.
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 wouldn’t 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 integrati
While Group Policy h rity settings that makes it such an i se to ensure that the
on of Group Policy and AD.
as many capabilities, it’s the ability to centrally manage secumportant tool. Group Policy is the mechanism you’ll u
security configurations of your Win2K infrastructure are applied consistently and without fail. I hope you’ll agree that Group Policy is an exciting and effective tool for managing the security of your Win2K infrastructure.
95
Chapter 4
96
Chapter 4: Understanding Authentication
As I discussed in Chapter 1, authentication provides the ability to positively prove that a securityprincipal is who or what it claims to be. Although authentication is usually associated with usersit applies equally to all security principals—users, 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.
,
ith,
reverse occurs, and a
ion, let’s take a quick look at the four
a key that you carry around with
s on. A typical example of two-factor
What It Is Authentication is simply a process that verifies someone’s or something’s identity. For example, think about what happens when you cash a check. When you present the check, you’re typically asked for your driver’s license. Your driver’s 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 wand that the ID was issued by a valid authority. It isn’t a perfect form of authentication, but it’s 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 authentication—Authentication occurs in a single direction. In some cases, a client proves its identity to a server; in other cases, the server proves its identity to a client.
• Mutual authentication—Both client and server prove their identity to the other.
While I mention clients and servers, don’t 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 authenticattypical ways that users can be authenticated. You’re typically authenticated by:
• Something you know—Typically, a secret piece of information that you need to remember. While it’s typically a simple password or Personal Identification Number (PIN), it can also be something like a digital private key.
• Something you have—Typically, a security token oryou. It can be a smart card or a security token such as the SecurID token from RSA Data Security.
• Something you are—Typically, 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 above—Typically, a combination of two of the first three methodand usually called two-factor authenticatiauthentication 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.
Chapter 4
97
AuWindow umber of authentication protocols, primarily Kerberos and NT LAunc n
thenticating in Windows 2000 s 2000 (Win2K) uses a n
N Manager (NTLM). Kerberos is a new protocol for Microsoft, and NTLM remains ha ged 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 supportsthe 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 Kerberos and NTLM. Message Block (SMB)/Common Internet File System (CIFS) network share access, network printer access, authenticated Remote Procedure Calls (RPCs), and Active Directory (AD) access 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.
In this hope you h use i y
Us g
. . . it is known to have had three heads . . .
In earli y propagexploit lt protoco ntity propagation.
Ori a na, Kerberserver identityeasily c
Installi ainless; 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.
1: The authentication protocols used in Win2K.
chapter, I’ll look at each of these authentication protocols. When I’m finished, I ’ll ave gained an in-depth understanding of them and are better prepared to maximize theirn our Win2K infrastructure.
in Kerberos V5: The New Authentication Scheme Kerberos; also spelled Cerberus. n. The watchdog of Hades, whose duty it was to guard the entrance—against whom or what does not clearly appear;
—Ambrose Bierce, The Enlarged Devil’s Dictionary
er versions of NT, NTLM was the default protocol for network authentication and identitation. Unfortunately for Microsoft, NTLM was also the vehicle for a number of hacker s against these versions of NT. As a result, Win2K has adopted Kerberos V5 as its defaul for network authentication and ide
gin lly created at the Massachusetts Institute of Technology (MIT) as part of Project Atheos was designed on the assumption that initial communications between a client and a would take place on an unsecured network. Thus, the protocol ensures that it can prove the of both client and server without passing credentials “in the clear” or in a format that is ompromised (like initial versions of NTLM).
ng Kerberos in your environment is pretty p
Chapter 4
98
As an authentication protocol, Kerberos provides a way for two entities to mutually authenticate
s a
tion c
es It Work” later in this chapter.)
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. Anetwork authentication protocol, Kerberos uses symmetric key cryptography to provide strong, mutual authentication between two entities on a network. As I said above, mutual authenticais established before the parties use their network connection. (For more details on symmetrikey cryptography, see “What Mak
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, I’ll 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.
Pub klic- ey 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 publickey–enc xt rypted message from someone else, that person uses your public key and encrypts the plainteinto ciph f the relationship between a public/private–key pair, anything encrypted with ertext. Because oone key can only with the other key. As a result, the only person who can decrypt a be decrypted messag you e sent to you with your public key is you (assuming that you kept your private key private likewere 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 don’t really use keys, and they can take a message of any arbitrary e length and produce a short, fixed-length, unique numerical value. Hash functions have sompretty unique properties, and they show that it’s computationally not feasible to find messages that will hash to y the same numerical value. Typically, hash functions are used to do things like protect the integritof a message. Two of the most well-known hash functions are MD5 and SHA-1. Win2K can use both of these fu nctions to ensure that, among other things, secure e-mail messages haven’t been tampered withand that IPSec network packets haven’t been modified in transit.
For thofor a siWin2K -based, on can provide a number of cost benefits to you and your organization.
ser 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
se of you who run a heterogeneous environment, Kerberos can also act as the foundation ngle sign-on solution. The full integration of the Kerberos authentication model into and its domain structure has led Microsoft to create the logical beginnings of a standardsheterogeneous, single sign-on environment that is structured around Win2K. Single sign-
• It reduces the time it takes for users to sign on and reduces the number of failed sign-onattempts that occur because of u
Chapter 4
99
• It improves security by reducing the number of user name/password combinations that users need to remember
It improves security by enhancing an administrator’s ability to maintain the integrity of user-account configurations.
•
If y all of t ehosts, yintegra(Discuschapter d this capability, check out the Win2K Technical Resources on
our organization is currently running a homogeneous NT environment, you already reap hes single sign-on benefits. For organizations with a healthy mix of Windows and UNIX
ou now have a network authentication solution in Kerberos that can allow you to te your UNIX and Win2K environments and provide single sign-on between them. sing how to achieve this seamless interoperability is well beyond the scope of this . For those of you who nee
Microsoft’s 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 wita major overhaul. More specifically, compared to NTLM, Kerberos provides the following
hout
nt
clients can obtain credentials for a server once per logon m, then reuse them as needed for subsequent logon attempts.
n,
o pability to use a
a
ows for a
st each
end ructures.
ials rs
u can create a single sign-on environment across your entire infrastructure, as I discussed above.
benefits to you and your organization:
• Better performance—Servers using NTLM must validate every access to a resource against a domain controller. On the other hand, Kerberos servers can authenticate a cliedirectly by verifying its presented credentials; it doesn’t have to consult a domain controller. In addition, Kerberossession, cache the
• Mutual authentication—NTLM provides only single-entity authentication, where theservers authenticate the clients. Kerberos, on the other hand, uses mutual authenticatiothereby allowing both parties to authenticate each other.
• More robust authentication delegation—NTLM and Kerberos both allow a service timpersonate a client on the local computer. Kerberos has the additional caproxy mechanism to allow a service to impersonate a client when it communicates with service on another computer.
• Two-way, transitive trust—As I discussed in Chapter 2, Win2K domains use Kerberostrust relationships that are two-way and transitive. Remember that this allsimplified domain-trust model, in which all domains in a forest automatically truother. 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 contwith in our NT 4.0 infrast
• Interoperability—Although 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 credentto be used across a multitude of platforms and can reduce the number of times your usesign on. In the best of cases, yo
Chapter 4
High-Level Overview Before going into all of the intricacies of the Kerberos protocol and concepts, I want to give youa high-level look at Kerberos and grounding in how it works. As Figure 4.1 shows, the Kerprotocol 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 dom
beros
ain. These secret keys are shared between the KDC and each of these users and services to prove their identities.
ain
beros
dentity. If the information matches, the logon
s it
shared between you and the KDC and is encrypted with your secret key.
4. Now it’s 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,”
e network resource’s secret key and contains, t, the Kerberos client
on
5.
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, I’ll present a high-level look at what happens when you log on to a Win2K domand 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. Kertakes 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 iinformation that you supplied is correct, and you’re now authenticated.
3. The client computer automatically requests a ticket-granting ticket (TGT) for you. This ticket proves that you’ve successfully authenticated to the domain, and it’s used in subsequent communications with the KDC to prove your authentic identity. I’ll discusthe TGT later in this chapter (see “Ticket-Granting Tickets”), so for now, I’ll say thatcontains a key
but suffice to say that it’s encrypted with thamongst other things, a session key.) To obtain a session tickesubmits your TGT as proof that an authentic security principal is requesting this sessiticket.
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
101
6. Kerberos uses the session key returned from the KDC to create an authenticator, whichwill 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; I’ll talk more about it later (see “Authenticators Provide Mutual Authentication”). The authenticator and KDC-encrypted session ticket are then submitted to the network resource for access.
The network res
7. ource uses the secret key that it shares with the KDC to decrypt the network
h
One of have tohandled transparently by the protocol when the session ticket is encrypted by the KDC with the secret kticket, iportion
The othyou have a session ticket to access a network resource, Kerberos caches it for future use. The next timagain. EStep 4
What MNow thKerberpredica because if only two parties know a secThe co
For exaadditioreceivesecret w
The shwhenevpasswoinclude
While party in tween parties A and B. Herein
session ticket. This reveals the session key, which is shared between you and theresource. In turn, the resource uses the session key to decrypt and validate the authenticator. You’re now successfully authenticated to the network resource for whicyou’ve requested access.
the first things to note about the Kerberos protocol is that the network resource doesn’t go to the domain controller to validate the client’s credentials. Instead, validation is
ey it shares with the network resource. When the network resource validates the session t knows that the KDC has vouched for your identity. This process accounts for a big of the performance advantage that Kerberos has over the NTLM protocol.
er portion of the performance advantage of Kerberos is accounted for by caching. Once
e you try to access the network resource, Kerberos only has to execute steps 5 and 6 ventually, however, your session ticket will expire, and Kerberos will need to execute
again to obtain a new one.
akes It Work at you have an idea of how the Kerberos protocol functions, I’ll describe what makes os work and what core concepts are rolled into these functions. First off, Kerberos is ted on the use of shared secrets. This works well
ret, either one of them can authenticate the other one by verifying that it knows the secret. ncept is simple, and it works really well for secrets shared by two parties.
mple, let’s suppose that two parties, A and B, want to communicate with each other. In n, Party B wants to be 100 percent sure that it’s communicating with Party A whenever it s a message from it. To do this, parties A and B can agree on a secret and not share this ith anyone else; I’ll say that they use something simple like a password.
ared secret can be effective only if Party A can prove that it knows the password er it sends a message to Party B. A simple way to do this is for Party A to include the rd in its message. When Party B reads the message, it verifies that the password is d as part of the message.
this might work in some situations, it doesn’t take into account the possibility of a third tercepting the message and stealing the secret shared be
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 otherparty that might be snooping around.
Chapter 4
How do you prove you know something without revealing it? A popular way to solve this
l. ts are:
. If
ways
e because ed
t on a shared secret key can authenticate each other without either party having to reveal the actual
sho
problem, and the way Kerberos solves it, is by using symmetric key cryptography. Symmetrickey cryptography allows parties A and B to share a single cryptographic key and use it to authenticate each other’s 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 itknows 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 protocoKerberos builds on this using a few key concepts that make Kerberos work. These concep
• 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 informationauthenticators didn’t use different information, an eavesdropper could reuse any captured authenticator to impersonate the authenticator’s real identity. For example, if you were to aluse 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 isn’t desirablany captured authenticators that were replayed by an eavesdropper couldn’t be differentiatfrom 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, let’s walk through a simple example. Going back to parties A and B, let’s see how their agreemen
secret and thus protecting the shared secret from being stolen by any eavesdroppers. This iswn 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
103
1. Party A sends a message to Party B that consists of two parts: the actual message and anauthenticator. The authenticator consists of two pieces of information encrypted wishared secret key. For the purpose of our example and one that relates to how Kerberos iimplemented, let’s 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
th the
s
must verify them. It first verifies that the unencrypted name in the authenticator matches the name of Party A. If the names don’t match, the message mustn’t have been encrypted with the correct shared secret, and hence the party couldn’t possibly be Party A, as it’s claiming to be.
Party B then validates the time contained in the authenticator—for 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. Let’s 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
our
he e
an 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,
ved.
al
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
iginal authenticator reached a party that decrypt the authenticator and extract the time
n
five-minute window? It means that the authenticator was constructed by Party A, but it doesn’t necessarily prove that it was sent from Party A. Consider the possibility thateavesdropper 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, ttime contained in the last authenticator it received. Now, if the time retrieved from thauthenticator is later th
single-entity authentication has been achie
3. Now Party A needs to authenticate the identity of Party B. Party B takes just the origintime 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 wouldn’t 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.
validating the times, Party A knows that its orknows the shared secret key required to value from it. Because Party A shares this secret key only with Party B, it must have beeParty B that received the original message and replied.
Chapter 4
104
This simple protocol shows how using a shared secret key can allow two parties to mutually authenticate each other. It’s a concept crucial to understanding how Kerberos works.
Distributing Keys—the Issues
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 let’s consider the reality that parties A and B aren’t 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?
ginning of this section may have
hird
s ’ll use the term domain to remain consistent with the Win2K nomenclature.
I’ll discuss what the KDC does in detail later in this chapter (see “Understanding the Key Distribution Center”), but for now, I’ll 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 key—the key it shares with the KDC.
If all you ever have to do is keep track of a shared secret key with one other party, it’s 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,
Those of you who read the definition of Kerberos at the bewondered 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 theproblem 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 tparty 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 Kerberorealm, I
This key is often referred to as a long-term key because it changes only infrequently. For user accounts, it’s typically derived from the user’s password. For non-user accounts, it’s typically generated when the account is added to the KDC, and it’s maintained automatically.
Chapter 4
How do we go from sharing a secret key with only the KDC to sharing a secret with everyone else com ugenera KDC d it shares another cop gure 4.3.
in the domain? The answer lies in using a short-term session key. Before a client can m nicate with a server, it sends a request to the KDC, announcing its intentions. The KDC
tes a unique session key that the client and server will use to authenticate each other. Theistributes this key to the client by encrypting the session key with the long-term key that with the client. The KDC then distributes this key to the server by encrypting
y of the session key with the long-term key that it shares with the server as shown in Fi
Figure 4.3: The theoretical scheme for distributing keys.
Second, if the client was able to communicate
ys Using Session Tickets
ssion 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.
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 aroundwhile 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. with the server before the server received the session key from the KDC, the connection wouldn’t 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 KeKerberos 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 it’s the inclusion ofthe server’s copy of the encrypted session key that makes the se
105
Chapter 4
Figure 4.4: Using a session ticket to distribute keys.
rack of all of these session keys.
per happens to get hold of one session key is the client, and the only entity thatof t s
authenticator is bundled
C.
Using this scheme, no one other than the client needs to keep tAll that the KDC needs to do is generate session keys, create tickets, and send them to the clients. It doesn’t need to keep track of anything else. If an eavesdrop
of these replies, it can’t do anything nefarious with it. The only entity that can recover the can decrypt the ticket and recover the other copy
he ession key is the server. Using a session ticket is actually quite ingenious, and it keeps theprotocol 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 MutualAuthentication”), contains the client’s name and the current time. Thewith 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 KD
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
ypt the , the
the client’s authenticator, as I described
above.
long-term shared secret that it shares with the KDC to decrypt the session ticket. In the sessionticket, the server finds its copy of the session key. It then uses the session key to decrclient’s authenticator. If everything decrypts correctly and all of the information is validatedserver 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 thesession key to encrypt the time value it received in
106
Chapter 4
107
Using session tickets has two m
• The server doesn’t need to keep track of session keys—It’s the client’s responsibilitto keep track of session tickets and the shared secret between the client and server. Tonly key that the server needs to keep track of is the long-term secret key
ain advantages:
y he
it shares with the KDC. When the server is done using a session key, it can just discard it.
ed to consult the KDC every time it accesses the server—reates a
UsUp t erived from his or her pas o c key by running it through som s e long-term secret
While the KDC could retrieve a client’s long-term key for each communication session between only once: when the client initially authenticates to the ich uses the long-term key derived from the client’s
n ticket in that it contains a copy of a session key that it uses to it
ts to ac ess, 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
y client access.
• The client doesn’t neSession tickets are cached on the client and can be reused. As long as the client cnew 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.)
ing Ticket-Granting Tickets to his point, I’ve talked about how a user’s long-term secret is dsw rd. Typically, a user password is converted to a cryptographie ort of one-way hashing function. The resulting cryptographic key is th
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.
a client and the KDC, it actually happensKDC. After the initial authentication, whpassword, 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 sessiocommunicate with the KDC. Obviously, the client also receives a copy of the session key thatwill use. But what keys are used to encrypt the client’s copy of the session key and the TGT itself? The client’s copy of the session key is encrypted with the user’s 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 it’s used just like any other ticket. If a client doesn’t have a cached copy of a session ticket for a service that it wan
c
up the client’s long-term key for each and ever
Chapter 4
108
Understanding the Key Distribution Center e
C provides two services for Kerberos:
rforms initial client authentications and issues TGTs
al use 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 it’s 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
ussing AD. That’s 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 it’s not the actual password, access to this attribute of an account object must be limited appropriately to ensure that it isn’t 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.
As I’ve discussed, Kerberos includes three main components: the client, the server, and thKDC. Of these, the KDC is the key to the success of the Kerberos protocol. It’s actually composed of more than what I’ve discussed so far—three 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 KD
• Authentication Service (AS)—Pe
• Ticket-Granting Service (TGS)—Issues session tickets for access to domain resources.
While I’ve mentioned it before, it’s 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 LocSecurity Authority. (For a review of the LSA, see Chapter 2.) Beca
components of Kerberos in Win2K without disc
Chapter 4
109
For those of you familiar with other Kerberos implementations, the Win2K implementation doesn’t 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, I’ve touched on most of the characteristics of the Kerberos protocol. The
y
ese
o context, I’ll 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.
e form or another so far, so I’ll move quickly through it.
T e Kerberos client then begins AS Exchange by sending a Kerberos Authentication Service Request (KRB_AS_REQ) message to the KDC’s authentication service, as shown below in
s you, the user, and the name of the service to
discussion started at a high level, and I’ve been working steadily down to some of the nitty-grittdetails. In this section, I’ll describe how Kerberos works in a domain environment by discussing the three sub-protocols that make up the overall Kerberos network authentication protocol. Ththree sub-protocols are:
• AS Exchange—Used between a client logon and the KDC to retrieve a TGT
• TGS Exchange—Retrieves a session ticket from the KDC
• Client/Server (CS) Exchange—Authenticates a client to a service.
To put these sub-protocols int
I’ve discussed all of this in on
Authentication Service Exchange It all begins when you log into the domain and enter your user name and password. The Kerberosclient 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 computer’s credentials cache in the LSA for later use.
h
Figure 4.6. The first part of the request identifiewhich you’re requesting access. In this case, you’re 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 computer’s credentials cache.
Figure 4.6: Sending messages using AS Exchange.
Chapter 4
When the KDC receives the KRB_AS_REQ message, it retrieves its copy of your long-term kefrom 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 pass
y
word correctly.
he , the
n e
for your TGT. In addition to the logon session key, the KDC places other information about you, such as your
ce the TGT is fully populated, the KDC encrypts the TGT
ly
ypt
t
ge
.
The KDC now goes about creating the set of credentials that your Kerberos client will use for trest of your logon session. To build these credentials, which will give you access to the TGSKDC generates a random, unique logon session key for you. First, it encrypts this logon sessiokey with its copy of your long-term key, then deletes its copy of your logon session key becausit won’t need it again.
Then the KDC uses a second copy of the logon session key as the basis
authorization data, in the TGT. Onwith 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 Rep(KRB_AS_REP) message.
When your client workstation receives the KRB_AS_REP message, it places the TGT directlyinto the credentials cache. It once again uses the cached copy of your long-term key to decrthe logon session key that was returned. The logon session key is also inserted into the credentials cache of your workstation. You’re now authenticated to the domain and ready to staraccessing network resources.
Ticket-Granting Service ExchanOnce you’re 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.7This 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
d with
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 you’re 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 you’re 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
ure 4.8.) This request contains the rvice session key, and a
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 you’re trying to access. Much like before, this session key is first encrypteyour 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.
network service that you want to access. (This is shown in Figsession ticket for the service, an authenticator encrypted with the sesimple flag that indicates whether the client wants mutual authentication to be performed. Let’s assume that we’re requesting mutual authentication.
.8: Sending messages using C/S Exchange. Figure 4
Wh tto decr racts both yodecrypt your supplied authenticator. If the authenticator is within the allowed tolerance, the remote computer considers you authenticated.
en he remote computer receives the KRB_AP_REQ message, it uses its long-term secret key ypt the service session ticket. From the service session key, the remote computer extur authorization information and the service session key. It uses the service session key to
111
Chapter 4
112
Because we assumed that the mutual authentication flag was set within the request, the remote ved within your authenticator to provide
r
e
st of the connection, the service session key can be used to encrypt the application data passed between the client and the server.
the c r c key for this purpose.
Inter-Domain Authenticationing I’ve ed about so f I’ll discuss er-domain authentication l process.
ork rce. The sa olds true fo s that reside in another domain. When you
access a ork service the same TGS e proto at I discuss ervice Exchange.”) When the
that y trying to a that ends with you talking to the ain.
In a Forest with Two DomaiThe best way to describe how th rough a simple example in which a Win2K
only two domains. Wh main tered as a security princ TGS in each treat GS of the o
request session tickets for the oth ss any other k resourc our domain
When you want to access a netwsending a TGS Exchange reques pecifying the network
e o domain. Whe trying to access isn’t a ser
referral ticket. This referral ticke in key, which your KDC shares with the KDC in the other domain.
wn domain and one for the other domain. Your
computer uses the session key to encrypt the time it receian authenticator of its own. The remote computer returns the remote server authenticator to youworkstation 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 threturned authenticator exactly matches the time stamp in the original authenticator, the client considers the remote service to be authenticated. During the re
Of course, lient and serve an share another
Everyth talk ar has concerned authentication in a domain. Now how int functions in a Win2K forest. It’s a simple referra
As for intra-domresou
ain access to a network resome h
urce, you need a ticket to access any netwr network service
want to netw in another domain, the process starts with Exchang col th ed above. (See “Ticket-Granting SKDC sees ou’re ccess a resource in another domain, it begins a referral process
TGS in the network resource’s account dom
ns is works is to walk th
forest has en these two domains were created, the TGS of each dowas regis ipal in the other domain’s KDC. This allows the domain to the T ther domain as just a generic service. As a result, you can
er domain’s TGS just as if you were trying to accenetwor e in y .
ork service in the other domain, your workstation starts by t to the TGS in your account domain, s
resource in thyou’r
ther en the TGS receives your request, it sees that the resource that vice in its domain. As a result, it sends you what is known as at is just another TGT that is encrypted with an inter-doma
Now you have two TGTs, one for your oworkstation 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 theinter-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.
Chapter 4
In a Forest with More Than Two Domains ess w ch the same in a Win2K forest with more than two domains;
e do
hree doand domains B and C are children of Domain A. (This is shown below in Figure 4.9.) You’re in
d you w
The referral proc orks pretty muit just takes more referrals! I’ll clarifexample uses thre
y how the process works using an example. While this mains, you can extrapolate it to n domains in the same fashion.
Let’s say that t mains—Domain A, Domain B, and Domain C— are all in a single tree,
Domain B, an ant to access a network resource in Domain C.
Figu cation.
The f A, and ends
t is encrypted with the inter-domain key that is shared
e
main to forward it to. There is only one place to send it—Domain C. So
e network resource, which your client can then use to
re 4.9: Using Kerberos referrals for inter-domain authenti
re erral path starts with the KDC in your Domain B, traverses a trust to Domain 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 KDCreceives your request, it sees that it’s for another domain and looks for the appropriatedomain to forward it to. There is only one place to send it—Domain A. So your client receives a TGT for Domain A thabetween domains A and B.
2. Your client sends a second TGS Exchange request to the KDC in Domain A. When thKDC receives your request, it sees that it’s for another domain and looks for the appropriate doyour 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 it’s for a network resource in its domain. It responds with a session ticket for thgive you access to the resource you want.
113
Chapter 4
114
Everything You Wanted to Know about Tickets In the last few sections, I’ve discussed the notion of tickets, both TGTs and session tickets. As you’ll 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 you’ll notice is that only part of the ticket is actually encrypted. So far, I’ve 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-vKerberos V5, so this value is always set to 5.
no No The version number of the ticket format. Win2K implements
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 ofin the session ticket.
it
Starttime Yes A time stamp that indicates when the ticket becomes valid. Endtime Yes A time stamp that indicates when the ticket expires. re ew-till Yes A time stamp that indicates the maximum expiration time for a ticket
that has its RENEWABLE flag set. An optional value. n
Caddr Yes Thvalue isn’t prese
e client addresses that are authorized to use this ticket. If the nt, the ticket isn’t restricted and can be used from
any network address. An optional value. Authorization-data
Yes Your account authorization values. For Win2K, this is a collection of security identifiers (SIDs) that represents your group memberships. I’ll 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 you’re 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.”)
Chapter 4
115
Thi ics T ket Flag Indicates This
FORWAal TGT. This flag is valid only for a TGT.
RDABLE The TGS can issue another TGT with different network addresses based on the origin
FORWA RDED One of two things: either the ticket has been forwarded, or it was issued from aforwarded TGT.
PROXIABLE The TGS can issue session tickets with a different network address than the one contained in the original TGT.
PROXY e ticket is different than the network The network address contained in thaddress.
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.
CalculTakingUsing r refresh session keys without having to go through all of the hupdated
•
• the cumulative lifespan of all incarnations of the ticket.
The waexpect.to the vsettings r renewa ndtime field; after that time has passed, the ticket cannot be renewed, and a new one must be issued.
for renewal, the KDC validates both the Endtime field and the
ld s 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 isn’t specified or if it occurs sometime in the past, the KDC defaults the value to the current time. Start times aren’t something you need to worry about, but it’s interesting to note that they can be used, even if it’s not often.
3: Overview of Kerberos ticket flags.
ating Their Lifespan a look at ticket fields and flags, you can see that renewing a ticket extends its lifespan. enewable tickets allows the KDC toassle of generating an entirely new ticket. But tickets flagged as renewable cannot be forever; they’re governed by the two expiration times that the KDC sets in the ticket.
Endtime—Limits the life of the current ticket
Renew-till—Limits
y in which Kerberos uses these ticket fields is pretty straightforward and much as you’d First, the value in the Endtime field is the result of adding the value in the Starttime field alue for Maximum Lifetime for [User|Service] Ticket specified in the Group Policy in effect for the domain. Any renewable ticket must be submitted to the KDC fol before the value in the E
When a ticket is submitted Renew-till field to ensure that neither value has passed. If the Renew-till time hasn’t 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 oand expire. Not only that, it also ha
Chapter 4
The expiration time is a little more involved, so let’s 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
riate Group the Starttime value of the ticket. The result is ex is
chosen and becomes the ticket’s E
ns whe
ck r the resource.
specified in the approp Policy setting, to then compared to the requested piration time of the ticket. As you’d expect, the earlier time
ndtime value.
Now let’s look at what happehas expired when it tries to use th
en a ticket expires. The client finds out that a session ticket ticket to access a network resource. The resource returns an
error, and the client has to go ba to the KDC and request a new session ticket fo
The ticket is validated only when you a new connection is established with the network resource. If connect to a resource with a valid ticket, even if the ticket expires one second later, the connection remains viable until it’s 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 long-
ple, you as a client may want to access a server to gain access to some
nd server to know that it is you who is logically accessing the resource, eve hbelow i
term key cached, it can automatically receive your new TGT; otherwise, the client is forced toonce 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 examresource, 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 seco
n t ough it’s the first server that is physically accessing the service. This scenario is shown n Figure 4.10.
.10: Delegating authentication. Figure 4
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
117
To delegate authentication, Kerberos can use one of two methods.
• Proxy tickets—You 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 tickets—Create 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
sues a session ticket with the FORWARDED flag set.
ocol works. Overall, Ker roptions
because the FORWARDABLE flag is set, and it is
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 prot
be os requires very little “care and feeding,” and Table 4.4 below recaps the configuration available in Group Policy.
Chapter 4
118
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 The maximRenewal
um 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 Ke olicy.
uratio ey’re not really Objects Us), or
local GPOs. They’re available only omain. If you think akes se
services for the entire domain; ther ply only to the
-based coounts also nd
shown in Figure 4.11.
ion—It should never be required of an individual user
d individual users by selecting this check
box. The default behavior for a Win2K KDC is to require that all accounts use pre-
ith other implementations of the Kerberos protocol, you may need to select this check box. However, just about all of the
rberos in Group P
While these Kerberos config n options are available in Group Policy, thavailable in Group Policy (GPOs) that are linked to sites, Organizational Units (O
from GPOs that are associated with the dabout this for a second, it m nse. The function of the KDC is to provide authentication
efore, the configuration options should apentire domain.
In addition to these GPOwith individual user acc
nfiguration options, three configuration options associated affect how Kerberos operates. These are described below a
• Account Is Trusted for Delegataccount, 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 checkbox.
• Account Is Sensitive and Cannot Be Delegated—While Kerberos permits delegateauthentication, you can disable this capability for
authentication data.
• Do Not Require Kerberos Preauthentication—Not all versions of Kerberos support pre-authentication data, so for interoperability w
newer Kerberos implementations support pre-authentication data.
Chapter 4
Figure 4.11: Account configuration options that affect Kerberos.
• Allows users to log on to stand-alone Win2K computers—You cannot use Kerberos because it’s a network authentication protocol and not well suited for local logons
older versions of Windows— This feature allows native Windows 3.11, 9x, and NT 4.0 computers to authenticate to
enables Win2K computers to access resources in your legacy NT
Using NTLM: Down-Level Compatibility As I’ve shown, Kerberos is the default network authentication protocol for Win2K. But that doesn’t mean that NTLM is dead. In fact, NTLM has been retained in Win2K to provide some very necessary functionality. This is because NTLM:
• Allows backward compatibility between Win2K and
Win2K domains. It also4.0 domains.
119
Chapter 4
120
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 isn’t 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 down-level clients. Windows NT 4.0 computers earlier than SP4 don’t support NTLM v2, and Windows 9x and Windows Me computers don’t 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 you’ve upgraded your entire environment to Win2K. Unfortunately, it isn’t an option. However, if you successfully upgrade your entire environment to Win2K, it’s worth investing a little time to use an intrusion detection system to identify how LM-based authentication is used on your network.
Chapter 4
121
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 forperforming their administrative duties. This has long been touted as good security practice, but it’s been somewhat of a pain. To use two accounts, administrators are forced to eith
er log in and selves up with two computers. Unfortunately, the
dministrators to always react quickly to administrative needs has led
For ma y out of t uch a command hasn’t been available in the Windows faSec d ount to l o without the need for a second computer or th
You cabout this command whe is chapter, Runas is such an exc g
andsimply, it allows you to run another tool or program as any another user.
In W nTo star , hold down the Shift key and right-click the icon ppears on the shortcut menu, a se the Run As command, a dialog box appears, where y on for the user for whom you want to run the tool or application.
out of their two accounts all day or set themdemands placed on system amany, if not most, of you to forgo two accounts and use just one to perform all of your job functions—the privileged account!
ny of you who are familiar with UNIX, the su command probably sounds like the wahis sort of situation. Up to now, however, s
mily of products. Thankfully, Win2K finally provides a service known as the on ary Logon Service (SLS). It allows administrators to use a normal non-privileged accog n as well as a privileged account for running administrative tasks when necessary
e need to log off and log back on.
a cess the SLS using the Runas (runas.exe) command. While it might make sense to talk n discussing authentication tools later in th
itin and long-overdue component that it deserves a section all to itself.
While I’ve 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
programs with a different set of permissions than their current logon provides. Put more
Starting the Runas CommandWin2K gives you two ways to start the Runas command: in Windows Explorer and on the command line. Let’s take a quick look at these methods.
i dows Explorer t the Runas command in Windows Explorer
for an administrative tool or application. The Run As command as shown in Figure 4.12. When you chooou can type the authentication informati
Chapter 4
Figure 4.12: Choosing the Run As command from the shortcut menu.
e shown in Figure 4.13 and described in the next sec n
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; they’rtio .
Figure 4.13: Starting the Runas command from the command line.
122
Chapter 4
123
In this figure, note the title bar of the console window. You’d expect to see the title ctually cmd (running as merion\administrator). That’s
ork environment, not the new user’s local environment
,
C:\WINNT\System32\cmd.exe, but it’s abecause when you start cmd.exe from Runas, you get a visual cue that you’re running under another security context. Unfortunately, this visual cue occurs only when you execute cmd.exewith 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 command’s syntax and options.
runas[/profile][/env][/netonly]/user:UserAccountName program
• /profile—Load the new user’s profile
• /env—Use the current netw
• /netonly—Use the user for remote access only, not for local access to resources
• /user:UserAccountName—Specifies the user account under which to run the programusing the format user@domain or domain\user/
• program—The 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, you’re 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 advantageof the R
unas command:
• Although it’s commonly used to run commands as an administrator, you can use it to run
• 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
a program in the context of any other user
Chapter 4
124
• You still need to use the appropriate user account name and password information; it doesn’t give you a magical ability to circumvent user authentication
• You can use it to administer resources in other domains and even forests (if you’re awayfrom your normal computer, this is a pretty cool feature)!
• Because you can’t open things like Windows Explorer, the Printers folder, Desktop items, and so on directly in Win2K, you can’t use Runas to start them
• If Runas fails and you kn
ow you entered the user name and password correctly, check that the RunAs Service is actually running and that the account isn’t locked out.
nts while running as a m
Using Smart Card Authentication Ano e all hear hat have se rity perspec istics that, together, offer an attractive security solution. These three ch
•
• ensitive computations from other parts of the system that have no
•
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
ailable when the specification was created.
smart card–aware applications. The specification also allows complete integration with the OS.
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 it’s available, no system administrators in your environment should ever again read their mail and compose simple docume
ember of the Domain Administrators group!
th r of the features built into Win2K is its embedded support for smart cards. While we’ved of smart cards and some of us may even have used one, what is it about smart cards tcurity professionals all excited? Well, smart card technology is attractive from a secutive because it provides three character
aracteristics are:
Tamper-resistant storage—Smart cards protect users’ private keys and other forms of personal information, including passwords
Isolation of security-sneed to know—These computations include authentication, digital signatures, and keyexchange operations
Portability of authentication credentials and other private information among multiple systems—Uses a small and convenient form factor familiar to most people.
problems with the myriad of “standards” that were avThe specification provides a standard model for interfacing smart card readers and cards with computers and with device-independent application programming interfaces (APIs) to enable
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
hen you log on to the domain, a private/public–key pair
blic
orkstation. If the smart card reader is properly installed, inserting the smart card triggers the Secure Attention Sequence. (This is akin
n, Win2K launches the MSGINA plays the Authentication dialog box
Kerberos protocol’s AS Exchange. Wthat 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 pukey from your user object in AD.
To give you a better idea of how smart card logon functions, I’ll 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 w
to pressing CTRL+ALT+DEL.) Just like with a regular logo(see Chapter 2 for a description of the MSGINA), which disthat requests just a single piece of information—the 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 you’d 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 arestored.
All operations that require the private key material occur in the smart card itself.
125
Chapter 4
126
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 it’s 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, you’ve 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 haven’t 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,
this.
• A full smart card implementation can be quite complex. As with all rollouts, I urge you to Make sure you understand how to use smart cards not only for
associated certificates
hat any smart cards you deploy have enough space to hold foresee over their expected lifetime.
Us gOther authentication schem etric authentication and IIS.
B metric Authentication When I was discussing all of the authentication protocols available in Win2K earlier in this
0”), you may have noticed that I didn’t list
maybe even by the time you read
test, test, and test again. authentication but also for all of the administration endeavors that ensure that a rollout issuccessful.
• 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 canquickly fill up a small 8-kilobyte (K) smart card once the keys and are installed in it. Make sure tall of the user credentials you
in Other Authentication Schemes es that I’ll touch on very briefly are biom
io
chapter (see “Authenticating in Windows 200biometric authentication in Table 4.1. This is because biometric authentication isn’t really supported natively by Win2K. This fact notwithstanding, biometric authentication may be something that you’re extremely interested in, so I thought it important to at least mention it.
Chapter 4
127
However, mention it is all I’m going to do because I’m not a very big believer in biometric access to
you gy is
n 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, I’ve spent a lot of time talking about Kerberos and, to a lesser extent, NTLM, smart cards, and secondary authentication. In this section, I’m 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, they’re all relatively specific to IIS. As a result, I’m going to defer discussing them until Chapter 10, where I’ll explore IIS from a security perspective.
Unlike other aspects of security configuration, when it comes to tuning the performance of either Kerberos or NTLM, there just aren’t a lot of options. Kerberos is fully integrated into the Win2K domain model and doesn’t 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 won’t ever really use Kerberos directly, it’s sometimes useful to keep an eye on all of the tickets that you’ve been granted. Aren’t 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, you’ll 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 you’ve obtained since you logged on (see Figure 4.15). While you can use this dialog box to purge all of your acquired tickets, you’ll 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.
authentication on the desktop. While I think it’s very beneficial for things like physical a data center environment, it’s 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 ofmay swear by them, but I’m not ready to embrace the technology just yet. Until the technoloeasier to use, easier to manage, and cheaper to deploy, all the while being implemented i
Authentication Tools and Troubleshooting
Chapter 4
l. Figure 4.15: Using the Kerberos Ticket Too
ork Dohile Win2K sna
ice to use a s line uti , or net uch a to
manage the W atool is pretty darn handy and lets you d ample:
Join a ain
• Manage computer accounts
Establish trust relationships am
• Verify and reset secure-channe
• Manage the trust relationships
Netw main Manager has plenty of MMCW p-ins where you can work, but every once in a while, it’s
lity to get something done. The Network Domain Managerol. (It’s shown below in Figure 4.16.) NDM lets you in trust relationships in your environment. Overall, the o a number of things, for ex
n imple command-dom.exe) is just sin2K domains and dom
(NDM
• computer to a dom
• ong domains
l relationships
among your domains.
128
Chapter 4
Figure 4
For those of you who’d rather use a gAct are pro
DomaYou GUI fans will like Domain Monitor (dommon.exe). To a certain extent, it’s a GUI implementation of the command-line Network Domain Monitor, minus some functionality. The
or keeps track of the domain controllers and their secure-channel status for
.16: Using the Network Domain Manager.
raphical user interface (GUI) to carry out these tasks, the ive Directory Users and Computers and Active Directory Domains and Trusts MMC snap-ins
bably the tools you’ll use.
in Monitor
Domain Monitdomains in your environment. It displays the domains that you’ve 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
130
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 Client’s name not foun 0x07
(principal unknown) Server’s name not found (principal unknown)
The account for the principal may have expired. Or the account exists in AD but hasn’t 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 controller–replication problems in your environment.
d The domain controller cannot find the specified name in AD.
0x17 Password has expired. A user’s password has expired and has been chaChange password to
nged, but it still has a valid TGT cached. Logging off, then logging on
problem. reset again will clear up this0x1A Requested server and A server receives a tic
ticket do not match This error typically indicates that there are problems in yoname-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.
ket that was issued to another server. ur
0x1F
Integrity check on decrypted field failed
There is an integrity issue with a decrypted ticket field or data stream. While the pr
0x29
Message stream modified
“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.
oblem may be a result of simple network
0x20 Ticket has expired A ticket has expired. Because it should renew automatically, there isn’t really anything to do besides notice that these
es are in your logs. messag0x22 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.
0x2 An authenticator has a time stamp that is different than the server’s 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.
5 Clock skew too great
Tab . le 4.6: Typical Kerberos error codes
Chapter 4
131
Authentication Best Practices Microsoft doesn’t 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
ind.
f
The Kerberos defaults are geared to a pretty typical office ou work five days a week and eight hours a day. If this is the
them—and the toughest issue of them all—what to do when a user
al is
apter has taken a lot of the mystery out of the I’ve accomplished what I set out to do.
are a few authentication best practices to keep in m
• Use a homogeneous Win2K environment—The best thing you can do for your authentication environment is get rid of all legacy clients and standardize on Kerberos. Iyou need legacy clients, do everything you can to set the LM authentication setting to Send NTLMv2 Response Only\Refuse LM & NTLM.
• Use the Runas command—The secondary authentication capabilities of Win2K are a great thing from a security perspective.
• Use multiple accounts—Now 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 defaults—environment, one in which yenvironment you have, the default Kerberos settings are probably just fine for you.
• Smart cards—The support for smart cards in Win2K isn’t perfect, but it’s available and may be worth a look. Even if you’re 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 comes to work one day without it!
Summary Remember that authentication provides the ability to positively prove that a security principwho 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, I’ve spent a great deal of time discussing it and the mechanisms that make it work. Hopefully this chKerberos protocol for you. If it has,
Chapter 5
132
Chapter 5: Configuring Access Control
at
trol decisions. The word unauthorized also implies that if you haven’t explicitly been granted access to some
control? Not entirely. Obviously, a third piece in
tion in
The Windows 2000 Access Control Model Before delving in, I want to point out that Win2K’s access control model isn’t 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 they’re necessary?
If you answered no to any of these questions, read on; by the time you’ve finished this chapter, you should know the answer to these and many other questions. In addition, you’ll have a thorough understanding of how Win2K uses both authorization and access control. Even if you
urage you to read on because I’ll provide the answers to many more questions about the Win2K access control model.
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 accesscontrol has no real function without the concept of authorization. Remember from Chapter 1 thauthorization gives a security principal the capability or privilege to perform an action or access an information resource. Thus, Win2K uses authorizations to make access con
resource, you’ll be denied access.
But is that all there is to the concept of access 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, I’ll spend a bit of time discussing authorizaWindows 2000 (Win2K). I’ll discuss authorization and access control together to create a complete description of how these two concepts collectively work within Win2K.
answered yes to all three questions, I enco
The Five Principles of Access Control To understand how Win2K performs access control, you’ll 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 Win2K’s 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.
Chapter 5
Figure 5.1: The access control model of Win2K.
In this chapter, I’ll 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.
U er-Based Authorizations user-based authorizations. Thus, applications
that run on your behalf run with the same set of permissions, authorizations, and privileges that
’re authorized to access. Access
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.
sThe access control model in Win2K begins with
you’ve been granted. As a result, these applications can do only what you’re 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 you’re authorized to access, and other users can access only the files on the system that theyto 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!
133
Chapter 5
134
Inheritance of Permissions the most powerful of Win2K’s access control model principles is inheritance of
ng
leges.
t r rights assignment, you’re correct; Win2K implements administrative privileges as user
u to
y administrators. Microsoft considers the
ever,
y, access control strives to answer the fairly simple question: “Can [security principal] perform [specified action] on [specified object]?” The question doesn’t seem so simple
change the question to read as Figure 5.2 shows: “Can Bob open the
Maybe permissions. When you create a new object, you can control the permissions on it by allowiinheritable 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. (I’ll 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 priviWin2K 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 system’s 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 lolike userights. (I’ll 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 Win2K’s access control model. It allows yomonitor for attempts to circumvent authorizations on resources in your environment and perform actions such as create an audit trail of actions taken bauditing of system events part of the access control model, and I agree. However, it’s really a topic unto itself. So although I’ll touch on auditing in this chapter when necessary, I’ll save the bulk of the discussion until Chapter 6, which I’ll devote entirely to auditing.
How Access Control Works The access control model describes the core principles behind Win2K’s access control; howmore important than understanding this model is understanding what access control really does. Quite simpl
in those terms, so let mefile?” The grammar of the two questions is the same, but the second one provides a more understandable context.
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 threadis actu
ally going to open the file for the process that is running on Bob’s behalf.
on
ur basic question is defined, let’s 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
proopeinte
As objwit that neither you nor Bob can physically reach in mputer and open a file on the hard drive; the
Figure 5.3. In the access token are Bob’s security identifier (SID) and a SID for every group that security descriptor is an access control list (ACL) that specifies
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 launchesyour behalf during your logon session receives a copy of this access token. As a result, Win2Kcan always look at the access token of a thread and know which security principal it’s running onbehalf 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 o
level of indirection between Bob and the action. When Bob takes an action such as using a cess to open a file, program instructions are executed that interact with Win2K to actually n the file. These program instructions use one of the standard application programming rfaces (APIs) provided by Win2K that were created just for this type of action.
a result of calling a system API to open a file, the action Bob wants to perform (open) and the ect he wants to perform the action on (a file) are both defined. If you’re not all that familiar h application programming, this description of events may seem a bit odd. But remember
to a coaction all happens on your behalf inside the code of the computer.
At this point, a thread running on Bob’s behalf has made a system call to open a specified file. Now it’s 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 validatingaccess rights throughout Win2K.
To perform the access control check to determine whether Bob can open the file, the SRM compares information stored in the thread’s access token (remember, it’s a copy of Bob’s access token) with the information stored in the file’s security descriptor. This process is shown in
he is a member of. In the file’swho is explicitly allowed or denied access to the file on a user and/or group basis.
135
Chapter 5
136
The R that app that exp access to the file, the SRM denies the thread access to the file. If the SRM find n find a membe
S M walks through the ACL of the file object looking for any access control entries (ACEs)ly directly to Bob or to any groups that Bob is a member of. If the SRM finds an ACElicitly denies
s a ACE that explicitly grants access to the file, it grants the thread access to the file. If its no explicit ACE that matches Bob’s SID or any of the group SIDs for groups that Bob is
r of, the SRM denies the thread access to the file.
Figure 5.3: The process of comparing access control.
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, I’ll walk through all the components that make up the access control implementation of Win2K. After I’m done, the example of how Bob opens a file should make complete sense to you.
This quick overview of access control gives
Chapter 5
137
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 they’re Win2K’s
y group is created, Win2K generates a unique SID to
r
through the SID for an account or security group created in one domain is
Not only are SIDs unique across your enterprise, they’re also kept unique for all time because the LSA never issues the sam ecycles a SID. For example, let’s 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 som quires you to regain access to this standalone Win old accconcernused to
SIDs vSo , globall e thing, aexplanation 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 object—its GUID.
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: they’re generated by the system, not by you or me; they’re unique; and they’re never reused.
Whenever a new account or securitassociate 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 system’s 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, it’s 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 osecurity group is unique to the domain in which it was created. This uniqueness is carried
your enterprise so that different than any of the SIDs in any other domains.
e SID twice and never r
ething else happens that re2K computer, so you create a new account. You then receive a new SID, guaranteed. Your
ount isn’t reassigned to you—or to anyone else, for that matter! As far as Win2K is ed, you’re two different security principals, even if your logon name is still the same as it
be.
ersus GUIDs far I’ve talked a lot about the uniqueness of a SID. If you recall from Chapter 3 what a
y unique identifier (GUID) is, it might seem to be the same thing. In a sense it is the samll in the name of backward compatibility. Of course, the details behind this simple
Chapter 5
138
As you’ll 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 num r , the stored ian obje
How v say aAmerichard wreplacedomain 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
keep in mind that when you move domains, you get a new
to
History attribute can hold multiple
be . The GUID lets any object be uniquely identified because once Win2K issues a GUIDGUID never changes, even when the object is renamed or moved. As a result, every object
n AD is assigned a GUID. So while other attributes can change throughout the lifetime of ct, the GUID always stays the same.
e er, the SID is one of those object attributes that can sometimes change. For example, let’s th t you work for a large international company that has Win2K domains for all of North
a and another Win2K domain for the Pacific Rim. After years of dedicated service and ork, you get your dream transfer from Smallville, USA, to Hong Kong. Instead of being d by an all-new account, your account can simply be moved from the NorthAmerica
in the next section, but for now, just SID.
After you have a new SID, you need a mechanism to access all the resources that you usedaccess 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-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 you’re 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, you’d 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 you’d ever want to do, so be safe and always use security groups for access control, not individual user accounts.
To summarize, I’ll relate all of this back to SIDs versus GUIDs. NT 4.0 and earlier use SIuniquely identify accounts and security groups, not GUIDs. So although SIDs seem to be a painbecause they can change over time, you shouldn’t 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, you’d be forced to modify all the ACLs on all the resources throughouyour 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, don’t expect Microsoft to make that mistake anytime soon
Ds to
t
.
Chapter 5
Where Win2K Uses SIDs Now that you’re becoming familiar with SIDs and recognize that I’ll be dealing with them for quite some time, you’re probably getting curious about all the places where SIDs are used. Maybe surprisingly, Win2K uses SIDs in only three major access control structures.
• Access tokens—Two 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
ery ACE to identify the accounts or security groups for e ie
cuss the deta ach of these structures in later sections of this chapter; for now, it’s to know w K uses SI
ucture o
of fields, a in Figure 5ining fields
member of.
• Security Descriptors—Two types of SIDs are used in a security descriptor: The first SID identifies an object’s owner, and the second SID identifies the owner’s primary security group affiliation.
• ACEs—A SID is used in evwhich acc
I’ll dis
ss is allowed, den
ils of e
d, or audited.
enough here Win2 Ds.
The Str f a SID As far as Win2K is concerned, a SID is a simple binary data structure that contains a variable number structure is, while the rem
s shown a
.4. The first field of the SID defines how large the contain the values that make up the SID.
Figure 5.4: The structure of a SID.
139
Chapter 5
140
Let’s take a quick look at each of these fields.
Subauthority Count—Indicates how many subauthority values are contained in the SID.
Revision—Indicates the version of the SID structure. Because the SID structure doesn’t changafter it’s created
e , the value is always 1.
Identifier Authority—Indicates the highest level of authority that can generate SIDs for the ipal. You should see only the values 0 through 5, where the valid authorities : null authority, world authority, local authority, creator authority, non-
n group
e,
. entifies a unique account or security group relative to the domain
(or local computer) and is known as the relative identifier (RID).
terprise because no two domains share the same domain identifier. An example of a
account or security
type of security princin ascending order areunique authority, and NT authority. For example, the SID for any account or security group iWin2K has an identifier authority value of 5 (NT authority), and the SID for the Everyonehas a value of 1 (world authority).
Subauthority fields—Contain the really important pieces of the SID. Each subauthority valuup to but not including the last value, identifies the domain from which the SID was issued or, if it’s 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 identifierThe last subauthority value id
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 it’s 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:
• S—The string is a SID.
• R—The revision level.
• X—The identifier authority value. 1 n-1• Y -Y —The 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 enwell-known domain identifier is the value 32, which Win2K uses for all the built-in groups such as Administrators, Power Users, and Users.
• Yn—The RID. Remember that this value is what distinguishes one 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.
Chapter 5
141
To better understand how a SID is typically represented in its string format, take a look at the
has
is a four-part value, and the RID has
IDs m again. Unfortunately, the situation
is ’t quite so simple for a Win2K domain infrastructure.
Because a Win2K domain can have several domain controllers, the ability to keep track of which re complicated. Remember that in Win2K, each
t domain controllers. When your requests is
me domain, with the same RID;
thus, there are two security groups with the exact same SID. What happened? Aren’t 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 controller’s instance of AD, the domain controller pulls a RID from its allocation of RIDs to construct the new object’s SID. As the domain controller uses up its allocation of RIDs, it has to request another block of values from the RID Master.
following two SIDs:
• S-1-5-32-549—This 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 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-515—The first three values of this SIDare the same as the one above. The domain identifiera value of 515. The value of the RID is fixed and will never be generated; it’s hard-coded and won’t be repeated. This is the well-known SID for the Domain Computers securitygroup. .
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 Rthat it’s used before and makes sure that it never uses the
n
RIDs have already been generated gets a bit modomain controller can accept requests to create a new account or security group, and each has a replica of AD.
Let’s 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 newsecurity group, but you do it on two differenprocessed, the domain controller does a quick search and decides that the new RID will have thevalue 42. At about the same time, the other administrator’s request is processed, and another domain controller also searches its copy of AD and sees that the value 42 has yet to be used anddecides to use it. Now there are two security groups, in the sa
Chapter 5
142
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 you’re probably already aware, a number of SIDs identify generic users and generic groups that don’t change. These constant SIDs are typically referred to as well-known SIDs, and they’re 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 sers and guests. u
S-1-3-0 Creator Owner A placeholdeinherited, this
r for an inheritable ACE. When the ACE is SID is replaced on the fly with the SID for the
object’s 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.
Chapter 5
143
One of the interesting things to note about these well-known SIDs is that some of them aren’t fully qualified and have a variable component. Two examples are the Domain Admins and
urity grou u e ou - duniversally recognized by Win2K systems, n d do t he seffective SIDs.
2K, there is on ne righ at is un rsally tccess to any resource you o This tr ce of DAC, as I
ss C rol” ea in this pter. A ugh DA kes sense, the basic is of wh right is r our purposes, a right is the
some operat If you ecall fr my initi discussio of accesion is an egral p f provi ing access control, so the concept of t. In Win2K, two types of access rights are impleme ted: acce
user rights.
ission is a specific right that g a secu principal the authorization to perform some ject. You can set p issions for ex
ings to r ze abo ermiss t ccess isn licitly a secu ty perspective, this arrangement is the way you
ork. Think what wou appen if the opposite was true, and access was automatically granted unless it was explicitly denied. You’d have to spend all your time
people from accessing the
a s
low from higher-level objects to lower-level objects. Inherited permissions ant that I’ll cover them later in this chapter (see “ACE Inheritance”).
issions inherited from a parent are protected by explicit permissions, and the inherited permissions aren’t applied.
O e last generic point: The granularity of authorizations has been greatly extended in Win2K to 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 isn’t just a single ACL for the entire object.
Domain Computers sec ps. Altho gh these sgroups i
curity grifferent
ps are wellmains won’
known an have t
ame
Access Rights When you look at Win ly o t th ive rue: The right to either allow or deny aexplained in “Discretionary Acce
thatont
wn. rlier
uth is the essen cha ltho C ma
I haven’t really addressed sue at a . Foauthorization to perform ion. ’ll r om al n s control in Win2K, authorizat
portan int art o d
access rights is very impermissions and
n ss
Access Permissions A perm ives rityoperation on an ob erm
eali on,ut p
ample, files, folders, and AD objects. i ns is thaOne of the more important th
granted, it’s automatically denied. (Fo if a ’ expt
rom riwant things to w ld h
modifying authorizations for your resources, trying to prevent certainresources 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. I’ll describe both ACEs and ACLs in detaillittle later in this chapter (see “ACLs”), but here, it’s important to link the concept of permissionwith the implementation of ACLs and ACEs.
Before talking in more detail about some of the different kinds of permissions, I want to talkbriefly about the three types of permissions you’ll encounter as you manipulate authorizations inWin2K:
• Inherited—Fare so import
• Explicit—Augment or replace inherited permissions on an object.
• Protected—Cannot be inherited by child objects; only explicit permissions exist. Child objects that have permissions that aren’t consistent with perm
ncover not only an object but also the attributes of an object.
Chapter 5
NTFS Permissions re are many advantages to using the NT File System (NTFS) over file systems based on the
-style File Allocation Table (FAT). For example, NTFS can track permissions and provide ership of files and folders. As a result, file and folder permissions are probably the most mon form of authorization that you’ll manipulate as you work with Win2K. You’re probably
Theoldowncomalready familiar with managing file and folder permissions in NT, and you won’t find things a
.
rk l
t if you understand how permissions work on local folders and files, you’ll 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.
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 accessedOn 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 netwoare subject to the assigned NTFS permissions as well as any share-level permissions. Share-levepermissions are important, bu
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 nhandles 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 dia
ow
log 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 isn’t all that intuitive is how the advanced permissions map to the basic file permissions that you’ll typically manipulate. The mapping between these two sets of permissions is shown in Table 5.2.
145
Chapter 5
146
Advanced Permission EnablesBasic Full Control Permiss
Enables Basic Modify Permission
EnablesBasic Read & Execute Permiss
Enables Basic List Folder Contents Permissio
Enables Basic Read Permission
EnablsBasic Write Permission
ion ion n
Traverse Folder / Execute File List Folder / Read Data Read Attributes Read Extended Attributes C ate Files / Write Data re
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.
object’s owner a number of times so far, but I haven’t really
set permissions on NTFS objects, you can also set permissions on objects in AD.
I’ve touched on the concept of an talked about object ownership. Just like every other object, folders and files must have an owner, and by default, it’s 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 TakeOwnership, which grants authorization on a folder or file. If you’ve been granted the Take Ownership permission on another user’s NTFS resource, you can take ownership of it from theAdvanced Permissions dialog box using the Owner tab.
AD Permissions Just as you canYou 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.
Chapter 5
Figure 5.7: The basic AD permissions dialog box for a user object.
When you administer AD, yo Directory u’ll often use the Microsoft Management Console (MMC) ActiveUsers and Computers snap-in. If you find perties of an object, the Security that when you view the protab isn’t present, you’ll need e is to make a quick configuration change to the snap-in. This changrequired because Win2K considers viewin bject to be an advanced g the security settings of an AD ofeature. To enable the Secu e iew, rity tab and th other advanced features of the snap-in, choose VAdvanced Features.
Like the basic NTFS permshows you only the basi
issi g b ty tab c permissions that are av
sions f obdit. A l rs othe ob ont the
ild objects (objects in the container), ser objects).
ons dialo ox, the basic AD permissions dialog box’s Securiailable to control access to AD objects. Again,
to access all the permisbox, then click View/E
or an ADist appea
ject, click Advanced in the basic permissions dialog f permissions that can apply to a number of objects, as
shown in Figure 5.8. If object (the container), ch
ject is a c ainer, the list includes permissions that apply toand a subset of child objects (for
example, only U
147
Chapter 5
Figure 5.8: The full AD permissions dialog box for a user object.
objAD it, they also apply to all the objects (such as files) in the folder. For example, let’s say that you give the GoodFellas security group Read permission on a folder. When you apply the permission, on the advanced
lect This folder, subfolders and files from the Apply onto
n
; it the permissions on an NTFS volume.
The fact that a container shows you the permissions that can apply to a number of different ects is one of the big differences between permissions on an NTFS volume and permissions in . When you own a folder on an NTFS volume and can set permissions on
NTFS permissions dialog box, you setext 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 doesn’t 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 caadd 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-specificisn’t a capability that is shared with
148
Chapter 5
149
In a i n set them at the attribute level. When you t he entire object. For a dFellas group to crea c ou 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
erty of a User object so that only you can change the value
s, then e resulting Properties tab (remember that properties and
dd tion to setting permissions on objects in AD, you ca se permissions to allow or deny access at the object level, they apply to t ex mple, you can set object-level permissions on an OU to allow the Goote hild objects in the OU. When y
permissions on the Home Phone propof 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 permissionclicking View/Edit. Figure 5.9 shows thattributes 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 doesn’t list every attribute, only the commonly used attributes that Microsoft thinks you’ll 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.
Chapter 5
150
Miscellaneous Permissions While I’ve taken a quick look at the two predominant types of permissions that you’ll work with in Win2K, there are obviously many more securable objects available in Win2K. So although I’ve 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 let’s talk very briefly about securable objects and what the term means. Simply put, if an permissions on it. That’s all there is to it, really, so if you
and calls them logon rights and privileges, n2K
govern how your users and
object is securable, you can set encounter an object and you’re not sure whether it’s securable, see if it has a permission that you can set.
User Rights If you’ve dealt with NT at all, you’re already familiar with the concepts of user rights and extended rights. Win2K redefines both of these terms respectively. Overall, the rights in Win2K are the same; they just have different names. Wialso 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 thatlets 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 thatother 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 computer’s
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 Privilege Determines which accounts can create a folder in the objects kernel’s object manager. Debug programs Privilege Determines which accounts can attach a debugger to any
process. Deny acfrom the network
Determines which accounts cannot connect to the computer over the network.
cess to this computer Logon right
Deny logon as batch job Logon right Determines which accounts cannot log on to the
Chapter 5
151
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 Privilege Determines which accounts can set the Trusted for Delegation setting on user and computer accounts. accounts to be trusted for
delegation 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 shouldn’t 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 Privilege Determines which accounts can modify system-wide environment variables. variables
Profile single process Privilege Determines which accounts can profile the execution of a single process.
Remove computer from Priviledoc g
ge Determines which accounts can remove a laptop from a kin station docking station.
Replace a procetoke
place the token of a ss-level n sub-process.
Privilege Determines which accounts can re
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. Synchrodata
nize directory service Privilege Isn’t implemented and shouldn’t be used.
Take owother ob
r permissions.
nership of files or jects
Privilege Determines which accounts can take ownership of files oother objects without regard to object
Table 5.3: Logon rights and privileges in Win2K.
Chapter 5
152
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, I’ll give you a quick example of the process of backing up the folders and files on a computer.
plete volumhe lume, rea tes of every file, and
read the data of ev usly access to perform your backup. To g p Files and
ile ess the ac ups. This privilege allows you to bac ary permissions on the NTFS volume.
Security Groups ws 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
n groups exist solely for sending bulk e-mail and are mentioned here just for completeness.
principal and thus has a SID. Through ACLs, members of a
istent 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 co trol and audit. Users who need access are added or removed from the appropriate security
urces don’t change very often.
If you need to back up a comthe folders on t
e, your backup software needs to be able to traverse all d the folder contents, read the attribu NTFS vo
ery file. Obvio , you don’t want to ask every one of your users to grant youet around this situation, you use the Back U
Directories priv ge to acc count from which you perform backk up the necess folders and files on the system because it overrides the
Not unlike NT 4.0, Win2K allo
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 isn’t a security principal and has no corresponding SID. Members of a distribution group cannot be used in ACLs. Distributio
A security group is a security 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 cons
ngroups as needed, and the ACLs on reso
Chapter 5
153
You aaddress s also function as distribution groups. Additionally, Exchange 200 E tion of dist u come the single
D groups for e-mail 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 groups—Grant 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 isn’t present in AD.
Domain local groups—Grant 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 isn’t published to the GC.
Global groups—Combine 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 isn’t 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 isn’t published to the GC.
Universal groups—Grant 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 I’ve noted above, on nesting groups in a mixed-mode domain.
c n mail-enable security groups by adding a Simple Mail Transfer Protocol (SMTP) , thus letting security group
0 ( 2K) controls access to public folders using AD security groups. The addirib tion groups and the ability to mail-enable security groups allows AD to be
repository for group membership across the enterprise. Unfortunately, using A
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 group’s scope after creating it.
Chapter 5
ACLs An ACL defines the permissions that apply to an object and its properties. Although this chapteis concerned with the type of ACL that you use to allow or deny access to resources, there are really tw
r
o types of ACLs in Win2K: DACLs and system access control lists (SACLs). The DA audited
StructWh t nsists primprincipal and providing the securi ith rights that are allowed, denied, and/or
CL allows or denies access to objects, while the SACL controls how access to objects is. (I’ll talk more about auditing in Chapter 6.)
ure of an ACL ile here are a couple of bookkeeping entries at the beginning of the ACL structure, it coarily of ACEs, as shown in Figure 5.10. Each ACE is responsible for identifying a security
ty principals waudited.
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 Size—Indicates the total number of bytes that the ACL uses.
• ACL Revision—Indicates the revision number for the ACL’s 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 Count—Indicates 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
155
Access Control Entries While the ACL is the overall structure for providing permissions in Win2K, it’s really the ACEs that carry all the real access control information. Although there are different types of ACE st ctures, as I mentioned earlier, all ACEs include a SID, an access mask, flags to determine
All ACEs are somewhat similar, but Win2K supports six ACE types, as shown in Table 5.4. Of
t-specific and can be used only in ACLs for AD objects.
ACE
ruinheritance of the ACE, and the ACE type.
these six ACE types, three are generic and can be used in ACLs for any securable object. The other three are objec
Type Description
Generic Denies access to an object in a DACL. AccObject-specific Denies access in a DACL to a property or property set or to limit
ess-denied
inheritance to a specified type of child object. Generic Allows access to an object in a DACL. Access-
or property set or to limit object.
allowed Object-specific Allows access in a DACL to a property
inheritance to a specified type of child Generic Logs attempts to access an object in a DACL. System-audit 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.
Tab
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 they’re 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 isn’t 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, let’s take a quick look at the basic structure of Win2K’s generic and object-specific ACE types. All three generic ACE types share the same structure, which Figure 5.11 shows.
le 5.4: The six types of ACEs.
Chapter 5
Figu
ject.
• e and Audit Flags—Control the auditing and inheritance aspects of the ACE.
f the object.
• SID—Identifies 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.
re 5.11: The structure of a generic ACE.
• ACE Size—Specifies the size of the entire ACE in bytes.
• ACE Type—Specifies whether the ACE allows, denies, or monitors access to an ob
Inheritanc
• Access Mask—Is an ACE type-specific value composed of 32 bits that correspond to theaccess rights o
.12: The structure of an object-specific ACE. Figure 5
156
Chapter 5
157
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 Type—If present, contains a GUID that is used to represent a type of child , an attribute or at or an extended right
e cts can inherit the ACE
ndicate ype field is t in the A
nher ally occurs. s ated Inherited ACEs aren’t always
ent obje ances:
hild objec
of the
L of the
Whenever one of these events h One of the things that you need to be aw
the container itself but is there only to be inherited down the chain. When this configuration occurs, the ACEs are inherited down the object
object tribute set,
• Inherited Object Typ —If present, contains a GUID that specifies which child obje
• Object Flags—I whether the Object Type or Inherited Object Tactually presen CE structure.
ACE Inheritance I’ve talked a bit about the i itance of ACEs, but not about how this process actuACE inheritance is the procesto the ACL of a child object.
by which the ACEs in the ACL of a parent object are propag recomputed but are instead
propagated from the par ct to the child object in the following circumst
• When a new c t is created.
• When the DACL parent object is modified.
• When the SAC parent object is modified.
appens, Win2K must re-evaluate the inheritance of ACEs.are of when this re-evaluation occurs is that a container object
may carry an ACL that isn’t effective on
hierarchy until they can be applied to a non-container object. They then become effective ACEsfor that object.
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
Altthree si
1. ACEs are grouped before any inherited ACEs.
.
By c
•
.13: The canonical order of ACEs.
hough this figure gives you an idea of what canonical order is, it’s best described by these mple rules:
Explicit
2. Within a group of explicit ACEs, access-denied ACEs are placed before access-allowedACEs.
3. Inherited ACEs are ordered in the same way in which they’re inherited. Inherited parentACEs come first, followed by grandparent ACEs, and so on
pla ing ACEs in canonical order, you can be assured of two things.
• Explicit ACEs are evaluated before inherited ACEs—The owner of a child object really has control over the object’s access, rather the object’s 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 ACEs—You 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, it’s time to talk about where ACLs arused. 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 it’s asso
e
ciated with, a security descriptor’s contents follow a general formula:
ts in a container inherit access control information from the
• 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 objeccontainer
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.
• Header—Contains 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.
ty principal that owns the object.
NIX
CL—Holds the ACL for the accounts and groups that can access the object.
• Owner SID—As it sounds, the SID of the securi
• Group SID—Is included only for use by Portable Operating Systems Interface for U(POSIX) subsystems and is totally ignored by the rest of Win2K.
• SACL—Contains the ACL for the accounts and groups that should be audited when they access the object.
• DA
159
Chapter 5
160
I’ve rea quick ion of the header, the control flags. The control flags are imp ta r wil simple bit fields and are shown in Table 5.5 along with Microsoft’s definitions.
Con ol
p tty much covered the rest of the fields contained in a security descriptor, so I want to take look at the most important port
or nt to a security descriptor because they control how ACEs from this security descriptol be propagated using inheritance to a child object’s security descriptor. Flags are stored as
tr Flag Definition
SE_DACL_AUTO_INHERITED Inheritable ACEs in this object's DACL have been propagated to objects. existing child
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 isn’t 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 doesn’t have to. If the owner doesn’t 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 object’s type.
After the object is created, the access control information it contains can be modified by the object’s owner or someone who’s 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 parent’s 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.
Chapter 5
161
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 evermust 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 you’the owner, you can always recover your ability to access the file.
y object
re
Access Tokens cess control puzzle is the access token. As I explained earlier, each r behalf during your logon session receives a copy of your logon
nd he
oken.
ry security group that contains the user; includes tribute, if present.
that the user has been granted on the local computer.
• a restricted token.
.
Most ofImpersaccess
The final piece in Win2K’s acthread that is launched on yousession access token. As a result, Win2K can always look at the access token of a thread aknow which security principal it’s running on behalf of. A Win2K access token consists of tfollowing information:
• User SID—The SID for the user that is assigned this access t
• Group SIDs—The list of SIDs for evethe list of SIDs from the user’s SID-History at
• Privileges—The list of privileges
• Owner SID—The 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 SIDvalue).
• Primary Group—The SID for the user’s primary group (remember, it’s only used for the POSIX subsystem).
• DACL—A default set of permissions that Win2K applies to objects that are created by the user if no other access control information is available.
• Source—The authenticating entity that caused the access token to be created.
• Type—A flag that indicates whether this access token is a primary access token or an impersonation access token.
• Impersonation Level—The extent to which a service can assume the security context of a client that is represented by this access token.
• Statistics—Some statistical information about this access token.
Restricting SIDs—A list of SIDs added to the token to create
• Session ID—An indication of whether the access token is associated with a Terminal Services user session
these values make sense, at least until you get to the Type field. The Type, onation Level, and Restricting SIDs fields are all involved in creating impersonation tokens and restricted access tokens. These are the topics of the next two sections.
Chapter 5
162
Imp sBefore . Win2Kdifferenby the p g env ext of some 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 ppermissionenterprise. However, what if the service had a bug and Alice was able to tell the service to get her a copy something that
Impersonation vice to access all resources by allowing ac lf. Thus, the servithe pay stub ex gain tries to retrieve a copy of Bob’s pay K uses the ide t y stub.
ImpersonatioThe ability of a s tokens. The ser associated with the primary control thread of the service process. This token makes access checks when the service needs to
ate a thread
er onation discussing impersonation access tokens, I want to go over the concept of impersonation supports the notion of impersonation, which is the ability to execute a thread with a t security context than that of the thread’s owner. The need for impersonation is driven roliferation of client/server applications that predominate today’s computin
ironments. When a client contacts a server, the server typically runs with the security cont service account
ermission to access her pay stub. If Bob contacts the service, the service must have to access his pay stub. The level of access holds true for all the employees in an
of Bob’s pay stub? From a security perspective, this level of access is obviously we don’t want.
overcomes the problems inherent in allowing a sercess checks to be performed against the requestor of the service, not the service itse
ce performs access control checks against the identity of the client. Going back to ample, if impersonation is used and Alice once a
stub, the service takes on the entity of Alice, then tries to access the pay stub. Win2nti y of Alice and (hopefully) determines that she isn’t authorized to view Bob’s pa
n Access Tokens process to impersonate another user is implemented using impersonation accesvice runs with its usual primary token, one that is
access objects of its own accord.
When a service accepts a client request to perform a function, the service needs to creto 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 service’s own security context. The notion of primary and impersonation access tokens is depicted in Figure 5.15.
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
is is
t
n 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. It’s 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 token’s SIDs, or by adding restricting SIDs to the access token.
client’s behalf, as if the service actually were the client. The client process controls to what extent a service can act on the client’s behalf by selecting an impersonation level. The choice in the hands of the client and not the service. To a certain extent, the concept of impersonation similar to granting someone power of attorney over your affairs. Four levels of impersonation areavailable:
• Anonymous—The client is anonymous to the service.
• Identify—The service can use the identity of the client in its own security mechanism bucannot impersonate the client.
• Impersonate—The service can impersonate the client but cannot pass on the client’s identity to another service.
• Delegate—The service can impersonate the client not only when it accesses resources on the service’s computer but also when it accesses services on other computers.
Restricted Access Tokens Win2K allows an applicatio
163
Chapter 5
164
Restricted access tokens aren’t something that you get automatically; they have to be explicitly cation to reduce the risk that a new process or thread may do
ted ch 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 t the downloaded Web pages will be successful at doing something malicious
ystem. For thosthis feature whenever yo
Tying It All Togetvered all the
Remember, the single go etermine whether a security n on some object. Win2K handles access control
decisions by considering the following three pieces of information:
principal’s desired access mask.
ject’s sec
ry briefly l’s desired access mask is pretty much the same thing. The desired access mask is a simple 32-bit flag structure in which b ts and turned off for rights that the se is desired access
compute wheth d to generate a granted acces
granted acc evaluated; if
If access is allowed or ddesired access mask bits are tu ng access mask is returned for use. The bits that
e which rights the security principal is actually authorized to use.
ining a security principal’s authorizations is summarized in the
3. e desired access mask, the security principal’s ed to see whether the Manage Auditing and Security Log privilege
CL is set in the granted access mask; otherwise, it’s
created for you by an applisomething bad. For example, Microsoft’s Internet Explorer (IE) 5.5 and higher uses a restricaccess token to laun
reduces the risk thato your s e of you who are Win2K application developers, I implore you to use
u can to limit the access you give each of your application threads.
her I’ve now co pieces that go into making an access control decision in Win2K.
al of an access control decision is to dprincipal is authorized to perform some actio
• The security principal’s access token.
• The security
• The ob urity descriptor.
I’ve talked ve about access masks as they relate to ACEs. Well, the security principa
its are turned on for rights that the security principal wancurity principal doesn’t want. The SRM manipulates th
mask to er access will be allowed or denied. The requested access mask is uses mask.
Initially, theright bit is
ess mask is set to all zeros (no access granted). Each requested access access is allowed, the corresponding bit is set in the granted access mask. enied, the bit is turned off in the requested access mask. Once all the
rned off, the grantiare left on in the granted access mask determin
The complete process for determfollowing five steps:
1. If there is no DACL in the object’s 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.
If the right to access the SACL is set in thaccess token is consultis present. If it is, the bit for the SAnot set.
Chapter 5
165
4. If the desired access mask indicates that the security principal wants access to Read or Modify Owner, the security descriptor is used to ect with one of the SIDs in the security principal’s
elds. If a match is found, the security principal e bits in the granted access mask aren’t set.
escriptor using the
a. If the inheritance flags of the ACE are marked INHERIT_ONLY, the ACE is skipped.
l gets no access to the object.
ontinues with the next ACE.
f. If all the ACEs are processed and there are any bits remaining in the desired access mask that haven’t 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 you’re 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.
Permissions, Change Permissions, compare the Owner SID of the objaccess token’s User SID or Group SIDs fiis granted access; otherwise, th
5. The object’s DACL examines each ACE in the object’s security dfollowing rules:
b. If the SID in the subject’s access token doesn’t match the SID in the ACE, the ACE is skipped.
c. If the ACE type is access-denied, the rights in the security principal’s desired access mask are compared with the ACE’s access mask. If there are any matches, the security principa
d. If the ACE type is access-allowed, the rights in the security principal’s desired access mask are compared with the ACE’s 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 c
Chapter 5
166
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 gro s o 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 mu v f the group object; therefore, a large group can generate a significant
ontain just other universal or global
ds on the
t are in other domains, client applications must
up is published t
lti- alued attribute oamount of replication traffic.
The simplest strategy for mitigating replication traffic is to use group nesting. Look toward creating large universal groups—umbrella groups that cgroups. 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 don’t have their membership published in the GC.
As I’ve just discussed, the ability to expand and view the membership of a group depenscope 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 thamake direct Lightweight Directory Access Protocol (LDAP) calls to a domain controller in theremote 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 you’ll have to make when you’re deciding how to deal with large universal groupsand 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.
Chapter 5
167
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 specifiaccess across an entire d
c access on a local computer without granting omain.
Domain local The group doesn’t 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 doesn’t require users to see full membership from any domain, AND group membership doesn’t need to cross domain boundaries.
Univers see full membership from any domain, OR al The group requires users todomain local and global groups won’t meet the requirements for the use of the group.
Tab .
• Act as part of the OS
• Create a token object
• Create permanent shared objects
• Debug programs
• Generate security audits
le 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 userrights 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:
Chapter 5
168
• Lock pages in memory
u
• Manage auditing and security log
• Modify firmware environment variables
• Replace a process level token
• Synchronize directory service data
Summary As I’ve described in this chapter, access control provides the logical controls that prevent you from accessing information resources that you aren’t authorized to access. And because Win2K’saccess control model isn’t 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 I’m 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, yoshould be able to ensure that access control is properly used to protect the information assets of your enterprise.
Chapter 6
169
Chapter 6: Managing Auditing
Time and time again, I’ve 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 i bjectives were:
In t g and tracking responsibility for the actions of users and resources. Accountability includes aud idered by many a paramount security obj iv ter.
I’ll kes time to implement and can use a lot of your system to review the audit logs that your systems create. If you’ve ever reviewed audit logs by harev i tried to automate your reviews, either wit it for you.
Per
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, let’s 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, I’ll explain how Win2K provides auditing of significant system events. Along the way, I’ll 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 you’ll have a newfound enthusiasm for and a thorough understanding of the Win2K auditing system.
rev ew, these four security o
• Confidentiality
• Integrity
• Availability
• Accountability
hat chapter, I defined accountability as assigniniting, cons
ect e in its own right, and the topic of this chap
say it right up front: Auditing is hard. It ta’s resources. It takes quite a lot of effort
nd, you know how much fun that can be! After iew ng audit logs manually, many of you have probablyh in-house scripts or programs or by purchasing a security product to do
haps you didn’t 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 haven’t experienced these things yourself but have heard of someone who has. As a result, many of you probably don’t 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
Chapter 6
170
Developing an Effectiv rategy lt au
is collected until you t alone in its default approach—little or no auditing out of the box. Those of us who are a bit more security-conscious definitely
l of a . rushing in to config to
bout
Security in any organization re olicies and tiv
with a defined security policy cWin2K infrastructure. As I allu ust fit
urity objecti
Identifying the Three Typenderstand whether your security controls are t things in your enterprise. But auditing can
have different meanings for different people, all depending on their vantage point. While we st security professionals would agree that there
gitimate 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 in an interrelated way. Validating your Win2K system’s configurations
ts ake
e Auditing StWin2K ships with a defauaudit data
dit policy that collects absolutely no information. As a result, no or I go into a system and configure something. Win2K isn’most other operating systems (OSs) also come configured with
want to turn on some leveBut before
uditing as soon as we install a new computer in our environmenture a potentially haphazard audit policy, it’s worth your while
analyze how and why you want to cohelp you, I’ll talk briefly ayour auditing strategy.
nfigure your new Win2K system to perform auditing. To some of the things you need to keep in mind when developing
ally starts with a comprehensive set of security pstandards (referred to collec ely as security policies, or more simply, security policy). Only
an you build an effective security-management program for your ded to in Chapter 1, the security controls that you deploy m
into the overall sec ves of your organization.
s of Auditing One of the most effective ways to measure and uworking to support your security policy is to audi
might assign them slightly different names, moare three basic types of system auditing.
• Managing configuration—Validating that the configuration of a computer matches a known baseline. Hopefully, this known baseline meets or exceeds current industry-standard best-practice recommendations.
• Preventing and detecting intrusion—Identifying, in real time, threats to your environment that may lead to an intrusion or detecting an actual intrusion.
• Auditing events—Collecting and analyzing selected system events to identify both the le
program, and they workcan reveal computers that don’t comply with your established baselines. Identifying new threato your environment by keeping track of the latest and greatest vulnerabilities allow you to taction 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.
Chapter 6
171
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. It’s this last type of auditing—auditing events—that 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 organization’s security policy. If your organization doesn’t 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
ent.
r.
. Attackers could also use audit data to identify users in your environment who have elevated privileges. It’s also not out of the question that business competitors could use
termine who your customers and suppliers are. Your security policy needs to data into account.
n situations where you ence of not
but also the integrity of the audit logs.
Trading Off Information against System Performance
nd disk resources in your environment. The more auditing you enable, e precious commodities is consumed. On the one hand, if you don’t
uditing, you may not capture the events required to fulfill your security policy.
.
that collecting and retaining system and user audit data can have on your environm
Overall, you want to ensure that any audit data that you generate in your environment helps youmaintain a secure computing environment and troubleshoot the problems that are bound to occuUnfortunately, this noble use of audit data isn’t 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
your audit logs to detake all of these potential uses of audit
Because auditing events produces information that is relevant to both normal system use as wellas system abuse, it’s 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, it’s doubly important ineed to use audit events to support legal action. As a result, you need to preserve evidonly the system configuration
Another aspect to consider before configuring the auditing of your Win2K systems is the trade-off between information and system performance. Auditing doesn’t come for free, and it consumes both processor athe more of each of thesenable enough aOn the other hand, enabling too much auditing can cause your system’s performance to significantly degrade. Too much auditing can also hide significant audit events in a sea of noise
Chapter 6
172
I can’t 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 banswering 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?
y
you auditing?
ible for retaining the logs?
g the logs?
• ed?
•
• cation?
are you ow
commendations to get you started later in the chapter in “Recommended Auditing Configurations.”
• What are
• 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 respons
• Who is responsible for reviewin
How often should logs be review
Who needs access to the logs?
Do logs need to be collected in a central lo
• 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 it’s important to know the answers to each of these questions, the answer to “What auditing?” may be one of the more interesting. Based on your security policy, you need to knwhat events you need to audit and how they relate to the security threats that you’re 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. I’ll give specific re
Chapter 6
173
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 logonby a user who is on vacation or known to be away from the office,
someone may be inappropriately using the user’s account. Audit account management —Success
The misuse of privilege. If you see a user being added to theAdmins group, you can validate that the action was correct arequired for the user to do their job. One of the last things yoa rogue Domain Administrator in your environment.
Domain nd u want is
File read access—Failure An attacker trying to gain access to sensitive corporate files. By ntial files
inappropriately trying to access the files.
creating a system access control list (SACL) on highly confidein your environment, you can keep track of people who are
File write access— InapFailure/Success environment. Changes to .exe and .dll files could signal a potential
virus or an attacker modifying the system for their illicit purposes.
propriate changes, or attempted changes, to program files in your
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
whenever , the user specific u can
pted in your environment. The Event Log urrence of events
itself. Instead, it’s a passive system with the job of collecting information from other objects in
appropriately, you can specify that audit entries be written to the Event Log Servicecertain events occur in your environment. Each audit entry records what action occurredwho was responsible for the action, the date and time of the action, and any informationto the audit event. Not only can you keep track of successfully attempted actions, but yoalso keep track of unsuccessful actions that are attemService isn’t an active subsystem because it doesn’t go out and look for the occ
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.
Chapter 6
Figure 6.1: The six logs of the Event Log Service.
Thr o are famare specialservice
ApplicThe Apapplica used by any application to record events that it thinks are imp a on the applica 000 ResourProduc
ee f these logs are the standard Application, System, and Security logs that most of us iliar with. They’re available on every Win2K system in your environment. The other three the Directory Service, File Replication Service (FRS), and DNS Server logs. These are more
ized logs, and they only exist on servers in your environment that have the appropriate installed.
ation Log plication Log records errors, warnings, and informational messages generated by tion software. This log can be
ort nt. Consequently, the quantity and quality of the events in this log depend entirelytions that are installed on your systems. For example, when you install the Windows 2ce Kit, the following event is registered in the Application Log: t: Microsoft Windows 2000 Resource Kit—Installation operation
completed successfully.
List 6
While this is one use of the Application Log, just about any event that an application believes is default, the Application Log can be written to and read by any
s 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
ing .1: The event registered in the System Log when you install the Win2K Resource Kit.
important can be written to it. By user in your environment.
System Log The System Log records errors, warnings, and informational messages generated by the OS. Thilog is used by Win2K
Free.
Listing 6.2: The event registered in the System Log when Win2K starts.
174
Chapter 6
175
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 kernel-mode 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 I’ve 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
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
the SE_AUDIT_NAME privilege.
'C:\WINNT\NTDS\ntds.dit'.
Listing 6.4: The event recorded in the Directory Service Log when AD finishes decrementing its database.
Chapter 6
176
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, ait 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 tran
nd
sfers that have been completed, and excessive replication traffic. For example, when the DNS service has
o the DNThe
problems opening a zone for which it’s been configured, the following event is written tS Server Log: 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
ntroller, the en to the FRS Log:
tion S
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 replicationhas completed. For example, when the FRS successfully overcomes replication issues with other domain controllers that are preventing the computer from becoming a domain cofollowing event is writtThe File Replica ervice 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
Reading the Event LogContrary to what you migh
n a vent log
record. While efficiency ofmore to do with a desire on result, when an application or the represents the event.
or 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.
sing
in the FRS Log when FRS overcomes replication issues.
Files t think, Win2K doesn’t store the event logs as simple text files.
Instead, it stores them imethod of storing e
binary format in an .evt file. This format provides the most compact information because not all of the information is stored in the saved storage is a valid reason for using a proprietary format, it really has Microsoft’s part to explain events in multiple languages. As asystem writes an event to a log, it stores a numerical value that
Programmers who are responsible f
Every application-and-event-number combination that is written to a log can be mapped to ale string to accurately reflect the recorded event.
Chapter 6
Because the event logs use a proprietary format, it’s not a simple thing to read them directly. Treconstruct the human-readable format of the logs, Win2K needs to combine information from anumber of sources, as shown below in Figure 6.2.
o
Figure 6.2: How Win2K reconstructs event records.
The prim
preopposed 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.
simple. It requires that the Event Viewer combine information
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
E\System\CurrentControlSet\Services\EventLog. If you pull up this Registry key on a computer, you’ll see the subkeys for each event log that is
ary 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
vious versions of the OS, not a lot has changed except that it’s now an MMC snap-in as
The process is actually pretty 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
Registry key HKEY_LOCAL_MACHIN
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 human-readable 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.
ty, and System logs, you can only use the Event Viewer to configure all of the event log settings. If you
shown in the Event Viewer, then select Properties from the shortcut
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, Securi
right-click any of the logs menu, the log’s 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
179
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 log’s 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 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 haven’t been backed up before their
needed
maximum size is reached. Overwrite events older Causes eacthan X days
h new audit event to overwrite the oldest existing audit event when the log has reached its maximum size, providing that the oldest ev old. If you choose this option, you also risk losing events for logs that haven’t been backed up before their maximum sievol
ent is more than X days
ze is reached. In addition, if no events can be overwritten, no more ents are logged, and auditing essentially ceases to function until the
dest event has aged sufficiently so that it can be overwritten. Do not ov(clear log
erwrite events manually)
N the loexthpr d up and cleared before it
ever allows new audit events to overwrite older audit events. Onceg reaches its maximum size, auditing for this log ceases until the log is plicitly cleared by an administrator. This is probably the most secure of e three options, provided that you’ve put appropriate operational ocedures in place to ensure that the log is backereaches 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 theshortcut menu. You’re then og, asked if you want to save the log before clearing it. When you clear a lI recommend that you always save a copy.
Chapter 6
180
As you’ve sevents
een, nfigure the event logs of a Win2K system in such a way that audit are being rated but not stored in the event log. While this is an undesirable situation
for any of the logs, it can be u ntly, if Win2K cannot continue auditing events to the Security Log, it has an option to actually halt the system. Known
ion will crash a computer if it cannot continue auditing security events. While a crash sounds pretty drastic, it’s really the only recourse for this setting because
ht require it to write security events to the event log, something it
you can co gene
nacceptable for the Security Log. Conseque
as CrashOnAuditFail, this opt
shutting down gracefully migcannot 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 1
Tab . s.
Wh t his setting, the Registry key is set to 2 and the key type to RE N person who is allowed to log on is the
le 6 3: CrashOnAuditFail setting
en he system crashes as a result of tG_ ONE. With the computer in this state, the only
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 you’ve 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 you’re 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.
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 you’re 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 you’d have to sift through to find what you’re 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 time—that 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 numeric d event. al ID of the generate
Table 6.4: Event record header in
The event record description con at is specific to the e wn below in Figure 6.5. As you can see, there is not only a Description text b Data text box; both
able as part of the va of an event record. T box is typically human-readable, w xt box, if it’s specifie pplication-specific data, which can be displayed ytes or words. You can d the details of each event
y simply double-clic in the Event Viewer.
formation.
tains information th vent, as shoox but also a
are avail riable portion he Description texthile the Data te d, contains a as either b isplay
record b king an event
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 eventtypes can be stored in each event log.
This Event Uses This And Represents This Type Icon
Error A sig nality is typically categorized as an error typically logs
nificant event. Loss of functioevent type. For example, if a service fails to successfully start, it
before exiting. an error eventWarning Something th cant but that could
fores . For example, applications that run into execution probl s but can continue processing without (significant) loss of functionality log warning events, then move on.
at may not be immediately signifihadow problemsem
Something that occurred successfully as part of normal operation. This is typically a major Win2K service, which uses the information event
Information
type to indicate that it’s started. In fact, when Win2K starts, it places an information event to mark the initialization of the system.
Suc 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.
cess Audit
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
essfully to access the object.
user tries unsucc
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 fofuture reference. Depending on your environment’s 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 bathe Security Log can be very different from how you back up the Application Log. Because hackers target the event lo
r
ck up
gs 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 we’ve 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 they’re 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 form ts frees you from having to remember to save all of the proper supporting files and Registr ation to view
sily 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
ay inform
the logs again. It also allows you to ea
that they’re more susceptible to malicious or unintended alteration. If you’re creating backups for evidential reasons, I recommend that you use the standard event log format.
Figure 6.7: Viewing a DNS Server L
No matter which format you chbacking up event logs. To back ht-click the event log
then choose e name a
og in CSV format.
oose, the Event Viewer is the only built-in mechanism for up an event log, open the Event Viewer, rig
you want to save, Save Log File As from the shortcut menu. In the standard Save As dialog box, specify th nd location of the backup.
184
Chapter 6
185
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 ca standdetermLocalSystem, Administrators, ServerOperators, and Everyone. This access is described below in Tab 6
This Ev
ac ount under which the application is running. For example, if you run the Event Viewer as ard user, you have different access rights than running it as a local administrator. In ining access to the event logs, Win2K only cares about four types of accounts:
le .6.
ent Log Runs Under These Accounts And Has This Access
LocalSystem Read, Write, Clear Administrators Read, Write, Clear ServerOperators Read, Write, Clear
Application
Everyone Read, Write LocalSystem Read, Write, Clear Administrators Read, Clear
Security
Everyone None LocalSystem Read, Write, Clear Administrators Read, Write, Clear ServerOperators Read, Clear
System
Everyone Read LocalSystem Read, Write, Clear Administrators Read, Write, Clear
Directory Service
Everyone Read LocalSystem Read, Write, Clear Administrators Read, Write, Clear
DNS Server
Everyone Read LocalSystem Read, Write, Clear Administrators Read, Write, Clear
File Replication Service
Everyone Read
Table 6.6: Event log access control set
Log i
y Log. As I mentio the Event Logs,” if you have the turned o ystem crashes. By limiting
curity Log, ity of a crash, but you elihoo m and cause a simple
e (DoS) attack on t
tings.
As you can see, the Security s the most tightly controlled of the six event logs. By at an intruder can fill restricting write access to the LocalS
up your Securitystem account, it’s highly unlikely th
ned earlier in “ConfiguringCrashOnAuditFail option n and the Security Log fills up, the swho can write to the Se you don’t eliminate the possibilsignificantly decrease the lik d that an intruder can crash your systedenial of servic he computers in your environment.
Chapter 6
186
Another way to control access to the Application, Security, and System logs is to use the t accounts
sions from view key for each of the
Registry key component RestrictGuestAccess setting
Registry key shown below in Table 6and null logon ses
.7. Setting each key to a value of 1 prevents guesing these event logs. Be sure to set this
three logs.
Hive HKEY_LOCAL_MACHINE Key \CurrentControlSet\Services\EventLog\[Application|Security|System]Name RestrictGuestAccess Type REG_DWORD Value 1
Table 6.7: Restricting guest access to the Application, Security, and System logs.
While you can configure these settings by hand, it’s 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 N w that you know where audit information in Win2K is written to, it’s time to look at how to
f
this is the focus of this section. The second level entails setting audit options on jects in your environment. I’ll describe this second level in “Auditing Objects” below.
in
oget audit information into the event logs. While you may think of auditing as a single set oconfigurations, Win2K treats it as two levels. The first level has to do with setting a basic audit policy, andspecific obThe best way to enable high-level audit policy is to use either Local Security Policy or domain-based 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 domabut your domain as well!
Chapter 6
Figure 6.8: Standard audit polic
As you can see, there are nine categories that you can configure to implement basic audit policy. Table 6.8; they track system-level events that are
y settings.
These nine categories are listed below in 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 netwoto the local computer.
rk
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 user’s 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. The success and/or failure of a user’s attempt to access an object. For Audit object access 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 user’s 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 aren’t 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 efon the security of the system.
fect
Table 6.8: Audit policy settings and what they control.
187
Chapter 6
188
Auditing Objects f the audit policy ble the standard auditing functions
wo configu s of auditing.
ct Access—Allows you to use the individual properties of an object to enable auditing of different pe e to users in your environment. Examples of
object types Registry, and they’re discussed
Directory Servi the individual properties of AD able auditi to users in your environment.
on any of th nage Auditing and Security Log privilege. This privilege allows users to specify the Audit Object Access configuration
istry, and the objects contained in AD. So
mended to never assign this privilege to anyone in your environment. This obviously causes an interesting problem: How do you set up auditing of
circconfigurations of sensitive objects in your environment, assign this privilege to one or more
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
While many o settings described above enaall by themselves, t ration options only enable a clas
• Audit Objermissions availabl
individual are files, folders, printers, and the below.
• Audit ce Access—Allows you to useobjects to en ng of different permissions available
To set audit policy ese objects, you must have the Ma
options of things like files, folders, printers, the Regwhile 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 recom
objects if you don’t assign this privilege to any users? Well, I recommend that under normal umstances, you don’t assign the privilege to anyone. When you’re setting up the audit
users. Once the audit configuration is complete, remove this privilege from the users. This form of least privilege requires some effort, but I believe it’s warranted because it ensures that you have complete control over how auditing is implemented in your environment.
Files and Folders
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.
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 g files and folders because there are a lot of he course of normal operation, are accessed
l o
to identify users who are destroying information.
on d settings in Windows Explorer. Right-click the file or r you w choo the shortcut menu. In the Properties dialog box that
the Auditing tab. On the Auditing , shown Figu ove, and modify the audit settings of the ted obj gurin e than a few computers is tedious at so I hig men et the audit properties of domain-d comp
choose to audit. This is especially true for auditinfiles on each of your systems, some of which, in toften. If you were to audit the successful access of your computer’s system DLLs, you’d quickly overrun the Security Log. However, auditing files and folders allows you to keep track of criticafiles in your environment. Overall, you want to set file system auditing to track someone whmight be probing around for things and
You can c figure file an folder policyfolde ant, then se Properties fromappears, click the Security tab, page
then click Advanced, and select re 6.9, you can add, rem below in
selec ect. Confi g file and folder policy on morbest, hly recom d that you use Group Policy to sbase uters.
Figure 6.9: Us cess C ure file and folder policy settings.
ters e many of you may no Overall,
auditing printers isn’t a common practice because it fills up your Security Log with information e 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.
ing the Ac ontrol Settings dialog box to config
PrinWhil t be aware that you can audit printers, you definitely can.
that has negligible value. However, if you hav
189
Chapter 6
190
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.
Tab ons for auditing printers.
uration information for Win2K. As a he computers
in your environment. You need to be concerned about changes that are made to specific Registry ack who has made them. Unfortunately, you once again cannot audit
le
le 6.10: Opti
The Registry The Registry holds just about all of the important configresult, it’s important that you consider auditing changes to the Registry settings of t
keys and use auditing to treverything; otherwise, you’d quickly fill up the Security Log. The audit options that are availabfor 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 t st (ACL) for a key or subkey. he access control liWrite 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 Reg
You can configure auditing settin ou ission
ay the Aconfiguring audit policy for the Ronce again highly recommend th set the Registry audit settings of your
istry.
gs for the Registry using Regedt32.exe. Select the item ys option from the Sewant, then choose the Perm
the Auditing tab to displcurity menu, click Advanced, then choose
uditing page. However, as with auditing files and folders, egistry on more than a few computers is tedious at best, so I
at you use Group Policy to domain-based computers.
Chapter 6
191
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 most important inform
key to individua r environment, AD is undoubtedly the ation store for your entire
s that are oc D infrastructure. Much like the Registry, bout chang to specific AD objects and their
e auditing to track who has made them. As in other areas, you thing; otherwise, yo p the Directory Service Log.
s whose audit optio can control, the audit options available for objects y on the object itse ferent objects have different options
12 below shows a s audit options available for user objects in AD.
Audits Do This
l computers in youWin2K infrastructure. Thus, it’s a good idea to
keep an eye on the change curring in your Ayou need to be concerned a es that are made properties, and you should uscannot audit every u’d quickly fill u
Unlike other object ns you in AD depend solel lf. As a result, difavailable. Table 6. ubset of
This Audit Access Attempts to
List Contents List the ect. contents of the objRead 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 e object. the password of th
Table 6.12: Some of the options for auditin jects.
ll from the discussion of setting access control on AD objects in Chapter 5 that l permissions directly on an object as well as on each attribute of an AD
available for the properties of an object depend on the type tting auditing fo
g user ob
You might recayou can set access controobject. Once again, the audit optionsof object that you’re se r.
To audit access to AD objects, you ne t the auditing options for the objects you care to collect ed to seaccess information from. In addition, y ensure that the Audit Directory Service Access system ou mustauditing option is enabled.
You can configure audit settings for AD objects much like you set auditing for files and folders. rer, select the AD object you want, right-click it, then choose Properties from
the dialog box th ars, click Security, Advanced, then the Auditing e Auditing page. If yo own user object, one of the things that
should quickly jump out at you is that some default audit settings already exist!
In Windows Explothe shortcut menu. In at appetab to display th u do this for your
Chapter 6
192
While Win2K ships out of the box with no other object audit settings configured, AD comes pre-
pts to
being pre-configured to audit any addition, deletion, and modification of AD objects and their properties.
ecurity Event R100 event records in the Win2K Security Log. Listing all of
d the scope of this chapter, but I want to list about 20 to give you an idea of event records you can find in your environment. These security event ow in Table 6.13.
Event ID Event Type Description
configured for you. AD contains too many objects and properties to list here, so I’ll describe a standard user object. By default, an AD user object audits all successful and failed attemboth change and reset a user’s 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
Examining S ecords There are well over that may appear them here is beyonthe types of securityrecords are listed bel
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 didn’t log on within the
specified amount of time. 531 Failure A logon failu red because the account is disabled. re has occur538 Success A user has logged off. 539 Failure A logon failu nd the account is locked as a result of the
account lock . re has occurred a
ttingsout policy se608 Success A user right h gned to a user. as been assi609 Success A user right has been removed from a user. 610 Success A trust relatio blished with the specified domain. nship has been esta611 Success A trust relatio oved from the specified domain. nship has been rem612 Success The audit poli nged. cy has been cha617 Success The Kerberos policy ha anged. s been ch618 Success The encrypte ry policy has been changed. d data recove624 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 SID-history to a user account has failed. Failure An attempt to add a
Table 6.13: A partial list of security event records.
Chapter 6
193
While there could be many more event records in your Security Log, the ones above are a
e, an Event ID of 670 could be an honest mistake, or it could indicate
reasonable subset to keep an eye on. Each event record affects the security of your environment.For example, let’s 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 it’s assigning the Act As Part of the Operating System right, you should get very suspicious! Likewisthat 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 doesn’t make immediate sense from the description, you’ll find a more detailed description in the Error and Event Messages Help file in the Win2K Resource Kit. This Help file doesn’t 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 you’ve installed on your computer.
Recommended Auditing Configurations I recommend the following auditing configurations for your Win2K environment.
It’s prudent for you to keep logs for at least two to three months. Because logs can become quite large, it’s 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, it’s 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, they’ll 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
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 yourlogs, what you put in them, and how large you’re willing to configure them.
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 doesn’t fill up for about 45 days. I’ve seen event logs configured up to 128 MB!
Retain log 45 days. Ideally, you’ll 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 I’d 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 I’d only be tempted to enable this setting in environments where security is more important than availability.
Table 6.14: Recommended settings for event logs.
Chapter 6
194
System Audit Policy The system audit policy configuration options control the overall system-level audit policy of
port the
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 supsecurity 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 you’ll audit
d files in your environment. In general, you want to set file system
Use This Setting
the sensitive folders anauditing to track someone who might be probing around for things and to identify users who are destroying information.
For This Audit Access
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.
Chapter 6
195
Printer Object Auditing ations in Table 6.17 below as a guideline and carefully plan how you’ll audit Use the recommend
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 it’s 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 Success, Failure Permissions Take Ownership Success, Failure
Table 6. ettings for auditing printers.
RegisUse e the R gmodify Registry keys bu changes. This strategy will allow you to trace any pro m
For i
17: Recommended s
try Object Auditing th recommendations in Table 6.18 below as a guideline and carefully plan how you’ll audit
e istry. As I mentioned earlier, the strategy is to track not only the unsuccessful attempts to t also the successful
ble s back to the user who caused them.
Th s Audit Access Use This Setting
Query Value No auditing Set l Va ue Success, Failure Create Success, Failure SubkeyEnumerate 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.
Chapter 6
196
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 don’t 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. I’m paranoid of unnecessary modifications to AD because the industry hasn’t developed a full set of best practices for it, and I’ve seen more than one AD forest chopped down because AD became unrecoverable after someone made untested modifications!
Summary In this chapter, I’ve attempted to show that audit logs are a valuable tool. They support individual accountability of a user’s actions, can provide evidence for investigations, and can reveal just how well your overall security implementations are working.
in2K hasn’t changed much from its implementation in previous versions of the OS, I hope that you now have a much more thorough understanding of
While the Event Log Service in W
how auditing works in Win2K. In addition, you should have a good foundation for mapping yourorganization’s 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!
Chapter 7
197
Chapter 7: Managing Security Configuration
ow-en
lf; it’s also because I
ment—and explain how to put it to best use in your enterprise.
ecurity Configuration Tool Set oth a set of Microsoft Management Console (MMC) snap-ins and a command-line
a centralized interface for configuring the core security of your Win2K mplify managing security in your enterprise and perform basic
mponent introduced with Win2K, it really has its roots n Manager (SCM), which was released as an add-on in Windows NT
4).
re the uter’s
you must more tools to configure the security settings you want on a single
cumbersome, security configuration in NT 4.0 doesn’t allow you dit or analysis. Realistically, the only tool you can use to monitor
ent was the Event Viewer.
t pulled rity
was comprehensive, and easy to use.
In previous chapters, I presented quite a bit of theory, along with some practical advice and htos to help you secure your Windows 2000 (Win2K) infrastructure. While this approach has benecessary to adequately cover the material, this chapter will be a little different.
In this chapter, I’m 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 itsethink that the best way to learn how to manage the security of your environment is to get in thereand just do it. As a result, you might find it beneficial to read this chapter while you’re 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, I’ll start by talking about the Security Configuration Tool Set (SCTS)—the single best practical tool for configuring the security of your environ
Understanding the SThe SCTS is btool, and it provides computers. It allows you to sisecurity audits as required.
SCTS Background While the SCTS feels like a
the Security Configuratio brand-new co
in4.0 Service Pack 4 (SP
NT 4.0 provides an adequate number of tools for a security administrator to configumultitude of security settings available for a computer. You can use tools like the registry
peditors, Windows Explorer, and the User Manager to configure different facets of a comsecurity. While these and other applications do the job, they’re cumbersome becauseopen three, four, or evencomputer. In addition to being
uto perform any real security ae security of your environmth
Recognizing these security-administration issues, Microsoft designed one mechanism thatogether the diverse functionality required to appropriately configure and analyze the secu
nfigurations of a Win2K computer. Microsoft also ensured that the SCTScoflexible, extensible,
Chapter 7
198
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 s functionality with Group Policy Objects (GPOs) to
The C the security configurations of your ente r e the more critical security areas of y r
s policy.
y, user rights assignments, and
llows you to configure the settings for the main Event Viewer logs (Application, System, and Security).
• Restricted groups—Allows you to explicitly define the membership of security groups
• Registry—Allows you to specify security and audit configurations for registry values.
• File system—Allows 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.
predecessor is its ability to combine itcentrally define and automatically apply security policies throughout your enterprise.
S TS isn’t a silver bullet that will help you manage all ofrp ise. However, it does allow you to configure and analyzou Win2K infrastructure:
• Account policies—Allows you to configure password policy, account lockout policy, and Kerbero
• Local policies—Allows you to configure audit policsecurity options.
• Event logs—A
that you consider sensitive.
• System services—Allows you to specify the configuration of installed services on the computers in your environment, including access control and startup options.
Chapter 7
Figu
The is engine. This engine carries out the real work of service attachment engines. The eng ecify the security configurations that are to be configured or analyzed.
MC snap-in provides a graphical user interface (GUI) for
.
re 7.1: The architecture of SCTS.
core of the architecture is the configuration and analys the SCTS, and you can extend it by writing custom
ine uses both security-configuration templates and security database files to sp
On top of the core engine, an Madministrators. 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 SCTSThe 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.
you might use to address different The SCTS wasn’t designed to replace all of the system tools that as ects of system security—such as the Active Directory Usp ers 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
200
Using Security Templates As I’ve 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.
Sec tyou to (In thisany quthe available security settings of a GPO.) A portion of a security template is shown below in Listing
uri y templates are implemented as text-based files that carry the .inf extension. They allow configure all the security attributes of a GPO except public key and IP security policies. chapter, I’ll discuss the appropriate settings for these configuration options. If you have estions about what a configuration option does, refer to Chapter 3, in which I talked about
7.1.
[version] signature="$CHICAGO$" revision=1 [System Access] Min uim mPasswordAge = 2 MaximumPasswordAge = 42 MinimumPasswordLength = 8 PasswordComplexity = 1 PasswordHistorySize = 24 RequireLogonToChangePassword = 0 ClearTextPassword = 0 [Registry Values] MAC NHI E\System\CurrentControlSet\Control\Lsa\AuditBaseObjects=4,0 MAC NHI E\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;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BA)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;SO)(A;;CCLCSWRPWPDTLOCRRC;;;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.
Chapter 7
201
As you can see from this listing, portions of a security template are straightforward and easy to plicated. To ease the burden of maintaining security
r
PreWin2K
•
•
•
The first three types build on one another, while the fourth rounds out the useful templates, as
read, while others are quite a bit more comtemplates, Win2K ships with the Security Templates MMC snap-in. I’ll discuss this snap-in late(see “Using the Security Templates MMC Snap-In”), but for now, just keep in mind that whileyou can use a text editor with security templates, there is a better way.
defined Security Templates ships with a number of predefined security templates, which fall into four categories.
Default—Used during a clean installation of Win2K.
Basic—Update the security of computers upgraded to Win2K.
Incremental—Provide different examples of how security can be configured on your computers.
• Miscellaneous—Don’t fit into the other categories.
shown in Figure 7.2.
Figure 7.2: The four types of predefined security templates and how they relate to one another.
Let’s take a closer look at these templates and how you might use them in your environment.
Chapter 7
202
Default Security Templates The first type of predefined templates are default security templates, and they’re used when you install and configure Win2K. For example, they’re used automatically on new Win2K systems that are clean-installed on an NT file system (NTFS) partition. It’s important to understand that default templates are applied only to fresh NTFS installs because security templates aren’t
lier) system or format the system o setting up the default security of a
hould 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.inf—The default workstation security template.
• Defltsv.inf—The default server security template.
• Defltdc.inf—The 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 don’t 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.inf—The basic workstation security template.
• Basicsv.inf—The default server security template.
applied when you upgrade a computer from an NT 4.0 (or earpartition as a file allocation table (FAT) volume. In addition tfreshly 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 s
• Basicdc.inf—The default domain controller promotion security template.
Because default security settings aren’t 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 isn’t 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 it—namely, the Basicsv.inf and Basicdc.inf security templates, in that order.
Chapter 7
203
Incremental Security Templates The third type of predefined template is incremental security templates. They’re 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 don’t include the default security settings plus the new modifications. The five incremental security templates are
tes
lt permissions of Win2K have been considerably tightened over those configured in NT 4.0, many non-certified,
unction properly when installed under Win2K and run by a
our e Power Users group or relax the permissions of your installation. Relaxing
permissions is exactly what this compatibility security template accomplishes, and it has for administrators who don’t want to put their end users in the Power
is
unt policies, auditing, and some security-minded Registry settings, but it doesn’t modify ACLs because they’re assumed to be properly set by the default security templates
• Hisecdc.inf and Hisecws.inf—Increase 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.
installed in the %Systemroot%\Security\Templates folder along with the basic security templaand are:
• Compatws.inf—Relaxes the ACLs for the Users security group so that they’re compatible with those of NT 4.0 workstations. Because the defau
legacy applications may not fnormal, non-privileged user.
In order for these types of applications to function properly, you may need to place yusers in th
been providedUsers security group. Using this security template isn’t secure, however, and I highly recommend that you don’t use it.
• Securedc.inf and Securews.inf—Increase the security of a computer by strengthening certain settings that weren’t tightened by the default security templates. Securedc.infintended to be applied to domain controllers, while Securews.inf is intended for use on both workstations and member servers. This template modifies things like acco
applied during installation.
Chapter 7
204
Miscellaneous Security Templates
.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.inf—Defines 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. I’ll 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 don’t 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 you’ll recall from my discussion of the overall SCTS architecture (see “Its Architecture”
sis engine uses both security templates and
The final type of predefined template doesn’t fit into any of the other categories, and it’s 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.inf—Define 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
earlier in this chapter), the configuration and analysecurity 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.
Chapter 7
The notion of a security database really starts to make sense once you know that there is one puter is
an
U ing the Security Templates MMC Snap-In Because security templates are implemented as text files, you can easily copy, paste, import, and
iting them using a text editor like the te
special database on each and every system. The local security policy of each Win2K comstored in a security database called %Systemroot%\Security\Database\Secedit.sdb. As you csee, security templates are used to create security databases; security databases are in turn used toimplement security policy for the local computer.
s
export template attributes using your favorite text editor. EdSecurity Editor can become tedious, however, so doing anything more than simple cut-and-pasoperations is prone to error, and you could find yourself with an inoperative security template. As a result, you’ll probably find it much easier to use the Security Templates MMC snap-in to create and edit security templates. It’s 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>Adm MMC. To load the Security
un. In the Run dialog box, type MMC.
ck
inistrative Tools, you have to load the Security Templates snap-in directly fromTemplates snap-in:
1. Choose Start>R
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 cliAdd to select the snap-in. Then click Close.
5. Click OK to close the Add/Remove Snap-In dialog box.
205
Chapter 7
206
B 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
ing the folder path node. You can add other folders to the w
late n from the shortcut menu.
egistry security, and file system security.
.
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.
y
Security Templates node, then expandlist of shown security templates by right-clicking the Security Templates node and choosing NeMenu Search Path from the shortcut menu. This allows you to more easily manage your customsecurity 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 tempname node, then choose the appropriate optio
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, R
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 tothe security template’s Password Policy, Account Lockout Policy, and Kerberos Policy settingsSelect a node, then double-click the configuration setting
Figure 7.4: Configuring minimum password length.
Chapter 7
Local Policies configure local policy settings in a security template in the same manner as you configure
ount policies. You first expand the Local Policies node of the security template thaYouacc t 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
dify. For example, selecting User Rights Assignment displays all of the
setting you want to moavailable 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, you’re 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
te the security template on a s are contained in the security
groups that are defined in your production forest, you have to creacomputer in the forest to ensure that the correct user and group SIDtemplate.
207
Chapter 7
208
Eve t You codiscusssetting u want to n Log, whose configuration dialog box
n Log Settings nfigure Event Log settings in a security template in the same way as the settings ed above. When you expand the Event Log node, you have access to the Event Log s of the security template. Select a setting, then double-click the configuration setting yo modify. One is the Retention Method for Applicatio
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, let’s 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 above—Overwrite Events by Days. If you haven’t 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.
Chapter 7
Figure 7.7: Configuring how many days to retain the Event Log.
Restricted Groups s of a
Configuring restricted groups in a security template allows you to define the membersecurity group. By defining who should be a member of a group, you inherently define that everyone else isn’t 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 membersof 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
rators sec ty
Typ a users FAdministrators, Backup Users, and other privileged security groups so that you can ensure who has
figured. Figure 7.9 below shows configuring the
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 aren’t defined above. In addition, if any of the specified group members aren’t yet members of the Administ
uri group, they’re automatically added.
ic lly, you use restricted groups for security groups that have greater privileges than standard. or example, you can use restricted groups to restrict membership in your Domain
, and thus doesn’t 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 constartup 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 you’re modifying the security template.
210
Chapter 7
211
If you need to configure a system service in a security template that isn’t 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.
Figu
For cowner you need a refresher, I discussed configuring these settings in Chapters 5 a late Security Policy Set g o configure inheritance
re 7.10: Selecting a Registry key to configure.
ea h key you add to the security template, you can specify the access control, audit, and settings using the standard Win2K ACL editor. (If
nd 6.) Once you do, the Temptin dialog box appears, shown below in Figure 7.11. It allows you t
on the configured object’s children based on the security settings you’ve selected.
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 Subkeys—Propagates 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 aren’t 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 Replaced—Don’t inherit permissions from a parent object. This option allows you to add a Registry key whose security settings you don’t want to change. As a result of applying the security template, the object’s 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 won’t 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 settingsyou want to configure.
e Security Con nalysis MMC Snap-In uration an s you to import, analyze, configure,
and export the security configu our environment. Although it’s implemented as a snap-in, the console tool actual no processing and acts only as a
S configuration y Templates snap-in, you
from within M instructions in “Using the Security Templates -In” earlier in this chapter.) The console is shown below in Figure 7.13.
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 th figuration and AThe Security Config d Analysis MMC snap-in allow
rations for the computers in yly performs
GUI to the SCT and analysis engine. Like the Securits>Administrative Tools. Instead, you have to can’t open the snap-in by choosing Start>P
load the consolerogram
MC. (Follow the MMC Snap
213
Chapter 7
rs a ter and analyzing the system
Becaus ed to do is open or create a security database. As shown in the figure above, the console gives you
g ome
te
tabase, you can either configure or analyze the security settings ary instructions; this is shown below in Figure 7.14.
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 administratosimple mechanism for loading security configurations into a compufor 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 anew security policy
• Unauthorized changes to the security of previously configured systems.
e the SCTS is driven from the contents of a security database, the first thing you ne
instructions on how to proceed. Overall, creating a security database is pretty simple. One thinto note, though, is that by default, it’s created in the \Security\Database subfolder of your hdirectory. When you create a new security database, you’re asked to specify the security templato be used to initialize the security database.
Once you open or create a security da of the computer. Once again, the console provides the necess
214
Chapter 7
gs of a computer.
e e
e settings are flagged as problems that need your atte o
To analyze the com the Security Configuration and Analysis node, then choose Analyze Security Now from the shortcut menu. You’re then prompted to provide the loca n 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.
Figure 7.14: Instructions for configuring and analyzing the security settin
Analyzing the Security of a Computer To begin, I highly recommend that you get acquainted with the console by analyzing thcomputer’s security. This security analysis compares the current state of the computer against thcontents 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, th
nti n.
puter’s security, right-click
tio for a log file
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 SecurityTemplates snap-in. As you drill down through the configurations to the
leaf nodes, you’ll notice
figuration, you’re given three pieces of information: that for each security con
• 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
217
To indicate how the security settings on the computer equate with the security settings defined in right-hand pane of the console uses three icons, superimposed over the
ettings aren’t in conformance with your security policy but also what they are and should be set to. You won’t find this information in the log file created after analyzing the
atches) or in the log file created
have a good handle on how the console works and have analyzed the security of a computer in your environment, it’s time to configure security. This configures a computer with
the security database. The console starts up the SCTS
urity Configuration and Analysis node. Cho e w from the shortcut menu, then type the name of a log file for the operation.
The changes re actually made to the local security policy. This is imp ta et’s say that you’re configuring the security settings for a stan a uration and Analysis snap-in. Because the tool
rity O being assigned to the computer. As a result, just
ole tool, the settings may not become effective.
I di
the security database, thesecurity setting icon. These three icons are explained below (and examples are shown in the figure above).
• Small, green check mark—The value of the security setting on the computer matches the value in the security database.
• Small, red circle with a white cross—The value of the security setting on the computer doesn’t match the value in the security database.
• No icon—There 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 s
security on the computer (although it lists the configuration mismwhen you use the Security Editor. As a result, the Security Configuration and Analysis snap-in can be a better tool when you’re first preparing the security templates for your environment.
Configuring the Security of a Computer Once you
the security settings contained inconfiguration 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 tool’s progress.
Just as you did to analyze security, right-click the Secos Configure Computer No
made to the local computer aor nt to understand. For example, ld- lone computer using the Security Config
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 secusettings that are applied as a result of a GPbecause you configure a computer using this consIf this doesn’t make sense, I highly recommend that you reread the section of Chapter 3 in which
scuss GPOs and how they’re processed in a domain environment.
Chapter 7
218
Using the Security Editor re,
nd validate security configurations for computers in y onmmanner, it’s a lot like the Security Configur Ana n ffers of extra features that enhance your ability to m e sec our ent. This tool is extremely beneficial as you develop and troubleshoot the security-configuration settings in your
get now it w he optio at the co nd uses, 7.1.
Using This Syn
You can use the Security Editor (secedit.exe), a command-line tool, to analyze, configurefresh, export, a our envir
, but it o environm
ent. In this a couple ation and
anage thlysis snap-iurity of y
infrastructure, so it’s important that you to k ell. T ns th mmaand its syntax, are listed below in Table
This Option Does This tax
/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
s edit /re hpoli machin licy | user_policy} [/enforce]
relevant GPOs.
ec fres cy { e‗po
/export Exports the settings fra se
om
e.
secedit /export /CFG filename [/mergedPolicy] [/DB filename] [/areas area1 area2…] [/log logpath] [/verbose] [/quiet]
curity database into a security template fil
/validate Validates the syntax of a secedit /validate filename security template.
Table 7.1: The options and syntax used by the Secedit command.
er configure security or export a computer’s security configuration, you can use ty area u want to ffect, as sh below in le 7.2.
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
Maps to This Snap-In
When you eiththe Areas flag to specify which securiBy default, the Security Editor
s yo a own Tab
flag, remember to separate each area you specify with a single space.
This Area
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.
Chapter 7
219
Advantages Over the Security Con on and is SWhile the Security Editor performs the s sis and io ons a rity Configuration and Analysis snap-in, its d-line im tion d f make it more versatile and useful. For example, let’s say you want to analyze the security settings of a
u c 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
ur is log for each computer.
also e it more useful than the Security Configuration and abilit export and validate security templates is a
en you’re t of developing the appropriate set of security ay have spent some e getting the security
st the way nt it. Usi e Securi itor’s E configuration from t configured computer and apply it
ironment
Security E ts ability rce a ref of all GP hat are fault, G ation rs when the com starts
after tha
iroity Editor to a ers for settings that violate your security
policy. By taking advantage of the tool’ can easily run a script
ec that’s outsid e o section I’ll
puter for discrepancies in its security configuration, you must first he corre ig on is. Y n then im ent this
urity template. F ’s assume that there should be only two members of the Administrators security group on the workstations in your enterprise—the local
ain-level Workstation Administrators security group. Let’s ly implemented the template that sets the Administrators
Secu nf. The e the fol g comm b S eGroup.s Se up
b that the membership of the Admicurity template. In addition, running this command produces a
du analysis e to com t before yzing rect, type the following command to alter the membership of the
inistrators everyone /add
figuratiame analy
comman
Analys configuratplementa
nap-In n functi and adde
s the Secueatures
large number of computers. While yo an do this
scheduler to automatically create a sec ity analys
The Security Editor’s extra featuresAnalysis snap-in. In particular, the
maky to n
extremely valuable feature whsettings for your environment. For exam
in the midsple, you m tim
configuration of a computer ju you wa ng th ty Ed xportcommand, you can extract the securityto other computers in your env
tha.
Another useful feature of the ditor is i to fo resh Os tappropriate for a computer. By de PO propag occu ever puterup, then every 60 to 90 minutes t.
Analyzing Security in Your EnvYou can also use the Secur
nment nalyze comput
s command-line functionality, you re enterprise. I won’t dito search for security violations across your enti
script across a number of computers bscuss how to best run a
f thisause e the scop , but discuss very quickly how you can autom
To effectively analyze a com
ate your security analysis.
make sure that you know what tconfiguration into a sec
ct security confor example, let
urati ou ca plem
Administrator account and the domassume, too, that you’ve appropriatesecurity membership and named it reGroup.i n typ lowin and:
secedit /configure /d/overwrite
ecur db /cfg cureGro .inf
When you run this command, you can group is as it’s set in the se
e assured nistrators
security database file that you can use the security that you know is cor
ring the stag e. Bu anal
local Administrators security group:net localgroup adm
Chapter 7
220
This command adds the Everyone group to the local Administrators security group. Clearly, this is something that you wouldn’t 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:
Sec p.sdb g Secu yResul og
log ted by th evious c and. The best way to li ol. If you don’t have this tool on your computer,
are located in the Apps\Posix CD-ROM. e g file to all of the security lowing com
grep Mismatch SecurityResults.log
in h be flagg s having ismatch. values, bu
secedit /analyze /db/verbose
ureGrou /lo rit ts.l
The analysis results are placed in the file crea e pr ommfind them is using the Grep command-you’ll find it in the Resource Kit for the UNIX tools. (These tools
ne to
directory of the Resource Kit policy violations using the fol
) You can parsmand:
the lo find
After you run this command, the Adm istrators group s ould ed a a mThere may also be a number of mismatches on soconcern.
me Registry t they’re no cause for
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 n’t. does
Implementing Security Config tion e plement W ows 200 rver and dows
nts th fter are lemented differently than the ones ossible to ent the security nts. Tneric W entation.
o ers t Win2K installations require different security features or security controls to
ci alicio eaches o urity po hile each Win2K environment has different specific security challenges, there are a few fundamental
ronm play. Fo r purposes, I propose that a generic four basic types of co
ion
tions.
uraIt’s probably safe to assume that you n2000 Professional in a number of different fashions throughout your en
ed to im ind 0 Seterprise. It’s also safe to
Win
assume that the Win2K environmeyou look after. As a result, it’s imp
at I look atell you exactly how to im
impplem
configurations for your environmethe security configurations of a ge
hus, in this section, I’ll present a solution for ensuring in2K implem
Identifying the Four Basic RolesDifferen
f Comput
adequately protect themselves from ac dental or m us br f sec licy. W
roles that the computers in the envi ent must r ouview of your environment will show that you have different levels of security configurat
mputers, each requiring .
• Domain controllers
• Member servers
• Web servers
• Worksta
Chapter 7
221
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 won’t discuss the security configuration of a Web server here; I devote all of Chapter 10 to the topic.
ain Controllers n two ba les:
princi
access to resources in the domain.
respo hostin h Active ctory (A nd the (KDC). As a general rule, domain controllers shouldn’t be
g any other services except those explicitly required to allow the server to fulfill its role in rs co the most se ve inform n for yo in2K
ent and shouldn’t be carelessly d by a security vulnerability in an . Acce ain controllers shou restricted to the at your organization can tolerate.
of a in2K enviro They on e file and print services, host databases, host m il services, and provide a
multitude of other infrastructure services. As a result, me s n have to run a our environment. However, to
on set of security eed to use member servers in an interactive
cess should be restricted to administrative personnel. In addition, member ounts
whenever possible.
Workstations Workstations in a Win2K environment are the standard c rs run Windows 2000
to f all of the users in your environment. To take e of domain authentication, all workstations should be members of a domain in your
ation from all w ons sh cur ocontrollers. Once users are authenticated to the domain, access to the local computer
u counts e cre ond t t-in nistrators and guest accounts. In addition, your users should never be added to the local
Let’s take a look at the other three basic roles.
DomDomain controllers in a Win2K enviro ment play sic ro
• They authenticate security
• They grant security principals
pals
As a result, domain controllers areKerberos Key Distribution Centerrunnin
nsible for g bot Dire D) a
the infrastructure. Domain controlleenvironm
ntain compromise
nsiti atio ur W
unnecessary service or applicationfewest number of administrators th
ss to dom ld be
Member Servers Member servers are the workhorsesapplications, provid
ny W nment.a
mber server
’re called
by definitio
to host
variety of disparate services and applications to function in yensure that your environment is kept secure, they should share a commconfigurations. Your typical users should never nfashion, and console acservers should be restricted from using local computer accounts and use domain acc
ompute ning theProfessional version of the OS on the deskadvantag
ps o
Win2K forest. As a result, user authenticdomain
orkstati ould oc n your
should be severely restricted, and no local admi
ser ac should b ated bey he buil
Administrators security group.
Chapter 7
222
Restructuring Roles While the three basic roles played by the co in your environment—domain controllers, member servers, and workstations—suffice for our purposes, you may find that you need to
tel del the s igurations for your the ber servers’ role into a variety of roles—
s s, and re ess
mber of ways that you can slice the functionality of your Win2K environment. But c uters ba m ty a
y concerns. Obviously, operational issues and cost constraints will sometimes require c lity onto com t the
les for separate computers can make security configuration in your environment much
urity Regardless of the other roles you require in your environment, there will always be a core set of
tant on all of the computers in your environment. It doesn’t make
De iIdentifyof detersets of
• 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 isn’t necessary to configure it in one of the computer-role policies. However, if the setting isn’t configured in the domain security policy, you need in most circumstances to configure it in each computer-role policy.
mputers
restructure them. For example, to adequa y mo ecurity confcomputers, you may need to break apart memservers, file servers, database servers, mail
There are a nu
erver mote acc servers.
the idea is to break out the functionality onfunctionalit
omp sed on com on securi nd
you to combine the roles of two sets of funseparate ro
tiona a single puter, bu notion of
easier to deploy.
Identifying the Fourth Role—Overall Domain Sec
security settings that is conssense to replicate these common settings across multiple security-configuration mechanisms. As a result, in addition to the three roles above, it’s valuable to create a fourth role—overall domain security.
fin ng Security Settings ing the roles of the computers in your Win2K environment greatly simplifies the exercise mining their security configurations. Based on the discussion so far, I’ve identified four
configuration settings that need to be defined.
• Domain security policy
Domain controller security
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 you’re contemplating in a development Win2K forest before deploying them in your production environments.
Chapter 7
223
For Account Policy I recommend that you start with the account policy settings shown below in Table 7.3.
Security Setting Domain Security
Domain Controller
Member Server
Workstation Security
Policy Security Security Policy Policy 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 1 N/A N/A N/A Password Policy\Minimum password length 8 N/A N/A N/A Passwocomple
rd Policy\Passwords must meet xity requirements
Enabled N/A N/A N/A
Passworeve bdomain
Disabled N/A N/A N/A rd Policy\Store password using rsi le encryption for all users in the
Accoun Policy\Account lockout duration
0 N/A N/A N/A t Lockout
Account Lockout Policy\Account lockout threshold
5 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 N/A ticket
60 N/A N/A
Kerberos Policy\Maximumticket
lifetime for user N/A 7 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 5 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 I’ve made some recommendations in previous chapters, you must be very careful how you assign these privilegein your environment. I’ve seen user rights assignments built into security te
s mplates 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.
Chapter 7
224
Security Setting Domain Security Policy
Domain Controller Security
Member Server Security
Workstation Security Policy
Policy 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 acc
N/A Failure N/A N/A ess
Aud oFailure
it P licy\Audit logon events Success, N/A N/A N/A
Aud oit P licy\Audit object access Failure N/A N/A N/A Audit Policy\Audit policy change Success, N/A N/A N/A
Failure Audit P ure N/A N/A N/A olicy\Audit privilege use FailAudit Policy\Audit process tracking No auditing N/A N/A N/A Aud
Failure it Policy\Audit system events Success, N/A N/A N/A
Secfor anon
urity Options\Additional restrictions ymous connections
No access without explicit anonymous
N/A N/A N/A
permissions Secto s
urity Options\Allow server operators chedule 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 N/A N/A N/A and Interactive Users
Security Options\Amount of idle time required before disconnecting session
2 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
Chapter 7
225
Security Setting Domain Security
Domain Controller
Member
Policy Security Policy
Security Policy
Policy Server
Workstation Security
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 Send NTLMv2 efuse LM
N/A N/A N/A Authentication Level only/r
& NTLM 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 logocontrolle
N/A 0 5 5 ns to cache (in case domain
r isn’t available) Security tem mai npass o
Disabled N/A N/A N/A Options\Prevent sysnte ance of computer account w rd
Securityinstallin
Enabled Enabled Disabled Options\Prevent users from g printer drivers
N/A
Secpasswo
urity Options\Prompt user to change rd before expiration
7 N/A N/A N/A
SecurityAllow au strative logon
Options\Recovery Console: tomatic admini
Disabled N/A N/A N/A
SecAllow lodrives a
urity Options\Recovery Console: f ppy copy and access to all
nd folders
Disabled N/A N/A N/A
Securityacc t
/A N/A Options\Rename administrator <renamed N/A Noun administrator>
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
Enabled N/A N/A N/A
data (always) 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
Chapter 7
226
Security Setting Domain
Domain Controller Security
Member Server Security
Workstation Security Policy
SecurityPolicy
Policy Policy
Security Options\Secure channel: Require strong (Win2K or later) session
Enabled N/A N/A N/A
key Sec(for RIS
urity Options\Secure system partition C platforms only)
Enabled N/A N/A N/A
Secpassword to conserv
A urity Options\Send unencrypted Disabled N/A N/A N/nect to third-party SMB
ers Security Options\Shut down system imm iaaudits
Disabled N/A N/A N/A ed tely if unable to log security
Security Options Lock N/A N/A N/A \Smart card removal behavior Workstation Security Options\Strengthen default permissions of global system objects
Enabled N/A N/A N/A
Security Options\Unsigned driver inst t
N/A Do not Do not Warn but
ion alla ion behavior allow
installation allow installation
allow installat
Securityinst t
t Silently Options\Unsigned non-driver N/A Do not Warn bualla ion behavior allow
installation allow installation
succeed
Tab .
ForI recom
Securit Domain Security
Domain Controller
Member Server
Workstation Security
le 7 4: Recommended local policy settings by computer role.
the Event Log mend that you start with the Event Log settings shown below in Table 7.5.
y Setting
Policy Security Policy
Security Policy
Policy
Settings for Event Logs\Maximum application log size
N/A 10240 20480 10240
Settings for Event Logs\Maximum security N/A log size
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
Chapter 7
227
Security Setting Domain Security Policy
Domain Controller Security
Member Server Security
Workstation Security Policy
Policy Policy
Settings for Event Logs\Retain security log N/A N/A 42 42 Set s m log N/A 42 42 N/A ting for Event Logs\Retain systeSet s ethod for app t
N/A By days By days As needed ting for Event Logs\Retention mlica ion log
Set s etention method for security log
N/A Manually By days By days ting for Event Logs\R
Set s tion method for N/A By days By days As needed ting for Event Logs\Retensystem log Settings for Event Logs\Shut down the computer when the security audit log is full
Disabled N/A N/A N/A
Tab
For Restricted Groups Whenever possible, try to use restricted groups to ensure that the group memberships of some of
ups are configured appropriately. While every environment
se
n-
is
le 7.5: Recommended Event Log settings by computer role.
your more sensitive security grocreates its administrative model differently, I offer the following general guidelines:
• Domain controllers—Control membership in the Domain Administrators, EnterpriAdministrators, DNS Admins, Schema Admins, and other privileged security groups that have far-reaching access throughout your domains and forest. This will ensure that no uauthorized users creep into one of your privileged security groups.
• Workstations—Control membership in the local Administrators security group. Thwill ensure that neither local computer accounts nor domain user accounts creep into this privileged security group.
Chapter 7
228
For System Services As a general rule, don’t run any service on a computer that isn’t 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 controllers—Never 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 you’re 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!
es on workstations. Remember that they’re workstations, not servers; they don’t need to be all things to all
ForWin2Kensurinensure file systhis cha
Using
is chapter u
settings is using Group Policy. I purposefully hat it’s relatively simple to deploy the security configurations
ty ur separate
• Workstations—Never run IIS, Indexing, and other such server servic
people.
the Registry and File System provides considerably better ACLs on both the Registry and the file system. Apart from g that the defaults don’t get modified, it’s hard to make any general recommendations. To that things stay as they were originally installed, I suggest that you use the Registry and tem settings from the default predefined security templates that I talked about earlier in pter. (See “Predefined Security Templates.”)
Group Policy Now that I’ve recommended many of the security settings for your environment, I’ll turn the discussion to how to apply them. The answer that is most in line with the themes of this to use either the Security Configuration and Analysis snap-in or the Security Editor. While yocould 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 securityconstructed the roles above so tusing GPOs. For each of the four roles that I’ve defined, I recommend that you create a securitemplate that reflects the required settings in each of the roles. You can then create foGPOs 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.
Chapter 7
229
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 simplifythe security management of your enterp
rise and perform basic security audits as required. It isn’t
icy, and Kerberos policy.
• Local policies—Allows you to configure audit policy, user rights assignments, and
ttings for the main Event Viewer logs
• he
•
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 policies—Allows you to configure password policy, account lockout pol
security options.
• Event Log—Allows you to configure the se(application, system, and security).
• Restricted groups—Allows you to explicitly define the membership of security groups that you consider sensitive.
System services—Allows you to specify the configuration of installed services on tcomputers in your environment, including access control and startup options.
Registry—Allows you to specify security and audit configurations for Registry values.
• File system—Allows 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 along way to ensuring that the security configuration of your enterprise remains not only consistent but also just as you expect!
Chapter 8
230
Chapter 8: Public Key Infrastructure—Part 1
Many organizations—hopefully yours is among them—have 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. We’ll 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, we’re 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 today’s security issues are left unaddressed. Here are a few examples.
• An unauthorized person, such as a contractor or visitor, might gain access to a company’s
tion.
r. For a network-sniffing device to the network. While
• Electronic mail may be intercepted in transit—or even worse, be out-and-out spoofed.
eoretical concerns but real security risks. Not only are hackers breaking
them n of
yees; 24
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 informa
• Confidential information might be intercepted as it’s being sent to an authorized useexample, an intruder might attachsniffers 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 it’s sent over the wire.
These aren’t merely thinto corporate computer systems over the Internet, but corporate insiders—such as employees, former employees, contractors working on-site, and other suppliers—are also attacking from within. In 1998, the Computer Security Institute of San Francisco, with the participatiothe Federal Bureau of Investigation (FBI), surveyed 520 security practitioners in American corporations and other institutions; 44 percent reported unauthorized access by emplopercent reported system penetration from the outside.
Chapter 8
231
How PKI Addresses These Issues The security risks described above reveal the need for an information infrastructure that achieves higPKI
•
• ce they were sent
rce of a message so that the sender cannot later claim
of d it e used T isms listed above:
• 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.
Win2K’s built-in PKI technologies are so numerous that it’s 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.
h levels of connectivity, communication, collaboration, and commerce in a secure fashion. addresses these vulnerabilities by providing the following security mechanisms:
Authentication—Ensures that entities sending messages, receiving messages, and accessing systems are who they say they are
• Confidentiality—Ensures that only intended recipients can access messages
Integrity—Ensures that messages haven’t been altered by other parties sin
• Non-repudiation—Ensures the southat they didn’t send it.
PKI is based on the use of digital certificates. It handles the issuance and ongoing maintenanceig al certificates and enables a wide variety of digital certificate–based applications to b. he following types of PKI-enabled applications provide the required security mechan
• Secure e-mail—Enables confidential information to be shared among enterprises, customers, employees, and partners over private and public networks
• Web browsers—Prevent electronic fraud such as data tampering, eavesdropping, and masquerading
File encryption—Restricts sensitive information from unauthorized individuals usingautomatic
Chapter 8
232
Understanding Cryptography
s
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 I’ll focuon 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; it’s been traced back 4,000 years to the ancient Egyptians. Using secret key cryptography, parties involved in communications share a single secret—namely, a key that use to encrypt and decrypt messages. To agree on this key, the parties must obviously have out-of-band method of communication that they consider secure. A large number of secret key
they an
To give you a better idea of how secret key cryptography can be used to protect data as it travels over a network, let’s look at an example. Let’s 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 they’ll use to encrypt all of the messages they send to each other and which secret key cryptographic method they’ll use. This is illustrated in Figure 8.1 below.
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).
Chapter 8
Figu protect data as it travels over a network.
To ay that Alice and Bob agree on key K and the XYZ algorithm.
ssage to Bob, she runs the plaintext message M through
e
e.
As I mentioned in the discussion of Kerberos in Chapter 4, it’s possible to construct systems for se urely communicating over public networks that only use secret key cryptography.
calability issues and must rely on storing many ’t discount secret key cryptography just yet; it’s much
y Cryptography cret key cryptography h public key cryptography
ric key ccryptography was first conceived tin Hellman back in 1976, and in
ir, a g the first practical realization of a RSA cryptosystem.
ber of public key cryptogr en proposed, including the ElGamal nd a whole slew o
re 8.1: Using secret key cryptography to
keep matters simple, let’s sHere is how communication occurs between them.
1. When Alice wants to send a methe 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 won’t be able to recover the original plaintext because sh(hopefully) doesn’t 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 Alic
cUnfortunately, such systems typically run into ssecret keys on a centralized server. But donfaster than public key cryptography and definitely has its place in PKI.
Public KeWhile se as been around for many centuries,(also known as asymmet ryptography) is only a few decades old. Public key
by Whitfield Diffie and Mar1977, Ron Rivest, Adi Sham nd Len Adleman took the concept one step further by producin
public key system; today it’s known as theA num aphy schemes have since becryptosystem a f elliptic curve cryptosystems.
233
Chapter 8
234
While all of the public key crypt cally unique, they share a simple property: m
ty allows d let public key to enc
original individual’s private key. o keys to encrypt and decrypt mess
ow a as it travels work, let’s go back to Alice and Bob. Unlike in the previous example, in which they
ethod they’ll orithm, as shown below in Figure 8.2.
osystems are techniUsing an encryption key, it’s covice versa). This proper
putationally infeasible to determine the decryption key (and an individual to publish his or her encryption key an
anyone use this rypt a message; this message can only be decrypted using the As you can see, public key cryptography uses not one, but twages.
To give you a better idea of hover a net
public key cryptography can be used to protect dat
needed to agree on two things, here they only need to agree on the public key mboth use. Let’s say that they agree on the ABC alg
Figu ata as it travels over a network.
the plaintext message M through the ABC encryption routine using her copy of Bob’s public key KB2. This produces an unintelligible, ciphertext
n then send the encrypted message S to Bob over an unsecured essage.
rivate
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
es using a secret key system, then encoding the secret key itself using a d
re 8.2: Using public key cryptography to protect d
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 Bob’s public key KB2. She then runs
message S. Alice canetwork without fear that an eavesdropper such as Eve will be able to read the mEve can’t recover the original plaintext message because she (hopefully) doesn’t have a copy of Bob’s private key KB1.
2. Bob runs the ciphertext message S through the ABC decryption routine using his pkey KB1. This recovers the original plaintext message composed by Alice.
As I touched
of encrypting messagpublic key system. Using this technique, the public key system transports the secret key. Anbecause the secret key is typically much shorter than the message, this technique is significantlyfaster than using only public key cryptography.
Chapter 8
235
Hash Functions Wh p s one key, cry g ary-length es. This is shown below in Fig
ile ublic key cryptography uses two keys and secret key cryptography usepto raphic hash functions use no keys. A cryptographic hash function converts an arbitr
message to a fixed number of bits using cryptography techniquure 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 better-known examples are Message Digest Five (MD5) and Secure Hash Algorithm (SHA)-1. Hash functions have the following properties:
mputationally infeasible to find two different messages that sh value
age hash value, it’s computationally infeasible to find any other
sh eed to compare two pieces of data, therefore, we can just
compare their hash values.
wing that only Alice could have encrypted the message because she is ion key. In effect, Alice has signed the message.
al
use a combination of a hash function plus public key cryptography, as shown below in Figure 8.4.
• Collision Free—It’s cocompute to the same ha
• One Way—Given a messmessage that has the same hash value.
As a result of these two properties, we can be sure that if two messages have the same havalue, they must be identical. If we n
Digital Signatures The fundamental properties of public key cryptography allow a form of message signing called digital signatures. Let’s 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, knothe only one who knows the encrypt
While this encryption method works in theory, in practice it isn’t used. Because public key cryptography is relatively slow from a computational standpoint, it’s impractical to encrypt largemessages such as Microsoft PowerPoint presentation files just to sign them. As a result, digitsignatures typically
Chapter 8
Figure 8.4: Using a digital signature to encrypt a message.
As you can see fromhashes is a two-step process.
this figure, sending the digitally signed message M from Alice to Bob using
A.
B
When public key cryptography is used in the real world, messages are encrypted and digitally
ge—A symmetric key encrypts the message, and a public key encrypts the symmetric key. This method ensures that the message is confidential.
essage is hashed, and the hash is encrypted using the private key method provides authentication of the sender, integrity of the
1. Alice runs message M through an agreed-on hash function to produce the hash value HAlice 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 H .
2. Bob uses Alice’s 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 didn’t sign the message, or it was somehow altered in transit.
Putting Cryptography into Practice
signed using a combination of the techniques discussed above. Three basic methods are used.
• An encrypted messa
• A signed message—A mof the sender. This message, and non-repudiation of the message.
• A signed and encrypted message—A 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 thtrust 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 keys—asymmetric keys. Each principal keeps one of these keys private and doesn’t share iwith anyone while making the other key, the public key, freely available to any and all othe
e
t rs.
to be?
e problems is to use a CA. A CA is a trusted third party that vouches
Even using a CA, there is one more problem: How do you locate and retrieve the certificates of r cipals 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 central repository for
s.
This isn’t 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 it’s just the two of us and we already have an existing relationship and are comfortable with each other’s identities, this can work. But let’s say that you collect the public keys for twenty other people; how will you keep them straight? And what if someone you’ve never met needs to communicate securely with you; how will you be sure that they are who they claim
The solution to both of thesr andfor the identity of a use 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 principal’s public key using its private key. Before signing, the CA also loads the certificate using information that identifies the principal.
p in
overhead of retrieving certificates manually, PKI generally includes a 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 principalFigure 8.5 shows the basic components of PKI.
.5: The basic comFigure 8 ponents of PKI.
237
Chapter 8
238
Ce iA certisecurity some other information. A certificate’s basic function is to ver tpubli date, anissued by th s the certificate.
hen you request one of the oagencyyou’re in fact you, and issues the ID. For example, a driver’s license typically contains the foll i
• hair
•
entity. A certificate cannot contain things like
your signature, photograph, or physical characteristics. Instead, it’s a virtual indication of who the digital signature that the CA places on the certificate.
rtif cates ficate is a digital binding of a public key to an individual, computer, application, or other principal, combined with
ify hat a public key belongs to a specific principal. At a minimum, a certificate contains a c key and a name, and it also typically contains things like a serial number, an expiration
d the name of the CA that issued the certificate. To prove that the certificate really was e CA, the CA also digitally sign
Think of a certificate as similar to your passport or driver’s license. Wse f rms of identification (ID), it’s issued by a recognized authority, typically a government
. The agency verifies that you meet the specified requirements of the ID, verifies that
ow ng types of information:
Personal information to help identify you, such as your height, weight, eye color, and color
Your photograph and signature
• The issuing authority.
In addition, a driver’s license is designed to be tamper-resistant. When you present it to others, they can use it to verify your identity.
Just like a driver’s license, a certificate is issued by a trusted third party—namely, a CA. The CAprovides the proof required to verify your online id
you are; this can be verified in
The overall structure of a certificate has been standardized to ensure that your virtual ID card canbe 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.
Chapter 8
239
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 certificate’s 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 Authority’s Digital The CA’s digital signature of the rest of the certificaSignature
te.
Table 8.1: Some of the fields in the X.509v3 certificate.
Certificate Authority Because of its importance in PKI, it’s 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 performonly a few basic services to manage a
s certificate’s life cycle. It:
re 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. I’ll 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.”)
• 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 befo
Chapter 8
240
Certificate Repository b of a CA is simple, the role of a certificate
ications in depth in Chapter
rk user accounts
• Digitally signed software that ensures the authenticity and integrity of the software you
Such
I’ll look at each of these trust models, briefly discuss their advantages and disadvantages, and t the appropriate chains of trust by
While from a technology perspective the jorepository is even simpler. Most PKI implementations today publish both issued certificates andCRLs into LDAP-accessible directory servers. This allows certificates and CRLs to be widelydisseminated 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 certificaterepository.
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 I’ll discuss all of the Win2K PKI-enabled appl9, I’ll 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 netwo
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.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.
present a realistic picture of how you might construcdeploying PKI-based technologies.
Chapter 8
Cross-Certification Cross-certification is arguably the simplest trust model, and it’s the model that most customers use today. The reason it’s been so widely adopted is that it was really the first mechanism usedbuild trust relationships among issuing CAs. W
to hile there are several cross-certification
mechanisms, bilateral cross-certification and the newer certificate trust lists (CTLs) are the most interesting.
in Fig
prevalent and
Bilateral Cross-Certification In a bilateral cross-certification operation, CAs cross-certify each other by signing each other’s public keys. This creates a cross-certified trust relationship, or cross-certificate, as shown
ure 8.7 below.
Figure 8.7: In bilateral cross-certification, CAs cross-certify each other by signing each other’s 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 Alice’s credentials and vice versa. Because Bob’s CA has signed the certificate containing the public key of Alice’s CA, Bob can trust Alice’s CA and hence Alice’s certificate. And because a bilateral cross-certification trust relationship has been set up, Alice can also validate Bob’s digital credentials.
Intermediate CAs may destroy a trust relationship by revoking cross-certificates, so it’s 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, it’s 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 cross-certification 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 other’s 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
243
A hierartrust is created by having a CA create a certificate containing the certified public keys of other
s. The resulting certificate points up a hierarchy to create a certification path between two rs. The top-most CA in a hierarchy is called the root CA because it provides the root of the
chy contains multiple CAs with clearly defined parent-child relationships. The chain of
CAusetrust relationships in the hierarchy.
ilateral Cross-Certification” above, let’s say that Bob needs to credentials and vice versa. As illustrated in Figure 8.8, Alice trusts CA A, while
A
this case, the root CA) provides the mechanism that allows Bob and Alice to trust
ing
• Organizational divisions—Different divisions in an organization may require different icates. Again, multiple issuing CAs can be used to separate and
, alance between security and
ome people believe that o
Going back to the example in “Btrust Alice’sBob 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 and B, Alice and Bob can construct a chain of trust to CA C, which they both trust. This common authority (in each other’s 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:
• Use—Certificates 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 issupolicy for these uses to be distinct, and separation provides a basis for administering these policies.
policies for issuing certifadminister these policies.
• Geographic divisions—Divisions 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 protectionprotection against network attacks, and so on) to tailor the busability
• 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, sthey should be avoided because of their complexity. They believe that it’s unreasonable tassume that everyone needing a certificate will trust one authority. And compromising the root CA key puts the entire hierarchy at potential risk.
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 Asho e
C . Because everyone trusts the hub CA, the chain of trust in the community is relatively rt; veryone is one trust relationship away from everyone else.
Figure 8.9: In a community of interest, a hub CA manages centralized trust relationships.
of-intere the tion and hierarchical le trying to mitigate many of the disadvantages of both. Everyone in the community has t in doing busin ach other an
ral cross-certification with the huto be business-driven and relatively simple. The egins in an organization and
parties within the community. Ud hierarchy that offloads the com
hence, trust becomes more scalable.
his trust model is still relativelyproblems associated with cross-certification and rarchies. Issues also abound with
plicability of the m ust network cre es rust also dilute it? Despite the unknowns, organizations such as the Automobile
hange (ANX om (a subsid n, or Securities Industry Root Certificate Authority (SIRCA) are examples of early
se this trust m
The community-trust, whi
st model leverages benefits of cross-certifica
an interesThey use bilate
ess with e d thus has an interest in creating relationships. b CA to create those relationships, allowing trust chain of trust b
extends to third creates a limite
sing the hub CA as the root, the community also plexity of maintaining multiple relationships;
Unfortunately, t new and isn’t immune to the interoperability certificate hie
the apextending the t
eshed tr ated by the hub CA. For example, do
Network ExcABA), and the
), ABAec iary of the American Bankers Associatio
efforts to u odel.
244
Chapter 8
245
Re mAs s iness needs h re, you’ll like u ess processes, I
st
astructure. As long as these business relationships remain strategic and healthy, it’s advantageous to maintain the high levels of trust
e advantages of joining a community of interest will xponentially larger group
of trust relationships. This will allow your company to leverage the community’s relationships and join other communities and hierarchies.
s, al and external
co mended Trust Relationships hould be evident by now, trust relationships aren’t a one-size-fits-all proposition. Bus
ave to drive the trust relationships that you use in your organization; therefoly se a combination of trust models and relationships. For internal busin
recommend that you consider a closed certificate hierarchy to provide trust relationships withinyour corporate boundaries.
Outside the corporate walls, initial trust relationships with customer segments will more thanlikely take a hierarchical form. You’ll probably need to use cross-certification with your closebusiness partners because they may have their own CA infr
that only one-on-one relationships can create.
As your company uses digital certificates, thlikely outweigh the disadvantages, and you can consider linking to an e
with other communities and organizations
Simply put, how a company builds trust relationships is closely related to how it does business. Over time, it’s conceivable that your organization will issue certificates to employees, supplierbusiness partners and retail customers, creating a secure foundation for all internbusiness transactions. Figure 8.10 illustrates how such a future deployment may look.
Figure 8.10: How your company may deploy future trust relationships.
Chapter 8
246
Even if your organization’s trust relationships don’t end up looking like this, a couple of things out. The first is the complete separation between intranet and Internet PKIs,
The second interesting thing is th an Internet PKI. This mix is inev b n uses will need to contend with it. Thus, any t ts capabilities than an intranet deployment so that it can adapt to any trust relationship your conduct its business.
This e f the iceberg, and the issues that surround esta is opefully, I’ve made you awa o technical issues that you must consider when you create such trus e compliance issues, I hope I’ve mad it y consider the domino effect that creating trust rela n
Certificates Jus a certificate doesn’t necessarily mean that you should trus .exp dfake dr o there are fake certificates. We know that driver’s licenses exp a ions are vio d
Val aThe r e is perform a validation check to e u certification path. Figure 8.1 h certificate might be invalid or n t wing:
blished CRL
• The issuing CA isn’t part of a trusted certification hierarchy or contained in a CTL
• The root CA for the certification path isn’t a trusted root CA
• The certificate isn’t permitted to be put to the use specified in the certificate.
are worth pointing 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.
e mix of trust models used in ita le, and any Internet PKI that your organizatio
In ernet PKI effort must be more flexible in i organization needs to
d scription of trust models is really just the tip obl hing trust relationships among CAs are many and complex. Hre f some of the high-level t r lationships. While I haven’t talked about policy, legal, ore clear that your organization must carefulltio ships can have on your PKI infrastructure.
Validating and Revokingt because someone presents you with t it The certificate may be a forgery, may come from someone you don’t trust, could be ire , or could be revoked. I’ll use the driver’s license analogy again. Just as we all know that
iver’s licenses are available, sire nd must be renewed and that they can be revoked when motor vehicle regulatlate ; the same holds true for certificates.
id ting fi st thing that PKI users need to do after receiving a certificatns re that any certificates involved in a transaction have a valid 1 s ows a number of checks carried out to validate a certificate. Aot rusted for a number of reasons; these include, but aren’t limited to, the follo
• The user’s name has changed
• The start and expiration dates are improper or expired
• The certificate format isn’t correct
• The information contained in the certificate is incorrect or incomplete
• The certificate’s digital thumbprint and signature fail integrity checks
• The certificate is listed as revoked in a pu
Chapter 8
247
Figure 8.11: Some of the checks carried out to validate a certificate.
Keep in mind that in Win2K’s 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 doesn’t invalidate the entire path. For example, a third-party CA might issue a certificate that specifies a lifetime that extends beyond the CA certificate’s expiration date. When the CA’s 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.
Chapter 8
248
While a third-party CA might issue a certificate that specifies a lifetime beyond the expiration date of the CA’s certificate, a Win2K CA never does this. For example, if a CA’s 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 intransaction haven
a ’t been revoked. For example, a certificate is revoked when a user has left an
the
with. Most CAs can be configured to
. As a result, an issued cert c citly enfor e . For exa a certificCA’s cJanuaryissued
If a CA request to issue a one-yea e ly 31, 2 02001, t
As a re ary 1, 2005January tes; instead, it truncates the end date to January 1, 2005. Likewise, after January 1, 2004, the CA truncates the
You the constraints imposed by nested validity dates. As a result, look at your CA hierarchies regularly and ensure that you aren’t needlessly limiting the lifetimes of any of your issued certificates.
organization or when a user’s private key has been compromised. Certificates are revoked by 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 canimagine, 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 CRLcan ensure that it’s genuine and hasn’t been tamperedperiodically 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
ifi ate expires before the CA certificate expires. As I discussed above, Win2K CAs explic nesting and don’t issue a certificate beyond the expiration date of the CA’s certificate
mple, if the end date of a root CA’s certificate is January 1, 2010, no child CA can issueate with a date later than January 1, 2010. Similarly, if the end date of an intermediate ertificate is January 1, 2006, no child CA can issue certificates with an end date later than 1, 2006. If the end date of an issuing CA’s certificate is January 1, 2002, no certificate
by the CA can have an end date later than January 1, 2002.
’s certificate has an end date of January 1, 2002 and it receives a r c rtificate on August 1, 2000, the CA issues the one-year certificate with an end date of Ju
0 1. However, if the CA receives a request to issue a one-year certificate on August 1, he CA issues the certificate with an end date of January 1, 2002.
sult of this strict nesting, a CA with a certificate lifetime of five years expiring on Janu, can issue one-year certificates until January 1, 2004, or two-year certificates until 1, 2003. After January 1, 2003, the CA no longer issues two-year certifica
end date of both one-year and two-year certificates to January 1, 2005.
typically want to renew CAs with new CA certificates before they’re bound by
Chapter 8
249
Choosing Certificate Life Cycles There are a number of things that you need to consider when choosing the lifespan of certificin 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 keys—Longer keys are harder to brute force; therefore, they support longer key lifetimes.
• Storin
ates
g private keys—The stronger the security provided for private keys, the longer es
data-center environment can allow you to choose longer certificate
s. In general, stronger cryptographic
technology supports longer key lifetimes.
ffers reasonable suggestions for choosing key tim
te Has
you can set the lifetime. In general, storing private keys in specialized hardware devicgives them longer key lifetimes than storing private keys on disk.
• CA security—The 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 lifetimes.
• Cryptographic strength—Some cryptographic technologies provide stronger security aswell as support for stronger cryptographic algorithm
• Administrative effort—The shorter the certificate lifetimes, the more often you have to renew certificates.
• Nesting certificate lifetimes—The deeper the nesting you deploy, the more careful and restrained you’re going to be in choosing certificate lifetimes.
Overall, choosing certificate lifetimes becomes a tradeoff between the risks you’re willing to take and the amount of administrative overhead you’re willing to put into your PKI. While there are no hard-and-fast rules, Table 8.2 below olengths and certificate life es for a typical organization.
This CertificaPurpose
This Lifetime And This Renewal Policy
Root CA (4096-bit keys)
20 y every 9.5 years to ensure that you can Renew with a new key pair
.
ears Renew the CA issue 10-year certificates. every 20 years
Intermediate CA (3072-bit keys)
10 y .5 years to ensure that you can ue 5-year certificates. Renew with a new key pair
ears Renew the CA every 4issevery 10 years.
Issuing CA (2048-but keys)
5 ye n w with a new key pair
every 5 years.
ars Renew the CA every 2.5 years to ensure that you caissue 2-year certificates. Rene
User 1 year Renew with a new key pair every year. (1024-bit keys) 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.
Chapter 8
250
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) don’t 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. It’s 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, it’s wise to carry out the two tasks above to ensure that you’re 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:
anage certificates
• Describes a CA’s criteria and process for validating and approving certificate requests, RLs, and liabilities if an issued certificate is misused.
the se
or a
• Specifies the practices and processes that the CA uses to issue and m
revoking certificates, publishing C
Commercial CAs commonly publish their CPS on their Web sites. As a result, you can readCPS to find out what practices the CA follows to issue various types of certificates, for what uthey authorize their issued certificates, and their liability when a certificate is compromised 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. I’ll 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.
Chapter 8
251
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 CA’s certificate before it expires.
I’m not a lawyer, don’t play one on TV, and never play one when I’m ensuring the security of the organizations I work for. Although the things I’ve listed above seem technical, don’t be fooled: A CPS is all about limiting corporate liability if something goes awry, so it’s therefore more the work of lawyers than security professionals. This is especially true for those of you who work in larger, multinational corporations.
Chapter 8
The E-Sign Act Another legal issue you may need to grapple with are the effects of the Electronic Signatures iGlobal and National Commerce Act (also known as the E-Signature Bill), which took effect iOctober 2000. The E-Signature Bill gives digital signatures legal status at the federal levelUnited States. It supersedes more than 50 laws at the state level as well as laws in other countries. But it doesn’t address issues of liability, and it doesn’t even mention PKI or define digital signature in the manner I’m discussing.
So we still don’t know h
n n
in the
ow courts will apply the law in situations where an organization or
m
it’s time to talk about more out the P K. The components of the Win2K PKI are shown in
re 8.12 and describ
individual is affected by PKI-related frauds. For example, we don’t know who’ll be held liable when a VeriSign-issued certificate is used to perpetuate fraud: VeriSign or the entity to whothe certificate was issued. In the interim, you’ll have to rely on contracts to explicitly spell out your organization’s expectations.
The Windows 2000 PKI Now that I’ve covered somspecifically ab
e of the basics of PKI and how it works,KI offered in Win2
Figu ed below.
Figure 8.12: The components of the Win2K PKI.
s
d make use of the basic cryptographic services provided by the operating system (OS).
Applications and services—Most of the PKI applications and services will be deployed acrosboth 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. They’re designed to interact with each other an
252
Chapter 8
253
Certificate stores—All of the keys and certificates are stored on behalf of the users, computers, a cryptographic service provider supplied by either Win2K
are
ave 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
matic certificate issuance for the computers in
.
AD—AD 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 CA—Is 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 CA—Stands apart from the rest of your enterprise to perform generic CA functions. A standalone CA doesn’t use certificate templates and doesn’t 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, they’re placed in a queue of pending requests that must be manually approved by a CA administrator.
and services in your environment inor a third party. These certificate stores also include all of the trusted CAs. Certificate storesused by the PKI-enabled applications and services to store and retrieve the required keys and certificates.
Security administration—The 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 policy—Not only do you h
your enterprise. In addition, you can control autoyour environment and some basic PKI-related policies using Group Policy Objects (GPOs).
Certificate server—Win2K implements the functions of a CA using a built-in certificate serverMore 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.)
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.
Chapter 8
254
Standalone CAs aren’t 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 incu a en usemanaged is relatively low.” I agree with this; a root CA and any subordinate CAs that don’t issue cert cyou to keep these CAs offline and protect them from potential attack from within your env n
Mic sben t ted certificate approval and automatic computer certificate enrollment.” I couldn’t agree more because being able to control certificate
ontrol lists (ACLs) on certificate templates within AD creates an easy-to-
andalone CAs, so in the rest of this section on the Win enterprise CA works, a standalone CA is pretty easy to figure out.
Ce iCertificate templates are nothing more than profiles that define what fields will be contained in cert c plates contain fields that can be pulled from can also contain information such as E i ally defined by its inte e is intended to be used for S/MIME e-m
rs high administrative cost. Microsoft seems to recommend standalone CAs for use “whrs don’t have Windows 2000 accounts and the volume of certificates to be issued and
ifi ates directly are great candidates for a standalone CA. This type of configuration allows
iro ment.
ro oft also recommends “that you install most issuing CAs as enterprise CAs to gain the efi s of integration with AD, including automa
issuance using access cadminister environment.
Enterprise CAs are more complicated than st2K PKI, I’ll discuss how to run and administer them. Once you know how an
rtif cate Templates
ifi ates issued by an enterprise CA. Certificate tem AD, such as Requestor Name and E-mail Address. Theyxp ration Time and Certificate Use. In fact, each certificate template is rend d use. For example, the certificate template for standard users is called User and
ail, 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.
D, and it’s easy to access them using the Active Directory d
Certificate templates are stored in ASites and Services MMC snap-in. Open the snap-in and choose View>Show Services. Expanthe 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.
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 you’re 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 they’re issued.
256
Chapter 8
257
Policy Modules An enterprise CA policy module always issues a certificate, or denies a request, immediately. Enterprise CA policy uses the native Win2K authentication mechanisms—Kerberos 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 beinrequested by consulting the certificate template ACLs. If a certificate template h
g as both Read and
uest
ns: CRL
can
Enroll permissions for the requestor, the certificate is immediately issued; otherwise, the reqis immediately denied.
For each certificate the policy module issues, it also adds a couple of X.509v3 extensioDistribution 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 CA’s certificate is published. Each of these records includes one or more URLs, whichspecify 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 are used by the CA after certificates are issued. Their main job is to publish the cert c lly specify the distribution of a certificate to AD, the local file system, or a URL. Exit modules also deliver CRLs to CRL dist u ule for enterprise CAs publishes both certificates and CR t
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.
Exit Modules
ifi ate in the appropriate location. Certificate requests can optiona
rib tion points. The default exit modLs o AD.
Installing Certificate Services Before you install Certificate Services, you first need to make sure that you have the required
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 AD—particular, Write permission on the Public Key Services node in the Active Directory SiteServices MMC snap-in. As a result, it’s often easiest to install an enterprise CA as an Enterprise Administrator. However, your organization may not want to assign Enterprise Administra
in s and
tor righ t le for installing and administering your enterprise CAs. As a result, you’ll have to assign W ission to the Public Key Services portion of AD to you n
Us omponents Wizard
he Certificate Services check box, then click Next to launch the W ndows Components Wizard. Use the Certification Authority Type dialog box (see Figure 8.15 below) to specify the enterprise CA type for your particular installation.
ts o administrators who are responsibrite perm
r e terprise CA administrators.
ing the Windows COnce 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 t
i
Figure 8.15: Using the Windows Components Wizard to select an enterprise CA type.
258
Chapter 8
259
The key to installing Certificate Services is to select Advanced Options in this dialog box, then
(CSP) that the CA will use for its cryptographic
• commend that you use the default
tion y)
SpIf you’re 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
requesting. In fact, the lifespan of a subordinate CA expires
an ans.
configure the following items:
• The Cryptographic Service Provider operations
The hash algorithm to use in signing certificates (I revalue, which is SHA-1)
• An existing key pair to use when you’re restoring a CA from backups
• The length of the public and private keys.
Describing the CA As you configure Certificate Services, you’re prompted for information to identify the CA. This includes, but isn’t limited to, the following:
• CA Name—The name of the CA (for example, ABC Company root CA)
• Organization—The legal name of your company (for example, ABC Company)
• Organizational Unit—The department responsible for the CA (for example, InformaSecurit
• Locality—The city where the CA is deployed
• State or Province—The state or province where the CA is deployed
• Country—The two-character code for the country where the CA is deployed.
ecifying the Lifespan of the CA Certificate
specify the lifespan of the certificate you’reis determined by the remaining lifespan of its parent CA. For example, if the parent CAin seven years, the lifespan of a subordinate CA will be set to expire in seven years. This cobviously play havoc with setting expiry dates for appropriately nested certificate lifesp
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, you’re 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, you’re 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.
Chapter 8
260
Administering Certificate Services To administer Certificate Services in Windows 2000 Server, Microsoft provides three tools.
• Certificate Services MMC Snap-in—Allows 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.
• CertReq—Allows you to request certificates from CAs.
• CertUtil—Allows 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 private-public key pair. If you’re 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. It’s meant to be run only by developers and extremely knowledgeable Certificate Services administrators.
Hardware Protection of Private Keys
way: The
s!
isk dr ve 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
ronments, this could result in the theft of company assets, including money and/or confidential information.
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 thisconsequences of compromising a user’s key are nowhere near as severe as compromising the private key of one of your CAs. Compromising a user’s private key affects only one user; but compromising your root CA private key compromises your entire PKI. It affects everyone inyour certificate hierarchy—your users, computers, and potentially your suppliers and partner
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 computer’s disk drive. For example, a private key stored on a d
i
banking or other financial services envi
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)
Chapter 8
261
Summary The first step in understanding how PKI functions is understanding the basic cryptographic techniques that the infrastructure is based on—namely, secret key encryption, public key cryptography, hash functions, and digital signatures. As you’ve provide an online environment that establishes the
learned, PKI is intended to trust of identities and to manage the related
s
I hope that you feel comfortable enough to create a PKI for your organization and that you’ll come back to read Chapter 9, where I’ll discuss Win2K PKI components in detail.
cryptographic keys that form the basis of an online identity. CAs, CRLs, and trust relationshipare just some of the components required to build a fully functional PKI.
In this chapter, I’ve concentrated on describing the core principles of PKI and how Win2K implements Certificate Services to fulfill the role of a CA. You’ve 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.
Chapter 9
262
Ch p
Back in ow they work. I described the basic cryptographic techniques that the infrastructure is based on—sec k PKI is to manage
In that revocatfully fuimplemconfiguis easy nd fully integrated with your Active Directory (AD) infrastructure.
But there is more to PKI than just theory and CAs. What I didn’t 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. I’ll describe how to successfully issue and use certificates in your environment. I’ll cover issuance mechanisms, and I’ll describe the applications and protocols available to you—how they work and how to deploy them to be successful and avoid problems down the road. When I’m done, you should understand how to successfully manage and deploy the PKI solutions delivered as part of Win2K.
Managing Certificates Once you’ve installed a CA or two in your environment, you need to be able to issue certificates to users, computers, and applications. In this section, I’ll 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 you’ve issued certificates appropriately, your users can take advantage of a wide variety of digital certificate–based applications and protocols built into Win2K, including Outlook Express, Internet Explorer (IE), the encrypting file system (EFS), and Internet Protocol Security (IPSec).
a ter 9: Public Key Infrastructure—Part 2
Chapter 8, I discussed the key components of public key infrastructure (PKI) and h
ret ey encryption, public key cryptography, hash functions, and digital signatures. I said thatintended to provide an online environment for establishing the trust of identities and the related cryptographic keys that form the basis of an online identity.
chapter, I also said that components such as certificate authorities (CAs), certificate ion lists (CRLs), and trust relationships were just some of the things required to build a nctional PKI. I concentrated on the core principles of PKI and how Microsoft ented its Certificate Services to fulfill the role of a CA. You learned how to install, re, and maintain an enterprise CA so that you can create a PKI for your organization that
to administer a
Chapter 9
263
Configuring Group Policy Settings In a ryou canCompu ure 9.1. Because these settings are comand not
•
es is important to effectively manage the certificates that you can use and trust in your environment.
G oup Policy Object (GPO), there are a number of public key security policy settings that configure to help manage certificate use in your environment. They exist under the ter Configuration node, as shown below in Fig
puter policies, you can only use them to define policy for computers in your environment 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 polici
Figure 9.1: The public key settings of Group Policy.
Chapter 9
264
Encrypted Data Recovery Agents The Encrypted Data Recovery Agents policy isn’t really a specific policy for the Win2K PKI;
EFS. This more
bled and can be used on computers within the ithin ter.
ted to the operation of a computer, such as IPSec, Web, and client authentication. This policy cannot be used in any way
Using the Autom y to issue certificates to all of the computers in your environment; otherwise, you’d have to manually request certificates for each one. If you have more than a handful of computers, that might take a while.
instead, it’s a policy about a specific client of Win2K that relies on digital certificates: policy controls how EFS is used in your environment. If the policy is defined using one orcertificates for your recovery agents, EFS is enascope of the GPO. If the policy is defined but empty, EFS is disabled on the computers w
pe of the GPO. I’ll talk more about this policy and the use of EFS later in this chapthe sco
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 rela
to issue any certificate type that the users in your environment will use.
atic Certificate Request Settings policy is the easiest wa
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 isn’t 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 es of
are allowed to add CAs of their own choosing to their list of trusted CAs
ers,
While you should use the Trusted Root CAs policy for CAs in your environment, you’ll 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.
The Trusted Root Certification Authorities and Enterprise Trust policies define three typcertificate trust issues in your environment.
• Which root CAs are trusted (remember, if you don’t trust a root CA, you won’t be able to verify the certificate as authentic and won’t trust it)
• Whether users
• The acceptable key usage for the certificates for each of the defined CAs.
When you install an enterprise CA, you’ll notice that it’s 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-MicrosoftCA, you need to add the root CA certificate to the Trusted Root CAs’ policy so that your uscomputers, and applications can validate certificates issued from these CAs.
Chapter 9
265
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, let’s 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, you’d 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, you’ll 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, co puters, and applications. The Certificates MMC snap-in is shown below in Figure 9.2. m
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.
Chapter 9
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 isn’t 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, you’ll see a page similar to the one shown
Figure 9.3: The Certificate Request Wizard.
below in Figure 9.4.
266
Chapter 9
eb pages are the only real interface for a standalone CA, they’re
inte 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.
Services Web pages is pretty simple and self-explanatory.
the Web by specifying some of the options yourself instead of using default values.
quest to a PKCS #10 file.
• Check on a pending request—While an enterprise CA will issue or deny a certificate users need to check the status of a pending request that has been submitted
Figure 9.4: The Certificate Services main Web page.
While the Certificate Services Walso the most feature-rich mechanism for retrieving certificates from an enterprise CA. The Web
rface allows you to set optional request features that aren’t
Overall, using the CertificateHowever, I want to go over the basic tasks that you can perform using this interface so that youhave some understanding of the capabilities available to you. You can perform the following tasks:
• Submit a basic certificate request—Submit 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 request—Submit an advanced certificate request over
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 re
immediately,to a standalone CA. If the certificate has been issued by the authority, users can download and install it.
267
Chapter 9
268
• Retrieve the CA’s certificate—Retrieve the certificate of the CA itself.
• Submit a request using a file—Make certificate requests using existing PKCS #10 and
ogging on using smart cards (see
are built into Win2K, the Certificate Services We aserious ificate Services, I urge you to become familiar with how thes s that o or request
chanism 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 /?
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 certificate—Request a certificate for a smart card on behalf of another user. I’ll talk more about this when I talk about l“Issuing Smart Cards”) later in this chapter.
While other mechanisms to request certificates b p ges will probably be used most often in your environment. Consequently, if you’re
about deploying Microsoft’s Certe Web pages function. I also urge you to consider modifying the pages to eliminate function y ur user base doesn’t require—for example, so that you give your users only one option f
ing a certificate.
Using CertReq.exe The final me
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 - Base64-encoded X-509 output file name CertChainFile - Base64-encoded PKCS7 output file name
Chapter 9
269
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" Example: "Name1: Value1\n Name2: Value2" C:\>
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 you’ll notice as you play with Certificate Services is that RequestIDs are sequential, starting with a value of 2. (RequestID 1 belongs to the CA’s certificate!)
Sending and Receiving Secure Email PKI-enabled secure email clients have been available for a number of years now, but they’ve yet to really catch on. Clients such as Qualcomm’s 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 messarecipient(s) have the
ge hasn’t been modified in transit; encryption ensures that only the intended ability to read a message.
odified in transit. Recipients can also decrypt encrypted email
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 most-supported 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 hasn’t been mmessages that were destined for them, but not those intended for others.
Chapter 9
270
Configuring Outlook Express B fore explaining how to send security-enhanced email messages from Outlook Express, I want
onfiguring Outlook Express to send y. First, I’ll assume that you already have Outlook
se as
eto step back and take a look at its configuration options. CS/MIME email messages is actually pretty easExpress appropriately configured to send and receive email. I’ll also assume that you’ve 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, you’re all set to send secure email messages!
To configure Outlook Express to send S/MIME email messages, run the application, then chooTools>Options. In the Options dialog box, click the Security tab. The Security page appears,shown below in Figure 9.5.
Figure 9.5: Configuring Outlook Express to send S/MIME email messages.
Chapter 9
271
Under Secure Mail, you can set three configuration options.
• Tell Me More—Displays some basic Help information about how to use the secure email capabilities of Outlook Express.
• Digital IDs—Displays 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 ID—Takes you to a Web site hosted by Microsoft that points the way to third-party CAs, where you can obtain digital certificates if you don’t 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 I’ve 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.
Chapter 9
272
Sending S/MIME Messages red Outlook Express to your liking, sending a security-enhanced email
age, all you need is your own
After you’ve configumessage 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 you’ll recall, to digitally sign a messdigital 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, Outlostored in your Conta
ok Express requires that you have a copy of the recipient’s digital certificate cts folder. If you already have the certificates for all of your intended
the message, right-click the name of the sender and choose Add to nd their digital certificate to
m both
recipients, you’re 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 receiveAddress Book from the shortcut menu. Then add the user athe Outlook Express Contacts folder.
Once you have your intended recipients’ digital certificates, you’re ready to send thesigned 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.
Chapter 9
273
How the EFS Works he EFT S is a personal file-encryption mechanism that is embedded in the Win2K kernel. EFS
to enable users to encrypt individual NT file system (NTFS) files as well d
pective as a user, EFS works transparently by encrypting and decrypting y policies
ter.) encrypted files when necessary. Finally, EFS
ore, and transfer encrypted files without decrypting the protected data.
uses PKI technologiesas entire folders, including all subfolders. (From now on, when I say files, I mean files an
lders.) From your persfofile reads and writes to NTFS volumes. As you’ve seen, you can establish data recoverusing the functionality of GPOs. (See “Encrypted Data Recovery Agents” earlier in this chapA data recovery policy allows you to recover allows you to back up, rest
The data recovery feature of EFS only recovers encrypted files. It doesn’t disclose the user’s private key that was originally used to encrypt the files. As a result, there is no requirement to escrow a user’s private keys!
Encrypting Files Now that you know something about EFS, I’ll dive in and discuss how it operates. As mentioned
logies to encrypt files. As you might recall from the
e,
ng blic key of each specified recovery agent. If
multiple recovery agents are specified, the header of the file contains multiple DRFs.
gh the
above, EFS is based on PKI technodiscussion of cryptography back in Chapter 8, one of the major disadvantages of public key encryption is that it’s 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 uniqurandom 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 usiyour public key, it encrypts it using the pu
To understand how all of this really works, take a look at Figure 9.8 below, and I’ll step throuprocess.
Chapter 9
274
.8: How EFS encrypts files. Figure 9
Onc ythe DatencryptFEK an only yoof the pcomplete, EFS stores th of the original file.
RecovWhile tWhat isyou won’t be able to decrypt it when you need ple, you could lose your private key, you mamistake u may los ou can eith
Obviou er the priv user accreate o e appropriate certificates.
Onc y u can useit befor access SettingThis is shown below in Figure 9.9.
e ou select to encrypt the contents of a file, EFS generates a unique FEK for the file using a Encryption Standard (DESX) algorithm. The FEK in turn is used to symmetrically the plaintext contents of the file to produce a ciphertext version of the file. To protect the d allow it to be used when the file needs to be decrypted, EFS encrypts the FEK using notur public key but also the public key of each recovery agent. The public key encryption rivate key creates the required entries for the DDF and DRF. Once all of the encryption is
e DDF and DRF headers with the ciphertext version
ering Files he concept of a recovery agent has been touched on many times, why is one needed? it? How do you use it? When a file is protected using EFS, there is always the risk that
it. For examy need to recover the file of someone who has left the company, or someone else may nly encrypt one of your critical files! These are just a few of many possible ways that yoe access to a file after it’s been encrypted using EFS. To work around the problem, yer escrow the encryption keys, or you can use recovery agents.
sly, Microsoft decided to use recovery agents in EFS to recover encrypted files whenevate key of the user who encrypted the file is unavailable. To do this, EFS uses standard
counts that are whose key usage is specified as an EFS recovery agent. You’ll need to ne or more user accounts that you want to act as EFS recovery agents and issue them th
e ou’ve decided on your recovery agents and issued them the appropriate certificates, yo a GPO to establish these recovery agents for your environment. Although I’ve discussed e, it bears repeating that to configure the recovery agent policy for your environment, youthe appropriate GPO(s). In Group Policy, select Computer Configuration, Windows s, Security Settings, Public Key Policies, then click Encrypted Data Recovery Agents.
Chapter 9
Figu
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
embers of a domain, the default recovery policy configures the f the initial domain controller to act as the recovery agent for the
re 9.9: Configuring EFS recovery agent policy.
above, for computers that are mlocal Administrator account odomain. For standalone computers, the local Administrator account is configured to act as the recovery agent for the computer. In either event, you don’t 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
can only
not going to have the universal use of a standard user certificate issued by an enterprise CA.
for your environment, you can begin using EFS. If you don’t have a valid EFS certificate, EFS attempts to obtain one from an available enterprise CA in your environment. When an enterprise CA isn’t available, or when the computer isn’t a domain member, EFS generates a self-signedcertificate on your behalf. This self-signed certificate is a single-purpose certificate thatbe used for EFS; it isn’t automatically trusted by others. As a result, it’s
275
Chapter 9
With Windows Explorer en you encrypt a file, EFS keeps track of this using an attribute associated with the file. Y use the graphical user interface (GUI) supplied by Windows Explorer to check
Wh ou can 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, you’re 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 doesn’t 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
277
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, ayou don’t ne
nd ed to install the Windows 2000 Resource Kit to use it.
Wh y the current encryption state of the cur t low in Listing 9.2. To the left of each
en ou use the cipher command without options, it displays ren folder and any files that it contains; this is shown be
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 it’s unencrypted. C:\Encrypted Folder>cipher Listing C:\Encrypted Folder\ New files added to this directory will be encrypted. E Image.bmp E Worksheet.xls E File.txt E Document.doc E Zipped.zip C:\ cEn rypted Folder>
List tus of the current folder and its files.
then
cipher.exe /d /a *.doc
at you should become familiar with, even if ent.
2000 Resource Kit tool designed to allow you EFS files. Running the efsinfo tool displays information abo t accounts that have been used to protect a file, as s w
ing 9.2: Using cipher.exe to display the encryption sta
You can also use the cipher command to encrypt and decrypt files. For example, to encrypt,decrypt, all of the files with a .doc extension, enter the following commands:
cipher.exe /e /a *.doc
The cipher command is one command-line tool thyou use Windows Explorer to display or alter the encryption status of files in your environm
With Efsinfo.exe You should also get to know efsinfo.exe, the Windows
to view specific information aboutut he EFS user account and the recovery agent ho n 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)
Chapter 9
278
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 requireto decrypt a file. The information that is listed is the information contained in the DDF and the DRF—namely, 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.
Recoverin
d
g Encrypted Files
puter.
If it isnto the recovery agent’s comby ch as S/M ll that practical because if a u h
Once y nd the files th the files. Once the files have been recovered, they should be returned to their owner with a sec
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 user’s computer. The recovery agent can install its private key on the computer, recover the file(s), then remove its private key from the com
’t practical for the recovery agent to travel to the computer, the file(s) have to be moved puter. It’s been suggested, even by Microsoft, that this is easily done
having the poor user who has lost their ability to decrypt their files use a secure protocol suIME to email their files to the recovery agent. This may not be a
ser as lost their EFS private key, they’ve probably also lost their S/MIME private key!
ou’ve resolved the issues of getting the private key of one of your recovery agents aat need to be recovered onto the same computer, you use the cipher command to recover
ure protocol to maintain their confidentiality.
Whenever you’re recovering another user’s files, I recommend that you never do it alone; always have a second recovery agent or even the user themselves present. It’s a good idea to have a witness to ensure that the data is kept confidential.
Yo hprotect our environ files to
u s ould also ensure that when you return recovered files to your users, they have a way to them once again. Consequently, when you develop EFS recovery procedures for yment, make sure that users retrieve a new EFS certificate before returning their recovered
them.
Chapter 9
279
KeepinIt’s reaadmini . Consequently, you need to do a number of things to ensure that files that have been protected usin E
• nal files. If
you encrypt individual files, these temporary files won’t be encrypted, and when you dits, the applications may substitute the temporary files for the originals. If
temporary files.
iles, but poor handling of a
e
ged in as a recovery
•
r enforced. Establish a two-tier archive methodology: The
• form, the plaintext contents of a file can
n
at have an EFS recovery policy defined for them to clear the paging files
• f the first domain controller installed.
g Protected Files Protected sonable to assume that files protected by EFS have been protected for a reason. As an strator, your job is to ensure that protected files aren’t left unintentionally unencrypted
g FS remain protected.
Always encrypt folders, not individual files—This is important because when you edit files, some applications create temporary files in the same folder as the origi
save your eyou always encrypt at the folder level, you’ll ensure that files aren’t left inadvertentlyunencrypted.
• Encrypt users’ My Documents and Temp folders—Most applications store users’documents in their personal folders, so encrypting the My Documents folder safeguards each user’s personal documents. Encrypting the Temp folder helps you avoid potential information leaks that may occur when applications create
• Ensure that the recovery agent’s private keys are handled properly—Poor handlingof private keys by individual users may expose their own frecovery agent’s private keys can compromise many users’ files. For this reason, it’s important to securely store all recovery agents’ private keys. At the very least, export thprivate keys for recovery accounts, remove them from the computer where they’re located, and store them in a safe place. This ensures that someone logagent cannot read files that others have encrypted.
Archive the private keys and certificates for your organization’s recovery agents— You need to do this so that you can recover encrypted files that were created under a recovery policy that is no longefirst 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 down—Although EFS ensures that FEKs are never written to disk in unencryptedreside in the paging file of an operating system (OS). A simple solution might be to encrypt the paging file, but you can’t do this because paging files are marked as systemfiles. Unfortunately, if paging space isn’t heavily used, a plaintext representation of aencrypted 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 thwhen they shut down.
Remove the default recovery agents immediately from all domains—The default recovery agent is the Administrator account oAlthough 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.
Chapter 9
280
EFS Limitations While EFS sounds like a great thing, it does have some limitations. If you’re aware of them, youcan deploy EFS and deal with a minimum of operational issues.
• EFS-protected files cannot be shared—Only the user who encrypted a file can open it (recovery agents excluded)
• Only Win2K NTFS volumes support EFS—As a result, enc
rypted files become e them to a drive that isn’t a Win2K NTFS volume
•
• art up. EFS wasn’t designed to encrypt your entire hard drive
• ion
Iss inI descriisn’t a whole lot to discuss here other than how to issue smart cards to your users. As a result, I’ll talk qu rs can use to lEnrollm
You can set up an enrollment station on any Win2K computer in your environment, including a The only requirements for the station are that a smart
e
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.
decrypted when you copy or mov
• Moving a file or folder into an encrypted folder doesn’t automatically encrypt it— Youneed to drag and drop the file into the folder
You can’t both encrypt and compress files and folders—If 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 encrypted—This ensures that a computer can st
• 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 aren’t protected as they pass over the network—To 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 encryptproperty from the file—To protect the confidentiality of the file, you need to use S/MIME encryption.
u g Smart Cards bed smart cards back in Chapter 4 as part of Win2K authentication. As a result, there
ickly about the three major steps you need to take to issue smart cards that your useog on to the computers in your environment. These steps are: set up a Smart Card ent Station, obtain an enrollment agent certificate, and issue the smart cards.
Windows 2000 Professional installation.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 oneof your enterprise CAs. Possessing such a certificate allows you to generate smart card certificatrequests on behalf of other users. By default, only domain
Chapter 9
281
You may be tempted to use a smart card to store your enrollment agent certificate, but don’t. Using multiple smart card readers on a single computer is problematic at best, and you’ll avoid a lot of hassle if you just request an enrollment certificate and store it on the local hard drive.
Once you’ve obtained an enrollment agent certificate, you use the Certificate Services Web pages to install a certificate on another user’s 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 user’s smart card.
As you begin issuing smart cards to users, you’ll be contending with a mixed environment in 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 DEL secure logon sequence. This mix of strong and weak
auth t ; there ointeract
which some folks are logging in using their
authentication and the CTRL+ALT+en ication schemes weakens the overall security stance of your Win2K infrastructuref re, you need to configure the user account policy to require smart cards to log on
ively for each of the users who’ve been issued smart cards.
Chapter 9
282
Using Software Signing and Authenticode Authenticode is Microsoft’s implementation of a code-signing mechanism that can be used to verify that:
• The software was truly released by the claimed authors
• It hasn’t been tampered with since it was released.
Authenticode allows software vendors and developers to digitally sign code using standadigital signatures. As a result, you can verify the publisher of a digitally signed software packaand the fact that it hasn’t been tampered with before it’s insta
rd ge
lled or executed.
Software signing and Authenticode technology are used not only in IE but also to help you e installation. I’ve discussed this before, but remember that in
A plying Internet Protocol Security
• Protecting IP network packets
se against network attacks.
ions ity at its end. This allows computers engaged in IPSec
Using Certificate Services, you can issue digital certificates to developers in your organization. You can have all internally developed code signed before it’s distributed in your Intranet environment. Only if the code was signed by one of your trusted CAs is it installed and/or executed.
control the behavior of softwarGroup Policy, you can set policies for:
• Unsigned driver installation behavior
• Unsigned non-driver installation behavior.
These two policies let you control how you’re going to react to software that isn’t digitally signed. Your options are to silently succeed, warn but allow installation, and don’t allow installation. No matter which option you choose today, in the future, all software will be digitallysigned in one fashion or another.
pThe 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.
• Providing defen
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 communicatchannel must handle the securcommunications to handle the security of the network channel, and they can assume that the actual physical medium isn’t secure.
Chapter 9
283
Why You Need It So far, I’ve 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 haven’t talked about any generic mechanto 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 diskdrives of your Win2K computers. Unfortunately, if you’re accessing an EFS-protected file that resides on a remote network share, it’s decrypted as it passes up through the Win2K kernel; bythe time it reaches the network,
ism
it’s passed in clear-text. So you went to all this trouble to protect
the persistent storage, but you didn’t 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 don’t have really tight physical security. For example, you’re not running all your cables within metal conduit, you’re not restricting access to all network jacks, and you’re 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 don’t physically oversee the network infrastructure? What about communications with partners and suppliers?
In the final analysis, physically securing the network isn’t really practical in your environment, and you can’t assume it’s being done elsewhere. As a result, your corporate data is susceptible to a number of security compromises as it passes through your network.
• Eavesdropping—If an attacker gains access to the data paths of your network, they can eavesdrop on communications that pass through the data paths they’ve gained access to.
• Modifying data—If an attacker can eavesdrop, who is to say that they won’t take the next step and alter the data as it passes through your network?
• Spoofing IP addresses—An 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 passwords—Many legacy applications and even some poorly designed new t format or a
s to your network, they
ur ate consequence to try to disrupt valid traffic.
ones send user names and passwords over the network in either clear-texformat that is easily compromised. If an attacker has gained accescan capture user name and password combinations of the legitimate users in your environment and steal their identities.
• Denying service—An 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 system’s resources. In either case, the attacker is trying to occupy yocomputers with network traffic of no legitim
Chapter 9
284
• Man in the middle—An attacker can pose as a legitimate entity to not one, but two, parties in the hope of monitoring, controlling, or altering communications between two
nicate,
nt an
ase the entire, OS.
IPS IPSec was designed to secure network comm
ve 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
sparent network-level security for any application and provides a
Whalso you and your environment.
• Anti-replay—Cryptographic techniques allow IPSec to ensure that an attacker cannot reuse or replay captured IP packets. As a result, an attacker cannot intercept a network
ess to your network resources.
PSec in Win2K can use pre-shared keys, digital certificates, or Kerberos as
er
fidentiality of data can be assured, and others cannot read the data even if it’s eavesdropped or intercepted.
• Integrity—IPSec 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-repudiation—Digital 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 I’ll discuss later in this chapter. (See “Creating an IPSec Policy.”)
computers on your network. For example, computers A and B may want to commubut if computer C successfully pretends to computer B that it’s computer A and vice-versa, computer C can sit in the middle!
• Compromising applications—An attacker can target applications in your environmeand exploit known vulnerabilities to compromise your applications. This compromise cgive the attacker access to either part of, or in the worst c
ec Services unications by encrypting individual IP packets
before they’re sent out onto your physical network. As a result, IPSec can protect against the attacks discussed abo
the packets. This provides tranmechanism that you can deploy without modifying applications.
ile encryption is the main component that many think about when discussing IPSec, IPSec provides a number of services to
packet and replay it to gain illicit acc
• Authentication—IPSec uses multiple techniques to establish the identities of other computers and thus ensure that communications are taking place among the appropriate computers. Ian authentication mechanism.
• Confidentiality—Encryption allows IPSec to ensure that data sent across a network isn’tdisclosed to attackers. Because encryption key(s) are only held by the sender and receivof the network packets, con
Chapter 9
285
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 packettunneled, it’s encapsulated inside a new packet, and th
is e tunnel provides the logical data path
t the data remains confidential, the data is readable to an attacker, who es
• ESP mode—Provides the same services as AH mode, but with two differences: It adds y the data portion of an IP packet, not the entire packet.
just the IP data payload of a packet, not the IP header information.
al IP header.
• AH tunnel mode—Essentially 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 isn’t 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.
through which encapsulated packets travel to their final destinations.
These four modes are described below.
• AH mode—Provides 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 doesn’t ensure thacan obtain an AH-protected packet. However, the HMAC signing of this mode ensurthat an attacker cannot modify the data. You can use AH mode by itself or in conjunctionwith ESP mode.
confidentiality, but it protects onlIt signs
• ESP tunnel mode—Encapsulates the entire original IP packet and adds new header andfooter 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 ofan 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 origin
Chapter 9
The key portion of this last statement is to understand. That is becaconfigurations aren’t really intended for deployment in your enviro
use these predefined nment. Instead, they’re
included for deployment-testing purposes and to help educate users about how IPSec can work inan environment. These predefined policies can be found in a Group Policy Object (GPO), as shown below in Figure 9.12. Thus, you’ll find that IPSec policy is best maintained using AD-based GPOs and not individual local GPOs.
efault, it initiates all network communications without using IPSec but can use the network security protocol when requested by another party.
ing,
Figure 9.12: Viewing predefined IPSec policies.
Each policy provides the following:
• Client—A mechanism to negotiate IPSec communications as requested by other computers. By d
• Server—A 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 isn’t able to use IPSec.
• Secure Server—A mechanism that requires all communications, outgoing and incomto be secured using IPSec. As a result, this policy won’t allow a computer to talk to a non-IPSec–enabled computer.
286
Chapter 9
287
While these predefined policies were intended as guides, in a homogenous Win2K environment, it’s 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 you’ve 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 isn’t yet part of the domain, you cannot use Kerberos authentication, nor can you easily use certificate-based authentication if you’re using enterprise CAs. Your only real option is to use the shared secret–based 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 it’s not a member of the domain, so it can’t 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 wizard—in 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 you’ve completed the wizard.
Figure 9.13: Using the IP Security Policy Wizard to choose the authentication option for a new IPSec policy.
When you’ve created the IPSec policy, you can configure its rules, filters, and filter actions.
Chapter 9
288
Configuring Rules Once you’ve created an IPSec policy, you can add rules to it. In the MMC snap-in console, right-click the policy, then choose Properties from the shortcut menu. In the policy’s 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 policy’s 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 policy’s 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 don’t want either of them to apply to all of your computer’s 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.
Chapter 9
289
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 don’t 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 security—Uses IPSec in ESP mode
• Medium security—Uses 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 don’t recommend it. It’s true that the implementation security issues that existed in earlier versions of PPTP have been fixed in Win2K’s version of PPTP, but I see no reason to use the protocol when IPSec is available.
Chapter 9
290
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 factor—authenticating 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 PKI-enabled 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 Authenticode—as well as management features such as the Certificate Services Web pages and the Certificate Manager—round 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 I’ve talked about here and make PKI a reality for your organization!
Chapter 10
291
Chapter 10: Internet Information Services
The security of Microsoft’s 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.
Chapter 10
292
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 we’ll 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 clear—Base-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 Force’s (IETF’s) 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 computer’s 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 user’s password with the challenge, creating its own thumbprint.
5. The server compares the two thumbprints; if they are identical, the user is authenticated.
Chapter 10
293
As you can see from Step 4, for digest authentication to work, the server must have access to a plain-text copy of the user’s password. An additional constraint of digest authentication is that it requires that the user accounts reside within a domain. Put together, this means that you’re 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 (NTLM—for downlevel clients) to automatically authenticate a user to IIS over standard HTTP. When using integrated Windows authentication, a user’s browser will use the user’s 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 access-control mechanisms, as Figure 10.2 shows, that combine to determine whether a user has access to an IIS resource.
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
295
Network Address Access ControIIS allows you to restrict service to er and DNS domains through the use of networ dYou can pull up the IP Address and Domain Name Restrictionssite through the IIS MMC snap-in rselecting Properties from the pop-u m ng Edit in the center of the tab.
l c tain IP addresses, ranges of IP addresses, hosts, k a dress access-control mechanisms, as Figure 10.3 shows.
dialog box for a particular Web by ight-clicking the appropriate Web server resource,
enu, clicking the Directory Sep curity tab, then clicki
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.
Chapter 10
296
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 pop-up 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.
Chapter 10
297
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 access-control 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.
Chapter 10
298
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 template—This option resets all the NTFS permissions in accordance with the selected template.
• Leave the current permissions intact, and add the template—This 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 permissions—This 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 IIS-specific 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.
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
300
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-of-process 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.
Chapter 10
301
• Site-Pause-Limit: The Reset Interval was reached or the Site-Pause-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.
Chapter 10
302
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 I’ll 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.
Chapter 10
303
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 Authentication—SSL provides a mechanism that allows a user to confirm the identity of an SSL-enabled server. An SSL-enabled client application can utilize public-key cryptography techniques to validate that a server’s certificate has been issued by a certificate authority (CA) that is in the client’s list of trusted CAs and to validate that the ID contained within the certificate matches the FQDN of the server.
• Client Authentication—SSL provides a mechanism to allow a server to confirm the identity of a user. Using the same basic public-key cryptographic techniques, an SSL-enabled server can request and validate that the user’s 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 Communications—SSL 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.
Chapter 10
304
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 RC4—Stream encryption ciphers
• RSA—Public-key algorithm for both encryption and authentication
• RSA key exchange—Key-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.
Chapter 10
305
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 server’s 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 server’s 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.
Chapter 10
306
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 application’s 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 application’s 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.
Chapter 10
307
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 certificate’s validity period. If the current date and time are outside the range of the certificate’s 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 server’s certificate from within the server’s 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 CA’s certificate to validate that the digital signature of the server’s 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 server’s 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 server’s 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 server’s 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.
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 client’s 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 client’s 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
309
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 certificate’s validity period. If the current date and time are outside the range of the certificate’s validity period, the client is not authenticated; otherwise, the server proceeds to the next step.
Chapter 10
310
• 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 client’s certificate from within the client’s 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 CA’s certificate to validate that the digital signature of the client’s 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 client’s 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.
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
312
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.
Chapter 10
313
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 client’s 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 user’s client certificate. The mapping is created by selecting the option to add a new mapping and selecting the user’s 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 user’s account for the mapping to be utilized.
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 many-to-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 user’s 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. It’s really pretty straightforward, but let’s cover the basic options just to make sure things are well understood:
• Match Capitalization—This 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 Field—This 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 Field—This 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) Organization—top-level organization or company name, (OU) Organizational Unit—a department within a company (for example, Human Resources), (CN) Common Name—name of the client (for example, George W. Bush), (C) Country—two-letter country designation (for example, US, FR, AU, UK), (S) State/Province—the full name of the state or province (for example, California, Alberta), and (L) Locality—the full name of the city (for example, San Francisco, Toronto).
315
Chapter 10
316
In addition to the common subfields found in a certificate, the rule editor supports several non-standard subfield categories, including (C) Country—two-letter country designation (for example, US, FR, AU, UK), (I) Initials—initials of the certificate owner, (GN) Given Name—given name of the certificate owner, (T) Title—title of the certificate owner, (Email) Email—email address of the certificate owner.
• Criteria—This 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 user’s 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. Don’t 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.
Chapter 10
317
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
C NTFS OS files E NTFS Application and
temporary storage F 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
Chapter 10
318
• 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.
Chapter 10
319
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*.*
Chapter 10
320
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.
Chapter 10
321
• 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
Chapter 10
322
• 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
Chapter 10
323
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 you’re 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)
Chapter 10
324
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 *
Chapter 10
325
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 connection’s 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
Chapter 10
326
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
EnableICMPRedirect 0 EnableSecurityFilters 1 SynAttackProtect 1 EnableDeadGWDetect 0 EnablePMUDiscovery 0 KeepALiveTime 300000DisableIPSourceRouting 1 TcpMaxConnectResponseRetransmissions 2
\CurrentControlSet\Control\Services\Tcpip\Paramaters
TcpMaxDataRetransmissions 3 \CurrentControlSet\Control\Services\NetBT\Paramaters ReleaseOnDemand 1
DynamicBacklogGrowthDelta 10 EnableDynamixBacklog 1 MinimumDynamicBacklog 20
\CurrentControlSet\Control\Services\AFD\Paramaters
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
Chapter 10
327
• 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
Chapter 10
328
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
Chapter 10
329
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
Chapter 10
330
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
Chapter 10
331
• 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. Read-only 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 simple—the 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 HTUhttp://www.microsoft.com/Downloads/Release.asp?ReleaseID=32362 UTH.
A good configuration guide for hardening Win2K can be found at HTUhttp://www.sys-exp.com/win2k/HardenWin2K.htmlUHT.
As always, make sure you check out what Microsoft is recommending for IIS configurations at HTUhttp://www.microsoft.com/securityUTH.
Chapter 10
332
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.