Cisco ISE 802.1x Authentication Options for MacBooks with JamF Cloud

[igaffine]

Hi all,

Hope everyone is well. I would appreciate if you could provide some options or typical approaches used for customers wanting to authenticate Apple MacBooks onto their wireless network.

One of our customers is currently provisioning home workers with MacBooks and using JamF Cloud to verify device compliance. The MacBooks are pre-built outside the office and shipped to the user.

I have been asked to look into options for attaching the Apple MacBooks to their office wireless network, when they return from lockdown.

Network Access Control is managed by our Cisco ISE deployment. and the wireless network currently has an 802.1x enabled SSID for internal devices, using EAP-TLS via the corporate MS AD and CA, and a guest hotspot wireless network deployed for Internet only access.

Ideally when the MacBook users return to the office we would like to use 802.1x (EAP-TLS), to give then secured access to internal services, but the customer ideally would like to avoid any onboarding process for the client, if at all possible.

Some initial thoughts:

Use the certificate provided from the JamF Cloud to authenticate MacBook onto Wi-Fi - As this will be a separate CA to our internal MS AD with CA, then the clients would require a copy of the internal MS CA root certificate and the ISE nodes will need the same from JamF. We would then need to understand how to authenticate against JamF.

I have heard about a JamF proxy function that somehow connects to the internal AD, so wondered if anyone has used that method.

Use ISE BYOD provisioning service and onboard the MacBook using the internal MS AD and CA. This requires the users to onboard their device, which is not favoured. 

Deploy a new Pre-shared Key (PSK) SSID to grant Internet only access and by integrating JamF Cloud to retrieve MDM compliance information, valid MacBooks would be applied a higher level of permission and be granted the necessary internal access.

Connect the MacBooks to the guest hotspot service and the user VPNs into the office, in the same manner as if they are working from home.

Appreciate your time reading this and providing any guidance.

Kind regards,

Ian

[Greg Gibbs]

There are a few caveats around this...

If the current certificate deployed by JamF Cloud uses the AD username in the subject (CN, SAN, etc), you could use that cert to authenticate them on the Wifi. It would require the ADCS Root chain that signed the ISE EAP cert to be installed on the client and the JamfF Root chain installed in the ISE Trust Store. You could then create an Cert Auth Profile (CAP) in ISE to use the credential from the cert and perform authentication against AD. You could then create an AuthC Policy with a matching condition of the cert Issuer Name (or other unique cert value) that uses the new CAP. Your AuthZ Policy could then match on the AD Group membership plus the cert Issuer Name (or other unique value) and have a condition to check the MDM Compliance.
If the current cert does not use the AD username in the subject, you might be better off integrating JamF Cloud with your ADCS via SCEP and having the user enrol a new ADCS-signed cert that includes their AD username. You could then create the same CAP and AuthC/AuthZ policies.

Either way, you would likely want to create the necessary profiles in JamF for the SSID name, required cert root chains and identity certs, etc. and publish them for the users via Self Service. The users should be able to perform the provisioning themselves prior to attending the site (from VPN, public wifi, personal hotspot, etc.) and the connection onsite should be pretty seamless.

As to your comment "We would then need to understand how to authenticate against JamF", the authentication happens against ISE. ISE uses the backend AD to authenticate and authorise the endpoint/user and uses the MDM API to check registration/compliance status. This communication is directly between ISE and JamF, so the client does not require network connectivity to JamF for this process.

[igaffine]

Hi Greg,

Many thanks for your reply. In terms of my comment "We would then need to understand how to authenticate against Jamf", I was thinking that if we were going to use the JamF Cloud as the location of the user accounts, so separate to internal MS-AD, then ISE would need to authenticate the users against it. In a similar way to multi-domain authentication, when CAs are different.

I will have a chat with the customer on your suggestion, as originally they did not want to install any internal certificates on the MacBook devices.

Also based upon what you have said, am I correct in thinking that a Policy Service Node can only have one active server certificate for EAP authentication?

[igaffine]

Hi Greg,

I have spoken to the customer and they have asked whether it is possible for JamF to use a device certificate for EAP-TLS, rather than a user one? I am not sure if this could work myself as the MacBook is not part of MS AD, therefore how would ISE be able to authentication against an non-existing device AD account. They are not happy about provisioning MacBooks with AD user account names in the certificates. We did wonder if a common/shared user account could be used as the subject of the certificate e.g. macbookuser'at'domain.com, and then we would check the MacBook against JamF MDM compliance.

Would JamF AD connector proxy improve our options?

Kind regards,

[Greg Gibbs]

To your question "am I correct in thinking that a Policy Service Node can only have one active server certificate for EAP authentication?", the answer is Yes.

I believe MacBooks can use a machine certificate, but this works much different than Windows which has separate and distinct Computer and User states. The documentation is pretty lacking on the Apple side. AD would likely not have the machine accounts, however, so you would only be able to authenticate the MacBook by checking that the cert is valid and trusted. There would be no additional check of the credential against an external directory.

As far as I can tell, the AD CS connector simply allows JamF to request a certificate from AD CS on behalf of the client. This would just be an alternative to SCEP.