A manager walked over to my desk holding a brand new Android phone and asked me to "put it in the business manager." I knew what they meant, sort of, but that phrase does not map to any single button in Intune. Android has a whole family of ways to run a device, and the words people use for them are a mess. Business manager, work profile, kiosk, COPE, COSU, fully managed. So lets untangle the Android Enterprise management types, figure out what each one actually does to a phone, and how you pick the right one before you hand hardware to a human.
First, the thing everyone calls "the business manager"
When someone says business manager, they almost always mean Managed Google Play. It is Google's enterprise app store, and it is the connection that makes every other Android option possible. You link your Intune tenant to a managed Google Play account once. After that, Intune can push apps, enforce policy, and enroll corporate devices.
You set it up under Devices > Enrollment > Android tab > Managed Google Play. As of August 2024 you can bind it with your Microsoft Entra account instead of a throwaway Gmail address, and that is the path Microsoft now recommends. The moment you connect, Intune drops five helper apps into your console automatically. Intune, Authenticator, Company Portal, Managed Home Screen, and Microsoft Launcher. You did not add them. They just show up because the plumbing needs them.
Intune sits over identities, devices, and apps. Android Enterprise is how phones plug into that model. Source: Microsoft Learn.
The Android Enterprise management types, in plain English
There are four live options, and they split cleanly on one question. Who owns the phone, and does the person get a personal side? Here is each one without the acronym soup.
Personally owned work profile (BYOD). The employee owns the phone. Android creates a separate, walled-off work profile with its own apps and its own briefcase badge. You manage that container. You never touch their photos, their texts, or their personal apps.
Corporate-owned work profile (COPE). The company owns the phone, but you still give the person a real personal space. You get more control than BYOD, they still get a private life on the device. This is the "here is your work phone, but check your kid's soccer schedule on it too" option.
Fully managed (COBO). The company owns it and it is a work device, full stop. No personal profile. You control the whole phone, top to bottom.
Dedicated (COSU). The company owns it and no single person owns it. Think kiosk, scanner, digital signage, a tablet bolted to a wall. It usually locks to one app or a small set of apps. Nobody signs in with their own identity.
There is a fifth name you will still hear, Android device administrator, or DA. That was the old way, before work profiles existed. Microsoft deprecated it, and it no longer works on devices that have Google Mobile Services. If someone hands you a DA setup, treat it as legacy and plan your move off it.
One table to keep them straight
Type
Who owns it
Personal space?
Best for
Wipe on exit
Work profile (BYOD)
Employee
Yes, the whole phone is theirs
Personal phones used for work
Only the work container
Corporate work profile (COPE)
Company
Yes, a private profile
Company phones people also live on
Company data, personal stays
Fully managed (COBO)
Company
No
Dedicated work phones per person
Whole device
Dedicated (COSU)
Company
No user identity at all
Kiosks, scanners, signage
Whole device
Personally owned work profile, the polite one
BYOD work profile is the option that respects the line between work and life. Android literally builds a second sandbox on the phone. Work apps go in there with a little badge. Your management stops at the edge of that sandbox. You can wipe the work profile clean and the person keeps every personal thing untouched.
This is the sweet spot for staff who already have a phone they love and do not want a second one in their pocket. It also pairs well with app protection policies if you want to go even lighter. I wrote about that split in Intune devices vs app policies if you are weighing full enrollment against just protecting the apps.
Corporate-owned work profile, the balanced one
COPE is for company hardware that you still want to feel humane. The org owns the phone, so you get stronger controls than BYOD, including tougher password rules. The employee still gets a private profile for personal apps and accounts. It is a good middle path when you are buying the phones but you do not want to run a police state.
One catch worth knowing up front. On COPE devices running newer Android, factory reset protection can require the original Google account after a reset. Plan your reprovisioning so you are not locked out of your own fleet.
Fully managed, the total one
Fully managed, or COBO, is a corporate phone assigned to one person with no personal side. You own the whole device and the whole experience. By default the user cannot install anything outside your approved apps, and they cannot remove what you require. You can open the door to the full Play Store if you want, but the default is locked down.
Reach for this when the phone is a work tool and only a work tool. Field techs, drivers, frontline staff who get a device for the job and nothing else.
Dedicated devices, the kiosk one
Dedicated, or COSU, is the type with no human owner. The device is the point, not the person. It usually pins to a single app or a small locked set through the Managed Home Screen. A checkout tablet, a warehouse scanner, a check-in kiosk, a screen showing a dashboard all day.
Picking a management type is half the job. The other half is provisioning. For the corporate types, the common enrollment paths are:
QR code. Factory reset the device, tap the first screen a few times to open the reader, scan the profile. Best for small batches.
Google Zero Touch. Buy from an authorized reseller and provisioning starts the instant the user powers on. Best for scale.
Samsung Knox Mobile Enrollment. The Samsung equivalent of zero touch for Knox devices.
Token entry. On the Google sign-in screen you type afw#setup instead of an email, then enter a token. Handy when QR and NFC are off the table.
BYOD work profile is the odd one out. It needs no factory reset. The person installs Company Portal, signs in, and Android builds the work profile in place. That single difference drives a lot of real world decisions.
Intune's enrollment options by platform. Android Enterprise gets its own lane. Source: Microsoft Learn.
The factory reset line you cannot ignore
Here is the single fact that trips people up most. Converting a phone into a corporate mode wipes it. You cannot bolt COPE, fully managed, or dedicated onto a phone that already has stuff on it. It has to start clean. BYOD is the exception, because the work profile is added, not baked in.
Management type
Factory reset required first?
Personally owned work profile (BYOD)
No
Corporate-owned work profile (COPE)
Yes
Fully managed (COBO)
Yes
Dedicated (COSU)
Yes
Blocking the types you do not want
You do not have to allow everything. Enrollment restrictions let you decide which Android flavors are even permitted. Under Devices > Enrollment > Device platform restriction, you can allow or block the Android platform, block specific manufacturers, set OS version ranges, and block personally owned devices entirely. If your org is corporate-only, turn personal ownership off and BYOD stops at the door.
Every enrolled device gets an MDM certificate so Intune can enforce policy. Source: Microsoft Learn.
Putting it together
The Android Enterprise management types come down to two questions. Who owns the phone, and does the person deserve a personal side. Personal phone, use BYOD work profile. Company phone people also live on, use COPE. Pure work phone, go fully managed. No owner at all, go dedicated. Managed Google Play is the connection under all of it, corporate modes need a clean device first, and enrollment restrictions let you slam the door on anything you did not choose. Get those four calls right and the rest of Android management gets a lot quieter.
What can we learn as a person
The factory reset rule stuck with me. To turn a phone into a fully managed or corporate device, you cannot just layer the new rules on top of the old mess. The phone has to be wiped first. A clean slate is not optional. It is the entry fee for becoming something different.
People are not so different. I have tried to bolt a big life change onto a life I never cleared out first. New habit, same old clutter underneath. New boundary, same old patterns still running in the background. It usually failed, and it failed for the same reason a corporate profile fails on a dirty device. There was too much left over to build cleanly on top of.
BYOD is the gentler truth on the other side. Some changes really are additive. You can keep your whole self and just build a small walled space for the new thing, and it coexists fine. The hard part is honesty about which kind of change you are facing. Some things you can add to who you already are. Some things need you to wipe the slate and start clean, even though it costs you everything that was already on there. So which change in your life are you trying to bolt on, when what it actually needs is a reset?
A client asked me if he could just export his Group Policy Objects and import them into Intune in an afternoon. I wish. Twenty years of GPOs do not lift and shift into the cloud in one clean drag and drop. But moving from Group Policy to Intune is a lot less painful than most admins expect, because Microsoft built a tool that does the boring analysis for you. Let me walk through it.
If you're pushing devices toward cloud management and want to cut the on-prem cord, this is where you start.
Why Group Policy to Intune isnt a straight copy and paste
Group Policy and Intune deliver settings in completely different ways. A GPO reaches a domain-joined machine through SYSVOL and LDAP, on your network, over a trust. Intune reaches a device through MDM configuration service providers, over the internet, with no domain required.
The good news is that Intune already has many of the same settings your GPOs do. They live in the Settings Catalog, a giant searchable list of everything Intune can configure. So a lot of your policy does translate. It just moves into a new home built for cloud-native Windows instead of a domain controller.
The tool that does the heavy lifting: Group Policy analytics
Group Policy analytics is a feature inside Intune that reads your actual GPOs and tells you what will carry over. It imports a GPO, checks each setting against what MDM supports, and reports a percentage. No guessing which settings have a cloud equivalent.
Step one: export the GPO as XML
On a machine with the tools, open the Group Policy Management console (GPMC.msc).
Expand your domain, then Group Policy Objects.
Right-click the GPO you want and choose Save Report.
Set Save as type to XML File and save it somewhere easy to find.
Keep each file under 4 MB. If a single GPO is bigger than that, trim its settings or split it before you export.
Export each GPO as an XML report from GPMC. Source: Microsoft Learn.
Step two: import it into Intune
In the Intune admin center, go to Devices > Manage devices > Group Policy analytics.
Select Import, pick your XML file, and choose a scope tag if you use them.
Select Next, then Create. Intune analyzes the file automatically.
Once the analysis finishes, each GPO shows an MDM Support percentage. That number is the share of its settings that have a matching setting in Intune. Select the percentage to drill into the individual settings and see exactly which ones map and which ones dont.
Read the migration readiness report
Before you migrate anything, look at the readiness report. Go to Reports > Device management > Group policy analytics. It sorts every setting into three buckets.
Ready for migration, the setting has a match in Intune and can move straight over.
Not supported, no MDM equivalent exists, so this one stays behind or needs a different approach.
Deprecated, the setting targets old Windows or old Edge versions nobody runs anymore.
The migration readiness report buckets every setting. Source: Microsoft Learn.
This report is the honest conversation about your environment. That deprecated bucket is usually bigger than people want to admit, and every setting in it is one you get to stop carrying.
Migrate the settings into a Settings Catalog policy
Now the actual move. Back in Group Policy analytics, you turn supported settings into a real Intune policy.
In Devices > Manage devices > Group Policy analytics, check the Migrate box next to the GPO you want.
Select Migrate to see every setting inside it.
On the Settings to migrate tab, check the specific settings you want in the new policy.
Review the values, name the profile something clear like "Windows: Imported Edge GPOs," and assign it to a group.
Select Create. The new Settings Catalog policy shows up under Devices > Configuration.
Pick exactly which settings move into the Settings Catalog policy. Source: Microsoft Learn.
One nice touch. If two of your GPOs set the same thing to different values, the tool catches the conflict right there and makes you pick a winner before it lets you continue. Thats a problem you'd normally only find months later when a machine behaves weird.
What wont come across cleanly
Set expectations before you start, because a few things need a different plan.
Domain-dependent settings. Anything that assumes a domain controller on the network doesnt make sense on a cloud-native device.
Group Policy Preferences. Drive maps, logon scripts, and printer mappings dont map one to one. Use Intune's own features for those instead.
Non-English and non-ADMX settings. The analytics percentage only reads non-ADMX settings in English, so the number can be off for other languages.
Security settings. Many belong in compliance policies or security baselines, not the Settings Catalog.
Do not migrate all your settings just because you can. Review each one. After the policy lands, confirm it applied by checking which policies are on the device, the same way you'd check any other Intune profile.
Putting it together
Migrating Group Policy to Intune is really four moves. Export your GPOs as XML, import them into Group Policy analytics, read the readiness report to see what actually translates, then migrate the supported settings into a Settings Catalog policy. Start with one well-scoped GPO like your Edge settings, pilot it against a small group, and prove it works before you touch the big ones. The tool removes the guesswork. Your job is deciding what deserves to come with you.
What can we learn as a person
The readiness report is the part I keep thinking about. It looks at everything you built over the years and quietly sorts it into three piles. This still works. This has no place where you're going. And this one is just deprecated, left over from a version of the environment that doesnt exist anymore.
I moved into a new chapter recently, and I tried to carry my whole old config with me. Every habit, every defense, every rule I wrote for a domain I dont live in anymore. Some of it translated fine. A lot of it was deprecated and I just hadnt run the report to notice. The healthiest thing wasnt migrating everything faster. It was being honest about what no longer applied.
So if you ran a readiness report on the settings you carry day to day, what would land in the deprecated pile? And what are you still enforcing out of habit that the new version of your life doesnt even support?
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?
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.
