Table of Contents
Microsoft Windows オペレーティングシステムは、Sambaを実装したOSとの間での相互運用性を 行うために、難しい問題を要求してくるといういくつかの特徴がある。この章では、 SambaサーバーをMicrosoft Windowsネットワーク環境に統合するための難問の1つを解決するために 使う、Samba-3(バージョン 3.0.8以降)のメカニズムについて明示的に説明する。この章では、 Windowsのセキュリティ識別子(SID)をUNIXのUIDとGIDについての識別情報マッピング(IDMAP) について説明する。
いろいろな場面において十分に適用出来るようにするため、各可能なSambaの配布タイプに ついて解説を行う。これは、どのようにIDMAP機能が実装されたかについての概要によって フォローされる。
IDMAP機能は、複数のSambaサーバー(またはSambaネットワーククライアント)がドメイン中で インストールされている場合に重要である。単一のSambaサーバーにおいては、IDMAP基盤 については余り気にかける必要はない。既定値におけるSambaの動作はほとんど の場合、十分に使えるものである。複数のSambaサーバーが使われる場合、あるサーバーから 別のサーバーにデータを移動する時にはしばしばこれが必要で、それはやっかい事が始まる 所でもある!
LDAPディレクトリ中にユーザーとグループアカウント情報が格納されている場合、すべてのサーバーは
ユーザーとグループに対して一貫したUIDとGIDを使うことが出来る。これは、NSSとnss_ldapツール
を使うことで出来る。Sambaはローカルアカウントのみを使うように設定出来、その場合、IDMAP
での問題が発生する範囲は若干少なくなる。これは、サーバーが単一のドメインに属していて、
ドメイン間の信頼関係が必要ない時に有効に動作する。別の言い方をすると、もしもSamba
サーバーがNT4ドメインのメンバーかADSのドメインメンバーである場合か、不慮のクロスオーバーが
ないように、セキュリティ名前空間を保持する必要がある場合、(すなわち、ユーザー
DOMINICUS\FJones
はFRANCISCUS\FJones
という
ユーザーのアカウントリソースへのアクセスが出来ないようにしなければならない)
[4]クローズする試みは、
IDMAP機能が設定されているという方法に対して提供されなければならない。
IDMAPの使用は、Sambaサーバーが一つ以上のドメインからワークステーションまたはサーバーによって アクセスされる場合に重要であり、そのような場合、winbindを動作させることが重要で、そうする と、外部のSIDをローカルのUNIX UIDとGIDに解決(IDマッピング)することが出来るようになる。
IDMAP機能は、Samba起動時にwinbindd
の実行を必要とする。
4つの基本的なサーバータイプがあり、これは、 サーバータイプとセキュリティモードの章に 説明がある。
スタンドアロンSambaサーバーはWindows NT4ドメイン、Windows 200x Active Directory ドメインかSambaドメインのメンバーでない形で動く。
定義により、これは、ユーザーとグループはローカルに作成/制御され、ネットワーク ユーザーの識別はローカルのUNIX/Linuxユーザーログイン情報に一致しなければならない。 そのため、IDMAP機能はほとんど関心を払う必要はなく、winbindも不要で、IDMAP 機能は関連しないか、興味を持つべきものではない。
Samba-3はWindows NT4 PDCまたはBDCとして動作でき、それによって、Windows NT4と 互換性を持つドメイン制御プロトコルを提供する。Samba-3のファイルと印刷共有 プロトコルはすべてのバージョンのMicrosoft Windows製品と互換がある。Windows NT4は Microsoft Windows Active Directoryと同様、広範囲にWindows SIDを使用する。
Samba-3ドメインメンバーサーバーとクライアントはMicrosoft Windows SIDと正しく相互に 処理を行わなければならない。入力されたSIDはローカルのUNIX UIDとGIDに変換され なければならない。Sambaサーバーから出力する情報は、適切なSIDでMicrosoft Windows クライアントとサーバーに提供されなければならない。
Windowsネットワークドメイン(NT4形式またはADS)のメンバーであるSambaはいろいろな
方法で識別情報のマッピングを扱うように設定出来る。使用するメカニズムは、
winbindd
デーモンが使われるか否かとどのようにwinbindの
機能が設定されているかに依存する。設定オプションの簡単な説明は以下の通り:
winbindd
が使われないと、Samba
(smbd
)は、入力されたネットワークからの
情報の識別を解決するための、基本的なUNIX/Linuxメカニズムを
使用する。これは、セッションセットアップ要求時にLoginID
(アカウント名)を使い、getpwnam()システムファンクションコール
にそれを渡す。この呼び出しは最近のUNIX/Linuxシステム上では
ネームサービススイッチ(NSS)メカニズムを使うように実装されて
いる。"ユーザーとグループがローカル"という場合、それらは
ローカルシステム上の、/etc/passwd
と
/etc/group
にそれぞれ格納されることを
意味する。
たとえば、ユーザーBERYLIUM\WambatW
が
Sambaサーバーに対して接続をオープンしようとする場合、
入力されるSessionSetupAndX要求は、/etc/passwd
ファイル中のユーザーWambatW
を検索するために
システムを呼び出す。
この設定は、スタンドアロンSambaサーバー、ドメインメンバーサーバー (NT4またはADS)とsmbpasswdまたはtdbsamベースのSamba passdb バックエンドを使うPDCに対して使うことが出来る。
この場合、ユーザーとグループアカウントは、ローカルアカウントとして 取り扱われる。ローカルアカウントそのものとただ1つ違う点は、 共有可能なリポジトリ内にアカウントが格納されると言うことである。 一般的には、これは、NIS形式のデータベースか、そうでなければ LDAP内にあると言うことである。
この設定は、スタンドアロンSambaサーバー、ドメインメンバーサーバー (NT4またはADS)とsmbpasswdまたはtdbsamベースのSamba passdb バックエンドを使うPDCに対して使うことが出来る。
Windows NT4ドメインかADSドメインのメンバーである単一のSamba サーバーか単純なSambaサーバーのみを必要とするサイトは多数ある。 標準的なサーバーの例は、ドメイン用のドメインコントローラー からアカウント認証情報を入手するためにwinbindを使うように 設定され、ローカルアカウントを持たないアプライアンスの ようなファイルサーバーである。ドメイン制御機能は、Samba-3、 Microsoft Windows NT4かMicrosoft Windows Active Directory によって提供される。
Winbindは、この状態においては非常に有益である。必要と
されるすべては、smb.conf
ファイル中で定義することが出来る
UIDとGIDの値の範囲である。/etc/nsswitch.conf
ファイルは、入力されたSIDを適切なUIDとGIDにマッピングする
ための、すべての難しい作業をこなすwinbind
を使うために設定される。SIDはwinbindがそれを受け取る順で
UID/GIDに割り当てられる。
この設定は、複数のSambaサーバーにまたがってUID/GIDとユーザーや グループとのマッピングが同一であることが求められる環境(サイト) では実用的でない。この方法の危険性の1つは、winbind機構の IDMAPデータベースファイルが壊れるか喪失した場合、IDMAP ファイル修正、再生成しても、UIDやGIDが以前と異なるユーザーや グループにマッピングされてしまい、結果としてSambaサーバー上に 格納されたWindowsファイルの所有者が不正になってしまう可能性 がある点である。
IDMAP_RID機能はSamba 3.0.8から提供された。これは、 ADSスキーマ拡張を適用しないMicrosoft ADSを使用する ことに関わりがあり、IDMAPテーブルをメンテナンスする 目的のためにLDAPディレクトリサーバーをインストールして いない、たくさんのサイトのために作業を簡単にする。 もしも単一のADSドメイン(ドメインのフォレストではなく 複数のドメインツリーでない)で、IDMAPテーブル問題に 対して単純なステレオタイプの解決方法を望んでいるなら、 IDMAP_RIDは明らかな選択肢である。
この機能はidmap uid
と
idmap gid
のレンジを割り当てることを
要求し、それが、SIDの相対識別子(RID)の部分を直接UIDのベースにRIDの
値を足した分に、自動マッピングするための、このレンジの
サブセットを割り当てることが可能な
idmap uid
の範囲内であることを要求する。
たとえば、もしもidmap uid
の範囲が
1000-100000000
で、
idmap backend = idmap_rid:DOMAIN_NAME=1000-50000000
で、発生したSIDが
S-1-5-21-34567898-12529001-32973135-1234
という値ならば、結果のUIDは1000 + 1234 = 2234
である。
この設定では、winbind
はsmb.conf
ファイル内で
指定されたidmap uid
と
idmap gid
の範囲からSIDからUIDとGIDに
解決を行うが、ローカルのwinbind IDMAPテーブルを使う代わりに、
すべてのドメインメンバーマシン(クライアントとサーバー)が共通の
IDMAPテーブルを共有できるためのLDAPディレクトリ中に格納された
ものを使う。
すべてのLDAP IDMAPクライアントは、smb.conf
ファイル中の
idmap backend
機能がLDAPリダイレクトを
正しく扱えないため、マスターLDAPサーバーのみを使うということは
重要である。
passdb バックエンドとしてのLDAPの使用はPDC、BDCとドメイン メンバーサーバーに対する優れた解である。それは、UID、GIDと 一致したSIDがすべてのサーバー間で首尾一貫している事を 保証するきちんとした解である。
LDAPベースのpassdbバックエンドの使用は、PADL nss_ldap ユーティリティか同等品を要求する。この状況の場合、 winbindは外部のSID、すなわち、スタンドアロン WindowsクライアントからのSID(すなわち、このドメインの メンバーでない)を他のドメインからのSIDと同じように 扱うために使われる。外部のUID/GIDは、ローカルのIDMAP テーブルでwinbindを使う時と同じ方法で正確に、 割り当てられた範囲(idmap uidとidmap gid)にマップされる。
nss_ldapツールセットはActive Directory経由と同様に、LDAP 経由でUIDとGIDにアクセスするために使われる。Active Directory を使うために、AD4UNIXスキーマ拡張か、Microsoft Services for UNIXバージョン3.5かそれ以降のどちらかをを、UNIXアカウント 認証情報を管理するために、ADSスキーマを 拡張するために インストールしてADSスキーマを変更することが必要である。 ADSスキーマが拡張されると、Microsoft管理コンソール(MMC) スナップインもADSのユーザーとコンピューター管理ツールから UNIXの認証情報を設定/管理することが出来るようにインストール される。各アカウントは、UIDとGIDデータがSambaによって使われる ことが出来る前に、UNIXで有効な状態と分離されなければならない。
Microsoft Windowsドメインセキュリティシステムは、アカウント作成のプロセスの
一部として、ユーザーとグループSIDを生成する。WindowsはUNIXのUIDかGIDのような
概念を持たない。その代わり、固有のタイプのセキュリティ記述子を持つ。Sambaが
ドメインコントローラーとして使われる時、各ユーザーとグループに固有のSIDを生成する
手段を提供する。Sambaは、smb.conf
ファイル中で指定されたベースの値にUID
またはGIDを2倍した値を足すという算術的に計算されたRIDを足すマシンとドメイン
SIDを生成する。この方法は“算術的マッピング”と呼ばれる。
例をあげると、もしもユーザーのUIDが4321の場合、算術的なRIDベースが1000だとすると、
RIDは1000 + (2 x 4321) = 9642
となる。そのため、もしもドメイン
SIDがS-1-5-21-89238497-92787123-12341112
ならば、
結果のSIDはS-1-5-21-89238497-92787123-12341112-9642
となる。
前述のタイプのSIDはSambaによって、自動的な機能としてその場で生成されるか
(passdb backend = [tdbsam | smbpasswd]
を使った場合)、
あるいはLDAPベースのldapsam中でアカウントの一部として恒久的に格納されても
よい。
ADSはUIDとGIDのような追加のアカウント属性に適応するために拡張できるディレクトリ スキーマを使う。Microsoft Service for UNIX 3.5をインストールすると、通常のADS スキーマをUNIXアカウント属性を含むように拡張する。これらはもちろん通常の ADSアカウント管理のMMCインタフェーススナップインモジュールを等して別途管理され なければならない。
ドメイン内で使われるセキュリティ識別子は、競合を避けるためと完全性を保つために 管理されねばならない。NT4ドメインコンテキスト中で、PDCはすべてのセキュリティ 認証情報の、バックアップドメインコントローラー(BDC)への配布を管理する。現時点で、 そのような情報のために適したSambaドメインコントローラーのpassdbバックエンドは、 LDAP中バックエンドのみである。
winbind
を使う誰にとっても、下記の設定例は有用である。多くの場合、
winbind
は、ドメインメンバーサーバー(DMS)とドメインメンバークライアント
(DMC)を使うために一番興味がある事項である。
2つの共通的な設定が使われる:
ネットワーク上にNT4 PDC(BDCがあってもなくても)かSambaPDC(BDCがあってもなくても)がある。
ネットワークは Microsoft Windows 200x ADSを使っている。
NT4ドメインメンバーサーバーのsmb.conは、NT4
DMSに対するsmb.conf
ファイルのグローバルセクション部分の例を示す。
winbind
の使用は、NSSの設定を必要とする。以下を含むように
/etc/nsswitch.conf
のエントリを編集する:
... passwd: files winbind shadow: files winbind group: files winbind ... hosts: files [dns] wins ...
ホストエントリでDNSを使う場合は、サイト上でDNSが使われている場合にのみ行う。
DMSを作成するには以下のような手順を踏む:
上記の設定を使って、smb.conf
ファイルを作成するかインストールする。
以下を実行する:
root#
net rpc join -UAdministrator%password
Joined domain MEGANET2.
ドメインへの参加が成功するかどうかは、以下のコマンドで確認できる:
root#
net rpc testjoin
Join to 'MIDEARTH' is OK
ドメインへの参加が失敗した場合、以下のようなエラーメッセージが出力される:
root#
net rpc testjoin
[2004/11/05 16:34:12, 0] utils/net_rpc_join.c:net_rpc_join_ok(66)
Join to domain 'MEGANET2' is not valid
ADSドメインへの参加手続きは、NT4ドメインへの参加と似ているが、smb.conf
ファイルは
ADSドメインメンバーサーバーのsmb.confで示された
内容の部分が異なる。
ADSのDMS操作はkerberos(KRB)を使用すること要求する。これを動作させるため、
krb5.conf
ファイルを設定する必要がある。正確な要求
内容は、どのバージョンのMITかHeimdal kerberosが使われているかに依存する。
現時点でMIT Kerberosのバージョンが1.3.5で、Heimdal が 0.61である最新の
バージョンのみを使うことを推奨する。
DMSを作成するには以下のステップを必要とする:
上記の設定でsmb.conf
ファイルを作成するかインストールする。
上記で示されたように、/etc/nsswitch.conf
ファイルを編集する。
root#
net ads join -UAdministrator%password
Joined domain BUTTERNET.
ドメインへの参加が成功するか失敗するかは以下のコマンドで確認出来る:
root#
net ads testjoin
Using short domain name -- BUTTERNET
Joined 'GARGOYLE' to realm 'BUTTERNET.BIZ'
ドメインへの参加が不正か失敗するかは以下を実行することで検出できる:
root#
net ads testjoin
GARGOYLE$@'s password:
[2004/11/05 16:53:03, 0] utils/net_ads.c:ads_startup(186)
ads_connect: No results returned
Join to domain is not valid
特定のエラーメッセージは、発生した不成功のタイプに依存するため、
上記とは異なるかもしれない。log level
を10まで
増やし、テストを再実行し、失敗の真の原因を探るために、生成されたログ
ファイルを調べること。
nmbd
, winbind
と smbd
デーモンをこの順番で起動する。
idmap_rid
機能は、ネイティブなwinbindとは異なり、新しい
ツールで、MicrosoftのSIDをUNIXのUIDとGIDに、予測可能なマッピングを作成する。
Samba IDMAP機能にこの手法を実装する一番の利点は、集中したIDMAPデータを保存する
必要性をなくすということである。不都合な点は、単一のADSドメイン内のみで使う
事ができる事と、ドメイン間信頼機能とは互換性がないことである。
このSIDからUID/GIDへのマッピングにおける代替手法はidmap_ridプラグインを
使って実現できる。このプラグインは、RIDに指定されたベース値を加える事に
よってUIDとGIDを引き出すために、ユーザーSIDのRIDを使う。このユーティリティは
複数のドメイン環境とは互換がない、“allow trusted domains = No”
パラメーターを指定することを要求する。idmap uid
と
idmap gid
の範囲を指定する必要がある。
idmap_rid機能はNT4/Samba形式のドメインとActive Directoryで使える。これをNT4
ドメインで使うためには、realm
パラメーターを含んでは
いけない。さらに、ドメインに参加するために使う手法は、
net rpc join
を使う。
ADSドメイン環境でのsmb.conf
ファイルの例は、
idmap_ridを使うADSドメインメンバーのsmb.conf
である。
Example 14.3. idmap_ridを使うADSドメインメンバーのsmb.conf
たくさんのユーザーが居る大きなドメイン中で、ユーザーとグループを列挙することを無効に
することは避けられない。例えば、Active Directory中に22000人ものユーザーが居る
サイトで、winbindベースのユーザーとグループの解決は、winbind
を
最初に開始する時点から12分以上利用できない。列挙を無効にすると、瞬間的に反応が
返る。ユーザーとグループの列挙を無効にすると言うことは、getent passwd
とgetent group
コマンドを使ってユーザーかグループの一覧を
表示することが出来ないと言うことである。特定のユーザーのみを検索することは
以下のような方法で可能である。
このツールを使用するには、ネイティブなwinbindの使用ごとにNSSの設定を必要とする。
以下のパラメーターを含むように/etc/nsswitch.conf
ファイルを
編集する。
... passwd: files winbind shadow: files winbind group: files winbind ... hosts: files wins ...
以下の手順でidmap_rid機能を使うことが出来る:
上記の設定でsmb.conf
ファイルを作成またはインストールする。
上記で示されたように/etc/nsswitch.conf
ファイルを編集する。
以下を実行する:
root#
net ads join -UAdministrator%password
Using short domain name -- KPAK
Joined 'BIGJOE' to realm 'CORP.KPAK.COM'
ドメインへの参加が不正または失敗するかは以下を実行することで検出できる:
root#
net ads testjoin
BIGJOE$@'s password:
[2004/11/05 16:53:03, 0] utils/net_ads.c:ads_startup(186)
ads_connect: No results returned
Join to domain is not valid
特定のエラーメッセージは、発生した問題のタイプに依存するため、上記と
異なるかもしれない。log level
を10まであげて、
テストを再実行し、失敗の真の原因を識別するために生成したログファイルを
調べること。
nmbd
, winbind
とsmbd
デーモンをこの順番で起動する。
root#
getent passwd administrator
administrator:x:1000:1013:Administrator:/home/BE/administrator:/bin/bash
IDMAPの情報をLDAP中に格納することは、NT4/Samba-3形式のドメインとADSドメインで 利用できる。OpenLDAPは、多くの標準準拠のLDAPサーバーが使われているにもかかわらず、 この目的に多用されているLDAPサーバーである。従って、このIDMAP設定を、Sun iPlanet LDAP Server,Novell eDirectory, Microsoft ADS plus ADAMやその他で使うことは可能で ある。
ADSドメインのための例は、 LDAPを使うADSドメインメンバーサーバーにある。
Example 14.4. LDAPを使うADSドメインメンバーサーバー
NT4またはSamba-3形式のドメインの場合、realm
は使わず、
ドメインに参加するために使うコマンドはnet rpc join
である。
上記の例は、バグの報告に記述されている高度な
エラー報告のテクニックも示している。
MIT kerberosがインストールされている場合(バージョン 1.3.4以降)、以下の内容を
含むように/etc/krb5.conf
を編集する:
[logging] default = FILE:/var/log/krb5libs.log kdc = FILE:/var/log/krb5kdc.log admin_server = FILE:/var/log/kadmind.log [libdefaults] default_realm = SNOWSHOW.COM dns_lookup_realm = false dns_lookup_kdc = true [appdefaults] pam = { debug = false ticket_lifetime = 36000 renew_lifetime = 36000 forwardable = true krb4_convert = false }
Heimdal kerberosがインストールされている場合、/etc/krb5.conf
ファイルは空白にするか(すなわち内容が無い)、以下の内容を含むように編集する:
[libdefaults] default_realm = SNOWSHOW.COM clockskew = 300 [realms] SNOWSHOW.COM = { kdc = ADSDC.SHOWSHOW.COM } [domain_realm] .snowshow.com = SNOWSHOW.COM
Sambaは、/etc/krb5.conf
ファイルがない時はHeimdalライブラリを
使えない。それが空白のファイルであるならば、Heimdal kerberosライブラリは使用可能
である。SambaがHeimdalライブラリを使う時には、自動的にこれを見つけることが出来る
ので、特に何も設定しなくても良い。
以下のエントリを含むようにNSS制御ファイル/etc/nsswitch.conf
を編集する:
... passwd: files ldap shadow: files ldap group: files ldap ... hosts: files wins ...
この解決方法のためには、PADLの
nss_ldap
ツールセットが必要である。必要とされる情報を
/etc/ldap.conf
ファイルに設定すること。以下は、
動作するファイルの例である:
host 192.168.2.1 base dc=snowshow,dc=com binddn cn=Manager,dc=snowshow,dc=com bindpw not24get pam_password exop nss_base_passwd ou=People,dc=snowshow,dc=com?one nss_base_shadow ou=People,dc=snowshow,dc=com?one nss_base_group ou=Groups,dc=snowshow,dc=com?one ssl no
以下の手続きは動くようにするための設定手順である:
上記で示されたようにsmb.conf
ファイルを設定する。
上記で示されたように/etc/krb5.conf
ファイルを作成する。
上記で示されたように/etc/nsswitch.conf
ファイルを設定する。
PADL nss_ldapツールセットをダウンロードし、コンパイルし、インストールする。
上記で示されたように/etc/ldap.conf
ファイルを設定する。
LDAPサーバーを設定し、以下のLDIFファイルで示されるような、IDMAPによって 必要とされるトップレベルのエントリをディレクトリに追加(初期化)する。
dn: dc=snowshow,dc=com objectClass: dcObject objectClass: organization dc: snowshow o: The Greatest Snow Show in Singapore. description: Posix and Samba LDAP Identity Database dn: cn=Manager,dc=snowshow,dc=com objectClass: organizationalRole cn: Manager description: Directory Manager dn: ou=Idmap,dc=snowshow,dc=com objectClass: organizationalUnit ou: idmap
Samba DMSをADSドメインに、以下のコマンドを使って参加させる:
root#
net ads testjoin
Using short domain name -- SNOWSHOW
Joined 'GOODELF' to realm 'SNOWSHOW.COM'
以下のようにして、Sambaのsecrets.tdb
ファイルに
LDAPサーバーへのアクセスパスワードを格納する:
root#
smbpasswd -w not24get
nmbd
, winbind
とsmbd
デーモンをこの順番で起動する。
ドメインへの参加が成功するか失敗するかを識別するため、この章の始めの方で 紹介された診断手続きに従うこと。多くの場合、失敗の理由が何も示されない コマンドプロンプトの静かな結果によって、失敗は表示される。
この方法はきれいなものではない。以下で提供される情報は手引きのみであり、かつ、 全くもって不確かで完全ではない。この方法は動く。数多くの巨大サイトで使用され、 耐えられるレベルのパフォーマンスを提供している。
smb.conf
ファイルの例は
NSS経由のRFC2307bisスキーマ拡張日付を使うADSドメインメンバーサーバー
にある。
DMSは通常の手順でドメインに参加しなければならない。更に追加で、PADL nss_ldap ツールセットのコンパイルとインストールが必要である。以下のようにしてこのツールを 構築する:
./configure --enable-rfc2307bis --enable-schema-mapping make install
/etc/nsswitch.conf
ファイル中には以下の内容が必要である:
... passwd: files ldap shadow: files ldap group: files ldap ... hosts: files wins ...
/etc/ldap.conf
も設定しなければならない。特定の説明に
ついては、PADLのドキュメントとnss_ldapのソースコードを参照のこと。
次のステップではADSスキーマの準備を必要とする。これは、この章の残りの部分で 簡単に説明する。
Microsoft Windows Service for UNIX (SFU)バージョン3.5は、Microsoftの Webサイトダウンロード から自由にダウンロードできる。このツールをダウンロードする必要はあり、 以下のMicrosoftの手順に従ってインストールする。
AD4UNIXツールの取得とインストールの手順は、 Geekcomix というWebサイトにある。