As we got JSS updated to 9.73, Casper Imaging stopped working.
After choosing the Configuration and providing my JSS account credentials I get the error message:
"Unable to create the invitation. Check to make sure you have permission to create an invitation"
I have administrator-privilege account with everything checked on JSS User Accounts & Groups side.
Please help. Thanks!
Solved! Go to Solution.
@mhasman I had the same issue when I was imaging a machine that already existed in the JSS. I don't believe I got that error on a machine that was not in JSS. Like you, my ID has full admin privileges.
As a test, I turned off the setting "Restrict re-enrollment to authorized users only" in Global Management --> User-Initiated Enrollment. Even though, as an admin, this restriction should not apply to you, I have not had the error repeat on me.
Give that step a try and see if it helps.
@dpertschi Yes, as Administrator I have full privileges, and everything is checked in JSS Objects
@bkramps I checked, mac is not in the JSS. Checked with another mac which is 100% not in the JSS - the same error message...
Checked Global Management --> User-Initiated Enrollment, "Restrict re-enrollment to authorized users only" is off. Turned it on, tested, turned it off, tested - the same issue...
Thanks for helping! I wonder if there is anything else I may try to play with...
@mhasman It looks from your screenshot that you are doing Netboot Imaging. Do you get the same error if you do Target Mode Imaging? I don't think I got the error doing TMI? Try a TMI and see if it repeats.
What tool, if any, did you use to create the NetInstall? I had previously been using Casper NetInstall Creator but stopped using it after going to 9.73 since I had so many issues. I created my own NetInstall but the AutoCasperNBI tool works well. If you used Casper NetInstall Creator, I would try making a NetInstall with AutoCasperNBI as a test.
It is possible that switching to my own NBI fixed my issue and not turning off the setting I mentioned in my last post. I did both at the same time.
@mhasman Your solution doesn't work for us if we're netbooting the device in question. Full admin rights on Casper? No problem. Partial admin rights? Not so good. Despite granting full rights to Capser Imaging for one of our tech bench staff (who does not have full admin rights) he gets the same "Needs an invitation) error even after we option-launch Casper Imaging.
Our 10.10.4 netboot image was built -- like you -- with AutoCasperNBI.
@bentoms Thanks for the reply
@themacdweeb Where you able to figure it out?
The tech has Create Read Update. However delete is not checked. for computer objects. (Should i check it?)The user was able to image and then one day was not able to. The tech was in a group and he was the only one that was having the issue i took him out of the group and gave him custom privileges. The user is the following LDAP User, Full Access, Custom.
We also deleted and added the account back and added him back to the group however no success and like i said other users in that group are not having the issue just him.
From trial and error I wound up with these settings for techs to image (TDM and NetBoot) and use Casper Remote successfully with limited rights.....please note these are likely not exactly what are required, but they are working for me on 9.63:
Computer Enrollment Invitations -CRUD (Create, Read, Update, Delete)
Computers - CRUD
Enrollment Profiles - CRUD
Policies - CR (I think Create was needed to use Casper Remote to push software...this really needs to be a separate permission)
Users - CR (I think this was for imaging too....not sure)
Some other settings - Read only to share information, I don't think any were required for functionality.
All - Read only
Eveything except change password and send emails to users
Recon -access to both
Add Computers Remotely
Create QuickAdd Packages (this was necessary for something....probably imaging? I don't actually want them creating quick add packages)
Casper Admin - none
Casper Remote - All
Casper Imaging - just not autorun data
we don't, as a general rule, provide edit or delete capabilities to ANY L1 or L2 helpdesk staff, so our solution looked differently than yours but i think you nailed it. we edited:
JSS Objects, JSS Settings, JSS Actions to allow more create/read rights and now our staff IS able to log into via netbooted image and run casper imaging on the local device.
note: we didn't give ANY recon rights.
thank you for the suggestions, everyone and, especially, @Josh.Smith
We just encountered this like minutes ago. PI is PI-005660. This means also Jamf Admin LDAP users/groups with a period or any special characters on their UN/PW will not work. So you need to create a special user for Casper/JamfPro Imaging. But this affects JamfPro Imaging only. LDAP accounts still work on JamfPro Admin.
Unfortunately, changing passwords doesn't work in an environment like mine that enforces a minimum complexity for the passwords our provisioning technicians use. In my experience in the past, sometimes these issues can be triggered by new features that are added in an upgrade but not enabled by default, but that doesn't appear to be the case here either. Or, I can't find a smoking gun if there is one.
Bumping this thread to add that I'm in the same boat... +1 for unsolved. I too discovered this issue last week in testing a v10 upgrade:
In my environment techs make API calls via script with their credentials. Valid passwords may contain "special characters" and Unicode. Most usually do since the techs are located globally and their international keyboards make this quite easy and valid! I cannot (and should not) control valid password character ranges...
Unicode (multi-byte characters) and punctuation have always needed to be URI Escaped (see my reply for some pointers) for them to work with the v9 API but this is no longer working in v10.
The web console for Jamf Pro web and the auth screens of the Apps work in accepting non-alphanumeric characters, but anything in those apps that leverage the API are affected. Besides the invitation creation of this thread, in the Recon app if you attempt to create a QuickAdd with an account that contains a Unicode character it will fail.
Fun troubleshooting fact: if you run Wireshark/packet capture on your JSS and connect over http (port 9006) you can grab the API calls and compare the
Authorization: Basic headers. Recon v9 and v10 QuickAdd creation creates the same headers when Unicode is used, so the breakdown is not encoding or the App but the API character decoding/handling.
My Product issue is: PI-005738 up 78 since April 3rd... hmm.., Looking forward to 10.13.2 and this being fixed. Jamf: have a bug-a-thon this weekend before the weather gets too nice, it'll make for a better summer! :]
JAMF says "Currently there is a known product issue (PI-005660). That is if a password contains special characters we are not able to log in to Jamf Imaging. Currently, the only workaround is to create an account with only numbers and letters. This will allow you to log in and image machines. This product is considered critical and we are working on a resolution, but we still are not aware of an ETA when it will be fixed. "
It worked for us.
Local account with admin rights and 4 letter pw got it done. Jamf Pro 10.3.1
Other threads with the same issue:
JAMF confirmed this in a support ticket as well. I just tried again, turns out the username can't have special characters either. For a work-around, create a group with custom (or enrollment if you don't use imaging) and assign the following permissions to enroll and image.
Computer enrollment invitations CRUD
mobile device enrollment invitations CRUD
Mobile Devices CR
Allow User to Enroll - Checked
Enroll Computers and Mobile Devices - Checked
Add Computers Remotely - Checked
Customize a Configuration - Checked
Use Jamf Imaging - Checked
Use PreStage Imaging and Autorun Imaging - Checked
WOW - Just discovered this issue for the first time (had Jamf for 2 years). Running JSS 10.3.1. Never saw this bug before.
I just wasted an entire day troubleshooting this with my dektop support team. It was a freaking ! character in my password! I was hung-up thinking it was a DEP error bcause of the word "invitaion" in the error string.
This is a sloppy bug. No excuse for this. Ouch!
Fixed in 10.4?