PWorkbook DirectoryServices NewHire Week3

Readiness and Sustained Education
Supporting Windows Operating Systems:

Directory Services New Hire Week 3
This Workbook provides reference material to accompany course presentations.
Released: 17 June 2005
MICROSOFT CONFIDENTIAL - For Internal Use Only
Terms of Use
Information in this document, including URL and other Internet Web site references, is subject to change without
notice. Unless otherwise noted, the example companies, organizations, products, domain names, e-mail
addresses, logos, people, places, and events depicted herein are fictitious, and no association with any real
company, organization, product, domain name, e-mail address, logo, person, place, or event is intended or should
be inferred. Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights
under copyright, no part of this document may be reproduced, stored in or introduced into a retrieval system, or
transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), or for any
purpose, without the express written permission of Microsoft Corporation.
For more information, see Microsoft Copyright Permissions at http://www.microsoft.com/permission
Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights
covering subject matter in this document. Except as expressly provided in any written license agreement from
Microsoft, the furnishing of this document does not give you any license to these patents, trademarks, copyrights,
or other intellectual property.
2005 Microsoft Corporation. All rights reserved.
The Microsoft company name and Microsoft products mentioned herein may be either registered trademarks or
trademarks of Microsoft Corporation in the United States and/or other countries. The names of actual companies
and products mentioned herein may be the trademarks of their respective owners.
THIS DOCUMENT IS FOR INFORMATIONAL AND TRAINING PURPOSES ONLY AND IS PROVIDED "AS IS" WITHOUT
WARRANTY OF ANY KIND, WHETHER EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE IMPLIED
WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, AND NON-INFRINGEMENT.
Supporting Windows Operating Systems: Directory Services New Hire Week 3

Table of Contents
Table of Contents
About This Course Week 3 .................................................................................................... 1

Audience................................................................................................................................... 1
Before You Begin..................................................................................................................... 1
What You Will Learn ............................................................................................................... 1
Content .................................................................................................................................... 1
Document Conventions ........................................................................................................ 2
Program Code Listings and Command Syntax................................................................... 3
Notes ......................................................................................................................................... 3
Demonstrations and Labs...................................................................................................... 4
Tables and Figures .................................................................................................................. 4
Workbook Section and Slide Numbering ............................................................................ 4
Instructor Notes ....................................................................................................................... 4
1. Troubleshooting Security Problems .................................................................................... 5

Before You Begin..................................................................................................................... 5
What You Will Learn ............................................................................................................... 5
Overview of Security .............................................................................................................. 5
What Are Groups? ................................................................................................................... 7
Group Types...................................................................................................................9
AdminSDHolder and Protected Groups................................................................. 9
What Are Access Control Lists? ..........................................................................................10
What Are Access Control Entries? ......................................................................................11
Types of Permissions............................................................................................................11
Inherited Permissions ................................................................................................ 11
Explicit Permissions ................................................................................................... 13
Active Directory Permissions...............................................................................................15
Exception to the Implicit/Explicit Permissions Rules with AD Permissions ............ 15
Overview of Delegation of Control ............................................................................. 16
Registry Permissions ............................................................................................................16
NTFS Permissions and Share Permissions .......................................................................17
Moving Versus Copying Files How it Affects Permissions ...........................................17
Resetting Permissions ........................................................................................................ 18
Implementing Security Policies......................................................................................... 19
User Right Assignments .......................................................................................................20
Audit Policies .........................................................................................................................20
Using Security Templates.....................................................................................................20
Using Secedit - Secedit.exe..................................................................................................21
Using Security and Configuration Manager.......................................................................22
Using Utilities to Troubleshoot Security Problems ......................................................... 22
Using Xcopy ............................................................................................................................22
Using Dsacls...........................................................................................................................23
Using Subinacl .......................................................................................................................23
Using TokenGroups.vbs ........................................................................................................24
Using ADtoken .......................................................................................................................24
Troubleshooting Security Problems.................................................................................. 24
Auditing...................................................................................................................................25
Common Problems with Security .......................................................................................26
How to Resolve Common Security Problems ...................................................................26
Examining Security Changes ............................................................................................. 26
New User Rights/Privileges .................................................................................................27
i
Table of Contents
LAB 1: Troubleshooting Security Problems..................................................................... 27

Resources............................................................................................................................. 28
Summary .............................................................................................................................. 28
2. Troubleshooting Trust Problems ....................................................................................... 29
Before You Begin...................................................................................................................29
What You Will Learn .............................................................................................................29
Reviewing Trusts ................................................................................................................. 29
Why the Need for Trust Relationships? .............................................................................30
Types of Trusts .......................................................................................................................30
Default Trusts..............................................................................................................30
Other Trusts.................................................................................................................31
Secure Channels....................................................................................................................32
Authentication Protocols......................................................................................................32
NTLM ...........................................................................................................................33
Kerberos Version 5 Protocol ......................................................................................33
Trusted Domain Object.........................................................................................................34
Creating Trust Relationships ............................................................................................. 35
Requirements for Creating Trusts ......................................................................................36
How to Create Trust Relationships between Windows Server 2003 or Windows 2000
and Windows NT 4.0.............................................................................................................36
How to Create Trust Relationships between Windows Server 2003 and Windows
2000........................................................................................................................................37
How to Create Trust Relationships between Windows Server 2003 and Windows
Server 2003 ...........................................................................................................................38
Using Utilities to Troubleshoot Trust Relationships Problems ..................................... 40
Using PortQuery.....................................................................................................................40
Using Netdom ........................................................................................................................42
Using NLTest ..........................................................................................................................43
Using Netmon ........................................................................................................................43
Using ADSIEdit .......................................................................................................................44
Using Ntdsutil.........................................................................................................................44
Troubleshooting Trust Problems....................................................................................... 44
Examining Common Problems with Trusts .......................................................................44
Common Name Resolution Problems ...............................................................................45
Common Connectivity Problems ........................................................................................45
Common Security Settings Problems ................................................................................45
User Rights ..................................................................................................................47
Security Settings .........................................................................................................47
How to Resolve Trust Problems ..........................................................................................51
Additional Information ................................................................................................52
LAB 2: Troubleshooting Trust Problems .......................................................................... 53
Resources............................................................................................................................. 53
Summary .............................................................................................................................. 53
3. Troubleshooting Group Policy Problems........................................................................... 55
Before You Begin...................................................................................................................55
What Is a Group Policy? ..................................................................................................... 55
What Is a Local Group Policy?.............................................................................................56
Differences Between Windows NT 4.0 Policy and Windows Server 2000 Group
Policy .......................................................................................................................................56
Disadvantages of System Policies .............................................................................56
ii
Table of Contents
Advantages of Windows 2000 Group Policies.......................................................... 56

Active Directory Structure and Group Policy .....................................................................57
What Is the Order of Group Policy Application? ...............................................................57
Where Are GPOs Stored? .....................................................................................................59
Group Policy Container .............................................................................................. 59
Group Policy Template ............................................................................................... 60
What Are Client-Side Extensions?.......................................................................................60
Creating Group Policy..........................................................................................................61
Creating a Group Policy Object (GPO) ................................................................................61
Editing a GPO .........................................................................................................................62
Linking a GPO ........................................................................................................................62
What Is User Group Policy Loopback Mode? ....................................................................63
Using Group Policy Core Troubleshooting Tools.............................................................. 63
Using Resultant GP Tools.....................................................................................................64
GPResult.exe .............................................................................................................. 64
Interpreting GPResult Output............................................................................... 64
User Output ..................................................................................................... 64
Administrative Templates (Registry-Based Policy)........................................ 65
Folder Redirection .......................................................................................... 67
Scripts.............................................................................................................. 68
Application Management ............................................................................... 68
Other Group Policy Extensions ....................................................................... 70
Computer Output ............................................................................................ 70
Security Privileges ................................................................................................ 72
GPResult Win2K Reskit .................................................................................... 73
Win2K GPResult - Syntax ..................................................................................... 73
WinXP GPResult Syntax .................................................................................... 73
Using Help and Support Center (HSC) RSoP Report ................................................ 74
Using RSoP Snap-in.................................................................................................... 75
Using Group Policy Verification Tool...................................................................................78
Using User Environment Debug Logging ...........................................................................79
Using Group Policy Editor Debug Logging .........................................................................79
Using GPText Debug Logging ..............................................................................................80
Considerations for Group Policy Core Troubleshooting ................................................. 81
Troubleshooting Group Policy Settings Problems............................................................81
Identifying and Resolving Group Policy Settings Problems...................................... 81
Were You Authenticated by a DC?....................................................................... 81
Can You Access Sysvol? ....................................................................................... 82
Check ACLs on GPO.............................................................................................. 83
Check GPO and OU Properties............................................................................. 83
What Is the Replication Status of the GPO? ....................................................... 83
Troubleshooting Client Side Extension Problems ............................................................84
Registry-Based Settings in Windows 2000 Policy .................................................... 84
Troubleshooting the Registry Client-Side Extension................................................. 84
Troubleshooting Scripts CSE ..................................................................................... 85
Script Storage - SYSVOL ....................................................................................... 85
Script Storage - Local GPO ................................................................................... 86
Typical Scripts CSE Process Errors ...................................................................... 86
Hung Scripts.................................................................................................... 86
Troubleshooting Security CSE Issues........................................................................ 87
Enabling SCECLI Debug Logging.......................................................................... 87
Security CSE Process ........................................................................................... 88
iii
Table of Contents
Common Security CSE Events ..............................................................................88

Troubleshooting Folder Redirection CSE...................................................................89
Troubleshooting Common Folder Redirection Issues .........................................89
Troubleshooting Software Installation CSE ...............................................................89
Gathering Troubleshooting Information...............................................................90
Verbose Logging ..............................................................................................90
Windows Installer Verbose Logging................................................................90
Repairing Default Policies ................................................................................................. 91
Recreating Default Policies .................................................................................................92
LAB 3: Troubleshooting Group Policy Problems............................................................. 92
Resources............................................................................................................................. 93
Summary .............................................................................................................................. 93
4. Troubleshooting User Profile Problems ............................................................................ 95

Before You Begin...................................................................................................................95
User Profile Overview.......................................................................................................... 95
User Profile Options ..............................................................................................................95
Settings Saved in a User Profile..........................................................................................96
Advantages of User Profiles ................................................................................................97
Types of User Profiles ......................................................................................................... 97
Local Profiles .........................................................................................................................97
Stored Location of Local Profiles ...............................................................................98
New Users ...................................................................................................................98
To Copy a User Profile.................................................................................................99
To Delete a User Profile..............................................................................................99
Roaming Profiles...................................................................................................................99
Computer Configuration for Profiles in Group Policy ............................................. 100
Delete Cached Copies of Roaming Profiles ...................................................... 100
Do Not Detect Slow Network Connections ....................................................... 101
Slow Network Connection Timeout for User Profiles........................................ 101
Wait for Remote User Profile ............................................................................. 101
Prompt User When Slow Link Is Detected ........................................................ 101
Log Users Off When Roaming Profile Fails ....................................................... 102
User Configuration for Profiles in Group Policy ...................................................... 102
Connect Home Directory to Root of the Share ................................................. 102
Exclude Directories in Roaming Profile............................................................. 103
Limiting Profile Size............................................................................................ 103
Slow Link Effects on Roaming User Profiles........................................................... 104
Profile Availability..................................................................................................... 105
Multiple User Accounts ...................................................................................... 105
Creating a Roaming Profile................................................................................ 106
Switching Between Roaming and Local User Profile ....................................... 108
Add a Home Directory to a User Profile ............................................................ 108
Mandatory Profiles............................................................................................................. 108
Mandatory Profile Benefits...................................................................................... 109
Creating a Mandatory User Profile.......................................................................... 109
Assigning a Roaming Mandatory User Profile ........................................................ 109
NTUser.dat / NTUser.man ....................................................................................... 110
Common Causes of User Profile Problems ................................................................... 110
Troubleshooting User Profile Loading and Unloading Problems ............................... 111
iv
Table of Contents
Using Utilities for Troubleshooting Problems with User Profiles................................. 111

Userenv Logging .......................................................................................................111
UPHclean ..................................................................................................................112
Leaktrackdump and DBGview .................................................................................113
LAB 4: Troubleshooting Common Problems with User Profiles .................................113
Resources ...........................................................................................................................114
Summary.............................................................................................................................114
5. Troubleshooting Account Lockout Problems .................................................................115

Before You Begin................................................................................................................ 115
What You Will Learn .......................................................................................................... 115
Examining Password Policies ..........................................................................................115
Enforce Password History ................................................................................................. 116
Maximum Password Age .................................................................................................. 116
Common Issue with Maximum Password Age ........................................................116
Minimum Password Age ................................................................................................... 117
Minimum Password Length.............................................................................................. 117
Password Must Meet Complexity Requirements .......................................................... 117
Store Passwords Using Reversible Encryption............................................................... 118
Examining Account Lockout Policy.................................................................................118
Account Lockout Duration ................................................................................................ 118
Account Lockout Threshold .............................................................................................. 119
Reset Account Lockout Counter ...................................................................................... 119
Examining Types of Attacks on a Domain .....................................................................119
Dictionary Versus Brute Force .......................................................................................... 120
Examining Domain Controller Behavior .........................................................................120
How Domain Controllers Verify Passwords .................................................................... 120
Replication Triggers ........................................................................................................... 121
Kerberos Negative Caching .............................................................................................. 121
New Features in the Windows Server 2003 Family...................................................... 121
Computers Running Windows Server 2003 that Act as Network Servers as well as
2000 SP 4 ................................................................................................................121
Troubleshooting Account Lockout Problems ................................................................121
Recommended Service Packs and Hotfixes .................................................................. 121
Common Causes for Account Lockouts.......................................................................... 121
Other Potential Issues ....................................................................................................... 121
Maintaining and Monitoring Account Lockout............................................................... 121
Enable Auditing at the Domain Level and Domain Controllers OU........................121
Windows 2000 and Windows Server 2003 Domains ......................................121
Netlogon Logging......................................................................................................121
Kerberos Logging .....................................................................................................121
Event and Netlogon Log Retrieval ...........................................................................121
Analyzing Log File Information.................................................................................121
Analyzing Netlogon Log Files .............................................................................121
Transitive Network Logon (Pass-Through Authentication)..........................121
Netlogon Log File Error Codes......................................................................121
Analyzing Event Logs ..........................................................................................121
Using Account Lockout Tools ...........................................................................................121
The Lockoutstatus.exe Tool .............................................................................................. 121
The Alockout.dll Tool.......................................................................................................... 121
The Aloinfo.exe Tool........................................................................................................... 121
The Acctinfo.dll Tool........................................................................................................... 121
v
Table of Contents
The EventcombMT.exe Tool .............................................................................................. 121

The Nlparse.exe Tool.......................................................................................................... 121
The Findstr.exe Tool ........................................................................................................... 121
The Windows Logon Monitor V1.0 Tool .......................................................................... 121
Event Log Samples .................................................................................................. 121
Using Excel to Go Through Logs ....................................................................................... 121
LAB 5: Troubleshooting Account Lockout Problems ................................................... 121
Resources........................................................................................................................... 121
Summary ............................................................................................................................ 121
6. Troubleshooting Logon Failures...................................................................................... 121

Before You Begin................................................................................................................ 121
Differences Between Logon Failures and Account Lockouts ..................................... 121
The Logon Process ............................................................................................................ 121
Finding a Domain Controller Required for Logon ......................................................... 121
Cross Forest Logon .................................................................................................. 121
WINS Records .......................................................................................................... 121
DNS SRV Records .................................................................................................... 121
Domain Controller from Last Validation Cached by Netlogon .................................... 121
Cached Credentials ............................................................................................................ 121
Examining Error Messages .............................................................................................. 121
Examining General Causes of Logon Failures .............................................................. 121
Lack of Name Resolution to Resolve a Domain Controller ......................................... 121
Connectivity Issues............................................................................................................. 121
Third Party Applications or Services................................................................................ 121
Other Possible Causes....................................................................................................... 121
Examining Security Causes of Logon Failures.............................................................. 121
GPO Settings ....................................................................................................................... 121
SMB Signing ........................................................................................................................ 121
Crashonauditfail ................................................................................................................. 121
Restrictanonymous ............................................................................................................ 121
Lmcompatibilitylevel ......................................................................................................... 121
Pre-Windows 2000 Compatible Permissions ................................................................ 121
Troubleshooting Logon Failures...................................................................................... 121
Gathering Information ....................................................................................................... 121
What Does the Error Message Point To?................................................................ 121
What Is Common Among Affected Users?.............................................................. 121
Is the Problem Computer or User Specific? ........................................................... 121
What Are the Recent Changes to a Network?........................................................ 121
What Are the Service Pack Levels on Domain Controllers and Clients? .............. 121
Analyzing Gathered Information...................................................................................... 121
Using Utilities for Troubleshooting Logon Failures....................................................... 121
Using Runas ........................................................................................................................ 121
Using Kerbtray and Klist.................................................................................................... 121
Taking Traces...................................................................................................................... 121
LAB 6: Troubleshooting Logon Failures ......................................................................... 121
Resources........................................................................................................................... 121
Summary ............................................................................................................................ 121
7. Troubleshooting EFS Problems ....................................................................................... 121

Before You Begin................................................................................................................ 121
vi
Table of Contents
Overview of EFS..................................................................................................................121
What Is EFS? ....................................................................................................................... 121
The Encryption Process ..................................................................................................... 121
Structure of an Encrypted File .................................................................................121
The Encryption Process............................................................................................121
The Decryption Process..................................................................................................... 121
The Recovery Process........................................................................................................ 121
Examining Results of Selecting Different Options .......................................................121
Results of Apply Changes to this folder only versus Apply Changes to this folder,
subfolders and files .......................................................................................................... 121
Adding Additional Users .................................................................................................... 121
Examining Public and Private Keys ................................................................................121
Moving and Copying Encrypted Files and Folders ........................................................121
Examining Local Encryption and Encryption on Remote Servers ..............................121
Trusted for Delegation....................................................................................................... 121
Certificates Available......................................................................................................... 121
Is the Certificate Valid? ............................................................................................121
Recovery Agents................................................................................................................. 121
Using Available Recovery Agents.............................................................................121
Adding New Recovery Agents ..................................................................................121
Examining EFS Limitations ..............................................................................................121
Recommended Practices .................................................................................................121
Using Utilities for Troubleshooting EFS Problems ........................................................121
Using Efsinfo ....................................................................................................................... 121
Using SecPol.msc ............................................................................................................... 121
Using Cipher ........................................................................................................................ 121
Troubleshooting EFS Problems .......................................................................................121
Common Problems with EFS............................................................................................ 121
How to Resolve Common EFS Problems?...................................................................... 121
New Features in Windows 2003 .....................................................................................121
LAB 7: Troubleshooting EFS Problems...........................................................................121
Resources ...........................................................................................................................121
Summary.............................................................................................................................121
Appendix A: Privileges and Logon Rights ...........................................................................121
Privileges.............................................................................................................................121
Logon Rights.......................................................................................................................121
Tables
Table 1. Note Icons ................................................................................................................................................. 3

Table 2. Demonstration and Lab Icons.................................................................................................................. 4
Table 3. Group Scopes - Behaviors ........................................................................................................................ 8
Table 4. Default Trusts ......................................................................................................................................... 31
Table 5. Other Trusts ............................................................................................................................................ 31
Table 6. Ports Required for Trusts ....................................................................................................................... 40
Table 7. Client Side Extensions............................................................................................................................ 61
Table 8. User Profile Settings ............................................................................................................................... 96
Table 9. Netlogon Log Error Codes ....................................................................................................................121
Table 10. Group Policy Settings Associated with Interactive Logon ................................................................121
Table 11. RestrictAnonymous Settings..............................................................................................................121
Table 12. Tickets.................................................................................................................................................121

vii
Table of Contents
Table 13. TGT...................................................................................................................................................... 121

Table 14. User Privileges.................................................................................................................................... 121
Table 15. Logon Rights....................................................................................................................................... 121
Table 16. Default Settings for Security Options Policies.................................................................................. 121
Figures
Figure 1. Slide Number Paragraphs .......................................................................................................................4

Figure 2. Relationship of Security Descriptors and ACLs to Authorization and Access Control Components....6
Figure 3. Permission Entries on Public Folder (Owner: Administrators).............................................................12
Figure 4. Permission Entries on Engineering Data Folder (Owner: Alice)...........................................................13
Figure 5. Modified Permission Entries on Engineering Data Folder ...................................................................14
Figure 6. The Delegation of Control Wizard .........................................................................................................16
Figure 7. External Trust Between a Windows NT 4.0 Domain and a Windows Server 2003 Forest Child
Domain .............................................................................................................................................................36
Figure 8. External trusts Between a Windows Server 2003 Forest and a Windows 2000 Forest....................37
Figure 9. Two Forest Trusts Between Three Windows Server 2003 Forests .....................................................39
Figure 10. Group Policy Inheritance .....................................................................................................................57
Figure 11. Policy Filtering Using Security Groups ................................................................................................58
Figure 12. GPO Storage Locations........................................................................................................................59
Figure 13. Extensible Group Policy Framework ...................................................................................................60
Figure 14. Group Policy Object Editor...................................................................................................................62
Figure 15. RSoP Results .......................................................................................................................................75
Figure 16. Choosing a Target User in the RSoP Wizard ......................................................................................76
Figure 17. RSoP Results .......................................................................................................................................77
Figure 18. Viewing Enabled Policies in RSoP Results .........................................................................................77
Figure 19. RSoP Snap-In User Interface...............................................................................................................78
Figure 20. Local Profile .........................................................................................................................................97
Figure 21. Roaming Profile ................................................................................................................................ 100
Figure 22. Group Policy Dialog Box.................................................................................................................... 100
Figure 23. Group Policy Dialog Box.................................................................................................................... 102
Figure 24. Link Effects on Roaming User Profiles ............................................................................................ 104
Figure 25. Profile Tab ......................................................................................................................................... 106
Figure 26. User Profiles Tab............................................................................................................................... 107
Figure 27. Mandatory Profile ............................................................................................................................. 109
Figure 28. Steps That Occur When a Logon Does not Work ............................................................................ 120
Figure 29. DCs Having badpwdcount ............................................................................................................... 121
Figure 30. user1 Properties Dialog Box ............................................................................................................ 121
Figure 31. EventCombMT Tool........................................................................................................................... 121
Figure 32. Nlparse.exe Tool ............................................................................................................................... 121
Figure 33. Event logged When Using MMC to Check Services on Remote Computer.................................... 121
Figure 34. Event Logged When Using Telnet Connect to a Server That Requires NTLM Authentication ...... 121
Figure 35. Sorted by the Event 681, a User Named jz9nz1 With the Error Code Event 3221225578 ........ 121
Figure 36. The Logon Process ........................................................................................................................... 121
Figure 37. Structure of an Encrypted File ......................................................................................................... 121
Figure 38. EFS Encryption with a DRA............................................................................................................... 121
Figure 39. EFS Decryption.................................................................................................................................. 121
Figure 40. EFS File Recovery ............................................................................................................................. 121
Figure 41. Confirm Attribute Changes Dialog Box ............................................................................................ 121
Figure 42. Encryption Details Dialog Box .......................................................................................................... 121
Figure 43. The Certificates Console .................................................................................................................. 121
Figure 44. The Certificates Console .................................................................................................................. 121
viii
About This Course Week 3

This weeks content continues to focus on the core components: security, trusts, group policy,
profiles, logons, and EFS. A good working knowledge in these areas is expected from every
Support Engineer.
Audience
This course is intended for Microsoft Support Professionals.
Before You Begin

1
Before starting this course, you should:
Have successfully completed the previous modules in this course.
Understand the concepts discussed and examined in the previous modules.
What You Will Learn

2
After completing this course, you will be able to understand and troubleshoot problems
related to:
Security
Trusts
Group Policy
User Profiles
Account Lockouts
Logon Failures
EFS
Content
3
Course materials include the following <multimedia | classroom> presentations, a Workbook

that contains supplemental reference information, <and a Lab Manual that contains practice
exercises>:
1. Troubleshooting Security Problems
The Microsoft Windows 2000 operating system protects files, applications, and other
resources from unauthorized use. Although you might already know how to use tools to
assign privileges or set permissions, understanding what privileges and permissions
really are, why they are necessary, and how they function can help you manage shared
resources effectively. Understanding these processes can also help you avoid
unnecessary risks and troubleshoot any problems you might encounter.
1
2. Troubleshooting Trust Problems

Trust technology is the foundation for the security architecture in Microsoft Windows
2000 and Windows Server 2003 networks using the Active Directory service. Trusts
enable network administrators to implement an authentication and authorization strategy
for sharing resources across domains or forests and provide a mechanism for
centralizing management of multiple domains and forests.
3. Troubleshooting Group Policy Problems
This session discusses how to troubleshoot group policy problems. To begin with, you will
learn about the purposes and components of Group Policy. Next, you will learn how to
create, edit, and link Group Policy. In addition, you will learn about the core Group Policy
troubleshooting tools and considerations for Group Policy core troubleshooting. Then, you
will learn how to troubleshoot problems with GP Settings and Client Side Extensions.
Finally, you will learn how to repair default the two default policies.
4. Troubleshooting User Profile Problems
This session explains what user profiles are and their problems loading and unloading. It
also explains how to troubleshoot user profile problems.
5. Troubleshooting Account Lockout Problems
Account lockout policy disables users accounts if an incorrect password is entered a
specified number of times over a specified period. These policy settings help you to
prevent attackers from guessing users passwords, and they decrease the likelihood of
successful attacks on a network. Before enabling an account lockout policy, it is
important to realize that there is a risk of unintentionally locking authorized users out of
their accounts.
6. Troubleshooting Logon Failures
Troubleshooting logon failures comes down to troubleshooting authentication. This
session explains how to troubleshoot logon failures.
7. Troubleshooting EFS Problems
EFS provides the core file encryption technology for storing files on NTFS file system
volumes. When files are encrypted, data in them is protected even if an attacker has full
access to the data storage system on the computer. This session explains how to
troubleshoot EFS problems.
Document Conventions
The following conventions are used in all course materials:
Acronyms appear in all uppercase letters.
Names of files appear in all uppercase letters, except when you are to type them directly
in a command statement. Unless otherwise indicated, you can use all lowercase letters
when you type a filename in a dialog or at a command prompt.
Filename extensions without a filename appear in all lower-case letters.
Book titles appear in Italic.
Other document conventions are described below.
2
Program Code Listings and Command Syntax

Program code listings, entries typed at a command prompt or in scripts or initialization files,
and text mode or command output text appear in Monospace type.
Program code listings and descriptive comments are formatted as shown in the following
example. The ellipsis (...) on the last line indicates a partial listing.
C:\%systemroot%>dir /ad
The variable %systemroot% refers to the drive and directory where the Microsoft Windows
operating system is installed.
Volume in drive C is Main
Volume Serial Number is 000A-BCDE
Directory of C:\%systemroot%
12/19/2004
12/19/2004
07/07/2003
11/17/2004
11/17/2004
11/17/2004
...
11:56
11:56
06:57
02:45
02:47
02:42
AM
AM
AM
PM
PM
PM
<DIR>
<DIR>
<DIR>
<DIR>
<DIR>
<DIR>
.
..
addins
Application Compatibility Scripts
AppPatch
Cache
Command syntax statements are formatted as shown below:

command {parameter1, parameter2, title} [option1 | option2]
Type command statement elements that appear in Bold exactly as they appear in the
example, including quotation marks.
Italic in command syntax statements indicates placeholders for variable information.
Braces ({ }) enclose required items as shown by {parameter1, parameter2,

title} in the example. Commas separate multiple items. Do not type the braces.
Square brackets ([ ]) enclose optional items as shown by [option1 | option2] in

the example. Pipe symbols (|) indicate alternate choices. Do not type the brackets.
Notes
Left margin icons and labels call attention to key information as described in Table 1.
Table 1. Note Icons
Icon
Label
Description
Note
Provides supplemental information such as related actions or results
Tip
Suggests alternate methods of performing tasks
Important Provides information that is essential to completing a task

CAUTION
Warns about possible loss of data or other undesirable results

3
Demonstrations and Labs

Header icons call attention to demonstrations and lab exercises as shown in Table 2.
Table 2. Demonstration and Lab Icons
Icon
Description
Indicates a demonstration to be performed by the Instructor or presented in
multimedia format
Indicates lab exercises to be performed by the Participant using detailed
instructions in Lab Manual
Tables and Figures

To help you find key information quickly, each table and figure is preceded by Caption.
Captions are numbered sequentially throughout course documents and are listed in the
Tables and Figures sections of the course document Table of Contents.
Workbook Section and Slide Numbering

Course module titles are numbered sequentially (i.e. 1. Session Title). Presentation slides are
numbered in the lower left corner. The first slide and last slide do not display slide numbers.
Workbook sections include two types of slide number paragraphs as shown in Figure 1 to
identify corresponding slides in the presentation.
Figure 1. Slide Number Paragraphs
Note
Each presentation slide corresponds to a workbook section. However, workbook sections

that include supplemental information may not be referenced on corresponding
presentation slides.
Instructor Notes
Superscript numbers in workbook and lab manual paragraphs reference numbered
paragraphs in the Instructor Notes section that contain information to assist in course
delivery. This section is only included in the Instructor versions of the Workbook and Lab
Manual.
4

The Microsoft Windows 2000 operating system protects files, applications, and other
resources from unauthorized use. Although you might already know how to use tools to assign
privileges or set permissions, understanding what privileges and permissions really are, why
they are necessary, and how they function can help you manage shared resources effectively.
Understanding these processes can also help you avoid unnecessary risks and troubleshoot
any problems you might encounter.
Before You Begin

1
Before starting this session, you should be familiar with:
Using Active Directory Users and Computers for viewing Active Directory objects.
The general concept of groups for managing users.
The GUI for setting permissions on Files and Folders.
What You Will Learn

2
After completing this session, you will be able to:
Explain the basic concepts related to Security.
Explain how to reset permissions.
Explain the different utilities used to implement and troubleshoot security policies.
Explain how to troubleshoot common problems with security.
Identify the security changes from Windows NT 4.0 to Windows Server 2003.
Overview of Security
3
The details of how access control works are quite complex, but the big picture is fairly simple:
Subjects act on objects. In the sentence, "Alice opens the file," Alice is the subject, or the
agent of an action; opens is the action; and the file is the object. The grammar is similar in
Windows 2000.
However, there are some important differences. When you say, "Alice opens the file," you know
that it is not really Alice who opens the file; it is done by a program. To be more precise, the
program runs as a process with threads of execution. It is actually one of those threads that
opens the file. Threads are the only real agents of action on a computer. In the grammar of
access control, the subject is always a thread.

5
In order for a thread to gain access to an object, it must identify itself to the operating
system's security subsystem. A thread does not have a security identity, so it must borrow one
from a security principal, such as Alice. When Alice logs on, her security identity is
encapsulated in an access token that is associated with her logon session. When Alice starts
an application, it runs as a process within her logon session. The application process and each
of its threads of execution receive copies of Alice's access token. When one of the
application's threads needs to open a file, the thread identifies itself as Alice's agent by
presenting her access token. Thus, responsibility for anything that the thread does to the file
on Alice's behalf is charged to Alice. This is the same behavior as if a user was accessing a
service or file remotely, the token is built for that user and attached to the users actions for
the duration of their session.
Before allowing the thread of execution to proceed, the operating system performs an access
check to determine whether the security principal associated with the thread is authorized the
level of access that the thread has requested. An access check compares information in the
thread's access token with information in the object's security descriptor:
The access token contains a SID that identifies the user and SIDs that identify the groups
whose members include the user.
The objects security descriptor contains a list of access control entries (ACEs) that
specify the access rights that are allowed or denied to particular users or groups SIDs.
The security subsystem checks the objects security descriptor, looking for ACEs that apply to
the user and group SIDs in the subjects access token. The system examines each ACE in
order until it finds one that either allows or denies access to the user or one of the users
groups, or until there are no more ACEs to check. If there is more than one ACE that applies to
the user, the result is cumulative. If the access check reaches the end of the DACL and the
desired access is still not explicitly allowed or denied, the security subsystem denies access.
Figure 2. Relationship of Security Descriptors and ACLs to Authorization and Access Control Components
6
The Windows Server 2000 and 2003 security infrastructure consists of the following
components:
Logon and Authentication Technologies

Logon and authentication technologies include a variety of protocols, including Kerberos
version 5 authentication, NTLM, Secure Sockets Layer/Transport Layer Security
(SSL/TLS), and Digest; as well as features such as Stored User Names and Passwords
that enable single sign-on (SSO) and reduced sign-on (RSO).
Authorization and Access Control Technologies

The ACL-based impersonation model and a new roles-based protected subsystem model
enable extremely flexible and manageable authorization and access control strategies.
Data Security Technologies

Encrypting File System (EFS), Internet Protocol security (IPSec), system key utility
(Syskey), and Routing and Remote Access Services (RRAS) provide additional security for
data under a variety of special circumstances.
Group Policy Technologies

Group Policy options that can enhance security management include security policy and
software restriction policies.
Trust Technologies
Trusts can be established between domains and across forests to improve security and
business processes for complex organizations.
Public Key Infrastructure (PKI) Technologies

Certificates, Certificate Services, and certificate policy-enabled qualified subordination
can be used to support a variety of application-specific security solutions.
Each of these sets of technologies can be used in conjunction with the other sets of
technologies, such as networking and storage, to enable secure network-enabled business
processes.
This session focuses on access control technologies.
What Are Groups?

5
Group accounts are used to manage privileges for multiple users. Global group accounts, for
domain use, are created in Active Directory Users and Computers, while local group accounts,
for local system use, are created in Local Users and Groups. Generally, group accounts are
created to facilitate the management of similar types of users in accessing objects.
Each security and distribution group has a scope that identifies the extent to which the group
is applied in the domain tree or forest. There are three different scopes: universal, global, and
domain local.
Groups with universal scope can have as their members groups and accounts from any
Windows 2000/2003 domain in the domain tree or forest and can be granted
permissions in any domain in the domain tree or forest. Groups with universal scope are
referred to as universal groups.
Groups with global scope can have as their members groups and accounts only from the
domain in which the group is defined and can be granted permissions in any domain in
the forest. Groups with a global scope are referred to as global groups.

7
Groups with domain local scope can have as their members groups and accounts from a
Windows 2000/2003 or Windows NT domain and can be used to grant permissions only
within a domain. Groups with a domain local scope are referred to as domain local
groups.
In the case of multiple forests, users defined in only one forest cannot be placed into groups
defined in another forest, and groups defined in only one forest cannot be assigned
permissions in another forest.
The following table summarizes the behaviors of the different group scopes.
Table 3. Group Scopes - Behaviors
Universal Scope
Global Scope
Domain Local Scope
In native-mode domains, can

have as their members
accounts from any domain,
global groups from any
domain and universal groups
from any domain.

accounts from the same
domain and global groups from
the same domain.
In native-mode domains, can have

as their members accounts,
global groups, and universal
groups from any domain, as well
as domain local groups from the
same domain.
In mixed-mode domains,
security groups with
universal scope cannot be
created.

accounts from the same
domain.
In native-mode domains, can have

as their members accounts and
global groups from any domain.
Groups can be put into other Groups can be put into other
groups (when the domain is groups and assigned
in native-mode) and
permissions in any domain.
assigned permissions in any
domain.
Groups can be put into other

domain local groups and assigned
permissions only in the same
domain.
Cannot be converted to any

other group scope.
Can be converted to universal

scope, as long as it does not have
as its member another group
having domain local scope.
Can be converted to universal

scope, as long as it is not a
member of any other group
having global scope.
When creating a new group, by default, the new group is configured as a security group with
global scope regardless of the current domain mode. Changing a group scope can be
accomplished by the following allowed conversions:
Note
Global to Universal
This is only allowed if the group is not a member of another group having global scope.
Domain Local to Universal

The group being converted cannot have as its member another group having domain
local scope.
Changing a group scope is not allowed in mixed-mode domains. Note that mixed-mode
domains are not part of the evaluated configuration.
8
Group Types
6
There are two types of groups in Windows 2000:
Security Groups
Security groups are listed in discretionary access control lists (DACLs) that define
permissions on resources and objects. Security groups can also be used as an e-mail
entity. Sending an e-mail message to the group sends the message to all the members of
the group.
Distribution Groups
Distribution groups are not security-enabled. They cannot be listed in DACLs. Distribution
groups can be used only with e-mail applications (such as Exchange), to send e-mail to
collections of users.
Note
Although a contact can be added to a security group as well as to a distribution group,

contacts cannot be assigned rights and permissions. Contacts in a group can be sent email.
Experience shows that using the approach described below will help you achieve maximum
flexibility, scalability, and ease of administration when managing security groups. Using
Account (global) groups and Resource (local) groups in the way described here lets you use
groups to mirror your organization's functional structure.
Put users into security groups with global scope. A global group can usually be thought of
as an Accounts group, that is, a group that contains user accounts.
Put resources into security groups with domain local (or machine local) scope. A local
group can usually be thought of as a Resource group, that is, a group to which you assign
permissions to access a resource.
Put a global group into any domain local (or machine local) group in the forest (this is
especially efficient when more than one domain is involved).
Assign permissions for accessing resources to the domain local (or machine local) groups
that contain them.
Delegate administration of groups to the appropriate manager or group leader.
AdminSDHolder and Protected Groups

Active Directory uses a protection mechanism to make sure that ACLs are set correctly for
members of sensitive groups. The mechanism runs once an hour on the PDC Emulator
Operations Master. The operations master compares the ACL on the user accounts that are
members of protected groups against the ACL on the following object, where
DC=<MyDomain>,DC=<Com> in this path with the distinguished name (also known as DN) of
your domain:
CN=AdminSDHolder,CN=System,DC=<MyDomain>,DC=<Com>

9
If the ACL is different, the ACL on the user object is overwritten to reflect the security settings
of the adminSDHolder object (and ACL inheritance is disabled). This process protects these
accounts from being modified by unauthorized users if the accounts are moved to a container
or organizational unit where a malicious user has been delegated administrative credentials
to modify user accounts. Note that when a user is removed from the administrative group, the
process is not reversed and must be manually changed.
The following list describes the protected groups in Windows 2000:
Enterprise Admins
Schema Admins
Domain Admins
Administrators
The following list describes the protected groups in Windows Server 2003 and in Windows
2000 Service Pack 4 or after you apply the 327825 hotfix:
Administrators
Account Operators
Server Operators
Print Operators
Backup Operators
Domain Admins
Schema Admins
Enterprise Admins
Cert Publishers
Additionally the following users are also considered protected:
Administrator
Krbtgt
What Are Access Control Lists?

7
An access control list (ACL) is an ordered list of access control entries (ACEs) that define the
protections that apply to an object and its properties. Each ACE identifies a security principal
and specifies a set of access rights allowed, denied, or audited for that security principal.
An object's security descriptor can contain two ACLs:
A discretionary access control list (DACL) that identifies the users and groups who are
allowed or denied access
A system access control list (SACL) that controls how access is audited
10
You can use this access control model to individually secure objects such as files and folders
on NTFS, Active Directory objects, registry keys, and printers, as well as devices, ports,
services, processes, and threads. Because of this individual control, you can adjust the
security of objects to meet the needs of your organization, delegate authority over objects or
attributes, and create custom objects or attributes that require unique security protections to
be defined.
What Are Access Control Entries?

8
All ACEs include the following access control information:
A SID that identifies a user or group
An access mask that specifies access rights
A set of bit flags that determine whether child objects can inherit the ACE
A flag that indicates the type of ACE
Types of Permissions
9
A permission is authorization to perform an operation on a specific object, such as a file.

Permissions are granted by owners. If you own an object, you can grant any user or security
group permission to do whatever you are authorized to do with it. This includes granting
permission to take ownership.
Tip
Although you can give permissions to individual users, it is more efficient to give them to
a security group. That way you can grant permission once to the group rather than
several times to each individual. Every user added to a security group receives the
permissions defined for that group.
When permission to perform an operation is not explicitly granted, it is implicitly denied. For
example, if Alice allows the Marketing group, and only the Marketing group, permission to read
her file, users who are not members of the Marketing group are implicitly denied access. The
operating system will not allow users who are not members of the Marketing group to read the
file.
Inherited Permissions
Some objects can contain other objects. For example, an NTFS folder object can contain file
objects and other folder objects. A registry key object can contain subkey objects. An Active
Directory organizational unit (OU) object can contain other OU objects as well as user objects,
group objects, and computer objects. Terminal objects contain Window Station objects that
contain Desktop objects that contain Window objects. Any object that is contained by another
object is called a child object. A child objects container is its parent object.
Child objects can inherit access control information from their parent object. For example,
suppose that the administrator for a server creates a file share with one folder, Public$. The
administrator creates this folder so that users can have a place to store information that they
want to share.

11
With this purpose in mind, the administrator sets the permissions, which are implemented as
ACEs, as shown in the following figure:
Figure 3. Permission Entries on Public Folder (Owner: Administrators)
None of the permissions that are listed in this figure were acquired through inheritance. This
is because the administrator cleared the Inherit from parent the permission entries that apply
to child objects check box. Clearing the check box sets the security descriptor control flag
SE_DACL_PROTECTED, which protects a child objects DACL by blocking inheritance from the
parent objects DACL.
Permissions that are acquired through inheritance are called inherited permissions.
Permissions that are not inherited, but are instead defined directly on an object, are called
explicit permissions. One way to tell an explicit permission from an inherited permission is to
select an entry in the Permission Entries list and read the text that is displayed after the list. In
this figure, the second entry is selected, and the text after the list says This permission is
defined directly on this object. In other words, the permission is explicit, not inherited.
The text in this figure also says This permission is inherited by child objects. Permissions on a
parent object that apply to child objects are called inheritable permissions. To see which of
the permissions that are set on a parent object are inheritable, examine the Apply to column
of Permission Entries. If Apply to says This object only (or, for folder objects, This folder only),
the permission is not inherited by child objects. Of the four permissions that are shown in
Figure 4, three are inheritable and one is not.
12
To see how inheritable permissions become inherited permissions, suppose that Alice creates
a subfolder in Public$. Alice is an engineer, so she names her folder Engineering Data.
Because this new object is a child of Public$, its DACL inherits permissions from the DACL on
Public$. The new objects permissions are shown in the following figure.
Figure 4. Permission Entries on Engineering Data Folder (Owner: Alice)
Note that Alice has not cleared the Inherit from parent the permission entries that apply to
child objects check box, so inheritable permissions in the parent objects DACL are inherited
by the child objects DACL. Inherited permissions are indicated in Permission Entries by a
disabled (unavailable) symbol at the beginning of each entry. The permission is still effective;
all that is disabled is the ability to modify the entry. Because inherited permissions are defined
on a parent object, they can be changed only by modifying the parent objects DACL.
Explicit Permissions
Even though inherited permissions cannot be changed, the owner of a child object can add
explicit permissions to the objects DACL. For example, suppose Alice decides that inherited
permissions that are given to Creator Owner are too restrictive because they allow only the
user who creates a file to make changes to the file. She wants all members of the Engineering
group to be able to edit and add information to the Engineering Data folder, so she explicitly
gives this group Modify permission for all objects in the folder. Alice also feels that people in
her companys marketing department will misuse information in Engineering Data, so she
decides to explicitly deny the Marketing group full control of (and therefore all access to) the
folder, subfolders, and files.
13
The results of Alices changes to the access control settings are shown in the following figure.
Figure 5. Modified Permission Entries on Engineering Data Folder
The list of permission entries in this figure now includes two explicit permissions, both with
enabled symbols indicating that the entries can be edited. Note that explicit permissions
appear at the top of the list. Permissions are listed in the order in which they will be processed
during an access check. Because explicit permissions are listed before inherited permissions,
they are processed first. The assumption is that the owner of a child object adds explicit
permissions in order to qualify inherited permissions. For example, in this figure, an inherited
permission allows Everyone to read the folder, subfolders, and files. Alice has added an
explicit permission that denies all access to a subset of the group Everyone the Marketing
group. The explicit deny entry is placed before any inherited entries; therefore, it is processed
before any inherited entries.
What is new in Windows 2000 and later is inheritance after the time of creation. New or
changed inheritable permissions in the DACL on a parent object are automatically propagated
to existing child objects every time the DACL on the parent object changes. If Alices folder
were on a system running Windows 2000 or later, the entry denying Marketing permission to
access the Engineering Data folder would be propagated to subfolders as soon as Alice
clicked Apply in the Advanced Security Settings dialog box.
Automatic propagation of inheritable permissions is a powerful capability because you can use
it to change permissions on an entire tree of objects by changing permissions on the top-level
object in the tree.
14
The owner of a parent object can choose to overwrite explicit permissions that are defined on
child objects. This is done by selecting the Replace permission entries on all child objects with
entries shown here that apply to child objects check box in the Advanced Security Settings
dialog box. When the owner of a parent object chooses this option, the propagation process
removes explicit permissions from the DACLs on all child objects. It also sets the option Inherit
from parent the permission entries that apply to child objects on all child objects, removing
any protection from inheritance that might have been set by the objects owners.
Active Directory Permissions

10
Now that the general concepts of security have been introduced, you will learn to apply them
to specific object types. Open the security page for any Active Directory object and you should
see the following standard object access rights or permissions:
Full Control
Has full control of the object.
Read
Can read the properties of the object.
Write
Can modify the properties of the object.
Create All Child Objects

This permission is necessary on the object type of the parent container. A security
principal, could, for example, have the right to create users, but not computers within a
given OU.
Delete All Child Objects

This permission is necessary on the object type of the parent container.
These standard permissions are fairly straightforward. One exception is the intended
functioning of Write when you attempt to modify several properties of the object and do not
have Write permission on all the properties. (For instance, the GUI might let you select
modifications to the address, home phone number and manager for user Bob even if you only
have Write permission for address and home phone number. In this case, however, none of
the properties will be changed.)
Exception to the Implicit/Explicit Permissions Rules with AD

Permissions
What do you think happens when a user or group has explicit Allow permission to delete All
Child Objects on a parent container, yet an ACE on a child object explicitly sets the Deny
Delete permission for the same user or group? Unlike NTFS permissions, in which the file
DACL overrides the parent folder DACL, certain parent-set permissions, such as Delete All
Child Objects and Delete Subtree, will override the child setting.

15
Overview of Delegation of Control

11
Delegation of administration is the transfer of administrative responsibility for a specific

administrative task from a higher authority to a lower authority. From an operational
perspective, delegation of administration involves a higher-level administrator conferring upon
a lower-level administrator the authority to carry out a specific administrative task. From a
technical perspective, delegation of administration involves a higher-level administrator
granting a controlled set of permissions to a lower-level administrator in order to carry out a
specific administrative task.
The Delegation of Control Wizard is the preferred method of setting up a delegation however;
most AD tools that can manipulate security permissions can be used (the result of delegation
is simply additional ACEs in the object DACL to control child object access).
Delegating control can be done on Containers, Objects or Attributes of objects though the
most commons scenarios are for delegation on Users, Groups, Computers and Organizational
Units.
Figure 6. The Delegation of Control Wizard
Registry Permissions
12
Just like permissions can be set on Active Directory objects, files, and folders, they can also be
set on registry keys using regedit.exe. Be very careful whenever making changing to
permissions on registry keys. To view the permissions set for keys and subkeys, use the
registry editor Regedit.exe. On the Edit menu, click Permissions.
16
NTFS Permissions and Share Permissions

13
Access on a shared folder is determined through two sets of permission entries; the
permissions set on the share (called share permissions) and the permissions set on the folder
(called NTFS file and folder permissions). Share permissions are often used for managing
computers with FAT32 file systems, or other computers that do not use the NTFS file system.
Share Permissions and NTFS Permissions are independent in the sense that neither changes
the other. The final access permissions on a shared folder are determined by taking into
consideration both the Share permission and the NTFS permission entries. The more
restrictive permissions are then applied.
NTFS permissions affect access both locally and remotely. NTFS permissions apply regardless
of protocol. Share permissions, by contrast, apply only to network shares. Share permissions
do not restrict access to any local user, or to any terminal server user, of the computer on
which you have set Share permissions. Thus, Share permissions do not provide privacy
between users on a computer used by several users, nor on a terminal server accessed by
several users.
Moving Versus Copying Files How it Affects Permissions

14
When you copy or move a file or folder on an NTFS volume, the manner in which Windows
Explorer handles the permissions on the object varies, depending on whether the object is
copied or moved within the same NTFS volume or to a different volume.
By default, an object inherits permissions from its parent object, either at the time of creation
or when it is copied or moved to its parent folder. The only exception to this rule occurs when
you move an object to a different folder on the same volume. In this case, the original
permissions are retained.
Additionally, note the following rules:
Note
The Everyone group is granted Allow Full Control permissions to the root of each NTFS
drive.
Deny permissions always take precedence over Allow permissions.
Explicit permissions take precedence over inherited permissions.
If NTFS permissions conflict -- for example, if group and user permissions are
contradictory -- the most liberal permissions take precedence.
Permissions are cumulative.
For more information, refer http://support.microsoft.com/default.aspx?scid=KB;ENUS;310316.

17
Resetting Permissions
15
The Reset permissions on all child objects and enable propagation of inheritable permissions
option is available for both file system object permissions, as well as for auditing. To reactivate ACL inheritance and remove all custom assigned access control entries for a
complete file system tree, perform the following tasks:
1. Open the Properties dialog box for the top-most object of the file system tree you want to
reset, and click the Security tab.
2. Click Advanced to display the Access Control Settings dialog box.
3. Select the Reset permissions on all child objects and enable propagation of inheritable
permissions check box to reset all subordinate file system objects. To reset audit
permission, a Reset auditing entries on all child objects and enable propagation of
inheritable auditing entries option exists under the Auditing tab.
4. A confirmation dialog box will present itself upon application of the new Access Control
setting, to ensure awareness that all subordinate, explicitly defined access control entries
will be destroyed by this action. Only inherited access control entries, and legacy access
control entries, (entries that left from a pre-upgrade installation of Microsoft Windows
NT), will remain on subordinate objects.
Note
For more information, refer http://support.microsoft.com/default.aspx?scid=KB;ENUS;223441.
Another way to reset security would be to use Security Configuration and Analysis using the
Windows interface:
1. Open Security Configuration and Analysis.
2. In the console tree, right-click Security Configuration and Analysis, and then click Open
Database.
3. In File name box, type the file name, and then click Open.
4. Do one of the following:
For a domain controller, in the console tree, right-click Security Configuration and
Analysis, click Import Template, and then click DC security.
For other computers, in the console tree, right-click Security Configuration and
Analysis, click Import Template, and then click setup security.
5. Select the Clear this database before importing check box, and then click Open.
6. In the console tree, right-click Security Configuration and Analysis, and then click
Configure Computer Now.
7. Do one of the following:
To use the default log specified in Error log file path, click OK.
To specify a different log, in Error log file path, type a valid path and file name, and
then click OK.
18
8. When the configuration is done, right-click Security Configuration and Analysis, and then
click View Log File.
Important
Applying the entire setup security template is a drastic measure that should be
avoided.
Implementing Security Policies

16
Security settings are grouped into seven areas:
Security Area Description
Account Policies Password Policies, Account Lockout Policies, and Kerberos Policies
Local Policies Audit Policy, User Rights Assignment, Security Options
Event Log Settings Application, System, and Security Event Log Settings
Restricted Groups Membership of security-sensitive groups
System Services Startup and permission for system services
Registry Permissions for registry keys
File System Permissions for folders and files
Administrators may define a security policy in Active Directory that contains specific security
settings for any and all security areas. This is accomplished by defining security settings in a
Group Policy object (GPO) that is associated with a domain or an organizational unit (OU).
Security settings that are defined for a domain or OU apply to all machines that are contained
in that domain or OU.
A security policy may also be established on the local machine. However, local machine
policies can only contain security settings for the first two security areas (Account Policies and
Local Policies). While all other security areas may be configured on a local machine through
the use of various tools, a local security policy may only be established for Account Policies
and Local Policies.
When there are conflicts, Security settings that are defined in Active Directory always override
any security settings that are defined on the local machine. Security settings for an OU always
override security settings defined in any parent OUs or on the domain itself. Thus, when
determining the security settings that apply to a specific machine, the order of precedence
may be represented as follows, from lowest to highest.
Local security policy
Domain policy
OU policy
OU policy (for the OU that the machine is contained in)
In the case of nested OUs, the child OU GPO takes precedence over a parent OU GPO.

19
User Right Assignments

17
Of the areas configured by security settings, most of these items have been discussed except
for User Rights Assignments and Audit policies.
A user right is authorization to perform an operation that affects an entire computer rather
than a specific object on the computer. User rights are divided into two categories: logon
rights and privileges. Logon rights control how human users and other security principals are
authorized to access a computerat the keyboard, through a network connection, as a
service, or as a batch job. Privileges control which users are authorized to manipulate system
resourcesby setting the computer's internal clock, for example, by loading and unloading
device drivers, by backing up or restoring files and folders, or by doing anything else that
affects the system as a whole.
Audit Policies
18
Audit Policy and User Rights are defined by default in the Default Domain Controller GPO,
which is associated with the Domain Controllers OU. As a result, all domain controllers have
the same Audit and User Rights policy. Thus, for example, to grant an individual the interactive
logon user right on a domain controller, the Default Domain Controller GPO should be
modified.
Using Security Templates

19
Importing a security template to a Group Policy object ensures that any accounts to which the
GPO is applied automatically receive the templates security settings when the Group Policy
settings are refreshed. On a workstation or server, the security settings are refreshed every 90
minutes, and on a domain controller, this process occurs every 5 minutes if changes have
occurred in any of the GPO settings that apply. Because DCs refresh policy every 5 minutes, it
is typically advised not to use security templates in GPOs that have extensive file system
security settings. The settings are also refreshed every 16 hours, whether or not any changes
have occurred.
The predefined security templates are provided as a starting point for creating security
policies that are customized to meet different organizational requirements. You can customize
the templates with the Security Templates snap-in. Once you customize the predefined
security templates, you can use them to configure security on an individual computer or
thousands of computers. You can configure individual computers with the Security
Configuration and Analysis snap-in, the Secedit command-line tool, or by importing the
template into Local Security Policy. You can configure multiple machines by importing a
template into Security Settings extension to Group Policy, which is an extension to Group
Policy. You can also use a security template as a baseline for analyzing a system for potential
security holes or policy violations by using the Security Configuration and Analysis snap-in. By
default, the predefined security templates are stored in systemroot\Security\Templates.
20
Some rules to apply when using security templates:
Do not apply predefined or newly-created security templates to your computer or network

without testing to ensure that the right level of application functionality is maintained.
Never edit the Setup security.inf template, since it gives you the option to reapply the
default security settings. If you ever remove a security template from a Group Policy
object, appropriately reapply the Setup security.inf to restore all default settings.
Do not apply the Setup security.inf template through Group Policy. The Setup security.inf
template should only be applied to the local computer through Secedit or Security
Configuration and Analysis. It is preferable to apply it in parts using the Secedit
command-line tool.
Instead of modifying a predefined template, customize the predefined template and then
save the changes under a different template name. Since these templates were designed
for specific needs, having the original template will always give you the option of using it.
When deciding on the default level of computer access that end users will have, the
determining factor is the installed base of applications that need to be supported. If
users only use applications that belong to the Windows Logo Program for Software, then
you can make all your end users members of the Users group. If not, you may have to
make your end users part of the Power users group so that they have the appropriate
privileges to use the application, which is less secure.
Using Secedit - Secedit.exe

20
You can use the secedit.exe command to configure and analyze system security by comparing
your current configuration to at least one template.
Secedit supports the following commands:
analyze
This command allows you to analyze the security settings on a computer by comparing
them against the baseline settings in a database. You can view the results of the analysis
in the Security Configuration and Analysis snap-in.
configure
You can use secedit /configure to configure local computer security by applying the
settings stored in a database.
export
Running secedit /export allows you to export the security settings stored in the database.
import
Running secedit /import allows you to import a security template into a database so that
the settings specified in the template can be applied to a system or analyzed against a
system.
validate
You can use secedit /validate to validate the syntax of a security template to be imported
into a database for analysis or application to a system.

21
generateRollback
You can run secedit / GenerateRollback to generate a rollback template with respect to a
configuration template. When applying a configuration template to a computer you have
the option of creating rollback template which, when applied, resets the security settings
to the values before the configuration template was applied.
Using Security and Configuration Manager

21
Security Configuration and Analysis can also be used to directly configure local system
security. Through its use of personal databases, you can import security templates that have
been created with Security Templates and apply these templates to the local computer. This
immediately configures the system security with the levels specified in the template.
Only use Security Configuration and Analysis to configure security areas not affected by Group
Policy settings. This includes areas such as security on local files and folders, registry keys,
and system services. Otherwise, Group Policy settings will override the local settings.
Do not use Security Configuration and Analysis when you are configuring security for a domain
or an organizational unit. Otherwise, you must configure each client individually. In that case,
you can:
Use Security Templates to create a template and apply it to the appropriate Group Policy
object.
Use the Security Settings extension to Group Policy to edit individual security settings on
a Group Policy object.
Using Utilities to Troubleshoot Security Problems

22
There are many utilities that are available to troubleshoot security problems. You may need to
choose your tool based upon the object that has the security settings applied. Also, you may
need to determine the groups the user account is a member of.
Using Xcopy
Xcopy is a command-line tools that copies files and directories, including subdirectories. It
comes with the Windows 2000 and Windows Server 2003.
Syntax:
xcopy Source [Destination] [/w] [/p] [/c] [/v] [/q] [/f] [/l] [/g] [/d[:MM-DD-YYYY]] [/u] [/i] [/s
[/e]] [/t] [/k] [/r] [/h] [{/a | /m}] [/n] [/o] [/x]
[/exclude:FileName1[+[FileName2]][+[FileName3]] [{/y | /-y}] [/z]
Parameters:
Source
Required. Specifies the location and names of the files you want to copy. This parameter
must include either a drive or a path.
Destination
Specifies the destination of the files you want to copy. This parameter can include a drive
letter and colon, a directory name, a file name, or a combination of these. The switches
can be listed with a short description by typing xcopy /?.
22
Some that are important to this discussion are:
/o
Copies file ownership and discretionary access control list (DACL) information.
/x
Copies file audit settings and system access control list (SACL) information (implies
/o).
Using Dsacls
This command-line tool included in the Windows 2000 and Windows Server 2003 Support
Tools displays and changes permissions (access control entries) in the access control list The
ACEs that you add by using Dsacls must be object-specific permissions that override the
default permissions defined in the Active Directory schema for that object type. DSACLS can
also be used to reset the permissions on objects to what they are defined as in the Schema.
The following article is available for Dsacls is 281146 How to Use Dsacls.exe in Windows
2000.
Note
The ACEs that you add by using DsAcls must be object-specific permissions that override
the default permissions defined in the Active Directory schema for that object type. Do
not add ACEs unless you are well-informed about security for Active Directory objects.
The following are the system requirements for Dsacls:
DsAcls runs on Windows 2000, Windows XP Professional, and Windows Server 2003.
To view an ACL, the user must have read permissions on Active Directory objects. To
change an ACL, the user must have write permissions to the Active Directory object.
Using Subinacl
Suninacl comes with the Resource Kit. SubInACL is a command-line tool that enables
administrators to obtain security information about files, registry keys, and services, and
transfer this information from user to user, from local or global group to group, and from
domain to domain. For example, if a user has moved from one domain (DomainA) to another
(DomainB), the administrator can replace DomainA\User with DomainB\User in the security
information for the user's files. This gives the user access to the same files from the new
domain.
SubInACL enables administrators to do the following:
Display security information associated with files, registry keys, or services. This
information includes owner, group, permission access control list (ACL), discretionary ACL
(DACL), and system ACL (SACL).
Change the owner of an object.
Replace the security information for one identifier (account, group, well-known security
identifier (SID)) with that of another identifier.
Migrate security information about objects. This is useful if you have reorganized a
network's domains and need to migrate the security information for files from one
domain to another.
Supported Operating Systems: Windows 2000, Windows Server 2003, Windows XP

23
Using TokenGroups.vbs
The tools discussed so far, help you determine the permissions on an object. TokenGroups
queries a GC to gather full group membership. Because it queries a GC, it will get Universal
group membership. This tool is available on http://toolbox.
Run regsvr32 <path to ads.dll> to register the dll on the machine from which the script is
being initiated.
Run the following command from the command prompt (the whole line, quotes and all):
cscript tokengroups.vbs "CN=User name,CN=Users,DC=domain,DC=com" >
<filename>.txt
Note
Quotes are needed around the "DN" if there are spaces in the name.
Using ADtoken
ADtoken can be used to dump information concerning a user account, such as group
membership. At times, group information is need when troubleshooting security issues.
Usage:
adtoken [options]
/all
= All Sections
/verbose
= Extra Information for some sections
/sidhist
= SIDHistory
/domains
= Trusted Domains (Verbose Info)
/dc
= DC Info (Verbose Info)
/site
= Site Information (Verbose Info)
/fsmo
= FSMO Information (Verbose Info)
/kerb
= Kerberos Information (Verbose Info)
/lsa
= LSA Information (Verbose Info)
/cred
= Credential Manager Info (Verbose Info) XP Only
/everytoken = All Machine Tokens (Verbose)
with /everytoken [/pid:PID] [/user:Username]
Troubleshooting Security Problems

23
When troubleshooting security problems, you will first need to determine the objects involved,
files, folders, Active Directory objects, etc, and what is the end result the customer wants?
Questions you might want to ask include:
Are users able to access an object that they should not?
What groups do the users belong to?
Where are the user accounts located?
Where are the resources the users are accessing located?
24
Auditing
24
Establishing audit policy is an important facet of security. Monitoring the creation or

modification of objects gives you a way to track potential security problems, helps to ensure
user accountability, and provides evidence in the event of a security breach.
The most common types of events to be audited are:
Access to objects, such as files and folders.
Management of user accounts and group accounts.
Users logging on to and logging off from the system.
When you implement the audit policy:
Specify the categories of events that you want to audit.
Set the size and behavior of the security log. It is important that you set the size of the
security log appropriately. Because the security log is limited in size, choose which events
you audit carefully. Also, consider the amount of disk space that you are willing to devote
to the security log. The maximum amount is defined in Event Viewer.
If you want to audit directory service access or object access, determine which objects
you want to monitor access of and what type of access you want to monitor.
Note
Auditing may effect system performance and its not generally recommended to leave
object access auditing enabled on a permanent basis but actually to disable auditing
after troubleshooting is completed.
Each object has a set of security information, or security descriptor, attached to it. Part of the
security descriptor specifies the groups or users that can access an object and the types of
access (permissions) that are granted to those groups or users. This part of the security
descriptor is known as a discretionary access control list (DACL).
A security descriptor for an object also contains auditing information. This auditing information
is known as a system access control list (SACL). More specifically, a SACL specifies the
following:
The group or user accounts to audit when they access the object.
The operations to be audited for each group or user, for example, modifying a file.
A Success or Failure attribute for each access event, based on the permissions that are
granted to each group and user in the object's DACL..
You can apply auditing to an object, and, through inheritance, the auditing can apply to any
child objects. An excellent article about applying auditing is
http://support.microsoft.com/default.aspx?scid=KB;EN-US;324739

25
Common Problems with Security

25
Common issues with security typically start with a client not having access to a resource that
he should, or a client having access to a resource that he should not. It can be difficult to
determine the token that is actually built on a remote machine for a specific user. To analyze
what that token contains, have that remote user logon to the remote target machine and
analyze the token. This may help determine the source of the problem if the issue deals with
token size, kerberos or user rights.
How to Resolve Common Security Problems

26
Typically, these problems can be traced back to group membership and or permission
interaction, NTFS permissions versus share permissions, or inherited permissions versus
explicit permissions. In order to confirm it is security permissions, create a new shared folder
and set permissions to everyone full control for both share and NTFS permissions. Also, gather
information about the users token using ADtoken.exe. Most of these issues come down to
comparing the token information to the users and groups listed in the security descriptor for
the object being accessed.
If NTFS permissions and share permissions are involved, a good rule of thumb is to manage
folder access by using NTFS permissions exclusively, set Share permissions to Full Control for
Everyone. This frees you from having to think about Share permissions, but NTFS permissions
are more complex than Share permissions, so using NTFS permissions correctly requires
deeper understanding on your part. Also, take share permissions out of the picture by having
the user try to access the resource locally, if possible.
In the situation with inherited permissions versus explicit permissions, things can get very
complex. It is best to start by having the customer dump the permissions on the object and
the users group membership. Remember explicit permissions always take precedence over
inherited permissions. Inherited Deny permissions do not prevent access to an object if the
object has an explicit Allow permission entry.
If you suspect a security template has been applied at the domain level, you can view the
gpttmpl.inf in the Default Domain Policy to determine what changes have been made. To reset
this file at the domain level back to the original values, follow
http://support.microsoft.com/default.aspx?scid=KB;EN-US;226243.
If you suspect a security template has been applied at the domain controller OU level, you can
view the gpttmpl.inf in the Default Domain Controller Policy to determine what changes have
been made. To reset this file at the domain controller level back to the original values, follow
Examining Security Changes

27
The Anonymous Logon group is no longer a member of the Everyone group. This change will
impact anonymous users attempting to access resources hosted on computers running
Windows XP Professional and members of the Windows Server 2003 family.
26
Anyone who accesses a computer and its resources through the network without an account
name, password, or domain is a member of the Anonymous Logon built-in security group. In
previous versions of Windows, members of the Anonymous Logon security group had access
to many resources, due to membership of the Everyone group. Because Administrators did not
realize that anonymous users were members of the Everyone group they might have
inadvertently granted them access to resources only intended for authenticated users.
When a computer running Windows 2000 is upgraded to a member of the Windows Server
2003 family, resources with permission entries for the Everyone group (and not explicitly to
the Anonymous Logon group) will no longer be available to anonymous users after the
upgrade. In most cases, this is an appropriate restriction on anonymous access. You may
need to permit anonymous access in order to support pre-existing applications that require it.
If you need to grant access to the Anonymous logon group, you should explicitly add the
Anonymous Logon security group and its permissions.
However, in some situations where it might be difficult to determine and modify the
permission entries on resources hosted on Windows Server 2003 family or Windows XP
Professional computers you can change the security setting, Network access: Let Everyone
permissions apply to anonymous users.
New User Rights/Privileges

Windows Server 2003 and Windows 2000 SP4 introduces two new User Rights,
seImpersonatePrivilege (Impersonate a Client after Logon) and seCreateGlobalPrivilege
(Create Global Objects).
When you assign the Impersonate a client after authentication user right to a user, you permit
programs that run on behalf of that user to impersonate a client. This security setting helps to
prevent unauthorized servers from impersonating clients that connect to it through methods
such as remote procedure calls (RPC) or named pipes.
The Create global objects user right (seCreateGlobalPrivilege) is a user right that is required
for a user to create global objects in a Terminal Services session. Note that users can still
create session-specific objects without being assigned this user right. By default, members of
the Administrators group, the System account, and Services that are started by the Service
Control Manager are assigned the Create global objects user right.
LAB 1: Troubleshooting Security Problems

28
During this lab session, you will:
Use the Authentication troubleshooting tools to troubleshoot Security problems.
Review the understanding of the concepts presented in this module.
Delegate Control Wizard and troubleshoot Active Directory access.
Install the Remote Administration tools.
Refer to the accompanying Lab Manual to complete the practice exercises.

27
Resources
29
The following Microsoft Knowledge Base articles provide additional information:
Appendix A: Privileges and Logon Rights
Summary
30
Topics discussed in this session include the:
Basic concepts related to Security.
Resetting permissions.
Utilities used to implement and troubleshoot security policies.
Troubleshooting common problems with security.
Security changes from Windows NT 4.0 to Windows Server 2003.
28

Trust technology is the foundation for the security architecture in Microsoft Windows 2000
and Windows Server 2003 networks using the Active Directory service. Trusts enable network
administrators to implement an authentication and authorization strategy for sharing
resources across domains or forests and provide a mechanism for centralizing management
of multiple domains and forests.
Before You Begin

1
Before starting this session, you should:
Understand the concepts of domains and forests.
Understand the Operations Master roles.
Understand the dependency that active directory has on DNS.
What You Will Learn

2
Review and create trust relationship between same and different OS platforms.
Explain how to use different utilities to troubleshoot trust relationship problems.
Explain how to troubleshoot common problems with trusts.
Reviewing Trusts
3
Active Directory provides security across multiple domains through interdomain trust
relationships. When there are trust relationships between domains, the authentication
mechanism for each domain trusts the authentication mechanism for all other trusted
domains. If a user or application is authenticated by one domain, its authentication is
accepted by all other domains that trust the authenticating domain. Users in a trusted domain
have access to resources in the trusting domain, subject to the access controls that are
applied in the trusting domain.

29
Why the Need for Trust Relationships?

4
Most organizations that have more than one domain have a legitimate need for users to
access shared resources located in a different domain. Controlling this access requires that
users in one domain can also be authenticated and authorized to use resources in another
domain. To provide authentication and authorization capabilities between clients and servers
in different domains, there must be a trust between the two domains. Trusts are the
underlying technology by which secured Active Directory communications occur.
When a trust exists between two domains, the authentication mechanisms for each domain
trust the authentications coming from the other domain. Trusts help to provide controlled
access to shared resources in a resource domain (the trusting domain) by verifying that
incoming authentication requests come from a trusted authority (the trusted domain). In this
way, trusts act as bridges that allow only validated authentication requests to travel between
domains.
How a specific trust passes authentication requests depends on how it is configured. Trust
relationships can be one-way, providing access from the trusted domain to resources in the
trusting domain, or two-way, providing access from each domain to resources in the other
domain. Trusts are also either nontransitive, in which case a trust exists only between the two
trust partner domains, or transitive, in which case a trust automatically extends to any other
domains that either of the partners trusts.
In some cases, trust relationships are established automatically when domains are created; in
other cases, administrators must choose a type of trust and explicitly establish the
appropriate relationships. The specific types of trusts that are used and the structure of the
resulting trust relationships in a given trust implementation depend on such factors as how
Active Directory is organized and whether different versions of Windows coexist on the
network.
Types of Trusts
5
Communication between domains occurs through trusts. Trusts are authentication pipelines
that must be present in order for users in one domain to access resources in another domain.
Two default trusts are created when using the Active Directory Installation Wizard. There are
four other types of trusts that can be created using the New Trust Wizard or the Netdom
command-line tool.
Default Trusts
6
By default, two-way, transitive trusts are automatically created when a new domain is added
to a domain tree or forest root domain using the Active Directory Installation Wizard. The two
default trust types are defined in Table 4.
30
Table 4. Default Trusts
Trust Type
Transitivity
Direction
Description
Parent and child
Transitive
Two-way
By default, when a new child domain is

added to an existing domain tree, a new
parent and child trust is established.
Authentication requests made from
subordinate domains flow upward through
their parent to the trusting domain.
Tree-root
Transitive
Two-way
By default, when a new domain tree is

created in an existing forest, a new tree-root
trust is established.
Other Trusts
7
Four other types of trusts can be created using the New Trust Wizard of Windows Server 2003
or the Netdom command-line tool: external, realm, forest, and shortcut trusts. These trusts are
defined in the following table:
Table 5. Other Trusts
Trust Type
Transitivity
Direction
Description
External
Nontransitive
One-way or
two-way
Use external trusts to provide access to

resources located on a Windows NT 4.0
domain or a domain located in a separate
forest that is not joined by a forest trust.
Realm
Transitive or
nontransitive
One-way or
two-way
Use realm trusts to form a trust

relationship between a non-Windows
Kerberos realm and a Windows Server
2003 domain.
Forest
Transitive
One-way or
two-way
Use forest trusts to share resources

between forests. If a forest trust is a twoway trust, authentication requests made in
either forest can reach the other forest.
Shortcut
Transitive
One-way or
two-way
Use shortcut trusts to improve user logon

times between two domains within a
Windows 2000 or Windows Server 2003
forest. This is useful when two domains are
separated by two domain trees.
When creating external, shortcut, realm, or forest trusts, you have the option to create each
side of the trust separately or both sides of a trust simultaneously.
If you choose to create each side of the trust separately, then you will need to run the New
Trust Wizard twice--once for each domain. When creating trusts using the method, you will
need to supply the same trust password for each domain. As a security best practice, all trust
passwords should be strong passwords.

31
If you choose to create both sides of the trust simultaneously, you will need to run the New
Trust Wizard once. When you choose this option, a strong trust password is automatically
generated for you.
You will need the appropriate administrative credentials for each domain between which you
will be creating a trust. Netdom.exe can also be used to create trusts.
Secure Channels
8
In the Windows 2000/2003 distributed security model, every domain member has a direct
trust path to a domain controller in the domain in which the computer account is located. The
trust path is implemented by the Net Logon service through an authenticated remote
procedure call (RPC) connection to the trusted domain authority namely, the domain
controller. In addition, domain controllers setup a secure channel to other Windows
2000/2003 domain controllers in trusted domains. The secure channel is used to provide
authentication, obtain and verify security information, including security identifiers (SIDs) for
users and groups.
The direct trust path between the domain members and the domain controllers is known as a
secure channel. Secure channels are used to authenticate domain member computer
accounts and to authenticate user accounts when a remote user connects to a network
resource and the user account exists in a trusted domain (pass-through authentication). A
secure channel must exist in order for account authentication to be performed. It is used by
the Netlogon service on the client and on the domain controller to communicate with each
other.
Secure channels are not stagnant. Netlogon routinely checks the status and responsiveness
of the secure channel. If the secure channel partner does not meet certain criteria, Netlogon
attempts to find a new secure channel partner. Netlogon is also responsible for changing the
machine account password and trust account password.
By default, a machine account password is reset every 30 days, in Windows NT 4.0 this was
every 7 days. The client sends the request to a domain controller. If the response from the
domain controller is not access denied or refusepasswordchange, the Netlogon service
considers the password change successful. On the domain controller, this password is stored
in active directory with the computer account and replicated to all domain controllers in the
domain. On the client, Netlogon remembers the last password as well as the new password for
they are stored in LSA. If the machine account is not validated when it is setting up a secure
channel using the new password, Netlogon attempts to use the old password, and if
successful, uses only the old password from this point on.
Authentication Protocols
9
Active Directory domain controllers authenticate users and applications by using one of two
protocols: either the Kerberos version 5 authentication protocol or the NTLM authentication
protocol. When two Active Directory domains or forests are connected by a trust,
authentication requests made using these protocols can be routed to provide access to
resources in both forests.
32
NTLM
10
The NTLM protocol is the default protocol used for network authentication in the Windows NT
4.0 operating system. For compatibility reasons, it is used by Active Directory domains to
process network authentication requests that come from earlier Windows-based clients and
servers. Computers running Windows 2000, Windows XP or Windows Server 2003 use NTLM
only when authenticating to servers running Windows NT 4.0 and when accessing resources in
Windows NT 4.0 domains.
When the NTLM protocol is used between a client and a server, the server must contact a
domain authentication service on a domain controller to verify the client credentials. The
server authenticates the client by forwarding the client credentials to a domain controller in
the client account domain. The authentication protocol of choice for Active Directory
authentication requests, when there is a choice, is Kerberos version 5. When the Kerberos
protocol is used, the server does not have to contact the domain controller. Instead, the client
gets a ticket for a server by requesting one from a domain controller in the server account
domain; the server validates the ticket without consulting any other authority.
Kerberos Version 5 Protocol

11
The Kerberos version 5 protocol is the default authentication protocol used by computers
running Windows 2000, Windows XP Professional, or Windows Server 2003. This protocol is
specified in RFC 1510 and is fully integrated with Active Directory, server message block
(SMB), HTTP, and remote procedure call (RPC), as well as the client and server applications
that use these protocols. In Active Directory domains, the Kerberos protocol is used to
authenticate logons when any of the following conditions is true:
The user who is logging on uses a security account in an Active Directory domain.
The computer that is being logged on to is a Windows 2000, Windows XP or Windows

Server 2003based computer.
The computer that is being logged on to is joined to an Active Directory domain.
The computer account and the user account are in the same forest.
The computer from which the user is trying to access resources is located in a nonWindows Kerberos realm.
If any computer involved in a transaction does not support the Kerberos version 5 protocol,
the NTLM protocol is used.

33
Trusted Domain Object

12
Each domain or forest trust within an organization is represented by a Trusted Domain Object
(TDO) stored in the System container within its domain.
The information contained in a TDO can vary depending on whether a TDO was created by a
domain trust or by a forest trust. When a domain trust is created, attributes such as the DNS
domain name, domain SID, trust type, trust transitivity, and the reciprocal domain name are
represented in the TDO. Forest trust TDOs store additional attributes to identify all of the
trusted namespaces from the partner forest. These attributes include domain tree names,
user principal name (UPN) suffixes, service principal name (SPN) suffixes, and security ID (SID)
namespaces. External trusts to a Windows NT 4.0 domain do not create TDOs in Active
Directory.
Both domains in a trust relationship share a password, which is stored in the TDO object in
Active Directory. As part of the account maintenance process, every seven days, the trusting
domain controller changes the password stored in the TDO. Because all two-way trusts are
actually two one-way trusts going in opposite directions, the process occurs twice for two-way
trusts.
To change a password, domain controllers in domains on each side of the trust complete the
following process:
1. The primary domain controller (PDC) emulator in the trusting domain creates a new
password.
2. A domain controller in the trusted domain never initiates the password change; the
trusting domain PDC emulator always initiates it.
3. The domain controller in the trusting domain sets the OldPassword field of the TDO object
to the previous NewPassword field.
4. The domain controller in the trusting domain sets the NewPassword field of the TDO
object to the new password.
5. Keeping a copy of the previous password makes it possible to revert to the old password
if the domain controller in the trusted domain fails to receive the change or if the change
is not replicated before a request is made that uses the new trust password.
6. The domain controller in the trusting domain makes remote call to a domain controller in
the trusted domain asking it to set the password on the trust account to the new
password.
7. The domain controller in the trusted domain changes the trust password to the new
password.
The password is now changed on both domain controllers. Normal replication distributes the
TDO objects to the other domain controllers in the domain. However, is possible for the
domain controller in the trusting domain to change the password without successfully
updating a domain controller in the trusted domain. This might occur because a secured
channel, which is required to process the password change, could not be established. It is also
possible that the domain controller in the trusted domain might be unavailable at some point
during the process and might not receive the updated password.
To deal with situations in which the password change is not successfully communicated, the
domain controller in the trusting domain never changes the new password unless it has
successfully authenticated (set up a secured channel) using the new password.
34
Different data about the trust relationship is kept in several key attributes of each
trustedDomain object. The following are the key attributes:
flatName
Contains the NetBIOS name of the domain for this trust relationship.
trustDirection
Contains the direction of the established trust relationship:
0=Disabled
1=Inbound (Trusting domain)
2=Outbound (Trusted domain)
3=Both (Trusted and trusting domains)
trustPartner
Contains a string that represents the DNS-style name of the domain if it is a Windows
2000 domain or the NetBIOS name of the domain if it is trust relationship between a
Windows 2000 domain and a non-Windows 2000 domain.
trustType
Contains the type of trust relationship that has been established to the domain.
1=A trust relationship between a Windows 2000 domain and a Windows NT 4.0 or
earlier domain.
2=A Windows 2000 trust relationship.
3=A trust relationship between a Windows 2000 domain and a non-Windows

Kerberos realm.
Creating Trust Relationships

13
It is necessary to manage domain and forest trusts when your organization needs to
collaborate with users or resources that are located in other domains, realms, or forests in
your organization and in other organizations. To set up an environment that takes advantage
of trusts, you must first create and configure the appropriate trusts that will enable your
organization to communicate effectively with users or resources in other places.
Note
A trust does not inherently allow users in a trusted domain to have access to resources in
a trusting domain. Users have access when they are assigned the appropriate
permissions. In some cases, users in trusted domains may have implicit access if the
resources are assigned to Authenticated Users.

35
Requirements for Creating Trusts

14
You cannot delegate the creation of trusts to any user who is not a member of the Domain
Admins or Enterprise Admins groups. Even though you can grant a user the Create TDO
(Trusted Domain Object) right or the Delete TDO right in the System container of a domain, the
user will not be granted the right to create a trust. This issue occurs because Netlogon and the
trust-creation tools (Active Directory Domains and Trusts and Netdom) are designed so that
only members of the Domain Admins group and the Enterprise Admins group can create
trusts.
How to Create Trust Relationships between Windows Server

2003 or Windows 2000 and Windows NT 4.0
15
To successfully create a trust with a Windows NT 4.0 domain, there needs to exist a means for
name resolution. Windows NT 4.0 uses WINs or LMHosts files for NETBios name resolution.
For the Windows 2000/2003 domain controller to contact the Windows NT 4.0 PDC, there will
need to exist a means of name resolution in that directions. Typically, a LMHosts file on both
the PDC and the Windows 2000 PDC emulator is the quickest way to address this issue.
You can manually create a one-way or two-way external trust between Windows Server 2003
or Windows 2000 domains and Windows NT 4.0 domains so that users from either domain
can be authenticated to access resources in the other domain.
Figure 7. External Trust Between a Windows NT 4.0 Domain and a Windows Server 2003 Forest Child Domain
This configuration allows users in the europe.corp.tailspintoys.com domain to access

resources in the Windows NT 4.0 domain. It does not allow the Windows NT 4.0 domain to
access resources in the europe.corp.tailspintoys.com domain or for any trusted domains that
the europe.corp.tailspintoys.com domain trusts.
36
By default, new external and forest trusts in Windows Server 2003 Active Directory enforce
SID filtering. Applying SID filtering to external and forest trusts helps to prevent malicious
users who have domain administrator level access in the trusted domain from granting to
themselves, or other user accounts in their domain, elevated user rights to the trusting
domain.

2003 and Windows 2000
16
An external trust is a trust relationship that can be created between Active Directory domains
that are in different forests or between an Active Directory domain and a Windows NT 4.0 or
earlier domain. An external trust relationship has the following characteristics:
It is nontransitive.
It must be established manually in each direction to create a two-way external trust

relationship. In Windows Server 2003, you can create both sides of the external two-way
trust at once by using the New Trust Wizard.
It enforces SID filtering by default in Windows Server 2003. External trusts created from
the trusting domain use SID filtering to verify that incoming authentication requests made
from security principals in the trusted domain contain only SIDs of security principals in
the trusted domain. SID filtering ensures that any misuse of the SIDHistory attribute on
security principals (including inetOrgPerson) in the trusted forest cannot pose a threat to
the integrity of the trusting forest.
External trusts provide access to resources in a domain outside of the forest that is not
already joined by a forest trust. The following illustration shows how external trusts can be
used between a Windows Server 2003 forest and a Windows 2000 forest.
Figure 8. External trusts Between a Windows Server 2003 Forest and a Windows 2000 Forest

37
In this example, two external trust relationships exist between domains in the Windows Server
2003 forest and the Windows 2000 forest. The direction of the one-way external trust arrow
indicates that the sales.corp.worldwideimporters.com domain trusts the
rome.europe.corp.tailspintoys.com domain, which means that users in the
rome.europe.corp.tailspintoys.com domain can access resources in the
sales.corp.worldwideimporters.com domain.
The direction of the two-way external trust arrow indicates that both the
europe.corp.tailspintoys.com domain and the sales.corp.worldwideimporters.com domain
trust each other. This relationship allows authentication requests to be passed between the
two domains, coming from either direction, to any shared resources in those two domains.
This configuration allows:
Users in the europe.corp.tailspintoys.com domain to access resources in the

sales.corp.worldwideimporters.com domain
Users in the sales.corp.worldwideimporters.com domain to access resources in the

europe.corp.tailspintoys.com domain
Users in the rome.europe.corp.tailspintoys.com domain to access resources in the

sales.corp.worldwideimporters.com domain
It does not allow:
Users in the rome.europe.corp.tailspintoys.com domain or europe.corp.tailspintoys.com

domain to access resources in the corp.worldwideimporters.com domain
Users in the sales.corp.worldwideimporters.com domain to access resources in either the

corp.tailspintoys.com or rome.europe.corp.tailspintoys.com domain
When a trust is established between a domain in a forest and a domain outside of that forest,
security principals from the external domain can access resources in the internal domain.
Active Directory creates a foreign security principal object in the internal domain to represent
each security principal from the trusted external domain. These foreign security principals can
become members of domain local groups in the internal domain. Directory objects for foreign
security principals are created by Active Directory and should not be manually modified. You
can view foreign security principal objects from Active Directory Users and Computers by
enabling advanced features.

2003 and Windows Server 2003
17
It is possible to extend the transitivity of domain trusts within a single Windows Server 2003
forest to another Windows Server 2003 forest by manually creating a one-way or two-way
forest trust. A forest trust is a transitive trust between a forest root domain and a second
forest root domain. A one-way forest trust allows all users in one forest to trust all domains in
the other forest; a two-way forest trust forms a transitive trust relationship between every
domain in both forests. The transitivity of forest trusts is limited to the two forest partners; the
forest trust does not extend to additional forests trusted by either of the partners.
38
A forest trust can be created only between a forest root domain in one Windows Server 2003
forest and a forest root domain in another Windows Server 2003 forest. Forest trusts can be
created between two forests only and cannot be implicitly extended to a third forest. This
means that if a forest trust is created between Forest 1 and Forest 2, and another forest trust
is created between Forest 2 and Forest 3, Forest 1 does not have an implicit trust with Forest
3. The following figure shows two separate forest trust relationships between three Windows
Server 2003 forests in a single organization.
Figure 9. Two Forest Trusts Between Three Windows Server 2003 Forests
In this example, a two-way transitive forest trust exists between the forest root domains in
Forest 1 and Forest 2, and another two-way transitive forest trust exists between the forest
root domains in Forest 3 and Forest 2.
This configuration allows:
Users in Forest 2 to access resources in any domain in either Forest 1 or Forest 3
Users in Forest 3 to access resources in any domain in Forest 2
Users in Forest 1 to access resources in any domain in Forest 2
This configuration does not allow users in Forest 1 to access resources in Forest 3 or vice
versa. To allow users in both Forest 1 and Forest 3 to share resources, a two-way transitive
trust must be created between the two forests.
If a one-way forest trust is created between two forests, members of the trusted forest can
utilize resources located in the trusting forest. However, the trust operates in only one
direction. For example, when a one-way, forest trust is created between Forest 1 (the trusted
forest) and Forest 2 (the trusting forest), members of Forest 1 can access resources located in
Forest 2, but members of Forest 2 cannot access resources located in Forest 1 using the
same trust.
There are specific requirements that must be met for using forest trusts. Before you can
create a forest trust, you need to verify that all domain controllers in both forests are running
Windows Server 2003. You also need to verify that you have the correct Domain Name System
(DNS) infrastructure in place and that you have established the appropriate functionality level
for Active Directory. This means that the forest must be raised to the Windows Server 2003
functional level and that you cannot install additional Windows 2000 or Windows NT Server
4.0 domain controllers in the forest.

39
Forest trusts can only be created when one of the following DNS configurations is in place in
your infrastructure:
A single root DNS server is the root DNS server for both forest DNS namespaces: the root
zone contains delegations for each of the DNS namespaces and the root hints of all DNS
servers include the root DNS server.
Where there is no shared root DNS server and the root DNS servers for each forest DNS
namespace are running a member of the Windows Server 2003 family, DNS conditional
forwarders are configured in each DNS namespace to route queries for names in the
other namespace.
Where there is no shared root DNS server and the root DNS servers for each forest DNS
namespace are not running a member of the Windows Server 2003 family, DNS
secondary zones are configured in each DNS namespace to route queries for names in
the other namespace.
Using Utilities to Troubleshoot Trust Relationships

Problems
18
Most problems with trusts come back to communication issues or permission issues between
the domains. Communication issues can be traced many times to name resolution issues, and
connectivity issues. The tools below can be used to help determine the root cause for the
issue. Once root cause is determined, then it can be corrected to allow the trust to be
established.
Using PortQuery
19
This command-line tool reports the status of TCP and UDP ports on a target computer. PortQry
is used to troubleshoot TCP/IP connectivity issues. It provides an additional level of detail on
port status not provided by other port scanning tools. You can use PortQry to query a single
port, an ordered list of ports, or a sequential range of ports.
Note
PortQry is a troubleshooting tool, not a security assessment tool.
Table 6. Ports Required for Trusts
Task
Outbound Ports
Set up trusts on
both sides from
the internal forest
LDAP (389 UDP and TCP) N/A

Microsoft SMB (445 TCP)
Kerberos (88 UDP)
Endpoint resolution
portmapper (135 TCP) Net
Logon fixed port
40
Inbound Ports
FromTo
Internal domain domain
controllersExternal
domain domain controllers
(all ports)
Task
Outbound Ports
Inbound Ports
Trust validation
from the internal
forest domain
controller to the
external forest
domain controller
(outgoing trust
only)
LDAP (389 UDP)

N/A
Endpoint resolution
Logon fixed port
Internal domain domain

controllersExternal
(all ports)
Use Object picker

on the external
forest to add
objects that are in
an internal forest
to groups and
DACLs
N/A
LDAP (389 UDP and

TCP)
Windows NT Server
4.0 directory service
fixed port
Net Logon fixed port
Kerberos (88 UDP)
Endpoint resolution
portmapper (135
TCP)
External serverInternal
domain PDCs (Kerberos)
External domain domain
controllersInternal
(Net Logon)
Set up trust on the

external forest
from the external
forest
N/A
LDAP (389 UDP and

TCP)
Microsoft SMB (445
TCP)
Kerberos (88 UDP)

controllersInternal
(all ports)
Use Kerberos
authentication
(internal forest
client to external
forest)
Kerberos (88 UDP)
N/A
Internal clientExternal
(all ports)
Use NTLM
authentication
(internal forest
client to external
forest)
N/A
Endpoint resolution
portmapper (135
TCP) Net Logon
fixed port

controllersInternal
(all ports)
Join a domain from

a computer in the
internal network to
an external
domain
LDAP (389 UDP and TCP) N/A

Kerberos (88 UDP)
Endpoint resolution
Logon fixed port
Windows NT Server 4.0
directory service fixed port

FromTo
Internal clientExternal
(all ports)
41
Using Netdom
20
This command-line tool enables administrators to manage Windows Server 2003 and
Windows 2000 domains and trust relationships from the command line.
You can use NetDom to:
Join a Windows XP Professional-based computer to a Windows Server 2003 or Windows

2000 or Windows NT 4.0 domain.
Provide an option to specify the organizational unit for the computer account.
Generate a random computer password for initial join.
Manage computer accounts for domain member workstations and member servers.
Management operations include:
Note
Add, Remove, Query.
An option to specify the organizational unit for the computer account.
An option to move an existing computer account for a member workstation from one
domain to another while maintaining the security descriptor on the computer
account.
Establish one-way or two-way trust relationships between domains, including the

following kinds of trust relationships:
From a Windows 2000 or Windows Server 2003 domain to a Windows NT 4.0

domain.
From a Windows 2000 or Windows Server 2003 domain to a Windows 2000 or

Windows Server 2003 domain in another enterprise (an "uplevel" external trust).
Between two Windows 2000 or Windows Server 2003 domains in an enterprise (a

shortcut trust).
The Windows Server 2003 or Windows 2000 Server half of an interoperable

Kerberos realm.
Verify and/or reset the secure channel for the following configurations:
Member workstations and servers.
BDCs in a Windows NT 4.0 domain.
Specific Windows Server 2003 or Windows 2000 replicas.
Manage trust relationships between domains, including the following operations:
Enumerate trust relationships (direct and indirect).
View and change some attributes on a trust.
You must run NetDom from the command window.
42
Using NLTest
21
This command-line tool helps perform network administrative tasks. You can use NLTest to:
Get a list of domain controllers.
Force a remote shutdown.
Query the status of trust.
Test trust relationships and the state of domain controller replication in a Windows
domain.
Force a user-account database to synchronize on Windows NT version 4.0 or earlier

domain controllers.
NLTest can test and reset the secure channel established by the Netlogon service. This secure
channel is established between clients and the domain controller that logs them on. NLTest
does not work for clients using Kerberos for authentication since this secure channel is not
used with Kerberos.
Note
You must run NLTest from the command window.
Using Netmon
22
Network Monitor sniffer traces can help you trace all of the traffic to and from a computer; as
well as to and from the DHCP server that issues IP addresses. A light version is delivered with
Windows 2000 Server. However, to use Network Monitor's full capabilities, you need the full
version included with Microsoft Systems Management Server.
To install Network Monitor, from the Start menu, point to the following:
Settings
Control Panel
Add/Remove Programs
Add/Remove Windows Components
Management and Monitoring Tools
Details
Network Monitoring Tools
As long as you have installed the full version available from Systems Management Server, you
can capture and view every packet on the network. Network Monitor isolates the network layer
where a problem occurred, or where an operation failed, and helps you determine the cause
of the problem.

43
Using ADSIEdit
23
This GUI tool is a Microsoft Management Console (MMC) snap-in that acts as a low-level editor
for Active Directory. Network administrators can use Active Directory Service Interfaces (ADSI)
for common administrative tasks such as adding, deleting, and moving objects with a directory
service. Attributes for each object viewed can be changed or deleted.
To view trusted domains and trust relationship properties by using ADSIEdit:
1. In ADSIEdit, expand the domain directory partition node and navigate to the System
container.
2. In the console details pane, use the Class column to identify all objects with the type
trustedDomain.
3. To view properties, right-click the trustedDomain object, and then click Properties.
4. In the Select which properties to view box, click Both to view both optional and mandatory
attributes.
5. In the Select a property to view box, select a property. Its value is displayed in the
Value(s) box.
Using Ntdsutil
24
Ntdsutil.exe provides management capabilities for Active Directory. You can use Ntdsutil.exe
to perform Active Directory database maintenance, manage and control single-master
operations, and remove replication metadata left behind by domain controllers that are
removed from the network without uninstalling Active Directory. You can also use Ntdsutil to
create application directory partitions and perform authoritative restore operations. This tool is
intended for use by experienced administrators.
Troubleshooting Trust Problems

25
As mentioned before, trust issues typically come down to communication issues, or

permission issues. Try to determine if the trust is now being initially setup or if it has been
established and now not working.
Examining Common Problems with Trusts

26
Communication issues typically come down to name resolution issues or connectivity issues.
When name resolution is being evaluated, you need to determine what name resolution
service is being used? For Windows 2000 and Windows Server 2003, DNS will always be
used. For Windows NT 4.0 domains, WINS service is typically used for NetBIOS name
resolution.
44
Common Name Resolution Problems

27
If you receive the following error, ERROR_NO_LOGON_SERVERS while using the Nltest tool to
query the secure channel, this is usually indicative of the inability to find a domain controller
for that domain. Run nltest /dsgetdc: <DomainName>: to verify whether you can locate a
domain controller. If you are unable to find a domain controller examine DNS registrations, in
a Windows 2000 / 2003 environment and network connectivity.
Winnt 4.0 uses WINS service or Lmhosts files for NetBIOS name resolution. One quick test
would be to try to map a drive from a machine in the Winnt 4.0 domain to the Windows 2000
/ 2003 domain and vice versa. If you are having name resolution issues, you will get an error
stating There are currently no logon servers available to service the logon request. One quick
way to take the WINS service from the equation is to place Lmhosts files on the DC in the
Windows 2000 / 2003 domain and the Winnt 4.0 PDC. Lmhosts files are case sensitive. To
eliminate the common mistakes made while creating Lmhosts file, there are Lmhosts
generator tools available on http://toolbox.
Common Connectivity Problems

28
If you have received error messages that are similar to the following error message and you
have verified that the LMHOST files are correct, the issue may be caused by a firewall, router
or switch that has blocked ports between the domain controllers:
No domain controller could be contacted.
To troubleshoot network devices, use PortQry Command Line Port Scanner version 2.0 to test
the ports between your domain controllers.
Common Security Settings Problems

29
Use the Netdom tool to verify the Kerberos v5 authentication protocol between a client and a
target domain. The Netdom tool trust verification option with the /Kerberos switch allows you
to obtain a session ticket from the Kerberos authentication service in the target domain. If
successful, the conclusion is that Kerberos operations such as Key Distribution Center (KDC)
referrals are operating correctly between the workstation and the target domain. Upon failure,
the list of referral tickets currently cached, are displayed. If you do not receive the session
ticket, the cause of failure can be determined by tracing the list of referral tickets from the
KDCs located on the path toward the target domain.
To verify the Kerberos authentication protocol issue the following command:
NETDOM TRUST <trusting_domain_name> /d: <name of the trusted domain>
/Kerberos /UserO:<User account for making the connection with the trusted
domain> /PasswordO:<Password of the user account specified by /UserO >
/UserD:<User account used to make the connection with the domain
specified by the /domain argument >
/PasswordD:<trusted_domain_user_password>

45
Note
Both users must be specified because the command will attempt a Kerberos v5
authentication of those users.
The above command will verify the following:
The trust passwords are correct (for example, determine if the passwords match).
The users can be located in Active Directory.
The users can be authenticated through the issuance of Kerberos v5 tickets.
The Restrictanonymous setting can cause trusts between Windows 2000 /2003 domains and
Winnt 4.0 to brake. When the RestrictAnonymous registry value,
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA, is set to 2, the access
token built for non-authenticated users does not include the Everyone group, and because of
this, the access token no longer has access to those resources which grant permissions to the
Everyone group. This could cause undesired behavior because many Windows 2000 services,
as well as third-party programs, rely on anonymous access capabilities to perform legitimate
tasks. This value is provided in MPSReports, the regentries.txt file. If you see this value is set
to anything other than 0, try resetting it to zero and reestablish the trust.
Other settings that can cause problems when establishing trusts include SMB signing and LM
compatibility level, the following article examines the needed settings for both of these,
Example of regentries.txt from MPSReports:
These are the entries you want to review to determine if Restrictanonymous, SMB signing, or
LM compatibility level could be causing the problems.
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\LSA
crashonauditfail [REG_DWORD]
lmcompatibilitylevel [REG_DWORD]
restrictanonymous [REG_DWORD]
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\lanmanworkstation\pa
rameters
enablesecuritysignature [REG_DWORD]
requiresecuritysignature [REG_DWORD]
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\lanmanserver\paramet
ers
enablesecuritysignature [REG_DWORD]
requiresecuritysignature [REG_DWORD]
46
User Rights
1. Access this computer from network.
2. Allow log on locally.
3. Bypass traverse checking.
These settings would be in the Default Domain Controllers GPO and you would test this by
adding the EVERYONE Group and see if that corrects this. These are located in the GPO at the
following location:
Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights
Assignment
Security Settings
1. Shut down system immediately if unable to log security audits.
Symbolic Name: CrashOnAuditFail
Registry Path: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\
CrashOnAuditFail (Reg_DWORD)
Shuts down the system immediately if unable to log security audits setting determines
whether the system shuts down if you cannot log security events. If the auditing system
fails, the system is shut down, and a Stop error message appears. Disable this in the
Default Domain Controllers Policy.
2. LDAP server signing requirements.
Symbolic Name: LDAPServerIntegrity
Registry Path:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters\
LDAPServerIntegrity (Reg_DWORD)
This value is set on the domain controller. LDAP server signing requirements security
setting determines whether the Lightweight Directory Access Protocol (LDAP) server
requires LDAP clients to negotiate data signing. The possible values for this policy setting
are:
None: Data signing is not required to bind with the server. If the client requests data
signing, the server supports it.
Require signing: The LDAP data-signing option must be negotiated unless Transport Layer
Security/Secure Socket Layer (TLS/SSL) is being used.
Not Defined: This setting is not enabled or disabled. Disable this in the Default Domain
Controllers Policy.
3. Require strong (Windows 2000 or later) session key.
Symbolic Name: StrongKey
Registry Path: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\
Parameters\RequireStrongKey (Reg_DWORD)

47
Require strong (Windows 2000 or later) session key setting determines whether a secure
channel can be established with a domain controller that cannot encrypt secure channel
traffic with a strong, 128-bit session key. Enabling this setting prevents establishing a
secure channel with any domain controller that cannot encrypt secure channel data with
a strong key. Disabling this setting allows 64-bit session keys. Before you can enable this
setting on a member workstation or on a server, all domain controllers in the domain that
the member belongs to must be able to encrypt secure channel data with a strong, 128bit key. This means that all such domain controllers must be running Windows 2000 or
later. Disable this in the Default Domain Controllers Policy.
4. Digitally encrypt or sign secure channel data (always).
Symbolic Name: EnableSecuritySignature
Registry Path:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Lanmanserver\Parameter
s\EnableSecuritySignature (REG_DWORD)
Enabling Domain member: Digitally encrypt or sign secure channel data (always) prevents
establishing a secure channel with any domain controller that cannot sign or encrypt all
secure channel data.
To enable the Domain member: Digitally encrypt or sign secure channel data (always)
setting on a member computer, all domain controllers in the domain that the member
belongs to must be able to sign or to encrypt all secure channel data. This means that all
such domain controllers must be running Windows NT 4.0 with Service Pack 6a (SP6a) or
later.
Disable this in the Default Domain Controllers Policy and verify that this is disabled in the
Default Domain Policy.
5. Digitally sign communications (always).
Symbolic Name: RequireSMBSignRdr
Registry Path:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameter
s\RequireSecuritySignature
Enabling digital signing in high-security networks helps to prevent the impersonation of
clients and of servers. This type of impersonation is known as <session hijacking>. An
attacker who has access to the same network as the client or the server uses session
hijacking tools to interrupt, end, or steal a session in progress. An attacker could
intercept and modify unsigned Subnet Bandwidth Manager (SBM) packets, modify the
traffic, and then forward it so that the server might perform unwanted actions.
Alternatively, the attacker could pose as the server or as the client after a legitimate
authentication and then gain unauthorized access to data.
Note
An alternative countermeasure that may help protect all network traffic is to enable
digital signatures with IPSec. There are hardware-based accelerators for IPSec encryption
and signing that can be used to minimize the performance impact from the server's CPU.
There are no such accelerators that are available for SMB signing.
48
The SMB protocol that is used for file sharing and for print sharing in computers that are
running Windows 2000 Server, Windows 2000 Professional, Windows XP Professional, or
Windows Server 2003 supports mutual authentication. Mutual authentication closes
session hijacking attacks and supports message authentication. Therefore, it prevents
man-in-the-middle attacks. SMB signing provides this authentication by placing a digital
signature in each SMB. Both the client and the server then verify the signature. Disable
this in the Default Domain Controllers Policy and verify that this is disabled in the Default
Domain Policy.
As a rule, any of the settings for Digitally Encrypt or Sign the Secure Channel or the
Secure Channel Data should be disabled.
6. Allow anonymous SID/Name translation.
The Network access: Allow anonymous SID/Name translation security setting determines
whether an anonymous user can request Security Identification Number (SID) attributes
for another user. Disable this in the Default Domain Controllers Policy.
7. Do not allow anonymous enumeration of SAM accounts.
Symbolic Name: RestrictAnonymousSAM
Registry Path: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\
RestrictAnonymousSAM (Reg_DWORD)
Do not allow anonymous enumeration of SAM accounts setting determines which
additional permissions will be granted for anonymous connections to the computer.
Windows allows anonymous users to perform certain activities, such as enumerating the
names of domain Security Accounts Manager (SAM) accounts and of network shares.
This is convenient, for example, when an administrator wants to grant access to users in
a trusted domain that does not maintain a reciprocal trust. By default, an anonymous
user has the same access that is granted to the Everyone group for a particular resource.
Disable this in the Default Domain Controllers Policy.
8. Do not allow anonymous enumeration of SAM accounts and shares.
Symbolic Name: RestrictAnonymous
Registry Path:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\RestrictAnonymous
Do not allow anonymous enumeration of SAM accounts and shares setting (also known
as RestrictAnonymous) determines whether anonymous enumeration of Security
Accounts Manager (SAM) accounts and shares is allowed. Windows allows anonymous
users to perform certain activities, such as enumerating the names of domain accounts
(users, computers, and groups) and of network shares. This is convenient, for example,
when an administrator wants to grant access to users in a trusted domain that does not
maintain a reciprocal trust. If you do not want to allow anonymous enumeration of SAM
accounts and of shares, enable this setting. Disable this in the Default Domain
Controllers Policy.
9. LAN Manager authentication level.
Symbolic Name: LmCompatibilityLevel
Registry Path:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\LmCompatibilityLevel

49
LAN Manager (LM) authentication is the protocol that is used to authenticate Windows
clients for network operations, including domain joins, accessing network resources, and
user or computer authentication. The LM authentication level determines which
challenge/response authentication protocol is negotiated between the client and the
server computers. Specifically, the LM authentication level determines which
authentication protocols that the client will try to negotiate or that the server will accept.
Possible settings include:
Send LM & NTLM responses: Clients use LM and NTLM authentication and never
use NTLMv2 session security; domain controllers accept LM, NTLM, and NTLMv2
authentication.
Send LM & NTLM - use NTLMv2 session security if negotiated: Clients use LM and
NTLM authentication and use NTLMv2 session security if the server supports it;
domain controllers accept LM, NTLM, and NTLMv2 authentication.
Send NTLM response only: Clients use NTLM authentication only and use NTLMv2
session security if the server supports it; domain controllers accept LM, NTLM, and
NTLMv2 authentication.
Send NTLMv2 response only: Clients use NTLMv2 authentication only and use
NTLMv2 session security if the server supports it; domain controllers accept LM,
NTLM, and NTLMv2 authentication.
Send NTLMv2 response only/refuse LM: Clients use NTLMv2 authentication only
and use NTLMv2 session security if the server supports it; domain controllers refuse
LM (they accept only NTLM and NTLMv2 authentication).
Send NTLMv2 response only/refuse LM & NTLM: Clients use NTLMv2 authentication
only and use NTLMv2 session security if the server supports it; domain controllers
refuse LM and NTLM (they accept only NTLMv2 authentication). Set this to Send LM
& NTLM responses.
10. LDAP client signing requirements.

Symbolic Name: LDAPClientIntegrity
Registry Path:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LDAP\LDAPClientIntegrity
This is only needed if the DS Client is installed which you would like you to do
Lightweight Directory Access Protocol (LDAP) client signing requirements setting
determines the level of data signing that is requested on behalf of clients that issue LDAP
BIND requests as follows:
None: The LDAP BIND request is issued with the caller-specified options.
Negotiate signing: If the Secure Sockets Layer/Transport Layer Security (SSL/TLS) has
not been started, the LDAP BIND request is initiated with the LDAP data signing option
set in addition to the caller-specified options. If SSL/TLS has been started, the LDAP
BIND request is initiated with the caller-specified options.
Require signing: This is the same as Negotiate signing. However, if the LDAP server's
intermediate saslBindInProgress response does not indicate that LDAP traffic signing is
required, the caller is told that the LDAP BIND command request failed. Set this to None.
50
How to Resolve Trust Problems

30
An excellent resource in troubleshooting trusts and secure channels is the following KB article:
http://support.microsoft.com/default.aspx?scid=KB;EN-US;889030 Inter-Domain Trust
Account Passwords.
Resetting Domain Controller Secure Channels in Windows 2000/2003
1. Install the Support Tools on the DC. This is located in the Support Directory on the
Product CD to get a copy of NETDOM.EXE.
2. Secure channels are reset against the Domain Controller holding the PDC Emulator Role.
Within the same domain if there are multiple DC's, it may be necessary to transfer
the FSMO Role to a different domain controller in order to reset the secure channel.
If there is only one DC in the domain the secure channel can be reset against
itself
If the DC is the only DC in a child domain, the secure channel can be reset
against the PDC Emulator in the Parent Domain.
3. Determine who is holding the FSMO Role of PDC Emulator through either of the following
three methods:
a.
NETDOM - netdom query fsmo
b.
Active Directory Users and Computers
c.
i.
Start the Active Directory Users and Computers snap-in, right-click the domain,
and then click Operations Masters.
ii.
Click the PDC tab; the current role holder is displayed in the Operations Master
window. On this tab, you can also change the operations master role to the
current computer in the second window (if this computer is not the current
holder).
NTDSUTIL
i.
On any domain controller, click Start, click Run, type ntdsutil in the Open box,
and then click OK. Microsoft recommends that you use the domain controller
that is taking the FSMO roles.
ii.
Type roles and then press ENTER.
iii.
Type connections and then press ENTER.
iv.
Type connect to server <servername> where <servername> is the name of the

server you want to use, and then press ENTER.
v.
At the server connections: prompt, type q, and then press ENTER again.
vi.
Type transfer <role>, where <role> is the role you want to seize. For a list of
roles that you can seize, type ? at the Fsmo maintenance: prompt, and then
press ENTER, For example, to transfer the PDC Emulator role, you would type
transfer pdc.
vii. After you transfer the roles, click q and then press ENTER until you quit the
Ntdsutil tool.
51
4. On domain controllers other than the PDC Emulator operations master role holder,
disable the Kerberos Key Distribution Center service (KDC). To do so:
a.
Click Start, point to Programs, click Administrative Tools, and then click Services.
b.
Double-click KDC, stop the KDC and then set the startup type to Disabled.
When the KDC is disabled, use the Netdom utility to reset the secure channels
between these domain controllers and the PDC Emulator operations master role
holder. To do so, run the following command from the domain controllers other than
the PDC Emulator operations master role holder:
netdom resetpwd /server:<server_name> /userd:<domain_name>\administrator
/passwordd:<administrator_password>
Where <server_name> is the name of the server that is the PDC Emulator
operations master role holder.
On domains that are having problems with Name Resolution or Name Hijacking, the
IP Address of the PDC Emulator can be substituted for the Server NetBIOS Name.
After you reset the secure channel, restart the domain controller. Even if your
attempt to reset the secure channel using the Netdom utility, and the command
does not complete successfully, proceed with the restart process.
If KDC is only running on the PDC Emulator Domain Controller, the Domain
Controller on reboot is forced to connect to the PDC Emulator's KDC (instead of
itself) forcing the domain controller to resynchronize its secure channel password
and issue themselves a new Kerberos ticket.
After the computers have finished restarting, start the Services program, restart the
KDC service and reset it to Automatic.
Additional Information
When a secure channel password is reset on domain controllers, the KDC is stopped to force
the DC to use the PDC Emulator's KDC to reset its tickets and secure channel password. The
password is stored in the registry under LSA and in copies of Active Directory on Domain
Controllers. At reboot after issuing the NETDOM command, the password is reset in the
registry of the DC that needs to be reset and in the copy of Active Directory on the PDC
Emulator. The password must be in sync in the reset machines LSA, and in active directory on
any DC that will authenticate this machine account.
If all the domain controllers are in the same site and connected by high speed connections the
synchronization of the password through AD Replication will occur very soon after reboot.
If the domain controller is in a different site where the replication schedule can be up to 3
hours by default the following steps should be taken:
Do not start the KDC on the domain controller being reset after reboot.
Use REPADMIN.EXE to force the KCC to run and rebuild connection objects if needed
C:\> REPADMIN /KCC (This assumes and DNS is working and all DCs are registered).
Use Active Directory sites and services to force replication from the PDC Emulator back
the DC that you reset the secure channel password on.
52
LAB 2: Troubleshooting Trust Problems

31
Configure trusts between two forests and troubleshoot cross forest trust issues.
Understand the basic concepts of trusts.
Troubleshoot trust problems.
Test and reset secure channels that are established by the domain controllers.
Resources
32
The following links provide additional information about troubleshooting trust problems:
Summary
33
Topics discussed in this session include:
Reviewing and creating trust relationship between same and different OS platforms.
Using different utilities to troubleshoot trust relationship problems.
Troubleshooting common problems with trusts.

53
54

This session discusses how to troubleshoot group policy problems. To begin with, you will learn
about the purposes and components of Group Policy. Next, you will learn how to create, edit,
and link Group Policy. In addition, you will learn about the core Group Policy troubleshooting
tools and considerations for Group Policy core troubleshooting. Then, you will learn how to
troubleshoot problems with GP Settings and Client Side Extensions. Finally, you will learn how
to repair default the two default policies.
Before You Begin

1
Understand Active directorys logical and physical structure.
Be familiar with the Active Directory Users and Computers MMC.
Understand the concepts of security.
What You Will Learn

2
Explain the purposes and components of a Group Policy.
Explain how to create, edit, and link Group Policy.
Describe the core Group Policy troubleshooting tools.
Explain the considerations for Group Policy core troubleshooting.
Explain how to repair default policies.
What Is a Group Policy?

3
Group Policy allows you to setup users environments only once, and to rely on the operating
system to enforce them thereafter.
Group Policy objects are different from profiles. A profile is a user environment setting that a
user can change desktop settings, registry settings in NTUser.dat files, profiles directory, My
Documents, or Favorites. You, as the administrator, manage and maintain Group Policy, an
MMC hosted administrative tool used to set policy on groups of users and computers.

55
What Is a Local Group Policy?

4
In Windows 2000/2003, group policy is typically discussed as part of Active Directory, but
Local Group Policies are also available. As its name implies, it is stored on a local machine at
\systemroot\System32\GroupPolicy. It can be useful if you only need to apply certain settings
to a small number of Windows XP or Windows 2000 clients, or your clients are not members
of a domain.
Differences Between Windows NT 4.0 Policy and Windows Server

2000 Group Policy
5
Microsoft Windows NT 4.0 introduced the System Policy Editor (Poledit.exe), a tool that you
use to specify user and computer configurations that it stores in the Windows NT registry.
Using the System Policy Editor, you control the user work environment and enforce system
configuration settings for all domain computers running Windows NT Workstation 4.0 or
Windows NT Server 4.0. System Policy settings are registry settings that define the behavior of
various components of the desktop environment.
In Windows 2000, you can create a specific desktop configuration for a particular group of
users and computers by using the Group Policy snap-in. For Windows 2000 clients, the Group
Policy snap-in almost entirely supersedes the System Policy Editor. It allows management of
desktop configurations for large, possibly nested, and even overlapping, groups of computers
and users. Non-local Group Policy objects exert their effect by being linked to any number of
targets, which can be sites, domains, or organizational units in Active Directory.
Disadvantages of System Policies

The system policy settings you specify with the System Policy Editor (Poledit.exe):
Are applied to domains.
Can be further controlled by user membership in security groups.
Are not secure. They can be changed by a user with the registry editor (Regedit.exe).
Persist in users' profiles, sometimes beyond their useful lives. After a registry setting is
set using Windows NT 4.0 System Policy, the setting persists until the specified policy
setting is reversed or the user edits the registry.
Are limited to administratively mandate desktop behavior based on registry settings.
Advantages of Windows 2000 Group Policies

The policy settings you specify using group policy represent the primary method for enabling
centralized change and configuration management in Windows 2000/2003.
Group policy settings:
Can be associated with sites, domains, and organizational units.
Affect all users and computers in the site, domain, or organizational unit.
Can be further controlled by user or computer membership in security groups.
Are secure. Only an administrator can change the settings.
56
Are removed and rewritten whenever policy changes.
Can be used to finely tune desktop control and to enhance the user's computing
environment.
For a detailed comparison of Windows NT 4.0 System Policy as compared to Windows 2000
Group Policy, see Applying Change and Configuration Management in the Microsoft
Windows 2000 Server Resource Kit Deployment Planning Guide.
Active Directory Structure and Group Policy

6
Group Policy uses the Active Directory structure (referred to in this course as the Active
Directory hierarchy) as a map for applying specific GPOs to specific Users and Computers.
Group Policy objects are linked to Active Directory container objectsSites, Domains, or
Organizational Units. These containers are collectively referred to as SDOU or SDOUs in Group
Policy discussions, since any of these objects may have links to one or multiple GPOs. The
location of the User or Computer account and the GPOs linked to the Site, Domain or
Organizational Unit(s) in which those accounts reside determine what Policies are applied to
the User or Computer.
It is important to note that GPOs cannot be linked from an object of objectClass=container.
GPOs are linked only from objects of objectClass=Site, objectClass=domainDNS, and
objectClass=OrganizationalUnit. These objects can contain other objects. For simplicity, these
objects will be referred to as Group Policy containers when used generally in this course.
What Is the Order of Group Policy Application?

7
Since Group Policies can be linked to Sites, Domains, or OUs, what determines the order of
application? The local Group Policy object is applied first. Then site-linked Group Policy objects
are applied in specified order, then domain-linked ones in specified order, and lastly
organizational unit-linked Group Policy objects beginning at the highest (in Active Directory
hierarchy) organizational unit containing the user or computer account and ending with the
lowest (closest to the user or computer) organizational unit containing the user or computer.
At each organizational unit, any Group Policy objects linked to it are applied in administratively
specified order.
Figure 10. Group Policy Inheritance

57
The order of application detailed in the previous paragraph (1. Local, 2. Site, 3. Domain, 4.
Organizational Unit) is significant to the architecture of Active Directory, because by default,
policy applied later overwrites policy applied earlier for each setting that is either Enabled or
Disabled. Settings that are not configured do not overwrite anything any Enabled or
Disabled setting applied earlier is allowed to persist.
This is the default behavior for policy application. Mechanisms do exist that let you either
force or prevent Group Policy objects from affecting groups of users or computers. The most
powerful mechanisms for avoiding the default behavior are the No Override and Block Policy
Inheritance settings. These settings can be configured via the GPO properties. It is best to
minimize the use of these. What happens if these two settings appear to conflict? For
example: an Administrator at the OU level could set the Block Inheritance flag for that OU,
which would prevent Policies from above applying to accounts in that OU or in child OUs.
However, if the Domain or Enterprise Administrator has set the No Override flag on a GPO, this
would trump the Block Inheritance setting at the OU level.
Figure 11. Policy Filtering Using Security Groups
In order for a GPO to apply to a given user or computer, that user or computer must have both
Read and Apply Group Policy permissions on the GPO. By default, Authenticated Users have
both Apply Group Policy and Read permissions set to Allow. Both of these permissions are
managed together as a single unit by using Security Filtering in Group Policy Management
Console (GPMC).
To set the permissions for a given GPO:
1. Right click the OU and select Properties.
2. Select the Group Policy tab.
3. Select the correct Group Policy and click the Properties button.
4. Select the Security tab.
58
Where Are GPOs Stored?

9
In a Windows 2000/2003, domain Group Policy objects store Group Policy information in two
locations: a Group Policy container and a Group Policy template. They are named with a
globally unique identifier (GUID), which is used to keep them synchronized.
Figure 12. GPO Storage Locations
Group Policy Container

The Group Policy container, located under cn=system, is an Active Directory storage area for
Group Policy object properties; it includes both computer and user Group Policy information.
The Group Policy container has the following properties:
Version Information
This makes sure that the information is synchronized with the Group Policy template
information.
Status Information
This indicates whether the Group Policy object is enabled or disabled.
Components with Settings in GPO

List of components (extensions) that have settings in the Group Policy object.
Policy Settings as Defined by the Extension Snap-ins

For example, the Group Policy container stores information used by the Software
Installation snap-in to describe the status of the software available for installation. This
data repository contains data for all applications, interfaces, and APIs that provide for
application publishing and assigning.

59
Group Policy Template

Group Policy objects also store Group Policy information in a folder structure called the Group
Policy template that is located in the System Volume folder of domain controllers (Sysvol) in
the \Policies subfolder. The Group Policy template is the container where Administrative
Templatebased policy settings, Security Settings, applications available for Software
Installation, and script files are stored.
When you modify a Group Policy object, the directory name given to the Group Policy template
is the GUID of the Group Policy object that you modify. For example, a Group Policy template
folder might be named as shown in the following example:
%systemroot%\sysvol\SYSVOL\www.Reskit.com\Policies\{47636445-af79-11d0-91fe080036644603}
A Group Policy snap-in can store data outside the Group Policy object; however, this requires
that at least a link to the Group Policy object be stored either in a Group Policy container
(Active Directory data store) or in a Group Policy template (file-type data stored on the Sysvol
folder).
What Are Client-Side Extensions?

10
Group Policy is an extensible Windows 2000 feature. This means that the functionality of the
Core Group Policy feature can be extended by MS or 3rd-party developers to enable
Configuration Management via Group Policy to virtually any component of Windows 2000.
Figure 13 illustrates the group policy framework.
Figure 13. Extensible Group Policy Framework
This extensible architecture is implemented within native Windows 2000 via Client Side
Extensions, which are the system modules responsible for implementing Group Policy
functionality for key components of Windows 2000.
60
These client-side extensions are loaded as needed when a client computer is processing
policy. The client computer first gets a list of Group Policy objects. Next, it loops through all the
client-side extensions and determines whether each client-side extension has any data in any
of the Group Policy objects. If a client-side extension has data in a Group Policy object, the
client-side extension is called with the list of Group Policy objects that it should process. If the
client-side extension does not have any settings in any of the Group Policy objects, it is not
called.
11
Table 7. Client Side Extensions
Client-side Extension
DLL File Name
Registry (in Administrative Templates)
Userenv.dll
Disk Quota (in Administrative Templates)
Dskquota.dll
Folder Redirection
Fdeploy.dll
Scripts
Gptext.dll
Software Installation
Appmgmts.dll
Security
Scecli.dll
IP Security
Gptext.dll
EFS (Encrypting File System) Recovery
Scecli.dll
Internet Explorer Maintenance
iedkcs32.dll
Remote Installation Services
none
Creating Group Policy

12
To set Group Policy for a selected Active Directory site, domain, or organizational unit, you
must have access to a Windows 2000 domain controller for that Active Directory, and you
must have Read/Write permissions to access the system volume of domain controllers (that
is, the Sysvol folder). Finally, you must have Modify rights to the selected active directory site,
domain, or organizational unit.
Creating a Group Policy Object (GPO)

13
Group Policy settings are contained in GPOs that are individually linked to selected Active
Directory objects, such as sites, domains, or OUs. To create and link a new GPO to the Domain
Controllers OU:
1. Expand your domain under Active Directory Users and Computers.
2. Click the plus sign (+) next to Domain Controllers OU to expand the tree.
3. Right-click Domain Controllers OU, and then click Properties.

61
4. On the Domain Controllers Properties page, click the Group Policy tab.
5. Click New, type HQ Policy, and then press ENTER.
Editing a GPO
14
To edit the HQ Policy GPO:

1.
In the MMC console, double-click the HQ Policy GPO (or highlight it), and then click Edit.
This opens the Group Policy Object Editor for editing the HQ Policy. It should appear as
shown in Figure 14.
Figure 14. Group Policy Object Editor
Linking a GPO
15
Group Policy objects are actually applied to a site, domain, or organizational unit by using a
link. Policies are linked using the Property page of the site, domain, or organizational unit. You
can select the Add button to see a list of available GPOs. These are organized by the tabs:
Domains/OU, Sites, All.
62
What Is User Group Policy Loopback Mode?

16
Group Policy applies to the user or computer in a manner that depends on where both the
user and the computer objects are located in Active Directory. In some cases, this processing
order may not be appropriate (for example, when you do not want applications that have been
assigned or published to the users in their OU to be installed while they are logged on to the
computers in some specific OU). With the Group Policy loopback support feature, you can
specify two other ways to retrieve the list of GPOs for any user of the computers in this specific
OU:
Merge Mode
In this mode, when the user logs on, the user's list of GPOs is gathered normally. Then
the computers list of GPOs is gathered using the computer's location in Active Directory.
The list of GPOs for the computer is then added to the end of the GPOs for the user. This
causes the computer's GPOs to have higher precedence than the user's GPOs. In this
example, the list of GPOs for the computer is added to the user's list.
Replace Mode
In this mode, the user's list of GPOs is not gathered. Only the list of GPOs based on the
computer object is used.
This setting is typically used with Terminal Servers.
Note
Loopback is supported only in a purely Windows 2000based environment. Both the

computer account and the user account must be in Active Directory. If either account is
managed by a Windows NT 4.0based domain controller, loopback does not function.
The client computer must be a Windows 2000based computer.
Using Group Policy Core Troubleshooting Tools

17
There are a number of tools available in the Windows 2000, 2003 and Windows XP
environments for obtaining Group Policy troubleshooting information, as listed below:
Resultant GP Tools
GPResult Win2K Reskit
GPResult WinXP Support Tools
HSC RSoP Report
RSoP Snap-in
Group Policy Verification Tool
User Environment Debug Logging
Group Policy Editor Debug Logging
GPText Debug Logging

63
This section of the course will examine each of these tools, discuss how they can be used in
troubleshooting Core Group Policy issues, and look at the best uses and limitations of each
tool.
Using Resultant GP Tools

18
This section discusses the Resultant Group Policy tools for Windows 2000/2003 and
Windows XP.
These tools provide both general and specific data about what the resultant Policies should be
for any Windows 2000/2003 user on any Windows 2000/2003 or Windows XP system.
GPResult.exe
In Windows 2000/2003, GPRESULT is provided with the Windows 2000 Resource Kit.
For Windows XP, GPRESULT was included with the Windows XP Support Tools and updated in
SP1.
Interpreting GPResult Output

This example analyzes the output of Group Policy Results when run in verbose mode using the
following command line:
gpresult /v Operating System Information
When GPResult is run with any mode, the following operating system information is always
displayed at the top of the output:
Microsoft (R) Windows (R) 2000 Operating System Group Policy Result tool
Copyright (C) Microsoft Corp. 1981-1999 Created on Wednesday, September
29, 1999 at 2:47:26 PM Operating System Information:
Operating System Type: Professional Operating System Version: 5.0.2128
Terminal Server Mode: Not supported
Output Details
This output provides you with:
Operating system type (Professional, Server, Domain Controller)
Operating system version (build number and any installed Service Packs)
Terminal Server mode, which indicates if Terminal Server is installed and if so, the mode
in which it is installed
User Output
Following the operating system output comes general information for the current user.
The output begins by detailing the user's configuration. This includes domain
membership, domain type, and the current site as indicated below:
User Group Policy results for:
CN=Alan Steiner,OU=Users,OU=Test,DC=ntdev,DC=microsoft,DC=com
Domain Name: NTDEV
Domain Type: Windows 2000
Site Name: Red-Bldg99
64
Following this, the output details profile information about the user.
The output details the roaming profile (if applicable) and location of the current profile
that is in use:
Roaming profile: \\ntprofiles\roamprof\AlanS
Local profile: C:\Documents and Settings\AlanS
Next, the output details all of the security groups to which the user belongs:
The user is a member of the following security groups: GROUP1\Domain
Users
\Everyone
BUILTIN\Administrators
BUILTIN\Users
BUILTIN\Power Users
GROUP1\RedirectedDesktop
GROUP1\Department 15333
GROUP1\mydocs1\LOCAL
NT AUTHORITY\INTERACTIVE
NT AUTHORITY\Authenticated Users
Following the details of security group membership, the output continues by detailing all
of the user's security privilege information (For the complete list of security privileges that
may be displayed by GPResult, please refer to Security Privileges section below.):
The user has the following security privileges:
Bypass traverse checking
Manage auditing and security log
Back up files and directories
Restore files and directories
Change the system time
Shut down the system
Force shutdown from a remote system
Take ownership of files or other objects
After detailing security privileges, a time stamp of when the last time Group Policy was
applied to current user and the domain controller from which the policy was applied to
the current user are listed.
Last time Group Policy was applied: Monday, September 06, 1999 at 9:25:40
AM
Group Policy was applied from: NTDS.ntdev.microsoft.com
Administrative Templates (Registry-Based Policy)

Next, if any registry-based policies have been applied to the user, the following is
displayed:
The user received "Registry" settings from these Group Policy objects
(GPOs):
Local Group Policy Revision Number: 40
Unique Name: Local Group Policy
Domain Name: EU-DesktopLockDown-Admin
Revision Number: 12 (Active Directory) 12 (Sysvol)
Unique Name: {EF06ECF2-A8C9-11D2-B575-0008C7457B4E}
Domain Name: group.microsoft.com
65
Linked to: Domain (DC=ntdev,DC=microsoft,DC=com)EU-DesktopSetup-Admin

Unique Name: {29021088-BF90-11D2-8614-00C04FF621C4}
Domain Name: group.microsoft.com
Linked to: Domain (DC=ntdev,DC=microsoft,DC=com)
Output Details
The output is a list of Group Policy objects that contain registry-based policy settings
(including Local Group Policy). Each Group Policy object is displayed with the following
details:
Friendly Name
Revision Number
Unique Name (GUID or Local Group Policy)
Domain Name
Linking information
Next, the details of the actual registry-based settings that were applied are displayed:
The following settings were applied from: Local Group Policy
KeyName: Software\Microsoft\Windows\CurrentVersion\Policies\System
ValueName: VerboseStatus
ValueType: REG_DWORD
Value: 0x00000001
KeyName:Software\Microsoft\Windows\CurrentVersion\Policies\Explorer
ValueName: NoSMHelp
Value: 0x00000001
The following settings were applied from: Default Domain Policy KeyName:
Software\Microsoft\Windows\CurrentVersion\Policies\Explorer ValueName:
NoManageMyComputerVerb
Value: 0x00000001
KeyName: Software\Microsoft\Windows\CurrentVersion\Policies\System
ValueName: VerboseStatus
ValueType: REG_DWORD Value: 0x00000001
Output Details
The output lists all registry settings that were applied to the user and the Group Policy
object (by its friendly name) that supplied the registry settings. Each registry settings is
displayed with the following details:
Keyname (location in the registry)
ValueName
ValueType (for example, DWORD or STRING)
Value (The value is displayed here only if it is non-binary. To see a binary value, run
GPResult in super-verbose mode with the /s switch.
66
Note
If any of the registry settings is written to a location outside the area that Group Policy
handles, this registry setting is not a true policy setting. Group Policy uses only the
following locations:
\Software\Policies
\Software\Microsoft\Windows\CurrentVersion\Policies
If any registry settings outside of these locations are applied, the following warning is also
displayed.
+++++++ Warning! The next registry setting is not a true policy setting
and will be left in the registry when the GPO that created it is no
longer applied.+++++++
Folder Redirection
If any Folder Redirection policy settings have been applied to the user, output similar to
the following is displayed:
The user received "Folder Redirection" settings from these GPOs:
EU-RedirectedDesktop-User1
Unique Name: {C19B776C-A8E8-11D2-9BEB-00A024070A22}
Domain Name: ntdev.microsoft.com
Linked to: Domain (DC=ntdev,DC=microsoft,DC=com) EU-FolderRedirectionUser1 Revision Number: 12 (Active Directory) 12 (Sysvol)
Unique Name: {FBEE2508-BCAA-11D2-B3EE-00C04FA3787A}
Desktop is redirected to \\ntpolicy1\desktop\%username%
My Pictures is redirected to \\ntpolicy1\mydocs1\%username%\My Pictures
My Documents is redirected to \\ntpolicy1\mydocs1\%username%
Output Details
The output is a list of Group Policy objects that contain Folder Redirection policy settings
(including Local Group Policy). Each Group Policy object is displayed with the following
details:
Friendly name
Revision number
Unique name (GUID or Local Group Policy)
Domain name
Linking information
A list of the folders that have been re-directed, and their re-directed location

67
Scripts
If any Scripts policy settings have been applied to the user, output similar to the following
is displayed:
The user received "Scripts" settings from these GPOs:EU-Marketing
Unique Name: {EF068882-A229-11D2-B575-0008C7457B4E}
Linked to: Domain (DC=ntdev,DC=microsoft,DC=com) EU-Canada Revision
Number: 44 (Active Directory) 44 (Sysvol)
Unique Name: {HJ924782-A444-11D2-B444-00039573954F}
Logon scripts specified in: EU-Marketing \\marketing1\logon$\adlogon.bat
Logoff scripts specified in: EU-Marketing
\\marketing1\logon$\adlogoff.bat
Logon scripts specified in: EU-Canada \\toronto3\logon$\pplogon.bat
Logoff scripts specified in: EU-Canada \\toronto3\logon$\adlogoff.bat
Output Details
The output is a list of Group Policy objects that contain Scripts policy settings (including
Local Group Policy).
Each Group Policy object is displayed with the following details:
Friendly name
Revision number
Domain name
Linking information
A list of scripts that were run is displayed with the following details:
Type of script (logon, logoff, startup, and shutdown)
Script name
Location from where the script was run
Application Management
If any Application Management policy settings have been applied to the user, output
similar to the following is displayed:
The user received "Application Management" settings from these GPOs: EUCorpStandard
Unique Name: {9B4293472AC06-44D2-B22A-0008C7457E8J}
Linked to: Domain (DC=ntdev,DC=microsoft,DC=com) EU-RedmondSite Revision
Unique Name: {9B4999999AC06-12O2-B66A-0008C7457B4E}
The user has been assigned the following applications: Microsoft Office
2000 Premium (RTM)
68
GPO Name: EU-CorpStandard Removal Option: Application is uninstalled when

policy is removed Microsoft FrontPage 20000 GPO Name: EU-RedmondSite
Removal Option: Application is uninstalled when policy is removed The
user has installed the following published applications: WinZip 7.0 GPO
Name: EU-CorpStandard Removal Option: Application is uninstalled when
policy is removed
Output Details
The output is a list of Group Policy objects that contain Application Management policy
settings (including Local Group Policy). Each Group Policy object is displayed with the
following details:
Friendly name
Revision number
Domain name
Linking information
A list of assigned and published applications is displayed with the following details:
Assigned or published
Name of application
Name of Group Policy object where the application was configured
Removal Option information for the application
If GPResult had instead been run in Super verbose mode (/s), it would also have provided
information on which applications would be available in Add/Remove Programs. The
output would look similar to the following:
The user has the following applications available in Add/Remove Programs:
Microsoft Money 99
GPO Name: EU-RedmondSite
Installed: No
Connection Manager Self Host -- Smart Card Corpnet Access
Installed: No
Microsoft Excel 97 SR2 (Legacy Deployment)
Installed: No
Output Details
The output is a list of applications that will appear in Add/Remove Programs. The details
provided are:
Name of application
Name of Group Policy object where the application was configured
Installed or not installed

69
Other Group Policy Extensions

For other Group Policy extensions that ship with Windows 2000 that have been applied to
the user, the following is displayed for each of these extensions:
The user received "Name of the Extension" settings from these GPOs: EUSecurityB31
Unique Name: {C19ASDAS-ADD8-11D2-9BEB-002342342342}
Linked to: Domain (DC=ntdev,DC=microsoft,DC=com) EU-SecurityHR Revision
Unique Name: {FBEASDAS-BDDA-11D2-B3EE-002342342342}
Computer Output
This section repeats the same processes as above for User Output, but this time displays
information for the computer that the user has logged on to.
The output begins with general information for the computer, including the computer
name and location, domain name, domain type and site name as indicated below.
Computer Group Policy results for:
CN=DEVPC01,CN=Computers,DC=ntdev,DC=microsoft,DC=com Domain Name: NTDEV
Domain Type: Windows 2000 Site Name: Red-Bldg99
After detailing the general information, the output shows a time stamp of when the last
time Group Policy was applied to this computer and the domain controller from which
Computer Group Policy was applied.
Last time Group Policy was applied: Monday, September 07, 1999 at 7:51:59
AM
Group Policy was applied from: NTDS.ntdev.microsoft.com
The Registry Based Policy, Folder Re-direction, and other Group Policy extensions that
have been applied to this computer are detailed at this point. This information is output
in the same format as detailed earlier in this document for the User Output.
In addition, the Computer section displays the following when applicable:
IP Security
If any IP Security policy settings have been applied to the computer, output similar to the
following is displayed:
The computer received "IP Security" settings from these GPOs: EUIPSecDefaultClientPol-RandyRam
Unique Name: {6EB61A60-A991-11D2-9BEB-00A024070A22}
Policy Name: NTDEV Default Client
Policy Description: All NTDEV machines get this
Policy Path: LDAP://CN=ipsecPolicy{163E9FDB-A9AE-11D2-AFD6006097936A9F}CN=IPSecurity,CN=System,DC=ntdev,DC=microsoft,DC=com
70
Output Details
The name of the Group Policy object that applied IP Security settings is displayed. For this
Group Policy object, the following details are displayed:
Friendly name
Revision number
Domain name
Linking information
IP Security settings details:
Policy name
Description
Policy path
Disk Quotas
If any Microsoft Disk Quota policy settings have been applied to the computer, output
similar to the following is displayed:
The computer received "Microsoft Disk Quota" settings from these GPOs:
Local Group Policy
Revision Number: 25
Unique Name: Local Group Policy
Domain Name:
Source: Local computer
Disk Quotas enabled: Yes
Disk Quotas enforced: Yes
Quota limit: 80 MB
Warning level: 120 MB
Log event when quota limit exceeded: No
Log event when quota warning level exceeded: No
Apply policy to removable media: No
Output Details
The name of the Group Policy object that applied Microsoft Disk Quotas is displayed. For
this Group Policy object, the following details are displayed:
Friendly name
Revision number
Domain name
Source
Disk Quota details:
Disk Quotas enabled: yes/no
Disk Quotas enforced: yes/no

71
Quota limit
Warning level
Log event when quota limit reached: yes/no
Log event when quota-warning level exceeded: yes/no
Apply policy to remove media: yes/no
Security Privileges
Here is a complete list of security privileges that can be tracked by GPResult in verbose mode:
Create a token object
Replace a process level token
Lock pages in memory
Increase quotas
Add workstations to domain
Act as part of the operating system
Manage auditing and security log
Take ownership of files or other objects
Load and unload device drivers
Profile system performance
Profile single process
Increase scheduling priority
Create a pagefile
Create permanent shared objects
Debug programs
Generate security audits
Modify firmware environment values
Force shutdown from a remote system
Remove computer from docking station
Synchronize directory service data
Enable computer and user accounts to be trusted for delegation
72
GPResult Win2K Reskit

The Win2k ResKit version of GPResult does not provide information on any of the following
Group Policy areas:
Security policies (use SCE)
Internet Explorer Maintenance policies
EFS Recovery policies
Win2K GPResult - Syntax

Listed below are the command-line switches available for GPRESULT in Windows 2000:
Gpresult [/v] [/s] [/c] [/u] [/?]
/v = verbose mode (GPO, registry settings, redirected folder details)
/s = super verbose (includes binary registry values)
/c = computer settings only
/u = user settings only
/? = help
WinXP GPResult Syntax

Listed below are the command-line switches and syntax for the Windows XP version of
GPResult:
Note
The /scope switch in this version of the tool allows you to specify a user or computer for
which results will be collected, and /u switch allows you to specify the security credentials
that will be used for authentication when collecting the data.
GPRESULT [/S system [/U username [/P [password]]]] [/SCOPE scope]

[/USER targetusername] [/V | /Z]
Description:
This command line tool displays the Resultant Set of Policy (RSoP)
for a target user and computer.
Parameter List:
/S
system
Specifies the remote system to connect

to.
/U
[domain\]user
Specifies the user context under which

the command should execute.
/P
[password]
Specifies the password for the given user

context. Prompts for input if omitted.
/USER
[domain\]user
Specifies the user name for which the

RSOP data is to be displayed.
/SCOPE
scope
Specifies whether the user or the

computer settings needs to be
displayed.

73
Valid values: "USER", "COMPUTER".

/V
Specifies that the verbose information

is to be displayed. Verbose information
details specific settings that have
been applied with a precedence of 1.
/Z
Specifies that the super-verbose

information is to be displayed. Superverbose information details specific
settings that have been applied with a
precedence of 1 and higher. This allows
you to see if a setting was set in
multiple places. See the Group Policy
online help for more information.
/?
Displays this help/usage.
Note
If you run GPRESULT without parameters, it returns the RSoP data for the current loggedon user on the computer it was run on.
Examples:
GPRESULT
GPRESULT /USER targetusername /V
GPRESULT /S system /USER targetusername /SCOPE COMPUTER /Z
GPRESULT /S system /U username /P password /SCOPE USER /V
Using Help and Support Center (HSC) RSoP Report

19
Although of limited use for administrators, users can run Help and Support Center RSoP
Report on their own computers to verify policy settings. This tool provides a user-friendly report
of most policies in effect on the computer on which it is run.
The HSC RSoP Report shows the Group Policy settings that have been applied to the computer
and logged-on user. The report is created as a flat file, which can also be saved as a .HTM file.
The user can access the HSC RSoP Report via the Windows Explorer or via web browser, as
described in the steps below.
To open the Group Policy Help and Support Center RSoP tool:
1. Click Start, click Help and Support Center.
2. Under Pick a Task, select Use Tools to view your computer information and diagnose
problems.
3. Click Advanced System Information, then click View Group Policy settings applied.
20
When system information is collected, RSoP results appear on the screen. This report can be
printed, saved, and sent to an administrator.
74
Figure 15. RSoP Results
Using RSoP Snap-in

21
The Resultant Set of Policy (RSoP) Snap-in lets you verify policies in effect for a given user or
computer, via the GPEdit user interface. The RSoP Snap-in is fully remotable, which means
administrators can direct the snap-in to check policies for any computer or user on a domain.
Once a user or computer is selected, you can expand the policy tree in the left pane of the
interface, and navigate to any of the policies that are in effect for the target user.
The Properties dialog boxes for the various Policies displayed provide the following
information:
Conflicting settings and GPO precedence
GP Version info
Scope and Filtering info
GP ACL Editor
GP CSE error info
Ability to launch GPEdit on listed GPO
The RSoP snap-in (Rsop.msc) enables you to poll and evaluate the cumulative effect that
local, site, domain, and organizational unit Group Policy objects (GPOs) have on computers
and users. Resultant Set of Policy enables you to check for GPOs that might affect your
troubleshooting. For example, a GPO setting can cause startup programs to run after you log
on to the computer.
75
Use this snap-in to evaluate the effects of existing GPOs on your computer. This information is
helpful for diagnosing deployment or security problems. Rsop.msc reports individual Group
Policy settings specific to one or more users and computers, including advertised and
assigned applications.
To run the RSoP Snap-in:
1. As Administrator, logon to your domain using Windows XP.
2. Click Start, Run, and type MMC. The Microsoft Management Console appears.
3. On the File menu, click Add/Remove Snap-in. When the Add/Remove Snap-in dialog box
appears, click Add.
4. In the Available Standalone Snap-ins dialog box, select Resultant Set of Policy and click
Add.
5. When the RSoP wizard welcome page appears, click Next. When the Mode Selection
page appears, click Next.
6. When the Computer Selection page appears, you can browse for the computer for which
you want to display settings. Otherwise, the wizard will check RSoP for the computer on
which it is being run. Click Next.
7. When the User Selection page appears, you can choose which user you wish to view
policy settings for. (In this example, the administrator chooses the user Cynthia as shown
in Figure 16.) Click Next.
Figure 16. Choosing a Target User in the RSoP Wizard
8. When the Summary of Selections page appears, click Next. The wizard should reach the
completion page. Click Finish. Close the Add Stand alone Snap in dialog box.
9. On the Add Remove Snap in dialog box, click OK. RSoP results should appear in the
console as shown in Figure 17.
76
Figure 17. RSoP Results
You can expand the policy tree in the left pane and navigate to any of the policies that are in
effect for the target user. In this example, as shown in Figure 18, RSoP shows the user Cynthia
is subject to various policies enabled via the GPO Kiosklockdown.
Figure 18. Viewing Enabled Policies in RSoP Results

77
22
Figure 19 shows the RSoP Snap-in User Interface.

Figure 19. RSoP Snap-In User Interface
Using Group Policy Verification Tool

23
The Group Policy verification tool (GPOTOOL.EXE) allows you to check the health of the Group
Policy Objects (GPOs) on Active Directory Domain Controllers (DCs). GPOTOOL is available in
the Windows 2000 Resource Kit and included in MPS Reports. GPOTOOL provides the
following information about GPOs on the target DC (for detailed syntax and usage see Group
Policy Verification Tool in the Troubleshooting Tools section of this course):
Check GPO Consistency

Reads mandatory and optional DS properties (version, friendly name, extension GUIDs)
and SYSVOL data (GPT.INI). Also, compares DS and SYSVOL version numbers and
performs other consistency checks (functionality version must be 2, user/machine
version > 0 if extensions property contains any GUID).
Check GPO Replication

Reads GPO instance from each DC and compares them (selected GPC properties and full
recursive compare for GPT).
Displays GPO Information

The tool can be used to display information about a particular GPO, including properties
that cannot be accessed through the Group Policy snap-in, like functionality version and
extension GUIDs.
78
Browses GPOs
A command line option can be used to search policies based on friendly name or GUID.
Even better, partial match is also supported for both name and GUID.
Preferred DCs
By default, all available DCs in the domain will be used; this can be overwritten with the
supplied list of DCs from the command line.
Cross-Domain Support
Command line option is available for checking policies in different domains.
Verbose Mode
If all policies are okay, the tool spews a validation message; in case of errors info about
corrupted policies is printed. A command line option can be used to turn on verbose
information about each policy being processed.
Using User Environment Debug Logging

24
As previously noted, the USERENV process provides the functionality of the Core Group Policy
Engine. Debug Logging is provided for USERENV, and may be enabled via the following registry
key:
HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\UserEnvDebugLevel
(REG_DWORD)
The values that can be used are as follows:
#define DL_NORMAL
0x00000001
#define DL_VERBOSE
0x00000002
#define DL_LOGFILE
0x00010000
#define DL_DEBUGGER
0x00020000
The value normally used for troubleshooting is 0x10002.
The USERENV debug log, USERENV.LOG, is created in the following location:

%windir%\debug\usermode\userenv.log
USERENV.LOG stores debug logging for the USERENV process, and tracks loading of the User
Profile and processing of Group Policy Objects.
For detailed information on how to enable the USERENV Debug Log, please see Q221833 Enabling User Environment Debug Logging in Retail Windows.doc in the Additional References
section of this course.
Using Group Policy Editor Debug Logging

25
Group Policy editing functions are provided via the Group Policy Editor MMC extension
(GPEDIT.EXE). Debug Logging is provided for GPEDIT, and may be enabled through the
following Registry key:
HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\ GPEditDebugLevel
(REG_DWORD)

79

#define DL_NORMAL
0x00000001
#define DL_VERBOSE
0x00000002
#define DL_LOGFILE
0x00010000
#define DL_DEBUGGER
0x00020000
The GPEDIT debug log, GPEDIT.LOG, is created in the following location:

%windir%\debug\usermode\gpedit.log
GPEDIT.LOG stores debug logging for the GPEDIT process. This log is useful when
troubleshooting GP modification problems such as not being able to open a policy in GPEdit.
Using GPText Debug Logging

26
The Scripts & Administrative Templates CSEs use functions in the gptext.dll file. There is
additional debug logging that can be enabled for these functions. Debug Logging is provided
for GPTEXT.dll, and may be enabled via the following Registry key:
HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\ GPTextDebugLevel
(REG_DWORD)
#define DL_NORMAL
0x00000001
#define DL_VERBOSE
0x00000002
#define DL_LOGFILE
0x00010000
#define DL_DEBUGGER
0x00020000
The GPTEXT debug log, GPTEXT.LOG, is created in the following location:

%windir%\debug\usermode\gptext.log
GPTEXT.LOG stores the debug logging for the Administrative Templates and Scripts CSE as
well as other functions in the gptext.dll file.
In practice, this debug logging is not very useful. But it is important to know that it is there in
case you are encountering problems in that area and do not have significant clues that might
lead you to the cause of the problem.
In the example below the Scripts CSE is failing to run logon scripts. This is because the System
does not have write access to the
HKCU\Software\Policies\Microsoft\Windows\System\Scripts registry key and cannot create a
Logon key. Scripts CSE troubleshooting will be discussed in further detail later in this course.
Below you can see the gptext.log contents when encountering this error.
GPTEXT(904.844) 11:24:20:593 ProcessScriptsGroupPolicy Entering
GPTEXT(904.844) 11:24:20:593 AddPathToList: Adding
<\\reprodom.com\SysVol\reprodom.com\Policies\{8825145A-5C3A-4A51-97F90526FBFB96EC}\User\Scripts> to list.
GPTEXT(904.844) 11:24:20:593 ProcessScriptsGroupPolicy Leaving with 5.
80
Considerations for Group Policy Core Troubleshooting

27
Now that you are familiar with the most useful tools and logs available for troubleshooting
Core Group Policy issues, you will learn about specific troubleshooting considerations, and
describe a troubleshooting approach and method for dealing with core GP issues.
This section discusses key troubleshooting considerations when faced with Group Policy
issues. Together, these comprise an overall troubleshooting approach for core GP issues.
Troubleshooting Group Policy Settings Problems

28
The first step in troubleshooting a group policy setting issue is to identify the issue. Questions
such as what errors are being logged and what is the client computer seeing will help you start
to determine the issue.
Identifying and Resolving Group Policy Settings Problems

29
This section discussed how to identify and resolve group policy setting problems.
Were You Authenticated by a DC?

In Windows 2000 Group Policy, policy is delivered based on the placement of objects and
links in the structure of Active Directory. GPOs are linked to Active Directory container objects,
and apply to other Active Directory container objects. Since access to the Active Directory
objects is dependent on a domain controller for that domain, if you are unable to authenticate
with a DC in the domain Group Policy will fail to apply.
An easy way to determine if a logged on user has been authenticated by an Active Directory
DC is to check the LOGONSERVER environment variable. (Type Set at a command prompt to
obtain a list of environment variables.)
If the LOGONSERVER value indicates the local computer name, rather than the name of a
domain controller, the user has been logged on with a local account, or with cached domain
credentials. They have not contacted a valid Domain Controller, and Group Policy will fail to
apply.
Checking the value of the LOGONSERVER environment variable is not a valid test on a
Windows XP client. Due to Windows XP Fast Logon Optimization, Windows XP will display the
last DC to authenticate the user even when logged on with cached credentials.
Tip For additional information, see http://support.microsoft.com/default.aspx?scid=KB;ENUS;305293.

81
Can You Access Sysvol?

Recall that every GPO consists of an active directory portion (the GPC) and a file system
portion (the GPT). Since the file system portion of each GPO is stored beneath the SYSVOL
share on each domain controller, both user and computer accounts must have adequate
access to the SYSVOL share to successfully process Group Policy.
Therefore, there are a number of things to check with regard to SYSVOL access if Group Policy
is failing.
First, verify that the user, computer, and System accounts all have adequate permissions to
access the SYSVOL share on the authenticating DC.
One way to check whether the computer has access is as follows:
1. Use the AT command to launch a cmd prompt interactively: (at 12:32p /interactive
cmd.exe) replace 12:32p with a time 1-2 minutes ahead of your current clock.
2. Then, type at the command prompt that is launched: dir \\<FQDN of the domain>\sysvol
3. If contents are displayed, walk the contents of the failing policy to make sure that you
have proper access to all relevant files.
If you are unable to access the SYSVOL share, and if you fail with access denied, check the
both share-level and NTFS-level permissions on SYSVOL, along with the following user rights:
Access this computer from the network
The DS version of MPSReports has a %computername%_USERRIGHTS.txt file that contains

the accounts granted these rights.
If the problem does not seem to be access-related, that is if all relevant accounts have proper
access to SYSVOL, then you need to make sure that the required policy files, the GPT files, are
there, and that there are no file-level permissions on the GPTs blocking access for the USER,
COMPUTER, or SYSTEM accounts. These accounts should have at least Read permission to
these files.
If you fail to access the SYSVOL with non-security related errors (examples would include
system errors 53, 67, 51, etc.) you could be having network connectivity problems. The
following items should be checked.
Can you connect to \\<FQDN of Domain>\sysvol?
If No -> Can you connect to %LOGONSERVER%\sysvol?
If Yes -> Check to make sure that the DFS client isnt disabled
Check to make sure that the TCP/IP NetBIOS Helper service is started
Check to make sure that the client computer is pointing to the proper DNS
server and that the DC has registered its records with the DNS server
If No -> Can you connect to \\<IP address of the logonserver>\sysvol?
If No ->Check to make sure that the Sysvol is shared out on that DC
If Yes -> Check DNS.
82
If Sometimes -> You could be seeing sporadic results based on the DC that is
hosting the \\<FQDN of Domain>\sysvol share. Try selecting a different DC to host
the SYSVOL share and refresh policy.
Check ACLs on GPO

In order for a GPO to apply to a specific user account, that user, or a group including the user,
must be in the ACL for the GPO itself, with at least Read and Apply Group Policy permissions.
These permissions are assigned via GPEdit, in the Properties of each GPO.
When checking ACLs for any purpose, you should also make sure that no permissions have
been denied to any of the accounts in question. Remember that a Deny for any permission will
override a Grant for the same permission. For example, if the user is granted the permission,
but a group containing the user is denied the permission, the deny overrules the grant, and
the user is not granted the permission he was denied.
It is also required that the account have permissions to read the gPLink attribute on the
linking OU.
Check GPO and OU Properties

There are a number of options that can be set in the Properties of each GPO and OU that
should be checked in event of trouble.
It may also be necessary to check the Properties of all OUs between the location of the User or
Computer account and the location of the GPO, to ensure that a value set at one level is not
preventing the GPO from applying further down the tree.
First, make sure the GPO in question has not been disabled. This is set via the Properties of
the GPO.
Does an OU closer to the user or computer object have Block inheritance set? If so, that would
prevent a GPO linked to a higher-level container from applying to an account at a lower level of
the tree. This can be overridden with the No Override option on the GP Link.
What Is the Replication Status of the GPO?

If you determine that a GPO or GPOs are not applying in the expected manner, Active Directory
and/or SYSVOL replication could be a factor, and should be checked.
Recall that each GPO consists of two pieces the GPC and the GPT. The GPC is maintained in
Active Directory, the GPT is maintained in SYSVOL on the local file system of each DC. In
addition, as previously noted, each of these relies on a different replication mechanism to
maintain consistency of these objects across all DCs. GPC data is replicated via Active
Directory replication, GPT data is replicated via FRS replication. Therefore, it may be necessary
to check the replication status of these objects.
Therefore, it is important to make sure that the version number is synchronized across all of
the DCs for both the AD version (GPC) and the Sysvol version (GPT) of policy. It is also
important to make sure that the AD version and the Sysvol version of the policy is in sync.
GPOTool provides this service and information for you. A sysvol mismatch error typically
indicates that the Sysvol version of policy is not in sync across all of the DCs in the domain. A
DS mismatch error indicates that AD replication has not yet successfully replicated the DS
version across all DCs in the domain. A version mismatch error typically indicates that the DS
version and Sysvol version do not match on a particular DC. This is usually caused by an
authoritative restore of either the GPC or GPT. On the other hand, it may be caused by FRS
issues such as anti-virus or a security policy changing the security descriptors of the contents
of the Sysvol.
83
Troubleshooting Client Side Extension Problems

30
Remember that the Core Group Policy engine has somewhat limited responsibility when it
comes to the specifics of Group Policy for any given part of the system, and that the ClientSide Extensions (CSE) are actually responsible for application of policy in their specific areas.
With that in mind, it makes sense to include a status check of any applicable CSEs to the
overall troubleshooting approach.
While details about the CSEs are provided in another section of this course, in the present
context of troubleshooting overall Group Policy functions, keep these two things in mind:
Make sure that relevant CSEs are not disabled.
If Core GP functions seem to be okay, it may be necessary to drill down at CSE-level to

complete troubleshooting.
The CSE can be disabled by use of the NoUserPolicy and NoMachinePolicy registry entries.
These entries are discussed in further detail in: Q216358 Troubleshooting Group Policy ClientSide Extension Behavior.
Registry-Based Settings in Windows 2000 Policy

As discussed in the Core Group Policy section of this course, most native Windows 2000
Group Policy Objects write settings to a designated section of the Registry, which are applied
via a mechanism that clears policy settings prior to policy refresh, and avoids settings being
permanently tattooed on the Registry.
This represents an improvement over the NT 4.0 System Policy model, where all Policy
settings were written directly to live registry keys. This behavior caused problems when
settings were enabled or disabled by mistake it was very difficult to determine what registry
keys were affected, and unwanted changes had to be located and undone manually.
However, there are still exceptions to this rule in Windows 2000. Administrators can still
specify NT 4.0-style settings via customized policy template files (.ADM files), which typically
write changes directly to specified registry keys.
Such settings are called Preferences rather than Policies, and do not take advantage of the
more flexible model provided by Windows 2000.
As a result, any settings specified via a direct registry path outside of the two Policies keys
noted above is left in place when policy is refreshed, unless it is specifically overridden by a
later policy.
Troubleshooting the Registry Client-Side Extension

The Registry Client-side Extension is invoked when the Administrative Templates nodes are
used in GPEDIT. The Registry CSE processes GPOs, which contain settings specified via the
Administrative Templates.
Windows 2000 provides an improved mechanism for applying such registry-based policy
settings, which makes it easier to determine what registry keys have been affected by Policy,
and if necessary, undo or adjust the settings.
84
This improved mechanism relies on the use of the REGISTRY.POL and NTUSER.POL files. A
REGISTRY.POL file exists as part of each GPO for which registry-based settings have been
specified, i.e. via the Administrative Templates. When Policy is applied, changes are applied
from the REGISTRY.POL files to the registry of the target computer, per the GPO order of
precedence. As the REGISTRY.POL files are processed, the NTUSER.POL files are created,
which reflect all of the changes that have been written to the registry as a result of the applied
GPOs.
There are two NTUSER.POL files on each system one containing User settings, and one
containing Computer settings. The user copy is stored in the root of the User Profile. The
computer copy is stored in the root of the All Users profile.
The core Group Policy engine invokes the Registry CSE at startup, logon, or the Policy Refresh
Interval, and passes the extension the list of Group Policy Objects to be applied. As the GPOs
are processed, settings are applied from the REGISTRY.POL files to the appropriate registry
keys on the target machine, and the NTUSER.POL files are created. The NTUSER.POL files
record all of the registry-based settings applied. At Policy refresh, the Registry CSE parses the
existing NTUSER.POL files on the target computer to clear any previously-specified registry
settings.
Troubleshooting Scripts CSE

Windows 2000 provides a mechanism for specifying and executing scripts via Group Policy.
This capability relies on the Scripts Client Side Extension.
By default, Group Policy may be configured to run the following types of scripts:
Start Up
Log On
Log Off
Shutdown
The role of the Scripts CSE in processing scripts is fairly straightforward. It simply locates the
specified script based on data provided by individual GPOs, and then passes the data to a
local USERINIT process, which executes the specified script. The Scripts CSE is not
responsible for errors that occur within the execution of the script.
Script Storage - SYSVOL

Each GPO that specifies a script to be run includes a SCRIPTS.INI file as part of the GPO data.
SCRIPTS.INI contains the path and parameters for each script to be run. SCRIPTS.INI is a
hidden file. On the SYSVOL, SCRIPTS.INI is stored in the following directories:
<domain>\Policies\<policy>\User\scripts\Logon
<domain>\Policies\<policy>\User\scripts\Logoff
<domain>\Policies\<policy>\Machine\scripts\Shutdown
<domain>\Policies\<policy>\Machine\scripts\Startup

85
Script Storage - Local GPO

If a script is specified via a Local GPO, the SCRIPTS.INI is located in:
%SYSTEMROOT%\System32\GroupPolicy\User\Scripts for logon and logoff scripts.
%SYSTEMROOT%\System32\GroupPolicy\Machine\Scripts for startup and shutdown

scripts.
Note
SCRIPTS.INI has the same ACLs as any of the other files in the LGPO directory structure.
Typical Scripts CSE Process Errors

As noted in the previous section, the two most frequent problems encountered with the
Scripts CSE are:
Bad Script Path in SCRIPTS.INI
Hung Script
Note
Failure of an individual script will result in that script only failing. The Scripts CSE will
continue executing other scripts as specified by the Scripts data in the registry.
Options for gathering troubleshooting information include:
Enabling USERENV logging, with verbose switch.
Event Log entries with source USERINIT.
Hung Scripts
The default time allocated for scripts to run is 10 minutesbut note that this is the time
allocated for all scripts to run. This means that if a script hangs, fails, or stops executing
for any reason, other scripts will be processed (only if scripts are running
asynchronously), but after 10 minutes any unprocessed scripts will be shut down.
This timeout value can be modified via the Computer policy setting Maximum wait time
for Group Policy Scripts.
Reasons Scripts Hang

Often scripts will hang because the script is requesting user input and the script is
hidden, preventing the user from providing the input. To resolve this problem rewrite the
script to not request user input or set the policy to run the script visible.
Computer Configuration/Administrative Templates/System/Scripts/Run
startup scripts visible
Computer Configuration/Administrative Templates/System/Scripts/Run
shutdown scripts visible
User Configuration/Administrative Templates/System/Scripts/Run logon
scripts visible
User Configuration/Administrative Templates/System/Scripts/Run logoff
scripts visible
86
Another reason startup or shutdown scripts will fail is because they run under the context
of the system. Some operations do not behave the same when run under the context of
the system. An example is mapping a network drive to a NT4 machine. This will fail unless
you specify alternate credentials. This is because NT4 does not recognize the computer
account as a valid account to establish a connection with.
To test your script with system credentials launch the command prompt with AT
Scheduler (at 2:34p /interactive cmd.exe ).
Note
This only works when connected to session zero. Therefore, if you are connected to a TS
session other than zero, this will not work. This will launch the command prompt running
under system credentials at which point you could call your script from the command
prompt to test whether or not it processes successfully.
Troubleshooting Security CSE Issues

When troubleshooting issues related to Security Policy, it is useful to have some familiarity
with the Security Client Side Extension, and with some of the specific common problems
encountered by customers. This section provides more detail on the Security CSE, and
discusses detailed troubleshooting steps for some common Security Policy issues.
The binary file that contains the Security CSE is SCECLI.DLL. This name will usually appear in
Events, error messages, and log entries generated and logged during processing of Security
GPOs.
SCECLI manages application of the Security policy settings that appear under the Security
Settings node in GPEdit. SCECLI is responsible for the following areas:
Account Policies
Local Policies
Event Log
Restricted Groups
System Services
Registry
File System
SCECLI provides debug logging when enabled, and the log is written to the file
WINLOGON.LOG. Enabling this log is the first step in troubleshooting Security Policy issues.
Enabling SCECLI Debug Logging

The following Registry entry is used to enable debug logging for SCECLI:
HKLM\Software\Microsoft\WindowsNT\CurrentVersion\WinLogon\GPExtensions\{827D319E
-6EAC-11D2-A4EA-00C04F79F83A}
ExtensionDebugLevel (REG_DWORD)
0 = Log nothing
1 = Log only errors
2 = Log all transactions

87
For troubleshooting, the best idea is to enter the value 0x2 to enable full logging. The log file is
then created in the following location:
%SYSTEMROOT%\security\logs\winlogon.log
This is one of the most important tools in troubleshooting the Security CSE. If you are having a
problem with the Security CSE one of your first steps should be enabling this debug logging
and collecting the winlogon.log file.
Security CSE Process

When the Security CSE is notified by the Core GP engine, it is provided a list of GPOs to apply.
The Security CSE then copies the gpttmpl.inf file from the folder structure of each policy in the
Sysvol. It copies that file locally to the hidden folder
%SYSTEMROOT%\Security\Templates\Policies. The settings are read from the gpttmpl.inf in
the Sysvol and written to an intermediary file named tmpgptfl.inf. Once the copy has
completed successfully the file is copied off and is named incrementally starting from
gpt00000.inf. If the GPO is linked to the domain then the cached template will be named with
the .dom extension otherwise, it will be named with the .inf extension. This is done because
some settings are only applied if they are linked to the domain, see Q259576 for more
information. The templates are then applied from the cached location in order from least to
greatest. This means that the gpt00000.inf will be applied before gpt00001.inf and that
gpt00001.inf will have a higher precedence in the case of a conflict.
The cached templates and their file attributes are captured by the DS version of MPSReports.
You can see the contents in the %COMPUTERNAME%_AppliedSecTempl.txt file.
Common Security CSE Events

There are two common events generated by SCECLI that provide good models for
troubleshooting approach and technique. This approach is discussed in the upcoming
sections.
The two common events that are discussed are SCECLI 1202 and USERENV 1000. These are
both essentially generic events that indicate that the SCECLI CSE encountered an error.
SCECLI 1202 is registered by the Security CSE, and the USERENV 1000 by the Core GP
Engine. These two events typically appear together in the Event Viewer when an error has
occurred.
Being generic notifications, neither event contains much useful detail, other than the Win32
error codes. In addition, there are several known causes of these events, for which solutions
have been documented.
The useful information that these events contain is a Win32 error code. By examining the
error code and associated documentation, you can obtain more detail about the cause of the
problem.
The SCECLI 1202 event will contain the Win32 error code in its hexadecimal form. The
USERENV 1000 event will contain the error code in its decimal form. Once you have the
decimal representation of the Win32 error code you can run net helpmsg <error code>
(replacing <error code> with the decimal error number) to get an error description.
Example:
C:\>net helpmsg 1332
No mapping between account names and security IDs was done.
88
Troubleshooting Folder Redirection CSE

The Folder Redirection Client Side Extension is housed in the binary file FDEPLOY.DLL. This
CSE handles creation and application of Folder Redirection Policy for the following redirectable
folders:
My Documents
My Pictures
Application Data
Desktop
Start Menu
Programs
Startup
Folder Redirection Policies are created using the GPEdit Folder Redirection snap-in.
Folder Redirection Policies are stored in SYSVOL\Policies\<policy GUID>\User\Documents &
Settings, and in the FDEPLOY.INI file.
Troubleshooting Common Folder Redirection Issues

A number of resources exist for gathering information useful in troubleshooting Folder
Redirection Policy failures. Few of them are discussed below:
Enable USERENV.LOG for core GP engine to verify that policy was processed
Recall that while USERENV hands off processing of GPOs to the Client Side Extension
(FDEPLOY, in this case) USERENV still logs which GPOs were handed off for processing. If
the GPO was never handed off, it was never processed, so it is always a good idea to
verify that all GPOs were indeed processed.
Examine the Event Log: Note entries with source name FOLDER REDIRECTION
As always, a good preliminary troubleshooting step is to check the Event Viewer. The
Event Viewer may not provide great detail, but it will at least usually let you know when
something is wrong, and perhaps provide a clue about where to look next. In this case,
look for Events logged with the source name Folder Redirection.
Enable FDEPLOY debug logging

Debug logging for FDEPLOY.DLL may be enabled via the following registry key:
HKLM\Software\Microsoft\WindowsNT\CurrentVersion\Diagnostics\FdeployDebugLevel
= Reg_DWORD 0x0f
The FDEPLOY log file is created at the following location:
%windir%\debug\usermode\fdeploy.log
This log tracks activity that takes place once the GPO is handed off to FDEPLOY for
processing, and will provide the most specific information about any problems that occur
in processing Folder Redirection policy.
Troubleshooting Software Installation CSE

The Software Installation Client-side Extension provides a policy-driven means of making
software and software updates available to client computers.

89
Administrators can define software MSI packages to be automatically made available or

installed on client computers, and can use Group Policy to define which users receive which
packages.
Gathering Troubleshooting Information

As with other Group Policy components, the first step in effective troubleshooting for Software
Installation is gathering information about the system, environment, and error conditions. A
number of good options exist for collecting such information.
As noted in other sections of this course, the Event Viewer is always a good first stop to get a
sense of what errors are occurring, and what components are generating the errors. When
problems are encountered, the following services, components, and processes all register
events that may be viewed using Event Viewer:
Application Management
Userenv
Windows Installer
Verbose Logging is also available for key components involved in Application Installation and
Management:
Application Management Log
USERENV Log
Windows Installer (MSI) Logs
The following sections discuss how to enable these logs.
Verbose Logging
Debug logging for the Software Installation CSE may be enabled via the following registry
key:
HKLM\Software\Microsoft\WindowsNT\CurrentVersion\Diagnostics
Appmgmtdebuglevel = Dword:0000009b
The Software Installation log file is APPMGMT.LOG, and is created in the following
location:
%SYSTEMROOT%\debug\usermode\appmgmt.log
Windows Installer Verbose Logging

Debug logging for the Windows Installer may be enabled via the following registry key:
HKLM\Software\Policies\Microsoft\Windows\Installer
Logging = "voicewarmup
Debug = DWORD: 00000003
Windows Installer Log Files

Depending on the deployment options specified for a software package, and the actions
taken by the user, debug information for Windows Installer is written to debug logs in one
of two locations.
90
For system-initiated deployment actions such as the advertisement of user-assigned

applications, Windows Installer runs in the system context, and the MSI log is created in
the system temp directory, for example:
%SYSTEMROOT%\temp\MSI*.log
For user-initiated actions, such as installation of applications from Add/Remove
Programs, the logs are created in the users temp directory, for example:
%temp%\MSI*.log
Note
Directory Services supports the application of the GPO. Performance handles the MSI
package. There is a testing tool named BASIC.MSI, which is used to see if the group policy
is being processed. This tool helps us determine if the issue resides in the MSI or the
GPO.
Repairing Default Policies

31
Windows 2000 default Group Policies often need to reset to a default state due to a number
of reasons. There are numerous key settings that are defined in the default policies. If these
settings are incorrectly configured it could affect client authentication, directory replication,
FRS, and many other components.
There are two default policies, the Default Domain Policy and the Default Domain Controllers
Policy. These policies are made up of the following settings by default:
Default Domain Policy
Password settings
Stored in {31B2F340-016D-11D2-945F00C04FB984F9}\MACHINE\Microsoft\Windows NT\SecEdit\gpttmpl.inf
Account lockout settings

Kerberos settings
EFS recovery agent policy (EDRP)

Stored in {31B2F340-016D-11D2-945F-00C04FB984F9}\MACHINE\registry.pol
Default settings for Remote install

Stored in {31B2F340-016D-11D2-945F00C04FB984F9}\USER\Microsoft\RemoteInstall\oscfilter.ini
Default Domain Controllers Policy
User Rights
Stored in {6AC1786C-016F-11D2-945F00C04fB984F9}\MACHINE\Microsoft\Windows NT\SecEdit\gpttmpl.inf

91
Auditing Settings
Digitally sign server communication (when possible)

Both policies also contain a gpt.ini file (in the root of the GUIDed folder) used to store the file
system version of the policy.
In some circumstances, the file system portion of policy can get lost. Some of these
circumstances include administrator deleting the file system portion of group policy from the
sysvol, or the file system portion of policy not being replicated with FRS to replica DC before
source DC is decommissioned, etc
Recreating Default Policies

Win 2003: This utility is dcgpofix.exe.
Win 2000: You can use a PSS homegrown utility named recreateDefPol.exe to recreate the
default policies. This tool will recreate the default policies with all of the default settings and
will recreate the Encrypted Data Recovery Policy (EDRP). The EDRP will be created when the
next administrator account logs on to the DC where recreateDefPol.exe was run. It will reset
the AD and Sysvol versions and will also reset the registered client-side extensions to their
defaults. It will not re-link the default policies to their default containers nor will it reset the
GPO permissions in the AD in the current version of the tool (this functionality may be added).
You will need to re-add any service accounts to their appropriate user rights as
recreateDefPol.exe will reset the user rights back to a default state. This is especially common
if Exchange is in the environment.
Tip For more information, refer to article 833783: The Dcgpofix tool does not restore security
settings in the Default
http://support.microsoft.com/?id=833783
LAB 3: Troubleshooting Group Policy Problems

32
Setup Group Policy troubleshooting tools.
Review your understanding on Group Policies and how to troubleshoot them.
Troubleshoot the effects of Domain Controller GPO synchronization.
Troubleshoot GPO load failures.
92
Resources
33
The following resource links provide additional information about troubleshooting group policy
problems:
http://www.microsoft.com/resources/documentation/WindowsServ/2003/all/deploygui
de/enus/Default.asp?url=/resources/documentation/WindowsServ/2003/all/deployguide/enus/dmebb_gpu_qumj.asp
http://www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/direc
tory/activedirectory/stepbystep/gpfeat.mspx
Summary
34
What is a Group Policy?
Creating Group Policy
Using Group Policy Core Troubleshooting Tools
Considerations for Group Policy Core Troubleshooting
Repairing Default Policies

93
94

This session explains what user profiles are and their problems loading and unloading. It also
explains how to troubleshoot user profile problems.
Before You Begin

1
MPS Reports.
Active directory user accounts.
Group policy.
What You Will Learn

2
Describe the types of user profiles.
Identify the common causes of problems with user profiles.
Explain how to troubleshoot problems with loading and unloading user profiles.
Explain how to troubleshoot common problems with user profiles by using different
troubleshooting tools.
User Profile Overview

3
A user profile contains configuration preferences and options for each user. It is a snapshot of
a user's desktop environment. The user or administrator may define the desktop environment.
Every user profile begins as a copy of Default User, which is a default user profile stored
locally on each computer running Windows 2000. The NTUser.dat file within Default User
displays configuration settings from the registry. NTUser.dat is used to store the registry
settings later loaded into HKCU in the registry when the profile is loaded. In addition, every
user profile also uses the common program groups, contained in the All Users folder.
User Profile Options

4
As an administrative tool, user profiles provide these options:
Administrators can create default user profiles that are appropriate for user's tasks.

95
Administrators can set up mandatory user profiles that do not save changes made by
users to the desktop settings. Users can modify the desktop settings of the computer
while they are logged on, but none of the changes are saved at log off. The mandatory
profile settings are downloaded to the local computer each time the user logs on.
Administrators can specify default user settings that will be included in all individual user
profiles.
Settings Saved in a User Profile

5
The following table is a sample of the settings contained in a user profile:

Table 8. User Profile Settings
Source
Parameters Saved
Windows Explorer
All user-definable settings for Windows Explorer
My Documents
User-stored documents
My Pictures
User-stored picture items
Favorites
Shortcuts to favorite locations on the Internet
Mapped network drives
Any user-created mapped network drives
My Network Places
Links to other computers on the network
Desktop contents
Items stored on the Desktop and Shortcut elements
Screen colors and fonts
All user-definable computer screen colors and display text settings
Application data and

registry hive
Application data and user-defined configuration settings
Printer settings
Network printer connections
Control Panel
All user-defined settings made in Control Panel
Accessories
All user-specific program settings affecting the user's Windows

environment, including Calculator, Clock, Notepad, and Paint
Windows 2000based
programs
Any program written specifically for Windows 2000 can be designed so

that it tracks program settings on a per-user basis. If this information
exists, it is saved in the user profile.
Online user education

bookmarks
Any bookmarks placed in the Windows 2000 Help system.
Note
The My Documents, My Pictures, Favorites, Start Menu, and Desktop folders are, by
default, the only folders displayed in Windows Explorer. The NetHood, PrintHood, Recent,
and Templates folders are hidden and do not appear in Windows Explorer. To view these
folders and their contents in Windows Explorer, from the Tools menu, point to Folder
options, click the View tab, then click Show hidden files and folders.
96
Advantages of User Profiles

6
User profiles provide several advantages to users:
More than one user can use the same computer, and each receives their customized
desktop settings when he or she logs on.
Customization of the desktop environment made by one user does not affect another
user's settings.
User profiles can be stored on a server so that they can follow users to any computer on
the network.
Types of User Profiles

7
There are three types of user profiles:
Local user profile
Roaming user profile
Mandatory user profile
Local Profiles
8
A local user profile is created the first time a user logs on to a computer and is stored on the
local hard disk of the computer. Any changes made to a local user profile are specific to the
computer where the changes were made. Therefore, if a user moves to another machine, the
profile will not be available.
Figure 20. Local Profile

97
Stored Location of Local Profiles

In a new installation of Windows 2000 or Windows XP, or an upgrade over Microsoft
Windows 95 or Microsoft Windows 98, a new folder for user profiles is created on the
same partition as the Windows 2000 installation:
<Windows 2000 installation drive>:\Documents and Settings
For each user that logs on the system, Windows 2000 will create a unique profile folder in the
\Documents and Settings folder known by %userprofile%.
If the Windows 2000 installation is an upgrade from Windows NT, user profile folders are
stored in the same location as in Windows NT:
%SystemRoot%\Profiles
New Users
9
When no pre-configured server-based user profile exists for a user, the first time a user logs
on to a computer, a user profile folder is created for the user name. The contents of Default
User folder are then copied to the new user profile folder. The user profile, along with the
common program group settings in the All Users folder, creates the user's desktop. When the
user logs off, any changes made to the default settings during the session are saved to the
new user profile folder. The user profile in Default User remains unchanged.
The name of the folder created is derived from the user ID, and if necessary, suffixed with the
name of the local computer or domain, whichever is applicable to the user logging on.
If a user with the same down-level name (also known as username) as another user, were to
log on, another folder would be created, but appending the name of the local computer or
domain in which the user's account originates.
Example:
User account from the domain:
<installation drive>:\Documents and Settings\johnd [DOMAIN]
User account on the local computer:
<installation drive>:\Documents and Settings\johnd [COMPUTER]
If another JOHND from a different domain (parent or child) logs on to the same Windows 2000
computer using an identical down-level account name and the SIDs, Security Identifiers of the
two accounts are not the same, a new folder would be created with an extension denoting
how many times the profile experienced this exception. This will occur if a user account is
deleted and later re-created, and the user logs on to the same computer.
Note
Once Windows 2000 is installed, it is very difficult to move the Documents and Settings
folder or Profiles (if upgraded from Windows NT 4.0) folder.
98
To Copy a User Profile

10
Administrators can copy existing profiles to other profiles. This can be done to give users the
same configuration or to modify profiles such as default user.
1. Open System in Control Panel.
2. On the User Profiles tab, under Profiles stored on this computer, click the user profile to
copy, and then click Copy To.
3. In the Copy To dialog box, under Copy profile to, type the location for the new profile, or
click Browse to select the path.
4. Click the Change button to open the Select User or Group dialog box, click a new user
from the Names list, and then click Add. The new user name will appear in Add Name.
5. Click OK to add the user as a new user profile on the computer.
Note
You must be logged on as an administrator to the local computer to copy user profiles.
To Delete a User Profile

Administrators can delete existing profiles. This can be done to remove unused profiles or
profiles from invalid accounts. More commonly, it is used to reset a users configuration to the
first log on (default user) state.
delete, and then click Delete.
Note
You must be logged on as an administrator to the local computer to delete user profiles.
Roaming Profiles
11
Roaming user profiles allow users to move among computers within the network and have
their settings follow them. Roaming user profiles store users data and individual computer
settings on a network share. When a user that has a roaming user profile logs onto the
network, their desktop settings and stored data are copied from the network share to the
computer they are using.

99
Figure 21. Roaming Profile
Computer Configuration for Profiles in Group Policy

12
Group Policy can be used to manage many aspects of Roaming Profiles.

Figure 22. Group Policy Dialog Box
The following settings can be configured for Group Policy affecting Computer Configuration:
Delete Cached Copies of Roaming Profiles

Determines whether the system saves a copy of a users roaming profile on the local
computer's hard drive when the user logs off.
100
Roaming profiles reside on a network server. By default, when users with roaming profiles log
off, the system also saves a copy of their roaming profile on the hard drive of the computer
they are using in case the server that stores the roaming profile is unavailable when the user
logs on again. The local copy is also used when the remote copy of the roaming user profile is
slow to load.
If this policy is enabled, any local copies of the users roaming profile are deleted when the
user logs off. The roaming profile remains on the network server that stores it.
Important
Do not enable this policy if the slow link detection feature of Windows 2000 is being
used. To respond to a slow link, the system requires a local copy of the users
roaming profile.
Do Not Detect Slow Network Connections

Disables the slow link detection feature.
Slow link detection measures the speed of the connection between a user's computer and the
remote server that stores the roaming user profile. When the system detects a slow link, the
related policies in this folder tell the system how to respond.
If this policy is enabled, the system does not detect slow connections or recognize any
connections as being slow. As a result, the system does not respond to slow connections to
user profiles and it ignores the policies that tell the system how to respond to a slow
connection.
If this policy is disabled or do not configure it, slow link detection is enabled. The system
measures the speed of the connection between the user's computer and profile server. If the
connection is slow (as defined by the "Slow network connection timeout for user profiles"
policy), the system applies the other policies set in this folder to determine how to proceed. By
default, when the connection is slow, the system loads the local copy of the user profile.
Slow Network Connection Timeout for User Profiles

Defines a slow connection for roaming user profiles.
If the server on which the user's roaming user profile resides takes longer to respond than the
thresholds set by this policy allow, then the system considers the connection to the profile to
be slow.
Wait for Remote User Profile

Directs the system to wait for the remote copy of the roaming user profile to load, even when
loading is slow. Also, the system waits for the remote copy when the user is notified about a
slow connection, but does not respond in the time allowed.
Prompt User When Slow Link Is Detected

Notifies users when their roaming profile is slow to load. The notice lets users decide whether
to use a local copy or to wait for the roaming user profile.
If this policy is disabled or not configured, when a roaming user profile is slow to load, the
system does not consult the user. Instead, it loads the local copy of the profile. If it is enabled
the "Wait for remote user profile" policy, then the system loads the remote copy without
consulting the user.

101
Log Users Off When Roaming Profile Fails

Logs a user off automatically when the system cannot load the user's roaming user profile.
This policy is used when the system cannot find the roaming user profile or the profile
contains errors, which prevent it from loading correctly.
If this policy is disabled or not configured, when the roaming profile fails, the system loads a
local copy of the roaming user profile, if one is available. Otherwise, the system loads the
default user profile (stored in <installation drive>\Documents and Settings\Default User).
User Configuration for Profiles in Group Policy

13
The following settings as shown in the following figure can be configured for Group Policy
affecting user configuration:
Figure 23. Group Policy Dialog Box
Connect Home Directory to Root of the Share

By default, on Windows 2000, %HOMEPATH% is mapped to the full path specified for the
home directory. For example, if %HOMEPATH% is defined as drive H: and is mapped to
\\server\share\%username%, then H: is mapped to the %username% subdirectory.
If this policy is disabled or not configured, Windows 2000 sets the value of the %HOMEPATH%
environment variable to the share specified, not just to its root folder.
If a user is getting his profile from a remote network share, this will slow down the time it
takes to log on and log off as the profiles are downloaded from the server for log on and
uploaded to the server when they log off.
102
Exclude Directories in Roaming Profile

Allows administrators to add to the list of folders excluded from the user's roaming profile.
This policy allows administrators to exclude folders that are normally included in the user's
profile. As a result, these folders are not stored by the network server on which the profile
resides, and do not follow users to other computers.
UserConfiguration\AdministrativeTemplates\System\Logon/Logoff\Exclude directories in
roaming profile
Once enabled, this allows multiple folder names to be defined, all relative to the root of the
users profile. Once included in the policy, these folders will not be copied to the local machine
at logon, nor copied back to the server at logoff.
When this policy is set, these folders are also added to the Exclusion List = setting in
NTUSER.INI (located in the root of the user profile folder).
This setting is likely to result in decreased time taken for a user to logon, by restricting the
amount of data within a user profile that really does roam with the user. However, it may also
result in a slightly different application environment or slightly decreased application
performance for users who regularly work at different machines.
Note
This policy cannot be used to include the default folders in a roaming user profile.
Limiting Profile Size

One of the potential issues when using roaming user profiles is that over time, the user profile
may potentially grow to a large size, as the user stores more data on their desktop, installs
more applications and increases the complexity of their roaming environment. Whilst much of
this enhances the user experience, it may result in prolonged logon and logoff times for the
user, as the data is copied down from or back up to the server.
Whilst overall excluding some of the profile folders from roaming can reduce profile size, there
may be situations in which it is more useful to actively restrict the overall quota size, to
prevent it growing to an excessive size.
Windows 2000 allows specification of profile quotas using the Group Policy Editor. The path in
the Group Policy name space is:
User Configuration\Administrative Templates\System\Logon/Logoff\Limit profile size
Sets the maximum size of a roaming user profile and determines the system's response when
a roaming user profile reaches the maximum size. By default, the size of roaming profiles is
not limited.
If you enable this policy, you can do the following:
Set a maximum permitted roaming profile size.
Determine whether the registry files are included in the calculation of the profile size.
Determine whether users are notified when the profile exceeds the permitted maximum
size.
Specify a customized message notifying users of the oversized profile.
Determine how often the customized message is displayed.

103
Note
Remember that the user will not be able to log off if the user profile quota is exceeded,
and, by default, small files are not listed in the dialog that displays the files contained in
the profile.
When used alone or together, the ability to exclude profiles from the roaming portion of a user
profile and set an overall quota size on profile provide the ability to successfully reduce and
maintain smaller user profiles. This should have the effect of improving the end-user
experience when logging on and logging off, especially when the user roams between remote
sites and has to access their profile data across a WAN link with low bandwidth and / or
latency.
Slow Link Effects on Roaming User Profiles

14
When a user attempts to download a roaming user profile, the Internet Protocol (IP) slow link
detection mechanism will be evaluated. The administrator can specify the connection speed
that determines a slow network when user profiles are being downloaded.
Figure 24. Link Effects on Roaming User Profiles
104
To specify the slow link detection speed:

1. In the Active Directory Users and Computers snap-in, right-click the site, domain, or
Organizational Unit in which the Group Policy Object (GPO) exists that will contain the
policy for the connection speed, then click Properties.
2. Click the Group Policy tab, click the appropriate GPO, then click Edit.
3. To change the slow link detection speed for Windows 2000 when a user's roaming user
profile is being downloaded, expand the Computer Configuration node and navigate to
the Administrative Templates\System\Logon folder.
4. Modify the Slow network connection timeout for user profiles policy. This policy uses two
values, one in kbps for the TCP/IP slow network detection mechanism and one in ms
(milliseconds) for the time to contact server. To disable slow link detection, use 0 (zero)
for these values. By default, the connection speed is set to 500 (kbps) and the time is set
to 120 (milliseconds).
5. Close the Group Policy snap-in.
Profile Availability
15
If the server storing the profiles is not available, the local cached copy of the roaming user
profile is used. If the user has not logged on to the computer before, a new local user profile is
created. If the user profile is not downloaded due to server problems, it is not uploaded when
the user logs off.
Multiple User Accounts

If the user has a user account on the local computer in addition to a domain user account, or
more than one domain user account, the local user profile is different for each account
because different user profiles are generated for each user who logs on. When the user logs
off, changed settings are saved to only one user profile, depending on which account the user
logged on to.
Note
A profile is only valid on the platform for which it was createdfor example, a Windows
2000 profile cannot be used on a Windows 98 computer.

105
Creating a Roaming Profile

This procedure would be used when configuring roaming user profiles on a user-by-user basis
when creating new user accounts.
1. Open Active Directory Users and Computers.
2. Locate the user account to configure for a roaming profile.
3. Right-click and select Properties.
4. On the Profile tab, enter the path to the network share and a folder to store that users
profile. Using the %username% environment variable is recommended.
Figure 25. Profile Tab
Note
On stand-alone computers, complete the above procedure in the Local Users and Groups
section of the Computer Management MMC.
106
Assuming the user has a local profile on this workstation:

2. On the User Profiles tab, in the Profiles stored on this computer list, click the profile to
copy.
16
Figure 26. User Profiles Tab
3. Click Copy To, then either type the name of the destination folder or browse the network
for it. The path will include the server name, share name and profile folder. It is
recommended that the %username% environment variable be used for the profile folder.
Example: \\server1\profiles\%username%.
4. Click the Change button to open the Select User or Group dialog box, click a new user
from the Names list, and then click Add. The new user name will appear in Add Name.
Note
You must be logged on to Windows 2000 as an administrator to copy a user profile.
Important
Windows 2000 and 2003 does not support the use of encrypted files with roaming
user profiles.

107
Switching Between Roaming and Local User Profile

Roaming profiles can be switched to local profiles and back to roaming profiles if needed.
change, then click Change Type.
3. In the Change Type dialog box, click Local profile or Roaming profile.
Note
If Roaming profile is unavailable, this indicates that the profile is a local user profile. See
the Windows 2000 system administrator to create a roaming user profile.
If a roaming profile is used on more than one computer simultaneously, the last settings
written to the roaming profile will be preserved, from the last log off.
Add a Home Directory to a User Profile

Administrators can add a home directory to a user profile that specifies a local location or
more commonly a network location. Specifying a network location will allow users home
directories and contents to follow them when roaming to different computers.
2. Locate applicable user account.
3. Right-click on the user account and select Properties.
4. Click the Profile tab.
5. Under Home folder select the Connect button, select the desired drive letter and type the
name of the destination folder or browse the network for it. The path will include the
server name, share name and home directory folder.
6. It is recommended that the %username% environment variable be used for the home
directory folder. Example: \\server1\home\%username%.
Note
Windows 2000 includes a desktop folder called My Documents, which offers a

convenient alternative to home directories but does not replace them. All users have a
My Documents folder in their user profile. The target folder location of the My Documents
folder can be re-directed to a network location.
Mandatory Profiles
17
A mandatory profile is a user profile that is not updated when the user logs off. It is
downloaded to the user's desktop each time the user logs on, and is created by an
administrator and assigned to one or more users to create consistent or job-specific user
profiles.
108
Figure 27. Mandatory Profile
Users cannot modify mandatory user profiles.
They are used to specify settings for individuals or entire groups of users.
Only system administrators can make changes to mandatory user profiles.
Mandatory Profile Benefits

An Information Technology (IT) administrator at a bank could implement mandatory profiles for
all tellers.
This would provide a consistent interface and configuration for all tellers in all locations.
Co-workers and help desk personnel would only have to learn one configuration.
Training personnel can design all training materials on the standard configuration.
Users can reset their interface and configuration by logging off and logging on.
This same methodology can be applied to other job functions within the bank as well. It might
be beneficial to implement mandatory profiles for loan officers, loan processors, new account
personnel, and so on.
Creating a Mandatory User Profile

18
To create a mandatory user profile, rename the NTUser.dat file to NTUser.man in the user
profile folder. This prevents any changes made during a session from being saved when the
user logs off.
Assigning a Roaming Mandatory User Profile

Prior to assigning a roaming mandatory user profile, a properly configured shared network
folder must be created to store the profile.

109
Note
A mandatory profile can be a local profile, but it isnt typically deployed in this way.
1. Create a shared folder on the appropriate server and grant full control to the Everyone
group.
2. Create a folder for the mandatory profile.
3. Copy a pre-configured user profile to the network share as discussed earlier.
4. Rename the NTUser.dat file to NTUser.man.
6. Locate the user account to be assigned the mandatory profile.
7. Right-click on the user account and select Properties.
8. On the Profile tab, in Profile path enter the location of the profile to be assigned.
9. For a network path, use the form <server name>\<shared profiles folder>\<profile
name>. Example: \\server1\profiles\teller
Note
An Administrator must complete this procedure. If the computer is a member of a

Windows 2000 domain, Group Policy settings may prevent this procedure.
NTUser.dat / NTUser.man
These two files contain the HKCU registry keys and settings that get loaded in the registry
when the user logs on. If needed, a SE can import these files into Regedit and view their
contents.
Common Causes of User Profile Problems

19
When a user with a roaming user profile uses multiple computers simultaneously, the settings
from the last time a user logs off from the computer are preserved. This means that if a user is
logged on to two computers simultaneously, the user should log off last from the computer
whose configuration the user wants to preserve. Only the last copy of the user profile is
preserved.
By default, roaming user profiles roam over a fast network link only. Users cannot receive their
roaming user profiles over a slow link, as a message explains to them. If users do not need to
see the message, you can use Group Policy to disable it, or you can set the Timeout for dialog
boxes policy setting in the Group Policy Object Editor to 1 to make it less noticeable. (This
setting is in the Computer Configuration\Administrative Templates\System\User Profiles node
of the Group Policy Object Editor.)
110
Educate users to keep their profile size to a minimum. For example, they can save shortcuts to
documents on their desktop instead of saving the actual document. If you use the Limit profile
size policy setting to manage profile sizes, teach users how to respond to the messages they
receive when they exceed that limitation. If you force users to reduce their profile size before
logging off, show them how to do so safely. The Limit profile size policy setting is available in
the User Configuration\Administrative Templates\System\User Profiles node of the Group
Policy Object Editor.
Other issues can occur if there is an application, such as a virus scanner, or printer driver, that
is not releasing a resource when the profile tries to upload to the profile server. This means
the next time the user logs on, the profile may be the default user profile.
Issues with Profiles:
Slow logons / slow logoffs
832161 You experience a delay when you use your Windows XP computer to log on.
833409 The roaming profile is not loaded after the user uses Terminal Services.
Troubleshooting User Profile Loading and Unloading

Problems
20
Profile load and unload issues are revealed to the end user when their desktop is not what
they expect. When troubleshooting these types of issues, one place to start is by reviewing the
application event log. Errors concerning the profile are located here. The session now enables
you to review the tools available to troubleshoot profile issues.
Using Utilities for Troubleshooting Problems with User Profiles

21
You can use the following utilities to troubleshoot the user profile problems:
Userenv Logging
The Userenv log is created in %Systemroot%\Debug\UserMode\Userenv.log file. If the
Userenv.log exists and is greater than 300 KB, the existing file will be renamed to
Userenv.bak, and a new log file created. Due to its size limitation, the Userenv.log may
overwrite data you are hoping to capture. This happens quite frequently on Terminal Servers
where user logon activity can be quite frequent. To address this issue, there is a tool available
on toolbox, userenv_backup.vbs, that automatically collects the logs very 10 minutes, storing
them in a centralized location.
Tip See the following Microsoft Knowledge Base article for details about enabling increased
verbosity in the log file: 221833: How to enable user environment debug logging in retail
builds of Windows.

111
The Userenv.log tracks the user logging on, the profile creation and access, then the GPO
processing. It then will log the profile unloading when the user logs off. It also logs the time for
each event allowing an SE to track the time for logons and logoffs. Errors in the Userenv log
can be searched for in the KB. This log in conjunction with errors in the application event log
will reveal most profile loading / unloading issues.
Userenv.log Analyzer (UEChk) available on http://toolbox
Especially on Terminal Servers, analyzing userenv.log files for troubleshooting the user logon
can be quite difficult. UEchk analyses the logs and displays them in a manner by parsing the
log files and displaying all user logons. For each userlogon, you can enable or disable all the
different Winlogon threads.
UPHclean
UPHclean should be used when a customer has profile unload issues. Many system and
service processes do work on behalf of users. When the work is done the system or service
process is responsible for releasing handles it has to the user profile hive. If this is not done by
the service as the user logs off the profile cannot be unloaded.
Improper coding either in Microsoft software can cause this problem in code or in 3rd party
software (e.g. printer drivers, virus scanner service, etc). With the information provided by the
system, there is no way to find out what software needs to be corrected to allow profiles to
unload. In the past, these issues have been fixed by code changes to release the registry
handle. The disadvantage of this approach is that in many cases multiple issues (different
code paths) are causing the profiles to not unload. Unless all problem code paths are fixed,
profiles do not unload.
The concept of UPHClean is to deal with these the same way the operating system deals with
other resource issues: when a task is done resources (memory, handles, etc) are
automatically reclaimed. UPHClean accomplishes this simply by monitoring for users to log off
and verifying that unused resources are reclaimed. If they are not it reclaims the resource and
logs its action (you can determine this by searching the event log for source UPHclean). This
approach is superior as it works for any known reason that profiles do not unload and will
keep working to address new unknown issues.
Tip See the following Microsoft Knowledge Base articles for details:
885958: Your Windows Server 2003-based terminal server that uses the UPHClean at
http://support.microsoft.com/?id=885958.
837115: Troubleshooting profile unloads issues at
http://support.microsoft.com/?id=837115.
The customer may complain of seeing the following events on Windows 2000:
event id 1000
Windows cannot unload your registry file. If you have a roaming profile, your settings are not
replicated. Contact your administrator.
DETAIL - Access is denied.
- or Windows cannot unload your registry class file. If you have a roaming profile, your settings are
not replicated. Contact your administrator.
112
DETAIL Access is denied.

- or Windows cannot log you on because the profile cannot be loaded. Contact your network
administrator. This last error is relevant if you find one of the other ones earlier in the
application log.
In WinXP or Win 2003, the application log may have the following events:
Userenv/1517
Windows saved user X registry while an application or service was still using the registry during
log off. The memory used by the user's registry has not been freed. The registry will be
unloaded when it is no longer in use.
This is often caused by services running as a user account, try configuring the services to run
in either the LocalService or NetworkService account.
Userenv/1524
Windows cannot unload your classes registry file - it is still in use by other applications or
services. The file will be unloaded when it is no longer in use.
Userenv/1500
Windows cannot log you on because your profile cannot be loaded. Check that you are
connected to the network, or that your network is functioning correctly. If this problem
persists, contact your network administrator.
This last error (1500) is relevant if you find one of the other ones earlier in the application log.
Note
More information about UPHclean can be found in its Readme.txt.
Eventcomb
UEChk good for terminal servers and analyzing userenv.log files.
Leaktrackdump and DBGview

Leaktrackdump and DBGview are tools that are used, but seldomly, in troubleshooting
applications not releasing resources.
LAB 4: Troubleshooting Common Problems with User

Profiles
22
Configure a custom user profile.
Review your understanding on User Profiles.
Configure roaming user profiles and profile policies.

113
Load and edit a users DAT profile.
Resources
23
The following Microsoft Knowledge Base articles provide additional information about
Troubleshooting User Profile Problems:
221833: How to enable user environment debug logging in retail builds of Windows
885958: Your Windows Server 2003-based terminal server that uses the UPHClean
837115: Troubleshooting profile unloads issues
Summary
24
Types of user profiles.
Common causes of problems with user profiles.
How to troubleshoot problems with loading and unloading user profiles.
How to troubleshoot common problems with user profiles by using different

troubleshooting tools.
114

Account lockout policy disables users accounts if an incorrect password is entered a specified
number of times over a specified period. These policy settings help you to prevent attackers
from guessing users passwords, and they decrease the likelihood of successful attacks on a
network.
Before enabling an account lockout policy, it is important to realize that there is a risk of
unintentionally locking authorized users out of their accounts. Such a result can be quite
costly for your organization, because locked-out users cannot access their user accounts until
the account unlocks automatically after a specified amount of time or until you unlock the
accounts for them.
Password and account lockout settings are designed to protect accounts and data in your
organization by mitigating the threat of brute force guessing of account passwords. Settings in
the Account Lockout and Password Policy nodes of the Default Domain policy settings enable
account lockout and control how account lockout operates.
Before You Begin

1
Active Directorys physical and logical structure.
Group Policy and its application.
MPS Reports and the data it collects.
What You Will Learn

2
Describe different Password Policy settings and Account Lockout Policy settings.
Describe the types of attacks on a domain.
Explain the domain controller behavior during account lockout.
Explain how to troubleshoot common account lockout problems.
Describe the purpose of the utilities that can be used to troubleshoot account lockout
problems.
Examining Password Policies

3
Password policies are used for domain accounts or local user accounts. They determine
settings for passwords, such as enforcement and lifetimes. Password policies are set in the
Default Domain policy under Computer Configuration\Windows Settings\Security
Settings\Account Policies\Password Policy\.
115
Enforce Password History

This security setting determines the number of unique new passwords that have to be
associated with a user account before an old password can be reused. The value must be
between 0 and 24 passwords. On domain controllers, the default is 1 in Windows 2000 and
24 in Windows 2003.
This policy enables administrators to enhance security by ensuring that old passwords are not
reused continually. To maintain the effectiveness of the password history, do not allow
passwords to be changed immediately after they were just changed by also enabling the
Minimum Password Age security policy setting (see below).
Maximum Password Age

This security setting determines the period of time (in days) that a password can be used
before the system requires the user to change it. You can set passwords to expire after a
number of days between 1 and 999, or you can specify that passwords never expire by setting
the number of days to 0. If the maximum password age is between 1 and 999 days, the
Minimum password age must be less than the maximum password age. If the maximum
password age is set to 0, the minimum password age can be any value between 0 and 998
days. The default is 42 for both Windows 2000 and Windows 2003.
Note
It is a security best practice to have passwords expire every 30 to 90 days, depending on

your environment. This way, an attacker has a limited amount of time in which to crack a
user's password and have access to your network resources.
Common Issue with Maximum Password Age

One of the common issues with this setting is discussed below:
Issue
How do you implement a maximum password age when you have everyone in your
organization having the same password for years?
Answer
There are two methods:
1. Start a schedule with an extremely high password age. Each week, slowly bring it down.
For example:
a.
You start the first day at 998.
b.
Next week or interval, you rule it down to 800.
c.
Next interval, you do 750 or 700 depending on the number of users that have
passwords that are old.
d.
Do this till you get down to the setting you want to keep.
2. By organizational unit or site, make the users' passwords expire and change by checking
User must change password at next logon in the user properties.
116
Minimum Password Age

This security setting determines the period of time (in days) that a password must be used
before the user can change it. You can set a value between 1 and 998 days, or you can allow
changes immediately by setting the number of days to 0.
The minimum password age must be less than the Maximum password age, unless the
maximum password age is set to 0, indicating that passwords will never expire. If the
maximum password age is set to 0, the minimum password age can be set to any value
between 0 and 998.
Configure the minimum password age to be more than 0 if you want Enforce password history
to be effective. Without a minimum password age, users can cycle through passwords
repeatedly until they get to an old favorite. The default setting does not follow this
recommendation, so that an administrator can specify a password for a user and then require
the user to change the administrator-defined password when the user logs on. If the password
history is set to 0, the user does not have to choose a new password. For this reason, Enforce
password history is set to 1 by default.
The default setting in Windows 2000 is 0, but in Windows 2003, it is 1.
Minimum Password Length

This security setting determines the least number of characters that a password for a user
account may contain. You can set a value of between 1 and 14 characters, or you can
establish that no password is required by setting the number of characters to 0. The default
for Windows 2000 is zero, but in Windows 2003, it is 7.
Password Must Meet Complexity Requirements

This security setting determines whether passwords must meet complexity requirements.
If this policy is enabled, passwords must meet the following minimum requirements:
Not contain all or part of the user's account name
Be at least six characters in length
Contain characters from three of the following four categories:
English uppercase characters (A through Z)
English lowercase characters (a through z)
Base 10 digits (0 through 9)
Non-alphabetic characters (for example, !, $, #, %)
Complexity requirements are enforced when passwords are changed or created.

With the latest patch level, the msgina will give you the following prompt when you set a
password does not meet the complexity:
Your password must be at least 6 characters; cannot repeat any of your previous X passwords;
must contain capitals; numerals or punctuation; and cannot contain your account or full
name. Please type a different password. Type a password that meets the requirements in both
text boxes.
Custom password filters can be created by the customer or bought from third parties. In
Windows 2000, this setting is disabled by default. In Windows 2003, it is enabled.
117
Password complexity is a giant step to a secure network. Here is an example of the

permutations that are available given a password length. The odds are better playing the
lottery.
6 Characters = 689,869,781,056
7 Characters = 64,847,759,419,264
8 Characters = 6,095,689,385,410,820
9 Characters = 572,994,802,228,617,000
10 Characters = 53,861,511,409,490,000,000
Store Passwords Using Reversible Encryption

This security setting determines whether the operating system stores passwords using
reversible encryption.
This policy provides support for applications that use protocols that require knowledge of the
user's password for authentication purposes. Storing passwords using reversible encryption is
essentially the same as storing plaintext versions of the passwords.
For this reason, this policy should never be enabled unless application requirements outweigh
the need to protect password information.
This policy is required when using Challenge-Handshake Authentication Protocol (CHAP)
authentication through remote access or Internet Authentication Services (IAS). It is also
required when using Digest Authentication in Internet Information Services (IIS).
By default, this policy is disabled in both Windows 2000 and Windows 2003.
Examining Account Lockout Policy

4
Account lockout policies are used for domain accounts or local user accounts. They determine
the circumstances and length of time that an account will be locked out of the system. You
can set account lockout policies for the domain in the Default Domain policy: Computer
Configuration\Windows Settings\Security Settings\Account Policies\Account Lockout Policy\.
Account Lockout Duration

This security setting determines the number of minutes a locked-out account remains locked
out before automatically becoming unlocked. The available range is from 0 minutes through
99,999 minutes. If you set the account lockout duration to 0, the account will be locked out
until an administrator explicitly unlocks it.
If an account lockout threshold is defined, the account lockout duration must be greater than
or equal to the reset time.
The default is none for both Windows 2000 and Windows 2003, because this policy setting
only has meaning when an account lockout threshold is specified.
Depending on the settings, you can lockout the administrator. It is preferred to have a lockout
duration that will unlock the user automatically. You will have an insurance policy that if
someone has set the administrator lock you can recover without a restore from backup.
118
Account Lockout Threshold

This security setting determines the number of failed logon attempts that causes a user
account to be locked out. A locked-out account cannot be used until it is reset by an
administrator or until the lockout duration for the account has expired. You can set a value
between 0 and 999 failed logon attempts. If you set the value to 0, the account will never be
locked out.
Failed password attempts against workstations or member servers that have been locked
using either CTRL+ALT+DELETE or password-protected screen savers count as failed logon
attempts.
The default setting in Windows 2000 is disabled. In Windows 2003 the default is zero.
Note
Microsoft recommends that the account lockout threshold be set to 10 or above. The
Security Hardening guide recommends that you set the value at 50.
Microsoft has tested the account lockout features against many applications, user
environmental factors, as well as the mathematical model behind the numbers in terms of
balance between security and administrative overhead.
Thresholds below 10 can result in a large number of lockouts due to user typing errors. Also,
many applications do a number of authentication attempts before refreshing their cache,
meaning a low account lockout threshold will lock the user out before the cache is refreshed.
Many applications will also send authentication requests on every protocol, causing multiple
attempts with one logon.
By changing the threshold to a larger number, you lower the number of false positives,
lowering the administrative burden of a lockout policy, and making it easier to spot potential
attacks, configuration errors or application errors.
Warning a low threshold setting can actually achieve less security and a higher cost of
ownership. If the help desk is unlocking people all day long then they are not going to take the
real lockouts seriously.
Reset Account Lockout Counter

This security setting determines the number of minutes that must elapse after a failed logon
attempt before the failed logon attempt counter is reset to 0 bad logon attempts. The
available range is 1 minute to 99,999 minutes.
If an account lockout threshold is defined, this reset time must be less than or equal to the
Account lockout duration.
The default setting in Windows 2000 is disabled. In Windows 2003, the default is zero. This
policy setting only has meaning when an account lockout threshold is specified.
Examining Types of Attacks on a Domain

5
Currently, several attack methods are based on guessing weak passwords by using dictionary
and brute force attacks. A dictionary attack occurs when a malicious user tries known words
that are in the dictionary and a number of common password names to try and guess a
password. A brute force attack occurs when a malicious user tries all of the possible
permutations until one is successful.
119
Dictionary Versus Brute Force

Because most users prefer passwords that they can easily remember, dictionary attacks are
often an effective method for a malicious user to find a password in significantly less time
than they would with brute force attacks. Therefore, the strength of a password depends on
how many characters are in the password, how well the password is protected from being
revealed by the owner, how well the password is protected if it is intercepted by a malicious
user on the network, and how difficult the password is to guess. Even good passwords that are
protected by cryptography on the network and that are not subject to dictionary attacks can be
discovered by brute force in a few weeks or months by a malicious user who intercepts the
password on the network.
Frequently, a malicious user will guess a number of passwords during a password-based
attack. To help prevent the attacks from being successful, you can configure account lockout
settings. The result of this configuration is that the associated account is temporarily disabled
after a specified number of incorrect passwords are tried. This helps to prevent a successful
attack by preventing the account from being used. However, a legitimate user cannot use that
account until it is unlocked.
Examining Domain Controller Behavior

6
The majority of Active Directory replication in Windows 2000 takes place at predefined
intervals. However, select changes to objects in Active Directory must take place immediately
to allow for proper administration of a domain.
How Domain Controllers Verify Passwords

7
To illustrate the authentication process, the following diagram describes the steps that occur
when a logon attempt does not work.
Figure 28. Steps That Occur When a Logon Does not Work
1. The client computer presents the user logon information to a domain controller. This
includes the users account name and a cryptographic hash of their password. This
information can be sent to any domain controller and is typically sent to the domain
controller that is identified as the closest domain controller to the client computer.
120
2. When a domain controller detects that an authentication attempt did not work and a
condition of STATUS_WRONG_PASSWORD, STATUS_PASSWORD_EXPIRED,
STATUS_PASSWORD_MUST_CHANGE, or STATUS_ACCOUNT_LOCKED_OUT is returned,
the domain controller forwards the authentication attempt to the primary domain
controller (PDC) emulator operations master. Essentially, the domain controller queries
the PDC to authoritatively determine if the password is current. The domain controller
queries the PDC for this information because the domain controller may not have the
most current password for the user but, by design, the PDC emulator operations master
always has the most current password.
3. The authentication request is retried by the PDC emulator operations master to verify that
the password is correct. If the PDC emulator operations master rejects the bad password,
the PDC emulator operations master increments the badPwdCount attribute for that user
object. The PDC is the authority on the user's password validity.
4. The failed logon result information is sent by the PDC emulator operations master to the
authenticating domain controller.
5. The authenticating domain controller also increments its copy of the badPwdCount
attribute for the user object.
6. The authenticating domain controller then sends a response to the client computer that
notifies the domain controller that the logon attempt did not work.
As long as that user, program, or service continues to send incorrect credentials to the
authenticating domain controller, logon attempts that failed because of an incorrect password
continue to be forwarded to the PDC until the threshold value for incorrect logon attempts is
reached (if you set it in a policy). When this occurs, the account is locked out.
Replication Triggers
8
When you change a password, it is sent over Netlogon's secure channel to the PDC operations
master. Specifically, the domain controller makes a remote procedure call (RPC) to the PDC
operations master that includes the user name and new password information. The PDC
operations master then locally stores this value.
Immediate replication between Windows 2000 domain controllers is caused by the following
events:
Lockout of an account
Modification of a Local Security Authority (LSA) secret
State changes of the Relative ID (RID) Manager
The following events are not urgent replications in Windows 2000 domains:
Changing the account lockout policy
Changing the domain password policy
Changing the password on a computer account
Domain trust passwords

121
Changes to account passwords can be made at any domain controller because all full replicas
of a given domain are writable. This can lead to unexpected behavior when a password is
changed by a user at domain controller A who then attempts to log on with authentication by
domain controller B. If the password has not been replicated from A to B, the logon attempt
does not succeed. In Windows NT 4.0, if authentication does not succeed at the BDC, the
authentication is forwarded to the PDC. Windows 2000 exhibits similar behavior, as follows:
A password change by a Directory Service-aware client at a domain controller is "pushed" by
that domain controller to the PDC FSMO role owner on a best-effort basis. This push of the
password to the PDC can be disabled on WAN links with the following registry key:
HKLM\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters
Registry value: AvoidPdcOnWan
Registry type: REG_DWORD
Registry value data: 0 (or value not present) or 1
FALSE = 0 or value not present (to disable)
TRUE = 1 (to enable)
Default: (value is not present)
Platform: Only Windows 2000 Domain Controllers
The password change is propagated to other domain controllers in the domain using normal
replication values.
When authentication does not succeed at a domain controller other than the PDC FSMO role
owner, the request is retried at the PDC FSMO role owner.
Down-level clients attempt to contact the PDC to make a password change as they do in
Windows NT 4.0.
Kerberos Negative Caching

9
When a DC that is not the PDC fails an authentication with STATUS_WRONG_PASSWORD,

STATUS_PASSWORD_EXPIRED, STATUS_PASSWORD_MUST_CHANGE or
STATUS_ACCOUNT_LOCKED_OUT (collectively referred to later as BAD_PASSWORD_STATUS),
the logon is retried at the PDC. In Windows 2000 Service Pack 2 (SP2), the Kerberos
authentication package implements a negative-caching mechanism that would stop the
forwarding of requests to the PDC if any of the preceding BAD_PASSWORD_STATUS statuses
were returned after 1 logon request for a period of 5 minutes. This was implemented to help
reduce the number of logon requests handled on the PDC.
New Features in the Windows Server 2003 Family

10
In the Windows Server 2003 family of operating systems, Microsoft has improved the function
of the Account Lockout feature on both servers and client computers.
122
Computers Running Windows Server 2003 that Act as Network

Servers as well as 2000 SP 4
To improve the experience for users and to decrease the overall total cost of ownership,
Microsoft made the following changes to the behavior of domain controllers in the Windows
Server 2003 family:
Password History Check (N-2)

Before a Windows Server 2003 operating system increments badPwdCount, it checks the
invalid password against the password history. If the password is the same as one of the
last two entries that are in the password history, badPwdCount is not incremented for
both NTLM and the Kerberos protocol. This change to domain controllers should reduce
the number of lockouts that occur because of user error.
Single User Object On Demand Replication

The updated replication scheme allows the domain controller to contact the PDC
operations master to request an update of the user object that failed authentication
because of an incorrect password. This helps to ensure that the authenticating domain
controller receives the most current user account information as quickly as possible.
Optimized Replication Frequency

The default frequency for replication between sites is to replicate every 15 seconds with
a 3-second offset to stagger the replication interval. This optimization improves the
replication of a password change in a site because it decreases the chances that the
domain controller would have to contact the PDC operations master. This does not apply
to windows 2000 sp 4. However you can manually change the replication window to
match that of windows 2003
Troubleshooting Account Lockout Problems

11
In an environment where you set the account lockout feature, you may notice a large number
of lockouts that occur. To determine if these lockouts are false lockouts or a real attack:
1. Verify that the domain controllers and client computers are up-to-date with service packs
and hotfixes.
2. Configure your computers to capture data:
Enable auditing at the domain level and domain controller OU.
Enable Netlogon logging.
Enable Kerberos logging if you have an issue with Kerberos.
3. Analyze data from the Security event log files and the Netlogon log files to help you
determine where the lockouts are occurring and why.
4. Analyze the event logs on the computer that is generating the account lockouts to
determine the cause.
One excellent resource for troubleshooting account lockouts is the troubleshooter available on
http://fasttrack. Available in the troubleshooter are scripts. Both can be sent to a customer.
One allows the customer to view all locked out accounts. The other unlocks all locked out
accounts. Both of these scripts are useful in a denial of service scenario.

123
Recommended Service Packs and Hotfixes

12
Security issues in Windows operating systems are discovered and fixed often. These fixes
often have an impact on account lockout and password policy features, as well as their
dependent components. Therefore, you should apply the latest service packs and hotfixes to
all of the domain controllers, servers, and clients to ensure that the account security settings
that you want are applied and to ensure that the domain controllers and operating systems
are up-to-date. Note that service packs resolve groups of issues and hotfixes resolve a specific
issue.
You should have an ongoing strategy to keep your computers updated and protected against
viruses, trojans, and so on, that may use vulnerabilities that are already fixed. Because these
issues are discovered and fixed on an ongoing basis, they are not listed in this document. For
more information, see Service Packs and Hotfixes Available to Resolve Account Lockout
Issues in the Microsoft Knowledge Base.
Common Causes for Account Lockouts

13
This section describes some of the common causes for account lockouts The common
troubleshooting steps and resolutions for account lockouts are also described in this section.
To avoid false lockouts, check each computer on which a lockout occurred for the following
behaviors:
Programs
Many programs cache credentials or keep active threads that retain the credentials after
a user changes their password.
Service Accounts
Service account passwords are cached by the service control manager on member
computers that use the account as well as domain controllers. If you reset the password
for a service account and you do not reset the password in the service control manager,
account lockouts for the service account occur. This is because the computers that use
this account typically retry logon authentication by using the previous password. To
determine whether this is occurring, look for a pattern in the Netlogon log files and in the
event log files on member computers. You can then configure the security control
manager to use the new password and avoid future account lockouts.
Bad Password Threshold is Set too Low

This is one of the most common configuration issues. Many companies set the Bad
Password Threshold registry value to a value lower than the default value of 10. If you set
this value too low, false lockouts occur when programs automatically retry invalid
passwords. Microsoft recommends that you leave this value at its default value of 10. For
more information, see "Choosing Account Lockout Settings for Your Deployment" in this
document.
124
Note
User Logging on to Multiple Computers

A user may log onto multiple computers at one time. Programs that are running on those
computers may access network resources with the user credentials of that user who is
currently logged on. If the user changes their password on one of the computers,
programs that are running on the other computers may continue to use the original
password. Because those programs authenticate when they request access to network
resources, the old password continues to be used and the users account becomes
locked out. To ensure that this behavior does not occur, users should log off of all
computers, change the password from a single location, and then log off and back on.
Computers running Windows XP or a member of the Windows Server 2003 family

automatically detect when the users password has changed and prompt the user to lock
and unlock the computer to obtain the current password. No logon and logoff is required
for users using these computers.
Note
Stored User Names and Passwords Retains Redundant Credentials

If any of the saved credentials are the same as the logon credential, you should delete
those credentials. The credentials are redundant because Windows tries the logon
credentials when explicit credentials are not found. To delete logon credentials, use the
Stored User Names and Passwords tool. For more information on Stored User Names and
Passwords, see online help in Windows XP and the Windows Server 2003 family.
Computers that are running Windows 95, Windows 98, or Windows Millennium Edition do
not have a Stored User Names and Passwords file. Instead, you should delete the users
.pwl file. This file is named Username.pwl, where username is the users logon name. The
file is stored in the Systemroot folder.
Scheduled Tasks
Scheduled processes may be configured to using credentials that have expired.
Persistent Drive Mappings

Persistent drives may have been established with credentials that subsequently expired.
If the user types explicit credentials when they try to connect to a share, the credential is
not persistent unless it is explicitly saved by Stored User Names and Passwords. Every
time that the user logs off the network, logs on to the network, or restarts the computer,
the authentication attempt fails when Windows attempts to restore the connection
because there are no stored credentials. To avoid this behavior, configure net use so that
is does not make persistent connections. To do this, at a command prompt, type net use
/persistent:no. Alternately, to ensure current credentials are used for persistent drives,
disconnect and reconnect the persistent drive.
Active Directory Replication

User properties must replicate between domain controllers to ensure that account
lockout information is processed properly. You should verify that proper Active Directory
replication is occurring.
Disconnected Terminal Server Sessions

Disconnected Terminal Server sessions may be running a process that accesses network
resources with outdated authentication information. A disconnected session can have
the same effect as a user with multiple interactive logons and cause account lockout by
using the outdated credentials. The only difference between a disconnected session and
a user who is logged onto multiple computers is that the source of the lockout comes
from a single computer that is running Terminal Services.

125
Service Accounts
By default, most computer services are configured to start in the security context of the
Local System account. However, you can manually configure a service to use a specific
user account and password. If you configure a service to start with a specific user
account and that accounts password is changed, the service logon property must be
updated with the new password or that service may lock out the account.
Other Potential Issues

14
Some additional considerations regarding account lockout are described below.
Account Lockout for Remote Connections

The account lockout feature that is discussed in this paper is independent of the account
lockout feature for remote connections, such as in the Routing and Remote Access
service and Microsoft Internet Information Services (IIS). These services and programs
may provide their own unrelated account lockout features.
Internet Information Services

By default, IIS uses a token-caching mechanism that locally caches user account
authentication information. If lockouts are limited to users who try to gain access to
Exchange mailboxes through Outlook Web Access and IIS, you can resolve the lockout by
resetting the IIS token cache. For more information, see "Mailbox Access via OWA
Depends on IIS Token Cache" in the Microsoft Knowledge Base.
MSN Messenger and Microsoft Outlook

If a user changes their domain password through Microsoft Outlook and the computer is
running MSN Messenger, the client may become locked out. To resolve this behavior, see
"MSN Messenger May Cause Domain Account Lockout After a Password" in the Microsoft
Knowledge Base.
Maintaining and Monitoring Account Lockout

15
After you configure the account lockout options that you want, set up the computers so that
you can capture more data about the accounts that are being locked out. This section
describes how to enable auditing, Netlogon logging, and Kerberos logging, as well as which
computers to retrieve the logs from. After you configure the logging and capture the
appropriate data, this section will show you how to analyze the information so that you can
ensure account lockout settings are working and identify attacks.
Enable Auditing at the Domain Level and Domain Controllers OU

16
The following sections describe how to enable auditing at the domain level for different
operating systems. To effectively troubleshoot account lockout, enable auditing at the domain
level for the following events:
Account Logon Events Failure
Account Management Success
Logon Events Failure
Process tracking Success (only relevant on Windows Server 2003)
126
Windows 2000 and Windows Server 2003 Domains

The Audit Policy settings are located in the Default Domain policy settings. To view the
Auditing policy settings, in the Group Policy MMC, double-click Computer Configuration,
double-click Windows Settings, double-click Security Settings, double-click Local Policies, and
then double-click Audit Policy.
Netlogon Logging
17
You can use Netlogon logging to capture Netlogon and NTLM events. It is recommended that
you configure Netlogon logging in a Windows 2000 domain that has Windows 2000 clients.
You must configure Netlogon logging on the primary domain controller (PDC) and on any other
domain controllers that are involved in user authentication. To determine the authenticating
domain controller, at a command prompt, type set l.
To enable Netlogon logging on computers that are running Windows 2000 Server, at a
command prompt, type nltest /dbflag:2080ffff. The log file is created in
<%systemroot%>\Debug\Netlogon.log. If the log file is not in that location, stop and restart
the Netlogon service on that computer. To do this, at a command prompt, type net stop
netlogon & net start netlogon. For more information, see Enabling Debug Logging for the
Netlogon Service on the Microsoft Knowledge Base.
Note
For more information, see Enabling Debug Logging for the Netlogon Service on the
Microsoft Knowledge Base.
109626 Enabling debug logging for the Net Logon service
Kerberos Logging
18
In very rare cases, you may have to enable Kerberos logging.
Caution ONLY RECOMMENDED IF YOU HAVE KERBEROS BROKEN. Because a bad password
occurs over Kerberos does not mean you have a Kerberos issue. Warnings in the logs
take long to go through and they have many errors by design so you may end up
explaining why an error is by design versus troubleshooting the issue.
If account lockouts involve Kerberos clients that are running a member of the Windows 2000
family or later, you can enable Kerberos logging on those client computers. You would typically
perform this step after you have determined that there is an authentication issue that is
related to Kerberos.
To enable Kerberos event logging on a computer:
1. Click Start, click Run, type regedit, and then press ENTER.
2. Add the
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters
registry value to the registry key:
127
Registry value: LogLevel
Value type: REG_DWORD
Value data: 0x1
If the Parameters registry key does not exist, create it.

3. Close Registry Editor and restart the computer.
Caution Incorrectly editing the registry may severely damage your system. Before making changes
to the registry, you should back up any valued data on the computer.
The logging process may degrade performance. Therefore, you should disable the logging
process after you capture the events that you want in the log file. To disable logging, remove
the LogLevel registry value, and then restart the computer.
To disable Kerberos event logging on a computer:
1. Click Start, click Run, type regedit, and then press ENTER.
2. Delete the
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters\
LogLevel registry value.
3. Close Registry Editor and restart the computer.
Caution Incorrectly editing the registry may severely damage your system. Before making changes
to the registry, you should back up any valued data on the computer.
For more information, see the HOW TO: Enable Kerberos Event Logging in the Microsoft
Knowledge Base.
Event and Netlogon Log Retrieval

19
After you set the auditing and logging, wait until account lockouts occur. When the account
lockout occurs, retrieve both the Security event log and the System event log (use
EventCombMT to gather the event logs), as well as the Netlogon logs for all of the computers
that are involved with the client's lockout. This includes the PDC emulator operations master,
the authenticating domain controller, and all of the client computers that have user sessions
for the locked-out user.
To determine the domain controllers that are involved with the lockout, run the
LockoutStatus.exe, available via the Microsoft Website and in the 2003 resource kit, tool and
specify the user account that is locked out. This tool gathers and displays information about
the specified user account from all the domain controllers in the domain. In addition, the tool
displays the user's badPwdCount value on each domain controller. The domain controllers
that have a badPwdCount value that reflects the bad password threshold setting for the
domain are the domain controllers that are involved in the lockout. These domain controllers
always include the PDC emulator operations master.
128
The badPwdCount value may appear to be higher than the threshold because of the way that
passwords are chained to the PDC emulator operations master. When a bad password is
presented by a user or program, both the authenticating domain controller and the PDC
emulator operations master increment their badPwdCount value for that account. When Active
Directory replication occurs, this can result in an increased value. However, the resultthe
account becoming locked outremains the same.
You can also use the EventCombMT.exe tool to gather specific event log data from multiple
computers to one central location. For more information about both the EventCombMT.exe
and LockoutStatus.exe tools, see the section on Using Troubleshooting Account Lockout
Utilities.
Analyzing Log File Information

20
The previous section described the processes that you can use to enable log files to record
information that is lockout-specific on your computers. This section focuses on analyzing
those log files and determining what behavior occurred that created the log files and caused
the issue that you are trying to resolve. This section also describes how to resolve the issues
that you find when you analyze the log files.
Analyzing Netlogon Log Files

Before you start to analyze the Netlogon log files, you should be familiar with the
authentication. This process will be covered in detail in the next module, although, this section
does have a brief description of the NTLM authentication process. Note a similar chain of
events occurs during Kerberos authentication.
The following sample scenario discusses what occurs when a user who is on a client computer
tries to gain accesses to a resource that is on a file server in the same domain as the user
account. In this process:
1. User credentials are passed to the file server. This is displayed in the Network Logon
section in the Netlogon.log file.
2. The file server tries to authenticate the user, but the file server has to forward the
credentials to the authenticating domain controller for validation because this account is
a domain user account. This behavior is displayed as Transitive Network logon in the
Netlogon.log file and is commonly referred to as pass-through authentication.
3. If the password is incorrect or if it is not the same as the password that is stored by the
authenticating domain controller, the authenticating domain controller chains the
credentials to the PDC for validation. This is displayed as Transitive Network Logon in the
Netlogon.log file.
The following sections provide a sample Netlogon.log file output from the following three
computers:
The PDC operations master for the domain: DC002
The authenticating domain controller: DC003
The member server: MEMSERVER01

129
The sample output sections show the following participants involved in network
authentication:
Domain name: Tailspintoys
Logon user name: User1
Logon computer name: Computer-006
Transitive Network Logon (Pass-Through Authentication)

Sample from the DC002 PDC emulator Netlogon log file
29-Mar 14:28:30 Transitive Network logon
Computer-006 (via DC003) 0xC000006A
Computer-006 (via DC003) 0xC0000234
Tailspintoys\User1
Tailspintoys\User1
Tailspintoys\User1
Tailspintoys\User1
Tailspintoys\User1
Tailspintoys\User1
Sample from the DC003 authentication domain controller Netlogon log file
29-Mar 14:28:30 Transitive Network logon Tailspintoys\User1
Computer-006 (via MEMSERVER01) 0xC000006A
Computer-006 (via MEMSERVER01) 0xC0000234
Sample from the MEMSERVER01 member server Netlogon log file

29-Mar 14:28:31 Network
Computer-006 0xC000006A
Computer-006 0xC0000234
130
logon Tailspintoys\User1
These Netlogon.log file samples provide an example of the information contained in the
Netlogon logs. This information is used to trace the account lockout from the domain
controller back to the member server on which a user or application tried to gain access
with the incorrect credentials.
Even though the log file does not display the exact process that is sending the incorrect
credentials, Netlogon log files do provide the following information to help you
troubleshoot the lockout:
Netlogon output displays the number of unsuccessful logon attempts (0xC000006A)

for a user's account in a certain time period. Logs in which there are several
0xC000006A events in one second indicate that the lockout is most likely caused by
a process, program, or script that is sending incorrect credentials.
Netlogon output provides a complete picture of all computers that are involved in
the account lockout. You can narrow down the culprit by determining the common
elements, such as programs, among the computers involved. For example, from the
Netlogon output above, after you determined that MEMSERVER01 was common to
all user lockouts, the troubleshooting focus changed to the particular network
services or user accounts that are used by MEMSERVER01.
In this example, MEMSERVER01 is the Microsoft Exchange server. After you examine
the Microsoft Outlook client and Exchange server settings, you may want to use the
information that is in the following two articles to help resolve the issue. These
articles describe how to remove unnecessary RPC bindings from the Exchange
server. For example, remove Named Pipe support if there is no client that requires
the named pipes.
Outlook locks your account because of a Directory Service Referral with

Exchange 2000 Server in the Microsoft Knowledge Base.
Unexpected account lockouts caused when logging on to Outlook from an

Untrusted Domain in the Microsoft Knowledge Base.
If the Netlogon logs from all domain controllers from the time of lockout but do not
display data that pertains to any of the locked-out user accounts that you are
analyzing, then NTLM authentication is not involved in the lockouts. This normally
indicates that the authentication issues are between computers running Windows
2000 or later, because earlier versions of Windows used NTLM authentication
exclusively. You should focus on Kerberos authentication troubleshooting by using
Kerberos logging and examining the Security event logs
Netlogon Log File Error Codes

Each event in the Netlogon log contains a corresponding error code. The following table
describes these error codes.
Table 9. Netlogon Log Error Codes
Log Code
Description
0x0
Successful login.
0xC0000064
The specified user does not exist.
0xC000006A
The value provided as the current password

is not correct.
0xC000006C
Password policy not met.

131
Note
Log Code
Description
0xC000006D
The attempted logon is invalid due to a bad

user name.
0xC000006E
User account restriction has prevented

successful login.
0xC000006F
The user account has time restrictions and

may not be logged onto at this time.
0xC0000070
The user is restricted and may not log on

from the source workstation.
0xC0000071
The user account's password has expired.
0xC0000072
The user account is currently disabled.
0xC000009A
Insufficient system resources.
0xC0000193
The user's account has expired.
0xC0000224
User must change his password before he

logs on the first time.
0xC0000234
The user account has been automatically

locked.
Many of these codes provide information in the log file that is redundant with the
corresponding Netlogon event log. This allows you to analyze the events in a variety of
ways.
Analyzing Event Logs

21
You cannot determine the authentication type that was used when an account is locked out
unless you enable Netlogon logging before the account lockout. However, because of
differences in authentication, there may be situations in which Netlogon logging does not
capture the data that you need to determine which computers were involved in an account
lockout. Configuring the appropriate computers to create event logs may provide additional
information in these situations.
Before the problems occur, you should enable security auditing on all computers that might be
involved in the account lockout event. Enabling auditing and Netlogon log files is discussed
elsewhere in this document. If the auditing is not configured before the initial error occurs, it
can be done afterwards.
Once the account lockout occurs, there are several tasks that should be completed to help
identify the cause of the issue:
1. Run EventCombMT or get MPS Reports to pull the security logs. The following article will
assist you in running EventCombMT: http://support.microsoft.com/?id=824209
Obtain these log files from the PDC emulator operations master and all domain
controllers that may be involved in the account lockout. Get both the Security and System
event logs from all of the computers that are locked out if those computers were logged
on when the lockout occurred.
132
Note
Pulling the EVT logs and going through them is a time consuming process. You can run a
text search on the text files like findstr (see examples below) to parse through the logs.
Also, you can import the text files into excel and autofilter them.
2. Look for Event 675 (Preauthentication Failures) in the Security event log for the domain
controllers for the locked-out user account. This event displays the IP address of the
client computer from which the incorrect credentials were sent. When you view these
events in the Security event log from the PDC, an IP address with Event 675 may be the
IP address of another domain controller because of password chaining from other
domain controllers. If this is true, obtain the Security event log from that domain
controller to see the Event 675. The IP address that is listed in that Event 675 should be
the IP address for the client computer that sent the invalid credential.
3. After you know which client computer is sending the invalid credentials, determine the
services, programs, and mapped network drives on that computer. If this information
does not reveal the source of the account lockout, perform network traces from that
client computer to isolate the exact source of the lockout.
Example Event Log Entry: Incorrect Password Processed by Kerberos

The following example displays a sample Event 675 in the Security event log from the PDC
emulator operations master:
Event Type: Failure Audit
Event Source: Security
Event Category: Account Logon
Event ID: 675
Date: 12/5/2001
Time: 5:47:26 PM
User: NT AUTHORITY\SYSTEM
Computer: COMPUTER-006
Description:
Pre-authentication failed:
User Name: user1
User ID: %{S-1-5-21-4235101579-1759906425-16398432-1114}
Service Name: krbtgt/Tailspintoys.com
Pre-Authentication Type: 0x2
Failure Code: 0x18
Client Address: 172.16.1.85
Example Event Log Entry: Account is Locked Out

The following example displays a sample of Event 644, which indicates that the account is
locked out:
Event Type: Success Audit
Event Category: Account Management
Event ID: 644
Date: 12/5/2001
Time: 5:47:26 PM
User: Everyone
Description:
User Account Locked Out:
Target Account Name: user1
133
Target
Caller
Caller
Caller
Caller
Note
Account ID:%{S-1-5-21-4235101579-1759906425-16398432-1114}
Machine Name:COMPUTER-006
User Name:USER1$
Domain:TAILSPINTOYS
Logon ID:(0x0,0x3E7)
For more information on account lockout events, see "Audit Account Lockout" on the
Microsoft TechNet Web site.
Example Event Log Entry: Logon Failure

The following example displays a sample of Event 529, which results from an unsuccessful
logon attempt due to an invalid user name or password. This event is often useful in
identifying the source of the lockout:
Event Type: Failure Audit
Event Category: Logon/Logoff
Event ID: 529
Date: 12/21/2001
Time: 2:05:20 PM
Description:
Logon Failure:
Reason: Unknown user name or bad password
User Name: user1
Domain: Tailspintoys
Logon Type: 2
Logon Process: User32
Authentication Package:
Negotiate
Workstation Name: COMPUTER-006
This event contains several useful elements. It identifies the name of the computer that is
attempting authentication, as well as the user and domain name. It also displays the logon
type, which is discussed later in this section.
When Event 529 is logged, you should look for patterns in the event. Determine if there are
several 529 events logged and determine if they all occur in one second or if they occur at
specific time intervals. If so, there is a process or service that is running on the computer that
is sending incorrect credentials. Look at the Logon Process and Logon Type entries in the log
to determine the type of process that is passing incorrect credentials and to determine how
the process is logging on.
Example Event Log Entry: Account Is Disabled
When there is an attempt to logon using a disabled account, a specific event is created in the
event log. This can help you quickly identify intruders, because normal operations should not
allow for the use of locked out accounts. You should analyze and respond quickly to these
events.
Event
Event
Event
Event
Date:
Time:
Type: Failure Audit

Source: Security
Category: Logon/Logoff
ID: 531
12/21/2001
2:05:21 PM
134
Description:
Logon Failure:
Reason: Account currently disabled
User Name: user1
Domain: TAILSPINTOYS
Logon Type: 2
Logon Process: User32
Authentication Package: Negotiate
Event that you get when you should lockout the administrator and the
settings prevent it.
Event ID: 12294
Source: SAM
Description: The SAM database was unable to lockout the account of # due
to a resource error, such as a hard disk write failure (the specific
error code is in the error data). Accounts are locked after a certain
number of bad passwords are provided so please consider resetting the
password of the account mentioned above.
DATA: 0000: a5 02 00 c0
Using Account Lockout Tools

22
After you determine the pattern for the account lockouts and narrow down your scope to a
specific client computer or member server, you should gather detailed information about all of
the programs and services that are running on that computer. Some of the information that
you should obtain includes:
Mapped network drives
Logon scripts that map network drives
RunAs shortcuts
Accounts that are used for service account logons
Processes on the client computers
Programs that may pass user credentials to a centralized network program or middle-tier
application layer
The following sections discuss the tools that you can use to help you gather information from
the network environment.
Note
The following tools are included with the ALTools.exe package that is available at Account
Lockout and Management Tools on the Microsoft Web site.

135
The Lockoutstatus.exe Tool

23
The LockoutStatus.exe displays information about a locked out account. It does this by
gathering account lockout-specific information from Active Directory.
The following list describes the different information that is displayed by the tool:
DC Name
Displays all domain controllers that are in the domain.
Site
Displays the sites in which the domain controllers reside.
UserState
Displays the status of the user and whether that user is locked out of their account.
Bad Pwd Count:

Displays the number of bad logon attempts on each domain controller. This value
confirms the .domain controllers that were involved in the account lockout.
Last Bad Pwd

Displays the time of the last logon attempt that used a bad password.
Pwd Last Set

Displays the value of the last good password or when the computer was last unlocked.
Lockout Time
Displays the time when the account was locked out.
Orig Lock
Displays the domain controller that locked the account (the domain controller that made
the originating write to the LockoutTime attribute for that user).
Figure 29. DCs Having badpwdcount
136
In the screenshot, one DC has badpwdcount =10 (which happens to be the bad password
threshold) one is PDC emulator, the other DC is the authenticating DC. This is due to password
chaining from the authenticating DC to the PDC.
The Alockout.dll Tool

24
The ALockout.dll tool and the Appinit.reg script are included in the ALTools package.
ALockout.dll is a logging tool that may help you determine the program or process that is
sending the incorrect credentials in an account lockout scenario. The tool attaches itself to a
variety of function calls that a process might use for authentication. The tool then saves
information about the program or process that is making those calls into the
Systemroot\Debug\Alockout.txt file. The events are time stamped so that you can match them
to the events that are logged in either the Netlogon log files or the Security event log files.
You can use Appinit.reg to initialize the .dll file. This file provides no other functionality.
Note
Microsoft does not recommend that you use this tool on servers that host network
programs or services. You should not enable ALockout.dll on Exchange servers because
the ALockout.dll tool may prevent the Exchange store from starting. Important: Before you
install the ALockout.dll tool on any mission-critical computer, make a full backup copy of
the operating system and any valuable data.
For more information, see Errors Installing Exchange Server with CleanSweep,
http://support.microsoft.com/default.aspx?scid=KB;EN-US;164431.on the Microsoft
Knowledge Base.
Use Alockout.dll in conjunction with normal Netlogon logging and/or security auditing. Use the
netlogon logs and/or security audit logs to determine the exact time(s) bad credentials were
sent for the client specific machine, then use those time stamps to zero in on the events
recorded in Alockout.txt set to configure Alockout.dll logging.
There are two separate versions, one for Windows 2000 and another for Windows XP.
Note
See readme.txt in .zip package for instruction on installation.
To set up this logging, follow steps below:

1. Copy alockout.dll to system32 directory on the machine in which account lockout occurs.
2. Run the appinit.reg script to add the dll to the Appinit_DLL key.
3. Restart the machine.
4. Wait for the account to lockout on that machine. The output file Alockout.txt will be
created in the winnt\debug directory.
To remove:
1. Remove the registry value HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows
NT\CurrentVersion\Windows].
2. "AppInit_DLLs"="alockout.dll"

137
3. Rename the alockout.dll.

4. Restart the machine.
Match up event timestamps in Alockout.txt with the netlogon logs and security events time
stamps of the 529 event or 681. By doing this action, the process that is causing the lockouts
can be exposed.
Sample Log
Tue Nov 05 13:16:15 2002, PID: 1236, Thread: 1240, Image C:\Program
Files\Internet Explorer\iexplore.exe,ALOCKOUT.DLL - DLL_PROCESS_ATTACH
Tue Nov 05 13:16:21 2002, PID: 1236, Thread: 1240, Image C:\Program
Files\Internet Explorer\iexplore.exe,ALOCKOUT.DLL - dll_process_detatch
Tue Nov 05 13:20:05 2002, PID:
716, Thread:
856, Image
mpnotify.exe,ALOCKOUT.DLL - DLL_PROCESS_ATTACH
Tue Nov 05 13:20:06 2002, PID: 1136, Thread: 1096, Image
C:\WINDOWS\System32\msiexec.exe,ALOCKOUT.DLL - DLL_PROCESS_ATTACH
C:\WINDOWS\System32\MsiExec.exe,ALOCKOUT.DLL - DLL_PROCESS_ATTACH
C:\WINDOWS\System32\MsiExec.exe,ALOCKOUT.DLL - dll_process_detatch
C:\WINDOWS\Explorer.EXE,UserName: lverge, Computer Name: SERVTEST,
Version: Microsoft Windows XP Professional ,Logon Server: \\DC1 ALOCKOUT.DLL - DLL_PROCESS_ATTACH
Tue Nov 05 13:20:31 2002, PID: 1700, Thread:
568, Image C:\Program
C:\WINDOWS\System32\msiexec.exe,ALOCKOUT.DLL - dll_process_detatch
628, Image
C:\WINDOWS\Explorer.EXE,UserName: lock5, Computer Name: SERVTEST,
Tue Nov 05 13:47:13 2002, PID:
864, Thread: 1212, Image
C:\WINDOWS\system32\svchost,***StartServiceW Failed!*** (0), Service:
Service: IMAPI CD-Burning COM Service (C:\WINDOWS\System32\imapi.exe), RC
was: Incorrect function.
(1), GLE was: Overlapped I/O operation is in
progress.
(997)
Tue Nov 05 13:47:28 2002, PID:
716, Thread:
680, Image
138
Tue Nov 05 13:47:29 2002, PID:

184, Thread: 1684, Image
The Aloinfo.exe Tool

25
If account lockouts seem to happen most frequently after a user is forced to change their
password, you may want to determine which users' passwords are about to expire. You can
use the ALoInfo.exe tool to display all user account names and the password age for those
user accounts. This will allow you to use the ALockout.dll tool and other account lockout tools
to set up the tools prior to the initial account lockout. You can also obtain a list of all local
services and startup account information by using the ALoInfo.exe tool.
AcctInfo.dll displays the following user account information that you may be able to use to
identify and resolve account lockout issues:
Last time the password was set
When the password will expire
User Account Control Raw Value and Decode
Time the account was locked out
If the account is locked out now, when it will be unlocked
Security identifier (SID) of the account, and its SIDHistory
Globally unique identifier (GUID) of the account
These account properties:
Last Logon
Last Logoff
Last Bad Logon Time
Logon Count
Bad Password Count
You can also use the AcctInfo.dll tool to obtain the domain password information (expiration,
lockout time, and so on). You can type the user's computer name in the tool, and then reset
the user's password on a domain controller in that user's site.
Usage: aloinfo [/stored] || [/expires && /server:<server>]
C:\aloinfo /expires /server:<DCnamer> -- This will dump password ages for all domain
user accounts.
C:\aloinfo /stored /server:<machinename> -- This will list all local services startup
account information and mapped drives of logged on user.

139
The Acctinfo.dll Tool

26
ACCTINFO.dll is used to add new property pages to user objects in AD users and computers to
help isolate/troubleshoot account lockouts and to change a users password on a DC in that
users site.
AcctInfo.dll displays the following user account information that you may be able to use to
identify and resolve account lockout issues:
Last time the password was set
When the password will expire
User Account Control Raw Value and Decode
Time the account was locked out
If the account is locked out now, when it will be unlocked
Security identifier (SID) of the account, and its SIDHistory
Globally unique identifier (GUID) of the account
These account properties:
Last Logon
Last Logoff
Last Bad Logon Time
Logon Count
Bad Password Count
It can display the domain password information (expiration, lockout time, etc.)
It allows one to enter the users workstation name and change the users password on a DC in
the users computers site. (note: works when client workstation is in the same site as AD site
as a dc hosting his user account.
When one changes the password this way, one can also unlock the account and set the user
must change password flag.
If lockoutstatus.exe is in the %systemroot%\system32 directory or a path specified in the
registry a button Account Lockout Status which will run lockoutstatus.exe for that user. If
not, the button is disabled.
To use this extension:
1. Copy addlinfo.dll to your system32 directory. Run regsvr32 addlinfo.dll.
140
Figure 30. user1 Properties Dialog Box
The EventcombMT.exe Tool

27
You can use the EventCombMT.exe tool to gather specific events from event logs from several
different computers into one central location. You can configure EventCombMT.exe to search
for events and computers. Some specific search categories are built into the tool, such as
account lockouts. Note that the account lockouts category is preconfigured to include events
529, 644, 675, 676, 681 and 12294.

141
Figure 31. EventCombMT Tool
The Nlparse.exe Tool

28
Because Netlogon log files may become more than 10 MB in size, you may want to parse the
files for the information that you want to view. You can use the NLParse.exe tool to parse
Netlogon log files for specific Netlogon return status codes. The output from this tool is saved
to a comma-separated values (.csv) file that you can open in Excel to sort further.
Note
The return codes that are specific to account lockouts are 0xC000006A and
0xC0000234.
142
Figure 32. Nlparse.exe Tool
The Findstr.exe Tool

29
You can also use the FindStr.exe tool to parse Netlogon log files. FindStr.exe is a commandline tool that you can use to parse several Netlogon.log files at the same time. After you gather
the Netlogon.log files from several domain controllers, extract information about a specific
user account from the files (user1, error code 0xC000006A, or error code0xC0000234). You
can use this tool to help you obtain output about a user, computer, or error code in the
Netlogon.log files.
To use the FindStr.exe tool, rename the Netlogon.log files, and then save the files to one
folder. To parse all of the Netlogon log files, type the following command at a command
prompt:
FindStr /I 0xc000006A *netlogon*.log >c:\6a.txt
For more information, see
http://www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/security/
bpactlck.mspx#EMAA

143
The Windows Logon Monitor V1.0 Tool

30
You can use Windows Logon Monitor v1.0 tool to assist just like Alockout.dll. The data is
outputted to the event logs, text file, or debugger. Windows logon Monitor will display the
Process ID/Process name, Thread ID, Clients LogonID, user name, domain name, and user
name for the credential that this application is about to send (optional). The utility pulls any
authentication that calls the following APIs:
WNetAddConnection
WNetAddConnection2
WNetAddConnection3
WNetUseConnectionW
WNetAddConnection3W
WNetAddConnectionW
LogonUserW
LogonUser
CreateProcessWithLogonW
StartServiceW
LogonUserExW
LogonUserEx
To use the tool you must install the tool through the wlmsetup.exe /setup command.
The install requires a reboot.
Config
Under the key HKLM\SYSTEM\CurrentControlSet\Control\LSA\WLMSSP
DebugFlags
(REG_DWORD)
ProcessFilter
(REG_MULTI_SZ)
UserFilter
(REG_MULTI_SZ)
LogAllProcess
(REG_DWORD)
LogAllUser
(REG_DWORD)
Installed
(REG_DWORD)
LogAllProcess
(REG_DWORD)
If this value is 1, then ProcessFilter is a list of processes that will
not be logged, if this value is 0, then ProcessFilter is a list of
processes that will be logged, default value is 1
ProcessFilter
(REG_MULTI_SZ)
A multi string that specifies the process name that will be logged,
default value is empty.
LogAllUser (REG_DWORD)
If this value is 1, then UserFilter is a list of users that will not be
logged, if this value is 0, then UserFilter is a list of users that will
be logged, default value is 1.
UserFilter (REG_MULTI_SZ)
A multi string that specifies the user name that will be logged, default
value is empty.
144
DebugFlags (REG_DWORD)
Multiple bit specify the debug log
WLM_DEBUG_INIT_BREAK
0x00000001
WLM_DEBUG_LOG_DEBUGGER
0x00000002
WLM_DEBUG_LOG_FILE
0x00000004
WLM_DEBUG_FUNCTION
0x00000008
Default value for DebugFlags is 0x00000000
WLM_DEBUG_LOG_DEBUGGER
If set, the debug information will be sent to debugger.
WLM_DEBUG_LOG_FILE
If set, the debug information will be appended to a file
%windir%\system32\wlmdbg.log, the file will be created if it does not
exist.
WLM_DEBUG_INIT_BREAK
If set, a breakpoint will be set on wlmssp.dlls initialization function,
you set this value only if you intend to debug wlmssp.dll and kernel mode
debugger is attached and enabled when machine is booted, otherwise, the
machine will hang during startup.
WLM_DEBUG_FUNCTION
If set, SSPs function entry & leave information will be logged, usually
turn this on if you have any problem with wlmssp.dll
Installed(REG_DWORD)
If this value is 0, or does not exist, means Windows Logon Monitor has
not been installed
If this value is 0x1, mean Windows Logon Monitor has been already been
installed
Remark:
A reboot is required after you change the above settings.
Event Log Samples

31
Figure 33. Event logged When Using MMC to Check Services on Remote Computer

145
32
Figure 34. Event Logged When Using Telnet Connect to a Server That Requires NTLM Authentication
Using Excel to Go Through Logs

33
You can also use the Excel to parse Netlogon log files and security logs. In large environments,
opening a large sorted file into Excel and using the filtering to see the data that you need to
see. After you gather the Netlogon.log files and use findstr to parse out all the bad password
attempts (0xC000006A), You will import the file into excel and filter out the users or
computers you are interested in and get a good idea of the scope of the issue. From several
domain controllers, extract information about a from the files error code.
To use excel first run findstr listed below or gather all the security logs with EventCombMT.
FindStr /I 0xc000006A *netlogon*.log >c:\6a.txt
1. Open Excel and navigate to the file that was saved the security logs or the parsed
netlogon logs.
2. When opening you will have to choose under the files of type all files *.*. Then, select the
file you want to import.
3. On the Import Text wizard leave the settings on page one at the default settings, which is
the Delimited option, and click Next.
4. On the second page, ensure the Tab and Space check boxes are checked and click Next.
5. Click Next again and then click Finish.
6. Select the top row, which is labeled 1. This will highlight all the data in the row.
7. With the first row selected, click the Data menu, choose filter and then autofilter.
8. Now you can sort by user name and by computer or data or event.
146
Figure 35. Sorted by the Event 681, a User Named jz9nz1 With the Error Code Event 3221225578
Script to Unlock all Locked Out Users

Provide this script in combination with disabling the lockout feature until the denial of service
attack is isolated. The lockout feature is to let you know of a problem and to help reduce the
attack surface. This script should only be used to reduce the pain. It is not a solution to
unlocking all users.
'##########################
'### FILE: AccountUnlock.vbs
'### CREATED: 2-12-03
'### FUNCTION: Resets all the locked user accounts in the domain.
'###
This script walks through the entire domain.
'###
Including all OUs and the Users Container.
'### Copyright (C) 2002 Microsoft Corporation
'#######################
Dim
Dim
Dim
Dim
strDomain
strDomainName
strUser
Counter
Counter=0
'#######################
'### Gathering the domain name from the user.
'#######################
strDomainName = inputbox( "Please enter a domainname", "Input" )
147
if strDomainName = "" then wscript.quit(1)

Set strDomain = GetObject("WinNT://" & strDomainName)
'#######################
'### Setting up the filter array and running through a If Then loop
'### to set the "IsAccountLocked" attribute to False.
'### Also outputs the users that were unlocked.
'#######################
strDomain.Filter = Array("User")
For each User in strDomain
If User.IsAccountLocked = True Then
wscript.echo User.Name
User.IsAccountLocked = False
User.SetInfo
Counter = Counter + 1
End If
Next
'#######################
'### Outputting the number of locked accounts.
'#######################
If Counter = 1 Then
wscript.echo "Only 1 user account in the " & strDomain.Name & "
domain was unlocked."
Else
wscript.echo Counter & " user accounts were unlocked in the " &
strDomain.Name & " domain."
End If
LAB 5: Troubleshooting Account Lockout Problems

34
Work with Account Lockout tools.
Troubleshoot Account Lockout problems.
148
Resources
35
The following Microsoft Knowledge Base articles provide additional information:
817701 Service Packs and Hotfixes That Are Available to Resolve Account Lockout
109626 Enabling debug logging for the Net Logon service

227033 SMS: Changing the SMSClient_<SiteCode> Password Can Cause Account

231399 SMS: SMSCliToknAcct& and/or SMSCliSvcAcct Accounts Locked Out on Site

264678 Increased account lockout frequency in a Windows 2000 domain

308471 List of features available in the Event Comb tool

315585 Troubleshooting account lockout problems in Windows Server 2003, in

824209 How to Use the EventCombMT Utility to Search Event Logs for Account
817701 Service Packs and Hotfixes That Are Available to Resolve Account Lockout
885119 How to set account lockout policies in Windows 2000

273499 Description of Security Event 681

Summary
36
Topics discussed in this session include the:
Password policy settings and Account Lockout policy settings.
Types of attacks on a domain.
Domain controller behavior during account lockout.
Troubleshooting common account lockout problems.
Utilities used to troubleshoot account lockout problems.

149
150

Troubleshooting logon failures comes down to troubleshooting authentication. This session
explains how to troubleshoot logon failures.
A key feature of authentication in the Windows 2000/2003 family is its support of single signon. Single sign-on allows a user to log on to the domain once, using a single password, and
authenticate to any computer in the domain. Single sign-on provides two main security
benefits:
For a user, the use of a single password or smart card reduces confusion and improves
work efficiency.
For administrators, the amount of administrative support required for domain users is
reduced, because the administrator only needs to manage one account per user.
Authentication, including single sign-on, is implemented as a two-part process: interactive

logon and network authentication. Successful user authentication depends on both of these.
Before You Begin

1
Be familiar with Operations Master roles.
Understand replication between domain controllers.
Understand the dependency of clients and domain controllers on DNS.
What You Will Learn

2
Explain the differences between a logon failure and an account lockout.
Explain the logon process.
Identify the different error messages returned by different operating systems.
Describe general causes of logon failures and the security issues that cause logon
failures.
Explain how to troubleshoot logon failures and the purpose of the utilities that
troubleshoot logon failures.

151
Differences Between Logon Failures and Account Lockouts

3
Logon failures obviously can cause account lockouts, based upon the companys account
lockout policy. A company needs to evaluate its need for security and weigh it against
administration costs, time to implement and maintain.
Account lockout policy should not be applied haphazardly. While you increase the probability
of thwarting an unauthorized attack on your organization with account lockout policy, you can
also unintentionally lock out authorized users, which can be quite costly for your organization.
If you decide to apply account lockout policy, set the Account lockout threshold policy
setting to a high enough number that authorized users are not locked out of their user
accounts simply because they mistype a password. Normally, our recommended
threshold is greater than 10 and less than 15. Account lockout problems are common
with thresholds less than 6. For additional security, customers should consider increasing
password complexity versus decreasing lockout threshold.
Authorized users can be locked out if they change their passwords on one computer, but
not on another computer. The computer that is still using the old password will
continuously attempt to authenticate the user with the wrong password, and it will
eventually lock out the user account. This might be a costly consequence of defining
account lockout policy, because the authorized users cannot access network resources
until their accounts are restored.
Password changes are done through a normal domain logon process and the new
password is passed up to the PDC Emulator awaiting normal replication to other domain
controllers in the domain. When a logon attempt fails because bad password if the
password being used is the previous password, then the bad password count is not
incremented and thus using your last password will not lockout your account. This
behavior was changed via a hotfix for Windows 2000 to reduce the number of account
lockout problems.
The Logon Process

4
Exactly how the logon process works depends on how you configure the computer. With
standard configurations of Windows 2000, interactive users log on with a password. In
another optional configuration of Windows 2000, users log on with a smart card. Although the
basic process is the same for both configurations, there are some differences. Figure 36
shows the logon process.
152
Figure 36. The Logon Process
When a user logs on to the network with a domain user and computer account, they begin by
pressing the key combination CTRL+ALT+DEL, which is the Secure Attention Sequence (SAS)
on computers with a standard Windows 2000 configuration.
In response to the SAS, Winlogon switches to the logon desktop and dispatches to a DLL
called the Graphical Identification and Authentication (GINA), a component loaded in
Winlogon's process. GINA is responsible for collecting the logon data from the user, packaging
it in a data structure, and sending everything to the LSA for verification. Third parties can
develop replacement GINAs, but in this case, Winlogon has loaded the standard component
(MSGINA.dll) supplied with the Windows 2000 operating system. MSGINA displays the
standard logon dialog box.
The user types their name and password, MSGINA returns the logon information to Winlogon.
Winlogon then sends the information to the LSA for validation by calling LsaLogonUser.
Upon receiving a data structure with Users logon data, the LSA immediately converts the
plaintext password to a secret key by passing it through a one-way hashing function. It saves
the result in the credentials cache, where the hashed password can be retrieved when it is
needed for encryption and decryption.
To validate a users logon information and set up a logon session on the computer, the LSA
must obtain the following:
A TGT that is good for admission to the ticket-granting service.
A session ticket that is good for admission to the computer.

5
The LSA gets these tickets by working through the Kerberos SSP, which exchanges messages
directly with the domain's KDC.
The messages follow this sequence:
1. The LSA sends a KRB_AS_REQ message to the KDC's authentication service in the
domain.

153
The message includes:
The user's principal name
The name of the account domain
Preauthentication data encrypted with the secret key derived from Alice's password.
2. The KDC's authentication service replies with a KRB_AS_REP message.
A session key for the user to share with the KDC, encrypted with the secret key
derived from the users password.
A TGT for the KDC in the domain, encrypted with the KDC's secret key. The TGT
includes a session key for the KDC to share with the user and authorization data for
the user. The authorization data includes the SID for the account, SIDs for security
groups in the domain that include the user, and SIDs for universal groups in the
enterprise that include either the user account or one of their domain groups.
3. The LSA sends a KRB_TGS_REQ message to the KDC's ticket-granting service in the
domain.
The name of the destination computer
The name of the destination computer's domain
Users TGT
An authenticator encrypted with the session key the user shares with the KDC
4. The KDC replies with a KRB_TGS_REP message.

A session key for the user to share with their local computer encrypted with the
session key the user shares with the KDC.
A session ticket to the computer encrypted with the secret key the computer shares
with the KDC.
The session ticket includes a session key for the computer to share with the user and
authorization data copied from the users TGT.
Upon receipt of the user session ticket, the LSA decrypts it with the computer's secret key and
extracts the authorization data. It then queries the local Security Accounts Manager (SAM)
database to determine whether the user is a member of any security groups local to the
computer and whether they have been given any additional user rights on the local computer.
It adds any SIDs returned by this query to the list taken from the ticket's authorization data.
The entire list is then used to build an access token. A handle to the access token is then
returned to Winlogon, along with the identifier for the users logon session and confirmation
that the logon information is valid.
Winlogon creates a window station and several desktop objects for the user, attaches their
access token, and starts the shell process, usually Explorer.exe, they will use to interact with
the computer. Any application process that they start during their logon session subsequently
inherits this access token.
154
Finding a Domain Controller Required for Logon

6
The process for locating a domain controller can be summarized as follows:

1. On the client (the computer that is locating the domain controller), the Locator is initiated
as a remote procedure call (RPC) to the local Netlogon service. The Locator API
(DsGetDcName) is implemented by the Netlogon service.
2. The client collects the information that is needed to select a domain controller and
passes the information to the Netlogon service by using the DsGetDcName API.
3. The Netlogon service on the client uses the collected information to look up a domain
controller for the specified domain in one of two ways:
Note
For a DNS name, Netlogon queries DNS by using the IP/DNS-compatible Locator
that is, DsGetDcName calls DnsQuery to read the SRV records and A records from
DNS after it appends an appropriate string to the front of the domain name that
specifies the SRV record.
For a NetBIOS name, Netlogon performs domain controller discovery by using the
Windows NT 4.0compatible Locator that is, by using the transport-specific
mechanism (for example, WINS).
In Windows NT 4.0 and earlier, discovery is a process for locating a domain controller for
authentication in either the primary domain or a trusted domain.
4. The Netlogon service sends a datagram to the discovered domain controllers ("pings" the
computers) that register the name. For NetBIOS domain names, the datagram is
implemented as a mailslot message. For DNS domain names, the datagram is
implemented as an LDAP UDP search.
5. Each available domain controller responds to the datagram to indicate that it is currently
operational and then returns the information to DsGetDcName.
6. The Netlogon service returns the information to the client from the domain controller that
responds first.
7. The Netlogon service caches the domain controller information so that it is not necessary
to repeat the discovery process for subsequent requests. Caching this information
encourages the consistent use of the same domain controller and, thus, a consistent
view of Active Directory.
Domain controllers must contact a global catalog server to retrieve any SIDs of universal
groups that the user is a member of. Additionally, if the user specifies a logon name in the
form of a UPN, the domain controller contacts a global catalog server to retrieve the domain of
the user.
Global catalog servers register global-catalog-specific service (SRV) resource records in DNS
so that clients can locate them according to site. If no global catalog server is available in the
site of the user, a global catalog server is located in the next closest site, according to the cost
matrix that is generated by the KCC from site link cost settings.

155
Cross Forest Logon

7
Machines and users are not always located in the same domain or forest. Occasionally users
in one domain/forest will logon to a computer in another forest/domain. In order for the user
to be logged on, the machines domain must trust the users domain. In this situation, the
computer locates a DC in its domain and the user authentication is passed to a DC in the
users domain. The PDC Emulator in the users domain must be discoverable by the PDC
Emulator in the machines domain.
WINS Records
8
A domain controller registers its NetBIOS name (<DomainName> [1B]) by broadcasting or

directing a NetBIOS name registration request to a NetBIOS name server, such as a WINS
server. Registering the NetBIOS name makes it possible for Windows-based clients that are
not DNS-enabled to find the domain controllers that are running Windows 2000/2003,
Windows NT 4.0, or Windows NT 3.51. In this case, the client finds the domain controller by
sending a Netlogon mailslot request that is based on the NetBIOS domain name.
DNS SRV Records

9
Every Windows 2000/2003based domain controller dynamically registers service records

(SRV records) in DNS, which allow servers to be located by service type (for example, LDAP)
and protocol (for example, Transmission Control Protocol [TCP]). Because domain controllers
are LDAP servers that communicate over TCP, SRV records can be used to find the DNS
computer names of domain controllers. In addition to registering LDAP-specific SRV records,
Netlogon also registers Kerberos v5 authentication protocolspecific SRV records to enable
locating servers that run the Kerberos Key Distribution Center (KDC) service.
Every Windows 2000/2003based domain controller also dynamically registers a single host
resource record (an A resource record), which contains the name of the domain
(DnsDomainName) where the domain controller is and the IP address of the domain
controller. The A resource record makes it possible for clients that do not recognize SRV
records to locate a domain controller by means of a generic host lookup.
Each Windows 2000/2003 based domain controller registers DNS records that indicate the
site where the domain controller is located. The site name (the relative distinguished name of
the site object in Active Directory) is registered in several records so that the various roles the
domain controller might perform such as Global Catalog or Kerberos server can be associated
with the domain controller's site. When DNS is used, the Locator searches first for a sitespecific DNS record before it begins to search for a DNS record that is not site-specific
(thereby preferentially locating a domain controller in that site).
A client computer stores its own site information in the registry, but the computer is not
necessarily located physically in the site associated with its IP address. For example, a
portable computer that was moved to a new location contacts a domain controller in its home
site, which is not the site to which the computer is currently connected. In this situation, the
domain controller looks up the client site on the basis of the client IP address by comparing
the address to the sites that are identified in Active Directory, and returns the name of the site
that is closest to the client. The client then updates the information in the registry.
156
The Configuration container (including all of the site and subnet objects in it) is replicated to
all domain controllers in the forest. Therefore, any domain controller in the forest can identify
the site in which a client is located, compare it to the site in which the domain controller is
located, and indicate to the client whether that domain controller's site is the closest site to
the client.
There is not necessarily a domain controller in every site. For various reasons, it is possible
that no domain controller exists for a particular domain at the local site. By default, each
domain controller checks all sites in the forest and then checks the replication cost matrix. A
domain controller advertises itself (registers a site-related SRV record in DNS) in any site that
does not have a domain controller for that domain and for which its site has the lowest- cost
connections. This process ensures that every site has a domain controller that is defined by
default for every domain in the forest, even if a site does not contain a domain controller for
that domain. The domain controllers that are published in DNS are those from the closest site
(as defined by the replication topology).
Domain Controller from Last Validation Cached by Netlogon

10
The Netlogon service on the client caches the domain controller information so that
subsequent requests need not repeat the discovery process. Caching this information
encourages consistent use of the same domain controller and, thus, a consistent view of
Active Directory.
Cached Credentials
11
Windows 2000, Windows XP and Windows 2003 allow users to logon interactively to their
computer using a domain user account and password without physical connectivity to the
network. In order to allow this type of logon to work, a hashed version of the users password
is stored locally on the computer in a protected storage location called the password cache.
Whenever a user attempts to logon interactively on the computer and no network connectivity
exists to a domain controller, the password entered by the user is hashed and this hash is
compared to the stored hash. If the two hashes match, the user is allowed to logon as though
a domain controller had verified the users credentials.
Again, the primary purpose of logging on with cached credentials is to enable you to access
the local workstation. However, if you have logged on by cached credentials, you may be
unable to access network resources because you have not been authenticated.
The required authentication can be performed by following one of two methods:
You can obtain a Kerberos protocol ticket when you attempt to map the drive.
You can specify the credentials when you attempt to map the drive.
The process to obtain the Kerberos protocol ticket occurs in the background. Typically, you are
unaware of this process, unless it is unsuccessful, in which case you can receive the error
message in the Summary section.

157
Note
To return to NTLM authentication (such as, when you attempt to access a Windows NT
4.0-based computer) the workstation must still be able to locate a (Kerberos) Key
Distribution Center (KDC) in its domain, and then the workstation must be unable to
obtain a ticket for the target server (that is expected when the target server is a Windows
NT 4.0-based computer). If a KDC cannot be located, the computer does not return to
NTLM.
By default, the cached credentials of the last 10 users who have successfully logged on to a
domain account can be used to log a user on locally if the authenticating domain controller
becomes unavailable. Once ten sets of credentials are in the store, the credential caching
engine will reuse the oldest set of cached credentials.
Cached credentials are stored in the registry:
HKEY_LOCAL_MACHINE\Security\Cache
Examining Error Messages

12
The errors a client may see due to authentication or logon issues may come as pop-ups at
logon, and / or may be logged in the security event log.
Win 9x clients may post the following errors:
The domain password you supplied is not correct, or access to your logon server has
been denied.
Winnt 4.0 clients may post the following errors:
The system could not log you on. Make sure your User name and domain are correct, and
then type your password again. Letters in passwords must be typed using the correct
case. Make sure that Caps Lock is not accidentally on.
The local policy of this system does not permit you to logon interactively.
Your account is configured to prevent you from using this computer.
The system cannot log you on to this domain because the system's computer account in
its primary domain is missing or the password on that account is incorrect.
Windows 2000 / WinXP / Windows Server 2003 may post the following errors:
The system could not log you on. Make sure your User name and domain are correct, and
then type your password again. Letters in passwords must be typed using the correct
case. Make sure that Caps Lock is not accidentally on.
The local policy of this system does not permit you to logon interactively.
Your account is configured to prevent you from using this computer.
The system cannot log you on to this domain because the system's computer account in
its primary domain is missing or the password on that account is incorrect.
158
Examining General Causes of Logon Failures

13
The general causes of logon failure are name resolution issues or connectivity issues. To
resolve name either resolution or connectivity issues, you must examine both the client
machine and the domain controller. Does the request reach the domain controller? Does the
domain controller respond? Does that response reach the client?
Lack of Name Resolution to Resolve a Domain Controller

14
Earlier the process of a client locating a domain controller for authentication was discussed.
Depending on the client, either DNS or some means of NetBIOS name resolution is used. You
will need to gather the client machines network configuration to review it and confirm it with
the customer. MPS Reports will gather its DNS configuration, and NetBIOS `name cache.
Network monitor may be used in these situations.
Connectivity Issues
15
Connectivity issues could be hardware issues either on the client or the domain controller or
somewhere in between. Simultaneous Network monitor traces on the client and the domain
controller may have to gather to determine if the packets from the client are making it to the
domain controller.
One issue with switches that occurs quite frequently is errors when a switch has the spanning
tree algorithm enabled. This is documented in A Client Connected to an Ethernet Switch May
Receive Several Logon-Related Error Messages During Startup,
Another issue to check is when the client machine is connected to a 10/100 Ethernet hub
with a 10/100 autosensing Ethernet adapter installed. Check the adapter media type to see if
it is set to autosense, autosensing, or autodetect. The lack of proper media type detection
may cause a timeout in the Netlogon process, where the server cannot respond to a client
request because of the autosensing problem on the adapter or switch. To resolve this issue,
manually set the media type within the driver properties of the Ethernet adapter.
Third Party Applications or Services

16
There are client side applications that are known to block ports or protocols that can keep a
user from authenticating. Examples of such applications include BlackIce, Surf control, and
proxy clients. MPS Reports will dump a list of applications on the client machine.

159
Other Possible Causes

17
Time delays in Windows 2000 / 2003 multi-master, replication play a critical role in logon. It
makes it difficult to identify the DC to which changes will be directed. Something as simple as
the creation of a user account and not waiting or forcing replication to occur will cause logon
failures. Errors can occur if the logon is directed to a DC where the new account has not been
replicated.
Kerberos security inspects the time stamp of the authentication request sent by the client that
is logged on. The time stamp is compared to the current time of the domain controller. If there
is a significant difference between the two times (the default is five minutes), authentication
fails. Log on locally to an administrative account, and synchronize the time between the
Windows 2000 Professional client and the domain controller.
Another related problem is the creation of two duplicate accounts at the same time. Since no
two objects can have the same name, one object will be renamed using the objects GUID
(Globally Unique Identifier). For example, if the user account named Fred was created
simultaneously on two DCs, they would both appear as Fred in the Active Directory Users
and Computers snap-in until replication took place.
The order of protocol bindings and the use of client redirectors are still factors in terms of a
successful logon. Each setting can provide its own unique type of failure. In addition, because
there is support for working Offline in Windows 2000 and later, the connectoid for the LAN
connection can be temporarily disabled, which will also cause network logon failures similar to
unplugging the network cable.
Examining Security Causes of Logon Failures

18
In examining security settings that can affect logons, you must remember these can be set via
group policy or through the registry.
GPO Settings
19
Table 10 lists and describes the Group Policy settings that are associated with logon.
Table 10. Group Policy Settings Associated with Interactive Logon
Group Policy Setting
Description
Password Policy:
Enforce password history
Maximum password age
Minimum password age
Minimum password length
Password must meet complexity
requirements
Store password using reversible
encryption for all users in the domain
160
Changes to the Password Policy settings control:

The strength and complexity required of
every users password
Group Policy Setting
Description
Audit Policy:
Audit account logon events
Audit account management
Audit logon events
Changes to the Audit Policy settings control:

Auditing of logons and logoffs
Auditing of password and permissions
changes
User Rights Assignment:

Access the computer from the network
Deny logon as a batch job
Deny logon as a service
Deny logon locally
Deny logon through terminal services
Logon as a batch job
Logon as a service
Logon locally
Changes to the User Rights Assignment settings

control:
Which users are allowed or disallowed to log
on to perform different tasks, including
logging on as a batch job and a service
Which users are allowed or disallowed to log
on locally or through Terminal Services, as
well as who can access the computer from
the network
Security Options:
Accounts: Limit local accounts use of
blank passwords to console logon only
Domain member: Maximum machine
account password age
Domain member: Require strong (in
Windows 2000 or later) session key
Interactive logon: Do not display last user
name
Interactive logon: Do not require
CTRL+ALT+DEL
Interactive logon: Message Text for users
attempting to log on
Interactive logon: Message title for users
attempting to log on
Interactive logon: Number of previous
logons to cache (in case the domain
controller is not available)
Interactive logon: Require domain
controller authentication to unlock
workstation
Interactive logon: Smart card removal
behavior
Recovery console: Allow automatic
administrative logon
Shutdown: Allow system to be shut down
without having to log on
Changes to the Security Options settings control:

Message text and title displayed by the GINA
during an interactive logon
Domain member settings
Authentication settings, including allowing
or disallowing blank passwords and
password age

161
SMB Signing
20
SMB signing requirements can cause clients to fail connectivity. Some clients including:
Win9x, Win3x, NT4, Mac, Unix, etc do not entirely support SMB signing and can cause these
clients to receive Access denied errors even though the credentials being passed are valid.
Lmcompatability and restrict anonymous settings can also cause this client to fail connectivity.
Registry Path:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\LanManServer\Parameters
This key contains the following values:
Value Name: EnableSecuritySignature
Data Type: REG_DWORD
Data: 0 (disable), 1 (enable)
Value Name: RequireSecuritySignature
Type: REG_DWORD
Value: 0 (disable), 1 (enable)
Default: 0
Version:
The EnableSecuritySignature and RequireSecuritySignature registry settings are available in
Windows Server 2003, Windows 2000, Windows XP, and Winnt 4.0. It can be set via the
registry or through a Group Policy.
Digitally sign client communications (always)
Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options
Description:
Determines whether the computer will always digitally sign client communications.
The Windows 2000 Server Message Block (SMB) authentication protocol supports mutual
authentication, which closes a "man-in-the-middle" attack, and supports message
authentication, which prevents active message attacks. SMB signing provides this
authentication by placing a digital signature into each SMB, which is then verified by both the
client and the server.
In order to use SMB signing, you must either enable it or require it on both the SMB client and
the SMB server. If SMB signing is enabled on a server, then clients that are also enabled for
SMB signing will use the packet signing protocol during all subsequent sessions. If SMB
signing is required on a server, then a client will not be able to establish a session unless it is
at least enabled for SMB signing.
If this policy is enabled, it requires the Windows 2000 SMB client to perform SMB packet
signing. If this policy is disabled, it does not require the SMB client to sign packets. This policy
is defined by default in Local Computer Policy, where it is disabled by default.
162
Note
SMB signing will impose a performance penalty on your system. Although it does not
consume any more network bandwidth, it does use more CPU cycles on the client and
server side.
Crashonauditfail
21
Registry Path:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\
Version:
The CrashOnAuditFall registry setting is available in Windows Server 2003, Windows 2000,
Windows XP, and Winnt 4.0. It can be set via the registry or through a Group Policy.
The CrashOnAuditFall entry directs the system to halt when it cannot record new events in the
security log in Event Viewer. This feature prevents unauthorized activities from occurring when
they cannot be recorded in the security log.
The system also uses this entry to indicate that this feature has been triggered (a value of 2).
When the value of this entry is 2, only members of the Administrators group can log on to the
computer. This restricted state lets an Administrator log on to resolve the problem and to reset
the value of this entry to 1.
Typically, the system cannot record security events because the security log in Event Viewer is
full or because the internal queue to the log has reached the maximum established by the
bounds value.
This entry does not exist in the registry by default. You can add it by using the registry editor,
Regedit.exe.
Restrictanonymous
22
Registry Path:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\
Version:
The RestrictAnonymous registry setting is available in Windows Server 2003, Windows 2000,
Windows XP, and Winnt 4.0. It can also be set through a Group Policy.
The RestrictAnonymous value restricts anonymous users from displaying lists of users and
from viewing security permissions.

163
The following table lists the possible settings for the RestrictbAnonymous value.
Table 11. RestrictAnonymous Settings
Value
Description
Disabled. Anonymous users are not restricted.
Enabled. Users who log on anonymously (a logon referred to as a null session

connection) cannot display lists of domain user names or share names. In
addition, these users cannot view security permissions; they cannot use all of
the features of Windows Explorer, Local Users and Groups, and other
programs that enumerate users or shares.
Anonymous users have no access without explicit anonymous permissions.

This entry does not exist in the registry by default. You can add it by using the registry editor,
Regedit.exe.
Lmcompatibilitylevel
23
Historically, Windows NT supports two variants of challenge/response authentication for

network logons:
LAN Manager (LM) challenge/response
Windows NT challenge/response (also known as NTLM version 1 challenge/response)
The LM variant allows interoperability with the installed base of Windows 95, Windows 98,
and Windows Millennium Edition clients and servers. NTLM provides improved security for
connections between Windows NT clients and servers. Windows NT also supports the NTLM
session security mechanism that provides for message confidentiality (encryption) and
integrity (signing).
Recent improvements in computer hardware and software algorithms have made these
protocols vulnerable to widely published attacks for obtaining user passwords. In its ongoing
efforts to deliver more secure products to its customers, Microsoft has developed an
enhancement, called NTLM version 2 that significantly improves both the authentication and
session security mechanisms. NTLM 2 has been available for Windows NT 4.0 since Service
Pack 4 (SP4) was released, and it is supported natively in Windows 2000. You can add NTLM
2 support to Windows 95 and Windows 98 by installing the Directory Services Client from the
Windows 2000 CD-ROM.
After you upgrade all computers that are based on Windows 95, Windows 98, Windows
Millennium Edition, and Windows NT 4.0, you can greatly improve your organization's security
by configuring clients, servers, and domain controllers to use only NTLM 2 (not LM or NTLM).
For reference, the full range of values for the LMCompatibilityLevel value that are supported
by Windows NT 4.0 and Windows 2000 /2003 includes:
Level 0
Send LM and NTLM response; never use NTLM 2 session security. Clients use LM and
NTLM authentication, and never use NTLM 2 session security; domain controllers accept
LM, NTLM, and NTLM 2 authentication.
164
Level 1
Use NTLM 2 session security if negotiated. Clients use LM and NTLM authentication, and
use NTLM 2 session security if the server supports it; domain controllers accept LM,
NTLM, and NTLM 2 authentication.
Level 2
Send NTLM response only. Clients use only NTLM authentication, and use NTLM 2
session security if the server supports it; domain controllers accept LM, NTLM, and NTLM
2 authentication.
Level 3
Send NTLM 2 response only. Clients use NTLM 2 authentication, and use NTLM 2 session
security if the server supports it; domain controllers accept LM, NTLM, and NTLM 2
authentication.
Level 4
Domain controllers refuse LM responses. Clients use NTLM authentication, and use
NTLM 2 session security if the server supports it; domain controllers refuse LM
authentication (that is, they accept NTLM and NTLM 2).
Level 5
Domain controllers refuse LM and NTLM responses (accept only NTLM 2). Clients use
NTLM 2 authentication, use NTLM 2 session security if the server supports it; domain
controllers refuse NTLM and LM authentication (they accept only NTLM 2).
A client computer can only use one protocol in talking to all servers. You cannot configure it,
for example, to use NTLM v2 to connect to Windows 2000-based servers and then to use
NTLM to connect to other servers. This is by design.
Windows NT-based computers (SP 4 and higher) can be configured to send only NTLMv2
responses by setting HKEY_LOCAL_MACHINE\System
CurrentControlSet\Control\Lsa\LMCompatibilityLevel =3 or higher. The LMCompatibilityLevel
registry value is exposed in the Local Policies\Security Options node of the Security
Configuration Manager tools (Local Security Policy and Security Settings extension of Group
Policy Object Editor) as Network Security: LAN Manager authentication level policy setting.
Clients that have the secure or high secure template applied to them will have
LMCompatibility set to 3 or higher.
Pre-Windows 2000 Compatible Permissions

24
To maximize security, by default, Windows 2000 Active Directory does not allow accounts
logged on with Anonymous access the ability to view group memberships and other user and
group information. Windows NT 4.0 did allow this degree of access. Several existing
applications, including Microsoft BackOffice applications like SQL Server as well as some third
party applications, depend on this type of access to function correctly.
To provide a clean and simple upgrade path from Windows NT, the Active Directory Installation
wizard offers the choice between Permissions compatible with pre-Windows 2000 servers,
which provides the security level compatible with some pre-Windows 2000 applications and
Permissions compatible only with Windows 2000 server.

165
If Permissions compatible only with Windows 2000 server is chosen while promoting a domain
controller and applications are not functioning correctly, try resolving the problem by adding
the special group Everyone to the Pre-Windows 2000 Compatible Access security group and
rebooting the domain controllers in the domain. Once the upgrade to Windows 2000
compatible applications is completed, administrators should return to the more secure
Windows 2000 configuration by removing Everyone from the Pre-Windows 2000 Compatible
Access security group and rebooting the domain controllers in the affected domain. This can
only be done from the command line using the following:
net localgroup "Pre-Windows 2000 Compatible Access" everyone /delete
Troubleshooting Logon Failures

25
When troubleshooting logon failures, you need to gather initial information from the customer
to determine the scope of the issue and if any patterns are exhibited.
Gathering Information
Gathering information on logon errors included getting the customer his analysis of the
problem as well as getting objective data such as MPSreports from a sampling of client
machines and domain controllers.
What Does the Error Message Point To?

Be sure to log the exact error message the client receives and note it in the case. This error
may already be logged in the KB and possible solutions can be reviewed. Also, the error
message should help you to determine if the issue is caused by a lack of name resolution, or
another reason.
What Is Common Among Affected Users?

Are all accounts affected, or just those created recently? Are all the clients located in one site?
Is the hardware the same for all affected clients? These are questions that will allow you to
determine if patterns exist.
Is the Problem Computer or User Specific?

The quick test to determine if it is the computer or the user, is to have the user try another
machine. Can the user successfully logon another machine?
What Are the Recent Changes to a Network?

Has any new hardware been installed such as routers, switches, or firewalls? Have they made
any DNS configuration changes? Have they applied any security patches or service packs to
the domain controllers or clients? If the customer answers yes to any of these questions, try to
determine the details.
What Are the Service Pack Levels on Domain Controllers and

Clients?
Determine if the customer has recently applied any security patches or service packs to his
domain controllers or his clients. Also, if the customer has old service packs installed on this
domain controllers or clients, determine why he has not applied the latest version. Determine
if the later service pack addresses any logon issues. Incompatibilities between machines that
has security patches / service packs and those that dont can occur.
166
Analyzing Gathered Information

When analyzing failed logons you need to determine what domain the user account resides in
and what domain the computer account resides in. This information will help you determine if
you need to focus on multiple domains or just one. Also, evaluate any recent changes made to
the environment such as security patches applied, etc. If it worked before the change,
consider backing out the change to see if it works then. You may want to discuss the situation
with your Techlead for direction.
Using Utilities for Troubleshooting Logon Failures

26
When troubleshooting logon failures, first check the security event logs on the domain
controller authenticating the user account and the client machine. If auditing is enabled, there
may be events logged that will help you diagnose the problem.
In addition to auditing, enabling Netlogon logging at the PDC emulator will be helpful.
Reference http://support.microsoft.com/default.aspx?scid=KB;EN-US;189541, Using the
Checked Netlogon.dll to Track Account Lockouts. Errors shown in the Netlogon.log may help
you determine why the logon failure is happening:
The errors you most likely receive are:
0xC0000234 User logon with Account Locked
0xC000006A User logon with Misspelled or bad Password
0xC0000072 User logon to account disabled by Administrator
0xC0000193 User logon with Expired Account
0xC0000070 User logon from unauthorized workstation
0xC000006F User logon Outside authorized hours
0xC0000224 User logon with "Change Password at Next Logon" flagged
0xC0000071 User logon with Expired Password
0xC0000064 User logon with Misspelled or Bad User Account
To track user account lockouts, only the 234 and 6A errors are important to us.
The following tools are useful when troubleshooting logon failures:
Using Runas
27
Allows a user to run specific tools and programs with different permissions than the user's
current logon provides. It is good practice for administrators to use an account with restrictive
permissions to perform routine, non-administrative tasks, and to use an account with broader
permissions only when performing specific administrative tasks. To accomplish this without
logging off and back on, log on with a regular user account and use the runas command to run
the tools that require the broader permissions.
To execute a program that will administer a server in another forest, type:
runas /netonly /user:domain\username command
167
Where domain\username is a user with enough permissions to administer the server, and
command is a command prompt window, program, saved MMC console, or Control Panel item.
For example, to create a shortcut for Active Directory Users and Computers, type:
runas /netonly /user:domain\username "mmc.exe dsa.msc"
The runas command can be used to start any program, MMC console, or Control Panel item as
long as the following requirements are met:
You provide the appropriate user account and password information.
The user account has the ability to log on to the computer.
The program, MMC console, or Control Panel item is available on the system and to the
user account.
The runas command is usually used to run programs as an administrator, although it is not
limited to administrator accounts.
Using Kerbtray and Klist

28
Kerberos Tray is included in the Windows Server 2003 Resource Kit and the Windows 2000
Resource Kit.
Version compatibility:
Kerberos Tray is supported for Windows Server 2003, Windows XP, and Windows 2000.
Kerberos Tray is a graphical user interface tool that displays ticket information for a computer
running Microsofts implementation of the Kerberos version 5 authentication protocol.
You can view and purge the ticket cache by using the Kerberos Tray tool icon located in the
notification area of the desktop. By positioning the cursor over the icon, you can view the time
left until the initial ticket-granting ticket (TGT) expires. The icon also changes in the hour
before the Local Security Authority (LSA) renews the ticket.
Kerberos List is included in the Windows Server 2003 Resource Kit and the Windows 2000
Resource Kit.
Kerberos List is supported for Windows Server 2003, Windows XP, and Windows 2000.
Kerberos List is a command-line tool that is used to view and delete Kerberos tickets granted
to the current logon session. To use Kerberos List to view tickets, you must run the tool on a
computer that is a member of a Kerberos realm.
When Kerberos List is run from a client, it shows the:
Ticket-granting ticket (TGT) to a Kerberos Key Distribution Center (KDC) in Windows
Ticket-granting ticket (TGT) to Ksserver on UNIX
Parameters:
Kerberos List uses the following syntax:
klist [tickets | tgt | purge] [-?]
168
Tickets
Lists the current cached tickets of services to which you have authenticated since logging on.
Table 12 displays the following attributes of all cached tickets:
Table 12. Tickets
Option
Description
End Time
Time at which that the ticket becomes invalid. After a ticket is past this time, it
cannot be used to authenticate to a service.
KerbTicket
Encryption Type
Encryption type used to encrypt the Kerberos ticket.
Renew Time
Maximum lifetime of a renewable ticket (see TicketFlags in the table below).

To continue using this ticket, you must renew it before reaching the
established End Time and before the expiration date established in
RenewUntil.
Server
Server and domain for the ticket.

TGT
Lists the initial Kerberos ticket-granting ticket (TGT). Table 13 displays the following attributes
of the currently cached ticket:
Table 13. TGT
Option
Description
AltTargetDomainName Name supplied to InitializeSecurityContext that generated this ticket,

typically a service principal name (SPN).
DomainName
Domain name of the service.
End Time
Time when the ticket becomes invalid. When a ticket is past the end time,
it cannot be used to authenticate to a service.
FullServiceName
Canonical name of the account principal for the service.
KeyExpirationTime
Expiration time from the KDC reply.
RenewUntil Maximum
lifetime of a
renewable ticket (see
TicketFlags)
To continue using a ticket, you must renew it. Tickets must be renewed
before the expiration time set in End Time and in RenewUntil.
ServiceName
A TGT is a ticket for the Key Distribution Center (KDC) service. The service
name for a TGT is krbtgt.
Start time
Time when the ticket becomes valid.
TargetDomainName
For a cross-realm ticket, this is the realm, rather than the issuing realm, in
which the ticket is good.
TargetName
Service name for which the ticket was requested. This is the name of a
servicePrincipalName property on an account in the directory.

169
Option
Description
TicketFlags
Kerberos ticket flags set on the current ticket in hexadecimal. Kerberos

Tray displays these flags on the Flags tab.
TimeSkew
The reported time difference between the client computer and the server
computer for a ticket.
purge
Will list each ticket and enables you to delete specific tickets. When you choose Yes to a
ticket, then purge tickets destroys the ticket that you have cached, so use this with caution. It
might stop you from being able to authenticate to resources. If this happens, you must log off
and then log on again.
-?
Displays command-line help.
Taking Traces
29
A limited version of Network Monitor is included in Windows Server 2003, Windows XP, and
Windows 2000. The full version of Network Monitor is included with Microsoft Systems
Management Server.
Network Monitor is supported for Windows Server 2003, Windows XP, and Windows 2000.
Network Monitor enables you to capture network traces, which can be used in troubleshooting
most network issues. These can help you determine the source of the problem. You can use it
to analyze the Kerberos conversation, to determine name resolution issues, and so on.
LAB 6: Troubleshooting Logon Failures

30
Understand the use of Klist and Kerbtray in working with Kerberos issues.
Troubleshoot and diagnose logon failures.
170
Resources
31
The following articles provide additional information about troubleshooting logon failure:
Windows 2000 Startup and Logon Traffic Analysis Whitepaper
http://www.microsoft.com/technet/prodtechnol/windows2000serv/deploy/confeat/w2k
start.mspx
Summary
32
The differences between a logon failure and an account lockout.
The logon process.
The different error messages returned by different operating systems.
General causes of logon failures and the security issues that cause logon failures.
How to troubleshoot logon failures and the purpose of the utilities that troubleshoot logon
failures.

171
172

Encrypting File System (EFS) provides the core file encryption technology for storing files on
NTFS file system volumes. Security features such as logon authentication and file permissions
protect network resources from unauthorized access. However, anyone with physical access
to a computer such as a stolen laptop can bypass security in the operating system by
installing a new operating system on that computer. In this way, sensitive data can be
exposed. Encrypting sensitive files by means of EFS adds another layer of security. When files
are encrypted, data in them is protected even if an attacker has full access to the data
storage system on the computer. This session explains how to troubleshoot EFS problems.
Before You Begin

1
Have knowledge of security concepts.
Understand the concepts of profiles.
Be familiar with Group Policies.
What You Will Learn

2
Explain the purpose and the working of EFS.
Identify the results of selecting different options when applying changes to files and
folders.
Explain the purpose of public and private keys and the concepts related to encryption.
Identify the limitations and best practices of EFS.
Explain how to use different utilities to troubleshoot EFS problems.
Overview of EFS
3
Windows supports a wide range of privacy standards and provides many features and options
to help ensure user privacy. When communicating over a network, users want to know that
what is sent and received cannot be intercepted or deciphered and that others cannot use
their passwords and other private information. Users also want to be sure that nobody can
access information on their computers without their knowledge. Windows protects privacy in
two key ways: it supports the Internet security and privacy standards; and it provides
encryption and identification capabilities that ensure the data sent or stored cannot be read
or tampered with.

173
The integrity or data authentication function assures that a piece of data originated from a
given entity and that it remains unaltered. Cryptography helps by binding the data to its
originator in such a way that if it is tampered with or accidentally corrupted then it becomes
obvious that this is the case. In some contexts, integrity might be defined only as ensuring that
data remain unaltered from a given point in time.
What Is EFS?
4
EFS addresses security concerns raised by tools available on other operating systems that
allow users to access files stored on an NTFS volume without an access check. With EFS, data
in NTFS files is encrypted on disk. The encryption technology used is public keybased and
runs as an integrated system service, making it easy to manage, difficult to attack, and
transparent to the user. If a user attempting to access an encrypted NTFS file has the private
key associated with that file, the user is able to open the file and work with it transparently as
a normal document. A user without the private key to the file is denied access.
Because EFS is tightly integrated with NTFS, file encryption and decryption are transparent.
When users open a file, it is decrypted by EFS as data is read from disk. When users save the
file, EFS encrypts the data as it is written to disk. Authorized users might not even realize that
the files are encrypted because they can work with the files as they normally do.
The Encryption Process

5
Individual files and file folders (or sub-folders) on NTFS volumes can be encrypted. Although it
is common to refer to file folders as having the encryption attribute set as encrypted, the
folder itself is not encrypted. When encryption is set for a folder, EFS automatically encrypts all
new files created in the folder. All files copied or moved into the folder Offline Files can also be
encrypted.
Note
When offline files are encrypted, the entire offline files database is encrypted rather than
individual files. Individual files do not display the encryption attribute. The database is
encrypted using the startup key for the system.
System files and any files in the %systemroot% folder or its subfolders cannot be encrypted.
No files or directories in a roaming user profile can be encrypted. A file cannot be both
compressed and encrypted. Being compressed does not prevent encryption, but when the file
is encrypted, it is uncompressed.
Note
Encrypting the temp directory can cause some applications to not function properly, and
therefore is not recommended.
EFS does not run if there is no recovery agent certificate, but it does designate a recovery
agent account by default and generates the necessary certificate if you do not. You can use
EFS to encrypt or decrypt data on a remote computer, but you cannot use it to encrypt data
sent over the network.
Other file permissions are unaffected. An administrator, for instance, can still delete a user's
EFS file even though the user cannot open it.
174
Structure of an Encrypted File

6
EFS uses a combination of public key and symmetric key encryption to ensure that files are
protected from all but the most computationally infeasible methods of attack.
EFS follows the standard cryptographic procedure of key encipherment. Data is encrypted
using a symmetric file encryption key (FEK) for speed and then the FEK is secured
asymmetrically for maximum security. When a user requests that a file be encrypted, EFS uses
a uniquely generated FEK to encrypt a file and then encrypts the FEK by using the public key
taken from the user's public key certificate. The encrypted FEK is stored in a file header. When
a user requests decryption, EFS decrypts the FEK using the user's private key, and then uses
the FEK to decrypt the file.
An encrypted file contains encrypted data and a header with fields to store copies of the
encrypted FEK for authorized users and designated data recovery agents (DRA). The structure
for an encrypted file is shown in Figure 37.
Figure 37. Structure of an Encrypted File
Data Decryption Field

An encrypted file contains a minimum of one stored FEK, the FEK encrypted by using the
initial encryptor's public key. The storage field for this encrypted FEK is called the data
decryption field (DDF). Additionally, if an EFS-encrypted file is shared, a copy of the FEK is
encrypted by using the newly authorized user's public key, and the encrypted FEK is
stored in another DDF.
Data Recovery Field

If a computer's effective security policy designates one or more DRA, then copies of the
FEK are encrypted for each DRA using each DRA's public key and stored in another file
header field called the data recovery field (DRF).

175
The Encryption Process

7
When a user encrypts an existing file, the following process occurs:

1. The EFS service opens the file for exclusive access.
2. EFS creates a temporary file in the current directory and carries out the following series
of operations:
a.
Each data stream in the source file is copied to the temporary file for backup
purposes.
b.
Each data stream in the original file is next truncated to a length of zero, and its
length is then set back to its original size. This essentially deletes all the data in the
stream.
c.
EFS writes the encryption metadata to the original file. At this point EFS has the
plaintext data in a temporary file and an empty source file that is marked encrypted
(because of the presence of the EFS metadata).
3. A FEK is randomly generated and used to encrypt the file with the AES, 3DES, or DESX
algorithms, depending on the version of the operating system and the effective security
policy.
4. A DDF is created to contain the FEK encrypted by using the user's public key. In addition:
Note
a.
If a DRA has been designated through Group Policy, a DRF is created to contain the
FEK encrypted by using RSA and the public key of the DRA.
b.
If there are multiple DRAs, a copy of the FEK is encrypted by using the public key of
each DRA, and a DRF is created to store each encrypted FEK.
The file recovery property in the certificate is an example of an enhanced key usage
(EKU) field. An EKU extension and extended property specify and limit the valid uses of a
certificate. File Recovery is one of the EKU fields defined by Microsoft as part of the
Microsoft public key infrastructure (PKI).
5. EFS writes the encrypted data, along with the DDF and the DRF, back to the file. Because
symmetric encryption does not add additional data, file size increase is minimal after
encryption. The metadata, consisting primarily of encrypted FEKs, is usually less than one
byte. File size in bytes before and after encryption is normally reported to be the same.
6. The plaintext temporary file is deleted. Data from deleted files might not be erased when
the file is deleted. The cipher /w command can be used to remove data from available
unused disk space on the entire volume.
176
When a user saves a file to a folder that has been configured for encryption, the process is
similar except that no temporary file is created.
Figure 38 shows the EFS encryption process when a data recovery agent is being used.
Figure 38. EFS Encryption with a DRA
The Decryption Process

8
Conversion to plaintext follows a similar process as for encryption, in that a temporary file is
created and the source file is written to it. The source file is then truncated and the data is
read from the temporary file and written back to the source file in the clear. When an
application accesses an encrypted file, decryption proceeds as follows:
1. NTFS recognizes that the file is encrypted, retrieves the DDF, and passes it to EFS.
2. EFS retrieves the private key belonging to the user from the profile of the user and uses it
to decrypt the DDF and obtain the FEK.
3. EFS then uses the FEK to decrypt sections of the file as needed by the application.
Note
Because EFS uses cipher block chaining, when an application opens a file, only those
sections of the file that the application is using are decrypted. The behavior is different if
the user removes the encryption attribute from the file. In this case, the entire file is
decrypted and rewritten as plaintext.
4. EFS returns the decrypted data to NTFS, which then sends the data to the requesting
application.

177
Figure 39 shows the decryption process:

Figure 39. EFS Decryption
The Recovery Process

9
Data recovery is similar to the decryption process except:
The DRF is used instead of the DDF.
EFS decrypts the DRF with the private key of a DRA to recover the FEK.
The recovery process is as follows:

1. NTFS recognizes the file as encrypted and sends a request to EFS.
2. EFS retrieves the DRF (instead of the DDF) and decrypts the DRF (instead of the DDF)
with the private key of the DRA (instead of the private key of the user) to obtain the FEK.
3. EFS uses the FEK to decrypt the file.
4. NTFS then completes the file request and sends the data to the requesting application.
178
Figure 40 shows the file recovery process:

Figure 40. EFS File Recovery
Examining Results of Selecting Different Options

10
To encrypt a file, check the Encrypt contents to secure data checkbox in the Advanced subdialog and click OK. EFS then converts this file as discussed earlier.
To encrypt a directory, the same steps are followed as for a file. If the directory is empty, an
encrypted flag is set in the directory header telling EFS that any file created in this directory is
to be created encrypted. If the directory is non-empty, another dialog box is displayed, as
shown in Figure 41, asking whether to apply the encryption to this folder only or to this folder,
subfolders and files.

179
Figure 41. Confirm Attribute Changes Dialog Box
Results of Apply Changes to this folder only versus Apply

Changes to this folder, subfolders and files
11
If the Apply changes to this folder only option is selected, then the directory is treated as if it is
empty, and the encrypted flag is set in the directory header. If, however, the Apply changes to
this folder, subfolders and files option is selected, then every file in this directory, and all
subdirectories, is encrypted as discussed above. The encrypted flag is then set for every
subdirectory, including the current directory, in the directory headers.
Adding Additional Users

12
Adding users to a file gives those users cryptographic access to that file. Cryptographic access
means the users are able to decrypt and encrypt the file, as well as add and remove other
users. Having cryptographic access, however, does not imply the users have file-system
access. File-system access is controlled through NTFS file access control lists (ACLs). For a
user to have full access to a protected file, the ACLs must be set to allow a user to access the
file in addition to adding the user being given cryptographic access.
Clicking on the Details button in the Advanced sub-dialog brings up the Encryption Details
dialog shown in Figure 42.
180
Figure 42. Encryption Details Dialog Box
Using the Add button, additional users can be added to the file. Any user that has an EFS
certificate in the current user's Trusted People or Other People certificate store can be added.
The active directory can also be searched for users.
Removing users from a file removes the users' cryptographic access to that file. The process is
the same as adding users. Clicking the Details button in the Advanced sub-dialog brings up
the Encryption Details dialog box.
Using the Remove button, users can be removed from the file. Like when users are added,
removing users only removes cryptographic access to the file. If the file-system ACLs are not
adjusted, then the removed users still have file-system access to the file.

181
Users electing to share encrypted files should remember the following:
Shared EFS files are not file shares. If authorized users need to access shared EFS files
over the network, a file share or a Web folder is required. Alternatively, users can
establish remote sessions with computers that store encrypted files by using Terminal
Services.
Any user who is authorized to decrypt a file can authorize other users to access the file.
Granting access is not limited to the file owner. Caution users to share files only with
trusted accounts, because those accounts can authorize other accounts. Removing the
Write permission from a user or group of users can prevent this problem, but it also
prevents the user or group from modifying the file.
EFS sharing requires that the users who will be authorized to access the encrypted file
have EFS certificates. These certificates can be located in roaming profiles or in the user
profiles on the computer on which the file to be shared is stored , or they can be stored in
and retrieved from Active Directory.
EFS sharing of an encrypted file often means that the file will be accessed across the
network. To enhance the security of file data, it is best if Web folders are used for
encrypted file storage whenever possible.
If a user chooses to remotely access an encrypted file stored on a file share and to
authorize other users to access the file, the authorization process and requirements are
the same as on the local computer. Additionally, EFS must impersonate the user in order
to perform this operation, and all of the requirements for remote EFS operations on files
stored on file shares apply.
If a user chooses to remotely access an encrypted file stored on a Web folder and to
authorize other users to access the file, the file is automatically transmitted to the local
computer in ciphertext. The authorization process takes place on the local computer with
the same requirements as for encrypted files stored locally.
Examining Public and Private Keys

13
EFS uses public key encryption in conjunction with symmetric key encryption to provide
confidentiality for files that resists all but the most sophisticated methods of attack. The FEK
a symmetric bulk encryption key is used to encrypt the file and is then itself encrypted by
using the public key taken from the user's certificate, which is located in the user's profile.
With roaming profiles, the user can decrypt files on any machine (assuming the same key was
used for encryption). With local profiles, you must manually export the key and import on the
new machine. The encrypted FEK is stored with the encrypted file and is unique to it. To
decrypt the FEK, EFS uses the encryptor's private key, which only the file encryptor has.
Public key encryption algorithms use asymmetric keys for encryption and decryption.
Asymmetric means that different keys are used to encrypt and decrypt the same data. Public
key encryption uses a private key (which is held only by its owner) and a public key (which is
available to other entities on the network). A public key, for example, can be published in
Active Directory so that it is accessible to users in the organization. The two keys are separate
but complementary in function. Information that is encrypted with the public key can be
decrypted only with the corresponding private key of the set. The two keys together are called
a key pair or a key set.
182
One drawback of public key cryptography is the amount of processing time that is required for
its mathematical operations. Symmetric key encryption, which uses the same key to both
encrypt and decrypt, is commonly 100 to 1,000 times faster, so symmetric and asymmetric
key encryption are often used together to provide a wide range of network and online
information security solutions. Thus, EFS encrypts data symmetrically with the FEK and then
encrypts and decrypts the FEK asymmetrically with the public key and the private key.
Moving and Copying Encrypted Files and Folders

14
Copying a file into an encrypted folder encrypts the file, but moving it into the folder leaves,
the file encrypted or unencrypted, just as it was before you moved the file.
Moving or copying EFS files to another file system removes the encryption, but backing them
up preserves the encryption.
Examining Local Encryption and Encryption on Remote

Servers
15
If users in your Windows XP or Windows Server 2003 family computing environment want to
store encrypted files on remote servers, it is useful to know the following:
Windows XP and the Windows Server 2003 family support the storage of encrypted files
on remote servers.
Users can use EFS remotely only when both computers are members of the same
Windows Server 2003 family forest.
Encrypted data is not encrypted when in transit over the network, but only when stored
on disk. The exceptions to this are when your system includes Internet Protocol security
(IPSec) or Web Distributed Authoring and Versioning (WebDAV). IPSec encrypts data while
it is transported over a Transmission Control Protocol/Internet Protocol (TCP/IP) network.
If the file is encrypted before being copied or moved to a WebDAV folder on a server, it
will remain encrypted during the transmission and while it is stored on the server.
Encrypted files are not accessible from Macintosh clients.
Storing EFS certificates and private keys on smartcards is not currently supported.
Strong private key protection for EFS private keys is not currently supported.
Before users can encrypt files that reside on a remote server, an administrator must designate
the remote server as trusted for delegation. This allows all users with files on that server to
encrypt those files.

183
Trusted for Delegation

16
To enable a remote server for file encryption:

2. Locate the remote server name, right-click the remote server name, and then click
Properties.
3. Click the Delegation tab.
4. Select the Trust this computer for delegation to specified services only option.
5. From the list of available services, select the Protected Storage service and the Common
Internet File System (CIFS) service.
Note
To perform this procedure, you must be a member of the Domain Admins group or the
Enterprise Admins group in Active Directory, or you must have been delegated the
appropriate authority. When encrypting files on a WebDAV server, the computer does not
need to be trusted for delegation. You cannot configure a computer in another forest for
encryption, even if there is a trust relationship established.
To encrypt a file or folder on a remote computer:

1. Open Windows Explorer.
2. On the Tools menu, click Map Network Drive, and then follow the instructions in the Map
Network Drive dialog box.
3. Right-click the file or folder that you want to encrypt, and then click Properties.
4. On the General tab, click Advanced.
5. Select the Encrypt contents to secure data check box.
Certificates Available
17
Windows 2000/2003 and Windows XP Professional store public key certificates for a user in
the personal certificate store of that user. Certificates can be stored in plaintext because they
are public information, and they are digitally signed by certification authorities to protect
against tampering.
User certificates are located in the Documents and Settings\username\Application Data\
Microsoft\SystemCertificates\My\Certificates folder for each user profile. These certificates
are written to the personal store of the user in the system registry each time the user logs on
to the computer. For roaming profiles, the certificates of users are located in a shared folder
on a server configured by the domain administrator and follow users when they log on to
different computers in the domain.
Certificates are issued by certification authorities (CAs), which verify the identity of entities
before issuing the certificates. EFS issues its own certificates if no CA is available. However,
you can deploy Certificate Services to issue EFS certificates and provide the following benefits:
184
Central certificate management and the publication of certificate revocation lists and the
ability to issue alternate recovery agent certificates to designated user accounts.
18
You can use the Certificates console, a snap-in to Microsoft Management Console (MMC), to
view a user's personal certificate stores. Figure 43 shows an example of a user's personal
store. The certificate for EFS displays Encrypting File System in the Intended Purposes column.
Because users can have more than one certificate that supports EFS user operations, multiple
certificates can appear with Encrypting File System in the Intended Purposes column.
Figure 43. The Certificates Console
19
Recovery agent certificates appear in the personal certificate store for the recovery agent
account. Figure 44 shows an example of the personal certificate store for a recovery agent
account.
Figure 44. The Certificates Console

185
Is the Certificate Valid?

20
Certificates are not expected to be valid indefinitely. Over time, an attacker can determine the
corresponding private key and render the data encrypted with that key vulnerable. Because of
this, certificates have a validity period that defines the length of time during which they can be
considered valid. Once the validity period expires, a new certificate must be obtained to
encrypt new data. However, the existing certificate and private key are normally retained so
older data can still be decrypted.
Certificates can also be revoked by the issuing CA, even when they are still within their validity
period. There are a number of reasons why a certificate could become untrustworthy,
including compromise of the certificate subject's private key or discovery that a certificate was
obtained fraudulently. When a certificate is revoked, it is placed on a certificate revocation list
(CRL) maintained by the CA.
When a file is encrypted, EFS checks the validity period on the certificate of the user as well as
the recovery agent. When a new user is added to an existing file, EFS checks for both the
revocation of the certificate being added and the chaining of the certificate to a trusted root
CA. If the certificate is found to be invalid, (because of expiration, revocation, or inability to
chain) the certificate is not used and the user is typically notified.
Recovery Agents
21
EFS supports data recovery in the sense that it makes it possible for designated DRAs to
decrypt files that user has encrypted. A DRA is established by default on Windows 2000
systems. The DRA is optional on Windows XP Professional and Windows Server 2003 in order
to provide organizations with greater flexibility in implementing data recovery strategies. With
Windows XP Professional and Windows Server 2003, one or more DRAs can be established for
individual computers, for a domain, or for a combination of individual computers and the
domain. However, in no case is the private key of any user revealed to a recovery agent.
In Windows 2000 Active Directory environments, a default recovery policy is configured for a
domain when the first domain controller is set up. The default recovery policy uses a selfsigned certificate to make the domain administrator account the DRA. The domain
Administrator can change the default EDRP if needed.
Using Available Recovery Agents

22
To recover an encrypted file or folder if you are a designated recovery agent:

1. Use Backup or another backup tool to restore a user's backup version of the encrypted
file or folder to the computer where your file recovery certificate and recovery key are
located.
2. Open Windows Explorer.
3. Right-click the file or folder and then click Properties.
4. On the General tab, click Advanced.
186
5. Clear the Encrypt contents to secure data check box.

6. Make a backup version of the decrypted file or folder and return the backup version to
the user.
Note
To open Windows Explorer, click Start, point to All programs, point to Accessories, and
then click Windows Explorer.
You can return the backup version of the decrypted file or folder to the user as an e-mail
attachment, on a floppy disk, or on a network share.
An alternate procedure would involve physically transporting the recovery agent's private key
and certificate, importing the private key and certificate, decrypting the file or folder, and then
deleting the imported private key and certificate. This procedure exposes the private key more
than the procedure above but does not require any backup or restore operations or file
transportation.
If you are the recovery agent, use the Export command from Certificates in MMC to export the
file recovery certificate and private key to a floppy disk. Keep the floppy disk in a secure
location. Then, if the file recovery certificate or private key on your computer is ever damaged
or deleted, you can use the Import command from Certificates in MMC to replace the
damaged or deleted certificate and private key with the ones you have backed up on the
floppy disk.
Adding New Recovery Agents

23
To add a recovery agent for the local computer:

1. Click Start, click Run, type mmc, and then click OK.
2. On the File menu, click Add/Remove Snap-in, and then click Add.
3. Under Add Standalone Snap-in, click Group Policy Object Editor, and then click Add.
4. Under Group Policy Object, make sure that Local Computer is displayed, and then click
Finish.
5. Click Close, and then click OK.
6. In Local Computer Policy, click Public Key Policies.
Found under Local Computer Policy/Computer Configuration/Windows Settings/Security
Settings/Public Key Policies
7. In the details pane, right-click Encrypting File System.
8. Click Add Data Recovery Agent, and then follow the instructions in the Add Recovery
Agent Wizard.
Note
To perform this procedure, you must be a member of the Administrators group on the
local computer, or you must have been delegated the appropriate authority. If the
computer is joined to a domain, members of the Domain Admins group might be able to
perform this procedure.

187
Be prepared to provide the wizard with the user name for a user with a published recovery
certificate. Alternatively, you can use the wizard to browse for .cer files that contain
information about the recovery agent you are adding.
Adding a recovery agent from a file identifies the user as USER_UNKNOWN. This is because
the name is not stored in the file. Before you can add or create a recovery agent, you must
configure Group Policy on your computer.
Examining EFS Limitations

24
By default, Windows XP SP1 (and later) and Windows Server 2003 use the Advanced
Encryption Standard (AES256) algorithm for encrypting files with EFS. Windows 2000 and
versions of Windows XP earlier than SP1 do not support the AES algorithm and cannot access
these files.
Windows 2000 can only use the expanded Data Encryption Standard (DESX) algorithm for EFS
encryption and decryption.
Versions of Windows XP earlier than SP1 can only use the expanded DESX or the TripleDES (3DES) algorithm for EFS encryption and decryption.
Windows XP with SP1 or later can encrypt or decrypt files using DESX, 3DES, or AES.
If you view EFS files using a computer that is running Windows 2000, Windows XP, or
Windows Server 2003 that does not either have any service packs installed, the EFS files may
appear to be corrupted or they may be filled with random characters only. This behavior
occurs if the EFS files were encrypted using either a Windows XP-based computer that has
Service Pack 1 (SP1) or later installed or a computer that is running Windows Server 2003.
Encrypt files by using an algorithm that is supported by the other operating systems that
access the files. To do so:
1. Decrypt all the EFS encrypted files in Windows XP SP1.
2. Locate and then edit the following key in the registry:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\EFS
Value name: AlgorithmID
Data type: REG_DWORD
Radix:
Hexadecimal
Value data: Use any of the values from the following list:
3DES: 0x6603 (This value is compatible with Windows XP and later.)
DESX: 0x6604 (This value is compatible with all versions of Windows 2000
and Windows XP.)
AES_256: 0x6610 (This is the default value. It is compatible with only
Windows XP SP1 and later.)
Group Policy uses FIPS compliant algorithms for encryption, hashing and signing, can also
specify the algorithm.
188
Because the EFS File System Run-Time Library (FSRTL) is located in the Windows operating
system kernel and uses the nonpaged pool to store the FEK, FEKs cannot be leaked to paging
files. However, because the contents of paging files are not encrypted, the plaintext contents
of encrypted files might temporarily be copied to paging files when open for application use. If
the plaintext contents of encrypted files are copied to a paging file, the plaintext remains in
the paging file until the contents are replaced by new data. Plaintext contents can remain in
paging files for a considerable amount of time even after applications close the encrypted
files.
A paging file cannot be encrypted. Paging files are held open by the system that prevents any
user from gaining access to and reading these files while the operating system is running.
However, someone other than the authorized user might start the computer under a different
operating system to read a paging file.
To prevent others from reading the contents of paging files that might contain plaintext of
encrypted files, you can do either of the following:
Disable hibernation mode on your computer.
Configure security settings to clear the paging files every time the computer shuts down.
Recommended Practices
25
Ensure files intended for encryption are created and remain encrypted.
Encrypt folders before creating sensitive files in them for maximum security. Doing this
causes the files to be created as encrypted and their data is never written to the disk as
plaintext.
Encrypt the My Documents folder if you save most of your documents to the My
Documents folder. This ensures that your personal documents are encrypted by default.
For Roaming User Profiles, this should only be done when the My Documents folder is
redirected to a network location.
Encrypt folders instead of individual files so that, if a program creates temporary files
during editing, these are encrypted as well.
Manage private keys to ensure file security.
The designated recovery agent should export the data recovery certificate and private key
to disk, secure them in a safe place, and delete the data recovery private key from the
system. In this way, the only person who can recover data for the system is the person
who has physical access to the data recovery private key.
The number of designated recovery agents should be kept to a minimum. This exposes
fewer keys to cryptographic attack and provides a higher level of assurance that
encrypted data will not be decrypted inappropriately.
Use Microsoft Certificate Services to manage EFS and DRA certificates and private keys.
Caution When configuring Certificate Services and using a custom certificate template to issue
EFS certificates, do not select the Prompt the user during enrollment and require user
input when the private key is used option. This option prevents EFS from using the private
key for encryption or decryption.

189
Provide security and reliability of data at all times.
Encrypt sensitive data on computers that are members of a domain. This protects against
compromise of data though offline cryptographic attacks.
Use Internet Protocol security (IPSec) to ensure that data remains encrypted as it is
transmitted over the network. EFS can be used in conjunction with Web Distributed
Authoring and Versioning (WebDAV) to store encrypted data on the Internet. In addition,
EFS can be used with Server Message Block (SMB) signing to ensure that the
transmission and reception of EFS files across a network is not altered in any way.
Back up the entire server, that stores server-based encrypted data regularly. This ensures
that, in case of data recovery, the profiles that include decryption keys can be restored.
Using Utilities for Troubleshooting EFS Problems

26
The following tools are associated with Encrypting File System.
Using Efsinfo
Encrypting File System Information is a Support Tools command-line tool.
Version compatibility
This tool is compatible with Windows 2000, Windows XP, Windows Server 2003.
Encrypting File System Information displays information about files and folders encrypted with
EFS on partitions that use the NTFS file system. Options include displaying encryption
information about the files and folders in the current folder, recovery agent information, and
certificate thumbnail information.
Example:
C:\EFSINFO /R /U /C /S:<Path>
<directory>: Not Encrypted
efs: Encrypted
Users who can decrypt:
DOMAIN\USER (Account Name / User@domain.com)
Certificate thumbprint: CED5 11D4 5FEA D798 A8B8...
Recovery Agents:
DOMAIN\RECOVERYUSER (Recovery Account Name / RUser@domain.com)
Certificate thumbprint: F6D3 5FD3 8251 BB36 52C1...
efs2: Encrypted
Users who can decrypt:
DOMAIN\USER (Account Name / User@domain.com)
Certificate thumbprint: CED5 11D4 5FEA D798 A8B8...
Recovery Agents:
190
DOMAIN\RECOVERYUSER (Recovery Account Name / RUser@domain.com)

Certificate thumbprint: F6D3 5FD3 8251 BB36 52C1...
Note the certificate thumbprints for the User and the Recovery Agent.
Using SecPol.msc
Local Security Settings is a MMC snap-in that ships with Windows Server 2003, Windows
2000 Server, and Windows XP Professional.
This tool is compatible with Windows 2000, Windows XP Professional, and Windows Server
2003.
Local Security Settings is compatible with Windows Server 2003 and Windows 2000 Server,
and can be used to EFS data recovery agents on computers running Windows Server 2003,
Windows XP Professional, and Windows 2000.
Using Cipher
Cipher is an operating system command-line tool.
This tool is compatible with Windows 2000, Windows XP, Windows Server 2003.
Allows a user or administrator to display or alter the encryption of files. In addition to
encrypting or decrypting a file or folder, Cipher can be used to update the file encryption keys
or the keys of the data recovery agent (DRA) should there be a change in the data recovery
policy.
When used with the /w switch, Cipher can also remove data from portions of the volume it can
access that have not been allocated to files or directories. Cipher does not lock the drive, so
other programs can obtain space on the drive which cipher cannot erase. Because the /w
option writes to a large portion of the volume, it might take a long time to complete and should
only be used when necessary.
Troubleshooting EFS Problems

27
When troubleshooting EFS issues with customers, you will want to ask questions like the
following:
What machine were the files on when they were last encrypted?
Was the machine was joined to the domain when the file was last encrypted?
Has the domain membership changed since?
Have the files been moved since? Where? How?
Was this machine created from an image?
Was sysprep used?
Were any 3rd party tools used on the machine? Sidchange?

191
Were the files encrypted before or after imaging and tools?
Has the machine been rebuilt?
What machined was the user logged onto when the encryption was last initiated?
What user account was used to encrypt the file?
Was it a local or domain account?
Has the account been recreated since?
What account was the EFS recovery agent at the time of encryption?
Has the DRA policy changed from the installation default?
Has the private key been backed up?
Has the first domain controller that was promoted into the domain been rebuilt?
Common Problems with EFS

28
The common problems with EFS are:
Access is denied when trying to access an encrypted file.
Customer is unable to encrypt files
How to Resolve Common EFS Problems?

29
The Access denied message appears when opening an encrypted file.

Cannot access files after disjoining or joining a domain
Access Denied error attempting to access EFS encrypted files
Each user has their own personal store (MY store) for keeping private data like certificates
and associated private keys.
The local user account that you use when logging in to a workgroup machine is a separate
security principal than the domain user account typically used for logon on a domain joined
machine. When you join a computer to a domain that has EFS encrypted files, you must move
(export and import) keys from local account profile to new domain account profile to preserve
EFS access.
Cannot decrypt EFS files after resetting a password
Because of the nature of how DPAPI, data protection API, works, forcefully resetting a
password may lose access to secrets protected by DPAPI. Changing the users password back
to what it was before the reset will generally restore access to the EFS files.
Cannot access remote EFS encrypted files from Windows 9x or Windows NT 4.0 clients
This is by design the server blocks Pre-windows 2000 machines from opening a remote
encrypted file.
192
Access Denied error attempting to access EFS encrypted files

Demoting and re-promoting a Domain Controller will render the copies of EFS keys stored on
that Domain Controller useless. This is true even if there are other Domain Controllers in the
domain.
If the only copy of a recovery agent or user keyset was stored on that domain controller, they
are permanently lost.
This could also mean EFS using a public key certificate encrypted the file, and the associated
private key for this certificate is not available on this computer.
In this case, locate the private key for the appropriate certificate and import it onto this
computer using the Certificates snap-in.
Customer is unable to encrypt files
1. Ensure that the certificate passes the trust and revocation check.
a.
Task: Check trust and revocation for a certificate. This will be reviewed in later
module.
2. Check the EFS Encryption Known Issues section of the EFS troubleshooter, available at
http://winweb/security/pki.
3. If you receive a specific error, search for EFS + (error codes and/or error message) in the
Microsoft knowledgebase.
New Features in Windows 2003

30
EFS in Windows Server 2003 and Windows XP Professional include the following features that
are not available on systems running Windows 2000:
Additional users can be authorized to access encrypted files.
Certificates can be checked for revocation status when encrypted files are shared.
(revocation is checked only when a user is added to an encrypted file)
Offline files can be encrypted.
The Advanced Encryption Standard (AES) and DES (3DES) encryption algorithms are
supported.
Encrypted files can be stored in Web folders using WebDav.
EFS can be used with Windows Server 2003 clusters.
File recovery policy can be configured with greater flexibility.

193
LAB 7: Troubleshooting EFS Problems

31
Configure EFS.
Work with remote EFS Files and DRAs.
Resources
32
The following links provide additional information about troubleshooting EFS problems:
Summary
33
The purpose and the working of EFS.
The results of selecting different options when applying changes to files and folders.
The purpose of public and private keys and the concepts related to encryption.
The limitations and best practices of EFS.
How to use different utilities to troubleshoot EFS problems.
194

Privileges
To ease the task of user account administration, you should assign privileges primarily to
group accounts, rather than to individual user accounts. When you assign privileges to a group
account, users are automatically assigned those privileges when they become a member of
that group. This method of administering privileges is far easier than assigning individual
privileges to each user account when the account is created.
The following table lists and describes the privileges that can be granted to a user.
Table 14. User Privileges
Privilege
Description
Act as part of the operating

system
This user right allows a process to impersonate any user without

authentication. The process can therefore gain access to the same
local resources as that user.
Processes that require this privilege should use the LocalSystem
account, which already includes this privilege, rather than using a
separate user account with this privilege specially assigned. If your
organization only uses servers that are members of the Windows
Server 2003 family, you do not need to assign this privilege to your
users. However, if your organization uses servers running Windows
2000 or Windows NT 4.0, you might need to assign this privilege to
use applications that exchange passwords in plaintext.
Default: Local System
Add workstations to a domain
This security setting determines which groups or users can add

workstations to a domain. This security setting is valid only on
domain controllers. By default, any authenticated user has this right
and can create up to 10 computer accounts in the domain.
Adding a computer account to the domain allows the computer to
participate in Active Directory-based networking. For example,
adding a workstation to a domain enables that workstation to
recognize accounts and groups that exist in Active Directory. This
security setting determines which groups or users can add
workstations to a domain.
This security setting is valid only on domain controllers. By default,
any authenticated user has this right and can create up to 10
computer accounts in the domain.
Adding a computer account to the domain allows the computer to
participate in Active Directory-based networking. For example,
adding a workstation to a domain enables that workstation to
recognize accounts and groups that exist in Active Directory.
Default: Authenticated Users on domain controllers

195
Privilege
Description
Adjust memory quotas for a

process
This privilege determines who can change the maximum memory

that can be consumed by a process.
This user right is defined in the Default Domain Controller Group
Policy object (GPO) and in the local security policy of workstations
and servers.
Default: Administrators
This user right determines which users can bypass file and directory,
registry, and other persistent object permissions for the purposes of
backing up the system.
Default: Administrators and Backup Operators
This user right determines which users can traverse directory trees
even though the user may not have permissions on the traversed
directory. This privilege does not allow the user to list the contents of
a directory, only to traverse directories.
and servers.
Default:
On workstations and servers:
Administrators
Backup Operators
Power Users
Users
Everyone
On domain controllers:
Administrators
Authenticated Users
196
Privilege
Description
This user right determines which users and groups can change the
time and date on the internal clock of the computer. Users that are
assigned this user right can affect the appearance of event logs. If
the system time is changed, events that are logged will reflect this
new time, not the actual time that the events occurred.
and servers.
Default:
Administrators
Power Users
Administrators
Server Operators
Create a pagefile
Allows the user to create and change the size of a pagefile. This is
done by specifying a paging file size for a particular drive under
Performance Options on the Advanced tab of System properties.
Default setting: Administrators
Create a token object
Allows a process to create a token which it can then use to get

access to any local resources when the process uses
NtCreateToken() or other token-creation APIs.
It is recommended that processes requiring this privilege use the
LocalSystem account, which already includes this privilege, rather
than using a separate user account with this privilege specially
assigned
Default setting: No one
Create global objects
This security setting determines which accounts are allowed to

create global objects in a terminal services session.
Default: Administrators and Local System.
Create permanent shared objects Allows a process to create a directory object in the Windows Server
2003 family and Windows XP Professional object manager. This
privilege is useful to kernel-mode components that extend the object
namespace. Components that are running in kernel mode already
have this privilege inherently; it is not necessary to assign them the
privilege.
Default setting: No one

197
Privilege
Description
Debug programs
This user right determines which users can attach a debugger to any
process or to the kernel. Developers who are debugging their own
applications to not need to be assigned this user right. Developers
who are debugging new system components will need this user right
to be able to do so. This user right provides complete access to
sensitive and critical operating system components.
Default setting:
Administrators
Local System
Enable computer and user

accounts to be trusted for
delegation
This security setting determines which users can set the Trusted for
Delegation setting on a user or computer object.
The user or object that is granted this privilege must have write
access to the account control flags on the user or computer object. A
server process running on a computer (or under a user context) that
is trusted for delegation can access resources on another computer
using the delegated credentials of a client, as long as the account of
the client does not have the Account cannot be delegated account
control flag set.
and servers.
Default setting On domain controllers:
Administrators
Force shutdown from a remote

system
This security setting determines which users are allowed to shut

down a computer from a remote location on the network. Misuse of
this user right can result in a denial of service.
and servers.
Default:
On workstations and servers: Administrators
On domain controllers: Administrators, Server Operators
Generate security audits
This security setting determines which accounts can be used by a

process to add entries to the security log. The security log is used to
trace unauthorized system access. Misuse of this user right can
result in the generation of many auditing events, potentially hiding
evidence of an attack or causing a denial of service if the Audit: Shut
down system immediately if unable to log security audits security
policy setting is enabled. For more information, see Audit: Shut down
system immediately if unable to log security audits.
Default: Local System
198
Privilege
Description
Impersonate a client after

authentication
This security setting determines which accounts are allowed to

impersonate other accounts.
Default: Administrators and Service
Increase scheduling priority
This security setting determines which accounts can use a process

with Write property access to another process to increase the
execution priority assigned to the other process. A user with this
privilege can change the scheduling priority of a process through the
Task Manager user interface.
Load and unload device drivers
This user right determines which users can dynamically load and
unload device drivers or other code in to kernel mode. This user right
does not apply to Plug and Play device drivers. It is recommended
that you do not assign this privilege to other users. Instead, use the
StartService() API.
Default setting: Administrators. It is recommended that you not
assign this privilege to any other user. Device drivers run as trusted
(or highly privileged) programs.
Lock pages in memory
This security setting determines which accounts can use a process

to keep data in physical memory, which prevents the system from
paging the data to virtual memory on disk. Exercising this privilege
could significantly affect system performance by decreasing the
amount of available random access memory (RAM).
Default: None. Certain system processes have the privilege
inherently.
Manage auditing and security log This security setting determines which users can specify object
access auditing options for individual resources, such as files, Active
Directory objects, and registry keys.
This security setting does not allow a user to enable file and object
access auditing in general. For such auditing to be enabled, the
Audit object access setting in Computer Configuration\Windows
Settings\Security Settings\Local Policies\Audit Policies must be
configured.
You can view audited events in the security log of the Event Viewer.
A user with this privilege can also view and clear the security log.

199
Privilege
Description
Modify firmware environment

values
This security setting determines who can modify firmware

environment values. Firmware environment variables are settings
stored in the nonvolatile RAM of non-x86-based computers. The
effect of the setting depends on the processor.
On x86-based computers, the only firmware environment value
that can be modified by assigning this user right is the Last
Known Good Configuration setting, which should only be
modified by the system.
On Itanium-based computers, boot information is stored in
nonvolatile RAM. Users must be assigned this user right to run
bootcfg.exe and to change the Default Operating System setting
on Startup and Recovery in System properties.
On all computers, this user right is required to install or upgrade
Windows.
Default setting:
Administrators
Local System
Profile a single process
This security setting determines which users can use performance

monitoring tools to monitor the performance of nonsystem
processes.
Default: Administrators, Power users, Local System
Profile system performance
This security setting determines which users can use performance

monitoring tools to monitor the performance of system processes.
Default: Administrators, Local System
Remove computer from docking

station
This security setting determines whether a user can undock a

portable computer from its docking station without logging on.
If this policy is enabled, the user must log on before removing the
portable computer from its docking station. If this policy is disabled,
the user may remove the portable computer from its docking station
without logging on.
Default: Disabled
Replace a process level token
Determines which user accounts can initiate a process to replace

the default token associated with a started subprocess.
Policy object and in the local security policy of workstations and
servers.
Default setting: Local Service and Network Service
200
Privilege
Description
This security setting determines which users can bypass file,

directory, registry, and other persistent objects permissions when
restoring backed up files and directories and determines which
users can set any valid security principal as the owner of an object.
Specifically, this user right is similar to granting the following
permissions to the user or group in question on all files and folders
on the system:
Traverse Folder/Execute File
Write
Default:
Workstations and servers: Administrators, Backup Operators
Domain controllers: Administrators, Backup Operators, Server
Operators
This security setting determines which users who are logged on

locally to the computer can shut down the operating system using
the Shut Down command. Misuse of this user right can result in a
denial of service.
Default:
Workstations: Administrators, Backup Operators, Power Users,
Users
Servers: Administrators, Backup Operators, Power Users
Domain controllers: Account Operators, Administrators, Backup
Operators, Server Operators, Print Operators
Synchronize directory service

data
This security setting determines which users and groups have the
authority to synchronize all directory service data. This is also known
as Active Directory synchronization.
Defaults: None
Take ownership of files or other

objects
This security setting determines which users can take ownership of

any securable object in the system, including Active Directory
objects, files and folders, printers, registry keys, processes, and
threads.
Default setting: Administrators
Some privileges can override permissions set on an object. For example, a user logged on to a
domain account as a member of the Backup Operators group has the right to perform backup
operations for all domain servers. However, this requires the ability to read all files on those
servers, even files on which their owners have set permissions that explicitly deny access to
all users, including members of the Backup Operators group. A user right--in this case, the
right to perform a backup--takes precedence over all file and directory permissions.

201
Logon Rights
The following table lists and describes logon rights.
Table 15. Logon Rights
Logon Right
Description
Access this
computer from a
network
This user right determines which users and groups are allowed to connect to the
computer over the network. Terminal Services are not affected by this user right.
Default:
Administrators
Backup Operators
Power Users
Users
Everyone
Administrators
Authenticated Users
Everyone
Allow log on locally
This logon right determines which users can interactively log on to this computer.
Logons initiated by pressing CTRL+ALT+DEL on the attached keyboard requires
the user to have this logon right. Additionally this logon right may be required by
some service or administrative applications that can log on users. If you define
this policy for a user or group, you must also give the Administrators group this
right.
Default:
On workstations and servers: Administrators, Backup Operators, Power
Users, Users, and Guest.
On domain controllers: Account Operators, Administrators, Backup
Operators, Print Operators, and Server Operators.
Allow log on through This security setting determines which users or groups have permission to log on
Terminal Services
as a Terminal Services client.
Default:
On workstation and servers: Administrators, Remote Desktop Users
On domain controllers: Administrators
Deny access to this
computer from
network
This security setting determines which users are prevented from accessing a
computer over the network. This policy setting supersedes the Access this
computer from the network policy setting if a user account is subject to both
policies.
Default: No one
202
Logon Right
Description
Deny log on as a
batch job
This security setting determines which accounts are prevented from being able to
log on as a batch job. This policy setting supersedes the Log on as a batch job
policy setting if a user account is subject to both policies.
Default: None.
Deny logon as a
service
This security setting determines which service accounts are prevented from
registering a process as a service. This policy setting supersedes the Log on as a
service policy setting if an account is subject to both policies.
Note: This security setting does not apply to the System, Local Service, or Network
Service accounts.
Default: None.
Deny log on locally
This security setting determines which users are prevented from logging on at the
computer. This policy setting supersedes the Allow log on locally policy setting if
an account is subject to both policies.
Important: If you apply this security policy to the Everyone group, no one will be
able to log on locally.
Default: None.
Deny log on through This security setting determines which users and groups are prohibited from
Terminal Services
logging on as a Terminal Services client.
Default: None.
Log on as a batch
job
This security setting allows a user to be logged on by means of a batch-queue

facility.
For example, when a user submits a job by means of the task scheduler, the task
scheduler logs that user on as a batch user rather than as an interactive user.
Note: In Windows 2000 Server, Windows 2000 Professional, Windows Server
2003 and Windows XP Professional, the Task Scheduler automatically grants this
right as necessary.
Default: Local System.
Log on as a service
This security setting determines which service accounts can register a process as
a service.
Default: None.
Note
The default settings listed above are for Windows XP Professional and the Windows
Server 2003 family.

203
Default settings for Security Options Policies on a local computer are described in the
following table.
Table 16. Default Settings for Security Options Policies
Policy
Local Setting
Additional restrictions for anonymous connections
Rely on default permissions (none set by

default)
Allow server operators to schedule tasks (domain

controllers only)
Not defined
Allow system to be shut down without having to log on
Enabled
Allowed to eject removable NTFS media
Administrators
Amount of idle time required before disconnecting session
15 minutes
Audit the access of global system objects
Disabled
Audit use of Backup and Restore privilege
Disabled
Automatically log off users when logon time expires (local)
Enabled
Clear virtual memory pagefile when system shuts down
Disabled
Digitally sign client communication (always)
Disabled
Digitally sign client communication (when possible)
Enabled
Digitally sign server communication (always)
Disabled
Digitally sign server communication (when possible)
Disabled
Disable CTRL+ALT+DEL requirement for logon
Not defined
Do not display last user name in logon screen
Disabled
LAN Manager Authentication Level
Send LM and NTLM responses
Message text for users attempting to log on
<None>
Message title for users attempting to log on
<None>
Number of previous logons to cache (in case domain

controller is not available)
10 logons
Prevent system maintenance of computer account

password
Disabled
Prevent users from installing printer drivers
Disabled
Prompt user to change password before expiration
14 days
Recovery Console: Allow automatic administrative logon
Disabled
Recovery Console: Allow floppy copy and access to all drives Disabled
and all folders
Rename administrator account
Not defined
Rename guest account
Not defined
Restrict CD-ROM access to locally logged-on user only
Disabled
Restrict floppy access to locally logged-on user only
Disabled
Secure channel: Digitally encrypt or sign secure channel

data (always)
Disabled
Secure channel: Digitally encrypt secure channel data

(when possible)
Enabled
204
Policy
Local Setting
Secure channel: Digitally sign secure channel data (when

possible)
Enabled
Secure channel: Require strong (Windows 2000 or later)

session key
Disabled
Send unencrypted password to connect to third-party SMB

servers
Disabled
Shut down system immediately if unable to log security

audits
Disabled
Smart card removal behavior
No Action
Strengthen default permissions of global system objects (for Enabled

example, Symbolic Links)
Unsigned driver installation behavior
Not defined
Unsigned non-driver installation behavior
Not defined

205
206

PWorkbook DirectoryServices NewHire Week3

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

PWorkbook DirectoryServices NewHire Week3

Загружено:

Авторское право:

Доступные форматы

Readiness and Sustained Education

Supporting Windows Operating Systems:

This Workbook provides reference material to accompany course presentations.

Released: 17 June 2005

MICROSOFT CONFIDENTIAL - For Internal Use Only

MICROSOFT CONFIDENTIAL - For Internal Use Only

Supporting Windows Operating Systems: Directory Services New Hire Week 3

2005 Microsoft Corporation. All rights reserved.

About This Course Week 3 .................................................................................................... 1

1. Troubleshooting Security Problems .................................................................................... 5

LAB 1: Troubleshooting Security Problems..................................................................... 27

Supporting Windows Operating Systems: Directory Services New Hire Week 3

2005 Microsoft Corporation. All rights reserved.

Advantages of Windows 2000 Group Policies.......................................................... 56

Common Security CSE Events ..............................................................................88

4. Troubleshooting User Profile Problems ............................................................................ 95

Supporting Windows Operating Systems: Directory Services New Hire Week 3

2005 Microsoft Corporation. All rights reserved.

Using Utilities for Troubleshooting Problems with User Profiles................................. 111

5. Troubleshooting Account Lockout Problems .................................................................115

The EventcombMT.exe Tool .............................................................................................. 121

6. Troubleshooting Logon Failures...................................................................................... 121

7. Troubleshooting EFS Problems ....................................................................................... 121

Supporting Windows Operating Systems: Directory Services New Hire Week 3

2005 Microsoft Corporation. All rights reserved.

Table 1. Note Icons ................................................................................................................................................. 3

Supporting Windows Operating Systems: Directory Services New Hire Week 3

Table 13. TGT...................................................................................................................................................... 121

Figure 1. Slide Number Paragraphs .......................................................................................................................4

Supporting Windows Operating Systems: Directory Services New Hire Week 3

2005 Microsoft Corporation. All rights reserved.

About This Course Week 3

About This Course Week 3

Before You Begin

Before starting this course, you should:

Have successfully completed the previous modules in this course.

Understand the concepts discussed and examined in the previous modules.

What You Will Learn

Course materials include the following <multimedia | classroom> presentations, a Workbook

About This Course Week 3

2. Troubleshooting Trust Problems

Acronyms appear in all uppercase letters.

Filename extensions without a filename appear in all lower-case letters.

Book titles appear in Italic.

Other document conventions are described below.

Supporting Windows Operating Systems: Directory Services New Hire Week 3

2005 Microsoft Corporation. All rights reserved.

About This Course Week 3

Program Code Listings and Command Syntax

Command syntax statements are formatted as shown below:

Italic in command syntax statements indicates placeholders for variable information.

Braces ({ }) enclose required items as shown by {parameter1, parameter2,

Square brackets ([ ]) enclose optional items as shown by [option1 | option2] in

Provides supplemental information such as related actions or results

Suggests alternate methods of performing tasks

Important Provides information that is essential to completing a task

Warns about possible loss of data or other undesirable results

Supporting Windows Operating Systems: Directory Services New Hire Week 3

About This Course Week 3

Demonstrations and Labs

Tables and Figures

Workbook Section and Slide Numbering

Each presentation slide corresponds to a workbook section. However, workbook sections

Supporting Windows Operating Systems: Directory Services New Hire Week 3