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を動作させることができます[1]。これは変化球の一種だと思いますが、ADDS環境にLinux上で動作するSamba AD DCを混ぜておけば、理論上はWindowsに固有の問題[2]に遭遇した場合でもDCが全滅するといった事態を回避できるという可能性も考えられます。
[1] 本稿執筆時点で最新バージョンであるWindows Server 2025ではARMマシンでも動作するという情報がありましたが、筆者の知る限りでは、公式にはリリースされていなく、ISOイメージもまだ公開されていないようです。
[2] 例えばこの事件は記憶に新しいかと思います。
また、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”とされています[3]。ただし、その機能レベルを選択できるからといって、その機能のすべてが実装されているわけではありません。機能レベルごとに欠けている機能や不完全な機能があります。なお、筆者が見た限りです（個人の所感ともいいます）が、古い機能レベルほど、いわゆる「枯れている」状態とはいえそうです。
また、機能レベルに関係なくSamba AD全体で実験的だったり、制限のあったりする機能や提供されていない機能[4]があります。Windows Server 2019, 2022, 2025の機能レベルは現時点で選択肢として用意されていないようです[5]。
[3] 公式WikiにはWindows Server 2008についても記載がありますが、Ubuntuのman page smb.conf(5)などを読むと、選択できる機能レベルはWindows Server 2008 R2以上となっています。
[4] 現在のSamba ADで最も低い機能レベルはWindows Server 2008 R2なので、機能レベルごとに欠けている機能のうちWindows Server 2008 R2機能レベルで欠けている機能は、Samba AD全体で欠けている機能です。
[5] Windows Server 2012 R2以前はすでにMicrosoft社の提供する延長サポートが終了しています。機能レベルとOSとしてのWindows Serverのバージョンは独立した考え方ですが、過去には機能レベルが廃止されており、また、Windows Server 2003機能レベルは廃止途上にあります。
加えて、Samba ADの構築・運用にはADに加え、Samba AD独自の知識やノウハウが必要です。つまり、何か問題が起きた場合、最終的には自分で設定やログを見直して調査・対応する必要があるということでもあります。筆者としてはこれは「おもしろい部分・楽しい部分」としてむしろ「メリット」の1つに挙げたいところですが、ことを始める前に認識しておくべき点です。
このように互換ソフトウェアであるSamba ADは本家のADDSと比べると当然ながら不足や制約、考慮すべき点がそれなりにあります。そのため、各種機能を駆使した大規模なADを構築・（本番）運用したいのであれば素直にWindows Serverを使うべきであるというのが公正な評価でしょう。
……と、どうしても「但し書き」的な説明が多くなってしまいましたが、結局のところは、Samba ADの性質（制約）を理解したうえで自己判断・利用あるいはエンジョイすればいいだけではあります。もっともこれはSambaに限らず、すべてのFLOSSについていえることでしょう。実際、本稿で紹介するようなシンプルな構成かつ小規模な利用であれば、それなりに使えるのではないかと思います。
1台目のSamba AD DCの構築
今回は次のような構成でSamba AD DCを構築します。
ドメイン名：example.com
1台目のDC（今回構築するもの）
ホスト名：samba-ad-dc01
IPアドレス：192.168.1.150
2台目のDC（次回構築するもの）
ホスト名：samba-ad-dc02
IPアドレス：192.168.1.151
OS：Ubuntu Server 24.04 LTS
DCはドメインのユーザーやコンピューターの認証・認可・管理を一手に引き受けるため、複数台配置して冗長構成をとることが一般的です。そのため、今回のシナリオもDCを2台構成にします。また、OSとホスト名はすでに設定済みの状態から作業を開始します。
それでは、1台目のSamba AD DCを構築していきます。
必要なパッケージ群をインストールします。
samba-ad-dc01$ sudo apt install -y samba-ad-dc krb5-user bind9-dnsutils
途中、krb5-userパッケージのインストールの際に、デフォルトのレルム名を聞かれますが、空白のままEnterで抜けてください。
パッケージ群のインストールが完了したら、デフォルトで起動するSambaのサービスを停止・無効化（マスク）します[6]。
samba-ad-dc01$ sudo systemctl disable –now smbd nmbd winbind
samba-ad-dc01$ sudo systemctl mask smbd nmbd winbind
[6] ちなみにsmbdはSMB/CIFSのファイル共有サービス、nmbdはNetBIOSによる名前解決リクエストに応答するサービス、winbindはドメインコントローラーと通信してADの認証情報を利用するためのサービスです。
これらのSamba関連のサービスを停止・無効化したらデフォルトで配置されるsmb.confを削除（もしくは移動）します。
samba-ad-dc01$ sudo rm /etc/samba/smb.conf
smb.confファイルを削除したら、samba-toolコマンドでドメインを展開します[7]。
samba-ad-dc01$ sudo samba-tool domain provision –use-rfc2307 –interactive
Realm: example.com
Domain [example]:
Server Role (dc, member, standalone) [dc]:
DNS backend (SAMBA_INTERNAL, BIND9_FLATFILE, BIND9_DLZ, NONE) [SAMBA_INTERNAL]:
DNS forwarder IP address (write ‘none’ to disable forwarding) [127.0.0.53]: 192.168.1.1
Administrator password:
Retype password:
[7] samba-toolでドメインを展開する際にsmb.confファイルが（再）作成・配置されますが、すでにsmb.confファイルが存在するとエラーとなるため、事前に削除が必要です。
入力項目を順に解説します。
いきなり”Realm”や”Domain”と似たようなことを聞かれて（あるいは、何を聞かれているのかがわからず）困惑するかもしれません。ADにおけるドメイン名（とコンピューター名）にはNetBIOSドメイン名とDNSドメイン名があり、ここではこの2つのドメイン名をそれぞれ聞かれています[8]。
“Realm”はDNSドメイン名を聞かれているため、今回の場合はexample.comと入力します。ADDSでドメインを作成する際の「Active Directory ドメイン サービス構成ウィザード」との対応でいうと、最初に入力するドメイン名に対応します。
他方、”Domain”はNetBIOSのドメイン名を入力する項目です。他のドメインと重複しない限りは、DNSドメインをドットで区切った一番左の部分（今回の場合はexample）の値を採用することが一般的です。プロンプトに[example]となっているようにデフォルト値もそうなっており、今回はそのままEnterを押して確定します。同じく、ADDSの構成ウィザードとの対応でいうと、「追加オプション」で聞かれるNetBIOSドメイン名に対応します。
[8] 歴史的にWindowsではNetBIOS/WINSという仕組みに名前解決を依存していた時代があり、現在もその名残があります（というか、現在でも使えます）。ADの前身であるWindows NTドメインでも名前解決にはNetBIOS/WINSが使われていました。ADでは名前解決にDNSが使われるようになりましたが、このような歴史的経緯やNTドメインとの互換性確保を理由に、ADドメインやWindowsマシンにはNetBIOS名を持たせる必要があります。
“Server Role”はデフォルトのdcとなっていますので、空欄のままEnterを押してこのマシンをDCとしてドメインをデプロイするようにします。
“DNS backend”ではDCの持つDNS機能を提供するバックエンドの選択を選択します。デフォルトではSambaにビルトインされたDNSサーバー機能（SAMBA_INTERNAL）が使用されますが、BIND[9]も選択できます。今回はデフォルトのSAMBA_INTERNALで進めるため、そのままEnterを押して確定します。
[9] BINDを使う場合、BIND9_DLZを選択します。BIND9_FLATFILEは現在サポートされず、削除予定となっています。
“DNS forwarder IP address”にはDNSフォワーダーのIPアドレスを入力します。通常、ドメインのDNSサーバー（今回の構成ではDC）はドメインのマシンからの様々な名前解決を一手に引き受けることになりますが、自力で名前解決できる範囲は今回作成するドメイン（example.com）に限られます。そのため、ドメイン外のリソースの名前解決を依頼されたときに、その依頼を転送する先を指定するのがこの項目です[10]。Ubuntu Server 24.04 LTSのインストール直後では127.0.0.53が”DNS forwarder IP address”のデフォルト値となっています[11]が、これはスタブモードで動作しているsystemd-resolvedのアドレスです。このあとsystemd-resolvedは使用できないようにするため、環境に合わせて（今回は192.168.1.1に）値を変更しておきます。
[10] 一般的なご家庭だと、ブロードバンドルーターにDNSの機能があり、そのIPアドレスを指定することになるはずです。よくわからない場合は、一旦Ctrl+Cで抜けて、resolvectl statusコマンドで現在参照しているDNSサーバーを確認してください。
[11] /etc/resolv.confから読み取った値と考えられます。
“Administrator password”にはAdministratorユーザーのパスワードを入力します。確認のためもう一度入力します。
すると、何やら大量のログが流れますが、最後に次のようなログが出て、コマンドを抜けるはずです。
INFO 2025-02-24 14:04:05,105 pid:3170 /usr/lib/python3/dist-packages/samba/provision/__init__.py #2432: A Kerberos configuration suitable for Samba AD has been generated at /var/lib/samba/private/krb5.conf
INFO 2025-02-24 14:04:05,105 pid:3170 /usr/lib/python3/dist-packages/samba/provision/__init__.py #2434: Merge the contents of this file with your system krb5.conf or replace it with this one. Do not create a symlink!
INFO 2025-02-24 14:04:05,157 pid:3170 /usr/lib/python3/dist-packages/samba/provision/__init__.py #2102: Setting up fake yp server settings
INFO 2025-02-24 14:04:05,182 pid:3170 /usr/lib/python3/dist-packages/samba/provision/__init__.py #493: Once the above files are installed, your Samba AD server will be ready to use
INFO 2025-02-24 14:04:05,182 pid:3170 /usr/lib/python3/dist-packages/samba/provision/__init__.py #498: Server Role: active directory domain controller
INFO 2025-02-24 14:04:05,183 pid:3170 /usr/lib/python3/dist-packages/samba/provision/__init__.py #499: Hostname: samba-ad-dc01
INFO 2025-02-24 14:04:05,183 pid:3170 /usr/lib/python3/dist-packages/samba/provision/__init__.py #500: NetBIOS Domain: EXAMPLE
INFO 2025-02-24 14:04:05,183 pid:3170 /usr/lib/python3/dist-packages/samba/provision/__init__.py #501: DNS Domain: example.com
INFO 2025-02-24 14:04:05,183 pid:3170 /usr/lib/python3/dist-packages/samba/provision/__init__.py #502: DOMAIN SID: S-1-5-21-1227575069-1623886296-1303063441
ちなみに–use-rfc2307というオプションは、RFC 2307に従い、LDAP（ドメイン）のスキーマを拡張し、UIDやGID、ホームディレクトリやログインシェルなどのPOSIXの属性を保管させるという設定です（このあたりのユーザー属性の設定については、今後の回で触れる予定です）。あとから拡張しようとすると手動操作が必要で面倒、かつ、指定しておいても特にデメリットもないため、ドメイン作成時に設定しておきます。
ここで生成されたsmb.confの設定値を確認してみます。
samba-ad-dc01$ cat /etc/samba/smb.conf
# Global parameters
[global]
dns forwarder = 192.168.1.1
netbios name = SAMBA-AD-DC01
realm = EXAMPLE.COM
server role = active directory domain controller
workgroup = EXAMPLE
idmap_ldb:use rfc2307 = yes
[sysvol]
path = /var/lib/samba/sysvol
read only = No
[netlogon]
path = /var/lib/samba/sysvol/example.com/scripts
read only = No
ちなみに、上ではインタラクティブにドメインを展開しましたが、オプションを使ってDNSフォワーダーを除く各値を引き渡すことも可能です[12]。
samba-ad-dc01$ sudo samba-tool domain provision –domain example –realm example.com –adminpass –server-role dc –use-rfc2307 –dns-backend SAMBA_INTERNAL
ただし、DNSフォワーダーを指定するオプションはないので、ここだけはあとからsmb.confを編集します。
[12] なお、Administratorユーザーのパスワードをヒストリに残すことに抵抗がある場合は、–adminpassオプションを省略できます。その場合、ランダムなパスワードが生成され、ログの中に”Admin password”としてパスワードが表示されます。その内容をメモにとっておき、あとからお好みのパスワードに変更するという流れになります。
Samba AD DCの設定が完了したら、DNS周りの設定をおこないます。今回、Samba AD DC自身にDNSサーバーの機能を持たせたので、ドメインのメンバーサーバー等からの名前解決リクエストをTCP/UDP 53で受け付ける必要があります。一方、デフォルトで動作しているsystemd-resolvdもTCP/UDP 53でリスンしています。このままだとポートが競合してエラーになるので、先ほど触れた通り、systemd-resolvdを停止・無効化します。
samba-ad-dc01$ sudo unlink /etc/resolv.conf
samba-ad-dc01$ cat
> nameserver 127.0.0.1
> search example.com
> EOF
samba-ad-dc01$ sudo systemctl disable systemd-resolved –now
また、（ドメイン作成時のログメッセージ（抜粋1行目）にもあるように）Kerberos認証の設定ファイルをsamba-toolが生成したファイルで置き換えます。
samba-ad-dc01$ sudo cp -f /var/lib/samba/private/krb5.conf /etc/krb5.conf
これで準備が整ったのでいよいよサービスを有効化・起動させます。
samba-ad-dc01$ sudo systemctl enable samba-ad-dc –now
ここで動作確認をしておきましょう。
まずは、ADユーザーでの認証が成功するかをkinitでADユーザーとして認証してKerberosチケットを受け取り、klistで受け取ったチケットを確認してみます。次のような表示になっていればAdministratorユーザー（プリンシパル）としてKerberosチケットを取得できおり、問題なく動作しています。
amba-ad-dc01:~$ kinit Administrator
Password for Administrator@EXAMPLE.COM:
Warning: Your password will expire in 41 days on Mon 07 Apr 2025 02:04:04 PM UTC
samba-ad-dc01:~$ klist
Ticket cache: FILE:/tmp/krb5cc_1000
Default principal: Administrator@EXAMPLE.COM
Valid starting Expires Service principal
02/24/2025 14:06:55 02/25/2025 00:06:55 krbtgt/EXAMPLE.COM@EXAMPLE.COM
renew until 02/25/2025 14:06:52
また、ADはDNSに依存するため、名前解決機能の動作状況を確認しておきます。SRVレコードを引いて確認してみます。
samba-ad-dc01$ for srv in _ldap._tcp _kerberos._tcp _kerberos._udp _kpasswd._udp; do echo -n “${srv}.example.com: “; dig @localhost +short -t SRV ${srv}.example.com; done
_ldap._tcp.example.com: 0 100 389 samba-ad-dc01.example.com.
_kerberos._tcp.example.com: 0 100 88 samba-ad-dc01.example.com.
_kerberos._udp.example.com: 0 100 88 samba-ad-dc01.example.com.
_kpasswd._udp.example.com: 0 100 464 samba-ad-dc01.example.com.
確認したレコードの詳細（お約束）を知りたい場合はSRV Records Registered by Net Logonを確認してください。
ドメイン参加
最終的にはDC2台構成を目指していますが、1台構築した時点でSamba ADドメインは利用できる状態になっています。そのため、ここでWindowsマシンをSamba ADドメインに参加させて、動作を確かめてみます。なお、ドメインに参加できるのはクライアント版WindowsだとProエディション以上です。
繰り返しになりますが、ドメインに参加するには、DNSでドメインの名前解決ができなければなりません。そのため、ネットワークアダプターの設定を変更し、今回構築した1台目のSamba AD DCを参照先のDNSサーバーとします。
図1 DNS設定の変更例（Windows 11）
準備が整ったらドメインに参加します。スタートボタンを右クリックし、「システム」を開くと「設定」ウィンドウが開きます。「システムの詳細設定」という項目をクリックすると「システムのプロパティ」が開くため、「コンピューター名」タブを選択します。すると、「変更」というボタンがあるため、これをクリックします。ドメイン名を入力するところがあるため、example.comと入力し、OKをクリックします[13]。
図2 ドメイン名変更画面（Windows 11）
[13] Windows 11の場合、他にもドメインへの参加方法があるようですが、（一応まだサポート期間が残っている）Windows 10でも共通して使えるこの手順を紹介しました。なお、コンピューター名を変えたい場合はここで適宜変えてください。
コンピューターをドメインに参加するための権限のあるADユーザーの認証情報を求められるため、Administratorユーザーの認証情報を入力します。「example.com ドメインへようこそ。」というメッセージボックスが出たら、ドメインに無事に参加できています。そして、指示通りにOSを再起動します。
再起動が完了したら、改めてログインしますが、今度はADユーザーであるAdministratorユーザーとしてログインしてみます。「他のユーザー」を選択し、ユーザー名にAdministrator@example.comまたはexample.com\Administratorと入力して、パスワードを入力します。
ADの管理ツールはクライアント向けWindowsでもオプション機能として導入できます[14]。先程同じ手順で「設定」ウィンドウの「システム」を開き「オプション機能」に移ります。Windows 11の場合は「オプション機能を追加する」横の「機能を表示」、Windows 10の場合は「機能の追加」をクリックします。検索ボックスに「RSAT[15]」と入力するとWindows Serverのリモート管理用ツールが抽出されますので次の2つにチェックを入れます。
「RSAT: Active Directory Domain Services およびライトウェイト ディレクトリ サービス ツール」
「RSAT: グループ ポリシー管理ツール」
図3 RSATの追加画面
[14] もし（評価版などを入手して）Windows Serverをドメインに参加させた場合は、「サーバー マネージャー」から「機能と役割の追加」を選択し、（ツリーを辿って）次の機能にチェックを入れます：「グループ ポリシー管理ツール」および「リモート サーバー管理ツール」-「役割管理ツール」-「AD DS および AD LDS ツール」
[15] RSATは”Remote Server Administration Tools”の略です。RSATの詳細はこちらから確認できます。
ツールがインストールできたら、スタートメニューから「Active Directory ユーザーとコンピューター」を開きます。すると、左側のツリーに今回構成したSamba ADドメインexample.comと表示されているはずです。そのツリーを開いたDomain ControllersフォルダにはSAMBA-AD-DC01というドメインコントローラーが、Computersフォルダにはドメインに参加させたコンピューターが見えるでしょう。
図4 「Active Directory ユーザーとコンピューター」でドメインコントローラーを表示した状態
Samba AD DCであっても、このようにADDSの管理用ツールでドメインやドメイン上のオブジェクトの情報を表示させることができます。ADDS互換を目指しているだけのことはあります。
Ubuntuマシンのドメイン参加手順については第837回で解説済みのため、本稿では割愛します。こちらの記事を参照してください。ただし、Samba ADドメイン参加した直後のUbuntuマシンではADユーザーでログインできない場合があることを確認しています。一度システムを再起動することで、手元の環境では改善できたので、同じ状況に陥った場合はシステムの再起動を試してください。
今回の作業でひとまずDC1台構成のSamba ADが構築できました。次回は以下について解説します。
2台目のDCの構築
グループポリシーオブジェクト（GPO）をより適切に取り扱うためのSYSVOLフォルダの構成
WACOCA: People, Life, Style.