Chapter 24. Winbind: ドメインアカウントの使用
Prev | Part III. 詳細な設定方法 | Next

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

### Tim Potter

Samba Team

`<tpot@linuxcare.com.au>`

### Andrew Tridgell

Samba Team

`<tridge@samba.org>`

### Naag Mummaneni

Notes for Solaris

`<getnag@rediffmail.com>`

### John Trostel

SNAP

`<jtrostel@snapserver.com>`

### Jelmer R. Vernooij

The Samba Team

`<jelmer@samba.org>`

### John H. Terpstra

Samba Team

`<jht@samba.org>`

June 15, 2005

## 機能と利便性

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 backend`が `ldap:ldap://hostname[:389]`に指定されている場合、 ローカルのマッピングを使用する代わりに、Winbindは、この情報をLDAP データベースから取得する。

### Note

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

Figure 24.1. 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\user`と`DOMAIN\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.conf`に“winbind”を追加 するだけである。これで、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関連のデーモンを止めておくことを推奨する。動いているかもしれないsmbd、nmbd、及び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.1root# ln -s /usr/lib/libnss_winbind.so /usr/lib/nss_winbind.so.1root# ln -s /usr/lib/libnss_winbind.so /usr/lib/nss_winbind.so.2

次に、rootになって、winbindd daemonからユーザやグループのエントリが見えるように、`/etc/nsswitch.conf`を編集する。たとえば`/etc/nsswitch.conf`ファイルを以下のように編集する:

    passwd:     files winbindshadow:     filesgroup:      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#  crleConfiguration 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”という文書にある。モジュールの管理に関するさらなる情報は、SystemManagement 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 domain`DOMAIN`”である。ここで、`DOMAIN`は対象のドメイン名である。

#### `winbindd`daemonの開始とテスト

最終的には、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\AdministratorCEO\burdellCEO\GuestCEO\jt-adCEO\krbtgtCEO\TsInternetUser

もちろん、ドメイン名は“CEO”で、winbind separatorは“\”である。

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

    root# /usr/local/samba/bin/wbinfo -gCEO\Domain AdminsCEO\Domain UsersCEO\Domain GuestsCEO\Domain ComputersCEO\Domain ControllersCEO\Cert PublishersCEO\Schema AdminsCEO\Enterprise AdminsCEO\Group Policy Creator Owners

ここで、`getent`コマンドを使用して、ローカルとPDCの両方からユーザとグループの統合された一覧を表示させることができる。以下のコマンドを入力する:

    root# getent passwd

`/etc/passwd`のような、ドメインユーザの新しいUID、GID、ホームディレクトリ及び既定値のシェルが表示される一覧が出てくるはずである。

グループについても同様に以下のコマンドを実行できる:

    root# getent group

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

##### Linux

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}

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

### 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=succeedauth       sufficient   /lib/security/pam_winbind.soauth       required     /lib/security/pam_stack.so service=system-authauth       required     /lib/security/pam_shells.soaccount    sufficient   /lib/security/pam_winbind.soaccount    required     /lib/security/pam_stack.so service=system-authsession    required     /lib/security/pam_stack.so service=system-auth

`/etc/pam.d/login`ファイルもほぼ同様に変更できる。以下のようになる:

    auth       required     /lib/security/pam_securetty.soauth       sufficient   /lib/security/pam_winbind.soauth       sufficient   /lib/security/pam_unix.so use_first_passauth       required     /lib/security/pam_stack.so service=system-authauth       required     /lib/security/pam_nologin.soaccount    sufficient   /lib/security/pam_winbind.soaccount    required     /lib/security/pam_stack.so service=system-authpassword   required     /lib/security/pam_stack.so service=system-authsession    required     /lib/security/pam_stack.so service=system-authsession    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.sologin auth required  /usr/lib/security/$ISA/pam_unix.so.1 try_first_passlogin auth required  /usr/lib/security/$ISA/pam_dial_auth.so.1 try_first_pass#rlogin  auth sufficient /usr/lib/security/pam_winbind.sorlogin  auth sufficient /usr/lib/security/$ISA/pam_rhosts_auth.so.1rlogin auth required  /usr/lib/security/$ISA/pam_unix.so.1 try_first_pass#dtlogin auth sufficient /usr/lib/security/pam_winbind.sodtlogin auth required  /usr/lib/security/$ISA/pam_unix.so.1 try_first_pass#rsh auth required /usr/lib/security/$ISA/pam_rhosts_auth.so.1other   auth sufficient /usr/lib/security/pam_winbind.soother auth required /usr/lib/security/$ISA/pam_unix.so.1 try_first_pass## アカウント管理#login   account sufficient      /usr/lib/security/pam_winbind.sologin account requisite /usr/lib/security/$ISA/pam_roles.so.1login account required /usr/lib/security/$ISA/pam_unix.so.1#dtlogin account sufficient      /usr/lib/security/pam_winbind.sodtlogin account requisite /usr/lib/security/$ISA/pam_roles.so.1dtlogin account required /usr/lib/security/$ISA/pam_unix.so.1#other   account sufficient      /usr/lib/security/pam_winbind.soother account requisite /usr/lib/security/$ISA/pam_roles.so.1other 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.soother password required /usr/lib/security/$ISA/pam_unix.so.1dtsession 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 = 12000と idmap gid = 3000-3500を設定し、 `winbind`を走らせている。以下を行うとすべてうまく行く。 ”

    root# wbinfo -uMIDEARTH\maryoMIDEARTH\jackbMIDEARTH\ameds...MIDEARTH\rootroot# wbinfo -gMIDEARTH\Domain UsersMIDEARTH\Domain AdminsMIDEARTH\Domain Guests...MIDEARTH\Accountsroot# getent passwdroot:x:0:0:root:/root:/bin/bashbin:x:1:1:bin:/bin:/bin/bash...maryo:x:15000:15003:Mary Orville:/home/MIDEARTH/maryo:/bin/false

“ところが、以下のコマンドは失敗する:”

    root# chown maryo a_filechown: `maryo': invalid user

“気が変になりそうなのだが何がいけないのだろう?”

前記の問題と同じである。使用しているシステムは、恐らく`nscd`を動作させているのだろう。システムを再起動ではなく一旦シャットダウンすれば、その後では、問題は解消しているだろう。

Prev | Up | Next
Chapter 23. スタッカブルVFSモジュール | Home | Chapter 25. 詳細なネットワーク管理