Chapter 11. アカウント情報データベース

Jelmer R. Vernooij

The Samba Team

John H. Terpstra

Samba Team

Gerald (Jerry) Carter

Samba Team

Jeremy Allison

Samba Team

Guenther Deschner

LDAP updates 
Samba Team

Olivier (lem) Lemaire

May 24, 2003

Table of Contents

機能と利便性
下位互換性のあるバックエンド
新しいアカウント格納システム
技術情報
セキュリティに関する重要な注意事項
Microsoft Windows と UNIX の間の、ユーザー識別子のマッピング
分散マシン上の共通のUID/GIDマッピング
LDAPに関するコメント
LDAPディレクトリとWindowsのコンピューターアカウント
アカウント管理ツール
smbpasswdツール
pdbeditツール
パスワードバックエンド
平文
smbpasswd: 暗号化したパスワードデータベース
tdbsam
ldapsam
よくあるエラー
ユーザーがログオンできない

3つのpassdbバックエンドがSambaチームで完全なメンテナンスが行われており、それは以下である: smbpasswd (旧式)、tdbsam(tdbベースのバイナリファイル 形式)とldapsam(LDAP)。もちろん、ldapsamバックエンド のみが、POSIX(UNIX)とSambaのユーザーとグループアカウント情報を単一のリポジトリに格納できる。 smbpasswdtdbsamバックエンドはSambaユーザー アカウントのみ格納する。

厳密な意味で、3つのアカウントストレージとアクセスシステムがサポートされている。それらの 1つは旧式である(smbpasswd)。すべての簡単なシステムには tdbsam方式 を使用することを推奨する。ldapsamはもっと大規模か、複雑なネット ワークで使用すること。

厳格かつ文字通りの意味で、passdbバックエンドはアカウント格納メカニズム(あるいは方法) のみである。技術の選択はミスリードの可能性があるが、言い回しの選択で困っている。 この章では、ユーザーと信頼アカウントにフォーカスをあてたアカウント格納システムの 本質について記述する。信頼アカウントは2つの形式があり、それはマシン信頼アカウント (コンピューターアカウント)とドメイン間信頼アカウントである。それらはユーザーのような エントリとして扱われる。

機能と利便性

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

平文

これは全く持ってバックエンドではないが、単純化のためにここに表示する。 Sambaは伝統的なUNIX/Linuxの/etc/passwd/etc/shadow形式のサブシテムに平文認証要求を渡す ように設定できる。Pluggable Authentication Modules (PAM) サポートが あるシステム上では、 全てのPAMモジュールがサポートされる。動作は、 Samba-2.2.x の場合と全く同様で、Microsoft Windowsクライアントにより 課されるプロトコルの制約も同様に適用される。平文パスワードの使用に 関する制約に関する詳細情報は、 技術情報の項を参照のこと。

smbpasswd

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

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

新しいアカウント格納システム

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

tdbsam

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

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

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

ldapsam

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

Samba では LDAP 用拡張の実装が新しくなり、これにより新しい形式の Samba スキーマを 使う OpenLDAP の設定が必要である。新しい形式のスキーマファイルは、Samba ディストリビューションの examples/LDAPのディレクトリにある。

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

技術情報

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

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

Sambaはなぜ単純にUNIXパスワードデータベースを使うことが出来ないかという質問は 多くの人から聞く。Windowsは、パスワードに対してそれ固有の暗号化形式を要求する。 WindowsのパスワードはUNIX形式の暗号化パスワードに変換できない。そのため、標準 UNIXユーザーデータベースを使うことが出来ず、Lanman ハッシュとNTハッシュは別の所に 格納しなければならない。

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

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

IDMAP: SIDのUIDへの解決

SIDのUIDへの解決は、Samba の適正運用の根幹を成す。以下の両例で、winbinddが 稼動していないか、あるいは、接続できない状況のとき、ローカルのSID/UID解決 のみが可能である。SIDのUIDへの解決 およびUIDのSIDへの解決の図を参照のこと。

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

IDMAP: SIDのUIDへの解決

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

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

理想的には、ネットワーク上でもディスク上でも平文パスワードを持ったり送信したり しないようなパスワードのスキームが欲しいところである。残念ながら、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 Home Edition は、ドメインメンバーになる機能はなく、ドメインログオンは実行できない。

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

  • Windows NT 3.5x.

  • Windows NT 4.0.

  • Professional と名の付く Windows エディション

  • Server/Advanced Server と名の付く Windows エディション

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

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

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

  • 平文パスワードがネットワーク経由で送信されない。誰かがネットワーク スニファーを使用して、SMBサーバーに送られるパスワードを記録することができない。

  • 平文パスワードが、メモリにもディスクにも、どこにも保存されない。

  • Windows NTは暗号化パスワードをサポートしないサーバーとやりとりする ことを好まない。そのサーバーを ブラウズすることを拒否する。そのため、 接続の度に、ユーザーにパスワードを入力するように要求するので、大変厄介 である。 これを止めさせる唯一の方法は、SMB暗号を使用することである。

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

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

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

  • 平文パスワードは、ディスクに保存されず、メモリにキャッシュされない。

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

  • TelnetやFTPなどの他のサービスが、平文パスワードをネットワーク上で 送信している。従って、SMBのために送信しても大勢に影響はない。

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

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

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

Windows SIDをUNIX UIDにマップする2番目の方法は、smb.conf中の idmap uididmap gidパラメーターを経由する 方法である。これらのパラメーターの情報についてはマニュアルページを参照のこと。リモート (非メンバーのWindowsクライアントあるいは外部ドメイン)SAMサーバーからのユーザーマッピング 時にはこれらのパラメーターは不可欠である。

分散マシン上の共通のUID/GIDマッピング

Samba は、分散ネットワーク環境中で、すべてのサーバー上で同一の UID と GID が使える 特別な機能を用意している。分散ネットワークとは、PDC が存在するもの、一つ以上の BDC があるもの、あるいは1つ以上のドメインメンバーサーバーがあるものである。なぜこれが 重要かというと、ファイルが1つ以上のプロトコル(たとえば NFS )で共有され、たとえば rsyncのようなツールを使って UNIX/Linux システム間で、ユーザーが ファイルをコピーすることがあるからである。

idmap backendと呼ばれるパラメーターを使って、 特別な機能を有効に出来る。このパラメーターの既定値は空の文字列である。 技術的に、LDAPベースのidmapバックエンドをUIDとGID向けに使うことは可能 であるが、SAMバックエンド用にLDAPの使用も行うネットワーク設定用にこれを 使う時にこれは最も意味を持つ。この設定については LDAP idmap バックエンドを使う設定例 にある。

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

[global]
idmap backend = ldap:ldap://ldap-server.quenya.org:636
# Alternatively, this could be specified as:
idmap backend = ldap:ldaps://ldap-server.quenya.org

LDAPバックエンドに重要な仕事をさせたいネットワーク管理者は、遅かれ 早かれPADLソフトウェアによって優れた功績を知ることになろう。 PADL http://www.padl.comはとても興味深い一連の ツールをオープンソースで作成し、公開している。これらのツールは 以下を含む:

  • nss_ldap:AIX、Linux、Solarisやその他のOS向けの ネイティブなネームサービスサポートを提供するLDAPネームサービススイッチ (NSS)モジュール。このツールはUID/GIDの一元的な格納と検索に使う ことができる。

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

  • idmap_ad:PADL Web サイト からの、Microsoftサービスのための、UNIX RFC2307スキーマを サポートするIDMAPバックエンド。

LDAPに関するコメント

現在の情報技術界で、多くの興奮と関心がLDAPディレクトリに向けられている。 LDAPアーキテクチャは高度に拡張性があるように設計された。また、広範囲な OSとプラットフォームを取り巻く、非常にたくさんのアプリケーションの潜在的 な領域をまたがって使うようにも設計されている。LDAP技術は会社全体のシングル サインオン(SSO)環境の基盤となる連携アイデンティティ管理(FIM)ソリューション の中心部をなしている(訳注:TivoliとかRSAでこのような製品がある様子)。

LDAPの実装は広範囲な種類のプラットフォームで構築されている。これは、 Microsoft Windows Active Directory(ADS)、NovellのeDirectoryやその他の もののの中心に位置する。LDAPによるディレクトリサービスの実装は、 新しい世代のアプリケーションと同様に古いものとも相互に関係し、 それらはすべて何らかの認証サービスに依存する。

UNIXのサービスは、ツールやユーティリティを介することによって、LDAPディレクトリ の情報を認証のために利用することが出来る。LDAPディレクトリ とミドルウェアのツールとユーティリティからなる統合環境により、すべての ユーザーが一元管理されたUNIXプラットフォームにアクセスすることが可能になる。 プラットフォームは、必要に応じて物理的に分散配置されてもよい。この機構の 恩恵を受けるアプリケーションとしては、UNIXログインシェル、メールとメッセージ システム、quota制御、印刷システム、DNSサーバー、DHCPサーバーやもちろんSambaも 含まれる。

多くのサイトが、Samba用に拡張性のあるpassdbバックエンドを提供するために、 まずはじめにLDAPをインストールする。その他はSamba SAMバックエンドのような 新しいユーザーのために存在するLDAPディレクトリに適合することが必要な場面に 直面する。Sambaに対する特別な必要性と魅力が何であっても、LDAPディレクトリ 構造とその実装のデザインに関する決定は、そのサイトの永続的な本質である。 これらは、長期にわたる情報システム管理コストに影響する広範囲な影響がある。

LDAPの展開を急いではならない。どのように、ディレクトリ情報ツリーが現在と 将来のサイトのニーズに影響するかのデザインを、それらが使える可能性と同じ ように理解する時間を取ること。SambaのSAM情報は、サイトからサイトに異なる DIT内に格納すべきであり、おのおのの実装において新しい経験が得られる。 最初の実装で目が覚め、2番目の実装では心配事が出来、三世代目でやっとうまく いくというのは、LDAPのベテランはよく理解していることである。

LDAPとSambaに対する注意

SambaはUNIX POSIX識別情報を、SambaとWindowsネットワーク環境に特有の 情報を格納する場所と同様に必要とする。取り扱われなければならない、 最もよく使われる情報はユーザーアカウント、グループアカウント、マシン 信頼アカウント、ドメイン間信頼アカウントとSamba内部で使う固有の中間 情報を含む。

この文書中の、展開ガイドラインは、他の本とインターネット上で公開されて いるHOWTO文書と同じように、出来上がっているディレクトリデザインと実装に 適合するわけではない。存在するDITは、共通のソース中で提案された単純な 情報レイアウトに適合することが出来ないかもしれない。更に追加すると、 Samba用に使われるLDAPディレクトリを提供するのに使われる共通スクリプトと ツールはあなたの要求に適合しないかもしれない。

これは一般的ではないが、存在するLDAP DITを持つサイトのために、サイト 固有のスクリプトとユーティリティ一式を作成する必要がある場合に、サイト 操作のスコープ内でSambaを供給することは可能である。DITを使ってユーザーと グループアカウントを配布する方法はこれをチャレンジングなことにさせる。 解決方法は、もちろん、価値があることであるが、それを行うための試行錯誤は チャレンジングである。サイトの要求を理解する時間を取り、急いで提供する ことは避けること。

上記から、サイトに適合しないスクリプトとツールをむやみやたらに使わないこと。 存在する基盤が、不適切なツールの不用意な使用によって被害を被らないことを 確実にするために、すべてのスクリプトを、それを実行する前に検査して検証すること。

LDAPディレクトリとWindowsのコンピューターアカウント

SambaはLDAPに対するターンキーソリューションを提供しない。Sambaとの統合の 前に、LDAPのデザインと設定を行う事は最も良いことである。LDAPの実用的な 知識はSambaの統合を容易にし、LDAPの知識がない場合には、いらいらした経験 しか得られない。

コンピューター(マシン)アカウントは、この章で説明されている、若干の制約を 受けるLDAPディレクトリサブジェクト中の好みの位置に配置できる。

コンピューター(マシン)アカウントのPOSIXとsambaSamAccountコンポーネントは、 両者ともSambaによって使われる。そのため、マシンアカウントは、Windows NT/200xが扱うのと同じ方法で、Samba内部で扱われる。ユーザーアカウントと マシンアカウントは、マシンアカウントが$文字で終わることを除いてお互い を識別できず、信頼アカウントも同じである。

有効なUNIX uidに結びつくWindowsのユーザー、グループ、マシン、信頼およびその他の アカウントの必要性は、遙か昔前のSambaの開発時に決められた。この決定が覆されたり 変更することは、Samba-3.x系列の間にはありそうもない。

Windows SIDからのUID解決はSambaが動作しているホストOSを参照しなければならない メカニズムによって、Samba内で行われる。NSSは、それが動いているすべてのホスト OSについて全部を知る必要があるということから、(Sambaのような)アプリケーション を隠蔽する良いメカニズムである。

SambaはNSS制御(設定)ファイル中のpasswdshadowgroup機能経由でホストOSが提供するUIDを問い合わせる。これを 達成するための最適なツールはUNIX管理者の決定にゆだねられている。それはSamba によっては強制されない。Sambaは1つの方法としてそのサポートライブラリとwinbindd を提供する。これをLDAP経由で行う事は可能で、すべてのアカウントエンティティが LDAPディレクトリ中にあることが可能なような適切なフックを提供する。

多くの人に対して、良い選択肢は、PADL nss_ldapライブラリを使うことである。 このユーティリティは、コンピューターアカウントがPOSIX/UNIXアカウントのUID に解決できるように設定されねばならない。これは基本的にLDAPのデザインの問題 である。Sambaメーリングリストとドキュメントで提供される情報は役に立つ例だけ を提供するようになっている。LDAPディレクトリのデザインは複雑な問題であり、 この文書の範囲外である。

アカウント管理ツール

Sambaはユーザーとマシンアカウントを管理するための2つのツールを提供する: smbpasswdpdbeditである。

pdbeditはSambaユーザーアカウント情報に加えてアカウントポリシーを 管理するために使うことが出来る。ポリシー管理機能は、パスワードのエージングと ログイン失敗の扱いの管理を行うドメインの既定値の設定を管理するために使われる。

何人かは、名前がSambaSAMAccount情報への格納メカニズムを参照しているために、 参照がsmbpasswd担っていることに困惑することがある。 しかし、これはユーティリティツールの名前でもある。このツールは結局、 netツールセット(Netコマンドを参照) という、新しく追加された新しい機能に取り替えられることになる。

smbpasswdツール

smbpasswdpasswdyppasswd プログラムに似たユーティリティである。これはpassdbバックエンド中の2つの32バイト パスワードフィールドを管理する。このユーティリティは実際のアカウントと、(smb.conf ファイル中の passdb backendによって指定される)パスワード 格納方式とは独立して動作する。

smbpasswdは、ユーザーのパスワードを変更する時に、ローカルのsmbd に接続する時にクライアント-サーバーモードで動作する。これは非常なメリットがある。

smbpasswdはWindows NT上のパスワードを変更する能力もある(これは NTドメインのユーザーのパスワードを変更する時に、NT PDCにその要求を送る時にのみ動作 する)。

smbpasswdは以下のように使うことが出来る:

  • ユーザーまたはマシンアカウントの追加

  • ユーザーまたはマシンアカウントの削除

  • ユーザーまたはマシンアカウントの有効化

  • ユーザーまたはマシンアカウントの無効化

  • ユーザーパスワードの削除

  • ドメイン間信頼アカウントの管理

通常のユーザーでsmbpasswdを実行するには、以下のように入力する:

$ smbpasswd
Old SMB password: secret

secretには、古いパスワードを入力するか、もしも 古いパスワードがなければ単にリターンキーのみを入力する。

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

もしも古い値が、このユーザーに対して格納されている現在の値と異なる場合か、 2つの新しい値が一致しない場合、パスワードは変更されない。

普通のユーザーによって起動された場合、コマンドはそのユーザーのみのSMBパスワード のみ変更できる。

rootで実行される場合、smbpasswdはSMBパスワードを変更 したいユーザー名をオプションの引数として指定できる。rootで実行される場合、 smbpasswdは古いパスワードの値をチェックするための プロンプトを出さないので、パスワードを忘れたユーザーのパスワードを設定できる。

smbpasswdは、passwdyppasswd コマンドを使っているUNIXユーザーに親しみやすい方法で動作するように設計されて いる。管理用として設計されているが、このツールは基本的なユーザーレベルの パスワード変更機能を提供する。

smbpasswd,の使い方の詳細は、マニュアルページ(最終的な 参照)を参照すること。

pdbeditツール

pdbeditはrootでのみ使えるツールである。これは、 ドメイン全体でのアカウントポリシーの設定のようにpassdbバックエンド を管理するのに使われる。pdbeditは以下のように使える:

  • ユーザーアカウントの追加、削除および変更。

  • ユーザーアカウントの表示。

  • ユーザーアカウントの移行(migrate)。

  • グループアカウントの移行。

  • アカウントポリシーの管理。

  • ドメインアクセスポリー設定の管理。

上場企業会計改革および投資家保護法(いわゆる米国SOX法)下で、アメリカの企業と 組織は一連の内部統制と伝達手段、記録、会計データの 保護を実施することが必要となった。米国SOX法はさらに以下の点についても影響 する:

  1. 財務データを格納する情報システムにだれがアクセスするかということ。

  2. どのように個人情報と会計情報が、従業員とビジネスパートナーとの間で扱われるかと言うこと。

  3. どのようにセキュリティの欠陥を管理するかと言うこと。

  4. すべての情報システムへのセキュリティとパッチレベル管理。

  5. どのように情報システムの変更が文書化され、追跡できるようになるかと言うこと。

  6. どのように情報アクセス制御が実装されて管理されているかと言うこと。

  7. 変更点とセキュリティに関するすべての情報システムの監査機能。

  8. プライバシーを確実にするための規律手順と制御。

手短に言うと、米国SOX法は、ビジネス関連の情報システムに関して責任を 強める道具である。特に会計データ処理と個人情報の記録に使われるすべての 情報システムのコンプライアンスを強化する。同様な責任は世界中で要求され ている。

政府の法律に従って情報システム操作を許可する Samba のツールと機能に 精通している必要性は明らかである。pdbeditは アカウントとシステムアクセス制御とポリシーを管理する能力を提供する 唯一の Samba ツールである。Samba シリーズの残存ライフサイクル中、 この重要な領域で新しいツールが実装されることはあり得る。

Sambaと比較した場合のWindows NT4で有効なドメイングローバルポリシー 制御はNT4 ドメイン対 Sambaポリシー制御 中にある。

Table 11.1. NT4ドメイン対Sambaポリシー制御

NT4ポリシー名

Sambaポリシー名

NT4 レンジ

Samba レンジ

Samba 既定値

Maximum Password Age(パスワード有効期間)

maximum password age

0 - 999 (日)

0 - 4294967295 (秒)

4294967295

Minimum Password Age(パスワード変更禁止期間)

minimum password age

0 - 999 (日)

0 - 4294967295 (秒)

0

Mimimum Password Length(最小パスワード長)

min password length

1 - 14 (文字)

0 - 4294967295 (文字)

5

Password Uniqueness(パスワード履歴)

password history

0 - 23 (#)

0 - 4294967295 (#)

0

Account Lockout - Reset count after(アカウントロックアウト期間)

reset count minutes

1 - 99998 (分)

0 - 4294967295 (分)

30

Lockout after bad logon attempts(ロックアウトの閾値)

bad lockout attempt

0 - 998 (#)

0 - 4294967295 (#)

0

*** Not Known ***

disconnect time

TBA

0 - 4294967295

0

Lockout Duration(ロックアウト閾値のリセット)

lockout duration

1 - 99998 (min)

0 - 4294967295 (min)

30

Users must log on in order to change password

user must logon to change password

0/1

0 - 4294967295

0

*** Registry Setting ***

refuse machine password change(マシンパスワード変更の禁止)

0/1

0 - 4294967295

0


pdbeditツールはアカウントセキュリティとポリシー 設定を管理できる唯一のツールである。これは、smbpasswdが出来ること と同様のことを含むスーパーセットである。

pdbeditの用途の中で特に重要なものの一つとして、 passdbバックエンドから他へのアカウント情報のインポート/エクスポート 機能がある。

ユーザーアカウントマネージャ

pdbeditツールはsmbpasswdツールと 同様、UNIX/Linuxシステムアカウントデータベース(バックエンド)中にすでに 存在するPOSIXユーザーアカウントを必要とする。システム管理者の責任と 考えられるので、ユーザーアカウントを作成するためにOSを呼び出すことは どちらのツールも行わない。NT4のドメインユーザーマネージャがアカウント を追加するために使われた時、Sambaは、ユーザー、グループ、マシンアカウント が正しく作成され、変更されることを行うために、(他のインタフェース スクリプトと同様)add user scriptを使う。 pdbeditツールを使用しても、それらのインタフェース スクリプトは使わない。

pdbeditを、ユーザーとマシンアカウントを管理 するために使うことを試みる前に、システム(POSIX)アカウントが すでに作成されているかを確かめておくこと。

ユーザーとマシンアカウントの表示

以下は、tdbsamパスワードバックエンド中に格納されているユーザーアカウント 情報の例である。表示は以下のコマンドを実行することで行える:

$ pdbedit -Lv met
UNIX username:        met
NT username:          met
Account Flags:        [U          ]
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

アカウントは古いsmbpasswd形式でも表示出来る:

root# pdbedit -Lw
root:0:84B0D8E14D158FF8417EAF50CFAC29C3:
     AF6DD3FD4E2EA8BDE1695A3F05EFBF52:[U          ]:LCT-42681AB8:
jht:1000:6BBC4159020A52741486235A2333E4D2:
     CC099521AD554A3C3CF2556274DBCFBC:[U          ]:LCT-40D75B5B:
rcg:1002:E95D4331A6F23AF8AAD3B435B51404EE:
     BB0F2C39B04CA6100F0E535DF8314B43:[U          ]:LCT-40D7C5A3:
afw:1003:1AAFA7F9F6DC1DEAAAD3B435B51404EE:
     CE92C2F9471594CDC4E7860CA6BC62DB:[T          ]:LCT-40DA501F:
met:1004:A2848CB7E076B435AAD3B435B51404EE:
     F25F5D3405085C555236B80B7B22C0D2:[U          ]:LCT-4244FAB8:
aurora$:1005:060DE593EA638B8ACC4A19F14D2FF2BB:
     060DE593EA638B8ACC4A19F14D2FF2BB:[W          ]:LCT-4173E5CC:
temptation$:1006:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX:
     A96703C014E404E33D4049F706C45EE9:[W          ]:LCT-42BF0C57:
vaioboss$:1001:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX:
     88A30A095160072784C88F811E89F98A:[W          ]:LCT-41C3878D:
frodo$:1008:15891DC6B843ECA41249940C814E316B:
     B68EADCCD18E17503D3DAD3E6B0B9A75:[W          ]:LCT-42B7979F:
marvel$:1011:BF709959C3C94E0B3958B7B84A3BB6F3:
     C610EFE9A385A3E8AA46ADFD576E6881:[W          ]:LCT-40F07A4

このコマンドが返すアカウント情報は、左から右に、以下の、コロンで 分離されたデータを含む:

  • ログインID。

  • UNIX UID。

  • Microsoft LanManagerパスワードハッシュ(パスワードは大文字に変換された後ハッシュされる)。

  • Microsoft NTパスワードハッシュ(大文字小文字の状態を保持したパスワードのハッシュ)。

  • Samba SAM アカウントフラグ。

  • LCTデータ(パスワード最終変更時刻)。

アカウントフラグパラメーターはpdbeditマニュアルページに 説明があり、 アカウントフラグ管理の節 で簡単に説明されている。

LCTデータは8桁の16進値で、最後にパスワードが変更された時刻の、 1970年1月1日からの値を保持している。

ユーザーアカウントの追加

pdbeditは、スタンドアロンサーバーまたはドメインに ユーザーアカウントを追加する時に使える。ここで紹介する例では、 vlaanというユーザーのアカウントが、SambaSAMAccount を追加する前に作成されている。

root#  pdbedit -a vlaan
new password: secretpw
retype new password: secretpw
Unix username:        vlaan
NT username:          vlaan
Account Flags:        [U          ]
User SID:             S-1-5-21-726309263-4128913605-1168186429-3014
Primary Group SID:    S-1-5-21-726309263-4128913605-1168186429-513
Full Name:            Victor Laan
Home Directory:       \\frodo\vlaan
HomeDir Drive:        H:
Logon Script:         scripts\logon.bat
Profile Path:         \\frodo\profiles\vlaan
Domain:               MIDEARTH
Account desc:         Guest User
Workstations:
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:    Wed, 29 Jun 2005 19:35:12 GMT
Password can change:  Wed, 29 Jun 2005 19:35:12 GMT
Password must change: Mon, 18 Jan 2038 20:14:07 GMT
Last bad password   : 0
Bad password count  : 0
Logon hours         : FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF

アカウントの削除

以下のコマンドを実行することで、SambaSAMAccountデータベースから アカウントを削除できる。

root#  pdbedit -x vlaan

アカウントは出力結果なしで削除される。アカウントはSambaSAMAccount (passdb バックエンド)データベースからのみ削除され、UNIXアカウント バックエンドからは削除されない。

アカウントを削除するためにNT4ドメインユーザーマネージャを使うと、 delete user scriptを起動するが、それは pdbeditツールではない。

ユーザーアカウントの変更

pdbeditマニュアルページにこのツールで有効な すべての操作の完全な詳細が記述されている。

下記は、ユーザーアカウント情報の、フルネーム情報を変更する例である:

root#  pdbedit -r --fullname="Victor Aluicious Laan" vlaan
...
Primary Group SID:    S-1-5-21-726309263-4128913605-1168186429-513
Full Name:            Victor Aluicious Laan
Home Directory:       \\frodo\vlaan
...

ユーザーのパスワードが満了して、ユーザーがパスワードを変更できなくなった を仮定してみよう。そのアカウントと本来のパスワードで作業が出来るように するには、ユーザーに追加の猶予時間が必要かもしれない。これは、どのように パスワード満了の設定を更新できるかの例を示している。

root#  pdbedit -Lv vlaan
...
Password last set:    Sun, 09 Sep 2001 22:21:40 GMT
Password can change:  Thu, 03 Jan 2002 15:08:35 GMT
Password must change: Thu, 03 Jan 2002 15:08:35 GMT
Last bad password   : Thu, 03 Jan 2002 15:08:35 GMT
Bad password count  : 2
...

ユーザーは2回ログオンに失敗し、次でアカウントがロックされるが、 パスワードはすでに満了している。以下で、どのようにこのアカウントを リセットするかを示す。

root#  pdbedit -z vlaan
...
Password last set:    Sun, 09 Sep 2001 22:21:40 GMT
Password can change:  Thu, 03 Jan 2002 15:08:35 GMT
Password must change: Thu, 03 Jan 2002 15:08:35 GMT
Last bad password   : 0
Bad password count  : 0
...

Password must change:パラメーターは以下のようにして リセットする:

root#  pdbedit --pwd-must-change-time=1200000000 vlaan
...
Password last set:    Sun, 09 Sep 2001 22:21:40 GMT
Password can change:  Thu, 03 Jan 2002 15:08:35 GMT
Password must change: Thu, 10 Jan 2008 14:20:00 GMT
...

別の方法として、このツールで日付を設定する方法もある:

root#  pdbedit --pwd-must-change-time="2010-01-01" \
              --time-format="%Y-%m-%d" vlaan
...
Password last set:    Sun, 09 Sep 2001 22:21:40 GMT
Password can change:  Thu, 03 Jan 2002 15:08:35 GMT
Password must change: Fri, 01 Jan 2010 00:00:00 GMT
...

時刻の形式についての情報は、strptimeマニュアルページを参照のこと。

SambaSAMAccountの操作に関するさらなる情報はpdbeditのマニュアルページ を参照のこと。

アカウントフラグ管理

Samba SAMアカウントフラグはSambaソースコード中で、ACB (account control block)と呼ばれている。Sambaソースコードの一部では、 これらはaccount encode_bitsやaccount control flagsとしても参照される。

手動での、ユーザー、マシン(ワークステーションまたはサーバー)、あるいは ドメイン間信頼アカウントのアカウントフラグの調整は、通常Sambaを 使用している場合には必要ない。別の観点からすると、何らかの理由で この情報が壊れた場合、壊れたデータの修正ができる可能性があると便利で ある。そのような修正のためのツールの選択枝はpdbedit ユーティリティである。

固有のSamba管理ツールを作成する開発者からアカウントフラグの情報に関する いくつかの要求があった。アカウントフラグの適切な管理に関する必要な情報 例は、LDAPディレクトリを管理するためのスクリプトの開発時に明白である。

アカウントフラグフィールドは最大16文字である。現在11個が使われている。 Samba SAM Accountコントロールブロックフラグ に一覧がある。pdbeditコマンドによって指定されたフラグの 順番に意味はない。実際、LDAPディレクトリ中のSambaAcctFlagsレコード中を どのような順番にしても問題はない。

Table 11.2. Samba SAM Accountコントロールブロックフラグ

フラグ説明
Dアカウントが無効。
Hホームディレクトリが必要。
Iドメイン間信頼アカウント。
Lアカウントが自動ロックされている。
MMNS (Microsoft network service)ログオンアカウント。
Nパスワードが不要。
Sサーバー信頼アカウント。
T一時的な重複アカウントエントリ。
U通常のユーザーアカウント。
Wワークステーション信頼アカウント。
Xパスワードは満了していない。

アカウントコントロールフラグを設定するためのpdbedit 使用例は以下の通り:

root#  pdbedit -r -c "[DLX]" jht
Unix username:        jht
NT username:          jht
Account Flags:        [DHULX      ]
User SID:             S-1-5-21-729263-4123605-1186429-3000
Primary Group SID:    S-1-5-21-729263-4123605-1186429-513
Full Name:            John H Terpstra,Utah Office
Home Directory:       \\aurora\jht
HomeDir Drive:        H:
Logon Script:         scripts\logon.bat
Profile Path:         \\aurora\profiles\jht
Domain:               MIDEARTH
Account desc:         BluntObject
Workstations:
Logon time:           0
Logoff time:          Mon, 18 Jan 2038 20:14:07 GMT
Kickoff time:         0
Password last set:    Sun, 03 Jul 2005 23:19:18 GMT
Password can change:  Sun, 03 Jul 2005 23:19:18 GMT
Password must change: Mon, 18 Jan 2038 20:14:07 GMT
Last bad password   : 0
Bad password count  : 0
Logon hours         : FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF

以下を実行することでフラグを既定値に設定できる:

root#  pdbedit -r -c "[]" jht
Unix username:        jht
NT username:          jht
Account Flags:        [U          ]
User SID:             S-1-5-21-729263-4123605-1186429-3000
Primary Group SID:    S-1-5-21-729263-4123605-1186429-513
Full Name:            John H Terpstra,Utah Office
Home Directory:       \\aurora\jht
HomeDir Drive:        H:
Logon Script:         scripts\logon.bat
Profile Path:         \\aurora\profiles\jht
Domain:               MIDEARTH
Account desc:         BluntObject
Workstations:
Logon time:           0
Logoff time:          Mon, 18 Jan 2038 20:14:07 GMT
Kickoff time:         0
Password last set:    Sun, 03 Jul 2005 23:19:18 GMT
Password can change:  Sun, 03 Jul 2005 23:19:18 GMT
Password must change: Mon, 18 Jan 2038 20:14:07 GMT
Last bad password   : 0
Bad password count  : 0
Logon hours         : FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF

ドメインアカウントポリシー管理

設定されているドメインアカウントアクセスポリシーを見るためには以下を実行する:

root#  pdbedit -P ?
No account policy by that name
Account policy names are :
min password length
password history
user must logon to change password
maximum password age
minimum password age
lockout duration
reset count minutes
bad lockout attempt
disconnect time
refuse machine password change

ドメインに対する以下の制御を確立するとする:

  1. min password length = 8 characters.

  2. password history = last 4 passwords.

  3. maximum password age = 90 days.

  4. minimum password age = 7 days.

  5. bad lockout attempt = 8 bad logon attempts.

  6. lockout duration = forever, account must be manually reenabled.

以下のコマンドでこれらの設定を実行する:

root#  pdbedit -P "min password length" -C 8
account policy value for min password length was 5
account policy value for min password length is now 8
root#  pdbedit -P "password history" -C 4
account policy value for password history was 0
account policy value for password history is now 4
root#  pdbedit -P "maximum password age" -C 7776000
account policy value for maximum password age was 4294967295
account policy value for maximum password age is now 7776000
root#  pdbedit -P "minimum password age" -C 7
account policy value for minimum password age was 0
account policy value for minimum password age is now 7
root#  pdbedit -P "bad lockout attempt" -C 8
account policy value for bad lockout attempt was 0
account policy value for bad lockout attempt is now 8
root#  pdbedit -P "lockout duration" -C -1
account policy value for lockout duration was 30
account policy value for lockout duration is now 4294967295

Note

最大(無限)なロックアウト時間を設定するためには値として-1を使用する。

Warning

アカウントポリシーは各 PDC と BDC 上で個別にに設定する必要がある。この時点 (Samba 3.0.11からSamba3.0.14a)で、アカウントポリシーは自動的に複製されない。 これはSamba3.0.20がリリースされるか、それより少し後に修正される予定である。 Samba リリースファイル中の、この機能に関する特定の更新情報がある WHATSNEW.txt ファイルをチェックしてみること。

アカウントのインポート/エクスポート

pdbeditツールはあるバックエンドからほかのものに 認証情報(アカウント)データベースのインポート/エクスポートができる。 例えば、古いsmbpasswdデータベースから tdbsamバックエンドにアカウントをインポート/ エクスポートするためには以下のように行う:

  1. root# pdbedit -i smbpasswd -e tdbsam
    

  2. smb.conf中のpassdb backendの設定を smbpasswdからtdbsamに 置き換える。

パスワードバックエンド

平文

古いバージョンのSambaではUNIXユーザーデータベースからユーザー情報を検索し、 結局いくつかの他のフィールドは/etc/samba/smbpasswd/etc/smbpasswdファイルから得ていた。パスワードの 暗号化が無効になっている時、SMB固有のデータは全く格納されない。その代わり、 すべての操作はSambaホストOSがその/etc/passwd データベースによってアクセスする方法経由で制御される。ほとんどのLinux システムでは、たとえば、すべてのユーザーとグループの解決はPAM経由で行われる。

smbpasswd: 暗号化したパスワードデータベース

伝統的にencrypt passwords = yes とSambaのsmb.confファイル中で設定した時、ユーザー名、LM/NTパスワード ハッシュ、パスワード変更時間とアカウントフラグのようなユーザーアカウント 情報はsmbpasswd(5)ファイルに格納される。これは、 たくさんのユーザー(数千くらい)を抱えるサイトに対するアプローチとしては 不利である。

  • 最初の問題は、すべての検索をシーケンシャルに行わなければならないという ことである。ドメインログオン時におおよそ二つの検索(1つは最初のログオン 検証で、もう1つはセッション接続セットアップで、それはネットワーク ドライブやプリンターのマッピング)が行われ、これは、大きなサイトでは、 性能のボトルネックになる。この場合必要なことは、データベースを使う ような、インデックスを使うアプローチである。

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

  • 最後に、smbpasswdエントリ中に格納されている情報の量には、たとえば ホームディレクトリ、パスワード満了時刻や相対識別子(RID)のような 追加の属性を入れる領域がない。

上記のような機能不足の点から、ユーザー属性を格納するより堅牢な手段を smbdによって使うことが開発されてきた。ユーザーアカウントにアクセス することを定義するAPIは、共通的にsamdbインタフェースとして参照される (以前には、これはpassdb APIとして呼ばれていて、現在もSambaソース コード中ではそのように名前が付けられている)。

Sambaは、Samba平文データベースの機能不足点を克服する一連の拡張された passdbバックエンドを提供している。これらはtdbsamとldapsamである。 もちろん、ldapsamは、大きな会社や巨大サイトが興味を持つものである。

tdbsam

SambaはTDB(trivial database)中にユーザーとマシンアカウント を格納できる。このバックエンドを使う時には追加の設定は不要である。 このバックエンドはLDAPを必要としない、新しくインストールする場合に 推奨される。

一般的なガイドとして、Sambaチームは250人あるいはそれ以上のユーザーが いるサイトに、tdbsamバックエンドを使うことを推奨していない。さらに 追加で、tdbsamは、アカウントデータベースを複製することが要求される PDC/BDC実装を要求するサイト中で使うための拡張性の能力はない。 明確にいうと、拡張性という理由で、ldapsamを使用すべきである。

250ユーザー制限は、純粋に、一般的に、おそらく一つ以上の物理配置 にまたがってばらけている、ルーティングネットワークを持つサイトを必要 とするという概念に基づく目安でしかない。Sambaチームは現時点で、tdbsam アーキテクチャのパフォーマンスベースの拡張性制限を把握していない。

数千のユーザーを抱えているが、1台のサーバーだけを必要とするサイトがある。 1つのサイトは最近UNIXシステム上で4500ユーザーを保持していることを報告し、 tdbsampassdbバックエンドでよい性能が出たことを 報告した。tdbsampassdbバックエンドを使う場合の制限は、 TDB格納場所の制限に関連し、それはSambaSAMAccountバックエンドのための 分散メカニズムの必要性にのみ基づく。

ldapsam

ldapsamが提供しないいくつかの弱点がある。この文書で参照されるLDAP サポートは以下を含まない:

  • Windows 200x Active Directoryサーバーからの ユーザーアカウント情報を検索する手段。

  • /etc/passwdを置き換える手段。

2番目の項目はLDAP NSSとPAMモジュールを使うことにより達成できる。LGPL バージョンのそれらのライブラリは PADL Softwareで作成されて いる。これらのパッケージに着いてのより詳細な情報は、 Gerald CarterによるLDAP, System Administration の第6章、NISを置き換えるを参照のこと。

このドキュメントでは、伝統的にsmbpasswd(5)ファイルに格納されている Sambaユーザーアカウント情報をLDAPディレクトリに格納するための使い方に ついて説明している。読者はすでに基本的なLDAPの概念とすでにインストール している動作中のディレクトリサーバーを持っていることを仮定している。 LDAPのアーキテクチャとディレクトリについてのより詳細な情報は、以下の サイトを参照してほしい:

有効に使える2つのSambaリソースは以下の通り:

  • The Samba-PDC-LDAP-HOWTO Ignacio Coupeauによって管理されている。

  • IDEALXからのNTマイグレーション スクリプトは、Samba-LDAPドメインコントローラー構成でユーザーとグループの 管理に関連づけるものである。Idealxはsmbldap-toolsと対話的な コンソール管理ツールも作成している。

サポートしているLDAPサーバー

LDAPのldapsamコードはOpenLDAP 2.xサーバーとクライアントライブラリを 使って開発とテストが行われている。同じコードはNetscape's Directory Server とクライアントSDKでも動作する。しかし、それらはコンパイルエラーとバグが 必ず生じる。それらを直すのはとても難しい。 バグ報告中で概要が説明されている手順 経由で修正を投稿してほしい。

Sambaは任意の標準準拠のLDAPサーバーとともに動作できる。

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

Samba-3.0はソースコードディストリビューション中の examples/LDAP/samba.schema中にある OpenLDAP 2.x用に必要なスキーマファイルを用意している。 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は 補助型オブジェクトクラスであるので、LDAP ディレクトリ中の存在するユーザーアカウント情報に付随するものとして 使うことが出来、Sambaアカウントの操作のために必要な情報を提供する。 しかし、RFC2307で定義されているposixAccountオブジェクトクラスと 重複するいくつかのフィールド(たとえばuid)がある。これは意図的なものである。

すべてのユーザーアカウント情報(UNIXとSamba)をディレクトリ中に格納する ために、sambaSamAccountとposixAccountオブジェクトクラスを組み合わせて 使う必要がある。しかし、smbdはそれでもgetpwnam() のような標準Cライブラリコール経由でユーザーのUNIXアカウント情報を、 得ることがある。これは、SambaサーバーはLDAP NSSライブラリのインストールと 正しく動くための設定も必要とすることを意味する。このように情報を区分することで、 すべてのSambaアカウント情報をLDAP中に格納することが出来るようにするが、 ネットワークが完全なLDAP基盤に移行しながら、UNIX のアカウント情報は NISで管理することができる。

OpenLDAPの設定

OpenLDAPディレクトリサーバー中でsambaSamAccountのサポートを行うためには、 最初にsamba.schemaファイルをslapdの設定ディレクトリにコピーする。 samba.schemaファイルはSambaソースディストリビューション中の examples/LDAPディレクトリ中にある。

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

次に、slapd.conf中にsamba.schema ファイルを含める。sambaSamAccountオブジェクトは他のスキーマファイルに 依存する2つの属性を含んでいる。uid属性は cosine.schema中で定義され、 displayName属性は 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

## uncomment these if you are storing posixAccount and
## posixGroup entries in the directory as well
##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エントリなど):

# Organization for Samba Base
dn: dc=quenya,dc=org
objectclass: dcObject
objectclass: organization
dc: quenya
o: Quenya Org Network
description: The Samba Network LDAP Example

# Organizational Role for Directory Management
dn: cn=Manager,dc=quenya,dc=org
objectclass: organizationalRole
cn: Manager
description: Directory Manager

# Setting up container for Users OU
dn: ou=People,dc=quenya,dc=org
objectclass: top
objectclass: organizationalUnit
ou: People

# Setting up admin handle for People OU
dn: cn=admin,ou=People,dc=quenya,dc=org
cn: admin
objectclass: top
objectclass: organizationalRole
objectclass: simpleSecurityObject
userPassword: {SSHA}c3ZM9tBaBo9autm1dL3waDS21+JSfQVz
# Setting up container for groups
dn: ou=Groups,dc=quenya,dc=org
objectclass: top
objectclass: organizationalUnit
ou: Groups

# Setting up admin handle for Groups OU
dn: cn=admin,ou=Groups,dc=quenya,dc=org
cn: admin
objectclass: top
objectclass: organizationalRole
objectclass: simpleSecurityObject
userPassword: {SSHA}c3ZM9tBaBo9autm1dL3waDS21+JSfQVz

# Setting up container for computers
dn: ou=Computers,dc=quenya,dc=org
objectclass: top
objectclass: organizationalUnit
ou: Computers

# Setting up admin handle for 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を使って 生成する必要がある。

以下のコマンドでLDAPデータベース中にLDIFの内容をロードする。

$ slapadd -v -l initldap.dif

adminパスワードと同様に、アクセス制御リストを十分に使ってLDAPサーバーの 安全性を確保することを忘れないこと。

Note

Samb aが LDAP サーバーにアクセスできる前に、Samba の secrets.tdbデータベース中に LDAP admin パスワード を以下のようにして格納する必要がある:

root# smbpasswd -w secret

Sambaの設定

以下のsmb.conf中のパラメーターは、SambaがLDAPサポートを出来るように 構築された場合にのみ有効である。Sambaは、LDAPライブラリを見つけると、 自動的にLDAPをサポートするように構築する。LDAPをサポートしているか 否かを調べる最も良い方法は以下の通り:

root#  smbd -b | grep LDAP
   HAVE_LDAP_H
   HAVE_LDAP
   HAVE_LDAP_DOMAIN2HOSTLIST
   HAVE_LDAP_INIT
   HAVE_LDAP_INITIALIZE
   HAVE_LDAP_SET_REBIND_PROC
   HAVE_LIBLDAP
   LDAP_SET_REBIND_PROC_ARGS

もしも使用したsmbdコマンドがHAVE_LDAP_H を出力しない場合、なぜLDAPヘッダーとライブラリがコンパイル中に見つから なかったかということを調べる必要がある。

LDAP関連のsmb.confオプションは以下の通り:

passdb backend = ldapsam:url

これらはsmb.confマニュアルページに説明があり、ここでは繰り返さない。 しかし、LDAPディレクトリを使うための例は LDAP使用の設定例にある。

Example 11.2. LDAP使用の設定例

[global]
security = user
encrypt passwords = yes
netbios name = MORIA
workgroup = NOLDOR
# LDAP関連のパラメーター:
# LDAPサーバーにバインドする時に使うDNの定義。
# smb.conf中にはこのDNのパスワードは格納されない。
# これは'smbpasswd -w secret'を使って
# secrets.tdbファイル中にパスフレーズを格納する。
# "ldap admin dn"を変更する場合、再設定する必要がある。
ldap admin dn = "cn=Manager,dc=quenya,dc=org"
# ディレクトリに接続ときのSSLオプションを設定する:
# ('off', 'start tls', または 'on' (既定値))
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
# マシンとユーザーサフィックスはベースサフィックスに追加される
# 引用符なしで記述すること。未定義状態が既定値である
ldap user suffix = ou=People
ldap group suffix = ou=Groups
ldap machine suffix = ou=Computers
# LDAP中の信頼UNIXアカウント情報
# (詳細はsmb.confマニュアルページを参照)
# ディレクトリを検索する時に使うベースDNの指定
ldap suffix = dc=quenya,dc=org

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

ユーザーアカウントはsambaSamAccountオブジェクトクラスを通じて管理 されるため、使っている管理ツールをsambaSamAccount属性を扱えるよう に修正する必要がある。

マシンアカウントはsambaSamAccountオブジェクトクラスを使って管理 されるため、ユーザーアカウントと同じように扱われる。しかし、これらの アカウントをLDAP名前空間の異なったツリーに格納することはそれも 可能である。グループを格納するために、 ou=Groups,dc=quenya,dc=orgを使うべきであり、 ユーザーのためにou=People,dc=quenya,dc=orgを 使うべきである。NSSとPAMの設定をそれに合わせて設定すること (通常は、/etc/openldap/sldap.conf設定 ファイル中で設定する)。

Samba では、グループ管理システムは POSIX グループをベースにして いる。これは、Samba は posixGroup オブジェクトクラスを使うという ことを意味する。今の所、NT 風のグループシステム管理はない( グローバルとローカルグループという)。Samba は Domain Groupsのみを認識し、Microsoft Windows 2000と Active Directoryとは異なり、Samba はネスト されたグループをサポートしない。

セキュリティとsambaSamAccount

ディレクトリ中のsambaSAMAccountエントリについてのセキュリティに関する 議論の際に覚えておかなければならない2つの重要な観点がある。

  • 絶対にSambaLMPasswordか SambaNTPasswordの属性値を暗号化されていないLDAPセッション下で検索しない。

  • 絶対に管理者以外のユーザーに SambaLMPasswordかSambaNTPasswordの属性値を閲覧させない。

これらのパスワードハッシュは平文と同等であり、オリジナルの平文 文字列を得ないでもユーザーを詐称するために使える。LM/NTハッシュ についてのより詳細な情報は、この章の アカウント情報データベース を参照のこと。

最初のセキュリティ問題に対応するため、ldap ssl smb.confパラメーターは、ディレクトリサーバーに接続する際に、 既定値のポート636を使う暗号化セッション (ldap ssl = on)を既定値で 要求する。OpenLDAPサーバーを使う場合、LDAPSを指定する場所で、 StartTLS LDAP拡張操作を使うことが可能である。この場合、安全な 通信プロトコルを使うことを強く推奨する(そのため、 ldap ssl = offを設定しては ならない)。

LDAPSプロトコルはLDAPv3 StartTLS拡張オプションが優先されるので、非推奨 であることに注意。しかし、OpenLDAPライブラリは引き続きクライ アントとサーバー間の古い安全な通信方法をサポートする。

次の安全対策は、管理者以外がディレクトリからパスワードハッシュを 得ることを防ぐことである。これはslapd.conf 中に以下のACLを設定することで行える:

## "ldap admin dn" アクセスは許可するがそれ以外は拒否
access to attrs=SambaLMPassword,SambaNTPassword
     by dn="cn=Samba Admin,ou=People,dc=quenya,dc=org" write
     by * none

sambaSamAccountsのための特別なLDAP属性

sambaSamAccountオブジェクトクラスは以下の表にあるような属性の集合である: Part APart B

Table 11.3. Attributes in the sambaSamAccountのオブジェクトクラス(LDAP), Part A

sambaLMPassword16進文字列表現で格納されているLanManパスワードの16バイトハッシュ値。
sambaNTPassword16進文字列表現で格納されているNTパスワードの16バイトハッシュ値。
sambaPwdLastSetsambaLMPasswordsambaNTPasswordが 最後に設定された時刻の、1970年からの経過秒数(整数値)。
sambaAcctFlags大カッコ[]で囲まれた11文字の文字列で、U(ユーザー)、W(ワークステーション)、 X(パスワード満了なし)、I(ドメイン信頼アカウント)、H(ホームディレクトリが必要)、 S(サーバー信頼アカウント)とD(無効)のようなアカウントフラグが格納。
sambaLogonTime未使用(整数値)。
sambaLogoffTime未使用(整数値)。
sambaKickoffTimeユーザーがロックされてログインできなくなる時刻(UNIX時刻形式)を指定。 もしも属性が省略された場合、アカウントは決して満了しない。この 属性をshadowAccountオブジェクトクラスのshadowExpire属性と一緒に 使うことで正確な日時で完全にアカウントを満了できる。
sambaPwdCanChangeユーザーにパスワード変更が許可されている時刻(UNIX時刻形式)。 もしもこの属性が設定されていない場合、ユーザーは任意の時刻に パスワードを変更できる。
sambaPwdMustChangeパスワードを強制的に変更しなければならない時刻(UNIX時刻形式)。 もしもこの値が0ならば、ユーザーは最初のログイン時にパスワードを変更 しなければならない。この属性が設定されていない場合、パスワードは 決して満了しない。
sambaHomeDrivesambaHomePathによって指定されるUNCパスにマップされるドライブ 名を指定。ドライブ名はXがマップするドライブ名である、 X:という形式で指定する必要がある。 smb.conf(5)マニュアルページ中のlogon drive パラメーターにある詳細を参照のこと。
sambaLogonScriptsambaLogonScriptプロパティは、.CMD, .EXE, や .BATファイルの ようなユーザーのログオンスクリプトのパスを指定する。文字列は空 でもよい。パスはnetlogon共有からの相対パスである。詳細な情報は、 smb.confマニュアルページのlogon script パラメーターを参照のこと。
sambaProfilePathユーザーのプロファイルのパスを指定。この値は空、ローカル な絶対パス、あるいはUNCパスが使える。詳細な情報は、smb.conf マニュアルページのlogon pathパラメーター を参照のこと。
sambaHomePathユーザーのホームディレクトリのパスを指定するsambaHomePath プロパティ。この値は空でも良い。もしもsambaHomeDriveが 設定され、ドライブ名の場合、sambaHomePathはUNCパスである 必要がある。パスは\\server\share\directory のようなネットワークUNCパスでなければならない。詳細な情報は、 smb.confマニュアルページのlogon home パラメーターを参照のこと。

Table 11.4. sambaSamAccountオブジェクトクラスの属性, Part B

sambaUserWorkstationsユーザーのログイン可能な、カンマで分離されたマシンのリスト。 Sambaドメインメンバーに接続することを試みる時に問題が発生する かもしれない。なぜならば、ドメインメンバーがこのリストになく、 ドメインコントローラーはそれを拒否するため。この属性が省略された 場合、既定値は何の制限がないことを仮定する。
sambaSIDユーザーのセキュリティ識別子(SID)。WindowsにおけるUNIX UID相当のもの。
sambaPrimaryGroupSIDユーザーのプライマリグループのセキュリティ識別子(SID)。
sambaDomainNameユーザーが属するドメイン。

これらのパラメーターの大多数はSambaがドメイン (どのようにSambaをPDCとして設定するかについての詳細がある ドメイン制御を参照)として振る舞う 時にのみ使われる。以下の4つの属性は、値が既定値でない場合にのみ sambaSamAccountエントリに格納される。

  • sambaHomePath

  • sambaLogonScript

  • sambaProfilePath

  • sambaHomeDrive

これらの属性は、値が既定値でない場合にのみsambaSamAccountに 格納される。例えば、MORIAがPDCとして設定され、そのsmb.conf ファイル中でlogon home = \\%L\%u が定義されているとする。beckyという名前のユーザーが がドメインにログオンした時にはlogon home 文字列は\\MORIA\beckyに展開される。もしも、smbHome属性が uid=becky,ou=People,dc=samba,dc=orgエントリ中に 存在するならば、この値が使われる。しかし、もしもこの属性が存在 しない場合、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 以降のバージョンは、アカウントとして格納される非 Samba(LDAP) パスワード を更新できる。pam_ldap を使う場合、UNIX と Windows パスワードを同時に変更できる。

ldap passwd syncオプションでは、 設定可能なldap passwd sync の値にある値を使うことが出来る。

Table 11.5. 設定可能なldap passwd syncの値

説明
yes

ユーザーがパスワード変更時に SambaNTPassword, SambaLMPasswordpasswordフィールドを更新する。

no

SambaNTPasswordSambaLMPasswordのみ更新する。

only

LDAPパスワードとLDAPサーバーに他の フィールドについても更新を行う。このオプションはいくつかのLDAP サーバーと、LDAPサーバーがLDAP_EXOP_X_MODIFY_PASSWDをサポートする 時のみ有効である。


より詳細な情報は smb.conf マニュアルページにある。

パスワード同期のためのOpenLDAPオーバーレイの使用

Howard Chuは、smbk5pwdという特別なオーバーレイを書いた。 このツールは、LDAP_EXOP_X_MODIFY_PASSWD操作が実行される時に、 OpenLDAPエントリ中のSambaNTPassword, SambaLMPasswordHeimdalハッシュを 変更する。

オーバーレイはOpenLDAP-2.3に含まれ、 contrib/slapd-modules/smbk5pwdサブディレクトリ にある。このモジュールはOpenLDAPでも使える。

よくあるエラー

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

Sambaをインストールしたが、UNIXアカウントを使ってログオンできない!

現在のpassdb backendにユーザーが追加されて いるかを確認すること。詳細は アカウント管理ツールを読むこと。