Validation for Group ownership is broken

[manicminer]

There are recently added undocumented validation rules for Group ownership in Microsoft Graph which are broken. Discussions with the service team would indicate that this validation is intended to affect Microsoft 365 (unified) groups with the goal of preventing group creation without a group having an owner that is a user principal. However at the same time we are seeing errors around group ownership for security groups too and the behavior is inconsistent, sometimes preventing creation of a group no matter what combination of owners are specified.

At group creation time, this seems to manifest in a 400 response with the following error description:

HTTP/1.1 400 Bad Request

Date: Thu, 29 Jul 2021 10:20:37 GMT
Content-Type: application/json
Cache-Control: no-cache
Transfer-Encoding: chunked
Content-Encoding: gzip
Vary: Accept-Encoding
Strict-Transport-Security: max-age=31536000
request-id: fe3ae0a7-46d6-4a29-9c23-9ed2c4ad0b0a
client-request-id: fe3ae0a7-46d6-4a29-9c23-9ed2c4ad0b0a
x-ms-ags-diagnostic: {"ServerInfo":{"DataCenter":"West Europe","Slice":"E","Ring":"5","ScaleUnit":"003","RoleInstance":"AM1PEPF000051D7"}}
Link: <https://developer.microsoft-tst.com/en-us/graph/changes?$filterby=beta,PrivatePreview:Restricted_AU_Properties&from=2021-04-01&to=2021-05-01>;rel="deprecation";type="text/html"
Deprecation: 
Sunset: 
x-ms-resource-unit: 1

{
    "error": {
        "code": "Request_BadRequest",
        "innerError": {
            "client-request-id": "fe3ae0a7-46d6-4a29-9c23-9ed2c4ad0b0a",
            "date": "2021-07-29T10:20:38",
            "request-id": "fe3ae0a7-46d6-4a29-9c23-9ed2c4ad0b0a"
        },
        "message": "Request contains a property with duplicate values."
    }
}

This does not correlate with the request payload which might for example look like the following:

POST https://graph.microsoft.com/beta/659c0000-0000-0000-0000-00000000a82e/groups
HTTP/1.1

Host: graph.microsoft.com
User-Agent: Hamilton (Go-http-client/1.1) HashiCorp Terraform/1.0.0 (+https://www.terraform.io) Terraform Plugin SDK/2.6.1 terraform-provider-azuread/1.6.0 pid-222c6c49-1b0a-5959-a213-6608f9eb8820
Content-Length: 233
Accept: application/json
Authorization: Bearer ...
Content-Type: application/json; charset=utf-8
Accept-Encoding: gzip

{
    "displayName": "foobar2",
    "mailEnabled": false,
    "mailNickname": "6fb69a33-5961-f0a4-6041-7af7712c0d06",
    "[email protected]": [
        "https://graph.microsoft.com/beta/directoryObjects/06ee5fa0-7a61-4313-bae7-4d1bf50cbb03"
    ],
    "securityEnabled": true
}

This error is returned despite:

• The group being created not being a unified group but is a "traditional" AAD security group
• The group has a valid owner specified
• There are no duplicate fields or values, for owners or any other property

In addition, when removing owners from a group, where there are two owners and one of these is a service principal and the other is a user principal, and the group is a security group and not a unified group, a 400 response can sometimes be received with the following error:

The group must have at least one owner, hence this owner cannot be removed

These behaviors have been documented by ourselves and several community members, in the following related issues:

hashicorp/terraform-provider-azuread#464
hashicorp/terraform-provider-azuread#473
hashicorp/terraform-provider-azuread#478
hashicorp/terraform-provider-azuread#567

[askingcat]

It seems that the original request is modified by the API. If I send the request without the [email protected] property, a request such as the one @manicminer posted above succeeds and my user is - of course - still added as the owner. Issuing the same request, but already adding my or any other user as the owner via the [email protected] property then results again in the error message

Request contains a property with duplicate values.

FYI: If I use the active directory via Azure portal (azure.portal.com), the problem seems to be avoided by never setting [email protected]. 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.

[otabut]

Hi,

I was experiencing pretty much the same issue too.

As per the documentation here : https://registry.terraform.io/providers/hashicorp/azuread/latest/docs/resources/group

---

API Permissions
The following API permissions are required in order to use this resource.

When authenticated with a service principal, this resource requires one of the following application roles: Group.ReadWrite.All 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

---

It worked for me after having granted Group Administrator role.

Hope this helps.

[ju-la-berger]

Thanks for the tip @otabut. However, 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')"

[Rich79923]

Any update/progress on resolving this issue? As getting elevated permission is not an option for us and would be forced to do @ju-la-berger 's solution above which kind of defeats the point of using terraform...

[sumitkatre123]

Hi Team, any update its known issue for quite long time :)

[tfrancois]

Agreed - I can confirm this is still an issue when using Azure AD API to remove user as owner when a service principal is the rightful owner of the group - but is not being recognized as such - therefore preventing the removal of a user as owner. Please advise on the timelines for a fix on this issue. Thank you.

[tyler-stark-MRI]

Any updates here? Been over a year.

[bitsofinfo]

please fix this!

[heintonny]

I agree, I hope this ticket can get some prioritie.

This issue cause delay and automation challenges in our delivery of Azure Landingzones to Microsoft Customers. Expensive delay for everyone.

[michaelshire]

I would also like to point out that the current API is not idempotent.

Without using the above workaround (i.e. no using separate service principle creating the resource, but instead using my identity to create the resource):

Calling the API and setting the "owner" only as "Identity2" (not including my identity). The Group resource has both my identity and "Identity2" in the "Owners" field.

Applying the same change using the same parameters, results in my identity in the "owners" field being removed (breaking idempotency).

I can't create a service principle for this (too many hoops to jump through). Has the workaround been tested for idempotency? I would expect the SP to be included in the Owners on the create, and removed in subsequent applies.

[itpropro]

Any update on this issue or #653 @darrelmiller @baywet ?

[baywet]

Hi everyone,
Apologies for the late reply here: we (the SDKs & tooling team) are not watching/triaging this repo. Only using it to capture metadata defects to improve SDKs generation.
The service team is not watching this repository either. The best way to get their attention for this kind of issues is to open a support ticket on a production tenant (see the links at the bottom of the page).
Don't assume you do not need to open a ticket because somebody else on this thread might already have opened one.
I'm going to go ahead and close this issue to make it clear no resolution will come from here directly.

[itpropro]

Hi everyone, Apologies for the late reply here: we (the SDKs & tooling team) are not watching/triaging this repo. Only using it to capture metadata defects to improve SDKs generation. The service team is not watching this repository either. The best way to get their attention for this kind of issues is to open a support ticket on a production tenant (see the links at the bottom of the page). Don't assume you do not need to open a ticket because somebody else on this thread might already have opened one. I'm going to go ahead and close this issue to make it clear no resolution will come from here directly.

Thanks for the clarification!