Ubuntu Weekly Recipe

第852回Sambaで作るActive Directory互換環境
(1)その特性と1台目のドメインコントローラーの構築

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が全滅するといった事態を回避できるという可能性も考えられます。

また、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]

加えて、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

これらの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:

入力項目を順に解説します。

いきなり"Realm"や"Domain"と似たようなことを聞かれて(あるいは、何を聞かれているのかがわからず)困惑するかもしれません。ADにおけるドメイン名(とコンピューター名)にはNetBIOSドメイン名とDNSドメイン名があり、ここではこの2つのドメイン名をそれぞれ聞かれています[8]

"Realm"はDNSドメイン名を聞かれているため、今回の場合はexample.comと入力します。ADDSでドメインを作成する際の「Active Directory ドメイン サービス構成ウィザード」との対応でいうと、最初に入力するドメイン名に対応します。

他方、"Domain"はNetBIOSのドメイン名を入力する項目です。他のドメインと重複しない限りは、DNSドメインをドットで区切った一番左の部分(今回の場合はexampleの値を採用することが一般的です。プロンプトに[example]となっているようにデフォルト値もそうなっており、今回はそのままEnterを押して確定します。同じく、ADDSの構成ウィザードとの対応でいうと、追加オプションで聞かれるNetBIOSドメイン名に対応します。

"Server Role"はデフォルトのdcとなっていますので、空欄のままEnterを押してこのマシンをDCとしてドメインをデプロイするようにします。

"DNS backend"ではDCの持つDNS機能を提供するバックエンドの選択を選択します。デフォルトではSambaにビルトインされたDNSサーバー機能SAMBA_INTERNALが使用されますが、BIND[9]も選択できます。今回はデフォルトのSAMBA_INTERNALで進めるため、そのままEnterを押して確定します。

"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に)値を変更しておきます。

"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 <Administratorユーザーのパスワード> --server-role dc --use-rfc2307 --dns-backend SAMBA_INTERNAL

ただし、DNSフォワーダーを指定するオプションはないので、ここだけはあとからsmb.confを編集します。

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 << EOF | sudo tee /etc/resolv.conf
> 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 [email protected]:
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: [email protected]

Valid starting       Expires              Service principal
02/24/2025 14:06:55  02/25/2025 00:06:55  krbtgt/[email protected]
        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)

コンピューターをドメインに参加するための権限のある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の追加画面

ツールがインストールできたら、スタートメニューから「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フォルダの構成

おすすめ記事

記事・ニュース一覧