Active Directory Rights Management Service (AD RMS) helps administrators get a handle on what users can do with data after being granted access to it. With AD RMS, an administrator can create usage policies that define how a document can be used after a user accesses it. Actions such as copying, saving, forwarding, and even printing documents can be restricted.

To be effective, AD RMS requires AD RMS–enabled client or server applications, such as MS Office, Microsoft Exchange, and Microsoft SharePoint Server. Developers can also create AD RMS–enabled applications by using the AD RMS Software Development Kit (SDK), available on the Microsoft Web site.

AD RMS key features

key features of the new AD RMS server role include the following:
• AD FS integration—AD RMS can be integrated with AD FS to set up a federated trust between organizations. With AD FS, the benefits of AD RMS can be extended outside the corporate network to ensure document security in business-to-business relationships.
• AD RMS Server self-enrollment—An RMS server must connect to the Microsoft Enrollment Service over the Internet to acquire a certificate, which allows the RMS server to issue client licenses and certificates to access protected content. With AD RMS in
Windows Server 2008, the server can self-enroll in this certificate, so there’s no need to contact Microsoft servers.
• Support For mobile and MC computers: new in windows 2012.
• Administrator role delegation—AD RMS enables network administrators to delegate AD RMS responsibilities to different users. There are three AD RMS administrator roles:

• AD RMS Enterprise Administrator: This role has full administrative authority over an AD RMS installation.
• AD RMS Auditor: This role can view RMS-related logs and reports.
• AD RMS Template Administrator: This role can create and manage AD RMS templates
• AD RMS Service Group: Act as the AD RMS service account. During the installation of AD RMS, the user account designated as the service account is automatically added to this group.

AD RMS Components

An AD RMS environment, like an AD FS environment, consists of several components, usually implemented as separate servers:

  • An AD RMS server—The AD RMS server role can be installed on one or more servers. Whether it’s installed on one server or multiple servers, the installation is referred to as an AD RMS root cluster. Multiple servers can be used for redundancy and load balancing.
    Only one AD RMS root cluster can be installed in an Active Directory forest. The AD RMS server self-signs a server licensor certificate (SLC), allowing the server to issue AD RMS client licenses and certificates.
  • An AD RMS database server—AD RMS uses a database to store AD RMS configuration data and Active Directory group membership information. A SQL database installed on a separate server is recommended for production environments, but you can use the
    Microsoft internal database for test environments.
  • An Active Directory domain controller—Servers running the AD RMS server role must be domain members, and users who use or publish AD RMS–enabled content must be in Active Directory with a valid e-mail address.
  • An AD RMS–enabled client computer—AD RMS client software must be installed on computers using AD RMS content. Windows Vista and Server 2008 computers include the necessary software, and older clients can download it from the Microsoft Web site.

The AD RMS process consists of two distinct actions:

  • publication of AD RMS–protected documents :  Publication of an AD RMS–protected document requires the user authoring the document to acquire a rights account certificate (RAC) and a client licensor certificate (CLC).
    With these certificates, the user can publish AD RMS–protected content, which involves the following steps:
    1. Create a document with an AD RMS–enabled application and specify rights for the document. A publishing document with usage policies is created.
    2. The document is encrypted by the AD RMS application, and the publishing certificate is bound to the document. The AD RMS server cluster is the only entity that can issue licenses to decrypt the file.
    3. The document author can now distribute the application for users to access it    .
  • access of these documents by an AD RMS client:
    1. A user attempts to access the document by using an AD RMS–enabled application.
    2. The AD RMS client reads the publishing license.
    3. The AD RMS server specified in the publishing license is contacted to request a use license.
    4. After verifying that the user is authorized to access the document, the AD RMS server issues a use license to the client.
    5. The document is decrypted, and the user can use the document according to the granted rights.
Requirement

requirements:
• Prepare a domain member server for the AD RMS role; its users should be people who will be using AD RMS–protected content.
• Create a service account, which must be a regular domain user account because it interacts with other services and computers. This account should have a strong password and should not be a member of any goups besides Domain Users; no additional rights should be granted to this account.
• Make sure the user account for installing AD RMS has the right to create new databases on the SQL server, if you use an external  atabase.
• If an external database is used, install the database server before installing AD RMS.
• Create a DNS CNAME record for the AD RMS cluster URL; this record is used to access the AD RMS service.

AD RMS certificate types

For AD RMS to operate, it uses various certificates and licenses, most popular ones:

  • Server licensor certificate (SLC): A certificate that contains the public key that encrypts the content key in a publishing license. It allows the AD RMS server to extract the content key and issue end use licenses (EULs) against the publishing key. It is generated when you create the AD RMS cluster. It allows the AD RMS cluster to issue SLCs to other servers in the cluster, rights account certificates to clients, client licensor certificates, publishing licensing, use licenses; and to deploy rights policy templates. It has a validity of 250 years. Since it is one of the core components, it is important to back up the SLCs on a regular basis.
  • Rights account certificate (RAC): A RAC is issued the first time a user attempts to access AD RMS-protected content, which is used to identify a specific user. RACs can be issued only to users in AD DS whose user accounts have email addresses that are associated with them. The default validity time for a RAC is 365 days.
  • Temporary Rights Account Certificate: Issued to users who are accessing AD RMSprotected content from a computer that is not a member of the same or trusted forest as the AD RMS cluster. A temporary RAC has a validity time of 15 minutes.
  •  Client Licensor Certificate: Allows a user to publish AD RMS-protected content when the client computer is not connected to the same network as the AD RMS cluster. The client licensor certificate public key encrypts the symmetric content key and includes it in the publishing license that it issues. The client licensor certificate private key signs any publishing licenses that are issued when the client is not connected to the AD RMS cluster. Since the client licensor certificates are tied to a specific user’s RAC, if another user who does not have a RAC attempts to publish AD RMS-protected content from the same client, they will not be able to until the client is connected to the AD RMS cluster so that the user can get a RAC.
  • Machine Certificate:  Used to identify a trusted computer or device. It is also used to encrypt the rights account certificate private key and decrypt the rights account certificates. It is created when the client computer first uses an AD RMS application. The  certificate is issued by the root cluster and contains the computer’s public key. The private key for the certificate is stored in a “lockbox” on the computer that is associated with the current logged-on user.

Other ones:

  • Active Directory Federation Services (AD FS) RACs: Issued to federated users. They have a validity of seven days.
  • Windows Live ID RAC: Used with a Microsoft account, formerly called a Windows Live Account. Windows Live ID RACs used on private computers have a validity of six months. Windows Live ID RACs on public computers are valid until the user logs off.
AD RMS license types:
  • Publishing license (PL): Determines the rights that apply to AD RMS-protected content. It contain:
    • the content key, which is encrypted using the public key of the licensing service.
    • list of users, which is identified by e-mail address, PL specifes what the users can do with the document.
    • the URL and the digital signature of the AD RMS server.
  • End Use License: Required to access AD RMS-protected content. This license contains the key to decrypt the document. The AD RMS server issues one EUL per user per document. EULs are cached by default.

 

Service Connection Point (SCP)

Management task include:

  • Register the SCP
  • Change the SCP
  • remove the SCP:

ADscpRegister cmd tool, availble in the RMS administration toolkit.

If you have a client computer that is not part of the Active Directory forest, you must use registry keys to point to the AD RMS cluster.

These registry keys are created in the client machine:
HKEY_Local_Machine\Software\Microsoft\MSDRM\ ServiceLocation \ Activation

The Activation key is a string, which would have the value of:

http(s)://your_cluster./wmcs/certification

Rights policy template

Rights policy templates, also known as RMS templates, are used to enforce the rights that a user or group has on rights-protected content. They allow you to standardize the implementing AD RMS policies across the organization. One template may be used on documents to grant view-only rights, which block the ability to edit, save, or print. If used with Microsoft Exchange Server, you can configure the template to block the ability to forward or reply to a message.

FSRM can be sued to scan documents and apply rights policy templates automatically based on resource properties or the contents of the document.

Steps to create Rights policy templates:
  1.  Add Template identification Information: Give a name and description
  2.  Add user rights:

AD RMS templates support the following rights:
• Full Control: Gives a user full control over an AD RMS–protected document including the ability to give other people access to the document.
• View: Gives a user the ability to view an AD RMS–protected document.
• Edit: Allows a user to modify an AD RMS–protected document.
• Save: Allows a user to use the Save function with an AD RMS–protected document.
• Export (Save as): Allows a user to use the Save As function with an AD RMS–protected document.
• Print: Allows an AD RMS–protected document to be printed.
• Forward: Used with Exchange Server, allows the recipient of an AD RMS–protected message to forward that message.
• Reply: Used with Exchange Server, allows the recipient of an AD RMS–protected message to reply to that message.
• Reply All: Used with Exchange Server, allows the recipient of an AD RMS–protected message to use the Reply All function to reply to that message.
• Extract: Allows the user to copy data from the file. If this right is not granted, the user cannot copy data from the file.
• Allow Macros: Allow the user to utilize macros.
• View Rights: Allow the user to view assigned rights.
• Edit Rights: Allow the user to modify the assigned rights.

3. Specify Expiration Policy:

Determine whether the published document availability expires. You can specify expiration parameters for content availability and for the use license. If the use license expires, the documents is no longer available to users, and users must get another license.

4. Specify Extended Policy:

Configure additional content protection options:

  • Enable users to view protected content by using a browser add-on
  • Require a new use license every time content is consumed (disable client-side caching): If users should not be able to open protected content when they are disconnected from the network, you should enable this option.
  • Application-specific options: You can specify additional policies with values that are specific to the application.

5. Specify Revocation Policy: You use these settings to specify what content can be revoked, which disallows access to content based on the content ID, user, or application. If you enable revocation, specify the URL of the revocation list.

Configuring Exclusion Policies

Exclusion policies allow you to specify which user accounts, AD RMS client versions, client software, and applications are automatically denied access to AD RMS. They also allow you to specify a minimum version of the AD RMS client software.

  • The User Exclusion policy allows you to configure AD RMS so that specific user accounts cannot obtain Use Licenses. User Exclusion is disabled by default. After you enable User Exclusion, you can specify the RACs based on the user’s email address (Active Directory Domain Services accounts) or public key strings (for external users).
  • Application Exclusion allows you to block specific applications, such as Office PowerPoint, from creating or consuming AD RMS–protected content. The criteria is based on application’s filename and its minimum and maximum version level. Application Exclusion is disabled by default.
  • The Lockbox Exclusion allows you to exclude older AD RMS clients. Lockbox version exclusion is disabled by default. After you have enabled Lockbox version exclusion, you must specify the minimum lockbox version that can be used with the AD RMS cluster.

 

Trust policies

To grant users from different organization or forest the ability to acquire use licenses to protected content in your forest.

There are three types of trust policies:

  1. Trusted User Domains
  2. Trusted Publishing Domains
  3. Federated Identity Support
trusted User Domains

By default, Active Directory Rights Management Services do not service requests from users whose rights account certificate (RAC) was issued by a different AD RMS server.
However, you can add user domains to the list of trusted user domains (TUDs), which allow AD RMS to process the requests. A TUD establishes a trust between AD RMS clusters in separate forest so that users in the trusted forest can access AD RMS content in the trusting forest.

Features:

  • One-way trust.
  • Connectivity between clusters must exists: Each time a user access content protected by the remote AD RMS cluster, the user receives the use license from the remote cluster. The reason for this is The TUD file contains the server licensor certificate (SLC) but does not contain the private key.
  • TUD does not require AD forest trust between forests, this trust makes it easier to work with groups of users from partner organization.

Process of establishing a TUD has two steps:

  1. Export the trusted user domain file on the trusted AD RMS cluster. The TUD file contains the server licensor certificate (SLC) but does not contain the private key.
    To export the TUD certificate, perform the following steps:
    1. Using the Server Manager, open the Active Directory Rights Management Services console.
    2. Expand the cluster, expand Trust Policies, and click Trusted User Domains.
    3. In the Center pane, under the Trusted User Domain Information section, right-click the certificate of the TUD, and then click Export Trusted User Domain.
    4. When the Export Trusted User Domain As dialog box opens, type a meaningful name in the File name text box, and click Save .
  2. Import the trusted user domain file on the trusting AD RMS cluster.
    To import the TUD certificate, perform the following steps:
    1. Using the Server Manager, open the Active Directory Rights Management Services console.
    2. Expand the cluster, expand Trust Policies, and click Trusted User Domains.
    3. In the Actions pane, click Import Trusted User Domain.
    4. In the Trusted user domain file text box, type the path to the exported server licensor certificate of the user domain to trust or click Browse to locate it.
    5. In Display name text box, type a name to identify this trusted user domain. If you would like to extend this trust to federated users, select Extend trust to federated users of the imported server.
    6. Click Finish.

Process of publishing and access the protected content:

  1. A user from the trusting partner publishes protected content, which is sent to the user from the trusted partner.
  2. The user from the trusted partner acquires an RAC from his or her local AD RMS server.
  3. The RAC is sent to the trusting partner’s AD RMS cluster to request a use license.
  4. The RAC is validated by the trusting partner, and a use license is issued to the user.

 

 

Trusted publishing domain (TPD)

A trusted publishing domain allows an AD RMS cluster to issue use licenses for content published by another AD RMS cluster. With a TPD, the private key and rights policy templates are exported from the trusted domain.

  • So after the trust is established and content is published, there is no need for trusted cluster to have connectivity.
  • Because the private key is exported along with the SLC, a higher degreen of trust must exist. Typically only in same organization.

Process of establishing a TPD has two steps:

  1. Export the trusted publishing domain file on the trusted AD RMS cluster. The TPD file contains the server licensor certificate (SLC) and the private key.
  2. Import the trusted publishing domain file on the trusting AD RMS cluster.

Process of publishing and access the protected content:

  1. A user from the trusting partner publishes protected content, which is sent to the user from the trusted partner.
  2. The user from the trusted partner attempts to open the protected content and requests an RAC from his or her local AD RMS server.
  3. The AD RMS server uses the private key imported from the trusting partner to create the use license is issued to the user.
Federated Identity support

Federated Identity Support allows users accounts to use credentials established by a federated trust relationship using Active Directory Federation Services (AD FS) instead of setting up trusted publishing domains or trusted user domains. When used with AD FS, users obtain rights account certificates from an AD RMS cluster.

When the rights account certificates are issued from a federated identity, the standard rights account certificate validity periods do not apply. Instead, the validity periods are specified in the Federated Identity Support settings.

In addition, because this is not a normal Active Directory trust, the trusts are not transitive, which means that other domains that are linked to remote domains are not automatically trusted by the other organization. However, when you are importing a Trusted User Domain, there is an option to trust federated users of the imported domain.

Process occurs when a user publishes protected content:

  1. A user from the publishing AD RMS cluster publishes protected content, which is sent to the user in the partner organization.
  2. The user from the partner organization attempts to open the protected content.
  3. An AD RMS server in the publishing cluster is contacted.
  4. The request to the AD RMS server is redirected to a federation server in the publishing organization
  5. The federation server requests identify confirmation from a federation server in the partner organization
  6. The user contacts his or her home federation server, and the client is authenticated by AD.
  7. The federation server confirms the user’s identity, and the user contacts the AD RMS server in the publishing organization with proof of identity.
  8. The AD RMS server in the publishing organization issues a use certificate to the user.

 

Backup and restore the AD RMS

The backup of AD RMS involves the following Procedures:

1. Backup the AD RMS database: there are three databases:
a, the configuration database is the most important one, as it containsthe data needed to manage account certification and licensing.
b, Directory service database contains cached content from AD, including users, group memberships, and security IDs.
c, The logging database contains log files about issued licenses and client activity.

2. Export the trusted publishing domain file : see the previous part.

3. Store the cluster key password in a safe place: If you don’t know the password, you can change it first in the AD RMS console by clicking Security Policies, cluster key password in the left pane, and then clicking the “change cluster key password”. If you do change the password, you must change it on all AD RMS servers in the cluster.

Restore the Configuration:

1. During the installation, choose the option to Join an existing AD RMS cluster , then you can supply the location of the AD RMS configuration database and cluster key password.

2. After the installation is finished, import the trusted publishing domain file.