I'm looking to use a service principal as the server admin, so it can be used in a release pipeline to create further active directory users.
I'm successfully able to make the service principal the server admin* and connect to the database using an Access token, so the service principal authentication works fine, which is great nice and an interesting challenge.
*EDIT: The AAD server admin was creating via the ARM template, notably if you tried creating manually via the portal, you cannot select service principals as admin users. But interestingly you can see the service principal name ok in the portal after creation using ARM instead. And you can login successfully with AAD auth, so it appears a server principal admin works fine.
However when creating further users, they never seem to be found with the error:
"Principal 'name here' could not be found at this time. Please try again later."
However when logged in as myself I am able to create other users fine.
Which leads me to think is SQL Server using some sort of Active Directory impersonation to validate the subsequent users / service principals exist?
If I were to grant my service principal access to the Graph API would that give it enough permissions? If so what is the minimum rights necessary?
I also see that Azure SQL Server has created a managed service identity in the background, so I wonder if that's also at play?
Also I saw on managed instances that they explicitly require a service principal with AAD rights to hook into AAD - which I presume is like an Azure SQL Server's MSI? But Azure SQL Server doesn't mention this with an AAD admin being enough.
I'd love to know how the underlying mechanism for the active directory hookup works as it could help me investigate my challenges further.
