認証の管理

完了

Power Platform 認証には、一連の要求、応答、およびユーザーのブラウザーと Power Platform または Azure サービスの間のリダイレクトが関与します。 この順序は、Microsoft Entra ID 認証コード付与フローに従います。

ユーザー アカウントを設定および管理する際は、Microsoft 365 の次の 3 つの主要 ID モデルを選択できます。

  • クラウド ID: Microsoft 365 のみでユーザー アカウントを管理します。 ユーザーの管理にオンプレミス サーバーは必要ありません。すべてクラウドで管理します。

  • 同期 ID: オンプレミスのディレクトリ オブジェクトと Microsoft 365 を同期し、オンプレミスでユーザーを管理します。 ユーザーがオンプレミスとクラウドで同じパスワードを使用できるように、パスワードを同期することもできますが、ユーザーは Microsoft 365 を使用する際に再度サインインすることが必要になります。

  • フェデレーション ID: オンプレミスのディレクトリ オブジェクトと Microsoft 365 を同期し、オンプレミスでユーザーを管理します。 ユーザーはオンプレミスとクラウドで同じパスワードを使用し、再度サインインしなくても Microsoft 365 を使用できます。 一般的にシングル サインオンと呼ばれる方式です。

運用を開始する際に、どの ID モデルを使用するかを慎重に検討することが重要です。 時間、既存環境の複雑さ、コストを考慮します。 これらの要因は組織ごとに異なります。 どのモデルを選択するかは、会社の規模と、IT リソースの深さや幅広さに大きく左右されます。

Microsoft 365 の ID と Microsoft Entra ID について

Microsoft 365 では、クラウドベースのユーザー ID と認証サービスの Microsoft Entra ID を使用してユーザーを管理します。 ID 管理をオンプレミスの組織で構成するか、Microsoft 365 で構成するかは早い段階で決めます。それがクラウド インフラストラクチャの基盤を形成する一要素になります。 この構成は後で変更することが困難な場合もあるため、組織のニーズに最適な方法を慎重に検討し、選択しましょう。

Microsoft 365 では、クラウド認証フェデレーション認証の 2 つの主要認証モデルのどちらかを選択して、ユーザー アカウントの設定と管理を行います。

クラウド認証

Active Directory の既存のオンプレミス環境があるかどうかによって、Microsoft 365 でユーザーの認証と ID サービスを管理する方法がいくつかあります。

クラウドのみ

クラウドのみのモデルでは、Microsoft 365 のみでユーザー アカウントを管理します。 オンプレミス サーバーは必要ありません。Microsoft Entra ID によって、すべてクラウドで処理されます。 Microsoft 365 管理センターか、Windows PowerShell の PowerShell コマンドレットを使用して、ユーザーを作成および管理します。ID と認証は、Microsoft Entra ID によってすべてクラウドで処理されます。

一般的にクラウドのみのモデルは次の場合に適しています。

  • 他にオンプレミスのユーザー ディレクトリがない。

  • 複雑なオンプレミス ディレクトリがあり、それを統合する作業は避けたい。

  • 既存のオンプレミス ディレクトリがあるが、Microsoft 365 の試用版またはパイロット版を実行したい。 後でオンプレミス ディレクトリに接続する準備が整ったら、クラウドのユーザーとオンプレミスのユーザーを照合できます。

シームレスなシングル サインオンによるパスワード ハッシュの同期

Microsoft Entra ID でオンプレミスのディレクトリ オブジェクト用の認証を有効にする最も簡単な方法です。 パスワード ハッシュ同期 (PHS) を使用すると、オンプレミスの Active Directory ユーザー アカウント オブジェクトと Microsoft 365 を同期し、オンプレミスでユーザーを管理できます。 ユーザーのパスワード ハッシュは、オンプレミスの Active Directory から Microsoft Entra ID に同期されるため、ユーザーはオンプレミスとクラウドで同じパスワードを使用できます。 オンプレミスでパスワードが変更またはリセットされた場合は、新しいパスワード ハッシュが Microsoft Entra ID に同期されるため、ユーザーはクラウド リソースとオンプレミス リソースで常に同じパスワードを使用できます。 パスワードがクリア テキスト形式で Microsoft Entra ID に送信されたり、Microsoft Entra ID に格納されたりすることはありません。 ID の保護など、Microsoft Entra ID の一部のプレミアム機能を使用するためには、どの認証方法を選択した場合でも PHS が必要になります。 シームレスなシングル サインオンによって、ユーザーは会社のデバイスを使用して会社のネットワークに接続すると、自動的に Microsoft Entra ID にサインインします。

シームレスなシングル サインオンによるパススルー認証

1 つ以上のオンプレミス サーバーで実行されるソフトウェア エージェントを使用して、オンプレミスの Active Directory で直接ユーザーを検証する Microsoft Entra ID 認証サービス用のシンプルなパスワード検証を提供します。 パススルー認証 (PTA) では、オンプレミスの Active Directory ユーザー アカウント オブジェクトを Microsoft 365 と同期し、オンプレミスでユーザーを管理します。 ユーザーはオンプレミスのアカウントとパスワードを使用して、オンプレミスと Microsoft 365 の両方のリソースやアプリケーションにサインインできます。 この構成では、パスワード ハッシュを Microsoft 365 に送信せずに、オンプレミスの Active Directory に対してユーザー パスワードが直接検証されます。 セキュリティの観点から、オンプレミスのユーザー アカウントの状態、パスワード ポリシー、サインイン時間をすぐに適用する必要がある企業の場合は、この認証方法が適しています。 シームレスなシングル サインオンによって、ユーザーは会社のデバイスを使用して会社のネットワークに接続すると、自動的に Microsoft Entra ID にサインインします。

シングル サインオン

Dynamics 365 Online では、既定で認証には Microsoft Entra ID が使用されますが、世界中の多くの組織はローカル Active Directory を使用して社内で認証を処理しています。

Microsoft Entra ID のシームレスなシングル サインオン (Microsoft Entra シームレス SSO) では、ユーザーは会社のデバイスを使用して会社のネットワークに接続すると、自動的にサインインします。 この機能を有効にすると、ユーザーはパスワードを入力しなくても Microsoft Entra にサインインできます。通常はユーザー名を入力する必要もありません。 この機能を使用すると、オンプレミス コンポーネントを追加しなくても、ユーザーはクラウドベースのアプリケーションに簡単にアクセスできます。

シームレス SSO は、パスワード ハッシュの同期またはパススルー認証のサインイン方式と組み合わせることができます。 シームレス SSO は、Active Directory フェデレーション サービス (ADFS) には適用されません*。

パスワード ハッシュの同期およびパススルー認証方式を使用したシームレス シングル サインオンの図。

シームレス SSO を使用するには、ユーザーのデバイスがドメイン参加している必要がありますが、Microsoft Entra 参加済みである必要はありません。

主な利点

  • 優れたユーザー エクスペリエンス

    • ユーザーはオンプレミスとクラウドベースの両方のアプリケーションに自動的にサインインします。

    • ユーザーはパスワードを何度も入力する必要がありません。

  • 展開および管理が容易です。他のオンプレミス コンポーネントは必要はありません。

重要ポイント

  • サインイン用のユーザー名には、オンプレミスの既定のユーザー名 (userPrincipalName) か、Microsoft Entra Connect で構成された別の属性 (代替 ID) を指定できます。 どちらの方法でも使用できます。シームレス SSO では、Kerberos チケットの securityIdentifier 要求を使用して Microsoft Entra ID の対応するユーザー オブジェクトを参照するためです。

  • シームレス SSO は便宜的な機能です。 なんらかの理由で実行に失敗した場合は、ユーザーのサインイン エクスペリエンスは通常の動作に戻ります。つまり、ユーザーはサインイン ページでパスワードを入力する必要があります。

  • Microsoft Entra のサインイン要求で、アプリケーション (例:https://myapps.microsoft.com/contoso.com) によって domain_hint (OpenID Connect) または whr (SAML) パラメーターが転送され、テナントまたは login_hint パラメーターの識別や、ユーザーの識別が行われる場合は、ユーザーはユーザー名やパスワードを入力しなくても自動的にサインインできます。

  • アプリケーション (例:https://contoso.crm.dynamics.com) によってサインイン要求が Microsoft Entra のテナント型エンドポイント (Microsoft Entra の共通エンドポイントのhttps://login.microsoftonline.com/common ではなく、https://login.microsoftonline.com/contoso.com または https://login.microsoftonline.com <tenant_ID>) に送信される場合でも、ユーザーにはサイレント サインオン エクスペリエンスが提供されます。

  • サインアウトがサポートされています。 そのため、ユーザーはシームレス SSO による自動サインインの代わりに、別の Microsoft Entra ID アカウントを選択してサインインできます。

  • Microsoft 365 Win32 クライアント (Outlook、Word、Excel など) のバージョン 16.0.8730.xxxx 以降は、非インタラクティブ フローを使用することでサポートされます。 OneDrive でサイレント サインオン エクスペリエンスを利用する場合は、OneDrive のサイレント構成機能をアクティブにする必要があります。

  • この機能は Microsoft Entra コネクトで有効にできます。

  • 無料の機能であるため、Microsoft Entra ID の有料版は必要ありません。

単一 AD フォレスト環境をクラウドにフェデレーションする

次のチュートリアルでは、フェデレーションを使用してハイブリッド ID 管理環境を作成する方法について説明します。 この環境は、テストを行うためや、ハイブリッド ID のしくみを詳しく理解するために使用できます。

チュートリアル: 単一 AD フォレスト環境をクラウドにフェデレーションする

Microsoft Entra の条件付きアクセス

Microsoft Entra ID での最も単純な条件付きアクセス ポリシーは、if-then ステートメントです: ユーザーがリソースにアクセスする場合 (if) は、アクションを実行する必要があります (then)。

例: 給与マネージャーが、Power Apps でビルドされた給与アプリにアクセスしたいときは、多要素認証を実行する必要があります。

管理者は次の 2 つの主な目標に直面しています。

  • ユーザーがどこでも、いつでも生産性を高められるようにする。

  • 組織の資産を保護する。

条件付きアクセス ポリシーを使用することで、組織のセキュリティを確保するために必要に応じて適切なアクセス制御を適用し、不要なときは適用しないことを選択できます。 条件付きアクセス ポリシーは、1 つ目の要素認証の完了後に適用されます。

条件付きアクセス ポリシーを構成できるのは、グローバル管理者のみです。 Microsoft Power Platform 管理者または Dynamics 365 管理者は、これを行うことができません。

条件付きアクセス プロセス フローの概念図。

条件付きアクセス ポリシーの設定方法については、条件付きアクセスの展開の計画を参照してください。