Basics of resource management in Azure Active Directory - Microsoft Enter (2023)

It's important to understand the specific structure and terminology of Azure resources. The following image shows an example of the four scope levels provided by Azure:

Terminology

Below are some of the terms you should be familiar with:

Resource- A manageable item available through Azure. Virtual machines, storage accounts, web applications, databases, and virtual networks are examples of resources.

resource group- A container that contains related resources for an Azure solution, e.g. For example, a collection of virtual machines, associated virtual networks, and load balancers to be managed by specific computers. Heresource groupcontains the resources that you want to manage as a group. You decide which resources belong to a resource group based on what makes the most sense for your organization. Resource groups can also be used to support lifecycle management by deleting all resources with the same lifetime at once. This approach also offers security advantages as there are no fragments left that can be exploited.

Subscription- From the perspective of the organizational hierarchy, a subscription is a management and billing container for resources and resource groups. An Azure subscription has a trust relationship with Azure AD. A subscription trusts Azure AD to authenticate users, services, and devices.

management group-Azure admin groupsprovide a hierarchical way to apply policy and compliance in different areas through subscriptions. You can be in the root tenant management group (highest scope) or lower in the hierarchy. You organize your subscriptions into containers called "management groups" and apply your governance terms to the management groups. All subscriptions within a management group automatically inherit the conditions applied to the management group. Note that policy definitions can be applied to a management group or subscription.

resource provider- A service that provides Azure resources. For example a commonresource providerit is Microsoft Compute that provides the virtual machine resource. Microsoft. Storage is another common resource provider.

Resource Manager Template- A JavaScript Object Notation (JSON) file that defines one or more resources to be deployed to a resource group, subscription, tenant, or management group. The template can be used to provision the resources consistently and repeatedly. SeeTemplate Deployment Overview. Besides thetongue of bicepscan be used instead of JSON.

Azure resource management model

Each Azure subscription is associated with controls used byAzure Resource Admin(POOR). Resource Manager is the provisioning and management service for Azure, has a trust relationship with Azure AD for identity management for organizations and Microsoft accounts (MSA) for individuals. Resource Manager provides a management layer that allows you to create, update, and delete resources in your Azure subscription. Use management features like access control, lockouts, and tags to secure and organize your resources after deployment.

Azure Resource Manager is the front-end service that hosts REST APIs used by PowerShell, the Azure portal, or other clients to manage resources. When a client makes a request to manage a specific resource, the Resource Manager forwards the request to the resource provider to complete the request. For example, when a client makes a request to manage a virtual machine resource, Resource Manager forwards the request to Microsoft. IT resource provider. Resource Manager requires the customer to provide an identifier for both the subscription and the resource group to manage the virtual machine resource.

Before the resource manager can execute resource management requests, a number of controls are checked.

• valid user verification- The user requesting resource management must have an account in the Azure AD tenant associated with the managed resource subscription.

• user authorization check- Permissions are assigned to users.Role-Based Access Control (RBAC). An RBAC role specifies a set of permissions that a user can have on a specific resource. RBAC helps you manage who has access to Azure resources, what they can do with those resources, and what areas they have access to.

• Azure Policy Checker-Azure PoliciesSpecify the operations that are explicitly allowed or denied on a specific resource. For example, a policy may specify that users may (or may not) deploy only a certain type of virtual machine.

The following diagram summarizes the resource model just described.

blue lighthouse-blue lighthouseallows the management of resources between clients. Organizations can delegate roles at the subscription or resource group level to identities in another tenant.

Subscriptions that allowDelegated resource managementwith Azure Lighthouse it has attributes that specify tenant IDs that can manage subscriptions or resource groups, and a mapping between the built-in RBAC role in the resource tenant and the identities in the service provider tenant. At runtime, Azure Resource Manager uses these attributes to authorize tokens that originate from the service provider tenant.

It's worth noting that Azure Lighthouse itself is modeled as an Azure resource provider, which means aspects of delegation to a tenant can be controlled through Azure policies.

Microsoft 365 Lighthouse-Microsoft 365 Lighthouseis a management portal that helps managed service providers (MSPs) secure and manage devices, data, and users at scale for small and medium-sized businesses (SMBs) using Microsoft 365 Business Premium, Microsoft 365 E3, or Windows 365 Business.

Azure resource management with Azure AD

Now that you have a better understanding of the resource management model in Azure, let's briefly explore some of the capabilities of Azure AD that can provide identity and access management for Azure resources.

Bill

Billing is important to resource management because some billing roles can interact with or manage resources. Billing works differently depending on the type of contract you have with Microsoft.

Azure Enterprise Agreements

Azure Enterprise Agreement (Azure EA) customers are listed in the Azure EA portal at the end of their business agreement with Microsoft. Onboarding assigns an identity to a "root" company administrator billing role. The portal provides a hierarchy of management roles:

• Departments help you break costs down into logical groupings and allow you to set a budget or quota at the department level.

• Accounts are used to segment other departments. You can use accounts to manage subscriptions and access reports. The EA portal may authorize Microsoft accounts (MSAs) or Azure AD accounts (referred to as "work or school accounts" in the portal). Identities with the Account Owner role in the EA Portal can create Azure subscriptions.

Azure AD tenants and corporate billing

When an account owner creates an Azure subscription within an enterprise contract, the subscription's identity and access management is configured as follows:

• The Azure subscription is associated with the same Azure AD tenant as the account owner.

• The account owner who created the subscription is assigned the service administrator and account administrator roles. (The Azure EA portal assigns Azure Service Manager (ASM) or "classic" roles to manage subscriptions. For more information, seeAzure Resource Manager vs. classic deployment.)

An enterprise agreement can be configured to support multiple tenants by setting the authentication type to "Cross work or school accounts" in the Azure EA portal. With this in mind, organizations can set up multiple accounts for each tenant and multiple subscriptions for each account, as shown in the following diagram.

It's important to note that the default settings described above give the Azure EA account owner permissions to manage resources in any subscription they create. For subscriptions with production workloads, consider decoupling billing and resource management by changing the service administrator for the subscription immediately after creation.

To further disassociate the owner from the account and prevent the service administrator from regaining access to the subscription, the subscription can be a tenantchangeafter creation. If the account owner doesn't have a user object in the Azure AD tenant to which the subscription is moved, he can't reclaim the service owner role.

For more information, visitAzure roles, Azure AD roles, and classic subscription administrator roles.

Microsoft Customer Agreement

Registered customers with aMicrosoft Customer Agreement(MCA) have a different billing management system with their own roles.

Abilling accountto the Microsoft Customer Agreement contains one or morebilling profilesthat allow the management of invoices and means of payment. Each billing profile contains one or moreinvoice sectionsto organize the costs on the billing profile invoice.

In a Microsoft customer agreement, billing roles originate from a single Azure AD tenant. To deploy subscriptions across multiple tenants, the subscriptions must first be created and then modified in the same Azure AD tenant as the MCA. In the following diagram, subscriptions for the Enterprise IT staging environment were moved to the ContosoSandbox tenant after creation.

RBAC and role assignments in Azure

In the Azure AD basics section, you learned that Azure RBAC is the authorization system that provides granular access management to Azure resources and spans manybuilt-in functions. you can createcustom roles, and assign roles in different areas. Permissions are applied by assigning RBAC roles to objects that request access to Azure resources.

Azure AD roles are based on concepts such asRole-based access control in Azure. HeDifference Between These Two Role Based Access Control Systemsis that Azure RBAC uses Azure Resource Management to control access to Azure resources, such as virtual machines or storage, and Azure AD roles control access to Azure AD, Microsoft applications and services, such as Office 365.

Both Azure AD roles and Azure RBAC roles integrate with Azure AD Privileged Identity Management to enable just-in-time activation policies such as approval workflow and MFA.

ABAC and role assignments in Azure

Attribute-Based Access Control (ABAC)It is an authorization system that defines access based on attributes associated with security principals, resources, and the environment. ABAC allows you to grant a principal access to a resource based on attributes. Azure ABAC refers to the ABAC implementation for Azure.

Azure ABAC builds on Azure RBAC by adding attribute-based role assignment conditions in the context of specific actions. A role assignment condition is an additional check that you can optionally add to your role assignment to provide more granular access control. A condition filters the permissions granted as part of role definition and assignment. For example, you can add a condition that requires an object to have a specific label in order to read the object. You cannot explicitly deny access to specific resources using conditions.

conditional access

Azure ADconditional access(CA) can be used to manage access to Azure management endpoints. CA policies can be applied to the Microsoft Azure Management Cloud application to protect Azure resource management endpoints, such as: eg:

• Azure Resource Manager provider (services)

• API de Azure Resource Manager

• Azure-PowerShell

• CLI de Azure

• Azure-Portal

For example, an administrator can configure a Conditional Access policy that allows a user to sign in to the Azure portal only from approved locations and also requires multi-factor authentication (MFA) or a hybrid Azure AD domain device.

Azure Administered Identities

A common challenge when building cloud applications is managing credentials in your code to authenticate to cloud services. Keeping credentials secure is an important task. Ideally, credentials are never displayed on developer workstations and are not verified in source control.Administered identities for Azure resourcesDeploy Azure services with a self-managed identity in Azure AD. You can use the identity to authenticate to any service that supports Azure AD authentication without credentials in your code.

There are two types of managed identities:

• A system-assigned managed identity is activated directly on an Azure resource. When the resource is activated, Azure creates an identity for the resource in the associated subscription's trusted Azure AD tenant. After the identity is created, the credentials are provided to the resource. The lifecycle of a system-assigned identity is tied directly to the Azure resource. When the resource is deleted, Azure automatically cleans up the credentials and identity in Azure AD.

  (Video) Azure Active Directory | Azure Active Directory Tutorial | Azure Tutorial For Beginners |Simplilearn

• A user-assigned managed identity is created as a separate Azure resource. Azure creates an identity in the Azure AD tenant that trusts the subscription that the resource is associated with. Once the identity is created, the identity can be assigned to one or more Azure resources. The lifecycle of a user-assigned identity is managed separately from the lifecycle of the Azure resources to which it is assigned.

Internally, managed identities are a special type of service principals that only use specific Azure resources. When the managed identity is deleted, the corresponding service principal is automatically deleted. Note that Graph API permissions authorization can only be done through PowerShell, so not all Managed Identity features can be accessed through the portal UI.

Azure Active Directory Domain Services

Azure Active Directory Domain Services (Azure AD DS) provides a managed domain to facilitate authentication of Azure workloads with legacy protocols. Supported servers move from an on-premises AD DS forest and join an Azure AD DS managed domain and continue to use legacy protocols for authentication (such as Kerberos authentication).

Azure AD B2C and Azure directories

An Azure AD B2C tenant is linked to an Azure subscription for billing and communication purposes. Azure AD B2C tenants have a different role structure in the directory that is separate from the Azure subscription Azure RBAC privileged roles.

When the Azure AD B2C tenant is initially provisioned, the user who creates the B2C tenant must have Contributor or Owner permissions on the subscription. Once created, this user becomes the first global administrator of the Azure AD B2C tenant, and can then create other accounts and assign them directory roles.

It's important to note that owners and collaborators of the linked Azure AD subscription can remove the link between the subscription and the directory, which will affect ongoing billing for Azure AD B2C usage.

Identity considerations for IaaS solutions on Azure

This scenario addresses the identity isolation needs that organizations have for Infrastructure as a Service (IaaS) workloads.

There are three main options for managing IaaS workload isolation:

• Virtual machines connected to standalone Active Directory Domain Services (AD DS).

• Virtual machines connected to Azure Active Directory Domain Services (Azure AD DS).

• Sign in to virtual machines in Azure using Azure AD authentication

A key concept to address with the first two options is that there are two realms of identity involved in these scenarios.

• Typically, when you sign in to an Azure Windows Server VM by using Remote Desktop Protocol (RDP), you sign in to the server with your domain credentials, which performs Kerberos authentication to a local AD DS domain controller or Azure AD DS. Alternatively, if the server is not joined to a domain, a local account can be used to log in to the virtual machines.

• When you sign in to the Azure portal to create or manage a VM, it authenticates to Azure AD (possibly using the same credentials if you have the correct accounts synced) and this could result in authenticating your domain controllers, if you do so you must use Active Directory Federation Services (AD FS) or pass-through authentication.

Virtual machines connected to standalone Active Directory Domain Services

AD DS is the Windows Server-based directory service that organizations have largely adopted for on-premises identity services. AD DS can be deployed when you need to deploy IaaS workloads to Azure that require identity isolation of AD DS administrators and users in another forest.

In this scenario, the following considerations should be made:

AD DS domain controllers – At least two AD DS domain controllers should be deployed to ensure that authentication services are highly available and performant. For more information, seeAD DS Design and Planning.

AD DS Design and Planning- A new AD DS forest must be created with the following services correctly configured:

• AD DS Domain Name Services (DNS)- AD DS DNS must be configured for the relevant zones within AD DS to ensure that name resolution for servers and applications works correctly.

• AD DS sites and services- These services must be configured to ensure that applications have low latency and efficient access to domain controllers. The relevant virtual networks, subnets, and data center locations where the servers are located must be configured under Sites and Services.

• AD DS-FSMO- Required Flexible Single Master Operation (FSMO) roles should be reviewed and assigned to the appropriate AD DS domain controllers.

• AD DS domain join- All servers (except "jumpboxes") that require AD DS for authentication, configuration, and management must be connected to the isolated forest.

• AD DS Group Policy (GPO)- AD DS GPOs must be configured to ensure that settings meet security requirements and that settings are standardized across the forest and across domain-joined computers.

• AD DS organizational units (OUs).– AD DS organizational units should be defined to ensure that AD DS resources are grouped into logical configuration and management silos for the purpose of managing and applying configuration.

• Role-based access control- RBAC must be defined for the management and access to the resources associated with this forest. This contains:

  • The ADDS group- Groups must be created to apply the appropriate permissions for users to AD DS resources.

  • management account- As mentioned at the beginning of this section, two administrator accounts are required to manage this solution.

    • An AD DS administrator account with the least privileged access rights necessary to perform required administration on AD DS and domain-joined servers.

    • An Azure AD administrator account to access the Azure portal to connect, manage, and configure virtual machines, virtual networks, NSGs, and other required Azure resources.

  • AD DS user accounts- The relevant user accounts must be provisioned and added to the correct groups to allow user access to the applications hosted by this solution.

    (Video) Azure Active Directory - The Ultimate Beginners Guide

Virtual networks (VNet)- Configuration guide

• AD DS domain controller IP address- Domain controllers should not be configured with static IP addresses within the operating system. The IP addresses must be reserved in the Azure VNet to ensure they are always the same, and the DC must be configured to use DHCP.

• VNet-DNS-Servidor- DNS servers must be configured in virtual networks that are part of this isolated solution to point to domain controllers. This is necessary to ensure that applications and servers can resolve the necessary AD DS services or other services connected to the AD DS forest.

• Network Security Groups (NSGs)- Domain controllers must be in their own virtual network or subnet, with NSGs defined to only allow access to domain controllers from required servers (for example, domain-joined machines or hop boxes). Jumpboxes should be added to an Application Security Group (ASG) to simplify NSG creation and management.

challenges: The following list shows the main challenges when using this identity isolation option:

• An additional AD DS forest to manage, manage, and monitor, creating more work for the IT team.

• Additional infrastructure may be required to manage software deployments and patches. Organizations should consider implementing Azure Update Management, Group Policy (GPO), or System Center Configuration Manager (SCCM) to manage these servers.

• Additional credentials that users must remember and use to access resources.

Virtual machines joined to Azure Active Directory Domain Services

When you need to deploy IaaS workloads to Azure that require identity isolation of AD DS administrators and users in a different forest, a managed domain can be deployed from Azure AD Domain Services (Azure AD DS). Azure AD DS is a service that provides a managed domain to facilitate authentication of Azure workloads using legacy protocols. This provides an isolated domain without the technical complexity of creating and managing your own AD DS. The following considerations must be made.

Azure AD DS Administered Domain- Only one Azure AD DS managed domain can be deployed per Azure AD tenant and is bound to a single virtual network. It is recommended that this virtual network be the "hub" for Azure AD DS authentication. From this hub, "spokes" can be created and linked to enable legacy authentication for servers and applications. Spokes are additional virtual networks where Azure AD DS joined servers reside and are connected to the hub through Azure network gateways or virtual network peering.

User Forest vs. Resource Forest- Azure AD DS offers two options for configuring the Azure AD DS managed domain forest. For the purposes of this section, we will focus on the user forest because the resource forest is based on a configured trust relationship with an AD DS forest, and this violates the isolation principle discussed here.

• Benutzerwald- By default, an Azure AD DS managed domain is created as a user forest. This type of forest synchronizes all Azure AD objects, including user accounts synchronized from an on-premises AD DS environment.

• Ressourcenwald- Resource forests only sync users and groups created directly in Azure AD and require a trust relationship to be set up with an AD DS forest for user authentication. For more information, seeResource forest concepts and features for Azure Active Directory Domain Services.

Managed domain location- When deploying an Azure AD DS managed domain, a location must be specified. The location is a physical region (data center) where the managed domain is deployed. It is recommended that you:

• Consider a location that is geographically close to the servers and applications that require Azure AD DS services.

• Consider regions that provide availability zone capabilities for high availability requirements. For more information, seeRegions and availability zones in Azure.

object deployment- Azure AD DS synchronizes the identities of the Azure AD associated with the subscription in which Azure AD DS is deployed. It's also worth noting that the lifecycle of these identities can also be reflected in Azure AD DS if the associated Azure AD is configured to sync with Azure AD Connect (user forest scenario). This service has two modes that can be used to provision user and group objects from Azure AD.

• in- All users and groups are synced from Azure AD to Azure AD DS.

• reach- Only users in the scope of one or more groups are synced from Azure AD to Azure AD DS.

When you first deploy Azure AD DS, an automatic one-way synchronization is configured to replicate your Azure AD objects. This one-way synchronization continues to run in the background to keep the Azure AD DS managed domain up to date with any Azure AD changes. There is no synchronization of Azure AD DS with Azure AD. For more information, seeHow objects and credentials are synchronized in an Azure AD Domain Services managed domain.

Note that if you need to change the synchronization type from All to Scope (or vice versa), the Azure AD DS managed domain must be deleted, recreated, and reconfigured. Additionally, organizations should consider using a "scoped" implementation to reduce identities to only those who need access to Azure AD DS resources as a best practice.

Group Policy Objects (GPOs)- To configure GPOs in an Azure AD DS managed domain, you must use Group Policy management tools on a server joined to the Azure AD DS managed domain. For more information, seeManage group policies in a domain managed by Azure AD Domain Services.

Secure LDAP- Azure AD DS provides a secure LDAP service that can be used by applications that require it. This setting is disabled by default and a certificate must be uploaded to enable secure LDAP. Additionally, the NSG that protects the virtual network where Azure AD DS is deployed must allow port 636 connectivity to the Azure AD DS managed domains. For more information, seeConfigure secure LDAP for a domain managed by Azure Active Directory Domain Services.

Administration- To perform administration tasks in Azure AD DS (such as join computers to domains or edit GPOs), the account used for this task must be part of the Azure AD DC administrators group. Accounts that are members of this group cannot log on to domain controllers directly to perform administrative tasks. Instead, you create an Admin VM that joins your Azure AD DS managed domain, and then install your regular AD DS management tools. For more information, seeUser account, password, and administration management concepts in Azure Active Directory Domain Services.

password hashes- For authentication to work with Azure AD DS, the password hashes for all users must be in a format suitable for Kerberos and NT LAN Manager (NTLM) authentication. To ensure that authentication with Azure AD DS works as expected, the following prerequisites must be met.

• Users synchronized with Azure AD Connect (from AD DS)- Old password hashes need to be synced from on-premises AD DS to Azure AD.

• Users created in Azure AD- Your password must be reset to generate the correct hashes for use with Azure AD DS. For more information, seeEnable password hash synchronization.

  (Video) S02E29 - Beginners Guide to Accessing On-Premises Resources with Azure AD Joined Devices - (I.T)

red- Azure AD DS is deployed in an Azure virtual network, therefore considerations must be taken to ensure that servers and applications are protected and can successfully access the managed domain. For more information, seeVirtual network design considerations and configuration options for Azure AD Domain Services.

• Azure AD DS must be deployed on its own subnet - don't use an existing subnet or gateway subnet.

• A network security group (NSG)- Created during provisioning of an Azure AD DS managed domain. This network security group contains the rules necessary for correct communication of the service. Do not create or use an existing network security group with your own custom rules.

• Azure AD DS requires 3-5 IP addresses- Make sure the IP address range of your subnet can provide this number of addresses. Restricting the available IP addresses can prevent Azure AD DS from managing two domain controllers.

• VNet-DNS-Servidor- As mentioned with the "hub and spoke" model, it is important that DNS is configured correctly in virtual networks to ensure that servers joined to the Azure AD DS managed domain have the correct DNS settings to resolve the managed domain of Azure AD DS. Each virtual network has a DNS server record that is propagated to the servers when they receive an IP address, and these DNS records must be the IP addresses of the Azure AD DS managed domain. For more information, seeUpdate the DNS settings for the Azure virtual network.

challenges- The list below highlights the main challenges of using this option for identity isolation.

• Some Azure AD DS configurations can only be managed by an Azure AD DS joined server.

• Only one Azure AD DS managed domain can be provisioned per Azure AD tenant. As we describe in this section, the hub-and-spoke model is recommended to provide Azure AD DS authentication for services in other virtual networks.

• Additional infrastructure may be required to manage software deployments and patches. Organizations should consider implementing Azure Update Management, Group Policy (GPO), or System Center Configuration Manager (SCCM) to manage these servers.

This isolated model assumes there is no connectivity to the virtual network hosting the Azure AD DS managed domain from the customer's corporate network and no trust relationships configured with other forests. A jumpbox or management server must be created to allow a point from which to manage and administer Azure AD DS.

Sign in to virtual machines in Azure using Azure Active Directory authentication

When it comes to deploying IaaS workloads on Azure that require identity isolation, the final option in this scenario is to use Azure AD to sign in to the servers. This provides the ability to make Azure AD the identity domain for authentication purposes and identity isolation can be achieved by deploying the servers in the appropriate subscription linked to the required Azure AD tenant. The following considerations must be made.

Supported operating systems- Signing in to virtual machines in Azure using Azure AD authentication is currently supported on Windows and Linux. For more details on supported operating systems, see the documentation forVentanaYlinux.

credentials: One of the key benefits of signing in to virtual machines in Azure using Azure AD authentication is the ability to use the same federated or managed Azure AD credentials that you normally use to access Azure AD services to sign in to the virtual machine.

network requirements- These VMs need to access Azure AD for authentication, so make sure that the VMs' network settings allow outbound access to Azure AD endpoints at 443. See the documentation forVentanaYlinuxfor more information

Role-Based Access Control (RBAC): There are two RBAC roles available to provide the appropriate level of access for these virtual machines. These RBAC roles can be configured through the Azure portal or through the Azure Cloud Shell Experience. For more information, seeConfigure role assignments for the virtual machine.

• Virtual machine administrator login- Users assigned to this role can sign in to an Azure virtual machine with administrator privileges.

• Virtual machine user login- Users assigned to this role can sign in to an Azure virtual machine with regular user rights.

Conditional Access – A key benefit of using Azure AD to sign in to Azure VMs is the ability to apply Conditional Access as part of the sign-in process. This gives organizations the ability to enforce conditions before access to the virtual machine is granted and to use multi-factor authentication to provide strong authentication. For more information, seeUse conditional access.

challenges: The following list shows the main challenges when using this identity isolation option.

• No central administration or server configuration. For example, there is no group policy that can be applied to a group of servers. Organizations should consider implementingUpdate management in AzureManage patches and updates for these servers.

• Not suitable for multi-tier applications that require authentication using local mechanisms such as Integrated Windows Authentication through these servers or services. If this is a requirement for your organization, we recommend that you investigate the standalone Active Directory Domain Services or Azure Active Directory Domain Services scenarios described in this section.

This isolated model assumes that there is no connectivity to the virtual network that hosts the virtual machines on the customer's corporate network. A jumpbox or management server should be created to allow a point from which to manage and manage these servers.

Next steps

• Introduction to delegated administration and sandboxes

• Azure AD basics

  (Video) How to configure basic policies in Azure Active Directory B2C | Azure Active Directory

• Isolation of resources in a single tenant

• Multi-tenant resource isolation

• Recommended course of action