ISE 802.1X authentication with MacOS

[reynaldolopeza]

Hi to everyone,

We have ISE 2.4 deployed as Radius server for Windows clients in Wired and Wireless 802.1X authentication working with no problems for more than 1 year. We are using EAP-FAST with EAP-Chaining and MSCHAPv2 for user and machine authentication and NAM client.

Now we have new MacOS Laptops in the company and we want to authenticate them using the same protocols and Policies that we use for our Windows clients, we confirmed that NAM is not supported for MacOS .Is it possible to use the same policies and protocols that we use for windows in our MacOS clients using the native MacOS 802.1X client.? We don't have much experience with MacOS so if you have any guide to configure the MacOS native 802.1X client I would really appreciate it.

[Greg Gibbs · Accepted solution]

See a related conversation here:

https://community.cisco.com/t5/network-access-control/machine-user-auth-for-mac-osx/td-p/3471203

EAP Chaining with NAM technically uses EAP-FASTv2 which is Cisco proprietary and only available via the NAM client, which is not supported in OSX. To perform EAP Chaining on OSX, you will need to wait until Apple supports TEAP (RFC 7170) in their native supplicant for standards-based EAP Chaining and use ISE version 2.7 or later.

All current versions of OSX use Network Profiles (in XML format) for configuring 802.1x and the necessary certificates. Most large customers use JAMF Pro or some other MDM to create and deploy the necessary Profiles, enrol the certificates, etc. OSX does not have native capability to join an AD domain either, so you would typically rely on either PEAP-MSCHAPv2 user authentication or EAP-TLS with system and/or user certificates.

[milsystems]

I know this is a pretty old thread, but @Greg Gibbs, the following is not true:

All current versions of OSX use Network Profiles (in XML format) for configuring 802.1x and the necessary certificates. Most large customers use JAMF Pro or some other MDM to create and deploy the necessary Profiles, enrol the certificates, etc. OSX does not have native capability to join an AD domain either, so you would typically rely on either PEAP-MSCHAPv2 user authentication or EAP-TLS with system and/or user certificates.

Mac OS systems can absolutely be AD joined, and valid device certificates can absolutely be issued to them by MIcrosoft AD Certificate Services. I have several environments where we are doing this - with a number of different MDMs - for both wired and wireless 802.1x using EAP-TLS.

[Greg Gibbs]

Please feel free to write something up about how you have done this within your environment to share with others that are looking to do the same.

From my experience working with large enterprise customers including global finance and service provider verticals, those organisations have not commonly integrated their Mac OS systems with AD and have leveraged JAMF Pro to enroll certificates (via SCEP proxy to AD CS on the backend).

[Glenn Kerr]

The old when will Apple support EAP Chaining dilemma. Frustrated us for YEARS too. Just sharing what we do in case it helps anyone.

Our environment - Windows and Macbooks, Cisco Trustsec infrastructure, mix of traditional network and SD-Access. ISE playing pivotal role, running v3 now but this also applied to later 2.x code for us.

Our Windows fleet has Anyconnect + NAM, configured for EAP Chaining, works splendidly for identifying a trusted computer on boot up, and then when a user logs on, reauth-ing to get a user-based AuthZ profile from ISE to elevate to user-centric permissions. We aim to do this for Macbooks and their users too.

Macbooks- Ours are not joined to the domain, but do have a machine certificate installed via our MDM.

ISE Policy Logic for Wired authentications

We have all our EAP Chaining policies at the top that Windows + NAM computer hit. Then, ..

Macbook AuthZ policy #1 - can't match EAP-Chaining policies, so next in our ISE policy sets we look for Dot1X authentication (machine certs) that have been issued by our PKI. Our Macbooks configured via MDM to present our machine-certs on LAN. If matching this ISE policy, we redirect to a portal on ISE (same technique for guest wireless portal).

Macbook AuthZ policy #2 - User logs into CWA portal. You can then match the user ID entered into the central web auth portal to an AD group. The policy looks like CWA-CWA_ExternalGroups EQUALS (YourOrgActiveDirectory:yourorg.net/Domain Users)

And obviously, in the policy set, #2 has to be above #1 for it to work in the correct sequence.

We build on that logic by having policies per department/division, and each get a AuthZ policy and different SGT. Isn't limited to Domain Users.

Because the machine presents our cert, can can assume its one of ours. And because we can stitch together the user ID (gleaned from the redirect to the portal with the previous match of policy that got them there), we kind of get the same functionality as NAM+EapChaining - but much less elegantly. It's not transparent like Windows + NAM, and any time the Macbook Ethernet goes down, another CWA logon has to be performed. Not great for the user.

Notes/Feedback:
- It's a poor user experience for the Macbook users. Not many on them are a fan of it. They've put up with it so far, but its unpopular.
- CWA Dictionary in ISE has limited options so don't expect a full set of attributes you can match.
- In Macbook AuthZ policy #2 above, "YourOrgActiveDirectory" is the Active Directory you've configured in ISE in the External Identity Sources. And "yourorg.net" is your active directory name. And "/Domain Users" is a group you've got in ISE from your AD that you can reference in policy.
- Our Macbook users may hate us. Secops are happy with the solution. This is a technical solution, not a user experience solution.

- Works for us with docking stations or Ethernet dongles
- If Macbooks are joined to the Active Directory domain, there's apparently a way to use the passive identity scraping as an alternative method to achieve the same.

- If you can get access to an Apple Account Manager, please pile on the pressure and request them to support EAP Chaining.

HTH

[Faramarz]

Hi Glenn,

Great explanation of how you implemented the workaround. We have the similar issue with JAMF Pro integration with ISE. We are not planning to pay for JAMF pro external MDM integration.

Just wondering whether you still use this workaround or Apple support the EAP chaining. Our MacBooks are not joined to the domain, but do have a machine certificate installed through AD CS on the backend.

Also, can you please elaborate more about those two policies you mentioned above?

Thanks a lot.

Cheers,

Faramarz