シームレスなシングル サインオンを実装する

完了

Contoso IT チームは、ユーザーが SSO を使用してオンプレミスのリソースと Azure のリソースの両方にアクセスできるようにしたいと考えています。 Microsoft Entra シームレス SSO は、パスワード ハッシュ同期またはパススルー認証と共に動作するテクノロジです。

さらに、シームレス SSO が有効になっていると、ユーザーは Microsoft Entra ID にサインインするためにユーザー名を入力する必要はほとんどなく、パスワードを入力する必要は全くありません。 この機能により、Contoso のユーザーは、追加のオンプレミス コンポーネントを必要とせずに、クラウドベースのアプリケーションに簡単にアクセスできるようになります。

パススルー認証でサポートされるシナリオ

Microsoft Entra パススルー認証は、Microsoft Entra ID に依存するサービスがオンプレミスの AD DS インスタンスに対して常にパスワードを検証していることを確かめるのに役立ちます。

Microsoft Entra Connect の構成ウィザードの [構成] ページのスクリーンショット。管理者がパススルー認証を選択し、さらに [シングル サインオンを有効にする] チェックボックスをオンにしています。

外部のパスワード検証要求をリッスンするオンプレミス エージェントを使用する Microsoft Entra Connect を使用することで、Microsoft Entra パススルー認証を構成できます。 このエージェントを 1 つまたは複数のサーバーに展開して、高可用性を実現できます。 すべての通信は送信のみであるため、このサーバーを境界ネットワークに展開する必要はありません。

パススルー認証エージェントを実行するサーバーを、ユーザーが属している AD DS ドメインに参加させる必要があります。 Microsoft Entra パススルー認証をデプロイする前に、どの認証シナリオがサポートされており、どれがサポートされていないのかを知る必要があります。

パススルー認証は、次の認証シナリオで使用できます。

  • Microsoft Entra ID によってサポートされているすべての Web ブラウザーベースのアプリケーションへのユーザー サインイン。

  • 先進認証をサポートする Office アプリケーションへのユーザー サインイン。

    Note

    これらの Office アプリには、先進認証を使用した Office 2019、Office 2016、および Office 2013 が含まれています。

  • Exchange ActiveSync、簡易メール転送プロトコル (SMTP)、Post Office Protocol (POP)、インターネット メッセージ アクセス プロトコル (IMAP) など、従来のプロトコルを使用した Microsoft Outlook クライアントへのユーザー サインイン。

  • オンラインおよびハイブリッド トポロジを含む、先進認証をサポートする Skype for Business アプリケーションへのユーザー サインイン。

  • Windows 10 デバイスの Microsoft Entra ドメイン参加。

  • 多要素認証のアプリ パスワード。

パススルー認証でサポートされないシナリオ

パススルー認証では、最も一般的な認証シナリオがサポートされていますが、この方法を使用できないシナリオもあります。 これらのシナリオは、次のとおりです。

  • Outlook を除く、従来の Office クライアント アプリケーションへのユーザー サインイン。

    Note

    これらの従来のクライアント アプリには、先進認証を使用しない Office 2010 と Office 2013 が含まれています。

  • Office 2010 上でのみ、Exchange ハイブリッド環境で予定表の共有と空き時間情報にアクセスします。

  • Skype for Business クライアント アプリケーションへのユーザー サインイン (先進認証なし)。

  • Windows PowerShell バージョン 1.0 へのユーザー サインイン。

  • 資格情報が漏洩したユーザーの検出。

  • Microsoft Entra Domain Services を必要とするシナリオ。 Microsoft Entra Domain Services では、テナントでパスワード ハッシュ同期が有効になっている必要があるため、パススルー認証のみを使用するテナントは、これらのシナリオでは機能しません。

  • Microsoft Entra Connect Health を必要とするシナリオ。 パススルー認証は Microsoft Entra Connect Health とは統合されていません。

  • iOS セットアップ アシスタントを使用する Apple Device Enrollment Program (Apple DEP) を使用する場合、先進認証はサポートされていないため使用できません。 パススルー認証を使用するマネージド ドメインでは、Apple DEP デバイスを Intune に登録することはできません。 別の方法として、Intune ポータル サイト アプリの使用を検討してください。

パススルー認証のしくみ

パススルー認証を展開する前に、そのしくみと、この認証方法が AD FS とどのように異なるかを理解しておく必要があります。 パススルー認証は、AD FS 認証がさらに単純化された形式ではありません。 どちらの方法でも、オンプレミスのインフラストラクチャを使用して、Microsoft 365 などのリソースにアクセスするときにユーザーを認証しますが、その方法は異なります。

Microsoft Entra Connect の構成ウィザードの [構成] ページのスクリーンショット。ウィザードでは、次の設定を構成できます: パススルー認証用に Microsoft Entra Connect 認証エージェントをインストールする、パススルー認証を有効にする、Azure でマネージド認証を有効にする、SSO を有効にする、パスワード ハッシュ同期を有効にする。[構成が完了したら、同期プロセスを開始する。] チェックボックスを管理者がオンにしました。

パススルー認証では、認証エージェントと呼ばれるコンポーネントを使用してユーザーを認証します。 Microsoft Entra Connect は、構成時に認証エージェントをインストールします。

インストール後に、認証エージェントは自身を Microsoft 365 テナントの Microsoft Entra ID に登録します。 登録時に、Microsoft Entra ID は認証エージェントに一意のデジタル ID 証明書を割り当てます。 (キーの組を持つ) この証明書は、Microsoft Entra ID との安全な通信を可能にします。 登録手順によって、認証エージェントの Microsoft Entra テナントへのバインドも行われます。

Note

認証要求は認証エージェントにプッシュされません。 その代わり、初期化中に、認証エージェントは、相互認証を使用することでセキュリティ保護された HTTPS チャンネルであるポート 443 を介して Microsoft Entra ID に接続します。 Microsoft Entra ID は、接続を確立した後、認証エージェントに Azure Service Bus キューへのアクセスを提供します。 このキューから、認証エージェントはパスワード検証要求を取得して管理します。 このため、受信トラフィックは存在せず、境界ネットワークに認証エージェントをインストールする必要はありません。

Contoso IT スタッフが Microsoft 365 テナントでパススルー認証を有効にし、ユーザーが Outlook Web App で認証を試みると、次の手順が実行されます。

  1. まだサインインしていない場合、ユーザーは [Microsoft Entra ユーザー サインイン] ページにリダイレクトされます。 このページで、ユーザーはユーザー名とパスワードを使用してサインインします。 Microsoft Entra ID は、サインイン要求を受け取り、ユーザー名とパスワードをキューに置きます。 Microsoft Entra セキュリティ トークン サービス (STS) は、認証エージェントの公開キーを使用してこれらの資格情報を暗号化します。 STS サービスは、登録プロセス中に認証エージェントが受け取る証明書からこの公開キーを取得します。

    Note

    Microsoft Entra ID は、一時的にユーザー資格情報を Azure Service Bus キューに置きますが、これらがクラウドに保存されることはありません。

  2. Azure Service Bus キューに永続的に接続されている認証エージェントは、キューの変更を検出し、暗号化された資格情報をキューから取得します。 資格情報は認証エージェントの公開キーを使用して暗号化されるため、エージェントはその秘密キーを使用してデータの暗号化を解除します。

  3. 認証エージェントは、標準の Windows API を使用して、ローカル AD DS に対してユーザー名とパスワードを検証します。 この時点では、このメカニズムは AD FS が使用するものと似ています。 ユーザー名には、オンプレミスの既定のユーザー名 (通常は userPrincipalName) または Microsoft Entra Connect で構成された別の属性 ("代替 ID" と呼ばれます) を指定できます。

  4. オンプレミスの AD DS は要求を評価し、成功、失敗、パスワードの期限切れ、またはユーザー ロックアウトのうち、適切な応答を認証エージェントに返します。

  5. 認証エージェントは、AD DS から応答を受け取ると、この応答を Microsoft Entra ID に返します。

  6. Microsoft Entra ID が応答を評価し、ユーザーに適宜応答します。 たとえば、Microsoft Entra ID は、すぐにユーザーをサインインさせるか、多要素認証 を要求します。 ユーザーはサインインが成功すると、アプリケーションにアクセスできます。

Note

ドメイン参加済みコンピューターからクラウドベース リソースにアクセスする際のユーザー エクスペリエンスをさらに向上させるために、パススルー認証と Microsoft Entra シームレス SSO を一緒にデプロイすることを検討しても構いません。 この機能を展開すると、ユーザーが会社のドメインに参加しているコンピューターにドメイン資格情報を使用して既にサインインしている場合は、サインインせずにクラウド リソースにアクセスできます。

追加の参考資料

さらに学習するには、次のドキュメントを参照してください。