Error Domain=com.Jamf.Jamf security.error Code=50

I see this error in multiple environments too. When seeing this, I'm unable to execute any login or logout triggered policies. I'd recommend to open a ticket with Jamf support - they're aware of the issue. A +1 for this defect would be helpful...

Casper Support says it is from the Boot volume and the Recovery were of different versions, but ours are the same. They also said it was erroneous.

We have this issue in our environment. Its been going on since we first started using Casper last summer to manage our iMacs.

For us it started with just the error message in the log "The jamf binary could not connect to the JSS because the web certificate is not trusted."

Now i get both the message:Error Domain=com.jamf.jamfsecurity.error Code=-50 "One or more parameters passed to a function were not valid." UserInfo={NSLocalizedDescription=One or more parameters passed to a fuction were not valid.}

AND the same "The jamf binary could not connect to the JSS because the web certificate is not trusted."

When these messages come up no login policies are run.

When this error message popped up no login scripts would run at all. Our instance is hosted my JAMF so we can be reasonably certain its not a certificate issue on our end. Jamf support has not been helpful is resolving this issue. The best they could do was come up with a convoluted workaround using launch daemons to circumvent it. Its a really messy and difficult to manage solution and when you manually invoke a login policy you lose any LDAP filtering you might have been using for them.

See the following two previous forum posts which date this issue going back to January 2016
https://www.jamf.com/jamf-nation/discussions/18539/problem-with-login-policy
and also https://www.jamf.com/jamf-nation/discussions/18816/problem-with-certificate-and-loginscripts

this is apparently Product issue: PI-002269
this has been a "high priority" for over a year now.
Hopefully now that this new error message is there it means more people are effected by it and hopefully it will finally get the attention and fixes it needs.

@m.entholzner do you know what defect they have this under now? Which one do i need to bug them about again? I REALLY REALLY want to use the software normally after this summer without having complicated workarounds in place.

@TexasITAdmin , PI-002269 is the same defect that was reported to me...

I created a support ticket for a status update on this issue. They reply was the same unhelpful "This product issue is still open and we do not have any status updates at this time. Please feel free to keep an eye on release notes in future versions of the JSS to see if this has been addressed."

They are still suggesting launchdaemons. Which is useless for invoking any login policy that is LDAP based. When you manually invoke a login trigger its completely LDAP blind. This breaks any LDAP group based drive mappings for us.

If they aren't going to fix this i HIGHLY suggest up voting and having your clients up vote the following to feature requests as they fix the issues caused by the Jamf work around:
https://www.jamf.com/jamf-nation/feature-requests/4841/ldap-group-policy-limitations-for-all-triggers

https://www.jamf.com/jamf-nation/feature-requests/4340/allow-scoping-policies-to-specific-users-based-on-ldap-membership

Hi All,

I just called JAMF regarding the same issue and heard no update on PI-002269 yet. They, of course, gave me the LaunchAgent/LaunchDaemon idea as well.

I ended up making a LaunchAgent that would call the JAMF login script every 30 seconds (specifically to check for our mounted Cloud drives):

#!/bin/bash

#Check for whether Cloud drive is mounted on our IP space

if [[ $(ifconfig | grep -E "128.164|161.253") ]]; then
    resultdrive=`df | awk '{print $9}' | grep "Cloud"`
    if  [[ -z "$resultdrive" ]]; then
        echo "Cloud drive not mounted, running login policy"
        sudo /usr/local/bin/jamf policy -trigger login -username $3
    else
        echo "Cloud drives mounted. Nothing to see here."
    fi
else
    echo "Not on corporate Network"
fi

Tying this into a LaunchAgent with a StartInterval of 30 or so will ensure that it runs the policy every 30 seconds to get drives at "like login" times.

Hope this helps! I'm sure there are ways to make this more complex, but this was a quick fix I could deploy to affected machines.

We are having the same issue here.

It started last week when I was unable to create a new quick add package after upgrading to 9.98 (apparently the recon app did not update). We also received the certificate errors as stated above and now the login and logout policies are not executing any longer.

I am half way in my flow of deciding to go with JAMF or not. This is a possible show stopper for me. Also using a workaround is a no go. These are things we are getting a tool like JAMF for.

I can confirm i'm seeing this error too on login policies trying to run. Very frustrating. We just had our jumpstart 2 weeks ago. Trying to get some stuff implemented only to be dead in the water with this random "bug"

oh, good luck brianmcbride99, i was in your shoes a year ago. Jumpstart worked just fine. but once we got it put into real world situation we ran into this problem. I've had bandaids all over this for the last year and only just now had the free time to revisit. Only to find its just the same if not worse.

Seeing this out of the blue on 9.96 as well, on a freshly imaged machine. Not sure if related to our other woes? (https://www.jamf.com/jamf-nation/discussions/23925/mdm-profile-randomly-auto-deleted)

Ran into this issue (login policies failing to run) during last year using 9.82. Trying to implement workarounds but its a shame such an important feature hasn't been fixed and theres no further information forthcoming. I was basically told that it wasn't being prioritised because loginhooks have been deprecated and Apple could remove them at any time.

Running into this issue again.

I understand it's deprecated technology and hence no further support can be given. But why not change the technology behind the login run at login/logout button.

If I check the run policy at login button make it happen. Generate a LaunchDaemon for me or something else that does the same. Of course I could do this all myself. But the point of using Jamf for me is having not to bother with those things.

Sometimes it's just useful to run things at login. I'm using it now for the update of the Abobe CC suite. It needs to be updated when the software is not running (non of the adobe products).

@arnokenis I agree with you, if it is broken remove it from the GUI. I actually asked Jamf about a similar issue with Managed Preferences Link why is it there if it is not supported, and they said its for our older clients that dont run updated hardware and OS'es.

Im in the same boat, i need to run two commands at every users login on every computer in a lab. One command can be ran as the user, but the other needs admin rights.

For whatever reason i can't get a LaucnhDaemon to run at login, am I missing something? Aren't Agents and Daemons practically the same thing except the folder they sit in, a different mechanism launches them?

Do i need to do something else to the LaunchDaemon to launch at user login with admin rights?

I'm seeing this now on v10.15.....

And, It seems that PI 002269 is STILL a known issue???
Since 2017?????
I really am starting to lose confidence in JAMF.

poor show!

@kerouak Dealing with this now myself and agree 100%.

i'm seeing random jamf errors with login policies that were fine with 10.14.6. Errors in logs

Error Domain=com.jamf.jamfsecurity.error Code=-50

and device signature errors, but not true device signature error because on restart or logout/login sometimes it works fine so signature isn't truly bad. Just wondering if others have seen uptick of loginhooks behaving worse in 10.15 vs 10.14. Will probably have to switch bunch of workflow over to outset. sigh.

Im getting this during testing of my DEPNotify workflow. Doesnt happen on the local admin user, but once I log into the 2nd user (ad bound mobile account) IM getting the same com.jamf.jamfsercuriy.error message.

I had seen this happening in the past with dep and re enrollments so trying some testing again after deleting the device from the JSS.

Gabe Shackney
Princeton Public Schools

@CasperSally What is your workflow for switching to Outset? Im interested in it, but never spent the time to figure it out.

Gabe Shackney
Princeton Public Schools

@gshackney I had already used outset to set docks once, so I was a little bit familiar with it. Jamf support is aware of the issue, though, and had offered to help me going with it - that may be a source of help for you?

I admit it is super frustrating paying a lot for jamf and constantly having to adapt to other tools to get things to work as they should.

BTW I should probably post that I validated this in my environment and can replicate this issue. Login hooks are still working and this error that I see gets tied to a device signature error but just for the user. My error is slightly different:
Error Domain=com.jamf.jamfsecurity.error Code=-50 "unlockWithPassword:error: : One or more parameters passed to a function were not valid." UserInfo={NSLocalizedDescription=unlockWithPassword:error: : One or more parameters passed to a function were not valid.}

1. My users are mobile bound ad users but this issue also affected my local admin user.
2. On the login screen if I wait for the 🔴 to indicate we are not on our network, the error would not occur.
3. If I didn't wait for the 🔴 to appear, it would cause the error listed above and would cause a device signature error on just the user and would kill the login hooks for that one login.

So for our environment just waiting an extra 30 seconds makes all the difference to getting all the login hooks to work.

Gabe Shackney
Princeton Public Schools

I have just started to see the exact same error message as gshackney above. In our environment, login hooks still seem to run but no other policies run, as the system does not checkin at any sort of scheduled interval. Only login/logout is recorded in jamf.log.

Manually attempting to run jamf policy indicates that it is already running.

I'm sure that a reboot would correct the issue on the affected systems, and I think that running killall jamf; jamf manage also corrected the situation.

The main problem from my perspective isn't correcting the situation on an individual system, but knowing when it happens and preventing it from happening.

Suddenly I'm seeing this on many of our Macs, potentially all of them... I'm opening a ticket with Jamf, this just started happening today.

Tue Nov 10 14:15:49 WSPUN003-06603 jamf[872]: Informing the JSS about login for user redacted
Tue Nov 10 14:15:49 WSPUN003-06603 jamf[872]: Error Domain=com.jamf.jamfsecurity.error Code=-50 "unlockWithPassword:error: : One or more parameters passed to a function were not valid." UserInfo={NSLocalizedDescription=unlockWithPassword:error: : One or more parameters passed to a function were not valid.}
Tue Nov 10 14:15:49 WSPUN003-06603 jamf[872]: Checking for policies triggered by "login" for user "redacted"...
Tue Nov 10 14:15:50 WSPUN003-06603 jamf[872]: Error Domain=com.jamf.jamfsecurity.error Code=-50 "unlockWithPassword:error: : One or more parameters passed to a function were not valid." UserInfo={NSLocalizedDescription=unlockWithPassword:error: : One or more parameters passed to a function were not valid.}
Tue Nov 10 14:15:50 WSPUN003-06603 jamf[872]: There was an error.

Device Signature Error - A valid device signature is required to perform the action.