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

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