One Entra tenant, two directories: SAML federation for an isolated Amazon WorkSpaces Applications environment

Introduction

Solution overview

Why this works: two independent authentication layers

1. SAML to AWS, using the production Entra identity. Entra authenticates the user as their production identity (for example, jdoe@example.com) and federates to AWS. This is where your MFA and Conditional Access apply, and it grants the streaming entitlement. It is independent of the isolated directory.
2. Windows logon to the streaming instance, using the isolated-directory identity. The streaming instance, domain-joined to the isolated directory (for example, euc.example.com), takes the SAML Name ID as the Windows username and prompts the user for that account's password.

The components

• Microsoft Entra ID is the identity provider (IdP). It authenticates the production user and issues a signed SAML assertion.
• AWS IAM is the trust anchor. It validates the assertion against an IAM SAML identity provider, maps the user to an IAM role, and issues temporary credentials.
• Amazon WorkSpaces Applications is the service provider (SP). It receives the authenticated session and presents the user with their stack and applications in the isolated environment.

How the sign-in flow works

1. The user signs in to Entra ID with their production credentials and selects the WorkSpaces Applications tile.
2. Entra ID issues a signed SAML assertion and posts it, with the relay state, to the AWS sign-in endpoint at https://signin.aws.amazon.com/saml.
3. AWS validates the assertion against the IAM SAML identity provider, confirms the role mapping, and issues temporary credentials.
4. The user is forwarded to the relay state URL, the portal for your stack, and the streaming session starts in the browser or the native client.
5. Inside the session, the domain-joined instance completes the Windows logon against the isolated directory, using the Name ID as the username and prompting for the isolated-directory password.

Starting environment

• A VPC with no route to the internet, with directory and fleet subnets across two Availability Zones.
• Interface VPC endpoints for the management plane: AWS Systems Manager (ssm, ssmmessages, ec2messages), EC2, and AWS Directory Service (ds), each with Private DNS enabled, plus an S3 gateway endpoint on all route tables.
• An interface VPC endpoint for the WorkSpaces Applications streaming service (com.amazonaws.<region>.appstream.streaming) with Private DNS enabled and associated with the stack, so the streaming data plane stays inside the VPC. Optionally, an appstream.api endpoint for private management calls.

• A directory that provides identity for the fleet, either an AWS Managed Microsoft AD or a self-managed Active Directory on EC2. Both are supported and the choice does not change the federation configuration; it changes only where the accounts live and who operates the domain controllers (AWS with Managed AD, you with a self-managed AD on EC2).
• DNS resolution set through a DHCP option set (or a Route 53 Resolver rule) that points the fleet subnets at the directory's DNS, which forwards AWS service names back to the VPC resolver so the private endpoints keep resolving.
• A delegated OU that receives the fleet's computer objects, and a service account with the minimum rights to create and manage those objects.

• A directory configuration pointing at the directory, with the target OU distinguished name and the service account.
• A domain-joined fleet (On-Demand or Always-On), joined at launch into the delegated OU, with Default Internet Access disabled. It runs streaming and service management over an AWS-managed interface rather than your subnet, so it operates correctly in an isolated VPC with no NAT. Both fleet types domain-join and federate identically, so the rest of this post just says the fleet. Elastic fleets are not domain-joined and are out of scope.
• A stack associated with the fleet, with the streaming endpoint associated to it, and scaling policies that maintain a buffer of idle instances.

• The fleet is domain-joined, so SAML 2.0 is mandatory. Domain-joined fleets do not support User Pool access, so SAML is the only option, not one among several.
• Private streaming does not remove the sign-in dependency. The streaming endpoint privatises the session, but the user's device still reaches Microsoft Entra ID and the WorkSpaces Applications user-authentication domains to sign in. For an internal-only deployment, route the user network to the streaming endpoint over a VPN or AWS Direct Connect, and allow the Entra and user-authentication domains plus the endpoint's own FQDN, <vpc-endpoint-id>.streaming.appstream.<region>.vpce.amazonaws.com. Once the endpoint is set on the stack, that name replaces the public *.amazonappstream.com dependency. The federation in this post is exactly that sign-in path.

Prerequisites

• An active Entra ID tenant whose identities will access WorkSpaces Applications.
• The Cloud Application Administrator or Application Administrator role, to create and configure the enterprise application and its single sign-on settings.
• Entra ID P1 or higher if you intend to assign the application to a security group. Assigning individual users works on all tiers.
• A populated identity source attribute on each user. The SAML Name ID is derived from an attribute such as user.userprincipalname or user.mail; an empty source attribute is a frequent cause of authentication failures.

• An AWS account with permission to create SAML identity providers, IAM policies, and IAM roles.
• An existing WorkSpaces Applications stack, with an associated fleet and image. The stack must exist before you create the IAM policy, because the policy scopes to the stack ARN. The stack name is case-sensitive.
• Region consistency. The relay state endpoint Region, the stack Region, and the IAM policy resource ARN Region must all match.

Values used in this post

Build order

1. Phase 1 (Entra): Create the enterprise application, complete the Basic SAML configuration, then export the federation metadata. The metadata download stays disabled until the configuration is set, so this order matters.
2. Phase 2 (AWS): Create the IAM SAML identity provider from that metadata, then the IAM role with an inline streaming policy. Capture the provider and role ARNs.
3. Phase 3 (Entra): Return to Entra to configure the claims with those ARNs, then assign users or groups.
4. Phase 4: Validate the end-to-end sign-in.

Phase 1: Create the Entra enterprise application and export metadata

Create the application

1. In the navigation pane, choose Enterprise applications, then + New application.
2. On the Browse Microsoft Entra Gallery page, choose + Create your own application.
3. Name the application (for example, WorkSpaces Applications), select Integrate any other application you don't find in the gallery (Non-gallery), then choose Create.
4. When the application has been created, under Manage, choose Single sign-on, then select SAML.

Set the Basic SAML configuration

Export the federation metadata

1. In the SAML Certificates section, the Certificate (Base64), Certificate (Raw), and Federation Metadata XML download links are now active (greyed out until the Basic SAML configuration is set).
2. Download the Federation Metadata XML and save it somewhere you can reach from the AWS IAM console.

Phase 2: Configure AWS IAM

Create the SAML identity provider

1. In the IAM console, choose Identity providers, then Add provider.
2. For Provider type, choose SAML.
3. For Provider name, enter a name of your choosing. This post uses EntraSSO. It becomes part of the provider ARN, so use it consistently from here on.
4. Under Metadata document, choose Choose file and upload the Federation Metadata XML from Phase 1.
5. Choose Add provider.
6. Open the provider and copy its ARN. With the name above it reads:

Create the IAM role

1. In the IAM console, choose Roles, then Create role.
2. For the trusted entity type, choose SAML 2.0 federation.
3. Under SAML 2.0-based provider, choose the SAML provider you created (EntraSSO in this post). Leave the optional Condition section blank; the trust condition is set explicitly when you edit the trust policy.
4. Choose Next. Do not attach a permissions policy at this step, then choose Next again.
5. Name the role. This post uses WSA-EntraSSO-Role. The name becomes part of the role ARN referenced in the Entra Role claim, so use it consistently. Choose Create role.
6. Set the trust policy. Open the role, choose Trust relationships, then Edit trust policy, and set it to:

Phase 3: Configure the Entra claims and assignment

Set the Name ID claim

Remove the default claims

Add the AWS claims

• The Role value is the role ARN, then a comma, then the provider ARN, with no spaces.
• RoleSessionName must be 2 to 64 characters, alphanumeric plus + = , . @ -, with no spaces. Mapping it to user.userprincipalname gives each user a unique session name for AWS traceability. A static string is permitted, but a per-user attribute is preferred.
• SessionDuration is in seconds, between 900 (15 minutes) and 43200 (12 hours). If omitted, the session defaults to 60 minutes.

Assign users and groups

1. On the enterprise application menu, choose Manage, then Users and groups.
2. Choose + Add user/group, select the users or groups that should have access, then choose Assign.

Map the production identity to the isolated directory account

Transform the Name ID to the isolated directory UPN

Create the matching directory accounts and the two passwords

• Their production Entra password, entered in the browser when Entra authenticates the federation. This is where MFA and Conditional Access apply.
• Their separate isolated-directory password, entered at the in-session Windows logon prompt.

Considerations for the split-domain pattern

• Username matches, passwords do not. The sAMAccountName is identical in both directories, which is what makes the Name ID resolve, but the production and isolated-directory passwords are separate and managed independently. See "Create the matching directory accounts and the two passwords."
• Keep RoleSessionName clean. Source RoleSessionName from user.userprincipalname, not the transformed Name ID, so AWS traceability carries the production identity.
• onPremisesSamAccountName is only populated for synced users. It flows for accounts synced from on-premises AD via Entra Connect; cloud-only users would not have it.
• Mind the 20-character sAMAccountName limit. If a production username exceeds it, the match breaks.
• No interactive logon banner on the streaming OU. A logon banner (legal notice) GPO blocks the service from completing the Windows logon and produces a repeating password prompt, the most common cause of that symptom on domain-joined fleets.
• Group Policy is your responsibility in the separate directory. The isolated directory has its own Group Policy. Production policies (security baselines, hardening, screen-lock, audit) do not carry across on their own, even where a trust exists, because a trust authenticates principals but does not replicate Group Policy. Recreate and maintain the required GPOs in the isolated directory from a domain-joined management instance.
• Network line of sight. The fleet VPC must reach the isolated directory's domain controllers for the Windows logon, with the AD ports open: DNS (53), Kerberos (88), LDAP (389 and 636), SMB (445), and the RPC range. The fleet subnets must resolve the directory's DNS, set through a DHCP option set or a Route 53 Resolver rule.
• Profiles and shared resources live on the isolated directory side. Without a trust, the session identity cannot authenticate to production file shares, SQL Server using Windows authentication, licensing servers, or printers. Use home folders or FSLogix backed by storage joined to the isolated directory.
• Conditional Access still applies at sign-in. The SAML authentication runs in the browser against the production identity, so confirm no device-compliance or IP-based policy traps your test accounts.
• Certificate-based authentication maps cleanly later. If you move to passwordless sign-in, the isolated directory is the account's real domain, so add the PrincipalTag:ObjectSid claim and the sts:TagSession trust permission.

Validate before you rely on it

Phase 4: Validate the integration

Run the sign-in

1. Open a new private or incognito browser window.
2. Browse to the User access URL, or sign in to the Entra My Apps portal and select the WorkSpaces Applications tile.
3. Authenticate as a user assigned to the application, using their production Entra credentials. MFA and Conditional Access apply at this step.
4. You are redirected to the WorkSpaces Applications sign-in page, where you choose Continue with Browser or Open WorkSpaces Applications client.
5. When the session opens, enter the user's isolated-directory password at the in-session Windows logon prompt: the second, separate password, not the production one.
6. Confirm the streaming session starts and your assigned applications are available.

What a correct SAML assertion looks like

• NameID is the persistent UPN that exists in the isolated directory (jdoe@euc.example.com), not a GUID-like pairwise identifier. It becomes the Windows username in the session.
• RoleSessionName is the production identity (jdoe@example.com), kept separate from the NameID for AWS traceability.
• Role is the role ARN, a comma, then the provider ARN, with no spaces.
• Audience matches the Entity ID from Phase 1 (urn:amazon:webservices, or your numbered variant).
• Recipient and Destination are https://signin.aws.amazon.com/saml.
• SessionDuration is 3600 (one hour), and the Status is Success with the Assertion signed by the Active token-signing certificate.

Clean up

Conclusion