AD RMS Infrastructure Concepts
Note: I have recently changed roles to become part of the Information Protection Team at Microsoft (the group responsible for building AD RMS and related technologies) where I will be acting as a Sr. Program Manager. Since the team already has a blog on AD RMS I have decided to concentrate my efforts in that blog, which you can find at http://blogs.technet.com/rms. My previous blog posts have already been moved there and in the future you should go to that blog for updates and news (quite a few of them are coming!).
You can find this particular post at http://blogs.technet.com/b/rms/archive/2012/04/16/ad-rms-infrastructure-concepts-part-1.aspx.
Hello and welcome to my blog!
This blog will be used to present AD RMS architecture concepts, as well as other relevant topics I might decide arbitrarily to discuss.
As you will learn from reading my blog I am quite passionate about AD RMS and all things Information Protection in the Enterprise. I have been working with this technology for several years now and I think it should be part of the security, compliance and risk management strategy of any enterprise dealing with sensitive information.
As I mentioned above, I will be dealing mostly with architectural aspects of designing and deploying Information Protection in the enterprise, and not as much on other aspects of the technology, such as how to make it work in different scenarios. For that you have some excellent content in Jason Tyler’s blog and the blog from the AD RMS product group at Microsoft.
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.
Active Directory
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.
Client-side components
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.
Comments
Anonymous
January 01, 2003
Great to see a blog on RMS. Do you have somthing on highly available and geographically dispersed implementations? =)Anonymous
January 01, 2003
The comment has been removedAnonymous
January 01, 2003
For those of you still looking at my old blog, I encourage you to go to the new blog at http://blogs.technet.com/rms, and especially that you watch the video we just published at channel9.msdn.com/.../Enabling-RMS-Everywhere-032013 where we explain the product's roadmap and all the new cool stuff we are building for RMS.Anonymous
July 04, 2011
Great Job, thanks a lot for the info.... i´ll ve waiting next post...Anonymous
April 01, 2013
thanks for information