Take Back Control of Your Microsoft Directories with an Infrastructure as Code Approach

Real-world use case

You're piling up technical debt by creating your Microsoft resources manually: here's how Infrastructure as Code let me take back control of my directories.

In a world where security and compliance no longer tolerate approximation, continuing to manage identities and access through the graphical interface is a technical inconsistency and represents a genuine dead end for security. Infrastructure as Code (IaC) is no longer optional: it's a way to automate, audit, and make reliable the creation of resources: accounts, groups, permissions, access policies, and so on.

Adopting IaC means guaranteeing consistency, traceability, and security, while meeting the requirements of standards like ISO 27001 or 9001. This article explains why IaC is now essential for professional, secure identity management, here for Microsoft Entra ID and Microsoft Active Directory. As a result, companies that keep relying on manual management expose themselves to errors, security gaps, and non-compliance.

The tools

There's a wide range of tools for provisioning resources, whether in the cloud or directly on-premises. Terraform, OpenTofu, CloudFormation, and Pulumi are well recognized. The oldest date back at least a decade, 2011 for CloudFormation and 2014 for Terraform. My preference goes to HashiCorp's solution: Terraform, and that's what I started with in 2020.

Terraform providers for Microsoft Entra ID and Microsoft Active Directory

The two modules I recommend are the ones created and maintained by the HashiCorp teams:

• Azure Active Directory It refers to the historical name of Microsoft's cloud directory solution (later renamed by the vendor to Microsoft Entra ID).
• Active Directory It refers to the historical name of Microsoft's Active Directory product.

In my experience, the operations and configuration options offered by these modules cover a wide range of needs for most companies. Their first version dates back to 2019 (v0.1.0).

The technical debt built up on Microsoft Entra ID and Microsoft Active Directory

If, since 2019, you've kept creating resources manually in your Microsoft directory, whether cloud or on-premises, it's fair to say you're building up technical debt. The lack of automation, the lack of traceability and reproducibility, the inability to guarantee environment consistency, and the difficulty of compliance (ISO, GDPR, security) without an up-to-date reference make audits more complex and costly. On top of that, the risk of error or loss during migrations, restores, or team changes becomes a real obstacle to your organization's growth and security. Believe me, knowing that at any moment you have the ability to extract the reference of your infrastructure and its access, and knowing it's up to date, is very valuable.

Where to start?

To stop relying on manual management and move to automated management that follows best practices, here's a project plan I've implemented.

Example project: Inventory and IaC migration of identities and access

1. Inventory of existing resources

Entra ID (Azure AD)

• Search for and export:
  • Users
  • Groups
  • Permissions (assigned roles)
  • Conditional Access Policies

Active Directory (on-prem AD)

• Search for and export:
  • Users
  • Groups
  • Permissions (group members, delegated rights)
  • GPOs (Group Policy Objects)

2. Structuring the reference repository

• Organize the exports into structured files (e.g., CSV).
• Document the mapping between Entra ID and AD resources (e.g., in a hybrid setup).

3. Preparing for Terraform authentication

• Create an application with a token in Microsoft Entra ID with the required permissions.
• Create a dedicated user account with the required permissions for the Active Directory directory.
• Ideally, avoid making WinRM calls directly to the Active Directory domain (use a jump box instead).

3. Generating the Terraform code

• Create the Terraform files for each resource (users, groups, permissions, policies).
• Use the official providers: hashicorp/azuread and hashicorp/ad
• Follow a clear, documented naming convention.

4. Importing existing resources

• Use the terraform import command to bring the actual resources into the Terraform state.
• Check that the inventory and the code are consistent.

5. Documentation and validation

• Generate an up-to-date Markdown reference repository for the teams.
• Validate compliance, traceability, and security.

6. Automation and maintenance

• Set up CI/CD workflows for future changes.
• Set up tests to ensure future provisioning follows the rules (naming convention, etc.).
• Train teams on how to use and maintain the IaC reference repository.

Conclusion

For my part, structuring identity and access management with Infrastructure as Code isn't just a technical project: it's a genuine transformation effort for the company. Yes, the approach is demanding, sometimes long and complex, but it's now essential to guarantee security, compliance, and quality. Organizations that put off this shift risk staying vulnerable, losing agility, and exposing themselves to growing technical debt.

IaC requires discipline, clear documentation, and upskilling the teams. But the benefit is huge: a well-controlled, auditable, scalable infrastructure that meets standards. The real question is no longer "should we do it?", but "how many companies are ready to take on the challenge and step out of the (false) comfort of manual management?" Those who choose automation and traceability lay the foundations of a modern, resilient, and secure IT system.