Azure AD Connect is Microsoft's free Hybrid Identity bridge product to synchronize objects and their attributes from on-premises Active Directory Domain Services (AD DS) environments and LDAP v3-compatible directories to Azure Active Directory.
One of the neat tricks Azure AD Connect has up its sleeve is the ability to implement Active Directory Federation Services (AD FS) as part of the configuration wizard.
AD FS Management through Azure AD Connect
An admin can implement the first AD FS server, implement the first Web Application Proxy server and federate a custom domain name from Azure AD during the initial configuration of Azure AD Connect. Alternatively, an existing AD FS farm can be pointed to.
On subsequent runs, an admin can:
- View the configuration of the AD FS farm, including the Federation service name, service account, primary server (when using WID), the AD FS farm behavioral level (FBL) and information on the SSL certificate and token signing certificate
- Federate additional Azure AD custom domain names
- Manage the Azure AD trust
- Update the SSL certificate
- Update the token-signing and token-decrypting certificates
- Add AD FS servers
- Add Web Application Proxy servers
- Specify the AD FS primary server (when using WID)
- Verify federated login
The AD FS management possibilities in Azure AD Connect makes the life of an admin easier in organizations with AD FS.
There are some requirements to managing AD FS with Azure AD Connect. Many of these requirements are documented as the Prerequisites for Azure AD Connect. It mentions specifically that the Azure AD Connect must be domain-joined, but this is not the case for most deployment scenarios.
However, it is when you want to manage AD FS through Azure AD Connect.
When you select the Federation with AD FS as sign-in option on the User sign-in page of the Azure AD Connect configuration wizard, the Next button remains greyed out and the following message appears:
You must be logged in as a domain user to configure federation with AD FS.
You may also experience this message when you’re signed in to a domain-joined Windows Server running Azure AD Connect with a local user account.
Why would you not domain-join Azure AD Connect?
One of the questions you might ask yourself is why you wouldn’t domain-join the Windows Server running Azure AD Connect. There can be several reasons:
- The way Azure AD Connect sets up outbound connections to Azure AD can be considered as a back-end system setting up connections to the Internet. From a regulatory perspective, this might permit the Windows Server running Azure AD Connect in a perimeter network only. From that network, domain-join may not be available or permitted.
- When synchronizing an LDAPv3-compatible directory service to Azure AD, instead of Active Directory, you may not want or be permitted to join the Windows Server running Azure AD Connect to the same Active Directory domain as the AD FS farm.
The alternative way
Of course, you can domain-join the Windows Server running Azure AD Connect, but you can also continue with Azure AD Connect without the Windows Server being domain-joined.
If the Windows Server running Azure AD Connect is not domain-joined, you’ll have to select the Do not configure sign-in option on the User sign-in page of the Azure AD Connect configuration wizard.
Run through the remaining part of the Azure AD Connect configuration wizard.
Then, create the ‘Microsoft Office 365 Identity Platform’ Relying Party Trust manually and use the claim rules from ADFSHelp for your ‘Office 365 Identity Platform’ Relying Party Trust to provide the same functionality as you would get on a domain-joined Azure AD Connect installation.
You will not be able to enjoy the management of AD FS through Azure AD Connect, this way, but you will have AD FS as sign-in method.
Keep in mind that you will experience a heavier management burden to implement renewed certificates, add additional Azure AD custom domain names and verify federated sign-ins.