For those who haven't worked with AD FS before, federations offer a standardized service that allows the secure sharing of identity information between trusted business partners (known as a federation) across an extranet. When a user needs to access a web application from one of its federation partners, the user's own organization is responsible for authenticating the user and providing identity information in the form of claims to the partner that hosts the web application. The hosting partner uses its trust policy to map incoming claims to claims that are understood by its web application, which uses these claims to make authorization decisions. So basically, Azure AD and Microsoft become your business partner in AD FS.
From a planning perspective, the following prerequisites must be in place:
- An Azure subscription or an Azure trial subscription; this is only required for accessing the Azure Portal and not for using Azure AD Connect. If you are using Azure PowerShell or Office 365, you do not need an Azure subscription to use Azure AD Connect.
- An Azure AD global administrator account for the Azure AD tenant you wish to integrate with.
- An AD Domain Controller (DC) or member server with Windows Server 2008 or newer (see the following table for the appropriate sizing for that machine).
The DC or member server you will be using as the Azure AD Connect machine in your environment must meet the following minimum specifications:
|
Number of objects in AD |
CPU |
Memory |
Hard drive size |
|
Fewer than 10,000 |
1.6 GHz |
4 GB |
70 GB |
|
10,000 to 50,000 |
1.6 GHz |
4 GB |
70 GB |
|
50,000 to 100,000 |
1.6 GHz |
16 GB |
100 GB |
| For 100,000 or more objects, the full version of SQL Server is required; otherwise, a Windows internal database or SQL Express can be used | |||
|
100,000 to 300,000 |
1.6 GHz |
32 GB |
300 GB |
|
300,000 to 600,000 |
1.6 GHz |
32 GB |
450 GB |
|
More than 600,000 |
1.6 GHz |
32 GB |
500 GB |
First, before you start the installation of AD Connect, you need to configure two user accounts. The first one should be a service account with enterprise administrator rights, or for sub-domains with domain administrator rights within your on-premises AD DS. The other one must be a global administrator in Azure AD.
The following screenshot shows the User settings you need for the Azure AD synch administrator:
These two accounts will perform actions on both directories. So, the on-premises user won't have access to Azure AD, and the Azure AD admin won't have access to the on-premises AD:
The following diagram shows you the basic workflow behind communication between Azure AD, AD Connect, and on-premises AD DS:
After you choose which type of user sign-on you want to use for your Azure AD users implementation, the wizard changes and adds or removes configuration options. For the AD FS implementation, you need to perform some more steps to get the federation running. For the AD FS implementation, you will need at least one AD FS Server and one AD FS Proxy additionally, as well as additional service accounts. The connection will work automatically, based on Windows Remote Management (WinRM). As explained earlier, the Azure AD will authenticate against your on-premises AD FS implementation.
The following diagram reflects the more complex environment:
