Be Master Of Your Domain – Active Directory 2008

  • Windows Server 2008 does not radically overhaul AD, but it includes a number of small, yet significant, changes.
  • The introduction of the RODC and Fine-Grained Password Policies is noteworthy, although FGPP has a somewhat unfinished feel due to the absence of a user-friendly management tool.
  • Other changes include useful enhancements to the MMC snap-ins, LDP.EXE, and NTDSUTIL. DFSR offers welcome relief from the problems associated with FRS, but carries a migration overhead.
  • AD auditing is now far more useful with the ability to see before and after information when changes are made to AD objects.
  • Introduction of the new Active Directory Database Mounting Tool marks a step on the road towards improved recoverability.
  • Improvements to AD-related technologies such as DNS and Group Policy provide further compelling reasons to consider an upgrade.

Fine Grained Password Policy (FGPP)

Password policies define the rules for domain user passwords. The screenshot below shows the default settings in Windows Server 2008. Prior to Windows Server 2008, password policy was applicable domain-wide. It was not possible to define different password policies based on organization unit (OU), group membership, or anything else. Organizations with political or legal requirements for separate passwords policies for specific groups of users often found this to be a serious limitation of the product. The only realistic alternatives were costly: either deploy separate domains with separate password policies or rely on third-party tools that worked around the limitation.

With Windows Server 2008, Microsoft now delivers a solution for assigning different password policies for different users. The feature is known as Fine-Grained Password Policy (FGPP) and is only available for domains at Functional Level 3 (Windows Server 2008).

FGPP is not implemented using Group Policy; the domain password policy is configured within the Default Domain Policy. The policies are defined within a new Password Settings Object (PSO) within a Password Settings Container (PSC) located within the System container within each domain.

File Replication Service v2 for SYSVOL Replication

The problems associated with troubleshooting SYSVOL replication using File Replication Service (FRS) in previous versions of Windows Server have been resolved. Windows Server 2008 supports the use of Distributed File System Replication (DFSR) for SYSVOL replication. Microsoft first introduced DFSR (also sometimes known as FRS2) in Windows Server 2003 R2, but support for SYSVOL replication was not available until Windows Server 2008.

FRS and DFSR are not compatible. When introducing a new Windows Server 2008 domain controller into an existing domain with Windows Server 2003 domain controller, SYSVOL replication will take place using FRS. To take advantage of DFSR, you must be at Domain Functional Level 3 (Windows Server 2008) and then go through the process of migrating from SYSVOL replication using FRS to DFSR. Microsoft provides a tool for this (dfsrmig.exe), but the process itself is complicated.

DFSR is not a patched version of FRS, but rather a complete re-development. If you create a new forest with domains at Functional Level 3, DFSR will be used by default for SYSVOL replication. You do not need to go through the process of migrating from FRS.

Read-only Domain Controller (RODC)

The introduction of the RODC in Windows Server 2008 may represent the biggest change to AD since its Windows 2000 inception. The RODC is intended to reduce the risk of security compromise in locations where the threat is highest (such as a perimeter network) or where the physical security of the domain controller is not optimal (for example, a branch office).

The RODC also supports the filtered attribute set, a new feature that enables administrators to define a set of attributes with values that do not replicate to RODCs in the forest. An example would be an application that uses certain attributes to store credential information for authentication to the application. If these attributes are added to the filtered attribute set, their values are replicated between writable domain controllers as normal, but they are not replicated to your RODCs.

However, Windows Server 2003 DCs do not support the filtered attribute set and will therefore replicate the attribute values to RODCs. For this reason, it is recommended to use the filtered attribute set only in forests at Functional Level 3, which have no domain controllers below Windows Server 2008.

An RODC can be configured as a Global Catalog Server (ROGC). Although it sounds like RODC/ROGC would be an ideal candidate for use with Exchange Servers deployed in branch offices, this is not the case. Exchange Servers cannot make use of RODC because Exchange requires a writeable DC/GC to be available. Branch offices will need to maintain a writeable domain controller locally (making RODC/ROGC unnecessary) or centralize their Exchange servers at hub sites and let clients access them remotely. A branch office considering RODCs may find this an unacceptable limitation.

Active Directory as a Service

On domain controllers running earlier versions of Windows Server, the AD functions are wholly integrated into LSASS.EXE, a critical system process that cannot be stopped and started without restarting the server.

On Windows Server 2008 domain controllers, the AD role still uses the LSASS.EXE process, but it now runs as a separate service, named Active Directory Domain Services, that can be stopped and started just like any other Windows service

This is a very useful feature. You can now run tasks such as offline defragmentation of the AD database (NTDS.DIT) without having to shut down and reboot in Directory Services Restore Mode (DSRM). The feature also helps when performing tasks such as hardware maintenance, operating system updates and application installations that require server restarts.

Owner Access Restrictions (OAR)

An inconvenient feature of AD delegation is that the creator of an object automatically becomes the owner of that object. The owner has full control over the object. In a fully delegated environment this feature can be problematic and can make troubleshooting more difficult. For example, a service desk employee may have been delegated the ability to create, but not delete, user objects in a given OU. As the creator and owner of an object, the employee will be able to delete it.

To allow restriction of the permissions automatically assigned to the creator of an object, Windows Server 2008 introduces a new security principal named OWNER RIGHTS. Read-only permissions to the OWNER RIGHTS principal on the given

Auditing Improvements

When configured correctly, versions of AD prior to Windows Server 2008 provided a reasonable level of audit detail. It was possible to see that an attribute had been changed and identify who changed it. However, the audit information did not include the value of an attribute before and after it was changed. Windows Server 2008 provides this information. This extremely useful feature can be used by administrators to quickly revert to the previous value if the change was accidental.

The screenshots below show an example of two audit entries from a Windows Server 2008 security event log. They indicate that the Department attribute for a user has been changed from Marketing to Consulting.

Granular Control of Auditing

The “Audit Directory Service Access” Group Policy setting for controlling AD auditing has been divided in Windows Server 2008 into four sub-categories to allow a more granular level of control. The four categories are:

  • Directory Service Changes
  • Directory Service Replication
  • Detailed Directory Service Replication
  • Directory Service Access

 

Active Directory Database Mounting Tool (DMT)

Windows Server 2008 AD Database Mounting Tool (DMT) is run from the command line as DSAMAIN.EXE. Note that DSAMAIN.EXE is also the name of the Exchange 5.5. Directory Service and the ADAM service in Windows Server 2003. The tool provides a useful method of looking at AD data from past backups without the need to restore into Directory Services Restore Mode (DSRM).

To reach the point where a snapshot of AD database is available for off-line perusal, the following steps are required.

1. Create a snapshot of the AD database using the NTDSUTIL snapshot command.

2. Mount the snapshot by using the NTDSUTIL snapshot command again.

3. Run dsamain, pointing to the mounted snapshot.

4. While dsamain is running, launch the desired tool for off-line viewing (for example, LDP.EXE, ADSIEDIT, or Active Directory Users and Computers).

The screenshot above shows Active Directory Users and Computers pointing to a locally mounted AD snapshot on port 20000 (as opposed to the default LDAP port 389):

DSAMAIN opens the mounted snapshot as a read-only instance. You can compare the information in the snapshot to information in the live directory. When objects are accidentally deleted, they can be restored by using existing methods for tombstone reanimation (e.g., AD Restore).The information from the mounted snapshot can then be used to manually enter the attributes removed during the deletion process (which is most of them).

LDP is a Lightweight Directory Access (LDAP) client that was originally developed exclusively for use within the Directory Services product team. It eventually found its way into the Support Tools in Windows Server 2000 and 2003 and has gradually evolved over the years. In Windows Server 2003 R2 Microsoft introduced a handy ACL editor. The version included in Windows Server 2008 has graduated from the obscurity of Support Tools and is now part of the product. The new version includes the ACL editor and other enhancements.

The Bind function of the Connection menu allows you to bind as the currently logged on user (see screenshot below). If you use LDP frequently, you will appreciate the time this can save.

Another useful feature is the addition of a SID Lookup utility. This allows you to obtain a user’s domain and login ID if you only have the security identifier (SID), as shown below.

Because LDP now forms part of the core product, in-depth help is available from Windows Server 2008 Help and Support.

Advertisements
This entry was posted in Exchange Servers. Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s