こんにちは。先月からSEとなったdessinです。
実務でADの話がたくさん出てくるので勉強した内容を書きます。
背景
ADについてはこちらの連載が大変参考になりました。ID管理がワーキンググループからドメイン管理に発展したという経緯が書かれており、こういった歴史も書かれた記事は私のような素養のない者には助かります。
しかし、この記事に書かれた内容の、「ドメインコントローラーを構築すると、DNSサーバーにSRVレコードとAレコードが自動的に作成されます。」というのがよくわかりませんでした。ドメインコントローラーにそんなことできるのかと。
DNSサーバーは以前に構築したことがあるし、同じネットワーク内にドメインコントローラーを作れば、自動的にレコードが登録されるところが見られるかと思い、Azureに実装しました。
概要
- AD検証用のリソースグループ、Vnet作成
- DNSサーバーの構築（手前味噌ですが私の記事を参考に）
- ドメインコントローラーの構築
これだけ見ていても、いつレコードが自動で登録されるのか、登録できるように設定されるのかよくわかりませんが進めます。
補足
↑の通り進めようとしたのですが、DNSサーバーはドメインコントローラーの構築の際に自動的にインストールされてしまいました。そのため、「ドメインコントローラー＋DNSサーバー」となったマシンでのDNSサーバーの様子を確認し、さらにそこからDNSサーバーの役割だけ削除して、2.で構築したDNSサーバーを使えないかを確認してみます。
作業
リソースグループ等の作成
リソースグループ名は"ADtest"、Vnet名は"ADnet"とします。Vnet内に作成するサブネットは10.0.0.0/24としています。仮想マシンは全部この中に作成します。
DNSサーバーの構築
概要に示した通り、以前の記事と同様にDNSサーバーを構築します。イメージはWindows Server 2019でサイズをStandard B2sにすることと、先に作ったVnet、サブネット内に作成することに注意。
作成したVMにRDPし、サーバーマネジャーからDNSサーバーのroleをインストールします。そして、名前解決要求のソースを制限するところまでやりました。
この検証の要点は、Forward Lookup Zonesに、ドメインコントローラーの情報が自動的に入ることを確認することですね。
背景のところで紹介した記事を再度確認すると、やはり「前方参照ゾーン」に情報が入っていることが見えます。
DNSサーバーはいったんここまでにしてシャットダウンしポータルで停止し、ドメインコントローラーに移ります。
ドメインコントローラーの構築
Azure上でドメインコントローラーを使うときに特有の設定
Azureの仮想マシンをドメインコントローラーとして構築するには一工夫必要なそうです。この記事を参考に、まずは仮想マシンを作成します。どうやらキャッシュを無効にしたディスクを使用せねばならぬ模様。記事に従って、「ADサーバーの事前構築」のところから「Azure の ネットワークインタフェース の IP固定化」まで真似します。ただし、サイズはB2sに変更するなど、検証用に小さくしました。名前は適当に"DC"としました。
この記事のポイントは、「ディスク」のタブで「新しくディスクを作成する」ところですね。仮想マシンを作成しました。
RDPしてディスクの初期化をするところで、デフォルトだとGPTが選択されていました。
とりあえず記事と同じMBRを選択しました。記事に従い、ディスクの設定を行いました。
さらにポータルでネットワーク構成でプライベートアドレスを「静的」に設定しました。
ドメインコントローラーのインストール
DCのRDPで、サーバーマネジャーでインストールします。ほとんどDNSサーバーのインストールと同じです。先ほどの記事と同じことをしますが、RDP画面を日本語化せずに進めているので、参考までにスクショを載せています。わかりづらければ先ほどの記事を参考にしてください。
チェックを付けようとすると別の画面が現れますが、そのままAdd Featuresします。
ここでDNSサーバーの役割追加はせず、Active Directory Domain Seviceだけです。そういう検証です。
確認画面では、自動で再起動するチェックボックスを入れてからインストールします。
インストールが完了したら、ドメインコントローラーにするためにこの部分をクリックします。
始めの画面ではadd a new forestを選択し、適当なドメイン名を設定します。forestとはドメインの管理単位のひとつですが、今は初めて作成するのでnew forestを追加するということですね。
次の画面は、パスワード設定です。検証用にはあまり深く考えることはなさそうです。デフォルトの✓状況のまま、パスワードだけ設定します。
次の画面はそのまま次へ。
次の画面も、自動で入るのでそのまま次へ。
次の画面では、キャッシュを無効にしたディスクを使用するために、パスをいじります。先ほどの記事を参考に次のように作成していきます。
最終的には下のように。
次の画面は単なる確認画面です。
最後は何か検証されますが、問題ないようです。黄色いチェックが出ていてもinstallをクリックします。
ウィザードが終わると、自動で再起動が入るのでRDPは一度切断されます。再度接続すると、、、
そこには"DNS"の文字が！！！なんでお前そこにおんねん！！！
分けて作成したDNSサーバーに、レコード登録されるところを確認したかったのですが・・・
教訓は、参考にした記事にはDNSが入るということは書かれてあったし、問題意識をもって記事を参考すること、それも通読しておくことが大事ということでしょうか。
とりあえずDNSサーバーの設定内容を確認してみます。そのあと、役割の削除でDNSサーバーを削除したらどうなるか確認します。
DNSサーバの中身
サーバーマネジャーの"DNS"をクリックし、下の画像の通り設定内容を確認します。
クライアントがドメインに参加するには以下のことが必要です。
- DNSサーバーはドメインコントローラーのIPアドレスを知っている
- クライアントがそのDNSサーバーへアクセスできる
- 名前解決の時はそのDNSサーバーを優先的に使うよう設定する
あとはパスワードなどの資格情報です。
1については上の画像の通り確認できました。2についても、同じサブネット内に置かれた仮想マシンなら通信が可能です。3については参考にした記事に書かれている通り、ポータルで設定できます。
ドメイン参加
記事を参考にクライアントとなる仮想マシンを作成し、DNSサーバーを固定する設定をしました。
（感想：DNSサーバーの設定は仮想ネットワークに紐づいているのか・・・・）
この仮想マシンにRDPして、GUIでドメイン参加します。
このとき、一度再起動しないとドメインの名前解決ができず参加できませんでした。再起動するとDNSサーバーが指定の10.0.0.5になり、参加できました。
ドメインコントローラーとDNSサーバーの分離
DNS機能の削除
まず、DNSサーバーと一体になったドメインコントローラーから、DNSサーバーの機能を削除します。
始めの画面ではNextをクリック。
次の画面では、サーバーを選択します。
役割と機能の追加の際にはチェックしなかったのに、DNSサーバーに✓が入っていました。✓を外してRemove Featuresします。
✓を外そうとしたときにこの画面が出てきました。DNSを必要とする機能を一緒に削除するか、という内容のようですが、その中にはActive Directory Domain Serviceはありませんね。分離させられそう。
次の画面ではなにも触らずにNextをクリック。
最後の確認画面で、DNSが削除されることを確認しRemoveをクリック。
Removeが終了したようです。再起動で反映されるといったようなメッセージが見えます。
再起動してRDPしたところ、ちゃんとDNSが削除されました。
クライアントへの影響
testuserにRDPして、再びドメインに参加してみます。今のところ、一度参加した後は特に何もしていないので切断されてはいない感じでしょうか。
Disconnectしようとすると警告されますが、検証なので無視します。
その後自動的に再起動されます。
同じ方法でドメイン参加しようとすると当然ですが失敗します。
ADデータベースの状態
DNSサーバー機能を削除しても、ADのデータベース自体には影響がないです。testuserのオブジェクトは依然として存在します。ドメインからDisconnectしたにもかかわらずこのような状態なのはドメインコントローラーとクライアントの通信ができていないからでしょうか。
別のDNSサーバーを使ってみる？？？
DNSサーバーにおけるドメインコントローラーの情報はSRVレコードといいます。これを別のマシンにインストールされたDNSサーバーに登録するとどうなるのでしょうか。
現状では、最初に作ったDNSサーバーには（当然ながら）ドメインコントローラーの情報はありません。
「SRVレコードが自動登録される」という説明にひっかかったことが、この記事を書くきっかけでしたが、どちらかというと「ドメインコントローラー自身が、DNSサーバーと一体になっていることを利用してドメイン情報をDNS側に流用する」といった表現のほうがしっくりきますね。
SRVレコードを登録してみます。
New Zoneの追加でtest.comを追加。
Other New RecordsをクリックするとSRVレコードを選択できるようです。
よくわからないがServiceにはLDAPを選択しました。そしてサーバー情報にはDC.test.com（＝ドメインコントローラーのFQDN）を入力。
IPアドレスがないと名前解決にならないのではないかと思いますが、SRVレコードにはIPアドレスを入力するべき場所がありません。そこでAレコードでdc(.test.com)の名前に対して10.0.0.5を登録しておきます。
これで、DNSサーバーのローカル環境で、ドメインコントローラーの（プライベート）名前解決ができました。
さらに、仮想ネットワークに指定した静的DNSサーバーを10.0.0.4 (ドメインコントローラーじゃないほうのDNSサーバー）に設定しなおしました。
クライアントでドメイン参加しなおし
さてクライアントでの名前解決はどうでしょうか。いけました。
とりあえずDNSサーバーを介してドメインコントローラーにアクセスできる状態です。これでドメイン参加できなかったら、SRVレコードの登録方法をいじってみるか、そうでなければもうDNSサーバーはドメインコントローラーから分離するなって感じです。
↑できませんでした！
ドメインコントローラーが管理しているはずのtest.comに参加できませんでした。
まとめ
他の情報源を当たってみると、DNSサーバーとドメインコントローラーは分けずに作成するのが通常の運用方法のようです。公式DOCを見つけたかったのですが、「同じマシンにドメインコントローラーとDNSサーバーを構築します」といったような表現は見つからず、「DNSの名前空間を利用します」というような表現があるのみでした。しかし、この検証（実験）からは、ADをインストールした時に入っているDNSを素直に利用するほうがよいことがわかりました。
全然知らないADについて無謀な実験をしました。駄文をだらだら書いてしまいましたが、自分の中ではADというものがわかるきっかけになりました。ADの冗長構成とは、この内容は関係が深いのではないかと推測します。
お疲れさまでした。