This post has been republished via RSS; it originally appeared at: New blog articles in Microsoft Community Hub.
Connecting from Windows Server (running on Azure On-Premises domain joined), to Managed Instance, while using Windows Authentication method, fails with below error message:
The steps we have been through, troubleshooting this issue, are as follows:
- we have created a Trusted Domain Object with SetupCloudTrust, then created GPO (Group Policy Object) setting to client machines using the incoming trust-based flow: https://learn.microsoft.com/en-us/azure/azure-sql/managed-instance/winauth-azuread-setup-incoming-trust-based-flow?view=azuresql
- checking klist, we were seeing the below: Error calling API LsaCallAuthenticationPackage:
- as per Configure Azure SQL Managed Instance for Windows Authentication for Azure Active Directory - Azure SQL Managed Instance | Microsoft Learn, we have tried to enable a system assigned service principal for the Managed Instance, but at this point, the option failed with "user attempted to use a feature which is disabled":
- the reason we were seeing "user attempted to use a feature which is disabled", is because the Managed Instance, was part of a Managed Instance Pool. So when you try to set system assigned service principal via Azure Portal, the portal will send a PATCH request which only contains properties which should be updated, so the InstancePoolName property, is not sent in the request body.
- this issue doesn't manifest with Azure CLI and Azure PowerShell, because both clients first fetch the instance (thus getting all of its properties), update the specified properties and then issue a PUT request which contains all of the Managed Instance's properties. Hence, we have been able to set up the system assigned service principal, via: az sql mi | Microsoft Learn
- as we were still unable to login to the Managed Instance, we reviewed carefully this article: How to set up Windows Authentication for Azure Active Directory with the incoming trust-based flow - Azure SQL Managed Instance | Microsoft Learn
- it seems that the issue was coming in from the space needed between kerberos and the /
This was able to fix our problem!
If you still encounter any issues on this topic, you can check the logs for more details: Enable Kerberos event logging - Windows Server | Microsoft Learn