Hardening Guide for Microsoft Windows Rights Management Services

By Brian Lich, Technical Writer, Microsoft Corporation

See other Security Tip of the Month columns

Microsoft Windows Rights Management Services (RMS) is a product that allows you to assign and enforce content use policies on e-mail messages, documents, and other objects controlled by an RMS-enabled application. The protection offered by RMS is embedded into the content when it is rights-protected and stays with it regardless of where it goes.

RMS is designed with security in mind, but additional steps can be taken to further enhance the security of an RMS deployment beyond the default installation settings:

  • Use SSL certificate authentication on the RMS Web services. Requests from the RMS client to the RMS cluster are not encrypted by default. By installing a Secure Sockets Layer (SSL) certificate and requiring SSL authentication on the RMS virtual directories on all RMS servers in the cluster, certification and licensing requests are encrypted as they are sent over the network. For additional security, you can enable smartcard authentication for the RMS Web services.

  • Use a hardware-based CSP to protect the RMS private key. When installing RMS, the default key protection for RMS cluster private keys is a software-based cryptographic service provider (CSP) that encrypts the RMS cluster's key and stores it in the RMS configuration database. For additional security, a hardware-based CSP, or hardware security module, can be used. This method of key protection stores the key on a smartcard that is attached to the RMS servers. The advantage to a hardware-based CSP is that the RMS private key is not stored on the computer. Safenet, Inc., and nCipher Corporation provide hardware-based CSPs that have been tested with RMS.

  • Protect the RMS super users group. The RMS super users group has full control over all rights-protected content and should be enabled and used only when necessary. Because of this, an Active Directory–restricted group should be used to control membership to the RMS super users group. An Active Directory-restricted group is managed through a group policy object in Active Directory and has the ability to tightly control its membership.

  • Use a domain account for RMS service account with standard privileges. A domain account that is in the Active Directory Domain Users security group should be used for the RMS service account. This account should not be granted any additional privileges.

  • Protect the e-mail address Active Directory attribute. RMS-enabled Microsoft Office applications use the e-mail and proxyaddresses attributes stored in Active Directory as the RMS user's unique identity to certify and license rights-protected content. It is very important to limit permissions on these attributes in Active Directory to trusted administrators. Furthermore, information security policies should be in place within your organization that prohibit the ability to recycle an e-mail address to another user.

  • Enhance ACLs on the RMS pipelines. The access control lists (ACLs) on the pipelines in the RMS Internet Information Services (IIS) virtual directory are restrictive by default. However for more control over who can use RMS, you can limit the RMS certification and publishing pipelines to specific Active Directory security groups, as opposed to using the default Domain Users security group.

  • Turn off anonymous authentication on RMS licensing pipeline. If your RMS topology does not require external users, such as .NET Passport, anonymous authentication should be turned off on the RMS licensing pipeline.

  • Minimize the number of services on all RMS servers. As with any defense-in-depth strategy for securing servers, all unnecessary services should be disabled on all of the individual RMS servers in each RMS cluster. In an RMS environment, RMS and required components should be the only services running on the RMS cluster servers.

  • Use an application layer firewall when using RMS in an extranet. When using RMS in an extranet scenario, an application layer firewall should be used. An application layer firewall, such as Microsoft Internet Security and Acceleration (ISA) Server, inspects the licensing and certification requests sent to the RMS server by terminating the SSL connection at the firewall, inspecting the traffic, and then reestablishing a separate connection internally.

  • Turn off Microsoft SQL Server Authentication on RMS configuration database. When Message Queuing sends messages from the RMS cluster servers to the logging database, it passes the credentials of the RMS service account to the database. Because RMS does not use SQL Server Authentication, it should be turned off and SQL Server should be configured to only allow Windows authentication requests.

  • Encrypt communication between RMS clusters and databases. To prevent malicious users from capturing or modifying logged data, increase the security of the RMS databases by configuring either SSL or Internet Protocol Security (IPsec) to provide encrypted channels. For more information about how to use SSL to increase the security of the communication with SQL Server 2000, see https://go.microsoft.com/fwlink/?LinkID=17060. For more information about how to use IPsec to increase the security of the communication between two servers, see https://go.microsoft.com/fwlink/?LinkID=17061.

  • Use LDAP signing to increase the security of network communications. Communications between RMS and the Active Directory global catalog should be signed. Signing Lightweight Directory Access Protocol (LDAP) traffic guarantees that the packaged data comes from a known source and has not been tampered with. Windows Server 2003 enables LDAP signing and encrypting by default. In Windows 2000 Server with Service Pack 3 (SP3) or later, LDAP signing is also supported.

For more technical information about RMS, go to Windows Server 2003 Rights Management Services.

If you have any feedback on how this tip could be improved or questions about RMS in general, go to the RMS Newsgroup.