Any luck with this? I opened up a ticket with apple enterprise support for some help here. You are able to use security import with the -T flag to specify applications, but I have yet to find a way to modify ACLs on existing keys.
You can do it from security, but you need to include the -U flag to indicate updating an existing keychain item.
The only problem is I believe it will always require the end user to authorize the change to the keychain item with a dialog that pops up. Its a security thing, to prevent applications from granting themselves access to your keychain items without you knowing it. Even when done as root it pops up a dialog with something like "security wants to change access permissions of the <name> item in your keychain."
I have only tried this in tests, and I was testing with a simple generic password keychain item. I wasn't attempting to modify a cert/private key.
IOW, I created a simple generic keychain item directly in Keychain Access, left the default ACL setting of "Confirm before allowing access" and no applications added to the list.
I then ran a command using security with the -U flag to update the keychain item by its label, and the -T flag with the path of the application to grant access to it, and I get prompted in the GUI to allow the change and enter my password. If I authenticate, it successfully adds it in. If I cancel, it leaves it as is. So it works, but can't be done silently.
Again, I believe I understand the reasoning behind this and it makes perfect sense. If it wasn't this way, an app you download could ask for your credentials and then silently grant itself access to any keychain items it finds in your login.keychain and be able to read them at will, including any passwords, account names, etc. Perfect way for malware to steal your information. Not good. So I get why Apple doesn't allow that.
@kboparai1 I found a couple workflows that work well when running as root for modifying the user keychain without prompt. I'll post them as soon as I "generify" the code, but they all involve removing and re-adding/importing keychain items with the proper ACLs. There's another post floating around on jamfnation where I posted code on finding the SHA on a certificate's private key to populate the AnyConnect config file if that's one of your issues.
That would be greatly appreciated, @timkalee!
My situation is that we would like to add two applications to the jss private key for another layer of security when accessing our VPN. This will allow us to only let computers with the jss private key/certificate to access our data center.
Doing the task manually is easy enough.. find the private key in the system keychain, head to the access control tab, hit the + and add the applications we want. It would be ideal to script something like this but so far, my research is coming up short...
@typeraj this is the workaround to get past the unlock System Keychain . https://live.paloaltonetworks.com/t5/Management-Articles/GlobalProtect-Requests-System-Keychain-Access-on-Mac-OS-X/ta-p/53332
Now I need to find a way to script this work around. Any help would be appreciated!
The below keychain would be the keychain you would allow access to the pan.gps file.
Same issue over here. Every time a new machine cert is issued GlobalProtect wants to access it, doesn't have permission, and requires us to manually enter admin credentials. It's easy enough to do through the GUI but it's definitely a pain that the user's VPN breaks every time they get a new cert.
@typeraj & @buckybadger At this time, there is no way to assign or provide access to a private key in the keychain programmatically if the cert/privkey already exist in the keychain. As suggested above by @mostlikelee, you would have to export the cert/privkey then reimport while providing access in the import command.
Something like this:
Export security export -k /path/to/users/keychain.keychain -t identities -P 'password here' -f pkcs12 -o /output/path/here.pem Import security import /output/path/here.pem -k /path/to/users/keychain.keychain -T "" -T "/Applications/GlobalProtect.app/Contents/Resources/PanGPS"
@buckybadger What you need to do is deploy the your company's Root.CA cert to the user login keychain, once you do that it should not prompt for a admin username and password. Where I am having issues is doing that via script since we do not have Jamf in our environment the script part is failing for me. I was able to test this out throughly on my test machine and exporting the cert from the System keychain and then import the Root.CA cert to the user login keychain.
I'll apologize in advance as I spend most of my time on the PC side of things so my total knowledge of how Keychain works is probably rudimentary at best.
When our CA issues a new machine certificate out to an endpoint how would having our root cert in keychain change the "Access Control" settings for the new machine cert?
That's ultimately the problem we have - by default the new machine cert comes into OSX with "Access Control" set to "Confirm before allowing access" and since we don't give our users admin rights they get stuck trying to allow the Global Protect client to access the new cert. In this environment we require the Palo Alto to check for a valid machine cert from our CA before the connection can continue so the VPN client has to be able to access the private key on the cert.
Ultimately I need a programmatic way to either default the private key access control to "Allow all applications to access this item" or figure out a way to add Global Protect to the list of allowed applications.
@buckybadger, how are you issuing the certs? Our AD certs are requested by a configuration profile, and there is a checkbox for AD cert payloads to make the private key accessible to all apps.
As far as I know, it's impossible to change the ACLs programmatically after the cert is imported.