Skip to main content

Hello - I am configuring Chrome to use kerberos to single sign on to my workplace home page but it isn't working.
We do not want to use MCX due to previous issues using them in our environment.



I have set the whitelist domains using:
sudo defaults write /Library/Preferences/com.google.Chrome.plist AuthNegotiateDelegateWhitelist '.domain.intra'
sudo defaults write /Library/Preferences/com.google.Chrome.plist AuthServerWhitelist '.domain.intra'



However loading the homepage still requests credentials. In Firefox, everything works fine once I set the domains.



Any idea why it doesn't work? Am I missing a setting? Ive tried forcing certain authentications too but then the page will not load at all.



Thanks for any help..

@bbot In a single test with macOS 10.14.2 (18C54) and Chrome 71.0.3578.98, it's working for me for a single domain.

Thanks for the info @dan-snelson . I'm going to be reimage a new Mac with Mojave and try again without any of our company software on there..



Are you using a configuration profile or a one time script to configure the settings? We've been deploying it via config profile successfully up until 10.13.6.

@bbot We're using a one-time script via Self Service.

@dan-snelson what version of the IWA web app are you running?

@bbot We don't use Okta IWA Web App for Desktop SSO.

This may be a silly question, but once the changes to the WhiteLists are made and Chrome restarted, so long as a machine has a valid Kerberos ticket then SSO should work and just pass through correct? I've been trying for some time now and continue to get the prompts within Chrome when trying to access expected resources. Machine is bound, Kerberos ticket, 10.14.2 and latest Chrome.

@andrew.nicholas I believe @bbot is running a similar setup; we no longer bind, using just Enterprise Connect, and Chrome is working for us with a single domain.

@dan-snelson Thanks dan, we still bind for a myriad of reasons but the accounts are local with EC tie ins as well.

@andrew.nicholas we're in the same boat, unable to get it to work on 10.14, 10.15, have you had success with this?

Agentless DSSO for my OKTA Tenant now works with these preferences

This should work successfully when setting the config via a managed Plist, won't work from the terminal

I needed to add “AuthNegotiateDelegateByKdcPolicy” true
See: https://chromeenterprise.google/policies/#AuthNegotiateDelegateByKdcPolicy

In case anyone else is looking at this thread in 2022, the current supported method (in my testing) is the configuration profile one, and the keys all use the term "allowlist" instead of "whitelist".  Good documentation here: https://chromeenterprise.google/policies/#HTTPAuthentication

Here's my working config profile:

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">

<plist version="1.0">

<dict>

<key>AuthNegotiateDelegateAllowlist</key>

<string>*.company.com</string>

<key>AuthServerAllowlist</key>

<string>*.company.com</string>

<key>AuthNegotiateDelegateByKdcPolicy</key>

<true/>

</dict>

</plist>

Thank you ncworster! This was exactly the fix we needed for our company. we changed the keys to "allowlist" and now sso is working properly for Google Chrome.

yes big thank you @ncworster and others in the thread from august 2023,  I have been fighting with kerberos auth for a few specific things in chrome for a while now, this solved the problem. Config profile -> Application & custom settings -> Upload > com.google.chrome preference domain> copy plist > scope.

Any help appreciated - this doesn't seem to be working for me on Sequoia.


Thanks

Reply


Terms & ConditionsCookie settings