terraform-provider-azuread
terraform-provider-azuread copied to clipboard
azuread_access_package_catalog access error despite global administrator
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
Affected Resource(s)
-
azuread_access_package_catalog_role
-
azuread_access_package_catalog
-
azuread_access_package_catalog_role_assignment
Terraform Configuration Files
data "azuread_group" "owners" {
display_name = var.owner_group
}
data "azuread_access_package_catalog_role" "owner_role" {
display_name = "Catalog owner"
}
resource "azuread_access_package_catalog" "catalog" {
display_name = var.name
description = var.description
externally_visible = var.externally_visible
published = var.published
}
resource "azuread_access_package_catalog_role_assignment" "catalog_owner_assignment" {
role_id = data.azuread_access_package_catalog_role.owner_role.object_id
principal_object_id = data.azuread_group.owners.object_id
catalog_id = azuread_access_package_catalog.catalog.id
}
Debug Output
https://gist.github.com/TechnicallyJoe/7958bc889ba24ebdc3db9485e68b91da
Panic Output
Expected Behavior
It to create a catalog
Actual Behavior
It errors -> See output
Steps to Reproduce
-
terraform apply
Important Factoids
- This was run from an account with 'Catalog Creator'
- This was also attempted to run from an account with 'Global Administrator'
- The same user principal (me) can create catalogs in the UI just fine.
- Removing the
data "azuread_access_package_catalog_role" "owner_role" {
and putting in the id directly replaces the error with an error onazuread_access_package_catalog
- az login was used for authentication
- azuread version 2.41.0 was used.
UPDATE:
Also tested manually creating a catalog and then adding resources to it. Got errors using my user principal, but setting up a service principal with EntitlementManagement.Read.All
rights worked and manually assigning it to the catalog owners on the catalog.
UPDATE 2:
Logging into an Service Principal using az cli also does not work. I had to use environment vars to get it to work. That is, at the very least, a related bug, if not the same one.
For some additional information on this topic:
I am having the same authorization issue, as long as I am working with my user in terraform:
Planning failed. Terraform encountered an error while generating this plan.
╷
│ Error: Retrieving access package catalog with object ID: "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"
│
│ with azuread_access_package_catalog.catalog,
│ on C:\terraform\module.tf line 3, in resource "azuread_access_package_catalog" "catalog":
│ 3: resource "azuread_access_package_catalog" "catalog" {
│
│ AccessPackageCatalogClient.BaseClient.Get(): unexpected status 403 with OData error: UnAuthorized: User is not authorized to perform the operation. Reason: The caller is not authorized.
╵
I have tested with accounts with the following permissions:
- Global Administrator
- Catalog owner
The moment I switch authorisation to a service principal the plan and apply works just fine. The service princial has the Catalog owner permission on that catalog.
Are you making sure to sign out and sign back in to Azure CLI after assigning directory roles? You can also try deleting the ~/.azure
directory and signing back in again.
I used the configuration specified above and it resulted in the same error as @TechnicallyJoe stated above. I also deleted the directory and re-signed in. Same behavior as previously. My User: fails, SPN works.
I am able to test even more, if you have anything other that I might try?
Looks like we need to update our docs guidance for this data source, as the API docs state that EntitlementManagement.Read.All
is needed. That said, you should probably get this permissions via Global Administrator
so I'm not sure why everyone is getting a 403. Unless you are signed in with a personal Microsoft account (e.g. via live.com) rather than a directory account (e.g. via login.microsoftonline.com)? Personal accounts are not supported.
I am definitly using no personal account.
Is there any updates on this topic here? I would be happy to provide any further debug infos.
I think this is the same issue as #1069 and is an upstream Microsoft issue. See https://github.com/hashicorp/terraform-provider-azuread/issues/1069#issuecomment-1511882415
I also have this issue.
I used a service principle with the EntitlementManagement.ReadWrite.All
role to build catalogs and access packages without policies. I was hoping to have catalog admins and catalog owners bulk create the policies with Terraform. But unless they log in to the Azure CLI with a service principle, no role or combination of roles will allow them to deploy, getting the same 403 error. Even GA is insufficient.
Of note, our tenant does require admin consent for EntitlementManagement.ReadWrite.All
but directory roles should be in play when authenticating as a user and not a SP.
Hope this sees some progress soon.
Any updates to this? This is insanely annoying when testing with a user principle.
I can confirm that this is still an issue.
I have the same issue. I tryed to import existing azuread_access_package_catalog and got
AccessPackageCatalogClient.BaseClient.Get(): unexpected status 403 with OData error: UnAuthorized: User is not authorized to perform the operation. Reason: The caller is not authorized.
The call https://graph.microsoft.com/v1.0/identityGovernance/entitlementManagement/catalogs/{guid} works in Microsoft Graph Explorer. In the request is a bearer token included. It seems that such a token ist not provided via the terraform calls.
Some more info:
I created an SP and tried logging in with it using the azure cli - Still wouldn't work. But if i add the SP using environment vars then it works fine. At least its a related bug
EDIT: I have added this to the original post.