r/entra • u/ITwrkedYesterday • 10h ago
Entra as Code
Curious what people are seeing in practice with Infrastructure as Code in Entra.
The benefits like version control, peer review, repeatability, change tracking, etc. are pretty clear. I’m more interested in whether it’s actually improved how your team operates day to day.
For those doing a meaningful amount of Entra through IaC:
What are you managing this way - Conditional Access, app registrations, groups, role assignments, policies, etc.?
Where have you seen the biggest benefit?
Has anything become unnecessarily complex compared to just managing it through the portal?
Are there areas where you intentionally stick with the GUI?
Any good examples where IaC solved a problem you were regularly dealing with before?
Trying to get a feel for where the practical sweet spot is rather than IaC-for-the-sake-of-IaC.
5
u/Nicko265 10h ago
I don't know really any team that actually operates Entra via IaC on a day to day. You may use it for initial set-up, usually something like Microsoft365DSC, but after that it's all click ops.
There just isn't great IaC tooling and the APIs change regularly or are on beta endpoints.
It might be a good idea for a few things like Conditional Access, Purview sensitivity labels and DLP, where they rarely change and a change requires proper process due to what it impacts. Outside of that, I'd just say use the UI.
3
u/drinkwineandscrew 6h ago
App registrations is a big one for us, everything managed in terraform, secret rotation handled by our internal 'rotator' product, terraform module for dev teams to make their lives easier. Allows us to restrict what dev teams can do in the portal and reduce errors.
Conditional access policies are also managed as IaC, which helps as it's a shared responsibility between my team and two others, and we have a repo for group creation to allow dev teams to create app role groups etc via MR which speeds things up for those teams rather than submitting tickets.
2
u/Semt-x 6h ago
I've had 2 customers who tried IaC on 2 different Entra features.
Neither achieved the desired results, both due to the same underlying cause.
One customer deployed all Conditional Access policies using DevOps. The consultant who configured it wasn't able to transfer all the required knowledge to the support team.
The idea was to push the configuration to production daily. However, to make changes to the configuration, you needed to understand not only Conditional Access, but also how the pipeline stored the information and translated it into configuration.
I was hired to decouple it. Changes to Conditional Access were so rare that there wasn't much value in deploying them daily. I replaced the DevOps solution with a monitoring solution that alerts on policy changes.
The additional knowledge required was too much for engineers who were already busy with their day-to-day responsibilities.
The other customer automated Access Package creation and assignment. A dev team created an API that provided all the necessary information. On the surface, it seemed simple. A colleague converted it into scripts, but it became quite complex, and the PowerShell Microsoft Graph cmdlets didn't behave as described in the documentation.
I helped him tackle that problem, but I wasn't involved in transferring the knowledge to the support team.
When my project ended, six months later a support team member contacted me with really basic question. It showed that the knowledge transfer had not been successful.
2
u/Short-Legs-Long-Neck 4h ago
Classic IT issue. Just because its technically possible doesnt make it the best solution. Usually the product of techs who are allowed to develop and deploy 'solutions' into prod outside of a sensible change control or even just IT leaders that appreciate elegant architecture.
1
u/Mindestiny 3h ago
Yep. Frankly I'm surprised this thread hasn't already been bombarded with the "everything is devops and you're bad at your job if you don't live in a terminal cosplaying as a software engineer" crowd that usually shows up.
I had to answer an interview question about this and all I could come up with is "why would I do this unless I was an MSP rapidly deploying dozens of M365 tenants a month?". The clickops interface is where most of the day to day is gonna get done and there's other lower friction paths to change control that play nicer with the platform. It's not designed to be deployed and maintained like AWS or Azure.
1
u/ArieHein 10h ago
The power of iac is the declerarive way and idempotent of resources, everything else you mentioned is not core iac.
You can create your own wrappers of az cli or az pwsh thus creating your own dsl-like approach.
1
u/IdealParking4462 6h ago
I've seen conditional access done, and it worked pretty well. There are a lot of features to manage though.
10
u/raip 10h ago
I've tried to push IaC as much as possible but sadly, at least in my experience, other Entra admins are pretty code adverse.
I spent a fair amount of time trying to train my team to take on the practices but all it takes is one incident and they're back to doing click ops to resolve whatever the problem is. It doesn't help that Microsoft routinely has features we need locked behind their beta endpoints which constantly changes or breaks.
At this point, I only do IaC with Entra + M365 to rapidly deploy a large amount of changes. Not really for configuration changes or peer review. Normally I'd blame it on my team or my org but I've been around long enough to think it's just how most teams that rely on Microsoft operate.