02-13-2023 06:50 AM
Hello!
I'm trying to provide a seamless Wi-Fi connection to our corporate Mac's. Currently to connect them to corp Wi-Fi network we have to create dummy AD accounts. I would like to remove this requirement and instead have them join based solely on the fact that they have the internal certificate from our CA (this is pushed via JAMF).
Currently we have a policy set in ISE for 802.1x - in the Authentication Policy we have a rule which has a condition of EAP-TLS which then links to a Certificate Authentication profile which specifies AD as the Identity store. This works perfectly for our Windows AD clients.
Is there a way I can add a new Authentication Policy into this Policy Set which will catch the Mac OSX devices, check the cert is valid and then permit access? If not, how would it be done alongside the Windows devices?
We have ISE 3.1.0.518 Patch 5
Thanks
Ad
Solved! Go to Solution.
02-13-2023 01:39 PM
Yes, you would need to use CAP that does not use an external ID store. For this use case in the past, I used certificate issuer match condition in the AuthC Policy. Ideally, the Macs would also use a certificate template with something unique in the certificate (like the OU field) to differentiate it from say Windows PCs also using EAP-TLS.
Example:
02-13-2023 07:33 AM - edited 02-13-2023 07:35 AM
For the authentication rule I don't believe you would need to add any additional rule to authenticate the macOS devices. However, for the authorization rule, if the current rule is conditioned to look at some attributes that are Windows specific, then you can just add a new one with some conditions that would be matched on the macOS devices, or, you can remove the Windows specific attributes and just look at the EAP-TLS and the issuer of the certificate. Also, if there is any different attributes that would be presented by the macOS devices during the authentication, then you can rewrite those attributes from the Advanced Settings tab under the external identity source of your AD.
02-13-2023 08:38 AM
Ok so I tried what you said, I added into the Authorization Rules an addtional rule which catches MacOS (the existing one is for AD) however, on checking logs, it doesn't get as far as the Authorization rules.
The Authentication rule which states EAP-TLS with the Certificate Auth Profile which has AD as the Identity store is hit, so the Mac fails authentication. Do I need to create a new Certificate Auth Profile which doesn't link to AD as the ID Store?
02-13-2023 01:39 PM
Yes, you would need to use CAP that does not use an external ID store. For this use case in the past, I used certificate issuer match condition in the AuthC Policy. Ideally, the Macs would also use a certificate template with something unique in the certificate (like the OU field) to differentiate it from say Windows PCs also using EAP-TLS.
Example:
02-14-2023 02:43 AM
Thanks, I'm going to add in a Condition that matches on the Certificate Issuer – Common Name. For the CAP, there is a profile already set up as follows;
Identity Store: [not applicable]
Use Identity From: Certificate Attribute - Subject - Common Name (I'm not sure what this means, can I leave this as it is?)
Match Client Certificate Against Certificate In Identity Store: Never
Thanks
02-14-2023 01:06 PM
"Use Identity From: Certificate Attribute - Subject - Common Name (I'm not sure what this means, can I leave this as it is?)"
This is what tells ISE which field in the certificate to use for identity, so it depends on what your certificate template looks like. If your cert template uses a username or computer name in the Subject - CN field of the certificate and that's what you want to see in the ISE logs, then you can leave that as is.
02-15-2023 02:12 AM - edited 02-15-2023 02:14 AM
Ok great thanks. One more question, by removing AD from the CAP - will this impact on the Authorization rules which specify AD Group the computer account needs to be? It currently look like this:
02-15-2023 01:40 PM
If the credential used for identity in the certificate (e.g. computer name) is not an active computer account in that AD group (which was your initial concern), then that 'AD Computer' AuthZ Policy rule will not be matched.
You would need a similar AuthZ rule as your AuthC rule that matches on the specific certificate attribute conditions.
03-02-2023 12:55 AM
Hi Greg - is it not the case that the would the AD Computer rule would not match therefore would be skipped then the Mac should hit the MacOS Rule? (Referring to above screenshot)
Thanks
03-02-2023 03:01 PM
Not likely. The only built-in methods for ISE to Profile a MacBook is using NMAP or User-Agent string. The former (NMAP) can be problematic due to the need to allow active NMAP scans from the ISE nodes to the clients. The latter (User-Agent) would only be possible when the client is redirected to one of the ISE PSN portals.
If MAC randomization is enabled on the MacBook, it would make profiling even more difficult since the parent Profile of Apple-Device would not even match. MacBooks do not provide any unique information to the network via DHCP (unlike Windows), so trying to Profile them is typically not feasible.
02-13-2023 08:47 AM
What the failure log says? could you please past it in here for review?
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide