Most M365 tenants have likely deployed CAP (conditional access policies, assuming they have Azure Premium P1/P2 licenses). With my previous employer, in 2019 I led the deployment of CAP to ensure only Intune compliant devices (the organization had about 100k devices, half of which are Macs) can access the M365 workloads.
It wasn't easy and couldn't really go 100% zero-trust, still had to define plenty of trusted named locations. It was a delicate juggling between trying to meet security requirements and ensuring users aren't negatively impacted, at least not too much.
Having been let go in early 2024, just kept working with a new employer. About a year after, just happened to looked at Graph and PowerShell scripts I had kept, some of them had the credentials of service principals with admin roles. And not surprisingly (but professionally disappointed) - they still can authenticate, from my home machine nonetheless.
Lessons learned?
- This company had Azure Premium P2 license, I am pretty sure this allows CAP to restrict service principals, at the very least to certain named locations.
- These are automation-type scripts, so it had to use service principals. But if possible, I would investigate the use of MSA (or even gMSA) instead.
- I am not sure how to control it, but admins are supposed to use a separate admin accounts with PIM+JIT when performing admin actions. However, it's tempting to use service principals for day to day work too.
- If certificates are used and let's say a dedicated jump/admin server is utilized as well, the person installing the cert can put that in the computer store without the ability to export the private key - this at least makes this certificate only usable in that machine (i.e., the service principal using that certificate as part of its credential when authenticating).
No comments:
Post a Comment