パスワードハッシュ同期と PTA の比較ガイド

By Mirko Peters · 2026-04-30 · Updated 2026-07-18

パスワードハッシュ同期と PTA の違いを、セットアップ、アーキテクチャ、セキュリティ、ガバナンス、実際の利用シーンの観点から解説します。

Automatically translated with AI from the original post. Read the English original

オンプレミスの Active Directory と Microsoft Entra ID（旧 Azure AD）の両方を運用していると、「どこからサインインしても、安全かつ混乱なくユーザーを認証するにはどうすればよいか」という問いが必ず出てきます。ここで役立つのが、パスワードハッシュ同期（PHS）とパススルー認証（PTA）です。どちらもオンプレミスとクラウドをつなぐ仕組みですが、セキュリティ、コンプライアンス、耐障害性の面では設計思想が大きく異なります。

PHS と PTA は、単にサインインを可能にするだけではありません。従来型の AD と、クラウドファーストの Entra ID のサービスを接続し、ハイブリッドな働き方を実現し、管理できる状態にします。どの方式を選ぶかによって、ユーザーのサインイン体験だけでなく、組織が脅威からどのように身を守り、コンプライアンスを管理し、成長に備えるかも変わってきます。

本ガイドは、テクニカルリードと経営判断を担う方々の双方に役立つ実践的な回答を目指しています。PHS と PTA を直接比較し、それぞれの動作原理と違い、適切な方式を選ぶためのポイントを解説します。構成、セキュリティレイヤー、災害復旧、コンプライアンス、パフォーマンスについても一通り取り上げます。読み終えるころには、余計な誇張や手間をかけずに、Microsoft のベストプラクティスに沿ったアイデンティティ戦略を立てるための指針が手に入るはずです。さっそく見ていきましょう。

認証方式の比較: Entra ID におけるパスワードハッシュ同期とパススルー認証

ハイブリッド ID とは、オンプレミスの Active Directory を Microsoft Entra ID に連携させることであり、その中核を担うのが選択する認証方式です。パスワードハッシュ同期（PHS）とパススルー認証（PTA）は、クラウドリソースにサインインするユーザーを検証する、2 つの異なる方法を提供します。どちらの方式もセキュリティだけでなく、パフォーマンス、コンプライアンス、日常的な使い勝手にも影響します。両方の目的と背景を理解しておくことで、自社環境にとって最適な判断ができるようになります。以下では、PHS と PTA の仕組みを、特に重要な詳細とフローに絞って説明します。

パスワードハッシュ認証と Azure の PTA: どのように動作するのか

パスワードハッシュ同期（PHS）とパススルー認証（PTA）は、オンプレミスの ID と Microsoft クラウドを接続するための、主流の 2 つの選択肢です。どちらの方式でも、ユーザーは従来の AD 資格情報を使ってクラウドサービスにサインインできますが、その仕組みは大きく異なります。

パスワードハッシュ同期では、Azure AD Connect を設定し、有効なすべての AD ユーザーのパスワードについて、特殊な不可逆の暗号化ハッシュを定期的に Entra ID へエクスポートします。これはドメインコントローラーの生のハッシュそのものではなく、ハッシュのハッシュです。そのため、Microsoft であってもパスワードを逆算することはできません。ハッシュがクラウドに保存されると、Entra ID はユーザーを直接認証できます。オンプレミスで問題が起きても影響を受けにくく、復元力に優れています。

一方 PTA では、パスワードの検証処理はオンプレミスの Active Directory に残ります。ユーザーが Microsoft クラウドサービスへのサインインを試みると、認証要求が Entra ID からオンプレミスで稼働する軽量な PTA エージェントの 1 つへ安全に転送されます。エージェントは入力されたユーザー名とパスワードを AD で照合し、成功か失敗かの結果を Entra ID に返します。Entra ID はその結果に基づいて、ユーザーを通すか、拒否するかを決定します。

次のように整理すると分かりやすいでしょう。PHS は、パスワードハッシュがクラウドに存在し、認証は Azure 上で行われる方式です。PTA は、クラウドにパスワードハッシュが存在せず、すべての資格情報の確認をエージェント経由でオンプレミスのドメインコントローラーが直接行う方式です。どちらを選ぶかによって、認証が実際にどこで行われるのか、そしてネットワークが安定稼働していることにどれほど依存するのかが決まります。こうした基本部分が、セキュリティ体制から災害時の回復力、ユーザー体験まであらゆるものに影響します。リスク、コンプライアンス、運用との関係を確認したい場合は、こちらの Entra ID 条件付きアクセスガイドで、アイデンティティガバナンスを強化する戦略を確認してください。

ハッシュ化されたパスワードの保存と安全な認証フロー

PHS では、各ユーザーのパスワードをハッシュ化し、さらにそのハッシュをハッシュ化したものを暗号化して Entra ID に同期します。このようにクラウド側に保存されるため、オンプレミスの AD に接続できない場合でも、Entra ID はサインイン要求に直接応答できます。

PTAはクラウドにコピーを作成せず、パスワードのハッシュをAzureに保存することもありません。代わりに、ユーザーがサインインするたびに、エージェントがオンプレミスのADに対して資格情報をリアルタイムで検証します。セキュアチャネルにより、パスワードが平文で露出することはありません。要約すると、PHSはクラウドに保存された二重ハッシュ化済みの資格情報に依存し、PTAは認証要求ごとにリアルタイムの確認を行い、資格情報をオンプレミスに保持します。

ハイブリッド認証におけるアイデンティティのセキュリティに関する考慮事項

ハイブリッドアイデンティティにおけるセキュリティは、壁を築くことだけではありません。一般的な攻撃を防ぎながら、日々の業務を円滑に続けられるよう適切なツールを選ぶことが重要です。PHSとPTAのどちらを選ぶかによって、パスワードデータの保存場所、転送方法、保存時と転送時の保護方法が変わります。さらに、条件付きアクセスやID保護といった防御ツールを、each方式がどのように活用するかも検討する必要があります。

組織はコンプライアンス要件を満たしつつ、進化する脅威に対応することが求められています。資格情報の窃取、フィッシング、侵害時の影響範囲の抑え込みのいずれが懸念であっても、ハイブリッド認証の方式はその対策に大きく影響します。各方式が脅威にどこまで耐えられるか、多層防御とどのように統合されるか、そして最新のレジリエントなアイデンティティ基盤にどう適合するかを把握しておく必要があります。ユーザーのセキュリティとよい利用体験のバランスを取る実践的な考え方については、Microsoft環境のベストプラクティスを解説したこちらのM365セキュリティガイドをご覧ください。

オンプレミスの保護とクラウドのセキュリティレイヤー

PHSとPTAはいずれも、オンプレミスのActive Directoryのセキュリティ機能を活用し、Entra ID経由でクラウドに拡張します。PHSでは、ハッシュがAzureに保存されると、クラウド固有の防御層を重ねられます。たとえば、条件付きアクセスポリシーやID保護の脅威スコアリングがすべての認証に適用され、ポリシーを厳密に適用しやすくなります。

PTAもこうしたクラウドの多層防御に対応しています。ただし、パスワードの検証はオンプレミスで行われるため、従来のAD保護を第一の防御線として維持できます。認証後も、条件付きアクセスや多要素認証などのクラウド側の制御が引き続き適用されます。どちらの方式を選ぶ場合でも、オンプレミスの保護と最新のEntra IDの機能を組み合わせることで、回復力のある多層防御のアイデンティティ基盤を構築できます。最新のクラウド脅威について詳しく知りたい場合は、OAuth同意攻撃の解説記事で、Entra IDに関する実際のリスクと対策を確認できます。

PHSとPTAにおけるアカウントのロックアウト、有効期限、サインイン時の利用体験

• アカウントのロックアウト: PTAでは、オンプレミスのロックアウトがすぐに適用されます。パスワードの誤入力が複数回発生すると、クラウドへのサインインもただちにブロックされます。PHSでは、次回のパスワードハッシュ同期までロックアウトが遅れます。
• パスワードの有効期限: PTAはADのパスワード有効期間をリアルタイムで反映するため、アカウントの期限が切れた時点で変更が求められます。PHSでは次回の同期時に反映されます。ハッシュの更新が行われていない場合、ユーザーは期限切れ後も短時間サインインできてしまうことがあります。
• サインインポリシー: PTAは、ADのサインイン時間の制御をすべて反映します。PHSでは、ポリシーの変更は同期後に適用されるため、クラウドでは一時的に反映が遅れます。
• リスク管理: PTAはリアルタイムの接続により厳格なポリシーの適用を確実にします。一方、PHSは即時性をわずかに犠牲にして、回復力と稼働時間の向上を図ります。

ユーザー体験: Entra IDにおけるシームレスなサインインとアクセシビリティ

適切なアイデンティティのフローは、パスワードやトークンだけの問題ではありません。ユーザーが安全かつスムーズに、余計な手間なくサインインできることが重要です。PHSとPTAのどちらを選ぶかは、特にリモートワークや分散型チームが増えた環境において、エンドユーザーの使い勝手に直接影響します。

このセクションでは、各方式がどのようにシームレスなサインインを実現するか、「一度設定すれば放置できる」ユーザーアクセスがどこで得られるか、そして、インターネットの一時的な障害、PTAエージェントの停止、パスワードの失念などの障害発生時にどうなるかを解説します。ユーザーのサインインを合理化し、不要なプロンプトを減らし、ネットワークの不安定な状況でもアクセスを保護することに焦点を当てます。その間も、セキュリティを最優先に維持します。

PHSとPTAでシームレスなシングルサインオンを有効にする

• Kerberos SSO のサポート: PHS と PTA のどちらでもシームレス SSO を利用できます。シームレス SSO は AD 内のコンピューター アカウント (AZUREADSSOACC) を利用するため、ドメイン参加済みのデバイスから真のシングル サインオンを実現できます。
• サインインの流れ: シームレス SSO を有効にすると、PHS と PTA のどちらを使っていても、信頼されたデバイスを使うユーザーはクラウド アプリであってもパスワードの入力を求められることがほとんどありません。AD の資格情報がバックグラウンドで使われます。
• 再認証の削減: シームレス SSO により再認証の回数が大幅に減り、ユーザーはアプリ、デバイス、ブラウザーの間を最小限の中断で移動できるようになります。
• 方式を問わないセキュリティ: シームレス SSO は PHS と PTA のどちらでも同等に安全ですが、ユーザーの体感はどちらの方式でも向上します。これは生産性の向上とヘルプデスクへの問い合わせ削減にとって重要なポイントです。

PTA の一時的な接続問題とクラウドへのフォールバックのシナリオ

• PTA エージェントのダウン: すべての PTA エージェントがオフラインになるか、Entra ID との通信を失うと、ユーザーは認証できなくなります。オンプレミスでの確認が行われないため、サインインもできなくなります。
• PHS の耐障害性: ローカルの AD が停止していても、PHS のユーザーはサインインを続けられます。保存されたハッシュを使って、認証はクラウドで処理されるためです。
• リモート拠点・支店: 回線が不安定な拠点では、PHS が一種の保険になります。回線品質が落ちても、ユーザーは業務を続けられます。
• フォールバック戦略: 一部の組織では、耐障害性を高めるために両方の方式を有効にし、PHS をバックアップとして構成しています。これにより、PTA に障害が発生した際に自動的にフェールオーバーできます。

認証エージェントの展開と管理

ハイブリッド認証は「設定したら放置」で済むものではありません。PHS と PTA にはそれぞれ運用上の要件があり、エージェント ソフトウェアの展開からアクセス許可の管理まで多岐にわたります。これらのシステムを円滑に稼働させるには、日々の運用作業と、セキュリティおよびコンプライアンスの要件のバランスを取ることが必要です。

Password Hash Sync を導入するチームの主な作業は、Azure AD Connect の管理が中心です。同期のスケジュール設定、更新の対応、エラーの監視などが含まれます。PTA の場合は、冗長性を確保するために複数のオンプレミス サーバーに軽量なエージェントを展開して監視することと、認証トラフィックを妨げる可能性のあるネットワークの問題のトラブルシューティングに重点が移ります。アクセス許可、パッチ適用、インシデント対応の手順も重要です。

クラウド サービスへの依存が高まる中、適切なエージェント管理は信頼性の高いサインイン環境を実現し、大規模化にもスムーズに対応できる土台になります。ガバナンスに本格的に取り組む方は、RBAC やポリシーの適用といった統制が Azure でどのような役割を果たすかについて、こちらのエンタープライズ ガバナンス戦略ガイドをご覧ください。

Azure AD Connect と PTA エージェントのアクセス許可を拡張する

• Azure AD Connect のアクセス許可: セットアップ時にはエンタープライズ管理者の権限が必要ですが、その後の継続的な同期では委任されたアクセス許可に切り替わります。必要以上に高い権限で実行しないでください。更新のたびに見直しましょう。
• PTA エージェントのアクセス許可: エージェントには「サービスとしてログオン」の権限と、AD への読み取り権限を持つサービス アカウントの資格情報が必要です。ただし、攻撃対象領域を減らすため、広範なドメイン管理者ロールは避けるべきです。
• 委任のベスト プラクティス: 最小権限の原則を適用してください。必要なアクセス許可だけを付与し、それ以上は与えないようにします。また、これらのロールに設定のずれがないか、定期的に監査しましょう。
• コンプライアンス監査: Microsoft Purview Audit などのツールを活用して変更を監視し、エージェントのアクティビティを追跡します。問題が発生した場合のフォレンジック調査にも役立ちます。

パスワード書き戻しの実装と既存アカウントのマッチング

• パスワードの書き戻し: Azure AD Connect でパスワードの書き戻しを有効にすると、ユーザーはクラウド上でパスワードをリセットできます。この変更はオンプレミスの AD に自動的に同期されるため、ヘルプデスクの負荷を軽減できます。
• ユーザーによるセルフサービス: 設定後は、ユーザーが Office.com または Microsoft Authenticator アプリからパスワードのリセットや変更を行えます。これにより、業務を止めることなくコンプライアンスを維持できます。
• マッチングの戦略: PHS を有効化する前、または PTA から切り替える前に、Entra ID と AD の間でユーザー アカウントが正しく対応付けられていることを確認してください。重複した ID やアクセスの問題を防ぐためです。
• 移行のベストプラクティス: パイロットグループで書き戻しをテストし、immutableID または mail 属性でアイデンティティの一致を確認して、本番移行後は同期エラーや資格情報の不一致を監視してください。

PTA から PHS への移行: 準備、実行、検証

Pass-Through Authentication から Password Hash Sync への切り替えは、スイッチを入れて成り行きを見守るだけでは済みません。移行では、環境を綿密に計画して文書化し、クラウドとオンプレミスの設定を一致させ、ユーザーや関係者へ明確に周知する必要があります。

このセクションでは、準備から検証までのエンドツーエンドの流れを解説します。テナントの準備方法、PHS の互換性の検証方法、そしてこの切り替えに伴って起こりうる問題への備えを確認します。目的は、ユーザーへの影響を最小限に抑え、予期しない問題を避け、必要に応じてロールバックできる円滑な経路を確保することです。各フェーズにはチェックポイントとベストプラクティスを用意しており、移行期間中もハイブリッド ID を安定して維持できます。

適切な移行計画があれば、認証の役割をクラウドへ移行できます。レジリエンスが高まり、リモートサイトや支店をサポートしやすくなり、今後の機能拡張にも道が開けます。変更は簡単ではありませんが、適切に進めれば火消しの作業が減り、本来のビジネスに集中できるようになります。

準備、テナントの概要、変更への準備状況の評価

• 既存の設定の棚卸し: 見落としを防ぐため、現在のすべての認証ポリシーとパスワード ポリシー、およびエージェントの展開内容を文書化してください。
• クラウドとの互換性の確認: すべてのアカウントが同期されており、PHS に適していることを確認してください。標準外のパスワード ポリシーや、レガシーな暗号化方式には特に注意が必要です。
• コミュニケーション計画: 今後の変更、起こりうる影響、新しいサインインの流れについて、関係者、ヘルプデスク、ユーザーに周知してください。
• ロールバック計画の策定: 移行中に問題が起きた場合に備えて、明確な代替手段を用意してください。どのような場合にロールバックするか、サービスを失わずにどう元に戻すかを把握しておくことが重要です。
• 影響を最小限にするスケジュール: ユーザーの利用が少ないメンテナンス時間帯を選び、切り替えの前後にサポート担当者が待機できるようにしてください。テナントのコンプライアンスへの影響について詳しくは、こちらのコンプライアンス ドリフトのエピソードをご覧ください。

PHS の有効化、本番環境への切り替え、成功の検証、緊急ロールバック

1. Azure AD Connect で PHS を有効化: Password Hash Sync のスイッチを入れ、すべてのユーザーでハッシュの同期が開始されることを確認してください。Azure AD Connect のダッシュボードで進行状況を追跡し、エラーが記録されていないことを確認します。
2. クラウドとの一致を検証: 本番トラフィックを移行する前に、同期されたアイデンティティが正しくマッピングされていること、および PHS でサインインできることを相互に確認してください。不一致や重複アカウントに注意が必要です。
3. 本番の認証を切り替える: 認証トラフィックを PTA から PHS へ段階的に移行します。まずパイロット グループで実施し、問題がなければテナント全体へ広げてください。
4. 成功とユーザー体験を監視: 切り替えの最中および切り替え後は、サインインにかかる時間、サービス正常性、ユーザーからのフィードバックに注意深く目を配ってください。サインインの失敗や予期しないエラーには迅速に対応します。
5. PTA エージェントを安全に廃止: PHS に十分な確信を持てたら、Microsoft のクリーンアップ手順に従って PTA エージェントを削除してください。変更内容を文書化し、インシデント対応計画を更新し、レガシーな依存関係が残っていないことを確認します。
6. 緊急ロールバック計画: 問題が深刻化した場合に備えて、エージェントを再有効化し、トラフィックの流れを元に戻すことで PTA へ切り替えられるようにしておいてください。ロールバックが必要になったときに 30 分以内に完了できるよう、事前に手順を練習しておくことが重要です。

ハイブリッド クラウド ID に適した認証方式の選択

これまでの事実と流れがすべて揃ったら、それを実際の要件に照らし合わせる段階です。PHS と PTA のどちらを選ぶかは、技術だけでなく、リスク プロファイル、コンプライアンス体制、ネットワークの信頼性、そしてチームが手作業で管理できる範囲にも左右されます。適切な選択は、技術面の目標だけでなく、事業上の実情、規制上の留意点、ユーザーの利用パターンにも合致している必要があります。

この最終セクションでは、実用性、既知の落とし穴、典型的なシナリオを整理します。ハイブリッド ID の計画を、目標に最も適した方式と自信を持って結び付けられるようにし、組織の変化に応じて戦略を切り替えられるようにすることが狙いです。

PHS の代わりに PTA を選択する場合: それぞれの方式を選ぶべきタイミング

• PTAを使うべき場合: クラウドへのパスワードハッシュの保存を一切認めない厳格な規制がある場合、またはオンプレミスのADポリシーをリアルタイムで適用する必要がある場合です。
• PHSを使うべき場合: 回復性を重視する場合です。オンプレミスのADがダウンしていたり到達できなかったりしても認証を継続できます(分散型やリモートのチームに最適です)。
• PTAが適している環境: 規制が厳しい環境や、クラウドとオンプレミスの間に堅牢な接続がある大規模で集中管理された環境です。
• PHSが適している環境: 稼働時間、シンプルな管理、クラウドファーストの回復性を重視する組織です。特にリモート拠点やネットワークの不安定さが懸念される場合に向いています。

よくある質問、多要素認証、重要なポイント

• 多要素認証(MFA)は両方の方式で機能しますか? はい。PTAとPHSのどちらも最新のMFAに対応しています。条件付きアクセス、SMS、アプリベースのコード、FIDO2などがあり、いずれも認証後にEntra IDによって適用されます。
• PHSを使うとオンプレミスのポリシーが失われますか? 完全に失われるわけではありません。パスワードの変更、アカウントロック、有効期限のほとんどは同期後も引き継がれます。ただし、PTAはこれらをリアルタイムで適用します。ミッションクリティカルなポリシーの適用が必要な場合は、PTAが適している可能性があります。
• ネットワーク障害が発生した場合はどうなりますか? PTAの場合、PTAエージェントに到達できなければ、すべてのクラウド認証が停止します。PHSはクラウド上のハッシュを使用するため、認証を継続できます(ユーザーはサインインできます)。それに応じてフェイルオーバー戦略を計画してください。
• コンプライアンスレポートと監査ログはどのように扱えばよいですか? PTAは主にオンプレミス(エージェントとドメインコントローラー上)でイベントを記録します。PHSはほとんどのアクティビティをEntra IDに送信するため、SIEMやコンプライアンスチームにとってより豊富なクラウド全体の可視性を提供します。広範なガバナンスには、クラウドでのログ記録と監視の方が容易です。IDリスクの低減について詳しくは、こちらのEntra ID 条件付きアクセスのエピソードをご覧ください。
• 重要なポイント: PTAとPHSにはそれぞれ役割があります。判断する前に、運用の手間、回復性、規制要件、ユーザーエクスペリエンスのバランスを検討してください。IDの負債や条件付きアクセスの乱立の監視も忘れないでください。強力で適用可能なポリシーこそが、実効性のあるセキュリティの中核です。上記のガイドで説明したとおりです。より広範なプラットフォームでセキュリティとガバナンスに取り組んでいる場合は、補完的なID管理戦略としてPower Platform のセキュリティのベストプラクティスもご覧ください。

併せて聴いていただきたいエピソード

Password Hash Sync と PTAについて調査している場合は、アーキテクチャ、セキュリティ、ガバナンス、導入に関する実践的な背景が得られる以下のエピソードがおすすめです。

• Microsoft AI Agent Harness – Simply Explained — オーケストレーション、ガードレール、評価、信頼性の高いAIワークフローについて理解できます。
• Microsoft Defender XDR – Simply Explained — IDとAIによる判断を、セキュリティの監視と対応につなげる方法を解説します。
• Microsoft Teams Governance – The Illusion of Control — ガバナンス、所有権、ポリシーが運用上のリスクをどのように低減するかを学べます。
• Azure Virtual Network – Simply Explained — クラウド接続の背後にあるアーキテクチャの前提を理解できます。