Protecting SharePoint 2010 with Information Rights Management

Overview

In recent weeks Information Rights Management (IRM) protections for SharePoint 2013 have received a fair amount of attention, as IRM is now configurable per-tenant, which brings the capabilities to SharePoint Online, supported by Windows Azure Active Directory Rights Management (AADRM). This is great, and I’ll have more to say about these new technologies, but I feel there’s a fair amount of missing public information about the way it’s been working on-premises for many years, which will prove to be foundational for the new stuff. I won’t go back in time to MOSS 2007 to describe that support, but I believe the Classic Windows Authentication scenarios that I will describe for SharePoint 2010 are largely the same as in the earlier implementation.

This first post focuses on the relationships of a few apparently-distinct topics and the effects that these considerations have for a user accessing Rights Managed content in SharePoint 2010. Namely:

1. How SharePoint publishes content with Rights Management protections using the User Information List’s Work E-mail value.
2. How that field gets initially loaded…
   1. If an entry is added to the User Information List when a user is granted access to a SharePoint Site Collection by name.
   2. If an entry is added to the User Information List when a user accesses a Site Collection for the first time, having been granted access by group or attribute previously.
   3. How each of these events vary if the user is authenticated with a SAML Claim, and how Claim Mappings for a SAML Claim Provider’s Trust Relationship can alter this experience.
3. How the User Information List’s Work E-mail value can change after the User Profile to SharePoint Quick or Full Synchronisation Timer Jobs have run.
   1. How the scope of users targeted by this timer job works by default.
   2. How the scope of users targeted by this timer job can be modified and the possible effects of choosing to make this change.
4. How Active Directory Rights Management Server (AD RMS, or just RMS below) discovers and caches e-mail address values for a user.
5. How changes to an Active Directory user’s mail attribute can have an impact on access to RMS-protected content in SharePoint.

As is no doubt evident already, this is complicated stuff, but in my view, quite necessary to understand if using RMS with SharePoint. These considerations become more important if e-mail addresses are fluid, or at scale, and especially critical if authenticating SharePoint with SAML Claims while using RMS. I’ve produced a process diagram to explain these variations in a single view, but first I will provide background details.

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

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

SharePoint 2010 IRM Implementation

What

IRM protections introduce secondary access controls on top of SharePoint’s own authentication and authorisation methods. RMS enforces a wide range of rights beyond what SharePoint presents in a list’s settings, but this isn’t the feature degradation it may appear to be at face value, since SharePoint continues to respect the normal authorisation controls that we define for SharePoint Groups like Visitors and Members. For instance, edit rights are not granted to Readers. However, the following Rights and Conditions are assigned as a Document Library-level policy, to all documents in a library:

• Rights:
  • Print (allowed/disallowed).
  • Access Content Programmatically (enables/disables embedded code and macros in documents). If enabled, we effectively leave the back door open to IRM circumvention by allowing extraction of content through code/macros. If disabled, we can’t protect these documents with Rights Management full-stop. This boils down to a choice between some defeatable mitigations vs. none.
• Conditions:
  • Expiration (users must verify their credentials every xx days).
  • End Date (optional – declares when the policy will no longer apply to the library).

A Document Library’s IRM Settings

These document library settings also allow administrators to prevent users from uploading documents that don’t support IRM, which (unintuitively) includes files that were previously encrypted with Rights Management. More on that below.

Why

We typically become interested in IRM if we want to restrict these rights to a limited set of users, or perhaps we might be inclined to share some information more freely if we feel that we’ve got more control over its access. These secondary controls mitigate risks of data leakage and introduce a validity period to document access rights. For instance, if a user has previously downloaded copies of RMS-protected content, and that user has now been marched out of the building, they will be unable to invoke any of their rights to re-open that content if the expiration period was set to a low value. To be clear, disabling that user’s account in Active Directory would prevent them from successfully authenticating for new requests, but these RMS expiration controls prevent access to already-downloaded, offline content. The rights themselves are no longer valid; the conditions for access have not been met. As always with security, there’s a potential usability trade-off, but typically where Rights Management is enabled, we’re more concerned with safeguarding information than with providing full-fidelity access on every device, where those trade-offs obtain.

How/When

Next, we need to be clear that this second tier of access control has a second authentication challenge and response. There is a separate client/server interaction between the Office Client and the AD RMS infrastructure. This secondary interaction acquires the certificate (Use License) a user needs to decrypt the content and take the actions allowed by the Publisher (the Web Application Pool’s identity). Put another way, the user requests a key which unlocks the rights that RMS manages.

We don’t begin to talk about RMS until after a user has been successfully authenticated by SharePoint and that user has been authorised to access the requested information. Once those normal conditions have been met, SharePoint attempts to publish the requested information with RMS encryption/restrictions, as configured at the document library where the content lives. This assumes that SharePoint “knows” that user’s e-mail address. Finally, the user will be challenged to authenticate by RMS. If successful, and if RMS can find a matching e-mail address for the user, the actions allowed by RMS are unlocked for the validity period defined in the document library settings. If the user cannot successfully authenticate with RMS or if the Active Directory data for the user doesn’t match the information SharePoint has, the user will not be able to decrypt the requested content.

Who

In the RMS world, we’re assigning rights with Active Directory Users and Groups (it is Active Directory Rights Management Server after all). In the SharePoint world, we’re publishing requested content to a user’s Work E-mail Address value (as defined at the requested resource). This is User Information List data – not the user’s e-mail address field from the User Profile Service Application nor from an LDAP query (although these are two ways the User Information List’s entry may have been populated or updated). A user’s directory data, User Profile data and User Information List data are often kept in sync with timer jobs, and typically should be for RMS.

Things become slightly more interesting when you consider that there are some not-necessarily-Active-Directory-based ways to secure SharePoint, such as FBA and SAML Claims, and in those cases the Work E-mail Address value may not originate from an LDAP query, but from an E-mail Claim. As I mentioned above, these are two separate client/server interactions, so this apparent disconnection does not mean that this is necessarily bad – but it definitely starts to get a bit complicated. There’s much more detail about that in the posts that follow.

FYI

That’s the scene, but first there are a few things to be aware of:

• IRM Protections for SAML Claims users were only introduced with the June 2011 CU for SharePoint 2010.
• Even though users authenticate to RMS separately, they do not log on with their e-mail address necessarily. If RMS is Windows-Authenticated then the user will logon with their User logon name (UPN or pre-Windows 2000) as usual.
• There is one massive red herring disguised by SharePoint’s IRM Settings. By default, users can apply Rights Management protections to SharePoint content whether or not SharePoint has been configured for IRM. In this case, a user publishes the content with RMS directly (from within the document) and then uploads it to SharePoint. This RMS-encrypted content is then stored with those encryptions in the content database, which means that the crawl account won’t be able to decrypt the content for inclusion in Search results. That’s problematic! You can prevent users from uploading these documents to a Rights Managed document library by selecting the Do not allow users to upload documents that do not support IRM setting. I would typically recommend using this setting for a consistent experience.

With this overview laid out, in my next posts I’ll get in to the muck of how it works.