A Microsoft Entra sign-in can open a Windows application in AWS without asking the user for a second Active Directory password. That sounds simple. The path behind it is not.

Identity claims, IAM permissions, certificate trust, revocation data, DNS, domain membership, and fleet capacity must all agree. A sound solution validates the complete path and documents failure points that a basic application-launch test would miss.

The reference design supports browser launch into a domain-joined Windows Server session through certificate-based authentication (CBA). The validation model checks application launch, the resulting Windows identity, password fallback, and the disable/re-enable path.

Why use certificate-based authentication?

The goal was to test whether an organisation using Microsoft Entra ID and Active Directory could give users a cleaner route into streamed Windows applications. Entra remains the primary authentication point, including its MFA and access policies. CBA removes the additional AD password prompt inside the streaming journey.

This matters when an application still needs a Windows domain identity, but users should not manage another sign-in step. Typical candidates include line-of-business applications, controlled contractor access, and published applications that are better kept close to company data.

Passwordless here does not mean unauthenticated. AWS describes CBA as a SAML-backed flow in which WorkSpaces Applications requests a user certificate and presents it through a virtual smart card. The identity provider still authenticates the user first.

For a broader view of hosted desktop choices, see our AWS, Azure Virtual Desktop and Citrix comparison.

What should a complete solution prove?

A defensible implementation should pass 11 acceptance checks before it is treated as successful. A green application window alone is not enough.

Sanitized acceptance matrix showing eleven checks for a WorkSpaces Applications CBA solution

The checks covered account isolation, Entra authentication, SAML mapping, domain join, CA trust, two revocation paths, passwordless launch, password fallback, reversible CBA state, and controlled teardown.

The key result is identity continuity. The UPN and SID originate in Active Directory, are synchronized to Entra, travel in the SAML assertion, and resolve back to the same Windows user. That end-to-end match turns a successful stream into a verified identity result.

How does the identity and certificate path work?

The design joins two related paths: federation establishes who may enter the AWS stack, while PKI lets Windows authenticate that same person to Active Directory without a password prompt.

  1. The user authenticates with Microsoft Entra ID.
  2. Entra sends a SAML assertion containing a persistent NameID, role information, UPN, ObjectSid, and the AD domain value.
  3. AWS STS creates the federated role session. The trust policy permits both sts:AssumeRoleWithSAML and sts:TagSession.
  4. WorkSpaces Applications reserves capacity in the domain-joined fleet.
  5. The service requests a short-lived user certificate from AWS Private CA.
  6. Windows receives the certificate through a virtual smart card and maps it to the intended AD identity.

The SID is not optional glue. AWS states in its CBA prerequisites that ObjectSid must match the AD SID for the user in the SAML NameID. The same guidance requires sts:TagSession and an online CRL distribution point reachable by the fleet and domain controller.

A six-stage implementation approach

A safe proof environment should remain isolated and deliberately small. It should use a dedicated non-production AWS account, with no route or trust to customer or production networks.

The implementation had six stages:

  1. Foundation: a dedicated VPC, private application subnets, controlled egress, tagging, budgets, and Systems Manager administration.
  2. Directory: one disposable Windows domain controller provided AD DS, DNS, AD CS, and the Entra Cloud Sync agent.
  3. Hybrid identity: synchronize a standard test user to Entra and check the UPN and on-premises SID at each boundary.
  4. Federation: an Entra enterprise application emitted the required SAML claims. The IAM role authorized the stream action and session tags.
  5. PKI: use the AD CS enterprise root to sign a short-lived AWS Private CA subordinate, then publish the chain to the enterprise Root and NTAuth stores.
  6. Application delivery: a custom Windows Server 2022 image, an Always-On multi-session fleet, and an application-view stack delivered the test application.

For revocation, AWS Private CA wrote its CRL to a private S3 origin. CloudFront exposed only the unauthenticated HTTP retrieval path needed by PKI clients while S3 Block Public Access stayed enabled. This follows the pattern in the AWS Private CA CRL guidance.

Evidence from connection to revocation

The first evidence is the connection screen. It explicitly shows the certificate-based authentication path. The streaming URL and browser chrome are removed from the published view.

Sanitized WorkSpaces Applications screen connecting with certificate-based authentication

The second proof is inside Windows. The sanitized demonstration launches Notepad in application view and checks the current Windows token. User and domain values are replaced with <TEST-USER> and <LAB-DOMAIN>.

Sanitized application launch and Windows whoami evidence with user and domain placeholders

The third evidence is revocation reachability. The CRL address embedded in the certificate returns HTTP 200. The public hostname, PCA identifier, IP, request identifiers, ETag, and timestamps are excluded from this crop.

Sanitized CRL request returning HTTP 200 with hostname and private CA identifier replaced

A complete validation also selects password fallback, authenticates the same AD identity, disables CBA, and enables it again. The expected behaviour must return in each state. This reversible test avoids mistaking a one-time success for an operable design.

Common implementation lessons

The hardest problems appear at the boundaries between services. Four lessons are especially reusable:

  • Inspect the emitted SAML assertion. A portal configuration can look correct while the actual claim name, value, or quotation format is wrong.
  • Test the certificate's real CRL URL. Publishing a CRL does not prove that the domain controller and fleet can retrieve it.
  • Check capacity before blaming identity. An empty Always-On fleet can produce connection errors that resemble CBA failures.
  • Treat disablement and cost demotion separately. Disabling CBA does not remove ongoing Private CA or NAT costs.

For intermittent demonstrations or retained pilots, a guarded pilot-light operating model can stop the domain controller and fleet, remove replaceable NAT and Private CA resources, and preserve the forest, custom image, stack, identity anchors, and CRL distribution. Promotion creates a new subordinate CA and reruns the acceptance checks.

Where can this pattern be useful?

This pattern fits organisations that already trust Entra for user authentication but still depend on Windows applications and AD identities. It can publish a controlled application through a browser or client while keeping execution, data access, and Windows policy inside the AWS environment.

Computer On Site designs this identity path around each customer's Entra tenant, Active Directory, applications, network controls, and operating model.

It is not the default answer for every workload. Cloud-native applications may not need an AD session at all. Full desktops may suit users who need a persistent workspace. Some applications have peripheral, latency, licensing, or graphics requirements that must be tested with real users.

Our cloud workspace services cover that wider assessment: identity, applications, network, storage, security, user experience, operations, and cost.

What must change before production?

The minimal reference configuration is not a production blueprint. A production design should use at least two domain controllers across Availability Zones, separate long-lived PKI roles, monitored and redundant revocation publication, approved backup and recovery procedures, tighter administrative boundaries, and tested concurrency and scaling.

It should also define ownership. Someone must own the Entra application, IAM role, AD identity, CA lifecycle, fallback path, evidence retention, and incident response. The design is only complete when those operating responsibilities are explicit.

Frequently asked questions

Does CBA remove every password?

It removes the AD password prompt from the WorkSpaces Applications session. The user still authenticates with the SAML identity provider, such as Microsoft Entra ID, under the organisation's access and MFA policies.

Does the Windows application still receive an AD identity?

Yes. The short-lived certificate is presented through a virtual smart card and mapped to the synchronized AD user. Validation should check the resulting Windows token rather than relying only on the application launch.

Why is CRL access part of authentication testing?

Windows must be able to check whether the certificate chain remains valid. AWS requires the CRL distribution point to be reachable from both the domain controller and fleet instance. A blocked or incorrect CDP can break CBA even when SAML is correct.

Is the reference architecture production-ready?

Not as-is. A minimal demonstration may use one domain controller, a multifunction AD CS role, and limited capacity. Production needs redundancy, separation of duties, monitoring, security review, capacity testing, and a rehearsed rollback path.

Turn an identity idea into a tested pilot

The value of this solution is not just a passwordless application window. It is a repeatable method for proving identity fidelity, certificate trust, revocation, capacity, fallback, and recovery together.

Computer On Site can design and validate an AWS application or desktop pilot around your identity, applications, and operating requirements. Talk to us about an AWS workspace assessment.