samba4 では samba-tool domain join <dnsdomain> SUBDOMAINコマンドがあるものの、サブドメインを構成できませんでした。調べたのですが、どうやら現状サポートされていないようで(https://serverfault.com/questions/829681/samba4-possible-to-build-a-ad-forest)、サブドメインを単独で作成し、信頼関係(一方向、子ドメインから親ドメイン)を設定することで、対処してみました。
構成は以下の通りです。dom01.local/subdom01.dom01.localともにsamba4です。
なお、dom01、subdom01ともに、DNSはBIND9_DLZにて、互いのゾーンを名前解決できる状態になっていることが前提です。(例えば stubゾーンとして等。)
2021/04/17追記: BIND9_DLZのスタブゾーンによる名前解決は、mastersだけではゾーン転送されません。(BIND9_DLZ, 9.11.5, Debian10/Buster)そこでmastersに加えてforwardersを指定することで子ゾーンの名前解決ができました。具体的には以下の様にしています。
2021/04/17追記以上
信頼関係の設定は、samba-toolを用いず、windowsの「Active Directory ドメインと信頼関係」を用いたところ、samba4 ad dc間でも設定できました。設定は、2台のそれぞれのドメインのwindows クライアントで行いました。
信頼関係の設定自体はWindows Serverで行う方法と全く変わりありませんので、信頼関係の設定方法は割愛しますが、結果から言って、一方向の信頼関係の設定の後、subdom01のワークステーションにdom01のユーザでログインできたことは確認できました。その反対は、ログインできないことも確認できました。
なお、samba-toolで同様のコマンドを使ったところ、信頼関係を削除してもログインできる状態になったので、samba-tool側の問題はあるのだろうという感じでした。
なお、Forest間の推移する信頼関係で、Windows Server ドメインツリー(親子)の親ドメインと双方向の信頼関係をさらに設定したところ、Windows server の子ドメインのアカウントで、subdom01にログインできました。構成は以下の通りです。
ネット上には、Samba AD DC間での信頼関係やサブドメインについての情報がほとんどなかったので、本稿を挙げた次第です。なお確認は、Debian 10 Buster/ Bind9 9.11.5で行いました。
以上です。
構成は以下の通りです。dom01.local/subdom01.dom01.localともにsamba4です。
なお、dom01、subdom01ともに、DNSはBIND9_DLZにて、互いのゾーンを名前解決できる状態になっていることが前提です。(例えば stubゾーンとして等。)
2021/04/17追記: BIND9_DLZのスタブゾーンによる名前解決は、mastersだけではゾーン転送されません。(BIND9_DLZ, 9.11.5, Debian10/Buster)そこでmastersに加えてforwardersを指定することで子ゾーンの名前解決ができました。具体的には以下の様にしています。
# /etc/bind/named.conf # 以下を追加 include "/etc/bind/subdom01.dom01.local.conf"; # /etc/bind/subdom01.dom01.local.conf zone subdom01.dom01.local { type stub; forwarders { 2WWW:XXXX:YYYY:ZZZZ::66; 192.168.2.66; }; masters { 2WWW:XXXX:YYYY:ZZZZ::66; 192.168.2.66; }; }; # コンフィグチェック sudo named-checkconf # bind9の再起動 sudo systemctl restart bind9なお、子側は/etc/bind/named.conf.options内で、forwardersを親側のad dc機にすることで親側の名前解決ができるので、上述の設定と合わせると互いのゾーンの名前解決ができる状態になります。
2021/04/17追記以上
信頼関係の設定は、samba-toolを用いず、windowsの「Active Directory ドメインと信頼関係」を用いたところ、samba4 ad dc間でも設定できました。設定は、2台のそれぞれのドメインのwindows クライアントで行いました。
信頼関係の設定自体はWindows Serverで行う方法と全く変わりありませんので、信頼関係の設定方法は割愛しますが、結果から言って、一方向の信頼関係の設定の後、subdom01のワークステーションにdom01のユーザでログインできたことは確認できました。その反対は、ログインできないことも確認できました。
なお、samba-toolで同様のコマンドを使ったところ、信頼関係を削除してもログインできる状態になったので、samba-tool側の問題はあるのだろうという感じでした。
なお、Forest間の推移する信頼関係で、Windows Server ドメインツリー(親子)の親ドメインと双方向の信頼関係をさらに設定したところ、Windows server の子ドメインのアカウントで、subdom01にログインできました。構成は以下の通りです。
以上です。
コメント
コメントを投稿