Azure-docs: is an adgroup actually required for managed identity?

[drdamour]

im not an ad admin, creating groups is a whole biz process for us. Can i grant roles to the identity directly?

---

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

• ID: 31b0d33c-f88e-d50c-2926-7933940f3b92
• Version Independent ID: 4aaef906-f501-6947-5d23-1b704470f09d
• Content: Secure SQL Database connection with managed identity - Azure App Service
• Content Source: articles/app-service/app-service-web-tutorial-connect-msi.md
• Service: app-service-web
• GitHub Login: @cephalin
• Microsoft Alias: cephalin

[SnehaAgrawal-MSFT]

@drdamour Thanks for the feedback! We are currently investigating and will update you shortly.

[SnehaAgrawal-MSFT]

Thanks again for asking Question! As mentioned in the doc to grant this identity access to our SQL Database, we need to add it to an Azure AD group.
Also, for granting permissions Azure AD user's credentials is required.
You may refer to below doc: https://docs.microsoft.com/en-us/azure/role-based-access-control/rbac-and-directory-admin-roles#azure-ad-administrator-roles

[drdamour]

I think u need to re-evaluate the question as https://docs.microsoft.com/en-us/azure/active-directory/managed-identities-azure-resources/tutorial-windows-vm-access-sql#create-a-contained-user-in-the-database-that-represents-the-vms-system-assigned-identity shows you can grant access to a user without adding them to an ad group. This article should be updated to explain the group is not nescessary.

And add clear instructions on what the app services managed identity name is

[SnehaAgrawal-MSFT]

@drdamour Thanks for bringing this to our attention. I have shared your feedback with the content owner for further review.

[cephalin]

@drdamour Actually this article used to be written the way you mentioned, without adding the identity to the AD group. However it doesn't work with Visual Studio development where best practice says we should do database migrations from local machine instead of automate in the cloud. The local database migrations necessitates a second AD account to access the SQL Database, which is impossible if you configure the managed identity in SQL Database directly. This tutorial is meant to show one complete scenario, not all the things you can and can't do with the identity.

please-close

[drdamour]

@cephalon shouldn’t the article indicate the reason for the group necessity as you have outlined here?

[cephalin]

@drdamour I think for simplicity for now we will forgo that description in order to keep the tutorial streamlined. I understand we're talking about the tricky balance of educating the customer without information overload, but thank you for the feedback. We will consider that.

[drdamour]

Ok, it confused a bunch of my colleagues too. Thanks.

[ImrePyhvel]

@cephalin I'm all for simplicity, but tutorials should walk through the simplest path. Writing extra loops are misleading as they can be taken as requirements. As can be seen, they have been and still are. If something extra is done as "best practice" then it would suffice to include those 2 words by the instructions.

[patrickjlee]

This tutorial is confusing as hell. I've spent hours on this without being able to get the app to connect to the Sql Azure database so far. I think it needs a major rewrite

[patrickjlee]

The tutorial is also buggy. For example, in the "Grant permissions to managed identity" section, the variable names need to be prefixed by $, otherwise Azure CLI gives an error, so it should be $groupid not groupid, and $msiobjectid not msiobjectid.

[sopelt]

@patrickjlee have you seen https://github.com/MicrosoftDocs/azure-docs/issues/43368 ? This cost us hours too...

As for $msiobjectid vs msiobjectid: This sounds like you are running snippets that are written for Azure CLI + bash in a powershell environment.

[sarah026]

To those suggesting direct user assignment:
Using AD group should remain in this article because it is the best practice when managing identities and deleting functions. Who wants to be login in to the database everytime a developer deletes a functions? Who needs the maintenance overhead? And since when did developers communicate these things to everyone anyway! You'll end up with really messy access model in the SQL server.

[drdamour]

@sarah026 managed identities have a different lifecycle and purpose then common users. The group doesnt make sense in their case.