|Laura E. Hunter|
Now we'll further refine our discussion to focus on new Active Directory features that are specific to the first service pack for Windows Server 2003.
Changes to the default tombstone lifetime
Several changes in Service Pack 1 have to do with the way Active Directory handles "tombstoned" objects. Just like in Windows 2000, when you delete an AD object, it is not immediately deleted; instead, it's marked as a tombstoned object. This allows the deletion to be replicated properly to other domain controllers. Once an object has been in this tombstoned state for a certain amount of time, it is finally deleted outright.
In Windows 2000, the default tombstone lifetime was 60 days. However, in Windows Server 2003, Microsoft changed it to 180 days, effectively tripling the amount of time that a deletion had to be communicated to all of the domain controllers in your environment.
There are two crucial caveats to keep in mind concerning this tombstone lifetime value:
- If you have already installed Active Directory using either Windows 2000 or the original Windows Server 2003 media, the default tombstone lifetime will not automatically change when you upgrade to Windows Server 2003 SP1. You will only receive the 180-day tombstone lifetime value automatically by building a pristine 2003 SP1 Active Directory forest.
- Several months ago, Microsoft Active Directory MVP Joe Richards discovered that the version of Dcpromo that comes with Windows Server 2003 R2 will revert this value back to its original setting of 60 days. Therefore, if you build a brand-new Active Directory forest using Windows Server 2003 R2 media, you will still receive the original 60-day default tombstone lifetime.
SID History added to tombstoned object attributes
In addition to modifying the tombstone lifetime for new Active Directory installations, 2003 Service Pack 1 added the SID History attribute to the list of attributes that are retained when an object is tombstoned. When an Active Directory object is tombstoned, it is stripped of most of its attributes, so the tombstoned object only takes up a fraction of the size of the original object within the Active Directory database. Each user, group and computer object within Active Directory is assigned a numeric security identifier, or SID. SIDs are unique within the domain and do not change, even if the security principal is renamed or moved to another container within the same domain.
Note: The SID is not retained if an object is deleted and re-created with the same display name; the re-created object would be a brand new object with a completely different SID.
All access control lists (ACLs) on files, folders or AD objects use the SID to determine whether a particular user or computer should be granted or denied access.
The notion of SIDs can become problematic, though, when you begin migrating from Windows NT domains into new Active Directory environments. If you migrate a user object from a legacy NT domain into a new Active Directory domain, a new SID will be created for the migrated user that corresponds to the new domain. If this migrated user still requires access to resources in the old NT domain, however, an issue will crop up in which the new Active Directory SID would not match the old NT4 SID.
To prevent this from happening, Windows 2000 introduced a feature called SID History, which allows migrated user objects to retain records of any old SIDs they once possessed. This allows a migrated user to continue to access a resource that used his old SID in its Access Control List. If the user attempted to access the resource with his current SID and was denied, Windows would check the SID History attribute to see if any previous SIDs would fit the bill and allow access.
Prior to Windows Server 2003 SP1, one of the attributes that was stripped when an object was tombstoned was this SID History attribute, which meant that if you restored an object, any previous SIDs that were recorded in its SID History were lost. Fortunately, Windows Server 2003 SP1 includes SID History among the attributes retained when an object is deleted.
SP1 offers simpler AD troubleshooting
Service Pack 1 also made changes in the types of Active Directory information that are logged in the Event Viewer on a domain controller, thus allowing for more proactive monitoring and easier troubleshooting.
One such update is Event ID 2089, which is recorded in the Directory Service event log if any directory partition has not been backed up for a significant length of time (half of the tombstone lifetime or more). The event is logged whether the partition is the Schema, Configuration, or domain partitions -- or any application partitions or ADAM partitions that are hosted on the DC in question.
Service Pack 1 also created an event in the Directory Services log if it attempts to perform an action that requires a particular Flexible Single Master Operation (FSMO), and that FSMO can't be contacted. For example, if an administrator attempts to add a new domain to Active Directory, but the DC cannot locate or contact the Domain Naming Master, an event would be logged in the Directory Services log if any of the FSMO role holders:
A) don't exist
B) can't be contacted, or
C) have not replicated recently with the DC in question.
Using virtualization technology with AD
Ever since SP1, administrators can run domain controllers using virtualization technology such as Microsoft Virtual Server 2005. That allows you to run multiple domains or forests on a single machine or to use virtualization to reduce the attack footprint of a physical server by separating its roles onto multiple virtual machines.
Running DCs in a virtual environment is not without its own considerations, however, and you should consult the Microsoft white paper Running Domain Controllers in Virtual Server 2005 before deploying this configuration in a production environment, as well as this article by Gary Olsen: Is domain controller virtualization really a good idea?
SP1 improves AD backups and restores
Backups, restores and disaster recovery measures for AD domain controllers also improved with Service Pack 1 by the inclusion of the following features:
- The Install From Media feature allows you to populate application directory partitions when installing a DC from backup media. This saves you from needing to replicate the whole of the DomainDNSZones and ForestDNSZones partitions across a slow or expensive WAN link.
- The authoritative restore process provides a much cleaner option for restoring group memberships of authoritatively restored users, groups and computer objects by generating an LDIF file that contains any back-link references for restored objects.
- The Ntdsutil utility has a greatly simplified syntax to remove extinct server metadata from the AD database. Extinct server metadata is created when a domain controller suffers an irretrievable hardware failure or is otherwise removed from the directory without using the Dcpromo tool. The metadata must be removed manually from the directory. Microsoft provides the simplified syntax in KB 216498.
Laura E. Hunter (CISSP, MCSE: Security, MCDBA, Microsoft MVP) is an Active Directory
Architect for a major engineering and staffing firm where she provides Active Directory planning,
implementation and troubleshooting services for business units and schools across an enterprise
network. Laura is a four-time recipient of the prestigious Microsoft "Most Valuable Professional"
award in the area of Windows Server-Networking. She is the author of the Active Directory Field Guide (APress Publishing) as well as co-author of
the Active Directory Cookbook,
Second Edition (O'Reilly). You can contact her at email@example.com.
This was first published in February 2007