AVD Contractor BYOD Access
Azure Virtual Desktop Conditional Access configuration for contractor BYOD access — Entra ID policies, Intune compliance, and RDP restrictions.
Audience: Latitudes IT Admin / Microsoft Entra Administrator | Time: 2–3 hours + 48-hour monitoring | Test account: btest@housingconnector.com
Contractors connect to AVD from any personal device (with MFA), but can only access Microsoft 365 data from inside the AVD session — never directly from their BYOD device.
Step 1: Prerequisites & Licensing
Required Licensing (per contractor user)
| License | Why Required |
|---|---|
| Microsoft Entra ID P1 (minimum) | Required for Conditional Access policies |
| Azure Virtual Desktop | Included with M365 E3/E5, M365 Business Premium, or Windows E3/E5 |
| Microsoft Intune | For session host compliance enrollment; included in M365 E3/E5 or M365 Business Premium |
Azure Infrastructure Checklist
Confirm All Are in Place
- Azure Virtual Desktop host pool deployed and operational
- Session hosts joined to Microsoft Entra ID and enrolled in Microsoft Intune
- Session hosts marked as compliant via Intune (see Step 4)
- Signed in with Global Administrator or Security Administrator role in Entra ID
Test Account
All configuration should be tested with btest@housingconnector.com before rolling out to additional contractor accounts. Use Report-only mode on all policies before enforcing.
Step 2: Create Security Group — SG-AVD-Contractors
Create a security group that targets all Conditional Access policies. Adding/removing contractors from this group is the only change needed during ongoing management — no policy edits required.
- Navigate to Microsoft Entra admin centre (entra.microsoft.com)
- Go to Identity → Groups → All groups → New group
- Configure the group:
| Field | Value |
|---|---|
| Group type | Security |
| Group name | SG-AVD-Contractors |
| Group description | Contractor users restricted to AVD-only O365 access |
| Membership type | Assigned |
- Click Create
- Open the newly created group and go to Members → Add members
- Search for and add
btest@housingconnector.com - Click Select to confirm
Ongoing Management
As you onboard additional contractors, simply add them to SG-AVD-Contractors. No policy changes are needed.
Critical Warning
The single biggest risk to FTE access is accidentally adding an FTE account to SG-AVD-Contractors. If an FTE is added, Policy 2 will require their device to be Intune-compliant before accessing O365 — and since FTE devices are not enrolled in Intune, they will be immediately blocked from Outlook, Teams, SharePoint, and all O365 services. Always double-check group membership before adding users. Consider setting up an Entra ID access review to periodically audit this group.
Step 3: Conditional Access Policy 1 — Allow AVD Connection
Allow contractors to authenticate to Azure Virtual Desktop from any device (including BYOD) with MFA. Without this policy, the block policy in Step 4 would prevent them from even connecting to AVD.
- Navigate to Entra admin centre → Protection → Conditional Access → Policies
- Click + New policy
- Name the policy:
CAP-Contractors-Allow-AVD-Connection
Assignments
- Under Users, click 0 users and groups selected
- Select Include → Select users and groups → Groups
- Search for and select SG-AVD-Contractors
- Under Target resources, click No target resources selected
- Select Select apps
- Search for and add all three apps:
| App Name | App ID |
|---|---|
| Azure Virtual Desktop | 9cdead84-a844-4324-93f2-b2e6bb768d07 |
| Microsoft Remote Desktop | a4a365df-50f1-4397-bc59-1a1564b8bb9c |
| Windows Cloud Login | 270efc09-cd0d-444b-a71f-39af4910ec45 |
All Three Apps Are Required
Azure Virtual Desktop handles the service connection. Microsoft Remote Desktop handles the client app authentication. Windows Cloud Login handles sign-in to the session host. Omitting any one of these will break the contractor's ability to connect to AVD.
Conditions
- Leave all conditions at Not configured (no restrictions on device platform, location, etc.)
Grant Controls
- Under Grant, select Grant access
- Select Require multifactor authentication
- Click Select
Enable Policy
- Set Enable policy to Report-only (for initial testing)
- Click Create
Why MFA?
MFA is recommended here because contractors are connecting from unmanaged BYOD devices. This adds a layer of identity verification before they reach the AVD session.
Step 4: Conditional Access Policy 2 — Block O365 from Non-Compliant Devices
Block all contractor access to Microsoft 365 apps unless the device is Intune-enrolled and compliant (i.e., the AVD session host). Contractor BYOD devices are not enrolled in Intune and will be effectively blocked from directly accessing O365 data.
- Navigate to Conditional Access → Policies → + New policy
- Name the policy:
CAP-Contractors-Block-O365-Non-Compliant
Assignments
- Under Users, select Include → Select users and groups → Groups
- Select SG-AVD-Contractors
- Under Target resources, select Select apps
- Add: Office 365 (built-in app group covering Exchange Online, SharePoint Online, Microsoft Teams, OneDrive, and all O365 services)
Conditions
- Leave all conditions at Not configured
Grant Controls
- Under Grant, select Grant access (not Block access)
- Select Require device to be marked as compliant
- Click Select
Grant Access vs. Block Access — Critical Distinction
The Grant control must be set to "Grant access" with the requirement of a compliant device — not "Block access". Setting it to Block access would block everyone, including users on the compliant AVD session hosts. The "Grant access + require compliant device" approach means: access is only granted if the device is enrolled and compliant. Contractor BYOD devices are effectively blocked because they are not enrolled in Intune.
Enable Policy
- Set Enable policy to Report-only
- Click Create
FTE Users Are Not Affected
This policy is scoped only to the SG-AVD-Contractors group. FTE users are not members of this group and will continue to access O365 normally from their Entra ID joined devices.
Step 5: Configure Intune Compliance Policy
Create a minimal compliance policy that marks AVD session hosts as compliant. The policy is intentionally configured with no rules — compliance is being used purely as a gating mechanism for Conditional Access, not for device health enforcement.
- Navigate to Intune admin centre (intune.microsoft.com)
- Go to Devices → Compliance → Policies
- Click + Create policy → Platform: Windows 10 and later
- Name the policy:
CP-AVD-SessionHosts-Minimal - Under Compliance settings, configure ALL categories as follows:
| Category | Setting |
|---|---|
| Device Health | All settings: Not configured |
| Device Properties | All settings: Not configured (do NOT set min/max OS version) |
| System Security | All settings: Not configured (do NOT require BitLocker, firewall, antivirus, or TPM) |
| Microsoft Defender for Endpoint | Not configured |
Do Not Add Any Compliance Rules
Any rule you add creates a potential point of failure. For example: requiring a minimum OS version means a delayed Windows Update could cause session hosts to fall out of compliance and lock all contractors out of AVD. Leave everything at "Not configured."
- Under Actions for noncompliance, keep the default: Mark device noncompliant — Immediately
- Under Assignments, target a device group: SG-AVD-SessionHosts Do NOT assign to All Devices
- Click Create
How This Works
When an Intune compliance policy has no rules configured, any device that receives the policy and successfully checks in with Intune is automatically marked as compliant. AVD session hosts will remain compliant as long as they are enrolled and checking in — no risk of falling out of compliance due to a missed update or configuration drift.
Why This Does Not Affect FTEs
Conditional Access scoping: Policy 2 targets only SG-AVD-Contractors. FTEs are not members of this group, so the compliance requirement is never evaluated for their sign-ins.
Compliance state for unenrolled devices: FTE laptops are not enrolled in Intune and have no compliance state in Entra ID. This has no effect on FTEs because no Conditional Access policy targeting FTEs requires a compliant device.
Important: Do NOT enable the tenant-wide Intune setting that marks devices with no compliance policy as non-compliant. Leave this at its default.
Step 6: Configure RDP Host Pool Properties
Prevent contractors from exfiltrating data out of the AVD session by restricting RDP redirection features. Conditional Access blocks direct O365 access from BYOD devices, but these RDP settings prevent copy/paste and file transfer as additional DLP controls.
- Navigate to Azure Portal (portal.azure.com)
- Go to Azure Virtual Desktop → Host pools → Select your contractor host pool
- Go to Settings → RDP Properties
- Configure the following:
| Setting | Value | Reason |
|---|---|---|
| Clipboard redirection | Disabled | Prevents copy/paste between AVD and local device |
| Drive/storage redirection | Disabled | Prevents mapping local drives into the session |
| Printer redirection | Disabled | Prevents printing to local printers |
| USB device redirection | Disabled | Prevents USB passthrough |
| Audio output redirection | Enabled | Allow audio for Teams calls |
| Camera redirection | Enabled | Allow webcam for Teams meetings |
| Microphone redirection | Enabled | Allow microphone for Teams calls |
- Click Save
Alternative: Custom RDP Properties String
You can also set these directly via the custom RDP properties field:
redirectclipboard:i:0;redirectprinters:i:0;drivestoredirect:s:;devicestoredirect:s:;redirectcomports:i:0;usbdevicestoredirect:s:;audiocapturemode:i:1;camerastoredirect:s:*;audiomode:i:0These Settings Are Essential for DLP
Without these restrictions, a contractor could copy sensitive data from the AVD session and paste it to their local machine, or save files to a redirected local drive. Do not skip this step.
Step 7: How the Policies Work Together
Important: Conditional Access policies in Entra ID are evaluated simultaneously — they are not processed in a top-down order like firewall rules.
Scenario A — Contractor opens Remote Desktop on their personal laptop Policy 1 (Allow AVD Connection) applies. The contractor satisfies MFA and is granted access. Policy 2 does not apply at this stage because Office 365 is not being accessed. Allowed.
Scenario B — Contractor opens Outlook/Teams inside the AVD session Policy 2 (Block O365 Non-Compliant) applies. The AVD session host is Intune-enrolled and compliant, so the grant condition is met. Allowed.
Scenario C — Contractor tries outlook.office.com from their personal browser
Policy 2 applies. The BYOD device is not enrolled in Intune and has no compliance state. The grant condition is not met. Blocked. Even if the contractor enrols their personal device in Intune, it will not be in the SG-AVD-SessionHosts group, will not receive the compliance policy, and will remain non-compliant.
Scenario D — Contractor tries teams.microsoft.com from their personal browser Same as Scenario C. The contractor sees a compliance error and must use AVD instead. Blocked.
Key Outcome
Contractors can connect to AVD from any device, but can only access O365 data from within the AVD session.
Step 8: Testing Procedure
Validate all scenarios using btest@housingconnector.com with policies in Report-only mode before enforcing.
8.1 Test in Report-Only Mode
- Sign in to entra.microsoft.com and navigate to Protection → Conditional Access → Sign-in logs
- Have
btest@housingconnector.comperform each test scenario below - Check the sign-in logs after each test to confirm the correct policy would have applied
8.2 Test Scenarios
| # | Scenario | Expected Result | Verify |
|---|---|---|---|
| 1 | Connect to AVD via Remote Desktop from personal laptop | ✅ SUCCESS — Connection allowed after MFA | User reaches AVD desktop |
| 2 | Open Outlook/Teams/SharePoint inside the AVD session | ✅ SUCCESS — O365 apps load normally | Full access to email, files, Teams |
| 3 | Open outlook.office.com in a browser on the personal laptop (not via AVD) | 🚫 BLOCKED — Device is not compliant | User sees "You cannot access this right now" error |
| 4 | Open teams.microsoft.com in a browser on the personal laptop | 🚫 BLOCKED — Device is not compliant | User sees compliance error |
| 5 | Attempt to copy text from AVD session and paste on local device | 🚫 BLOCKED — Clipboard disabled | Paste produces no content |
| 6 | Check if local drives appear in AVD File Explorer | 🚫 BLOCKED — Drive redirection disabled | No local drives visible in session |
| 7 | Open Microsoft Remote Desktop app and sign in | ✅ SUCCESS — App lists available desktops | AVD workspace and session hosts are visible |
8.3 Enforce Policies
Always Test in Report-Only Mode First
Enforcing an incorrectly configured block policy could lock contractors out of AVD entirely. Do not switch to enforcement until all Report-only tests pass.
- Once all tests pass in Report-only mode, navigate to each policy
- Change Enable policy from Report-only to On
- Re-run all test scenarios to confirm enforcement
- Monitor sign-in logs for 24–48 hours to catch any unexpected blocks
Step 9: Rollout Checklist
- Confirm Entra ID P1 licensing for all contractor accounts
- Deploy AVD host pool with Entra ID joined session hosts enrolled in Intune
- Create minimal Intune compliance policy (CP-AVD-SessionHosts-Minimal) with no rules
- Assign compliance policy to SG-AVD-SessionHosts device group only
- Create SG-AVD-Contractors security group in Entra ID
- Add btest@housingconnector.com to SG-AVD-Contractors
- Create CAP-Contractors-Allow-AVD-Connection (set to Report-only)
- Create CAP-Contractors-Block-O365-Non-Compliant (set to Report-only)
- Configure RDP host pool properties (disable clipboard, drives, printers, USB)
- Run all 7 test scenarios in Report-only mode — all pass
- Switch both policies to Enforced (On)
- Re-run all test scenarios under enforcement — all pass
- Monitor sign-in logs for 48 hours — no unexpected blocks
- Onboard remaining contractor accounts to SG-AVD-Contractors
Policy Summary
| Setting | Policy 1: Allow AVD | Policy 2: Block O365 |
|---|---|---|
| Policy Name | CAP-Contractors-Allow-AVD-Connection | CAP-Contractors-Block-O365-Non-Compliant |
| Users | SG-AVD-Contractors | SG-AVD-Contractors |
| Target Apps | Azure Virtual Desktop, Microsoft Remote Desktop, Windows Cloud Login | Office 365 (all apps) |
| Conditions | None | None |
| Grant | Grant access + Require MFA | Grant access + Require compliant device |
| Effect | Contractors can connect to AVD from any device with MFA | Contractors can only access O365 from Intune-compliant AVD session hosts |
Q&A
Q: Why couldn't a contractor just join Entra ID and enrol their device in Intune to access resources directly?
Even if a contractor did both of those things, it still wouldn't work. The compliance policy (CP-AVD-SessionHosts-Minimal) is assigned only to the SG-AVD-SessionHosts device group. A contractor's personal laptop — even if enrolled in Intune — would not be a member of that device group. Without receiving the compliance policy, the device has no compliance state, and Conditional Access treats "no compliance state" the same as "non-compliant." Policy 2 would still block them.
The only way a contractor could bypass this is if they somehow got their personal device into the SG-AVD-SessionHosts device group:
- If it's an assigned (manual) group, they'd need admin access to Intune to add their device.
- If it's a dynamic device group, they'd need to know the rule criteria and make their device match it.
Dynamic Group Rule Design
This is why the dynamic group rule should be based on something a contractor cannot control — such as the Azure VM resource ID, the Entra ID device ID, or an Intune device category that only admins can set. Avoid basing the rule on attributes a contractor could spoof or manipulate on their own device.
Additional Resources
- Support: support@latitudes.io
- Entra admin centre: entra.microsoft.com
- Intune admin centre: intune.microsoft.com
- Azure Portal (AVD): portal.azure.com → Azure Virtual Desktop
- Microsoft Docs: Set up MFA for Azure Virtual Desktop