Securing Amazon WorkSpaces with Entra Conditional Access: How to Give Contractors a Separate IP Whitelist Without Touching Your Global Block Policy
A common enterprise challenge when federating Amazon WorkSpaces with Microsoft Entra ID: granting contractors IP-restricted access to a specific WorkSpaces environment without weakening your global Conditional Access block policy. This article covers the design, configuration, and safe validation of a per-application IP whitelist using Entra Conditional Access primitives and the What If simulation tool.
If your organisation uses Microsoft Entra ID to federate identity into Amazon WorkSpaces Personal, WorkSpaces Pools, or WorkSpaces Applications, there is a good chance you already have a Conditional Access policy in place that restricts sign-in to approved internal IP ranges. It is one of the most common controls we see in enterprise and public sector environments — a global block that says: if you are not coming from our network, you are not getting in.
That works well for employees. But what happens when you need to onboard contractors who are working from their own sites, with their own IP ranges, and who need access to a specific WorkSpaces environment? You do not want to loosen the global policy. You do not want to punch a hole that exposes all your other apps. You just want contractors to reach their designated WorkSpaces application, and only from IPs you have approved.
This post walks through exactly how to do that using Entra Conditional Access, and how to validate the design safely using the built-in What If tool — without touching your production environment.
The Common Customer Starting Point
Before getting into the solution, it is worth establishing why this scenario comes up so frequently — because the starting posture is both common and entirely deliberate.
Many enterprise and public sector organisations restrict their Entra ID tenant so that authentication is only permitted from their own internet egress IPs. In practice this means all user sign-ins must originate from a known corporate network — whether that is a head office, a data centre, or a managed remote access gateway such as a VPN or SD-WAN breakout point. Anything outside those ranges is blocked at the Conditional Access layer before it ever reaches an application.
This is a well-established security control. The rationale is straightforward: even if credentials are compromised, an attacker signing in from an unrecognised IP cannot complete authentication. It significantly reduces the attack surface for credential-based threats and is often a baseline requirement in regulated industries and government environments.
The implementation is typically a single Conditional Access policy applied to all users and all cloud applications, with a Block grant and a Named Location exclusion for the organisation's approved IP ranges. Simple, broad, and effective.
The problem this creates is equally common: third-party contractors, system integrators, and managed service providers who need access to specific applications cannot sign in from their own locations because their egress IPs are not in the organisation's approved range. The instinct is to add their IPs to the global Named Location — but that broadens access across the entire tenant. A better approach is to carve out a narrow exception: allow contractors to reach only the specific application they need, only from IPs you have explicitly approved, with no impact on the global policy that protects everything else.
For Amazon WorkSpaces environments using Entra ID federation, this scenario arises regularly. A contractor workforce may need access to a dedicated WorkSpaces Personal directory, a WorkSpaces Pools environment, or a WorkSpaces Applications deployment — and the organisation needs that access controlled independently of its internal user policy.
Why This Is Not as Straightforward as It Looks
The instinct most people have is to create a second Conditional Access policy that allows contractor access, and assume it will coexist with the global block. This does not work.
Entra evaluates all matching Conditional Access policies independently and combines the results using one non-negotiable rule:
A Block result always wins. No other policy can grant access if a Block policy has matched the same sign-in.
So if your global block policy matches a contractor sign-in — even if a second policy says allow — the contractor is blocked. The block must be made not to match in the first place. The correct approach is to exclude contractors from the global block via a user group exclusion, then govern their access entirely through a dedicated, app-scoped policy.
How It Applies to Amazon WorkSpaces
Amazon WorkSpaces Personal, WorkSpaces Pools, and WorkSpaces Applications all support SAML 2.0 federation with Microsoft Entra ID. Each environment registers as an Enterprise Application in your Entra tenant, which is exactly what makes this architecture possible — Conditional Access can target a specific Enterprise Application, meaning your contractor policy can be scoped to just the WorkSpaces environment they need, leaving every other app governed by the global policy unchanged.
The three WorkSpaces Enterprise Applications you might see in your tenant are:
| Application | WorkSpaces Product |
|---|---|
| Amazon WorkSpaces (Entra) | WorkSpaces Personal |
| WorkSpaces Pool | WorkSpaces Pools |
| WorkSpaces Applications | WorkSpaces Applications (AppStream-based) |
The pattern described in this post applies to any of these. You pick the one your contractors need — the rest stay fully protected by the global block.
The Architecture
Four components make up the full solution:
NL-Contractors-ApprovedIPs— A Named Location in Entra containing the contractor organisation's approved egress IP/CIDR ranges.GRP-Contractors-ExternalAccess— An Entra security group containing all contractor identities. This group is what connects the global block exclusion to the contractor-specific policy.- Global block policy (existing) — Modified with a single change:
GRP-Contractors-ExternalAccessis added to the Exclude list under Users. Nothing else changes. CA-EnterpriseApp-Contractors-IPWhitelist— A new Conditional Access policy scoped to contractors and the specific WorkSpaces Enterprise Application, implementing whitelist-only access from approved IPs.
How the IP Whitelist Works
Conditional Access does not have a native allow-only grant. A whitelist is implemented by inverting a Block policy with a location exclusion:
- Condition: Location = Any location, excluding
NL-Contractors-ApprovedIPs - Grant: Block
This means: sign in from an approved IP and the policy does not match (location excluded) — access passes through. Sign in from anywhere else and the policy matches — blocked. Whitelist-only behaviour, achieved entirely within standard Conditional Access primitives.
Configuration
Step 1: Create the Named Location
Navigate to Entra Portal > Protection > Conditional Access > Named locations > + IP ranges location.
| Field | Value |
|---|---|
| Name | NL-Contractors-ApprovedIPs |
| IP ranges | Contractor egress IPs in CIDR notation |
| Mark as trusted location | Optional |
Step 2: Create the Security Group
Navigate to Entra Portal > Groups > New group.
| Field | Value |
|---|---|
| Group type | Security |
| Group name | GRP-Contractors-ExternalAccess |
| Membership type | Assigned (or Dynamic based on contractor account attributes) |
Add contractor identities as members.
Step 3: Add the Group Exclusion to the Global Block Policy
Open your existing global block policy and navigate to Assignments > Users > Exclude. Add
GRP-Contractors-ExternalAccess.This is the only change made to the global policy. Its scope, location conditions, and grant controls remain unchanged.
Do this after validating the contractor policy in Report-only mode (see the validation section below). Adding the exclusion before the contractor policy is active leaves contractors in a state where the global block does not apply but no replacement policy governs them yet.
Step 4: Create the Contractor Whitelist Policy
Navigate to Conditional Access > Policies > + New policy.
| Section | Field | Value |
|---|---|---|
| Name | CA-EnterpriseApp-Contractors-IPWhitelist | |
| Users | Include | GRP-Contractors-ExternalAccess |
| Users | Exclude | Break-glass / emergency access accounts |
| Target resources | Include | Your WorkSpaces Enterprise Application |
| Conditions > Locations | Include | Any location |
| Conditions > Locations | Exclude | NL-Contractors-ApprovedIPs |
| Grant | Block access | |
| Policy state | Report-only (initially) |
Policy Interaction Matrix
Before going live it is worth being explicit about what each policy does for each user type:
| User | Target App | Source IP | Global Block | Contractor Policy | Result |
|---|---|---|---|---|---|
| Internal user | Any app | Internal IP | Not applied (IP excluded) | Not in scope | Allow |
| Internal user | Any app | External IP | Applied — Block | Not in scope | Block |
| Contractor | WorkSpaces app | Approved IP | Not applied (user excluded) | Not applied (location excluded) | Allow |
| Contractor | WorkSpaces app | Any other IP | Not applied (user excluded) | Applied — Block | Block |
| Contractor | Any other app | Any IP | Applied — Block | Not in scope (wrong app) | Block |
The last row is particularly important: contractors are only excluded from the global block for the specific WorkSpaces application. Attempt to reach anything else — Microsoft 365, internal tools, other WorkSpaces environments — and the global block applies in full.
Validating with the What If Tool
Before enabling anything in production, Entra's Conditional Access What If tool lets you simulate sign-in scenarios against your policies without triggering real authentication events or modifying any policy state. Think of it as a dry run against your policy set — you tell it who is signing in, from where, and into what application, and it tells you exactly which policies would apply and why.
Access it via Entra Portal > Protection > Conditional Access > What If.
Figure 1 — The What If tool form. User, target application, device platform, client app, and IP address are the key fields for this scenario.
For this scenario, populate the fields as follows for each simulation:
| Field | Value |
|---|---|
| Identity type | Users |
| User | The contractor test account |
| Target type | Cloud apps |
| Cloud app | Your WorkSpaces Enterprise Application |
| Device platform | Windows |
| Client app | Browser |
| IP address | The contractor approved IP (Simulation A) or 8.8.8.8 (Simulation B) |
Note: Device platform and Client app are mandatory fields in the What If tool. Country must be consistent with the IP address entered.
Phase 1: Before the Group Exclusion
With both policies in Report-only mode but without the group exclusion applied to the global block, run the contractor simulation from an approved IP.
Expected result: The contractor whitelist policy should be absent from the results (location excluded — correct). The global block should appear (group exclusion not yet added — expected at this stage).
Figure 2 — Before the group exclusion: global block appears in results, contractor policy is correctly absent (location excluded). This is the expected intermediate state.
Phase 2: After the Group Exclusion
Add
GRP-Contractors-ExternalAccess to the global block policy's Exclude list, then re-run.Simulation A — Contractor, approved IP:
Figure 3 — Simulation A: "Policies that will apply" tab. Only the MFA policy applies. Both block policies are absent.
Figure 4 — Simulation A: "Policies that will not apply" tab. Global block excluded due to Users and groups. Contractor policy excluded due to Location. Both reasons are exactly correct.
Simulation B — Contractor, external IP (8.8.8.8):
Figure 5 — Simulation B: "Policies that will apply" tab. Contractor whitelist policy blocks from an unapproved IP. Global block correctly absent (group exclusion holds for all IPs).
Figure 6 — Simulation B: "Policies that will not apply" tab. Global block excluded due to Users and groups — the exclusion applies regardless of source IP, not just from approved contractor IPs.
Results Summary
| Scenario | Contractor Policy | Global Block | Validated Result |
|---|---|---|---|
| Contractor, approved IP | Not applied — Location | Not applied — Users and groups | Allow |
| Contractor, external IP | Applied — Block | Not applied — Users and groups | Block |
| Internal user, internal IP | Not in scope | Not applied — Location | Allow |
| Internal user, external IP | Not in scope | Applied — Block | Block |
| Contractor, any other app | Not in scope | Applied — Block | Block |
All five scenarios produced the expected result. The architecture is validated.
One Thing to Watch: MFA
If your tenant has an MFA Conditional Access policy that applies to unmanaged or external devices, it will likely apply to contractor sign-ins from approved IPs too. This is not a problem with the IP whitelist architecture — it is your existing MFA policy doing its job — but it does mean contractors will need to complete MFA on sign-in. Make sure contractor accounts are provisioned with an MFA method (Microsoft Authenticator is the most reliable) before go-live.
Governance
A few things worth putting in place before this goes to production:
Access reviews for
GRP-Contractors-ExternalAccess: This group is excluded from your global block policy. Run a quarterly access review to ensure membership stays accurate and justified as engagements start and end.Named Location maintenance: When a contractor's egress IP changes, update
NL-Contractors-ApprovedIPs before the change takes effect to avoid access interruption.Break-glass accounts: Ensure your emergency access accounts are excluded from all Conditional Access policies including the new contractor policy.
Applying This to WorkSpaces Pools and WorkSpaces Applications
The pattern is identical for WorkSpaces Pools and WorkSpaces Applications — only the Enterprise Application selected in the Target resources step changes. If contractors need access to multiple WorkSpaces environments, you have two options:
Option A: Create a single contractor policy and add multiple WorkSpaces applications to the Target resources Include list. Simpler to manage, but all contractors get access to all listed apps.
Option B: Create separate contractor policies per WorkSpaces application, each with its own Named Location if different contractor groups have different IP ranges. More granular, but more policies to maintain.
For most environments, Option A is the right starting point. Option B becomes relevant when you have multiple distinct contractor organisations with different access requirements.
Summary
Entra Conditional Access gives you the building blocks to implement a clean, app-scoped IP whitelist for contractor access to Amazon WorkSpaces without any changes to your global security posture. The key insight is that you cannot simply add an allow policy on top of a block — you need to make the block not match by excluding the contractor group, then govern their access through a dedicated policy. The What If tool makes it safe to validate the full interaction before a single real sign-in event occurs.
The full architecture document including configuration steps, policy interaction matrix, and What If validation results with screenshots is available on request.
This pattern applies to Amazon WorkSpaces Personal, WorkSpaces Pools, and WorkSpaces Applications wherever SAML 2.0 federation with Microsoft Entra ID is in use.
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article