Summary
This post walks through a real-world troubleshooting scenario involving Microsoft Entra ID Managed Identity authentication failures to Azure SQL Database.
The issue appeared intermittently across multiple Azure services and was ultimately traced to an edge case affecting Entra ID groups created as SQL logins, a feature that is currently in public preview.
We’ll cover:
- What the issue looked like
- How it was investigated
- The root cause identified with Product Group involvement
- Key learnings and recommended best practices
Scenario Overview
An application environment was configured to use Microsoft Entra ID Managed Identity authentication to connect to Azure SQL Database.
- The authentication model was changed from SQL authentication to Managed Identity several months earlier.
- Multiple Azure compute services (for example, App Service and Container-based workloads) were configured to authenticate using system-assigned or user-assigned managed identities.
- These managed identities were added to Microsoft Entra ID groups, and those groups were created as logins in Azure SQL Database.
For a period of time, everything worked as expected.
Symptoms Observed
At different points in time, authentication failures began to appear:
- One application started failing authentication suddenly, despite no recent configuration changes.
- Another application experienced similar failures weeks later.
- The failures were consistent and reproducible from the application side.
- Reverting temporarily back to SQL authentication immediately restored connectivity.
Timeline Evidence
A review of Azure SQL Database audit logs showed a very narrow failure window:
- ✅ Last successful login: shortly before the failures began
- ❌ First failed login: within minutes of the last success
No permission changes, role modifications, or security configuration updates were found during that time window.
Investigation Findings
After ruling out common causes such as:
- Permission removal
- Token expiration issues
- Application-side configuration changes
- Network or firewall changes
The case was checked internally against similar escalated incidents.
Key Finding
A known issue was identified and confirmed by the Azure SQL Product Group:
In certain edge cases, when Microsoft Entra ID groups are created as SQL logins, the login cache can become corrupted, causing authentication attempts to fail unexpectedly.
Important characteristics of this issue:
- It does not require a configuration change to trigger
- It can appear suddenly after a long period of stability
- It affects group-based logins rather than individual users
- Restarting the database clears the cache and restores functionality
The Product Group is actively working on a fix.
Important Note on Feature Status
Creating Microsoft Entra ID users or groups as SQL logins is currently in public preview.
Because of this:
- It is not recommended for production workloads
- Behavioral edge cases are still being addressed
- Platform-level fixes may be required to fully stabilize the experience
You can find the official documentation here:
https://learn.microsoft.com/en-us/sql/t-sql/statements/create-login-transact-sql?view=azuresqldb-current&preserve-view=true#arguments-1
Recommended Best Practice: Use Contained Database Users
To avoid this class of issues and align with Azure SQL Database’s security model, the recommended approach is to use contained database users instead of server-level logins.
Why Contained Database Users?
1. Database Portability
Authentication is handled entirely at the database level, not in the master database.
This means:
- Users and permissions move with the database
- No need to recreate logins during restores, migrations, or failovers
- Ideal for geo-replication, DR, and cross-environment moves
2. Improved Resiliency and Reduced Dependency
Traditional logins require access to the master database during authentication.
Contained users:
- Authenticate directly against the user database
- Reduce connection dependencies
- Improve reliability during failovers and maintenance events
3. Alignment with Azure SQL Security Model
Azure SQL Database is designed around database-scoped security.
Contained users:
- Avoid server-level constructs that are limited in Azure SQL
- Fit naturally with least-privilege and modern identity designs
4. No Orphaned Users During Restore or Migration
With traditional logins, orphaned users are a common issue.
Contained users:
- Store authentication metadata inside the database
- Remain consistent across restores and migrations
- Eliminate orphaned-user remediation steps
How to Create a Contained Entra ID User or Group
Below is the syntax to create a database-contained Microsoft Entra ID user, group, or managed identity:
CREATE USER [<Entra ID user or group name>] FROM EXTERNAL PROVIDER;
GO
After creation, assign only the permissions required by the workload, following least-privilege principles.
Key Takeaways
- Managed Identity authentication issues can occur even without configuration changes
- Entra ID group-based SQL logins are still in preview and may exhibit edge-case behavior
- Cache-related authentication failures can be resolved temporarily by restarting the database
- Contained database users are the recommended, production-ready approach
- Aligning with database-scoped security improves portability, resiliency, and operational stability
Final Thoughts
As Azure SQL Database continues to evolve, identity integration with Microsoft Entra ID is becoming more powerful—but also more nuanced.
For production workloads today, contained database users remain the safest and most resilient choice when integrating with managed identities.
If you’re designing or modernizing your authentication strategy, reviewing your use of preview features and aligning with supported best practices can help avoid unexpected outages.
Microsoft