null  null
Tips and Tricks Guide To
Securing Windows
Server 2003
Roberta Bragg
By Sean Daily, Series Editor
Welcome to The Tips and Tricks Guide to Securing Windows Server 2003!
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 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 such as NetIQ, who agree
to bear the book’s production expenses and host the book on its Web site for the benefit of its
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 “realtime”—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
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, NetIQ has
set 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 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, or calling us at (707) 539-5280.
Thanks for reading, and enjoy!
Sean Daily
Series Editor
Note to Reader: This book presents tips and tricks for eight Windows Server 2003 security
topics. For ease of use, the questions and their solutions are divided into chapters based on topic,
and each question is numbered based on the chapter, including:
Chapter 1: Understanding and Utilizing PKI in Windows Server 2003
Chapter 2: Securing Web Services and Web Servers—the Administrative Perspective
Chapter 3: Understanding Active Directory Foundations
Chapter 4: Fulfilling the Promises of Group Policy
Chapter 5: Administrative Authority
Chapter 6: Triple A’s—Authentication, Authorization, and Audit
Chapter 7: Remote Access
Chapter 8: Security Tools, Mechanisms, and Emerging Issues.
Introduction...................................................................................................................................... i
Chapter 1: Understanding and Utilizing PKI in Windows Server 2003..........................................1
Q 1.1: We are upgrading Windows 2000 Professional clients to Windows XP Professional and
have found that our public key policy, which disables Encrypting File System, has no effect on
Windows XP clients. Why does this happen and what can we do?.................................................1
Disabling EFS by Setting a Windows XP EFS Registry Key .............................................1
Using Windows XP EFS Local Security Policy ..................................................................2
Automating the EFS Disable Process Through a Script ......................................................3
Using Group Policy to Automate the EFS Disable Process ................................................3
Using Public Key Group Policy in Windows Server 2003..................................................4
Q 1.2: Developing a public key infrastructure using Windows Certificate Services seemed like
the way to go until I discovered that there is no auto enrollment. Do you expect that users will be
able to obtain certificates on their own? ..........................................................................................4
Quick Steps to Auto Enrollment ..........................................................................................6
Q 1.3: We’d like to use Secure Sockets Layer to secure communications on our intranet but we
don’t want the expense or possible security risk of using third-party certificates. Is there a way to
benefit from Windows 2000 Certificate Services without deploying Active Directory?..............12
Planning for PKI ................................................................................................................12
Defining PKI..........................................................................................................13
Enterprise and Standalone CAs .........................................................................................15
Managing CA Administration................................................................................16
Obtaining Certificates ............................................................................................17
Statement of Practice Policy ..................................................................................17
Best Practices .....................................................................................................................18
Installing and Configuring .................................................................................................18
Pre-installation Practices........................................................................................19
Installing the Standalone Root CA ........................................................................19
Q 1.4: What purpose does a certificate revocation list serve? .......................................................21
Certificate Revocation .......................................................................................................22
Certificate List Revocation Publishing ..............................................................................26
Introduction to Delta CRLs....................................................................................27
Delta CRL Implementation....................................................................................29
Q 1.5: If a user’s private key is destroyed or becomes corrupted can his or her Encrypting File
System files be recovered?.............................................................................................................30
Prepare the CA for Key Recovery .....................................................................................30
Prepare EFS Custom Template for Key Archival..............................................................35
Using the New Certificates and Recovering Keys.............................................................37
Q 1.6: The financial managers group would like to be able to encrypt meeting minutes and share
them. How do I set this up for them?.............................................................................................40
Best Practices and Caveats.................................................................................................40
How the Sharing of Encrypted Files Works ......................................................................42
Step-by-Step Process to Secure Shared Encrypted Files ...................................................46
Simple EFS Sharing...............................................................................................46
EFS Sharing on a Share .........................................................................................48
Chapter 2: Securing Web Services and Web Servers—the Administrative Perspective...............50
Q 2.1: I’ve just been reading about the dangers of allowing services to log on using the Local
System account. Isn’t this account the one that the World Wide Web Service uses? Is there
something I can do to mitigate the risk? ........................................................................................50
Understanding IIS 5.0 Application Privileges Processing.................................................50
How IIS 6.0 Solves the Problem........................................................................................52
Q 2.2: I keep hearing about the new NetworkService account in Windows Server 2003.
Microsoft says that this account is less privileged than the Local System account but doesn’t
explain what that means. Any ideas?.............................................................................................53
What Can the NetworkService Account Do? ....................................................................54
What Can the Local System Account Not Do? .................................................................55
Q 2.3: I’ve heard that the new Windows Server 2003 Web Server is installed as a hardened Web
server. Do I need to do anything to ensure that I have a secure Web server or can I simply bring
up this system with a default installation and not worry about it?.................................................55
Installing the Windows Server 2003 Web Server..............................................................56
Post-Installation Lockdown Steps......................................................................................58
Q 2.4: The use of Internet-downloadable components has been a major security issue. As we
move to Windows Server 2003, how can we prevent malicious code from running on our
systems? .........................................................................................................................................61
Code Groups ......................................................................................................................62
Named Permission Sets..........................................................................................64
Creating Custom Permission Sets..........................................................................64
Policy Assemblies..............................................................................................................68
Security Policy ...................................................................................................................68
The Microsoft .NET Framework Configuration Tool ...........................................69
Process ...............................................................................................................................70
Q 2.5: We do not allow users to store data on their hard drives. They are provided a place on a
file server. I can protect this area with discretionary access control lists, but how do I protect data
during transport from client to file server? ....................................................................................72
Preparing and Securing Web Folders for WebDAV..........................................................72
Using SSL to Transfer Files to Web Folders .....................................................................75
Q 2.6: How are configuration changes made to IIS, and how can I protect the IIS configuration?79
Ensuring Survival of the Metabase ....................................................................................80
Stopping and Starting IIS...................................................................................................81
Backup ...............................................................................................................................81
Modifying the Metabase ....................................................................................................82
Enabling the Edit-While-Running Feature ............................................................84
Securing the Metabase .......................................................................................................85
Chapter 3: Understanding Active Directory Foundations .............................................................87
Q 3.1: My company will be merging with another. Both companies have their own Windows
2000 forests. I know we will want to provide access to some resources in each forest to users
with accounts in the other. What’s the best way to do so? ............................................................87
External Trusts ...................................................................................................................87
Non-Transitive Trusts Mean Limited Access Between Forests ............................87
Forest Trust ........................................................................................................................90
Requirements for Forest Trusts..............................................................................91
Forest Trust Details................................................................................................92
Creating a Forest Trust...........................................................................................93
Q 3.2: Help! We have a large, multidomain forest that contains thousands of users, and we use
universal groups extensively to provide access to resources. We also have many small branch
offices that have only a handful of users each. Because the Global Catalog server must be
accessed at logon to determine membership in universal groups, all users at branch offices access
Global Catalogs across the WAN even though they have a domain controller locally. If I make
the domain controllers at these branch offices Global Catalog servers, I’ve increased the
replication traffic by an unacceptable amount. Does Windows Server 2003 have an answer?.....95
Win2K Branch Office Solutions........................................................................................97
Windows Server 2003 Universal Group Membership Caching ........................................99
Q 3.3: Our IT Audit department wants me to change the Kerberos policy and set the time skew
back to 5 minutes. If I do so, many users will have logon problems. How can I convince
management that IT Audit is wrong?...........................................................................................100
Time Service Operation ...................................................................................................100
Time Convergence Process..................................................................................101
Impact of Time Skew on Kerberos ..................................................................................102
A Rational Solution to WAN Kerberos Logon Problems................................................103
Q 3.4: What possible advantage is there to implementing universal groups? .............................104
Win2K Mixed Domain Functional Level Group Management Practice .........................104
Win2K Native or Windows Server 2003 Domain Functional Level and Universal Groups107
Q 3.5: Is it possible to place the Active Directory database on a different drive from its logs? .109
Q 3.6: What steps should I take to secure Active Directory? ......................................................111
System Configuration Including Access Control ............................................................111
GPO Permissions .................................................................................................112
Certificate Template Permissions ........................................................................113
DNS Permissions .................................................................................................113
Administrative Practice....................................................................................................114
Chapter 4: Fulfilling the Promises of Group Policy ....................................................................116
Q 4.1: My Windows XP system just asked me if I wanted to report an error to Microsoft. What’s
up with that?.................................................................................................................................116
From the User Perspective—Control Panel Error Reporting Settings.............................117
Controlling Error Reporting with Group Policy ..............................................................118
Controlling Error Reporting.................................................................................118
Advanced Error Reporting Settings .....................................................................120
Q 4.2: How can I prevent users from running tools that they should not run?............................121
Setting Restrictive File Permissions ................................................................................121
Removing Executables.....................................................................................................121
Using Software Restriction Policies ................................................................................121
A Simple Policy to Restrict Tool Use..............................................................................122
Creating a Simple Software Restriction Policy ...................................................123
Testing the Policy ................................................................................................125
Examining the Policy for Holes...........................................................................125
Certificate Rules...............................................................................................................127
Trusted Publishers................................................................................................127
Moving On .......................................................................................................................128
Q 4.3: What is a strong account policy, and how do I configure it in Windows Server 2003?...129
Q. 4.4: How can I ensure that the proper system file and registry permissions are maintained
across all Windows Server 2003 servers in my domain? ............................................................133
Determining Appropriate Files and Registry Permission Settings ..................................134
Using Group Policy to Maintain File and Registry Permission Settings.........................135
Using Secedit to Maintain File and Registry Permission Settings ..................................138
Q 4.5: How can I prevent wireless access points from become an unguarded entry point into my
Securing Wireless Communications ................................................................................143
Standard Security Options ...................................................................................144
Standard Security Options Plus Fire walling .......................................................145
Add 802.1x Technology.......................................................................................145
Windows Server 2003 Wireless Network (IEEE 802.11) Policies..................................147
Q 4.6: I want a kiosk on the shop floor to have the same user settings no matter who logs on.
What can I do? .............................................................................................................................150
How Loopback Processing Mode Works ........................................................................151
Configuring Loopback Processing Mode ........................................................................152
Chapter 5: Administrative Authority ...........................................................................................153
Q 5.1: How do I prevent unauthorized use or abuse of the local Administrator account? ..........153
Disable the Administrator Account for Windows Server 2003 and Windows XP..........154
Limit Local Account Use of Blank Passwords to Console-Logon Only .........................154
Rename Administrator Account ......................................................................................154
Allow Anonymous SID and Name Translation ...............................................................155
Do Not Allow Anonymous Enumeration of SAM Accounts ..........................................155
Define Restricted Groups.................................................................................................156
Restrict Users to the Explicitly Permitted List of Snap-Ins.............................................157
Q 5.2: I seem to have locked out the Administrator account in the domain. I can no longer log on
to the domain using this account. What should I do? ..................................................................157
Q 5.3: How can I give administrative abilities to my Help desk staff without making them full
Delegating Control...........................................................................................................159
Delegating Common Tasks..................................................................................160
Creating a Custom Task.......................................................................................162
Providing Administrative Tools for Sub-Administrative Groups....................................163
Q. 5.4: Our policy is to let users in sensitive departments maintain the backups for servers within
their departments. To allow users in the Accounting department to back up their servers, I
created a global group for the users and a local group on each server. The local group is assigned
the right to back up files and directories in the local security policy of each server, but these
users cannot back up the servers. What is wrong?.......................................................................168
Location, Location, Location...........................................................................................168
Q. 5.5. What exactly can an Enterprise Administrator do? .........................................................171
Q 5.6: How can I support delegation of services for an n-tier application without creating a huge
security hole? ...............................................................................................................................175
Constrained Delegation in Windows Server 2003...........................................................176
Chapter 6: Triple A’s—Authentication, Authorization, and Audit .............................................179
Q 6.1: How does authorization occur when users in one Windows Server 2003 forest attempt to
access a file on a server in another Windows Server 2003 forest? ..............................................179
Q 6.2: I am tasked with tracing logon behavior across our Windows Server 2003 forest and
would like some help understanding the difference between the Audit categories Audit Account
Logon and Audit Logon. What is the difference?........................................................................184
Tracing a User’s Logon and Logoff Events.....................................................................187
Q 6:3: I’ve added Access Control Lists to a folder to allow one group of users full control, and
set permissions to give another group of users the ability to read and write files. Recently, I
discovered that users in the second group can also delete files in this folder. I’ve tried assigning
the Deny delete permission to the files, but the second group are still able to delete files. How
can this be and how do I fix it? ....................................................................................................190
Permissions vs. Special Permissions................................................................................191
Additional Permissions and Rights......................................................................195
Q. 6.4: What is the difference between user rights, permissions, and privileges?.......................196
Logon Rights........................................................................................................197
Q 6.5: Which file activity should be audited and how do I do so? ..............................................201
Maintaining an Audit Trail ..............................................................................................201
Monitoring a User’s Activity ...........................................................................................202
Compatibility Resolver ....................................................................................................202
Log Changes in System Files...........................................................................................203
How to Set Up File Auditing ...........................................................................................203
Set Audit Policy ...................................................................................................203
Set SACLs on Files and Folders ..........................................................................204
SACL Inheritance ................................................................................................206
Q 6.6: What impact do the Kerberos policy settings have?.........................................................207
The Kerberos Process ......................................................................................................208
Authentication Processing—the Ticket Granting Service ...................................208
Service Ticket Generation—the Authentication Service.....................................208
Authorization .......................................................................................................209
The Kerberos Policy ........................................................................................................209
Chapter 7: Remote Access ...........................................................................................................211
Q 7.1: If I allow the use of Remote Assistance, what prevents unauthorized users from taking
control of a user’s desktop or server? ..........................................................................................211
Soliciting Remote Assistance ..........................................................................................212
Offering Remote Assistance ............................................................................................214
The Ultimate in Remote Assistance Risk Avoidance ......................................................216
Q 7:2: What is the Session Initiation Protocol? ...........................................................................217
Internet Engineering Task Force RFC SIP Security ........................................................217
Message Integrity, Authorization, and Authentication ........................................218
Message Privacy ..................................................................................................218
Route Privacy.......................................................................................................219
Identity Privacy....................................................................................................220
Miscellaneous Uses of Cryptography ..............................................................................220
Microsoft Implementation ...............................................................................................221
Q 7.3: I want to make use of Terminal Server Remote Administration mode. What can I do to
improve security when using this facility over the Internet?.......................................................222
Using the Terminal Servers Configuration Console............................................224
Remote Desktop Port Settings .............................................................................225
Client Settings......................................................................................................225
Terminal Services Group Policy Settings ............................................................227
Remote Desktop Web Connection.......................................................................228
Q. 7.4: I want to setup dial-up remote access and a virtual private network connection, but I don’t
want to configure Active Directory. Is this setup possible? ........................................................230
Understanding the Difference Between Authentication and Authorization ....................230
Choosing an Authentication Provider..............................................................................230
Authentication Methods...................................................................................................232
MS-CHAP and MS-CHAPv2 ..............................................................................235
SPAP ....................................................................................................................236
PAP ......................................................................................................................236
Data Encryption ...............................................................................................................237
Remote Access Policy......................................................................................................239
Policy Attributes ..................................................................................................240
Account Lockout..................................................................................................242
Installation and Configuration .........................................................................................242
Q 7.5: I set up a Windows 2000 virtual private network (VPN) for use by our salesmen to
connect to the corporate LAN. It worked fine at first, but we had a security review, and the
experts advised us to change the VPN protocol from Point-to-Point Tunneling Protocol (PPTP)
to Layer 2 Tunneling Protocol (L2TP)/IPSec and change our authentication method to
certificates. It seems to work in my test lab, but when I put it into production, I cannot get it to
work. In addition, we must be accessible to Windows 98 clients. Will upgrading our Routing and
Remote Access Service (RRAS) server to Windows Server 2003 solve this problem?..............242
VPN Design Issues for L2TP/IPSec ................................................................................243
VPN Protocols Choices....................................................................................................245
PPTP ....................................................................................................................246
L2TP/IPSec ..........................................................................................................246
L2TP over IPSec and NAT—NAT-Traversal .................................................................247
Q 7.6: How can I securely and remotely administer systems? ....................................................249
How It Works...................................................................................................................249
Applying Maximum Security ..........................................................................................252
Using Group Policy to Secure Remote Desktop for Administration...............................256
Remote Desktop Web Connection...................................................................................257
Chapter 8: Security Tools, Mechanisms, and Emerging Issues...................................................258
Q 8.1: How do I determine which Group Policy settings are actually being applied? ................258
Mining the Common Infrastructure Management Object Manager Database.................258
Obtaining Results with RSoP...............................................................................259
Storing, Recovering and Printing RSoP...............................................................262
RSoP Best Practices.........................................................................................................263
Q 8.2: Managing multiple Windows boxes is like herding cats. It’s hard to keep up with which
systems have up-to-date patches and which still need them. How can I figure this out?............263
Analyzing the Analyzer: MBSA Internals.......................................................................264
Understanding Prerequisites ................................................................................264
Getting Secure the MBSA Way...........................................................................265
Now What? ..........................................................................................................268
Q 8.3: We have a problem with employees who bring in their home laptops and plug in to the
office network. Although I can control the software and function of computers in my network, I
have no control over these renegade machines: whether they have antivirus software installed,
are running IIS, or are a Dynamic Host Configuration Protocol server. They’re causing havoc. Is
there a way I can prevent these rogue computers from running on my network? .......................268
Microsoft’s IPSec Implementation ..................................................................................269
How IPSec Works................................................................................................270
Writing an IPSec Policy to Keep Rogue Computers Out of Your Network....................273
Changing the Authentication Method..................................................................276
Requiring Computer Certificates for Authentication...........................................276
Q. 8.4: I’m always a little leery of using secedit to apply a security template. What if the system
is not working the way I want it to after I apply the template? ...................................................279
Q 8.5: I’d like to prevent clients on my network from using or receiving Telnet commands and
from running a Web server. Can this be done?............................................................................281
IPSec Blocking Policy Basics..........................................................................................282
Creating and Testing the Policy.......................................................................................282
Q 8.6: How can I secure communications between two computers on the LAN? ......................285
Create the Policy ..............................................................................................................287
Testing the Policy ............................................................................................................291
Copyright Statement
© 2003, Inc. All rights reserved. This site contains materials that
have been created, developed, or commissioned by, and published with the permission
of,, Inc. (the “Materials”) and this site and any such Materials are
protected by international copyright and trademark laws.
TITLE AND NON-INFRINGEMENT. The Materials are subject to change without notice
and do not represent a commitment on the part of, Inc or its web
site sponsors. In no event shall, Inc. or its web site sponsors be
held liable for technical or editorial errors or omissions contained in the Materials,
including without limitation, for any direct, indirect, incidental, special, exemplary or
consequential damages whatsoever resulting from the use of any information contained
in the Materials.
The Materials (including but not limited to the text, images, audio, and/or video) may not
be copied, reproduced, republished, uploaded, posted, transmitted, or distributed in any
way, in whole or in part, except that one copy may be downloaded for your personal, noncommercial use on a single computer. In connection with such use, you may not modify
or obscure any copyright or other proprietary notice.
The Materials may contain trademarks, services marks and logos that are the property of
third parties. You are not permitted to use these trademarks, services marks or logos
without prior written consent of such third parties.
If you have any questions about these terms, or if you would like information about
licensing materials from, please contact us via e-mail at
[email protected]
Chapter 1
Chapter 1: Understanding and Utilizing PKI in Windows
Server 2003
Q 1.1: We are upgrading Windows 2000 Professional clients to
Windows XP Professional and have found that our public key policy,
which disables Encrypting File System, has no effect on Windows XP
clients. Why does this happen and what can we do?
A: Unfortunately, Windows XP has a different Encrypting File System (EFS) model than
Windows 2000 (Win2K) has. There are several differences between the models, but the
difference that is causing your problem is that Windows XP’s EFS does not require that a Data
Recovery Agent be present before files can be encrypted; Win2K’s EFS model does. The Win2K
“no-recovery-agent, no encryption” rule lets you easily prevent file encryption across an entire
domain of Win2K clients. As you’ve discovered, you simply need to remove the Data Recovery
Agent certificate from the public key policy, and delete the recovery policy.
Windows XP Professional has no such limitation. XP allows data file encryption regardless of
whether a Data Recovery Agent exists. To disable EFS in Windows XP, you must take a
different tack. Here are your choices:
On standalone systems, either make the registry key modification discussed in the next
section or apply the setting in local security policy.
Why would someone directly edit the registry when the local security policy reduces the chances of
human error (that is, prevents you from typing a wrong value in the registry) and is easier to use? To
make changes to many systems, you can modify the registry, especially if you’re working remotely.
Although applying a setting in local security policy reduces the chance of error, this option isn’t
feasible if you have to update 5000 Windows XP systems.
For Windows XP joined in a Windows Server 2003 domain, you can use a Group Policy
You can manage settings by including the modified registry key in a script.
On Windows XP systems joined in a Win2K domain, you can automate your efforts by
adding the registry key to a security template, and importing the template into a Group
Disabling EFS by Setting a Windows XP EFS Registry Key
To disable EFS on a standalone Win2K Pro computer, you can add a new value to the
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\EFS
subkey. The new value must be of type DWORD. Call it EfsConfiguration, and give it a value of
1. If you need to enable EFS, simply change the value to 0.
Chapter 1
Using Windows XP EFS Local Security Policy
To disable EFS using the local security policy setting, follow these steps:
1. Open the Start menu, select Programs, Administrative Tools, Local Security Policy.
2. In the Local Security Settings window, navigate to and expand Public Key Policies.
3. Right-Click Encrypting File System, and select Properties.
4. Clear the Allow users to encrypt files using the Encrypting File System (EFS) check box,
as Figure 1.1 shows.
Figure 1.1: Disabling EFS for Windows XP through a local security policy setting.
5. Click OK.
6. Open a command prompt, and type
to refresh the policy.
Gpupdate is the Windows XP command used to refresh Group Policy. This command replaces
Win2K’s secedit refreshpolicy command. If you choose not to use the gpupdate command, Group
Policy will still refresh, it will just take longer.
Chapter 1
Automating the EFS Disable Process Through a Script
Modifying registry keys on a couple of machines may be a simple undertaking; however,
modifying a key on hundreds or thousands of machines isn’t as simple. There are many ways to
do so in an automated fashion. One of the simplest ways is to create the setting to be set when
the Windows XP systems start. Another method is to use a script that is run locally on the
Window XP systems. In the script use the following command:
reg add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\EFS"
/v EfsConfiguration /t REG_DWORD /d 1
You can use a similar command to turn EFS back on, either by simply changing the value to 0 or by
deleting the key using the following command
reg delete "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\EFS"
/v EfsConfiguration /f
The /f eliminates the need for prompting from the user to confirm the deletion.
Using Group Policy to Automate the EFS Disable Process
If you would like to add the ability to push the disabled setting through Group Policy on a
Windows XP system in a Win2K domain, you can do so by editing the Sceregvl.inf file. This
file, which is located in the %windir%\inf folder, is a list of registry settings that are exposed in
the Local Policy\Security Options section of security templates. By adding registry information
to the file, you can expose additional entries, thus extending your ability to manage settings
through security configuration and analysis or Group Policy. The file has two sections, one that
lists registry keys, [Register Registry Values], and one that details what will appear in the
security template, [Strings].
First, add the registry information to the file. The following line should be placed within the
other registry settings in the [Register Registry Values] section:
A good place to add this line is below registry keys that are in similar locations. In my file, I’ve
placed the line with the other Windows NT\CurrentVersion subkeys. Table 1.1 explains the
previous command.
Example in the
Previous Statement
Lists the path
Defines the registry data
Represents the string value
in the [Strings] section
Specifies the type of dialog
box presented to users in
the GUI for configuration
Two radio buttons—Enable and
Disable; choosing Disable will
set the registry value to 0
Table 1.1: Explanation of the registry addition parameters.
Chapter 1
In the [Strings] section of the file, add the Display Name parameter, without the percent signs
(%), and add a string for display in the GUI. In the following example, I’ve chosen to label the
setting within the file to make it easier to find. Using a semi-colon (;) identifies the label as a
;==========Public Key===================================
EfsConfiguration = "Public Key: Users cannot encrypt files"
After you have saved the file, you must register it to make the changes available to security
templates. To do so, type the following statement at a command prompt:
C:\>Regsvr32 scecli.dll
A pop-up window will indicate that the command has succeeded.
The list of security options available in the security template should now include your option, as
will the Group Policy Objects (GPOs) examined on this machine. To use the security template,
set its value to Enable, save the template, and import it into a Group Policy linked to the
organizational unit (OU) in which Windows XP computer accounts reside.
The Microsoft article “How to Add Custom Registry Settings to Security Configuration Editor”
(;EN-US;Q214752&) includes a brief
discussion about modifying Sceregvl.inf as well as a description of other parameter values.
Using Public Key Group Policy in Windows Server 2003
Disabling EFS in Windows Server 2003 is much like doing so for a single EFS system. The
difference is that you modify the EFS property page in a Group Policy. You may choose to do so
for the entire domain, or selectively enable or disable EFS per OU.
A Win2K Pro system has the same problem if it is in a Windows NT domain. The NT domain
administrator cannot be a File Recovery Agent. To disable EFS on a Win2K Pro computer, a hotfix is
available from Microsoft (;EN-US;Q288579&).
The hotfix adds the previously discussed registry key, but you must still change the value of the key
to 1 to disable EFS.
Q 1.2: Developing a public key infrastructure using Windows
Certificate Services seemed like the way to go until I discovered that
there is no auto enrollment. Do you expect that users will be able to
obtain certificates on their own?
A: Enrollment of thousands of users is no picnic. Windows Server 2003 makes this process
easier—automatic enrollment is possible with Windows Server 2003 Certificate Services.
Automatic enrollment means that users do not have to learn about certificates, nor about how to
obtain one. It also means that re-enrollment can be transparent as well. However, you must
configure auto enrollment for each type of certificate you intend to distribute. This requirement
is a good thing, as you may not want all certificates distributed in this manner. It does, however,
mean more planning and administrative work must be done.
Chapter 1
The first step is to determine which certificates should be automatically distributed. For our
example, we’ll use the ordinary User certificate. This certificate can be used for authentication,
email encryption, and the Encrypting File System (EFS). To provide User certificates that can be
auto enrolled, you must create a new type of certificate template—a Version 2 certificate
template—and configure it for auto enrollment.
Windows 2000 (Win2K) Enterprise Certificate Services use Version 1 standard templates, and
although a variety of templates exist, it is not possible to customize templates. Windows Server
2003 Certificate Services can use Version 1 and Version 2 templates, and Version 2 templates
are customizable. You create customized Version 2 templates by copying Version 1 templates,
then modifying them. After you’ve created and modified a template to suite your business needs,
you can use the template to create certificates using the typical end-user or enrollment-agent
enrollment process. Templates modified to allow auto enrollment will be automatically issued to
new users. Such templates can also be used to automatically replace expiring Version 1
certificates, or even be quickly pushed out to replace existing certificates.
In addition to auto enrollment, other template modifications are possible. Choices for
customization are not endless, but you can add to and modify many aspects of a template,
Customization of enrollment policies (who can enroll who)
Certificate authorization (who can authorize a certificate issuance)
Domain authentication (which domain contains the user’s account)
Certificate administrator (who manages the Certificate Authority—CA)
Enrollment agent signed (which enrollment agent is used)
Key creation (where keys are created and how)
Key type and Cryptographic Service Provider (CSP) type (which key and which CSP will
be used)
Certificate contents (what information will be included in the certificate)
Validity, issuance, and application policies and key usages (what can the certificate be
used for)
Key archiving (can the key be automatically archived)
To create Version 2 templates, you must use a Windows Server 2003 Enterprise Server. In addition,
only Windows Server 2003 and Windows XP are able to utilize certificates created with Version 2
Chapter 1
Modifying templates is not difficult, but there are some requirements. You should spend some
time evaluating your template requirements as part of your plan for your public key
infrastructure (PKI) design. The following considerations might impact the design:
If you require modified templates, your design must include a Windows Server 2003
Enterprise CA installed on a Windows Server 2003 Enterprise Server.
Although you might have mixed CA hierarchies consisting of Win2K and Windows
Server 2003 servers, only Windows Server 2003 and Windows XP computers can utilize
Version 2 certificates and the advanced features they offer.
Quick Steps to Auto Enrollment
Before you can modify templates, you must set up a Windows Server 2003 CA. The CA is
responsible for issuing certificates. Although an offline root CA is not required, best practices
include establishing a standalone root CA that you keep offline and physically secured. Although
PKI designs will vary, at least one Windows Server 2003 Enterprise subordinate CA should be
established to manage Version 2 certificates. An Enterprise CA is integrated with Active
Directory (AD). I’m going to assume for the moment that you either understand how to set up
Certificate Services or that you already have a pristine Windows Server 2003 CA in a test
environment to experiment with. To prepare User certificates for auto enrollment you have only
to do the following: Log on as an Enterprise Administrator or as a member of Domain Admins in
the root domain in the forest. Load the new certificate template snap-in either by opening it in an
empty Microsoft Management Console (MMC). Alternatively, you can click Start, Run, then
Or you can right-click the Certificate Templates folder in the Certificate Authorities console, and
select Manage, as Figure 1.2 illustrates.
Figure 1.2: Windows Server 2003 provides the new Certificates Templates MMC console.
Chapter 1
To create a Version 2 template, you must copy a Version 1 template. To do so, right-click the
template you want to copy, and select Duplicate Template from the resulting menu. A copy of
the template is made and its property pages displayed. Change the template display name (which
automatically changes the template name). This opportunity is the only one you will have to do
so. After you’ve saved the new template, you can’t change the template’s name. In Figure 1.3,
the User template has been copied and renamed User2.
You can also make other changes at this time on the various property pages. You can modify the
validity period, renewal period, and storage location of the certificate on the General tab.
Caution should be taken not to change the validity period to exceed the lifetime of the CA ticket.
No changes are made in our example.
Figure 1.3: Changing the template’s display name.
Chapter 1
Select the Request Handling tab, which Figure 1.4 shows. Because the certificate can be used for
EFS, it is tempting to select Archive subject’s encryption private key check box. However, many
other steps must be taken to make this choice usable. In addition to creating a certificate template
that allows this, a key recovery agent must be appointed and enrolled and the CA must be
configured. We’ll leave the check box clear for this example. Other adjustable items on this tab
are key size, CSP, permission to export the private key, and the requirement for user input (for
example, confirmation that a user wants a certificate) during auto enrollment.
Figure 1.4: The Request Handling tab.
View, but do not change, the Issuance Requirements tab, which Figure 1.5 shows. On this tab,
you can require approval before certificate issuance. However, requiring approval before auto
enrolment is a little counter-productive.
Chapter 1
Figure 1.5: The Issuance Requirements tab.
Select the Superseded Templates tab, which Figure 1.6 shows. On this tab, click Add to add the
user Version 1 template to the Superceded window. (Superceded templates are templates that this
new template will replace automatically.) In my design, I want only the User2 template to be
used, so I have indicated that the User2 template supersede the User template. In another design,
one in which both Windows Server 2003 or Windows XP and Win2K systems coexist, leaving
the User template available makes more sense. Win2K systems cannot use Version 2 templates
but might need to be able to enroll User certificates.
Be very careful in your design—if you intend, for example, to require key archival for certificates that
can be used for EFS, Win2K clients must not be able to obtain an EFS certificate at all. Neither the
EFS Version 1 nor User Version 1 templates can be configured for key archival, and Win2K cannot
use Version 2 templates.
Chapter 1
Figure 1.6: Identifying templates for the new template to supersede.
Select the Security tab, which Figure 1.7 shows. Select the group or groups that should use auto
enroll for this template. In my scenario, I want Domain Users to auto enroll; however, your
design might require you to create a special group. Windows Server 2003, like Win2K, uses the
discretionary access control lists (DACLs) set on certificate templates to determine who can
manage or obtain a particular certificate type. Windows Server 2003 uses the auto enroll DACL
to determine whether a group of users or computers should auto enroll the certificate.
Chapter 1
Figure 1.7: You must modify template DACLs to determine who will auto enroll.
Click OK to save the template, then close the Certificate Templates console. Open the
Certification Authority console. Right-click Certificate Templates, select New, then select
Certificate Template to Issue. In the resulting window, which Figure 1.8 shows, select the User2
template, then click OK.
Figure 1.8: The certificate must be enabled for each CA that will issue it.
Chapter 1
If you would like to replace current User certificates with User2 certificates, right-click the
Certificates container, and select Re-enroll All Certificate Holders.
Before you replace certificates, be aware of the capabilities of the certificate you may be replacing.
For an example of what you don’t want to happen, look no further than EFS. When a new certificate is
issued, subsequent files will be encrypted using the new certificate, but what about those already
encrypted? The old private key will still be needed to decrypt those files. Changing a certificate has
ramifications beyond the simple act of modifying the certificate and superceding an older one. You
must carefully consider all sides of the issue.
For more information about PKI enhancements in Windows Server 2003 and Windows XP Pro, check
Q 1.3: We’d like to use Secure Sockets Layer to secure
communications on our intranet but we don’t want the expense or
possible security risk of using third-party certificates. Is there a way
to benefit from Windows 2000 Certificate Services without deploying
Active Directory?
A: A full-blown Public Key Infrastructure (PKI) integrated with Active Directory (AD) might
be the solution for many, and third-party certificates might be the answer for others. If you
simply need a small number of certificates for internal use, Windows Server 2003 Certificate
Services can be deployed in a workgroup environment. To do so
Plan and design the PKI for secure deployment and maintenance
Install and configure Certificate Services
Use certificates
Planning for PKI
Simply installing Certificate Services is easy; however, installing Certificate Services in a secure,
sustainable manner is a lot harder to do. You use certificates because you believe they will
provide some added security, so you must learn how to protect the process and infrastructure that
produces them. If you do not, it will be as if you are storing the key to your house under a rock in
your backyard. Security is great—until someone finds the rock.
To protect your PKI, you must understand how the system works and develop strong procedures
and practices for its use and protection. You must develop procedures and policies that dictate
every step of the process, including how the Certificate Authority (CA) is physically protected,
who administers it and how, who can request certificates, and how certificates will be used in
your organization.
Chapter 1
Defining PKI
PKI is the computers and devices, programs, keys, and certificates that are used to implement
public key encryption solutions. Public key encryption involves the use of a matched key pair.
Unlike session key encryption (or symmetric encryption), which use the same key to encrypt and
decrypt, public key algorithms use one key to encrypt and another to decrypt. The public key is
widely available and the private key is kept secret. Thus, people and programs can use the public
key to encrypt, but only the owner of the key pair will have access to the private key, so only the
key owner can decrypt. A certificate is used to bind the identity of the user to the keys, and
includes a copy of the public key. Typical uses for public key encryption include secure email,
digital signatures, smart cards, and SSL.
PKI systems base their security on adherence to a trust model. Several models can be illustrated
by reviewing popular products:
Pretty good privacy (PGP), a publicly available, free solution, uses a distributed model.
There is no central source that issues certificates, and if you and I want to communicate,
we must exchange public keys. As Figure 1.9 shows, for each user to send and receive
encrypted email with others, the user must provide a copy of his or her keys to each one
of the others and they must provide the user with a copy of their keys. Each user
maintains his or her key ring.
Figure 1.9: PGP’s distributed trust model.
Microsoft’s Encrypting File System (EFS), if not reconfigured to use Certificate Services,
relies on self-signed certificates or certificates signed by the owner.
In Windows XP and later, users can distribute trust to other individuals, as Figure 1.10
shows. In this figure, User A has set up a trust relationship with Users B and C. By
storing a copy of Users B and C’s certificates, User A can then grant them the ability to
encrypt and decrypt documents originated by User A. Users B, C, and D can all encrypt
their own documents, but have not extended trust to others.
Chapter 1
Figure 1.10: In the default EFS self-trust model, users can trust others with their encrypted documents.
Windows Server 2003 Certificate Services, like those of Windows 2000 (Win2K), are
based on a centralized, hierarchical trust model. When Certificate Services are installed
on the first server in the intended hierarchy, this server becomes the Root CA. This
server’s certificate is signed by itself. This server can be used to create and sign
certificates for Subordinate CAs as well as certificates for a multitude of uses.
Certificates issued by the other CAs are trusted because their authority comes from the
Root CA, which is the source of trust (see Figure 1.11).
Figure 1.11: Subordinate Servers can trace their certificates’ source of trust back to the Root CA.
Chapter 1
In a large organization, it makes sense to distribute the PKI across multiple Subordinate CAs.
This setup allows for geographic distribution of CAs, the ability to specialize a CA in the
production of one type of certificate, and the ability to isolate, take offline, and further protect
the Root CA. Because the source of all trust is the Root CA, if it can be compromised, the entire
PKI is compromised. A large organization will also benefit from PKI’s integration with AD,
which will greatly simply many processes and offer a wider variety of features.
Enterprise and Standalone CAs
For smaller organizations, Windows Server 2003 and Win2K offer two types of CA: Enterprise
CAs, which must be integrated with AD, and Standalone CAs, which can exist in an AD
environment or used in a workgroup. Standalone CAs can participate in a hierarchy, including
one in which Enterprise CAs exist, or you can implement a single Standalone Root CA for your
certificate needs.
The Standalone CA can issue certificates for email security, securing Web servers with SSL,
server authentication, client authentication, and protecting communications with SSL or IPSec.
The Standalone CA cannot issue keys to be used for smart card authentication. However, you
might be able to store some types of keys on smart cards for use in custom applications.
There are three major differences between Standalone and Enterprise CAs. First, an ADintegrated Enterprise CA can rely on AD to authenticate the users and computers that request
certificates. An Enterprise CA, by default, issues certificates upon request and can even be
configured to automatically enroll users and computers (this feature is new in Windows Server
2003). A Standalone CA does not have a centralized directory and cannot by default
automatically issue requested certificates. Instead, certificate requests made to Standalone CAs
are placed in a pending container. An administrator must then issue each requested certificate.
After a Standalone CA has been installed, an administrator can change its settings to allow a
requested certificate to be automatically issued. However, this practice is not recommended because
anyone who can access the Web-based certificate enrollment pages can request a certificate.
Second, Enterprise CAs use certificate templates. Each certificate is assigned a purpose (or
purposes) for which it can be used. For example, an EFS Recovery Agent certificate can be used
to authorize an account to recover EFS encrypted files. By setting permissions on templates, an
administrator can restrict the use of different types of certificates to particular groups of users.
Templates also simplify the request process because a template can include much of the
necessary information and AD can provide what information the request is missing.
Standalone CAs can issue multiple types of certificates, but requestors must complete a longer
request process. In addition, you can’ restrict the use of different types of certificates to a
particular group of users. However, if a request is made for a computer certificate, the requestor
must be a member of the computer’s local Administrators group. The keys for the certificate
must be generated by the computer, and the certificate must be installed in the computer’s
certificate store. If the certificate is not placed in the computer’s certificate store, the computer
cannot use it.
Chapter 1
Third, for your certificate-reliant applications to work, the applications must be able to validate
the certificate by tracing trust from the certificate back to the Root CA. In an AD
implementation, this process is facilitated by the automatic placement of the CA Root certificate
in the Trusted Root Certificate Store of every computer joined in the domain. When you
implement a Standalone CA in a workgroup, you must find another way to do so. (If a
Standalone CA is installed on a member server in an AD domain, its certificate will be
automatically distributed to the Trusted Root Certificate Store for all computers in the domain).
A CA uses its private key to sign the certificates it issues. To determine the validity of the signature,
and thus the certificate, an application must have access to a copy of the signed certificate. The
certificate holds a copy of the CA’s public key, which can be used to test the signature on the
presented certificate. The signature is an encryption of a cryptographic hash of a portion of the
certificate. To test its validity, the application creates its own cryptographic hash of the certificate,
then uses the CA’s public key to decrypt the signature and obtain the hash produced by the CA. The
two hashes, one produced by the CA and the other produced by the application, can then be
compared. If they match, the certificate is valid; otherwise, the certificate is rejected. For applications
to access a copy of the CA’s certificate, a copy must be available in the Trusted Root Certificate
Store. Enterprise CAs and Standalone CAs installed on member servers in an AD domain
automatically place certificates in the Trusted Root Certificate Store. In a workgroup, however, you
must find a means for placing it there.
Managing CA Administration
A feature common to both Enterprise and Standalone CAs is the ability to delegate
administration of the CA by assigning permissions on the CA container. By default, the ability to
install Certificate Services requires membership in the local Administrators group in a
workgroup or in the Domain Admin or Enterprise Admin groups in a domain. By default,
members of these groups are the default administrators of the installed CA. After installation, the
right to manage the CA can be granted by managing the access control lists (ACLs) on the CA.
Four roles can be defined:
Certificate Authority Administrator—Can renew CA certificates, backup and restore the
certificate database, and deny, issue, and revoke certificates.
Certificate Manager—Can deny, issue, and revoke certificates
User—Can request certificates
Computer Administrator—Can administer the computer but has no ability to administer
the CA
The Certificate Authority Administrator and Certificate Manager roles are defined by using
ACLs. To create the roles, create two new groups (for example, IssueCerts and CertMgrs—you
might want to give these groups names that will not reveal their roles). As Figure 1.12 shows,
give the groups the Issue and Manage Certificates and Manage CA permissions, respectively. To
complete the job, remove the Windows Server 2003 Administrator groups from the permissions,
and place designated user accounts in the appropriate groups to give them CA administrative
roles. These users do not also need to be members of a Windows Server 2003 administrative
group. This setup provides an excellent use of the separation-of-duties security principle.
Chapter 1
Figure 1.12: Using ACLs to control permissions for CA roles.
Obtaining Certificates
To implement certificate-based applications, users must be able to request and receive
certificates, which can be accomplished by using Web-based certificate enrollment pages. These
pages are installed during the installation of Certificate Services (or you can install them
separately). The pages must be installed on IIS 6.0. If the CA is a member server in an AD
domain, the Web-enrollment pages can be installed on a Web server that is not on the same
computer as that which hosts Certificate Services. This setup allows a separate computer to
become a certificate Registration Authority (RA). IIS is installed on the RA, and users must
directly connect to this system to request and receive certificates. The RA is the only computer
that connects to CAs to obtain certificates, making it easier to protect the CAs. You could use
IPSec, for example, to block connections other than those to the RA. Unfortunately, in a
workgroup environment, the certificate enrollment pages must be installed on the same computer
as the CA, making this computer both the RA and CA.
Statement of Practice Policy
In addition to the policies and procedures that govern the internal management of PKI, a
statement of practice policy is an important public feature. If your Certificate Services are to be
presented to the public, to an extranet, and even to an intranet, you might want to provide a
policy statement that outlines how the system is protected and what constitutes acceptable use.
Because you want this statement to be public knowledge, you will probably post it to your Web
site. You could also make it viewable to anyone viewing a certificate or include the URL for the
policy location as part of the certificate. Such a policy statement should be developed in
conjunction with your legal department. It can be deployed by creating a text document that must
be placed in the system folder of the CA computer before the CA is installed.
Chapter 1
Best Practices
Although not every company has the luxury of long ramp up times and hired expertise, every
organization can benefit from the wisdom and knowledge of those who have developed, secured,
and maintained a PKI:
First, spend planning time to develop a policy. If Certificate Services are to be used by
the public, a legal practice policy statement is necessary. The existence of a statement of
policy is paramount, even if there is no intention to publicly publish it. The policy
explicitly specifies how the system is protected, how it is managed, and who may request
certificates. Detailed procedures, a backup and recovery plan, and a security plan are
developed from these policies.
You must protect the computer on which Certificate Services is installed. If more than
one CA is installed and a hierarchical trust established, the Standalone Root CA can be
moved offline and protected in a vault or other maximum-security environment. The
Subordinate CAs remain online and available to issue certificates. If the use of the
services is small, and appropriate planning has been done, you might take offline the
issuing CA when it’s not needed.
Care must be taken to make the certificate revocation list (CRL) and the Authority
Information Access (AIA) available elsewhere and to include information about their
location as part of the policy file or within the configuration of the CA. The CRL is
important because many applications check this list to determine whether a certificate has
been revoked. If they cannot find the CRL, they will not accept the certificate. The AIA
is important because it indicates the location at which a copy of the CA certificate can be
found. If the CRL cannot be located, and the CA certificate cannot be found, the
certificates may be useless.
Perform a test rollout. Many Certificate Services problems will be revealed and can be
CA that remains online at all times should be placed in a locked room to which few have
physical access. The server should be hardened prior to installing the CA, and it should
be kept patched and monitored for changes to security policy. The CA computer is
subject to any of the multiple physical and remote attacks that might be used against
other servers, and it is a more interesting target. If remote administration is to be used, a
protected communication channel between the remote workstation and the CA should be
used. The protected channel can be implemented using IPSec.
Local groups should be created to implement management roles.
Install IIS 6.0 or later on the computer prior to installing Certificate Services. The Web
server should not be used for anything other than the certificate enrollment pages.
Installing and Configuring
When the policies have been decided, the procedures outlined, and the practical uses for
certificates defined, it is time to install Certificate Services. As I stated in the Best Practices
section, a test implementation prior to rollout will resolve many issues.
Chapter 1
Pre-installation Practices
Install and harden a Windows Server 2003 Server. Perform a minimal install of IIS 6.0. By
leaving out extraneous services, documentation and files, you have made the server potentially
more secure. Every snippet of code in a system might hide an additional vulnerability; therefore,
it is always wise to run with minimal services installed.
Active Server Pages (ASP) are required for the Web enrollment pages. If the ability to use ASP is not
present on the Web server (and it will not be if you do a minimal install), the necessary code ability to
use ASP will be installed during the installation of Certificate Services.
Installing the Standalone Root CA
To install the Standalone Root CA, follow these steps:
1. Open the Start menu, select Settings, Control Panel, Add or Remove Programs.
2. Click Add/Remove Windows Components.
3. Select the Certificate Services check box, then click OK.
4. On the CA type page select Standalone Root CA.
5. Select the Use custom settings to generate the keypair and CA certificate check box, then
click Next.
6. On the Advanced Options page, select the Cryptographic Service Provider (CSP). The
CSP is the code that performs the cryptographic functions for the CA. The default is
Microsoft Strong Cryptographic Provider. Unless an application you are using requests a
different CSP, leave this default setting in place.
7. Select the message hash algorithm. Message hash algorithms are used to create a
cryptographic hash of portions of the certificate. It is a message digest that the private key
encrypts in a digital signature. The CA uses this function when signing the certificates
that it produces as well as for other cryptographic functions. The default is SHA-1
(secure hash algorithm).
8. Set the key length for the Root CA. In general, the longer the key, the stronger the
encryption and the longer encryption will take. The CAs will be signing certificates and
won’t be doing much encryption, so the Root CA requires strong protection. Thus, a long
key is a good idea. The default key length is 2048. Click Next.
Enter the Common Name. The Common Name is the name by which the CA will be
known (see Figure 1.13).
Chapter 1
Figure 1.13: Giving the CA a common name.
10. Enter the Distinguished Name (DN). The DN is the fully X.500 directory compatible
formatted name. It has the format CN=common name; CN= other name; DC=mydomain,
11. Accept or modify the validity period. The validity period is the time in years that the
Root CA’s certificate will be valid. (A root certificate can be renewed.)
12. Accept or modify the local storage location. A good practice is to place the certificate
database and the certificate log on separate physical disks. If the disks are also on
separate controllers, some efficiency in data writes can be gained. Default storage is in
13. Accept or modify the location of the certificate services shared folder. This location is
one of the locations for the AIA, the CA certificate, and the CPD (CRL Distribution
Point). On a Standalone CA in a workgroup, the services shared folder must be shared so
that these items can be retrieved. The default location is systemdrive\CAConfig.
14. A pop-up window will ask for the OK to stop IIS. Click OK.
15. If you did not install ASP when you installed IIS, a pop-up window will inform you that
ASP will be installed. Click OK.
16. Wait for the installation to finish.
Before you begin any other work with your CA, you should make a backup copy of the
configuration and certificate database using the Certificate Services backup program. It backs up
the CA private key, CA certificate, the certificate database, and the certificate database log. It
does not back up other important Windows Server 2003 information. For example, it does not
back up the IIS metabase (the configuration database for IIS that includes important
configuration information necessary to run the CA certificate enrollment pages), the Windows
Server 2003 registry, or other system information. A System State backup is the best regular
procedure to follow and should be performed frequently.
Chapter 1
Q 1.4: What purpose does a certificate revocation list serve?
A: A certificate revocation list (CRL), pronounced krill, is a signed list of certificates that have
been revoked. A Windows Server 2003 Certification Authority (CA) assigns an expiration date
to every certificate that it issues. The application using the certificate should be programmed to
check the date and not allow the use of an expired certificate. For example, a certificate
presented for authentication, if expired, will not be accepted. In this way, the periodic need to
obtain a new certificate ensures that certificates do not remain valid and useful forever. You can
imagine the chaos, and potential for intrusion, if authentication certificates for employees who
left the company several years ago were still valid.
How should you handle certificates that are known to be compromised, or those certificates
belonging to employees who just quit today? You would hardly want to wait until these
certificates expire for them to be invalid. For situations such as these, CA administrators have the
ability to revoke certificates.
But how do you discover that a certificate has been revoked? Asking every application to query
the CA would be inefficient, if not unworkable. Attempting to somehow round up every copy of
a certificate and mark it revoked is equally ridiculous. Enter the CRL. The CRL provides a list of
revoked certificates. When a certificate is presented, its CRL is checked to ensure that the
certificate has not been revoked. To assist in this process, each certificate can indicate the
location of its CA CRL. A Windows 2000 (Win2K) or Windows Server 2003 CRL can be
located on a Web site, FTP site, within a shared folder, or present in Active Directory (AD).
Default locations can be found by examining the CRL Distribution Point (CDP) properties of the
CA, as Figure 1.14 shows. If necessary, the default locations can be changed and/or locations can
be added. Should an application need to check the revocation status of a particular certificate, it
can query the location, download the list, and check it.
Chapter 1
Figure 1.14: The CDP lists the locations at which CRLs are published. These locations will be included in the
certificates issued by this CA.
Although this arrangement sounds perfect, several revocation and CRL considerations exist:
When should a certificate be revoked and for what reason?
Can a revoked certificate be “un-revoked”?
The CRL, once downloaded, is cached at the client. The CA periodically publishes an upto-date CRL, but the client will not download this new list immediately. Thus, the
information about revoked certificates can be out of date. How do you deal with this
As the number of issued certificates increases, the CRL grows. At some point, such a list
might become rather cumbersome. How does Windows Server 2003’s Delta CRL
manage this problem?
Certificate Revocation
You can manually revoke certificates by right-clicking a valid certificate in the CA Issued
Certificates container. To revoke a certificate, a CA administrator must provide a reason for the
revocation (see Figure 1.15).
Chapter 1
Figure 1.15: A reason must be selected when revoking a certificate.
The following list describes acceptable reasons for revocation:
Key Compromise—The location of the private key of the certificate has been
compromised. The private key is necessary for digital signature and for decrypting data
encrypted with its paired public key. If the storage area of the private key is now in the
possession of unauthorized parties, the certificate should be revoked immediately.
CA Compromise—The disk location, or token, at which the CA’s private key is stored
has been compromised. Unauthorized individuals are in possession of the private key.
Revoking the CA certificate means that all certificates signed by this private key are
considered to be revoked. The rationale behind this action is the ability of the individual
in possession of the CA to issue unauthorized certificates.
Affiliation Changed—When an employee is fired or resigns, any certificates that the
employee held should be revoked. In some institutions, the affiliation change might mean
that the individual transferred to another location or to another department. Your security
policy will dictate whether this revocation is required.
Superseded—A new certificate is issued for the user before the assigned certificate
expires. Perhaps the individual’s smart card does not work, the user has changed his or
her name, or the user has forgotten the pin or other identification token required to use
the smart card. Another reason for using this revocation is that a change has been made to
the certificate template (for example, the re-issuing of Encryption File Certificates after
the template has been redesigned to include key archival).
Cessation of Operations—When a CA is decommissioned, you provide this reason for
revoking the certificate. If a CA is no longer issuing certificates but is still publishing a
CRL, the CA certificate should NOT be revoked.
Certificate Hold—When the reason for revocation is not clear or there is a chance that the
certificate should not be revoked, use this temporary revocation reason. This revocation
assignment is the only one that can be reversed.
Remove From CRL—If a revoked certificate is “un-revoked,” it remains in the CRL, but
is marked as RemoveFromCRL.
Unspecified—If a certificate needs to be revoked but doesn’t fit the previously named
categories, you can classify it as Unspecified. However, unspecified revocations should
not be “un-revoked” as there is no audit trail listed about why the certificates were
revoked the first time.
Chapter 1
When a certificate is revoked, its serial number, the reason for revocation, and the time it was
revoked are added to the CRL on the CA. The CRL is periodically published to the locations
indicated in the CDP. The information stays on the CRL until at least one publication period
after the certificate expires. The published list is signed with the CA certificate. You can view
the current CRL by selecting the View CRLs tab of the Revoked Certificates Properties page,
which Figure 1.16 shows.
Figure 1.16: The View CRLs tab of the Revoked Certificates Properties page.
Chapter 1
On this tab, click View CRL to see a list similar to the one that Figure 1.17 shows.
Figure 1.17: The CRL.
When a certificate is presented for validation, it is checked for a CDP extension (the location of a
CRL). The CDP will indicate which protocol (LDAP, FILE, HTTP, FTP) is to be used to retrieve
the CRL and its location. The CRL will be downloaded and cached, unless a cached, valid
version exists. A cached version of the CRL will always be used if it is valid. (To delete a cached
CRL, delete all temporary Internet files.)
Some interesting logic is used to determine the validity of the CRL:
Validate the signature—Win2K and Windows XP can only natively utilize the CRL
signed by the same CA that signed the certificate in question. Windows Server 2003 can
utilize information from revocation providers such as those using the OCSP, SCVP, and
XKMS protocols. This support must be programmatically configured.
Determine the expiration date of the CRL—This date can be checked by examining the
next update field of the CRL. If this date has already passed, the CRL is considered
Chapter 1
Check the CRL for the certificate serial number—If the CRL has not expired and the
serial number of the certificate exists on the CRL, the CRL is considered valid and the
certificate is considered revoked. If the CRL has expired and the certificate serial number
is on the expired CRL, unless the revocation reason is Certificate Hold, the certificate is
considered revoked and a new CRL is not downloaded. If the serial number of the
certificate is not on the CRL or the reason for revocation is Certificate Hold and the CRL
is expired, a new CRL is downloaded and checked for the certificate serial number. (If
the reason is Certificate Hold, a new CRL must be checked to see whether the certificate
has been removed from hold status.)
If the CRL must be downloaded and can’t be found, a server offline error is generated. You
should program an application in how to respond to this error. In Win2K and Windows Server
2003, when a certificate is being used for authentication and the CRL cannot be located, the
certificate is not accepted and authentication is denied.
Each CA in a CA hierarchy generates its own CRL, and each Win2K and Windows Server 2003 CRL
will only contain records of its own revoked certificates. Although some certificate models do so,
Win2K and Windows Server 2003 don’t support any mechanism in which a CRL signed by anything
other than the issuing CA is valid. That is, a CA may not report certificate revocation information
about another CA. A revoked certificate from the root CA will only be noted on a CRL issued and
signed by the root CA, and each subordinate CA will provide its own CRL with information about
revoked certificates that it issued.
Certificate List Revocation Publishing
When a CA is installed, the publishing period of the CRL is one week. That is, a new CRL will
be published each week. This period can be modified. The validity period of the CRL should
always be longer than the publishing period to allow for AD. Because the new CRL might take
time before it is available, keeping the old CRL valid beyond the new CRL publication date
makes sense. By default, the validity period is extended by 10 percent. You can adjust the
publishing period through the CA properties, and you can modify both the publishing period and
validity period by editing the registry. The values to modify are
ame\CRLOverlapPeriod and
ame\CRLOverlapUnits. The difference can be a maximum of 12 hours, and the time period must
be at least 1.5 times the Kerberos skew time as indicated in the Kerberos policy for the domain.
Use certutil to make these changes. For example, the following command sets the overlap period
to 2 days:
Certutil –setreg ca CRLOverlapPeriod = days Certutil –setreg ca
CRLOverlapUnits = 2
The administrator might manually publish a new CRL, but this publication won’t cause a client
to download a new CRL and will not affect the set publishing period.
Chapter 1
In addition to the timing issues associated with the latency inherent in the infrequent publishing
of CRLs and the time that may be taken to replication the CRL information across the domain,
CRLs can become large and further slow processing. A base or full CRL is the complete list of
revoked certificates. Over time, this list might become quite large and unwieldy. Although the
best practice might require frequent updating of the CRL and frequent downloading of the CRL
to the client, as the list grows, this practice becomes impractical. In a large, distributed AD
infrastructure, the CRL must replicate through the structure; the latency involved might make it
impossible to appropriately manage frequent publication and distribution of the CRL.
The CRL can become large (30,000 revoked certificates can equal 1MB). If the publishing period is
short, this file being published will add substantially to the replication traffic. If the publishing period is
set longer, there is risk of not having an up-to-date CRL. Remember, an administrator can revoke a
certificate at any time, but the list is not published unless the administrator manually publishes it or
the publishing time is reached. Even if an administrator publishes a list sooner, the client will not
download it until its currently cashed list has expired.
To help solve this problem, Windows Server 2003 provides the ability to use Delta CRLs.
Introduction to Delta CRLs
A Delta CRL is an interim CRL published between the publication of base CRLs. As I
previously mentioned, a base CRL is a list of every revoked certificate. A Delta CRL is a smaller
list of just those certificates revoked since the last CRL or the last Delta CRL. (Delta CRLs are
defined in Request for Comments—RFC—2459.) When a client needs to download a CRL, the
client will automatically get the most up-to-date listing. If the base CRL has expired, the client
will download the current base CRL and any Delta CRLs that have been published since the base
CRL was published. If the base CRL is still current, the client will only download those Delta
CRLs published after the current CRL. Thus, the client needs to download the full CRL at longer
intervals, and yet the revocation information can be kept up to date by downloading smaller,
Delta CRLs at shorter intervals.
In addition, the client can be forced to download Delta CRLs even though the base CRL has not
expired. When the CRL publishing time is reached, a new base CRL is created that includes the
revoked certificates published on the interim Delta CRLs. Figure 1.18 shows an example of this
arrangement. In this figure, the base CRL is published on Tuesday and is not due for publication
again until Friday. A new Delta CRL is scheduled for publication each day. Each day additional
certificates are revoked, and each day a new Delta CRL is published. On Friday, a new base CRL
is published that includes the revoked certificates published on all Delta CRLs.
Chapter 1
Figure 1.18: Delta CRLs are issued between regular, base CRL, publication.
This model is quite simple and only meant to present the concepts behind the use of Delta CRLs.
A number of considerations are used to determine whether a Delta CRL will be downloaded:
Only Windows XP and Windows Server 2003 can utilize Delta CRLs. If Delta CRLs are
implemented, the legacy clients will continue to use the base CRLs only. This behavior
needs to be taken into consideration in planning the time between base CRL publication.
The CRL extension CRL Publication Period tells the client the frequency of CRL
publication. This setting is used by the client to determine when it should look for the
next base or Delta CRL.
The administrator can implement a freshness policy that defines the maximum
permissible age of the base or Delta CRL. A new CRL must be retrieved if the CRL is
older than this age. The age is computed as the difference between the current time and
the ThisUpdate field of the CRL.
The base CRL is stored by default in AD. Directory replication latency must be taken into
account when planning publication periods.
Delta CRL publication periods should not be less than the time it takes for AD
replication. Otherwise, it might be possible for a retrieved Delta CRL to reference a base
CRL that isn’t available to the client for download because it hasn’t replicated to the
domain controller that the client uses.
Delta CRL publication periods should not be less than the AD replication interval
configured for remote sites. Otherwise, because the base CRL of a Delta CRL is indicated
in the Delta CRL, it might be possible that a delta CRL would reference a base CRL that
was not available to the client in the remote site.
When a new base CRL is published (either automatically or on demand) it is not
immediately downloaded by the client. A new base CRL will be downloaded the next
time the client looks for a CRL and finds that it either has no base CRL in its cache or
discovers that the base CRL it possesses has expired.
Chapter 1
To determine which base CRL and which Delta CRLs are appropriate at any time, the CRL Number
and Delta CRL Indicator fields of the Delta CRL are inspected. The CRL Number is a monotonically
increasing number issued in sequence by the CA for each CRL (base and Delta) it publishes. The
Delta CRL Indicator identifies the base CRL that can be used with a Delta CRL. By inspecting the
CRL Number, the client can know whether it has all the interim Delta CRLs between the base CRL
and the highest number Delta CRL in its cache. If the base CRL cached by the client has a CRL
Number less than the Delta CRL Indicator of any of its Delta CRLs, the client will attempt to retrieve a
new base CRL.
Delta CRL Implementation
To implement Delta CRLs, you configure their publishing schedule. To do so, open
Administrative Tools, Certification Authority, right-click Revoked Certificates, and select
Properties. On the Revoked Certificates Properties page, which Figure 1.19 shows, select the
Publish Delta CRLs check box. Enter the publication interval. Click OK.
Figure 1.19: Requiring Delta CRL publication.
Chapter 1
For more information about CRLs, check out the following Web sites:
Q 1.5: If a user’s private key is destroyed or becomes corrupted can
his or her Encrypting File System files be recovered?
A: The mechanism for recovering files in Windows 2000 (Win2K) is to use a data recovery
agent. Although Windows Server 2003 still offers this option, it also lets you archive a user’s
Encrypting File System (EFS) private key and authorize a key recovery agent. To do either
requires some planning.
Key archival is the best way to go, but requires a 100 percent Windows Server 2003 enterprise.
Key archival is superior to file recovery because there is less risk of data exposure. In file
recovery, the file might be exposed because it must be decrypted by the recovery agent, then
later encrypted by the owner. Although the recovery agent does not have to open the file to
decrypt it, the opportunity for data exposure exists. If a file recovery station is used, and it should
be, the plain text file exists on the file recovery station and could be transported in clear text to
the owner. With key recovery, the files remain decrypted and in their proper location. The
original key of the user is recovered by the key recovery agent and made available to the original
owner. No files are moved or decrypted in the process.
You must, however, configure your enterprise for key archival, or key recovery is not possible.
Before users are allowed to encrypt files, establish the formal key recovery policy and configure
EFS templates, assign key recovery agents, and configure your Windows Server 2003 Certificate
Authority (CA). The following conditions must be true: The enterprise must be 100 percent
Windows Server 2003; no files have been encrypted yet, or users are ready to decrypt and reencrypt with new EFS certificates; the Enterprise CA must be installed on a Windows Server
2003 Enterprise Edition server.
Prepare the CA for Key Recovery
The CA is not configured for key recovery by default. To prepare it, you must perform several
steps before you can issue certificates that will be able to archive their private key. You don’t
have to first decide who should be the key recovery agent; the account or accounts used for key
archival should not be accounts used for ordinary user or administrator duties. These accounts
should be created for this purpose. Although they should be assigned to specific individuals
when key recovery is necessary, there is no reason to assign them before setting up key recovery.
Chapter 1
The process of preparing a user account to be a key recovery agent is straightforward. First, a
group is created whose members will be authorized to recover keys. This group must be given
the right to enroll as a Key Recovery Agent and the Manage CA and Issue and Manage
Certificate permission on the CA. To do so, open the Start menu, click Administrative Tools, and
select the Certification Authority console. Permissions on certificates can be managed by rightclicking the Certification Authority\name of CA container and selecting Manage. In this window,
right-click the Key Recovery Agent certificate, and select Properties. On the Security tab of the
certificate (see Figure 1.20), add the group you have created (Key Agents created in this domain)
and assign the Enroll permission. If your policy calls for it, you should also remove the Enroll
permission from the Domain Admins and Enterprise Admins groups at this time. Create user
accounts in Active Directory (AD) and add them to the key recovery agents group.
Figure 1.20: Give the key recovery group permission to obtain the key recovery certificate.
Next, the Key Recovery Agent certificate must be enabled for the CA. To do so, right-click
Certificate Templates, select New, then Certificate Template to Issue. In the Enable Certificate
Template dialog box, select the Key Recovery Agent (see Figure 1.21), and click OK.
Chapter 1
Figure 1.21: Enable the Key Recovery Agent certificate for the CA.
After the certificate is available, each user account, which will be used for key recovery, must
request its key recovery agent certificate. If users have not been assigned, an administrator can
log on as one of the approved key recovery agent accounts to obtain the certificate. An
administrator should not retain control over this account. To obtain the certificate, log on using
the selected Key Recovery Agent account. For the following example, we’ll use the account Joe
Use Internet Explorer (IE) to browse to the CA Web location—http://certserver/certsrv (where
certserver is the name of your CA). Click the Request a Certificate task, click the Advanced
Certificate request link, click Request and Submit a request to this CA, and in the Certificate
Template drop-down box, select Key Recovery Agent (see Figure 1.22). Next, click Submit. You
will be informed that the request must be processed by an administrator and to return for your
certificate later. Use Run as to open the Certification Authority console. Open the Pending
Requests container. Locate the recently requested certificate, right-click it, and select Issue.
Close the console, thus returning to your IE session as the agent, and return to the CA Web
location (for this example, http://certserver/certsrv). Select View the Status of a pending
certificate request, click on the certificate, click Install this certificate, and repeat this process for
each Key Recovery Agent.
Chapter 1
Figure 1.22: Request a Key Recovery Agent Certificate.
Before keys can be archived, the certificates issued for Key Recovery Agents must be assigned
to the CA. To do so, right-click the name of the CA in the console, and select Properties. On the
Recovery Agents tab, select Archive the Key under Do the following when a certificate request
includes key archival. Enter the number of recovery agents to use in the text box provided. For
each recovery agent, add its certificate by clicking Add and selecting it from the provided list,
then clicking OK. A certificate icon with a red circle and a white cross over it will appear in the
Certificates window. The status listed is Not Loaded. When you have added them all, click
Apply, and click OK when prompted to restart the service. After the service has restarted (you
might need to close and open the properties page), the red circle with the white cross should be
gone and the status should be Valid (see Figure 1.23).
Chapter 1
Figure 1.23: Assigning the Key Recovery Agent Certificate to the CA.
Another check of the status of Key Recovery Agent certificates can be made by opening the
certificates console for the CA computer. The KRA certificate store, when inspected, should
contain valid certificates for the Key Recovery Agents assigned (see Figure 1.24).
Chapter 1
Figure 1.24: Checking that Key Recovery Agent certificates have been assigned to the CA.
Prepare EFS Custom Template for Key Archival
Now that the CA is prepared, it’s OK to prepare the EFS certificate for key archival. To do so,
you must create a custom template. This process is described in Question 1.1. In short, a custom
template is created by duplicating an existing template, then modifying its properties. After
duplication of the EFS Basic template, one change must be made for key archival, another
change is optional. As Figure 1.25 shows, on the Request Handling properties page, select the
Archive subject’s encryption private key check box.
Chapter 1
Figure 1.25: Configuring EFS custom template for key archival.
If EFS has been in use in your enterprise, it is a good idea to supercede the basic EFS template
with the new one. Otherwise, until users request a new EFS certificate, their files will continue to
use the basic template, which does not offer key archival. You can automatically require that the
old template be superceded by entering its information on the Superceded Templates property
page. Simply click Add, and select it from the list, then click OK. Figure 1.26 shows the page
after this entry. When the new template is complete, it can be added to the CA in the manner
previously described for the Key Recovery Agent certificate.
Chapter 1
Figure 1.26: Requiring that the new certificate supercede the old.
Using the New Certificates and Recovering Keys
Now that the certificates are ready and a Key Recovery Agent has been assigned to the CA, users
must request the new certificates. If you configured the new EFS certificate to supercede an older
EFS Basic certificate, the user will automatically receive a new certificate; however, if the user
has been using a self-signed certificate, the user must replace it by requesting a recovery
certificate. This action can be done from the Certificates console or from the certsrv Web page.
To verify that the issued EFS certificates have archived their keys or to validate that an archived
key exists before attempting recovery, you can view its status in the Certification Authority
console. You might need to add the column Archived Key; you can do so from the View menu
by selecting Add/Remove Columns while the Issued Certificates container is open. After the
column has been added, it will display a Yes to tell you which certificates have valid archived
private keys (see Figure 1.27).
Chapter 1
Figure 1.27: The Archived Key column.
Users encrypt and decrypt files in the ordinary manner. However, if a user’s private key is lost or
becomes corrupt, you now have a way to retrieve the key. To do so, as Administrator, view the
certificate of the user by double-clicking it in the Issued Certificates container of the CA. Select
the Details page, and write down the certificate’s serial number. (The serial number of the
certificate is the serial number of the private key, and is a 20-digit hexadecimal number.) Close
the Certificate Authority console, and give the Key Recovery Agent the serial number. The Key
Recovery Agent logs on. (From here, the Key Recovery Agent is doing the recovery. The Key
Recovery Agent does not need to be a member of any administrative group.) At the C:\
command prompt, enter the following command to recover the key (see Figure 1.28):
certutil –getkey serialnumber outputblob
Figure 1.28: Key recovery.
Chapter 1
Dir outputblob
to determine whether the file was produced. If it was not, it might be because you have entered
the serial number incorrectly. The outputblob file is placed on the hard drive. To retrieve the key
and create a certificate file that the user can import to his or her certificate store, issue the
following command (see Figure 1.29):
certutil –recoverkey outputblob username.pfx
When prompted, provide a password and confirm it. The pfx file and the password should be
delivered to the user in a secure manner. The certificate and private key can then be imported
into the user’s personal certificate store.
Figure 1.29: Creating the certificate file for transfer to the user.
The outputblob file is a PKCS#7 file. It contains the KRA certificate, the user certificate, and chain and
Inner content—an encrypted PKCS#7 containing the user’s private key. When the Key Recovery
Agent uses the RecoverKey command, the user certificate and private key is extracted into a
PKCS#7 file suitable for import into the user’s certificate store. A password is placed on this file to
prevent tampering.
Chapter 1
Q 1.6: The financial managers group would like to be able to encrypt
meeting minutes and share them. How do I set this up for them?
A: Unlike Windows 2000 (Win2K), Windows XP and Windows Server 2003 can be configured
to allow users to share encrypted files. The process is not complex, but requires you to complete
a number of steps and employ several best practices to ensure the security of the files as well as
provide for data recovery should encryption keys be damaged or lost.
Best Practices and Caveats
A number of security and practical issues should be addressed before implementing a shared
environment for encrypted files:
Education—Administrators and users should be educated in the specifics of file
encryption. Although a folder can be set to automatically encrypt files saved or moved to
its location, thus making the actual encryption and decryption of data files transparent to
the user, several actions might render the supposed encrypted file to be decrypted and
therefore available to those who should not have access. A notice is not always given
when an action will decrypt a file. Every participant should be instructed about these
areas, including:
Copying an encrypted file to a drive formatted as FAT (including floppy
disks) will decrypt the file (see Figure 1.30).
Figure 1.30: Warning that a file will be decrypted if copied or moved to a FAT-formatted drive.
If an encrypted file is copied over the network to a shared folder, it is first
decrypted locally, then re-encrypted at the server (if the server has been
configured to store encrypted files). Thus, the file traverses the network in
clear text. If the data is captured, it can be read.
If an unencrypted file is placed in a folder not marked for encryption, the
file will not be encrypted.
If a folder’s encryption setting is removed, new files placed in the folder
will not be encrypted, but the files already encrypted will not be decrypted.
Chapter 1
Recovery—Windows XP and Windows Server 2003 do not require that a recovery agent
be present for files to be encrypted. Self-signed certificates will be issued to any user the
first time the user encrypts a file. Thus, unless registry settings (or a corresponding
policy) have been changed to disable this feature, any user can encrypt files and the
potential for data loss is great because a recovery agent isn’t required.
Recovery agent keys can be created and placed into action. Files encrypted before they
are configured will not be recoverable.
A recovery policy and procedure needs to be in place before files are encrypted. Who will
be able to recover files? How should they do so? How should recovered files be handled?
Key backup—Encryption keys should always be backed up. There have been many cases
in which user and recovery agent keys were both destroyed, leaving data unrecoverable.
Data location—If users are going to share encrypted files, where will the data be located?
If the data will be on a network share, precautions for securing the data as it traverses the
network should be made.
In the case of sharing encrypted files, users and administrators need to realize that once a
user has shared the ability to encrypt and decrypt the file with another, that user has the
ability to share the ability to encrypt and decrypt the file with others as well. File
permissions should be used in conjunction with file encryption to ensure that data is not
provided to unauthorized individuals.
File auditing should be established to record file access and determine whether attempts
are made by unauthorized individuals. Files should be audited for failure and success:
Audited for failure to determine whether any attempts were made, and audited for success
to if the attempts were successful.
The physical location for the files is important, and the server or workstation where they
are located should be physically protected. (The specific computers involved should be
The users involved should be required to use strong passwords. Remember, if someone
can deduce the password and log on as that individual, that person can decrypt the file.
Recovery agent(s) should be created before the first file is encrypted. A recovery agent is
a role represented by a user account and a recovery certificate and its matching private
key. The recovery agent role does not have to belong to a specific individual; however,
the policy for its management and use should be determined. The recovery agent private
key should be archived, removed from the system, and kept in a safe place. The private
key is not necessary except to recover files.
Chapter 1
It is my opinion that most organizations should disable EFS until and unless they are willing to
invest in the establishment and maintenance of a Public Key Infrastructure (PKI). Only with a
well-designed PKI can you establish data (or, in the case of Windows Server 2003, key )
recovery considerations. The past years of data loss due to improper management of file
encryption keys is testimony to this fact. However, I’m willing to agree that it is possible to
safely utilize EFS without an investment in a PKI. Such can occur in a situation in which small,
manageable groups require sensitive data management; they are willing to invest in the
procedural safeguards necessary to ensure data recovery; they are willing to provide the
educational process to prevent unnecessary or inadvertent exposure of data files; and backup of
encryption keys is followed religiously.
How the Sharing of Encrypted Files Works
Before setting up secure shared encrypted files, you should know how and why this feature
works. This information will help you to trouble shoot problems, and prevent you from
inadvertently exposing files. First, make sure you understand the basic file encryption algorithm.
When a file is encrypted, a symmetric key is created and used to encrypt the file. It is not reused.
Symmetric key encryption uses a single key to encrypt and decrypt. Figure 1.31 illustrates this
concept. In EFS, the key used to encrypt the file is called a File Encryption Key (FEK).
Figure 1.31: Illustration of symmetric encryption.
Next, the public key of the user who has requested that the file be encrypted is used to encrypt
the FEK used in step 1. Public key encryption, unlike symmetric key encryption, is asymmetric,
that is it uses a key pair. One key is used to encrypt, and the other to decrypt. Figure 1.32
illustrates this concept.
Chapter 1
Figure 1.32: Illustration of asymmetric encryption.
The encrypted FEK is placed in a field called the Data Decryption Field (DDF). If, and only if, a
recovery agent exists, the public key of the recovery agent is used to encrypt the FEK and the
result is placed in the Data Recovery Field (DRF). Figure 1.33 illustrates these processes.
Figure 1.33: Illustration of file encryption.
Now the file is encrypted. To decrypt the file, it is necessary to have the key that is the other part
of the key pair for either the user who encrypted the key or, if a recovery agent exists, the
recovery agent key. This key is called the private key. The process is as you might expect: The
user’s private key is used to decrypt the encrypted FEK, which is available in the DDF. The FEK
is used to decrypt the file (see Figure 1.34).
Chapter 1
Figure 1.34: Illustration of file decryption.
If the recovery agent’s private key is used to decrypt the encrypted FEK, which is available in
the DDR, the FEK is used to decrypt the file. Figure 1.35 illustrates the recovery process.
Figure 1.35: Illustration of the recovery process.
Have you deduced a way that multiple people can share encrypted files? You’re right if you
guessed that you can allow multiple users’ public keys to encrypt the FEK, and add the result to
the DDF. The ability to share encrypted files in Windows XP Professional and Windows Server
2003 is possible because both OSs allow DDFs to contain a FEK encrypted by a different users’
public keys.
The only piece of the puzzle left: How does the file system know which users’ public keys to use
and where to find the keys? Here’s how it works: A user encrypts a file. After the file is
encrypted, the user can right-click the file, select Properties, click Advanced, then click Details.
The encryption property page shows which account was used to encrypt the file as well as which
recovery agent account was used (see Figure 1.36).
Chapter 1
Figure 1.36: Viewing encryption details.
This knowledge is useful, use it! You do not need to be the owner or the one who encrypted the file to
see who encrypted it and which recovery agent can be used to recover the file.
By clicking Add, the user can select additional users to whom the user wants to give the ability
to decrypt and encrypt the file. A copy of the encrypted FEK is decrypted using the user’s private
key. (The original encrypted FEK remains in the DDF.) The FEK is encrypted using the public
key of the each selected user and placed in a new DDF field.
After the process, information about every user who can decrypt the file is shown on the
encryption details page. For this process to work, several things are necessary:
The user who encrypted the file must select who can encrypt the file.
The certificates for those users that the original user wants to add must be in that user’s
Trusted People certificate store.
The pubic and private keys of the users who will be encrypting and decrypting the files
must be available (typically through the profile).
Chapter 1
Step-by-Step Process to Secure Shared Encrypted Files
So, you’ve educated your administrative staff and users. A policy is written and procedures for
use and recovery are in the works. How do you establish shared encryption files for the financial
management group? I’m going to detail two scenarios. The first one is simple to set up, though
somewhat awkward for users. The second is more convenient for users, but more difficult to set
up and protect. (The second scenario involves the use of a network file share, which requires an
additional step, securing communication, which is not detailed in this answer. Check out
Question 8.6 for more information about this step.) As I previously mentioned, each user and
administrator must be educated about the use of EFS as well as potential problem areas.
Simple EFS Sharing
In this scenario, a Windows XP Professional computer, computer Z, is designated as the
repository for the encrypted files. The computer is hardened and physically secured. Local
accounts will be used. Three folders are designated for use in setting up the process: Folder A is
marked as encrypted and will be used during setup. Folder B is not marked as encrypted and will
be used during setup and to store a copy of each user’s certificate. Folder C will be used to store
the shared, encrypted files. Two processes are required, one to set up each user, and the other to
share the files. When every user has completed the first four steps and the user in charge of the
shared files has completed the rest of the steps, the users will be able to log on and decrypt the
file. Each time a new file to be shared is added to Folder C, the user in charge must repeat Step 8
(of the following sequence) before other users will be able to decrypt the file. First, a recovery
agent is created. Next, users are set up using the following steps:
1. User logs on to computer Z.
User creates a file in Folder A. Because Folder A is marked for encryption, the file will
be encrypted and a key pair and self-signed certificate will be created for the user. A selfsigned certificate is merely one which is not signed by a Certification Authority (CA).
3. The user exports or archives a copy of his or her certificate, placing the copy in Folder B
(instructions for this process follow). It is not necessary to include a copy of the user’s
private key in this export. This point is also a good time to create an archive of the
certificate and private key for backup. This copy should not be stored online; instead it
should be placed on a floppy disk or CD-ROM and stored in a safe place.
4. The user logs off.
5. Steps 1 through 4 are repeated for each user who will have access to encrypted files.
When a user logs on, a profile for the user is created. A copy of the user’s certificate and
private key are stored in the profile.
6. The user who will be in charge of the files to be shared logs on and creates a file to be
shared in Folder C. All files to be shared will be created in Folder C.
7. The user then opens his or her certificates store, navigates to the Trusted People store,
and adds the certificates created in Step 3—one for each user with whom the user will
share the encrypted file.
Chapter 1
8. The user opens the EFS details page for the encrypted file and adds the users. (Their
names will show up as available after their certificates have been placed in the user’s
Trusted People certificate store.) The user then closes the page. Any designated user can
now log on and read the encrypted file.
To export certificates only, the user opens a Microsoft Management Console (MMC), selects
Add/Remove Snap-in from the File menu, clicks Add, selects Certificates, clicks Add again,
clicks Finish to select the user certificate, then clicks Close. Next the user clicks OK to return to
the console, then selects Save As from the File menu to save the certificates console for later use.
A good practice on a computer to be used by multiple users is to name the console using the
user’s initials or other identifying information. The user then right-clicks the user certificate
(expand the Personal Store, and select the Certificates folder), selects All Tasks, then selects
Export the certificate, and clicks Next on the Welcome page. The user then clicks Next twice to
accept the default settings (no private key is necessary for our purposes; however, a private is
required for archival purposes, and the user would need to adjust the request accordingly),
browses to Folder B, names the file, selects Next, then selects Finish to export the certificate and
close the wizard. Finally, the user needs to click OK to close the pop-up message that notifies
you that the export has been successful.
To add certificates to the Trusted People store, you open the Certificates console, right-click the
Trusted People certificates store, select All Tasks, then select Import, and click Next on the
Welcome page. Browse to the location for the certificates stored in Folder B, select a certificate
file, then click OK. The certificate is added to the Trusted People store. Repeat as necessary.
To share an encrypted file, navigate to the file in Windows Explorer, right-click the file, select
Properties, click Advanced, then click Details. On the Details page, click Add. The users whose
certificates have been added to this user’s Trusted People store will be displayed (see Figure
Figure 1.37: Viewing the users’ certificates with whom you want to share access to the encrypted file.
On the Add user page, select the user to share the file and click Add. The user is added and his or
her certificate is used to encrypt the FEK. The details page now displays the users who can
encrypt and decrypt the file (see Figure 1.38).
Chapter 1
Figure 1.38: Viewing which users can transparently access this encrypted file.
EFS Sharing on a Share
It might be more convenient to store encrypted files on a folder share. However, additional steps
are necessary to make this setup work and to ensure the security of the file. First, if the files are
available via the network, additional vulnerabilities exist, and care must be taken to ensure the
security of the file server, its file shares, and traffic to and from the server. Second, each user will
probably be using his or her desktop to access the files. The precautions you should take depend
on the nature of the files, the location of the file server, users, and so on. At a minimum, the
shared folder permissions should be restricted to those users who need to have access to the files,
file permissions should ensure that files are not deleted or accessible to those other than intended,
and traffic between users’ computers and the file server should be protected. Communication
protection could take the form of a virtual private network (VPN) or IPSec.
It should be clear from the previous discussion that both user certificates and private keys must
be available on the file server if users are to connect and encrypt and decrypt files. After that is
accomplished, a process similar to that already discussed must be followed (that is the user in
charge of the files must include the certificate for each of the group’s users in his or her Trusted
People store, and the user must add each user to the encryption properties details page of each
file the users will be allowed to encrypt and decrypt).
Chapter 1
The considerations that result from users’ certificates and private keys being available can be
resolved by using roaming profiles for these users and by having the roaming profile location be
on the file server. The shared folder could include three folders set up like Folders A, B, and C
from the previous example. In such a situation, each user would do the following: Log on to the
domain. This step creates the user’s profile on the file server in the profile folder designated in
the user’s account. Next, the user would need to connect to the share, then create a new file in the
encrypted Folder A. Doing so will create a certificate and private key for the user. Finally, the
user needs to export a copy of his or her certificate, and place it in non-encrypted Folder B, then
connect to the share and encrypt a file to obtain his or her certificate. The user in charge of the
files can then access each certificate and put a copy in his or her Trusted People store, create the
files to be shared in encrypted Folder C, and add each user to the encrypted details properties of
the new file.
Chapter 2
Chapter 2: Securing Web Services and Web Servers—the
Administrative Perspective
Q 2.1: I’ve just been reading about the dangers of allowing services to
log on using the Local System account. Isn’t this account the one that
the World Wide Web Service uses? Is there something I can do to
mitigate the risk?
A: Yes, the Local System account is the account used by the World Wide Web Service to log
on. Thus, in versions of Internet Information Server (IIS) earlier than 6.0, all processes that are
run within the Inetinfo service (the IIS Web service) ultimately run under the context of the
Local System account. IIS 6.0 will be able to run under the context of a less privileged account.
An application running as the Local System account has access equivalent to that of the
operating system (OS). This access can, to put it mildly, be a bit of a security problem. Should a
running application be compromised, an attacker might be able to gain control of the entire
computer with access to all files and folders. The attacker could destroy data, copy Trojans and
other malicious code to the system, retrieve sensitive data, use this system as a launching pad to
penetrate other systems on your network, and so on. Of course, other defensive measures on the
network as well as on the Web server system can help prevent these actions or at least mitigate
their impact. Before I describe the changes to IIS 6.0, let’s take a good look at application
processing in IIS 5.0.
Understanding IIS 5.0 Application Privileges Processing
When a user connects to an IIS server on which only anonymous access is allowed, the
IUSR_machinename account is used to authenticate to the system. The privileges and object
access granted to this account determine what the user can do. Part of your job in securing IIS is
to restrict this account to only the privileges and file and object access that is required, and to
deny the account access to sensitive processes and objects. Then an attacker must elevate the
privileges of this account, say to Administrator or even that of the OS. Your job is to make sure
that this attack can’t happen by patching known vulnerabilities and following sound
administrative practices that mitigate the risk should some new exploit be discovered.
The user is initially restricted by the amount of access given the IUSR_machinename account.
However, if a faulty Web application or IIS process is attacked or an attacker is able to run code that
contains a call to the RevertToSelf API, it is possible for the attacker to run code of his or her choice
in the security context of IIS itself. The security context under which IIS (Inetinfo.exe) operates is that
of the account that this service uses to log on, the Local System account.
Chapter 2
To prevent an attacker from gaining control, you can follow these sound practices:
Don’t run Web applications in-process. Web applications can be run in-process or out-ofprocess. Applications running in-process run in the context of Inetinfo—the IIS Web
service that runs as Local System. Applications running out-of-process run in the context
of the IWAM_machinename account, a less privileged security context. When an
anonymous user runs a Web application, the application impersonates the user and runs
in the IUSR_machinename security context. During an attack, the security context of the
running code may be changed to that of the process. There may always be problem code
that can be broken and allows the changing of security context from IUSR_machinename
to that of the process. If this attack happens, would you rather have an attacker’s code run
under the Local System account or the less privileged IWAM_machinename account?
Crashing a running process that is running out-of-process will leave the system in the
context of the IWAM_machinename account, not the Local System account.
The IWAM_machinename account is an unprivileged account by default, and the default status for
running Web applications is medium, which means they run out-of–process. Processes running within
Inetinfo, however, get better performance, so someone may have changed the status to low (running
within Inetinfo).
Give only privileges and access to the IUSR_machinename and IWAM_machinename
accounts. Audit frequently to detect any changes to the privileges and access assigned to
these accounts.
Do not write applications that include calls to RevertToSelf. However, if you must, make
sure these applications run out-of-process. Uploading or finding a resident application
that includes a RevertToSelf call will benefit the attacker very little if the process is
running out-of-process and the IWAM_machinename account has limited privileges and
A handy tool, dumpbin.exe, which is part of Visual Studio and is available with the platform software
development kit (SDK), can be used to search DLLs for calls to RevertToSelf. To prevent an attacker
from uploading his or her own code that contains these calls, use access permissions to prevent the
uploading of files to directories that also include the execute permissions.
Use access permissions to prevent an attacker from uploading his or her own code. If you
must provide folders with write access, make sure that script and execute access are not
also available on these same folders.
Apply the hotfix MS01-026
( to
prevent an attack that allows an end-run to require a process to run out-of-process. Without this
patch, an attacker might be able to cause code to run within the Inetinfo.exe process even if the
process is assigned to run out-of-process.
Chapter 2
How IIS 6.0 Solves the Problem
IIS 6.0, the version of IIS that will be available with Windows Server 2003, has two ways to
prevent these types of attack. First, Inetinfo.exe can be run under the context of a new built-in
account that has very few privileges, NetworkService. Second, IIS has a different architecture.
IIS 6.0 provides a new application-isolation environment that seeks to provide a more stable,
fault-tolerant architecture that will be less vulnerable to attacks and more self-healing. (Who
cares if you can crash a process if when you do so you gain no privileges, no access to data, no
data is lost, and the process begins running again on its own?) Figure 2.1 illustrates IIS 6.0
Figure 2.1: The IIS 6.0 architecture.
Three basic elements of the architecture lessen the opportunities for privilege-escalation attacks:
IIS 6.0 separates Web server code from application-handling code. In the original design,
IIS had one process, Inetinfo.exe. In later revisions, this process was modified to allow
requests to one or more out-of-process applications. IIS 6.0 uses three components: an
HTTP listener (http.sys), Web Administration Service (WAS), and an application
handler. The application handler is loaded into its own worker process that services
requests from the HTTP listener (http.sys).
Chapter 2
No third-party code runs in http.sys or in WAS. All third-party code must run in user
mode, and http.sys runs in kernel mode. Http.sys cannot be crashed by user-mode code.
Should there be a Web service problem in request handling, http.sys can continue to
queue requests for any Web service that is up and running. The Web service will restart
crashed worker processes (mini-Web server processes) if there are requests still queued.
WAS is the home of Web server configuration and process management.
In IIS 6.0, all application code runs in an isolated environment; there is no such thing as
an in-process application. No malfunctioning Web application can disrupt another Web
application or a Web site that is run from other worker processes. (Worker processes run
within application pools. Application pools define Web applications that might share one
or more worker processes.) Each worker process can be configured to run under the
context of a different account.
Q 2.2: I keep hearing about the new NetworkService account in
Windows Server 2003. Microsoft says that this account is less
privileged than the Local System account but doesn’t explain what
that means. Any ideas?
A: Most services in Windows 2000 (Win2K) run under the Local System or SYSTEM account.
Thus, they operate with 21 security privileges. Services, then, can do just about anything,
whether they need to or not. Because of this power they often attract privilege escalation attacks
that are successful. If an attacker can break the service, the attacker might be able to run code
under the security context of the operating system (OS), and thus fully own that system.
Microsoft has long indicated that best practices require services to run under the least privileged
account possible but has not provided much help for those who want to restrict the services that
Microsoft provides. The NetworkService and LocalService accounts are two new accounts in
Windows XP and Windows Server 2003 that are suitable for use by many services. (For
information about the Local System approach vs. Windows Server 2003’s approach, see the
sidebar “Privilege Best Practices.”)
One of the prime candidates for the NetworkService account is IIS 6.0. In Windows Server 2003, IIS
will install as a static Web server, and requires very few privileges to run. Expectations are that Web
masters that require additional abilities will add the abilities as they are needed and adjust the
privileges of the service account if necessary. This administrative method is an about-face from the
traditional Microsoft everything-is-on out-of-the-box configuration.
If the two accounts have the same privileges, why are there two? The answer lies in how the OS
makes use of each. A service running in the security context of the LocalService account will
access a remote system anonymously. Let’s pretend that a service running on computer
LocalDesk attempts to connect to a network share on FileSrv2. If anonymous privileges are
appropriately curtailed on the remote system, access will be denied. If we change the account
assigned to the service to NetworkService and attempt to access the same share, we might
succeed because the service is now accessing the remote system FileSrv2 as the local computer
LocalDesk. If the computer account LocalDesk has been give appropriate privileges on the share
on FileSrv2, it will be able to connect.
Chapter 2
These conditions help to set some guidelines for the use of these new accounts. If a service does
not need network access privileges, use the LocalService account. If it does, use
Privilege Best Practices
It’s difficult to think rationally about this topic. On one hand, everyone can understand that running a
service with an account that only has the privileges it needs is a good thing. It follows the security dictum
of least privilege. On the other hand, creating and maintaining a large number of accounts—one for each
service—could be an administrative nightmare. Although creating the account and assigning privileges
could be a function of the service installation, how can passwords be easily maintained? I can understand
why using Local System seemed to be easy, but I believe it has contributed to the problem. After all,
processes running with bloated privilege assignments eventually expand their operations to include the
use of those privileges, and therefore make it harder to replace the Local System account with a less
privileged account—no one knows anymore what the process really needs. Windows Server 2003‘s
approach is long overdue. Less privileged, yet default, accounts are present, and services can be
designed around their use.
What Can the NetworkService Account Do?
In Writing Secure Code (Microsoft Press, 2001), David LeBlanc and Michael Howard report
four privileges for both accounts: SeSystemtimePrivilege, SeAuditPrivilege,
SeChangeNotifyPrivilege, and SeUndockPrivilege. In an April 2002 Microsoft TechEd session,
five privileges were identified. This disparity is not at all uncommon in a product under
development. It is sufficient to say that the number of privileges for these accounts lies far shy of
those of Local System. An explanation of NetworkService’s account privileges as identified at
the April TechEd session is shown in Table 2.1.
Required for
Required to generate audit log entries.
Required, along with
SeAssignPrimaryTokenPrivilege to access a process
token and create a new process that uses the
security context of the user of the other process—
possibly resulting in a privilege escalation.
Required for
Interface (CGI)
Required, along with SeIncreaseQuotaPrivilege, to
access a process token and create a new process
that uses the security context of the user of the other
process—possibly resulting in a privilege escalation.
Required for
CGI programs
This privilege lets a user receive notification of
changes to files and directories. It is used to bypass
directory traversal checks and for NTFS optimization.
Required to remove a computer from a docking
Table 2.1: Explanation of the NetworkService account’s privileges.
Chapter 2
What Can the Local System Account Not Do?
Everyone complains that the Local System account has too many privileges to be used to run any
service. It is true that this account essentially operates as the OS and has more privileges than the
Administrator account. But is it all-powerful? Let’s consider what it can’t do. It can’t shut down
remote systems. This inability makes sense—what business would it have shutting down remote
systems? It also can’t create a new computer account, synchronize directory service data, or
enable computer or user accounts for delegation. If these limitations seem strange to you, look
closely. In every case, these privileges have a more global effect. In other words, they allow
management of systems in the domain, and this ability exceeds the security boundary of the local
computer. In its own realm, Local System is still the most powerful account.
Finding the privileges of a running process is not something you will find listed in the application
documentation. The reason is that the process runs in the security context of the user account that is
running it. Services, of course, run in the security context of the account used to log on the service
during startup. If these accounts are standard OS accounts, you might be able to find a list of
privileges assigned to them in Microsoft’s documentation. If you would like to find out the privileges in
real time, you can compile and run the Token Monitor application provided in Writing Secure Code.
Q 2.3: I’ve heard that the new Windows Server 2003 Web Server is
installed as a hardened Web server. Do I need to do anything to
ensure that I have a secure Web server or can I simply bring up this
system with a default installation and not worry about it?
A: Microsoft has identified several new security-relative modifications to IIS 6.0. One of the
most exciting changes is that a default IIS 6.0 Web server installs in a simple state. To use some
of the more advanced (and harder to secure) features of IIS, you will have to install them. Thus,
instead of having many features that you might not need turned on, your IIS server will start with
minimal functionality. As you know, the fewer features a product has, the less opportunity there
is that some new vulnerability is discovered. You can easily enable more sophisticated features
as you need them.
Installing IIS 6.0 on Windows Server 2003 (Standard or Enterprise editions) is different than
installing the Windows Server 2003 Web Server. The Web server edition of Windows Server
2003 is meant to be an inexpensive Web server. It lacks many of the standard Windows Server
2003 features and installs the OS and IIS during the same process. The other Windows Server
2003 server products do not install IIS by default. (You can install IIS on these systems, and the
process actually offers much more control to the installer than is given during the installation of
the Windows Server 2003 Web Server.) With either option, there are decisions to be made that
might mean a more secure Web server.
During the installation of IIS 6.0 on a Windows Server 2003 system, you have the choice of whether
to install Background Intelligent Transfer Service (BITS), Simple Mail Transfer Protocol (SMTP),
Network News Transfer Protocol (NNTP), File Transfer Protocol (FTP), FrontPage Server Extensions,
remote administration tools, and the scripts virtual directory. During the installation of Windows Server
2003 Web Server, many of these items are not installed, and the choice is not offered to the installer.
Chapter 2
Installing the Windows Server 2003 Web Server
Windows Server 2003 Web Server is a version of Windows Server 2003 that Microsoft meant to
be deployed as a Web server only. Do not assume that this product, although it does reduce
vulnerability by not including some default features, will automatically install as a hardened
server. There are additional installation steps that you should take, options that you should avoid,
and post-installation configuration that you should perform to improve security. The following
steps discuss the installation process with a focus on improving security. These steps follow two
premises that you apply to any installation:
Don’t select installation options just because you can.
Remove options that are not necessary.
If you typically develop automated-installation processes to fulfill your requirements for
unattended installation, review these steps and determine how your unattended installations can
follow the same principals:
1. Format and wipe the hard drive. A new installation should always be made on a clean,
newly formatted drive to ensure that old data or software is no longer on the drive.
2. Ensure that the computer is separated from the production network and the Internet to
prevent possible infection or compromise during the installation process.
3. Boot from the Windows Server 2003 Web Server CD-ROM or use a network boot disk to
access a network installation point.
4. Follow instructions to continue the setup until you reach the Setup Options page. On this
page, click Advanced.
5. Change the name of the default system folder from WINDOWS to something else, and
click OK. Although it is easy to discover the system folder, unsophisticated scripts look
for it by the default name. Changing the name is a small act that could prevent such a
malicious script from doing any harm.
6. Click Accessibility Options, and select the option to use Microsoft Magnifier or
Microsoft Narrator for use during setup, if you desire. Click OK.
7. Back on the Setup Options page, select the primary language, then click Next.
8. The Preparing Installation phase follows the standard for Windows server installs (the
system copies files, reboots twice, and offers to install third-party SCSI drivers, repair or
quit, partition the disk, format drives, and so on).
9. On the Regional and Language Options page, click Customize to review or set regional
options such as number, date, and time formats.
10. On the Languages tab, click Details. On the resulting page, you can enable extended
support of advanced text to services to all programs. If you select this check box,
Notepad and other programs that do not normally support speech and handwriting
recognition will be configured to do so. I can’t think of any reason for including this
functionality on a Web server. You can also configure the system to support additional
input methods and extra language support. Again, if not absolutely needed, do not install
extra features. When in doubt, don’t install. If you discover later that a feature is needed,
you can install it. Click OK to return to the Regional and Language Options page.
Chapter 2
11. Select the Advanced tab on which you can select support for non-Unicode programs. This
support enables non-Unicode programs to display Windows menus and dialog boxes in
their native language. Again, unless this functionality is needed in your environment,
don’t select it. Click OK to move on.
12. On the Personalize Your Software page, enter your organization’s standard information,
then click Next.
13. Enter the computer name and a strong administrator password. Should you attempt to
leave the password blank, Windows Server 2003 Web Server will warn you that this
practice is not recommended. If you attempt to use a simple password such as
“password,” a warning box will instruct you in how to create a strong password. Click
14. A choice of typical or custom is given for network installation. Select custom so that you
have the opportunity to remove additional elements.
15. Clear the Client for Microsoft Networking check box if you have no need to access
resources on a Microsoft network using Microsoft Server Message Block (SMB). Once
again, you are minimizing your environment. Although there are no known
vulnerabilities introduced by this code, should the Web server be compromised, this
option could be used to connect to other resources in your network, giving the attacker a
way to attack other systems.
16. Clear the File and Printer Sharing for Microsoft networks check box if you will not need
to share folders or printers from the Web server. Many attacks on Microsoft servers
utilize this service, and it is not needed for users to access Web content.
17. Ensure that the Internet Protocol check box is selected, then click Next.
18. Enter the IP address and relevant DNS and gateway information. Leave the default
selection for workgroup, and click Next.
19. The system will finish the installation and reboot.
20. Press Ctrl+Alt+Delete, enter the administrator password, and click OK.
Immediately, the system automatically installs remote administration tools, then provides a
server administration Web page, which Figure 2.2 shows, at
http://localhost:8099/tasks.asp?tab1=TabsWelcome. The page provides links to a server tour, and
tasks for setting the server name, administrator password, and default page. Tabs provide links
that can be used to perform Web server administration and computer administration.
If you decide to install from an existing system, the dynamic update phase provides an opportunity to
download the latest changes from Microsoft. When prompted, select No. Dynamic update during
installation is not a good idea as it will unnecessarily expose the system to attack before it has any
defenses in place. If, at some date, recent changes can be downloaded and placed on your internal
update server, you can put this functionality to good use. Until then, a better option is to provide a
batch file that can be run after installation or as a part of an automated installation. The batch file can
include hotfixes.
Chapter 2
Figure 2.2: IIS 6.0 Server Administration page.
Post-Installation Lockdown Steps
To harden the default installation, you need to revisit four areas: remote administration, IIS, the
Security Lockdown Wizard, and general configuration. The Windows Server 2003 Web Server
installs the HTML-based Web Admin tool by default; you have the option to also install the new
Remote Desktop Web tool. First, determine the risk of attack via remote administration tools for
your environment. For an intranet Web server that isn’t exposed to the Internet, the risk may be
small. If your Web server will be an e-commerce site, the risk may be great.
If you do not allow remote administration, then you have eliminated one type of attack. If you
have multiple Web servers, requiring console access for administration may be impractical. An
alternative is to provide each Web server with two network cards. You will then need to
configure one card to link the Web server to the network on which your firewall, and thus the
Internet, can be found. Configure the other card to connect to an internal administration network.
For a discussion about Remote Desktop Administration, see Question 7.3.
However, if you have determined that the risk of remote administration outweighs the benefit,
remove the remote administration tools. To do so, open the Start menu, select Control Panel,
Add or Remove Programs. Select Remote Administration Tools, then click Remove.
Windows Server 2003 Web Server installs a minimum number of services. If you require
additional services, you will have to add them. Likewise, if the installation has installed services
that you do not need, you will need to remove them. To do either, open the Start menu, select
Control Panel, Add or Remove Programs, Add/Remove Windows Components, then add or
remove the items that Table 2.2 defines.
Chapter 2
by Default
BITS Server
Background transfer of files using idle bandwidth
FTP Service
Provides FTP services
Server 2000
Enables remote publishing of unique FrontPage extensions to the Web
IIS Snap-In
Administrative console for the Microsoft Management Console (MMC)
interface; unless you intend to do all your administration remotely,
leave this console installed
NNTP Service
Provides newsgroup services
SMTP Service
Provides mail services for the Web server; doesn’t provide mailbox
services for clients; installed to support email alert feature; although
disabled by default, this feature will email alerts to the email address
configured; if this Web server will not use the services, uninstall
World Wide Web
If you remove this service, you will not have a Web site; you might
remove this service if you have added FTP and only want to be an FTP
Table 2.2: Services you can add or remove from the default Windows Server 2003 Web Server installation..
The Security Lockdown Wizard will automatically run the first time you open the IIS console
and click the Web site. The implementation goal of Windows Server 2003 Web Server is to
provide a secure Web server from the start; the lockdown wizard is primarily a way to add
request handlers or to remove them if they have been added and are no longer necessary, with
one exception—Active Server Pages (ASP) is installed and enabled by default, so you will need
to use the lockdown wizard if you want to disable it.
During the installation of IIS 6.0 on a Windows Server 2003, you have more choices, one of
which is to not install ASP. During the installation of the Windows Server 2003 Web Server, this
option is not offered. There is no way to prevent the installation of ASP from occurring, and the
initial Web pages that load and are designed to help you implement the Web server are ASP.
There is no doubt that ASP assists in the building of robust, feature-rich Web sites. The problem
with ASP is that it can provide an avenue for a malicious attacker to more quickly and easily
attack both the Web server and client computers that download ASP. Securing clients from ASPbased attacks requires considerable effort. Although IIS 6.0 and its ASP component will ship
with no known vulnerabilities, it is always wise to disable or simply not install this feature.
The initial configuration for Windows Server 2003 Web Server includes items that have been on
security lockdown checklists in the past:
Only read Web permissions are available on the home directory root. No script source
access, directory browsing, or write permissions are selected (see Figure 2.3).
Execute permissions are set to scripts only.
No Internet Server API (ISAPI) filters are installed.
Chapter 2
Figure 2.3: The IIS 6.0 home directory property page reveals minimal permission settings.
Allowing anonymous users to write to the root directory would be a recipe for disaster.
Malicious scripts and executables could be uploaded to the Web server and then executed. If
directory browsing was allowed, an attacker or curious visitor might discover interestingsounding files and folders or otherwise think they have found something that warrants a more
extended attack.
A check of the file system reveals other areas in which security can be tightened. Inetpub is the
default installation directory and two folders, AdminScripts and Issamples, hold scripts. In the
past, the Issamples folder has been the source of scripts that could be used to attack IIS. Delete
these folders. (If you want to study these scripts or use them in your site, at least move them
elsewhere so that they are not available to an attacker).
Chapter 2
Q 2.4: The use of Internet-downloadable components has been a
major security issue. As we move to Windows Server 2003, how can
we prevent malicious code from running on our systems?
A: Although there is no guarantee that you can prevent malicious code, as part of its security
framework, Windows Server 2003 includes two security mechanisms that you can manage
administratively. These mechanisms are the use of a role-based security model and the ability to
enforce code access rights. Role-based security lets the programmer assign permissions to code
objects according to defined roles. In many cases, each role will correspond to a Windows user
group. Administrators can manage who has access to what code by adding user accounts to
specific groups that correspond to the role that the users play. You should be aware that a
program might ignore Windows groups and create its own internal roles. These roles are then
programmatically assigned to users or groups. In this instance, the administrator does not control
the membership in the role. Enforcing code access rights allows an administrator grant
permissions to code assemblies at runtime. Assemblies, which are units of code, are the building
blocks of the Windows Server 2003 framework. Thus, role-based security restricts who can run
what code, and code access rights restrict what code can do on a system no matter who runs the
Code access security is a flexible process that can be customized for each computer and each
user of a computer. It allows the administrator to set the Security Policy for managed code
operating on a computer. Security Policy is the set of rules used by the Common Language
Runtime (CLR) to determine which type of access is allowed to code. The CLR is the engine that
executes the managed code.
The first thing you must realize about the process of enforcing code access rights is that this
mechanism only applies to assemblies that consist of well-managed code. If code is not
managed, the safeguards that you have designed won’t apply. Of course, you do have the option
of preventing unmanaged code from running at all.
The second thing is that code access permissions do not supersede the control mechanisms
provided by the operating system (OS). For example, permissions assigned to files and folders in
NTFS-formatted file systems will prevent code from accessing files, even if the code has been
granted full access to the file system. If access to the file system is denied to the code assembly
but permitted by NTFS permissions, access is still denied. To determine whether access will be
granted, you need to determine the order in which permissions are determined. If the assembly is
allowed to run, its code access permissions are determined. At this time, the system does not
know which files the assembly will attempt to access, it just knows that the system gives the
assembly the right to read and write files. When the assembly actually attempts to open a file for
reading or writing, the normal file permissions are applied. Alternatively, an assembly that has
been denied file access will not be able to access files; file permissions are never explored.
Chapter 2
The third consideration with this model is that it requires the cooperation of both programmer
and administrator to make it work. If the administrator does not set the proper access
permissions, code will run under the default settings that allow all code all permissions that it
requests. If the programmer does not write the code to ask for only the permissions necessary for
execution, and the organization demands that the code be run, the administrator will have to
relax the security permissions to let the code run. The first step for both programmer and
administrator is to gain an understanding of code groups, code access permissions or named
permission sets, code security policy, and process.
Code Groups
Code groups are simply a means of organizing code based on some condition. Within the
Security Policy, this organization results in a hierarchical structure that has the code group All
Code at the top of each Security Policy level. By grouping code, named set of permissions can be
more easily applied to a body of code rather than specifying code’s application on each
individual assembly. At runtime, the CLR examines the identifying characteristics of the code to
determine membership in the code group. Administrators configure enterprise, machine, and user
policy levels with a hierarchy of code groups, the root of which is a code group that contains all
Figure 2.4 shows a snapshot of the .NET Framework Configuration Tool. You can see that the
All Code group has representation at the enterprise, machine, and user levels.
Figure 2.4: By default, each level includes the All Code group.
Chapter 2
Code group membership may be determined by examining the evidence. Evidence is just
information that the CLR uses to determine membership in a code group and the appropriate
Security Policy. Evidence information can be embedded in the assembly (such as a digital
signature) and can be examined directly by the CLR or presented to the CLR by a trusted
application domain host (such as a URL). An application domain host is the computer that
creates the application domain and loads the assembly into it. (A trusted host is one that has been
given permission to share this information with the CLR—other types of application domain
hosts are defined in Table 2.3. The application domain host knows from where the code
originated, has the digital signature of the assembly, and can specify a Security Policy for the
code that runs within it. This policy cannot expand the permission set assigned by enterprise,
machine, and user policy, but it can reduce it. The following information is presented as
All code (AllMembershipCondition)—All code will always match this condition
Application directory (ApplicationDirectoryMembershipCondition)—Tells where the
application is installed
Cryptographic hash (HashMembershipCondition)—MD5, SHA1, or other cryptographic
hash is presented
Software publisher (PublisherMembershipConditions)—Public key of a valid
Authenticode signature
Site membership (SiteMembershipCondition)—HTTP, HTTPS, and FTP site from which
the code originated
Strong name (StrongNameMembershipCondition )—Cryptographically strong signature
URL (UrlMembershipCondition )—Contains the URL from where the code originated
Zone (ZoneMembershipCondition)—The Internet Explorer (IE) zone from which the
code originated
Domain Host
Browser host
Code is run within the context of a Web site
Custom designed
Creates domain and/or load assemblies into a domain; might also
load dynamic assemblies; might be managed or unmanaged code
Server host
Handles requests submitted to a server
Shell host
Runs applications such as executables in the shell
Table 2.3: Application hosts.
Chapter 2
Named Permission Sets
A named permission set is a predefined set of permissions that an administrator can assign to a
code group. Built-in named permission sets cannot be modified, but custom permission sets can
be created. Built-in named permission sets are:
Nothing—Code cannot run
Execution—Code can run but has no access to protected resources
Internet—A default policy for content of unknown origin
LocalIntranet—A default policy for the enterprise
Everything—All permission except skip verification
FullTrust—Full access to all resources
These sets of code access permissions are defined to deal with the most common requests for
access to resources; however, you can create custom permissions. Code-access permissions work
because the assembly includes code that requests the appropriate permissions for the access it
needs. So, for example, each new request to read a different file is accompanied by a request for
permission to read the file, and each new request to append data to a different file is
accompanied by a request for read and write permissions.
These FileIOPermissions have caused problems in the past. The programmer uses built-in classes
that let the system know which sensitive operations it will want to perform. The assembly, in
essence, enumerates for the system which files it may access and for what purpose, which
registry keys it may read or modify, whether it needs to add or modify environmental variables,
and so on. The administrator sets the Security Policy that details which code has which
permissions. If there is a match between requests and approved access, the code works as
expected. If not, an error occurs. The code should have explicit actions defined for what to do if
these errors occur. Such actions might be as simple as a graceful exit or might be in the form of
messages or event log entries that detail the reason that the code didn’t work.
Creating Custom Permission Sets
When a new code group is configured, you can select a default set of code access permissions or
a pre-selected permission set or you can design a new set. A new code group is created by rightclicking the code group’s parent-to-be, and selecting Create New Code Group. A permission set
is selected in the Assign a Permission Set to the Code Group dialog box, which Figure 2.5
Chapter 2
Figure 2.5: A pre-defined permission set (either default or custom designed) can be selected for a new code
group or you can create a new permission set.
To create a new permission set, you must name the new set and select the set’s permissions from
the Assign Individual Permissions to Permission Set dialog box, which Figure 2.6 shows.
Figure 2.6: Permission sets are created by selecting individual permissions.
Chapter 2
Table 2.4 defines the available permissions.
Directory Services
Browse or write
None or ALL
Event Log
Unrestricted to all or none, browse, instrument, or audit per specific log
Unrestricted to all, or read or write on individual variables
File IO
Read, write, append, path disc. on stated paths
File Dialog
Unrestricted or open, save or open, and save
Isolated Storage
Unrestricted access to the file system storage or set a quota for use; also set
administration by user or roaming user, isolation by user, roaming user or domain
Message Queue
Unrestricted to all message queues or restricted to those identified by path or other
element such as machine name, category, and label; access granted is either none,
browse, peek, send, receive or administer
Unrestricted or to listed OLE DB providers; the option to allow blank passwords is
available with a check box, but applies to all
Unrestricted or limited to machine and category; access is either none, browse, or
Unrestricted or no, safe (from a restricted print dialog box), default (only one job
from other than default printer), or all printers
Unrestricted or per registry key; access is read, write, or create
Unrestricted or find info about members, find info about types (classes), or script
engines and compilers are allowed to generate assemblies
Unrestricted or by selecting allowed security permissions; permissions possible are
displayed in Figure 2.7
Service Controller
Unrestricted or by identification and assignment of access—either none, browse, or
Socket Access
Unrestricted or allowed by identification of host, port, direction, and selection of TCP
or UDP
SQL Client
Unrestricted access to SQL Server or limited access to SQL server using;
you must select the check box if you want to allow blank passwords
Web Access
Unrestricted or by listing host and accept or connect
User Interface
Unrestricted or specify access to windows and clipboard; access to windows is
either all windows and events, only to top level safe windows, only to safe sub
windows or no windows; clipboard access is to all, own, or none
Table 2.4: Available permissions.
Chapter 2
Figure 2.7: Security permissions for assemblies.
Although a program asks for security permissions and administrators define them, an application
can use the following security actions to determine what to do with the defined security
permissions, including completely ignore them:
LinkDemand—This action takes place at just-in-time (JIT) compile time and checks the
immediate caller of the class or method to determine whether the caller has the
appropriate privileges.
InheritanceDemand—Evaluated at load time; checks the subclasses.
Demand—Evaluated at load time; checks all callers.
Assert—Evaluated at run time; seeks to excuse the particular class or method from
adherence to the Security Policy. This condition is useful if it helps a trusted application’s
performance. However, it opens a security hole. What if an untrusted application calls
this method? Administratively, all asserts can be denied in the Security Policy causing
this class or method not to run.
Deny—Evaluated at run time; seeks to explicitly prevent the use of permissions that the
assembly already has. This condition is useful if the assembly calls code that the
assembly doesn’t want to use its permission set. For example, if the assembly calls a
script that has unrestricted access. The CLR will check the caller (your assembly) for
permissions requested by the script. If your assembly has denied some of it s own
permission set, the script will not be given access.
PermitOnly—Evaluated at run time.
Chapter 2
RequestMinimum—Evaluated at grant time; the assembly might specify in its
permissions list what it wants, what would be nice if available, and what permissions to
refuse if they are granted but exceeds what the assembly needs. The three request security
actions (RequestMinimum, RequestOptional, and RequestRefuse) define which the
assembly requests. RequestMinimum says “I have to have these or I can’t run at all.”
RequestOptional—Evaluated at grant time; the assembly might use these permissions if
they are granted, but if the permissions aren’t granted, the assembly will still run.
RequestRefuse—Evaluated at grant time; the assembly identifies permissions that it does
not require and will not use even if granted.
Policy Assemblies
Policy assemblies are assemblies used during policy evaluation. By default, system assemblies
used in the evaluation of default permissions are automatically included, as Figure 2.8 shows. If
you create a custom permission, be sure to add the assembly to the policy assemblies.
Figure 2.8: The policy assemblies in the machine node of Security Policy for the framework.
Security Policy
When an assembly is run, the Security Policy asks the questions “Where did the code come
from?” and “Who wrote the code?” The answers to these questions determines how the code
maps to various permission structures (in which level and code access group does it belong?).
You can think of the Security Policy as a collection of statements that might sound like these:
Chapter 2
Code from can access files in folder D:\folderforstuff\
Code running on my local machine can use the Clipboard
Code from cannot read or write to disk or the
registry, use the clipboard, or read or modify environmental variables
As administrator, you write the Security Policy using one of two tools: caspol.exe, the code
access security policy tool (caspol is a command-line tool); and the Microsoft .NET Framework
Configuration Tool, a GUI tool. Both tools let you view policy, code groups, and permissions
sets as well as create, modify, and delete them. You also can assign permissions to code groups
and analyze security settings on assemblies. In addition, these tools let you directly edit the
The Microsoft .NET Framework Configuration Tool
The Microsoft .NET Framework Configuration Tool is a multipurpose tool that lets you manage
code access security. To load the tool either access its console from Start, Programs,
Administrative Tools; from Start, Run, and enter mscorcfg.msc; or from the command-line
<systemdrive>\<system folder>\Microsoft.NET\Framework\<version
Next, expand the RunTime Security Policy node. There are three subnodes—enterprise,
machine, and user—which represent Security Policy levels. Each subnode has configurable code
groups, permission sets, and policy assemblies. You can use a handy wizard to assign permission
sets to code groups. In the following example, we will create a new code group and assign a
permission set:
1. Right-click the All code container under the machine node, and select New.
2. On the Identify new Code Group page of the wizard, enter a code group name and
description. (You can also import a code group from an XML file.) Click Next.
3. On the Choose a Condition Type page, use the drop-down box to choose which condition
will make an assembly a member of this code group. The conditions available match the
evidence categories I previously discussed. You can also choose the custom category.
4. Depending on the category chosen, the appropriate text boxes and/or check boxes are
displayed for your entry. So, for example, strong name allows the entry of a public key,
while URL allows the entry of a URL (see Figure 2.9). Click Next.
5. On the Assign a Permission Set to the Code Group page, you can use the drop-down list
to select a permission set or choose Create a permission set. For this example, we’ll select
the option to create a permission set. Click Next.
6. On the Identify the New Permission Set page, enter a name and description or choose to
add a permission set by importing an XML file. Click Next.
7. On the Assign Individual Permission to Permission Set page, select permissions from the
left window, then click Add to add them to the window on the right. When you are done,
click Next. Click Finish to end the wizard and create the code group.
Chapter 2
Figure 2.9 Strong Name as the evidence of membership in the code group allows entry of a public key.
Alternatively, you can create a custom permission set, then assign that set to a particular code
group. To create a permission set:
1. Right-click the permission set node, and select New.
2. On the Identify Permission Set page, add a name and description or import a permission
set from a prepared XML file. Click Next.
3. On the Assign Individual Permissions to Permission Set page, select permissions from the
left window and click Add to move the permissions to the right pane. Each permission
will ask for qualifying information. When you are done, click Finish.
The following section explains how the code access security process works. At run time, the list
of demanded permissions for the assembly is read and evaluated against the Security Policy. The
first step involves gathering evidence, that is, determining the author (who signed it) of the code,
the source (URL, site, zone) of the code, and any special identity such as the strong name
assigned to the code. The evidence is gathered by the CLR and trusted application hosts. Trusted
application hosts are IE, ASP.NET, and the shell. Evidence is divided into classes:
Chapter 2
Site—Web site
URL—A specific location on some site
ApplicationDirectory—The folder(s) in the file system that hold the program code for the
Zone—IE zones such as intranet, trusted sites, and so on
StrongName—Cryptographic name
Publisher—Who signed the code
The evidence is given to the Security Policy. Membership in a code group is determined. A code
group may be the set of all code from a particular Web site or from particular authors. Next, the
assemblies’ requests are judged against those granted in the Security Policy according to the
code group and the three hierarchical Security Policy levels: enterprise, machine, and user. See
Table 2.5 for more information about these policy levels. A hierarchy of code groups is present
at each level. The resulting permissions are the intersection of grants set at all levels. The
enterprise level grants the total permissions that an assembly can have. The machine and user
level grants cannot expand these permissions; they can only make the Security Policy more
restrictive. The final resultant set of permissions is the set assigned to the assembly on this
computer being used by this user in this application domain.
Policy Level (in hierarchical
Can be Modified by
An enterprise policy configuration
file is distributed so that
managed code in an enterprise
setting is effected
All managed code that runs on
this computer
Administrator or user
All code is associated with the
current user on this OS
Application domain policy
Application domain host code
This policy represents the
resultant set of the three previous
policy levels.
Table 2.5: Policy level descriptions.
An administrator can set a machine-level policy that doesn’t allow the other policy levels to be
evaluated. However, other factors might also limit what the assembly can do. During runtime,
each caller of the code will also be checked against the Security Policy; if any of the callers don’t
have the appropriate permissions, the particular access will not occur. However, assert can be
used to allow simple, limited code to always run. No matter the simplicity or the limitations
placed on code, there may be a way to misuse it. Although the programmer can assert that the
code should always be allowed to use the permissions granted to it, the administrator can deny
assert, and thus prevent abuse. It will be up to each organization to establish the Security Policy
that works best for them, and programmers and administrators will need to implement it. If no
attempt has been made to edit Security Policy, the default Security Policy is applied to the all
code group. More restrictive polices are defined for code groups at the machine and user level.
Chapter 2
Q 2.5: We do not allow users to store data on their hard drives. They
are provided a place on a file server. I can protect this area with
discretionary access control lists, but how do I protect data during
transport from client to file server?
A: There are several ways to secure data in flight, including using virtual private networks
(VPNs), IPSec, and the Secure Sockets Layer (SSL). VPNs are usually the methodology of
choice when transferring data across the WAN, while transport-mode IPSec, explained in
Question 8.5, is preferred for transferring files on the LAN. However, another methodology
exists for protecting files in transport on the intranet, WebDAV over SSL.
WebDAV is the Microsoft implementation of the Distributed Authoring and Versioning
extension to HTTP/1.1. You can read about DAV in Request for Comments (RFC) 1518. It was
originally designed as an alternative to using FTP to publish files to a Web server, but can also
be used as an alternative to SMB. If the Web client is installed, Internet Explorer (IE), Microsoft
Office applications, and the Windows Desktop can be used to read and write files to a WebDAVenabled folder. Office applications can also directly open files from and save files to the Web
folder, much as they would use a regular local folder or shared folder on a file server. To use
WebDAV securely requires securing the IIS Server, the Web folders and the Web site that hosts
them. Our focus here is securing data in flight, but we’ll start with a secure implementation of
To use WebDAV in Windows Server 2003, you must WebDAV enable the IIS 6.0 Web server
and create Web folders on it. (Web folders and WebDAV can also be used with IIS 5.0 and
Windows 2000—Win2K.) Then, using the Web client, files can be transferred from the client
computer to the Web folder using HTTP. No file share is necessary on the Web server.
WebDAV itself does not provide any mechanism for protecting data in transport. However, you
can protect data during transfer to the Web folders by establishing and using SSL—after
authenticating the connection with the Web server, all data is encrypted during transport. Files
saved in the WebDAV folders are not encrypted.
Preparing and Securing Web Folders for WebDAV
First, you must enable WebDAV, create and secure the Web folder. To do so, create a folder on
the Web server, and apply NTFS file permissions to limit its access to the Windows groups that
should use it. This first folder will be the location for the Web site. Next, open the Internet
Information Services Console, right-click the Default Web Site (or Web site you have created),
and select New, then Virtual Directory. Click Next on the New Virtual Directory Creation
Wizard Welcome page. Give the virtual directory an alias to be used for accessing it (for this
example, I’ll name it Stuff), then click Next. Enter the path to the new folder or use the Browse
button to browse to its location, then click Next. Set folder permissions.
Because this folder will be the root for the WebDAV folders, you might want to set it with run
scripts and read permission. I added write permission so that approved users can save files to the
folder, and browse (Directory Browsing) so that users can see the files that are stored there. The
appropriate permissions to set will depend on your implementation. You might not want, for
example, users to see the files available or you might even want users to only be able to write
files but not read them. Keep in mind these are virtual directory folder permissions. The
underlying NTFS permissions further control who can do what with the files.
Chapter 2
Click Next, then click Finish to complete the creation of the virtual directory. Set authentication.
On a static Web server, anonymous connections are allowed; however, they are not a good idea
when enabling folders for WebDAV. No one should be allowed to access a Web folder for
reading or writing without proper identification. A good choice for Web-based authentication on
the intranet is Windows integrated (see Figure 2.10). The dialog box that Figure 2.10 shows can
be located on the property pages of the Web site. It is reached by clicking Edit at the top of the
Directory Security page. Basic authentication means passwords are passed in the clear, which
might be OK if you will also use SSL.
Figure 2.10: Set authentication methods.
Next, enable WebDAV by right-clicking in the IIS console on the local computer, and selecting
Security. Doing so runs the IIS Security Lockdown Wizard. Click Next twice to advance to the
Enable Request Handler’s page. Scroll down and select the Enable WebDAV Publishing check
box, as Figure 2.11 shows, click Next, then click Finish to complete the wizard.
Chapter 2
Figure 2.11: WebDAV is disabled by default. To enable it, run the Security Lockdown Wizard.
The WebDAV ISAPI request handler is not enabled by default to prevent its malicious use. Before
you enable WebDAV, you should thoroughly consider the additional risk it entails. Remember,
WebDAV enables access to documents using Microsoft Office, many versions of IE, and other
products that meet the HTTP/1.1 WebDAV specification. It does so over port 80. Therefore, unlike file
sharing, which can be blocked at the firewall, WebDAV manipulation of this data can be
accomplished across a port commonly open on the firewall. If your intention is to allow such access,
you must ensure that other controls are in place. If you will merely be using WebDAV on your
intranet, you must still take the appropriate action to block external access to port 80 of the WebDAVenabled IIS server on your internal network. Security controls for WebDAV are summarized later.
Before setting up SSL, it’s wise to test the Web folder for accessibility. To do so, make sure that
your Windows XP client has the Web Client service enabled and started (you can check and also
enable it if it is disabled by going to the Start menu, selecting Administrative Tools, then
selecting Services). You will also need the appropriate URL. For this example, I used the IP
address of the Web site, followed by the alias assigned to the virtual directory. Then, to test, try
one of these options:
Any Office product should be able to save or open files saved to the Web folder as if the
folder existed on the local hard drive. Instead of using a local drive path or mapping a
network drive, simply save to My Network Places, and select the correct Web folder or
type the URL.
Open My Computer, and select My Network Places, double-click Add a new Network
Place, and enter the URL. A file can be dragged from the desktop or Explorer window to
the Web folder.
Chapter 2
Open IE, from the File menu select open, input the URL, and select the Open as a Web
folder check box. A file can be dragged from the desktop or Explorer window to the Web
folder (see Figure 2.12).
Figure 2.12: Use the IE File menu’s Open dialog box to open a Web folder.
If your logon does not match the NTFS permissions set on the underlying folders, you will be
prompted for a user ID and password, as Figure 2.13 shows.
Figure 2.13: The site doesn’t allow anonymous connection, so you might need to enter a user ID and
Using SSL to Transfer Files to Web Folders
Setting up SSL for use with Web folders is simple and straightforward. The basic process is the
same as for setting up SSL for other purposes. You must decide where the certificate should
come from and where it should be installed? Because our example is an intranet Web site, the
steps which follow obtain the certificate from an internal Windows Server 2003 Certificate
Authority (CA). If you choose, you might obtain a certificate from one of the commercial CAs.
Chapter 2
IIS offers several locations where the certificate might be installed. It can be installed at the Web
site level, and all connections to the Web folders can be required to use SSL. It can be installed
on a Web folder. In this manner, connections elsewhere on the site do not have to use SSL. It can
also be installed at a subfolder level. Our example consists of a Web site set up specifically for
WebDAV, so the certificate will be installed at the Web site level.
To require SSL for Web folder access, you must request a certificate, install it, and require SSL.
To request a certificate, in the Internet Information Services console, right-click the Web site,
and select Properties, then select the Directory Security tab. Click Server Certificate in the
Secure Communications area of the page, click Next on the wizard welcome page, select Create
a new Certificate, and click Next. Select Send the Request immediately to an on-line certification
authority, and click Next. (If you must obtain your certificate from a third-party CA, you will
need to create a request for forwarding to the authority, then install the certificate when you
receive it.)
Next, you’ll need to enter a name for the new certificate. Change the bit length if you desire
stronger security. In general, the longer the bit length of the key, the better the security but the
worse the performance. Click Next. Enter the legal name of the organization in the Organization
text box, enter the departmental name in the organizational unit (OU) text box, and click Next.
The NetBIOS name of the site (the server name) will appear in the Common Name text box. You
might replace it with the fully qualified domain name (FQDN) or, because this is strictly planned
for intranet access, leave the NetBIOS name. In this example, the FQDN was entered. Click
In the next step, enter the city and state location of the Web server, and click Next. Select a CA,
then click Next. All online CAs should be available in the drop-down box. Review the settings
on the Certificate Request Submission, and click Next. Click Finish on the notice that the
certificate has been installed, select the Web Site tab, enter the port number for SSL (the standard
port number is 443), and click Apply.
Return to Directory Security page, and click Edit in the Anonymous Access and Authentication
Control section. Change authentication method to Basic Authentication if desired. The SSL
connection will occur before authentication and thus the entered user ID and password will be
Click View Certificate to review the certificate details and verify that a Web Server certificate
has been installed. The designation of the type of certificate is found by examining the
Certificate Template Name on the Details page. The specified use of the certificate—Server
Authentication—can be found on the General page. Click OK to close the view, then click OK to
close the properties page.
After the certificate is installed, HTTPS can be used to access the server and ensure encryption
of the entire communication between the client and the server. However, ordinary HTTP can also
be used. To ensure that all communication is encrypted, you must configure the Web server to
only accept SSL. To do so, return to the Directory Security properties page for the Web site,
click Edit on the Secure Communications section of the page, and on the Secure
Communications dialog box, select Require Secure Channel. If all clients are capable of 128-bit
encryption, select this option as well (see Figure 2.14). Click OK to close the window and apply
the setting. Now all clients will be required to use HTTPS to connect.
Chapter 2
Figure 2.14: Require SSL, as clients will not remember to request it.
Click OK to close the Properties pages. To test, return to the client and enter the URL to access
the Web folder. If you use HTTP, it will not work and provide an error message. Modify the
URL to use HTTPS and access is allowed. Note that the failure came before the request to enter
a user ID and password, thus showing that the SSL connection will occur before logon. Even use
of the basic authentication clear-text password will actually be encrypted when using SSL.
Be sure to retest connections using HTTPS. If you forget, you will be warned, as Figure 2.15
Chapter 2
Figure 2.15: If properly configured, any attempt to access the Web folders without using HTTPS will fail.
Fortunately, entering HTTPS and repeating the operation will get you to the Web folder, as
Figure 2.16 shows.
Chapter 2
Figure 2.16: After authentication, the Web folder is ready for use in reading and saving files.
When securing your Web folders with SSL, it is wise to understand that a certificate used by this
purpose must be from a trusted CA or you will receive warnings when first attempting access. On an
intranet using an internal CA, it is likely that trust of the CA, and thus the certificate issued for the
Web server, will already be established. However, if a Windows Server 2003 standalone CA is used,
or if clients not joined in the domain of an Enterprise CA are used, you might need to acquire a copy
of the CA certificate and place it in the Certificate store of the client system. You can do so during the
first access to the Web server, if users are properly instructed.
Q 2.6: How are configuration changes made to IIS, and how can I
protect the IIS configuration?
A: The IIS metabase is the hierarchical store of configuration information and schema for the
IIS Web server. Although the IIS console exposes some administrative settings, other items can
only be managed by modifying the metabase. If the metabase is missing or corrupt, there can be
no Web server. In Windows NT and Windows 2000, the metabase was stored in a proprietary
format binary file. This file was difficult to modify and understand. It was not directly readable
or editable. It was subject to corruption and was not automatically backed up. Windows Server
2003 replaces the binary file with two XML files. When the Web service is running, the
metabase consists of these two files and the in-memory metabase. This setup makes it easier to
understand and modify and a revision history is automatically kept. In addition, troubleshooting
the metabase and discovering corruption is easier because the plain text file can be easily
examined and compared with backup copies written to the history folder.
Because the metabase is now an XML file, it can be manually modified using text editors such as
Notepad as well as with scripts or programs. You should remember that its text is case sensitive.
Chapter 2
Ensuring Survival of the Metabase
Unlike IIS 5.0, IIS 6.0 attempts to ensure survival of the metabase, and thus IIS, by creating
automatic backups of MetaBase.xml (configuration) and MBSchema.xml (identifies the
properties that can be written to keys in the metabase). During operation, a copy of the metabase
is in memory. If the edit-while-running feature is enabled, the MetaBase.xml file can be edited
while IIS is running. After a predetermined number of changes within 5 minutes, a copy is saved
to disk. The file can also be manually edited and saved to disk if the IIS service is stopped, the
file is modified and saved programmatically using Active Directory Service Interfaces (ADSI).
A save event is also triggered, regardless of changes made, at 4-hour intervals. If changes have
been made, IIS uses temporary files to ensure the availability of the metabase files. The
procedure is as follows: IIS locks the in-memory metabase, then increments by one the value of
the HistoryMajorVersionNumber property in the in-memory metabase. This number is checked
against existing files in the history folder. If the number is already in use, the value of
HistoryMajorVersionNumber is increased by one. This process continues until IIS arrives at a
unique number. A temporary metabase file copy named metabase.bak is created and given the
HistoryMajorVersionNumber. IIS then unlocks the MetaBase.xml file. (New writes to the file
are now possible.) If the file is write-locked or read-only, an error message is posted to the event
logs and processing proceeds. The metabase.bak file is written to the history folder and renamed
Metabase_HistoryMajorVersionNumber_minor version number.xml. If the MetaBase.xml file is
newer than the metabase.bak file, an error is posted to the event logs and the process is stopped.
If the MetaBase.xml file is not newer than the metabase.bak file, the MetaBase.xml file is
overwritten by the .bak file, and the .bak file is deleted. Checks are made to ensure that the
metabase is ready for future modification and that the copy being made is current. (The metabase
file can be write-locked by an application and no changes can then be made to it. The metabase
file is not normally read-only.)
The MetaBase.xml file can become newer than the metabase.bak file if the administrator makes a
change to the MetaBase.xml file about the same time that the in-memory file is written to disk.
You can manually modify the MetaBase.xml file, but not the MBSchema.xml file. However, you
can make changes to the MBSchema.xml file programmatically. Because the MetaBase.xml file
and the MBSchema.xml file are a pair, a current copy of the MBSchema.xml file must be saved
to the history folder with the same major and minor version numbers as its MetaBase.xml file.
Before this is done, the MBSchema.xml file is checked for pending changes. If no changes are
pending, a copy of the MBSchema.xml file is made and copied to the history folder and
renamed. If changes are pending, the MBSchema.xml file is renamed to a temporary schema file.
The in-memory schema (the one with the changes made in it) is written to MBSchema.xml. The
temporary schema file is renamed with the version numbers and saved to the history file.
Chapter 2
Stopping and Starting IIS
When IIS is started, the stored copy of the metabase is written to memory. If the file cannot be
parsed (missing XML tags, misspelled property name, corruption, or other errors), a copy is
written to the history file, an error is placed in the event logs, and IIS will not start.
When IIS is stopped, the configuration and schema files are checked for changes that might have
been made since a copy was last written to disk. If changes have been made, a new copy is
written to disk and a new history file is created. Otherwise, only a history file is created; no new
copy is written to disk. (This configuration reduces the time taken to stop IIS.)
In addition to the automatic creation of history files, regular backups should be made. When the
configuration backup/restore feature is used, backups of the metabase can be restored to the same
IIS server or to another installation of IIS on a Windows Server 2003.
This backup does not back up your IIS server content or your SSL certificate, if one is used. You
should also back up your content files and, of course, a copy of the SSL certificate should always be
Two types of backup are possible:
Secure backup—An administrator-provided password is used by IIS to encrypt the secure
properties and a copy of the password. The rest of the data is in plain text.
Nonsecure backup—Data is encrypted with a blank password and therefore can be
restored by any member of the Administrators group.
To back up, in the Start menu’s Run text box, type
and press Enter to open the IIS Manager. In IIS Manager, click the computer listed under Internet
Information Services. From the Action menu, select All Tasks, click Backup/Restore
Configuration, then click Create Backup. In the Configuration backup name text box, enter a
name for the backup file. To make the backup secure, select the Encrypt backup using password
check box, and enter a password in the Password box and Confirm Password box (see Figure
2.17). Click OK. A set of two files, namex.mdx and namex.scr, will be created (where name is
the name you entered and x is the version number). If the file name does not exist in the backup
location, x will equal 0; otherwise, it is incremented each time the same file name is used.
Chapter 2
Figure 2.17: Naming and protecting the backup file.
To restore a backup, in the Start menu’s Run text box, type
and press Enter to open the IIS Manager. In IIS Manager, click the computer listed under Internet
Information Services. From the Action menu, select All Tasks, click Backup/Restore
Configuration, and under Previous Backups, click a file name in the list, then click Restore. If
prompted for a password, enter the password. If you use an SSL certificate on your Web server
and you restore to a different Windows Server 2003 server, you will need to install the same SSL
certificate to the IIS server in order for IIS to start.
Modifying the Metabase
Modifications are made to the metabase via IIS Manager, ADSI, Windows Management
Instrumentation (WMI), COMM DLLs, or executable programs. This process uses the Admin
Base Objects layer. As I previously mentioned, while IIS is running you can make changes to the
MetaBase.xml in-memory file. This method is a very efficient way to make changes, especially
when doing so remotely.
To do so, you must first enable the edit-while-running feature. To safely edit the file, you should
understand both XML and the metabase schema. Incorrect edits and improperly formatted edits
can result in catastrophic damage to the metabase and prevent IIS from running. The basics of
XML and the metabase schema are provided in the Help files:
Metabase Configuration Files—which defines XML terminology and metabase
Metabase Property Reference—which details the metabase properties and attributes.
The following instructions detail how to make a simple change, such as editing a common
property. To change the property value for the number of maximum history files that are kept,
make sure that the edit-while-running feature has been enabled. Open the MetaBase.xml file in
Notepad. Navigate to the section of the file at which the MaxHistoryFiles value is located, as
Figure 2.18 shows. (You might need to use the find feature in Notepad). Change the value listed
to the number you want. (The default setting is 10.) Close and save the MetaBase.xml file.
Chapter 2
Figure 2.18: Manually editing the MetaBase.xml file.
When the file is saved, IIS uses the file change notification feature of the file system to trigger
changes to the in-memory version. The following process is activated: IIS reads the
HistoryMajorVersionNumber property value in MetaBase.xml. The corresponding history file
(the one with the highest minor version number and same major version number in the history
folder) is searched for. If the file is found, the MetaBase.xml file is parsed, looking for fatal
XML errors. If no errors are found, MetaBase.xml is compared with the history file and changes
are identified. If changes were made (the key to which changes are made is also in the inmemory metabase through the Admin Base Objects layer—see the illustration in Figure 2.19),
the changes do not violate the schema, and the metabase is not write-locked, the changes are
written to the in-memory metabase. (The metabase might be write-locked if changes are being
made at this time programmatically.) A new history file is then written to the history folder. If
errors occur during this process, they are written to the event logs and changes are not recorded.
Figure 2.19: Illustration of the process triggered when the modified MetaBase.xml file is saved.
Chapter 2
Enabling the Edit-While-Running Feature
To allow modifications to be made to the metabase while IIS is running, you must enable the
edit-while-running feature. You can do so from the IIS Manager (IIS will not need to be stopped
and started), or by manually editing the MetaBase.xml file and restarting IIS. Metabase history
must be enabled to do so (enable history = 1).
To enable the edit-while-running feature using IIS Manager, right-click the local computer in IIS
Manager, and select Properties. Select Enable Direct Metabase Edit (see Figure 2.20), then click
Enabling the edit-while-running feature depends on metabase history to track setting modifications. If
metabase history is not enabled (it is by default), you cannot enable the edit-while-running feature.
Each MetaBase.xml file is marked with a unique version number and saved in the history folder
(%windir%\system32\inetsrv\history) along with MBSchema.xml. A change history is therefore
available as well as a backup. The default number of metabase file pairs is 10. (If the number of file
pairs has reached 10 and a new file pair needs to be saved, the oldest file pair is deleted.)
Figure 2.20: Enabling the edit-while-running feature.
To enable the edit-while-running feature by directly editing the MetaBase.xml file, open
MetaBase.xml with Notepad from the %windir%\system32\inetsrv directory. Navigate to the
IISComputer node, and change the value of EnableEditWhileRunning to 1. Save changes, close
the file, and restart IIS.
Chapter 2
Securing the Metabase
The metabase survival is critical to the operation of IIS. Thus, you do not want unauthorized
changes to be made. To secure the metabase, use sound security practices and include file-level
security and encrypted properties. The security recommendations that Microsoft suggests for this
purpose are paraphrased in Table 2.6.
Use complex passwords
Don’t write them down
Maintain access control on
metabase-related files
For more information about these files, see Table 2.7
Use the concept of least
Only give the minimal and necessary permissions and privileges to users
Do not use EFS to encrypt the
Doing so slows IIS and might cause errors
Copy the MetaBase.xml file
before manually editing it
You can restore a good copy of MetaBase.xml by copying the good
version of a corrupted MetaBase.xml
Create backups using the
backup/restore configuration
Do so frequently and whenever changes are made to the metabase
Do not use import and export
to backup the metabase file
Sensitive data (such as passwords) is not exported; import and export is
meant for transferring sections of the metabase file to another computer
Backup content
Metabase backup does not backup content files
Prevent simultaneous
metabase changes
Can cause corruption
Monitor event logs for related
IIS event messages
Learn what the error messages mean and how to correct the situation
Set up file auditing on the
metabase files
You can identify who has been mucking with, and potentially corrupting,
the metabase files; only manual edits of the file are recorded giving the
user name; set auditing on tool executables to determine who is using
Table 2.6: Microsoft security recommendations.
All metabase-related files and folders are secured by the default permission settings, which grant
full control to NT AUTORITY\SYSTEM and BUILTIN\Administrators. To restrict these
permissions further, you might want to create a select group of administrators and give them Full
Control while removing the local Administrators Group. Related files and folders are identified
in Table 2.7.
File/Folder (all are located at %systempath%\System32)
The configuration storage database
The schema for the configuration file
The metabase history files
The metabase backup files
Table 2.7: Metabase-related files.
Chapter 2
Because the MetaBase.xml file is written in plain text, several sensitive metabase properties
(such as the anonymous user password) are encrypted in the MetaBase.xml file so that they
cannot be viewed by unauthorized users. These encrypted properties should not be edited
directly. A table of encrypted properties can be found in the Encrypted Properties Help file. You
cannot modify the encrypted property of an existing schema property; however, you can use
ADSI to add new properties to the schema with the encrypted property set.
Do not attempt to edit directly the encrypted properties, as there is no way to encrypt your entries
before saving the xml file. Encrypted properties should only be modified using WMI, ADSI, or Admin
Base Objects.
Chapter 3
Chapter 3: Understanding Active Directory Foundations
Q 3.1: My company will be merging with another. Both companies
have their own Windows 2000 forests. I know we will want to provide
access to some resources in each forest to users with accounts in the
other. What’s the best way to do so?
A: Well, you could give users who need access in a forest an account in that forest. Seriously,
this approach may be valid when you want to maintain the security boundaries between forests
and especially so if very few people need access. You do have other alternatives; the choice you
make depends on the nature of the forest and the nature of the access you require. Other than the
new account, new password approach, you have three choices: Combine all users and resources
into one forest, create a Windows NT–style one-way trust (otherwise known as an external trust),
or, if both forests are Windows Server 2003 forests, create a Windows Server 2003 cross-forest
trust. Let’s assume that in this case immediate consolidation into one forest is not an option.
External Trusts
If the forests are both Windows 2000 (Win2K) forests, or if you are using the word forest to also
mean NT domain, or if only one of the forests is a Windows Server 2003 forest, you can create
NT-style trusts between two domains. Be very clear about this—these trusts are not Kerberos
trusts, they are one-way, non-transitive trusts between two domains (one from each forest). NT
LAN Manager (NTLM) is used for authentication. These trusts are called external trusts.
Non-Transitive Trusts Mean Limited Access Between Forests
Within a Win2K or Windows Server 2003 forest trusts are transitive, which means every domain
trusts every other domain. Therefore, a user account that resides in one domain can be given
access to resources and privileges in any other domain. (This means that resource access can be
assigned to any forest resource to any user with an account in any domain in the forest. However,
no default access is given; it must be created.) Figure 3.1 illustrates trust relationships in a
Win2K or Windows Server 2003 forest. The forest is composed of two trees, Teluro.local and Two-way arrows between domains indicate trust relationships. Although not usually
explicitly diagrammed, each domain also trusts every other domain in the forest. User Alice,
with an account in domain West.Teluro.local can be given access to a file server in the domain and a printer in the East.Teluro.local domain. Likewise,
Bob, a user in the domain, can be given access to these resources. Dotted lines
indicate successful resource access.
Chapter 3
Figure 3.1: Transitive, two-way Kerberos-style trusts are created between all domains in a forest.
None of the trust relationships is explicitly defined; they occur because the forest and tree
membership of a new domain is specified during promotion. There is also no way to remove that
trust. The trust exists because the domain is a member of the forest.
In Win2K, there is really no such thing as a trust between forests. You can only have a trust between
two domains, each of which is a member of a different forest. If trust relationships are required
between multiple domains from two different forests, multiple trusts between each domain pair must
be established.
An external trust, however, is created between two domains in separate forests. It only creates
the trust in one direction. Such a trust is an NT-style trust. A trust created between two domains,
the domain in one forest and the domain in another
forest provides one-way access depending on choices made when the trust is created. If the domain is the trusted domain, users in the domain can be given
access to resources in domain Users in the
domain cannot be given access to resources in the domain.
Chapter 3
Figure 3.2 shows that Mary, who has an account in the domain, can be given
read permission on the accounting file that is on a server in domain.
Bob, however, whose account is in the domain can’t be given access
to the printer in the domain through the same trust relationship. In addition,
through this trust, Mary cannot be given access to any other domain in the other forest unless
another explicit NT-style trust is created between her domain and the other. Access to a printer in
the domain is not possible unless you create another trust.
Figure 3.2: An external trust creates a one-way, non-transitive relationship between two domains in different
Because the external trust is non-transitive, each access requirement from a different domain
creates a need for a new trust relationship. Figure 3.3 illustrates one-half of the trusts necessary
to provide the full access between every domain in each forest. Rather messy at best, but the only
option available prior to Windows Server 2003.
Chapter 3
Figure 3.3: Multiple trust requirements result in multiple trust relationships.
This type of trust (one-way, non-transitive relationship) is often exactly the trust required. It offers
security benefits—creating this trust does not grant more privileges than are required and can
maintain stronger security boundaries (this trust grants no automatic privileges, rights, or access
between domains). Although creating trust relationships is about possibility, there is the possibility
that a privileged user in one domain can maliciously gain access to objects in another. For example,
when two domains trust each other, any user in either domain can be granted access in the other. Via
accident or malicious attack the possibility is greater in this case that access might be given or taken
where it shouldn’t be. If there is no legitimate reason for granting such trust, then don’t. If possibility is
limited, an attacker’s ability is also limited, and that is always a good security goal.
Forest Trust
Windows Server 2003 offers a better solution for the everyone-trusts-everyone objective.
Windows Server 2003 lets you create a forest trust between the root domains of two Windows
Server 2003 forests, and provide one-way or two-way transitive trust between all domains in
both Windows Server 2003 forests. If a two-way trust is created, any user in any domain can be
given access to any resource in any other domain in either forest. Figure 3.4 illustrates this type
of trust relationship. Here, Mary, and Bob can be provided access to any resource anywhere in
either forest without creating additional trust relationships.
Chapter 3
Figure 3.4: The Windows Server 2003 forest trust.
Forest trusts may be a solution for companies who are merging, companies in partner
relationships who require joint access to resources, and for those seeking to consolidate
administrative authority in organizations in which multiple forests were created in an ad hoc
manner. However, before selecting forest trust as the answer, every organization should evaluate
its needs and the benefits of providing this type of access.
Requirements for Forest Trusts
Before a forest trust can be created the following conditions must be met:
The functional level of the forest must be Windows Server 2003. (Therefore, all domain
controllers must be Windows Server 2003, and the domain-functionality level for each
domain must be set to Windows Server 2003.)
Domain Name System (DNS) must be configured to insure name resolution for both root
forest domains. A DNS server can be authoritative for both domains, each DNS server
can list the other’s DNS server as a conditional forwarder, or you may use root hints or
delegated zones.
To create a forest trust, an administrator must be an Enterprise Admin. An Enterprise
Admin in the other forest must complete the trust.
Chapter 3
Win2K domains start in mixed mode. When all domain controllers in the domain are Win2K domain
controllers, the domain can be changed to native mode. Windows Server 2003 introduces a new
term—forest functionality level. Forest functionality level indicates the minimum operating system
(OS) level of every domain controller in the forest. When all domain controllers throughout the forest
are Windows Server 2003, the forest functionality level may be changed to Windows Server 2003.
Those familiar with the Win2K designations mixed mode and native mode domains can follow
the logic for Windows Server 2003. For example, additional Win2K features such as Universal
Groups are only available after the domain mode of a Win2K domain is changed from mixed
mode to native mode. A Win2K forest composed only of native mode domains could use these
features to full advantage. Instead of using the term mode, Windows Server 2003 adopts the
terms domain functionality and forest functionality. Three domain functional modes are
available, and each provides different capabilities. Table 3.1 describes the functional levels and
their requirements. By default, a Windows Server 2003 domain begins life as a Windows Mixed
functional domain, and Windows Server 2003 forest functionality is initially Win2K Mixed
You must set Windows Server 2003 domain and forest functionality modes. You do so on the General
page of the domain or forest root folder in Active Directory Domains and Trusts.
Domain Description
Forest Description
Windows Mixed
Some combination of Win2K, Windows Server 2003,
and NT domain controllers; NT and Windows Server
2003 servers are OK
Some combination of Win2K
and Windows Server 2003
Windows 2000
Native Mode
Win2K domain controllers only; no NT or Windows
Server 2003 domain controllers; NT and Windows
Server 2003 servers OK
Win2K native mode domains
and Windows Server 2003
Windows Server
Windows Server 2003 domain controllers only; NT
and Windows Server 2003 servers OK
Windows Server 2003
domains only
Table 3.1: Windows Server 2003 domain and forest functionality.
Forest functional modes define the status of domains within the forest. Thus, a Windows Server
2003 forest in which all domains are Windows Server 2003 in functionality is a Windows Server
2003 functional mode forest. Just as a forest composed entirely of Win2K native mode domains
can take advantage of advanced features, a Windows Server 2003 functional forest can as well.
One of the advanced features is the ability to create forest trusts.
Forest Trust Details
A forest trust can be either two-way or one-way. The terms incoming and outgoing are used in
Windows Server 2003 to define the direction of trust. After you complete a forest, users may be
assigned access to resources in the other forest, as defined during trust setup. Authentication
from the trusting forest to the trusted forest is also possible. Authentication may be Kerberos or
Chapter 3
Creating a Forest Trust
Creating a forest trust is made quick and easy by a new trust wizard. Although the operation can
be accomplished with participation by a member of each forest’s Enterprise Admins group,
should one individual have this membership (albeit with two separate accounts) in both forests,
the trust can be set up from one forest. To set up the trust
1. Open Active Directory Domains and Trusts.
2. Right-click the forest root domain (this is the first domain), and select Properties.
3. Select the Trust tab, and click New Trust.
4. Enter the DNS name of the other forest root domain (this is the second domain).
5. Select forest trust.
6. Enter the direction of the trust:
Two-way—Users from either forest can be assigned access by users from the
other forest.
One-way (Incoming)—Users in the first (trusted) forest can be assigned access to
resources in the second (trusting) forest, as Figure 3.5 shows.
Figure 3.5: A one-way incoming trust.
One-way (Outgoing)—Users in the second (trusted) forest can be assigned access
to the resources in the first (trusting) forest, as Figure 3.6 shows.
Chapter 3
Figure 3.6: A one-way outgoing trust.
7. Select the sides of the trust.
8. If This domain is selected, the trust is created in this domain. Enter and confirm a
password. An administrator must complete the trust at the other forest.
9. If Both this domain and specified domain is selected, enter a user name and password
from the second forest.
If you have not elevated the forest functionality to Windows Server 2003, you cannot create a forest
trust. (Check the forest functionality, not the domain functionality.)
This new terminology—first forest, incoming, outgoing—can be confusing. In both Figure 3.5
and Figure 3.6, the forest is the first forest, the forest from which the trust wizard was
first run. In Figure 3.5, the trust arrow points to the forest. The arrow is incoming, so
the trust is incoming. The forest is the trusted forest. Those familiar with diagrams of
NT and Win2K external trusts will recognize the phrase you point to people you trust. That also
applies here. The users in the forest can be granted access to any resource in the forest. This trust doesn’t give users in the forest
access to resources in the forest.
In Figure 3.6, the trust arrow points away from the first forest. It is an outgoing trust. The forest is now the trusted forest and users in its forest can be granted access
to resources in the forest.
Chapter 3
Q 3.2: Help! We have a large, multidomain forest that contains
thousands of users, and we use universal groups extensively to
provide access to resources. We also have many small branch offices
that have only a handful of users each. Because the Global Catalog
server must be accessed at logon to determine membership in
universal groups, all users at branch offices access Global Catalogs
across the WAN even though they have a domain controller locally. If
I make the domain controllers at these branch offices Global Catalog
servers, I’ve increased the replication traffic by an unacceptable
amount. Does Windows Server 2003 have an answer?
A: Windows Server 2003 does provide a better way to handle this problem. To understand why
Microsoft developed Windows Server 2003’s solution and when it should be used, you must
understand the relationship between authentication, universal groups, native mode, and Global
Catalog (GC) servers in Windows 2000. Win2K universal groups can exist only in native-mode
domains. Universal groups can have as members any user from any domain in the forest, from
any other universal group, and from any global group from any domain in the forest. Universal
groups can be granted access to any resource in the forest. They often serve as collections of
global groups from multiple domains. Thus, any resource can, with the inclusion of a single
access control entry (ACE), provide access to large numbers of users. This functionality
simplifies administration of resources and reduces the size of the discretionary access control list
(DACL) on any one object, as Figure 3.7 illustrates. In the diagram, the ForestPrinters universal
group is granted the right to print to printers located in domains A, B, and C. The ForestPrinters
group has as members three global groups: Aprinters, Bprinters, and Cprinters. Each of the three
groups consists of users from the respective domains.
Figure 3.7: Use of the universal group ForestPrinters reduces the number of ACEs in a DACL.
Chapter 3
When Nancy, a user in domain C, logs on to the domain controller in domain C, her membership
in any universal groups must be determined. This information is determined by querying the GC
server. In this forest, the available GC server is a domain controller in domain A. The group
security IDs (SIDs) of the groups Nancy is a member of, including the ForestPrinters group,
become part of the information in the Kerberos tickets returned to her computer and can be used
to create access tokens. This activity is transparent to Nancy. If everything works as designed,
Nancy gets her desktop and is able to compose documents, print them, and do other jobs.
A problem can occur, however, if Nancy works in a branch office and there is no domain
controller from her domain present in her branch office. If such is the case, to complete her log
on, her computer must be able to access a domain controller and a GC across the WAN. Figure
3.8 illustrates this process. In step 1, Nancy’s computer will contact the domain controller
located at headquarters. In step 2, the domain controller contacts the GC to determine Nancy’s
universal group membership. Finally, in step 3, the information is returned to Nancy’s computer
as part of a Kerberos ticket. If the WAN link is down, Nancy’s computer will not be able to
reach the domain controller or the GC server. She will not be able, therefore, to be authenticated
by the domain controller or obtain current information about her membership in and groups,
including universal groups. She can, of course, log on with cached credentials, but might then be
limited in her ability to access network resources. Cached credentials may be out of date and,
thus, not provide correct information to provide her with the rights and privileges she needs to do
her job. She also may have trouble connecting to and using network resources as neither her
system nor the network resource can complete the processing necessary.
Figure 3.8: Logging on from a branch office requires WAN access to a domain controller and GC server.
Chapter 3
Win2K Branch Office Solutions
The intuitive solution to branch office logon for mixed-mode Win2K environments is to place a
domain controller in all but the very smallest branch offices. By very small, I mean less than 10
employees. Microsoft guidelines also discuss the use of a single domain controller in a branch
office that houses between 10 and 50 users, or calculating the number of domain controllers
required based on Group Policy requirements and the use of applications that rely heavily on
Lightweight Directory Access Protocol (LDAP) queries against Active Directory (AD).
These guidelines work well while the domain is in mixed mode. However, when domains are
moved to native mode, you can create universal groups, which means that logons from branch
offices will seek a GC server across the WAN if necessary regardless of whether a domain
controller is present. The intuitive solution no longer works. Figure 3.9 illustrates this scenario.
When Nancy attempts to log on, her computer is able to communicate with the local domain
controller. However, to find a GC, the domain controller must communicate across the WAN to
a GC at headquarters. The figure also represents, with the use of dotted lines, replication of data
between GCs at headquarters. (Actual replication patterns will vary, but the concept is correctly
displayed—information from all domains is replicated to all GCs.) Locating a GC only at
headquarters may be an acceptable practice if the number of users in Nancy’s branch office is
small and WAN connections are stable and meet bandwidth requirements. However, if the WAN
link is down, the GC cannot be reached and normal logon will not be possible. If, however,
cached credentials exist for Nancy on the computer she is using, then logon will occur.
Figure 3.9: A domain controller at a branch office doesn’t eliminate the need for WAN access to a GC.
Chapter 3
Is it possible that the lack of a GC server can mean that clients will not be able to log on? Yes, if no
cached credentials exist for a user in a native-mode domain and the GC cannot be reached, the user
cannot be logged on. This behavior will not affect an administrator. For more information please see;EN-US;q216970.
A solution to this is to place a GC server at each branch office that has a domain controller.
However, although this setup means localization of authentication traffic, it means increased
replication traffic over the WAN. The GCs must replicate changes in forest data between
themselves. Branch offices with low bandwidth connections might find replication demands
excessive. In addition, branch office domain controllers might not meet the increased memory
and processor requirements of a GC. Figure 3.10 illustrates the authentication and GC replication
patterns in this scenario.
Many forests consist of domains that are in mixed mode and domains that are in native mode. Nancy
might be a member of universal groups located in the native-mode domains while her domain is still
in mixed mode. What will the logon behavior be? In this scenario, Nancy’s logon does not have to
access a GC. Instead, should Nancy attempt to access a resource that has universal group access
assigned, the domain controller for that domain will be contacted, then the domain controller will
contact the GC to determine whether any universal group membership SIDs need to be added to
Nancy’s access token.
Figure 3.10: Authentication traffic across the WAN can be decreased by placing a GC at a branch office, but
this setup means increased replication traffic across the WAN.
Chapter 3
Windows Server 2003 Universal Group Membership Caching
Windows Server 2003 provides a simple solution to the problem. Because the major reason that
branch offices need access to a GC is to determine group membership in universal groups,
Windows Server 2003 lets you configure domain controllers to provide universal group
membership caching. If this option is enabled, the first time a user logs on, universal group
membership must be determined by contacting the GC server across the WAN. Membership
information is then cached indefinitely on the designated domain controller. The following rules
govern this behavior:
Cached data is periodically refreshed.
The default refresh time is 8 hours
You can refresh 500 users’ cached universal group membership data at one time.
The ability to cache membership data is site specific; thus, all domain controllers in that
site must be Windows Server 2003 server machines.
Universal group membership caching allows faster logons and reduces the need for locating GC
servers at branch offices; thus, reducing replication traffic on the WAN. GC servers may still be
required at branch offices that use applications that rely heavily on LDAP searches of AD. To
configure a Windows Server 2003 domain controller for universal group membership caching:
1. Open Active Directory Sites and Services.
2. Expand the Site object for the site where universal group membership caching is desired.
3. Double-click the NTDS Site Setting object.
4. On the Site Setting tab of the NTDS Site Setting Properties page, which Figure 3.11
shows, select the Enable Universal Group Membership Caching check box.
5. In the Refresh cache from box, select the site from which the cache should be refreshed.
Figure 3.11: Configuring universal group membership caching.
Chapter 3
Q 3.3: Our IT Audit department wants me to change the Kerberos
policy and set the time skew back to 5 minutes. If I do so, many users
will have logon problems. How can I convince management that IT
Audit is wrong?
A: One of the most confusing elements in Windows 2000 (Win2K) and Windows Server 2003
domains is the W32Time service—how it synchronizes time between all computers in the
domain and the impact of time on logon. Early installation instructions don’t explain the reliance
of Kerberos on time, and many organizations run into logon problems. In a busy environment,
problems are often resolved by attacking the symptom instead of digging into the cause. In an
effort to ease logon, many administrators—who did not understand the reason for Kerberos’
reliance on time—solved the problem by modifying the domain Kerberos policy Maximum
tolerance for computer clock synchronization, commonly referred to as the time skew. The time
skew is the allowable difference between the timestamp accompanying the logon credentials and
the time on the domain controller. Adjusting the Kerberos policy time skew is a quick solution
that rids the administrator of pesky Kerberos logon errors, but is not an adequate solution. To
understand why, you must understand how and why Kerberos uses time and how the time server
works in Windows Server 2003 and Win2K. If you’ll give me a chance, I think I can convince
you to rethink your battle with IT Audit.
Time Service Operation
Win2K introduced the time synchronization service, W32Time, that is present in Windows
Server 2003. W32Time is an implementation of the Simple Network Time Protocol (SNTP) as
described in the Internet Engineering Task Force (IETF) Request for Comments (RFC) 1769.
SNTP is a derivative of the Network Time Protocol. NTP can accomplish a higher degree of
accuracy and has significant management utility, complexity, and size. NTP can offer
synchronization to within microseconds, and SNTP can achieve synchronization to within
milliseconds—an adequate measurement for the purposes of Kerberos. In a Win2K or Windows
Server 2003 forest, W32Time can keep computer clocks in a site within 2 seconds of each other,
and those throughout the enterprise within 20 seconds of each other. Such synchronization is
accomplished automatically if the PDC emulator of the forest root is synchronized with an
accurate time source. (It presumes insignificant latency in network function—there are not
unusual delays in data transfer or network operation.)
If your application requires tighter synchronization, you can designate specific Win2K or
Windows Server 2003 computers to synchronize with other time sources or seek third-party
software. You should be aware, however, that if your solution removes the ability of the entire
forest to synchronize with a single source, you are increasing the maintenance costs and reducing
security. Kerberos relies on the synchronization of time between client and domain controller. If
you are using multiple time sources, the potential exists for an attacker to compromise one or
more of them, and thus be successful in using a replay attack.
Chapter 3
W32Time messages from the domain controller are authenticated. The secure computer password of
the client is used by the domain controller to sign a 64-bit hash of the time message. This signature
accompanies the time. When the client receives the message, it uses the same algorithm to hash the
offered time, decrypts the signed hash to get the hash sent by the domain controller, and compares
the two. If they do not match, the time is rejected. Because the client password is only known to the
domain controller and the client, this system is reliable. However, if a Win2K or Windows XP client is
configured to synch with its own timeserver instead of accepting a time message from the domain
controller, the time messages from the time server are not signed and therefore not secure.
Time Convergence Process
When you boot a Win2K, Windows XP Professional, or Windows Server 2003 computer that is
joined in an Active Directory (AD) domain, the system contacts a domain controller for
authentication purposes. Based on information from the domain controller, the time service
calculates the local or target time. This time is compared with the actual time on the computer.
The client then adjusts its local time to be the target time. Time is initially checked at 45-minute
intervals, but if the target time and local time are the same, the time interval for checking is
increased to 8 hours. In this manner, client machines can be kept in time synch with their domain
controllers. Domain controllers look to assigned time servers or the PDC emulator of the domain
to adjust their own time. The PDC emulator of the domain syncs with the PDC emulator of its
parent domain or with the PDC emulator of the forest root domain (see Figure 3.12). The forest
root domain PDC emulator should be synched with a reliable time service. If such is not the case,
multiple W32Time errors will clog the system log. The many designated time servers on the
Internet are useful time server sources.
Figure 3.12: A time-synchronization-hierarchy diagram.
Chapter 3
Impact of Time Skew on Kerberos
Kerberos is the preferred network authentication protocol used by Win2K and Windows Server
2003 computers joined in a domain. It is a standards-based authentication protocol specified in
RFC 1510. This protocol has many built-in features that are designed to prevent common types
of attacks. One such attack is the replay attack, an attack in which the attacker captures
authentication material as it is passed across the network, then attempts to use it to gain access to
network resources by attempting to pose as the original user or computer. To prevent the success
of this attack, the Kerberos standard calls for synchronized clock values across the network and
makes computer clock time an important part of the security of the protocol. For this reason,
Microsoft implemented time synchronization in the form of W32Time in Win2K and Windows
Server 2003.
The Kerberos authentication process is complex, but the impact of time can be sketched in a few
steps. The Kerberos client presents logon credentials to the domain controller. An integral part of
these credentials is the timestamp from the client computer. To prevent modification to the
timestamp, the timestamp is encrypted. This encrypted data is called the authenticator.
When credentials are received at the domain controller, the server decrypts the authenticator and
extracts the client clock time. It then compares the client time with its own clock. If the
difference is larger than an acceptable time skew designated by Kerberos policy, the
authentication will fail. The Kerberos server also checks to make sure that the authenticator does
not have a time that is earlier or the same as an authenticator already received from this client. (If
it does, the credentials are rejected.) If the timestamp passes these tests, the server modifies the
authenticator, re-encrypts it with the session key, and returns it to the client. The client then
decrypts the authenticator. Because only the client and server share the session key, the client
uses the modified authenticator to authenticate the server. This process of mutual authentication
is another strong security feature of Kerberos.
Part of the reason for a time skew is to accept reasonable transport time and minor clock
differences as part of the equation. The time skew cannot be too large, however, as that would
give an attacker time to devise and carry out a replay attack.
On a Win2K or Windows Server 2003 network, the time skew is set to 5 minutes, which is more
than enough time for most credentials to traverse the network and to allow for minor time
difference between systems, yet not enough time for an attacker to prepare a replay attack.
However, when there is a significant time difference between the timestamp that accompanies
the logon request, and the clock on the domain controller, some legitimate domain logons will
fail. Adjusting the time skew is one possible answer (see Figure 3.13), of course, but the mistake
most administrators make is to enlarge the time skew too much, thus weakening this protective
Chapter 3
Figure 3.13: The Kerberos policy time skew setting.
A Rational Solution to WAN Kerberos Logon Problems
Although adjusting the Kerberos time skew may solve Kerberos logon problems, you should
investigate the possible causes of the problem. The first, and most obvious, is checking the time
differences between client computers and their domain controllers. A computer clock problem,
or a server operator who incorrectly modifies the time, could be the cause.
One consideration that will not be an issue is the time differences between time zones. If clocks
are synchronized, the fact that different time zones are selected in the interface has no meaning.
Win2K and Windows Server 2003 are set to common Universal Time Coordinate (UTC), the
interface reflects UTC plus or minus some number of hours according to time zone. However, if
the clock differences are not the result of time zones, there will be a problem because the clocks
are not synchronized. Restricting the ability to modify system time and monitoring for faulty
clocks will help you avoid many of the Kerberos time problems.
If logon issues as a result of network latency are the problem, attempt to calculate the minimum
increase in skew time that will eliminate the problem instead of enlarging the skew by a random
large amount. It is likely that network latency is causing other problems as well, and perhaps a
better solution can be found in attacking the cause of the latency rather than increasing the risk of
The Microsoft article “A List of the Simple Network Time Protocol Time Servers That Are Available on
the Internet” (Q262680) can assist you in finding a reliable time source.
Chapter 3
Q 3.4: What possible advantage is there to implementing universal
A: The successful and advantageous use of universal groups depends on the understanding and
usage of other Windows groups. In an environment in which no disciplined use of other
Windows groups is implemented and assignment of rights and resource access is made to
individual user accounts, there is little to no advantage to be gained by adding universal groups
to the mix. However, in environments in which global groups and local groups have been
properly implemented, the careful and appropriate addition of universal groups is a logical
extension that can ease the administration and audit of large Active Directory (AD)
To obtain the full benefits of universal groups, multiple domains in the forest must be at the
Windows 2000 (Win2K) native or Windows Server 2003 domain functional level. For a domain
to be in Win2K domain functional level, an environment must contain no Windows NT domain
controllers and at least one Windows Server 2003 domain controller. A domain cannot be set to
Windows Server 2003 functional level until all domain controllers are Window Server 2003
systems. In either case, the domain functional level must then be set; it will not automatically be
changed. For a forest functional level of Windows Server 2003, all domains must be at Windows
Server 2003 domain functional level, and the forest must be set to Windows Server 2003 forest
functional level.
A Win2K domain controller is not aware of domain or forest functional level. Instead, a Win2K
domain exists in mixed or native mode. When a Windows Server 2003 server is promoted to
domain controller, its domain functional level is Win2K mixed. An AD domain could consist of
NT, Windows Server 2003, and Win2K domain controllers. We classify the functional level of
this type of domain as Win2K mixed. The functional level can be raised to either Win2K native
or Win2K and Windows Server 2003 depending on the types of domain controllers present.
Different group types, scope, and membership are dependent on the forest functional level.
An additional domain functional level, Windows Server 2003 interim, can be selected when an NT
domain controller is upgraded to become the first Windows Server 2003 domain controller in a forest.
The Windows Server 2003 interim functional level provides improved replication algorithms and group
management. Win2K servers cannot be promoted to become domain controllers if the Windows
Server 2003 domain functional level is interim. The interim functional level is only meant to exist until
all NT domain controllers in the domain have been upgraded or retired.
Win2K Mixed Domain Functional Level Group Management Practice
Best practices for group administration in NT and Win2K mixed mode is clearly illustrated in the
acronym, AGLP: placing accounts (A) into global groups (G), nesting global groups in domain
local groups (L), and assigning resource access permissions (P) to domain local groups. Figure
3.14 illustrates this concept. In the figure, Nancy and Carol are members in the DomainClerks
global group. On each server A, B, and C, a local group Clerks exists. DomainClerks is a
member of each of these Clerks groups. On each server, the local group Clerks has been granted
resource access to folders that the members of the DomainClerks need to do their job. Because
the local group has the permission and therefore its members have this access, Nancy and Carol,
by extension, have the access required to do their jobs.
Chapter 3
Figure 3.14: Assignment of access to clerks using AGLP.
For those who are new this concept, it might initially seem easier to simply add Nancy and Carol
to each of the local Clerks groups on the three servers, or if there are few required resources, to
directly give Nancy and Carol the required permissions on the resources. However, in all but the
smallest environment, this process becomes unmanageable very quickly. When new clerks are
hired, they too must be given access to resources. When new servers or resources are added, all
of the clerks must be added to the access lists, or at least to the new servers’ local groups. What
happens when a clerk quits or is fired? To remove the clerk’s access from multiple servers or
multiple resources can become quite a chore. It could take months, even years, to determine to
which resources Carol has access and remove that access. In addition to being messy and at some
point a detriment to performance, this scenario creates a security vulnerability. Unmanaged
access to resources exists that might be discovered and utilized by an attacker.
However, if best practice (the AGLP process) is followed, the management of users and resource
access is immensely simplified. If John joins the company as a new clerk, you simply need to
add his account to the global group DomainClerks, and he immediately has access to the
resources he needs to do his job. If Carol quits, the administrator can simply remove her account
from the DomainClerks group, and she, or anyone able to log on to her account, has no access to
these resources. This setup is also easily auditable. You simply identify the appropriate resources
for clerks, examine the resources to determine the groups, then trace back to the global group and
its membership to determine access. To determine whether access has been granted only to those
who should have access, you simply review the account list.
Chapter 3
This practice is also extensible to multiple domains where trust relationships are correctly
configured. In Figure 3.15, a second domain has been added to our example.
Figure 3.15: Extending AGLP to multiple domains.
If the members of the DomainClerks group need access to resources in this new domain, you can
provide it by
Establishing a trust between the two domains. If both domains are Win2K domains in the
same forest, this trust is already established. If they are not, an NT-style trust must be
Creating a local group Clerks on each server in the domain on which there are resources
to which clerks need access (or in a Win2K functional level or Windows Server 2003
functional level domain, creating a domain local group on the domain controller).
Creating access control lists (ACLs) on the appropriate resources, and granting the Clerks
group appropriate access.
Adding the global group DomainClerks to each of these local groups.
Chapter 3
In addition, should the new domain have users who need access to the same resources, you can
create a new DomainClerks global group for that domain and make it a member of each local
Clerks group. Adding domain2 users to the domain2 DomainClerks global group provides the
users with access to the resources in domain2. Should they also require access to resources in
domain1, you can simply add the DomainClerks group from domain2 to the local Clerks groups
on domain1 servers. You can repeat this process for each new domain. If you have used the
AGLP formula to implement groups in your mixed mode forest, you will recognize this
structure. When you convert domains to native mode, you do not have to change this
configuration to continue providing appropriate access.
Win2K Native or Windows Server 2003 Domain Functional Level and Universal
When all NT domain controllers have been upgraded to Win2K or decommissioned, a Win2K
domain may be changed to native mode. (If the Win2K domain was established as the result of a
clean install and no NT domain controllers are part of the domain, a Win2K domain can
immediately be changed to native mode. However, this change doesn’t occur automatically.) If a
Windows Server 2003 domain controller is part of the domain, the domain functional level is
Win2K mixed by default, but in the absence of NT domain controllers can be raised to Win2K
native. In native mode, or in Win2K native domain functional level, universal groups and
additional group nesting rules are available. Table 3.2 lists the groups, scope, and membership
available in a Win2K mixed mode domain or a Win2K mixed functional level domain as well as
in Win2K native functional level.
Group Type
Win2K Mixed Mode or Win2K Mixed Functional Level
Assigned permission in any
Accounts in the same domain
Domain Local
Assigned permission only in the
same domain
Accounts and global groups from
any domain
Win2K Native or Windows Server 2003 Functional Level
Assigned permission in any
Accounts, global groups, and
universal groups from any
Assigned permission in any
Accounts and global groups in
the same domain
Domain Local
Assigned permission only in the
same domain
Accounts, global groups, and
universal groups from any
domain; domain local groups
from the same domain
Table 3.2: Groups, scope, and membership.
To illustrate the use of universal groups, I’ll return to the previous example. We still have
domains A and B, but now the domain functional level has been raised to Win2K native. We
don’t have to modify group type, membership, and so on to continue to use the resources in the
domain and to manage additional resources and users. Everything works as before. However,
with a simple change, we could reduce future user and group administration activity.
Chapter 3
To do so, you can create and use a UnivClerks group. Instead of adding multiple domain global
groups to the domain local groups, we add the single universal group to the domain local groups.
The global groups are added to the universal group, and our users Carol and Nancy have access
to the resources they need. Users are added to the global groups, so the domain administrators
still maintain control over the users who have access to resources in the domain administrators’
domains. The domain administrators control the access of universal groups to resources, so they
maintain their control over resource access to some degree. However, they cannot supervise the
membership of other global groups that are members of the universal groups. Figure 3.16 shows
how the previous scenario changes with the addition of universal groups.
Figure 3.16: Adding universal groups.
Chapter 3
Q 3.5: Is it possible to place the Active Directory database on a
different drive from its logs?
A: Yes! It is possible, and there are very good reasons for doing so. First, having the database
and log separated makes more room on the database drive. As the database expands, there will be
more room on the drive because the log files are not taking up space (adequate room on the log
file drive must also be provided). Furthermore, adequate space for log files can also be assured.
Second, keeping log files on a separate physical disk from the database can assist in recovery.
Third, should the hard drive on which the database is installed become uncomfortably full
(Active Directory—AD—requires plenty of space and should not be pinched by lack of free
space on its drive), moving the database to another, larger drive, is an alternative to rebuilding
and restoring.
First, however, a little background is in order. Like many transaction-based databases, changes
are not written directly to the AD database. Instead, changes are written to a transaction log and
eventually the directory is then updated. This two-step process preserves the integrity of the
database should processing be interrupted. Without the transaction log, an interruption might
leave a transaction half done. Suppose, for example, that you instructed AD to move Joe Blow
from the Accounting organizational unit (OU) to the Finance OU. Although you and I see the
transaction as one smooth move, the database sees it as two. First, Joe is removed from
Accounting, then he is added to Finance. If the power goes out after he is removed from
Accounting but before he is placed in Finance, we’ll have a problem. What’s happened to Joe’s
account? When the server reboots, Joe’s account might have disappeared from Active Directory
Users and Computers. Worse still, some of Joe’s data might have made the move, while other
parts may be lost. However, the transaction log ensures that, even in the case of a power failure,
transactions can be recovered.
During normal operation, each transaction log is checkpointed, that is, it is marked as to which
transactions have completed. You can think of checkpointing like putting a check mark next to
completed tasks in a task list. Changes to AD are written one after another to the log file.
Meanwhile, previously written transactions are entered into the database. When a transaction is
complete, the checkpoint is moved. Should the system go down, the checkpoint shows where
completed processing was. When the computer reboots, the logs are checked, and if a transaction
is incomplete, the data in the logs can enable its completion or at least the removal of partial
changes so that the database is the same as it was before the transaction began. The ability to
rollback or roll forward transactions cements the integrity of AD and is essential to its operation.
In many cases, full recovery is possible after system failure.
If, however, the database should become corrupt or the problem is the hard drive itself, recovery
from backup is facilitated if all logs as well as the database have been backed up. A database
restore, along with the application of backed up logs can bring the directory very close to current.
If logs and database are on separate physical drives, then one of two scenarios is possible: If the
database drive is lost, it may be possible to restore the database from backup, then apply the logs
for the log disk(if the logs are online, this action is automatic). Everything can be returned to
normal. If the log drive is lost and the current database is intact, the system will discard any
partially completed transactions.
Chapter 3
In many cases, of course, this choice might not be valid for recovery. If multiple domain
controllers for the domain are present and online, the loss of one domain controller can be
recovered by installing a new Windows Server 2003 system and promoting it to domain
controller. Normal replication with the other domain controllers will bring it up to snuff.
However, lack of another domain controller or changes that had not replicated to other domain
controllers might require the restoration of the failed domain controller’s database. In any course,
modifying the log location requires few steps. You will use the ntdsutil.exe command, a
command that is used to manage AD. It can be used to maintain the database, move the logs and
database, control single master operations, and remove metadata left behind by domain
controllers that are not cleanly removed or that fail during install.
To do so, take the database offline. Moving the database or its logs cannot be accomplished
while they are being used. To do so, shut down the domain controller. As it reboots, when the
Starting Windows progress bar appears, press the F8 key to start the server in directory services
restore mode. From the Advanced menu, select Directory Services Restore Mode. Use the
ntdsutil utility to move the logs. This command moves the logs and changes the registry to
reflect their location. To move the logs to drive D, type
At the ntdsutil prompt type
Then type
move logs d:\ntds
A new directory, ntds is made on the drive and the files are moved. View the new location by
Verify the integrity of the database by typing
Back up the system state. (This will backup AD.) If you do not perform a backup, the location of
the log files might not be retained. Finally, restart the computer.
If, instead of moving the log files, you want to move the directory database ntds.dit, use ntdsutil and
the files command, then enter
move DB to D:\directory
where directory represents the name of the directory on the D drive that you would like the database
to be.
Chapter 3
Q 3.6: What steps should I take to secure Active Directory?
A: Active Directory (AD) provides a security configuration assignment mechanism for the
forest. Authentication is controlled there, as are security settings (through Group Policy) for all
users and computers in each domain. Security for AD is set and maintained in a number of ways.
You should develop a comprehensive, formal security policy that is approved by management.
AD security practices can be divided into four areas: system configuration, including secure,
default settings on AD objects; administrative practice; physical security; and authentication and
System Configuration Including Access Control
System requirements for authentication and authorization ensure a secure directory environment
for the AD database. Users must authenticate in and have appropriate authorization to access and
modify AD objects. Network, as well as local, access must be authenticated. After this
authentication is accomplished, each access to an AD object is checked by comparing the
privileges and permissions granted to a user and the groups to which the user is a member with
the access control lists (ACLs) assigned to AD objects.
Like files and folders, AD objects can be assigned common access properties such as Read,
Write, and Delete. However, AD objects also have specific permission settings that are
applicable for the type of object they represent. User and computer accounts have a password
property, and each user automatically has the Change Password DACL on his or her account (see
Figure 3.17). The Reset Password property on all user accounts is set for Administrators, and can
be set for other groups or users.
Figure 3.17: Observing Group Policy permissions.
Chapter 3
Many AD objects are managed by assigning permissions that have far-reaching effects on the
security of AD and other resources within your forest. For example, setting permissions on
Group Policy Objects (GPOs) determines who can edit the GPO and the accounts to which the
policy applies. In addition, setting permissions on certificate templates determines which users
and computers are allowed to request that type of certificate. And permissions on DNS entries
determine which computer has the right to change the IP address listed.
GPO Permissions
Unlike simple access to the Security tab of a user’s properties page, security on GPOs must be
set by accessing the GPO through the property pages of the site, domain, or organizational unit
(OU) to which the policy is linked. To access a GPO’s properties, right-click the container, select
Properties, select the Group Policy page, select the GPO link, and click Properties. Select the
Security tab. To specify a security group or user who may modify this group policy link, assign
the group Full Control. To specify a security group or user to whom the GPO is applied, assign
the group Read and Apply Group Policy permissions, as Figure 3.18 shows.
Figure 3.18: Setting a GPO’s security settings.
Note that by default, the Authenticated Users group has the Read and Apply Group Policy
permissions on each GPO. Thus, any user account that is located within the container to which
the GPO is linked will have the policy applied. Should you want to filter policy application, you
can substitute the group or groups who should have the policy applied. Be sure to note that other
groups require permissions on the GPO.
Chapter 3
Certificate Template Permissions
Certificate template permissions are set on the certificate templates, which can be located in the
Certificates Template console. The Certificates Template console can be added to a Microsoft
Management Console. As Figure 3.19 shows, permissions include Enroll, which means that a
user can request and obtain a certificate; Autoenroll, which means an account may autoenroll;
Read, Write, and Full Control.
Figure 3.19: Certificate template permissions.
DNS Permissions
When DNS zones are stored in AD, and the zones are set to allow only secure dynamic updates,
permissions set on each resource record can control who is allowed to modify the IP address for
each record. To evaluate or modify the permission settings, open the DNS console, expand the
zone, right-click the resource record, and select Properties. Select the Security tab, and examine
the default settings. A wide view of the permissions can be examined by clicking Advanced (see
Figure 3.20). To modify the settings, use the Write Permission to identify who can modify the
resource record.
Chapter 3
Figure 3.20: Examining resource record permissions. Note that the computer batfish has full control over the
setting of its resource record.
Administrative Practice
Microsoft has prepared a best practices list for AD security. In Table 3.3, I’ve incorporated this
list into my best practices list and added comments.
Do not log on using your
administrative account. Instead
use a normal user account and
use the Run as utility to run
administrative tools.
Using an ordinary account mitigates the risk that inadvertent damage
is done either through accident, malicious activity, or the accidental
running of malicious code.
Physically secure computers in a
locked room.
Pay special attention to domain controllers at remote offices. Special
computer rooms are not often available and disregard for physical
security is often the rule.
Rename or disable the default
Administrator account.
If not disabled, do not use for ordinary administrative work. Each
administrator should have an administrative account for
Manage security relationship
between forests.
Simplify by using forest trusts where many trust relationships
between domains are necessary. Use external domain trusts to
isolate access from forest to forest.
Remove all users from the
Schema Admin group. Add a
user account only when changes
to the schema must be made.
An empty schema admin group can assist in making sure schema
changes are approved. Require approval before an account can be
placed in the group. That approval should only be granted after a
review of the required schema changes.
Chapter 3
Restrict user, group, and
computer access to shared
Shared resources include files, folders, printers, devices, data, and
programs that are made available to network users.
Do not disable the encryption of
AD traffic.
By default, all traffic on AD administrative tools is encrypted while in
transit. It is also signed. Although you can disable this feature via a
registry setting, don’t. Audit access to this key and ensure that it is
not changed.
Ensure that members of
administrative groups are trusted.
Administrative groups are Administrators, Domain Admins, Enterprise
Admins, Account Operators, Server Operators, Printer Operators,
and Backup Operators. Investigate potential and current members of
these groups. Only trustworthy users should be assigned
membership and their activity should still be audited.
Establish sites where geographic
locations exist that need
immediate access to changes to
the AD.
AD provides security management information. Establishing separate
sites ensures the resources to get the information there quickly.
For each site have at least one
domain controller and one Global
Catalog (GC) server
If sites must access this information from another site, there may be
delays in receiving and applying modified information.
Perform regular backups.
Need I say more?
For each domain, have at least
two domain controllers and one
GC server.
A single domain controller domain is a risky setup. If the domain
controller crashes, how long will it take you to restore from backup?
Having an extra domain controller can avoid outages while the other
is repaired.
Limit membership in
administrative groups.
Use delegation of authority to assign only the privileges to groups
that are need by their members.
Audit activity that affects critical
AD operations, changes to
administrative groups, and
security policy.
Auditing provides the accountability you require. You need to know
when and who are modifying key files, settings, and group
Maintain default settings on AD
objects unless study by
respected researchers proves
changes that tighten security.
Windows Server 2003 is a new OS. Microsoft has set the security
high on AD objects. Are they perfect? No. And I’m sure time will
suggest changes that may tighten security. However, it is unlikely that
the ordinary administrator has spent the time with Windows Server
2003 necessary to understand the permissions required for all
operations that need to work with AD objects. Modifying these
permissions can be a risky undertaking.
Table 3.3: Secure AD best practices.
Chapter 4
Chapter 4: Fulfilling the Promises of Group Policy
Q 4.1: My Windows XP system just asked me if I wanted to report an
error to Microsoft. What’s up with that?
A: Windows 2000 (Win2K) Group Policies improved the ability of Administrators to configure
security and manage users and computers. Windows Server 2003 and Windows XP include
considerable new functionality in this arena. One of the functions added is the ability to
automatically report system and application errors to a central place. By default, the location is
Microsoft (see the sidebar, “Pros and Cons of Software Reporting”). However, this function can
be turned off or configured so that errors are reported to a corporate file share.
Pros and Cons of Software Reporting
What software company wouldn’t want to know the types of errors that its software is generating? If the
company could keep and organize such records, the company could focus its efforts on those areas in
which the most errors occur. Corrections could be made to the software and delivered via a hotfix or in
the next release, and support would know the most common errors and could be prepped about how to
help customers fix the problem or at least work around it.
Think about the normal channels that an error report must travel. Typically, those willing to pay for
support get the most attention, and so they should. Large customers get better support than small, and
the masses rely on public newsgroups, word of mouth, and trial and error. But the masses collectively are
greater than the big customer, and automated error reporting is one way of collecting that information.
Knowing what is problematic to most folks is good marketing research. Providing feedback by providing
links to helpful articles is also good public relations and may even help some people.
In the real world, however, who wants extraneous communications between their client systems and the
outside world? Corporate IT can, however, put error reporting to their advantage by sending automatic
error messages to a corporate file share and restricting the type of error messages that are forwarded.
Unless they’re ready to deal with the results, I’d recommend disabling the error reporting service for
Error reporting is turned on by default in Windows XP. Those responsible for configuring new
systems will want to determine whether they want error reporting turned on, and set up machines
so that they fulfill their corporate policy not Microsoft’s. Then they can use Group Policy to
ensure that systems maintain these settings, and configure settings differently for different
machines as time goes on.
Error reporting can be configured in two places: from the Control Panel or through Group Policy.
The local security policy can be used on standalone systems, and Group Policy can be used to
control systems joined in domains. Remember, whenever a Group Policy setting conflicts with a
local setting, Group Policy will override local settings. In addition, when settings are made in
gpedit.msc, the Group Policy console for the local machine, these settings override any setting
made in Control Panel.
Ultimately, to assure error reporting does not occur at all, disable the error reporting service. You can
do so either through the Control Panel Services applet or Group Policy.
Chapter 4
From the User Perspective—Control Panel Error Reporting Settings
The intent of the error reporting service is to gather information when an error occurs, notify the
user, provide helpful links where more information can be found, and offer the user the ability to
report errors to Microsoft or to a corporate file share. Collected information could be used to
better understand the errors, and thus make the product better or determine a workaround or
corrective action. To the ordinary corporate user, however, these choices may be confusing. To
corporate IT, allowing the user a choice in this matter is not up for discussion—the options are
configured to meet the corporate policy requirements.
Error reporting is enabled by default in Windows XP and disabled by default in Windows Server 2003.
The default actions for Windows XP are
Errors are categorized as application or user-mode errors and system or kernel-mode
User-mode errors will cause the display of an alert with choices to Report this problem or
Don’t report this problem as well as the option to Click here for more information.
If a kernel mode or Stop error occurs, the Stop message is displayed and diagnostic
information is written to a memory dump file. When the system is restarted, the error
reporting service gathers information about the problem and prompts the user to report
the error.
By default, if the problem is reported, the report is sent to Microsoft. However, you can
configure it to be sent to a corporate file share.
When reviewing the settings in Control Panel, remember that Group Policy settings override the
Control Panel settings. If no Group Policy is configured, Control Panel settings apply. Control
Panel error reporting settings are located by clicking Error Reporting on the Advanced page of
the system properties. Figure 4.1 displays the choices. Error reporting can be enabled, or
disabled. If enabled, users may choose to report errors to a corporate file path. The default is to
send errors to Microsoft.
Figure 4.1: Error reporting settings in Control Panel.
Chapter 4
Controlling Error Reporting with Group Policy
Administrators will want to push the control of settings through Group Policy and, as is often
true, additional settings are available.
Windows XP systems in workgroups can be controlled via the gpedit.msc console on each system.
(To access, open the Run window, type
and click OK).
Frankly, I see very little benefit to reporting errors to Microsoft using the error reporting service.
Instead, I see a waste of corporate resources. Do you really want all 2000 Windows XP clients
sending notes to Microsoft? You may argue that your corporate firewall settings do not permit
this type of traffic, but do you really want all Windows XP clients making the attempt? Either
disable the error reporting service or use Group Policy to create appropriate settings for your
To manage error reporting settings with Group Policy, open a Group Policy Object (GPO—for
example, gpedit.msc on a Windows XP system), then open Computer
Configuration\Administrative Templates\System\Error Reporting\. Three items are available:
Display Error Notification, Report Errors, and a folder—Advanced Error Reporting settings.
Display Error Notification is a simple Not Configured, Disabled, Enabled setting. Report Errors
settings are described in Table 4.1. Settings made in the Advanced folder depend on the value of
settings in the first two. In addition, the result of each is dependent on the other. Table 4.1
describes the relationships.
Display Error
Report Errors
User is notified of errors
User is notified of errors and given opportunity to report
Not Configured or
User is not notified, errors are reported automatically
Not Configured
User can control through Control Panel
Not Configured
User can control notification from Control Panel, but not
error reporting
Not configured
User is not notified, cannot change setting in Control Panel;
error reporting may be configured from Control Panel
Table 4.1: Error reporting setting dependencies in Group Policy.
Controlling Error Reporting
If error reporting is enabled, the additional settings are available both from the Report Errors
Properties page, which Figure 4.2 shows, and from the Advanced Error Reporting Settings
folder. Table 4.2 explains the options available in Figure 4.2.
Chapter 4
Figure 4.2: Report errors properties.
Do not display
links to any
Microsoft ‘more
If this option isn’t selected, links to
Microsoft sites are included.
This feature might actually be very useful
for administrators, but might only serve to
confuse the average user.
Do not collect
additional files
If this option isn’t selected, when
certain errors occur, additional related
files (such as log files) might be
collected and sent as well.
The question becomes, as usual, what is
the benefit to the user? It might aide
Microsoft or corporate IT when files and
errors are sent to the corporate file share.
Do not collect
machine data
If this option isn’t selected, system
configuration, hardware information,
and other settings may be collected.
Useful information for the corporate
Force queue
mode for
application errors
When selected, errors are not reported
when they occur but instead are
queued. The next administrator to log
on will be prompted to send the errors.
On the one hand, should the error be
severe, the queue might not be available.
On the other, errors may be reviewed on
the system they occurred on instead of
blindly sending all information to a central
Previous Setting
This button is a toggle switch. When
you click it, you return to the settings
for the prior policy. The button then
reads Next Setting. When you click
Next Setting, you return to the policy
settings you just left.
Useful feature, although I wish it included
more history than just the prior policy
Table 4.2: Error Reporting Settings.
Chapter 4
Advanced Error Reporting Settings
If error reporting is enabled, the additional settings in the Computer
Configuration\Administrative Templates\System\Error Reporting\Advanced Error Reporting
settings provide even more control:
Default Application Error Reporting Setting—This setting lets you configure whether
general application errors are reported. A drop-down box allows toggling between Report
all application errors and Do not report application errors. Two check boxes below the
drop-down box allow you to choose to Report all errors in Microsoft applications or
Report all Windows component errors. If these check boxes are selected, the drop-down
box setting is ignored.
List of applications to always report errors for—If enabled, you can create a list of
applications that will always report errors. This setting is useful if you have a select
number of executable applications to track errors for. Instead of allowing reporting on all
applications, do not configure Default Application Error Reporting Setting; instead,
simply list the problem application in this setting. (If Default Application Error
Reporting Setting is set to Report all errors in Microsoft applications, any settings in this
list are ignored. In other words, all errors with any application are reported, not just the
ones in this list.)
List of applications to never report errors for—This option is the reverse of the previous
setting. If you have known error issues with a particular application and do not want to
continue to see its errors reported, list the application. Errors with other applications will
be reported.
Report Operating System Errors—If this option is enabled, the system will report OS
Report Unplanned Shutdown Events—If this option is enabled, the system will report
unplanned shutdown events.
Enable Report Unplanned Shutdown Events on all servers and make sure that reports are delivered
to the corporate file share, not to Microsoft. Reviewing information on the share provides an easy way
of documenting when servers went down. Many attacks require system shutdown, and servers do not
allow shutdown without logon. If an attacker is able to shutdown the system, the attacker may reboot
the server with an alternative OS and obtain sensitive information or files that would allow him or her
to crack passwords or other data offline.
Chapter 4
Q 4.2: How can I prevent users from running tools that they should
not run?
A: Although you didn’t mention which tools you don’t want users to run, I can think of
numerous tools that should not be used by most ordinary users, such as registry editing tools,
networking utilities, and resource kit utilities. There are three ways that you can prevent users
from running these tools:
Protect executable files by using file permissions
Remove executable files from users’ machines
Use Software Restriction Policies
Setting Restrictive File Permissions
Setting restrictive file permission is the time-honored way of restricting the use of files.
Recommended security practices include making sure that all drives on all Windows NT,
Windows 2000 (Win2K), Windows XP, and Windows Server 2003 computers are NTFS
formatted. When Windows is installed on NTFS drives, standard file permission settings on
system folders are fairly secure; the administrator’s responsibility is to lock down other folders
and files and consistently investigate, test, and deploy more restrictive settings on system files
and administrative tools. However, this method doesn’t prevent the savvy user from placing a
copy of a restricted tool in a folder in which the user has the right to run the program. And there
is also no guarantee that for every machine, every permission setting is correct.
You can write Group Policies that set file and folder permissions to a corporate standard, and
push these settings across an enterprise. However, a sophisticated user or an attacker has only to
provide their own copies of the restricted tools to foil these administrative tactics.
Removing Executables
Another sound practice is to remove the executables. There are two problems with this approach.
First, a user can still provide their own copy of a tool. Second, Windows File Protection (WFP)
might make it difficult to remove tools that are considered part of the OS and thus protected.
Another concern is that patches, system updates, and additional Windows components might
reinstall the removed executable without warning.
Using Software Restriction Policies
The ability to use Software Restriction Policies is new with Windows XP and Windows Server
2003. Software Restriction Policies offer a new way to prevent unauthorized use of system tools,
restrict users to only approved software, and prevent attackers from using system tools in an
attack on the system. Software Restriction Policies let you, the administrator, either create a
policy that disallows any software, then create unrestricted rules that let only approved software
run, or create a policy that lets all software run, then create disallowed rules that prevent
identified software from running. Software is either disallowed or unrestricted based on the
following rule types:
Chapter 4
Path—Explicitly identify the program path.
Hash—When a program is selected, a cryptographic hash is built. Any attempt to run the
program will result in a check of the hash, and the program will be allowed to run (or not
allowed to run) based on the type of policy. The program can reside anywhere, and the
action will be the same. This option is useful to prevent software from running no matter
the location.
Certificate—Rules are built based on the presence of a code publishers’ software signing
Internet zone—You can prevent software from running from a particular Internet
Explorer (IE) software zone. You cannot prevent software that has been downloaded
from that zone from running.
Enforcement properties include or exclude DLLs and identify whether the policy applies to
members of the Administrators group. Additional settings allow addition or deletion of file types
(designated file types) that can be managed and determine whether users, computer
administrators, or enterprise administrators are affected by trusted publishers. By default,
policies apply to all users and program files except library files such as DLLs.
Software Restriction Policies might not appear where you would expect them in a Resultant Set of
Policies (RSOP) report. When you run RSOP to determine the effective policy applied for a user, you
would expect Software Restriction Policies to appear in the location in which they are configured
(User Configuration, Windows Settings, Security Settings, Software Restrictions). However, Software
Restriction Policies might appear under Extra Registry Settings instead.
To create, examine, or manage local Software Restriction Policies:
1. Click Start, select Run, and type
in the Run text box.
2. Click OK or open the Administrative Tools, Local Security Policy console.
3. Select the Software Restriction Policies container.
4. If no policy exists, right-click the container, and select Create Software Restriction
To create or manage Software Restriction Polices for a site, domain, or organizational unit (OU),
open the Group Policy Object (GPO) for the appropriate container. The Software Restriction
Policy container is located under Computer Settings, Security Settings.
A Simple Policy to Restrict Tool Use
You can easily create a policy that restricts the use of tools. You will have to determine the list of
tools that need to be restricted and the type of rule that will be used. Unfortunately, you’ll have
to come up with your own list of tools, but I can help you understand how to make choices for
the type of Software Restriction rule to use, and provide you with a step-by-step policy-creation
Chapter 4
It is possible to create a Software Restriction Policy that can prevent systems from running.
Therefore, the best procedure to follow is to create a policy in the Local Security Policy of a single
Windows XP system. Then test the policy by applying it to a single OU that represents a test
computer or computers. When you are sure that this policy meets your requirements for software
restriction without breaking other software, you can use the policy to restrict multiple systems.
A good first policy will start with all software allowed to run and will contain rules that prevent
individual programs from running. This process will give you the opportunity to learn how the
policy works without taking as large a risk of making the system inoperable. The following
Local Security Policy example meets these requirements.
Again, always test Software Restriction Policies on a single machine first! It is possible to crash the
operating system (OS) by being overly restrictive.
Creating a Simple Software Restriction Policy
This example policy will prevent the following tools from running:
All software located in the C:\alpha geek tools folder
Regedit32.exe (no matter where it is located)
Software on sites included in the IE Restricted Sites security zone
Solitaire game (sol.exe—no matter where it is located)
Figure 4.3 shows the completed policy.
Figure 4.3: The Additional Rules section of a policy lists the policy type and basic information.
This policy should not restrict administrators, so the first step to take is to set the policy so that it
will only affect ordinary users:
1. Double-click the Enforcement object at the root of the Software Restriction Policy
2. In the resulting window, which Figure 4.4 shows, change the setting from the default by
selecting the All users except local administrators check box, then click OK.
Chapter 4
Figure 4.4: Be sure to change the policy from the default setting to let local administrators use the restricted
Next, a rule for each tool, folder, or certificate should be restricted:
1. Right click the Additional Rules container, and select Create new path rule.
2. Enter the path C:\alpha geek tools (or browse to select it).
3. Leave the security level at Disallowed, and click OK.
4. Right click the Additional Rules container, and select New Internet Zone Rule.
(Differences in options may exist due to different versions of beta software.)
5. Select the Internet zone Restricted Sites.
6. Leave the security level at Disallowed.
7. Change the description to comment that these sites are ones you do not trust, and click
8. Right-click the Additional Rules container, and select New Hash Rule.
9. Browse to a copy of the sol.exe file. The hash appears in the File Hash box, and
information about the file will appear in the File Information box. Leave the security
level at Disallowed, and click OK.
10. Repeat these steps, except browse to a copy of the regedt32.exe file in step 9.
Chapter 4
Testing the Policy
The first time you create a rule of a particular type, test the rule. You can do so by logging off
and logging on as an ordinary user, then attempting to run the tool. You should be refused and
receive the message that Figure 4.5 shows.
Figure 4.5: If a user attempts to run a restricted program, an error message will appear.
Next, log on as an administrator and attempt to run the tool. You should be able to. The
instructions I previously provided don’t include these testing instructions for brevity sake.
Finally, when the policy is complete, test all rules to ensure that they operate as you expect. Any
changes to the rules should require a retest.
Are these tests sufficient? You should always seek to write exhaustive tests for your policy. No one
list of testing scenarios will work for every rule set. Do not rely on these suggestions alone to work for
your policy.
To test this policy, make sure that you have designated in the Restricted Sites zone in IE a Web
site that has software that can be run from its Web pages. To test the policy that we created in
our example, log on as an ordinary user and attempt to run files in the alpha geek folder. Attempt
to play solitaire. Attempt to run regedt32. Copy the sol.exe file to a temporary folder. Attempt to
play solitaire. Open IE and navigate to the previously designated Web site. Attempt to run
software. All of these tests should fail. A pop-up message similar to the one that Figure 4.5
shows should be the result of each attempt. Next, try to download software from the restricted
Web site and run it. This attempt should be successful. The Software Restriction Internet zone
rule only applies to programs that are run from within the zone. Next, log on as Administrator,
and repeat the tests. You should be successful each time.
Examining the Policy for Holes
It might be possible, even desirable, to create multiple rules to handle some areas. For example,
if your policy seeks to absolutely prevent users from running certain tools, you should create
hash rules for each tool. Path rules, such as the one written for C:/alpha geek tools, will only
prevent the running of tools from within this folder and its subfolders. If the user can copy a tool
from the folder to another, that user can run the tool. If the user can obtain a copy of the tool
from another source, the user can run the tool. A hash rule, however, will prevent the software
from running from any location on the computer.
Chapter 4
The rationale behind path rules is twofold. First, it quickly blocks any new tool that is added to
the folder. This affords some protection while the Group Policy is adjusted and a hash rule is
written for the specific program. Second, if the Software Restriction Policy is written to disallow
all software, a large number of system programs must be allowed to run. Being able to do so by
selecting a folder versus creating individual rules for all system files is essential. Hash rules can
be used to specifically prevent some tools located within the system folder from running. Also, if
system files are being blocked, don’t forget to think about the copies that may be in dllcache.
If you are not using hash rules to prevent software from running, don’t forget to make a path rule that
includes %windir%\system32\dllcache. A copy of the disallowed program might be at this location,
and if a path rule does not cover it, the program will be able to run.
You should also be clear about which program file types are covered by your policies? When a
path rule is written, if a program file type is not covered, the program will be allowed to run. You
can examine which program file types are covered by opening the Designated File Types object
of the Software Restriction Policies container. From this window, you can also add and remove
file types.
Another policy hole consideration results from a program that calls another program that calls
another program—is this behavior restricted or allowed? The answer is not simple and there is
no blanket rule. If a program is disallowed, it cannot call other programs. If a program can run on
its own or is called from within another unrestricted program, the program will run. Conversely,
if an unrestricted program calls a disallowed program, the disallowed program will not run,
possibly resulting in the failure to run of the unrestricted program.
What will happen if multiple policies apply to the same programs? As the following list shows,
an order of precedence exists. The first element listed, hash rule, is highest in the order and will
take precedence:
1. Hash rule
2. Certificate rule
3. Path rule (if path rules conflict, the most restrictive will take precedence)
4. Internet zone rule
Finally, you should realize that later versions of a restricted program might not be restricted by
the rules you have written. A hash rule applied to a known virus file, for example, cannot restrict
a later version of the virus.
Chapter 4
Certificate Rules
Another type of software restriction rule is the certificate rule type. Certificate rules apply to
scripts and .MSI files only. To use them, a code-signing certificate is used to sign the files.
Certificate rules are used to identify the code-signing certificates that are valid on this computer
or on the computers within the Group Policy Container (GPC) of this GPO. Certificate rules are
an excellent way to ensure that only approved scripts can be run. They also solve the dilemma
caused by the following scenario: If all software is disallowed, rules might be written that let the
OS run. In addition, rules can be written that allow only the software a user needs to run. How
then, can logon scripts, new software installations, and maintenance scripts be allowed to run? If
a rule is written that indicates that certificate A is approved, any script or .MSI file that is signed
with certificate A will run. Those not signed by this certificate will not run.
Trusted Publishers
In a related area, Trusted Publishers Properties, which Figure 4.6 shows, should be configured to
determine who can select trusted publishers in IE. Trusted publishers can be designated within
the Content tab, Trusted Publishers section of IE. This designation lets software that is signed by
approved software publishers be run from IE. The default setting is to allow end users to select
trusted publishers.
Figure 4.6: The default rule for trusted publisher lets users select them.
Chapter 4
Moving On
Now that you can successfully create a small local software restriction policy, you might want to
design and execute domain-wide policies. Before you attempt to do so, you should be aware of
several considerations. First, be aware how very new this process is. Second, Windows Server
2003 has not been released. Third, you will need to develop sophisticated troubleshooting skills
and procedures and detailed testing plans before deploying widespread policies.
There is a lot more to software restriction policies than you first might believe. This area is new
and will take a while before all the bugs and best techniques are worked out. In the time it took
to write the first draft of this answer and do my first review, a bug was discovered in the
processing of rules that restrict 16-bit programs. The Microsoft article “Software Restriction
Policies Do Not Recognize 16-Bit Programs” at;EN-US;q319458 states that 16-bit software
that is run in the virtual machine (ntvdm.exe) is not recognized by software restriction policies.
Thus, the rule written to prevent the running of or edit.exe doesn’t work. Users
can run these programs even if the programs were specifically denied by software restriction
rules. Microsoft already has a fix to correct this problem. It can be obtained from Microsoft
support services. The company advises you to obtain and use the fix only if you are attempting to
restrict such software.
Win2K cannot process software restriction policies. You will have to wait for Windows Server
2003 and your migration to Windows Server 2003 domain controllers if you want to fully benefit
from these practices. You will only be able to impact users with Windows XP on the desktop.
Still, software restriction policies will be useful policies as you move forward.
Even simple software restriction policies can easily frustrate. A simple troubleshooting technique
is to allow the collection of processing into a log file. You can do so by adding a value to the
registry and entering the path and file name of the log. To do so, add the string value
LogFileName to the
registry key. For my test, I then entered the value C:\temp2\softstop.txt (see Figure 4.7), then ran
some tests. Files that I didn’t explicitly run showed up on the list.
Figure 4.7: You can troubleshoot software restriction rule problems by creating a log through registry edits.
Chapter 4
Q 4.3: What is a strong account policy, and how do I configure it in
Windows Server 2003?
A: An account policy is the recommended settings for the collection of controls that affect user
accounts and the ability for a user to authenticate to the system. Security professionals advocate a
strong account policy, one which makes it difficult for an intruder, because this policy sets the
standards for initial access into the system. Access controls are typically defined as file
permissions, dial-up permissions, and such. However, realistically, they include every control
that manages access in any form. The first control that users have to interface with is logging on.
If controls such as password policy and account policy are set correctly, many would-be
intruders would not be able to test the underlying resource-based access controls. Many groups
have proposed strong account and password policies for Windows, and it is amazing how closely
they agree. The settings in Tables 4.3 and 4.4 reflect this agreement.
Much confusion abounds around the terms authentication and authorization. Authorization is
concerned with determining who has the right to do something. Who can read the file, use the printer,
add users to the system, reset passwords. Authentication is the process used to determine whether
users (perhaps a user who is attempting to logon to a system) is who they say they are. So are the
logon process and its controls concerned with authorization or authentication? The answer is both: A
user is authorized to access the system by being given a user ID and password and the right to
logon. When the user attempts to use this right, the user must authenticate to the system—prove that
the user is who he or she says by providing credentials (the password) to the system. After the logon
process has completed, the level of the user’s access to the resources on the system and the user’s
rights to do things with the system and its resources are controlled by authorization.
password history
13 passwords
Setting password history encourages users to not reuse
passwords. This setting needs to be supported by Minimum
password age; otherwise, users will merely keep changing
their passwords to return to an old familiar one.
password age
42 days
Forcing a periodic change in passwords lessens the chance
that a password that has been guessed or cracked will be
used. If an attacker obtains a password after it has been
changed, the knowledge does the attacker no good.
Password Age
5 days
This setting supports Enforce password history. A minimum
password age of 0 would allow users to immediately change
their passwords—not a good idea, as they might return to their
original password.
Password Length
8 characters
There is some disagreement about the number of characters
that is best. The way the original LAN Manager password was
hashed, a 14-character password was no harder to crack than
two 7-character parts. A length longer than 7 characters gave
no protection. However, both the NTLMv2 and Kerberos
management of password hashing removes this shortcoming,
and in Windows Server 2003, the default interface can handle
more than 14 characters.
Password must
meet complexity
When this feature is enabled, passwords must consist of three
out of four recommendations: upper- and lower-case letters,
numbers, and keyboard special characters. Instruction also
needs to be given to assist users in composing strong
Chapter 4
passwords because this setting doesn’t prevent users from
including dictionary words in passwords or prevent users from
putting numbers at the end of the password and upper-case
letters at the beginning—prime locations for brute-force
password cracking programs to look.
Store password
using reversible
This setting should not be turned on. It is available to
accommodate non-Microsoft clients that do not understand the
Windows authentication process and so must be able to
decrypt passwords. This setting is also available at the user
account level and should be used there if necessary.
Account Lockout
30 minutes
The number of minutes a locked out account will stay locked
out. If this is set to 0, the account will have to be unlocked by
an administrator or someone who has been given the right to
do so.
Account lockout
5 invalid logons
The number of incorrect attempts at guessing a password that
can be made before the account is locked out.
Reset account
lockout counter
10 minutes
The number of minutes after which the count of invalid logon
attempts will be reset. If the number of minutes between one
invalid logon and another is greater than the number of
minutes to which this setting is configured, the previous invalid
logon attempts won’t matter.
Table 4.3: Windows Server 2003 password and account policy settings.
Understanding how these settings can affect security is important. For example, suppose, as
Figure 4.8 illustrates, Sally enters an incorrect password at 8:01, 8:02, and 8:03. The invalid
logon count increases by one each time and is at three when Sally is called into the boss’ office
and sits through a lecture. At 8:30, she again enters an incorrect password, however, because the
reset account lockout counter is set to only 10 minutes, the invalid logon count is only at 1. (At
8:32, she notices her password written on a note stuck to her monitor and successfully logs on.)
Chapter 4
Figure 4.8: An illustration of how the account-lockout counter reset time can affect security.
Two important factors are revealed in this figure. First, consider the effect that several of the
settings have on each other. This interactive effect is one you should seek as it tightens security.
For example, if you set Maximum password age, you will force users to change passwords at
least every 42 days. Setting Enforce password history, requires users to use unique passwords
each time they change their passwords—at least until the number of passwords remembered is
exceeded. Unfortunately, if you do not also set Minimum password age, your users can
immediately change passwords multiple times in a row until they have returned to their original
password. Set Minimum password age so that users will not be able to avoid using unique
passwords. Also be aware that not one of these settings—even though together they represent a
strong account and password policy—forces users to create strong passwords or prevents them
from writing down their passwords and attaching the note to their monitors, sharing them with
other users, or complaining to management when they have to get help to reset a password they
have forgotten. Table 4.4 defines recommendations for strong account-level settings.
Chapter 4
User must
password at next
Used when initial account is
activated or when there are
changes in password policy to
force password resets
This setting is enabled by default when a new
account is created, and may be turned off by an
User cannot
Select this setting for service
Recommended password policy settings require
users to change passwords; hence this setting
must not be selected for ordinary users. However,
service accounts should be manually periodically
reset. A forced change will shut down the service
as it has no way to respond to the request. If
someone should learn the password for the
service account and logon as the service account
and be able to change it, the service would no
longer function. Select this option for only service
Password never
Not selected for user accounts,
selected for service accounts
All users should be required to periodically change
their passwords. However, when a password
policy exists that requires them to do so, all service
accounts will need the Password never expires
policy selected. Passwords for service accounts
should be manually changed periodically; they
have no way to respond to an automated request
to do so.
Account is
Only select when you want to
disable an account
A good practice is to disable accounts when a user
leaves the company; doing so solves two
problems. First, you can immediately remove the
user’s access to systems while you remove the
user from membership in groups and thus access
to resources. Second, if a mistake is made or the
user is rehired shortly, you can easily reinstate the
user’s account. Another good practice is to create
accounts and leave them disabled if users have
not started working yet. Doing so lets you create
many accounts a few days in advance of user start
dates. Then you need only to enable the accounts
on the day that users begin work, avoiding the
delay that sometimes occurs when many users
start work on the same day.
Account is
locked out
This setting is unavailable and
can be activated only through
the account lockout policy
Administrator must clear this check box to reenable the account.
Store password
in reversible
encrypted form
Might be necessary if alternative
operating systems (OSs) are
used as workstations for users
with Windows Server 2003
Domain accounts only; passwords in Windows
Server 2003 are stored after being encrypted with
a one-way cryptographic encryption algorithm or
one-way hash. Thus, they cannot be decrypted.
Smart Card
Required for
When selected, a user must
present a valid smart card and
pin number (or other unique
piece of information) to logon
Smart cards must be implemented in the domain.
Account is
When a service application is
In Windows 2000 (Win2K), there is no way to limit
Chapter 4
trusted for
running under a user account,
this right lets the service
account impersonate the user
account to gain access to
the access given away by this right. If this box is
selected, an attacker could create code that would
utilize this setting to gain access. Windows Server
2003, however, has mechanisms in place to limit
the access granted.
Account is
sensitive and
cannot be
Use this setting to prevent the
delegation of this account
If this setting is selected, programmatic attempts at
delegating the account will be overridden.
encryption types
for this account.
Should be selected only if
required to allow users to
connect from OSs that require
Data Encryption Standard
The default encryption algorithms used are
stronger than the DES encryption types enabled
by this setting. Use this setting only if it is required
for interoperability with other OSs.
Do not require
Kerberos preauthentication
Win2K and Windows Server
2003 by default preauthenticate; use this setting if
interoperability with nonWindows Kerberos is required
Pre-authentication ensures that tickets are not
issued before authentication credentials are
checked. Pre-authentication is an optional part of
the Kerberos standard, and other implementations
may not require nor be able to interoperate with a
system that does.
Table 4.4: Windows Server 2003 account-level password and account policy settings.
You can find more information and resources at the following Web sites: The SANS Institute has
checklists available for purchase at; Microsoft checklists are available for
download at, and National Security Agency (NSA) checklists are
available for download from links at
Q. 4.4: How can I ensure that the proper system file and registry
permissions are maintained across all Windows Server 2003 servers
in my domain?
A: Although it may never be possible to guarantee that at any one moment in time all servers
have the correct permission settings on system files and registry keys, it is important to have a
strategy in place that can be used to periodically set them to your approved status. One way to do
so is by using Group Policy, another by manual application of a template via Security
Configuration and Analysis, and a third uses secedit in a batch file to apply on the file system
and/or registry nodes of a security template. None of these solutions is perfect. One or another
may be best for your circumstances. To make a choice, consider the impact of moving large
amounts of data through the infrastructure and the inefficiency of applying this same amount of
data during every Group Policy refresh. In addition, determine what you must do to ensure
reapplication of the proper permissions using other methods. Group Policy refresh is built-in to
Windows 2000 (Win2K); you will have to write, implement, and maintain any batch file or
custom application to manage the application in any other way. The first step for any of the three
options is to ensure that you have the best possible set of file and registry permission settings.
Chapter 4
Determining Appropriate Files and Registry Permission Settings
The default settings for the root of the system drive, root system files, and registry keys in
Windows Server 2003 is different than those established in previous builds of Windows. The
root of the system drive is C if the operating system (OS) has been installed on this drive. An
improvement is the application of default security permissions on the system drive. Table 4.5
identifies these settings. In previous versions of Windows, the default setting was Everyone Full
Apply To
Full Control
This folder, subfolders and files
Full Control
This folder, subfolders and files
Full Control
Subfolders and files only
Read and Execute
This folder, subfolders and files
Create Folders/Append Data
This folder and subfolders
Create Files/Write Data
Subfolders only
Read and Execute
This folder only
Table 4.5: Default system drive root permissions.
System files in the root of the drive either receive inherited permissions or are explicitly
permissioned. Inspecting the permissions on these files (many of which are displayed in Table
4.6) will help you understand the result of the default folder permissions on files placed in the
root as well as consider the reasoning behind the more restrictive permissions set. The wise
administrator doesn’t assume that the default permissions on system folders, files, and registry
keys are always going to be the best possible settings.
Boot.ini, NTDETECT.COM,ntldr
Administrators and SYSTEM
Full Control
Boot.ini, NTDETECT.COM,ntldr
Power Users
Read and Execute
Config.sys, autoexec.bat
Administrators and SYSTEM
Full Control
Config.sys, autoexec.bat
Power Users
Config.sys, autoexec.bat
Read and Execute
Administrators and SYSTEM
Full Control
Read and Execute
Table 4.6: Default drive root file permissions.
The installation of new software or the addition of services might add folders and files for which
permissions are automatically set or for which there is need to consider changes to the inherited
permissions. (When the Windows Server 2003 server is promoted to domain controller, an
additional set of permissions is applied.)
Chapter 4
To affect the settings that are applied at install, you can modify the defltsv.inf file in the
installation files folder. This inf file is used to apply file and folder permissions during
installation. After installation, to return the permissions settings to those applied at install time,
use the Security Configuration and Analysis console and select the setup security.inf security
template. (By default, security templates are stored at %systemroot%\security\templates.) To
reapply only the system drive root security settings apply the rootsec.inf security template. This
template can also be used to apply similar settings to the root of other disks. To reapply the
settings applied when a server is promoted to a domain controller, use the DC security.inf
security template. However, when reapplying default permissions using these templates, you
should realize that any configuration settings that you may have applied using templates, Group
Policy, or manually set will be overwritten if a default template setting exists. Instead of using
these default templates, make a copy of them after set up and maintain both copies with official
settings changes. A copy can either be made using Explorer or the Security Configuration and
Analysis console. In this way, you have a backup of the current security settings. And should you
need to return to the default settings, the original default template is available.
Using Group Policy to Maintain File and Registry Permission Settings
Group Policy in Windows Server 2003, like Group Policy in Win2K, allows administrators to
centrally configure and push security policy and other administrative settings to an entire site,
domain, or organizational unit—OU. Policies, officially named Group Policy Objects (GPOs),
are linked to these containers. It is rarely efficient or practical to implement site policies, so most
policies will be implemented at the domain or OU level. In addition to domain policies, a local
Group Policy is configured and can be adjusted on individual workstations or servers.
GPOs are only applied to the computer or users whose accounts exist within the container to
which they are linked. Thus, because all user and computer accounts for a domain are within the
domain container, all GPOs linked at the domain level are applied to all users and computers in
the domain unless otherwise filtered. OU policies are applied only to the user and computer
accounts that are within the OU.
File and registry permission settings are only configurable within the Computer Settings portion
of the Group Policy. When paths are added to the policy, the discretionary access control lists
(DACLs) applied to them are applied to the objects on the computer when the policy is applied.
Figure 4.9 illustrates a domain with several OUs.
Chapter 4
Figure 4.9: OU structure in the Active Directory Computers and Users snap-in.
Figure 4.10 shows more of its logical structure. In addition to a domain policy and a domain
controller policy, each OU has its own policy. In this example, multiple polices affect the
settings for Computer1 and users JohnC and CarolM. Each policy is applied during boot or
logon. First the local policy is applied, then the domain policy, then the OU1 policy. The policies
linked to OU2 and OU3 are not applied to the users and computers listed in OU1. Computer2,
whose account in is OU2, will receive its local policy, the domain policy, and the policy for
OU2. It will not receive the policy for OU1 or OU3.
Chapter 4
Figure 4.10: Logical OU diagram.
GPO application is cumulative. The settings applied in a GPO will be applied in addition to the
previous GPO settings unless there is a conflict. That is, if a setting is not configured in a
previous GPO, the new GPO’s setting will be applied. If the new GPO and the old GPO have a
conflicting setting, the conflict is resolved by applying the most recently applied GPO’s setting.
If the new GPO’s setting for a previously set configuration is not configured, the previous setting
will remain.
You can use Group Policy to maintain registry and file permission settings. The permissions can
be configured within the Security Policy part of a security template and imported into the GPO
or entered directly. Should permissions be set differently on a server, the correct settings will be
reapplied at the next policy refresh. (Computers’ policy is refreshed at boot and periodically if
policy has been changed.) The problem with using Group Policy is that the file and registry
permission settings increase the size of the GPO and are reapplied at each boot regardless of
whether thy have changed. So there is some inefficiency and performance loss. In a small
environment, this activity might not be an impediment; in a larger infrastructure that contains
multiple domains and many domain controllers, the size of the GPO adds to the replication
The portion of a GPO labeled Security Settings (and sometimes referred to as the Security Policy) is
refreshed periodically. By default, this setting is 16 hours plus a randomized offset. The entire GPO is
not refreshed unless changes have been made, unless requested using gpupdate or default settings
have been modified to do so. For information about how to modify this default setting, see the
Microsoft article “How to Delay Security Policies from Being Applied” (Q277543).
Chapter 4
Using Secedit to Maintain File and Registry Permission Settings
Alternatively, to maintain file and registry permission settings, you can use the command-line
tool secedit. Many of you are familiar with the Security and Analysis Configuration GUI, which
you can use to analyze or apply security settings. Secedit is the command-line version of this
tool. Like its GUI counterpart, secedit can be used to analyze the security settings on a server and
apply new security settings by utilizing a template. In addition, secedit can be used to apply a
single node from a security template. Thus, to re-apply your preferred file permissions, you can
use a single command-line command. To re-apply your preferred registry permissions, you can
use another line. Put both commands in a batch file or write a simple script, and you can re-apply
both file permissions and registry permissions across multiple servers. And you can use the
scheduling service to periodically refresh these settings without any replication burden.
The following example shows how to use a batch file and the scheduler to updates a server’s file and
folder permissions settings. If you want to update file permissions on more machines, you will need to
place the security template and batch file on those machines and schedule a task to run.
For the following example, the security template name is Base1. It is the result of copying the
setup security template and maintaining file and registry permissions settings. Before you can
refresh the settings, you must import the template into a database. The following statement will
do so for you
secedit /import /db base1.sdb /cfg base1.inf /overwrite
To refresh the file permissions settings on a server, use the following statement at the command
line, as Figure 4.11 shows
secedit /configure /db %windir%\security\database\base1.sdb
/areas FILESTORE /log base1.log
Figure 4.11: Using secedit to refresh the file permissions on a server.
Chapter 4
To refresh the registry permissions settings on a server, use the following statement at the
command line
secedit /configure /db %windir%\security\database\base1.sdb /cfg
base1.inf /areas REGKEYS /log base1.log
You can, of course, do both at the same time
secedit /configure /db %windir%\security\database\base1.sdb
/areas FILESTORE REGKEYS /log base1.log
And even import the database
secedit /configure /db %windir%\security\database\base1.sdb /cfg
%windir%\security\security\base1.inf /overwrite /areas FILESTORE
REGKEYS /log base1.log
When the command successfully completes, inspect the log file for confirmation (see Figure
Figure 4.12: The log file created by a successful application.
After testing the statements, you can schedule a periodic refresh by putting both commands (or
the combination line) in a batch file. Test the batch file. If successful, use the task scheduler or
schtasks.exe to schedule the refresh. The following example command line schedules a batch file
to run every Monday evening at 10PM under the authority of the system. Table 4.7 provides an
explanation of the switches; additional switches are available.
schtasks.exe /create /tn filepermit /tr base1config.bat /sc
weekly /d MON /ru SYSTEM
Chapter 4
Create a task
The name of the new task
The name of the batch rile or command to run
When to schedule the repetitive event (once, every n times a month, every month, every n times
a day, at this time every day, and so on)
Which day of the week; Monday is the default, so I could have left out this switch in the
example; /d * runs the process every day
Under whose authority; if a user account name is entered here (use the domainname\username
format), the password is entered using the /rp switch; to use a local computer account use the
\machine switch and \u and \p parameters (when the SYSTEM account is used, no password is
Table 4.7: The switches for schtasks.exe.
To provide a specific user account, use the /ru switch to enter the account name and the /rp
switch to enter the password. After the task is entered, you can query the task by using the query
Schtasks.exe /query /fo LIST /v
The /fo switch is used to specify the format of the output, and the /v switch reports the advanced
settings for each task. Figure 4.13 shows the results. (The user’s password is not displayed.)
Figure 4.13: Querying scheduled tasks.
Chapter 4
You can examine the same tasks in the GUI by selecting All Programs from the Start menu,
Accessories, System Tools, Scheduled Tasks. The GUI doesn’t display the user password either
(see Figure 4.14).
Figure 4.14: Querying scheduled tasks through the GUI.
The GUI has the advantage of showing the last time the task ran, as Figure 4.15 shows. You can
use both the command-line schtasks.exe tool and the GUI Scheduled Tasks, creating the tasks in
one and displaying or modifying the task in the other.
Chapter 4
Figure 4.15: Displaying the status of scheduled tasks.
Q 4.5: How can I prevent wireless access points from become an
unguarded entry point into my network?
A: Wireless access points (WAPs) can become back doors into your network; but properly
configured and managed, they can be safely used. Windows Server 2003 Group Policy provides
a tool that can assist in your security efforts.
Unrestricted proliferation of WAPs throughout your network can undermine many of your
security defenses. It will not be easy to control them. Unlike many technological advances,
WAPs have two things that make them immediate candidates for abuse. First, their price point is
low. For a few hundred dollars, you can purchase an access point and a wireless network card for
your PC or laptop. Many already have company-issued or came-with-the-laptop wireless
connectivity installed. Second, the technology is engaging, convenient, and easy to implement.
WAPs arrive preconfigured in some cases, and computer interfaces often automatically detect
their presence. A technically unsophisticated, ordinary user can purchase the box, stick it under
his or her desk, and cable it to the company LAN. With minimal to no help on the wireless LAN
card enabled laptop, the user can now roam around his or her cubicle and to adjacent areas
without the network cable tether.
It would certainly be nice if technology could step in and offer the ability to either prevent these
access points from being able to exist on your network or immediately detect them for you.
There is no way to do the former, nor easily the later. You currently cannot eliminate the
problem, but you can take steps to manage it:
Chapter 4
Have a strong written policy that specifies appropriate use of wireless networking and the
consequences of infractions.
Have a strong education element. Teach users how to use the corporate wireless LAN and
the problems rogue access points can cause.
Use technology to control and secure authorized wireless communications.
Adopt technology that seeks to manage and control wireless access.
You must implement the first two, and Wireless Access Policies in Windows Server 2003 Group
Policy can help with the last two.
Securing Wireless Communications
Wireless communications have come under fire for their weak data-encryption implementation
and lack of sound authentication mechanisms. Add to these shortcomings a cavalier
implementation, and you have the recipe for disaster. Although techniques for spying on
computer systems using specialized antennas, watching the blinking network access lights,
telescopically viewing computer monitors, and other techniques have been used in the past, these
techniques require some sophistication or clear line of sight to implement. Wireless networking
as now used requires neither.
For most, the threat to data exposure has been perceived as limited to penetration of limited
access points to the network. No access points, no threat. Limited access points with detection
and firewalling lessen the threat. Difficult to entirely prevent exposure, but if properly designed
and configured, an acceptable risk. However, wireless access to the corporate network exposes
internal communications to external entities. The outsider doesn’t have to physically connect to
the internal LAN, penetrate the corporate firewall, nor discover unprotected dial-up access. He or
she has only to sit within the range of the WAP (60 to 300 feet for most) and have his or her own
wireless networking card. A single, improperly configured WAP serves up the network to any
such passerby. Many properly configured WAPs are easily subject to penetration due to weak
encryption implementations and the existence of tools that purport to decrypt communications.
Several wireless 802.xx standards exist. Many of the differences in technology are not important to
security but can cause problems in implementation. Before adopting a standard, you will want to
consider these differences, but first consider the security facilities offered by the particular solution.
The information offered here is merely to help you differentiate between the currently available
802.11 1 or 2Mbps transmission, 2.4GHz band, using frequency hopping spread spectrum (FHSS) or
direct sequence spread spectrum encoding (DSSS) schemes
802.11a extends 802.11 to provide 54Mbps in the 5GHz band, uses orthogonal frequency division
encoding scheme; typical access areas extend up to 60 feet
802.11b Wi-Fi extends 802.11 to provide 11Mbps in the 2.4GHz band and using only DSSS; typical
access areas extend up to 300 feet
802.11g is an extension that provides 20+ Mbps in the 2.4GHz band
802.1x is currently a draft proposing authentication mechanisms for 802.11 wireless networks
Chapter 4
Four security implementation opportunities exist for wireless networking: do nothing, use
standard security options available for configuration on the access points, use standard security
options plus firewall the access point, add 802.1x authentication and improved technology.
Standard Security Options
Most commercially available WAPs include five purported security mechanisms. The following
bullet points briefly discuss each mechanism.
Encryption—The Wireless Encryption Protocol (WEP) can be switched on and will be
used to encrypt data transmitted across the wireless LAN. Although the implementation
has been demonstrated to be weak, it is nevertheless useful in thwarting casual
eavesdropping and many intentional penetration attempts. The determined attacker will
persevere. I recommend turning on encryption.
SSID—The SSID is merely an identification mechanism and is not a security device.
Many systems broadcast the SSID and many wireless connectivity applications
automatically detect the SSID or all nearby wireless networks. For those that are not
automatically broadcast, keeping such a secret is next to impossible. However, you can
modify from the default. Most WAPs have a default SSID. These are not secret, and
attackers will try these default SSIDs.
Turn off broadcast—Broadcasting the availability and SSID of a WAP is helpful to
network users. Unfortunately, it is also helpful to intruders. Preconfigure authorized
systems to use authorized access points and turn off broadcasting. Yes, security through
obscurity is not particularly good security, but it does limit exposure.
Use MAC addresses for authentication—By limiting access to approved MAC addresses,
you prevent most unauthorized computers from connecting. Take note, because the
authentication is based on the network card address, possession of the computer or the
card provides access. In addition, MAC addresses can be spoofed, so this plan isn’t
Insist on direct connection for administration—Allowing wireless access for
administration of the access point opens security configuration to anyone within range of
the system. By configuring the system to require physical connection, you’ve limited this
exposure. Some systems can require direct serial connection, while others require
Ethernet cabling directly to the box.
Although these security mechanisms have their shortcomings, they at least provide some
measure of security.
Chapter 4
Standard Security Options Plus Fire walling
Placing a WAP on the internal side of the corporate firewall is not firewalling the access point.
Wireless connectivity does not go through the firewall. However, you can firewall the WAP by
placing a firewall or remote access server between the WAP and the rest of your network. You
can then require virtual private network (VPN) connectivity to the internal LAN, or at the very
least, authentication to the remote access server. No internal network resources can be accessed
until this authentication is accomplished. Figure 4.16 illustrates this technique. In the figure, the
WAP is connected to the external card of a remote access server. Although it is possible to obtain
connection to the WAP, connectivity to any internal resource can only be acquired if connection
to the remote access server is successful. Additional restrictions such as port filtering or the
addition of an actual firewall is also possible.
Figure 4.16: Setting up a firewall for wireless clients.
Add 802.1x Technology
802.1x is currently a draft standard. In an 802.1x network, a network access server (NAS)
requires authentication before allowing access to the network. The standard uses RADIUS as the
mechanism for providing authentication. Current implementations include Windows Server 2003
and use certificates (either smart card based user/computer certificates or local certificates on the
client computer). In essence, 802.1x places the responsibility for firewalling the access point on
the access point itself.
The standard also describes approved authentication protocols and the implementation of
approved data encryption processes that address the weaknesses of WEP. Two choices for
authentication are Extensible Authentication Protocol (EAP) and Protected Extensible
Authentication Protocol (PEAP). Windows Server 2003 provides support for both.
Chapter 4
EAP is described in Request for Comments (RFC) 2284. It was designed to support multiple
authentication methods including smart cards, Kerberos, public key, one-time passwords, and
other methodologies not yet in existence. The goal of EAP was to offer the ability to provide
different authentication methods without having to re-program the NAS. The NAS, which sits
between the clients and a back-end authentication server, can simply act as a pass-through and
does not need to understand multiple authentication methods or even specific implementations of
them. The NAS simply needs to understand EAP, then let the client and the authentication server
do the work. The original specification was developed for use with remote access servers such as
RADIUS, with which clients typically connected to the network through dial-up or Internet
EAPOL, or extensible authentication over LANs, is the adoption of this protocol to wireless
network interfaces to traditional LANs. EAPOL is diagrammed in Figure 4.17.
Figure 4.17: Steps in EAPOL.
As Figure 4.17 shows, the NAS, a switch (or, in our case, WAP) provides a point of entry for the
user. The switch detects a client and sends the EAPOL Request-ID message to the client. The
client responds with an EAPOL Response-ID that includes authentication information. The NAS
encapsulates the Response-ID in a remote authentication dial-in user service request packet and
forwards it to a RADIUS server. (The NAS acts as a relay of messages from the client using
EAPOL and to the RADIUS server using RADIUS packets.) The RADIUS server responds with
accept or deny packets that include encapsulated EAP success or failure packets. (RADIUS on a
Windows Server 2003 network will use Active Directory—AD). The access server forwards to
the client. If authentication is successful, the port on the access server is open and the user
PEAP is essentially EAP wrapped in Transport Layer Security (TLS—a technology similar to
SSL). Additional modifications also support improved security. In fact, it is being developed to
address weaknesses in the EAP standard. Three improvements exist:
Chapter 4
Because EAP is wrapped in TLS, the EAP session between the back-end authentication
server and the client is encrypted and the integrity is protected in a TLS channel. Mutual
authentication between the back-end sever and the EAP client is required. EAP did not
require mutual authentication and was felt to expose too much information about the
process—information that would make it easier for an intruder to mount an attack. Now,
no EAP conversation occurs until the TLS session is established and all EAP
communication is encrypted.
TLS provides built-in support session resumption and management of fragmentation and
reassembly—two networking issues with EAP. Because EAP doesn’t include these
capabilities, each authentication method has to provide them, thus resulting in a
duplication of effort as well as an additional exposure to denial of service or
vulnerabilities due to poor code.
TLS provides support for key exchange and the development of key hierarchy for the
generation of authentication and encryption keys. To work with EAP, each authentication
method had to do so. These techniques are complex and difficult to get correct. Requiring
each implementer and authentication method provides too many opportunities for poor
mechanisms and increased vulnerability.
Windows Server 2003 Wireless Network (IEEE 802.11) Policies
Windows Server 2003 Group Policy provides an opportunity to centrally control configuration of
authorized wireless networks. Although it does not and cannot prevent the existence of
unauthorized WAPs, use of a policy provides more than and administrative convenience. First,
the policy provides a mechanism to present a list of preferred WAPs. The client will seek to
connect to these access points first, in the order listed. A user would have to specifically
configure his or her system to attempt connection to other systems. For most people, transparent
connectivity is desired. The ordinary user just wants to be able to do his or her job, not figure out
how to connect to the network. If there is no benefit to independently configuring their systems
(users have wireless connectivity that they don’t have to mess with), they won’t. The determined
individual will always find a way around policy. Second, although the attacker will be perfectly
capable of configuring his or her computer, the policies that control authorized access points add
technology to reduce that threat. By using Group Policy to set them, you can avoid the possibility
that misconfiguration will produce a vulnerability.
Wireless policy can be set in the Computer Settings, Windows Settings, Security settings,
Wireless Network Access Policy. First, create the wireless policy. In the GPO, right-click
Wireless Network (IEEE 80.11) Policies, and select Create wireless network policy. Click Next
on the welcome page, then enter a name and description for the policy, and click Next. Click
Finish to complete the policy wizard and proceed to editing the policy settings. On the general
properties page, the default is to Use windows to configure wireless settings for clients (see
Figure 4.18), though you can select the Automatically connect to non-preferred networks.
Important to consider are the choices that require client connections to either:
Any available network (access point preferred)
Access point (infrastructure networks) only
Computer–to-computer (ad-hoc networks only)
Chapter 4
You allow ad-hoc as well as infrastructure networks with the first choice; otherwise, set
restrictions. You might need different policies if you allow a select group of users access to more
than one kind of wireless network. Remember that you can create different policies and
implement them at either the domain or OU level. What you cannot do is create multiple polices
in a single Group Policy Object (GPO) and assign them to specific users or computers.
Figure 4.18: Identify the policy and the type of wireless network authorized.
The Preferred Networks tab, which Figure 4.19 shows, is used to identify configuration for each
authorized access point. For each, click Add, then add the network information.
Figure 4.19: Identify and add network information.
Chapter 4
On the Network Properties tab (see Figure 4.20), enter the network name, or SSID, and a
Figure 4.20: Configure WEP.
Choose the WEP key and authentication modes, or ad-hoc designation if appropriate. If IEEE
802.1x is supported, use the IEEE 802.1x tab (see Figure 4.21). Your first choice is to select
between the use of EAP or PEAP.
Figure 4.21: Configure 802.1x.
Chapter 4
Use the Settings button to configure authentication behavior. You can select whether smart card
or computer resident certificates are required, and identify which CA(s) are to be trusted. If a
Microsoft Enterprise CA is online, it will appear as on option (see Figure 4.22).
Figure 4.22: Select smart card or computer certificate and identify Trusted Root Certification Authorities.
Q 4.6: I want a kiosk on the shop floor to have the same user settings
no matter who logs on. What can I do?
A: Sometimes it is necessary to severely control machines that will operate in public places. The
systems are placed there for specific purposes, not for general use. Typical uses for kiosks are in
malls, plant floors, and public Internet access systems. In these cases, most users who might step
up to the system either use the auto-logged-on user account, which has minimal system access
permissions. However, it is possible for such not to be the case; for example, in libraries and
computer labs in which each user has an account. In addition, autologon can be bypassed by
holding down the Shift key during startup.
In any of these scenarios, it is always possible that a user with elevated privileges on the network
might log on to the kiosk, plant floor, library, or lab computer. In this case, the best policy to
follow is the one you request—ensure that the user’s access to the system from this machine is
no different than that of the restricted users. Fortunately, this setup is easily accomplished by
using Group Policy and the loopback processing mode.
Chapter 4
How Loopback Processing Mode Works
In normal processing mode, Group Policy is applied at the Local, Site, Domain, and
organizational unit (OU) level. Settings are merged except when they represent conflicts, in
which case the most recently applied settings wins. Computer settings are applied separately
from user settings and are the result of settings in Group Policy Objects (GPOs) that are linked to
containers within which user and computer accounts exist.
In the typical setting in which loopback processing is required, the computer to be used and most
user accounts that may access the systems may reside in the same OU. Settings for computers
and users can be strictly set and maintained. However, users with accounts in other OUs will
receive the settings made in the policies linked to that OU. This action is not what we want. If
loopback processing mode is set, after this user’s typical user properties are applied, the local
user settings for the Group Policy within which the computer account resides are reapplied. The
user’s configuration settings now reflect this policy. Two versions of loopback processing mode
Loopback with merge—User configuration is composed of settings from both the user’s
usual list and that of the user settings in the GPO that is applied to the computer. In the
case of conflict, the computer/user settings win.
Loopback with replace—The user configuration is replaced in entirety by the GPO list
user settings for the computer. Some organizations use the loopback with replace because
they want to secure the computer in the same manner for all users.
Understanding loopback processing, although simple in principal, is not all that easy. Figure 4.23
illustrates the concept. In the figure, two scenarios are simply represented. In one, the GPO for
the plant OU specifies many user and computer configurations which lock down access to the
system as well as the network. The GPO is applied to all computer and user accounts in the OU.
Jasper Johnson (JasperJ) has an account at the in the user’s container. The GPO in the Plant OU
does not ordinarily apply to him. For lack of a more visible illustration, we’ll pretend one
characteristic of the GPO is red wallpaper. In the A scenario, loopback processing has not been
applied. When users with accounts in the Plant OU log on, the computer receives red wallpaper.
When Jasper logs on, he does not. Instead, he gets the default blue background and can modify
the wallpaper as he wishes. In the B scenario, loopback processing with replace has been applied.
Users accounts in the Plant OU receive the red wallpaper. This time, Jasper does as well.
No matter how many configuration settings are applied in the Plant OU, all of them will be
applied to Jasper’s account if he should log on to a computer with its account in the Plant OU.
When Jasper returns to his desktop computer, one that is not in the Plant OU, he receives the
settings configured for his account, not the Plant OU GPO settings.
Chapter 4
Figure 4.23: Illustration of loopback processing.
Configuring Loopback Processing Mode
Configuring loopback processing is simple: Determine the appropriate restrictive setting for
computer and user accounts in the Plant OU. set them in the GPO, and test. Have Jasper log on to
see that the settings do not apply to him. Open the GPO, and navigate to Computer
Configuration, Administrative Templates, System, Group Policy. Double-click User Group
Policy loopback processing mode, click Enable, select the mode using the Mode drop-down box
(see Figure 4.24). Click OK to complete the changes.
Figure 4.24: Configuring policy loopback processing mode.
Chapter 5
Chapter 5: Administrative Authority
Q 5.1: How do I prevent unauthorized use or abuse of the local
Administrator account?
A: When either Windows Server 2003 or Windows XP Professional is joined in a domain, the
local Administrator account and local Administrators group is still present. In fact, it is the
Domain Admins membership in the local Administrators group that allows members of Domain
Admins to administer the local system. But, additional accounts, both local and global, can be
added to the local Administrators group, and the local Administrator account cannot be deleted.
A discussion about preventing unauthorized use or abuse of the Administrator’s account should
also consider protecting and limiting administrative authority of any kind on these machines.
In Windows NT 4.0, you could prevent abuse by using strict procedural guidelines that advised
Do not add (or severely restrict the addition of) additional domain accounts to the local
Administrator group.
Do not add local accounts to the local Administrators group.
Require a strong password for the local Administrator account.
Require a strong local account policy for all member servers and workstations.
Require a strong password policy for all member servers and workstations.
Use domain accounts to administer local systems.
Rename the Administrator account.
Restrict anonymous access.
Physically secure the computer.
Windows 2000 (Win2K) includes additional controls (Restricted Groups, the ability to make
administrative security settings in a GUI, and the ability to use Group Policy to push security
settings from a central location). Windows Server 2003 and Windows XP include new features
that enhance those of NT and Win2K and support good procedural decisions by providing
additional software controls. Many of these Win2K, Windows XP, and Windows Server 2003
controls can be enforced through Group Policy (under Local Policies\Security Options or by
using Restricted Groups) and are detailed in the following sections. Remember that software
controls alone can never enforce security and may come at the price of administrative
convenience. If you decide to use additional controls, regardless of their origin in NT, Win2K,
Windows XP, or Windows Server 2003, you should thoroughly investigate their impact and test
them in your own environment before widespread deployment.
Chapter 5
Disable the Administrator Account for Windows Server 2003 and Windows XP
This security option (only for Windows Server 2003 and Windows XP) lets you disable the local
Administrator account. Because members of the Domain Admins group have administrative
authority on computers joined in their domain, you still maintain the ability to administer the
system. Using this option prevents the possibility that an intruder will obtain the Administrator
password and thus control of this system. Selecting this feature, however, can have some
interesting affects. Table 5.1 describes areas that may cause problems.
I need to make some changes
and normally would boot into
safe mode to do so.
The Administrators account is disabled
and is normally used in safe mode.
Not a problem, the
Administrators account will
always be enabled in safe
I changed the password
policy after disabling the
Administrator account.
If the Administrator’s account does not
meet the new policy, you will not be
able to re-enable the account.
Another administrator must log
on and reset the Administrator
account password.
The secure channel between
the workstation and the
domain controller has failed.
There are no other local Administrator
accounts. You cannot make the
changes necessary to correct the
Reboot to safe mode and fix
the problem.
Table 5.1: Potential problems with disabling the local Administrator account.
Limit Local Account Use of Blank Passwords to Console-Logon Only
Admittedly, the password policy should prevent the use of blank passwords entirely. However,
you should recall that someone who has the password to the local Administrator’s account (or
other account with membership in the local Administrators group) could modify the local
account and password policy to permit blank passwords and modify and account to use one.
When the use of blank passwords is limited to console logon only (an option for only Windows
XP and Windows Server 2003 systems), an account with a blank password cannot be used for
network logon. The user must sit at the Windows XP or Windows Server 2003 system on which
the account exists. You have effectively prevented an intruder from using the local Administrator
account (or any other privileged account) to access files, folders, registry keys, and so on, on this
machine. This configuration also prevents applications such as FTP, Telnet, and terminal
services from using an account with a blank password. However, Microsoft advises that
applications requiring remote access could be written to bypass this setting.
Rename Administrator Account
Everyone knows that security through obscurity doesn’t work, right? Wrong. Well, if obscurity is
your only defense, of course it doesn’t work. However, making things more difficult for
attackers is a useful practice. Because everyone knows that an account exists called
Administrator, attackers have half of the information they need to obtain administrative-level
access to the system. Changing the name of the local Administrator’s account adds an effective
barrier. This security option works for Win2K, Windows XP, and Windows Server 2003.
Admittedly, there are ways to discover which account is the local Administrator’s account, but
there are also ways to make that harder, as I discuss in the next section.
Chapter 5
Allow Anonymous SID and Name Translation
If this setting is enabled (and it is enabled by default on Windows XP and Windows Server 2003
servers), an anonymous request for the name of the account associated with the SID belonging to
the local Administrator account will be answered, providing the account name. Because wellknown SIDs (SID numbers always assigned to certain accounts) are easy to look up, leaving this
setting enabled provides attackers with a way to determine to what you changed your
Administrator’s account. If you disable this setting (and it is disabled by default on
workstations), an anonymous request for this information will be denied.
This setting must be the same for all domain-level accounts and is made in the Default Domain
Group Policy. Local account settings can be different and can be set by changing this security
option within a group policy linked to the specific organizational unit within which the machine
account resides.
An additional security option setting, which I detail in the following section Do not allow
anonymous enumeration of SAM accounts can also be used to obscure information about the
domain. However, it does have implications for trusts.
Do Not Allow Anonymous Enumeration of SAM Accounts
This Windows XP and Windows Server 2003 security option prevents anonymous access to a
listing of Security Accounts Manager (SAM) accounts. (A similar setting is available in Win2K.)
Preventing knowledge of system accounts makes attacking harder for an attacker. Account
names are half of the information necessary to assume the access level of an authorized user.
There are two considerations when using the setting. One consideration concerns the settings
usefulness in an organization that uses naming conventions for user accounts. If an attacker
knows or can deduce this convention, the attacker can easily guess the correct account name for
any employee. For example, if user accounts in my company are always formed from the first
two letters of the first name and the first three letters of a last name, knowing an employee’s
name is the same as knowing the account name. An attacker developing a directed attack will
have no problem finding the name of employees for whose account the attacker wants to attack.
However, many attacks rely on readily available system information. Knowing the naming
convention and learning employee names require additional steps. Anytime you can slow down,
frustrate, or turn away an attack is good.
However, making sure that this setting is invoked may cause other problems. Some functions
require the ability to anonymously list accounts. Think, for example, of how an administrator in a
trusting domain is able to access the account list of the trusted domain. A trust does not provide
automatic privileges in the trusted domain. The administrators of the trusting domain do not
authenticate to the trusted domain. The only mechanism by which they can obtain the user
account list (and thus provide the trusted domain users access to resources in the trusting
domain) is to access the account list anonymously.
Chapter 5
If you chose to prevent anonymous access to a listing of the SAM accounts, Windows Server 2003
provides you with a workaround. When the trusting domain administrator is assigning access to
resources in his or her domain to trusted domain users, Windows Server 2003 prompts for an
account and password for the trusted domain. If the administrator in the trusted domain has provided
the trusting domain administrators with an ordinary user’s account in the trusted domain, the
administrator will be able to successfully assign the trusted domain user accounts access to
resources in the trusting domain. Now the trusting domain’s administrator becomes an authenticated
user in the trusted domain, not an anonymous user, and thus has the access level needed. You must
make the decision about which option provides the greater risk—giving a domain administrator in a
trusting domain ordinary user-level access to the trusted domain or allowing anonymous listing of
domain accounts.
Define Restricted Groups
The ability to define Restricted Groups is only available in a Win2K or Windows Server 2003
domain using Group Policy. Defining a group as restricted allows administrative control over the
membership of local groups. Normally, membership in groups is a function of the local
Administrators group. A problem arises because a local administrator may create new local
groups and add them, as well as existing accounts, into the local Administrators group. Limiting
and carefully evaluation of the membership in privileged groups is a necessary function but is
hard to do. In addition, an attacker, knowing that the local Administrator account may be
watched, will often add a new user account and place that account in the local Administrator’s
group for future use.
By making the local Administrators group a restricted group, this problem can be lessened.
Although anyone with local administrative rights on the local system can add an account to the
Administrators group in the local SAM, if the account is not also in the membership list of the
Administrators group in the Restricted Groups Group Policy setting, the account will be removed
at policy refresh.
Be careful when using this feature. In the typical implementation, Restricted Groups is implemented
at the organizational unit (OU) level by adding the Administrators group to the Restricted Groups part
of a GPO. The name of the group should be typed in; otherwise, the potential exists for limiting the
group affected to the local Administrators group on the current system.
To increase the effectiveness of this control, audit for security policy changes. The addition of a
new user to the Administrators Group will create a record in the Security event log. If you are
monitoring the log for records of this type, you will have advanced warning that an intrusion
may be occurring.
Don’t define any group without placing authorized members in it. Doing so will remove every member
from the group. If the Administrators group is added to Restricted Groups and no members are
added, even the Administrator account will be removed and the administrator will not be able to log
on. If you define the Default Domain Controllers Group Policy without placing authorized members in
it, you have removed the ability of the Domain Administrator to log on to the domain.
Chapter 5
Restrict Users to the Explicitly Permitted List of Snap-Ins
To prevent local administration of a system, you can disallow the administrative tools that users
can load into the Microsoft Management Console (MMC). Setting this Group Policy setting
(User Configuration\Administrative Templates\Windows Components\Microsoft Management
Console) denies access to all snap-ins. Next, you must configure access in the
Permitted/Restricted Snapins folder at the same location for those snap-ins you want to be
available. Conversely, you could leave this setting not configured and restrict access by disabling
access to specific snap-ins within the Permitted/Restricted Snapins folder. Restricted snap-ins
will not appear in the Add/Remove Snap-in list. Users who open consoles that contain the
restricted snap-ins will see the snap-in as grayed out and they will be inaccessible.
Command-line utilities and tools that do no load in an MMC console are not affected by this setting. A
sophisticated attacker will not be foiled.
Q 5.2: I seem to have locked out the Administrator account in the
domain. I can no longer log on to the domain using this account.
What should I do?
A: You probably have introduced an empty Restricted Groups policy for the Administrators
group at the domain controller Group Policy Object (GPO) level. You will need to add the
Administrator account to this policy.
Windows 2000 (Win2K) introduced the concept of Restricted Groups and it is present in the
same form in Windows Server 2003. This Group Policy was developed to allow domain
administrators to control the membership of local groups on computers within an organizational
unit (OU) or within the domain. Let me explain further.
Each Win2K, Windows XP, and Windows Server 2003 computer has a local Administrators
group and a local Security Accounts Manager (SAM) database of accounts even if the computer
has been joined in a domain. As you know, account membership in the local Administrators
group gives broad powers on the local machine. This access is a very good reason for restricting
membership in this group to only those individuals who require such power. Unfortunately, it is
difficult to restrict those who are given membership in the Administrators group from adding
other members. It is also an attack technique to add users to administrative groups after
successfully obtaining administrative access. The attackers can then use those user accounts in
the future.
However, if a group is added to the Restricted Groups policy, and users are added to this group,
only these group members will be allowed. If members are added to the group on the local
machine, when the policy is refreshed, they will be removed. I’ve illustrated this confusing
concept in the following example scenario:
Chapter 5
Sally’s account is given membership in the Administrator’s group of her Windows XP machine.
A Group Policy exists for the OU in which Sally’s computer account resides. The
Administrator’s group is added to the Restricted Groups policy in this Group Policy. Sally’s
account is added to the Administrators group within the policy. Sally is tricked into adding
Tom’s account to the local Administrators group on her computer. Tom has no domain
administrative privileges. During policy refresh, the discrepancy is found. Tom’s account is not
in the Restricted Groups Administrators group. Tom’s account is removed from the local
Administrators group on Sally’s computer. That afternoon, Tom attempts to remotely edit the
registry on Sally’s’ machine to play a trick on her. He cannot do so. At the end of the week, John
reviews the audit logs on Sally’s machine and finds the records in which Sally added Tom to the
Administrators group and Tom attempted to remotely access the registry. Tom and Sally are in a
little bit of trouble.
You can user Restricted Groups to manage membership in any group, whether it is default or
created. However, problems might be caused by people who do not read instructions or because
it is easy to select the default groups that exist on the domain controller instead of the desired
groups on the local machines. Because many people do not study the documentation and insist
on trying configuration on production machines without proper testing, it is possible to prevent
authorized individuals from doing their administrative job, and indeed, it is possible to lock out
the domain Administrator account. It happens because two steps must be taken to create a proper
policy. First, the group must be added to the Restricted Groups policy. Second, authorized
members must be added to the group. Any authorized member that is not added to the group
inside the Restricted Groups policy will be removed from the group. The two-step process is not
intuitive and doesn’t produce a warning if not carried out properly. The administrator or
consultant who likes to break things to learn about them will be rewarded here.
What happens if an Administrator for a child domain removes the Enterprise Admins group from the
local Administrators group in his or her domain? Members of the Enterprise Admins group have
limited access to child domains. (To totally prevent the Enterprise Admins group from having any
access in a child domain requires a little bit more work.) Can the Enterprise Admins get their access
back? Yes. They can do so by creating a SITE policy that adds the Administrator group of the child
domain, then adds the Enterprise Admins group to the Administrators group in the policy. At the next
policy refresh, the Enterprise Admins will have access to the child domain.
Unfortunately, it is also possible for the careful reader of documentation to create a Restricted
Groups policy with unexpected results. For example, suppose your domain,
east.newyork.mpptp.local, is a Win2K domain and all your clients are Windows XP. You want
to create a policy to restrict membership in the local Administrators group of all Windows XP
computers. To do so, you open the Domain Security Policy, right-click Restricted Groups, click
Add Group, click Browse, select Administrators, and click OK. Because this policy is for the
Windows XP computers and you do not want the default Administrator account to be part of this
group, you do not add any members. You close the Default Security Policy.
Chapter 5
Sound correct? Yes, except for one thing. Because the domain policy will be applied to every
domain computer, it is also applied to the domain controllers. Browsing in the Add User
windows located in the domain Administrators group, you will find that the Administrator
account cannot log on to the domain. To correct this situation, an Enterprise Admin can logon
from another domain and open Active Directory Users and Computers. By changing the focus of
the console to the east.newyork.mpptp.local domain, the Enterprise Admin can edit the
Restricted Groups policy to correct the situation. To do so, the Enterprise Admin member needs
to remove the domain\Administrators group from the Restricted Groups policy, then add a group
by typing
This policy will then apply to the local Administrators group on the computers in the domain
instead of the built-in Administrators group on the domain controllers.
Q 5.3: How can I give administrative abilities to my Help desk staff
without making them full administrators?
A: In Windows Server 2003, as in Windows 2000 (Win2K), delegation of administrative
authority is accomplished by modifying permissions on Active Directory (AD) objects. In this
manner, ordinary users can be given the ability to manage computers and users without giving
them more rights than they need. The appropriate way to accomplish this task is to:
Create organization units (OUs) that contain the user and computer accounts over which
delegated administrative authority is to be granted.
Create a group whose members are to be given the right to administer user and/or
computer accounts. You can create as many of these sub-administrative groups as you
need to delegate tasks to.
Use the Delegation of Control Wizard to assign the specific, and only the specific,
administrative rights that are required to the group.
Place appropriate users in the administration group.
Delegating Control
Delegation may be accomplished by selecting pre-prepared common tasks, such as reset
passwords, or by creating a custom task. The problem with the ability to delegate control is that
it exposes the myriad of permissions that are available on objects within the AD. Determining
which ones to grant to provide appropriate rights to management groups can be a challenge. For
this reason, several common tasks are defined. Going beyond these options and creating a
custom task does not have to be daunting; you simply need to understand permissions and to
keep your assignments limited. It would be very easy to arrange many complex sets of
permissions with wide-ranging and unintentional effects.
Chapter 5
Delegating Common Tasks
Common tasks are predefined sets of permissions available by selecting a check box within the
Delegation of Control Wizard. Tasks available for delegation include:
Create, delete, and manage user accounts
Reset user passwords and force password change at next logon
Read all user information
Create, delete, and manage groups
Modify the membership of a group
Manage Group Policy links
Generate Resultant Set of Policy (Planning)
Generate Resultant Set of Policy (Logging)
Create, delete, and manage inetOrgPerson accounts
Reset inetOrgPerson passwords and force password change at next logon
Read all inetOrgPerson information
For example, suppose I want to give my Help desk group the ability to reset user passwords and
force password change at next logon, modify the membership of a group, and read all user
information in the New York OU. To do so, I would perform the following steps: Create the
Help desk group. Right-click the New York OU in the Active Directory Users and Computers
Microsoft Management Console (MMC) snap-in, select Delegate Control, then click Next. In the
resulting window, click Add. In the Select Users, Computers, or Groups window, click Add.
Click Advanced, type
and click Find Now. Select the Help desk group, click OK twice, then click Next. From the
Tasks to Delegate window, select Delegate the following common tasks radio button, as Figure
5.1 shows. Select the tasks that represent the ability to reset user passwords and force password
change at next logon, modify the membership of a group, and read all user information. Then
click Next. Review your choices, and click Finish.
Chapter 5
Figure 5.1: Delegating common tasks.
After delegating authority, you cannot run the wizard to remove these rights. You can, however,
view and modify these rights by inspecting the permissions granted on the OU. In Active
Directory Users and Computers, right-click the OU, and select Properties, then select the
Security tab.
If you do not see the Security tab on the properties page for the OU, you must change the view to
Advanced. To do so, in Active Directory Users and Computers, select Advanced View from the View
Because the properties that you have selected are not those exposed in the main security page’s
permissions window, you must click Advanced to see or change them. Viewing the permissions
assigned as a result of task delegation is a good way to begin to understand the multitude of
permissions that can be assigned. As you will soon learn, the task may assign permissions whose
names do not exactly match the task description. In my example, the permissions granted are
defined as Property and/or Object Permissions that can be either Allow or Deny. To understand
each permission, select it, and click Edit. Table 5.2 describes the permissions from my example.
The permissions are all set to Allow.
Chapter 5
Read/Write Property on Group
Read Members, Write Members
[none ]
Write Property on User objects
Write pwdLastSet
[none ]
Reset Password on User
Reset Password
Read All Properties on User
Read all Properties, Read
account restrictions, read
general information, read group
membership, Read Logon
Information, Read Personal
Information, Read Phone and
Mail Options, Read Public
Information, Read Remote
Access Information, Read Web
information, Read
accountExpires, Read
accountNameHistory, Read
adminDescription, and so on for
every property
Read all properties
Table 5.2: AD permissions as a result of delegation of authority.
Creating a Custom Task
If the common tasks do not meet your needs, you can create a custom task and assign it to a
group. Doing so requires knowledge of the permissions that are available and the necessary sets
of permissions that are needed to accomplish some administrative task. There is no dictionary of
permissions and explanations, and there are a seemingly infinite number of possible permissions
and combinations. Not only are there many permissions that have odd-sounding names, but there
will be new permissions added when new applications that modify the schema are installed. For
example, adding Exchange 2000 Server to a forest will add hundreds of objects to AD. Each
object may have its own collection of permissions.
Even without a definitive dictionary of permission by your side, you can create useful custom
tasks. For example, to give the PandCM (Printer and Computer Managers) group the ability to
manage computers, printers, and shared folders for the New York OU, I would perform the
following steps:
1. Right-click the New York OU, and select Delegate Control, then click Next.
2. Click Add.
3. On the Select Users, Computers, or Groups window, click Add.
4. Click Advanced, type
and click Find Now.
5. Select the PandCM group, click OK twice, then click Next.
6. From the Tasks to Delegate window, select Create a custom task to delegate.
Chapter 5
7. Select Only the following objects in the folder, as Figure 5.2 shows.
8. Select check boxes next to
Computer objects
Printer objects
Shared folder objects
Create selected objects in this folder
Delete selected objects in this folder
9. Click Next.
10. Under Show these Permissions, select General.
11. Under Permissions, select Full Control, and click Next.
12. Review your choices, and click Finish.
Figure 5.2: Select the objects to control.
Providing Administrative Tools for Sub-Administrative Groups
Delegation of authority provides a great way to spread responsibility for administrative tasks
while limiting administrative authority. You can give only the rights and permissions that allow a
user to do a job without giving that user authority that might put systems at risk. Delegation of
authority creates administrative groups, outside of the default, powerful Administrators group.
Chapter 5
You can also support these administrative efforts by creating custom MMC console that expose
only the data for which a group of users is responsible. For example, suppose the PandCM group
needs a tool to add and remove computers, printers, and file shares for the New York OU. It
would be overkill to ask them to use Active Directory Users and Computers, and you would be
needlessly exposing the structure of your directory. To create a custom MMC console for the
PandCM group, create a MMC and add Active Directory Users and Computers. Next, create a
custom task pad that displays only the New York OU. Filter the display so that only computers,
shared folders, and printer objects appear. Next, create shortcuts to custom tasks such as Create
new computer and Create a printer. Remove menus, toolbars, and items that would allow users
of the console to display or work with other OUs or containers in AD. Finally, Restrict the scope
of the console by using console modes. Doing so can prevent users from adding additional snapins to their console.
After you have tested the console, use Group Policy to establish which consoles can be used by
the PandCM group. You might then distribute the console to members of the group via floppy
disk, email attachment, or use Group Policy to publish and assign the console to the group
members. To create a custom console for the PandCM group:
1. Open a blank console by selecting the Start men, Run, typing
then clicking OK.
2. Select Add Remove snap-in from the File menu.
3. Click Add.
4. Select the Active Directory Users and Computers snap-in, click Add, Close, then click
5. Expand the domain, and select the New York OU.
6. From the Action menu, select New Taskpad View.
7. From the Welcome window, select Next.
8. In the Taskpad Display window, select Horizontal list. Then select List size: Large, and
click Next.
9. In the Taskpad Target window, select Selected tree item, and click Next.
10. Enter New York for the name of the taskpad, and click Next.
11. Leave the Start new Task wizard check box selected, click Finish, then click Next.
12. Select Menu Command, and click Next.
13. Select the command source Tree item task.
14. Leave the New York OU selected, and in the available commands window, select New-
>Computer, and click Next.
15. Name the task Create New Computer.
16. Change the description to Create a new Computer, and click Next.
17. Select the computer icon, and click Next.
Chapter 5
18. Select the Run this wizard again option, then click Finish to repeat the process and create
tasks for adding a new printer, and for adding a new shared folder.
19. From the File menu, select Options.
20. Change the console name to New York.
21. Change the Console mode to User mode—limited access, single window.
22. Clear the Allow the user to customize views check box, as Figure 5.3 shows.
Figure 5.3: Restricting changes to the console by preventing a view change.
23. Click OK.
24. From the View menu, select Filter Options.
25. Select Show only the following types of objects.
26. Select Computers, Printers, Shared Folders, then click OK.
27. Select the New York OU.
28. From the View menu, select Customize.
29. Clear all the check boxes, as Figure 5.4 shows, then click OK.
30. From the File menu, click Save, name the console New York, and click OK.
Chapter 5
Figure 5.4: Removing all possible functions that might modify the console view.
Open the console as a user in the PandCM group to test its functionality. You should see only
computers, printers, and shared folders in the New York OU, and be restricted to managing
them, as Figure 5.5 shows.
Figure 5.5: The custom console is easy to use and restricts its users to allowed functions.
Chapter 5
One way to restrict the new console’s users is to use file permissions. However, doing so won’t
ensure that users who are supposed to use the new console do so. Users might attempt to thwart
your restrictions and use Active Directory Users and Computers to manage their OU or create
their own consoles. Although the rights and permissions they have been given will restrict their
actions, you might want to require them to use the custom console. To restrict users from using
other consoles, you can use Group Policy settings. First, you must determine which consoles
they may need to use, then write the policy to either restrict all consoles except those allowed, or
to allow all consoles except those restricted. You can also prevent users from opening a console
in author mode. Author mode is the mode that allows a user to modify the console. To create the
policy to restrict author mode:
1. Open or create a Group Policy Object (GPO) link in the New York OU.
2. Navigate to the User Configuration, Administrative Templates, Windows Components,
Microsoft Management Console, Restricted/Permitted snap-ins.
3. Select the Restrict the user from entering author mode check box, click Enabled, then
click OK.
To restrict the use of consoles:
1. Open or create a GPO in the New York OU.
2. Navigate to User Configuration, Administrative Templates, Windows Components,
Microsoft Management Console.
3. If you want to prevent the use of all consoles, then individually enable them, double-click
Restrict users to the explicitly permitted list of snap-ins, select Enable, and click OK. If
you would rather choose the snap-ins to prevent users from using, skip to Step 6.
4. Double-click Restricted/Permitted snap-ins, select the console you want to allow, select
Enabled to allow users in this OU to use the console, then click OK.
5. Repeat Steps 3 and 4 for each console you want to permit users to use, then skip to the
end of this list.
6. Double-click Restricted/Permitted snap-ins, then double-click the console you want to
prevent users from using.
7. Select Disabled to prevent users in this OU from using this console, or select Enabled to
allow them to use the console.
8. Repeat Steps 6 and 7 for each console you want to prevent users from using.
Chapter 5
Q. 5.4: Our policy is to let users in sensitive departments maintain the
backups for servers within their departments. To allow users in the
Accounting department to back up their servers, I created a global
group for the users and a local group on each server. The local group
is assigned the right to back up files and directories in the local
security policy of each server, but these users cannot back up the
servers. What is wrong?
A: User rights are easily assigned in Windows Server 2003; the challenge is to assign them in
the right place to accomplish what you want to do. User rights are assigned in Group Policy, but
multiple levels exist. Which level will give you the results you want? To select the appropriate
location, you must understand how Group Policy affects user rights and how Group Policy
processing for user rights varies from Group Policies’ usual application.
Location, Location, Location
On a Windows Server 2003 server that is not joined in a domain, user rights are assigned in the
local security policy. These rights affect the local users. When, and if, the server is joined to a
domain, these rights still affect local users’ accounts. If a user logs on with a local user account,
the user will receive the rights assigned in the local security policy. However, users that use a
domain account to access the server are subject to the more complex rules of Group Policy.
Several Group Policies have the potential to affect the user rights assigned to a domain account.
Table 5.3 shows four basic levels that can do so in the order in which they are applied.
Local Security
Affects only the local computer on which it resides
Not recommended for use
Affects all computers in the domain, set in the default domain controller policy
linked to the Domain Controller OU
Affects only the computers with accounts in this OU or a child OU
Table 5.3: Group Policy levels.
If you inspect the default domain controller security settings Group Policy Object (GPO—
located at Windows Settings, Security Settings, Local Policies, User Rights Assignment), you
will find the backup files and directories user right assigned to Administrators, Server Operators,
and Backup Operators. Inspect the GPO for the domain, and you will find that all user rights are
not defined by default (see Figure 5.6). This setting seems to imply that all computers in the
domain can be backed up by users with membership in these local groups assigned at the local
level in the local security policy. However, if you use local security policy and add a group to the
groups that can back up files and folders, then use the Resultant Set of Policy to determine who
has the right to back up files and directories, you will see that it remains Administrator, Server
Operators, and Backup Operators. Setting local policy doesn’t seem to have any affect.
Chapter 5
Figure 5.6: Default domain security policy.
To understand what’s happening in this example and how to interpret what will happen to other
locally set security settings, note that Group Polices are applied in order. Although one policy’s
settings can complement another policy’s setting, such only happens when one of the policies
does not have a setting defined. If more than one policy has conflicting settings, the policy
applied last will be used. Domain-level Group Policy is applied after the local security policy, so
any policy set locally will be overridden by the domain policy unless the domain policy doesn’t
have the setting configured.
Many settings are not defined in the domain policy, so when domain policy is applied, no
changes are made to those items. However, the default domain policy is not the only one applied.
The default domain controller GPO is applied as is any policy created at the OU or parent OU for
the computer. Changes in these policies change the computer and user settings from those
applied by the local Group Policy. If you inspect the default domain controller GPO, you will
find that it has the user right Backup Files and Directories defined. Hence, when you set user
rights in the local security policy of a computer joined in a domain, the user rights will only
affect users logging on to the computer with a local account.
Chapter 5
So how can we create a policy that lets us define the group that has the Backup Files and
Directories right? We could make a change at the default domain policy, but that would affect
every computer in the domain. Instead, we’ll create a different user rights policy for different
computers in the domain by creating a policy that is applied at the OU level. The policy will only
be applied to computers whose accounts exist within the OU. OU policies are applied after the
domain policy, so their settings will be used when a conflict exists. They will override the
domain policy for all computers in the OU.
To give the right to back up the servers in the Accounting OU to a select group of users in the
Accounting department, use the following steps: Create an Accounting OU, and place the
computer accounts for Accounting servers within this OU. On each of the Accounting servers,
create a local group Abackup. In the domain, create the global group GABackup, and make the
accounting employees authorized to back up the Accounting servers members of this group.
Make the GABackup group a member of the local group Abackup. In the GPO for the
Accounting OU, open the properties page for the Backup Files and Directories user right (located
at Windows Settings, Security Settings, Local Policies, User Rights). Select the Define these
policy settings check box, and add the Abackup group, then click OK (see Figure 5.7). Close the
Group Policy.
Figure 5.7: Defining user rights for the Accounting GPO.
After the policy has refreshed, use Resultant Set of Policies to inspect the user rights for one of
the servers in the Accounting OU. You will find that the effective policy lists only the Abackup
group under the user right Backup Files and Directories. On other servers in the domain, the
default setting will still be Server Operators, Backup Operators, and Administrators. Remember,
when a policy is applied and settings are not defined, the new settings are added to the old.
However, if settings exist in more than one policy, the most recently applied policy will be used.
Chapter 5
Q. 5.5. What exactly can an Enterprise Administrator do?
A: The Enterprise Administrator can do whatever the Enterprise Administrator wants to do. The
Enterprise Administrator role was established in Windows 2000 (Win2K). An Enterprise
Administrator can administer the entire forest. To be such an uber administrator requires
membership in the Enterprise Admin group, which only exists in the root domain in the forest.
By default, its only member is the root domain local Administrator account. Much of the
authority for this group exists as a result of its membership in the Administrators group in each
domain, but it also has specific rights of its own. These rights typically provide management of
forest-wide resources. Examples of such rights are the right to install an Enterprise Certification
Authority (CA) and the right to run Resultant Set of Policy (RSOP) across multiple domains in a
OK, so it’s easy to figure out what an Enterprise Admin can do—just think anything
administrative anywhere, but especially those things that require authority in multiple domains.
To illustrate the difference between a Domain Administrator and an Enterprise Administrator,
let’s say, for example, that a Domain Administrator has been charged with providing email
services or certificate services for his or her domain. The obvious choices are to install Exchange
for email and to install Windows Server 2003 certificate services. The first Exchange installation
in a forest, however, must be initialized by an Enterprise Administrator, and subsequent
installations must also have more rights than a Domain Administrator has. Installing enterprise
certificate services is also not possible without Enterprise Admin membership. Other activities
may also require rights beyond those of the Domain Administrator. Table 5.4 lists many of the
activities that require rights beyond those of the Win2K and Windows Server 2003 Domain
Administrator, and indicates some rights that do not require Enterprise Admin membership.
Chapter 5
In order to
You must be
Install enterprise root CA
Enterprise Admin, Forest Root Domain Admin
Install enterprise subordinate CA
Enterprise Admin, Forest Root Domain Admin
CA administrator standalone CA, no
Local Admin
CA administrator standalone CA in a
Local Admin, Domain Admin
Enforce role separation on CA
Local Admin
Authorize Dynamic Host Configuration
Protocol (DHCP) in Active Directory (AD)
Domain Admin
Administer all DHCP servers in domain
Domain Admin
Administer the local DHCP server on the
local computer
DHCP Admin
Administer every domain in the forest
Enterprise Admin
Run dcpolfix to restore default Group
Policy Objects (GPOs)
Enterprise Admin
Create AD application partition
Enterprise Admin
Delegate RSOP control at site and
domain level
Enterprise Admin
Enlist a Domain Name System (DNS)
server in an AD application partition
Enterprise Admin
Run RSOP in domain
Domain Admin
Runs RSOP across domain boundaries
Enterprise Admin
Install first instance of Exchange (forest
prep has not been run prior)
Enterprise Admin, Schema Admin, Domain Admin
Install additional instances of Exchange
(or initial if forest prep has been run)
Either Enterprise Admin and local Administrators, or Domain
Admin, local Administrators, and Full Exchange Administrator
Table 5.4: Which rights and activities administrators can perform.
Although this table doesn’t provide a comprehensive list of every right that is considered
expressly the domain of the Enterprise Administrator, one approach that might help you
understand the role of Enterprise Administrator is to place that role in the context of others. To
help you do so, I have put together a picture of role-based administration as represented by the
hierarchical structure of groups in Windows Server 2003. (This representation is my own
interpretation—I can find no official reference to hierarchical administration.) At the top of the
hierarchy, of course is the Enterprise Admin, followed by the forest role of Schema Admin (a
forest-wide role but not one that is all powerful in it). Next are domain roles, starting with
Domain Admin, then by specific server or network administration roles. Next, are the Users,
followed by specific accounts that have limited rights and permissions. It is not possible to place
in this hierarchy those users who have been delegated rights. These are roles that you create by
giving users or groups permissions on AD objects. They might also be roles created by assigning
specific user rights to custom user groups. There is no one place where they fit, as the delegated
or assigned rights might make them uber admins of organizational units (OUs) or minor players
with little more than user-level rights on the system(s) they use. Figure 5.8 illustrates the
Chapter 5
hierarchy, while Table 5.5 places the default user and computer groups at each level. Outside of
the base hierarchy, but of great importance, are the roles designated by specific services that
might be added. Exchange Administrator is one of these, as are the certificate services roles Issue
and Manage Certificates and Certificate Manager.
This hierarchical viewpoint is meant merely as a way to consider administrative authority in a
Windows Server 2003 forest. It does not begin to address the concept of scope, which details where
members can come from and where the groups can be given authority.
Figure 5.8: Role-based administration in Windows Server 2003.
An example of an unusual delegated role is that created by delegating management of DHCP
authorization on the network, which is done through the Sites and Services Console. The Netservices
container is selected, and the delegation of control wizard used to give the Full control permission for
this folder, existing objects, and creation of new objects, to a user group that you have created for this
Chapter 5
A Hierarchical View of Windows Server 2003 Administration
Forest Role
Domain Role
Server/Computer Role
User Role
Enterprise Admin
Uber admin
Schema Admin
Modify Schema
Domain Admin
Administer domains
Cert Publishers
Computers that can publish certificates to
Group Policy Creator Owners
Members can create and edit group policy
objects for the domain
Domain Computers
Can be managed, domain administration
Domain Controllers
Serve as domain controllers in domain
Backup Operators
Backup and Restore
Server Operators
Logon interactively, create shares, shut
down computer, format drive, stop start
services, backup and restore
Account Operators
Create and manage groups, users, and
computers. Cannot manage
administrators, domain controllers.
Print Operators
Manage printers and document queues
Network Configuration Operator
Client side of network configuration;
cannot install/remove drivers or services
DHCP Administrators
Can administer local DHCP server service
Can administer DNS Server service
DNS clients that are permitted to perform
dynamic updates on behalf of other clients
(common membership is a DHCP server)
Rights common to all support applications;
by default, group membership is the
account associated with Microsoft support
applications, such as Remote Assistance;
users should not be added to this group; it
is managed by the Help and Support
IIS 6.0 worker process group; an account
is assigned here by the system to manage
a namespace ( would be a
namespace, as would;
do not add users to this group
RAS and IAS Servers
Can access remote access properties of
Domain Users
Logon to domain; run applications; access
files; use printers; add workstation to
domain; bypass traverse checking;
shutdown workstation
Domain Guests
Logon on to domain (account disabled by
default.); bypass traverse checking;
shutdown workstation
Logon locally; bypass traverse checking;
Chapter 5
shutdown workstation; run applications;
access files, and use printers
Logon on (account disabled by default.);
bypass traverse checking; shutdown
Pre-Win2K Compatible Access
Adding the group Everyone here and
rebooting domain controllers provides
security level compatible with many preWin2K applications
Remote Desktop Users
Log on to a computer from a remote
DHCP Users
View-only access to the DHCP Server
WINS Users (installed with WINS
Server service)
View-only access to the WINS server
Table 5.5 Role Hierarchies
Q 5.6: How can I support delegation of services for an n-tier
application without creating a huge security hole?
A: First it’s important to consider why delegation is necessary in this situation, only then will
you be able to select the most secure way to do so. In the typical scenario, an Internet-accessible
Web server application requires access to multiple SQL database servers. To do so, the Web
server must be able to provide credentials that are acceptable to the databases. No problem, we
think, we’ll use the domain user ID to assign privileges in the databases. When the user runs the
application, the appropriate access will be granted. However, if we try to run such an application,
we soon find that this setup will not work. A problem exists because the application on the Web
server needs to access the SQL databases, and to do so needs to act as if it is the user. This
process, sometimes known as impersonation, is referred to as delegation. (Do not confuse this
with delegation of authority, the ability to provide users with administrative responsibility in
organizational units—OUs).
Delegation is not possible in Windows NT 4.0, but is, if permissions are set, in Windows 2000
(Win2K) and Windows Server 2003. The ability to do so in Win2K is based on the Kerberos
protocol delegate flag specification. According to the Kerberos standard (as defined in Request
for Comments—RFC—1510), a Ticket Granting Ticket (TGT) can be granted with the delegate
flag set, which then allows the ability of a third party (someone other than the user who acquired
the ticket) to use the ticket to obtain a service ticket for another service. For example, suppose
userA uses Kerberos to authenticate to WebServerB. UserA then uses a program on
WebServerB, which needs to access data in a database on SQLServerC. UserA does have
appropriate permissions for the data that resides in the database. Because the delegate flag is set,
WebServerB can impersonate userA and authenticate to SQLServerC. WebServerB obtains data
from SQLServerC, and uses the data to complete its processing and return results to userA.
Chapter 5
As useful as this feature is, it is often criticized as a security issue in Win2K. The reason is
because delegation cannot be restricted. The server that has been trusted for delegation can then
act for the user account in any way. Thus, the privileges and access rights that the user holds are
available for the server. This feature might be too easy to abuse. Unfortunately, in Win2K, there
is no way to restrict this action.
Constrained Delegation in Windows Server 2003
In Windows Server 2003, this issue is mitigated by providing the ability to restrict, or constrain,
delegation. Delegation can be restricted to certain services. Thus, delegation may only be granted
for querying a database. In our example scenario, WebServerB can be trusted for delegation only
in accessing SQL Server. If userA authenticates to WebServerB and attempts to access data on
SQLServerC, userA will be successful. However, an attempt by an administrator of WebServerB
to run a program and impersonate userA to access files on FileServerD to which userA has
access, will not.
The choice of whether to trust a computer for delegation to any service is still possible in
Windows Server 2003. However, the ability to constrain this delegation to only certain services
is available as well. You can do so by designating a computer or user account that is assigned to
a service as trusted for delegation to specific services. To use constrained delegation, the
following must be true.
The computer must be in a Windows Server 2003 domain functionality level
The computer doing the delegation must be trusted for delegation
The account that the server is delegating for (userA in our example) must not have the
local account policy option setting Account is sensitive and cannot be delegated selected.
Implementing constrained delegation is a three-step process. First, determine the computer
and/or services to be trusted for delegation. Next, determine sensitive accounts (good candidates
are administrator-level accounts) and mark the local account policy option Account is sensitive
and cannot be delegated. Finally, mark the selected service accounts/computers as trusted for
To protect sensitive accounts, you can use the following process to mark the local account polity
as Account is sensitive and cannot be delegated. Right-click the user account in the Microsoft
Management Console (MMC) Active Directory Users and Computers snap-in, and select
Properties. Select the Account tab. In the Account options section, select the Account is sensitive
and cannot be delegated check box (see Figure 5.9). Click OK to close the property pages.
Repeat this process for each account identified as sensitive.
Chapter 5
Figure 5.9: Restricting sensitive accounts.
To set a computer/service accounts as trusted for delegation, open Active Directory Users and
Computers, click the Computers Container in the console tree, right-click the computer to
delegate, and select Properties. This computer is the mid-tier computer, such as the Web server
in our example. Select the Delegation tab. Select the Trust this computer for delegation to
specified services only check box (see Figure 5.10).
Figure 5.10: Trust the computer for delegation.
Chapter 5
Next, select either the Use Kerberos only or Use any authentication protocol option, and click
Add. Under Add Services, click Users and Computers. Under Select Users or Computers, enter
the name of the user or computer for which the system will be trusted to delegate. In our
example, this would be SQLServerC. In the Available Services section (see Figure 5.11), select
the service to be trusted for delegation. (The services available on the computer selected will be
displayed.) Click OK, repeat the steps as necessary (multiple computers and services on each
computer can be selected), then click OK to close the property page.
Figure 5.11: Select the service to be trusted for delegation.
Chapter 6
Chapter 6: Triple A’s—Authentication, Authorization, and
Q 6.1: How does authorization occur when users in one Windows
Server 2003 forest attempt to access a file on a server in another
Windows Server 2003 forest?
A: The important thing to remember when attempting to understand authorization across a forest
trust is that it follows the same concept as authorization within a forest. Authorization is based
on successful authentication. Within a domain, access to resources is the result of five
operations, as Figure 6.1 illustrates.
Figure 6.1: Access to resources within a domain.
1. The client authenticates to the Key Distribution Center (KDC—domain controller) for the
client’s domain and receives a ticket-granting ticket (TGT).
2. Using the TGT, the client asks the KDC for a session ticket for use with the server on
which the resource resides.
3. The KDC issues the session ticket.
4. The client uses the session ticket to access the server, and the server is able to use the
authorization material that accompanies the ticket to build an access token.
Chapter 6
5. Finally, the access control entries (ACEs, which determine who can do what with the
resource) are compared with the values in the access token (which determines who the
user is and what groups the user is a members of). If everything is in order, access is
Access to a resource in another domain within the forest follows the same model, except a
domain controller in the domain in which the resource resides must provide the session ticket.
The following steps explain the process:
1. The client requests a session ticket.
2. To get the session ticket, the user’s domain controller answers the client’s request for a
session ticket with a referral ticket, a sort of TGT good in another domain. The client’s
domain controller cannot offer this ticket for every domain in the forest, only for those
with which it shares an inter-domain password. In essence, these domains turn out to be
its child domains and its parent domain.
3. In a forest with only two domains, a single referral ticket gets the client to the correct
4. From this domain’s domain controller, the client can obtain a session ticket.
5. The session ticket is then used to request access to the resource.
Figure 6.2 illustrates this operation.
Figure 6.2: Access to resources in a second domain.
Chapter 6
In a larger forest, a series of responses to referral tickets result in another referral ticket until the
client receives a referral ticket for the correct domain. This referral ticket is then used to obtain a
session ticket for the resource server. In a forest with multiple trees, the requests will always go
through the tree root domains. Figure 6.3 traces this route. This forest has two trees, the
Teluro.local tree and the tree. In the diagram, Alice, whose account is in the
West.Teluro.local domain, wants to access a resource on server Fullsome in the domain. To do so, her client asks the KDC in West.Teluro.local for a
session ticket for The KDC realizes that this server is not
in its domain nor in its tree, so instead grants a referral ticket for its parent domain Teluro.local,
the root domain of the tree. Now, when requested, the Teluro.local KDC must provide a referral
ticket for a domain in the tree. In fact, because both the Teluro.local and Hcwt.local
domains are the root domains of their respective trees, they share an inter-domain password, so a
referral ticket can be provided to the KDC. The request and resultant referral ticket
process continues, this time walking down the trust path of the tree until a referral
ticket for the domain is provided. This referral ticket is then used to
obtain a session ticket for the server Fullsome. The trust path for any such forest resource access
request will be similar. If the resource server is on a different domain tree than the client, the
path must always go through the tree root domains.
Figure 6.3: Using the trust path to obtain resource access.
Chapter 6
Resource access across a Windows Server 2003 forest trust is similar. When the trust is created
between the forests, access can be granted to user accounts from the trusted forest. The trust path
will always go through the forest root domains. The client still needs a session ticket for the
resource server. This session ticket can only be granted by the KDC of the resource server’s
domain. To get the ticket, the request must follow the trust path to the root domain of the client’s
forest, from there to the root domain of the resource forest, and eventually to the resource
server’s domain. When the client obtains a referral ticket to the resource server’s domain, the
client will be able to request and obtain a session ticket for the server.
However, there is a problem determining the location of the resource server. Although the client
may have the Service Principal Name (SPN) of the resource, the client must obtain information
about the location of the server with respect to the domain in which the client’s account is
The SPN is either the DNS name of the domain, the DNS name of the host, or the distinguished
name (DN) of the service connection point object.
In a single forest, information about all domains is part of the Global Catalog (GC). Routing
hints, or the domain location of the resource domain, can be obtained by querying the GC. When
the client is in one forest and the resource server lies in another forest, information about the
resource server’s KDC will not be in the GC of the client’s forest. Not to worry; a list of all
trusted domain objects is in the GC of the client’s forest. Figure 6.4 and the following description
detail this part of the equation. For this example let’s assume that
An appropriate forest trust has been established between the two forests.
Alice, whose user account is in the forest, is logged on to her domain, the domain, from a Win2K Pro system that is a member of the
same domain.
Alice is attempting to map a drive to the file share Project 123, which is on a server in the
East domain, which is in the forest.
Chapter 6
Figure 6.4: Finding the location of a resource across a forest trust.
1. Alice’s computer’s Kerberos client contacts the KDC service on a domain controller in
the domain, and requests a session ticket for the SPN of the
resource computer East in the domain.
2. The domain controller attempts to locate the SPN and does not find it in its own database,
so it queries the GC server for its forest,
3. The GC determines that the SPN is not in its forest (the GC cannot see outside its own
forest) but looks in its database of trusted domain objects. In this list, the GC looks for a
match between the suffix of the requested computer and that of the requested SPN. In this
case, because the forest trust exists, the GC will find a match. The GC provides the
domain controller with a routing hint to a domain in the forest route
4. The domain controller contacts the forest root domain of the forest,
including the routing hint, which includes the address of Alice’s workstation.
5. The forest root domain, because it doesn’t have the SPN of the
server in its database, contacts the GC for Alice’s forest, and the GC provides the
6. The domain controller passes the SPN of the server back to Alice’s
7. Now that the trust path is known, Alice’s Kerberos client works in the normal manner to
obtain a TGT for the domain, then negotiates the session ticket
for the server.
8. Alice’s workstation presents the session ticket to the file server.
Chapter 6
Q 6.2: I am tasked with tracing logon behavior across our Windows
Server 2003 forest and would like some help understanding the
difference between the Audit categories Audit Account Logon and
Audit Logon. What is the difference?
A: Here’s a simple explanation of the difference between the two:
Setting Audit Account Logon Events records events where the account resides. If Nancy
logs on to the domain from her desktop, the Security event log of the domain controller
will record Account Logon Events. Many Account Logon events are Kerberos events.
Setting Audit Logon Events records events where the logon event occurs. These events
are recorded in the Security event log of Nancy’s desktop computer.
Thus, to have a clear picture of a user’s domain log on and log off behavior, you must enable
auditing of Audit Account Logon Events on the domain controllers and Audit Logon Events on
every computer that the user might use to log on to the domain. You will then need to
consolidate event logs from multiple computers and query for the different logon events
associated with that user. You must also keep in mind the many logon events that might be
generated during this user’s normal activities:
Account Logon Events might be recorded when the user attempts to access resources, not
just when the user logs into the domain.
Multiple logons by the user from different computers.
Logons by the same user using another account.
Unlock workstation events.
The user’s use of the run as command to perform secondary logons
The user’s employment of alternative credentials when mapping network drives.
Tracking logons is not a simple task, but a user’s activity can be tracked with a little practice and
the knowledge of typical events’ meanings. Tables 6.1, 6.2, and 6.3 detail Account Logon Events
and Logon Events.
Chapter 6
Authentication Server (AS)
ticket issued
This ticket is the first Kerberos ticket issued if the user presents
valid credentials; it essentially says “OK, this user is who they say
they are.”
Ticket Granting Service
(TGS) ticket issued
This ticket is issued for a specific server or service. When the
user, for example, wants to access files on a file server, a TGS
ticket for the file server is required.
Security principle renewed
an AS ticket or TGS ticket
Tickets are renewable (see Kerberos policy definitions in the
domain Group Policy).
Pre-authentication failure
Authentication failed, many times as a result of a timesynchronization failure.
TGS was not granted
Failure perhaps as a result of an invalid AS, unknown server or
service, or time skew.
Account mapped to domain
A confirmation that the account has been located.
Domain account logon
If an account exists within the domain, logon can fail for many
reasons (see error codes listed in Table 6.2).
Table 6.1: Account logon events are recorded where the account resides.
Unknown user or bad
The user account or password is invalid.
Time restriction violation
A valid logon time range is defined for this user account and this
time is not within that range.
Account disabled
The account is disabled at this time.
Log on not allowed at this
The computers from which this account can logon are specified in
the account for the user. This computer name is not within that
Logon of this type not
allowed at this computer
Policy does not allow this type of log on (network, interactive,
remote) at this computer.
Account password expired
The password for this account expired.
Netlogon not active
The Netlogon service has stopped.
Table 6.2: Account logon failure codes for Event 681.
Chapter 6
User successfully
logged off
Always present if a user logged off in normal fashion.
Failure due to bad
password or unknown
user name
Either an attack or the user forgot his or her password.
Attempt to log on
outside of allowed time
Allowed time range is set in user account properties.
Attempt to log on using
a disabled account
A disabled account is not a locked out account. A disabled account is
made so by an administrator selecting the check box labeled
Disabled. A locked out account is locked out due to unsuccessful
logon attempts.
Attempt to log on using
an expired account
Temporary workers’ accounts are often set with expiration dates that
can be changed. This event is probably the result of a contractor
staying beyond the estimated job tenure.
User is not allowed to
log on from this
Allowed computers for logon can be set in user properties. This
computer is not one of those listed for this user.
Attempt to log on with a
type of logon that is not
Logon on locally, network logon, batch logon, service logon, and
remote logon can all be denied implicitly or explicitly.
Attempt to log on with
an expired password
Passwords can be set to expire (there is a difference between
expired account and expired password).
The Netlogon service is
not active
Netlogon stopped or is otherwise malfunctioning.
Failed for some other
Other reasons not documented.
User logged off
User employed Ctrl+Alt+Del to log off.
Account is locked out
Bad logon attempts reached the account lockout threshold for this
Successful log on to a
Logon was successful.
541 –
Logon events related to
Computer endpoints can be authenticated using IPSec policies.
These logon events are reported as well.
Table 6.3: Logon events.
Chapter 6
Tracing a User’s Logon and Logoff Events
One of the benefits of understanding ordinary events is that you’ll know what extraordinary
events mean. A good exercise is to attempt to determine which events will be found in the logs
of the client computer and the domain controller during an ordinary logon. After compiling your
list, log on at a client as an ordinary user. Leave the user logged on while you examine the event
logs of the domain controller. Are you able to find what you expected? Remember that you can
filter the Security event log by the user’s name but that Kerberos logon events will be register as
system events (NT AUTHORITY\SYSTEM). Find the user logon event (an event 528 logon type
3 for network logon) using the filter on the user’s name, then remove the filter and examine the
nearby events. You will find that when opened, the details list the user ID. Return to the client
computer and log off the user. Log on as Administrator to view the security events. What would
you expect to find here?
On the local workstation you should find a 528 event—successful logon, as Figure 6.5 shows. In
this figure, Nancy, is clearly identified within the body of the event message. Her SID is the only
identity in the main event heading because this event was pulled from an exported event log. On
the local workstation VMXP1, the user Nancy replaces the SID. If the local workstation log had
been exported in comma or tab-delimited format, the name Nancy, not the SID, would appear.
Working with user names is easier than working with SIDs, which provides a good reason for
exporting logs in comma or tab-delimited format for review.
Figure 6.5: Successful interactive logon at the workstation VMXP1 by Nancy.
Chapter 6
On the domain controller, we will find events that record the Kerberos ticket requests and a 528
event with a logon type of 3 for network logon. Successful Kerberos events are 672,
authentication ticket request, as Figure 6.6 shows.
Figure 6.6: A successful authentication ticket requests indicates the user’s credentials are in order.
As Figure 6.6 shows, the user is identified by presenting proper credentials (user ID and
password). As Figure 6.7 illustrates, event 673 shows a service ticket request in which the user
requests a service ticket to use the workstation desktop.
Chapter 6
Figure 6.7: A successful service ticket request is required before the user can access his or her desktop.
In this figure, note the logon ID. This number is unique for each logon session. Later in the day
when the user logs off, the same logon ID will be used (as Figure 6.8 shows). If a user performs
multiple logons and log offs at the same computer, each log on can be matched to its log off
event by using the logon ID. When audit logs are consolidated, several logon IDs may be present
for the same user. They will represent different logon sessions, either at the same computer or at
multiple computers. Connecting logon events by comparing logon IDs will keep things straight.
This information might be important if you are trying to determine the timeframes at which a
particular user was actually online.
Chapter 6
Figure 6.8: Event 538 indicates a successful logoff.
Q 6:3: I’ve added Access Control Lists to a folder to allow one group
of users full control, and set permissions to give another group of
users the ability to read and write files. Recently, I discovered that
users in the second group can also delete files in this folder. I’ve tried
assigning the Deny delete permission to the files, but the second
group are still able to delete files. How can this be and how do I fix it?
A: The actual access and ability to manipulate files within a Windows Server 2003 NTFS folder
depends on several factors, which is why you often think that you are setting permissions
correctly, only to discover later that you have given more or less permission than you intended.
Because I don‘t know the exact permission settings you’re trying to troubleshoot, I’ll explore the
possible permission issues that most frequently cause deletion problems to happen. To do so, I’ll
look at each factor that may affect file access:
Permissions vs. special permissions—Permissions may be made up of several subtasks.
Inheritance—Permissions set on parent folders that are inherited by those below.
Additional permissions and rights—The Change Permission permission, Take Ownership
permission, Full Control permission, and the Take Ownership right.
Chapter 6
Folder permissions—Permissions set directly on a particular folder.
File permissions—Permissions set directly on a file.
It is only by consideration of all these elements that we can answer the question, What
permissions does Joe User have on this file?
Permissions vs. Special Permissions
The first three issues can be eliminated as the cause of your problem by inspecting the
permissions granted according to choices made when assigning permissions on folders and files.
Each of the permissions listed under the Security tab are composed of other special permissions
that you can view by clicking the Advanced tab. Our objective is to look for the case in which
the Delete permission may have been inadvertently explicitly granted to the files. Table 6.4 lists
permission for folders and files and their makeup. For the Delete permission to be explicitly
granted on your files, either the Full Control or Modify permission would have to be granted.
Special Permissions
(If Applicable)
Special Permissions
Full Control
All permissions
All special permissions
Read & Execute,
List Folder
Contents, Read,
Write, Special
All special permissions
except Full Control,
Delete Subfolders and
Files, Take Ownership,
and Change
Read &
Execute, Read,
Write, Special
All special permissions
except Full Control,
Take Ownership, and
Change Permissions
Read &
Read & Execute,
List Folder
Contents, Read,
Folder/Execute File, List
Folder/Read Data, Read
Attributes, Read
Extended Attributes,
and Read Permissions
Read &
Execute, Read,
Folder/Execute File, List
Folder/Read Data,
Read Attributes, Read
Extended Attributes,
and Read Permissions
List Folder
List Folder
Contents, Special
Folder/Execute File, List
Folder/Read Data, Read
Attributes, Read
Extended Attributes,
and Read Permissions
Not applicable
Not applicable
List Folder/Read Data,
Read Attributes, Read
Extended Attributes,
and Read Permissions
List Folder/Read Data,
Read Attributes, Read
Extended Attributes,
Read Permissions
Create Files/Write Data,
Create Folders, Append
Data, Write Attributes,
and Write Extended
Create Files/Write Data,
Create Folders, Append
Data, Write Attributes,
and Write Extended
Whichever special
permissions you grant
Whichever special
permissions you grant
Table 6.4: File and folder permissions and special permissions.
Chapter 6
Figure 6.9 displays the advanced permissions selections when the Modify Permission is chosen
on a folder. A quick scan of Table 6.4 shows me that because you gave users the ability to Read,
or to Read & Execute and Write, you have not accidentally given them the Delete permission.
Figure 6.9: The Modify Permission is made up of many special permissions.
Permissions set on a folder may be inherited by its subfolders and files. For most folders, this
behavior is the default. However, this behavior can be changed by choosing a different selection
from the Apply to drop-down box when applying permissions, and can be blocked by clearing
the appropriate check box on the Security tab of the properties pages of the folder.
The Apply to setting can be assigned when assigning permissions. You can view the current
Apply to settings by clicking Advanced on the Security tab of the properties page of the folder,
as Figure 6.10 shows. The choices available include:
This folder only
This folder, subfolders, and files
This folder and subfolders
This folder and files
Chapter 6
Subfolders and files only
Subfolders only
Files only
Figure 6.10: Viewing the Apply to settings for permissions.
The effective permissions on the file are the result of merging the permissions inherited from all
of a file’s parent folders with the explicit permissions granted on the file. In cases in which a
Deny permission conflicts with an Allow, in most cases, Deny will win over Allow. However,
when the conflict is a result of the inheritance of settings from different parents, the result will
depend on the parent that is closest to the file.
To block inheritance, you must clear the Inherit from parent the permission entries that apply to
child objects. Include these with entries explicitly defined here check box, which you can find on
the Advanced Security Settings page for the folder. Figure 6.10 shows an example of a page in
which this check box is cleared, which is the default setting.
Chapter 6
A possible answer to your question involves inheritance. If users are allowed to read and write
files to a folder, they don’t necessarily have permission to delete them. However, if permissions
have been set in the folder to give the CREATOR OWNER Full Control, as Figure 6.11 shows,
that permission will be inherited, giving the creator of the file full control over the file. Full
Control grants the user the ability to delete the file. Giving CREATOR OWNER Full Control is
the default setting at the root of the system drive, and thus is inherited by all subfolders. If this
behavior is not the desired behavior, you will need to either set the Deny Delete permission at the
folder level (and have it apply to this folder, subfolders, and files) or block inheritance at the
folder level and remove or modify the setting granting permissions for the CREATOR OWNER.
You indicate that you added ACLs to your folder. Could it be that CREATOR OWNER—Full
Control was inherited from the root?
Figure 6.11: Blocking inheritance can be accomplished by clearing the Inherit… check box.
Trying to determine the affect of multiple inherited permissions and explicit permissions on the
local file can be confusing. Windows Server 2003 computers have an additional resource that
will calculate the answer for you. For any user, you can calculate the effective permissions by
simply using a few clicks:
1. Right-click the file or folder, and select Properties.
2. In the resulting window, select the Security tab, click Advanced, and select the Effective
Permissions tab.
3. Click Select, and enter the name of the user for which you want the system to calculate
effective permissions.
4. Click Check Names to check the name against the account database, then click OK.
5. The effective permissions will be displayed, as Figure 6.12 shows.
Chapter 6
Figure 6.12: Displaying a user’s effective permissions for a folder.
CREATOR OWNER is one of many implicit groups in Windows Server 2003. Membership in these
groups cannot be modified by an administrator. Membership in these groups is the result of
something the user is doing. In this case, the user who creates a file or folder is the CREATOR
Additional Permissions and Rights
Several possibilities exist that might change the ability of users to delete files. The File Delete
Child built-in special permission catches everyone. The general rule of permission indicates that
Deny overrides Allow. So if John User is assigned the Deny Delete permission on a file, and the
Users group gets the Full Control permission via inheritance from the parent folder, we might
think that this combination of Allow and Deny permissions will mean that John will not be able
to delete the file. We would be wrong. Instead, the File Delete Child permission comes into play.
It says that groups or users granted Full Control on a folder can delete files and subfolders in that
folder regardless of permissions protecting the files and folders (or even the fact that they may
have no permissions at all on the file). This permission does not give them the ability to delete
folders in subfolders or files. This permission cannot be changed. To prevent this situation, give
the group all permissions except Full Control on the folder, then an explicit Deny Delete on a file
within the folder will prevent the file from being deleted.
Ownership implies the ability to change permission settings. Therefore, if a user is the owner of a
file, the user can change the permissions on the file and give him or herself the ability to delete
the file. By default, if a user creates a file or folder, the user is the owner of the folder. In
addition, if the Change Permission permission is given to a user or group, the user or group can
change the permissions and grant themselves Delete permission. Finally, the Take Ownership
permission can be granted to any user or group. This permission allows the user or group to take
ownership, then, as owner, assign themselves permissions of their choosing on the file or folder.
Take Ownership is also an implicit right of the Administrators group. Thus, administrators can
take ownership of any file, then assign themselves permissions of their own choosing.
Chapter 6
Q. 6.4: What is the difference between user rights, permissions, and
A: This subject is confusing for two reasons. First, because documentation from Microsoft and
others has sometimes ambiguously defined these words. It’s easy to find various interpretations.
Second, because we quite naturally think of these things in everyday terms. If we look them up
in a thesaurus, we find that privilege is a synonym for right. Our gut reaction is that rights and
privileges and maybe even permissions mean the same thing. They’re not.
The first distinction I’ll make is between permissions and rights. Permissions detail the level of
access that a user, computer, or group has to an object. The easiest example is file access
permissions. A group or user account can be given read, write, delete, execute, or other
combinations of permissions that give the group or user various levels of access to a file.
Permissions can also be set on registry keys, printers, and directory objects. Permissions set on
directory objects can also dictate a user’s ability to go far beyond the typical read, modify, and
delete functionality. Directory object permissions include such things as resetting a password and
unlocking an account. These permissions are sometimes hard to reconcile with our definition
because we tend to think of them in terms of rights granted to administrators in previous versions
of Windows. If you have trouble, just remember that permissions change access to objects. When
you reset the password of a user account, you are manipulating one characteristic of that object,
much as you might change the attributes of a file to read only.
Rights dictate broad ability to manage or access systems. A right enables some system-wide, or
perhaps even domain- or forest-wide, ability. Examples of rights are the ability to logon or shut
down a system remotely. In Windows 2000 (Win2K) and Windows Server 2003, the user rights
category is a broad category that is divided into logon rights and privileges.
The sheer number of permissions makes the topic too broad to discuss in detail in this Q&A.
Permission are expandable, as new permission may be created for objects within the Active
Directory (AD), and new objects may be added to the directory. User rights, however, are finite.
It’s important to get a firm understanding of what they are. User rights, which consist of logon
rights and privileges, are configured in the User Rights section of the local security policy (see
Figure 6.13) of a standalone Windows Server 2003 server or Windows XP computer. User rights
for a domain are configured in the default domain controller Group Policy.
Chapter 6
Figure 6.13: Configuring user rights.
Logon Rights
Logon rights affect the ability of a user or computer account to authenticate. Two types of logon
rights exist—allow and deny. Table 6.5 describes logon rights.
Chapter 6
Default Membership
Access this
from a
Affects which user and computer accounts can
connect to another computer from the network.
Although not obvious, also affects the use of
administrative utilities, such as Group Policy, that
use network connections even if accessed from the
local interface of a domain controller. For this
reason, the Enterprise Domain Controllers group is
included here. (If the Everyone group is removed,
even computers cannot access other computers
from the network. Should someone remove the
group Everyone, an administrator will still be able
to manage Group Policy through the GUI and reset
the policy to allow access to administrative tools.
Domain: Administrators,
Authenticated Users, Enterprise
Domain Controllers, Everyone
Workstation/Server: Administrators,
Everyone, Power Users, Backup
Logon as a
batch job
Allows logon using a batch utility
None; if IIS is installed, default IIS
Logon as a
All accounts used for services must have this right.
LocalSystem, LocalService,
Logon locally
Use Ctrl+Alt+Del at the console to logon. Also
known as an interactive logon.
Domain: Administrators, Server
Operators, Account Operators,
Backup Operators, Printer
Workstation/Server: Administrators,
Power Users, Users, Guests,
Backup Operators
Allow logon
Users that can use Terminal Services. (This right
has no effect on systems earlier than Win2K
Service Pack 2—SP2.)
Domain: Administrators
Workstation/Server: Administrator,
Remote Desktop Users
Deny access
to this
from the
Explicitly prevents an account or group from
remotely connecting to this computer across the
Deny log on
as a batch
Explicitly prevent an account from logging on as a
batch job.
Deny log on
as a service
Explicitly prevent an account from being used as a
service account.
Deny logon
Explicitly prevent an account from logging on
Deny logon
Explicitly prevent logon using Terminal Services.
(This right has no effect on systems earlier than
Win2K SP2.)
Table 6.5: Logon rights.
Chapter 6
The remaining user rights are privileges. The following list provides important things to
remember about privileges:
Some privileges might override permissions. For example, the right to back up files and
directories will enable users with this right to back up a file even if there are explicit
permissions on this file that deny access to the user.
Some permissions extend or override privileges. For example, giving a user the Create
Computer permission on an organizational unit (OU) or on the computer container in AD
allows the user to create more than 10 computer accounts in the domain regardless of
whether the user has the Add workstations to domain privilege.
Administrators can regain control of all objects regardless of settings through user rights.
That is, administrators can take ownership of an object and give themselves back any
access they need.
Some privileges are more powerful than others. Take a hint from the default settings.
Those rights assigned only to administrators or not assigned at all are unusually set that
way for a reason.
System process might already have these privileges inherently and do not need to be
assigned to them.
An administrator’s right to take ownership of objects cannot be removed.
Table 6.6 describes privileges.
Default Membership
Act as a part of the
operating system
Process can gain access as user and access all
resources. Calling process can request other
privileges and an identity that is not tracked in the
audit log.
Add workstations
to a domain
Add 10 computers to a domain. A user can also be
given the Create Computer permission on an OU or
computer container in AD. This permission gives
the user the right to add more than 10 computers to
the domain.
Domain: Authenticated users
Workstation/Server: Not
Adjust memory
quotas for a
Use a process that has write property access to
another process (to increase the processor quota of
the process).
Domain: Administrators,
Backup Files and
Make a backup.
Administrators, Server
Operators, Backup
Bypass Traverse
Travers folders to follow a path, even though a user
has no privileges on them (the user cannot list the
contents of the folder, just traverse them).
Domain: Everyone,
Authenticated Users,
Workstation/Servers: Backup
Operators, Users, Power
Users, Everyone,
Change the system
Set the internal clock of the computer.
Domain: Administrators,
Server Operators
Chapter 6
Administrators, Power Users
Create a Pagefile
Create and change the size of a pagefile.
Create a Token
Allows a process to create a token that can then be
used to access resources.
Create Permanent
Shared Objects
Create a directory object.
Debug Programs
Attaché a debugger to any process.
Enable Computer
and User accounts
to be trusted for
Change the Trusted for Delegation setting on a user
or computer account. Doing so allows access in a
multi-tiered application of a front-end process to use
a user’s credentials to run backend processes and
gain access to resources and privileges. The
computer and user account involved must be
trusted for delegation. Use of this service can leave
resources vulnerable to attacks.
Domains: Administrators
Server/Workstation: Not
Force shutdown
from a remote
Remotely shutdown a computer.
Domain: Administrators,
Server Operators
Generate Security
Add entries to the Security log.
Scheduling Priority
Change the scheduling priority of a process.
Load and Unload
Device Drivers
Install/uninstall Plug-and-Play (PnP) device drivers.
(Non PnP device drivers can only be installed or
uninstalled by administrators regardless of this
setting). This privilege might be abused to add
malicious code disguised as a device driver.
Lock Pages in
The OS manages pages in memory, paging some
out as necessary to make room for others. Some
pages are not removed from memory as they are
critical for operations. This privilege can be used to
keep other pages in memory. The OS would then
not be able to remove them. This setting could
make processes that use these pages run faster,
but would lead to degradation of operations as less
memory is available for management by the OS.
Manage Auditing
and Security Log
View and clear the Audit log. Add or remove
auditing of objects, registry keys, files, and folders.
Modify firmware
Change system environmental variables.
Perform volume
maintenance tasks
Run processes such a Disk Defragmenter and Disk
Cleanup (not compatible with Win2K SP2 and
Not defined
Profile single
Monitor non-system processes using Performance
Profile system
Monitor system processes using Performance
Remove computer
Undock portable computer (use Eject from the Start
Chapter 6
from docking
Replace processlevel token
Replace the token that a process started its
processing with. (and thus change its ability to
access resources)
Restore files and
Restore files and folders from backup media.
Administrators, Server
Operators, Backup
Operators, Print Operators,
Account Operators
Shutdown the
Shutdown the system from the console.
Domain: Administrators,
Server Operators, Print
Operators, Account
Server: Administrators,
Power Users, Backup
Workstation: Users, Backup
Operators, Power Users,
Administrators, Everyone
Directory Service
A process can provide directory synchronization
(only relevant on domain controllers).
Take ownership of
files or other
Take ownership of a securable object (such as a
file, folder, registry key, directory object, printers,
processes, threads).
Table 6.6: Privileges.
Q 6.5: Which file activity should be audited and how do I do so?
A: You might want to audit file activity for several reasons. File auditing is used to maintain an
audit trail of activity against a file or files that are critical, sensitive, or otherwise important, to
monitor the activity of a particular user, to determine permissions required for an application to
run, and to log changes to system files. Before you set up file auditing, you should determine
which of these reasons applies, whether the auditing should be temporary or permanent,
understand the proper steps that need to be taken to do so, and have a commitment to review the
information collected in your audit. In addition, you need to take the time to understand exactly
what information this type of audit can reveal. Auditing file activity does not stop someone from
improperly accessing a file—auditing simply records file activity. If that information is to be
useful, time has to be spent reviewing the audit logs and associating the records with behavior or
results. You might be able to determine who modified the file, if you can determine what time
the file was altered and who was accessing it at that time.
Maintaining an Audit Trail
An audit trail details the activity that occurs with respect to some physical item or process. It’s
possible that you will want a round-the-clock record of certain file access in conjunction with the
processing of some activity or that certain files are so critical, that you will always want to know
who touched them and what they did. There are three critical pieces of information to gather.
Chapter 6
You must identify the files. This can be determined by combining the data owners’ knowledge of
the files and processes involved, and by understanding how the processes work on the systems
involved. For example, if you need to record access to files involved in accounts receivable, the
data owners, the Accounts Receivable department, might not even know the exact names of the
files involved. However, the data might be in a SQL Server database, in which case the ability to
audit data access would need to be approached from a database design and audit capability.
Merely auditing access to the database file would be insufficient, as it would not reveal the
activity within the database. You can gather from the data owners what information access needs
to be monitored, but you may need to review the system operation to discover where the data is
actually kept and the details of how it can be monitored. Other cases might prove more
straightforward. For example, the system might include text or other files that can be audited at
the file-system level. Alternatively, you might simply need to record access to sensitive
documents stored directly in the file system. Maintaining an audit trail can be an ongoing activity
or might be required for projects that have a limited timeframe.
Monitoring a User’s Activity
There is no built-in magical button that will allow you to spy on an individual user’s activity on
your Windows Server 2003 network. However, by establishing file auditing, user rights auditing,
and logon auditing, and reviewing the audit logs, you can create a detailed picture. Remember,
though, full accountability for every thing a user has done is not always what is required. (And
might not be practical as it will produce large log files and long analysis times.) It might only be
necessary to note their access to specific files over some timeframe. Such is often the case when
an individual has come under suspicion, or doing so might be part of standard operating
procedure when someone with access to sensitive files is leaving the company or at critical times
such as during quarterly reporting. Although other auditing activities cannot be configured in a
granular manner, file auditing can be set to specifically record the activity of a single user.
Compatibility Resolver
One of the most frequent abuses of administrative authority is the use of membership in the local
Administrators group as the key to application compatibility. Windows NT, Windows 2000
(Win2K), and Windows Server 2003 seek to restrict access to key system files and registry keys.
In many areas, the Administrators group may have Full Control as its assigned privilege, while
ordinary users are only allowed Read. Applications written to publish Microsoft standards do not
require more than the configured access rights. Unfortunately, many applications are not written
to these standards. They might have been written to require Full control over files and registry
keys even when it is not necessary for their function or when it would have been easy to store
information in separate containers where Full control could have been granted without violating
the standard.
Sadly, in most environments, the answer is to simply put the users who need to run the program
in the local Administrators group. (I’ve even seen some cases in which the user is placed in the
Domain Admins group—eek!) Problem solved. Well, the problem of being able to run the
application is solved. Unfortunately, the result of this solution is that too many people have
administrative privileges. Not only does this run the risk of serious compromise of systems and
allow more frequent successful virus infection and Trojan implantation, but it also results in
many hundreds of hours wasted in reconfiguring users systems so that they work after the
exuberant user has dinked with the settings.
Chapter 6
There is an acceptable compromise here. However, it will take some work. The answer is to
determine the files and registry keys that the application needs access to, and assign privileges on
those files and registry keys. Simply create a group, assign the group the privileges, and add
people who must run the application to the group. They now have more access than best practice
recommends for some registry keys and files, however, they do not have that access everywhere,
and they do not have administrative privileges. You can use auditing to determine to which files
and registry keys access is required for an application.
Log Changes in System Files
Ordinary maintenance of systems, including the addition of new services, service packs, and hot
fixes, makes innumerable changes to system files. Although you should keep paper records of
these activities, you cannot always know the exact changes that result from maintenance and you
can’t determine any unauthorized changing of files. Although you might not want to keep
detailed records of every change that affects any file, you can selectively monitor those files or
folders that you consider highly sensitive. (Good candidates are files that the Security Operations
Guide templates baseline.inf and baselineDC.inf set additional security restrictions on. You can
download these templates from
ws/windows2000/staysecure/.) If you set some auditing on systems files, especially on systems
such as domain controllers and on those exposed to the Internet, such as IIS Server, you can
match recorded changes against paper logs and determine whether intrusion attempts are
How to Set Up File Auditing
File Auditing is configured in two steps. First, Object Access auditing must be configured in
Group Policy in Computer Configuration, Windows Settings, Security Settings, Local Policy,
Audit Policy. Next, each file or folder for which you want to audit access must be configured for
auditing. Two procedural items must be considered regardless of the actually step-by-step
process. First, the placement of the Audit policy in the GPO hierarchy must be considered;
second, the affect of inheritance must be considered.
Set Audit Policy
Audit Policy can be set at any level in the GPO hierarchy. Remember that Group Policy settings
are cumulative except where there is a conflict. A specific example that you will need to attend
to is that Audit Policy in the Default Domain Controllers policy is set to No Auditing. Setting the
Audit Policy in the Default Domain Policy will not change that. You must specifically set (or
change to Not Defined) Audit Policy in the Default Domain Controller default policy to audit
activity on domain controllers.
Often, when reviewing the security policy of a company, I find that Object Access auditing has not
been turned on. The reason? They erroneously believe that magically all object access is then turned
on and their drives will fill up with audit records. Nothing could be further from the truth. Auditing must
be specifically set on the objects themselves before audit records will be produced.
Chapter 6
After you have determined which files you want to audit, to audit access to files and folders, you
must first set the Object Access condition in the Audit Policy of the GPO (see Figure 6.14). Set
the policy to record Success and Failure. The true measure of what actually is recorded is
determined when the settings are made at the file and folder level.
Figure 6.14: Turning on auditing for object access.
Set SACLs on Files and Folders
SACLs are the instructions configured for auditing object access. After the audit policy has been
correctly set, you must set auditing for each folder or file you want to audit. SACL settings on a
folder can be inherited by the files within that folder, depending on its configuration. To set
SACLs, navigate to the folder or file in Windows Explorer, right-click the object, and select
Properties. Select the Security tab, click Advanced, click Auditing, and click Add to add a
SACL. Enter the name of a user or group to audit, and click OK. In the Apply Onto text box,
select appropriately depending on inheritance requirements. In the Auditing Entry for dialog box,
select the access level to audit for, and select Success and/or Failure, then click OK (see Figure
6.15). Click OK again.
Chapter 6
Figure 6.15: Set access to audit for.
Determine whether you want to clear the Allow all inheritable auditing entries to propagate to
this object and all child objects. Include these with entries explicitly defined here check box, then
click OK (see Figure 6.16). And click OK again to close the Properties page.
Chapter 6
Figure 6.16: Determine changes to inheritance from above.
SACL Inheritance
Like DACLs, SACLs can be inherited and can be blocked from subfolders. Three methods of
affecting inheritance exist. First, when setting the SACL, you can choose to limit or expand its
affect. When a SACL is applied to a folder, the Apply Onto drop-down box in the auditing entry
page for each SACL lets you select one of the following:
This folder, subfolders and files
This folder only
This folder and subfolders
This folder and files
Subfolders and files only
Subfolders only
Files only
The default setting is This folder, subfolders and files. Thus, all files and folders lower in the
hierarchy than this folder will have the same SACL applied. If such is not your intent, you must
choose one of the other possibilities.
Chapter 6
Second, when configuring the SACL, you have the opportunity to clear the Allow all inheritable
auditing entries to propagate to this object and all child objects. Include these with entries
explicitly defined here check box. If you clear this check box, changes made to SACLs above
this folder’s hierarchy will not affect it. This setting is also available when setting a SACL
specifically on a single file. In this way, you have granular control over which settings are
applied where.
The Include these with entries explicitly defined here check box for Window Server 2003 is different
then in Win2K. In Windows Server 2003, new audit settings created above the file in the hierarch
might either propagate to the folder and add to the settings already there, or can be prevented from
having any affect. Changes made above the file or folder in the hierarchy will NOT overwrite settings
made here.
Q 6.6: What impact do the Kerberos policy settings have?
A: Kerberos policy settings are established in the default Group Policy Object (GPO) for the
domain. Current settings can be viewed or modified in the Computer Configuration, Windows
Settings, Security Settings, Account Policy, Kerberos Policy container (see Figure 6.17).
Figure 6.17: Kerberos policy for the domain.
To understand these settings and before considering modifications, it is necessary to understand
how the Kerberos protocol is used in Windows 2000 (Win2K) for authentication.
Chapter 6
The Kerberos Process
The Kerberos standard is defined in Request for Comments (RFC) 1510 and the Win2K
implementation follows the standard. Unlike traditional challenge and response authentication
protocols, Kerberos was designed to work in an assumed hostile environment and has several
built-in protective mechanisms that work to make it a more secure protocol. Two major subprotocols form the basis of the algorithm: the Ticket Granting Service and the Authentication
Authentication Processing—the Ticket Granting Service
First the user is authenticated. Credentials are presented and validated against stored data. The
successful completion of this phase results in the granting of a Ticket Granting Ticket (TGT). In
Win2K, this ticket is often referred to as the user ticket. The follow steps detail this process: The
user presses Ctrl+Alt+Delete and is presented the logon screen. The user enters his or her ID and
password. The Kerberos client modifies the entered password and uses it to encrypt a
timestamp—the current time on the client system. This information, along with a clear-text copy
of the timestamp is sent to the Kerberos Key Distribution Center (KDC). In Win2K and
Windows Server 2003, the KDC resides on every domain controller. When a client is booted, it
uses DNS to locate an available domain controller.
The KDC examines the clear-text timestamp. If the time varies from the time on the KDC by
more than the Maximum tolerance for computer clock synchronization (referred to as the time
skew), the authentication request is rejected. Otherwise, the KDC uses its copy of the user’s
password from its account database to encrypt the clear-text timestamp. It then compares its
encrypted timestamp with the one provided by the client. If the two match, the client is
The KDC prepares the TGT (the user ticket). It includes information about the client and the
domain and is signed by the domain controller. Portions of the TGT are encrypted using the
KDC’s password, and portions are encrypted using the client’s password. The TGT is sent to the
client, and the client examines the TGT and stores it in its cache.
After this process, often referred to as pre-authentication, the client does not yet have a desktop.
Access to any computer service must be obtained by presenting a valid service ticket to the service.
After the TGT or user ticket is obtained, this process continues automatically as part of the logon
process. The TGT is also used when the user requests access to network services. Use of the TGT
to obtain a service ticket is transparent to the user.
Service Ticket Generation—the Authentication Service
After the client receives the TGT, a service ticket must be obtained before the user has access to
his or her desktop. To get a service ticket, the following process occurs: The client submits the
TGT, an authenticator (a new timestamp encrypted with the user password and a clear-text copy
of the timestamp), and a request for a service ticket for the desktop to the KDC. The KDC
examines the authenticator, checking against its own time to ensure that any time difference falls
within the allowed time skew, and encrypts the timestamp with its own copy of the user
password for comparison with the provided client-encrypted timestamp. If everything is OK, the
KDC prepares a service ticket. The ticket includes information about the client and the resource
Chapter 6
(the computer). Some of the information is encrypted using the password of the client, and some
using the password of the computer. The service ticket is returned to the client.
Because portions of the ticket are signed using the password of the local computer, the computer
can establish its authenticity. The service ticket is also proof to the computer that the client has
authenticated to the KDC.
At this point, the client has authenticated to the domain and received a TGT to be used for proving it
has authenticated and to request service tickets for access to network resources. The client has
requested and received a service ticket that proves to the logon computer that the client has
authenticated to the network. However, nothing so far described grants the user authorization to
access that resource. The reason is that in order to keep the process description simple, I have left
out a portion of the process.
Before any resource on a Win2K, Windows XP, Windows NT, or Windows Server 2003
computer can be accessed, appropriate authorization to do so must be obtained. When the NT
LAN Manager protocol is used, a list of SIDs identifying the user account and the user’s
memberships in domain groups and rights is returned to the client during logon. In addition, local
group membership and privileges is gathered at this time. This information is gathered into an
access token, which can be used by the system to compare with required user or group
memberships assigned in resource discretionary access control lists (DACLs). How is this
information obtained when the Kerberos protocol is used?
The Kerberos protocol is an authentication protocol. However, the standard identifies an
authorization field in the ticket and describes it as the location to be used by the implementer of
the protocol to store authorization data. In Win2K and Windows Server 2003, when the TGT
(user) ticket is prepared by the KDC, the authorization information is placed in the authorization
field. Thus, the data travels with the ticket back to the client. When a request for a service ticket
is made, because the TGT accompanies this request, the authorization data is also available to be
included in the authorization field of the service ticket.
So, in our logon scenario, when the service ticket is received by the client system, the user’s
authorization data for the domain is available. The local group memberships and privileges on
the local machine can be retrieved from the local SAM, and an access token can be built. At this
point, the normal process can be used to determine the user’s privileges on the system. This
information is added to the access token and the user obtains his or her desktop. User actions and
requests for local resources can be examined in the normal manner using the access token.
The Kerberos Policy
Armed with knowledge of the Kerberos process, we can now examine the Kerberos policy and
comment on the effect of modifying it.
Chapter 6
Enforce User Logon Restrictions (Enabled)—When enabled, this setting requires that the
KDC validates every request for a session ticket against the user rights policy of the
target computer. In other words, if the target computer user rights policy denies the user
the right to access this computer from the network, and this Kerberos policy is disabled,
the check is not made and a service ticket is issued. When this policy is enforced, users
must have the right to logon locally if the requested service is located on the local
computer, and the right to access this computer from the network if the resource is
located on another computer. Administrators may be tempted to disable this policy as this
processing takes more time. However, disabling the policy weakens security and should
not be done.
Maximum lifetime for service ticket (600 minutes)—The service ticket is issued to the
client and stored in the client’s cache. It can be reused if future requests are made for the
same network resource. However, there is no reason for the client to store this ticket
forever, and doing so would not be a good idea. The longer tickets are stored, the more
possibility there is that a malicious user might capture and reuse the ticket. Setting the
ticket expiration date is part of the Kerberos specification. By making the default 600
minutes (10 hours), the ticket is valid longer than the typical user session. (After the
typical user day of 8 hours, the user should be logging off, which will also delete the
tickets). However, should the ticket expire, a new request for a new service ticket is made
in the background. The user will not be aware of this request. Changing the number of
minutes that this ticket is valid will have no obvious effect that a user can detect;
however, making it excessively large serves no purpose and may weaken security.
Shortening the time period may gain little in the way of security except in a very hostile
environment. If you chose to change the setting, it must be at least 10 minutes and less
than or equal to the setting of the maximum lifetime for a user ticket.
Maximum lifetime for user ticket (10 hours)—Likewise, the user ticket must also expire
and the time is set at a reasonable level. All arguments and process descriptions given for
the service ticket are valid. If the user ticket does expire, the client can generate a request
for ticket renewal or for a new ticket without requiring action from the user.
Maximum lifetime for user ticket renewal (7 days)—A TGT may be renewed. However,
this setting will limit to a number of days the renewal period. If the renewal timeframe is
exceeded, a new request must be made (that is, a ticket that is older than 7 days cannot be
renewed, a new ticket must be generated.
Maximum tolerance for computer clock synchronization (5 minutes)—This setting
configures is the maximum time difference between the client system and the KDC. This
setting assists Kerberos in being resistant to replay attacks. Should an attacker capture the
TGT, in addition to decrypting the ticket data and submitting its own request for a service
ticket, the attacker would have to create an authenticator. Without a valid password for
this specific account, doing so would be impossible. However, the attacker might attempt
to reuse the authenticator captured with the ticket. If this is done, the reasoning is that the
time difference will now exceed the allowable skew time and the request will be denied.
Ticket expiration date has no effect on the current connection to or use of a service.
Chapter 7
Chapter 7: Remote Access
Q 7.1: If I allow the use of Remote Assistance, what prevents
unauthorized users from taking control of a user’s desktop or server?
A: Remote Assistance is a feature of Windows Server 2003 Server and Windows XP that allows
remote control over a desktop session. Rest assured that there are controls that you can use to
ensure that only authorized individuals and computers can participate. Let’s take a brief tour of
the Remote Assistance possibilities, then I’ll explain the controls and what I consider to be best
Remote Assistance is NOT the same as Remote Desktop!
First, Remote Assistance is NOT the same as Remote Desktop (this point bears repeating).
Remote Desktop provides an administrator with the ability to remotely connect to a computer for
troubleshooting or management purposes or to access the network remotely. A Remote Desktop
session does not allow a user present at the remote system to see the activity on the screen. The
machine is locked and cannot be accessed while the remote session is active.
Unlike the Remote Desktop, which starts a separate session, Remote Assistance allows the
participation in an existing session by an individual logged on to the system (called the novice)
and someone (called the expert) from a remote computer. Both novice and expert can see what’s
happening on the novice’s computer, and both can participate. The expert can watch the novice
to see a demonstration of a problem, diagnose and potentially fix a problem, and use the session
for instructing the novice about some difficult task. Peers can help each other.
Although the first use of Remote Assistance may be that of a computer expert helping a computer
novice, administrators can also use Remote Assistance to share the troubleshooting of difficult
system problems and obtain help in configuration and maintenance.
Sounds like something too good to be true? I’ll be the first to admit that I had my reservations
about such a process not fulfilling its promises and, at the same time, about keeping out
unwanted assistance. After all, what ordinary user in his or her right mind could resist asking all
kinds of folks for help over the Internet, never realizing that the user is opening up his or her
system to those whose motives are not to help. Isn’t soliciting for Remote Assistance kind of like
inviting in a carjacker when you’re driving in a strange city and you’ve lost your way?
Let’s not ignore the huge benefits of this service because we’re too lazy to learn how to control
and secure it. The answer, as usual, lies in the correct application of Group Policy. If Group
Policy is not configured, the default setting lets a user control Remote Assistance through the
Control Panel.
Chapter 7
Soliciting Remote Assistance
In this scenario, a user with a problem asks for help. Default settings allow the user to make that
request of anyone. The user can do so via Instant Messaging, email, or by saving a request in a
file and getting that file to someone the user trusts. The “expert,” upon receiving the information,
has merely to follow instructions to start the Remote Assistance application and connect to the
novice machine. The novice then has the opportunity to accept or reject the session. If the user
accepts, the initial view of the novices screen is just that, a view. If, however, no limitations have
been placed on the service, the expert can, with the click of a button, attempt to take control. The
novice, of course, can accept or reject the request.
This back and forth communication gives us a hint at the control we can place over these types of
sessions. A Remote Assistance session can be either view only or allow remote control.
Although the choice exists during the session to refuse the expert’s request for control, this
choice and others can be configured via settings on the Remote tab of the System Control Panel
applet, as Figure 7.1 shows. Clicking Advanced on this tab, presents the following choices:
Allow Remote Assistance invitations be sent from this computer—Determines whether
the user of this system can use Remote Assistance.
Allow users to connect remotely to this computer—Determines whether to allow or deny
remote control once connected.
Set the maximum amount of time invitations can remain open (in days, minutes, and
Chapter 7
Figure 7.1: Control Panel choices for Remote Assistance.
However useful this function may be, allowing a user to control it via Control Panel is not
realistic. Although many users are capable of making good choices in choosing their mentors,
others have no common sense at all. Likewise, well-meaning but ill-advised “experts” can do
much harm.
Group Policy does offer a solution and allows different control for different computers and can
be centrally managed. By default, Remote Assistance settings in Group Policy are not configured
and therefore have no impact on the settings made in Control Panel. However, like other Group
Policy settings, once you set Group Policy settings, they will override any local settings.
Group Policy controls for Remote Assistance are located under Computer
Settings\Administrative Templates\System\Remote Assistance. To control Remote Assistance
solicitations, select the Solicited Remote Assistance node, and select the settings appropriately.
In Figure 7.2, Remote Assistance, including remote control, is allowed, but invitations are only
valid for 3 hours.
Chapter 7
Figure 7.2: Group Policy controls for soliciting Remote Assistance.
A final note about security: Part of the invitation process lets the novice insist that the expert use
a password. The novice creates the session password and must communicate it to the expert. The
Remote Assistance invitation does not include the password automatically. Password protection
is a good feature, but users must be trained in creating strong passwords, and above all, in
communicating the password somehow other than by adding it to the Remote Assistance
invitation or a messenger or other chat session that others may read. I can also imagine the
scenario in which the novice enters a password but does not communicate it to the expert. When
the expert asks the novice for the password, the novice has already forgotten it.
Offering Remote Assistance
Just as some users will offer up control of their systems to anyone who will respond, others who
can benefit from expert assistance will have difficulty sending out a request. After all, what if the
help they need is so basic that they can’t follow simple instructions? And what if your desktop
support model doesn’t include the ability to respond to huge numbers of email requests for help?
What if you don’t choose the exposure that allowing emailed invitations provides?
Chapter 7
When a lot of requests for assistance flood the support desk via Windows XP’s automated solicited
assistance invitations, some may time out before help can be given. To prevent this behavior, users
can set long-term invitations. These long-term invitations increase the risk of compromise. To reduce
the exposure of long-term invitations, change your Remote Assistance model from allowing Solicit
Assistance to Offer Assistance.
There is a solution—experts can Offer Assistance. In this scenario, support personnel can request
access to view and chat with the desktop user. Once again, the novice is required to accept, and,
if asked, to confirm that the expert can take control. This solution solves several problems. First,
it is not configurable from Control Panel, only through Group Policy. Second, approved user
accounts must be listed in the Group Policy that applies to the computer. Third, this approach
allows finer tuned control. A novice’s request may either time out or has to be set to lengthy time
periods to ensure that support personnel will get to them. This option may be unacceptable—the
longer the control option is open, the more time a malicious attempt to take control may occur.
Authentication of the expert is required, and domain accounts are used. There is no need for a
hastily created session password to be created and somehow communicated to the expert.
Finally, Offer Assistance can be enabled even if Solicit Assistance is disabled. You can create an
environment in which frivolous, unauthorized, and potentially dangerous remote control sessions
cannot occur, and yet benefit from being able to remotely control the novice’s desktop through
an authenticated and approved connection.
The settings available in Group Policy, which Figure 7.3 show, are
Permit remote control of this computer: Allow helpers to remotely control the
computer—An authorized user can offer assistance and, if accepted, view, chat, and take
control of the computer.
Permit remote control of this computer: Allow helpers to only view the computer—An
authorized user can offer assistance and, if accepted, view and chat.
Helpers—A list of domain users who are authorized to offer remote assistance to this
computer. The helper’s name must be put in domainname\username or
[email protected] format. At this point, no check is made to determine whether
this account exists within the domain; however, when an attempt is made to offer
assistance, access is denied if the name does not exist. Logon credentials of the logged on
user are automatically provided when the Offer Assistance tool is used.
Chapter 7
Figure 7.3: Group Policy Offer Assistance controls.
The Ultimate in Remote Assistance Risk Avoidance
Of course, security settings aside, you might want to prevent the use of Remote Assistance in
your network or in specific domains or organizational units (OUs). Although you can use the
disable check box in the Group Policy Remote Assistance object, the easiest and most absolute
way to deny the use of Remote Assistance is to disable the Remote Assistance service. Although
you can do so on an individual machine, use the Services container in Group Policy to push this
setting to multiple systems. Disabling the service has the added bonus of ensuring that some asyet-unknown security vulnerability associated with this service won’t be allowed and reduces the
load on the processor. Remember, one of the tenets of information security is to only run those
processes that are essential for the operations at hand. If you do not intend to control and manage
Remote Assistance, disable the service.
Chapter 7
Q 7:2: What is the Session Initiation Protocol?
A: Session Initiation Protocol (SIP) is an emerging Internet standard described in Request for
Comments (RFC) 2543. The SIP signaling protocol is used to establish, create, and manage
sessions between communication devices such as PCs, PDAs, and smart phones. It provides the
benefits of presence (who is online and what is their status), notification (you’ve got a call),
request (do you want this connection?), and mobility (can find you anywhere on any device).
Many of you are familiar with Microsoft’s Messenger and other instant messaging (IM) products
that provide these features. SIP, however, can be used for much, much more. Because developers
are able to depend on devices built to the standard, applications such as conferencing, customer
relationship management (CRM), call centers, and others yet unimagined can be built. SIP
allows the integration of location via Universal Resource Identifier (URI—defined in RFC 2396)
and allows the integration of messaging, multimedia conferences, and telephony. The
components of SIP are:
URI—Uniquely identifies users
Call_ID—Globally unique identifier (GUID) that identifies a particular conversation. It
includes an undue cryptographically random number generated by SIP and the URI of the
Client software (such as IMs)
Registration servers—Store URIs.
Proxies—To pass on communications.
Gateways—Integrate with older phone-based communication systems and with the older
h.323 telephony standard.
Server and gateway products are available from Tellme, Webley Systems, WorldCom, and Level3
Communications. Microsoft Windows Server 2003 will also provide SIP components.
Although the ability to communicate across the Internet in real time to share files, applications,
and video is nice, there are some serious security concerns. How can you ensure that only those
invited to the conference can join? Can conversations and shared documents be kept private?
How can you be sure that the participants are who they say they are? What kind of information
might an attacker gain by tracing how and who is talking to whom? These concerns have
answers within the standard.
Internet Engineering Task Force RFC SIP Security
Four security issues are addressed in the SIP specification:
Message integrity, authorization, and authentication
Message privacy
Route privacy
Identity privacy
Chapter 7
Message Integrity, Authorization, and Authentication
In a perfect world, accident or attack would never modify the contents of a message between
sender and recipient and invalid attempts to redirect messages or spuriously terminate them
would not be an issue. Because the perfect world does not exist contingencies must be made to
ensure message integrity and validate users, computers, and requests. Checksums and
timestamps can be used to ensure message integrity. The checksum ensures that the message has
not changed, and the timestamp helps to prevent successful replay of attacks. Likewise,
authentication mechanisms can be used to prove the identity of the proxy, sender, and recipient.
In addition to Secure Sockets Layer (SSL), SIP supports HTTP authentication mechanisms such
as basic and digest. Pretty good privacy (PGP) can also be used.
After identification of user or proxy, authorization is checked. Authorization can be set to
include the client-side rights of the caller (sender) to call, type of call, entry to conference, or use
of advanced features such as application sharing. Authorization to use specific proxies for
particular purposes can also be set and based on identification of caller. IPSec can be used for
authentication between client and proxy and proxy to proxy.
Responses that may redirect calls or terminate them should be authenticated. Such calls, if not
validated, can lead to session hijack, premature termination, and denial of service.
Unauthenticated responses will be dropped.
Message Privacy
Session requests, responses, and message bodies might include sensitive information. Message
bodies might also include copies of encryption keys. SIP systems can encrypt the message body
and those parts of the message header that are not necessary for routing or identification. End-toend encryption is accomplished by using the user keys.
Although a common explanation of public key cryptography explains that the recipient’s public key is
used to encrypt the message so that the recipient’s private key can be used to read it, such is not
usually the case. Instead, to improve performance, the message is usually encrypted using a session
key, which is then encrypted with the public key of the recipient. To decrypt the encrypted session
key, the private key of the recipient is used. Then the session key can be used to decrypt the
Should Alice, for example, send a secure IM message to Bob, the message is first split into two
parts—the header fields that are to be encrypted and the message body make one part and the
other part is a short header that remains in clear text. A session key may be used to encrypt the
header fields and message body. Next, Bob’s public key is used to encrypt the session key. The
encryption field of the header is used to specify the type of encryption used, and information
about which key to be used in the response is included. Bob’s client receives the message and
uses Bob’s private key to decrypt the session key, which then is used to decrypt the message. If
Bob sends a response, it should be encrypted with a session key and Alice’s public key used to
encrypt the session key.
Because Alice may have many public key pairs, the secure IM message will let Bob know which
public key to use. The public key may be included in the message as well. This inclusion avoids
confusion. When Bob’s response, encrypted with Alice’s public key, returns, Alice’s client won’t have
to guess which of her private keys to use to decrypt it.
Chapter 7
Typically, encryption will occur at the client, but implementation may provide encryption by the
SIP proxy if clients are not capable or if administrative policy requires enforcement of security
policies. Users of end-to-end encryption should note that it only provides privacy—there is no
guarantee that messages come from the sender indicated.
Route Privacy
Within the SIP message header, the VIA field includes routing information. VIA is not an
acronym, it merely serves to indicate that the field holds information about how the data should
go (it should go via the route included). Hop by hop, additional VIA statements are added until
the end of a message route where the path taken is revealed fully within the message. This
information can be used by the response, as each VIA statement can be used to find the way back
to the previous routing device. One by one, addresses are followed until the response is delivered
back to the sender.
This type of routing information can provide useful information to an attacker, and so hop-byhop encryption of VIA fields is also possible. During this process, the request Hide field is used
to request that VIA fields are hidden from subsequent proxies. Each proxy encrypts the VIA field
address that identifies the previous proxy. The proxy can choose the mechanism because only
that proxy will decrypt it. The VIA header field is cached along with an association to the header
field. The index into the cache is placed into the VIA header field. It then adds its own address to
the VIA field, maintains the Hide field (instructing the next proxy to encrypt this new
information), and passes the message on. At each proxy, the only information that can be
determined is the identification of the previous hop.
When a response must be returned, the client has the address of the last proxy in the chain. This
proxy takes the address from its cache, decrypts the VIA field information (because it originally
encrypted it) to discover where it must pass the message. The process is repeated at the next
proxy and so on until the response has returned to the originator of the request.
Because route hiding of this type may not prevent message looping, additional information is
added to the VIA field so that the proxy can tell that it has seen the message before. This ID
obviously cannot be the proxy name as that would not hide the route. Instead, a secret key,
timestamp, and checksum is used. A checksum can detect that the decryption returned correct
information and the timestamp can help to prevent a replay attack.
To ensure that VIA information continues to be encrypted proxy by proxy, messages must be sent to
trusted proxies. A trusted proxy is one which is controlled by some party that you trust to configure for
the security controlled mandated by your policy. This could be a proxy owned by your organization or
that of a business partner or associate with whom mutual trust relationships have been developed.
Chapter 7
Identity Privacy
In addition to route and message privacy, there is often reason to hide who is talking to whom.
You can do so by using hop-to-hop encryption. IPSec, Transparent LAN service (TLS) or some
other transport or network layer encryption may be used to encrypt messages as they travel
between proxies. The message may be unencrypted as it travels from sender to proxy and from
proxy to recipient. Hop-to-hop privacy may also be used with end-to-end encryption. Figure 7.4
illustrates the difference between end-to-end and hop-to-hop encryption. In the top half of the
figure, all communications from the first PC to the last are encrypted (end-to-end encryption).
The bottom half of the figure represents hop-to-hop encryption. Data is only encrypted between
any two points on the path.
Figure 7.4: End-to-end encryption vs. hop-to-hop encryption.
Miscellaneous Uses of Cryptography
Cryptography is used throughout the specification to ensure privacy or to help aid in mitigating
attack. Many users will have multiple devices and yet a single SIP URL (the user address or
location registered for the user). A single SIP URL ensures that the user can be located wherever
he or she may be and may use any device desired or available. Smart phones, for example, may
be more convenient in airport terminals if the message is text, while PCs are more useful for
multimedia conferencing. However, the possibility for misdirection by chance or by malicious
action is possible. To ensure consistent communication and to mitigate the possibility of a
hijacked session, a tag in the from section of the message header is used. This tag is
cryptographically random and globally unique and identifies the return of responses to the
correct device.
Chapter 7
Microsoft Implementation
You might have already recognized some of the SIP communication specifications in Messenger
and other IM applications. Windows Server 2003 Messenger Service integrates SIP on the
Internet, and Microsoft Exchange 2000 Instant Messaging Server utilizes SIP on the intranet.
Although security implementation is lacking in current versions of Messenger, SIP is integrated
into Windows Server 2003 to provide secure real-time communication technology. Real-time
communication is based on the Real Time Protocol (RTP) for Voice over IP (VoIP).
Microsoft RTC Server is incorporated in Windows Server 2003 as a basic infrastructure service
and is fully complaint with the IETF standard. Standard services, a SIP proxy, and registration
extension module are available by default, and a rich API is present so that programmers may
build even more exotic applications. The registration extension module will register users and
track online information. Messaging can be federated across boundaries, and therefore will be
available to provide secure communications between forests. Authentication can be configured
within the property pages of the RTC Server, as Figure 7.5 shows.
Figure 7.5: Authentication can be configured on the property pages of the RTC Server.
Chapter 7
Think of the possibilities! Microsoft mentions real-time help and support via phone available at the
click of a Help button, purchasing applications that can access and retrieve order status in real-time
and make that information available to the customer, and network messaging to users—say an
instant notification that the Exchange server is going down for maintenance. But what can you
envision? I think of instant alerts to my pager about my flight status so that I don’t run thorough the
airport only to discover that the flight has been delayed or cancelled. Or maybe notice that my room
at the hotel is available for early check-in and that it’s non-smoking and on the quiet side of the hotel
as I requested. What are your ideas?
For more information about SIP, check out the following Web sites:
Q 7.3: I want to make use of Terminal Server Remote Administration
mode. What can I do to improve security when using this facility over
the Internet?
A: Terminal Services in Remote Administration mode, called Remote Desktop for
Administration in Windows Server 2003, is automatically installed and a TCP/IP connection is
configured on all Windows Server 2003 servers. Remote administration with this tool, however,
is not enabled by default. After it is enabled, only members of the Administrators group have
permission to connect (but they can connect only two at a time). These default security settings
are useful. Connections should only be enabled after you have decided upon and strengthened
security for Remote Desktop for Administration.
Remote administration is enabled by selecting the Allow users to connect remotely to this computer
check box on the Remote tab of Control Panel System applet, which Figure 7.6 shows.
Chapter 7
Figure 7.6: Enabling Remote Desktop for Administration.
Another good default security setting is that an administrator cannot access Remote Desktop for
Administration if his or her account has a null/blank password. This setting is a default Group
Policy setting that can be disabled. Don’t disable it. Monitor this setting in Group Policy
(Computer Configuration, Security Settings, Local Policies, Security Option, Limit local account
use of blank passwords to console logon only) and make sure it stays enabled.
Several additional settings and tools can be used to improve security including Group Policy, the
local Terminal Server configuration tool, and local client settings. In addition, don’t forget
regular system hardening practices. Defense in-depth, or the combination of many layers of
security, will assist you in protecting this system. Realize, however, that when you enable remote
access for administrative purpose, you are exposing the system to additional risk. This risk must
be weighed against the benefit of remote administration and the impracticality of administering
all servers from the console.
Windows Server 2003 Administrative Tools, the collection of consoles developed to administer
Windows Server 2003 computers, and the selection of Microsoft Management Console (MMC) snapins, are designed with remote administration in mind. These tools can be used to remotely administer
Windows Server 2003 servers. The difference between using these tools and using Remote Desktop
for Administration is that the Remote Desktop tool establishes a remote control session directly with
the Windows Server 2003 server. Rather than managing multiple tools that must be pointed at a
particular server, the Remote Desktop tool lets you work as if you are sitting at the Windows Server
2003 server console.
Chapter 7
Using the Terminal Servers Configuration Console
The Terminal Servers Configuration console can be used to modify the default settings for
Remote Desktop for Administration. To do so, from the Start menu, select Terminal Services
Configuration, Connections. Right-click the RDP-TCP connection, and click Properties. On the
general page, change the encryption level to high. All data that transfers between client and
server will be at the server’s highest encryption level. Currently that is set to 128 bits. The client
must be able to use 128 bits or it will not be able to connect.
On the Logon Settings page, select the Always prompt for password check box. The Remote
Desktop connection has a setting that allows the user to save his or her password for the
connection. This setting would allow anyone who was able to log on to the local computer to
access the remote system through the console. Thus, the setting isn’t a good idea as it allows an
attacker to sidestep access controls on the remote system. Setting the connection properties to
prompt for password ensures that the user logs on each time, regardless of the client setting.
On the Sessions tab, which Figure 7.7 shows, note that by default, user accounts are set to
Disconnect from session if a session limit is reached or connection is broken (the option is
greyed out in the figure). This setting is a good idea if systems administration tasks are running
and a connection is broken as a result of network problems. The task will continue to run while
the session is in a disconnected state, and the administrator can reconnect. The alternative, End
session, would stop the running process with unpredictable results.
Figure 7.7: Be sure that if a network connection is broken the session is not ended.
Chapter 7
Set Active session limit and Idle session limit according to the usage of these sessions. Limiting
active sessions is probably not a good idea, as it will prevent some administrative chores from
getting done. Limiting an idle session is useful. If you are engaged in a session and leave your
computer, anyone could use the open session to the server—a session open with administrative
privileges. Setting an idle timeout may prevent such an occurrence; at least it will limit the
exposure. This setting will also help in a situation in which multiple administrators want to
connect. If two administrators are connected, yet not using the session, the third administrator
cannot connect.
For centralized control, on the Client Settings tab, click to clear the Use connection settings from
user settings check box, then adjust settings to disable items that you might not want to expose to
remote administration (such as printer and drive mapping, COM, serial and line printer
terminal—LPT—port mapping).
Remote Desktop Port Settings
To allow use of the Remote Desktop for Administration tool over the Internet, TCP port 3389
must be open on the firewall or an alternative port must be assigned to the service. If possible,
configure the firewall to allow the 3389 port connection only to an authenticated user. If you will
be limiting the computers, limit the connections to the port on those specific computers. Block
connections to that port on sensitive systems by using IPSec.
Changing the port used by Remote Desktop requires a registry setting and an adjustment when
using the client tool. The registry setting is located at
\RDP-Tcp\PortNumber. To access the server using the new setting, type the new port number
after the IP address of the computer to which you want to connect. If the new port is 8098, and
the IP address of the server is, the new IP address and port combination will be
Client Settings
You configure the client settings on the Sessions and Remote control tabs of the user account.
The Sessions tab settings mirror those in Terminal Services Configuration. Remember, however,
that Terminal Services Configuration settings override those set for the individual user. The
Remote control tab settings establish whether this account can be remotely controlled.
Administrative accounts and user accounts that are used by administrators for Remote Desktop
for Administration should not be configured to allow remote control. Thus, you need to clear the
Enable remote control check box, as Figure 7.8 shows.
Chapter 7
Figure 7.8: Disable remote control for administrative users.
In addition to settings that enhance security, strong policies and procedures will increase security
as well. Be sure to consider which administrators should be allowed to perform remote
administration using Remote Desktop for Administration. You might want to have a policy that
designates those that can remotely administer servers from the local intranet, those that can
remotely administer servers from the Internet (can your firewall authenticate remote
connections?), and those that are not allowed to use this method of administration.
By default only members of the Administrators group can use Remote Desktop for
Administration; however, rather than log on as administrator, the best practice is to log on as an
ordinary user to make the connection, then use Runas to perform administrative tasks as
necessary. You can accomplish by adding your normal user account to the Remote Desktop
Users Group on the computer to which you want to connect. Members of the Remote Desktop
Users Group have the right to log on remotely. There are those who might argue that the sole
purpose of connecting is to do administrative tasks, so the use of Runas is not efficient in this
situation. However, by connecting as an ordinary user, the administrator prevents access to an
administrator-level connection if the administrator leaves the connection up and unattended. Any
account with membership in the Administrators group should have a strong password; make sure
that your normal user account has one as well.
Chapter 7
Be very aware of the possibility of other administrators who may be connected to the same
server that you are. The Remote Desktop connection is not meant to provide a multi-user session,
and will not protect you from possibly destructive acts that result when two administrators
attempt to work with the same subsystem. Although only two Remote Desktop connections are
allowed, a local administrator could also be present at the console. You can use the Terminal
Services Manager tool or the query user command to detect multiple sessions. Using the query
user command without arguments will return the names of users connected to the same computer
to which you’re connected, as Figure 7.9 shows.
Figure 7.9: Using the query user command.
You should avoid performing remote control administrative tasks that require a reboot unless
you have a way to physically intervene if necessary (for example, a floppy disk in the drive
prevents the server from rebooting). Check server event logs while connected. Pop-up messages
will not be available across the terminal session. Checking event logs will keep you on top of
server warnings and errors.
Terminal Services Group Policy Settings
You can control Remote Desktop for Administration settings via Group Policy. This practice is a
great way to administer the settings for all servers that you want to administer in this manner, but
even a server in a workgroup can benefit from this approach. Settings that affect Remote
Desktop are located in both User and Computer configuration areas of Group Policy under
Administrative Templates, Windows Components, Terminal Services. Important areas for
settings include:
Computer: Encryption and Security—Prompt client for password and set client
encryption level.
Computer : Sessions—Time settings for disconnected sessions, active sessions, active but
idle sessions, and reconnection as well as terminating a session when time limits are
Chapter 7
User: Sessions—Mirrors compute sessions, but are applicable for only the users who
receive this policy; also includes remote control settings.
If multiple settings are used (Group Policy, client settings, Local Security Policy, and Terminal
Services Configuration), conflicts are resolved according to the following order of precedence:
Local client settings will be overridden by user-level policy.
User level policy is overridden by the Terminal Services Configuration Tool.
User Group Policies will override all except Computer Group Policies.
Remote Desktop Web Connection
The Remote Desktop Web connection consists of sample Web pages, files, and an ActiveX
Client Control, which is automatically downloaded when the Web page configured for the
connection is accessed. You must deploy this application on a Web server. Internet Explorer (IE)
4.0 or later can then be used by any client to access the remote desktop of another computer even
if a Terminal Services client program is not installed on the local computer.
Two issues should be considered: Is security in place to protect the legitimate session, and what
prevents a malicious site from setting up Web pages and luring users in? In this scenario, the
ActiveX client control is downloaded, the user tricked into logging on, then the malicious site
owner runs programs that affect the client system, remotely controls the client, and so forth.
Two possible protective mechanisms can help prevent the malicious use of this tool. First, by
default, certain normal functions of a Remote Desktop session are configured to be active only
when the client is in trusted IE security zones. Trusted IE security zones are My Computer, Local
Intranet, and Trusted Sites. The restricted settings (such as Start Program, a specific program is
started upon connection, and working directory, this program be allowed to place data and
temporary files) are active in the Internet and Restricted Sites zones. Second, if a definitive
solution is required, Secure Sockets Layer (SSL) and SSL with client authentication certificates
can be used.
The Remote Desktop Web Connection is installed on a Windows Server 2003 IIS 6.0 server by
accessing Control Panel, Add or Remove Programs, Add/Remove Windows Components, and
selecting this option under the World Wide Web server subcomponents. After you install it, it
can be used by browsing to the http://server/tsweb location. The Active X component will
prompt before download, as Figure 7.10 shows.
Chapter 7
Figure 7.10: The Remote Desktop Web Connection ActiveX prompt.
You can access any Windows Server 2003 server that is configured for Remote Administration
by entering the server’s IP address in the logon screen, which Figure 7.11 shows. The Remote
Desktop Web Connection is governed by the same security settings made for the Remote
Desktop for Administration tool. The connection eliminates the necessity to open an additional
port on the firewall. For additional security, establish SSL and require client certificates on the
Web server that hosts the service.
Figure 7.11: Logon to the Remote Desktop through the Remote Desktop Web Connection.
Chapter 7
Q. 7.4: I want to setup dial-up remote access and a virtual private
network connection, but I don’t want to configure Active Directory. Is
this setup possible?
A. Windows Server 2003 Routing and Remote Access (RRAS) can be established in either a
domain or workgroup environment. So yes, you can set up dial-up remote access and a virtual
private network (VPN) without Active Directory (AD). RRAS, however, has additional options
when established in a Windows Server 2003 AD domain. Before you begin either setup, there
are decisions to be made about the authentication mechanisms to choose, the remote access
policies that will be used, and whether you need and how you will accomplish data encryption.
You must also determine which users will be allowed to remotely access the network.
Understanding the Difference Between Authentication and Authorization
Understanding the difference between authentication and authorization is a critical skill for those
who will set up, configure, and troubleshoot Windows Server 2003 RRAS. Although enabling
the service is simply a few mouse-clicks away, ensuring that clients that should be able to
connect can and that those that shouldn’t be able to can’t will take a little more of your time.
Let’s examine how a RRAS client gets connected. During the initial connection request, the
client must complete two steps: First, the client must authenticate (with one exception discussed
later) or prove a valid identity to the RRAS server. Although hardware devices may participate in
this process, the typical authentication process includes the use of a user name and password.
Next, if the client is successful in authentication, authorization comes into play. The client has
proven who he or she is and must now be authorized to connect. To complete your RRAS setup,
you must configure both authentication methods and authorization information. Authentication
must be configured on both the client and the server and can be configured via Windows Server
2003 remote access policies for greater granularity.
Choosing an Authentication Provider
During installation, you must choose whether Windows will oversee authentication and
authorization or if a central Remote Authentication Dial-In User Service (RADIUS) server will
do so. In a workgroup, choose Windows Authentication. The local Security Accounts Manager
(SAM) database of the Windows Server 2003 RRAS server will be used. Should you later decide
to implement AD and make the RRAS server a member of a domain, AD accounts can be used
for authentication. You might also choose to switch to RADIUS as the authentication provider
and set up Windows Internet Authentication Service (IAS) to centrally control both
authentication (using domain accounts) and authorization.
There is no need in either case for a separate user database. Figure 7.12, 7.13, and 7.14 illustrate
the three possibilities for authentication. Figure 7.12 shows a standalone RRAS and the request
for access from many clients. Because the users have accounts on the server, they can be
authenticated locally.
Chapter 7
Figure 7.12: Standalone RRAS in a workgroup.
In Figure 7.13, domain accounts are used.
Figure 7.13: RRAS in an AD domain.
In Figure 7.14, the RRAS server acts as the RADIUS client and passes the request to the
RADIUS server. The RADIUS server will pass credentials to the domain controller for
Chapter 7
Figure 7.14: RRAS with a RADIUS server.
Whether a workgroup server, member server, or IAS server is used, you will have a choice of
authentication methods and the ability to configure remote access policy.
Authentication Methods
Several authentication methods are possible; it is up to you to select and restrict those acceptable
for use. Authentication methods must be configured at both the server and client. For
authentication to be processed, at least one of the methods available on the client must be
available on the server. Although the server has an extensive list of methods available, many
clients do not. The primary reason for restricting the authentication methods available is to
improve security. However, your ability to restrict authentication methods on the server might be
dictated by those available on the clients that are used in your enterprise. Although most
Windows clients can utilize several authentication methods, others and many non-Windows
clients can only use the older less secure authentication protocols. When making authentication
method choices, you must consider both the degree of security desired and the capability of the
clients that exist in your environment.
The range of authentication protocols available consists of older protocols, which pass passwords
in the clear to sophisticated protocols that require smart cards for authentication. The RRAS
server will request the use of protocols in a predefined order from the most to least secure, but it
is the client’s capability that will dictate the protocol actually used. If the client is not capable of
using MS-CHAPv2, for example, but is capable of PAP, and PAP is authorized for use, PAP will
be used. If you do not want to allow older, less secure authentication protocols, you must make
them inaccessible in the server environment. Doing so might mean that some clients cannot
connect. Your written security policy, if implemented to the letter, might then require that clients
be replaced.
Chapter 7
Server-side authentication protocols are set on the Authentication Methods page of the RRAS
properties (see Figure 7.15), and client-side authentication methods are set by editing the profile
of the dial-up connection (see Figure 7.16).
Figure 7.15: RRAS authentication methods.
Figure 7.16: Client-side authentication methods.
Chapter 7
If the Extensible Authentication Protocol (EAP) is chosen as the authentication method, you
must choose an EAP protocol (see Figure 7.17).
Figure 7.17: If EAP is selected, you must select the EAP Method. Only EAP MD-5 Challenge is available on a
standalone server.
I’ll provide more information about EAP later in this answer. Table 7.1 describes the protocols
that are available regardless of the authentication provider.
Challenge/response, can be changed
by user
Microsoft Challenge Handshake
Authentication Protocol
Microsoft Challenge Handshake
Authentication Protocol version 2
Clear text
Shiva Password Authentication
Clear text
Password Authentication Protocol
Challenge/response, the user can
remotely complete a password
Challenge Handshake Authentication
Protocol dependent
Extensible Authentication Protocol;
this protocol is generic and lets
several potential authentication
processes be used.
Table 7.1: RRAS authentication methods.
Chapter 7
For backward compatibility, two versions of MS-CHAP are available. Both versions are
nonreversible encrypted password authentication protocols. Using either lets you select
Microsoft Point-to-Point Encryption (MPPE) for data encryption. You should always deselect
MS-CHAP if possible, as MS-CHAPv2 is a marked improvement over MS-CHAP. The two
versions are different in the following ways:
MS-CHAPv2 does not allow LANMAN-style passwords. LANMAN authentication does
not allow capitol letters and has other characteristics that make it a cryptographically
weak authentication protocol. In addition, the LANMAN password-changing algorithm is
weak and is not allowed with MS-CHAPv2.
MS-CHAP only provides client authentication while MS-CHAPv2 provides mutual
authentication. The client authenticates to the server and is able to authenticate the server
in return. This activity ensures that rogue servers cannot be used to trick clients into
transferring confidential data to non-company servers.
MS-CHAP uses a 40-bit encryption key based on the user’s password. Therefore, each
session for which the same password is used will have the same encryption key. This
setup gives an attacker more time to determine the key and a longer time to use it to
decrypt messages. MS-CHAPv2 uses an encryption key based on the password and an
arbitrary challenge string—the encryption key will always be different.
MS-CHAPv2 uses two encryption keys, one for transmitted data and the other for
received data. MS-CHAP uses one encryption key.
A password longer than 14 characters cannot be used with MS-CHAP.
A Windows Server 2003 RRAS server doesn’t by default support LANMAN (LM) authentication. That
is, the authentication mechanisms used by MS-CHAP and MS-CHAP v2 require an NTLM-style
password. If you require support for LM style passwords (to support Windows NT 3.5x and Windows
98 clients using MS-CHAP), you can enable it by modifying the registry. You will need to change the
AllowLMAuthentication value at
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RemoteAccess\Policy to 1.
With the MS-CHAPv2 authentication algorithm, the client requests a connection. The server
(RRAS or RADIUS) returns an arbitrary challenge string and a session identifier. The client
returns a response that consists of a peer challenge string, the user name, and the one-way
encryption of the received challenge string, user password, and session identifier. The server
compares its version of what the response should be to the client’s response. If they match, the
server returns an indication of success or failure and a response based on the peer challenge
string, the encrypted response of the client, and the user password. (The connection is dropped if
the user authentication failed.) The client authenticates the server response and, if correct, uses
the connection provided. If the server response fails to authenticate the client, the connection is
Chapter 7
Windows passwords are usually stored in the SAM database or in AD using a one-way
encryption protocol. Thus, they cannot be decrypted. During authentication, the same algorithm
is used to encrypt the password entered by the user, then used to encrypt the challenge string sent
from the server. The server is then able to uses its copy of the one-way encrypted password to
encrypt the challenge string and compare the result with that returned from the client. If,
however, the client does not understand the Windows authentication process and cannot use this
protocol to encrypt the user-entered password, it cannot participate in this type of authentication
process. An older authentication protocol, CHAP, uses the challenge response process but
requires that you enable reversible encryption for the storage of the user’s password in the SAM
or AD. Doing so weakens the ability of the server to protect the password.
SPAP also requires that passwords be reversibly encrypted in the database. SPAP is required for
use by connections to some remote access devices. The SPAP client can be used to authenticate
to a RRAS server if enabled. It is more secure than PAP, but less secure than CHAP and MSCHAP.
PAP uses plaintext passwords. Because anyone could capture this information and reuse it to
remotely access your network as an authorized user, the use of PAP is discouraged. The only
reason to enable its use on the network is for the use of legacy clients. If you need to enable its
use, consider the alternative of upgrading the clients so that you will not have to use it.
In addition to specifying the allowed authentication protocols, you have the choice of allowing
unauthenticated access. Although doing so defeats the purpose of requiring user identification for
access, it’s useful when utilizing certain authorization attributes that are available when RADIUS
is used:
Unauthenticated access is necessary when using Dialed Number Identification Service
(DNIS), one of the possible RADIUS authorization attributes. This method allows any
connection based on the number dialed. DNIS is provided by most telephone companies.
To enable its use, you must enable unauthenticated access, provide a remote access
policy that specifies DNIS and sets the called station-ID to the phone number, and you
must enable unauthenticated access on the remote access policy.
Chapter 7
Automatic Number Identification/Calling Line Identification (ANI/CLI) is based on the
phone number of the caller. It is different than caller-ID authorization, which utilizes a
user name and password and is configured to only work if the user name and password
matches the account that has been configured to match the phone number. In ANI/CLI,
no user name and password is sent. This service provides the phone number of the caller
to the receiver and is available from most phone companies. To use this method,
unauthenticated access must be enabled on the RRAS server and in the remote access
policy for ANI/CLI. A user account is created for each telephone number that will be
used. The user ID becomes the phone number. For example, if the phone number used
will be 444-4444, the account user ID will be 4444444. In addition, the user identity
attribute value of the
Access\Policy key must be set to 31. Other registry settings can be made to further refine
the use of this method.
If you chose to allow guest access, you can use unauthenticated access, then modify the
registry to include the account name used as a value in the key—
Access\Policy\defaultuser identity.
EAP’s name implies its usage. It was designed to be extensible by not specifying exactly the
authentication method used. Therefore, it conceivably can be modified to use any authentication
protocol. Two choices currently exist in Windows Server 2003, EAP-TLS and EAP-MD5. A
third type, EAP-RADIUS, is not really an authentication type at all:
EAP-TLS—This authentication type is a certificate-based protocol similar to but not the
same as Secure Sockets Layer (SSL). It is currently only available in a Win2K or
Windows Server 2003 domain environment and is used to allow smart card
authentication via remote access servers.
EAP-MD5—This authentication type operates in a similar fashion to CHAP, except it
uses EAP. It is often required for user name and password security system devices. It is a
good way to test EAP functionality before attempting EAP-TLS and smart cards because
it eliminates the smart card piece of the process to verify that EAP is working.
EAP-RADIUS—EAP-RADIUS is not an EAP type; instead it centralizes EAP
authentication via the RADIUS server. The EAP type passed to the RRAS server is
available to pass the EAP authentication to the RADIUS server.
Data Encryption
Authentication protocols encrypt, obscure, or pass the password in the clear depending on the
protocol chosen. Data encryption is optional. Two options are available: First, for remote
connections, data encryption is available by selection from the Encryption tab if MS-CHAP, MSCHAPv2, or EAP-TLS is selected. Second, if a VPN is configured, data encryption depends on
the type of VPN (PPTP or IPSec). Data encryption for remote dial-up access is accomplished via
Chapter 7
Data encryption levels that the server will accept are configured within the dial-in profile for the
remote access policy (see Figure 7.18). Each remote access policy can specify its data encryption
choices, including No encryption. The policy can specify, therefore, that only the strongest
encryption be used; however, the client must be capable of performing the encryption and an
appropriate authentication method (MS-CHAP, MS-CHAPv2, or EAP) must be selected.
Figure 7.18: Configuring data encryption for dial-up connections.
Client encryption is configured by editing the client profile of the client connection (see Figure
7.19). Your choices are
Optional encryption (connect even if no encryption)—This setting is the default setting
Require encryption (disconnect if server declines)—A good client-side control
Maximum strength encryption (disconnect if server declines)—If the remote access
policy on the server does not specify, or if the server is not capable, the connection is
refused by the client
No encryption allowed (server will disconnect if it requires encryption)—For maximum
efficiency, minimum security
Chapter 7
Figure 7.19: Client-side encryption configuration
Remote Access Policy
One of the strengths of Windows Server 2003 and Win2K RRAS is the ability to granularly
control remote access authorization. Previous remote access implementations had a simple
policy—either you were granted dial-up access or you were not. In addition, the configuration
settings of the remote access server were true for every connection. There was no way to specify
different authentication, encryption, or authorization attributes.
On Windows Server 2003 and Win2K server, RRAS extends these meager offerings and allows
an almost-endless variety of remote access policies to meet sophisticated needs. By default,
client access to dial-up connectivity is set on the property pages of the client account to be
Control Access through Remote Access Policy, as Figure 7.20 shows. When a new RRAS server
is enabled, the default remote access policy is, you guessed it, Allow Access if Dial-in Permission
is enabled. Thus, no access is configured for the new RRAS server.
Chapter 7
Figure 7.20: Default remote access policy settings.
To provide remote access to your network, you must either set Allow Access on the dial-in
properties page of each client account that is authorized for remote access, or you must configure
remote access policies. To do so, you create a policy and set the restrictions and conditions under
which it will allow access and configure connectivity. Within each policy, you can select the
authentication methods and data encryption specifics identified earlier. You also must set the
conditions or authorization attributes that determine whether a connection can occur.
Policy Attributes
Within the remote access policy, you configure the acceptable types of connections. A broad
range of policy conditions or types are available. Do not confuse these parameters with the
authentication process described earlier; these are conditions of access. The authentication
protocols selected determine how an individual proves who he or she is. The policy attributes
offer a wide range of conditions to restrict authenticated access.
First, although individual user accounts may be selected and given authorization for remote
access by selecting Allow Access on their account dial-in property page, remote access policy
enables authorization via Windows group membership. Furthermore, a remote access policy can
let you granularly authorized access by specifying conditions that must be met for access. A
client may be authenticated and authorized for remote access, but if the connection does not meet
these conditions, the call will be disconnected. A few of the conditions are available only if
RADIUS is being used. Authentication types are configured during the construction of a remote
access policy by adding attributes (see Figure 7.21). Table 7.2 lists and describes them.
Chapter 7
Figure 7.21: RRAS policy conditions.
Only the authentication method listed is acceptable.
Called Station ID
Which phone number is dialed?
Calling Station ID
Which phone number placed the call, or potentially
in a VPN, the IP address of the caller (cannot do
caller ID and callback together)?
Client Friendly
The friendly name of the RADIUS client. (The
RADIUS client is the RRAS server or other server,
not the client computer.)
Client IP
IP address of the RADIUS client.
Client Vendor
Manufacturer of the RADIUSM proxy
Day and Time
A range of acceptable times for connection.
Framed Protocol
Only the protocols listed are allowed (choices such
as AppleTalk, PPP, X.25, and so on).
MS-RAS Vendor
Not yet defined.
NAS identifier
A Network Access Server (NAS) vendor string.
The IP address of the NAS.
NAS Port Type
The type of port used by the NAS (port choices
include FDDI, 802.11 wireless, ISDN, DSL).
Service Type
Type of service user has requested (such as
callback logon).
Tunnel Type
Tunnel protocol used (such as PPTP or L2TP).
Windows Group
Membership in a Windows group.
Table 7.2: RRAS authentication types.
Chapter 7
Account Lockout
An additional element of the operations policy for remote access is whether to implement
account lockout. In a local network environment, account lockout is configured via the account
policy of the domain or standalone server. For remote access, an additional step can be taken.
The goal, of course, is to prevent someone from using a password cracker to remotely attack
accounts. When set, the remote access account lockout will lockout an account after the
designated number of invalid attempts. Account lockout must be enabled via a registry
modification if using Windows Authentication.
Installation and Configuration
The RRAS service is pre-installed but disabled on every Windows Server 2003 and Win2K
server. To start the service and continue with its configuration, you must enable it. Prior to
starting the wizard, determine which options you need. Select Administrative Tools, Routing and
Remote Access Service to open the console. Right-click the server, and choose Configure and
enable Routing and Remote Access Service. On the Welcome page, select Next. From the menu,
select Remote access (dial-up or VPN), and click Next. On the Remote Access page, select both
Dial-up and VPN, and click Next. Select the use of DHCP if you already have a DHCP server.
Provide RRAS with a range of addresses to use for clients and/or allow clients to request an
address. In the address dialog box, click Add, then enter the address range. On the Manage
Multiple Routing and Remote Access Servers page, select No, I don’t want to set up this server to
use RADIUS, click Next twice, then click OK. After the RRAS service starts, you’ll need to
configure authentication methods, data encryption requirements, and remote access policies.
Q 7.5: I set up a Windows 2000 virtual private network (VPN) for use
by our salesmen to connect to the corporate LAN. It worked fine at
first, but we had a security review, and the experts advised us to
change the VPN protocol from Point-to-Point Tunneling Protocol
(PPTP) to Layer 2 Tunneling Protocol (L2TP)/IPSec and change our
authentication method to certificates. It seems to work in my test lab,
but when I put it into production, I cannot get it to work. In addition,
we must be accessible to Windows 98 clients. Will upgrading our
Routing and Remote Access Service (RRAS) server to Windows
Server 2003 solve this problem?
A: From what you’re saying, I suspect that your environment uses Network Address Translation
(NAT). As you know, NAT modifies the IP source address of all packets. Although this behavior
does not cause a problem for Point-to-Point Tunneling Protocol (PPTP), your original VPN
protocol, it does cause a problem for Layer 2 Tunneling Protocol (L2TP)/IPSec. In essence,
IPSec sees the packet manipulation performed by NAT as tampering, and drops the packet. This
behavior is not a design flaw in the Windows 2000 (Win2K) implementation of L2TP/IPSec, but
rather a lack of NAT-related direction on the part of the standard, and the Win2K
implementation is written to the standard. The short answer to your question about upgrading to
Windows Server 2003 is maybe. There is an emerging standard for NAT-Traversal that
Microsoft has indicated will be supported by Windows Server 2003. However, we are talking
about an emerging standard, and an operating system (OS) that, as I write this, has not yet
Chapter 7
You should spend some time investigating this issue on three fronts. First, some non-NAT
related issues of virtual private network (VPN) design have an impact on L2TP/IPSec
implementations. Second, understanding the L2TP/IPSec implementation as it stands now and
the problems that NAT can cause is important. If this is your problem, you will want to be able
to document it. There is no sense getting in an argument over the security evaluation results. It is
not always possible to implement the preferred solution, but you’ll want to have valid reasons
why you can’t. Finally, you should understand the emerging standard for NAT-Traversal, as it
might be an option you want to pursue.
VPN Design Issues for L2TP/IPSec
VPNs are good choices for secure communications because data is tunneled from one network to
another across one or more other networks. Logically, it’s as if a single tunnel connected the
client directly to the server with no other devices between. Physically, such is not true, although
all packets are encapsulated within the tunneling protocol, which affords some protection.
Security, however, is ensured because of the data encryption and other characteristics of the
tunneling protocols. Computer authentication, data integrity, and protection from replay attacks
are common benefits. In addition, user authentication and access control can be enforced.
Microsoft Windows Server 2003 VPNs can exist as client-to-server VPNs and as endpoint-toendpoint (server to server) demand-dial VPN connections. Figure 7.22 illustrates the client-toserver VPN that you have indicated is your design. Communications are tunneled and encrypted
between the client and the server. Subsequent access by the client to resources on the network,
although it is tunneled and encrypted between the client and the VPN server, is not tunneled or
encrypted between the VPN server and the internal resource.
Figure 7.22: Client-to-server VPN.
Figure 7.23 shows the endpoint-to-endpoint configuration. All communications that originate in
one network with a destination of another network are tunneled and encrypted between the
Routing and Remote Access Service (RRAS) servers on the network boundaries.
Communications between the client and the VPN server on one network—or between the VPN
server on the other network and other resources—is not tunneled or encrypted.
Chapter 7
Figure 7.23: Endpoint-to-endpoint VPN.
Either configuration can work with L2TP/IPSec, but the use of the client-to-server model is more
likely to produce unexpected results as the user might move and his or her connection might be
unhampered at some locations and be blocked at others. In the endpoint-to-endpoint
configuration, it should be easier to determine whether NAT is the problem.
A standalone Windows Server 2003 RRAS server can be used as a VPN tunnel endpoint, as can
a Windows Server 2003 server that has been joined in a domain. Question 7.4 described a
standalone RRAS server and available authentication methods. The advantage of using a domain
member is that domain user accounts can be used for authentication and the user database does
not lie on the RRAS server. One advantage to this setup is that, should the server be
compromised, no useful account database information can be gained. In addition, as company
needs grow, more servers can be added and user accounts do not have to change. Client
computer domain membership and user accounts can also be used to push security settings to
users and client machines, something unattainable with a standalone server.
You don’t say whether your situation involves domain membership for the VPN server, and this
information might have a bearing on your problem. Using certificates for authentication is also
easier in a domain environment. Because an Enterprise Certification Authority (CA) can be used,
certificates can be published to Active Directory (AD) and are then automatically available for
user authentication. Computer certificates, which are required for the default implementation of
L2TP/IPSec, can also be automatically published, and thus are readily available. However, there
are numerous issues here. The CA must be correctly configured and protected. If it is
compromised, all the certificates it has issued are compromised, and thus the identity of any
client or server using these certificates is in doubt.
Chapter 7
Although a Windows Server 2003 L2TP/IPSec VPN can be configured to use shared keys instead of
certificates, this setup is not recommended. The shared key, of which only one can be created, is
visible in the configuration of both client and server and will not remain secret very long, as Figure
7.24 shows.
Figure 7.24: The shared key is revealed.
L2TP/IPSec can be configured for shared key instead of certificates. Such is also possible in Win2K
but requires more than a GUI interface change. Although it is not recommended as an authentication
measure, you should try this configuration in your situation to make sure that your problems are not
certificate related. If you change nothing other than shared key configuration (don’t forget to enter the
same key on the client) and the clients are able to connect, your problem might be certificates, not
VPN Protocols Choices
Because you are moving from PPTP to L2TP/IPSec, it’s important to consider the differences
between the two protocols. Both are choices for Windows VPNs. Of the two, L2TP/IPSec is
considered the more secure but both have advantages and disadvantages.
Chapter 7
It is possible to have a non-encrypted PPTP or IPSec tunnel. By definition, VPN just means the
connection of two networks across a third network. This type of a tunnel, one that does not use
encryption, is not recommended. Tunneling alone affords little protection. The information about
protocols provided here is very brief and introductory. One source for learning more about the
protocols is through each protocol’s Request for Comments (RFC), which can be found at L2TP is RFC 2661 and IPSec is RFC 2401.
PPTP is described is a standard that has primarily been implemented by Microsoft and has been
available since Windows 98 and Windows NT 4.0. The first implementation came under public
scrutiny and was strongly criticized for weaknesses in keying, authentication, and encryption
algorithms. Microsoft subsequently revised the protocol, correcting these flaws. The
improvements were acknowledged by the original critics, but PPTP remains flawed in the eyes
of many simply because of the early criticism.
When a PPTP session is established, an IP, AppleTalk, or IPX frame is encapsulated with a GRE
header and an IP header, the IP header contains the IP address of the VPN client and server.
Figure 7.25 illustrates this design.
Figure 7.25: PPTP encapsulation and encryption.
The PPP frame is encrypted using keys generated by the MS-CHAP, MS-CHAP v2, or EAP-TLS
authentication protocols. Only these authentication protocols can be used to provide an encrypted
PPTP VPN solution. Microsoft Point-to-Point Encryption (MPPE) is the encryption algorithm
If this combination is chosen for the VPN, L2TP uses IPSec for data encryption. (L2TP/IPSec is
usually pronounced as L2TP over IPSec.) The L2TP encapsulation, like PPTP, works with a PPP
frame but provides two layers of encapsulation. First, the PPP frame is wrapped with an L2TP
header and a UDP header. Next, this message is wrapped with an IPSec header and trailer, an
IPSec Authentication trailer (for message integrity and authentication), and finally, an IP header.
Figure 7.26 illustrates this design. The IP header includes the source and destination address of
the client and server.
Chapter 7
Figure 7.26: L2TP/IPSEc encapsulation and encryption.
As you can see, the entire message, exclusive of the IPSec header and trailer and the final IP
header is encrypted. DES or 3DES is the encryption algorithm used.
L2TP over IPSec and NAT—NAT-Traversal
One of the issues with IPSec and hence VPNs using L2TP over IPSec is the inability to use them
in natted environments. In a typical scenario, a VPN tunnel is used to provide access from
outside the firewall to inside by opening the ports on the firewall used by the VPN. Both PPTP
and L2TP over IPSec VPNs can be configured this way—unless the firewall, router, or other
remote access device, which sits between the VPN client and the VPN server, uses NAT. The
current IPSec standard does not address this issue, in fact, an implementation—such as Win2K—
written to the standard, sees the NAT manipulation of the addressing as tampering and drops the
The problem with NAT comes about because the NAT device must translates the source address,
and might assign a new source port to maintain a table to be used in routing replies back to the
originating host. Here’s what’s happening: The NAT device modifies an outgoing packet by
changing the real source address, the address of the sending client, to that of the Internet routable
address provided to the NAT device. When packets from the Internet return to the NAT device, it
is able to modify the destination address (which arrives using the Internet routable address
assigned as the source address of the outgoing packet). How does it know the new source address
to use? It knows because it keeps a table of sources addresses and ports mapped to the assigned
source address and ports it replaced in outgoing packets. It is able to match the incoming packets
and modify the destination address and port. However, because of the built-in security
mechanisms of IPSec such tampering with the address is not allowed, hence the packets are
dropped. This is why a Win2K to Win2K VPN that must pass through a NAT device can only
use PPTP.
Legacy clients, Windows 95, Windows 98, and Windows NT do not have native L2TP/IPSec ability to
participate as VPN clients. However, Microsoft has recently released an L2TP/IPsec client for
Windows 98, Windows ME, and Windows NT 4.0 Workstation that can be downloaded from
relnotes.asp. The client is just that, a client. It will not enable any of these clients to become a server
and will not install on Window NT Server. It also will not install on Win2K or Windows Server 2003.
The new client also supports NAT-traversal.
Chapter 7
Before any NAT-traversal can occur, the client must be capable of recognizing the use of NAT,
and the server must be NAT-Traversal enabled. To fully understand the process, you should
know something of how IPSec works. The following text explains, in simplified form, how
NAT-Traversal works. The client detects the NAT-Traversal capability of the server by an
exchange of strings (in the draft an MD5 hash of the draft title) during the first messages of
IPSec, Phase I negotiation. (Phase I negotiation of IPSec includes establishment of IKE
communications and generation of master key that is used in Phase II to generate encryption
keys.) If the server does not return a message that includes the hash, it is not considered to be
NAT-Traversal enabled.
Next, the presence and location of a NAT device is detected by using the NAT-D payload
message. To discover if NAT is being used, each side looks to see whether the IP address of the
message has been modified. This is done by including a hash of the original source address and
port. When received, a new hash of the existing source address and port is made. If the new hash
matches the original (included in the payload), there is no NAT device in-between and
processing continues per the IPSec standard. If the hash does not match, NAT is being used.
Although port 500 is the standard port for IKE traffic, IPSec-aware NAT devices may respond in
a different way than standard NAT when they detect IKE traffic. Because NAT-Traversal does
not include the ability to determine exactly what an IPSec-aware NAT device is doing, moving,
or floating the IKE traffic to port 4500 avoids the problems that the non-standard IPSec-aware
NAT device may pose. Additional modifications such as the inclusion of a non-ESP marker may
also be necessary. After the initial NAT-Traversal communication is established, subsequent
negotiations must start on port 4500. An illustration of the IKE floating can be found in Figure
Figure 7.27: IKE floating.
Finally, negotiation of NAT-Traversal encapsulation occurs. Normal IPSec negotiations include
the use of either Tunnel or Transport modes. NAT-Traversal requires the use of either of two
new modes: UDP-Encapsulated-Tunnel and UDP-Encapsulated-Transport. Either of the modes
allows NAT manipulation of the source IP and port information as this information is now
available in a header designed for this purpose. Figure 7.28 is an example rendering of the UDPEncapsulated-Transport mode.
Figure 7.28: UDP-Encapsulated-Transport mode.
Chapter 7
Q 7.6: How can I securely and remotely administer systems?
A: Allowing remote administration risks penetration. Unfortunately, there are few organizations
that can insist that all administration take place at the local console for all systems. Perhaps some
critical, sensitive systems can be restricted, but for the vast majority, it is necessary to provide a
secure way to remotely administer them.
When administering systems on the LAN, Windows Server 2003 encrypts the traffic between the
administrator’s desktop system and the server when any of multiple administrative tools are
used. When remote administration is necessary, more security, as well as the ability to run the
server’s local administration tools, is required. The local LAN administrator can use
administrative tools present on his or her desktop. Kerberos authentication, authorization
settings, and encrypted traffic ensure the security of the action. Accessing the server over dial-up
lines or the Internet from the other side of the corporate firewall presents different challenges.
The protocols present on the LAN will not be available, and the desktop tools will be useless. To
correctly and conveniently administer the server, the ability to run the server’s local tools is
With Windows Server 2003, this can be accomplished by enabling Remote Desktop for
Administration. Remote Desktop for Administration uses Terminal Services technology but does
not install Terminal Server application-sharing, multi-user technology or process scheduling. Nor
does Remote Desktop for Administration require special licensing. This lightweight technology
is efficient, causing hardly a noticeable effect on a busy server. It can even be utilized by
administrators from earlier versions of the Windows OS if Remote Desktop Connection is
How It Works
Remote Desktop for Administration uses the Terminal Services Remote Desktop Protocol (RDP)
on port 3389. The user interface (UI) is transmitted to the Remote Desktop Connection, and the
mouse movements and keyboard clicks of the Remote Desktop Connection on the client are
transmitted to the server. To the administrator, the session looks as if she or he is actually sitting
at the remote server’s console. While the session is in place, the administrator can also use the
local system. Each session, the remote and the local session, operate independently. A second
administrator can also connect simultaneously. Each session is also independent, however, the
second administrator will see information about the other connection.
Connections can be made via LAN, WAN, virtual private network (VPN), or dial-up connection,
and jobs started on the remote server will continue to run even though the administrator has
disconnected. Thus, time-consuming jobs—such as backup—can be started by the administrator,
who then disconnects. The administrator can later reconnect to see the status of the job. In
addition, tasks that normally would not be candidates for remote administration, such as domain
controller promotion, can be managed in this manner.
Remote Desktop for Administration is disabled on domain controllers by default, but is easily
enabled. To do so, open the System applet from Control Panel, select the Remote tab, and clear
the Allow users to connect remotely to this computer check box (see Figure 7.29).
Chapter 7
Figure 7.29: Enabling Remote Desktop for Administration.
Click Select Remote Users…Note that while you can add non-administrative users and give
them remote access, all members of the Administrators group can connect even if not listed (see
Figure 7.30). For this example, we’ll click Cancel, then click OK.
Figure 7.30: Giving users remote access.
Chapter 7
To connect and administer the server, use the Windows Server 2003 Remote Desktop
Connection by opening the Remote Desktop Connection from the Start menu (click Accessories,
Communications, Remote Desktop Connection). Enter the name of the computer or IP address to
administer (see Figure 7.31), then click Connect.
Figure 7.31: Specifying the computer you want to administer.
Log on to the system in the normal manner. A desktop screen that represents the remote server is
displayed. You may use any administrative tool. Log off when your administrative session is
If you need to administer multiple computers, instead of using the Remote Desktop Connection,
load the Microsoft Management Console (MMC) Remote Desktops snap-in. Doing so will let
you store multiple connections and more easily move between remote administrative sessions.
To configure the Remote Desktop snap-in, from the Administrative Tools menu, click Remote
Desktops, or from a command prompt type
Right-click Remote Desktops in the console tree, and select Add new connection. In the Server
name or IP address text box of the Add New Connection dialog box, enter the name or TCP/IP
address of the server you want to administer. Enter a friendly name in the Connection name box,
and clear the Connect to console check box if you are just setting up the connection (see Figure
7.32). Optionally enter the user name, password, and domain name, then click OK. Simply repeat
these steps to add additional servers to the console.
Chapter 7
Figure 7.32: Adding a new connection.
Applying Maximum Security
When making the decision to allow remote administration, and when configuring it, you should
be aware of the security implications, and make every effort to ensure that security is a primary
By default all connections to the Remote Desktop Connection are encrypted using the maximum
key strength supported by the client. If you want to ensure that only clients capable of the large
key size be used to connect, you have the option of changing this setting to High. You do so on
the General tab of the RDP-Tcp Properties page (see Figure 7.33). The RDP properties page can
be located from the Terminal Services Configuration console by right-clicking the RDP-Tcp icon
in the Connections container. Your encryption choices are High, to be used when only 128-bit
clients will be used; or Client compatible, which negotiates the encryption strength. Both settings
use the RSA RC4 algorithm.
Chapter 7
Figure 7.33: Setting the encryption level.
On the Logon Settings tab, which Figure 7.34 shows, you can select either Use client-provided
logon information or Always use the following logon information. If the second option is
selected, use the provided spaces to enter user name, domain name, and password. However,
selecting this option and providing this information is a very a bad idea. Do not configure these
settings! Doing so is the same as allowing anyone to log on who can connect to the server. That
individual will have the authority given to the user identified in the logon information and stored
Do set the Always prompt for password option. This setting prevents the casual interloper who
obtains access to the user’s desktop from being able to administer servers.
Chapter 7
Figure 7.34: Configuring logon settings.
On the Sessions tab, which Figure 7.35 shows, you can control the settings that determine
whether disconnected sessions will be entered, whether active sessions have a limit, and what
happens if a session connection is broken. In addition, you can control whether a session can be
reconnected to only from the previous client or from any client.
Although you might not want to make limitations that restrict administration, where sensitive
servers are at risk, it may be that you want to restrict reconnection to occur only from the
previous client. Doing so prevents the hijacking of a session, even should an attacker know the
username and password of the administrator. Likewise, you might want to limit session time and
disconnect idle sessions. However, these settings might interrupt processing if a function is in
process that requires an open session and the session disconnects.
Chapter 7
Figure 7.35: Configuration session settings.
From the Remote Control tab, which Figure 7.36 shows, select the Do not allow remote control
option. Preventing remote control of a user session on a server is important. Should there be a
need to provide administrative assistance to another administrator, the local administrator can
reset this setting to allow the connection.
Figure 7.36: Disabling remote control.
Chapter 7
Using Group Policy to Secure Remote Desktop for Administration
Configuring multiple servers for remote administration can be a tedious chore. Use Group Policy
to reduce the work and to ensure consistent settings across servers. Many of the settings have
more to do with Terminal Services for application servers; however, you can use Group Policy
for all your terminal server and remote administration settings. You will find that the Group
Policy Administrative Templates offer more choices for Terminal Services settings than those
available for a standalone system. You can also use Group Policy to apply different settings for
different computers and users. Table 7.3 shows some settings that I recommend you change
according to your policy.
Client/Server Data Redirection
Allow Time Zone redirection
By default, session time zone is
the server time zone. If this
setting is enabled, a capable
client (Remote Desktop
Connection and Windows CE
5.1) connecting to a Windows
Server 2003 terminal server will
redirect its time zone information
to the server.
Time setting is very important for
audit purposes and Kerberos
tickets. Time zone redirection
should not be allowed for remote
Do not allow clipboard redirection
Allowed by default, enable this
feature to prevent users from
sharing data between the client
computer and the server via the
This setting is more relevant for
application users. Nevertheless,
it should be enabled to prevent
using the clipboard during an
administrative session.
Do not allow smart card device
Smart card devices are mapped
on connection. Enable this
setting to prevent this. A remote
administrator will not be able to
use a smart card to log on to a
remote administration session.
Leave this setting alone. It is a
good idea to require smart card
logon for remote administration.
Allow audio redirection
Allow user to redirect server
sound to the client computer.
I know of no security reason not
to allow this.
Do not allow COM port
COM port redirection allows
redirection of server data to client
COM ports
COM port redirection may be
necessary for administrative
Do not allow client printer
If this setting is enabled, it
prevents print jobs origination at
the server from being redirected
to the client computer-attached
Policy dependent.
Do not allow LPT port redirection
If enabled prevents LPT port
Policy dependent.
Do not allow drive redirection
Prevents mapping of client drives
to session. By default, client
drives are mapped.
Policy dependent
Chapter 7
Do not set default client printer to
be default printer in a session
Disables the automatic
remapping of the default printers.
If not set, it automatically maps
local computer printer as the
default printer to be used.
Policy dependent.
Encryption and Security
RPC Security Policy/secure
server – (require security)
Requires secure RPC
communication, allowing only
authenticated encrypted RPC
requests. If not set, allows
unsecured RPC.
RPC connections are used to
configure terminal server
Always prompt client for
password upon connection
If not set, client may configure his
or her system to use a recorded
Set to prevent just anyone from
using the stored credentials to
administer the server.
Set client encryption level
Set as conditions require.
Set at high if possible.
Set time limit for disconnected
More specific for client sessions
than remote administration.
Consider effect on long
administrative processes before
Allow reconnection from original
client only
Prevents connection to an inprogress session from other than
the computer that started the
Prevents hijacking of a session.
Terminate session when time
limits are reached.
More specific for client sessions
than remote administration
Consider effect on long
administrative processes before
Set a time limit for active
Terminal Services sessions
Client Only
Start a program on connection
Application mode relevant.
Set rules for remote control of
Terminal Services user session
Allows remote control if enabled,
does not need user’s permission.
Relevant only for application
Table 7.4: Recommended settings to change according to your company’s policies.
Remote Desktop Web Connection
The Remote Desktop Web Connection allows Terminal Services connection from any Web
browser. It requires, however, that a special Web page be loaded on the machine to be connected
to; in essence running a Web server on the computer. When a connection is made to the Web
page, a special client control is downloaded to the client machine if it does not have the Remote
Desktop Connection utility. The client still needs to log on. This control could be used for remote
administration purposes, but places additional risk on the server because a Web server is now
running on the system, and because the user does not require a client.
Chapter 8
Chapter 8: Security Tools, Mechanisms, and Emerging Issues
Q 8.1: How do I determine which Group Policy settings are actually
being applied?
A: Resultant Set of Policy (RSoP) is a new Windows XP Professional and Windows Server
2003 utility that can display which Group Policy settings have been applied to a particular user
or computer account. This tool can be used to troubleshoot problems with Group Policy. Two
modes are available with Windows Server 2003: logging mode and planning mode. Logging
mode displays the aggregate settings for a user or computer, and planning mode lets an
administrator anticipate the impact of applying different Group Policy Objects (GPOs). Logging
mode can be applied to a standalone computer, and is currently operative on Windows XP
computers joined in Windows 2000 (Win2K) domains. RSoP is not available for Win2K or other
legacy Windows systems.
Mining the Common Infrastructure Management Object Manager Database
RSoP gathers the information it presents from the Common Infrastructure Management Object
Manager (CIMOM or WinMgmt) database. This database contains information about computers’
hardware, software installation settings, scripts, folder redirection settings, security settings, and
Internet Explorer (IE) maintenance settings. Each time a computer logs on to the network, the
database is refreshed with current information.
As you may recall, the Common Infrastructure Management (CIM) model, now known as the
Web-based Enterprise Management (WBEM) initiative, was adopted by the Distributed
Management Task Force (DMTF). This emerging standard is meant for all computer systems in
order to have a common way of describing and managing systems. Windows Management
Instrumentation (WMI), which is built into Win2K, Windows XP, and Windows Server 2003, is
the Windows-specific implementation. It can be used to discover information about Windows
systems as well as manage them. More information can be found by researching WMI.
An introduction and tips about using WMI to manage Win2K systems can be found at
Chapter 8
Obtaining Results with RSoP
To request RSoP, you must either be logged on to the machine as the user whose policy you
want to see, have local Administrator privileges on the machine you are querying (membership
in the local Administrators, Domain Admins, or Enterprise Admins group is required), or have
been delegated control over RSoP. To see the actual settings applied (logging mode) to a user or
computer account on a specific computer, follow these steps.
For Windows XP systems:
1. In the Run text box, type
and press Enter.
2. A Microsoft Management Console (MMC) window with the RSoP for the current user
and current computer will appear.
Alternatively, for Windows XP systems:
1. Open an MMC console.
2. Open the File menu, and select Add/Remove Snap-ins.
3. Click Add.
4. In the Snap-in window, click Resultant Set of Policy.
5. The RSoP wizard will begin. Click Next.
6. Chose Logging Mode (it may be the only mode available), and click Next.
7. In the Browse Existing Data page, select a computer, and click Next.
8. In the Browse Existing Data page, select a user, and click Next.
9. Click Next again.
10. Click Close to close the Add Snap-in window.
11. Click OK to close the Add/Remove Snap-ins window.
12. Click RSoP folders to view the data, as Figure 8.1 shows.
Chapter 8
Figure 8.1: Clicking an element displays the RSoP.
For Windows Server 2003:
1. In the Run text box, type
and press Enter.
2. An MMC window with the RSoP for the current user and current computer will appear.
Alternatively, for Windows Server 2003:
Open an MMC console.
Open the File menu, and select Add/Remove Snap-ins.
Click Add.
In the Snap-in window, click Resultant Set of Policy.
The RSoP for the current user on the current computer appears. To change to another user
or computer, right-click the xx, and select .xxxxx.
You can also determine the order in which policies are applied. Simply right-click on the
policy element, select Properties, then click the Precedence tab, as Figure 8.2 shows.
Chapter 8
Figure 8.2: The order of policy application is displayed in the Precedence window.
You will know in a glance if there is a problem with policy application as a red x on the user or
computer configuration level indicates an error. Right-click these objects, select Properties, then
select the Error Information tab, which Figure 8.3 shows. An explanation of the error is
documented on this tab. In Figure 8.3, the error tells you that the policy was not applied during
computer start or user logon due to some problem in reaching a domain controller. Indeed, the
domain controller was shut down when Windows XP was booted. Simply rebooting the domain
controller and the Windows XP system and logging on cleared the error.
Chapter 8
Figure 8.3: Error conditions are displayed in the property pages.
Storing, Recovering and Printing RSoP
Visual, right-at-the-moment views of the results of applying Group Policy are priceless. Being
able to determine what might have gone wrong, especially in the case of the application of
security settings, is an excellent addition to a Windows security administration toolset.
Sometimes, however, you will want to store and reuse RSoP, or save it to another file format that
can be archived, printed, or utilized elsewhere. The ability to save this type of information to a
text file is a common request I receive from auditors.
The results of running RSoP can be saved in an MMC console file by simply selecting Save from
the File menu, naming the file, and clicking Save. The file can then be reopened from an MMC
console or by typing the file name in the Run text box. Saving the data in another format is not
Chapter 8
Although you cannot print out the entire RSoP console or save its contents to a text file, another tool,
gpresult, can dump most of the RSoP data to a text file. Gpresult is not a GUI-based tool; you run it
from the command line and pipe, or place the results in a text file by using the > symbol. The
following command places all the available Group Policy information that refers to the currently
logged on user at the local machine into a text file, filename.txt:
gpresult /z > filename.txt
You can also obtain Group Policy information for other users and computers by using the /s computer
and /u domain\user switches.
RSoP Best Practices
RSoP can streamline your Group Policy troubleshooting chores, quickly determine whether the
latest security setting change is propagating to clients, and in planning mode, give an initial test
to proposed changes. Although every user can run RSoP, not all information will be displayed.
(.adm file information is usually denied due to default file permission settings.) To see all there is
to see, and to examine the RSoP for accounts other than your own, you must have local
Administrator group membership. This requirement means that some administrators will want to
place Help desk operators as members in local Administrator groups, or worse, provide them
Domain Admin membership. Instead, use delegation of authority to give RSoP permissions on
the computer or user accounts to a group of select personnel. If you have already arranged your
computer and user accounts into OUs for administrative purposes, this element is one more that
you can hand over to groups already assigned.
Q 8.2: Managing multiple Windows boxes is like herding cats. It’s hard
to keep up with which systems have up-to-date patches and which
still need them. How can I figure this out?
A: Microsoft has three free tools that may help you: HFNetChk, QChain, and Microsoft
Baseline Security Analyzer (MBSA). HFNetChk is a command-line tool that can analyze a
Windows NT, Windows XP, or Windows 2000 (Win2K) computer and report missing hotfixes.
QChain is a tool to help you apply multiple hotfixes to a computer at a time without excess
rebooting between fixes. MBSA is a GUI tool that
Analyzes basic security on an NT, Windows XP, or Win2K system
Analyzes security settings for IIS (if present on the system)
Analyzes security settings for SQL Server (if present on the system)
Determines which hotfixes are missing
Provides a way to immediately download and apply missing fixes.
Scans a Windows Server 2003 system and reports vulnerabilities (although MBSA
doesn’t officially support Windows Server 2003)
Chapter 8
Although a combination of HFNetChk and QChain can help you keep systems up to date with
hotfixes, they do nothing about basic system security analysis and require some sophistication to
run. MBSA, however, provides a quick and easy security assessment and an immediate way to
update a system. Although MBSA might not answer all your questions and is not exactly the
solution for large enterprises, it is a valuable aide for the harried systems administrator.
Analyzing the Analyzer: MBSA Internals
MBSA is at heart a GUI interface for HFNetChk. Rather than learning how to operate a
command-line tool, users and new administrators can simply start a GUI product and click their
way to security—or so they may think. In reality, of course, they should be thinking about what
they are doing.
As with any product, there are three things to understand in order to use it. Before you run
MBSA, and certainly before you attempt to act on any of the results, consider the following:
What is necessary to run it?
How do you run it?
How should you interpret and act on the results?
Understanding Prerequisites
When MBSA is installed, you are asked if you want to view a readme file (the file is also
available pre-installation at the download site) that explains that MBSA is simple to run but does
have basic requirements. MBSA can only be hosted by Win2K and Windows XP systems, but
can be used to scan NT and unofficially Windows Server 2003 systems. Table 8.1 lists OS
Scan Locally
Scan Remotely
Windows 9x, ME
NT Workstation
Win2K Professional
Windows XP
Windows XP
Professional using
simple file sharing
Windows XP Home
Windows Server 2003
Yes (but not officially
supported in version
Table 8.1: Where to run and what to scan using MBSA.
Chapter 8
Before a successful scan can be run, the user running the scan must have local administrative
privileges on the system to be scanned. Thus, if you are running a scan, you must be logged on to
the scanning machine using an administrative account in the domain of the scanned machine.
The application will not prompt you to enter alternative user account names and passwords if
your currently logged on account is not valid. If you want to scan a subnet, you must have
administrative privileges on every machine in the subnet or it will not be scanned. The scanning
system must meet several requirements:
Win2K or Windows XP system
Internet Explorer (IE) 5.01 or later or other versions of IE and an XML parser
XML parser (MSXML version 3.0 SP2)—An XML parser is part of IE 5.01 or later;
however, if you’re running an earlier version of IE, you can install version 3.0 SP2 of the
XML parser during the installation of MBSA or obtain it from the Microsoft Web site.
If you are going to remotely scan IIS computers, you will need to install IIS Common
Files on the computer from which the scan will be made.
The remotely scanned system must meet the following requirements:
NT 4.0 SP4 and later, Win2K, or Windows XP Professional
Server service must be running
Remote registry service must be running on Windows XP and Win2K systems
Windows Server 2003 can be scanned, but scanning of beta products is not officially
Obviously, the SQL Server, IIS, and Microsoft Office scans will only be completed if these
products are located on the scanned computer.
Getting Secure the MBSA Way
During the installation, you may choose to install MBSA just for your use or for anyone to run.
However, MBSA can only scan computers for which its user has administrative privileges, so
installing for anyone to run is the equivalent of installing for any administrator to run, not just
anyone. MBSA is started by clicking the desktop icon or running it from Start menu, Programs,
Microsoft Security Baseline Analyzer. It can also be run from the command line. Next, you can
make scans or review scan reports. Three scanning choices are possible: scanning the local
computer, scanning one remote computer via IP address, or scanning a range of computers or an
entire domain. The scan reports, one for each computer scanned, are then saved to the local
machine in the %userprofile%\SecurityScans folder and can be reviewed at any time.
Scan reports are stored in the user profile of the user who performed the scan. Thus, they are not
normally viewable by another user of the computer. However, precaution should be taken to ensure
the security of the scan. Information about the status and configuration of any computer should not be
made widely available. Best practices include performing the scan remotely for most systems and
using Encrypting File System (EFS) to secure the reports. Be aware, however, that extremely
sensitive systems do not allow remote administration, and thus, should not be configured (by enabling
the remote registry service) for remote scanning. These systems should be reviewed for proper
security configuration and patch updates from the console.
Chapter 8
Each report consists of the results of reviews in several areas along with details of what was
scanned and instructions about how to correct the situation. General security settings are marked
with a red x if they are very weak, medium issues with a yellow x, and good settings are marked
with a green check mark, as Figure 8.4 shows. Yellow x’s may also indicate an area which
MBSA cannot conclusively determine. For example, some hotfixes should only be installed in
certain circumstances. The basic areas scanned are:
Service pack and patch updates—MBSA uses a version of HFNetChk to check registry
key, file versions, and file checksums against an XML file at the Microsoft download
center Web site to determine whether the computer is up-to-date with service packs and
updates. Each missing hotfix is reported, and a link to associated Knowledge Base
articles and the download location is provided. Administrators may access, download,
and apply a missing patch directly from within MBSA. No attempt however is made to
fully explain the patch or to link multiple patch requirements into a single install.
Passwords—MBSA checks the local Security Accounts Manager (SAM) database for
weak passwords by scanning for accounts for which the password is blank; is the same as
the username; is the same as the machine name; or equals password, admin, or
Administrator. This check is not made on domain controllers.
Account checks—Accounts are checked for password expiration and the number of
accounts for which passwords do no expire is reported.
Administrator group check—The number of members in the Administrators group is
reported—more than two administrators on a local machine is considered questionable.
Guest account—The status of the guest account is checked. Having the guest account
disabled is a plus.
Restrict anonymous—MBSA considers a restrict anonymous setting of 2 to be the goal
(includes a brief explanation of these settings).
File System—The file system on all drives is checked to see if it is NTFS.
Auto Logon—The system is checked to make sure auto logon is not configured.
Chapter 8
Figure 8.4: MBSA returns information about common vulnerabilities and how to fix the situation.
Other areas are evaluated, including:
Auditing—Is it enabled? Are both logon success and failure checked?
Services—Are any of the especially dangerous services (RAS, Telnet, FTP, WWW, or
SMTP) installed?
Shares—Which shares are present and what are the permissions settings on them?
OS version
If IIS or SQL Server is present on the machine and the check boxes to scan them have not been
cleared, MBSA will also look for common vulnerabilities in those products.
Password checks can take a very long time if multiple accounts exist. In addition, if account
lockout is set, it is possible that the multiple password tests—because most should and will fail—
may lock out accounts. MBSA documentation suggests that account lockout is changed so that
such will not happen. However, early reports of account lockout were reported. Password checks
are not run against domain controllers.
Chapter 8
Now What?
There is actually quite a lot of useful security information available in a scan, but MBSA has the
same problems that any vulnerability checker has. Users of the scanner must realize that there are
no hard and fast security rules. When the scanner tags having more than two administrators as a
vulnerability, it cannot take into account the number of computers that are managed in a
network. Networks with hundreds of computers will require more than two administrators to
manage them; networks with thousands of nodes even more. Likewise, hotfixes should be
evaluated on their own merit. If a hotfix should only be applied in some circumstances, it is
difficult for a vulnerability checker to indicate so in a manner that will make everyone think
before applying it. A third issue also involves the application of hotfixes. MBSA provides a click
through so that the administrator can locate, download, and apply a hotfix immediately.
However, when multiple hotfixes are needed, there is no way to automatically build a chain.
Savvy administrators will use the report to determine status of the machine, then use other
methods to bring the system up to date.
Nevertheless, MBSA is a useful tool. Home users and network administrators can evaluate basic
security against a common norm. They can, and should, make decisions about which parts of the
report are valid for themselves.
Q 8.3: We have a problem with employees who bring in their home
laptops and plug in to the office network. Although I can control the
software and function of computers in my network, I have no control
over these renegade machines: whether they have antivirus software
installed, are running IIS, or are a Dynamic Host Configuration
Protocol server. They’re causing havoc. Is there a way I can prevent
these rogue computers from running on my network?
A: You cannot keep employees (or anyone else for that matter) from bringing in their own
computers and attempting to connect to your network. However, you can secure access to your
company’s Windows 2000 (Win2K), Windows XP, and Windows Server 2003 computers and
services. To do so, you’ll create an IPSec policy to be used on each computer. The policy will
ensure that each computer connection is authenticated. (Before other communications take place,
each computer will present credentials that prove it is an authorized computer on your network.)
Rogue computers, computers that are not under your control, will not have the credentials and
thus cannot participate. To help you create this IPSec policy, I’ll start with a brief explanation of
how IPSec works.
Creating IPSec policies that restrict connections can be a career-limiting project. You must test this
approach thoroughly—you might need to adjust the policies on some computers to allow some
applications and services to function.
Chapter 8
Microsoft’s IPSec Implementation
Did you ever avoid doing something because you thought it was going to be very complex and
hard? Were you pleasantly surprised when you actually tackled the chore and found it to be
straightforward? IPSec is like that. Is the protocol complex? Read the Request for Comments
(RFC) and you’ll think so. However, the RFC uses enough code to explain the protocol that a
programmer can use the RFC to write an implementation of IPSec. The fact is, you don’t have to
be able to write the code to understand how IPSec works and to benefit from using it.
IPSec enables secure TCP/IP communications between two computers. It can protect against
attacks. Table 8.2 describes IPSec features, the security protection they provide, and the possible
attacks they foil.
IPSec Feature
Security Principle
Deflects these Attacks
Mutual authentication
Identifies each computer to
the other. Each must present
credentials that the other
computer trusts.
Identity spoofs, man-in-the-middle attacks
Confidentiality—data is kept
A sniffer can capture the packet, but the
data payload cannot be read
Message digests/checksum
Message integrity—we know
the message has not been
changed in transit.
Message spoofing—if the packet is
captured and information is modified
before sending on the packet, the
checksum calculated by the receiving side
will not match that attached by the sender
Filtering by Domain Name
System (DNS) name, IP
address, or subnet and
Transmission Control
Protocol (TCP) and/or User
Datagram Protocol (UDP)
port numbers
Least privilege.
Attacks directed at specific ports; filter
known or questionable connections
Table 8.2: IPSec features, security principles, and attack profiles.
Chapter 8
How IPSec Works
Although you can create and assign a Microsoft IPSec policy from the command line, a rich GUI
interface is available from the local security policy and is a part of Group Policy. IPSec policies
are composed of IPSec rules. Rules contain a filter list. A filter list is composed of the elements
defined in Table 8.3.
How will the computers mutually authenticate? Choices are shared key, Kerberos,
and certificates.
Filter Action
What will happen if the filter is triggered?
Tunnel Setting
Will a tunnel be used? If a tunnel is not to used, the IPSec policy is said to be in
IPSec transport mode.
Connection Type
Should this filter work on the entire network? The local LAN? Only remote
Table 8.3: Items that a filter list contains.
A filter list may contain many filters. Filters are composed of the elements described in Table
8.4. A policy is created by creating a rule complete with a filter list. Assigning the policy to the
computer activates the policy. When a packet triggers the filter, the action selected in the filter
action will occur.
Is this packet from my computer? A particular computer? All computers in a
Will this packet go to my computer? A particular computer? All computers in a
Should the filter be mirrored (packets in the opposite direction)?
Protocol Type
Which protocol—TCP or Internet Control Message Protocol (ICMP)?
From, To port
All ports? Or a specific port.
Table 8.4: Elements contained in filters.
There are three types of filter actions, and policies are usually described by referring to the type
of filter action implemented.
Permit—Allow the specified traffic to proceed.
Block—Prevent the specified traffic from leaving or being received by the computer.
Negotiate Security—Negotiate with the other computer including selection authentication
method, integrity protocol, encryption protocol, and so on. This type of policy is the only
one of the three that requires a policy be present on two computers. We will use this
policy type in our example.
Chapter 8
Authentication Header (AH) provides authentication, integrity, and anti-replay for the entire
packet. It does not provide confidentiality (it does not encrypt the payload). If you choose to use
only AH, the data will be readable, but it is protected from tampering by AH’s integrity feature.
If the data that is received is not the data that was sent, the packet is dropped. AH uses a keyedhash algorithm (Microsoft choices are either SHA-1 or MD-5; the standard does not specify
which hash algorithm must be used). Figure 8.5 illustrates that the entire IP packet is signed and
notes the insertion of an authentication header. The authentication header details are described in
Table 8.5.
Figure 8.5: AH signs the entire IP packet.
Next header
Indicates the protocol
The length of the AH header
Parameter Index
A combination of the SPI, the destination address, and whether AH or Encapsulating
Security Payload (ESP) is being used identifies which security association
(connection) this packet is part of. Many IPSec communications can be occurring at
the same time, each represented by two security associations. The SPI assists the
receiving computer in determining to which security association this particular packet
Provides anti-replay protection. Each packet receives a 32-bit incrementing number
that allows the receiving computer to detect whether a packet has been previously
received. If a packet with a duplicate number is received, it will be rejected as a
possible replay.
Data that guarantees the integrity of the message: an integrity check value (ICV)
calculated over the IP header, AH header, and IP payload. The entire packet, with
the exception of data that may change in transport, is signed.
Table 8.5: AH details.
ESP provides this type of protection as well as confidentiality. An IPSec policy that uses ESP
will encrypt the data.
Chapter 8
If a negotiate policy is triggered, several steps must occur before the session between the
computers can take place. Two important things should be considered. First, both policies need
to match in several areas. If SHA-1, for example, is chosen as the integrity protocol on
ComputerA, it must also be chosen for ComputerB. Second, the authentication method may need
further configuration. Kerberos is the default. To use it, all systems must either be members of
the same Win2K or Windows Server 2003 forest or be members of different Windows Server
2003 forests that have a cross-forest trust. If certificates are chosen as the authentication method,
the Certificate Authority (CA) source must be correctly chosen, each computer must have a
certificate from this CA, and a copy of the CA certificate must be in the Trusted Root Certificate
Store of each computer.
The negation process is composed of two parts: Main Mode and Quick Mode (see Figure 8.6).
Main Mode must successfully complete first. In Main Mode, the computers authenticate,
establish a security association to share information and calculate a master key. The master key
will be used in Quick Mode to calculate session keys. The master key is never exchanged;
instead, some small piece of data is shared, a complicated mathematical formula that
incorporates this shared data is used. As a result of the nature of the calculation, the key will be
the same, but any data captured during this process is not enough for a third-party to calculate the
same master key.
Figure 8.6: IPSec negotiation.
After the successful completion of Main Mode, Quick Mode creates two security associations.
One security association is used for output and the other for input. Security associations are
uniquely identified by the SPI, the security protocol, and a negotiable key. Data is then formatted
according to the policy and passed to the receiving computer. It is possible for Main Mode to
complete successfully and for Quick Mode to fail, or for successful transmission to begin and
then fail, due to faulty policy configuration.
Chapter 8
Writing an IPSec Policy to Keep Rogue Computers Out of Your Network
Now that you know something about IPSec, you can use it to keep rogue computers away from
your resources. To do so, we’re going to place an IPSec policy on every authorized computer on
your network. We want to make sure that before any communication between two computers
takes place, they authenticate themselves to each other. Before we deploy this solution in your
production domain, we’ll write the policy on two computers, ComputerA and ComputerB, and
test by attempting communications between ComputerA and ComputerB and a third computer,
ComputerC, which does not have the policy. The first step is to create the policy on ComputerA:
1. Open the Start menu, Programs, Administrative Tools, Local Security Settings, right-
click IPSec Security Policies on Local Machine, select Create IP Security Policy, then
click Next.
2. Enter a name for the policy, click Next, clear the Activate the default Response Rule
check box, click Next, and click Finish. (Leave the Edit properties item selected.)
3. On the Rules tab, click Add, click Next, leave the This rule does not specify a tunnel
radio button selected, click Next again, leave the All network connections radio button
selected, and click Next.
4. On the IP Filter List Wizard page, click Add to add a new IP filter list, then enter a name
for the filter list, click Add to add a filter, name the filter, then click Next.
5. Use the drop-down arrow box to change to Any IP Address, click Next, use the drop-
down arrow box to change to My IP Address, click Next, leave the protocol type as Any,
click Next, then click OK.
6. On the Filter List page, select your filter, click Next, and on the Filter Action page, click
Add to create a new filter action, then click Next.
7. Enter a name for the filter and click Next.
8. Leave the Negotiate security radio button selected, click Next, leave the Do not
communicate with computers that do not support IPSec radio button selected, and click
9. Select the Custom radio button, and click Settings.
10. Click the Data and address integrity without encryption (AH).
11. Click OK, click Next, then click Finish.
12. On the Filter Action page, select your new filter action, click Next, then click Finish.
For the first test of the rule, we’ll use the shared-key authentication method.
On the Authentication Method page, which Figure 8.7 shows, select Use this string to protect the
key exchange (preshared key) check box. This setting is not secure for authentication because
anyone who can view the security policy can see the key. It is, however, a good choice for
testing. We will know that our policy works (and if it does not work, that the problem is not a
result of our use of certificates or a Kerberos issue). This setting also makes troubleshooting
IPSec policies easier. After our initial test, we will change this setting to require a certificate.
Enter a test string, and click Next, click Finish, then click OK twice.
Chapter 8
Figure 8.7: Setting the authentication method.
Before you can test the policy, two steps must occur. This policy must be copied to ComputerB,
and you must assign the policy to both computers. This step is an important step—you can create
a policy, but it will not take effect until you assign it. You could re-create the policy on
ComputerB, but the simplest way to avoid mistakes is to export the policy from ComputerA to a
file, then import the policy on ComputerB. First, create a new folder on ComputerA, and share it.
Then open the Local Security Policy, right-click the IPSec Security policy on Local Machine,
select All Tasks, and select Export Policies. Browse to the new folder, enter a file name, and
click OK. A copy of the policy is now available at the shared location.
On ComputerB, map a network drive to the share on ComputerA. Open the Local Security
Policy, right-click IPSec security policy on Local Machine, select All Tasks, and select Import
Policies. Browse to the mapped drive, select the policy, and click OK. The policy is transferred
to ComputerB. Disconnect the network drive on Computer B.
From ComputerC, map a drive to the share on ComputerA. DO NOT import the policy. You
have mapped the drive only to show that before the implementation of the policy, ComputerC
can access the share on ComputerA. Disconnect the network drive on ComputerC.
Now you are ready to assign and test the policies. On ComputerA and ComputerB, right-click
the policy that you created, and select Assign. From ComputerB, map a drive to the share on
ComputerA. You should succeed. Next, attempt to map a drive from ComputerC to the share on
ComputerA. You should get a warning that the network cannot be found, as Figure 8.8 shows.
Chapter 8
Figure 8.8: ComputerC, sans policy, cannot connect to the network share.
OK, so you believe you have a workable policy, but how do you really know? What if things do
not work the way you expect when you assign the policy? The first troubleshooting tool to turn
to is the IP Security Monitor. This tool is much more flexible in Windows Server 2003. You can
use it to determine whether an IPSec policy is in effect on a computer, to see the security
associations, and to determine whether the policy is working as expected. If, for example, your
policy requires the encryption of packets, the tool will tell you whether any packets are traveling
between the two computers unencrypted. In our case, the tool will tell you there is no encryption
(we did not include encryption in the policy) as well as how many packets have been
authenticated. Figure 8.9 shows a capture of IP Security Monitor in action. You should load the
tool on both ComputerA and ComputerB, and monitor the activity during your tests. IP Security
Monitor is a Microsoft Management Console (MMC) snap-in.
Figure 8.9: IP Security Monitor in action.
Chapter 8
Changing the Authentication Method
As you will recall, our goal was to provide the authentication of all communications between
computers on the network. The policy we created does so. But couldn’t just anyone who
understands IPSec create their own policy and get right back in the game? As you’ve seen, there
is nothing really complicated about this policy. It would be easy to re-create. The only thing
preventing an outsider from doing so would be the shared secret we used as a password. This
secret is not a good barrier, especially not to users of your network. Remember, they’ll be using
legitimate machines as well. If they can view the policy, they can see the password. So you will
lock out a great number of people, but any sophisticated individual will discover the trick, and if
they have Win2K, Windows XP Pro, or Windows Server 2003, they can create their own policy.
The solution to this problem is to change the authentication method. If all computers that should
be part of the network are joined in a Win2K or Windows Server 2003 domain, you can use
Kerberos. Remember, the computers are authenticating, not the users. So a user bringing his or
her own laptop from home may be able to logon to the network using his or her user ID and
password, but the user’s computer, because it is not joined in the domain, cannot logon to the
network. Changing the IPSec policy to require Kerberos is simple; you simply change the check
box on the Authentication Methods page.
Another solution is to require that the computer use a certificate to authenticate. This choice will
require a little more work, but will provide a more secure solution. Although it is possible that
users could join their computers to the domain, if you have correctly set up your environment,
they cannot obtain a certificate for their computer. This solution is also useful in a workgroup in
which Kerberos is not a possibility.
It is possible with Windows Server 2003 and Win2K to automatically distribute certificates to
machines. To do so, the computers must be joined in a Win2K or Windows Server 2003 domain, and
you must be using an Enterprise CA. In a large environment, this method is the only practical way to
distribute them. You will have to adjust user rights to ensure that ordinary users cannot join a
computer to a domain, and take the slight risk that someone will get around that. (By default,
authenticated users can join as many as 10 workstations to a domain; you can modify this setting by
changing User Rights and by using ADSI Edit to modify a value in Active Directory—AD.)You should
also remember that once the user’s computer is joined to your domain, the user could be controlled
through Group Policy. If, however, you have few computers to service and want to individually control
the distribution of certificates, do not configure Certificate Services to automatically provide
certificates to computers.
Requiring Computer Certificates for Authentication
If you have an existing Microsoft CA in your environment, you may request a certificate for a
computer by using the Certificate Services Web-enrollment pages. If you do not, you may build
a Microsoft Standalone CA as I described in Question 1.3. Changing the IPSec authentication
method to use certificates is a three-step process. First, if your CA is not installed on a member
server in a Windows Server 2003 or Win2K domain, you must acquire a copy of the CA’s
certificate for each computer that you want to be able to authenticate. Then you will need to
obtain a unique server certificate for each computer, and you’ll need to change the IPSec policy
to require them.
Chapter 8
The following steps assume that the CA is already present, and that you are a Certificate Services
administrator and member of the Local Administrators group on ComputerA and ComputerB.
Acquiring a CA certificate requires a visit to the CA’s certificate enrollment Web pages. On
ComputerA, open IE, and go to the Web enrollment site http://Cacomputername\certsrv. Select
Obtain a CA certificate to install the certificate. Repeat this process for ComputerB.
To provide server certificates for authorized computers, on ComputerA, open IE, and go to the
Web enrollment site http://Cacomputername\certsrv. Click Request a certificate, as Figure 8.10
Figure 8.10: Requesting a server certificate from the Web-enrollment site.
Select Advanced request, select Certificate request using a form, click Create and submit a
request to this CA, select Server Authentication Certificate, select Create new key, and leave the
selection of CSP on Microsoft Strong Cryptographic, unless your CA has been set up with an
alternative CSP. If such is the case, select that CSP instead. Fill out all the information, select the
Use local machine store check box, as Figure 8.11 shows.
Chapter 8
Figure 8.11: Make sure to request a computer certificate.
Click Submit. A message will inform you that the request has been submitted and is pending
approval and requests that you return to the Web site at a later time. Repeat the process for
ComputerB. On the CA, open the Certificate Authority console, expand the Pending Certificates
container, right-click the certificate request for ComputerA, select Issue Certificate, right-click
the certificate request for ComputerB, and select Issue Certificate. Return to ComputerA and the
Web-enrollment homepage. Click Check on pending request. You should see the approved
request for this computer. Click the request. On the page announcing that the certificate has been
issued, click Install this certificate. Repeat this process for ComputerB.
You must process requests for certificates from the Standalone CA promptly. The request process
will time out. Even if a certificate has been issued by the CA, if the user does not return to the Web
site within 10 days to obtain the certificate, the user will not be able to do so.
To verify that the certificate has been placed in the certificate store for the computer, you will
need to inspect the store. To do so, open the Start menu, select Run, and enter MMC. From the
File menu, choose Add or remove snap-in. Click Add, then select Certificates. In the pop-up
window, select This computer for the certificate store to open, and click OK. Expand the
Personal container. The certificate should be located here. Repeat the process for ComputerB.
Chapter 8
Now that certificates have been deployed, you can change the IPSec authentication method. To
do so, open the Local Security policy on ComputerA, expand the IPSec Security Policies on
Local Machine, and double-click your policy. On the Rules tab, select the policy you created,
and click Edit. Select the Authentication Methods tab, click Add, select Use a certificate from
this certificate authority, use the browse button to select your CA, click OK twice, then click
Close. Repeat these steps for ComputerB.
To test the policy, map a drive to the share on ComputerA from ComputerB. You should be
successful. Next, attempt to map a drive from ComputerC to ComputerA. You should be
Q. 8.4: I’m always a little leery of using secedit to apply a security
template. What if the system is not working the way I want it to after I
apply the template?
A: It is certainly possible to make mistakes when configuring security settings. That is why you
must thoroughly test changes made in a security template by implementing it in a test
environment. However, no matter how carefully a template has been tested, it is possible that
some change will wreak havoc on a particular machine. After all, it is impossible to test every
possible scenario. The GenerateRollback switch of the secedit command can help you recover
from this situation. If this switch is used prior to a security template application, a rollback
template is created that you can use to return the system to its former state. Although doing so
will have no effect on changes to the permissions settings made in the File and Registry nodes of
the security template, all other settings can be returned to the pre-rollback template state.
Here’s how it works: When you use GenerateRollback, it walks the new template looking for
configured settings. When it finds one, it analyzes the current computer’s database settings and
places the configured setting in the new rollback template. So, for example, if the new template
secure.inf changes the password length to 8 characters, secedit reads the old password length of
0, and places this value in the new rollback template, rollbacksecure.inf. No settings are applied
during the secedit and GenerateRollback process. (Your new template must be applied in a
separate action, for example, by using a secedit cfg command or the Security Configuration and
Analysis console.)
After the new template is applied, its changes can be rolled back by using the generated rollback
template. However, if other templates have been applied since the original change, the rollback
template will not be able to reverse those change made. If you think of the rollback template as a
sort of backup, you will not get confused as to what it can do.
Chapter 8
To use the secedit GenerateRollback command, use the following syntax. The switches are
defined in Table 8.6.
secedit /GenerateRollback /CFG filename.inf /RBK
SecurityTemplatefilename.inf [/log Rollbackfilename.inf] [/quiet]
GenerateRollback does not track registry and file permissions settings. Thus, any changes made
using a security template cannot be rolled back using the template produced by the secedit
/GenerateRollback command. You should always use caution when changing permissions settings
and document thoroughly in case you later discover you have made an error.
Generate a
template that can
be used to roll
back to the
previous state
A good practice is to always generate a rollback template just
before applying the template. Doing so ensures that the
rollback template was created just prior to the template’s
The name of the
template of which
to create a
rollback template
This is the template you will be applying. (the template must
already exist). When the command is run, it will create a
reverse of this template and save it with the name entered after
the /RBK switch.
The name of the
rollback template
This is the template that will be generated and can be used to
rollback the security settings to the previous state. You can
give it any name you like, though I would suggest a meaningful
name such as the template name with the word rollback
appended. Be sure to specify the path where you want the
template stored.
The path where a
log of the activity
should be located
If no log directory is specified the %windir%\security\logs folder
will be used. The file produced is scesrv.log.
Activity should not
This is a useful switch when you want to include this command
in a batch file that will run in the background.
Table 8.6 Secedit switches for GenerateRollback.
To produce a simple rollback template and test its function, open a new Microsoft Management
Console (MMC) console, and add the Security Configuration and Analysis and Security
Templates snap-ins. Create a new security template by right-clicking the Security
Templates\%windir%\security\templates node, selecting New template, entering a name similar
to sample.inf, and clicking OK. Doing so creates a shell template in which nothing is configured.
Open sample.inf, and set the password length (Windows Settings, Security Settings, Account
Policies, Password Policy, Minimum password length) to 10 characters. Right-click the
sample.inf template, and select Save. Right-click the Security Configuration and Analysis node,
and select Open database. Enter a name for the database, and click OK. Save the MMC console.
Open a command prompt, and enter the following command (see Figure 8.12)
Chapter 8
secedit /GenerateRollback /CFG
%windir%\security\templates\sample.inf /RBK rollbacksample.inf
Press Enter to execute the command. When asked if you want to continue, press Y. When the
command has completed, check the log at %windir%\security\logs\secsrv.log. At the commandline, enter the following command to apply the sample template
secedit /configure /db %windir%\security\templates\sample.sdb
/cfg %windir%\security\templates\sample1.inf /overwrite
Use the local security policy to inspect the password policy to determine whether the change has
been made. Use the following command to apply the rollback template
secedit /configure /db %windir%\security\templates\sample1.sdb
/cfg %windir%\security\templates\rollbacksample1.inf /overwrite
Use the local security policy to inspect the password policy to determine whether the change has
been made. The password length requirement should be returned to 0 password length.
Figure 8.12: Note the answer to the file and registry permissions question and the normal, successful
completion of the command.
Q 8.5: I’d like to prevent clients on my network from using or
receiving Telnet commands and from running a Web server. Can this
be done?
A: There are two ways to lock down these services. First, the services can be disabled on the
workstation and in Group Policy. A reapplication of Group Policy will reset the services to
disabled, should they have been improperly enabled. A second and more flexible way is to use
and IPSec blocking policy.
Chapter 8
IPSec Blocking Policy Basics
In many discussions of IPSec, very detailed information is given about creating negotiation
policies to control and keep private communications between two computers. However, IPSec
can also be used to create other types of policies. These policies do not engage in any
negotiation, nor do they encrypt anything. These policies are written to either accept or block
certain types of packets. They can be used to prevent communication from being passed up the
stack for further processing, or to prevent communication from leaving the computer. They can
also be used to allow communication, and often allow and blocking policies are used together for
special effect. For example, you might deny all Telnet communication with a computer, but
allow Telnet access from a particular computer.
Blocking and allowing policies can be written by writing filters for specific protocols and ports
or to block or allow traffic to or from an IP address, a range of addresses, DNS, WINS, or DHCP
servers. To learn how to write these types of policies you should first start with a simple one.
Your request is perfect for this introduction.
Creating and Testing the Policy
To test your understanding of this option, create the following policy on a single computer in
your test lab that has IIS installed. You will use the Local Security Policy of the computer to
create the policy. To test it, make sure that the Telnet service on the test server computer is not
disabled. Use a test client computer to Telnet to the test computer, then end the session. Use this
client to browse to the Web site on the test computer, assign the IPSec blocking policy as
instructed later, and use the client to attempt to Telnet to the test computer. You should be
blocked. Use the client to browse to the Web site, you should be blocked. Unassign the policy,
and retest Telnet and the Web site. You should be successful.
When you have completed a successful test, you can export the policy (right-click the IPSec
Policies on local computer, and select Export policies to store the policies in a file). You can then
import the policy to a Group Policy Object (GPO) you have created on the appropriate
organizational unit (OU) in your domain. This OU should only have computer accounts for the
computers that that you want to block these protocols for. To create the policy, create a console
and add the Group Policy Snap in. Navigate to the Local Computer Policy, Computer
Configurations, Windows Settings, Security Settings, IP Security Policy on Local Computer
container, and select Create IP Security Policy. Click Next on the Welcome screen, then enter a
name for the policy and a description, and click Next. Clear the Activate the default response
rule check box. The default rule responds to IPSec requests from other computers. Our blocking
rule has no need to do that. Click Next, then click Finish to close the wizard.
On the Rules page, clear the Add Rule Wizard check box. The wizard steps through
configuration of the tunnel, authentication, and other properties that are not used in a blocking
policy. Click Add to add a rule, and on the IP Filter List page of the New Rule properties, click
Add to add a filter. Enter a name and description for the filter list, as Figure 8.13 shows, then
click Add to add a filter.
Chapter 8
Figure 8.13: Naming the Filter List.
Enter a filter description. If this filter is not to be mirrored, clear the Mirrored check box (see
Figure 8.14). Click Next. A mirrored filter also matches packets with the exact opposite source
and destination address. In this first example, we are writing a filter to block Telnet traffic
initiated in either direction, so mirroring is appropriate.
Chapter 8
Figure 8.14: Determine whether a filter should be mirrored.
The source address is indicated as My IP address; change it to Any address, then click Next. The
destination address is indicated as Any IP address, change it to My IP Address, then click Next.
Use the drop-down box to select the TCP protocol, then click Next. Leave the From any protocol
check box selected, and select the To this port check box, then enter 23 in the text box below,
and click Next. Select the Edit Filter check box, and click Finish to end the wizard.
Examine the filter. You should have a filter that identifies any packets from any address going to
the host computer on port 23. Because the filter is mirrored, it will also identify any packets from
the host computer going to port 23 on any other computer. Click OK to close the filter properties
Repeat this process, except this time you will create a non-mirrored filter to identify packets
coming from any IP address and any port to this host on port 80. This filter will not be tripped by
any packets leaving this computer to port 80 on another computer. This computer can be used to
access Web sites. At this point, you should have two filters in the filter list (see Figure 8.15).
Click OK to close the filter list.
Chapter 8
Figure 8.15: The filter list.
On the IP Filter list property page, select the filter list you have created, select the Filter Action
page, and click Add to add a filter action. Click Next on the welcome page, then enter a name for
the action and a description, and click Next. Select block, click Next, select your filter action,
and select the Connection page (notice that All network connections is selected by default). You
could, instead, decide to only block these protocols if they were on the local LAN or from a
remote source. Click Close to return to the Rules page, and click OK to close the policy. To
activate the filter, right-click it in the details pane, and select Assign.
Q 8.6: How can I secure communications between two computers on
the LAN?
A: As you know, most computer-to-computer communication can be captured and the data read
by anyone who has access to the network. Years ago this was less of a problem—less data of a
sensitive nature traversed the LAN, and protocol sniffers were hardware-based and expensive.
Now we give no real thought to the nature of data that is available, and sniffers are cheap, even
free, and knowledge about how to use them is very widespread. This does not mean that
someone is taking the time and trouble to monitor communications on your LAN, but that you
should give some consideration to protecting internal communications. You cannot assume that
data is safe, or that nothing of value is exposed.
Chapter 8
Windows Server 2003, Windows 2000 (Win2K), and Windows XP Professional can use IPSec to
protect communications on the LAN. By creating and assigning IPSec policies on two or more
computers, you can ensure that communications between them are secured using encryption,
integrity, mutual authentication, and so on. You can specify all communications as being
effected, or opt to trigger policy negotiation and thus protection, for only specific protocols or IP
address ranges. I’m going to outline a scenario and step you through implementation while
defining terms as I go. You can adapt my scenario to yours by adjusting the filters,
authentication, encryption, and integrity parameters to those you and your company require.
In my scenario, I’ve decided to follow through on the example in Question 1.6, in which an
administrator needed to setup sharing of encrypted files. The decision to place the files on a file
server has been made. The file server has been hardened, the share restricted, and the encryption
and sharing process tested on sample user accounts and files. What remains is to put into place
encrypted and authenticated communications. We know we’ll eventually have multiple users
connecting, but to start, we’ll build the policy and test it between one user and the file server.
After this setup is up and running, it’s a simple process to place the IPSec policy on an
organization unit (OU) in which computers used for communication will have their accounts.
It’s important to remember that communication takes place between two computers. The computers
mutually authenticate, not the users.
Before creating the policy, we have some decisions to make. For each decision, I’ll give you my
recommendation. It’s important to make these decisions before creating the policy. Policy
parameters must match or communication won’t work. (I’ll explain where you can find the
following policies later in this tip.)
Authentication—Three choices are available: shared key, Kerberos, and certificate.
Shared key is primarily for testing purposes. It lets you eliminate Kerberos or certificates
as the cause of failure. It’s a good practice to test the policy first with shared key, then
move to another authentication. If you’re comfortable and both computers are members
in the forest, Kerberos can be used at startup. Certificates are not difficult to use, but each
computer must have one and must trust the root source of the other computer’s
certificate. Be sure to test your policy with a shared key before going with certificates.
The rational behind this recommendation is that the shared key is visible in the GUI for
any administrator to see and visible in clear text when certain troubleshooting tools are
used. Using it is sort of like writing down your password on a post it note and putting it
on your monitor.
Encryption—Choices are DES or 3DES. The important consideration here is that for each
phase, the policy on each machine matches the other. If 3DES is chosen for the file server
policy and the client machine is set at DES, negotiation will fail and no communication
will take place. Because default choices create a list that includes both types (negotiation
will settle on the highest strength that both computers can do), I’d leave this setting alone.
After the policy is tested and working, it can always be tweaked to remove the weaker
Integrity ensures that each packet has not been tampered with and, because it is signed by
the sending computer, authenticates that the packet came from the correct source.
Choices are SHA1 or MD5. Once again, I recommend leaving the default setting.
Chapter 8
Diffie-Hellman group—During Main Mode (the first part of negotiations), a master key
is calculated using the Internet Key Exchange (IKE) algorithm using large prime numbers
in the calculation. The Diffie-Hellman group specifies the relative size of these prime
numbers. The larger the prime, the stronger the key, the longer time encryption takes.
Time is not the only consideration here; like authentication, integrity, and encryption,
each policy must match, or negotiation will fail. I recommend leaving the default setting.
Key regeneration—A master key is created in Main Mode or the IKE phase. The master
key is used to create the session keys—the keys used to encrypt the data. The session
keys can be used for the entire session or can be changed every so many packets or
minutes. Likewise, the master key can be regenerated over time. The principal is that
frequently changing keys keeps more of the data secure. If an attacker should decrypt a
key, that key will only be good on a small part of the data. Once again, the default
settings are adequate for our purposes and a good place to begin testing.
Filter—The main consideration is to determine when the policy will be brought to bear.
Our choices are to trigger the policy based on a specific protocol, specific IP addresses,
or both. In many cases, the IPSec policy is developed to secure certain types of
communication (such as Telnet or that which is generated from or to a specific
computer). In our case, we could establish the policy to ensure encryption between the
two computers only for file transfer. For our test here we’ll set a single filter based on IP
addresses. You can expand the filters and make the encryption more specific if you
Create the Policy
Now we are ready to create the policy. After we do so, we’ll test it. To create the policy, open the
Administrative Tools menu, select Local Security Policy, right-click the IP Security Policies on
the Local Machine, and select Create IP Security Policy. On the Welcome page, click Next, enter
a name for the rule, and click Next again. Clear the Activate the default response rule check box,
then click Next, and click Finish. Select the General Page to examine IKE (or Main Mode)
policy settings, then click Advanced. Note that a new master key will be generated every 480
minutes, or every 8 hours. Click Methods, and note that the security methods (encryption,
integrity, and Diffie-Hellman group, are arranged from strongest preference to lowest. This
arrangement allows negotiation to try several possible strengths. Should the other computer not
be able to match any of these, the negotiation will fail. Click Cancel twice, and return to the
Rules page.
On the Rules tab, click Add to add a Rule. An IP filter list consists of one or more filters that
specify IP addresses and/or protocols for which the rule will fire. On the Welcome page, click
Next. On the tunnel endpoint page, leave the default setting: the This rule does not specify a
tunnel check box selected. IPSec can create a tunnel should you want to tunnel data from one
network to another across a third. Because all machines are on the local LAN, this setup is not
necessary. Click Next.
On the Network tab, select All network connections. We want the rule to fire no matter the
location of the client machine. Though the clients should be on the local LAN, what if their IP
address is spoofed across a remote connection? Yep, if the policy fires, unless the attacker can
match the policy and authenticate to the computer, the connection will fail. Click Next.
Chapter 8
Leave the Authentication method as Kerberos. If these computers were not member computers in
a Win2K or Windows Server 2003 domain, you would have to select shared key or certificate.
Click next. Click Add to add a filter list on IP filter list tab. Enter a name for the filter list, and
click Add to add a filter, then click Next. Enter a name the filter, and click Next. Leave the
source as My IP address, and click Next.
Use the Destination address drop-down box to select A specific IP address, enter the IP address
of the file server (see Figure 8.16), then click Next. You are telling the IPSec Policy agent that
any traffic from this computer addressed to that IP address should negotiate the connection and
use IPSec to protect the communication.
Figure 8.16: Specifying the destination address of the IP traffic.
On the IP Protocol page, leave the setting at Any, click Next, then click Finish. Doing so returns
you to the IP Filter List page. Here, you could use the Add button to create additional filters if
necessary. Click OK to return to the Filter List Page. On this page, select the filter list you just
created (see Figure 8.17), then click Next.
Chapter 8
Figure 8.17: Selecting the filter list that you just created.
On the Filter Action page, click Add. Now that you have set a trigger, you must indicate what
action will be taken. Enter a name for the filter action, and click Next. Because you want security
to be negotiated, click Negotiate security, then click Next. Leave the setting Do not communicate
with computers that do not support IPSec selected, then click Next. If your filter is triggered, you
want the communication to proceed. Communication with other computers won’t trigger the
policy. Click Custom on the IP Traffic Security Page, then click Settings. Examine the settings
for encryption and integrity. This is where settings for the Quick Mode of IPSec are established.
Phase two is where the session key is used to encrypt the data for transfer (see Figure 8.18).
Figure 8.18: Specifying the security method settings.
Chapter 8
Examine the Session key settings, which determine how frequently the session key will be
changed. Remember to set these the same for each computer; otherwise, communication might
commence, then halt after the first key change, because it will no longer match that on the other
computer. We’ll leave the settings at their defaults to make our job easier. You might determine
that they need to be adjusted, just don’t forget to make them match on each computer.
Click Next, then click Finish to return to the Filter Action page. Select the filter action you just
created (see Figure 8.19), then click Next, and click Finish to return to the New Rule Page.
Figure 8.19: Selecting the filter action you just created.
Examine each page of the rule to make sure you have it correctly written, then click OK, then
Close to complete the rule.
Before you can assign, or activate, the rule, you must complete its duplicate on the file server.
The simplest way is to export a copy of the IPSec policies on this computer, then import it at the
file server and make changes. To export the rule, right–click the IP Security Policies on Local
Computer, and select All Tasks\Export Policies. Browse to a floppy disk, and save the file. On
the file server, open the Local Security Policy, right-click the IP Security Policies, and choose
All Tasks\Import policies. Locate the policy file on the floppy, and click Open
Before you can use the policy, you must adjust it for the new computer. Double-click the policy
to open it, and click Edit to edit the rule. Double-click the filter list to open it, and click Edit to
edit the filter properties. You will change the source and destination address values. The source
address will still be My IP Address, remember that now represents the IP address of the file
server. However, the destination address should be changed to the client IP address. Later, after
the policy is tested, you might need to make a filter for each client machine IP address, or, if they
represent a contiguous range of IP addresses, you can modify the filter list to reflect that. Click
OK four times to save the changes and close the policy.
Chapter 8
Testing the Policy
Now the policy is ready to be tested. You must first assign the policy on both machines. To do
so, right-click the policy, and select Assign. The assigned policy will always be evident by a Yes
in this column in the interface.
To test the policy, map a drive to the folder share on the file server, and create a text file there. If
you are successful and can demonstrate that the communication was encrypted in transit, then
you have correctly established IPSec communications. Either you can create a file on the share or
not, so that part is easy to demonstrate. Evidence of IPSec activity is also easy to prove. A new,
IP Security Monitor Microsoft Management Console (MMC) snap-in documents activity. Be
sure to open it before beginning your test. Statistics about both phases of IPSec are documented.
Figure 8.20 shows the Security Association (SA) for Quick Mode, and Figure 8.21 shows clearly
that confidentiality (encrypted) packets have been sent and received. An SA represents IPSec
secured connection between two computers. Each secured connection will have an IKE SA
(created in Main Mode to transfer data used to create the master key) and two in Quick Mode
(for data traffic). The Quick Mode SA noted here represents the two made for the connection.
Two SAs are created, one for sending and the other for receiving. Because Quick Mode cannot
happen without successful completion of Main Mode, the policy is working as expected.
Figure 8.20: The SA for Quick Mode.
Chapter 8
Figure 8.21: Evidence that confidentiality (encrypted) packets have been sent and received.
Was this manual useful for you? yes no
Thank you for your participation!

* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project

Download PDF