Microsoft press windows server 2008 active directory resource kit - part 5 pps

308 Part III: Administering Windows Server 2008 Active Directory
Figure 8-8 SCW domain controller services and firewall rules.
After configuring an SCW policy, you can apply the policy to the server where you configured
the policy. You can also apply that SCW policy to other computers with the same configura-
tion by running use the Scwcmd tool to either directly apply the policy or to transform the
policy into a Group Policy Object that can then be linked to the Domain Controllers OU. For
details on how to do this, see Chapter 13.
Caution
Be careful when applying an SCW policy that was configured on one computer to
other computers. The SCW policy is specific to the computer where it was created, so if the
other computers have a different configuration (for example, they are running other server
roles or applications), the SCW policy may disable services or block firewall ports. Ensure that
all servers have the same configuration before applying the SCW policy.
Configuring the Default Domain Controllers Policy
In addition to reducing the domain controller attack surface, you can also use Group Policy to
increase the security of your domain controller deployment. When you deploy a Windows
Server 2008 domain, the following two default GPOs are created and applied to the domain
and to the Domain Controllers OU:
■ Default Domain Policy, which is linked to the domain object and affects all users
and computers in the domain (including computers that are domain controllers)
through policy inheritance.
Chapter 8: Active Directory Domain Services Security 309
■ Default Domain Controllers Policy, which is linked to the Domain Controllers OU.
This policy generally affects only domain controllers, because by default, computer
accounts for domain controllers are kept in the Domain Controllers OU.
You can configure security policies using both the Default Domain Policy and the Default
Domain Controller Policy. By default, all polices defined at the domain level are inherited by
OUs in the domain unless the policy inheritance is blocked or a policy linked to the OU
contains settings that override the domain policies. By applying domain controllers specific
security settings in the Default Domain Controller Policy, or in another GPO linked to the
Domain Controllers OU, you can apply security policy settings that are specific to domain

controllers, but not to all users, groups, and computers in the domain.
Note
This chapter is primarily concerned with domain controller security, so this chapter will
focus on settings available in the Default Domain Controllers Policy. For details on configuring
the security settings in the Default Domain Policy, see Chapter 13. For details on configuring
Group Policy, including configuring Group Policy links and inheritance, see Chapter 11,
“Introduction to Group Policy.”
Configuring Domain Controller Audit Policy Settings
One of the key components in a domain controller security policy is auditing changes made
on the domain controllers. By auditing changes made on domain controllers, you can identify
who is responsible for directory changes and when the changes were made.
Windows Server 2008 introduces some important changes to the auditing on domain controllers.
In Windows 2000 Server and Windows Server 2003, there was one audit policy, Audit
Directory Service Access, that controlled whether auditing for directory service events was
enabled or disabled. In Windows Server 2008, this policy is divided into four subcategories:
■ Directory Service Access
■ Directory Service Changes
■ Directory Service Replication
■ Detailed Directory Service Replication
Note
These subcategories are not visible through Group Policy Management Editor.
To view and configure the subcategories, use the Auditpol.exe command-line tool.
To view the current directory service access audit settings, type Auditpol /get
/category:“ds access”.
310 Part III: Administering Windows Server 2008 Active Directory
From a security auditing perspective, the most important new feature is the Directory Service
Changes subcategory. This new subcategory adds the following functionality:
■ When you change an attribute on an object, AD DS logs the previous and current values
of the attribute. If the attribute has more than one value, only the values that change
as a result of the modify operation are logged.

■ When you create a new object, values of the attributes that are populated at the time of
creation are logged. If the user adds attributes during the create operation, those new
attribute values are logged. In most cases, AD DS assigns default values to attributes
(such as samAccountName). The values of such system attributes are not logged.
■ If an object is moved, the previous and new location (distinguished name) is logged
for moves within the domain. When an object is moved to a different domain, a create
event is generated on the domain controller in the target domain.
■ If an object is undeleted, the location where the object is moved to is logged. In addition,
if the user adds, modifies, or deletes attributes while performing an undelete operation,
the values of those attributes are logged.
By default, the Audit directory service access audit category is not enabled in the Default
Domain Controllers OU, but the Directory Service Access subcategory is enabled. This audit
policy logs when administrators access objects in AD DS, but the changes to those objects
are not logged. To enable the Directory Services Changes auditing, you can choose to enable
the Audit directory service access option in the Default Domain Controllers Policy audit
policy. When you enable this option, all subcategories are also enabled.
To enable just the Directory Service Changes subcategory, you must use the Auditpol.exe
command-line tool and run the following command:
auditpol /set /subcategory:"directory service changes" /success:enable
Windows Server 2008 also introduces subcategories under the other audit categories. The
categories, subcategories, and default settings for AD DS specific audit settings are listed in
Table 8-3. To view these audit settings, type Auditpol /get /category:* at a command prompt.
Table 8-3 Configuring Domain Controller Audit Policy Settings
Category Subcategory Default Setting
Audit logon events Logon Success and Failure
Audit logon events Logoff Success
Account Lockout Success
Audit logon events IPSec Main Mode, IPSec Extended Mode, IPSec
Quick Mode
No Auditing

Audit logon events Special Logon Success
Audit logon events Other Logon/Logoff events No Auditing
Audit logon events Network Policy Server Success and Failure
Chapter 8: Active Directory Domain Services Security 311
In most cases, if the goal of your audit policy is to audit administrator activity in AD DS, you
should accept the default domain controller audit settings. If you are using the audit policy
for other purposes, such as intrusion detection, you may want to also audit the failure of
events such as logon events or account management events. By default, if you enable auditing
for any of the categories, auditing will also be enabled for all subcategories.
Note
Configuring the audit policy is only the first step in enabling AD DS auditing. After
configuring the audit policy, you must configure the System Access Control List (SACL) on each
object to enable auditing. To do this, enable auditing for the domain or OU object in Active
Directory Users and Computers.
Configuring Domain Controller Event Log Policy Settings
When you configure the audit settings for domain controllers, you should also consider
changing the event log settings on the domain controllers. In particular, you should increase
the maximum size of the security log to accommodate the increased number of audited
events that might be generated. Table 8-4 lists the changes that are recommended for the
Event Log settings on the Default Domain Controller Policy.
Audit policy change Audit Policy Change Success
Audit policy change Authentication Policy Change Success
Audit policy change Authorization Policy Change, MPSSVC Rule-Level
Policy Change, Filtering Platform Policy Change,
Other Policy Change Events
No Auditing
Audit account
management
User Account Management Success
Audit account

management
Computer Account Management Success
Audit account
management
Security Group Management Success
Audit account
management
Distribution Group Management, Application
Group Management, Other Account
Management Events
No Auditing
Audit account logon
events
Kerberos Service Ticket Operations Success
Audit account logon
events
Other Account Logon Events No Auditing
Audit account logon
events
Kerberos Authentication Service Success
Audit account logon
events
Credential Validation Success
Table 8-3
Configuring Domain Controller Audit Policy Settings (continued)
Category Subcategory Default Setting
312 Part III: Administering Windows Server 2008 Active Directory
Security Alert To ensure that you retain the audit information, you must archive the
system and security logs regularly, and before they fill up. If you accept the recommended
settings for the retention method, the oldest events will be overwritten when the log files fill

up. If you use a retention method of Do Not Overwrite Events, new events will not be written
to the log file when it has reached its maximum size.
Table 8-4
Recommended Domain Controller Event Log Policy Settings
Policy Default Setting
Recommended
Setting
Comments
Maximum securi-
ty log size
Not defined; by de-
fault, maximum log
size is 128 MB
131,072 KB Increased to accommodate
security auditing that is enabled
in the default domain controller
Audit Policy
Prevent local
guests group
from accessing
application log
Not defined Enabled Prevents members of the built-
in group Guests from reading
the application log events
Prevent local
guests group
from accessing
security log
Not defined Enabled Prevents members of the built-
in group Guests from reading

the security log events
Prevent local
guests group
from accessing
system log
Not defined Enabled Prevents members of the built-
in group Guests from reading
the system log events
Retain security
log
Not defined (No change) Specifies the number of days
the events are retained if the
retention method for this log is
By Days
Retain system log Not defined (No change)
Retention meth-
od for security log
Not defined Overwrite events as
needed
Overwrites the security log
when the maximum log size is
reached to ensure that the
log contains the most recent
security events and to ensure
that logging continues
Retention meth-
od for system log
Not defined Overwrite events as
needed
Overwrites the system log when

the maximum log size is reached
to ensure that the log contains
the most recent security events
and to ensure that logging
continues
Chapter 8: Active Directory Domain Services Security 313
Configuring Domain Controller User Rights Assignment Policy Settings
User rights define what types of administrative or operations tasks users can perform on
domain controllers. In order to ensure domain controller security, you should configure the
user rights assignment to limit which users can log on to and perform administrative tasks
on domain controllers.
Important
Most of the default settings for the domain controller user rights and security
options are configured for optimal security. Although most of the settings are configured as
Not Defined in the Default Domain Controller Policy, almost all of the settings do have a
default value which meets security requirements. To review the default value, access the setting
properties and click on the Explain tab.
Because the default settings are configured to be secure, you do not necessarily need to enable
or disable most of the settings. However, if you do modify any of these settings at the
domain level, they will be inherited by domain controllers in the Domain Controllers OU.
Before making any changes to the security settings at the domain level, you should configure
the security settings in the Default Domain Controllers Policy to match the default setting
or block policy inheritance at the Domain Controllers OU.
Table 8-5 lists the default and recommended policy settings for domain controller user rights
assignment policies.
Table 8-5 Default and Recommended Domain Controller User Rights Assignment
Policy Settings
Policy Default Setting
Recommended
Setting

Comments
Allow log on
locally
Account Operators
Administrators
Backup Operators
Print Operators
Server Operators
Administrators
Backup Operators
Server Operators
Printers should not be installed
on domain controllers, so Print
Operators should not need to log
on to domain controllers.
Account Operators should have the
administration tools installed on
their workstations rather than
logging on to domain controllers.
Shut down the
system
Administrators
Backup Operators
Print Operators
Server Operators
Administrators
Backup Operators
Server Operators
See above.
Load and

unload device
drivers
Administrators
Print Operators
Administrators If no printers are installed on the
domain controller, Print Operators
should not be allowed modify
device driver settings.
314 Part III: Administering Windows Server 2008 Active Directory
Configuring Domain Controller Security Options Policy Settings
The Default Domain Controllers Policy includes a large number of security settings that
affect a wide variety of domain controller, network, file system, and user logon security
configuration settings. Although some of these settings will only affect domain controllers,
other settings can also affect network connectivity for client computers.
Important
Like the user rights settings, most of the security settings are configured as
Not Defined in the Default Domain Controller Policy. However, almost all of the settings do
have a default value.
Table 8-6 lists the security setting categories available in the policy.
Manage
auditing and
security log
Administrators Depends on com-
pany requirements
In some organizations, users other
than administrators may need to
access and manage the security
logs. Create a group for this specific
purpose and assign this right to
that group.

Table 8-6 Security Setting Categories
Category Description
Accounts Use these settings to enable, disable, or rename the Administrator
and Guest accounts, or to restrict access to the local accounts
with blank passwords.
Audit Use to configure global audit settings. This category contains two
settings that require some consideration:
■ Force audit policy subcategory settings (Windows Vista or
later). If you enable this option, you force all audit settings
to be made at the subcategory level rather than have the
subcategory inherit the category settings.
■ Shut down system immediately if unable to log security
audits. Enabling this option means that the domain
controller will be shut down if a security audit cannot be
logged. In most cases, you should disable this setting to
avoid domain controller shut downs.
DCOM Use to enable or disable users from launching DCOM
applications remotely or locally.
Table 8-5 Default and Recommended Domain Controller User Rights Assignment
Policy Settings (continued)
Policy Default Setting
Recommended
Setting
Comments
Chapter 8: Active Directory Domain Services Security 315
More Info For details on all of the security settings available in Windows Server 2008,
download the Group Policy Settings Reference Windows Vista spreadsheet located at
/>c0d9289f09ef&displaylang=en.
Devices Use to configure access to devices such as CD-ROMs or floppy
disks or to restrict users from installing print drivers on print servers.

Domain controller Use to set restrictions on server operators scheduling tasks using
the AT command, configure LDAP signing, and configure the
domain controller to refuse password changes from member
computers.
Domain member Use to configure network security settings and configure settings
for setting computer passwords.
Interactive logon Use to set restrictions on the interactive logon process on the
domain controllers. Options include:
■ Clearing the last user logon name
■ Configuring logon messages when users log on to the
domain
■ Configuring smart card requirements
Microsoft network client Use to configure requirements for digitally signing network
communications for client computers.
Microsoft network server Use to configure settings for digitally signing network communica-
tions and for disconnecting users when their logon hours expire.
Network access Use to configure a wide variety of network access settings including
whether to allow anonymous enumeration of SAM accounts
and configuring options for connecting to shares.
Recovery console Use to define who can access the recovery console, and if floppy
drives and other drives are accessible from the recovery console.
Shutdown Use to configure if users can shutdown the computer without
logging on and if the virtual memory pagefile should be cleared
at shut down.
System cryptography Use to enforce security requirements for keys stored on computers,
and for algorithms used to create secure keys.
System objects Use to set security requirements for Windows system objects.
System settings Use to configure additional subsystems, such as POSIX, and to
enable certificate rules for software restriction policies.
User Account Control Use to configure how user account control settings will be

applied to Windows Vista client computers.
Table 8-6
Security Setting Categories (continued)
Category Description
316 Part III: Administering Windows Server 2008 Active Directory
Implementing SMB Signing
Windows Server 2008 supports SMB signing as a means to ensure that all file share access on
domain controllers is encrypted. Computers in the same domain as the domain controller
access file shares during the user logon process to access logon scripts and profiles in the
Netlogon share. Group Policy objects are accessed through the SYSVOL share. For these
reasons, all domain controllers should take advantage of SMB signing to improve security.
Table 8-7 describes the Security Options policy settings for SMB signing.
Note
You can also enforce these options by applying an SCW policy to the domain
controllers. When you run the SCW, you have the option of configuring registry settings on
the server to enforce SMB security. Figure 8-9 shows the interface. If you select both options,
SMB signing will be enforced on the server.
Table 8-7
Security Options Policy Settings for SMB Packet Signing
SMB Setting Explanation
Microsoft network client:
Digitally sign communications
(always)
The domain controller requires SMB signing when initiating
SMB requests with other domain controllers, member servers,
or workstations. The domain controller refuses to communicate
with other systems that do not support SMB signing. For
enhanced security, enable this Group Policy setting.
Microsoft network client:
Digitally sign communications

(if server agrees)
The domain controller negotiates SMB signing when initiating
SMB requests with other domain controllers, member servers,
or workstations. The domain controller requests SMB signing,
but it will communicate with other systems that do not support
SMB signing. Enable this option only if you have Windows 95
and earlier operating systems.
Microsoft network server:
Digitally sign communications
(always)
The domain controller requires SMB signing when receiving
SMB requests from other domain controllers, member servers,
or workstations. The domain controller refuses to communicate
with other systems that do not support SMB signing. For en-
hanced security, enable this Group Policy setting. This option is
enabled by default in the Default Domain Controllers Policy.
Microsoft network server:
Digitally sign communications
(if client agrees)
The domain controller negotiates SMB signing when receiving
SMB requests with other domain controllers, member servers,
or workstations. The domain controller requests SMB signing,
but it will communicate with other systems that do not support
SMB signing. This option is enabled by default in the Default
Domain Controllers Policy.
Chapter 8: Active Directory Domain Services Security 317
Figure 8-9 Configuring SMB signing by using the SCW.
Configuring SYSKEY
By default, the AD DS data store is encrypted when it is stored on the domain controller
hard disk. This provides a level of security if an attacker gains access to the physical hard disk

on which the data store is located. The data is encrypted by using the system key (SYSKEY)
in Windows Server 2008.
You can use the SYSKEY tool to provide an extra level of security when domain controllers
start up. SYSKEY gives you three options for configuring the startup key:
■ Store Startup Key Locally This option creates a machine-generated random key stored
on the local system by using a complex encryption algorithm. This is the default
configuration of Syskey.exe, and it provides strong encryption of password information
in the registry. Because the System Key is stored on the local system, this method allows
for unattended system restarts.
■ Password Startup This option requires an administrator-chosen password to derive
the System Key. If you select this option, an administrator must enter System Key
password during system startup.
■ Store Startup Key on Floppy Disk This option creates a machine-generated random
key that stored on a floppy disk. The floppy disk with the System Key must be inserted
into the floppy drive to start the domain controller.
Configuring SYSKEY to use a password or floppy disk to start may provide an additional level
of security for domain controllers that are not physically secure. However, this option also
requires that an administrator who knows the password be present or that the floppy disk be
318 Part III: Administering Windows Server 2008 Active Directory
available when the domain controller is restarted. If you do store the SYSKEY on a floppy disk
and the disk is lost, you will not be able to restart the domain controller.
Note
Consider using an RODC in situations where the domain controller cannot be
physically secured, rather than implementing SYSKEY security settings.
Designing Secure Administrative Practices
One of the most important components in designing AD DS security is designing secure
administrative practices. Because administrators have full control of the AD DS environment,
they can circumvent or modify even the best security design. When creating your administra-
tive practices, consider the following suggestions:
■ Limit the number of enterprise and domain administrator accounts to highly trusted

personnel. This is particularly important for service administrator accounts. Keep the
membership of service administrator accounts to the absolute minimum and assign
only reliable, trusted users who fully understand the implications of any changes made
to the directory. Do not use service administrator accounts for day-to-day administrative
tasks.
■ Implement a change control process. All changes made in an AD DS environment
should be subject to a change control process. This is particularly important for changes
that have an impact on the entire directory service environment. For example, schema
changes should be implemented only after careful planning and testing and after
approval from the forest owners.
■ Limit the Schema Admins group to temporary members. Most organizations will change
the schema very rarely, so no one needs to be logged on as a schema administrator
on a regular basis. To secure the schema change process, keep the membership of
the Schema Admins group empty. Add a trusted user to the group only when an admin-
istrative task must be performed on the schema. Remove that user after the task is
completed.
■ Use a Restricted Group policy to restrict the membership for the critical domain and
forest accounts. When you implement a Restricted Group policy, the group membership
is monitored by the domain controllers and any users that are not included in the
Restricted Group Policy are automatically removed.
■ Ensure that administrators have and use two different accounts. For users who fill
administrative roles, create two accounts: one regular user account to be used for
normal, day-to-day tasks and one administrative account to be used only for performing
administrative tasks. The administrative account should not be mail-enabled or used
for running applications that are used every day, such as Microsoft Office, or for
browsing the Internet.
Chapter 8: Active Directory Domain Services Security 319
■ Apply the principal of least privileges for all administrative groups. Carefully define the
permissions that are actually required for each administrative group and then assign
only those permissions. For example, if an administrator needs to manage only specific

users accounts or computer accounts, or manage only some settings for these accounts,
create an OU to contain these accounts, and then delegate permissions to the adminis-
trative account. Also avoid using the Account Operators group to assign permission to
configure user and group accounts. The default directory permissions give this group
the ability to modify the computer accounts of domain controllers, including deleting
them. By default, there are no members of the Account Operators group, and its
membership should be left empty.
■ Hide the domain administrator account. Every installation of AD DS has an account
named Administrator in each domain. This is the default administrative account, which
is created during domain setup, that you use to access and administer the directory
service. This is a special account that the system protects to help ensure that it is avail-
able when needed. This account cannot be disabled or locked out. You should rename it
to something other than Administrator. When you rename the account, make sure that
you also change the text in the Description for the account. In addition, you should
create a decoy user account called Administrator that has no special permissions or user
rights and monitor for event IDs 528, 529, and 534 in connection with both the
renamed and decoy accounts.
■ Never share administrator accounts. In some organizations, all senior administrators
know the password for the default Administrator account, and all of them use this
account to perform administrative tasks. Sharing administrator accounts makes it
impossible to accurately audit who made the changes to the directory, so this practice is
strongly discouraged. Sharing administrator accounts and passwords can also create a
security problem as administrators leave the team or company.
■ Secure the Administrative logon process. To minimize the chances of someone misusing
or compromising an administrator account, consider taking these steps to enforce
strong administrative credentials:
❑ Require smart cards for administrative logon. Have service administrators use
smart cards for their interactive logons. In addition to forcing the administrative
users to have physical possession of the cards to log on, smart cards also ensure
the use of randomly generated, cryptographically strong passwords on the user

accounts. These strong passwords help to protect against the theft of weak
passwords to gain administrative access. You can enforce the use of smart cards
by enabling the Interactive logon: Require smart card security option for each
administrative account.
❑ Split the logon credentials for sensitive administrative accounts. For each account
that is a member of the Enterprise Admins and Domain Admins groups in the
forest root domain, assign two users to share that account, so that both users
must be present to log on successfully with that account. You can split the logon
320 Part III: Administering Windows Server 2008 Active Directory
credentials by using either split passwords (where each administrator only knows
part of the password) or split smart cards plus personal identification numbers
(PINs).
■ Secure service administrator workstations. In addition to configuring administrator
account security, you should also ensure the security of the administrator workstations.
To do this, consider implementing the following processes:
❑ Restrict which workstations service administrators can log on to. Each administra-
tive account can be restricted so that it is allowed to log on only to specific work-
stations. If one of your administrative accounts is compromised, limiting the
possible workstations limits the number of locations where that account can be
used.
❑ Apply a special security policy to the administrator workstations. Consider
moving all of the service administrator workstations into a dedicated OU and then
apply a highly secure policy for the workstations. For example, you might limit
the Allow Log On Locally user right to the service administrator accounts.
❑ Ensure that administrative workstations have all security updates installed and
the antivirus software on the workstations is current.
❑ Encourage administrators to use Remote Desktop to perform administrative tasks.
You can enable Remote Desktop on any Windows Server 2008 server and
configure the security settings so that only specified administrators can connect to
the server through Remote Desktop. If you install the Remote Desktop 6 client

on Windows XP clients or use a Windows Vista client, you can enforce network
encryption for all Remote Desktop connections.
■ Secure backup media. When you back up the domain controllers in your organization,
the entire directory store is copied to the backup media. Although the data is encrypted,
an attacker who gains access to the tapes will have unlimited time to decrypt and gain
access to the data. You can help prevent unauthorized users from gaining physical
access to backup media by doing the following:
❑ Store backup media that is used on-site in a secure location where access is
audited.
❑ Store archival backup media securely off-site.
❑ Establish secure processes for transporting backup media.
■ Set object ownership quotas. On domain controllers that are running Windows
Server 2008, you can set quotas that limit the number of objects that a security principal
(user, group, computer, or service) can own in a domain, configuration, or application
directory partition. By default, the security principal that creates an object is the object
owner, although ownership can be transferred. AD DS quotas eliminate the ability to
create unlimited numbers of objects in a directory partition, which can be used for
denial-of-service attacks. By default, quotas are not set; therefore, there are no limits to
Chapter 8: Active Directory Domain Services Security 321
the number of objects that any security principal can own. To set quotas, use the Dsmod
Quota command.
Summary
This chapter provided a brief overview of the basic concepts of Windows Server 2008 AD DS
security, including the security principals, access control lists, authentication, and authoriza-
tion. The first part of this chapter focused on the primary means of providing authentication
and authorization in AD DS through the Kerberos protocol. Kerberos provides a secure
mechanism for users to authenticate to AD DS and to gain access to network resources.
The second component to providing AD DS security is to secure domain controllers and
implement secure administrative practices. The second part of this chapter provided details
on how to implement this type of security.

Best Practices
■ If possible, upgrade all servers and workstations to at least Windows Server 2000 with
the latest service packs. By doing this, you can ensure that Kerberos is used for all
authentication requests, and you can configure security features like SMB signing on
domain controllers.
■ Implement dedicated domain controllers. In other words, do not run applications or
services that are not required on domain controllers. Doing so makes it easier to reduce
the attack surface of the domain controllers and also makes it easier to create one SCW
policy that can be applied to all domain controllers.
■ Implement a complex password policy and encourage administrators to configure
extremely complex passwords. Suggest that administrators use pass phrases rather than
just passwords.
■ Assign the least permissions possible to all administrator accounts. Ensure that all
administrators only have permission to perform the tasks required for their jobs.
Additional Resources
These resources contain additional information related to this topic:
Related Information
■ Chapter 5, “Designing the Active Directory Domain Services Structure,” goes into detail
on designing secure AD DS boundaries.
■ Chapter 9, “Delegating the Administration of Active Directory Domain Services,”
explains how to delegate administrative permissions within AD DS. This is useful when
applying the least permission standard.
322 Part III: Administering Windows Server 2008 Active Directory
■ Chapter 11, “Introduction to Group Policy,” goes into detail about how to configure
Group Policy, including how to enable and block Group Policy inheritance. You may
want to block Group Policy inheritance at the Domain Controllers OU to prevent
domain level security settings from being applied to domain controllers.
■ Chapter 13, “Using Group Policy to Manage Security,” provides information on
additional Group Policy settings that are available to configure security.
■ “The Kerberos Network Authentication Service (V5),” available at />rfc/rfc1510.txt, describes the current Kerberos standard.

■ “Kerberos Authentication Technical Reference,” available at />windowsserver/en/library/74d58697-970a-45db-9139-ebcd3db051181033.mspx?mfr=true
■ “Authorization and Access Control Technologies,” available at http://
technet2.microsoft.com/windowsserver/en/library/74d58697-970a-45db-9139-
ebcd3db051181033.mspx?mfr=true
■ “Troubleshooting Kerberos,” available at />en/library/26ce2e7f-52d6-4425-88cc-1573bc5e646d1033.mspx?mfr=true
■ “Troubleshooting Kerberos Errors,” available at />prodtechnol/windowsserver2003/technologies/security/tkerberr.mspx
Related Tools
Windows Server 2008 provides several tools that can be used when troubleshooting Kerberos
authentication. Table 8-8 lists some of these tools and when you would use each of the tools.
Table 8-8 Kerberos Troubleshooting Tools
Tool Name Description and Use
Klist.exe: Kerberos List This tool is installed on Windows Server 2008 domain controllers and is
available for download as part of the Windows Server 2003 Resource Kit
tools.
Kerberos List is a command-line tool that is used to view and delete
Kerberos tickets granted to the current logon session. To use Kerberos
List to view tickets, you must run the tool on a computer that is a
member of a Kerberos realm.
Kerbtray.exe: Kerberos
Tray
Kerberos Tray is available for download as part of the Windows Server
2003 Resource Kit tools.
Kerberos Tray is a graphical user interface tool that displays ticket
information for a computer running Microsoft’s implementation of
the Kerberos version 5 authentication protocol. You can view and purge
the ticket cache by using the Kerberos Tray tool icon located in the
notification area of the desktop. By positioning the cursor over the icon,
you can view the time left until the initial TGT expires. The icon also
changes in the hour before the Local Security Authority (LSA) renews the
ticket.

Chapter 8: Active Directory Domain Services Security 323
Resources on the CD
■ SampleDC_SCWPolicy.xml. This is a sample Security Configuration Wizard file that
configures the services, Windows Firewall, and registry settings for a Windows Server
2008 domain controller.
Related Help Topics
■ Security Configuration Wizard help
Tokensz.exe
Kerberos Token Size
Kerberos Token Size is available for download from the Microsoft
download center.
You can use Kerberos Token Size to verify if the source of the Kerberos
errors stems from a maximum token size issue. The tool will simulate
an authentication request and report the size of the resulting Kerberos
token. The tool will also report the maximum supported size for the token.
Setspn.exe The Setspn utility is installed on Windows Server 2008 domain control-
lers and is included in the Windows Server 2003 Support Tools.
The Setspn utility allows you to read, modify, and delete the Service
Principal Names (SPN) directory property for an Active Directory service
account. Because SPNs are security-sensitive, you can only set SPNs for
service accounts if you have domain administrator privileges.
Ksetup.exe The Ksetup utility is installed on Windows Server 2008 domain
controllers and is included in the Windows Server 2003 Support Tools.
The Ksetup utility configures a client connected to a server running
Windows Server 2008 to use a server running Kerberos V5. The client
then uses a Kerberos V5 realm instead of a Windows Server 2008 domain.
Ktpass.exe The Ktpass utility is installed on Windows Server 2008 domain controllers
and is included in the Windows Server 2003 Support Tools.
The Ktpass utility is used to configure a non–Windows Server Kerberos
service as a security principal in the Windows Server 2008 AD DS.

W32tm.exe: Windows
Time
This tool is included in Microsoft Windows server and client operating
systems.
W32tm.exe is used to configure Windows Time service settings. It can
also be used to diagnose problems with the time service.
Table 8-8
Kerberos Troubleshooting Tools (continued)
Tool Name Description and Use

325
Chapter 9
Delegating the Administration
of Active Directory Domain
Services
In this chapter:
Active Directory Administration Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 326
Accessing Active Directory Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 327
Active Directory Object Permissions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 329
Delegating Administrative Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345
Auditing the Use of Administrative Permissions. . . . . . . . . . . . . . . . . . . . . . . . . . . 348
Tools for Delegated Administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 352
Planning for the Delegation of Administration . . . . . . . . . . . . . . . . . . . . . . . . . . . 354
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 355
Additional Resources. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 356
Active Directory Domain Services (AD DS) is typically deployed as a common directory
service shared between various business divisions within an organization. Using a common
directory service helps reduce the costs associated with maintaining the infrastructure, but
introduces a number of other considerations:
■ How to manage users and resources independently between divisions when

decentralized administration is required
■ Ensuring that administrators or users can only perform permitted tasks within their
own business division
■ Ensuring that specific objects or information stored within the directory is only
available to administrators with the appropriate permissions
These considerations can be addressed by a thorough understanding of how to delegate
administrative tasks. Delegation involves a higher-level administrator granting permissions to
other users to perform specific administrative tasks within the Active Directory structure.
The Active Directory structure provides a hierarchical view of the directory service: first at the
site and domain level, and then at the organizational unit (OU) level within a domain. This
hierarchy provides powerful options for managing permissions and delegating administrative
tasks at various levels throughout the logical infrastructure.
326 Part III: Administering Windows Server 2008 Active Directory
This chapter describes administrative delegation, starting with a discussion of the various
types of tasks that might be delegated within an enterprise. Then it describes object access,
the types of permissions that can be assigned to objects residing within the directory, and
how to use these permissions for delegation of administration. Finally, the chapter provides
information about auditing changes to objects residing within AD DS.
Active Directory Administration Tasks
Active Directory administration tasks typically fall into one of two categories—data manage-
ment or service management. Data management tasks relate to the management of content
that is stored within the Active Directory database. Service management tasks relate to the
management of all aspects that are required to ensure a reliable and efficient delivery of the
directory service throughout the enterprise.
Table 9-1 describes some of the tasks that are related to each of these categories.
Table 9-1 Active Directory Administration
Category Tasks
Data management
■ Account management—includes creating, maintaining, and
removing user accounts

■ Security group management—includes creating security
groups, provisioning security groups to grant access to network
resources, managing memberships of security groups, and
removing security groups
■ Resource management—includes all aspects of managing
network resources such as end-user workstations, servers, and
resources hosted on servers such as file shares or applications
■ Group Policy management—includes all aspects of creating,
assigning, and removing Group Policy objects within the Active
Directory structure
■ Application-specific data management—includes all
aspects of managing Active Directory-integrated or enabled
applications such as Microsoft Exchange Server
Service management ■ Installation and trust management—includes aspects such
as the creation and deletion of domains, the deployment of
domain controllers, and the configuration of appropriate Active
Directory functional levels
■ Domain controller and directory database management—
includes aspects related to the management of domain control-
ler hardware, database maintenance, and the application of
service packs and security updates
■ Schema management—includes the extension or modification
of the schema to support the deployment of Active Directory-
enabled applications
Chapter 9: Delegating the Administration of Active Directory Domain Services 327
More Info For more information about the tasks related to data management and service
management, refer to “Best Practices for Delegating Active Directory Administration” found
at />activedirectory/actdid1.mspx.
Delegating data and service management tasks within an organization requires an under-
standing of the administrative needs of all business units. This understanding ensures

the most effective delegation model used to provide a more effective, efficient, and secure
networking environment. To deploy the delegation model, you need to understand
Active Directory object permissions, delegation methods, and auditing. These concepts are
discussed in the next few sections.
Accessing Active Directory Objects
To effectively delegate administrative tasks, you need to know how Active Directory controls
access to objects stored within the directory service. Access control involves the following:
■ Credentials of the security principle attempting to perform the task or access the
resource
■ Authorization data used to protect the resource or authorize the task being performed
■ An access check that compares the credentials against the authorization data to deter-
mine if the security principle is permitted to access the resource or perform the task
When a user logs on to an AD DS domain, authentication takes place and the user receives an
access token. An access token includes the security identifier (SID) for the user account,
SIDs for each security group of which the user is a member, and a list of privileges held by the
user and the user’s security groups. The access token helps to provide the security context
■ Operations master roles management—includes tasks that
ensure the proper assignment and configuration of operations
master roles
■ Backup and restore management—includes all tasks related
to performing regular backups of the directory database and
restore procedures when required
■ Replication management—includes all tasks related to the
creation, maintenance, and monitoring of the replication topology
■ Security policy management—includes all tasks related to
the management of the default domain controller security policy
and managing the password, account lockout, and Kerberos
account policies
Table 9-1 Active Directory Administration (continued)
Category Tasks

328 Part III: Administering Windows Server 2008 Active Directory
and credentials needed to manage network resources, perform administrative tasks, or access
objects residing in Active Directory.
Security is applied to a network resource or an Active Directory object by authorization data
that is stored in the Security Descriptor of each object. The Security Descriptor consists of
the following components:
■ Object owner The SID for the current owner of the object. The owner is typically the
creator of the object or a security principal that has taken over ownership of an object.
■ Primary group The SID for current owner’s primary group. This information is only
used by the Portable Operating System Interface for UNIX (POSIX) subsystem.
■ Discretionary access control list (DACL) A list of access control entries (ACEs) that
define the permissions each security principle has to an object. Each security principal
that is added to the access control list obtains a set of permissions that specify the extent
to which that user or group can manipulate the object. If a user does not appear in an
ACE, either individually or as a member of a group, that user has no access to the object.
■ System access control list (SACL) Defines the audit setting on an object including which
security principle is to be audited and the operations that are to be audited.
Figure 9-1 illustrates the architecture of a user’s access token and an object’s security descrip-
tor. When a user tries to access a network resource or an Active Directory object, an access
check is performed and each ACE is examined until a User or Group SID match is found.
Access is then determined by the permissions configured on the ACE.
Figure 9-1 Access check between a user’s access token and an object’s security descriptor.
User SID
Group SIDs
Access
check
List of privileges
and other access
information
User

Access Token
Owner’s SID
SACL
ACE
ACE
Primary Group SID
Object
Security Descriptor
DACL
ACE
ACE
ACE
ACE
Chapter 9: Delegating the Administration of Active Directory Domain Services 329
Evaluating Deny and Allow ACEs in a DACL
ACEs are listed within a DACL in a specific order, which has a direct affect on the outcome of
the access check. During an access check, ACEs are evaluated in sequence. The evaluation
sequence is listed as follows:
■ ACEs that have been explicitly assigned are evaluated before inherited ACEs.
■ For each set of explicit or inherited ACEs, Deny ACEs are always evaluated before Allow
ACEs.
Figure 9-2 illustrates how Allow and Deny permissions are evaluated for both explicit and
inherited ACEs.
Figure 9-2 Evaluating Allow and Deny ACEs.
Active Directory Object Permissions
Every object in Active Directory has an access control list (ACL), which means that you can
modify the permissions on that object. This includes objects visible through the Active Direc-
tory Users And Computers administrative console as well as objects visible through the Active
Directory Sites and Services administrative console, ADSI Edit, or Ldp.exe. The most common
tool used to modify Active Directory object access is Active Directory Users And Computers.

However, each of the previously mentioned tools can be used to perform the common task of
managing object access within the directory service.
Access control permissions on an Active Directory object are separated into two categories:
standard permissions and special permissions. Special permissions are granular options that can
be applied to an object. A standard permission is made up of a group of special permissions
to allow or deny a specific function. For example, the Read standard permission is made up of
the Read permissions, List contents, and Read all properties special permission entries.
Object
Security Descriptor
DACL
Deny ACE 1 (Explicit)
Deny ACE 2 (Explicit)
Allow ACE 1 (Explicit)
Allow ACE 2 (Explicit)
Deny ACE 1 (Inherited)
Deny ACE 2 (Inherited)
Allow ACE 1 (Inherited)
Allow ACE 2 (Inherited)
330 Part III: Administering Windows Server 2008 Active Directory
Standard Permissions
To view the standard permissions for any Active Directory object in the domain directory par-
tition, access the Security page for that object’s Properties sheet in the Active Directory Users
And Computers administrative console.
Note
If the Security page is not visible, select Advanced Features on the View menu and
then reselect the object and open its Properties sheet.
The Security page displays the group or user names that are assigned permissions to the
object. As you select a group or user entry, the associated allow or deny permissions for that
entry are shown. Figure 9-3 illustrates the permissions for the Domain Admins group on the
Sales organizational unit. Notice that, by default, the Allow box is checked for each permission

to provide the Domain Admins group full control over the Sales OU.
Figure 9-3 Viewing the Security page on an Organizational Unit object.
Depending on the type of object being secured, you will notice that different permissions may
be visible on the security page. For example, the following standard permissions are common
with all objects:
■ Full control
■ Read
■ Write
■ Create all child objects
■ Delete all child objects
Chapter 9: Delegating the Administration of Active Directory Domain Services 331
Some Active Directory objects also have standard permissions that are applied to grouped sets
of properties. For example, a user object has several read-and-write property sets such as Gen-
eral Information, Personal Information, Phone And Mail Options, and Web Information. Each
of these property sets refers to a set of object attributes, so granting access to a single property
set provides access to a set of attributes. For example, the Personal Information property set
includes attributes such as homePhone, homePostalAddress, and streetAddress. Using the prop-
erty sets to assign access to groups of attributes simplifies the process of assigning permis-
sions without having to modify at the granular attribute level.
Note
The Active Directory schema defines which attributes are part of each property set by
using the rightsGuid value for the property category (in the Configuration directory partition)
and the attributeSecurityGUID for the schema object. For example, the rightsGuid value for
cn=Personal-Information, cn=Extended-Rights, cn=configuration, dc=forestname is equiva-
lent to the attributeSecurityGUID for cn=Telephone-Number, cn=Schema, cn=Configuration,
dc=forestname. This means that the telephone number is included in the Personal Information
property set.
In addition to the standard permissions, the Security page may also show extended rights
related to the object being secured. Depending on the object, these rights include options
such as Allowed To Authenticate, Generate Resultant Set Of Policy, Receive As, Send As, Send

To, Change Password, and Reset Password.
Special Permissions
One of the entries in the permissions list on the Security page is Special Permissions. In addi-
tion to being able to grant standard permissions, you can also grant special permissions to
Active Directory objects.
Note
You can determine if special permissions are applied to an object by viewing the Allow
or Deny check boxes located next to the Special Permissions entry. If a check mark is visible,
special permissions have been assigned.
As mentioned previously, special permissions are much more granular and specific than
standard permissions. To simplify management, you would typically use standard permis-
sions on an object; however, there may be specific needs that require you to modify the special
permission entries.
To get access to special permissions, click Advanced on the Security page and then ensure that
the Permissions page is selected. Figure 9-4 shows the interface. Table 9-2 explains the
options available on the Permissions page.
332 Part III: Administering Windows Server 2008 Active Directory
Figure 9-4 Viewing the Advanced Security Settings for an object.
Table 9-2
Special Permissions Configuration
Option Explanation
Type This value is set to either Allow or Deny. Normally, the interface sorts
the permissions so that all Deny permissions are listed first, but the
sort order can be changed by clicking any column header. Regardless
of the order of appearance in this column, the Deny permissions are
always evaluated first.
Name This is the name of the security principal to which each ACE applies.
Permission This column lists the level of permission granted for the security
principal. Levels of permission can be standard rights, such as Full
Control; special permissions such as Create/Delete User Objects; or

just Special. The types of permissions available depend on the type of
object and how granular the permission entry is.
Inherited From This column lists the location where this permission is set and if the
permission is inherited from a parent container.
Apply To This column specifies the depth to which this permission applies. It
has a variety of settings, including This Object Only, This Object
And All Descendant Objects, All Descendant Objects, as well as many
others.
Include Inheritable Permis-
sions From This Object’s
Parent
This option allows you to specify if parent permission entries are to be
applied to the object.
Add/Edit/Remove buttons These buttons allow you to add new ACEs, remove existing ACEs, or
edit a specific ACE to provide more granular permission settings.