question

Azurebegginer avatar image
0 Votes"
Azurebegginer asked ·

Azure Portal /Azure AD - Giving access to virtual machines and network

Hello,

Hope you are well. We are moving a team of resouces (System admin, Network etc.) who are managing on-premise environment to managing azure environment.

Do I need to create their IDs in Azure AD first, than add these IDs to contributor role at resource group/resource level in Azure portal.

For example I have a resource group for virtual machines. So I create a Systemadmingroup (Assigned) in Azure AD and than create a user for system admin (Users1) and add it to Systemadmingroup group.

Than I add this group - Systemadmingroup to contribitor role for the resources group created for virtual machine.

Is this the right approach.

Please guide.

azure-active-directoryazure-virtual-machines
10 |1000 characters needed characters left characters exceeded

Up to 10 attachments (including images) can be used with a maximum of 3.0 MiB each and 30.0 MiB total.

StephaneBudo avatar image
2 Votes"
StephaneBudo answered ·

Hi,

Jai is correct in that you can create a sync between your on-premises Active Directory and Azure Active Directory using a tool called "AAD Connect". This tool will ensure that the users and groups you create and maintain on-premises are replicated to Azure.
More information here:
https://docs.microsoft.com/en-us/azure/active-directory/hybrid/whatis-azure-ad-connect

In regards to the management (and security) of each resources in Azure, there are a lot of different ways to structure this, but your approach is correct.
Each resource in Azure has to be part of a Resource Group, each Resource Group has to be part of a Subscription and each Subscription has to be part of a Azure Active Directory (or tenancy).
With that in mind, the security gets inherited down by default, so if you assign the contributor role to a user at the Subscription level, by default, this user will have contributor role to all the Resources Groups and Resources created in that Subscription. The same is true for each Resource Group, whereby if a user gets contributor access to a Resource Group, it will inherit contributor access to all the resources in the group, but NOT to any other Resource Group.
This principle goes down to each resources.

I would not recommend to assign permissions to a specific resource unless absolutely necessary as the management would quickly become a nightmare, so your approach to assign permissions at the Resource Group level is a good one. In the same way, it's also preferable to assign permissions to a User Group as opposed to individual users.
If you wanted to compare it to an on-premises technology (analogy), think of it like a file share, containing folders, containing files (where files are resources, folders are resource groups and file shares are subscriptions). You would rarely assign permissions to a specific file, but instead assign permissions to folders based on group of users and not individual user accounts.

This is known as RBAC (Role-Based Access Level). More information here:
https://docs.microsoft.com/en-us/azure/role-based-access-control/overview

Hope this helps, but let me know if you need any more clarification.

Cheers,

Stephane

·
10 |1000 characters needed characters left characters exceeded

Up to 10 attachments (including images) can be used with a maximum of 3.0 MiB each and 30.0 MiB total.

JaiVerma-7010 avatar image
1 Vote"
JaiVerma-7010 answered ·

I assume you are not syncing users and groups from on premises and wants to provision separate identity. In that situation, plan sounds good.

Alternatively, you can sync your users and groups to cloud and leverage on premise group. Your life will be easy and you will get leaver, mover joiner out of the box.

·
10 |1000 characters needed characters left characters exceeded

Up to 10 attachments (including images) can be used with a maximum of 3.0 MiB each and 30.0 MiB total.