My colleague had cause yesterday to change the password that is associated with the Apple ID that they use to login to Apple School Manager. This is the account that we normally (but not always) use to create DEP Tokens and VPP Tokens. In general, we use Managed Apple IDs to log in to Apple School Manager.

It shouldn’t matter what the reason for changing the password is, but, for context, this is why:

MDM-based Activation Lock

We had a message from a customer that after they rebuilt two iPhones that were previously enrolled via Automated Device Enrollment (DEP) into their Jamf Pro instance. Both iPhones could not be setup because they reported locked with Activation Lock. The account to unlock them showed as the Apple ID used to create the DEP Token. The only way to unlock the device was for the customer to come to our office (2km away from their office), so that my colleague could enter the password. My colleague works part-time, so the customer had to wait a day before the devices could be unlocked.

We decided that since Activation Lock is confined to a specific user in School Manager, the Apple IDs used for assigning DEP Tokens need to be accessible by all members of the team. So, we changed the password to a non-personal one and added it to our joint password manager.

DEP Sync failed ⛔️

Shortly afterwards we started noticing a lot of errors in the JAMFSoftwareServer.log files of all our Jamf Pro instances, such as this:

12:01:10 [ntInstanceSyncCommService] - com.jamfsoftware.jss.objects.streamlinedenrollment.service.DeviceEnrollmentProgramException: An error occurred during oauth token refres

These messages were accompanied by error messages in the Jamf Pro, in Settings > Global Management > Device Enrollment Program:

And in School Manager, the last sync was shown as several hours ago, exactly around the time the password was changed:

We have to download a new DEP Token for every MDM location 😟

That was too much of a coincidence, so I downloaded a new DEP token and uploaded it to the relevant Jamf Pro instance. Sure enough, DEP synchronisation resumed. After a big sigh, we started the manual process of generating new DEP Tokens for all of the Jamf Pro instances where the previous token had been generated by the Apple ID that had had the password changed, logging in to each Jamf Pro instance in turn, and uploading the token.

We checked Apps & Books too, since the VPP tokens had been generated by the same account. But we were able to add licenses to a software title and sync the changes to the Jamf Pro instance without any problem. So, it seems to be a problem with DEP only.

Enterprise…? 👎

I created a Support Ticket via AppleCare Enterprise and got some disappointing answers:

this is expected behaviour. If the main DEP account password gets reset the VPP token has to be renewed as this is bound to each other.

Also once a year you’ve to renew the DEP/VPP tokens so this in general is not an issue

What was the reason for the password reset ?

Firstly, we don’t use the main DEP account to generate DEP tokens. If that is a known requirement, I missed that documentation. We were encouraged to create new Managed Apple IDs to perform administration within School Manager, so whoever has the task to renew the DEP Tokens at any particular time, theirs is the Apple ID used.

Secondly, asking why a password should be reset is a surprising response. Rotating passwords is a common and healthy thing for administrators to do. But I did explain that the poor design of MDM Activation Lock was the reason. And just because we have to do this tedious manual task every year doesn’t mean we should have to do it additionally whenever we change staff or need to change a password.

Thirdly, this is an enterprise service! None of the functions that are done within School Manager should be tied to a particular account, and even less should they be dependent on the password of that particular account!

Imagine if all the changes you made in Active Directory using your AD account were rendered non-functional when you changed your password? It’s unthinkable.

And, finally, although we did not seem to be affected, the answer from AppleCare was that the VPP Tokens should also be renewed:

if you change the VPP account password the VPP token has to be renewed.

I’ve opened two Feature Requests with AppleCare Enterprise:

1. DEP Token generation should not be linked to a specific Apple ID, but rather to the ASM Account itself. There are valid security reasons why rotating an account password should be possible, and it makes no sense that changing the password would cause such a mass loss of service.

2. Activation Locked devices that were locked by MDM should not be linked to a specific Apple ID, but rather to the ASM Account itself.

Conclusion

Any of you who work with multiple MDM Locations would be negatively impacted by this “expected behaviour”.

• What if your password is compromised?
• What if the member of your team that generated the tokens left your company?

Rotating passwords is a normal operation. Changing a individual user’s password should not break a live enterprise service. And Activation Lock that is done via MDM should not be linked to an individual’s account.

Apple need to sort these out. I urge anyone reading this to open cases, Feedbacks and Feature Requests with Apple to raise impact.