Windows Authentication for Azure AD principals for SQL Managed Instance is now Generally Available

GarryBargsley Were you able to fix this error?

Login failed for user '<token-identified principal>'. (Microsoft SQL Server, Error: 18456)

 We are having the same issue. Please share the details if it was fixed.

NikoNeugebauer sravani-saluru 

luistorres, that patch seems designed to resolve authentication errors; I am not nearly that far into the process. I can't figure out how to grant a local service account permission to delegate kerberos tickets to the Azure service principal. It's not that it doesn't work, it's that the Azure SP doesn't exist in my local AD.

GarryBargsleyI didn't encounter that specific error, but I'd guess that your Windows login is failing to match against a login in SQL Server.  Assuming that you're trying to connect as a member of the Azure AD admin group/user, I'd try removing and re-adding the admin group/user from your Managed Instance.

Likely that's the issue:

Based on a Microsoft communication: After installing updates released on November 8, 2022, or later on Windows Servers with the domain controller (DC) role, user, computer, service, or gMSA accounts, you might have issues with Kerberos authentication in your environment. 
Here security update package released today:
https://learn.microsoft.com/en-us/windows/release-health/windows-message-center#2961

Wyatt_Best do you have any guidance on how you got Windows Auth to work?  We followed the directions but not getting it to work and very frustrated.

MS Support has been no help either.

We have successfully set up Windows Authentication with Azure SQL Managed Instance. Users are able to connect with SSMS or applications that use Windows auth.

I'm now struggling to set up Kerberos delegation (double hop) for a linked server scenario. I want to link an on-prem SQL Server to Azure SQL MI. I know how to set up the Kerberos delegation in our local AD environment, but I can't figure out how to delegate to anything in Azure. There are no database.windows.net objects available in Active Directory Users and Computers.

Any suggestions?

What are the troubleshooting steps for getting this working?  I have worked with my Infrastructure team to perform the Incoming trust steps.  However, when I try to login to MI from SSMS I get the following:

TITLE: Connect to Server
------------------------------

Cannot connect to .database.windows.net.

------------------------------
ADDITIONAL INFORMATION:

Login failed for user '<token-identified principal>'. (Microsoft SQL Server, Error: 18456)

For help, click: https://docs.microsoft.com/sql/relational-databases/errors-events/mssqlserver-18456-database-engine-error

------------------------------
BUTTONS:

OK
------------------------------

I ran the klist command and show the following:

#4>     Client: admin
        Server: krbtgt/KERBEROS.MICROSOFTONLINE.COM @ T.COM
        KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
        Ticket Flags 0x40a10000 -> forwardable renewable pre_authent name_canonicalize
        Start Time: 10/27/2022 16:58:07 (local)
        End Time:   10/28/2022 2:58:07 (local)
        Renew Time: 11/3/2022 14:14:33 (local)
        Session Key Type: AES-256-CTS-HMAC-SHA1-96
        Cache Flags: 0x200 -> DISABLE-TGT-DELEGATION
        Kdc Called: 01.t.com

#5>     Client: admin
        Server: MSSQLSvc/a.database.windows.net:1433 @ KERBEROS.MICROSOFTONLINE.COM
        KerbTicket Encryption Type: Unknown (-1)
        Ticket Flags 0x40200000 -> forwardable pre_authent
        Start Time: 10/27/2022 16:55:56 (local)
        End Time:   10/27/2022 17:55:56 (local)
        Renew Time: 0
        Session Key Type: AES-256-CTS-HMAC-SHA1-96
        Cache Flags: 0x200 -> DISABLE-TGT-DELEGATION
        Kdc Called:

I am not sure if KDC is being blocked by firewalls or not.

NikoNeugebauer 

I wonder the benefit of doing this since in terms of security this might cause some new vulnerabilities if the windows credentials does not follow the principal of least access privileges.