(This blog post was originally published under the personal blog of Enrique Saggese at http://blogs.technet.com/b/information_protection and has been archived here at his request.)
While I will be discussing high-level design aspects in most of my posts, let me start with something somewhat different: how AD RMS works. It should be obvious that doing an adequate design for an AD RMS solution will be much easier if you understand what’s going behind scenes, so I will be dedicating the rest of this article to provide some background about AD RMS infrastructure components, and in my next post we will exploring AD RMS certificates and licenses and how it all works together.
AD RMS infrastructure
AD RMS, like any IT service, relies on some infrastructure to work. In the case of AD RMS there are several components that work together in order for the solution to deliver a useful service. The most relevant ones are:
· AD RMS servers and clusters
· The AD RMS SQL Server database
· Active Directory
· The Rights Management Services client and RMS-enabled applications in the client
· AD RMS-integrated server applications
While there are other components that work along with AD RMS to make the whole thing work, those should cover the most important ones needed to understand other topics in this blog.
AD RMS Servers and Clusters
AD RMS provides its services to other elements as a web-service, and it is thus hosted inside Internet Information Services in a Windows Server. It normally runs over HTTPs (though running it over HTTP is also possible) providing a few web service operations that can be consumed by clients and services to perform information protection and consumption tasks.
AD RMS actually not only uses IIS in the hosting server, but it also uses Message Queuing to interact with the AD RMS database which we will be discussing later. That ensures that operations in the AD RMS services that need to send data to the database can be performed asynchronously and that in turn increases performance and resiliency of the database services.
Multiple AD RMS servers are typically joined together forming AD RMS clusters, which are basically collections of identically-configured AD RMS servers connected to the same AD RMS database and working together to resolve requests from other clients and servers. In an AD RMS cluster it doesn’t matter which server resolves a request, so the requests are typically load balanced through a mechanisms such as Network Load Balancing in Windows or an external load balancer.
AD RMS Database
As stated, a group of identical AD RMS servers form an AD RMS cluster. Servers in a cluster don’t host persistent service-related data in their own disks. All configurations, logs, persistent status and operation data and caches are actually hosted externally to the AD RMS servers in a SQL Server database called the AD RMS Database. That way, all servers share a common configuration and if a server fails users can continue to work through other servers in the cluster.
There’s actually not a single AD RMS database but three. Those three databases are typically hosted in the same server and are:
· The AD RMS Configuration Database, which hosts all the configurations defining the behavior of the cluster such as its URLs and caching behavior, as well as copies of some certificates and other items needed to keep the service running. It typically also holds the core certificates and keys for the AD RMS servers themselves.
· The AD RMS Caching database, which is used to cache frequently used data about the users and groups defined in Active Directory, in order to avoid impacting the performance of AD every time the service needs anything from the directory.
· The AD RMS Logging Database, in which AD RMS puts information about transactions that have been performed by the service. This information is not used by AD RMS for anything other than for reporting.
AD RMS uses Active Directory to authenticate users of the system within the forest where it is installed. It also uses AD to obtain information about the email address of the users, which is used as the users’ identifier thorough the system, and to obtain information about group membership when the rights assigned to a document refer to a group instead of an individual user.
As stated above, AD RMS caches data from AD in the AD RMS AD Caching database in order to avoid hitting the domain controllers too hard.
AD RMS typically works together with client-side components to perform the encryption, decryption and policy enforcement tasks.
The main client-side components in an AD RMS system are the Rights Management Services client and AD RMS-enabled applications.
The Rights Management Services client, which comes installed as part of Windows Vista SP1 and later and in Windows 7, and that can be installed in earlier versions of Windows, deals with all the key management, communicates with the AD RMS services in requesting licenses and providing certificates and communicates with the client applications to perform the encryption and decryption of content. It also provides a secure environment for all these tasks to occur, helping prevent tampering and potential key disclosures.
AD RMS enabled server-side applications
While most AD RMS-related operations are performed between the clients and the AD RMS servers, having some level of integration between certain server-side services and AD RMS can provide for a better user experience and more efficient IT services. For example, Exchange Server 2010 can acquire licenses for content on behalf of the users so users don’t have to wait for a license to be acquired when they open email they have in their inbox. It also provides the ability to create and consume protected content in the browser when using OWA, along with other capabilities.
In my next post I will describe how certificates and licenses form part of the AD RMS process and how all these components work together in detail.