By the end of this article a user at CatSnackJack picks up an iPhone, signs in with the same credential they use for Outlook, and their Managed Apple Account already exists because your directory created it. The Global Administrator you needed to build the trust has been downgraded. And you know which of your existing accounts got quietly renamed on the way.
Prerequisites. A verified domain in Apple Business. A locked and captured domain, because Apple lists that as a federation prerequisite and states that if your goal is federated authentication you need to lock and capture first. That is [AB 4.1] and this sheet assumes it is done. An Entra ID account holding Global Administrator for the duration of step 2 only. An Apple Business role with permissions to configure federation, which by definition cannot be a role you will later test with. One ordinary test user in the federated domain. And an Entra tenant that no other Apple Business organisation is using, which Apple requires and which nothing will tell you at the time.
The medium. Configuring federation and sync is portal-only on the Apple side. Apple exposes no API for either, so I am not going to invent a command-line equivalent for the steps that set them up. Reading is a different matter: the Apple Business API can list users in an organisation, and Microsoft Graph can answer gate 3’s user principal name comparison in a line, so an automation-minded reader has options for the checks even though the configuration is clicks. The Entra half of the checks in step 1 can equally be done from the browser using the Users list with its column and export controls, and nothing in this sheet requires a terminal.
Naming convention. One artefact persists and wants a name: the account you use for the Entra side. Use a dedicated administrative identity, not a person’s daily account, because it will hold Global Administrator for an hour and a documented reduced role forever after, and you want that visible in an access review. At CatSnackJack it is [email protected], and the fact that it is not jo.harker is the point.
Step 1. The gates, all of them, before you touch anything
Approving federation blocks new personal Apple account creation on the domain permanently and cannot be walked back to the state before it. Everything below is browser-only and takes about fifteen minutes.
Gate 1, no conflicts. In Apple Business go to Settings, then Domains, and read the domain. If an Account Conflict message is present, stop. Select Resolve, then Download Conflicts to get the list, review it, and use Merge only where the accounts are genuinely identical on both sides. Expected result: a domain with no conflict message. This gate matters more than it looks: with conflicts outstanding, federation and sync can appear to succeed while creating no accounts at all, for anybody, including users who are not themselves conflicted.
Gate 2, no other organisation holds the domain. On the same screen, confirm there is no Domain already claimed alert. If there is, the route is Contact Apple Support and not anything you can fix yourself.
Gate 3, the UPN check, and this is the one that saves the rollout. Apple maps userPrincipalName to the Managed Apple Account, not the mail attribute. In the Entra admin center open the Users list, add the columns for user principal name and mail, and export the list to CSV from the browser. Sort and compare the two columns.
Expected result: for every user you intend to federate, the two values are identical. Any row where they differ is a user whose Managed Apple Account will be built from a name they do not recognise, possibly on a domain you have not federated. Fix those in Entra ID before continuing, or accept and document that those users are out of scope. Failure mode if you skip this: the accounts arrive, they are wrong, and correcting a Managed Apple Account name afterwards is an unnotified rename that you then have to communicate.
Gate 4, an exact domain match. Confirm the domain in Apple Business is the exact fully qualified name you intend. Apple treats catsnackjack.com and accounts.catsnackjack.com as separate domains and will not infer one from the other.
Gate 5, pick the test user now. Choose a real user in the federated domain who does not hold federation permissions in Apple Business, whose UPN equals their mail, and who will answer a message from you within the hour. Write their name down. Step 3 needs them and improvising at that point is how people end up testing with an account that structurally cannot work.
Step 2. Approve federated authentication
In Apple Business go to Settings, then Domains. Select Get Started next to User sign-in and directory sync. Select Microsoft Entra ID, then Continue. Select Sign in with Microsoft, enter the Entra ID Global Administrator user name, and complete the sign-in. Then read the application agreement, select Consent on behalf of your organization, and select Accept. Review the verified and conflicted domains if you are prompted to, then select Done.
Apple renders the five consent items as follows, and it is worth reading them rather than clicking through:
| Setting | Value | Why |
|---|---|---|
| View your basic profile | openid, profile, email | The identity claims in the token: issuer, audience, subject, tenant and user principal name. |
| Read audit log data | AuditLog.Read.All | Apple polls for password change and reset events and uses them to terminate the Apple session. This is the security payoff of federating. |
| Read domains | Domain.Read.All | Domain IDs and verification status, so Apple knows which of your domains are real. |
| Read directory data | Directory.Read.All | The user objects. Apple reuses this same grant for directory sync rather than asking again, which is why step 5 needs no credentials. |
| Maintain access to data | offline_access | Refresh tokens, so the connection survives without a human. |
Do not skip the consent checkbox. Without Consent on behalf of your organization the grant is a user consent rather than an administrator consent for the tenant, and the whole downgrade in step 6 rests on having made an organisation-wide grant in the first place. This is the one control on this screen that changes what you have actually agreed to.
Expected result: the connection is established and Apple Business shows Entra ID connected. Note that the five strings above are Apple’s rendering of the request. Whether Microsoft’s consent blade words them identically is not something I can confirm, so read your own screen rather than matching it against this table.
To find the resulting application afterwards, open the Entra admin center, go to Enterprise applications, and search for Apple. Read the Application ID off the overview blade rather than expecting a value from anywhere else. That identifier is specific to your tenant’s instance and no published source gives one. As of August 2026 the gallery listing still carries the old Apple Business Manager name, so do not conclude you are in the wrong place if the display name does not say Apple Business.
Step 3. Test with one real user
Apple gates this itself, and its stated preconditions are that the check for user name conflicts is complete and the Managed Apple Account default format is updated. Both follow from step 2 and step 1.
Read this before you click. Apple states that the federated authentication test also changes your default Managed Apple Account format. This is not a read-only test.
Select Federate next to the domain. Select Sign in to Microsoft Entra ID Portal, enter the user principal name of the test user from gate 5, and select Next. Enter their password, select Sign In, then select Done, then select Done again. Sign out of Apple Business.
The doubled Done is not a typo in this article. Apple’s procedure has two.
Expected result: the sign-in completes. Apple documents exactly two failure causes here, which are that the user name or password from the federated domain is incorrect, and that the account is not in the domain you chose to federate. If you get a failure and both of those are demonstrably false, the most likely third cause is that you tested with an account holding federation permissions, which cannot sign in federated by design.
Step 4. Enumerate who is about to be renamed, then turn it on
Verification gate, and it is the last chance to build this list. Turning federation on silently renames every existing Apple Business user whose email address is in the federated domain, changing their Managed Apple Account to match that address. Apple does not notify them and states elsewhere that you need to notify them yourself.
So before you flip the switch, go to People, then Users, and list every existing Apple Business account whose address is in the domain you are federating. Export or write it down. That list is your notification list and there is no way to reconstruct it afterwards, because after the rename the old names are gone.
Expected result at CatSnackJack: four accounts, being the two Organization Administrators from [AB 2.1] and two accounts created by hand during testing. A small number here is normal for an organisation federating early, and a large number is the signal that you should have done this before you created accounts by hand.
Now, in the Domains section, select Manage next to the domain, then Turn on Sign in with Microsoft Entra ID, and turn on the Sign in with Microsoft Entra ID toggle.
Expected result: federated sign-in is live for the domain. One thing changes immediately and it is not announced on that screen: the accounts on your step 4 list are renamed. The block on creating new personal Apple accounts is not new here, because Apple applies that at the approval step back in step 2, and your domain lock applied it earlier still. Send those people a message the same day.
Minimum operating system for a user to sign in with federated authentication is iOS 15.5, iPadOS 15.5, macOS 12.4 or visionOS 1.1. Note that this is a different floor from the one for domain capture notifications, which is iOS 18, iPadOS 18, macOS 15.1 and visionOS 2. Do not conflate the two when you scope a pilot.
Step 5. Turn on Directory Sync
In Apple Business go to Settings, then Domains. Under Directory Sync, select Set up next to the Microsoft Entra ID domain you want to sync with Apple Business. Do not go hunting for a Microsoft Entra Connect section: that phrase is a heading in Apple’s documentation, not a container in the interface.
That is the whole procedure Apple publishes, and the brevity is not an omission on my part. There is no token, no Entra-side step and no credential, because the consent from step 2 already carried Directory.Read.All.
Verification gate. The product enforces the ordering and its error message is the clearest confirmation you will get that you are in the right place: attempting sync before federation returns “Cannot turn on Microsoft Entra Connect Sync now. You must federate a domain to turn on Microsoft Entra Connect Sync.” If you see that, step 4 did not complete.
Auto Merge must be off before the first sync, because leaving it on can cause distinct accounts to be silently merged with re-imported accounts and overwrite data. Apple states repeatedly that it should be off and, as far as I can find, never says where the control lives. I am not going to print a navigation path I cannot source. Look for it on the domain management screen alongside the sync controls, and if you cannot find it, raise it with Apple support before you sync rather than after.
The attribute mapping is fixed and there is no editable mapping screen on the Apple side. Apple’s own table headed OIDC user attribute mapping reads:
| Entra ID attribute | Apple Business attribute | Required |
|---|---|---|
givenName | First Name | Yes |
surname | Last Name | Yes |
userPrincipalName | Managed Apple Account and email address | Yes |
objectId | Not shown in Apple Business, used to identify conflicting accounts | Yes |
Department | Department | No |
Employee Id | Person Number | No |
employeeOrgData.costCenter | Cost Center | No |
employeeOrgData.division | Division | No |
Apple publishes two other versions of this table on the same set of pages, differing on whether display name is carried and on the casing of half the optional fields. The three agree on the four required rows, which are the ones that matter. Do not attempt to extend the mapping: Apple warns that adding attributes not listed can break the OIDC connection through token validation failures, because it only processes the attributes it lists.
To force a cycle, under Directory Sync select the Entra ID domain, then Sync Now.
Expected result: accounts appear in Apple Business with the role of Staff and their details read-only, though the role itself stays editable. Apple states the initial sync takes longer than subsequent cycles and declines to publish a cadence for the Business guide, deferring to Microsoft’s documentation. A figure of twenty to forty minutes appears in Apple’s Deployment guide, but that page predates the 2026 rename by five months, so treat it as indicative and use Sync Now when you need certainty rather than waiting on a number.
Step 6. Hand back the Global Administrator
The elevated role was needed once, for step 2. Leaving it attached is an omission rather than a requirement, and it is exactly the kind of standing privilege a review will find eighteen months from now with nobody able to explain it.
Apple documents two supported reductions. Change the account to Global Reader, Application Administrator or Cloud Application Administrator. Or give it both Directory Reader and Reports Reader. The underlying permissions the integration actually needs are read on domains, read on users and read on audit logs, which is what those roles supply.
Expected result: [email protected] holds a read-only role and federation keeps working. Verify by running step 7 after the downgrade rather than before, because that turns this from an assumption into a test.
Step 7. The end-to-end test
Do not test by signing in to Apple Business. That proves nothing, because the accounts that can sign in there are the ones excluded from federation.
Take a user who exists only in Entra ID and has never been created by hand in Apple Business. Confirm they appear in Apple Business with the role of Staff, having arrived by sync. Then have them sign in on an Apple device with their Entra ID credential.
Then run the part that proves the security argument. Reset that user’s password in Entra ID, and observe that their Apple session terminates and challenges for reauthentication. That single action tests the whole chain: the audit log scope is granted and working, Apple is polling it, the events are being matched, and your credential lifecycle now governs Apple sessions.
Expected output: the user is signed out and prompted to sign in again with the new password. If the account arrived but the session does not terminate, the consent is incomplete and the audit log scope is where to look. If the account never arrived at all, go back to gate 1, because unresolved conflicts stop account creation while reporting success.
One deliberate exclusion from this test: do not try to prove it by signing in to iCloud on the web from a Mac. Apple states users cannot sign in to iCloud.com from a Mac unless they have first signed in with their Managed Apple Account on another Apple device, so a failure there tells you nothing about your federation.
Rollback, and what it does not undo
Federation itself is reversible, which is more than can be said for most of this series. In the Domains section select Manage next to the domain, turn off the Sign in with toggle for the identity provider, and select Confirm. Apple notes you cannot disconnect while it is in the process of enabling federation or while an account transfer process is incomplete, so a rollback in the middle of a domain capture is not available to you.
What disconnecting does not undo is the renaming from step 4, and it does not un-block personal account creation on a domain you also locked. Older writing claims federation cannot be undone without contacting Apple. That was true once and is not now, so ignore it.
Expect conflicts on reconnection. Apple maintains a documented procedure for resolving sync conflicts precisely because disconnect-and-reconnect generates them, so treat a rollback as something that costs you a conflict cleanup rather than as a free undo.
Completion checklist
No Account Conflict message on the domain. The UPN and mail comparison is done and any mismatches are fixed or documented as out of scope. The single-user test passed with a real user who is not an administrator. The pre-federation list of existing accounts is saved and those people have been told their Managed Apple Account name changed. Directory Sync is on, Auto Merge is off, and accounts are arriving with the role of Staff. The Global Administrator has been reduced to a documented read-only role and federation still works afterwards. And the password reset test terminated a live Apple session, because until that happens you have single sign-on without the security property that justified it.
One thing to put in a calendar rather than a checklist: Apple states the federation connection expires and that federation and sync stop when it does, and publishes no period. Check the connection quarterly. The alternative is finding out on the morning nobody can sign in.
Identity is done. The next part of the series stops talking about people and starts talking about hardware, beginning with how a device gets into the register at all.
Apple Business
‹ Previous: [AB 5] Federating Apple Business with Microsoft Entra ID
Next: [AB 6] How Devices Enter: Customer Numbers, Reseller Numbers, and the Carrier Channel ›
