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)
- 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
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
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
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
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?
- Assuming the pre-requisites are satisfied (AAD Connect installation, with correct configuration) and you’re not seeing this thing work, then please ensure that ”msDS-KeyCredentialLink” is getting populated in the write-back flow
- Still no luck? Get intimate with Plan Device-based Conditional Access on-Premises
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
- List of Device Access Control Policies
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
- 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.