06-30-2022 06:25 AM
I am having a problem (ISE 3.0) where we are moving some of our PCs to be Azure AD joined only. As such I am losing access to the AD Probe built into ISE for profiling. Without this probe, the built in profile conditions classify my Windows 11 boxes as Windows XP and by policy ISE disables the port. Is there a way to have a probe that would use the Azure AD or Intune to supply information to the profile engine? Other work around ideas are welcome. Thanks
David
Solved! Go to Solution.
06-30-2022 03:29 PM
Using Profiler conditions like Windows version in your AuthZ Policies is problematic to begin with. These are easily spoofed and applications (like MS Skype for Business) have wreaked havoc in the past and resulted in erratic Profile changes.
A better approach would be to use active authentication like 802.1x EAP-TLS for your legitimate Corp Windows PCs and restrict access for everything else.
Moving to Azure AD Joined will reduce the options for authenticating the Windows endpoints. You can't authenticate a computer/user against AAD with EAP-TLS (even with the upcoming feature enhancement in ISE 3.2). The best you will be able to do is authenticate the Windows computer/user based purely on a valid and trusted certificate in ISE, then authorize based on other conditions like Intune MDM Registration/Compliance.
If this is the plan, I would highly suggest moving to ISE 3.1 ASAP to take advantage of the new MDM APIv3 with Intune. This will allow ISE to use the GUID for performing MDM checks against Intune as opposed to the 'legacy' MAC address based check. The latter obviously causes lots of issues with wired dongles/docks and random/changing wireless MAC addresses.
See Integrate MDM and UEM Servers with Cisco ISE for info on how to integrate Intune with ISE 3.1 using MDM APIv3 and the MS Graph API.
06-30-2022 07:01 AM
06-30-2022 03:29 PM
Using Profiler conditions like Windows version in your AuthZ Policies is problematic to begin with. These are easily spoofed and applications (like MS Skype for Business) have wreaked havoc in the past and resulted in erratic Profile changes.
A better approach would be to use active authentication like 802.1x EAP-TLS for your legitimate Corp Windows PCs and restrict access for everything else.
Moving to Azure AD Joined will reduce the options for authenticating the Windows endpoints. You can't authenticate a computer/user against AAD with EAP-TLS (even with the upcoming feature enhancement in ISE 3.2). The best you will be able to do is authenticate the Windows computer/user based purely on a valid and trusted certificate in ISE, then authorize based on other conditions like Intune MDM Registration/Compliance.
If this is the plan, I would highly suggest moving to ISE 3.1 ASAP to take advantage of the new MDM APIv3 with Intune. This will allow ISE to use the GUID for performing MDM checks against Intune as opposed to the 'legacy' MAC address based check. The latter obviously causes lots of issues with wired dongles/docks and random/changing wireless MAC addresses.
See Integrate MDM and UEM Servers with Cisco ISE for info on how to integrate Intune with ISE 3.1 using MDM APIv3 and the MS Graph API.
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