07-05-2017 10:06 AM
When using Microsoft Office 365 Exchange cloud service and posture on the switch, clients are getting a self-signed certificate warning from the switch. This is due to the application trying to be accessed by the client machine prior to posture completing. Is there a permanent way to fix this? When we used on-premise email, we denied the IP addresses of the servers explicitly in the posture redirect ACL but this is not a feasible solution now that this is maintained in the cloud. We have been told to put 'no ip http secure-server' on the switch but want to know if this will cause any issues with posture discovery or redirection? Is this expected behavior or is there a workaround?
Solved! Go to Solution.
07-05-2017 11:46 AM
Thanks for the input on this and the concern was if there would be an adverse affect if 'no ip http secure-server' was configured on the switch since it shows as optional in our Universal switch configuration guide. Configuring this command resolved the issue for the customer since the switch no longer intercepted HTTPS traffic and redirected it to ISE. After consulting with BU, it was confirmed the NAD does not have to intercept HTTPS traffic for AnyConnect posture to work correctly and HTTP is enough. Using the 'ip http secure-server' command on the switch is up to the customer.
10-30-2018 05:35 AM
You don't need HTTPS and you are redirecting too much traffic. Assuming you are not using the client provisioning portal to install AnyConnect Posture Module (you really shouldn't be), you only need to redirect the traffic used for posture discovery:
If you want to block traffic preposture use a DACL for that. My standard posture redirect ACL, assuming client GWs are .1 and their a 10.x.x.x network, is:
ip access-list extended POSTURE-DISCOVERY
permit tcp any 10.0.0.1 0.255.255.0 eq 80
permit tcp any host 72.163.1.80 eq 80
deny ip any any
That won't affect any traffic other than the GW and enroll.cisco.com traffic.
10-30-2018 09:27 AM
07-05-2017 11:12 AM
It sounds like you are temporarily quarantining endpoints that are not compliant which limits their access to email and other applications.
ISE cannot stop/prevent applications from trying to use the network - it can only authorize access based on the desired polices using enforcement on the switch. The resulting behavior and alerts in the applications is a function of the limited access.
Typically you want and need HTTP and HTTPS services ENABLED on the network device in order to capture :80 and :443 traffic and perform URL redirection to ISE for web-authentication or notification ("You have been quarantined because your OS/software requires updates...". Disabling these either HTTP or HTTPS services will prevent URL redirection on the respective port.
07-05-2017 11:46 AM
Thanks for the input on this and the concern was if there would be an adverse affect if 'no ip http secure-server' was configured on the switch since it shows as optional in our Universal switch configuration guide. Configuring this command resolved the issue for the customer since the switch no longer intercepted HTTPS traffic and redirected it to ISE. After consulting with BU, it was confirmed the NAD does not have to intercept HTTPS traffic for AnyConnect posture to work correctly and HTTP is enough. Using the 'ip http secure-server' command on the switch is up to the customer.
07-10-2017 10:14 AM
Correct HTTPS is not needed and is not recommended.
https://communities.cisco.com/thread/79494?start=0&tstart=0
In ISE 2.2 you are able to use posture without any redirection at all
You can tell the new clients to go to getmyagent.company.com when they first need to load the agent.
http://www.cisco.com/c/en/us/support/docs/security/identity-services-engine-22/210523-ISE-posture-style-comparison-for-pre-and.html
10-30-2018 04:31 AM
any solution for this issue.
it seems like ip http secure-server is a requirement for posture|client provisioning to work
I have disable https ( using no ip http secure-server), and after disabling it users posture is not working.
10-30-2018 05:35 AM
You don't need HTTPS and you are redirecting too much traffic. Assuming you are not using the client provisioning portal to install AnyConnect Posture Module (you really shouldn't be), you only need to redirect the traffic used for posture discovery:
If you want to block traffic preposture use a DACL for that. My standard posture redirect ACL, assuming client GWs are .1 and their a 10.x.x.x network, is:
ip access-list extended POSTURE-DISCOVERY
permit tcp any 10.0.0.1 0.255.255.0 eq 80
permit tcp any host 72.163.1.80 eq 80
deny ip any any
That won't affect any traffic other than the GW and enroll.cisco.com traffic.
10-30-2018 09:22 AM
Awesome Paul, I tweaked my redirect ACL as per your recommendation and its working like a charm.
Tanks for saving me some time and headache.
10-30-2018 09:27 AM
10-30-2018 09:18 AM
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