MENU

Microsoft Entra SSPRで社内ADへパスワードを書き戻せないときの確認手順

Active Directory

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])

ITtripTOOLS
その「面倒」、無料で解決。 ITtripがつくる、6つの道具。 無料ツール一覧へ すべて無料・追加課金なし
先頭0を守るCSV編集こわさないCSV PDFに直接書き込みかけるPDF 写真＋説明をPDFに写レポ スマホ⇄PCで共有コピペ便 · 文章・写真 みんなの日程を調整日程Fit 匿名質問・投票を集めるKOEQ
目次

SSPRのパスワードライトバックとは

Microsoft Entra SSPRでは、利用者がクラウド上から自分のパスワードを再設定できます。

対象がオンプレミスADから同期されたユーザーの場合、クラウドで設定した新しいパスワードを社内ADへ返す仕組みが「パスワードライトバック」です。ライトバックには、主に次の2方式があります。

方式オンプレミス側の構成主な確認場所
Microsoft Entra Connect SyncEntra ConnectサーバーWindowsのApplicationログ、Entra Connect構成
Microsoft Entra Cloud SyncCloud SyncプロビジョニングエージェントCloud Sync構成、プロビジョニングエージェント
クラウド専用ユーザーオンプレミス側の同期元なし社内ADへの書き戻し対象外

Microsoft Entra ConnectとCloud Syncは、異なるドメインやユーザー範囲を対象として併用される場合があります。そのため、「組織でどちらを導入しているか」だけでなく、問題が発生しているユーザーをどちらの方式が担当しているかまで確認しなければなりません。([Microsoft Learn][1])

この記事では、Microsoft Entra Connect Syncを利用している環境の通信障害を中心に説明します。Cloud Syncを利用している場合は、Entra Connectサーバー向けの手順をそのまま適用せず、プロビジョニングエージェント側を確認してください。

最初に確認する切り分け順序

SSPRの書き戻し障害は、次の順番で確認すると原因を絞り込みやすくなります。

順番確認内容判断できること
1対象ユーザーと同期方式誤ったサーバーや方式を調査していないか
2Applicationログ書き戻し要求やService Bus接続の状態
3実際のService BusへのTCP 443通信ファイアウォールやネットワークによる遮断
4TLS、.NET、同期サービスEntra Connectサーバー側の実行環境
5AD権限とパスワードポリシー通信後に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 ログ
      └ Application

SSPRを実行した時刻の前後を中心に、イベントソースが「PasswordResetService」または「ADSync」になっているイベントを確認します。

特に重要なのが、次のイベントです。

イベントID意味次に確認すること
31019テナントのService Busへ要求を正常に送信したユーザー操作時の開始・成功・失敗イベント
31034Service 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側の調査
FalseTCP 443へ接続できないDNS、ファイアウォール、経路、プロキシ構成
名前解決エラーホスト名を解決できないDNSサーバー、外部名前解決、入力した名前
タイムアウト通信が破棄または遮断されている可能性ファイアウォール、経路、プロキシ、タイムアウト設定

Microsoftの手順では、追加の確認方法として次のコマンドも案内されています。

Invoke-WebRequest `
  -Uri https://<namespace>.servicebus.windows.net `
  -Verbose

Test-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のパスワードが変わらない場合は、次の順番で確認します。

  1. 対象ユーザーがオンプレミスADから同期されているか確認する
  2. Entra Connect SyncとCloud Syncのどちらが担当しているか特定する
  3. Applicationログで31034、31019、31001～31008を確認する
  4. イベントログから実際のService Bus接続先を記録する
  5. Test-NetConnectionでTCP 443を確認する
  6. ファイアウォール、プロキシ、TLS 1.2、.NETを確認する
  7. Azure AD Syncサービスの状態を確認する
  8. 通信が正常なら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”

Active Directory
Active Directory Microsoft Entra ID SSPR Entra Connect

この記事を書いた人

佐藤健司のアバター 佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

関連記事

コメント

コメントする

目次