In modern organizational management, especially with Infrastructure-as-Code (IaC) tools like Terraform, precise permission control is essential. Azure Active Directory (AAD), ahem, Entra ID, offers permission levels to manage and control resources, yet there’s often a gap between what’s allowed and what would be ideal for secure, granular access control.

One common challenge is the need to create and manage groups without the ability to edit groups outside an individual’s purview — such as restricting users to only create and manage their own groups. This gap becomes evident in scenarios where permissions like Group.ReadWrite.All grant excessive control, making it challenging to apply the least privilege principle. What if there were a permission like Group.ReadWrite.Mine, which would enable users to create and manage only the groups they own?

This capability would not only empower users to self-manage their groups but also allow IaC solutions like Terraform to create groups and assign ownership more flexibly, without compromising on security. Maybe this capability already exists? If so, I haven’t seen it.

When first attempting to create a new Entra ID Group using Terraform I am greeted with this message.

│ Error: Creating group “My Cool Group”
│
│ with azuread_group.my_cool_group,
│ on teams.tf line 5, in resource “azuread_group” “my_cool_group”:
│ 5: resource “azuread_group” “my_cool_group” {
│
│ unexpected status 403 (403 Forbidden) with error: Authorization_RequestDenied: Insufficient privileges to complete the operation.

That’s because you need these permissions:

When authenticated with a service principal, this resource requires one of the following application roles: Group.ReadWrite.All or Directory.ReadWrite.All.

Now what about just giving group creation access using the Group.Create permission? However, this means Terraform will have a hard time managing the groups full lifecycle since possibly removing the groups might be out of the question. Perhaps Group.Create is smart enough to allow you to edit and delete groups that you yourself created?

Well just using Group.Create doesn’t allow you to set the owners.

data "azuread_user" "keyser" {
  mail = "keyser@soze.com"
}

resource "azuread_group" "my_cool_group" {
  display_name     = "My Cool Group"
  security_enabled = true

  owners = [
    data.azuread_client_config.current.object_id,
    data.azuread_user.keyser.object_id,
  ]
}

You’ll be met with this doozey:

│ Error: Could not retrieve owners for Group (Group: “a07f4e2a-5b68–4d84-abe9-ce0ce5c2b0c4”)
│
│ with azuread_group.my_cool_group,
│ on teams.tf line 9, in resource “azuread_group” “my_cool_group”:
│ 9: owners = [
│ 10: data.azuread_client_config.current.object_id,
│ 11: data.azuread_user.markti.object_id,
│ 12: ]
│
│ unexpected status 403 (403 Forbidden) with error: Authorization_RequestDenied: Insufficient privileges to complete the operation.

This is a major problem.

It turns out if you want to set the owners attribute you need a lot more privileges. If specifying owners for a group, which are user principals, this resource additionally requires one of the following application roles: User.Read.All, User.ReadWrite.All, Directory.Read.All or Directory.ReadWrite.All The quest for precise permissions in Entra ID, such as a hypothetical Group.ReadWrite.Mine, raises an important question: should this level of granular control exist to empower users and improve security?

I think so.

In organizations where automation and Infrastructure-as-Code are priorities, the ability to delegate specific permissions would allow tools like Terraform to deploy groups with confidence, while empowering users to self-manage memberships without risking unnecessary exposure to other groups.

While broader permissions like Group.ReadWrite.All fulfill current needs, a more tailored approach could bridge the gap between automation flexibility and stringent access control. As the needs for identity and access management evolve, perhaps it’s time to reconsider how permissions can support both user empowerment and security—leading to a truly modernized approach to group management in Azure.