Getting Started with Azure SQL Data Sync Using User-Assigned Managed Identity (UAMI)
Azure SQL Data Sync is a powerful service that enables data synchronization across multiple Azure SQL Databases. Traditionally, Data Sync relied on SQL Authentication, requiring administrators to manage usernames and passwords for both hub and member databases. With the introduction of User-Assigned Managed Identity (UAMI) support, Azure SQL Data Sync now provides a more secure and modern authentication model built on Microsoft Entra ID. This enhancement reduces credential management overhead, eliminates password storage concerns, and helps organizations strengthen their security posture. In this article, we'll explore how to onboard Azure SQL Data Sync with UAMI, configure the required permissions, create synchronization components, and review best practices for long-term management. Why Use UAMI with Azure SQL Data Sync? User-Assigned Managed Identity offers several advantages over traditional SQL authentication: Eliminates password storage and rotation requirements Reduces credential exposure risks Integrates with Microsoft Entra ID authentication Supports centralized identity management Improves compliance and security posture Simplifies operational maintenance Whether you're deploying a new synchronization topology or modernizing an existing Data Sync environment, UAMI provides a secure cloud-native alternative to password-based authentication. Architecture Overview A typical UAMI-enabled Azure SQL Data Sync deployment looks like this: Authentication Method: Microsoft Entra ID via User-Assigned Managed Identity The same managed identity can be used by Data Sync to authenticate against all participating databases. Prerequisites Before configuring Azure SQL Data Sync with UAMI, ensure the following prerequisites are completed: 1. Enable Microsoft Entra Authentication The Azure SQL Server hosting both Hub and Member databases must have Microsoft Entra authentication enabled and an Entra administrator configured. 2. Create a User-Assigned Managed Identity Create a UAMI within Azure and collect the following information: Managed Identity Name Client ID Resource ID These values will be required during configuration. 3. Install the Required PowerShell Module UAMI support requires the Azure SQL preview PowerShell module: Install-Module Az.Sql -RequiredVersion 6.6.0-preview ` -AllowPrerelease ` -Force ` -AllowClobber Or a later version that includes Data Sync UAMI support. Phase 1: Configure Database Access Before Data Sync can use a managed identity, the identity must be granted access to all databases participating in synchronization. Connect to each Hub and Member database using a Microsoft Entra administrator account and create a user for the managed identity. Example: DECLARE @MSIname SYSNAME = '<UAMI_NAME>'; DECLARE @dbName SYSNAME = DB_NAME(); DECLARE @clientId UNIQUEIDENTIFIER = '<CLIENT_ID>'; -- Create User -- Grant db_datareader -- Grant db_datawriter -- Grant CONTROL permissions The UAMI must be created and granted permissions on every database participating in synchronization. Phase 2: Create the Sync Group After permissions are configured, create the Sync Group using UAMI authentication. Example PowerShell: New-AzSqlSyncGroup ` -ResourceGroupName $resourceGroup ` -ServerName $serverName ` -DatabaseName $hubDatabase ` -Name $syncGroup ` -HubDatabaseAuthenticationType UserAssigned ` -ResourceId $identityResourceId Key Parameters Parameter Description HubDatabaseAuthenticationType Authentication method for Hub Database UserAssigned Enables UAMI authentication ResourceId Full ARM Resource ID of the UAMI Phase 3: Add Sync Members Once the Sync Group is created, add member databases and specify UAMI authentication. Example: New-AzSqlSyncMember ` -ResourceGroupName $resourceGroup ` -ServerName $serverName ` -DatabaseName $hubDatabase ` -SyncGroupName $syncGroup ` -Name $memberName ` -MemberDatabaseAuthenticationType UserAssigned ` -ResourceId $identityResourceId At this stage, both Hub and Member databases are configured to authenticate using the managed identity. Phase 4: Configure Synchronization Refresh Hub Schema Refresh the schema metadata before selecting tables for synchronization. Update-AzSqlSyncSchema ` -ResourceGroupName $resourceGroup ` -ServerName $serverName ` -DatabaseName $hubDatabase ` -SyncGroupName $syncGroup Configure the Synchronization Schema Data Sync requires an explicit schema definition specifying which tables and columns will participate in synchronization. Example schema: { "Tables": [ { "QuotedName": "[dbo].[contacts]", "Columns": [ { "QuotedName": "[id]" }, { "QuotedName": "[name]" } ] } ] } Apply the schema: Update-AzSqlSyncGroup ` -ResourceGroupName $resourceGroup ` -ServerName $serverName ` -DatabaseName $hubDatabase ` -Name $syncGroup ` -HubDatabaseAuthenticationType UserAssigned ` -ResourceId $identityResourceId ` -SchemaFile "C:\schema.json" Trigger Synchronization After configuration is complete, trigger the initial synchronization. Start-AzSqlSyncGroupSync ` -ResourceGroupName $resourceGroup ` -ServerName $serverName ` -DatabaseName $hubDatabase ` -SyncGroupName $syncGroup Phase 5: Rotating UAMIs Over time, organizations may need to replace an existing managed identity. UAMI_v1 → UAMI_v2 Only one UAMI can be assigned to a Sync Group or Sync Member at a time. To rotate identities: Grant required database permissions to the new UAMI. Remove the current UAMI. Assign the new UAMI in the same operation. Update Sync Group Update-AzSqlSyncGroup ` -HubDatabaseAuthenticationType UserAssigned ` -ResourceId $newUamiResourceId ` -RemoveIdentityResourceId $oldUamiResourceId Update Sync Member Update-AzSqlSyncMember ` -MemberDatabaseAuthenticationType UserAssigned ` -ResourceId $newUamiResourceId ` -RemoveIdentityResourceId $oldUamiResourceId Common Pitfalls During implementation, the following issues are commonly encountered: Pitfall #1: Missing Entra Administrator If the SQL Server does not have an Entra administrator configured, UAMI authentication will fail. Pitfall #2: Missing Database Permissions The managed identity must be created and granted permissions in every participating database. Pitfall #3: Multiple UAMIs Assigned Azure SQL Data Sync supports only one UAMI per Sync Group or Sync Member at a time. Pitfall #4: Identity Included During PATCH Updates When updating schemas through REST APIs, avoid re-submitting the identity block if the managed identity is already assigned. This may result in a DataSyncMultipleIdentities error. Validation Checklist Before moving to production, verify the following: Microsoft Entra administrator configured UAMI created successfully UAMI user created in all Hub and Member databases Required permissions granted Sync Group configured with UserAssigned authentication Sync Members configured with UserAssigned authentication Schema refreshed successfully Synchronization schema applied Initial synchronization completed successfully Data synchronized correctly between Hub and Member databases Best Practices For secure and scalable deployments: Prefer UAMI over SQL Authentication for new deployments. Use dedicated managed identities for Data Sync workloads. Follow least-privilege access principles where possible. Test configuration changes in non-production environments first. Maintain documentation for identity ownership and rotation procedures. Monitor synchronization health after identity updates. Standardize naming conventions for managed identities. References The following Microsoft resources provide additional details for implementing Azure SQL Data Sync with User-Assigned Managed Identities: 1. Configure Microsoft Entra Authentication for Azure SQL Database Configure an Entra administrator for Azure SQL Database, which is a prerequisite for UAMI-based authentication. https://learn.microsoft.com/azure/azure-sql/database/authentication-aad-configure 2. Manage User-Assigned Managed Identities Learn how to create and manage User-Assigned Managed Identities in Azure. Managed identities eliminate the need to manage credentials in code and can be reused across multiple Azure resources. Manage user-assigned managed identities using the Azure portal explains the process and prerequisites. [Manage use...soft Learn | Learn.Microsoft.com] 3. Connect to Azure SQL Using Microsoft Entra Authentication Configure and validate Entra-based connectivity for Azure SQL Database before granting permissions to the managed identity. https://learn.microsoft.com/azure/azure-sql/database/authentication-microsoft-entra-connect-to-azure-sql 4. Azure SQL Data Sync PowerShell Documentation Review PowerShell cmdlets used to create Sync Groups, Sync Members, refresh schemas, and trigger synchronization. 5. Azure SQL REST API Documentation Use REST APIs for automation and Infrastructure-as-Code deployment scenarios involving Azure SQL Data Sync. Conclusion User-Assigned Managed Identity support represents a significant security enhancement for Azure SQL Data Sync. By eliminating dependency on stored credentials and leveraging Microsoft Entra authentication, organizations can improve security, simplify operations, and reduce administrative overhead. Whether you're building a new synchronization topology or migrating from SQL Authentication, UAMI provides a modern, scalable, and cloud-native authentication model for Azure SQL Data Sync. As cloud environments continue to adopt identity-first security practices, implementing UAMI for Azure SQL Data Sync is an important step toward a more secure and manageable data platform.Understanding Microsoft Entra ID Group Membership Caching and Azure SQL Authentication Timing
Contributor: hudajazmawi Executive Summary Organizations frequently use Microsoft Entra ID groups to manage access to Azure SQL databases. This approach simplifies administration, improves security, and supports just-in-time access models. In some scenarios, users may experience temporary authentication failures shortly after being granted access through a Microsoft Entra ID group. These failures can appear inconsistent, especially when access succeeds to one database while failing against another. Understanding how group membership caching works during authentication can help explain this behavior and reduce unnecessary troubleshooting efforts. This article explains a real-world scenario involving temporary authentication failures after group assignment, describes the underlying authentication behavior, and provides practical recommendations for validation and mitigation. Issue Description A user was granted access to Azure SQL through membership in a Microsoft Entra ID group. Shortly afterward, the user attempted to connect using Microsoft Entra authentication. The observed behavior was: Authentication to certain databases succeeded immediately. Authentication to other databases failed temporarily. The issue appeared shortly after the group membership was granted. Access eventually began working without any configuration changes. The behavior resolved after a period of time without additional intervention. At first glance, the results appeared inconsistent because some connection attempts were successful while others failed, even though the same user credentials and group assignments were being used. Technical Background Azure SQL supports Microsoft Entra authentication, allowing access to be granted through users, groups, and service principals managed within Microsoft Entra ID. When a user authenticates, Azure SQL must determine the user's effective permissions. For users who belong to many Microsoft Entra groups, membership information may be cached to improve authentication efficiency and reduce repeated directory lookups. Caching is a common design pattern used throughout distributed systems to improve performance, scalability, and reliability. However, because caches contain information retrieved at a specific point in time, there can be a temporary delay before recently changed security information becomes visible to all authentication requests. This behavior is particularly important to understand when organizations use: Just-in-time access workflows Privileged access management processes Temporary group assignments Automated access provisioning Frequent permission validation testing Root Cause The investigation determined that the authentication failures were caused by Microsoft Entra ID group membership caching. A login attempt occurred before the user was added to the required Microsoft Entra ID group. During that earlier authentication attempt, the user's group memberships were retrieved and cached. After the user was added to the required group, subsequent authentication attempts continued using the previously cached membership information until the cache expired. As a result, authentication requests temporarily evaluated permissions using outdated group membership data. Because the newly assigned group membership had not yet been reflected in the cached information, authentication failed even though access had already been granted. Once the cached membership information expired and fresh group membership data was retrieved, authentication succeeded without any additional configuration changes. Detailed Explanation To understand the behavior, consider the following simplified sequence: Step 1: Initial Authentication A user attempts to connect to Azure SQL before being added to the required Microsoft Entra ID group. During this process: The user's current group memberships are evaluated. Membership information is cached. The required access group is not yet present. Authentication behavior reflects the permissions available at that moment. Step 2: Group Membership Change The user is added to the appropriate Microsoft Entra ID group. From an administrative perspective, the access assignment has been completed successfully. However, any previously cached authentication information may still reflect the user's earlier membership state. Step 3: Immediate Retesting The user immediately attempts another connection. Although the directory now contains the new group membership, the authentication process may still reference cached membership information created before the change occurred. The result can be a temporary authentication failure. Step 4: Cache Expiration After the cached data expires or is refreshed, authentication retrieves updated membership information. The newly assigned group is now visible during authorization evaluation. At this point, authentication succeeds as expected. Why Some Databases May Behave Differently One of the most confusing aspects of these scenarios is that different databases may appear to behave differently even when they use identical group assignment models. This typically occurs because authentication state and cache usage can differ depending on the sequence and timing of connection attempts. For example: Database A may be accessed for the first time after the group assignment occurs. Database B may have received a connection attempt before the group assignment occurred. As a result: Database A may evaluate fresh membership information and allow access. Database B may continue referencing previously cached membership information until the cache expires. This can create the appearance of inconsistent behavior even though the system is operating as designed. Mitigation and Recommendations The following practices can help reduce the likelihood of encountering similar authentication timing scenarios. 1. Assign Access Before Testing Whenever possible, add users to the required Microsoft Entra ID groups before any authentication attempts are made against Azure SQL resources. This helps ensure that fresh membership information is used during the first authentication request. 2. Avoid Immediate Validation After Permission Changes If a user has recently been granted group-based access, consider allowing time for authentication cache refresh behavior before conducting validation testing. Immediate testing can sometimes produce results based on older membership information. 3. Plan for Temporary Authentication Delays Organizations implementing just-in-time access should account for the possibility of short propagation and cache refresh intervals when designing operational procedures. 4. Use DBCC FLUSHAUTHCACHE When Appropriate For controlled testing and validation scenarios, administrators may use: DBCC FLUSHAUTHCACHE; DBCC FLUSHAUTHCACHE; This command can help refresh authentication cache behavior during troubleshooting and validation activities. As with any administrative operation, testing should be performed according to organizational change-management procedures. 5. Capture Precise Timing Information When investigating authentication behavior, collecting exact timestamps is extremely valuable. Recommended data points include: Time the user was added to the Microsoft Entra ID group Time of each authentication attempt Database target of each connection attempt Time any cache refresh operation was performed Time authentication eventually succeeded Accurate timestamps help establish a clear correlation between group membership changes and authentication behavior. Validation Guidance If you need to verify whether group membership caching is influencing authentication results, consider the following approach: Record the exact time a user is added to the required Microsoft Entra ID group. Record the time of every authentication attempt. Identify whether any login attempts occurred before the group membership change. Observe whether successful authentication occurs after a period of time without configuration changes. Where appropriate, perform controlled tests using authentication cache refresh procedures. Compare authentication outcomes against the timeline of group membership updates. This structured approach often helps determine whether the observed behavior is related to authentication caching rather than a permission configuration issue. Key Takeaways Temporary authentication failures immediately after group-based access assignment do not necessarily indicate a configuration problem. Authentication behavior may be influenced by previously cached Microsoft Entra ID group membership information. Login attempts that occur before a group membership change can affect subsequent authentication behavior until cached data expires. Different databases may appear to behave differently if they are accessed at different points in the authentication timeline. Capturing precise timestamps significantly improves troubleshooting accuracy. Proper testing practices and awareness of cache behavior can reduce confusion and accelerate issue resolution. Closing Summary Microsoft Entra ID group-based authorization provides a powerful and scalable way to manage Azure SQL access. However, like many modern cloud authentication systems, caching is used to optimize performance and improve efficiency. When group memberships change immediately before authentication testing, temporary differences between cached and current membership information may lead to short-lived authentication failures. Understanding this behavior can help administrators accurately interpret results, design effective validation procedures, and avoid unnecessary troubleshooting. By assigning permissions before authentication attempts, allowing appropriate time for cache refresh behavior, and capturing precise timing information during investigations, organizations can more effectively manage Microsoft Entra-based access and streamline their operational workflows. As always, when troubleshooting authentication scenarios, focusing on the exact sequence and timing of events often provides the clearest path to identifying the underlying cause and validating a successful resolution. Further Reading To learn more about Microsoft Entra authentication and Azure SQL security, review the following Microsoft documentation: Microsoft Entra authentication for Azure SQL https://learn.microsoft.com/azure/azure-sql/database/authentication-aad-overview Explains how Microsoft Entra authentication works with Azure SQL and the benefits of group-based access management. DBCC FLUSHAUTHCACHE (Transact-SQL) https://learn.microsoft.com/sql/t-sql/database-console-commands/dbcc-flushauthcache-transact-sql Describes how to clear the database authentication cache and notes that it clears cached Microsoft Entra group membership data stored in the database.Understanding Azure SQL Data Sync Firewall Requirements
Why IP Whitelisting Is Required and What Customers Should Know Azure SQL Data Sync is commonly used to synchronize data between on‑premises SQL Server databases and Azure SQL Database. While the setup experience is generally straightforward, customers sometimes encounter connectivity or configuration issues that are rooted in network security and firewall behavior. This blog explains why Azure SQL Data Sync requires firewall exceptions, what type of IP addresses may appear in audit logs, and how to approach this topic from a security and documentation standpoint—based on real troubleshooting discussions within the Azure SQL Data Sync ecosystem. The Scenario: Sync Agent Configuration Fails Despite Valid Setup A frequently reported issue occurs when the Azure SQL Data Sync Agent (installed on an on‑premises server) fails to save its configuration. The error typically indicates that a valid agent key is required—even when: The agent key was freshly generated from the Azure SQL Data Sync portal Connection tests succeed The agent has been reinstalled or the server restarted New sync groups were created Despite these efforts, synchronization does not proceed until a specific public IP address is allowed through the Azure SQL Database firewall. Why Firewall Rules Matter for Azure SQL Data Sync Azure SQL Database is protected by a server‑level firewall that blocks all inbound traffic by default. Any external client—including the Data Sync Agent—must be explicitly allowed to connect. In Azure SQL Data Sync: The Data Sync Agent runs on‑premises It connects outbound over TCP port 1433 It uses the public endpoint of the Azure SQL logical server The Azure SQL firewall must allow the public IP address used by the agent If this IP is not allowed, the agent cannot complete configuration or perform synchronization operations—even if authentication and permissions are otherwise correct. Identifying the Required IP Address In the referenced discussion, the required IP address was identified by reviewing Azure SQL audit logs, which revealed connection attempts being blocked at the firewall layer. Once this IP address was added to the Azure SQL server firewall rules, synchronization completed successfully. This highlights an important point: Audit logs can be a reliable way to identify which IP address must be whitelisted when Data Sync connectivity fails. Is This IP Address Owned by Microsoft? Can It Change? A natural follow‑up question is whether the observed IP address is Microsoft‑owned, and whether it can change. From the discussion: Azure SQL Data Sync relies on Microsoft‑managed service infrastructure Some outbound connectivity may originate from Azure service IP ranges Microsoft publishes official IP ranges and service tags for transparency However, documentation does not guarantee that a single static IP will always be used. Customers should therefore treat firewall configuration as a network security requirement, not a one‑time exception. Related Microsoft Resources While Azure SQL Data Sync documentation focuses on setup and troubleshooting, firewall requirements are often implicit rather than explicitly called out. The following Microsoft resources were referenced in the discussion to help customers understand Azure service IP ownership and ranges: Gateway IP addresses – Azure Synapse Analytics Download Azure IP Ranges and Service Tags – Public Cloud These resources can help security teams validate Microsoft‑owned IPs and plan firewall policies accordingly. Key Takeaways for Customers ✅ Azure SQL Data Sync requires firewall access to Azure SQL Database ✅ The public IP used by the Data Sync Agent must be explicitly allowed ✅ Audit logs are useful for identifying blocked IPs ✅ IP addresses may belong to Microsoft infrastructure and can change over time ✅ Firewall configuration is a security prerequisite, not an optional step Closing Thoughts Azure SQL Data Sync operates securely by design, leveraging Azure SQL Database firewall protections. While this can introduce configuration challenges, understanding the network flow and firewall requirements can significantly reduce setup friction and troubleshooting time. If you're implementing Azure SQL Data Sync in a locked‑down network environment, we recommend involving your network and security teams early and validating firewall rules as part of the initial deployment checklist.
