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. Continue reading “RMS Use Licenses, Offline Access and Rights Revocation with SharePoint 2010”
As this series of posts about SharePoint 2010 with Rights Management moves on, it moves further from SharePoint. In this post I’m describing the final steps in the RMS protection process, where RMS authenticates the requesting user and authorises actions with RMS-protected content.
In most configurations, RMS will rely on its internal AD Cache to reduce the number of LDAP queries for user attributes or Active Directory group membership. RMS typically queries this cache when users request a license. If RMS finds a matching e-mail address for a user, the allowed rights will be granted in a Use License, which will persist inside a document or on a user’s machine until the rights expire. LDAP queries are only issued if cached values don’t exist or if they have expired. After an LDAP query is issued, the response is used to process the immediate request and the values are stored in the AD Cache for later use.
Although this caching process should “just work” initially, there are a number of tiers where user information can fall out of sync. First and foremost, does the signed-on user have an e-mail address in Active Directory that matches the SharePoint User Information List? What happens if this e-mail address changes, or if it didn’t match initially? How can we invalidate stale AD Cache values? How long does the AD Cache persist? What’s in it? What needs to be considered when turning it off? In many cases the default AD Cache values will be suitable, but operational processes should be orchestrated with AD Cache settings in mind, whatever they may be. Cache invalidation processes should also be understood before they need to be invoked. I will explore these considerations in more detail here.
Continue reading “RMS AD Caching for SharePoint 2010 Users”
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.
Continue reading “Inspecting an AD RMS Request from SharePoint 2010”