Proxy prompts for Keychain Access - Mavericks and Yosemite - Automation possible?

look at the man page for security.

EDIT: just noticed the -U switch.

I would have a script that runs at login to see if the user already has a keychain entry for your proxy server.
If it exists then i would use the ```
security add-internet-password command
``` with the -U switch and the -A switch. If the proxy server keychain item doesn't exist, then you could create it with the security command, but I would probably just wait for the user to create it instead and then let the script check for its presence every 15 minutes or whatever suits your needs then when it finds it change its allow all apps access settings, once your script has done its job it could run a self destruct function to remove the script and the launchagent

add-internet-password [-h] [-a account] [-s server] [-w password] [options...] [keychain]
            Add an internet password item.

            -a account      Specify account name (required)
            -c creator      Specify item creator (optional four-character code)
            -C type         Specify item type (optional four-character code)
            -d domain       Specify security domain string (optional)
            -D kind         Specify kind (default is "application password")
            -j comment      Specify comment string (optional)
            -l label        Specify label (if omitted, service name is used as default label)
            -p path         Specify path string (optional)
            -P port         Specify port number (optional)
            -r protocol     Specify protocol (optional four-character SecProtocolType, e.g. "http", "ftp ")
            -s server       Specify server name (required)
            -t authenticationType
                            Specify authentication type (as a four-character SecAuthenticationType, default is "dflt")
            -w password     Specify password to be added
            -A              Allow any application to access this item without warning (insecure, not recommended!)
            -T appPath      Specify an application which may access this item (multiple -T options are allowed)
            -U              Update item if it already exists (if omitted, the item cannot already exist)

find-internet-password [-h] [-a account] [-s server] [options...] [-g] [keychain...]
            Find an internet password item.

            -a account      Match account string
            -c creator      Match creator (four-character code)
            -C type         Match type (four-character code)
            -d securityDomain
                            Match securityDomain string
            -D kind         Match kind string
            -j comment      Match comment string
            -l label        Match label string
            -p path         Match path string
            -P port         Match port number
            -r protocol     Match protocol (four-character code)
            -s server       Match server string
            -t authenticationType
                            Match authenticationType (four-character code)
            -g              Display the password for the item found
            -w              Display the password(only) for the item found

Your setup sounds identical to mine, Bluecoat and all. Except we use mobile account (AD) instead of local.

There's no way to do it all completely automatically, as you can't pass the login password to a script. But what I've got is a script in Self Service that users can run which updates their proxy details. So basically, they log in for the first time, and as part of the user training, I tell them to run this script.

I do other stuff in the keychain (wireless, Exchange), but the main thing I do is:

1) Delete the current keychain entries, if they exist. I haven't found a way to update pre-existing entries. And as there doesn't seem to be a way to easily iterate over the contents of the keychain, I had to use an ugly hack.

USERKEYCHAIN=`security default-keychain | xargs`
while true
do
    k=`strings "$USERKEYCHAIN" | grep -m 1 www-proxy | awk '{print $1}'`
    if [[ $k ]]; then
        security delete-internet-password -s "$k"
    else
        break
    fi
done

2) Put the keychain entries back in, and set it so it's already set to "Always allow" (that's the "-A" argument, I believe). I use a bit of AppleScript to get the password from the user, but it could also be done with jamfhelper or cocoadialog. One line for http, one line for https.

security add-internet-password -a "$USER" -w "$NEWPASSWORD" -r htpx -P $PROXYPORT -s "$PROXYADDRLONG" -A -l "$PROXYADDRLONG ($USER)" -j "default" -t "dflt"
security add-internet-password -a "$USER" -w "$NEWPASSWORD" -r htsx -P $PROXYPORT -s "$PROXYADDRLONG" -A -l "$PROXYADDRLONG ($USER)" -j "default" -t "dflt"

I have found that in Mavericks, it requires a reboot after this is run. Every other version of OSX, including Yosemite, doesn't need a reboot (although my testing in Yosemite is limited at this point).

Open to suggestions, but this is what I've been using.

Edit: Also just noticed the U switch, somehow missed that in the above comment. I feel it would be cleaner to remove them and readd them, as I sometimes end up with 3 or 4 entires, which makes things painful.

Can you kerberize the proxy?

+1 for the suggestion by @bentoms to enable Kerberos on the proxy. That is what we have done in our organization and it works wonderfully. We still see the proxy prompt at login, but now we just click Cancel and Kerberos does the rest. We have not yet enabled Kerberos authentication in Chrome or Firefox, so those applications still prompt for credentials.

Unfortunately, we cannot enable Kerberos.
I also noticed, having worked with Yosemite for quite a while now, every time our folks change their AD password (30 days), when they re-enter it in the prompts, the keychain entries get reset.
They have to go in and reenable the allow all access piece.

..

@ dwandro92 -- when you mention enabling kerberos on the proxy, is this down on the proxy server within your organization or in a script thats deployed with your image? I understand that the ticket viewer also handles the kerberos identity, have you ever utilized this utility?

@msample it will be down to the proxy 1st.

Once the proxy is setup to use Kerberos, the clients should then be able to pass lever is authentication to it.

Ben is correct, we had the same exact issue here because our proxies aren't kerberized. We installed proxies just for our MACs and our problems are gone.