Samba の SID と認証設計 – LDAP、UID/GID、SMB 認証の責務を分ける

Samba を単なるファイル共有として使うだけなら、SID を強く意識する場面は多くありません。

しかし、OpenLDAP などの LDAP 基盤と連携し、Unix / Linux 側の UID / GID と SMB 側の認証を同時に扱い始めると、Samba の SID が急に重要になります。

ここで混乱しやすいのは、LDAP にユーザーがあること、Unix ユーザーとして見えること、Samba ユーザーとして認証できること、ファイル権限が期待通りに効くことが、すべて別の話だという点です。

この記事では、Active Directory を使わず、OpenLDAP を中心にしながら Samba のファイル共有を運用する場合に、SID、UID / GID、passdb、認証、認可をどう分けて考えるかを整理します。

SID は Windows / SMB 側の識別子である

SID (Security Identifier) は、Windows 系の認証・認可でユーザーやグループなどのセキュリティ主体を識別するための ID です。表示名やユーザー名が変わっても、アクセス権の判断では SID が重要になります。

Samba は Linux / Unix 上で SMB 共有を提供しますが、Windows クライアントから見ると Windows 的なアカウント情報を扱う必要があります。そのため Samba 側にも、ユーザーやグループを SID と結び付ける仕組みがあります。

Samba は、これらの対応関係を解決しながらアクセス権を判断します。したがって、SID を無視すると、SMB 共有としての認証や権限の話が抜け落ちます。

LDAP にユーザーがあるだけでは Samba ユーザーとは限らない

LDAP は、ユーザーやグループの属性を保持するディレクトリです。LDAP を中心にすれば、Unix / Linux 側のアカウント情報や認証情報を集約できます。

しかし、LDAP に POSIX ユーザーが存在することと、Samba の SMB 認証で使えることは同じではありません。Samba は、SMB 認証で使うパスワードハッシュや SID との対応を必要とします。

ここを混ぜると、「LDAP にはユーザーがあるのに Samba でログインできない」「Linux では見えるのに SMB 共有では権限が合わない」という状態になります。

LDAP はユーザー情報の中心にできます。ただし、Samba 固有の認証情報や SID の世界まで自動的に消えるわけではありません。

認証と認可を分ける

Samba のトラブルでは、「ログインできるか」と「ファイルにアクセスできるか」を分けて見る必要があります。

SMB 認証に成功しても、Unix 側のファイル権限や Samba の共有設定が合っていなければアクセスできません。逆に、Unix 側でファイル権限があっても、Samba ユーザーとして認証できなければ SMB 経由では使えません。

passdb と Samba ユーザー

Samba のユーザー情報は passdb という考え方で管理されます。バックエンドには tdbsam や ldapsam などがあり、LDAP を使う場合でも Samba としてのユーザー管理は passdb の文脈で考える必要があります。

つまり、LDAP 側に POSIX ユーザーがある、Samba 側で SMB 認証できる、Unix の UID / GID と Windows 的な SID が対応している、という三つは同じではありません。

net getlocalsid
pdbedit -L
pdbedit -Lv ユーザー名

上記のようなコマンドで、Samba が持っているローカル SID や Samba ユーザー情報を確認できます。Samba の認証トラブルでは、LDAP にユーザーがあるかだけでなく、Samba のユーザーとして見えているかを確認する必要があります。

Active Directory を使わない場合の前提

この話は、Samba を Active Directory ドメインコントローラーとして使う構成ではありません。AD を導入すれば、SID、ドメイン、認証、端末参加などを一つの世界として扱えます。

ここで扱っているのは、Windows ドメインを作りたいわけではなく、LDAP を中心にした Unix 系の認証基盤に、Samba のファイル共有を接続したいという構成です。

この構成では、LDAP を中心にしたいという意図と、Samba が必要とする SID / passdb / SMB 認証の世界が重なります。その境界を曖昧にしないことが重要です。

SID を揃えるという設計

複数の Samba を扱う場合、ファイルサーバーごとに別の SID 世界を作ると、管理が分かりにくくなります。

元の設計で考えていたのは、LDAP サーバー側でも Samba を稼働させ、その Samba を認証操作用として扱い、ファイルサーバー側の Samba と SID を揃えるという構成です。

LDAP サーバーを認証の中心に置きつつ、Samba のパスワード変更や Samba アカウント操作を LDAP サーバー側に寄せる。ファイルサーバーとしての Samba と、認証操作を受ける Samba が別ホストでも、同じ SID の世界として扱う。そうすることで、管理上の違和感を減らせます。

SID を明示的に設定する

認証用 Samba とファイルサーバー側 Samba を同じ SID の世界として扱いたい場合は、基準にする Samba のローカル SID を確認し、もう一方の Samba に明示的に設定します。

net getlocalsid

net setlocalsid S-1-5-21-1111111111-2222222222-3333333333

net getlocalsid

ここで重要なのは、SID を新しく作ることではありません。どちらの Samba を基準にするかを決め、その SID に揃えることです。

ファイルサーバー側ですでにアクセス権を運用している場合は、既存の SID、passdb、LDAP 上の Samba 属性を確認してから作業する必要があります。SID を変更すると、Samba がユーザーやグループをどの Windows 的な識別子として扱うかに影響します。

運用中のサーバーで実行する場合は、現在の SID、passdb、LDAP 上の Samba 属性、関連設定をバックアップしてから行うべき操作です。

この構成で守りたいこと

• LDAP をユーザー情報の中心にする
• Samba 固有のパスワード情報や SID を無視しない
• ファイルサーバーごとに別の SID 世界を作らない
• パスワード変更の操作場所を利用者にとって自然な位置に寄せる
• ログインできることとファイル権限が効くことを分けて確認する

注意点

SID を揃える設計は便利ですが、雑に複製すると危険です。Samba のローカル SID、passdb、LDAP 上の Samba 属性、Unix 側の UID / GID、ファイルシステム上の所有者と ACL は、それぞれ別の情報です。

特に、すでに運用中の Samba で SID を変更すると、既存のアクセス権やクライアント側の認識に影響する可能性があります。検証環境で確認し、バックアップを取った上で、どちらの SID を正とするのかを決めてから行うべきです。

また、Samba と LDAP の連携方式はバージョンや構成によって前提が変わります。現在の Samba では Active Directory ドメインコントローラーとして構成する選択肢もありますが、この記事では OpenLDAP を中心にしたファイル共有用途の整理として扱っています。

まとめ

Samba の SID と認証を考える時は、LDAP、UID / GID、SID、passdb、認証、認可を分けて見る必要があります。

LDAP にユーザーがあること、Unix ユーザーとして見えること、Samba ユーザーとして認証できること、SMB 共有でファイル権限が期待通りに効くことは同じではありません。

Samba は、Windows 的な SID の世界と Unix 的な UID / GID の世界をつなぐ位置にあります。だからこそ、どの情報を LDAP に持たせ、どの情報を Samba が扱い、どこでアクセス権を判断するのかを分けて設計する必要があります。

ログインできることと、ファイルにアクセスできることは別です。この違いを潰さないことが、Samba と LDAP 連携を安定して運用するための前提になります。

関連記事

障害切り分けとは何か – 影響範囲から構造を読む NTP トラブル時に確認すること – chrony、ntpd、timesyncd の整理 設計書に残すべきは項目ではなく判断である – 粒度、理由、実体をつなぐ文書設計 自動化は業務ロジックと責任分界を透明にする – 効率化の前に構造を定義する クラウドという言葉の本質 – 場所ではなく運用モデルと責任分界で考える SNMP Trap は監視設計の主役ではない – Polling、状態監視、イベント通知を分けて考える TFTP の仕組みとファイアウォール設計 – UDP、動的ポート、PXE Boot を分けて考える Dovecot で INBOX が空に見える時の復旧手順 – Maildir と Index の再同期