terraform-provider-azuread: azuread: GroupsClient.BaseClient.Post(): unexpected status 400 with OData error: Request_BadRequest: Request contains a property with duplicate values.

I hit this with #567. My workaround is to assign someone other than myself as an owner of the Azure AD group. Terraform then successfully creates the AAD group and automatically makes my ID an owner as well as the other individual I specified. It got me past this “duplicate values” error.

I faced the same error and was able to “fix” it by assigning the authenticated user principal to the directory role Groups Administrator as stated in the documentation

If anyone comes across this issue, this did it for me (little dirty but can live with that code until this is fixed) -

locals {
  azuread_admin_group_mail_nickname = uuidv5("dns", "ca.dev.xyz")
  azuread_admin_group_owners        = concat([data.azuread_service_principal.terraform_client.id], data.azuread_user.admin_user.*.id)
  azuread_admin_group_id           = shell_script.azuread_admin_group.output.id
}

provider "shell" {}

resource "shell_script" "azuread_admin_group" {
  lifecycle_commands {
    create = "az ad group create --display-name ${var.azuread_admin_group_name} --mail-nickname ${local.azuread_admin_group_mail_nickname}"
    read   = "az ad group show --group ${var.azuread_admin_group_name}"
    update = "az ad group delete --group ${var.azuread_admin_group_name} && az ad group create --display-name ${var.azuread_admin_group_name} --mail-nickname ${local.azuread_admin_group_mail_nickname}"
    delete = "az ad group delete --group ${var.azuread_admin_group_name}"
  }
}

Hi all, since it seems there is no traction as yet with fixing this in the API, I am proposing a potential fix for this error by retrying the group creation when this error is detected and the calling principal has been specified as an owner. The workaround relies on the other side of this API bug, that the calling principal is auto-added behind the scenes and the group is subsequently returned having the calling principal as an auto-appended owner.

If anyone is able to test out by compiling the provider locally from the bugfix/group-400-owner branch (see #1037), any such feedback will be greatly appreciated as it’s not feasible to field-test this workaround in all circumstances. Thanks!

I experienced this issue when I was authenticating using a service principal.

After I gave the Group.ReadWrite.All API permission to the SPN it worked.

This is also stated in the documentation:

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

If using the assignable_to_role property, this resource additionally requires one of the following application roles: RoleManagement.ReadWrite.Directory or Directory.ReadWrite.All

When authenticated with a user principal, this resource requires one of the following directory roles: Groups Administrator, User Administrator or Global Administrator

I must admit it isn’t the ideal solution to give such broad permissions.

In the enterprise I am working at, it is impossible for ordinary mortals to acquire such elevated rights.

My workaround for daily use in Terraform is to create the group via Azure CLI and import it into the state for further management via Terraform, e.g. like this:

AD_APP_DISPLAY_NAME='foo.bar'
AD_APP_TF_STATE_ADDR='module.foo.azuread_group.bar'

az ad group create --display-name "${AD_APP_DISPLAY_NAME}" --mail-nickname "$(cat /proc/sys/kernel/random/uuid)"

terraform import "${AD_APP_TF_STATE_ADDR}" "$(az ad group show --group "${AD_APP_DISPLAY_NAME}" --query 'objectId' --output 'tsv')"

(It is only the creation of the group that fails. Further modifications are working.)

That workaround seems to be working. Thanks a lot for sharing it @mlcooper!

Here is the code we are using:

owners = ["foo-bar-foo-1"]
  lifecycle {
    ignore_changes = [
      # Ignore changes to tags, e.g. because a management agent
      # updates these based on some ruleset managed elsewhere.
      owners,
    ]
  }

I understand. Just wanted to add every last bit of information I have.

Unfortunately that is correct. We’re hoping to get some traction on this very soon but right now Terraform cannot resolve this error. I’m afraid since this doesn’t affect any of our testing tenants that our ability to experiment with this is limited, however you might try adding additional arbitrary owners to the group to see if this helps bypass this error.

The error appears to stem from specifying the calling principal as the sole owner of the group. In many cases the API assigns that same principal as the default owner in the case that none are specified, but this doesn’t appear to be universal, and the ‘duplicate’ error only seems to occur for a subset of users.