You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.0.7
on windows_amd64
+ provider registry.terraform.io/hashicorp/azuread v2.2.1
Affected Resource(s)
azuread_group
Terraform Configuration Files
terraform {
backend"local" {}
required_version="~> 1.0"required_providers {
azuread={
source ="hashicorp/azuread"
version ="~> 2.2"
}
}
}
provider"azuread" {
alias="dev"
}
resource"azuread_group""group-to-be-made-dynamic" {
provider=azuread.devdisplay_name="~~testing~~ make this dynamic later"description="test group for terraform azuread 2.x"assignable_to_role=falseprevent_duplicate_names=truesecurity_enabled=truevisibility="Private"
}
output"group_resource" {
value=azuread_group.group-to-be-made-dynamic
}
Output
terraform plan
azuread_group.group-to-be-made-dynamic: Refreshing state... [id=2b219e17-1405-414b-82ec-96b86461469d]
╷
│ Error: An existing "azuread_group" with name "~~testing~~ make this dynamic later" (ID: "2b219e17-1405-414b-82ec-96b86461469d") was found and `prevent_duplicate_names` was specified. To be managed via Terraform, this resource needs to be imported into the State. Please see the resource documentation for "azuread_group" for more information.
│
Expected Behavior
Running terraform plan or terraform apply should still find the azuread_group it created (or was imported) earlier , regardless of the object's membershipRule setting. This was the behaviour of provider <= 1.6.
Actual Behavior
Terraform does not detect the group any longer and aims at creating a fresh one. Depending on the setting of prevent_duplicate_names it will either create an additional copy or refuse the creation (see output above).
Steps to Reproduce
terraform apply
manually change the created AzureAD group to have a dynamic membership rule (any will do)
terraform plan
Important Factoids
I am porting terraform workflows to provider 2.x. In some cases groups created initially via terraform, are turned into dynamic membership groups by a Graph API call after terraform apply.
Nonetheless those groups are kept in terraform state in order to support referencing them (e.g. for azurerm RBAC rules) as well as to support future display_name, description and owner changes.
This process works perfectly on azuread provider <= 1.6
I do realize that actual support for membershipRule might be on the roadmap already but as long as this is not implemented, the provider should also consider and check if groups are already in its state regardless of their membershipRule attribute.
The text was updated successfully, but these errors were encountered:
Hi @rafabu, thanks for opening this issue. As you have posited, this incompatibility stems from introduction of support for unified groups (M365 groups) and the way in which the API overloads these two concerns in a single property.
Whilst we could add a workaround to avoid recreating groups with dynamic membership, such a workaround would have to be removed when we soon add proper support for dynamic memberships, and that removal would be a breaking change. Unfortunately that means we won't be able to work around this in the immediate term.
I would suggest considering the azuread_group data source as a workaround in the meantime, or use a lifecycle block to force the provider to ignore the type property, for example:
I'd also recommend subscribing to #132 as that issue will be updated when we add support for dynamic memberships. For now, I'm going to close this one as there's unfortunately no stable workaround that we can implement in the meantime.
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.
Community Note
Terraform (and AzureAD Provider) Version
Affected Resource(s)
azuread_group
Terraform Configuration Files
Output
Expected Behavior
Running terraform plan or terraform apply should still find the azuread_group it created (or was imported) earlier , regardless of the object's
membershipRule
setting. This was the behaviour of provider <= 1.6.Actual Behavior
Terraform does not detect the group any longer and aims at creating a fresh one. Depending on the setting of
prevent_duplicate_names
it will either create an additional copy or refuse the creation (see output above).Steps to Reproduce
terraform apply
terraform plan
Important Factoids
I am porting terraform workflows to provider 2.x. In some cases groups created initially via terraform, are turned into dynamic membership groups by a Graph API call after terraform apply.
Nonetheless those groups are kept in terraform state in order to support referencing them (e.g. for azurerm RBAC rules) as well as to support future
display_name
,description
andowner
changes.This process works perfectly on azuread provider <= 1.6
I do realize that actual support for
membershipRule
might be on the roadmap already but as long as this is not implemented, the provider should also consider and check if groups are already in its state regardless of their membershipRule attribute.The text was updated successfully, but these errors were encountered: