azuread_group failing plan with Service Principal authentication

[kenchan0130]

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

Terraform (and AzureAD Provider) Version

$ terraform -v
Terraform v1.3.6
on darwin_arm64

Affected Resource(s)

• azuread_group

Terraform Configuration Files

resource "azuread_group" "test" {
  display_name     = "test"
  types            = ["Unified"]
  mail_enabled     = true
  owners = [
    data.azuread_user.test.object_id,
  ]
}

Debug Output

Panic Output

Expected Behavior

If I have not set a value for groupGetAdditional, then I expect groupGetAdditional not to be executed on read with ervice principal authentication.

Actual Behavior

When I do a plan using the service principal's authentication, I get the following error:

│ Error: Could not retrieve group with object UID "957037e5-809a-63a7-f023-afeea21efaf7"
│ 
│   with azuread_group.test,
│   on main.tf line 1, in resource "azuread_group" "test":
│  1: resource "azuread_group" "test" {
│ 
│ retrieving additional fields: GroupsClient.BaseClient.Get(): unexpected
│ status 403 with OData error: ErrorAccessDenied: Access is denied. Check
│ credentials and try again.

Steps to Reproduce

1. terraform import azuread_group.test 957037e5-809a-63a7-f023-afeea21efaf7 with user authentication
2. terraform plan with service principal authentication

Important Factoids

References

• https://github.com/hashicorp/terraform-provider-azuread/issues/729

[kenchan0130]

I would suggest that the groupGetAdditional entries be a separate resource from azuread_group. In a CI/CD environment, it appears that we are being held back by having these handled in the same resource.

[manicminer]

Thanks for raising this @kenchan0130. That's a great idea, I think that splitting these properties into a separate resource is a good way to approach this.