Microsoft Entra パススルー認証（Pass-through Authentication / PTA）は、Microsoft Entra ID へのサインイン時に、ユーザーのパスワードをオンプレミス Active Directory に直接照合する認証方式です。結論から言うと、今回確認すべきポイントは「すぐに全利用者へ機能変更が入る」というより、PTAを使っているテナントで、エージェント構成・高可用性・パスワード ハッシュ同期との併用・移行手順を見直すことです。公式ページは日本語版で 2026年5月27日に更新されており、Microsoft Entra Connect を使ったハイブリッド ID 環境の管理者は、運用設計に抜けがないか確認しておきたい内容です。(Microsoft Learn)
Microsoft Entra パススルー認証とは
Microsoft Entra パススルー認証は、Microsoft Entra ID でクラウドアプリにサインインする際、入力されたパスワードをオンプレミス Active Directory に問い合わせて検証する仕組みです。ユーザーはオンプレミスとクラウドで同じパスワードを使えるため、Microsoft 365 や SaaS アプリへのサインイン体験を統一しやすくなります。(Microsoft Learn)
重要なのは、PTAではオンプレミスのパスワードがクラウドに保存されない点です。Microsoft Entra ID はサインイン要求を受け取り、オンプレミスに配置された軽量な Authentication Agent が Active Directory に対してパスワードを検証します。エージェントは社内ネットワークから Microsoft Entra ID へ送信接続を行う方式のため、DMZ に置いたり、外部から社内へ着信ポートを開けたりする前提ではありません。(Microsoft Learn)
一方で、PTAは「クラウドだけで完結する認証」ではありません。サインイン時にオンプレミス Active Directory、ドメイン コントローラー、Authentication Agent、ネットワーク接続が関係します。つまり、オンプレミス側の障害やメンテナンスが、クラウドアプリへのサインインに影響する可能性があります。
2026年5月27日更新で管理者が見るべきポイント
今回の公式情報でまず押さえるべきなのは、PTAの基本仕様が大きく別物になったというより、現在のPTA運用で確認すべき条件が明確に整理されていることです。特に、既存環境では「動いているから問題ない」と判断せず、次の項目を棚卸ししてください。
| 確認項目 | 管理者が見るべき内容 |
|---|---|
| 認証方式 | テナントで Pass-through Authentication が有効か |
| エージェント状態 | Authentication Agent が Active になっているか |
| 高可用性 | 本番環境で最低3台のエージェントを用意しているか |
| 障害時対応 | パスワード ハッシュ同期をバックアップ方式として検討しているか |
| ネットワーク | エージェントから Microsoft Entra ID への送信通信が許可されているか |
| セキュリティ | PTAエージェント サーバーをドメイン コントローラー相当の重要資産として保護しているか |
| 移行計画 | AD FS から切り替える場合、検証期間と切り戻し手順を用意しているか |
Microsoft のクイックスタートでは、本番環境ではテナントあたり最低3台の Authentication Agent を推奨し、システム上限は40台とされています。また、PTAエージェントを実行するサーバーは Tier 0 システムとして扱うことが推奨されています。(Microsoft Learn)
影響範囲：誰に、どこまで影響するのか
PTAの影響は、単に「サインイン方法が変わる」だけではありません。オンプレミス Active Directory、Microsoft Entra Connect、条件付きアクセス、MFA、業務アプリ、障害対応まで含めて確認する必要があります。
| 対象 | 影響内容 | 確認ポイント |
|---|---|---|
| 一般ユーザー | オンプレミスとクラウドで同じパスワードを使用 | パスワード期限切れ時の案内、SSO体験、MFA要求 |
| ID管理者 | サインイン方式がテナント単位で影響 | 有効化範囲、管理者アカウント、切り戻し手順 |
| インフラ管理者 | PTAエージェントとAD DSへの接続が必要 | サーバー配置、ドメイン参加、TLS 1.2、ネットワーク経路 |
| セキュリティ担当 | 条件付きアクセスやMFAと連携 | レガシ認証ブロック、Smart Lockout、監査ログ |
| アプリ開発者 | Microsoft Entra ID 経由の認証フローに影響 | モダン認証対応、UPN/Alternate ID、トークン処理 |
| ヘルプデスク | サインイン失敗の切り分けが必要 | AADSTS80001 などのエラーコード、AD側のアカウント状態 |
PTAはテナント レベルの機能です。有効化すると、テナント内の管理対象ドメインのユーザー サインインに影響します。AD FS からPTAへ切り替える場合、Microsoft は Exchange ActiveSync の移行影響を考慮し、AD FS インフラを停止する前に少なくとも12時間待つことを案内しています。(Microsoft Learn)
パスワード ハッシュ同期、AD FS、PTAの違い
Microsoft Entra のハイブリッド認証では、主に「パスワード ハッシュ同期」「パススルー認証」「フェデレーション認証（AD FSなど）」を比較して選びます。PTAは、オンプレミス Active Directory のアカウント状態やパスワード ポリシーをサインイン時に反映したい組織に向いています。(Microsoft Learn)
| 認証方式 | 向いているケース | 注意点 |
|---|---|---|
| パスワード ハッシュ同期 | できるだけシンプルにクラウド認証を使いたい | オンプレミス側の一部状態反映には同期タイミングが関係する |
| パススルー認証 | オンプレミスADのパスワードポリシーやアカウント状態を即時に近い形で反映したい | オンプレミスAD、エージェント、ネットワークに依存する |
| AD FSなどのフェデレーション | 既存のフェデレーション基盤や特殊な認証要件がある | インフラが複雑で、運用・証明書・冗長化の負荷が高い |
PTAを選ぶ場合でも、パスワード ハッシュ同期を完全に無視するのはおすすめできません。Microsoft は、PTAやフェデレーションを使う場合でも、高可用性、災害復旧、ID Protection の観点からパスワード ハッシュ同期の有効化を推奨しています。(Microsoft Learn)
ただし、PTAからパスワード ハッシュ同期へのフェールオーバーは自動ではありません。オンプレミス障害時にパスワード ハッシュ同期へ切り替えるには、Microsoft Entra Connect でサインイン方法を手動変更する必要があります。Microsoft Entra Connect サーバー自体が停止している場合は、Microsoft サポートの支援が必要になる可能性があります。(Microsoft Learn)
管理者が最初に確認すべき設定
PTAを利用中、またはこれから展開する管理者は、まず次の順番で確認すると効率的です。
Microsoft Entra 管理センターで状態を確認する
Microsoft Entra 管理センターで Microsoft Entra Connect の画面を開き、Pass-through authentication が有効になっているか、各 Authentication Agent が Active になっているか確認します。サインイン障害時に、機能が無効化されていたり、エージェントが Inactive になっていたりすると、ユーザー影響が広がります。(Microsoft Learn)
特に、運用中の環境では次の状態を記録しておくと、障害時の切り分けが早くなります。
- 有効なAuthentication Agentの台数
- 各エージェントのサーバー名
- 設置先サイト、接続先ドメイン コントローラー
- 最終確認日時
- エージェント更新後のサインインテスト結果
クラウド専用の管理者アカウントを用意する
PTA環境では、オンプレミス側の障害に備えて、クラウド専用の Hybrid Identity Administrator アカウントを用意しておくことが重要です。公式クイックスタートでも、オンプレミス サービスが失敗または利用不可になった場合にテナントを管理できるよう、クラウド専用またはクラウド側で管理できる Hybrid Identity Administrator アカウントの作成が案内されています。(Microsoft Learn)
これは「緊急用アカウント」です。通常業務では使わず、強力な認証保護、利用記録、保管手順をセットで設計してください。PTAの障害時に管理者自身がサインインできなければ、復旧作業の開始が遅れます。
エージェントは最低3台を目安にする
本番環境では、Microsoft は最低3台の Authentication Agent を推奨しています。1台だけの構成では、そのサーバーの停止、更新、ネットワーク障害、証明書更新トラブルがそのままサインイン障害につながります。(Microsoft Learn)
ただし、複数台を置けばロードバランサーのように均等分散されるわけではありません。Microsoft のFAQでは、複数エージェントは高可用性を提供するもので、決定的なロードバランシングを提供するものではないと説明されています。1台のエージェントは標準的な4コアCPU、16GB RAMのサーバーで毎秒300〜400認証を処理できる目安が示されていますが、実際の台数はピーク時のサインイン数、拠点構成、ADサイト設計を含めて判断します。(Microsoft Learn)
展開時の注意点：サーバー、ネットワーク、セキュリティ
PTAの展開で失敗しやすいのは、エージェントを「軽量だから適当に置いてよい」と考えることです。実際には、エージェントはユーザーのパスワード検証に関わるため、かなり重要度の高いサーバーとして扱う必要があります。
サーバー要件を満たす
クイックスタートでは、Microsoft Entra Connect を実行するサーバーとして Windows Server 2025、2022、2019、2016 が案内されています。TLS 1.2 を有効にし、検証対象ユーザーと同じ Active Directory フォレストに参加させる必要があります。また、Windows Server Core への Pass-through Authentication Agent のインストールはサポートされていません。(Microsoft Learn)
実務では、次のような配置を避けるべきです。
- ドメイン コントローラーへ安易に同居させる
- 運用担当が不明な古いサーバーへ設置する
- パッチ適用や再起動計画がないサーバーへ設置する
- バックアップ、監視、ログ収集の対象外にする
- 仮想マシンをクローンしてエージェントを増やす
特に、Authentication Agent をインストール済みの仮想マシンをクローンして別エージェントとして構成する方法はサポートされていません。追加エージェントは正規の手順でインストール、登録してください。(Microsoft Learn)
通信は送信方向が中心
PTAエージェントは、Microsoft Entra ID に対して送信接続を行います。主に 443 が認証済み通信に使われ、80 は証明書失効リストの取得に使われます。クイックスタートでは、443、80、状況により8080などの通信要件が示されています。(Microsoft Learn)
ネットワーク設計では、次の点を確認してください。
- エージェント サーバーから Microsoft Entra ID への送信通信が可能か
- 証明書検証に必要なURLがブロックされていないか
- 送信プロキシを使う場合、必要なURLを明示的に許可しているか
- TLS通信のインライン検査や終端処理が影響していないか
- エージェントからドメイン コントローラーへ安定して到達できるか
PTAはDMZに置く設計ではありません。エージェントはAD DSへ到達する必要があるため、ドメイン コントローラーに近いネットワークに配置し、外部公開ではなく送信通信でMicrosoft Entra IDと連携させる考え方が基本です。
エージェントサーバーはTier 0として保護する
PTAエージェントはパスワード検証要求を扱うため、セキュリティ上はドメイン コントローラーに近い重要度で扱うべきです。Microsoft のセキュリティ詳細でも、エージェントが動作するサーバーは Tier 0 システムとして扱うことがベストプラクティスとされています。(Microsoft Learn)
実務では、少なくとも次の対策を検討してください。
- 管理者権限を最小限にする
- EDRや監査ログの対象にする
- 対話型ログオンを制限する
- 不要なソフトウェアを入れない
- 定期的な更新と再起動計画を作る
- バックアップ、監視、インシデント対応手順を用意する
移行時の注意点：AD FSから切り替える場合
AD FSや他のフェデレーション技術からPTAへ移行する場合、単にMicrosoft Entra Connectでサインイン方法を変えるだけでは不十分です。認証基盤の切り替えは、ユーザーの業務停止に直結します。
移行前に、少なくとも次のテストを行ってください。
| テスト項目 | 確認内容 |
|---|---|
| 通常サインイン | ブラウザー、Officeクライアント、主要SaaSでサインインできるか |
| MFA | 条件付きアクセスとMFA要求が想定通りか |
| パスワード期限切れ | 期限切れユーザーが適切に案内されるか |
| アカウントロック | AD側でロックされたユーザーがサインインできないか |
| 無効化ユーザー | ADで無効化したユーザーがブロックされるか |
| Exchange ActiveSync | モバイルや古いクライアントに影響がないか |
| 切り戻し | 問題発生時に旧方式へ戻す手順があるか |
AD FSからPTAへ切り替える場合、Microsoft はクイックスタートや移行リソースの確認を推奨しています。特に、切り替え後すぐにAD FSインフラを停止せず、一定時間の様子見を行うことが重要です。(Microsoft Learn)
また、古いテナントではUPN同期に関する注意点があります。Microsoft のFAQでは、2015年6月15日以前に作成され、もともとAD FSでフェデレーションしていたテナントがPTAへ移行した場合、オンプレミスUPN変更が同期されないケースが説明されています。該当する環境では、UPN変更の同期設定を確認してください。(Microsoft Learn)
開発者・アプリ担当者が確認すべきこと
PTAは主にID基盤側の認証方式ですが、アプリ開発者やSaaS管理者にも影響があります。特に、Microsoft Entra ID を認証基盤として使う業務アプリでは、認証方式そのものよりも、サインイン時にどの条件付きアクセス、MFA、ユーザー属性、UPNが使われるかが重要です。
Microsoft の技術情報では、ユーザーがMicrosoft Entra IDで保護されたアプリへアクセスすると、Microsoft Entra IDがサインイン要求を処理し、Authentication Agent がActive Directoryでユーザー名とパスワードを検証した結果を返します。その後、Microsoft Entra ID側でMFAなどの追加処理が行われます。(Microsoft Learn)
アプリ担当者は、次の点を確認してください。
- アプリがモダン認証に対応しているか
- UPN変更やAlternate ID利用時にアプリ側のユーザー識別が崩れないか
- 条件付きアクセスでMFAやデバイス条件が追加されても正常に動作するか
- 非対話型認証や古いプロトコルに依存していないか
- サインイン失敗時にユーザーへ適切な案内を出せるか
- アプリ側で独自にパスワードを保持、検証していないか
PTAは、アプリに直接パスワードを渡す仕組みではありません。アプリはMicrosoft Entra IDが発行するトークンを検証する設計を維持し、認証フローの詳細をアプリ内で抱え込まないことが大切です。
サポートされるシナリオと制限事項
PTAは、Webブラウザーベースのアプリ、モダン認証を使うOfficeクライアント、Microsoft Entra参加やハイブリッド参加のWindowsデバイスなどをサポートします。一方で、すべてのMicrosoft Entra機能をPTA単独で満たせるわけではありません。(Microsoft Learn)
特に注意したい制限は次のとおりです。
| 制限事項 | 実務上の影響 |
|---|---|
| 漏えい資格情報の検出はPTA単独では対応しない | Microsoft Entra ID Protection を使う場合、パスワード ハッシュ同期も検討する |
| Microsoft Entra Domain Services にはパスワード ハッシュ同期が必要 | Entra Domain Services 利用環境ではPTA単独構成にしない |
| Microsoft Entra Connect Health とPTAは統合されない | エージェント状態、イベントログ、サインインログを別途監視する |
| 一時パスワードや期限切れパスワードでのEntra参加デバイスサインインに制限あり | ユーザー案内とパスワード変更手順を整備する |
| PTAからPHSへのフェールオーバーは自動ではない | 障害時の手動切り替え手順を事前に準備する |
Microsoft の制限事項ページでは、Microsoft Entra Domain Services がパスワード ハッシュ同期を必要とすること、PTAがMicrosoft Entra Connect Healthと統合されないこと、一時または期限切れパスワードでのMicrosoft Entra参加デバイスへのサインインがサポートされないことが示されています。(Microsoft Learn)
よくある障害と切り分けポイント
PTAのサインイン障害では、Microsoft Entra IDだけでなく、Authentication Agent、Active Directory、ネットワーク、ユーザー属性を順番に確認する必要があります。
| エラー・症状 | 主な原因 | 確認すべきこと |
|---|---|---|
| AADSTS80001 | Active Directoryへ接続できない | エージェントが対象ユーザーと同じADフォレストに参加しているか |
| AADSTS80002 | AD接続タイムアウト | ドメイン コントローラーの応答、ネットワーク遅延 |
| AADSTS80004 | ユーザー名が不正 | UPN、Alternate ID、入力ユーザー名 |
| AADSTS80007 | AD通信エラー | AD状態、エージェントログ |
| invalid username/password | オンプレミスUPNとクラウドUPNの不一致など | UPN同期、代替ログインID、テストアカウント |
Microsoft のトラブルシューティングでは、Pass-through Authentication が有効であること、Authentication Agent が Active であることを最初に確認するよう案内されています。また、UPN不一致によるユーザー名・パスワードエラーや、サインイン エラーコードごとの原因も整理されています。(Microsoft Learn)
Active Directory の「Log On To」設定でログオン可能なワークステーションを制限している場合も注意が必要です。PTAエージェントはWin32 LogonUser APIを使ってADに対して認証するため、PTAエージェント サーバーを許可リストに含めないと、Microsoft Entra IDへのサインインがブロックされる可能性があります。(Microsoft Learn)
PTA運用で失敗しやすいポイント
Microsoft Entra パススルー認証の運用でよくある失敗は、次のようなものです。
1台構成のまま本番利用している
検証環境では1台でも動作しますが、本番ではサーバー停止や更新のたびにサインイン影響が出ます。最低3台を目安に、複数サイトやドメイン コントローラーとの距離も考えて配置してください。
パスワード ハッシュ同期を無効のままにしている
PTAを選ぶ理由があっても、PHSをバックアップ認証方式やID Protection用途として併用できないか検討する価値があります。特に、ランサムウェアやネットワーク障害でオンプレミス基盤が止まった場合、PHSを事前に有効化していたかどうかが復旧速度に影響します。(Microsoft Learn)
エージェントサーバーを通常サーバー扱いしている
PTAエージェントサーバーは、パスワード検証に関わる重要なサーバーです。一般的なアプリケーションサーバーと同じ権限管理、監視レベルでは不十分です。
AD FS停止を急ぎすぎる
AD FSからPTAへ切り替えた直後に旧基盤を停止すると、一部クライアントや移行中の認証フローで問題が発生したときに切り戻しが難しくなります。切り替え後の監視期間を設け、主要クライアントの成功率を確認してから段階的に停止してください。
UPNとサインインIDを軽視している
オンプレミスUPN、クラウドUPN、メールアドレス、Alternate IDが混在している環境では、ユーザーは「正しいパスワードを入れているのに失敗する」と感じます。PTA移行前に、サインインIDの設計を整理しておくことが重要です。
これから対応する管理者向けチェックリスト
最後に、Microsoft Entra パススルー認証を使う管理者が今すぐ確認すべき項目を整理します。
| 優先度 | 対応 | 完了の目安 |
|---|---|---|
| 高 | Microsoft Entra 管理センターでPTAとエージェント状態を確認 | Enabled / Active を確認できる |
| 高 | クラウド専用の管理者アカウントを用意 | オンプレミス障害時も管理画面へ入れる |
| 高 | Authentication Agentを最低3台構成にする | 単一障害点を避けられる |
| 高 | PHS併用と手動フェールオーバー手順を確認 | 障害時の認証方式切り替えを説明できる |
| 中 | AD FS移行環境の切り戻し手順を作る | 停止前に検証・監視期間を確保できる |
| 中 | 条件付きアクセス、MFA、レガシ認証ブロックを確認 | 認証強度を維持できる |
| 中 | UPN、Alternate ID、アプリ側ユーザー識別を確認 | サインインIDの不一致を減らせる |
| 中 | エージェントサーバーをTier 0相当で保護 | 権限、監視、更新、ログ管理が整備される |
| 低 | エラーコード別の一次対応表をヘルプデスクへ共有 | 問い合わせ時の切り分けが早くなる |
Microsoft Entra パススルー認証は、オンプレミス Active Directory のポリシーを活かしながら、Microsoft Entra ID の条件付きアクセスやMFAと組み合わせられる実用的な認証方式です。ただし、オンプレミス基盤に依存する以上、エージェントの冗長化、PHSとの併用、緊急管理者アカウント、移行テストを省略すると、障害時に大きな影響が出ます。まずは現在のエージェント台数と状態、PHSの有効化方針、AD FS移行の有無を確認し、自社のサインイン基盤が「普段動く」だけでなく「障害時にも復旧できる」構成になっているか見直してください。
コメント