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

Hello all,

 

In the past year, we've seen a lot on Intune and ConfigMgr 2012 R2. Intune is rapidly evolving and I'm excited about the future functionality planned for Intune and ConfigMgr 2012 R2. With that said, I wanted to start a 5 part blog series dedicated to Intune/ConfigMgr 2012 R2 and ADFS. If interested, hop along for the ride, because we'll be doing some really cool stuff in this series.

 

Most have seen the blogs available that show how to setup Intune and ConfigMgr 2012 R2 without ADFS in a lab scenario. But wouldn’t it be cool to setup ADFS in a lab scenario to see how it all works with single sign-on? Even better, wouldn’t it be cool if we could use Azure to host our internet-facing ADFS Web Application Proxy (WAP) to forward authentication requests to our lab ADFS? Well, guess what? You can and this blog series is going to walk you through how to set up such a Windows Intune/ConfigMgr 2012 R2 ADFS On-Prem and Azure Lab. The first part in this series is the home lab or intranet setup. The other parts of this series are coming very soon. In fact, I have them all done except for Part 5, which I am very close to finishing. As for the others, I will be uploading all the content and publishing very soon. These blogs are fairly lengthy, so it will take some time to complete, giving me time to put the finishing touches on the other parts in this series. Placeholder "links" have been listed below. As I complete each part of this series, I'll update the placeholders below with a link to the blog. Hope you enjoy!

 

Additional Links to Other Parts of the Blog Series.

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

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

Part 4 – Configuring Intune and ConfigMgr 2012 R2

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

 

Before we get into the guts of the configuration, some terminology we’ll be using:

  • Intranet – refers to your home lab setup

  • Internet – refers to the Azure portion that we’ll be connecting to the Intranet

     

This blog post assumes you’ve already done the following (in order):

  • Installed a domain controller that is Windows Server 2012 R2 in your intranet

  • Have a registered, Internet domain name. If possible, register an Internet domain name with the same name as your intranet domain. If this is not possible, there will be more on what to do later in the blog to work around. NOTE: I wasn’t able to procure an Internet domain name that was the same as my intranet domain, so I will include steps to work around.

  • Obtain a wildcard certificate from a Trusted Public CA following the instructions at this link. By no means is this a plug for the company, but I used DigiCert to obtain my certificate. NOTE: Since the cert is a wildcard, the subject name of the cert will be *.contoso.com, for example. Lastly, the certificate must be provisioned in PFX format.

  • Created an Azure trial subscription or have an Azure subscription

  • Create an Intune trial subscription or have an Intune subscription

Part 1 - Intranet Lab Setup:

You’ve already ensured you’ve completed the above pre-requisites and are ready to get started. The first step is the Intranet lab setup. In these steps, we’ll configure a RRAS server that we’ll use to connect our intranet lab to Azure, where our ADFS WAP will be hosted that will forward internet authentication request from Intune to the ADFS service in the intranet environment. Unless you have a commercial Cisco or Juniper Network router for your intranet, it’s easiest to spin up a RRAS server in your lab to accomplish this.

 

Let’s dive right in!

Step 1:

Install and configure RRAS on your Windows 2012 R2 domain controller. NOTE: You can install this on any server in you lab. I don’t know about you, but I just don’t have the capacity in my home lab to spin up virtual servers for a lot of different purposes. So, I installed it on my domain controller.

 

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 Remote Access checkbox and click Next

 

On the Features and Remote Access screens, click Next

 

On the Role Services screen, select Routing and click Next. A new window will appear saying additional features are needed to support this role service. Click Add Features to add the necessary features.

 

 

Back on the Role Services screen, notice that DirectAccess and VPN (RAS) and Routing are now selected. Click Next to continue.

 

On the Web Server Role (IIS) and Role Services screen, click Next.

 

On the Confirmation screen, click Install. The services will now install. When complete, click Close to close the Add Roles and Features Wizard.

 

 

In Server Manager, you will see the yellow exclamation to configure Remote Access. Click the icon and the Configure Remote Access screen will appear. Choose the option to Deploy VPN Only.

 

 

The Routing and Remote Access Management Console will appear. In the left pane, right-click on the server with the red icon and choose Configure and Enable Routing and Remote Access from the context menu

 

 

The Routing and Remote Access Server Setup Wizard will appear. On the Welcome screen, click Next.

 

On the Configuration screen, check the Remote Access (Dial-Up or VPN) option and click Next.

 

 

On the Remote Access screen, check the VPN Server checkbox and click Next.

 

 

On the VPN Connection, choose the network adapter desired to be leveraged for RRAS and click Next.

On the IP Address Assignment, choose Automatically if you leverage a DHCP server. If you do not leverage a DHCP server, select the From A Specified Range of Addresses option. NOTE: In my lab, I use a static range.

 

On the Address Range Assignment Window, click New. The New IPv4 Address Range window will appear. Enter the range desired and click OK. Then click Next to continue.

 

On the Managing Multiple Remote Access Servers screen, click Next.

 

On the Summary screen, click Finish.

 

NOTE: If you intranet domain matches your registered Internet domain name, skip step 2. For step 3, only execute the steps starting with creating the A record for the ADFS service name.

Step 2:

If you were not able to obtain a registered Internet domain name that matches your intranet domain, add a UPN suffix in AD Domains and Trusts for the registered Internet domain name.

At the start screen on your server type in “Domains and Trusts” and select Active Directory Domains and Trust from the menu below.

 

 

The Active Directory Domains and Trusts window will appear. Right-click the top-node and choose Properties from the context menu. NOTE: Notice the intranet lab name of MSLAB.local

 

The Active Directory Domains and Trusts properties window will appear. On the UPN Suffixes tab, in the Alternative UPN suffixes field, type in the name of the registered Internet domain and click Add. Then click OK to close the window. NOTE: Notice the name of the UPN added is pfedemo.com. This is the name of my registered Internet domain.

 

Step 3:

Create a new DNS primary zone for the new UPN in your intranet DNS. The purpose of this is so when the ADFS WAP we’ll setup later receives the authentication request to enroll a device via Intune, the ADFS WAP can then resolve the ADFS service name to the domain controller, where ADFS will be installed, and the user can be authenticated to enroll the device.

 

On your domain controller, from your Start screen, open DNS Manager by clicking the DNS tile

 

DNS Manager will open. Expand the Forward Lookup Zones node. Right-click the Forward Lookup Zones zone and select New Zone from the context menu.

 

 

The New Zone Wizard will appear. On the Welcome screen, click Next. On the Zone Type screen, ensure the Primary Zone radio button is selected and click Next.

 

 

On the AD Zone Replication Scope screen, accept the default selection, To all DNS servers running on domain controllers in this domain, and click Next.

 

 

On the Zone Name screen, in the Zone Name input field, type in the name of the registered Internet domain and click Next. In my lab, I have used pfedemo.com.

 

 

On the Dynamic Update screen, accept the default and click Next. Then on the Finish screen, click Finish to create the new zone.

 

Back in DNS Manager, you will now see the new zone you have created.

 

NOTE: For those who have an internet registered domain name that is the same as their intranet domain name, execute the following steps down.

Right-click on the new zone and choose New Host (A or AAAA) from the context menu.

 

The New Host Window will appear. IMPORTANT: In the Name field, type in the name that you will give to your ADFS service. Using my lab as the example, in the Name field, input “fs”. In the IP address field, type in the IP address of your domain controller (as the DC will host the ADFS service in the intranet lab). Click Add Host to create the new A record. You can ignore the notification that the PTR record could not be created.

 

 

Right-click on the new zone and choose New Alias (CNAME) from the context menu

The New Resource Record window will appear. In the Alias Name field, type in “enterpriseregistration”. In the Fully Qualified Domain Name (FQDN) for Target Host field, type in the FQDN of the DNS A record you created in the previous step. In my example, I would type in “fs.pfedemo.com” as this is the name of my ADFS service name. When complete, click OK to create the CNAME record. NOTE: Creation of this record is only required if you want to leverage WorkPlace Join on Windows 8.1 devices.

 

Right-click on the new zone and choose New Alias (CNAME) from the context menu

The New Resource Record window will appear. In the Alias Name field, type in “enterpriseenrollment”. In the Fully Qualified Domain Name (FQDN) for Target Host field, type in “manage.microsoft.com”. NOTE: Creating this record ensures that users will not have to type in manage.microsoft.com along when enrolling their devices.

Using the list of public DNS forwarders for here, choose a public DNS provider. NOTE: I use OpenDNS

 

Back in DNS Manager, right-click Conditional Forwarders and choose New Conditional Forwarder from the context menu.

 

The New Conditional Forwarder window will appear. In the DNS Domain field, give the Forwarder an intuitive name. In the IP Address section, type in secondary DNS server IP of the public DNS provider chosen and press tab. Then, type in the primary DNS server IP of the public DNS provider chosen. Finally, click OK to create the DNS Conditional Forwarder.

 

That about wraps up the foundation of the home intranet lab setup. We’ll have a few more things to configure later on, but done for now. Next up, create our Azure Network and provision our Azure VM.

 

Till next time.....