Cisco Anyconnect 3.1.04072, 10.9, and Admin Credentials

[ImAMacGuy]

Anybody run into Anyconnect prompting for admin credentials when the user changes their password? Apparently when they change it, and launch A.C. it prompts to modify the system keychain. Any way around that? The users are submitting for admin rights in order to do this update, which they shouldn't be. I never noticed it in the earlier versions. There's a new 3.1.05something version out, I haven't had a chance to grab it yet though.

[dexterrivera]

I have packaged Cisco AnyConnect 3.1.05152 and have not seen that.

[ooshnoo]

We are using 3.1.05152 as well, and while we have not seen the issue described, we do see it prompting for to modify the system keychain when attempting to access a VPN that has certificate based authentication enabled.

We've engaged both Cisco and Apple support and have not gotten anywhere with either of them so far.

[ImAMacGuy]

we're seeing it too ooshnoo. I think that may also be the issue the users are seeing, after a support guy went to work with the user, he said they never had any setup done...

[ooshnoo]

One thing the Apple engineer did say is that there is no reason for AnyConnect to be doing this since all users and processes should have read access to the system keychain.

I suspect its an issue with AnyConnect.

[ImAMacGuy]

oddly, we have 2 vpn concentrators - 3 and 4. When I connect to 3 it prompts for the system cert... and then returns certificate validation failed. so I went to 4 and it prompts... and then lets me in... went back to 3 and it works...

[ooshnoo]

one way I just "solved" our issue was to allow all applications access to the private key of the local machine certificate. Of course how i could push out a shell script to do the same is beyond me since every Mac is named different, therefore no cert is named the same.

Regardless, I believe the issue you're seeing is that an ACL on some item in they system keychain is not set to allow all apps access.

[colonelpanic]

A quick google search did not help figure out how to change the application access on a private key. Has anyone else run into this issue and solved it?

[ooshnoo]

FWIW, I have a TAC case open with Cisco regarding this, which of course they're beating around the bush saying it's an OS issue.

[bentoms]

FWIW, I'm seeing the same using Palo Alto's Global Protect.

Every login gets a prompt for the "system keychain" & we're using cert based authentication.

Next week I can test on a 10.8 mac too.

I'll test our changing acl on the private key & will advise.

[bentoms]

Well this thread did me to enter the correct search terms in Google: https://live.paloaltonetworks.com/docs/DOC-5059

So, I'll try & see about scripting a solution.

Once done I'll post here & maybe it'll work for you guys?

I'll need the path of the anyconnect client & someone to test though.

[ooshnoo]

@bentoms

That is our workaround as well...the change the properties on the private key. I asked Apple enterprise support about a way to script it, but they said it's not possible given the fact that the cert on every machine has a different name.

But FWIW, here is the path to AnyConnect...

/Applications/Cisco/Cisco AnyConnect Secure Mobility Client.app

[ImAMacGuy]

I've got multiple private keys... how do I know which one is the machine certificate?

[waqas]

Running into the same issue with AnyConnect 3.1.05187 for Yosemite.

Has anyone found a permanent solution?

[mapurcel]

I'm also seeing this issue on Yosemite and the new client 3.1.05187

[guidotti]

I am not seeing this at all... We are using 3.1.05160.
Does anyone have a concrete answer why some are seeing this but not all?
I have users in 10.7, 10.8, 10.9, and now 10.10 using the same client.

[RobertHammen]

BTW, I ran into this at a client that was using machine-cert-based authentication and non-admin users.

The workaround was to (manually in Keychain Access, sadly):

a) allow AnyConnect access to the Private Key of the machine cert, and
b) allow AnyConnect access to the Private Key of the MDM cert

b) assumes that you are using MDM enrollment. Some people in high-security environments may not.

Regardless, once both private keys are allowed to be accessed by AnyConnect, the user is never prompted for admin credentials (unless the machine is removed from/re-added to mdm).

Doesn't look like there is any way to script this with the security command, but I'd love to be proved wrong...

--Robert

[waqas]

Thank you Robert for the latest update on this. It certainly resolves one issue, albeit via a manual addition to Access Control.

I'm also hoping for someone to share a scripted solution for this. That'll be heaven.

[RobertHammen]

I'm using the AD Certificate payload to get the machine certificate and install it on the machine. I could in theory allow all applications to access the private key of the machine cert, but that tends to make security teams unhappy ;-)

It may also be possible to script this via the Security command, however that would entail exporting the machine certificate/private key and re-importing it. I tend to prefer letting the AD Certificate profile handle obtaining and installing the cert/private key automatically...

[mostlikelee]

I believe I found a solution on this. Currently testing a scripted solution which is working for user based certificates, but the jist is this:

#get fingerprint from VPN cert
SHA=`security find-certificate -c $CERTNAME -Z | grep SHA | awk '{print $3}'`
VPNSERVER="yourserver"

#populate .anyconnect config file in user home
echo "<?xml version="1.0" encoding="UTF-8"?>
<AnyConnectPreferences>
<DefaultUser></DefaultUser>
<DefaultSecondUser></DefaultSecondUser>
<ClientCertificateThumbprint>${SHA}</ClientCertificateThumbprint>
<ServerCertificateThumbprint></ServerCertificateThumbprint>
<DefaultHostName>${SERVERNAME}</DefaultHostName>
<DefaultHostAddress></DefaultHostAddress>
<DefaultGroup></DefaultGroup>
<ProxyHost></ProxyHost>
<ProxyPort></ProxyPort>
<SDITokenType>none</SDITokenType>
<ControllablePreferences></ControllablePreferences>
</AnyConnectPreferences>" > ~/.anyconnect

AnyConnect uses ~/.anyconnect to determine which cert to use, if not populated it WILL search your keychains for available machine certs (including Casper's) and prompt for Admin access because it does not have ACLs for these certs.

Naturally you do need Anyconnect ACLs in whichever cert is authenticating, which I've only found when using the -T flag when importing. You might need to deploy a machine cert via script as i'm not sure this is available through config profiles.

I'll be posting my current workflow and script using user based certs as soon as I have some time :) :)

Hope this helps, been a headache here for a while....

[bainter]

@timkalee We use smart cards in our environment and getting hit with this issue. Do you know which certs it is looking for? The dialog reads:
"OS X wants to make changes. Type an administrator's name and password to allow this. OS X wants to use the 'System' keychain."

Thanks for your digging!

bainter

[waqas]

Hi Bainter,

For me, it was adding the Anyconnect app to the Access Control tab of the MDM cert (it's unique to every enrolled mac) and the user ID cert in the System keychain. Doing that suppressed the prompt.

[mostlikelee]

@waqas.s.khan The only way I found you can modify an existing cert ACL is manually. Have you found a way to automate/script that change?

@bainter I don't have a lot of familiarity with the smart card workflow in AnyConnect but I'll let you know if I come across anything

[joshuasee]

I'm also caught up in the access to the System keychain issue. Like others, I couldn't find a way to get at the machine certificate and key silently, so I tried a slightly different tack. Here are the ideas I came up with, which I offer as a source of inspiration and/or derision. Note the first two involve using a user rather than machine certificate to login with AnyConnect. I used @timkalee suggestions on creating the anyconnect preferences files, and Workaround 1 below to avoid admin prompts related to the keychain. This is still in testing, but it seems to work.

Workaround 1:
Load a config profile to create a user identity (cert/private key) in the users login keychain. The user can adjust access to items in their own keychain without being an admin. Right now, I install the profile with a script when the install AnyConnect policy is run. The script pulls the AD credentials from the computer and uses them as username and password in the config profile when requesting a user identity, which means the script doesn't have to ask the user for them.

Workaround 2:
As above, but request the identities for users with a non-corporeal AD account, such as an automated AD binding account. This means the config profile should be pushable via MDM rather than installed by a script, hopefully making the process less brittle. If you do this for all eligible users ahead of time, they can silently get an identity while on the local LAN, and then install AnyConnect when they feel they need it, even out in the wild. I may switch to this method based on feedback from initial testing.

Workaround 3:
You can downgrade the credentials required to make changes to the System keychain using the security authorizationdb command, then upgrade them back after the install. The user will still get prompted for admin credentials, but theirs will work even if they're not admin. I abandoned this method because of the additional scripting, security risks, and level of customer education/handholding required.

[mostlikelee]

@joshuasee How are you pulling AD user credentials via script?

[joshuasee]

AD computer credentials, not user. Oddly enough, you request an identity for one account with the credentials of another… and it works.

Note the name produced by the command below is formatted for authentication, with the $ lopped off, rather than being the actual RecordName for the computer

adcompname=$(dsconfigad -show | sed -n 's/$//g;s/Computer.Account.*.=.//p'); 
adpassword=$(security find-generic-password -w "/Active Directory/YourADHere" -s /Library/Keychains/System.keychain);

[ooshnoo]

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

[tep]

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

[tep]

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

[tep]

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.

[jhbush]

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

[tep]

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!

[jhbush]

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

[roiegat]

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.

[erikfulton]

Has anyone had a response from Cisco for a fix?

[sanaumann]

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

[bradtchapman]

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.

[mapurcel]

@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

[mostlikelee]

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

[roiegat]

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.