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, https://fs.pfedemo.com/adfs/ls/IdpInitiatedSignon.aspx . 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.
Join your ADFS WAP to your home lab domain and restart the server. Once back up, connect to the VM and log in again with your admin credentials.
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 fs.pfedemo.com. 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 is joined to the home lab domain) any other device will not yet be able to resolve the ADFS service name. To complete this task, we have to add some public DNS records in our public DNS manager. Let’s do that now!
Step 3 - Create Public DNS records for ADFS WAP in Azure
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 the same records created in the home lab DNS. The only caveat is that the A record you create for your ADFS service name should point to the PUBLIC IP of your ADFS WAP server in Azure. You can find the PUBLIC IP of the ADFS WAP in Azure by looking at the VM Dashboard in Azure. See the screenshot below:
Notice the A record for the ADFS Service that points to the public IP address of my ADFS WAP and the two CNAME records for enterpriseenrollment and enterpriseregistration, configured in the same manner as in Part 1.
Once you create the records, 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 (https://fs.pfedemo.com/adfs/ls/IdpInitiatedSignon.aspx). And, it should work like a charm!
Step 4 – Complete the SSO configuration for ADFS and Intune
Lastly, we have a few more steps to complete to finish our ability to leverage SSO with Intune. The first thing we need to do is we need to Install Windows PowerShell for single sign-on with ADFS.
On your on-prem ADFS server, navigate to the link:
http://technet.microsoft.com/en-US/library/jj151814.aspx
Review the contents of the link. The direct installer for Windows Powershell for SSO (which is actually is called Azure Active Directory Module for Windows Powershell (64-bit)) is located here:
http://go.microsoft.com/fwlink/p/?linkid=236297
Download and install the Windows Powershell for single-sign on with ADFS on your on-prem ADFS server.
Next, we need to setup the trust between our ADFS and Intune. On your on-prem ADFS server, open the Microsoft Azure Active Directory Module.
At the prompt, type in “$cred=Get-Credential”. When prompted for credentials, type in your admin credentials for Intune (what you log into the Intune management portal with)
Once authenticated, at the next prompt, type in “Connect-MsolService –Credential $cred”. This will connect you to Azure AD.
Next, type "New-MsolFederatedDomain –DomainName %domain%". NOTE: Replace the %domain% placeholder with the name of the public domain.
When you execute this command, you will receive a WARNING message saying that you need to verify ownership of the public domain by creating a TXT record in the public DNS zone file for your domain. Notate what the WARNING message says as you will need that info to create the file. Again, I will not show steps to configure the public DNS as it can be different depending on your provider. If you have questions regarding how to create this record with your provider, contact your provider to assist with this step.
After adding the TXT file in your public DNS, it can take 15 minutes to 72 hours to take effect. For me, it only took about 30 minutes, so go take a break and come back in a bit.
After your break, run the "New-MsolFederatedDomain –DomainName %domain%" command again. NOTE: Replace the %domain% placeholder
Lastly, run “Convert-MsolDomainToFederated –DomainName %domain%”. NOTE: Replace the %domain% placeholder with the name of the public domain to finalize the process of setting up the trust between ADFS and Intune.
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....