RBAC, Conditional Access and SSO
Control who manages AVD resources with RBAC, enforce security policies with Conditional Access, eliminate the double sign-in with SSO, and plan authentication methods including passwordless and smart card.
Three layers of AVD access control
Think of AVD security like a concert venue.
- RBAC is the backstage pass system. It decides who can set up the stage (manage host pools), who can let people in (assign users), and who can only watch (read settings). Different crew members get different coloured passes.
- Conditional Access is the bouncer at the door. Even if you have a ticket, the bouncer checks your ID, makes sure you are not on a banned list, and might ask for extra proof (MFA) before letting you in.
- SSO is the wristband. Once the bouncer lets you in, you do not need to show your ticket again at every bar or food stand inside the venue.
Azure RBAC for AVD
Built-in AVD roles
Azure provides several built-in roles specifically for AVD management. These follow least-privilege principles.
| Role | What It Can Do | Typical Assignee |
|---|---|---|
| Desktop Virtualization Contributor | Full management of all AVD resources (create, modify, delete host pools, app groups, workspaces) | AVD team leads, platform engineers |
| Desktop Virtualization Reader | Read-only access to all AVD resources | Auditors, helpdesk (view only) |
| Desktop Virtualization User | Lets users connect to application groups (assigned at the app group level) | End users |
| Desktop Virtualization Host Pool Contributor | Manage host pools but not app groups or workspaces | Session host administrators |
| Desktop Virtualization Host Pool Reader | Read-only access to host pools | Monitoring tools, read-only admins |
| Desktop Virtualization Application Group Contributor | Manage application groups | App publishing team |
| Desktop Virtualization Application Group Reader | Read-only access to app groups | Helpdesk |
| Desktop Virtualization Workspace Contributor | Manage workspaces | Workspace administrators |
| Desktop Virtualization Workspace Reader | Read-only access to workspaces | Reporting tools |
| Desktop Virtualization Session Host Operator | Start, stop, restart, and drain session hosts | Operations team, on-call staff |
| Desktop Virtualization Power On Off Contributor | Start and stop VMs via autoscale | Autoscale service principal |
🏢 Raj at TerraStack delegates carefully: “I gave our helpdesk team Desktop Virtualization Reader plus Session Host Operator. They can see everything and restart stuck session hosts, but they cannot change host pool settings or delete anything. Our app publishing team gets Application Group Contributor so they can publish RemoteApps without touching the infrastructure.”
Exam tip: Desktop Virtualization User is NOT a management role
The Desktop Virtualization User role is assigned to end users at the application group level — it grants the ability to connect and use desktops or apps. It does NOT grant any management permissions. If a question asks about assigning users to access AVD, the answer is Desktop Virtualization User on the application group resource.
Custom RBAC roles
If built-in roles do not match your needs, you can create custom roles. Common custom scenarios:
- AVD Deployer — can create host pools and register session hosts but cannot assign users or modify Conditional Access
- Profile Manager — can manage FSLogix storage accounts and file share permissions but not AVD resources
- Autoscale Operator — can start/stop/deallocate VMs but nothing else (narrower than Power On Off Contributor)
Custom roles are defined in JSON with specific Actions and NotActions. They can be scoped to a subscription, resource group, or individual resource.
Conditional Access for AVD
Conditional Access policies evaluate signals (user, device, location, risk) and enforce controls (MFA, device compliance, block) before granting access.
Key concept: Two cloud apps to target
AVD authentication involves two cloud apps in Conditional Access:
| Cloud App | App ID | Purpose |
|---|---|---|
| Azure Virtual Desktop | 9cdead84-a844-4324-93f2-b2e6bb768d07 | Authenticates the user to the AVD service (feed retrieval, resource enumeration) |
| Microsoft Remote Desktop | a4a365df-50f1-4397-bc59-1a1564b8bb9c | Authenticates the connection to the session host (the actual RDP session) |
Important: You should apply Conditional Access policies to both cloud apps. If you only target Azure Virtual Desktop, the user can get past the feed but still connect without MFA on the RDP session.
Common CA policy patterns for AVD
| Policy | Signal | Control | Purpose |
|---|---|---|---|
| Require MFA for AVD | All users, both AVD cloud apps | Require MFA | Baseline security for all connections |
| Block from untrusted locations | Both AVD cloud apps, exclude trusted IPs | Block access | Geo-restrict AVD access |
| Require compliant device | Both AVD cloud apps, device state | Require device to be marked as compliant | Only managed devices can connect |
| Require hybrid Entra joined device | Both AVD cloud apps, device state | Require hybrid Entra join | Restrict to corporate-managed PCs |
| Risk-based MFA | Both AVD cloud apps, sign-in risk medium+ | Require MFA | Adaptive security based on risk signals |
🏛️ JC at the Federal Department layers three CA policies: “Every connection requires MFA via FIDO2 key. Connections are blocked from outside the country. And the device must be Intune-compliant with BitLocker enabled. Director Walsh does not negotiate on this.”
Deep dive: Conditional Access frequency and AVD
By default, Entra ID re-evaluates Conditional Access when the authentication token expires. For AVD, this means users may be prompted for MFA during reconnection if their token has expired.
You can control this with sign-in frequency settings in the CA policy. Setting sign-in frequency to a longer period (e.g., 12 hours) reduces MFA prompts during the workday. Setting it shorter increases security but may interrupt users.
For the exam, know that sign-in frequency is configured in the Session controls section of the Conditional Access policy, not in the Grant controls.
Authentication methods
Passwordless authentication
AVD supports several passwordless methods:
| Method | How It Works | Requirements |
|---|---|---|
| FIDO2 security keys | Physical USB or NFC key | Entra ID joined or hybrid joined session hosts. Key must support CTAP2. |
| Windows Hello for Business | Biometric or PIN tied to the device | Device must be Entra ID joined or hybrid joined. Requires TPM. |
| Certificate-based auth | X.509 certificates on smart cards or virtual smart cards | AD DS or Entra certificate-based authentication configured |
Smart card redirection
For organisations using physical smart cards (common in government and healthcare), AVD can redirect the smart card reader from the client device into the remote session. The user inserts their smart card locally, and the session host uses it for authentication.
🏛️ JC uses smart card redirection for privileged access: “Our security auditor Aisha logs in with her PIV card. The card reader on her laptop is redirected into the AVD session, and she authenticates to classified systems inside the session using the physical card.”
MFA with AVD
MFA is enforced through Conditional Access policies targeting the two AVD cloud apps. Options include:
- Microsoft Authenticator push notifications
- FIDO2 security keys
- Phone-based verification (SMS or voice call — less secure, being deprecated)
- Temporary Access Pass (for onboarding when a user does not have their MFA device yet)
Single sign-on (SSO)
The problem SSO solves
Without SSO, users connecting to AVD see two credential prompts:
- Sign in to Entra ID (to access the AVD feed and resources)
- Sign in again at the session host (to authenticate the RDP connection)
This is confusing and frustrating. SSO eliminates the second prompt.
How SSO works in AVD
When SSO is enabled, AVD uses an Entra ID authentication token to sign in to the session host automatically. The user authenticates once to Entra ID, and the session host trusts that token.
Requirements for SSO:
- Session hosts must be Entra ID joined or hybrid Entra ID joined
- SSO must be enabled in the host pool RDP properties
- The “Microsoft Remote Desktop” Entra ID enterprise application must be configured to allow SSO
- Supported on Windows, macOS, iOS, Android clients and web client
🌐 Priya at NomadTech enabled SSO immediately: “Our remote workers connect from 12 countries on personal laptops. Before SSO, they had to enter credentials twice — half of them raised helpdesk tickets thinking the first login failed. After enabling SSO, login complaints dropped to zero.”
Exam tip: SSO and the consent dialog
When SSO is first enabled, users may see a one-time consent dialog asking them to allow the connection. You can suppress this by configuring the “Microsoft Remote Desktop” enterprise application in Entra ID to grant admin consent for the organisation. Expect a question about this — if SSO is enabled but users report a consent prompt, the fix is admin consent in the enterprise application, not a Conditional Access change.
| Method | Security Level | User Experience | Requirements |
|---|---|---|---|
| Password + MFA (Authenticator) | Good | Moderate — two prompts unless SSO enabled | Entra ID + Authenticator app |
| FIDO2 security key | Excellent | Tap and go — fast and phishing-resistant | Entra ID joined, CTAP2-compliant key |
| Windows Hello for Business | Excellent | Biometric or PIN — seamless | TPM, Entra ID joined or hybrid |
| Smart card (redirected) | Excellent | Insert card — familiar for gov/health | Smart card reader, RDP redirection enabled |
| Certificate-based auth | Excellent | Transparent if cert is on device | PKI infrastructure, cert deployment |
| Password only | Poor | Simple but insecure | Not recommended — always pair with MFA |
Putting it all together: RBAC + CA + SSO
| Layer | Controls | Example |
|---|---|---|
| RBAC | Who can manage AVD resources | Raj gives helpdesk Desktop Virtualization Reader, ops team gets Session Host Operator |
| Conditional Access | Conditions for user connections | JC requires MFA + compliant device + domestic IP for all AVD connections |
| SSO | Smooth user login experience | Priya enables SSO so remote workers authenticate once and land in their desktop |
| Auth methods | How users prove identity | JC uses FIDO2, Priya uses Authenticator, Mia uses smart card for clinical staff |
JC wants to ensure that all AVD users must use MFA and connect from a compliant device. He creates a Conditional Access policy targeting only the 'Azure Virtual Desktop' cloud app. What is the problem with this approach?
Priya enabled SSO for her AVD host pool, but users report seeing a consent dialog on first connection. How should Priya resolve this for all NomadTech users?
Raj needs to allow his operations team to restart stuck session hosts but NOT modify host pool settings, assign users, or delete any resources. Which built-in role should he assign?
🎬 Video coming soon
RBAC, Conditional Access and SSO
Next up: Defending AVD with Microsoft Defender — how to protect session hosts with Defender for Cloud, configure antivirus exclusions for FSLogix, and onboard endpoints to Defender for Endpoint.