Keeping AD FS Integrated Windows Authentication (IWA/WIA) Clients Signed In

Over the last couple of years we’ve started doing less AD FS work, with the advent of Password Hash Sync for Azure AD sign-on, and Microsoft’s continued investment in Azure AD Premium. We’ve also seen a few organisations struggle to operate AD FS successfully, even if I personally like the technology. So I’ve changed our approach to unveil all of this with as much realism as possible, and to draw some feature comparisons in both directions. We also spend a lot of time talking about expectations of SSO, and how the ways we think about SSO on the web aren’t quite as automatic as what we get with Windows hashes and tickets.

So… what this means is that we don’t do as much AD FS work anymore, and when Microsoft released a hotfix for AD FS in the August 2014 update rollup, it didn’t catch my eye. This hotfix and the related configuration that needs to be added to the AD FS trust with Azure AD are documented in the newer Configure Persistent Single Sign-On article, and I first picked up on this configuration in the Azure MFA article for AD FS. At any rate, this configuration specifies two new Issuance Transformation Claims Rules for the AD FS Relying Party Trust with Azure AD (AKA “Microsoft Office 365 Identity Platform”):

@RuleTemplate = "PassThroughClaims"
@RuleName = "Pass through claim - InsideCorporateNetwork"
c:[Type == "http://schemas.microsoft.com/ws/2012/01/insidecorporatenetwork"]
=> issue(claim = c);
A custom Issuance Transform rule to pass through the persistent SSO claim
@RuleName = "Pass Through Claim - Psso"
c:[Type == "http://schemas.microsoft.com/2014/03/psso"]
=> issue(claim = c);

This configuration assumes that you are achieving KMSI somehow at AD FS, either through the “Persistent SSO” or “Keep Me Signed In” (KMSI) capabilities. For the purposes of this post I am focused on the latter, and this implementation is spelled out in more detail in the Microsoft documentation I’ve linked to above. To sum this all up, once you add these two Claims Rules and enable KMSI at AD FS, you can pass through KMSI to Azure AD, which in turn will keep you signed in to SharePoint Online, Outlook Web App, etc. I won’t bloat this post by drifting in to a wider discussion of how this behaviour will change for every client/server interaction, but I will say that if you want your AD FS users to be able to experience KMSI in the same way that Password Hash Sync or Cloud-Only users benefit from it, then you should seriously look at this option. The reason why this is necessary is that federated users won’t always be able to tick the KMSI box at Azure AD, either because redirection happens too quickly, or in other cases they may not even see that login page.

If I’m spelling this out a bit slowly so far, stick with me, because I don’t think most people understand how this configuration works. First, it’s important to note that users must be inside the corporate network and select KMSI in order to benefit from KMSI passing through. I’m not sure this is explicitly spelled out anywhere, although you can reasonably infer it when you test it out. What this means is that you can still select KMSI when signing on at the WAP, but it won’t pass through to Azure AD. This is going to be desirable for most organisations. Second, I think there’s a fair amount of confusion about how this passes through when you do configure things this way. I think a lot of people may not realise that this gets you the same experience as ticking KMSI at Azure AD, and that’s the really beneficial change to the user experience.

However… what is really unclear everywhere, and what I had not really appreciated until some recent work, is that Integrated Windows Authentication clients (like Internet Explorer) won’t benefit from KMSI, because they will never see the KMSI tick box. Now, you could argue that Integrated Windows Authentication clients don’t need KMSI, since those clients are signed on seamlessly, but this overlooks the fact that Azure AD will still challenge the user to select their username, and this interrupts SSO. While it’s true that there are other approaches to bypassing that username challenge such as Smart Links, IdP-Initiated Sign-On and Sign-On Acceleration for SharePoint Online, there will still be Service-Provider initiated flows that fail to benefit from these provisions. And while these users could select KMSI at Azure AD (if they manage to tick the box before getting redirected), I wouldn’t want to wager that most will figure this out or understand how it’s supposed to work. With all of this in mind, I pondered how we can get KMSI for Integrated Windows Authentication Clients.

The solution I’ve come up with is pretty simple, and it may not be suitable for everyone, but I thought I should share it nevertheless. In short, we can transform the InsideCorporateNetwork Claim to PSSO. What does this mean? It means that all users signing on directly at AD FS will benefit from KMSI, even if they use an Integrated Windows Authentication Client that is never presented with the tick box. It’s certainly worth validating that this is suitable from a security point of view (devices roam, etc.), but remember that as soon as you enable KMSI for AD FS, you are accepting those risks anyway.

As it stands, I think this configuration could be fine-tuned, to create a more elegant combination of this rule with the PSSO rule that Microsoft specifies, but I also think it’s viable to simply add this Custom Issuance Transformation Rule to the other two that Microsoft specify:

c:[Type == "http://schemas.microsoft.com/ws/2012/01/insidecorporatenetwork"]
=> issue(Type = "http://schemas.microsoft.com/2014/03/psso", Issuer = c.Issuer, OriginalIssuer = c.OriginalIssuer, Value = c.Value, ValueType = c.ValueType);

If you have recommendations on how this can be improved, please share them in the Comments and I’ll update the post if I agree.

Ultimately, this rule will not change the Claims that we pass to Azure AD, but it will change the Claims Value if a specific condition is met. If you’re inside the corporate network, we opt you in to KMSI. Now, please keep in mind that I offer this approach for you to consider the risks and the option that it can open up. I also advise that you should test this, to make sure that you are really happy with how KMSI works. For instance, if your internal network itself is not locked down, this probably isn’t suitable. But with all this said, I am pleased with the improvements to the user experience that I have seen in my testing, and think that others may be able to benefit from this approach.

One final comment: for the purposes of this post I am focused on the changes to KMSI for clients that can consume it. Some of the Office client flows don’t use KMSI (relying on Credential Manager instead), so keep that in mind while evaluating all of this.