Prerequisites
- Terraform
- AzureAD Provider
v1.5and newer
Problem
The behavior of
owners for the Resource azuread_group is not consistent for all users due to Microsoft Azure API / Graph inconsistencies. This has resulted in several design changes of the Terraform AzureAD Provider in order to workaround these inconsistencies, however not all symptoms and scenarios have been addressed for everyone since the API behaves in ways that make our potential workarounds mutually exclusive. You might encounter a AzureAD POST response similar to this when adding your own principle or object ID in the
owners block of the azuread_group resource.data "azuread_client_config" "current" {}
resource "azuread_user" "group_owner" {
user_principal_name = "logged.in.user@email.com"
display_name = "yourname"
mail_nickname = "yournickname"
password = "SecretP@sswd99!"
}
resource "azuread_group" "example" {
display_name = "yourself-example"
mail_enabled = true
mail_nickname = "yourselfExampleGroup"
security_enabled = true
types = ["Unified"]
owners = [
data.azuread_client_config.current.object_id,
]
}
[DEBUG] Begin AzureAD Response for POST https://graph.microsoft.com/beta//groups:
==========================================
HTTP/1.1 400 Bad Request
...
{"error":{"code":"Request_BadRequest","message":"Request contains a property with duplicate values.","innerError":{"date":"...","request-id":"...","client-request-id":"..."}}}
...
==========================================
End AzureAD Response
Cause
- Various Microsoft Azure API inconsistencies are causing these issues. The provider design has been enhanced as much as possible to help with the most common inconsistencies. Not all can be avoided from the provider side due to dependencies and impact it has on others. You can test this outside of Terraform by using this Microsoft Graph Explorer and
POSTyour payload that includes your logged-in user.
Outcome
The final decision was to design the provider to default initial owner as the calling principal when no
owners are specified in the resource and it is recommended that practitioners include their calling principal when specifying owners; avoiding most API inconsistencies, but not all. For most users, the API allows the calling principal to be included in the list of owners, and for others, it requires that the calling principal is one of the owners.There are also additional constraints around what kind of principals must be included in the initial set of
owners when creating a group. The API does not automatically include the caller as an owner for everyone, so altering the behavior of the provider here it is not an option and would leave many users with owner-less groups. This leaves us in a position where we cannot definitively document when a user should or should not include their own principle in the list of owners because it is not the same situation for everyone.
Recommendation
- Please report this problem in an Azure Service Ticket to help with visibility and future fixes & enhancements.
- Stay up-to-date with the newest AzureAD Provider Versions released when possible to account for various fixes with the API since the initial beta support for Microsoft Graph was introduced in
v1.5.