ユーザー VPN 経由でドメインに参加し、再起動を乗り切る

ポイント対サイト VPN を経由してドメイン参加を実行できます。この接続に通常できないのは、その後に続く再起動をまたいで接続を維持することであり、そこが最初のドメイン ユーザーがサインインしようとする場面です。私は今、参加を三つの段階で進めます：ローカル管理者でサインインしたまま経路と検出を確認し、参加を実行し、引き渡す前に最初のドメイン ログオンをテストします。各段階には、それぞれ別の場所で失敗するテストがあります。

これらの段階を分けておくことが、参加には成功したものの使えないノート PC でプロジェクトが終わるのを防ぎます。

接続する前に：エディション、ローカル管理者、DNS

マシンにはドメイン参加をサポートするエディションと、それを実行する権限を持つローカル管理者が必要です。参加は使用中のセキュリティ コンテキストで実行されるため、VPN は同じセッションで稼働している必要があります。

クライアントの参照先は、パブリック リゾルバーでも hosts ファイルのエントリでもなく、組織のディレクトリ DNS にしてください。参加には サービス レコードの検出 が必要で、その後、そのレコードが示すホストに到達しなければなりません。古いサフィックスやパブリック リゾルバーは検出をまったく別の場所へ送ります。

時計も確認します。Kerberos は時刻のずれに厳しく、一か月間オフラインだったノート PC は紛らわしい参加エラーのよくある原因です。

ドメインが検出できることを確認する（ping だけでは不十分）

参加を試みる前に、ドメインの LDAP SRV レコードを解決します。ad.corp.example という例示的な単一ドメイン環境では、クエリは次のとおりです：

Resolve-DnsName -Type SRV _ldap._tcp.dc._msdcs.ad.corp.example

返されたレコードは必要ですが十分ではありません。一覧に含まれる各 DC 名を解決し、トンネル経由で必要なサービスに到達できることを確認します。ドメイン名への ping は検出についてほとんど何も証明しません。

文書化された AD の依存関係（認証、SMB と RPC のトラフィック、時刻同期）を許可します。それぞれを実際に配備したファイアウォール規則と照合してください。ドメイン コントローラのポートをインターネットに公開することは、検討に値する近道ではありません。

参加を実行し、エラーを読む

サポートされている参加コマンドまたはシステムのダイアログを使い、エラー テキストを正確に記録します。「指定されたドメインは存在しないか、または連絡できませんでした」は資格情報ではなく、検出または到達性を示します。

同じ名前のオブジェクトが既にある場合でも、反射的に削除しないでください。事前にステージングされたアカウントの可能性があり、netjoin の強化 は所有者とポリシーに応じて一部の再利用を制限します。ディレクトリの所有者にオブジェクトの確認または修正を依頼してください。

参加の成功は中間点であり、ゴールではありません。次の段階こそ、ユーザーが実際に試すものです。

最初のドメイン サインインを計画する

参加が完了しても、すべてのドメイン ユーザーの資格情報がキャッシュされるわけではありません。最初のサインイン画面では、どのユーザーもログインしていない状態で DC への経路が必要です。ユーザー VPN がサインイン後にしか起動しないなら、その経路はありません。これは設計の欠落であり、クライアントの不具合ではありません。

その最初のログオンには、サポートされている事前ログオンまたはデバイス トンネルのワークフロー、既存のサイト経路、または承認済みの代替手段を使用します。そのうえで全体の順序をテストします：再起動し、資格情報の画面に到達し、想定したドメイン ユーザーとしてサインインし、トンネルが設計どおりに動作することを確認します。

ユーザーの切り替えと VPN の持続性はクライアントによって異なります。ローカル管理者として開始した接続が別のユーザーのセッションに引き継がれると想定しないでください。

ローカルの回復アクセスを確保する

ノート PC を引き渡す前に、承認済みのローカル回復経路を残しておきます。最初のドメイン ログオンが失敗したとき、たった今失敗した同じトンネルに依存しない戻り道が必要です。

何を証明したか（SRV 解決、DC への到達性、参加エラー、最初のログオンの方法、回復用アカウント）を書き留めます。その記録が、再現可能な構築とオフィスでしか動かないノート PC の違いになります。