Azure.ResourceManager.Sql 1.3.0 – ImportExistingDatabaseDefinition: ManagedIdentity usage and association (system-assigned vs user-assigned)

Question

Azure.ResourceManager.Sql 1.3.0 – ImportExistingDatabaseDefinition: ManagedIdentity usage and association (system-assigned vs user-assigned)

FELDNER Ilanit 0

Hi,

We’re using the Azure.ResourceManager.Sql SDK (v 1.3.0) in C# to automate BACPAC imports with managed identity access to both the storage account and the SQL server.

The constructor for ImportExistingDatabaseDefinition now supports StorageKeyType.ManagedIdentity and AuthenticationType.ManagedIdentity, and the comments suggest that when using managed identity, the storageKey and administratorLogin parameters should contain the resource ID of the identity.

However, the implementation still enforces non-null checks on both parameters. This makes it unclear whether the system-assigned managed identity is actually supported or if only user-assigned identities are currently functional.

Questions

Is the system-assigned managed identity supported when using StorageKeyType.ManagedIdentity, or does the SDK currently only support user-assigned identities?
If user-assigned MI is required, is the correct setup to assign it to the SQL server and grant it Storage Blob Data Reader on the target container, then pass its resource ID to the ImportExistingDatabaseDefinition parameters?
Specifically, does the identity need to be explicitly assigned in the Azure Portal under SQL Server → Identity → User-assigned → Add → [select our Managed Identity] for the import to work?

Is there an official example or documentation describing how to properly associate a managed identity with the SQL import operation?

Abhisek Mishra 940 Reputation points Microsoft External Staff Moderator

2025-11-06T08:14:58.32+00:00
Hi FELDNER Ilanit,

Welcome to the Microsoft Q&A and thank you for posting your query here.

Let’s break down your inquiries:

Is system‑assigned MI supported?
Practically no (with Azure.ResourceManager.Sql v1.3.0). The import model requires you to pass the Managed Identity’s resource ID in both storageKey and administratorLogin when you set StorageKeyType = ManagedIdentity and AuthenticationType = ManagedIdentity. A system‑assigned MI (SA‑MI) has no standalone ARM resource ID, while a user‑assigned MI (UAMI) does—so only UAMI can satisfy those parameters today.

If UAMI is required, what’s the correct setup? Yes, you are correct. The general setup for using a user-assigned managed identity (MI) for a BACPAC import is:

Assign the user-assigned MI to the SQL Server: Go to SQL Server > Identity in the Azure portal. Under User-assigned, select Add, and assign the desired managed identity to the SQL server.

Grant the MI the appropriate permissions on the Storage Account: In the target Storage Account (where the BACPAC file is stored), ensure that the user-assigned managed identity has the Storage Blob Data Reader role on the specific container.

Pass the resource ID of the user-assigned MI: When initializing the ImportExistingDatabaseDefinition, pass the resource ID of the user-assigned MI for both the storageKey and administratorLogin parameters. This is required as the SDK uses the MI’s permissions to access the storage and perform the import.

Must I assign that UAMI under SQL Server → Identity → User‑assigned? Yes, the user-assigned managed identity needs to be explicitly assigned to the SQL Server via the Azure portal for the import to work correctly. This is a necessary step because the SQL Server instance will use this MI to authenticate and access the storage account.

Navigate to SQL Server > Identity in the portal, and under User-assigned, add the managed identity.

This ensures that the SQL server can authenticate and authorize the managed identity for accessing the target container in the storage account.

As of now, I have not come across a single document where a comprehensive official example in the documentation is present, that fully walks through this case of using managed identities for BACPAC import operations with the Azure SDK.

I hope this information is helpful! If you still have questions or you come across issues, please let us know what is needed in the comments so this question can be answered.
VRISHABHANATH PATIL 1,475 Reputation points Microsoft External Staff Moderator

2025-11-11T06:07:56.39+00:00

Hi,

I hope you had a chance to review the information shared earlier, and I hope this information has been helpful! If you still have questions, please let us know what is needed in the comments so the question can be answered.
FELDNER Ilanit 0 Reputation points

2025-11-12T09:16:54.3133333+00:00

Thank you very much for the detailed elaboration — it really helped clarify the Managed Identity behavior.

I just want to double-check one important point before proceeding, as this is a large production system and the impact could be significant.

Our SQL Server already uses a system-assigned managed identity (SAMI) for several production operations. To enable import/export through the ARM SDK, we’re considering adding a user-assigned managed identity (UAMI).

However, the fact that adding a UAMI effectively takes over the existing system-assigned identity makes this a real concern — especially since our servers already use TDE with existing encrypted data, which makes testing and rollback scenarios very difficult.

So before we proceed:

Can a SQL Server safely have both SAMI and UAMI without disrupting existing SAMI-based access?

Is it confirmed that UAMI takes precedence once assigned?

Has this setup been validated on servers already using TDE encryption keys tied to the SAMI?

This situation is quite risky to test in production, so I’d appreciate any clarification or confirmation from the product team.

Thanks again for your help and the detailed explanations so far.
Abhisek Mishra 940 Reputation points Microsoft External Staff Moderator

2025-11-12T15:34:30.8433333+00:00
Hi FELDNER Ilanit,

Thank you for asking the question in detail and highlighting the critical nature of your production environment. It's always good to double check.

Regarding having both system-assigned managed identity (SAMI) and user-assigned managed identity (UAMI) on an Azure SQL Server:
Yes. Azure supports assigning both a system-assigned managed identity (SAMI) and one or more user-assigned managed identities (UAMIs) to the same SQL Server resource. This means you can enable a UAMI alongside your existing SAMI without immediately removing or disabling SAMI-based access.

However, when you add a UAMI, it becomes the primary identity for outbound operations (such as import/export via ARM SDK or Key Vault access). SAMI remains enabled but will not be used for these operations unless explicitly referenced. This is by design and documented in Azure identity behavior.

For Transparent Data Encryption (TDE) and encryption keys tied to a SAMI:
Adding a UAMI does not automatically revoke or replace TDE keys associated with SAMI. Existing encryption continues to work as long as SAMI retains its Key Vault permissions. However, if TDE uses customer-managed keys (BYOK), you must ensure the UAMI has equivalent Key Vault permissions (get, wrapKey, unwrapKey) because the UAMI will be used for outbound calls once it becomes primary.

Given the sensitive nature of TDE and production encryption keys, it is advisable to:

Maintain SAMI to preserve existing access and encryption key bindings.

Grant UAMI the required permissions for Storage (Blob Data Reader) and Key Vault before using it for import/export or encryption operations.

Validate in a staging environment that mirrors production, if possible.

Use sys.dm_server_managed_identities to confirm which identity is primary after changes.

You can refer below links to learn furtheron SAMI and UAMI.

https://learn.microsoft.com/en-us/entra/identity/managed-identities-azure-resources/overview

https://learn.microsoft.com/en-us/azure/azure-sql/database/transparent-data-encryption-byok-overview?view=azuresql&tabs=azurekeyvault%2Cazurekeyvaultrequirements%2Cazurekeyvaultrecommendations

I hope this information is helpful! If you still have questions or you come across issues, please let us know what is needed in the comments so this question can be answered.

Your answer

VRISHABHANATH PATIL 1,475 Reputation points Microsoft External Staff Moderator

2025-11-11T06:07:56.39+00:00

Hi,

I hope you had a chance to review the information shared earlier, and I hope this information has been helpful! If you still have questions, please let us know what is needed in the comments so the question can be answered.
FELDNER Ilanit 0 Reputation points

2025-11-12T09:16:54.3133333+00:00

Thank you very much for the detailed elaboration — it really helped clarify the Managed Identity behavior.

I just want to double-check one important point before proceeding, as this is a large production system and the impact could be significant.

Our SQL Server already uses a system-assigned managed identity (SAMI) for several production operations. To enable import/export through the ARM SDK, we’re considering adding a user-assigned managed identity (UAMI).

However, the fact that adding a UAMI effectively takes over the existing system-assigned identity makes this a real concern — especially since our servers already use TDE with existing encrypted data, which makes testing and rollback scenarios very difficult.

So before we proceed:

Can a SQL Server safely have both SAMI and UAMI without disrupting existing SAMI-based access?

Is it confirmed that UAMI takes precedence once assigned?

Has this setup been validated on servers already using TDE encryption keys tied to the SAMI?

This situation is quite risky to test in production, so I’d appreciate any clarification or confirmation from the product team.

Thanks again for your help and the detailed explanations so far.

Share via

Azure.ResourceManager.Sql 1.3.0 – ImportExistingDatabaseDefinition: ManagedIdentity usage and association (system-assigned vs user-assigned)

Questions

Your answer