Posted on 02-14-2017 11:20 AM
I am setting up a new JSS server on Windows 2012 R2 and I am receiving this message int he JAMF.log.
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.}
I am able to apply Managed Prefences and Policies, but I cannot get Configuration Profiles to apply.
Any suggestions or has anyone seen this error before?
Posted on 02-15-2017 03:22 AM
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...
Posted on 02-16-2017 08:12 AM
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.
Posted on 03-06-2017 09:42 AM
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.
Posted on 03-06-2017 09:44 AM
@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.
Posted on 03-06-2017 10:49 PM
@TexasITAdmin , PI-002269 is the same defect that was reported to me...
Posted on 03-15-2017 08:38 AM
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.
Posted on 03-15-2017 08:50 AM
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
Posted on 03-31-2017 10:19 AM
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.
Posted on 04-03-2017 06:15 AM
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.
Posted on 04-27-2017 07:49 AM
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"
Posted on 04-27-2017 12:28 PM
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.
Posted on 04-27-2017 04:55 PM
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)
Posted on 06-05-2017 07:43 AM
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.
Posted on 11-15-2017 01:07 AM
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).
Posted on 06-22-2018 11:59 AM
@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?
Posted on 01-21-2020 01:11 AM
I'm seeing this now on v10.15.....
Posted on 01-21-2020 01:17 AM
And, It seems that PI 002269 is STILL a known issue???
Since 2017?????
I really am starting to lose confidence in JAMF.
poor show!
Posted on 01-31-2020 07:49 AM
@kerouak Dealing with this now myself and agree 100%.
Posted on 04-29-2020 05:29 AM
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.
Posted on 08-04-2020 09:37 AM
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
Posted on 08-04-2020 07:13 PM
@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
Posted on 08-05-2020 04:30 AM
@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.
Posted on 08-21-2020 07:29 AM
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.}
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
Posted on 11-10-2020 08:18 AM
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.
Posted on 11-10-2020 12:34 PM
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.
Posted on 06-01-2021 10:46 AM
Seeing this issue now on my Big Sur machines. AD bound mobile users. No previous issues until this point. I did change login hooks to run in the background as part of my Big Sur testing. I have not yet changed that back to see if it makes a difference.