Significant Identity and Access Management Improvements in Windows Server 2012 R2

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.

Problems with the current Microsoft Stack

Before we dive in to the new capabilities, it’s worth reviewing the sorts of problems that are hard to solve today.

• Microsoft’s Reverse Proxy technologies are not well aligned:
  • Microsoft’s only Claims-Aware Reverse Proxies are UAG and the ADFS Proxy. The ADFS Proxy can only publish ADFS, while UAG does not support mobile device access when it publishes ADFS. This means you may need to use both the ADFS Proxy and UAG if you want to publish a Claims-Based Web Application that’s authenticated by ADFS.
  • TMG never supported SAML Claims.
  • The SharePoint Server 2013 Hybrid App Model requires TMG for inbound and two-way hybrid configurations. UAG is unsupported at this time.
    • If you need to introduce TMG to support this model today, appliances can still be found on the market, but for the other reasons above, it’s difficult to recommend this approach.
• Multiple-Factor Authentication (MFA) solutions typically require customisation or third-party products for your Reverse Proxy.
• Kerberos Claims were introduced to Windows Server 2012, and ADFS 2.1 could transition them to SAML Claims, but since scarcely anyone has a Windows Server 2012 domain, this hasn’t solved many problems yet. Additionally, it’s not clear how this is intended to work with current Reverse Proxy technologies.

With all of this in mind, it’s hopefully clear why my first interest was in the new Web Application Proxy role. Surely this must be the replacement for TMG that we’ve been waiting for! In truth, it’s not that simple, and UAG is not going away any time soon, but it does play a significant part in solving many of the problems that I’ve described above.

What is the Web Application Proxy?

When I started installing the preview, I poked around for pre-release content. As of earlier this week, there was one interesting document on TechNet, the Web Application Proxy Overview, which I would class as required reading. Here are some key points that are probably un-obvious:

• The Web Application Proxy is the successor to the ADFS Proxy. Once you grok the role it’s playing, this becomes clear, but I really didn’t expect this was the direction of travel.
• ADFS is required for the Web Application Proxy. All configuration data are held in the ADFS configuration database.
  • This doesn’t mean that all Web Applications need to be SAML Claims-authenticated!
    
  • This does mean that the Web Application Proxy automatically publishes ADFS.
  • One thing I should mention from my testing that isn’t documented yet: I had to provision a new Windows Server 2012 R2 ADFS farm. I could not connect the Web Application Proxy to an existing Windows Server 2008 R2 ADFS farm. I also experienced a few headaches with other options that I will document below.
• The Web Application Proxy Can publish ADFS Relying Parties or applications can be “proxied” using Pass-Through authentication (these are not pre-authenticated).
  • ADFS Relying Parties can now be “Non-Claims Aware”!
    • A Non-Claims Aware Replying Party seems to require Kerberos Constrained Delegation. The documentation and the GUI back this up.
      • For authentication to work for Kerberos Constrained Delegation, the Web Application Proxy will need to reside in the same forest as the authenticating user, which explains the Microsoft recommendation for a B2B firewall configuration.
        • In my opinion, it will probably be preferable to deploy the Web Application Proxy in a WORKGROUP if the Web Application Proxy is only publishing ADFS and SAML Claim-authenticated Web Applications.
• Generally speaking, the Web Application Proxy has many similarities to the ADFS Proxy, but ADFS itself has a number of enhancements, particularly as we start to move on to MFA and Device Authentication.

What’s new in ADFS

When we think about the Web Application Proxy, it’s really a window in to ADFS. But ADFS is no longer just a federation service. There appears to be a portal, possibly for password resets (disabled by default, and I haven’t got this working yet) and a number of new Claims Descriptions and Endpoints that are worth noting.

New Claims Descriptions

New Endpoints

Also, ADFS ships with a pre-configured Relying Party, the Device Registration Service (clearly supporting some of the Device Authentication scenarios).

The most dramatic change is the Authentication Policies container. This is all new.

The Primary Global Authentication Policy is pretty much as you would expect.

The Multi-Factor tab is where things will get interesting.

These settings are also configured per-Relying Party.

These few tick boxes may appear trivial, but these are scenarios that are particularly difficult to solve elegantly today. I’m not going to speak to the Device Authentication and Multi-Factor Authentication functionality in this post other than to call it out as a feature enhancement. The documentation that I’ve linked above refers to three Solution Guides, which I simply haven’t had time to process yet, but they will likely be of interest if you’ve made it this far.

• Solution Guide: Join to Workplace from Any Device for SSO and Seamless Second Factor Authentication Across Company Applications.
• Solution Guide: Manage Risk with Additional Multi-Factor Authentication for Sensitive Applications.
• Solution Guide: Manage Risk with Multi-factor Access Control.

Oh, and remember that Non-Claims Aware Relying Party I was talking about? It might be of interest to check out the final tab in that configuration:

That is literally as far as I’ve got right now, but I think it reveals what’s new in ADFS. All of that is now supported through the Web Application Proxy (from what I can tell). If you’re curious, I have ADFS-authenticated SharePoint 2010 published via the Web Application Proxy successfully right now. Based on that lab result, we have a new Claims-Aware Reverse Proxy option, which is a fantastic give-away in Windows absent all of these other improvements.

I still have much more to test, but this all feels promising so far. For now, I will conclude with those new farm tidbits, and hopefully put some more meat on these bones in the near future.

You need a new Windows Server 2012 R2 ADFS farm

As I mentioned above, I encountered a few headaches when trying to get my Web Application Proxy connected to ADFS. In the end I had to build a new farm on Windows Server 2012 R2. These are some things you shouldn’t bother trying.

• For probably the first time in about five years, I tried to run an in-place upgrade on my current Windows Server 2008 R2 ADFS Farm. This failed during installation per an unknown error. I suspect the error boils down to Windows Server 2012 R2 only having English language support for EN-US while my servers are built on EN-GB. The Preview release does not support cross-language upgrades.
• Following that failure, I tried to join a new Windows Server 2012 R2 VM to my existing Windows Server 2008 R2 farm. This also failed, but the error did not emerge until the final step of the configuration. This is pretty clear to me.