Azure DevOps Server Patch 6後にID解決できない原因とAD信頼関係の確認手順

Azure DevOps Server Patch 6の適用後、特定のActive Directoryドメインに所属するユーザーやグループだけを検索・解決できなくなった場合、最初に確認すべきなのはAzure DevOps Serverのデータベースではありません。アプリケーション層から対象ドメインへの信頼関係、信頼の方向、DNSによるドメインコントローラー検出を確認します。

Patch 6では、ID解決時にAzure DevOps Serverが接続するActive Directoryドメインが信頼済みかどうかを検証する処理が追加されました。そのため、未信頼ドメイン、方向が逆の一方向信頼、壊れた信頼関係、条件付きフォワーダーの不備など、以前から存在していた構成上の問題がPatch適用後に表面化する可能性があります。(Microsoft Learn)

この記事では、信頼済みActive Directoryドメイン検証の影響を切り分け、Azure DevOps Serverの各アプリケーション層で信頼関係、DNS、通信経路を確認し、AD管理者へ正確に修正を依頼する手順を解説します。

Patch 6後のID解決エラー：信頼済みActive Directoryドメイン検証の影響を調べる

2026年7月21日に公開されたAzure DevOps Server Patch 6では、ID解決時に信頼済みActive Directoryドメインだけへ接続するための検証が追加されました。ユーザーやグループを検索できない現象がPatch適用直後から始まった場合は、この変更の影響を優先して調査します。(Microsoft Learn)

ただし、Patch 6によってActive Directoryの信頼関係そのものが変更されるわけではありません。Patch適用前から存在していた次のような状態が、新しい検証を通過できなくなった可能性を考えます。

Azure DevOps Server側から見て対象ドメインが信頼されていない
一方向信頼は存在するが、必要な方向と逆になっている
信頼関係のセキュアチャネルが正常に機能していない
対象ドメインのDNS名やSRVレコードを解決できない
対象ドメインのドメインコントローラーやグローバルカタログへ接続できない
複数あるアプリケーション層の一部だけDNSやファイアウォール設定が異なる

最初に確認する3つのポイント

確認項目	正常な状態	問題がある場合の代表例
AD信頼関係	Azure DevOps Server側から対象ユーザードメインへの有効な信頼経路がある	未信頼、逆方向の一方向信頼、信頼パスの障害
DNSとDC検出	アプリケーション層から対象ドメインのSRVレコードとDCを検出できる	条件付きフォワーダー不備、古いDNS情報、経路障害
全アプリケーション層の通信	すべてのノードから同じ結果になる	特定ノードだけDNSサーバー、経路、FWルールが異なる

Patchの再適用やサービス再起動を繰り返す前に、この3点を確認するのが効率的です。

Azure DevOps ServerのID解決とは

Azure DevOps ServerにおけるID解決は、入力されたユーザー名やグループ名をActive Directory上のセキュリティプリンシパルと対応付け、Azure DevOpsのユーザー、チーム、権限グループ、担当者などとして扱える状態にする処理です。

Azure DevOps ServerにはIdentity Management Serviceがあり、Active Directory上のユーザーおよびグループ情報を同期します。ADグループをAzure DevOpsグループへ追加したとき、アプリケーション層の起動時、定期ジョブの実行時などに同期が行われます。(Microsoft Learn)

信頼済みドメインの検証に失敗すると、次のような画面で問題が現れる可能性があります。

プロジェクトやチームへユーザーを追加する画面
Azure DevOpsのセキュリティグループへADグループを追加する画面
リポジトリ、ビルド、エージェントプールなどの権限設定
作業項目の担当者選択
ユーザー名やグループ名を入力するID検索欄
既存ADグループのメンバー情報更新

既存ユーザーが画面上に表示されていても、新しいユーザーを検索できない場合があります。Azure DevOps Server内に保持されている既存のID情報と、Active Directoryへ新たに問い合わせるID解決処理は分けて考える必要があります。

症状から原因を絞り込む

症状	優先して疑う原因	次に行う確認
同一ドメインのユーザーは検索できるが、特定ドメインだけ失敗する	信頼関係、信頼方向、対象ドメインのDNS	`nltest /domain_trusts`と`nltest /dsgetdc`
すべての外部ドメインが失敗する	共通のDNS、FW、サービスアカウント側の信頼経路	全アプリケーション層のDNSと通信経路
特定のアプリケーション層を経由したときだけ失敗する	ノード固有のDNS、経路、ファイアウォール	各ノードで同じコマンドを実行して比較
ユーザーは解決できるがADグループだけ失敗する	グローバルカタログ、グループスコープ、ネスト構成	GC検出、3268番ポート、ADグループ構成
管理端末では検索できるがAzure DevOpsでは失敗する	アプリケーション層またはサービス実行コンテキストの問題	Azure DevOps Server上から直接検証
同一ドメインを含めてすべて失敗する	AD接続全体、Azure DevOpsサービス、DNSの広範な障害	サービス状態、イベントログ、DC検出
ログインはできるがユーザー追加だけ失敗する	認証経路とID検索経路の違い	ログイン成功だけでAD信頼問題を除外しない

特に重要なのは、管理者のPCではなく、Azure DevOps Serverのアプリケーション層から検証することです。

一方向信頼は「存在」より「方向」が重要

一方向信頼が設定されていても、その方向が逆であれば、Azure DevOps Serverから対象ドメインのIDを解決できないことがあります。

たとえば、次の構成を想定します。

Azure DevOps Server側：DEVOPS.CONTOSO.LOCAL
検索したいユーザー側：USERS.FABRIKAM.LOCAL

Azure DevOps Serverをリソース側として、USERS.FABRIKAM.LOCALのユーザーを受け入れるには、基本的に次の方向の信頼が必要です。

DEVOPS.CONTOSO.LOCAL
信頼する側・リソース側
        │
        └──── trusts ────▶ USERS.FABRIKAM.LOCAL
                            信頼される側・アカウント側

netdom trustでは、第1引数が信頼するドメイン、/Domain:に指定するのが信頼されるドメインです。信頼の検証は次の形式になります。(Microsoft Learn)

netdom trust DEVOPS.CONTOSO.LOCAL /Domain:USERS.FABRIKAM.LOCAL /Verify

逆に、USERS.FABRIKAM.LOCALだけがDEVOPS.CONTOSO.LOCALを信頼している場合、信頼関係は存在していてもAzure DevOps Serverが必要とする方向と一致しない可能性があります。

nltestの結果で信頼方向を判断する

Azure DevOps Serverのアプリケーション層で次のコマンドを実行します。

nltest /domain_trusts /all_trusts /v
nltest /domain_trusts /direct_out /v
nltest /domain_trusts /direct_in /v

Microsoftの説明では、各オプションは次の意味です。(Microsoft Learn)

表示結果	意味	判断
`Direct_Out`に対象ドメインがある	現在のプライマリドメインが対象ドメインを明示的に信頼している	一方向信頼の方向は適切である可能性が高い
`Direct_In`だけに対象ドメインがある	対象ドメインが現在のドメインを信頼している	一方向信頼が逆向きの可能性がある
`All_Trusts`にはあるが`Direct_Out`にはない	同一フォレストや推移的信頼など、直接ではない経路の可能性がある	AD管理者が信頼パス全体を確認
`All_Trusts`にもない	信頼されていない、または信頼情報を取得できていない	信頼作成、DNS、DC到達性を確認

同一フォレストの推移的信頼やフォレスト信頼では、対象ドメインがDirect_Outに直接表示されない場合があります。そのため、Direct_Outだけを根拠に異常と断定せず、All_Trustsと「Active Directory ドメインと信頼関係」の両方で信頼パスを確認します。

信頼済みActive Directoryドメイン検証の調査手順

Patch 6の適用状況と発生時刻を確認する

最初に、問題がPatch 6適用後に始まったことを確認します。

記録する項目は次のとおりです。

Patch 6の適用日時
最初にID解決エラーが確認された日時
正常に検索できるドメイン
検索できないドメイン
ユーザーだけか、グループも失敗するか
すべてのプロジェクトで発生するか
すべてのアプリケーション層で発生するか
表示されたエラーとWindowsイベントログの内容

MicrosoftのPatch公開案内では、PatchインストーラーにCheckInstallを付けて適用状況を確認できます。実際のファイル名に置き換えて実行します。(Microsoft for Developers)

"<Patch 6インストーラーのフルパス>" CheckInstall

「Patch 6」という名称だけで判断せず、対象製品、インストーラー名、適用日をセットで記録しておくと、過去バージョン向けPatchとの混同を防げます。

正常ドメインと失敗ドメインのテスト表を作る

1件のユーザーだけで判断すると、アカウント無効化、表示名変更、グループスコープなど別の要因を混同します。少なくとも次の組み合わせで確認します。

テスト対象	目的
Azure DevOps Serverと同じドメインのユーザー	ID解決機能全体が動作しているか
正常な信頼済みドメインのユーザー	外部ドメイン検索が全体的に失敗していないか
問題があるドメインの一般ユーザー	対象ドメイン固有の問題か
問題があるドメインのADグループ	グループ解決やGC接続にも影響があるか
問題があるドメインの別ユーザー	個別アカウントの問題ではないか

入力した表示名、UPN、DOMAIN\ユーザー名などの形式と、検索結果も記録します。画面によって受け付ける形式が異なる場合があるため、同じ検索条件で比較することが重要です。

すべてのアプリケーション層で信頼関係を確認する

複数のアプリケーション層がある場合は、すべてのサーバーで次のコマンドを実行します。

(Get-CimInstance Win32_ComputerSystem).Domain
ipconfig /all

nltest /domain_trusts /all_trusts /v
nltest /domain_trusts /direct_out /v
nltest /domain_trusts /direct_in /v

比較する項目は次のとおりです。

コンピューターが参加しているドメイン
使用しているDNSサーバー
DNSサフィックス検索一覧
対象ドメインが信頼一覧に表示されるか
対象ドメインの表示がノードごとに異ならないか
Direct_OutとDirect_Inのどちらに表示されるか

1台だけ異なる結果になる場合、Azure DevOps Server全体の不具合ではなく、そのノード固有のDNS、ルーティング、ファイアウォール、NIC設定を疑います。

DNSのSRVレコードとドメインコントローラー検出を確認する

ADの信頼関係が正しくても、Azure DevOps Serverから対象ドメインのドメインコントローラーを検出できなければID解決は成功しません。

アプリケーション層から次のコマンドを実行します。

Resolve-DnsName `
  _ldap._tcp.dc._msdcs.USERS.FABRIKAM.LOCAL `
  -Type SRV

nltest /dsgetdc:USERS.FABRIKAM.LOCAL /force
nltest /dsgetdc:USERS.FABRIKAM.LOCAL /gc /force
nltest /dclist:USERS.FABRIKAM.LOCAL

nltest /dsgetdcはDNSへドメインコントローラーを問い合わせ、検出したDCへの接続も確認します。/forceを付けると、キャッシュではなくDNSへの再問い合わせを強制できます。(Microsoft Learn)

正常であれば、対象ドメインのDCまたはGCのFQDN、IPアドレス、サイト情報などが返ります。

失敗する場合は、AD管理者またはDNS管理者と次を確認します。

条件付きフォワーダーの宛先が正しいか
対象ゾーンや委任情報が最新か
_ldap._tcp.dc._msdcsのSRVレコードが登録されているか
DNSサーバー間でゾーン情報が複製されているか
Azure DevOps Serverから対象DNSサーバーへ到達できるか
対象DCのIPアドレスへ正しい経路があるか
古いDCや廃止済みIPアドレスがDNSに残っていないか

単純なホスト名の名前解決だけでなく、ADがDC検出に使用するSRVレコードまで確認することがポイントです。

AD管理者に信頼関係を検証してもらう

信頼関係の確認は、Azure DevOps管理者だけで完結させず、両方のADドメインを管理できる担当者と実施します。

直接信頼の例では、管理者権限のコマンドプロンプトから次を実行します。

netdom trust DEVOPS.CONTOSO.LOCAL /Domain:USERS.FABRIKAM.LOCAL /Verify

/Verifyは、指定した信頼関係のセキュアチャネルシークレットを検証します。netdom trustを利用するにはAD DS管理ツールまたはRSATが必要で、管理者として実行する必要があります。(Microsoft Learn)

GUIで確認する場合は、一般的に次の場所を使用します。

「Active Directory ドメインと信頼関係」を開く
Azure DevOps Server側ドメインのプロパティを開く
「信頼」タブを開く
対象ドメインと信頼方向を確認する
信頼関係の検証を実行する
必要に応じて対象ドメイン側からも検証する

フォレスト信頼の新規作成はnetdom trustでは行えないため、「Active Directory ドメインと信頼関係」または組織で承認された管理手段を使用します。(Microsoft Learn)

/Reset、信頼の削除、再作成は影響が大きい操作です。Azure DevOps Serverだけでなく、同じ信頼関係を利用するファイルサーバー、業務システム、認証基盤にも影響する可能性があるため、変更管理と影響調査を行ってから実施します。

AD通信に必要なポートを確認する

DNSでDCを検出できても、LDAP、Kerberos、RPC、グローバルカタログなどの通信が遮断されていればID解決は失敗します。

代表的な確認対象は次のとおりです。

用途	主なポート	確認ポイント
DNS	TCP/UDP 53	ドメイン名、SRVレコード、DC検出
Kerberos	TCP/UDP 88	ドメイン間認証
LDAP	TCP/UDP 389	ユーザー、グループ、ディレクトリ検索
LDAPS	TCP 636	LDAPSを使用する構成の場合
グローバルカタログ	TCP 3268	フォレスト内のID・グループ検索
GC over SSL	TCP 3269	TLS対応GCを使用する場合
RPC Endpoint Mapper	TCP 135	RPCサービスの接続先決定
動的RPC	TCP 49152～65535	NetLogon、LSAなどのRPC通信
SMB	TCP 445	信頼作成など、一部の管理処理

Windows Serverの新しい既定構成では、動的RPCポートとしてTCP 49152～65535が使用されます。ただし、必要な通信はAD構成や実行する処理によって異なるため、一覧にあるポートを無条件に全ネットワークへ開放するのではなく、Azure DevOps Serverのアプリケーション層から必要なDCやGCへの通信に限定して設計します。(Microsoft Learn)

TCPポートの簡易確認には、次のコマンドを利用できます。

$dc = "dc01.users.fabrikam.local"

Test-NetConnection $dc -Port 389
Test-NetConnection $dc -Port 3268
Test-NetConnection $dc -Port 135
Test-NetConnection $dc -Port 88

Test-NetConnectionで確認できるのは指定したTCPポートへの接続です。UDP通信、動的RPCの実処理、LDAP検索、Kerberos認証が正常に完了することまでは保証しません。

失敗時は、Windows Defender Firewall、ネットワークファイアウォール、拠点間VPN、VLAN間ACL、クラウド側のセキュリティルールを確認します。複数のDCがある場合、特定のDCだけ許可されている構成にも注意が必要です。

Azure DevOps Serverのサービスアカウントを確認する

Azure DevOps ServerのWebサービスやTeam Foundation Background Job Agentは、Azure DevOps Serverのサービスアカウントで実行されます。Microsoftのドキュメントでは、このアカウントを一般的にTFSServiceと表現しています。(Microsoft Learn)

Azure DevOps Server Administration Consoleで次を確認します。

アプリケーション層のサービスアカウント
サービスアカウントが所属するドメイン
そのドメインから対象ユーザードメインへの信頼経路
複数ノードでサービスアカウント設定が一致しているか
サービスアカウントの変更やパスワード変更が一部ノードだけに反映されていないか

管理者が対話ログオンした状態でAD検索に成功しても、Azure DevOps Serverのサービス実行コンテキストで同じ結果になるとは限りません。組織で承認された手段を用いて、サービスアカウント側のドメイン関係や権限も確認します。

サービスアカウントを変更すること自体を最初の対処にしてはいけません。先に信頼方向、DNS、DC検出、通信経路を確認し、サービスアカウント固有の問題であると判断できた場合に限って変更を検討します。

修正後にユーザー検索とグループ同期を分けて確認する

AD信頼関係やDNSを修正したら、まずAzure DevOps Serverのユーザー検索画面で対象ドメインのユーザーとグループを再検索します。

その後、既存ADグループのメンバー情報が更新されるか確認します。

Azure DevOps Serverのドキュメントでは、AD情報の定期ジョブは既定で1時間間隔で動作し、すべてのグループは既定で24時間以内に更新されます。アプリケーション層の起動も同期の契機になります。(Microsoft Learn)

したがって、次の2つを分けて判定します。

対話的なID検索：修正後、対象ユーザーやグループを新たに検索できるか
バックグラウンド同期：既存ADグループのメンバー変更がAzure DevOpsへ反映されるか

ユーザー検索が直った直後にグループメンバーが更新されなくても、信頼関係の修正に失敗したとは限りません。同期ジョブの実行状況と経過時間を確認します。

原因別の修正方針

確認結果	修正方針	注意点
対象ドメインとの信頼がない	セキュリティ要件を確認し、適切なドメイン信頼またはフォレスト信頼を設計する	Azure DevOpsだけの都合で安易に双方向信頼にしない
一方向信頼が逆向き	Azure DevOps Server側が対象ユーザードメインを信頼する方向へ修正する	既存システムへの影響をAD管理者が確認する
信頼検証が失敗する	セキュアチャネル、DC複製、信頼パスを修復する	`Reset`や再作成は変更管理の対象にする
SRVレコードを解決できない	条件付きフォワーダー、委任、ゾーン複製を修正する	hostsファイルだけで恒久対応しない
DCは見つかるが接続できない	FW、ACL、ルート、VPN、DC側受信規則を修正する	1台のDCだけでなく実際に選択されるDCを確認
特定ATノードだけ失敗する	DNS、NIC、FW、経路を正常ノードに合わせる	ロードバランサー経由では断続障害になりやすい
ユーザーは解決できるがグループが失敗する	GC到達性、グループスコープ、ネスト、信頼パスを確認する	ユーザー検索成功だけで完了としない
AD修正後も古い結果が残る	ID検索と同期ジョブを分けて再検証する	いきなりサーバー全体を再起動しない

やってはいけない切り分け方法

Patch 6の巻き戻しだけで完了とする

Patchを外すことで一時的に挙動が戻ったとしても、未信頼ドメインへの接続、逆向きの信頼、DNS不備といった根本原因は残ります。Patch 6で追加された検証の目的を踏まえ、恒久対策はAD構成と通信経路の正常化を基本とします。

「信頼関係がある」とだけ確認する

一方向信頼では、信頼の存在だけでなく方向が重要です。Direct_OutとDirect_In、信頼する側と信頼される側を明記して確認します。

管理端末からだけテストする

AD管理者の端末とAzure DevOps Serverでは、利用するDNS、ネットワーク経路、FWルール、所属サイトが異なる場合があります。必ず各アプリケーション層からテストします。

Pingが成功しただけで通信正常と判断する

Pingが成功しても、DNSのSRV検索、LDAP、Kerberos、GC、RPCが利用できるとは限りません。DC検出と必要なサービス通信を個別に確認します。

Azure DevOps Serverのデータベースを直接変更する

ID情報を修正する目的でAzure DevOps Serverのデータベースを直接編集してはいけません。Microsoftは、サポートの指示や正式なバックアップ手順を除き、Azure DevOps Serverデータベースを手動変更しないよう明記しています。(Microsoft Learn)

信頼修正前にユーザーを削除して再登録する

根本原因がAD信頼やDNSにある状態でユーザーを削除しても、再登録時のID解決が再び失敗します。既存の権限、作業項目の履歴、監査情報にも影響するため、先にAD接続を正常化します。

修正完了の判断基準

次のすべてを確認できた状態を完了とします。

Patch 6の適用状況と発生時刻を記録した
対象ドメインへの信頼経路をAD管理者が確認した
一方向信頼の場合、信頼方向が要件と一致している
信頼関係の検証が正常終了する
すべてのアプリケーション層から対象ドメインのSRVレコードを解決できる
nltest /dsgetdcで対象DCまたはGCを検出できる
必要なLDAP、Kerberos、GC、RPC通信が許可されている
Azure DevOps Serverの検索画面で対象ユーザーを解決できる
対象ADグループも検索・追加できる
既存ADグループのメンバー変更が同期後に反映される
複数のアプリケーション層で結果に差がない

Patch 6後に特定ドメインのユーザーやグループだけを検索できなくなった場合は、まず各アプリケーション層でnltest /domain_trustsを実行し、信頼の有無と方向を確認します。続いてSRVレコードとnltest /dsgetdcでDC検出を確認し、AD管理者に信頼関係の検証を依頼します。

Azure DevOps Server側の再起動やユーザー再登録を先に行うのではなく、信頼関係、DNS、DC到達性、サービス実行環境の順に切り分けることが、影響を最小限に抑えながら復旧するための確実な進め方です。

この記事を書いた人

佐藤健司

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

Azure DevOps Server Patch 6後にID解決できない原因とAD信頼関係の確認手順

Patch 6後のID解決エラー：信頼済みActive Directoryドメイン検証の影響を調べる

最初に確認する3つのポイント

Azure DevOps ServerのID解決とは

症状から原因を絞り込む

一方向信頼は「存在」より「方向」が重要

nltestの結果で信頼方向を判断する

信頼済みActive Directoryドメイン検証の調査手順

Patch 6の適用状況と発生時刻を確認する

正常ドメインと失敗ドメインのテスト表を作る

すべてのアプリケーション層で信頼関係を確認する

DNSのSRVレコードとドメインコントローラー検出を確認する

AD管理者に信頼関係を検証してもらう

AD通信に必要なポートを確認する

Azure DevOps Serverのサービスアカウントを確認する

修正後にユーザー検索とグループ同期を分けて確認する

原因別の修正方針

やってはいけない切り分け方法

Patch 6の巻き戻しだけで完了とする

「信頼関係がある」とだけ確認する

管理端末からだけテストする

Pingが成功しただけで通信正常と判断する

Azure DevOps Serverのデータベースを直接変更する

信頼修正前にユーザーを削除して再登録する

修正完了の判断基準

この記事を書いた人

コメント

コメントするコメントをキャンセル

Azure DevOps Server Patch 6後にID解決できない原因とAD信頼関係の確認手順

Patch 6後のID解決エラー：信頼済みActive Directoryドメイン検証の影響を調べる

最初に確認する3つのポイント

Azure DevOps ServerのID解決とは

症状から原因を絞り込む

一方向信頼は「存在」より「方向」が重要

nltestの結果で信頼方向を判断する

信頼済みActive Directoryドメイン検証の調査手順

Patch 6の適用状況と発生時刻を確認する

正常ドメインと失敗ドメインのテスト表を作る

すべてのアプリケーション層で信頼関係を確認する

DNSのSRVレコードとドメインコントローラー検出を確認する

AD管理者に信頼関係を検証してもらう

AD通信に必要なポートを確認する

Azure DevOps Serverのサービスアカウントを確認する

修正後にユーザー検索とグループ同期を分けて確認する

原因別の修正方針

やってはいけない切り分け方法

Patch 6の巻き戻しだけで完了とする

「信頼関係がある」とだけ確認する

管理端末からだけテストする

Pingが成功しただけで通信正常と判断する

Azure DevOps Serverのデータベースを直接変更する

信頼修正前にユーザーを削除して再登録する

修正完了の判断基準

この記事を書いた人

関連記事

コメント

コメントする コメントをキャンセル

コメントするコメントをキャンセル