Q. What is required to use federation with an Azure AD instance?
A. There are two methods of authentication for Azure AD:
- Native authentication in Azure AD using its username and passwords (which could be populated in Azure or synchronized via a hash of the password hash from on-premises AD via Azure AD Connect)
- Authentication to AD on-premises via federation
The later approach requires federation to be established between your on-premises AD instance and your Azure AD instance. Note that while I say on-premises AD instance it does not have to be hosted on-premises. It could also be hosted in Azure IaaS for example. To enable the federation you require the following:
- A server deployed with ADFS role installed and the initial configuration performed that will link it to your on-premises AD instance. The name of the ADFS server should be the public DNS name, e.g. sts.savilltech.com rather than an internal name like savdaladfs01.savilltech.net
- A server deployed with Web Application Proxy role installed (part of Remote Access in Windows Server 2012 R2) that has had the initial configuration performed that links it to the ADFS server that automatically makes it an ADFS Proxy, that is Internet facing, has an Internet routable IP address, an internal network IP address and has port 443 open. It should have the certificate matching the public name of the ADFS service installed. Note there is no configuration to specify which IP address is internal and which is external, WAP simply listens on all and automatically handles communications between networks.
- On the public internet have DNS entry for the public name, e.g. sts.savilltech.com that points to the public IP of the Web Application Proxy installation.
- If you use the same DNS zone internally and externally (split-brain DNS) then add an entry for the ADFS, e.g. sts.savilltech.com that points to the ADFS server internal IP address (and not the public WAP IP address). If you do not use split-brain DNS then create a zone for the full name, e.g. sts.savilltech.com (not a zone called savilltech.com, but the entire name) that points to the ADFS server internal IP address. More on why this is done in FAQ Q. I need to create a DNS record internally for an external zone but don't want to clash the entire DNS zone. What can I do?
- Make sure Azure AD Connect is already running to synchronize accounts
- Have an account in the Azure AD tenant that is a global admin but whose UPN is not part of the custom domain name for the Azure AD instance, e.g. savilltech.net but instead has the onmicrosoft.com domain name
- Execute PowerShell to enable the federation on a machine with the Azure AD PowerShell module installed
Microsoft has details on the conversion at https://msdn.microsoft.com/en-us/library/azure/jj205461.aspx and https://msdn.microsoft.com/en-us/library/dn194092.aspx. Below is an example conversion with comments to explain each step of the process.
#Save credential for an Azure AD account in the tenant that is using the @xxxx.onmicrosoft.com and is a global administrator $cred=Get-Credential #Connect to Azure AD as the credential Connect-MsolService –Credential $cred #Create a connection to the ADFS server. You will be prompted for a credential with administrative privileges on the ADFS server Set-MsolAdfscontext -Computer savdaladfs01 #This next step should not be required but can fix problems if the federation conversion will not work #Set-MsolPasswordPolicy -ValidityPeriod 90 -NotificationDays 14 -DomainName 'savilltech.net' #Switch to federation for authentication Convert-MsolDomainToFederated –DomainName 'savilltech.net'
And done! When authenticating it will now leverage federation to on-premises AD. Note when accessing services you can add the home realm to avoid having to perform home realm discovery via typing in an address, for example https://manage.windowsazure.com/savilltech.net instead of https://manage.windowsazure.com. Note that even if federation is having problems you will still be able to login with accounts that utilize the xxxx.onmicrosoft.com DNS UPN.