04-12-2015 01:52 AM - edited 03-10-2019 10:37 PM
Hi everyone
We are running a Cisco ISE Version: 1.3.0.876 Patch 1 for 802.1X deployment (Wired + Wireless) with posture assessment where the supplicant for the endpoint is Cisco Anyconnect Secure Mobility Client v4.0.00061.
Symptoms:
The Configuration is working fine both Wired and Wireless, but the issue is that some user suddenly start to have issue connecting Wireless with the Cisco Anyconnect dislpaying System Scan: Bypassing Anconnect Scan
(Some info are masked)
and When I digged into this found that the configuration.xml files in the path: C:\ProgramData\Cisco\Cisco AnyConnect Secure Mobility Client\Network Access Manager\newConfigFiles is renamed automatically into configuration_bad.xml.
Workaround:
Question:
So was wondering if anybody has a clue why this configutatyion.xml turned into bad??
I'm goin to dig into the Event Viewer for logs about this before going to Cisco TAC
05-28-2015 01:02 AM
Just In case if anyone is facing the above issue, it seems to be resolved.
Mostly that happens due to the Endpoint doesn't match any of the Client Provisioning Policies in Cisco ISE which in this case Cisco ISE will instruct the Endpoint to use Cisco NAC agent for Posture and accordingly the Cisco Anyconnect Stop the posture phase. what that translates into is that the Endpoint will be stuck at the Posture UnKnown state Authorization rule (access granted will depend on your configured Authz Policy) in my case was very limited access.
The Reason why the endpoint was not hitting any of the Client Provisioning Policies still unknown.
So basically I was pushing Anyconnct configurations attribute if the following are true:
Windows All -------- user part of Domain users + NAS-Port-Type = Wireless –IEEE802.11
After isolating the NAS-Port-Type Condition I was matching under this policy, the issue disappear so far. It seems that some time the WLC was not sending this attribute to Cisco ISE or dropping it.
07-07-2015 02:09 PM
Hello, my friend you solved the problem? I have the same problem with a Windows machine 8.1
08-10-2015 12:30 AM
Hi Marcovrg33
As I stand now, This is mainly due to Client provisioning not being matched.
Well the reason why it is not getting matched is still vague.
Mostly now this issue stopped appearing in my Setup after clearing all the conditions that where inside the Client Provisioning policy I configured, Leaving anyone that Passes AuthC and AuthZ to get Client Provisioning policy (Don't think of it as security breach as in my case it was actually a redundant check against Wired/Wireless and AD membership)
So Basically I had two rules for Client Provisioning pushing the same anyconnect configuration.
Wired
Operating Sys Conditions Result
Windows All User part of Domain users
+ Anyconnct Config
NAS-Port-Type = Wireless –IEEE802.11
Wireless
Operating Sys Conditions Result
Windows All User part of Domain users
+ Anyconnct Config
NAS-Port-Type = Wired
and the issue happened to my customer only for wireless clients and not wired so after removing one condition and monitoring for a while it did happen again and now removing both and issue didn't happen so far.
now the rule looks like this
Operating Sys Conditions Result
Windows All NA Anyconnct Config
Actually the TAC case is still opened for the same and they couldn't find root cause for the same till now.
If you have the same issue, Try not to match any condition like I lastly did and see.
hope i clarified this issue to you
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: