第852回でSambaを使いドメインを作成した際に--use-rfc2307というオプションを指定しました。これはドメインの属性を拡張し、UIDやGID、ホームディレクトリやログインシェルなどのPOSIXの属性を保管させるという設定であることは簡単に解説しました。

この仕様（RFC 2307）自体はSambaのActive Directory（AD）互換に固有の話ではありません。しかし、--use-rfc2307オプションはドメインコントローラー（DC）を最初に作成したときに指定したものであり、かつ、ドメインに参加するUbuntuマシンには関係のあるトピックです。そのため、今回はRFC 2307に基づくスキーマ拡張で追加したUNIX属性について、実際の挙動や利用方法を紹介します。

ADユーザーの作成とデフォルト状態の確認

まず、Ubuntuマシンを用意し、ドメインの名前解決ができるようにDNSの設定をおこない、ADに参加します[1]。

member$ sudo apt -y install sssd-ad sssd-tools realmd adcli
member$ sudo realm join -v example.com
member$ sudo pam-auth-update --enable mkhomedir

続いて、ドメインに参加したWindowsマシンで「Active Directory ユーザーとコンピューター」を使い、ubuntuというADユーザーを追加します。

この時点で、作成したばかりのADユーザーのホームディレクトリやログインシェルがADに参加させたUbuntuマシンでどのように設定されるかを確認します。次のようにgetentコマンドを実行することで/etc/passwdと同じ形式でエントリを確認できます。

member$ getent passwd ubuntu@example.com
ubuntu@example.com:*:1289001115:1289000513:ubuntu:/home/ubuntu@example.com:/bin/bash

上の結果からは、このADユーザーはホームディレクトリが/home/ubuntu@example.com、ログインシェルが/bin/bashであることがわかります。

ADユーザーなので、/etc/passwdにubuntu@example.comユーザーのエントリがあるわけではなく、AD統合にデフォルトで使用されるSystem Security Services Daemon（以下、SSSD）[2]がその設定ファイル/etc/sssd/sssd.confの内容に基づいて生成しています。

member$ sudo cat /etc/sssd/sssd.conf

[sssd]
domains = example.com
config_file_version = 2
services = nss, pam

[domain/example.com]
default_shell = /bin/bash
..
fallback_homedir = /home/%u@%d
ad_domain = example.com
...
ldap_id_mapping = True
access_provider = ad

今回着目しているホームディレクトリとログインシェルのデフォルト値（フォールバック値）は抜粋部分にあるfallback_homedir = /home/%u@%dとdefault_shell = /bin/bashがそれぞれ該当します。

ADユーザーのログインシェルとホームディレクトリの設定

何も指定していないときの挙動がわかったところで、ADユーザーubuntuのホームディレクトリとログインシェルを指定します。

Windowsから指定する場合は、適切なADユーザーで「Active Directory ユーザーとコンピューター」を開きます。そして、「⁠表示」から「拡張機能」をクリックしチェックを入れます。この状態で、「⁠Users」から設定対象のADユーザーのプロパティを開くと、「⁠属性エディター」というタブが追加されるようになります。このタブを開くと属性がズラッと一覧されるため、unixHomeDirectoryやloginShellに値を指定することで、ホームディレクトリやログインシェルが指定できます。

Samba AD（Ubuntu）側で操作するのであれば、samba-tool user addunixattrsコマンドを使用します。

samba-ad-dc01$ sudo samba-tool user addunixattrs ubuntu 1000 --gid-number=1000 --unix-home='/home/ubuntu' --login-shell='/bin/dash'
Modified User 'ubuntu' successfully

なお、ubuntu 1000はubuntuユーザーにUID 1000を与えるという意味になりますが、samba-toolはADユーザー間でこのUIDの重複を許さないという動きをします。その一方で、後述するように、SSSDのデフォルト設定ではADユーザーのUID/GIDは使用されません。つまり、実際に使われない場合でも「UID/GIDの指定が必須、しかも重複は許されない」というちょっと面倒なことになります。よって、事後にsamba-tool user editコマンドでuidNumber属性とgidNumber属性を削ってしまってもいいかもしれません[3]。

samba-ad-dc01$ sudo samba-tool user edit ubuntu --editor=vim

あるいは、ユーザー作成時にホームディレクトリとログインシェルを設定してしまうということもできます。ユーザーを作成するときにホームディレクトリとログインシェルを指定するのであればUID/GIDを指定する必要はありません。

samba-ad-dc01$ samba-tool user create ubuntu --unix-home='/home/ubuntu' --login-shell='/bin/dash'

いずれの方法を採るにせよ、unixHomeDirectory属性やloginShell属性が設定されると、getentコマンドの結果が次のように変化します。

member$ getent passwd ubuntu@example.com
ubuntu@example.com:*:1289001116:1289000513:ubuntu:/home/ubuntu:/bin/dash

ホームディレクトリが/home/ubuntuに、ログインシェルが/bin/dashになることがわかります。getentコマンドの結果だけでは物足りないという方もいるかもしれないので、実際にログインもしてみます。

member$ sudo login
member login: ubuntu@example.com
パスワード:
...

$ id
uid=1289001116(ubuntu@example.com) gid=1289000513(domain users@example.com) groups=1289000513(domain users@example.com)
$ env |grep -e HOME -e SHELL
HOME=/home/ubuntu
SHELL=/bin/dash

ADユーザーのUID/GID

先ほど軽く触れましたが、SSSDを使ってUbuntuマシンをドメインに統合する場合、UID/GIDについてはデフォルトでは使用されず、SSSDが自動生成した値が使用されます。

そもそもUID/GIDの指定が必要とされるのは、ドメインに参加する複数のUbuntuマシン間でADユーザーに同じUID/GIDを使用させるためです。例えば、複数のマシンから共通のNFSファイルシステムにアクセスする環境で、ファイルの所有者やパーミッションを一貫させる必要があるといった場面が挙げられるでしょう。

この目的に対し、「⁠中央集権」的にUID/GIDを指定しておき、それをクライアントマシンに使わせれば、すべてのUbuntu（を含むLinuxマシン）で同じUID/GIDを使用させることができます。これがドメイン側でADユーザーの属性情報としてUID/GIDを格納し、クライアントのLinuxマシンはこの属性値を読み取って適用するというアプローチです。

しかし、この「中央集権」的な方法だと、LinuxマシンにアクセスしうるすべてのADユーザーにUID/GIDを指定する（特にUIDは一意となるよう重複させない）必要が出てきます。また、各LinuxマシンにローカルなUID/GIDとの衝突回避といったことも考慮に入れなければならない可能性もあり、設定・管理にそれなりの手間と時間とが必要となります。

他方、先ほど見たようにsssd.confのデフォルト値ではldap_id_mapping = Trueと指定されています。この場合、ADユーザーに関するSID（セキュリティ識別子；Windows OSにおけるユーザーやグループの識別ID）から特定のアルゴリズムに基づいてUID/GIDが計算、割り当てられます。SSSDの設定が揃っていれば、どのUbuntuマシンでも計算結果が同じとなり、マシン間でUID/GIDが揃うことが（多くの場面で）期待されます。このように各マシンで「分権」的にUID/GIDを生成して間に合うのであれば、「⁠すべてのADユーザーにUID/GIDを割り当てて回る」ことを避けられるというメリットがあります。

ただし、この「分権」的な方法も完璧ではありません。この方法ではIDの生成の際にドメインごとに利用するIDのレンジ（⁠「⁠スライス⁠」⁠）を選定します。しかし、すでに使われているレンジとハッシュが衝突すると別のレンジを選定しようとしますが、そのときにマシン間で割り当てられるUID/GIDのスライスがずれる可能性があるようです。このような場合にはldap_id_mapping = Falseとして「中央集権」的にADユーザーにUID/GIDを設定するという方法が解決策の1つとなります[4]。

4回にわたってお送りしてきた「Sambaで作るActive Directory互換環境」は今回が最終回となります。取り上げられていないトピックは多々ありますが、「⁠UbuntuでSamba ADを使い始めるには」という観点でまとめました。一連の記事が「ご家庭AD環境」を構築される際の参考となれば幸いです。