Catalina SSO Extension

Valued Contributor II

I am trying to get the Catalina SSO extension up and running and it seems to be fighting me at every step of the way. I was wondering what resources or tips any of you guys have.

I have been able to get the extension to see our AD server and it will kick back correctly if you put in a bad password. However it cannot tell how many days until your password expires or what our password requirements are when you go to change your password. In Production we use NoMad and it is seeing everything fine. Our Macs are AD bound and we use mobile accounts. I know the SSO extension does not like Mobile accounts from apples documentation, but documentation on this as a whole seems to be lacking. Never mind SSO is not working for anything in Safari, but one thing at a time :).




Honored Contributor III

@AJPinto Is there some specific reason you're using mobile accounts? With the SSO Extension, and NoMAD, the idea is to use a local account whether or not you are binding to AD.

Contributor III

@AJPinto a couple of questions:

• why are you still binding with these tools (as mentioned before)?

• Uninstall or unload NoMAD when testing SSO, also do a kdestroy -a and try again just with SSO Extention.

• why the multiple hosts? you should be able to single that down to just

• you may need to create a kerb5.conf file

default_realm = "REALM.COMPANY.COM"

• If you are using Chrome, you can use a configuration profile to manage those settings


Valued Contributor II

@Walt We are AD binding with a configuration profile, NoMad lingers around for sharedrive mapping and password changes. NoMad is a left over from before we AD bound. AD binding and Mobile accounts are required per cooperate policy, we are a Windows shop and centralized management is a requirement.

I will rip NoMad off and see where that gets me, thanks!

I have been looking at SSO for chrome but have not gotten started working on it yet. Our windows auth list for chrome does not work for chrome Mac for some reason in my very limited testing. Mainly there are ~5 authentication whitelists needed, but 90% of sites use * in chrome but using in this SSO Extension for Catalina does not work, I am getting ready to try and see if that does anything differently.

We are generating Kerberos tickets without issue, I have destroyed all the tickets but that did not seem to change anything.

Contributor III

@AJPinto You were local before and now AD bound? That is definitely not a ideal situation with modern Apple provisioning..just my thoughts. And in your defense to your environment, Jamf is a centrally managed service if you have things like intune you can incorporate and connect those for that unified experience.

if you have an Apple account team or SE they may be able to help with the SSO stuff to get it to work with Chrome and your profile, you may end have to do what we did and create multiple configuration profiles for each realm or domain as it seems that there is not a global lookup option in your case as was mine.

Valued Contributor II

@Walt Not to go too far in the weeds, but we are a financial institution and have all kinds of federal laws and regulations to abide by, and on top of that we are extremely conservative when it comes to security practices. Baring the Apple ID I maintain for testing purposes we are not allowed to use Apple ID's on our Macs or use any of Apples Services (such is imessage or icloud for example). Most of the people who have Macs around my company are developers, content creators (video editing), or your officer title is high enough to get what you want lol.

Our Macs have been AD bound for the past 4-5 years, the Catalina SSO extension is only something I have started recently working on. I had tinkered with SSO for chrome back 1st quarter but got pulled off on another project and have not been able to get back to it, being the only JAMF admin has its down sides. Our mac environment makes up about 1.5% of our total device count, and the entire support for it is really 3 people with me being the admin. For the most part we have to make the Macs play by Windows rules and as you well know macOS really dont like that lol.

I have tried to get Intune setup with JAMF but our email team has little interest in it so that endeavor is kinda dead in the water. I would really love Intune to be setup for the SCCM reporting it offers among other things.

Reach out out to Apple is next on my list, I dont think this is something JAMF support can help with but I may get a ticket to them anyway just to see what they have to say.

New Contributor III

FWIW, I can't deploy Kerberos SSO at all at the moment. Jamf has a larger issue going on. I have existing ones that are working, but I can't deploy new ones with new clients.


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.


# Variables
loggedInUser=`/bin/ls -l /dev/console | /usr/bin/awk '{ print $3 }'`
loggedInUserHome=`dscl . -read /Users/$loggedInUser NFSHomeDirectory | awk '{print $NF}'`

# 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/" ]; then

    # backup current file
    /bin/cp "/Users/$loggedInUser/Library/Preferences/" "/Users/$loggedInUser/Library/Preferences/"
    /bin/echo "Preference archived as: /Users/$loggedInUser/Library/Preferences/"

    /usr/bin/defaults write /Users/$loggedInUser/Library/Preferences/ AuthNegotiateDelegateWhitelist $tld
    /bin/echo "AuthNegotiateDelegateWhitelist set to $tld for $loggedInUser"
    /usr/bin/defaults write /Users/$loggedInUser/Library/Preferences/ AuthServerWhitelist $tld
    /bin/echo "AuthServerWhitelist set to $tld for $loggedInUser"
    /usr/sbin/chown $loggedInUser /Users/$loggedInUser/Library/Preferences/

    # Respawn cfprefsd to load new preferences
    /usr/bin/killall cfprefsd


    /bin/echo "Google preference not found for $loggedInUser"


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.

Valued Contributor

@AJPinto I was able to successfully make a case for local accounts with a security policy that mimics AD if that's your concern. We are not in the financial industry but have similar compliance/security requirements to abide by.

The writing has been on the wall for a long while in terms of AD binding with mobile accounts. Enterprise Connect and Kerberos SSO cannot manage mobile accounts fully and we've run into all sorts of issues over the years.

I'd be happy to share my password policy script if that would help the conversation with your compliance/security teams. In my case I still bind to AD for other reasons but use local user accounts on all but a few lingering Macs left over from our old deployment method.