10.14.5 DEP problem creating user account

I did see that error a couple times the other day, but it wasn't with 10.14.5. I don't know what exact version these were on, but they were Macs that were unboxed last week so 10.14.5 would not have been on them yet. I think we simply rebooted and it still booted to the login screen as if there was no problem.

Thanks for letting me know, I also noticed that I had no User Profiles after the reboot... Did you notice that on your by any chance? Device profiles seem unaffected.

Sorry, I don't use user profiles.

We've seen this for a while intermittently on 10.14.x and 10.15.x. Unable to reproduce consistently, and factory resetting the device using option-cmd-r usually fixes it. I have logged a case with Jamf but would be interested to know if anyone knows the root cause...

We are seeing this as well in our environment. Seems intermittent and not specific to OS. Anyone hear back from JAMF? @myronjoffe we also have cases open with Apple/JAMF.

@JackLaRocca ended up closing the case with jamf as they needed logs and the device had already been re-provisioned. did you manage to get further into the root cause?

@myronjoffe still working with them. We are on 10.21 and still seeing it... :/

Hi Folks, this issue was hard to diagnose as we didn't see anything in the logs on either the JSS side or the client side pointing to the problem.

The issue is the root CA cert, which in our case was from InCommon.

What we did to fix it was 1) generate fresh SSL certs, then 2) create the Tomcat P12 cert, 3) move the certs into the correct location on our JSS, and 4) stop and restart Tomcat.

You can test to see if your server has this problem by using the following command:

openssl s_client -connect yourjss.example.com -port 8443

Run the above command from a Mac or Linux machine (don't know how to do this in Windoze).

In the Certificate chain section, if you see the words "AddTrust" then you have this problem and need to fix it.

For example, you'll see "AddTrust: in the last three lines here:

Certificate chain
 0 s:C = US, postalCode = 12345, ST = California, L = San Francisco, street = 124 Main Street, street = Boss Office, O = "University of SF", OU = CRM, CN = myjss.example.com
   i:C = US, ST = MI, L = Ann Arbor, O = Internet2, OU = InCommon, CN = InCommon RSA Server CA
 1 s:C = US, ST = MI, L = Ann Arbor, O = Internet2, OU = InCommon, CN = InCommon RSA Server CA
   i:C = US, ST = New Jersey, L = Jersey City, O = The USERTRUST Network, CN = USERTrust RSA Certification Authority
 2 s:C = US, ST = New Jersey, L = Jersey City, O = The USERTRUST Network, CN = USERTrust RSA Certification Authority
   i:C = SE, O = AddTrust AB, OU = AddTrust External TTP Network, CN = AddTrust External CA Root
 3 s:C = SE, O = AddTrust AB, OU = AddTrust External TTP Network, CN = AddTrust External CA Root
   i:C = SE, O = AddTrust AB, OU = AddTrust External TTP Network, CN = AddTrust External CA Root

@dniven I don't think this is related to the issue as we have the complete certificate chain (Digicert root CA) and still saw the issue.

@danwestbrook

Hey All. Update from our Apple Care and JAMF support cases. In our case the root cause for this issue was that we had login/logout hooks enabled and in use for a policy executing immediately after enrollment of DEP machines. After disabling the hooks via "Settings > Computer Management (framework) > Check In > Uncheck Login/Logout hook" and removing the login logout triggers from policies, our account creation(via apple setup) problem went away. I recommend you try this in your environment. Guidance is that the login/logout hooks are deprecated tech and not recommended to be used by apple or JAMF. They ultimately cause the jamf agent to hang and make the apple setup account creation pane time out.

https://www.jamf.com/jamf-nation/discussions/27703/login-logout-hooks-deprecated-technology

@JackLaRocca Im not so sure that you've identified the root cause. Our very first policy triggers off Enrollment Complete or Recurring check-in and Not the login hook and we still saw the issue.

@myronjoffe we had the same workflow and no login triggers...simply having it enabled in settings created churn and the endpoint still loaded login/logout hooks and searched for policies triggered by it