Cleaning Up Metadata and SRV Records

In the last video, I showed how to clean up the metadata for a Domain Controller that’s no longer able to participate in your AD forest.  In this video, which follows from the previous post, I want to show one additional bit of cleanup that will be necessary.  In the video below, I briefly describe the need to manually cleanup SRV records as part of the overall metadata cleanup effort.  After the video, I provide a deeper overview of SRV records and how to read one:

SRV Records and DNS

Most of you probably know how must Active Directory depends on DNS.  In fact, AD can’t function without it because DNS is how Active Directory services are located within an environment.

To allow Active Directory services to be located, DNS uses a particular type of record known as an SRV record.  SRV records are not specific to Active Directory or even Microsoft.  These records are used by servers to advertise the types of services they have available for clients to use.  For example, Active Directory provides LDAP, Kerberos and Global Catalog services (among others) and advertises this through DNS SRV records.

These records, located in the forward lookup zone for your Active Directory domain, come from a file called NETLOGON.DNS.  On a domain controller, this file is populated during the DCPROMO process.  NETLOGON.DNS is located at the following location on your domain controller:

%systemroot%\Windows\System32\Config\netlogon.dns

If DNS is configured to accept dynamic updates, these records will also be added to DNS.  However, if DNS doesn’t accept dynamic update it will be necessary to send this file to your DNS team so they can enter the files directly.

Understanding SRV Records

When you first look at an SRV record, it can be a bit confusing.  To help with that, I’ve provided the following walk-through of a few SRV records that are used by DCs to advertise services.

First, let’s look at the list of SRV records available for W2K8-DC1.W2K8Forest.com (note that some of these are wrapped onto multiple lines here, but they should be viewed as one line):

_ldap._tcp.W2K8Forest.com. 600 IN SRV 0 100 389 W2K8-DC1.W2K8Forest.com.
_ldap._tcp.pdc._msdcs.W2K8Forest.com. 600 IN SRV 0 100 389 W2K8-DC1.W2K8Forest.com.
_ldap._tcp.467fe6a7-28e3-475f-9739-b11684cc1bf3.domains._msdcs.W2K8Forest.com. 600 IN SRV 0 100 389 W2K8-DC1.W2K8Forest.com.
61657dc6-742e-4fae-98cb-60ddb9406c41._msdcs.W2K8Forest.com. 600 IN CNAME W2K8-DC1.W2K8Forest.com.
_ldap._tcp.dc._msdcs.W2K8Forest.com. 600 IN SRV 0 100 389 W2K8-DC1.W2K8Forest.com.
_ldap._tcp.gc._msdcs.W2K8Forest.com. 600 IN SRV 0 100 3268 W2K8-DC1.W2K8Forest.com.
_gc._tcp.W2K8Forest.com. 600 IN SRV 0 100 3268 W2K8-DC1.W2K8Forest.com.
_ldap._tcp.DomainDnsZones.W2K8Forest.com. 600 IN SRV 0 100 389 W2K8-DC1.W2K8Forest.com.
_ldap._tcp.ForestDnsZones.W2K8Forest.com. 600 IN SRV 0 100 389 W2K8-DC1.W2K8Forest.com.
_ldap._tcp.Dallas._sites.W2K8Forest.com. 600 IN SRV 0 100 389 W2K8-DC1.W2K8Forest.com.
_ldap._tcp.Dallas._sites.gc._msdcs.W2K8Forest.com. 600 IN SRV 0 100 3268 W2K8-DC1.W2K8Forest.com.
_ldap._tcp.Dallas._sites.dc._msdcs.W2K8Forest.com. 600 IN SRV 0 100 389 W2K8-DC1.W2K8Forest.com.
_gc._tcp.Dallas._sites.W2K8Forest.com. 600 IN SRV 0 100 3268 W2K8-DC1.W2K8Forest.com.
_ldap._tcp.Dallas._sites.DomainDnsZones.W2K8Forest.com. 600 IN SRV 0 100 389 W2K8-DC1.W2K8Forest.com.
_ldap._tcp.Dallas._sites.ForestDnsZones.W2K8Forest.com. 600 IN SRV 0 100 389 W2K8-DC1.W2K8Forest.com.
_kerberos._tcp.dc._msdcs.W2K8Forest.com. 600 IN SRV 0 100 88 W2K8-DC1.W2K8Forest.com.
_kerberos._tcp.Dallas._sites.dc._msdcs.W2K8Forest.com. 600 IN SRV 0 100 88 W2K8-DC1.W2K8Forest.com.
_kerberos._tcp.W2K8Forest.com. 600 IN SRV 0 100 88 W2K8-DC1.W2K8Forest.com.
_kerberos._tcp.Dallas._sites.W2K8Forest.com. 600 IN SRV 0 100 88 W2K8-DC1.W2K8Forest.com.
_kerberos._udp.W2K8Forest.com. 600 IN SRV 0 100 88 W2K8-DC1.W2K8Forest.com.
_kpasswd._tcp.W2K8Forest.com. 600 IN SRV 0 100 464 W2K8-DC1.W2K8Forest.com.
_kpasswd._udp.W2K8Forest.com. 600 IN SRV 0 100 464 W2K8-DC1.W2K8Forest.com.
W2K8Forest.com. 600 IN A 192.168.1.40
gc._msdcs.W2K8Forest.com. 600 IN A 192.168.1.40
DomainDnsZones.W2K8Forest.com. 600 IN A 192.168.1.40
ForestDnsZones.W2K8Forest.com. 600 IN A 192.168.1.40

Now let’s select a few records from this list and analyze them.

_ldap._tcp.W2K8Forest.com 600 IN SRV 0 100 389 W2K8-DC1.W2K8Forest.com

This is a generic LDAP SRV record.  The information it’s conveying is broken out as follows:

• SERVICE (_ldap): this lets us know that W2K8-DC1 is providing the LDAP service
• PROTOCOL (_tcp): this lets us know that W2K8-DC1 is providing this service through the TCP protocol
• NAME (W2K8Forest.com): this is the domain for which this record is relevant
• TTL (600): this is the default time to live (TTL) of the record (in seconds)
• CLASS (IN): this represents the standard Internet Class for DNS
• RESOURCE RECORD (SRV): this tells us that the record is intended to help clients locate services on the network (in this case, the LDAP service)
• PRIORITY (0): this is the DNS priority for the server.  Clients will try to connect to servers that have a lower number before they attempt to use those with a higher number (in this case, a lower number equals a higher priority).
• WEIGHT (100): This allows for load-balancing of the servers providing the listed service.  If you have newer and faster servers that can handle more client connections, you might want to set a higher weight (a server with a record that has a higher weight has a greater likelihood of being chosen over a lower weight).
• PORT (389): This represents the port that will be used by the server.  So if a client makes an LDAP request to W2K8-DC1, it will need to do so through port 389.
• TARGET (W2K8-DC1.W2K8Forest.com): This is the fully qualified domain name of the server providing the listed service

61657dc6-742e-4fae-98cb-60ddb9406c41._msdcs.W2K8Forest.com. 600 IN CNAME W2K8-DC1.W2K8Forest.com.

Though this isn’t strictly an SRV record (it’s a CNAME record), it’s important to mention since it’s found in the netlogon.dns file.  What this record does is allow the DCs to talk with each other.  The relevant components are as follows:

• DSAGUID (61657DC6-742E-4FAE-98CB-60DDB9406C41): this is the globally unique identifier of the DSA (directory system agent), which is the DC.
• RESOURCE RECORD (CNAME): identifies this record as a canonical name record, providing translation (in this case) between the server GUID and the known computer name.
• TARGET (W2K8-DC1.W2K8Forest.com): The fully qualified domain name of the DC.

There are a few special terms in the netlogon.dns file that deserve a bit more attention.  Those are explained below:

• _gc: This indicates that the server is providing the Global Catalog service
• _pdc: This indicates that the server owns the Primary Domain Controller Emulator role within the domain.  The PDC Emulator is one of the Single Master Operator roles that was explained in an earlier post.
• _msdcs: This is used exclusively for Active Directory Domain Controllers.  It is necessary because services like Kerberos and LDAP aren’t specific to Microsoft, thus clients need a way to identify the Microsoft implementation of these services.

Site-Specific Records

Briefly, I want to make sure and mention an element that appears in some of the SRV records.  Take a look at the record below:

_ldap._tcp.Dallas._sites.W2K8Forest.com. 600 IN SRV 0 100 389 W2K8-DC1.W2K8Forest.com.

Notice that it contains a reference to “Dallas._sites”.  The purpose of this added element is so that clients can specify which Active Directory site they’re in (a site is defined here) and can leverage the resources that are closest to them.  Without these records, DNS might direct a client to use a resource at the other end of a slow network link, but with site-specific records clients can be directed to resource that will provide the most optimal experience.

NOTE: This highlights the importance of always keeping each of your IP Subnets updated and properly linked to sites in Active Directory.

DomainDnsZones and ForestDnsZones

These represent the Application partitions used when DNS is integrated and replicated via Active Directory.  DomainDnsZones are used for information replicated within a domain and ForestDnsZones are used for replicating information between domain controllers within the forest.

The records above are:

DomainDnsZones.W2K8Forest.com. 600 IN A 192.168.1.40
ForestDnsZones.W2K8Forest.com. 600 IN A 192.168.1.40

These are made available for DCs that are seeking other domain controllers that host these partitions (which DCs host an Application partition is specified when the partition is created).  In this case, these records indicate that these partitions can be contacted at the IP address 192.168.1.40 (the IP Address of W2K8-DC1).

Summary

SRV Records can be a very detailed topic and it’s important to spend time getting to know them.  Below I’ve provided several links that provide additional reading on this important topic.

As I said in the previous post, sometimes bad things happen that allow us to share information with each other.  Hopefully this has been helpful.

Articles that will be useful for further reading on this topic:

• SRV Resource Records
• How to verify that SRV DNS records have been created for a domain controller
• Configuring DNS for the Forest Root Domain

Cleaning Up Active Directory Metadata

I’m not 100% satisfied with the video associated with this post, but I’m including it since I think it’s important to AD Administrators to be familiar with this process.  Yesterday, while trying to do something in my lab, I realized I hadn’t brought one of my DCs online in a very long time, and that the tombstone lifetime for the forest had expired.

Deleted Objects, Tombstones and Garbage Collection

As I explain in the video, when an object is deleted in AD it isn’t actually removed from the directory.  Instead, it’s marked as an object to be deleted, it’s hidden and it’s put in a special deleted items container.  The purpose of this is to allow the change to the object (the fact that it’s been removed from AD) to replicate to all other DCs so they can remove their copy of it from their instance of NTDS.DIT.  This “hidden but not-yet-deleted” object is called a tombstoned object.

Additionally, because Active Directory doesn’t allow objects to remain in a “hidden but not-yet-deleted” state, it assigns a lifetime to that tombstoned object measured in days.  The default number of days that the deleted object will be retained is:

• Windows 2000 (all versions): 60 days
• 2003 RTM: 60 days
• Windows 2003 SP1: 180 days
• Windows 2008/Windows 2008 R2: 180 days

You can see (and, if necessary, change) this value by taking the following steps:

1. Connect to a domain controller using ADSI Edit
2. Connect to the Configuration Partition
3. Navigate to the following path:

CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,CN=<domain name>

Once at this object, right-click CN=Directory Service and select “properties”.  In the list of attributes, scroll down to “tombstoneLifetime” and you’ll see how many days the deleted objects will be retained in your directory before they’re deleted.

Once a deleted object has been in a deleted state for longer than its tombstone lifetime, it will be permanently removed from the directory.  This happens when a process known as Garbage Collection runs.  This process looks for deleted objects that have exceeded the tombstone lifetime.  If one is found, this object is permanently deleted.

By default, the Garbage Collection process runs once ever 12 hours (known as the Garbage Collection Interval), though the frequency of this process can be changed by going to the same object listed above (CN=Directory Service) and modifying the “garbageCollPeriod”.

By default, a longer tombstone lifetime and a longer Garbage Collection Interval will result in a larger NTDS.DIT file, but it might also allow a longer time to recover accidentally deleted objects. 

WARNING!!!

You’ll have to do a bit of experimenting to see the effect of changing these values, though the strong recommendation is to leave them at their defaults unless you have a valid business need AND you’ve fully tested and understand what these changes will mean to your environment.

Exceeding the Tombstone Lifetime

You can probably already tell why this is relevant to Active Directory, but just in case I’ll explain.  Let’s assume that you have two DCs (DC1 and DC2).  In DC1 you create a user named Steve.  Steve’s user object is replicated to DC2.  Then DC2 goes offline due to a problem and during that outage, Steve leaves the company and you delete his user object.  Time goes by and the replacement for DC2 is delayed and it’s quite awhile before you are able to bring it back online (let’s say that it’s 182 days later).  If DC2 were allowed to begin replicating with DC1 again, we’d have a problem.  Why?

Remember that DC2 received a copy of Steve’s user object, but it never received word that Steve had left the company.  Further, since the tombstone lifetime has expired for Steve’s user object, it’s been completely removed from DC1 and thus there is nothing to replicate to DC2.  So we end up with an inconsistent directory.  DC1 has no record of Steve while DC2 still considers Steve to be a valid user object.

To correct for this problem, Microsoft has designed Active Directory so that a DC can no longer participate in replication if it’s been offline for longer than the tombstone lifetime.  This prevents the sort of scenario I’ve just described from happening.

But it also means that if you need to remove that DC from the Active Directory forest, you must use a manual process.

Removing the Failed DC

All of that explanation is background to get us to the video I’ve created for this post.  What I’ve done in the video is start at the point that DC2 has to be removed from Active Directory since it’s exceeded the tombstone lifetime and can no longer replicate with DC1.  Below, I walk you through the steps of removing DC2 from the Active Directory forest using a process known as Metadata Cleanup.

Though I took one step while the video was not running (and thus wasn’t able to demonstrate it), I fully explain it so that you can understand what will happen when you need to do Metadata Cleanup on your own.

Sometimes when things happen, it opens the door to explain a principle that AD Admins should know about.  Hopefully this post was one of those instances.  Until next time…

For further information on this process, the following articles can provide assistance:

• The Active Directory database garbage collection process
• Clean Up Server Metadata

The Active Directory Structure - The Basics

In the two videos below, I discuss the basics of the directory structure within Active Directory, addressing concepts of uniqueness within a domain.  I explain the basic concepts related to Distinguished Names and Relative Distinguished Names, as well as showing how to use various tools to learn more about Active Directory objects and their attributes.

Part 1

Part 2

Tools used in this video:

1. Active Directory Users and Computers – the default tool provided for administrators working with AD objects
2. ADSI Edit – a more in-depth editor for Active Directory objects.  It grants access to the different naming partitions within AD, including the Domain Naming, Configuration and Schema partitions, as well as RootDSE

To learn more about these tools, see the following articles:

• ADSI Edit (adsiedit.msc)
• Working with Active Directory Users and Computers

In the next series, I’ll begin to show some of the command-line utilities used to administer Active Directory. 

Until then…

"Protect Object from Accidental Deletion” in Active Directory

This video shows a new feature of AD DS for Windows 2008.  In the past, accidentally moving or deleting objects in AD resulted in significant work to recover the directory to its original state.  Now, a feature has been added to limit these mistakes.  This video discusses this feature, and shows the scenarios when this feature is enabled and disabled.

Installing Windows 2008 R2 Active Directory Domain Services - Part 4 (Read Only Domain Controllers)

In this video, I show how to install a Read-Only Domain Controller (RODC), and I discuss some of the advantages to using an RODC.

Tools used in this video:

1. DCPromo – This command-line tool is used to add/remove Active Directory Domain Services on a specified Windows Server

How to Activate a Windows Product License Key on Windows 2008 R2 Server Core

In a previous demonstration I promised to show how to activate your Windows Product License Key on a Windows Server Core machine.  I forgot to do that, so I’ve created this brief video to do so.

Essentially, you do everything through a Visual Basic Script called the Windows Software Licensing Management Tool (slmgr.vbs).

For a complete description of the available switches when working with slmgr.vbs, you can check out the following TechNet article:

Slmgr.vbs Options

Sorry about neglecting this in the previous video.  Hopefully now everyone is caught up.

Until next time…

Installing Windows 2008 R2 Active Directory Domain Services - Part 3 (Server Core)

In this demo, I show how to use an unattend.txt file to promote a Windows 2008 Server Core machine to be a domain controller.

Tools used in this video:

1. DCPromo – This command-line tool is used to add/remove Active Directory Domain Services on a specified Windows Server

Reference Material Used in Creating this Blog:

• Dcpromo
• How to use unattended mode to install and remove Active Directory Domain Services on Windows Server 2008-based domain controllers

In the final part of this series I’ll show how to configure a DC as a Read-Only Domain Controller (RODC).
Until then…

Windows 2008 Server Core–Initial Configuration

In this video, I show the basic steps necessary to set up a Windows Server Core machine so that it can communicate on the network and join an Active Directory domain.

In this video, I show how to use NETSH and NETDOM to configure TCP/IP settings, rename the computer and join an existing domain.

Tools used in this video:

1. NETSH – This is a multi-purpose command-line tool that is useful for performing many different tasks within a Windows Server environment.  In the present video, I show how to use this tool to configure TCP/IP and DNS settings on a selected network interface.
2. NETDOM – This tool allows the administrator to work with Active Directory domains as well as trust relationships from the command line.

Reference Material Used in Creating this Blog:

• Configuring a Server Core Installation: Overview
• How to Use the Netsh.exe Tool and Command-Line Switches
• Netdom

Installing Windows 2008 R2 Active Directory Domain Services - Part 2

In this demonstration, I show how to add a second domain controller to an existing forest.  Additionally, I demonstrate how to work through a particular problem related to DNS that the 2nd DC encounters when trying to find the AD DS domain.

Tools used in this video:

1. DCPromo – This command-line tool is used to add/remove Active Directory Domain Services on a specified Windows Server

In the third part of this series, I’ll show you how to install AD DS onto a Windows Server running Windows Server Core.  Until then…

Installing Windows 2008 R2 Active Directory Domain Services - Part 1

In this video, I explain how to use the built-in graphical tools on your Windows 2008 R2 Server to install a new Active Directory forest.  In this video, I demonstrate the use of the DCPROMO tool to perform a local install of AD DS.

Part 1

Part 2

Part 3

The tools we use in this video are:

1. DCPromo - this command line tool is used to install ("promote") or uninstall ("demote) Domain Controllers (DC) into an Active Directory Directory Services (AD DS) forest.  It can be used to create a new forest, create a new domain within a forest, and/or add DCs to an existing domain or forest.

Next time I’ll show how to add a 2nd DC to an existing forest via the GUI.  Until then…

Terminology for Active Directory

Before I post any videos about how to do things in AD DS, it’s important to establish the basic terminology that we’ll be working with.  As we move forward, I’ll try to reference this post for the basic definitions of terms.  And, of course, there are far more terms that apply to AD DS than are listed below.  But these basic definitions should get your started.

If you want a more full-bodied discussion of AD DS concepts, I’ve listed a few book recommendations at the end of this post.

• Authentication – the process by which Active Directory verifies that a security principle is who they claim to be.
• Authorization – the process by which Active Directory determines the level of permissions (i.e. what it’s allowed to do and what it is restricted from doing) a security principles has over the resources it wishes to access.
• Domain – a partition within an Active Directory Forest that allows the setting of administrative boundaries, limits replication of objects, and enables the setting of security parameters via Group Policy
• Domain Controller (DC) – a special Windows server that stores the Active Directory database and provides directory functionality.
• Domain Naming System (DNS) – the name resolution system used by Active Directory (may be integrated with Active Directory, or maintained separately).
• Forest – this represents a single instance of Active Directory.  It will contain at least one Domain and possibly many domains.  Directory partitions (configuration, schema, domain, and application) combine to define the Active Directory Forest.
• Global Catalog – a special type of Domain Controller that contains a writable copy of all directory objects that exist within the same domain as the GC, along with a read-only thumbnail of all objects from every other domain within the Forest.
• Group Policy – allows for automated management of Active Directory objects (users, computers, and groups).  Group Policies can be configured to impact local machines, sites, domains, or organizational units
• Kerberos – the standard authentication protocol used by Active Directory.  For a complete discussion of the Kerberos protocol, refer to RFC 4120 available at http://www.ietf.org/rfc/rfc4120.txt
• LDAP – the lightweight directory access protocol used to access information and services available within Active Directory
• Organizational Unit (OU) – the standard container within Active Directory contains objects such as users, groups and computers.  Organizational units can be used to apply Group Policy settings to the objects housed within the OU and potentially its child OUs.
• Operations Masters - specialty roles within Active Directory that ensure the health of the directory throughout the forest.  These roles are either unique to a domain (i.e. each domain will have one of them) or a forest (there will be only one in an entire forest).  They are:
  • Schema Master (forest-wide): maintains and updates the AD DS Schema
  • Domain Naming Master (forest-wide): manages the addition/removal/modification of domains within AD DS
  • RID Master (domain-wide): hands out relational IDs (RIDs) used by a domain controller when creating unique objects in AD.  When a new object is created in AD DS, the domain controller adds a RID to the domain SID (security identifier) to produce a unique identifier for that object within the domain
  • PDC Emulator (domain-wide): this DC functions as the primary domain controller for clients that are not Active Directory aware (such as Windows NT 4).  It also manages password changes for a domain
  • Infrastructure Master (domain-wide): keeps track of object changes in other domains and updates object references in its domain that point to the objects which have been changed in other domains
• Partial Attribute Set (PAS) – this is the list of attributes that will be replicated to the Global Catalog as part of the thumbnail of each object in the directory
• Partition – AD DS has 3 essential partitions and one optional partition.  These groupings of objects are broken out by purpose and in order to minimize replication throughout the forest.  The partitions are:
  • Configuration (replicated forest-wide): contains all objects used for the configuration and maintenance of Active Directory
  • Domain (replicated domain-wide): contains all objects specific to a domain, such as users and computers
  • Schema (replicated forest-wide): contains the objects and properties allowed within Active Directory
  • Application (optional): this partition can be replicated to any domain controllers specified and can contain objects determined by the application using this partition.  For example, when DNS is integrated with Active Directory it can be replicated to any domain controller of your choosing.
• Replication – the process of replication allows the information within Active Directory to be housed in multiple locations via the multi-master model of AD.  Replication occurs per partition and happens as follows:
• Configuration: information is replicated forest-wide
• Schema: information is replicated forest-wide
• Domain: information is replicated domain-wide with certain information replicated forest-wide via Global Catalogs
• Application: information is replicated based on the requirements of the application
• Security Principle – an object that can authenticate against Active Directory
• Schema – the schema contains the definitions for the various objects (and properties that those objects can have) that exist within the Active Directory structure
• Site – a well-connected group of Domain Controllers, servers and clients with high-speed connectivity
• Trust – allows users in one domain to authenticate to external environments (other domains, forests, or non-Active Directory environments) in order to gain access to the resources located in those environments

One caveat…AD DS is big.  It’s quite complex, and the list above is in no way a complete list of terms necessary for you to become an AD expert (in fact, the best description of the list above is “woefully inadequate”!).  These terms are offered only because they are the absolute minimum information that needs to be understood when working with Active Directory.

As we move forward, I’ll mention other terms as they become relevant.  For now, these should get you started.

The Active Directory Family–More to Love in 2008

Prior to Windows 2008, when people said “Active Directory” they meant the directory service provided for free with Windows Server 2000/2003.  Windows Windows 2008, however, Microsoft has expanded on the concept of Active Directory so that it now has more than one meaning.

In this post, I thought I’d give a brief description of each of the core products that make up the Active Directory family.  Seeing this list, you’ll understand that it’s no longer technically accurate to talk about ‘Active Directory’ (though those of us who have worked with AD since the beginning certainly continue to speak of it in these terms).  Instead, using the new terminology below is the more appropriate way to refer to the various members of the Active Directory suite of products.

1. Active Directory Domain Services (AD DS) – this is the classic version of Active Directory that is responsible for managing authentication (proving who you are), and authorization (deciding how much you can do) within your Microsoft domain.  It stores user and computer objects (among many other types of objects) and manages communication, directory lookups, and security for the people and resources accessing your infrastructure
2. Active Directory Lightweight Directory Services (AD LDS) – Previously known as ‘ADAM’, AD LDS is a lightweight version of Active Directory used in conjunction with directory-enabled applications.  While it is not intended to handle authentication/authorization, it does serve as a place to store objects and directory data necessary to the functioning of these directory-enabled applications.
3. Active Directory Certificate Services (AD CS) – This product was once known as Microsoft Public Key Infrastructure (PKI), and is designed to allow you to set up your own internal certificate authority, allowing you to issue and manage digital certificates for the objects within your infrastructure.
4. Active Directory Rights Management Services (AD RMS) – While Windows Server has a native way to protect documents from being accessed by unauthorized persons, AD RMS takes it a step further by managing permissions over those documents.  AD RMS allows you to define who has the rights to do many things with the documents in your environment, setting permissions for who can open, read, edit, etc. the documents being managed by AD RMS.
5. Active Directory Federation Services (AD FS) – This service allows users from other domains to log into web-based applications even though those users are not from your own infrastructure, providing a Single-Sign On (SSO) experience for users accessing your web-based applications from other environment (both Windows and non-Windows).

Even though Active Directory has expanded and now includes 5 products rather than the single ‘Active Directory’ that debuted in Windows 2000, the central theme of AD is still identity management.  Each of the products listed above has some functionality related to this area, so it made sense to consolidate each of these products under the heading “Active Directory”.

Knowing a bit about these different products that make up the Active Directory family is important as you work with Windows 2008.  And now that you know them, you’ll be in a good position to respond to someone who talks about ‘Active Directory’ with the question “Which part of the Active Directory suite are you talking about?”