Suppose we'd like to block Google Chrome from authenticating to google for Bookmark/settings and (most problematically) plugin syncing.
We've seen a few instances where a plugin someone thought was awesome for their home use sneaks into the corp environment if they login to google with the browser itself.
For this client, allowing authentication to google services as web pages (mail.google.com docs.google.com and the like ) is something that needs to be allowed generally, but I'm looking to just block the scenario of users logging their browsers into the google cloud.
Anyone solved this use case? If not, I'll go to work with a policy trace and a few scenarios, but if the wheel is invented, I'm all ears!
I did a trace on the sign in process and it looks like an interactive sign in involves these URL's
Chrome-initiated browser login hits these:
POST https://accounts.google.com/_/lookup/accountlookup?hl=en&_reqid=NNNNN&rt=j
CONNECT https://www.googleapis.com
POST 2017.01.31 14:44:48 https://accounts.google.com/_/common/diagnostics/?hl=en&_reqid=NNNNN&rt=j
In contrast going to gmail in a browser hits these
POST https://clients1.google.com/tbproxy/af/query?client=Google%20Chrome
GET https://mail.google.com/mail/gxlu?email=USERNAME&zx=1485894750242
POST https://accounts.google.com/_/signin/v1/lookup
Relaunching Chrome if you've ever connected your account to Chrome will hit these sites:
CONNECT https://security.google.com
CONNECT https://myaccount.google.com
CONNECT https://translate.googleapis.com
CONNECT https://accounts.google.com
CONNECT https://www.googleapis.com
My guess based on this is that blocking
https://accounts.google.com/embedded/setup/chrome/usermenu
might be a good way to prevent new folks from logging in and connecting their Chrome.
And blocking
Might be reasonable ways to block re-login's.
Note also that logging into Chrome also makes it generate a lot of https://mtalk.google.com:5228 traffic if chat is enabled for that google account. If you have to block instant messaging in your environment, this sure causes a lot of noise in logs, which is another nice reason to block users from associating their user account to Chrome.
That guess, however would be wrong. LOL. Further datapoints necessary apparently. The blocks above don't work and some combo of
client*.google.com and www.googleapis.com appears to be the likely path of blocking. That will have a lot of collateral damage though, I reckon.
I'll post if I figure it out.
Corporate Headquarters
6220 America Center Drive
San Jose, CA 95002 USA