Windowsにおいてドメインコントローラーが検出される方法

ドメインに所属しているWindowsのサーバーやクライアントが，どのように最寄のドメインコントローラーを見つけるのか，そのメカニズムは複雑です。

それで，Windowsベースのドメインにおいて，どのようにドメインコントローラーを発見するのか，Microsoftの公式情報に基づいて，そのメカニズムを説明したいと思います。

この記事では，DNS名と，NetBIOS名を用いて，どのようにドメインコントローラーを発見するのか，そのプロセスについて書いています。ちなみに，NetBIOS名は，後方互換性のためだけに用いられます。基本的には，DNS名が用いられるべきです。

このプロセスを知っておくなら，ドメインコントローラーの検出に問題が生じているときのトラブルシューティングにも役立つと思います。

ロケーターがどのようにドメインコントローラーを発見するのか

以下の流れによって，ロケーターはドメインコントローラーを発見します。

① クライアント（ドメインコントローラーを探しているコンピューター）において，ロケーターは，ローカルのNetlogonサービスに対して，RPCコールを開始します。Netlogonサービスによって，DsGetDcName APIコールが実行されます。

② クライアントは，ドメインコントローラーを選ぶのに必要な情報を集めます。そしてその情報を，DsGetDcNameコールを使って，Netlogonサービスに渡します。

③ クライアントのNetlogonサービスは，集めた情報を使い，次の二つのうち一つの方法を用いて，ドメイン内のドメインコントローラーを探します。

– DNS名の場合，IP/DNS対応のロケーターを使ったNetlogonクエリDNSは，SRVレコードを特定するために，ドメイン名を適切な文字列に付加した後に，DsGetDcNameが，DnsQueryコールを呼び出し，SRVレコードとAレコードをDNSから読みとります。

– Windowsベースのドメインにログオンしているワークステーションは，以下の一般的な形式でSRVレコードのDNSを問い合わせます。

_service._protocol.DnsDomainName

Active Directoryのサーバーは，TCPプロトコルを使って，LDAPサービスを提供します。それで，クライアントはLDAPサーバーを探すとき，次の形式でDNSにレコードを問い合わせます。

_ldap._tcp.DnsDomainName

– NetBIOS名の場合には，Netlogonは，Microsoft Windows NT version 4.0互換のロケーターを使って，ドメインコントローラーの探索を行います。
Windows NT 4.0またはそれ以前の場合，「探索」は，プライマリドメインか，信頼されているドメイン内で，認証のためのドメインコントローラーを見つけるためのプロセスです。

④ Netlogonサービスは，名前が登録されているデータをコンピューターに送ります。NetBIOSドメイン名に関しては，メールスロットメッセージとしてデータが実装されています。DNSドメイン名に関しては，データは，LDAP User Datagram Protocol (UPD)検索として実装されています。(UDPとは，TCP/IPプロトコルの一式に含まれる，経路確保などの事前のやり取り（コネクションの確立）無しに、データ送信を開始するパケット通信の方式です。)

UDPは，一つのコンピューター上の一つのプログラムが，他のコンピューターの一つのプログラムに対してのみ，データを送信できることに注意してください。UDPはプロトコルのポート番号を含んでいるため，リモートコンピューター上の複数のあて先（プログラム）の中から，正しく見分けることができます。

⑤ 有効なドメインコントローラーはそれぞれ，DsGetDcNameに対して，自分が現在利用可能な状態にあるかどうかという情報を返します。

⑥ Netlogonサービスは，ドメインコントローラーの情報をキャッシュするので，以後のリクエストにおいて，検出プロセスを繰り返す必要はなくなります。

クライアントがログオンしたりドメインに参加したりする際，ドメインコントローラを検出しなければなりません。クライアントはドメインコントローラーを見つけるために，DNS LookupのクエリをDNSに対して送り，できれば，クライアントが所属するサブネットの中で見つけようとします。
それで，クライアントは次の形式でDNSに問い合わせて，ドメインコントローラーを見つけようとします。
_LDAP._TCP.dc._msdcs.domainname

クライアントがドメインコントローラーを見つけた後，LDAPを使って，Active Directoryにアクセスするためのコミュニケーションを確立します。やりとりの一部として，ドメインコントローラーは，クライアントがどのサイトに属しているのか，クライアントのIPサブネットから特定します。もし，ドメインコントローラーと通信しているクライアントが最寄のサイトに属しているのではない場合，ドメインコントローラーは，クライアントのサイト名を返します。もし，クライアントがすでにそのサイト内でドメインコントローラーを探して見つけられなかった場合（例えば，クライアントが，クライアントのサブネット内で，ドメインコントローラーを探すために，DNS LookupのクエリをDNSに送ったときなど），クライアントは，最適ではないドメインコントローラーを使います。そうではない場合，クライアントは最適なサイトを指定した新しいDNS Lookupを再び行います。

クライアントがドメインコントローラーを見つけた後，ドメインコントローラーのエントリーはキャッシュされます。もし，ドメインコントローラーが最適なサイト内になかった場合には，クライアントは，15分後にキャッシュを消去します。そして，最適なドメインコントローラーがクライアントと同じサイト内にないか，探そうと試みます。

クライアントがドメインコントローラーとのコミュニケーション経路を確立した後，ログオンや認証証明書，またWindowsベースのコンピューターに必要であれば，セキュアチャネルを確立することができます。こうして，クライアントは，ディレクトリに対して，通常のクエリを投げたり，情報を検索したりする準備が整います。

クライアントは，ログオン時に，ドメインコントローラーとLDAPコネクションを確立します。ログオンプロセスは，Security Accounts Managerを用います。コミュニケーションパスはLDAPのインターフェースを使い，クライアントはドメインコントローラーによって認証されるため，クライアントのアカウントは，検証され，Security Account Managerからディレクトリサービスエージェントに渡されます。そしてデータベースレイヤーに渡され，最後に，Extensible Storage engine(ESE)のデータベースに渡されます。