So far, exactly one person has permissions in the Kladde's subscription: you, as Owner, that is, with all of them. In operations that is too little and too much at the same time. Too little, because a second person has to be able to look when something is stuck. Too much, because nobody needs all the permissions for everyday work. In this lesson you learn how Azure assigns permissions, create a group with read access for the Kladde and prove who may do what.
The tenant and its accounts
Permissions in Azure hang on accounts from Microsoft Entra ID. With your Azure subscription you got a tenant, a directory
with a default domain of the form <name>.onmicrosoft.com. In it there are four kinds of accounts that can receive permissions:
- Users: accounts of people. Most belong to the tenant (members).
- External users (guests): accounts from another tenant or personal Microsoft accounts that you have invited, such as a consultant for a review. They sign in with their own account and get permissions in your tenant without you managing a password for them.
- Groups: collections of accounts. Assigning permissions to a group means: whoever is a member has them. For permissions in Azure you use security groups.
- Service principals and managed identities: accounts for programs instead of people. In module 3.3, the Kladde gets a managed identity with which it accesses the database without a password.
You'll need your tenant's default domain right away for the test users. Microsoft Graph, the interface behind Entra ID, tells it
to you; az rest can talk to Graph too:
az rest --method get --url "https://graph.microsoft.com/v1.0/domains" --query "value[?isDefault].id" --output tsv
kladdepractice.onmicrosoft.com
kladdepractice is a made-up name; for you, your tenant's name appears there. In the Microsoft Entra admin center, the same domain
is on the overview page under “Primary domain”.