azurerm_mssql_managed_instance_active_directory_administrator unable to destroy when azuread_authentication_only is set to True

[gunadeau]

Is there an existing issue for this?

• [X] I have searched the existing issues

Community Note

• Please vote on this issue by adding a :thumbsup: reaction to the original issue to help the community and maintainers prioritize this request
• Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment

Terraform Version

1.4.2

AzureRM Provider Version

3.48.0

Affected Resource(s)/Data Source(s)

azuread_authentication_only

Terraform Configuration Files

resource "azurerm_mssql_managed_instance_active_directory_administrator" "example" {
  managed_instance_id = azurerm_mssql_managed_instance.sql_mi_example.id
  login_username      = var.sql_managed_instance_config_1.sqlmiAdminGroup
  object_id           = data.azuread_group.sqlmiAdminGroup.object_id
  tenant_id           = data.azurerm_subscription.current.tenant_id
  azuread_authentication_only = true
}

Debug Output/Panic Output

azurerm_mssql_managed_instance_active_directory_administrator.example: Destroying... [id=/subscriptions/XXXXX/resourceGroups/mymanagedinstancesRG/providers/Microsoft.Sql/managedInstances/mymanagedinstances/administrators/ActiveDirectory]
╷
│ Error: deleting Managed Instance Azure Active Directory Administrator: (Administrator Name "ActiveDirectory" / Managed Instance Name "mymanagedinstances" / Resource Group "mymanagedinstancesRG"): sql.ManagedInstanceAdministratorsClient#Delete: Failure sending request: StatusCode=400 -- Original Error: Code="InvalidManagedServerAzureADAdminDeleteOperation" Message="User tried to delete managed server Azure Active Azure admin when AzureADOnlyAuthentication is set, please use azureADOnlyAuthentications API first."
│ 
│ deleting Managed Instance Azure Active Directory Administrator:
│ (Administrator Name "ActiveDirectory" / Managed Instance Name
│ "mymanagedinstances" / Resource Group
│ "mymanagedinstancesRG"):
│ sql.ManagedInstanceAdministratorsClient#Delete: Failure sending request:
│ StatusCode=400 -- Original Error:
│ Code="InvalidManagedServerAzureADAdminDeleteOperation" Message="User tried
│ to delete managed server Azure Active Azure admin when
│ AzureADOnlyAuthentication is set, please use azureADOnlyAuthentications API
│ first."
╵
##[error]Error: The process '/opt/hostedtoolcache/terraform/1.4.2/x64/terraform' failed with exit code 1

Expected Behaviour

The issue is happening while trying to destroy the whole SQL Managed instances.

I think it should not try to destroy "azurerm_mssql_managed_instance_active_directory_administrator" since it will get automatically destroy by the SQL Managed instances itself.

If someone really need to only destroy "azurerm_mssql_managed_instance_active_directory_administrator" it would have to turn this parameter to Falseazuread_authentication_only = False before doing it.

In our case, there is no way to turn this parameter to "false": azuread_authentication_only = true, we have an internal policies that is preventing us to do it.

A work around for now is to destroy the SQL managed instance directly in the portal, when it's done, we can start the destroy in Terraform to destroy the left over.

Actual Behaviour

When appplying, Terraform try to destroy the resource: azurerm_mssql_managed_instance_active_directory_administrator before destroying the SQL Managed Instance. It failed because it says the resource cannot be deleted since the flag: azuread_authentication_only is set to True

Steps to Reproduce

1. Create a SQL managed instance using Terraform
2. Make sure to useazurerm_mssql_managed_instance_active_directory_administrator and specify an Active Directory Group and this parameter to TRUE: azuread_authentication_only
3. Once the SQL managed instance is created, try to destroy it with Terraform

Important Factoids

No response

References

No response

[shhintbw]

We are also running into this issue. In general you would expect to create the administrator resource first before the managed instance and the resource will then try to delete that administrator resource first, which is disallowed based on the information in the error message (or the mechanism needs to change for how to do that).

[Matthew0x]

The same issue is also present with Synapse Analytics Workspace upon activation of azureread_authentication_only. Using TF the deployment will succeed and create the resource, but whenever removing it, the AAD admin object/setting will block the destroy action.

The workaround (like you said) was to use a custom script that will run before the destroy action on the setting/object. After the script had ran and disabled the option, the destroy is performed with no further issues.

In case of Synapse the AAD setting can be split apart from the workspace's object, but I didn't notice a difference in behavior (I think the problem is that the setting is declared in the main object and not separable so it's not gone until the main object is destroyed)

[AndrewRiceSCA]

Same issue. I was able to work around by adding the following to my Synapse resource to disable azuread_authentication_only as part of the destroy. Only works if your aad_admin and sql_aad_admin are configured as part of your Synapse resource.

provisioner "local-exec" {
  when    = destroy
  command = "az synapse ad-only-auth disable --workspace-name ${self.name} -g ${self.resource_group_name}"
}

[fgarcia-cnb]

having this issue in synapse as well. since we are using a workspace key, the AD admin has to be separate from the main resource, so the provisioner would have to be on the ad admin resource, but cannot use "self" since it actually needs to reference the parent. i guess i could parse the parent from self to get that working. still, destroy time provisioners are no longer recommended. also, wont work with terraform cloud/enterprise

ideally the ad admin resource should record the "ad auth only" flag, and disable it if necessary, remove the AD admin, then restore the original ad auth setting if necessary.

[nathanblair]

I wonder if this issue is related/would resolve? #24801