#背景
net ads joinコマンドでADに参加させるとOU(組織単位)が変更されてしまう事象が発生。
ドメインコントローラ(Win)にコンピュータオブジェクトを「Shared」というOUコンテナに作成。
RHELサーバでAD参加させると「Shared」からはオブジェクトが消え、デフォルトの「Computers」コンテナに移動してしまう。
この対策として検証を行った。
(昔からある伝統的な方法が受け継がれているため、sssdではなくsambaでのAD参加となります。RedHat的にはsssdを使用したrealmコマンドが現在は推奨のようです。)
#検証結果概要
コマンドでOUを指定していない場合はデフォルトのコンテナに参加する。
コマンドオプションでOUを指定することで事象が解消する。
オプションの指定方法はsambaのバージョンにより異なる。
net adsコマンドはsambaを使用しているためsambaがインストールされいてるかで挙動が変わる。
##環境
ドメインコントローラ：Windows2019
RHEL7.7
RHEL8.6
#検証
AD参加コマンド
net ads join -U <ADユーザ> -S <ドメコンサーバ>
上記コマンドをRHEL7.7サーバで実行したとき、OUがデフォルトコンテナの「Computers」に移動する事象が再現した。
そこで下記のようにOUを明示的に指定することでドメインコントローラで登録していた「Shared」に参加させることに成功。
net ads join --ou="OU=Shared,OU=Servers,DC=example,DC=com"
※--ouのオプション指定だが、sambaのバージョンによって異なる可能性があるので以下コマンドで確認
net --version
smbd -V
ここまでの検証をRHEL7.7とRHEL8.6のサーバで実施したところRHEL8.6ではOUが移動する事象が発生しなかった。
調査をするとsmbd.serviceの有無によって挙動が変わるようだ。
smbd.serviceが存在していない(インストールされていない)場合は、net adsコマンドはsambaの最小構成のコマンドとして動き、sambaクライアント寄りのコマンドとしてADに参加する。よってドメインコントローラの情報は考慮されず、デフォルトのOUである「Computers」に入る。
smbd.serviceが存在する場合(smbdがinactive(dead)状態でも)、net adsコマンドはsmbdの起動状態にかかわらずsambaサーバとしての動きをするためドメインコントローラに登録されいる情報を参照してADに参加する。
よって、今回のOUが移動する事象が発生しなかった。
##結論
OUを明示的に指定してあげれば問題なし！
今回は検証していないがreamlコマンドでsssdを使用すると柔軟に対応してくれるようなので検討した方が良い。