In Part 1: AD RMS – Data Access Controls we learned about file access controls to data and resources by leveraging permissions via NTFS and share restrictions.

Part 2: AD RMS – Encryption covered the Encrypting File System and BitLocker functionality.

Part 3: AD RMS – Features & Operational Considerations covered some of the higher level features and operational considerations of the technology, reviewing content permission and control.

In today’s post I will be outlining the system requirements of Active Directory Rights Management Services as well as other dependencies for the service.

AD RMS System Requirements

Like any other application, Active Directory Rights Management Services has minimum and recommended system requirements.

Server 2008 R2 and Internet Information Services (IIS) are required in order to successfully install and initialize AD RMS. Additionally, AD RMS also requires access to a database server with SQL Server being identified as part of the system requirements. The database can be run either on the same server as AD RMS or on a remote server.

As defined by Microsoft the “requirement” for AD RMS is:

One (1) Pentium 4 Processors running at 3 GHz or higher
512 MB of RAM
40 GB of free hard disk space

The recommended configuration is:

Two (2) Pentium 4 Processors running at 3 GHz or higher
1 GB of RAM
80 GB of free hard disk space

AD RMS Software Requirements

Below are the software requirements for running your Server 2008 R2 based configuration on the Active Directory Rights Management Services role:

The File system installed should be NTFS and Message Queuing needs to be enabled.

Internet Information Services (IIS) is needed as well as ASP.NET.

Your Server 2008 R2 system in the AD RMS role must be installed in an Active Directory domain. The domain controllers need to be running Windows Server 2000 with Service Pack 3 (SP3), Windows Server 2003, Windows Server 2008, or Windows Server 2008 R2.

An additional requirement is that all users and groups who need to use AD RMS to acquire licenses and publish content must have an e-mail address configured in Active Directory.

AD RMS also requires a database server and Microsoft’s outlined requirements recommend SQL Server 2005 or SQL Server 2008. (SQL Server 2000 is not supported).

Additional Considerations

Before AD RMS can be installed there are several additional considerations that need to be reviewed:

The AD RMS server needs to be installed as a member server in the same domain as the user accounts that will be leveraging the service.

You will need to create a domain user account to be used as the AD RMS service account.

You need to also specify a user account to be used for the installation of AD RMS; this account needs to be different than the AD RMS service account and it must have access to query the Active Directory Domain Services (AD DS) domain.

If you are going to register the AD RMS service connection point (SCP) during installation, the specified user account installing must be a member of the Domain Enterprise Admins group (or have at least the equivalent permissions).

With respect to using an external database server for the AD RMS databases, the user account must have the right to create new databases. If SQL Server 2005 or SQL Server 2008 is used, the user account must be a member of the System Administrators database role, or equivalent

A Few More Recommendations

Microsoft best practices also details the following additional recommendations:

The database server used to host the AD RMS databases should be installed on a separate computer.

When installing an AD RMS cluster, secure sockets layer (SSL) certificates should be used and it should be issued from a trusted root certification authority.

You will need to create a DNS alias (CNAME) record for the AD RMS cluster URL and a separate CNAME record for the computer hosting the AD RMS configuration database. This is helpful in a scenario where the AD RMS servers are no longer in use or taken out of service as the CNAME record can be updated without having to publish all rights-protected files again.

If you are using a named instance for the AD RMS configuration database, the SQL Server Browser service must be started on the database server before installing AD RMS. If the SQL Server Browser service is not started the AD RMS installation will not be able to locate the configuration database and the installation will fail.

And that’s as far as system recommendations and other considerations for AD RMS go.

Next time, we’ll finally get to the fun part — installing AD RMS on a Server 2008 R2 system!

Related posts:

• Active Directory Rights Management Services: Features & Operational Considerations
• Active Directory Rights Management Services: Data Access Controls
• Active Directory Rights Management Services: Encryption – EFS and BitLocker

As I mentioned before, Server 2008 R2 is still in “Release Candidate” status so the details in these articles might change before the product is officially released to manufacturing (RTM), so please keep this in mind.

Now before we get started, let’s do a quick review of what we already covered:

In AD RMS – Data Access Controls we briefly reviewed file access controls to data and resources by leveraging permissions via NTFS and share restrictions. In this article we will take a look at some of the other ways outside of AD RMS that administrators can limit intentional and unintentional data leakage.

In AD RMS – Encryption: EFS and BitLocker we reviewed the Encrypting File System and BitLocker functionality. While not directly related to Active Directory Rights Management Services they are a part of any good security and control strategy.

In today’s segment on Features and Operational Considerations we will review some of the higher level features and operational considerations of the technology in order to get a good understanding of what it offers in terms of content permission and control. I’ll cover:

• Why use AD RMS?
• What AD RMS can do
• How Rights Management works (in a nutshell)
• Shares and Licenses

Why Use AD RMS?

When administrators leverage Active Directory Rights Management Services (AD RMS) as part of their security strategy, they add an additional layer above and beyond standard file based security, EFS, or disk encryption technologies such as BitLocker.

This is accomplished by allowing for the protection of information through persistent usage policies and rights management. The best part of this use and rights security is that it is not limited to where the data is stored but rather it is part of the data itself, which means that no matter where the data resides it effectively carries the permissions and restrictions with it.

AD RMS allows administrators to set up the services that will allow data owners to configure permissions to sensitive information as part of their security efforts to keep it from intentionally or accidentally being sent to or received by people that should not have access to it in the first place.

As an example, if I have general file access rights (read) to a Word document and I have it in my possession there is nothing preventing me from forwarding that out to the world in an email.

AD RMS resolves that issue.

As another example, if I have general file access rights (read) to a Word document and I am fired from my company I will always have access to that Word document saved on my own storage device.

AD RMS resolves this problem as well.

What AD RMS Can Do

The AD RMS environment that administrators will deploy includes a system running Server 2008 R2, the latest version released. This system would be running with the AD RMS server role enabled in order to handle all of the necessary certificates for the data. You would also need it to host database services and the AD RMS client.

The AD RMS client is included as part of Windows 7 and Windows Vista and is leveraged as part of the solution to process the permissions on the data.

Data owners are able to define who can open, modify, print, forward, or take other actions with the data. Policy templates can also be created and can be applied directly to the information so that the users do not have to define permissions or rights individually.

As an example a template could be set up as “INTFTE” which allows for “all rights denied except READ” and that could be applied to Word Documents and Spreadsheet and the like, where only those people that are full time, internal employees would even be granted access to the data and then only at a READ level. At that setting they would be unable to print out the data, copy and paste it out and the ability to create screen shots or clippings would be disabled when that document was open.

If you want to be able to leverage rights management to data created on a given application it must be rights management aware or be able to leverage add-ons that have been created to make an application AD RMS-enabled, even if it does not natively implement RMS functionality. Text files created with Notepad cannot be rights enabled because the application cannot leverage the functionality natively as an example.

How Rights Management Works (in a nutshell)

The way the Active Directory Rights Management Service works is that it will issue RMS licenses by way of the AD RMS client which is required for creating the permissions and restrictions on the rights-protected content. The client is also needed for access to that data as well.

Data that is protected by AD RMS leverages encryption and an embedded Usage Policy that defines how each user or group will have access to that data. The data owner will decide the rights that those trusted users will have and they will enable that access right through the application itself.

When a data creator / owner decides that they will rights protect a Word 2007 document, that is done right through Word by selecting the “Office Button” (sometimes called “The Pearl”) in the upper left hand corner of the application and choosing the Prepare option (preparing the document for distribution) and then choosing the Restrict Permission option.

[NOTES FROM THE FIELD] – When content is rights protected (often referred to a “published” or “distributed”) through AD RMS, it is encrypted with Advanced Encryption Standard (AES) 128-bit encryption. (Data Encryption Standard (DES) 56-bit encryption is available for backward compatibility).

In our example above in using Word, AES 128-bit encryption would be used as Microsoft Office 2007 always uses AES 128-bit encryption by default.

AD RMS uses public and private keys to encrypt the content encryption symmetric key. The rights policy data in the publishing license and the use license are also encrypted. AD RMS also uses the public keys to digitally sign AD RMS certificates and licenses as well.

Once the permissions are set (such as READ) then specific users or groups are assigned that license or right to that data. The data owner may then put the Word document out on a share (where the share may have access and permissions rights added to it through the share itself and / or where file permissions may be set via NTFS).

When a user with share and file rights access attempts to view the document they must also have this “licensed” right to do so from the owner or they will be denied access to the data from the rights management perspective.

You can see where combining share, file system, EFS, and BitLocker can add to the security of data and how RMS adds an additional layer even above and beyond that.

Shares and Licenses

If a user was accidentally put into a group that has permissions to a shared resource (such as the Payroll folder and network share), they would suddenly have access to data that they should never have been granted access to in the first place.

However, if the actual data was rights protected this user would not have the license right to access the data; despite the fact they are in a share they don’t otherwise belong in they cannot read the data because they have no RMS access to it.

Additionally, in a situation where someone is fired or quits working for a company, their rights to that data can be revoked. Despite the fact that they may still have data saved on a removable drive or flash memory in their possession, they will no longer be able to access it as their rights, remotely managed via the AD RMS service, will now be denied.

An overly simple way to consider AD RMS is — deny all access rights to all users / groups except those with specific granted rights by way of RMS permissions.

Further Reading

For a much more of a detailed look at the actual process please consider a review of Deploying Active Directory Rights Management Services at Microsoft — specifically the Process That IRM Uses to Generate and Retrieve Licenses section of the article.

Next Time

In my next article AD RMS – System Requirements and other Considerations we’ll go over the recommend system requirements and some of the high level configuration considerations for a standard set up. See you then!

Related posts:

• Active Directory Rights Management Services: System Requirements & Other Considerations
• Active Directory Rights Management Services: Encryption – EFS and BitLocker
• Active Directory Rights Management Services: Data Access Controls

In today’s article we will take a look at some of the other ways outside of AD RMS that administrators can limit intentional and unintentional data leakage.

As I mentioned in my overview post on Active Directory Rights Management Services, AD RMS allows administrators additional ways to protect proprietary information and sensitive data through access and usage restrictions that follow the data wherever it is accessed.

By leveraging AD RMS administrators can dramatically reduce the probability and the possibility that the data is intentionally or accidentally received by users who should not have access to the data in the first place.

As I noted before, the information in this article is subject to change with the RTM, so please keep this in mind and if you do notice any changes feel free to post them in the comments.

Encrypting File System (EFS)

One of the ways to restrict access to data is to encrypt the data (lock it up) so that only the people or groups that have the permissions to access it can — everyone else is denied access.

Much in the same way that very few people have access to your home (only people with the keys to the doors of the house have allowed access) EFS offers administrators a way to set up strict access controls.

What’s different to this method over NTFS permission that we discussed in the last article is that the encryption permissions follow the file around … to an extent.

EFS adds on to the NTFS security layer by effectively scrambling the contents of that data so that it can be read only by someone who has the encryption key to decipher it. Just being an administrator of a system is not necessarily going to allow you to gain ownership of the data and the control to access it because now you’d need the key to unlock / decipher the data as well.

When a user attempts to access an encrypted file and that user does not have the key to unlock it they will receive an access denied message and they will be unable to read the file.

Because encryption is set on the object (and can be inherited) the effect of copying and moving files around can impact their encryption state.

The Rules of Encryption

The overall rules for encryption are as follows:

• Rule # 1

When moving or copying a file within the same NTFS volume an encrypted file will not inherit the encryption state of the target folder when that folder is unencrypted. When you copy or move an encrypted file to an unencrypted folder, the file is still encrypted. If you have enabled a folder to encrypt files and you move or copy an unencrypted file to it, it will become encrypted at that point.

• Rule # 2

When copying or moving a file or folder from one NTFS volume to another, an encrypted file will not inherit the encryption state of the target folder when that folder is unencrypted. When you copy or move an encrypted file to an unencrypted folder, the file is still encrypted. If you have enabled a folder to encrypt files and you move or copy an unencrypted file to it, across partitions, it will become encrypted at that point.

• Rule # 3

Moving or copying a file or folder to a FAT16 or FAT32 volume – EFS supports attribute driven encryption only on the NTFS file system, so when you move or copy an encrypted NTFS file or folder to a FAT volume, (16 or 32) the encryption attribute will be lost. Because most forms of removable media do not support the NTFS file system, the same is also true.

What You Need to Know about EFS

Some key thoughts with respect to encrypting data by way of EFS:

When you need to access encrypted data and you are on a system where the key to the data is present, you can access the encrypted data by simply double clicking on it; there is no other interaction for you. The operating system decrypts the file to access it and then when it is closed it automatically encrypts it again.

You need to back up your encryption certificate and encryption key in case you need to recover these if the system crashes or there is some other error and the system needs to be rebuilt and so on. If you neglect to do this and there is an issue and no other recovery agent is available then these encrypted files are forever locked. This is especially important on standalone systems that are not attached to a domain.

When there are other users that are going to need access to files or folders that you encrypt they will need to have their own EFS certificate added to the files in order to gain access to them. Think of this like having their own key just to this file. They are not leveraging your key – your key unlocks ALL of your encrypted files; their key when added to a file that you lock with your key allows them to access that data and only that data.

Last Thoughts on EFS

EFS does not offer a complete solution for securing files that are sent across the network. EFS secured files are decrypted when they need to be sent over the wire, which can expose the file to possible interception and attacks if someone is monitoring (sniffing) the wire. In order to secure the transmission of sensitive data on an internal or external network another form of encryption would be needed such as IPSec or SSL depending on the need.

As you can see from this high level overview, there are ways to better secure the data but there are still some pretty big loop holes when it comes to storing the data, moving it around on portable drives and transmitting it over the wire.

[NOTES FROM THE FIELD] – Because this was an introductory overview of EFS there are a lot of details I glossed over. I would recommend reviewing the details of the Encrypting File System information on the Microsoft website to get more details.

Of special interest would be the Changes in Functionality from Windows Server 2003 with SP1 to Windows Server 2008 section.

BitLocker / BitLocker to Go

So with our review of EFS done I’ll turn our attention to BitLocker and Bitlocker To Go.

BitLocker Drive Encryption is available on some versions of Windows Vista, Windows Server 2008 R2 and in some editions of Windows 7. When leveraged BitLocker Drive Encryption is one of the best ways to protect portable systems such as laptops from loss of data and information when the laptops themselves are lost or stolen.

Additionally, the use of Bitlocker on desktop systems is also a good consideration when you consider how much information can be lost from recycled desktop systems that have not undergone a proper hard drive wipe routine before being sold off.

[NOTES FROM THE FIELD] – Bitlocker leverages the Trusted Platform Module (TPM) version 1.2 to help protect user data and to ensure that a computer has not been tampered with while the system was offline.

The main focus of this topic for the article is to talk about securing files and access control, so this part of what it offers is a little beyond the scope of the conversation.

For additional details on this there is the “What is a TPM” section of the BitLocker Drive Encryption Overview; it is a Vista based article but it is still applicable.

The Windows BitLocker Drive Encryption Step-by-Step Guide is another good detailed document to review.

For our conversation regarding securing files, BitLocker works well on a local drive on a laptop or a desktop as it completely prevents someone from accessing a system in its entirety unless they have a password to start up the system.

Without that password (or the recovery key if the password is lost) the entire system is unavailable.

Fairly skilled people understand that there are ways to get around regular file based security that the operating system offers by installing another version of the operating system locally or booting from a DVD or USB key to work from a lower level of disk access to get to the stored data.

When BitLocker is correctly enabled, the whole area of disk data that is locked out under the encryption is inaccessible to that person even at that low level.

With respect to BitLocker To Go this security of the data is expanded further as it can be leveraged on portable devices to lock all the data even when it is stored on FAT formatted drives keeping the data completely secured from unauthorized access.

The User – the Single Point of Failure

The problem with EFS and BitLocker to Go (most specifically) is that the single point of failure is the end user.

If the end user un-encrypts their EFS locked data or transfers it to a FAT or FAT32 drive it ends up being accessible to anyone that can get to it. If the user sends that data off to themselves in an email it can be left behind in the SENT folder and so forth allowing people that should not have access to it the possibility of getting access to it.

If the end user with the BitLocker to Go device like a USB stick needs to make edits and changes to data and temporarily copies it off the protected device to work on it (as would be the situation under a legacy operating system like Windows XP) and then forgets to delete the local copy, it is left behind unprotected and potentially available to others that should not have access to it.

Active Directory Rights Management Services (AD RMS) takes that point of failure and removes it by taking the control of the data away from the user.

But we’ll cover this in more detail in my next AD RMS article. Stay tuned!

Related posts:

• Active Directory Rights Management Services: Features & Operational Considerations
• Active Directory Rights Management Services: Data Access Controls
• Active Directory Rights Management Services: System Requirements & Other Considerations

This is accomplished through access and usage restrictions that follow the data wherever it is accessed, above and beyond what is set at the folder and file level through NTFS and / or the Encrypting File System (EFS).

By fully leveraging the rights management and access controls available in AD RMS an administrator can drastically reduce the probability (and the possibility) that the data is intentionally or accidentally received by other users that should not have access to the data in the first place.

Today we’ll review Active Directory Rights Management Services as it applies to both Windows Server 2008 as well as Windows Server 2008 R2, and I’ll focus specifically on data access controls.

[NOTES FROM THE FIELD] – Because Server 2008 R2 is in “Release Candidate” status at the moment until it is officially released to manufacturing (RTM), the information is subject to change.

The Basics: Other Types of Access Control

Before we take a look at all the benefits that AD RMS and the AD RMS client offers in the way of locking down permission to data and access rights, I think it’s important to do a historic review of how this was done.

[NOTES FROM THE FIELD] – NTFS permission settings on files and folders are not necessarily relevant when it comes to what AD RMS offers directly, but it does make sense to have an understanding of where the “first” set of permission controls and rights access were introduced.

When your job as a system administrator involved the responsibilities of securing access control to information, historically this meant that you set permissions on the folders and data files themselves. If it was across networks then share permissions might come into play.

These access control permissions were set through the file system and leveraged by the operating system in use. These file and folder access controls could be set to users and / or groups.

ALLOW permissions were cumulative on the local system in that if you were a member of one group and had READ permission and a member of another you had CHANGE / WRITE — so the permissions would combine to give you the least restrictive level of access (in other words, the most control).

If there was a DENY permission anywhere from any one of the groups you were a member of that was a permission setting that trumped all others. Even if the combined access control allowed you FULL CONTROL of a set of data the DENY always had the override and prohibited all access.

This was a problem whenever you had a large environment where a user was a member of many groups for obvious reasons. It got even worse if the administrator decided to set very granular levels of access control by way of NTFS and you’re dealing with inheritance.

More subtly, there might be a reason to limit most people’s READ rights (as an example) to very sensitive information such as exact employee salary and compensation, but what would you do if someone had permission to read and access this information and wanted others to see it?

They could print it out or copy it to a FAT drive (file allocation table) where the file system permissions set by NTFS are removed and anyone that could physically access the data could get their hands on it.

These are some clear and obvious limitations of file system access controls.

Summary of File Based Access Control

So with all these details I thought it made sense to try to net them all out.

There is the additional consideration of inheritance and so forth but in an effort to just keep the overview simple for now consider permissions set on the data object itself.

• NTFS File Permissions

NTFS File Permissions are those set on the files themselves:

Full Control allows for the following level of access control:

• Read
• Write
• Modify
• Execute
• Change attributes
• Permissions
• Take ownership of the file

Modify allows for the following level of access control:

• Read
• Write
• Modify
• Execute
• Change the file’s attributes

Read & Execute:

• Read
• Run / Execute the file — run a program as allowed by other access controls

Read — display the file’s data, attributes, owner, and permissions

Write — write to the file, append the file, and read or change file attributes

• NTFS Folder Permissions

NTFS Folder Permissions are settings made at the folder level locally on the system:

Full Control:

• Read
• Write
• Modify
• Execute files in the folder
• Change attributes permissions
• Take ownership of the folder or files within the folder

Modify:

• Read
• Write
• Modify
• Execute files in the folder
• Take ownership of the folder or files within the folder

Read & Execute:

• Read
• Run / Execute the file — run a program as allowed by other access controls

List Folder Contents:

• Display the folder’s contents
• Display the data itself
• Display the data attributes
• Display the data owner
• Display the data permissions for files within the folder
• Run / Execute the file — run a program as allowed by other access controls

Read — display the file’s data, attributes, owner, and permissions

Write — write to the file, append the file, and read or change file attributes

• Share Permissions

Share Permissions are given to the shared resource over the network:

Read:

• View files and subdirectories
• Execute applications
• No changes can be made

Change:

• View files and subdirectories
• Execute applications
• Add data / subdirectories
• Delete data / subdirectories
• Change / append files or subdirectories

Full Control:

• All of the above

NTFS permissions and share permissions are independent and the most restrictive of the two will be applied to the shared resource.

This would be in the situation that a resource access is attempted across the network (as local access renders share permissions irrelevant).

So in the example of where JOHN has FULL CONTROL of a file locally (NTFS) at the system console but across the network that user only has READ access to the share, JOHN will only be able to READ the data — that would be the maximum control level that user would have accessing the data remotely.

Next Time

In my next article I will go over some of summary details of how the Encrypting File System (EFS) offers another form of access control over data.

Related posts:

• Active Directory Rights Management Services: Features & Operational Considerations
• Active Directory Rights Management Services: Encryption – EFS and BitLocker
• Active Directory Rights Management Services: System Requirements & Other Considerations

When Active Directory was first introduced in Windows Server 2000 it quickly became the most widely implemented Network resource management system in use.

By providing a single logon process from the Windows logon prompt on the client side for authenticated access to all resources locally and on the network as well as a single point of administration, it is hard to argue with results.

The first version of Active Directory used an access control list (ACL) to provide an object based method of managing access to network resources.

Still not every business’ needs were met with the initial release of Active Directory.

Certificate Services, Windows’ method of determining access to web based resources such as email, and Microsoft Metadirectory Services (MMS), Windows’ method for providing central access to multiple network directories, were both separate components from Active Directory.

Here and Now …

When Microsoft released Windows Server 2003 Active Directory’s prominence was secured by adhering to the demands of customers for better integration with other network security components.

Microsoft improved the way Active Directory and Certificate Services worked together. MMS was replaced with Microsoft Identity Integration Server (MIIS), which provided even better integration with other directory types.

Additional features were added in the first revision of Server 2003 such as the Authorization Manager and Windows Rights Management Services (RMS).

The Authorization Manager introduces role-based access control (RBAC) which provides the ability for Administrators to group permissions based on job roles allowing for users to be associated with multiple job roles.

RMS provides the administrator with the ability to associate usage polices that adhere to the new information protection laws to resources. RMS works together with Certificate Services and IIS to uphold its policies on the local network and the World Wide Web.

In Server 2003 Revision 2, Active Directory Federation Services (ADFS) and Active Directory Applications Mode (ADAM) were introduced.

ADFS extends the convenience of Active Directory’s single sign-on authentication to the web by creating a single user session that can be used across multiple web applications.

ADAM was introduced so directory-enabled applications could take advantage of Active Directory’s access control without requiring an actual domain or domain controller.

Windows Server 2008

In Windows Server 2008 Active Directory has continued on its path of integration with its latest family of components. Active Directory components are now available as server roles, which I have listed below:

• Active Directory Domain Services (AD DS)
• Active Directory Certificate Services (AD CS)
• Active Directory Lightweight Directory Services (AD LDS)
• Active Directory Federation Services (AD FS)
• Active Directory Rights Management Services (AD RMS)

As you have probably noticed, the server roles listed above all contain Active Directory in the name. The new Active Directory roles provide the same functionality of the many identity access components from previous Windows Server versions, but with new names.

Active Directory Domain Services (AD DS)

Active Directory Domain Services is the new name for Active Directory Directory Services and remains the core Active Directory Component. Aside from the improvements to the user interface, there are four major improvements to AD DS which I will go over below.

• Read-only domain controllers (RODC) – provide reliable security to insecure environments by replicating a writable domain controller.
  
  Changes cannot be made to a RODC and only the user credentials used with the RODC are stored on the server. This makes it so the whole directory would not need to be rebuilt if security on the RODC were to be breeched.
• Auditing enhancements – there are now four different auditing categories: Directory Service Access, Directory Service Changes, Directory Service Replication and Detailed Directory Service Replication.
  
  This allows for better event searching and logging policy management.
• Granular password and account lockout policies – domains are no longer limited to a single password or lockout policy. Multiple policy objects can now be saved to a domain and applied to groups or users.
• Restartable AD DS – you can now perform maintenance on AD DS by simply stopping the Domain Controller Service.
  
  Before you had to reboot the machine and start in Directory Services Restore Mode to perform maintenance which led to more down time.

Active Directory Certificate Services (AD CS)

Certificate Services is named Active Directory Certificate Services in Server 2008. There are several notable improvements to AD CS. I have listed the major changes below.

• Certificate Web enrollment support improvements – the ActiveX control for Web enrollment, XEnroll.dll, has been replaced with the COM control, CertEnroll.dll. The new control is more secure and manageable.
• Network device enrollment support – AD CS now provides built in support for issuing certificates to network devices to allow applications using the device to interact with other network entities.
• Online certificate status protocol (OCSP) support – Server 2008 includes this as an optional role service.
  
  OCSP checks a certificates status for revocation prevent clients from having to download the entire certificate revocation list, thus improving network performance.
• Enterprise PKI (PKIView) – PKI Health has a new name and can now be used as an MMC snap-in. This tool is used for troubleshooting and monitoring the health of certificates and certificate authorities.
• CAPI2 Diagnostics – a new PKI troubleshooting feature that performs highly detailed logging for several validation processes.

Active Directory Lightweight Directory Services (AD LDS)

Active Directory Lightweight Directory Services (AD LDS) is the new name for Active Directory Application Mode (ADAM).

AD LDS is essentially the same as ADAM except for it is now available as an in-box role in Server 2008 where it needed to be downloaded from the Microsoft Download Center in Server 2003.

As mentioned previously, but referring to ADAM, AD LS is a stripped down version of AD DS designed to be used in applications. Many CRM and HR applications use Active Directory for storing their data. AD LDS can be used instead of AD DS making it possible for these applications to be used without needing to configure access to network resources.

Active Directory Federation Services (AD FS)

The name for Active Directory Federation Services (AD FS) remains the same, save the addition of a space in the acronym.

AD FS allows for businesses to set up trust relationships with other directories, thus enabling the other directory’s user’s credentials to be used across directories. While there is little change to the name, a couple notable improvements have been made which I will go over below.

• Federation trust import/export support – before the process of configuring federation trusts was a long manual process. The manual process is still long, however once set up; settings can be exported and then imported to other AD FS Servers.
• AD FS deployment limiting – a group policy can be applied to disable deployment of AD FS servers on Windows Server 2008.

Active Directory Rights Management Services (AD RMS)

The follow-up to Windows RMS is Active Directory Rights Management Services (AD RMS).

The purpose of AD RMS remains the same as its predecessor. It is now integrated with Office 2007 and Internet Explorer 7 for securing sensitive information hosted on the server. For example, rights can be applied to emails to prevent recipients from forwarding messages.

AD RMS is available as a role in Server 2008 and now includes an MMC snap-in for administration as opposed to a Web-based interface.

Still More to Come …

The Preceding components are the five Active Directory components released in Windows Server 2008. This year, MIIS has been updated for Server 2003 under the title Identity Lifecycle Manager. An updated release for Server 2008 code-named Identity Lifecycle Manager 2 is currently in beta.

Notable new features available to this release include administration from a GUI and SharePoint Services as well as an approval request process for content available from Office 2007 applications. You can find out more about Identity Lifecycle Manager 2 here.

While it would be nice to have had the release of Identity Lifecycle Manager included with Server 2008, it goes to show you that Microsoft knows it’s work is never finished and will keep improvements to Active Directory coming.

Related posts:

• Server 2008: Active Directory Certificate Services
• Server 2008: Install Active Directory Certificate Services
• Windows Server 2008: Install Active Directory Domain Services