You could also press command+shift+G when Finder is activated and input ~/Library/Application Support/Google/Chrome/ also press tab key for filename auto-completion; there you could remove chrome’s profile or rename it. Then user’s profile, account and extensions and browsing history will be reset and removed. To delete the browser cache in your Google Chrome browser on a Mac please follow one. If you select 'Settings', the browser settings open in a new window.
I'm interested in getting Google Chrome set up on an image where the first run and subsequent runs just opens the browser and sends the user to a homepage without prompting the user to log in or do anything else. It appears that this may not be so simple. There have been a few posts in the past about this (one method with a manifest, the other Google Chrome Master Preference) but I haven't been able to get anything working. Would anyone be willing to share how they're doing it? It feels like this ought to be possible. Master Preferences are pretty easy as a DMG deployment. From memory It's basically just two files.
Library/Google/Google Chrome Master Preferences. I use two methods. One by setting some 'suggested' settings via the option in a file I believe in /Library/Application support (I'll update tomorrow if you are interested when I get into the office).
This file sets some settings on a first time basis only and the user can override them with their own settings. I then lock all the settings required for my environment via a configuration profile (you could also use the legacy managed preferences method in the JSS).
Basically I configured a plist file called com.google.chrome.plist (see picture attachment for a partial look at the file) with all of the locked settings. Uploaded that into the configuration profile and applied it to the machines. It works great. Whenever I need to update settings, like whitelisting plugins or sites, I just update the plist file and re-upload it to that configuration profile.
OK so here's the update. For one time only prefs you must create a file called Google Master Preferences found at /Library/Google/Google Chrome Master Preferences. It's a simple txt file in JSON format.
More details at. For this I just use Composer to package the file and deploy it when I image the computers. From what I can tell it only supports a subset of the available preferences ( they are listed at the end of the page ). Like I said previously this will ONLY give defaults prefs the first time chrome is run and they are NOT locked just friendly suggestions.
For the real good stuff, I deploy a Configuration Profile (Computer not User). Per JAMF's recommendation they suggest only using one configuration profile per set of preferences so mine is ONLY dedicated to Google Chrome settings. To create the settings you must create a plist file called com.google.chrome.plist. In this file I put all of the settings that must be locked down and NOT changeable by the user.
The complete list of available prefs is located at When you construct your plist it must be in the right format, see my screenshot above. Once applied via configuration profile the changes are instant. You can verify that the prefs have taken hold by typing in chrome:policy in the address bar, it will then show you a list of all the prefs that have been applied. I used the method of importing a com.google.chrome.plist file into a configuration profile as mentioned by maxbehr and it works a treat. The full list of available options is at (note, some preferences are only for Chromium OS, each setting is marked whether it is applicable to OS X or not). For default settings (as opposed to enforced settings) we normally just load chrome a few times to capture all the prompts, then copy the chrome profile out of Library/Application Support into the default user template. Have tried using managed preferences but haven't had much luck getting it to work.
I know this is an old post, but maybe just maybe someone like me is stuck with Yosemite, and comes across this. Run the following lines in a login script to set the browser as default for each user. Assuming Chrome is already installed: open -a 'Google Chrome' -args -make-default-browser sleep 1 sqlite3 /Library/Application Support/com.apple.TCC/TCC.db 'REPLACE INTO access VALUES('kTCCServiceAccessibility','com.apple.loginwindow',0,1,1,NULL);' osascript -e 'tell application 'System Events' to tell process 'CoreServicesUIAgent' to tell window 1 to click button 1' /dev/null 2&1 sqlite3 /Library/Application Support/com.apple.TCC/TCC.db 'delete from access where client='com.apple.loginwindow';' Very subtle solution and works quite nicely. Thanks for the reply! I was able to apply my preferences.
I took the com.google.Chrome.manifest file and saved it to my desktop. I then made the changes to the file. I copied it to the managed preferences path you mentioned. I then renamed the file to com.google.Chrome.plist and it worked just fine. The struggle I have now is uploading the manifest file to the JSS. It tells me there is a format issue.
How can I convert this manifest file so that it will work with the JSS in a configuration profile? You might be able to help me out here.I'm having difficulty with google as there are no directories outside of the user account for chrome in OS X. I have tried the JAMF process with the configuration profile, using the manifest file and options there yet it effectively does nothing on the client machine. I have switched to manual manipulation of the manifest file and converting it to a plist file.yet still no enforcement/changes. What I am attempting to do is forced the user to log in under the provided domain account for our google apps for education and deny access to a personal log in - i.e.
Gmail or others. We are running 10.10.5 and up (I am building a workflow and wanted to incorporate this to the new image flow.) Just as a note I have edited the manifest using this page: utilizing the.@domain restriction pattern Thanks for any input on this -Nate. @Npooter229 Nate, unfortunately it looks like those two policy options are Chrome OS only. If you notice each preference setting has a Supported On clause, only the ones that list Chromium (Mac OS X) will work on the Mac. Those with Chrome OS will only work on Chrome OS devices (Chrome book, etch). The only policy I can think of would be the SyncDisabled preference but that only restricts whether a user can login to a google account to sync across devices, there is no way I know to further restrict which accounts (personal or institutional) they can usesorry.
![Location Location](/uploads/1/2/5/6/125635931/145099817.png)
I could really use some help on this.I seem to be doing everything posted here and get no errors, but Chrome just isnt reading/applying the policies I have a very simple plist (for testing):
After reloading and rebooting Any help would be greatly appreciated!! Either will work I think, Configuration Profile is the preferred method. I know of no way of forcing the client to reconnect to Apple's Push Service Network. Configuration profiles require use of Apple's Push Service. The JSS needs access to 17.0.0.0/8 via ports 2195 and 2196. And the client needs access to 17.0.0.0/8 via port 5223.
If you don't have access to those ports or you just want to test the easiest method is to download your config profile, there is a download button on the configuration profile edit screen, from the JSS and then manually install it on the client. I'm sorry to bug you again, but while it's working in general, I'm having trouble with the AllowedDomainsForApps policy It's a string and I'm not sure if it's just the way I'm putting it in or what. I've tried it with and without quotes (it's also apparently new to v. 51, which I do indeed have) Every other policy below is being read properly
Is changing the file name suffix manually the problem? FYI.ultimately my goal is to require our students to log into Chrome with their school email accounts and to block all extensions. You'll probably want to preserve the.plist extension - i.e.
com.google.Chrome.plist - Your.plist file will be formatted as an XML file, same as any other.plist, just preserve that extension before uploading as a custom config profile payload. The key for blacklisting all extensions would look like: ExtensionInstallBlacklist. Here's an example.plist I created to force install a particular Chrome extension. Notice I had to add the 'ExtensionInstallBlacklist' key and enter a blank string - if you don't add this key and blank array, your end users will not be able to install any extensions except the one(s) listed under the 'ExtensionInstallForcelist' key. I was unsure about the 'ExtensionInstallWhitelist' key, so I left it in there, as it doesn't seem to interfere with extension install functionality.
But I went back in, installed two more extensions, and even though I've both restarted the computer and done a forced check-in with sudo jamf recon, those extensions are still there. Hmmmm.so what have I done wrong? Here's what I have in my plist:
No worries, where would we be if somebody didn't lend a hand once in a while?:) I think I may see what's preventing extension installs - I changed the following to remove the asterisk between the tags. Sorry, I realize my earlier post may have been confusing, as I had the asterisk in the one-liner, but removed it from the example.plist. The 'ExtensionInstallBlacklist' key below should resolve any extension install issues. ExtensionInstallBlacklist I also noticed the 'RestoreOnStartup' key line has a syntax error that may cause issues.
I've replaced a '.' With a ' in the line below: RestoreOnStartup0 Cheers! Couple of things, if I read it correctly the.
is required to blacklist all extensions. Second the syntax error after RestoreOnStartup. Also I don't think 0 is a valid argument for that key.
I've put a complete plist at if you want to download it. Here is the text
Agree with, the first run tabs sections needs to be in its own block outside of distribution. Also remember that the Master Prefs are only applied the one time and never again. Try setting up a new temp user to ensure that it's a 'clean' first run for chrome. Couple questions for your configuration policy, does it successfully upload when you attempt to create it in the JSS? What is the preference domain in your configuration profile it should be EXACTLY com.google.Chrome. Finally on a machine that has the policy applied, open chrome and type in chrome://policy into the URL bar.
What if anything is returned? @maxbehr Hello! A few of us are working up the Chrome preferences and we have been able to push out via Configuration Profiles nicely, but a few issues have come up that I am hoping you or someone can help with.
We can get our policies to apply and can see them within chrome://policy, but the only thing that does not work is 'RestrictSigninToPattern' (we want to be able to limit users to just our domain only). It shows within Policy, but Gmail and other non-domain emails still work. Extension blacklists, homepages, incognito mode all apply nicely, but the Sign-in does not work. Any suggestions? I re-read your original post.
To clarify, from my understanding RestrictSigninToPattern is setting what domains a user is allowed to login to chrome with, meaning the sign in function in Preferences that allows synching of bookmarks, passwords etc. If you are attempting to block a user from logging into a web page like gmail or some other google hosted email system RestrictSigninToPattern does not cover this. Furthermore I don't believe there is a way to restrict the logging in to google services by domain. I know this is an older post, but I am trying to create a preferences file and a policy file for Chrome. My Mac users are supported be myself with little IT involvement since my company is 99.9% Windows PC's (15,000+ Windows, less than 50 Macs). I'm using Profile Manager to create the custom files to load manually on the 15 Macs I support. Right now, SSO is working for everything native to macOS (10.12.6).
Chrome, however, requires credentials for everything.Proxy, intranet, you name it. I got the policies from my Windows Registry and the masterpreferences file from the Managed Workstation team. Do I need to create two separate files for preferences and policies? I know I can basically take the masterpreferences file from IT and make it a plist for the users.
But the policies I'm struggling with. For instance, I have the chromepolicylist.html from chromium.org, to which none of the preferences on the masterpreferences file are listed.so I presume its different (since the registry entries in Windows come from AD GPOs). Here is the masterpreferences file loaded on all the Windows PC's: This file (if good as is for Macs) is called what and goes where? The policies that I need to set/test is done in Profile Manager as a Custom Settings plist (com.google.Chrome)? Where does the file go or is that set in the profile itself?
Sorry.I know this sounds newb-ish, but until I can get jamf Pro approved and setup here, everything I do is manually and I'm struggling. Any help is appreciated! Couple of things. First the master preference file is a one time thing. The first time a client opens the browser those preferences are applied.
They are not locked however and the user is free to change (break) anything. I would only recommend it for basic things (homepage etc).
This is placed at /Library/Google/Google Chrome Master Preferences The plist file is where all of the real work is done. These are all locked prefs that the user cannot override and are what are referenced on the chromium policy pages. This file is placed at /Library/Managed Preferences/com.google.chrome.plist Assuming the name of your internal DNS network is marathon.com (if not substitute with your appropriate domain), for single sign on you need three specific keys AuthSchemes basic,digest,ntlm,negotiate AuthNegotiateDelegateWhitelist marathon.com AuthServerWhitelist marathon.com Since you also referenced a proxy server there are several other keys to set the proxy server depending on your particular setup. Finally the file you have above is the master preference file which can be placed at /Library/Google/Google Chrome Master Preferences. The plist however you'll have to create as its syntax is completely different than the Windows format. We use custom config profiles to manage Chrome settings on the fly. Your config file will be an.xml file, converted to.configprofile or.mobileconfig.
This site will have Chrome parameters + syntax you can set in your xml: Use timsutton's MCX to Profile script to convert your.plist/xml to a custom Config Profile. Upload custom config profile under Mac Configuration Profiles in your JPS. We set ours to 'Computer Level' enforcement. Deploy said profile to scope.
No restart needed, you can observe Chrome settings get adjusted as you watch. We use this to restrict Chrome extensions in our Lower and Middle Schools. Just bear in mind these profiles can take minutes to install, depending on your load. Here's an example of a very bare-bones xml that blocks all Chrome extension installations, force installs a specific extension, allows for Java and Citrix plugins (partly deprecated) and blocks the 'no connection' dinosaur easter egg game. Convert this to a config profile, and you can deploy and enforce via Jamf. In this example, you can adjust these parameters as your see fit, add extensions to force install or block, etc.
Convert this to a config profile, and you can deploy and enforce via Jamf.
GPOs in Windows allow passthrough of credentials to proxy for authentication. On macOS, you type your credentials once and it authenticates with that for anything that uses macOS natively.
As Chrome does not, I need to configure the policies to do so. In Windows and macOS, its set to autodetect, exclude simple hostnames and there is a wpad.dat that pulls from the server automatically using the autodetect setting. Not sure if that helps with what I need to configure in the com.google.Chrome.plist file. All I have (used from the Chrome Policies in Windows RegEdit) is ProxyMode autodetect. If I need more, then I will certainly give it a shot! Appreciate everyones replies! So try this.
Quit Chrome. Copy the below text into a blank text document. Save the file as com.google.chrome.plist. If not already present create the folder /Library/Managed Preferences. Copy plist file to the managed preferences folder.
Open Chrome. Type in chrome://policy in the address barverify that the entries you created are present under the Chrome Policies section (if not quit chrome and from the command line type in sudo killall cfprefsd and then reopen chrome). Attempt to navigate with chrome From what you described, Chrome should auto discover the proxy serverusing the wpad.dat file download the proxy.pac file and be setup. Two things: You may need to manually populate the ProxyBypassList, and second make sure that the domain you enter for the two settings matches your internal DNS zone. If it all works then you can add the plist file to Profile Manager in OSX server and push it to your clients.
I'm sort of a trial and error kind of guy when it comes to this stuff. But I wouldn't be surprised if someone like has a quicker solution. Looks like your syntax is off. The entire plist body is enclosed in a tag. Good test is to install Xcode.
Open the PLIST in Xcode if it fails to open it's not a properly formatted plist. Does your proxy server force the client to bypass it for intranet sites? If you strip out the proxy info for chrome and direct connect to the sharepoint server does it still fail? I'm guessing the proxy server does not forward kerberos credentials on to the sharepoint server. Also try adding the sharepoint server to the list of bypass proxy addresses in your plist. As for search, NTLM will always prompt for username and password on the Mac. The mac does not have the ability to do SSO NTLM authentication, only Kerberos.
That certainly puts a crimp in my plans:( So I don't know if you're familiar with these or not.but I'm part of the macadmins Slack and I had talked to them over a year ago about enabling SSO and problems I was having. I ended up getting into ADmitMac client by Thursday software which had code built in that could read certain GPOs that Windows could. That included LANMAN authentication. As soon as I bought it, they went end of life. It was right around that time that the search.domain.com stuff stopped working for my Mac users (once I uninstalled it). There is another client called Nomad that has been mentioned there which performs similar functions.
While macOS doesn't support NTLM SSO natively, is that whats actually happening here since everything else in the system runs on Kerberos for SSO? Is there some 3rd party piece that allows NTLM SSO on Macs? As far as I know there is no piece of software that does NTLM SSO on the Macintosh. Whilst ADmitMac may be able to read GPO's (Centrify does the same thing) this would have not given you NTLM SSO. Instead it would have regulated authentication methods (similar to the NTLMv2Enabled policy) as well as things like requiring smb signing. Nomad allows you to not bind your mac to AD, instead users use regular local accounts and use the Nomad application to get kerberos credentials, but again this is only Kerberos. The closest I think you are going to get to NTML SSO is having the user check the remember in keychain option for anything that requires NTLM.
This would give the illusion of NTLM SSO, until such time as they change their password and then would have to enter it again into keychain. If you are using smart cards like I am, this of course won't work. Two potential, though not so elegant options. You can try the policy
Adding '-force-dark-mode' to the command line of current builds of Chrome 73 makes everything dark. The dark theme is still unfinished, hence this menu with almost illegible black text on a dark grey background. The macOS work has top priority (P1). The Windows work is only P2 (originally P3), surprisingly suggesting that it's less important, even though Chrome has far more Windows 10 users than it does macOS users. Development of the Windows theme was at least, for a time, hindered by one of the developers not.
Chrome already has a dark-ish theme for incognito windows; these set the tabs, address bar, and related areas to be dark gray so that they're immediately distinguishable from regular, non-incognito windows. However, incognito only changes the main window chrome. Other parts of the interface, such as menus, are left in their usual light colors. Dark mode builds on the incognito theme to change menus and other parts of the interface dark, too.