Apple MDM Push Cert Under Personal Account - Need to move to ABM

Ok, let me see if I can clear this up. There is ABM and there is MDM. And between the two, you need a Push cert, a DEP token, and a VPP Token.

ABM is all about chain of custody. There are three main topics for chain of custody: hardware, software, and identity. ABM is a contract between Apple and your business. When you establish ABM, Apple is stating that they recognize you as a legitimate business entity and, provided your purchase your Apple hardware from a DEP-aware reseller, your hardware will be associated to your business entity at time of purchase (often before time of receipt) to permit automated device enrollment. This magic starts through Apple's activation servers (you have no direct control of these outside associating devices to an MDM in ABM). In a gross oversimplification, Apple hardware can exist in two states in Apple's activation server infrastructure: retail asset or corporate asset. When an Apple hardware device starts, it must communicate with the activation servers. When it does, it is told if it is a retail asset (unassociated to a business) or a corporate asset (associated to an MDM). The behavior of Setup Assistant is influenced by this decision. A retail asset will simple progress through Setup Assistant. A corporate asset will communicate with your MDM and behave based on the definitions in your prestage policy (enrollment policy).

Software is easier to understand. Using ABM, you purchase or license software from the App Store. Pro tip: If you have 200 devices in your environment, there is a good chance you will eventually have 201, then 210, and so forth. When licensing free software, license more than you need. $0 * 200 = $0 * 500. The benefit is that your fleet can grow and you don't need to keep looping into ABM to add licenses. Get more than you think you will ever need. Your future self will appreciate your current efficiency efforts.

Identity is creating a link between ABM and your identity provider. This does not have a direct impact on your MDM unless you are doing shared iPad or you are using managed Apple IDs to enroll devices or access specific Apple ID-dependent functions. Identity is the federation (link of trust) between ABM and your identity provider (Microsoft). This was discussed in the first post regarding managed Apple IDs. Many organization I support never make it here. They see no need for Apple IDs and thus will stop at domain lock (prevent creation of future IDs using the company's domain). Traditionally, not federating made sense but Apple is expanding the capabilities and the necessity to use an Apple ID. Things like continuity, universal control, and iPhone Mirroring require devices be signed into an Apple ID. Just a few years ago, these services did not exist. Today, many users are issued multiple devices and to get the most benefit managed Apple IDs are become more relevant and useful.

Ok, primer complete. Now to your desire to implement automated enrollment and volume licensing. As I noted, to setup your MDM, you need a Push cert, a DEP token, and a VPP token. What you must understand is that you DO NOT need to use the same account for all three. In a school system for example, you may have three levels, elementary, middle, and high school. This school district has one Apple School Manager (educator version of ABM) and three MDMs, one for each level. The IT directory may have the credentials for the Push and will manage that annually on each MDM. However, in ASM (ABM), the director creates sub-admins for each school. They each has access to their individual VPP token and able to license software for the needs of their individual school level. Thus, three additional IDs are used for VPP (note, you must created locations to have more than one VPP token - do not try to use one token on multiple MDMs).

This means that in your case, using user@business.com to manage the Push cert while using user@business.appleaccount.com to access and import your DEP and VPP tokens is completely legitimate and very common. The IDs on these items DO NOT need to be the same.

Next, the annual refresh. Please understand the Push is the critical item. Never, ever, ever, allow it to expire and always use the originating ID to RENEW the cert. This is critical. Failure to renew the Push cert can result in total loss of control of your environment.

If I understand your concern, it is that the Apple ID used to create the Push cert is a personal Apple ID that happens to use your company's domain in the username.

I will tell you that your proposed solution is a terrible one. If you create a new Push cert, you will be forced to re-enroll all of your devices. This will require an erase of the devices and a re-enroll if you want to gain full supervision. (Ok, technically, your Macs can be enrolled without erasing but only if they are unmanaged first and then enrolled using the profiles command)

I am going to recommend that you initially do nothing. If you have control of user@business.com, you will be able to renew your cert annually and everything will be fine. The fact that it is not in ABM (a managed Apple ID) is not important. Please note, many other organizations are in the same boat that you are. The reason is that managed Apple IDs did not always exist. Deployments as old as 2 years likely have personal Apple IDs used for Push Cert creation. This is more common than the use of a managed Apple ID simply due to the timing of Apple's feature releases.

Ok, now that you have done nothing and everything is still working, you can start considering how to migrate personal Apple IDs to managed Apple IDs. The first step you can perform is to lock your domain in ABM. Locking the domain will have no impact to existing Apple IDs that use your company's domain. Locking the domain will simply prevent people from creating new IDs that include your domain. Once you lock the domain, you cannot unlock without removing the domain from ABM and repeating the verification process. If an Apple ID is needed that uses your domain, it will need to be created by your in ABM and the user will receive an invite.

Next, and this is the hard part, is deciding if you want to continue. The step after locking the domain is to Capture the domain. Capturing the domain will notify all existing Apple IDs user that use your company's domain to either "transfer to a work account" or "keep as a personal account." This will come as an email to the users and they will have 30 days to complete the decision.

At this point, you will receive the notice on the Push ID account's email and you will opt to "transfer to a work account." This will convert the ID to a managed Apple ID and you will retain access to the Push portal.

Ah, but so will all your other users. And there are deeper implications (potantially). Managed Apple IDs cannot participate in commerce. So no credit cards, no subscriptions, and no purchases. If you used user@business.com for things other than the Push cert, you may lose access to some purchases.

The final step would be to enable Federation and Sync. If you want to issue all staff members a managed Apple ID, but you don't want to manually create them, used Federation and Sync. This will allow ABM to sync to your identity provider and when you add a new user in the IdP, they will automatically sync to ABM and be issued an Apple ID.

Ok, hope this is helpful. Don't ruin your life by creating a new Push cert. Terrible idea.

DEP and VPP also need to be updated each year. However, these are more forgiving. If you forget to update them, you will have service disruption (will not be able to enroll new devices and VPP software will not install). However, renewing the tokens after expiration will solve the issue with no lasting impact to the fleet. And, most importantly, you can use a different ID for DEP and VPP each year. You can delegate this to a subordinate and they may use their ID to update these tokens.

On DEP and VPP, the IDs are not really important like with the Push cert. The DEP token is a trust token linking the MDM to ABM to retrieve device records. That is basically it. The token allows periodic checkin to ABM for new devices. In the case of Intune, this is glacial 24 hour cycle which can be frustrating if you are expecting results that are not present. Get used to pressing the refresh button and waiting for updates. In the case of VPP, the ID is technically the app owned, but assuming your are doing device assignment, this is swept under the rug. If you have not done so already, go to ABM and review or create your MDM server. This requires access to Intune as you will need to export a private key from the MDM. Import that into ABM and this will create the token. Export the token and import it into your MDM. Assign your assets to the token in MDM and then define the auto-assignment behavior for future devices.

Keep in mind, if you are new to this and need help, Apple's Consultant Network is filled with capable profession MDM implementors in your region (or beyond).

I hope this helps understand the architecture and the role of the certs and tokens. The bottom line is using one ID for push and another for DEP and VPP is fine. And having the ID used for push NOT be a managed Apple ID is also fine. Yes, you can align the IDs through identity federation. But it is not worth it unless your goal is to embrace managed Apple IDs as a whole.

Sorry, wrote so much I exceeded the 5000 character limit. Sorry for the split post.