Configuring EAP-TLS Wireless connections on macOS with Jamf
June 23, 2019 Leave a comment
After procuring a new Ruckus Wireless network to replace our soon-to-be EOL Aruba equipment my attention turned to simplifying the current setup in preparation for the changeover. One of those tasks involved moving to policy-defined Wi-Fi connections for our internal devices.
eduroam for organisation owned devices
After configuring eduroam for BYOD I was intrigued by the possibility of using the same SSID to also onboard our college-owned devices; a mixture of Windows 10 domain-joined laptops and MacBooks on macOS Mojave. Now we have Jamf Pro fully operational the task looked much more manageable.
I decided to look into certificate-based authentication (EAP-TLS) to achieve this. All the information to do this with AD CS and macOS devices is out there but it’s a bit scattered so this post aims to bring it all together in one handy step-by-step guide.
Jamf Pro AD CS Connector
We’re using Active Directory Certificate Services (AD CS) to issue certs to our devices using an auto-enrollment policy. You have two methods to do this; either use the original Jamf payload or the new Jamf Pro AD CS Connector. We don’t have SCEP \ NDES enabled on our CA (which appears to be required for the older Jamf AD CS method) so the Connector looked a better option.
https://docs.jamf.com/technical-papers/jamf-pro/integrating-ad-cs/10.6.0/Overview.html
https://www.jamf.com/jamf-nation/discussions/29230/what-is-ad-cs-connector-used-for-what-is-it-s-purpose
The latter has the advantage that the machine in question doesn’t need to be directly connected to AD CS to renew its cert, which could prove useful in future as well.
https://docs.jamf.com/ad-cs-connector/1.0.0/Installing_the_Jamf_AD_CS_Connector.html
https://www.sysopnotes.com/archives/jamf-adcs-setup/
Setting up the link between Jamf and AD CS
When running the installation the PowerShell command will look something like
PS C:\Jamf\adcs-connector-1.0.0\ADCS Connector> .\deploy.ps1 -fqdn youradcs.internaldomain.co.uk -jamfProDN jamf.yourdomain.co.uk -cleanInstall
- youradcs.internaldomain.co.uk is the DNS name of your AD Certificate Services server
- jamf.yourdomain.co.uk is the DNS name of your Jamf Pro server
The Jamf instructions above are pretty simple for the first part of the installation but pay attention to some key points below:
- the Jamf Pro AD CS Connector will only work on Server 2016, don’t even try it on anything older!
- check, check and check again that you’ve saved the “Client cert keystore password” generated by the PowerShell script before continuing
- when you configure the CA details in Jamf Pro make sure you use the name of the CA as it is displayed in AD CS
this is really easy to miss as the instructions aren’t particularly clear, note the setup as per the YouTube walkthrough below
(use this link to skip to the relevant section about naming the CA https://youtu.be/oRkpkN1Z3aI?t=612 )
Credit to Daniel MacLaughlin for making this and highlighting the key points 🙂
AD CS Certificate Template
If you already have a certificate template deployed for your Windows machines don’t try and re-use it for the Jamf Pro AD CS Connector. You need different settings when deploying with the AD CS connector as Jamf Pro will be requesting the certificates rather than the Computer itself.
Certificate Subject Name must be set to “Supply in the request”
Jamf server’s Computer Object in Active Directory needs to be given rights to Enrol \ Auto Enroll
Configuration Profile
Now go into Jamf and build a Profile to push out to your devices.
This part is important! You need to have all these elements defined within the same Profile for it to work!
- Certificate to be generated from AD CS
- Root CA for AD CS
- Root CA for RADIUS server
(if different to AD CS Root, which was the case for our eduroam profile) - Wireless network payload to actually make the connection
Defining the Certificate Payload
Enlarge the image below to see the Certificate payload more closely. You’ll see where I named the PKI CA wrongly at first but even after changing it to the proper CA name the UI doesn’t update. Still works though, which is the main thing (!)
Certificate subject is CN=$COMPUTERNAME.yourinternal.domain.co.uk
SAN name is $COMPUTERNAME.yourinternal.domain.co.uk
It appears having the SAN defined is important for the next part when you define the Wireless connection Payload.
Defining the Network Payload
When configuring the Wi-Fi connection Payload itself the next part is absolutely crucial. All credit to sbirdsley on Jamf Nation for this vital bit of info:
https://www.jamf.com/jamf-nation/discussions/27058/eap-tls-certificate-based-wifi-authentication
The username must be defined as follows or the connection will fail:
host/%ComputerName%.%AD_DomainNameDNS%
Also note the Identity Certificate you supply in the Network Payload must match the one you enter in the Certificate Payload. It’s on a dropdown so should be easy to match but if you have multiple entries be careful to pick the correct one.
Obviously, you’ll also need to set WPA2 Enterprise and TLS in the Security Type and Protocols sections.
Deploying the Profile and troubleshooting errors
Once saved the Configuration Profile should apply quickly.
Note: you will need to reboot for the connection to take effect. I’ve read elsewhere that the certificates are deployed to the System Keychain, which only connects at startup and if you try to manually connect once already logged in you’ll get errors as the user doesn’t have access to the required certificates.
Another common error you may see in the Jamf logs if the profile doesn’t apply successfully is this:
Unable to retrieve AD CS certificate for profile payload
If you receive this error double-check the name you entered in PKI settings when defining the AD CS server. If this doesn’t exactly match the name of your Certificate Authority (note this is the name of the CA itself, not the name of the server on which it’s installed) the profile won’t work.
DEP users beware
Also a further note for those deploying new machines via DEP. Because Configuration Profiles apply pretty much as soon as they possibly can there is a possibility you’ll get a certificate generated too early in the process with the wrong machine name i.e. “Administrator’s Macbook Pro” or something along those lines.
The best workaround we have for that so far is to name any manually-enrolled machines before starting the enrollment process and for brand new machines run machine naming as early on in the deployment process as possible. If you get a failed Wireless connection on a newly-enrolled machine check the certificates list in AD CS for any wrongly-named certificates. Revoke them and try again.
NPS logging
During the initial setup and troubleshooting process I found that our RADIUS server wasn’t giving me a great lot of detail from the default log files that get created by Windows NPS.
Turns out you can get a much more readable version in the Event Viewer by manually enabling some additional Audit Log settings – thanks Mike Nowak for the tip!
https://www.mikenowak.org/nps-authentication-events-not-showing-event-log/