Creating Azure AD group without owners

[miqm]

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritise this request
• Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritise the request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment

Description

I've seen some discussion on problem with AD v2 and group owners list. I want to maintain AD groups that does not have an owner - just as I would create them on Azure Portal. Additionally, this can be handy when specifying group owners as resources as described in #435

New or Affected Resource(s)

• azuread_group

Potential Terraform Configuration

Option 1 - specify that group will be created without owners:

resource "azuread_group" "group" {
  display_name     = "GROUP NAME"
  security_enabled = true
  no_owners = true
}

Option 1 - not providing owners creates a group without owners:

resource "azuread_group" "group" {
  display_name     = "GROUP NAME"
  security_enabled = true
}

References

• Discrete feature to create multiple AAD Group Owners #435

[manicminer]

Hi @miqm, thanks for requesting this. Unfortunately, API changes made in the last few months mean we are unable to create groups without owners. We have done our best to document this and other constraints on the documentation page for the azuread_group resource.

[miqm]

@manicminer - in the docs you say It's recommended - not it's required. Through Azure Portal I can create an AAD group without owners and also I can remove all owners of particular group. I'm just asking to provide same functionality as there is in the CLI and Portal.

[manicminer]

@miqm Thanks, that isn't as clear as it could be and we can improve the wording there. Though in the description for the owners property we do state:

Groups cannot be created with no owners or have all their owners removed.

I'll look at tidying up the info box as I can see how that might be misleading.

[miqm]

AAD Security Groups can be created without owners or have all owners or members removed. I'm not talking about M365 groups but the security ones.

[manicminer]

There is an API bug which applies the same conditions to security groups. It's inconsistently applied to different users/tenants so in order to support those for whom this bug manifests, we have to enforce group ownership regardless of group type.

[miqm]

So if it is a bug this means that it will work someday. All CLI and portal uses API to create groups, enforcing owners by TF while rest of the tools doesn't have this problem is odd. Perhaps you could add some switch on provider to wave this limitation for users that are sure it'll work?

[manicminer]

Unfortunately the behavior of the Portal and CLI isn't representative of the experience when using a tool like Terraform, as they are first-party Microsoft apps. We're unlikely to change the provider behavior here until such as time as we can confirm the API is fixed, as the logic around group ownership is complex and balanced right now to avoid breaking users as much as possible.

[manicminer]

Please see #464, #473, #478 and #567 for context.

[miqm]

Thanks. I saw also your GH issue microsoftgraph/msgraph-metadata#92 and there's a comment

the problem seems to be avoided by never setting owners@odata.bind. If add additional owners during creation of a group are added, two requests will be made: One just for creating the group and then a second one to https://graph.microsoft.com/beta/$batch to add the owners.

Could TF provider implement such behaviour as an alternative?

[miqm]

Also if #435 is considered to implement you shouldn't set owners to empty list if property is not provided - just don't provide and the api should not clear it and will allow to create security groups without owners but then we'll need to maintain group owners by using separate resources.

[manicminer]

That comment is prefixed with "If I use the active directory via Azure portal", which as I mentioned isn't a good indicator as the portal is a first-party app.

One person's experience doesn't always match another's. When no owners are specified on group creation, sometimes the API obliges, but sometimes it adds an owner automatically, and sometimes it just returns a 400 error - both for security groups and M365 (unified) groups. The constraint on the type of owner for M365 groups is also inconsistently applied, and also erroneously applied to security groups.

#435 was opened (and my initial comment there added) prior to the API introducing these breaking changes.

[github-actions]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.
If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.