Inspecting an AD RMS Request from SharePoint 2010

In this series of posts on SharePoint with RMS, I’ve mostly focused on the ways things might go wrong if Active Directory data, User Profiles and User Information Lists are misaligned. Now, assuming SharePoint has a reliable Work E-mail value for a user, there are still a number of things that happen between the initiation of a request for RMS-protected content and interaction with it. In this post I will inspect a successful request for RMS-protected content from SharePoint 2010.

Posts in this Series

SharePoint 2010 On-Premises with AD RMS:

Part 1 – Protecting SharePoint 2010 with Information Rights Management
Part 2 – How SharePoint 2010 Finds and Updates a User’s Work E-mail Address
Part 3 – How SharePoint 2010 Authentication Provider Types Alter the Initial Population of Work E-mail Values
Part 4 – Inspecting an AD RMS Request from SharePoint 2010
Part 5 – RMS Publishing Permissions for SharePoint 2010 Application Pool Identities
Part 6 – RMS AD Caching for SharePoint 2010 Users
Part 7 – RMS Use Licenses, Offline Access and Rights Revocation with SharePoint 2010
Part 8 – SharePoint 2010 with AD RMS Process Diagram and Summary

Planned posts, covering newer versions and new twists:

SharePoint 2010 with Windows Server 2012 AD RMS
SharePoint 2013 with AD RMS
SharePoint On-Premises with AADRM
SharePoint Online with AD RMS
SharePoint Online with AADRM
SharePoint with RMS Trusts including ADFS
Search, Rehydrated Users and RMS

A Successful Request

Once everything is configured correctly and working within SharePoint (more to come in my next post), the normal process looks a bit like this (glossing over some of the lower-level RMS details):

A user requests RMS-Protected content. Depending on browser trust settings, an initial dialogue will look like one of these options (which is just normal browser stuff):
SharePoint challenges the user for authentication in the Office client associated with the requested file type. Again, this is just normal opening-authenticated-documents stuff. In this example I’m looking at a Classic NTLM-authenticated Web Application, but the process is as you would expect at this stage for any request for SharePoint content from a client application.

A Fiddler capture of the initial challenge (401) and response (200)

Note: the process is winword, thus the new challenge/response. This may or may not be visible to a user, depending on browser trust settings, client software, etc.
Next, behind the scenes (outside of this client/server interaction), the requested SharePoint Web Application’s Application Pool’s Identity publishes the content to the requesting user’s e-mail address (as defined in the User Information List). This interaction creates the RMS Publishing License certificate and encrypts the content. Remember, SharePoint does not encrypt this data at rest, or else Search would be unable to decrypt it.SharePoint finds the location of AD RMS from the IRM configuration in Central Administration. This information is often pulled from the RMS Service Connection Point (SCP) in Active Directory, as specified during RMS installation.
Once encryption completes, we’re back in the user’s session where the document is opened read-only or for editing in the associated Office client application, as initially requested. The user is still communicating with SharePoint using their Office client at this time. The decryption process doesn’t begin until after the Office client has successfully completed the download (see the large Result in result #23 below).
Once the document has been downloaded, the user is challenged for authentication by RMS, presenting a self-explanatory message to the user beforehand:

The RMS location information for this new request is pulled from inside the document, where it was written as part of the publishing process in step 3 above. The authentication prompt from the AD RMS servers is normally an Integrated Windows Authentication challenge, although RMS also supports federation with ADFS (which is beyond the scope of these already huge posts). Before moving to step 6 we assume the user has provided valid credentials that RMS accepts.
After RMS has authenticated the user, it will check its AD Cache (a SQL Server database these days, formerly in the registry) to see if the authenticated user has any previously-cached mail or proxyAddresses values from earlier logins, and whether these cached values have expired.

AD Cache data in the AD RMS DRMS_DirectoryServices database

RMS issues this query using the SID of the user that just logged on to RMS, returning whatever mail or proxyAddressess attribute data the cache might hold for that user. If the SID isn’t found in the cache database, the process skips to step 8 below.

Note: for SharePoint people, this approach of peeking inside an RMS database probably feels very wrong, but the RMS team seem to be more comfortable with this sort of thing in some cases, like when it comes to cache configuration.
If RMS hasn’t previously cached information for the user, or if the values are expired, RMS will issue a Global Catalogue LDAP query based on the credentials that have just been provided. Assuming this LDAP query finds mail or proxyAddresses values for the user, they will be stored in the AD RMS AD Cache for as long as the cache lifetime specifies. At this point RMS will have issued a Rights Account Certificate (RAC) for this user, which is bound to the Use license that RMS issues for the requested content in the next step.

An RMS Global Catalogue Query and Response

And the response

Whew! That’s a lot of steps. One thing that may not be clear is that the integration between SharePoint and RMS is rather loose. There is no second hop from SharePoint to RMS a la Kerberos. Instead, RMS acts as a sort of encrypting/decrypting filter between a user and SharePoint. The user can only work with an RMS-protected document if they have a valid certificate (a Use License) from RMS that allows those actions. If a user doesn’t have that certificate then the document will initiate a request to RMS so the user can acquire it. When RMS challenges a user for credentials, they can provide any credentials they like (assuming browser trust settings don’t automatically provide the logged on session’s credentials), but this user must have a mail or proxyAddresses value in Active Directory that matches SharePoint’s User Information List Work E-mail entry. The point of spelling this out is that there are two distinct client/server interactions. Nothing ensures continuity between them, although in practice the only way that this will work is if the requesting user has the “right” e-mail address in Active Directory, or if that address has been moved to the proxyAddresses attribute following a change. Also, in practice it will probably be practical to establish browser trust with the SharePoint Web Applications, AD RMS and AD FS (if it’s in play). Although these would still all be distinct client/server interactions, the browser would provide some continuity and improved usability (bypassing a number of prompts, which otherwise get pretty ugly).

Now that it’s open, what have I got?

It might be of interest to look at the resultant RMS permissions on the protected document once it’s open. Only the publishing user (the SharePoint Web Application’s Application Pool’s Identity) and the requesting user have any rights. The source document still lives in SharePoint and all the original SharePoint permissions persist there for everyone else. If “edit” permissions were granted for the document, a member can write changes back to the source SharePoint content within the lifetime of the RMS permissions. Once that lifetime expires the user needs to re-authenticate with RMS in order to acquire a new Use License. Put another way, the user is allowed to work with a document locally for a specified duration. Changes still get written back to SharePoint, but any given user’s offline copy is only usable by that user (and the Application Pool Identity that published it) for as long as we allow. I’ve included some screenshots of these RMS permissions here, revealing how they change across the most common default Permission Groups.

The Permissions dialogue for a Viewer in a successfully downloaded RMS-protected document

The Permissions dialogue for a Member in a successfully downloaded RMS-protected document

The Permissions dialogue for an Owner in a successfully downloaded RMS-protected document

“More Options” (for Owners) reveals that only the SharePoint Web Application’s Application Pool Identity (the publisher) and the requester/owner (Mike Ray) have access

Taking a step back, this all makes a great deal of sense. Documents are less likely to be exported (Saved As) to an offline, unencrypted copy, as only Owners have this right, so users continue to work within SharePoint rather than with unprotected copies. A different approach would probably result in a clunky disconnect between SharePoint and RMS. In many ways, the SharePoint approach to Rights Management is less of an anomaly than the File Server/Exchange models, as the information lifecycle is preserved inside SharePoint.

In the next post in this series I will look at some initial configuration requirements that are often overlooked.

Posts in this Series

A Successful Request

Now that it’s open, what have I got?

Related

Leave a Reply Cancel reply