A bit off topic but Google Chrome whitelisting was incredibly easy thankfully, just mod tld at step 6. I have this scoped to anyone who has Chrome installed. If they have chrome installed but haven't opened it yet, the .plist file won't exist and the below will exit at step 13.
#!/bin/bash
# Variables
loggedInUser=`/bin/ls -l /dev/console | /usr/bin/awk '{ print $3 }'`
loggedInUserHome=`dscl . -read /Users/$loggedInUser NFSHomeDirectory | awk '{print $NF}'`
tld="*.your.domain.eg"
# Google Chrome
/bin/echo "*** Enable single sign-on in Google Chrome for $loggedInUser ***"
/bin/echo "Quit all Chrome-related processes"
/usr/bin/pkill -l -U ${loggedInUser} Chrome
if [ -f "/Users/$loggedInUser/Library/Preferences/com.google.Chrome.plist" ]; then
# backup current file
/bin/cp "/Users/$loggedInUser/Library/Preferences/com.google.Chrome.plist" "/Users/$loggedInUser/Library/Preferences/com.google.Chrome.plist.backup"
/bin/echo "Preference archived as: /Users/$loggedInUser/Library/Preferences/com.google.Chrome.plist.backup"
/usr/bin/defaults write /Users/$loggedInUser/Library/Preferences/com.google.Chrome.plist AuthNegotiateDelegateWhitelist $tld
/bin/echo "AuthNegotiateDelegateWhitelist set to $tld for $loggedInUser"
/usr/bin/defaults write /Users/$loggedInUser/Library/Preferences/com.google.Chrome.plist AuthServerWhitelist $tld
/bin/echo "AuthServerWhitelist set to $tld for $loggedInUser"
/usr/sbin/chown $loggedInUser /Users/$loggedInUser/Library/Preferences/com.google.Chrome.plist
# Respawn cfprefsd to load new preferences
/usr/bin/killall cfprefsd
else
/bin/echo "Google preference not found for $loggedInUser"
fi
Back on topic we're mobile account AD bound to on-prem as well. I found that I had to log out/in in order for the password age to appear, but having it show the users password age, a redirect to our 'change your password' website and auto-sign in for Chrome were the only real benefits.
I actually came here to see if it's possible to have it auth to AzureAD rather than on-prem? That'd resolve it prompting for login while working from home as you can't get rid of the window without logging in via VPN first, otherwise you end up dragging the window off the screen to get it out of the way.
It works extremely well with local accounts and there is a straight forward script that will convert mobile accounts to local, but the suggestion to go to local accounts is going to be met with migrating all our Macs from Jamf to Intune instead (I cringe at the idea of that workload). Don't put too much effort in to getting Jamf/Intune talking to each other - it doesn't actually do anything unless you install the Company Portal app on all your Macs and (IMO) was a waste of time.
Having just upgraded everyone to Catalina, deploying FileVault and having a lot of users working from home, we're hitting issues with users having one password for their secureToken, another password for their Mac login, then their actual current AD password. SSO Extension with local accounts solves all of the above, but it isn't going to happen.
