ISE 2.4 Posture Client not meeting requirements

[stuart.pannell]

Hello all great gurus of ISE. I am currently testing a 2.4 build using 802.1x and windows 10 clients. I am using the AnyConnect NAM and posture agents and everything looked like it was running smooth until my customer tried to connect to the network the other day. They couldn't connect and rebooted their Windows 10 Client a number of times and eventually was granted access.

Now the way we allow access is: -

1. Are you a domain computer (802.1X using PEAP-TLS and Machine certificates) if yes then place in login VLAN ready for users and apply access-list on the WLC to allow access to AD, DNS and WSUS services

2. Are you a Domain User - Yes run posture check - AM Application and Updates and Windows Critical updates if all 3 pass posture then vlan switch to user vlan and allow access.

now according to the customer they didn't even have windows updates services turned on since the device was built so how could (According to the ISE Logs) the user pass posture? It failed a number of times prior to allowing access. Is there a setting somewhere that allows a number of attempts before doing something else i.e. grant or deny access?

[Colby LeMaire · Accepted solution]

There is no setting like that.  In the posture report for the endpoint, it should show you the details of which individual checks passed, failed, or were skipped for whatever reason.

Now just some thoughts on your setup.  If you want to do both machine and user authentication, then you should use EAP-Chaining.  You are already using the Anyconnect NAM, so you are most of the way there.  The reason is that without EAP-Chaining, there is no way to tie the machine and user authentication together.  So imagine the scenario where a user is already logged into their laptop when they connect to wireless.  Only the user credentials would be presented.  And if you are doing only username/password (i.e. PEAP) for the user, then someone could gain access with a non-corporate PC.

Also, VLAN switching is not recommended for user PC's.  When you first connect, you are assigned to one VLAN and get an IP from that VLAN.  Then after you meet requirements, you are switched to a new VLAN and get a new IP.  That can break things like GPO updates, drive mappings, and login scripts.  The recommendation would be to use dACLs/named ACLs to control access during the transition from not compliant to compliant.