目次
UNIXとMicrosoft Windows NTを統合化されたログオンで統合することは、長い間 異機種間コンピューティング環境において「聖杯」と考えられてきた。
もう一つ、この機能がなければ、UNIXとMicrosoft Windowsネットワークの相互運用性が 著しく限定されるというものがある。UNIXシステム全般に渡ってファイル共有を 可能にし、ドメインユーザーとグループの所有者を整合性のある形で割り当てられる 機構がなければならない。
winbindは、Sambaシステム中で、統一されたログオンの 問題を解決するコンポーネントである。Winbind は、Microsoft RPC コール、 Pluggable Authentication Modules (PAM)、Name Service SwitchのUNIXの実装を 使用して、Windows NTのドメインユーザーがUNIXマシン上のUNIXユーザーとして動作 できるようにする。この章は、Winbindシステムについて、その機能、設定の仕方、 及び内部的にどのように動いているのかを説明する。
Winbind は、三つの別々の機能を提供する。
ユーザーの本人確認情報の認証(PAM経由)。これは、Windows NT4ドメインか (Sambaドメインも含む)Active Directoryドメインからユーザーとグループ アカウントを使ってUNIX/Linuxシステムにログオンすることを可能にする。
Winbindは、winbind_idmap.tdbと呼ばれるデータベースを維持し、その中に、
UNIX UID/GIDとNT SID間のマッピング情報を格納する。このマッピングは、
ローカルUID/GIDを持たないユーザーまたはグループにのみ使用する。
idmap uid/gid の範囲から割り当てられ、NTのSIDにマッピングされた
UID/GIDが格納される。idmap backend
が
ldap:ldap://hostname[:389]
に指定されている場合、
ローカルのマッピングを使用する代わりに、Winbindは、この情報をLDAP
データベースから取得する。
もしもwinbindd
が実行中ではないとき、smbd
(winbindd
を呼び出す方)は、代替手段として純粋にローカルな
/etc/passwd
と/etc/group
からの情報を
使用することにし、動的マッピングは使用しない。OSでNSSが有効になっている場合、
ユーザーとグループ情報の解決はNSS経由で行われる。
UNIXとMicrosoft Windows NTでは、ユーザー及びグループ情報の見せ方のモデルも、 それを実行するために使用している技術も異なるのは周知の事実である。これが、 二つのシステムを統合して、満足の行く運用をすることを困難にしてきた。
これに対してよく行われる解決策は、UNIXとWindowsの両システム上に全く同名の ユーザーアカウントを作成し、Sambaを使用して、両システム間のファイルサービスと 印刷サービスを提供するというやり方であった。ただし、この解決策は、双方の マシンにユーザーを追加したり削除したりする作業が面倒でパスワードも2セット 持たなければならず、その両方がUNIXとWindowsシステム間の同期のずれの問題に つながり、ユーザーの混乱を招くという、完璧には程遠いものである。
UNIX マシンのための統一されたログオンという問題を、次のように三つの 構成要素に分けることができる:
Windows NTのユーザー及びグループ情報を取得する。
Windows NT ユーザーを認証する。
Windows NT ユーザーのためにパスワードを変更する。
理想的には、統一されたログオンという問題の解決方法は、UNIXマシン上に情報を複製する ことなく、上記の問題を全て満足させ、しかも、 ユーザーやグループ情報をどちらの システムで維持しても、システム管理者の仕事を増やさないというものであってほしい。 Winbind システムは、統一されたログオンという問題の三つの構成要素を簡単に優雅に こなすソリューションを提供するものである。 problem.
Winbindは、UNIXとWindows NTのアカウント管理を、UNIXマシンがNTドメインの完全な メンバーになることを可能にすることによって統一する。一旦これを行えば、UNIX マシンは、NTユーザーやグループをあたかも「ネイティブな」UNIXユーザーや グループであるかのように見ることができるようなり、UNIXのみの環境でNIS+を使用 するのとほぼ同様に、NTドメインを使用することができるようになる。
その結果、UNIX マシン上のプログラムのいずれかが、OSにユーザー名やグループ名の検索を 依頼すると、指定されたドメインを担当する NT のドメインコントローラーにその検索を 依頼することにより、問い合わせは解決する。Winbind は低レベル(Cライブラリ内の NSS名前解決モジュール経由)でOSに繋がるので、NT ドメインコントローラーへの上記の リダイレクションは、完全に透過である。
UNIXマシンのユーザーは、「ネイティブの」UNIX名を使用するのと同様に、 NTユーザー名とグループ名を使用することができる。ユーザーはファイルをchownして、 NTドメインユーザーの所有に変えることもでき、UNIXマシンにログインしてドメイン ユーザーとしてUNIXのX Window Systemセッションを実行することもできる。
Winbindが使用されていることが明らかにわかるところは、ユーザー及びグループの名前が
DOMAIN\user
とDOMAIN\group
の形を取ると
いう点だけである。これは、Winbind が、信頼関係のあるドメインに参照するの特定の
検索について、ドメインコントローラーへのリダイレクト決めるために必要である。
さらに、Winbind は、PAMシステムのhookとしての認証サービスを提供し、NTドメインを 経由して、PAM対応のあらゆるアプリケーションに対して認証を行う。この機能は、一カ所 (ドメインコントローラー上)に全てのパスワードが格納されるため、システム間の パスワード同期の問題を解消する。
NTベースのドメイン基盤がすでにあり、それにUNIX ワークステーションか サーバーを組み入れたいという要望のある組織がWinbindの対象となる。Winbind より、このような組織は別個のアカウント基盤を管理する必要なく、UNIX ワークステーションを展開することができる。これは、NTベースの組織にUNIX ワークステーションを展開するための間接費を大幅に軽減する。
Winbind のもう一つの興味深い使用方法は、UNIXベースの装置の中心部分に 使用することである。Microsoftベースのネットワークにファイルサービスと 印刷サービスを提供する装置は、Winbindを使用することで、ドメインに シームレスに統合される。
外部のSID(foreign SID)という単語は、特定の環境に依存しない 反応としてしばしば見受けられる。以下はSambaメーリングリスト上で起きたやりとりを 書化したものである。これは、winbindの使用に関連してしばしば現れる混乱の良い例で ある。
事実:Winbindはローカルドメインの一部でないワークステーションを使うユーザーを 扱う必要がある。
対応:「なぜ?私はwinbindなしで長い間ドメインに所属していないワークステーション をSambaとともに使っている。winbindは他のSamba/Windows PDCによって制御される ドメイン中のメンバーサーバーとしてのSamba用ではないかと思う。」
もしも、SambaサーバーがローカルSambaドメイン以外のドメインからアクセスされる か、もしも、ローカルドメインメンバーでないマシンからアクセスされる場合、winbindは Sambaドメインのメンバーであるユーザーから分離された外部のユーザーの識別情報を保持する めの割り当てられた領域からUIDとGIDを割り当てる。
これは、winbindは、ドメインメンバーとドメイン非メンバーのワークステーションがある、 単一のSambaPDCがローカルネットワーク上にある場合に甚だしく有用である。もしも、 winbindが使われないと、ドメインのメンバーでないWindowsワークステーション上の georgeというユーザーはPDCとして動作しているSambaサーバーのアカウントデータベース 中のgeorgeと呼ばれるユーザーのファイルにアクセスできる。winbindが使われると、 既定値の状態は、ローカルユーザーのgeorgeがDOMAIN\georgeというアカウントとして 扱われ、外部(ドメインのメンバーでない)アカウントは、おのおの別のSIDを持つために MACHINE\georgeとして扱われる。
Winbindシステムは、クライアント/サーバーアーキテクチャを想定し設計されたもので
ある。長時間走り続けるwinbindd
デーモンがUNIXドメイン
ソケット上でリクエストが来るのを待つ。これらのリクエストは、NSS及びPAM
クライアントにより生成され、順番に処理される。
Winbind を実装するのに使用されている技術を以下に詳述する。
過去数年間、Sambaチームの多くのメンバーが、Microsoftリモートプロシージャー コール(MSRPC)システムの各側面を解明しようと努力してきた。このシステムは、 リモート管理、ユーザー認証、印刷スプーリングを含むWindows NTマシン間の ネットワーク関連操作の大半に使用されている。当初、Sambaへのプライマリ ドメインコントローラー(PDC)機能の実装を支援するために 着手した作業で あったが、結果としてそれ以外の目的に使用できる一連のコードを得ることが できた。
winbind はドメインユーザーとグループを列挙し、個々のユーザーやグループの詳細 情報を取得するために、各種のMSRPC コールを使用する。他のMSRPC コールは、 NTドメインユーザーを認証し、ユーザーのパスワードを変更するために使用できる。 Windows PDCに、直接ユーザー及びグループ情報を問い合わせることで、Winbindは、 NTのアカウント情報をUNIXユーザー名とグループ名にマッピングする。
2001年後半より、SambaはNT4のRPC サービスではなく、「ネイティブモード」 のプロトコルを使用して、Microsoft Windows 2000とやり取りする機能を持つ ようになった。LDAP及びKerberosを使用し、winbindを走らせている ドメイン メンバーは、Windows 200xクライアントの世界で行われるのと全く同じように、 ユーザーとグループを列挙でき、そうすることによってより効率的で効果的な winbind の実装を提供する。
Name Service SwitchまたはNSSは、多くのUNIX OSに存在する機能である。 これは、ホスト名、メールの別名、ユーザー情報などのシステム情報を、異なる ソースから解決することを可能にする。例えば、スタンドアロンのUNIXワーク ステーションは、ローカルのファイルシステムに格納されている一連のフラット ファイルからシステム情報を解決できる。ネットワークに繋がったワーク ステーションは、最初にローカルファイルからシステム情報を解決しようとし、 次にユーザー情報についてNISデータベースに問い合わせるか、あるいは、ホスト名 情報についてDNS サーバーに聞くことができる。
UNIXユーザー名とグループの解決の際、NSSのAPIは、winbind が自分をシステム 情報のソースとして見せることを可能にする。winbindは、このインタフェースと MSRPCコールを使用して、Windows NTサーバーから取得した情報を使用して、 アカウント列挙の新しいソースを提供する。標準のUNIXライブラリコールを 利用して、winbind を走らせているUNIXマシン上でユーザーとグループを列挙させ、 NTドメインのみならず、信頼関係のあるいずれのドメインでもその全ユーザーと グループを、あたかも、ローカルユーザーやグループのように見ることができる。
NSSの基本制御ファイルは/etc/nsswitch.conf
である。
UNIXアプリケーションが検索を行うと、Cライブラリは要求されたサービス
タイプに一致する列を/etc/nsswitch.conf
の中で探す。
例えば、ユーザー名またはグループ名の検索の場合、「passwd」の
サービスタイプが使用される。設定の中のこの列が、そのサービスのどの
実装が、どういう順番で試行されるべきか指定している。もし、passwdの
設定列が以下のようになっている場合:
passwd: files example
Cライブラリは、最初に/lib/libnss_files.so
と呼ばれる
モジュールをロードし、次に/lib/libnss_example.so
モジュールをロードする。Cライブラリはこれらのモジュールを順番に動的
ロードし、モジュール内の解決機能を呼んでリクエストを解決しようとする。
要求が解決されると、Cライブラリ は、その結果をアプリケーションに返す。
このNSSインタフェースは、OSへのフックのための、Winbindへの簡単なしくみを
提供する。必要な手続きは、/lib/
の中に
libnss_winbind.so
を書き、次に適切な場所で
/etc/nsswitch.conf
に「winbind」を追加
するだけである。これで、Cライブラリは、Winbindを呼んでユーザー名や
グループ名を解決できるようになる。
PAMは、認証と認証技術を抽象化するものである。PAMモジュールを使用すると、 異なるシステムアプリケーション用にそれぞれ異なる認証方法を指定でき、 しかも、これらのアプリーケーションを再コンパイルする必要はない。 PAM はまた、特別なポリシーを認証に実装するためにも有用である。例えば、 システム管理者は、ローカルなパスワードファイルに格納されたユーザーからは コンソールログインのみを許可し、NISデータベースから解決されるユーザーに ついては、ネットワーク経由のログインを許可することができる。
Winbind は、認証管理とパスワード管理のPAMインタフェースを使用して、 Windows NTユーザーをUNIXシステムに統合する。これにより、 Windows NT ユーザーはUNIXマシンにログインでき、適切なPDCの認証を受けることが できるようになる。このようなユーザーはパスワードの変更もできる上、 その変更内容をPDCに直に反映させることができる。
PAMは、認証を必要とするサービスごとに、/etc/pam.d/
の
ディレクトリに管理ファイルを設けて設定する。アプリケーションが認証要求を
出すと、Cライブラリ内のPAMコードが、認証を行うために、どのモジュールを
どの順番でロードするべきかを決定するためにこの管理ファイルを検索する。
このインタフェースにより、Winbindに新しい認証サービスを追加することが
簡単になる。必要な手順は、/lib/security/
に
pam_winbind.so
モジュールをコピーすることと、
Winbind 経由の認証を可能にするために、関連するサービスのPAM管理ファイルを
更新することである。詳細は、
PAMベースの分散型認証のPAMの説明を参照のこと。
Windows NT/200xでユーザーまたはグループが作成されると、数字で構成される 相対ID(RID)を割り当てられる。これは、UNIXとは幾分異なる。UNIXでは、 ユーザーIDに使用される数字の範囲と、グループIDに使用される数字の範囲が 別々になっている。RIDをUNIXのIDに変換する、またはその逆を行うのが Winbindの仕事である。Winbindを設定する際、UNIXユーザーIDのスペースの 一部とUNIX グループIDのスペースの一部を、Windows NTのユーザーと グループを格納する場所である。Windows NTユーザーが最初に解決されるとき、 上記の範囲の中から次の空き番号をUNIX上のIDとして割り当てる。この 同じプロセスがWindows NTグループに対しても適用される。こうして一定の 時間が経つと、全てのWindows NTユーザーとグループはWinbindにより、対応 するUNIXユーザーIDとグループIDへマッピングされることになる。
このマッピングの結果は、tdbのデータベース内のIDマッピングデータベースに 一貫して格納されていく。これにより、RIDが一貫した方法でUNIXのIDに マッピングされていくことを確保している。
Active Directoryシステムは、数多くのユーザー名やグループ名の検索を発行 する。 これらの検索に係るネットワークの負担を軽減するため、Winbindは、 NTドメインコントローラーから供給されるSAM シーケンス番号に基づいて、 キャッシュに保存する。PDCから返されたユーザー情報やグループ情報は、 同じくPDCから返されたシーケンス番号と一緒に、Winbindによってキャッシュに 保存される。ユーザー情報やグループ情報が変更される度に、Windows NTは シーケンス番号を増やす。キャッシュに保存されたエントリが満了になる ときに、シーケンス番号をPDC からリクエストし、キャッシュのエントリの シーケンス番号と比較する。番号が一致しないときは、キャッシュに保存された 情報を捨て、PDCから直接更新情報をもらうように更新を行う。
この節では、Winbindを入手して使えるようにするまでの手順を説明する。WinbindはNTまたは Windows 200xの PDCを通して、Windowsのドメインユーザーにtelnetやftpのような通常のサービス と、Sambaの各種サービスのためのアクセス制御と認証管理の機能を提供することができる。
現在使用しているSamba設定ファイルがあるなら、バックアップを取ること!。
使用中のシステムが既にPAMを使用しているなら、
/etc/pam.d
ディレクトリの内容をバックアップすること!。
起動ディスクをまだ作成していないのなら今すぐに作ること!。
PAM設定ファイルを間違って修正すると、使用中のマシンにログインするのがほとんど不可能に
なってしまうことがある。このため、うまくいかない時にはマシンをシングルユーザーモードで
立ち上げ、/etc/pam.d
を元の状態に戻せるようにすること。
Samba の最新バージョンには、正常に機能する winbindd daemon が含まれている。ソースコードを ダウンロードする手順については、 Samba Webページか 最寄の Samba ミラーサイトにある説明を参照のこと。
ドメインユーザーがSambaの共有やファイルにアクセスできるようにし、また使用するマシンが 提供するその他のサービスにもアクセスできるようにするには、PAMを使用するマシン上で正しく 設定しなければならない。Winbindモジュールをコンパイルするには、PAM開発ライブラリを インストールすべきである。 PAMのウェブサイトを参照のこと。
開始する前に、使用しているサーバー上で走っている全てのSamba関連のデーモンを止めておくことを
推奨する。動いているかもしれないsmbd、nmbd、及びwinbinddの全プロセスを停止する。
PAMを使用するには、PAMを認識するサービスが使用するPAMモジュール、複数のPAMライブラリ、及び
PAMのための/usr/doc
と/usr/man
のエントリを含む、
/etc/pam.d
のディレクトリ構造を提供する、標準PAM パッケージを持って
いることを確認する。WinbindをSamba内で構築する際、pam-devel パッケージをインストールして
いると、よりうまくいく。このパッケージには、PAMを認識するアプリケーションをコンパイルする
のに必要なヘッダーファイルが含まれる。
PAM は、最新世代の UNIX/Linux システムの標準コンポーネントである。しかし、残念ながら
PAM対応のSambaを構築するのに必要なpam-devel
ライブラリをインストール
しているシステムは数が限られている。また、Samba は Winbind ファイルを使用中のシステム上の
正しい位置に自動インストールするかもしれない。そこでこれ以上先に進む前に、以下に説明する
設定が本当に必要かどうか確認すること。もしかしたら、
/etc/nsswitch.conf
の設定だけで済むかもしれない。
winbindd daemonをnsswitch経由で走らせるために必要なライブラリを正しい場所にコピー しなければならない:
root#
cp ../samba/source/nsswitch/libnss_winbind.so /lib
また、以下のシンボリック・リンクを作成することが必要である:
root#
ln -s /lib/libnss_winbind.so /lib/libnss_winbind.so.2
root#
ln -s /usr/lib/libnss_winbind.so /usr/lib/libnss_winbind.so.1
root#
ln -s /usr/lib/libnss_winbind.so /usr/lib/nss_winbind.so.1
root#
ln -s /usr/lib/libnss_winbind.so /usr/lib/nss_winbind.so.2
次に、rootになって、winbindd daemonからユーザーやグループのエントリが見えるように、
/etc/nsswitch.conf
を編集する。たとえば/etc/nsswitch.conf
ファイルを以下のように編集する:
passwd: files winbind shadow: files group: files winbind
winbindd
daemonが必要とするライブラリは、次回システムが再起動する
とき、自動的にldconfig
のキャッシュに入るが、手動で以下を行う方が
早い(それに、再起動する必要もない):
root#
/sbin/ldconfig -v | grep winbind
これにより、winbinddがlibnss_winbind
を使える状態になり、
dynamic link loaderによって使われる現在の検索パスを返す。ldconfig
コマンドの出力にgrep
フィルターを適用することで、このライブラリが
本当にdynamic link loaderによって認識されるかの確証を確認できる。
Sun Solarisのダイナミックリンクローダー管理ツールはcrle
と呼ばれる。
このツールは元々のOS環境の一部として提供されていないライブラリファイルを含む
ディレクトリを検索するよう指示するために必要である。以下の例は、ダイナミックリンク
ローダーの検索パスに、どのようにして/usr/local/lib
ディレクトリを
追加するために使うかを示す:
root#
crle -u -l /usr/lib:/usr/local/lib
引数なしで実行した場合、crle
は現在のダイナミックリンクローダーの
設定を表示する。それは以下の通り:
root#
crle
Configuration file [version 4]: /var/ld/ld.config
Default Library Path (ELF): /lib:/usr/lib:/usr/local/lib
Trusted Directories (ELF): /lib/secure:/usr/lib/secure (system default)
Command line:
crle -c /var/ld/ld.config -l /lib:/usr/lib:/usr/local/lib
これから、/usr/local/lib
ディレクトリは、オブジェクトモジュールの
依存関係を満足させるために、ダイナミックリンクライブラリの検索中に含まれていることが
わかる。
(この節はAIXを動作させている人にのみ関係する。)
Winbind AIX識別モジュールは、Sambaソースのnsswitchディレクトリ内に
libnss_winbind.so
として構築される。このファイルは、
/usr/lib/security
にコピーでき、AIXの名前変換から、WINBIND
という名前にするべきであると指示してくる。次の節では、以下のようにして、
WINBIND: program = /usr/lib/security/WINBIND options = authonly
/usr/lib/security/methods.cfg
が追加できるようなる。このモジュールは
識別のみサポートするが、標準のWinbind PAMモジュールを認証に使用して成功した例が報告されて
いる。ローダブルな認証モジュール設定の際には、システムにログオンできない状態になって
しまうこともあり得るので、慎重に行なうこと。AIX認証モジュールAPIに関する詳細情報は、
AIXのための、
Loadable Authentication Module Programming Interfaceで記述されている、
「Kernel Extensions and Device Support Programming Concepts for AIX」
という文書にある。モジュールの管理に関するさらなる情報は、
System
Management Guide: Operating System and Devicesにある。
winbinddの動作を制御するために、smb.conf
ファイルにいくつかのパラメーターを設定する必要が
ある。これについては、winbindd(8)マニュアルページに、より詳細に説明されている。
以下のWinbind設定のためのsmb.confによるsmb.conf
は、
[global]セクションの中の必要なエントリも含むように変更したものである。
例24.1 Winbind設定のためのsmb.conf
ドメインセキュリティに関与するすべてのマシンはドメインのメンバーであるべきである。 これはPDCとすべてのBDCにも適用される。
ドメインへの参加手続きは、net rpc join
コマンドを使って行う。この
手続きは、MS DCE RPC経由で登録された(通常はPDC)ドメインコントローラーと通信を行う。これは、
もちろん、smbd
プロセスが対象のドメインコントローラー上で動作
していなければならないということである。それ自身のドメインに参加できるように、一時的に
PDCとしてSambaを起動することは、そのために必要である。
PDC
という名前のPDCで、ドメイン中で管理者権限を持つドメイン
ユーザーがAdministrator
である時、以下のコマンドを入力し、
Sambaサーバーをドメインに参加させる。
ドメインにマシンを参加させる前に、対象のドメインコントローラー(通常はPDC)でSambaが 動作しているかを確認し、ポート137/udp, 135/tcp, 139/tcp, と 445/tcpが開いているかを 確認する(もしもPDCがSambaかWindows Server 2Kxの場合)。
root#
/usr/local/samba/bin/net rpc join -S PDC -U Administrator
このコマンドへの正しい解答は、「Joined the domainDOMAIN
」
である。ここで、DOMAIN
は対象のドメイン名である。
最終的には、Sambaのその他の部分が立ち上がるときに、自動的にwinbindd daemonを呼び出す ように、Sambaの起動スクリプトを変更したいと思うかもしれないが、Winbind部分だけを最初に テストしておくことは可能である。Winbind のサービスを立ち上げるには、以下のコマンドを rootとして入力する:
root#
/usr/local/samba/sbin/winbindd
winbindd
実行ファイルの位置への適切なパスを使用すること。
上記は、/usr/local/samba
のディレクトリツリーの中にSamba を
インストールしたと仮定している。使用するシステム上でwinbindd
が別の
所にある場合は、Sambaファイルの位置を探す必要がある。
心配性な人の場合、daemonが本当に動いているかは以下で確認出来る。
root#
ps -ae | grep winbindd
このコマンドは、daemonが動いているなら、以下のような結果を返してくるはずである。
3025 ? 00:00:00 winbindd
次に、本当のテスト用に、PDC上にあるユーザー情報を取得する:
root#
/usr/local/samba/bin/wbinfo -u
これは、PDC上のWindowsユーザー情報に入っているユーザーの一覧をエコーバックするはずである。 例えば、以下のような結果が表示される:
CEO\Administrator CEO\burdell CEO\Guest CEO\jt-ad CEO\krbtgt CEO\TsInternetUser
もちろん、ドメイン名は「CEO」で、winbind separatorは 「\」である。
root#
/usr/local/samba/bin/wbinfo -g
CEO\Domain Admins CEO\Domain Users CEO\Domain Guests CEO\Domain Computers CEO\Domain Controllers CEO\Cert Publishers CEO\Schema Admins CEO\Enterprise Admins CEO\Group Policy Creator Owners
ここで、getent
コマンドを使用して、ローカルとPDCの両方からユーザーと
グループの統合された一覧を表示させることができる。以下のコマンドを入力する:
root#
getent passwd
/etc/passwd
のような、ドメインユーザーの新しいUID、GID、
ホームディレクトリ及び既定値のシェルが表示される一覧が出てくるはずである。
グループについても同様に以下のコマンドを実行できる:
root#
getent group
winbindd daemonはsmbdとnmbd daemonが動き出してから起動する必要がある。これを
行うには起動スクリプトを書き換える。それは、Red Hat Linuxでは
/etc/init.d/samba
にあり、Debian Linuxでは
/etc/init.d/samba
にある。これらのdaemonを正しい順序で走らせる
ためのコマンドをスクリプトに加える。たとえば、起動スクリプトの例としては、
smbd, nmbd, と winbinddを直接/usr/local/samba/bin
ディレクトリ
から起動する。このスクリプト中のstart
関数は以下の通り:
start() { KIND="SMB" echo -n $"Starting $KIND services: " daemon /usr/local/samba/bin/smbd $SMBDOPTIONS RETVAL=$? echo KIND="NMB" echo -n $"Starting $KIND services: " daemon /usr/local/samba/bin/nmbd $NMBDOPTIONS RETVAL2=$? echo KIND="Winbind" echo -n $"Starting $KIND services: " daemon /usr/local/samba/sbin/winbindd RETVAL3=$? echo [ $RETVAL -eq 0 -a $RETVAL2 -eq 0 -a $RETVAL3 -eq 0 ] && \ touch /var/lock/subsys/smb || RETVAL=1 return $RETVAL }
winbindd をデュアル・デーモン・モードで走らせたい場合は、上記例の中の:
daemon /usr/local/samba/sbin/winbindd
の列を、以下に変える:
daemon /usr/local/samba/sbin/winbindd -D
.
stop
関数は、サービスを停止するために以下のように起動に対応するエントリを持つ:
stop() { KIND="SMB" echo -n $"Shutting down $KIND services: " killproc smbd RETVAL=$? echo KIND="NMB" echo -n $"Shutting down $KIND services: " killproc nmbd RETVAL2=$? echo KIND="Winbind" echo -n $"Shutting down $KIND services: " killproc winbindd RETVAL3=$? [ $RETVAL -eq 0 -a $RETVAL2 -eq 0 -a $RETVAL3 -eq 0 ] && \ rm -f /var/lock/subsys/smb echo "" return $RETVAL }
WinbindはSolaris 9では動作しない。 see Solaris 9でのWinbindの節を参照のこと。 for details.
Solarisでは、/etc/init.d/samba.server
起動スクリプトを変更する必要が
ある。また、通常は smbd と nmbdのみを起動するが、winbinddも起動すべきである。Sambaが
/usr/local/samba/bin
にインストールされている場合、このファイルには
以下のようなものを含むことが出来る:
## ## samba.server ## if [ ! -d /usr/bin ] then # /usr がマウントされていない exit fi killproc() { # 名前指定でプロセスを停止 pid=`/usr/bin/ps -e | /usr/bin/grep -w $1 | /usr/bin/sed -e 's/^ *//' -e 's/ .*//'` [ "$pid" != "" ] && kill $pid } # Sambaサーバーに必要な起動/停止プロセス case "$1" in 'start') # # 使用環境(パス、ワークグループ、ホスト)に合わせて以下を編集すること # echo Starting SMBD /usr/local/samba/bin/smbd -D -s \ /usr/local/samba/smb.conf echo Starting NMBD /usr/local/samba/bin/nmbd -D -l \ /usr/local/samba/var/log -s /usr/local/samba/smb.conf echo Starting Winbind Daemon /usr/local/samba/sbin/winbindd ;; 'stop') killproc nmbd killproc smbd killproc winbindd ;; *) echo "Usage: /etc/init.d/samba.server { start | stop }" ;; esac
繰り返すが、Winbindをデュアルdaemonモードで動かしたい場合、上記の:
/usr/local/samba/sbin/winbindd
の部分を、下記に変える:
/usr/local/samba/sbin/winbindd -D
ここまで来たということは、winbindd
とSambaが一緒に動作している状態に
なったと言うことである。Winbindを使用して、他のサービスに認証を提供できるようにしたい
場合は、この先を読み進めること。PAMの設定ファイルを、この手順の中で変更する必要が出て
くる(現在使っている/etc/pam.d
ファイルのバックアップを取っていない
ならば、今行うこと)。
他のサービスでwinbinddを使用するためのPAM モジュールが必要になる。このモジュールは、
以下のコマンドで、../source
ディレクトリから
../source/nsswitch
ディレクトリにコンパイルされる:
root#
make nsswitch/pam_winbind.so
pam_winbind.so
ファイルは、他のPAMセキュリティモジュールのある
場所にコピーしなければならない。Red Hat システムでは、/lib/security
というディレクトリである。Solaris では、PAMセキュリティモジュールは、
/usr/lib/security
に入る。
root#
cp ../samba/source/nsswitch/pam_winbind.so /lib/security
/etc/pam.d/samba
ファイルは変更する必要がない。このファイルはそのまま残す:
auth required /lib/security/pam_stack.so service=system-auth account required /lib/security/pam_stack.so service=system-auth
Winbindを認証サービスに使用できるように手を加えたその他のサービスは、コンソール上の通常
ログイン(またはターミナルセッション)、telnetログイン、それにftpサービスである。これらの
サービスを有効にするには、まず、/etc/xinetd.d
(または
/etc/inetd.conf
)の中のエントリを変更する必要があるかも知れない。
Red Hat Linux 7.1以降のバージョンは、新しい xinetd.d 構造を使用しており、この場合、
/etc/xinetd.d/telnet
と/etc/xinetd.d/wu-ftp
の中の文字列を
enable = no
から
enable = yes
に変更する必要がある。
ftpサービスを動作させるためには、既にサーバー上に存在するドメインユーザーのために、個別に
ディレクトリを用意するか、ホームディレクトリを全ドメインユーザー用の汎用ディレクトリに
変更する必要がある。これらは、smb.conf
のtemplate homedir
グローバルエントリで簡単に設定できる。
template homedir中のディレクトリは、自動的には生成されない! pam_mkhomedirか、あらかじめ当該ユーザーに対してディレクトリを作成しておくようにして、 固有のホームディレクトリを使ってUNIXにログインできるようにすること。
/etc/pam.d/ftp
ファイルは、/etc/pam.d/samba
ファイルと似たような形で、Winbindのftpアクセスを許可するように変更できる。変更後の
/etc/pam.d/ftp
ファイルは以下の通り:
auth required /lib/security/pam_listfile.so item=user sense=deny \ file=/etc/ftpusers onerr=succeed auth sufficient /lib/security/pam_winbind.so auth required /lib/security/pam_stack.so service=system-auth auth required /lib/security/pam_shells.so account sufficient /lib/security/pam_winbind.so account required /lib/security/pam_stack.so service=system-auth session required /lib/security/pam_stack.so service=system-auth
/etc/pam.d/login
ファイルもほぼ同様に変更できる。以下のようになる:
auth required /lib/security/pam_securetty.so auth sufficient /lib/security/pam_winbind.so auth sufficient /lib/security/pam_unix.so use_first_pass auth required /lib/security/pam_stack.so service=system-auth auth required /lib/security/pam_nologin.so account sufficient /lib/security/pam_winbind.so account required /lib/security/pam_stack.so service=system-auth password required /lib/security/pam_stack.so service=system-auth session required /lib/security/pam_stack.so service=system-auth session optional /lib/security/pam_console.so
auth sufficient /lib/security/pam_winbind.so
を追加するが、それに加え
required pam_securetty.so
を加えることにより、ネットワーク上からのrootのログインを不許可とした。また、
sufficient /lib/security/pam_unix.so use_first_pass
行をwinbind.so
行の後に加え、パスワードからのプロンプトが二重表示される
問題を解消した。
/etc/pam.conf
の変更が必要である。ドメインユーザーがローカルにも
telnetでもログオンできるように変更する。以下が変更内容である。pam.conf
を要件に沿ってカスタマイズしてもよいが、最悪の場合、システムがほとんど起動不能になることが
あるので、変更内容に十分自信がある場合のみ変更すること。
# #ident "@(#)pam.conf 1.14 99/09/16 SMI" # # Copyright (c) 1996-1999, Sun Microsystems, Inc. # All Rights Reserved. # # PAMの設定 # # 認証管理 # login auth required /usr/lib/security/pam_winbind.so login auth required /usr/lib/security/$ISA/pam_unix.so.1 try_first_pass login auth required /usr/lib/security/$ISA/pam_dial_auth.so.1 try_first_pass # rlogin auth sufficient /usr/lib/security/pam_winbind.so rlogin auth sufficient /usr/lib/security/$ISA/pam_rhosts_auth.so.1 rlogin auth required /usr/lib/security/$ISA/pam_unix.so.1 try_first_pass # dtlogin auth sufficient /usr/lib/security/pam_winbind.so dtlogin auth required /usr/lib/security/$ISA/pam_unix.so.1 try_first_pass # rsh auth required /usr/lib/security/$ISA/pam_rhosts_auth.so.1 other auth sufficient /usr/lib/security/pam_winbind.so other auth required /usr/lib/security/$ISA/pam_unix.so.1 try_first_pass # # アカウント管理 # login account sufficient /usr/lib/security/pam_winbind.so login account requisite /usr/lib/security/$ISA/pam_roles.so.1 login account required /usr/lib/security/$ISA/pam_unix.so.1 # dtlogin account sufficient /usr/lib/security/pam_winbind.so dtlogin account requisite /usr/lib/security/$ISA/pam_roles.so.1 dtlogin account required /usr/lib/security/$ISA/pam_unix.so.1 # other account sufficient /usr/lib/security/pam_winbind.so other account requisite /usr/lib/security/$ISA/pam_roles.so.1 other account required /usr/lib/security/$ISA/pam_unix.so.1 # # セッション管理 # other session required /usr/lib/security/$ISA/pam_unix.so.1 # # パスワード管理 # #other password sufficient /usr/lib/security/pam_winbind.so other password required /usr/lib/security/$ISA/pam_unix.so.1 dtsession auth required /usr/lib/security/$ISA/pam_unix.so.1 # # Kerberos V5 認証のサポート(Kerberosを使用するにはアンコメントすること) # #rlogin auth optional /usr/lib/security/$ISA/pam_krb5.so.1 try_first_pass #login auth optional /usr/lib/security/$ISA/pam_krb5.so.1 try_first_pass #dtlogin auth optional /usr/lib/security/$ISA/pam_krb5.so.1 try_first_pass #other auth optional /usr/lib/security/$ISA/pam_krb5.so.1 try_first_pass #dtlogin account optional /usr/lib/security/$ISA/pam_krb5.so.1 #other account optional /usr/lib/security/$ISA/pam_krb5.so.1 #other session optional /usr/lib/security/$ISA/pam_krb5.so.1 #other password optional /usr/lib/security/$ISA/pam_krb5.so.1 try_first_pass
さらに、winbind.so
行の後にtry_first_pass
行を追加することで、パスワードからのプロンプトが二重表示される問題を解消する。
Sambaを再起動して、pam.confで設定したアプリケーションから接続してみる。
Winbindシステムは、NSSとPAM及び適切なMicrosoft RPCコールを使用することで、UNIXシステム 上のMicrosoft Windows NTドメインユーザーのシームレスな統合を可能にした。その結果、UNIXと NTの混在するネットワークを運用する管理コストの大幅削減が実現さた。
Winbindは、現在のリリース版には、幾つかの制約があり、これは将来の リリースで克服していきたいと考えている:
Winbindは、現行では、他のOSへの移植は可能だが、Linux、Solaris、AIX、 及びIRIXのOSでのみ使用可能である。このような移植を実現するには、移植先の OSのCライブラリが、NSSとPAMシステムをサポートしていることが要件となる。 NSSとPAMがUNIXベンダーの間でサポートを得るようになってきたので、この二つの サポートは以前より一般的に見られるようになった。
Windows NT RIDからUNIX IDへのマッピングは、 アルゴリズムで決められる のではなく、マッピングされていないユーザーとグループをWinbindが目にした 順番に番号を振っていく。そのため、RIDとUNIX IDのマッピング情報を持つ ファイルが不良になったり壊れたりした場合、前と同じマッピングを再現 することは難しいかもしれない。
現行では、Winbind PAMのモジュールは、Windows NTユーザーに対して設定される ワークステーションのログオン時間などの制約を考慮しておらず、PDC が強制 するものと想定している。
いかなる状況でもwinbindd
が動作しているシステム上で
nscd
を動かさないこと。
もしもnscd
がUNIX/Linuxシステム上で動いている時、NSSWITCHが
正しく設定されていても、ファイルとディレクトリの管理のために、ドメインユーザーと
グループを解決することはできない。
「
smb.conf
ファイルは正しく設定した。
idmap uid = 12000と
idmap gid = 3000-3500を設定し、
winbind
を走らせている。以下を行うとすべてうまく行く。
」
root#
wbinfo -u
MIDEARTH\maryo MIDEARTH\jackb MIDEARTH\ameds ... MIDEARTH\rootroot#
wbinfo -g
MIDEARTH\Domain Users MIDEARTH\Domain Admins MIDEARTH\Domain Guests ... MIDEARTH\Accountsroot#
getent passwd
root:x:0:0:root:/root:/bin/bash bin:x:1:1:bin:/bin:/bin/bash ... maryo:x:15000:15003:Mary Orville:/home/MIDEARTH/maryo:/bin/false
「 ところが、以下のコマンドは失敗する: 」
root#
chown maryo a_file
chown: `maryo': invalid user
「 気が変になりそうなのだが何がいけないのだろう? 」
前記の問題と同じである。使用しているシステムは、恐らくnscd
を動作させて
いるのだろう。システムを再起動ではなく一旦シャットダウンすれば、その後では、問題は解消して
いるだろう。