Microsoft Entraのセルフサービス パスワード リセット（SSPR）で再設定が完了しても、社内のActive Directory Domain Services（AD DS）に新しいパスワードが反映されない場合は、同期方式を確認したうえで、Microsoft Entra ConnectサーバーからService Busへの通信を切り分ける必要があります。
Microsoft Entra Connectを使用している環境では、WindowsのApplicationログからイベントID「31034」または「31019」を探し、実際に接続しているService Busのホスト名を特定します。そのホストに対してTCP 443の外向き通信を確認するのが、最初の具体的な調査です。
ただし、通信に成功しても、AD側の権限不足やパスワードポリシー違反は残ります。この記事では、同期方式の確認からイベントログ、通信テスト、管理者が次に調べるべき項目まで順番に解説します。([Microsoft Learn][1])
SSPRのパスワードライトバックとは
Microsoft Entra SSPRでは、利用者がクラウド上から自分のパスワードを再設定できます。
対象がオンプレミスADから同期されたユーザーの場合、クラウドで設定した新しいパスワードを社内ADへ返す仕組みが「パスワードライトバック」です。ライトバックには、主に次の2方式があります。
| 方式 | オンプレミス側の構成 | 主な確認場所 |
|---|---|---|
| Microsoft Entra Connect Sync | Entra Connectサーバー | WindowsのApplicationログ、Entra Connect構成 |
| Microsoft Entra Cloud Sync | Cloud Syncプロビジョニングエージェント | Cloud Sync構成、プロビジョニングエージェント |
| クラウド専用ユーザー | オンプレミス側の同期元なし | 社内ADへの書き戻し対象外 |
Microsoft Entra ConnectとCloud Syncは、異なるドメインやユーザー範囲を対象として併用される場合があります。そのため、「組織でどちらを導入しているか」だけでなく、問題が発生しているユーザーをどちらの方式が担当しているかまで確認しなければなりません。([Microsoft Learn][1])
この記事では、Microsoft Entra Connect Syncを利用している環境の通信障害を中心に説明します。Cloud Syncを利用している場合は、Entra Connectサーバー向けの手順をそのまま適用せず、プロビジョニングエージェント側を確認してください。
最初に確認する切り分け順序
SSPRの書き戻し障害は、次の順番で確認すると原因を絞り込みやすくなります。
| 順番 | 確認内容 | 判断できること |
|---|---|---|
| 1 | 対象ユーザーと同期方式 | 誤ったサーバーや方式を調査していないか |
| 2 | Applicationログ | 書き戻し要求やService Bus接続の状態 |
| 3 | 実際のService BusへのTCP 443通信 | ファイアウォールやネットワークによる遮断 |
| 4 | TLS、.NET、同期サービス | Entra Connectサーバー側の実行環境 |
| 5 | AD権限とパスワードポリシー | 通信後にADへの設定が失敗していないか |
いきなりサービスを再起動したり、パスワードライトバックを無効化・再有効化したりするのではなく、先にログと接続先を記録することが重要です。
対象ユーザーと同期方式を確認する
最初に、問題が発生しているユーザーがパスワードライトバックの対象であることを確認します。
確認すべき項目は次のとおりです。
- ユーザーがオンプレミスADに存在する
- そのユーザーがMicrosoft Entra IDへ同期されている
- 現在調査しているEntra Connectインスタンスの同期対象に含まれている
- Microsoft Entra ConnectとCloud Syncのどちらが担当しているか判明している
- SSPRのオンプレミス統合でパスワードライトバックが有効になっている
- 複数フォレストや複数同期サーバーがある場合、対象ユーザーの同期元が特定できている
Microsoftのトラブルシューティング情報でも、対象ユーザーが現在のMicrosoft Entra Connectインスタンスを通じて同期されているか確認するよう案内されています。ユーザーオブジェクトが同期エンジン内で正しく関連付けられていなければ、通信が正常でもライトバックは成功しません。([Microsoft Learn][1])
SSPR画面でパスワードの再設定が完了したことは、社内ADへの書き戻しまで完了したことを意味しません。クラウド側での本人確認と、オンプレミス側へのライトバックは分けて考えます。
Applicationログでイベント31034と31019を確認する
Microsoft Entra Connectサーバーで、イベントビューアーを開きます。
確認場所は次のとおりです。
イベント ビューアー
└ Windows ログ
└ ApplicationSSPRを実行した時刻の前後を中心に、イベントソースが「PasswordResetService」または「ADSync」になっているイベントを確認します。
特に重要なのが、次のイベントです。
| イベントID | 意味 | 次に確認すること |
|---|---|---|
| 31019 | テナントのService Busへ要求を正常に送信した | ユーザー操作時の開始・成功・失敗イベント |
| 31034 | Service Busリスナーへの接続でエラーが発生した | 接続先名、TCP 443、証明書、TLS |
| 31001 | パスワードリセット要求をオンプレミス側が検出した | 続く31002または31003 |
| 31002 | パスワードリセットの書き戻しに成功した | 操作完了 |
| 31003 | 要求は到達したが、ADへのパスワード設定に失敗した | AD権限、ポリシー、保護されたアカウント |
| 31006 | パスワード変更要求を検出した | 続く31007または31008 |
| 31007 | パスワード変更の書き戻しに成功した | 操作完了 |
| 31008 | 変更要求は到達したが、ADへの設定に失敗した | AD権限、ポリシー、アカウント状態 |
31034は、テナントのService Busリスナーへ接続できなかったことを示します。一方、31019はService Busへのハートビート送信が成功したことを示します。イベントの詳細に表示されるService Busの名前は、後続の通信テストで使用するため正確に記録してください。([Microsoft Learn][1])
記録しておく情報は次のとおりです。
- イベント発生日時
- イベントID
- イベントソース
- Service Busの名前または完全修飾ドメイン名
- エラーメッセージ
- SSPRを実行した時刻
- パスワードの「リセット」か「変更」か
31019が定期的に記録されていても、特定ユーザーのライトバックが成功するとは限りません。31019はService Busとの通信状態を判断する材料であり、AD側の権限やパスワードポリシーまでは確認できないためです。
実際のService Busに対してTCP 443を確認する
Applicationログから接続先を確認したら、Microsoft Entra Connectサーバー上でPowerShellを開き、TCP 443への接続をテストします。
イベントログに完全なホスト名が記録されている場合は、その名前をそのまま使用します。
Test-NetConnection `
-ComputerName <イベントログで確認したService Busのホスト名> `
-Port 443イベントログに名前空間だけが表示されている場合は、パブリッククラウド環境では次の形式になります。
Test-NetConnection `
-ComputerName <namespace>.servicebus.windows.net `
-Port 443次はコマンドの書式例であり、実際の環境で測定したホスト名ではありません。
Test-NetConnection `
-ComputerName ssprdedicatedsbprodxxx-1.servicebus.windows.net `
-Port 443結果では、主に次の項目を確認します。
TcpTestSucceeded : True判定の目安は次のとおりです。
| 結果 | 判断 | 次の調査 |
|---|---|---|
True | 対象ホストのTCP 443へ接続できた | HTTPS、TLS、証明書、サービス、AD側の調査 |
False | TCP 443へ接続できない | DNS、ファイアウォール、経路、プロキシ構成 |
| 名前解決エラー | ホスト名を解決できない | DNSサーバー、外部名前解決、入力した名前 |
| タイムアウト | 通信が破棄または遮断されている可能性 | ファイアウォール、経路、プロキシ、タイムアウト設定 |
Microsoftの手順では、追加の確認方法として次のコマンドも案内されています。
Invoke-WebRequest `
-Uri https://<namespace>.servicebus.windows.net `
-VerboseTest-NetConnectionが成功しても、パスワードライトバック全体が正常とは断定できません。TCP接続は、ADの権限、パスワードポリシー、同期対象、Service Busとのアプリケーション通信まで保証するものではないためです。([Microsoft Learn][1])
ファイアウォールとプロキシを確認する
Microsoft Entra Connectのパスワードライトバックでは、Entra Connectサーバーからクラウドへの外向きHTTPS通信が必要です。
パブリッククラウドでは、主に次の宛先が使用されます。
*.passwordreset.microsoftonline.com
*.servicebus.windows.netファイアウォールやプロキシでURLを制限している場合は、次の点を確認します。
- Entra Connectサーバーから外向きTCP 443が許可されている
- Service Busのドメインが許可対象になっている
- パスワードリセットサービスのドメインが許可対象になっている
- 接続を短時間で切断するアイドルタイムアウトが設定されていない
- HTTPS検査によって証明書エラーが発生していない
- イベントログに記録された実際の接続先が許可されている
- プロキシやファイアウォールの変更履歴と障害発生時刻が一致していないか
イベント31034にリモート証明書が無効である旨のエラーが含まれている場合は、Microsoft Entra Connectサーバーが必要なルート証明書を信頼できているかも確認します。HTTPS検査装置が通信を再署名している環境では、ネットワーク管理者による証明書チェーンの確認が必要です。([Microsoft Learn][1])
国別クラウドでは接続先が異なる
パブリッククラウド用の接続先を、US Governmentや中国の21Vianet環境へそのまま適用してはいけません。
| クラウド | 主な接続先の形式 |
|---|---|
| パブリッククラウド | *.passwordreset.microsoftonline.com、*.servicebus.windows.net |
| Azure US Government | *.passwordreset.microsoftonline.us、*.servicebus.usgovcloudapi.net |
| Azure China 21Vianet | .servicebus.chinacloudapi.cnを使用する指定ホスト |
国別クラウドを利用している場合は、環境に対応したMicrosoft公式のエンドポイント一覧を確認してください。([Microsoft Learn][1])
TLS 1.2と.NET Frameworkを確認する
ネットワーク経路に問題が見つからない場合は、Microsoft Entra Connectサーバーの実行環境を確認します。
TLS 1.2
Microsoftのトラブルシューティング手順では、同期サーバーでTLS 1.2が正しく有効になっているか確認するよう案内されています。
確認時は、Microsoftが公開しているTLS 1.2確認用スクリプトを管理者権限で実行します。設定を変更した場合は、サーバー再起動が必要になることがあります。
レジストリを独自判断で変更するのではなく、現在のOS、Microsoft Entra Connectのバージョン、組織のセキュリティ基準を確認したうえで実施してください。
.NET Framework
パスワードライトバックのトラブルシューティングでは、同期サーバーで.NET Framework 4.8以降が有効になっていることを確認します。
.NET Frameworkの更新はMicrosoft Entra Connectだけでなく、同じサーバー上の他のアプリケーションにも影響する可能性があります。適用前に再起動の要否や業務影響を確認してください。([Microsoft Learn][1])
Microsoft Entra Connect Syncサービスを確認する
Windowsのサービス管理画面で、同期サービスの状態を確認します。
services.mscサービス一覧では、表示名「Azure AD Sync」を探します。
停止している場合や、一時的な接続障害が疑われる場合は、管理者がサービス再起動を検討します。Microsoftの手順でも、同期サービスの再起動によってMicrosoft Entra IDとの接続を再確立する方法が案内されています。([Microsoft Learn][1])
ただし、サービス再起動は同期処理やパスワードライトバックを一時的に停止させます。次の項目を確認してから実施してください。
- 実行中の同期処理がないか
- 業務時間中に停止して問題ないか
- 冗長構成やステージングサーバーの運用ルール
- 変更申請や作業承認が必要か
- 再起動前のイベントログを保存したか
原因調査の前に再起動すると、障害時のログが追いにくくなることがあります。先にイベントIDと接続先を記録しておくことが重要です。
ライトバックの無効化・再有効化は最後に行う
サービス再起動でも改善しない場合、Microsoft Entra Connect構成ウィザードでパスワードライトバックを一度無効化し、再度有効化する方法があります。
この操作によって、Microsoft Entra IDとのライトバック構成が再設定されます。ただし、設定変更中はパスワードライトバックを利用できないため、安易に実行すべきではありません。
実施前に確認する内容は次のとおりです。
- 現在のEntra Connect構成
- 対象フォレスト
- 使用している管理者アカウント
- カスタム同期ルールの有無
- 作業中のライトバック停止による影響
- 元の設定に戻す手順
- 変更前後のイベントログ
Microsoft Entra Connect自体を更新する場合は、カスタム同期ルールを事前にバックアップします。再インストールやアップグレードは、通信、TLS、サービス状態を確認した後の対応とします。([Microsoft Learn][1])
通信が正常ならAD側の権限とポリシーを確認する
TcpTestSucceeded : Trueで、イベント31019も記録されている場合は、ネットワーク以外の原因へ調査を進めます。
特に、イベント31001の後に31003が記録されている場合、クラウドからのパスワードリセット要求はオンプレミスまで到達しています。失敗箇所は、その後のADへのパスワード設定処理である可能性が高くなります。
Entra ConnectのADアカウントに権限があるか
Microsoft Entra Connectがパスワードを書き戻すには、同期に使用するADアカウントに対象ユーザーの「パスワードのリセット」権限が必要です。
権限がOU単位で委任されている環境では、次の点を確認します。
- 対象ユーザーが権限委任済みOUに存在する
- 子OUへの権限継承が無効になっていない
- 同期用アカウントが変更されていない
- 特定ユーザーだけ異なるアクセス制御になっていない
- 保護された管理者グループのアカウントではないか
Microsoftの手順では、Synchronization Service Managerで使用中のAD DSアカウントを特定し、Active Directoryユーザーとコンピューターの「有効なアクセス」で「パスワードのリセット」権限を確認します。([Microsoft Learn][1])
社内ADのパスワードポリシーに違反していないか
クラウドで入力を受け付けても、オンプレミスADのポリシーを満たさなければ書き戻しは失敗します。
主な確認項目は次のとおりです。
- パスワードの最小文字数
- 複雑さの要件
- パスワード履歴
- パスワードの最小有効期間
- 独自のパスワードフィルター
- ユーザーにパスワード変更禁止属性が設定されていないか
- Fine-Grained Password Policyが適用されていないか
ApplicationログのADSyncイベント6329は、最小有効期間、履歴、複雑さ、フィルターなどの制限によって、指定したパスワードへ変更できなかった場合に記録されることがあります。([Microsoft Learn][1])
テストのために本番環境のパスワードポリシーを安易に緩和してはいけません。まず対象ユーザーに適用されているポリシーを特定し、その要件を満たす別のパスワードで確認します。
症状から次の調査先を判断する
| 確認結果 | 考えられる状態 | 次に行うこと |
|---|---|---|
| 31034があり、TCP 443も失敗 | Service Busへの通信を遮断 | ファイアウォール、DNS、プロキシを確認 |
| 31034に証明書エラーがある | TLS検査または証明書信頼の問題 | 証明書チェーン、ルートCAを確認 |
| 31019が定期的に記録される | Service Busとの基本通信は成立 | 操作時の31001～31008を確認 |
| 31001の後に31003 | リセット要求は到達したがAD設定に失敗 | 権限、ポリシー、保護アカウントを確認 |
| 31006の後に31008 | 変更要求は到達したがAD設定に失敗 | 権限、ポリシーを確認 |
| 31001や31006が記録されない | 対象範囲や同期方式が異なる可能性 | ConnectとCloud Sync、ユーザースコープを再確認 |
| 31002または31007 | 書き戻し処理は成功 | 利用者の操作対象や認証先を確認 |
「クラウドで再設定できた」「TCP 443に接続できた」という1つの結果だけで、原因を判断しないことが重要です。イベントの時系列を追い、どこまで処理が進んだかを確認します。
管理者へ引き継ぐ情報を整理する
自分でネットワークやEntra Connectの設定を変更できない場合は、次の情報を整理して管理者へ渡します。
発生日時：
対象ユーザー：
操作内容：パスワードリセット／パスワード変更
同期方式：Entra Connect Sync／Cloud Sync／未確認
Entra Connectサーバー：
確認したイベントID：
イベントソース：
Service Busの接続先：
Test-NetConnectionの結果：
TLS 1.2の確認結果：
.NET Frameworkの状態：
Azure AD Syncサービスの状態：
直近のネットワーク・プロキシ変更：イベントログやPowerShellの結果を共有するときは、ユーザー情報、テナント情報、サーバー名などの取り扱いに注意してください。パスワードや管理者資格情報は記録・送付しません。
SSPRの書き戻し障害は「どこまで届いたか」で判断する
Microsoft Entra SSPRで社内ADのパスワードが変わらない場合は、次の順番で確認します。
- 対象ユーザーがオンプレミスADから同期されているか確認する
- Entra Connect SyncとCloud Syncのどちらが担当しているか特定する
- Applicationログで31034、31019、31001～31008を確認する
- イベントログから実際のService Bus接続先を記録する
Test-NetConnectionでTCP 443を確認する- ファイアウォール、プロキシ、TLS 1.2、.NETを確認する
- Azure AD Syncサービスの状態を確認する
- 通信が正常ならADの権限とパスワードポリシーを調べる
最初に行うべき作業は、サービス再起動や設定変更ではありません。同期方式、イベントID、実際の接続先を記録し、クラウドからの要求がどこまで届いているかを確認することです。
[1]: https://learn.microsoft.com/en-us/entra/identity/authentication/troubleshoot-sspr-writeback “Troubleshoot self-service password reset writeback – Microsoft Entra ID | Microsoft Learn”
コメント