AD連携を行う上でのセキュリティ

DNSをAD統合している場合、DNSのレコードもADオブジェクトとして管理されることは前述した通りである。ADオブジェクトである以上、アクセス権が存在し、セキュリティで保護された更新が有効である場合、基本的に Creator-owner とドメイン管理者のみ変更可能である。

クライアント-DDNSの場合はクライアントPCのSystemアカウント（＝AD上ではそのコンピュータアカウント）が実行するので、管理者が手動で実行するようなケースを除いて特に気にすることはないのだが、問題はDHCP-DDNSである。

特にセキュリティで保護された更新のみ許可されたゾーンで、DHCPサーバをフェールオーバーさせた場合、切り替え前のサーバでリースしたクライアントのDNSレコードが切り替え後のサーバで更新不可能（これはIPアドレスの変更だけでなくタイムスタンプの更新も含む）になってしまう。

そこで、DnsUpdateProxyというビルトイングループがADに用意されている。 参考：KB816592 の「DnsUpdateProxy セキュリティ グループを使用する」

このセキュリティグループに、すべてのDHCPサーバのコンピュータアカウントを登録することで、DHCPサーバのフェールオーバー時に発生しうるアクセス権の問題は解決できる。

ただしその仕組みというのは、この DnsUpdateProxy のメンバーが作成したDNSレコードはオブジェクトのアクセス権保護が設定されない。従って後からクライアント-DDNSでレコードが更新された場合、所有権は自然にそのコンピュータアカウントに設定されるという具合である。

しかしこれは、DnsUpdateProxyメンバーのサーバでDHCP-DDNSにより作成したレコードは好き放題に書き換えられることになることを示している。また、DHCPサーバがドメインコントローラ上に構築されている場合は、DHCPサービスがドメインコントローラのコンピュータアカウントで実行されていることになり、かなり高い権限を持つことになる。（クライアントDDNSで更新されたレコードでも上書き可能なようである）

Technet Library では以下のような状況の場合は、更新専用IDを作成することを推奨している。
これらの3条件がandなのかorなのか明記されていないが、おそらく「セキュリティで保護された動的更新だけを許可」が 目的の場合にはこの対処が必要だと思われる。 作業手順は Technet Library に記載されている。

ただし、重要な注意事項があり、DHCPサーバを別のサーバにフェールオーバーさせた場合、（恐らく）セキュリティ上の理由により この専用IDの credential はバックアップされないため、切り替え後に手動で入力する必要がある。

逆に言えば、オブジェクトのセキュリティ保護にこだわらないのであればこの作業は不要ということになる。

はたして「セキュリティで保護された更新のみ」にする必要があるのか？

オブジェクトベースのアクセス権制御が最初から機能として存在していることに加え、
ドメイン管理者の権限ではなく適正に格下げされた権限でサービスを動作させるのは
セキュリティの基本であるのは確かだが、DHCPサーバの冗長構成を組んだ場合の解決策が
あまりにも ad hoc としか言いようがない。

DnsUpdateProxyの実装を見るとそこにはセキュリティの考慮は一切なく、
たとえば DHCPクライアントPCにサーバと同じ名前を付けて
Workgroup状態でネットワークに繋ぐとどうなるか…。間違いなく
DHCPサーバからの更新でDNSレコードは上書きされるだろう。

更新専用IDを作成したとしても、あかの他人がレコードを（故意にせよ事故にせよ）
書き換えられることには変わりないわけで、どこまで固執する必要があるのかは
各サイトによってもっとしっかり議論されるべき問題であると思う。

なお、サーバなど常時運転していて DNS レコードが消えて困るものについてはクライアント-DDNSをOFFにしておく方がよい。トラブルの元は最初から断ち切っておくのが基本である。マルチホームなサーバがいる場合には、よほどの理由がない限りすべてのインタフェースでクライアント-DDNSを切っておくことを強くオススメしたい。

戻る