azuread_invitation requires User.ReadWrite permissions

[pmjacinto]

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 v1.2.7 on darwin_amd64
azuread 2.28.1

Affected Resource(s)

• azuread_invitation

Terraform Configuration Files

provider "azuread" {
  tenant_id = "..."
  client_id     = "..."
  client_secret = "..."
}

resource "azuread_invitation" "test" {
  redirect_url       = "https://portal.azure.com/"
  user_email_address = "abc.def@domain.com"
}

terraform {
  required_providers {
    azuread = {
      source  = "hashicorp/azuread"
      version = "=2.28.1"
    }
  }
  required_version = ">= 0.15"
}

Expected Behavior

Expected to be able to invite a user when authenticated with an SP that only has User.Invite.All and does not have User.ReadWrite.All or Directory.ReadWrite.All as stated in the provider docs.

https://registry.terraform.io/providers/hashicorp/azuread/latest/docs/resources/invitation

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

Actual Behavior

Error when applying: "Failed to patch guest user after creating invitation"

Steps to Reproduce

1. terraform apply

Important Factoids

The provider code tries to patch the newly created guest user to determine if it exists.

terraform-provider-azuread/internal/services/invitations/invitation_resource.go

Lines 166 to 191 in 720f09e

	// Attempt to patch the newly created guest user, which will tell us whether it exists yet
	// The SDK handles retries for us here in the event of 404, 429 or 5xx, then returns after giving up
	status, err := usersClient.Update(ctx, msgraph.User{
	DirectoryObject: msgraph.DirectoryObject{
	ID: invitation.InvitedUser.ID,
	},
	CompanyName: utils.NullableString("TERRAFORM_UPDATE"),
	})
	if err != nil {
	if status == http.StatusNotFound {
	return tf.ErrorDiagF(err, "Timed out whilst waiting for new guest user to be replicated in Azure AD")
	}
	return tf.ErrorDiagF(err, "Failed to patch guest user after creating invitation")
	}
	status, err = usersClient.Update(ctx, msgraph.User{
	DirectoryObject: msgraph.DirectoryObject{
	ID: invitation.InvitedUser.ID,
	},
	CompanyName: utils.NullableString(""),
	})
	if err != nil {
	if status == http.StatusNotFound {
	return tf.ErrorDiagF(err, "Timed out whilst waiting for new guest user to be replicated in Azure AD")
	}
	return tf.ErrorDiagF(err, "Failed to patch guest user after creating invitation")
	}

Is a PATCH required for this scenario instead of a GET?

[manicminer]

@pmjacinto Thanks for reporting this. Whilst it's possible to create invitations having only User.Invite.All, unfortunately a PATCH request has been found to be necessary as GET operations on newly created objects in MS Graph exhibit behavior attributable to caching, and are not reliable. Accordingly we will have to put this down as a documentation bug.

[AzCii]

I just ran into the same problem, providing User.ReadWrite to the user executing terraform is not an option for me.
Would it be possible to make this check optional insted? or maybe an option to select PATCH or GET in the terraform configuration.

[AzCii]

When doing a destroy, the User.Invite.All, is also not enough.

UsersClient.BaseClient.Delete(): unexpected status 403 with OData error: Authorization_RequestDenied: Insufficient privileges to complete the operation.

Here i would again suggest that the delete is optional in the terraform configuration, if it's not possible to do this with only Users.Invite.All

[magic-happenz]

@manicminer I just run into this. Can you explain how this issue can be open more than two years without fixing at least the mentioned "documentation bug"?
I wanted to add that I would suggest to solve this problem differently. Using a patch to check if the user was successfully invited is a pretty bad workaround requiring a permission overkill. We have restricted users and processes with ' User.Invite.All' and allow them to only write on the users they invited using administrative units. The patch avoids that this is useful for anybody using Terraform for that.
Assigning access to read and write all users in the directory just to check if an invite was successfully is a pretty bad workaround and should not have been implemented in the first place. Could you please update us on how its planned to address this problem now two years later?