Login hooks and policies not working after JSS upgrade

CCNapier
Contributor

So upgraded to 101 and it seems that some managed iMacs are no longer triggering login hooks, or getting specific policies.

Running JAMF manage says "The JSS is available".

On a particular broken device, we renamed com.apple.loginwindow.plist and ran JAMF manage and it all started working - login hooks working again.

I still have to check the policies, but this is all very worrying. We only manage about 300 iMacs, but that could be a lot to fix manually since policies don't appear to be triggering.

Thoughts, ideas, sympathy?

8 REPLIES 8

millersc
Valued Contributor

We've been seeing a problem with login hooks on and off for a while. We've moved to using Outset.

CCNapier
Contributor

@millersc oh, you don't use any Casper Policies with a Login Trigger? :(

millersc
Valued Contributor

@CCNapier I had a few using the Login Trigger and was finding that the binary would not send the login information back to the JSS. Have a defect number for this issue with no resolution available. So using Outset is my only option for the couple that have to use the Login Trigger. Plus Outset now has Privileged Login, which runs as root.

This is one of the items that bother me. This is a normal operation expected in this MDM, but yet works off and on, depending the version and OS. Base functionality I expect to always work in an MDM that I pay for. I shouldn't have to use a 3rd party OSS, but I'm thankful it does exist.

relliott
New Contributor

We are having the exact same problem. Our login hooks mostly map shared drives for users. Sometimes the hooks work and sometimes they don't. We have had to resort to letting the users run a policy via self service if their mapped drives don't appear.

CCNapier
Contributor

We have been looking at the difference between a working machine and not working machine.
The only difference we have found is the com.apple.loginwindow.plist file between machines.

Working machine has this:

bash-3.2# strings com.apple.loginwindow.plist
bplist00
ZLogoutHookYLoginHook_
J/Library/Application Support/JAMF/ManagementFrameworkScripts/logouthook.sh_
I/Library/Application Support/JAMF/ManagementFrameworkScripts/loginhook.sh

A broken machine has almost the same with subtle difference:

bash-3.2# strings com.apple.loginwindow.backup
bplist00
ZLogoutHook_
EnableMCXLoginScriptsYLoginHook_
J/Library/Application Support/JAMF/ManagementFrameworkScripts/logouthook.sh
I/Library/Application Support/JAMF/ManagementFrameworkScripts/loginhook.sh

EnableMCXLoginScriptsYLoginHook_ instead of ZLogoutHookYLoginHook*

So deleting or renaming the "broken" plist file will recreate on JAMF Manage command, and all is well.
Having to go around manually identifying and fixing this is a pain, but just seems to be normal practice when troubleshooting and fixing JAMF issues :(

djdavetrouble
Contributor III

You could pick up the bad value with and EA and script the fix. Just an idea, I am looking at a similar issue where my login hook that is supposed to fire at first login fires at second login....

CCNapier
Contributor

JAMF support are telling me that because login hooks are deprecated by Apple, that we shouldn't be using them in JAMF Pro (even though it's a viable tick box). "They are only provided for legacy OS".

Support is telling me that we should be using launchagent/daemons instead and therefore, in a roundabout way, are suggesting that the login trigger is not supported by JAMF (it may have uncertain behaviour if used, and that's that).

Excellent.

Looking at Outset to see if this does the job :(

millersc
Valued Contributor

@CCNapier that's funny. It was only a few weeks ago I had a conversation with my buddy and was given a PI number. With nothing in the talk about this being depreciated.

I haven't played with 10 yet, I'm curious if they have login triggers.