Table of Contents
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 経由)
ID 解決 (NSS 経由)
Winbind は、winbind_idmap.tdb と呼ばれるデータベースを維持し、その中に、UNIX UID/GID と NT SID 間のマッピング情報を格納します。このマッピングは、ローカル UID/GID を持たないユーザーまたはグループにのみ使用します。idmap uid/gid の範囲から割り当てられ、NT の SID にマッピングされた UID/GID が格納されます。 idmap backend が ldapsam:url に指定されている場合、 ローカルのマッピングを使用する代わりに、Winbind は、この情報を LDAP データベースから取得します。
winbindd が実行中ではないとき、smbd (winbindd を呼び出す方) は、代替手段として純粋にローカルな /etc/passwd 及び /etc/group からの情報を使用することにし、動的マッピングは使用しません。
UNIX と Microsoft Windows NT では、ユーザー及びグループ情報の見せ方の モデルも、それを実行するために使用している技術も異なるのは周知の事実です。 これが、二つのシステムを統合して、満足の行く運用をすることを困難にしてきました。
これに対してよく行われる解決策は、UNIX と Windows の両システム上に 全く同名のユーザー・アカウントを作成し、Samba のプログラム・スイートを使用して、 両システム間のファイル・サービスと印刷サービスを提供するというやり方でした。 ただし、この解決策は、双方のマシンにユーザーを追加したり削除したりする作業が 面倒で、パスワードも 2 セット持たなければならず、その両方が UNIX と Windows システム間の同期のずれの問題につながり、ユーザーの混乱を招くという、 完璧には程遠いものです。
UNIX マシンのための統一されたログオンという課題を、次のように三つの 構成部分に分けることができます。
Windows NT のユーザー及びグループ情報を取得する。
Windows NT ユーザーを認証する。
Windows NT ユーザーのためにパスワードを変更する。
理想を言えば、統一されたログオンの課題の解決法は、UNIX 側のマシン上に 情報を複製することなく、上記三つのタスクを全て実行することができ、しかも、 ユーザーやグループ情報をどちらのシステムで維持しても、システム管理者の仕事を 増やさないというものであってほしいです。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 セッションを実行することも できます。
Winbind が使用されていることが明らかにわかるところは、ユーザー及び グループの名前が DOMAIN\user 及び DOMAIN\group の形を取るという点だけです。これは、Winbind が、特定のルックアップについては ドメイン・コントローラーへのリダイレクトをする決定をするために、また、 信頼関係のあるどのドメインが参照先なのかを決定するために必要です。
また、Winbind は、Pluggable Authentication Modules (PAM) システムに繋がる 認証サービスを提供し、NT ドメインを経由して、PAM 対応のあらゆるアプリケーションに 対して認証を行います。この機能は、一つの場所 (ドメイン・コントローラー上) に全てのパスワードが格納されるため、システム間のパスワード同期の問題を解消します。
既存の NT ベースのドメイン基盤を持っており、それに UNIX ワークステーションまたはサーバーを組み入れたいという要望のある組織が Winbind の対象となります。Winbind により、このような組織は別個の アカウント基盤を管理する必要なく、UNIX のワークステーションを展開する ことができます。これは、NT ベースの組織に UNIX ワークステーションを 展開するための間接費を大幅に軽減します。
Winbind のもう一つの興味深い使用方法は、UNIX ベースの装置の 中心部分に使用することです。Microsoft ベースのネットワークに ファイル・サービスと印刷サービスを提供する装置は、Winbind を使用することで、 ドメインとしてシームレスに統合されます。
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 インターフェースは、Winbind を OS に繋がり易くします。 必要な手続きは、/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 マシンにログインでき、適切な プライマリ・ドメイン・コントローラーの認証を受けることができるように なります。このようなユーザーはパスワードの変更もできる上、 その変更内容をプライマリ・ドメイン・コントローラーに直に反映させる ことができます。
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 にマッピングされていくことを確保しています。
動作中のシステムは実に多くのユーザー名やグループ名の検索を要請します。 これらの検索に係るネットワークの負担を軽減するため、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 デーモンが入っています。 ソースコードをダウンロードする手順については、 Samba のウェブサイト または最寄の Samba ミラーサイトにある説明を参照ください。
ドメイン・ユーザーが Samba の共有やファイルにアクセスできるようにし、またご使用の マシンが提供するその他のサービスにもアクセスできるようにするには、PAM をご使用の マシン上で正しく設定しなければなりません。Winbind モジュールをコンパイルするには、 システム上に最低でも PAM 開発ライブラリがインストールされていなければなりません。 PAM のウェブサイトを参照ください。 http://www.kernel.org/pub/linux/libs/pam/
開始する前に、ご使用のサーバー上で走っている全ての Samba 関連のデーモンを止めておく方が 良いでしょう。走っているかもしれない smbd、 nmbd、 及び winbindd の全プロセスを 止めてしてください。PAM を使用するには、PAM-aware サービスが使用する PAM モジュール、 複数の pam ライブラリ、及び PAM のための /usr/doc と /usr/man のエントリーを含む、/etc/pam.d のディレクトリ構造を提供する、標準の PAM パッケージを持っていることを確認してください。 Winbind を Samba 内で構築する際、pam-devel パッケージをインストールしていると、 よりよくできます。このパッケージには、PAM-aware のアプリケーションをコンパイルするのに 必要なヘッダー・ファイルが含まれます。
PAM は、最新世代の UNIX/Linux システムの標準コンポーネントです。しかし、残念ながら PAM 対応の Samba を構築するのに必要な pam-devel ライブラリを インストールするシステムは数が限られています。また、Samba-3 は Winbind ファイルをご使用の システム上の正しい位置に自動インストールするかもしれません。そこでこれ以上先に進む前に、 以下に説明する設定が本当に必要かどうか確認してください。もしかしたら、 /etc/nsswitch.confの設定だけで済むかもしれません。
winbindd デーモンを 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
次に、winbindd デーモンからユーザーやグループのエントリーが見えるように、 root として、/etc/nsswitch.conf を編集しなければなりません。 私の /etc/nsswitch.conf ファイルはこの編集後、 以下のようになりました:
passwd: files winbind shadow: files group: files winbind
winbindd デーモンが必要とするライブラリは、次回システムが 再起動するときに自動的に ldconfig のキャッシュに入りますが、 手動で以下を行う方が早いです。(それに、再起動する必要もありません。)
root# /sbin/ldconfig -v | grep winbind
これにより、winbindd が libnss_winbind を使える状態になり、 確認のエコーバックをします。
(この項は AIX を使用している方のみ、お読みください。)
Winbind AIX 識別モジュールは、Samba ソースの nsswitch ディレクトリ内に libnss_winbind.so として構築されます。このファイルは、 /usr/lib/security にコピーでき、AIX の名前変換から、 WINBIND という名前にするべきであると言ってきます。以下に示す stanza を
WINBIND: program = /usr/lib/security/WINBIND options = authonly
/usr/lib/security/methods.cfg に追加することができます。 このモジュールは識別のみサポートしますが、標準の Winbind PAM モジュールを 認証に使用して成功した例が報告されています。ローダブルな認証モジュールの設定の際には、 システムにログオンできない状態になってしまうこともあり得るので、 慎重に行ってください。AIX 認証モジュール API に関する詳細情報は、18章の “AIX のためのカーネル拡張機能とデバイス・サポート・プログラミングのコンセプト” の項を参照ください。(18章にはそのような項はありません。) ローダブルな認証モジュールのプログラミング・インターフェースとこれらのモジュールの管理に関する詳細は、 “システム管理ガイド: OS とデバイス” を参照ください。
smb.conf ファイルの中に、winbindd の動作を制御するための幾つかのパラメーターを設定する 必要があります。これについては、winbindd(8) の man ページに、より詳細に説明されています。 次の例に使用する私の smb.conf ファイルは、[global] セクションの中の必要なエントリーも含むように変更したものです。
Example 21.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 |
以下のコマンドを入力し、Windows ドメインの名前が DOMAIN であり、そのドメインの管理権限を持つドメイン・ユーザーが Administrator であるところの PDC ドメインに、 Samba サーバーを参加させます。
root# /usr/local/samba/bin/net rpc join -S PDC -U Administrator
このコマンドへの正しい解答は、“Joined the domain DOMAIN (DOMAIN というドメインに参加しました。)” であり、 このとき DOMAIN が、ご使用のドメイン名であるはずです。
最終的には、Samba のその他の部分が立ち上がるときに、自動的に winbindd デーモンを呼び出すように、Samba の起動スクリプトを変更したいと思われる でしょうが、Winbind 部分だけを最初にテストしておくことは可能です。 Winbind のサービスを立ち上げるには、以下のコマンドを root として 入力してください:
root# /usr/local/samba/bin/winbindd
上記は、/usr/local/samba のディレクトリ・ツリーの中に Samba を インストールしたと仮定しています。ご使用のシステム上で winbindd が別のところに入っている場合は、Samba のファイルの場所を探す必要があります。
Winbindd は、“デュアル・デーモン・モード” でも走らせることができます。 これは、二つのプロセスとして走らせることを意味します。最初のプロセスは全ての リクエストにキャッシュから答えることにより、クライアントへの回答を速くします。 もう一つのプロセスは、最初のプロセスが回答したクエリーのキャッシュを直後に更新します。 この方法の長所は、回答が常に正確でかつ速くなるということです。デュアル・デーモン・モード は、コマンドラインに -B を付け足すことで有効になります:
root# /usr/local/samba/bin/winbindd -B
私は心配性なのでデーモンが本当に走っているか、必ず確認したくなります:
root# ps -ae | grep winbindd
このコマンドは、デーモンが走っているなら、以下のような報告を返してくるはずです:
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
winbindd デーモンは、smbd 及び nmbd のデーモンが走り出してから起動する 必要があります。これを行うには起動スクリプトを書き換えます。起動スクリプトは、 Red Hat Linuxでは、/etc/init.d/smb に、Debian Linuxでは /etc/init.d/samba に入っています。これらのデーモンを 正しい順序で走らせるためのコマンドをスクリプトに加えます。私の起動スクリプトは、 /usr/local/samba/bin のディレクトリから、直接 smbd、 nmbd、winbindd の順に起動します。このスクリプトの 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/bin/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/bin/winbindd
の列を、以下に変えてください:
daemon /usr/local/samba/bin/winbindd -B
.
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 では動きません。Solaris 9 でのWinbind の項を参照ください。
Solaris では、/etc/init.d/samba.server 起動スクリプトを 変更する必要があります。また、通常は smbd と nmbd は起動しますが、winbindd は 起動するべきではありません。/usr/local/samba/bin に Samba をインストールしている場合、このファイルに以下のようなものが入っているはずです:
## ## samba.server ## if [ ! -d /usr/bin ] then # /usr がマウントされていない exit fi killproc() { # names プロセスを停止 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/bin/winbindd ;; 'stop') killproc nmbd killproc smbd killproc winbindd ;; *) echo "Usage: /etc/init.d/samba.server { start | stop }" ;; esac
また、Sambaがデュアル・デーモン・モードを実行するようにしたい場合は、上記の:
/usr/local/samba/bin/winbindd
の部分を、下記に変えてください:
/usr/local/samba/bin/winbindd -B
ここまで来たということは、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 グローバルエントリで 簡単に設定できます。
/etc/pam.d/ftp ファイルは、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 システムは、Name Service Switch、Pluggable Authentication Modules、 及び適切な Microsoft RPC コールを使用することで、UNIX システム上の Microsoft Windows NT ドメイン・ユーザーのシームレスな統合を可能にしました。その結果、 UNIX とNT の混在するネットワークを運用する管理コストの大幅削減が実現されました。
Winbind は、現在のリリース版には、幾つかの制約があり、これは将来の リリースで克服していきたいと考えています:
Winbind は、現行では、他の OS へのポートは可能では ありますが、Linux、Solaris、AIX、及び IRIX の OS でのみ使用可能です。 このようなポートを実現するには、ポート先の OS の C ライブラリが、 Name Service Switch と Pluggable Authentication Modules の二つの システムをサポートしていることが要件となります。NSS と PAM が UNIX ベンダーの間でサポートを得るようになってきましたから、この二つの サポートは以前より一般的に見られるようになりました。
Windows NT RID から UNIX ID へのマッピングは、 アルゴリズムで決められるのではなくマッピングされていないユーザーと グループを Winbind が目にした順番に番号を振っていきます。ですから、 RID と UNIX ID のマッピング情報を持つファイルが不良になったり 壊れたりした場合、前と同じマッピングを再現することは難しいかもしれません。
現行では、Winbind PAM のモジュールは、Windows NT ユーザーに対して設定されるワークステーションのログオン時間などの制約を 考慮しておらず、PDC が強制するものと想定しています。
いかなる状況でも、winbindd が走っているシステムでは、 nscd を走らせないでください。
nscd UNIX/Linux システム上で nscd が走っているとき、 NSSWITCH が正しく設定されていても、ファイルとディレクトリの管理のために、 ドメイン・ユーザーとグループを解決することはできません。
“ smb.conf ファイルは正しく設定されています。idmap uid = 12000 と指定し、また idmap 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 (name service caching daemon) を走らせているのでしょう。システムを再起動ではなく 一旦シャットダウンしてください。その後では、問題は解消しているでしょう。