Microsoft has added external identity support for Domainless SAML IdP federation to Azure Virtual Desktop. Aligned with the general availability of Domainless SAML IdP federation in Microsoft Entra ID, this update removes one of the most persistent friction points in B2B collaboration scenarios: the requirement that a guest user’s email domain match a domain configured on the external identity provider.

If you’ve ever tried to give a partner, contractor, or acquired company access to your AVD environment and hit a wall because their email domain didn’t line up with your SAML IdP configuration, this is the update that fixes that.

The Problem It Solves

Traditional direct federation in Microsoft Entra ID works by routing authentication based on email domains. You configure a SAML or WS-Fed identity provider and associate it with one or more verified domains. When a guest user signs in, Entra ID looks at their UPN suffix (email domain) and routes them to the matching IdP.

This works fine when your partner organization uses a single, predictable email domain. It falls apart quickly in real-world scenarios:

  • Multi-brand organizations where subsidiaries use different domains but share a central IdP
  • Mergers and acquisitions where the acquired company’s domains haven’t been migrated yet
  • Contractor networks where individual contractors use personal email domains
  • Partner ecosystems where multiple organizations need access through different IdPs but some share email providers

In all these cases, the domain-matching requirement meant you either couldn’t federate at all or had to configure and verify every possible domain — an administrative nightmare.

How Domainless Federation Works

Domainless SAML IdP federation changes the routing model entirely. Instead of matching on email domain, Entra ID routes authentication requests based on the SAML Issuer URI and optional domain_hint parameters.

Here’s what happens under the hood:

  1. You configure a SAML IdP in Entra ID as domainless
  2. When an invited guest user redeems their invitation, Entra ID sends the authentication request to the configured SAML IdP using the Issuer URI — not the user’s email domain
  3. The guest authenticates at their home IdP
  4. Entra ID accepts the SAML assertion based on the trust relationship with the IdP, regardless of the user’s email domain
  5. The guest account is created in your tenant and can be assigned to AVD host pools and app groups

The trust is placed on the SAML assertion and Issuer, not on the email suffix. This is a fundamental shift that makes external identity management far more flexible.

Key Constraint

Only one wildcard (domainless) IdP can be configured per Entra tenant. If you need to support multiple external IdPs with domainless routing, you’ll need to plan your federation topology carefully — potentially using a federating broker or identity hub pattern.

What This Means for AVD

From the Azure Virtual Desktop perspective, this update means you can now:

  • Provide desktops and RemoteApps to external identities whose email domains differ from the domain configured on the SAML IdP
  • Invite guest users by email without worrying about whether their domain matches your federation configuration
  • Use existing AVD assignment mechanics — no special provisioning flow for domainless external identities
  • Leverage Entra SSO — external identities authenticated via the domainless SAML IdP receive Entra tokens that AVD accepts for sign-in

AVD doesn’t require any special configuration for domainless federation. It simply consumes Entra authentication and treats the guest identity like any other Entra user once they’re in the directory.

How to Configure It

Configuration happens entirely in Microsoft Entra ID. AVD just consumes the result.

Step 1: Configure the Domainless SAML IdP in Entra ID

  1. Sign in to the Microsoft Entra admin center as at least External Identity Provider Administrator
  2. Navigate to Identity > External Identities > All identity providers
  3. Select Add SAML/WS-Fed identity provider
  4. Provide the required settings:
    • Display name — a friendly name for the partner IdP
    • Issuer URI — the SAML IdP’s unique issuer identifier (this is what routing will be based on)
    • Metadata URL or file — to import SAML endpoints and signing certificates
  5. Enable Domainless — check the Domainless field on the IdP configuration
  6. Save the configuration

Step 2: Invite External Users

  1. Go to Identity > Users > All users
  2. Select + New user > Invite external user
  3. Enter the guest user’s email address — no domain restrictions apply
  4. Configure display name, groups, roles, or access packages as needed
  5. Send the invitation

When the guest redeems their invitation, Entra ID routes the sign-in to the domainless SAML IdP using the Issuer URI. The guest authenticates at their home IdP and is then created as a guest in your tenant.

Step 3: Assign Users to AVD Resources

  1. Go to your AVD host pool and app group configuration in the Azure portal
  2. Assign the Entra guest users or groups to Desktop application groups or RemoteApp groups
  3. External users can now sign in to AVD using the Windows App or supported Remote Desktop clients

Step 4: Apply Governance and Conditional Access

  • Use Entra Governance (access packages, lifecycle policies) to manage the guest lifecycle
  • Apply Conditional Access policies that cover external users (MFA, device compliance, risk-based access)
  • Consider Entitlement Management to let external users request access through a governed workflow

Use Cases

Partner and Contractor Access

The most immediate use case. Organizations working with external partners, suppliers, or contractors can now provide AVD access without requiring those users to have specific email domains. Configure one domainless federation with the partner’s SAML IdP and invite users by email.

Mergers and Acquisitions

During M&A transitions, acquired company employees often need access to the parent organization’s AVD environment before domain migration is complete. Domainless federation bridges this gap — the acquired company’s IdP can be configured as the domainless IdP, and users can access AVD with their existing credentials.

Multi-Brand Organizations

Organizations operating multiple brands with different email domains but a shared identity infrastructure can use a single domainless IdP to provide AVD access across all brands without configuring each domain individually.

BYOD and Cross-Organization Workforces

Combine domainless federation with Entra Conditional Access and device compliance policies to provide controlled AVD access from users on external managed devices or personal devices. The server-side policy enforcement ensures security without relying on client-side controls.

Security Considerations

While domainless federation removes domain-matching requirements, it doesn’t remove security responsibilities:

  • Trust the IdP, not the domain — Your security boundary is now the SAML IdP trust relationship, not domain verification. Make sure you trust the IdP you’re federating with.
  • One domainless IdP per tenant — This is a constraint but also a guardrail. Be deliberate about which IdP you configure as domainless.
  • Conditional Access is critical — With external identities accessing AVD, ensure your CA policies cover guest users. Require MFA, assess sign-in risk, and apply device compliance where appropriate.
  • Governance and lifecycle — Use Entra Governance to manage guest lifecycle. External users shouldn’t persist indefinitely without review.
  • Audit and monitoring — Monitor sign-in logs for external identity authentications. Watch for unusual patterns from the federated IdP.

How This Fits the Broader AVD Identity Story

Microsoft has been steadily expanding identity support in Azure Virtual Desktop:

  • September 2025: External identity support without FSLogix (preview)
  • November 2025: External identity support reached GA, with FSLogix profile containers in preview
  • May 2026: FSLogix support for cloud-only and external identities reached GA
  • June 2026: Domainless federation support added, removing the last domain-matching barrier

Combined with existing features like Entra SSO, Conditional Access, and FSLogix profile containers for external identities, AVD now has a comprehensive external identity story. Organizations can securely provide virtual desktops and applications to users outside their organization while maintaining governance and security controls.

What You Should Do Now

  1. Identify external identity scenarios — Map out where external users need AVD access and whether domainless federation would simplify your current setup
  2. Evaluate your SAML IdP landscape — Determine which external IdP should be configured as the domainless IdP for your tenant
  3. Plan your governance strategy — Define access packages, lifecycle policies, and Conditional Access rules for external users before enabling the feature
  4. Pilot with a partner — Configure domainless federation for one external organization, invite a limited set of users, and validate end-to-end AVD access
  5. Update your documentation — If your team has procedures for external user onboarding, update them to reflect the new domainless option

Summary

Domainless SAML IdP federation support in Azure Virtual Desktop removes a real-world friction point that has limited B2B collaboration scenarios. By decoupling authentication routing from email domain matching, Microsoft has made it significantly easier to provide AVD access to partners, contractors, and acquired workforces.

The configuration is straightforward — set up the IdP in Entra ID, invite users by email, assign them to AVD resources. The real work is in governance: making sure you have the right Conditional Access policies, lifecycle management, and monitoring in place for external identities accessing your virtual desktop environment.

If you’re already using external identities with AVD, this expands what you can do. If you’ve been avoiding external identity scenarios because of domain-matching complexity, this removes that barrier.

Kevin Kaminski is the owner of Big Hat Group Inc., a Microsoft partner focused on AI and cloud technologies. Follow him at https://x.com/kkaminsk for more Azure Virtual Desktop insights.