Chapter 24. Winbind: ドメインアカウントの使用

Tim Potter

Andrew Tridgell

Samba Team

Naag Mummaneni

Notes for Solaris 

John Trostel

Jelmer R. Vernooij

The Samba Team

John H. Terpstra

Samba Team

June 15, 2005

Table of Contents

機能と利便性
はじめに
Winbindが提供するもの
対象となるユーザ
外部のSIDの取り扱い
Winbindの動き方
Microsoft Remote Procedure Calls
Microsoft Active Directoryサービス
Name Service Switch
Pluggable Authentication Modules
ユーザとグループIDの割り当て
結果のキャッシュ保存
インストールと設定
はじめに
用件
テスト
結論
よくあるエラー
NSCDの問題に関する警告
Winbindがユーザとグループを解決しない

機能と利便性

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システムにログオンすることを可能にする。

  • IDの解決(NSS経由)。これは、winbindが使われなかった時の既定値である。

  • Winbindは、winbind_idmap.tdbと呼ばれるデータベースを維持し、その中に、 UNIX UID/GIDとNT SID間のマッピング情報を格納する。このマッピングは、 ローカルUID/GIDを持たないユーザまたはグループにのみ使用する。 idmap uid/gid の範囲から割り当てられ、NTのSIDにマッピングされた UID/GIDが格納される。idmap backendldap:ldap://hostname[:389]に指定されている場合、 ローカルのマッピングを使用する代わりに、Winbindは、この情報をLDAP データベースから取得する。

Note

もしもwinbinddが実行中ではないとき、smbd (winbinddを呼び出す方)は、代替手段として純粋にローカルな /etc/passwd/etc/groupからの情報を 使用することにし、動的マッピングは使用しない。OSでNSSが有効になっている場合、 ユーザとグループ情報の解決はNSS経由で行われる。

Figure 24.1. Winbind Idmap

Winbind Idmap

はじめに

UNIXとMicrosoft Windows NTでは、ユーザ及びグループ情報の見せ方のモデルも、 それを実行するために使用している技術も異なるのは周知の事実である。これが、 二つのシステムを統合して、満足の行く運用をすることを困難にしてきた。

これに対してよく行われる解決策は、UNIXとWindowsの両システム上に全く同名の ユーザアカウントを作成し、Sambaを使用して、両システム間のファイルサービスと 印刷サービスを提供するというやり方であった。ただし、この解決策は、双方の マシンにユーザを追加したり削除したりする作業が面倒でパスワードも2セット 持たなければならず、その両方がUNIXとWindowsシステム間の同期のずれの問題に つながり、ユーザの混乱を招くという、完璧には程遠いものである。

UNIX マシンのための統一されたログオンという問題を、次のように三つの 構成要素に分けることができる:

  • Windows NTのユーザ及びグループ情報を取得する。

  • Windows NT ユーザを認証する。

  • Windows NT ユーザのためにパスワードを変更する。

理想的には、統一されたログオンという問題の解決方法は、UNIXマシン上に情報を複製する ことなく、上記の問題を全て満足させ、しかも、 ユーザやグループ情報をどちらの システムで維持しても、システム管理者の仕事を増やさないというものであってほしい。 Winbind システムは、統一されたログオンという問題の三つの構成要素を簡単に優雅に こなすソリューションを提供するものである。 problem.

Winbindが提供するもの

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\userDOMAIN\groupの形を取ると いう点だけである。これは、Winbind が、信頼関係のあるドメインに参照するの特定の 検索について、ドメインコントローラへのリダイレクト決めるために必要である。

さらに、Winbind は、PAMシステムのhookとしての認証サービスを提供し、NTドメインを 経由して、PAM対応のあらゆるアプリケーションに対して認証を行う。この機能は、一カ所 (ドメインコントローラ上)に全てのパスワードが格納されるため、システム間の パスワード同期の問題を解消する。

対象となるユーザ

NTベースのドメイン基盤がすでにあり、それにUNIX ワークステーションか サーバを組み入れたいという要望のある組織がWinbindの対象となる。Winbind より、このような組織は別個のアカウント基盤を管理する必要なく、UNIX ワークステーションを展開することができる。これは、NTベースの組織にUNIX ワークステーションを展開するための間接費を大幅に軽減する。

Winbind のもう一つの興味深い使用方法は、UNIXベースの装置の中心部分に 使用することである。Microsoftベースのネットワークにファイルサービスと 印刷サービスを提供する装置は、Winbindを使用することで、ドメインに シームレスに統合される。

外部のSIDの取り扱い

外部の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の動き方

Winbindシステムは、クライアント/サーバアーキテクチャを想定し設計されたもので ある。長時間走り続けるwinbinddデーモンがUNIXドメイン ソケット上でリクエストが来るのを待つ。これらのリクエストは、NSS及びPAM クライアントにより生成され、順番に処理される。

Winbind を実装するのに使用されている技術を以下に詳述する。

Microsoft Remote Procedure Calls

過去数年間、Sambaチームの多くのメンバが、Microsoftリモートプロシージャ コール(MSRPC)システムの各側面を解明しようと努力してきた。このシステムは、 リモート管理、ユーザ認証、印刷スプーリングを含むWindows NTマシン間の ネットワーク関連操作の大半に使用されている。当初、Sambaへのプライマリ ドメインコントローラ(PDC)機能の実装を支援するために 着手した作業で あったが、結果としてそれ以外の目的に使用できる一連のコードを得ることが できた。

winbind はドメインユーザとグループを列挙し、個々のユーザやグループの詳細 情報を取得するために、各種のMSRPC コールを使用する。他のMSRPC コールは、 NTドメインユーザを認証し、ユーザのパスワードを変更するために使用できる。 Windows PDCに、直接ユーザ及びグループ情報を問い合わせることで、Winbindは、 NTのアカウント情報をUNIXユーザ名とグループ名にマッピングする。

Microsoft Active Directoryサービス

2001年後半より、SambaはNT4のRPC サービスではなく、ネイティブモード のプロトコルを使用して、Microsoft Windows 2000とやり取りする機能を持つ ようになった。LDAP及びKerberosを使用し、winbindを走らせている ドメイン メンバは、Windows 200xクライアントの世界で行われるのと全く同じように、 ユーザとグループを列挙でき、そうすることによってより効率的で効果的な winbind の実装を提供する。

Name Service Switch

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.confwinbindを追加 するだけである。これで、Cライブラリは、Winbindを呼んでユーザ名や グループ名を解決できるようになる。

Pluggable Authentication Modules

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の説明を参照のこと。

ユーザとグループIDの割り当て

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管理者がドメインメンバの認証のために、Windows NT/200x PDCの認証機構を 頼れるようになる。Windows NT/200xユーザは、Sambaサーバ上に別のアカウントを持つ必要が なくなる。

  • この文書は誰が読むべきものか?

    この文書はシステム管理者のためのものである。この文書は、Sambaをファイルサーバ上に実装する 予定であり、既存のWindows NT/200xユーザを、PDCからSambaサーバへ(比較的簡単に)統合したい 場合のものである。

用件

現在使用しているSamba設定ファイルがあるなら、バックアップを取ること!。 使用中のシステムが既にPAMを使用しているなら、 /etc/pam.dディレクトリの内容をバックアップすること!。 起動ディスクをまだ作成していないのなら今すぐに作ること!

PAM設定ファイルを間違って修正すると、使用中のマシンにログインするのがほとんど不可能に なってしまうことがある。このため、うまくいかない時にはマシンをシングルユーザモードで 立ち上げ、/etc/pam.dを元の状態に戻せるようにすること。

Samba-3の最新バージョンには、正常に機能する winbindd daemonが含まれている。ソースコードを ダウンロードする手順については、 Samba Webページか 最寄のSamba ミラーサイトにある説明を参照のこと。

ドメインユーザがSambaの共有やファイルにアクセスできるようにし、また使用するマシンが 提供するその他のサービスにもアクセスできるようにするには、PAMを使用するマシン上で正しく 設定しなければならない。Winbindモジュールをコンパイルするには、PAM開発ライブラリを インストールすべきである。 PAMのウェブサイトを参照のこと。

テスト

開始する前に、使用しているサーバ上で走っている全てのSamba関連のデーモンを止めておくことを 推奨する。動いているかもしれないsmbdnmbd、及びwinbinddの全プロセスを停止する。 PAMを使用するには、PAMを認識するサービスが使用するPAMモジュール、複数のPAMライブラリ、及び PAMのための/usr/doc/usr/manのエントリを含む、 /etc/pam.dのディレクトリ構造を提供する、標準PAM パッケージを持って いることを確認する。WinbindをSamba内で構築する際、pam-devel パッケージをインストールして いると、よりうまくいく。このパッケージには、PAMを認識するアプリケーションをコンパイルする のに必要なヘッダファイルが含まれる。

nsswitch.confとWinbindライブラリをLinuxとSolaris上で設定する

PAMは、最新世代のUNIX/Linuxシステムの標準コンポーネントである。しかし、残念ながら PAM対応のSambaを構築するのに必要なpam-develライブラリをインストール しているシステムは数が限られている。また、Samba-3は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

さらに、Sun Solarisの場合は以下が必要である:

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におけるNSS Winbind

(この節は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にある。

smb.confの設定

winbinddの動作を制御するために、smb.confファイルにいくつかのパラメータを設定する必要が ある。これについては、winbindd(8)マニュアルページに、より詳細に説明されている。 以下のWinbind設定のためのsmb.confによるsmb.confは、 [global]セクションの中の必要なエントリーも含むように変更したものである。

Example 24.1. Winbind設定のためのsmb.conf

[global]
# DOMAIN\username のように、ドメインとユーザ名を '\'を挟んで分ける。
winbind separator = \
# ドメインユーザには、10000から20000のUIDを使用する。
idmap uid = 10000-20000
# ドメイングループには、10000から20000のGIDを使用する。
idmap gid = 10000-20000
# winbindユーザとグループの列挙を可能にする。
winbind enum users = yes
winbind enum groups = yes
# winbind ユーザに本当のシェルを与える(telnetアクセスを持つ場合のみ必要)
template homedir = /home/winnt/%D/%U
template shell = /bin/bash

SambaサーバをPDCドメインに参加させる

ドメインセキュリティに関与するすべてのマシンはドメインのメンバであるべきである。 これはPDCとすべてのBDCにも適用される。

ドメインへの参加手続きは、net rpc joinコマンドを使って行う。この 手続きは、MS DCE RPC経由で登録された(通常はPDC)ドメインコントローラと通信を行う。これは、 もちろん、smbdプロセスが対象のドメインコントローラ上で動作 していなければならないということである。それ自身のドメインに参加できるように、一時的に PDCとしてSambaを起動することは、そのために必要である。

PDCという名前のPDCで、ドメイン中で管理者権限を持つドメイン ユーザがAdministratorである時、以下のコマンドを入力し、 Sambaサーバをドメインに参加させる。

Note

ドメインにマシンを参加させる前に、対象のドメインコントローラ(通常はPDC)でSambaが 動作しているかを確認し、ポート137/udp, 135/tcp, 139/tcp, と 445/tcpが開いているかを 確認する(もしもPDCがSambaかWindows Server 2Kxの場合)。

net rpc join機能の使用方法は以下の通り:

root# /usr/local/samba/bin/net rpc join -S PDC -U Administrator

このコマンドへの正しい解答は、Joined the domainDOMAIN である。ここで、DOMAINは対象のドメイン名である。

winbindddaemonの開始とテスト

最終的には、Sambaのその他の部分が立ち上がるときに、自動的にwinbindd daemonを呼び出す ように、Sambaの起動スクリプトを変更したいと思うかもしれないが、Winbind部分だけを最初に テストしておくことは可能である。Winbind のサービスを立ち上げるには、以下のコマンドを rootとして入力する:

root# /usr/local/samba/sbin/winbindd

winbindd実行ファイルの位置への適切なパスを使用すること。

Note

上記は、/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\である。

同様にPDCからグループ情報を取得することができる:

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

init.d起動スクリプトの修正

Linux

winbindd daemonはsmbdnmbd 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
}
Solaris

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

再起動

この時点でsmbd, nmbd, と winbindd daemonを再起動すると、まるでローカルユーザで あるかのように、Sambaサーバにドメインメンバとして接続できるはずである。

WinbindとPAMの設定

ここまで来たということは、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

Linux/FreeBSD固有のPAM設定

/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.conftemplate homedir グローバルエントリで簡単に設定できる。

Note

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行の後に加え、パスワードからのプロンプトが二重表示される 問題を解消した。

Solaris固有の設定

/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 が強制 するものと想定している。

NSCDの問題に関する警告

Warning

いかなる状況でもwinbinddが動作しているシステム上で nscdを動かさないこと。

もしもnscdがUNIX/Linuxシステム上で動いている時、NSSWITCHが 正しく設定されていても、ファイルとディレクトリの管理のために、ドメインユーザと グループを解決することはできない。

Winbindがユーザとグループを解決しない

smb.confファイルは正しく設定した。 idmap uid = 12000idmap gid = 3000-3500を設定し、 winbindを走らせている。以下を行うとすべてうまく行く。

root# wbinfo -u
MIDEARTH\maryo
MIDEARTH\jackb
MIDEARTH\ameds
...
MIDEARTH\root

root# wbinfo -g
MIDEARTH\Domain Users
MIDEARTH\Domain Admins
MIDEARTH\Domain Guests
...
MIDEARTH\Accounts

root# 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を動作させて いるのだろう。システムを再起動ではなく一旦シャットダウンすれば、その後では、問題は解消して いるだろう。