第855回 Sambaで作るActive Directory互換環境 (4) UNIX属性の利用
https://gihyo.jp/admin/serial/01/ubuntu-recipe/0855?utm_source=feed
#gihyo #技術評論社 #gihyo_jp #技術解説 #OS #サーバ関連 #Ubuntu #Samba #Active_Directory
第855回 Sambaで作るActive Directory互換環境 (4) UNIX属性の利用
https://gihyo.jp/admin/serial/01/ubuntu-recipe/0855?utm_source=feed
#gihyo #技術評論社 #gihyo_jp #技術解説 #OS #サーバ関連 #Ubuntu #Samba #Active_Directory
SambaはWindows OSの持つ各種ネットワーク機能を実装したフリーソフトウェアです。中でも、利用できるファイル共有サーバー(第85回)やプリントサーバー(第218回)の機能を提供することは有名です。 実はこのSambaはActive Directory(以下、AD)のドメインコントローラー(以下、DC)互換の機能も提供しています。Sambaを使ったAD互換環境の構築方法を複数回に分けて解説します。 Samba ADのメリット・デメリット Samba ADのメリット・デメリットを整理しておきます。 そもそもSamba ADというよりAD自体のメリットですが、第836回でも触れた通りユーザーやコンピューターを一元的に管理や認証・認可できることです。 ADを使った認証・認可の例としては、ADドメインのユーザー(ADユーザー)が挙げられます。ドメインに参加しているマシンであり、かつ、適切な権限があれば、ADユーザーは特に事前設定不要でそのマシン(PC)にログインできます。 また、ADによるリソース管理の例については第836回でも紹介しましたが、グループポリシー(GPO)を利用することでドメインのコンピューターを一括で設定・管理(統制)できます。 どちらも会社組織において統制に関わる重要な部分であり、かといって、1ユーザー・1マシンごとに温かみのある作業で対応して回るのは(組織が大きくなればなるほど)骨の折れる作業です。この作業コストの削減を見込めることがADの最大のメリットといえるでしょう。 続いて、Samba ADを使うことのメリットですが、このようなAD(互換)環境をWindows ServerのAD機能(Active Directory Domain Services。以下、Samba ADと区別するため、Windows ServerのAD機能のことをADDSと呼びます)をWindows Serverなしで構築できることでしょう。 Windows Serverのライセンスは価格的に個人で購入するにはちょっとハードルが高いと考えられます。ご家庭でAD環境を運用してみたいといった場合にはSamba ADの出番かもしれません。最近だと、ADに参加できるNASといったものもあるようなので、試してみたいという方もいるかと思います。 ライセンス以外でも、例えばRaspberry PiのようなARMボード(マシン)でもSamba AD DCを動作させることができます。これは変化球の一種だと思いますが、ADDS環境にLinux上で動作するSamba AD DCを混ぜておけば、理論上はWindowsに固有の問題に遭遇した場合でもDCが全滅するといった事態を回避できるという可能性も考えられます。 本稿執筆時点で最新バージョンであるWindows Server 2025ではARMマシンでも動作するという情報がありましたが、筆者の知る限りでは、公式にはリリースされていなく、ISOイメージもまだ公開されていないようです。 例えばこの事件は記憶に新しいかと思います。 また、AD(特にLinuxマシンから見たAD)の理解を深めるという意味ではSamba ADは「良き師匠」となる可能性があります。第836回でも触れた通り、ADDSはLDAPやKerberos、DNSなどのオープン系の技術要素の統合・実装です。ADDS環境であればWindowsらしい「GUIで値を入力していったらいい感じに設定・構成してくれる」といった部分も、コマンドラインベースで作業するSamba ADでは「実際には何をやっているのか」を意識しながら進める必要があります。筆者の感想になりますが、ADDS互換を目指すという都合上、Samba ADというプロジェクト自体も「ADはどういう技術の集まりで成立しているのか」という点でWikiが充実しているように感じられます。もちろん、Sambaはソースコードが公開されており、その気になれば読むことができます。 一方で、世の常ですが、メリットはデメリット(ないしは注意点・考慮すべき点)にもなります。 まず、Samba ADはあくまで互換ソフトウェアであり、ADDSそれ自体ではないという点が挙げられます。例えば、Sambaでは使用できる機能レベルの選択の幅に制限がある、あるいは、選択できたとしても動作しない機能がある可能性があります。 「機能レベル」はADドメインで利用できる機能の範囲を設定しているもので、Windows Serverのバージョンと対応付けられています。当然、機能レベルが高いほどより新しい機能が使えます。この機能レベルという仕組みにより、ドメインに複数のバージョンのWindows ServerのDCを混在させられます。例えば機能レベルにWindows Server 2016を選択しているドメインでは、この機能レベルをサポートするWindows Server 2016以降(本稿執筆時点でWindows Server 2016, 2019, 2022, 2025)のマシンがDCとして参加できます。 Samba ADの機能レベルは、公式情報を確認すると、Windows Server 2008 R2, 2012, 2012 R2, 2016の各機能レベルが'Supported Functional Levels'とされています。ただし、その機能レベルを選択できるからといって、その機能のすべてが実装されているわけではありません。機能レベルごとに欠けている機能や不完全な機能があります。なお、筆者が見た限りです(個人の所感ともいいます)が、古い機能レベルほど、いわゆる「枯れている」状態とはいえそうです。 また、機能レベルに関係なくSamba AD全体で実験的だったり、制限のあったりする機能や提供されていない機能があります。Windows Server 2019, 2022, 2025の機能レベルは現時点で選択肢として用意されていないようです。 公式WikiにはWindows Server 2008についても記載がありますが、Ubuntuのman page smb.conf(5)などを読むと、選択できる機能レベルはWindows Server 2008 R2以上となっています。 現在のSamba ADで最も低い機能レベルはWindows Server 2008 R2なので、機能レベルごとに欠けている機能のうちWindows Server 2008 R2機能レベルで欠けている機能は、Samba AD全体で欠けている機能です。
今回はSMBサーバーの別実装、KSMBDを紹介します。 SambaとKSMBD UbuntuでSMB(Server Message Block)サーバーを仕立てる場合は、通常はSambaを使用します。なんならUbuntu誕生前からそうです。 SMBはMicrosoftが策定しているプロトコルで、仕様書が公開されています。したがって、Sambaのような実装の開発が可能となります。 ご存知のとおりSambaは大きくsmbdとnmbdから構成されており、smbdはシングルスレッドで動作しています。また、ユーザースペースで動作するデーモンであり、SMBの仕様書にある内容をすべて実装するのが困難です。 そんな中登場したのがKSMBDです。こちらはカーネルスペースで動作しており、Sambaが抱えるいくつかの問題を解決します。そのうちの1つはマルチスレッド化による高速化です。ただしSambaを置き換えることを目標に開発されているわけではありません。 KSMBDはUbuntu 22.04 LTSで採用されたカーネルのバージョンである5.15からメインラインにマージされました。その後カーネル6.6で安定版とされました。24.04 LTSのカーネルは6.8以降なので、KSMBDを使用するにはちょうどいいタイミングです。なお、少なくとも24.04 LTSではKSMBDはカーネルモジュールとしてビルドされています。 KSMBDを動作させるには、ユーザースペースで動作するユーティリティであるksmbd-toolsも必要です。カーネルモジュールについては特に気にする必要はなく、使用するのはもっぱらこちらです。 動作環境 前述のとおり、カーネル6.6から安定版とされたことにより、使用するUbuntuのバージョンは24.04.2 LTSです。カーネルのバージョンは6.11で、ksmbd-toolsのバージョンは3.5.1です。 なお、特徴上Sambaとは同居できず排他利用です。したがって、Sambaが動作していない24.04 LTSを用意するのがおすすめです。 インストールと初期設定 では進めていきましょう。まずインストールですが、前述のとおりksmbd-toolsが対象です。 $ sudo apt install ksmbd-tools 次に設定ファイルを編集します。Sambaだと/etc/samba/smb.confですが、KSMBDでは/etc/ksmbd/ksmbd.confです。ただしデフォルトでは存在せず、/etc/ksmbd/ksmbd.conf.exampleがあるので、これをコピーします。 $ sudo cp /etc/ksmbd/ksmbd.conf.example /etc/ksmbd/ksmbd.conf あとはksmbd.confを編集していきます。 ksmbd.confは、中身を見るとわかるのですが、smb.confと書式が似ています。 もちろん違いもあって、SambaとKSMBDでは機能が違うのでセクションの項目には違いがあります。また、変数は使用できません。具体的には、smb.confでは%hはホスト名を表す変数ですが、ksmbd.confにはこの機能はありません。したがってnetbios nameはデフォルトではKSMBD SERVERですが、ここはホスト名に変えておくといいでしょう。 共有設定に関しては、よほど凝ったことをしていなければそのままコピー&ペーストすると動きます。 Sambaにはsmb.confの設定を確認するtestparmコマンドがありますが、KSMBDにはこれに類するものはありません。 設定を書き換えたら、適用します。 $ sudo systemctl restart ksmbd.service エラーが出なければ成功です。 Windowsはデフォルトの設定だとユーザーアカウントなしでのログインはできないため、ログインユーザーを作成します。 $ sudo ksmbd.adduser --add $USER 名前解決 これで共有フォルダーとしては使用できるようになりましたが、Ubuntuの「ファイル」やWindowsのエクスプローラーなどからは共有フォルダーとしては見えません。Sambaにあるnmbdに相当するものがKSMBDにはないため、他の方法を用意します。 avahi Ubuntuで見えるようにするためには、Avahiに設定を追加します。Ubuntu Serverにはインストールされないので、avahi-daemonパッケージをインストールしてください。そして/etc/avahi/services/smb.serviceを次の内容で作成します。