Introducing Windows Server 2008 - Chapter 7: Active Directory Enhancements
An Author's Life
If you think you IT pros lead a busy life, you wouldn't want to be an IT pro and an author at the same time! Immediately after finishing off almost a year of work as lead author of the Windows Vista Resource Kit, Microsoft Press invited me to author their first book about Windows Server 2008 (formerly Windows Server Code-Name "Longhorn"). After six frenzied weeks of writing and over 2000 email discussions with the Windows Server product team, my book Introducing Windows Server 2008 is finished and is now available for pre-order on Amazon (the book will ship around the end of May). Most of this book is based on near-Beta 3 builds of Windows Server 2008, but to ensure that all the content is technically accurate for RTM, I had the help of almost one hundred members of the Windows Server team at Microsoft who acted as peer reviewers for the book's content. These experts (and clearly those who are actually developing Windows Server 2008 know more about this product than anyone else) also added a ton of value to my book by contributing almost a hundred "From The Experts" sidebars that provide deep technical insights about how Windows Server 2008 works and how to deploy, configure, maintain and troubleshoot its various roles and features.
Here's a breakdown of the various chapter titles so you can see what topics are covered:
- Usage Scenarios
- Windows Server Virtualization
- Managing Windows Server 2008
- Managing Server Roles
- Windows Server Core
- Active Directory Enhancements
- Terminal Services Enhancements
- Clustering Enhancements
- Implementing Network Access Protection
- Internet Information Services 7.0
- Other Features and Enhancements
- Deploying Windows Server 2008
- Additional Resources
And to whet your appetite a bit so that you'll run out and order this title, here are two brief excerpt from Chapter 7 that deal with new features of Active Directory in Windows Server 2008. The first excerpt deals with enhancements to auditing of Active Directory:
AD DS Auditing Enhancements
The first enhancement we’ll look at is AD DS auditing. In the current platform, Windows Server 2003 R2 (and in Windows Server 2008 also), you can enable a global audit policy called Audit Directory Service Access to log events in the Security event log whenever certain operations are performed on objects stored in Active Directory. Enabling logging of objects in Active Directory is a two-step process. First, you open the Default Domain Controller Policy in Group Policy Object Editor and enable the Audit Directory Service Access global audit policy found under Computer Configuration\Windows Settings\Security Settings\Local Policies\Audit Policy.
Figure 1: Enabling success auditing for directory service access
Then you configure the system access control list (SACL) on the object or objects you want to audit. For example, to enable Success auditing for access by Authenticated Users to User objects stored within an organizational unit (OU), you do the following:
Open Active Directory Users and Computers, and make sure Advanced Features is selected from the View menu.
Right-click on the OU you want to audit, and select Properties.
Select the Security tab, and click Advanced to open the Advanced Security Settings for the OU.
Select the Audit tab, and click Add to open the Select User, Computer or Group dialog.
Type Authenticated Users, and click OK. An Auditing Entry dialog opens for the OU.
In the Apply Onto list box, select Descendant User Objects.
Select the Write All Properties check box in the Select column.
Figure 2: Configuring auditing (continued)
Click OK to return to Advanced Security Settings for the OU, which should now show the new SACL you configured.
Figure 3: Configuring auditing (finished) (Click to enlarge image)
Close all dialog boxes by clicking OK as needed.
Now if you go ahead and change a property of one of the user accounts in your OU—for example, by disabling an account—an event should be logged in the Security log with event ID 4662 and source Directory Service Access to indicate that the object was accessed.
Figure 4: Audit success event in the Security log (Click to enlarge image)
So far, this is the same in Windows Server 2008 as in previous versions of Windows Server. What’s new in Windows Server 2008, however, is that while in previous Windows Server platforms there was only one audit policy (Audit Directory Service Access) that controlled whether auditing of directory service events was enabled or disabled, in Windows Server 2008 this policy has been divided into four different subcategories as follows:
Directory Service Access
Directory Service Changes
Directory Service Replication
Detailed Directory Service Replication
One of these subcategories—Directory Service Changes—has been enhanced to provide the ability to audit the following changes to AD DS objects whose SACLs have been configured to enable the objects to be audited:
Objects that have had an attribute modified will log the old and new values of this attribute in the Security log.
Objects that are newly created will have the values of their attributes at the time of creation logged in the Security log.
Objects that are moved from one container to another within a domain will have their old and new locations logged in the Security log.
Objects that are undeleted will have the location to which the object has been moved logged in the Security log.
The usefulness of this change should be obvious to administrators concerned about maintaining an audit trail of changes made to Active Directory, and auditing actions like these is an important part of an overall Identity and Access (IDA) strategy for an organization. For instance, using the Security log and filtering for a particular User object, you can now track in detail all changes to the attributes of that object over the entire lifetime of the object. When you enable Success auditing for the Audit Directory Service Access global audit policy (and this policy has Success auditing enabled for it by default within the Default Domain Controllers Policy), the effect of this is to also enable Success auditing for the first of the four subcategories (Directory Service Access) described earlier, which audits only attempts to access directory objects. If you need to, however, you can selectively enable or disable Success and/or Failure auditing for each of these four auditing subcategories individually by using the Auditpol.exe command-line tool included in Windows Server 2008. For example, if you wanted to enable Success auditing for the second subcategory (Directory Service Changes) so that you can maintain a record of the old and new values of an object’s attribute when the value of that attribute is successfully modified, you can do so by typing auditpol /set /subcategory:“directory service changes” /success:enable at a command prompt on your domain controller. If we do this in the preceding example and then enable the user account we disabled previously, three new directory service audit events are added to the Security log.
Figure 5: Granular auditing event (Click to enlarge image)
The first (earliest) of these events is 4662, indicating the User object has been accessed, while the second event (5136) records the old value of the attribute modified and the third event (also 5136) records the new value of the attribute. Table 7-1 lists the possible event IDs for Directory Service Changes audit events.
An attribute of the object has been modified.
The object was created.
The object has been undeleted.
The object has been moved within the domain.
In addition to enabling you to track the history of an object this way, Windows Server 2008 also gives you the option of setting flags in the Active Directory schema to specify which attributes of an object you want to track changes for and which attributes you don’t want to track changes for. This can be very useful because tracking changes to objects can lead to a whole lot of audit events and your Security log can fill up awfully fast.
The second brief excerpt from my book is a "From The Experts" sidebar that discusses some advanced issues surrounding the use of DNS servers with Read-Only Domain Controllers (RODCs) (RODCs are another new feature of Active Directory in Windows Server 2008). This sidebar gives you a taste of the kind of high level technical detail that is provided by many of these expert sidebars:
From the Experts: Advanced Considerations for DNS on RODCs in Branch Office Sites
When installing a Windows Server 2008 Read Only Domain Controller (RODC) in a branch office site, using the Active Directory Installation Wizard or the DCPromo command-line tool, you are prompted to specify a DNS domain for the Active Directory domain that you are joining the RODC to during promotion. During this process, you are prompted with DNS Server installation options. A DNS Server is required to locate domain controllers and member computers in an Active Directory domain, both in the hub site and the local branch office site. The default option is to install a DNS Server locally on the RODC, which replicates the existing AD-integrated zone for the domain specified and adds the local IP address in the DNS Server list of the domain controller local DNS Client setting.
As a best practice, Microsoft recommends that client computers have Dynamic DNS updates turned on by default and that DHCP Servers be used to configure the DNS Server list. Similarly for branch office sites, clients should be configured to use Dynamic DNS updates, and you should set the Primary DNS Server or use DHCP to set the DNS Server list to direct clients to the DNS Server running on the RODC.
If there is only one DNS Server and RODC running in the branch office site, Microsoft recommends that client computers also point to a DNS Server running on a domain controller in the hub site. This can be done either by configuring clients with an Alternate DNS Server for the hub-site DNS Server or by configuring DHCP Servers to set the DNS Server list to first the local DNS Server and then the remote DNS Server in the hub site. The DNS Server on the RODC should be the first DNS Server in the list to optimize resolution performance for branch office clients.
In larger branch office scenarios, if setting up two or more RODCs in a site, you are provided the default option to install DNS Server locally on all the RODCs. Within the same site, the RODCs do not replicate directly with each other. The RODCs rely mainly on replication with domain controllers in the hub site during scheduled intervals to refresh local data in the directory. Hence, a branch office DNS Server on an RODC receives updated DNS zone data during the normal replication cycle from a hub-site domain controller connected to the local RODC.
In addition to replication from the hub site, DNS Servers on RODCs also attempt to replicate local data after receiving a client update request. The branch office DNS Server redirects the client to a hub-site DNS Server on a domain controller that is writeable and can process the update. Shortly thereafter, it attempts to contact a hub-site domain controller to update its local copy of the data with the changed record. Any other branch office DNS Server on RODCs on the site do not attempt to obtain a local copy of the single record update because they did not receive the original client update request. This mechanism has the advantage of allowing an updated client record to be resolved quickly within the branch office, without necessitating frequent and large replication requests for all domain data from the hub site. If network connectivity is lost, or no domain controller in the hub site is able to provide the updated record data to the DNS Server in the branch office, the record will be available locally only after the next scheduled replication from the hub-site domain controllers, and it will be available to all RODCs in the branch office site.
As a consequence of a DNS Server’s attempt to replicate individual records between replication cycles, if DNS zone data is stored across multiple RODCs, the local branch office records might accumulate some incongruities. To ensure a high level of consistency for DNS data, the recommendation is to configure all client computers in the branch office site with the same DNS Server list—for example, by using DHCP.
If, however, in the more rare case that timely resolution of local branch office client records is absolutely critical, to avoid any inconsistencies for resolution, you can install DNS Servers on all RODCs in the site, but point clients only to a single DNS Server.
Well, that's a brief peek at Introducing Windows Server 2008 from Microsoft Press. If you're keen on learning more about Microsoft's new Windows Server operating system as it rolls towards RTM later this year, you should pre-order this book today from Amazon! And be sure to check out my website www.mtit.com as well for more information about this title and other books I've written.