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 ¹ 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

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

---

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
  • See more:[Top Issue].
  • See more: Hello4Business and Hybrid Certs
• 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 headers¹

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!