Microsoft Entra パススルー認証のセキュリティの深掘り

この記事では、Microsoft Entra パススルー認証のしくみについてより詳しく説明します。 ここでは、機能のセキュリティ面について重点的に説明します。 この記事は、セキュリティおよび IT 管理者、コンプライアンスおよびセキュリティの最高責任者、あらゆる規模の組織や企業で IT セキュリティとコンプライアンスを担当するその他の IT プロフェッショナルを対象としています。

ここで扱うトピックは次のとおりです。

• 認証エージェントのインストールおよび登録方法に関する詳細な技術情報。
• ユーザー サインイン時のパスワードの暗号化に関する詳細な技術情報。
• オンプレミスの認証エージェントと Microsoft Entra ID 間のチャネルのセキュリティ。
• 認証エージェントの運用上のセキュリティを維持する方法についての詳細な技術情報。

パススルー認証の主要なセキュリティ機能

パススルー認証には、次の主要なセキュリティ機能があります。

• この機能は、テナント間でのサインイン要求を分離する、セキュリティで保護されたマルチテナント アーキテクチャ上に構築されています。
• オンプレミス パスワードが何らかの形でクラウドに保存されることはありません。
• パスワード検証要求のリッスンおよび応答を行うオンプレミスの認証エージェントは、ネットワーク内からの送信接続のみを行います。 これらの認証エージェントを境界ネットワーク (DMZ、"非武装地帯"、"スクリーン サブネット" とも呼ばれます) にインストールする必要はありません。 ベスト プラクティスとして、認証エージェントを実行するすべてのサーバーは Tier 0 システムとして扱うようにしてください (リファレンスを参照)。
• 認証エージェントから Microsoft Entra ID への送信通信で使用されるのは、標準ポート (ポート 80 とポート 443) のみです。 ファイアウォールで受信ポートを開く必要はありません。
• 認証済みのすべての送信通信でポート 443 が使用されます。
• ポート 80 が使用されるのは、証明書失効リスト (CRL) をダウンロードして、この機能で使用される証明書が失効していないことを確認する場合のみです。
• ネットワーク要件の完全な一覧については、「Microsoft Entra パススルー認証: クイック スタート」をご覧ください。
• ユーザーがサインイン時に指定するパスワードは、Windows Server Active Directory (Windows Server AD) に対する検証でオンプレミスの認証エージェントに受け入れられる前に、クラウドで暗号化されます。
• Microsoft Entra ID とオンプレミスの認証エージェント間の HTTPS チャネルは、相互認証を使用して保護されます。
• パススルー認証では、Microsoft Entra 条件付きアクセス ポリシー (多要素認証 (MFA) を含む) とレガシ認証のブロック、フィルター処理によるブルート フォース パスワード攻撃の除外により、作業を中断せずに、ユーザー アカウントを保護します。

パススルー認証に関連するコンポーネント

Microsoft Entra ID の運用、サービス、データのセキュリティに関する一般的な詳細については、トラスト センターのページをご覧ください。 ユーザー サインインにパススルー認証を使用する場合には、次のコンポーネントが関連します。

• Microsoft Entra セキュリティ トークン サービス (Microsoft Entra STS): サインイン要求を処理し、必要に応じてユーザーのブラウザー、クライアント、またはサービスにセキュリティ トークンを発行するステートレスな STS。
• Azure Service Bus:エンタープライズ メッセージングと中継通信を使用するクラウド対応通信を提供し、オンプレミスのソリューションをクラウドに接続するのに役立ちます。
• Microsoft Entra Connect 認証エージェント: パスワード検証要求のリッスンと応答を行うオンプレミス コンポーネント。
• Azure SQL Database: メタデータや暗号化キーを含む、テナントの認証エージェントに関する情報が保持されています。
• Windows Server AD: ユーザー アカウントとそのパスワードが格納されるオンプレミスの Active Directory。

認証エージェントのインストールと登録

次のいずれかのアクションを実行すると、認証エージェントがインストールされ、Microsoft Entra ID に登録されます。

• Microsoft Entra Connect を使用してパススルー認証を有効にする
• 認証エージェントを追加してサインイン要求の高可用性を確保する

認証エージェントを運用させるには、次の 3 つの主なフェーズが必要です。

• インストール
• 登録
• 初期化

次のセクションでは、これらのフェーズを詳細に説明します。

認証エージェントのインストール

(Microsoft Entra Connect またはスタンドアロン インスタンスを使用して) オンプレミス サーバーに認証エージェントをインストールできるのは、ハイブリッド ID 管理者のアカウントのみです。

インストールでは、次の 2 つの新しい項目が、[コントロール パネル]>[プログラム]>[プログラムと機能] の一覧に追加されます。

• 認証エージェント アプリケーション自体。 このアプリケーションは NetworkService 権限で実行されます。
• 認証エージェントの自動更新で使用されるアップデーター アプリケーション。 このアプリケーションは LocalSystem 権限で実行されます。

重要

セキュリティの観点から、管理者はパススルー認証エージェントを実行しているサーバーをドメイン コントローラーとして扱う必要があります。 パススルー認証エージェント エージェント サーバーは、「攻撃に対してドメイン コントローラーをセキュリティで保護する」で説明されているように強化する必要があります。

認証エージェントの登録

認証エージェントは、インストール後に自身を Microsoft Entra ID に登録します。 Microsoft Entra ID は、セキュリティで保護された Microsoft Entra ID との通信で使用できる一意のデジタル ID 証明書を各認証エージェントに割り当てます。

登録手順では、認証エージェントとテナントとのバインドも行います。 その後、Microsoft Entra ID は、この特定の認証エージェントのみがテナントのパスワード検証要求を処理する権限があることを認識できます。 この手順は、登録する新しい認証エージェントごとに繰り返されます。

認証エージェントは、次の手順を使用して、Microsoft Entra ID に自身を登録します。

1. Microsoft Entra はまず、ハイブリッド ID 管理者が自分の資格情報を使用して Microsoft Entra ID にサインインすることを要求します。 認証エージェントはサインイン時、ユーザーに代わって使用可能なアクセス トークンを取得します。

2. 次に、認証エージェントは公開キーと秘密キーのキー ペアを生成します。

   • このキー ペアは、標準の RSA 2048 ビットの暗号化を使用して生成されます。
   • 秘密キーは、認証エージェントが存在するオンプレミス サーバーに保持されます。

3. 認証エージェントは要求に含まれる以下のコンポーネントを使用して、HTTPS 経由で Microsoft Entra ID に登録要求を行います。

   • エージェントが取得したアクセス トークン。
   • 生成された公開キー。
   • 証明書署名要求 (CSR または証明書要求)。 この要求により、Microsoft Entra ID を証明機関 (CA) として使用して、デジタル ID 証明書を申請します。

4. Microsoft Entra ID は登録要求内のアクセス トークンを検証し、要求がハイブリッド ID 管理者からのものであることを確認します。

5. 次に、Microsoft Entra ID はデジタル ID 証明書に署名して、認証エージェントに送信します。

   • Microsoft Entra ID 内のルート CA は証明書の署名に使用されます。

   Note

   この CA は、Windows の信頼されたルート証明機関ストアには 存在しません。

   • この CA はパススルー認証機能でのみ使用されます。 この CA は、認証エージェントを登録するときの CSR への署名でのみ使用されます。
   • 他の Microsoft Entra サービスはこの CA を使用しません。
   • 証明書の件名 ("識別名" または DN とも呼ばれます) はテナント ID に設定されます。 この DN はテナントを一意に識別する GUID です。 この DN により、証明書の範囲がテナントのみでの使用に限定されます。

6. Microsoft Entra ID では、Azure SQL Database 内のデータベースに認証エージェントの公開キーが格納されます。 Microsoft Entra ID のみがデータベースにアクセスできます。

7. 発行された証明書は、オンプレミス サーバーの Windows 証明書ストア (CERT_SYSTEM_STORE_LOCAL_MACHINE などの場所) に格納されます。 この証明書は認証エージェントとアップデーター アプリケーションの両方で使用されます。

認証エージェントの初期化

認証エージェントの開始時 (登録後の初回開始時またはサーバーの再起動時) に、パスワード検証要求の受け入れを開始できるように、Microsoft Entra サービスと安全に通信する方法が必要になります。

認証エージェントを初期化する方法を以下に示します。

1. 認証エージェントは、Microsoft Entra ID に送信ブートストラップ要求を行います。 この要求は、ポート 443 で、相互に認証された HTTPS チャネルを介して行われます。 この要求では、認証エージェントの登録中に発行された証明書と同じ証明書が使用されます。
2. Microsoft Entra ID は、テナント ID で識別される、テナントに固有の Service Bus キューにアクセス キーを提供することで、この要求に応答します。
3. 認証エージェントは、キューへの (ポート 443 を介した) 永続的な送信 HTTPS 接続を行います。

これで、認証エージェントがパスワード検証要求を取得して処理する準備ができました。

テナントに複数の認証エージェントが登録されている場合は、初期化の手順で、各エージェントが同じ Service Bus キューに接続されていることが確認されます。

パススルー認証でのサインイン要求の処理方法

次の図は、パススルー認証でユーザー サインイン要求がどのように処理されるかを示しています。

パススルー認証では、次のようにユーザーのサインイン要求が処理されます。

1. ユーザーが Outlook Web アプリなどのアプリケーションへのアクセスを試みます。
2. ユーザーがまだサインインしていない場合は、アプリケーションでブラウザーが Microsoft Entra のサインイン ページにリダイレクトされます。
3. Microsoft Entra STS サービスがユーザー サインイン ページで応答します。
4. ユーザーが [ユーザー サインイン] ページにユーザー名を入力し、[次へ] ボタンを選択します。
5. ユーザーが [ユーザー サインイン] ページにパスワードを入力し、[サインイン] ボタンを選択します。
6. ユーザー名とパスワードが HTTPS POST 要求で Microsoft Entra STS に送信されます。
7. Microsoft Entra STS が、テナントで登録されたすべての認証エージェント用の公開キーを Azure SQL Database から取得し、このキーを使用してパスワードを暗号化します。 テナントで登録された認証エージェントごとに 1 つの暗号化されたパスワード値が生成されます。
8. Microsoft Entra STS が、ユーザー名と暗号化されたパスワードの値で構成されるパスワード検証要求をテナントに固有の Service Bus キューに配置します。
9. 初期化された認証エージェントは Service Bus キューに永続的に接続されるため、使用可能な認証エージェントのいずれかがパスワード検証要求を取得します。
10. 認証エージェントは識別子を使用して、公開キーに固有の暗号化されたパスワード値を検索します。 秘密キーを使用して公開キーの暗号化を解除します。
11. 認証エージェントが、Win32 LogonUser API (dwLogonType パラメーターは LOGON32_LOGON_NETWORK に設定) を使用して、Windows Server AD に対してユーザー名とパスワードを検証します。
    • この API は、フェデレーション サインイン シナリオでユーザーのサインイン時に Active Directory フェデレーション サービス (AD FS) によって使用されるものと同じ API です。
    • この API は、Windows Server の標準的な解決プロセスに従ってドメイン コントローラーを検索します。
12. 認証エージェントが Windows Server AD から結果 (成功、ユーザー名またはパスワードが正しくない、パスワードの期限が切れているなど) を受け取ります。

注意

認証エージェントがサインイン プロセスの間に失敗した場合は、サインイン要求全体が破棄されます。 あるオンプレミス認証エージェントから別のオンプレミス認証エージェントにサインイン要求が渡されることはありません。 これらのエージェントはクラウドのみと通信し、相互には通信しません。

13. 認証エージェントは、ポート 443 を介して相互認証された送信 HTTPS チャネル経由で Microsoft Entra STS に結果を戻します。 相互認証では、登録時に認証エージェントに対して発行された証明書を使用します。
14. Microsoft Entra STS は、この結果がテナントの特定のサインイン要求と関連していることを確認します。
15. Microsoft Entra STS は、構成どおりにサインインの手順を続行します。 たとえば、パスワードの検証が成功した場合、ユーザーは MFA のためにチャレンジされるか、アプリケーションにリダイレクトされることがあります。

認証エージェントの運用上のセキュリティ

パススルー認証で運用上のセキュリティが維持されるように、Microsoft Entra ID は証明書エージェントの証明書を定期的に更新します。 Microsoft Entra ID によって更新がトリガーされます。 これらの更新は、認証エージェント自体が管理しているわけではありません。

認証エージェントが Microsoft Entra ID との信頼関係を更新するには、以下を行います。

1. 認証エージェントは数時間ごとに Microsoft Entra を ping して、証明書を更新する時期であるかどうかを確認します。 証明書は有効期限が切れる 30 日前に更新されます。 この確認は、登録時に発行されたものと同じ証明書を使用して、相互認証された HTTPS チャネル経由で行われます。
2. サービスで更新の時期であることが示された場合、認証エージェントは公開キーと秘密キーの新しいキー ペアを生成します。
   • これらのキーは、標準の RSA 2,048 ビットの暗号化を使用して生成されます。
   • 秘密キーはオンプレミス サーバーの外部に移動されることはありません。
3. 次に、認証エージェントは、HTTPS 経由で Microsoft Entra ID に証明書更新要求を行います。 要求には、次のコンポーネントが含まれています。
   • Windows 証明書ストアの CERT_SYSTEM_STORE_LOCAL_MACHINE の場所から取得した既存の証明書。
   • 手順 2 で生成した公開キー。
   • CSR。 この要求により、Microsoft Entra ID を CA として使用して、新しいデジタル ID 証明書を申請します。
4. Microsoft Entra ID は、証明書更新要求の既存の証明書を検証します。 次に、要求がテナントに登録されている認証エージェントからのものであることを確認します。
5. 既存の証明書がまだ有効である場合、Microsoft Entra ID は新しいデジタル ID 証明書に署名し、新しい証明書を認証エージェントに戻します。
6. 既存の証明書の有効期限が切れている場合、Microsoft Entra ID は登録されている認証エージェントのテナントの一覧から認証エージェントを削除します。 その後、ハイブリッド ID 管理者は手動で新しい認証エージェントをインストールして登録する必要があります。
   • Microsoft Entra ID ルート CA を使用して、証明書に署名します。
   • 証明書の DN を、テナントを一意に識別する GUID であるテナント ID に設定します。 この DN により、証明書の範囲がテナントのみに限定されます。
7. Microsoft Entra ID では、それのみがアクセス可能な Azure SQL Database 内のデータベースに認証エージェントの公開キーが格納されます。 また、認証エージェントに関連付けられた古い公開キーを無効にします。
8. その後、新しい証明書 (手順 5 で発行されたもの) はサーバーの Windows 証明書ストア (CERT_SYSTEM_STORE_CURRENT_USER などの場所) に格納されます。

信頼の更新手順は (ハイブリッド ID 管理者の関与なしに) 非対話形式で行われるため、認証エージェントは CERT_SYSTEM_STORE_LOCAL_MACHINE の場所の既存の証明書を更新するためのアクセス権を持たなくなります。

Note

この手順で、CERT_SYSTEM_STORE_LOCAL_MACHINE の場所から証明書自体が削除されるわけではありません。 9. この時点から、新しい証明書が認証に使用されます。 以降の証明書更新のたびに、CERT_SYSTEM_STORE_LOCAL_MACHINE の場所にある証明書が置き換えられます。

認証エージェントの自動更新

新しいバージョンが (バグ修正またはパフォーマンスの強化が行われて) リリースされると、アップデーター アプリケーションによって認証エージェントが自動的に更新されます。 アップデーター アプリケーションでは、テナントに対するパスワード検証要求は処理されません。

Microsoft Entra ID は、新しいバージョンのソフトウェアを、署名済みの Windows インストーラー パッケージ (MSI) としてホストします。 MSI への署名は、ダイジェスト アルゴリズムに SHA-256 を指定した Microsoft Authenticode を使用することによって行われます。

認証エージェントの自動更新を行うには、以下を実行します。

1. アップデーター アプリケーションは 1 時間ごとに Microsoft Entra を ping して、使用可能な新しいバージョンの認証エージェントがあるかどうかを確認します。 この確認は、登録時に発行されたものと同じ証明書を使用して、相互認証された HTTPS チャネル経由で行われます。 認証エージェントとアップデーターは、サーバーに格納されている証明書を共有します。
2. 新しいバージョンが使用可能な場合、Microsoft Entra ID はアップデーターに署名済みの MSI を戻します。
3. アップデーターは、MSI が Microsoft によって署名されていることを確認します。
4. アップデーターは MSI を実行します。 このプロセスでは、Updater アプリケーションは次の処理を行います。

注意

アップデーターはローカル システム権限で実行されます。

5. 認証エージェント サービスを停止します。
6. サーバーに新しいバージョンの認証エージェントをインストールします。
7. 認証エージェント サービスを再起動します。

Note

テナントに複数の認証エージェントが登録されている場合、Microsoft Entra ID がそれらの証明書を同時に更新することはありません。 代わりに、Microsoft Entra ID では一度に 1 つずつ証明書が更新され、サインイン要求の高可用性が保証されます。

次のステップ

• 現在の制限事項: サポートされているシナリオについて確認します。
• クイックスタート - Microsoft Entra パススルー認証を設定します。
• AD FS からパススルー認証への移行: AD FS (または他のフェデレーション テクノロジ) からパススルー認証に移行するための詳細なガイドをご覧ください。
• スマート ロックアウト: ユーザー アカウントを保護するようにテナントのスマート ロックアウト機能を構成します。
• しくみ: Microsoft Entra パススルー認証のしくみの基礎を確認します。
• よく寄せられる質問: よく寄せられる質問への回答を参照してください。
• トラブルシューティング: パススルー認証に関する一般的な問題を解決する方法を確認します。
• Microsoft Entra シームレス SSO: 補完的な Microsoft Entra 機能のシームレス シングル サインオンの詳細について説明します。