Posted on 7th July 2016 by Darren Wallace

Workaround for wired device-authentication against Cisco RADIUS solutions

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.

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.

RADIUS - Authenticating

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.

RADIUS - Select a certificate

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!

RADIUS - Enter connection details

RADIUS - Connected

Success! or so I thought…

The Problem

There were three key issues with this solution that meant the problem was not solved satisfactorily:

  1. The initial connection required the entry of  specific information and the use of the administrator username and password
  2. The RADIUS authenticated connection was not maintained nor auto-connected at the login window
  3. 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.

RADIUS - EAP 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:

  1. Pull the local hostname and figure out it’s fully-qualified hostname.
  2. Inject this into the appropriate place in the profile (replacing the “CHANGEME” text)
  3. 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.

RAIDUS - change me

  • 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.

Bringing it all together

Now to bring this all together!

  1. 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.RADIUS - username in profile
  2. Export / download this, and (if required) de-sign it as detailed above.
  3. Package this downloaded profile in your favourite OS X package creation tool
    1. To minimise modifications to the script, I’d suggest calling the profile “RADIUS template.mobileconfig” and deploying it to “/private/tmp”
  4. Add the script (mentioned above and linked again here) as a post-flight script to the package.
  5. 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!

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.

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.