Radius 1 Mac OS
Hi All. This blog is another in an ongoing recent theme I’ve been using; Customer Requests! (Maybe I should add a new tag for this type)
This time, I had a customer running device-based RADIUS (802.1x) authentication on their wired network.
Mac OS X Extras: Using Centrify and your Windows Infrastructure to provide 802.1x EAP-TLS to Mac OS X Systems Background Secure access to Wifi or Ethernet networks is a goal of any security conscious IT infrastructure team, however diversity of platforms makes this goal very hard to achieve, especially when organizations are looking to. Welcome to the FreeRADIUS project, the open source implementation of RADIUS, an IETF protocol for AAA (Authorisation, Authentication, and Accounting). The FreeRADIUS project maintains the following components: a multi protocol policy server (radiusd) that implements RADIUS, DHCP, BFD, and ARP; a BSD licensed RADIUS client library; a RADIUS PAM.
All options in the configuration profile appeared to be setup correctly and the device obtained its Active Directory (AD) certificate correctly and without issue.
However the device just sat there on “Authenticating…” without any change.
Deep dive time
After some further work with the customer’s RAIDUS team, we found a RADIUS log message similar to what Ben Toms mentions in his post, specifically:
“User not found in Active Directory”
It appears that the Mac client is presenting the certificate to the RADIUS server, as requested, but the request is being accepted as a ‘user-authentication’ request, rather than a ‘device-authentication’ request.
Due to this, the Cisco unit attempts to look up the authentication request against AD users and not computers, resulting in the “user” not being found.
Now Ben had a great work around of setting the NPS server to modify the incoming authentication request, to make it acceptable to the RADIUS server.
This was not something the customer’s Cisco ACS unit could do. Additionally, his issue was only seen by Ben on Mac OS X 10.8, where-as I was having issues with OS X 10.11.4.
Regardless, I worked with the customer’s AD team with the various options for certificate templates, with no resolution in sight (*sad panda*).
After some more digging on the client side, I found that if I kept cancelling and reconnecting the 802.1x connection in the “Network” System Preferences, I would eventually get prompted to select a device certificate and username for the connection.
If I specified the AD certificate (typically seen as the fully-qualified domain name of the client device), then entered “host/[fully-qualified domain name of the client device]” for the ‘username’ it would connect!
Success! or so I thought…
The Problem
There were three key issues with this solution that meant the problem was not solved satisfactorily:
- The initial connection required the entry of specific information and the use of the administrator username and password
- The RADIUS authenticated connection was not maintained nor auto-connected at the login window
- The RADIUS authenticated connection was not auto-connected after login, even when logging in as the same user account.
The Fix
As is the case with the newer OSes, 802.1x configurations can only be deployed in a configuration profile. This configuration profile does have a space for a username.
What if I manually specify “host/[FQDN]” for my test Mac, before deploying the profile?
Success! It works exactly as it should, with no end user configuration, and with automatic reconnection at both the login window and afterwards.
Problem #2
The next problem was how to make this dynamic enough that I can deploy the same profile out to all Mac devices and have it work?
Well, Configuration Profile files are simply xml files, files which can be manipulated with a script!
After a few hours, I had written a script that will:
- Pull the local hostname and figure out it’s fully-qualified hostname.
- Inject this into the appropriate place in the profile (replacing the “CHANGEME” text)
- Install the profile locally into the device.
The Script
As always, the script I’ve created can be found on our GitHub here.
The run through what each section does:
- Lines 50-54 – My previous ‘output to logfile and window’ function
- Lines 57-67 – Check that there is actually a profile at the location specified in line 31
- Lines 70-74 – Work out the fully-qualified hostname of the local device
- Lines 77-87 – Check that the fully-qualified hostname that has been found is legitimate (contains at least one . )
- Lines 90-102 – Replace the phrase specified in line 38, with the obtained fully-qualified hostname
- Lines 105-117 – Install the profile into the booted devices’ OS
- Lines 120-126 – Delete the now used ‘on-disk’ profile from the local OS.
- Lines 132-149 – Run the above functions
Script Requirements
As you can imagine, there are a few requirements to using the above script:
- The ‘username’ field must be “host/CHANGEME” in the EAP payload. “CHANGEME” will be replaced with the fully-qualified hostname.
- The profile has to be ‘unsigned’. I’ve not tested this with a signed profile but I imagine, as the script will edit the profile after its has been signed and before its installed, it will not work. If you produce a signed profile normally (certainly if you’re using Casper, and optionally if your using Profile Manager), then you can use our ‘de-sign config profile’ automator service available from here.
Radius 1 Mac Os X
Bringing it all together
Now to bring this all together!
- Build your normal RADIUS / 802.1x Ethernet profile in your MDM of choice. Don’t forget to add your certificates (both AD and server) and the “host/CHANGEME” username.
- Export / download this, and (if required) de-sign it as detailed above.
- Package this downloaded profile in your favourite OS X package creation tool
- To minimise modifications to the script, I’d suggest calling the profile “RADIUS template.mobileconfig” and deploying it to “/private/tmp”
- Add the script (mentioned above and linked again here) as a post-flight script to the package.
- Deploy the package to your required devices using your deployment tool of choice.
Gotchas
As with anything, there are always a few things to look out for!
- As this workaround requires making on-device changes to the profile, they can’t be deployed using an MDM solution.
- This does mean that users could remove the profile and no longer be able to authenticate against your RADIUS servers.
- Workarounds could simply be blocking access to the ‘Profiles’ System Preference, or as elaborate as only allowing non-RADIUS-authenticated devices to communicate with your management solution, and having checks in place to automatically reinstall the profile as required.
- Usual RADIUS requirements, such as:
- The device needs to be bound to AD to obtain an AD certificate
- The device needs to be able to contact your AD certificate server and the RADIUS servers when the profile is installed
- Ensure you have all the settings you need in the profile. I would also recommend checking out these guides and KBs:
- JAMF Nation – How to setup Machine-based authentication
- Apple – 802.1x Authentication
- Mac Mule – 10.8 CLIENTS NOT CONNECTING TO EAP-TLS WIRELESS WITH W2K8 NPS
- Mac Mule (Again!) – AUTHENTICATING 10.7 MACS TO A RADIUS SERVER WITH CERTIFICATE ENABLED PEAP AUTHENTICATION
- AFP548 – 802.1x EAP-TLS Machine Authentication in Mt. Lion with AD Certificates
Summary
There you go, hopefully that’ll give other Mac Admins a helping hand with trying to sort out RADIUS for their Mac devices. As always, if you have any questions, queries or comments, let us know below and I’ll try to respond to and delve into as many as I can.
Radius 1 Mac Os Download
The usual Disclaimer:
While the author has taken care to provide our readers with accurate information, please use your discretion before acting upon information based on the blog post. Amsys will not compensate you in any way whatsoever if you ever happen to suffer a loss/inconvenience/damage because of/while making use of information in this blog.