Tips and Tricks Guide To

tm

Securing Windows Server 2003

Roberta Bragg

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

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 Serversthe Administrative Perspective Chapter 3: Understanding Active Directory Foundations Chapter 4: Fulfilling the Promises of Group Policy Chapter 5: Administrative Authority Chapter 6: Triple AsAuthentication, 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: Wed like to use Secure Sockets Layer to secure communications on our intranet but we dont 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

ii

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 users 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 Serversthe Administrative Perspective...............50 Q 2.1: Ive just been reading about the dangers of allowing services to log on using the Local System account. Isnt 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 doesnt 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: Ive 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
iii

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. Whats 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

iv

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, Ive 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. Whats up with that?.................................................................................................................................116 From the User PerspectiveControl 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
v

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 network?.......................................................................................................................................142 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 administrators?.............................................................................................................................159
vi

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 AsAuthentication, 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 Users Logon and Logoff Events.....................................................................187 Q 6:3: Ive 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. Ive 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 Inheritance............................................................................................................192 Additional Permissions and Rights......................................................................195 Q. 6.4: What is the difference between user rights, permissions, and privileges?.......................196 Logon Rights........................................................................................................197 Privileges..............................................................................................................199 Q 6.5: Which file activity should be audited and how do I do so? ..............................................201 Maintaining an Audit Trail ..............................................................................................201 Monitoring a Users Activity ...........................................................................................202 Compatibility Resolver ....................................................................................................202 Log Changes in System Files...........................................................................................203
vii

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 Processingthe Ticket Granting Service ...................................208 Service Ticket Generationthe 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 users 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 dont want to configure Active Directory. Is this setup possible? ........................................................230 Understanding the Difference Between Authentication and Authorization ....................230

viii

Choosing an Authentication Provider..............................................................................230 Authentication Methods...................................................................................................232 MS-CHAP and MS-CHAPv2 ..............................................................................235 CHAP...................................................................................................................236 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 NATNAT-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. Its hard to keep up with which systems have up-to-date patches and which still need them. How can I figure this out?............263
ix

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. Theyre causing havoc. Is there a way I can prevent these rogue computers from running on my network? .......................268 Microsofts IPSec Implementation ..................................................................................269 How IPSec Works................................................................................................270 Writing an IPSec Policy to Keep Rogue Computers Out of Your Network....................273 Testing..................................................................................................................274 Changing the Authentication Method..................................................................276 Requiring Computer Certificates for Authentication...........................................276 Q. 8.4: Im 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: Id 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 Realtimepublishers.com, Inc. All rights reserved. This site contains materials that have been created, developed, or commissioned by, and published with the permission of, Realtimepublishers.com, Inc. (the Materials) and this site and any such Materials are protected by international copyright and trademark laws. THE MATERIALS ARE PROVIDED AS IS WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, TITLE AND NON-INFRINGEMENT. The Materials are subject to change without notice and do not represent a commitment on the part of Realtimepublishers.com, Inc or its web site sponsors. In no event shall Realtimepublishers.com, Inc. or its web site sponsors be held liable for technical or editorial errors or omissions contained in the Materials, including without limitation, for any direct, indirect, incidental, special, exemplary or consequential damages whatsoever resulting from the use of any information contained in the Materials. The Materials (including but not limited to the text, images, audio, and/or video) may not be copied, reproduced, republished, uploaded, posted, transmitted, or distributed in any way, in whole or in part, except that one copy may be downloaded for your personal, noncommercial use on a single computer. In connection with such use, you may not modify or obscure any copyright or other proprietary notice. The Materials may contain trademarks, services marks and logos that are the property of third parties. You are not permitted to use these trademarks, services marks or logos without prior written consent of such third parties. If you have any questions about these terms, or if you would like information about licensing materials from Realtimepublishers.com, please contact us via e-mail at info@realtimepublishers.com.

xi

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 XPs EFS does not require that a Data Recovery Agent be present before files can be encrypted; Win2Ks 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 youve 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 youre working remotely. Although applying a setting in local security policy reduces the chance of error, this option isnt 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 setting. 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 Policy.

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

gpupdate

to refresh the policy.

Gpupdate is the Windows XP command used to refresh Group Policy. This command replaces Win2Ks 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 isnt 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:
MACHINE\Software\Microsoft\Windows NT\CurrentVersion\EFS\EfsConfiguration,4,%EfsConfiguration%,0

A good place to add this line is below registry keys that are in similar locations. In my file, Ive placed the line with the other Windows NT\CurrentVersion subkeys. Table 1.1 explains the previous command.
Parameter Registry path Registry type Display name Display type Explanation Lists the path Defines the registry data type Represents the string value in the [Strings] section Specifies the type of dialog box presented to users in the GUI for configuration 4 %EfsConfiguration% 0 Two radio buttonsEnable and Disable; choosing Disable will set the registry value to 0 REG_DWORD Example in the Previous Statement Result

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, Ive chosen to label the setting within the file to make it easier to find. Using a semi-colon (;) identifies the label as a comment.
;==========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 (http://support.microsoft.com/directory/article.asp?ID=KB;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 (http://support.microsoft.com/directory/article.asp?ID=KB;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
easierautomatic 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, well 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 templatea Version 2 certificate templateand 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 youve 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, including Customization of enrollment policies (who can enroll who) Certificate authorization (who can authorize a certificate issuance) Domain authentication (which domain contains the users account) Certificate administrator (who manages the Certificate AuthorityCA) 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 templates.

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). Im 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 type
certtmpl.msc

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 youve saved the new template, you cant change the templates 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 templates 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 subjects 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. Well 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 designif 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.

10

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.

11

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 dont 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 out http://www.microsoft.com/windowsxp/pro/techinfo/planning/pkiwinxp/whatsnew.asp.

Q 1.3: Wed like to use Secure Sockets Layer to secure communications on our intranet but we dont 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 greatuntil 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.

12

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: PGPs distributed trust model.

Microsofts 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 Cs 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.
13

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 servers 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.

14

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 PKIs 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 computers local Administrators group. The keys for the certificate must be generated by the computer, and the certificate must be installed in the computers certificate store. If the certificate is not placed in the computers certificate store, the computer cannot use it.

15

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 CAs 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 CAs 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 CAs 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 AdministratorCan renew CA certificates, backup and restore the certificate database, and deny, issue, and revoke certificates. Certificate ManagerCan deny, issue, and revoke certificates UserCan request certificates Computer AdministratorCan 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 CertMgrsyou 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.

16

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.
17

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 its 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 resolved. 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.

18

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 wont 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.
9.

Enter the Common Name. The Common Name is the name by which the CA will be known (see Figure 1.13).

19

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, DC=com.
11. Accept or modify the validity period. The validity period is the time in years that the

Root CAs 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 systemroot\system32\certlog.
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.

20

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.

21

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 situation? As the number of issued certificates increases, the CRL grows. At some point, such a list might become rather cumbersome. How does Windows Server 2003s 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).

22

Chapter 1

Figure 1.15: A reason must be selected when revoking a certificate.

The following list describes acceptable reasons for revocation: Key CompromiseThe 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 CompromiseThe disk location, or token, at which the CAs 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 ChangedWhen 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. SupersededA new certificate is issued for the user before the assigned certificate expires. Perhaps the individuals 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 OperationsWhen 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 HoldWhen 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 CRLIf a revoked certificate is un-revoked, it remains in the CRL, but is marked as RemoveFromCRL. UnspecifiedIf a certificate needs to be revoked but doesnt 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.
23

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.

24

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 signatureWin2K 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 CRLThis date can be checked by examining the next update field of the CRL. If this date has already passed, the CRL is considered expired.

25

Chapter 1 Check the CRL for the certificate serial numberIf 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 cant 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 dont 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 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Certsvc\Configuration\CAN ame\CRLOverlapPeriod and HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Certsvc\Configuration\CAN 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 wont cause a client to download a new CRL and will not affect the set publishing period.

26

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 CommentsRFC2459.) 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.

27

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 isnt available to the client for download because it hasnt 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.

28

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.

29

Chapter 1

For more information about CRLs, check out the following Web sites: http://csrc.nist.gov/pki/documents/sliding_window.pdf http://csrc.nist.gov/pki/documents/acsac99.pdf http://www.microsoft.com/technet/treeview/default.asp?url=/TechNet/security/prodtech/dbsql/tshtcrl.a sp

Q 1.5: If a users 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 users 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 dont 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.

30

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.

31

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, well use the account Joe Blow. Use Internet Explorer (IE) to browse to the CA Web locationhttp://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.

32

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).

33

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).

34

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, its 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 subjects encryption private key check box.

35

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.

36

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).

37

Chapter 1

Figure 1.27: The Archived Key column.

Users encrypt and decrypt files in the ordinary manner. However, if a users 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 certificates 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.

38

Chapter 1 Enter
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 users 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 contentan encrypted PKCS#7 containing the users 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 users certificate store. A password is placed on this file to prevent tampering.

39

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: EducationAdministrators 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 folders encryption setting is removed, new files placed in the folder will not be encrypted, but the files already encrypted will not be decrypted.

40

Chapter 1 RecoveryWindows 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 isnt 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 backupEncryption 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 locationIf 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 secured.) 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.

41

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, Im 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.

42

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 users 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).

43

Chapter 1

Figure 1.34: Illustration of file decryption.

If the recovery agents 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? Youre 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? Heres 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).

44

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 users 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 users 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).

45

Chapter 1

Step-by-Step Process to Secure Shared Encrypted Files So, youve 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? Im 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 users 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. 2.

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). (instructions for this process follow). It is not necessary to include a copy of the users 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.

3. The user exports or archives a copy of his or her certificate, placing the copy in Folder B

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 users 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 3one for each user with whom the user will share the encrypted file.

46

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 users 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 users 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 users Trusted People store will be displayed (see Figure 1.37).

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).

47

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 groups 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).

48

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 users profile on the file server in the profile folder designated in the users 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.

49

Chapter 2

Chapter 2: Securing Web Services and Web Serversthe Administrative Perspective

Q 2.1: Ive just been reading about the dangers of allowing services to log on using the Local System account. Isnt 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, lets 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 cant 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.

50

Chapter 2 To prevent an attacker from gaining control, you can follow these sound practices: Dont run Web applications in-process. Web applications can be run in-process or out-ofprocess. Applications running in-process run in the context of Inetinfothe 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 attackers 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-ofprocess. 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 access.

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 (http://www.microsoft.com/technet/treeview/default.asp?url=/TechNet/security/news/nt4srp.asp) 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.

51

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 architecture.

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).

52

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 doesnt 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 2003s 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. Lets 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.

53

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 NetworkService.
Privilege Best Practices Its 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 accountsone for each servicecould 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 accountno one knows anymore what the process really needs. Windows Server 2003s 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 NetworkServices account privileges as identified at the April TechEd session is shown in Table 2.1.
Privilege SeAuditPrivilege SeIncreaseQuotaPrivilege Discussion 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, along with SeIncreaseQuotaPrivilege, to access a process token and create a new process that uses the security context of the user of the other processpossibly resulting in a privilege escalation. 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 station. Required for IIS? Yes Required for Common Gateway Interface (CGI) programs Required for CGI programs

SeAssignPrimaryTokenPrivilege

SeChangeNotifyPrivilege

Yes

SeUndockPrivilege

No

Table 2.1: Explanation of the NetworkService accounts privileges.

54

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? Lets consider what it cant do. It cant shut down remote systems. This inability makes sensewhat business would it have shutting down remote systems? It also cant 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 Microsofts 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: Ive 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.

55

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: Dont 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 cant 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, dont 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.

56

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, dont select it. Click OK to move on.
12. On the Personalize Your Software page, enter your organizations 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 Next.
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.

57

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 isnt 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.
58

Chapter 2
Component BITS Server Extensions FTP Service FrontPage Server 2000 Extensions IIS Snap-In Definition Background transfer of files using idle bandwidth Provides FTP services Enables remote publishing of unique FrontPage extensions to the Web interface. Administrative console for the Microsoft Management Console (MMC) interface; unless you intend to do all your administration remotely, leave this console installed Provides newsgroup services Provides mail services for the Web server; doesnt 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 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 site Installed by Default No No No

Yes

NNTP Service SMTP Service

No Yes

World Wide Web Service

Yes

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 exceptionActive 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.

59

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).

60

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. 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 wont 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.

61

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 codes 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 code. 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.

62

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 CLRother 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 evidence: 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
Example IE Description Code is run within the context of a Web site Creates domain and/or load assemblies into a domain; might also load dynamic assemblies; might be managed or unmanaged code ASP.NET Windows shell Handles requests submitted to a server Runs applications such as executables in the shell

Application Domain Host Browser host Custom designed host Server host Shell host

Table 2.3: Application hosts.

63

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: NothingCode cannot run ExecutionCode can run but has no access to protected resources InternetA default policy for content of unknown origin LocalIntranetA default policy for the enterprise EverythingAll permission except skip verification FullTrustFull 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 didnt 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 groups 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 shows.

64

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 sets 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.

65

Chapter 2 Table 2.4 defines the available permissions.

Permission Directory Services DNS Event Log Environmental Variables File IO File Dialog Isolated Storage File Message Queue Access Browse or write None or ALL Unrestricted to all or none, browse, instrument, or audit per specific log Unrestricted to all, or read or write on individual variables Read, write, append, path disc. on stated paths Unrestricted or open, save or open, and save 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 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 instrument 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 Unrestricted or by identification and assignment of accesseither none, browse, or control Unrestricted or allowed by identification of host, port, direction, and selection of TCP or UDP Unrestricted access to SQL Server or limited access to SQL server using ADO.net; you must select the check box if you want to allow blank passwords Unrestricted or by listing host and accept or connect 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

OLE DB Performance Counter Printing Registry Reflection Security Service Controller Socket Access SQL Client Web Access User Interface

Table 2.4: Available permissions.

66

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: LinkDemandThis 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. InheritanceDemandEvaluated at load time; checks the subclasses. DemandEvaluated at load time; checks all callers. AssertEvaluated 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 applications 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. DenyEvaluated 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 doesnt 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. PermitOnlyEvaluated at run time.
67

Chapter 2 RequestMinimumEvaluated 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 cant run at all. RequestOptionalEvaluated at grant time; the assembly might use these permissions if they are granted, but if the permissions arent granted, the assembly will still run. RequestRefuseEvaluated 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:

68

Chapter 2 Code from www.somewebsite.com can access files in folder D:\folderforstuff\ Code running on my local machine can use the Clipboard Code from www.wevehadtroublefromthembefore.com 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 information. 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 number>\mscorcfg.msc

Next, expand the RunTime Security Policy node. There are three subnodesenterprise, machine, and userwhich 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, well 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.

69

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. Process 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:

70

Chapter 2 SiteWeb site URLA specific location on some site ApplicationDirectoryThe folder(s) in the file system that hold the program code for the application ZoneIE zones such as intranet, trusted sites, and so on StrongNameCryptographic name PublisherWho 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 order) Enterprise Can be Modified by Administrator Comments 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 All code is associated with the current user on this OS This policy represents the resultant set of the three previous policy levels.

Machine User Application domain policy

Administrator Administrator or user Application domain host code

Table 2.5: Policy level descriptions.

An administrator can set a machine-level policy that doesnt 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 dont 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.

71

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 well start with a secure implementation of WebDAV. 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 2000Win2K.) 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 SSLafter 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, Ill 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.

72

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 Handlers 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.

73

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, its 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.

74

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 menus 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 doesnt allow anonymous connection, so you might need to enter a user ID and password.

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.

75

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, youll 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 Next. 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 encrypted. 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 certificateServer Authenticationcan 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.

76

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 shows.

77

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.

78

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.

79

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.

80

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.) Backup 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 maintained.

Two types of backup are possible: Secure backupAn 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 backupData is encrypted with a blank password and therefore can be restored by any member of the Administrators group.
inetmgr

To back up, in the Start menus 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.

81

Chapter 2

Figure 2.17: Naming and protecting the backup file.

To restore a backup, in the Start menus Run text box, type

inetmgr

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 Fileswhich defines XML terminology and metabase terminology Metabase Property Referencewhich 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.

82

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 layersee 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.

83

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 OK.
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.

84

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.
Recommendation Use complex passwords Maintain access control on metabase-related files Use the concept of least privilege Do not use EFS to encrypt the metabase Copy the MetaBase.xml file before manually editing it Create backups using the backup/restore configuration tool Do not use import and export to backup the metabase file Backup content Prevent simultaneous metabase changes Monitor event logs for related IIS event messages Set up file auditing on the metabase files Comments Dont write them down For more information about these files, see Table 2.7 Only give the minimal and necessary permissions and privileges to users Doing so slows IIS and might cause errors You can restore a good copy of MetaBase.xml by copying the good version of a corrupted MetaBase.xml Do so frequently and whenever changes are made to the metabase

Sensitive data (such as passwords) is not exported; import and export is meant for transferring sections of the metabase file to another computer Metabase backup does not backup content files Can cause corruption Learn what the error messages mean and how to correct the situation 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 them

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) \Inetsrv\MetaBase.xml \Inetsrv\MBSchema.xml \Inetsrv\History\historyfile \Inetsrv\MetaBack\backupfile
Table 2.7: Metabase-related files.

Comments The configuration storage database The schema for the configuration file The metabase history files The metabase backup files

85

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.

86

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. Whats 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 NTstyle 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. Lets 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 thisthese 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 Hcwt.com. 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 Production.West.Hcwt.com domain and a printer in the East.Teluro.local domain. Likewise, Bob, a user in the West.Hcwt.com domain, can be given access to these resources. Dotted lines indicate successful resource access.

87

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 East.Hcwt.com domain in one forest and the East.Security-careers.com domain in another forest provides one-way access depending on choices made when the trust is created. If the East.Hcwt.com domain is the trusted domain, users in the East.Hcwt.com domain can be given access to resources in domain East.Security-careers.com. Users in the East.Security-careers.com domain cannot be given access to resources in the East.Hcwt.com domain.

88

Chapter 3 Figure 3.2 shows that Mary, who has an account in the East.Hcwt.com domain, can be given read permission on the accounting file that is on a server in East.Security-careers.com domain. Bob, however, whose account is in the East.Security-careers.com domain cant be given access to the printer in the East.Hcwt.com 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 West.Security-careers.com 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 forests.

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.

89

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 benefitscreating 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 shouldnt be. If there is no legitimate reason for granting such trust, then dont. If possibility is limited, an attackers 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.

90

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 others 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.

91

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 termforest 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 functionality.
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. Functional Mode Windows Mixed Domain Description Some combination of Win2K, Windows Server 2003, and NT domain controllers; NT and Windows Server 2003 servers are OK Win2K domain controllers only; no NT or Windows Server 2003 domain controllers; NT and Windows Server 2003 servers OK Windows Server 2003 domain controllers only; NT and Windows Server 2003 servers OK Forest Description Some combination of Win2K and Windows Server 2003 domains Win2K native mode domains and Windows Server 2003 domains Windows Server 2003 domains only

Windows 2000 Native Mode Windows Server 2003

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 NTLM.

92

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 forests 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-wayUsers 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.
93

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 terminologyfirst forest, incoming, outgoingcan be confusing. In both Figure 3.5 and Figure 3.6, the Hcwt.com 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 Hcwt.com forest. The arrow is incoming, so the trust is incoming. The Hcwt.com 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 Hcwt.com forest can be granted access to any resource in the Security-careers.com forest. This trust doesnt give users in the Security-careers.com forest access to resources in the Hcwt.com forest. In Figure 3.6, the trust arrow points away from the first forest. It is an outgoing trust. The Security-careers.com forest is now the trusted forest and users in its forest can be granted access to resources in the Hcwt.com forest.
94

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, Ive 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 2003s 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.

95

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, Nancys computer will contact the domain controller located at headquarters. In step 2, the domain controller contacts the GC to determine Nancys universal group membership. Finally, in step 3, the information is returned to Nancys computer as part of a Kerberos ticket. If the WAN link is down, Nancys 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.

96

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 displayedinformation 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 Nancys 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 doesnt eliminate the need for WAN access to a GC.

97

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 http://support.microsoft.com/default.aspx?scid=kb;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, Nancys 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 Nancys 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.

98

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.

99

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 servicehow it synchronizes time between all computers in the domain and the impact of time on logon. Early installation instructions dont 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 administratorswho did not understand the reason for Kerberos reliance on timesolved 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 youll 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 millisecondsan 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 functionthere 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.

100

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.

101

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 mechanism.

102

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 attack.
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.

103

Chapter 3

Q 3.4: What possible advantage is there to implementing universal groups? 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) environments. 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.

104

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 clerks 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.

105

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 created. 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.

106

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 Groups 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 doesnt 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 Global Domain Local Scope Assigned permission in any domain Assigned permission only in the same domain Assigned permission in any domain Assigned permission in any domain Assigned permission only in the same domain Membership Accounts in the same domain Accounts and global groups from any domain Accounts, global groups, and universal groups from any domain Accounts and global groups in the same domain Accounts, global groups, and universal groups from any domain; domain local groups from the same domain Win2K Mixed Mode or Win2K Mixed Functional Level

Win2K Native or Windows Server 2003 Functional Level Universal

Global Domain Local

Table 3.2: Groups, scope, and membership.

To illustrate the use of universal groups, Ill 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 dont 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.

107

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.

108

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 DirectoryADrequires 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, well have a problem. Whats happened to Joes account? When the server reboots, Joes account might have disappeared from Active Directory Users and Computers. Worse still, some of Joes 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.

109

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 controllers 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
ntdsutil

At the ntdsutil prompt type

files

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 typing
info

Verify the integrity of the database by typing

integrity

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.

110

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 authorization. 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.

111

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 users 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 GPOs 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 GPOs 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.

112

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.

113

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, Ive incorporated this list into my best practices list and added comments.
Practice Do not log on using your administrative account. Instead use a normal user account and use the Run as utility to run administrative tools. Physically secure computers in a locked room. Rename or disable the default Administrator account. Manage security relationship between forests. Remove all users from the Schema Admin group. Add a user account only when changes to the schema must be made. Comments Using an ordinary account mitigates the risk that inadvertent damage is done either through accident, malicious activity, or the accidental running of malicious code.

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. If not disabled, do not use for ordinary administrative work. Each administrator should have an administrative account for accountability. Simplify by using forest trusts where many trust relationships between domains are necessary. Use external domain trusts to isolate access from forest to forest. 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.

114

Chapter 3
Restrict user, group, and computer access to shared resources. Do not disable the encryption of AD traffic. Shared resources include files, folders, printers, devices, data, and programs that are made available to network users. 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, dont. Audit access to this key and ensure that it is not changed. 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. AD provides security management information. Establishing separate sites ensures the resources to get the information there quickly.

Ensure that members of administrative groups are trusted.

Establish sites where geographic locations exist that need immediate access to changes to the AD. For each site have at least one domain controller and one Global Catalog (GC) server Perform regular backups. For each domain, have at least two domain controllers and one GC server. Limit membership in administrative groups. Audit activity that affects critical AD operations, changes to administrative groups, and security policy. Maintain default settings on AD objects unless study by respected researchers proves changes that tighten security.

If sites must access this information from another site, there may be delays in receiving and applying modified information. Need I say more? 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. Use delegation of authority to assign only the privileges to groups that are need by their members. Auditing provides the accountability you require. You need to know when and who are modifying key files, settings, and group memberships. Windows Server 2003 is a new OS. Microsoft has set the security high on AD objects. Are they perfect? No. And Im 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.

115

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. Whats 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 wouldnt 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 theyre ready to deal with the results, Id recommend disabling the error reporting service for clients.

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 Microsofts. 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.

116

Chapter 4

From the User PerspectiveControl 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 discussionthe 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 errors. User-mode errors will cause the display of an alert with choices to Report this problem or Dont 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.

117

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

gpedit.msc
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 organization. To manage error reporting settings with Group Policy, open a Group Policy Object (GPOfor 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 folderAdvanced 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 Notification Enabled Enabled Not Configured or Disabled Not Configured Not Configured Disabled Report Errors Not Configured Enabled Enabled Not Configured Disabled Not configured Result User is notified of errors User is notified of errors and given opportunity to report User is not notified, errors are reported automatically User can control through Control Panel User can control notification from Control Panel, but not error reporting 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.

118

Chapter 4

Figure 4.2: Report errors properties.

Setting Do not display links to any Microsoft more information website Do not collect additional files

Description If this option isnt selected, links to Microsoft sites are included.

Notes This feature might actually be very useful for administrators, but might only serve to confuse the average user.

If this option isnt selected, when certain errors occur, additional related files (such as log files) might be collected and sent as well. If this option isnt selected, system configuration, hardware information, and other settings may be collected. 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.

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. Useful information for the corporate troubleshooter. 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 database. Useful feature, although I wish it included more history than just the prior policy settings.

Do not collect additional machine data Force queue mode for application errors

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.

Table 4.2: Error Reporting Settings.

119

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 SettingThis 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 forIf 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 forThis 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 ErrorsIf this option is enabled, the system will report OS errors. Report Unplanned Shutdown EventsIf 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.

120

Chapter 4

Q 4.2: How can I prevent users from running tools that they should not run? A: Although you didnt mention which tools you dont 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 administrators 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 doesnt 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:

121

Chapter 4

PathExplicitly identify the program path. HashWhen 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. CertificateRules are built based on the presence of a code publishers software signing certificate. Internet zoneYou 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

secpol.msc

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

Policy. 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, youll 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 exercise.

122

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.exeno 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

container.
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.

123

Chapter 4

Figure 4.4: Be sure to change the policy from the default setting to let local administrators use the restricted tools.

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

OK.
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.

124

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 dont 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.

125

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, dont forget to think about the copies that may be in dllcache.
If you are not using hash rules to prevent software from running, dont 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 programis 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.

126

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.

127

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 http://support.microsoft.com/default.aspx?scid=kb;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 command.com or edit.exe doesnt 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 HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Safer\CodeIdentifiers 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 didnt explicitly run showed up on the list.

Figure 4.7: You can troubleshoot software restriction rule problems by creating a log through registry edits.

128

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 systemprove 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 users access to the resources on the system and the users rights to do things with the system and its resources are controlled by authorization. Setting Enforce password history Recommendation 13 passwords remembered Comments 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. 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. This setting supports Enforce password history. A minimum password age of 0 would allow users to immediately change their passwordsnot a good idea, as they might return to their original password. 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. 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

Maximum password age

42 days

Minimum Password Age

5 days

Minimum Password Length

8 characters

Password must meet complexity requirements

Enabled

129

Chapter 4
passwords because this setting doesnt 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 beginningprime locations for brute-force password cracking programs to look. Store password using reversible encryption Disabled 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. 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. The number of incorrect attempts at guessing a password that can be made before the account is locked out. 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 wont matter.

Account Lockout duration

30 minutes

Account lockout threshold Reset account lockout counter after

5 invalid logons 10 minutes

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.)

130

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 passwordsat 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 settingseven though together they represent a strong account and password policyforces 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.

131

Chapter 4

Setting User must change password at next logon User cannot change password

Recommendation Used when initial account is activated or when there are changes in password policy to force password resets Select this setting for service accounts

Comments This setting is enabled by default when a new account is created, and may be turned off by an administrator. 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 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. A good practice is to disable accounts when a user leaves the company; doing so solves two problems. First, you can immediately remove the users 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 users 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. Administrator must clear this check box to reenable the account. 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 cards must be implemented in the domain.

Password never expires.

Not selected for user accounts, selected for service accounts

Account is disabled

Only select when you want to disable an account

Account is locked out Store password in reversible encrypted form

This setting is unavailable and can be activated only through the account lockout policy Might be necessary if alternative operating systems (OSs) are used as workstations for users with Windows Server 2003 accounts When selected, a user must present a valid smart card and pin number (or other unique piece of information) to logon When a service application is

Smart Card Required for logon Account is

In Windows 2000 (Win2K), there is no way to limit 132

Chapter 4
trusted for delegation running under a user account, this right lets the service account impersonate the user account to gain access to resources Use this setting to prevent the delegation of this account 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. If this setting is selected, programmatic attempts at delegating the account will be overridden.

Account is sensitive and cannot be delegated Use DES encryption types for this account.

Should be selected only if required to allow users to connect from OSs that require Data Encryption Standard (DES). Win2K and Windows Server 2003 by default preauthenticate; use this setting if interoperability with nonWindows Kerberos is required

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. 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.

Do not require Kerberos preauthentication

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 http://www.sans.org; Microsoft checklists are available for download at http://www.microsoft.com/security, and National Security Agency (NSA) checklists are available for download from links at http://www.nsa.gov.

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.

133

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 Control.
Group Administrators SYSTEM CREATOR OWNDER Users Users Users Everyone Permission Full Control Full Control Full Control Read and Execute Create Folders/Append Data Create Files/Write Data Read and Execute Apply To This folder, subfolders and files This folder, subfolders and files Subfolders and files only This folder, subfolders and files This folder and subfolders Subfolders only 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 doesnt assume that the default permissions on system folders, files, and registry keys are always going to be the best possible settings.
Files Boot.ini, NTDETECT.COM,ntldr Boot.ini, NTDETECT.COM,ntldr Config.sys, autoexec.bat Config.sys, autoexec.bat Config.sys, autoexec.bat IO.SYS, MSDOS.SYS IO.SYS, MSDOS.SYS Group Administrators and SYSTEM Power Users Administrators and SYSTEM Power Users Users Administrators and SYSTEM Users Permissions Full Control Read and Execute Full Control Modify Read and Execute Full Control Read and Execute Yes Yes Inherited No No

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.)

134

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 unitOU. 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.

135

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.

136

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 GPOs 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 GPOs setting. If the new GPOs 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 burden.
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).

137

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 servers 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.

138

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 4.12).

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

139

Chapter 4

Switch /create /tn /tr /sc /d /ru

Description 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 entered)

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 switch
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 users password is not displayed.)

Figure 4.13: Querying scheduled tasks.

140

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 doesnt 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.

141

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:

142

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 doesnt 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 products: 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

143

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. EncryptionThe 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. SSIDThe 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 broadcastBroadcasting 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 authenticationBy 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 isnt foolproof. Insist on direct connection for administrationAllowing 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, youve 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.

144

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.

145

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 connections. 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 DirectoryAD). The access server forwards to the client. If authentication is successful, the port on the access server is open and the user authenticated. PEAP is essentially EAP wrapped in Transport Layer Security (TLSa 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:

146

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 processinformation 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 reassemblytwo networking issues with EAP. Because EAP doesnt 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 dont have to mess with), they wont. 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 Computerto-computer (ad-hoc networks only)

147

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.

148

Chapter 4 On the Network Properties tab (see Figure 4.20), enter the network name, or SSID, and a description.

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.

149

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 requestensure that the users 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.

150

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 users typical user properties are applied, the local user settings for the Group Policy within which the computer account resides are reapplied. The users configuration settings now reflect this policy. Two versions of loopback processing mode exist: Loopback with mergeUser configuration is composed of settings from both the users 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 replaceThe 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 users container. The GPO in the Plant OU does not ordinarily apply to him. For lack of a more visible illustration, well 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 Jaspers 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.

151

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.

152

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 Administrators 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.

153

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.
Action I need to make some changes and normally would boot into safe mode to do so. I changed the password policy after disabling the Administrator account. The secure channel between the workstation and the domain controller has failed. Problem The Administrators account is disabled and is normally used in safe mode. Workaround Not a problem, the Administrators account will always be enabled in safe mode. Another administrator must log on and reset the Administrator account password. Reboot to safe mode and fix the problem.

If the Administrators account does not meet the new policy, you will not be able to re-enable the account. There are no other local Administrator accounts. You cannot make the changes necessary to correct 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 Administrators 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 doesnt work, right? Wrong. Well, if obscurity is your only defense, of course it doesnt 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 Administrators 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 Administrators account, but there are also ways to make that harder, as I discuss in the next section.

154

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 Administrators 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 employees 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.

155

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 users 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 domains 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 riskgiving 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 Administrators 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.
Dont 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.

156

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. Ive illustrated this confusing concept in the following example scenario:

157

Chapter 5 Sallys account is given membership in the Administrators group of her Windows XP machine. A Group Policy exists for the OU in which Sallys computer account resides. The Administrators group is added to the Restricted Groups policy in this Group Policy. Sallys account is added to the Administrators group within the policy. Sally is tricked into adding Toms account to the local Administrators group on her computer. Tom has no domain administrative privileges. During policy refresh, the discrepancy is found. Toms account is not in the Restricted Groups Administrators group. Toms account is removed from the local Administrators group on Sallys computer. That afternoon, Tom attempts to remotely edit the registry on Sallys machine to play a trick on her. He cannot do so. At the end of the week, John reviews the audit logs on Sallys 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 doesnt 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.

158

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
Administrators

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.

159

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
help

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.

160

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 menu.

Because the properties that you have selected are not those exposed in the main security pages 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.

161

Chapter 5

Permission Read/Write Property on Group objects Write Property on User objects Reset Password on User Objects Read All Properties on User objects

Properties Read Members, Write Members Write pwdLastSet [none] 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

Object [none ] [none ] Reset Password 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

help

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. 162

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.

163

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

mmc

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

OK.
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.

164

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 modelimited 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.

165

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.

166

Chapter 5 One way to restrict the new consoles users is to use file permissions. However, doing so wont 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.

167

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.
Level 1 2 3 4 GPO Local Security Policy Site Domain OU Description 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 doesnt seem to have any affect.

168

Chapter 5

Figure 5.6: Default domain security policy.

To understand whats 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 policys settings can complement another policys 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 doesnt 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.

169

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, well 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.

170

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 forest. OK, so its easy to figure out what an Enterprise Admin can dojust 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, lets 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.

171

Chapter 5

In order to Install enterprise root CA Install enterprise subordinate CA CA administrator standalone CA, no domain CA administrator standalone CA in a domain Enforce role separation on CA Authorize Dynamic Host Configuration Protocol (DHCP) in Active Directory (AD) Administer all DHCP servers in domain Administer the local DHCP server on the local computer Administer every domain in the forest Run dcpolfix to restore default Group Policy Objects (GPOs) Create AD application partition Delegate RSOP control at site and domain level Enlist a Domain Name System (DNS) server in an AD application partition Run RSOP in domain Runs RSOP across domain boundaries Install first instance of Exchange (forest prep has not been run prior) Install additional instances of Exchange (or initial if forest prep has been run)

You must be Enterprise Admin, Forest Root Domain Admin Enterprise Admin, Forest Root Domain Admin Local Admin Local Admin, Domain Admin Local Admin Domain Admin Domain Admin DHCP Admin Enterprise Admin Enterprise Admin Enterprise Admin Enterprise Admin Enterprise Admin Domain Admin Enterprise Admin Enterprise Admin, Schema Admin, Domain Admin 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 doesnt 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 interpretationI 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
172

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 purpose.

173

Chapter 5

A Hierarchical View of Windows Server 2003 Administration Forest Role Domain Role Enterprise Admin Schema Admin Domain Admin Cert Publishers Group Policy Creator Owners Domain Computers Domain Controllers Server/Computer Role Backup Operators Server Operators Uber admin Modify Schema Administer domains Computers that can publish certificates to AD Members can create and edit group policy objects for the domain Can be managed, domain administration Serve as domain controllers in domain Backup and Restore Logon interactively, create shares, shut down computer, format drive, stop start services, backup and restore Create and manage groups, users, and computers. Cannot manage administrators, domain controllers. Manage printers and document queues Client side of network configuration; cannot install/remove drivers or services 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 service IIS 6.0 worker process group; an account is assigned here by the system to manage a namespace (Microsoft.com would be a namespace, as would peachweaver.com); do not add users to this group Can access remote access properties of users Logon to domain; run applications; access files; use printers; add workstation to domain; bypass traverse checking; shutdown workstation Logon on to domain (account disabled by default.); bypass traverse checking; shutdown workstation Logon locally; bypass traverse checking; 174

Account Operators

Print Operators Network Configuration Operator DHCP Administrators DnsAdmins DnsUpdateProxy

HelpServicesGroup

IIS_WPG

RAS and IAS Servers User Role Domain Users

Domain Guests

Users

Chapter 5
shutdown workstation; run applications; access files, and use printers Guests Logon on (account disabled by default.); bypass traverse checking; shutdown workstation Adding the group Everyone here and rebooting domain controllers provides security level compatible with many preWin2K applications Log on to a computer from a remote location View-only access to the DHCP Server service View-only access to the WINS server service

Pre-Win2K Compatible Access

Remote Desktop Users DHCP Users WINS Users (installed with WINS Server service)
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 its 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, well 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 unitsOUs). 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 CommentsRFC1510), 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.

175

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 delegation. 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.

176

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.

177

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.

178

Chapter 6

Chapter 6: Triple AsAuthentication, Authorization, and Audit

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 (KDCdomain controller) for the

clients 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.

179

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 allowed. 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 users domain controller answers the clients request for a

session ticket with a referral ticket, a sort of TGT good in another domain. The clients 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

domain.
4. From this domains 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.

180

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 Hcwt.com tree. In the diagram, Alice, whose account is in the West.Teluro.local domain, wants to access a resource on server Fullsome in the Production.West.Hcwt.com domain. To do so, her client asks the KDC in West.Teluro.local for a session ticket for Fullsome.Production.West.Hcwt.com. 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 Hcwt.com 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 Hcwt.com KDC. The request and resultant referral ticket process continues, this time walking down the trust path of the Hcwt.com tree until a referral ticket for the Production.West.Hcwt.com 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.

181

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 servers domain. To get the ticket, the request must follow the trust path to the root domain of the clients forest, from there to the root domain of the resource forest, and eventually to the resource servers domain. When the client obtains a referral ticket to the resource servers 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 clients account is located.
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 servers KDC will not be in the GC of the clients forest. Not to worry; a list of all trusted domain objects is in the GC of the clients forest. Figure 6.4 and the following description detail this part of the equation. For this example lets assume that An appropriate forest trust has been established between the two forests. Alice, whose user account is in the Hcwt.com forest, is logged on to her domain, the Production.West.Hcwt.com 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 Security-careers.com forest.

182

Chapter 6

Figure 6.4: Finding the location of a resource across a forest trust.

1. Alices computers Kerberos client contacts the KDC service on a domain controller in

the Production.West.Hcwt.com domain, and requests a session ticket for the SPN of the resource computer East in the East.Security-careers.com 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, Hcwt.com.

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 Security-careers.com route domain.
4. The domain controller contacts the forest root domain of the Security-careers.com forest,

including the routing hint, which includes the address of Alices workstation.
5. The forest root domain, because it doesnt have the SPN of the Security-careers.com

server in its database, contacts the GC for Alices forest, and the GC provides the information.
6. The domain controller passes the SPN of the Security-careers.com server back to Alices

workstation.
7. Now that the trust path is known, Alices Kerberos client works in the normal manner to

obtain a TGT for the East.Security-careers.com domain, then negotiates the session ticket for the server.
8. Alices workstation presents the session ticket to the file server.

183

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: Heres 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 Nancys desktop computer.

Thus, to have a clear picture of a users 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 users 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 users use of the run as command to perform secondary logons The users employment of alternative credentials when mapping network drives.

Tracking logons is not a simple task, but a users 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.

184

Chapter 6

Event 672

Definition Authentication Server (AS) ticket issued Ticket Granting Service (TGS) ticket issued Security principle renewed an AS ticket or TGS ticket Pre-authentication failure TGS was not granted Account mapped to domain account Domain account logon attempt

Comments 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. 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. Tickets are renewable (see Kerberos policy definitions in the domain Group Policy). Authentication failed, many times as a result of a timesynchronization failure. Failure perhaps as a result of an invalid AS, unknown server or service, or time skew. A confirmation that the account has been located. If an account exists within the domain, logon can fail for many reasons (see error codes listed in Table 6.2).

673

674 675 677 678 681

Table 6.1: Account logon events are recorded where the account resides.

Error Code 1326 1328 1331 1329

Definition Unknown user or bad password Time restriction violation Account disabled Log on not allowed at this computer Logon of this type not allowed at this computer Account password expired Netlogon not active

Comments The user account or password is invalid. A valid logon time range is defined for this user account and this time is not within that range. The account is disabled at this time. The computers from which this account can logon are specified in the account for the user. This computer name is not within that list. Policy does not allow this type of log on (network, interactive, remote) at this computer. The password for this account expired. The Netlogon service has stopped.

1327 1330 1792

Table 6.2: Account logon failure codes for Event 681.

185

Chapter 6

Event 528 529

Definition User successfully logged off Failure due to bad password or unknown user name Attempt to log on outside of allowed time Attempt to log on using a disabled account

Comment Always present if a user logged off in normal fashion. Either an attack or the user forgot his or her password.

530 531

Allowed time range is set in user account properties. 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. 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. Allowed computers for logon can be set in user properties. This computer is not one of those listed for this user. Logon on locally, network logon, batch logon, service logon, and remote logon can all be denied implicitly or explicitly. Passwords can be set to expire (there is a difference between expired account and expired password). Netlogon stopped or is otherwise malfunctioning. Other reasons not documented. User employed Ctrl+Alt+Del to log off. Bad logon attempts reached the account lockout threshold for this account. Logon was successful. Computer endpoints can be authenticated using IPSec policies. These logon events are reported as well.

532

Attempt to log on using an expired account User is not allowed to log on from this computer Attempt to log on with a type of logon that is not allowed Attempt to log on with an expired password The Netlogon service is not active Failed for some other reason User logged off Account is locked out Successful log on to a computer Logon events related to IKE

533

534

535 536 537 538 539 540 541 547

Table 6.3: Logon events.

186

Chapter 6 Tracing a Users Logon and Logoff Events One of the benefits of understanding ordinary events is that youll 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 users 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 users 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 eventsuccessful 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.

187

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 users 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.

188

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.

189

Chapter 6

Figure 6.8: Event 538 indicates a successful logoff.

Q 6:3: Ive 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. Ive 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 dont know the exact permission settings youre trying to troubleshoot, Ill explore the possible permission issues that most frequently cause deletion problems to happen. To do so, Ill look at each factor that may affect file access: Permissions vs. special permissionsPermissions may be made up of several subtasks. InheritancePermissions set on parent folders that are inherited by those below. Additional permissions and rightsThe Change Permission permission, Take Ownership permission, Full Control permission, and the Take Ownership right.

190

Chapter 6 Folder permissionsPermissions set directly on a particular folder. File permissionsPermissions 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.
Permission Full Control Modify Folder All permissions Read & Execute, List Folder Contents, Read, Write, Special Permissions Read & Execute, List Folder Contents, Read, Special Permissions List Folder Contents, Special Permissions Special Permissions (If Applicable) All special permissions All special permissions except Full Control, Delete Subfolders and Files, Take Ownership, and Change Permissions Traverse Folder/Execute File, List Folder/Read Data, Read Attributes, Read Extended Attributes, and Read Permissions Traverse Folder/Execute File, List Folder/Read Data, Read Attributes, Read Extended Attributes, and Read Permissions List Folder/Read Data, Read Attributes, Read Extended Attributes, and Read Permissions Create Files/Write Data, Create Folders, Append Data, Write Attributes, and Write Extended Attributes Whichever special permissions you grant Read & Execute, Read, Write, Special Permissions All special permissions except Full Control, Take Ownership, and Change Permissions File Special Permissions

Read & Execute

Read & Execute, Read, Special Permissions

Traverse Folder/Execute File, List Folder/Read Data, Read Attributes, Read Extended Attributes, and Read Permissions Not applicable

List Folder Contents

Not applicable

Read

Read

Read

List Folder/Read Data, Read Attributes, Read Extended Attributes, Read Permissions Create Files/Write Data, Create Folders, Append Data, Write Attributes, and Write Extended Attributes Whichever special permissions you grant

Write

Write

Write

Special Permissions

Special Permissions

Special Permissions

Table 6.4: File and folder permissions and special permissions.

191

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.

Inheritance 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

192

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 files 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.

193

Chapter 6 A possible answer to your question involves inheritance. If users are allowed to read and write files to a folder, they dont 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 OWNERFull 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. 194

Chapter 6

Figure 6.12: Displaying a users 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 OWNER.

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.
195

Chapter 6

Q. 6.4: What is the difference between user rights, permissions, and privileges? A: This subject is confusing for two reasons. First, because documentation from Microsoft and
others has sometimes ambiguously defined these words. Its 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. Theyre not. The first distinction Ill 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 users 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. Its 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.

196

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 existallow and deny. Table 6.5 describes logon rights.

197

Chapter 6

Right Access this computer from a network

Description 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. Allows logon using a batch utility All accounts used for services must have this right. Use Ctrl+Alt+Del at the console to logon. Also known as an interactive logon.

Default Membership Domain: Administrators, Authenticated Users, Enterprise Domain Controllers, Everyone Workstation/Server: Administrators, Everyone, Power Users, Backup Operators

Logon as a batch job Logon as a service Logon locally

None; if IIS is installed, default IIS account LocalSystem, LocalService, NetworkService Domain: Administrators, Server Operators, Account Operators, Backup Operators, Printer Operators Workstation/Server: Administrators, Power Users, Users, Guests, Backup Operators Domain: Administrators Workstation/Server: Administrator, Remote Desktop Users

Allow logon through Terminal Services Deny access to this computer from the network Deny log on as a batch job Deny log on as a service Deny logon locally Deny logon through Terminal Services

Users that can use Terminal Services. (This right has no effect on systems earlier than Win2K Service Pack 2SP2.) Explicitly prevents an account or group from remotely connecting to this computer across the network.

Explicitly prevent an account from logging on as a batch job. Explicitly prevent an account from being used as a service account. Explicitly prevent an account from logging on interactively. Explicitly prevent logon using Terminal Services. (This right has no effect on systems earlier than Win2K SP2.)

None

None None None

Table 6.5: Logon rights.

198

Chapter 6 Privileges 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 administrators right to take ownership of objects cannot be removed.

Table 6.6 describes privileges.

Privilege Act as a part of the operating system Description 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 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. Use a process that has write property access to another process (to increase the processor quota of the process). Make a backup. Default Membership None

Add workstations to a domain

Domain: Authenticated users Workstation/Server: Not relevant

Adjust memory quotas for a process Backup Files and Directories Bypass Traverse Checking

Domain: Administrators, NETWORKSERVICE, LOCALSERVICE Administrators, Server Operators, Backup Operators Domain: Everyone, Authenticated Users, Administrators Workstation/Servers: Backup Operators, Users, Power Users, Everyone, Administrators Domain: Administrators, Server Operators

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).

Change the system time

Set the internal clock of the computer.

199

Chapter 6
Workstation/Servers: Administrators, Power Users Create a Pagefile Create a Token Object Create Permanent Shared Objects Debug Programs Enable Computer and User accounts to be trusted for delegation Create and change the size of a pagefile. Allows a process to create a token that can then be used to access resources. Create a directory object. Attach a debugger to any process. 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 users 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. Remotely shutdown a computer. Administrators Domains: Administrators Server/Workstation: Not applicable. Administrators

Force shutdown from a remote system Generate Security Audits Increase Scheduling Priority Load and Unload Device Drivers

Domain: Administrators, Server Operators Workstation/Server: Administrators LOCALSERVICE, NETWORKSERVICE Administrators Administrators

Add entries to the Security log. Change the scheduling priority of a process. 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. 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. View and clear the Audit log. Add or remove auditing of objects, registry keys, files, and folders. Change system environmental variables.

Lock Pages in Memory

None

Manage Auditing and Security Log Modify firmware environmental variables Perform volume maintenance tasks Profile single process Profile system performance Remove computer

Administrators Administrators

Run processes such a Disk Defragmenter and Disk Cleanup (not compatible with Win2K SP2 and earlier). Monitor non-system processes using Performance Monitor. Monitor system processes using Performance Monitor Undock portable computer (use Eject from the Start 200

Not defined

Administrators Administrators Administrators

Chapter 6
from docking stations Replace processlevel token Restore files and directories menu). Replace the token that a process started its processing with. (and thus change its ability to access resources) Restore files and folders from backup media. LOCALSERVICE, NETWORKSERVICE Administrators, Server Operators, Backup Operators, Print Operators, Account Operators Domain: Administrators, Server Operators, Print Operators, Account Operators Server: Administrators, Power Users, Backup Operators Workstation: Users, Backup Operators, Power Users, Administrators, Everyone

Shutdown the system

Shutdown the system from the console.

Synchronize Directory Service Data Take ownership of files or other objects

Table 6.6: Privileges.

A process can provide directory synchronization (only relevant on domain controllers). Take ownership of a securable object (such as a file, folder, registry key, directory object, printers, processes, threads). Administrators

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 fileauditing 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. Its 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.

201

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 Users Activity There is no built-in magical button that will allow you to spy on an individual users 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. (Ive even seen some cases in which the user is placed in the Domain Admins groupeek!) 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.
202

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 cant 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 http://www.microsoft.com/technet/treeview/default.asp?URL=/technet/security/prodtech/windo 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 occurring. 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.

203

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.

204

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.

205

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.
206

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 folders 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.

207

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 Service. Authentication Processingthe 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 timestampthe 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 users 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 authenticated. 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 KDCs password, and portions are encrypted using the clients 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 Generationthe 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
208

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.

Authorization 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 users 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 users 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 users 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.

209

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 clients 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.

210

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 users 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. Lets take a brief tour of the Remote Assistance possibilities, then Ill explain the controls and what I consider to be best practices.
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 whats happening on the novices 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? Ill 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. Isnt soliciting for Remote Assistance kind of like inviting in a carjacker when youre driving in a strange city and youve lost your way? Lets not ignore the huge benefits of this service because were 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.

211

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 experts 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 computerDetermines whether the user of this system can use Remote Assistance. Allow users to connect remotely to this computerDetermines whether to allow or deny remote control once connected. Set the maximum amount of time invitations can remain open (in days, minutes, and hours).

212

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.

213

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 cant follow simple instructions? And what if your desktop support model doesnt include the ability to respond to huge numbers of email requests for help? What if you dont choose the exposure that allowing emailed invitations provides?

214

Chapter 7

When a lot of requests for assistance flood the support desk via Windows XPs 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 solutionexperts 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 novices 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 unacceptablethe 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 novices 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 computerAn 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 computerAn authorized user can offer assistance and, if accepted, view and chat. HelpersA list of domain users who are authorized to offer remote assistance to this computer. The helpers name must be put in domainname\username or username@domainname 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.

215

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 wont 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.

216

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 (youve got a call), request (do you want this connection?), and mobility (can find you anywhere on any device). Many of you are familiar with Microsofts 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 (URIdefined in RFC 2396) and allows the integration of messaging, multimedia conferences, and telephony. The components of SIP are:
URIUniquely identifies users Call_IDGlobally unique identifier (GUID) that identifies a particular conversation. It includes an undue cryptographically random number generated by SIP and the URI of the client. Client software (such as IMs) Registration serversStore URIs. ProxiesTo pass on communications. GatewaysIntegrate 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

217

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 recipients public key is used to encrypt the message so that the recipients 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 message.

Should Alice, for example, send a secure IM message to Bob, the message is first split into two partsthe 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, Bobs 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. Bobs client receives the message and uses Bobs 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 Alices 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 Bobs response, encrypted with Alices public key, returns, Alices client wont have to guess which of her private keys to use to decrypt it.

218

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 privacythere 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.

219

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.

220

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.

221

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 userssay 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 dont 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 its 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: http://www.microsoft.com/windows2000/server/evaluation/business/rtcfaq.asp http://www.microsoft.com/technet/treeview/default.asp?url=/TechNet/prodtechnol/winxppro/evaluate/i nsid01.asp http://www.rfc-editor.org/rfcsearch.html

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.

222

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. Dont 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, dont 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.

223

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 servers 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 isnt 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.

224

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 servera 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 terminalLPTport 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 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TerminalServer\WinStations \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 192.168.5.66, the new IP address and port combination will be 192.168.5.66:8098. 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.

225

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.

226

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 youre 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 SecurityPrompt client for password and set client encryption level. Computer : SessionsTime settings for disconnected sessions, active sessions, active but idle sessions, and reconnection as well as terminating a session when time limits are reached.
227

Chapter 7 User: SessionsMirrors 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.

228

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 servers 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.

229

Chapter 7

Q. 7.4: I want to setup dial-up remote access and a virtual private network connection, but I dont 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 shouldnt be able to cant will take a little more of your time. Lets 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.

230

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 authentication.

231

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 clients 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.
232

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.

233

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.

Ill provide more information about EAP later in this answer. Table 7.1 describes the protocols that are available regardless of the authentication provider.
Protocol MSCHAP MSCHAPv2 SPAP PAP CHAP Data Encryption MPPE MPPE No No No Password Challenge/response, can be changed by user Challenge/response Clear text Clear text Challenge/response, the user can remotely complete a password change Protocol dependent Description Microsoft Challenge Handshake Authentication Protocol Microsoft Challenge Handshake Authentication Protocol version 2 Shiva Password Authentication Protocol Password Authentication Protocol Challenge Handshake Authentication Protocol Extensible Authentication Protocol; this protocol is generic and lets several potential authentication processes be used.

EAP

Protocol dependent

Table 7.1: RRAS authentication methods.

234

Chapter 7 MS-CHAP and MS-CHAPv2 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 users 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 stringthe 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 doesnt 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 clients 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 dropped.

235

Chapter 7

CHAP 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 users password in the SAM or AD. Doing so weakens the ability of the server to protect the password. SPAP 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 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, its 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.

236

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 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Remote 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 HKEY_LOCAL_MACHINE\SYSTME\CurrentControlSet\Services\Remote Access\Policy\defaultuser identity.

EAPs 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-TLSThis 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-MD5This 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-RADIUSEAP-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 MPPE.

237

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

238

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 policyeither 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.

239

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.
240

Chapter 7

Figure 7.21: RRAS policy conditions.

Type Authentication Types Called Station ID Calling Station ID

Windows Authentication X X X

RADIUS X X X

Description Only the authentication method listed is acceptable. Which phone number is dialed? Which phone number placed the call, or potentially in a VPN, the IP address of the caller (cannot do caller ID and callback together)? The friendly name of the RADIUS client. (The RADIUS client is the RRAS server or other server, not the client computer.) IP address of the RADIUS client. Manufacturer of the RADIUSM proxy A range of acceptable times for connection. Only the protocols listed are allowed (choices such as AppleTalk, PPP, X.25, and so on). Not yet defined. A Network Access Server (NAS) vendor string. The IP address of the NAS. The type of port used by the NAS (port choices include FDDI, 802.11 wireless, ISDN, DSL). Type of service user has requested (such as callback logon). Tunnel protocol used (such as PPTP or L2TP). Membership in a Windows group.

Client Friendly Name Client IP Client Vendor Day and Time Restrictions Framed Protocol MS-RAS Vendor NAS identifier NAS- IPADDRESS NAS Port Type Service Type Tunnel Type Windows Group x x X X X

X X X X

X X x x x X

Table 7.2: RRAS authentication types.

241

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 dont want to set up this server to use RADIUS, click Next twice, then click OK. After the RRAS service starts, youll 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 youre 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 shipped.

242

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 youll want to have valid reasons why you cant. 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, its 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 networkor between the VPN server on the other network and other resourcesis not tunneled or encrypted.

243

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 dont 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.

244

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 (dont forget to enter the same key on the client) and the clients are able to connect, your problem might be certificates, not NAT.

VPN Protocols Choices Because you are moving from PPTP to L2TP/IPSec, its 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.

245

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 protocols Request for Comments (RFC), which can be found at http://www.rfc-editor.org/rfcsearch.html. L2TP is RFC 2661 and IPSec is RFC 2401.

PPTP 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 used. L2TP/IPSec 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.

246

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 NATNAT-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 wayunless 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 implementationsuch as Win2K written to the standard, sees the NAT manipulation of the addressing as tampering and drops the packets. 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. Heres whats 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 http://www.microsoft.com/windows2000/techinfo/howitworks/communications/remoteaccess/l2tpclient 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.

247

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 7.27.

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.

248

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 administrators 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 servers 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 servers local tools is necessary. 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 installed. 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 servers 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 jobssuch as backupcan 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).

249

Chapter 7

Figure 7.29: Enabling Remote Desktop for Administration.

Click Select Remote UsersNote 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, well click Cancel, then click OK.

Figure 7.30: Giving users remote access.

250

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 complete. 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
tsmmc.msc

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.

251

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 consideration. 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.

252

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 here. Do set the Always prompt for password option. This setting prevents the casual interloper who obtains access to the users desktop from being able to administer servers.

253

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.

254

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.

255

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.
Setting Allow Time Zone redirection Defined Client/Server Data 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. Allowed by default, enable this feature to prevent users from sharing data between the client computer and the server via the clipboard. 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. Allow user to redirect server sound to the client computer. COM port redirection allows redirection of server data to client COM ports If this setting is enabled, it prevents print jobs origination at the server from being redirected to the client computer-attached printer. If enabled prevents LPT port redirection. Prevents mapping of client drives to session. By default, client drives are mapped. Time setting is very important for audit purposes and Kerberos tickets. Time zone redirection should not be allowed for remote administration. Comments

Do not allow clipboard redirection

This setting is more relevant for application users. Nevertheless, it should be enabled to prevent using the clipboard during an administrative session. Leave this setting alone. It is a good idea to require smart card logon for remote administration.

Do not allow smart card device redirection

Allow audio redirection Do not allow COM port redirection Do not allow client printer redirection

I know of no security reason not to allow this. COM port redirection may be necessary for administrative tasks. Policy dependent.

Do not allow LPT port redirection Do not allow drive redirection

Policy dependent. Policy dependent

256

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. Encryption and Security Requires secure RPC communication, allowing only authenticated encrypted RPC requests. If not set, allows unsecured RPC. If not set, client may configure his or her system to use a recorded password. Set as conditions require. Sessions More specific for client sessions than remote administration.

Policy dependent.

RPC Security Policy/secure server (require security)

RPC connections are used to configure terminal server services.

Always prompt client for password upon connection Set client encryption level Set time limit for disconnected sessions Set a time limit for active Terminal Services sessions Allow reconnection from original client only

Set to prevent just anyone from using the stored credentials to administer the server. Set at high if possible. Consider effect on long administrative processes before setting.

Prevents connection to an inprogress session from other than the computer that started the session. More specific for client sessions than remote administration Client Only

Prevents hijacking of a session.

Terminate session when time limits are reached.

Consider effect on long administrative processes before setting. Relevant only for application mode.

Start a program on connection Set rules for remote control of Terminal Services user session

Application mode relevant. Allows remote control if enabled, does not need users permission.

Table 7.4: Recommended settings to change according to your companys 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.

257

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 http://www.microsoft.com/technet/treeview/default.asp?url=/TechNet/prodtechnol/windows2000serv/ maintain/mngwmi.asp.

258

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

rsop.msc

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.

259

Chapter 8

Figure 8.1: Clicking an element displays the RSoP.

For Windows Server 2003:

1. In the Run text box, type

rsop.msc

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.

260

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.

261

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 possible.

262

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. Its 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 doesnt officially support Windows Server 2003)

263

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 securityor 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 specifics.
OS Windows 9x, ME NT Workstation Win2K Professional Win2K Server/Advanced Server Windows XP Professional Windows XP Professional using simple file sharing Windows XP Home Edition Windows Server 2003 servers Host No No Yes Yes Scan Locally No Yes Yes Yes Scan Remotely No Yes Yes Yes

Yes Yes

Yes Yes

Yes No

Yes No

Yes No

No Yes (but not officially supported in version 1)

Table 8.1: Where to run and what to scan using MBSA.

264

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 youre 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. 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 supported

The remotely scanned system must meet the following requirements:

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.

265

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 xs 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 updatesMBSA 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. PasswordsMBSA 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 checksAccounts are checked for password expiration and the number of accounts for which passwords do no expire is reported. Administrator group checkThe number of members in the Administrators group is reportedmore than two administrators on a local machine is considered questionable. Guest accountThe status of the guest account is checked. Having the guest account disabled is a plus. Restrict anonymousMBSA considers a restrict anonymous setting of 2 to be the goal (includes a brief explanation of these settings). File SystemThe file system on all drives is checked to see if it is NTFS. Auto LogonThe system is checked to make sure auto logon is not configured.

266

Chapter 8

Figure 8.4: MBSA returns information about common vulnerabilities and how to fix the situation.

Other areas are evaluated, including: AuditingIs it enabled? Are both logon success and failure checked? ServicesAre any of the especially dangerous services (RAS, Telnet, FTP, WWW, or SMTP) installed? SharesWhich 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 testsbecause 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.

267

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. Theyre 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 companys Windows 2000 (Win2K), Windows XP, and Windows Server 2003 computers and services. To do so, youll 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, Ill 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 thoroughlyyou might need to adjust the policies on some computers to allow some applications and services to function.

268

Chapter 8

Microsofts 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 youll 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 dont 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 Mutual authentication Security Principle Identifies each computer to the other. Each must present credentials that the other computer trusts. Confidentialitydata is kept private. Message integritywe know the message has not been changed in transit. Deflects these Attacks Identity spoofs, man-in-the-middle attacks

Encryption Message digests/checksum

A sniffer can capture the packet, but the data payload cannot be read Message spoofingif 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 Attacks directed at specific ports; filter known or questionable connections

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.

Table 8.2: IPSec features, security principles, and attack profiles.

269

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.
Item Authentication Method Filter Action Tunnel Setting Connection Type Function How will the computers mutually authenticate? Choices are shared key, Kerberos, and certificates. What will happen if the filter is triggered? Will a tunnel be used? If a tunnel is not to used, the IPSec policy is said to be in IPSec transport mode. Should this filter work on the entire network? The local LAN? Only remote connections?

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.
Item Source Destination Address Mirror Protocol Type From, To port Function Is this packet from my computer? A particular computer? All computers in a subnet? Will this packet go to my computer? A particular computer? All computers in a subnet? Should the filter be mirrored (packets in the opposite direction)? Which protocolTCP or Internet Control Message Protocol (ICMP)? 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. PermitAllow the specified traffic to proceed. BlockPrevent the specified traffic from leaving or being received by the computer. Negotiate SecurityNegotiate 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.

270

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 AHs 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.

Component Next header Length Security Parameter Index (SPI)

Function Indicates the protocol The length of the AH header 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 belongs. 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.

Sequence Number

Authentication Data

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.

271

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.

272

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, were 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, well 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 Next.
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, well 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.

273

Chapter 8

Figure 8.7: Setting the authentication method.

Testing 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 stepyou 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.

274

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.

275

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 couldnt just anyone who understands IPSec create their own policy and get right back in the game? As youve 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, theyll 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 users 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 DirectoryAD.)You should also remember that once the users 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 CAs 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 youll need to change the IPSec policy to require them.

276

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 CAs 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 shows.

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.

277

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.

278

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 unsuccessful.

Q. 8.4: Im 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. Heres how it works: When you use GenerateRollback, it walks the new template looking for configured settings. When it finds one, it analyzes the current computers 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.

279

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. Switch /GenerateRollback Function Generate a template that can be used to roll back to the previous state The name of the template of which to create a rollback template The name of the rollback template Comments 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 templates application. 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. 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. If no log directory is specified the %windir%\security\logs folder will be used. The file produced is scesrv.log. This is a useful switch when you want to include this command in a batch file that will run in the background.

/CFG

/RBK

/log

The path where a log of the activity should be located Activity should not produce comments

/quiet

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)

280

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: Id 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.

281

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.

282

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.

283

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 pages. 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.

284

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 problemless 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.

285

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. Im 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, Ive 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 well eventually have multiple users connecting, but to start, well build the policy and test it between one user and the file server. After this setup is up and running, its a simple process to place the IPSec policy on an organization unit (OU) in which computers used for communication will have their accounts.
Its 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, Ill give you my recommendation. Its important to make these decisions before creating the policy. Policy parameters must match or communication wont work. (Ill explain where you can find the following policies later in this tip.) AuthenticationThree 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. Its a good practice to test the policy first with shared key, then move to another authentication. If youre 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 computers 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. EncryptionChoices 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), Id leave this setting alone. After the policy is tested and working, it can always be tweaked to remove the weaker choice. 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.

286

Chapter 8 Diffie-Hellman groupDuring 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 regenerationA master key is created in Main Mode or the IKE phase. The master key is used to create the session keysthe 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. FilterThe 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 well set a single filter based on IP addresses. You can expand the filters and make the encryption more specific if you choose.

Create the Policy Now we are ready to create the policy. After we do so, well 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.

287

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.

288

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 wont 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.

289

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. Well leave the settings at their defaults to make our job easier. You might determine that they need to be adjusted, just dont 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, rightclick 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.

290

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.

291

Chapter 8

Figure 8.21: Evidence that confidentiality (encrypted) packets have been sent and received.

292