RMS Use Licenses, Offline Access and Rights Revocation with SharePoint 2010

After a brief diversion, I’m returning to my series on SharePoint with RMS. This post finishes off the baseline considerations, although there’s a lot more to say. But at last, in this post, we’ve reached the point where we know that RMS thinks I’m cool – so now what? Or if you prefer, I’m taking a look at the RMS Use License that is typically embedded in Microsoft Office documents, or in other cases might be associated with a client’s machine.

The Use License that RMS issues acts like an offline enforcer of allowed rights. The rights granted by RMS and the duration they persist define what a user can do with their offline copy of RMS-protected content and how long they can continue to take those actions before they need to re-visit SharePoint and the RMS infrastructure in order to claim fresh rights. Since rights persistence is defined by the owner(s) of a SharePoint list, the impact of those settings should be well understood by any users that have this control.This post focuses on what a user can do offline once RMS has done its job, and the user’s experience once those rights expire, bringing the tension between valid offline access versus timely rights revocation to the fore.

You will notice I’m talking about offline access a lot here. When I say “offline” in reference to RMS-protected content, I mean the documents that have already been encrypted by RMS and decrypted/opened by a user. I say the files are offline because the original unencrypted content still resides in the SharePoint content database. Any edits that RMS allows a user to make to the offline content need to be saved back to SharePoint if they will persist over time.

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 – Reverse Proxy Considerations for AD RMS and SharePoint
• Part 9 – SharePoint 2010 with AD RMS Process Diagram and Summary

Planned posts, covering newer versions and new twists:

• Changes to IRM in SharePoint 2013 and RMS in Windows Server 2012
• SharePoint Online with AD RMS or AADRM
• SharePoint On-Premises with AADRM
• AD RMS Trust, Federation and AADRM

Cache expiration versus Use License expiration

The cache expiration configuration options described in my last post should not be confused with rights expiration. The RMS AD Cache is a server-level optimisation. The cache’s expiration settings control how long a user’s LDAP attribute values should persist within the RMS infrastructure. Alternately, a SharePoint list’s IRM expiration settings determine the validity period of a user’s Use License.

In an example I’ve been looking at here, the RMS AD Cache values lasted for twelve hours while the Use License lasts for one day:

Once a Use License expires, any attempts to invoke rights will be denied by the Office application. For example, attempting to save an opened document after permission expires results in the following error:

The client application (Word in this case) will enforce rights expiration whether the user has access to RMS or not. This is truly an offline protection. In order to refresh this license, the user must re-authenticate (and be re-authorised) by SharePoint and RMS in order to carry out the requested action. In other words, any rights changes (such as revoked authorisation, IRM changes in the document library, or a disabled account) would be enforced as soon as the user comes back online to refresh the license.

However, it’s worth clarifying that reading is not a right. Open, offline documents do not close or become obfuscated once a Use License expires. If an RMS-protected document is open offline, it can remain open as long as the user keeps it open. But as soon as a user attempts to invoke any rights after the Use License has expired (for instance, by saving or printing a document), that action will be prevented as described above, until fresh rights have been acquired with a renewed Use License.

Managing license expiration without Protection Policies

It’s also important to understand that the IRM implementation in SharePoint does not use RMS Protection Policies. This is just how it works and how it has been. I mention this here because if you’re trying to wrap your head around how RMS rights can be revoked, you’ll probably refer to the RMS documentation for Windows Server 2008+, which spells out how revocation is controlled in the Protection Policy, which can even be configured to always require a connection to RMS:

“AD RMS License revocation is not supported in Windows Server 2008 or Windows Server 2008 R2.  Instead, the document lifecycle should be set in the protection policy*.  If there is a high probability of a need to remove access to a particular document, we recommend that the customer set the validity time to “0” in the template, or select “Require a connection to verify a user’s permission” in Office.  Note that these options will require a connection to the RMS Server when opening content, which will impact offline consumption scenarios.”

This has a few implications, but most importantly, this good guidance for Protection Policies is not how we control revocation in SharePoint. If we misinterpret this policy guidance to mean that document library expiration settings should be set to zero days, we would achieve precisely the opposite of what we intend.

[Setting expiration to zero days]… “has the effect of disabling the need to verify credentials, making licenses valid indefinitely (or for as long as the user’s RAC and the content are valid). It does not set the duration of the licenses to 0 days.”*

(* My bold in both of the two quotes above.)

The upshot of all this is that we need to carefully configure expiration in SharePoint lists with rights revocation in mind. On the low end, we can force users to verify their credentials every day (since zero days turns off verification). On the high end we might set expiration at sixty days or more. With a low value, users must have access to RMS if they want to retain rights within their offline copy of the SharePoint content. This impacts valid offline access (your CEO on a visit to a mine in the middle of Australia) and invalid offline access (when rights have been removed within SharePoint or an account has been disabled). Simply put, valid or invalid rights (that have already been granted) will persist offline in the Use License for the duration of the expiration policy. Put another way, invalidation will not take effect until the already-granted rights in the Use License expire. Clearly, setting this value to “1” tilts the balance in favour of protecting against data leakage. Setting the value to “sixty” shifts towards usability for roaming users.

To clarify further, a lot of risks can be mitigated by disallowing Save As or Export. In this scenario, a user can take allowed actions within opened documents for the duration of the Use License, but they must have opened that document before rights have been revoked in order to present risk. Data can only be leaked if the open content allows it, or through other means (taking a photo of the screen, etc). In any case, the risks of data leakage are equivalent to the likelihood that any user will have RMS content open before rights are revoked, and those risks decrease further by disallowing Save As (a/k/a Export) and/or by granting rights for a shorter duration. An information owner or administrator needs to define IRM settings with these risks, mitigations and offline access requirements in mind.

Rights revocation, the RMS AD Cache and Use Licenses

Now let’s put this together with the RMS AD Cache information from the last post. When thinking about how to protect against invalid usage, the RMS AD Cache is not a significant factor, as it will only come in to play when a user is prompted for authentication after a Use License (EUL) has expired. The user still needs to be authenticated and authorised to access content in SharePoint before the user authenticates with RMS – at which point the cache comes in to play. To this end, we can safely assume that the RMS AD Cache is a performance improvement for online users. Offline users already have their rights, or those rights will have expired.

Once rights expire and a user attempts to invoke them within offline content, the user will be redirected to SharePoint and then RMS to refresh the Use License. The user can’t remain offline if they want to refresh the expired rights. Since this request to renew rights would also need to pass through SharePoint and RMS authentication before the RMS AD Cache is used to define and issue an RMS Use License, we don’t need to think about taking special steps to invalidate the cache for revoked users. They either already have rights (and we need to wait for them to expire) and/or we need to revoke access by:

• Removing the user’s authorisation in SharePoint: change list permissions or inherited permissions.
• Preventing authentication: disable the AD user account.
• Removing the user’s authorisation in Active Directory:
  • Remove the user from the AD group that has access in SharePoint, or…
  • Change an attribute for a user, so they can no longer claim to have that attribute (when SharePoint content is secured by an attribute-based Claim, as in many SAML Claims deployments).

In short, this is all normal. The RMS AD Cache does nothing special. Likewise, there are no special mechanisms for invalidating offline rights that have already been granted because the Use License (EUL) will be embedded in the document or stored on the client’s machine. We can comfortably assume we won’t have access to this user’s machine or device. If we do, then presumably there aren’t any data leakage risks. Other technologies may add to these options, but I’m really only concerned with out-of-the-box functionality here.

Rights revocation in SharePoint with RMS Use Licenses

Since SharePoint’s IRM implementation basically respects SharePoint’s normal access controls, it’s worth briefly reviewing how they work. It’s likely that SharePoint token lifetime and permission revocation processes will come under the microscope if an organisation is considering supplementary protections like RMS. SharePoint 2010’s Security Token Service has a number of controls in Set-SPSecurityTokenServiceConfig that define token lifetimes, which vary by Authentication Provider Type. My colleague Sol wrote about them recently, specifically focusing on the Windows token lifetimes. These controls are the successor to stsadm.exe -o setproperty -propertyname token-timeout -propertyvalue <xxx> found in earlier versions. By default, the STSADM token-timeout value was set to 24 hours. In SharePoint 2010, WindowsTokenLifetime defaults to 23 hours (1380 minutes). There are related controls for FBA. SAML Claims token lifetimes default to the lifetime of the Relying Party Trust with the Identity Providing STS (IP-STS).

Additionally, the MaxLogonTokenCacheItems parameter sets an upper limit to the number of tokens that the STS will cache (note: this changes in SharePoint 2013). There are a number of other STS cache settings that can have an impact on the behaviour of the STS, as best explained by Josh Gavant. Forgive me for citing an article about SharePoint 2013 when I’m talking about SharePoint 2010 – it’s just that Josh explains this far better than anyone else. If this is unfamiliar, I’d work backwards to 2010 from this article. For instance:

MaxLogonTokenOptimisticCacheItems defines how many tokens are kept in the local Weak Reference cache, and MaxLogonTokenCacheItems specifies how many of these are stored as strong references instead of only weak references (details on weak references are available here). LogonTokenCacheExpirationWindow specifies how close to expiration tokens are considered to already be expired. So by default, tokens are considered expired 10 minutes prior to actual expiration time. Finally, WindowsTokenLifetime is used to set the Time-To-Live in the distributed logon token cache for cached security tokens of all types (not just Windows-bootstrapped tokens).

Clearly, this goes way beyond the scope of my RMS articles, but I wanted to identify the effects these settings can have when revoking access to RMS-protected content. If we set Use License expiration to 1 day (the lowest) and if we accept the default WindowsTokenLifetime in SharePoint 2010, then a user will need to re-authenticate with SharePoint in order to claim a new Use License, save one exception: the periods may not align. Consider this example:

• A user logs on from home at 8:00, gets challenged to authenticate and is granted access to SharePoint. The SharePoint STS will cache this user’s credentials for 23 hours by default. 
• This user successfully requests RMS-protected content from SharePoint at 16:00, granting a 24 hour Use License.
• The user’s account is disabled at 16:30.
• The user prints or exports the document at noon the following day.

In this scenario, the user’s SharePoint-cached token has expired but the RMS Use License is still valid, so the rights allowed by it can still be invoked up until the point when they expire. I won’t go in to all the possible scenarios with STS-cached tokens and revocation, as there are too many permutations to consider. What if there’s a reverse proxy involved as well? How do those token lifetimes influence these outcomes? However, I think this illustrates the type of things that should be thought about when defining these settings. The bottom line is that specific revocation scenarios should be tested. I would recommend tweaking these settings in either direction to get a better sense of the final outcomes.

Rights revocation in SharePoint when Active Directory Group membership changes

When a list is secured with Active Directory groups, rights will typically be revoked either by disabling the Active Directory user or by removing that user from an Active Directory Group (for instance, when moving between departments). In this scenario we don’t make any authorisation changes in SharePoint or RMS, so how are rights revoked? In short, this will occur in SharePoint 2010 as it does without RMS in the mix. RMS Group expansion is irrelevant to this concern since SharePoint 2010 publishes to the user rather than the group (although, as mentioned above, there are some changes in 2013 that I will revisit in a later post). Additionally, offline access is no different than as described above, since rights are granted to the user. So again, if content is secured with Active Directory groups, revocation will work normally. A user’s group membership changes won’t be reflected until that user is challenged to authenticate again, so these concerns all roll back up into the token cache considerations I mention above.

Offline Caching with SharePoint Workspace or SkyDrive Pro

Lastly, it’s worth mentioning that RMS is not supported in SharePoint Workspace or SkyDrive Pro. This all makes sense, since SharePoint content is encrypted on-demand for a specific duration. This simply isn’t how these tools work today.

Use Licenses and revocation in a nutshell

All told, this boils down to two things which are often the core SharePoint information security considerations without RMS in the picture.

1. Make sure Site Collection Owners understand this problem space and why it matters. Provide clear guidance on how lists should be configured.
2. Plan and design for authentication and caching with rights revocation in mind.

RMS doesn’t change a thing here, but it may underline the importance of these concerns.