ゲスト ユーザーのための AD FS およびサード パーティ プロバイダーとの直接フェデレーション (プレビュー)Direct federation with AD FS and third-party providers for guest users (preview)

直接フェデレーションは、Azure Active Directory のパブリック プレビュー機能です。Direct federation is a public preview feature of Azure Active Directory. 詳細については、「Microsoft Azure プレビューの追加使用条件」を参照してください。For more information about previews, see Supplemental Terms of Use for Microsoft Azure Previews.

この記事では、B2B コラボレーションのために別の組織との直接フェデレーションを設定する方法について説明します。This article describes how to set up direct federation with another organization for B2B collaboration. 任意の組織の ID プロバイダー (IdP) が SAML 2.0 または WS-Fed プロトコルをサポートしていれば、その組織との直接フェデレーションを設定することができます。You can set up direct federation with any organization whose identity provider (IdP) supports the SAML 2.0 or WS-Fed protocol. パートナーの IdP との直接フェデレーションを設定すると、そのドメインに属する新しいゲスト ユーザーがご自身の Azure AD テナントに、そのユーザー自身の組織アカウント (IdP が管理する) を使用してサインインし、コラボレーションを開始できます。When you set up direct federation with a partner's IdP, new guest users from that domain can use their own IdP-managed organizational account to sign in to your Azure AD tenant and start collaborating with you. ゲスト ユーザーが別個の Azure AD アカウントを作成する必要はありません。There's no need for the guest user to create a separate Azure AD account.

注意

直接フェデレーションのゲスト ユーザーは、テナント コンテキストが含まれたリンク (例: https://myapps.microsoft.com/?tenantid=<tenant id> または https://portal.azure.com/<tenant id>、または検証済みのドメインの場合は https://myapps.microsoft.com/\<verified domain>.onmicrosoft.com) を使用してサインインする必要があります。Direct federation guest users must sign in using a link that includes the tenant context (for example, https://myapps.microsoft.com/?tenantid=<tenant id> or https://portal.azure.com/<tenant id>, or in the case of a verified domain, https://myapps.microsoft.com/\<verified domain>.onmicrosoft.com). アプリケーションとリソースへの直接リンクも、テナント コンテキストが含まれている限り機能します。Direct links to applications and resources also work as long as they include the tenant context. 直接フェデレーションのユーザーは現在、テナント コンテキストが含まれていない共通エンドポイントを使用してサインインできません。Direct federation users are currently unable to sign in using common endpoints that have no tenant context. たとえば、https://myapps.microsoft.comhttps://portal.azure.com、または https://teams.microsoft.com を使用するとエラーが発生します。For example, using https://myapps.microsoft.com, https://portal.azure.com, or https://teams.microsoft.com will result in an error.

ゲスト ユーザーが直接フェデレーションを使用で認証されるタイミングWhen is a guest user authenticated with direct federation?

組織との直接フェデレーションを設定した後、招待した新しいゲスト ユーザーは、直接フェデレーションを使用して認証されます。After you set up direct federation with an organization, any new guest users you invite will be authenticated using direct federation. 重要なこととして、直接フェデレーションを設定しても、ご自身からの招待を既に利用済みのゲスト ユーザーに対する認証方法は変更されないことに注意してください。It’s important to note that setting up direct federation doesn’t change the authentication method for guest users who have already redeemed an invitation from you. 次に例をいくつか示します。Here are some examples:

  • ゲスト ユーザーがご自身からの招待を既に利用済みであり、その後にゲスト ユーザーの組織との直接フェデレーションを設定した場合、それらのゲスト ユーザーは、直接フェデレーション設定前に使用していたのと同じ認証方法を引き続き使用することになります。If guest users have already redeemed invitations from you, and you subsequently set up direct federation with their organization, those guest users will continue to use the same authentication method they used before you set up direct federation.
  • 取引先組織との直接フェデレーションを設定してゲスト ユーザーを招待し、それ以降にその取引先組織が Azure AD に移行した場合、ご自身のテナント内に直接フェデレーション ポリシーが存在する限り、既に招待を利用済みのゲスト ユーザーは、引き続き直接フェデレーションを使用します。If you set up direct federation with a partner organization and invite guest users, and then the partner organization later moves to Azure AD, the guest users who have already redeemed invitations will continue to use direct federation, as long as the direct federation policy in your tenant exists.
  • 取引先組織との直接フェデレーションを削除すると、直接フェデレーションを現在使用しているすべてのゲスト ユーザーがサインインできなくなります。If you delete direct federation with a partner organization, any guest users currently using direct federation will be unable to sign in.

これらのどのシナリオでも、ご自身のディレクトリからゲスト ユーザー アカウントを削除してから再招待することで、ゲスト ユーザーの認証方法を更新できます。In any of these scenarios, you can update a guest user’s authentication method by deleting the guest user account from your directory and reinviting them.

直接フェデレーションは、contoso.com や fabrikam.com などのドメイン名前空間に関連付けられます。Direct federation is tied to domain namespaces, such as contoso.com and fabrikam.com. 組織では、AD FS またはサード パーティの IdP との直接フェデレーション構成を確立するときに、これらの Idp に 1 つまたは複数のドメイン名前空間を関連付けます。When establishing a direct federation configuration with AD FS or a third-party IdP, organizations associate one or more domain namespaces to these IdPs.

エンド ユーザー エクスペリエンスEnd-user experience

直接フェデレーションを使用すると、ご自身の Azure AD テナントに、ゲスト ユーザーが各自の組織アカウントを使用してサインインします。With direct federation, guest users sign into your Azure AD tenant using their own organizational account. 共有リソースへのアクセス時にサインインを求められると、直接フェデレーションのユーザーは IdP にリダイレクトされます。When they are accessing shared resources and are prompted for sign-in, direct federation users are redirected to their IdP. サインインが成功した後、Azure AD に戻ってリソースにアクセスします。After successful sign-in, they are returned to Azure AD to access resources. 直接フェデレーションのユーザーの更新トークン有効期間は 12 時間です。これは、Azure AD でのパススルー更新トークンの既定の長さです。Direct federation users’ refresh tokens are valid for 12 hours, the default length for passthrough refresh token in Azure AD. 連携した IdP で SSO が有効な場合、ユーザーは SSO を体験することになり、初回認証後にサインインを求めるメッセージは表示されません。If the federated IdP has SSO enabled, the user will experience SSO and will not see any sign-in prompt after initial authentication.

制限事項Limitations

Azure AD での DNS 検証済みドメインDNS-verified domains in Azure AD

フェデレーションを行うドメインは、Azure AD で DNS 検証済みでないことが必要です。The domain you want to federate with must not be DNS-verified in Azure AD. 直接フェデレーションは、アンマネージド (電子メールで検証済み、または "バイラル") の Azure AD テナントで設定できます。理由は、それらが DNS で検証されないためです。You're allowed to set up direct federation with unmanaged (email-verified or "viral") Azure AD tenants because they aren't DNS-verified.

認証 URLAuthentication URL

直接フェデレーションをポリシーで使用できるのは、認証 URL のドメインがターゲット ドメインと一致する場合か、認証 URL がこれらの許可されている ID プロバイダーのうちの 1 つである場合のみです (この一覧は変更される場合があります)。Direct federation is only allowed for policies where the authentication URL’s domain matches the target domain, or where the authentication URL is one of these allowed identity providers (this list is subject to change):

  • accounts.google.comaccounts.google.com
  • pingidentity.compingidentity.com
  • login.pingone.comlogin.pingone.com
  • okta.comokta.com
  • oktapreview.comoktapreview.com
  • okta-emea.comokta-emea.com
  • my.salesforce.commy.salesforce.com
  • federation.exostar.comfederation.exostar.com
  • federation.exostartest.comfederation.exostartest.com

たとえば、fabrikam.com に対して直接フェデレーションを設定する場合、https://fabrikam.com/adfs という認証 URL は検証に合格します。For example, when setting up direct federation for fabrikam.com, the authentication URL https://fabrikam.com/adfs will pass the validation. 同じドメイン内のホストも合格します (たとえば https://sts.fabrikam.com/adfs)。A host in the same domain will also pass, for example https://sts.fabrikam.com/adfs. ただし、同じドメインの https://fabrikamconglomerate.com/adfs または https://fabrikam.com.uk/adfs という認証 URL は、合格しません。However, the authentication URL https://fabrikamconglomerate.com/adfs or https://fabrikam.com.uk/adfs for the same domain won't pass.

署名証明書の更新Signing certificate renewal

ID プロバイダーの設定でメタデータ URL を指定した場合、署名証明書が有効期限切れになると、Azure AD によって自動的に更新されます。If you specify the metadata URL in the identity provider settings, Azure AD will automatically renew the signing certificate when it expires. ただし、証明書が有効期限切れになる前に何らかの理由でローテーションされた場合、またはメタデータ URL を指定しなかった場合には、Azure AD による更新はできません。However, if the certificate is rotated for any reason before the expiration time, or if you don't provide a metadata URL, Azure AD will be unable to renew it. この場合、署名証明書を手動で更新する必要があります。In this case, you'll need to update the signing certificate manually.

フェデレーション リレーションシップの制限Limit on federation relationships

現在のところ、最大 1000 のフェデレーション リレーションシップがサポートされています。Currently, a maximum of 1,000 federation relationships is supported. この制限には、内部フェデレーションと直接フェデレーションの両方が含まれます。This limit includes both internal federations and direct federations.

複数のドメインに対する制限Limit on multiple domains

現在、同じテナントからの複数のドメインとの直接フェデレーションはサポートされていません。We don’t currently support direct federation with multiple domains from the same tenant.

よく寄せられる質問Frequently asked questions

アンマネージド (電子メールで検証) テナントが存在するドメインとの直接フェデレーションを設定することはできますか。Can I set up direct federation with a domain for which an unmanaged (email-verified) tenant exists?

はい。Yes. ドメインが検証されておらず、テナントで管理者の引き継ぎが実施されていない場合は、そのドメインとの直接フェデレーションを設定することができます。If the domain hasn't been verified and the tenant hasn't undergone an admin takeover, you can set up direct federation with that domain. アンマネージドまたは電子メールで検証済みのテナントは、ユーザーが B2B の招待を利用したとき、または現時点で存在しないドメインを使用して Azure AD のセルフサービス サインアップを実行したときに作成されます。Unmanaged, or email-verified, tenants are created when a user redeems a B2B invitation or performs a self-service sign-up for Azure AD using a domain that doesn’t currently exist. これらのドメインとの直接フェデレーションを設定することができます。You can set up direct federation with these domains. Azure portal 上で、または PowerShell を使用して、DNS で検証済みのドメインとの直接フェデレーションを設定しようとすると、エラーが表示されます。If you try to set up direct federation with a DNS-verified domain, either in the Azure portal or via PowerShell, you'll see an error.

直接フェデレーションと電子メールのワンタイム パスコード認証の両方が有効な場合、どちらの方法が優先されますか。If direct federation and email one-time passcode authentication are both enabled, which method takes precedence?

取引先組織との直接フェデレーションが確立すると、その組織に属する新しいゲスト ユーザーに対して、電子メールのワンタイム パスコード認証よりも直接フェデレーションが優先されます。When direct federation is established with a partner organization, it takes precedence over email one-time passcode authentication for new guest users from that organization. 直接フェデレーションを設定する前に、ゲスト ユーザーがワンタイム パスコード認証を使用して招待を利用した場合、それらのゲスト ユーザーは引き続きワンタイム パスコード認証を使用することになります。If a guest user redeemed an invitation using one-time passcode authentication before you set up direct federation, they'll continue to use one-time passcode authentication.

直接フェデレーションは、部分的に同期されたテナントに起因するサインインの問題に対応していますか。Does direct federation address sign-in issues due to a partially synced tenancy?

いいえ。このシナリオでは、電子メールのワンタイム パスコード機能を使用する必要があります。No, the email one-time passcode feature should be used in this scenario. "部分的に同期されたテナント" とは、オンプレミスのユーザー ID がクラウドに完全には同期されていないパートナーの Azure AD テナントのことです。A “partially synced tenancy” refers to a partner Azure AD tenant where on-premises user identities aren't fully synced to the cloud. クラウド上に ID がまだ存在していないゲストが、B2B の招待を利用しようとした場合、そのゲストはサインインできません。A guest whose identity doesn’t yet exist in the cloud but who tries to redeem your B2B invitation won’t be able to sign in. ワンタイム パスコード機能であれば、このゲストをサインインさせることができます。The one-time passcode feature would allow this guest to sign in. 直接フェデレーション機能は、IdP によって管理される独自の組織アカウントをゲストが持っているが、その組織に Azure AD の存在がまったくないというシナリオに対応しています。The direct federation feature addresses scenarios where the guest has their own IdP-managed organizational account, but the organization has no Azure AD presence at all.

手順 1:取引先組織の ID プロバイダーを構成するStep 1: Configure the partner organization’s identity provider

最初に、取引先組織において、必須の要求と証明書利用者信頼を指定して ID プロバイダーを構成する必要があります。First, your partner organization needs to configure their identity provider with the required claims and relying party trusts.

注意

直接フェデレーション用の ID プロバイダーを構成する方法を示すために、例として Active Directory フェデレーション サービス (AD FS) を使用します。To illustrate how to configure an identity provider for direct federation, we’ll use Active Directory Federation Services (AD FS) as an example. AD FS との直接フェデレーションの構成に関する記事を参照してください。直接フェデレーションの準備として、AD FS を SAML 2.0 または WS-Fed の ID プロバイダーとして構成する方法の例が示されています。See the article Configure direct federation with AD FS, which gives examples of how to configure AD FS as a SAML 2.0 or WS-Fed identity provider in preparation for direct federation.

SAML 2.0 の構成SAML 2.0 configuration

Azure AD B2B は、以下に示す特定の要件に従って、SAML プロトコルを使用する ID プロバイダーと連携するように構成できます。Azure AD B2B can be configured to federate with identity providers that use the SAML protocol with specific requirements listed below. ご利用の SAML ID プロバイダーと Azure AD の間に信頼を設定する方法の詳細については、「シングル サインオンに SAML 2.0 ID プロバイダー (IdP) を使用する」を参照してください。For more information about setting up a trust between your SAML identity provider and Azure AD, see Use a SAML 2.0 Identity Provider (IdP) for Single Sign-On.

注意

直接フェデレーションのターゲット ドメインを Azure AD 上で DNS によって検証することはできません。The target domain for direct federation must not be DNS-verified on Azure AD. 認証 URL のドメインは、ターゲット ドメインに一致する必要があります。または、許可されている ID プロバイダーのドメインである必要があります。The authentication URL domain must match the target domain or it must be the domain of an allowed identity provider. 詳細については、「制限事項」のセクションを参照してください。See the Limitations section for details.

必須の SAML 2.0 属性および要求Required SAML 2.0 attributes and claims

次の表では、サード パーティの ID プロバイダーに構成する必要がある、特定の属性と要求の要件を示します。The following tables show requirements for specific attributes and claims that must be configured at the third-party identity provider. 直接フェデレーションを設定するには、ID プロバイダーからの SAML 2.0 応答において以下の属性が受け取られる必要があります。To set up direct federation, the following attributes must be received in the SAML 2.0 response from the identity provider. これらの属性は、オンライン セキュリティ トークン サービスの XML ファイルにリンクするか手動で入力することによって、構成できます。These attributes can be configured by linking to the online security token service XML file or by entering them manually.

IdP からの SAML 2.0 応答に必須の属性:Required attributes for the SAML 2.0 response from the IdP:

属性Attribute Value
AssertionConsumerServiceAssertionConsumerService https://login.microsoftonline.com/login.srf
対象ユーザーAudience urn:federation:MicrosoftOnline
発行者Issuer パートナー IdP の発行者 URI (たとえば http://www.example.com/exk10l6w90DHM0yi...)The issuer URI of the partner IdP, for example http://www.example.com/exk10l6w90DHM0yi...

IdP によって発行される SAML 2.0 トークンに必須の要求:Required claims for the SAML 2.0 token issued by the IdP:

属性Attribute Value
NameID の形式NameID Format urn:oasis:names:tc:SAML:2.0:nameid-format:persistent
emailaddressemailaddress http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress

WS-Fed の構成WS-Fed configuration

Azure AD B2B は、以下に示すいくつかの特定の要件に従って、WS-Fed プロトコルを使用する ID プロバイダーと連携するように構成できます。Azure AD B2B can be configured to federate with identity providers that use the WS-Fed protocol with some specific requirements as listed below. 現時点で 2 つの WS-Fed プロバイダー (AD FS と Shibboleth) が、Azure AD との互換性テスト済みです。Currently, the two WS-Fed providers have been tested for compatibility with Azure AD include AD FS and Shibboleth. WS-Fed 準拠のプロバイダーと Azure AD の間に証明書利用者信頼を確立する方法の詳細については、Azure AD ID プロバイダーの互換性に関するドキュメントで「STS Integration Paper using WS Protocols」(WS プロトコルを使用した STS 統合に関する文書) を参照してください。For more information about establishing a relying party trust between a WS-Fed compliant provider with Azure AD, see the "STS Integration Paper using WS Protocols" available in the Azure AD Identity Provider Compatibility Docs.

注意

直接フェデレーションのターゲット ドメインを Azure AD 上で DNS によって検証することはできません。The target domain for direct federation must not be DNS-verified on Azure AD. 認証 URL のドメインは、ターゲット ドメインまたは許可されている ID プロバイダーのドメインに一致する必要があります。The authentication URL domain must match either the target domain or the domain of an allowed identity provider. 詳細については、「制限事項」のセクションを参照してください。See the Limitations section for details.

必須の WS-Fed 属性および要求Required WS-Fed attributes and claims

次の表では、サード パーティの WS-Fed ID プロバイダーに構成する必要がある、特定の属性と要求の要件を示します。The following tables show requirements for specific attributes and claims that must be configured at the third-party WS-Fed identity provider. 直接フェデレーションを設定するには、ID プロバイダーからの WS-Fed メッセージにおいて以下の属性が受け取られる必要があります。To set up direct federation, the following attributes must be received in the WS-Fed message from the identity provider. これらの属性は、オンライン セキュリティ トークン サービスの XML ファイルにリンクするか手動で入力することによって、構成できます。These attributes can be configured by linking to the online security token service XML file or by entering them manually.

IdP からの WS-Fed メッセージに必須の属性:Required attributes in the WS-Fed message from the IdP:

属性Attribute Value
PassiveRequestorEndpointPassiveRequestorEndpoint https://login.microsoftonline.com/login.srf
対象ユーザーAudience urn:federation:MicrosoftOnline
発行者Issuer パートナー IdP の発行者 URI (たとえば http://www.example.com/exk10l6w90DHM0yi...)The issuer URI of the partner IdP, for example http://www.example.com/exk10l6w90DHM0yi...

IdP によって発行される WS-Fed トークンに必須の要求:Required claims for the WS-Fed token issued by the IdP:

属性Attribute Value
ImmutableIDImmutableID http://schemas.microsoft.com/LiveID/Federation/2008/05/ImmutableID
emailaddressemailaddress http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress

手順 2:Azure AD で直接フェデレーションを構成するStep 2: Configure direct federation in Azure AD

次に、手順 1 で構成した ID プロバイダーとのフェデレーションを Azure AD 上で構成します。Next, you'll configure federation with the identity provider configured in step 1 in Azure AD. Azure AD ポータルまたは PowerShell のいずれかを使用できます。You can use either the Azure AD portal or PowerShell. 直接フェデレーション ポリシーが有効になるまで 5 分から 10 分かかる場合があります。It might take 5-10 minutes before the direct federation policy takes effect. この間、直接フェデレーション ドメインの招待を利用することを試みないでください。During this time, don't attempt to redeem an invitation for the direct federation domain. 次の属性は必須です。The following attributes are required:

  • パートナー IdP の発行者 URIIssuer URI of partner IdP
  • パートナー IdP のパッシブ認証エンドポイント (サポートされているのは https のみ)Passive authentication endpoint of partner IdP (only https is supported)
  • CertificateCertificate

Azure AD ポータルで直接フェデレーションを構成するにはTo configure direct federation in the Azure AD portal

  1. Azure ポータルにアクセスします。Go to the Azure portal. 左ウィンドウで、 [Azure Active Directory] を選択します。In the left pane, select Azure Active Directory.

  2. [外部 ID] > [すべての ID プロバイダー] を選択します。Select External Identities > All identity providers.

  3. 選択し、次に [新しい SAML/WS-Fed IdP] を選択します。Select , and then select New SAML/WS-Fed IdP.

    新しい SAML または WS-Fed IdP を追加するためのボタンを示すスクリーンショット

  4. [新しい SAML/WS-Fed IdP] ページの [ID プロバイダー プロトコル] で、 [SAML] または [WS-FED] を選択します。On the New SAML/WS-Fed IdP page, under Identity provider protocol, select SAML or WS-FED.

    SAML または WS-Fed IdP ページの解析ボタンを示すスクリーンショット

  5. 取引先組織のドメイン名を入力します。これは直接フェデレーションのターゲット ドメイン名になります。Enter your partner organization’s domain name, which will be the target domain name for direct federation

  6. メタデータの詳細を設定するメタデータ ファイルをアップロードすることができます。You can upload a metadata file to populate metadata details. メタデータを手動で入力する場合は、次の情報を入力します。If you choose to input metadata manually, enter the following information:

    • パートナー IdP のドメイン名Domain name of partner IdP
    • パートナー IdP のエンティティ IDEntity ID of partner IdP
    • パートナー IdP のパッシブな要求元エンドポイントPassive requestor endpoint of partner IdP
    • CertificateCertificate

    注意

    メタデータ URL は省略可能ですが、強くお勧めします。Metadata URL is optional, however we strongly recommend it. メタデータ URL を指定すると、署名証明書が有効期限切れになったときに、Azure AD によって自動的に更新することができます。If you provide the metadata URL, Azure AD can automatically renew the signing certificate when it expires. 証明書が有効期限切れになる前に何らかの理由でローテーションされた場合、またはメタデータ URL を指定しなかった場合には、Azure AD による更新はできません。If the certificate is rotated for any reason before the expiration time or if you do not provide a metadata URL, Azure AD will be unable to renew it. この場合、署名証明書を手動で更新する必要があります。In this case, you'll need to update the signing certificate manually.

  7. [保存] を選択します。Select Save.

PowerShell を使用して Azure AD で直接フェデレーションを構成するにはTo configure direct federation in Azure AD using PowerShell

  1. 最新バージョンの Azure AD PowerShell for Graph モジュールをインストールします (AzureADPreview)。Install the latest version of the Azure AD PowerShell for Graph module (AzureADPreview). (詳細な手順が必要な場合は、ゲスト ユーザー追加のクイックスタートに、「最新の AzureADPreview モジュールをインストールする」セクションがあります。)(If you need detailed steps, the quickstart for adding a guest user includes the section Install the latest AzureADPreview module.)

  2. 次のコマンドを実行します。Run the following command:

    Connect-AzureAD
    
  3. サインイン プロンプトで、マネージド グローバル管理者アカウントを使用してサインインします。At the sign-in prompt, sign in with the managed Global Administrator account.

  4. フェデレーション メタデータ ファイルにある値に置き換えたうえで、次のコマンドを実行します。Run the following commands, replacing the values from the federation metadata file. AD FS サーバーと Okta の場合、フェデレーション ファイルは federationmetadata.xml です (例: https://sts.totheclouddemo.com/federationmetadata/2007-06/federationmetadata.xml)。For AD FS Server and Okta, the federation file is federationmetadata.xml, for example: https://sts.totheclouddemo.com/federationmetadata/2007-06/federationmetadata.xml.

    $federationSettings = New-Object Microsoft.Open.AzureAD.Model.DomainFederationSettings
    $federationSettings.PassiveLogOnUri ="https://sts.totheclouddemo.com/adfs/ls/"
    $federationSettings.LogOffUri = $federationSettings.PassiveLogOnUri
    $federationSettings.IssuerUri = "http://sts.totheclouddemo.com/adfs/services/trust"
    $federationSettings.MetadataExchangeUri="https://sts.totheclouddemo.com/adfs/services/trust/mex"
    $federationSettings.SigningCertificate= <Replace with X509 signing cert’s public key>
    $federationSettings.PreferredAuthenticationProtocol="WsFed" OR "Samlp"
    $domainName = <Replace with domain name>
    New-AzureADExternalDomainFederation -ExternalDomainName $domainName  -FederationSettings $federationSettings
    

手順 3:Azure AD で直接フェデレーションをテストするStep 3: Test direct federation in Azure AD

次に、新しい B2B ゲスト ユーザーを招待して直接フェデレーションの設定をテストします。Now test your direct federation setup by inviting a new B2B guest user. 詳細については、「Azure Portal で Azure Active Directory B2B コラボレーション ユーザーを追加する」を参照してください。For details, see Add Azure AD B2B collaboration users in the Azure portal.

直接フェデレーション関係を編集する方法How do I edit a direct federation relationship?

  1. Azure ポータルにアクセスします。Go to the Azure portal. 左ウィンドウで、 [Azure Active Directory] を選択します。In the left pane, select Azure Active Directory.
  2. [外部 ID] を選択します。Select External Identities.
  3. [すべての ID プロバイダー] を選択しますSelect All identity providers
  4. SAML/WS-Fed ID プロバイダー でプロバイダーを選択します。Under SAML/WS-Fed identity providers, select the provider.
  5. ID プロバイダーの詳細ウィンドウで、値を更新します。In the identity provider details pane, update the values.
  6. [保存] を選択します。Select Save.

直接フェデレーションを削除する方法How do I remove direct federation?

直接フェデレーション設定を削除できます。You can remove your direct federation setup. 実行した場合、既に招待を利用済みの直接フェデレーションのゲスト ユーザーは、サインインできなくなります。If you do, direct federation guest users who have already redeemed their invitations won't be able to sign in. しかし、ディレクトリから削除し、再招待することで、リソースへのアクセス権をもう一度付与することができます。But you can give them access to your resources again by deleting them from the directory and reinviting them. Azure AD ポータルで ID プロバイダーとの直接フェデレーションを削除するには:To remove direct federation with an identity provider in the Azure AD portal:

  1. Azure ポータルにアクセスします。Go to the Azure portal. 左ウィンドウで、 [Azure Active Directory] を選択します。In the left pane, select Azure Active Directory.
  2. [外部 ID] を選択します。Select External Identities.
  3. [すべての ID プロバイダー] を選択します。Select All identity providers.
  4. ID プロバイダーを選択し、 [削除] を選択します。Select the identity provider, and then select Delete.
  5. [はい] を選択して削除を確定します。Select Yes to confirm deletion.

PowerShell を使用して ID プロバイダーとの直接フェデレーションを削除するには:To remove direct federation with an identity provider by using PowerShell:

  1. 最新バージョンの Azure AD PowerShell for Graph モジュールをインストールします (AzureADPreview)。Install the latest version of the Azure AD PowerShell for Graph module (AzureADPreview).
  2. 次のコマンドを実行します。Run the following command:
    Connect-AzureAD
    
  3. サインイン プロンプトで、マネージド グローバル管理者アカウントを使用してサインインします。At the sign-in prompt, sign in with the managed Global Administrator account.
  4. 次のコマンドを入力します。Enter the following command:
    Remove-AzureADExternalDomainFederation -ExternalDomainName  $domainName