A box of 40 new iPads landed on my desk the same morning a user emailed asking to get her personal iPhone on work email. Two devices, two completely different jobs. You do not enroll a pallet of company iPads the same way you onboard one person's phone, and picking the wrong path means wiping and starting over. So here are the iOS/iPadOS enrollment methods in Intune, which ones are built for bulk, which are single shot, and who each one is actually for.
The Devices area of the Intune admin center, where enrollment lives. Source: Microsoft Learn.
Before anything: the Apple push certificate
Nothing Apple enrolls without an Apple MDM Push certificate. It's the handshake between your tenant and Apple's push service, and every single method below depends on it.
Set it up under Intune admin center > Devices > Enrollment > Apple > Apple MDM Push certificate. Two gotchas that bite people. Use a dedicated service Apple ID, not a real person's account, because whoever owns it is now load-bearing forever. And it expires every year. If that certificate lapses, every iOS and iPadOS device you manage silently falls out of management at once, and there's no quick undo.
Quick answer on WIP, MDM, and MAM
People ask whether these methods set up WIP, MDM, or both. Short version: WIP doesn't exist on Apple. Windows Information Protection is a Windows only feature, so no iOS enrollment method touches it. On Apple you have two lanes instead. MDM means the device is enrolled and managed. MAM means App Protection Policies protect the work data inside apps without enrolling the device at all. Every method here lands in the MDM lane, except plain App Protection Policies, which is the MAM lane for personal phones you never enroll.
Single-shot methods, mostly for personal devices
These are one device at a time, driven by the user, and they lean toward bring your own device.
Device enrollment with the Company Portal
The classic path. The user installs the Intune Company Portal from the App Store, signs in, and follows the prompts to install a management profile.
User installs Company Portal and signs in with their work account.
Company Portal walks them through downloading the management profile.
They open Settings, and here's the gotcha, they must manually tap to install the profile under General > VPN & Device Management. iOS will not auto-install it.
The device checks in and policies apply.
This gives the device user affinity, so it ties to a person and gets their apps and email. It's not supervised, so you get the smaller set of controls Apple allows on user-owned devices.
Web-based device enrollment
The newer BYOD path. The user starts enrollment in Safari instead of leaning entirely on the Company Portal app up front. You turn it on under Devices > Enrollment > Enrollment types by creating an enrollment type profile and assigning it to a group. Same result as Company Portal enrollment, user affinity and MDM, just a slightly smoother start. They still need Company Portal afterward to get to company apps.
Account-driven user enrollment
This is the privacy-first BYOD option, and it replaced the old profile-based user enrollment. It uses a Managed Apple ID alongside the person's personal Apple ID, and it only manages the work side. You cant wipe the whole phone or see personal apps, which is exactly what nervous employees want to hear.
It needs a few things lined up first. Apple Business Manager, federation between Managed Apple IDs and Microsoft Entra, and iOS 15 or later. Configure it under Devices > Enrollment > Enrollment types. Use this when people balk at full device enrollment on a phone they paid for.
Bulk methods, built for corporate devices
These are how you handle a pallet of company hardware without touching each screen by hand.
Automated Device Enrollment, the big one
Automated Device Enrollment, or ADE, used to be called DEP. This is the zero-touch method. A device enrolls the moment it's turned on and connects to Wi-Fi during Setup Assistant, before a user ever gets it. It supervises the device, which unlocks the full set of restrictions, and it scales to thousands.
In Apple Business Manager, connect your organization to Intune and assign your devices to the Intune MDM server.
In Intune, go to Devices > Enrollment > Enrollment program tokens and upload your ABM token.
Sync, so Intune pulls in the device serial numbers Apple assigned to you.
Create an enrollment profile that defines the Setup Assistant experience and whether the device gets user affinity.
Assign the profile to your devices. Next time they wipe and boot, they enroll on their own.
Syncing ADE devices from Apple Business Manager into Intune. Source: Microsoft Learn.
The gotcha is upstream. A device can only use ADE if it lives in Apple Business Manager, which means you bought it through Apple or an authorized reseller, or you added it manually with Apple Configurator. The token also expires yearly, so put a reminder on it just like the push certificate.
Apple Configurator
When devices arent in Apple Business Manager, Apple Configurator is the fallback. It runs on a Mac and you plug the iOS devices in over USB. It comes in two flavors, and the difference matters.
Setup Assistant with modern authentication. Supervises the device, gives it user affinity, and the user signs in. Good for corporate devices going to a specific person.
Direct enrollment. No user affinity, no Company Portal, and the device isnt wiped. Built for shared corporate devices that nobody personally owns, like a pool of loaner iPads.
The honest gotcha is that Configurator means a Mac, cables, and hands on every device. Fine for a drawer of iPads. Miserable for a thousand.
iOS/iPadOS enrollment methods matrix: who each is for
Method
Bulk or single
Owner
Supervised
User affinity
Managed as
Company Portal enrollment
Single
Personal or corporate
No
Yes
MDM
Web-based enrollment
Single
Personal or corporate
No
Yes
MDM
Account-driven user enrollment
Single
Personal (BYOD)
No
Yes, Managed Apple ID
MDM, work data only
Automated Device Enrollment
Bulk
Corporate
Yes
Optional
MDM
Configurator, Setup Assistant
Bulk, hands-on
Corporate
Yes
Yes
MDM
Configurator, direct enrollment
Bulk, hands-on
Corporate, shared
No
No
MDM
App Protection Policies
n/a
Personal
n/a
n/a
MAM, no enrollment
Blocking what you don't want
Enrollment methods decide how devices come in. Enrollment restrictions decide which ones you let in at all. Under Devices > Enrollment, device platform restrictions can block personal iOS devices while allowing corporate ones, and device limit restrictions cap how many devices one person can enroll. Set these before you open the gates, not after.
Blocking personally owned devices with a platform restriction. Source: Microsoft Learn.
Putting it together
That covers the iOS/iPadOS enrollment methods worth knowing. Pick the method by who owns the device and how many you have. Corporate hardware at scale goes through Automated Device Enrollment, full stop. Corporate devices that never made it into Apple Business Manager fall back to Apple Configurator. A personal phone that just needs email is Company Portal or web-based enrollment, or account-driven user enrollment when the person wants their privacy protected. And if you only care about the work data and not the device, skip enrollment and use App Protection Policies. Whatever you choose, set your enrollment restrictions first and never let that Apple push certificate expire.
What can we learn as a person
The push certificate is the part that stuck with me. One quiet certificate sits under all of it. You set it once, you forget it, and it just works for a year while you handle louder problems. Then it lapses, and every device you thought you had a handle on silently stops listening to you, all at once, and you didnt even feel it happen.
I have certificates like that in my own life. The quiet standing thing that holds everything else up. Sleep. A weekly call with someone who matters. The half hour that keeps me sane. None of it screams for attention, so it's the first thing I let expire when the box of iPads lands on the desk. And then one day everything I was managing just quietly disconnects, and I finally look down and realize the cert lapsed months ago.
So what's the quiet certificate holding up your whole setup right now, the one you keep meaning to renew? And when does it expire?
I used to lose an afternoon every time I wanted a throwaway LAMP stack. Install PHP, fight the Apache config, remember which MySQL socket the thing wants, google the same permissions error I googled last year. Last week I did none of that. I opened Claude Code in an empty folder, told it what I wanted, and watched it write the files, start the containers, and hand me a working page. This is how AI and Docker fit together for that kind of grunt work, and how to build a small LAMP stack with a basic HTML page without touching a config file yourself.
What you need first
Docker Desktop installed and running. On Windows or Mac, that is the whale icon in your tray. If it is not green, nothing below works.
Claude Code installed and signed in. It lives in your terminal, not a browser.
An empty folder for the project. Make one so Claude has a clean sandbox to work in.
That is the whole shopping list. You do not install PHP, Apache, or MySQL on your actual machine. They live inside containers, and Docker keeps them off your real system.
How Claude Code actually touches Docker
Claude Code runs commands in your terminal. That is the trick. It has no special Docker plugin. It just runs the same docker commands you would type, reads the output, and reacts to it. When it runs docker compose up, that command talks to the Docker daemon, and the daemon runs your containers. Claude is sitting where you normally sit.
Because it can read command output, it can debug. If a container crashes, it reads the logs, sees the error, and fixes the file that caused it. You are not copy pasting stack traces back and forth. It watches the same screen you would.
Claude Code stands in the client spot, running the same commands you would. Source: Docker Docs.
The one setting that keeps you safe
By default Claude Code asks before it runs anything. A box pops up showing the exact command, and you approve or deny it. Keep it that way while you learn. You will see every docker command before it runs, and you can say no.
There is a flag called --dangerously-skip-permissions that turns the prompts off. The name is not a joke. Do not use it for this. Watching the commands go by is how you learn what the AI is doing, and it is how you catch the one time it wants to do something you did not intend.
Building the LAMP stack
Open your terminal, move into the empty folder, and start Claude Code.
mkdir lamp-demo
cd lamp-demo
claude
Now give it a real prompt. Be specific about the parts you care about, and let it pick the boring details. Something like this works well:
Build a LAMP stack with Docker Compose in this folder. Use PHP 8.3 with Apache, and MariaDB for the database. Put the web files in a src folder mounted into the container so I can edit them live. Serve the site on localhost port 8080. Add an index.php that connects to the database and prints a success message, and a plain index.html landing page. Then bring it up and confirm it works.
The compose file it writes
Claude will write a docker-compose.yml, a src/index.php, and a src/index.html. The compose file it produces looks close to this.
The ./src:/var/www/html line is the important one. It mounts your local src folder into the container, so the file you edit on your disk is the file Apache serves. Change index.html, refresh the browser, see it. No rebuild.
The mounted folder is why your edits show up without rebuilding. Source: Docker Docs.
The PHP page it writes
The PHP file it writes will connect to the database using the host name db, because inside the compose network the database container is reachable by its service name. That part trips up beginners, and it is nice to watch the AI just get it right. A minimal version reads like this.
<?php
$conn = new mysqli("db", "appuser", "apppass", "appdb");
if ($conn->connect_error) {
die("Database connection failed: " . $conn->connect_error);
}
echo "LAMP stack is alive and talking to MariaDB.";
Bringing it up and checking it
Claude will offer to run the command. Approve it.
docker compose up -d
First run pulls the images, so give it a minute. When it finishes, open a browser.
http://localhost:8080/index.html shows your plain landing page.
http://localhost:8080/index.php shows the database success message.
You can also open Docker Desktop and look at the Containers tab. You will see two containers, web and db, both running. Click either one for logs, a shell, and the file system, all in the same window.
If the PHP page throws a connection error on the very first load, the database container is usually just still starting. Wait a few seconds and refresh. If it persists, tell Claude the exact error and let it read the logs. That back and forth is the whole point.
Tearing it down
When you are done poking at it, stop everything.
docker compose down stops the containers and keeps your database data.
docker compose down -v stops them and deletes the database volume too, for a clean slate.
Your src folder stays on disk either way, because it lives on your machine, not in the container.
Wrapping up
The pattern is small and it repeats. Empty folder, clear prompt, approve the commands, check the browser. Claude Code writes the compose file and the pages, Docker runs them in throwaway containers, and the mounted folder lets you edit live. Keep the permission prompts on so you see every command, review the compose file before you run it, and use docker compose down -v when you want to start over. Once this clicks, standing up a test environment stops being a chore and starts being a sentence.
What can we learn as a person
For years I treated asking for help as cheating. If I did not build the LAMP stack by hand, config file by config file, it did not count. I carried that into more than terminals. I would white knuckle a problem alone because using the tool felt like admitting I was not smart enough to go without it.
Watching an AI stand up in twenty seconds what used to cost me an afternoon poked a hole in that story. The people I respect most are not the ones who refuse the tools around them. They are the ones who know which tool to reach for and are not too proud to reach. A calculator did not make anyone worse at math. It freed them up to think about the harder thing.
We are surrounded by tools, and I do not just mean software. A therapist is a tool. A friend who is good at the thing you are bad at is a tool, in the kindest sense. A checklist, a calendar, a person who will just sit with you. I spent a long time refusing to use any of them because I thought struggling alone was the honest way to live. So where in your life are you still doing everything by hand, when there is a tool right next to you that you have been too stubborn to pick up?
I found a service account last month with a password set in 2016. It ran SQL, it had a service principal name registered, and its password was set to never expire. Someone even helpfully wrote the password in a OneNote called "IT Passwords." That account is a loaded gun pointed at the whole domain, and the fix has been sitting in Active Directory for over a decade. Group Managed Service Accounts kill this problem for good.
If you're hardening AD and you already audited who's in Domain Admins, this is the next box to check. Your service accounts are probably worse.
Why an old service account password is a gift to attackers
Any service account with a registered SPN is kerberoastable. Here's the short version of the problem. Any domain user, even a low-privilege one, can request a Kerberos service ticket for that account. The ticket comes back encrypted with the account's password hash. The attacker takes it offline and brute-forces it at their leisure, with no lockout and no alarm.
A short or old or reused password falls in minutes. And once they crack it, they own whatever that service could touch, which for a SQL account is usually a lot. Microsoft's own guidance for stopping kerberoasting says it plainly. Replace the user account with a Group Managed Service Account.
What Group Managed Service Accounts actually do
A gMSA is a domain account where Active Directory owns the password, not you. When you point a service at one, the operating system takes over credential management completely.
The password is 240 bytes of random. No human picks it, and no human ever sees it. It never lands in a OneNote.
It rotates every 30 days on its own. Active Directory changes it automatically, and the member servers pull the new one. Nobody schedules a change or plans an outage.
It works across a server farm. That's the "group" part. Multiple hosts behind a load balancer can share one gMSA identity.
It manages the SPN for you. You set the service principal name when you create the account, and Kerberos just works.
Now run the kerberoasting math again. An attacker can still request that ticket. But a 240-byte random password that rotates every 30 days is not getting cracked offline before it changes again. You didnt hide the account. The loot is just worthless now.
First, find your kerberoastable accounts
You cant fix what you havent found. Start by listing every user account that has an SPN, because those are the roastable ones.
Look at that PasswordLastSet column and prepare to wince. If you run Microsoft Defender for Identity, its Service accounts inventory finds these for you, flags the ones with a password set to never expire, and separates real gMSAs from plain user accounts pretending to be service accounts.
Defender for Identity inventories your service accounts and flags the risky ones. Source: Microsoft Learn.
Setting up a gMSA, step by step
You need a 2012 or later domain functional level, a host running 2012 or later, and the AD PowerShell module. From there its four moves.
Create the KDS root key, once per forest
The Key Distribution Service root key is what AD uses to generate gMSA passwords. You only make it once for the whole forest.
Add-KdsRootKey -EffectiveImmediately
In production that key needs about 10 hours to replicate before it works, so create it early and go do something else. In a lab, there's a flag to make it effective right away, but dont use that shortcut in prod.
Create a group for the hosts
Make a security group and add the computer accounts that are allowed to use the gMSA. Then create the account and point it at that group.
Test should return True. If it doesnt, check that the host is in the group and that the group membership has replicated.
Point the service at it
In the service's Log On settings, enter the account as CONTOSO\svc-sql$ and leave the password blank. That trailing dollar sign matters. Start the service and you're done. You will never type that password, because it doesnt have one you could type.
Before you go all in
A few honest limits, because gMSA isnt a fit for absolutely everything.
Not every app supports it. SQL Server, IIS application pools, and scheduled tasks on modern Windows are fine. Failover clustering isnt, and some third-party apps arent. Test before you commit.
You cant interactively log on with one. A gMSA runs services, it doesnt sit at a desktop.
Mind the 10-hour KDS wait. Plan the root key ahead of your first real deployment so you're not stuck waiting.
Dont put service accounts in Protected Users. That group breaks them. Use a gMSA for the service and Protected Users for your human admins.
Putting it together
Find your SPN user accounts, then replace the important ones with Group Managed Service Accounts. Create the KDS root key once, make a group for the hosts, create the account with New-ADServiceAccount, install and test it on the servers, and repoint the service with a blank password. Active Directory handles a 240-byte password that rotates every month, and the kerberoasting attack that owned your old account just stops working. Start with your SQL accounts, since those are usually the fattest target.
What can we learn as a person
The 2016 password is the thing I cant stop thinking about. It made sense the day someone set it. Then the world kept moving and it never changed, and the exact thing that was supposed to protect the account slowly turned into the easiest way in.
I have passwords like that. Rules I set for myself in a hard year that made total sense then, and I never rotated them. A way of protecting myself that fit who I was at the time, kept unchanged so long that it quietly became the vulnerability instead of the defense. The genius of a gMSA isnt that the password is strong. It's that it never stops changing, so no single old version of it can be used against me forever.
So whats your 2016 password? What defense did you set once, a long time ago, that you've never once rotated since?
A pentest report crossed my desk where the whole domain fell in about twenty minutes. No cracked domain admin password, no phishing, no malware. The attacker asked a forgotten certificate server for a certificate that said "I am the domain admin," and the server politely handed it over. Thats the quiet reality of AD CS attacks. Your certificate authority is a domain admin factory, and almost nobody audits it.
Maybe you've hardened your tier model and locked down who's in Domain Admins. If you never looked at Active Directory Certificate Services, you left the back door wide open.
Why a certificate is as good as a password
Certificates authenticate. A certificate that identifies you as a domain admin logs in exactly like the real one. Worse, it doesnt care if you reset the password afterward. The certificate stays valid until it expires, which might be a year or more.
So a single misconfigured template or CA is enough. An unprivileged user can request a certificate for a privileged account and quietly become them. Security researchers cataloged these escalation paths as ESC1 through ESC8. They sit at Tier 0, right next to your domain controllers, and they rarely get a second look.
The template misconfigs: ESC1 through ESC4
Most AD CS attacks start with a certificate template that trusts the wrong people or asks too few questions.
ESC1, a template lets the enrollee supply their own subject, has a client authentication EKU, and allows unprivileged users to enroll. Any user can request a cert as anyone, including a domain admin. The "Supply in the request" setting is the single most common cause.
ESC2, a template has the Any Purpose EKU or no EKU at all, so an issued cert can be used for almost anything an attacker wants.
ESC3, a template grants the Certificate Request Agent EKU, letting a holder enroll on behalf of other users.
ESC4, the template object's own ACL or owner is weak, so an unprivileged user can rewrite the template into an ESC1 whenever they feel like it.
Defender for Identity flags the ESC1 template misconfiguration. Source: Microsoft Learn.
The fixes rhyme across all four. Turn off "Supply in the request." Strip authentication EKUs from templates that dont need them. Remove enroll rights from groups like Authenticated Users and Everyone. Require CA manager approval. And unpublish any template you dont actually use, because a template nobody can request cant be abused.
The CA and endpoint misconfigs: ESC5 through ESC8
The second half moves from templates to the certificate authority itself and how people reach it.
ESC5, someone has control over the CA's own AD objects, like the CA computer account or the PKI containers in the configuration partition. Control those and you control the whole PKI.
ESC6, the CA has the EDITF_ATTRIBUTESUBJECTALTNAME2 flag turned on, which lets any request specify its own subject alternative name no matter how the template is configured.
ESC7, an unprivileged user holds Manage CA or Manage Certificates rights, so they can approve their own requests or flip on the ESC6 flag themselves.
ESC8, the web enrollment endpoint accepts NTLM over plain HTTP, so an attacker can relay a domain controller's authentication and get a certificate as that DC.
Defender for Identity flags the ESC7 CA ACL misconfiguration. Source: Microsoft Learn.
Remediation here is mostly about access and flags. Pull Manage CA and Manage Certificates rights back to a small, trusted group. Turn off the SAN flag with certutil -setreg policy\EditFlags -EDITF_ATTRIBUTESUBJECTALTNAME2 and restart the service. And if you dont use web enrollment, disable it. If you do, enforce HTTPS and Extended Protection for Authentication so relays fail.
How to actually audit AD CS attacks
You dont have to check every template by hand. Three approaches cover it.
Microsoft Defender for Identity. If you have it, the security posture assessments flag ESC1, ESC2, ESC3, ESC4, ESC6, ESC7, ESC8, and more in Secure Score, with a remediation path for each. Certificate authority checks need a sensor on the AD CS server.
Community auditors. Defensive PowerShell tools like Locksmith and PSPKIAudit scan your PKI and report the same misconfigurations in plain language, no license required.
By hand. Open the Certificate Templates console (certtmpl.msc), check each template's enrollment permissions and the "Supply in the request" flag, and run certutil -getreg policy\EditFlags on the CA to check for the SAN flag.
The AD CS security posture assessments in Microsoft Secure Score. Source: Microsoft Learn.
Whatever you use, run it now. Most of these misconfigs have been sitting in environments for years. Whoever stood up the CA clicked through the template wizard and never came back.
Putting it together
AD CS attacks all cash out the same way. A misconfigured template or CA lets an unprivileged user mint a certificate for a privileged account. That certificate is a login that survives password resets. Audit your templates for "Supply in the request" and loose enrollment rights, pull dangerous rights off the CA, kill the SAN flag, and lock down web enrollment. Treat your certificate authority like the Tier 0 asset it is, because an attacker already does.
What can we learn as a person
What gets me about this whole class of problem is that the front door was fine. Strong domain admin passwords, MFA, the works. The domain fell through a system nobody thought to look at, because it had been quietly issuing trust the entire time.
I have systems like that in myself. I guard the obvious doors, the big reactions, the habits I know are watching me. Meanwhile some old belief I set up years ago keeps handing out certificates in the background. It tells every new situation "this is who you are," and I never audit it. And like a certificate, it survives the resets. I can change the behavior on the surface and that old thing keeps authenticating as me anyway, because I never revoked it at the source.
So whats your AD CS? What quiet system in you has been issuing trust on your behalf for years, that you've never once stopped to audit?
Ordered a new laptop for a remote hire last month. Dell shipped it straight to her apartment. She opened the box, connected to Wi-Fi, and signed in. I never touched the machine. Nobody on my team ever touched the machine. That whole flow is Intune zero touch deployment, and its worth actually explaining how it works instead of just saying "Autopilot handles it."
What Intune zero touch deployment actually means
Zero touch deployment means nobody in IT ever physically handles the device. No imaging. No unboxing at the office. The manufacturer ships it directly to wherever it needs to go, often straight to the employee's house. Windows Autopilot makes this possible, but Autopilot alone isnt the whole story. The real trick is getting the device pre registered before it ever leaves the warehouse.
The hardware hash is the whole trick
Every Windows device generates a hardware hash, a fingerprint built from its manufacturer, model, and serial number. Intune needs that hash registered to your tenant before Autopilot can recognize the device. Normally someone has to boot the machine and run a PowerShell script to grab it.
OEM registration skips that step entirely. Dell, HP, Lenovo, and most major manufacturers generate the hash at the factory. They register it directly with Microsoft on your behalf, before the box ever ships. Thats the actual mechanism behind zero touch deployment. The hash exists before the device does.
How OEM registration and manual registration both feed into Windows Autopilot. Source: Microsoft Learn.
Setting up drop shipping with Dell
Before Dell can register a single device for you, someone at Dell needs your permission. This step trips people up more than anything else in the whole process.
Granting Dell authorization
Dell emails a unique authorization link to your organization. A Global Administrator signs into the Microsoft 365 admin center using a cloud native account, something like yourcompany.onmicrosoft.com. That admin opens the link, checks a consent box, and selects Accept. Authorization happens instantly once they do.
Accepting the authorization request from an OEM like Dell. Source: Microsoft Learn.
Notice this requires Global Administrator, not just an Intune admin role. Thats a genuinely high privileged role, so dont hand this task to just anyone. Also worth knowing, once you authorize an OEM this way, you cant remove them yourself later. Revoking access means emailing Microsoft's support alias directly.
What happens after authorization
Once authorized, Dell registers every device you order automatically. No CSV files. No PowerShell scripts. No IT person unboxing anything first. The hash gets written to Microsoft's Autopilot database and tied to your tenant, all before the device ships. Dell never gets access to your actual tenant, they're only writing to Microsoft's registration database on your behalf.
What still needs setting up on your end
Registration only gets the device recognized. You still need a deployment profile assigned to whatever group that device lands in, defining things like deployment mode and whether the Enrollment Status Page blocks device use until apps finish installing. Ive covered building that profile in detail elsewhere, so I wont repeat all of it here. Just know registration and the profile are two separate steps, and skipping the profile means the device boots to a normal, unmanaged Windows setup instead of your branded OOBE.
The actual drop ship workflow
Authorize Dell once, using a Global Administrator account
Build your Autopilot deployment profile and Enrollment Status Page ahead of time
Order the laptop through Dell, specifying your tenant during the order
Dell registers the hash and ships straight to the new hire's address
The employee opens the box, connects to Wi-Fi, and signs in
Windows Autopilot takes over from there, joining Entra ID and enrolling in Intune automatically
Nobody on your team touches a single cable in that entire sequence.
Gotchas worth knowing before you rely on this
Confirm your reseller or Dell account rep actually supports OEM registration for your specific device line, not every SKU qualifies
Double check the tenant ID gets attached correctly at order time, a wrong tenant ID means the device registers somewhere other than your organization
Build and test your deployment profile before the first real shipment goes out, dont let a new hire be your test case
Remember you cant self service remove OEM authorization later, so get the right admin to grant it in the first place
Putting it together
Intune zero touch deployment is really two things stacked together. Dell registers the hardware hash before the device ships, and your Autopilot deployment profile tells that device what to do the moment it powers on. Get the authorization done once, get your profile built and tested, and every laptop after that ships straight to whoever needs it without IT ever unboxing a single machine.
What can we learn as a person
What gets me about OEM authorization is that you're trusting a company you'll never actually talk to with a piece of your process. Some person at Dell you'll never meet handles a step that used to require your own hands on the keyboard. And once you grant that trust, you cant even take it back yourself, you have to ask Microsoft to do it for you.
Honestly, a lot of life runs the same way. We hand pieces of our process to people we'll never meet, a pharmacist filling a prescription, an engineer who built the bridge we drive over, a stranger raising our kid's classmate. We dont personally verify most of it. We just trust the registration happened correctly somewhere upstream.
What's a piece of your life running on trust you never actually verified? And has it been working out fine anyway?
I used to work in an environment where the help desk admin spent half their day resetting passwords twice. Once in Active Directory, and then again in Office 365. If they forgot the second reset, the user could not sign in to their email, and the phone would ring. It was a miserable, repetitive cycle that drove everyone crazy. We eventually installed Microsoft Entra Connect to sync the directories, and the help desk team almost cried tears of joy.
Ok, so here is the deal with Microsoft Entra Connect. It is the sync engine that bridges your on-premises Active Directory with Microsoft Entra ID. Today we will build a simple setup guide. We will walk through how to install it, configure permissions, enable writeback, and harden the server so bad actors cannot compromise your domain.
The Microsoft Entra Connect installation welcome screen. Source: Microsoft Learn.
A simple setup guide for Microsoft Entra Connect
To start, download the latest version of the installer from the Microsoft Entra admin center. Before you double-click the file, make sure your server runs TLS 1.2. Microsoft enforces TLS 1.2 for all sync connections now, and the installation will fail if you do not enable this protocol on the server first.
Once you verify your server meets the prerequisites, run the installer:
Accept the license terms on the welcome screen.
Choose the Use express settings option. Express settings configure password hash synchronization by default, which works perfectly for a single Active Directory forest.
Enter your Entra tenant credentials. You must use an account with the Hybrid Identity Administrator or Global Administrator role.
Enter your on-premises Active Directory Enterprise Admin credentials. The installer needs this level of access to create the dedicated sync account in your domain.
Review the configuration on the ready screen, check the box to start synchronization, and click Install.
Select Express settings to automate the setup process. Source: Microsoft Learn.
Minimum permissions for the Entra Connect user
During the express installation, the wizard automatically creates a user account starting with MSOL_ in your on-premises Active Directory. Microsoft configures this account with the exact permissions needed to read your directory. If you want to use custom settings or pre-create this account, you must configure the permissions yourself.
The sync account needs these minimum permissions at the root of your domain directory:
Replicating Directory Changes. This permission allows the sync service to read changes from your Active Directory domain.
Replicating Directory Changes All. The service account needs this permission to sync password hashes from your domain controllers.
If you enable writeback features later, you must grant write permissions to this account. For example, password writeback requires the account to have Reset Password, Change Password, and Write permissions on the lockoutTime and pwdLastSet attributes for all user objects in your sync scope. You can read the official Microsoft Entra Connect permission guide on Microsoft Learn to see the full list of attribute requirements.
Hardening the Entra Connect server and user access
Microsoft Entra Connect holds the keys to your entire hybrid identity kingdom. If an attacker compromises this server, they can sync malicious changes to the cloud or extract password hashes from your on-premises domain. Hardening this server is not optional.
First, install Entra Connect on a dedicated member server. You must never install this software on a Domain Controller. Installing it on a member server reduces the attack surface and prevents easy privilege escalation if someone gains local admin access to the sync box.
Second, restrict local administrative access. Only allow trusted domain administrators to log in to the sync server. The installer creates a local group called ADSyncAdmins on the server. Make sure you only place authorized users in this group, as anyone in it can modify the synchronization rules and configurations.
Third, secure the synchronization user account. The MSOL_ account does not need domain administrator rights. Do not add this account to the Domain Admins or Enterprise Admins groups. Microsoft restricts access to the sync credentials by default, but you should also monitor the account logs for any unexpected sign-in attempts. You can learn more about securing these configurations in the Microsoft Entra Connect sync hardening guide on Microsoft Learn.
Enabling writeback features
A simple setup guide usually stops at one-way synchronization, where changes only flow from AD to the cloud. But you will want to enable writeback features to make the system truly useful. The most popular option is Password Writeback, which works with Self-Service Password Reset.
To enable Password Writeback:
Launch the Microsoft Entra Connect wizard from your server desktop.
Click Configure and select Customize synchronization options.
Enter your Hybrid Identity Administrator credentials to authenticate.
Proceed through the screens to the Optional Features page.
Check the box for Password writeback and click Next to apply the change.
You must enter your hybrid administrator credentials in the wizard to configure writeback. Source: Microsoft Learn.
Once you turn on this setting in the wizard, go to the Microsoft Entra admin center. Navigate to Protection, click Password reset, and select On-premises integration. Make sure you enable the option to write back passwords to your on-premises directory. This setup allows users to reset their own passwords in Microsoft 365, and the service will update their Active Directory password in real time.
What can we learn as a person
Managing a network without synchronization is exhausting. You push changes to one database, then copy them manually to another, hoping the two systems stay in alignment. If you do not set up writeback, information only flows one way, and the cloud never talks back to your local server. Honestly, our personal lives run into the same problem when we isolate ourselves. We try to handle every project, stress, and anxiety in our own heads without letting anyone else in. Operating in a one-way sync means you carry the entire load alone, and eventually, the systems fall out of alignment.
But the thing is, we need writeback. We must escrow our keys. A few trusted relationships can act as our on-premises integration, allowing support to flow back into our lives when the pressure builds up in our heads. Trying to run everything yourself only leads to a crash. Who acts as your writeback connection? Which person do you allow to push support and feedback back into your life when things get heavy?
We use cookies to ensure that we give you the best experience on our website. If you continue to use this site we will assume that you are happy with it.
