Posted on 11-20-2014 03:09 PM
So the situation I am running into:
Mac devices are pointed to a proxy.pac file in our environment.
The first time a user logs in, they are prompted for HTTP and HTTPS credentials to get out to the internet.
The users enter the credentials, and everything is alright UNTIL some application decides to try to get out to the internet. Then they are prompted again, over and over.
The solution appears to be to go into keychain access, go into the properties for the HTTP and HTTPS entries under login keychain, Passwords category, and click Access Control, Allow all applications to access this item.
My question is: is there a way to script this before the user ever logs into their account (local accounts, not AD)? Could I somehow create dummy entries automatically in the keychain with the proper bluecoat servers and the user's ID and a bogus passwords and have the allow all applications box checked automatically? That way, when they logged in, there would be an incorrect password try, but they could correct it and everything would function properly from that point forward. Any thoughts?
Posted on 11-20-2014 03:26 PM
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
Posted on 11-20-2014 10:00 PM
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.
Posted on 11-21-2014 12:45 AM
Can you kerberize the proxy?
Posted on 11-21-2014 07:15 AM
+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.
Posted on 01-12-2015 10:28 AM
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.
Posted on 01-20-2015 08:53 AM
..
Posted on 03-08-2015 10:11 PM
@ 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?
Posted on 03-09-2015 12:01 AM
@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.
Posted on 03-09-2015 06:48 PM
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.