Setting Up Windows Intune/ConfigMgr 2012 R2 with ADFS On-Prem and Azure Lab - Part 3


Ok, to quickly recap what we did in Part 2, we created our Azure virtual private network, configured our home VPN device (RRAS server), validated connectivity between the home intranet and Azure through the Azure portal, and provisioned our Azure VM that will host the ADFS WAP role.


Additional Links to Other Parts of the Blog Series.

Part 1 – Home Intranet Lab Setup

Part 2 – Create and Configure Azure Network and Provision Azure VM

Part 4 – Configuring Intune and ConfigMgr 2012 R2

Part 5 - Enrolling the Different Device Types in Intune (Windows Phone, Android, iOS)


Next up, we need to install and configure ADFS On-Prem and in Azure.  It’s about to get pretty cool, so hang on!


Part 3 – Install ADFS On-Prem and Install ADFS WAP on Azure VM


Step 1:

Ensure you have copied the certs provisioned in the pre-requisites from Part 1 to the domain controller in your home intranet lab.


Login as administrator on the domain controller and open Server Manager on the server you wish to install the role and select the Add Roles and Features link.


The Add Roles and Features Wizard will appear.  On the Before You Begin screen, click Next.


On the Installation Type screen, ensure the Role-Based or Feature-Based Installation radio button is selected and click Next.


On the Server Selection screen, ensure the Select a Server From the Server Pool radio button is selected and click Next


On the Server Roles Screen, select the Active Directory Federation Services checkbox and click Next


On the Features and Remote Access screens, click Next.


On the Active Directory Federation Services (AD FS) screen, click Next.


On the Confirmation screen, click Install.


After ADFS installs, click the “Configure the federation service on this server” link.


The ADFS Configuration Wizard window will appear.  On the Welcome screen, accept the default option and click Next.



On the Connect to AD DS screen, choose an account to perform the configuration.  Using a domain admin account is easiest.  However, you can use an account that has write permissions in AD.  Once the account has been specified, click Next.


On the Specify Service Properties screen, in the SSL Certificate field, click the Import button to the right.  Navigate to the location of the PFX file, select it, and click Open.


You will be prompted to input a password.  Input the password given when the PFX was created and click OK.


Back on the Specify Service Properties screen, notice the SSL Certificate and Federation Service Name fields are now populated.  You must change the Federation Service Name to the name you wish to call your Federation Service.  NOTE:  This value will be the A record we created in the new DNS Zone in Part 1.  In the Federation Service Display Name field, type in a name that you wish to display on the ADFS Login page.  When complete, click Next.


On the Specify Service Account screen, in the Account Name field, click the Select button.  The Select User or Service Account window will appear.  Type in the user account and click the Check Name button.  Click OK to close the Window.  The Account Password field will appear.  Input the password for the account and click Next.  NOTE:  I used my domain admin account.  You can use any account you wish as the wizard will configure the permissions and SPN for the user automatically.


On the Specify Configuration Database screen, choose to leverage the Windows Internal Database or point ADFS to a SQL server.  I elected to use the WID, which is the default selection.  Click Next.


On the Review Options screen, just click Next.


On the Pre-Requisite Check screen, AD FS wizard will run a pre-req check to ensure all is ready for the configuration.  If any notifications, review them and correct.  When ready, click Configure.


ADFS will now be configured.  When the configuration is complete, click Close to close out the wizard.


Now, let’s see if it works!  Open up an IE and type in the following URL, replacing the FQDN with the FQDN of your federation service name, .  You should see something similar to this:


If you click Sign in, you’ll be prompted to input your credentials.  If you add this site as an Intranet Site in IE security settings, you’ll get SSO and you’ll see the screen below.

NOTE:  If you click the URL I provided above as an example, which is my actual ADFS service, you’ll get forwarded to my Azure ADFS WAP, which will then wait for credentials to pass to my ADFS service in my home intranet lab to authenticate.  If you have certificates installed, you may get prompted to choose a certificate, but just click cancel and you’ll eventually get to the login page.


Awesome!  The ADFS On-Prem is installed and successfully configured.  Now on to the Azure VM.


Step 2:

Configure the Azure VM as an ADFS Web Application Proxy (WAP).  WAP is new in Server 2012 R2 and it makes ADFS much easier to work with.


Ok, log into your Azure portal and connect to your Azure VM with your admin credentials.  Once logged in, ensure you have copied the same PFX certificate used to configure the ADFS On-Prem server to the Azure VM.  Navigate to the certificate, right-click and select Install from the context menu.  Enter the password and complete the wizard to successfully import the certificate on the Azure VM.

Because it is not a best practice to join our ADFS WAP to the On-Prem domain, we need to edit our host file to allow the ADFS WAP server to resolve the ADFS service name to our ADFS On-Prem server.  Open up Windows Explorer and navigate to C:\Windows\System32\drivers\etc.  Open the HOSTS file in Notepad.  Add an entry for your ADFS On-Prem server IP and the ADFS service name.  Save the HOSTS file when complete.  And from the Azure VM, attempt to ping the ADFS service name and IP to validate a response.  See screenshot below for how the HOST file looks for Azure VM.

As can be seen, is the IP of my ADFS On-Prem server and I have set it to resolve to my ADFS federation service name.


Open Server Manager and click Add Roles and Features


The Add Roles and Features Wizard will appear.  On the Before You Begin screen, click Next.


On the Installation Type screen, ensure the Role-Based or Feature-Based Installation radio button is selected and click Next.


On the Server Selection screen, ensure the Select a Server From the Server Pool radio button is selected and click Next


On the Server Roles Screen, select the Remote Access checkbox and click Next


On the Features screen, click Next and on the Remote Access screen, also click Next.  On the Role Services screen, check the Web Application Proxy checkbox.  When prompted to add features, click the Add Features button.  Click Next to Continue.


On the Confirmation screen, click Install.  When the installation is complete, Click the “Open the Web Application Proxy Wizard” link.


The Web Application Proxy Configuration Wizard will appear.  Click Next to continue.


On the Federation Server screen, in the Federation Service Name field, type in the FQDN of your federation service.  For example, mine was/is  In the Credentials area, input the credentials of a local admin account on the home intranet ADFS server (domain controller).  You can use any account, but I used the domain admin because this is a lab environment.  In a production environment, I would not recommend such.  When finished, click Next.


On the AD FS Proxy Certificate screen, click the down-arrow and choose the certificate listed and click Next.


On the Confirmation screen, click Configure


Now, the WAP will attempt to establish a relationship with the ADFS On-Prem server.  Once the wizard is complete, you’ve successfully configured your ADFS WAP.  If you’d like, you can open up the Remote Access Management console on the ADFS WAP server and view the WAP status.  However, something cooler to do is from the ADFS WAP, you should be able to open up IE and go to the same URL we used earlier to test and you should get the ADFS login page.  While the ADFS WAP can now hit the ADFS service from the Internet (because it the server explicitly listed in its HOST file), any other device will not yet be able to resolve the ADFS service name.  To complete this task, we have to add a record in our public DNS manager.  Let’s do that now!


Step 3

From whomever you purchased the registered Internet domain name, they should provide a DNS manager that you can use to add records as needed.  Log in to your “hosting” provider and access the DNS manager.  I used GoDaddy and will show screenshots from my DNS Manager.

Since it will be different across different providers to accomplish this step, I will not show each individual step.  However, what you want to do is create an A record for your ADFS service name and set the A record to point to the PUBLIC IP of your ADFS WAP server in Azure.  See the screenshot below:


Once you create the record, it could take some time for it to take effect.  I think I waited 30 minutes before trying to access the URL we’ve used to test ADFS from a complete external, internet device, with no direct ability to resolve my ADFS service name (  And, it should work like a charm! 


With that, we’ve done everything necessary to create a single sign-on experience for our to-be Intune users.  All we need to do now is configure Intune and configure an Intune subscription in ConfigMgr and we’re all done.  That’s what’s next in the final blog for this series.  Hang in there, we are almost done!


Till next time....