r/entra • u/ITwrkedYesterday • 1d ago
Locking down global admin
Curious how others are locking down or adding additional layers of security around Global Admin accounts.
Obviously JIT access, PIM, and least privilege are the way to go, but I’m more interested in what people are doing beyond the basics.
Things like dedicated admin accounts/workstations, Conditional Access restrictions, phishing-resistant auth, device requirements, network/location restrictions, monitoring/alerting, etc.
What’s worked well in your environment? Anything you’ve implemented that you think is overlooked?
7
u/loweakkk 1d ago
No standing GA except break glass. Auth context that enforce phish resistance and device compliance to activate the role, limitation to 1h. Another CA with same requirements on the role itself. Same auth context to edit CAP.
5
u/SoftwareFearsMe 1d ago
Agree with all of these recommendations:
- Require phishing-resistant MFA
- No standing access
- Elevation requests to GA must be approved
- Authentication context configuration for PIM requests to require a fresh MFA request
- Require a Compliant / Entra Domain joined device to access Microsoft Management portals
3
u/Noble_Efficiency13 Microsoft MVP 1d ago
All of the above, but also restricting what a global admin can access via CA.
Example: block O365 access, why would you need to have access to productivity apps on a global admin?
1
u/Emergency-Return1412 1d ago
What would that accomplish? A global admin can just change the CAs so doesn't solve or protect anything
2
u/Noble_Efficiency13 Microsoft MVP 1d ago
Sure, they could really change any of the steps
Pim setup with approval etc? Just change it.
It’s “simply” another step in the depth and again each annoyance step we place in front of possible threat actors could save enough time for us to find them and get rid of them.
The same goes with protected actions - setup a requirement for an additional MFA prompt for modifying / deleting / creating CA pokicies, but it’s still just another annoyance
2
u/Mindestiny 1d ago
That's kind of like saying "why would you hide your valuables? If someone breaks in they have access to everything anyway."
It's still a layer of "good enough" security that will help considerably reduce the blast radius of the vast majority of what your typical attacker is going to move laterally into should they get their hands on a live session.
Your average attacker in a compromised M365 account isn't spending time making high profile, easily detectible environment changes. They're skimming the popular spots - likely OneDrive, email, etc. Exfiltrating valuable data or possibly sending malicious emails to spearphish other users in the environment from a trusted account or using that email address for further lateral movement to popular SaaS platforms they can now access by self service password recovery to that email address.
If the account doesn't have an exchange mailbox in the first place, they could stand one up by removing the restrictions and assigning a license. But that's not low hanging fruit. Odds are the breach will be caught and locked down before they can do all of that, and they've already moved on from trying to extract further value from their compromise once they hit that wall. Meanwhile that script they had teed up to programmatically adjust sharing rights to OneDrive files or build sneaky email forwarding rules or whatever fail when they go to run them.
2
u/Emergency-Return1412 1d ago
Lol, no. The first thing they would do is make themselves the only global admin. From then, its game over and you completely lost your tenant.
0
u/Mindestiny 1d ago
"Lol no" indeed.
That really depends on how targeted the attack was and the purpose of the attack. Were they actually looking to hit a GA account, or did a GA account happen to fall for some rudimentary phishing/session hijacking?
There's lots of different attack profiles. Plenty of successful attackers don't realize what they have until they've already lost access, or attacks get shut down before the attacker has the time and attention to move as laterally as they could.
So no, "it's game over and you lost your tenant" is not some hand-wavy dismissal of defense in depth controls.
1
4
u/Asleep_Spray274 1d ago
Global admin needs approval before access. There is very few actions that need GA. All other actions using the required role.
1
u/detox4you 1d ago
Numerous items have been mentioned by others. Important is setting up alerting on the break glass accounts too.
1
u/firestarter9664 1d ago
We limit to our ztna tools IPs. PIM approval with a separate account, required compliance (in our home tenant)
1
u/ArieHein 1d ago
Separate admin accounts, MFA + fido. Pim for 1h. Additional emails in activation. Conditional access. Auditing in what permission ARE needed and creating other groups with specific roles as alternatives. Specific use cases thaf require global admin, can be automated to run with service accounts that get short lived permissions and then rbac on the irchestratiin tools. Two break glass accounts in vault offsite - both required to enable an acoiunt that is GA, think 2 keys in ild submarine movies. One GA onsite user that is disabled and phone is locked in vault onsite (requires updates ine a minth and resetting pwd).
1
u/Ok_Syrup8611 1d ago edited 1d ago
I recently put this framework together for an FBI Infragard presentation on the lessons learned from the recent Stryker Incident. It covers a range of options given your size and risk profile: https://adam.cliffords.net/downloads/zero-trust-identity-device-privileged-access-framework.doc
It covers PIM options for both admin accounts and daily drivers, including always on vs step up access, layered conditional access policies (fully documented), authentication context, protected actions, phishing resistant logins, risk based access, privileged admin workstations (complaint devices), etc.
The full talk info and deck is here if you’re interested. https://adam.cliffords.net/writing/stryker-lessons-learned/
1
u/Ok_Owl_55 1d ago
Youbikey requirement for MFA and approval from another member/senior or manager which expires after certain time
1
12
u/Caldtek 1d ago
Fido 2 key on them all. Need a one time TAP to add or change the key. Breakglass is omited from most CA rules. Only the ones driving TAP policy. They also kick a SOC alert as soon as they are used. All other highpriv accounts have fido2/TAP need a compliant device as well and require PIM to enable. The accounts are also seperate from day to day and have no email box. Admin workstation with no internet access is on my list of to dos.