Samba の SID と認証の整理

Samba を単なるファイル共有として使うだけなら、SID を強く意識する場面は多くありません。しかし、LDAP と連携してユーザー情報を管理し始めると、Samba の SID と認証情報をどこで管理するのかが急に重要になります。

この記事は、Active Directory を使わず、OpenLDAP を認証基盤として使いながら Samba を運用する場合に、何がややこしくなるのかを整理したメモです。

SID とは何か

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

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

ユーザー名は人間が読むための名前
UID / GID は Unix 側の識別子
SID は Windows / SMB 側の識別子
Samba はこれらの対応関係を解決しながらアクセス権を判断する

LDAP と Samba で認証の主体がずれる

私の環境では、ユーザー情報の中心は LDAP です。Samba も LDAP と連携しており、ユーザーやパスワードの情報を LDAP 側に寄せています。

ここで違和感が出るのは、LDAP サーバーを認証データの主体にしたいにもかかわらず、Samba のパスワード変更や Samba アカウントの操作は Samba 側の文脈で行う必要がある点です。

特に Samba は、単なる POSIX アカウントだけではなく、SMB 認証で使うパスワードハッシュや SID との対応を持ちます。そのため、LDAP にユーザーが存在するだけでは Samba ユーザーとして十分ではない場合があります。

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

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

自分の環境では、Windows ドメインを作りたいわけではなく、LDAP を中心にした Unix 系の認証基盤に、Samba のファイル共有を接続したいという位置付けです。だからこそ、Samba 特有の SID と LDAP 側の認証情報の境界が気になります。

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 のユーザーとして見えているかを確認する必要があります。

SID を揃えるという発想

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

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

SID を明示的に設定する

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

# 基準にする Samba で SID を確認する
net getlocalsid

# 表示例
# SID for domain SAMBA-AUTH is: S-1-5-21-1111111111-2222222222-3333333333

# もう一方の Samba で同じ SID を設定する
net setlocalsid S-1-5-21-1111111111-2222222222-3333333333

# 設定後に確認する
net getlocalsid

ここで重要なのは、SID を「新しく作る」のではなく、どちらを基準にするかを決めてから、同じ SID に揃えることです。ファイルサーバー側ですでにアクセス権を運用している場合は、既存の SID と passdb の状態を確認してから作業する必要があります。

SID を変更すると、Samba がユーザーやグループをどの Windows 的な識別子として扱うかに影響します。運用中のサーバーで実行する場合は、現在の SID、passdb、LDAP 上の Samba 属性をバックアップしてから行うべき操作です。

この構成で守りたいこと

LDAP をユーザー情報の中心にする
Samba 固有のパスワード情報や SID を無視しない
ファイルサーバーごとに別の SID 世界を作らない
パスワード変更の操作場所を利用者にとって自然な位置に寄せる

注意点

SID を揃える設計は便利ですが、雑に複製するとかえって危険です。Samba のローカル SID、passdb、LDAP 上の Samba 属性、Unix 側の UID / GID の対応関係を理解せずに移行すると、アクセス権が期待通りに解決できなくなる可能性があります。

また、複数の Samba サーバーを同じ認証基盤に接続する場合は、どのサーバーでユーザー追加やパスワード変更を受け付けるのかを明確にした方がよいです。運用操作の入口が複数になると、あとから原因調査が難しくなります。

まとめ

Samba と LDAP を組み合わせる時に難しいのは、LDAP が認証の主体であるように見えても、Samba には Samba の認証情報と SID の世界があることです。

Active Directory を使わない構成では、LDAP、Unix アカウント、Samba passdb、SID の関係を自分で整理する必要があります。この記事の要点は、Samba をファイル共有のサービスとしてだけでなく、SMB 認証のための独立したレイヤーとして見ることです。

その視点を持つと、LDAP サーバー側に認証操作用の Samba を置き、ファイルサーバー側の Samba と SID を揃えるという設計の意味が見えてきます。

参考
書籍

参考書籍

Samba逆引きリファレンス Samba 3.4対応

Samba のファイルサーバー機能、認証、ドメイン、LDAP 連携を確認したい場合の参考書籍です。価格や在庫はリンク先で確認してください。

Amazon で見る

このリンクは Amazon アソシエイトリンクです。

参考