Many people think of AD FS as merely a federated authentication service. And with a name like Active Directory Federation Services, it’s easy to see why. However, it also has the capacity to make authorisation decisions within its Claims Engine. This may be most familiar as the Office 365 Client Access Policies, but those policies are basically just a flavour of AD FS Issuance Authorisation Rules. An AD FS Issuance Authorisation rule provides a gate at AD FS, where permissions can be granted or denied to authentic users, per-Relying Party, before giving the user Claims for the requested Relying Party. In most cases we will think about these rules as coarse controls, to block a wide category of requests, such as those originating from outside the network, for members of a group, or for any combination of request-based, device-based and user attribute-based Claims. We can even create authorisation rules based on the user’s Identity Provider, or from additional factors of authentication. We will typically still implement most of our authorisation logic within the Relying Parties we are authenticating to, but in some cases it’s very useful to control access at this intermediary tier – especially if a large class of users, devices or networks should be treated as higher risk.
These concepts are not new, and the TechNet documentation I reference here dates back to the earliest wave of AD FS 2.0 RTW content:
Ultimately, I think these articles do answer the question of how to create an AD FS Issuance Authorisation rule, but I can’t point very clearly to the place on these pages that spells it out, and I do think there is a lot of confusing information about this in other places which may lead people astray. Namely, there is a lot of information that only concerns itself with the default Active Directory Claims Provider Rules and the Claims that come from request headers. Also, some of the most referenced AD FS + SharePoint content seems to have been written without authorisation rules in-mind. I want to try to clear some of that up in this post.
I’ve added a fairly significant update regarding the new MFA stage in the pipeline half-way down this post.
Continue reading “The Rules of AD FS Claims Rules”
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”
Continuing this series about the SharePoint 2010 IRM implementation, in this post I’ll keep looking at the Work E-mail Address attribute in the User Information List, but focus specifically on how the initial value in that field gets populated from different sources for different Authentication Provider Types. As with the fuller picture considered in the last post, this is a lot more complicated than anyone would expect at a glance, but it’s really the lynchpin of this functionality – thus the depth here.
Continue reading “How SharePoint 2010 Authentication Provider Types Alter the Initial Population of Work E-mail Address Values”