Microsoft Entra External IDのドメインレスSAMLフェデレーションを使うと、外部ユーザーのメールアドレスと、Microsoft Entraに登録したSAML IdPのドメインが一致していなくても、外部IdPの資格情報で認証できます。
たとえば、パートナー企業のIdPが複数組織のユーザーを管理しており、利用者のメールアドレスがgmail.com、yahoo.co.jp、関連会社の独自ドメインなどに分散していても、メールドメインごとのフェデレーション設定を追加せずに認証できます。2026年7月、Microsoftはこの機能をワークフォーステナント向けに一般提供しました。(Microsoft Learn)
ただし、単に「ドメインレス」を有効にするだけでは不十分です。初回の招待では、招待リダイレクトURLにdomain_hintを付け、値をSAML IdPのIssuer URIと一致させる必要があります。また、メールアドレスのドメイン確認は省略されますが、SAMLアサーションのメールアドレス要求そのものは引き続き必要です。(Microsoft Learn)
EntraのドメインレスSAMLフェデレーションとは
従来のSAMLフェデレーションでは、外部IdPから返されるメールアドレスのドメインが、Microsoft Entra側でそのIdPに関連付けたドメインと一致する必要がありました。
たとえば、Microsoft Entra側でpartner.exampleを登録しているにもかかわらず、IdPが[email protected]を返した場合、次のようなエラーが発生することがあります。
AADSTS5000819:
SAML Assertion is invalid.
Email address claim is missing or does not match domain from an external realm.
ドメインレスSAMLフェデレーションでは、メールドメインではなく、Issuer URIとの関連付けを利用して認証要求を外部IdPへルーティングします。これにより、IdPが返すメールアドレスのドメインと、事前登録したIdPドメインの一致が不要になります。(Microsoft Learn)
| 比較項目 | 従来のドメインベース | ドメインレスSAML |
|---|---|---|
| 認証先の判断 | メールドメインと登録ドメイン | Issuer URIとdomain_hint |
| メールドメインの一致 | 必要 | 不要 |
| SAMLのメール要求 | 必要 | 必要 |
| 複数ドメインへの対応 | ドメイン追加が必要 | 任意のメールドメインを利用可能 |
| ワイルドカードIdP | 該当なし | 1テナントにつき1つ |
| 主な用途 | 単一企業、管理された独自ドメイン | 複数組織、個人メール、業界共通IdP |
重要なのは、ドメインレスとは「メールアドレスの確認が不要」という意味ではなく、「メールアドレスのドメインとIdP登録ドメインを比較しない」という意味である点です。
ドメインレスSAMLが向いているケース
EntraのドメインレスSAMLフェデレーションは、次のような環境で特に有効です。
- 業界団体やコンソーシアムの共通IdPで、複数企業の利用者を認証している
- 委託先や個人事業主が、Gmailなど組織外のメールアドレスを利用している
- M&Aやグループ再編により、利用者のメールドメインが多数存在する
- 学術認証基盤など、IdPと利用者のメールドメインが必ずしも一致しない
- 独自IdPで本人確認を行いつつ、Microsoft Entra上ではB2Bゲストとして管理したい
一方、外部ユーザーが別のMicrosoft Entraテナントに所属している場合は、SAMLでEntra同士を接続するのではなく、通常のEntra間B2Bコラボレーションを利用するのが基本です。Microsoftも、2つのMicrosoft Entraテナント間で直接SAMLフェデレーションを構成する方法を、サポート対象または推奨構成としていません。(Microsoft Learn)
構成前に確認する前提条件
本稿では、一般提供の対象として案内されたワークフォーステナントのB2Bゲスト招待を前提に説明します。Microsoft LearnのSAML/WS-Fed構成ページ自体は、ワークフォーステナントと外部テナントの両方を対象としていますが、2026年7月の一般提供案内ではワークフォーステナント向け機能として掲載されています。(Microsoft Learn)
必要な権限
IdPをMicrosoft Entraへ登録する管理者には、少なくとも外部IDプロバイダー管理者ロールが必要です。
外部ユーザーを招待する側には、テナントの外部コラボレーション設定に応じて、ゲスト招待者、ディレクトリライター、ユーザー管理者などの権限が必要です。Microsoft Graphを使う場合、最小権限としてUser.Invite.Allを利用できます。(Microsoft Learn)
パートナーIdPから入手する情報
外部組織のIdP管理者から、最低でも次の情報を入手します。
| 項目 | 内容 |
|---|---|
| Issuer URI | IdPを一意に識別するURI |
| パッシブ認証エンドポイント | HTTPSで公開されたサインイン先 |
| 署名証明書 | SAML応答の署名検証に使用 |
| メタデータURL | 証明書更新の自動化に利用 |
| 対象ユーザー | 外部IdPで認証を許可するユーザー |
| メール要求 | 利用者のメールアドレスを返す設定 |
| NameID | persistent形式で返す設定 |
Issuer URIは、次のようなRFC 3986形式の有効なURIでなければなりません。
https://idp.partner.example/saml
partner-idpのような単語だけの値は使用できません。後述するdomain_hintには、このIssuer URIを指定します。(Microsoft Learn)
ワークフォーステナント用のSAML設定値
外部IdPには、Microsoft Entraをサービスプロバイダーとして登録します。
| SAML設定 | ワークフォーステナントでの値 |
|---|---|
| Assertion Consumer Service | https://login.microsoftonline.com/login.srf |
| Audience | https://login.microsoftonline.com/<テナントID>/ |
| Issuer | パートナーIdPのIssuer URI |
| NameID Format | urn:oasis:names:tc:SAML:2.0:nameid-format:persistent |
| メール要求 | http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress |
新しいフェデレーションでは、Audienceをurn:federation:MicrosoftOnlineなどのグローバル値ではなく、テナントIDを含むエンドポイントに設定することが推奨されています。(Microsoft Learn)
メール要求は省略できない
ドメインレスSAMLで省略されるのは、メールアドレスのドメイン一致確認です。
次のメール要求自体が不要になるわけではありません。
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress
IdPがメール要求を返さない場合、ドメインレスを有効にしていても認証に失敗する可能性があります。導入テストでは、SAMLトレースなどを使い、実際のアサーションにメール要求が含まれていることを確認してください。(Microsoft Learn)
DNS設定が不要になるとは限らない
ドメインレスSAMLを有効にしても、フェデレーション設定時のDNS確認が必ず省略されるわけではありません。
Microsoft Entraに入力するIdPの対象ドメインと、パッシブ認証エンドポイントのドメインが異なる場合、パートナー側DNSにDirectFedAuthUrlのTXTレコードが必要になることがあります。
たとえば、対象ドメインがfabrikam.comで、認証先が別ドメインの場合は次のように設定します。
fabrikam.com. IN TXT DirectFedAuthUrl=https://login.fabrikam-idp.example/adfs
つまり、ドメインレスSAMLは「ドメイン登録が一切不要になる機能」ではありません。利用者のメールドメインとの照合をなくす機能と理解するのが正確です。(Microsoft Learn)
Microsoft EntraでドメインレスSAMLを構成する手順
パートナー側のSAML IdPを設定する
最初に、外部IdPへMicrosoft Entra用の証明書利用者信頼またはSAMLアプリケーションを追加します。
ワークフォーステナントの場合は、次の値を中心に設定します。
ACS:
https://login.microsoftonline.com/login.srf
Audience:
https://login.microsoftonline.com/<TENANT_ID>/
NameID Format:
urn:oasis:names:tc:SAML:2.0:nameid-format:persistent
Email claim:
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress
この段階で、テストユーザーに対して実際に返されるメールアドレスも確認します。メールアドレスのドメインは、Microsoft Entra側で登録するIdPドメインと一致していなくても構いません。(Microsoft Learn)
Microsoft EntraへSAML IdPを追加する
Microsoft Entra管理センターで、次の順に移動します。
Microsoft Entra ID
└ External Identities
└ すべてのIDプロバイダー
└ カスタム
└ 新規追加
└ SAML/WS-Fed
設定画面で次の情報を入力します。
| 項目 | 設定内容 |
|---|---|
| 表示名 | パートナーやIdPを識別できる名称 |
| IDプロバイダープロトコル | SAML |
| ドメインレス | 有効 |
| フェデレーションIdPのドメイン名 | 初期登録用の対象ドメイン |
| Issuer URI | 外部IdPのIssuer URI |
| パッシブ認証エンドポイント | HTTPSのサインインエンドポイント |
| 証明書 | 外部IdPの署名証明書 |
| メタデータURL | 可能であれば登録 |
「ドメインレス」を選択すると、利用者のメールアドレスに対するドメインチェックが適用されなくなります。認証要求は、ドメインではなくIssuer URIとの関連付けによって処理されます。(Microsoft Learn)
設定後は反映を待つ
フェデレーションポリシーが有効になるまで、5分から10分程度かかる場合があります。
保存直後に招待を引き換えると、古い認証経路へ進んだり、フェデレーションが見つからなかったりする可能性があります。設定後は少なくとも10分程度空けてから、新しいテストユーザーで確認するのが安全です。(Microsoft Learn)
必要に応じて招待の引き換え順序を変更する
ワークフォーステナントで、Microsoft Entraの確認済みドメインに属するユーザーを外部SAML IdPへ誘導する場合は、招待の引き換え順序も確認します。
Microsoft Entra ID
└ External Identities
└ Cross-tenant access settings
└ 既定の設定
└ 受信アクセス設定
└ B2Bコラボレーション
└ 引き換え順序
SAML/WS-Fed IDプロバイダーを、プライマリIDプロバイダーの上位へ移動します。これにより、Microsoft Entra IDなど別の認証方式よりも、外部フェデレーションを優先できます。(Microsoft Learn)
外部ユーザーをdomain_hint付きで招待する方法
ドメインレスSAMLでは、初回招待のリダイレクトURLにdomain_hintを含めます。
ここで指定する値は、メールドメインではありません。Microsoft Entraに登録したSAML IdPのIssuer URIです。(Microsoft Learn)
たとえば、Issuer URIが次の場合を考えます。
https://idp.partner.example/saml
domain_hintを付けたリダイレクトURLは、次のようになります。
https://myapps.microsoft.com/?tenantid=<TENANT_ID>&domain_hint=https%3A%2F%2Fidp.partner.example%2Fsaml
Issuer URIには:や/が含まれるため、クエリパラメーターへ入れる際はURLエンコードします。
Microsoft Graphで招待する例
Microsoft Learnでは、招待リダイレクトURLへのdomain_hint追加が必要とされています。管理センターの招待画面にリダイレクトURLの入力欄が表示されない場合は、Microsoft GraphのPOST /invitationsを使う方法が確実です。Microsoft Graphでは、招待先メールアドレスとinviteRedirectUrlを指定してB2B招待を作成できます。(Microsoft Learn)
POST https://graph.microsoft.com/v1.0/invitations
Authorization: Bearer <ACCESS_TOKEN>
Content-Type: application/json
{
"invitedUserEmailAddress": "[email protected]",
"invitedUserDisplayName": "外部ユーザー",
"inviteRedirectUrl": "https://myapps.microsoft.com/?tenantid=<TENANT_ID>&domain_hint=https%3A%2F%2Fidp.partner.example%2Fsaml",
"sendInvitationMessage": true
}
sendInvitationMessageをtrueにすると、Microsoft Entraから招待メールが送信されます。
Microsoft Graph PowerShellで招待する例
Connect-MgGraph -Scopes "User.Invite.All"
$tenantId = "<TENANT_ID>"
$issuerUri = "https://idp.partner.example/saml"
$encodedIssuer = [System.Uri]::EscapeDataString($issuerUri)
$redirectUrl = `
"https://myapps.microsoft.com/?tenantid=$tenantId&domain_hint=$encodedIssuer"
$params = @{
invitedUserEmailAddress = "[email protected]"
invitedUserDisplayName = "外部ユーザー"
inviteRedirectUrl = $redirectUrl
sendInvitationMessage = $true
}
New-MgInvitation -BodyParameter $params
既存のURLにすでにクエリパラメーターがある場合は、?domain_hint=ではなく&domain_hint=で追加します。
ユーザーが招待を引き換える
招待されたユーザーがメール内のリンクを開くと、Microsoft Entraはdomain_hintに指定されたIssuer URIを使って、対応する外部SAML IdPへ認証要求を送ります。
ユーザーは外部IdPの資格情報でサインインします。認証に成功すると、Microsoft Entra側のB2Bゲストユーザーと外部IdPとの関連付けが更新されます。以後は、対象アプリへ直接アクセスした場合でも、外部SAML IdPを使って認証できます。(Microsoft Learn)
ドメインレスSAMLでもゲストアカウントは作成される
ドメインレスSAMLフェデレーションは、Microsoft Entra上のB2Bゲストアカウントを不要にする機能ではありません。
招待を送信すると、ワークフォーステナント内にゲストユーザーオブジェクトが作成されます。このオブジェクトに対して、次のようなアクセス制御を行います。
- エンタープライズアプリへのユーザー割り当て
- セキュリティグループへの追加
- アプリケーションロールの付与
- ゲストユーザーの有効期限や利用状況の管理
外部IdPが担当するのは主に認証です。どのアプリやリソースへアクセスできるかは、リソース側テナントのゲストオブジェクトと権限設定で管理します。(Microsoft Learn)
既存のゲストユーザーは自動で切り替わらない
すでに招待を引き換えたユーザーへ後からドメインレスSAMLを設定しても、認証方法は自動的には変更されません。
既存ユーザーは、メールワンタイムパスコードやMicrosoftアカウントなど、最初に利用した認証方式を引き続き使用します。既存ユーザーを外部SAML IdPへ切り替える場合は、ユーザーの引き換え状態をリセットし、domain_hintを含む経路で再度引き換えさせます。(Microsoft Learn)
本番移行では、次の順序が安全です。
- 新規テストユーザーでドメインレスSAMLを確認する
- アプリへのアクセスとSAML要求を確認する
- 既存ユーザーの移行対象を抽出する
- 対象ユーザーの引き換え状態をリセットする
domain_hint付きの招待またはアクセスURLを案内する- 旧認証方式でサインインしていないか確認する
認証できない場合のチェックポイント
AADSTS5000819が表示される
次の2点を確認します。
- 外部IdPがメールアドレス要求を返しているか
- Microsoft Entra側で「ドメインレス」が有効になっているか
ドメインレスを有効にしても、メールアドレス要求自体は必要です。(Microsoft Learn)
外部IdPへリダイレクトされない
domain_hintの値を確認します。
誤り:
domain_hint=partner.example
正しい例:
domain_hint=https%3A%2F%2Fidp.partner.example%2Fsaml
値は、Microsoft EntraのSAML IdP設定に入力したIssuer URIと一致させます。メールドメインやパッシブ認証エンドポイントを指定しないよう注意してください。(Microsoft Learn)
設定直後だけ失敗する
フェデレーションポリシーの反映には5分から10分かかることがあります。保存直後の結果だけで設定ミスと判断せず、時間を空けて再確認します。(Microsoft Learn)
新規ユーザーは成功するが既存ユーザーは別方式になる
既存ユーザーは、以前の招待引き換え時に選択した認証方式を保持します。新しいフェデレーションへ切り替えるには、引き換え状態のリセットが必要です。(Microsoft Learn)
証明書更新後にサインインできない
メタデータURLを登録すると、証明書期限切れ時の自動更新に利用できます。ただし、証明書が有効期限前にローテーションされた場合や、メタデータURLを登録していない場合は、Microsoft Entra側の証明書を手動更新しなければならないことがあります。(Microsoft Learn)
導入時に注意したい制限と運用上のポイント
ワイルドカードIdPは1テナントにつき1つ
現在、ドメインレスとして利用できるワイルドカードIdPは、1テナントにつき1つです。
複数の外部組織がそれぞれ異なるSAML IdPを持ち、すべてをドメインレスで接続したい場合には、この制限が設計上の問題になります。その場合は、メールドメイン単位の通常フェデレーション、Entra間B2B、メールワンタイムパスコードなどを組み合わせてください。(Microsoft Learn)
メタデータURLを登録しても証明書監視は必要
メタデータURLの登録は強く推奨されていますが、すべての証明書ローテーションが自動処理されるとは限りません。
少なくとも次の情報は運用台帳に記録しておくと安全です。
- 現在の署名証明書の有効期限
- IdPのメタデータURL
- 証明書更新の担当組織
- 更新前の連絡期限
- 緊急時の手動更新手順
無効なドメイン名の入力に注意する
Microsoft Learnでは、無効なドメイン名を入力した場合、設定を保存していなくてもIdP構成が削除されることがある既知の問題が案内されています。
既存構成を編集する際は、事前にIssuer URI、エンドポイント、証明書、登録ドメインなどを記録してから操作してください。(Microsoft Learn)
IdPを削除すると既存ユーザーも影響を受ける
フェデレーション構成を削除すると、すでに招待を引き換えたフェデレーションユーザーがサインインできなくなる場合があります。
削除やIdP切り替えを行う場合は、対象ゲストユーザーの引き換え状態をリセットし、別の認証方式で再度引き換えられるようにする移行計画が必要です。(Microsoft Learn)
まず新規テストユーザー1名で確認する
EntraのドメインレスSAMLフェデレーションを導入するときは、最初から既存ゲスト全員を移行しないことが重要です。
まず、登録済みIdPドメインとは異なるメールアドレスを持つ新規ユーザーを1名用意し、次の順に確認します。
- 外部IdPがpersistent形式のNameIDを返す
- SAMLアサーションにメールアドレス要求が含まれる
- Microsoft Entraでドメインレスが有効になっている
domain_hintがIssuer URIと一致している- 招待リンクから外部IdPへリダイレクトされる
- 認証後にゲストユーザーとして対象アプリへアクセスできる
- 2回目以降も外部IdPで認証できる
- 証明書の期限と更新方法が管理されている
ドメインレスSAMLの導入効果は大きいものの、成否を分けるのは「ドメインレス」のチェックボックスではありません。Issuer URI、domain_hint、メール要求、招待の引き換え状態を一つの認証経路として正しく組み合わせることが、安定運用のポイントです。

コメント