Skip to main content

We have SSO policy that runs at every network change to reestablish the key, with documentation from Apple. This was setup prior to me supporting. The problems is, that it runs and reestablishes the SSO, but in the logs, it shows a network error. When that happens, it prevents any other policy from running other then self service policies until the user restarts their mac. It doesn't happen on all devices, it's pretty sporadic. We only find out when we notice updates not installing. When you go to the device, the only policy that runs over and over is out SSO Policy.


Here is the script that runs in the policy.


#!/bin/bash


killall AppSSOAgent


sleep 10


app-sso -a "oursite" -R -q


exit 0


 


 


Here is our Config Profile.



 

@SMR1 Whoever set that up went overboard. The Kerberos SSO tool should automatically re-generate the TGT when needed. Try disabling that SSO policy and see if was truly required.

When we disable that policy, the SSO doesn't always reconnect. We had some test devices where we removed it, but when users were coming in to the office and connecting to LAN or moving to and from wifi, the SSO wouldn't always connect so we would run the SSO policy from self-service to connect it back.

When we disable that policy, the SSO doesn't always reconnect. We had some test devices where we removed it, but when users were coming in to the office and connecting to LAN or moving to and from wifi, the SSO wouldn't always connect so we would run the SSO policy from self-service to connect it back.


Are you using Entra ID or on-prem AD? I realized the Single Sign-On Extension config you posted is set to use an SSO payload rather than a Kerberos payload, and the latter is what we're using for on-prem AD.

Are you using Entra ID or on-prem AD? I realized the Single Sign-On Extension config you posted is set to use an SSO payload rather than a Kerberos payload, and the latter is what we're using for on-prem AD.


Entra ID

Entra ID


That explains the difference, and I can't offer any guidance on that yet (it'll be a learning experience for me next year so I'll just grab some 🍿 and add this 🧵 to my watchlist).

I'll update this when I get an answer.

Here is part of the log I shared with Jamf last year and what they said.



 

On What trigger and frequency this policy is running, it might be the case that this policy keep on executing and doesn't allow other policies to run, Once you restart the device it Kills the JAMF Service

As I mentioned above, the policy runs on a network change. The policy does it's job and reconnects the SSO, but causes an issue with the management framework. When the issue does happen, the only policy that will run is the SSO one.

Thought I would check our sso policy. We have 495 Mac's. Since we've had that policy in place it's ran 544,425 times.

Reply


Terms & ConditionsCookie settings