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.