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.

8 Replies to "Workaround for wired device-authentication against Cisco RADIUS solutions"

  • Mattias

    This looks cool! I ran into the same problem that the end-user had to fill in the username. I was thinking about a similar solution, no need for that now… 🙂
    I must say we don’t have to fill in the “host/” part, only the computer account. Is the host the same as the domain?

    • Darren Wallace

      Hi Mattias,

      Thanks for the comment.

      The ‘host/’ is literally that, “host/”. It’s not a placeholder or something to be substituted.

      For example, if the FQDN of the client was “client01.test.com”, then the username, once injected, would be “host/client01.test.com”

      Hope that helps!

      Darren

  • Mattias

    YES! (sorry for the capitals, just so happy I found this).

    It seems to be possible to use variables in profile manager.

    So, what you do is: Create the profile as you described. But instead of using host/CHANGEME, you enter %AD_ComputerID%.

    And that’s it! It will automatically fetch the computer ID and use this for authentication.

    • Darren Wallace

      Hi Mattias,

      I’ve actually just completed a blog on payload variables for Jamf Pro (formally Casper) and Profile Manager.

      Just a minor correction, I’d need to use “host/%AD_ComputerID%” because the ‘Host\’ was the bit I needed ????

      Thanks for your comment!

      Darren

      • Mattias

        Probably it will work without the “host/” part. When we manually connect we have to enter the hostname followed by a $ sign. Also I found this in an Apple training I found online:

        User name. If using a password-based protocol, enter the user name that
        will be used to authenticate the device. If using TLS, the value entered for
        Username will be sent in response to an identity request, instead of a
        value from the identity certificate itself. If the value from the certificate
        doesn’t work properly for authentication, you may enter something like
        host/computername.domain.com or computername$.

        http://training.apple.com/pdf/WP_8021X_Authentication.pdf

        • Darren Wallace

          Hi Marrias,

          Aha that was the issue I was having. The customer’s Radius authentication solution required “host\[hostname]” 🙂

  • Hi Darren can you help us understand and answer the following questions?

    What RADIUS attributes are best suited for MAC clients to check whether a user is already domain authenticated.
    – Is there a method on MACs to force the machine to send its hostname in the RADIUS packet when performing PEAP-MCHAPv2 and EAP-TLS. Is there a best practice or Apple proprietary way to do this?

    • Darren Wallace

      Hi Aaron,

      Thanks for your message, but I’m afraid I don’t quite understand what you’re asking.

      As far as methods to test if a user is already authenticated for RADIUS, that will depend on your RAIDUS / Network configuration. At the client I worked with, if the client couldn’t authenticate to RADIUS, it wouldn’t get an IP address so that was quite simple!

      For Mac RADIUS, you can’t alter the packets that are sent without some sort of 3rd party interception tool. Additionally, to my knowledge, once a device is authenticated, you should be good.

      If this doesn’t answer your questions, I’d suggest you take a step back and explain what you’re actually trying to do or what issues you are having.

      Also, I’d strongly suggest joining the Mac Admins Slack (Free!) which is easier to work through these types of questions. Plus there currently are 11,237 others who can help!

      I hope that helps,

      Darren

Leave a Reply

Your e-mail address will not be published. Required fields are marked *