SuccessFactors からオンプレミス Active Directory へユーザーを自動作成する Azure AD（現 Microsoft Entra ID）プロビジョニングで、突然オンデマンド実行だけが失敗することがあります。本記事では HybridSynchronizationActiveDirectoryCredentialValidationFailure の原因・切り分け・運用上の備えを、実務目線でまとめます。
現象：オンデマンド プロビジョニングだけが失敗する
「SuccessFactors → Active Directory ユーザー プロビジョニング」を利用している環境で、初回同期（定期同期）は成功していたにもかかわらず、オンプレミス プロビジョニング エージェントを配置したサーバーを再起動した後から、オンデマンド プロビジョニング（ポータルからの即時実行）が失敗し始めるケースがあります。
代表的なエラーが次のものです。
HybridSynchronizationActiveDirectoryCredentialValidationFailure
エラーメッセージは「オンプレミス ディレクトリとの通信中に不正な応答を受信した」「オンプレミス エージェントの状態やサービスを確認せよ」といった趣旨で表示され、パッと見はオンプレ側のエージェント／資格情報（Credential）の問題に見えます。しかし、実際には別の原因で発生していた事例が報告されています。
| よくある状況 | 管理者がハマりやすい推測 | 実際に起きていたこと（今回のケース） |
|---|---|---|
| Azure ポータル上のエージェント状態が「アクティブ（緑）」 | 「通信できている＝AD 接続も問題ないはず」 | 「アクティブ」は疎通・ハートビートの指標であり、オンデマンド実行時の接続確立・ドメイン設定適用まで保証しない |
| オンプレ側サービスが稼働している | 「サービスが動くなら資格情報も問題ない」 | サービス稼働は前提条件に過ぎず、クラウド側ジョブの初期化不具合で接続先情報が欠けると失敗する |
| 再起動を境に失敗し始めた | 「再起動で設定が飛んだ／証明書が壊れた」 | 同時期（2022/5/6 前後）に複数テナントで同一障害が発生しており、環境差よりサービス側要因が濃厚だった |
前提整理：SuccessFactors → オンプレ AD プロビジョニングの構成
切り分けを正しく進めるには、処理がどこで起きているかを把握するのが近道です。SuccessFactors からオンプレ AD へのプロビジョニングは、大まかに「クラウド側のプロビジョニング サービス」と「オンプレ側のプロビジョニング エージェント」で分担されます。
| 要素 | 配置場所 | 役割 | 障害が起きたときの見え方 |
|---|---|---|---|
| SuccessFactors（HR ソース） | クラウド | 従業員データ（入社・異動・退職など）を提供 | コネクタ設定の誤りだと取得自体が失敗しやすい |
| Azure AD / Microsoft Entra ID プロビジョニング サービス | クラウド | マッピング・ルール評価、オンデマンド／定期ジョブの実行、オンプレへの指示 | サービス側障害でもポータル表示は正常に見えることがある |
| オンプレミス プロビジョニング エージェント | オンプレ（Windows Server） | クラウドからの要求を受け、AD DS へ実際の作成・更新を実行 | 停止すると状態が「非アクティブ」になりやすいが、稼働中でも別要因で失敗する |
| Active Directory Domain Services（AD DS） | オンプレ | ユーザー／属性の格納先（ターゲット） | DC 障害、LDAP/LDAPS、権限不足などで失敗する |
| サービス アカウント（AD 書き込み権限） | オンプレ | ユーザー作成・更新の実行主体 | パスワード期限切れや権限変更は典型的原因 |
今回のポイントは、オンプレ側（エージェントや AD）だけを疑って深掘りすると遠回りになり得ることです。とくにオンデマンド プロビジョニングは、ジョブの初期化や接続先の解決など、クラウド側の内部処理に依存します。
よく混同される「Azure AD Connect」との違い
同じ「同期」「ユーザー作成」という言葉が出るため、Azure AD Connect（ディレクトリ同期）と混同されがちです。しかし、SuccessFactors → オンプレ AD プロビジョニングはクラウド主導で、目的も経路も異なります。切り分けを間違えないために、違いを押さえておくと便利です。
| 観点 | SuccessFactors → オンプレ AD（今回） | Azure AD Connect（参考：よくある同期） |
|---|---|---|
| 起点 | SuccessFactors（HR） | オンプレ AD |
| 主役 | Azure AD / Entra のプロビジョニング サービス＋オンプレ エージェント | Azure AD Connect サーバー（同期エンジン） |
| 目的 | 入社・異動情報からオンプレ AD のユーザーを作る／更新する | オンプレ AD のアカウントを Azure AD へ同期する |
| 障害の見方 | プロビジョニング ログ、オンプレ エージェント、クラウド側ジョブ | 同期サービス、コネクタ スペース、メタバース、同期ルールなど |
オンデマンドと定期同期の違い：なぜ「オンデマンドだけ」落ちるのか
運用現場で一番混乱しやすいのが、「定期は動いているのにオンデマンドだけ失敗する」状況です。オンデマンドは便利な反面、内部的には定期ジョブと異なる初期化処理や呼び出し経路が使われることがあり、サービス側の変更の影響を受けやすい場合があります。
| 項目 | オンデマンド | 定期同期（スケジュール） |
|---|---|---|
| 主な用途 | 特定ユーザーを即時に反映、テスト、トラブルシュート | 全体を継続的に反映（通常運用） |
| 失敗の影響 | 対象ユーザーに限定されやすいが、入社対応などで致命的になり得る | 大量に滞留すると組織全体に影響 |
| 切り分けの勘所 | 「オンデマンド固有の経路」も疑う（今回のようにサービス側が原因になり得る） | 権限・属性マッピング・対象スコープなど構成要因が表に出やすい |
原因：Microsoft 側のサービス不具合（構成変更がなくても発生）
結論から言うと、当該エラーは個々の環境設定ミスではなく、Microsoft 側サービスの不具合が原因だった、と説明されています。
Microsoft の回答として共有された根本原因は、次のようなものです。
- HR（SuccessFactors）→ オンプレ AD へのプロビジョニング ジョブの内部コードをリファクタリングした
- その不具合により、ジョブ初期化時にドメイン設定を適用できなくなった
- 結果として、オンデマンド プロビジョニング時にターゲットのオンプレ AD に接続できない状態になった
また、同時期（2022/5/6 前後）に複数の利用者がまったく同じエラーを報告しており、「自分たち／顧客側では構成変更をしていない」というコメントが重なっていた点が、サービス側障害を強く示唆します。
| 「サービス側障害」を疑う強いサイン | なぜ重要か | 次のアクション |
|---|---|---|
| 自環境で変更していないのに突然失敗 | 構成差より、外部要因（サービス更新・障害）の可能性が上がる | 変更履歴の棚卸し（本当に変更ゼロか）＋サービス正常性の確認へ |
| 同じタイミングで複数テナントが同一エラー | 局所的なネットワーク／資格情報の問題では説明しにくい | コミュニティ報告やサポート情報を参照し、問い合わせを準備 |
| 定期同期は動くがオンデマンドだけが失敗 | 同じ構成でも実行経路が異なる可能性がある | オンデマンド固有の問題（クラウド側実装）を視野に入れる |
解決策：クラウド側修正のデプロイで自然復旧
Microsoft のエンジニアリング チームが問題を認識した後、クラウド側のコード修正が行われ、デプロイ完了後は次の状態になったとされています。
- テナント側で構成を変更しなくても
- オンデマンド プロビジョニングが再び正常動作する
実際の利用者報告としても、「特に設定変更を行わないまま、数時間〜翌日には正常に動くようになった」という確認が複数見られました。つまり、エージェントの再インストールや構成の作り直しが必須だったわけではない、という点が運用上とても重要です。
まずやるべき切り分け：オンプレ要因かサービス要因かを早く判定する
エラー名に「CredentialValidation」と付いていると、どうしても「アカウントのパスワード」「権限」「LDAP」の方向へ突っ込みたくなります。ただし、今回のようにサービス側が原因のケースもあるため、確認順序を工夫すると被害を減らせます。
| 最短で迷わない判断フロー | YES の場合 | NO の場合 |
|---|---|---|
| エージェントが非アクティブ（灰/赤）か？ | オンプレ側（サービス停止、通信、登録状態）を最優先で復旧 | 次の判定へ |
| 失敗がオンデマンドに偏っているか？ | オンデマンド固有の経路・サービス側影響も疑う | 定期も落ちているなら、権限・ネットワーク・スコープ等の構成要因も濃厚 |
| 同時期に同一エラー報告が多発しているか？ | サービス障害の可能性が高い。サービス正常性確認＋サポート準備 | 自環境要因の可能性が高い。オンプレ/構成の差分を丁寧に洗う |
| 確認ポイント | 見る場所／やり方 | OK の目安 | NG だった場合の次手 |
|---|---|---|---|
| プロビジョニング ログの詳細 | Azure ポータルの「プロビジョニング ログ」で失敗イベントを開く | 失敗理由、操作種別（On-demand か）、コリレーション ID が確認できる | コリレーション ID と時刻を控えてサポートに提示できる形にする |
| オンプレ エージェントの状態 | Azure ポータルでエージェントが「アクティブ」かを確認 | アクティブ（緑） | 非アクティブなら、サービス起動・ネットワーク・登録状態を優先確認 |
| エージェント サービスの稼働 | オンプレ サーバーのサービス管理でエージェント関連サービスを確認 | 起動中、再起動後も自動起動している | 停止／頻繁な再起動ならイベントログで原因を追う |
| ネットワーク変更の有無 | ファイアウォール／プロキシ／ルーティング変更、証明書更新、OS パッチ適用など | 変更なし、または変更があっても想定内で影響を説明できる | 変更があれば差分を戻す／例外設定を追加して再試行 |
| サービス アカウントの状態 | パスワード期限、ロック、権限（OU 作成権限など） | 期限切れなし、ロックなし、必要権限あり | 更新後にオンデマンドで再試行（ただし同時多発ならサービス側も疑う） |
| 同時多発の兆候 | コミュニティや社内の複数テナント、顧客から同時期に報告がないか | 単発 | 多発ならサービス障害の可能性が高い。情報収集・サポート連絡を優先 |
再起動直後にやると効果的な「3つのワンポイント確認」
今回の事例では再起動がトリガーのように見えましたが、再起動後はオンプレ側の問題も起きやすいのは事実です。サービス障害の可能性も残しつつ、再起動直後に次の 3 点だけは機械的に確認すると、ムダな疑心暗鬼を減らせます。
- エージェント関連サービスが想定どおり自動起動しているか（遅延起動や依存サービスで待たされていないか）
- サーバーの時刻ずれがないか（認証や TLS で予期せぬ失敗を起こしやすい）
- プロキシ／FW のポリシー変更が直前に入っていないか（再起動のタイミングで適用されることがある）
サポート連絡の前に準備しておくと早い情報
Microsoft サポートに問い合わせる場合、ログの「どこを渡すか」で初動の速度が変わります。以下の情報をセットで整理しておくと、やり取りが短くなりやすいです。
| 項目 | 例 | なぜ必要か |
|---|---|---|
| 発生日時（タイムゾーン含む） | 2022-05-06 10:15 JST | サービス側で同時間帯の障害・デプロイ履歴と突合できる |
| エラーコード | HybridSynchronizationActiveDirectoryCredentialValidationFailure | 分類・既知問題の照合に直結する |
| コリレーション ID / リクエスト ID | （ポータルの詳細に表示される ID） | クラウド側のトレースで原因追跡が可能になる |
| 影響範囲 | オンデマンドのみ／定期も含む、特定 OU のみ等 | 再現経路と原因切り分けのヒントになる |
| オンプレ側の変更履歴 | サーバー再起動、パッチ適用、プロキシ設定変更など | 「変更なし」と言い切れる根拠があると調査が早い |
復旧を急ぐときの現実的な対応（やって良いこと／避けたいこと）
サービス側障害が疑わしい局面では、復旧を焦って大掛かりな変更を入れるほど、復旧後に「何が効いたのか」が分からなくなります。そこで、実務的におすすめの整理を載せます。
| 対応 | おすすめ度 | 理由 | 実施するときのコツ |
|---|---|---|---|
| プロビジョニング ログの収集・整理 | 高 | 原因がオンプレでもサービスでも必ず役立つ | 失敗イベントをいくつか選び、共通点（同じ OU、同じ操作）をメモする |
| エージェント サービスの再起動 | 中 | オンプレ側の一時不調なら回復することがある | 再起動前後でログを分けて採取し、現象の変化を記録する |
| エージェントの再インストール／再登録 | 低（慎重に） | サービス側障害では効果が薄い一方、復旧後の差分が増える | サポート指示がある場合や、明確な破損が疑われる場合に限定する |
| AD 側の権限変更・OU 変更を無闇に行う | 低 | 根本原因と無関係だと副作用だけ残る | まずは既存の権限が変わっていないことの確認を優先する |
| 一時的な手動プロビジョニング（緊急対応） | 中 | 入社日が近い等、業務影響が大きい場合に必要 | 手動で作ったアカウントが後で重複しないよう、命名規則と突合ルールを決めておく |
運用上の注意：オンデマンド実行を「本番の即時反映」として使うなら監視が必須
オンデマンド プロビジョニングは、テストや特定ユーザーの即時反映に便利です。一方で、定期ジョブとは内部の経路が異なることがあり、今回のように「オンデマンドだけ落ちる」状況が起こり得ます。オンデマンド実行を日常運用の一部として使っている場合は、次の備えが効きます。
- ジョブ失敗をすぐ検知できるアラート（通知先、当番、一次対応手順まで含める）
- 影響範囲の可視化（失敗が特定 OU／特定属性の更新だけか、全件か）
- 緊急時の代替手段（最小限の手動作成、入社対応の暫定フロー）
| 備え | 狙い | 具体例 |
|---|---|---|
| 失敗アラートの設定 | 気付くのが遅れるリスクを減らす | プロビジョニング失敗ログを監視し、一定回数を超えたら通知 |
| エージェントの冗長化 | オンプレ側の単一障害点をなくす | 別サーバーに追加エージェントを配置し、片系停止でも継続できるようにする |
| 再起動・パッチ適用の手順化 | 「再起動を境に…」の疑念を減らす | 再起動後に簡易テスト（オンデマンド実行など）を行い、結果を記録 |
| 問い合わせテンプレの用意 | サポート連絡を迅速化 | 時刻、コリレーション ID、影響範囲、変更履歴をまとめた定型文 |
コミュニケーション例：関係者への説明を短く、正確にする
障害対応で地味に難しいのが、社内外の関係者へ「原因がどこにありそうか」「いつ復旧しそうか（または見通しが立っていないか）」を伝えることです。今回のようにサービス側が疑わしいときは、断定し過ぎず、しかし不安を煽らない言い回しが有効です。
現在、SuccessFactors→オンプレ AD のオンデマンド プロビジョニングで
HybridSynchronizationActiveDirectoryCredentialValidationFailureが発生しています。エージェントはアクティブでオンプレ側サービスも稼働しており、同時期に同様の事象報告が複数あるため、サービス側要因の可能性も含めて調査中です。プロビジョニング ログのコリレーション ID を採取し、必要に応じて Microsoft サポートへエスカレーションします。入社対応など緊急分は暫定的に手動作成でカバーします。
似た名前の別エラーに注意：CredentialValidationUnavailable
同じ話題の中で、後年（2025 年）に次のような似た名前のエラーが話題に上がっています。
HybridSynchronizationActiveDirectoryCredentialValidationUnavailable
名前が似ているため同一原因に見えますが、ログ上ではまだ公式な回答が掲載されていない状況がある、とされています。従って、次のように扱うのが安全です。
| 観点 | CredentialValidationFailure | CredentialValidationUnavailable |
|---|---|---|
| ニュアンス | 「検証に失敗」 | 「検証が利用できない／到達できない」 |
| 想定される方向性 | 資格情報・接続・ドメイン設定などの問題（ただしサービス側不具合もあり得る） | 一時的なサービス到達性、依存サービス、バックエンド障害なども疑う |
| 推奨アクション | オンプレ／サービス両面で切り分け。既知障害の可能性も確認 | 最新ドキュメント確認＋サポートへログを添えて個別確認 |
まとめ：このエラー＝即オンプレ不具合、とは限らない
HybridSynchronizationActiveDirectoryCredentialValidationFailure は、メッセージ上は「オンプレ エージェントや資格情報を確認せよ」と促します。しかし、実際には Microsoft 側のコード変更に起因するサービス障害で発生した事例があり、テナント側の変更なしでクラウド修正のデプロイ後に復旧した、という経緯が共有されています。
運用担当として押さえたい要点は次のとおりです。
- まずプロビジョニング ログからオンデマンド固有の失敗かを確認し、コリレーション ID を確保する
- エージェントがアクティブでも、オンデマンド経路の不具合で失敗することがある
- 同時期に同一エラーが多発しているなら、サービス障害の可能性を早期に疑う
- 再発に備え、失敗アラートとエージェント冗長化、問い合わせテンプレを整備する
「自分たちが何か壊したのでは」と焦るほど、再インストールや設定変更を繰り返してしまいがちです。まずはログで事実を押さえ、サービス要因も含めた切り分けを進めることが、最短復旧につながります。
コメント