Don’t try this at home (Or configuring AD FS against Azure AD Domain Services)


Fair warning: While I have disclaimer in the bottom of the page, and blog title basically emphasizes it… Do not try this in production unless you’re in very comfortable terms with Azure AD and Active Directory in general.


Azure AD Domain Services is Azure Managed version of Active Directory – Basically in exchange for your domain admin credentials, you get two managed endpoints to direct your resources at.

When to use it?

Example: You don’t want to extend your on premises network to Azure, but you still want to offer LDAP & Kerberos to your services deployed in the cloud.

More at FAQ

And more


The curious case of AD FS and AAD DS 

Every now and then I’ve wondered whether its possible provide these endpoints to VM running Active Directory Federation Services -> Based on my tests it is possible with some limitations

Good to know before proceeding

  • There exists no officially supported scenario of deploying AD FS, where you won’t need Domain Admin credentials to install AD FS as a member server to the target forest. 
  • Options 1 & 2 require Domain Admin
    • Option 1:
      • You can let the wizard create the objects given you’re armed with domain admin privileges
    • Option 2
      • Or ask for domain admin to pre-create the required objects, and then install AD FS with -AdminConfig switch, where you detail the pre-configured container for AD FS 

    • Option 3
      • By combining the two following guides, you can get AD FS working on AAD DS:
        • Guide 1: ”Create an Organizational Unit (OU) on an Azure AD Domain Services managed domain”
        • Guide 2:  Starting with AD FS in Windows Server 2016, you can run the cmdlet Install-AdfsFarm as a local administrator on your federation server, provided your Domain Administrator has prepared Active Directory

From Guide 1

  • Create an OU, where you create the container for DKM


$initialPath = ”CN=fscon,OU=NotInLocalDomain,DC=azure4d,DC=onmicrosoft,DC=com”

From Guide 2

  • Modify the original script to accumulate the new OU ($InitialPath) – Or alternatively bind new parameters to pass the $InitialPath

# The OU Name is a randomly generated Guid
[string]$guid = [Guid]::NewGuid()
write-host ("OU Name" + $guid)

$ouName = $guid
$initialPath = "CN=fscon,OU=NotInLocalDomain,DC=azure4d,DC=onmicrosoft,DC=com"

Install AD FS

  • Create certificates before the install.
    • If you don’t create certs before the install, the install will fail (in theory it should use the same path for CERTS, but in my tests it didn’t. I might try again at some point, if there is valid case for such install, but for now I am satisfied with creating the certificates before hand)
    • In this case I used the public cert for all three certificates.

$adminConfig = .\NewOU.ps1 -AcctToAclDkmContainer "AZURE4D\fsacc"

Install-AdfsFarm -FederationServiceName $fsname `
-CertificateThumbprint $thubmprint -FederationServiceDisplayName $fsname -ServiceAccountCredential $svcaccount -OverwriteConfiguration -Credential $credentials -AdminConfiguration $adminConfig -SigningCertificateThumbprint $thubmprint -DecryptionCertificateThumbprint $thubmprint


Install AD FS Farm with modified script



Any service where AD FS has to write data into synced object, such as RegisteredDevices OU, or similar functionality won’t be in the scope of this installation. In this form AD FS is only able to authenticate, and authorize accounts.

See it in action

  • Synced on-prem user logging into Azure VM, and using integrated auth to login into Claims Xray (


Br, Joosua!


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!