Cheat sheet: AD FS and Azure AD Hybrid Conditional Access

What is so great about AD FS 2016 + Azure AD Hybrid Device Join?

  • You get absolutely the best SSO experience with it – In fact it’s preferred over any 1 of the existing methods in terms of the use experience when used with W10 (Standard licensing)ADFSss
  • It works as seamless second factor for Azure AD Applications with Azure AD Conditional Access (AAD P1)
  • You can use it as seamless factor for your on-premises federations by requiring the presence of trusted claims in the request. In the absence of these trusted claims you can fall-back into standard 2-Factor Auth (AAD P1)
  • Hybrid Device Registration with AD FS is not dependent on AAD Connect to enable SSO on the device (AAD P1)
    • AAD connect Synchronization links the device to corresponding Azure Device, once the on-prem device satisfies required filter conditions in metaverse


  1. Please note, that Azure AD join is not something that replaces initial Sign-on modes, it still requires that initial sign-in has taken place before the device is paired with Azure AD to obtain SSO experience based on the PRT tokens

Major tips to get it right

Do I need any on-premises pointing device registration records to accomplish the scenario presented?

  • Absolutely none – In fact, if you look at the Device Registration Logs, you will find out that it explicitly states that local endpoints will NOT be enabled


DRS is in Hybrid AAD mode, registration endpoints will NOT be enabled.

Do I need to enable Device Authentication in the Authentication policies for Intra/extranet? 

No – The device authentication claims in this scenario are emitted as part of Windows, or Forms authentication. This happens with the AD DS Device Object and its properties in conjunction with Primary Refresh Token, which is accounted for in the Windows Login process,

  • While you need to have Device Registration enabled, you don’t need to enable device authentication as method in the authentication policies.



  • If you look at the claims with forms authentication and Extranet login, you will see the Device Claims that were emitted as part of the FormsAuthentication



Take note of the PRT claim – You wont find it in the RP’s login trace pipeline, because it’s formed at Windows Login

If you want to peek under the hood, and understand how these DRS claims end up in the same pipeline, then check DRS trace logs

Here DRS is checking for device match


”GetDeviceKeyFromKeyCredLink” &  GetDevice(ID,DC): 




Is it multi-factor authentication method?

Not in the context of AD FS, but conceptually it’s Multifactor Auth (one factor more added to the on-going authentication sequence)

Is there single important action that help will me in achieving the goal?

  • Yes, start with the newest version of the AAD Connect. It now supports both AAD HDJ and Writeback configuration during the setup without manual scripts AAD Connect 1.1.819.0
    • (DISCLAIMER: Do always review the changes made to AAD connect, and estimate if there is any change existing Relying Party trusts or sync related settings before proceeding)

What should I confirm before debugging anything else?

Coarse flow description

Example policy using Device-Based Conditional Access

1. Requiring presence of ’known device’ when accessing on-prem federations

  • This policy will ensure, that unknown devices will have to perform standard multi-factor authentication, whereas known devices will be granted access based on the presence of the ’isknown’ claim with value=True


Do I need Web Application Proxy

In my experience not, if you have capable reverse proxy, and opt for the Azure AD joined Domain devices. For Example KEMP VLM that can impersonate WAP for most of the features, and forward IP and Proxy information to AD FS via the use of headers1

This would have been different with the non hybrid device registration which requires that SSL is terminated at the WAP's directly

Extra stuff:

  1. One very welcome addition is, that the shared W10 and Server 2016 Devices don’t reserve this feature to only single user. Thus you get for example in remote desktop installation the Azure AD join SSO for multiple users.


Br, Joosua!


Azure AD Federation with KEMP

My earlier blog post ’The yellow box’ was about using AD FS as IDP and KEMP as SAML Service Provider. In that particular Blog I covered how KEMP was doing Pre-authentication, and then KCD to the back-end – It was quite comprehensive scenario, and didn’t feel I need to cover more ground on KEMP’s SAML capabilities until now.


Original order

Original scheme with AD FS

Azure AD as Direct IDP

Previously I was also using Azure AD for B2B identities, but with AD FS acting as sort of IDP proxy. This time I wanted switch the order, so that Azure AD is directly IDP for KEMP.

The challenge was especially more interesting, because according my short investigation it felt that this hasn’t been covered before – this was also the case in KEMP’s official documentation.

”Microsoft Active Directory Federation Services (AD FS) is the SAML-based Identity Provider (IdP) which has been tested and which is referred to in this document. However, other IdPs may also work.” 

new order

Updated scheme without AD FS


Bit of background before going through the configuration (or miniblog inside another blog…)

Q: Why not just use the Azure AD App Proxy?

A: Yes, that’s good question, I’ve covered using Azure AD App Proxy in another blog ’Azure AD’s best kept secret’ for similar scenario, and to be honest, I couldn’t say straight off the bat what to decide on this?

I would see that in larger enterprise both could be used for different scenarios:

The most fundamental principles are following:

AAD App Proxy: Its much easier to get going with AAD App Proxy due to its relatively easy and straightforward configuration. In some cases it requires about zero changes to networking. And it’s ”born in the cloud” or in another words, it sits in Azure AD, where you have API’s, users, and permissions out of the box

KEMP : Kemp can do both ”old” and ”new” stuff, meaning, that it does some classic reverse proxy tricks which can’t be found in AAD App Proxy (at the moment). It also does management of other products, and can use on-demand VPN tunnels to facilitate need for more back-end resources (That’s the new stuff anyway…)

If you would go ”Full-Azure” then you would need to publish some solutions with Azure Application Gateway, which is more of an classic reverse proxy. You would still need a third Azure solution (Azure Load balancer) if you need UDP protocol to be load balanced as well

So basically KEMP can do most of the stuff that the three separate Azure Products do, but you would need more components from Azure, if you would like to cover same kind of portfolio of features that KEMP covers.

I think this represents pretty good example of the hybrid landscape, where you have a lot of overlapping solutions, but might need to decide your approach on not just technical factors. In the end (and acknowledging the overlapping features) I don’t see these solutions as pitted against each other completely, but more like synergy creating mesh in the evolving market.


  • Configuration requires Azure AD Premium P1 subscription to create application with SAML integration.
    • I am keen to see, if KEMP would be interested to become first ADC vendor (that I know), to implement Azure AD authentication with the OpenID Connect Protocol
  • VLM-Free (Something that is great about KEMP, is that their free offering has pretty much all important features, its just limited in bandwidth)


I did an light co-op with my colleague @tomikoski to ensure that SAML Assertion Attributes can’t be altered in MITM -type scenario

  • We tested changing signature and usernames with BURP.
    • Changing either one, or both resulted in KEMP correctly informing about failed verification, and not thus authorizing access to the back-end resource
  • Successful verification displays rc[0] status with message ’Signature is OK’



  • Failed verification displays rc[-1] status



  • Altered attributes in BURP

Kuvaesitys vaatii JavaScriptin.

  • Displayname modification in the payload was also tested with bit of humor included- It was safe to say, that this resulted in the attacker  @tomikoski  not gaining access to the back-end resource.

Ugly Payload

Say hello to my little friend


  • SAML Assertion Signature verification from IDP side (Azure AD) – This is referred as SAML signing certificate on Azure AD


Azure AD Side

  • SAML Assertion Signature verification from SP side (KEMP) – This is referred as IDP signing certificate on Azure AD



Settings configuration



KEMP SubVS configuration


KEMP SSO configuration


AAD Configuration



See it in action:



And muchos Gracias for Tomi Koskis BURP knowHow!

Going beyond specification

A little while ago I wrote about impersonating Web Application Proxy to AD FS with KEMP’s simple header modification.

Since writing the blog in LinkedIn, I’ve received some queries whether this works when you wan’t to process advanced AD FS claim rules, for example based on the forwarded client IP?

While documentation available don’t state it’s possible, you can actually do it, by going bit beyond the normal specification with header injections.

Behind the scenes

AD FS host is expecting ’X-MS-Forwarded-Client-IP’ header from KEMP. If this header is not present in the request, and ’X-MS-PROXY’ is it will just assume client is from extranet – In this scenario you can’t use any advanced claim rules in AD FS, that would use the Public forwarded from client.

As you all might know, its pretty standard stuff to include the ’X-Forwarded-For’ header to requests terminated in the edge, then re-encrypted to back-end. Well… 🙂 we are going to use the same logic here, just apply it in a bit different way.

The trick

  1. Ask KEMP to add ’X-Forwarded-For (+ Via)’ in ’Add HTTP Headers’
  2. Ask KEMP to Copy ’X-Forwarded-For (+ Via)’ to header ’X-MS-Forwarded-Client-IP’

The result

Now forwarded Client IP’s are part of the requests, and can be applied in advanced claim rules.

In the example, I’ve set AD FS to bypass MFA for Partner IP, if Partner user terminates from certain Public IP . This all works now courtesy of header modification provided by KEMP

Hope this helps somebody substituting WAP with KEMP

Br, Joosua