Security Best Practices using RMS

  • Article

Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2

The following best practices provide guidelines that can help you effectively manage security for Rights Management Services (RMS). General security best practice information is available at the Microsoft Web site (https://go.microsoft.com/fwlink/?LinkId=49428).

  • 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. Ask your hardware vendor if they have a hardware-based CSP that has been tested for use 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. An Active Directory® group must be assigned as the RMS super users group.

  • 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 proxyaddress 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, an information security policy should be in place within your organization that prohibits the ability to recycle an e-mail address to another user.

    Note

    Alternatively, to avoid this problem, you can assign rights to groups rather than individual employees in your rights policy templates. If group membership is determined when a license is requested, the rights policy always reflects current group membership. You can also mitigate the problem of recycled e-mail addresses if you use RMS-enabled applications that publish to security identifiers (SIDs) rather than to e-mail addresses.

  • Enhance ACLs on the RMS pipelines. The access control lists (ACLs) on the pipelines in the RMS 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 those who log on through Windows Live™ ID, 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 re-establishing a separate connection internally.

  • Turn off SQL Server authentication mode 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. In SQL Server authentication mode, credentials are passed in plaintext in the connection string. Since RMS does not use SQL authentication mode, it should be turned off and the 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, secure the RMS databases by configuring either Secure Sockets Layer (SSL) or Internet Protocol Security (IPsec) to provide encrypted channels. For more information about how to use SSL to secure communication with SQL Server, see https://go.microsoft.com/fwlink/?LinkID=99948. For more information about how to use IPsec to provide secure communication between two servers, see https://go.microsoft.com/fwlink/?LinkID=99950.

  • Use LDAP Signing to Secure Network Communications. Communications between RMS and the Active Directory global catalog should be signed. Signing 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. LDAP signing is also supported in Windows 2000 Server with Service Pack 3 (SP3).

  • Monitor the size of the logging message queue. Use System Monitor to regularly monitor the size of the outbound logging message queue. If the queue size grows substantially, verify that the logging listener service is operating correctly. If a malicious user causes the logging listener service to stop, the outbound logging message queue will grow and eventually exceed the disk space of the RMS server. If this occurs, the server will deny requests. For more information about the logging listener service, see "RMS Logging Listener Service" in "RMS: Technical Reference" in this documentation collection.

  • Enable auditing on your database server. Auditing the activity on your database server provides additional security for your RMS installation because it keeps track of activity and changes that are made to your databases.

  • Monitor the network traffic to your RMS servers. RMS should be monitored and managed in your organization in the same manner as other Web-based services. RMS servers can be the target of denial-of-service attacks and should be managed appropriately.