Intune: Wi-Fi 802.1x, NPS, and user PKCS certificates (2023)

One of the things I dislike most about Azure AD joined devices on our corporate network (using NPS on Windows Server for authentication) is that entering my credentials on every connection is a poor user experience compared to, say, a traditional device-joined domain that can seamlessly authenticate per device or user. While there isn't really a way to replicate device-based authentication with Azure AD joined devices (in short, there's no computer object in AD for NPS to look up), you can configure things to use a user certificate.

There are some prerequisites for this:

• Wireless network with WPA2-Enterprise (or any variant that uses 802.1x)
• Active Directory domain already configured
• AD Certificate Authority already configured (Enterprise CA)
• User accounts synchronized with Azure AD
• NPS installed and configured
• Devices joined to Azure AD and enrolled in Intune
  

As part of this process, we set up a certificate template, installed the Intune Certificate Connector for Intune on a server of your choice, and created some configuration profiles.

Configuring the certificate authority

The first step is to set up a template on the CA server:

• Open the certificate authority console, expandcertificate templates, right click and select the folderAdministrator🇧🇷 This will open the certificate template console.
• Find themof the userCertificate template, right click and select itDuplicate.
• On the General tab, give the template a name, and on the Compatibility tab, set the Certification Authority to Windows Server 2008 R2 and the Certificate Subject to Windows 7/Server 2008 R2.
• On the Request Management tab, select the Allow private key export check box. This is required for the Intune connector to install the private key on the end user's device.
• On the Encryption tab, make sure the minimum key length is 2048.
• On the Request Subject Name tab, verify that Deliver is selected.
• On the Extensions tab, under Application Policies, make sure there are three entries: Client Authentication, Secure Email, and Encrypting File System.
• On the Security tab, add the server computer account you're using for the Intune connector with read and write permissions. Click Apply to save the template and close the console.
• Back in the AC console, right clickcertificate templatesand catchNew > Certificate template to issue🇧🇷 Select the template you just created.
• Finally, we need to allow the server to manage the certificates: open the CA properties and add the account of the server computer that will host the connector.Issue and manage certificatesmirequest certificatespermissions
• If you have not yet exported your root CA certificate, open the CA's properties, select the current certificate from the list, and click View Certificate. From there, you can go to the Details tab, click Copy to File, and export it as a Base64-encoded .cer file.
  

Install the certificate connector for Intune

We need a service account to run the connector, assuming you don't want it to run as SYSTEM. I haven't tested it as SYSTEM, but unfortunately the documentation isn't very clear on permissions; it basically says that it has to be an administrator account on the server, with rights to login as a service. If you're trying to put this on a domain controller, your only option is to add the account to the domain administrators group. Don't forget to configure login as a service directly in gpedit.msc.

Open the Intune portal and go toTenant administration > Connectors and tokens > Certificate connectors🇧🇷 Click Add and follow the link and instructions to download the installer.

Run the installer with administrator privileges on the server. Follow the steps and make sure you have at least PKCS selected in the list of features. At a minimum, you must select PKCS and Certificate Revocation.

After successfully completing and completing the wizard, you should be able to refresh the Certificate Connectors page and see your connector listed.

Deploy AD CA root certificate

You must install the root CA certificate from the Trusted Root Store on your end user devices. We can do this using a configuration profile: go to the Intune portalDevices > Configuration Profilesand click Create Profile. Select the platform (Windows 10+) and then Profile Type: Templates > Trusted Certificate. If you try to implement this on other devices, the profile type might be slightly different, but it should be obvious which one is a trusted certificate.

Follow the steps and upload the root CA certificate .cer file that you exported earlier. Complete the tasks as required and complete the wizard. In my case, I assigned this to a device group that contained my Surface devices.

NPS Network Policy

Assuming you already have a working 802.1x WiFi setup, you should at least have a network policy in NPS. Make sure that one of the authentication methods is "Microsoft: smart card or other certificate". You don't need to remove the other options: if you leave PEAP and strong password enabled, users will still be able to log in with their username/password as usual. We'll use a client-side configuration profile to force the client to use a certificate.

Check which certificate NPS uses to identify itself: Under Conditions > Authentication Methods, click the different options and click Edit. This should open a window indicating the current certificate. Having this issued by your AD CA makes configuring the profiles easier, but it doesn't have to be: mine is issued by DigiCert, so I need to get the root CA certificate used (DigiCert Global Root CA in this case ) and redo the steps above to deploy that certificate to the devices.

provide the certificate

Now we need to create a PKCS certificate configuration profile: go to the Intune portalDevices > Configuration Profilesand click Create Profile. Select Platform (Windows 10+) and then Profile Type: Templates > PKCS Certificate.

Complete the fields as follows; leave the default settings, except:

• Key Storage Provider - Login to KSP Software
• Certification Authority: The FQDN of the CA server that issues the certificates. This can be the root server or a secondary server (preferably secondary as the company's corporate root CA must be offline).
• Certificate Authority Name: The name that appears in the CA console, usually DOMAIN-COMPUTERNAME-ca
• Certificate Template Name: The name of the certificate template created above
• Certificate Type: User
• Subject Alternative Name: User Principal Name (UPN), Value: {{UserPrincipalName}}
• Advanced Key Usage: Client Authentication, Secure Email (these two can be added using the Preset dropdown), and finally Encrypting File System, 1.3.6.1.4.1.311.10.3.4. I'm not sure if you need the secure email and EFS entries here, but I had a lot of trouble getting the certificate to be automatically picked up by the Windows 10 device, and since they're in the certificate, they can be entered here as well.
  

Assign the profile to the appropriate groups (you can target a device if you want to select "all users on these devices"). Wait a moment for your devices to update their configuration profiles (or click Sync in the portal) and you should see your CA issuing certificates. If you open mmc and add the Certificates (Users) snap-in on a client device, you should see the certificate displayed on the device.

A quick note here: if your usernames and UPNs don't match, you may not be able to authenticate, ie H. Your pre-Win2000 username should match the beginning of your UPN. DOMAIN\myusername and[Email protected]

Creating the Wi-Fi profile

Go to the Intune portal nowDevices > Configuration Profilesand click Create Profile. Select the platform (Windows 10 and later) and then the profile type: Templates > Wi-Fi. Follow the steps and complete the following settings:

• Wi-Fi Type: Business
• WiFi Name (SSID): Your WiFi SSID
• Connection Name – The name displayed in Windows, usually the same as the SSID
• Automatically connect when in range: Yes
• Authentication mode: user
• EAP Type: EAP-TLS (this is the "Microsoft: Smart Card or Other Certificate" you saw in NPS)
• Server Trust: Certificate Server Names: The name of the certificate used by the NPS server, for example, radius.lab.katystech.blog
• Server Validation Root Certificates – Find the root CA certificate that issued the NPS server certificate (which you should have previously uploaded as a trusted certificate). If your server's certificate is from AD CA, use the AD CA root certificate.
• Client Authentication: Authentication Method: PKCS Certificate
• Client Certificate (Identity Certificate): Select the PKCS certificate profile created above
• Client Authentication Root Certificate: Select the previously uploaded AD CA root certificate
  

Complete the steps and assign them as needed. In my case, I assigned the surfaces to the group. While you can assign this to devices (as I did), don't expect this connection to work while no one is connected. A suitable certificate should already exist in the user's personal store; if no one is logged in, you probably expect SYSTEM to have a certificate.

testing your device

Now for the fun part (hopefully!): Make sure your device has some sort of network connection, e.g. connected through a port and synchronize with it. Wait a few minutes and verify that the profiles were applied successfully in the Intune portal.

You can verify that your certificate has been seen through the Certificates snap-in (within mmc.exe) or in PowerShellGet-ChildItem Cert:\CurrentUser\Mywhich should display a list of fingerprints and subjects.

The device must also have a wireless profile, which can be seen in Windows Settings > Wi-Fi > Known networks or by running itshow netsh wifi profileat a command prompt.

If you click the Wi-Fi connection menu in Action Center, you can connect to the network without entering any credentials and without confirming anything.

It doesn't work, help!

I had a lot of trouble getting this to work because of certificates. Make sure you have the correct certificate in the Wi-Fi profile. There are some troubleshooting methods you can use here:

• Export device profile - runnetsh wlan export profileto export saved profiles to XML, which you can review in a text editor.
• If you keep getting "Can't connect because you need a certificate to sign in," and you definitely have the certificate on your device, unassign the Wi-Fi profile from Intune and manually create it once the device has gone Wi-Fi. Fi profile: Go to Control Panel (control.exe, not new settings), Network and Sharing Center, Set up a new connection or network, Configure and edit advanced settings manually. Play around with it until the connection works or it throws another error.
• If you manually created a profile on the device, export it as soon as it works. Try putting the same settings in the Intune profile. You can verify this by re-exporting the profile after it has been applied to the device and comparing the two files. This allowed me to determine if I was using the correct CA certificate for server validation.
• Enable monitoring on the NPS server - run at command promptauditpol /set /subcategory:"Network Policy Server" /success:enable /failure:enableand check the security log in Event Viewer. You should filter this to only show NPS related entries. Try connecting again and hopefully you'll see something useful in the log.
• And finally, another niche case: If you can get NPS to forward billing packets to a filtering application to identify who is who, you can manipulate the attributes that NPS is passing. In my case we are using Fortigate and you cannot assign a UPN to a user, you have to provide a sAMAccountName/Pre-Win2000 login. By manipulating attributes, we can replace "@domain.tld" with an empty string. This only works if the first part of the UPN matches the sAMAccountName. This setting can be found in the connection request policy under "Attributes".
  

Other reading

• Use private and public key certificates in Microsoft Intune | Microsoft documents
• Certificate Connector for Microsoft Intune Overview - Azure | Microsoft documents