Trying Out Autopilot Hybrid Join Over VPN In Your Azure Lab

by Scott Muniz | Aug 27, 2020 | Azure, Microsoft, Technology, Uncategorized

This article is contributed. See the original author and article here.

As an IT admin you plan to ship new devices to end users which can join the on-premises AD (Active Directory) by leveraging Autopilot with Intune for device management.

This post is a walkthrough of evaluating the Autopilot Hybrid join over VPN scenario in a lab environment hosted in Azure.

Infrastructure

I have added steps to build the configurations and dependencies along the post, this can get complicated due to the number of components involved. Here is an agenda for this post along with a high-level network configuration of the setup:

For this lab exercise you will need:

Step1: Create an Azure Virtual Network

Let us start with setting up a networking infrastructure where we can place our VMs later. We will create a New Virtual Network.

• Sign-in to https://portal.azure.com/
• Click Create a resource and look for Virtual Network to create one.

1. Choose your appropriate Azure Subscription.
2. Create a new Resource Group for this lab.
3. Specify a Name of the Virtual Network.
4. Choose a Region you want to place this resource to.
5. Click Review + Create (leaving defaults for IP Address, Security and Tags)

• Click Create to finish creating the Virtual Network.

Step2: Create an Azure Virtual Network Gateway

We will now create a Virtual Network Gateway which acts as a software VPN.

• Sign-in to https://portal.azure.com/
• Click Create a resource and look for Virtual Network Gateway to create one.

1. Choose your appropriate Azure Subscription.
2. Specify a Name for the Virtual Network Gateway
3. Select the same Region you chose while creating the Virtual Network in the previous exercise.
   • Leave the Gateway type to VPN
   • Leave VPN type to Route-based
   • Leave the SKU to default VpnGw1
   • Leave Generation to Generation1
4. From the Virtual Network drop-down chose the name of the Virtual Network you created in Step1.
   • Leave the default the Gateway subnet address range.
   • Leave Create new under Public IP address
5. Specify a Public IP address name
   • Leave Enable active-active mode to Disabled.
   • Leave Configure BGB ASN to Disabled.
6. Click Review + Create.

• Click Create to complete the task.

Note: This may take 20 minutes or up. Do not proceed before this activity completes.

Step3: Create Virtual Machines – Domain Controller & Member Server

Now we start preparing the on-premises infrastructure starting with a Domain Controller and a Member Server both hosted as an Azure VM.

• Sign-in to https://portal.azure.com/
• Click Create a resource and look for Virtual Machine under Compute to create one each by repeating the steps twice one for the Domain Controller and the other for the Member Server.

1. Choose your appropriate Azure Subscription.
2. Select the Resource Group from previous exercise.
3.  Specify a Name of the VM
   • Region is auto populated based on the region you selected from step2.
   • Leave the default availability option. (No infrastructure redundancy required.)
4. From the Image drop-down choose a Windows Server OS
   • Leave the Azure spot instance default to No
   • Choose a size as appropriate. (I am leaving the default suggested by Azure)
5. Specify a Username and a password.
   • Leave the default inbound ports for RDP.
   • Leave default licensing.
6. Click Review + Create.

The wizard automatically chooses the Networking from the same resource group we selected. Feel free to make any changes as desired.

• Click Create to complete the process.

Once both the VM’s are successfully created, move to the next steps in configuring them.

Step4: Configure Virtual Machine 1 (Domain Controller)

On the first VM acting as a Domain Controller, install the following roles:

• Active Directory Domain Services [Domain Controller]

• Install Azure AD Connect to connect to Azure AD Tenant.
  1. Re-run AAD Connect to configure Hybrid Azure AD Join

• Create users on-prem and confirm synchronization in AAD. Do not forget to assign licenses.

• Install Active Directory Certificate Services [CA: Certificate Authority] Please choose Enterprise CA since Standalone is not supported for NDES.

• Create Certificate Templates for SCEP Profiles by following the instructions from this blog post for setting up NDES for SCEP certificate deployments. We will reference this blog post at various phases during the setup.
  1. Web Server Certificate – For NDES Server (VM2)
  2. Client Authentication Certificate – For NDES Server (VM2) you can even merge this with the Web Server Certificate by adding Client Auth. Capabilities instead of creating a new template.
  3. SCEP Certificate Template – For Devices

Step5: Azure DNS Configuration

Once your custom domain is created, we need to configure Azure networking to support the custom DNS configuration.

• Sign-in to https://portal.azure.com/
• Browse the Virtual Network created earlier Contoso-VNET
  1. Choose DNS Servers from the blade.
  2. Select Custom.
  3. Specify the internal IP Address of VM1 (in my case it is 10.0.0.4)
  4. Click Save

• Restart both the VMs connected to this network.

Step6: Configure Azure Virtual Machine 2 (Member Server)

On the second VM we will install a list of roles and features for our solution. One of the primary reasons for building this VM2 is the fact that you cannot co-locate both NDES and CA on the same server.

1. Join this VM to the Domain created in Step4.

2. Create and configure an NDES Service Account.

3. Install the NDES Role for additional guidance refer the instructions from this blog post.

4. Install an Azure AD Application Proxy Connector – Instead of a WAP (Web App Proxy server) for publishing NDES URL to the internet.

5. Add and an AAD APP Proxy Application for NDES. Refer the instructions from this blog post.

6. Request the NDES Web Certificate. Refer the instructions from this blog post.

7. Install the Intune Certificate Connector – SCEP

8. Install the Intune Domain Join Connector

Step7: Azure VPN Configuration

The above tasks prepare us to setup the Azure VPN user configuration.

• Sign-in to https://portal.azure.com/
• Browse the Virtual Network Gateway resource you created earlier we called it Contoso-VPN
• Click the User VPN Configuration from the menu and click Configure now.

1. Specify an Address pool for the VPN clients to connect.
2. Under Tunnel type specify IKEv2
3. For Authentication type, leave Azure certificate.

4. Under Root Certificates specify a name (example Root) and for Public Certificate Data:
   1. Make sure that you exported the root certificate as a Base-64 encoded X.509 (.cer) file. You need to export the certificate in this format so you can open the certificate with text editor.
   2. Open the certificate with a text editor, such as Notepad. When copying the certificate data, make sure that you copy the text as one continuous line without carriage returns or line feeds. You may need to modify your view in the text editor to ‘Show Symbol/Show all characters’ to see the carriage returns and line feeds. Copy only the following section as one continuous line:

5. Save the configuration.

Note: This may take 10 minutes or up to complete.

6. Click Download VPN Client and save for later use.

Optional: VPN Validation

To reduce the complexity, it is a good idea to validate the VPN connection outside Intune configuration.

• Build a Windows 10 VM or use a physical machine (meeting OS Prerequisites) which is not joined to the Domain we created above.
• Copy the VPN client we downloaded in the previous exercise.

Instead of executing the installer of the VPN client, we will manually create the VPN configuration from the Generic folder with the file name called VPNSettings.xml

• Use the following PowerShell cmdlet to manually create the VPN connection. Replace the highlighted values.

Add-VpnConnection -Name ContosoVPN -ServerAddress azuregateway-Replace_With_GUID.vpn.azure.com -AuthenticationMethod MachineCertificate -DnsSuffix domain.dns.com -SplitTunneling -TunnelType Ikev2

Add-VpnConnectionRoute -ConnectionName ContosoVPN -DestinationPrefix 10.0.0.0/16

• Import a Client-Auth cert for this device with Common Name = Computer Name

For this step you may want to generate a Certificate Template with Computer Authentication capability with Name supply in request and the option to export the private key.

• Connect VPN and try to ping/rdp/network-share or even join the machine to Domain.

Step8: Intune Configurations

Now that your base infrastructure configuration is complete, you can proceed with the Intune configuration.

• Enable Intune Automatic Enrollment
• Configure Tenant Branding
• Configure ESP (Enrollment Status Page)
• Create an AAD Group for Devices
• Create Autopilot Deployment Profile for Hybrid VPN Join and assign to the above AAD-Group, preferably to All Devices.

• Capture hardware hash import device and assign profile. Get-WindowsAutoPilotInfo. The sample below will capture the hash, upload in Intune, add to a group and assign to the deployment profile.

Get-WindowsAutopilotInfo –online -AddToGroup “AZ-XYZ” -Assign

• Create Root Cert Configuration Profile and assign to the same AAD-Group.

• Create SCEP Certificate Profile and assign to the same AAD-Group.

Specify the Subject name format as CN={{FullyQualifiedDomainName}}

• Create a VPN Configuration Profile and assign to the same AAD-Group. Refer the configuration settings from the VPN Client you downloaded under the folder named Generic with the file name called VPNSettings.xml

1. Specify a Connection Name
2. Under Servers Description, specify a Name.
3. For Ip Address or FQDN, specify the VPNServer info from VPNSettings.xml
4. Set Default server to True.
5. Enable Register IP address with internal DNS
6. Choose the Connection type as IKEv2
7. Choose Always On to Enable
8. Set the Authentication method to Machine Certificates.
9. Under Authentication certificate choose the SCEP Certificate profile you created before.
10. Enable Device Tunnel

• Leave the following sections to defaults:
  • Apps and Traffic Rules
  • Conditional Access
• Customize the DNS Settings by adding:
  1. Add the Domain name as your DNS Suffix.
  2. Add Name Resolution Policy table (NRPT) rule by specifying:
     1. Domain
     2. DNS Server IP

• Leave the Proxy settings to defaults.
• Under Split Tunneling:
  1. Enable the configuration.
  2. Under Destination prefix and Prefix size specify the subnet address under <Routes> by referring the VPNSettings.xml

• Deploy to the AAD-Device group and proceed with testing/validation on a device.

Time for testing and evaluation!

Thanks,

Arnab Mitra

Completely Private Azure SQL with Conditional Access Policy

by Scott Muniz | Aug 27, 2020 | Azure, Microsoft, Technology, Uncategorized

This article is contributed. See the original author and article here.

My customer wanted to lock down their Azure SQL access very, very tightly. The server should have no public endpoints whatsoever, and the only access to it should be from a specific set of trusted IP addresses. This is a common requirement, especially for customers in heavily-regulated industries such as finance and healthcare.

Instead of relying on the firewall built in to Azure SQL Server, which is specific that that instance, they preferred to rely on the Conditional Access Policy (CAP) capabilities within Azure Active Directory (AAD). This would allow them to ensure that authentication requests for all Azure resources could be validated and controlled from a single place, that being, AAD.

This article will describe the challenges of setting up this environment and provide at least one architecture to solve it. I’ll show how to have an Azure VM running SQL Server Management Studio (SSMS) that authenticates against AAD and accesses Azure SQL via a Private Endpoint. None of these services will have internet access.

Note that “Locations” in AAD entail IP ranges in CIDR format. Fully qualified domain names (FQDN) are not allowed.

One thing to remember: all network traffic that flows from one Azure service to another, whether it’s in the same region or different, flows across the private Microsoft network. For example, if a VM in one region accesses an Azure SQL Server in another region via the latter’s public IP, that traffic occurs across private Microsoft fiber, even though a “public Internet IP” is used on the Azure SQL instance.

Locking Down Azure SQL

Even though traffic between an Azure VM and Azure SQL on a public IP will stay within the Microsoft network backbone, that public IP is not guaranteed to be static. Customers are therefore encouraged to access Azure SQL Server via its FQDN only, not via the underlying IP address.

Since Locations in AAD require IPs and not FQDNs, we cannot specify our Azure SQL Server instance as a Trusted Location in AAD. We will have to use the Private Endpoint capabilities of Azure SQL Server to tie it down to a Virtual Network (VNet).

I created one VNet (10.0.0.0/16) with two subnets:

1. SQLServer (10.0.0.0/24)
2. VMs (10.0.1.0/24)

I then configured a Private Endpoint to be present in the SQLServer subnet. Lastly, I set “Deny public network access” to “Yes.”

 

 

One thing to note: DNS with Private Link can be tricky. I did it the easy way: by letting Private Link automatically create an Azure Private DNS Zone that was associated with the VNet. That way the SSMS VM could find the SQL Server on its private endpoint via its FQDN: “sql-server-gary.database.windows.net.” Do not use its internal FQDN of “sql-server-gary.privatelink.database.windows.net.”

For more information on DNS and Azure Private Link see this very helpful set of documents.

Locking Down SSMS VM

This was easy. Just disassociate the public IP from the IP configuration of the VM’s network interface. To access, I just created a jump box in the same subnet (VMs). Our SSMS VM now has access only to the internal VNet.

In addition, I added a “deny internet” outbound rule on the SMSS VM’s Network Security Group (NSG) near the top of the priority list. Before it I added a rule to allow Azure Active Directory outbound flow.

 

 

Please note that the rules in this NSG are only used as examples for this specific use case. Your application will undoubtedly have additional requirements that you should consider. The goal should be to deny all traffic except that which is mandatory, and then only between the necessary components.

Locking Down AAD

In addition to controlling access via user sign on with multi-factor authentication (MFA), the customer wanted to make sure that no rogue agent was able to access from a public IP. Therefore, they created a CAP with the following configuration:

1. All users included.

2. All locations included.

3. Trusted locations excluded.

4. Azure SQL Database included.

5. Block access.

I added the VNet’s CIDR (10.0.0.0/16) as a Trusted Location in AAD. Of course, I could have chosen “All Cloud Services” instead of just “Azure SQL Database” to provide protection to even more resources.

Allowing Access from VNet to AAD

Lastly, it’s necessary to allow requests for authentication tokens to flow from our VNet to AAD.

Azure uses an internal IP for this. Unfortunately, this IP is not static, and can change at any time.

To make the IP static we will take advantage of the NAT Gateway service. This will fix the range of IPs used for outbound traffic. I associated the NAT Gateway with both of my subnets: SQLServer and VMs.

The “IP prefix” CIDR range should be added as a Trusted Location in AAD. This will allow the token request from our VNet to AAD to flow.

 

 

Conclusion

Here is a diagram to tie it all together. In this case I don’t have a jump box in Azure, but rather access is made from an on-premises computer via a private ExpressRoute connection.

This approach is attractive for several reasons:

• It adds another layer of protection to your cloud security. Redundancy is often desirable.
• Controlling access at the Azure Active Directory layer, where authentication tokens are provided, provides a single place to add new trusted locations, as opposed to doing so for each individual service.