azuread_application_from_template - DeletingSamlSpNotAllowed: Property appId is invalid

[niven01]

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

Tested with

Terraform versions 1.5.0 , 1.8.3
AzureAD Versions: 2.48 , 2.50

Affected Resource(s)

• azuread_application_from_template

Terraform Configuration Files

data "azuread_application_template" "sso_app_template" {
  display_name = "AWS Single-Account Access"
}

resource "azuread_application_from_template" "sso_app" {
  display_name = var.application_name
  template_id  = data.azuread_application_template.sso_app_template.template_id

  provisioner "local-exec" {
    command = "az ad sp update --id ${azuread_application_from_template.sso_app.service_principal_object_id} --set preferredSingleSignOnMode='saml'"
  }
}

Debug Output

https://gist.github.com/niven01/a683eee62518b3c6fbebf8774816d39c

Panic Output

Expected Behavior

Running a terraform destroy should delete app registration. This had been working a month ago. It had not been ran since then.

Actual Behavior

terraform destroy fails to delete app registration with following

Error: deleting Application From Template (Template ID: "8b1025e4-1dd2-430b-a150-2ef79cd700f5", Application ID: "ea5fe2bc-58c1-483e-bd4f-40c560986ebc", Service Principal ID: "24cdec0c-d201-4af9-8752-fd5735276f2f"): ApplicationsClient.BaseClient.Delete(): unexpected status 400 with OData error: DeletingSamlSpNotAllowed: Property appId is invalid

Steps to Reproduce

1. terraform apply -var="application_name=MY_APP_NAME" --auto-approve
2. terraform destroy -var="application_name=MY_APP_NAME" --auto-approve

Important Factoids

References

• #0000

[paulellis55]

@niven01 - I am seeing the same error (error: DeletingSamlSpNotAllowed: Property appId is invalid) in a different context - trying to delete an Azure enterprise app through its MSGraph API endpoint. It was all working fine until about a week ago.

[benehofer]

The error occurs precisely when the identifiers or reply URLs of the SAML configuration of the registered application do not correspond to one of the validated domains of the tenant. In this case, the service principal cannot be deleted. This can be checked with the PS cmdlet Remove-AzureADServicePrincipal; the detailed error message referring to invalid URLs is displayed. The solution is to first adapt the SAML URLs accordingly and then destroy the app via TF.

[nbaju1]

This can be checked with the PS cmdlet Remove-AzureADServicePrincipal; the detailed error message referring to invalid URLs is displayed.

Can also be checked by trying to delete an application with an "incorrect" identifier URI in the Azure Portal.

This is new behavior, so a new "feature" from Microsoft, perhaps?

[paulellis55]

Thanks @benehofer for the tip - the error message from the PS cmdlet Remove-AzureADServicePrincipal provides much more useful information than we were seeing from the API.
Message: Deleting a service principal with 'preferredSingleSignOnMode' property 'saml' is not allowed when the application contains identifierUris that do not use a verified domain of the organization or its subdomain, or end with a trailing slash

In our case we're working around the new "feature" by changing the registered application's attribute called identifierUris to match the verified domain of the Entra ID tenant before calling to delete the app.

[niven01]

Looking at this further it appears there is a deeper problem and definitely due to a Microsoft change as the process I'm about to describe is actually done via API. I have tested via Terraform and the Portal too.

We have automation to onboard app registrations and setup SSO with AWS. We need to setup multiple identifiers for multiple instances. This had been working up to 2 days ago. We are basically following the steps outlines here: https://learn.microsoft.com/en-us/entra/identity/saas-apps/amazon-web-service-tutorial#aws-single-account-access-architecture

When setting up the IdentifierURI I need to pass the following for example. App Reg one: https://signin.aws.amazon.com/saml#1, App Reg Two: https://signin.aws.amazon.com/saml#2

As per documentation adding the #2 makes the Identifier unique and allows us to have multiple.

This has now stopped working via API, Terraform or Directly in the Portal meaning we cannot onboard any more AWS SSO App Registrations. Azure is aware an app registration already has the value of signin.aws.amazon.com/saml and denies the request.

API response: Another object with the same value for property identifierUris already exists

I think the workaround for deleting the app registration by changing the registered application's attribute called identifierUris to match the verified domain of the Entra ID tenant before calling to delete the app is working because value being entered does not exist in any other SAML config for an app registration at the time. Then once deleted the workaround can be used again for the next deletion as the app the change was made to is now gone.

I'd be interested if anyone else is having issues creating applications that use the same pattern needed for AWS.

We have a ticket logged with Microsoft to discuss this. i dont think is a fix needed in Terraform at this point

[niven01]

FYI, the issue when creating app registrations for AWS appears to have been resolved. The original issue still exists. The workaround provided of changing the attribute identifierUris to the verified domain of the Entra ID tenant before calling to delete the app still appears to work.

[DanGaita]

There's another, simple, sad, and manual workaround: delete the enterprise app (service principal) from the portal!

That being said, the portal is basically calling a function in the back-end. It's usually the same function that's called when you run the corresponding PowerShell cmdlet. Finding out what exactly is being called when running an enterprise app delete from the portal would be interesting.