Chapter 3: Configuring Additional Active Directory Server Roles

Windows Server 2008 includes several other roles related to Active Directory. These include Active Directory Lightweight Directory Service (AD LDS), Active Directory Rights Management Service (AD RMS), and Active Directory Federation Services (AD FS). This chapter will briefly cover each of these and also provide a little more detail about read-only domain controllers (RODC). In this chapter you will learn to:

Configure Active Directory Lightweight Directory Service (AD LDS).
Configure Active Directory Rights Management Service (AD RMS).
Configure the Read-Only Domain Controller (RODC).
Configure Active Directory Federation Service (AD FS).

Configuring Active Directory Lightweight Directory Services

Previously called Active Directory Application Mode (ADAM), AD LDS provides directory services for applications with a lower overhead than a full deployment of Active Directory Domain Services (AD DS). AD LDS is a Lightweight Directory Access Protocol (LDAP) directory service. AD LDS provides many of the same capabilities as AD DS as well as running multiple instances of AD LDS on the same server, each with its own schema. However, it doesn’t support domains, forests, group policy objects, and some other core features of AD DS. There are several scenarios where an organization should consider using AD LDS rather than AD DS including the following:

To provide authentication for public-facing network services.
As a development environment for creating and testing AD DS and AD LDS-integrated solutions.
When deploying a directory-aware application that, if configured to use the existing directory services infrastructure, would require changes to the schema that would be incompatible with other requirements.
As part of a solution to consolidate multiple identity management services.
For migrating legacy applications to AD DS.

AD LDS Management Tools

A variety of tools are used for managing AD LDS. You will see that many of these management utilities can be used with both AD LDS and AD DS. You will also see that some of the tools specific to AD LDS are less mature than some of those used to configure AD DS. Table 1 provides a description of each of the tools, the rest of the section provides examples of when you should use each. Since there is limited space available in this section and so many tools are being introduced rather than documenting every possible parameter or option available we will focus on the information that you need to provide to complete the action and then consider basic examples.

Tool Name	Accessed From	Description
Active Directory Lightweight Directory Services Setup Wizard	Administrative Tools folder	This graphical tool is used create new AD LDS instances.
Adaminstall	Command prompt	This is the command line tool for creating AD LDS instances using preconfigured setup scripts.
Programs and Features	Control Panel	This is the only way to remove AD LDS instances using the graphical interface.
Adamuninstall	Command prompt	This is the command line tool for removing AD LDS instances using preconfigured setup scripts.
Ldp	%systemroot%\ADAM	A graphical tool for administering any LDAP directory service.
Dsdbutil	Command prompt	A command line tool for managing AD LDS including backing up and restoring data, moving data files, modifying the service account, and changing network ports.
Dsmgmt	Command prompt	A command line tool for managing the configuration of AD LDS.
Repadmin	Command prompt	A command line tool for configuring AD LDS replication.
Csvde	Command prompt	A command line tool for importing and exporting data from AD LDS and AD DS using comma-seperated value (CSV) formatted data.
Ldifde	Command prompt	A command line tool for importing, exporting, and deleting data from AD LDS and AD DS using LDAP Data Interchange Format (LDIF) files.
Adamnsync	Command prompt	A command line tool for synchronizing objects in AD DS with AD LDS
ADSI Edit	Administrative Tools folder	A graphical tool for editing objects in AD LDS and AD DS.
Dsacls	Command prompt	A command line tool for managing permissions in AD LDS and AD DS.
ADSchemaAnalyzer	%systemroot%\ADAM	A graphical tool for migrating schemas from other instances and AD DS into an AD LDS instance.
Services console	Administrative Tools folder	A graphical tool for stopping, starting, and restarting system services including AD LDS instances.
Active Directory Schema snap-in	MMC snap-in	A graphical tool for managing AD DS and AD LDS schemas.

Table 1: AD LDS Administration Tools.

Tip: You can see that it’s a pretty big list, which tools should you expect to encounter on the exam? I suggest that you focus on what can and cannot be done with each, and what information is required to perform various tasks rather than the specific syntax required. Most importantly, ensure that you understand creating and removing instances, then importing and exporting data.

Creating Instances and Application Partitions

Adding the AD LDS role using Server Manager is very easy, the installation wizard completely automates the process. After installation you must create a new instance for AD LDS to actually begin offering network services. You can create instances using the Active Directory Lightweight Directory Services Setup Wizard available in the Administrative Tools folder, or from a command prompt using adaminstall. You need to provide the following information when creating an instance either by completing each page of the installation wizard or by entering it into an answer file to use with adaminstall:

Specify either a unique instance or a replica of an existing one. If you want to start from scratch select unique, if you want to copy the configuration from an existing instance select replica.
An instance name, use a name that reflects the purpose of the instance.
Specify the LDAP and SSL port numbers for the instance to use for network communications. If they are available the default values of 389 and 636 will be used, otherwise the first two ports available will be the defaults, starting at 50,000.
Specify whether or not to create a new application directory partition, if you choose to create a new one then you will have to provide a distinct name the distinguished name format, e.g.: CN=LDSInstance1,DC=dillard,DC=test.
Specify the file location for the instance’s data files.
Specify the service account under which the instance will operate, that means that the instance will have the same permissions and user rights of the account provided.
Specify the name of the user or groups that will be the AD LDS Administrators for the instance.
You can choose to import LDIF files to define the instance’s schema and import data.

If you choose to install from a command prompt the format of command is:

%systemroot%\ADAM\adaminstall.exe /answer:drive:\pathname\filename.txt"

To remove an instance from a command prompt use adamuninstall instead. To do so using the graphical interface you have to use Programs and Features tool located in Control Panel. Regardless of which tool you are using any errors encountered will be recorded in the following registry key: HKLM\Software\Microsoft\Windows\CurrentVersion\ADAM_Installer_Results. More detailed results are available for each attempt in %windir%\debug, separate log files are created each time you execute the wizard or adaminnstall.

Configuring AD LDS Data

You have an opportunity to import data into a new instance during the setup process, after setup is complete you can do so using either of two command line tools: ldifde and csvde. You also use these tools to export data from an instance. Ldifde uses the LDIF data format while csvde uses the comma-seperated value (CSV) format. Both tools accept the same parameters, the only difference is the format of the data files, you can use the /? parameter to view the complete syntax and all parameters available. At a minimum, you’ll need to specify whether to import or export data; the name of the file to use; the name of the server; and the network port of the instance. There are many other optional parameters, for example, you can dynamically replace text strings during the process to facilitate importing data from one domain into another or provide a username and password to use when connecting to the instance.. When exporting you can also define an LDAP search filter, limit the search scope, specify what attributes to include or ignore, or ignore binary values.

You can create, modify, and delete objects within an instance using ADSI Edit, you need to connect to the desired instance by specifying the server name and the instance’s connection point in the distinguished name format, i.e. the application directory partition specified during installation. You can also manage objects in the instance using Ldp, after executing this tool you must first specify the server information using the Connect command on the Connection menu, to complete the connection click Bind on the Connection menu and specify what credentials to use for authentication. Now open the View menu and click Tree, select the distinguished name of the instance from the drop-down list and click OK. I prefer to use ADSI Edit but you should have a basic understanding of the Ldp tool too.

You configure permissions on objects using Ldp, or from a command prompt using Dsacls. With Dsacls you have to provide the connection information, the object’s distinguished name, the name of the user or group for the new permissions, and the permissions to apply, e.g.:

dsacls "\\DC2.dillard.test:389\cn=TestGroup,CN=LDSInstance1,OU=Users,o=Dillard,c=US" /G "CN=Stephanie,OU=Users,o=Dillard,c=US":SD

This command grants Stephanie delete permissions on the object named TestGroup. The permissions can be complex. Figure 1 shows the ACE – Access Control Entry and the Security descriptor boxes used for managing permissions in Ldp. Table 2 lists all of the permissions available when editing an object with Dsacls.

Figure 1: Managing Permissions with Ldp.

Permission	Description
GR	Generic Read
GE	Generic Execute
GW	Generic Write
GA	Generic All
SD	Delete
DT	Delete an object and its children
RE	Read security information
WD	Edit security information
WO	Edit owner information
LC	List an object’s children
CC	Create a child object
DC	Delete a child object
WS	Write to self, also known as Validated Write
WP	Write property
RP	Read property
CA	Control access right
LO	List the object access

Table 2:

Tip: I think that its unlikely you will encounter many questions about managing permissions in AD LDS or AD DS, but I suggest you remember that Ldp and Dsacls are used and that you understand the basic process.

You manage the schema using the Active Directory Schema snap-in described in Configuring the Active Directory Infrastructure. First, you have to set up the Active Directory Schema snap-in by registering the Microsoft Management Console (MMC) snap-in:

Enter the regsvr32 schmmgmt.dll from a command prompt.
Open an empty MMC console by clicking Start, then clicking Run, and then entering mmc.
Open the File menu, click Add/Remove Snap-in, select Active Directory Schema, click Add, and then click OK.
In the console tree, right-click on Active Directory Schema, then click Change Active Directory Domain Controller.
Click This Domain Controller or AD LDS instance.
Click <Type a Directory Server name[:port]here> and enter the name of the server and the port number of the instance as shown in figure 2, then click OK.
Navigate to the desired container, right-click on an object and select Properties to change its attributes.

Figure 2: Changing the Directory Server

Configuring AD LDS Authentication

In LDAP parlance users are known as security principals. Before requests are granted the AD LDS server must verify the credentials of the security principal making it or bind (authenticate) the principal to the directory. Binding can occur in several ways:

With the security principal’s Windows credentials from the local account database or the AD DS domain.
With the security principal’s AD LDS credentials.
Through an AD LDS proxy object.

Presumably you already know how manage Windows user accounts so we will focus on AD LDS. You can add a user to the directory by navigating to the desired container, right-clicking on the container, selecting New, and clicking Object. Specify the object’s class in Select a class, click Next, specify a canonical name for the user in Value, click Next, and then click Finish. Of course, this assumes that user objects are defined in your schema, if not you could import the LDIF file included with AD LDS at %windir%\ADAM\MS-User.ldf. You can reset passwords for AD LDS security principals using ADSI Edit by navigating to the object, right-clicking on it, and selecting Reset password. You can reset them with Ldp by navigating to the object, right-clicking on it, and then clicking Modify. Now type userpassword in Attribute, enter the new password in Value, click Enter, and click Run.

To enable binding through an AD LDS proxy object requires some additional administration. First, you need to ensure that the user classes have been imported into the schema from the LDIF files located in %windir%\ADAM. Then you create the proxy object and map it the security identifier (SID) of a domain user account. Then you complete a simple bind by specifying the proxy object as the user name and the domain account’s password.

Note: The entire process of configuring a proxy for AD LDS is long. It’s not a procedure likely to arise on the exam so rather then including several pages of instructions here I’ll refer you to Microsoft’s TechNet article, Practice Managing Authentication, in the section “Bind through an AD LDS proxy object.”

Exercise 1: Preparing Your Lab for Additional Server Roles

This chapter introduces four additional server roles, in order to succeed when you sit for the exam you need to do more than read this book because I believe that it is important for you to get hands on with the software and explore it thoroughly. Completing the exercises and tasks presented in the book will help a great deal, I suggest that you go further and see what else is possible. Push things a little further and see what is not possible too, deliberately provide invalid information to see what kinds of error messages appear. With that said, it is time to set up these other server roles in your practice lab.

You already saw that installing the AD LDS role is easy, the other roles discussed in this chapter require more effort. Ideally, you would create five separate copies of the virtual hard disk you created in Configuring DNS for Active Directory, and dedicate each one to a single role. That is a lot of disk space though, each Windows Server 2008 VHD file is going to be 5 to 7 gigabytes, perhaps even larger. If you have the room available then separate virtual machines for each role is the way to go, if not, you can economize by combining the AD LDS, AD RMS, and AD FS roles onto a single server. Use another server for the RODC role and a third for some AD FS functionality. You should maintain the original domain controller (DC) on a separate server. Alternatively, you can install a role while studying it, then remove it and install the next one. Whatever approach you choose, make sure you have the virtual machines ready then install the AD LDS role as described earlier in this chapter. Instructions for installing each of the other roles is provided in their respective sections later in the chapter.

Configuring Active Directory Rights Management Services

AD RMS, previously called RMS, is designed to help organizations protect their information from unauthorized use. For example, a document owner can specify who is allowed to open, modify, print, copy, or do other things thereby reducing the risk of accidental or deliberate exposure of sensitive information. Encryption is used to protect documents, only users defined by the document owner are able to decrypt it and view the contents. Microsoft is reluctant to refer to AD RMS as a security solution because it does have limitations. A malicious user could take a picture of their screen and forward the picture rather than the original document, or they could dictate the contents of the document over the phone to someone else. In other words, the technology is very good at protecting against accidental exposure or attacks by malicious external users, but only moderately effective with malicious internal users.

Aside: My friends and formers colleagues at Microsoft Jesper Johansson and Steve Riley have a humorous photo that illustrates the limitations very effectively, one they love to use when speaking at conferences. It shows a computer monitor screen-down on a photocopy machine. How do you defend against analogue attacks like that?

Understanding How AD RMS Works

A typical AD RMS deployment includes a handful of components: An AD DS-based domain controller (DC), an AD RMS certification (or root) cluster that can provision new clients and issue licenses, a licensing cluster that can only issue licenses, an AD RMS logging and configuration database server, a document owner, and document consumers. By this point it should be obvious that the DC is for user authentication. The certification and licensing server clusters are the servers that interact directly with the clients, using load-balanced clusters improves performance and reliability however these roles can be assigned to a single system. The logging and configuration database can be located on the certification and licensing server for testing purposes, but for a production deployment its best to use a separate server for this role. Figure 3 illustrates the logical architecture of an AD RMS deployment. With regards to any single protected document there are two types of clients: those who author documents and those who consume them, of course a particular person’s role is going to change from situation to situation.

Figure 3: AD RMS Logical Architecture

An example of complete transaction will help you to understand both the architecture and the process. Here’s the scenario: Tara and Kristen are collaborating on a secret project, Kristen’s friend Asia works at the same company but she is not assigned to the project, Jeff is Kristen’s roommate and he works for a competing firm.

The RMS client software, rights account certificate (RAC), RMS policies, and RMS-enabled applications are all installed on both Tara’s and Kristen’s computers.
Tara creates an important document about the project in Microsoft Word, she attempts to apply an RMS policy to it that gives her ownership and grants Kristen read privileges.
The client software requests a publishing license on behalf of Tara from the certification and licensing server.
After verifying that Tara is authorized to create documents the server sends the license to Tara’s computer, the transaction is recorded on the logging and configuration database server.
The RMS client creates an encryption key which is used to encrypt the document contents, RMS information such as the address of the certification and licensing cluster and the name of the policy applied to the document are added to the unencrypted document header. A copy of the decryption key is retained on the RMS server.
Tara sends the document to Kristen.
When Kristen attempts to open the document the RMS client on her computer extracts the address of the root cluster, identifying information about the document, and the policy applied to it.
The RMS client uses this information to locate the cluster and request a use license for reading the document.
The certification and licensing cluster cross-references the information sent by the client with what is stored in its database and determines that Tara does have permission to read the document.
The certification and licensing cluster sends the license, including a decryption key specific to Tara’s document, back to Tara’s client.
Tara is able to open and view the document.
She is stunned by its contents and wants to share it with her pal Asia so she tries to forward the email to which it was attached. If she’s using Microsoft Outlook then she will see an error message and be unable to forward it. If she’s using an email client that is not RMS-enabled then she could forward the email with the document attached, lets assume she does.
Asia receives the document but she’s unable to open it. She sees the email attachment, she can save it a folder on her computer, but Microsoft Word will not be able to open it.
Tara takes her computer home (let’s assume it’s a laptop) then she decides to meet Asia for dinner.
Jeff decides to place his professional interests ahead of his relationship with Kristen and removes the hard drive from Kristen’s computer. He attaches it to another computer, after searching for interesting files he runs across a copy of the RMS-protected document that Tara sent, he tries to open it in Microsoft Word but is unable to.
He assumes that Word is enforcing some sort of protection tries to bypass it by opening it in a text editor but all he sees is a large blob of encrypted text preceded by a file header where he can see the address of the certification and licensing cluster.
Now you’re thinking that without even realizing it Kristen has avoided embarrassing Tara and losing both of their jobs. However, she’s so excited about what she learned from Tara that she tells Asia everything she can remember while they sip Margaritas.

That is a lot of information, the technology is a little complex because rights management is an inherently difficult problem to solve. For the end-users the impact is fairly small, they just need to understand what the purpose of RMS is and under what circumstances to use each of the RMS policies. Microsoft has even managed to hide a great deal of the complexity from administrators, getting it up and running is not difficult.

Installing AD RMS

First, note that AD RMS must be installed on a server that belongs to an AD DS domain with a functional level of at least Windows Server 2003 because it relies on AD DS for authentication and it leverages Universal groups. Before installing this server role on any computer you need to provision an AD RMS service account that is a member of the domain and belongs to the Domain Users group. The account needs no additional privileges. AD RMS requires Microsoft SQL Server or some other database management system (DBMS) for storing the configuration database and policy information. The DBMS can be installed on the same server, for most production deployments its best to install on a separate one. For testing purposes you can use the Windows Internal Database (previously known as Microsoft SQL Server Desktop Engine (MSDE)) that is included with Windows Server 2008 however due to the limited capabilities of this technology I strongly recommend that you acquire a fully feature DBMS.

Note: In prerelease versions of Windows Server 2008 this service account had to be a member of the Domain Admins group in order for the installation process to complete. This is no longer the case, Microsoft corrected this issue in the final release of Windows Server 2008.

You will need to provide a fair amount of information when installing this server role, here are the detailed steps when using the Add Roles Wizard:

The role requires several additional services and features: Internet Information Server, the Windows Process Activation Service, and Message Queuing. If these are not already installed you will be prompted to add them when you select the AD RMS role in the wizard.
You need to decide whether or not to include Identity Federation Support, for your practice lab do not include it you have to establish an Active Directory Federation Services (AD FS) server prior to deploying AD RMS with federation.
You need to decide whether to create a new cluster or join an existing one. For your lab you’ll create a new one, in a production environment the AD RMS cluster would normally consist of two or more servers.
You need to specify the database to use, for your practice lab use the Windows Internal Database with the default options.
You must provide credentials for the AD RMS service account you created earlier, if you provide invalid credentials the wizard will not allow you to proceed. If you were adding the server to an existing cluster then you would use the same credentials for the service account on each.
You have to specify how to store the cluster key, for your lab use AD RMS centrally managed storage.
You need to provide a strong password to protect the key.
You have to select the website for the cluster.
You must provide a FQDN for the cluster and specify whether or not SSL will be required. In most cases you should use SSL to protect the communications between the cluster and the clients. You’ll have to provide an SSL certificate or ask the wizard to create a self-signed one, self-signed is suitable for your lab.
You need to provide a name for the server licensor certificate.
You need to register the service connection point to help clients find the cluster.
You may be prompted to reboot at the end of the installation process.
When the wizard completes AD RMS is ready, the next step is to create RMS policy templates and customize other settings if needed.

Managing AD RMS

Most AD RMS management tasks are conducted using the Active Directory Rights Management Services console, located in the Administrative Tools folder. When you open this for the first time you need to click on Add Cluster in the actions pane and specify the address of the cluster. When you connect to the server in your lab you will see a security alert due to the fact that you are using a self-signed certificate. Click Yes when this dialog box appears. There are many elements in the RMS console, as shown in figure 4.

Figure 4: Active Directory Rights Management Services Console Interface.

If you expand the containers in the console tree on the left you will see various objects that you can select, view and manage. The details pane in the center and the actions pane on the right change their appearance depending upon what you have selected in the tree. Lets start with the list of tasks visible when you have the root cluster selected.

Establishing Trust

An AD RMS cluster supports several types of trusts, you can configure trusts to allow users from other domains or even other organizations to read protected content. The four types of trusts are:

Trusted user domains – Allows clients of an AD RMS cluster in another organization or AD forest to obtain licenses from your cluster.
Trusted publishing domains – Allows your AD RMS cluster to issue use licenses for documents protected with a publishing license from a different cluster. This is useful when consolidating clusters, the remaining cluster can process requests for documents protected by the decommissioned cluster.
Federated trust – Allows your AD RMS cluster to issue use licenses to users in another forest that does not have AD RMS installed. You can also add the role feature at any time using Server Manager.
Windows Live ID – Allows users with a Windows Live ID to request use licenses from your AD RMS cluster.

To manage trusts expand the Trust Policies container in the console tree. Select Trusted User Domains to configure trusted user domains If you click Import Trusted User Domain you must specify the file that contains the server licensor certificate from the cluster to be trusted. You also use the Trust Policies container to enable the Windows Live ID trust. Select Trusted Publishing Domains to configure trusted publishing domains. If you click Import Trusted Publishing Domain you must specify the file that contains the server licensor certificate, cluster key, and templates from the cluster to be trusted. You will also have to provide the password needed to decrypt the file. Select Federated Identity Support to configure federated trusts, but this object will only be visible if identity federation support was included during the role installation. You must specify the address of the federated identity certificate service. You can also export server information which can then be imported into other AD RMS clusters that want to trust yours, right-click on your domain in the details pane while either the Trusted User Domains or Trusted Publishing domains object is selected, as shown in figure 5.

Figure 5: Exporting the Server Licensor Certificate

Setting Rights Account Certificate Policies

Users who are allowed to publish and consume protected content from your AD RMS cluster are issued one of two rights account certificates (RAC): standard RACs that they use on their primary computer and temporary RACs that they use while logged onto another user’s computer or a public kiosk. You can configure the validity period of standard RACs in days, the default value is 365. You can configure the validity period of temporary RACs in minutes, the default value is 16. To adjust these values select Rights Account Certificate Policies in the console tree and click on the desired action in the details pane.

Managing Rights Policy Templates

In a production deployment designing the rights policy templates often consumes a great deal of time. Not because they are complicated or difficult to implement but rather because of several other factors. Its important that the collection of certificates made available to an organization users match the business requirements, existing business processes and the expectations of the people who will be using them. Another factor is whether external users will be consuming protected documents. I have seen some organizations that ended up with scores of policy templates, far too many for the users to be able to figure out which is the best to use for a particular document. I have seen others that over simplify, trying to get by on only a handful of templates so that users often have to spend a lot of time defining custom permissions for each document. I could easily write an entire chapter just focusing on this aspect of AD RMS, however I do not think that you will see many questions on designing policy templates for various scenarios. The exam tends to focus on operational tasks so this section will focus on creating and modifying policy templates, but it’s important you understand that this aspect requires serious consideration before you deploy AD RMS in a production environment.

To manage policy templates select Rights Policy Templates in the console tree. The next task is to specify a location for storing the template files, while they stored in the configuration database you also need to make them available to users. You could specify a shared folder which clients can access, or you could deploy them automatically using group policy or a software management product. First create a folder and share it on the network, configure both file system and share permissions to allow the RMS service account to write to the folder. Then return to the AD RMS console and click on Properties in the actions pane. Make sure the Enable export check box is enabled, then enter the share name in UNC format and click OK. To create a new rights policy template do the following:

Launch the Create Distributed Rights Policy Template wizard by clicking Create Distributed Rights Policy Template in the actions pane.
Click Add.
Select the appropriate language for the rights policy template from the Language drop down list.
Enter the name the template in the Name box.
Although its not required, I suggest that you enter an unambiguous description for the policy template in the Description box.
Click Add, then click Next.
Click Add, type the email address of the user or group who will be able to work with content protected with this template in The e-mail address of a user or group box, and then click OK. Alternatively, you can select Anyone.
You can customize what rights the user will have, at a minimum you probably want to grant them the View right.
Click Finish.

Archived templates are still stored in the configuration database but they are no longer available to users. This feature is useful for designing and testing templates or for retiring templates that have already been applied to older content. To archive a template select it from the list in the details pane and click Archive this Rights Policy Template in the actions pane. To manage archived templates click on Manage Archived Rights Policy Templates in the actions pane. You can create additional templates in the archive, delete archived certificates, or make them active by selecting the certificate and clicking Distribute this Rights Policy Template in the actions pane. You can also access all of these tasks by right-clicking on an object and selecting the desired command as shown in figure 6.

Figure 6: Managing Rights Policy Templates.

Tip: There is an easy way to distribute policy templates from AD RMS servers running Windows Server 2008 to Windows Vista clients with Service Pack 1. Two new tasks are available in the Task Schedule, one for manually retrieving the templates at any time and the other for automatically retrieving them any time a user logs on. You can enable or customize these tasks on the client machines using Task Scheduler or via group policy.

Viewing Reports

You can view three kinds of AD RMS reports, however two of them require downloading and installing the Microsoft Report Viewer control first. When you click on Reports in the console tree you can see a link to the control in the details pane. Click the link, download the control, install it, and restart the AD RMS console. You should now have access to the three types of reports:

Statistics reports – Presents information about users who have received RACs from the cluster.
Health reports – Presents system health information about the cluster including successful and failed requests for service location and certificates.
Troubleshooting reports – Presents more detailed information about activities by specific users during specific periods of time.

Managing Exclusion Policies

Exclusion policies allow you to prevent users from receiving RACs and licenses based on the criteria you have specified. If you create an exclusion policy that blocks a user who already has licenses the existing ones are still valid but they are unable to request new ones. The four types are:

User Exclusion – A list of user accounts not trusted by the cluster.
Application Exclusion – A list of application file names that are not trusted by the cluster, you must also specify the minimum and maximum versions of each application in a 4 number, period-delimited format, e.g. “2.2.0.0.”
Lockbox Version Exclusion – Clients use the lockbox to protect their private keys, you can ensure that only clients with the minimum lockbox version are trusted.
Windows Version Exclusion – Enabling this type of exclusion prevents Windows 98 and Windows ME clients from obtaining use licenses.

Navigate to Exclusion Policies in the console tree, then right-click on the desired type of exclusion and enable that type of exclusion, as shown in figure 7. What options are available depend on what type of exclusion you are configuring, right-click on Users and select Exclude User; right-click on Application and select Exclude Application; or right-click on Lockbox and select Properties. There are no additional options for excluding Windows Versions but you should briefly explore each type so that you are familiar with them. For example, figure 8 shows the Lockbox Properties dialog box.

Figure 7: Enabling Application Exclusions.

Figure 8: Specifying the Minimum Lockbox Version.

Managing Security Policies

There are three other tasks located in the Security Policies container. If you enable super users you can select a group whose members will all be able to decrypt any RMS-protected documents published by the cluster. Normally this feature is only enabled temporarily to facilitate data recovery. You can change the cluster key password, and you can decommission the cluster if you are preparing to remove the cluster.

Other Tasks

Four local user groups are created when you install the AD RMS server role. You can add domain accounts to these local groups to implement a moderate degree of administration delegation. The four groups and their capabilities are:

AD RMS Auditors – Members can manage logging and reporting but nothing else on the cluster.
AD RMS Enterprise Administrators – Members can manage all aspects of the cluster, the account of the person who installed the role is automatically added to this group.
AD RMS Service Group – Members can run services owned by the cluster, the service account specified during the installation of the role is automatically added to this group.
AD RMS Template Administrators – Members can manage templates but nothing else on the cluster

Provisioning RMS Clients

The AD RMS client is integrated with Windows Server 2008 and Windows Vista, you can download installation packages for other versions from Microsoft, use the installation package that matches the CPU type:

There’s normally very little that you need to do to manage RMS clients, once you have installed and configured the cluster trusted clients can automatically request and use RACs and licenses. Of course, they do have to be able to find the cluster, they usually do this by finding its service connection point in their AD DS domain. Another way is for the client to examine the protected document to see the extranet URL of the cluster. Finally, you can override the other methods by modifying registry values on the client at HKLM\Software\Microsoft\MSDRM\ServiceLocation. You can add keys called Activation and Enterprise Publishing and specify the URL of the cluster as the value for the key. For federated trusts you can create a key called FederationHomeRealm with the URI of the Federation Service at HKLM\Software\Microsoft\MSDRM\Federation.

Configuring Read-Only Domain Controllers

Read Only Domain Controllers (RODC) are a new type of DC in Windows Server 2008 intended to improve security when deploying them in locations where physical security is not assured. Organizations of all sizes have been asking Microsoft to reduce the risk of deploying DCs in branch offices and other places where the servers cannot be isolated in a secured data center. With previous versions of Windows organizations had to either compromise security or subject users in remote locations to endure slow logon times. There are other situations where RODCs make sense including business applications that have to be installed on DCs; when you wish to consolidate several server roles into a DC in order to reduce the number of physical computers in use; or when deploying AD DS in an extranet. In the past administrators would sometimes use configure the SYSKEY utility that encrypts the AD DS data store so that the startup key is stored on a floppy disk. While this does help to protect the AD DS data from physical attack it also makes managing the DCs more difficult. Deploying an RODC is a better choice than trying to use SYSKEY in this manner on your writeable DCs.

Deploying Read-Only Domain Controllers

Before creating an RODC you need to establish a domain with a functional level of Windows Server 2003 or higher and at least one writable DC running Windows Server 2008. If the forest includes any domain controllers that are not running Windows Server 2008 then you must run adprep /rodcprep once in the forest before deploying a RDOC. This procedure updates the permissions on all the DNS application directory partitions in the forest so that RODCs running DNS can replicate the permissions successfully.

Promoting a member server to the RODC role is straightforward, install the AD DS role and then run dcpromo, the Active Directory Installation Wizard. When navigating through the wizard specify that you are adding a DC to an existing domain; the name of any domain in the forest; the name of the domain where it belongs; the site where it is located; the RODC option; the group for delegation of administration of the RODC; and the location for storing the AD DS data files. Optionally, you can perform an unattended installation from a command prompt as described in Configuring the Active Directory Infrastructure.

Configuring RODC Password Replication Policy

One of the important benefits of an RODC is that it has a lower administrative overhead that writeable DCs. It only supports inbound, or unidirectional replication so no incorrect information can be written to the AD DS database from an RODC. Configuring the password replication policy is one important procedure. You can prevent replication of the passwords for specific accounts by adding them to the domain’s Denied RODC Password Replication Group. This group includes several groups by default:

Cert Publishers
Domain Admins
Enterprise Admins
Enterprise Domain Controllers
Enterprise Read-Only Domain Controllers
Group Policy Creator Owners
The krbtgt domain account
Schema Admins.

Several other groups are blocked by default but are not members Denied RODC Password Replication Group. You control this list of groups from the Password Replication Tab of the Properties dialog box for the DC as shown in figure 9. You can access this dialog box by right-clicking on the DC in Active Directory Users and Computers and selecting Properties. These groups are:

Account Operators
Administrators
Backup Operators
Server Operators.

Figure 9: Configuring the RODC Password Replication Policy.

A second group, Allowed RODC Password Replication Group, has no members by default. You can control membership in these two groups to precisely control what passwords are cached on the RODCs. Blocking caching improves security for those accounts because the RODC will not have any information about their passwords should an attacker gain physical control of the server. The cost of this extra security is significant though, these users have to authenticate to a writeable DC, presumably across a wide area network (WAN) link.

Administrator Role Seperation

Granting administrative privileges on a writeable DC means that you are giving that person control over the entire domain by adding them to the Domain Admins group. You can grant accounts administrative privileges on an RODC without giving them control of the entire domain using the dsmgmt tool:

Log onto a DC with an account that belongs to the Domain Admins group.
Enter dsmgmt at a command prompt.
Enter local roles.
Enter add <domain>\<user> administrators for each account you wish to configure, where <domain> is the name of the domain where the account is located and <user> account name.

Other RODC Considerations

The DNS server running on an RODC hosts read-only copies of zones that must be managed on the writable DNS servers. This means that the RODC is not able to directly register client updates, instead it refers clients to a server that hosts a primary or Active Directory integrated copy of the zone file. If the RODC is unable to locate an NS record for a writable DNS server in the same site it will look for one in other sites.

The RODC filtered attribute set is a set of attribute not replicated to any RODCs in the forest. By filtering particularly sensitive attributes such as encryption keys or passwords you minimize the data exposed should an RODC be stolen. You can configure the attributes to filter using the Active Directory Schema snap-in as described in Steps to Add an Attribute to the Filtered Attribute Set. The following attributes are part of the filtered attribute set and marked confidential to support credential roaming and BitLocker Drive Encryption:

msPKIAccountCredentials
msPKIDPAPIMasterKeys
msPKIRoamingTimeStamp
msFVE-KeyPackage
msFVE-RecoveryGuid
msFVE-RecoveryPassword
msFVE-RecoveryInformation
msFVE-VolumeGuid
msTPM-OwnerInformation

Configuring Active Directory Federation Services

Like me, you probably have scores of unique accounts for different websites that you visit. It takes a lot of work to follow the advice of security experts by maintaining unique usernames and passwords for each of those online identities. Its likely that even at work you have multiple identities for accessing services on your organization’s network and those of partner companies. For example, you may arrive at work and log onto your desktop with a domain account, then enter another password in order visit your company’s travel website, and then provide yet another set of credentials when you check on your healthcare plan. Active Directory Federation Services (AD FS) is designed to help reduce the number of logons users have to keep track of. AD FS also reduces the administration overhead of working with other organizations, in the scenario above both the travel agency and the health insurance company have to create and maintain a user account for you. If AD FS were deployed then these two organizations could trust yours to provision and manage user accounts, they could simply grant your domain account limited access to the necessary network services. In other words, instead of managing separate accounts for each employee at your firm they can manage the trust relationship and permissions for a few groups.

There are four types of AD FS servers that can be used in different combinations for various situations:

Federation Service: Federation servers that use the same trust policy, they forward authentication requests.
Federation Service Proxy: Uses WS-Federation Passive Requestor Profile (WS-F PRP) protocols to proxy communication between the Federation Service and browser clients.
Claims-aware agent: Installed on a web server, it enables claims-aware applications to make authentication decisions for AD FS security tokens.
Windows token-based agent: Installed on a web server that uses Windows-based authorization, it converts between AD FS security tokens to Windows NT access tokens.

AD FS supports many different deployment architectures, figure 10 shows a logical architecture based on the travel agency described earlier. You could deploy a federation server proxy in your own perimeter network to support employees who are working remotely without forcing them to log on via a virtual private network.

Figure 10: Federated Web Single Sign-On AD FS Scenario

Most books that cover Active Directory or identity and access management dedicate at least one entire chapter to AD FS, unfortunately I only have a handful of pages available here. Consequently, this section focuses on what you are likely to encounter in the exam: questions about installation and configuration. There is very little space to talk about how it works or to give planning and design advice. I provided a couple of links in the References section at the end of the chapter where you can find guidance that covers those aspects of AD FS.

Installing AD FS

You need two servers to be able to access all of the AD FS components. Install the Federation Service on the first system by launching the Add

Roles Wizard, you can install this role on the same virtual machine where you already installed AD RMS and AD LDS. To continue perform the following:

Select Active Directory Federation Services on the Select Server Roles page.
Select Federation Service on the Select Role Services page.
Specify Create a self-signed token-signing certificate on the Choose a Token-Signing Certificate page.
Specify Create a new trust policy on the Select Trust Policy page, use the default directory for storage.
Complete the installation wizard.

Now set up the proxy server and the web agents on a separate server by launching the Add Roles Wizard, if you want to avoid making another virtual machine you can install these components on the RODC you created earlier. To continue perform the following:

Select Active Directory Federation Services on the Select Server Roles page.
Select Federation Service Proxy, AD FS Web Agents, Claims-aware Agent, and Windows Token-based Agent on the Select Role Services page. Add the required role services when prompted.
Specify Create a self-signed certificate for SSL encryption on the Choose Server Authentication Certificate for SSL Encryption page.
Enter the name of the server where you installed the Federation Services, as shown in figure 11.
Specify Create a self-signed client authentication certificate on the Choose a Client Authentication Certificate page.
Accept the default values for the IIS role services and complete the installation wizard.

Figure 11: Specifying the Name of the Federation Server

Configuring the AD FS Proxy and AD FS Agents

There isn’t a great deal to configure on the second server that you just deployed. Open the Active Directory Federation Services console, right-click on Federation Service Proxy, and then select Properties. You can configure the Federation Services URL and the certificate used for communication to the Federation Services on the General tab. You can specify default web pages for client activities on the Web Pages tab. Figure 12 shows the Troubleshooting tab where you can specify what kinds of events to record in the AD FS log.

Figure 12: Troubleshooting Tab of the Federation Services Proxy Properties Dialog Box

Open Internet Information Services (IIS) Manager and navigate the console tree to Application Pools. Right-click on AD FS AppPool and select Basic Settings or Advanced Settings to see the configuration options for managing the AD FS application pool. Select the Default Web Site in the console tree and double-click on Authentication in the details pane. You can enable or disable the AD FS Windows Token-Based Agent here.

Configuring the Federation Service

Managing the first server you deployed, the Federation Services server, is more complex. Open the Active Directory Federation Services console, right-click on Federation Service, and then select Properties. You can configure the location of the trust policy file and the certificate token signing on the General tab. You can specify default web pages for client activities on the Web Pages tab. The Troubleshooting tab is where you can specify what kinds of events to record in the AD FS log, and you can enable anonymous access on the Advanced tab.

Configuring Account Stores

To use user and computer accounts from AD DS or AD LDS directories you need add them to the account stores for the federation service. To do so right-click on Account Stores in the navigation tree of the Active Directory Federation Services console, specify AD DS or AD LDS as the store type. If you specify AD DS it will automatically use the domain to which the server belongs, if you specify AD LDS you will be prompted to provide details about the AD LDS store and server.

Important: While you can define multiple AD LDS stores in the federation service there can be only one AD DS store.

After creating an account store you can add group claim extractions and custom claim extractions so that information stored in the directory is added to each user’s claims. To do this right-click on the account store, select New, then select either Group Claim Extraction or Custom Claim Extraction, and enter in the information when prompted.

Configuring Organization Claims

Claims are statements about users such as name or access right, that are understood by both organizations in the federation. The account partner creates claims, the resource partner then makes decisions based on what is in the claim. For example, a claim might assert that Tara belongs to a group called “Corp Travelers.” When the resource partner sees this claim it can decide to allow Tara to access the travel booking system. Three identity claims are created during installation: user principal name, email, and common name. These cannot be mapped, they are simply passed through if enabled. Group claims map an AD DS or AD LDS group to some role, e.g. “Corp Travelers” to the role “Allowed to Book Travel.” So when Tara finishes the authentication process to the travel agency’s website she’s able to book a trip. Custom claims contain whatever information you specify about the user. To create a new claim right-click on Organization Claim in the navigation tree of the Active Directory Federation Services console, click New, then click Organization Claim. Enter the name for the new claim and select the type of claim then click OK as shown in figure 13.

Figure 13: Creating a New Group Claim.

To map a group from the directory to the new claim right-click on it and select Properties. Click on the Resource Group tab, enable Map this claim to the following resource group, then click the ellipses button to search the directory for the desired group. When ready click OK to apply the mapping, as shown in figure 14.

Figure 14: Mapping a Group to a Group Claim

Configuring Resource Partners

So far we have been discussing what the configuration of the account partner in the federation. The account partner also needs to define the trust with the resource partner. To do so right-click Resource Partners in the navigation tree of the Active Directory Federation Services console, click New, then click Resource Partners. The Add Resource Partner Wizard will launch, enter the details about the partner such as the federation service address. After defining the resource partner you can add outgoing claim mappings by right-clicking the resource partner, selecting New, then select either Group Claim Extraction or Custom Claim Extraction, you then enter in the information about the new claim.

The resource partner will need a copy of your verification certificate. This is the digitally signed token-signing certificate without the private keys. To export your verification certificate

Right-click Federation Services in the navigation tree of the Active Directory Federation Services console.
Click Properties.
Click View on the General tab of the Federation Services Properties dialog box.
The Certificate dialog box appears, click the Details tab.
Click Copy to File.
The Certificate Export Wizard launches, click Next three times to accept the default values.
On the File to Export page provide the file name to use, click Next, and click Finish. Close the two dialog boxes.
The verification certificate is now ready to be sent to the resource partner.

Configuring Account Partners

Now we switch to the other organization’s point of view. They must also define relationship with the other organization and specify what resources to share. The resource federation service processes incoming claims, verifies that they match the list of allowed claims, maps them to its own claims, and send the client a new security token which the client submits to the shared application. To configure a new partner right-click Account Partners in the navigation tree of the Active Directory Federation Services console, click New, then click Add Account Partner to start the Add Account Partner Wizard. You will need to provide information about the account partner including the URI and endpoint URL of their federation service, their verification certificate, and the identity claims the partner will provide. After defining the account partner you can add incoming claim mappings by right-clicking the resource partner, selecting New, then select either Group Claim Extraction or Custom Claim Extraction, you then enter in the information about the new claim.

Configuring Applications

Now the resource partner’s applications must be defined. To do so right-click Applications in the navigation tree of the Active Directory Federation Services console, click New, then click Application. The wizard will prompt you for information about the application such as whether it’s claims-aware or Windows NT-token based, the URL, and what identity claims to accept.

Summary

This chapter introduced you to four distinct server roles available in Windows Server 2008: Active Directory Lightweight Directory Service (AD LDS), Active Directory Rights Management Service (AD RMS), and Active Directory Federation Services (AD FS). A great deal of information was provided on installing and configuring each. Due to space limitations focus was placed on the most common tasks, before you sit for the exam you should go beyond what this chapter presented by reading documents in the References section of this chapter and by practicing using the each of the management tools discussed here. One final note, Microsoft’s study guide for this exam indicates that ‘Windows Server Virtualization issues’ relating to each of the four roles may be on the exam, however I know of no such issues and I could find no information about potential issues on Microsoft’s website or in other resources that I leveraged while writing the chapter.

Chapter Review

This section presents a list of review questions designed to help reinforce the knowledge presented earlier in the chapter. To persuade you to explore the management tools more deeply a few questions may require you to examine those tools further rather than rereading the chapter.

Questions

In what way does the filtered attribute set helps to protect sensitive information such as passwords and encryption keys stored in AD DS?
1. Items with these attributes are encrypted with SYSKEY.
2. These attributes are encrypted when stored in the AD DS database.
3. These attributes are not replicated to RODCs.
4. These attributes are protected by BitLocker Drive Encryption.
Which of the following is the correct procedure to grant a domain user limited administrative privileges on an RODC?
1. Use dsmgmt to add the user’s domain account to the local administrators group.
2. Use Active Directory Users and Computers to remove the user’s domain account from the Domain Admins group and add the account to the local Administrators group.
3. Use Active Directory Users and Computers to add the user’s domain account to the RODC Admin group.
4. Use Computer Management to add the user’s domain account to the local Administrators group as shown in figure 15.

Figure 15: The Computer Management console

If you need to recover AD RMS-protected content that was encrypted by a recently departed employee which of the following procedures would work best?
1. Log in as a member of the Enterprise Administrators group and open the documents with the appropriate RMS-enabled applications.
2. Enable the super users security policy, grant the Domain Administrators group the super users privilege, then log on with an account that belongs to the Domain Administrators group and open the documents with the appropriate RMS-enabled applications.
3. Log in as a member of the AD RMS Enterprise Administrators group and open the documents with the appropriate RMS-enabled applications.
4. Log in using the RMS service account specified during installation and forcibly decrypt them using the data recovery tools.
What is the easiest way to check for the recommended lockbox version number for AD RMS?
1. Right-click on the RMS cluster in the navigation tree in Active Directory Rights Management Services, select Properties, and check the lockbox version number on the General tab.
2. Visit the RMS page on Microsoft’s website and click on the Recommended lockbox version link.
3. Rick-click on Exclusion Policies in the navigation tree in Active Directory Rights Management Services, select Properties, and then click View the recommended minimum lockbox version.
4. Right-click on the Lockbox object in the navigation tree in Active Directory Rights Management Services, select Properties, and then click View the recommended minimum lockbox version.
It is not possible to configure a content expiration date for a rights policy template.
1. True.
2. False.
Which kind of trust policy should you use when you wish to allow clients of another organization to be able to view AD RMS-protected documents from yours if the other organization does not have RMS deployed?
1. Windows Live ID trust.
2. Trusted publishing domain trust.
3. Federated trust.
4. Trusted user domain trust.
Which kind of trust policy should you use when you wish to allow clients of another forest to be able to view AD RMS-protected documents from your cluster if the other organization has RMS deployed?
1. Windows Live ID trust.
2. Trusted publishing domain trust.
3. Federated trust.
4. Trusted user domain trust.
You are preparing to deploy the first server in a new AD RMS cluster. You create a new account with a strong password for the RMS service account. What domain group should you add it to?
1. Enterprise Admins.
2. Domain Admins.
3. Domain Users.
4. AD RMS Service Group.
5. None of the above.
Which of the following are problems that AD RMS does not address?
1. A traveling employee whose mobile computer is stolen from the hotel room while the employee is out for dinner.
2. An ambitious employee who wants to get help for a project and needs to share a sensitive document with a colleague in another department even though that person is not authorized to know details of the project.
3. A careless but hard-working employee who wants to send copies of sensitive documents to his personal email address so that he can continue to work on them after arriving at home for the evening.
4. An employee who wants to expose potentially embarrassing information about how some executives mishandled a contract with a business partner.
You tried to create a new AD LDS instance by running an unattended installation with adaminstall and an answer file but after the installation completes the new instance isn’t available on the server. Where should you look for more information?
1. In the registry at HKLM\Software\Microsoft\Windows\CurrentVersion\ADAM_Installer_Results.
2. In the file system, look for the latest AD LDS setup log file at %windir%\debug.
3. In the file system, look for the latest AD LDS setup log file at %windir%\adam\setup.
4. In the Application event log.
You have successfully installed an instance of AD LDS on a server. You register the Schema Admin console dll by executing regsvr32 schmmgmt.dll at a command prompt. You open the Administrative Tools folder and see the Active Directory Lightweight Directory Services Setup Wizard but you do not see Active Directory Schema. Why is that?
1. You are logged on with an account that does not belong to the Schema Admins domain group.
2. You forgot to use the –f switch when you registered the dll.
3. You need to create a new console using mmc and add the Active Directory Schema snap-in to it.
4. You need to restart the server before you can open that tool or manage the new instance.
All of the AD FS components can be installed and operated on a single server.
1. True.
2. False.
Look at figure 16, where would you right-click if you wanted users with accounts in one of your organization’s AD LDS directories to be able to access a website hosted by a business partner?
1. Trust Policy
2. Organization Claims
3. Account Stores
4. Applications
5. Resource Partners
6. Travel

Figure 16: AD FS Management Console

You are trying to establish an AD FS federation relationship with a new account partner. While navigating through the Add Account Partner Wizard you encounter the error message shown in figure 17. What is the most likely reason for this problem?
1. The partner exported the wrong kind of digital certificate from their AD FS server.
2. You specified an invalid URI for the partner’s federation service.
3. You specified an invalid URL for the partner’s federation service endpoint.
4. You have not properly configured the claims-aware agent on the server hosting the shared application.

Figure 17: Error Message from the Add Account Partner Wizard.

Answers

C is correct, these attributes are filtered from objects before they objects are replicated to any RODCs. SYSKEY is used to encrypt the AD DS database on all DCs, and the local account database on computers that are not domain controllers. BitLocker is an optional disk encryption technology included with Windows Vista and Windows Server 2008, it encrypts entire storage volumes, not specific elements within AD DS.
A is correct, you use the local roles context of dsmgmt to enter this command: add <domain>\<user> administrators. B is incorrect because you can’t use Active Directory Users and Computers to manage local groups. C is incorrect because there is no such group. D is a red herring, the Local Users and Groups container is removed from the Computer Management console during the execution of the AD DS installation wizard. This last answer is a little unfair though, I made the screen shot on a member server rather than a DC, but I want to ensure that you are aware of this subtle difference between DCs and member computers
B is the correct answer, the super users feature is designed to address this specific scenario.
D is the correct answer. A is wrong because the lockbox version number is not displayed in that location and its possible that the lockbox version of your RMS cluster is higher than the minimum recommended version. B is incorrect because there is no such link on Microsoft’s RMS page, at least not right now! C is wrong because there is no properties command on the right-click menu for the Exclusion Policies object.
B is correct. This is one of the key features of AD RMS, you can force documents to expire after a specific date or number of days after publication by opening the Properties dialog box for the template and selecting the Expiration Policy tab. You can also set an expiration period for use licenses in order to cause cached use licenses to stop working and force users to acquire a new one from the cluster.
C is the correct answer.
D is the correct answer.
E is correct. The account is made a member of the Domain Users group by default when you create it. The account is added to the AD RMS Service Group during the role installation process and it needs no additional privileges.
D is the correct answer. Microsoft describes AD RMS as a policy enforcement tool rather than a security tool because someone who has permission to read a protected document can employ various analogue methods to share that information with unauthorized users.
Both A and B are correct. You might want to create both valid and invalid answer files and use each with adaminstall so that you can examine the log files in %windir%\debug to see what kind of information is recorded for both successful and unsuccessful installs.
C is correct.
B is correct because you cannot install the AD FS proxy on the same system as the Federation Services. Typically the proxy is deployed in a perimeter network for servicing remote clients while the Federation Services could be deployed either internally or on the perimeter network.
C is correct, you add AD DS and AD LDS directories by right-clicking Account Stores in the navigation tree.
A is correct. If you follow the instructions for exporting the verification certificate provided in this chapter your resource partners should not see this sort of error message. However, some administrators may assume that they need to use Certificates MMC snap-in where they could easily select the wrong account or certificate to export.

References

Getting Started: AD LDS.

Active Directory Rights Management Services.

Windows Rights Management Services for Windows Server 2003.

Windows Server 2008 Active Directory Federation Services website.

Active Directory Federation Services website.