SANS Security 505.1 Securing Active Directory & DNS

Copyright 02010, The SANS Institute. All rights reserved.
The entire contents of this

publication are the property of the SANS Institute.
IMPORTANT-READ CAREFULLY:
This Courseware License Agreement (TLA") is a legal agreement between you (either
an individual or a single entity; henceforth User) and the SANS Institute for the personal,
non-transferable use of this courseware. User agrees that the CLA is the complete and
exclusive statement of agreement between The SANS Institute and you and that this CLA
supersedes any oral or written proposal, agreement or other coinmunication relating to
the subject matter of this CLA. If any provision of this CLA is declared unenforceable in
any jurisdiction, then such provision shall be deemed to be severable from this CLA and
shall not affect the remainder thereof. An amendment or addendum to this CLA may
accompany this courseware. BY ACCEPTING THIS COURSEWARE YOU AGREE TO
BE BOUND BY THE TERMS OF THIS CLA. IF YOU DO NOT AGREE YOU MAY
RETURN IT TO THE SANS INSTITUTE FOR A FULL REFUND, IF APPLICABLE.
The SANS Institute hereby grants User a non-exclusive license to use the material
contained in this courseware subject to the terms of this agreement. User may not copy,
reproduce, re-publish, distribute, display, modify or create derivative works based upon
all or any portion of this publication in any medium whether printed, electronic or i-
otherwise, for any purpose without the express written consent of the SANS Institute.
Additionally, user may not sell, rent, lease, trade, or otherwise transfer the courseware in
any way, shape, or form without the express written consent of the SANS Institute.
The SANS Institute reserves the right to terminate the above lease at any time. Upon
termination of the lease, user is obligated to return all materials covered by the lease
within a reasonable amount of time.
V2010 0125 rev1

_.
SANS Institute works extremely hard to continuously improve both the quality of courseware and instruction. The
evaluation forms that we provide daily are one of the most effective methods to help improve the course and to give
feedback to the instructors. The numerical score helps us track trends,and the written comments give us the context
to make immediate improvements. We truly appreciate the time you take to provide this feedback.
Some things to remember: 10 = very good, 1 = very bad!
3 4
Value of Course Content:

or
2 3 4 5 6 7 8
Please make every effort to score each of these areas individually and write comments which you feel are relevant
or important in the comments section. If a lab does not work on your computer system, please reflect that in the
course content score, and please give us any information you have as to what went wrong so we make appropriate
corrections to our courseware. Rest assured that all eval comments are read by the senior management a t SANS.
Evaluations are used to adapt the course and make it even better,so please do fill them in! If you have specific
comments regarding the venue, snacks, etc., we have provided a separate evaluation specifically for those areas.
Some people do not believe in giving 1Os, and that is fine. However, please keep in mind that delivering a course is a
performance, and performers work harder when they are motivated. If and only if your course is on par with the best
instruction you have ever received a 10 is appropriate.
If you give the overall course andlor course content a low score, please explain why in the comments field so we can
adapt.You can also be assured if you explain your concerns to an event manager we will be discreet. If you are willing,
please sign your name at the bottom of the evaluation. If you are having difficulties, SANS can quickly come to your
aid if we know who you are. In addition, we also routinely use quotes from previous students in upcoming brochures. If
you do not want to be quoted, please let us know.
Thank you for your thoughtful consideration,
Eric Bassel, Mason Brown, Stephen Northcutt, and Alan Paller

This page intentionally left blank.
Securing Active Directory & Windows DNS
www.sans.org 02010
2 Active Directory & DNS
All reasonable and good faith efforts have been exerted to verify that the information in this
document is accurate and up-to-date. However, new software releases, new developments, new
discoveries of security holes, new publications hom Microsoft or others, etc. can obviate at any
time the accuracy of the information presented herein.
Neither the SANS Institute nor GIAC provide any warranty or guarantee of the accuracy or
usefulness for any purpose of the information in this document or associated files, tools or scripts.
Neither the SANS Institute, GIAC nor the author(s) of this document can be held liable for any
damages, direct or indirect, financial or otherwise, under any theory of liability, resulting from the
use of or reliance upon the information presented in this document at any time.
This document is copyrighted (2010) and is the exclusive property of the SANS Institute
(www.sans.org). Reproductions of this document in any number, in any form, in whole or in part,
is expressly forbidden without prior written authorization.
Microsoft, MS-DOS, MS, Windows, Windows NT, Windows 2000, Windows XP, Windows
2003, Active Directory, Internet Information Server, IIS, Group Policy, and Proxy Server are
either registered trademarks or trademarks of Microsoft Corporation in the United States and/or
other countries. Fortezza is a registered trademark of the National Security Agency. Netscape
Navigator is a product and trademark of Netscape Corporation. The pineal gland is what Rene
Descartes thought linked the immaterial soul to the material body, for how else could something
non-material cause the material body to change? Apache is a product and trademark of the
Apache Software Foundation. Kerberos is a trademark of the Massachusetts Institute of
Technology. iPlanet is a product and trademark of Netscape Corporation. Lotus Notes is a
product and trademark of International Business Machines Corporation.
Other product and company names mentioned herein may be the trademarks of their respective
owners.
The legal consequences of any actions discussed in this document are unknown. No lawyers or
legal experts participated in the writing of any part of this document. Readers are advised to
consult with their attorney before implementing any of the suggestions in this document.
SANS Institute
Active Directory & DNS 3
Network security is something produced by a community. Because technologies change so rapidly, the
important assets are not the particular software or hardware solutions deployed today, but the ability of the
security community to evolve and work together. It is part of the mission of the S A N S Institute to facilitate
this. This manual is a community document in that it was written with reliance upon the prior work of
others and is updated regularly with the input of the security community members who use it. That means
you.
If you find a significant error offact or an important omission which would clearly add value to the
document, please e-mail the contact listed below. If your suggestion is incorporated, we would be pleased
to list your name as a contributor.
Document Contact: Jason Fossen (Jason@EnclaveConsulting.com)

Document Version: 12.4
Last Modified: 6-Oct-2009
Contributors:
Jason Fossen (www.EnclaveConsu1ting.com):author.
Brendan Moon (Compaq): changes for added clarity and technical correctness.
Lora Fulton (Boston University): dssec.dat file for AD permissions.
Rick Tuey (Logicon): good suggestions for user-hiendliness.
Holly Villanueva (JCPenney's): loopback adapter issues corrected.
Scott Crawford (Evangel University): table of Alt characters for passwords.
Bill Boswell (winconsultants.com): AD permissions inheritance, slow RPC connection object facts.
Mike Forrester (HAS Corp): LDAPMINER.EXE
Christian Gauthier (Quebec): Delegwkinf
John Vanmeter (DOT): SecureResponses registry value.
George Garner (erols.com): NTFS 3.0 for 2000, and 3.1 for XP.
Urity (http://www.securityfriday.com/Topics/win2k~passwd.html): 15-t character passwords, LM hashes.
Ken Hoover (Yale University): excellent info about migrations to AD and DNS.
Dustin Decker (Mission, Kansas): numerous recommendations for additions.
Michael St.Vincent (Deloitte & Touche): time sync issues and tips.
Nelly Chien (consultant): syskey tip.
David Roncaglia (Autodesk): AdminSDHolder permissions.
Vladimir Markovic (SWS Securities): forcing TCP for Kerberos.
Walter Jones (McKesson): setting IockoutTime = 0 and KB294952.
Jason Felix ( D E N ) : correction to syskey behavior.
Matthew Arnold (Human): updates to SFU 3.5.
Scott Fendley (ISC): screenshots of DCPROMO, Support Tools, and loopback adapter (thanks!).
Dave Stevens (Carnegie Mellon): IU3324949 for how to change default location for new objects.
Seth Robertson (Aegis Mortgage): event log max size of 300MB for auditing AD.
David Hoelzer (Cyber-Defense): "local resource already in use" error message.
Sean Lynn (MITRE): BSOD may contain system key.
Elizabeth Aebersold (UT-Austin): great recommendations for smoother EDU on-sites.
David Perez (Human): lots of misc updates, including the dsHeuristicsproperty in AD.
Ryan Giles (Human): Changing the default User and Computers containers (ISB324949).
Christian Gigandet (Human): Multiple fixes in this document and others.
SANS institute
Table of Contents ................................................................................................................ 4

Websites. Utilities. Articles and Advisories Mentioned in The Course ............................. 6
The 20 Critical Security Controls ....................................................................................... 7
What To Expect .................................................................................................................. 9
Active Directory Tools ..................................................................................................... 11
Security Begins With Physical Security ........................................................................... 17
Encrypt Hashes And Keys With SYSKEY.EXE.............................................................. 20
Encrypt Entire Drive With BitLocker (2008) ................................................................... 24
Read-only Domain Controllers (2008 or Later) ............................................................... 26
Backups For Disaster Recovery and Auditing .................................................................. 34
Configure Fault-Tolerant Replication Pathways .............................................................. 38
Securing Replication Traffic ............................................................................................. 45
Prevent Unwanted Changes To The Schema.................................................................... 49
Operations Masters ........................................................................................................... 53
Today’s Agenda ................................................................................................................. 59
Active Directory Permissions ........................................................................................... 60
AD Access Control List Tools .......................................................................................... 66
Delegation of Control ....................................................................................................... 70
Delegation Example: Resetting Passwords ....................................................................... 74
Delegation Example: Editing Selected Properties ............................................................ 77
Custom MMC Consoles .................................................................................................... 80
Delegation Example: Joining Computers ......................................................................... 86
Delegation Example: Full Control Over An OU .............................................................. 90
Delegation Example: Limiting Enterprise Admins.......................................................... 93
Auditing Access to Active Directory ................................................................................ 96
Directory Service Change Auditing (2008) .................................................................... 100
Today’s Agenda............................................................................................................... 103
How Does The Forest Design Affect Security? .............................................................. 104
External Trusts ................................................................................................................ 107
Intra-Forest Trusts ........................................................................................................... 110
Cross-Forest Trusts (2003 or Later) ................................................................................ 113
Scenario: Federation And Selective Authentication ....................................................... 117
Scenario: Empty Root Domain Forests ........................................................................... 122
Scenario: Extranet Forests .............................................................................................. 126
Extranet Forest Firewall And IPSec Considerations ...................................................... 131
When To Create More Forests ........................................................................................ 135
When To Create More Domains ..................................................................................... 137
Today’s Agenda .............................................................................................................. 140
DNS Tools ...................................................................................................................... 141
Active Directory Integration of DNS .............................................................................. 144
Unix BIND Interoperability ............................................................................................ 147
SRV Resource Records ................................................................................................... 151
Secure Dynamic Updates ................................................................................................ 154
SANS Institute
DNS Security Best Practices........................................................................................... 160

Appendix A: Becoming A Domain Controller ............................................................... 168
Appendix B: Universal and Native-Mode Groups .......................................................... 177
Appendix C: Kerberos .................................................................................................... 181
AS Exchange: Getting A Ticket Granting Ticket ........................................................... 188
TGS Exchange: Getting A Session Ticket ...................................................................... 192
Client/Server Exchange: Authenticating......................................................................... 194
Kerberos Delegation And Forwarded TGTs ................................................................... 198
Fine-Tuning Kerberos ..................................................................................................... 202
MIT Kerberos Interoperability Overview ....................................................................... 205
Appendix D: Shortcut Trusts .......................................................................................... 209
Appendix E: NTLMv2 Authentication ........................................................................... 213
SANS institute
6 Active Directorv & DNS
1 Microsoft Windows Server I httD://www.microsoft.com/windowsserver/

I Active Directory Technical I http://www.microsoft.com/activedirectory/ I
Documents from Microsoft
MSDN Library http://msdn2.microsoft.com/library/
Win32 ActivePerl http://www.activestate.com
Espionage Act of 1996 http://www.fas.org/irp/congress/l996rpth104359.htin
When a KB-number is referenced in the course, e.g., KB188806, this refers to a

Microsoft KnowledgeBase or TechNet article. These articles can be found either in one's
TechNet subscription CD-ROMs or at http://search.microsoft.com.
cronyms an reviati o 11s

AD = Active Directory (ntds.dit)
DACL = Discretionary Access Control List (permissions)
DC = Domain Controller (dcpromo.exe)
DFS = Distributed File System
FSMO = Flexible Single Mode Operation (a DC role)
GC = Global Catalog (index of AD)
GPO = Group Policy Object
MMC = Microsoft Management Console (rnmc.exe)
NC = Naming Context (a part of the Active Directory database)
NETLOGON = A folder shared as NETLOGON (part of SYSVOL).
OU = Organizational Unit (subdivision of a domain)
RODC = Read-only Domain Controller
SACL = System Access Control List (auditing)
SYSVOL = A folder shared as SYSVOL with scripts and GPOs.
Snap-In = MMC snap-in tool (e.g., AD Users and Computers)
ecommende
Active Directory Cookbook, by Robbie Allen (O'Reilly, www.rallenhome.com).
Active Directory: Designing, Deploying and Running, by Desmond, Richards, Allen and
Lowe-Norris (O'Reilly).
"Planning Active Directory for Branch Office Environments" (Microsoft whitepaper).
The entire Wroducts & Technologieskctive Directory section in the TechNet library.
SANS Institute
Active Directorv & DNS 7
The SANS Institute is a partner in the 20 Critical Security Controls: Consensus Audit
Guidelines project (http://www.sans.org/cag/). The 20 Critical Security Controls are the
most important parts of NIST's Special Publication 800-53,Recommended Security
Controls for Federal Information Systems and Organizations, and can be applied to any
type of network, Federal or otherwise (http://csrc.nist.gov/publications/PubsSPs.html).
But how do you implement these controls when you have thousands of Windows systems
to secure? This course will help you to enforce these controls as they pertain to the
configuration of Microsoft Windows servers, workstations and laptops in an Active
Directory environment. Not all of the controls relate to operating system hardening
though, such as the controls related to firewall design, but many of the controls do, and
this week-long course will show you many techniques for enforcing them.
s?
Full descriptions of the 20 Critical Security Controls can be found on the SANS web site
(http://www.sans.org/cag/)and in the SANS two-day course which discusses them
(SEC440), but here is a listing of the names of the controls:
evant to this course
Control 1: Inventory of Authorized and Unauthorized Devices
Control 2: Inventory of Authorized and Unauthorized Software
SANS Institute
Control 3: Secure Configurations for Hardware and Software on Laptops,

Workstations, and Servers
Control 4: Secure Configurations for Network Devices such as Firewalls, Routers,

and Switches
Control 5 : Boundary Defense
Control 6: Maintenance, Monitoring, and Analysis of Audit Logs
Control 7: Application Software Security
Control 8: Controlled Use of Administrative Privileges
Control 9: Controlled Access Based on Need to Know
Control 10: Continuous Vulnerability Assessment and Remediation
Control 11: Account Monitoring and Control
Control 12: Malware Defenses
Control 13: Limitation and Control of Network Ports, Protocols, and Services
Control 14: Wireless Device Control
Control 15: Data Loss Prevention
Control 16: Secure Network Engineering
Control 17: Penetration Tests and Red Team Exercises
Control 18: Incident Response Capability
Control 19: Data Recovery Capability
Control 20: Security Skills Assessment and Appropriate Training to Fill Gaps
Many of the tools you need to enforce these controls are either built into Windows Server
by default or are free to download, so you don't always have to spend a fortune on third-
party products to achieve good security. Throughout the week we'll talk about many t
security recommendations and technologies, and then I'll mention how they map onto the
20 Critical Security Controls as the controls relate to Windows security.
SANS Institute
This course discusses intermediate to advanced security topics for Microsoft Active
Directory, with a special focus on securing replication channels, delegation of authority,
and forest trust design. This course also discusses the security features of Active
Directory-integrated DNS servers with secure dynamic updates.
irectory is the foundational security service in Windows environments,

providing a directory service infrastructure upon which virtually all other security
and management features depend. Almost everything you will learn about
Windows security will assume you have and understand Active Directory.
Physically secure the Active Directory database.

Design a forest of one or more domains with security in mind.
Secure your FSMO Master and Global Catalog servers.
Secure the Active Directory Schema.
Delegate authority safely over users and computers in OUs.
Replicate Active Directory over insecure networks like the Internet.
Secure your Windows DNS servers.
c ?
Note that this is not an "Introduction to Active Directory" course. If you've never seen
Active Directory in your life, then you will struggle a little during the seminar. However,
SANS Institute
with only a little bit of experience or background reading you can benefit from the
seminar greatly. Just pick up any short Active Directory book at the bookstore, or
download some of Microsoft's free Active Directory whitepapers (from
http://www.microsoft.com/activedirectory/),and you'll be fine.
out migration strategies from earlier versions?

Unfortunately, there is not enough time in the seminar to cover migration strategies too.
This course does not discuss migration in any way.
Try It !Exercises
Throughout the courseware you will see "TryIt Now!" exercises. If you have a
Windows Server laptop computer with you, you are welcome to follow the exercises. If
you do not, then the exercises will be demonstrated by the instructor and there are
numerous screenshots to illustrate the tools. You can also do the exercises later when
you do have access to a Windows Server.
ttendee Com
A Windows Server laptop is not required for attending this course. Typically, 50% to
75% of the audience will not have Windows Server installed on their laptops and that's
fine. But if you do have such a laptop, make the following configuration changes to help
ensure you can more enjoyably follow the Try It Now! exercises with the instructor.
Have Windows Server Enterprise installed in a VM (2008 or later).
Have that Windows Server DVD with you.
Configure the VM with a fixed IP address: 10.1.1.1
Install DNS and be a DNS client to your own IP address: 10.1.1.1
Install SUPTOOLS.MS1 from the \Support\Tools folder on the Windows DVD.
Apply the latest Service Pack and reboot.
Promote your machine to a domain controller. (Follow the steps in Appendix A if
you have never done this before.)
SANS Institute
- REPLMON.EXE
- REPADMIN.EXE
- LDIFDE.EXE
- NTDSUTIL.EXE
- Powershell Cmdlets
- www.JoeWare.net
- www.Rallen~ome.com
There are a variety of graphical and command-line tools for managing Active Directory.
Most of these tools will be installed by default after you run Server Manager and
DCPROMO.EXE to install Active Directory. Others are a part of various Microsoft
Resource Kits, downloaded separately from Microsoft’s website or obtained from various
third-party websites. Hence, just expect that you’ll need to build your own personal
collection of binaries and scripts to keep in your AD toolbox. If you can’t find one of the
tools below, just Google the filename.
et s:
Active Directory Users and Computers
Active Directory Domains and Trusts
Active Directory Sites and Services
Active Directory Schema
Group Policy Management (GPMC)
Note that the Schema Manager snap-in cannot be installed until its DLL (schmmgmt.dl1)
has been registered with the operating system using REGSVR32.EXE. Follow the
instructions in the next T v It Now! exercise to do so.
Go to the Run line and execute “regsvr32.exe schmmgmt .dll”> click OK in the
dialog box that appears. Now execute “mmc.exe”at the Run line > Console menu >
SANS institute
Add/Remove Snap-In > Add > Active Directory Schema. Add all of the above snap-in
tools to your console and save it to your desktop as "AD Tools".
Actwe Directory Sites and Services

Local Computer Policy Security Configurabon and Analysis
Security Templates
Zecurity Configurabon and Analysis
Security Templates
Note too that in Windows Server 2008 and later, you can stop and restart Active
Directory Domain Services just like any other service. This is useful, for example, for
patching and performing defragmentation of the AD database without the necessity of
rebooting into Directory Services Restore Mode (a type of Safe Mode).
Remote Sewer dministration Tools (RS

A package of tools can be downloaded from Microsoft for free to be installed on
Windows Vista or later for the sake of administering Active Directory and Server 2008 or
later (KB9413 14). This package is called the "Remote Server Administration Tools
(RSAT)" and it comes in both 32-bit and 64-bit versions. Installing RSAT is also how to
install the Group Policy Management Console (GPMC) on Vista+SPl or later.
DCPROMO.EXE -- Wizard to convert a server into a domain controller.

LDP.EXE -- LDAP query and edit utility (see KB224543).
REPLMON.EXE -- Display and manage replication and links (see REPADMIN).
Note: Not all the tools listed here are installed by default. Please do a search of
Microsoft's site on the tool's name to find the latest version and URL.
SANS Institute
Active Directorv & D N S 13
B Default-First-Site-Name
a l$'Gc;oDZILLA
CN=Sche rn R CN=Confi guration, D C=mo nstert s land, D C=co m
CN=Configuration,DC=monsterisland,DC=co in
DC=monsterisland,DC=com
001s:
ermissions and Trusts
ACLDIAG.EXE -- Displays permissions on AD objects.
DSACLS.EXE -- Manage ACLs on AD objects (good for scripts!).
DSREVOKE.EXE -- View or delete AD permissions.
ENUMPROP.EXE -- LDAP and permissions browser.
SDCHECK.EXE -- Checks the Security Descriptor of AD objects.
NETDOM.EXE -- Manage trusts and computer domain memberships.
NLTEST.EXE -- Manage NetLogon service and DCs, updated for AD.
mpor
data to a comma-delimited text file.
LDIFDE.EXE -- Import/export bulk AD data to a text file (KB237677).
MOVETREE.EXE -- Move objects between domains.
DSADD.EXE -- Add objects to AD.
DSGET.EXE -- Display properties of selected AD objects.
DSMOD.EXE -- Modify objects in AD.
DSMOVE.EXE -- Move or rename objects in AD.
DSQUERY.EXE -- Find types of objects in AD.
DSRM.EXE -- Remove or delete objects in AD.
nsive troubleshooting diagnostics.

DNSCMD.EXE -- Troubleshooting and managing DNS.
DSASTAT.EXE -- Compares AD data between multiple servers.
DSMGMT.EXE -- Maintain AD store, manage FSMO servers, clean
metadata, perform AD recovery tasks, delegate roles, and more.
NETDIAG.EXE -- Tests operation of IP, DNS, Trusts, Kerberos, etc.
NTDSUTIL.EXE -- Maintain AD store, manage FSMO servers, clean
metadata, perform AD recovery tasks, and more.
REPADMIN.EXE -- Monitor and manage replication links and the KCC.
This is something like a command-line version of REPLMON.EXE.
S A N S Institute
igration Tools:
ADPREP.EXE -- This tool must be run on the Schema FSMO master
(/forestprep) and all Infrastructure FSMO masters (/domainprep) in all domains
prior to upgrading AD. The tool is found in the \sources\adprep folder of the
Windows Server installation DVD.
Active Directory Migration Tool (ADMT) -- The ADMT is the primary tool for
migrating your current Windows domain(s) to a more recent version. This is also
the best tool for consolidating multiple domains into one. Make sure to use the
latest version, it is updated periodically.
CLONEPRINCIPAL Scripts -- These VBScript scripts use COM+ components to

create mirror user, group and computer accounts in another domain (in another
forest) which possess the same SIDs as the originals; this is useful for creating a
parallel forest while preserving the original upgraded forest as fall-back position;
the scripts and DLLs include Clonepr.dl1, Clone-gg.vbs, Clone-ggu.vbs, Clone-
lg.vbs, Clone-pr.vbs, Sidhist.vbs, ADsSecurity.dl1 and ADsError.dl1.
A popular website for Windows tools is http://www.joeware.net/freetools/, including a

collection of free tools for Active Directory. The tools are regularly updated and the
documentation is nice. These tools can be run from within either CMD.EXE or
Powershell. Some of the more interesting tools include:
ADFIND.EXE -- Better than Microsoff’s own DSGET or DSQUERY, it’s a

flexible search tool that can also show deleted items and server-side query
performance statistics. Very nice for automating security audits.
ADMOD.EXE -- Better than Microsoft’s own DSMOD or DSRM, a tool to

modi@, create, delete or undelete objects in AD.
ATSN.EXE -- Matches IP addresses to their AD sites, or lack thereof.
0LDCMP.EXE -- A safe way to list or delete old computer or user accounts.
SECDATA.EXE -- Dump the important properties of user and computer objects

to a properly-formatted CSV file which can be easily parsed or imported to Excel.
UNLOCK.EXE -- Flexible way of displaying or unlocking locked accounts.
ST
It’s been acquired by Microsoft now, but one of the many mind-bogglingly cool tools
from Sysintemals is the free ADRESTORE.EXE utility for restoring deleted AD objects
in Windows Server 2003 and later. Microsoft even has a KB article on how to use it:
SANS Institute
KB84000 1. For the time being at least, you can still get the Sysinternals tools from
http://www.microsoft.com/sysinternals/.
Active Directory can be managed entirely through scripts. The scripts can be written in
VBScript, PowerShell, JScript, Ped, or any other language, as long as the script can use
the ADSI interface.
The Active Directory Services Interface (ADSI) exposes an easy-to-use interface for
scripting the management of AD. Despite its name, ADSI is a generic interface for any
vendor's directory services, Microsoft's or otherwise. For example, the following
directories can all be accessed via ADSI:
Windows Active Directory
Microsoft Exchange Server
NetWare 3.x, 4.x and 5.x (bindery or NDS)
Netscape Commerce Server
IBM Lotus Notes
Any LDAP-compatible directory.
PowerShell also provides access to the System.DirectoryServicesclasses in the .NET

Framework for managing Active Directory. There are also free AD cmdlets from third-
party companies, such as Quest Software, which make the use of these classes easier.
PowerShell is available in Windows Server 2008 and later by default, but it can be
installed on Windows XP/2003/Vista too (www.microsoft.com/powershell/).
ie
Robbie Allen has written some of the best books on Active Directory out there, such as
the Active Directory Cookbook (O'Reilly), and you can get a ton of great information,
links and VBScriptPerl scripts from his website: http://www.rallenhome.com
S ?
The main protocol used to query and edit AD is the Lightweight Directory Access
Protocol (see RFC 225 1 and KB22 1606 for more information about LDAP). LDAP is an
industry-standard protocol for accessing many types of directory databases besides AD.
LDAP is built into Internet Explorer, My Network Places "Entire Directory", AD
management snap-ins, etc. Microsoft also has a generic LDAP client named LDP.EXE.
LDAP servers listen on ports TCP 389 and 636 by default. The Global Catalog service
listening on ports TCP 3268 and 3269 is actually an LDAP server. LDAP over SSL on
TCP ports 636 and 3269 requires the installation of a digital certificate on the domain
controller (KB247078).
iC
Windows Server 2003 and later signs and encrypts its LDAP management traffic by
default. And virtually all the AD administration tools that come with Windows 2003 and
SANS Institute
later will use secure LDAP when connecting to other domain controllers, even if those
controllers are running Windows 2000. However, for Windows 2000 domain controllers
to support secure LDAP they must have Service Pack 3 or later installed (KB325465).
The administration tools from the Windows Server 2003 or later CD/DVD (installed with
ADMINPAK.MS1 or the Remote Server Administration Tools (RSAT)) should be
installed on any machine from which you plan to manage Active Directory. This will
significantly increase the integrity and privacy of your administration work.
There are new ports to definitely block at the perimeter firewall, including LDAP
Port Number Protocol Description

3268 TCP Global Catalog with LDAP
3269 TCP Global Catalog with LDAP and SSL encryption
544 TCP Kerberos KSHELL
464 TCP and UDP Kerberos Passwords
88 TCP and UDP Kerberos Secure Authentication
636 TCP LDAP SSL
389 TCP and UDP Lightweight Directory Access Protocol (LDAP)
137 UDP NetBIOS query requests
138 UDP NetBIOS query responses
139 TCP NetBIOS Session (for SMB or CIFS)
135 TCP RPC mapper
445 TCP SMB without NetBIOS (CIFS)
3389 TCP Terminal Server
42 TCP WINS replication
SANS Institute
- UPS & Dual Power Supplies

- KVMover IP - RAID5 for AD database
- R AlD l for transaction logs
- R AlD l forOS
- Lots of ECC RAM & L2 Cache
- Two DCs and GCs per site (ideally)
- Alternate WAN replication paths
- Do sites, subnets and DNS right!
- Large deletable file in each volume ducate other IT staff and

- Scheduled monitoring script managers about multi-master
- Fixed paging files (>IGB) rep1ication dangers.
Physical security for domain controllers (DCs) is especially important because AD uses
multi-master replication. This means that modification of the AD database on one DC
will be spread to all other DCs in the domain. The least protected DC becomes the weak
link in the chain.
For example, an attacker with physical access to a DC could modi@ system executables
to implement a "SID spoofing" attack which could be used to elevate his or her privileges
to a Domain Admin or Enterprise Admin (KB289246, KB3 11401). Or such an attacker
could modify a random DC to accept changes to the Schema even though it is not the
Schema FSMO master (discussed later). These are real documented threats, not
theoretical possibilities.
Though it should be obvious to network administrators who manage security, the

following physical security and fault tolerance measures should always be implemented:
Domain controllers (DCs) should be kept in locked, access-controlled rooms.

Preferably the rooms should be in locations where entry/exit is likely to be
witnessed by others. Beware of crawlspaces above the ceiling tiles or below the
floor panels.
Very few network administrators will actually require physical access to DC

hardware, so do not allow more than the minimum necessary personnel to have
SANS Institute
direct access to the server room with the DCs, their backup devices, or their
backup media. And note that minimum personnel does not include the janitors!
Ideally, the lock to the server room should either require a pass-number or a
magnetic ID card for entry. Each administrator should have a unique pass-
number or ID card, and the lock should log who enters when. If the lock is a
deadbolt which requires a key, then endeavor to obtain a type of lock whose keys
cannot be easily copied and keep a strict inventory of keys.
Consider installing electronic surveillance equipment to monitor the server room.

A wireless hidden camera and time-elapsed (10-hour) VCR that only records
when there is motion detected can be purchased for less than $800 (e.g.,
www.pimall.com). Since no one typically enters the room, the VHS tape might
last for months, and, because it's wireless, the VCR can be conveniently located.
Prefer granting access to a DC through Terminal Services rather than through

direct physical access. Also, consider having all admins RDP into a single secure
Terminal Server and do all their AD administration work from there instead of
from their own desktops; the TS server should be physically secure, regularly
patched and virus-scanned, and disallowed all Internet access, which should help
to prevent accidental corruption from a compromised administrator's laptop or
desktop computer.
Control access to the keyboard, monitor and mouse. One option is to place
servers in one room and the keyboard, monitor and mouse in another. The cables
will extend through a hole in the wall. If there are multiple servers, then purchase
a peripherals switch so that multiple servers can share a single keyboard, monitor
and mouse.
Computer cases should be elevated off the floor and covered from above to
protect against standing water and the sprinkler system. This is conveniently
done by placing computers inside locked cabinets which have caster wheels and a
solid cover on the top.
Prevent undesired reboots into other operating systems, e.g., from a floppy disk.
Physically control access to the floppy drive, change the BIOS boot order, or don't
have a floppy drive permanently attached. A locked chassis cabinet with "server
blades" and external RAID solves many problems in one efficient package.
Install self-updating virus scanners on all domain controllers to prevent the spread
of malware through the automatic FRS replication of the SYSVOL share
(Ks822 158).
I
Using the NTDSUTIL.EXE tool, set a long passphrase for the local administrator
account on domain controllers before that account is needed to restore Active
Directory in a crisis (KB223301). Physically secure copies of that passphrase.
SANS Institute
Create one or more large files in each volume (at least 1GB on each) that can be
deleted in an emergency to free up hard drive space as needed. Schedule a script
to run every 15 minutes to monitor free drive space, to delete the emergency
file(s) as needed, and, most importantly, to alert administrators to the situation.
You can create a big empty 1GB file, for example, but running this command:
"fsutilxxe file createnew c:\ReserveFile.txt 1000000000".
Backup devices should be kept in locked, access-controlled rooms, and backup

media should be kept in locked cabinets.
There should be a strict accounting of backup media: these tape cartridges, CD-
ROMs, DVDs and removable hard drives should be numbered, dated, and
accounted for at all times.
Provide for off-site storage of duplicate copies of the backup media, and regularly
rotate updated versions there. You must be able to trust the off-site facility to
securely handle your data. Consider encrypting the media and/or storing them in
lockboxes before delivery to the remote site.
Have at least two DCs per site, if this is economically feasible, and make them
both Global Catalog servers.
At a minimum, the AD database and transaction log files should be on two

separate hard drives of the DC. But, really, the DC's operating system should
have its own mirrored set of drives; the transaction logs their own mirrored set;
and a 4-disk RAID-5 array for the AD and SYSVOL databases. Hard drives are
cheap these days! A DC with this setup, plus 1 GB of RAM and dual-Xeon 1GHz
CPUs, could handle ten thousand users logging on in the morning over a 10-
minute period at 50% CPU load. 80% of the access to AD is read access, so AD
really benefits from RAID-5 storage, and adding more CPUs increases
performance more than adding RAM beyond 1 GB.
All DCs should be attached to Uninterruptible Power Supplies (UPSs). Don't

forget that routers, switches and WAN equipment run on electricity too.
Educate IT staff and management about the devastating harm that an attacker
could wreak to the entire forest with physical access to only a single DC. If they
do not understand the nature of multi-master replication, the role of the Schema,
the power of the Domain Admins and Enterprise Admins groups, etc., then they
will unlikely take the need for physical security seriously. This will lead to lax
policies, lack of discipline in policy enforcement, and lack of funding from
management (and that's when a hacking bootdisk image will be posted to the
Internet with instructions that read: "Insert CD into drive on domain controller,
press reset, run away").
SANS Institute
- Master keys.
- LSA Secrets.
- Password.
The SYSKEY.EXE tool first became famous with Windows NT 4.0 Service Pack 3 as a
utility to encrypt password hashes in the SAM database to defend against LOphtCrack.
SYSKEY encryption is enabled by default in Windows 2000 and later, and cannot be
(safely) disabled. There are options to configure, however, which can enhance security.
SYSKEY.EXE creates a 128-bit RC4 key called the "System Key". The System Key is
used to protect much more than just password hashes. The System Key encrypts the
following data:
Protection keys for users' passwords in AD or the local SAM database.
Users' "Master Keys" that are used to protect private keys for digital certificates.
Protection keys for the "LSA Secrets" in the registry, such as service account
passwords and the computer's own Master Key.
The protection key for the local administrator account password that is used when
booting into Safe Mode.
Note: The System Key does not encrypt the entire AD database, only the data
specified above. It also does not encrypt anything in the SYSVOL or any critical
operating system executable files. Any cleartext data can be modified by attackers
with physical access to DCs. i
i
System Key encryption counters the threat of adversaries who have stolen copies of the
Active Directory or local SAM accounts databases. This might be the theft of the entire
SANS Institute
computer, just its hard drives, or, more likely, backup media such as tape cartridges.
System Key encryption also helps to defend machines when they are booted into other
operating systems --such as booting to Linux from a floppy disk-- that circumvent NTFS
permissions and which provide direct sector-level access to the hard drives.
? ?
SYSKEY.EXE can be executed from the Run line at any time to reconfigure how the
System Key is created and stored. There are three options, but disabling the System Key
is not one of them:
The System Key can be stored locally with, as the Resource Kit says, a "complex
obscuring function" in the registry of the computer. Nonetheless, hackers have of
course found it anyway. This option is the default.
The System Key can be derived from a password a user must enter during boot
up. The password can be up to 128 characters long, and is hashed with MD5 to
create the 128-bit System Key. The password is not stored on the machine. If the
password is not entered, the computer simply sits forever in a half-booted state.
The System Key can also be derived randomly and stored on a floppy disk. The
computer will prompt for the floppy disk if it is not already in the drive. Without
the correct floppy the computer will hang forever in a half-booted state. Copies
of the floppy can be made for safe-keeping.
To examine or change your current System Key configuration, run SYSKEY.EXE from
the Run line.
Notice that the option to disable is grayed out. Click the Update button.
SANS Institute
22 Active Directory i3 DNS
Keep in mind that each Windows computer can have its own separate SYSKEY.EXE
configuration. This includes desktop and laptop machines. Domain controllers do not
replicate System Keys, and each can be configured differently with different System Key
options.
The good thing about the store-locally option is that machines can reboot totally
unattended. Power spikes, brown outs, reboots after automated software installations,
etc., they don't require administrators to run from machine to machine typing in
passwords or inserting floppy disks. You also don't need to keep track of which
password or floppy goes with which version of the backup on which machine.
The very bad thing about the store-locally option is that there are tools which can extract
it from the SYSTEM registry file if that file is stolen! (For example, the Cain tool from
www.oxid.it, which also performs password hash cracking, can extract the local System
Key). You can keep this default setting in low-security environments, but strongly
consider changing it in medium- to high-security environments. And, in all
environments, physically secure the machines and keep a strict inventory of their backup
media.
The passphrase option is the most secure, but also the most burdensome. If the
passphrase is lost or maliciously changed, there is no recovery except to restore the
SANS Institute
"System State" to a time when the password was known or when no passphrase was set.
("System State" is an option in the Windows Backup program.) Also, every time the
computer reboots, a human being must manually enter the passphrase (it cannot be
scripted or automated). In high-security environments, this behavior might be acceptable
or specifically desired, but most IT staff will quickly find it a horrendous annoyance.
You might also invest in a KVM-over-IP product that allow remote access to the
keyboard, video and mouse through an IP network.
Tip: The BIOS password on a laptop is usually trivial to circumvent. The

System Key password, on the other hand, cannot be circumvented, and, when
combined with the correct use of EFS file encryption, can secure a laptop's data
even against sophisticated and well-funded adversaries.
The floppy disk method moves the System Key off the hard drive (and off tape backups)
and backup copies of the floppy disk can be made. If a floppy disk is stolen, this does not
in itself compromise the system: an adversary must also have a copy of the AD/SAM
database and must still crack the password hashes found there. If a floppy disk is
compromised, change the SYSKEY.EXE option to "Password Startup", reboot, then
change the option back to "Store Startup Key on Floppy Disk", and a new System Key
will be generated. Then have users change their passwords immediately. Keep a few of
your old floppy disks in case you need to restore from older tapes, and keep multiple
copies of the floppy disks in secure off-site locations.
Not all domain controllers are subject to the same threats. If the DCs at corporate
headquarters are physically secured and the backup media strictly managed, then it is
acceptable to keep the default store-locally option. At a remote site, perhaps collocated
on another network, you might insist that the password option be used. For the rest, the
floppy disk method might be best. And you can always change your mind at any time.
And note that it's possible that the system key may be written to the crashdump file after
a BSOD, so, if you're that paranoid, consider turning off full crashdump files in the
System applet in Control Panel.
Administrators, and others with the SeDebugPrivilege user right, can use Cain to extract
usernames and password hashes cached and decrypted in RAM (www.oxid.it). These
can be loaded into Cain or other tools to find the weak passwords. Other tools can turn
off System Key protection, but this usually comes at the expense of losing all the hashes
that are already there.
Very importantly, don't forget that adversaries who have stolen your SAM and SYSTEM
files for your registry will be able to defeat System Key protection of passwords ifyou
have set the "Store Startup Key Locally" option with SYSKEY.EXE. They can also
defeat the protection if they've stolen the System Key floppy disk or know the startup
password of course.
SANS Institute
- Transparent to the user.
Domain controllers running on Windows Server 2008 and later can use BitLocker to
encrypt the drive volume(s) which contain the operating system and Active Directory
database. When used with a Trusted Platform Module (TPM) chip, BitLocker also
provides boot-up integrity protection to help defend against malware infections.
BitLocker requires at least two drive volumes: a 1.5GB or larger boot-up volume (usually
assigned letter I'D:") and one or more volumes for the operating system and other data
(usually assigned letter "C:"). The boot-up volume cannot be encrypted, all other
volumes can.
BitLocker is not available on Windows Server 2008 or later by default, but you can add it
as one of the features in Server Manager or by executing "servermanagercmd.exe -install
bitlocker" at the command line. Don't worry, this doesn't encrypt your drive, it just
makes BitLocker available for use.
The two main benefits of BitLocker Drive Encryption are:
Verification of the integrity of boot-up files and other start-up data structures to
help prevent rootkits and other malware from secretly taking control of the
computer, and,
SANS Institute
Sector-level encryption of entire hard drive volumes, including the paging and
hibernation files on those volumes, to prevent exposure of confidential data on
stolen or lost hard drives.
BitLocker can optionally make use of a Trusted Platform Module (TPM) chip in the
mainboard of the computer, but a TPM chip is not absolutely required. For the sake of
data recovery in an emergency, backup keys can be exported to external media or, when
the computer is a domain member, even uploaded to Active Directory automatically.
After the computer has booted and the user has logged on, BitLocker is 100% transparent
to the user. It imposes about a 5% overhead on the performance of the system.
A Trusted Platform Module (TPM) is a chip built into the motherboard of a computer
which can perform on-board random number generation, encryption, hashing, and other
cryptographic operations. The TPM is also a secure storage location for keys, passwords,
hashes and other secret data.
The following summarizes the various ways BitLocker can be implemented. The options
are arranged from most secure (top) to least secure (bottom):
+ + oken. User must enter a 4- to 20-digit PIN and insert a

USB token containing a key during boot-up, but the token does not need to be left
connected to the computer after boot-up. Boot-up integrity is checked. TPM
required. Emergency recovery required if the USB token is lost.
oken. User must insert a USB token containing a key during boot-
up, but it does not need to be left connected to the computer after boot-up. No
PIN required. Boot-up integrity is checked. TPM required. Emergency recovery
required if the USB token is lost.
. User must enter a 4- to 20-digit PIN during the text-mode phase of

boot-up. No USB token required. Boot-up integrity is checked. TPM required.
Emergency recovery required if the PIN is forgotten.
nly. No user interaction required. No USB token or PIN necessary.

BitLocker is 100% transparent in this case, hence, is the most convenient option,
even if it is not the most secure. Boot-up integrity is checked. TPM required.
). User must insert a USB token containing a key

during boot-up, but it does not need to be left connected to the computer after
boot-up. No TPM chip or special BIOS required. No PIN can be used. Boot-up
integrity is not checked, hence, no rootkit or spyware protection! This is the only
no-TPM option for BitLocker, hence, the default for all legacy computers.
ee
BitLocker is discussed in detail in a different day of this week-long course. It is covered
in SEC505.3 "Windows PKI, EFS and BitLocker".
SANS Institute
- Server 2008 or later. - Pre-created RODCs.

Full or Server Core. - DSMGMT.EXE
- Forest level: 2003 +
- adprep.exe hodcprep
- PDC Emulator must - If compromised, delete
be 2008 or later. RODC account!
- Modify schema.
checkbox!
A read-only domain controller (RODC) is exactly what it sounds like, but it requires .
Windows Server 2008 or later, either full or Server Core. No changes made to the AD
database of a RODC, whether on-line or off-line, will be replicated back to any other
domain controllers. Additionally, no changes made to the SYSVOL share will be
replicated to any other controller. In a sense, this is the reintroduction of the old Backup
Domain Controller (BDC) concept from the Windows NT 4.0 days of the prior century.
RODC controllers are intended for locations where the physical security of the controller
cannot be assured, such as remote branch offices or even main offices where physical
access to controllers just can't be realistically restricted. RODC controllers will likely
have TPM chips in their motherboards and use BitLocker too.
When a RODC receives a read request, such as for logon authentication, the request is
satisfied locally, but an LDAP write request, such as for a phone number change, will
have to be referred to a standard writable controller instead, perhaps across a slow WAN
link. Similarly, if the DNS service is installed on a RODC, queries are supported, but not
dynamic updates. If a RODC DNS server receives an update request, the request is
referred to another DNS server, then the RODC requests a DNS synchronization update
from that other DNS server for just the new records since the last update. RODC DNS
servers also do not register name server (NS) records in DNS for any locally-hosted
zones, hence, they don't advertise themselves as being authoritative for those zones.
SANS Institute
Active Directon, & DNS 27
A local RODC will allow faster logons at a branch office site because users will not be
forced to go across a slow WAN link to find a domain controller; but you only get this
performance boost if the RODC has been configured to cache the credentials of the users
at the site. This is not enabled by default, but is easy to configure. RODCs will keep a
log of which credentials are cached so that, if the RODC is compromised, just those users
can be forced to change their passphrases immediately.
The schema determines which attributes are replicated to RODCs. By default everything
is replicated to RODCs with the exception of password hashes. You can edit the schema
to fine-tune which attributes are not replicated to RODCs.
The RODC must be able to replicate with at least one regular (non-RODC) in the same
domain as the RODC itself (you cannot have a domain in the forest whose only
controllers are RODCs) and that writable controller must be running Windows Server
2008 or later. There are other prerequisites and issues to consider too:
Forest functionality level must be Server 2003 or better, wh

controllers must be running at least Windows Server 2003 to
You must run "adprep.exe /rodcprep" as an Enterprise Adm

on the Schema Master controller before attempting to install a RODC (get this
tool from the Server 2008 or later installation DVD). This command will update
permissions on DNS replication partitions for the sake of RODC DNS servers.
This command requires network connectivity to the Infrastructure Master in each
domain or it will fail otherwise. If all domain controllers were installed with
Windows Server 2008 or later to begin with, this step isn't necessary.
For every domain that will contain a RODC, the PDC Emulator operations master
in that domain must be running Windows Server 2008 or later. This is required to
keep the clocks on the RODCs in sync. (There are W32TM.EXE tricks that can
be performed instead, but it's better to upgrade the old DCs.)
Though not a requirement, it is highly recommended that you review and perhaps
hand edit the DNS SRV records for the sites containing RODCs after deployment
to ensure that clients at those sites will use their local RODCs as intended.
Windows Server 2003 domain controllers don't recognize RODCs when
considering SRV records for sites.
Though not a requirement, it is highly recommended that you edit the following
certificate template permissions if you have an enterprise certification authority:
1) on the "Domain Controller" certificate template, add the Enroll permission for
the "Enterprise Read-only Domain Controllers" group, and 2) on the "Domain
Controller Authentication" and "Directory E-Mail Replication" certificate
templates, add Enroll and Autoenroll permissions for the "Enterprise Read-only
SANS Institute
Domain Controllersttgroup, and allow Read permission for the "Authenticated

Users" group. RODCs otherwise won't get their required digital certificates.
Some directory-integrated applications can fail when using RODCs (especially code
using ADSI's DsGetDcName function with the DS WRITABLE REQUIRED flag set),
so you should test RODCs with such applications a test site before deployment (see
KB92977 1, KB929770 and KB929768 for a fuller discussion).
Note that you can have a mixture of Windows Server 2003 and RODC controllers in a
domain, but, again, the domain must be at functionality level Server 2003 or better and
the PDC Emulator in that domain must be Windows Server 2008 or later too.
ODC Installation
In the lab you will need to install two VMs if you want to experiment with a RODC.
You'll see the DCPROMO.EXE option for a read-only domain controller grayed out
when you run it on the first controller in a domain or forest.
You can install a RODC on a full or Server Core installation. On a full installation of
Windows Server, just run DCPROMO.EXE as you would normally when becoming a
domain controller (after installing the AD role in Server Manager). During the
DCPROMO installation process you'll be presented with a screen that has a checkbox to
install a RODC. On Server Core, you'll need to edit and use an appropriate XML
unattend file and pass it into DCPROMO.EXE as an argument (search Google with
"site:microsoft.com Steps For Deploying An RODC" to get more information).
You can delegate the power to install the RODC to someone at the remote site who is not
a Domain Admin. To do this, you pre-create the RODC's computer account in AD with a
special wizard and specify which user or group can join the RODC to the domain.
SANS Institute
To pre-create a computer account for a RODC and grant a non-administrative user the
rights to install that RODC, open the Active Directory Users and Computers snap-in on a
Windows Server 2008 or later writable domain controller > right-click the Domain
Controllers OU > select "Pre-Create Read-only Domain Controller Account" > answer the
questions of the wizard (click the help links as necessary).
3 6iJ rorp.sans.org
El 2 Euilbn
At the remote site, the trusted user will install Windows Server 2008 or later on a new
system, give it the same name as the pre-created RODC account, and then run
"dcpromo.exe /useexistingaccount:attach",which will join the computer to the domain
(so don't manually join it beforehand) and install AD. The user will need to know the
credentials for the global AD account who was entrusted to install the RODC.
If you wish to use the install-fiom-media feature, you no longer use NTBACKUP.EXE to
make a copy of the AD database; instead, a Domain Adrnin will run NTDSUTIL.EXE to
invoke its "IFM" subcommand on a writable domain controller to create the media from
which the RODC controller will later be installed. This tape, USB drive or DVD can
then be shipped to the remote site to help speed the installation process of the domain
controller, read-only or not (see http://go.microsoft.com/fwlink/?LinkId=86716).
io
Any global user can be granted administrative privileges over a RODC, but this will not
give them any additional power over the domain or over other domain controllers. When
delegating authority to a user at a branch office this way, the user can log on to an RODC
to perform maintenance work such as installing a new device driver or rebooting the
system. However, don't put that user into the local Administrators group! This
delegation of authority is done differently.
To list the available delegation of authority roles, not groups:
SANS Institute
In an elevated command shell, run "DSMGMT.EXE".

Run "local roles".
Run "list roles".
To list who currently has the Administrators role (empty by default):
In an elevated command shell, run "DSMGMT.EXE".

Run "local roles".
Run ''show role administrators".
Note that the above command does not show the current membership of the local
Administrators group! This is a different delegation of authority feature.
To add a user to the local Administrators role on the RODC:
In an elevated command shell, run "DSMGMT.EXE" .

Run "local roles".
Run "add domain\username administrators".
Since this command doesn't change any group memberships, what is it doing? The
command appends the user's SID number to a REG MULTI SZ value in the registry
named "544" located under HKLM\SYSTEM\Curr&Contro?Set\Control\Lsa\roDcRoles.
544 is the well-known RID number of the built-in Administrators group, but this doesn't
actually add the user to that group.
lica olicy
By default, no passwords for user or computer accounts are cached locally on a RODC,
but such caching can be selectively enabled for particular accounts or groups. As a
security precaution, only allow replication of passwords to a RODC for the users and
computers at that RODC's site, and never allow replication of password hashes for users
in powerful groups like Domain Admins or Enterprise Admins.
Two groups exist specifically for enforcing RODC password replication policy, but you
are not limited to the use of these groups:
Allowed RODC Password Replication Group
Denied RODC Password Replication Group
These groups only have their indicated effect, though, because of the permissions
assigned to them in the properties of the various RODC computer accounts. Each RODC
can have a different password replication policy; you don't have to have a single policy
for all RODCs everywhere. Change the replication policy on a RODC by going to its
properties and selecting the Password Replication Policy tab.
To change the password replication policy on a RODC, right-click the RODC computer
account in the Domain Controllers OU > Properties > Password Replication Policy tab.
SANS Institute
Add or remove users, computers and groups as you wish, you're not limited to the built-in
RODC-related groups.
If you wish to see who has authenticated through a RODC to the domain, click the
Advanced button on the Password Replication Policy tab of the RODC computer. You
can also prefill the RODC's password cache here for users or computers that have not yet
authenticated but soon will. If you wish to prefill a RODC's password cache from the
command line, see "repadmin.exe /rodcpwdrepl /?".
e ise
When the RODC controller is eventually compromised, delete its computer account from
AD. This will show the following dialog box.
-
SANS Institute
Use this dialog box to 1) save a list of all user and computer accounts that had cached
credentials on the RODC to a CSV text file and 2) assign a different random password to
all such users. You can also reset all cached computer account credentials, but this will
require rejoining each machine back to the domain; this may be required in a high
security environment, but could be an administrative nightmare in itself.
ere e Se
Password hashes are not replicated to RODCs by default. If there are any other attributes
that you'd also rather not replicate to RODCs, then those attribute definitions in the
schema can be modified to mark them as "RODC Filtered", i.e., as not being in the set of
attributes replicated to RODCs. Microsoft calls this collection of so-marked attributes
the "RODC Filtered Attribute Set" (if you want to Google it).
However, only if the forest functionality level is at Server 2008 or better (not 2003) will
these RODC replication restrictions in the schema be enforced on all domain controllers,
since, at that forest functionality level, every controller in every domain will be running
Windows Server 2008 or later. If a compromised RODC controller is modified to request
replication from a pre-2008 controller, such as Windows Server 2003, that older
controller won't know anything about RODC attribute set filtering and may just cough up
the restricted attributes. Hence, if you must have this RODC filtering feature, you must
ensure that all controllers are running Windows Server 2008 or later and that the forest
functionality level is at Server 2008 or better too. I
To prevent an attribute in the schema from replicating to RODC controllers, right-click the
ADS1 Edit snap-in > Connect To > select "Schema" from the list of well-known naming
contexts in the middle of the dialog box > OK > expand the list of schema objects and
double-click the desired attribute (e.g., CN=Phone-Pager-Primary)> on the Attribute
SANS Institute
Editor tab, scroll down and double-click the "searchFlags" property > note the decimal
number already in that property > add 640 (decimal) to the decimal number already in the
property > OK > OK. Note that the property is now labeled "CONFIDENTIAL I
RODC-FILTERED" after the change.
Any schema attribute whose searchFlags property has its 7thand 10thbits set to one will
no longer be replicated to RODC controllers. This is accomplished by OR-ing that
bitmask with 0x80 and 0x200, or, because the ADS1 Editor shows this property as a
decimal, by adding 640 (0x80 = 128 and 0x200 = 512) to that decimal.
SANS Institute
- For both AD and the SYSVOL share.

- No authoritative restore for the Schema!
You have to assume that eventually your domain controllers will become compromised
by hackers, malicious insiders, viruses, wom s or terrorists -- not to mention good old
fashioned fires, floods, tornados, bad hardware, and Microsoft programming bugs.
"The single most important thing any company or individual can do

to improve security is have a good backup strategy."
--Bruce Schneier, 15.July.08 Crypto-Gram Newsletter
Backups are needed not only for disaster recovery, but also to gather forensics data for
incident response, to have legal evidence in case you plan to prosecute someone in court,
and to maintain "baselines" against which periodic audit comparisons can be made.
Again, much more than just account and password information is stored in AD, so the
loss of Active Directory would mean Game Over.
ecommende
This manual cannot cover all the issues involved in doing AD backups and restores. But
be aware that there are complexities which can severely burn you if you're not aware of
them. These complexities mainly come from the fact that AD is a multi-master replicated
transactional database.
The following is a reading list to get you on top of the issues; search Microsoft's website
or the Resource Kit for the title of the article to find its current location:
TechNet: "Active Directory Disaster Recovery"
SANS Institute
Article: Step-by-step Guide for Using the Active Directory Database Mounting
'I
Tool in Windows Server 2008" (NTDSUTIL.EXE and DSAMAIN.EXE)

Whitepaper: "Best Practices: Active Directory Forest Recovery"
Resource Kit: "Active Directory Backup and Restore"
Resource Kit: "AD Diagnostics, Troubleshooting, and Recovery"
Whitepaper: "Active Directory Branch Office Planning Guide" (Chap. 10)
KB240363: ''HOWto Back Up and Restore the System State"
KB241594: "How to Perform an Authoritative Restore to a Domain Controller"
KB2 16243: "Authoritative Restore of AD and Impact on Trusts"
KB263532: "Disaster Recovery of AD on Dissimilar Hardware"
KB3 15136: "HOWTo Complete a Semantic Database Analysis for AD"
KB243267: "How To Automate NTDSUTIL.EXE Using a Script"
ase
In Windows Server 2008 and later, you can make a shadow copy of the Active Directory
database even while the controller is running. This can be performed with Windows
Backup, third-party backup tools that support volume shadow copies, or
NTDSUTIL.EXE. Run the following command in an elevated command prompt shell to
make a snapshot of the drive:
n t d s u r . i l . exe " a c t i v a t e i n s t a n c e n t d s " s n a p s h o t c r e a t e q u i E quilr.
The above command will show a GUID number curly braces for the snapshot. Next,
mount that snapshot on a folder with the GUID number shown:
The above command will show a folder path that was just created. It will be something
like "C:\$SNAP-20080312230 VOLUMEC$". Go ahead, browse to that folder now with
Windows Explorer. It's a snapshot of the entire drive, including the AD database!
Next, we want to make the snapshot AD database available through LDAP on a local
TCP port number, such as TCP/9999. In a new elevated command shell, run the
following command. The command wraps, and you'll have to enter your own path
information, the below is just an example:
d s a m a i n . e x e - d h p a t h C:\$SNAP-2 0 0 8 0 3 1 2 2 3 0 -V O L U M E C $ \ W i n d o w s \ N T D S \ n t d s . d i t
-1dapport 9999
You can now connect to TCP/9999 on localhost with LDP.EXE or some other LDAP tool
and browse the snapshot AD database! To stop sharing on that port, hit Ctrl-C.
To unmount the snapshot, run the following commands:
n t d s u t i l .c?:-:(? snapshot " 1 i s L m o u n t e d " quic quit

ntcisui-i I . e x e snapshot "urimount 2 " quit q u i t # O r w h a t e v e r r-he n u m b e r
is.
SANS Institute
By scheduling the various NTDSUTIL.EXE commands above, you could make a new
snapshot every night at 3AM for auditing and recovery purposes. For more information,
just search Microsoft's site for "dsamain.exe active directory".
in in Server 2
If you are running in Server 2008-R2 Forest Functionality Mode or higher, which
requires all domain controllers to be Server 2008-R2 or later too, then you can use
Powershell to enable a "Recycle Bin" feature for deleted AD objects. Enabling the
feature and actually recovering deleted objects is performed at the command line using
Powershell 2.0 or later.
Here are some of the issues that tend to be forgotten yet can prevent successful recovery:
By default, you cannot restore any portion of AD sixty days after the backup was
made. This is because the default lifetime for a "tombstone", i.e., a marker for a
deleted item, is sixty days. (In fact, if a server is off-line for more than 60 days,
that server should not be reattached to the network and should be reinstalled.)
Are you confident that you will not need to restore from sixty-day-old tapes? Are
all of your backups younger than sixty days?
When restoring AD on Windows Server 2000/2003, you must boot into a type of
Safe Mode called "Directory Services Restore Mode" with the password of a local
administrative account on the DC. Do you know what that password is? Do you
know about the utilities available for resetting that password while AD is
running? (KB223301) On Windows Server 2008 and later, AD is just a service
like any other service, hence, it can be stoppedhtarted separately without
rebooting the entire machine, and there is a new whole-drive backup program too.
When restoring data in AD which was previously deleted, you must perform an
"authoritative restore'' of that data. This means you mark that data as
authoritative with the NTDSUTIL.EXE tool after restoration but before bringing
the DC back on line. Without doing so, as soon as the previously-deleted objects
are restored, they will be deleted again by their tombstones. Do you know how to
do an authoritative restore with NTDSUTIL.EXE?
The SYSVOL share contains Group Policy data and other important objects. An
authoritative restore of the SYSVOL is a separate procedure from the restore of I
AD. Do you know how to do this? (Actually, it's pretty easy: restore the old
files to a temporary folder while in Directory Services Restore Mode, then
manually copy them into the SYSVOL after the DC has fully rebooted.)
During a nonauthoritative restore, the process of updating the restored DC's

database from other DCs (this is the "backfill" process) requires time and I
bandwidth. Using backfill on remote DCs with slow WAN links may take many
SANS Institute
hours and effectively prevent that link from being used for anything else. Do you
have at least two DCs per site?
The Schema cannot be authoritatively restored. (gulp)
To back up the "System State", which includes the AD database, the user must be
a member of either the Backup Operators or Administrators groups. However, to
restore the System State, the user must be a member of Administrators; being a
member of Backup Operators is insufficient. Do all of your remote sites have at
least one user who is an Administrator on their DCs? How long will it take to get
someone there?
The AD database must be restored to its original drive volume. Are all the drive
volumes on all the DCs documented somewhere? Also, you cannot restore the
AD database from one DC on another DC even if their drive volumes are
identical.
Computer account passwords, including the accounts used for trust links, are
changed automatically on a periodic basis. Microsoft's documentation is
contradictory for what this period is: some say 7 days but the prior password is
cached too (14 days total) and some say 30 days. Hence, authoritative restores of
this data fiom backups older than 30 days will cause problems for computers and
trust relationships, and perhaps 7- or 14-day old backups will too. Fortunately,
computer passwords and trusts can be reset without too much difficulty.. .ifyou
know that this is the problem and how to do it (right-click computer > Reset
Account).
If the FSMO RID Master's or Domain Naming Master's role is forcibly

transferred to another system with NTDSUTIL.EXE, the box which previously
held this role can never be brought back on-line again. You must reinstall the
operating system from scratch. The old PDC Emulator and Infrastructure Master
can be brought back on-line, however, even if their roles have been transferred in
their absence.
Make certain that you have applied Service Pack 2 or later on your Windows
2000 domain controllers and that you have made backups after the SP application.
There is a serious bug in Microsoft's AD backup API (fixed in SP2) that can leave
your DCs unbootable after restoring from a corrupted backup (KB295932).
Better yet, upgrade, Windows 2000 is getting pretty old.. .
SANS Institute
3% Active Directory & DNS
Every DC can receive changes to NTDS.DIT or the SYSVOL and these changes will be
replicated to the other DCs. Through the use of time-stamps, Update Sequence Numbers
(USNs), and server Globally Unique Identifiers (GUIDs), conflicts are resolved so that
later changes overwrite earlier ones, and only new information is replicated. This is
multi-master replication.
Importantly, replication occurs at the level of properties of objects, not entire objects.
This makes replication significantly more efficient, even over slow WAN links.
aming Contexts
There are three major partitions of the Active Directory database called "naming
contexts" and each is replicated separately:
Domain Naming Context(s)
Schema Naming Context
Configuration Naming Context
1) Schema Naming Context

The Schema defines the abstract structure or "blueprint" of AD. Schema information
is replicated to all DCs throughout the entire forest.
SANS institute
2) Configuration aming Context

The Configuration NC holds information about sites, subnets, replication transports,
trusts, and other services, such as Exchange 2000. Configuration information is
replicated to all DCs throughout the entire forest.
aming Context(s)
This is the information normally identified with Active Directory, such as domains,
OUs, users, computer accounts, groups, etc. The Domain NC is replicated to all other
DCs in the same domain, but only a portion of it is replicated through the Global
Catalog to other domains.
: There is a fourth container called "RootDSE" which is required for

Pv3 compatibility. It holds information about the LDAP server itself,
protocol versions supported, SASL methods, etc. (Kl3219005). It is not specific
to AD and is not, strictly speaking, a naming context because it is not replicated to
other DCs. Each DC has its own unique RootDSE container.
OW!
You can see and edit these three naming contexts by right-clicking on the "ADSI Edit"
tool and selecting "Connect To" > Naming Context pull-down menu > DesiredNC > OK.
Repeat this procedure until you've added all three NCs: Domain NC, Configuration
Container, and Schema. (ADSI Edit is a Supporf Tool from the Windows CD.)
r3 3 Domain I\iC [godzilla fossen net]
CN=\n/eilKnown Security Pi incipals
To experiment with the ADS1 Edit tool, you can manually add a user account to your
Domain NC without using "AD Users and Computers":
1) Open "ADSI Edit" > Domain NC > DC=domain > CN=Users.
2) Right-click on CN=Users and select New > Object > user > Next.
3) Enter "Sans57" for the Value of CN > Next. Enter "Sans57" for the Value of
sAMAccountName > Next. (The Schema determines that CN and
sAMAccountName are mandatory values of User class objects.)
SANS Institute
4) Click the “More Attributes“ button to see the optional values which the Schema
provides for User objects.
5) Pull down the ”Select A Property To View“ menu and select “pager“. Enter “867-
5309” in the Edit Attribute box > Set > OK > Finish.
Now open “AD Users and Computers” > domain > Users. Right-click Users > Refresh.
Notice the new Sans57 account. Go to the properties of Sans57 > Telephones tab, and
notice the pager number has been set.
By analogy, think of the NCs as tables in an Access database, or as separate spreadsheets

in an Excel workbook. A change to a “row” in the table or spreadsheet is like a change to
an object in a NC, and that change needs to be replicated to other DCs. How?
Sites and Subnets

AD replication is organized around sites. A “site” is a set of well-connected IP subnets
and the computers on them. “Well-connected” means there is, at the bare minimum,
128Kbps free bandwidth between any two computers out of a total available bandwidth
of 256Kbps. A site is typically an Ethernet or Token Ring LAN. A slow WAN or VPN
link would divide two separate sites. Sites are defined with the “Active Directory Sites
and Services” snap-in.
The concept of a “site” is a physical one, and should not be confused with the logical
constructs of the contents of AD such as domains, OUs, groups, etc. A site does not
contain a domain or vice versa. A site can have all, some or none of the DCs of a
domain, or a single site can have DCs from multiple domains, but this is talking about
physical hardware, not the contents of AD.
The name of the first site created in AD is “Default-First-Site-Name”. This can and
should be renamed to something more appropriate for one’s environment.
I
Tiee Favorites 1
USlvl”P Inter-Site T r a n s p o r t
R B Default-First-Site-Name
B c3 Servers
8 B GODZILLA
63
it] 0 Subnets
El @jA n o t h e r s i t e
Open the AD Sites and Services snap-in. Right-click the Sites container and select New
> Site. Enter “Site2” for the name, click DEFAULTSITELINK, and OK. Read the
SANS institute
message and click OK. Open Sites > Default-First-Site-Name > Servers. Right-click
your current server and select Move > Site2 and click OK. Open Sites > Site2 > Servers,
and right-click Servers and select New > Server. Enter "Server2" and OK.
Every site can be associated with one or more IP subnet(s) to identify the addresses in use
at the site. Subnets are created manually --or with a script-- and then assigned to a site.
This information is used to optimize various network functions so that clients and servers
in a site search for each other first instead of searching in other sites. For example, when
a client needs to find a DC, a Global Catalog DC, or a DFS share replica, the client can
query a DNS server for the IP addresses of such servers in its own site; this is possible
because site information is incorporated into the DNS server's zone data.
Try It
To create an IP subnet definition, open "AD Sites and Services" > right-click on Subnets
and select New > Subnet > enter the network ID and subnet mask > click the desired site
at the bottom to associate it with this subnet > OK.
All subnets in the organization's LAN should be defined in AD and associated with a site,
even if that site doesn't have a DC in it. If client's cannot find their site information in
DNS, it will be difficult to shape their network traffic. Also, DCs in adjoining sites with
low-cost connectors will add their SRV records to the DC-less site in DNS automatically,
or you can manage these external site SRV records manually if desired (see the "Active
Directory Branch Office Guide" whitepaper for a full discussion of the issues).
Replication within a site is automatic and automatically configured by a service called the
Knowledge Consistency Checker (KCC). By moving a DC to a different site you are
telling the KCC to create new RPC replication connections between itself and the other
DCs in the new site. If desired, you can manage these replication connections manually,
but this is not recommended and rarely necessary for intrasite replication (KB242780).
RPC replication channels are created such that there is no more than three "hops"
between any two DCs in a site. And because replication occurs every five minutes, there
should only be a 15-minute delay between the time a change is made on one DC and all
the other DCs in the site knowing about it, even if there were 50 other DCs in the site.
These replication connections (often called "connection objects") represent the actual
channels that do the work of replicating data. The different NCs are replicated
separately, but they all follow the replication end-points indicated by the connection
objects.
The KCC creates replication connections between DCs in different sites as well.
However, it does not do this automatically until you provide some extra information to it.
You provide this information in the form of "Inter-Site Transports", a.k.a., "site linlts".
Intersite links are not the actual replication connections themselves! Site links are user-
SANS institute
._
friendly abstractions. A site link bundles together the preferences of the administrator in
a form understandable by both the administrator and the KCC. The KCC, apprised of
your desires in the form of intersite link objects, proceeds to create connections in
accordance with your desires.
Each site will have one DC which is automatically nominated to use its KCC for creating
the intersite connection objects (typically, this is the oldest DC in the site). This domain
controller, whose KCC has taken on these extra duties, is grandiosely called the "Inter-
Site Topology Generator (ISTG) Role Owner". The ISTG box will pick one DC in the
local site, one DC in the remote site, and have them replicate with each other. This is
repeated for each NC in each domain for which the site has DCs. The local DC then
replicates all the changes it receives to the other local DCs, and vice versa. These
designated DCs are called "bridgehead servers" because they are the conduit between the
two sites. If one bridgehead DC goes down, the KCC will switch that role to another box
automatically.
Note: If you have less than 100 sites, then it is best to let the KCC manage both
intrasite and intersite connections. With more than 100 sites, however, the KCC
may become overwhelmed because it will attempt to compute the most efficient
spanning-tree topology possible using all the cost, schedule and transitive-link
information available to it. In this case, stop the KCC from managing intersite
connections and create the connection objects manually instead. KB245610
provides a script for making the Configuration NC change necessary to stop the
KCC on all sites this way. The "Active Directory Branch Office Guide"
whitepaper is more-or-less indispensable for understanding the issues involved.
Intersite links come in two flavors:

RPC Site Links (fast- and slow-link versions)
SMTP Site Links
Note: All the RPC links go in the Inter-Site Transport > IP container, but in the
properties of the connection objects themselves you can choose "IP" for slower links
and "RPC" for faster links. These settings adjust the timeouts and failure tolerances.
Intrasite connections always use the fast RPC transport. Be aware that if you do
manually change a connection object to use the "IP" transport, that connection object
falls out of the control of the KCC. You will have to manage it by hand for evermore.
If in doubt, just delete the modified connection object and the KCC will create a new L
one for you.
You will create these site links and assign them cost values, activation schedules,
replication intervals, and transitivity states. The KCC will use this information to
configure connection objects with these properties.
SANS Institute
Active Directon, & DNS 43
The SMTP site link uses the ITS SMTP Service for its delivery agent. Data to be
replicated are encrypted with an extended version of S/MIME, encrypted with the other
DC's computer certificate, and e-mailed to it.
However, SMTP transports can only be used when the two DCs are in two different
domains. The SMTP site link only replicates the Schema, the Configuration NC, and the
Global Catalog; it cannot be used to replicate the Domain NC or the SYSVOL. Hence, if
you only have a single domain, you cannot use the SMTP transport.
It !
To create an RPC intersite link, in the "AD Sites and Services" snap-in open the Sites
container > Intersite Transports > IP > right-click on IP > New Site Link > enter a
descriptive name for the link > add sites > OK.
Transport links have properties which control the replication schedule and cost of the
connections derived from them. The default cost is 100; the default interval, 180
minutes, i.e., replicate once every 3 hours; and the default activation schedule, 24 hours
per day, seven days a week. You can change these settings to suit your environment.
ote: SMTP transports ignore schedule settings.
Hence, multiple alternative replication paths can be configured between any two sites for
the sake of shaping traffic flows. The KCC will follow a spanning-tree algorithm to try
to work out the best overall topology, and, if a server or link goes down, the KCC will try
to work around it automatically. If you wish, it is possible to disable the KCC and create
the connection objects by hand, but this will likely be only when you have more than 100
sites.
The entire AD database is not replicated between domains. For the sake of efficiently
searching for objects across all domains, a subset of the AD database is replicated to
special DCs throughout the enterprise called Global Catalog (GC) servers.
The "global catalog" is not a separate database from AD. Rather, some AD data are
simply marked as being part of the catalog and some are not. All objects in AD are in the
GC, but not all properties of all objects are in the GC. The GC comprises roughly 55% of
the AD database.
There is not a "GC site link". Instead, GC replication rides piggyback on whatever RPC
and SMTP transports already exist.
You make a DC a Global Catalog server by going to the properties of a server's NTDS
Settings in the "AD Sites and Services" snap-in. You could make every DC a GC if you
wanted, and two per site is the recommended minimum if bandwidth considerations does
not preclude this.
SANS Institute
To mark a DC as a Global Catalog server, open AD Sites and Services > SiteName >
Servers > YourServerName > NTDS Settings > right-click NTDS Settings > Properties >
check the box labeled "Global Catalog" > OK.
Check the box

to make this
machine a GC
server.
The SYSVOL share is multi-master replicated by the File Replication Service (FRS)
automatically (IU3220140, IU3220938). This is the same service which replicates the
shares you create with the Distributed File System (DFS) snap-in. It uses the same type
of RPC connectors as for other AD data.
an licatio oI eran ce
When a new site is created, by default it will only have a single intersite link with one
other site. However, to make your replication topology more resistant to DoS attacks and
to improve fault tolerance generally, multiple redundant site links should be added
manually. Each site link will have a cost value associated with it. The KCC will build
replication pathways using the lowest cost links, but will fail over to the higher cost links
when necessary.
SANS Institute
- MPLS is encrypted.
- WAN router encryption.
- Good, but does not provide

complete end-to-end security.
- Assign a fixed TCP port.

- True end-to-end protection.
- Rarely used.
The details of how AD replication traffic is secured are undocumented. Very often,
domain controllers are scattered across multiple remote offices, sometimes in foreign
countries. It is important, then, to both integrity-check and encrypt all AD replication
traffic.
se es, C.
Leased lines, Multi-Protocol Layer Switching (MPLS) links, Asynchronous Transfer
Mode (ATM) links, Frame Relay links, and other such technologies do not provide
encryption by default. Just because your frames are not going over the Internet does not
make them private or secure, especially when the other end of the connection is in a
foreign country. MPLS in particular is often confused for being a VPN solution.
Despite the slow bandwidth, AD replication over a slow link can work well. Even over a
lowly 19.2 Kbps connection, an intersite RPC link can be stable and, for example, 1000
new user accounts could be replicated in 162 seconds. The main reason for the good
performance is that intersite replication data are typically compressed to about 12% of
their original size.
ote: Read the "AD Branch Office Planning Guide" whitepaper for tips on how
to manage large numbers of remote slow-link sites.
SANS Institute
Fortunately, data encryption for dial-up connections can be handled by the remote access
hardware. Microsoft's Routing and Remote Access Service (RRAS), for example, can be
configured for 128-bit RC4 encryption on the dial-up connection, a 127-character
password, callback or Caller ID security, and IP packet filtering to screen any errant
communications. RRAS can be installed on the DC itself, but it is far better for security
for it to be installed on another server on the DC's LAN either behind a firewall or with
firewall capabilities configured.
Note: RRAS security will be discussed during the "IPSec, RRAS and VPNs" day
of the seminar. Please refer to that manual for more information.
Site-to-Site S
It is possible to replicate DCs directly over the Internet with the RPC intersite link.
However, you must take care to strongly encrypt the data and to prevent unwanted direct
connections to the DCs themselves. Virtual Private Networking (VPN) fits the bill
nicely.
Establish a VPN tunnel between the remote networks and configure the routers to
forward their replication traffic through the tunnel. Importantly, the VPN is not being set
up directly between the two DCs. Instead, VPN routers within the LAN or DMZ, or from
the firewalls themselves, will maintain the tunnel to carry the DC's traffic. This
arrangement is compatible with private range addresses inside the LANs and prevents
direct connections to the DCs from the Internet. The firewall or VPN devices should also
filter the traffic to/from the DCs to help protect them.
Note: VPNs will be discussed during the "IPSec, RRAS and VPNs" day of the
seminar. Please refer to that manual for more information.
PSec For End

A site-to-site VPN protects replication and DCs from the hostile Internet, but it does not
secure the replicated data on all segments of the network, e.g., a VPN only encrypts data
going through the tunnel. Internet Protocol Security (IPSec), however, can provide end-
to-end encryption between DCs. With IPSec, replicated data never exists in unencrypted
packet form on any network, LAN or WAN.
For example, DCs can be configured to use IPSec 3DES encryption of packets whenever
they communicate with each other. IPSec will be used for DCs in the local site as well as
remote DCs on the other side of the VPN tunnel. Though not recommended, it is
possible for DCs to replicate directly with each other over the Internet using IPSec
instead of the router-to-router VPN, just make sure the two firewalls block all traffic to
the DCs except IPSec-encrypted traffic from just the IP address of the other DC.
Alternatively, just route the IPSec traffic through the VPN tunnel (which is probably
using IPSec itself too).
Note: IPSec will be discussed another day of the seminar. Please refer to the
I
IPSec manual for more information.
SANS Institute
ort
If using IPSec for all DC-to-DC traffic is too hard on their CPUs, install IPSec offload
network adapter cards and configure IPSec to only secure the replication traffic and
ignore everything else. Replication is conducted over RPC, hence, there is an initial
connection to the RPC Endpoint Mapper (RPCSS) on TCP port 135, then a switch over to
a high-numbered port for the bulk of the communications. This high port number is not
fixed by default, but it can be made static (Kl3224196). This is useful for IPSec, firewall
design and performance testing because filtering rules can be hard-coded for just that
port. Note that DCs use many other ports/protocols, but this is the (now fixed) channel
for AD contents (not including the SYSVOL).
Note: See KB 154596 and KB 179442 for more information about fixing other
RPC ports for IPSec and firewalling, e.g., the ports used for trust relationships.
To set the static port, create a REG DWORD value named "TCP/IP Port" (note the space
character) here: HKLM\SYSTEM\CurrentControlSet\Se~ices\NTDS\Parameters\.Edit
the value with REGEDIT.EXE, switch to decimal editing, and enter the port number.
More conveniently, use Group Policy to push out a script or custom ADM template
which sets this value.
Static eplication Service (

A different registry value is used to fix the RPC port used for replicating the SYSVOL
and FRS traffic in general (KB319553). However, the data in the SYSVOL is usually not
as sensitive as the AD data proper. Also, note that the following registry value will fix
the port for all FRS-replicated files, such as DFS files, and if you're going to use IPSec,
IPSec will be used for all of this traffic. In this case, make sure that all other machines to
which you are FRS replicating files support IPSec as well.
To set the static port, create a REG DWORD value named "RPC TCP/IP Port
Assignment" here: HKLM\SY ST~M\CurrentControlSet\Services\NTFRS\Parameters\.
Edit the value with REGEDIT.EXE, switch to decimal editing, and enter the port number.
More conveniently, use Group Policy to push out a script or custom ADM template
which sets this value.
Data replicated via SMTP is encrypted using a version of S/MIME with the digital
certificate of the target DC. Unfortunately, SMTP can only replicate between domains,
so two DCs in the same domain cannot use it. However, having SMTP site links
available provides fault tolerance and may be the only replication option available if the
direct IP connectivity required for RPC is absent.
SMTP replication requires that you:
Install a Windows Enterprise Certification Authority (CA) from which to

distribute digital certificates to the replicating bridgehead DCs.
SANS Institute
Install the 11s SMTP Service on the bridgehead DCs (if it is not already).
A digital certificate for each DC is required because the e-mail messages are encrypted
and digitally signed with an extended version of S/MIME. The encryption, however, is
only 56-bit, and there appears to be no documented way of increasing the keysize.
Note: The steps for installing a Certification Authority and distributing

certificates will be discussed in the Windows PKI seminar. Please refer to that
manual for more information.
Importantly, even though the 11s SMTP Service must be installed, this does not mean that
the 11s HTTP Service must also be installed. These are two separate daemons in the TIS
package. If the HTTP component has already been installed, just stop and disable the
World Wide Web Publishing Service on the DC.
The 56-bit encryption is better than nothing, but somewhat disappointing, especially
since SMTP replication is specifically intended for over-the-Internet replication.
Fortunately, the SMTP Service can be configured for 128-bit Transport Layer Security
(TLS) link encryption (and so can Exchange Server and many other SMTP engines).
SANS Institute
The Schema is the "blueprint" for the Active Directory database. Strictly speaking, the
Schema is the set of definitions for the classes and attributes of AD objects, following
object-oriented programming guidelines. Every object that exists in AD is an
instantiation of a class in the Schema (e.g., a user account is an instance of the User class)
and classes can inherit properties from each other.
You can add your own custom classes and attributes to the Schema, hence, you can create
virtually any type of custom object you like in AD. Some installation programs, such as
the one for Exchange 2000, modify the Schema automatically. The Schema can be
viewed and edited with the AD Schema Manager snap-in. (As discussed earlier, you
cannot install the Schema Manager snap-in until after you execute "regsvr32.exe
schmmgmt.dl1" to register the tool's DLL.)
SANS Institute
El Bi: Acbve Directory Schema
n: applicabonEnbty Structural
% amlicabonProcess Structural
Adding
The AD database can be modified to contain new types of objects or attributes. For
example, if you would like your routers to download their configuration from AD, the
Schema can be modified to define the structures necessary to hold this information.
The Schema is edited using either ADS1 scripts or the Schema Manager snap-in. (As
discussed earlier, you cannot install the Schema Manager snap-in until after you execute
"regsvr32.exe schmmgmt.dl1" to register the tool's DLL.)
Warning! Making improper changes to the Schema can result in non-functional

domain controllers throughout the entire forest. And the Schema cannot be
authoritatively restored!
Before you can edit the Schema, you must enable Schema modifications on the FSMO
Schema Master. You also must be a member of the Schema Admins global group (or
have the same permissions as that group on the Schema).
You can create new attributes or whole new classes of objects by right-clicking on the
Attributes or Classes containers and selecting Create. The details and implications of
creating new items cannot be discussed here, but a taste of the process is possible if you
have a non-production server available.
To add a new attribute to the Schema on a disposable lab DC, open the Schema
Manager snap-in > right-click on the Attributes container > Create Attribute > Continue.
Enter the following properties and click OK:
Common Name: testproperty
LDAP Display Name: testproperty
Unique X.500 Object ID: 1.2.840.233.1.4.2510
Syntax: Case Insensitive String
Minimum: 1
Maximum: 1000
Deactivating Classes
You cannot delete classes or attributes in the Schema, but you can deactivate them. You
activate or deactivate a class or attribute by right-clicking it > Properties > (un)checking
SANS Institute
the box for the item's active state. When a class or attribute is "deactivated" it cannot be
used for the creation of new objects or classes. To reactivate a defunct class or attribute,
just (un)check the box again.
ote: Though not supported by Microsoft, you can delete items fiom the Schema
if you're willing to risk it (see InstantDoc #27096 at www.windowsitpro.com).
In Windows Server 2003 and later, however, there is an alternative to deletion. After
deactivating a class or attribute, it can be renamed. A new class or attribute with the
same name can then be created. The ability to rename Schema objects permits, in effect,
the editing of these objects: if an object needs to be edited, it can be deactivated,
renamed, and a new object created with just the changes desired. There are some
limitations on this capability, though, so make sure to research your proposed change
before relying on its possibility.
An attacker with physical access to a DC can modify that machine such that it will accept
changes to its local Schema even though it is not the Schema FSMO master. And this is
true whether the DC is in the root domain or a subdomain. Hence, physical security for
all DCs is critical even if you do have an "empty root" domain.
All domain controllers must be physically secured. The Schema Master machine
should receive special attention. If you wish to make the Schema Master DC a
virtual machine, that's fine, but running in a VMper se does not make a server
more secure.
Use read-only domain controllers running Windows Server 2008 or later at

locations where the security of the controller is at high risk.
Create a site just for the Schema Master in the AD Sites And Services snap-in.
The site should have one subnet object linked to it, and that subnet should have a
32-bit subnet mask and address just for the IP address of the Schema Master.
Configure an intersite connector for it and schedule replication to occur only once
per week at a specific time, e.g., only on Thursday at 3:OOpm. (You can always
force replication to occur immediately whenever you wish.) Most AD changes
that administrators plan to do which may cause harm are done on Friday after
users have left, so scheduling replication on Thursday gives the longest period of
time to disconnect the Schema Master in case of trouble; also, this delayed-
replication site can be used for doing authoritative restores of accidentally- or
maliciously-deleted objects (InstantDoc 42932).
Using IPSec or a personal firewall, block all packets to/fiom the Schema Master
except the packets fiom one other chosen domain controller with which it will
replicate. If possible, schedule changes in the filtering rules such that these
unblocked packets are only allowed during the scheduled replication period, e.g.,
SANS Institute
only on Thursday at 3:OOpm (a scheduled batch script with IPSec filtering is great
for this). Because clients cannot use the Schema Master for normal AD
operations, most of the Schema Master’s SRV records in DNS should be removed
so that clients will not waste time trying to connect to it (KB306602).
Only temporarily add administrators to the Schema Admins group when changes
to the schema need to be made. Remove members from the group immediately
after changes are successful. Under normal circumstances, the Schema Admins
group should be empty.
Use the Restricted Groups feature of Group Policy to enforce proper membership
in the Schema Admins group.
Audit and alert on changes to the Schema Admins group through AD SACLs
and/or a host-based IDS system.
Audit and alert on all successful and failed write access to the Schema NC itself
through AD SACLs and/or a host-based IDS.
Have good backups of all domain controllers so that, in a worst case scenario, you
can restore all the DCs to a state prior to the corruption of the schema.
SANS Institute
There are some services which are not suited for multi-master replication. These services
run in Flexible Single Master Operation (FSMO) mode instead of multi-master mode. If
a DC is running a FSMO service, then that DC is called the "FSMO Master'' of that
service and is said to have or play that "role". Microsoft usually shortens FSMO Master
to just "Operations Master".
There are five Operations Master roles:

1) PDC Emulator Master
2) RID Master
3) Infrastructure Master
4) Schema Master
5 ) Domain Naming Master
.
I
Open a command-prompt window and execute "netdom query fsmo" to see a list of the
current Operations Masters. Try "netdom help" too, because this is a tool you should
become familiar with.
C:\>netdom query fsmo

Schema owner godzilla.fossen.net
Domain role owner godzilla.fossen.net
PDC role godzilla.fossen.net
RID pool manager godzilla.fossen.net
Infrastructure owner godzilla.fossen.net
The command completed successfully.
C Emulator Master (one per domain)

For downlevel compatibility with NT 4.0 domain controllers and clients, the PDC
Emulator acts as a mixed-mode PDC, replicates data to NT 4.0 BDCs, and is the
Master Browser for legacy clients.
Also, by default, when a user's password is changed, this new password

information is replicated to the PDC Emulator on a best-efforts basis, which can
then expeditiously replicate it to the other DCs, including any NT BDCs. This
can be disabled when slow WAN links make this inconvenient for remote sites
(KB232690, KB2255 11).
Additionally, when a user attempts to log on with an incorrect password, his or

her authenticating DC will check that password against the accounts database on
the PDC Emulator; the thinking is that perhaps the user's password is actually
correct, but the authenticating domain controller simply hasn't been updated with
it yet. Both of these behaviors can cause unwanted WAN traffic, so it is possible
to turn these features off through a registry modification (Ks2255 11).
Account lockout signals are immediately sent to the PDC Emulator.
Changes to the LSA Secrets are immediately sent to the PDC Emulator.
Changes to inter-domain trust account passwords are immediately sent to the PDC
Emulator.
RID Master role owner changes are immediately sent to the PDC Emulator
The PDC Emulator is the preferred machine when administrators edit Group
Policy Objects over the network. This can be changed with the GPO option
named "Group Policy Domain Controller Selection" (discussed tomorrow).
The PDC Emulator also plays a special role in time synchronization, which is
critically important for Kerberos to function. All desktops and member servers
synchronize their clocks with their authenticating domain controllers; domain
controllers synchronize their clocks with the PDC Emulator in their respective
domains; PDC Emulators synchronize their clocks with the PDC Emulator of
their parent domain forming a "synchronization chain" up to the PDC Emulator in
SANS Institute
the root domain. Hence, the PDC Emulator in the root domain should be
synchronized with a reliable and trusted source. The "NET TIME" command can
be used to do just this (KB224799, KB216734, KB223 184) and see also the
W32TM.EXE tool.
Also, every 60 minutes the PDC Emulator will compare the permissions on the
users in the Administrators, Domain Admins, Schema Admins and Enterprise
Admins groups against the permissions on the \System\AdminSDHolder container
in AD. If they differ, the ACLs on the users will be changed to match the ACL on
the AdminSDHolder container (KB232199, KB3 18180).
aster (one per domain)

A Security Identifier (SID) is a unique number assigned to every user, group and
computer in a domain. Part of the SID is the same for all members of the domain,
but the other part is unique for each user, group and computer. This unique part is
called the Relative Identifier (RID). The job of the RID Master is to allocate
blocks of RIDS for each DC's use. When a DC has only 100 RIDS left to assign to
new objects from its original block of 512, it will contact the RID Master and
obtain another block of free numbers.
nfrastructure aster (one per domain)

Except for the Global Catalog, Domain NC data is not replicated between
domains. However, objects in one domain may reference objects in other
domains; for example, a group in one domain may have as a member a user from
another domain. When an object in one domain changes, and that object is
referenced in other domains, the other domains need to update their references.
The Infrastructure Masterk job is to query the Global Catalog to discover when
these changes have occurred and to update the references accordingly. The
Infrastructure Master will then replicate these updates to the other DCs.
ote: In a multi-domain environment, the Infrastructure Master should

not also be a Global Catalog server. This setup will cause the
Infrastructure Master to never find bad references.
Sche
Only the Schema Master can make changes to the Schema. The Schema defines
the structure of the objects and attributes in the AD database.
Only the Domain Naming Master can authorize the addition or removal of
domains froin the AD forest. You must be able to contact this FSMO master
when performing these actions.
You can reassign Operations Master roles to different DCs. For each of the roles below,
right-click on the listed snap-in and select "Operations Master".
SANS Institute
Schema Master AD Schema snap-in

Domain Naming Master AD Domains and Trusts snap-in
RID Master, PDC Emulator AD Users and Computers snap-in
Master, and Infrastructure Master
Right-click on "AD Users and Computers" snap-in and choose "Operations Master"
Click on each of the three tabs and note the Master for each role. Click Cancel.
Changing Operations asters Forcibly

In the event that a FSMO Master has become permanently unavailable, a DC can be
forcibly promoted to an Operations Master with the NTDSUTIL.EXE tool. Keep in mind
that the first DC installed in the first domain will have all five roles by default.
However, if the RID Master's or Domain Naming Master's role is forcibly transferred to
another system with NTDSUTIL.EXE, the box which previously held this role can never
be brought back on-line again. You must reinstall the operating system on that box (see
KB216498 for the steps to remove all traces of the old DC). The old PDC Emulator and
Infrasti-ucture Master can be brought back on-line, on the other hand, even if their roles
have been transferred (and then you can gracefully txansfer the roles back again).
S A N S Institute
D \>ntdsutil roles help

ntdsutil roles
fsmo maintenance help
? - P r i n t t h i s help information
Connections - Connect t o a s p e c i f i c domain c o n t r o l l e r
Help - P r i n t t h i s help information
Quit - Return t o the p r i o r menu
Seize domain naming master - Ouerwrite domain r o l e on connected seruer
Seize i n f r a s t r u c t u r e master - Ouerwrite i n f r a s t r u c t u r e r o l e on connected s e r v e r
Seize PDC - Ouerwrite PDC r o l e on connected s e r v e r
Seize R I D master - Ouerwrite R I D r o l e on connected seruer
Seize schema master - Ouerwrite schema r o l e on connected seruer
Select operation target - S e l e c t s i t e s , seruers, domains, r o l e s and Naming
T r a n s f e r domain naming master - Make connected seruer the domain naming master
T r a n s f e r i n f r a s t r u c t u r e master - Make connected seruer the i n f r a s t r u c t u r e master
T r a n s f e r PDC - Make connected seruer the PDC
T r a n s f e r R I D master - Make connected s e r v e r the R I D master
T r a n s f e r schema master - Make connected seruer the schema master
as
Have written disaster recovery plans in place to handle downed Operations
Masters. It should cover how or whether to force role transfers, which backup to
restore from, who to notify, etc. In general, though, it is better to fix or recover an
Operations Master than to transfer its role to another box, so make frequent
backups.
Separate the RID Master and PDC Emulator roles across two physical DCs, but
put the boxes in the same AD site and on the same LAN to ensure steady
replication (KB223346). Remember, if a hacker wanted to cause the most
disruption by taking out a single domain controller, the PDC Emulator would be
it.
Place the PDC Emulator on a segment which has the best overall connectivity
with other DCs, especially DCs in remote sites, and upgrade its hardware as the
domain grows to avoid its becoming a bottleneck.
The PDC Emulator should not itself directly synchronize with a time server on the
Internet. Choose another secure machine inside the LAN to synchronize its clock
with an external server, then have the PDC Emulator synchronize with it.
The Schema Master and Domain Naming master roles should be located on a
single DC, and that DC should be closely watched and physically protected.
In a single-domain environment, simply inark all DCs as GC servers. This will

not cause any extra replication traffic. There are some services and applications
which will only query the GC, even if there is only a single domain in the forest.
SANS Institute
In a multi-domain environment, a single system should not be both the

Infrastructure Master and a Global Catalog server at the same time. The
Infrastructure Master should be in the same site as at least one Global Catalog
server though because of its extensive use of a GC.
Each site should have at least one Global Catalog server, with preferably two or
more depending on capacity requirements.
If a remote site cannot support a GC server because of connectivity issues, then a

registry value can be set to allow logons without the GC (KB241789). In this
case, avoid specifying any Deny permissions to resources for universal groups
when possible.
The Domain Naming master should be a Global Catalog server. If the Domain
Naming master is not a GC and your forest is not in 2003 mode, the creation of
grandchild domains may fail.
SANS Institute
An almost universally-ignored and misunderstood topic is the role of property-level

permissions on data in the AD database. Ironically, this feature of AD is one of its most
useful, and security managers ignore AD ACLs at their own peril. Part of the reason it is
misunderstood is its implications for delegation of authority, hence, politics start to cloud
people's judgment. Let's see what all the fuss is about.
SANS Institute
anage inheritance:
- This object andlor "child"
objects in the container.
- Computer objects.
- Group objects.
- User objects.
ACL Conflicts:
- Explicit vs. Inherited.
Origin of ACLs:
- Explicit
- inherited
- AdminSDHolder
Every property of every object in the Active Directory database can have its own
separate set ofpermissions! In addition, there are object permissions, container
permissions, control of inherited permissions from containers, access auditing, and more.
These features make it possible to delegate authority and to regulate AD access very
precisely.
he Security Tab: dvanced Features

In order to see the Security tab on AD objects, you must enable the viewing of Advanced
Features. To do this, right-click on any container in "AD Users and Computers'' > View
> Advanced Features.
To see the permissions and audit settings on a container or object, right-click the item >
Properties > Security tab. The following screenshot shows the Security tab.
SANS Institute
Full contml m u
Read m u
wae m u
Create al! child otjects m u
Delete a[!child o$e& m u
Clicking on the Advanced button will show the full set of permissions and audit settings
for the item, as well as its owner. Only a summary of these settings is shown on the prior
Security tab. The following screenshot shows the Advanced property sheet.
Specie! This ab,ea on!
If you select a permission entry and click the View/Edit button, you open a property sheet
defining the permission. The screenshot below shows the View/Edit property sheet of a
permission. Notice there are two tabs: one for permissions for the object as a whole,
another for the permissions for the properties of that object (see below). The Name at the
top shows for which usedgroup the permission applies; click Change to select another.
SANS Institute
Access control entries (ACES)can be inherited from parent containers. This is true for
both discretionary access control lists (DACLs) and system access control lists (SACLs),
i.e., it is true for both permissions and audit settings.
An inherited permission or audit setting is displayed with a slightly grayed-out key icon
or a checkbox with a gray background.
A property of the object/container as a whole is the "protection flag", shown as a

checkbox labeled "Allow inheritable permissions from parent to propagate to this object".
Note that you can disable/enable ACE inheritance for both DACLs and SACLs separately
on the Permissions tab and the Auditing tab of the Advanced property sheet.
When you select View/Edit on an ACE, the Apply Onto pull-down menu controls the
propagation of the permission to subobjects and subcontainers which are inheriting
(KB178170). The Apply Onto setting can be configured separately for the object ACL
and the properties ACL. The items on the Apply Onto list include items such as:
This object only.

This object and descendant objects.
Descendant objects only.
Descendant aCSResourceLimits objects.
Descendant certificationAuthority objects.
Descendant Computer objects.
Descendant Connection objects.
Descendant Contact objects.
Descendant Group objects.
Descendant groupPolicyContainer objects.
Descendant IntelliMirror Group objects.
Descendant IntelliMirror Service objects.
Descendant MSMQ Configuration objects.
Descendant Organizational Unit objects.
Descendant Printer objects.
Descendant Shared Folder objects.
Descendant Site objects.
Descendant Site Link objects.
Descendant Site Link Bridge objects.
Descendant Site Settings objects.
Descendant Site Container objects.
Descendant Subnet objects.
Descendant Subnets Container objects.
Descendant Trusted Domain objects.
Descendant User objects.
SANS Institute
Active Directory 63
Full con+ml 0
List contents 0
Read all properbes 0
Write all properties
Delete 0
Delete subtree 0
Read permissions 0 0
Modi@permissions 17 0
r.lodiFf owner El o
AI1 validated writes 17 0
Notice the checkbox at the bottom labeled "Apply these permissions to objects and/or
containers within this container only". This box is grayed out if you select Apply Onto
This Object Only. But if these permissions are to be inherited by descendant objects in
this container, this checkbox controls whether the permissions are inherited by
descendant objects in the subcontainers as well (and the sub-sub-containers, and the sub-
sub-sub-containers, and so on). This checkbox is equivalent to the "propagate
permissions down only one level deep" found in other ACL editing tools.
eri ici
Note that a permission set explicitly on an object/container for a particular user/group
will override a conflicting permission on that object/container inherited from higher in
AD. Permissions assigned to a user/group are inherited, unless that user/group has been
specifically assigned a different permission on the item inheriting. Explicit permissions
always override inherited permissions; they are not merged or compared (KB233419).
For example, if user Bob has No Access on an OU, and a printer object in that OU is
inheriting, but the printer has been explicitly assigned Full Control to Bob, then the
inherited permission for Bob is ignored and Bob will indeed have Full Control of the
printer. It is not that Bob's Full Control permission somehow wins out over the No
Access, rather, the No Access permission is simply not processed for Bob. The same
would have been true if Bob had Write as the inherited permission and Read as the
explicit one: Bob's final permission would be Read, not Write.
SANS Institute
64 Active Directorv
An object's default owner is either Domain Admins or the Administrators group on the
domain controller, depending on what type of object it is. This can be changed on the
Owner tab. The owner of an object, just as with NTFS, can change the permissions on
that object at will and possesses the permissions assigned to CREATOR OWNER as
well. Users do not own their own user accounts by default. Properties do not have
owners, only objects like user accounts and OUs have owners.
While every AD property can have its own access control list, not every property is
visible in the GUI interface when assigning permissions. Many objects have over 100
properties, so it would be cumbersome to show them all in the graphical ACL editors.
Also, many of these properties are only modified by AD system processes and
administrators should not normally tamper with them.
Exactly which properties are visible to snap-ins is determined by an ASCII text file
named DSSEC.DAT located in \%SystemRoot%\System32\. This can be edited with
Notepad to reveal any property of any object in snap-ins so that permissions can be
assigned to it with those CUI tools. The alternative is to use a command-line ACL editor.
a 1 1owedch i1d C l asses E f f e c t i ve=7
Each type of object (like "[User]") is in square brackets; the properties of that object type
are listed below it. Simply change the "7" after the property name to zero or blank (see
"badPwdCount=" in the screenshot above) then close and re-open your snap-in, such as
the "AD Users and Computers" snap-in. You will see that property in the CUI ACL
editor. If a property is not listed, you can add it manually. The change takes effect
immediately, but you still must close and reopen the snap-in. Strictly speaking, 7 means
that the property is not shown in the GUI on the computer running the snap-in, 6 means
that the "Read" property will be shown, 5 means that the "Write" property will be shown,
and 0 or blank means both properties will be shown.
SANS Institute
Active Directorv 65
ote: Each new permission adds about 70 bytes to the AD database (KB197054).
e issi ?
The ACL on an object is determined by four factors:
The default permissions for that object's class in the Schema.
The permissions explicitly assigned to that object manually.
The permissions that object has inherited from its parent container(s).
The permissions on the AdminSDHolder container.
Every 60 minutes the PDC Emulator will compare the permissions on the users in the
Administrators, Domain Admins, Schema Admins and Enterprise Admins groups against
the permissions on the \System\AdminSDHolder container in AD. If they differ, the
ACLs on the users will be changed to match the ACL on the AdminSDHolder container
(KB232199, KB318180).
Whatever permissions and audit settings are set in a class in the Schema are the default
explicit permissions set on any new object created based on that class. Hence, if you
change the permissions in a Schema class, then create a new object based on that class,
that new object will have the custom permissions you added to the class. However, any
objects of that same type which already existed before you modify the ACL will not have
their permissions dynamically reset to match the new ACL on that class. Note that it is
not the permissions on the class object itself which are copied, but the permissions
defined in the defaultSecurityDescriptorproperty of the class which are copied to the new
instance of the class. Search for "defaultSecurityDescriptor"on Microsoft's website for
more information about the syntax of the SDDL strings found there (KB297947).
arning! Modifications to the Schema can have far-reaching and unintended

consequences. Test all proposed changes in a lab first. Fortunately, you can
always go back and re-edit the ACL on a class, so this change is more forgiving
than other Schema modifications, but note that this still will not dynamically
change the ACLs of the objects which had been created based on it.
As an example, you might create a new class called "sensitiveUser" based on the "user"
class. This new class would be no different, except that its default DACL would be more
strict, and its SACL (for auditing) would audit all failed access and all successful
changes. Sensitive user accounts --like those of managers, OU administrators, HR
personnel, etc.-- would be created based on the sensitiveuser class instead of the default
user class. A custom MMC console with a script would be used to create the accounts.
Another example would be to modify the ACL on the user class so that users could not
modify their own personal information, such as phone numbers (KB292304). But any
user account which had already been created would have the old default permissions.
Fortunately, you can use DSACLS.EXE to search-and-reset default Schema permissions

on objects in selected domains and OUs.
__
SANS Institute
66 Active Directorv
- Support Tools - Dumps ACLs in a very

- Editheplace ACLs detailed format.
- Cannot edit ACLs.
- Reset Schema defaults.
- Recursively remove
- Display cumulative final
permissions for a specified
permissions for a selected user or group.
user or group.
- Compare against defaults - AD is 100% scriptable!
from the Schema.
- VBScript, Ped, JScript, etc.
- Dump tab-delimited ACLs.
- This includes ACLs.
There are a variety of command-line tools available for viewing or setting AD access
control lists (ACLs). The ADS1 2.5 interface can also be utilized with custom scripts to
do the same.
DSACLS.EXE is a Support Tool that is the command-line equivalent of the Security tab
on AD objects. An advantage of DSACLS is that it can edit permissions on an item
without overwriting the item's other permissions. The utility can also control inheritance
and reset permissions back to the defaults defined in the Schema.
Display Permissions, Owner and Audit Settings (/A)

To show the permissions on the Guest account, as well as its owner and audit
settings, you would execute the following (without /A, only permissions shown):
Dsacls .exe "cn=Guest,cn=Users,dc=domain,dc=domain" /A
efault Permissions from Schema (/S and /T)

When a new object is created in AD it can inherit permissions from its container,
but that object's initial explicit permissions come from its class definition in the
schema. The schema not only defines an object's structure, but also that object's
default permissions. DSACLS.EXE can reset an object's explicit permissions
back to their "factory defaults'' when mistakes have been made customizing its
ACL (/S). You can do the same for an entire OU and everything inside it (/S /T).
SANS Institute
Active Directorv 67
The ability to restore explicit permissions to their schema defaults is extremely useful.
For example, if you accidentally mangle the permissions on a few thousand user accounts
(or any type of object) and you wanted to fix it before anyone else notices, try this:
1. Create a new, temporary OU.
2. Move the objects into the new OU.
3. Use DSACLS.EXE to restore all those objects to their default permissions.
4. Move the objects back into their old OU.
5. Delete the temporary OU.
If the permissions were mangled on the OU itself, just edit its ACL by hand to match the
ACL for the organizationalunit class. Be wary of using DSACLS.EXE on the old OU
itself because you'll likely reset the default permissions on everything in the OU too (if
you use the /T switch). If that's what you want, fine, but the steps above assume there are
other things in the OU besides the mangled user accounts.
Another use is when you wish to change the default permissions on all objects of a
certain class. You'll modify the ACL on the class in the schema, which will affect all
new objects based on it, then you'll use DSACLS.EXE to reset all the existing objects of
that type to their (new) schema defaults.
Let's look at some command-line examples. If you wanted to reset the default explicit
permissions on a user account named "Bob Tenvilliger":
dsackexe "cn=Bob Terwilliger,ou=Boston,ou=East Coast,dc=usa,dc=sans,dc=org"

IS
If you wanted to reset the default permissions on all the objects in the Boston OU, the
command-line would look like this (careful of the /T switch!):
dsacls.exe "ou=Boston,ou=East Coast,dc=usa,dc=sans,dc=org" IS IT
ACLDIAG.EXE is a Support Tool from the Windows Server CD-ROM for viewing AD
permissions and audit settings. It cannot be used to access remote systems.
ACLDIAG.EXE can do the following:

Display the final, cumulative, effective permissions and audit settings a user or
group has to an item in AD in a user-friendly format.
Compare AD permissions against the default permissions from the schema.
Fix permissions set with the Delegation of Control Wizard using a built-in
template (this amounts to simply reapplying the template from the command line).
Dump AD permissions in a tab-delimited format suitable for import into a
spreadsheet or database.
SANS institute
68 Active Directory
P:\>acldiag "cn=Rdministrator,oniusel.s,dc=sans.dc=g" : f indztr "Eueryone"

Allow \Eueryone Change Password
Rudit Successful and Failed Create all subobjects attempts by \Everyone
Rudit Successful and Pailed Delete all subobjects attempts by \Eueryone
Rudit Successful and Failed CIrite all propertics attempts by \Everyone
Rudit Successful and Failed R11 c o n t w l accesses attempts by \Everyone
Rudit Successful and Failed Modify nemhership attempts by \Everyone
Rudit Successful and Failed Create all suhobjmets attempts by \Eueryone
Audit Successful and Failed Delete all subobjects attempts by \Eueryone
Rudit Successful and Failed Write all properties attempts by \Everyone
Audit Successful and Failed All control accesses attenpts by \Everyone
Rudit Successful and Failed Modify Membership attempts by \Everyone
The following screenshot shows a tab-delimited ACL produced by ACLDIAG.EXE

imported into a spreadsheet for analysis. This capability is very important for conducting
automated audits of AD access control lists. A script could dump all ACLs into a
database, compare them against a similar dump from three months ago, then list all the
differences. Having such a comparison baseline is also useful for troubleshooting.
This-obJecJxi_ - elow ,BUICTIN\Pre-Wlndows 2000 Compatible Access LisCconten& - 1 (from dc=sans,dc=org

All Subobpcts Allow BUILTINMdministrators &Createall subobjects (from dc=sans,dc=org
All Subobjects Allow BUILTNMdrninistrators Read all properties (from dc=sans,dc=org
All Subobjects Allow BUILTINMdministrators Write all properties (from dc=sans.dc=org
All Subobjects Allow BUILTINMdministrators List contents (from dc=sans.dc=org
A! Su&IJbje_Sts- Allow BUJI~~dministrators I List object- (firtm Lc-=sans.d_c=org
All Subobjects Allow 'BUILTINMdministrators All control accesses (from dc=sans,dc=org
All Subobjects Allow iBUILTIN\Adrninistrators Modify Membership (from dc=sans.dc=org
All S_ubobjects Allow SANS\Enterprise Admins :Create all subobjects -(from dc=sans,dc=org
All Subobjects ;Allow iSANS\Enterprise Admins !Delete all subobjects *(from dc=sans.dc=org
AllLu&bjgets Allow ISANS\Enterprise Admins Re2d all propsies I $Em dc=sans.dc=org
All Subobjects .All_ow /SANS\Entypriy Admins Write all properties (fr!m dcEsans_.dc=org
All Subobjects ,Allow tSANS\Enterprise Admins -'~ist contents ,(from dc=sans.dc=org
All Subobjects Allow lSANS\_EnterpriseAdmins 'List ObJKct (from dc=sans,dc=o
All Subobjects Allow ;SANS\Enterprise Admins All control accesses (from dc=sans,dc=o
All Su@bJ@?__AllLw /SANS\Enterprise A i m s ? Ix I- Modify MemLeiLkp- (from-d=sag.dc=o
All Subobjects _-Allow__,BU_ILJIN\Pre_Windows 2000 Compatible Access +List contents_ I ( h m dc=sans,dc=o
Group objects Allow 'BUILTIN\Pre-Windows 2000 Compatible Access .Read all properties Inherited permission
Group objects Allow BUILTIN\Pre-Windows 2000 Compatible Access List contents Inherited permission
Y BUILTIN\Pre-Windows 2000 Compatible Access List Object Inherited permission
SDCHECK.EXE, also one of the Support Tools, displays ACL information in a very
detailed format. It cannot be used to change permissions or audit settings. A useful
aspect of the tool is that it shows both inherited and explicit permissions, and gives the
parent container from which an inherited permission was inherited.
E
DSREVOKE is a separate download from Microsoft. It recursively displays or deletes
AD permissions for a specified user or group at your specified OU and its sub-OUs.
However, the tool cannot remove permissions set on non-OU containers or other non-OU
objects unless those permissions were inherited from a parent OU. The tool also cannot
remove permissions set within the Schema or Configuration naming contexts.
SANS Institute
Active Directorv 69
The Active Directory Services Interface (ADSI) enables programmers to manage AD

permissions with custom code, including VBScript and Per1 scripts. ADSI version 2.5
can be used for the management of permissions, auditing and ownership of Active
Directory objects. For more information, see the following:
http://www.microsoft.com/adsi/
http://msdn.microsoft.com/scripting/
The ADSI interface can also be accessed through standard Visual Basic, C/C++, and the
.NET Framework languages like C# and VB.NET.
SANS Institute
70 Active Directory
Delegate authority using:

- Active Directory permissions.
- Group Policy.
- Q: How would you delegate authority

over a shared folder to a user?
- A: Give the user Full Control over it!
administrator on just one machine?

- A: Add their user account to the local
Administrator's group on just that box!
In NT 4.0, it was difficult to give a user any administrative powers without making him
or her a full administrator for the entire domain. In Windows 2000/2003, on the other
hand, it is possible to delegate administrative power very precisely. This is true even in a
single-domain environment.
Here are a few examples of how power can be delegated in AD:
A non-administrative user could have full control over all user and computer
accounts in an OU, but no other OUs. "Non-administrative1'means that that user
is not a member of Enterprise Admins, Domain Admins or the local
Administrators group on any domain controller.
A help desk global group could be given the power to reset anyone's password in
the domain except for the sensitive user accounts, such as those of administrators
and service accounts.
Alternatively, each OU could have its own separate help desk group, and each
group could only reset passwords for users in their assigned OU.
A non-administrative user or group could be given the authority to join a single

particular computer to the domain or have the blanket authority to add any
number of computers to the domain. This can be restricted on a per-OU basis too.
SANS Institute
Active Directorv 71
The receptionists global group could be given the power to change a single
property of all user accounts (e.g., home phone number) but not be able to change
anything else.
A global group could be given the Backup Folders and Files user right on all
computers in an OU, but not have this right anywhere else. This group would not
necessarily have to have the Restore Folders and Files right either.
ele ver
Consider, if you were a Domain Admin and you wanted to give a regular user the ability
to manage the contents of a shared folder, how would you do it? Simple! You simply
give that user Full Control over the NTFS folder and the share. Now that non-
administrative user can add, delete, rename, move, and copy files in the share. All other
users can only read the contents of the folder.
Instead of a shared folder, apply the same thought process to an OU. In this case, it is not
files in a folder but user and computer accounts in an OU that the non-administrative
person will have power over. The only thing that's strange here is that a user account is
both an object in AD (hence, it has permissions) and something that another person uses
to log onto the domain.
And because each property of a user account can have its own separate ACL, you can
delegate authority over each of these properties.
In abstract, then, "delegation" has three parts:
1. The object --user, group, computer, shared folder, OU, domain, whatever-- that
someone will be given full or limited power over (power is always power "over"
something). This object must have permissions or some kind of access control
mechanism that can be modified on a per user or per group basis.
2. The person who already has the power to change the permissions on that object.
This is almost always an administrator, but includes anyone with the equivalent of
the Change Permissions permission on the object. This person is the one who
''grants" authority to another over the object.
3. The person who "receivesttthe authority. This is the person who will have
additional permissions on the thing over which they will have authority. The
exercise of this authority is made possible through these permissions. People
without the authority lack the permissions on the object to modify it anyway.
Delegation assumes that the person who grants the authority 1) has the legal/political
right to do so, 2) the person receiving the authority has the legal/political right to exercise
it through powers over the delegated object, 3) there is a mechanism in place to prevent
others from exercising those same powers when they have not been given these
legal/political rights. These "legal/political rights" are relative to your organization (e.g.,
SANS Institute
72 Active Directory
commercial corporation, military base, government office) and may be enforced through
threat of employment termination, fines, three years in Leavenworth prison, etc. Hence,
delegation of authority in AD is more than just modification of AD permissions, but it is
what we are concerned with here.
est Practices for Delegating

The following is a list of best practices for delegation of authority, with examples to
follow in the next few slides:
Write a policy document which describes exactly how you want to delegate
authority, the names of the groups to which authority will be granted, the exact
permissions these groups will have, and keep a written log of all changes. AD
permissions can become confusing very quickly, hence, write a plan first, stick to
it, and document when you deviate from it.
Focus delegation on Organizational Units. Try to delegate authority as high as

possible in the OU structure. Design your OUs around how you plan to delegate
authority, then create sub-OUs as necessary for Group Policy needs.
Try to avoid delegating authority over sub-OUs in a way which contradicts the
authority assigned at the parent level. In short, avoid creating "delegation
orphans'' in an OU structure where descendant OUs are not under the control of
those groups which control its parent(s).
In general, it is better to create new OUs and assign custom permissions to them
than to modify the permissions on the built-in OUs or the domain container itself.
If there is ever a problem with the ACLs you configure on your custom OU, you
can usually move its contents to another OU or reset those its ACLs to their
schema defaults without worrying too much about crashing AD. When modifying
permissions on built-in OUs or at the domain level, see if you can achieve your
ends by adding new Allow permissions instead of adding Deny permissions or
changing the factory-default access control entries from Microsoft.
Assign permissions to groups when you delegate, not individual users, and grant
the least power necessary to let delegates get their work done, but no more. This
is just best practice for assigning any kind of permission.
Don't forget that AD supports auditing as well as permissions. Diligent auditing

will not prevent misuse, but it can detect it, limit its further action, and document
what damage has been done so that it may be repaired. In a politically-charged
organization, auditing allows peaceful coexistence through the policy of "trust but
verify". (Auditing is discussed in an up-coming section.)
Use Group Policy to restrict access to powerful snap-ins. For example, create a
domain-wide Policy that blocks access to all administrative snap-ins to all users
SANS Institute
Active Directory 73
except members of the various OU and Domain Admins groups. But don't forget
that other tools are easily available which are not snap-ins.
Create custom MMC consoles for delegates that only show the OUs or objects
over which they have control, and add "Tasks" to the console to help them use
their authority safely. This should also help reduce their support phone calls to
you.
Be cognizant of the political ripples your delegation choices will make. Political
battles among IT staff are made more intense by Active Directory, not less.
Consider investigating third-party tools for managing AD permissions if you'd

rather not edit the raw AD permissions.
g on the delegation bandwagon by providing tools that simplify and

automate the delegation process:
Aelita Enterprise Directory Manager (http://www.aelita.com)
BindView bv-Admin for Windows 2000 (http://www.bindview.com)
FastLane ActiveRoles (http://www.quest.com/fastlane/activeroles/)
NetIQ Directory Security Administrator (http://www.netiq.com/products/dsa/)
astLane Active
FastLane ActiveRoles (http://www.quest.com/fastlane/activeroles/)is a commercial
product specifically designed to help manage delegation of authority. It uses the native
permissions in AD for delegation, so you are not forever bound to their product and you
don't have to deploy special FastLane applications to those who will be granted authority.
Create custom "roles" or use the built-in categories in the product, then assign users or
groups to these roles. Next, choose the OU or domain where you want that role to have
special authority. Role definitions can be downloaded from their website or you can
define custom ones yourself.
Importantly, you can produce detailed reports on sets of AD permissions, and you can use
the verify feature to check that the roles set by the product are still in effect. There are
also web-based tools for help desk staff. The ActiveRoles tool itself is an MMC snap-in.
SANS Institute
74 Active Directory
To assist in the delegation of administrative powers, Windows 2000/2003 includes a

Delegation of Control Wizard. It can be found on the context menus of containers in the
"AD Users and Computers" and "AD Sites and Services" snap-ins.
The Wizard can simplify the process of delegating many common tasks, such as resetting
passwords and the ability to add users to groups. The end result of using the Wizard is a
new set of permissions on the relevant AD items.
Let's use the Delegation of Control Wizard to give a global group the ability to reset
passwords on any user account in a single OU. Create an Organizational Unit named
"Boston" and a security global group named "Boston Help Desk".
_. _.
Note, too, that the checkboxes which appear in the Delegation Wizard can be edited to
include any custom task you wish. The DELEGWIZ.INF file determines what
checkboxes appear in the Wizard and what changes they make (KB308404). The format
of the file is not too obscure, and, once made, the file can be shared with other
administrators to simplify their work.
To delegate password-reset authority over the Boston OU > right-click the Boston OU >
Delegate Control > Next > Add > select the group you wish to grant authority to, e.g.,
Boston-OU-Help-Desk-Staff > Add > OK > Next.
SANS Institute
Active Directorv 75
Check the box labeled "Reset password" > Next > Finish. That's it! (Note: the
checkboxes in the screenshot below will look different from yours because the picture
came from a machine with a custom DELEGWIZINF file.
Tasks to Delegate
You can select common tasks or customizeyour own
d all uset infotniaion

te, delete and manage groups
ity the membership of a group
ge Group Policy links
ontiol over the entire OU [for an OU Admins group]
e
The Delegation Wizard tool suffers from some important limitations:
It only appends additional permissions to an item's ACL. It cannot remove prior

existing permissions or de-delegate authority already granted (see
D SREVOKE.EXE).
It cannot be used to specify Deny permissions to limit authority.
It cannot configure audit settings.
It cannot delegate control over an individual object separately from its OU.
SANS Institute
76 Active Directorv
It cannot be used on the Builtin container (or the LostAndFound container).
And, if there are problems during the delegation process, the Wizard will not help
you to repair faulty permissions you have already set or otherwise assist in
troubleshooting, e.g., it cannot compare permissions on an object against that
object's default permissions from the schema.
However, all of these limitations can be overcome when you manage the raw AD
permissions yourself. Let's run through a variety of delegation tasks together.
SANS Institute
Active Directorv 77
- Web-applications
exclusive full control over

an OU for contact objects.
group to have write
access to phone number
fields -with exceptions!
IT staff are not the only ones who will need to edit Active Directory. Because AD is
intended to be a general-purpose directory database, many groups within your
organization may need to manage their portion of it. For example, if AD were used as
the Human Resources database, then HR personnel would need to be able to edit and
have exclusive access to such data as salaries, disciplinary histories, 401K plan
information, Social Security numbers, health insurance plan beneficiaries, etc., all of
which would be stored in AD as properties of user accounts.
Let's take as an example granting the Receptionists global group the permissions
necessary to edit the phone number information for all users except those of a certain OU
which contains contacts for the Sales group. The Sales group will then be given the
authority to create contacts in this OU and edit all their fields.
ce issio er S
Create a global security group named "Receptionists", then give that group write
permission on the phone/fax/pager fields of User Objects and Contact Objects at the
domain level. These permissions will be inherited throughout the domain. Alternatively,
you could assign these permissions on just selected OUs.
The property permissions you will be granting to User Objects and Contact Objects are
the following:
Write Fax Number
Write Fax Number (Others)
SANS Institute
78 Active Directory
Write Home Phone

Write Home Phone (Others)
Write Mobile Number
Write Mobile Number (Others)
Write Pager Number
Write Pager Number (Others)
To grant write permission to the Receptionists group, right-click on your domain name in
"AD Users and Computers" > Properties > Security > Advanced > Add > select
Receptionists > OK > Properties tab > select "User Objects" from the list of Apply Onto
options > check the Allow box next to the desired permissions (see above) > OK > OK >
OK. Now, repeat the exact same procedure, but for "Contact Objects" instead.
revent Edits To Contacts In An OU

Imagine that the sales department does not want any of the receptionists to be able to
change any information on contacts in a certain OU. We could prevent the OU from
inheriting any permissions at all, but this is overkill. Instead, we will simply deny write
access on the permissions above to Contact Objects on the OU. These deny permissions
will be inherited by the contacts, hence, the Receptionists group will have both
Allow:Write and Deny:Write permissions, but because neither permission has been
explicitly assigned to the contacts themselves, the deny permission will override the
allow permission.
This time, we will use all the same permissions as above, except that these permissions
will be set to "Deny", and we will be doing it on a single OU instead of at the domain
level.
To prevent the Receptionists group from modifying any Contact Objects in an OU, right-
click on that OU > Properties > Security tab > Advanced > Add > select Receptionists >
OK > Properties tab > select "Contact Objects" from the Apply Onto list > check the Deny
box for all the phone/fax/pager fields (see above) > OK > OK > OK.
Keep in mind, too, that these permissions will always be enforced against Receptionists.
It doesn't matter whether they use a script, snap-in, or third-party tool.
it Sales G ~ Q U anage Contacts

Finally, we will permit members of the Sales global group to create and manage contacts
--and only contacts-- in the OU.
To allow Sales group members to manage contacts in an OU, right-click on the OU >
Properties > Security tab > Advanced > Add > select the Sales group > OK > Object tab
> select Contact Objects from the Apply Onto list > check Allow next to Full Control > OK
> OK > OK.
SANS Institute
Active Directorv 79
What if we wanted to allow the Sales group to create distribution global groups so they
could add their contacts to these groups? This is not so easy to delegate. You can give
them the permissions to create groups, but you can't prevent them from creating security
global groups if you do so (not a big deal, but we want to be tidy).
Solution? A partial solution is to create a custom script for their console which allows
them to create only distribution groups in their OU. This would then have to be followed
up with periodic administrative audits to ensure no security groups had been created.
Keep in mind that if Sales members do create any security groups, this does not
compromise network security in and of itself: these groups would have no built-in rights
or permissions, and they could only be created in that one OU. Auditing group creation
in the OU will help to identify troublemakers.
SANS Institute
80 Active Directorv
- You can associate your own

scripts with icons.
- Properties of the highlighte~
object can be passed as
arguments to your scripts.
The Microsoft Management Console (MMC) is an application which displays and

manages other administrative tools called "snap-ins". The MMC doesn't really "do"
anything itself, it merely helps to make the use of snap-ins easier.
To bring up a new empty console, go to the Run line and execute "mmc.exe"
Importantly, MMC consoles can be customized, and this customization requires no

programming, registry modifications, or AD edits. Customizing the MMC is a point-and-
click procedure, with Wizards to assist.
hy Create Custom Consoles?

Custom consoles can be created to make one's own work more efficient, but, more
importantly, it helps to make the process of delegating authority a success.
Many of the people who will be granted additional authority in AD will find it
extraordinarily difficult to actually exercise this authority with the raw snap-ins. For
example, imagine loading up the "ADUsers and Computers" snap-in on the receptionist's
desktop and saying, "There you go! 'I. A custom console for the receptionist, on the other
hand, would make his or her AD tasks 95% easier.
Even network administrators who are new to Windows will greatly appreciate your
making custom consoles for them until they learn more about AD. And when the ease of
SANS Institute
Active Directorv 81
custom consoles is combined with the scriptability of AD, you will be able to save
yourself real time and effort.
S? re ?
You can add your desired snap-in tools to a custom MMC console and save it. Then,
whenever you open the console, only your desired tools are shown.
Try It !
To add a snap-in tool to your console, pull down the Console menu (or the File menu in
XP) > Add/Remove Snap-In > Add > double-click each desired tool > Close > OK.
If the tool you are looking for is not available, then you don't have the relevant service or
product installed on the local machine. Importantly, if you create a custom console and
copy it to a remote system, that system must have the necessary snap-ins locally installed
as well. Remember, the MMC just displays snap-in programs that already exist on the
computer where the console is being opened.
emote Server Administration

Fortunately, you do not have to be sitting at a domain controller in order to manage
Active Directory. The Windows Server 2003 CD-ROM includes an installation program
(\i386\ADMINPAK.MSI) for a variety of server and AD management snap-ins to be used
on Windows XP, and you can download the "Remote Server Administration Tools
(RSAT)" from Microsoft for Windows Vista.
Not only can you add standard snap-in tools, you can also add ActiveX controls, such as
NetMeeting and Performance Monitor, or an embedded version of Internet Explorer with
a shortcut to a specific URL. An ActiveX control will most often be added when you've
installed a third-party tool for this. The URL shortcuts are called "Link To Web
Address" snap-ins; these are handy for pre-configuring a console for a user with all the
webpages he or she will need to get their work done.
... .. . . .. ... .. . . .. .. .. . . . .. . . . .. .. .
?
Let's look at an example. The following screenshot shows a customized console which
only shows the contents of the Users container in AD. Along the side are icons for
common tasks such as creating user accounts, resetting passwords, enabling/disabling
SANS Institute
82 Active Directory
accounts, renaming accounts, deleting accounts, etc. The console could have been
created to point to any container or OU in the directory.
To create a custom MMC console similar to the screenshot above, follow these steps:
1. Open a new empty console (mmc.exe).

2. Console menu > Add/Remove Snap-in.
3. Add > Active Directory Users and Computers > Add > Close > OK.
4. Right-click on the Users container in your domain > New Window From Here.
5. Window menu > select original window > close it.
6. Right-click on yellow Users container > New Taskpad View > Next.
7. Select Vertical List, InfoTip, and Large list size > Next.
8. Select "All tree items.. ." > check the box > Next.
9. Set name to "Users Container" and description to your AD domain name > Next.
IO. UNcheck the "Start New Task Wizard" box > Finish.
11. Right-click yellow Users container > Edit Taskpad View > Tasks tab.
12. New > Next > Menu Command > Next > Command Source: Tree Item Task.
13. Select "New+User" from available commands > Next.
14. Enter "Create User Account" as the task name (and change description) > Next.
15. Choose an icon > Next > Finish > OK.
16. (Follow steps 11 through 15 for other tasks as well, e.g., reset password.)
17. Right-click yellow Users container > Edit Taskpad View > Tasks tab.
18. New 1 Next > Shell Command > Next.
19. Enter "sol.exe" as the Command (but imagine it is a script/program).
20. Click the black arrow next to Parameters (and ponder a script) > Next.
21. Enter "Create Mailbox" for the task name > Next.
22. Select an icon > Next > Finish > OK.
23. Right-click yellow Users container > View > Customize.
24. Uncheck every checkbox > OK.
25. Make sure the MMC console window is not maximized.
26. Drag the separator bar in the console all the way to the left until it disappears.
i
27. Pull down the Console menu > Options.
28. Pull down console mode list and set "User Mode - Limited Access, Single".
29. Uncheck "Enable context menus..." and "Allow the user to customize.. .".
30. Check the box for "Do not save changes to this console" > OK.
31. Pull down Console menu > Save As > name it "Users.msc".
32. Close console.
SANS Institute
Active Directory 83
33. Right-click Users.msc > select "Run As", or simply double-click the console to run it under
your own user context, You could also select "Author" when you right-click in order to
edit the console again.
ip: If it's difficult to find a place to right-click and bring up the View option, open
the MMC in Author mode and click on the upper-left icon next to the Console menu
and select Customize View there.
In the following screenshot, the Certification Authority snap-in has been enhanced with
different Taskpad Views on each of its subcontainers, hence, the icons on the tab-view
are different for each "yellow folder". In this case, the Policy Settings container is used
to addremove certificate templates from the CA. The custom view helps to simplify
these tasks.
0Revoked Certificates
1 Manage Available Certificate Templates
0Issued Certificates
0 Pending Requests Code Signing, Mrroroft Trust L
Encrypting File System
Code Signing Code Signing
Client Authentication, Server Aut
lent Authentication, Server Aut
Make a certhcate template available for use on this

CA This does not create the template or any A
rerttficates, but it does make it possible to issue
blab Available certificates based on the added temcllate A
Manage Available Certificate
-. " _""
Templates
"I -
Note that a custom script or program could be launched when one of the above icons is
clicked. This enables programmers to easily extend the functionality of the snap-in
because a variety of properties of the highlighted object are passed into the
script/program as command-line arguments. The script or program would need to be
copied to the computer along with the console file.
ip: To run a custom console under the context of a different user, right-click the
console file > Run As > enter the desired username and password. This is a
handy way to check whether AD permissions have been set correctly for the
authority you wish to delegate.
Similarly, the console below greatly simplifies basic user certificate management tasks.
This is the Certificates snap-in, which exists by default on every machine, hence, this
console could simply be copied to a computer or made available in a shared folder.
SANS Institute
84 Active Directory
Manage My Personal Digital Certificates
Bnamn.straicr
~Adni.nistrator
H;arnn!strator
RAd
Administrator
HAdministrator
..
ministrator
<[lone>
EFS Reccvery c e i t
Admin Cert
Code Signing Cert
<None>
<None>
Seccre Emai, Cienr A-rrenr :a[ cn, Smart Ca
F le Recoveiy
Code Sigr ng, M c r ~ s o fTrust
Code Signing
Encrypting File System

t L.sc Signing, Er
Encrypting File System, Secure Email, Client A

a
Administrator Admin Cert Code Signing, Microsoft Trust List Signing, Enc
RAdministrator EFS Recovery Agent Cert File Recovery
Administrator Code Signing Cert Code Signing
RAdministrator Enrollment Cert Certificate Request Agent
.............
Request Import Export View Delete
Certificate Certificate Certificate Certificate iCe~tjf!catej
One last certificate-related tool is the Certificate Services Website. The console below is
actually just a dedicated Internet Explorer which, when opened, always goes to the same
URL: http://server/certsrv/. You can configure it, of course, to go to any fixed URL you
wish. This "tool" could be e-mailed to anyone with Windows and it will work.
" "_ ". . .
You use this web site to request a certificate for your web browser, e-mail
client. or other secure program Once you acquire a certificate, you will be
able to securely identify yourself to other people over the web, sign your e-
mail messages, encrypt your e-mail messages, and more depending upon
the type of certificate you request
Select a task:
r Retrieve the CA certificate or certificate revocation list
C Request a certificate
C Check on a pending certificate
Finally, the following shows the Event Viewer tool with what appears to be extra logs.
The new icons are simply different "views" of the built-in logs which filter what is
displayed. For example, the highlighted log view below only shows failed authentication
attempts in the Security log due to unknown usernames or bad passwords. You can
create as many new log views as you wish, each with its own filter.
SANS Institute
Active Directorv 85
8 Failure Audit 6/1/2002 10:06:28 AM Security

9 Failure Audit 6/1/2002 10:06:26 AM Security
Directory Service a Failure Audit 6/1/2002 10:06:26 AM Security
File ReplicationService
System-Errors Only
System- Errors and Warnings
Securit -Failures On1
It !
In the Administrative Tools folder, right-click on Event Viewer > Author > right-click the
System Log > New Log View > right-click the new icon (System Log (2)) > Rename it to
"System Log - Errors Only" > right-click the new icon again > Properties > Filter tab >
uncheck the Information and Warnings checkboxes > OK. When you close the console,
choose Yes to save, and this new log view will be saved as well.
e s
Group Policy can be used to hide snap-ins from users and to prevent them from editing
their MMCs in "author mode". To see these options in a Group Policy Object, go to User
Configuration > Administrative Templates > Windows Components > Microsoft
Management Console.
3 c.21 Administrative Tetnplates

E 0Windows Components
Id 3 NetMeetiny
Isi 9Internet Explorer
a Extension snap-ins
Group Policy
With these options, you can determine whether or not certain users can:
Open any MMC in author mode.
Execute a particular MMC snap-in.
NOT execute a particular MMC snap-in.
Use a particular snap-in extension.
Use selected snap-in extensions related just to Group Policy editing.
SANS Institute
86 Active Directory
Two ways to do it:

I User Rights
2 AD Permissions
- Limited to I O .
- ms-DS-MachineAccountQuota
- Create computer account.

- Join to domain.
When a Windows computer "joins the domain" it will have a computer account in AD
and will have logged onto the domain at least once. During logon, the computer will
open an RPC NetLogon channel to a DC, use either NTLM or Kerberos to authenticate
itself, and begin to process Group Policy (except for NT).
Joining computers to the domain is a somewhat sensitive operation, so this power should
be delegated only to IT staff (ideally). There are two ways a user or group could have the
power to join a computer to the domain: through user rights or AD permissions.
By default, the Authenticated Users group is permitted to join computers to the domain
because this group has the "Add Workstations To Domain" user right. However, because
of the potential for abuse, Microsoft has limited the maximum number of computers a
non-administrative user can join to ten (10). Hence, a regular user may receive the
following error message when joining his or her eleventh computer (Isl325 1335):
ERROR: Your computer could not be joined to the domain. You have
exceeded the maximum number of computer accounts you are allowed
to create in this domain. Contact your system administrator to
have this limit reset or increased.
You can change the default joining quota by setting an AD value named "ms-DS-
MachineAccountQuota" to the new quota number (up to two billion). This can be done
with a script (ADSI__Allow__More__Workstations.vbs) or by hand with the ADSI Edit tool.
SANS Institute
Active Directorv 87
it !
To manually increase the quota of computers a regular user can join to the domain, open
the AD Users and Computers snap-in > right-click your domain > Properties > Attribute
Editor tab > select "ms-DS-MachineAccountQuota"> Edit.
However, for security reasons, non-administrative users should generally not be

permitted to add any computers to the domain. Hence, set the above quota to zero (0)
and instead delegate this authority as you desire through AD permissions.
When a computer is joined with one's "Add Workstations To Domain" user right, the
relevant AD permissions are simply ignored. This is one of the best examples of how
rights can trump NTFS/AD permissions.
Even without the "Add Worltstations To Domain" right, however, it is still possible to be
able to create computer accounts and to join those computers to the domain. Note that
those are two separate tasks (create computer account, join that computer to the domain)
and they require different permissions.
To create a computer account, one only requires the inherited "Create Computer Objects"
permission on the OU where the computer account will be created. There is a
corresponding "Delete Computer Objects" permission as well.
SANS Institute
88 Active Directory
To give a group the power to add computer accounts to an OU, right-click on that OU in
the "AD Users and Computers" snap-in > Properties > Security tab > Advanced button >
Add > select the group from the list > OK > set the Apply Onto list to "This object and all
descendant objects" > scroll down and check the box for "Allow: Create Computer
Objects" > OK > OK > OK.
Delete account ob&

create app4icabonVersionobjects 0 0
Deleteapplrcabonliereionobjects
Create Computer objects
DeleteComputer objects
Create Contact objects
DeleteContact objects
Create dowent objei-cts
Ddete dowment objects
create docuumendwles oblects 0
Let's exercise this permission and create a computer account. When we do so, we'll see
how it is a different set of permissions to be able to actually join the computer to the
domain with this computer account. In the dialog box for creating the account we will
select which user/group can join this account to the domain; this account/group can be
one's own, i.e., the user currently adding the computer account, but it does not have to be.
To add a computer account to an OU, right-click that OU in the "AD Users and
Computers" snap-in > New > Computer > enter the computer name > click Change >
select the user or group permitted to actually join this computer to the domain > OK >
Next > Next > Finish.
SANS Institute
Active Directory 89
This ability is handy. Imagine a user calling the help desk to request a new computer
account; the help desk pre-creates the account and gives just that one user the permission
to join the computer to the domain. Alternatively, a certain non-administrative user or
group could be given the blanket permission to add computer accounts to an OU; when
they add these accounts, the user/group could simply give themselves the permission to
join the computers to the domain.
Note: If you wish to change the default AD container for new users and
computers, see KB324949 for instructions.
ornain
Since the permissions to create a computer account are different from those required to
join a computer to the domain, what permissions are required to join a computer to the
domain with a pre-existing computer account? This is easy to determine because we
need only examine the permissions added to the computer account itself when it is
created and a specific user is allowed to join it.
The minimum permissions one requires on a computer account in order to join a machine
to the domain with that account are the following:
Properties: This Object Only: Write Account Restrictions
Object: This Object Only: Validated Write To Service Principal Name
Object: This Object Only: Validated Write To DNS Host Name
Object: This Object Only: Reset Password
Additional permissions may be set automatically depending on where the computer

account is created, who created it, with what tool (e.g., script or snap-in), etc., but the
above are the minimum permissions for joining.
SANS Institute
90 Active Directory
After migrating to Active Directory, your old Windows NT 4.0 resource domains will
most likely become OUs, and those resource domain administrators will become OU
administrators instead-- a politically-charged demotion they will almost certainly resent.
But the resentment can be mitigated if they can be shown that they are, in fact, losing
very little power. This is the case because all of the users and computers they had control
over before, they still control.
It is possible to create an "OU Admins" global group and give it administrative power
over all the users and computers in an OU. This group can create, delete, and modify all
the user accounts, computer accounts, and groups in their OU. This OU Admins global
group can also be automatically added to the local Administrators group on every
computer in that OU, just as the Domain Admins group was automatically added. And
because OU Admins will manage Group Policy for their OU, their work will be
simplified because they will gain even more power over these users and computers than
they had using Windows NT (emphasize this to mitigate the resentment).
What an OU Admin loses is the power to change domain-wide settings, such as

password/lockout policies, Kerberos policies, and trust links. But that doesn't mean they
can't politically have a say in how these things are determined (once again, the authority
vs. power distinction) and it's not like these settings are reconfigured on a daily basis
anyway. Politically, there should be a committee which jointly agrees upon domain-wide
settings, then the CIOKTO will actually make the change. In fact, if there were a
SANS Institute
Active Directorv 91
number of Domain Admins under Windows NT they had to agree upon domain-wide
settings in committee anyway in order to avoid chaos.
ele S: er
To delegate authority over an OU, perform the following as a Domain Admin:
I. Create a new global security group that will be granted power over the OU. Place
that group in the OU it will control. For example, if the name of the OU is
"Boston", then create a "Boston-OU-Admins" group in the Boston OU. We will
refer to it just as the "OU Admins" group below.
2. Give the OU Admins group Full Control to the OU with the "Apply Onto: This
Object and All Descendant Objects" inheritance setting on both the Object and
Properties tabs of the Advanced ACL property sheet. Ensure that all sub-OUs are
inheriting from this parent OU.
3. If the domain is in native mode, add the OU Admins global security group to the
"Group Policy Creator Owners" global security group (that's why you have to be
in native mode). This allows OU Admins to create Group Policy Objects. If the
domain is in mixed mode, you will either have to add the desired individual user
accounts to the Group Policy Creator Owners group, or a Domain Admin can
create one or more Group Policy Objects and give the OU Admins group Full
Control over it. Because the OU Admins group already has Full Control over
their OU, they can link whatever Group Policy Objects they want to it.
4. Have an OU Admin create a Group Policy Object and link it to their OU. Using
the "Restricted Groups" feature of Group Policy, add the OU Admins group to the
local Administrators group on every computer in the OU.
ote: The steps involving Group Policy will be discussed tomorrow.
S
When creating an OU Admins group and delegating authority to it, there are a few issues
to keep in mind during your planning:
Where will the OU Admins group itself be located in AD? If you want the
current members of that group to have control over it, then place the group in the
OU over which the group itself has authority. If you want centralized control
over its membership, then place the group in a different OU controlled by the
central IT staff. Keep in mind, however, that if OU Admins control Group Policy
in their OU, they can add whoever they like to the local Administrators group on
computers in their OU. Hence, it will likely be the case that either 1) the OU
Adinins group controls both their Group Policy and its own group membership, or
2) the OU Admins group will control neither their Group Policy nor their own
membership.
SANS Institute
92 Active Directory
The same question is valid for the user accounts in the OU Admins group?
Where are they in AD? Who has control over them? If the OU Admins group
will be controlled by a central IT authority, then perhaps central IT would like to
have exclusive control over the user accounts in it too.
Do you want to allow the OU Admins group to manage the Group Policy Objects
linked to its OU? Group Policy is somewhat complex, so not all OU Admins
groups will be able to manage it. Because of the importance of Group Policy for
security, moreover, central IT might want to retain control over Group Policy
itself. This will become a sore political topic, so watch out.
SANS Institute
Active Directorv 93
- Authorize DHCP servers.

- EA group will still control
all sites, intersite links and
connection objects - but
maybe that’s a good thing!
Delegation of authority doesn’t always mean that a group is getting more power.
Sometimes it means a built-in group will have its power curtailed.
In a multi-domain forest, the Enterprise Admins (EA) group only exists in the root
domain. The EA group is automatically added to the local Administrators groups on all
the DCs in all the subdomains in the forest. The EA group is also given some special
permissions in AD (see below). The intent is to give the EA group power over
everything, directly or indirectly, in the entire forest.
For political or security reasons, however, the vast power of the EA group may be
unacceptable to you or to some of the divisions within your organization. Fortunately,
the delegation model AD provides makes it possible to remove the power of the EA
group over any or all of the subdomains in the forest. Later, if you regret having made
this choice, you can easily go back. The steps for limiting the power of the EA group are
configured on a per-subdomain basis, hence, it is not the case that either the EA group
has control over all subdomains or none.
Moreover, note that a Domain Admin in a subdomain can remove the power of the EA
group unilaterally. The procedures below do not require the consent or approval of the
EA group.
SANS Institute
94 Active Directory
Note: An interesting Lucent whitepaper by James Barrett, "Windows 2000

Active Directory Design: Restricting the Enterprise Administrators Group",
describes the procedures listed below (www.lucent.com).
Warning! These measures are not supported by Microsoft. If they cause

problems, Microsoft is not obligated to give you assistance. If problems occur,
reverse the steps and reapply the permissions removed.
acks To Limiting T er of Enterprise ins

If you limit the power of the EA group over a subdomain, there are a few drawbacks to
be aware of
Subdomains of the subdomain to be secured from the EA group (sub-subdomains)

cannot be added or removed without restoring the EA group's default
permissions. But the necessary permissions for addinghemoving these sub-
subdomains can be added temporarily and the removed afterwards. Adding sub-
sub-domains will also probably be a very rare occurrence.
After securing the subdomain from the EA group, EA group members will no
longer be able to authorize DHCP servers. However, if the EA group or the
Domain Admins group from the root domain is added to the DHCP Users group
in the subdomain, then either of these root-domain-level groups will be able to
authorize DHCP servers. Adding the Domain Admins group from the subdomain
to the DHCP Users group there is insufficient. The ability to authorize DHCP
servers is probably not an issue that political feathers will get ruffled about.
The EA group has Full Control over the Configuration NC and everything
underneath it, including all the sites, subnets and connection objects. It is not
recommended that you remove these permissions, hence, the EA group will still
be able to manage replication (and many other forest-wide settings). However,
additional permissions can be added to those already there to allow custom groups
in one or more of the subdomains to manage this data. This, however, is precisely
the sort of anarchy the EA group was intended to prevent, so beware!
dmins Over
Follow the steps below to remove the power of the root domain's Enterprise Admins
group over a single subdomain in the forest:
1. Remove the EA group from the local Administrators group on the DCs in the
subdomain to be protected.
2. Remove all permissions assigned to the EA group on the subdomain container

itself. This means right-clicking on the name of the subdomain in the "AD Users
and Computers" MMC snap-in > Properties > Security tab > highlight the EA
group > Remove > OK.
SANS Institute
Active Directorv 95
3. Remove all permissions assigned to the EA group on the built-in domain local
Administrator account in the subdomain.
4. Change the permissions on the \SystemMdminSDHolder container in AD so that

the Enterprise Admins group, if present on the ACL, only has Read access, not
h l l control, to it.
Every 60 minutes the PDC Emulator in the subdomain will compare the permissions on
the users in the Administrators, Domain Admins, Schema Admins and Enterprise Admins
groups against the permissions on the \SystemMdminSDHolder container in AD. If they
differ, the ACLs on these users will be changed to match the ACL on the
AdminSDHolder container (Kl3232 199, Kl33 18180). Whatever permissions the
Enterprise Admins have on the AdminSDHolder container, therefore, will be the
permissions on the Administrator account within one hour. That is why the
AdminSDHolder ACL must be changed too.
Also keep in mind that the root-domain-only Schema Admins group can modify the
permissions on classes in the Schema. Hence, any new objects based on those classes
will inherit those new permissions. Malicious Schema Admins members might grant
themselves or the EA group Full Control on a variety of object types (users, computers,
groups, etc.) in an attempt to reassert their lost power.
However, 1) this will not affect the permissions on objects that already exist, and 2) such
ACL changes on the classes in the Schema would be easily and immediately detectable
because the Schema is replicated forest-wide. A script or IDS could alert subdomain
administrators to all changes.
And, besides, if political tensions are really that bad --if "malicious Schema Admins"
group members are to be feared-- then perhaps the subdomains would be better off as
separate stand-alone forests anyway.
SANS Institute
96 Active Directorv
Enable the audit policy:
- Unlike NTFS SACLs,

many are built-in
from the factory.
A phenomenal amount of data can be logged when auditing access to AD. The same
level of detail and flexibility available when configuring AD permissions is also available
for auditing. Every property of every object could be separately audited.
Audit data appear as items in the Event Viewer Security log on each DC separately,
hence, custom scripts or add-on tools are required to remotely extract, centrally
consolidate, and intelligently analyze this log data.
AD auditing must be enabled before any data appear in Event Viewer. It is disabled by
default prior to Windows Server 2003 R2. After it is enabled, the system access control
lists (SACLs) on objects and containers in AD can be customized to fine-tune exactly
which actions will be logged.
S itin
AD auditing on domain controllers is enabled through Group Policy. Keep in mind that
this is auditing as determined by the System Access Control Lists (SACLs) on the
individual AD objects and containers configured for auditing, it is not a general auditing
policy which is simply switched on, such as logodlogoff auditing.
To enable AD SACL auditing, open the "AD Users and Computers" MMC snap-in > right-
click on the Domain Controllers OU > Properties > Group Policy tab > highlight the
Default Domain Controllers Policy > Edit > Computer Configuration > Windows Settings >
Security Settings > Local Policies > Audit Policy > double-click "Audit directory service
SANS Institute
Active Directory 97
access" > check all three boxes, including Success and Failure > OK > close Group
Policy window > OK.
ec er S
Unlike NTFS SACLs, which must all be configured by hand, Active Directory installs
with an extensive set of default SACLs. The default audit settings for an object are --just
like default permissions-- defined by the schema and the container into which the object
is placed. Access to the Schema itself by the Everyone group is almost 100% audited.
For most object types the default SACL tracks all modifications to the object, but no
readlist access to it. Hence, simply enabling "Audit Directory Service Access" will
immediately cause audit data to be generated for almost all AD changes without the
administrator being required to configure any AD SACLs by hand first.
However, to modify an AD SACL, simply edit the ACL just as you would for AD DACL
permissions. Don't forget to "View > Advanced Settings" to see the Security tab!
0 0
El El
El El
All Validated Writes El El
All Extended Rights El El
Create All Child Oblects E l E l
Delete All Child Oblects E l m
Change Scherna Master El El
Manage Replication Topology El El
Replicating Directory Changes El El
Replication Synchronization El El
Update Schema Cache El El
!
To modify the audit settings on an AD object, right-click the object > Properties > Security
tab > Advanced button > Auditing tab > select Add, Remove or View/Edit as needed.
ic
However, AD access can be indirectly audited through other audit policies found in the
above Group Policy Object. If direct auditing occurs in virtue of SACLs on particular
AD objects, indirect auditing occurs when certain types of actions occur on the domain
controller, such as adding a user to a group or changing password policy. These actions
result in AD modifications, hence, they also fall under the rubric of AD auditing.
SANS Institute
98 Active Directorv
_ . ....
) ~ ... - . .. ... . _...........
_ ... ^ .."
--
Account Policies @Audit account logon events Success, Failure

@Audit account management Success, Failure
@Audit directory service access Success, Failure
@Audit logon events Success, Failure
@Audit object access Failure
@Audit policy change Failure
m k u d i t privilege use Failure
Registry @Audit process tracking Not defined
File System Audit system events Success, Failure
Here are the different audit policies directly relevant to AD auditing, the others will be
discussed in the Group Policy seminar:
Audit Account Logon Events (Success, Failure)-- This tracks authentication

requests processed by the domain controllers even when the access is not to the
domain controller itself. These authentication requests are sent by users'
machines when a user logs on locally at those desktops, and by servers when a
client logs on remotely to those servers, e.g., when a user maps a drive letter to a
server's shared folder. Think of DCs as providing a service for the sake of other
machines on the network (checking usernames and passwords) and this category
logs whenever that service is provided. When this policy is enabled on the
workstations and servers themselves, then it applies only to the local accounts on
those machines, hence, it only applies to authenticated access to those machines.
Strictly speaking, this audit policy logs information at the machine where the
account in use is physically stored, i.e., either in the global AD database on a DC
or in the local SAM database on a member server.
Audit Account Management (Success, Failure)-- This monitors user and group
tasks such as account creation, deletion, modification, and group membership
changes. Note that only the bare fact that an account or group has been modified
will be logged through this policy, not the detailed data made available with
"Audit Directory Service Access".
Audit Directory Service Access (Success, Failure)-- This is required to begin

logging access to AD objects as defined on those objects' individual SACLs. By
analogy, NTFS SACLs also do not cause data to be written to the Event Log
unless the "Audit Object Access" policy is enabled.
Audit Logon Events (Success, Failure)-- This tracks interactive and over-the- i
network logons to the target computer itself. Strictly speaking, it logs information
on the machine where the Security Access Token (SAT) is created for the local or
remote user that is performing the logon, but the SIDs for that SAT do not all
SANS Institute
Active Directory 99
have to come from the target computer itself: the global SIDs will come from a
DC and the local SIDs will come from the target machine, but the target machine
is still the location where the SAT is created.
bject Access (Success, Failure)-- This is required to begin logging access

to NTFS folders and files, registry keys, and shared printers. It is not the case that
enabling this category will cause all filesystem, registry and printer access to be
logged. Rather, enabling the category makes it possible to have the audit ACLs
(the System Access Control Lists) on those objects not do nothing. It takes two
changes to audit access to a file, for example; this category must be enabled and
that particular file must be configured to audit some kind of access to it.
olicy Change (Success, Failure)-- Tracks changes to the audit policies

themselves, and changes to user rights assignments.
se (Not Defined)-- Monitors the exercise of the various user

rights on the machine, e.g., take ownership, change system time, etc. Enable this
policy on an as-needed basis only to avoid filling the logs.
rocess Tracking (Not Defined)-- This is rarely enabled, and usually only
y programmers who are debugging their own code. This category tracks
program execution, process loading and unloading, filesystem handle creation and
release, indirect object access, and other low-level OS behaviors. Enabling this
category will cause a vast amount of extra log data and will slow the system down
considerably.
vents (Success, Failure)-- Tracks system startup, shutdown, and

other system-wide events. This also records clearing of the System and Security
logs.
s!
If there are only a few dozen objects or properties that you really care to monitor, then
strongly consider simply writing your own ADS1 scripts to do it automatically. By
programming standards, scripting access to AD --especially the read-only access being
contemplated here-- is fairly easy. A scheduled script could check a variety of settings
and properties every 15 minutes and, if something has changed, the script would alert
administrators through e-mail messages, pop-up alerts, numeric pages on their
cellphones/beepers, etc.
We will discuss the components of such scripts during the scripting day of the week.
SANS Institute
100 Active Directory
- Logs non-default values added during the creation of
- Logs previous and new location when objects are

moved or undeteted.
Prior to Windows Server 2008, auditing in AD could tell you who made a change to
which attribute, but the event logs wouldn't tell you what the attribute was both before
and after the change, hence, you knew which attribute was changed, you knew what the
new (current) value is, but you didn't know what the prior setting was. These leaves an
important gap in our auditing and forensics work, and makes it more difficult to reverse-
out malicious or accidental changes to the directory.
Starting with Server 2008, though, you can log both the old and new values of a changed
attribute, as well as track more precisely move, create and undelete operations. These
changes appear in the Security event log with ID numbers 5 136 (modify), 5 137 (create),
5138 (undelete) and 5139 (move).
In a security template or Group Policy, enabling the "Audit Directory Service Access"
audit policy category will enable change auditing on Windows Server 2008 and later.
0L.E
Starting with Windows Vista, the various audit categories have been broken into
subcategories which can be enableddisabled independently of each other. You cannot
manage these subcategories individually through Group Policy except by pushing out a
script which runs AUDITPOL.EXE. This binary is the only way in both Vista and Server
2008 to view and manage these subcategories separately from each other. However,
when you enable the "Audit Directory Service Access" audit category in Server 2008 and
later, all the subcategories under it are enabled by default too.
SANS institute r
Active Directorv 101
To see your current audit policies, including the subcategories, open a command shell
with elevated privileges and run "auditpol.exe /get /category:*".
System audit policy

Category/Subcategory Setting
System
Security System Extension No Auditing
System Integrity Success and Failure
IPsec Driuer No Auditing
Other System Euents No Fluditing
Security State Change Success
Logon/Logoff
Logon Success and Failure
Logoff Success and Failure
Account Lockout Success and Failure
IPsec Main Mode No Fluditing
IPsec Quick Mode No Auditing
IPsec Extended Mode No Auditing
Special Logon Success and Failure
Other Logon/Logoff Euents Success and Failure
Object Access
File System No Auditing
Registry No Auditing
Kernel Object No Fluditing
SQM No Auditing
Certification Services No Auditing
Flpplication Generated No Auditing
Handle Manipulation No Auditing
File Share No Auditina
11 Filtering Platform Packet Drop

Filterina Platform Connection
No
No
Auditin;
Auditina
On a Server 2008 and later domain controller, to see just the AD-related audit
subcategories, run "auditpoLexe /get /category :"DS Access"."
:\> audit po 1. exe /yet /cat ega1.y :"DS ftccess "

v s t e m audit u o l i c v
at
st e gor y / S ubc e y a i*y Setting
S ftccess
Directory Seru i c e Ghanyes Success and Failure
Direct o 1.y S eru i c e Re p l i c a t ion Success and Failure
Detailed Directory Service Replication Success and Failure
D iPec t o ry S e ~v i c e FI c c e s s Success and Failure
......
I
4. . .
~
. . . . . . . . - .. . __ -
-. -.. .- .I
.........
..- .
. . . . . . . . . . . .
b
.
. ;
I
~,
The audit subcategory which captures pre- and post-change attribute values is named
"Directory Service Changes". This, and all the other subcategories, are enabled when the
"DS Access" parent category is enabled. In a security template or Group Policy, this
parent audit category is named "Audit Directory Service Access".
SANS Institute
The following is a list of best practices for auditing AD:
To save disk space and optimize performance, only collect the audit data which
will be useful to you. At a minimurn, audit the Account Logon Events, Account
Management, and Policy Change categories (successhl and failed). In medium-
to high-security environments, also audit the Directory Service Access category
(successful and failed). With Windows Serve 2008 and later, if you need to keep
the Security log small, you can selectively disable the "Directory Service
Changes" audit subcategory with AUDITPOL.EXE, but keep this enabled
otherwise.
On controllers prior to Server 2008, increase the size of the security log to no
larger than 300MB; this low limit is due to a known bug which can events to be
dropped if the log grows larger than 300NIB (KB 183097). On Windows Server
2008 and later, there is no such artificial limit, so change the size of the log to
2GB or larger.
Set the retention method on the security log to "Overwrite events by days", and
only overwrite events after they have been saved twice during normal backup.
For example, if you make a full backup every seven days, set the security log to
only overwrite events older than 15 days. If you backup the logs each night, then
only overwrite events older than three days.
If you enable "Audit Directory Service Access" and you customize the SACLs on
AD objects, ensure to at least audit all failed and successful attempts to modify
any of the following by the Everyone group:
Enterprise Admins group,
Schema Admins group,
Domain Admins group,
Group Policy Creator Owners group,
Pre-Windows 2000 Compatible Access group,
Cert Publishers group,
Domain Controllers group,
DnsAdmins group,
all user/computer accounts which are members of any of the above,
any other users/groups which are likely targets of attack.
Consider investing in a host-based IDS which is capable of scanning for AD

changes. At a minimum, the IDS should be capable of searching for user-
definable events in the logs in near real-time. Barring a full IDS, consider writing f
your own scripts to do the same.
SANS Institute
Active Directory 103
In the next few sections we will discuss forest design. This encompasses the number of
domains to have, the number and types of trusts, inter-domain replication, and special
forest designs like the "empty root forest".
SANS Institute
Your forest design is your set of answers to the following questions:
How many forests do we have?

How many domains do we have in each forest?
What are the trust relationships among all our domains?
Do we have an extranet forest? How is it firewalled?
Do we have an empty root domain? Why?
Do we allow direct RADIUS or LDAP authentication instead of using trusts?
Do we enforce selective authentication limits on our cross-forest trusts?
Do we have many stand-alone computers because we can't (or don't want to) put
them in forests? Where are they? How are they managed?
How you assemble your forests, domains and trust links can have a big impact on your
overall security. Yet such issues are rarely discussed from a security point of view, they
are usually discussed in the context of administration, e.g., the AD preferences of the
Exchange Servers, slow WAN links, the size of the user base, etc. The security issues are
complex and many of the security consultants we hire frankly just don't know much
about Active Directory. In this section, then, we're going to talk about forest design
strictly from a security point of view.
Trust Types
Windows NT 4.0 only had one type of trust link available. Windows Server 2003 and
later, on the other hand, has five:
SANS Institute
External
Intra-Forest
Cross-Forest
Shortcut
Kerberos Realm
Shortcut trusts are discussed in an appendix because they don't affect security, they only
change the speed of Kerberos referrals. Kerberos Realm trusts are also covered in an
appendix, along with general coverage of Kerberos internals, because they're only for
links to non-Windows Kerberos realms, often implemented on Unix/Linux. The three
trust types that concern us are the External, Intra-Forest and Cross-Forest trusts, which
will be covered momentarily.
There are three forest design scenarios you'll likely face, and we'll discuss each of these
scenarios separately to work through the issues together:
Cross-forest trust with a partner company ("federated forests").
Empty root doinain forests.
Extranet forests.
The questions and principles discussed, though, will aid in your planning of any forest for
many different purposes.
When considering trust and forest designs, here are the main issues and threats which
often determine the best approach to take (these are the pivotal topics):
The existence and direction of a trust link affects where users can log on and to
which resources they can be granted access. If the absence of a trust prevents you
from logging on at a workstation or server, either locally or across the network,
then you cannot be assigned any privileges or permissions on that computer. This
isn't always bad. Remember that direction of trust is the opposite direction of
access to resources (e.g., if I trust you, you can ride my motorcycle, but if I
declare that I trust you, this doesn't give me access to your swimming pool).
The type and direction of a trust link determines which authentication protocol(s)
can be used, such as NTLM, Kerberos and/or EAP-TLS. Some are more secure
than others, some have better backwards compatibility, and some have unique
features which others lack, e.g., Kerberos delegation of identity.
RADIUS, LDAP and certificate-based authentication can be configured to more-

or-less implement a trust link between a server that supports these features (IIS,
ISA Server, VPN, wireless, RRAS, dial-up, etc.) and a forest containing the users
who need to access the server. Hence, it is not always the case that a server must
be a domain inember in order to authenticate users with their global accounts.
SANS institute
106 Active Directorv
The type of a trust link determines whether Active Directory data is replicated
between the domains in the trusting relationship. No trust at all means no shared
global catalog, no shared schema and two separate configuration naming contexts
(with sites, subnets, etc.). But some trusts support NTLM and Kerberos, yet their
existence doesn't include AD replication.
Different authentication protocols and replication features means different rules in

any firewall designed to regulate this traffic. The firewall-friendliness of these
protocols can make or break an Active Directory deployment for an extranet
forest or for public servers in the DMZ.
Let's begin by discussing trust relationships, the links which connect domains and forests
together into units, then consider various forest design scenarios.
SANS institute
Active Directory domains can participate in different types of trusts. One of these trust
types is the traditional Windows NT-style trust, which, in Active Directory, is called an
"external trust".
External trusts have the following characteristics:
Must be created manually by an administrator.
Are one-way, but two one-way trusts can be created when needed.
Are intransitive, so there is no "pass through" of trust. Unlike a cross-forest trust,

an external trust between two domains in two forests is a trust between those two
domains only.
Do not imply any replication of any data between the domains, hence, if two
domains only have an external trust between them, there is no database
replication. Normally two AD domains will replicate a common Global Catalog,
Schema and Configuration NC with each other, but not when there are only
external trusts between them, and it doesn't matter what the DNS names of the
AD domains are either. Said another way, you cannot have merely an external
trust between two domains in the same forest.
SANS Institute
Can be created between an AD domain and another AD domain, or between an

AD domain and a Windows NT 4.0 domain. This is true in both native and mixed
mode. If both domains are AD, they can each be part of a forest, but not the same
forest, and it does not matter if the domains are root domains or subdomains.
Employs NTLM pass-through authentication. Kerberos isn't supported.
Windows NT 4.0 domains only support external trusts. So if you want your AD
domain to trust (or be trusted by) an NT domain, you must use an external trust.
o Crea Trust
An external trust is created manually with the AD Domains and Trusts snap-in. Other
trust types are created with this snap-in too. In the properties of the domain object, go to
the Trusts tab and launch the New Trust wizard.
To manually create an external trust to an external domain, open "AD Domains and
Trusts", right-click the local domain > Properties > Trusts tab > New Trust button. This
will launch a wizard that will ask you a series of questions and establish the desired
trust(s) for you.
External trusts to NT domains are useful during the migration process to AD. A two-way
trust with the old NT domain can make users' transition to the new AD domain more
smooth because, no matter what, they can always log on with their old account to access
resources, and usually these resources are available to them anyway if their new AD
accounts were created using the "SID history" feature.
External trusts are useful when the users and computers of another AD domain are being
assimilated into one's own. Assimilation is not the ''joining" of domains (discussed
,
SANS Institute
below), but the creation of replacement accounts in one's domain for the users and
computers in the domain being assimilated. Once all the replacement accounts have been
created and all resources migrated over, the other domain is simply destroyed. Until
then, though, two-way external trusts can ease the process.
If two Windows 2000 AD domains are in different forests, only an external trust can link
them. Windows Server 2003 and later also provides a special kind of trust called a
"cross-forest trust" for this, but only when both forests are at the Windows 2003 forest
functional level or better.
SANS Institute
Transitive Trusts:
- Created automatically.
- Kerberos authentication.
- Transitive.
- AD replication of the - Download copy of Schema.
Schema, Configuration NC
and Global Catalog.
- NT cannot participate.
- Transitive trust with the
Inter-domain replication of directory data did not exist under Windows NT. This is new
to Active Directory. When two domains replicate AD data between them, they must have
a "transitive trust". This type of trust is sometimes called a "Kerberos trust" or "forest
trust", but you must take care to distinguish this type of trust with cross-forest trusts
(discussed later) and pure Kerberos realm trusts (discussed in an appendix).
Transitive trusts have the following characteristics:
They are created automatically when installing the domain.
Authenticated with Kerberos via an exchange of inter-domain trust keys.
They are two-way by default.
They must be transitive.
They imply that database replication is occurring between the domains. There is a
shared Schema, Configuration NC, and Global Catalog.
Windows NT domains cannot participate in transitive trusts.
SANS Institute
The first AD domain you install is special. This is your "Windows root domain" (which
should not be confused with ".", the DNS root domain). It is the founding domain, the
one that sets the original Schema and Configuration NC which all other domains must
copy if they are to join it. Because of this, your Windows root domain cannot be
removed and it cannot be joined to any other previously existing domains or forests.
rise
Your root domain will be the only domain which has the built-in Enterprise Admins and
Schema Admins groups. Subdomains which join the root will simply not have these
groups. Only members of the Schema Admins group can modify the schema. The
Enterprise Admins group is added to the local Administrators group of every domain
controller of every subdomain that joins the root domain. Both are global groups in
mixed mode, and universal groups in native mode.
res
Only someone who knows the credentials of an account in the Enterprise Admi
can use DCPROMO.EXE to join a new subdomain to the forest. What does "join the
forest" mean?
There is a deceptively simple question in the DCPROMO Wizard: "DOyou want to

create a new forest or join an existing forest?" If you join a domain to an existing forest,
then:
Your new domain will not create its own Schema and Configuration NC, but
instead copy these from its parent domain in the forest.
There will be a single replicated Global Catalog between the forest and the joined
domain.
SANS Institute
A two-way transitive Kerberos-based trust will be established between the joined

domain and its immediate parent in the DNS hierarchy.
The Enterprise Admins group from the root domain will be added to the
Administrators group on the domain controllers (and just the domain controllers)
in the joined domain.
eplicafion Boundaries, ot Security Boundaries

If the Schema, Configuration NC and Global Catalog are replicated among joined
domains, then what is left over to not be replicated? The Global Catalog is about 55% of
the AD database measured in megabytes, hence, about 45% of Active Directory is not
replicated between domains. Hence, domains are replication boundaries, and a valid
reason for creating multiple domains is to control replication traffic (more on this later).
hat Exactly Is The Difference Bet "Forest" And

A "tree" is two or more domains where the DNS names of the domains are in a
hierarchical, parent-child relationship. For example, t'corp.microsoft.comttis a
subdomain of ttmicrosoft.comtt,and together they form a simple tree.
All the domains in the tree share a contiguous DNS namespace then. They also share a
common Schema, Configuration, and Global Catalog in that these data are replicated
between all domain controllers in the entire tree because these domains are part of a
single forest.
A "forest" is one or more domains joined with two-way transitive trusts, sharing a single
Schema, Configuration NC and Global Catalog. For example, "rnicrosoft.com" and
"sans.org" could be combined into a forest, but not a single tree, because they are not in a
DNS parent-child relationship. Nonetheless, one could still be the AD root and the other
would still trust and replicate with it. A forest need not have a common DNS root
domain (except "." of course) but it will have a single AD root domain. The first domain
installed in the forest will be the AD root domain. Again, what makes a forest is not the
names of the domains, but whether they share a single Schema, Configuration NC and
Global Catalog, and are linked by two-way transitive trusts.
Now, some people will say that a single domain is a tree by itself and also a forest, but
this author prefers to let such semantic debates rest on ice. It is much more helpful to get
the answers to these questions and be done with it:
How many domains do we have?
What are their DNS and NetBIOS names?
What kinds of trusts are there?
What data are they replicating? i
If you have the answers to these questions, you have everything you need to understand
the environment even if the definitions of the terms "tree" and "forest" are still unclear.
SANS Institute
- Creates one enormous complete trust model!

- But no multi-forest transitivity, each cross-forest trust is separate.
A new type of trust available only with Windows Server 2003 and later is the “cross-
forest” trust. This is sometimes called a “forest trust”, but take care to distinguish intra-
forest trusts and the inter-forest trusts being discussed here.
The purpose of a cross-forest trust is to transitivity link all the domains in two separate
Windows forests with trust links just as though they were just two trees in the same
forest. But there is an important difference between two trees in a single forest and two
forests with a cross-forest trust: all domains and domain controllers in a single forest
replicate Active Directory with each other, but a cross-forest trust does not entail any
cross-forest replication whatsoever.
Cross-forest trusts have the following characteristics:
Available only when all the domain controllers in all the domains in the two
forests are running Windows Server 2003 or later.
Available only when all the domains in the two forests are running at the
Windows Server 2003 domain hnctional level or better.
Available only when the two forests are running at the Windows Server 2003
forest functional level or better.
SANS Institute
Can be one-way or two-way, your choice.
Must be transitive, but this transitivity extends only to the domains in the two
forests with the trust and not to any further forests trusted by one of the forests at
hand; that is to say, if forest A has a cross-forest trust with forest B, and forest B
has a similar trust with forest C, it does not follow that forest A has some kind of
"transitive cross-forest trust" with C; if forest A wishes to trust forest C, or vice
versa, then A and C must establish their own separate cross-forest trust.
Is created only between the root domains of the two forests.
Does not include or imply cross-forest replication of the Schema, Configuration

NC, or any other Active Directory data.
Both NTLM and Kerberos authentication methods are available for authenticating
across domains in the forests. NTLM cannot be disabled.
Kerberos ticket delegation does not work across forests. This is when you mark a
server as "trusted for delegation", but it's only trusted within its own forest.
SID filtering is enabled automatically. This prevents evil Enterprise Admins in

the other forest from adding SID numbers to the credential information they
return which are actually SID numbers for groups in your forest.
The "Selective Authentication" feature is available, but not enabled by default. If

enabled, this forces administrators in the trusting forest to explicitly grant the
"Allowed To Authenticate" permission on computer accounts in the trusting forest
in order to grant permissions to users or groups in the trusted forest who need to
get access to that computer.
DNS servers in both forests must either share a common DNS narnespace, or,
more likely, be configured to use "conditional forwarding" to forward queries
related to the other forest's domain(s) to the DNS servers in the other forest.
Cross-Forest Trust
A cross-forest trust is created using the Active Directory Domains and Trusts snap-in,
just like the other trusts. The New Trust wizard will ask the appropriate questions and
walk you through the process.
irectory "Functio na I
Just as Windows 2000 domains can run in either mixed or native mode, so Windows *
Server 2003/2008 domains can run at different 'Yhctional levels" too. Higher levels
enable more functionality, but at the price of backwards compatibility with earlier
versions of Active Directory. These are the available domain functional levels:
SANS Institute
evel. This is the same as mixed

mode in Windows 2000. Domain controllers can be Windows NT 4.0, Windows
2000 or Windows Server 2003. This is the default level.
unctional Level. This is the same as native

mode in Windows 2000. Domain controllers can be Windows 2000 or Windows
Server 2003.
indows Server 2003 unctional Level. This is unique to Windows

Server 2003 and later. The only permitted domain controllers are those running
Windows Server 2003 or later. Many features unique to Windows Server 2003,
such as domain controller renaming, are available only in this level.
indows Server 2008 evel. This is unique to Windows

Server 2008 and later. All domain controllers must be running Windows Server
2008 or later.
Once a domain's functional level has been advanced, it cannot be rolled back and no
domain controller can be added unless its operating system meets the version
requirements above. To raise a domain's functional level, use the Active Directory
Domains and Trusts MMC snap-in.
To raise the functional level of a domain, open the Active Directory Domains and Trusts
MMC snap-in > right-click the domain > Raise Domain Functional Level.
In a multi-domain forest, each domain's functional level can be configured separately

from the others. It is not the case that every domain in the forest must be at the same
functional level, unless the forest functional level has been upgraded too.
In addition to the domain functional levels, there are also multiple forest functional
levels. A forest functional level determines what features are enabled in all domains
throughout the entire forest. The forest functional levels are:
QWS Server 20 evel. This exists only for

the sake of upgrading from Windows NT to Windows Server 2003. Windows
2000 domain controllers are not permitted. This level is only made available
when upgrading the operating system of a Windows NT 4.0 domain controller to
Windows Server 2003. Once all controllers have been upgraded, you can upgrade
the domain functional level and then the forest functional level.
evel. Supported domain controllers are

Windows NT, Windows 2000 and Windows Server 2003. This is the same forest
functional level that exists in Windows 2000 forests.
SANS Institute
Windows Server 2003 Forest Functional Level. All domain controllers must be
running Windows Server 2003 or later. Many of the unique features of Windows
Server 2003 are available only at this level, including cross-forest trusts, domain
renaming, renaming Schema objects, global catalog replication tuning, linked
value replication, InetOrgPerson passwords, and more. All domains in the forest
must be running at Windows Server 2003 domain functional level or better prior
to upgrading to this forest level.
Windows Server 2008 Forest Functional Level. All domain controllers in all
domains must be running Windows Server 2008 or later.
Once a forest's functional level has been advanced, there's no going back ...
To raise a forest's functional level, right-click the Active Directory Domains and Trusts
MMC snap-in > Raise Forest Functional Level.
Please raise your domain and forest functional levels to their highest available now.
SANS Institute
- One-way or two-way trust?

- External or cross-forest?
- Want to share everything to Authenticated Users?
- Requires 2003 forest functional level or better.

- Enable on the trusting trust link (one or both).
- "Allowed To Authenticate" permission in AD.
Configure only on specific servers you want to share.
Imagine you have a partner company with whom you regularly share resources. It could
be a supplier, distributor or contractor, but it might also be another company under an
umbrella holding corporation or just another division within your company. In any case,
you have separate Active Directory forests, there is an impending need for some of the
domains in these two forests to trust each other, but the human beings in the two IT
groups don't really trust each other. You've decided to make the site-to-site VPN
connecting your two corporate networks permanent. It's time to start setting up one or
more trust links. What do you do?
uestion 1: Do you want a one-way or a two-way trust?
Because it's two separate forests, you're thankful you don't have to worry about
replicating AD data between your organizations (but there have been rumors of
something called "Microsoft Identity Lifecycle Manager" being deployed later for some
PKI reason). If both sides must share resources, it must be a two-way trust. If only one
party needs to share resources with the other, it need only be a one-way trust. Because
we're imagining a partner company, it'll have to be a two-way trust.
2: Do you want external trusts or cross-forest trusts?
Only if both forests are at the 2003 functional level or better can a cross-forest trust be
established, so you might be compelled to use external trusts if any of your domain
controllers are running Windows 2000. From an authentication and authorization point
SANS institute
of view, the big difference between external and cross-forest trusts is whether the trust
relationship is transitive. If two domains in two different forests only have an external
trust, only those two domains trust each other (intransitive). If the two root domains
establish a cross-forest trust, on the other hand, every domain in both forests will trust
every other domain in both forests (transitive). Domain-to-domain external trusts are
more secure because they do less, but if each forest only has one domain, or if a mesh (or
mess) of external trusts will be created anyway, there's less administrative overhead to
using a cross-forest trust. Cross-forest trusts also fully support Kerberos referrals. In the
end you grudgingly choose a cross-forest trust. Why are you anxious?
uestion 3: Do you want all the users in the other forest to get access to everything in
your forest which has been shared to the Authenticated Users group, such as shared
folders, databases, web apps, and IP fax-printers?
No! But what can we do? The built-in Authenticated Users group includes every user
and computer that is a member of any domain in the two forests. There's no way to
change this. Do we need to review every permission on every resource in the forest to
confirm that nothing important is shared out to Authenticated Users now?
Fortunately, you don't. Both external and cross-forest trusts support a feature Microsoft
calls "Selective Authentication".
Selective ent k a tio

Selective Authentication (SA) is a feature of cross-forest and external trusts. It requires
that all domain controllers in the two forests be running Windows Server 2003 or later,
and the functional level of both forests must be at 2003 mode or better.
The effect of SA is not to remove users from the other forest from the Authenticated
Users group. This can't be done. But before one can exercise the privileges or
permissions that have been granted to the Authenticated Users group on a server, you
have to successfully authenticate to that server. If you can block the initial authentication
from remote forest users to your servers, then it doesn't matter what permissions or rights
have been granted to the Authenticated Users group on the server: can't authenticate,
you're not a member of the Authenticated Users group!
By enabling Selective Authentication on a trust, you turn off the ability of remote forest
users to authenticate at all to local servers. Since the default is now to prevent
authentication, you can override that default and allow authentication on just the servers
that you know you wish to share across forest boundaries.
Hence, using SA is a three-step process: 1) enabling SA on the trust link, 2) choosing

which foreign users, computers and groups are permitted to authenticate to your own
local servers, then 3) configuring permissions on the resources of that server to share
access, either through the Authenticated Users group or through the native groups of the
remote forest.
SANS Institute
e io
Selective Authentication can be enabled on a trust when running the New Trust Wizard to
create it, or it can be enabled afterwards for existing trusts by going to the properties of
the trust in the AD Domains and Trusts MMC snap-in.
OW!
To enable the Selective Authentication feature on an existing cross-forest or external
trust, open the AD Domains and Trusts snap-in > Properties of the domain > Trusts tab >
properties of the relevant trust > Authentication tab > choose "Selective Authentication:
Allow authentication only for selected resources in the local forest ..." > OK.
In a two-way trust relationship, one trust might have SA enabled (Forestl -3 Forest2)
while the other trust could have SA disabled (Forest2 3 Forestl), or both could have SA
enabled, or both could have SA disabled. SA is not enabled by default.
You can also enable SA from the command line with NETDOM.EXE.
ic res
Once SA has been enabled on a trust link, users and computers in the trusted forest will
no longer be able to access resources on computers in the trusting forest because they
won't be able to authenticate at all. You now have to grant permission to authenticate to
allow the access. This is done, not on the server itself, but on the server's computer
account in Active Directory.
SANS Institute
To allow access to a computer that exists in your own (trusting) forest, go to the
properties of that computer account in the AD Users and Computers MMC snap-in >
Security tab > and grant the "Allowed To Authenticate" permission to whatever
users/computers/groupsyou wish in the trusted forest. You can also grant this
permission to Authenticated Users.
Authenticated Users
DomainAdmins
How does a server know that a user is from another forest and hence might need the
"Allowed To Authenticate" permission? That userk collection of SIDs in their Kerberos
ticket will include one named "Other Organization" (S-1-5-1000). This SID is added by
the domain controllers in the trusting forest automatically.
3) Configure Permissions On That Server

Now configure permissions and privileges on the server you wish to share across forest
boundaries just like normal. You can configure permissions based on the Authenticated
Users group, or you can assign permissions directly to users, computers and groups from
the other forest.
Note that, by default, only members of the Account Operators, global Administrators,
Domain Administrators, Enterprise Administrators, and SYSTEM groups located in the
trusting domain can modi@ the Allowed to Authenticate permission. A member of the
local Administrators group on a computer, then, cannot change this permission in AD.
For more information about Selective Authentication, see the article entitled "Planning
and Implementing Federated Forests" on Microsoft's web site (Google it).
SANS Institute
s "
No, Selective Authentication is different from SID Filtering. SID Filtering is enabled by
default on all external and cross-forest trusts created on domain controllers running
Windows 2000 Service Pack 4 or later operating systems. It prevents a rather unlikely
attack from evil Domain Admins in other forests, but, of course, if that's what you're
worried about, evil Domain Admins, then there's much bigger things to worry about.. .
SANS Institute
- Two or more domains.

- 99.9% of users and
computers in subdomain(s).
- Only the essential users and
DC accounts in root domain
to maintain it.
subdomains with
.
An "empty root domain" model has at least two domains. One is the first Windows AD
domain installed --the "root domain"-- but it will have no user or computer accounts
except for those necessary to maintain the root domain itself (hence, it is "empty"). User
and computer accounts would be created in one or more subdomains under the empty
root. 99.9% of the users, computers and resources will be in the subdomain(s).
Recommend Creating
It is widely believed that Microsoft, HP, NetIQ and other AD-savvy vendors recommend
creating an "empty root domain" for technical and security reasons, and that this is better
than having a single domain in most cases. This is not true. I take Microsoft to be
authoritative on this issue, and the Microsoft whitepaper entitled "Setting Up An Empty
Root Domain", to be more-or-less their official statement. I will quote that whitepaper
here because this issue has sparked heated arguments at prior SANS conferences:
"In general, political and not technical decisions cause organizations not to use the single
domain model (p.1I)."
"The empty root domain is not suitable for all situations. In particular, if departments are
amenable to working together, and dividing responsibility and control using organizational
units, a single domain model may be preferred (p.IO)."
.almost all decentralization that can be done with domains could also be done with
'I..
OUs in a single domain, at far lower cost (p.19)."
SANS Institute
Politics, not valid technical or security considerations, is the most common reason for
deploying an empty root model. This is not to say that it is a "bad model", only that its
appropriateness is not as universal as is widely believed.
re ?
Proponents of empty root domains --which includes other articles from Microsoft itself--
give the following reasons for its benefits over the single domain model. I will play
devil's advocate for the sake of balance:
nterprise Admins and Schema Admins groups." But in a

single domain, where users and resources are divided into OUs, and OU Admins
groups are delegated authority over them, members of the OU Admins groups
cannot modify the Schema Admins or Enterprise Admins groups. Only a small
number of users --perhaps only one or two-- really need to be a member of the
Domain Admins group because the rest of the authority is delegated. And in both
models someone has to be trusted not to abuse their forest-wide powers.
Permissions and auditing can be set on the Schema Admins and Enterprise
Admins groups to secure them, and simple scheduled scripts could check their
memberships every five minutes to alert of changes. Only rarely will someone
need to be added to the Schema Admins or Enterprise Admins groups at all. The
greater threat comes from poor physical security, but all domain controllers in all
forest models must be physically secured, not just in single-domain models. The
argument from a compromised Enterprise Admins group is an argument for
multiple forests, not for an empty root domain model.
etter decentralized administration than with

through AD permissions and Group Policy, authority can be delegated more
precisely, easily and quickly with OUs than with the creation of entire new
domains, and at a far lower cost. Kerberos, password and account lockout
policies can only be configured at the domain level, but creating separate domains
to enforce different password policies and shuffling users between domains when
you want to change those users' policy, is drastic overkill. Why not just use a
custom password complexity filter at a fraction of the cost?
omain will never become obsolete." Why would the single domain
become "obsolete"? Because you cannot change its name? With Windows
Server 2003 and later you can rename domains; with Windows 2000 domains,
you couldn't rename the root domain. Because the DCs in the single-domain
model won't be upgradeable to future versions of Windows Server? Then the
same must be true for the root domain's DCs too then (and, besides, that's just
silly). Because it won't have to be renamed or destroyed if the company is
acquired by or merges with another company? There's no protection from the
whirlwinds of capitalism-- besides, all bets are off in that case anyway and you
can always resort to cross-forest trusts. Because you can add a subdoinain more
easily? But you can add subdomains to your current single domain just as easily,
SANS Institute
and this seems to beg the question about the desirability of having multiple
domains anyway.
"An empty root provides more flexibility for managing users/resources."

This is just false. It is far easier to move users, computers and groups from one
OU to another within a single domain than between domains. OUs are trivially
easy to create and delete, but domains require new hardware, new software
licenses, replication traffic planning, etc. If one's organization acquires or merges
with another, the other domain cannot simply be "plugged into" the current root as
a subdomain --the DCPROMO.EXE joining process just doesn't work like that--
and an external or cross-forest trust to that domain doesn't magically make it a
replication partner. It would be far easier to recreate or clone accounts from the
other domain into an OU in the current one, especially with the capabilities of the
Active Directory Migration Tool version 2.0+.
"Corruption in the AD database of the subdomain won't spread to the root."

But, by definition of an "empty root", it's the subdomain which has all the users
and computers-- who cares about the root domain when 99.9% of the network has
just crashed? Besides, global catalog replication is two-way, and Schema and
Configuration NC changes propagate top-down, not bottom-up (ix., from the root
domain to the subdomains), so any corruption in these datasets is functionally
identical to having the same problem in a single domain. This argument is
actually an argument for having multiple forests, not multiple domains in the
same forest.
"It isolates the other subdomains from the changes made in just one
subdomain." The argument from the need for isolation is an argument for
having multiple forests, not an empty root in a single forest. Any changes which
affect the Global Catalog will affect all domains in the forest, and the Global
Catalog comprises about 55% of the AD database.
"We can use SID Filtering to make the subdomain a true security
boundary." But SID Filtering only works when the other domains are outside
the local forest. If SID Filtering is enabled inside the forest, replication stops,
universal security groups don't work, Exchange has problems, and transitive trusts
fail (KB289243). SID Filtering is enabled by default in Windows Server 2003
and in Windows 2000-SP4, but it only applies to external and cross-forest trusts.
SID Filtering can be turned off with the NETDOM.EXE tool, but this would be a
bad idea. And because SID Filtering cannot be used within a forest, this means
that any Domain Admin in one domain can modify his or her sIDHistory attribute
to include the SID of a Domain Admin in another domain, thus effectively
becoming a Domain Admin in that other domain for the sake of remote DACL
authorizations- all this, of course, amounts to a strong argument in favor of
having multiple forests with cross-forest trusts instead of an empty root forest!
SANS Institute
is e ?
No, the empty root model has its strengths and weaknesses like other models, and should
be chosen when it is best for the circumstances. The point is, rather, that the single
domain model should still be considered the default or initial choice. One should have to
clearly just@ not going with a single domain in favor of any other model, including the
empty root model. The empty root should not be the presumptive choice.
In most cases, though, if you are content to have a domain be a member of the forest,
then that domain should usually be an OU instead. On the other hand, if there are
legitimate security reasons for splitting off some users/computers into a separate domain,
then usually they should be in a domain outside of the forest with either no trusts with the
forest or only an external/cross-forest trust. Most good arguments for having multiple
domains are actually arguments for having multiple forests in disguise.
The most likely valid reason to have an empty root domain is when the organization is
international, and the language, geographical, political or cultural differences between the
countries are significant enough that having separate domains would simplify
administration, or when compliance with local laws in these various countries
necessitates it. But then why does the root domain have to be "empty"?
In short, think of the empty root domain model as just one of the tools sitting on your
security workbench. No tool is best for everything. The same is true of the empty root
domain model.
SANS Institute
- Avoid joining servers to the internal forest!
- What are the alternatives for stand-alone servers?

RADIUS and LDAP add-ons for web applications.
ISA Server supports both RADIUS and LDAP.
RRAS supports RADIUS for IPSec, SSTP and PPTP VPNs.
802.1 1 wireless access points support RADIUS -F EAP.
But what good is authentication without authorization rules?
- One-way or two-way trust? External or cross-forest?
.
You have services you want to provide to users on the Internet, usually over protocols
like HTTP, SMTP, Telnet, FTP, RDP, RPC or various VPN flavors. Some of these users
are your own company employees who happen to not be at the office; some are partners,
suppliers, contractors, temporaries and regular customers with whom you have an on-
going working relationship; and some of these users are unauthenticated random
strangers who happen to be browsing your web site or forwarding SMTP messages to
you. These services are hosted on one or more servers and these servers are located
somewhere on some network. These Internet-exposed servers and their portion(s) of
your overall network is called your extranet.
The question today is whether these extranet servers are stand-alones or members of an
Active Directory domain. If they are domain members, in which forest? Do the domains
in this forest maintain any trust relationships to other forests? Where are these extranet
domain controllers physically located and how are they firewalled?
There are many reasons why Internet-exposed servers should be (or must be) domain
members. Kerberos delegation, digest authentication, single sign-on, Group Policy,
application design requirements, identity and password management goals, ease and
scalability of administration, etc. could all be used as arguments for making some or all
of one's extranet servers members of some domain. If security is the only concern, then
perhaps stand-alones are better, but when in real life is security the onZy consideration?
SANS Institute
E er
Whenever possible, avoid joining extranet servers to any internal domain or forest which
is used for the bulk of your other users, workstations and servers. If an extranet server is
compromised, its domain membership might be exploited to gain further access into the
internal network or compromise other domain members. If you do this anyway, at least
make the extranet a separate site in AD and place one or two RODC controllers in that
site instead of a full writable controller; this won't buy you much, but it might at least
slow down your adversaries if they waste time trying to alter the RODCs.
re ores
If your Internet-exposed servers must be domain members, create a new separate forest
just for them. It's not good enough to create a new domain within your internal forest, it
must be a new forest composed of one or more new domains. We'll call this an extranet
forest.
An extranet forest provides a number of advantages:
Single sign-on with Kerberos, NTLMv2 or certificates across the servers and
applications hosted within the forest.
A single set of global groups for the consistent and easy management of
permissions and privileges across servers in the extranet.
Group Policy management of extranet servers for all their security settings, such
as IPSec, Windows Firewall, password policies, authentication protocols,
software updates, PKI, audit policies, etc.
An LDAP-accessible database (namely, Active Directory) for the storage of

configuration data used by applications designed for directory integration (such as
Authorization Manager for 11s web applications).
You have the option to create trust links to other domains and forests, such as a
one-way cross-forest trust using selective authentication.
Users and computers created in the extranet forest do not thereby acquire any
status, privileges or permissions in the internal forest (unless you choose so). And
you can create, modify and delete vast numbers of objects in the extranet without
causing any additional replication traffic among internal domain controllers, e.g.,
creating user accounts for customers, suppliers, contractors, etc.
Corruption of the Active Directory database in the extranet forest, especially its
schema, will not be replicated to the internal forest.
An adversary gaining Enterprise Admin or Domain Admin control over the

extranet forest does not, in itself, allow a compromise of the internal forest.
SANS Institute
You can delegate authority within the extranet forest in ways which would be
difficult or impossible to do in the internal forest, e.g., add a semi-trusted
contractor to the Domain Admins group.
There are disadvantages to creating an extranet forest too though:
More integration and dependencies among the domain members and controllers
creates more potential opportunities for components to fail naturally or be actively
exploited. Think of the extra protocols involved in domain membership:
Kerberos, LDAP, the RPC "secure channel", NTP, SMB for Group Policy, etc.
Compromise of a domain controller would lead to the compromise of every other

computer and user in the extranet forest. r
IPSec and/or special firewall rules would have to be maintained to regulate

communications between controllers and member servers. You'll likely need to
add at least one more interface or VLAN to the firewall to segment off the
controllers from the member servers too.
hat ay Cross-Forest Trust Is Intolerable?

There are other ways to authenticate internal forest users without creating a trust link
between the extranet and internal forests. RADIUS, LDAP and certificate-based
authentication methods generally don't require Active Directory trust relationships. In
fact, these authentication methods usually don't require domain membership for the client
or server computers at all!
Microsoft's built-in RADIUS server, named Ynternet Authentication Service (IAS)" in

Windows Server 2000/2003 and "Network Policy Server (NPS)" in Windows Server
2008 and later, can be installed on an internal domain controller. Servers and
applications in the extranet can forward their authentication requests to the internal
RADIUS servers even though there is no trust link between the extranet forest and the
internal forest. In fact, the extranet servers using RADIUS could be stand-alones and still
be permitted to forward RADIUS authentication requests to the internal controllers with
the RADIUS service installed.
Similarly, extranet server applications which support LDAP can be configured with
credentials to log onto an internal domain controller and forward user authentication
requests directly via LDAP.
Examples of servers that can forward authentication requests via RADIUS or LDAP:
Microsoft ISA Server supports both RADIUS and LDAP. ISA Server can be used
as a reverse HTTP proxy for any web applications which support Basic
authentication over SSL, such as Outlook Web Access (OWA), SharePoint
SANS Institute
Services, WebDAV, SOAP and XML-based web services generally. The ISA
Server can be a stand-alone.
Microsoft RRAS, for IPSec, SSTP and PPTP VPN access, supports RADIUS.
802.11 wireless access points with WPA support RADIUS.
Many other third-party servers and applications, especially when designed for
Unix/Linux servers since they cannot normally be joined to an AD domain,
support RADIUS and/or LDAP.
Another option is to create "shadow accounts" in the extranet forest for all users in the
internal forest. Shadow accounts have the same usei-name as the original accounts in the
internal network. If the shadow accounts have the same passwords too, users won't have
to remember multiple passwords. If certificate authentication is used to the extranet
instead, the passwords don't have to be kept synchronized. Accounts and passwords can
be kept automatically synchronized with products like Microsoft's Identity Lifecycle
Manager (ILM) or third-party equivalents.
Aye, there's the rub.. . If you only wish to allow/deny access based on whether a user
cadcannot authenticate with internal domain credentials, then RADIUS, LDAP and
shadow accounts are good enough. But what about the permissions and privileges
defined on the servers being accessed, especially when some of these servers are a part of
the internal forest? You have NTFS permissions on the hard drive, logon restrictions
defined through user privileges, permissions on tables and other objects in SQL Server,
Exchange Server mailbox permissions, delegated roles in SharePoint and other web
applications, etc. -- all of these may require reference to group memberships defined in
the internal forest, not in the extranet forest, but it becomes a huge pain to manage such
authorization issues without a one-way trust. The point of authenticating users is to
confirm their identities before granting them the permissions and privileges their group
memberships provide them, but if authentication is divorced from these groups,
permissions and privileges, then authentication loses much of its purpose. You might
find yourself needing a one-way trust link after all.. .
es ?
If users need to authenticate to the extranet servers with their global accounts from an
internal forest, you may need to establish a trust link. If you do require a trust between
the extranet forest and the internal forest, then the trust should:
Be a cross-forest trust, which requires that both forests be at the 2003 forest
functionality level or better, which requires that every domain controller in the
two forests be running Windows Server 2003 or later.
Be one-way, where the root domain of the extranet forest trusts the root domain of
the internal forest, but not the other way around! The internal forest should never
SANS Institute
trust the extranet forest. (Don't forget that access to resources is opposite to the
direction of trust.)
Have the selective authentication feature enabled, hence, users from the internal
forest will not be able to access resources on extranet servers unless those servers
have been specially configured to allow it. This may seem to defeat the intent of
the one-way trust, but we must assume that eventually either an extranet server or
an internal computer will be compromised, so we want to enforce defense in
depth whenever possible to limit the scope of the damage.
SANS Institute
If you do create a one-way trust from your extranet forest to the internal forest, you'll
need to carefully design your firewall and IPSec policies to prevent the spread of any
compromise of the extranet servers to your internal network.
I
While establishing the cross-forest trust initially, just allow all traffic between the IPS of
the extranet controllers and the desired internal controllers for the 5-15 minutes necessary
to establish the trust, then restrict the necessary ports afterwards. Which internal
controllers will be used is controlled by the DNS SRV and host records you'll add
beforehand to the DNS service on the extranet controllers (DNS for Active Directory is
discussed in a different part of this course).
Once the trust is established, the following traffic will have to be allowed between the
extranet controllers and the desired internal controllers for a one-way cross-forest trust.
I Kerberos I 88/TCP/UDP
That's it! Only Kerberos must be allowed between the extranet and internal domain
controllers fora cross-forest trust, once the trust is established. If the extranet controllers
SANS Institute
later get rooted, only Kerberos traffic is permitted by the firewall. This should hopefully
block any attacks long enough for you to scrub the extranet controllers clean and
reinstall.
However, if you wish to allow Kerberos and also NTLM, then you'll need to assign a
fixed RPC port number for NTLM (say, TCP/5 113) and allow that too. To assign a fixed
TCP port for NTLM, set the number in the DCTcpipPort value in the registry under
HKLM\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters.
RPC End Point Mapper 135/TCP

RPC NetLogon <your-choice>/TCP
As you can see, allowing NTLM requires allowing access to 135/TCP and another port
for the RPC-based NTLM traffic. Not ideal, to say the least. If you must allow NTLM,
consider using a firewall which can perform application-layer inspection of RPC traffic,
such as ISA Server 2006 or later. If an adversary attempts to attack the internal domain
controllers through the RPC ports, hopefully the deep inspection of the RPC traffic by the
firewall will block the attack or at least alert the administrators.
Note: If you're interested, SANS has a course on ISA Server too (SEC520).
There is another firewall issue. To establish the trust in the first place, it was easiest to
just temporarily allow all traffic between the controllers. However, when permissions are
managed on extranet servers, and global or universal groups from the trusted internal
forest need to be browsed and added to local groups on the extranet servers, there are
other ports that need to be temporarily made available to the internal controllers during
this permissions-management time. You can either temporarily allow all traffic again, or,
if this is going to be a regular occurrence, create a new rule in the firewall which can be
quickly enabled and disabled on-the-fly.
The following are the additional ports to allow browsing of groups in the internal forest.
Remember these ports are only for packets coming to/from the IP addresses of the
extranet controllers and the desired internal controller(s).
RET End Point Mapper 135/TCP

RPC NetLorron <vow-choice>/TCP
I RPC LSA NTDS I <your-choice>/TCP
SANS Institute
The fixed RPC port for NetLogon is the same as above for NTLM (RPC connection to
the same service). The LSA's NTDS RPC port is fixed by setting a value named "TCP/IP
Port" in HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters.
If you have other services or protocols in use, these will have to be provisioned as well.
Have your protocol analyzer ready and consult the following reference documents
(Google as necessary):
MS Whitepaper: "Active Directory in Networks Segmented by Firewalls".
MS Whitepaper: "Planning and Implementing Federated Forests".
KI3179442: "How to configure a firewall for domains and trusts".
KI3224 196: "Restricting Active Directory replication traffic and client RPC traffic
to a specific port".
Keep in mind that the firewall should only allow the necessary traffic between the
extranet and internal controllers themselves. The extranet controllers are denied all
communications with other internal hosts either with the perimeter firewall, IPSec, or the
Windows Firewall.
eC e S
IPSec is a network-layer protocol which provides authentication, encryption, and static
packet filtering. Windows has built-in support for IPSec. Though IPSec is best known
for packet encryption and Virtual Private Networking, it can also be used for
authentication and static packet filtering. For stateful or dynamic packet filtering on the
host, use the Windows Firewall or a third-party equivalent.
Unlike Encapsulating Security Payload (ESP), IPSec's Authentication Header (AH) does
not perform data encryption, hence, the overhead of using AH is less than using ESP with
encryption enabled. If NAT-T is required to traverse devices performing Network
Address Translation (NAT), then ESP can be used with or without encryption.
Keep in mind that the bulk of the packets coming idout of your public servers will not be
IPSec-secured, e.g., HTTP and HTTPS will not use IPSec. If the performance penalty
does become too great, inexpensive IPSec-offload network adapter cards can be installed
to relieve their mainboard CPUs of the burden.
All extranet servers, including the controllers, should be configured to require IPSec AH
(or ESP with no encryption) for all non-public communications. They should ideally use
certificate authentication and disable the Filter Action option to "Allow unsecured
communication with non-IPSec-aware computers".
If there are sensitive ports on your DMZ servers that could benefit from encryption, such
as for Terminal Services or Telnet, then require that IPSec encryption by all means. Just
don't impose Performance penalties on yourself unnecessarily.
The perimeter firewall should also be configured to drop all IPSec packets whatsoever
except those to/from the VPN gateway.
SANS Institute
We must also plan for compromise. If one of the servers in the extranet is taken over by
hackers, we don’t want that compromised machine to be a useful platform for attacking
the other servers. Hence, every extranet server should block the unnecessary packets
from every other extranet server, including their IPSec packets (perhaps especially their
IPSec packets). This should be done with a host-based firewall because IPSec only
provides static packet filtering. For example, unless you have a special application that
needs it, why do the SMTP gateways and web servers need to talk to each other? Why
does the DNS server need to be open to the other machines for anything other than DNS?
And, unless you’re using a load balancing service, it is very rare that the web servers
need to be able to receive packets from each other at all. In short, if a communications
channel is needed between the boxes in the DMZ, then allow it in cleartext, if it’s not
needed, then block it.
If a server is compromised badly enough, say, through a buffer overflow exploit with a
reverse shell, the server will open an outgoing TCP channel back through the firewall and
out to a system on the Internet controlled by the hacker; there, the hacker will have a
listening application, possibly netcat, waiting for the connection from the server in order
to establish a remote CMD shell session on the server. You might not be able to predict
and block the attack, but at least you can block the reverse shell from phoning home.
Hence, make sure to block all unnecessary out-going traffic from the extranet servers to
the Internet as well.
This block-everything-except-what’s-needed rule applies to the communications between

these extranet servers and the other boxes inside the LAN as well, but you’ll need to
permit the IPSec though for remote administration. The network administrators behind
the firewall who need to access these boxes will have the necessary certificate, Kerberos
ticket or pre-shared key for IPSec authentication, but you’ll have to decide whether other
users need this kind of unfettered access (probably not). The public ports on the extranet
servers will be available to everyone, both inside and outside the LAN, but only
configure the internal machines that need complete access to these machines with the
proper IPSec credentials for authentication.
How to configure all this? Well, the Windows track has an entire day devoted to IPSec
and the Windows Firewall. Unfortunately, no time to discuss it now.
SANS Institute
So, in general, when can or should another forest be created? From a security point of
view, consider creating another forest for your organization when:
When certain resources or users are so important for the organization that they
should be separated off into their own forest with their own special IT staff,
facilities, firewalls, procedures, etc. Example: a DoD contractor working on a
secret skunkworks project worth billions of dollars, or when lives are at stake. In
this case, we don't trust all of the Domain Admins or Enterprise Admins, or the
procedures and controls implemented in the new forest would be incompatible
with how the original forest is managed.
When certain computers or users must be separated from the main forest in order
to protect the forest+om them because of their likely coinpromise. Example:
extranet TIS servers, or a large number of temporaries working on a short-term
project, or a malware forensics lab. In this case, we can either have no trust links
or use Selective Authentication.
When the need for fault tolerance overrides all other financial or IT
considerations. Example: your company owns 20 nuclear power plants, each its
own separate forest, because you absolutely cannot have a compromise at one
facility lead to compromise of the others. In this case, the shared Schema,
Configuration NC and Global Catalog represent threats because other people and
machines beyond your control can modify them.
_.
SANS Institute
When a forest needs to be established for software testing or development

purposes, especially for software that modifies the Schema or Configuration NC.
This forest could also be used for patch testing, Group Policy testing, and user
training.
There are, of course, additional reasons to create a new forest that are not primarily
motivated by security, but can have security implications:
When your company acquires or merges with another, but the other company
already has a large and well-managed forest. In this case, the other forest was
already created for you and it's more practical in the short-term at least to just set
up a cross-forest or external trust. Such trusts are often used during the migration
or assimilation process.
When you must run a mission-critical application that must modify the Active
Directory database in ways which are incompatible with other needs.
When there are legal mandates which require an absolute separation of data,
hence, you can't even have a Global Catalog. Example: HIPAA requirements in
the healthcare industry, a contractor doing classified work for the military, a
financial institution handling foreign bank account information, etc.
When the bandwidth between two sites is so slow or unreliable that no replication
optimization tricks can cope with it. Example: when there is no connectivity
whatsoever between the two sites.
SANS Institute
- Probably the best argument for a multi-domain forest.
All the domains in a forest automatically trust all the others domains in that forest, and
there is quite a bit of AD replication among them. These facts make it much less likely
that new domains will be created for security purposes. Domains are not primarily
security boundaries, they are mainly replication boundaries.
Here are some situations where creating additional domains in the forest makes sense, but
note that these situations will be rather rare and there are important mitigating factors to
consider.
Consider adding a new domain to a forest that already exists:
When certain Group Policy settings which can only be applied domain-wide must
be different for different users or computers (and you really cannot live with the
homogeneous settings or find any work-arounds). Kerberos policies, account
lockout policies, and password policies can only be configured at the domain
level in Windows 2000/2003.
However, tighter Kerberos settings can usually be applied to everyone because

their effects are invisible to users; lockout policies are typically the same for
everyone because the security advantages of having less than five chances to
guess your password are far outweighed by the administrative hassles, even in
paranoid environments, and lockout policies have the potential for being a self-
imposed DoS attack; and separate password policies can be accommodated by
SANS Institute
custom password complexity filters that enforce different policies for different
global groups, by the issuance of smart cards to critical users, and the use of
custom passwordlockout policies in AD with Windows Server 2008 and later.
When the bandwidth between two sites is slow and unreliable, but not so
unreliable that one site must be converted into a separate forest. By converting
one site into a new domain in the forest, this will result in a reduction in Domain
NC replication traffic because only the Global Catalog will be replicated, and you
can perform the initial setup using the install-fi-om-media trick.
However, keep in mind that AD can replicate over very slow WAN links during
non-peak hours, you can easily replicate over site-to-site VPNs, and broadband
Internet access is cheap as dirt. Wouldn't it be better to upgrade the bandwidth?
Or to set up a separate forest with a two-way cross-forest trust to reduce
bandwidth consumption even more?
When you absolutely must have a separate DNS domain name for a group of
users and computers, and simply having multiple DNS records for the same hosts
or multiple DNS servers with different zones of authority is insufficient.
However, UPN suffixes for user logons do not have to match the name of your
AD domain, SMTP domain suffixes for e-mail addresses do not have to match
your AD domain name either, and "split" or "segmented" or delegated DNS
subdomains can usually be implemented to achieve the same results.
When the organization is international and the language, political or cultural

differences are significant enough that separate domains would simplify
administration; for example, default language and "locale" settings are usually set
domain-wide. A separate domain may also be necessary to comply with local
laws concerning privacy, encryption, corporate disclosure rules, etc.
In this author's opinion, the needs of an international organization is the best argument for
having multiple domains in a single forest. In general, it will be rare that a security
consideration drives the creation of a new domain in the forest. Almost always, security
issues drive the creation of new forests, not new domains.
easons TQ Create
In the real world, though, domains proliferate like rabbits. Here is a sampling of reasons
that should not be persuasive for adding more domains to a forest, yet are very often the
stated or unstated reasons for doing so.
"Because we had multiple domains when running Windows NT 4.0."
"Because group X doesn't feel that their 'identity' will be preserved if they are
'nierely' an OU.
SANS Institute
"Because IT group X feels they are being 'demoted' if they don't get their own
domain. "
"Because our division's MBAs want their own domain for prestige too."
"Because we need room to grow -- future expansion!"
"Because IT group X absolutely will not tolerate their subordination or even their
peering with IT group Y. And there's so much resentment and bitterness that they
are going to hold up the entire AD deployment indefinitely unless they get their
own domain, even if there's not security or technical reason for it."
Any of the above describe your organization? Don't feel bad, that how it works almost
everywhere. The human layer in the OS1 model is always the most fragile.. .
SANS institute
Windows domain controllers and clients require DNS. DNS is no longer an optional
service on Microsoft networks. After political issues, DNS issues are the biggest obstacle
to effective AD deployments. Your DNS infrastructure will also be targeted by your
adversaries because it is something of an Achilles' Heel for Active Directory.
Windows DNS supports the following RFC standards:

SRV resource records (RFC 2782).
Dynamic updates (RFC 2136).
DNS change notification (RFC 1996).
Incremental zone transfers (RFC 1995).
Negative and positive caching (RFC 2308).
DNS security extensions (RFC 2535).
Wildcards in hostnames (RFC 1034).
Windows DNS also supports the following features:

Active Directory integrated zones.
AD permissions on DNS records stored in AD.
Secure dynamic updates with AD-integrated zones.
WINS lookup through DNS for non-Windows clients.
UTF-8 Unicode characters in DNS records, including the underscore character.
Automatic scavenging of stale dynamic DNS records.
SANS Institute
Your primary graphical tool for managing DNS is the MMC snap-in named "DNS".
Please add this snap-in to your favorite console now, or you can find it in the
Administrative Tools folder off the Start menu.
PI @ Global Logs
DomainDnsZones
ForesEnsZones
Conditional Forwarde:s
.. __ .__ .. . . .. . .. .
4 ; __ ... _ _ ..._
-
__-.... .. . ... ..-
_
I
. .......I.... . .. , -. -.
. b..
Besides the DNS snap-in in the Administrative Tools folder, there are other utilities
useful for managing DNS.
SANS institute
1PCONFIG.EXE is built into Windows and can be used to display IP

configuration data, releasehenew DHCP leases, display/clear the DNS cache on
the client, refresh all dynamic update records in DNS, and more.
SLOO .EXE
NSLOOKUP.EXE is a command-line resolver. It can be used to issue queries to
selected DNS servers to test the information returned. In particular, use the "1s"
command to test whether your DNS servers permit zone transfers.
DIG.EXE is a popular replacement for NSLOOKUP because it is more versatile.

DIG is not a Microsoft tool, it is downloaded for free from the BIND website at
http://www.isc.org/products/BIND/. Go to the current release section and get the
Windows Binary Kit to get a Windows version of BIND (with DIG.EXE in it).
sc
DNSCMD.EXE can be used to manage virtually every aspect of local or remote
DNS servers. It can list/create/delete resource records, clear the DNS cache, set
IP addresses for recursive queries, sign DNSSEC zones, create/delete zones,
initiate zone transfers to secondaries, change zone type, initiate scavenging of
stale records, etc.
:\>dnscmd.exe /?
SBGE: DnsCmd <SeruerName> <Command> [<Command P a r a m e t e ~ s > l
<Se r u e r N a m e > :
-- l o c a l machine u s i n g LPC
i P address -- RPC o u e r TCP/IP
DNS name -- RPC o u e r TCP/IP
o t h e r s e r v e i s name -- RPC o u e r named p i p e s
<Command>:
/Info -- Get s e r u e r i n f o r m a t i o n
/Conf i g -- R e s e t s e r v e r O F z o n e c o n f i g u r a t i o n
/EnumZones -- Enumerate z o n e s
/Statistics -- Q u e r y / c l e a P seivei. s t a t i s t i c s d a t a
/ClearCache -- C l e a r DNS s e i w e r c a c h e
/I,Irit eBackFiles -- W r i t e b a c k a l l z o n e OP r o o t - h i n t d a t a f i l e < s >
/ S t a r t S c a u e ngi n g -- I n i t i a t e s sexweis s c a v e n g i n g
/ R e s e t L i s t e n R d d P e s s e s -- S e l e c t s e w e r I P a d d r e s s < e s > t o s e r v e DNS r e q u e s t s
/Reset Forwardem -- S e t DNS sewei*s t o f o x w a r d r e c u r s i u e q u e P i e s t o
/Zone1 nf o -- Uiew z o n e i n f o r m a t i o n
/Zoneodd -- C r e a t e a new z o n e on t h e DNS s e r u e r
/ZoneDelete -- D e l e t e a z o n e fpom DNS s e r v e r or DS
/Zonepause -- P a u s e a z o n e
/ZoneResume -- Resume a z o n e
/Zone R e l o ad -- R e l o a d z o n e fpom its d a t a b a s e < f i l e or DS>
/ZoneWriteBaclc -- W r i t e b a c k z o n e t o f i l e
/Eon e Ref r e s h -- F o r c e r e f r e s h o f s e c o n d a r y z o n e f r o m mastep
/ZoneUpdatePromDs -- Update a DS i n t e g r a t e d z o n e b y d a t a f r o m DS
/ZoneResetType -- Change z o n e t y p e Primai.y/SecondaPy/DSintegi.ated
/ Z o n e R e s e t S e c o n d a i * i e s -- R e s e t s e c o n d a r y \ v o t i f y i n f o r m a t i o n f o P a z o n e
/ZoneResetScavengeSeruers-- R e s e t s c a v e n g i n g s e i w e l * s f o r a z o n e
/ZoneResetMasters -- R e s e t s e c o n d a r y z o n e ' s master s e w e r s
/En umRe c o rds -- Enumerate r e c o r d s a t a name
/RecordBdd -- Create a P e c o r d i n z o n e o r R o o t H i n t s
/Re coi*dDel e t e -- D e l e t e a r e c o r d f r o m z o n e , R o o t H i n t s or Cache d a t a
/NodeDe l e t e -- D e l e t e a l l r e c o r d s a t a name
/8geB 1 l R e c o i d s -- F o r c e a g i n g on n o d e < s > i n z o n e
<Command P a r a m e t e r s > :
-- p a r a m e t e m s p e c i f i c t o e a c h Command
dnscmd <CommandName> /? -- FOP h e l p i n f o on s p e c i f i c Command
SANS Institute
DNSLINT.EXE can perform a variety of DNS-related tests and produce a

summary report in HTML format (KB321045). In particular, the tool can verify
that the necessary SRV records for Active Directory exist and that DNS
delegation is working properly. It can also test DNS, POP3, SMTP and IMAP
servers as specified in a configuration text file.
DNSDIAG.EXE runs only on Windows Server 2003 or later and is a Resource

Kit tool. The tool’s purpose is to run through the same DNS queries that your e-
mail server uses in order to deliver SMTP mail. Use this tool when SMTP
gateways are failing because of DNS misconfiguration issues.
On any machine hosting the DNS service, there is an Event Viewer log just for
DNS for the sake of auditing and troubleshooting.
ce r
Performance Monitor has over 60 counters for charting and logging DNS activity,
including counters for queries, zone transfers, dynamic updates, etc.
SANS institute
- No more zone transfers.

- No more primary-secondary distinction.
- All DNS servers must be domain controllers.
DNS zone data can be stored either in text files or in Active Directory. When stored in
AD, each record is stored and replicated separately as an AD object-- the entire zone file
itself is not stored as such.
When zone records are stored in AD there are a number of benefits:
NS Replication Topology: An independent DNS replication

topology does not have to be implemented. DNS data is piggy-backed on top of
multi-master AD replication. This simplifies planning and troubleshooting.
No Single Point of Failure: Because there is no single DNS primary --any server
can receive updates-- there is no single point of failure.
Permissions on NS Records: Each DNS record is an object in AD, and as such

each record can have its own permissions, owner and audit settings.
Secure Dynamic Updates: Along with Kerberos authentication, permissions on

DNS records can be used to implement a system for secure dynamic updates.
More Efficient Replication: Only the changed properties of individual DNS

records are replicated, not entire zone files. And domain controllers are designed
to multi-master replicate vast quantities of data in a reliable and speedy way. This
makes replication of large numbers of DNS record changes more efficient.
i
SANS Institute
An AD-integrated DNS server can still act as a primary DNS server to non-AD-
integrated DNS servers, Microsoft's or otherwise. An AD-integrated DNS server cannot
be a secondary.
To store a DNS domain's data in AD, right-click on that domain in the DNS snap-in >
Properties > General tab > middle Change button > select Primary Zone > check the box
labeled "Store the zone in Active Directory" > OK.
: To import or change a large number of DNS records, switch an AD-

integrated zone to become a standard primary. This will cause a standard zone
text file to be created. Modify this file as desired, then switch the zone back to
AD-integrated. This will import all the records from the zone file into AD.
SANS Institute
SSEC
Windows Server 2008-R2 and later supports Domain Name System Security Extensions
(DNSSEC) as specified in RFC 4033,4034 and 4035. DNSSEC allows authentication
and integrity verification of DNS response data in order to combat spoofing and man-in-
the-middle attacks against DNS traffic. This is accomplished, in part, by signing zone
data (RSA public key encryption of SHA-1 hashes, using 512- to 4096-bit RSA keys)
using the DNSCMD.EXE command-line tool.
However, this course does not cover DNSSEC for the following reasons:
DNSSEC and dynamic updates are incompatible. (Hence, every time a DNS
record is added, deleted or modified, the zone must be signed with
DNSCMD.EXE again. If DNS records are stored in AD, the records must be
exported to a zone file, digitally signed, then re-imported again.)
Only Windows 7, Server 2008-R2 and later are DNSSEC-aware. Windows

2000/XP/2003/Vista/2008 systems ignore DNSSEC-related options.
Even when a Windows DNS client (i.e., a stub resolver, not a DNS server) is
DNSSEC compatible, like Windows 7, the client does not itself validate any
DNSSEC records or responses. DNS clients simply rely upon a flag being set in
the response from the DNS server to indicate that the information was validated
by the DNS server. To authenticate the DNS server and its responses, clients
must use IPSec.
The command-line switches and batch scripts necessary for DNSCMD.EXE, the
main DNSSEC configuration tool, are too numerous to adequately cover here in
the time allowed. And the Group Policy options or DNSSEC are not easily
discussed until after the Group Policy day of the course.
DNSSEC will most likely be deployed only on your public DNS servers which host the
DNS records of your Internet-exposed servers and which handle forwarded queries from
your internal DNS servers.
When a significant portion of the other DNS servers around the world are impleinenting
DNSSEC too, this courseware will provide further coverage of the topic. In the
meantime, if you would like more information about DNSSEC, please download
Microsoft’s how-to whitepaper: Domain Name System Security Extensions (best to
Google for it, the URL may have changed).
SANS Institute
The de facto standard DNS server on the Internet is the Berkeley Internet Name Domain
(BIND) DNS server (http://www.isc.org). Many organizations have extensive BIND
infrastructures already in place with BIND-savvy administrators to manage them; for
these organizations, interoperability with AD and Microsoft DNS is a critical issue.
Strictly speaking, only the support of SRV records is absolutely necessary for AD
compatibility, and SRV records are available with BIND versions 4.9.7 and 8.1.1 and
later. Hence, you don’t have to use Microsoft DNS servers at all.
Microsoft recommends that Unix BIND servers be version 8.2.2-P5 or later. BIND 8.2.2
supports SRV records, dynamic updates, fast zone transfers, negative caching,
incremental zone transfers and DNS security extensions. Make sure to use the latest
version of BIND, though, due to other security issues (at least version 9.4.0).
: During the installation of Active Directory, Windows creates a text file

named NETLOGON.DNS in \%SystemRoot%\System32\Config\ which shows all
of the SRV records the server requires. This file can be used to check that SRV
records have been updated correctly, or it can be used to manually import these
records into non-Microsoft DNS servers. Note that this file is only created when
AD is installed, and it is not updated thereafter.
SANS Institute
-
eroperabiIity Scenarios
The following interoperability scenarios are possible:
Unix primary DNS zone transfer into a Microsoft standard secondary.
Microsoft standard primary zone transfer into a Unix secondary.
Microsoft AD-integrated zone transfer into a Unix secondary. The Unix machine
only requires that the Microsoft DNS server support zone transfers; it doesn't
have to know or care that the data is ultimately corning from AD.
Having Unix DNS servers be authoritative for a parent domain (e.g., SANS.ORG)
and Microsoft DNS servers be authoritative for a child domain (e.g.,
CORP. SANS.ORG).
Having Microsoft DNS servers be authoritative for a parent domain (e.g.,

SANS.ORG) and Unix DNS servers be authoritative for a child domain (e.g.,
CORP.SANS.ORG).
Configuring a Microsoft DNS server to forward its queries to a Unix DNS server.
The Microsoft DNS server might be a caching-only server.
Configuring a Unix DNS server to forward queries to a Microsoft DNS server.

The Unix DNS server might be a caching-only server.
However, the following scenarios are not possible:
Unix primary DNS zone transfer to a Microsoft AD-integrated secondary.

Besides zone transfers no longer being used, an "AD-integrated secondary" is a
contradiction since there is no such thing.
Requiring secure dynamic updates on the BIND DNS server from Windows
clients. Windows clients use a different form of secure dynamic update.
If you have a Unix DNS infrastructure, and your Internic-assigned domain name is
mycornpany.com, then create a subdomain for the Windows network named something
like ad.mycompany.com. The Windows DNS servers can be authoritative for just that
zone, while leaving the rest of the Unix DNS infi-astmctureintact. When a hostname
cannot be resolved, the Windows DNS servers can be configured to forward their queries
to the Unix DNS servers.
When an AD-integrated DNS server is switched to become a standard primary, its

records are written to a standard zone file. This zone file can be modified as desired, then
reimported into AD by converting the zone back to being AD-integrated. Alternatively, i
the data from this zone file can be merged into the zone file on a Unix DNS server.
SANS institute
0
Windows Server 2003 and later DNS servers support a feature called “conditional
forwarding”. In Windows 2000 DNS you forward all requests or none, but in Windows
2003 and later you can set different forwarding options for each DNS domain namespace.
For example, you might configure your DNS server to never forward queries except 1)
when the query is for an AD domain in another forest, in which case forward the queries
to the DNS servers in that other forest, or 2) when the query is for specific BIND-
managed domains in one’s own environment, in which case forward the queries to those
BIND DNS servers.
ic es
BIND 8.x supports RFC 2845 secure dynamic updates involving the use of shared secrets
for Transaction SIGnatures (TSIG). Windows DNS servers and clients do not support
this, but instead use a different form of secure updates (GSS-TSIG). Hence, BIND DNS
servers cannot require secure updates from the Windows clients, and non-Windows
clients using RFC 2845 secure updates cannot securely update Windows DNS servers.
However, Windows clients can use regular (insecure) dynamic updates with BIND
servers, and non-Windows clients can do the same with Windows DNS servers.
If you allow regular (insecure) dynamic updates to your BIND DNS server, then 1)
ensure that the firewall blocks updates to the server from the Internet, 2) configure the
named.conf file on the DNS server to restrict the range of IP addresses from which clients
are permitted to use dynamic updates using the “allow-update” statement, and 3) consider
only permitting updates from the Windows DHCP server and allow it to perform updates
on behalf of all clients.
iles S
It is possible to take the zone and configuration files from a Unix BIND server and use
them on a Windows DNS server. The zone files themselves can simply be copied into
the %SystemRoot%\System32\Dns\ folder and used as-is. Make sure to configure the
relevant zone to be a standard primary or secondary.
€!S S
On the Advanced tab of the server’s property sheet there is a “Load Zone Data On
Startup” pull-down list. If “From File” is selected, the Windows DNS will look for a file
named boot.dns in the %SystemRoot%\System32\Dns\ folder. This file can be a renamed
copy of a named.boot file from a BIND DNS server. However, the file must use the
older BIND 4.x format, not the newer 8.x format. Windows DNS does not support
version 8.x named.boot files. For configuration options not found or not supported in the
boot.dns file, the server will query the registry.
1
SRV records require the underscore character in hostnarnes. The underscore character,
however, was not supported in the original RFCs for DNS. A BIND 8.x DNS server,
SANS Institute
therefore, must have the “check-names ignore” statement in the named.conf file for the
zone used by AD. This permits underscore characters and other non-standard hostnames
required for AD.
There is a related configuration option on the Advanced tab of a Windows DNS server’s
property sheet. There is a pull-down menu there labeled “Name Checking”. This
determines how Windows DNS will handle different character sets in DNS records as
required for international language support. The options are:
Strict RFC (ANSI) -- Strict enforcement of RFC 1123 syntax.
Non RFC (ANSI) -- Permit hostnames not compliant with RFC 1123.
Multibyte (UTF8) -- Permit non-US-ASCII Unicode characters.
All Names -- Permit any of the above.
The default is “Non RFC”, which is more-or-less the Windows equivalent of the “check-
names ignore” setting in BIND. If you select another option and a record is processed
which does not conform to the name checking rules, the data is considered to be in error
and is discarded. Do not choose “Multibyte” except when non-US-ASCII characters
must be supported, e.g., in Asian countries.
Note that RFC 2181 updates RFC 1123, and extends the naming convention for labels to
include any binary string, which includes underscore characters.
eco
For more information about BIND integration, see the following articles (locate them by
their titles through Google, their URLs change frequently):
Microsoft article, “Configuring Berkeley Internet Name Domain (BIND) to

Support Active Directory”.
KB 198408, “Microsoft DNS Server Registry Parameters”
Microsoft whitepaper, “Using BIND DNS Servers with Windows 2000”.
Chapter 7 of Building Enterprise Active Directory Services: Notes from the Field
(Microsoft Press: 2000). This chapter is a case study of a pure BIND 8.2.1 DNS
system for a Windows 2000 network. It includes examples of how to configure
named. conf for the DNS daemon.
SANS Institute
Windows DNS servers also support a type of record, SRV records, which are required for
Active Directory. The purpose of SRV records is to identify available services, the
protocol(s) they are available on, the port numbers they are using, the FQDN of the
systems hosting them, and to provide load-balancing information. The following are
examples of SRV records:
1dap.-tcp.sans.org SRV 0 100 389 boxl.sans.org
kerberos.-udp. sans.org SRV 5 1 0 0 88 box2.sans.org
1dap.Itcp.dc.-rnsdcs.sans.org SRV 1 1 0 0 389 box3.sans.org
-kerberos.-tcp.Site1.-sites.dc.-msdcs.sans.org SRV 0 1 0 0 88 box4.sans.org
The general format of a SRV record is the following:
-sewice.grotoco1.domainnarne SRV priority# weigh# port# FQDN
-service -- This hostname identifies the service available, e.g., LDAP

server Cldap), Kerberos KDC Ckerberos), Global Catalog server
Cgc), or Kerberos change password Ckpasswd).
grotocoZ-- This domain identifies the protocol used, e.g., TCP or

UDP .
priority# and ~ e i --gThese

~ ~numbers are used for load-balancing.
A client will choose the server with the lowest priority. If multiple
SANS Institute
servers have the same priority, then the client will choose one of them
at random, with the probability of choosing a particular server
proportional to its weight.
port##-- This identifies the TCP or UDP port number where the service
is available.
FQDN -- This is the fully qualified domain name of the server hosting
the service in question. Another DNS record (an A record) will map
the FQDN to the actual IP address.
Other SRV records include the Globally Unique ID number (GUID) of the server. This is
used when clients know the GUID of the server, but the server has moved to a new DNS
domain. An example of a SRV record with a GUID is the following:
b86b6e29-ecb5-4b81-9d3d-bb9ec6lebf68_msdcs.sans.org SRV 0 1 0 0 389 boxl.sans.org
S Servers?
There has been a lot of speculation about whether Windows will continue to use SMB,
NetBIOS and WINS servers. Windows will continue to use SMB (or "CIFS", if you
want to be tricked by Microsoft's marketing gurus), but this no longer requires NetBIOS
or WINS.
It is possible to turn off NetBIOS entirely. By default, Windows will use both SMB with
NetBIOS and SMB without NetBIOS in parallel. SMB with NetBIOS operates on TCP
port 139. SMB without NetBIOS operates on TCP port 445 and is sometimes called the
"Common Internet File System (CIFS)" (KB204279). But beware, you may have other
software that requires NetBIOS, such as older versions of Exchange.
10s
You can disable the use of NetBIOS for TCP/IP session support. This can be done for all
machines through a DHCP scope option or on each machine manually.
Keep in mind that the elimination of NetBIOS will not be a security panacea. Many
vulnerabilities ascribed to NetBIOS were actually the product of the SMB protocol and
the Server service. For example, null user sessions are a feature of SMB. Windows will
still use SMB, the Server service, named pipes, remote registry access, Full Control for
the Everyone group, etc. Even if you eliminate NetBIOS you could still be vulnerable to
good-old-fashioned null user session attacks.
To disable the use of NetBlOS sessions, open the "Network and Dial-up Connections"
window > Local Area Connection > Properties > Properties of TCPllP > Advanced button
z WINS tab > "Disable NetBlOS Over TCPlIP" radiobutton.
SANS Institute
However, if you wish to completely eliminate all NetBIOS support whatsoever, then
you’ll have to stop the NETBT.SYS driver itself. One way to do this is in Device
Manager > View menu > select Show Hidden Devices > Non-Plug and Play Drivers >
right-click NetBIOS Over TCPIP > Properties > Driver tab > set the Startup Type to
Disabled > reboot.
You can also disable the NetBIOS driver from the command line with SC.EXE. Query
the status of the driver with “ s c .exe qc n e t b t ” , and set it to disabled with
“sc.exe c o n f i g n e t b t s t a r t = d i s a b l e d ” (to get back to defaults, set
“ s t a r t = s y s t e m ” instead). Note that this will also prevent the TCP/IP NetBIOS
Helper service from starting.
__
SANS Institute
- Can update DNS records on behalf of machines that

don't support MS secure dynamic updates, e.g.,
Linux, Mac, Windows SxlMelNT, etc.
Windows supports dynamic updates (RFC 2 136) and secure dynamic updates (IETF
Draft "GSS Algorithm for TSIG" and RFC 2078, but Microsoft secure updates do not
follow RFCs 2535 or 2137). Dynamic updates permit DNS records to be changed
automatically when a client's IP address changes, instead of requiring an administrator to
change the client's records by hand. Secure update requires Kerberos authentication.
Hence, clients or DHCP servers which do not support Kerberos will not be able to use
secure updates.
Windows systems can update their own address (A) records, and rely up DHCP servers to
update their reverse lookup (PTR) records. Legacy systems rely upon their DHCP
servers to update all their records for them.
A primary DNS server supports dynamic updates, but secure updates are possible only
with AD-integrated DNS servers. This is because these updates are secure in virtue of
the permissions set on the records themselves in AD. The default permissions allow any
authenticated user to create a new record; once created, that user, and only that user, will
have full control over the record (administrators still have control of course). If two
systems have the same FQDN, the second one to attempt the secure dynamic update will
fail.
Note: Make sure the clocks between the client, DHCP server and DNS server are
synchronized to within 5 minutes of each other for the sake of Kerberos.
SANS Institute
When DNS records are stored in AD, a separate access control list of permissions can be
applied to each record individually. Permissions are generally left at their defaults for the
sake of secure dynamic updates, which rely on these permissions for authorization.
To see DNS records in AD and edit their permissions, use either "AD Users and
Computers" or "ADS1 Edit" in the /System/MicrosoftDNS container. Before the records
can be seen in AD Users and Computers, though, you must enable the viewing of
"Advanced Features".
If !
To edit the permissions on a DNS record in AD, open the "AD Users and Computers"
snap-in > right-click on your domain > View > Advanced Features > expand your domain
> System > MicrosoftDNS > your domain name > right-click a DNS record > Properties >
Security tab.
Keep in mind that any DNS record with Read access for the Everyone group will be
visible to anonymous hackers on the Internet. Write permission is necessary to update
the record. With secure dynamic updates, a domain member has the permission to add
and modify its own record, but it cannot change the records of other machines.
Administrative users, of course, have permission to change any DNS record they wish.
Secure updates can be required by the Windows DNS server on a per-zone basis.
If 1
To require secure updates on a domain, right-click on that domain in the DNS snap-in >
Properties > General tab > Allow Dynamic Updates? > select Only Secure Updates.
If secure updates are not required, then any client can change any record. This is because
non-secure updates are always attempted first, even if the client is capable of secure
updates. If your DNS servers are accessible from the Internet, then hackers can change
your mission-critical records to redirect clients to the wrong mail servers, web servers,
DCs, etc. Because of the centrality of DNS, corrupted DNS records can seriously disrupt
network services.
A Windows DHCP server can update DNS records on behalf of clients who cannot do so
for themselves. Indeed, even Windows clients rely upon their DHCP servers to update
their reverse lookup (PTR) records for them, even though these clients can update their
own address (A) records with their DNS servers directly themselves.
#I
To configure your DHCP server to perform updates for clients, right-click on IPv4 in the
DHCP snap-in > Properties > DNS tab > check boxes labeled "Enable DNS dynamic
updates according to the settings below" and "Dynamically update DNS A and PTR
records for DHCP clients that do not request updates".
SANS Institute
The following screenshot is from the DHCP snap-in, not the DNS snap-in.
Tip: In a Unix BIND environment, have the Windows DHCP server always
update DNS records on behalf of DHCP clients, then configure the named.conf
file on the DNS server to allow-update only from the DHCP server itself.
NSUpdateProxy Group
If a DHCP server createshpdates DNS records for a client, then the DHCP server owns
that record in AD: only that one particular DHCP server can change it. This can be
inconvenient if the DHCP server becomes unavailable or if the client is upgraded to
Windows (in which case the client should become the new owner).
However, if the DHCP server is added to the DNSUpdateProxy global group, then the
DNS records it creates will have no owner. The first client to modify or update the
record becomes its owner and will have exclusive control over it like other dynamic
records. (Add the computer to the group with "AD Users and Computers" just as you
would add a user to a group. You are adding the System account of the DHCP server to
the group by doing this.) DNSUpdateProxy is a built-in group which has this capability
designed into the operating system; there is no user right named "Create Ownerless
Object" or anything similar to be configured.
Important: If the DHCP server is a member of the DNSUpdateProxy group,

then the DNS records it creates are not secure. Anyone who updates or modifies
these records becomes their owner with exclusive control over them. This
includes the DNS records of the DHCP server itself!
SANS Institute
Since the DHCP server updates its own DNS records, then the DHCP server's DNS
records may not be owned and exclusively controlled by the DHCP server itself. Hence,
after the Windows DHCP server updates its own DNS records, change the permissions on
its DNS records to give it exclusive control, or, if the DHCP server is running Windows
Server 2003 or later, configure DHCP dynamic update credentials.
arning! If you install DHCP on a domain controller and you add the server to
the DNSUpdateProxy group, then that DC's DNS records are not protected.
Either do not install DHCP on a Windows 2000 DC, or manually change the
permissions on the Windows 2000 DC's DNS records to give the DC exclusive
control/ownership of them. If the DC is running Windows Server 2003 or later,
however, then you should set dynamic update credentials.
pdate Credentials (Windows Server 2003/2008 and

Windows Server 2003 and later DHCP servers can be configured to use a hard-coded set
of credentials with which to authenticate to a dynamic DNS server for the sake of secure
dynamic updates on behalf of the clients obtaining IP addresses from it.
This feature should always be used, but it is especially important if the DHCP service is
installed on a domain controller because of the ownerless DNS records issue discussed in
the section above concerning the DNSUpdateProxy group. It may also help to limit the
damage caused by a malfunctioning or attacked DHCP server when that server is a
domain controller.
The same credentials can be used on all DHCP servers in the forest. The account used
should be added to the DNSUpdateProxy group, but it should not be added to any
administrative groups. The account should be secured like any other service account.
SANS Institute
On a Windows Server 2003/2008 or later system running the DHCP service, create a
global account named “DnsUpdateCredentiaIsForDhcp”and add it to the
DNSUpdateProxy group. Next, open the DHCP snap-in on the DHCP server > right-click
the server > Properties tab > Advanced tab > Credentials button > set the username,
domain and passphrase > OK > OK.
Because the account will not be a member of any administrative groups, it’s OK to give it
an obvious/descriptive name. However, because the account is likely to be forgotten,
give it a passphrase of 20+ characters and set its passphrase to never expire.
CP Audit Logging
It’s important to enable audit logging in DHCP so that link-layer MAC addresses can be
mapped to IP addresses (and ultimately to computers and people) for the sake of incident
response and forensics. To enable logging in the DHCP snap-in, right-click the
IPv4/IPv6 container > Properties > General tab > check the box “Enable DHCP audit
logging”. To change the default folder where the logs are stored, see the Advanced tab
on that same property sheet.
alues S
There are a few registry values related to hostname resolution that should be mentioned.
QueryIpMatching
Hive: HJSEY LOCAL MACHINE

Key: \System\CurrentControlSet\Services\DnsCache\Parameters
Value Name: QueryIpMatching
DataType: REG DWORD
Data: 0 or C(defau1t is 0)
When QueryIpMatching is set to 1 on a system, the system will only accept DNS
resolution replies from the same IP address of the DNS server originally queried. Hence,
if a computer queries a DNS server at 10.0.0.1, then the client will only accept query
responses from 10.0.0.1. Setting this value will help to prevent the poisoning of the
hostname cache on the computer. This value is not related to “DNS cache poisoning” on
DNS servers however.
isableDynarnicUpdate
Hive: HKEY LOCAL MACHINE

Key: \System\CurrentControlSet\Services\Afd\Parameters
Value Name: DisableDynamicUpdate
DataType: REG DWORD
Data: 0 or c(defau1t is 0) 1
This registry value can be used to disable dynamic updates entirely on a client or server,
preventing that machine from attempting to update its DNS records.
SANS Institute
egister ecords
Hive: HKEY LOCALMACHINE

Key: \System\CunrentControlSet\Services\Netlogon\Parameters
Value Name: RegisterDnsARecords
DataType: REG DWORD
Data: 1 = register (default), 0 = do not register
The RegisterDnsARecords values determines whether a domain controller should attempt

to dynamically register its records related to being a domain controller (all the records
found in the Netlogon.dns file). This value only relates to DCs. Disabling dynamic
updates entirely also disables these.

Key: \Syste&\CurrentControlSet\Services\Afd\Parameters
Value Name: UpdateSecurityLevel
DataType: REG DWORD
Data: 0x00~00000(default), 0x000000 10, or, 0x00000100
This value controls how clients attempt to update their own records on their DNS servers.
The default (0 in decimal) configures the client to attempt insecure update first, then
secure update if necessary. Setting the value to 0x00000010 (16 in decimal) will cause
the client to use only insecure updates. Setting the value to 0x00000100 (256 in decimal)
will cause the client to use only secure updates.
SANS Institute
The following items summarize the security best practices for DNS discussed so far.
Block all access from the Internet to your internal DNS servers.
Use a hardened DNS server outside the firewall or in the extranet for Internet
clients. The Internet-accessible DNS server(s) should only have the few essential
records necessary for your e-mail, FTP, HTTP and other public servers.
Configure internal DNS servers to forward their queries to the external DNS
servers for the resolution of FQDNs on the Internet. Don't allow internal DNS
servers to directly query other DNS servers around the world.
Have more than one external and internal DNS server for load balancing and fault
tolerance. DNS is particularly vulnerable to DoS attacks. Avoid connecting all
DNS servers to the same segment, switch or router since this creates an
unnecessary single point of failure.
Be cautious of which DNS servers you choose to forward queries to if you don't
control them. Do you trust those DNS servers? Are they hardened and monitored
boxes? Consider doing your own iterative queries if you can't trust the DNS
servers of your ISP.
SANS Institute
Use the "Secure cache against pollution" option on the Advanced tab of the
property sheet of the DNS server if it is exposed to the Internet. Internal-only
DNS servers can leave this box unchecked, but only if they only query other
internal DNS servers. Best to use the option on all DNS servers.
Disable zone transfers on both internal and external DNS servers. If it is required,
only permit zone transfers to selected IP addresses.
Update the root hints information on your DNS servers performing iterative
queries and periodically check that they are current and unmodified.
Use Active Directory-integrated zones on internal DNS servers, but not on

external Internet-accessible servers.
Require secure dynamic updates on internal DNS servers. Disable dynamic

updates entirely on external or Internet-accessible DNS servers.
The DNS records of critical systems (such as mail servers, domain controllers,
web servers, etc.) should be protected by assigning them restrictive AD
permissions so that only Administrators can edit them. Don't forget to enable AD
auditing of changes to these records too.
Require IPSec authentication for all intranet DNS traffic to confirm that clients
are connecting to the real DNS servers. Especially require IPSec authentication if
you use zone transfers.
Configure DHCP dynamic update credentials, especially when the DHCP service
is hosted on a domain controller.
Enable debug logging when bugs or attacks are suspected. In paranoid

environments, the logging can be enabled continuously as long as the
performance penalty and drive space requirements are satisfactory.
Enable the "Netmask ordering" option on the Advanced tab of the property sheet
of the DNS server to slightly optimize network traffic. This is not a security
issue.
After verifiing that all services and applications will not fail, try to uninstall
WINS and disable NetBIOS (tyy, because you may have to re-enable it again if
something breaks). Disable NetBIOS in any case on servers which are directly
accessible from the Internet. Block all incoming and outgoing NetBIOS traffic at
the perimeter firewall.
SANS Institute
And, of course, apply the latest Service Packs and patches.
iscellaneous
Examine the hosts and lmhosts files on computers suspected of being
compromised. Malware often modifies these files.
Don't forget to save the contents of the DNS hostnarne cache on machines before
they are imaged for forensics purposes: "ipconfig.exe /displaydm > a:\file.txt".
User Performance Monitor or other scripts to track the accessibility and health of
DNS servers. If DNS has problems, Active Directory and everything else has
problems too. DNS is the forgotten Achilles Heel for many network services.
To Disable Zone Transfers

AD-integrated DNS servers can still act as primaries for regular secondary DNS servers.
Remote users, including hackers, can still use the NSLOOKUP.EXE utility to list all
records in a domain too (1s -d targetdomain.com.). To control which secondaries and
NSLOOKUP users can obtain resource records, the property sheet of each domain in the
DNS snap-in includes a Zone Transfers tab.
You can disable zone transfers and NSLOOKUP listings entirely by unchecking the box
labeled "Allow Zone Transfers". The Name Servers tab will list all DNS servers which
are authoritative for the zone, including other AD-integrated DNS servers and non-AD
secondary servers. The Notify button is used when the DNS server is acting as a primary
to a non-AD secondary DNS server.
To disable zone transfers entirely, right-click the desired zone > Properties > Zone
Transfers tab > uncheck the box labeled "Allow zone transfers".
SANS Institute
Controlling zone transfers is important because hackers will attempt to download all
records from your DNS servers in order to discover which IP addresses are in use and to
better guess what is hosted on each server (hostnames typically indicate the major
service, e.g., www, ftp, pdc). Hackers can find out the IP addresses of the two official
Internic-registered DNS servers for your domain(s) by doing a whois lookup at
http://www.networksolutions.com.
If you are using AD-integrated DNS zones (which is recommended) and no non-AD
secondaries, then disable zone transfers entirely. If secondaries are in use, then permit
zone transfers only to the other servers on the Name Servers tab or control by IP address.
Use NSLOOKUP with the listing command ("1s -d domainname.com.") to test whether
your DNS servers are promiscuously revealing zone data.
DNS activities can be logged to a text file for troubleshooting or security analysis.
!
To enable DNS activity logging, go to the Properties of the DNS server in the DNS snap-
in > Debug Logging tab > check the desired activities to be logged > OK.
SANS Institute
The DNS activities that can be logged include the following:

Query -- queries received from clients.
Notify -- notification messages received from other DNS servers.
Update -- dynamic updates received from other computers.
Questions -- the question section for each DNS query message processed.
Answers -- the answer section for each DNS query message processed.
Send -- number of DNS query messages sent.
Receive -- number of DNS query messages received.
UDP -- number of DNS requests received over a UDP port.
TCP -- number of DNS requests received over a TCP port.
Full Packets -- number of full packets written and sent by DNS.
Write Through -- number of packets written through and back to the zone.
The default location for the DNS log is \%SystemRoot%\System32\dnsV)ns.log. You

can change the folder and filename, as well as the size. Once the log file reaches its
maximum size, logging will wrap around and start writing at the top of the file.
Secure Cache Against

DNS cache poisoning is a type of attack in which bogus query responses are sent to a
DNS server in an attempt to overload and/or "pollute" the server's cache of DNS records.
For example, a hacker might pollute a DNS server's cache with the incorrect IP addresses
for popular websites. f
Any unsolicited DNS replies your server receives are automatically dropped, no
configuration required (KB24 1352). This prevents a certain type of DNS cache
poisoning where an attacker sends DNS replies with incorrect information, even though
the DNS server never sent a query for this data in the first place.
SANS Institute
Another anti-poisoning option must be enabled manually. If the "Secure Cache Against
Pollution" option is enabled, when your DNS server queries another server, and that other
DNS server returns additional records outside of the DNS domain of the data requested,
then your DNS server will drop the additional records. For example, if your DNS server
queries another server for the IP address of www.sans.org, and that other DNS server's
reply includes records for www.microsoft.com, then your DNS will not include the
www.microsoft.com records in its cache.
If !
To enable partial protection against DNS cache poisoning, go to the Properties of your
DNS server in the DNS snap-in > Advanced tab > check the box "Secure Cache Against
Pollution".
The "BIND Secondaries'' option is when there are older versions of BIND (e.g., 4.9.4)
being used as secondaries. These older versions use a different format for zone transfers
than newer versions. Windows DNS uses the newer fast zone transfer BIND format by
default.
"Netmask Ordering" will arrange the answers in the DNS server's responses such that the
IP address(es) of the answers most similar to the clients will be placed near the top of the
answers list. Clients typically use the answers in order from top to bottom. This helps to
optimize the overall performance of the network because clients tend to connect to
servers closest to them on the network.
SANS Institute
._
The “Name Checking” list permits the control over hostname syntax and character set
verification. Hostnames can be required to be RFC 1123 compliant or not, and UTF-8
Unicode characters are also supported for international character sets.
SANS Institute
Congratulations! You have finished the course!
Thank you for attending this seminar, and please complete the evaluation form. Your
feedback plays a important role in the development of fbture courses and the editing of
this current one.
Thank You!
SANS Institute
If you have never installed an AD domain controller, follow these steps to install Active
Directory on your test computer. If you wish to use VMware or Virtual PC, that is
perfectly fine.
I
Windows Server is installed as a non-domain controller first, then Active Directory

Services are installed when the machine is promoted to become a domain controller
(DC). Active Directory (AD) can later be uninstalled to make the system a non-domain
controller again. Promotion and demotion do not require reinstallation of the operating
system.
Note: If you are installing AD on a lab computer which is not connected to a

network and is not a virtual machine (VMware or Virtual PC), you may need to
install the "Microsoft Loopback Adapter" if you experience networking problems.
This virtual adapter is installed using the Add/Remove Hardware applet in
Control Panel. Double-click the "Add/Remove Hardware" applet in Control
Panel > Next > select Yes > Next > select "Add a new hardware device" at the
bottom > Next > select "Install the hardware that I manually select from a list
(Advanced)" > Next > select "Network Adapters" > Next > select "Microsoft" on
the left-hand side and "Microsoft Loopback Adapter" on the right > Next > Next
> Finish. Now find your Loopback Adapter in your Network Connections applet
I
in Control Panel and configure that adapter with an IP address (10.1.1.1) and set
both DNS servers for that adapter to be your own IP address (10.1.1.1).
On Windows Server 2008, open the Server Manager console in the Administrative Tools
folder in the Start menu. Right-click on the Roles container > Add Roles > check "Active
Directory Domain Services" > Next.
SANS Institute
I
Ab select Server Roles
Click Next.
I
Active Directory Doniain Services
Click Install.
SANS institute
Confirm Installation Selections
Installation Progress
Notice that you have to run DCPROMO.EXE now. Click Close.
SANS Institute
Run "dcpromo.exe" in a command shell or at the Run line > check the YJse advanced
mode installation" box > Next.
1COme tQthe OiRaQrY

w i n Sewices r ~ ~ t ~ l l ~ ~ j o ~
{AD US)on this sewer. making the sewer an

r ~ d o r domain
f contmller To continue, click IJed
p IJse advanced mode tnstaiiation

L a m mare about t h addtional
~ options that are
avzrlable 111advanced mode ifistallation
More aboir: M i v e U,redow C a m n Sewices
Select "Create a new domain in a new forest" > Next.
SANS institute
Invent a DNS name for your domain, but don't choose "corp.sans.org'l, choose a name
unique to you, such as 'Ifirstname.Za.stname.com". Click Next.
Namethe Fbrest Rwt Domian

The first domain m the forest IS the forest mot domain its name ISalso the name of
the forest
Invent an appropriate NetBIOS name for your domain, but don't choose "SANS", choose
a name unique to you, such as "LASTNAME". Click Next.
SANS Institute
Domain NetBiOS Mane

This IS the name that users of eadier vemons of Wmdows will use to tdsnlfifthe
n w doman
Choose the "Windows Server 2008" forest Eunctionality level from the pull-down menu.
Click Next.
Make sure to leave the "DNS Server" box checked, or check it if it's unchecked. The first
domain controller you install in a forest must be a Global Catalog server and cannot be a
read-only domain controller (RODC). Click Next.
SANS Institute
You don't need to assign a static IPv6 address, but you do need a static IPv4 address at a
minimum (such as 10.1.1.1, netmask 255.0.0.0). Also, make sure that your primary DNS
server in your network adapter card settings is your own IP address. Click Yes to
continue, then Yes again if prompted with a warning message. Don't worry about the
warning here, they can be fixed and usually fix themselves after first reboot.
This computer has one or more nehvork adapters without any static IP
address setbngs, If a network adapter has both IPv4 and IPv6 enabled,
then both IPv4 and IPv6 addresses should be statically assigned. Otherwise,
either the IPv4 or the IPv6 address should be stat~callyassigned far the
nebwork adapter, Assigning s t a k IP addresses ensures reliable Domain
Name System @NS) operation. If you do not configure the I F address
setbngs to be statically assigned, then when the dynamically assigned IP
addresses change, dients may not be able to contact this domain controller
and any delegabons that point to the previous IP address(es) will stop
workng.
Do you want to assign a static IP address to one of your nehork adapters

now?
ues
...,.,...,.,-...,......._....
Accept the default folder locations. Click Next.
SANS Institute
Location for Database. Log Files. and SYSVOL

Speaiy the folders that ill contain the Mrve D,r&ay domain contmller
database. log files. and SYSVOL
Assign a password you won't forget. Click Next.
Directory Services Restom Mode Administrator Passarrord
Click Next.
S A N S Institute
Check the "Reboot on completion" box and wait.. . It will reboot.
Congratulations, you're now a domain controller!
Log on as Administrator and look in Start Menu > Programs > Administrative Tools to
find your Active Directory management tools.
SANS Institute
Active Directow 177
..
User groups have become more flexible (and more complicated) in Windows 2000 and
later. There are new factors to consider, all of which affect how groups can be used.
Each of the following affects group membership:
Universal Groups
Native Mode vs. Mixed Mode
Distribution vs. Security Groups
iversa S
A new type of group in Windows is the "universal group". Universal groups are
enterprise-wide groups. Universal groups can contain users and global groups from any
domain in the forest, but they cannot hold local groups. The purpose of a universal group
is to collect users from many different domains into one group for the sak
rights and permissions (and sending e-mail).
Universal distribution groups exist in mixed mode environments, but uni

groups only exist on native mode DCs (see below).
!
niversal group, open "AD Users and Computers" > domain > Users. Right-
click on Users > New > Group. Select the "Distribution" radiobutton (unless you are in
native mode) and then select "Universal". Enter a group name > OK.
X I
I
II
..... .- .
I .. .- .....
......
Depending on the mode of the DCs, different group options are available. The following
summarizes the essential facts:
NT 4.0 grouping options are still available in both mixed and native mode, but
more options become available in native mode.
S A N S Institute
All group types can be created in either native or mixed mode, except that
universal security groups cannot be created in mixed mode. Universal security
groups are available only in native mode.
ution vs. Security Groups

A "distribution group" is an e-mail list to be used by e-mail applications and servers. (In
Microsoft Exchange these are called "distribution lists".) A distribution group cannot be
assigned rights or permissions. A local, global or universal group can be flagged as a
distribution group. Hence, when specifjling group types it is now necessary to say
"distribution local group'' or l'security local group" or "distribution global group" and so
on.
Note: It does not affect a user's total time to log on to be a member of a

distribution group. A user can be a member 1000 distribution groups and his or
her logon time will be the same. It does not affect his or her Security Access
Token or the PAC in their Kerberos tickets.
Because distribution groups cannot be assigned rights or permissions, the various options
for distribution group memberships will not be discussed here.
A ''security group" can be both 1) assigned rights and permissions, and 2) used for e-mail
distribution lists. In NT 4.0 these were just called "groups", not "security groups".
Local, global and universal groups can be security groups.
The following points summarize the options for security groups in native and mixed
modes:
In native mode, a local security group can contain another local security group.
In native mode, a global security group can contain another global security group.
In native mode, universal security groups can be created.
In native mode, universal security groups can contain any other type of group,
including other universal groups, except for local groups. A universal group
cannot contain any type of local group in either mixed or native mode.
Except for the additional native-mode options listed above, the same NT 4.0 group
membership rules apply in Windows 2000 with respect to the domains from which
members are drawn. For example, you cannot add a local group from a remote domain to
a local-domain local group, and global groups cannot contain users from remote domains.
Universal groups, by design, can contain members from many domain simultaneously
(but still cannot contain local groups from anywhere).
Strategy for Universal Groups

Because universal groups are enterprise-wide, they are in the Global Catalog and
replicated to every domain and DC. When a user logs on, his or her universal groups
memberships are checked by querying the Global Catalog.
SANS Institute
roblem
But because universal groups are a part of the Global Catalog, frequent changes to
universal groups will cause high amounts of replication traffic between domains.
Domains are often separated by slow and expensive WAN links.
Solution
Universal groups should only contain global groups, not individual users. Once
these global groups are in place, hopefully they should not have to be changed
often. The members of the global groups themselves can be changed at will
without penalty for the Global Catalog because global group memberships are not
held in the Global Catalog. The names of local and global groups are replicated
via the Global Catalog, but not their memberships.
Also, universal groups do not have to be used to assign rights and permissions to users
from remote domains. Just like in NT 4.0, a local group can contain a global group from
a remote (trusted) domain. Hence, use universal groups only when it is too inconvenient
not to do so.
S?
When a user or computer logs onto the domain, a Security Access Token (SAT) will be
created for the user/computer which contains the Security ID (SID) numbers for that
account and all the security groups of which that account is a member. A SAT also
contains a list of rights a user has on the system. The SIDs in the SAT are compared
against the permissions on resources when the user/computer tries to access them. This is
how permissions are enforced. The rights in the SAT are checked whenever a
user/computer attempts to perform a task which requires a special right, e.g., change
system time or perform a tape backup.
S S ?
An OU and its contents exist in Active Directory. Objects in AD have access
permissions (discussed later). Permissions grant or deny access on the basis of SID
numbers. When attempting to read or change objects in OUs or AD, the objects'
permissions are compared against the SIDs in the user's SAT. The SIDs in a user's SAT
are determined, in part, by the groups to which the user belongs.
s 0 s?
The following summarizes the purpose of each group and the best practices for working
with them. Except for universal groups, little has changed here fi-omNT 4.0.
1. User accounts should be placed into global grou s based on job description,
shared need or geographical location. A user can be a member of multiple global
groups simultaneously.
2. Global groups from multiple domains should be placed into a universa
whenever all these global groups need to have the same rights or permissions
assigned to them. Universal groups can also be used as e-mail distribution lists
for selected users from multiple domains.
S A N S Institute
3. For each resource which requires permissions assigned to it, one or more local
groups should be created which have these permissions. Local groups should
also be created whenever a custom selection of rights needs to be assigned to
users.
4. Place globalhniversal groups into local groups so that these globalhniversal
groups can inherit the rights and permissions assigned to the local groups. The
purpose of local groups is to organize globalhniversal groups for the sake of
efficiently distributing rights and permissions.
In a small- or medium-sized network, the above group strategy may be overkill.

However, in a large network, especially with multiple administrators in remote locations,
creating and documenting a "group infrastructure" such as the above can reduce chaos
and help to maintain security.
SANS Institute
The default authentication protocol in Windows 2000 and later is no longer NTLM, but
Kerberos V5. This means that, whenever possible, Kerberos authentication will be
negotiated between client and server instead of NTLM, but NTLM is still available for
backwards compatibility. Virtually all communications between domain controllers and
member computers is authenticated with Kerberos. Kerberos offers a number of benefits
over NTLM.
os S
Kerberos enjoys the following benefits over NTLM:
Kerberos is faster than NTLM and consumes less bandwidth. NTLM is an W C -

based protocol, while Kerberos uses UDP (for the most part). NTLM requires
pass-through of authentication traffic to a domain controller; Kerberos clients, on
the other hand, can reuse their locally-cached tickets for many hours and can send
them to servers without the necessity of those servers contacting any domain
controllers.
Kerberos uses mutual authentication, NTLM only authenticates the client.
Kerberos can be used with Smart Cards for two-factor authentication (PKINIT)
where the TGT is encrypted with the user's public key.
Kerberos credentials can be forwarded or "delegated", while NTLM supports only

standard one-hop impersonation. This assists distributed applications enforce
user-based access control and supports auditing of that user at each server.
Kerberos is an RFC 1510 standard, hence, it offers the potential for

interoperability with non-Microsoft hosts, such as Linux.
However, Kerberos authentication traffic can be "sniffed" and a brute-force attack can be
mounted to attempt to reveal the user's password. This is possible because, ultimately,
the user's master key is derived from the user's password, and this key is used to encrypt
sniffable data during the AS Exchange (see below). As always, strong password policy is
required.
A Kerberos sniffer for Windows is Kerbcrack (http://ntsecurity.nu/toolbox/kerbcrack/).
s
There are a variety of tools and Group Policy settings related to Kerberos, especially for
Unix integration. Some are installed with CD:\Support\Tools\Setup.exeon the Windows
SANS institute
CD-ROM, some come from the Windows Server Resource Kit,and others must be
separately downloaded from Microsoft. If a tool seems to be missing, please check that
you have the necessary software installed.
TRAY.EXE (Resource Kit)-- Shows a taskbar icon for displaying and

purging Kerberos tickets. Ticket flags, lifetimes, and other details are shown in a
user-friendly format.
KLIST.EXE (Resource Kit)-- Command-line tool for displaying and purging

tickets one-by-one. Shows the raw hex ticket flag fields.
NETDOM.EXE (Support Tool) -- Command-line tool which can 1) join a

computer to a domain, 2) manage computer accounts, 3) establish trust
relationships, including trust links to non-Microsoft Kerberos realms, 4) verify
and test NetLogon secure channels, 5) manage the transitivity characteristic of a
trust relationship.
SETSPN.EXE (Resource Kit)-- Manage the Service Principal Names (SPNs) of

Kerberized services running on hosts with computer accounts in AD.
Recommended Reading
For more information about Kerberos, see Appendix C of this manual and also the
following documents:
A gentle and humorous introduction to Kerberos:

http://web.mit.edu/kerberos/www/dialogue.html
"The Moron's Guide To Kerberos":

http ://www.isi.edu/gost/brian/security/kerberos.html
The official MIT web site for Kerberos:

http ://web.mit.edu/kerberos/www/index.html
A Kerberos FAQ:
http://www.nrl.navy.mil/CCS/people/kenh/kerberos-faq.html
"Windows 2000 Authentication: Under The Hood'':

1027,2398-6-100-
http://activeanswers.compaq.com/ActiveAnswers/Render/l,
225-1,OO.htm
"Windows 2000 Kerberos Authentication":

.a
http://www.microsoft.com/windows2OOO/techinfo/howitworks/security/kerberos
SP
"Answers to Frequently Asked Kerberos Questions (KJ3266080)":

http://support.microsoft.com/default.aspx?scid=kb;EN-US;q266O80
SANS Institute
"Forged SID Could Result in Elevated Privileges" and "SID Filtering":

http :/www.microsoft.com/windows2000/techinfo/administration/security/sid~lter
.asp
http://www.microsoft.com/technet/security/bulletin/MS02-00 1.asp
http://support.microsoft.com/directory/article.asp?ID=~;EN-US;Q289243
Information about Kerberos support for the Macintosh:

http://web.mit.edu/macdev/www/kerberos.html
Distributed Computing Environment (DCE) Kerberos V5:

http ://www.opengroup.org/dce/
er S
The following is a list of RFCs and IETF drafts which Microsoft has proposed, extended,
conforms to or to which Microsoft attempts to conform. They are listed here for
reference. Search for drafts and RFCs at http://search.ietf.org.
RFC 1510: Kerberos
RFC 1964: GSSAPI for Kerberos
RFC 2478: SPNEGO
RFC 3244: Windows 2000 Kerberos Change Password and Set Password
Generating KDC Referrals to Locate Kerberos Realms

txt
draft-swift-win2k-krb-referrals-00.
The Windows 2000 RC4-HMAC Kerberos Encryption Type

draft-brezak-win2k-krb-rc4-hmac-04.txt
User-to-User Kerberos Authentication Using GSS-API

draft-swift-win2k-krb-user2user-00.txt
Extension to Kerberos V5 For Additional Initial Encryption

txt
draft-ietf-cat-kerberos-extra-tgt-02.
Extending Change Password for Setting Kerberos Passwords

txt
draft-trostle-win2k-cat-kerberos-set-passwd-00.
Kerberos Change Password Protocol

draft-ietf-cat-kerb-chg-password-02.txt
PUNIT (for Smart Cards)

draft-ietf-cat-lterberos-pk-init-09.txt
SANS Jnstitute
Before diving into Kerberos message exchanges, let's define a few terms and discuss
some implementation details. Note that these terms won't mean much until aft.. the
presentation of the exchanges, so just peruse them now and immediately move on. Extra
detail is added below so you can come back to read this later to fill in the gaps.
ey Distribution Center (
The Key Distribution Center (KDC) is that trusted server or service which issues tickets
and manages keys on behalf of other principals. The KDC is made up of two services:
the Authentication Service (AS) and the Ticket Granting Service (TGS).
Every AD domain controller is a KDC. Keys are stored in AD and multi-master

replicated to all domain controllers, hence, there are no "masterffor ''slave" KDCs. The
AS and TGS services are housed together in the Local Security Authority (LSASS.EXE)
running on each domain controller.
The KDC listens on UDP and TCP port 88 for ticket requests. UDP is used by default,
but TCP is employed when a ticket is larger than 2KB and can be configured, through a
registry modification, to always be used instead of UDP (KB244474).
Authentication Service (AS)

The Authentication Service (AS) is that part of the KDC which issues Ticket Granting
Tickets (TGTs) to access the TGS on the KDC. You authenticate once to the AS for a
TGT with your secret master key at the beginning, then your master key is not used
afterwards until you need a new TGT; this prevents adversaries from sniffing too much
data encrypted with your master key, which would happen if you used your master key
for every ticket request, and optimizes the performance of the KDC, since it will not have
to access your master key for every ticket request you would make afterwards.
Ticket Granting Service (

The Ticket Granting Service (TGS) is that part of the KDC which issues session tickets.
(It also issues TGTs to TGSs in other domains for cross-domain authentication referrals,
but that will be discussed later.) To request a ticket from the TGS to another server, a
client must present a TGT to the TGS.
Ticket Granting Tickets (TGT)

A "session ticket" is what a client presents to a target principal when authenticating to
that principal. A "principal" is just any computer, person, service or thing that can
engage in Kerberos authentication exchanges.
A ticket has a number of fields, but, most importantly, it contains 1) an encrypted

"session key" and 2) an "authenticator". These are discussed below.
A Ticket Granting Ticket (TGT) is just a session ticket to the TGS itself. Clients need a
TGT in order to request more tickets from the TGS, and more tickets are needed if the
client is to authenticate to other servers on the network. The TGS is like any other
SANS Institute
service in that you must present a ticket to it first in order to access resources, the only
difference being that a TGS dispenses Kerberos tickets instead of web pages or e-mail
messages like "regular" servers. What ticket does the TGS expect? The TGT!
er
The "master key" is a symmetric key unique to a particular principal. A user's master key
is derived from that user's password stored in AD, hence, only that user and the domain
controllers have knowledge of the user's master key. Master keys are never exchanged
with other servers besides KDCs. The master keys of computers are derived from their
password hashes, and computers change their passwords automatically on a periodic
basis. The RC4 master key is an MD4 hash of the full case-sensitive Unicode password.
(Note: the Kerberos master key is different than the master key we will discuss in the PKI
seminar for protecting users' private keys.)
essio S
A "ticket" is something a client sends to a server in order to authenticate to that server. It
includes everything the server needs to identify the client and all the groups the client
belongs to (i.e., all of the client's SIDs) so that server can authorize and audit requests
made by the client. This information is stored in the "SID PAC". A ticket also includes
an encryption key shared between the client and the server, but that session key is not
included in the ticket in cleartext. The session key in the ticket in encrypted with the
server's master key, so only the server can decrypt the session key in the ticket.
Hence, a "session key" is a symmetric key shared between two principals for the sake of
mutual authentication. The session key is randomly generated by the KDC when the
client requests a ticket. Two copies of the key are included with the ticket the KDC sends
to the client: one copy is encrypted so only the client can read it, the second copy is
encrypted so only the target server can read it. Upon receipt from the KDC, the client
decrypts its own copy of the session key, creates an "authenticator" with it, then sends the
authenticator and the ticket (which includes the server's encrypted copy of the key) to the
server. At no time is the session key transmitted over the network in the clear.
The KDC sends the ticket to the client instead of the target seilrer in order to optimize
traffic flows and, more importantly, permit the client to cache the ticket. By default, a
client can cache and reuse a ticket for 10 hours!
Windows Kerberos session keys use 56-bit DES-CBC-CRC and 56-bit DES-CBC-MD5,
as well as 56- and 128-bit HMAC-RC4. 128-bit RC4 is the default. However, when
Kerberos is used to exchange keys for encryption purposes beyond authentication, make
sure to install Service Pack 2 or later on Windows 2000, or else 128-bit RC4 will be
unavailable and the encryption strength will automatically negotiate down to 56-bit.
Windows XP/2003 supports 128-bit RC4 for non-authentication purposes by default.
ortant! Make sure to install Service Pack 2 or later on Windows 2000 to

ensure the use of 128-bit keys.
SANS Institute
The Privilege Attribute Certificate (PAC) is a field in a ticket which contains all the
user's Security ID numbers (SIDs) from the global and universal security groups of
which the user is a member. When a ticket is presented to a server, that ticket contains
the user's SIDs PAC, hence, that server can authorize and audit that user's requests. More
formally, with the PAC data a server can construct a Security Access Token (SAT) to
represent the remote user (or computer, if that's who the principal is) and use that token to
impersonate the user locally. A SAT includes all the SIDs for a principal --user, global
groups, universal groups, and local groups-- as well as a list of all the "rights" the user
has on the server's machine, e.g., take ownership right, backup files right, etc. With the
SAT, the server can authorize access to files and services based on access control lists.
The PAC data is digitally signed by the KDC to ensure its integrity and authenticity.
There are Unix compatibility issues related to the PAC as well, but these will be
discussed later (see also the Recommended Reading list above).
uthenticator
An "authenticator" is something a client sends to a target principal to prove that the client
really is who/what the client proclaims to be. The client will have received a ticket to the
principal from the TGS on the KDC, so the client needs to prove to the principal that the
client is indeed in possession of a copy of the session key sent to the principal in the
ticket.
How can you prove to another party that you have a copy of a symmetric key which is
(supposedly) shared only between the two of you, but without sending the key itself?
The answer: encrypt something with that key and send the ciphertext to the other party.
This ciphertext is the authenticator.
The "authenticatorffis some well-formatted data encrypted with a session key shared with
another principal; the data is formatted to include the identity of the client, the KDC's
identity, and a timestamp accurate to within a fraction of a millisecond of the client's
clock. The identities in the authenticator must match the ticket, and the timestamp cannot
be too old (no more than five minutes old, by default).
Additionally, all Kerberos principals keep track of the tickets/authenticators they've

received recently to guard against replay attacks. Hence, within a, say, five-minute
period, if an adversary replays captured tickets and authenticators to a server, that server
will notice that the authenticator is a duplicate. The server doesn't have to keep track of
too many authenticators because they quickly expire.
A "principal" is a user, computer or service which engages in Kerberos authentication.

i
A User Principal Name (UPN) identifies a user. It looks like an e-mail address, but the
domain in the address is the user's AD domain or realm, e.g., in "armin@sans.org" the
i
SANS Institute
username "armin" is an account in AD and "sans.org" is typically the user's AD domain

name (but may be a Unix Kerberos realm instead).
You can actually log onto your desktop with your UPN when you hit Ctrl-Alt-Del!
Administrators can change the default UPN domain name to anything they desire in the
Properties of the "AD Domains and Trusts" snap-in. Hence, my AD domain might be
"sans.org", but an administrator could change my user principal name to
"armin@tanzarian.com"and it will still work fine because the DC will simply do an
LDAP query to find your account in AD.
A Service Principal Name (SPN) identifies a service on a host and optionally its port
number; for example, "MSSQLSERVER/machinel.sans.org:1433" is the SPN for
Microsoft SQL Server listening on TCP 1433 on machine1 .sans.org. Additional names
can be added manually with the SETSPN.EXE tool. The generic computer SPN for
machine 1.sans.org would come in two forms: "HOST/machinel .sans.org" and
"MACHINE 1$@SANS.ORG ".
Assuming that machine1 .sans.org is a domain controller too, its KDC SPN would be
"krbtgt/rnachinel.sans.org@SANS.ORG" or just plain "krbtgt/SANS.ORG". In fact,
there is a global user account on domain controllers named "krbtgt" for the identity of the
KDC, and a derivative of its password is used as the master key for the AS for issuing
TGTs. The password is automatically updated periodically. The krbtgt account cannot
be renamed or deleted.
On a Windows network, the "Kerberos realm" is identical to your "Windows domain",

and the name of your realm is identical to the DNS name of your domain. You will often
see the word "realm" used interchangeably with "domain" when discussing AD.
Note that Windows 2000/XP/2003 does not support Kerberos version 4.
_-
SANS institute
I
.
e
Purpose: The purpose of the AS Exchange is to obtain a Ticket Granting Ticket (TGT).
A TGT is a ticket to the Ticket Granting Service (TGS) itself on the KDC. With a TGT,
the client can request session tickets from the TGS for authenticating to other servers.
1. (KRB AS REQ) The AS Exchange begins with a message from the client to the
- _ .
Authentication Service (AS) on the KDC. This message contains, in cleartext, a

nonce, the client's name and domaidrealm, and the desired server's name and
domaidrealm; in this case, the desired service is the TGS itself on the KDC. The
message also includes an encrypted "pre-authentication data" field. This field is
encrypted with the master key derived from the user's password; its purpose is to
prove to the AS that the client knows the password, and is similar to an
authenticator in that it contains the microsecond timestamp from the client
system. This preauthentication data helps to prevent DoS attacks because the
KDC will simply drop the request if the preauthentication data does not check out
OK.
2. (KRB- AS_ _ REP) The AS replies with the client's nonce and a newly-generated
session key, both encrypted with the client's password-derived master key. The
reply also includes the TGT to the TGS on the KDC itself. The TGT contains the
TGS server's name and realm in cleartext, but it also contains, in encrypted
format, the newly-generated session key shared with the client, the client's name
and realm, the microsecond time on the AS when this TGT was generated, and the
user's SID credentials (the user's "PAC"). All this is encrypted with the master
key of the TGS itself, hence, only the TGS on the KDC can decrypt the TGT.
Whenever the TGT is sent to the KDC, the user's credentials can be extracted
from the TGT itself, hence, the KDC is not burdened with attempting to cache
every user's credentials or having to query AD for them each time.
The Privilege Attribute Certificate (PAC) contains all the user's Security ID numbers
(SIDs) from the global and universal security groups of which the user is a member. The
PAC data is also digitally signed by the KDC to ensure its integrity and authenticity.
Note: The strange "(KRB AS-EQ)" labels are from EFC 1510 to help you map
these descriptions onto the$-otocol definitions in the RFC and in other books.
Tip: You can track AS Exchanges per second in Performance Monitor

(NTDS:KDC AS Requests). You can also track TGS Exchanges per second
(NTDS:KDC TGS Requests) and ClientEerver Exchanges per second to
authenticate to the domain controller from which the performance data is being
gathered (KDCKerberos Authentications). i
SANS Institute
Is e
A computerk keys are stored in the LSA Secrets portion of the registry and a user's keys
are stored in their "credentials cache". The credentials cache is never paged to disk and
is kept in a secure portion of RAM which only the LSA can access. The cache is
automatically purged at logoff. The user can display ticket information or purge their
own tickets with Resource Kit tools like KERBTRAY.EXE and KLIST.EXE.
For example, the following screenshot shows the output of running "KLIST.EXE
Tickets". The second ticket from the top is the TGT from the AS Exchange. The
"Server:" string is the SPN and we can see that "krbtgt" is the desired service, i.e., it is a
ticket to the TGS itself. The tickets look identical because this tool does not show the
flags of the tickets. RC4-HMAC encryption and authentication of the tickets is in use.
:OKLI ST - EXE Tickets

a c h e d T i c k e t s : <4>
S e w e l . : krhtgt/USA.SRNS.ORG@USR.SRNS.ORG
Kei-hTicket Encryption Type: RSADSI RC4-HMRG<NT>
End T i m e : 7/15/2002 15:52:23
Renew T i m e : 7/22/2002 5:52:23
Seiwei.: krbtgt/USR.SRNS.#RG@USR.SRHS.ORG
KevbTicket Encryption Type: RSRDSI RC4-HMRG<NT>
End T i m e : 7/15/2002 15:52:23
Renew Time: 7/22/2002 5:52:23
Seruei.: MEGRLON$@USR.SFINS.ORG
Kei-hTicket Enci-yption Type: RSRDSI RC4-HMAC<NT)
End Time: 7/15/2002 15:52:23
Renerr Time: 7/22/2002 5:52:23
-
S e w e r : ldap/megalon .usa. s a n s oi*g/usa. s a n s .org@USR .SRNS. ORG
K e ~ h T i c k e t E n c i y p t i o n Type: RSRDSI RC4-HMRC<NT>
End T i m e : 7/15/2002 15:52:23
Renett T i m e : 7/22/2002 5:52:23
More details on the TGT are available if "KLIST.EXE Tgt" is run. Note that the raw
hexadecimal of the TicketFlags field is shown.
SANS Institute
:\>KLIST.EXE Tgt
a c h e d TGT :
eruiceName: k r b t g t
aPgetName : k r b t g t
u l l S e r v iceName : Ldmin i s t r a t o r
omainName: USL.SLNS.ORG
argetDamainName: USfi.SLNS.ORG
ItTargetDamainName: USfi .SLNS .ORG
i c k e t P l a g s : 0~40e00000
e yExy irat i o n T i m e : 256/0/29 9 20 0 :100 :8 048
t a r t T i m e : 7/15/2002 5:52:23
ndTime: 7/15/2002 15:52:23
e n e u U n t i 1 : 7/22/2002 5:52:23
imeskew: 7/22/2002 5:52:23
:\>
The KERBTRAY.EXE tool shows the same information, but it also interprets the
meaning of the TicketFlags field. The screenshot below is of the same ticket, but it
shows that this is the initial TGT received from the TGS. The other krbtgt ticket (the first
one on the list) is my copy of my ''forwarded'' ticket that I may send to servers to whom I
wish to delegate my identity. The third ticket (ldap) is for accessing the LDAP port on
the computer named megalon.usa.sans.org, and the last ticket (MEGALON$) is the
Administrator's ticket to the computer (because Administrator is logged on locally).
- -.
_- xi
_.
Client Piiricipal Adminictrator@USA SANS ORG
[USA SANS ORG

krbtgt/USA SANS ORG
rg/usa sans org
oes The xchange Look Li e In The Even ?

If you audit the "Audit Account Logon Events" category (discussed later), Kerberos
ticket exchanges are logged to the Security log. A request for a TGT during the AS
i
I
SANS Institute
Exchange appears as Event ID 672. A failed TGT request is Event ID 676 when the user
name is unknown, and Event ID 675 when the password I s bad.
I Date 7/15/2002 Source Security

~ Tie 3 40 12 PM Categoy Account Logon
j Typ~ SuccessAt Event@ 672
o Lo or
All Kerberos-related events include the IP address of the client involved. This capability
has been sorely desired for years. The event data also show the name of the user or
computer involved, SID numbers, ticket flag options, and ticket encryption type as well.
When Event ID 676 occurs due to logon failure, a "failure code" is also written into the
event message body. The failure codes can be used to further analyze the cause of the
failure, and this information can be extracted by script. The failure codes are:
Code 06 -- Invalid username.
Code 12 -- Workstation or time-of-day restrictions were violated.
Code 18 -- Account locked out.
Code 23 -- Password expired.
Code 37 -- Clock on client's machine too far out of sync with domain controller's.
SANS Institute
Purpose: The purpose of the TGS Exchange is to obtain a session ticket to another
principal --such as an e-mail server-- from the TGS on the KJIC. With a session ticket to
server X, a client can authenticate to server X.
1. (KRB-TGS-REQ) The TGS Exchange message from the client contains, in

cleartext, a nonce, the client’s name and realm, and the desired server’s name and
realm. It also contains the “authenticator”, which is the client’s name, realm, and
microsecond timestamp, all encrypted with the session key the client shares with
the TGS. This session key was obtained when the client received the TGT during
the AS Exchange. Finally, the message also contains the TGT to the TGS (also
obtain’during the AS Exchange).
2. (KRB TGS REP) The TGS replies with the client’s nonce and a newly-
generated session key, both encrypted with the session key obtained with the
TGT. This new session key is to be shared with the other server. The reply
message also includes a ticket to the other server, which is encrypted with the
other server’s master key. The ticket includes the new session key, the client’s
name and realm, the microsecond time on the TGS when the ticket was generated,
and the user’s SIDs PAC. Because it includes the PAC, the target server will
know who the user is and to which groups the user belongs.
ST.E nd E
ISLIST.EXE and KERBTRAY .EXE will show that new tickets have been received. The
name in the ticket should contain the name of the desired server, i.e., the server for whom
a ticket was requested from the KDC.
hat Does The TGS Exchange Look Like In The Event Log?
If you audit the “Audit Account Logon Events’’category (discussed later), Kerberos
ticket exchanges are logged to the Security log. A successful TGS request for a ticket
appears as Event ID 673, while a failed request is 677. The ticket below was for the
computer (MEGALON) where the Administrator was sitting. You must obtain a ticket to
access your own computer (which would be an Event ID 528 action). When tickets are
renewed, this produces events of ID 674. If a ticket request fails because the client
doesn’t support Kerberos, hence, it will use NTLM instead, then Event ID 677 is written.
SANS Institute
Active Directow 193
ote: A good article which discusses the nuances of Kerberos event ID'Sis
http://www.windowsitpro.com/Articles/Index.cfm?ArticleID=20052
SANS Institute
Purpose: The purpose of the ClientlServer Exchange is for the client to successfully
authenticate to the other principal, usually a server, and to convey to that other principal
the 1) SIDs PAC identity of the client and 2) a shared session key.
1. (UU3 AP REQ) The client sends to the target principal the session ticket from
the TGS Exchange and an authenticator encrypted with their shared session key.
The ticket includes the client's name, realm, SIDs PAC, and the server's copy of
their shared session key -- all encrypted with the server's master key. Windows
clients always request mutual authentication, so that flag is also set.
2. (MU3 AP REP) The server decrypts the ticket, extracts the session key, decrypts
the authen&ator with the session key, and examines the timestamps for validity.
Since mutual authentication was requested, the server takes the timestamp from
the client's authenticator, encrypts it with the session key, and sends it back to the
client. This proves that the server has the session key, hence, that the server is in
possession of the relevant master key.
Does The Client

Windows 2000/XP/2003 has built-in Kerberos support for these protocols:
SMB/CIFS (accessing shared folders and printers).
Authenticated RPC (this refers to dozens, if not hundreds, of services).
LDAP (querying and updating Active Directory).
Certificate requests to Windows Certification Authorities.
Secure DDNS Updates (to an AD-integrated DNS server).
HTTP (to an IIS 5.x web server).
IPSec I m
RSVP
Note: Windows Telnet and FTP do not use Kerberos!
But simply using one of the above protocols is not sufficient to invoke Kerberos, e.g., the
other system might not be in a trusted domain or might not be using Windows at all.
Even though Kerberos is the default protocol, its use must still be negotiated between
client and server. This is handled by the Negotiate SSP Package.
egotiate The SS
The "Generic Security Service Application Programming Interface" (GSS-API), defined
in RFC 2078, is intended to shield programmers from the underlying details of the
authentication mechanisms of the operating system.
SANS Institute
A service or application can simply "plug into" a GSS-API authentication package in the
OS and let that package do its work on behalf of the application. From the program's
perspective, it hands an authentication request down through the GSS-API to an
authentication package managed by the OS, that package handles all the details of the
authentication process, then the package returns to the program a goodhad result and
perhaps some credentials.
The authentication package is thus a multi-purpose generic provider of authentication

services to any process or application that needs it. The package is not tied to any
particular application-- it can be used by any application whose designers wish to use the
package. And to get to that package, the application submits requests through the GSS-
API interface.
Windows 2000/XP/2003 does not use GSS-API. However, Windows does use SSPI, and
SSPI is extremely similar to GSS-API in purpose and design.
Security Support
Microsoft's Security Support Provider Interface (SSPI) can be thought of as Microsoft's
embraced-and-extended implementation of GSS-API. Because it has been extended, it is
not the case that code written to the GSS-API can be made to work with SSPI, or vice
versa, without some modification. But if you are familiar with GSS-API, then think of
SSPI as MS-GSS-API.
If an application on computer A uses GSS-API, and an application on computer B uses

SSPI, they can still authenticate to each other if they negotiate the same or compatible
authentication packages. It's the package that does the real authentication work, but the
interface to (GSS-API or SSPI) might be different from machine to machine.
Security Support Authentication

On Windows, an SSPI "authentication package" is a DLL which actually does the low-
level work of authentication. These packages are officially called "Security Support
Providers (SSPs)". All SSPs are accessed through the SSPI.
The four most important SSPs in Windows are:

SChannel: TLSBSL certificate-based authentication.
NTLM: NTLMvl and NTLMv2 authentication.
Kerberos: Kerberos V5 authentication.
Negotiate: SPNEGO negotiation of one of the other SSPs.
The Negotiate SSP is an implementation of the RFC 2478 "Simple and Protected GSS-
API Negotiation (SPNEGO)" mechanism. The NegotiateBPNEGO SSP doesn't actually
perform any authentication itself. Instead, two SPNEGO-enabled hosts will use it to
negotiate which other authentication protocol should be used, i.e., to negotiate which
other SSP should be used.
SANS Institute
Whenever the Kerberos SSP is used in Windows, it is because the Negotiate SSP first
brokered a deal to use it. There is no raw Krb.5 API in Windows like there is in Unix. All
applications and services that wish to use Kerberos simply call on the Negotiate SSP
package in the SSPI. Hence, programs are not "Kerberized" in Windows. Windows
applications are simply modified to use the Negotiate SSP instead of the NTLM SSP!
This is a huge advantage for Windows developers who would like to quickly and easily
"plug into'' Kerberos without rewriting a large chunk of their code base. At the same
time, this drastically limits the portability of other applications that look for a Unix-style
Krb5 interface (because that interface just doesn't exist in Windows).
The default SSP in Windows 2000/XP/2003 is the Negotiate package. Negotiate prefers
Kerberos over NTLM, hence, Kerberos is the default protocol. Moreover, if Kerberos
can be used for a service and the KDC is available, then Kerberos must be used and fall-
back to NTLM will not occur. This restriction is hard-wired into the OS. However, if
Kerberos cannot be used even though the KDC is available --perhaps the other principal
is running Windows NT 4.0-- then NTLMv1 or NTLMv2 will be used instead.
Note: SASL ( W C 2222) with LDAP is supported, but not with other protocols
besides LDAP. SPNEGO is used instead of SASL whenever possible.
Note: For more information about the SSPI, SSP packages, SPNEGO, etc., read
Keith Brown's Programming Windows Security (Addison-Wesley).
oes
Windows machines find their KDCs --their domain controllers-- automatically through
DNS queries for the Kerberos SRV records. The IP addresses of KDCs do not have to be
manually configured on each client and server. DHCP can be used to configure DNS
configuration settings.
Note: DNS SRV records will be discussed in the DNS section of the week.
If a client's regular KDC is down, the client will simply connect to a different domain
controller. Kerberos master keys are replicated via AD, so any domain controller will do.
The ClientEerver Exchange will not result in new tickets in KLIST.EXE or

KERBTRAY.EXE. The client already has its cached session ticket, and the server does
not automatically acquire a ticket to the client simply because the client authenticated to
it.
oes The ClienVServer Exchange Look Like In The

If you audit the "Audit Logon Events" category (discussed later), then Event ID 540 is
recorded for an over-the-network logon. Importantly, this is the same Event ID for both
NTLM and Kerberos authentications, but if you examine the log entries themselves you
will see that the SSP authentication packages listed are different.
SANS Institute
Date 7/15/2002 souice Secuiily

Time 3 33 46 PM Categoy LOQOll/LOQOfi
Typg SuccessAL EventLD 540
Cppulei MEGALON
SANS Institute
A Kerberos client can forward a copy of its own TGT to a server so that that server can
take on the client's identity when accessingfurther servers beyond itself on behalf of the
client. This loaning out of TGTs is called "delegation". But delegation should not be
confused with impersonation, a technique that has been around for years. Let's consider
these issues in detail.
mpersonation Doesn't Su
When an interactively-logged-on user at one computer authenticates to a process on
another computer with NTLM, the remote process "impersonates" the local user by
temporarily taking on the user's identity. This is how NTFS permissions and user rights
restrictions are enforced on the remote system. One's identity consists of one's Security
ID numbers (SIDs).
However, in this scenario, the remote process cannot access further servers as the user,
e.g., if the remote server is an IIS web server, the IIS box cannot log into a back-end SQL
Server with the user's credentials. Impersonation is "one hop only", hence, the user's
identity cannot flow beyond the initial remote server to whom he or she directly contacts.
This limits our ability to authorize and audit user's requests in multi-tier distributed
applications.
For example, when a user authenticates to an IIS web server with NTLM, and the server
needs to access a back-end SQL Server, webmasters will usually hard-code a username
and password into the scripts on the web server for accessing the database server. The
unique identity of the user does not flow through the IIS box to the database server;
instead, everyone accesses the database under the context of the single credentials hard-
coded in the IIS scripts. This drastically limits the authorization and auditing possible on
the database server.
User authenticates as him-
/ \ But IIS authenticatesto database

with hard-coded credentials, not
as the user! Can't delegate!
SANS Institute
le
Kerberos supports impersonation, just like NTLM, but it also supports delegation, unlike
NTLM. "Delegation" is the ability of a process to authenticate to other processes,
perhaps on other computers, as a user which has remotely authenticated to it. Delegation
is "multi-hop impersonation".
In the example above, when a user authenticates to the 11s server via Kerberos, that 11s
server can authenticate to the back-end SQL Server as that user. Moreover, the SQL
Server could now access further back-end systems with the user's credentials as well.
The userk identity can flow from machine to machine as necessary to make the whole
distributed application work. Now, each server in the n-tier architecture knows who is
making each request and can use that information to enforce permissions and audit
behavior on a per-request or per-transaction basis.
Delegation is also needed to make .NET distributed applications secure. Imagine you
have your wireless PDA and you're making a stock trade. Your PDA connects to your
brokerage's server (boxl) which queries a quote machine (box2), then accesses your
trading account (box3), checks your trading/margin restrictions for the desired stock
(box4), contacts your bank to transfer the necessary funds on the fly (boxes 5 , 6 , 7 and 8
on the bank's side), opens a secure channel to NASDAQ and executes your trade (box9).
If necessary, your identity can flow to each of these machines.
Delegation also must be enabled on servers where users are storing EFS-encrypted files
in shared folders. The file server has to be trusted for delegation because it needs to be
able to access each user's roaming user profile.
0
Impersonation is always enabled on Windows NT/2000/XP/2003 systems and cannot be
disabled. Delegation is disabled by default, but can be enabled. Once enabled, a
computer will be able to take on the identity of a remote user when accessing other
machines beyond itself. Strictly speaking, it will be processes running under System
context that will be able to do so.
arning! Only enable delegation on trusted systems. A maliciously-configured

server which supports delegation can impersonate users when accessing other
machines for any purpose whatsoever. A user, in effect, will be giving the server
a copy of the user's TGT and saying, "OK, you can be me now, do whatever you
wish", so it is crucial that the server remain secure.
When a server is trusted for delegation, this means that it can accept a "forwarded" TGT
from the client, i.e., the "forwarded" flag is turned on in the TGT. When the server
submits this forwarded TGT from the client to a KDC in a TGS Exchange for a ticket to
another system, the TGS will go ahead and issue a session key and ticket to the computer
even though its IP address is not the same as the original client. At the same time, the
KDC will verify that the computer is trusted for delegation before issuing the requested
SANS Institute
"_
ticket. Importantly, because the TGT sent to the server has the "forwardable" flag set, the
delegation process can continue through an entire chain of servers.
To enable the processes running as System on a computer to use a Forwarded TGT

from a client to access other machines as that client, right-click the computer's account in
"AD Users and Computers" > Properties > General tab > check the box labeled "Trust
computer for delegation" > OK.
If a process on a computer is running under a service account instead of System, then that
process is still capable of using delegated TGTs. The only difference is that that service
account must be marked as ''trusted for delegation".
To enable a service account to use forwarded TGTs, right-click that user account in "AD
Users and Computers" > Properties > Account tab > check the box labeled "Account is
trusted for delegation" > OK.
The same warning applies here as before. If the process running under the service
account trusted for delegation is malicious, then that process can more-or-less steal one's
identity on the network for as long as the TTL on one's forwarded TGT is still good (and
the default is 10 hours). This is even more dangerous, in fact, because malicious users
have a better chance of getting a service to run under a standard user account than the
System account.
elegation Of ccount's Credentials

All Windows Kerberos tickets have the "forwardable" flag set by default, including one's
TGT from the AS. This is required for delegation. But some user accounts are perhaps
i
SANS Institute
too important to ever allow their identities to be borrowed. For example, if a service
account must be added to the Domain Admins group in order for its daemon to run,
security would be enhanced if that account could not forward its TGT to any other
machine.
!
To prevent a user account from forwarding its TGT to other machines or processes, right-
click that account in "AD Users and Computers" > Properties > Account tab > check the
box labeled "Account is sensitive and cannot be delegated" > OK.
When a sensitive account is denied delegation powers, its TGT will have neither the
"forwardable" nor "forwarded" flags set, hence, the client will not be able to forward a
copy of it to other machines or processes.
The "sensitive" option cannot be enabled on the built-in Administrator account. But
other accounts which have been added to the Domain Admins or Enterprise Adrnins
groups can be marked as "sensitive". Be aware, however, that some management tools
may break if your account cannot delegate its credentials.
SANS Institute
The operation of Kerberos can be fine-tuned to enhance security and interoperability. In

Group Policy Objects linked to the domain container --and nowhere else-- there are
Kerberos options:
Group Policy Object > Computer Configuration > Windows Settings > Security
Settings > Account Policies > Kerberos Policy:
Enforce User Logon Restrictions.
Maximum Lifetime for Service Ticket.
Maximum Lifetime for User Ticket.
Maximum Lifetime for User Ticket Renewal.
Maximum Tolerance for Computer Clock Synchronization.
However, there is no Group Policy option to require Kerberos only and refuse all other
authentication protocols. This would not be practical in any case.
Enforce User Logon Restrictions

If "Enforce User Logon Restrictions" is enabled, the KDC will perform a few checks
before issuing a ticket to a user. The KDC will check that the user's account has not been
deleted or disabled, and that the user has the necessary logon right for the type of access
being requested, e.g., over the network or interactive logon.
The security benefits are clear, but all available documentation this author could locate
does not describe how the user rights checks are performed. Nor did my informal testing
identi@ the specific traffic. Microsoft warns that there is a performance penalty, but it is
enabled by default, so the penalty must be slight (hopefully). The default is enabled.
Recommendation: enabled.
Ticket Lifetimes
Kerberos tickets cannot be cached and reused forever. To determine the appropriate time
to live (TTL) of various ticket types, you must balance security with performance,
especially when DCs are servicing large numbers of clients.
"Maximum Lifetime for Service Ticket" specifies how long cached tickets are
permitted to be replayed to target servers. When the TTL expires, the client will
have to perform another TGS Exchange to get a new ticket and session key to the
desired server. Note that the client's current connections to the target server will
not be terminated when the ticket expires, rather, any m w authenticated
connections will require a TGS Exchange after the relevant cached ticket expires.
The shorter the lifetime, the better the security, but also the worse the
performance of the network as more TGS Exchanges are now required. This must
i
be ten minutes or greater, but not longer than the maximum user ticket lifetime.
SANS Institute
The default is 600 minutes (10 hours). Recommendation: 60 minutes in medium-

to high-security environments, 600 minutes in low-security environments.
ser Ticket" specifies the TTL of the client's TGT.

At expiration, a new TGS Exchange will be performed to renew the TGT's TTL
(not an AS Exchange), but the user will not be prompted for a password. The
default is 10 hours. Recommended: 1 hour in medium- to high-security
environments, 10 hours in low-security environments.
ifetime for User enewal" specifies the absolute

maximum TTL of a session ticket or TGT (even though it says k s e r ticket", it
applies to all ticket types, see KE3232179). After expiration, the ticket cannot be
renewed and a new ticket must be obtained. The default is 7 days.
Recommendation: 7 days.
olerance for Computer Clock Synchronization" determines the

maximum skew between the KDC's and client's clocks after which the KDC will
refuse to issue tickets. The threat is that an adversary may attempt to capture and
replay tickets at a later time. The default is 5 minutes. Recommendation: 5
minutes.
By default, "preauthentication data" is included in the client's initial request to the KDC
during the AS Exchange. The purpose of this data is to prove to the KDC that the client
knows the password (master key) prior to the AS returning a TGT. This is an important
security requirement because, without it, an adversary could request millions of TGTs for
a user and attempt a brute-force key search against them all (the more TGTs retrieved, the
better the odds the brute-force attack will succeed). Also, simply requesting millions of
TGTs is a denial of service attack in itself.
Preauthentication is required by default and can only be disabled on a per-user basis.

Preauthentication cannot be disabled for an entire domain or OU through Group Policy
If large numbers of users need this change, write a custom ADS1 script. Disabling the
preauthentication requirement as a permanent fix, however, is not recommended.
To disable the requirement for preauthentication data on a particular user account, right-
click that account in "AD Users and Computers" > Properties > Account tab > check box
labeled "Do not require Kerberos preauthentication" > OK.
SANS Institute
SANS Institute
Kerberos is an RFC standard, hence, there are interoperability options with non-Windows
systems such as Unix/Linux. The most popular Kerberos implementation is MIT
Kerberos (http ://web.mit.edu/kerberos/www/index.html).
Is Windows Kerberos RFC 1510 compliant? Originally, it was not. However, Paul Hill
and Ted T'SOat MIT worked with Microsoft to develop a cleaner implementation to bring
it more into line, and, at the same time, the MIT folks updated the RFC for Kerberos to
accommodate what Microsoft was trying to do. So, currently, Windows Kerberos is
RFC-compliant. But that doesn't mean 100% interoperability is possible in all cases.
Like the Open Software Foundation's DCE Kerberos, Microsoft puts identifying
information into the PAC field of tickets. This field cannot be processed by MIT or DCE
Kerberos, hence, that data must be ignored by MITDCE principals and Windows
principals have to "map" MIT/DCE principals to domain accounts so that some form of
SIDs PAC data is available to the Windows OS. In the end, though, Kerberos has been
good for Microsoft (better security) and Microsoft has been good for Kerberos (by
making it available to a much wider audience).
ote: See the recommended reading list below to follow up on the RFC
compliance controversy. A good place to begin is MIT's Kerberos FAQ, which
includes a letter from Ted T'so at MIT discussing just this issue
(http://www.nrl.navy.mil/CCS/people/kenWkerberos-faq.html#ntbroken) .
The following summarizes what MIT interoperability scenarios are (not) possible:
A Unix client to a Microsoft KDC is possible. Configure the /etc/krb5.conf file

on the client to point it towards the KDC, then users will kinit with their AD
account. See the KTPASS.EXE tool below to assist in the configuration.
A Windows client to a MIT KDC is possible. This is configured with

KSETUP.EXE, but there are serious scalability and security issues. Not
surprisingly, Microsoft hasn't made it terribly easy or usehl to use any other KDC
besides Microsoft's.
Using a MIT Kerberos realm as an accounts domain, or a MIT Kerberos realm as

resource domain, is possible with explicit Kerberos cross-realm trusts. To create
this, in the "AD Domains and Trusts'' tool try to create a regular external trust
with the MIT realm; it will fail, so a dialog box will appear asking for the
necessary MIT realm information, then it will establish the trust. See the
recommended reading below for the configuration steps (there's more than a few).
The MIT KDC does not use or understand the PAC authorization data in
Microsoft tickets, so user principal names in MIT tickets are transparently
SANS Institute
mapped to accounts in AD (right-click on a user account in AD and select "Name

Mappings").
An AD domain without a Microsoft KDC is not possible. You must use

Microsoft's KDC to have an AD domain at all.
nteroperabiIity Tools
There are tools available from Microsoft for enabling cross-platform Kerberos support:
KSETUP.EXE (Support Tool) -- Command-line tool for 1) configuring a

Windows system to authenticate to an MIT Kerberos realm instead of a domain
controller, 2) manage account mapping froin a local account to a Kerberos realm
account, 3) change the computer's password, and 4) change the user's password in
the Kerberos realm.
KTPASS.EXE (Support Tool) -- Command-line tool for 1) creating a

/etc/krb5.keytab file for a Unix system to authenticate to a Microsoft KDC, 2)
create a security principal in AD for the Unix system, and 3) set the password in
AD for use with the Unix host.
Code Samples (Download) -- There are code samples available from Microsoft
for providing better Unix-to-Windows Kerberos interoperability. Compile these
sample tools on a Unix-flavored system in order to:
find Windows KDCs through DNS SRV record queries,
create user accounts in AD from the Unix host,
changehet passwords on AD user accounts from the Unix host,
search AD for account and Unix-style password information,
create computer accounts for Unix systems, and
synchronize accounts between AD and a Unix system (but not the
passwords).
Download the tools from the page for the article describing them:
"Interoperability With Microsoft Windows 2000 Active Directory and
Kerberos Services" (in the Recommended Reading section below).
ecommended
The official MIT web site for Kerberos:
http://web .mit.edu/kerberos/www/index.html
"Windows 2000 Kerberos Interoperability":

http://www.microsoft.com/windows200O/techinfo/howitworks/security/kerbint.asp
"Research Workshop on Kerberos Interoperability" Video Presentations at MIT:

http://web.mit.edu/pismerenllSR-Summer-2000/msr-presentations.html
"Step-by-step Guide to Kerberos 5 Interoperability":
SANS Institute
http://www.microsoft.com/windows2000/techinfo/planning/security/kerbsteps.asp
"Interoperability with Windows 2000 Active Directory and Kerberos Services":

http ://ms dn .microsoft .com/library/default .asp?url=/library/en-
us/dnactdir/html/kerberossamp.asp
''Microsoft To Publish Details of Kerberos Authorization Data in Windows 2000":

http://www.microsoft .com/technet/treeview/default.asp?url=/TechNet/security/prodtech/k
erberodkerberos.asp
ices 1
While on the topic of Unix interoperability, a related Microsoft toolset called "Services
for Unix (SFU)" is also available (http://www.microsoft.com/windowsserversystem/sfu/).
SFU is free and runs on Windows 2000 Professional and Server, Windows XP
Professional, and Windows Server 2003.
SFU 3.5 was tested for interoperability specifically with Solaris 7 and 8, HP-UX 1li,
AIX 5L 5.2, and Red Hat Linux 8.0.
SFU provides the following capabilities:

Interix IS0 9945-1/IEEE 1003.1 POSIX subsystem, providing over 1900 Unix
interfaces for wide binary and scripts support (not an emulator).
NFS server, client and gateway (cluster-aware active/active sharing, NTFS
permissions translation including setuid/setgid/stickybits emulation).
NIS server and client (up to 64,000 clients to the server).
Telnet server and client.
Password synchronization with Active Directory (source code for the Unix
PAM/SSOD Components is supplied, as are precompiled binaries for Solaris, HP-
UX, RedHat Linux, and IBM AIX).
Name mapping service (associates Unix IDS to Windows SIDs).
KornShell and C Shell.
Per1 interpreter.
300+ standard Unix tools such as grep, awl, sed, tar, cpio, kill, at, etc.
Source code for tools and an X Server can be purchased from http://www.interix.com.
Interoperability goes both ways. Perhaps the most popular tool for integrating Windows
and Unix machines is "Samba" (http://www.samba.org). Samba runs on Unix/Linux
machines to provide services to Windows clients and to make it easier for Unix/Linux
boxes to access Windows servers. Importantly, Samba implements the Server Message
Block (SMB) protocol, otherwise known as the "File and Print Sharing Protocol", for
accessing shared folders, printers and named pipes on Windows hosts.
Samba components that can be installed on Unix/Linux hosts:
SANS Institute
A file and print server for clients using SMB, such as Windows 9x/NT/2000/XP,
which also emulates a Windows NT domain controller for user authentication.
A NetBIOS name server, similar to WINS, which acts as a Master Browser.
SMBFS, a Linux-only filesystem for mounting remote SMB shared folders.
An SMB client for Unix hosts that "feels" like an FTP client.
SWAT, a web-based administration tool for your Samba boxes.
A variety of Windows-ish network administration tools.
There are a number of excellent books on Samba. For a reading list, see
http://samba. org/saiba/books. html
SANS Institute
.
When there are only two domains in one's organization, the second domain must join the
root domain, hence, there will be a direct trust link between them. W e n a third domain
is added, that third domain can join the root directly or it can join the second domain
instead. This affects where the new trust link will be installed.
For example, if the root domain is named SANS.ORG, and the second domain is named
SECOND.SANS.ORG, the name of the third domain will determine who it directly
trusts. If the third domain is named THIRD.SANS.ORG, it will trust the root domain
(SANS.ORG) directly because it will be a direct DNS child of the root.
If the third domain is named THIRD.SECOND.SANS.ORG, it will trust the second

domain directly and the root domain only transitively.
The lines in a tree

diagram represent DNS
naming relationships
and the default direct
trust links created. But
trust links (lines) can be
added at will.
Similarly, if the third domain is named GIAC.ORG, then it will trust SANS.ORG
directly. Not only is GIAC.ORG not a subdomain of SECOND.SANS.ORG, it's not even
a subdomain of the original root, SANS.ORG. This is just fine though. GIAC.ORG can
still join the SANS.ORG forest, download the Schema and the Configuration NC,
replicate the Global Catalog with it, establish a two-way transitive trust link, everything.
The DNS names of AD domains affects which trusts are automatically created. But you
can simply add more trusts at will if you find the automatic ones insufficient. These
manually-added transitive two-way trusts are called "shortcut trusts" and they help to
make "walking the trust path" more efficient.
When two AD domains trust each other, the ticket-granting service (TGS) in each domain
is registered as a security principal in the other domain, and the two domains exchange
interdoinain Kerberos keys with each other. The TGS in each domain can treat the TGS
SANS Institute
in the other domain as just another service that requires authentication, but, once
authenticated, that “service” in the other domain can issue tickets to computers in that
domain. So, once I have a TGT to a KDC in another domain, I can get tickets from that
foreign KDC to access servers in its domain. The foreign KDC trusts my TGT because it
was encrypted with the interdomain trust key shared between our two domains.
Simple Case: Two

When a user in one domain (A) requires access to a server in another domain (B), the
user’s computer sends a request to the user’s local KDC (in A) for the remote server (in
B). The local KDC sees that the desired server is in a different but trusting domain and
issues the user a “referral ticket”. A referral ticket is a TGT for the TGS in the remote
trusting domain. The client reissues the request for a ticket to the server, but this time it
sends the request to the TGS in the remote domain, i.e., the domain which contains the
desired server. The remote TGS accepts the request because the TGT presented to it was
encrypted with the interdomain trust key shared between the local and remote TGS’s. In
effect, an interdomain trust key is like a semi-permanent session key shared between the
two TGS’s.
Complex Case: Multiple

However, even though all domains in a forest trust each other in virtue of their two-way
transitive trusts, it is not the case that every domain has exchanged interdomain trust keys
with every other domain. In fact, a domain in a tree only exchanges interdomain keys, by
default, with its immediate DNS parent to form a b-tree with the Windows root domain at
the top. In a forest composed of multiple trees, the tops of these trees trust the Windows
root domain, i.e., the very first domain installed.
When a client in one domain seeks to obtain a ticket to a server in another domain, the
client’s TGS will check to see if it has exchanged an interdomain key with the TGS of the
server’s domain. If they haven’t, the local TGS will compute the shortest referral path
between itself and the server’s domain. This computation is possible because all domains
in the forest replicate information about their interdomain links through the Global
Catalog. A “referral path” is the chain of TGS referrals a client must walk through in
order to finally get a ticket from the TGS in the domain of the desired server.
The client in domain C will have to follow

the Kerberos referral path through R to get
to the TGS in S to get a ticket to a server in
S. The KDCs in C and R have exchanged
interdomain trust keys. The KDCs in S
and R have exchanged interdomain trust
keys. But C and S have not so exchanged.
SANS Institute
Active Directory 21 1
For example, consider a forest composed of three domains: R, C and S. Domain R is the
Windows root domain, and S and C have each exchanged interdomain keys with R, but
not with each other. Imagine a client in C who wishes to obtain a ticket to a server in S:
1. The client sends a request for a ticket to the server to its local TGS in C. The
TGS in C determines that the server is in S, i.e., in a remote domain. The TGS in
C checks to see if it has an interdomain key with S in order to do a direct referral.
It does not, so the TGS in C computes the shortest referral path to S, and that is
via R. Hence, the TGS in C gives the client a referral TGT to the TGS in R.
2. The client reissues its original request for a ticket to the server to the TGS in R.
The TGS in R checks to see if it contains the desired server; it does not, so it
computes the shortest referral path to S. Now, R and S have exchanged
interdomain keys, hence, the TGS in R gives the client a TGT to the TGS in S.
3. The client issues the same request for a ticket to the server to the TGS in S, which
is the server’s home domain. The TGS in S checks to see if it contains the desired
server, and it does, hence, the TGS in S gives the client a regular session ticket to
the server. The client caches this ticket so the entire foregoing procedure does not
have to be repeated every single time.
Kerberos referrals require time and resources. How could the performance of the
scenario above be improved? If S and C had exchanged interdomain kerberos keys
directly, then there would have been only one referral instead of two (because the step
through the root domain, R, could have been eliminated). That is what adding a shortcut
trust would accomplish.
A “shortcut trust” between two domains in a forest causes the exchange of a Kerberos
interdomain trust key between them.
The double-headed dashed arrow

represents the “shortcut trust”.
Domains C and S have now
exchanged interdomain trust
keys, hence, the referral path is
just directly between them now.
Now, with an interdomain key, the TGS in each domain can issue referral TGTs directly
to each other’s machines without going through any other domains as intermediaries. A
shortcut tiust is one-way, but two one-way shortcuts can be created (like in the diagram
above). Shortcut trusts are also transitive, hence, they can only be created between two
SANS Institute
domains in the same forest. Shortcut trusts simply exist to make Kerberos referrals more
efficient, but they don't really add any new trusting relationships as we understood them
in Windows NT (because C and S already "trusted" each other, they just didn't have an
interdomain Kerberos key).
Shortcut Trust
A shortcut trust is created the exact same way an external trust is created --using the "AD
Domains and Trusts'' snap-in-- except that the other domain must already be in the same
forest.
To manually create a shortcut trust to another domain in the forest, open "AD Domains
and Trusts", right-click the local domain > Properties > Trusts tab > New Trust button.
hen Should Shortcut Trusts Be Created?

Apparently there are no penalties for creating shortcut trusts. Add shortcut trusts
whenever they improve authentication performance. Indeed, adding shortcut trusts would
also cut down on the flood of Kerberos traffic root-level DCs would otherwise be forced
to process.
SANS Institute
.
Even though Kerberos is the default authentication protocol in Windows 2000 and later,
the "Windows NT/LanManager" (NTLM) and "LanManager" (LM) protocols are still
supported for backwards compatibility and for when Kerberos cannot be used, e.g.,
Windows Telnet does not support Kerberos, but it can use NTLM.
When password information is transmitted across the network with NTLM, the password
itself is not sent. Rather, a hash of the password is used as an encryption key for
encrypting a random challenge sent to the client from the server. When the server
encrypts the challenge with the user's password hash, and the result on the server is
identical to what the client returned, this proves that the user knows the password.
ip: You can track NTLM authentications with Performance Monitor on domain
controllers (NTDS:NTLM Authentications).
The AD database and the local SAM accounts database botli store a user's password
information in hashed format. Two hashes are stored: the LM hash and NTLM hash.
so
NTLM comes in two versions: NTLMvl and NTLMv2. They have drastically different
security characteristics. For example, NTLMv1 traffic can be sniffed by LOphtCrack to
extract password hashes, NTLMv2 cannot. NTLMv2 can also be used to derive shared
secret encryption keys between client and server in a way which is much more secure
than NTLMvl (discussed later).
NTLMv2 authentication is supported on the following operating systems:

Windows 95/98 with the Directory Services Client Upgrade.
Windows NT 4.0 with SP4, or with the Directory Services Client Upgrade.
Windows 2000 and later natively.
ic
The LanManager (LM) hash used in NTLMv1 is derived by the following steps:
1. Make the cleartext password 14 characters long by either truncating it or padding --
null characters (blanks).
2. Convert all characters to uppercase. Numbers and symbols are unchanged.
3. Reverse the bits of each character byte.
4. Split the 14-byte string into two 7-byte pieces.
5. Use each 7-byte piece as an encryption key with the DES algorithm to encrypt a
fixed string built into the operating system. This "magic string" is the same on all
Windows computers and is 8 bytes in length (Ox4B47532140232425 hex).
SANS Institute
6. Take the two results of encrypting the magic string with the two DES keys and
concatenate them together. This produces a single 16-byte output. This 16-byte
output is the LanManager hash of the password.
Weaknesses of the LanManager hash that makes it easier to crack:

Passwords longer than 14 characters are no stronger than 14-character passwords
because they are truncated.
Case-sensitivity is lost because the password is converted to uppercase. This
reduces the “keyspace” which needs to be searched to break the encryption
because there are fewer possible characters.
Because the 14-byte password is broken into two 7-byte strings, and these strings
are used to separately encrypt the magic string, this reduces the effective length of
the encryption key from 14 to 7 bytes (a reduction in encryption strength by
orders of magnitude).
If the original password is seven characters or less, this is instantly recognizable
because the second DES key will be all null characters (blanks).
Because no random bytes are added to the hashing process (no “salt”), two
identical passwords will have identical LanManager hashes. This allows an
attacker to use a pre-computed dictionary of LanManager hashes to quickly
search for matches.
When used during NTLMv1 challenge/response authentication, the 16-byte LanManager

hash is padded with five bytes of “0” (zero) characters to produce the 21-byte session
key. This is cut into three 7-byte pieces which are each used as DES-CBC keys to
encrypt the challenge. The three encrypted challenges are concatenated and returned to
the DC as the client’s response. It is a simple problem to “reverse out’’the original LM
hash given the server’s challenge and the client’s response.
The
The NT hash is produced by truncating or padding the password to 14 characters. This
string is converted to Unicode, which preserves the case of the letters. This 14-byte
string is hashed with MD4 to produce a 16-byte output. This output is the NT hash of the
password.
The NT hash is many times stronger than the LM hash because the full password length
is used and case-sensitivity is retained. However, because no “salt” added to the NT
hash, two identical passwords will yield identical hashes, hence, pre-computed
dictionaries of hashes can be used to quickly crack the encryption. Moreover, because
both the NT and LM hashes are used in parallel during NTLMv1 authentication, the
strength of the NT hash is irrelevant in NTLMv1.
For NTLMvl challenge/response authentication, the NT hash is padded with 0’s to create
the 21-byte session key used to DES-encrypt the challenge the same way the LM hash is
used (see above). It is also easy to compute the NT hash from the server’s challenge and
the client’s response, though still much more difficult to crack than the LM hash.
SANS Institute
e io s
NTLMv2 also uses a challenge/response method of confirming the user's password, but it
is much more secure. A summary of the features of NTLMv2 are:
The LM hash of the user's password plays no role whatsoever.
Client input into the challenge (a salt) to prevent chosen plain text attacks. This
prevents the use of pre-computed databases of hashedkeys to speed the cracking.
The client's response is different with each session even if the user's password
stays the same.
Use of MD5 hashing with salt to prevent "reversing out" the raw password hash.
Use of a timestamp to verify that the response is timely.
Client challenge sent to the server to ensure that the server is in possession of the
client's password. Strictly speaking, this is not mutual authentication because a
rogue server could also have the client's password hash, but it is better than
NTLMvl , which made no such check.
The most efficient cracking method is a dictionarylbrute force search of all
possible passwords, which is infeasible for long passphrases.
Man-in-the-middle (MITM) attacks infeasible because of the quasi-mutual
authentication. (If an attacker has the password hash already, why do a MITM?)
Replay attacks infeasible because server's challenge is different each time.
Downgrade attacks can be prevented by registry values that will require NTLMv2
from either the server's or client's side.
LOphtCrack cannot extract password hashes from NTLMv2 authentication
sessions. Nor is any future version expected to be able to do so.
It is compatible with 127-character passwords.
The client's response to an NTLMv2 server's challenge is computed as follows:
Client's Response = HMAC-MDS(K, server's challenge + M) + M
Where K = HMAC-MD5(MD4(password), username + domain)

M = ResponseType + HiResponseType + time + client's
challenge to server + servername + server's domain.
HMAC-MD5 produces a hash that requires a key (K) to compute the hash. Because the
response includes the time and a random challenge to the server, the response is
effectively "salted". When computing K, the "MD4(password)" is treated as the HMAC
secret key.
ote: Because of the use of a timestamp in the client's response, the date and
times on client and domain controller need to be synchronized to within 30
minutes of each other for NTLMv2, and within 5 minutes for Kerberos. Use the
NET.EXE TIME command to synchronize clocks automatically.
SANS Institute
216 Active Directow
Configuring uthentication
Authentication and session security options are set in a registry value named
LMCompatibilityLevel on both Windows NT and Windows 9x clients.

Key: \Systei\CurrentControrolSet\Control\Lsa\
Value Name: LMCompatibilityLevel
Value Type: REG D W O m
Value Data: oto5
LMCompatibilityLevel can be set to a single digit number between 0 and 5. The

following table describes the results of these settings for authentication. (See the second
table below for this value's effect upon session security, i.e., integrity-checking and
encryption.) A domain controller is also a client in that one can log on locally and it can
be used to access network resources. Systems which are not domain controllers only
make use of the client changes specified below.
0 This is the default behavior if the value is not defined. The client will
authenticate exactly as it did before and not use NTLMv2. Domain controllers
will accept NTLMv2 if a client requests it.
1 Clients will attempt to negotiate NTLMv2, but will fall back to LM and
NTLMv 1 authentication when necessary. Domain controllers will accept
NTLMv2 authentication if the client requests it.
2 Clients will use NTLMvl authentication only. Clients will not use LM or
NTLMv2 responses. Domain controllers will accept NTLMv2 authentication if
the client requests it.
3 Clients will use NTLMv2 authentication only. Domain controllers will accept
NTLMv2 authentication if the client requests it.
4 Clients will use NTLMv2 authentication only. Domain controllers will refuse
LM authentication, and accept NTLMv1 or NTLMv2 authentication if the client
requests it.
5 Clients will use NTLMv2 authentication only. Domain controllers will refuse
LM and NTLMvl authentication and accept only NTLMv2.
When in doubt, set LMCompatibilityLevel to one (1) for widest compatibility. This will
still use NTLMv2 when it is negotiated.
The LMCompatibilityLevel value also controls how session security options are used,
i.e., integrity-checking and encryption of data other than passwords. The following table
describes the session security options set by the same LMCompatibilityLevel value above
used for authentication.
0 This is the default behavior if the value is not defined. NTLMv2 session
security is not used.
1 Clients use NTLMv2 session security if negotiated with server. The server can
either be Windows NT or Windows 9x.
SANS Institute
2 Same as 1.
3 Same as 1.
4 Same as 1.
5 Same as 1.
You may also be interested in KB 147706: “How to Disable LM Authentication on

Windows NT”. See KB239869, KB241338 and KB236414 for related information.
v2 ica S er
NTLMv2 support is built into Windows 2000 and later. Nothing needs to be done.
There is also a Group Policy option to require NTLMv2 or Kerberos authentication only,
and to always reject NTLMvl and LM. This will be discussed in the Group Policy
course, but the option is found in the GPO under Computer Configuration > Windows
Settings > Security Settings > Local Policies > Security Options > LAN Manager
Authentication Level. In Windows X P and later, the option is named “Network Security:
LAN Man Authentication Level” instead.
ie 1
The Active Directory Client Extensions (ADCE) upgrade is included on the Windows
2000 CD-ROM OClients\Win9x\dsclient.exe), but the latest version should always be
downloaded fiom Microsoft instead. This is required, in fact, if you wish to install
ADCE on Windows NT 4.0 Workstation with SP6a (ADCE cannot be installed on
Windows NT 4.0 Server). The ADCE was last seen at the following URL:
http ://www.microsoft.com/windows2000/server/evaluation/
news/bulletins/adextension. asp
Also see KnowledgeBase articles KB288358 and KB295166.
Installing the ADCE on Windows 9x/NTW yields the following benefits:
ort. Even if ADCE is uninstalled or not used to log onto a AD

e relevant files are not removed and NTLMv2 will still be available.
reness. Clients will log onto the domain controller closest to them in
the AD site model. Windows 9x clients will also be able to change their password
on the closest DC, but Windows NT Workstation must still find the PDC
Emulator when changing passwords. Beware of this NTW behavior!
ting. Make sure to install the latest WSH too though.
hares provide fault tolerance and load balancing.
ok. Permits edits to AD user accounts in the Windows
address book: Start Menu > Search > For People.
Note that installing the ADCE does not add support for IPSec, Kerberos or Group Policy.
SANS Institute
v2 Session Security
When an RPC session is established with the PKTPRIVACY switch to request data
encryption, the encryption cipher and keysize are negotiated. When NTLMv2 is the
authentication protocol for the RPC channel, the details of the negotiation process can be
managed by you. This capability is important because of the sensitivity of the data being
often sent through these channels, e.g., the NetLogon secure channel is an RPC channel.
Note: For more information about RPC security and the registry values below,
see the sections on RPC in these books: Writing Secure Code, 2nd Edition by
Howard and LeBlanc (Microsoft Press) and Programming Windows Security by
Brown (Addison Wesley). The first covers a wide variety of security topics and
has a more practical orientation, while the second discusses low-level internals.
Key Negotiation
The NTLMv2-enabled client generates a 128-bit RC4 key (the "session key"). The
session key is re-keyed every 8192 bytes of data encrypted with it. The session key is not
based on the user's password, it is generated on the fly. This is the key used for both
encryption and HMAC-MD5 integrity-checking. Integrity-checking can be used without
encryption, but encryption always includes integrity-checking.
The session key is sent to the server after it is encrypted with another key (the "key
exchange key"). This other key is only used for protecting the session key while it is
being sent to the server.
Key exchange key = HMAC-MDS(K, Client's Response)

where K and "Client's Response" are defined above in
the section on NTLMv2 authentication.
The key exchange key is different with every session, is 128-bits long, but it is ultimately
derived from the user's password, hence, password policy is critical for the protection of
encrypted RPC channels as well (when using NTLMv2).
Requiring NTLMv2 Strong Encryption For RPC Sessions

Certain characteristics of your NTLM-SSP-negotiated session can be made mandatory for
the successful negotiation of the session. If these requirements are not met, the session
will fail. There is a registry value for the server-side (NtlmMinServerSec) and another
for the client's side (NtlmMinClientSec) of the session. Both values are set under the
following key (KB239869, KB147706):
Key: HKLM\System\CurrentControlSet\Control\LSAMSVl-0
Value: NtlmMinClientSec, or, NtlmMinServerSec
Type: REGDWORD
Data: Default is zero, but can be any logical-OR combination of:
0x00000010 = Require message integrity (HMAC signatures).
0x00000020 = Require message encryption.
0x00080000 = Require NTLMv2 authentication and session key.
SANS Institute
Active Directow 219
0x20000000 = Require 128-bit RC4 session key.
If 0x00000010, the connection will fail if integrity-checking is not negotiated.

If 0x00000020, the connection will fail if encryption is not negotiated.
If 0x00080000, the connection will fail if NTLMv2 is not negotiated.
If 0x20000000, the connection will fail if 128-bit encryption is not negotiated.
Importantly, these options can be combined through logical-OR. For example, if

NtlmMinServerSec is set to 0x20080030 on the server, then the client must authenticate
with NTLMv2, use 128-bit encryption and integrity-check all messages, or else the
session will not be successfully established in the first place.
mportant! Just because the NTLM SSP enforces these requirements does not
mean that every application or service will use the NTLM SSP (in fact, most will
not, since Kerberos is the default). And it does not mean that every NTLM-
authenticated connection will use its SSP to derive encryptiodintegrity keys. And
it does not mean that every NTLM-authenticated session will use encryption or
integrity-checking for its dataflows at all. These details are up to the original
programmer, and if he or she does not provide a mechanism for adding
encryption, then nothing can be done about it (except to use IPSec).
Also, keep in mind that these settings apply to all applications and services that do
happen to use NTLMv2 for SSP-derived encryption and integrity keys. Hence, beware of
these applications and services breaking when you set security requires too high for their
session peers to support (but usually these peers will be Windows 9x/NT).
v2 Strong Encryption
The registry values above can be set on Windows 2000 and later, but there are also Group
Policy options to configure the same which are easier to use.
ote: This option does not appear in Group Policy Objects on Windows 2000;
however, a Windows 2003/2008 domain controller will show them. You can also
import a template created on a Windows XP/2003 machine into a Windows 2000
GPO, or you can simply edit the template manually, to achieve the same result.
These tasks will be discussed in the Group Policy seminar.
For example, the following screenshot is from a Windows Server 2003 group policy. The
setting is found in the GPO under Computer Configuration > Windows Settings >
Security Settings > Local Policies > Security Options > Network Security: Minimum
Session Security for NTLM SSP Based (Including RPC) Clients/Servers.
SANS Institute
Nelwotk secutity Minimum session security for NTLM SSP based

[including secure RPC] setvets
Requite t4TLMv2 session secutily

Requite 128 bit enctyption
Removing The L
The LanManager hash can be removed from the Active Directory database entirely with a
simple registry change. The LM hash can also be removed from the local SAM accounts
database on Windows 2000 and later workstations and member servers.
Removing the LM hash has two benefits: 1) if the AD or SAM database is captured, the
LM hashes will not exist to be cracked so easily, and 2) it helps to prevent any use of the
LanManager authentication protocol ever again.
Consider the following. Rainbowcrack (http://www.antsight.corn/zsl/rainbowcrack/) is a

free password hash cracking tool that can generate a 24GB precomputed database of
LanManager hashes for passwords 1 to 7 characters in length from a set of 77 characters.
A database of this size cracks 14-character random passwords with 99.9% reliability
because of the weaknesses of the LM hash algorithm. And it does this in seconds, not
days or months, because database searches are much less computationally expensive than
hashing. For example, in one test on a P4-2.8GHz, Rainbowcrack was able to crack five
such 14-character random passwords in just 178 seconds!
Tip: If your password is 15 characters or longer, Windows doesn't store the

correct LM hash of this password anyway. In fact, the LM hash of a 15+
character password indicates that the password is null.
There are a few issues to consider however:

The LM hash is not removed from a user's account until the next time the user
changes his or her password. Hence, it is not the case that all the LM hashes are
simply cleaned out in one shot.
Windows 9x clients without the ADCE installed will not be able to authenticate.
Windows 9x clients will not be able to change their own passwords, even if
ADCE has been installed. Hence, either administrators will have to manage their
passwords for them, or a custom intranet website will need to be made available
to these clients for changing their passwords.
SANS Institute
Macintosh UAM authentication and password change is lost.
Unix PAM authentication and password change is lost (if LM hash is required).
Older third-party network management tools --particularly those which audit or

manage passwords-- may fail when the LM hash is no longer in use.
ote: Install Service Pack 2 or later on Windows 2000 before removing the LM
hash from AD or its local SAM database.
ve
To disable use of the LM hash on Windows 2000/XP/2003, for both the Active Directory
and local SAM accounts databases, you must add two items (a key and a value) under the
"HKLM\System\CurrentControlSet\Control\Lsa\" key:
1) Add a subkey named "NoLMHash", and
2) Add a REG-DWORD value named "NoLMHash" and set the value to 1.
Note that you are not putting the value (the second item) in the subkey just created.
When completed, these two registry paths will exist:
HKLM\System\CurrentControlSet\Control\LsaWoLMHash\
HKLM\System\CurrentControlSet\Control\Lsa\NoLMHash
Notice the "\" at the end of the first item? It is a key! The second item is a
REG-DWORD value set to "l", and they are both at the same level in the registry
hierarchy, i.e., the new value is not in the new key.
ote: Strictly speaking, only the subkey must be present on Windows 2000 and
only the REGDWORD value must be present on Windows XP/2003, but just set
them both through Group Policy or a script and save yourself the administrative
hassles. It will not hurt anything to make both changes (KI3299656).
ve
On Windows XP/2003 there is a Group Policy option named "Network Security: Do not
store LAN Manager hash on next password change" which will accomplish the same
result. It is located under Computer Configuration > Windows Settings > Security
Settings > Local Policies > Security Options.
SANS Institute
-
-..
. . ................... .................. _.-.
..... .I.__. ____ __I...................
.. .... ....... -. .......... .- . '
Network access: Named Pipes that can be accessed anonymously
Metwork access: Remotely accessible registry paths
This will work on Windows 2000, but you cannot create the Group Policy on a Windows
2000 machine directly.
Securing The "Secure Channel"

The NetLogon daemon provides a variety of critical domain-related services. Its main
RPC channel is called the "NetLogon secure channel" or just "the secure channel", but
the NetLogon service handles other dataflows and other RPC channels as well.
NetLogon runs in the Local Security Authority context (LSASS.EXE).
On member machines, NetLogon assembles the list of all trusted domains for logon,
locates domain controllers, handles NTLM authentication of user's domain accounts, and
automatically changes the computer's password periodically. One of the first things a
member server or workstation does when it boots up is to establish a NetLogon secure
channel to a domain controller.
Here is an example of the importance of this channel: Windows 2000/XP workstations

download a copy of the DC's public key certificate through it and encrypt a backup copy
of the user's Master key with it (the Master key helps protect your private keys and other
sensitive data); if the user is unable to decrypt their private keys in the normal way, the
encrypted Master key is sent up to the DC through the secure channel where it is
decrypted and sent back to the client.
Another example: when a user changes his or her own password on their desktop (Ctrl-
Alt-Del > Change Password) the new password information is immediately pushed up to
a DC through the NetLogon channel.
On domain controllers, NetLogon handles NTLM pass-through authentication, NTLM

trust account management, and SAM replication with Windows NT Backup Domain
Controllers (BDCs), and more. I
Note: Microsoft has a detailed article on the behavior of the NetLogon service in
Windows NT (KB266729). Most of this behavior is retained in Windows i
2000/XP/2003, with the important exception that Kerberos is the default
authentication protocol now, but NTLM is still supported.
SANS Institute
In Windows NT 4.0 the RPC-based secure channel did not include authentication of the
server (because NTLM does not support mutual authentication), did not integrity-check
its payload, and did not encrypt its payload except for the initial authentication sequence.
Other than the initial authentication for the RPC session, exactly in what sense this
channel was "secure" is a bit of a mystery. There are hints that the previously-
undocumented-because-of-export-issues SSPI EncryptMessageO function was used to
encrypt password information during DC replication, but these issues are still not
documented well.
ote: NETDOM.EXE and NLTEST.EXE can be used to verify and reset the
secure channel on Windows NT/2000/XP/2003 (KB158148). You can also force
the creation of a secure channel to a particular desired DC.
In SP4 for Windows NT Microsoft introduced a new set of registry values that could be
set to integrity-check and/or encrypt the secure channel (KB183859). These capabilities
were built into Windows 2000/XP/2003 by default and can be managed through Group
Policy. It's important to know about this option in Windows NT for maintaining
interoperability. Also, the NetLogon probably hasn't changed much because of the need
for mixing-and-matching different OS'S in both NT- and AD-based domains.
S
d HMAC integrity-checked. The exact cipher
and hashing algorithm is selected by the underlying Security Support Provider (SSP) that
was negotiated to authenticate the RPC connection, hence, the SSP will either be NTLM
or Kerberos. The details of the session key management are hidden under the SSP's
Security Support Provider Interface (SSPI), but some things can be said.
S
On Windows NT, Service Pack 4 or later permits an administrator to increase the security
of the NetLogon channel. With SP4, all NetLogon channel data can be encrypted and
digitally signed for integrity. This is enabled in the registry under the following key:
HKEY LOCAL MACHINE

\SY STEM\CurrentControlSet\Services\Netlogon\Parameters
There are three values that may be added. Their effects are summarized in the table
below. Notice that the signing or encryption is for out-going packets only.
SANS Institute
remote system support neither option, the

NetLogon connection to it will fail.
But what is the encryption? NTLMv2 not only provides very strong authentication, but it
has an improved scheme for generating session keys for use in sealed RPC channels,
including registry values for requiring 128-bit encryption. Make sure to require
NTLMv2 if you seek to harden the NetLogon channel.
Note: See the section in the manual on NTLMv2 Authentication for more
information about how to require 128-bit session key encryption (IU3239869).
indows 2000M
The same registry values above are valid on Windows 2000/XP/2003 as well. And a
fourth one has been added (REiG-DWORD: RequireStrongKey). These can be set
through Group Policy.
In the local or a domain-based Group Policy Object, secure channel options are found
under Computer Configuration > Windows Settings > Security Settings > Local Policies
> Security Options:
Secure Channel: Digitally Encrypt or Sign Secure Channel Data (Always).

You cannot use this option unless all domain controllers in all trusted/trusting
domains are either Windows 2000/2003 or Windows NT 4.0 SP4 or later, and all
domain member computers must be Windows NT 4.0 SP4 or later.
Secure Channel: igitally Encrypt Secure Channel

This option is best for backwards compatibility.
Secure Channel: Digitally Sign Secure Channel Data (When Possible). This
option is best for backwards compatibility, but man-in-the-middle attacks are
much less likely than generic packet sniffing, so it is more important to attempt to
encrypt the channel. Moreover, whenever the secure channel is encrypted, it is
also always digitally signed.
Secure Channel: Require Strong (Windows 2000 or Later) Session Key. This
option requires that all domain controllers in all trustedltrusting domains be
Windows 2000/2003, and all domain members must be Windows 2000 or later.
Windows NT 4.0, even with the latest Service Pack, cannot be made to support
this option. The details of why this is more secure are unavailable, but it is likely
that the encryption is at least 128-bit RC4. The key is probably derived from the
computer's own Kerberos master key.
Important! Due to now-defunct export issues, Windows 2000 requires Service Pack i
2 or later to support 128-bit encryption. Windows XP/2003 and later supports strong
encryption by default.
SANS Institute
But what about its only being out-going packets that are secure? Is this also true on
Windows 2000/XP/2003? Unfortunately, these details are not documented, and the
persons at Microsoft with whom I spoke just didn't know.. . A tcpdump of the packets
only shows that the payloads are not in cleartext, but this doesn't mean they are
encrypted.
SANS institute

SANS Security 505.1 Securing Active Directory &amp; DNS

Uploaded by

Copyright:

Available Formats

You might also like

SANS Security 505.1 Securing Active Directory &amp; DNS

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

SANS Security 505.1 Securing Active Directory &amp; DNS

Uploaded by

Copyright:

Available Formats

Copyright 02010, The SANS Institute. All rights reserved.

The entire contents of this

V2010 0125 rev1

Some things to remember: 10 = very good, 1 = very bad!

Value of Course Content:

Thank you for your thoughtful consideration,

Eric Bassel, Mason Brown, Stephen Northcutt, and Alan Paller

Document Contact: Jason Fossen (Jason@EnclaveConsulting.com)

Table of Contents ................................................................................................................ 4

DNS Security Best Practices........................................................................................... 160

1 Microsoft Windows Server I httD://www.microsoft.com/windowsserver/

When a KB-number is referenced in the course, e.g., KB188806, this refers to a

cronyms an reviati o 11s

"Planning Active Directory for Branch Office Environments" (Microsoft whitepaper).

evant to this course

Control 1: Inventory of Authorized and Unauthorized Devices

Control 2: Inventory of Authorized and Unauthorized Software

Control 3: Secure Configurations for Hardware and Software on Laptops,

Control 4: Secure Configurations for Network Devices such as Firewalls, Routers,

Control 5 : Boundary Defense

Control 6: Maintenance, Monitoring, and Analysis of Audit Logs

Control 7: Application Software Security

Control 8: Controlled Use of Administrative Privileges

Control 9: Controlled Access Based on Need to Know

Control 10: Continuous Vulnerability Assessment and Remediation

Control 11: Account Monitoring and Control

Control 12: Malware Defenses

Control 14: Wireless Device Control

Control 15: Data Loss Prevention

Control 16: Secure Network Engineering

Control 17: Penetration Tests and Red Team Exercises

Control 18: Incident Response Capability

Control 19: Data Recovery Capability

irectory is the foundational security service in Windows environments,

Physically secure the Active Directory database.

out migration strategies from earlier versions?

Actwe Directory Sites and Services

Remote Sewer dministration Tools (RS

DCPROMO.EXE -- Wizard to convert a server into a domain controller.

nsive troubleshooting diagnostics.

CLONEPRINCIPAL Scripts -- These VBScript scripts use COM+ components to

A popular website for Windows tools is http://www.joeware.net/freetools/, including a

ADFIND.EXE -- Better than Microsoff’s own DSGET or DSQUERY, it’s a

ADMOD.EXE -- Better than Microsoft’s own DSMOD or DSRM, a tool to

ATSN.EXE -- Matches IP addresses to their AD sites, or lack thereof.

0LDCMP.EXE -- A safe way to list or delete old computer or user accounts.

SECDATA.EXE -- Dump the important properties of user and computer objects

UNLOCK.EXE -- Flexible way of displaying or unlocking locked accounts.

PowerShell also provides access to the System.DirectoryServicesclasses in the .NET

Port Number Protocol Description

- UPS & Dual Power Supplies

- Large deletable file in each volume ducate other IT staff and

Though it should be obvious to network administrators who manage security, the

Domain controllers (DCs) should be kept in locked, access-controlled rooms.

Very few network administrators will actually require physical access to DC

Consider installing electronic surveillance equipment to monitor the server room.

Prefer granting access to a DC through Terminal Services rather than through

Backup devices should be kept in locked, access-controlled rooms, and backup

At a minimum, the AD database and transaction log files should be on two

SANS Security 505.1 Securing Active Directory & DNS

SANS Security 505.1 Securing Active Directory & DNS

SANS Security 505.1 Securing Active Directory & DNS