topic Limitations of Windows Supplicant with 802.1x in Network Access Control

Limitations of Windows Supplicant with 802.1x

chatataridge — Thu, 08 Dec 2016 16:57:23 GMT

The question is have is surrounding EAP Chaining and the use of the Any Connect NAM module vs the Windows Supplicant. The introduction of the Any Connect NAM could prove to be challenge in this environment, however customer would like to authenticate both the machine and user through Microsoft Active Directory. I have learned that without EAP chaining the machine has a tendency not to re-authenticate when the machine sleeps and then requires a reboot.

Since the customer engineers are currently comfortable with the Windows Supplicant I am looking for a creative way to authenticate both the user and the machine without deploying the Any Connect NAM. Using EAP-PEAP has some limitations within the Windows Supplicant (authenticate user OR computer). I have been labing policies leveraging Profiling to glean unique information about the devices to identify them as corp assets. I.e. Host name in the DHCP probe. While this is not as secure as the certificate issued by AD when the machine joined the domain this does offer a form of machine authentication that doesn't rely on the Supplicant to send both machine and user credentials.

My question is: How are others solving the limitations of the supplicants that do not support EAP-FAST for 802.1x wired and wireless deployments?

Re: Limitations of Windows Supplicant with 802.1x

Jason Kunst — Thu, 08 Dec 2016 18:53:12 GMT

The problem is that windows supplicant will only send the user credentials when you are in the user space. So if for some reason you went to sleep and your authentication expired then when it came alive it would not be able to send machine+user auth.

Another option is to use machine certs only and then redirect to a CWA portal for them to do the user authentication.

For future you can push Microsoft to support TEAP

Re: Limitations of Windows Supplicant with 802.1x

howon — Thu, 08 Dec 2016 19:29:46 GMT

In addition to what Jason noted, with profiling, ISE 2.1 added AD probe where existence in AD can be used to identify corporate assets. The profiling attribute is in profiling policy; ACTIVEDIRECTORY_PROBE -> AD-Host-Exists. Once you create policy with this to put matching endpoints to endpoint group, you can use that during authorization policy.

Re: Limitations of Windows Supplicant with 802.1x

chatataridge — Thu, 08 Dec 2016 20:37:21 GMT

howon

Thank you, I had not found this new profile policy attribute. I have a few more questions:

Will the AD probe work with wireless and wired clients?

What is the AD probe using to match the client to AD membership?

What Profiling services are needed? DHCP, HTTP, RADIUS, NMAP, DNS and SNMPQUERRY

Is there an aging timmer for profiled endpoint groups?

Would the expression read: AD-Host-Exists equals "TRUE"

Len

Re: Limitations of Windows Supplicant with 802.1x

chatataridge — Thu, 08 Dec 2016 20:40:45 GMT

Jason

Yes it would be great if Microsoft and Apple would deploy a supplicant that offers both machine and user credentials. I have suggested the CWA redirect, however they customer is looking for a solution that dosnt require end user interaction.

Len

Re: Limitations of Windows Supplicant with 802.1x

Shivaprasad Gudsi — Thu, 27 Sep 2018 15:00:50 GMT

Hi Expert,

I am also looking for some way to identify the corporate assets without using AnyConnect.

Please can you elaborate more on the AD probe and how to use it ?? whether in authentication or authorization.

Please help. Thanks in advance.