Azure Application Gateway Adfs

AD FS provides simplified, secured identity federation and Web single sign-on (SSO) capabilities. Federation with Azure AD enables users to authenticate using on-premises credentials and access all resources in cloud. As a result, it becomes important to have a highly available AD FS infrastructure to ensure access to resources both on-premises and in the cloud. Azure Application Gateway enables you to build highly scalable and available web sites by providing HTTP load balancing and delivery control. Web Application Firewall Application Gateway provides you with all the benefits of a basic Application Gateway, as well as protection against malicious web requests.

-->

AD FS provides simplified, secured identity federation and Web single sign-on (SSO) capabilities. Federation with Azure AD or O365 enables users to authenticate using on-premises credentials and access all resources in cloud. As a result, it becomes important to have a highly available AD FS infrastructure to ensure access to resources both on-premises and in the cloud. Deploying AD FS in Azure can help achieve the high availability required with minimal efforts.There are several advantages of deploying AD FS in Azure, a few of them are listed below:

  • High Availability - With the power of Azure Availability Sets, you ensure a highly available infrastructure.
  • Easy to Scale – Need more performance? Easily migrate to more powerful machines by just a few clicks in Azure
  • Cross-Geo Redundancy – With Azure Geo Redundancy you can be assured that your infrastructure is highly available across the globe
  • Easy to Manage – With highly simplified management options in Azure portal, managing your infrastructure is very easy and hassle-free

Design principles

The diagram above shows the recommended basic topology to start deploying your AD FS infrastructure in Azure. The principles behind the various components of the topology are listed below:

  • DC / ADFS Servers: If you have fewer than 1,000 users you can simply install AD FS role on your domain controllers. If you do not want any performance impact on the domain controllers or if you have more than 1,000 users, then deploy AD FS on separate servers.
  • WAP Server – it is necessary to deploy Web Application Proxy servers, so that users can reach the AD FS when they are not on the company network also.
  • DMZ: The Web Application Proxy servers will be placed in the DMZ and ONLY TCP/443 access is allowed between the DMZ and the internal subnet.
  • Load Balancers: To ensure high availability of AD FS and Web Application Proxy servers, we recommend using an internal load balancer for AD FS servers and Azure Load Balancer for Web Application Proxy servers.
  • Availability Sets: To provide redundancy to your AD FS deployment, it is recommended that you group two or more virtual machines in an Availability Set for similar workloads. This configuration ensures that during either a planned or unplanned maintenance event, at least one virtual machine will be available
  • Storage Accounts: It is recommended to have two storage accounts. Having a single storage account can lead to creation of a single point of failure and can cause the deployment to become unavailable in an unlikely scenario where the storage account goes down. Two storage accounts will help associate one storage account for each fault line.
  • Network segregation: Web Application Proxy servers should be deployed in a separate DMZ network. You can divide one virtual network into two subnets and then deploy the Web Application Proxy server(s) in an isolated subnet. You can simply configure the network security group settings for each subnet and allow only required communication between the two subnets. More details are given per deployment scenario below

Steps to deploy AD FS in Azure

The steps mentioned in this section outline the guide to deploy the below depicted AD FS infrastructure in Azure.

1. Deploying the network

As outlined above, you can either create two subnets in a single virtual network or else create two completely different virtual networks (VNet). This article will focus on deploying a single virtual network and divide it into two subnets. This is currently an easier approach as two separate VNets would require a VNet to VNet gateway for communications.

1.1 Create virtual network

In the Azure portal, select virtual network and you can deploy the virtual network and one subnet immediately with just one click. INT subnet is also defined and is ready now for VMs to be added.The next step is to add another subnet to the network, i.e. the DMZ subnet. To create the DMZ subnet, simply

Cached

  • Select the newly created network
  • In the properties select subnet
  • In the subnet panel click on the add button
  • Provide the subnet name and address space information to create the subnet

1.2. Creating the network security groups

A Network security group (NSG) contains a list of Access Control List (ACL) rules that allow or deny network traffic to your VM instances in a Virtual Network. NSGs can be associated with either subnets or individual VM instances within that subnet. When an NSG is associated with a subnet, the ACL rules apply to all the VM instances in that subnet.For the purpose of this guidance, we will create two NSGs: one each for an internal network and a DMZ. They will be labeled NSG_INT and NSG_DMZ respectively.

After the NSG is created, there will be 0 inbound and 0 outbound rules. Once the roles on the respective servers are installed and functional, then the inbound and outbound rules can be made according to the desired level of security.

After the NSGs are created, associate NSG_INT with subnet INT and NSG_DMZ with subnet DMZ. An example screenshot is given below:

  • Click on Subnets to open the panel for subnets
  • Select the subnet to associate with the NSG

After configuration, the panel for Subnets should look like below:

1.3. Create Connection to on-premises

We will need a connection to on-premises in order to deploy the domain controller (DC) in azure. Azure offers various connectivity options to connect your on-premises infrastructure to your Azure infrastructure.

  • Point-to-site
  • Virtual Network Site-to-site
  • ExpressRoute

It is recommended to use ExpressRoute. ExpressRoute lets you create private connections between Azure datacenters and infrastructure that's on your premises or in a co-location environment. ExpressRoute connections do not go over the public Internet. They offer more reliability, faster speeds, lower latencies and higher security than typical connections over the Internet.While it is recommended to use ExpressRoute, you may choose any connection method best suited for your organization. To learn more about ExpressRoute and the various connectivity options using ExpressRoute, read ExpressRoute technical overview.

2. Create storage accounts

In order to maintain high availability and avoid dependence on a single storage account, you can create two storage accounts. Divide the machines in each availability set into two groups and then assign each group a separate storage account.

3. Create availability sets

For each role (DC/AD FS and WAP), create availability sets that will contain 2 machines each at the minimum. This will help achieve higher availability for each role.While creating the availability sets, it is essential to decide on the following:

  • Fault Domains: Virtual machines in the same fault domain share the same power source and physical network switch. A minimum of 2 fault domains are recommended. The default value is 3 and you can leave it as is for the purpose of this deployment
  • Update domains: Machines belonging to the same update domain are restarted together during an update. You want to have minimum of 2 update domains. The default value is 5 and you can leave it as is for the purpose of this deployment

Create the following availability sets

Availability SetRoleFault domainsUpdate domains
contosodcsetDC/ADFS35
contosowapsetWAP35

4. Deploy virtual machines

The next step is to deploy virtual machines that will host the different roles in your infrastructure. A minimum of two machines are recommended in each availability set. Create four virtual machines for the basic deployment.

MachineRoleSubnetAvailability setStorage accountIP Address
contosodc1DC/ADFSINTcontosodcsetcontososac1Static
contosodc2DC/ADFSINTcontosodcsetcontososac2Static
contosowap1WAPDMZcontosowapsetcontososac1Static
contosowap2WAPDMZcontosowapsetcontososac2Static

As you might have noticed, no NSG has been specified. This is because azure lets you use NSG at the subnet level. Then, you can control machine network traffic by using the individual NSG associated with either the subnet or else the NIC object. Read more on What is a Network Security Group (NSG).Static IP address is recommended if you are managing the DNS. You can use Azure DNS and instead in the DNS records for your domain, refer to the new machines by their Azure FQDNs.Your virtual machine pane should look like below after the deployment is completed:

5. Configuring the domain controller / AD FS servers

In order to authenticate any incoming request, AD FS will need to contact the domain controller. To save the costly trip from Azure to on-premises DC for authentication, it is recommended to deploy a replica of the domain controller in Azure. In order to attain high availability, it is recommended to create an availability set of at-least 2 domain controllers.

Domain controllerRoleStorage account
contosodc1Replicacontososac1
contosodc2Replicacontososac2
  • Promote the two servers as replica domain controllers with DNS
  • Configure the AD FS servers by installing the AD FS role using the server manager.

6. Deploying Internal Load Balancer (ILB)

6.1. Create the ILB

To deploy an ILB, select Load Balancers in the Azure portal and click on add (+).

Note

if you do not see Load Balancers in your menu, click Browse in the lower left of the portal and scroll until you see Load Balancers. Then click the yellow star to add it to your menu. Now select the new load balancer icon to open the panel to begin configuration of the load balancer.

  • Name: Give any suitable name to the load balancer
  • Scheme: Since this load balancer will be placed in front of the AD FS servers and is meant for internal network connections ONLY, select 'Internal'
  • Virtual Network: Choose the virtual network where you are deploying your AD FS
  • Subnet: Choose the internal subnet here
  • IP Address assignment: Static

After you click create and the ILB is deployed, you should see it in the list of load balancers:

Next step is to configure the backend pool and the backend probe.

6.2. Configure ILB backend pool

Select the newly created ILB in the Load Balancers panel. It will open the settings panel.

  1. Select backend pools from the settings panel
  2. In the add backend pool panel, click on add virtual machine
  3. You will be presented with a panel where you can choose availability set
  4. Choose the AD FS availability set

6.3. Configuring probe

In the ILB settings panel, select Health probes.

Azure Application Gateway Basic

  1. Click on add
  2. Provide details for probea. Name: Probe nameb. Protocol: HTTPc. Port: 80 (HTTP)d. Path: /adfs/probee. Interval: 5 (default value) – this is the interval at which ILB will probe the machines in the backend poolf. Unhealthy threshold limit: 2 (default value) – this is the threshold of consecutive probe failures after which ILB will declare a machine in the backend pool non-responsive and stop sending traffic to it.

We are using the /adfs/probe endpoint that was created explictly for health checks in an AD FS environment where a full HTTPS path check cannot happen. This is substantially better than a basic port 443 check, which does not accurately reflect the status of a modern AD FS deployment. More information on this can be found at https://blogs.technet.microsoft.com/applicationproxyblog/2014/10/17/hardware-load-balancer-health-checks-and-web-application-proxy-ad-fs-2012-r2/.

6.4. Create load balancing rules

In order to effectively balance the traffic, the ILB should be configured with load balancing rules. In order to create a load balancing rule,

  1. Select Load balancing rule from the settings panel of the ILB
  2. Click on Add in the Load balancing rule panel
  3. In the Add load balancing rule panela. Name: Provide a name for the ruleb. Protocol: Select TCPc. Port: 443d. Backend port: 443e. Backend pool: Select the pool you created for the AD FS cluster earlierf. Probe: Select the probe created for AD FS servers earlier

6.5. Update DNS with ILB

Using your internal DNS server, create an A record for the ILB. The A record should be for the federation service with the IP address pointing to the IP address of the ILB. For example, if the ILB IP address is 10.3.0.8 and the federation service installed is fs.contoso.com, then create an A record for fs.contoso.com pointing to 10.3.0.8.This will ensure that all data trasmitted to fs.contoso.com end up at the ILB and are appropriately routed.

Warning

If you are using the WID (Windows Internal Database) for your AD FS database, this value should instead be temporarily set to point to your primary AD FS server or the Web Application Proxy will fail enrollement. After you have successfully enrolled all Web Appplication Proxy servers, change this DNS entry to point to the load balancer.

Note

If your deployment is also using IPv6, be sure to create a corresponding AAAA record.

7. Configuring the Web Application Proxy server

7.1. Configuring the Web Application Proxy servers to reach AD FS servers

In order to ensure that Web Application Proxy servers are able to reach the AD FS servers behind the ILB, create a record in the %systemroot%system32driversetchosts for the ILB. Note that the distinguished name (DN) should be the federation service name, for example fs.contoso.com. And the IP entry should be that of the ILB's IP address (10.3.0.8 as in the example).

Warning

If you are using the WID (Windows Internal Database) for your AD FS database, this value should instead be temporarily set to point to your primary AD FS server, or the Web Application Proxy will fail enrollement. After you have successfully enrolled all Web Appplication Proxy servers, change this DNS entry to point to the load balancer.

7.2. Installing the Web Application Proxy role

After you ensure that Web Application Proxy servers are able to reach the AD FS servers behind ILB, you can next install the Web Application Proxy servers.Web Application Proxy servers need not be joined to the domain. Install the Web Application Proxy roles on the two Web Application Proxy servers by selecting the Remote Access role. The server manager will guide you to complete the WAP installation.For more information on how to deploy WAP, read Install and Configure the Web Application Proxy Server.

8. Deploying the Internet Facing (Public) Load Balancer

8.1. Create Internet Facing (Public) Load Balancer

In the Azure portal, select Load balancers and then click on Add. In the Create load balancer panel, enter the following information

  1. Name: Name for the load balancer
  2. Scheme: Public – this option tells Azure that this load balancer will need a public address.
  3. IP Address: Create a new IP address (dynamic)

After deployment, the load balancer will appear in the Load balancers list.

8.2. Assign a DNS label to the public IP

High availability cross-geographic AD FS deployment in Azure with Azure Traffic Manager

Click on the newly created load balancer entry in the Load balancers panel to bring up the panel for configuration. Follow below steps to configure the DNS label for the public IP:

  1. Click on the public IP address. This will open the panel for the public IP and its settings
  2. Click on Configuration
  3. Provide a DNS label. This will become the public DNS label that you can access from anywhere, for example contosofs.westus.cloudapp.azure.com. You can add an entry in the external DNS for the federation service (like fs.contoso.com) that resolves to the DNS label of the external load balancer (contosofs.westus.cloudapp.azure.com).

8.3. Configure backend pool for Internet Facing (Public) Load Balancer

Follow the same steps as in creating the internal load balancer, to configure the backend pool for Internet Facing (Public) Load Balancer as the availability set for the WAP servers. For example, contosowapset.

8.4. Configure probe

Follow the same steps as in configuring the internal load balancer to configure the probe for the backend pool of WAP servers.

8.5. Create load balancing rule(s)

Follow the same steps as in ILB to configure the load balancing rule for TCP 443.

9. Securing the network

9.1. Securing the internal subnet

Overall, you need the following rules to efficiently secure your internal subnet (in the order as listed below)

RuleDescriptionFlow
AllowHTTPSFromDMZAllow the HTTPS communication from DMZInbound
DenyInternetOutboundNo access to internetOutbound

9.2. Securing the DMZ subnet

RuleDescriptionFlow
AllowHTTPSFromInternetAllow HTTPS from internet to the DMZInbound
DenyInternetOutboundAnything except HTTPS to internet is blockedOutbound

Note

If client user certificate authentication (clientTLS authentication using X.509 user certificates) is required, then AD FS requires TCP port 49443 to be enabled for inbound access.

10. Test the AD FS sign-in

The easiest way is to test AD FS is by using the IdpInitiatedSignon.aspx page. In order to be able to do that, it is required to enable the IdpInitiatedSignOn on the AD FS properties. Follow the steps below to verify your AD FS setup

  1. Run the below cmdlet on the AD FS server, using PowerShell, to set it to enabled.Set-AdfsProperties -EnableIdPInitiatedSignonPage $true
  2. From any external machine, access https://adfs-server.contoso.com/adfs/ls/IdpInitiatedSignon.aspx.
  3. You should see the AD FS page like below:

On successful sign-in, it will provide you with a success message as shown below:

Template for deploying AD FS in Azure

The template deploys a 6 machine setup, 2 each for Domain Controllers, AD FS and WAP.

You can use an existing virtual network or create a new VNET while deploying this template. The various parameters available for customizing the deployment are listed below with the description of usage of the parameter in the deployment process.

ParameterDescription
LocationThe region to deploy the resources into, e.g. East US.
StorageAccountTypeThe type of the Storage Account created
VirtualNetworkUsageIndicates if a new virtual network will be created or use an existing one
VirtualNetworkNameThe name of the Virtual Network to Create, mandatory on both existing or new virtual network usage
VirtualNetworkResourceGroupNameSpecifies the name of the resource group where the existing virtual network resides. When using an existing virtual network, this becomes a mandatory parameter so the deployment can find the ID of the existing virtual network
VirtualNetworkAddressRangeThe address range of the new VNET, mandatory if creating a new virtual network
InternalSubnetNameThe name of the internal subnet, mandatory on both virtual network usage options (new or existing)
InternalSubnetAddressRangeThe address range of the internal subnet, which contains the Domain Controllers and ADFS servers, mandatory if creating a new virtual network.
DMZSubnetAddressRangeThe address range of the dmz subnet, which contains the Windows application proxy servers, mandatory if creating a new virtual network.
DMZSubnetNameThe name of the internal subnet, mandatory on both virtual network usage options (new or existing).
ADDC01NICIPAddressThe internal IP address of the first Domain Controller, this IP address will be statically assigned to the DC and must be a valid ip address within the Internal subnet
ADDC02NICIPAddressThe internal IP address of the second Domain Controller, this IP address will be statically assigned to the DC and must be a valid ip address within the Internal subnet
ADFS01NICIPAddressThe internal IP address of the first ADFS server, this IP address will be statically assigned to the ADFS server and must be a valid ip address within the Internal subnet
ADFS02NICIPAddressThe internal IP address of the second ADFS server, this IP address will be statically assigned to the ADFS server and must be a valid ip address within the Internal subnet
WAP01NICIPAddressThe internal IP address of the first WAP server, this IP address will be statically assigned to the WAP server and must be a valid ip address within the DMZ subnet
WAP02NICIPAddressThe internal IP address of the second WAP server, this IP address will be statically assigned to the WAP server and must be a valid ip address within the DMZ subnet
ADFSLoadBalancerPrivateIPAddressThe internal IP address of the ADFS load balancer, this IP address will be statically assigned to the load balancer and must be a valid ip address within the Internal subnet
ADDCVMNamePrefixVirtual Machine name prefix for Domain Controllers
ADFSVMNamePrefixVirtual Machine name prefix for ADFS servers
WAPVMNamePrefixVirtual Machine name prefix for WAP servers
ADDCVMSizeThe vm size of the Domain Controllers
ADFSVMSizeThe vm size of the ADFS servers
WAPVMSizeThe vm size of the WAP servers
AdminUserNameThe name of the local Administrator of the virtual machines
AdminPasswordThe password for the local Administrator account of the virtual machines

Additional resources

Next steps

AD FS provides simplified, secured identity federation and Web single sign-on (SSO) capabilities. Federation with Azure AD enables users to authenticate using on-premises credentials and access all resources in cloud. As a result, it becomes important to have a highly available AD FS infrastructure to ensure access to resources both on-premises and in the cloud.

Introducing Federation with Azure AD

Federation is a collection of domains that have established trust. The level of trust may vary, but typically includes authentication and almost always includes authorization.
We can federate your on-premises environment with Azure AD and use this federation for authentication and authorization. This sign-in method ensures that all user authentication occurs on-premises. This method allows administrators to implement more rigorous levels of access control.

Architectural Diagram

If we need highly available Federation, then we have to set up “password hash synchronization” option as a backup in case ADFS infrastructure fails.


ADFS configuration prerequisites

  • Windows Remote Management

If the target server is domain joined, then ensure that Windows Remote Managed is enabled
In an elevated PS command window, use command

Enable-PSRemoting –Force

  • SSL Certificate

It’s strongly recommended to use the same SSL certificate across all nodes of your AD FS farm and all Web Application proxy servers. The certificate must be an X509 certificate.
You can use a self-signed certificate on federation servers in a test lab environment. However, for a production environment, I recommend that you obtain the certificate from a public CA

The identity of the certificate must match the federation service name (for example, sts.contoso.com)

  • Name resolution for federation servers

Set up DNS records for the AD FS federation service name (for example sts.contoso.com) for both the intranet (your internal DNS server) and the extranet (public DNS through your domain registrar). For the intranet DNS record, ensure that you use A records and not CNAME records. This is required for windows authentication to work correctly from your domain joined machine.

After configure the prerequisites, next we install Azure AD Connect tool.

Installation of Azure AD Connect

Download Microsoft Azure Active Directory Connect from here

  • Sign in as a local administrator to the server you wish to install Azure AD Connect on. You should do this on the server you wish to be the sync server.
  • Navigate to and double-click AzureADConnect.msi.
  • On the Welcome screen, select the box agreeing to the licensing terms and click Continue.
  • On the Express settings screen, click Use Customize settings.

Installrequired components

When you install the synchronization services, you can leave the optional configuration section unchecked and Azure AD Connect sets up everything automatically. It sets up a SQL Server 2012 Express LocalDB instance, create the appropriate groups, and assign permissions.

User sign-in

After installing the required components, you are asked to select your user’s single sign-on method. In our case, we’ll select Federation with ADFS.

Connect toAzure AD

On the Connect to Azure AD screen, enter a global admin account and password.

Connect yourdirectories

To connect to your Active Directory Domain Service, Azure AD Connect needs the forest name and credentials of an account with sufficient permissions.

Microsoft Azure Application Gateway

After entering the forest name and clicking Add Directory, a pop-up dialog appears and prompts to create a new account or use existing account required by Azure AD Connect for connecting to the AD forest during directory synchronization.

Azure ADsign-in configuration

This page allows you to review the UPN domains present in on-premises AD DS and which have been verified in Azure AD. This page also allows you to configure the attribute to use for the userPrincipalName.

Azure Application Gateway Adfs

Domain and OU filtering

By default all domains and OUs are synchronized. If there are some domains or OUs you do not want to synchronize to Azure AD, you can unselect these domains and OUs.

Uniquely identifying your users

The Matching across forests feature allows you to define how users from your AD DS forests are represented in Azure AD. A user might either be represented only once across all forests or have a combination of enabled and disabled accounts. The user might also be represented as a contact in some forests.

2017 download all icloud photos to mac. After you are signed-in, click on the Photos Icon. In iCloud Photos, click on the Photos Tab and press Command + A to select all iCloud Photos and click on the Download icon to start the process of downloading All iCloud Photos to Mac. Note: If Command+A is not working, make sure iCloud Photos.

Sync filtering based on groups

The filtering on groups feature allows you to sync only a small subset of objects for a pilot. To use this feature, create a group for this purpose in your on-premises Active Directory. Then add users and groups that should be synchronized to Azure AD as direct members. You can later add and remove users to this group to maintain the list of objects that should be present in Azure AD. All objects you want to synchronize must be a direct member of the group. Users, groups, contacts, and computers/devices must all be direct members. Nested group membership is not resolved. When you add a group as a member, only the group itself is added and not its members.

Optional Features

This screen allows you to select the optional features for your specific scenarios.

Create a new ADFS farm or use an existing ADFS farm

You can use an existing AD FS farm or you can choose to create a new AD FS farm. If you choose to create a new one, you are required to provide the SSL certificate. If the SSL certificate is protected by a password, you are prompted for the password.

Specify the ADFS Servers

Enter the servers that you want to install ADFS on.

Specify the service account for the ADFS service

The AD FS service requires a domain service account to authenticate users and lookup user information in Active Directory.

Select the Azure AD domain that you wish to federate

This configuration is used to setup the federation relationship between AD FS and Azure AD. It configures ADFS to issue security tokens to Azure AD and configures Azure AD to trust the tokens from this specific ADFS instance. This page only allows you to configure a single domain in the initial installation. You can configure more domains later by running Azure AD Connect again.

Verify the Azure AD domain selected for federation

When you select the domain to be federated, Azure AD Connect provides you with necessary information to verify an unverified domain. See Add and verify the domain for how to use this information.

Configure and verify pages

Select start the synchronization as soon as possible.

Verify your federation configuration

Azure AD Connect verifies the DNS settings for you when you click the Verify button.

In addition, perform the following verification steps:

  • Validate that you can sign in from a browser from a domain joined machine on the intranet: Connect to https://myapps.microsoft.com and verify the sign-in with your logged in account. The built-in ADDS administrator account is not synchronized and cannot be used for verification.
  • Validate that you can sign in from a device from the extranet. On a home machine or a mobile device, connect to https://myapps.microsoft.com and supply your credentials.
  • Validate rich client sign-in. Connect to https://testconnectivity.microsoft.com, choose the Office 365 tab and chose the Office 365 Single Sign-On Test