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 winbindshadow: files winbindgroup: files winbind...hosts: files [dns] wins...
ホストエントリでDNSを使う場合は、サイト上でDNSが使われている場合にのみ行う。
DMSを作成するには以下のような手順を踏む:
上記の設定を使って、smb.conf
ファイルを作成するかインストールする。
以下を実行する:
root#
net rpc join -UAdministrator%passwordJoined domain MEGANET2.
ドメインへの参加が成功するかどうかは、以下のコマンドで確認できる:
root#
net rpc testjoinJoin 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%passwordJoined domain BUTTERNET.
ドメインへの参加が成功するか失敗するかは以下のコマンドで確認出来る:
root#
net ads testjoinUsing short domain name -- BUTTERNETJoined 'GARGOYLE' to realm 'BUTTERNET.BIZ'
ドメインへの参加が不正か失敗するかは以下を実行することで検出できる:
root#
net ads testjoinGARGOYLE$@'s password:[2004/11/05 16:53:03, 0] utils/net_ads.c:ads_startup(186) ads_connect: No results returnedJoin 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 winbindshadow: files winbindgroup: files winbind...hosts: files wins...
以下の手順でidmap_rid機能を使うことが出来る:
上記の設定でsmb.conf
ファイルを作成またはインストールする。
上記で示されたように/etc/nsswitch.conf
ファイルを編集する。
以下を実行する:
root#
net ads join -UAdministrator%passwordUsing short domain name -- KPAKJoined 'BIGJOE' to realm 'CORP.KPAK.COM'
ドメインへの参加が不正または失敗するかは以下を実行することで検出できる:
root#
net ads testjoinBIGJOE$@'s password:[2004/11/05 16:53:03, 0] utils/net_ads.c:ads_startup(186) ads_connect: No results returnedJoin to domain is not valid
特定のエラーメッセージは、発生した問題のタイプに依存するため、上記と 異なるかもしれない。log level
を10まであげて、 テストを再実行し、失敗の真の原因を識別するために生成したログファイルを 調べること。
nmbd
, winbind
とsmbd
デーモンをこの順番で起動する。
root#
getent passwd administratoradministrator: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 ldapshadow: files ldapgroup: files ldap...hosts: files wins...
この解決方法のためには、PADLの nss_ldap
ツールセットが必要である。必要とされる情報を /etc/ldap.conf
ファイルに設定すること。以下は、 動作するファイルの例である:
host 192.168.2.1base dc=snowshow,dc=combinddn cn=Manager,dc=snowshow,dc=combindpw not24getpam_password exopnss_base_passwd ou=People,dc=snowshow,dc=com?onenss_base_shadow ou=People,dc=snowshow,dc=com?onenss_base_group ou=Groups,dc=snowshow,dc=com?onessl no
以下の手続きは動くようにするための設定手順である:
上記で示されたようにsmb.conf
ファイルを設定する。
上記で示されたように/etc/krb5.conf
ファイルを作成する。
上記で示されたように/etc/nsswitch.conf
ファイルを設定する。
PADL nss_ldapツールセットをダウンロードし、コンパイルし、インストールする。 上記で示されたように/etc/ldap.conf
ファイルを設定する。
LDAPサーバを設定し、以下のLDIFファイルで示されるような、IDMAPによって 必要とされるトップレベルのエントリをディレクトリに追加(初期化)する。
dn: dc=snowshow,dc=comobjectClass: dcObjectobjectClass: organizationdc: snowshowo: The Greatest Snow Show in Singapore.description: Posix and Samba LDAP Identity Databasedn: cn=Manager,dc=snowshow,dc=comobjectClass: organizationalRolecn: Managerdescription: Directory Managerdn: ou=Idmap,dc=snowshow,dc=comobjectClass: organizationalUnitou: idmap
Samba DMSをADSドメインに、以下のコマンドを使って参加させる:
root#
net ads testjoinUsing short domain name -- SNOWSHOWJoined '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-mappingmake install
/etc/nsswitch.conf
ファイル中には以下の内容が必要である:
...passwd: files ldapshadow: files ldapgroup: 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サイトにある。