@timkalee
Did you ever get this working? If so, care to share???

@joshuasee Would you be willing to share your full script?

Are those of you who've had success using local users or domain users?

I'd like to share what worked for us:

• Create /opt/.cisco/certificates/client/proflie
• Copy the .pem into the newly created folder (profile), and copy the .key to /opt/.cisco/certificates/client/
• Create an xml file to tell the app which cert to use, and place in /opt/cisco/anyconnect/profiles

Skip the Keychain altogether.

@tep would you mind elaborating a bit more on how you fixed this issue? What version are you currently using?

We're currently running v 3.1.05170. The workaround is basically to keep everything outside of the keychain, so you never get prompted. We added some verbiage to the configuration xml file with information about the cert:

<CertificateMatch>
<DistinguishedName>
<DistinguishedNameDefinition>
<Name>CN</Name>
<Pattern>Certificate Name</Pattern>
</DistinguishedNameDefinition>
</DistinguishedName>
</CertificateMatch>

Then, put the .pem and .key files in the locations noted above and viola!

Another issue we have been seeing...OSX system scan stuck at 10%

Anyone find a scriptable way to fix this? Were running into the same issue with Anyconnect version 3.1.06079.

For testing we've just given tester admin rights to their machines, but we can't do that when we deploy.

Has anyone had a response from Cisco for a fix?

Hey, all.

I didn't get to read all the responses, but we opened a case with Cisco. If we disable certificate checking on our ASA, the client should only require a user/pass and not a certificate, meaning it should stop asking users to authenticate to the system keychain each time it needs to connect to the VPN.

We are in the process of implementation, I will report back on whether or not this resolves us. If anyone else has access to try this sooner, let me know.

~SGN

Version 4.2 is out now and might have fixed some of these issues. I'm curious as to why you all are not updating to the latest release if you have Cisco maintenance agreements.

@mostlikelee would you be able to post your script and workflow using user based certs? We're upgrading to the 4.2 client and seeing the same issue. thanks in advance

@mapurcel I've been slacking, I'll have that up soon I promise!

So we have a work-around for this, not what I would call a a true fix. But essentially we changed our configuration profile for our AD to" allow access to all applications". This lets the Cisco app use the AD cert and doesn't prompt for credentials. Ideally I'd like to have it just allow Cisco app that, but right now you can't fine tune the configuration profile that well.

@roiegat

That's what we do as well, however AnyConnect always wants to first read the enrollment cert / private key that the JSS installs, and then the AD cert second, and we can't find a way to have AnyConnect look at the AD cert first and therefore not prompt to allow access.

Have you seen this behavior?

@tep

Hello tep, Can you please elaborate on the solution that worked for VPN Any Connect?

Any progress on this? We still see this issue in 4.2 as well.

We just had a user getting this same message now.

I have the same issue as well, Any fix on this ? Help

i'm running 10.11.6 and Cisco AC 4.3.00748 and have been running into this problem. our workaround has been to click deny 3 or 4 times until it brings up the login window. then the user is able to login successfully.

preliminary testing has shown to be working

Open up the system keychain, and under category select certificates. in my certificate system keychain i only have one private key. double click the private key, click access control, and select "Allow all applications to access this item". rebooted and no more prompts when opening up AC. so far this has worked for 3 machines, but still in preliminary testing stages.

hope this helps :)

update: i'm 4 for 4 with using this fix.

@john.martin

Open up the system keychain, and under category select certificates. in my certificate system keychain i only have one private key. double click the private key, click access control, and select "Allow all applications to access this item". rebooted and no more prompts when opening up AC. so far this has worked for 3 machines, but still in preliminary testing stages.

That's the only way we've been able to fix the issue. What's needed is a way to automate it or to allow access to the key by default.

ah, understood.

All.. After having been advised by Jamf support, I have created a feature request for setting the permissions correctly on the JSS client cert. Please vote it up:

https://jamfnation.jamfsoftware.com/featureRequest.html?id=5266

Fellas...

I have a solution for this!!!!

Like @tep, In our lab environment we have "fixed" this issue by configuring the AnyConnect profile that's pushed out by our VPN appliance to use "Certificate Matching." The only difference being...we keep the certs in the Keychain, not outside of Keychain elsewhere on the Mac.

By configuring the profile to do this, AnyConnect will only try and use certs that match a specific criteria that's dictated in the profile.

Our AnyConnect XML profile now has the following keys:

<CertificateMatch>

<DistinguishedName>

        <DistinguishedNameDefinition>

          <Name>ISSUER-DC</Name>

          <Pattern>ourdomaincomponent</Pattern>

        </DistinguishedNameDefinition>

      </DistinguishedName>

    </CertificateMatch>

Once this profile is download from the appliance, AnyConnect will only look for certs matching the issuer domain component entry in the cert, and it connected up right away...no keychain prompts!

While we use the "Issuer Domain Component" key, as we have a few different CAs, there are other keys you can use, and are dictated in the Cisco documentation below.

https://www.cisco.com/c/en/us/td/docs/security/vpn_client/anyconnect/anyconnect43/administration/guide/b_AnyConnect_Administrator_Guide_4-3/configure-vpn.html#ID-1428-00000555

Let me know if this helps you out!
@jwojda @waqas @mapurcel @RobertHammen @mostlikelee @aprild @jmartin99

@ooshnoo thank you for this information. Is there any way you could provide a bit more information in regards to ISSUER-DC and ourdomaincomponent key? Is the ourdomaincomponent supposed to be com.company.my? If I recall correctly the issue is the enrollment certificate from the JSS that causes this, correct? Anyway just trying to have all the info I can when I go and ask for this to be added. Do you know the particular file name or is it the connection profile for your particular VPN gateway?