Today I just ran into this same exact issue. I found that removing "Require Authentication" in the Pre-Stage Enrollment fixed it.

Without removing it, the MacBook would just be unmanaged and giving me the "The specified item could not be found in the keychain." error. Running jamf enroll -prompt fixes it.

Wanted to update given my back and forth with our TAM.

We were advised to run sudo jamf enroll -reenroll -archiveDeviceCertificate (these are hidden commands, which can be revealed by running sudo jamf help <jamf binary command> -hidden)

While the above does allow us to re-enroll our machine, this does not fix the issue during the imaging process, and as a result does not install our JSS management account or local users that normally get created during imaging. I've confirmed this behavior both when using one of our standard imaging configurations, as well as when just installing a vanilla base OS.

Have a few more things to try tomorrow ...

@aporlebeke

Same here from our TAM. I created a new configuration with just our vanilla 10.11.6 base OS (AutoDMG), and no dice on enrollment of a machine experiencing this issue. I let them know that doing manual steps after Imaging is not acceptable with 40+ global offices. It seems that this is issue is isolated to 9.96+. I stressed that this needs to be fixed in 9.98. Imaging is not a dead process yet (its coming of course) and until its timely death, it needs to continue to function as expected.

We're using AutoDMG as well, anyone having issues not using it?

@dgreening FYI, this is not isolated to just 9.96. We're still on 9.82.

@aporlebeke Funny our TAM said it was 9.96+. JOY!

SO, at the suggestion by a JAMF engineer that was passed along to me by @dgreening (thank you thank you) we were able to reimage two of our machines just by manually removing the information under User & Location in the computer entry.

We automatically collect the last logged in user on our faculty and administrator machines as part of our daily inventory collection by doing a sudo jamf recon -endUsername $(defaults read /Library/Preferences/com.apple.loginwindow lastUserName)

Working on a script to add to our imaging workflow which removes the user & location info, which I will post once I've successfully tested it.

We are a bit further back on the JSS version train, so this might not work for you, but wanted to pass along all the same.

@aporlebeke Indeed! I just confirmed that purging the User/Location data from my testers device record enabled it to re-enroll on the next run through netboot based Imaging. Nothing else had worked. It would fail enroll every single time. Relayed this back to my TAM/engineering.

Looks like the product issue which we are running into on this (needing to clear the user/location data to have enrollment work at Imaging) is PI-002950.

Good work! Guessing we can run an API call to remove those fields based on the UDID of the machine. Did clearing username alone not do the trick? @dgreening

I did not try the username alone: I cleared all of the User/Location fields. I encourage those of who who are seeing this to try that and report back.

We're now having this issue on a brand new Mac. It's never been on our JSS so it isn't in there for us to be able to delete it or clear its User or Location fields.

I've tried resetting the PRAM which has not helped.

I've tried doing

sudo jamf removeFramework

then running a QuickAdd package, which has not helped (the QuickAdd package failed).

After doing the latter I see some errors in jamf.log:

MAC010065:~ admin$ tail -n 20 /var/log/jamf.log 

Thu Feb 02 13:50:40 MAC010065 jamf[750]: The SSL certificate for (our JSS server name) does not need to be trusted.

Thu Feb 02 13:50:43 MAC010065 jamf[805]: Error Domain=NSCocoaErrorDomain Code=4 "“JAMF.keychain” couldn’t be removed." UserInfo={NSFilePath=/Library/Application Support/JAMF/JAMF.keychain, NSUserStringVariant=(

    Remove

), NSUnderlyingError=0x7fa3b1509d00 {Error Domain=NSPOSIXErrorDomain Code=2 "No such file or directory"}}

Thu Feb 02 13:50:44 MAC010065 jamf5805]: Error Domain=com.jamf.jamfsecurity.error Code=-25300 "The specified item could not be found in the keychain." UserInfo={NSLocalizedDescription=The specified item could not be found in the keychain.}

Thu Feb 02 13:50:44 MAC010065 jamf5805]: Error Domain=com.jamf.jamfsecurity.error Code=-25300 "The specified item could not be found in the keychain." UserInfo={NSLocalizedDescription=The specified item could not be found in the keychain.}

Thu Feb 02 13:50:44 MAC010065 jamf5805]: 

There was an error.



     Error enrolling computer: CRUD Operation Error - An error has occurred while creating, reading, updating or deleting a device.

We are on 9.96. I opened a support case about it but the support representative seems to be suggesting that it is a problem with our base OS image, but if that was the case then would it not affect all Macs imaged with this image? We have 10 other Macs of identical model from the same batch that have not experienced this issue.

@dgreening when you say "imaging is not dead yet but it's coming" what do you mean? Are you suggesting that in future we would need to stick with the version of macOS preinstalled on the Mac? What would we do if we needed to wipe a Mac and restore it to a stable state, if imaging will not be available? It's very difficult for us to keep pace with Apple's annual OS releases, they typically release a new version not long after we've just installed the current version.

Per 9.100.0 release notes, can now flush User & Location categories. See the 9.100.0 release notes here.

Still having this same problem. Occurs but not all the time. Using JAMFCloud.

Same errors in log with regards to SSL Certificate must be trusted, item could not be found in keychain, and "connection failure the request timed out".

Doing remove framework, doing a clean install on the machine, etc.. nothing works. Have user / location data cleared doesn't help.

The only way I can get a machine to enroll when this happens is to delete it from the JSS, and frankly I am getting a little upset at the lack of response from JAMF Support.

Any other ideas?

I am facing this issue a lot. I have enrolled about 36 macbooks till now, out of which about 10 of them went into this stage. 2 of them automatically got resolved after sometime, but others seems to be stuck until i run a removeframework and reenroll them. Any better ideas?

This has happened several times with our Mac enrollment via DEP. It is not consistent, however, and it has been tricky figuring out a root cause. With a handful of laptops, there was a certificate error and the device never checked in with the JSS.

What has definitely worked for individual laptops is executing the following Terminal command on each device:

sudo jamf enroll -prompt

Then, you can run sudo jamf recon and/or sudo jamf policy to update records and push policies.

Hope that helps!

Yes. Seeing the exact same thing. Two out of seventy-five MacBook Airs that we just reimaged came up with the error, and we've seen similar numbers with previous deployments. Running sudo jamf enroll -prompt has worked every time for us.

Hi @pkerobinson,

Thanks!

sudo jamf enroll -prompt

Did the trick for me :)

BR
Daniel

Even easier than jamf enroll -prompt is to create an Enrollment Invitation (paper airplane icon) that never expires (put the date out as far as you can) and is re-usable. Take the invitation ID that is created then you can do jamf enroll -invitation <invitation ID>. That way you do not have to enter any more dialog like you do with the -prompt method.

The only downside is that if you put a valid email address in the invitation, that user is put in as the username. At least in our environment that's what we see. So just do something like "a@a" and you get past that.

I am getting this error on at least half the macs I am manually enrolling. In may case, as it turns out, I am being inadvertently caught in our DNS filter. Setting DNS to 8.8.8.8 before enrolling is the key to success here :P

Question for you all: in the local jamf.log at enrollment, do you see ONE or TWO certificate errors? If it is two... well, you might be running into a PI which was introduced in Jamf 10.9.

I'll take a look during the next enrollment. All of the current machines I am working on have been enrolled, and reenrolled, and have had multiple Device Sig errors so I wouldn't trust those logs. On my next clean one though, I'll take a look.

I too have used the jamf enroll -prompt to fix this issue with some success but only problem with it is, if the device is sited it will re-enroll the device and fix certificate but device will be un-sited. Simple enough to re-site in the JSS on the computer record, but not ideal. So I moved to using the sudo jamf enroll -prompt -reenroll -archiveDeviceCertificate that @aporlebeke references which of course you still have to enter the JSS Username and Pass and SSH Username and Pass, which is a pain. So I then modified it to use the enrollment invitation ID that @stevewood talked about, and used that in terminal for a while but it was still became a pain to type or paste after entering necessary su and sudo on a standard user who's logged in because of the rather long syntax. So I decided to set it up as a self service policy using the execute command in Files and Process section of policy. I just pasted the command sudo jamf enroll -id <invitationIDNumber> -reenroll -archiveDeviceCertificate then set the policy to be available ongoing and then set an update inventory in Maintenance section of policy and made it available in Self-Service in our Software Update and Maintenance category. Then whenever we run into the issue we can just enable the policy, open up Self-Service on the device and run it. I didn't feel it was good idea to leave the policy enabled where user might run it so we disable policy when we aren't using it. When it is done device signature error is fixed, a new inventory is submitted and the device is still sighted in JSS. Just FYI, in testing I found this can be run over and over as long as you create invitation with the multiple uses checked and in testing I didn't see any problems or issues but not sure. I think technically you could set this up as a policy to run automatically to catch any devices that might be out there with the error that are checking in but not getting inventory updates or running policies on checkins etc. If it runs on a device that is working fine, doesn't seem to cause issues. At this point we don't know for sure and we don't see the issue a lot so will just enable when we need it and disable when done.

@rfreeborn did I see correctly that the the -reenroll and/or archiveDeviceCertificate components are new as of 10.14.0?

I opened a ticket on this. Was informed of:

PI-006766 - Race condition during MDM-first Enrollment causes enrollment to fail.

There is apparently a workaround that involves editing the QuickAddWatcher thread parameters in the jss_custom_settings table, and adjusting "failtime" it will increase the failure timeout to provide a longer window for the MDM enrollment process to complete