LPI 試験対策: ネットワーク・クライアントの管理

LPIC-2 (中級レベルの管理) の主題 210

このチュートリアルは、Linux での中級レベルのネットワーク管理について取り上げる全 7 回からなるシリーズの第 5 回目です。今回も引き続き、David Mertz が LPI (Linux Professional Institute) の LPIC-2 (中級レベルの管理) 202 試験に備えるためのお手伝いをします。今回のチュートリアルではいくつかのプロトコルを取り上げ、ネットワーク内のクライアントのネットワーク設定を集中化して構成する方法をプロトコル別に検討します。DHCP は、IP アドレスの割り当てをはじめ、クライアント・マシンとの基本ハンドシェークを確立するために広く使われているプロトコルです。上位レベルでは、ネットワーク上のマシンの間で任意の情報を共有するために、NIS と (NIS よりも一般的な) LDAP が使用されています。このチュートリアルでは、柔軟でネットワーク化されたユーザー認証システム、PAM についても説明します。

2012年 5月 17日 ― 著者からのリクエストにより、リンク切れを更新しました。「このチュートリアルについて」セクションでは、リンク・テキスト「詳しく説明している目標のリスト」の URL が更新されています。「参考文献」セクションでは、1)「LPIC Professional Certifications」のリンク、2)「LDAP の公式仕様は RFC 2251 です」のリンク、3)「Linux-PAM System Administrators' Guide」のリンクが更新されています。(訳注: このチュートリアルの原文は 2006年に初版が公開されたものであるため、LPI 試験の構成や内容は現在とは異なる部分があり、その他の内容も 2006年時点の現状に基づいて書かれています)

David Mertz, Developer, Gnosis Software, Inc.

David Mertz は、人工言語はごく自然な言語である一方、自然言語はやや人工的であると考えています。David の個人的な Web ページでは、彼の人生に関するさまざまな側面を調べることができます。また、著書には『Text Processing in Python』があります。彼が書いたこれまでの記事または今後の記事に関するご意見、ご提案をお寄せください。



2012年 8月 02日

始める前に

はじめに、このチュートリアル・シリーズから学べる内容、そしてチュートリアルを最大限に活用する方法を紹介します。

このシリーズについて

LPI (Linux Professional Institute) では、Linux システム管理者を初級レベル (「認定レベル 1」) と中級レベル (「認定レベル 2」) の 2 つのレベルで認定しています (訳注: 2012年 7月現在は 3 つのレベルがあります)。認定レベル 1 を取得するには 101 試験と 102 試験に合格する必要があり、認定レベル 2 を取得するには 201 試験と 202 試験に合格する必要があります。

developerWorks では、この 4 つの試験に備えるためのチュートリアルを提供しています。各試験の出題範囲には複数の主題が含まれるため、developerWorks でも主題ごとに自習用のチュートリアルを用意しています。LPI 202 試験の出題範囲となっている 7 つの主題 (訳注: 2012年 7月現在、LPI 202 試験は主題 208 から主題 213 までの 6 つの主題で構成されています) と、それぞれに対応する developerWorks チュートリアルを以下に記載します。

表 1. LPI 202 試験: チュートリアルと主題
LPI 202 試験の主題developerWorks チュートリアルチュートリアルの概要
主題 205LPI 202 試験 (主題 205):
ネットワーク構成
基本的な TCP/IP ネットワークの構成方法を学びます。これには、ハードウェア層 (一般的には Ethernet、モデム、ISDN、または 802.11) からネットワーク・アドレスのルーティングまで含まれます。
主題 206LPI 202 試験 (主題 206):
メールとニュース
Linux をメール・サーバーとして使用する方法と、ニュース・サーバーとして使用する方法を学びます。メール転送、ローカルでのメール・フィルタリング、メーリング・リストを保守するためのソフトウェア、そして NNTP プロトコル対応のサーバー・ソフトウェアについて取り上げます。
主題 207LPI 202 試験 (主題 207):
DNS
Linux を DNS サーバーとして使用する方法を学びます。BIND の基本的な構成方法、DNS ゾーンの管理方法、そして DNS サーバーをセキュアにする方法を取り上げます。
主題 208LPI 202 試験 (主題 208):
Web サービス
Apache Web サーバーをインストールして構成する方法、Squid プロキシ―・サーバーを実装する方法を学びます。
主題 210 LPI 202 試験 (主題 210):
ネットワーク・クライアントの管理
(本チュートリアル) DHCP サーバー、NIS クライアントおよびサーバー、LDAP サーバー、PAM 認証サポートを構成する方法を学びます。試験の具体的な目標を記載した、以下の表を参照してください。
主題 212 LPI 202 試験 (主題 212):
システム・セキュリティー
ルーターを構成する方法、FTP サーバーをセキュアにする方法、SSH を構成する方法、それ以外の各種セキュリティー管理タスクを実行する方法を学びます。
主題 214 LPI 202 試験 (主題 214):
ネットワークのトラブルシューティング
ネットワークの問題を検出して解決できるようにするためのツールとコマンドについて学びます。

認定レベル 1 の試験に備えるためには、LPI 101 試験のための developerWorks チュートリアルを参照してください。LPI 202 試験以外の認定レベル 2 の試験に備えるためには、LPI 201 試験のための developerWorks チュートリアルを参照してください。また、LPI 試験に備えるための developerWorks チュートリアル全体についての概要も読んでください。

Linux Professional Institute では、特定のサード・パーティーによる試験対策用の教材や講座などは認定していません (訳注: 2012年 7月現在では認定を行っています)。詳細については、info@lpi.or.jp にお問い合わせください。

このチュートリアルについて

「ネットワーク・クライアントの管理」チュートリアルへようこそ。このチュートリアルは、Linux での中級レベルの ネットワーク管理について取り上げる全 7 回からなるシリーズの第 5 回目です。今回はいくつかのプロトコルを取り上げ、ネットワーク内のクライアントのネットワーク設定を集中化して構成する方法をプロトコル別に説明します。具体的には、クライアント・マシンの基本ハンドシェーク (IP アドレスの割り当てなど) を確立するために広く使われている DHCP について、そして上位レベルでは、ネットワーク上のマシンの間で任意の情報を共有するために使用されている NISおよび (NIS よりもよく使用されている) LDAP について説明します。このチュートリアルでは、柔軟でネットワーク化されたユーザー認証システム、PAM (Pluggable Authentication Module) についても説明します。

201 試験および 202 試験のための developerWorks シリーズの他のチュートリアルと同じく、このチュートリアルは特定の主題に関する完全な資料ではなく、試験に備えるためのガイド兼出発点として意図されています。読者には、LPI で詳しく説明している目標のリストを調べ、このチュートリアルで提供している情報を必要に応じて他の教材で補うことをお勧めします。

このチュートリアルは、LPI の主題 210 の目標に合わせて編成されています。おおまかには、目標の重要度が高くなるほど、試験での設問が多くなると思ってください。

表 2. Web サービス: このチュートリアルで対象とする試験目標 (訳注: 2006年時点の試験目標)
LPI 試験の目標目標の重要度目標の要約
2.210.1
DHCP の設定
重要度 2DHCP サーバーを構成します。この目標には、デフォルトおよびクライアントごとのオプションの設定と、静的ホストおよび BOOTP ホストの追加が含まれます。さらに、DHCP 中継エージェントの構成と DHCP サーバーの保守もこの目標に含まれます。
2.210.2
NIS の設定
重要度 1NIS サーバーを構成します。この目標には、システムを NIS クライアントとして構成することも含まれます。
2.210.3
LDAP の設定
重要度 1LDAP サーバーを構成します。この目標には、ディレクトリー階層、グループ、ホスト、サービスの操作、そしてその他のデータをディレクトリー階層に追加することも含まれます。また、項目のインポートと追加、ユーザーの追加と管理も含まれます。
2.210.4
PAM 認証
重要度 2さまざまな方法で認証をサポートするように PAM を構成します。

前提条件

このチュートリアルを最大限に活用するには、Linux の基礎知識と、チュートリアルに記載されているコマンドを演習できる実際の Linux システムが必要です。


はじめに

DHCP の概要

DHCP (Dynamic Host Configuration Protocol) は、BOOTP プロトコルの後継プロトコルです。DHCP サーバーの主な役割は、ネットワークに接続したり、ネットワークから切断されたりするクライアント・マシンに IP アドレスを割り当てることです。ほとんどの IP ネットワークでは、IP アドレス割り当ての競合を避けるために DHCP を使用しています (これには、トポロジーとクライアントが不変の IP ネットワークでさえも含まれます)。

DHCP サーバーはクライアントに IP アドレスを割り当てるだけでなく、ルーティング情報、サブネット情報、DNS アドレスなども提供します (場合によっては、これ以外の情報も提供することがあります)。DHCP による IP アドレスの割り当て有効期間は、サーバーの構成およびクライアントからのリクエストの詳細によって異なり、短い場合もあれば、無期限の場合もあります。実際、DHCP は、特定のマシンには常に (その MAC ハードウェア・アドレスを基に) 同じ IP アドレスを割り当てますが、いずれにしてもマシン間での競合を防ぐことには変わりありません。

DHCP の公式仕様は RFC 2131 です (リンクについては、チュートリアルの後のほうにある「参考文献」セクションを参照)。

NIS の概要

NIS (Network Information Service) は、以前は「Yllow Pages」(YP) として知られていた、Sun Microsystems のクライアント・サーバー型ディレクトリー・サービス・プロトコルです。このプロトコルは、コンピューター・ネットワーク上のユーザー名やホスト名などのシステム構成データを配布するために使用されます。

NIS/YP は、コンピューター・ネットワーク内のユーザー、ホスト名、およびその他の有用な情報のほとんどを中央のディレクトリーでまとめて管理するために使用されます。例えば、一般的な UNIX 環境では、/etc/passwd にユーザーの (認証用) リストが置かれています。NIS を使用する場合、それとは別の「グローバル」なユーザー・リストが追加されます。そのリストは、ユーザーを認証するために任意のホストで使用されます。

現在ほとんどの一般的な用途では、より汎用的かつセキュアな LDAP が NIS に代わって使用されるようになっています。

NIS について詳しく調べるには、「The Linux NIS(YP)/NYS/NIS+ HOWTO」が絶好の出発点となります (「参考文献」のリンクを参照)。

LDAP の概要

LDAP (Lightweight Directory Access Protocol) は、ディレクトリー・サービス (具体的には X.500 ベースのディレクトリー・サービス) にアクセスするためのクライアント・サーバー型のプロトコルです。

LDAP ディレクトリーはデータベースに似ていますが、傾向として、データベースよりも記述的な属性ベースの情報を格納します。そのため、LDAP は、ネットワークで共有されるあらゆるタイプの情報を格納できるだけの柔軟性を提供します。ディレクトリーに格納される情報は、書き込まれる回数より読み取られる回数のほうが遥かに多いため、LDAP ディレクトリーは大量のルックアップまたは検索操作に素早く応答するように調整されています。

LDAP では、可用性と信頼性を高めると同時に、応答時間を短縮するために、情報を広範囲にわたって複製することができます。ディレクトリー情報が複製されると、レプリカの間での一時的な不整合は次第に同期されていきます。

LDAP の公式仕様は RFC 2251 です (「参考文献」のリンクを参照)。

PAM の概要

Linux-PAM (Pluggable Authentication Modules for Linux) は、アプリケーションのユーザー認証方法をローカル・システム管理者が選択することを可能にする、共有ライブラリーの集合です。

PAM 対応のアプリケーションは、実行時に認証方法を切り替えることができます。まさに、アプリケーション自体を再コンパイルすることなくローカル認証システム全体をアップグレードすることができます。この PAM ライブラリーはローカルでシステム・ファイル /etc/pam.conf (または /etc/pam.d/ に置かれている一連の構成ファイル) を使用して、ローカルで使用可能な認証モジュールによってユーザーからのリクエストを認証するように構成します。モジュール自体は一般に、動的にロード可能なオブジェクト・ファイルという形で /lib/security ディレクトリーに配置されます。

詳細を調べる出発点としては、「Linux-PAM System Administrators' Guide」がお勧めです (「参考文献」のリンクを参照)。

その他のリソース

ほとんどの Linux ツールの例に漏れず、話題に上っているユーティリティーについては、どんな場合にも man ページが役立ちます。バージョンとスイッチは、ユーティリティーまたはカーネルのバージョン、あるいは Linux のディストリビューションによって異なる可能性があります。さらに詳しい情報を入手するには、Linux Documentation Project に HOWTO 文書をはじめ、有用な各種のドキュメントが豊富に揃っています。Linux ネットワーク構築に関する書籍も、さまざまなものが出版されています。なかでも、私が大いに参考になると思ったのは、オライリー・ジャパンから出版されている『TCP/IP ネットワーク管理』(Craig Hunt 著) です (「参考文献」のリンクを参照)。


DHCP の設定

プロトコル全般

多くのネットワーク・プロトコルと同じく、DHCP (Dynamic Host Configuration Protocol) はクライアント/サーバー・インターフェースによるプロトコルです。DHCP クライアントは、DHCP サーバーと比べると遥かに単純なプログラムになっており、それはプログラムの内部に関しても構成に関しても言えることです。DHCP クライアントのジョブは、基本的にそのクライアントのローカル物理サブネットで DHCPDISCOVER メッセージをブロードキャストして、応答を待つことです。

DHCPDISCOVER メッセージには、ネットワーク・アドレスとリース期間の値を示唆するオプションを含めることができます。DHCPDISCOVER メッセージを受信したサーバーは、リクエストの送信元 MAC アドレスに対し、DHCPOFFER メッセージで応答します。するとクライアントが、提示側のサーバーのうちのいずれか (通常は、最初に (唯一) 応答したサーバー) に、DHCPREQUEST メッセージで応答します。

クライアントが実際に使用する構成パラメーターは、DHCPACK メッセージで受信します。この時点で、クライアントは割り当てられた IP アドレスを受け取り、それによってクライアントの通信はデータ・リンク層 (イーサネット) からネットワーク層 (IP) へと移ることになると言えます。

クライアント・プロセス

一般に、DHCP クライアントを構成するために必要な情報は、そのクライアントが取得することを希望する情報一式だけです。例えば、Debian ベースのディストリビューションで通常使用する DHCP クライアント、dhclient は、/etc/dhcp3/dhclient.conf ファイルで構成されます。dhcp3-client パッケージで配布されるサンプル・ファイルの構成オプションは、1 つを除いてすべてコメントアウトされています。有効にされているその唯一のオプションは、以下のようになっています。

リスト 1. dhclient.conf のオプション
      request subnet-mask, broadcast-address, time-offset, routers,
        domain-name, domain-name-servers, host-name,
        netbios-name-servers, netbios-scope;

上記のデフォルト構成の例では、クライアントは基本的に、「使用可能な情報をすべて要求」しているだけです。ネゴシエーション・メッセージのうち、サーバーから送信される DHCPACK メッセージには、要求されたこれらすべての値に関する情報が含まれることになります。クライアントがこのメッセージを受け取ると、そこに含まれている情報を使用するようになります。このリストにはクライアントの IP アドレスが明示されていませんが、それはその構成は常にネゴシエートされるためです。

クライアントはタイムアウトとリース期間 (およびその他にもいくつか) のオプションを指定できるだけでなく、ほとんどの場合は必要でないにせよ、使用を希望する IP アドレスに制限を設けることもできます。特定の IP アドレスを除外するには、例えば reject 192.33.137.209; のように指定します。クライアントが使用したいアドレスを明示的に指定するには、fixed-address 192.5.5.213; のように指定します。

クライアントは、リースの提示を DHCPDECLINE メッセージによって拒否することができますが、サーバーは可能な限り要求を満たそうとします。DHCP サーバーは、リクエストの送信元の MAC アドレスに応じて、常に固定の IP アドレスが割り当てられるようにすることもできます。マシンごとの IP アドレスの構成は、クライアントでの構成で行われるよりも、サーバーでの構成で行われるほうが一般的です。

取得したリースの経過を追うために、dhclient は割り当てられたリースのリストを /var/lib/dhcp3/dhclient.leases ファイル (このパスは、ディストリビューションによって異なる場合があります) に保持します。そのため、システムが物理ネットワークから切断されたり、システムがリブートしたりしても、有効期限が切れていない DHCP リースを使用できなくなることはありません。

サーバー・プロセス

DHCP サーバーは、DHCP リースにおいて、クライアントにさまざまな情報を提供するため、DHCP の構成オプションに関する情報をクライアントより多く必要とします。さらに、クライアントごとに一意に決まる IP アドレスが必ず割り当てられるようにする必要もあります。通常、DHCP サーバーは dhcpd デーモンとして実行され、その構成情報を /etc/dhcpd.conf (このパスは、ディストリビューションによって異なる場合があります) から取得します。複数の物理ネットワークが 1 つのサーバーに接続されている場合には一般に、1 つの dhcpd デーモンが複数のサブネットを管理することもできますが、大抵は 1 つのサーバーが 1 つのサブネットを管理します。リスト 2 に、サーバー構成のほぼ完全な例を記載します。

リスト 2. dhcpd.conf 構成オプション
      # default/max lease in seconds: day/week
      default-lease-time 86400;
      max-lease-time 604800;
      option subnet-mask 255.255.255.0;
      option broadcast-address 192.168.2.255;
      option routers 192.168.2.1;
      # DNS locally, fallback to outside local domain
      option domain-name-servers 192.168.2.1, 151.203.0.84;
      option domain-name "example.com";
      # Set the subnet in which IP address are pooled
      subnet 192.168.2.0 netmask 255.255.255.0 {
         range 192.168.2.100 192.168.2.199;
      }
      # Assign a fixed IP to a couple machines by MAC address
      group {
         use-host-decl-names true;
         host first.example.com {
            hardware ethernet 00:00:c1:a2:de:10;
            fixed-address 192.168.2.200;
         }
         host second.example.com {
            hardware ethernet 00:dd:cc:a1:78:34;
            fixed-address 192.168.2.201;
         }

上記の構成で実行されているサーバーに対してクライアントがブロードキャスト・メッセージを送信すると、クライアントが上記で指定されている MAC アドレスを持つ場合には、クライアントに 192.168.2.200 または 192.168.2.201 がリースされ、そうでない場合にはプールされた 192.168.2.100 から 192.168.2.199 までのアドレスのうち、使用可能なアドレスがリースされます。

クライアントに IP アドレスが (手動構成により) すでに割り当てられている場合、そのクライアントは DHCPINFORM メッセージを使用して、IP アドレス以外の構成情報を提供するようにサーバーに指示することもできます。注意する点として、クライアントが現在、特定の IP アドレスを使用していることをサーバーに通知することと、クライアントが特定の IP アドレスを要求することは、同じではありません。後者の場合、サーバーは既存のリース状況次第で要求を聞き入れることもあれば、聞き入れないこともあります。前者の場合、サーバーにはクライアントの IP アドレスを決定する権限はなく、IP アドレスのリースそのものが行われません (ただし、サーバーは、使用されていることがわかっている IP アドレスを新たに IP アドレスを要求してくるクライアントに割り当てないようにします)。

リースの有効期限が切れても、構成パラメーターが引き続き適用されるようにするには、クライアントとサーバーが新しいリースをネゴシエートする必要があります。サーバーでの構成情報が (例えば、外部 WAN を介した動的 DNS により) 変更される可能性が高い場合には、リースの期間を短くすることができます。クライアントがリースをグレースフルに終了するには、DHCPRELEASE メッセージを送信するという方法を採ることができますが、これを行わなければ正しい操作ではないということではありません (このメッセージを送信する間もなく、クライアントがクラッシュまたはリブートしたり、切断されたりすることもあります)。

リリース・メッセージが送信されない限り、リースはその条件として与えられた期間、サーバーによって保守されます。したがって、リブート後のマシンがリブート前のリースを引き続き使用することもよくあります (リース情報は、サーバーとクライントの両方で dhclient.leases に格納されます)。


NIS の設定

NIS を使用する場合

NIS に関連するユーティリティーの大半は、その名前に今でも yp という接頭辞が付いています。NIS は以前、「Sun Yellow Pages」と呼ばれていましたが、商標の問題により、その名前を NIS に変更せざるを得なかったためです。NIS は、マシンのネットワークがユーザーやグループなどの情報 (それぞれ、/etc/passwd、/etc/group の内容) を共有できるようにして、NIS ドメイン内のあらゆるマシンでユーザーに権限が与えられるようにするために使用されます。

NIS は、情報が配布されるドメインを定義するという点、そしてマスター・サーバーとスレーブ・サーバーがドメイン内で階層的に情報を配布できるようにするという点でも、DNS と似たような動作をします。事実、原理上は /etc/hosts に保管されたドメイン名情報を配布すれば、NIS を DNS の代わりに使用することができます。けれども、この方法が実際に使用されることはめったにありません。原則的にあらゆるタイプの情報を NIS データベースに格納できるという点で、NIS にはある程度の柔軟性があります (NIS データベースは DBM フォーマットになっていますが、NIS サーバー・パッケージに含まれる makedbm ツールが、通常は裏でフラット・ファイルを DBM フォーマットに変換します)。

NIS の後継として、データ暗号化と認証を組み込んだ NIS+ という名前のサービスも開発されましたが、NIS+ には NIS との後方互換性がなく、広く使われてはいません。

準備手順

NIS クライアントは RPC 呼び出しを行うため、どの NIS ユーティリティーを実行するにも、/sbin/portmap デーモンを実行して RPC プログラム番号を TCP/IP (または UDP/IP) プロトコルのポート番号に変換する必要があります。ほとんどの Linux ディストリビューションは起動スクリプトで /sbin/portmap を起動しますが、% ps -ax | grep portmap によって、このデーモンが実行中であることを確認してください。

デーモンが実行されていない場合は、/sbin/portmap をインストールしてシステムの起動スクリプトに組み込んでください。

NIS クライアント・ユーティリティー (ypbind デーモン)

NIS クライアントに組み込まれているツールには、ypbindypwhichypcatyppoll、および ypmatch があります。このうち、ypbind デーモンは root として実行する必要があります。このデーモンは通常、システム起動スクリプトのなかで起動されます (ただし、システム起動スクリプトで呼び出さなければならないわけではありません)。

ypbind 以外のツールは、ypbind のサービスを利用しますが、これらのツールはユーザー・レベルで実行されます。古いバージョンの ypbind はローカル・ネットワークでバインディング・リクエストをブロードキャストします。しかし、この方法では、悪意のある NIS サーバーがブロードキャストされたリクエストに応答して、悪質なユーザー情報やグループ情報をクライアントに渡す可能性があります。そのため、/etc/yp.conf ファイルを使用して、ypbind が接続する特定のサーバーを構成することをお勧めします。複数のサーバーが構成されている場合 (または、危険であってもブロードキャストを使用する場合)、ypbind は、最も短時間で応答できるサーバーという基準で、バインド先のサーバーを 15 分ごとに切り替えることができます。複数のサーバーを構成する場合には、これらのサーバーをマスター/スレーブ構成にしなければなりませんが、クライアントがその詳細を知る必要も、考慮する必要もありません。以下に、ypbind の構成例を記載します。

リスト 3. /etc/yp.conf
      ypserver 192.168.2.1
      ypserver 192.168.2.2
      ypserver 192.168.1.100
      ypserver 192.168.2.200

/usr/sbin/ypbind を実行する前に、ネットワークの NIS ドメイン名を設定する必要があります。NIS ドメイン名は、NIS サーバーが使用するように構成されている任意の名前にすることができます。ただし通常は、DNS ドメイン名とは異なる名前にしなければなりません。NIS ドメイン名を設定するには、% ypdomainname my.nis.domain を実行します (my.nis.domain の部分は実際のドメイン名に置き換えてください)。

NIS クライアント・ユーティリティー (その他の構成)

NIS をドメイン名のルックアップ・プロセスの一部として使用するには、/etc/host.conf の内容を変更して、ルックアップする順番のなかに NIS を含めます。例えば、最初に /etc/hosts で名前を調べ、次に NIS で調べ、最後に DNS で調べるとしたら、次のようにします。

リスト 4. ルックアップ順序の変更
      % cat /etc/host.conf
      order hosts,nis,bind

NIS によるユーザー認証を有効にするには、クライアントの /etc/passwd ファイルを変更して +:::::: を含めるようにします。

NIS データベース情報は、この「未入力」パターンにより、ログイン試行のテンプレートとして機能します。ユーザー情報は、必要に応じて微調整することができます。以下はその一例です。

リスト 5. /etc/passwd ファイルの具体的な内容
      +user1:::::::
      +user2:::::::
      +user3:::::::
      +@sysadmins:::::::
      -ftp
      +:*::::::/etc/NoShell

上記のコードにより、ログイン・アクセスが許可されるのは user1user2user3、および sysadmin ネットグループのすべてのメンバーに制限されますが、NIS データベース内の他のすべてのユーザーに関するアカウント・データが提供されます。

NIS のソース自体は /etc/nsswitch.conf に構成されます。このファイルは、その名前からしてネーム・サーバーのルックアップ専用の構成であるように思うかもしれませんが、ここにはさまざまなタイプの情報が記述されます。基本的に、この構成ファイルに記述されるのは、情報ソースを検索する順序です。順序に含まれる nis という名前は、情報が NIS サーバーから取得されることを意味し、files という名前は適切なローカル構成ファイルを使用することを意味します。dns は、hosts オプションで使用される名前です。

さらに、初期ソースに必要な情報が含まれていない場合のアクションを指定することもできます。具体的には、検索を諦めるには return を指定します (continue を指定すると、単に NIS が完全に応答していないというのでない限り、次のソースでその当該データの検索を試行します)。以下に一例を記載します。

リスト 6. /etc/nsswitch.conf
      passwd:         compat
      group:          compat
      shadow:         compat
      hosts:          dns [!UNAVAIL=return] files
      networks:       nis [NOTFOUND=return] files
      ethers:         nis [NOTFOUND=continue] files
      protocols:      nis [NOTFOUND=return] files
      rpc:            nis [NOTFOUND=return] files
      services:       nis [NOTFOUND=return] files

NIS クライアントのユーザー・ユーティリティー

ypwhichypcatyppollypmatch の各ユーティリティーは、NIS 情報を問い合わせるためにユーザー・レベルで使用します。

  • ypwchich は、NIS サーバーの名前を出力します。
  • ypcat は、NIS データベースのすべてのキーの値を出力します。
  • yppoll は、NIS マップのバージョンとマスター・サーバーを出力します。
  • ypmatch は、NIS マップの 1 つ以上のキーの値を出力します。

詳しい使用法については、それぞれのユーティリティーの man ページを参照してください。

NIS サーバー・ユーティリティー (ypinit、ypserv)

NIS サーバーがクライアントに NIS データベースを提供するために使用する ypserv デーモンは、/etc/ypserv.conf ファイルで構成されます。前述のとおり、ドメイン内ではマスター NIS サーバーとスレーブ NIS サーバーの両方を実行することができます。NIS データベースのセットは、マスター・サーバー上で % /usr/lib/yp/ypinit -m を実行することで初期化されます。初期化はサーバーを初めて実行するときにだけ行われ、その後は変更があると % make -C /var/yp を実行します。

スレーブ・サーバーは、実際にはマスター・サーバーからデータベースを取得する NIS クライアントに過ぎません (データベースを取得して、ypserv を実行します)。マスター・サーバーの情報をローカルで実行中のスレーブ・サーバーにコピーするには、% /usr/lib/yp/ypinit -s my.nist.domain を実行します。

マスター・サーバーでは、以下のお馴染みの構成ファイル (の一部) の情報から NIS データベースが構築されます。

  • /etc/passwd,
  • /etc/group,
  • /etc/hosts,
  • /etc/networks,
  • /etc/services,
  • /etc/protocols,
  • /etc/netgroup,
  • /etc/rpc.

エクスポート対象のデータベースは、/var/yp/Makefile に構成されます。このファイルは、再ビルドされた時点でも変更を伝播します。

NIS マップが (yppush プログラムにより) 再ビルドされると、変更内容がスレーブ・サーバーに通知されます。すると、スレーブ・サーバーはそのデータベースを同期させるために必要な変更を自動的に取得します。NIS クライアントでは、こうした処理を行う必要はありません。NIS クライアントは常に NIS サーバーと対話し、情報を読み取ってその DBM データベースに保管するためです。


LDAP の設定

LDAP を使用する場合

LDAP (Lightweight Directory Access Protocol) の目的は、原則的に NIS と同じです。それは、ネットワーク構成に関する構造化された情報をクライアントからサーバーに配布することですが、LDAP の場合、どの情報をどのクライアントに対して配布するかを階層的に構造化し、必要に応じてリクエストを他の LDAP サーバーにリダイレクトする点、そしてセキュリティー・メカニズムを組み込むという点で、NIS よりも進んでいます。しかも LDAP には、クライアントが LDAP サーバーに格納された情報を更新し、その情報を要求する他のクライアントに対し、(当然、パーミッションに応じて) LDAP サーバーが更新済みの情報を配布するためのメカニズムおよびツールもあります。

インストール

OpenLDAP (通常は Linux で使用されるフリー・ソフトウェアの実装ですが、商用の実装もあります) を実行する前に、以下に挙げるいくつかの必須ライブラリーの存在を確認するか、インストールする必要があります。

  • OpenSSL TLS (Transport Layer Security) サービスは、OpenSSL プロジェクトから (または Linux ディストリビューションのインストール・メカニズムを使用して) 入手することができます。
  • Kerberos 認証サービスはオプションですが、あると非常に役立ちます。MIT Kerberos または Heimdal Kerberos のいずれかを使用することができます。
  • SASL (Simple Authentication and Security Layer) は、基本ディストリビューションの一部としてインストールされる場合もありますが、Cyrus SASL として入手することもできます。
  • Sleepycat Software の Berkeley DB が推奨されますが、他の DBM 実装でも互換するはずです。
  • Posixスレッドと TCP ラッパーは、絶対に必要というわけではありませんが、あると役立ちます。

上記の前提条件が満たされていれば、OpenLDAP ライブラリーをダウンロードした後に行うインストール手順は、ほとんど通常と同じです。

リスト 7. 通常の OpenLDAP インストール手順
      % ./configure
      % make depend
      % make
      % make test  # make sure things went OK
      % su root -c 'make install'

基本インストールが完了したら、slapd 構成ファイルを構成します (このファイルは通常、/usr/local/etc/openldap/slapd.conf にあります)。セットアップによって、ドメイン・コンポーネントを指定します。

リスト 8. slapd.conf で指定するドメイン・コンポーネント
      database bdb
      suffix "dc=eng,dc=uni,dc=edu,dc=eu"
      rootdn "cn=Manager,dc=eng,dc=uni,dc=edu,dc=eu"
      rootpw <secret>
      directory /usr/local/var/openldap-data

<secret> の値を調べるには、slappasswd ユーティリティーを使用します。そして、その暗号化された base64 エンコード文字列を <secret> として使用します。

リスト 9. <secret> の値を調べる
      % slappasswd
      New password: *******
      Re-enter new password: ********
      {SSHA}YzPqL5Jio2+17NFIy/pAz8pqS5Ko13fH

slapd.conf に構成できるパーミッション、レプリケーション、およびその他のオプションについての詳しい情報は、詳細な説明がある man ページをよく調べてください。

slapd デーモンを起動する方法は、他のあらゆるデーモンを起動する場合とほとんど同じです。ldapsearch を使用して、このデーモンが機能したかどうかをテストすることができます。

リスト 10. slapd が機能したかどうかを調べるためのテスト
      su root -c /usr/local/libexec/slapd
      ldapsearch -x -b '' -s base '(objectclass=*)' namingContexts

すべてが順調に機能していれば、以下のような応答が出力されるはずです。

リスト 11. 機能している slapd の応答
      dn:
      namingContexts: dc=eng,dc=uni,dc=edu,dc=eu

LDIF ファイルを使用してデータを追加する

LDAP で使用されるデータ・フォーマットはバイナリー・フォーマットですが、LDAP データベースのデータをエクスポートおよびインポートするには、LDIF (LDAP Data Interchange Format) と呼ばれる ASCII シリアライズを使用します。LDIF では、バイナリー・データが base64 でエンコードされたデータとして表されます。OpenLDAP には、LDAP サーバーから LDIF にデータをエクスポートするためのツール (ldapsearch)、LDIF から LDAP サーバーにデータをインポートするためのツール (ldapadd)、そして LDIF に記述された一連の変更を LDAP サーバーに適用するためのツール (ldapmodify および ldapdelete) が組み込まれています。

さらに、LDIF は、Mozilla Application Suite や他のユーザー・アプリケーション・レベルのツールでアドレス帳のデータをインポートおよびエクスポートするフォーマットとしても使用されています。Microsoft Windows 2000 Server と Windows Server 2003 にも、Active Directory との間でデータを転送するための LDIF ツール (LDIFDE) が組み込まれています。

手作業で LDAP サーバーに情報を追加するには、まず、LDIF ファイルを作成します。

リスト 12. サンプル LDIF ファイル example.ldif の作成
      dn: dc=example,dc=com
      objectclass: dcObject
      objectclass: organization
      o: Example Company
      dc: example

      dn: cn=Manager,dc=example,dc=com
      objectclass: organizationalRole
      cn: Manager

次に、% ldapadd -x -D "cn=Manager,dc=example,dc=com" -W -f example.ldif を使用して、作成した LDIF ファイルを追加します。

もちろん、example.com ドメインは、サイトに応じたドメイン名に置き換えてください。通例、LDAP ドメインの階層と名前は、お馴染みの DNS で使用するものと一致します。上記の操作を行うときに入力を求められる rootpw の値には、slapd.conf に指定した値を使用します。

LDAP データベースに対してクエリーを実行する

データベースの情報をまるごと複製するには、slurpd (Standalone LDAP Update Replication Daemon) というツールがあります。一方、個々のデータ値を複製するとしたら、ldapsearch などのツールを使用するか、あるいは多くの場合は、実行するアプリケーションに LDAP サポートを組み込みます。また、LDAP データベースを LDIF にダンプする、slapcat というツールもあります。例えば、多くのメール・ユーザー・エージェント (MUA) では、LDAP を使用してアドレスと連絡先情報を見つけることができます。

アプリケーション (アプリケーションまたはスクリプト言語を使って自分でプログラムしたものを含む) 内で LDAP リソースにアクセスするには、LDAP URL を使用します。これらの URL は、ldap://host:port/dn?attributes?scope?filter?extensions という形を取ります。

URL に含まれるフィールドのほとんどはオプションです。デフォルトでは、ホスト名は localhost に、ポートは 389 に設定されます。デフォルトのルート識別名は空の文字列です。認証情報が必要な場合は、URL の extensions の部分に指定します。

LDAP URL の他、多くの LDAP サーバーおよびクライアントは、標準ではないにせよ、広範に使用されている LDAPS URL もサポートしています。LDAPS URL は、平文接続ではなく SSL 接続を使用し、636 をデフォルトのポートとして使用します。したがって、ldap://host:port/dn?attributes?scope?filter?extensions という形になります。


PAM 認証

PAM を使用する場合

PAM (Pluggable Authentication Modules) について最初に覚えておくべき点として、PAM 自体はアプリケーションでもプロトコルでもありません。PAM はライブラリーの集合であり、アプリケーションが既にコンパイル済みであっても PAM を使用することができます。アプリケーションが PAM に対応する場合、システム管理者はそのアプリケーションのセキュリティー・ポリシーを、アプリケーション自体を変更したりアップグレードしたりせずに、構成することができます。デーモンおよびサーバーをはじめ、多くの Linux ツールは PAM 対応となっています。

特定のツールが PAM に対応するかどうかを高い確度で調べる簡単な方法は、ldd を使用して、そのツールが使用するライブラリーを調べることです。例えば、ログイン・ユーティリティーが PAM に対応しているかどうかを確認するには以下のようにします。

リスト 13. ログイン・ユーティリティーが PAM に対応しているかどうかの確認
      % ldd /bin/login | grep libpam
      libpam.so.0 => /lib/libpam.so.0 (0xb7fa8000)
      libpam_misc.so.0 => /lib/libpam_misc.so.0 (0xb7fa5000)

loginlibpam.solibpam_misc.so を使用するからといって、PAM 機能が実際に使用されていて、しかもこのツールが PAM 機能を正しく使用していることが完全に保証されるわけではありませんが、判断基準にはなります。同様にして、ログイン・ユーティリティーのほかに Apache についても PAM に対応するかどうかを確認したい場合があります。

リスト 14. Apache とログイン・ユーティリティーが PAM に対応しているかどうかの確認
      % ldd /usr/sbin/apache2 | grep libpam
      % ldd /bin/login | grep libpam
      libpam.so.0 => /lib/libpam.so.0 (0xb7fa8000)
      libpam_misc.so.0 => /lib/libpam_misc.so.0 (0xb7fa5000)

上記の結果から、私が使用している Apache インストール済み環境は PAM には対応していないことがわかります (ただし、PAM 対応のバージョンもあります)。

PAM が特定のツールで完全に機能しているかどうかをもっと詳しく調べるためには、そのツール用の PAM 構成ファイルを作成するという方法があります。例えば、ログイン・ユーティリティーをテストするとしたら、以下のような内容の /etc/pam.d/login ファイルを作成します (ただし、このファイルはおそらくシステムにすでに存在しているはずです。その設定のほうがより有意義であることが考えられるので、既存のファイルを削除しないでください)。

リスト 15. etc/pam.d/login を使用することによる、ログイン・ユーティリティーが PAM に対応しているかどうかの確認
      auth      required    pam_permit.so
      auth      required    pam_warn.so

これで PAM に適切に対応した login を実行すると誰でもログインすることができ、syslog にそのアクションが記録されるはずです。syslog にエントリーが示されていれば、このアプリケーションは PAM に対応していることになります。お気付きかもしれませんが、この構成では誰にでもシェル・アクセスを許可してしまうため、これは考えうる最悪の構成です。この点を念頭に、PAM は慎重に構成しなければならないことに注意してください。

PAM の設定

PAM は、2 種類の構成ファイルで機能します。libpam.so ライブラリーで行われるコンパイルのほとんどは「使用可能な場合は良いほうのファイルを使用するが、悪いほうのファイルでもよしとする」という方法が採られます。その一方、「良いほうのファイルを使用するが、悪いほうのファイルもチェックする」という方法で PAM ライブラリーをコンパイルすることもできます。その仕組みについて説明します。

現在推奨されている PAM の構成方法は、サービスと同じ名前を付けたファイルを /etc/pam.d/ ディレクトリー内に作成し、そのファイルに当該サービスのセキュリティーを記述する方法です。今では推奨されていない以前の方法では、/etc/pam.conf という単一のファイルを使用して、すべてのアプリケーションのセキュリティー・ポリシーを設定していました。保守の観点からすると、アプリケーションごとに構成ファイルがあったほうが作業しやすく、シンボリック・リンクを作成して、あるアプリケーションのセキュリティー・ポリシーを別のアプリケーションに「複製」することもできます。どちらの構成スタイルにしても、基本的には同じように見えます。単一の /etc/pam.conf ファイルに含まれる行は、以下の形式となっています。

リスト 16. /etc/pam.conf ファイルに含まれる行の形式
      <service>  <module-type>  <control-flag>  <module-path>  <args>

アプリケーションごとの構成ファイルの場合、最初のフィールドはファイル名と同じになるため、省略されます。古いスタイルでは、前に取り上げたテスト目的のログイン構成は以下のようになります。

リスト 17. /etc/pam.conf
      login     auth      required    pam_permit.so
      login     auth      required    pam_warn.so

<module-type> フィールドの値は、以下の 4 つのうちのいずれかです。

  • auth (認証に関する処理などを行う)
  • account (ユーザーのステータスで構成されるシステムに基づき、認証以外のアクセス許可などに関する処理を行う)
  • session (サービスが使用される前や、使用された後にアクションを行う)
  • password (ユーザー認証のトークンの更新などを行う)

<control-flag> フィールドは、モジュールを「積み重ね」ることで、ある特定の認証方法がどのようなときに必要で、そもそもその認証方法が実行されるのかどうか、そしてどのようなときに他の認証方法へのフォールバックを許容するのかをきめ細かく制御するために使用します。

取りうる値は以下のとおりです。

  • required
  • requisite
  • sufficient
  • optional
  • include

これらについては、次のセクションで説明します。

これまで記載した例でも使用されている <module-path> は、要求されるモジュール・ロケーション (パスが指定されていない場合) の共有ライブラリー名、または明示的ロケーション (パスが「/」で始まる場合) の共有ライブラリー名を指定します。リスト 17 では、あるいは /lib/security/pam_warn.so を指定することもできます。<args> には、特定のモジュールがその操作を構成するために必要な内容に応じて任意の値を指定することができますが、ほとんどの PAM モジュールでは、限られた数の汎用的な引数しかサポートしていません。ただし、PAM モジュールは拡張可能であることに注意してください。誰かが新しい PAM モジュールを作成した場合には、そのモジュールを /lib/security に追加し、それを反映するようにアプリケーションの構成ファイルを更新するだけで、すべてのアプリケーションが新規モジュールを使用できるようになります。

PAM パーミッションの例

<control-flag> がどのように機能するかを理解するために、これから、やや複雑なサンプルを作成します。まず始めに行うべきことは、特殊な OTHER サービスの作成です。OTHER があれば、サービスに対して PAM ポリシーが定義されていない場合、OTHER のポリシーが使用されます。リスト 18 に、安全なデフォルトの例を記載します。

リスト 18. /etc/pam.d/other
      auth      required    pam_warn.so
      auth      required    pam_deny.so
      @include safe-account
      @include safe-password
      @include safe-session

上記の例では、認証時の試行は syslog に記録された後に、拒否されます。@include ステートメントは、/etc/pam.d/safe-account やその仲間のコンテンツをインクルードするだけに過ぎません。これにより、これらの「安全」なデフォルトの定義に、他の <module-type> での認証試行に対する同様の命令 (警告してから拒否) を含めることができます。

ここで、仮想の classified-db アプリケーションに対するアクセス権限を構成します。このアプリケーションを使用するユーザーはアクセスについて懸念していることから、ユーザーは一致する網膜または指紋のいずれかを提供するだけでなく、パスワードを入力することになっています。ただし、パスワードはローカル構成ファイルの /etc/passwd または /etc/shadow のいずれかに保管され、2 つの外部データベース・サーバーのいずれかから入手することができます。

この例で使用するセキュリティー・モジュールのうち、実在するのは (私が知っている限り) pam_unix.so だけです。このモジュールは、昔ながらの UNIX スタイルでパスワード・アクセスを制御します。

リスト 19. /etc/pam.d/classified-db
      auth      optional    pam_unix.so
      auth      optional    pam_database1.so    try_first_pass
      auth      optional    pam_database2.so    use_first_pass
      auth      requisite   pam_somepasswd.so
      auth      sufficient  pam_fingerprint.so  master=file1 7points
      auth      required    pam_retinaprint.so

この構成のフローは、多少複雑です。まず、3 つの optional モジュール・タイプでパスワード認証を試行します。これらの認証試行は optional であるため、1 つのモジュール・タイプで認証に失敗したとしても、認証プロセスが停止したり、完了したりすることはありません。最初に試行されるのは、標準の UNIX 認証パスワードです (ユーザーに対し、パスワードの入力が促されます)。次に、database1 でパスワードをチェックしますが、このチェックでは最初に汎用モジュール引数 try_first_pass を使用して、UNIX パスワードがデータベース内のパスワードと同じであるかどうかを調べます。同じでない場合に限り、パスワードの入力をさらに促します。ただし、database2 の場合には、ユーザーが入力した UNIX パスワード (汎用引数 use_first_pass) を使用して認証を試行するだけです。

optional のパスワード・システムと照合させるために使用しているのは、仮想の pam_somepasswd.so です。このモジュールは、それまでに行われたパスワードのチェックで、成功したものがあるかどうかを判別します (それにはおそらくセマフォーを使用しますが、その方法は、仮想モジュールに任されます)。重要な点は、このチェックが requisite であることです。したがって、失敗した場合には、それ以上の認証は行われず、失敗がレポートされます。

最後の 2 つの認証チェック (このチェックに到達した場合) は、sufficient です。つまり、いずれか 1 つのチェックが成功すれば、全体としての成功ステータスが呼び出し側アプリケーションに返されます。最初に pam_fingerprint.so を使用して指紋のチェックを行います (モジュールには仮想の引数が渡されることに注意してください)。このチェックが (おそらく、指紋スキャナーがないか、指紋のスキャン結果が不適切であることが理由で) 失敗した場合に限り、網膜スキャンが試行されます。網膜スキャンの場合も、成功すれば sufficient と同じく成功ステータスが返されますが、ここではすべてのフラグを説明するために required を使用していることに注意してください。従って、網膜スキャンが成功したとしても他の方法でチェックを続けることになります (けれども、この例には、それ以上のチェックはないため、sufficient を使ったとしても同じことです)。

<control-flag> に微調整した複合フラグを指定する方法は他にもありますが (括弧で囲んだ [value1=action1 ...] のセットを使用するなど)、通常は基本のキーワードだけで間に合います。

参考文献

学ぶために

製品や技術を入手するために

  • developerWorks から直接ダウンロードできる IBM ソフトウェアの試用版を使用して、Linux で次の開発プロジェクトを構築してください。

議論するために

コメント

developerWorks: サイン・イン

必須フィールドは(*)で示されます。


IBM ID が必要ですか?
IBM IDをお忘れですか?


パスワードをお忘れですか?
パスワードの変更

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


お客様が developerWorks に初めてサインインすると、お客様のプロフィールが作成されます。会社名を非表示とする選択を行わない限り、プロフィール内の情報(名前、国/地域や会社名)は公開され、投稿するコンテンツと一緒に表示されますが、いつでもこれらの情報を更新できます。

送信されたすべての情報は安全です。

ディスプレイ・ネームを選択してください



developerWorks に初めてサインインするとプロフィールが作成されますので、その際にディスプレイ・ネームを選択する必要があります。ディスプレイ・ネームは、お客様が developerWorks に投稿するコンテンツと一緒に表示されます。

ディスプレイ・ネームは、3文字から31文字の範囲で指定し、かつ developerWorks コミュニティーでユニークである必要があります。また、プライバシー上の理由でお客様の電子メール・アドレスは使用しないでください。

必須フィールドは(*)で示されます。

3文字から31文字の範囲で指定し

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


送信されたすべての情報は安全です。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Linux, Open source
ArticleID=828047
ArticleTitle=LPI 試験対策: ネットワーク・クライアントの管理
publish-date=08022012