Chapter 11. Account Information Databases

Jelmer R. Vernooij

The Samba Team

John H. Terpstra

Samba Team

Gerald (Jerry) Carter

Samba Team

Jeremy Allison

Samba Team

Guenther Deschner

LDAP updates

Olivier (lem) Lemaire

May 24, 2003

Table of Contents

特長と便益
下位互換性のあるバックエンド
新しいバックエンド
技術情報
セキュリティに関する重要な注意事項
MS Windows と UNIX の間の、ユーザー識別子のマッピング
分散されたマシン上の共通 UID や GID のマッピング
アカウント管理ツール
smbpasswd コマンド
The pdbedit コマンド
パスワード・バックエンド
プレーンテキスト
smbpasswd 暗号化パスワード・データベース
tdbsam
ldapsam
MySQL
XML
よくあるエラー
ユーザーがログオンできない
ユーザーが誤ったバックエンド・データベースに追加される
auth methods の設定

Samba-3 では、複数のアカウント・バックエンドを同時に稼動できるという新しい 機能を実現しました。新たに可能になったパスワード・バックエンドの各種の 組み合わせにより、過去には MS Windows Active Directory でのみ可能だったような 柔軟性と拡張性を達成できるようになりました。この章は新機能と、その最大活用法を 説明します。

特長と便益

Samba-3 は Samba-2.2.x の以下の機能について完全な下位互換性を提供します:

下位互換性のあるバックエンド

プレーンテキスト

このオプションは、UNIX/Linux の /etc/passwd 式のバックエンド以外は 使用しません。Pluggable Authentication Modules (PAM) サポートのあるシステム上では、 全てのPAMモジュールがサポートされます。動作は、Samba-2.2.x の場合と全く同様で、MS Windows クライアントにより課されるプロトコルの制約も同様に適用されます。プレーンテキストの パスワードの使用に係る制約に関する詳細情報は、技術情報の項 を参照ください。

smbpasswd

このオプションは、MS Windows LanMan と NT の暗号化パスワード及び一部のアカウント情報を 格納するフィールドを含むプレーン ASCII (テキスト) レイアウトを維持する smbpasswd ファイルの継続的使用を可能にします。 この種のパスワード・バックエンドは、MS Windows NT4/200x サーバーと包括的な相互運用を 行うために必要な拡張コントロールを提供するための、MS Windows NT/200x SAM (Security Account Manager) 情報を一切格納しません。

このバックエンドは、Samba のより古いバージョンとの下位互換性のためにのみ使用するべきです。 将来のリリースでは、切り捨てられていくかもしれません。

ldapsam_compat (Samba-2.2 LDAP 互換性)

Samba-2.2.x LDAP スキーマを使用し、既存の OpenLDAP バックエンドとの継続的運用を可能にする パスワード・バックエンドのオプションがあります。このオプションは、現時点で移行を強制する 理由はないのですが、主に移行ツールとして提供されています。 このツールは最終的には切り捨てられることになります。

Samba-3 には多数の新しいパスワード・バックエンド機能が導入されました。

新しいバックエンド

tdbsam

このバックエンドは、ローカル・サーバーに、リッチなデータベース・バックエンドを 提供します。このバックエンドは、複数のドメイン・コントローラー(つまり、PDC + 一つ以上の BDC)をインストールしている場合には適しません。

tdbsam パスワード・バックエンドは、旧 smbpasswd 情報の他、拡張されたMS Windows NT / 200x SAM 情報をバイナリ形式の TDB (トリビアル・データベース) ファイルに格納します。拡張情報を含むことで、 Samba-3 が、MS Windows NT4/200x ベースのシステムと同様のアカウント・アクセス及び システム・アクセス制御を実現することを可能にします。

tdbsam 機能を入れたのは、OpenLDAP を稼動させることに伴う 複雑性とその間接費用を発生させずにシンプルなサイト運用を可能にしたいという ユーザーからのリクエストに直接応えるためです。このオプションは、ユーザー数 250 未満のサイトにのみ推奨します。これより大規模のサイト、または実装では、OpenLDAP の使用または Active Directory の統合を強く推奨します。

ldapsam

これは、アカウント分散して導入されている場合に、リッチなディレクトリ・バックエンドを 提供します。

Samba-3 では、LDAP 用拡張の実装が新しくなり、これにより新しい形式の Samba スキーマを 持つ OpenLDAP の設定を必要とします。新しい形式のスキーマ・ファイルは、Samba ディストリビューションの examples/LDAP のディレクトリに入っています。

新しい LDAP の実装は、Samba の過去のバージョンで可能だったコントロール能力を著しく 向上するものです。このバージョンでは、“ユーザーごとの” プロファイル設定、 ホーム・ディレクトリ、アカウント・アクセス制御、その他多くの設定が可能でになりました。 企業サイトでは、機能性と拡張性の向上のリクエストに、Samba チームがしっかり耳を傾けたと いうことを見ていただけるでしょう。

mysqlsam (MySQL ベースのバックエンド)

特定の分野では MySQL ベースの SAM が人気を博すであろうと予想しています。このデータベース・ バックエンドは、既存のMySQL技術を最大活用したいサイトにとって、大変関心の高いものに なるでしょう。

xmlsam (XML ベースのデータファイル)

これは、アカウントとパスワードのデータを XML 形式のデータファイルに格納することを 可能にします。このバックエンドは、通常の運用には使用できません。これは pdbedit の pdb2pdb 機能と組み合わせての使用しかできません。使用される DTD は将来変更される 可能性があります。

xmlsam のオプションは、データベース・バックエンド間あるいは バックアップ間のアカウントの移行に便利でしょう。このツールを使用すれば、移行先バックエンドの 形式に移行する前に、データを編集することが可能です。

技術情報

旧 Windows クライアントは、プレーンテキストのパスワードを送信します。Samba はこれらのパスワードを 暗号化し、UNIX ユーザー・データベースに格納されているハッシュと比較することにより、確認することが できます。

より新しい Windows クライアントはプレーンテキストのパスワードのかわりに、暗号化されたパスワード (Lanman及びNTハッシュと呼ばれるもの) を送信します。最新のクライアントは、暗号化されたパスワード のみを送信し、クライアントのレジストリが改変されていない限り、プレーンテキストのパスワードを 送信することを拒否します。

これらのパスワードは UNIX 式の暗号化パスワードに変換することができません。そのため、標準的な UNIX ユーザー・データベースを使用することはできず、Lanman ハッシュと NT ハッシュは別の所に格納しなければ なりません。

パスワードの暗号化の仕方が異なるのみならず、Windows は UNIX ユーザー・データベースには格納されない ような各ユーザーに関する特定のデータを格納します。例えば、ユーザーがログインする可能性のある ワークステーション、ユーザーのプロファイルが格納されている場所、等々です。Samba は passdb backend を使用してこの情報を取り出し、格納します。 通常、使用できるバックエンドは、LDAP、プレーンテキストファイル、及び MySQL です。 passdb backend のパラメーターに関する詳細は、 smb.conf の man ページを参照ください。

Figure 11.1. IDMAP: SID の UID への解決

IDMAP: SID の UID への解決

SID の UID への解決は、Samba の適正運用の根幹を成します。以下の両例で、winbindd が稼動していないか、 あるいは、コンタクトが取れない状況のとき、ローカルの SID/UID 解決のみが可能です。 SID の UID への解決 及び UID の SID への解決 の図を参照ください。

Figure 11.2. IDMAP:UID の SID への解決

IDMAP:UID の SID への解決

セキュリティに関する重要な注意事項

UNIX と SMB のパスワード暗号化のテクニックは、一見、類似しているように見えます。 しかし、この類似性は、皮一枚だけの表面的なものです。UNIX のスキームでは、通常、 ログインの際に、クリアテキスト・パスワードをネットワークを通して送信します。 これは、まずいです。SMB の暗号化スキームは、ネットワークを通してクリアテキスト・ パスワードを送信することは絶対にありませんが、ディスク上に 16 バイトのハッシュ値を 格納します。これもまずいです。なぜでしょうか。それは、16 バイトのハッシュ値は、 “パスワードと同等” だからです。ユーザーのパスワードをハッシュ値から 導き出すことはできませんが、クライアントに手を加えれば、サーバーにアクセスする ために使える可能性があるのです。これは、侵入者の側にかなりの技術的知識があることを 前提としていますが、それでも、可能であることは確かです。従って、(smbpasswd ファイル、 LDAP、MySQLの) いずれのバスワード・データベース・バックエンドを使用していても、 そこに格納されたデータが、全ユーザーのクリアテキストのパスワードを持っているかのように、 慎重に取り扱わなければならないのです。これらのデータベースの内容は極秘とし、 ファイルは、適切に保護されていなければなりません。

理想的には、ネットワーク上でもディスク上でもプレーンテキストのパスワードを持ったり 送信したりしないようなパスワードのスキームが欲しいところです。残念ながら、Samba は他の SMB システム (Windows NT、Windows for Workgroups、Windows 9x/Me) との互換性を 確保しなければならないという要件のために、これは実現できません。

Windows NT 4.0 サービスパック 3 はデフォルト設定でプレーンテキストのパスワードの送信を 無効化しています。これにより、暗号化されたパスワードのサポートを使用するか、 プレーンテキストのパスワードを再度有効化するように Windows NT レジストリを編集するか、 どちらかが必要になります。

Microsoft Windowsの下記のバージョンは、ドメイン環境にログオンする可能性があるにも かかわらず、完全なドメイン・セキュリティのプロトコルをサポートしていません。

  • MS DOS ネットワーク・クライアント 3.0 で、基本的なネットワーク・ リダイレクターがインストールされているもの
  • Windows 95 で、アップデートされたネットワーク・リダイレクターが インストールされているもの
  • Windows 98 [Second Edition]
  • Windows Me

Note

MS Windows XP Home は、ドメイン・メンバーになる機能はなく、ドメイン・ログオンには参加できません。

下記の Microsoft のバージョンは、ドメイン・セキュリティのプロトコルを完全にサポートしています。

  • Windows NT 3.5x
  • Windows NT 4.0
  • Windows 2000 Professional
  • Windows 200x Server/Advanced Server
  • Windows XP Professional

Microsoft SMB/CIFS クライアントの現在のリリース版は全て、ここに説明する SMB のチャレンジ/ レスポンス認証の仕組みをサポートしています。クリアテキストの認証を有効化しても、 クライアントが暗号化による認証に参加する能力を無効化するわけではありません。 そうではなく、クライアントがプレーンテキストでも暗号化でもどちらのパスワード認証方式にも 対応できるようにします。

MS Windowsのクライアントは、暗号化されたパスワードのみキャッシュします。 レジストリの変更により、プレーンテキストのパスワードが再度有効化された場合、 プレーンテキストのパスワードはキャッシュされません。このことは、ネットワーク接続が切れた場合、 キャッシュされた (即ち暗号化された) パスワードのみがリソースサーバーに送られて、 自動再接続を実行するために使用されるということを意味します。リソースサーバーが暗号化された パスワードをサポートしていない場合、自動再接続はできません。暗号化されたパスワードの使用を 強く推奨します。

暗号化されたパスワードの長所

  • プレーンテキストのパスワードがネットワークを 通して送信されない。誰かがネットワークスニファーを使用して、SMB サーバーに送られるパスワードを記録することができない。

  • Pプレーンテキストのパスワードが、メモリーにも ディスクにも、どこにも保存されない。

  • Windows NT は暗号化パスワードをサポートしない サーバーとやりとりすることを好まない。また、サーバーが「userレベル」 のセキュリティ・モードになっているとき、そのサーバーを ブラウズすることを拒否する。そのため、接続の度に、ユーザーが パスワードを出すようにプロンプトするので、大変厄介である。 これを止めさせる唯一の方法は、SMB の暗号を使用することである。

  • 暗号化パスワードのサポートにより、共有 (リソース) への自動再接続が可能になる。

  • PDC/BDC の運用に暗号化パスワードは不可欠である。

暗号化されていないパスワードの長所

  • プレーンテキストのパスワードは、ディスクに保存されず、 メモリーにキャッシュされない。

  • Login や FTP などの、UNIX の他のサービスと同じパスワード・ ファイルが使用できる。

  • Telnet や FTP などの他のサービスが、プレーンテキストの パスワードをネットワーク上で送信している。従って、これを SMB のために 送信することにより、大勢に影響はない。

MS Windows と UNIX の間の、ユーザー識別子のマッピング

MS Windows NT4/200x がセキュリティ識別子 (SID) を要求するのと同様に、UNIX/Linux の全てのオペレーションは、ユーザー識別子 (UID) を要求します。Samba は MS Windows のユーザーを UNIX/Linux の UID にマッピングするために、二つの方法を提供します。

第一に、すべての Samba SAM (セキュリティ・アカウント・マネジャー・データベース) アカウントが、そのアカウントとマッピングされるべき UNIX/Linux UID を必要とします。 アカウント情報データベースにユーザーが追加されるにつれ、Samba は Samba のホスト OS にそのアカウントを追加するために、add user script インターフェースを呼びます。本質的には、ローカルSAMの中の全アカウントが、 ローカル・ユーザー・アカウントを必要とします。

Windows の SID を UNIX の UID にマッピングする二つ目の方法は、idmap uididmap gid のパラメーターを smb.conf の中で設定することです。 これらのパラメーターについての詳細情報は man ページを参照ください。これらのパラメーターは リモートの SAM サーバーからユーザーをマッピングする際に不可欠です。

分散されたマシン上の共通 UID や GID のマッピング

Samba-3 は、分散型ネットワークに所属する全サーバーが同一の UID や GID を維持することを 可能にする特殊機能を持っています。分散型ネットワークとは、PDC が一つあり、一つ以上の BDC かつまたは一つ以上のドメイン・メンバー・サーバーが存在するネットワークです。 どうしてこれが重要なのでしょうか? これは、ファイルが複数のプロトコル (例えばNFS) で共有されていて、ユーザーが UNIX/Linux システム間で rsync などの ツールを使用してファイルをコピーしているときに、重要です。

この特殊機能により、idmap backend というパラメーターが使用できる ようになります。このパラメーターのデフォルト設定は空の文字列です。技術的には LDAP ベースの idmap バックエンドを UID 用及び GID 用に使用することが可能ですが、LDAP を SAM バックエンド にも使用するようなネットワーク設定の時に使用するのが、最も意味があると言えるでしょう。 以下の でこれを説明します。

Example 11.1. LDAP idmap バックエンドを使用する設定例

[global]
idmap backend = ldap:ldap://ldap-server.quenya.org:636
idmap backend = ldap:ldaps://ldap-server.quenya.org

LDAP バックエンドを最大活用したいと考えるネットワーク管理者は、遅かれ早かれ、PADL ソフトウェア社の 優れた功績を知ることになるでしょう。PADL 社 http://www.padl.com は、 オープンソース用に役に立ちそうな数多くのツールを制作し、リリースしてきました。 その中には、以下のようなツールがあります:

  • nss_ldap: LDAP ネームサービス・スイッチのモジュールであり、AIX、Linux、 Solaris その他の OS にネイティブのネームサービスを提供します。このツールは、UID や GID の一元的格納と取り出しに使用できます。

  • pam_ldap: PAM モジュールであり、UNIX/Linux システムのアクセス認証への LDAP の統合を提供します。

  • idmap_ad: IDMAP バックエンドであり、UNIX 用の Microsoft のサービスを サポートします。 ウェブサイト から RFC 2307 のスキーマが入手できます。

アカウント管理ツール

Samba は、ユーザー・アカウントとマシン・アカウントの管理のために二つのツールを提供します。 これらのツールは smbpasswdpdbedit と呼ばれます。 三つ目のツールも開発中ですが、Samba-3.0.0 に合わせて出荷できる見込みはありません。 この新ツールは TCL/TK GUI ツールで、MS Windows NT4 ドメイン・ユーザー・マネジャーによく 似たものになる予定です。Samba-3.0.1 のリリースまでには、発表できるようになることを望んでいます。

smbpasswd コマンド

smbpasswdのユーティリティは、passwd または yppasswd のプログラムと似ています。これは、 パスワード・データベース・バックエンドに 32 バイトのパスワードのフィールドを 二つ維持するものです。

smbpasswd はクライアント-サーバー・モードで作動し、 ユーザーのパスワードを変更するようにローカルの smbd に連絡します。 これは大きな便益をもたらします。

smbpasswd は、Windows NT サーバー上のパスワードを変更する 機能を持ちます。(NTドメイン・ユーザーのパスワードを変更する場合に、NT プライマリ・ドメイン・コントローラーにリクエストが送られる場合にのみできます。)

smbpasswd は以下の目的のために使用できます:

  • ユーザー・アカウントまたはマシン・アカウントを 追加 する。
  • ユーザー・アカウントまたはマシン・アカウントを 削除 する。
  • ユーザー・アカウントまたはマシン・アカウントを 有効化 する。
  • ユーザー・アカウントまたはマシン・アカウントを 無効化 する。
  • ユーザー・アカウントまたはマシン・アカウントを NULL に設定 する。
  • ドメイン間信頼アカウントを管理する。

smbpasswd をノーマルユーザーとして使用するには以下の通りタイプしてください:

$ smbpasswd
Old SMB password: secret

secret のところに、古いパスワードをタイプするか、 古いパスワードがない場合は、ただリターンキーを押して下さい。

New SMB Password: new secret
Repeat New SMB Password: new secret

古い値が当該ユーザーに関して現在保存されている値と一致しない場合、または、 新しく入力したパスワードの二つの間で不一致の場合、パスワードは変更されません。

普通のユーザーからこのコマンドが出された場合は、このコマンドは、このユーザー自身の SMB パスワードの変更のみを許可します。

root からコマンドが出された場合は、smbpasswd は変更したい パスワードのかわりに、変更したい SMB パスワードの所有者であるユーザー名を指定する、 オプションを受け付けます。root からコマンドが出された場合、smbpasswd は古いパスワードを聞き返してきたり、チェックしたりはしません。従って、root は自分のパスワードを忘れたユーザーのパスワードを再度設定することができます。

smbpasswd は、passwd または yppasswd コマンドを使用する UNIX ユーザーが馴染んでいる方法で動作するように設計されています。 管理者の使用も考慮した設計ですが、このツールはユーザーレベルでの変更という不可欠な機能を 提供するものです。

smbpasswd の使用に関する詳細は (決定的な参考文献としては) man ページを参照してください。

The pdbedit コマンド

pdbedit は、root のみが使用できるツールであり、 パスワード・データベース・バックエンドの管理に使用します。 pdbedit は以下の目的に使用できます:

  • ユーザー・アカウントを追加、削除、変更する。
  • ユーザー・アカウントを一覧表示する。
  • ユーザー・アカウントを移行する。

pdbedit ツールはアカウントのセキュリティとポリシーの設定内容を 管理できる唯一のツールです。このツールは、smbpasswd が行える全オペレーションを 実行できる上、それ以上のことも行うことができます。

pdbedit の特に重要な目的は、一つの パスワード・データベース・バックエンドから別のパスワード・データベース・バックエンド への、アカウント情報の移行を可能にすることです。 この章の XML パスワード・バックエンドに 関する項を参照ください。

以下に tdbsam パスワード・バックエンドに格納されているユーザー・アカウント情報の例を 示します。この一覧は、以下を実行することにより、作成されました:

$ pdbedit -Lv met
UNIX username:        met
NT username:
Account Flags:        [UX         ]
User SID:             S-1-5-21-1449123459-1407424037-3116680435-2004
Primary Group SID:    S-1-5-21-1449123459-1407424037-3116680435-1201
Full Name:            Melissa E Terpstra
Home Directory:       \\frodo\met\Win9Profile
HomeDir Drive:        H:
Logon Script:         scripts\logon.bat
Profile Path:         \\frodo\Profiles\met
Domain:               MIDEARTH
Account desc:
Workstations:         melbelle
Munged dial:
Logon time:           0
Logoff time:          Mon, 18 Jan 2038 20:14:07 GMT
Kickoff time:         Mon, 18 Jan 2038 20:14:07 GMT
Password last set:    Sat, 14 Dec 2002 14:37:03 GMT
Password can change:  Sat, 14 Dec 2002 14:37:03 GMT
Password must change: Mon, 18 Jan 2038 20:14:07 GMT

pdbedit ツールは、一つのバックエンドから別のバックエンドへの認証 (アカウント) データベースの移行を可能にします。例えば: 古い smbpasswd データベースから tdbsam バックエンドへ、アカウントを移行するには:

  1. パスワード・データベース・バックエンドを passdb backend = tdbsam, smbpasswd に設定する。

  2. 以下を実行する:

    root# pdbedit -i smbpasswd -e tdbsam
    

  3. 次に smb.conf 内で、パスワード・データベース・バックエンドの設定から smbpasswd を外す。

パスワード・バックエンド

Sambaは、今日市場に出ている SMB/CIFS サーバー技術の中でも最も柔軟性の高い、バックエンドの アカウント・データベース設計を提供しています。この柔軟性は、以下に説明する機能を使用し始めると 一目瞭然です。

複数の異なるパスワード・バックエンドを指定することが可能であるのみならず、同じタイプの複数の バックエンドを指定することが可能です。例えば、二つの異なる tdbsam データベースを使用する場合:

passdb backend = tdbsam:/etc/samba/passdb.tdb \
tdbsam:/etc/samba/old-passdb.tdb

プレーンテキスト

Samba のより古いバージョンは、ユーザー情報を UNIX のユーザー・データベースと、 /etc/samba/smbpasswd または /etc/smbpasswd のファイルの中の幾つかのフィールドから取り出しました。 パスワードの暗号化が無効化されていると、SMB に特有のデータは一切格納されません。 そのかわり全てのオペレーションが、Samba のホスト OS が /etc/passwd データベースにアクセスするように行われます。例えば、Linux のシステムでは、 全てのオペレーションが PAM 経由で実行されます。

smbpasswd 暗号化パスワード・データベース

従来は、Samba の smb.conf ファイル内で encrypt passwords = yes を設定すると、ユーザー名、LM/NT パスワード・ハッシュ、 パスワード変更回数、及びアカウントのフラッグ等のユーザー・アカウント情報は、 smbpasswd(5) のファイルに格納されるものでした。 このアプローチでは、ユーザー数が多い (数千人規模の) サイトでは、幾つかの短所があります。

  • 一つ目の問題は、全てのルックアップが順番に実行されるということです。 一つのドメイン・ログオンにつき、大体二つ (ネットワーク・ドライブまたはプリンターを マッピングする時のような通常のセッション接続については一つ) のルックアップが発生することを 考えると、大規模サイトでは、このことが性能上のボトルネックとなってしまいます。 ここで必要なのは、データベースで使用されているような、インデックスを使用するアプローチです。

  • 二つ目の問題は、複数の Samba サーバーに smbpasswd ファイルを複製したい管理者は、 rsync(1)ssh(1) のような外部ツールを使用し、 カスタム化した社内用のスクリプトを書く必要があったことです。

  • 最後に、smbpasswd のエントリーの一つ一つに格納される情報量が多く、ホーム・ディレクトリ、 パスワード有効期限、相対 ID (RID) などの付加的な属性を格納する余地が全く残らないことです。

これらの欠点に対処するため、smbd が使用する、より堅牢なユーザー属性の格納方法が 開発されました。ユーザー・アカウントへのアクセスを定義する API は、一般に samdb インターフェースと呼ばれます。(以前は、passdb API と呼ばれていたもので、Samba の CVS ツリーでは、今でもこの名前が使われています。)

Samba は smapasswd プレーンテキスト・データベースの欠陥を克服するために、 一連の強化されたパスワード・データベース・バックエンドを提供します。これらは、tdbsam、 ldapsam、及び xmlsam です。これらのうち、ldapsam は大規模の企業サイトにとって 最も関心の高いものとなるでしょう。

tdbsam

Sambaは “TDB” (トリビアル・データベース) にユーザー・アカウントと マシン・アカウントのデータを格納することができます。このバックエンドを使用する場合、 特に追加的な設定は必要ありません。このバックエンドは、LDAP を必要としない新規の 実装事例に推奨します。

一般的な指針として、Samba チームは、ユーザー数 250 名以上のサイトには tdbsam バックエンドの使用を推奨しません。また、tdbsam は、アカウント・データベースの 複製を必要とするような PDB/BDC の実装を必要とするサイトでの使用を意図した拡張は できません。拡張性という理由で、この場合、明らかに ldapsam の使用を推奨するべきです。

ユーザー数 250 という限界は、このユーザー数になると、一般論として、 ルーティッド・ネットワークを持ち、サイトが複数の物理的ロケーションにまたがっている 可能性もあるであろう、という考えに基づいた目安に過ぎません。 現時点で Samba チームは、tdbsam アーキテクチャーの、性能に基づいた拡張性の限界を 把握していません。

ldapsam

ldapsam が提供しない機能があるということを、強調しておかなければなりません。 この文書の中で言及する LDAP のサポートは、以下を含みません:

  • Windows 200x Active Directory サーバーからの ユーザー・アカウント情報の取り出しをする方法。

  • /etc/passwd を置換する方法。

このうち、二つ目については、LDAP NSS 及び PAM のモジュールを使用することに より達成できます。これらのライブラリの LGPL バージョンは、 PADL Software 社から入手できます。 これらのパッケージに関する詳細情報は、 LDAP のシステム管理、Gerald Carter 著、出版元: O'Reilly、6章 NIS の置換 (原典:LDAP, System Administration; Gerald Carter by O'Reilly; Chapter 6: Replacing NIS) に載っています。

この本は、従来 smbpasswd(5) のファイルに格納されていた Samba の ユーザー・アカウント・情報の格納のために、LDAPディレクトリを使用する方法を 説明しています。読者は、LDAPの概念の基本的理解をし、稼動できる ディレクトリ・サーバーをすでにインストールしているという前提で書かれています。 LDAP アーキテクチャーとディレクトリに関するより詳細な情報は、以下のサイトを 参照してください。

他に、役に立つかもしれないSamba関連の参照先を二箇所挙げます:

  • Ignacio Coupeau が管理している Samba-PDC-LDAP-HOWTO

  • IDEALX による NT 移行スクリプトで、 このような Samba-LDAP ドメイン・コントローラー設定をしているユーザーとグループの管理を 目的としているもの。

サポートされている LDAP サーバー

LDAP の ldapsam コードは、OpenLDAP 2.0 と 2.1 のサーバーとクライアントのライブラリを使用して 開発・試験されています。同じコードが、Netscape の Directory Server と Client SDK でも 作動するはずです。しかし、コンパイル・エラーやバグが発生するのはやむを得ません。 これらの障害はそれほど直すのが難しいことはないでしょう。 バグの報告 の章で説明しているプロセスに従って、 修正プログラム (バグフィックス) を提出してください。

スキーマと RFC 2307 posixAccount への関係

Samba-3.0 は OpenLDAP 2.0 に必要なスキーマ・ファイルを examples/LDAP/samba.schema の中に持っています。 sambaSamAccount のオブジェクトクラスを以下に記述します:

objectclass (1.3.6.1.4.1.7165.2.2.6 NAME 'sambaSamAccount' SUP top AUXILIARY
    DESC 'Samba-3.0 Auxiliary SAM Account'
    MUST ( uid $ sambaSID )
    MAY  ( cn $ sambaLMPassword $ sambaNTPassword $ sambaPwdLastSet $
          sambaLogonTime $ sambaLogoffTime $ sambaKickoffTime $
          sambaPwdCanChange $ sambaPwdMustChange $ sambaAcctFlags $
          displayName $ sambaHomePath $ sambaHomeDrive $ sambaLogonScript $
          sambaProfilePath $ description $ sambaUserWorkstations $
          sambaPrimaryGroupSID $ sambaDomainName ))

samba.schema ファイルは、OpenLDAP 2.0/2.1 用にフォーマットされています。Samba チームは上記スキーマが使用する OID スペースを所有しており、これを使用することを推奨します。このスキーマを Netscape DS と使用できるように翻訳した場合は、改良したスキーマ・ファイルを パッチとして jerry@samba.org に提出してください。

smbpasswd ファイルが、ユーザーの /etc/passwd の エントリーに追加する情報を格納することを意図しているように、sambaSamAccount オブジェクトは、UNIX のユーザー・アカウント情報を捕捉することを意図しています。 sambaSamAccount は、AUXILIARY のオブジェクトクラスであり、従って、LDAP ディレクトリ中の既存のユーザー・アカウント情報を増補するために使用することができ、 よって、Samba のアカウント処理に必要な情報を提供することができます。しかし、 RFC2307 に記述されている posixAccount のオブジェクトクラスと重複するフィールド (例:UID) が幾つかあります。これは意図的なものです。

ディレクトリ内に全てのユーザー・アカウント情報 (UNIX 及び Samba) を格納するためには、 sambaSamAccount と posixAccount のオブジェクトクラスを組み合わせて使用することが 必要です。しかし、smbd はそれでも、標準の C ライブラリコール (例:getpwnam() など) によって、UNIX のユーザー・アカウント情報を入手します。このことは、Samba サーバーには、 LDAP NSS ライブラリがインストールされ機能していなければならないということを意味します。 このように情報を分けることで、LDAP 内に全ての Samba のアカウント情報を格納することを 可能にしながら、ネットワークが完全な LDAP のインフラに移行するまでの間、UNIX のアカウント情報は NIS で維持することができるのです。

OpenLDAP の設定

OpenLDAP ディレクトリ・サーバーの中に sambaSamAccount オブジェクトのためのサポートを 持つためには、まず、slapd の設定ディレクトリへ、samba.schema ファイルをコピーします。 samba.schema ファイルは Sambaの ソース・ディストリビューションの examples/LDAP のディレクトリ内にあります。

root# cp samba.schema /etc/openldap/schema/

次に、samba.schema ファイルを slapd.conf の中に入れます。sambaSamAccount オブジェクトは、他のスキーマ・ファイルに依存する属性を 二つ持っています。uid の属性は cosine.schema で定義され、uid の属性は inetorgperson.schema ファイル内で定義されています。この二つは samba.schema ファイルよりも前に入れて置かなければなりません。

## /etc/openldap/slapd.conf

## スキーマ・ファイル (デフォルトでcore.schema は必要)
include	           /etc/openldap/schema/core.schema

## sambaSamAccount に必要
include            /etc/openldap/schema/cosine.schema
include            /etc/openldap/schema/inetorgperson.schema
include            /etc/openldap/schema/nis.schema
include            /etc/openldap/schema/samba.schema
....

sambaSamAccount オブジェクトクラス (及び場合によっては、posixAccount と posixGroupの オブジェクトクラス) の検索スピードを上げるため、以下の例に示すように、 一部の最も有用な属性に関するインデックスを維持することを推奨します。

# 維持するインデックス
## OpenLDAP で要求されるもの
index objectclass             eq

index cn                      pres,sub,eq
index sn                      pres,sub,eq
## pdb_getsampwnam をサポートするために必要なもの
index uid                     pres,sub,eq
## pdb_getsambapwrid() をサポートするために必要なもの
index displayName             pres,sub,eq

## posixAccount と posixGroup のエントリーもディレクトリ内に格納するのなら、
## これらのコメントアウトを外す。
##index uidNumber               eq
##index gidNumber               eq
##index memberUid               eq

index   sambaSID              eq
index   sambaPrimaryGroupSID  eq
index   sambaDomainName       eq
index   default               sub

以下を実行して新しいインデックスを作成します:

root# ./sbin/slapindex -f slapd.conf

これらの変更後は、slapdを再起動するのを忘れないでください:

root# /etc/init.d/slapd restart

LDAP データベースを初期化する

LDAP データベースにアカウントを追加できる前に、アカウントを格納するコンテナを 作成しなければなりません。以下の LDIF ファイルを書き換えて、ニーズ (DNS エントリ等々) にあったものにしてください:

# Samba ベースのための組織構成
dn: dc=quenya,dc=org
objectclass: dcObject
objectclass: organization
dc: quenya
o: Quenya Org Network
description: The Samba-3 Network LDAP Example

# ディレクトリ管理のための組織内の役割
dn: cn=Manager,dc=quenya,dc=org
objectclass: organizationalRole
cn: Manager
description: Directory Manager

# ユーザーのためのコンテナの設定
dn: ou=People,dc=quenya,dc=org
objectclass: top
objectclass: organizationalUnit
ou: People

# People OU のための管理ハンドルの設定
dn: cn=admin,ou=People,dc=quenya,dc=org
cn: admin
objectclass: top
objectclass: organizationalRole
objectclass: simpleSecurityObject
userPassword: {SSHA}c3ZM9tBaBo9autm1dL3waDS21+JSfQVz

# グループのためのコンテナの設定
dn: ou=Groups,dc=quenya,dc=org
objectclass: top
objectclass: organizationalUnit
ou: Groups

# Groups OU のための管理ハンドルの設定
dn: cn=admin,ou=Groups,dc=quenya,dc=org
cn: admin
objectclass: top
objectclass: organizationalRole
objectclass: simpleSecurityObject
userPassword: {SSHA}c3ZM9tBaBo9autm1dL3waDS21+JSfQVz

# コンピューターのためのコンテナの設定
dn: ou=Computers,dc=quenya,dc=org
objectclass: top
objectclass: organizationalUnit
ou: Computers

# Computers OU のための管理ハンドルの設定
dn: cn=admin,ou=Computers,dc=quenya,dc=org
cn: admin
objectclass: top
objectclass: organizationalRole
objectclass: simpleSecurityObject
userPassword: {SSHA}c3ZM9tBaBo9autm1dL3waDS21+JSfQVz

上記の userPassword は、slappasswd を使用して生成します。

次に、以下のコマンドによって、LDIF ファイルの中身を LDAP データベースに ロードします。

$ slapadd -v -l initldap.dif

適切なアクセス制御リストと管理パスワードで、LDAP サーバーのセキュリティを 確保することを忘れないで下さい。

Note

Samba が LDAP サーバーにアクセスできる前に、以下のように、LDAP 管理パスワードを Samba-3 の secrets.tdb データベース内に格納する必要があります:

root# smbpasswd -w secret

Samba の設定

ご使用の Samba のバージョンが LDAP サポートつきで構築されている場合に限り、以下のパラメーターは smb.conf 内にあります。Samba は、LDAP ライブラリが見つかれば、自動的に LDAP サポートありで 構築されます。

LDAP 関連の smb.conf オプション: passdb backend = ldapsam:url, ldap admin dn, ldap delete dn, ldap filter, ldap group suffix, ldap idmap suffix, ldap machine suffix, ldap passwd sync, ldap ssl, ldap suffix, ldap user suffix,

これは smb.conf の man ページに説明されているので、ここでは繰り返しません。 ただし、LDAP ディレクトリありで使用する場合の smb.conf ファイルの例 を以下に示します。

Example 11.2. LDAP ありの設定

[global]
security = user
encrypt passwords = yes
netbios name = MORIA
workgroup = NOLDOR
# ldap 関連パラメーターが
# ディレクトリ・サーバーにバインドするためのDNを定義する。
# このDNのパスワードは、smb.confファイルには格納されない。代わりに、
# 'smbpasswd -w secretpw' を使用して、
# パスフレーズを secrets.tdb ファイルに格納するように設定しなければならない。
# "ldap admin dn" の値が変化したら、このパスワードはリセットされなければならない。
ldap admin dn = "cn=Manager,ou=People,dc=quenya,dc=org"
# ディレクトリに接続する際の SSL オプションを定義する。
# ('off', 'start tls', or 'on' (default))
ldap ssl = start tls
# syntax: passdb backend = ldapsam:ldap://server-name[:port]
passdb backend = ldapsam:ldap://frodo.quenya.org
# smbpasswd -x delete the entire dn-entry
ldap delete dn = no
# Machine Suffix と User Suffix が、ベースの Suffix に追加される。
# 引用符は入れない。拡張子のデフォルト設定は NULL。
ldap user suffix = ou=People
ldap group suffix = ou=Groups
ldap machine suffix = ou=Computers
# LDAP 内の UNIX アカウント情報を信頼する。
# (詳細は smb.conf の man ページを参照のこと。)
# ディレクトリを検索する際に使用するベース DN を指定する。
ldap suffix = dc=quenya,dc=org
# 一般的には、デフォルトの ldap 検索フィルターでよい。
ldap filter = (&(uid=%u)(objectclass=sambaSamAccount))

アカウント管理とグループ管理

ユーザー・アカウントは、sambaSamAccount のオブジェクトクラスを通して管理されるので、 sambaSamAccount の属性を取り扱うことが出来るように、ご使用の既存の管理ツールを変更する 必要があります。

マシン・アカウントは、ユーザー・アカウントと同様、sambaSamAccount のオブジェクトクラスで 管理されます。しかし、これらのアカウントを LDAP ネームスペースの別のツリーに格納したい場合は、 それも可能です。グループの格納には、“ou=Groups,dc=quenya,dc=org”、 ユーザーの格納には “ou=People,dc=quenya,dc=org” を使用してください。 NSS と PAM を正しく設定してください (通常、/etc/openldap/sldap.conf の設定ファイル内での設定となります。)

Samba-3 では、グループ管理システムは POSIX のグループに基づいています。つまり、Samba は posixGroup のオブジェクトクラスを使用するということです。今のところ、NT のような (グローバルグループとローカルグループの) グループシステム管理はありません。 Samba-3 は、Domain Groups についてのみ知っており、MS Windows 2000 や Active Directory とは違って、ネストしたグループはサポートしていません。

セキュリティと sambaSamAccount

ディレクトリ内の sambaSamAccount のエントリーのセキュリティについて検討するとき、 以下の二つの重要な事項を覚えておかなければなりません。

  • 暗号化されていない LDAP セッションを通して、lmPassword または ntPassword の属性値を取り出しては いけない

  • 管理者でないユーザーに、lmPassword または ntPassword の属性値を 絶対に見せては いけない

これらのパスワードのハッシュ値は、クリアテキストと同等であり、元のクリアテキストの文字列を 導き出さなくても、ユーザー自身になりすますために使用することができます。LM/NT のパスワードの ハッシュに関する詳細は、この章の アカウント情報データベース の項を参照ください。

上記の一つ目のセキュリティ上の課題に対応するために、smb.confldap ssl パラメーターは、ディレクトリ・サーバーに 連絡する際に、636 のデフォルト・ポートを使用して暗号化されたセッションを要求するように、 デフォルト設定 (ldap ssl = on) されています。OpenLDAP サーバーを使用している場合、LDAPS のかわりに、StartTLS LDAP の拡張オペレーションを使用することができます。どちらの場合も、このセキュリティ設定をオフにする (ldap ssl = off)ことは極力避けるように、 強く勧告します。

LDAPS のプロトコルは、LDAPv3 StartTLS の拡張オペレーションにいずれ取って代わられることに 気をつけてください。しかし、OpenLDAP ライブラリは、クライアントとサーバー間のコミュニケーションの セキュリティを確保するための古い方法を、今のところサポートしています。

二つ目のセキュリティ確保のための予防策としては、管理者でないユーザーがディレクトリから パスワードのハッシュ値を入手できないようにすることです。これは、slapd.conf 内で以下の ACL を使用することにより、達成できます。

## "ldap admin dn" にアクセスを許し、その他のすべてのユーザーにはアクセスを拒否する
access to attrs=lmPassword,ntPassword
     by dn="cn=Samba Admin,ou=People,dc=quenya,dc=org" write
     by * none

sambaSamAccounts の LDAP 特殊属性

sambaSamAccountsのオブジェクトクラスは、次表 (Part APart B)に示す属性で構成されます:

Table 11.1. sambaSamAccounts オブジェクトクラス (LDAP) の属性 Part A

sambaLMPassword16 進法の文字列に変換されて保存される LANMAN パスワードの 16 バイトのハッシュ
sambaNTPassword16 進法の文字列に変換されて保存される NT パスワードの 16 バイトのハッシュ
sambaPwdLastSetsambaLMPasswordsambaNTPassword の二つの属性が最後に設定された時刻を、1970 年を起点として 何秒後であるかによって表す整数値
sambaAcctFlagsU (ユーザー)、W (ワークステーション)、 X (パスワード有効期限なし)、I (ドメイン信頼アカウント)、H (ホーム・ディレクトリが必要)、 S (サーバー信頼アカウント)、D (無効化) などのアカウントに関するフラッグを表す、 大括弧 [] に入った 11 文字の文字列
sambaLogonTime現在使用されていない整数値
sambaLogoffTime現在使用されていない整数値
sambaKickoffTimeユーザーがログインを拒否され、 以後ログインできない状態になる時刻 (UNIX の時刻の形式) を指定する。この属性を指定しない アカウントは有効期限が切れることがない。この属性を「shadowAccount」のオブジェクトクラスの 「shadowExpire」の属性と共に使用すると、指定された日付に、正確に、アカウントが完全に 有効期限切れとなる。
sambaPwdCanChangeユーザーがパスワードを変更できるようになる時刻 (UNIX の時刻の形式) を指定する。この属性を設定しない場合、そのユーザーは、いつでもパスワードを 変更できる。
sambaPwdMustChangeユーザーがパスワード変更を強制される時刻 (UNIX の時刻の形式) を指定する。この値が「0」に設定されている場合、そのユーザーは、 最初にログインする際に、パスワードを変更しなければならない。この属性が設定されていない場合、 そのパスワードは有効期限が切れることがない。
sambaHomeDriveSambaHomePath により指定された UNC パスを マッピングする先のドライブ名を指定する。ドライブ名は “X:” の形式で指定しなければならない。 X を、ドライブ名で置き換える。詳細は smb.conf(5) の man ページの “logon drive” のパラメーターの項を参照のこと。
sambaLogonScriptSambaLogonScript の属性は、 ユーザーのログオン・スクリプトのパスを .CMD、.EXE、または .BAT ファイルに指定する。NULL でもよい。 このパスは netlogon 共有の相対パスである。詳細は smb.conf の man ページの logon script のパラメーターの項を参照のこと。
sambaProfilePathユーザーのプロファイルへのパスを指定する。 この値は、NULL でも、ローカルの絶対パスでも、UNC パスでもよい。詳細は smb.conf の man ページの logon path のパラメーターの項を参照のこと。
sambaHomePathsambaHomePath の属性は、 ユーザーのホーム・ディレクトリのパスを指定する。NULL でもよい。sambaHomeDrive が設定され、 ドライブ名が指定されている場合は、sambaHomePath は UNC パスでなければならない。 パスは、ネットワーク UNC パスで、\\server\share\directory の形式でなければならない。 この値は NULL でもよい。詳細は smb.conf の man ページの logon home のパラメーターの項を参照のこと。

Table 11.2. sambaSamAccounts オブジェクトクラス (LDAP) の属性 Part B

sambaUserWorkstationsこの属性では、 ユーザーがログインに使用することを許可されているマシンをカンマで区切って一覧表示できる。 Samba ドメイン・メンバーに接続しようとすると問題がおきることがある。これは、ドメイン・メンバーが このリストに載っておらず、ドメイン・コントローラーがログインを拒否するため。 この属性を指定しない場合、デフォルト設定は、特に制約を設けないことを意味する。
sambaSID ユーザーのセキュリティ識別子 (SID)。Windows における UNIX の UID と同等のもの。
sambaPrimaryGroupSID ユーザーのプライマリ・グループのセキュリティ識別子 (SID)。
sambaDomainName ユーザーが所属するドメイン。

これらのパラメーターの大半は、Samba が、あるドメインの PDC として作動している場合にのみ 使用されます。(Samba をプライマリ・ドメイン・コントローラーとして設定する方法の詳細は ドメイン管理 の章を参照ください。) 以下の四つの属性は、 値がデフォルト値でない場合で、sambaSamAccount のエントリーと共にのみ保存されます。

  • sambaHomePath
  • sambaLogonScript
  • sambaProfilePath
  • sambaHomeDrive

これらの属性は、値がデフォルト値でない場合で、sambaSamAccount のエントリーと共にのみ保存されます。 例えば、MORIA が PDC として設定され、その smb.conf ファイルで logon home = \\%L\%u と定義されたとしましょう。“becky” という名のユーザーがドメインにログオンするとき、 logon home の文字列は「\\MORIA\becky」になります。 “uid=becky,ou=People,dc=samba,dc=org” のエントリーの中に smbHome の属性が存在するとき、 この値が使用されます。しかし、この属性が存在しないときは、その代わり、 logon home のパラメーターの値が使用されます。 Samba は、値がデフォルト (例えば \\MOBY\becky) でない場合に限り、 ディレクトリのエントリーに属性値を書き込みます。

sambaSamAccount の LDIF エントリーの例

以下は sambaSamAccount のオブジェクトクラスの使用方法を示す、LDIF の実例です。:

	dn: uid=guest2, ou=People,dc=quenya,dc=org
	sambaLMPassword: 878D8014606CDA29677A44EFA1353FC7
	sambaPwdMustChange: 2147483647
	sambaPrimaryGroupSID: S-1-5-21-2447931902-1787058256-3961074038-513
	sambaNTPassword: 552902031BEDE9EFAAD3B435B51404EE
	sambaPwdLastSet: 1010179124
	sambaLogonTime: 0
	objectClass: sambaSamAccount
	uid: guest2
	sambaKickoffTime: 2147483647
	sambaAcctFlags: [UX         ]
	sambaLogoffTime: 2147483647
	sambaSID: S-1-5-21-2447931902-1787058256-3961074038-5006
	sambaPwdCanChange: 0
	

以下は、sambaSamAccount とposixAccount の両方のオブジェクトクラスを使用するための LDIF エントリーの例です:

	dn: uid=gcarter, ou=People,dc=quenya,dc=org
	sambaLogonTime: 0
	displayName: Gerald Carter
	sambaLMPassword: 552902031BEDE9EFAAD3B435B51404EE
	sambaPrimaryGroupSID: S-1-5-21-2447931902-1787058256-3961074038-1201
	objectClass: posixAccount
	objectClass: sambaSamAccount
	sambaAcctFlags: [UX         ]
	userPassword: {crypt}BpM2ej8Rkzogo
	uid: gcarter
	uidNumber: 9000
	cn: Gerald Carter
	loginShell: /bin/bash
	logoffTime: 2147483647
	gidNumber: 100
	sambaKickoffTime: 2147483647
	sambaPwdLastSet: 1010179230
	sambaSID: S-1-5-21-2447931902-1787058256-3961074038-5004
	homeDirectory: /home/moria/gcarter
	sambaPwdCanChange: 0
	sambaPwdMustChange: 2147483647
	sambaNTPassword: 878D8014606CDA29677A44EFA1353FC7

パスワードの同期化

Samba-3 以降のバージョンは、アカウントと共に格納された Samba でない (LDAP) パスワードを更新できます。pam_ldap を使用しているとき、UNIX と Windows のパスワードを 一度に変更できます。

ldap passwd sync のオプションは、 下表に示す値を持つことができます。

Table 11.3. ldap passwd sync の設定できる値

解説
yes

ユーザーがパスワードを変更すると、 ntPasswordlmPassword 及び password のフィールドを更新する。

no

ntPasswordlmPassword のみを更新する。

only

LDAP パスワードのみを更新し、その他のフィールドは LDAP サーバーに任せる。このオプションは、一部の LDAP サーバーにのみ有効である。 LDAP サーバーが LDAP_EXOP_X_MODIFY_PASSWD をサポートする場合にのみ可能。

より詳細な情報は smb.conf の man ページを参照ください。

MySQL

誰かが素晴らしい新アイデアを思いつくということが時々ありますが、ユーザー・アカウントを SQL バックエンドに格納するという考えはその一つです。これをしたい人こそが、その特殊な便益を知ることが できる立場にあると言えます。これは言い逃れのようですが、実際、Samba ユーザーの大半にとって 取るに足らない利便が、残り少数のユーザーにとって大変な意義がある理由を、事細かに説明していたら 切りがありません。ともあれ、SQL を何としても使用したいという向きには、機能するシステムを 実現するために、以下の説明が役に立つでしょう。

データベースの作成

自分でテーブル設定してフィールド名を pdb_mysql に指定する (コラム名については下記を参照)、 あるいは、デフォルトのテーブルを使用することができます。 nameexamples/pdb/mysql/mysql.dump のファイルに、必要なテーブルを 作成するための正しいクエリーが入っています。以下のコマンドを使用します。

$ mysql -uusername -hhostname -ppassword \
	databasename < /path/to/samba/examples/pdb/mysql/mysql.dump

設定

このプラグインは、説明書類が充分ではありませんが、簡単に説明します。以下を smb.conf の中の passdb backend の変数に 追加してください:

passdb backend = [other-plugins] mysql:identifier [other-plugins]

識別子は、他のプラグインの識別子や pdb_mysql の他のインスタンスとぶつからない限り、 どのような文字列でも構いません。passdb backend に複数の pdb_mysql.so エントリーを指定する場合は、それぞれ異なる識別子を使用しなければなりません。

その他のオプションは、smb.conf[global] セクションを通して 得ることができます。下表 を参考にしてください。

Table 11.4. MySQL パスワード・データベース・バックエンドのための基本的な smb.conf のオプション

FieldContents
mysql hostホスト名、デフォルト設定は「local host」
mysql password 
mysql userデフォルト設定は「samba」
mysql databaseデフォルト設定は「samba」
mysql portデフォルト設定は「3306」
tableユーザー格納するテーブル名

Warning

MySQL ユーザーのためのパスワードは、smb.conf ファイルに格納されるので、smb.conf ファイルは Samba を使用するユーザーに対して読み込み専用にするべきです。これは、セキュリティ上のバグとして 認識されており、近日中にフィックスします。

下表 にコラム名を示します。 デフォルトのコラム名は前述の dump ファイルの中にあります。

Table 11.5. MySQL パスワード・データベース・バックエンドの MySQ Lフィールド名

フィールドタイプ内容
logon time columnint(9)ユーザーの最後のログオンの UNIX タイムスタンプ
logoff time columnint(9)ユーザーの最後のログオフの UNIX タイムスタンプ
kickoff time columnint(9)ユーザーがワークステーションから離れるべき時刻の UNIX タイムスタンプ (強制はされない)
pass last set time columnint(9)パスワードが最後に設定された時刻の UNIX タイムスタンプ
pass can change time columnint(9)パスワードの変更できるようになる時刻の UNIX タイムスタンプ
pass must change time columnint(9)パスワードを変更しなければならない時刻の UNIX タイムスタンプ
username columnvarchar(255)UNIX ユーザー名
domain columnvarchar(255)ユーザーが所属する NT ドメイン
nt username columnvarchar(255)NT ユーザー名
fullname columnvarchar(255)ユーザーのフルネーム
home dir columnvarchar(255)UNIX ホーム・ディレクトリのパス (logon home のパラメーターと同等)
dir drive columnvarchar(2)ディレクトリ・ドライブのパス (e.g., “H:”)
logon script columnvarchar(255)ログオン時にクライアント側で走らせるバッチファイル
profile path columnvarchar(255)プロファイルのパス
acct desc columnvarchar(255)ASCII の NT ユーザーデータ
workstations columnvarchar(255)ユーザーがログオンできるワークステーション (あるいは、全部のときは NULL 設定)
unknown string columnvarchar(255)未知の文字列
munged dial columnvarchar(255)未知
user sid columnvarchar(255)NT ユーザーの SID
group sid columnvarchar(255)NT グループの SID
lanman pass columnvarchar(255)暗号化された lanman password
nt pass columnvarchar(255)暗号化された nt passwd
plain pass columnvarchar(255)プレーンテキストの password
acct ctrl columnint(9)NT ユーザーデータ
unknown 3 columnint(9)未知
logon divs columnint(9)未知
hours len columnint(9)未知
bad password count columnint(5)アカウントを無効化する前に許される無効なパスワードによる試行回数
logon count columnint(5)ログオン試行回数
unknown 6 columnint(9)未知

各コラム名の後にコロン (:) を入れることにより、テーブルを更新する際に、更新するコラムを指定することが できます。また、コロンの後に何も指定しないと、フィールドのデータは更新されません。コラム名を NULL 設定すると、そのフィールドは使ってはならないという設定になります。

設定の例 を以下に示します:

Example 11.3. MySQL パスワード・データベース・バックエンドの設定

[global]
passdb backend = mysql:foo
foo:mysql user = samba
foo:mysql password = abmas
foo:mysql database = samba
# ドメイン名は静的データで変更できない。
foo:domain column = 'MYWORKGROUP':
# フルネームのコラムのデータは、他の幾つかのコラムから取ってくる。
foo:fullname column = CONCAT(firstname,' ',surname):
# Samba はパスワードのコラムに絶対に書き込みをしてはいけない。
foo:lanman pass column = lm_pass:
foo:nt pass column = nt_pass:
# unknown 3 column は格納されない。
foo:unknown 3 column = NULL

プレーンテキストのパスワードまたは暗号化パスワードを使用する

プレーンテキストのパスワードは使用しないように、私は強く勧告しますが、それでも使用することはできます。

プレーンテキストのパスワードを使用したいなら、「identifier:lanman pass column」と 「identifier:nt pass column」を「NULL」設定して (引用符なし)、「identifier:plain pass column」 をプレーンテキストのパスワードを持つコラム名に設定してください。

暗号化パスワードを使用するなら、「identifier:plain pass column」を「NULL」設定して (引用符なし) ください。これはデフォルト設定です。

テーブルからコラムにないデータを取る

一部のデータを「constant」にすることにより、データベース内に全データを持たないようにすることも できます。

例えば、「identifier:fullname column」を CONCAT(Firstname,' ',Surname) などに設定することができます。

あるいは、「identifier:workstations column」を NULL などに設定することができます。

プログラム言語の組み立て方についての詳細は MySQL のマニュアルを参照ください。

XML

このモジュールは libxml2 がインストールされていることを要件とします。

pdb_xml の使用方法は、かなりわかりやすいです。 データをエキスポートするには、以下を使用します

$ pdbedit -e xml:filename

(ファイルネームが、データを入れるべきファイルの名前であるとき)

データをインポートするには、以下を使用します: $ pdbedit -i xml:filename

よくあるエラー

ユーザーがログオンできない

Samba をインストールしたのに、私の UNIX アカウントからログオンできません!

ユーザーが最新の Samba の passdb backend に追加されていることを確認してください。Account Management Tools の項を参照してください。

ユーザーが誤ったバックエンド・データベースに追加される

Samba-3 に移行したばかりのユーザーから、幾つか苦情が寄せられました。下記の smb.conf ファイルのエントリーが問題の原因で、新しいアカウントが tdbsam の passdb.tdb ファイルではなく、 移行前の smbpasswd ファイルに追加されていました。

[global]
...
passdb backend = smbpasswd, tdbsam
...

Sambaは、passdb backend のパラメーターのエントリーの中の、最初のエントリーに 新アカウントを追加します。tdbsam にしたい場合は、エントリーを以下に変更してください:

passdb backend = tdbsam, smbpasswd

auth methods の設定

auth methods のパラメーターを明確に設定する場合は、 guest であることを、オンラインのエントリーの最初に、たとえば、 auth methods = guest sam などで指定しなければなりません。

つまり、このような指定がオンラインのパラメーターの 最後 でなければならないという、 passdb backend のオプションの要件とは正反対です。