Azure VM を Entra Domain Services に参加させる:先に決める
参加の前に三つの判断があります。ワークロードが必要とするディレクトリモデル、ドメインを解決するプライベート DNS、認証できるアカウントです。
管理されたディレクトリを使う必要のある Windows Server VM の前には三つの判断があり、参加コマンドはそのうち最小のものです。ディレクトリモデルを間違えると、参加は成功してもアプリケーションは認証できないままです。名前解決を誤ると、資格情報の問題に見える地点で障害が現れます。
サーバーに触れる前にモデル、名前解決、アカウントを決めておけば、コマンドは一度で通ります。
三つの参加のうち、実際にどれが欲しいのか
デバイス参加は、条件付きアクセスとシングルサインオンのためにマシンを Microsoft Entra ID に登録しますが、ワークロードに社内風ドメインへの Kerberos チケットは与えません。従来のドメイン参加はコンピューターオブジェクトをディレクトリに結び付け、マシンアカウント、グループポリシー、ドメイン認証を与えます。管理されたドメインはその二つ目のモデルをサービスとして提供します。名前は似ていますが結果は違います。
普通の意味でのドメインコントローラーが関わるのは最後の二つだけで、パッチ一覧からサーバーを外せるのは管理された選択肢だけです。
判断は好みではなくアプリケーションで決まるのが普通です。LDAP バインド、SPN 付きのサービスアカウント、グループポリシーオブジェクトを必要とするソフトウェアはドメインモデルに属します。社内デバイスで利用者の身元を知るだけで足りるソフトウェアは通常は属しません。
| Model | What the server gets | Where it appears |
|---|---|---|
| Entra device join | Device identity and conditional access signals | Microsoft Entra ID |
| Managed domain join | Machine account, Kerberos, group policy | The managed directory |
| Self-hosted AD DS | The same, plus every controller you operate | Your own forest |
参加を完了できるかは DNS の経路が決める
ドメイン参加はドメインのコントローラーレコードのロケーター検索から始まるため、資格情報を確認する前に名前解決が働いている必要があります。VM を管理されたドメインのディレクトリアドレスに向け、仮想ネットワークの DNS 設定を通すか、その名前空間だけを送る条件付きフォワーダーを通します。名前空間に限定したフォワーダーのほうが通常は安全で、VM の残りの解決に手を付けないからです。
裸のホスト名ではなくロケーターを試します。ドメイン名への ping はほとんど何も証明しませんが、ドメインコントローラーレコードへの SRV クエリは期待したターゲットを返すか、すぐに失敗します:
Resolve-DnsName -Name "_ldap._tcp.dc._msdcs.ds.corp.example" -Type SRV -Server 10.20.0.4
Test-NetConnection -ComputerName 10.20.0.4 -Port 53
ドメイン名と二つのアドレスは、管理されたドメインの構成にある値に置き換えてください。ここにある番号は例で、クエリが別ゾーンの応答を返すなら、VM は管理された名前空間を転送しないリゾルバーを使っています。参加を何度繰り返してもそれは変わりません。
ワークロードは管理されたドメインが自らのサービスリソース用に確保するサブネットの外に置き、ディレクトリのポートはプライベート経路に保ちます。それらのポートを公開することは近道ではなく、リスクプロファイルの異なる別の設計です。
アカウントの適格性はマシンより先に確認される
参加を実行するアカウントには、対象コンテナーでコンピューターオブジェクトを作る権限が必要で、管理されたドメインに対して認証できる必要があります。管理されたドメインが存在する前に作られたクラウド専用アカウントは、ドメインが必要とするパスワード由来の材料を持たないことがあり、パスワードの変更やリセットでそれが再生成されます。この細部が、パスワードは正しいのに間違ったパスワードに見える参加の失敗の一種を説明します。保守作業の時間帯が始まる前に、ドメインに対して資格情報を試してください。
同期されたハイブリッドアカウントには独自の前提があり、見える利用者オブジェクトだけでは満たしません。ディレクトリに載っていることと、そこからチケットを得られることは同じではありません。保守作業の時間帯の最中ではなく、その前にアカウントを試してください。
参加の権利は狭く委任します。一度の登録のために将来のサーバー利用者全員にドメイン管理者のメンバーシップを与えるのは、一時的な問題のための恒久的な許可です。
参加そのものはコマンド一つです
モデルを選び、DNS が応答し、アカウントが適格なら、操作は通常の Windows の操作です。プロンプトはパスワードをスクリプトやシェル履歴の外に保ちます:
Add-Computer -DomainName "ds.corp.example" -Credential (Get-Credential) -PassThru
この形のコマンドはマシンを自動では再起動しないので、再起動は保守計画のもとで復旧手段を残したまま行います。すでに別のドメインに参加しているサーバーには移行計画が必要で、最初の参加の上に二つ目を重ねるのではありません。
コンピューターオブジェクトが入ったコンテナーと、それを作ったアカウントを記録します。再構築の後にマシンを再参加させる必要があるとき、どちらも重要で、後からサーバーを見てもどちらも明らかではありません。
参加が与えないもの
ドメイン参加は誰かをローカル管理者にするものではなく、リモートデスクトップやファイル共有へのアクセスも与えません。それらの権利は別に構成され、管理されたドメインではサポートされる管理範囲の中にとどまります。
ネットワーク経路は設定の一手順ではなく継続的な依存関係です。プライベート接続が消えると、サーバーはキャッシュされた資格情報で動き続け、何かがディレクトリを必要とした時点で、障害は変更された構成の隣ではなくアプリケーションログに現れます。
Microsoft の Windows Server 参加ガイダンス は、管理されたドメインの作業手順でサポートされる前提条件を列挙しています。上の三つの判断と照らして読み、食い違いは回避する細部ではなく止まる理由として扱ってください。