Active Directory Rights Management Services (AD RMS) in Windows Server®
2012. These changes should enable IT professionals working with AD RMS
to meet the needs of their business in a secure, reliable and flexible
way.
AD RMS is the server role that provides you with management and
development tools that work with industry security
technologies—including encryption, certificates, and authentication—to
help organizations create reliable information protection solutions. For
more information, see Active Directory Rights Management Services Overview.
New AD RMS features covered in this topic include:
New AD RMS features covered in this topic include:
-
Changes to AD RMS and Microsoft SQL Server requirements.
-
Changes in deployment of AD RMS when using Server Manager and Windows PowerShell
For
Windows Server 2012, requirements for configuring Microsoft SQL Server
to support AD RMS have been revised or changed in response to customer
feedback.
What value does this change add?
The following changes to AD RMS Setup have been made to enable better support for remote deployment of AD RMS and SQL servers and to address customer feedback that requested more flexible deployment options.
What works differently?
In previous releases, AD RMS setup required that the account used to install AD RMS must have local administrator privilege on any computers hosting a SQL Server installation that was to be used to support the storage of AD RMS-related data. This was because AD RMS Setup required the ability to read SQL database settings from the Windows Registry. Because of customer feedback, this has been changed for this release.
For Windows Server 2012, AD RMS now has the following requirements for access to SQL Server.
What value does this change add?
The following changes to AD RMS Setup have been made to enable better support for remote deployment of AD RMS and SQL servers and to address customer feedback that requested more flexible deployment options.
What works differently?
In previous releases, AD RMS setup required that the account used to install AD RMS must have local administrator privilege on any computers hosting a SQL Server installation that was to be used to support the storage of AD RMS-related data. This was because AD RMS Setup required the ability to read SQL database settings from the Windows Registry. Because of customer feedback, this has been changed for this release.
For Windows Server 2012, AD RMS now has the following requirements for access to SQL Server.
-
The AD RMS installer account must have sysadmin permissions in the SQL Server installation.
-
The SQL Server Browser service must be running to locate available SQL instances.
-
Firewall exceptions should be enabled on the SQL server
computer for ports that will be used by AD RMS setup. The TCP port for
the SQL instance that will host the AD RMS databases should be enabled.
The UDP port for the SQL Server Browser service should also be enabled.
For example, the default ports are usually TCP port 1433 for the SQL
Server instance and UDP port 1434 for the SQL Server Browser service.
-
SQL Server 2005 Service Pack 3
-
SQL Server 2008 Service Pack 3
-
SQL Server 2008 R2 Service Pack 1
-
SQL Server 2012
In
previous releases, AD RMS Setup supported only deployment at the same
server computer where AD RMS was to be installed. Based on customer
feedback, this has been changed. For Windows Server 2012, AD RMS now
supports remote deployment at targeted server computers.
What value does this change add?
The following changes to AD RMS Setup have been made to enable better integration with the newly revised Server Manager in Windows Server 2012 which better supports secure and flexible remote server deployment for AD RMS and other Active Directory technologies.
What works differently?
As a result of this change, when deploying AD RMS on remote servers to ensure the security of your deployment, you will be prompted for user credentials. Deployment now also requires an additional step that can be completed using either Server Manager or Windows PowerShell.
What value does this change add?
The following changes to AD RMS Setup have been made to enable better integration with the newly revised Server Manager in Windows Server 2012 which better supports secure and flexible remote server deployment for AD RMS and other Active Directory technologies.
What works differently?
As a result of this change, when deploying AD RMS on remote servers to ensure the security of your deployment, you will be prompted for user credentials. Deployment now also requires an additional step that can be completed using either Server Manager or Windows PowerShell.
For
Windows Server 2012, Server Manager has been redesigned to provide
support for remote deployment of AD RMS as part of a two-step process
that can be summarized as follows:
The requirements for selecting the credentials that you enter here are as follows:
-
Launch the Add Roles and Features Wizard in Server Manager to
add the AD RMS role. This will add and install the files necessary for
AD RMS.
-
After adding the AD RMS role, launch the AD RMS Configuration
wizard to select deployment options and configure the AD RMS cluster.
The requirements for selecting the credentials that you enter here are as follows:
-
The account used to deploy AD RMS must have membership in the
local Administrators group on the server computer where you are
installing and configuring AD RMS.
-
The account used must also have sysadmin permissions on the
server that hosts the configuration database for the AD RMS cluster.
Note
Prompting for credentials only occurs in Server Manager if you are installing AD RMS to a remote server; however, the credentials requirements are the same for installing locally.
| Note |
|---|
If you are going to be viewing reports related to AD RMS, you
must also install the .NET Framework 3.5 using Server Manager (or by
typing Install-WindowsFeature NET-Framework-Core at the
Windows PowerShell prompt) prior to installing the Microsoft Report
Viewer 2008, which is used to generate troubleshooting and system health
reports on AD RMS in Windows Server 2012. For more information, see the
Test Lab Guide: Deploying an AD RMS Cluster. |
For
Windows Server 2012, you can now optionally complete the two-part
AD RMS deployment process as described in the previous section using
Windows PowerShell commands. In Windows Server 2008 R2, the ADRMS module
was provided as part of the base operating system but this has changed
to enable more flexibility and modularity in installing the product. For
this release, you need to use commands provided within the new
ServerManager module for Windows PowerShell.
For example, to complete the first part of the deployment process (copy and install all required files for AD RMS) you would use the following Server Manager cmdlet examples at a Windows PowerShell prompt.
You can then install AD RMS by using the Install-ADRMS cmdlet which is provided as part of the AD RMS deployment module for Windows PowerShell. When using this cmdlet, use the new Credentials
parameter as shown below. This parameter is required to support remote
deployments and is recommended that you include it for all
PowerShell-based deployments.
By adding the -Credential parameter you will be
prompted to enter the required credentials to deploy AD RMS. If the
installation is targeted for a remote computer, credentials must be
passed through and validated at the remote computer before installation
of AD RMS will proceed.
For example, to complete the first part of the deployment process (copy and install all required files for AD RMS) you would use the following Server Manager cmdlet examples at a Windows PowerShell prompt.
| Example | Description |
|---|---|
Add-WindowsFeature ADRMS –IncludeAllSubFeature -IncludeManagementTools | Adds all AD RMS role services and tools. This command downloads and makes available all support files needed to work with AD RMS. |
Add-WindowsFeature ADRMS-Server | Adds the AD RMS server role only. This command downloads and makes available those files needed to support an AD RMS server installation. |
Add-WindowsFeature ADRMS-Identity | Adds identity federation support for AD RMS. This command downloads and makes available files needed to support AD RMS working with AD FS. |
Install-ADRMS –Path adrmsDrive:\ -Credential
For
Windows Server 2012, uninstalling AD RMS can also be accomplished using
Windows PowerShell as a two-step process comparable to a reversal of
the process described in the previous section for AD RMS deployment.
This process can be summarized as follows:
-
Uninstall the AD RMS role.
This can be performed separately by using Windows PowerShell and running the Uninstall-ADRMS cmdlet in the ADRMS module. -
Remove the AD RMS files and registry settings that were previously added to support AD RMS.
If you are using Windows PowerShell, use the Remove-WindowsFeature ADRMS cmdlet in the ServerManager module to perform this step as a separate action.
| Note |
|---|
| If you use the Remove Roles and Features Wizard in Server Manager to remove the AD RMS role it accomplishes as a single action both of the steps summarized above. Also, this same joint action occurs if you run Remove-WindowsFeature ADRMS, which calls the Uninstall-ADRMS cmdlet. |
In
addition to new changes to Windows PowerShell that affect deployment of
the AD RMS role and its services and components, new properties have
been added for Windows Server 2012 that can be used when deploying
AD RMS installations. The following table provides details and comments
on where these new properties can be used to support new changes such as
support for strong cryptography.
| Install Type | Container | Property | Default Value | Description |
|---|---|---|---|---|
| RootCluster | CryptoSupport | SupportCryptoMode2 | True | This container appears by default and is set to enable support for strong cryptography. |
| RootCluster | SSLCertificateSupport | — | — | This container only appears when the ClusterURL property is set to HTTPS. |
| RootCluster | SSLCertificateSupport | SSLCertificateOption | ChooseLater | The default for this property enables you to choose a certificate later after deploying AD RMS. Other alternate values include Create (enables creation of a self-signed certificate) or Existing (Enables use of an existing certificate). |
| RootCluster | SSLCertificateSupport | Thumbprint | [not set] | This property is used to specify the thumbprint to identify a certificate. It only appears when the SSLCertificateOption property is set to Existing. |
| LicensingCluster | SSLCertificateSupport | — | — | This container only appears when the ClusterURL property is set to HTTPS. |
| LicensingCluster | SSLCertificateSupport | SSLCertificateOption | ChooseLater | The default for this property enables you to choose a certificate later after deploying AD RMS. Other alternate values include Create (enables creation of a self-signed certificate) or Existing (Enables use of an existing certificate). |
| LicensingCluster | SSLCertificateSupport | Thumbprint | [not set] | This property is used to specify the thumbprint to identify a certificate. It only appears when the SSLCertificateOption property is set to Existing. |
| JoinCluster | SSLCertificateSupport | — | — | This container appears when the DatabaseName property is set to a cluster database that is using SSL. |
| JoinCluster | SSLCertificateSupport | SSLCertificateOption | ChooseLater | The default for this property enables you to choose a certificate later after deploying AD RMS. Other alternate values include Create (enables creation of a self-signed certificate) or Existing (Enables use of an existing certificate). |
| JoinCluster | SSLCertificateSupport | Thumbprint | [not set] | This property is used to specify the thumbprint to identify a certificate. It only appears when the SSLCertificateOption property is set to Existing. |
| JoinCluster | ADFSSupport | — | — | This container exists by default in all AD RMS installations that are running at Windows 2008 R2 or later but only appears in Windows Server 2012 if the ADRMS-Identity role service is installed. |
| JoinCluster | ADFSSupport | ADFSUrl | [not set] | The value of this property must be a Web address (URL) to a valid AD FS server. For example, "http:// fs.corp.contoso.com" |
| Note |
|---|
When the SSLCertificateOption property is configured to use a
value of Existing and the Thumbprint property is empty or not set, it
might appear incorrectly that installation of AD RMS has failed when
using the Install-ADRMS cmdlet in a Windows PowerShell
session. For example, under these conditions, you see the following
error message after a PowerShell-based installation. PS rmsdrive:\> install-adrms -path . -force Install-ADRMS : Value cannot be null. Parameter name: findValue At line:1 char:1If such an error should appear, it indicates only that AD RMS is missing an expected SSL binding. If this happens, you can assume that AD RMS is fully provisioned and operating as expected. To address the issue, you only need to configure SSL certificates on IIS before using the AD RMS server. |
In
previous releases of AD RMS included with Windows Server® 2008 and
Windows Server® 2008 R2 it was not possible to launch more than a single
instance of the AD RMS Configuration wizard to install or update
multiple AD RMS deployments from the same server computer. Because of
design changes to Server Manager for Windows Server 2012, multiple
instances of the Add Roles and Features Wizard can now be run
simultaneously, making it possible to launch two or more instances of
the AD RMS Configuration wizard.
What value does this change add?
The changes to Server Manager in Windows Server 2012 enable server roles and technologies across Windows Server 2012 to be more open, efficient and flexible when you are choosing role deployment options.
What works differently?
As a result of changes to Server Manager to enable multiple instances to be deployed and configured simultaneously in Windows Server 2012 and because this change is at odds with how AD RMS is best designed to be deployed, AD RMS setup is not able to prevent multiple AD RMS configuration wizards from being launched to create new clusters or for joining an existing cluster. Therefore, the AD RMS Configuration wizard applies the following logic and process detection to determine how to manage the occurrence of multiple instances of AD RMS setup occurring at the same time.
What value does this change add?
The changes to Server Manager in Windows Server 2012 enable server roles and technologies across Windows Server 2012 to be more open, efficient and flexible when you are choosing role deployment options.
What works differently?
As a result of changes to Server Manager to enable multiple instances to be deployed and configured simultaneously in Windows Server 2012 and because this change is at odds with how AD RMS is best designed to be deployed, AD RMS setup is not able to prevent multiple AD RMS configuration wizards from being launched to create new clusters or for joining an existing cluster. Therefore, the AD RMS Configuration wizard applies the following logic and process detection to determine how to manage the occurrence of multiple instances of AD RMS setup occurring at the same time.
-
If multiple instances are launched and are used to join an
already existing AD RMS cluster, AD RMS setup should succeed for all
active instances.
-
If multiple instances are launched and are being used to try to
create the same new AD RMS cluster, AD RMS setup fails for all active
instances.
This
section describes issues to consider when you deploy AD RMS on virtual
machines. In general, AD RMS is well suited to virtualization especially
for testing and evaluation purposes. There are, however, a few
practices that you should observe when you are working with virtualized
AD RMS servers. The following section describes these considerations.
What value does this change add?
Using virtualization platforms, such as Hyper-V to deploy AD RMS for evaluation purposes offers a number of convenience features that can make testing easier. For example, virtualization enables you to easily establish a full private virtual networked configuration separate from your production networked environment in which you can freely test and evaluate AD RMS deployment to your satisfaction before attempting a deployment of it in your production environment.
What works differently?
When working with virtualized AD RMS servers, the following are some deployment practices and features that need to be observed or followed for best results.
What value does this change add?
Using virtualization platforms, such as Hyper-V to deploy AD RMS for evaluation purposes offers a number of convenience features that can make testing easier. For example, virtualization enables you to easily establish a full private virtual networked configuration separate from your production networked environment in which you can freely test and evaluate AD RMS deployment to your satisfaction before attempting a deployment of it in your production environment.
What works differently?
When working with virtualized AD RMS servers, the following are some deployment practices and features that need to be observed or followed for best results.
-
To ensure consistent performance between virtualized AD RMS
servers operating in test conditions to how a comparable physical AD RMS
server might perform in a subsequent production deployment of AD RMS,
follow the recommended guidance requirements as you create your virtual
machines and then use those as well for installing AD RMS on a physical
server computer. In particular, select the recommended amount of RAM for
virtual AD RMS servers to the higher recommended amount. If you follow
recommended hardware guidelines, there should be no perceptible
difference in performance between virtualized test server deployments of
AD RMS and any comparable physical server installations you might later
deploy into production as a result of your virtual lab test results.
-
When you install AD RMS on a virtual server you will not be able
to use an internal hardware security module (HSM) for AD RMS key
storage. You can, however, use all other forms of key storage: network
HSM key storage, AD RMS centrally managed key storage and software CSP
key storage.
-
If you have previously installed AD RMS on a virtual hard drive
(VHD) and then take that VHD offline to uninstall AD RMS, the AD RMS
role will not be completely removed. To ensure full and proper removal
of AD RMS, you should remove the AD RMS server role first before
shutting down any VHD associated with the original installation of
AD RMS on your virtual machine.
For
Windows Server 2012, AD RMS now joins the list of server roles such as
Active Directory Domain Services (AD DS) and Active Directory
Certificate Services (AD CS) that are supported for Server Core
deployment. Server Core is an installation option that enables you to
perform a minimal installation of the Windows Server operating system
which can be useful for reducing total cost of ownership (TCO) in
deploying and managing servers.
What value does this change add?
Using Server Core to deploy AD RMS can provide you with simplified management, reduced maintenance, reduced memory and disk requirements and a reduced attack surface. Servers that run under Server Core can be simpler and less costly to manage and more stable and secure in production deployments. For more information, see What is Server Core? and Why is Server Core Useful?
What works differently?
In Windows Server 2012, the Server Core installation option is no longer an irrevocable selection that is made during setup. In Windows Server 2008 R2 and Windows Server 2008, if your requirements changed, there was no way to convert between a full installation and Server Core installation without completely reinstalling the operating system. You can now administratively convert between a full Windows Server installation and running on Server Core as needed. For more information, see Windows Server Installation Options.
On Server Core installations, the optional Identity Federation Support role service for the AD RMS server role is not supported. This is because Identity Federation Support relies on a role service of the AD FS Server role, the Claims-aware Agent, which is disabled on Server Core installations.
If you attempt to add Identity Federation Support for AD RMS, the following error will occur.
The instructions to work around the issue by downloading the source
files do not apply for this case. Identity Federation Support cannot be
installed because the Claims-aware Agent is disabled on Server Core.
What value does this change add?
Using Server Core to deploy AD RMS can provide you with simplified management, reduced maintenance, reduced memory and disk requirements and a reduced attack surface. Servers that run under Server Core can be simpler and less costly to manage and more stable and secure in production deployments. For more information, see What is Server Core? and Why is Server Core Useful?
What works differently?
In Windows Server 2012, the Server Core installation option is no longer an irrevocable selection that is made during setup. In Windows Server 2008 R2 and Windows Server 2008, if your requirements changed, there was no way to convert between a full installation and Server Core installation without completely reinstalling the operating system. You can now administratively convert between a full Windows Server installation and running on Server Core as needed. For more information, see Windows Server Installation Options.
On Server Core installations, the optional Identity Federation Support role service for the AD RMS server role is not supported. This is because Identity Federation Support relies on a role service of the AD FS Server role, the Claims-aware Agent, which is disabled on Server Core installations.
If you attempt to add Identity Federation Support for AD RMS, the following error will occur.
The request to add or remove features on the specified server failed. Installation of one or more roles, role services, or features failed. - The source files could not be downloaded. Use the /source option to specify the location of the files that are required to restore the feature. The file location should either be the root directory of a mounted image or a component store that has the Windows Side-by-Side directory as an immediate subfolder.
Windows Server 2012 also includes the following feature updates,
which have been added recently as updates for the AD RMS role in Windows
Server 2008 R2.
-
Simple delegation
-
Strong cryptography
Simple
delegation for AD RMS enables you to have the same access rights to
protected content that are assigned to one person delegated to other
individuals within their organization.
What value does this change add?
Simple delegation provides the ability to have content rights assigned to executives and managers be easily and effectively delegated to their assistants. This enables the assistants to have the same level of access permission to Information Rights Management (IRM)-protected content as the executive. By extending the Active Directory schema to support two new attributes, delegation of rights can be easily turned on or off as needed to accomplish the appropriate level of privilege or restriction for those who support the leadership and management of your organization.
What works differently?
The requirements for enabling the use of AD RMS simple delegation in Windows Server 2012 are similar to the requirements for using it in Windows Server 2008 R2. Two attributes, msRMSDelegator and msRMSDelegatorBL must be added to the Active Directory schema. This can be done using update files executed using the Ldifde.exe tool. These extension attributes must be applied to all forests where AD RMS licensing occurs. Also, you might also need to set additional permissions for AD RMS to read these attributes and update your SQL installation that supports AD RMS as part of preparing your deployment to support the use of simple delegation as well.
The only other change in requirements for simple delegation in Windows Server 2012 that differs from how it was enabled in Windows Server 2008 R2 is a new AD RMS PowerShell property that can be used to enable and disable it. By default, the feature is disabled, however, to enable simple delegation use the following command line at an elevated Windows PowerShell prompt at an AD RMS provided PowerShell drive:
For more information, see An update is available to enable simple delegation in AD RMS on Windows Server 2008 R2-based computers.
What value does this change add?
Simple delegation provides the ability to have content rights assigned to executives and managers be easily and effectively delegated to their assistants. This enables the assistants to have the same level of access permission to Information Rights Management (IRM)-protected content as the executive. By extending the Active Directory schema to support two new attributes, delegation of rights can be easily turned on or off as needed to accomplish the appropriate level of privilege or restriction for those who support the leadership and management of your organization.
What works differently?
The requirements for enabling the use of AD RMS simple delegation in Windows Server 2012 are similar to the requirements for using it in Windows Server 2008 R2. Two attributes, msRMSDelegator and msRMSDelegatorBL must be added to the Active Directory schema. This can be done using update files executed using the Ldifde.exe tool. These extension attributes must be applied to all forests where AD RMS licensing occurs. Also, you might also need to set additional permissions for AD RMS to read these attributes and update your SQL installation that supports AD RMS as part of preparing your deployment to support the use of simple delegation as well.
The only other change in requirements for simple delegation in Windows Server 2012 that differs from how it was enabled in Windows Server 2008 R2 is a new AD RMS PowerShell property that can be used to enable and disable it. By default, the feature is disabled, however, to enable simple delegation use the following command line at an elevated Windows PowerShell prompt at an AD RMS provided PowerShell drive:
PS w:\SecurityPolicy\Delegation> Set-ItemProperty -path . –Name IsEnabled –Value $true
Strong
cryptography for AD RMS enables you to increase the cryptographic
strength of your AD RMS deployment by running in an advanced mode known
as cryptographic mode 2.
What value does this change add?
Running AD RMS in strong cryptographic provides an updated and enhanced cryptographic implementation to support much stronger encryption as well as stronger cryptographic keys. For example, in mode 2 operation, RSA encryption is enhanced from 1024 bit encryption to 2048 bit encryption. Also, cryptographic keys are also longer (moved from 160 bit keys to using 256 bit keys) and the option to use a SHA-2 hashing algorithm (SHA-2/SHA-256) standards.
The value of strong cryptography in AD RMS is that it can be part of enabling your organization to satisfy regulatory compliance with current security standards that are set by the National Institute of Standards and Technology (NIST). Starting January 1, 2011, NIST issued Special Publication 800-57 which recommends the use of 2048-bit RSA keys. United States Federal agencies are required to comply with NIST recommendations and many private enterprises and other countries may choose to implement this recommendation. To learn more, see NIST Special Publications (http://csrc.nist.gov/publications/PubsSPs.html).
What works differently?
To enable the use of strong cryptography in your AD RMS deployment, all computers that host either AD RMS server or client software must be patched and updated.
To update AD RMS servers to cryptographic mode 2, you can use the AD RMS management console or the AD RMS cmdlets for Windows PowerShell.
Using the AD RMS management console, you can choose to update existing AD RMS servers from cryptographic mode 1 to cryptographic mode 2 by doing the following:
To update to Cryptographic Mode 2 using Windows PowerShell, use the following syntax:
The following items apply to the parameters specified as part of the above syntax:
What value does this change add?
Running AD RMS in strong cryptographic provides an updated and enhanced cryptographic implementation to support much stronger encryption as well as stronger cryptographic keys. For example, in mode 2 operation, RSA encryption is enhanced from 1024 bit encryption to 2048 bit encryption. Also, cryptographic keys are also longer (moved from 160 bit keys to using 256 bit keys) and the option to use a SHA-2 hashing algorithm (SHA-2/SHA-256) standards.
The value of strong cryptography in AD RMS is that it can be part of enabling your organization to satisfy regulatory compliance with current security standards that are set by the National Institute of Standards and Technology (NIST). Starting January 1, 2011, NIST issued Special Publication 800-57 which recommends the use of 2048-bit RSA keys. United States Federal agencies are required to comply with NIST recommendations and many private enterprises and other countries may choose to implement this recommendation. To learn more, see NIST Special Publications (http://csrc.nist.gov/publications/PubsSPs.html).
What works differently?
To enable the use of strong cryptography in your AD RMS deployment, all computers that host either AD RMS server or client software must be patched and updated.
To update AD RMS servers to cryptographic mode 2, you can use the AD RMS management console or the AD RMS cmdlets for Windows PowerShell.
Using the AD RMS management console, you can choose to update existing AD RMS servers from cryptographic mode 1 to cryptographic mode 2 by doing the following:
-
In the navigation pane, select the AD RMS server you want to upgrade.
-
From the Action menu (or in the Actions pane), select the Update to Cryptographic Mode 2 option.
To update to Cryptographic Mode 2 using Windows PowerShell, use the following syntax:
Update-ADRMS –UpdateCryptographicModeOnly –ServiceAccount <PSCredential> -force –NewCSPName <”Mode2 Supported CSP”> -Regen
- UpdateCryptographicModeOnly
is the parameter that indicates that cryptographic mode 2 should be
enabled. This is a one-way operation. Once complete, you cannot return
the AD RMS server to cryptographic mode 1.
-
The Force parameter is an optional switch that can be used to override prompting for user confirmation.
-
The NewCSPName parameter indicates the
cryptographic providers that you want to use for encryption. This is an
optional setting depending on your current cryptographic key settings.
By default it is the Microsoft Enhanced RSA and AES Cryptographic
Service Provider, but could also be another cryptographic mode 2
provider, such as one from a Hardware Security Module (HSM) that
supports at least 2048 bit encryption.
The CSP name cannot be specified for centrally managed keys. If an AD RMS cluster is using a centrally managed key for cryptographic mode 1, it must update to a centrally managed key for cryptographic mode 2. It cannot update to a CSP key.
Update-ADRMS –UpdateCryptographicModeOnly –ServiceAccount ADRMSSvc –NewCSPName "Microsoft Enhanced RSA and AES Cryptographi
Figure 1 AD DS Configuration Wizard