Unable to add user [DOMAIN\user] to Azure SQL Managed Instance for Entra synced AD user.

Hi Monika,

Yes, there is one more important distinction here.

Getting the Kerberos ticket generated confirms that the Windows authentication flow is working at the authentication layer, but it does not automatically mean SQL Managed Instance can resolve or create a DOMAIN\User login using CREATE LOGIN ... FROM WINDOWS.

For Azure SQL Managed Instance, there are two common patterns:

1. Microsoft Entra metadata mode / default pattern

In this mode, you normally create the login as a Microsoft Entra principal, for example:

CREATE LOGIN [******@domain.com] FROM EXTERNAL PROVIDER;

or preferably a synced Entra security group:

CREATE LOGIN [MyEntraSqlAccessGroup] FROM EXTERNAL PROVIDER;

Then create users in the required database and grant permissions.

2. Windows authentication metadata mode

If you specifically want to create logins using this syntax:

CREATE LOGIN [DOMAIN\Username] FROM WINDOWS;

then the SQL Managed Instance must be configured to use the Windows authentication metadata mode. Otherwise SQL MI may not be able to resolve DOMAIN\Username, and you can get errors like:

Msg 15007
'DOMAIN\Username' is not a valid login or you do not have permission.

So I would check the following:

In the Azure portal, go to the SQL Managed Instance.

Check the Microsoft Entra ID / authentication metadata configuration.

If you want to use CREATE LOGIN ... FROM WINDOWS, make sure the authentication metadata mode is set appropriately for Windows principals.

Confirm that the user or group is synced from on-prem AD to Microsoft Entra ID.

Confirm that the SQL Managed Instance has its system-assigned managed identity enabled and that the required Microsoft Entra permissions/Directory Readers access are granted.

Run the CREATE LOGIN command in the master database.

Try creating access through an AD/Entra synced security group instead of an individual user, if possible.

For example, if using Windows metadata mode:

USE master;
GO

CREATE LOGIN [DOMAIN\SqlAppUsers] FROM WINDOWS;
GO

Then inside the application database:

USE YourDatabaseName;
GO

CREATE USER [DOMAIN\SqlAppUsers] FROM LOGIN [DOMAIN\SqlAppUsers];
GO

ALTER ROLE db_datareader ADD MEMBER [DOMAIN\SqlAppUsers];
-- Add only the required roles/permissions for the application

If the instance is still in the default Microsoft Entra metadata mode, then use the Entra principal syntax instead:

USE master;
GO

CREATE LOGIN [******@domain.com] FROM EXTERNAL PROVIDER;
GO

or:

CREATE LOGIN [YourSyncedEntraGroupName] FROM EXTERNAL PROVIDER;

In short, Kerberos ticket generation and SQL login creation are two separate parts of the setup. The error is likely because SQL MI is not currently configured to resolve DOMAIN\Username as a Windows principal, or because the required Entra/Directory permissions are not in place. If your legacy app truly requires Windows authentication with DOMAIN\User style principals, validate the authentication metadata mode first.

Hello Joshee, Monika,

Greetings!

Thanks for raising this question in Q&A forum.

The error Msg 15007 'DOMAIN\Username' is not a valid login or you do not have permission is happening because Azure SQL Managed Instance, when configured with Entra ID as the admin, does not directly resolve on-premises Windows logins using the classic CREATE LOGIN [DOMAIN\user] FROM WINDOWS syntax unless a specific Authentication Metadata Mode is enabled on the Managed Instance. Even though your Kerberos trust is configured and tickets are generating correctly, the SQL MI still cannot resolve the Windows principal metadata without this additional setting being turned on.

Here is what you need to do step by step:

The key missing piece is enabling the Windows Authentication Metadata Mode on your SQL Managed Instance. Go to the Azure Portal, navigate to your SQL Managed Instance resource, then go to Settings → Microsoft Entra ID, and look for the Authentication metadata mode dropdown. Select the Windows (New Mode) option and click Save authentication metadata configuration.

This mode allows users to use Windows authentication with Azure SQL Managed Instance when your environment is synchronized between Active Directory and Microsoft Entra ID — which is exactly your setup with Entra Connect Sync. Once enabled, the CREATE LOGIN [DOMAIN\Username] FROM WINDOWS syntax will work correctly for your synced AD users.

After enabling the mode, connect to your SQL Managed Instance using your admin account and re-run your login creation command:

CREATE LOGIN [DOMAIN\Username] FROM WINDOWS;

Make sure you are using the NetBIOS domain name (short domain name like CONTOSO) and not the FQDN (contoso.local) in the login syntax.

Also confirm that your SQL Managed Instance has a System-Assigned Managed Identity and a System-Assigned Service Principal enabled. Go to the Identity tab of your SQL MI resource in the Azure Portal and verify that the System-assigned managed identity and System-assigned service principal are both set to On. These are required for the MI to query Entra ID and resolve Windows principal metadata.

Also verify that a system-assigned service principal has been created for each SQL Managed Instance as part of the one-time infrastructure setup for Windows Authentication. If this step was skipped during the initial Kerberos setup, it can silently cause login creation to fail even when Kerberos tickets are working fine.

After creating the login successfully at the instance level, make sure to also create the corresponding database user within each database the legacy app needs to access:

USE [YourDatabase];
CREATE USER [DOMAIN\Username] FOR LOGIN [DOMAIN\Username];
ALTER ROLE db_datareader ADD MEMBER [DOMAIN\Username];

Finally, if the error persists after all the above steps, check the troubleshooting guide at https://learn.microsoft.com/en-us/azure/azure-sql/managed-instance/winauth-azuread-troubleshoot for common Kerberos error codes that may point to any remaining configuration gaps in your trust setup.

The Windows Authentication Metadata Mode is the most commonly missed step in this setup and is very likely the reason you're hitting this error despite having Kerberos working correctly.

If this answer helps you kindly accept the answer which will help others who have similar questions.

Best Regards,

Jerald Felix.