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 の最新バージョンには、正常に機能する 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 は 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を動作させて いるのだろう。システムを再起動ではなく一旦シャットダウンすれば、その後では、問題は解消して いるだろう。