Cisco Anyconnect 3.1.04072, 10.9, and Admin Credentials

ImAMacGuy
Valued Contributor II

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.

68 REPLIES 68

dexterrivera
New Contributor III

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

ooshnoo
Valued Contributor

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
Valued Contributor II

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
Valued Contributor

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
Valued Contributor II

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
Valued Contributor

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
Contributor

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
Valued Contributor

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
Release Candidate Programs Tester

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
Release Candidate Programs Tester

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
Valued Contributor

@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
Valued Contributor II

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

waqas
New Contributor III

Running into the same issue with AnyConnect 3.1.05187 for Yosemite.

Has anyone found a permanent solution?

mapurcel
Contributor III

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

guidotti
Contributor II

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
Valued Contributor II

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
New Contributor III

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
Valued Contributor II

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
Contributor

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
Contributor

@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
New Contributor III

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
Contributor

@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
Contributor III

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
Contributor

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

joshuasee
Contributor III

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
Valued Contributor

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

tep
Contributor II

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

tep
Contributor II

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

tep
Contributor II

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
Valued Contributor II

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

tep
Contributor II

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
Valued Contributor II

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

57ce52d9c73d4149872b93e42cae53ba

roiegat
Contributor III

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
New Contributor

Has anyone had a response from Cisco for a fix?

sanaumann
New Contributor III

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
Valued Contributor II

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
Contributor III

@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
Contributor

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

roiegat
Contributor III

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.