CH 2

Five Key Lessons to
Securing
Directory
Roberta Bragg MCSE, CISSP, Author, Columnist, Speaker, Consultant
YourActive
Chapters
1. Perform a Self-Audit 2. Know and Use Security Tools and Techniques 3. Monitor Active Directory Operations 4. Leverage People and Processes 5. Active Directory Security Maintenance
Sponsored by:
CONTENTS
CHAPTER 2: KNOW AND USE SECURITY TOOLS AND TECHNIQUES .............5 TECHNIQUES FOR MANAGING AD SECURITY ...........................................6 SECURING AUTHENTICATION, DCS, AND DC COMMUNICATION ..................................6 Securing Authentication Via Group Policy .......................................................................8 Hardening Domain Controllers Via Group Policy....................................................... 11 Using Security Templates to Secure Domain Controllers ........................................ 13 Using Group Policy Administrative Templates ............................................................ 14 Hardening Domain Controller Communications Via Group Policy........................ 14 HARDEN DNS..................................................................................................................... 15 Securing DNS Using Placement and Policy.................................................................. 15 Securing DNS Configuration............................................................................................ 16 Securing DNS Using Group Policy.................................................................................. 18 MANAGING DOMAINS AND TRUSTS ................................................................................. 19 MANAGING DIRECTORY OBJECTS .................................................................................... 20 Protect Active Directory by Restricting Group Membership and Understanding Active Directory ACLs............................................................................ 21 Standard and Extended Rights ....................................................................................... 21 Adding AD Classes.............................................................................................................. 23 Modifying AD Default Permissions and Properties.................................................... 24 Assigning Authority for AD Administration................................................................... 24 TOOLS..................................................................................................................25 USING GROUP POLICY TOOLS .......................................................................................... 26 Group Policy Editor............................................................................................................. 26 Understanding and Controlling GPO Inheritance....................................................... 29 Reporting............................................................................................................................... 39 Ensuring Permission Consistency .................................................................................. 41 Backup and Restore........................................................................................................... 42 Managing Backups............................................................................................................. 44 Delegating Group Policy.................................................................................................... 45 GPO Planning and Analysis Modeling............................................................................ 47 Modeling a Group Policy Hierarchy ............................................................................... 47 Determining the Results of Group Policy Implementation....................................... 49 USING SECURITY CONFIGURATION AND ANALYSIS AND SECURITY TEMPLATES ......... 50 USING ADSI EDIT TO MANAGE DIRECTORY OBJECTS ................................................... 51 USING THE ACTIVE DIRECTORY DOMAINS AND TRUSTS CONSOLE ......................................... 53 Selective Authentication .................................................................................................... 53 SID Filtering.......................................................................................................................... 54 SUMMARY ...........................................................................................................55 ABOUT QUEST WINDOWS MANAGEMENT..............................................56 ABOUT QUEST SOFTWARE, INC..................................................................56
Securing Your Active Directory. Chapter 2 - Know and Use Security Tools and Techniques
CHAPTER 2: KNOW AND USE SECURITY TOOLS AND TECHNIQUES

How-tos with an Emphasis on Securing Active Directory
Hardening steps for Active Directory (AD) can be divided into four major categories:
Securing systems on which AD relies such as authentication and

Domain Name System (DNS)
Securing domain controllers (DCs), the computers on which the

AD database resides
Securing communications, such as AD replication and remote

administration, between domain controllers
Securing AD directly using access control lists (ACLs)

Many of the processes and functions used to perform these steps rely on Group Policy, AD administration tools and other common Windows administration tools. This chapter will discuss both the techniques used to harden AD and the how-tos of using these tools.
TECHNIQUES FOR MANAGING AD SECURITY

Security principles for hardening AD:
Use Group Policy and related processes to harden domain

authentication, DCs, and DC communications
Harden DNS Protect DCs and AD by limiting and managing external trusts
and forest trusts
Protect AD by restricting membership in the Schema Admin and

Enterprise Admin groups, and understanding and managing AD permissions
Securing Authentication, DCs, and DC Communication

The majority of settings that impact security for all domain computers can be found either directly within a Group Policy Object (GPO), or can be added via a template to the GPO. Once the GPO is linked to a site, domain or organizational unit (OU), security settings are propagated to the user and computer accounts within that container. Default GPOs linked to the domain controller OU and those linked to the domain object can be used to improve security for DCs and protect AD. In some cases, the use of additional GPOs is warranted. In fact, when making radical changes to security policy, such as adding IPSec policies, a unique GPO should be linked to the domain controller OU. Doing so makes it easier to recover from an incorrectly configured policy. The entire GPO can be deleted, without losing other security settings. Here are a few quick facts about Group Policy that are important in order to understand some of the descriptions coming later:
Password Policy, Account Lockout Policy and Kerberos Policy

settings for the domain must be configured in the Account section of the Default Domain Security Policy. The Account section is shown in Figure 1. Settings made to the Password Policy and Account Lockout Policy sections of the GPO in GPOs linked to OUs will only affect the local member computer accounts for member computers with accounts in those OUs.
Figure 1. Account Policies.
User rights for the domain are configured in the Default Domain
Controller Security Policy. They can also be configured in additional GPOs linked to the DC OU.
Security settings to manage domain controllers should be

configured in GPOs linked to the domain controller OU. Security settings made in GPOs linked to the site or domain object within which domain controllers reside will also have an impact on DC security, as will settings on individual DCs. The rule is that GPOs are applied in the order of local, site, domain and OU-linked GPOs. All settings are merged unless there is a conflict or restrictions, such as No Override, are applied. When conflicts occur, the last setting applied wins. (Those settings applied in the domain controller default security policy should therefore win.)
GPOs linked to domain objects for other domains have no

impact on domain member computers or domain user accounts.
Additional settings that can be used to lock down computers and

provide additional user and computer security are contained in the Administrative Templates section of Group Policy.
Securing Authentication Via Group Policy

Controlling access to domain resources is an important part of AD security and must be managed by having strong authorization and authentication controls. Authentication is the process whereby an entity attempts to prove they are who they say they are, while authorization is the process that specifics what an authenticated user can do. Authorization, in the form of assigned privileges and resource access permissions is critical, but if the authentication process is weak, authorization is weak as well. If administrators with access and privilege throughout systems, domains and forests use simple passwords, it does not matter that they are the only ones who can configure security, manipulate objects in AD or take ownership of any resource. An attacker will soon deduce the password and simply access and control systems as the administrator. If users share or leave passwords vulnerable, it does not matter how few can access some critical resource like customer records. An attacker will obtain the passwords and do damage as authorized users. Strengthen authentication to support sound authorization controls. Five areas must be managed:
Strengthen the password policy or provide alternatives Set a reasonable Account Lockout Policy Maintain a strong Kerberos Policy Reduce or eliminate anonymous access (access that does not
require credentials)
Harden the authentication process

All of these, with the exception of providing alternatives to passwords, can be accomplished using Group Policy in Windows Server 2003. Two areas of Group Policy are used: the Account Policy and Security Options sections. In addition, some password alternatives provide administration via administrative templates that can be added to Group Policy. Pay special attention to the location of the GPO where recommended changes must be made. Many of the appropriate settings for these areas must be set as part of security policy; they will be discussed further in Chapter 4, along with recommendations on strong policies and obtaining management and user buy-in.
Strengthening the password policy will require management approval. Dont forget to discuss the technical and non-technical controls that are part of a good policy. Technical controls are those things that can be implemented in the Windows password policy such as password length and complexity and how often the password must be changed. Non-technical controls are things such as not sharing passwords, not writing them down, and requiring complexity beyond what can technically be controlled by the operating system. When a strong policy is approved, changes should be made to the Default Domain GPO. There can be only one password policy per domain; changes made to the default domain GPO affect all domain accounts. A strong policy should also be required for computers if local accounts are used to authenticate to these systems. Password policies for local computer accounts on domain computers can be set in GPOs linked to the OU within which the computer account resides. The password policy for stand-alone computers (computers that are not members of a domain) should be set in the Local Security Policy. Account Lockout should be set to prevent an attacker from guessing passwords or running automated dictionary attacks against accounts. A number of incorrect entries, whether manually or automatically generated, triggers account lockout. At this point, even a correct password will fail. Lockout can be configured to automatically be released after a time period, or require administrative action. The Account Lockout threshold must be carefully considered. Set too low, it may lock out legitimate users who occasionally fat finger their attempts. It can also be an avenue for a denial of service attack, since an attacker could effectively lock out all accounts by attacking them all. In organizations with strong perimeter controls, opportunities for such attacks may be few, making account lockout viable. By default, Kerberos Policy is correctly configured for most organizations and should be left alone. Two settings that are often modifiedand should not beare Maximum Tolerance for Computer Clock Synchronization and Enforce User Logon Restrictions. The computer clock synchronization time can prevent replay attacks. In a replay attack, the attacker captures valid credentials and attempts to use them to gain access to networks and systems. Kerberos requires that communications from the client not be older than the clock synchronization time. If they are, they are rejected. Lengthening this time weakens this security feature of Kerberos. When the Enforce User Logon Restrictions policy is enabled, each request for a session ticket is evaluated against the target computers user rights policy. If a user is denied the right to log on at the target computer, his request for a session ticket will fail.
Securing Your Active Directory. Chapter 2 - Know and Use Security Tools and Techniques 9
Disabling Enforce User Logon Restrictions may save time and therefore improve performance, but it weakens security. In addition to Account Policy, other areas of Group Policy can impact authentication. These include the policies described below, which are found in Computer Configuration, Windows Settings, Security Settings, Local Policies, Security Options. Policy
Interactive Logon: Require Domain Controller Authentication to Unlock Workstation Network Security: Do Not Store LAN Manager Hash Value on Next Password Change
Recommendation/Description
Enable Prevents an administrator whose account has been disabled from logging on to a DC using cached credentials. Disable Discontinues storage of weak LM hash in the password database. Many password cracking programs attack the weak LM hash and then deduce the stronger NTLM hash. Without the weaker LM hash, these crackers take much, much longer and may not be effective. Set to Send NTLMv2 response, only, refuse LM and NTLM Note: Down-level clients can be configured to use NTLMv2. Windows 9x must install the AD Client and apply registry edits. Windows NT must have registry edits applied. This change in policy may also impact older server applications such as RRAS, and should be tested before being deployed in a production environment. Negotiate signing if some domains require it; require it if all domains require it Secures communications between clients and domain controllers and between domain controllers.
Network Security: LAN Manager Authentication Level
Network Security: LDAP Client Signing
10
Reducing or eliminating anonymous access can be managed via Security Options. Security Options can vary through the domain, but in some cases they only make sense for GPOs linked to the domain controller OU. Security Options that impact anonymous access: Policy
Network Access: Do Not Allow Anonymous Enumeration of SAM Accounts and Shares Network Access: Let Everyone Permissions Apply to Anonymous Users Network Access: Named Pipes that Can Be Accessed Anonymously
Description
Enable Prevents a connection made without an account ID and password from being able to list accounts and shares. Disable Allows anonymous users to have privileges and access granted to the Everyone group. Remove named pipes not used by DCs. For example, the SQL\QUERY named pipe is not needed unless SQL is installed on the DC. Installing SQL on the DC is not a good practice. Shares should be protected by placing explicit permissions on the share and on its root folder. The COMFG share often listed as accessible anonymously can be removed from this setting unless the DC is running the host integration servicea service that would rarely be installed.
Network Access: Shares that Can Be Accessed Anonymously
Hardening Domain Controllers Via Group Policy

In addition to physical security, access to DCs is controlled by settings in several areas of Group Policy. User rights related to DC security include the policies described below, which are found in Computer Configuration, Windows Settings, Security Settings, Local Policies, User Rights Assignment. Policy
Shut Down the System
Remove the right from the Account Operators group and the Print Operators group. Do not allow users permission to shut down DCs. Remove Backup Operators and assign this right to a special group for DCs. Remove Backup Operators and assign this right to a special group for DCs. This group should be different than the group assigned Backup Files and Directories.
Backup Files and Directories Restore Files and Directories
11
Multiple registry entries are exposed in the GUI as Security Options. Many of these settings directly relate to audit checkpoints listed in Chapter 1. Specific settings useful in managing DC security include: Policy
Accounts: Guest Account Status Accounts: Rename Administrator Account Devices: Prevent Users from Installing Printer Drivers Devices: Unsigned Driver Installation Behavior
Disable Rename
Enable
Do not allow installation. If a driver required for DC operation is not signed, temporarily modify this setting, install the driver, and then reenable the setting. Disable
Domain Controller: Allow Server Operators to Schedule Tasks
The Restricted Groups section of the Default Domain Controller Security Policy can be used to control group membership. When a user group is added to the Restricted Groups section of Group Policy, membership in the group is managed by Group Policy. Normally, group membership is managed by administrative groups, either by members of the default Windows administrative groups or custom Windows groups delegated responsibility for group membership. However, once a group is added to the Restricted Groups section of the GPO, the membership of that group is dependent on the list of user accounts added to the group within Restricted Groups. If members are added to AD or domain computer local groups in other ways, the group membership will change to those user accounts listed in Restricted Groups on the next Group Policy refresh. Likewise, if a user is added to a Restricted Group within the security settings of the GPO, the account, if not present in the AD or local computer group, will be added. Tread carefully when using Restricted Groups. It is not advised to manage all groups in this manner, and some even advise against managing any domain groups this way due to potential inconsistencies and excessive replication traffic.
Registry and File System Permissions can be set and maintained

using Group Policy. However, careful testing should be done to ensure that performance does not become an issue. The Security Setting section of a GPO is reapplied periodically (16 hours by default) whether or not changes have been made. If a large number of permissions is maintained, this can significantly impact
12 Securing Your Active Directory. Chapter 2 - Know and Use Security Tools and Techniques
performance. Registry information and files important to operating system operation are permissioned during operating system installation and server promotion to a DC (via Dcpromo). If changes are recommend by Microsoft or internal study to promote security, changes can be rapidly distributed to multiple DCs by using the Registry and File System Permissions section of Group Policy. The System Services section enables centralized control over services enabled or disabled on domain computers. Permissions set here also determine which users and groups can enable, disable, start, stop or set startup characteristics of services. The presence of an enabled or disabled service may impact what a user can do. For example, the Domain Users group may have permission to remotely access the network, but if the Remote Access service is stopped or disabled on a server, users cannot access the server using that service. This area of Group Policy should be used to both disable unnecessary or unauthorized services, and to prevent unauthorized users from changing this status. If left unconfigured, an unnecessary service such as Telnet might be enabled then used to attack a DC, or an attacker might take advantage of services known vulnerability. (Telnet, for example, sends passwords in clear text across the network.) Alternatively, an attacker might disable services required for DC operation, causing a Denial of Service (DoS) attack. Recommendations for which services to disable on DCs is part of the security guides provided by Microsoft and referenced earlier.
Public Key Policies dictate policies such as whether or not certificates will be issued, and if the Encrypting File System can be used. Public Key policy management should reflect organization policy. Software Restriction Policies, if configured, determine what software can run. Policies can either allow all software to run except software explicitly defined as being disallowed, or prevent all software from running except that which is explicitly unrestricted.
Using Security Templates to Secure Domain Controllers

Security templates contain sections of Group Policy Security Settings. A template can be configured to hold security settings for DCs, and even Registry settings not visible within the Security Settings. Security templates can be applied directly to a DC (or any other Windows computer based on NT technology). They can also be imported into a GPO, thus changing the security settings on the GPO.
13
Using Group Policy Administrative Templates

Administrative Templates are an often-overlooked portion of the GPO. Both user and computer settings are contained in Administrative Templates. Their use is even more important on DCs and other servers than on many desktops, since many of the application templates they control are not needed on servers and DCs, but are installed anyway. Use Administrative Templates to harden applications such as Internet Explorer (IE), Windows Media Player and so on.
Hardening Domain Controller Communications Via Group Policy

Communications to and from DCs must be allowed, but there is no reason additional security cannot be used to protect sensitive communications or block unnecessary ones through the following settings.
The user right Deny Access to This Computer From the Network (Add the Guest account and all non-operating system
service accounts used to run local services. There is no reason these accounts should be allowed network access.)
The Security Option Domain Controller: LDAP Server Signing Requirement (Require signing. Protects Lightweight Directory Access Protocol (LDAP) communications between administrative stations and AD. If an attacker captures a packet and modifies it, the signature will vary and the packet will be dropped.)
The IPSec Policy Management section of Group Policy can be

used to implement IPSec policies that affect DC communications. By linking the GPO containing an IPSec policy designed for DCs to the domain controller OU, communications for all DCs can be centrally managed. Policies can be written to block access via specific computers, and/or over specific ports. Negotiation of communications is also possible. An appropriate IPSec policy for DCs is to require authenticated communications. Using authentication certificates can restrict communications to those between DCs, or between DCs and other computers that have been issued certificates from a trusted certification authority (CA). If a rogue computer attempts to communicate with the DC, access will be denied.
14
Harden DNS
AD cannot exist without DNS. Without DNS, clients cannot locate DCs and authenticate to the domain, and DCs cannot locate replication partners, blocking AD changes. If an attacker can compromise DNS, he can disrupt the very backbone of AD and mine DNS for information useful in further attacks. There are three ways to harden DNS:
DNS Placement and Policy Group Policy Restrictions DNS Configuration
Securing DNS Using Placement and Policy

Two useful techniques are split DNS and access policy. Split DNS is a technique whereby only the IP addresses of those servers that need to be accessible from the Internet are exposed in an external DNS server. The IP addresses of servers and other computers that should only be accessible from the internal network are kept in a separate DNS database. For many organizations this may mean that its ISPs DNS is used to list externally accessible Web servers, remote access servers and mail servers, while the organizations DNS server holds all other information and is not accessible to outsiders. In other organizations, the external DNS server may be managed by the organization as well, but IP addresses are still segmented. In still others, Windows DNS is used exclusively for internal Windows computers, while a UNIX server manages DNS for all other systems, including any Windows servers that must be accessible externally. The advantage of separate external and internal DNS servers is that if the external DNS server is compromised, it does not expose the entire network. Access policy is the formal designation that defines which computers are accessible from the Internet. Most security professionals agree that only Web servers, external DNS servers, and the external connections for remote access servers, VPN servers, firewalls and the like should be accessible. All client systemsand most servers should not be accessible.
15
Securing DNS Configuration

DNS services can be further secured by making adjustments in the DNS administration console. The following settings should be used to harden DNS.
Secure DNS Cache Against Pollution. If a DNS server is queried

and does not know an address, it may attempt to find that address by contacting another DNS server. If the address is retrieved, the DNS server will add it to its cache and make it available for future requests. It might be possible for an attacker to therefore pollute the cache by providing incorrect addresses, directing clients to a rogue server or causing a DoS situation if the IP address is unreachable. Securing the DNS cache against pollution can help prevent this, since the DNS server wont cache an IP address that is not received from a DNS server that has responsibility for that domain. This setting is selected on the Advanced page of the DNS server properties pages as illustrated in Figure 2.
Figure 2. Advanced DNS server property settings.
16
Restrict Zone Transfers. When DNS is integrated with AD, DNS

information is replicated as part of AD. If DNS is not ADintegrated, secondary DNS servers should be used to provide alternatives for DNS lookup. Zone transfers are used to keep secondary servers up-to-date. Only approved secondary DNS servers should have the right to request and receive a zone transfer. To restrict zone transfers, add approved computers to the Name Servers property page for the zone or to the Zone Transfers page, select the Allow zone transfers check box, and choose the appropriate option on the Zone Transfers page, as shown in Figure 3.
Figure 3. Zone transfers options.
Configure Local Root Hints, if possible. Root hints provide

references for DNS servers to begin a search for IP addresses. The typical DNS server contains root hints that specify root DNS servers for the Internet. If your DNS infrastructure uses an internal root, configure root hints on other DNS servers to point to this root. This can prevent internal information from going to the Internet. The Root Hints page of the DNS server properties pages is used to configure root hints.
Disable Recursion, where possible. DNS servers that use

forwarders must have recursion enabled in order to perform recursive inquiries for clients. (Recursive queries are managed by the DNS server; they eventually return the answer to the requesting client. In an iterative query, the DNS server returns a pointer to the requesting client, then the client continues the search.) However, if some DNS servers in your infrastructure are not used in this manner, disable recursion to prevent flooding attacks. (DNS servers use iterative responses to communicate with each other.) Recursion can be disabled on the Advanced page of DNS server properties pages.
Securing DNS Using Group Policy

Techniques for securing DNS include hardening the server on which it resides, segmenting internal DNS from external DNS, and configuring security using the DNS console. Group Policy can be used to harden the DNS server. When DNS is AD-integrated, the DNS service runs on a DC and DNS data can be secured within AD. The general hardening techniques used to secure DCs should be substituted for those listed for DNS servers. When DNS is not integrated with AD, it may reside on a separate Windows server or it may not even be Windows DNS at all. (In that case you will need to refer to the hardening techniques specific to your version of DNS and the operating system it resides on.) When the Windows DNS service is installed on a member server, use the general hardening techniques recommended for Windows 2000 Server or Windows Server 2003. The theory behind the white papers is that a general hardening template should be used to tightly lock down all servers, and then a template designed for each computer role should be used to loosen security just enough so the computer can do its job. An infrastructure template is supplied by Microsoft for DNS servers. The recommended way to apply settings is to:
Create a computer OU Create a unique DNS server OU as a child OU of the computer OU Place all DNS server accounts in this OU Import the general hardening security template (use a
Microsoft-provided template or create one of your own) into a GPO linked to the computer OU
Import the infrastructure security template (use a Microsoftprovided template or create one of your own) into a GPO linked to the DNS server OU
If this process is used, any computers in the computer OU or its child OUs will be locked down according to settings in the template as well as settings made in the GPO linked to the computer OU. Before implementing this method, you should determine what additional steps might be needed to ensure that all computers can perform their designated functions. For example, in the general hardening template the DNS service is disabled, but since a special template is applied to the DNS server that enables the DNS service, the DNS server will be able to function as a DNS server. Check out these online Microsoft server hardening resources:
Windows Server 2003 Security Guide

www.microsoft.com/technet/security/prodtech/win2003/w2003hg/sgch00.mspx
Windows 2000 Security Hardening Guide

www.microsoft.com/technet/security/prodtech/win2000/win2khg/default.mspx
Windows 2000 Security Operations Guide

www.microsoft.com/downloads/details.aspx?familyid=f0b7b4ee-201a-4b40-a0d2cdd9775aeff8&displaylang=en
Managing Domains and Trusts

Within a Windows forest, all domains trust each other. While there are unique administrative accounts for each domain, domains are not security boundariesthe forest is. In many organizations there are legitimate reasons for multiple forests, and they may need to communicate and share resources. For many organizations, this sort of resource sharing may also be a requirement for business partners. For these reasons, trust relationships are created between domains from different forests andin Windows Server 2003 forestsbetween forests. For extended information about Windows trusts, please see What are Domain and Forest Trusts at
www.microsoft.com/resources/documentation/WindowsServ/2003/all/techref/enus/Default.asp?url=/resources/documentation/windowsserv/2003/all/techref/enus/w2k3tr_trust_what.asp, It is important that these trusts are created in the
most limited manner that will still fulfill the requirements. This can be done by:
Making the trust one-way when possible. In a one-way trust, one

side of the trust contains resources and is referred to as the trusting domain, while the other side of the trust contains users and is referred to as the trusted domain. Users from the trusted domain can be granted access to resources in the trusting domain. It is one-way because even though the trusted domain can still have resources and the trusting domain may have user accounts, no user from the trusting domain can be granted access to the trusted domain resources.
Limiting trusts to trusts between the specific domains required. Limiting trusts with partners to trusts with domains in forests
that contain only partner-shared resources (do not provide trusts relationships to domains within the organizations internal forest).
Limiting authentication across the trust. Limiting authorization within trusting domains. Providing a
blanket trust for all trusted users or to all resources should not be the default setup.
Using Security Identifier (SID) Filtering on external trusts. SIDs

from group memberships are included in a users access token, used when assessing access to resources. Since it might be possible for a malicious attacker to include SIDs from a trusting domain in his trusted domain users access token, SID Filtering can be applied to mitigate this attack. SID Filtering removes any trusting domain SIDs from the trusted users access token. Limiting trusts in these ways can prevent unnecessary exposure of AD objects to external users. Limiting access can reduce the risk that trusts might be used in a successful attack. Trusts can be created and managed using Active Directory Domains and Trusts or commandline tools such as Netdom.
Managing Directory Objects

Directory objects themselves can be manipulated, either improving or weakening security in the process. Adding and configuring software or simply managing users, computers, printers and AD processes can change the security status of your AD environment. Permissions on AD objects can also be directly manipulated using GUI tools, including:
Active Directory Users and Computers Active Directory Domains and Trusts Active Directory Sites and Services
Numerous other tools are available from Start | Administrative Tools, such as ADSI edit and various command-line tools. These tools allow direct configuration of access control lists (ACLs). The Delegation of Control wizard, used to assign authority over groups of AD objects, delegates the right to manage directory objects and their properties, including ACLs. The security-conscious administrator will learn about AD ACLs before using these tools.
Protect Active Directory by Restricting Group Membership and Understanding Active Directory ACLs
AD ACLs are used the same way as ACLs on files, folder, printers and Registry. When a request is made to do something with an object, this request is compared to the ACLs on the object. However, AD object permissions are different from those applied to other objects. AD permissions are composed of standard permission sets applicable to all objects, and unique permissions are applicable to only specific types of objects. Its easy to see why this is so: objects like users are different from computers, and both are different from an Exchange mailbox. How do you ensure that the correct permissions exist on all objects? How can you ensure that weak permissions do not allow an attacker to steal information or damage AD processing? No resource exists that defines every possible permission on every AD object. You can, however, develop a sound policy by evaluating the basic objects and evaluating proper protection for objects you add. To start, become familiar with standard object rights, and then extended rights.
Standard and Extended Rights

Standard rights are generic rights that can be applied to every object. They are:
DELETE: Delete the object. READ_CONTROL: Read data from the security descriptor, but not
the Systems Access Control List (SACL) (auditing information).
WRITE_DAC: Modify the Discretionary Access Control List (DACL). WRITE_OWNER: Assume ownership of the object. SYNCHRONIZE:
Use the object for synchronization. Synchronization is used when multiple processes (or threads) need access to the same object.
ACCESS_SYSTEM_SECURITY: Read or set the SACL. GENERIC_READ: Read permissions and properties on the object.
List the object name if the parent container is listed, or, if the object is a container, list its contents.
GENERIC_WRITE: Read permissions, write properties and

perform validated writes to the object.
GENERIC_EXECUTE: Read permissions, and list contents of a

container object.
GENERIC_ALL: Create or delete children; delete a subtree; read and

write properties; examine children and the object; add and remove object from the directory; read or write an extended right.
CREATE_CHILD: Create children. The Access Control Entry (ACE)

ObjectType member can contain a Globally Unique Identifier (GUID), which identifies the type of child object that can be created. (GUIDs are unique numbers generated by Windows and by some applications to identify a component.) If there is no GUID in the ObjectType, all child object types can be created.
DELETE_CHILD: Delete children of the object. The ACE

ObjectType member can contain a GUID which identifies the type of child object that can be deleted. If there is no GUID in the ObjectType, all child object types can be deleted.
LIST: List children of the object. The right to list children of this
object. For more information about this right, see Controlling Object Visibility within the ADSI-Edit tool section.
SELF: Perform an operation controlled by validated write access

right. The ACE member ObjectType can contain a GUID identifying the validated write. If no GUID is in the ObjectType, all validated write operations possible for this object can be performed.
READ_PROP: Read the object properties. A property set or

property can be defined by a GUID in the ObjectType member of the ACE. If no GUID is present, all object properties can be read.
WRITE_PROP: Write object properties. A property set or property

can be defined by a GUID in the ObjectType member of the ACE. If no GUID is present, all object properties can be written.
DELETE_TREE: Delete all children of this object. Permissions on

the children do not matter; that is, a user with this right can delete a child object even if the child object denies deletion.
LIST_OBJECT: List this object. Without this right, or the LIST

right (listed earlier), the object is hidden from the user.
CONTROL_ACCESS: Perform an operation that is controlled by

an extended access right. The ObjectType member of the ACE may contain a GUID which identifies the extended right. If it does not, all extended write operations associated with the object can be performed. Extended rights are specific to only some objects within the AD. This list is very long, and there is no comprehensive list. Table 1 lists a few extended rights specific to Windows 2003.
22
Rights
Allowed to authenticate inetOrgPerson
Object(s)
Computer or service
Explanation
inetOrgPerson is an alternative user object, new to Windows Server 2003, required for compatibility with other directory structures and applications developed to use those structures The right to create an inbound-only trust between forests The right of a user to enable or disable the Reversible Encrypted Password setting for a user(s) or computer(s) account The right to generate Resultant Set of Policy logging of the specific domain or OU The right to generate Resultant Set of Policy planning on the specific domain or OU Migrate SID-history without administrator privileges In Windows 2003 it is possible to cache group membership for Universal Groups. This means that a remote branch office need not have access to a Global Catalog server; instead, Universal Group membership is cached local on a domain controller. This privilege is necessary to update the cache on demand.
Create inbound forest trust Enable per user reversibly encrypted password Generate RSoP logging Generate RSoP Planning Migrate SID-History Refresh group cache
User or group
User
OU or domain
Domain or OU
User or group Domain
Table 1: Extended Rights
Adding AD Classes
AD classes define the types of objects that can be included in the AD and what properties these objects will have. Included in the class definition are the default permissions that will be assigned. Classes added to AD cannot be removed; this can cause problems if a new class has the same name as an existing class that is no longer required. Windows 2003 allows AD classes to be disabled, thus freeing up the name and preventing the proliferation of objects no longer required in the directory.
23
In order for applications to work well in an AD domain, they must be integrated with the AD; to do so, they will typically add new classes. One example is Microsoft Exchange Server. In order to install such applications, the administrator must be a member of Schema Admins. Keeping the membership of this group empty until such applications must be installed is a sound security practice. Adding new object classes to the AD should not be done without a great deal of thought, planning and testing. Restricting membership of the Schema Admins group will prevent accidental additions and make malicious additions harder. It will also be much easier to prove intent, as the individual must first have his account added to Schema Admins and install the application. He cannot claim that he did not know the application would add new object classes.
Modifying AD Default Permissions and Properties

Access to many object properties is part of normal administration tools. For example, user account properties are exposed through Active Directory Users and Computers. Access to some object permissions is also possible there, as well as through other administration tools, and by using the Delegation of Control wizard. However, many objects are not accessible through typical administration tools. To work with them requires the use of ADSIedit.
Assigning Authority for AD Administration

AD administration is by default in the hands of the Domain Admins and Enterprise Admins groups. However, administration of specific objects can be delegated either by using server application software (such as delegating responsibility for Exchange server objects, or Certification Authority Objects through respective administration consoles) or by directly modifying permissions on AD objects. While permissions on objects can be directly manipulated, a typical method is to use the Delegation of Control Wizard to assign custom groups the responsibility for administration of objects within an AD container. Examples include assigning the reset password task for an OU, or the ability to add and manage user accounts within an OU. The dsrevoke utility can be used to list and remove delegated AD permissions. Chapter 4 discusses delegation of authority.
24
TOOLS
Many tools can be used to manage AD, and all of them are important to security in some way. Information about the different types of tools can be found in various chapters of this book, some of which will be available in future installments:
Managing AD Security: Chapter 2 (this chapter) Monitoring Group Policy Health: Chapter 3 Delegation of Authority: Chapter 4 Auditing and Monitoring AD security: Chapter 5 Note
Other tools have functionality beyond whats needed to ensure the security of AD, and are beyond the scope of this book. But they are all important, since if used incorrectly they can weaken security. Please do not make the mistake of thinking that only the tools mentioned in this e-book can impact the security of AD. Even more important than learning how to use all the tools is to learn when to use them, and how to use them correctly. More harm can be done by an untrained, unthinking employee with administrative privileges than by most attackers. Take a caution from medical practitioners: whatever you do, Above all, do no harm. If you do not know how to properly use a tool or if you do not understand why you are making changes, stay away from a production network until you do.
25
Using Group Policy Tools

Tools to manage Group Policy for DCs include the Group Policy Editor (GPE), Group Policy Management Console (GPMC) and security templates. The Security Configuration and Analysis tool can be used to directly apply security settings to DC, one at a time, or to analyze a DCs current security settings. Finally, direct editing of the Registry using regedit is also available. The Group Policy Editor can be directly loaded in a Microsoft Management Console (MMC); it is also available by accessing the properties page of an AD site, domain, or OU, or by using the GPMC. (Once the GPMC is installed, the GPE is no longer accessible from the GPO properties page.) The GPE is easy to use, and provides basic utility. However, it does not provide many essential features for managing Group Policy. You cannot determine, for example, the impact of a combination of multiple GPOs on a specific computer, server or user. You cannot copy the GPO or export it and use it in another domain. You cannot even print the policy. To examine the settings in the policy you must browse through the policy, opening many sub containers to determine if anything in them is set. In Windows 2003, the GPMC provides the missing parts of Group Policy management. The tool (which was not part of the initial release of Windows 2003) can also be used to manage Group Policy in a Windows 2000 domain. To do that, you must run the GPMC on a Windows XP Professional or Windows 2003 computer and have at least one license for Windows 2003 (you will also lose some functionality). The GPMC is not essential for creating and using GPOs; but it is much more difficult to manage Group Policy without it.
Group Policy Editor

The GPE can be used to create and edit GPOs, manage GPO inheritance and filter GPO application. After GPMC installation, use the GPE to manage settings within the GPO. GPMC is used for all other Group Policy management duties.
Creating and Editing GPOs

GPO creation and linking are two separate actions. It is possible to have a GPO not linked to either a site, domain or OU, and equally possible to link a GPO to all of them. When using the AD object's property pages to create a GPO in Active Directory Users and Computers or Active Directory Sites and Services, the GPO is automatically linked to the object, but the GPO can be unlinked.
To create a new GPO: 1) To create a domain- or OU-level GPO, open Active Directory Users and Computers. To create a site GPO, open Active Directory Sites and Services. 2) To create a domain or OU GPO, right-click the domain or OU object and click Properties. To create a site GPO, right-click the site and select Properties. 3) Select the Group Policies tab as shown in Figure 4.
Figure 4. Create a new GPO from the domain, site or OU properties page. 4) Click the New button. 5) Enter a name for the new GPO and click OK. 6) To edit the GPO, select the new policy and click Edit. 7) Edit the policy by selecting a container and navigating to the specific option desired; then double-click to open the item selected in the detail pane, as shown in Figure 5.
27
Figure 5. Open items to make changes. 8) When your edit is complete, click OK in the item view, then close the GPO by closing the policy windows.
Editing a GPO in a GPE Console

An existing policy can be edited by returning to the same interface, or it can be loaded in an MMC and edited. To create the MMC: 1) Create a new MMC console by typing MMC in the Start | Run text box and clicking OK. 2) Select the File menu then select Add/Remove Snap-in 3) Click the Add button, then select Group Policy Object Editor and click OK. 4) Click Next from the Welcome page of the wizard. Use the Browse button to locate the policy to edit, as shown in figure 6, and then click OK.
28
Figure 6. Select the policy to edit by browsing the AD objects where policy can be linked. 5) Click Finish, click Close, and then click OK to return to the console and edit the policy. 6) Expand the policy in the console to view or edit its settings.
Understanding and Controlling GPO Inheritance

Multiple GPOs can be applied to a user or computer object. The order in which they are applied follows the AD hierarchy, and the process is called inheritance. The following order is used: local, site, domain, OU. If the account resides in an OU that is part of an OU hierarchy, any GPOs linked to OUs above the accounts OU are applied starting with the GPO linked to the top-most OU and continuing down. If multiple GPOs are linked to an object, they are applied in the order in which they are linked. Each GPO is applied, one after the other. If no conflicts exist, then settings are merged. If a conflict exists, then the last setting applied wins. There may be reasons to modify this behavior. GPOs in Windows 2000 and Windows 2003 domains can be marked to block the inheritance of other GPOs (that is, not apply the settings contained in the GPO), prevent a GPO from overriding settings and allow machine settings to be reapplied over individual settings. (Keep in mind that best practices recommend limiting use of these techniques.) Many problems with Group Policy processing are not problems at all; instead, they are unwise, possibly unauthorized, or simply the set and forget use of these properties. Since the application or non-application of a GPO can critically impact the security of AD, it is recommended that these features not be used on policies linked to the domain or to the domain controller OU.
29
To inspect the policy and ensure that blocking inheritance has not been set: 1) Select the Group Policy property page of the site, domain, or OU. 2) View the Block Policy Inheritance check box as shown in Figure 7. If the box is selected, policy inheritance is blocked.
Figure 7. Block Policy Inheritance is set for the AD object. 3) Click OK.
30
It is important to note that No Override always beats Block Policy Inheritance. If, for example, No Override is set on a GPO linked to the domain, and Block Policy Inheritance is set on an OU, the domain GPO settings are inherited by accounts in the OU. The use of Block Policy Inheritance and No Override should be carefully coordinated within the domain to ensure that the proper policy is applied. To determine if No Override has been set: 1) Open the Group Policy property page. 2) Check the No Override column of the GPO as shown in Figure 8. If the column is selected, No Override is in effect. To remove the setting, double-click in the column. 3) Click Close.
Figure 8. No Override is configured from the GPO properties page. This will ensure adherence to any Block Policy Inheritance settings.
31
Using WMI Filters

Windows 2003 GPOs can be restricted via the Windows Management Instrumentation (WMI) Filters defined in the GPO. WMI is a way to manage Windows computers. WMI Filters on GPOs limit GPO application to computers or user accounts that meet specific characteristics. This is done by creating a dynamic group that contains a collection of accounts with a specific characteristic. For example, a WMI filter could select all computers with a specific Network Interface Card (NIC). This could be important for the management of DC policies. Another WMI filter could be useful when the DHCP client service is disabled on DCs, which can in turn disable certain client NICs. In this scenario, a GPO that enabled the DHCP client service could be filtered to bypass those computers.
Group Policy Management Console

GPMC solves many Group Policy management issues and concerns, empowers the Group Policy administrator, provides a native tool that finally allows you to manage Group Policy in a way that is fairly efficient and comprehensive, and can even reduce staff requirements. Specifically, GPMC provides:
Backup and restore of GPOs HTML reporting of GPO settings HTML reporting of Resultant Set of Policy (RSoP) data (both
logging and planning mode data)
Simplified management of Group Policy security Import and export (backup) of GPOs and WMI filters Copy and paste of GPOs and WMI filters A GUI that makes Group Policy easier to use Scripting of policy tasks exposed within the tool (but not scripting of settings within a GPO)
Installing and Configuring the GPMC

GPMC is a free download, available at
www.microsoft.com/downloads/details.aspx?FamilyId=0A6D4C24-8CBD-4B359272-DD3CBFC81887&displaylang=en.
While GPMC can be used to manage Windows 2000, XP Pro and Windows 2003 computers, it must be installed on an XP Pro or Windows 2003 computer. If XP is used, it must have:
Service Pack 1, at minimum The Microsoft .NET Framework Post SP1 hotfix QFE 326469
(This updates gpedit.dll to version 5.12600.1186 required by GPMC.)
To install the GPMC: 1) Double-click the gpmc.msi package, then click Next. 2) Read and accept the End User License Agreement (EULA). Note that the license specifies that you must have a valid license for Windows 2003 in order to run the utility. Click Next. 3) If installing on XP, you will be prompted to install post SP1 hotfix 326469 if gpedit.dll has not been updated. The hotfix is delivered with the download and can be installed at this time. 4) Click Close to complete the installation. To open the GPMC console, use one of the following methods:
Click Start, click Run, type GPMC.msc, and then click OK. Use the Group Policy Management shortcut from Administrative
Tools.
Open GPMC from the property pages of sites, domains and OUs.
(The old access to GPE is no longer available; however, it can be accessed through GPMC.)
Create a custom GPMC console by adding the Group Policy

Management snap-in to an MMC. When first loaded, the GPMC console (shown in Figure 9) displays the forest in which the account that opened the console exists. If forest trusts are configured, additional forests can be loaded and Group Policy can be managed by those with proper authority.
Figure 9. The Group Policy Management Console (GPMC) is a new tool that provides management of Group Policy much superior to the Group Policy Editor.
Top-level containers are:
Domain: A sub-node for each domain. Site: A sub-node for each site. Group Policy Modeling: The ability to predict the results of a new
policy. The Group Policy Modeling node will not be present in a pure Windows 2000 forest.
Group Policy Results: The ability to see the results of the current
policies. Expanding a domain container provides a policy-based view of AD and additional Group Policy elements. All GPOs linked to the domain can be found by name from the Group Policy Objects container; follow the links extending from a top-level list of domain GPOs or from the expanded OU container. All WMI filters are also listed. Note that below each domain, site, or OU, GPO links are displayed as shortcuts, but in the Group Policy Objects container, GPOs are shown as little scrolls without the shortcut arrow. This highlights that the GPO exists separately from any container. Its also important to remember to perform GPO-related operations, such as backup and copy, from the GPO in the Group Policy Objects containernot from the link. Every GPO is represented in the Group Policy Objects container, while only those GPOs linked to a site, domain or OU are represented in the site and domain containers. If you select a domain, site or OU, as shown in Figure 10, the detail pane provides three pages of information.
Figure 10. Select the domain, site or OU container to see its associated Group Policy information.
34
The Linked Group Policy Objects tab displays GPOs linked to the
container.
The Group Policy Inheritance tab, shown in Figure 11, displays a

list of GPOs inherited from parent containers in order of their application (precedence). The list does not include any Site policies. Read the list from the bottom up to see the order in which the policies are applied. In the figure, the order indicates that the default domain policy is applied, then the Communications Policy for DCs, then the Default Domain Controller Policy. The Default Domain Controller Policy has precedence over the other policies.
Figure 11. All inherited GPOs are listed, with the exception of Site policies. Site policies can vary depending on the computer and user account, and what Site they are located in.
The Delegation tab, Figure 12, lists the delegated administrative

permissions on the domain, site or OU object. The drop-down list is used to view the Link GPOs, Perform Group Policy Modeling analysis and Read Group Policy Results Data Permissions. Note that both inherited and explicit permissions are listed. To view delegated permissions at the GPO level, examine the property pages of the GPO.
35
Figure 12. Delegated Permissions are listed. You must change the drop-down list to view different permissions. GPO-specific properties can be examined by double-clicking on the GPO. Scope, Details, Settings and Delegation tabs can also be reviewed.
Scope, Figure 13, displays to what objects the GPO is linked; to

which users, computers, and groups the GPO will apply; and to which WMI filter the GPO is linked.
Figure 13. Use the Scope page to determine where the GPO is linked.
The Details tab of a GPO provides information relative to the

GPO, including whether or not the user and/or computer portions of the GPO are enabled.
The Settings tab displays only the settings configured for the GPO. The Delegation tab lists the explicit permissions on the GPO and
includes the users, computers and groups to which the GPO will apply, as well as who can edit and delete the GPO. Several options are available to customize how GPMC works. The following options can be selected from the GPMCs View/Options menu:
Options: Customize the location of columns for some tables. Reporting: Set the location of .adm files used for reporting. The
default search path for .adm files is the system folder then the SYSVOL folder of the GPO. It can be overridden.
General:
Enable or disable trust detection. By default, a two-way forest trust is required to add an additional forest to a GPMC. This can be modified to allow management of GPOs across a oneway forest trust, or to use the Stored User Names and Passwords feature of Windows XP and Windows 2003 to enable access to GPOs in non-trusted forests. Enable or disable the distinction between GPOs and GPO links. Display the DC name beside the domain name.
Basic Operations
Creating, editing, testing, protecting, reporting, backup/restoring, and copy/pasting are all basic Group Policy management processes available via GPMC. Other operations, such as designating which DC to use for Group Policy, can also be managed from the console.
Setting the DC to Use for Group Policy

The GPMC, like the GPE, will default to using the domains Primary Domain Controller (PDC) Emulator. While it is possible to use the GPMC on another DC, remember that arbitrary DC selection is not a good idea. Internal policy should mandate that the same DC be used for all GPOs that can be created by a group of administrators. If Group Policy management is delegated and distributedon an OUby-OU basis, for exampleselection of a single DC is less important. The reason is that use of multiple DCs can cause issues due to replication. If two different administrators are editing the same GPO, but on different DCs, what will be the result? It is possible that GPOs will go out of synch, or that policies written by one administrator will be overwritten by another.
Creating and Editing a GPO From GPMC

Several different paths can be used to create a GPO from within GPMC. Each one allows use of the Group Policy Object Editor to define settings for that GPO. This tool is the same one exposed in Windows 2000 and Windows 2003 prior to installing GPMC. Methods for creating a GPO via the GPMC:
Right-click on any domain or OU and choose Create and Link a GPO here from the context menu. This operation creates the
GPO and links it to the domain or OU selected.
Use a script. GPMC provides many sample scripts, including

CreateGPO.wsf, which can be used to create a GPO using the default options. The scripts are placed in the Program Files\GPMC\Scripts folder when GPMC is installed.
Right-click the Group Policy Objects node in any domain and click New. A new, unlinked GPO is created. (Remember that the
GPO is not applied until it is linked.) To edit the settings in any GPO, right-click the GPO and select Edit.
Scoping GPOs
The process of assigning which users and computers will be impacted by a GPO is called scoping the GPO. This may be accomplished by linking the GPO, using security filtering or using a WMI filter. The methods are described below:
Linking. Explicitly link the GPO during or after creation. The linked
scope of a GPO can also be changed by dragging a GPO from the Group Policy Object node to an OU in the same domain.
Security filtering. Prior to the GPMC, this required using the ACL
editor to set the Read and Apply Group Policy permissions for specific users and groups. With GPMC, the user or group is added to the Scope tab for the GPO or GPO link. This automatically sets the Read and Apply Group Policy permissions. Should you want to Deny these permissions, you must use the ACL editor.
WMI filter. WMI filters dynamically determine the scope of

GPOs, based on attributes. WMI client-side support is only available for XP Pro and Windows 2003 (Windows 2000 ignores WMI filters). The filter is always evaluated on the client computer, meaning that each client examines the WMI filter to see if it applies. Dont overuse WMI filters, since they can mean extended processing time.
38
Reporting
Prior to the GPMC, Group Policy lacked native reporting. This made a seemingly simple activity, like documenting a Group Policy, a tedious, manual chore. The GPMC provides extensive HTML reporting, and reports can be viewed and printed. Some of the reports that can be produced include:
GPO settings. Click the Settings tab of the GPO or GPO link pane
to produce a report, an example of which is shown in Figure 14.
Figure 14. Use the Show all link to see all settings in the GPO, or view only selected areas. Only configured settings will display.
Group Policy Modeling (RSoP planning). Group Policy Results (RSoP logging).
Some settings might not be displayed. Microsoft indicates that the following items might not be displayed:
IE Maintenance section does not include the details of Content

Ratings.
IE Settings in Preference mode. Some cookie settings Customized Java settings in Zones and Privacy Some details for Wireless and IPSec settings
To save a report, right-click on the object and select Save Report (or select Save Report from the Action menu); name the report then save it as an XML or HTML file.
Reports are automatically displayed in a condensed fashion, as shown in Figure 15, and show only areas where settings are established. This simplifies viewing. To examine the settings requires expanding the category. To expand all of the settings, use the show all option at the top of the report. In the Administrative templates portion of the report, the Explain information can be viewed by clicking the setting name as shown in Figure 16.
Figure 15. A full report of the GPO settings can be produced by clicking on the Settings tab.
40
Figure 16. Administrative Template settings can display the Explain information.
Ensuring Permission Consistency

When permissions are modified on a GPO using the GPE or GPMC, they are actually modified on the GPO information in both AD and Sysvol. Permission settings in both must be the same in order for correct policy processing to occur. It is possible to directly set permissions outside of the GPE and GPMC interfaces, and therefore possible that these permissions might be out of synch. GPMC checks permission consistency when you select the GPO. If there is a problem, a dialog box will warn you and, if you are authorized, allow you to click OK in order to change the permissions in Sysvol to mirror those in AD.
Bug Alert
Check Windows 2000 domains for this issue by looking at the Default Domain Policy and the Default Domain Controllers Policy from the GPMC. There is a bug in Windows 2000 that incorrectly sets the ACLs on the Sysvol portion of the GPO to allow inheritance. This may cause them to be out of synch with the permissions set in AD. To correct the error, examine the GPOs in the GPMC and, when prompted, click OK to make the permissions match. The permissions will be synched with the ACLs on the AD portion of the GPO, and the allow inheritance feature will be removed.
41
Backup and Restore

When backup is selected from the context menu, a copy of the GPO is saved to the file system. Likewise, backup also serves as the export function for the GPO. Hence, a GPO backup can be used with either the restore or import function. The backup includes:
The GUID and domain name The GPO settings WMI filter links (not the filter itself) Permission settings on the GPO An XML report of the GPO settings
The backup does not include items stored outside the GPO (only items stored in Sysvol or AD portions of the GPO are backed up.) Be careful; some items many think are part of the GPO are not stored with the GPO and thus are not backed up, including WMI filters (these can be backed up separately using GPMC); IPSec Policies (export to a file from the IP Security Policy snap-in to back up); and links from the domain, site or OU object to the GPO. Warning: Anyone who can access the backup, or a copy of the exported GPO, has a large amount of information about the security configuration of the enterprise. This information should not be readily available. Only authorized administrators, security teams and auditors should have access to this information. The location, and the DACLs set on these files, are critical. Think of these backups like you do any other backups of sensitive data and maintain good copies of your critical data both locally and off-site. Additionally, protect AD from accidental or malicious use of these backups in a restore that might leave systems vulnerable. If an outdated GPO is restored, or a weaker one imported, enormous damage could be done. Ensure limited access to these files and limit all GPMC operations to those trusted individuals who need access in order to do their jobs. Restore takes a backup and reinstates it in the domain. The GUID of the original GPO is used, as is the domain information. You cannot use a backup/restore process to move a GPO to another domain. The restore replaces the GOP setting, the ACLs on the GPO and the WMI filter links.
42
To back up a GPO: 1) Right-click on the GPO in GPMC and select Back Up from the context menu. 2) Provide a file system location, the name of the file and a description, and then click Back Up as shown in figure 17. Click Back Up again, and then click OK to save the GPO.
Figure 17. GPOs may be saved to the file system. Make sure this is done to a secure locationnot somewhere where unauthorized individuals can access the file. To back up all GPOs: 1) Right-click on the Group Policy Objects node and select Backup All from the context menu. 2) Provide a file system location and description. 3) Click Back Up, then OK. To restore a GPO that still exists, an administrator need only have edit settings and delete and modify security permissions on the GPO. To restore a GPO that has been deleted, an administrator needs the Create GPO right.
43
To restore a GPO that still exists: 1) Right-click on the GPO in the Group Policy Objects container and select Restore from Backup from the context menu. Click Next. 2) Browse to the GPO location and click Next. 3) Select the backup and click Next. 4) Review the settings and click Finish. 5) Click OK. Sample scripts that perform basic functions are provided with the GPMC. To back up a GPO, use the provided script BackupGPO.wsf or BackupAllGPOs.wsf. To restore a GPO, use the example scripts RestoreGPO.wsf or RestoreAllGPO.wsf. Information about GPO backups can be found using the QueryBackuplocation.wsf script.
Managing Backups
Information on backups, as well as the ability to delete, organize (sort), restore and view backup settings is located in the Manage Backups dialog. To access this page: 1) Right-click on the Domains container and select Manage Backups from the context menu. OR Right-click on the Group Policy Objects container and select Manage Backups from the context menu. 2) Locate and select the file location of the backups and click OK. A backed-up GPO can be imported into an existing GPO. Import can be used to restore a GPO, or completely replace the existing settings in a GPO with the settings in the backup GPO. Import can be used to move GPO settings from one domain to another, even if the new domain is in another forest, and even if theres no trust relationship between the original and destination domains. To import a GPO, right-click the GPO under the Group Policy Objects node and follow the wizard. The GPMC Copy command uses an existing GPO to obtain settings that it then transfers to a new GPO in a new domain. (If the copy function is used in the same domain it will link the GPO to the new object, not produce a new GPO). To copy a GPO to a new domain, an administrator must have GPO creation rights in the new domain and read access to the source GPO. A trust is required between the source and destination domains.
Delegating Group Policy

Group Policy change can increase or decrease the security level of every computer in the forest. Therefore, creation of GPOs and their management is by default restricted to The Group Policy Creator Owners group and Domain Admins. However, the ability to delegate some of the workload is an intrinsic part of proper Group Policy management. Like many administrative privileges, Group Policy management can be assigned in a granular fashion. Authority can be given at a specific domain or OU level, and authority does not have to be carte blanche. The privileges of creating, editing, linking, and performing modeling or results analysis, as well as creating and/or editing WMI filters, can be granted or denied separately. To give a domain user the ability to create and manage GPOs through the domain, you can add the users account to the Group Policy Creator Owners Group. But membership in this group may provide too much authority. What if a group just needs the ability read report results? To provide that permission, the user account could be added to a group that already has management permissions in the GPMC. This would be a bad idea, as group membership cannot be restricted. Any group member receives the rights and permissions applied to the group, and that may be more than the user needs. Instead, consider using the Delegation tab of the Group Policy Object container, shown in Figure 18.
Figure 18. The Group Policy Objects Delegation tab displays all users and groups that can create GPOs in the domain.
45
This tab can be used to add a user or group and configure their access using permissions. Major permission categories include:
Linking. Use the Delegation tab. Provides the ability to link a

GPO to a site domain or OU.
Group Policy Modeling. By default, this is available only to

members of the Domain Admins group. In a Windows Server 2003 forest, or in a Windows 2000 forest in which the schema has been updated, this can now be delegated.
Group Policy Results. Permission is normally granted to only

members of Domain Admins or the local administrator of the target computer. To delegate this, assign the Generate Resultant Set of Policy (logging) permission.
Create WMI Filters. Use the Delegation tab of the WMI Filters
page. WMI filters are stored in the domains system container in AD, so permissions applied to this container would do the same thing. Two possible permissions are available: Creator Owner (can create new WMI filters, but has no access to WMI filters created by others), and Full Control (create, own and have full control on all WMI filters in the domain; assigned by default to Domain Admins and Enterprise Admins). You can also apply permissions to a specific WMI filterEdit or Full Control. By default, all users have Read permission to all WMI filters. This is necessary to allow Group Policy processing on the client and it cannot be removed. To manage delegation for a GPO, use the Delegation tab of the GPO and/or permissions directly on the GPO. These privileges are more granular and include (as shown in figure 19):
Read. Read the GPO. Edit settings. Read, write, create child objects, and delete child
objects.
Edit, delete and modify security. Read, write, create child objects,
delete child objects, delete, modify permissions, and modify owner. The apply group policy right is not set.
Read as used in security filtering. Set when adding users using

the scope page in the GPMC.
Custom. Displayed, but cannot be set from GPMC. Includes

combinations of rights such as Deny.
Deny. Must be set using the Advanced page.
46
Figure 19. For each GPO, specific rights can be delegated.
GPO Planning and Analysis Modeling

Implementation of an extensive Group Policy design is a daunting task. The more computers and users that must be managed, and the more diverse their roles, the harder it is to keep track of the hundreds of settings and multiple GPOs implemented. It is also difficult to design a GPO strategy for a large enterprise. Windows 2003 helps this situation with the Resultant Set of Policies (RSoP) MMC snap-in, which can be used in both logging and planning mode. GPMC provides an interface for this process. Group Policy Modeling (I wonder what will happen if) can be used to plan and design a GPO hierarchy and see what the results will be. Group Policy Results (I wonder what the heck happened here?) allows the administrator to examine the current GPO structure and determine its impact on a specific user or computer. The GPMC tools are exposed at the forest level. Use these tools to model and analyze the impact of GPOs linked to the domain and to the domain controller OU, which can affect the security of DCs.
Modeling a Group Policy Hierarchy

In Group Policy Modeling, no GPOs are actually applied, but the results of applying the GPOs can be determined. Known as RSoP Planning Mode in Windows 2003, Group Policy Modeling requires a DC running Windows 2003, but it can also do RSoP for any Windows 2000 or XP Pro computers in the forest. The service, Resultant Set of Policy Provider, runs on the Windows 2003 server and must be enabled for the process to work. Figure 20 shows a previous query.
47
Figure 20. Previous queries are displayed from the Group Policy Modeling node. Group policy modeling requires GPOs. Best practices call for using a test forest. Follow these steps: 1) Right-click the Group Policy Modeling container and select Group Policy Modeling from the context menu. 2) On the Group Policy Modeling Wizard welcome page click Next. 3) Select a DC to process the simulation. 4) Find the Container to be used for user information (where the user accounts are located). 5) Find the Container to be used for computer information (where the computer accounts are located), and then click Next. 6) Indicate where the user and computer accounts are located. 7) Continue the wizard as listed in the RSoP section. 8) The report is displayed in the detail pane.
48
The Summary page displays information that impacts the results, including a list of GPOs that will be applied, security group members affected, and WMI filters applied. The Settings page displays the setting which will be applied, and the Query page displays the parameters used to create the query. A list of GPOs that will impact the user or computer can be a confirmation of proper structure; or, conversely, can point to a flaw in your GPO design. The results of the query are available for later review; the query can also be re-run after GPO changes have been made. Delete any queries that are no longer needed. To save a copy of the report to the file system, right-click on the query in the details pane and select Save from the context menu, then browse to a location, enter a file name, and click Save. The GPMC provides HTML reporting of the results, but not the precedence information provided by the RSoP MMC snap-in. The HTML report tells you the final result, such as what setting will be applied. Precedence information will show the history. The Advanced View (right-click on the query in the console pane and select Advanced View) option opens the RSoP snap-in and provides information on every GPO that attempts to set the setting, along with what it would have set the setting to.
Determining the Results of Group Policy Implementation

The Group Policy Results node of the GPMC can be used to analyze the exact security configuration for users and computers in a production environment. The resultant set of policy logging mode is useful for confirming expected results, troubleshooting policy application, and auditing security implementation against official policy for compliance. The data is especially important because it is not simulated on the DC, but calculated at the target computer. However, the client must be running Windows XP or Windows 2003. Using the logging tool is similar to the use of the RSoP console and Group Policy Modeling tool in the GPMC.
49
Using Security Configuration and Analysis and Security Templates

Security templates are text files that contain a list of security settings. They can be configured using a text editor; but to ensure correct syntax, and make the job easier, add the security templates snap-in to an MMC console, as shown in Figure 21. Settings in a template can be applied to a single machine at a time by using the Security Configuration and Analysis snap-in or by using the secedit command-line tool.
Figure 21. Security templates can be viewed and modified in the Security Templates snap-in. Secedit can be scripted to apply security to multiple computers on a network, or scheduled for periodic re-application. The analysis component of both tools can be used to compare the current computers security configuration to that of an existing template. While security settings in the template can be most easily understood and adjusted in the snap-in, it is possible for security settings to be included in the text file and not displayed in the snapin. Figure 22, for instance, shows a template file that includes a Registry setting to harden TCP/IP. TCP/IP settings are not a preconfigured Security Option or other component of the default security settings GUI. However, if correctly entered, any Registry entry recorded in the template will be set if the template is applied using Group Policy, Security Configuration and Analysis, or secedit.
Figure 22. Template files can contain Registry settings that are not displayed in the GUI. Group Policy can work with security templates to manage DC security settings, by importing them into a GPO and applying them. Settings can first be applied and tested on a single machine, then tested via Group Policy in a test domain on a test network, before being imported into the production GPO. This saves time over manual configuration, and reduces the risk of configuration errors. To configure a template, open it in the Security Templates GUI and change settings just as you would in Group Policy.
Using ADSI Edit to Manage Directory Objects

While many basic administration tools can be used to manage specific collections of AD objects, more powerful tools, including ADSI Edit, are available. ADSI Edit is a support tool that can be used to add, delete and move directory objects. Support tools are available in the Support directory of the Windows 2003 CD-ROM. They are not installed by default and should not be installed on every computer. They might provide an attacker who successfully gains access to a specific DC the ability to attack more of AD, including the current domain and the entire forest. ADSI Edit provides a lower-level view than is available with basic administration tools, and exposes objects that may not be viewable using default administrative tools. Because it provides this view, it should not be used when basic administration tools or scripts can be used.
To use ADSI Edit: 1) Install the Windows support tools from the server installation disk Support directory. 2) Add ADSI Edit to an MMC console. 3) Right-click the ADSI Edit node and select Connect to. 4) In the text box, select Naming Context of Distinguished Name for the area of AD (Domain, Configuration, Schema) you wish to view or modify. 5) Click OK. 6) Repeat this procedure to add the other containers if desired. 7) Expand the container to expose the objects, as shown in Figure 23.
Figure 23. ADSI Edit can be used to view or modify directory objects.
52
Using the Active Directory Domains and Trusts Console

The Active Directory Domains and Trusts console is used to add, remove and configure trusts. Two important features of trust creation and management are often overlooked. These features limit access by controlling cross-trust authentication and implementing SID Filtering.
Selective Authentication
Many administrators believe that no access across a completed trust is possible until the trusting domain administrator modifies access controls on domain resources. This is not precisely true. After a trust is completed, the trusting domain will pass through authentication of users from the trusted domain. This means that these users may have access to domain resources. For example, trusted domain users could log on from a computer in a trusting domain and access any computer resources available to the Everyone or Interactive groups. To limit this type of access, the authentication scope of a trust can be managed between domains in different Windows 2003 forests. This process is called Selective Authentication. When Selective Authentication is configured and a user authenticates a new SID across a trust, the Other Organization SID is assigned. This SIDs presence prompts a check on the resource domain to ensure that the user is authorized to authenticate. (If the user is not from across a trust, the This Organization SID is assigned. Only one of these SIDs can be present in a users Access Token.) To configure Selective Authentication for trusts: 1) Open the Active Directory Domains and Trusts console. 2) Right-click the domain node and select Properties. 3) Select the Trusts tab. 4) Select Domains trusted by this domain (outgoing trusts) or Domains that trust this domain (Incoming trusts). 5) Select the external trust or forest trust to administer and click Properties. 6) Select the Authentication trust. 7) For external trust, select either authentication or Selective authentication. the
Domain-wide
53
8) For the forest trust, select either Forest-wide authentication or Selective authentication. 9) If Selective Authentication is selected, the domain and/or server properties must be modified to provide the Allowed to authenticate permission on the object. If server properties are not modified in the external trust, no users can access their resources even if provided explicit access to objects on the server. If domain properties do not provide authentication in the forest trust, no resources in the domain can be accessed even if explicit access is granted to external users.
SID Filtering
SID Filtering removes the SIDs in users authorization credentials that represent group membership or user accounts from a different forest. (SIDs from a different forest can be added to the users access token by the forest, but not delivered across the forest trust.) This prevents spoofed credentials from being used across a trust. SID Filtering is automatically enabled when Windows 2003 external or forest trusts are created, or when Windows 2000 SP4 or later DCs are used to establish the trust.
54
SUMMARY
Securing AD requires much more planning and activity than simply protecting the AD database itself. Peripheral services such as DNS must be hardened, and domain authentication and domain controller access controls must be strengthened. Native security tools can be used to perform many of these functions. Other Windows tools can be used to monitor, maintain, prepare for recovery, and audit AD. Some of the more interesting management tasks that ensure the security of AD are those that monitor its health. In the next chapter, well focus on these processes and the tools used to accomplish them.
55
ABOUT QUEST WINDOWS MANAGEMENT

Quest Software, now including the people and products of Aelita Software, provides solutions that simplify, automate and secure Active Directory, Exchange and Windows environments. The Quest Windows Management group delivers comprehensive capabilities for secure Windows management and migration. For more information on Quest Softwares Windows Management group, please visit www.quest.com/microsoft.
ABOUT QUEST SOFTWARE, INC.

Quest Software, Inc. provides business-critical software for 18,000 customers worldwide, including 75 percent of the Fortune 500. Quest offers products for application performance management for packaged applications and Java environments; database management for Oracle, DB2, SQL Server, Sybase and MySQL environments; and Windows management in Active Directory and Exchange. These management solutions help customers develop, deploy, manage and maintain the IT enterprise without expensive downtime or business interruption. Headquartered in Irvine, Calif., Quest Software can be found in offices around the globe and at www.quest.com.
Quest Software Windows Management 6500 Emerald Parkway Suite 400 Columbus, OH 43016 USA Phone: 614-336-9223 1-800-263-0036
56
NOTES

CH 2

Enviado por

Dados do documento

Descrição original:

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

CH 2

Enviado por

Direitos autorais:

Formatos disponíveis

Five Key Lessons to

CHAPTER 2: KNOW AND USE SECURITY TOOLS AND TECHNIQUES

Securing systems on which AD relies such as authentication and

Securing domain controllers (DCs), the computers on which the

Securing communications, such as AD replication and remote

Securing AD directly using access control lists (ACLs)

TECHNIQUES FOR MANAGING AD SECURITY

Use Group Policy and related processes to harden domain

Protect AD by restricting membership in the Schema Admin and

Securing Authentication, DCs, and DC Communication

Password Policy, Account Lockout Policy and Kerberos Policy

Figure 1. Account Policies.

Security settings to manage domain controllers should be

GPOs linked to domain objects for other domains have no

Additional settings that can be used to lock down computers and

Securing Authentication Via Group Policy

Harden the authentication process

Network Security: LAN Manager Authentication Level

Network Security: LDAP Client Signing

Network Access: Shares that Can Be Accessed Anonymously

Hardening Domain Controllers Via Group Policy

Backup Files and Directories Restore Files and Directories

Domain Controller: Allow Server Operators to Schedule Tasks

Registry and File System Permissions can be set and maintained

Using Security Templates to Secure Domain Controllers

Using Group Policy Administrative Templates

Hardening Domain Controller Communications Via Group Policy

The IPSec Policy Management section of Group Policy can be

DNS Placement and Policy Group Policy Restrictions DNS Configuration

Securing DNS Using Placement and Policy

Securing DNS Configuration

Secure DNS Cache Against Pollution. If a DNS server is queried

Figure 2. Advanced DNS server property settings.

Restrict Zone Transfers. When DNS is integrated with AD, DNS

Figure 3. Zone transfers options.

Configure Local Root Hints, if possible. Root hints provide

Disable Recursion, where possible. DNS servers that use

Securing DNS Using Group Policy

Windows Server 2003 Security Guide

Windows 2000 Security Hardening Guide

Windows 2000 Security Operations Guide

Managing Domains and Trusts

Making the trust one-way when possible. In a one-way trust, one

Using Security Identifier (SID) Filtering on external trusts. SIDs

Managing Directory Objects

Standard and Extended Rights

GENERIC_WRITE: Read permissions, write properties and

GENERIC_EXECUTE: Read permissions, and list contents of a

GENERIC_ALL: Create or delete children; delete a subtree; read and

CREATE_CHILD: Create children. The Access Control Entry (ACE)

DELETE_CHILD: Delete children of the object. The ACE

SELF: Perform an operation controlled by validated write access

READ_PROP: Read the object properties. A property set or

WRITE_PROP: Write object properties. A property set or property

DELETE_TREE: Delete all children of this object. Permissions on

LIST_OBJECT: List this object. Without this right, or the LIST

CONTROL_ACCESS: Perform an operation that is controlled by

User or group Domain

Table 1: Extended Rights

Modifying AD Default Permissions and Properties

Assigning Authority for AD Administration

Using Group Policy Tools