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