Closed Mode and Posture Check

[David-IT]

Hi everyone,

I'm facing some challenges while configuring Posture with closed mode and an IBNS 2 setup.

First, is it possible to perform posture checks in closed mode?

How did you manage port configuration and ACL/DACL settings?

• Should the ACL be used for redirection and the DACL for granting access?
• Did you configure VLAN access on the switch port settings or within the authorization profile?

My configuration seems to be working, but the PC never connects when booting while already plugged in.

Thanks for your help!

[MHM Cisco World]

But as I know posture not work with close mode you need low impact mode allow some traffic between client and ISE after posture success the client will get full access 

MHM

[Rob Ingram]

@David-IT yes you can perform ISE posture in closed mode, you just need to ensure the devices pass authentication - so ensure you have run monitor mode for a period.

Typically posture is only run when the user logins in, not when the computer is authenticating. What authorisation policy rules do you have configured?

You use the ACL pre-configured on the switch if you redirection based posture or use the redirectionless method, then you don't need the ACL. https://www.cisco.com/c/en/us/support/docs/security/identity-services-engine-22/210523-ISE-posture-style-comparison-for-pre-and.html#anc7

Yes, the DACL is applied post authentication. You can apply a different DACL, depening on whether the device is compliant or non-compliant.

Having multiple VLANs is an administrative overhead. I would typically rely on the switchport to define the VLAN, if you wish to restrict access then push down the DACL or use SGTs depending on posture compliance.

[David-IT]

Everything works well, especially when I disconnect the cable.
The ACL, web browser pop-up, and all checks confirm that everything is functioning correctly.

However, the main issue arises when I start the PC.
In this situation, the automatic check does not run, and even when I try to manually trigger the checks through the browser, I have error with agent is not detected.

[Rob Ingram]

@David-IT what policies have you configured? For computer / users etc - provide screenshots.

What is the state of "show authentication session interface gig x/x/x detail" when it fails and when it does work?

[David-IT]

Authentication is successful, but the workstation can't send its posture to ISE.

I get the error: "Cisco ISE unable to detect AnyConnect posture agent." on the workstation

Strangely, everything works fine after a shut/no shut action on the port. However, on the first boot, it fails at the switch redirect and doesn't let me pass this first step.

Thanks for your help.

ISE Version: 3.4
ISE Secure Client: 5.1.7.80

Extended IP access list ACL_REDIRECT
10 deny udp any eq bootpc any eq bootps
20 deny udp any any eq domain 
30 deny ip any host <cisco ise ip address>
40 permit tcp any any eq www 
50 permit tcp any any eq 443 
60 deny ip any any 

[David-IT]

After some troubleshooting, I discovered that my laptop was making two authentication requests during a cold boot. Although both requests used the same RADIUS username, the identities in the logs were different—one was hostname@domain.com and the other was host/hostname@domain.com.

I eventually disabled both options (Stateless Session Resume and EAP-TLS Session Resume), and the authentication became unique after a cold boot. Only one request, hostname@domain.com, remained, and the issue was resolved.

Any thoughts on what might have caused this?

[Aref Alsouqi]

I think the host/hostname@domain.com would come first because that would be belonging to the machine authentication and the hostname@domain.com would belong to the user authentication. The TLS session resume might have allowed ISE to use the cached information from the previous session, but tbh I don't think you should change turn off that. How did you configure the NIC for dot1x? and how ISE policies are configured? are you doing dot1x for both machine and users?

[David-IT]

I did some digging, and it turns out that simply enabling "stateless authentication resume" causes this issue.
It's quite strange and have simply removed this option.

(ISE issues TLS client a session ticket that can be presented to any PSN to shortcut reauth process)