Chapter 3: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.

AD LDS Management Tools

Tip: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:

Creating Instances and Application Partitions

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.

Creating Instances and Application Partitions 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.

Configuring AD LDS Data

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.

Configuring AD LDS Data

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.

Configuring AD LDS DataYou 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:

1. Enter the regsvr32 schmmgmt.dll from a command prompt.

2. Open an empty MMC console by clicking Start, then clicking Run, and then entering mmc.

3. Open the File menu, click Add/Remove Snap-in, select Active Directory Schema, click Add, and then click OK.

4. In the console tree, right-click on Active Directory Schema, then click Change Active Directory Domain Controller.

5. Click This Domain Controller or AD LDS instance.

6. 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.

7. 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.

Configuring AD LDS Authentication 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.

Configuring AD LDS Authentication 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: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.

Exercise 1: Preparing Your Lab for Additional Server Roles 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. I

f 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: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

Understanding How AD RMS WorksAn 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.

1. 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.

2. 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.

3. The client software requests a publishing license on behalf of Tara from the certification and licensing server.

4. 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.

Understanding How AD RMS Works5. 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.

6. Tara sends the document to Kristen.

7. 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.

8. The RMS client uses this information to locate the cluster and request a use license for reading the document.

9. 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.

10. The certification and licensing cluster sends the license, including a decryption key specific to Tara’s document, back to Tara’s client.

Understanding How AD RMS Works11. Tara is able to open and view the document.

12. 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.

13. 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.

14. Tara takes her computer home (let’s assume it’s a laptop) then she decides to meet Asia for dinner.

15. 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.

Understanding How AD RMS Works16. 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.

17. 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.

Installing AD RMS

Note: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.

Installing AD RMS 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:

1. 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.

2. 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.

3. 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.

4. You need to specify the database to use, for your practice lab use the Windows Internal Database with the default options.

Installing AD RMS

5. 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.

6. You have to specify how to store the cluster key, for your lab use AD RMS centrally managed storage.

7. You need to provide a strong password to protect the key.

8. You have to select the website for the cluster.

9. 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.

Installing AD RMS

10. You need to provide a name for the server licensor certificate.

11. You need to register the service connection point to help clients find the cluster.

12. You may be prompted to reboot at the end of the installation process.

13. 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.

Managing AD RMS

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

Establishing Trust 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.

Managing Rights Policy Templates 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:

Managing Rights Policy Templates1. Launch the Create Distributed Rights Policy Template wizard by clicking

Create Distributed Rights Policy Template in the actions pane.

2. Click Add.

3. Select the appropriate language for the rights policy template from the Language drop down list.

4. Enter the name the template in the Name box.

5. Although its not required, I suggest that you enter an unambiguous description for the policy template in the Description box.

6. Click Add, then click Next.

7. 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.

8. You can customize what rights the user will have, at a minimum you probably want to grant them the View right.

9. Click Finish.

Managing Rights Policy Templates 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.

Managing Rights Policy Templates Tip: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.

Managing Exclusion Policies

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:

x86 version. x64 version. Itanium version. 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.

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.

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.

Configuring RODC Password Replication Policy

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.

Configuring 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:

1. Log onto a DC with an account that belongs to the Domain Admins group.

2. Enter dsmgmt at a command prompt.

3. Enter local roles.

4. 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.

Other RODC Considerations 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.

Configuring Active Directory Federation Services

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

Configuring Active Directory Federation Services 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:

1. Select Active Directory Federation Services on the Select Server Roles page.

2. Select Federation Service on the Select Role Services page.

3. Specify Create a self-signed token-signing certificate on the Choose a Token-Signing Certificate page.

4. Specify Create a new trust policy on the Select Trust Policy page, use the default directory for storage.

5. Complete the installation wizard.

Installing AD FS 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:

1. Select Active Directory Federation Services on the Select Server Roles page.

2. 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.

3. Specify Create a self-signed certificate for SSL encryption on the Choose Server Authentication Certificate for SSL Encryption page.

4. Enter the name of the server where you installed the Federation Services, as shown in figure 11.

5. Specify Create a self-signed client authentication certificate on the Choose a Client Authentication Certificate page.

6. 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

Configuring the AD FS Proxy and AD FS Agents

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: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.

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.

Configuring Resource Partners 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

1. Right-click Federation Services in the navigation tree of the Active Directory Federation Services console.

2. Click Properties.

3. Click View on the General tab of the Federation Services Properties dialog box.

4. The Certificate dialog box appears, click the Details tab.

5. Click Copy to File.

6. The Certificate Export Wizard launches, click Next three times to accept the default values.

7. On the File to Export page provide the file name to use, click Next, and click Finish. Close the two dialog boxes.

8. 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.