目次


Linux の 302 (Mixed Environment) 試験対策

Winbind

Windows ドメイン・コントローラーを使用して Linux のアカウントを管理する

Comments

コンテンツシリーズ

このコンテンツは全#シリーズのパート#です: Linux の 302 (Mixed Environment) 試験対策

このシリーズの続きに乞うご期待。

このコンテンツはシリーズの一部分です:Linux の 302 (Mixed Environment) 試験対策

このシリーズの続きに乞うご期待。

概要

この記事では、以下の内容について学びます。

  • Winbind のインストール
  • Winbind の構成

この記事は、LPIC-3 Specialty「302 Mixed Environment Exam」試験の主題 313 の目標 313.3 の試験対策となります。この目標の重要度は 2 です。

前提条件

この連載記事を最大限に活用するには、Linux の高度な知識と、この記事で説明するコマンドを演習できる実際の Linux システムが必要です。具体的には、この記事では読者が Linux コマンドライン関数の実用的知識を持っていること、「Linux の 302 (Mixed Environment) 試験対策: 概念」で説明している Samba の目的について少なくとも全般的に理解していること、そしてドメイン・コントローラーを使用するように Samba を構成する方法を含め、Samba の構成についての基礎知識があることを前提とします。また、smb.conf 構成ファイルの全体的な構成を十分に理解していること、System V (SysV) 起動スクリプトとスーパー・サーバーの用途を含め、一般的なサーバーがどのようにして動作するかについても理解していることが必要です。この記事で説明する情報を使用するには、実際に Windows ドメインにアクセスできなければなりません (Samba が管理するドメインか、Windows Server オペレーティング・システムを実行しているコンピューターが管理するドメインを使用することができます)。

Winbind の概要

Linux の 302 (Mixed Environment) 試験対策: Samba の役割」および「Linux の 302 (Mixed Environment) 試験対策: ドメイン制御」で説明したように、Windows ネットワークにはドメイン・コントローラーが存在することがよくあります。ドメイン・コントローラーとは、ネットワーク内のすべての Windows コンピューターの認証を管理するコンピューターのことです。このようなドメイン・コントローラーを構成することで、多数のユーザーとコンピューターを抱えるネットワークでの作業が極めて簡単なものになります。それは、ユーザー・アカウント情報を複数のコンピューターに複製して管理する必要がなくなり、代わりに Windows アカウント情報のすべてを 1 台のコンピューターに集約できるためです。これにより、管理者には 1 ヶ所でアカウントを管理できるという利点がもたらされ、ユーザーには自分のパスワードを一度変更すれば、その変更がドメインのすべてのメンバー・コンピューターに適用されるという利点があります。

Samba サーバーにさまざまなオプションを設定することで、Samba サーバーをドメインのメンバーとして構成することができます。以下に記載するのは、ドメインに参加するための一般的なグローバル・オプション一式の設定例です。

security = Domain
password server = CONTROL
domain logons = No
encrypt passwords = Yes

ドメイン・コントローラーが Microsoft Active Directory ドメイン・サービスの機能をサポートする場合には、security = Domain ではなく、security = ADS と設定することもできます。Samba サーバーをドメインに参加させるには、net join member -U adminuser (ここで、adminuser はドメインの管理アカウントです) というコマンドを実行する必要もあります。Samba サーバーをドメイン・メンバーとして構成する方法についての詳細は、「Linux の 302 (Mixed Environment) 試験対策: Samba の役割」を参照してください。

Samba サーバーに関してはこれで十分ですが、Samba は Linux コンピューターで実行できるサーバーの 1 つに過ぎません。他のサーバーやローカル・ログイン・サービスも、原則的にはドメイン・コントローラーの恩恵を受けられるはずです。例えば、ネットワーク上で Linux ワークステーションとして機能しているコンピューターや、Linux コンピューター上で実行されている POP (Post Office Protocol) e-メール・サーバーに、認証の際にドメイン・コントローラーを使用するようにさせたい場合もあります。そこで登場するのが Winbind です。Winbind は、Linux が Samba 以外の認証タスクに Windows ドメインのアカウントを使用できるようにするための橋渡しをする役割を担います。

Winbind を構成する際には、その前に Winbind に関する制約を理解しておく必要があります。まず、Linux のアカウントが必要とする UNIX スタイルのユーザー ID (UID) やグループ (GID) は、Windows ドメインにはありません。その理由は、Microsoft のドメイン認証の方法は Windows の要求を念頭に設計されているからです。Windows ドメインでこれらの ID の代わりとなるのはセキュリティー ID ですが、セキュリティー ID は、Linux の UID と GID に直接対応するわけではありません。また、ドメイン・コントローラーは UNIX/Linux の home ディレクトリーの情報を保存しないため、Winbind では Linux のこの情報の一部をローカルで作成しなければならないという制約もあります。大抵はそれでも問題ありませんが、これは、Winbind を使用する 2 台の Linux コンピューターが、1 人のユーザーに対してそれぞれに異なる UID と GID を作成する可能性も大いにあり得ることを意味します。この可能性が現実のものとなり、その 2 台の Linux コンピューターが NFS (Network File System) を使用してファイルを共有しているとしたら、マイナスの影響は避けられません。NFS では、ネットワーク内の全サーバーでユーザーの UID と GID に矛盾があってはならないからです。そのような場合には、ネットワークに LDAP (Lightweight Directory Access Protocol) サーバーを構成して、そのアカウント・データベースを Linux アカウントと Windows ドメイン・アカウントの両方に使用したほうが無難でしょう。

Winbind は以下の設定内容に応じた動作をします。

  • smb.conf 内の Winbind 固有のオプション
  • 最近の Linux インストールに標準で含まれている PAM (Pluggable Authentication Modules) サブシステムの構成オプション
  • 最近の Linux インストールに標準で含まれている NSS (Net Service Switch) サブシステムの構成オプション
  • winbindd サーバー・プログラム

このため、Winbind を構成するには上記の構成のそれぞれを変更する必要があります。Winbind は Samba サーバーのメイン・プログラム (smbd および nmbd) が実行されていなくても使用することができますが、必要なサポート・ファイルをすべて入手するためには、サーバーをインストールしてください。また、個別の Winbind パッケージ (通常は、winbind あるいは samba-winbind という名前) をインストールする必要が出てくることもあります。さらに、samba-winbind-clients という名前のパッケージをインストールしなければならない場合もあります。最終的なインストール済み環境には、必ず /lib/security/pam_winbind.so および /lib/libnss_winbind.so.2 ファイルが含まれていることを確認してください。

Winbind に関するオプションを smb.conf で設定する

Winbind をセットアップするために最初に必要な作業は、前のセクションで簡単に説明したように、ドメインに参加するようにコンピューターを構成することです。詳しい手順については、「Linux の 302 (Mixed Environment) 試験対策: Samba の役割」で説明しています。次に、Winbind に固有の各種オプションを smb.conf で設定する必要があります。

Winbind に関するオプションについて探る

smb.conf で設定する可能性のあるオプションを以下に記載します。

  • winbind separator: ドメインでの Windows ユーザー名には、ユーザー名とドメイン名の両方が含まれます。このオプションは、ユーザー名とドメイン名の区切り文字を設定するためのものです。デフォルトは円記号 (\) ですが、代わりにプラス記号 (+) を使用することもよくあります。
  • winbind cache time: Winbind は指定された期間、認証データをキャッシュに入れておきます。キャッシュに入れる期間は、デフォルトで 300 秒 (5 分) に設定されますが、Winbind 構成をテストする際には、この値を小さくしても構いません。
  • template shell: このオプションを使用して、ユーザーのデフォルト・シェルを設定します。デフォルト値は /bin/false です。この値は、シェル・アクセスをサポートしないシステムには適切ですが、ユーザーがローカルでログインできるようにしたり、SSH (Secure Shell) などのサーバーを介してログインできるようにしたりするには、このオプションを /bin/bash に設定するか、その他の正当な Linux シェルに設定してください。
  • template homedir: ユーザー用にデフォルト・ホーム・ディレクトリーを設定する必要があります。デフォルト・ホーム・ディレクトリーには、例えばユーザー名には %U、ドメイン名には %D を使用するなど、1 つ以上の Samba 変数を使用するのが通常です。このパラメーターはデフォルトで /home/%D/%U に設定されます。
  • winbind enum users: このブール値のオプションは、プログラムがユーザーを列挙できるようにする、特定のシステム・コールのサポートを有効または無効に設定します。デフォルト値は Yes です。値を No に設定すると、finger などの少数のプログラムが奇妙な振る舞いをするという代償は伴いますが、パフォーマンスを向上させることができます。
  • winbind enum groups: このオプションは、ユーザーではなくグループに適用されるという点を除き、winbind enum users とほとんど同じように機能します。
  • winbind use default domain: このオプションを Yes に設定すると、Winbind はほとんどの処理で、ユーザー名に含まれるドメイン名の部分を削除します。これによりユーザー名が短縮されるため (例えば、MYDOMAIN\rexx は rexx になります)、この設定は大抵の場合は望ましい設定となります。ネットワークに複数のドメインが含まれる場合には、当然、デフォルト値の No を使用することになります。
  • idmap uid: このオプションを使用すると、ダッシュ (-) を区切り文字に使用して UID の範囲を設定することができます (10000-20000 など)。使用する UID の範囲が、ローカルで定義されたシステム用の UID と重ならないようにしてください
  • idmap gid: このオプションは、GID の範囲を設定するという点を除き、idmap uid と同様です。

サンプル構成を検討する

一例として、リスト 1 に示す smb.conf のオプションのセットについて検討してみてください。この構成では、上記で説明したすべてのオプションが使用されています。

リスト 1. Winbind の構成を示す smb.conf ファイルの例
winbind separator = +
winbind cache time = 60
template shell = /bin/bash
template homedir = /home/%U
winbind enum users = Yes
winbind enum groups = Yes
winbind use default domain = Yes
idmap uid = 10000-20000
idmap gid = 10000-20000

もちろん、これらのオプションはニーズに合わせてカスタマイズすることができます。例えば template shell については、前述したように e-メール・サーバーや FTP サーバーなどのログイン・シェルへのアクセスを提供しないサーバーにはデフォルト値のほうが適切です。

PAM の構成を行う

smb.conf の構成が完了したら、次は PAM の構成に取り組みます。PAM については「Linux の 302 (Mixed Environment) 試験対策: 認証と承認」で説明しましたが、Winbind の目的からすると、Samba ユーザーではない非 Samba ツール用の認証方法として PAM に Windbind を追加する必要があります。そのための作業には、少し注意が必要です。というのも、ディストリビューションによって PAM の構成方法は異なることから、あるディストリビューションで完璧に上手く行っている変更でも、別のディストリビューションでは無残にも機能しないことがあるためです。

PAM の概要

PAM は、認証を必要とするプログラムが使用することのできる一連のライブラリーです。これに該当するプログラムには、例えばテキスト・モードのログインを処理する login プログラム、グラフィカル・ユーザー・インターフェースからのログインを処理する X Display Manager プログラム、そして POP e-メール・サーバー・プログラムが挙げられます。柔軟なシステムを提供するためには、この後説明するように、構成ファイルを使用して PAM を構成することができます。

PAM は複合システムであり、ディストリビューションによって PAM の構成に違いがあることから、この記事で完全に説明することは不可能です (「参考文献」セクションで、参考になる PAM 関連の資料へのリンクを紹介しています)。PAM を構成するには、/etc/pam.d ディレクトリーに保存されているファイルを使用します。このディレクトリー内のファイルのほとんどは、特定のプログラム (テキスト・モードの login プログラムや SSH サーバー・プログラムなど) に対する PAM の動作を指定するものです。その一方、大抵のディストリビューションには、system-auth や common-stackname (stackname は、4 つの PAM スタック名 (auth、account、session、password) のいずれか) などのグローバル PAM 構成ファイルが用意されています (各スタックは、PAM が提供する特定のタイプのサービスの 1 つを定義します)。

PAM スタックを変更する

PAM を再構成する際には、その変更をすべてのログイン・サービスに適用する必要があるのか、それとも少数のログイン・サービスのみに適用すればよいのかを判断しなければなりません (/etc/pam.d 内のファイルを調べて、どのような類のログイン・サービスがシステムにインストールされているのかを確認してから、そのすべてのサービスで Winbind を使用する必要があるのか、あるいは一部のサービスだけに必要なのかをよく検討してください)。変更する必要のあるサービスが 1 つか 2 つだけで (POP サーバーなど)、他のサービス (FTP サーバーなど) には Winbind による認証を有効にする必要がないとしたら、変更対象のサービスに対応するファイルだけを変更します。一方、すべてのサービスに変更を適用する場合には、system-auth などの汎用ファイルを編集します。

典型的な PAM スタックの一例として、リスト 2 に Ubuntu バージョン 10.10 システムの /etc/pam.d/common-auth ファイルを示します

リスト 2. PAM スタックの例
auth  [success=1 default=ignore]  pam_unix.so nullok_secure
auth  requisite                   pam_deny.so
auth  required                    pam_permit.so

あいにく、この構文は若干わかりにくくなっていますが、pam_unix.so モジュールは、ローカル・パスワード・データベース・ファイルを使用して認証を管理するように構成されています。この行に指定されている success=1 オプションは、このモジュールが成功の結果を返した場合、PAM が次の 1 行をスキップすることを意味します。したがって、pam_unix.so が成功した場合には pam_deny.so (これは、常に認証失敗コードを返します) がスキップされ、ログインが成功するというわけです。

この構成を変更して Winbind を組み込むには、pam_winbind.so モジュールへの参照を追加し、pam_unix.so 行に設定されているスキップする行数を変更する必要があります。変更後の一例をリスト 3 に示します。このリストでは、変更箇所が強調表示されています。

リスト 3. Winbind サポートが追加された PAM スタック
auth  [success=2 default=ignore]  pam_unix.so nullok_secure
auth  [success=1 default=ignore]  pam_winbind.so cached_login try_first_pass
auth  requisite                   pam_deny.so
auth  required	                  pam_permit.so

Ubuntu (上記の例で使用しているディストリビューション) 以外のディストリビューションでは、PAM に対して他にも変更が必要ですが、変更するには初期構成を完全に理解していなければなりません。また、4 つのスタック (authaccountsessionpassword) のすべてを変更しなければならないことにも注意してください。これらのスタックは、1 つのファイルにまとめて現れることもあれば、複数のファイルに分けられていることもあります。個々のサービスに変更を加える場合には、変更を加えたいサービスに対応するそれぞれの構成ファイルで、4 つすべてのスタックを変更する必要があることに注意してください。

ディストリビューションによっては、Winbind パッケージをインストールすると、それに応じて自動的に PAM 構成が適切な内容に変更されるため、変更作業を行う必要がないものもあります。

NSS の構成を行う

Winbind によるログインを可能にするために調整しなければならない 2 つ目のサービスは、NSS です。幸い、NSS を構成するのは PAM を構成するよりもかなり単純です。/etc/nsswitch.conf ファイルを編集して、以下の 3 行を変更します。

passwd:     compat
group:      compat
shadow:     compat

一部のシステムでは、これらの行に compat ではなく files が指定されています。また、それ以外のエントリーが使われている場合もあります。この 3 行は NSS に対し、ジョブを行う際にローカル・ファイルを使用するように指示します。NSS のジョブとは、ユーザーとグループのリストを必要とするプログラムに、これらのリストを提供することです。Winbind をシステムに追加するには、各行に Winbind への参照を追加します。

passwd:     compat winbind
group:      compat winbind
shadow:     compat winbind

Winbind を実行する

以上の変更が完了したら、いよいよ Winbind を実行してテストすることができます。Winbind を起動するには、通常は以下の SysV 起動スクリプトを使用します。

# /etc/init.d/winbind start

注: システムが NSCD (Name Service Cache Daemon) を実行中の場合には、このデーモンを終了してから Winbind デーモンを実行してください。NSCD は Winbind の動作に干渉する可能性があるためです。

システムの起動時にデーモンが自動的に実行されるようにする場合は、デーモンの SysV 起動スクリプトがこのタスクに対して適切に構成されていることを確認してください。それを確認するには、chkconfigntsysvupdate-rc.d、あるいは他のツールを使用することができます。

Winbind が稼働状態になったら、wbinfo プログラムを使用して Winbind をテストすることができます。-u オプションを指定すると、ユーザーの一覧が返されます。

$ wbinfo -u
grogers
fastaire
mikhail

上記の出力例には、3 人のユーザーが示されています。ユーザーの一覧を取得するには、「getent passwd」と入力することもできます。このコマンドは基本的に、/etc/passwd ファイルの内容を取得することに相当します。このコマンドは、ローカル・アカウント、Winbind、あるいは他のあらゆる使用中のサービス (LDAP サーバーなど) を含め、何らかの手段で定義されているすべてのユーザーを返します。

注: 特に winbind enum users = No が設定されている場合をはじめ、wbinfo -u コマンドと getent passwd コマンドはドメイン・ユーザーの完全な一覧を返さないことがあります。したがって、これらのコマンドが機能していない疑いがある場合には、ログインできるかどうかをテストして、Winbind が機能していることを確認してください。

Winbind が機能しているかどうかをテストする究極の方法は、当然、PAM で Winbind を使用するように構成したサービスのユーザーを適切に認証することができるかどうかを確認することです。この機能をテストするには、Windows ドメインでは定義されているけれども、ローカル・コンピューター上には定義されていないアカウントを使用する必要があります。テストが成功しない場合は、クライアントと Windows ドメイン・コントローラーの両方でログ・ファイルを調べてみてください。忘れてはならない点として、inbind use default domain = No を設定した場合、ローカル・ユーザー名は DOMAIN\username という形になります (あるいは、winbind separator を設定してある場合には、別の区切り文字を使った同様の形)。

次回の予告

この連載の次のトピック「Linux の 302 (Mixed Environments) 試験対策: CIFS の統合」では、Linux コンピューターをファイル共有クライアントとして SMB (Server Message Block)/CIFS (Common Internet File System) ネットワークに統合する方法を取り上げます。このトピックには、スタンドアロンのクライアント・ツールを使用して、標準的な Linux ファイルシステム階層に SMB/CIFS 共有をマウントする方法も含まれます。


ダウンロード可能なリソース


関連トピック


コメント

コメントを登録するにはサインインあるいは登録してください。

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Linux
ArticleID=782565
ArticleTitle=Linux の 302 (Mixed Environment) 試験対策: Winbind
publish-date=01062012