PART I – The Install
Have you ever noticed that users’ Windows 10 computers automatically detect their Office 365 account? But Google Chrome doesn’t? (And management wants you to fix it!)
Well, stop messing around with your IE trusted site settings & policies (which Chrome reads from and uses, too). This utility is all you need: Chrome Store: Windows 10 Accounts. Literally.
Once the extension is installed, you will see a new tiny Windows flag icon in the upper right.
You can right click on the flag icon and select the options for usage.
If the default setting of Allow this extension to read and change all your data on websites you visit makes you uncomfortable as it makes me, you can manage it at a per site level. The only other setting available for management is the option to allow the Windows 10 authentication when in Incognito mode.**
So this extension is pretty neat, huh? You’re probably wondering how to deploy it to your enterprise now. This time, your packaging engineer doesn’t have to be bothered — because Chrome supports automatic installation of extensions as part of the Chrome Group Policies! The specific setting, which you can learn about in that guide is ExtensionInstallForcelist, which forces a silent install of the extension for Chrome users.
Note: depending on what types of accounts you have in your organization & where they are located in the OU structure for GPOs, you may not want to set this particular policy on a per-machine basis via Computer Policy. For instance, the local administrator account wouldn’t be tied to an Azure/Office365 account + your service accounts should not and generic accounts may not be either. It would best to keep this particular extension policy at the standard AD user level.
You can actually even create your own local Chrome Web Store to host the files locally on your network, which is extremely helpful if you have a heavily restricted network where downloading any foreign files are strictly prohibited. The information on how to do so is covered in the guide I listed earlier. Another option would be using the Chrome Browser Cloud Management platform to manage your Chrome and other Google specific software across all types of devices (including *nix, MAC OSX/iOS, Android, etc), which is also covered in the guide.
** Just a note on extension management – I’m not currently aware of a central way to manage the policies for the extensions themselves. So if you are interested in tweaking the default settings of the Windows 10 extension (such as restricting its application only to specifically identified URLs), then you may have to wait a while for something like that to be implemented (at either a Google level or an Extension dev level). You might have the option of locating a configuration files for the extension and then pushing down a copy of it using GP File Preferences. The danger there is that if Microsoft updates the extension and the configuration schema changes, then you would need to stay on top of it constantly, or risk it breaking after a mass overnight update of the extension when a new version is released. And that would stink. Wish I had a good solution for this at the moment, but I don’t. Maybe Google will allow you to specific parameters for the install which would allow you to establish the settings during install! That would be great.
Thanks for reading thus far, and if you’re interested, you can read Part II below!
PART II – The Cleanup* (Optional but worth the read)
Oh and don’t forget to remove all of the configuration parameters you entered trying to get this to work (if you did so like me, without google searching first). Go back and clean up your Kerberos Delegation and Authentication settings in Google Chrome’s GPO. There is a time and place for those settings in the SSO world (like for your internal applications), but they do not help you when your Cloud apps are using your Azure account/identity because IE and Edge are tapping into a native Windows authentication method for Apps. Hence, you need this extension which adds that functionality to Chrome. Don’t worry, the extension is made and support by Microsoft themselves, so it isn’t some kind of shady kludge.
You should also go back and clean up your IE zone assignments and associated policies, even if you didn’t touch them trying to get Chrome to do SSO with Office 265. Why? Because even if you didn’t mess with them, there is a high chance that someone before you has played around with them (and possibly made terrible mistakes in the process).
During your review of IE zone assignment and policy settings, you want to look for any wildcards (*) and/or un-encrypted protocols (http://) — if there is justification for them then at least ensure you’re only allowing secure protocols.
You should definitely check for the infamous Automatic logon with current user name and password setting (specifically, the Internet and Trusted Sites zones).
Now, it is perplexing to me why Microsoft has the setting for Automatic logon only in Intranet zone setting, because Intranet sites have their own zone in IE assignments, so this setting is very redundant and also confusing! It is OK to use either this setting or Automatic logon with current user name and password on the Intranet zone profile, but you never want to use the latter option on your Internet or Trusted Sites zone! Ever! Because if an untrusted site asks for credentials, you would be passing your AD credentials to them in an attempt to authenticate (and that is very, very bad). The appropriate setting for the Internet zone would be either Anonymous logon (for let’s say, end users) or Prompt for username and password(for power users or IT admins that may need to logon to a foreign site – i.e. an FTP server – with basic authentication). Or, by default if you don’t touch it, the setting would be Automatic logon only in Intranet zone. Confusing, huh?
Also, personally I recommend that you fully define your intranet sites and don’t rely on IE to detect them for you. See below screenshot for a sample configuration. A good explanation of these settings and how they are managed can be found on this MS Support article.
Note that the option for Require server verification is checked – this filters out HTTP as an allowed protocol. I don’t recall if this has implications on the other allowable protocols (such as ftp://, file://, etc) as it has been awhile. If it causes issues you could uncheck the option. Because your intranet sites should all be HTTPS at this point anywhere, and if they are not, you have bigger problems!
This Zone Assignment manages not only IE with respect to websites but also with respect to FTP (in either IE or Windows Explorer) and SMB/CIFS (in Windows Explorer). So you will want to ensure that your domain name and IP range(s) are present here. A word of advice here if you are using the 172.16.0.0/12 network — you will have to add each /16 network in use… individually! So if you are using the first available /15 for instance, you would need to add both *://172.16.*.* and *://172.17*.*. If you’re using every possible /16 within that network, then you need to add from 172.16.0.0/16 to 172.32.0.0/16 as individual line items. This can be a bit of a pain if you’re using the 172.16.0.0/12 – but chances are, your users are probably already pissed at you for choosing that range as most people are unfamiliar with it. This particular blog post by the guys at TheSysadmins.co.uk does a good job of explaining the two different ways that you can deploy these Zone Assignment mappings – one way is directly through the Group Policy settings for Internet Explorer (which frustratingly greys out both users’ and admins’ ability to add/remove items on a per case basis); another (and better, IMO) way is to deploy them is via REG Key preferences in Group Policy (which allows users and/or admins – depending on how you set it up) to add or remove items from the list for individual users.
Getting the full list of possibilities correct (by protocol & hostname and/or IP) is actually extremely important for content stored on NETLOGON, because if that location is not picked up as an Intranet zone, you may end up having issues with Logon Scripts called from that shared directory — either blocked altogether or most likely the user gets a popup for each logon script and then has to click Yes or No… Yikes!!! I believe you can avoid this by storing the Logon Script directly in the GPO by uploading it rather than calling the network path to //domain.net/NETLOGON — but it has been awhile since I have done it and I honestly cannot remember. (I will make note of this for a future blog post, though!). BTW, if you are still using Logon Scripts in 2019, you may want to evaluate whether or not they are still needed — because MS has added almost any functionality you can think of as either a GP policy or preference. This means that you don’t need to use CMD to load REG keys or call an MSI package anymore, because both of those each have a new, more scale-able and supportable method for deploying them to your domain computers.
Today’s post took us from configuring Office 365 SSO in Google Chrome to a brief lesson on IE site zone assignments and their most important associated policies. I hope to cover the IE group policy settings in more depth soon!
Never A Null Moment 