ハイブリッド ID 導入戦略の定義Define a hybrid identity adoption strategy

このタスクでは、次のトピックで検討したビジネス要件を満たすために、ハイブリッド ID ソリューションのハイブリッド ID 導入戦略を定義します。In this task, you define the hybrid identity adoption strategy for your hybrid identity solution to meet the business requirements that were discussed in:

ビジネス ニーズ戦略の定義Define business needs strategy

最初のタスクでは、組織のビジネス ニーズの決定に対応します。The first task addresses determining the organizations business needs. 組織のビジネス ニーズは非常に多岐にわたり、注意を怠るとスコープ クリープが発生する可能性があります。This can be very broad and scope creep can occur if you are not careful. 最初はシンプルさを心がけながら、今後の変更に対応し、容易にするような設計の計画を常に意識してください。In the beginning, keep it simple but always remember to plan for a design that will accommodate and facilitate change in the future. 設計がシンプルか複雑かを問わず、Azure Active Directory は、Office 365、Microsoft Online Services、クラウド対応アプリケーションをサポートする Microsoft ID プラットフォームです。Regardless of whether it is a simple design or an extremely complex one, Azure Active Directory is the Microsoft Identity platform that supports Office 365, Microsoft Online Services, and cloud aware applications.

統合戦略の定義Define an integration strategy

マイクロソフトでは、クラウド ID、同期済み ID、フェデレーション ID の 3 つの主な統合シナリオを用意しています。Microsoft has three main integration scenarios which are cloud identities, synchronized identities, and federated identities. これらの統合戦略の 1 つを導入する計画を行う必要があります。You should plan on adopting one of these integration strategies. 選択する戦略はさまざまで、選択の決定要因には、どのようなタイプのユーザー エクスペリエンスを提供するか、既存のインフラストラクチャがあるか、何が最もコスト効率に優れているか、などがあります。The strategy you choose can vary and the decisions in choosing one may include, what type of user experience you want to provide, do you have an existing infrastructure, and what is the most cost effective.

統合シナリオ

上の図で定義されているシナリオは、次のとおりです。The scenarios defined in the above figure are:

  • クラウド ID: クラウドのみに存在する ID です。Cloud identities: these are identities that exist solely in the cloud. Azure AD の場合は、具体的に Azure AD ディレクトリ内に存在します。In the case of Azure AD, they would reside specifically in your Azure AD directory.
  • 同期済み: オンプレミスとクラウドに存在する ID です。Synchronized: these are identities that exist on-premises and in the cloud. Azure AD Connect を使用すると、これらのユーザーは作成されるか、既存の Azure AD アカウントと結合されます。Using Azure AD Connect, these users are either created or joined with existing Azure AD accounts. ユーザーのパスワードは、パスワード ハッシュと呼ばれるものを使用して、オンプレミスの環境からクラウドに同期されます。The user’s password hash is synchronized from the on-premises environment to the cloud in what is called a password hash. 同期済みのものを使用する場合の注意点として、オンプレミス環境でユーザーが無効にされた場合に、そのアカウントの状態が Azure AD に反映されるまでに最大 3 時間かかることがあります。When using synchronized the one caveat is that if a user is disabled in the on-premises environment, it can take up to three hours for that account status to show up in Azure AD. 同期時間の間隔がその原因です。This is due to the synchronization time interval.
  • フェデレーション: これらの ID は、オンプレミスとクラウドの両方に存在します。Federated: these identities exist both on-premises and in the cloud. Azure AD Connect を使用すると、これらのユーザーは作成されるか、既存の Azure AD アカウントと結合されます。Using Azure AD Connect, these users are either created or joined with existing Azure AD accounts.

注意

同期オプションの詳細については、オンプレミス ID と Azure Active Directory の統合に関するページをお読みください。For more information about the Synchronization options, read Integrating your on-premises identities with Azure Active Directory.

次の表は、各戦略の長所と短所を把握するのに役立ちます。The following table helps in determining the advantages and disadvantages of each of the following strategies:

戦略Strategy 長所Advantages 短所Disadvantages
クラウド IDCloud identities 小規模な組織の管理がさらに容易になります。Easier to manage for small organization.
オンプレミスでインストールするものはありません。Nothing to install on-premises. 追加のハードウェアは必要ありませんNo additional hardware needed
ユーザーが退職した場合、容易に無効にすることができますEasily disabled if the user leaves the company
ユーザーは、クラウド内のワークロードにアクセスするときにサインインする必要がありますUsers will need to sign in when accessing workloads in the cloud
クラウド ID とオンプレミスの ID で、パスワードが同じ場合と異なる場合がありますPasswords may or may not be the same for cloud and on-premises identities
同期済みSynchronized オンプレミスのパスワードにより、オンプレミスとクラウドの両方のディレクトリを認証しますOn-premises password authenticates both on-premises and cloud directories
小規模、中規模、または大規模の組織での管理がさらに容易になりますEasier to manage for small, medium, or large organizations
ユーザーは一部のリソースにシングル サインオン (SSO) できますUsers can have single sign-on (SSO) for some resources
マイクロソフトが推奨する同期方法ですMicrosoft preferred method for synchronization
管理がさらに容易になりますEasier to manage
お客様によっては、企業ごとのポリシーにより、クラウドと自社ディレクトリの同期を積極的に行わない場合があります。Some customers may be reluctant to synchronize their directories with the cloud due specific company’s police
フェデレーションFederated ユーザーはシングル サインオン (SSO) できますUsers can have single sign-on (SSO)
ユーザーが解雇されたり退職したりした場合、アカウントを即座に無効にしてアクセスを取り消すことができますIf a user is terminated or leaves, the account can be immediately disabled and access revoked,
同期では実現できない高度なシナリオをサポートしますSupports advanced scenarios that cannot be accomplished with synchronized
設定および構成の手順が多くなりますMore steps to set up and configure
高度なメンテナンスが必要ですHigher maintenance
STS インフラストラクチャ用に追加のハードウェアが必要な場合がありますMay require additional hardware for the STS infrastructure
フェデレーション サーバーをインストールするために、追加のハードウェアが必要な場合があります。May require additional hardware to install the federation server. AD FS を使用する場合は、追加のソフトウェアが必要ですAdditional software is required if AD FS is used
SSO の広範な設定が必要ですRequire extensive setup for SSO
フェデレーション サーバーがダウンした場合の障害点が重大で、ユーザーの認証ができなくなりますCritical point of failure if the federation server is down, users won’t be able to authenticate

クライアント エクスペリエンスClient experience

使用する戦略は、ユーザーのサインイン エクスペリエンスに影響します。The strategy that you use will dictate the user sign-in experience. 次の表に、ユーザーがサインイン エクスペリエンスに何を求めるかに関する情報を示します。The following tables provide you with information on what the users should expect their sign-in experience to be. すべてのフェデレーション ID プロバイダーが、すべてのシナリオで SSO をサポートするわけではありません。Not all federated identity providers support SSO in all scenarios.

ドメインに参加しているプライベート ネットワーク アプリケーション:Doman-joined and private network applications:

同期済み IDSynchronized Identity フェデレーション IDFederated Identity
Web ブラウザーWeb Browsers フォーム ベース認証Forms-based authentication シングル サインオン。組織 ID の提示が必要な場合がありますsingle sign-on, sometimes required to supply organization ID
OutlookOutlook 資格情報の要求Prompt for credentials 資格情報の要求Prompt for credentials
Skype for Business (Lync)Skype for Business (Lync) 資格情報の要求Prompt for credentials Lync の場合はシングル サインオン。Exchange の場合は資格情報が要求されますsingle sign-on for Lync, prompted credentials for Exchange
OneDrive for BusinessOneDrive for Business 資格情報の要求Prompt for credentials シングル サインオンsingle sign-on
Office Pro Plus サブスクリプションOffice Pro Plus Subscription 資格情報の要求Prompt for credentials シングル サインオンsingle sign-on

外部ソースまたは信頼されていないソース:External or untrusted sources:

同期済み IDSynchronized Identity フェデレーション IDFederated Identity
Web ブラウザーWeb Browsers フォーム ベース認証Forms-based authentication フォーム ベース認証Forms-based authentication
Outlook、Skype for Business (Lync)、OneDrive for Business、Office サブスクリプションOutlook, Skype for Business (Lync), OneDrive for Business, Office subscription 資格情報の要求Prompt for credentials 資格情報の要求Prompt for credentials
Exchange ActiveSyncExchange ActiveSync 資格情報の要求Prompt for credentials Lync の場合はシングル サインオン。Exchange の場合は資格情報が要求されますsingle sign-on for Lync, prompted credentials for Exchange
モバイル アプリMobile apps 資格情報の要求Prompt for credentials 資格情報の要求Prompt for credentials

タスク 1 で、サードパーティ IdP があるか、サード パーティ IdP を使用して Azure AD とフェデレーションを行うことを決定した場合は、次のサポートされる機能を理解しておく必要があります。If you have determined from task 1 that you have a third-party IdP or are going to use one to provide federation with Azure AD, you need to be aware of the following supported capabilities:

  • SP-Lite プロファイルに準拠している SAML 2.0 プロバイダーは、Azure AD および関連するアプリケーションに対する認証をサポートできますAny SAML 2.0 provider that is compliant for the SP-Lite profile can support authentication to Azure AD and associated applications
  • パッシブ認証がサポートされます。これにより、OWA や SPO などに対する認証が容易になります。Supports passive authentication, which facilitates authentication to OWA, SPO, etc.
  • SAML 2.0 Enhanced Client Profile (ECP) を使用して Exchange Online クライアントをサポートできます。Exchange Online clients can be supported via the SAML 2.0 Enhanced Client Profile (ECP)

また、どの機能が使用できないかについても注意が必要です。You must also be aware of what capabilities will not be available:

  • WS-Trust/WS-Federation のサポートがない場合、他のすべてのアクティブなクライアントが停止しますWithout WS-Trust/Federation support, all other active clients break
    • つまり、Lync クライアント、OneDrive クライアント、Office サブスクリプション、Office 2016 以前の Office Mobile がなくなります。That means no Lync client, OneDrive client, Office Subscription, Office Mobile prior to Office 2016
  • Office からパッシブ認証に移行することで、これらのクライアントで純正の SAML 2.0 IdP をサポートできますが、あくまでもクライアント間ベースでのサポートになりますTransition of Office to passive authentication allows them to support pure SAML 2.0 IdPs, but support will still be on a client-by-client basis

注意

最新の一覧については、「Azure AD のフェデレーション互換性リスト」の記事をご覧ください。For the most updated list read the article Azure AD federation compatibility list.

同期戦略の定義Define synchronization strategy

このタスクでは、組織のオンプレミス データとクラウドの同期に使用するツールと、どのようなトポロジを使用する必要があるかを定義します。In this task you will define the tools that will be used to synchronize the organization’s on-premises data to the cloud and what topology you should use. ほとんどの組織で Active Directory を使用しているため、ここでは上記の質問に回答するために、Azure AD Connect の使用に関する詳細情報を示します。Because, most organizations use Active Directory, information on using Azure AD Connect to address the questions above is provided in some detail. Active Directory がない環境向けには、この戦略を計画するための FIM 2010 R2 または MIM 2016 の使用に関する情報を提供します。For environments that do not have Active Directory, there is information about using FIM 2010 R2 or MIM 2016 to help plan this strategy. ただし、Azure AD Connect の今後のリリースで LDAP ディレクトリがサポートされるため、計画のスケジュールによってはこの情報が役に立つ場合があります。However, future releases of Azure AD Connect will support LDAP directories, so depending on your timeline, this information may be able to assist.

同期ツールSynchronization tools

長年にわたり、いくつかの同期ツールが登場し、さまざまなシナリオで使用されています。Over the years, several synchronization tools have existed and used for various scenarios. 現在、サポートされているすべてのシナリオで、Azure AD Connect が主要なツールとして選ばれています。Currently Azure AD Connect is the go to tool of choice for all supported scenarios. AAD Sync や DirSync もまだまだ健在で、現在の環境にも見られます。AAD Sync and DirSync are also still around and may even be present in your environment now.

注意

各ツールでサポートされる機能の最新情報については、記事「 ディレクトリ統合ツールの比較 」をお読みください。For the latest information regarding the supported capabilities of each tool, read Directory integration tools comparison article.

サポートされているトポロジSupported topologies

同期戦略を定義する場合、使用するトポロジを決定する必要があります。When defining a synchronization strategy, the topology that is used must be determined. 手順 2. で決定した情報に基づいて、使用に適したトポロジを決定できます。Depending on the information that was determined in step 2 you can determine which topology is the proper one to use. 単一のフォレスト、単一の Azure AD トポロジが最も一般的で、単一の Active Directory フォレストと Azure AD の単一のインスタンスで構成されます。The single forest, single Azure AD topology is the most common and consists of a single Active Directory forest and a single instance of Azure AD. このトポロジは、多くのシナリオで使用されており、次の図に示すように、Azure AD Connect の高速インストールを使用する場合に想定されるトポロジです。This is going to be used in a majority of the scenarios and is the expected topology when using Azure AD Connect Express installation as shown in the figure below.

サポートされるトポロジ単一フォレスト シナリオでは、図 5 に示すとおり、大規模な組織はもちろんのこと小規模な組織でも複数のフォレストを持つことは一般的です。Supported topologies Single Forest Scenario It is common for large and even small organizations to have multiple forests, as shown in Figure 5.

注意

Azure AD Connect の同期を使用したオンプレミス AD や Azure AD のさまざまなトポロジの詳細については、記事「 Azure AD Connect のトポロジ」をお読みください。For more information about the different on-premises and Azure AD topologies with Azure AD Connect sync read the article Topologies for Azure AD Connect.

複数フォレスト トポロジ

複数フォレストのシナリオMulti-Forest Scenario

次の項目に該当する場合は、複数のフォレストで構成される単一の Azure AD トポロジを検討してください。If this is the case, then the multi-forest single Azure AD topology should be considered if the following items are true:

  • ユーザーの ID がフォレスト全体で 1 つのみである: 詳細については、ユーザーの一意の識別子に関するセクションで後述します。Users have only 1 identity across all forests – the uniquely identifying users section below describes this in more detail.
  • ユーザー ID が配置されているフォレストに対してユーザーの認証を行う。The user authenticates to the forest in which their identity is located
  • UPN とソース アンカー (変更できない ID) がこのフォレストから取得される。UPN and Source Anchor (immutable id) will come from this forest
  • Azure AD Connect からすべてのフォレストにアクセスできる: つまり、ドメインに参加する必要がない。この項目を満たしやすくなる場合は Azure AD Connect を DMZ に配置できます。All forests are accessible by Azure AD Connect – this means it does not need to be domain joined and can be placed in a DMZ if this facilitates this.
  • ユーザーのメールボックスが 1 つのみである。Users have only one mailbox
  • ユーザーのメールボックスをホストするフォレストが、Exchange グローバル アドレス一覧 (GAL) に表示される属性に最適なデータ品質を備えている。The forest that hosts a user’s mailbox has the best data quality for attributes visible in the Exchange Global Address List (GAL)
  • ユーザーにメールボックスがない場合、任意のフォレストを使用してこれらの値を提供できる。If there is no mailbox on the user, then any forest may be used to contribute these values
  • リンクされたメールボックスがある場合、サインインに使用される別のアカウントが異なるフォレストにある。If you have a linked mailbox, then there is also another account in a different forest used to sign in.

注意

クラウドとオンプレミスの両方に存在するオブジェクトは、一意の識別子を使用して "接続" されます。Objects that exist in both on-premises and in the cloud are “connected” via a unique identifier. ディレクトリ同期の場合は、この一意の識別子を SourceAnchor といいます。In the context of Directory Synchronization, this unique identifier is referred to as the SourceAnchor. シングル サインオンの場合は、これを ImmutableId といいます。In the context of Single Sign-On, this is referred to as the ImmutableId. Azure AD Connect の設計概念 」を参照してください。Design concepts for Azure AD Connect for more considerations regarding the use of SourceAnchor.

上記に該当しない場合で、かつアクティブなアカウントまたはメールボックスが複数ある場合は、Azure AD Connect により 1 つだけ選択され、それ以外は無視されます。If the above are not true and you have more than one active account or more than one mailbox, Azure AD Connect will pick one and ignore the other. リンクされたメールボックスはあるが、その他のアカウントがない場合、それらのアカウントは Azure AD にはエクスポートされず、そのユーザーはどのグループのメンバーにもなりません。If you have linked mailboxes but no other account, these accounts will not be exported to Azure AD and that user will not be a member of any groups. これは、以前に DirSync で実施されていた処理とは異なります。このような複数フォレストのシナリオのサポートを向上するための措置です。This is different from how it was in the past with DirSync and is intentional to better support these multi-forest scenarios. 次の図に、複数フォレストのシナリオを示します。A multi-forest scenario is shown in the figure below.

複数の Azure AD テナント

複数のフォレストと複数の Azure AD のシナリオMulti-forest multiple Azure AD scenario

組織で使用する Azure AD のディレクトリは 1 つのみにすることをお勧めしますが、Azure AD Connect の同期サーバーと Azure AD ディレクトリの間で 1:1 の関係が維持されていれば、複数使用するシナリオもサポートされます。It is recommended to have just a single directory in Azure AD for an organization but it is supported it a 1:1 relationship is kept between an Azure AD Connect sync server and an Azure AD directory. Azure AD のインスタンスごとに、Azure AD Connect をインストールする必要があります。For each instance of Azure AD, you need an installation of Azure AD Connect. また、Azure AD は設計上分離されているため、Azure AD の 1 つのインスタンス内のユーザーは、別のインスタンス内のユーザーを表示できません。Also, Azure AD, by design is isolated and users in one instance of Azure AD will not be able to see users in another instance.

次の図に示すように、Active Directory の単一のオンプレミス インスタンスと複数の Azure AD ディレクトリの接続も可能でサポートされています。It is possible and supported to connect one on-premises instance of Active Directory to multiple Azure AD directories as shown in the figure below:

単一フォレストのフィルター処理

単一フォレストのフィルター処理のシナリオSingle-forest filtering scenario

これを行うには、次の項目に該当する必要があります。To do this, the following must be true:

  • 各 Azure AD Connect 同期サーバーは、操作対象のオブジェクトのセットが相互排他的になるようなフィルター処理を構成する必要があります。Azure AD Connect sync servers must be configured for filtering so they each have a mutually exclusive set of objects. たとえば、各サーバーが特定のドメインまたは OU をスコープにするようにします。This done, for example, by scoping each server to a particular domain or OU.
  • DNS ドメインは 1 つの Azure AD ディレクトリにしか登録できないため、オンプレミス AD のユーザーの UPN で個別の名前空間を使用する必要があります。A DNS domain can only be registered in a single Azure AD directory so the UPNs of the users in the on-premises AD must use separate namespaces
  • Azure AD の 1 つのインスタンスのユーザーは、そのインスタンスのユーザーのみを表示できます。Users in one instance of Azure AD will only be able to see users from their instance. 他のインスタンスのユーザーを表示することはできません。They will not be able to see users in the other instances
  • 1 つの Azure AD ディレクトリだけが、オンプレミスの AD を持つ Exchange ハイブリッドを有効にできます。Only one of the Azure AD directories can enable Exchange hybrid with the on-premises AD
  • 相互排他性は書き戻しにも適用されます。Mutual exclusivity also applies to write-back. そのため、単一のオンプレミス構成を前提としている一部の書き戻し機能は、このトポロジではサポートされません。This makes some write-back features not supported with this topology since these assume a single on-premises configuration. これには次のものが含まれますThis includes:
    • 既定の構成によるグループの書き戻しGroup write-back with default configuration
    • デバイスの書き戻しDevice write-back

次はサポートされていません。実装として選択しないでください。The following is not supported and should not be chosen as an implementation:

  • 同じ Azure AD ディレクトリに対する複数の Azure AD Connect 同期サーバーの接続は、同期サーバーが相互に排他的な一連のオブジェクトを同期するように構成されている場合でもサポートされません。It is not supported to have multiple Azure AD Connect sync servers connecting to the same Azure AD directory even if they are configured to synchronize mutually exclusive set of object
  • 複数の Azure AD ディレクトリへの同じユーザーの同期は、サポートされていません。It is unsupported to sync the same user to multiple Azure AD directories.
  • 1 つの Azure AD のユーザーを他の Azure AD ディレクトリで連絡先として表示するような構成の変更もサポートされていません。It is also unsupported to make a configuration change to make users in one Azure AD to appear as contacts in another Azure AD directory.
  • 複数の Azure AD ディレクトリに接続するような Azure AD Connect Sync の変更もサポートされていません。It is also unsupported to modify Azure AD Connect sync to connect to multiple Azure AD directories.
  • Azure AD のディレクトリは、分離するように設計されています。Azure AD directories are by design isolated. ディレクトリ間に共通の統合された GAL を構築しようとする際に他の Azure AD ディレクトリからデータを読み取るような、Azure AD Connect Sync の構成の変更はサポートされていません。It is unsupported to change the configuration of Azure AD Connect sync to read data from another Azure AD directory in an attempt to build a common and unified GAL between the directories. Azure AD Connect Sync を使用している別のオンプレミス AD の連絡先としてユーザーをエクスポートすることもサポートされていません。It is also unsupported to export users as contacts to another on-premises AD using Azure AD Connect sync.

注意

組織でネットワーク上のコンピューターからインターネットへの接続が制限されている場合、次の記事の一覧にあるエンドポイント (FQDN、IPv4 と IPv6 のアドレス範囲) を、クライアント コンピューターの送信許可リストと Internet Explorer の信頼済みサイト ゾーンに追加して、コンピューターで Office 365 を正常に使用できるようにしてください。If your organization restricts computers on your network from connecting to the Internet, this article lists the endpoints (FQDNs, IPv4, and IPv6 address ranges) that you should include in your outbound allow lists and Internet Explorer Trusted Sites Zone of client computers to ensure your computers can successfully use Office 365. 詳細については、「 Office 365 の URL と IP アドレスの範囲」をお読みください。For more information read Office 365 URLs and IP address ranges.

多要素認証戦略の定義Define multi-factor authentication strategy

このタスクでは、使用する多要素認証戦略を定義します。In this task you will define the multi-factor authentication strategy to use. Azure Multi-Factor Authentication では、次の 2 種類のバージョンが用意されています。Azure Multi-Factor Authentication comes in two different versions. 1 つはクラウドベースで、もう 1 つは Azure MFA Server を使用するオンプレミス ベースです。One is a cloud-based and the other is on-premises based using the Azure MFA Server. 上記で行った評価に基づいて、戦略に適したソリューションを決定できます。Based on the evaluation you did above you can determine which solution is the correct one for your strategy. 次の表を使用して、どの設計オプションが企業のセキュリティ要件を最適に満たすかを判断します。Use the table below to determine which design option best fulfills your company’s security requirement:

多要素設計オプション:Multi-factor design options:

セキュリティで保護する資産Asset to secure クラウドでの MFAMFA in the cloud オンプレミスでの MFAMFA on-premises
Microsoft アプリMicrosoft apps はいyes はいyes
アプリ ギャラリー内の SaaS アプリSaaS apps in the app gallery はいyes はいyes
Azure AD アプリケーション プロキシ経由で公開される IIS アプリケーションIIS applications published through Azure AD App Proxy はいyes はいyes
Azure AD アプリケーション プロキシ経由で公開されない IIS アプリケーションIIS applications not published through the Azure AD App Proxy いいえno はいyes
VPN、RDG などのリモート アクセスRemote access as VPN, RDG いいえno はいyes

戦略のソリューションが決定した場合でも、さらに上記の評価を使用して、ユーザーの配置を検討する必要があります。Even though you may have settled on a solution for your strategy, you still need to use the evaluation from above on where your users are located. これにより、ソリューションが変更される可能性があります。This may cause the solution to change. 次の表を使用すると、この決定に役立ちます。Use the table below to assist you determining this:

ユーザーの配置User location 推奨される設計オプションPreferred design option
Azure Active DirectoryAzure Active Directory クラウドでの Multi-Factor AuthenticationMulti-FactorAuthentication in the cloud
AD FS によるフェデレーションを使用した Azure AD とオンプレミスの ADAzure AD and on-premises AD using federation with AD FS 両方Both
Azure AD Connect を使用した Azure AD とオンプレミスの AD。パスワード同期なしAzure AD and on-premises AD using Azure AD Connect no password sync 両方Both
Azure AD Connect を使用した Azure AD とオンプレミスの AD。パスワード同期ありAzure AD and on-premises using Azure AD Connect with password sync 両方Both
オンプレミスの ADOn-premises AD Multi-Factor Authentication ServerMulti-Factor Authentication Server

注意

また、選択した多要素認証の設計オプションで、設計に必要な機能がサポートされていることを確認する必要があります。You should also ensure that the multi-factor authentication design option that you selected supports the features that are required for your design. 詳細については、「 ユーザーに適した多要素のセキュリティ ソリューションの選択」をお読みください。For more information read Choose the multi-factor security solution for you.

Multi-Factor Auth ProviderMulti-Factor Auth Provider

Azure Active Directory テナントを持つグローバル管理者は、既定で多要素認証を使用できます。Multi-factor authentication is available by default for global administrators who have an Azure Active Directory tenant. ただし、すべてのユーザーに多要素認証を拡張する場合や、グローバル管理者が管理ポータル、カスタムの案内応答、レポートなどの機能を利用できるようにする場合は、Multi-Factor Authentication Provider を購入して構成する必要があります。However, if you wish to extend multi-factor authentication to all of your users and/or want to your global administrators to be able to take advantage features such as the management portal, custom greetings, and reports, then you must purchase and configure Multi-Factor Authentication Provider.

注意

また、選択した多要素認証の設計オプションで、設計に必要な機能がサポートされていることを確認する必要があります。You should also ensure that the multi-factor authentication design option that you selected supports the features that are required for your design.

次のステップNext steps

データ保護要件の決定Determine data protection requirements

参照See also

設計上の考慮事項の概要Design considerations overview