Windows Server 2012 R2 introduces a number deep changes to the way that AD FS works, which means that as practitioners, we need to look for solutions to problems in new, unexpected places. For instance, in the old world, if AD FS was completely unresponsive, the first place I would look after AD FS itself would be IIS. In AD FS 2012 R2, IIS doesn’t play a role. Requests are still served by the HTTP.SYS kernel driver but we interact with it using NETSH HTTP, which connects to the driver via the User Mode HTTP Server API. IIS and other familiar components would also interact with this API previously, but they provided a friendlier layer of abstraction between an administrator and the API. Interacting with HTTP.SYS using NETSH HTTP brings a learning curve with it, particularly when it comes to understanding what is and is not controlled here. Also, there is no GUI and the security that HTTP.SYS enforces is stricter than the abstracted layer that IIS has historically opened up. This web server architecture change and other new differences add to the difficulty of tracking down problems when things don’t work as expected, as detailed in this post.
Last week, Microsoft released Windows Server 2012 R2 Preview. Some information about new features like the Web Application Proxy role began to emerge from recent industry events, but there isn’t an awful lot to absorb at the moment. Having played around with the preview for a few days, I’m pleased to report that the new features look good. While there are always niggles and unsupported scenarios, the features themselves are bringing Microsoft’s Identity and Access Management (IAM) offerings nearer to parity with the industry leaders. These changes should be of particular interest for SharePoint on-premises and Office 365 customers, as a number of scenarios that were on the bleeding edge of ADFS/UAG capabilities have been brought into the fold with some important enhancements to ADFS, which isn’t just for federation anymore.
In short, we get a new Claims-Aware Reverse Proxy, Device Claims in and outside of the network, Multiple-Factor Authentication and other enhancements for making access control decisions on more than just a username and password. I’ve discussed all of these topics routinely over the last couple of years in SharePoint on-premises and Office 365 contexts, but the current provisions in ADFS and UAG are not as elegant as what we find in the preview, so I’m keenly exploring the new functionality and will try to keep the content flowing. In this post I will focus on the features themselves, as there’s a lot of new stuff and the implementation of this functionality will only be clear with a bit more information than what you’ll find online today. I’m kind of rushing this out after limited use because I know there’s a big appetite for knowledge about the Microsoft Reverse Proxy roadmap, so apologies for the incompleteness in advance.
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.
In the first part of this series about the SharePoint 2010 IRM implementation, I provided an overview of the technology and why we might use it to enhance SharePoint’s access controls. In this second article, I’ll look closely at the key piece of information that bridges the gap between SharePoint and a Rights Management Server – namely, a user’s e-mail address. RMS relies on a user’s e-mail address in this way outside of the SharePoint world as well; this is an RMS requirement. SharePoint’s implementation attempts to work with this, even though SharePoint doesn’t require a user to have an e-mail address for most things to work.
IRM support has been built in to SharePoint as a WSS (now Foundation) technology. WSS/Foundation don’t have a User Profile Service, so the e-mail address information that RMS requires needs to come from somewhere else. As we’ll see below, it wouldn’t be optimal to query Active Directory for that value whenever RMS-protected content is requested, so SharePoint uses the value it (hopefully) already has in the lowest common denominator (WSS/Foundation) user information container. As we’ll see, reliably populating and updating that information is less straight-forward than it would appear at a glance.
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:
- How SharePoint publishes content with Rights Management protections using the User Information List’s Work E-mail value.
How that field gets initially loaded…
- If an entry is added to the User Information List when a user is granted access to a SharePoint Site Collection by name.
- 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.
- 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.
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.
- How the scope of users targeted by this timer job works by default.
- How the scope of users targeted by this timer job can be modified and the possible effects of choosing to make this change.
- How Active Directory Rights Management Server (AD RMS, or just RMS below) discovers and caches e-mail address values for a user.
- 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.