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.

---

Background

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

From Guide 2

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

# THIS IS NOT THE FULL SCRIPT- original @ https://docs.microsoft.com/fi-fi/windows-server/identity/ad-fs/deployment/Install-AD-FS-Delegated-Admin

# 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

 

Limitations

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 (adfshelp.com)

 

Br, Joosua!