Windowsでドメインから一度抜けて、再度ドメイン参加する具体的な方法

Windowsの「信頼関係に失敗しました」などでドメイン再参加を考える場合、最初にセキュアチャネルを診断・修復します。ドメインから抜けて再参加する作業は最後の手段です。ワークグループへ移すとドメイン資格情報でサインインできなくなるため、検証済みのローカル管理者、BitLocker回復キー、ネットワーク、データバックアップ、コンピューターアカウントの扱いを準備します。

Microsoftの現行公式手順は、Test-ComputerSecureChannelやnetdomで確認・修復し、それでも必要な場合に再参加します。コンピューターアカウントを先に削除しないでください。

この記事は、社内のActive Directory Domain Services（AD DS）へ参加しているWindowsのメンバーPCを対象とします。Microsoft Entra IDへの参加や、Microsoft 365のアカウントをアプリへ追加する操作とは別です。Microsoftの参加要件 で対象エディションを確認してください。Windows 11 Homeは、このAD DSドメイン参加の対象ではありません。ドメインコントローラー自体を本手順でワークグループへ移す作業も対象外です。

再参加が必要かを切り分ける

• 端末の日時とドメインコントローラーの時刻が大きくずれていない
• DNSが社内AD DNSを指し、ドメインとDCの名前解決ができる
• VPNまたは社内LANから必要なDCへ到達できる
• Test-ComputerSecureChannelの結果とイベントログ
• コンピューターアカウントがADに存在し、無効化・重複していない
• ユーザーサインインだけか、端末全体の信頼関係か

Test-ComputerSecureChannelがTrueなら、そのテストではセキュアチャネルが正常です。それでもサインインや共有に問題がある場合は、ユーザー資格情報や権限、名前解決等の調査を続けます。Falseだけでパスワード不整合と決めず、先にDCへの接続・DNS・時刻を確認してください。修復に必要な資格情報はGet-Credentialで入力し、コマンド行へパスワードを直書きしません。

作業前の準備

1. 利用者データ、証明書、業務アプリ設定、暗号化キーをバックアップし、テスト復元します。
2. Windows LAPS等で管理されたローカル管理者のパスワードを取得し、オフラインでサインインできることを実際に確認します。
3. BitLocker回復キーの保管先と端末IDを確認します。キーをチケット本文へ貼りません。
4. 固定IP、DNS、VPN、Wi-Fi、プロキシ、端末管理、EDRの設定を記録します。
5. ADのコンピューターオブジェクト、OU、グループ、委任、説明、証明書、管理ツールの登録を保存します。
6. 保守時間と、再参加失敗時に現地または帯域外で支援できる担当を確保します。

まずセキュアチャネル修復を試す

対象のメンバーPCへローカル管理者でサインインし、承認されたネットワークからDCへ接続できる状態にします。次は管理者として開いたWindows PowerShell 5.1での例です。最初のコマンドは確認、2番目はセキュアチャネルの修復です。確認でTrueなら、理由なく修復コマンドを続けて実行しません。

Test-ComputerSecureChannel -Verbose

接続条件を直してもFalseとなり、管理担当が修復を必要と判断した場合は、必要なドメイン側権限を持つアカウントを入力します。

Test-ComputerSecureChannel -Repair -Credential (Get-Credential) -Verbose

Test-ComputerSecureChannelの公式仕様 はメンバーコンピューター用で、ドメインコントローラーでは誤った結果になると説明しています。DCの診断は管理者がnetdomやnltest等の該当手順で行います。修復の失敗は表示されたエラーを記録し、無条件に同じ操作を繰り返さないでください。

修復成功後に、Test-ComputerSecureChannelの結果、ドメインユーザーのサインイン、GPO、ファイル共有を確認します。必要な再起動は保守計画に従います。修復で必要な機能が戻れば、ドメインを離脱して再参加する必要はありません。

ワークグループへ移す

再参加が必要な場合は、利用者をサインアウトし、検証したローカル管理者で作業します。Microsoftの再参加手順 のコンピューター名の設定を使い、いったんワークグループへ変更してから、同じ画面でドメインへ戻します。

1. コントロールパネルの「システムとセキュリティ」→「システム」から、システムの詳細設定や関連する「設定の変更」を開きます。表示経路が異なる場合は「システムのプロパティ」の「コンピューター名」タブを探します。
2. 「変更」を選び、「所属するグループ」で「ワークグループ」を選びます。管理担当が決めた一時的なワークグループ名を入力して「OK」を選びます。
3. 資格情報を求められたら、離脱に必要な権限を持つ指定アカウントを入力します。変更が成功したことを確認して再起動します。
4. 再起動後はローカルアカウントでサインインします。サインイン先が端末名になっていることを確認し、ドメインアカウントやMicrosoftアカウントと混同しません。

この時点ではまだワークグループです。ドメインユーザーのサインインや業務共有が使えることを前提にせず、ローカル管理者で次の参加作業を続けます。失敗時に遠隔支援やVPNを維持できるかは、離脱前に確認してください。

再度ドメインへ参加する

1. 社内LANまたは承認済みVPNへ接続し、AD DNS・ドメイン名解決・時刻を確認します。既存コンピューターアカウントの扱いも管理担当と確認します。
2. 「システムのプロパティ」→「コンピューター名」→「変更」で、今度は「ドメイン」を選び、組織のドメイン名を入力します。
3. 別の入口を使う場合、Windowsの「設定」→「アカウント」→「職場または学校にアクセスする」→「接続」で、ローカルのActive Directoryドメインへこのデバイスを参加させる項目を選びます。Entra IDへの参加項目と取り違えません。
4. 例のad.example.comをそのまま使わず、組織のドメインFQDNに置き換えます。求められた資格情報には、参加用に委任されたアカウントを使います。
5. 参加の成功を確認して再起動し、元のドメインユーザーでサインインします。AD側のOU、GPO、管理グループと端末の状態を確認します。

PowerShellでの参加が組織で承認されている場合、Windows PowerShell 5.1を管理者として開き、Add-Computerの公式仕様 に従って実行できます。次は対象PC自身を参加させる例です。返るHasSucceededとエラーメッセージを確認し、成功後に作業を保存して再起動します。

Add-Computer -DomainName 'ad.example.com' -Credential (Get-Credential) -PassThru

特定DCを指定する必要がある場合は、-ServerにDCのDNS FQDNを指定します。たとえばdc01.ad.example.comです。ドメイン名のad.example.comとも、短いコンピューター名のDC01とも区別してください。

同名アカウントの再利用で0xaac・2732が出る場合

再参加で同名のコンピューターアカウントを再利用する場合は、参加権限だけでなく所有者と再利用ポリシーも確認します。MicrosoftのKB5020276 は、0xaac（2732）、Netjoinイベント4101、C:\Windows\Debug\NetSetup.logを再利用ブロックの確認先として説明しています。

管理者は既存アカウントの所有者と、信頼する所有者・作成者を指定する再利用許可ポリシーを確認します。この許可リストへ参加操作の担当者を追加することとは違います。Everyone等の広いグループを許可したり、解決のために担当者をDomain Adminsへ追加したりしません。NetJoinLegacyAccountReuseによる旧回避策は2024年8月以降サポートされていません。

同じKBは、特定DCを指定する場合にDNS FQDNを使う条件も案内しています。ログと更新・ポリシーを管理担当へ渡し、必要な対応を選んでもらいます。同名アカウントの削除・所有者変更・セキュリティ設定の緩和を、すべての再参加失敗に対する最初の操作にしないでください。

ユーザープロファイルの注意

同じユーザー名でもSIDが異なれば新しいプロファイルが作成されます。通常の再参加で同じドメインアカウントなら既存プロファイルを再利用できることが多いですが、コンピューター移行、ドメイン変更、アカウント再作成では別です。レジストリでProfileListを安易に付け替えず、USMTや組織の移行手順を使います。

再参加後の受入確認

• ドメインサインインとローカル緊急サインインができる
• セキュアチャネルが正常でDC/DNSイベントにエラーがない
• GPO、証明書、Windows Update、EDR、MDMが再適用される
• ファイル共有、プリンター、業務アプリ、SSO、VPNが動く
• 組織のポリシーに従い、BitLocker回復キーとLAPSパスワードの保管先・参照権限・必要なバックアップの成功を実際に確認する
• AD、資産管理、EDRに重複端末がない

失敗時の戻し方

ドメイン参加に失敗しても、ローカル管理者でワークグループ状態へ戻れることが最小のロールバックです。DNS・時刻・ネットワーク・資格情報・オブジェクト権限を修正して再試行します。旧コンピューターオブジェクトを削除・再作成する前に属性とグループをエクスポートします。端末初期化は最終手段で、バックアップ復元と再登録手順を承認してから行います。

Windows LAPSを使う

Windows LAPSは、構成に応じてローカル管理者パスワードを管理し、ADまたはMicrosoft Entra IDへバックアップします。再参加しただけで、両方へ最新値が必ず保存されるとは考えないでください。組織が選んだバックアップ先、対象ローカルアカウント、取得権限、ローテーションと監査を確認し、作業前の緊急サインインに使えることを検証します。

オフライン端末・遠隔地端末

遠隔地でドメイン接続がVPN経由の場合、ワークグループへ抜けた後にVPNクライアントへサインインできず、再参加できないことがあります。Windowsサインイン前VPN、端末証明書、現地ネットワーク、帯域外管理の可否を試します。可能なら社内LANまたは技術者がいる拠点で作業します。

端末を利用者宅で再参加させる場合は、情報システム部門が認めた遠隔支援と資格情報の入力手段を使います。パスワードをチャットや画面共有の記録へ残さず、入力担当・接続先・再起動後の連絡手段を事前に決めます。通信断時にも、利用者が検証済みのローカルアカウントでサインインできる状態を確保します。

コンピューターアカウントをリセットする場合

AD Users and ComputersのReset Accountは、端末側とのセキュアチャネルを再確立する作業と組み合わせます。リセットだけして放置すると信頼関係が切れます。対象名、SID、OU、グループ、BitLocker/LAPS属性を確認し、似た名前のサーバーを誤操作しないよう二者確認します。

コンピューターオブジェクト削除はリセットより影響が大きく、AD Recycle Binやバックアップがあっても関連付け復旧が複雑です。削除が必要な端末廃止と、再参加トラブルを分けます。

証明書と端末管理

再参加で自動登録証明書、Wi-Fi/VPN証明書、Windows Hello for Business、MDM登録が変わることがあります。証明書ストアの現在値と有効期限を記録し、重複証明書や失効がないか確認します。秘密鍵をエクスポートする場合は製品手順と保護された保存先を使います。

IntuneやEDRに旧端末と新端末の重複レコードが生まれた場合、すぐ削除せず最終チェックイン、デバイスID、証明書、所有者を照合します。正しい新登録を確認してから旧登録を廃止します。

サービスアカウントとスケジュールタスク

端末上のサービスやタスクがドメインアカウントで動く場合、離脱中に起動失敗や認証の再試行が起きる可能性があります。保守前に対象を一覧化し、業務担当の了承を得て安全に停止できるものを止めます。再参加後に資格情報、サービス起動、依存アプリを確認します。

復旧後の再起動を複数回行う前にイベントログとサービス状態を保存します。再参加は端末アクセスの復旧であり、業務アプリの正常化まで含めて完了とします。

公式情報・参考資料

• Microsoft Learn – コンピューターをドメインへ参加させる
• Microsoft Learn – Windows LAPSの概要
• Microsoft Learn – Test-ComputerSecureChannel