Users may be required to authenticate to their applications (for example, Microsoft 365 apps, Teams (work or school), OneDrive, etc.) at every sign-in. The repeated authentication prompts are due to the virtual machines Azure AD device state. We recommend virtual machines are Azure AD Joined (AADJ) or Hybrid Azure AD Joined (HAADJ) for the best user experience.
Virtual machines, which are AADJ or HAADJ create the user’s primary refresh token (PRT) at sign-in. Primary refresh token(s) created at sign-in will be used to authenticate to Azure AD based applications. Standard Domain Joined (DJ) virtual machines don’t create a PRT at sign-in, instead rely on the Microsoft Azure AD broker plugin.
Azure AD broker directories and apps
Starting in FSLogix 2210 (2.9.8361.52326) and later versions, all content stored in following locations is no longer roamed as part of the user profile.
The following articles are provided to help determine whether or not your virtual machines are configured to use primary refresh tokens as part of an Azure AD sign-in process.
When using non-persistent VDI, you need to prevent users from adding work or school accounts. Use the below registry entry to prevent adding these virtual machines to your Azure AD directory. Failure to do so will result in your directory having lots of stale Hybrid Azure AD joined devices that were registered from your non-persistent VDI platform resulting in increased pressure on your tenant quota and risk of service interruption because of running out of tenant quota.
When it comes to identity and access, most organizations that are considering using the public cloud are concerned about two things:
Ensuring that when people leave the organization, they lose access to resources in the cloud.
Striking the right balance between autonomy and central governance – for example, giving project teams the ability to create and manage virtual machines in the cloud while centrally controlling the networks those VMs use to communicate with other resources.
Azure Active Directory (Azure AD) and Role-Based Access Control (RBAC) work together to make it simple to carry out these goals.
Azure subscriptions
First, remember that each Azure subscription is associated with a single Azure AD directory. Users, groups, and applications in that directory can manage resources in the Azure subscription. The subscriptions use Azure AD for single sign-on (SSO) and access management. You can extend your on-premises Active Directory to the cloud by using Azure AD Connect. This feature allows your employees to manage their Azure subscriptions by using their existing work identities. When you disable an on-premises Active Directory account, it automatically loses access to all Azure subscriptions connected with Azure AD.
What is RBAC?
Role-based access control (RBAC) is an authorization system built on Azure Resource Manager that provides fine-grained access management of resources in Azure. With RBAC, you can grant the exact access that users need to do their jobs. For example, you can use RBAC to let one employee manage virtual machines in a subscription while another manages SQL databases within the same subscription.
What is role-based access control?
You grant access by assigning the appropriate RBAC role to users, groups, and applications at a certain scope. The scope of a role assignment can be a subscription, a resource group, or a single resource. A role assigned at a parent scope also grants access to the child scopes contained within it. For example, a user with access to a resource group can manage all the resources it contains, like websites, virtual machines, and subnets. The RBAC role that you assign dictates what resources the user, group, or application can manage within that scope.
The following diagram depicts how the classic subscription administrator roles, RBAC roles, and Azure AD administrator roles are related at a high level. Roles assigned at a higher scope, like an entire subscription, are inherited by child scopes, like service instances.
In the preceding diagram, a subscription is associated with only one Azure AD tenant. Also note that a resource group can have multiple resources but is associated with only one subscription. Although it’s not obvious from the diagram, a resource can be bound to only one resource group.
What can I do with RBAC?
RBAC allows you to grant access to Azure resources that you control. Suppose you need to manage access to resources in Azure for the development, engineering, and marketing teams. You’ve started to receive access requests, and you need to quickly learn how access management works for Azure resources.
Here are some scenarios you can implement with RBAC.
Allow one user to manage virtual machines in a subscription and another user to manage virtual networks
Allow a database administrator group to manage SQL databases in a subscription
Allow a user to manage all resources in a resource group, such as virtual machines, websites, and subnets
Allow an application to access all resources in a resource group
RBAC in the Azure portal
In several areas in the Azure portal, you’ll see a pane named Access control (IAM), also known as identity and access management. On this pane, you can see who has access to that area and their role. Using this same pane, you can grant or remove access.
The following shows an example of the Access control (IAM) pane for a resource group. In this example, ramtest has been assigned the Backup Operator role for this resource group.
How does RBAC work?
You control access to resources using RBAC by creating role assignments, which control how permissions are enforced. To create a role assignment, you need three elements: a security principal, a role definition, and a scope. You can think of these elements as “who”, “what”, and “where”.
1. Security principal (who)
A security principal is just a fancy name for a user, group, or application that you want to grant access to.
2. Role definition (what you can do)
A role definition is a collection of permissions. It’s sometimes just called a role. A role definition lists the permissions that can be performed, such as read, write, and delete. Roles can be high-level, like Owner, or specific, like Virtual Machine Contributor.
Azure includes several built-in roles that you can use. The following lists four fundamental built-in roles:
Owner – Has full access to all resources, including the right to delegate access to others.
Contributor – Can create and manage all types of Azure resources, but can’t grant access to others.
Reader – Can view existing Azure resources.
User Access Administrator – Lets you manage user access to Azure resources.
If the built-in roles don’t meet the specific needs of your organization, you can create your own custom roles.
3. Scope (where)
Scope is where the access applies to. This is helpful if you want to make someone a Website Contributor, but only for one resource group.
In Azure, you can specify a scope at multiple levels: management group, subscription, resource group, or resource. Scopes are structured in a parent-child relationship. When you grant access at a parent scope, those permissions are inherited by the child scopes. For example, if you assign the Contributor role to a group at the subscription scope, that role is inherited by all resource groups and resources in the subscription.
Role assignment
Once you have determined the who, what, and where, you can combine those elements to grant access. A role assignment is the process of binding a role to a security principal at a particular scope, for the purpose of granting access. To grant access, you create a role assignment. To revoke access, you remove a role assignment.
The following example shows how the Marketing group has been assigned the Contributor role at the sales resource group scope.
RBAC is an allow model
RBAC is an allow model. What this means is that when you are assigned a role, RBAC allows you to perform certain actions, such as read, write, or delete. So, if one role assignment grants you read permissions to a resource group and a different role assignment grants you write permissions to the same resource group, you will have read and write permissions on that resource group.
RBAC has something called NotActions permissions. Use NotActions to create a set of allowed permissions. The access granted by a role, the effective permissions, is computed by subtracting the NotActions operations from the Actions operations. For example, the Contributor role has both Actions and NotActions. The wildcard (*) in Actions indicates that it can perform all operations on the control plane. Then you subtract the following operations in NotActions to compute the effective permissions:
Delete roles and role assignments
Create roles and role assignments
Grants the caller User Access Administrator access at the tenant scope
To provide applications, services, or devices access to a central identity, there are three common ways to use Active Directory-based services in Azure. This choice in identity solutions gives you the flexibility to use the most appropriate directory for your organization’s needs. For example, if you mostly manage cloud-only users that run mobile devices, it may not make sense to build and run your own Active Directory Domain Services (AD DS) identity solution. Instead, you could just use Azure Active Directory.
Although the three Active Directory-based identity solutions share a common name and technology, they’re designed to provide services that meet different customer demands. At high level, these identity solutions and feature sets are:
Active Directory Domain Services (AD DS)
Enterprise-ready lightweight directory access protocol (LDAP) server that provides key features such as identity and authentication, computer object management, group policy, and trusts.
AD DS is a central component in many organizations with an on-premises IT environment, and provides core user account authentication and computer management features.
The Active Directory Domain Services (AD DS), is the traditional on-premises version of domain services provided by AD. Organizations use AD DS to centrally manage all their resource objects, such as users, computers, printers, shared folders, groups, organizational units (OUs), etc. These objects are part of the Active Directory domain, which allows the administrators to securely manage them through Group Policies. Some of the key features offered by AD DS includes:
One-premises identity & authentication
User and computer management
Group Policies
Domain trusts
AD DS is managed by the organizations on-premises. The Enterprise Administrators are responsible for managing AD DS domain controllers, AD sites, trust relationships between the domains, Group Policies, backing up and restoring AD DS, etc.
NOTE: In this article, the terms traditional AD and traditional AD DS, refer to the on-premises deployment of Active Directory and Active Directory Domain Services.
Azure Active Directory (Azure AD)
Azure Active Directory (Azure AD) is the Azure solution for identity and access management. Azure AD is a multitenant, cloud-based directory and identity management service from Microsoft. It combines core directory services, application access management, and identity protection into a single solution.
Cloud-based identity and mobile device management that provides user account and authentication services for resources such as Office 365, the Azure portal, or SaaS applications.Azure AD can be synchronized with an on-premises AD DS environment to provide a single identity to users that works natively in the cloud.
Azure AD offers some of the same features in the cloud, as AD DS offers on-premises. However, just because they both have AD in their names, doesn’t mean they are identical services. Azure AD is a cloud-based identity service that offers the following:
Cloud-based identification & authentication
User and computer management
Mobile Device Management (MDM)
Access to Software as a service (SaaS) applications, Microsoft Azure portal, and Office 365 services
Because Azure AD is hosted and managed by Microsoft in the cloud, organizations don’t have direct access to AD domain controllers the way they do in their on-premises environment. Microsoft exposes parts of the Azure AD to organizations through the web-based interface so they have enough control to run and customize the services, but Microsoft is responsible for managing the services and servers behind the scenes in its datacenters across the globe.
Azure Active Directory Domain Services (Azure AD DS)
Provides managed domain services with a subset of fully-compatible traditional AD DS features such as domain join, group policy, LDAP, and Kerberos / NTLM authentication.
Azure AD DS integrates with Azure AD, which itself can synchronize with an on-premises AD DS environment. This ability extends central identity use cases to traditional web applications that run in Azure as part of a lift-and-shift strategy.
The Azure AD DS is a managed AD DS service in the cloud. In other words, if you want the traditional AD DS running in the cloud, you can take advantage of the Azure AD DS service by running AD DS under Azure AD. This means that you will be able to use traditional AD DS features, such as Kerberos and NTLM authentication, Group Policies (which aren’t supported in Azure AD), LDAP, etc.
For organizations who are interested in running traditional AD DS services in the cloud, Microsoft offers a couple of methods. You can either use a manageddomain or a self-manageddomain. Here’s the difference.
Managed Domain
A managed domain is something that you will create in the cloud using AD DS and Microsoft will create and manage the associated resources as necessary.
Self-Managed Domain
A self-managed domain is an AD DS environment that you can create in the cloud using the traditional tools. For example, you will use Virtual Machines (VMs) to install the AD DS domain controllers, member servers, etc. This is a self-managed domain so you (not Microsoft) will be responsible for managing the domain just like you do in your on-premises environment.
With Azure AD DS, the core service components are deployed and maintained for you by Microsoft as a managed domain experience. You don’t deploy, manage, patch, and secure the AD DS infrastructure for components like the VMs, Windows Server OS, or domain controllers (DCs).
Azure AD DS provides a smaller subset of features to traditional self-managed AD DS environment, which reduces some of the design and management complexity. For example, there’s no AD forests, domain, sites, and replication links to design and maintain. For applications and services that run in the cloud and need access to traditional authentication mechanisms such as Kerberos or NTLM, Azure AD DS provides a managed domain experience with the minimal amount of administrative overhead.
When you deploy and run a self-managed AD DS environment, you have to maintain all of the associated infrastructure and directory components. There’s additional maintenance overhead with a self-managed AD DS environment, but you’re then able to do additional tasks such as extend the schema or create forest trusts.
Azure AD DS and Azure AD
Azure AD lets you manage the identity of devices used by the organization and control access to corporate resources from those devices. Users can also register their personal device (a bring-your-own (BYO) model) with Azure AD, which provides the device with an identity. Azure AD then authenticates the device when a user signs in to Azure AD and uses the device to access secured resources. The device can be managed using Mobile Device Management (MDM) software like Microsoft Intune. This management ability lets you restrict access to sensitive resources to managed and policy-compliant devices.
Traditional computers and laptops can also join to Azure AD. This mechanism offers the same benefits of registering a personal device with Azure AD, such as to allow users to sign in to the device using their corporate credentials.
Azure AD joined devices give you the following benefits:
Single-sign-on (SSO) to applications secured by Azure AD.
Enterprise policy-compliant roaming of user settings across devices.
Access to the Windows Store for Business using corporate credentials.
Windows Hello for Business.
Restricted access to apps and resources from devices compliant with corporate policy.
On an Azure AD-joined or registered device, user authentication happens using modern OAuth / OpenID Connect based protocols. These protocols are designed to work over the internet, so are great for mobile scenarios where users access corporate resources from anywhere.
With Azure AD DS-joined devices, applications can use the Kerberos and NTLM protocols for authentication, so can support legacy applications migrated to run on Azure VMs as part of a lift-and-shift strategy
Aspect
Azure AD-joined
Azure AD DS-joined
Device controlled by
Azure AD
Azure AD DS managed domain
Representation in the directory
Device objects in the Azure AD directory
Computer objects in the Azure AD DS managed domain
Authentication
OAuth / OpenID Connect based protocols
Kerberos and NTLM protocols
Management
Mobile Device Management (MDM) software like Intune
Group Policy
Networking
Works over the internet
Must be connected to, or peered with, the virtual network where the managed domain is deployed
