Intune Suite’s Cloud PKI & Unifi Authentication Made Simple

If you’ve been navigating the world of 802.1x network authentication using Intune and third-party tools, get ready for a game-changer. With the introduction of the Intune Suite featuring Cloud PKI, the path to secure network connectivity for managed endpoints has never been clearer. After acquiring Unifi networking equipment and the Intune Suite, I’m eager to delve into Cloud PKI & Unifi authentication!

Table Of Contents

The Background

The need for transparent network authentication has been around for quite some time. In the past, the internal network was considered a secure area, and access was restricted to known devices using certificate authentication.

This is typically a barrier when transitioning from traditional on-premises to modern cloud-based operations. Initially, old on-premises solutions were stretched to fit the modern cloud environment. Distributing the certificates required considerable effort, and numerous creative solutions were devised to make the NPS server trust cloud-only devices. While this approach worked to some extent, it’s no longer sustainable.

The solution then shifted to utilizing third-party solutions (SCEPman and RADIUSaaS), which have proven effective. Gone were the days of complex configurations between cloud and ground.

Now, armed with Intune Suite’s Cloud PKI, I wonder if I can simplify this even more. Join me on this journey as I harness the potential to achieve a new standard of connectivity—one that’s both seamless and secure.

Cloud PKI & Unifi Authentication Prerequisites

The main prerequisites for the setup of this blog post are the Intune suite and Ubiquiti Unifi network equipment.

Intune Suite’s Cloud PKI Add-On

The Intune Suite contains several advanced endpoint and security management add-on solutions unified in Microsoft Intune. One is the Cloud PKI add-on, which allows you to create certificate authorities in the cloud and further automate certificate lifecycles for managed devices.

The Cloud PKI add-on is the prerequisite I need, and this is available for trial or purchase through the Intune add-on blade found in Intune’s Tenant administration. It can be purchased as a standalone add-on or as part of the Intune suite.

I can see Cloud PKI active as a capability in my tenant.

This will allow me to use Intune to configure certificates to my managed endpoints.

Unifi Network Equipment

With the Cloud PKI add-on, I have a locksmith onboard, ready to provide keys to my endpoints. Now, I must ensure my doors are ready to accept these shiny new keys.

Not everything can be solved by software alone. Sometimes, I also need physical equipment. I enjoyed unboxing the Ubuiquitis Dream Machine Special Edition, a Unifi USW-Lite-16-PoE switch, and a Unifi U7-Pro access point this time.

The picture above shows my chaotic pilot installation before the solution goes to the rack.

The picture above shows the Dream Machine racked and ready with direct fiber from Altibox using an SFP transceiver.

Radius In The Cloud?

The UNIFI network equipment still needs a RADIUS server as a doorkeeper. RADIUS is a networking protocol that provides centralized authentication, authorization, and accounting management for users or devices connecting.

I will use RADIUSaaS for this project, which I know from other projects and is compatible with Microsoft Cloud PKI.

Cloud PKI Implementation

I’m now eagerly prepared to begin the setup process to see if I can get this spaceship off the ground!

Cloud PKI has its administration blade under Tenant Administration in Intune:

There are no CAs configured out of the box.

Create The Root CA

First out, I need to create a Root CA resource.

After providing a name and a description, I will configure the details for the Root CA.

As for CA type (1), I will select “Root CA” before setting the validity period (2) to 15 years. Next, I need to configure the purposes of use under Extended Key Usages (3). These will be tattooed and impossible to change later on, and it will also put limitations on the certificate options available to the issuing CA created later on. The subject attributes (4) should be filled in as accurately as possible before selecting the Encryption (5).

The root CA should now be completed within seconds.

The CA is now listed in the portal.

Create The Issuing CA

Next up is to create the issuing CA.

After providing a name and a description, I will configure the details for the Issuing CA.

As for CA type (1), I will select “Issuing CA”. This allows me to select between Intune and bringing my root CA under Root CA Source (2). Selecting Intune allows me to select my Intune-based Root CA (3). Next is selecting the Validity Period (4) for the issuing CA. I can now select among the Extended Key Usages (5) enabled from the Root CA. The subject attributes (6) should be filled in as accurately as possible, and the Encryption (7) should be locked from the Root CA.

The issuing CA should now be completed within seconds.

This is all the infrastructure needed within Intune as a baseline for distributing certificates using Cloud PKI

Deploy Root And Issuing CAs To The Endpoints

Each newly created CA (Root CA and Issuing CA) must be distributed to the managed endpoints to ensure they trust our new Cloud PKI service in Intune.

This will give you two CER files representing the configured Intune CA’s. These certificates should now be distributed to the managed endpoints using Intune.

I am using the Trusted Certificate template for this purpose. The Root CA should go to the “Computer Certificate Store – Root”, and the Issuing CA should go to the “Computer Certificate Store – Intermediate”.

My managed Windows devices will now trust my cloud PKI service. These two CAs should also be distributed to other operating systems using Intune, macOS, iOS, and Android.

Issuing Client Certificates

Next, I will issue client certificates to my managed endpoints, which will later be used as keys to access my managed Unifi WiFi. The client certificates are configured using the Scep Certificate Template.

For Certificate Type (1), I am using Device, as I want the device to get a network connection regardless of which user is signed in to the device.
For Subject name format (2), I am using “CN={{AAD_Device_ID}}”.
For Attribute (3), I set URI to “CN={{AAD_Device_ID}}”.
Next, I configure my preferred values for the certificate (4).
Validity period: 1 year, Key storage provider: TPM, Key usage: Digital Signature and Key encipherment, Key size: 2048 bits, Hash algorithm: SHA-2.
For Root Certificate (5), I select the policy distributing the Issuing CA.
For Extended Key Usage (6), I select the predefined value “Client Authentication”. Use the right-most dropbox for this.
Enrollment Settings (7) is defaulted at 20%,
Scep Server URL (8) is copied from the Issuing CA found in the Cloud PKI admin blade.

The policy is assigned to all devices.

Verify Certificates At Endpoint

The three configuration profiles will now distribute the certificates to the targeted Windows endpoints. I can easily verify this using the Microsoft Management Console with the Certificate snap-in.

Quick Keyboard Shortcut Tips
Getting to the Certificate snap-in as normal user:
<win>+r – mmc – <enter> – <ctrl>+<m> – c – <tab> – <space> – <tab> – <enter>

Getting to the Computer Certificate snap-in as local admin:
<win>+r – mmc – <enter> – <ctrl>+<m> – c – <tab> – <space> – c – <enter> – <enter> – <tab> – <enter>

The root certificate should be visible under Trusted Root Certificate Authorities.

The issuing certificate should be visible under Intermediate Certification Authorities.

The device certificate should be visible under Personal if you run MMC with admin privileges and load the Certificates snap-in for the local computer.

The Event Viewer on the device will also provide information on the certificate-issuing process. Filtering on Event ID 36 in the “Microsoft – Windows – DeviceManagement-Enterprise-Diagnostics-Provider-Admin” log will give some information.

I can also see all certificates issued by the issuing CA from the Cloud PKI blade under the Tenant Administration in Intune.

I also have the option to revoke certificates issued at this location manually.

RADIUSaaS Implementation

RADIUS (RFC 2865) is the go-to protocol for handling network authentication for big corporations. RADIUS, short for Remote Authentication Dial-In User Service, is like the guardian of access, ensuring that only authorized users get through. Whether it’s for securing WiFi, wired connections (using 802.1X, EAP), or VPNs, RADIUS steps up to the plate. Originating from Livingston Enterprises, Inc.’s labs in 1991, this protocol has become a cornerstone of IETF standards.

UNIFI relies on the Radius service to authenticate using certificates. After some consideration, I’ve opted to employ an online RADIUS as a Service (RADIUSaaS ) solution, leveraging my familiarity from previous projects. Alternatively, I could have looked into freeRADIUS as an alternative running in a dockerized deployment

Request a RADIUSaaS Free Trial

I will start by requesting a free trial of RADIUSaaS from here:
https://www.radius-as-a-service.com/start-now/

After a while, I got access to my RADIUSaaS instance.

Upload My Cloud PKI Root Certificates To RADIUSaaS

Since my devices will authenticate using client certificates from Cloud PKI, I must ensure my RADIUSaaS instance trusts these certificates. To achieve this, I will upload the Root CA and the Issuing CA from Cloud PKI as trusted certificates on RADIUSaaS.

Navigating to Settings – Authentication Certificates, I can add both certificates.

Both the Root CA and Issuing CA are now available in the RADIUSaaS portal as trusted roots for client authentication.

With these in place, RADIUSaaS should trust certificates issued from my Intune Cloud PKI service.

Upload RADIUSaaS Server Certificate To Endpoints

In earlier projects involving RADIUSaaS and SCEPman, I have been using my own SCEPman certificates all over the place to simplify trust relationships. I have a challenge with Cloud PKI as the certificate chain can’t be exported with the private key for use in the RADIUSaaS service. This means my RADIUSaaS will use its private certificate, which I need to ensure my endpoint’s trust. If not, the TLS dialogue between endpoints and RADIUSaaS will suffer.

Download RADIUSaaS Server Certificate

I will navigate to Server Settings and download the current Server Certificate from RADIUSaaS.

I now have the CER file containing the full certificate chain.

Deploy RADIUSaaS Server Certificate To The Endpoints

With the CER file, I can now distribute this as a trusted root certificate to my endpoints using Microsoft Intune.

The policy will now ensure this certificate is distributed.

Verify Certificate At Endpoint

Looking into the Certificate Snap-in of MMC, the new RADIUSaaS trusted root certificate will be visible like this:

With this, I have a full circle of trust even though certificates from Cloud PKI can’t be used as server certificates at RADIUSaaS.

RadSec VS Radius Proxy

Earlier, I worked on RADIUSaaS implementations with HPE Aruba Central, utilizing the more secure RadSec protocol to transport RADIUS datagrams over TCP and TLS. The RADIUS protocol is a widely deployed authentication and authorization protocol, but unfortunately, my UNIFI products do not support the RadSec protocol. This means I need to use a RADIUS proxy inside RADIUSaaS.

Add Proxy To RADIUSaaS

Inside the RADIUSaaS Portal, I can find Proxy Settings under the Settings menu, where I can add up to two proxies in different regions. I will select Stockholm, which is my closest region.

The proxy will now be provisioned.

Once completed, I can see the Proxy IP Address listed behind the region. I will need this IP when configuring the Radius profile in UNIFI.

UNIFI Implementation

With Cloud PKI and RADIUSaaS with a proxy up and running, it is time to configure my UNIFI WiFi network.

Radius Profile in Unifi

The details needed to configure the Radius profile in UNIFI are available under Settings—Server Settings in the RADIUSaaS portal.

First, I will navigate to Settings – Profiles – Radius to create a new profile for my RADIUSaaS service.

I can now complete the profile setup.

I will enable the RADIUS profile for Wireless Networks (1).
For the authentication server (2), I add the IP address for the RADIUSaaS proxy and the coresponding Shared Secret.
Accounting is also enabled (3) to allow RADIUSaaS to receive usage logs.

WiFi Profile In UNIFI

With the Radius profile established, I will create a new WiFi Profile in UNIFI and use it to authenticate endpoints.

I navigate to Settings – Wifi in the Unifi portal and select to create a new profile.

By going to Manual in the Advanced section, I can change to WPA3 Enterprise and select the newly created Radius profile.

In my demo, I am routing this WiFi into the Default network, but I will change it to a corporate network.

Please be aware!
The network might reboot and give interuptions when applying this change!

With the network visible in the air, it is time to let the endpoints in.

Intune WiFi Profile Distribution

Now that the infrastructure is set, it’s time to invite the endpoints to the party. They all have their keys and trust each other, so all that’s left is to guide them to the right door.

The final step to getting this spaceship off the ground is distributing the WiFi profile using Intune. Since I am forced to use the built-in RADIUSaaS server certificate, I need to add the Subject/SAN from that certificate to my configuration.

The WiFi profile is distributed using the Wi-Fi template.

The Wi-Fi type (1) should be Enterprise.
Wi-Fi name and Connection name (2) is set to the SSID as configured in UNIFI.
Connect automatically when in range (3) is set to Yes.
Authentication Mode (4) is set to Machine.
EAP type (5) is set to “EAP – TLS”.
Server Trust Certificate server names (6) is set to the SAN name from the RADIUSaaS Server Certificate.
Root Certificates for server validation (7) is the profile distributing the RADIUSaaS root server certificate.
Client Authentication Method (8) is set to “SCEP certificate”.
Client certificate for client authentication (9) is set to the profile distributing the SCEP certificate from Cloud PKI.

With this configuration, the devices should connect automatically to the new WiFi network. They will use the certificate issued from Cloud PKI for authentication, which RADIUSaaS should trust. The endpoints will also trust the certificate used by RADIUSaaS.

Proof Of Concept – Network Connected!

The irony in this setup is that the device needs a network to sync all the configurations from Intune. I was using the guest network for this initial onboarding. Once set, the computer automatically connected to my corporate WiFi authenticated with the Cloud PKI certificates.

I now have a certificate-based authentication for my WiFi using Intune Cloud PKI!

My Topology Of Components

My setup is now a mix of cloud and physical installations holding solutions from Microsoft and 3rd parties.

The drawing above illustrates how all of these components are connected.

Logs And Insights

Everyone is happy as long as the solution is running as expected, but the proper nerds also want to examine the solution’s logs and insights.

Intune Insights

Looking at the device in Intune, I can verify if the device configuration policies have been applied successfully to the device.

Looking at the configuration policies, I can find information on the policies that have been applied successfully.

Looking at the Issuing CA in Cloud PKI, I can see assigned certificates.

These are examples of some places in Intune where you can look for health states.

UNIFI Insights

Looking at the WiFi profile in the UNIFI Network configuration, I can see which devices are connected to the managed corporate WiFi network.

Clicking on the device will give me more insights into the network experience at the device.

Unifi has more Logs available for examination if necessary.

RADIUSaaS Insights

The RADIUSaaS portal has Logs available under the Insights menu blade. Here I can clearly see devices login in Ok.

Clicking the small arrows at the start of each line expands the information for easier reading and filtering. I can even see the data as JSON.

The Insights menu also has several graphs and insights to help see the service’s health state.

These reports and insights can be filtered using the KQL syntax. Those interested in advanced hunting and insights can export logs from RADIUSaaS to Azure Log Analytics.

Having the data in Azure Log Analytics will allow for further analyses using the KQL Kusto language

Final Thoughts

For many, 802.1x network authentications are seen as significant hurdles on the path from traditional operations to modern cloud-based operations. Fortunately, solutions exist, and I’ve previously tested many of the components mentioned in this blog. Now that I have access to the UNIFI network and Microsoft’s new Cloud PKI as part of the Intune Suite, I’m pleased to report that setting this up was relatively straightforward.

However, it’s not ideal that I couldn’t integrate certificates from Cloud PKI into RADIUSaaS. Nonetheless, there are ways to address this, and I believe there will be new opportunities in this area going forward. I’m hopeful that Cloud PKI will offer the functionality to apply certificates to services like RADIUSaaS. Maybe Microsoft will introduce their own integrated cloud-based Radius service that’s readily accessible?

In the era of perimeterless Zero Trust, network security details start feeling as important as choosing the perfect avocado—sure, it matters, but is it worth stressing over when you could be debating pineapple on pizza instead?

External References

• Microsoft Cloud PKI for Microsoft Intune – Microsoft Intune | Microsoft Learn
• Use SCEP certificate profiles with Microsoft Intune | Microsoft Learn
• RADIUSaaS Docs
• FreeRADIUS
• UniFi | RADIUSaaS Docs
• Extensible Authentication Protocol (EAP) for network access in Windows | Microsoft Learn