目次
3つのpassdbバックエンドがSambaチームで完全なメンテナンスが行われており、それは以下である:
smbpasswd
(旧式)、tdbsam
(tdbベースのバイナリファイル
形式)とldapsam
(LDAP)。もちろん、ldapsam
バックエンド
のみが、POSIX(UNIX)とSambaのユーザーとグループアカウント情報を単一のリポジトリに格納できる。
smbpasswd
とtdbsam
バックエンドは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クライアントにより
課されるプロトコルの制約も同様に適用される。平文パスワードの使用に
関する制約に関する詳細情報は、
技術情報の項を参照のこと。
このオプションは、Microsoft Windows LanMan と NT の暗号化パスワード
及び一部のアカウント情報を格納するフィールドを含む平文ASCII(テキスト)
レイアウトを維持するsmbpasswd
ファイルの継続的
使用を可能にする。この種のパスワードバックエンドは、Microsoft
Windows NT4/200xサーバーと包括的な相互運用を行うために必要な拡張
コントロールを提供するための、Microsoft Windows NT/200x SAM
(Security Account Manager)情報を一切格納しない。
このバックエンドは、Samba のより古いバージョンとの下位互換性のために のみ使用するべきである。将来のリリースでは、切り捨てられていくかもしれない。
Samba では多数の新しいパスワードバックエンド機能が導入された。
このバックエンドは、ローカルサーバーに、リッチなデータベースバックエンドを 提供する。このバックエンドは、複数のドメインコントローラー(つまり、PDC+ 一つ以上のBDCをインストールしている場合には適さない。
tdbsamパスワードバックエンドは古い smbpasswd情報のほかに、拡張された Microsoft Windows NT/200x の SAM 情報をバイナリ形式のTDB(trivial database) ファイルに格納する。拡張情報を含むことで、Samba が、Microsoft Windows NT4/200x ベースのシステムと同様のアカウントアクセス及びシステムアクセス制御を実現する ことを可能にする。
tdbsamを入れたのは、OpenLDAPを稼動する伴う 複雑性と、その間接費用を発生させずに、シンプルななサイト運用を 可能にしたいというユーザーからの要求にに直接応えるためである。これは、 ユーザー数250未満のサイトにのみ推奨する。これより大規模のサイト、 または実装では、OpenLDAP の使用またはActive Directoryへの統合を強く 推奨する。
これは、分散アカウントを導入している場合に、リッチなディレクトリバックエンド を提供する。
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
のマニュアルページを参照のこと。
SIDのUIDへの解決は、Samba の適正運用の根幹を成す。以下の両例で、winbinddが 稼動していないか、あるいは、接続できない状況のとき、ローカルのSID/UID解決 のみが可能である。SIDのUIDへの解決 およびUIDのSIDへの解決の図を参照のこと。
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
下記のバージョンのMicrosoft Windowsは、ドメインセキュリティのプロトコルを完全にサポートしている。
Windows NT 3.5x.
Windows NT 4.0.
Professional と名の付く Windows エディション
Server/Advanced Server と名の付く Windows エディション
Microsoft SMB/CIFS クライアントの現在のリリース版は全て、ここに説明するSMBの チャレンジ/ レスポンス認証の仕組みをサポートしている。平文認証を有効化しても、 クライアントが暗号化による認証に参加する能力を無効化するわけではない。そうではなく、 クライアントが平文でも暗号化でもどちらのパスワード認証方式にも対応できるようにする。
Microsoft Windowsのクライアントは、暗号化されたパスワードのみキャッシュする。 レジストリの変更により、平文パスワードが再度有効化されても、平文パスワードは キャッシュされない。このことは、ネットワーク接続が切れた場合、 キャッシュされた (即ち暗号化された)パスワードのみがリソースサーバーに送られて、自動再接続を実行する ために使用されるということを意味する。リソースサーバーが暗号化された パスワードを サポートしていない場合、自動再接続はできない。暗号化されたパスワードの使用を強く 推奨する。
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 uidとidmap gidパラメーターを経由する
方法である。これらのパラメーターの情報についてはマニュアルページを参照のこと。リモート
(非メンバーのWindowsクライアントあるいは外部ドメイン)SAMサーバーからのユーザーマッピング
時にはこれらのパラメーターは不可欠である。
Samba は、分散ネットワーク環境中で、すべてのサーバー上で同一の UID と GID が使える
特別な機能を用意している。分散ネットワークとは、PDC が存在するもの、一つ以上の
BDC があるもの、あるいは1つ以上のドメインメンバーサーバーがあるものである。なぜこれが
重要かというと、ファイルが1つ以上のプロトコル(たとえば NFS )で共有され、たとえば
rsync
のようなツールを使って UNIX/Linux システム間で、ユーザーが
ファイルをコピーすることがあるからである。
idmap backend
と呼ばれるパラメーターを使って、
特別な機能を有効に出来る。このパラメーターの既定値は空の文字列である。
技術的に、LDAPベースのidmapバックエンドをUIDとGID向けに使うことは可能
であるが、SAMバックエンド用にLDAPの使用も行うネットワーク設定用にこれを
使う時にこれは最も意味を持つ。この設定については
LDAP idmap バックエンドを使う設定例
にある。
LDAPバックエンドに重要な仕事をさせたいネットワーク管理者は、遅かれ 早かれPADLソフトウェアによって優れた功績を知ることになろう。 PADL http://www.padl.comはとても興味深い一連の ツールをオープンソースで作成し、公開している。これらのツールは 以下を含む:
nss_ldap:AIX、Linux、Solarisやその他のOS向けの ネイティブなネームサービスサポートを提供するLDAPネームサービススイッチ (NSS)モジュール。このツールはUID/GIDの一元的な格納と検索に使う ことができる。
idmap_ad:PADL Web サイト からの、Microsoftサービスのための、UNIX RFC2307スキーマを サポートするIDMAPバックエンド。
現在の情報技術界で、多くの興奮と関心が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のベテランはよく理解していることである。
SambaはUNIX POSIX識別情報を、SambaとWindowsネットワーク環境に特有の 情報を格納する場所と同様に必要とする。取り扱われなければならない、 最もよく使われる情報はユーザーアカウント、グループアカウント、マシン 信頼アカウント、ドメイン間信頼アカウントとSamba内部で使う固有の中間 情報を含む。
この文書中の、展開ガイドラインは、他の本とインターネット上で公開されて いるHOWTO文書と同じように、出来上がっているディレクトリデザインと実装に 適合するわけではない。存在するDITは、共通のソース中で提案された単純な 情報レイアウトに適合することが出来ないかもしれない。更に追加すると、 Samba用に使われるLDAPディレクトリを提供するのに使われる共通スクリプトと ツールはあなたの要求に適合しないかもしれない。
これは一般的ではないが、存在するLDAP DITを持つサイトのために、サイト 固有のスクリプトとユーティリティ一式を作成する必要がある場合に、サイト 操作のスコープ内でSambaを供給することは可能である。DITを使ってユーザーと グループアカウントを配布する方法はこれをチャレンジングなことにさせる。 解決方法は、もちろん、価値があることであるが、それを行うための試行錯誤は チャレンジングである。サイトの要求を理解する時間を取り、急いで提供する ことは避けること。
上記から、サイトに適合しないスクリプトとツールをむやみやたらに使わないこと。 存在する基盤が、不適切なツールの不用意な使用によって被害を被らないことを 確実にするために、すべてのスクリプトを、それを実行する前に検査して検証すること。
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制御(設定)ファイル中の「passwd」、「shadow」 と「group」機能経由でホストOSが提供するUIDを問い合わせる。これを 達成するための最適なツールはUNIX管理者の決定にゆだねられている。それはSamba によっては強制されない。Sambaは1つの方法としてそのサポートライブラリとwinbindd を提供する。これをLDAP経由で行う事は可能で、すべてのアカウントエンティティが LDAPディレクトリ中にあることが可能なような適切なフックを提供する。
多くの人に対して、良い選択肢は、PADL nss_ldapライブラリを使うことである。 このユーティリティは、コンピューターアカウントがPOSIX/UNIXアカウントのUID に解決できるように設定されねばならない。これは基本的にLDAPのデザインの問題 である。Sambaメーリングリストとドキュメントで提供される情報は役に立つ例だけ を提供するようになっている。LDAPディレクトリのデザインは複雑な問題であり、 この文書の範囲外である。
Sambaはユーザーとマシンアカウントを管理するための2つのツールを提供する:
smbpasswd
とpdbedit
である。
pdbedit
はSambaユーザーアカウント情報に加えてアカウントポリシーを
管理するために使うことが出来る。ポリシー管理機能は、パスワードのエージングと
ログイン失敗の扱いの管理を行うドメインの既定値の設定を管理するために使われる。
何人かは、名前がSambaSAMAccount情報への格納メカニズムを参照しているために、
参照がsmbpasswd
担っていることに困惑することがある。
しかし、これはユーティリティツールの名前でもある。このツールは結局、
net
ツールセット(Netコマンドを参照)
という、新しく追加された新しい機能に取り替えられることになる。
smbpasswd
はpasswd
とyppasswd
プログラムに似たユーティリティである。これはpassdbバックエンド中の2つの32バイト
パスワードフィールドを管理する。このユーティリティは実際のアカウントと、(smb.conf
ファイル中の passdb backend
によって指定される)パスワード
格納方式とは独立して動作する。
smbpasswd
は、ユーザーのパスワードを変更する時に、ローカルのsmbd
に接続する時にクライアント-サーバーモードで動作する。これは非常なメリットがある。
smbpasswd
はWindows NT上のパスワードを変更する能力もある(これは
NTドメインのユーザーのパスワードを変更する時に、NT PDCにその要求を送る時にのみ動作
する)。
ユーザーまたはマシンアカウントの追加。
ユーザーまたはマシンアカウントの削除。
ユーザーまたはマシンアカウントの有効化。
ユーザーまたはマシンアカウントの無効化。
ユーザーパスワードの削除。
ドメイン間信頼アカウントの管理。
通常のユーザーで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
は、passwd
やyppasswd
コマンドを使っているUNIXユーザーに親しみやすい方法で動作するように設計されて
いる。管理用として設計されているが、このツールは基本的なユーザーレベルの
パスワード変更機能を提供する。
pdbedit
はrootでのみ使えるツールである。これは、
ドメイン全体でのアカウントポリシーの設定のようにpassdbバックエンド
を管理するのに使われる。pdbedit
は以下のように使える:
ユーザーアカウントの追加、削除および変更。
ユーザーアカウントの表示。
ユーザーアカウントの移行(migrate)。
グループアカウントの移行。
アカウントポリシーの管理。
ドメインアクセスポリー設定の管理。
上場企業会計改革および投資家保護法(いわゆる米国SOX法)下で、アメリカの企業と
組織は一連の内部統制
と伝達手段、記録、会計データの
保護を実施することが必要となった。米国SOX法はさらに以下の点についても影響
する:
財務データを格納する情報システムにだれがアクセスするかということ。
どのように個人情報と会計情報が、従業員とビジネスパートナーとの間で扱われるかと言うこと。
どのようにセキュリティの欠陥を管理するかと言うこと。
すべての情報システムへのセキュリティとパッチレベル管理。
どのように情報システムの変更が文書化され、追跡できるようになるかと言うこと。
どのように情報アクセス制御が実装されて管理されているかと言うこと。
変更点とセキュリティに関するすべての情報システムの監査機能。
プライバシーを確実にするための規律手順と制御。
手短に言うと、米国SOX法は、ビジネス関連の情報システムに関して責任を 強める道具である。特に会計データ処理と個人情報の記録に使われるすべての 情報システムのコンプライアンスを強化する。同様な責任は世界中で要求され ている。
政府の法律に従って情報システム操作を許可する Samba のツールと機能に
精通している必要性は明らかである。pdbedit
は
アカウントとシステムアクセス制御とポリシーを管理する能力を提供する
唯一の Samba ツールである。Samba シリーズの残存ライフサイクル中、
この重要な領域で新しいツールが実装されることはあり得る。
Sambaと比較した場合のWindows NT4で有効なドメイングローバルポリシー 制御はNT4 ドメイン対 Sambaポリシー制御 中にある。
表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
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
マニュアルページに
説明があり、
アカウントフラグ管理の節
で簡単に説明されている。
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レコード中を
どのような順番にしても問題はない。
表11.2 Samba SAM Accountコントロールブロックフラグ
フラグ | 説明 |
---|---|
D | アカウントが無効。 |
H | ホームディレクトリが必要。 |
I | ドメイン間信頼アカウント。 |
L | アカウントが自動ロックされている。 |
M | MNS (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
ドメインに対する以下の制御を確立するとする:
min password length = 8 characters.
password history = last 4 passwords.
maximum password age = 90 days.
minimum password age = 7 days.
bad lockout attempt = 8 bad logon attempts.
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 8root#
pdbedit -P "password history" -C 4 account policy value for password history was 0 account policy value for password history is now 4root#
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 7776000root#
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 7root#
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 8root#
pdbedit -P "lockout duration" -C -1 account policy value for lockout duration was 30 account policy value for lockout duration is now 4294967295
最大(無限)なロックアウト時間を設定するためには値として-1を使用する。
アカウントポリシーは各 PDC と BDC 上で個別にに設定する必要がある。この時点 (Samba 3.0.11からSamba3.0.14a)で、アカウントポリシーは自動的に複製されない。 これはSamba3.0.20がリリースされるか、それより少し後に修正される予定である。 Samba リリースファイル中の、この機能に関する特定の更新情報がある WHATSNEW.txt ファイルをチェックしてみること。
古いバージョンのSambaではUNIXユーザーデータベースからユーザー情報を検索し、
結局いくつかの他のフィールドは/etc/samba/smbpasswd
か/etc/smbpasswd
ファイルから得ていた。パスワードの
暗号化が無効になっている時、SMB固有のデータは全く格納されない。その代わり、
すべての操作はSambaホストOSがその/etc/passwd
データベースによってアクセスする方法経由で制御される。ほとんどのLinux
システムでは、たとえば、すべてのユーザーとグループの解決はPAM経由で行われる。
伝統的に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は、大きな会社や巨大サイトが興味を持つものである。
Sambaは「TDB」(trivial database)中にユーザーとマシンアカウント を格納できる。このバックエンドを使う時には追加の設定は不要である。 このバックエンドはLDAPを必要としない、新しくインストールする場合に 推奨される。
一般的なガイドとして、Sambaチームは250人あるいはそれ以上のユーザーが いるサイトに、tdbsamバックエンドを使うことを推奨していない。さらに 追加で、tdbsamは、アカウントデータベースを複製することが要求される PDC/BDC実装を要求するサイト中で使うための拡張性の能力はない。 明確にいうと、拡張性という理由で、ldapsamを使用すべきである。
250ユーザー制限は、純粋に、一般的に、おそらく一つ以上の物理配置 にまたがってばらけている、ルーティングネットワークを持つサイトを必要 とするという概念に基づく目安でしかない。Sambaチームは現時点で、tdbsam アーキテクチャのパフォーマンスベースの拡張性制限を把握していない。
数千のユーザーを抱えているが、1台のサーバーだけを必要とするサイトがある。
1つのサイトは最近UNIXシステム上で4500ユーザーを保持していることを報告し、
tdbsam
passdbバックエンドでよい性能が出たことを
報告した。tdbsam
passdbバックエンドを使う場合の制限は、
TDB格納場所の制限に関連し、それはSambaSAMAccountバックエンドのための
分散メカニズムの必要性にのみ基づく。
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のldapsamコードはOpenLDAP 2.xサーバーとクライアントライブラリを 使って開発とテストが行われている。同じコードはNetscape's Directory Server とクライアントSDKでも動作する。しかし、それらはコンパイルエラーとバグが 必ず生じる。それらを直すのはとても難しい。 バグ報告中で概要が説明されている手順 経由で修正を投稿してほしい。
Sambaは任意の標準準拠のLDAPサーバーとともに動作できる。
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ディレクトリサーバー中で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データベースにアカウントが追加できる前に、格納するためのアカウント コンテナーを作成する必要がある。以下の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サーバーの 安全性を確保することを忘れないこと。
以下の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使用の設定例にある。
例11.2 LDAP使用の設定例
ユーザーアカウントは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エントリについてのセキュリティに関する 議論の際に覚えておかなければならない2つの重要な観点がある。
これらのパスワードハッシュは平文と同等であり、オリジナルの平文 文字列を得ないでもユーザーを詐称するために使える。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
sambaSamAccountオブジェクトクラスは以下の表にあるような属性の集合である: Part AとPart B。
表11.3 Attributes in the sambaSamAccountのオブジェクトクラス(LDAP), Part A
sambaLMPassword | 16進文字列表現で格納されているLanManパスワードの16バイトハッシュ値。 |
sambaNTPassword | 16進文字列表現で格納されているNTパスワードの16バイトハッシュ値。 |
sambaPwdLastSet | sambaLMPassword とsambaNTPassword が
最後に設定された時刻の、1970年からの経過秒数(整数値)。 |
sambaAcctFlags | 大カッコ[]で囲まれた11文字の文字列で、U(ユーザー)、W(ワークステーション)、 X(パスワード満了なし)、I(ドメイン信頼アカウント)、H(ホームディレクトリが必要)、 S(サーバー信頼アカウント)とD(無効)のようなアカウントフラグが格納。 |
sambaLogonTime | 未使用(整数値)。 |
sambaLogoffTime | 未使用(整数値)。 |
sambaKickoffTime | ユーザーがロックされてログインできなくなる時刻(UNIX時刻形式)を指定。 もしも属性が省略された場合、アカウントは決して満了しない。この 属性をshadowAccountオブジェクトクラスのshadowExpire属性と一緒に 使うことで正確な日時で完全にアカウントを満了できる。 |
sambaPwdCanChange | ユーザーにパスワード変更が許可されている時刻(UNIX時刻形式)。 もしもこの属性が設定されていない場合、ユーザーは任意の時刻に パスワードを変更できる。 |
sambaPwdMustChange | パスワードを強制的に変更しなければならない時刻(UNIX時刻形式)。 もしもこの値が0ならば、ユーザーは最初のログイン時にパスワードを変更 しなければならない。この属性が設定されていない場合、パスワードは 決して満了しない。 |
sambaHomeDrive | sambaHomePathによって指定されるUNCパスにマップされるドライブ 名を指定。ドライブ名はXがマップするドライブ名である、 「X:」という形式で指定する必要がある。 smb.conf(5)マニュアルページ中の「logon drive」 パラメーターにある詳細を参照のこと。 |
sambaLogonScript | sambaLogonScriptプロパティは、.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
パラメーターを参照のこと。
|
表11.4 sambaSamAccountオブジェクトクラスの属性, Part B
sambaUserWorkstations | ユーザーのログイン可能な、カンマで分離されたマシンのリスト。 Sambaドメインメンバーに接続することを試みる時に問題が発生する かもしれない。なぜならば、ドメインメンバーがこのリストになく、 ドメインコントローラーはそれを拒否するため。この属性が省略された 場合、既定値は何の制限がないことを仮定する。 |
sambaSID | ユーザーのセキュリティ識別子(SID)。WindowsにおけるUNIX UID相当のもの。 |
sambaPrimaryGroupSID | ユーザーのプライマリグループのセキュリティ識別子(SID)。 |
sambaDomainName | ユーザーが属するドメイン。 |
これらのパラメーターの大多数はSambaがドメイン (どのようにSambaをPDCとして設定するかについての詳細がある ドメイン制御を参照)として振る舞う 時にのみ使われる。以下の4つの属性は、値が既定値でない場合にのみ sambaSamAccountエントリに格納される。
これらの属性は、値が既定値でない場合にのみ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の使用例である。
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 の値にある値を使うことが出来る。
表11.5 設定可能なldap passwd sync
の値
値 | 説明 |
---|---|
yes | ユーザーがパスワード変更時に
|
no |
|
only | LDAPパスワードとLDAPサーバーに他の フィールドについても更新を行う。このオプションはいくつかのLDAP サーバーと、LDAPサーバーがLDAP_EXOP_X_MODIFY_PASSWDをサポートする 時のみ有効である。 |
より詳細な情報は smb.conf
マニュアルページにある。
「Sambaをインストールしたが、UNIXアカウントを使ってログオンできない!」
現在のpassdb backendにユーザーが追加されて いるかを確認すること。詳細は アカウント管理ツールを読むこと。