パート III NIS+ の管理

このパートでは、Solaris オペレーティング環境上での NIS+ ネームサービスの管理および問題解決について説明します。

第 10 章 NIS+ のテーブルと情報

この章では、これらのテーブルの構造と設定方法の概要について説明します。

NIS+ は、将来のリリースでサポートされない可能性があります。NIS+ から LDAP への移行支援ツールは、Solaris 9 オペレーティング環境で使用できます (『Solaris のシステム管理 (ネーミングとディレクトリサービス : DNS、NIS、LDAP 編)』を参照)。詳細については、http://www.sun.com/directory/nisplus/transition.html を参照してください。

NIS+ テーブル構造

NIS+ は、さまざまなネットワーク情報をテーブルに格納します。NIS+ テーブルには、単純なテキストファイルやマップには見られない機能がいくつかあります。これらのテーブルは列エントリ構造をもち、検索パスを使用することや、リンクすることができ、しかも複数の設定方法があります。NIS+ にはあらかじめ構成された 16 個のシステムテーブルがあり、独自のテーブルを作成することもできます。表 10–1 は、事前構成した NIS+ テーブルを示します。

cred テーブルには NIS+ のセキュリティに関係する情報だけが入っています。これについては第 12 章「NIS+ 資格の管理」で説明します。

これらのテーブルには、ユーザー名からインターネットサービスまでの幅広い情報が格納されています。この情報の多くは、設定時または構成の手順の中で生成されます。たとえば、password テーブル内のエントリは、ユーザーアカウントが設定されたときに作成されます。hosts テーブル内のエントリは、マシンがネットワークに追加されたときに作成されます。また、networks テーブル内のエントリは、新しいネットワークが設定されたときに作成されます。

この情報はこのような広範囲にわたる操作によって生成されるため、このマニュアルでは詳細を説明していません。ただし、使いやすさを考慮して、テーブルの各列に含まれる情報は、第 23 章「NIS+ テーブルの情報」 に要約してあります。詳細な説明は、グループを NIS+ グループやネットグループと区別する場合など、理解しにくい内容についてのみ行います。テーブルの情報の詳細は、Solaris の「システム管理マニュアルセット」と「ネットワーク管理マニュアルセット」を参照してください。

ドメインにさらに多くのオートマウントマップを作成できますが、必ず NIS+ テーブルとして格納し、auto_master テーブルの中に入れてください。オートマウントマップを作成して、ユーザー用に作成された auto_master に追加するときは、列名にはキーと値が必要です。オートマウントの詳細は、オートマウントまたは NFS ファイルシステムの関連マニュアルを参照してください。

ネームサービスとして、NIS+ テーブルはオブジェクト自体ではなく、オブジェクトの参照情報を格納するように設計されています。そのため、NIS+ はエントリの大きなテーブルをサポートできません。テーブルに非常に大きなエントリがある場合、rpc.nisd は機能しません。

列とエントリ

NIS+ テーブルにはさまざまな種類の情報が格納されていますが、これらの基本構造はすべて同じで、行と列から構成されます。この列は、「エントリ」または「エントリオブジェクト」と呼ばれます。

クライアントは、キー、または検索可能な任意の列によりアクセスできます。たとえば、baseball という名前のマシンのネットワークアドレスを見つけるには、ホスト名の列を探して baseball を見つけます。

次に、baseball のエントリ行を移動して、そのネットワークアドレスを見つけます。

クライアントは、任意のレベルでテーブル情報にアクセスできる (つまり、テーブルに全体としてアクセスできる) ため、NIS+ は 3 つのレベルすべてにセキュリティ機構を提供しています。たとえば、管理者は、オブジェクトレベルで全員にテーブルの読み取り権を割り当て、列レベルで所有者に変更権を割り当て、エントリレベルでグループに変更権を割り当てることができます。テーブルのセキュリティの詳細は、第 15 章「NIS+ のアクセス権の管理」で説明します。

検索パス

テーブルには、その「ローカル」ドメインについての情報だけが収められています。たとえば、doc.com. ドメイン内のテーブルには、doc.com. ドメインのユーザー、クライアント、およびサービスについての情報だけが収められています。 たとえば、sales.doc.com. ドメイン内のテーブルには、sales.doc.com. ドメインのユーザー、クライアント、およびサービスについての情報だけが収められています。

あるドメイン内のクライアントが、別のドメインに格納されている情報を見つけようとした場合、完全指定名を使用しなければなりません。環境変数 NIS_PATHに説明されているように、環境変数 NIS_PATH が正しく設定されていれば、NIS+ サービスによって自動的に処理されます。

情報を探すときにサーバーがたどる「検索パス」をどの NIS+ テーブルでも指定できます。この検索パスは、NIS+ テーブルをコロンで区切って順番に並べたものです。

table:table:table...

検索パス内のテーブル名は、完全指定する必要はありません。テーブル名は、コマンド行で入力された名前と同じように展開されます。サーバーが自分のローカルテーブル内に情報を検出できなかった場合、サーバーはクライアントにテーブルの検索パスを返します。クライアントはそのパスを使用して、その情報が見つかるかまたは最後まで、検索パスに名前があるすべてのテーブルを順番に探していきます。

検索パスのメリットを次に示します。次のようなドメイン階層があるとします。

下位にある 3 つのドメインの hosts テーブルの内容は次のようになります。

ここで、sales.doc.com. ドメイン内の luna にログインしたユーザーが、別のクライアントにリモートログインする場合を考えてみます。このユーザーが完全指定名を指定しない場合、そのユーザーがリモートログインできるのは localhost、 phoebus、europa、ganymede、および mailhost の 5 台のマシンだけです。

sales.doc.com. ドメインの hosts テーブルの検索パスに、manf.doc.com. ドメインの hosts テーブルが指定されていると仮定します。

hosts.org_dir.manf.doc.com.

これで sales.doc.com. ドメイン内のユーザーは、たとえば、rlogin sirius と入力することができ、NIS+ サーバーはこれを検出します。NIS+ サーバーはまずローカルドメインで sirius を探し、見つからなければ manf.doc.com. ドメイン内を探します。 クライアントは manf.doc.com. ドメインをどのように認識するのでしょうか。 第 2 章「NIS+ の紹介」で説明したように、この情報はディレクトリキャッシュに格納されています。これがディレクトリキャッシュにない場合、クライアントは、第 2 章「NIS+ の紹介」で説明したプロセスに従ってこの情報を入手します。

ただし、検索パスを指定する方法には、若干の欠点があります。ユーザーがたとえば、rlogin luba (luna でなく) などと間違った名前を入力した場合、サーバーは 1 つのテーブルではなく、3 つのテーブルを探さなければエラーメッセージを返せません。名前空間の全域に検索パスを設定した場合、1 つの操作は 2、3 のドメインではなく、10 個のドメイン内のテーブルを検索してから終了します。もう 1 つの欠点は、多数のクライアントが NIS+ テーブルにアクセスする必要があるとき、複数のサーバーのセットと通信するために、パフォーマンスの低下を招くという点です。

また、mailhost は別名として使用されることが多いため、特定のメールホストについての情報を探したいときは、その完全指定名 (mailhost.sales.doc.com. など ) を使用しなければなりません。そうしないと、NIS+ は検索したすべてのドメインで見つけたすべてのメールホストを返します。そうしないと、 NIS+ は、検索したすべてのドメインで見つかったメールホストをすべて返します。

テーブルの検索パスを指定するには、nistbladm コマンドで説明するように、nistbladm コマンドに -p オプションを付けて実行します。

テーブルの設定方法

NIS+ テーブルの設定には 3 つまたは 4 つの作業が伴います。

1. org_dir ディレクトリの作成

2. システムテーブルの作成

3. システムテーブル以外のテーブルの作成 (必要に応じて)

4. 情報を入力してテーブルを生成 (populate) する

NIS+ のファイルとディレクトリで説明したように、NIS+ のシステムテーブルは org_dir ディレクトリに格納されます。したがって、テーブルを作成するには、その前にテーブルを入れる org_dir ディレクトリを作成しなければなりません。これには 3 つの方法があります。

• nisserver スクリプトを使用。nisserver スクリプトは、ディレクトリとシステムテーブのフルセットを作成します。nisserver スクリプトを実行することを推奨します。

• nismkdir コマンドを使用。nismkdir コマンドは単にディレクトリを作成するものです。

• /usr/lib/nis/nissetup ユーティリティを使用。nissetup ユーティリティは org_dir および groups_dir ディレクトリとシステムテーブルのフルセットを作成します。

nisserver スクリプトと、nissetup および nismkdir ユーティリティについては、nismkdir コマンド を参照してください。また、nismkdir コマンドの詳細については、nismkdir コマンド を参照してください。

nissetup ユーティリティのメリットは、サーバーが NIS 互換モードで動作しているドメインのテーブルに対して、適切なアクセス権を割り当てる機能です。-Y フラグを付けて実行すると、このユーティリティは作成するオブジェクトの「未認証」カテゴリに読み取りアクセス権を割り当てます。その結果、未認証の NIS クライアントは、そのドメインの NIS+ テーブルから情報を得ることができます。

NIS+ の 16 個のシステムテーブルと、これらに格納される情報の種類については、第 10 章「NIS+ のテーブルと情報」で説明します。これらを作成するには、前述の 3 つの方法を使用できます。nistbladm コマンドは NIS+ テーブルの作成と変更を行います。nistbladm コマンドで名前空間内のすべてのテーブルを作成できますが、入力量が多くなり、列の正確な名前やアクセス権を知っている必要があります。nisserver スクリプトを使う方がはるかに簡単です。

システムテーブル以外のテーブル、つまり NIS+ によってまだ構成されていないテーブルを作成するには、nistbladm コマンドを使用します。オートマウントマップを追加する場合は、キーの列と値の列が必要です。

NIS+ テーブルを生成するには、NIS マップから行う方法、ASCII ファイル (/etc 内のファイルなど) から行う方法、および手作業の 3 つの方法があります。

NIS サービスからアップグレードしている場合、すでにネットワーク情報の大部分が NIS マップに格納されています。この情報を NIS+ テーブルに手作業で再入力する必要はありません。nispopulate スクリプトか nisaddent ユーティリティで自動的に転送できます。

他のネットワーク情報サービスを使用していない場合で、しかもネットワークデータを /etc 内のファイルで管理しているときも、この情報を再入力する必要はありません。nispopulate スクリプトか nisaddent ユーティリティを使用すれば自動的に転送できます。

初めてネットワークを設定する場合、十分なネットワーク情報がどこにも格納されていないことがあります。この場合、まず情報を入手して、次に NIS+ テーブルに手作業で入力する必要があります。これを行うには、nistbladm コマンドを使用できます。また、特定のテーブルの全情報を「入力ファイル」(これは本質的に /etc 内のファイルと同じです) に入力し、次に、nispopulate スクリプトか nisaddent ユーティリティを使用してファイルの内容を転送することによっても同じことが行えます。

テーブルの更新方法

ドメインが設定されると、サーバーはそのドメインの NIS+ テーブルの最初のバージョンを受け取ります。これらのバージョンはディスクに格納されますが、サーバーは起動されると、これらをメモリーにロードします。サーバーがテーブルに対する更新を受信すると、サーバーはそのメモリーにあるテーブルをすぐに更新します。サーバーが情報の要求を受信すると、その応答のためにメモリーにあるコピーを使用します。

もちろん、サーバーはその更新をディスクにも格納する必要があります。ディスクにあるテーブルを更新するには時間がかかるため、NIS+ の全サーバーはテーブル用の「ログ」ファイルを持っています。このログファイルは、テーブルに対して行われた変更内容を、ディスク上で更新できるまで、一時的に格納するように設計されています。ログファイルは、テーブル名を接頭辞として使用し、これに .log を追加します。たとえば :

hosts.org_dir.log
bootparams.org_dir.log
password.org_dir.log
ipnodes.org_dir.log

ログファイルが大きくなりすぎて大量のディスク領域を占有しないように、ディスクにあるテーブルのコピーは毎日更新しなければなりません。このプロセスは「チェックポイントを実行する」と呼ばれます。これには、nisping -C コマンドを使用します。

第 11 章 NIS+ のセキュリティの概要

この章では、NIS+ のセキュリティシステムと、システムが NIS+ 名前空間全体に与える影響について説明します。

NIS+ は、将来のリリースでサポートされない可能性があります。NIS+ から LDAP への移行支援ツールは、Solaris 9 オペレーティング環境で使用できます (『Solaris のシステム管理 (ネーミングとディレクトリサービス : DNS、NIS、LDAP 編)』を参照)。詳細については、http://www.sun.com/directory/nisplus/transition.html を参照してください。

Solaris のセキュリティ - 概要

Solaris のセキュリティは、ユーザーが Solaris 環境に入るために通過しなければならないゲートと、内部でそのユーザーが何をできるのかを判定するアクセス権マトリックスの 2 つによって確保されています。このセキュリティシステムの概略については、図 11–1 を参照してください。

図 11–1 Solaris のセキュリティゲートとフィルタ

上の図に示すように、Solaris システムは 4 つのゲートと 2 つのアクセス権マトリックスから構成されます。

• 「ダイアルアップゲート」モデムや電話回線により Solaris 環境にアクセスするには、正しいログイン ID とダイアルアップパスワードが必要です。

• 「ログインゲート」Solaris 環境に入るには、正しいログイン ID とユーザーパスワードが必要です。

• 「ファイルおよびディレクトリマトリックス」Solaris 環境に入ってから、ファイルやディレクトリに関して、読み取り、実行、変更、作成、削除等の各種操作を行う権限はアクセス権マトリックスによってコントロールされます。

• 「root ゲート」root 権限にアクセスするには、正しいスーパユーザー (root) パスワードが必要です。

• 「RPC ゲートによる保護」セキュリティレベル 2 (デフォルト値) の NIS+ 環境においては、NIS+ サービスを使って NIS+ オブジェクト (サーバー、ディレクトリ、テーブル、テーブルエントリなど) にアクセスしようとする場合、ユーザー ID は Secure RPC プロセスを使った NIS+ によって確認されます。

  ダイヤルアップ、ログイン、ルートゲート、およびファイルとディレクトリのアクセス権マトリクスの詳細は、Solaris の各マニュアル及び資料を参照してください。

  Secure RPC ゲートをパスするには、Secure RPC パスワードが必要です。「Secure RPC パスワード」は、「ネットワークパスワード」と呼ばれる場合もあります。Secure RPC パスワードとログインパスワードは通常同一なので、ゲートをパスした場合はパスワードを再入力する必要がありません (2 つのパスワードが異なった場合についての説明は、Secure RPC パスワードとログインパスワードの問題 を参照)。

  ユーザー要求が Secure RPC ゲートを自動的にパスするのに、1 組の「資格」セットが使われます。ユーザーの資格を作成、提示、判定するプロセスを、そのプロセスがユーザーが誰であり、正しい RPC パスワードを所持しているかを確認することから、「認証 (authentication)」と呼びます。この認証プロセスは、ユーザーが NIS+ サービスを要求するごとに自動的に実行されます。

  NIS 互換モード (YP 互換モードでもある) の NIS+ 環境では、ユーザーが正しい資格を所持しているかにかかわらず (認証プロセスによって、ID が確認され、Secure RPC パスワードがチェックされたかにかかわらず)、誰でもすべての NIS+ オブジェクトを読み取ることができ、またそれらエントリを変更できるので、Secure RPC ゲートによるガードは極めて弱くなります。誰もがすべての NIS+ オブジェクトを読み取りかつそれらエントリを変更できるので、互換モードの NIS+ ネットワークは通常モードのよりも安全性が低くなります。

  NIS+ の認証と資格の作成および管理については、第 12 章「NIS+ 資格の管理」を参照してください。

• 「NIS+ オブジェクトマトリックス」一度正しく認証されると、ユーザーが NIS+ オブジェクトを読み取り、変更、作成、削除する権限はアクセス権マトリックスに管理されます。このプロセスをNIS+ の「承認 (authorization)」と呼びます。

  NIS+ のアクセス権および承認の詳細は、第 15 章「NIS+ のアクセス権の管理」を参照してください。

NIS+ のセキュリティ - 概要

NIS+ のセキュリティは NIS+ の名前空間全体にかかわっています。セキュリティと名前空間を別に設定することはできません。このため、セキュリティの設定方法は名前空間の各構成要素を設定する手順と密接に関係することになります。一度 NIS+ のセキュリティ環境を設定すると、その後はユーザーの追加および削除、アクセス権の変更、グループメンバーの再割当やネットワーク展開を管理するために必要なその他すべての管理ルーチンタスクを実行できます。

NIS+ のセキュリティ機能は名前空間内の情報と、名前空間そのものの構造を不正アクセスから保護するものです。このセキュリティ機能がなければ、どんな NIS+ クライアントであっても名前空間に保存された情報を獲得することも変更することもできないだけでなく、ダメージを与える可能性があります。

NIS+ セキュリティには次の 2 つの機能があります。

• 「認証 (authentication)」。認証は NIS+ 主体を識別するのに使われます。主体 (ユーザーまたはマシン) が NIS+ オブジェクトにアクセスしようとするときはいつも、ユーザー ID と Secure RPC パスワードが確認されチェックされます。

• 「承認 (authorization)」。承認はアクセス権を識別するのに使われます。NIS+ 主体が NIS+ オブジェクトにアクセスしようとするときはいつも、所有者、グループ、その他、未認証の 4 つのクラスの 1 つに位置付けられています。NIS+ セキュリティシステムは NIS+ 管理機能により、各クラスに NIS+ オブジェクトに対する読み取り、変更、作成、削除の各権限を指定します。たとえば、あるクラスは passwd テーブルの特定列を変更できるが、その列を読み取ることはできないように、あるいは別のクラスはいくつかのエントリを読み取ることはできるが、それ以外はできないように設定できます。

NIS+ のセキュリティ機能は 2 段階のプロセスを用意しています。

1. 「認証 (authentication)」。NIS+ は資格 (credential) を使ってユーザーを確認します。

2. 「承認 (authorization)」。承認プロセスがユーザー ID を確認すると、NIS+ はクラスを判定します。NIS+ オブジェクトまたはサービスに対して何が行えるのかは、ユーザーがどのクラスに属しているかに依存します。これは UNIX の標準的なファイルおよびディレクトリのアクセス権システムと同様の考え方に基づいています (クラスの詳細は、承認クラス を参照)。

このプロセスは、マシン A の root 権限を持つユーザーが su コマンドを使って、第 2 の NIS+ アクセス権で NIS+ オブジェクトにアクセスすることを防ぐものです。

ただし、NIS+ は、他人のユーザーログインパスワードを知っている者が、そのユーザーになりすましてユーザー ID と NIS+ アクセス権を使用することを妨ぐことはできません。また root 権限を持つユーザーが「同一」マシンからログインしている別のユーザーになりすますのを防ぐこともできません。

図 11–2 に、このプロセスの詳細を示します。

図 11–2 NIS+ セキュリティプロセスの概要

NIS+ の主体について

NIS+ の主体とは、NIS+ サービス要求を依頼するエンティティ (クライアント) です。NIS 主体には、クライアントマシンに一般ユーザーとしてログインしたユーザー、スーパーユーザーとしてログインしたユーザー、NIS+ クライアントマシンにおいてスーパーユーザー特権で動作しているプロセスを含みます。つまり NIS+ の主体はクライアントユーザーの場合もクライアントマシンの場合もあります。

NIS+ の主体は、NIS+ サーバーから NIS+ サービスを提供する主体を指すこともあります。すべての NIS+ サーバーは NIS+ クライアントにもなるので、サーバーが NIS+ の主体となる場合もあります。

NIS+ セキュリティレベル

NIS+ サーバーは、2 つのセキュリティレベルのどちらかで動作します。セキュリティレベルにより、要求を送信して認証を取得しなければならない資格主体の種類が決まります。NIS+ は、最高セキュリティレベル (セキュリティレベル 2) で動作するように設計されています。レベル 0 は、テスト、設定、およびデバッグのときにだけ使用します。セキュリティレベルについては、表 11–1 を参照してください。

セキュリティレベルとパスワードコマンド

Solaris リリース 2.0 から 2.4 の環境では、nispasswd を使用してパスワードを変更します。ただし、資格がなければ、nispasswd は機能しません (より上位のレベルでの資格があった場合を除き、セキュリティレベル 0 以下では機能しない)。Solaris リリース 2.5 以降の場合は、セキュリティレベルや資格ステータスにかかわらず、passwd コマンドを使ってパスワードを変更できます。

NIS+ の認証と資格 - 紹介

NIS+ 資格の目的は、NIS+ サービスや NIS+ オブジェクトへのアクセスを要求する各主体の ID を「認証」(確認) することにあります。つまり、NIS+ 資格および承認プロセスは Secure RPC システムを実装することです。

資格および認証システムは他人になりすますのを防ぐシステムです。あるマシンの root 権限を持つユーザーが su コマンドを使って、ログインしていないもしくは別のマシンにログインしている第 2 のユーザーになりすまし、NIS+ アクセス権を使用して NIS+ オブジェクトにアクセスすることを妨げます。

サーバーが主体を認証すると、主体は 4 つの認証クラスのどれかに置かれ、次にサーバーは承認されている動作を知るためにアクセスしようとする NIS+ オブジェクトをチェックします。承認の詳細は、NIS+ の承認とアクセス - 紹介を参照してください。

ユーザーおよびマシンの資格

主体には、「ユーザー」と「マシン」の 2 つの基本的な種類があります。

• 「ユーザー (user) 資格」。一般ユーザーとして NIS+ クライアントにログインした場合、NIS+ サービス要求には当人の「ユーザー」資格を含みます。

• 「マシン (machine) 資格」。スーパーユーザーとして NIS+ クライアントにログインした場合、サービス要求は「クライアントマシン」資格を使います。

DES と LOCAL 資格

NIS+ 主体には DES と LOCAL の 2 つの資格が用意されています。

DES 資格 (credential)

認証を行う仕組みとしては DES 資格が唯一のものです。将来は他の仕組みも利用できるようになるかもしれません。DES 資格と NIS+ 資格は同等のものではありません。

このマニュアルでは、DES 資格という用語は、鍵の長さにかかわりなく Diffie - Hellman 鍵をベースにした認証を表すものとして一般的に使われています。鍵の長さはあらかじめ決められたセットから指定することができます。Diffie - Hellman 鍵の長さの設定や表示を行うには nisauthconf(1M) を使用します。

DES (データ暗号化規格) 資格は資格の 1 種であり、保護認証を提供するものです。このマニュアルで NIS+ 主体を認証するために資格をチェックすると記述している場合は、NIS+ がチェックしている DES 資格のことを意味します。

主体が NIS+ サービスを要求したり、NIS+ オブジェクトにアクセスするごとに、ソフトウェアは格納してある資格情報を使って主体の資格を作成します。DES 資格は NIS+ 管理機能によって各主体に作られた情報から作成されます。第 12 章「NIS+ 資格の管理」を参照してください。

• 主体の DES 資格の正当性を NIS+ が確認すると、その主体は「認証」されます。

• 主体は所有者、グループ、その他のいずれかの承認クラスを得るために認証されなければなりません。つまり、これらクラスの１つを得るために、有効な DES 資格を持つ必要があるのです。有効な DES 資格を持たない主体は自動的に未認証クラスに割り当てられます。

• 主体がクライアントユーザーであるかクライアントマシンであるかにかかわらず、DES 資格情報は常に主体のホームドメインの cred テーブルに格納されます。

LOCAL 資格

LOCAL 資格は、ユーザー ID 番号とホームドメイン名を含む NIS+ 主体名とのマップです。ユーザーがログインすると、システムは DES 資格が格納されているホームドメインを特定する LOCAL 資格をチェックします。システムはその情報を使ってユーザーの DES 資格情報を獲得します。

ユーザーがリモートドメインにログインした場合、その要求はユーザーのホームドメインを示す LOCAL 資格を使います。NIS+ は次にユーザーの DES 資格情報を知るためにユーザーのホームドメインを問い合わせます。こうして、たとえユーザーの DES 資格情報がリモートドメインに格納されていなくても、リモートドメインで認証されます。

図 11–3 資格とドメイン

LOCAL 資格情報はどのドメインにも格納できます。実際、リモートドメインにログインし認証されるためには、クライアントユーザーはリモートドメインの cred テーブルに LOCAL 資格を持っている必要があります。ユーザーが、アクセスしようとするリモートドメインに LOCAL 資格を持っていなかった場合、NIS+ はユーザーの DES 資格を獲得するためにユーザーのホームドメインに入ることができなくなります。そのような場合、ユーザーは認証されず未認証クラスを与えられることになります。

ユーザータイプと資格種類

ユーザーは両方の資格を持つことができますが、マシンは DES 資格しか持てません。

すべてのマシンの root UID は常に 0 であるため、root は他のマシンに対して NIS+ アクセスできません。もしマシン A の root (UID=0) がマシン B にアクセスしようとすると、すでに存在しているマシン B の root (UID=0) と衝突します。このため、LOCAL 資格は、クライアント「マシン」については意味を持たないため、クライアント「ユーザー」にだけ認められています。

NIS+ の承認とアクセス - 紹介

NIS+ の承認の基本的目的は、各 NIS+ 主体が各 NIS+ オブジェクトとサービスに対して持っているアクセス権を特定することにあります。

一度主体の NIS+ 要求が認証されると、NIS+ は承認クラスを与えます。NIS+ オブジェクトに対して行うことのできる動作を指定するアクセス権は各クラスに与えられます。クラスごとに別のアクセス権が与えられる場合、各承認クラスはそれぞれアクセス権を持つということです。

• 「承認クラス」。承認クラスには次の 4 つがあります。所有者、グループ、その他、未認証 (詳細は、次の承認クラスを参照)。

• 「アクセス権」。アクセス権には次の 4 つがあります。作成 (CREATE)、削除 (DESTROY)、変更 (MODIFY)、読み取り (READ) (詳細は、NIS+ アクセス権を参照)。

承認クラス

NIS+ オブジェクトは NIS+ 主体に直接アクセス権を与えずに、主体の 4 つの「クラス」にアクセス権を与えます。

• 「所有者」。オブジェクトの所有者になった主体が所有者クラスの権限を与えられます。

• 「グループ」。各 NIS+ オブジェクトグループは関連した 1 つのグループを持ちます。オブジェクトグループのメンバーは NIS+ 管理機能が指定します。オブジェクトグループクラスに属している主体がグループクラスの権限を与えられます。この場合の「グループ」とは NIS+ グルーブを表します。UNIX のグループやネットグループのことではありません。

• 「その他」。その他クラスは、サーバーが認証できるすべての NIS+ 主体を包含するクラスです。所有者とグループクラスを除く、すべての認証されたものを意味します。

• 「未認証」。認証されていないものすべてを意味します。

図 11–4 承認クラス

システムは、NIS+ 要求を受信すると、要求を出している主体が属しているクラスを判定します。主体は、判定されたクラスに属しているすべてのアクセス権を使用できます。

オブジェクトに対するアクセス権は、各クラスで任意の組み合わせが可能です。ただし、通常は上位クラスが下位クラスのすべての権限に追加権限を持つように割り当てられます。

たとえば、未認証およびその他クラスには読み取りアクセスを許可し、グループクラスには読み取りおよび変更アクセスを許可し、所有者クラスには読み取り、変更、作成、および削除アクセスを許可することができます。

4 つのクラスについては、以下に詳しく説明します。

所有者クラス

所有者は「単一」の NIS+ 主体です。

NIS+ オブジェクトへのアクセスを要求する主体は、所有者アクセス権を得る前に認証され (有効な DES 資格を提示し) なければなりません。

デフォルトではオブジェクトの所有者は、オブジェクトを作成した主体になります。ただし、オブジェクト所有者は 2 つの方法で別の主体に所有権を譲ることができます。

• オブジェクトが作成されたときに、主体が別の所有者を指定する方法 ( コマンドによるアクセス権の指定を参照)

• オブジェクトの作成後に、主体がオブジェクトの所有権を変更する方法 ( オブジェクトとエントリの所有権の変更を参照)

一度主体が所有権を放棄すると、その主体はオブジェクトに対する所有者のアクセス権すべてを放棄することになり、グループ、その他、未認証のいずれかの所有権を持つことになります。

グループクラス

オブジェクトグループは 1 つの NIS+ グループです。この場合の「グループ」とは、UNIX のグループやネットグループのことではありません。

NIS+ オブジェクトにアクセスを要求する主体は、認証され (有効な DES 資格を提示し) かつグループアクセス権を与えられる前にそのグループに属していなければなりません。

1 つの NIS+ グループは NIS+ 主体の集合であり、名前空間へのアクセス権を与えるのに都合の良いようにまとめられたものです。NIS+ グループに与えられるアクセス権はそのグループのメンバーである主体すべてに適用されます。オブジェクトの所有者が、そのオブジェクトのグループに属している必要はありません。

オブジェクトが作成された時、そのオブジェクトはデフォルトグループに割り当てられます。オブジェクトが作成された時でもその後でも、そのオブジェクトをデフォルト以外のグループに割り当てることができます。オブジェクトグループはいつでも変更できます。

NIS+ グループに関する情報は NIS+ group テーブルに格納されないことに注意してください。NIS+ group テーブルには UNIX グループに関する情報が格納されます。NIS+ グループに関する情報は、適切な groups_dir ディレクトリのオブジェクトに格納されます。

NIS+ グループの情報は、各 NIS+ ドメインの groups_dir サブディレクトリにある、NIS+ グループ「オブジェクト」に格納されます。

図 11–5 NIS+のディレクトリ構造

NIS+ グループの管理については、第 17 章「NIS+ グループの管理」を参照してください。

その他クラス

その他クラスは、NIS+ によって認証されたすべての NIS+ 主体のクラスです。すなわち、所有者およびグループクラスのすべてと有効な DES 資格を提示したものを加えたものです。

その他に与えられたアクセス権は、認証されたすべての主体に適用されます。

未認証クラス

未認証クラスは、正しく認証されなかったものすべてで構成されます。すなわち、有効な DES 資格を提示しなかったものです。

承認クラスと NIS+ オブジェクトの階層

NIS+ オブジェクトと承認クラスには各レベルに適用される階層があります。標準的な NIS+ ディレクトリ階層のデフォルトは次のようになります。

• 「ディレクトリレベル」。各 NIS+ ドメインには groups_dir と org_dir という 2 つの NIS+ ディレクトリオブジェクトがあります。各 groups_dir ディレクトリオブジェクトはさまざまなグループで構成されます。各 org_dir ディレクトリオブジェクトにはさまざまなテーブルが含まれます。

• 「グループレベルまたはテーブルレベル」。グループは個々のエントリやグループで構成されます。テーブルには列と個々のエントリが含まれます。

• 「列レベル」。テーブルは 1 つ以上の列で構成されます。

• 「エントリ (行) レベル」。グループもしくはテーブルは 1 つ以上のエントリを持ちます。

各レベルには 4 つの承認クラスが適用されます。ディレクトリオブジェクトはそれ自身の所有者とグループを持ちます。ディレクトリ内の個々のテーブルは、ディレクトリの所有者およびグループと異なる所有者およびグループを持ちます。テーブル内では、1 エントリ (行) が個々の所有者もしくはグループを持ちます。この所有者もしくはグループは、テーブル全体の所有者やグループとは異なり、またオブジェクト全体の所有者やグループとも異なります。テーブル内の個々の列は、テーブル全体と同じ所有者やグループを持ちます。

NIS+ アクセス権

NIS+ オブジェクトのオブジェクト定義には、オブジェクトのアクセス権を指定します (オブジェクト定義は、niscat -o コマンドで確認できます)。

NIS+ オブジェクトは、UNIX ファイルが UNIX ユーザーに対するアクセス権を指定するのと同じ方法で、NIS+ 主体に対するアクセス権を指定します。アクセス権は、NIS+ 主体が NIS+ オブジェクトについて実行することが許されている動作の種類を表します。

NIS+ の動作はオブジェクトの種類によって異なりますが、読み取り、変更、作成、および削除の 4 つのクラスに分類されます。

• 「読み取り」。オブジェクトの読み取り権を持った主体はオブジェクトの内容を読み取ることができます。

• 「変更」。オブジェクトに対する変更権を持った主体がオブジェクトの内容を変更できます。

• 「削除」。オブジェクトの削除権を持った主体はオブジェクトの内容を削除することができます。

• 「作成」。上位レベルのオブジェクトに対する作成権を持った主体が、そのレベルの下位に新規のオブジェクトを作成できます。すなわち、NIS+ ディレクトリオブジェクトの作成権を持っていれば、そのディレクトリ内に新しいテーブルを作成できます。NIS+ テーブルの作成権を持っていれば、そのテーブル内に新しい列とエントリを作成できます。

NIS+ クライアントから NIS+ サーバーへのすべての通信は、実際には特定の NIS+ オブジェクトに対してこれらの動作のうちの 1 つを実行してほしいという要求です。たとえば、NIS+ 主体が他のマシンの IP アドレスを要求した場合、実際には、この種の情報を格納している hosts テーブルオブジェクトへの読み取り権を要求しています。主体が NIS+ 名前空間にディレクトリを追加するようサーバーに要求した場合、実際には、そのディレクトリの親オブジェクトに対して「変更」権を要求しています。

これらの権限は論理的には、ディレクトリ、テーブル、列とエントリのように下位に展開するものであることに注意してください。たとえば、新規にテーブルを作成するには、そのテーブルを格納する NIS+ ディレクトリオブジェクトに対する作成権が必要です。そのテーブルを作成した場合、そのデフォルト所有者になります。所有者として、自分自身にそのテーブルに対する作成権を与え、テーブルに新規のエントリを作成できます。テーブル内に新規のエントリを作成した場合、それらのエントリの所有者になります。所有者として、他のユーザーにテーブルレベルの作成権を与えることもできます。たとえば、テーブルのグループクラスにテーブルレベルの作成権を与えることができます。その場合、テーブルのグループのすべてのメンバーがテーブル内に新規のエントリを作成できます。新規のテーブルエントリを作成したグループの個々のメンバーは、そのエントリのデフォルト所有者になります。

NIS+ 管理者

NIS+管理者は、NIS+オブジェクトに対して「管理者権限」を持つユーザです。管理者権限は、オブジェクトに対する作成および削除権限で構成されます。また、オブジェクトによっては変更権限が含まれる場合もあります (NIS+ アクセス権については、NIS+ アクセス権 を参照してください)。

NIS+ オブジェクトを作成するものは誰でもそのオブジェクトに対する初期アクセス権を持つと設定します。もし作成者が管理権限をオブジェクトの所有者に限った場合 (初期状態では作成者) は、所有者だけがそのオブジェクトに対する管理権限を持ちます。一方、作成者が管理権限をオブジェクトのグループに与えた場合は、グループの全員がそのオブジェクトに対して管理権限を持つことになります。

あるオブジェクトに対して管理権限を持つものは誰でもそのオブジェクトの NIS+ 管理者とみなされます。

すなわち、NIS+ ソフトウェアは NIS+ 管理者を 1 人にしようとするものではないということです。

理論的には、管理権限をその他クラスに与えることも、未認証クラスに与えることもでき、ソフトウェア上では可能です。しかし、管理権限をグループクラス以上に広げて与えてしまうと、NIS+ のセキュリティを実質的に無効にしてしまいます。もし管理権限をその他クラスや未認証クラスに与えた場合、NIS+ のセキュリティは保証されません。

NIS+ のパスワード、資格、およびコマンド

管理者のパスワード、資格、および鍵には次のコマンドを使用します。各コマンドの説明についてはマニュアルを参照してください。

• chkey - 主体の Secure RPC 鍵の組み合わせを変更します。必要のない場合は chkey を使わずに、passwd を使ってください。詳細については、NIS+ 主体の鍵の変更 を参照してください。

• keylogin - keyserv を使って主体の非公開鍵を復号化し格納します。

• keylogout - 格納されている非公開鍵を keyserv から削除します。

• keyserv - サーバーに非公開暗号鍵を格納させます。詳細については、キーログインを参照してください。

• newkey - 公開鍵データベースに新規の鍵の組み合わせを作成します。

• nisaddcred - NIS+ 主体に資格 (credential) を作成します。詳細については、資格情報の作成および、NIS+ 資格情報の管理を参照してください。

• nisauthconf - Diffie - Hellman 鍵の長さの表示あるいは設定を行います。

• nisupdkeys - ディレクトリオブジェクト内の公開鍵を更新します。詳細については、公開鍵の更新を参照してください。

• passwd - 主体のパスワードを変更し管理します。詳細については、第 16 章「パスワードの管理」を参照してください。

第 12 章 NIS+ 資格の管理

この章では、NIS+ 資格とその管理方法について説明します。

NIS+ セキュリティタスクには、Solstice AdminSuite ツールがあればより簡単に実行できるものがあります。

NIS+ は、将来のリリースでサポートされない可能性があります。NIS+ から LDAP への移行支援ツールは、Solaris 9 オペレーティング環境で使用できます (『Solaris のシステム管理 (ネーミングとディレクトリサービス : DNS、NIS、LDAP 編)』を参照)。詳細については、http://www.sun.com/directory/nisplus/transition.html を参照してください。

NIS+ 資格について

NIS+ 資格は、NIS+ のユーザーを識別するために使用します。この章では、NIS+ セキュリティシステム全体と、特にシステムで資格が果たす役割について、十分理解しているユーザーを想定しています。

これらのタスクを実行するのに使われるコマンドの構文、オプションなどの詳細については、NIS+ のマニュアルを参照してください。

この章の DES 資格の説明は、192 ビット Diffie - Hellmaun DES 資格に適用することができます。これらは似てはいますが、その他の鍵の長さを使用した認証は細部では異なっています。コマンド行インタフェースを使用して鍵を操作するときは、その違いはユーザーにもシステム管理者にも意識されることはありません。指定した鍵の長さの表示や設定は nisauthconf(1M) を使って行います。

資格の機能

この章では、NIS+ のコマンド一式を使用してクライアント情報を作成する方法について説明します。

資格および認証システムは他人になりすますのを防ぐシステムです。あるマシンの root 権限で su コマンドを使って、ログインしていないもしくは別のマシンにログインしている第 2 のユーザーになりすまし、第 2 のユーザーの NIS+ アクセス権を使用して NIS+ オブジェクトにアクセスすることを防ぎます。

NIS+ には、他人のユーザーログインパスワードを知っている者が、そのユーザーになりすましてユーザー ID と NIS+ アクセス権を使用することを妨ぐことはできません。また root 権限を持つユーザーが「同一」マシンにログインしている別のユーザーになりすますのを防ぐこともできません。

資格と資格情報

DES 資格をどのように作成しそれがどのように機能するのかを理解するには、実際の資格と、資格を作成しチェックするのに使われる情報とを区別する必要があります。

• 「資格情報」。DES 資格を作成するのに使われるデータであり、サーバーが資格をチェックするのに使われる

• 「DES 資格」。主体を認証するために、主体からサーバーへ渡される一連の数字。主体が NIS+ 要求を行うたびに作成されチェックされる。DES 資格については、DES 資格の詳細を参照してください。

認証コンポーネント

資格および認証プロセスを機能させるには、次の要素が必要です。

• 「主体の DES 資格情報」。この情報は各主体に NIS+ 管理者が最初に作成します。この情報は主体のホームドメインの cred テーブルに格納されます。主体の DES 資格情報は次のもので構成されます。

  • 「主体名」。ユーザーの完全ログイン ID もしくはマシンの完全ホスト名

  • 「主体の Secure RPC ネット名」。各主体は固有の Secure RPC ネット名を持っています (Secure RPCネット名の詳細は、DES 資格の Secure RPC ネット名を参照)(Secure RPC ネット名の詳細については、DES 資格の Secure RPC ネット名を参照)。

  • 「主体の公開鍵」

  • 「主体の非公開暗号鍵」

• 「主体の LOCAL 資格」

• 「サーバーの公開鍵」。各ディレクトリオブジェクトには、当該ドメインのすべてのサーバーの公開鍵の複製が格納されています。cred テーブルには各サーバーの DES 資格も格納されていることに注意してください。

• 「主体の公開鍵のキーサーバーの複製」。キーサーバーは、その時点でログインしている主体 (ユーザーまたはマシン) の公開鍵の複製を持っています。

主体の認証方法

承認プロセスには 3 つのフェーズがあります。

• 「準備フェーズ」。NIS+ 管理機能がユーザーのログインに先立って行う設定動作。たとえば、ユーザーのための資格情報を作成

• 「ログインフェーズ」。ユーザーがログインした時にシステムが行う動作

• 「要求フェーズ」。NIS+ 主体が、NIS+ サービスもしくは NIS+ オブジェクトに要求を発する時にソフトウェアが行う動作

これら 3 つのフェーズの詳細については、次の項目を参照してください。

資格準備フェーズ

ユーザーの資格情報は、nisclient スクリプトを使用すれば最も簡単に作成できます。この節では、NIS+ のコマンド一式を使用してクライアント情報を作成する方法について説明します。

NIS+ 主体がログインする前に、NIS+ 管理者は当該主体 (ユーザーまたはマシン) のための資格情報を作成する必要があります。管理者は次のようにする必要があります。

• 各主体の公開鍵と非公開暗号鍵を作成します。これらの鍵は主体のホームドメインの cred テーブルに格納されます。これは nisaddcred コマンドを使って行われます (NIS+ 主体の資格情報を作成する方法を参照)。

• サーバーの公開鍵を作成します (公開鍵の更新 を参照)。

ログインフェーズ - 詳細

主体がシステムにログインする時、次のステップが自動的に実行されます。

1. 主体のために keylogin プログラムが起動します。keylogin プログラムは cred テーブルから主体の非公開暗号鍵を取得し、主体のログインパスワードを使って復号化します。

   ---

   注 –

   主体のログインパスワードが Secure RPC パスワードと異なる場合、keylogin コマンドはパスワードを復号化できず、「cannot decrypt」などのエラーとなるか、メッセージなしでコマンドが失敗します。この問題については、Secure RPC パスワードとログインパスワードの問題を参照してください。

   ---

2. 復号化された主体の非公開暗号鍵は、要求フェーズでの利用に備えてキーサーバーに渡され格納されます。

   ---

   注 –

   復号化された非公開暗号鍵はユーザーが keylogout コマンドを実行するまでキーサーバーに格納されます。ユーザーが keylogout を実行せずにログアウトした (またはログアウトせずに帰宅してしまった) 場合には、復号化された非公開鍵がサーバーに格納されたままになっています。もしユーザーマシンの root 権限を持った誰かがユーザーログイン ID に su コマンドを使った場合、その人間はユーザーの復号化された非公開鍵を使用でき、ユーザーのアクセス承認を使って NIS+ オブジェクトにアクセスできることになります。このような事態を避けるため、ユーザーが業務を終了する時は確実に keylogout コマンドを使ってログアウトするように注意する必要があります。同様にもしユーザーがログオフする場合は、業務に戻る時はログバックするだけで良いのです。もしユーザーが確実にログオフしなかった場合、業務に戻る時に確実に keylogin を実行する必要があります。

   ---

要求フェーズ - 詳細説明

NIS+ 主体の要求が NIS+ オブジェクトにアクセスするつど、その主体を認証するために NIS+ ソフトウェアは複数段階のプロセスを実行します。

1. NIS+ はオブジェクトドメインの cred テーブルをチェックします。

   • 主体が LOCAL 資格情報を持っている場合、NIS+ では LOCAL 資格に含まれるドメイン情報を使用して主体のホームドメイン の cred 資格を検索し、必要な情報を取得します。

   • もし主体が資格情報を持っていなかった場合、残りのプロセスは実行されず、主体の承認アクセスクラスには未認証クラスが与えられます。

2. ユーザーのホームドメインの cred テーブルから、NIS+ がユーザーの DES 資格を取得します。ユーザーパスワードを使って非公開暗号鍵が復号化され、キーサーバーに格納されます。

3. NIS+ が NIS+ ディレクトリオブジェクトからサーバーの公開鍵を獲得します。

4. キーサーバーが、主体の復号化された非公開鍵とオブジェクトのサーバー (オブジェクトが格納されているサーバー) の公開鍵を使って、「共通鍵」を作成します。

5. 共通鍵を使用して、暗号化された「DES 鍵」が作成されます。これは、Secure RPC が乱数を発生させ、これを共通鍵を使って暗号化することで行われます。このため、DES 鍵は「乱数鍵」もしくは「乱数 DES 鍵」として参照される場合があります。

6. NIS+ が主体のサーバーの時刻情報に基づいてタイムスタンプ (DES 鍵を使って暗号化される) を作成します。

7. NIS+ が 15 秒のタイムウィンドウ (DES 鍵を使って暗号化される) を作成します。この「ウィンドウ」はタイムスタンプとサーバーの内部クロックとの間で許容される最長時間になります。

8. NIS+ が主体の DES 資格を作成します。これは次のもので構成されます。

   • 主体の cred テーブルに基づく Secure RPC ネット名 (unix.identifier@domain)

   • キーサーバーから得た暗号化された主体の DES 鍵

   • 暗号化されたタイムスタンプ

   • 暗号化されたタイムウィンドウ

9. NIS+ が NIS+ オブジェクトの格納されているサーバーに次の情報を渡します。

   • アクセス要求

   • 主体の DES 資格

   • ウィンドウ判定子 (暗号化済)。ウィンドウ判定子は暗号化されたウィンドウに 1 を加えたもの

10. オブジェクトのサーバーがこの情報を受信します。

11. オブジェクトのサーバーが、資格の中の Secure RPC ネット名の一部を使って、主体のホームドメインにある cred テーブル内にある主体の公開鍵をチェックします。

12. サーバーが主体の公開鍵とサーバーの非公開鍵を使ってもう一度共通鍵を作成します。この共通鍵は主体の非公開鍵とサーバーの公開鍵を使って作成されている共通鍵と一致する必要があります。

13. 共通鍵を使って、主体の資格の一部として受信している DES 鍵を暗号化します。

14. サーバーが、新しく復号化した DES 鍵を使って主体のタイムスタンプを復号化し、ウィンドウ判定子を使ってそれをチェックします。

15. サーバーが、復号化しチェックしたタイムスタンプと自分の内部時計とを比較し、次のプロセスを実行します。

    1. サーバーとの時間差がウィンドウ許容値を越えていた場合、要求は拒否され、プロセスが中止されて、エラーメッセージが表示されます。たとえば、タイムスタンプが 9:00 am であり、ウィンドウが 1 分であったとします。もしその要求をサーバーが受信して復号化したのが 9:01 am であれば、その要求は拒否されます。

    2. タイムスタンプがウィンドウ許容値内である場合、サーバーは主体から前に受信した要求のタイムスタンプよりも大きいかチェックします。これによって、NIS+ 要求を正しい順序で処理しているか確認できます。

       • 順序誤りの要求はエラーメッセージとともに拒否されます。たとえば、タイムスタンプが 9:00 am でありその主体から最後に受信した要求のタイムスタンプが 9:02 am だった場合、その要求は拒否されます。

       • 最後に受信した要求と同じタイムスタンプであった場合もエラーメッセージが表示されて拒否されます。これによって、要求を 2 度処理することはなくなります。たとえば、タイムスタンプが 9:00 am であり最後にその主体から受信した要求のタイムスタンプも 9:00 am だった場合、この要求は拒否されます。

16. タイムスタンプがウィンドウ許容値内であり、その主体からの最後の要求よりも大きかった場合に、サーバーはその要求を受け入れます。

17. サーバーは次に、要求をコンパイルし、タイムスタンプをその主体から受信した最後のものとして格納し、要求に基づいて動作します。

18. 要求に対する応答としてサーバーから受信した情報が信頼できるサーバーからのものであるかを主体が確認できるようにするため、サーバーは主体の DES 鍵を使ってタイムスタンプを暗号化し、データとともに主体に送り返します。

19. 主体側では、主体の DES 鍵を使って送り返されたタイムスタンプを復号化します。

    • 復号化が成功した場合は、サーバーからの情報を要求者へ戻します。

    • 何らかの理由で復号化に失敗した場合は、エラーメッセージが表示されます。

DES 資格の詳細

DES 資格は次の内容で構成されます。

• 主体の「Secure RPC ネット名」。DES 資格の Secure RPC ネット名を参照

• 「確認 (verification)」フィールド。DES 資格確認フィールドを参照

DES 資格の Secure RPC ネット名

• 「Secure RPC ネット名」。資格のこの部分は NIS+ の主体を特定するのに使用します。Secure RPC ネット名はすべて次の 3 つの要素で構成されます。

  • 「接頭辞」。接頭辞は常に unix になります。

  • 「識別子」。主体がクライアントユーザーの場合、ID フィールドはユーザーの UID です。主体がクライアントマシンの場合、ID フィールドはマシンのホスト名です。

  • 「ドメイン名」。主体の DES 資格を含んでいるドメイン名がドメイン名になります (主体のホームドメイン)。

NIS+ 主体名は常にドット (.) で終わりますが、Secure RPC ネット名はドット (.) で終わらないことに注意してください。

DES 資格確認フィールド

確認フィールドは資格を確かめるために使用するフィールドです。cred テーブルに格納された資格情報に基づいて作成されます。

確認フィールドの構成は次のとおりです。

• 主体の非公開鍵と NIS+ サーバーの公開鍵に基づく、暗号化された主体の DES 鍵 (要求フェーズ - 詳細説明参照)

• 暗号化されたタイムスタンプ

• タイムウィンドウ

DES 資格の作成方法

DES 資格を作成するには、keylogin コマンドを実行する必要がありますが、これは主体が資格を作成する「前」に実行します。keylogin コマンド (単に「keylogin」とする場合が多い) は、NIS+ 主体がログインする時に自動的に実行されます。図 12–2 を参照してください。

主体のログインパスワードが Secure RPC パスワードと異なる場合は、keylogin コマンドは成功しないことに注意してください。詳しくは、Secure RPC パスワードとログインパスワードの問題を参照してください。

keylogin コマンドの目的は、主体が自身の非公開鍵にアクセスできるようにすることにあります。keylogin コマンドを実行すると、cred テーブルから主体の非公開鍵を取り込み (fetch)、主体の Secure RPC パスワード (非公開鍵は主体の「Secure RPC パスワード」を使って最初に暗号化される) を使ってそれを復号化し、将来の NIS+ 要求に備えてキーサーバーに格納します。

図 12–1 keylogin コマンドで主体の非公開鍵を作成

主体が DES 資格を作成するには、主体が要求を送る相手サーバーの公開鍵が必要です。この情報は主体のディレクトリオブジェクトに格納されています。主体がこの情報を獲得すれば資格の確認フィールドを作成できます。

まず、主体が種々の資格情報を暗号化するためにランダム DES 鍵を作成します。主体は自分の非公開鍵 (キーサーバーに格納されている) とサーバーの公開鍵を使って、ランダム DES 鍵を作成し暗号化するための共通鍵を作成します。次に DES 鍵で暗号化したタイムスタンプを作成し、それを確認フィールドで他の資格関連情報の中に入れます。

図 12–2 DES 資格の作成

Secure RPC パスワードとログインパスワードの問題

主体のログインパスワードと Secure RPC パスワードが一致しないと、ログイン時に keylogin はパスワードを復号化できません。keylogin はデフォルトで主体のログインパスワードを使用することになっていて、また非公開鍵は主体の Secure RPC パスワードを使用して暗号化されているからです。

この場合でも主体がシステムにログインすることは可能ですが、キーサーバーがそのユーザーのための復号化された非公開鍵を持っていませんから、未認証クラスが与えられることになります。ほとんどの NIS+ 環境において、未認証クラスにはほとんどの NIS+ オブジェクトに対する作成権、削除権、変更権を与えないように設定されますから、結果としてユーザーが NIS+ オブジェクトにアクセスしても「アクセス権拒否」などのエラーになります。

「ネットワークパスワード」を「Secure RPC パスワード」の同意語として使用する場合があります。ネットワークパスワードの入力を求められたら Secure RPC パスワードを入力します。

別の承認クラスを得るには、この場合 keylogin プログラムを実行し、パスワード入力のプロンプトに主体の Secure RPC パスワードを入力する必要があります (キーログインの項を参照)。

しかし keylogin を実行しても、現在のログインセッション以外には無効で、一時的な解決にしかなりません。キーサーバーはこの方法によって、復号化された形でユーザーの非公開鍵を持つようになるのですが、ユーザーの cred テーブル中の非公開鍵が Secure RPC パスワード (ユーザーのログインパスワードとは異なっている) を使用して暗号化されているという点に変わりはないからです。次にログインした時には同じ問題が発生します。この問題を永久的に解決するには、ユーザーの Secure RPC パスワードではなくユーザーログイン ID を使って、cred テーブルにある非公開鍵を再度暗号化する必要があります。このためにはユーザーが chkey -p コマンドを実行します (NIS+ 主体の鍵の変更の項を参照)。

Secure RPC パスワードがログインパスワードと異なる問題を永久的に解決するには、ユーザー (またはユーザーに対応している管理者) が次の手順を実行してください。

1. ログインパスワードを使用してログインします。

2. keylogin プログラムを実行して、キーサーバーに保存される非公開鍵を一時的に復号し、一時的な NIS+ アクセス権を得ます。

3. chkey -p を実行し、cred テーブル内の暗号化された非公開鍵を、ユーザーログインパスワードに基づいたものに永久的に変更します。

4. ログインセッションの終了の準備ができたら、システムをログオフする前に keylogout を実行します。

5. logout コマンドを使って、システムからログオフします。

キャッシュに保存された公開鍵の問題

正しい資格を作成し、正しいアクセス権を与えられたのに、主体の要求が拒否される場合があります。この原因のほとんどは、サーバーの公開鍵が古いバージョンだった時に作られた、古いオブジェクトが残っていることにあります。この問題は通常次の方法で解決します。

• アクセスしようとしているドメインで、nisupdkeys を実行します (nisupdkeys コマンドの使用法については nisupdkeys コマンドを、この種の問題の解決方法については 資格情報が古いを参照)。

• マシン上で nis_cachemgr を終了します。次に /var/nis/NIS_SHARED_DIRCACHE を削除してから、nis_cachemgr を再起動します。

資格に関連する情報が格納されている場所

この節では、NIS+ 名前空間のどこに資格関連情報が格納されるのかを説明します。

公開鍵など、資格に関する情報は、名前空間内の様々な場所に保存されています。NIS+ は、情報を格納しているオブジェクトの生存期間に応じてこの情報を定期的に更新しますが、場合によっては、更新の間に同期が失われ、システムが正常に動作しなくなることがあります。その結果、システムが正常に動作しなくなることがあります。資格関連の情報を格納するすべてのオブジェクト、テーブル、ファイル、および再設定方法を、表 12–2 に示します。

cred テーブルの詳細

主体の資格情報は「cred テーブル」に格納されています。cred テーブルは NIS+ が標準で持つ 16 のテーブルの 1 つです。cred テーブルはドメインにつき１つ存在し、ドメインに属するクライアントマシンおよびマシンにログインできるユーザー (つまり、ドメイン中の主体) の資格に関する情報を持っています。cred テーブルはドメイン中の org_dir サブディレクトリにあります。

cred テーブルをリンクしないでください。各 org_dir ディレクトリはそれ自身の cred テーブルを持つ必要があります。他の org_dir の cred テーブルとのリンクも使用しません。

ドメイン内のすべてのマシンにログインできるユーザーすべての LOCAL 資格情報が cred テーブルに格納されています。cred テーブルにはまた、ホームドメインとしてとしてドメインを持っているユーザーの DES 資格情報も格納されています。

cred テーブルの内容は niscat コマンドを使って見ることができます。方法については、第 19 章「NIS+ テーブルの管理」を参照してください。

表 12–3 に示すように、cred テーブルには 5 つの列があります。

2 列目の認証の種類で他の 4 列の値の種類を判定します。

• 「LOCAL」。認証タイプが LOCAL の場合、残りの列には主体ユーザー名、UID、GID が入ります (最後の列は空白)。

• 「DES」。認証タイプが DES の場合、残りの列には主体名、Secure RPC ネット名、公開鍵、暗号化非公開鍵が入ります。これらの鍵は他の情報と組み合わされ、DES 資格の暗号化および復号化に使用されます。

資格情報の作成

資格情報を作成したり管理したりするには次の方法があります。

• Solstice AdminSuite ツールを使用します。このツールを使用すると容易に資格を管理できます。個々の資格を管理する場合はこのツールの使用を推奨します。

• nisclient スクリプトを使用します。1 つの主体の資格を容易に作成し変更できます。便利な方法なので、個々の資格を管理する方法として推奨します。本書では nisclient スクリプトの使用方法を手順ごとに示しながら、資格情報を作成していきます。

• nispopulate スクリプトを使用します。これはすでに NIS+ マップまたは /etc ファイルに資格情報を格納してある１つ以上の主体の資格を作成したり、変更したりする便利な方法です。NIS+ 主体グループの資格を管理する方法として推奨します。本書では nispopulate スクリプトの使用方法を手順ごとに示しながら、資格情報を作成していきます。NIS+ テーブルの生成 (populate)を参照してください。

• nisaddcred コマンドを使用します。次の節では、nisaddcred コマンドを使って資格と資格情報を作成する方法を説明します。

nisaddcred コマンド

nisaddcred コマンドは資格情報を作成するコマンドです。

nispopulate スクリプトと nisclient スクリプトを使って資格情報を作成することもできます。これらスクリプトは nisaddcred コマンドよりも容易に使えて効果的なものです。ネットワークが特別な機能を必要とするのでなければ、これらのスクリプトを使用してください。

nisaddcred コマンドは、LOCAL 資格と DES 資格情報の作成、更新、および削除を行います。資格情報を作成するには、適切なドメインの cred テーブルに対する作成権が必要です。資格を更新するには、cred テーブル、または少なくとも cred テーブルの特定エントリに対する変更権が必要です。資格を削除するには、cred テーブル、または cred テーブルのエントリに対する削除権が必要です。

• 別の NIS+ 主体資格を作成または更新する場合

  LOCAL 資格情報

  nisaddcred -p uid -P principal-name local

  DES 資格情報

  nisaddcred -p rpc-netname -P principal-name des

• 自分の資格を更新する場合

  LOCAL 資格情報

  nisaddcred -local

  DES 資格

  nisaddcred des

• 資格を削除する場合

  nisaddcred -r principal-name

関連コマンド

この章で説明する nisaddcred コマンドに加えて、資格に関して有用な情報を提供するコマンドが 2 つ用意されています。

nisaddcred コマンドを使って資格情報を作成する方法

nisaddcred コマンドを使用して、LOCAL および DES 資格情報を作成します。

LOCAL 資格情報

LOCAL 資格情報を作成するために nisaddcred コマンドを使用すると、nisaddcred コマンドは主体のログインレコードから主体ユーザーの UID (および GID) を抽出し、ドメインの cred テーブルに置きます。

DES 資格情報

DES 資格情報を作成するのに使用した場合、nisaddcred は 2 つのプロセスを実行します。

1. 主体の Secure RPC ネット名を作成します。Secure RPC ネット名は、パスワードレコードから取得した主体のユーザー ID 番号とドメイン名 (たとえば、unix.1050@doc.com) を結合して作成されます。

2. 主体の非公開鍵と公開鍵を生成します。

nisaddcred が非公開鍵を暗号化するには、Secure RPC パスワードが必要です。nisaddcred コマンドを引数 -des で呼び出すと、主体の Secure RPC パスワードの入力を要求されます。通常このパスワードは主体のログインパスワードと同じです(異なる場合は、Secure RPC パスワードとログインパスワードの問題に示す手順に従ってさらに操作が必要となります)。

nisaddcred コマンドは 1 対の乱数 (Difie-Hellman 方式を使った 192 ビットの認証鍵) を作成します。この鍵は Difie-Hellman の鍵ペア (key-pair) または省略して単に「鍵ペア」と呼びます。

この鍵ペアの一方が「非公開鍵」であり、もう一方が「公開鍵」になります。公開鍵は cred テーブルの公開データフィールドに置かれます。非公開鍵は主体の Secure RPC パスワードで暗号化された後に非公開データに置かれます。

図 12–3 nisaddcred コマンドを使って主体の鍵を作成する方法

デフォルトでは、cred テーブルをすべての NIS+ 主体 (未認証主体であっても) が読み取ることができるので、セキュリティ上の予防措置として、主体の非公開鍵を暗号化しています。

Secure RPC ネット名と NIS+ 主体名

資格情報を作成する際、何度も主体の「RPC ネット名 (rpc-netname)」と「主体名 (principal-name)」を入力しなければなりません。どちらも独自の構文が必要です。

• 「Secure RPC ネット名」。Secure RPC ネット名は Secure RPC プロトコルで判定されるので、NIS+ のネーミング規則には従いません。

  • ユーザーの場合： unix. uid@domain

  • マシンの場合： unix .hostname@domain

  Secure RPC ネット名がユーザーを識別する場合、ユーザーの UID が必要です。Secure RPC ネット名がマシンを識別する場合、マシンのホスト名が必要です。nisaddcred コマンドに指定するときは、Secure RPC ネット名の前に -p (小文字) フラグを入力してください。

  Secure RPC ネット名は常に unix (すべて小文字) で始まりドメイン名で終わります。Secure RPC プロトコルに従うため、ドメイン名にはドットを付けません。

• 「主体名」。NIS+ 主体名は通常の NIS+ 命名規約に従いますが、常に完全指定名でなければなりません。構文は、principal.domain になります。

識別する対象がクライアントユーザーであっても、クライアントマシンであっても、主体名で始まり、その後にドットと完全なドメイン名が続き、最後はドットで終わります。資格の作成に使用する場合、常に先頭は -P (大文字) フラグで始まります。資格の削除に使用する場合、-P フラグは使用しません。

管理者のために資格情報を作成する方法

名前空間を最初に設定する場合、ドメインをサポートする管理者の資格情報を最初に作成します。管理者の資格情報を一度作成すると、他の管理者、クライアントマシン、およびクライアントユーザーの資格情報を作成できます。

自分の資格情報を作成しようとすると、堂々めぐりに陥ります。つまり、ドメインの cred テーブルに対する作成権がなければ自分の資格情報を作成できず、もし NIS+ 環境が適切に設定されていれば、資格を持つまではそのような権限を持つこともできません。この循環から抜け出さなくてはなりません。これには、次の 2 つの方法があります。

• ドメインのマスターサーバーにスーパーユーザーとしてログインしている間に、資格情報を作成する

• ダミーパスワードを使用して、他の管理者に自分の資格を作成してもらってから chkey コマンドを使用してパスワードを変更する

どちらの場合も、別の NIS+ 主体に資格情報を作成してもらうことになります。自分の資格情報を作成するには、NIS+ 主体の資格情報を作成する方法の項を参照してください。

NIS+ 主体の資格情報を作成する方法

NIS+ の資格情報はドメインの設定後いつでも作成できます。すなわち、cred テーブルがあれば作成できます。

NIS+ 主体の資格情報を作成する

• 主体のホームドメインの cred テーブルに対する作成権が必要

• サーバーは、主体の存在を認識している必要がある。この場合「サーバーが認識している」とは以下のことを意味する

  • 主体がユーザーの場合、ドメインの NIS+ passwd テーブルかサーバーの /etc/passwd ファイルのどちらかにエントリが必要

  • 主体がマシン場合、ドメインの NIS+ host テーブルかサーバーの /etc/hosts ファイルのどちらかにエントリが必要

これらの条件を満たせば、-p と -P の両方のオプション付きで nisaddcred コマンドを実行できます。

LOCAL 資格情報

nisaddcred -p uid -P principal-name local

DES 資格情報

nisaddcred -p rpc.netname -P principal-name des

次の原則に注意してください。

• 主体ユーザーの場合、LOCAL 資格と DES 資格の両方の情報を作成できます。

• 主体マシンの場合、DES 資格情報しか作成できません。

• 主体のホームドメイン (ユーザーまたはマシン) でだけ DES 資格情報を作成できます。

• ユーザーの LOCAL 資格情報はユーザーのホームドメインでも他のドメインでも作成できます。

ユーザー主体 - 例

UID が 11177 の morena という名前の NIS+ ユーザーの LOCAL および DES 資格情報を作成する例を次に示します。彼女の所属するドメインは doc.com. で、この例ではドメインの主体マシンから彼女の資格情報を入力します。

client# nisaddcred -p 11177 -P morena.doc.com. local
client# nisaddcred -p unix.11177@sales.doc.com \
   -P morena.doc.com. des
Adding key pair for unix.11177@sales.doc.com
   (morena.doc.com.).
Enter login password:

Enter login password: プロンプトに対する正しい応答は morena のログインパスワードです。 彼女のログインパスワードを知らない場合は、ダミーパスワードを使用します。ダミーパスワードは、次の例のように、後で chkey コマンドを使って変更できます。

ダミーパスワードと chkey の使い方 - 例

ユーザーのログインパスワードを知らない場合、次に説明するようにダミーパスワードを使うことができます。

表 12–5 は、ダミーパスワードを使って資格情報を作成した管理者が、chkey コマンドを使ってパスワードを変更する方法を示します。この例では、UID が 119 の eiji という名前の管理者の資格情報を作成します。eiji はルートドメインに属しているので、rootmaster という名前のルートマスターサーバーから彼の資格情報を入力します。

Retype password:
Done.

まず、通常の方法で eiji の資格情報を作成しますが、ダミーのログインパスワードを使用します。NIS+ は警告を発して、再入力を要求します。再入力を行うと、この操作は完了します。ドメインの cred テーブルには、ダミーパスワードに基づく eiji の資格情報が入っています。しかし、ドメインの passwd テーブル (または /etc/passwd ファイル) には、まだ彼のパスワードエントリが残っているので、彼はシステムにログオンできます。

次に、eiji は本当のログインパスワードを入力して、ドメインのマスターサーバーにログインします (ログイン手順では、passwd テーブルまたは /etc/passwd ファイルのパスワードをチェックするため)。そこから eiji は、まずダミーパスワードを使用して keylogin を実行し (cred テーブルをチェックするため)、chkey -p コマンドを使用して cred エントリを本当のパスワードに変更します。

別のドメインでの作成 - 例

これらの 2 つの例では、主体ユーザーのホームドメインのマスターサーバーにログインしている間に、主体ユーザーの資格情報を作成しました。しかし、適切なアクセス権がある場合、別のドメインに資格を作成できます。次の構文でドメイン名を付加するだけです。

LOCAL 資格情報

nisaddcred -p uid -P principal-name local domain-name

DES 資格情報

nisaddcred -p rpc-netname -P principal-name des domain-name 

次の例では、まず chou という名前のシステム管理者の LOCAL および DES 資格情報を、そのシステム管理者のホームドメイン (これは、たまたまルートドメイン) に作成し、次にその LOCAL 資格を doc.com ドメインに追加します。chou の UID は 11155 です。このコマンドは、ルートマスターサーバーから入力します。簡単にするため、chou の正しいログインパスワードを入力しているものとします。

rootmaster# nisaddcred -p 11155 -P chou.doc.com. local
rootmaster# nisaddcred -p unix.11155@doc.com -P chou.doc.com. des
Adding key pair for unix.11155@doc.com (chou.doc.com.).
Enter login password:
rootmaster#  nisaddcred -p 11155 -P chou.doc.com. local doc.com.

LOCAL 資格情報は、UID を NIS+ 主体名にマップします。クライアントユーザーである NIS+ 主体は、さまざまなドメインにさまざまな UID を持てますが、NIS+ 主体名は 1 つしか持てません。したがって、chou などの NIS+ 主体が自分のホームドメイン以外のドメインからログインする場合、そのドメインにパスワードエントリを持つだけではなく、そのドメインの cred テーブルに LOCAL 資格も持っていなければなりません。

マシン の場合—例

主体「マシン」の資格情報を作成する例を次に示します。このホスト名は starshine1 で、ルートドメインに所属しています。したがって、この資格はルートマスターサーバーから作成されます。この例では、ルートマスターに root としてログインしている間に資格情報を作成します。しかし、有効な資格情報と適切なアクセス権をすでに持っている場合、自分のユーザー名でログインしているときに、資格を作成できます。

rootmaster# nisaddcred -p unix.starshine1@doc.com -P \
starshine1.doc.com. des
Adding key pair for unix.starshine1@doc.com
(starshine1.doc.com.).
Enter starshine1.doc.com.'s root login password:
Retype password: 

パスワードプロンプトに対しては、主体マシンのスーパーユーザーパスワードを入力してください。もちろん、ダミーパスワードを使用することもできます。このダミーパスワードは、その主体マシンにスーパーユーザーとしてログインすれば、後で変更できます。

NIS+ 資格情報の管理

以下のいくつかの節では、nisaddcred コマンドで資格情報を管理する方法について説明します。nisaddcred で資格情報を管理するには、cred テーブルに対する作成権、変更権、読み取り権、削除権が必要です。

自分の資格情報を更新する方法

自分の資格情報を更新することは、資格を作成することよりはるかに簡単です。自分のユーザー名でログインしているときに、次のような nisaddcred コマンドを入力するだけです。

# nisaddcred des
# nisaddcred local

別のユーザーの資格情報を更新する場合は、そのユーザーの資格情報を作成するのと同じ操作を行います。

資格情報を削除する方法

nisaddcred コマンドは、主体の資格情報を削除しますが、コマンドを実行しているローカルドメインだけから削除できます。

システム全体から完全に主体を削除するには、主体のホームドメインおよび LOCAL 資格情報のあるすべてのドメインから主体の資格情報を明示的に削除しなければなりません。

資格情報を削除するには、ローカルドメインの cred テーブルへの変更権が必要です。-r オプションを使い、完全 NIS+ 主体名で主体を指定します。

# nisaddcred -r principal-name 

次の 2 つの例では、システム管理者 morena.doc.com. の LOCAL と DES の資格情報を削除します。最初の例では、システム管理者のホームドメイン (doc.com.) から両方の資格情報を削除し、2 番目の例では、sales.doc.com. ドメインから LOCAL 資格情報を削除します。 該当するドメインのマスターサーバーから、それぞれがどう入力されるかに注意してください。

rootmaster# nisaddcred -r morena.doc.com.
salesmaster#  nisaddcred -r morena.doc.com.

資格が本当に削除されたことを確かめるには、次に示すように、cred テーブルに対して nismatch を実行します。nismatch の詳細については、第 19 章「NIS+ テーブルの管理」を参照してください。

rootmaster# nismatch morena.doc.com. cred.org_dir 
salesmaster# nismatch morena.doc.com. cred.org_dir

第 13 章 NIS+ 鍵の管理

この章では、NIS+ の鍵と、鍵を管理する方法について説明します。

NIS+ セキュリティタスクには、Solstice AdminSuite ツールがあればより簡単に実行できるものがあります。

NIS+ は、将来のリリースでサポートされない可能性があります。NIS+ から LDAP への移行支援ツールは、Solaris 9 オペレーティング環境で使用できます (『Solaris のシステム管理 (ネーミングとディレクトリサービス : DNS、NIS、LDAP 編)』を参照)。詳細については、http://www.sun.com/directory/nisplus/transition.html を参照してください。

NIS+ 鍵

NIS+ 鍵は NIS+ の関連情報を暗号化するために使用します。

この章では、NIS+ セキュリティシステム全体と、特にシステムで鍵が果たす役割について、十分理解しているユーザーを想定しています (詳しくは、第 11 章「NIS+ のセキュリティの概要」を参照してください)。

NIS+ 鍵に関するコマンドとその構文やオプションについての詳しい説明は、nis+(1) のマニュアルページを参照してください。また、nisaddcred コマンドも鍵に関連のある働きをします。詳細については、 第 12 章「NIS+ 資格の管理」を参照してください。

キーログイン

主体がログインする時、パスワードの入力を求めるプロンプトが現れます。このパスワードはユーザーがセキュリティゲートをパスし、ネットワークにアクセスするために必要なものです。ログインプロセスは、ユーザーのホームドメインの cred テーブルにあるユーザーの非公開鍵を復号化しキーサーバーへ渡します。キーサーバーはその復号化された非公開鍵を使って、ユーザーが NIS+ オブジェクトにアクセスするつど、ユーザーの認証を行います。

通常は、この場合だけ主体にパスワードが要求されます。しかし、cred テーブルにある主体の非公開鍵がユーザーのログインパスワードと異なるパスワードを使用して暗号化されていると、ログインプロセスはそれを login の際にログインパスワードを使って復号化できないので、キーサーバーに復号化した非公開鍵を提供できません。(これは cred テーブル内にあるユーザーの非公開鍵が、ログインパスワードと異なる Secure-RPC パスワードを使用して暗号化された場合に多く起こります。)

「ネットワークパスワード」と「Secure-RPC パスワード」を同意語として使用する場合があります。

この問題を一時的に解決するには、ログインの後には必ず主体が keylogin コマンドを使用して、キーログインを実行する必要があります。-r フラグを使って、スーパーユーザー主体にログインし、ホストの /etc/.rootkey にスーパーユーザーの鍵を格納します。

主体ユーザーの場合

keylogin

主体マシンの場合 (一度だけ)

keylogin -r

ただし、オリジナルのパスワードを使用して確実にキーログインを実行しても、そのログインセッションにおいて一時的に問題が解決するだけです。cred テーブルの非公開鍵はユーザーのログインパスワードと異なるパスワードを用いて暗号化されたままであり、次にユーザーがログインした時に同じ問題が起こります。この問題を永久的に解決するには、chkey コマンドを使用して、非公開鍵の暗号化に使ったパスワードをユーザーのログインパスワードに変更します (NIS+ 主体の鍵の変更を参照)。

NIS+ 主体の鍵の変更

chkey コマンドは cred テーブルに格納されている NIS+ 主体の公開および非公開鍵を変更します。このコマンドは passwd テーブル内もしくは /etc/passwd ファイル内のどちらのエントリにも影響を与えません。

chkey コマンドについて

• 新規に鍵を作成し、パスワードを用いて非公開鍵を暗号化します。-p オプションをつけて実行した場合、chkey コマンドは既存の非公開鍵を新規のパスワードで再暗号化します。

• 新規に Diffie-Hellman の鍵ペアを作成し、提供されたパスワードを使用して非公開鍵を暗号化します (各主体に複数の Diffie-Hellman の鍵のペアが存在することは可能) 。しかし、ほとんどの場合ユーザーは新規の鍵ペアを求めず、既存の非公開鍵を新規のパスワードを使って再暗号化しようとします。これを行うには、-p オプション付きで chkey を実行します。

詳細については、マニュアルを参照してください。

NIS+ 環境では、どんな管理ツールまたは passwd (あるいは nispasswd) コマンドを用いてログインパスワードを変更しても、cred テーブル内の非公開鍵は新規のパスワードを使用して自動的に再暗号化されます。従って、ログインパスワードの変更後に chkey コマンドを実行する必要はありません。

chkey コマンドはキーサーバー、cred テーブル、および passwd テーブルとの関連で動作します。chkey を実行するには次のようにします。

• ホームドメインの passwd テーブルにエントリが必要です。この条件を満たさなければ、エラーメッセージが返されます。

• キーサーバーに復号化された非公開鍵のあることを確認するために、keylogin を実行する必要があります。

• cred テーブルの変更権を持っていなければなりません。この権限がない場合は「permission denied」などのエラーメッセージが返ります。

• cred テーブル内の非公開鍵の暗号化に使われた、オリジナルのパスワードを知らなくてはなりません (ほとんどの場合、これは Secure RPC パスワード)。

ログインパスワードを使って非公開鍵を再暗号化するために chkey コマンドを使用するには、最初にオリジナルのパスワードを用いて keylogin を実行し、次に 表 13–1 に示す手順で chkey -p を実行します。表 13–1 は、主体ユーザーとして keylogin と chkey を実行する方法を示しています。

Sirius% chkey -p
Updating nisplus publickey database
Updating new key for 'unix.1199@Doc.com'.

鍵の変更

次の節では、NIS+ 主体の鍵の変更方法を説明します。

サーバーの鍵を変更するときは常に、ドメイン内の全クライアントの鍵情報も更新する必要があります。方法については、クライアントの鍵情報の更新で説明します。

ルートからのルート鍵の変更

ルートマスターから (root として) ルートマスターサーバーの鍵を変更するには、表 13–2 の手順を実行します。

rootmaster# nisaddcred des

引数の意味は、それぞれ以下のとおりです。

• pid は ps -e | grep rpc.nisd コマンドで通知されるプロセス ID 番号

• dirs は更新するディレクトリオブジェクト (rootmaster によって保管されたディレクトリオブジェクト)

表 13–2 に示すプロセスの最初の手順では、nisaddcred がルートマスターの cred テーブルを更新し、/etc/.rootkey を更新し、ルートマスターのキーログインを実行します。この時点では、マスターに保管されたディレクトリオブジェクトが更新されておらず、その資格情報とルートマスターとは同期がとれていません。表 13–2 に示すその後の手順は、すべてのオブジェクトを更新するのに必要です。

サーバーの鍵を変更するときは常に、ドメイン内の全クライアントの鍵情報も更新する必要があります。方法については、クライアントの鍵情報の更新で説明します。

別のマシンからルート鍵を変更する手順

別のマシンからルートマスターの鍵を変更する場合、それに必要な NIS+ 資格とそれを行う承認を得ていなくてはなりません。

引数の意味は、それぞれ以下のとおりです。

• principal はルートマシンの Secure RPC ネット名。たとえば、unix.rootmaster@doc.com (ドットなし)

• nis-principal はルートマシンの NIS+ 主体名。たとえば、rootmaster.doc.com. (ドットで終わる)

• dirs は更新するディレクトリオブジェクト (rootmaster で保管されたディレクトリオブジェクト)

nisupdkeys を実行する場合、関連したディレクトリオブジェクトのすべてを同時に更新するように注意します。すなわち、すべてを 1 つのコマンドで行います。分割して更新すると、認証エラーになります。

サーバーの鍵を変更するときは常に、ドメイン内の全クライアントの鍵情報も更新する必要があります。方法については、クライアントの鍵情報の更新で説明します。

複製からルート複製の鍵を変更する手順

複製からルート複製の鍵を変更する手順を次に示します。

replica# nisaddcred des
replica# nisupdkeys dirs

引数の意味は、それぞれ以下のとおりです。

• dirs は更新するディレクトリオブジェクト (replica で保管されたディレクトリオブジェクト)

nisupdkeys を実行する場合、関連したディレクトリオブジェクトのすべてを同時に更新するように注意します。すなわち、すべてを 1 つのコマンドで行います。分割して更新すると、認証エラーになります。

サーバーの鍵を変更するときは常に、ドメイン内の全クライアントの鍵情報も更新する必要があります。方法については、クライアントの鍵情報の更新で説明します。

ルート以外のサーバーの鍵の変更手順

サーバーからルート以外のサーバー (マスターまたは複製) の鍵を変更する手順を以下に示します。

subreplica# nisaddcred des
subreplica# nisupdkeys parentdir dirs

引数の意味は、それぞれ以下のとおりです。

• parentdir はルート以外のサーバーの親ディレクトリ (subreplica の NIS+ サーバーを持つディレクトリ)

• dirs は更新しようとするディレクトリオブジェクト (subreplica で保管されたディレクトリオブジェクト)

nisupdkeys を実行する場合、関連したディレクトリオブジェクトのすべてを同時に更新するように注意します。すなわち、すべてを 1 つのコマンドで行います。分割して更新すると、認証エラーになります。

サーバーの鍵を変更するときは常に、ドメイン内の全クライアントの鍵情報も更新する必要があります。方法については、クライアントの鍵情報の更新で説明します。

公開鍵の更新

NIS+ サーバーの公開鍵は名前空間のあちこちに格納されています。サーバーに新規の資格情報を作成する場合、新規の鍵ペアが作成され cred テーブルに格納されます。しかし、名前空間ディレクトリオブジェクトには、まだサーバーの古い公開鍵のコピーが残っています。nisupdkeys コマンドを使用して、これらのディレクトリオブジェクトのコピーを更新します。

nisupdkeys コマンド

古い鍵ペアの保全が危うくなったり、非公開鍵の暗号化に使ったパスワードを忘れてしまったりして新規の鍵ペアを作成する場合、nisupdkeys を使用してディレクトリオブジェクト内の古い公開鍵を更新できます。

nisupdkeys コマンドで次の操作を行うことができます。

• 1 台の特定サーバーの鍵を更新する

• NIS+ ディレクトリオブジェクトをサポートしているサーバーすべての鍵を更新する

• サーバーの公開鍵をディレクトリオブジェクトから削除する

• サーバーの IP アドレスが変更された場合にそれを更新する

ただし、nisupdkeys は主体マシン上の NIS_COLD_START ファイルを更新できません。サーバーの鍵のコピーを更新するには、NIS+ クライアントが nisclient コマンドを実行しなければなりません。あるいは、NIS+ キャッシュマネージャを実行中でかつコールドスタートファイル内で１つ以上のサーバーを利用できる場合、主体はディレクトリオブジェクト上で生存期間がタイムアウトするまで待つことができます。タイムアウトが発生すると、キャッシュマネージャはコールドスタートファイルを自動的に更新します。生存期間のデフォルトは 12 時間です。

nisupdkeys を使うには、NIS+ ディレクトリオブジェクトへの変更権が必要です。

公開鍵の引数の更新と例

nisupdkeys コマンドは /usr/lib/nis にあります。nisupdkeys コマンドは次の引数を使います。nisupdkeys コマンドの詳細と引数すべてのリストは、nisupdkeys(1M) のマニュアルページを参照してください。

表 13–5 で公開鍵の更新手順の例を示します。

IP アドレスの更新

サーバーの IP アドレスを変更するかアドレスを追加する場合、NIS+ アドレス情報を更新するために nisupdkeys を実行する必要があります。

1 つ以上のサーバーの IP アドレスを更新するには、-a オプション付きで nisupdkeys を使用します。

指定されたドメインのサーバーの IP アドレスを更新。

rootmaster# nisupdkeys -a  domain

特定サーバーの IP アドレスを更新。

rootmaster# nisupdkeys -a -H  server

クライアントの鍵情報の更新

サーバーの鍵を変更するときは、常に全クライアントの鍵情報も更新する必要があります。NIS+ のサーバーは NIS+ のクライアントでもあります。そのため、あるサーバーの鍵を更新した場合は、それが NIS+ のサーバーであるか通常のクライアントであるかにかかわらず、ドメイン内にあるほかのすべてのマシンの鍵情報を更新する必要があります。

クライアントの鍵情報を更新するには、以下の 3 通りの方法があります。

• クライアント鍵情報は、クライアントの nisclient スクリプトを実行すれば、最も簡単に作成できます。

• 別の方法で個々のクライアントの鍵情報を更新するには、クライアント側で nisinit コマンドを実行します。クライアントを初期設定するを参照してください。

• ドメイン内にある全てのマシンのクライアントの鍵情報を一括で更新するには、ドメインのディレクトリオブジェクトの生存期間の値を短くします。クライアントの鍵情報を一括で更新するを参照してください。

クライアントの鍵情報を一括で更新する

サーバーの鍵を変更したあとで、ドメイン内にあるすべてのマシンのクライアントの鍵情報を一括更新できます。

1. nischttl コマンドを使用して、ドメインのディレクトリオブジェクトの生存期間 (TTL) を、すぐに満了するような小さな値にしてください。

   たとえば、sales.doc.com. ドメイン内のサーバーの鍵を変更した場合、ディレクトリの TTL 値を 1 分にするには、以下のように入力します。

   client% nischttl 60 sales.doc.com.

2. ディレクトリの TTL 値が満了すると、キャッシュマネージャはエントリを終了し、クライアントのために新しく更新された情報を入手します。

3. ディレクトリオブジェクトの TTL 値が満了したあとで、ディレクトリオブジェクトの TTL 値をデフォルト値に戻します。

   たとえば、sales.doc.com. ドメインのディレクトリオブジェクトの TTL 値を 12 時間に戻すには、以下のように入力します。

   client% nischttl 12h sales.doc.com.

   TTL 値の使用の詳細は、nischttl コマンドを参照してください。

第 14 章 拡張セキュリティ資格の管理

NIS+ は、将来のリリースでサポートされない可能性があります。NIS+ から LDAP への移行支援ツールは、Solaris 9 オペレーティング環境で使用できます (『Solaris のシステム管理 (ネーミングとディレクトリサービス : DNS、NIS、LDAP 編)』を参照)。詳細については、http://www.sun.com/directory/nisplus/transition.html を参照してください。

Diffie-Hellman 拡張鍵

NIS+ は、RPCSEC_GSS RPC(3N) セキュリティフレイバーを使用して、192 ビット Diffie-Hellman [RPC(3N) セキュリティフレイバー AUTH_DES] を超える RPC(3N) 層におけるより厳格なセキュリティを提供します。システム上で使用可能なセキュリティメカニズムのリストについては、nisauthconf(1M) コマンドを参照してください。また、これらのセキュリティメカニズムは、より厳格な暗号と各 NIS+ トランザクションの完全性を提供します。すなわち、各 NIS+ トランザクションのデータが変更されていないことが検証されます。

システム管理者は、後述のガイドラインに従って、NIS+ サーバー環境を構築する前または後に nisauthconf(1M) を実行することによって、より厳格なセキュリティメカニズムの利点を活用することができます。

新しい公開鍵ベースのセキュリティメカニズムへの移行

Diffie-Hellman 640 ビット (dh640-0) のような公開鍵暗号ファミリーのより厳格なセキュリティメカニズムを使用するには、既存の cred テーブルに各主体の新しい資格を追加することが必要です。後述の手順は、現在 Diffie-Hellman 192 ビット (RPC セキュリティフレイバー AUTH_DES) セキュリティを実行しているシステムを、Diffie-Hellman 640 ビット (RPC セキュリティフレイバー RPCSEC_GSS) セキュリティを実行するように変換する場合のものです。この移行手順は、最もよくある場合を説明したものですが、公開鍵暗号ファミリーのどれか 1 つのセキュリティメカニズムタイプから、公開鍵暗号ファミリーの別のセキュリティメカニズムに変換する場合、原理は同じです。

以下の例では、$PATH に /usr/lib/nis があることを前提にしています。

NIS+ セキュリティメカニズムの構成

NIS+ セキュリティの構成は、nisauthconf(1M) コマンドを使用して行います。nisauthconf はセキュリティメカニズムのリストを設定した順に取ります。セキュリティメカニズムは、secure_rpc(3N) で指定された 1 つまたは複数の認証フレイバーを使用することができます。des が唯一の指定されたメカニズムである場合には、NIS+ は他の NIS+ クライアントおよびサーバーの認証に AUTH_DES だけを使用します。NIS+ は、nisaddcred(1M) の場合を除いて、des より後のメカニズムは無視します。

nisauthconf [-v] [mechanism, ...]

この場合の mechanism は、システム上で使用可能な RPC セキュリティメカニズムです。使用可能なメカニズムのリストについては、nisauthconf(1M) を参照してください。メカニズムを指定しないと、現在構成されているメカニズムのリストが出力されます。

新しいセキュリティメカニズム資格の作成

NIS+ ユーザーおよびホスト主体ごとに、新しいメカニズムの資格情報を作成する必要があります。これを行うには、システムが現在のメカニズムによる認証を継続している間に、NIS+ を実行しているマシンの 1 つで nisauthconf(1M) コマンドを実行して新しい資格を作成しなければなりません。資格作成の基本の詳細については、NIS+ 主体の資格情報を作成する方法も参照してください。

新しいセキュリティメカニズム資格 - 例

des から dh640-0 へ変換します。nisauthconf がスーパーユーザーとして実行されており、nisaddcred が、ホームディレクトリの中で作成権を持っているどれかの主体として実行されていることが必要です。サーバー名は server1、ユーザーの主体名は morena です。ユーザー morena の UID は 11177 です。

client# nisauthconf des dh640-0
client% nisaddcred -P server1.doc.com. -p unix.server1@doc.com dh640-0
			(画面上には何も表示されない)
client% nisaddcred -P morena.doc.com. -p unix.11177@doc.com -ldummy-password	dh640-0
			(画面上には何も表示されない)

NIS+ ディレクトリオブジェクトへの新しい鍵の追加

すべてのサーバーの新しい資格が生成されたら、nisupdkeys(1M) を実行して、これらのサーバーが提供するすべてのディレクトリオブジェクトに新しい公開鍵を追加します。nisupdkeys(1M) コマンドを使用するには、その NIS+ ディレクトリオブジェクトに対する変更権を持っていなければなりません。詳細については、公開鍵の更新を参照してください。

これらの NIS+ ディレクトリを提供するすべてのサーバー、およびこれらのディレクトリにアクセスするすべてのクライアントは、Solaris 7 以降を実行していなければなりません。

NIS+ ディレクトリオブジェクトへの新しい公開鍵の追加 - 例

この例では、新しい公開鍵を使用してサーバーが提供しているディレクトリは、doc.com、org_dir.doc.com.、および groups_dir.doc.com. です。 更新は、マスターサーバー主体として行われます。新しいメカニズムを実行する前に、nisauthconf(1M) を使用して nisupdkeys を構成することが必要です。この例では、現在の認証メカニズムは des で、新しいメカニズムは dh640-0 です。

masterserver#	nisauthconf dh640-0 des
masterserver# nisupdkeys doc.com.
			(画面上には何も表示されない)
masterserver# nisupdkeys org_dir.doc.com.
			(画面上には何も表示されない)
masterserver# nisupdkeys groups_dir.doc.com.
			(画面上には何も表示されない)

新しいセキュリティメカニズム資格を受け入れるようにする NIS+ サーバーの構成

各サーバー上で NIS+ 認証を構成して、新旧両方の資格を受け入れるようにします。そのためには、nisauthconf(1M) および keylogin(1) を実行し、keyserv(1M) を再起動することが必要です。keylogin(1) コマンドは、各メカニズムの鍵を /etc/.rootkey に格納します。keylogin の基本の詳細は、キーログインを参照してください。

新しいセキュリティメカニズム資格を受け入れるようにする NIS+ サーバーの構成 - 例

この例では、現在の認証メカニズムは des で、新しいメカニズムは dh640-0 です。ここでは順序が重要です。クライアントおよびサーバーの NIS+ 認証では des より後のエントリは無視されます。

server# nisauthconf dh640-0 des
server# keylogin -r
			(画面上には何も表示されない)
server# /etc/reboot

新しいセキュリティメカニズム資格を使用するようにするマシンの構成

新しい資格を受け入れられるようになったので、マシンを新しい資格によって認証するように変換することができます。そのためには、nisauthconf(1M) および keylogin(1) をスーパーユーザーとして実行し、再起動します。

新しいセキュリティメカニズム資格を受け入れるようにするマシンの構成 - 例

この例では、新しいメカニズムは dh640-0 ですが、システムは、dh640-0 資格が使用可能でないか、あるいは dh640-0 による認証に成功しなかった場合には、des 資格による認証も試みます。

workstation# nisauthconf dh640-0 des
workstation#  keylogin -r
			(画面上には何も表示されない)
workstation# /etc/reboot

次の例では、新しいメカニズムは dh640-0 で、このメカニズムによる認証だけが行われます。システムを新しいメカニズムだけで認証するように構成する前に、キャッシュに書き込まれているディレクトリオブジェクトが新しいメカニズムの鍵を含むように、リフレッシュされることが必要です。これは、nisshowcache(1M) によって検証することができます。キャッシュに書き込まれているディレクトリオブジェクトがタイムアウトしてリフレッシュされるのを待つ代わりとして、次の方法があります。nis_cachemgr(1M) を終了し、続いて nisinit(1M) を使用して新しい NIS_COLD_START を構築し、続いて niscachemgr(1M) を再起動します。

ディレクトリオブジェクトの手動によるリフレッシュ - 例

ディレクトリオブジェクトを手動でリフレッシュするには、次のようにします。

# pkill -u 0 nis_cachemgr
# nisinit -cH masterserver
# niscachemgr -i

マシン主体およびこのマシンのすべてのユーザーが cred テーブルの中に dh640-0 資格を持っていなければ、dh640-0 だけで認証を行うようにシステムを構成することはできません。

workstation# nisauthconf dh640-0
workstation#  keylogin -r
			(画面上には何も表示されない)
workstation# /etc/reboot

新しい資格を保護するパスワードの変更

ダミーパスワードを持った新しい資格を与えられた各ユーザーは、chkey(1) を実行してログインパスワードに変換することが必要です。詳細については、NIS+ 主体の鍵の変更を参照してください。

新しい資格を保護するパスワードの変更 - 例

chkey(1) を実行してログインパスワードに変換します。

# chkey -p
			(画面上には何も表示されない)

新しいセキュリティメカニズム資格だけを受け入れるようにするサーバーの構成

低グレードのセキュリティメカニズムから高グレードのものに変換する場合には、新しい高グレードのセキュリティメカニズムタイプの資格だけを受け入れるように NIS+ サーバーを構成することによって、最大限のセキュリティが達成されます。新旧両方のメカニズムによって認証を行うようにサーバーを構成した後で、変換します。

新しいメカニズムだけを使用して認証を行うようにシステムを構成する前に、キャッシュに書き込まれているディレクトリオブジェクトをリフレッシュして、新しいメカニズムの鍵を含むようにし、nisshowcache(1M) を使用してこれを検証します。

新しいセキュリティメカニズム資格だけを受け入れるようにするサーバーの構成 - 例

各 NIS+ サーバー上で nisauthconf(1M) を実行し、再起動します。この例では、NIS+ サーバーは dh640-0 資格の認証だけを受け入れるように構成されます。

server#  nisauthconf dh640-0
server# /etc/reboot

この段階で、オプションで、ディレクトリオブジェクトを更新して、古い公開鍵を削除できます。これはマスターサーバーから行う必要があり、新しいセキュリティメカニズムだけを使用して認証を行うサーバーが管理するディレクトリごとに一度、nisupdkeys(1M) を実行しなければなりません。この例では、更新されるディレクトリは、doc.com、org_dir.doc.com.、および groups_dir.doc.com. です。

masterserver#	nisupdkeys doc.com.
			(画面上には何も表示されない)
masterserver#  nisupdkeys org_dir.doc.com.
			(画面上には何も表示されない)
masterserver#	nisupdkeys groups_dir.doc.com.

cred テーブルからの古い資格の削除

必要に応じて、cred テーブルから古いセキュリティメカニズムの資格を削除できます。そのためには、ローカルドメインの cred テーブルに対する変更権が必要です。詳細は、「資格情報の削除」の項を参照してください。

cred テーブルからの古い資格の削除 - 例

この例では、主体 morena.doc.com が自分の des 資格を cred テーブルから削除します。

master# nisaddcred -r morena.doc.com. dh192-0

第 15 章 NIS+ のアクセス権の管理

この章では、NIS+ アクセス権とその管理方法について説明します。

NIS+ セキュリティタスクには、Solstice AdminSuite ツールがあればより簡単に実行できるものがあります。

NIS+ は、将来のリリースでサポートされない可能性があります。NIS+ から LDAP への移行支援ツールは、Solaris 9 オペレーティング環境で使用できます (『Solaris のシステム管理 (ネーミングとディレクトリサービス : DNS、NIS、LDAP 編)』を参照)。詳細については、http://www.sun.com/directory/nisplus/transition.html を参照してください。

NIS+ のアクセス権について

NIS+ アクセス権によって、NIS+ ユーザーが実行できる操作とアクセス可能な情報が決定されます。この章では、NIS+ セキュリティシステムとそのアクセス権について、十分に理解していることを前提としています。NIS+ セキュリティシステムについては、第 11 章「NIS+ のセキュリティの概要」を参照してください。

NIS+ アクセス関連のコマンドとその構文、オプションについては、nis+(1) のマニュアルページを参照してください。

承認およびアクセス権について

NIS+ 名前空間のセキュリティは、承認、アクセス権、および NIS+ 資格と認証の相互作用によって確保されています。これらの詳細については、NIS+ の承認とアクセス - 紹介を参照してください。

承認クラス - 復習

承認クラスに説明があるように、NIS+ のアクセス権は各クラスに与えられるものです。4 つの NIS+ クラスが用意されています。

• 「所有者」。所有者クラスは 1 つの NIS+ 主体です。デフォルトではオブジェクトの所有者は、オブジェクトを作成した主体になります。しかし、オブジェクトの所有者は所有権を別の主体に譲ることで所有者を変更できます。

• 「グループ」。グループクラスは 1 つ以上の NIS+ 主体の集まりです。1 つの NIS+ オブジェクトは 1 つだけの NIS+ グループを持つことができます。

• 「その他」。その他クラスには、NIS+ に認証された NIS+ 主体のすべて (すべての所有者クラスとグループクラス、および有効な DES 資格を提示したものすべて) が含まれます。

• 「未認証」。未認証クラスは、適切な認証を受けられなかったものすべてで構成されます。すなわち、有効な DES 資格を提示できなかったすべてのものです。

アクセス権 - 復習

NIS+ アクセス権で詳述したように、NIS+ には 4 種類のアクセス権があります。

• 「読み取り」。オブジェクトに対する読み取り権を持った主体がオブジェクトの内容を読み取れます。

• 「変更」。 オブジェクトに対する変更権を持った主体がオブジェクトの内容を変更できます。

• 「削除」。オブジェクトに対する削除権を持った主体がオブジェクトを削除できます。

• 「作成」。 上位レベルのオブジェクトに対する作成権を持った主体が、そのレベルの下位に新規のオブジェクトを作成できます。すなわち、NIS+ ディレクトリオブジェクトの作成権を持っていれば、そのディレクトリ内に新しいテーブルを作成できます。NIS+ テーブルに対する作成権があれば、そのテーブル内に新規の列とエントリを作成できます。

これらの権限は論理的には、ディレクトリ、テーブル、列とエントリのように下位に展開するものであることに注意してください。たとえば、新規にテーブルを作成するには、そのテーブルを格納する NIS+ ディレクトリオブジェクトに対する作成権が必要です。そのテーブルを作成した場合、そのデフォルト所有者になります。所有者として、自分自身にそのテーブルに対する作成権を与え、テーブルに新規のエントリを作成できます。テーブル内に新規のエントリを作成した場合、それらのエントリの所有者になります。テーブルの所有者として、テーブルレベルの作成権を他の人に与えることもできます。たとえば、自身のテーブルのグループクラスのテーブルレベルの作成権を与えることができます。その場合、テーブルのグループのすべてのメンバーがテーブル内に新規のエントリを作成できます。新規のテーブルエントリを作成したグループの個々のメンバーは、そのエントリのデフォルト所有者になります。

アクセス権の連鎖

承認クラスは連鎖の関係にあります。つまり、上位クラスは通常下位クラスにも属しており、自動的に下位クラスの権限を得ることになります。次のように機能します。

• 「所有者クラス」。オブジェクトの所有者はそのオブジェクトのグループに所属していても、いなくてもかまいません。所有者があるグループに属していると、そのグループに与えられている権限をすべて得ることになります。オブジェクトの所有者が自動的に、その他と未認証のクラスにも属することになり、自動的にこれら 2 つのクラスに与えられている権限を獲得することになります。

• 「グループクラス」。オブジェクトのグループメンバーは自動的にその他と未認証クラスに所属します。したがって、グループメンバーは自動的にその他クラスと未認証クラスのメンバーがそのオブジェクトに持っている権限を獲得します。

• 「その他クラス」。その他クラスは自動的に、未認証クラスがオブジェクトに対して持っている権限と同じ権限を持つことになります。

• 「未認証クラス」。未認証クラスは、オブジェクトが未認証クラスに与えている権限を持つだけです。

この基本原則は、下位クラスのアクセス権は自動的に上位クラスに与えられるということです。つまり、上位クラスは下位クラスよりも多くの権限を持つことができ、権限が少なくなることはないということです (この原則の例外は、もし所有者がグループのメンバーでなければ、所有者の持っていない権限をグループクラスに与えることが可能になる場合)。

アクセス権の割り当てと変更方法

NIS+ オブジェクトを作成した時、NIS+ はそのオブジェクトに所有者クラスとグループクラスのアクセス権のデフォルトセットを与えます。デフォルトでは、所有者はそのオブジェクトを作成した NIS+ 主体です。デフォルトのグループは、環境変数 NIS_GROUP の中で名前をつけられたグループです。

異なるデフォルト権限の指定

NIS+ は NIS+ オブジェクトが作成された時に自動的に付与されたデフォルト権限を変更する 2 つの異なった方法を提供しています。

• NIS_DEFAULTS 環境変数。NIS_DEFAULTS はセキュリティに関するデフォルト値を保管し、その 1 つはアクセス権です。このデフォルトアクセス権は、オブジェクトが作成された時にオブジェクトに自動的に付与されるものです (詳細については、NIS+ デフォルトの表示 - nisdefaults コマンドを参照してください)。

  NIS_DEFAULTS 環境変数の値を変更すると、変更後に作成されたオブジェクトに新規の値が与えられます。しかし、以前に作成されたオブジェクトは影響を受けません。

• -D オプション。-D オプションは、いくつかの NIS+ コマンドで使用されます。NIS+ オブジェクトを作成するコマンドに -D オプションを使用すると、NIS_DEFAULTS 環境変数が指定したデフォルト権限を上書きします。詳細については、デフォルトを無効にするを参照してください。

既存オブジェクトへのアクセス権を変更する

NIS+ オブジェクトを作成する場合、既存のデフォルトアクセス権 (NIS_DEFAULTS 環境変数か -D オプションの指定かのどちらかによる) に対処する必要があります。デフォルト権限を変更するコマンドは次のとおりです。

• nischmod コマンド

• テーブルの列の場合は nistbladm コマンド

テーブル、列、およびエントリのセキュリティ

NIS+ テーブルに対するアクセス権を指定する方法には、次の 3 通りあります。

• 「テーブル」全体を対象にアクセス権を指定する

• 「エントリ」(行) 単位でアクセス権を指定する

• 「列」単位でアクセス権を指定する

列とエントリ (行) が交差する部分をフィールドといいます。データ値はすべてこの交差領域、つまりフィールドに入力します。

列とエントリレベルのアクセス権を持っていると、テーブルレベルのアクセス権の制限があっても個々の行と列にアクセスできますが、テーブル全体へのアクセス権以上に列とエントリレベルの権限を制限することはできません。

• 「テーブル」。テーブルレベルは基本的なレベルです。テーブルレベルに付与されたアクセス権は、列ごとまたはエントリごとに特に変更された場合を除き、テーブル内のすべての部分に適用されます。テーブルレベルの権限は最も厳格であるべきです。

  ---

  注 –

  承認クラスは連結しているということに注意してください。上位クラスは、下位クラスに割り当てられた権利を取得していることになります。アクセス権の連鎖を参照してください。

  ---

• 「列」。列レベルの権限を持っていると、列ごとに追加アクセス権を持つことになります。たとえば、その他クラスと未認証クラスにテーブルレベルの権限が何も付与されていなかったとします。この場合、この 2 つのクラスはテーブル内のデータに対して、読み取り権、変更権、作成権、削除権を持ちません。列レベルの権限を持てば、テーブルレベルの権限の制限を超えて、その他クラスのメンバーであっても特定の列のデータを読み取ることができます。

  一方、所有者クラスとグループクラスにテーブル全体の読み取り権が付与されている場合、列レベルの権限を使ってグループクラスの列の読み取り権を妨げることはできません。列のグループはテーブルのグループやエントリのグループと同じにはなりません。

• 「エントリ (行)」。エントリレベルの権限があれば、行ごとに追加アクセス権を持つことになります。たとえば、個々のユーザーに指定したエントリに限って変更する権限を与えることができるのです。

  エントリのグループはテーブルのグループとは同じである必要はなく、別のグループにできます。そうすることによって、特定のグループのメンバーに、他のグループに属するエントリに影響を与えないで、あるエントリのセットにアクセスする権限を付与できます。

テーブル、列、エントリの例

列またはエントリレベルのアクセス権は、追加アクセスを次の 2 つの方法で提供できます。1 つは権限を持つ主体を増やす方法で、もう 1 つは同じ主体に権限を追加する方法です。もちろん、これらを組み合わせることも可能です。以下にその例を示します。

テーブルオブジェクトが、そのテーブルの所有者に対して読み取り権を与えたとします。

このことは、テーブルの所有者だけがテーブル全体の内容を読み取れることを意味します。所有者でない主体は、アクセスできません。テーブルのエントリ 2 にグループクラスに対して読み取り権を与えることができます。

テーブルの内容をすべて読み取れるのは所有者だけですが、このテーブルのグループのメンバーであれば、この特定エントリの内容を読み取ることができます。次に、特定の列がその他クラスに読み取り権を与えたとします。

その他クラスのメンバーは例 1 のすべてのエントリを読み取ることができます。グループクラスのメンバーは、(その他クラスに属しているので) 例 1 のすべてとエントリ 2 の全列を読み取ることができます。*NP* になっているセルは、「グループ」、「その他」いずれのクラスも読み取りができません (どちらにもアクセス権がない)。

異なるレベルの権限

この節では 4 つの権限 (読み取り、作成、変更、削除) が 4 つのアクセスレベル (ディレクトリ、テーブル、列、エントリ) とどのようにかかわるのかを説明します。

種々の権限とレベルに関係した機能を次の表 15–5 にまとめます。

読み取り権

• 「ディレクトリ」。ディレクトリの読み取り権があれば、ディレクトリの内容を表示できます。

• 「テーブル」。テーブルの読み取り権があれば、テーブル内のすべてのデータを読み取れます。

• 「列」。列の読み取り権があれば、その列のすべてのデータを読み取れます。

• 「エントリ」。エントリの読み取り権があれば、そのエントリのすべてのデータを読み取れます。

作成権

• 「ディレクトリ」。ディレクトリレベルの作成権があれば、テーブル等の新規オブジェクトをディレクトリ内に作成できます。

• 「テーブル」。テーブルレベルの作成権があれば、テーブル内に新規のエントリを作成できますが、列は作成できません。テーブルレベルの作成権だけでは、テーブルに新規のエントリを追加できますが、新規の列を追加することはできません。

• 「列」。列の作成権があれば、列内のフィールドに新規のデータを入力できます。新規の列を作成できません。

• 「エントリ」。エントリの作成権があれば、その行のフィールドに新規のデータを入力できます。(エントリレベルの作成権では新規の行を作成することはできません。)

変更権

• 「ディレクトリ」。ディレクトリレベルの変更権があれば、ディレクトリオブジェクトの移動と名前の変更ができます。

• 「テーブル」。テーブルレベルの変更権があれば、テーブル内のデータをすべて変更できます。新規の行を作成 (追加) できますが、新規の列は作成できません。空白フィールドにデータを入力することも可能です。

• 「列」。列の変更権があれば、その列の任意のフィールドのデータを変更できます。

• 「エントリ」。エントリの変更権があれば、その行の任意のフィールドのデータを変更できます。

削除権

• 「ディレクトリ」。ディレクトリレベルの削除権があれば、テーブル等のディレクトリ内の既存オブジェクトを削除できます。

• 「テーブル」。テーブルレベルの削除権があれば、テーブル内の既存のエントリ (行) を削除できますが、列は削除できません。削除できるのは既存のエントリだけで、既存の列は削除できません。

• 「列」。列の削除権があれば、その列の任意のフィールドのデータを削除できます。

• 「エントリ」。エントリの削除権があれば、その行の任意のフィールドのデータを削除できます。

アクセス権の格納場所

オブジェクトのアクセス権は、そのオブジェクトの定義の一部として指定され、格納されます。この情報は NIS+ テーブルには格納されません。

NIS+ オブジェクトのアクセス権の読み取り

アクセス権を読み取るには niscat コマンドを使用します。

niscat -o objectname

アクセス権を読み取るオブジェクト名を指定します。

このコマンドは、NIS+ オブジェクトに関する次の情報を返します。

• 「所有者」。所有権を持っている NIS+ 主体。通常はオブジェクトを作成した人ですが、元の所有者が所有権を渡した場合もある

• 「グループ」。オブジェクトの NIS+ 主体

• 「未認証クラスのアクセス権」。認証された (有効な DES 資格を提示した) か否かにかかわらず、全員が持つ権限

• 「所有者クラスのアクセス権」。オブジェクトの所有者に付与されたアクセス権

• 「グループクラスのアクセス権」。オブジェクトのグループに付与されたアクセス権

• 「その他クラスのアクセス権」。認証された NIS+ 主体全てに付与されたアクセス権

4 つの承認クラスのアクセス権は、次のように 16 文字の文字列で表示されます。

	r---rmcdr---r---

各文字がアクセス権の種類を表します。

• r は読み取り権

• m は変更権

• d は削除権

• c は作成権

• - はアクセス権のないことを表す

先頭の 4 文字は未認証に、次の 4 文字は所有者に、その次の 4 文字はグループに、そして最後の 4 文字はその他に、それぞれ与えられたアクセス権を表します。

図 15–1 アクセス権の表示

UNIX ファイルシステムとは異なり、先頭のアクセス権は未認証用であり、所有者用ではありません。

デフォルトのアクセス権

オブジェクトを作成すると、NIS+ はそのオブジェクトにデフォルトの所有者、グループ、および アクセス権を割り当てます。デフォルトの所有者は、そのオブジェクトを作成する NIS+ 主体です。デフォルトのグループは、環境変数 NIS_GROUP の中で名前をつけられたグループです。デフォルトのアクセス権は次のようになります。

環境変数 NIS_DEFAULTS のセットがある場合、NIS_DEFAULTS 内の値が新規のオブジェクトに適用されるデフォルト値を決定します。コマンド行でオブジェクトを作成した場合は、-D フラグを使ってデフォルト値以外を設定できます。

テーブルに対するアクセス権をサーバーが割り当てる方法

この節では、読み取り、変更、削除、作成の操作が行われる際、テーブルオブジェクト、エントリ、列に対するアクセス権をサーバーが各クラスにどのように割り当てるかということについて説明します。

セキュリティレベル 0 では、サーバーはアクセス権を実行しないため、すべてのクライアントがテーブルオブジェクトに対する完全なアクセス権を付与されます。セキュリティレベル 0 は管理者だけがテストの目的で使用します。通常の業務にはレベル 0 を使用しないでください。

サーバーがアクセスを許可するか否かを決定する 4 つの要素があります。

• 主体が要求する処理の種類

• 主体がアクセスしようとしているテーブル、エントリ、または列

• その特定のオブジェクトに対して、主体が所属する承認クラス

• テーブル、エントリ、または列がその主体の承認クラスに割り当てたアクセス権

認証後に主体は、主体が有効な DES 資格を所持しているかを確認することで要求を行い、NIS+ サーバーは処理の種類と要求のオブジェクトを決定します。

• 「ディレクトリ」。オブジェクトがディレクトリかグループの場合、サーバーは 4 つのクラスに付与されている権限を知るためにオブジェクトの定義をチェックし、どのクラスに主体が所属しているか判定し、主体のクラスとそのクラスに付与された権限に基づいて、その要求を受け入れるかまたは拒否します。

• 「テーブル」。オブジェクトがテーブルの場合、サーバーは 4 つのクラスに付与されているテーブルレベルの権限を知るためにテーブルの定義をチェックし、どのクラスに主体が所属しているか判定します。所属しているクラスが要求処理を行うテーブルレベルの権限を持っていない場合は、サーバーは次にどの行または列にかかわる処理かを判定し、要求処理に必要な該当する行または列レベルのアクセス権があるかを決定します。

コマンドによるアクセス権の指定

ここでの説明では、NIS+ 環境のセキュリティレベルが 2 (デフォルト) であるものと想定しています。

この節では、この章で説明するコマンドを使用するときにアクセス権や所有者、グループ所有者、オブジェクトを指定する方法を説明します。

アクセス権の構文

この節では、承認とアクセス権に関係する NIS+ コマンドに使われるアクセス権の構文について説明します。

クラス、演算子、および権限の構文

アクセス権は、環境変数で指定する場合もコマンドで指定する場合も、「クラス (class)」、「演算子 (operator)」、「権利 (right)」という 3 種類の引数で区別されます。

• 「クラス」。クラスは、「権利」が適用される NIS+ 主体のカテゴリを意味します。

• 「演算子」。 演算子は、「権限」について行われる操作を示します。

• 「権限」。アクセス権そのものです。使用可能な値は次のとおりです。

コンマ (,) で区切ることで、複数のコマンドを 1 つのコマンド行にまとめることができます。

所有者とグループの構文

• 「所有者」。NIS+ グループを指定するには、NIS+ グループ名にドメイン名を付けて使います。

• 「グループ」。NIS+ グループを指定するには、NIS+ グループ名にドメイン名を付けて使います。

  主体名が完全指定されていることに注意してください。(principalname.domainname)

  所有者

principalname

グループ

groupname.domainname

オブジェクトとテーブルエントリの構文

オブジェクトとテーブルエントリは異なる構文を使います。

• オブジェクトは単純なオブジェクト名を使います。

• テーブルエントリはインデックス付きの名前を使います。

オブジェクト

objectname

テーブルエントリ

[columnname=value],tablename

この場合、角括弧 ( [ ] ) は構文の一部であり、オプション記号ではありません。

インデックス付きの名前では、列と値のペアを複数指定できます。その場合、操作はすべての列と値のペアに一致するエントリにだけ適用されます。列と値のペアが増えると、検索条件が厳しくなります。

たとえば :

列はインデックス付きの名前の特殊な形式になっています。列の操作は nistbladm コマンドでだけ可能なため、詳細については nistbladm コマンドを参照してください。

NIS+ デフォルトの表示 - nisdefaults コマンド

nisdefaults コマンドは、名前空間内で現在有効な 7 つのデフォルトを表示します。これらのデフォルトは次のいずれかです。

• NIS+ ソフトウェアが提供するプリセット値

• 環境変数 NIS_DEFAULTS 値で指定 されるデフォルト (変数 NIS_DEFAULTS のセットがある場合)

オブジェクトを作成する時に -D オプション付きのコマンドを使って上書きしなければ、このマシン上でオブジェクトを作成すると自動的にデフォルト値を獲得することになります。

これらのオプションを使用して、すべてのデフォルト値もしくはそのサブセットを表示できます。

• すべての値を冗長書式で表示するには、引数なしで nisdefaults コマンドを実行します。

master% nisdefaults
Principal Name : topadmin.doc.com.
Domain Name : doc.com.
Host Name : rootmaster.doc.com.
Group Name : salesboss
Access Rights : ----rmcdr---r---
Time to live : 12:00:00:00:00
Search Path : doc.com.

• すべての値を簡潔書式で表示するには、-a オプションを付けます。

• 値のサブセットを表示するには、適切なオプションを使用します。その値は簡潔モードで表示されます。権限と検索パスのデフォルトを簡潔モードで表示する例を次に示します。

  rootmaster% nisdefaults -rs ----rmcdr---r--- doc.com.

• 値のサブセットを冗長モードで表示するには、-v フラグを使用します。

デフォルトセキュリティ値の設定

この節では、nisdefaults コマンド、環境変数 NIS_DEFAULTS、および -D オプションに関連したタスクを実行する方法を説明します。環境変数 NIS_DEFAULTS は次のデフォルト値を指定します。

• Owner

• グループ

• アクセス権

• 生存期間

環境変数 NIS_DEFAULTS に設定した値はデフォルトとなり、そのシェルを使用して作成したすべての NIS+ オブジェクトに適用されます (-D オプション付きでコマンドを実行してデフォルト値に上書きした場合を除く)。

環境変数 NIS_DEFAULTS を指定することで、デフォルト値 (所有者、グループ、アクセス権、および生存期間) を指定できます。一度 NIS_DEFAULTS の値を設定するとそのシェルから作成したすべてのオブジェクトは、-D オプション付きでコマンドを実行して上書きした場合を除きそのデフォルトに設定されます。

NIS_DEFAULTS の値を表示する

echo コマンドを使って、環境変数の値をチェックできます。以下にその例を示します。

client% echo $NIS_DEFAULTS
owner=butler:group=gamblers:access=o+rmcd 

nisdefaults コマンドを使用して、名前空間でアクティブな NIS+ デフォルトの一般的リストを表示することも可能です。NIS+ デフォルトの表示 - nisdefaults コマンドを参照してください。

デフォルトを変更する

環境変数 NIS_DEFAULTS の値を変更することで、アクセス権、所有者、およびグループのデフォルトを変更できます。ユーザーのシェルに適切な環境コマンド (C シェルには setenv、Bourne シェルと Korn シェルには $NIS_DEFAULTS=, export) を次の引数を付けて使用します。

• access=アクセス権 (コマンドによるアクセス権の指定で説明されたフォーマットを使って)

• owner=所有者名

• group=グループ名

複数の引数をまとめる場合は、コロン (:) で区切ります。

owner= 主体名 :group= グループ名

表 15–13 に例をいくつか示します。

デフォルトを変更したシェルから作成されるすべてのオブジェクトとエントリは、指定した新規の値になります。テーブルの列またはエントリに対してはデフォルトを指定できません。列とエントリはデフォルトをそのまま継承します。

NIS_DEFAULTS の値を再設定する

変数 NIS_DEFAULTS をオリジナルの値に再設定するには、ユーザーのシェルに適したフォーマットを使って、引数なしで変数の名前を入力します。

C シェルの場合

client# unsetenv NIS_DEFAULTS

Bourne シェルまたは Korn シェルの場合

client$ NIS_DEFAULTS=; export NIS_DEFAULTS

デフォルトを無効にする

次の NIS+ コマンドのどれかを使えば、NIS+ オブジェクトまたはテーブルエントリを作成する時に、いつでもデフォルトのアクセス権、所有者、およびグループを無効にできます。

• nismkdir - NIS+ ディレクトリオブジェクトを作成

• nisaddent - エントリを NIS+ テーブルに転送

• nistbladm - NIS+ テーブル内にエントリを作成

デフォルト値を無効にするには、コマンドによるアクセス権の指定の説明のように、コマンドの構文に -D オプションを挿入します。

デフォルトを設定する時と同様、複数の引数を 1 行のコマンド行で指定できます。なお、列とエントリの所有者とグループは常に同じであるため、これらを無効にすることはできません。

nismkdir コマンドを使用して、sales.doc.com ディレクトリを作成し、デフォルトアクセス権を無効にして所有者にだけ読み取り権を付与するには、次のように入力します。

client% nismkdir -D access=o+r sales.doc.com

オブジェクトとエントリのアクセス権を変更する

nischmod コマンドは、NIS+ オブジェクトまたはテーブルエントリのアクセス権を変更します。テーブル列のアクセス権は操作しません。列の場合、nistbladm コマンドに -D オプションを付けて実行してください。nischmod コマンドを使用するには、そのオブジェクトかエントリに対する変更権が必要です。

nischmod コマンドを使用して権限を追加する

オブジェクトまたはエントリに権限を追加する例を次に示します。

オブジェクト

nischmod class+right object-name

テーブルエントリ

nischmod class+right [column-name=value],table-name

sales.doc.com. ディレクトリオブジェクトのグループに読み取り権と変更権を追加する場合は、次のように入力します。

client% nischmod g+rm sales.doc.com.

hosts.org_dir.doc.com. テーブル内の name=abe エントリのグループに読み取り権と変更権を追加する場合は、次のように入力します。

client% nischmod g+rm '[name=abe],hosts.org_dir.doc.com.'

nischmod を使用して権限を削除する

オブジェクトまたはエントリの権限を削除するには、次のように入力します。

オブジェクト

nischmod class-right object-name

エントリ

nischmod class-right [column-name=value],table-name

sales.doc.com. ディレクトリオブジェクトのグループから作成権と削除権を削除するには次のように入力します。

client% nischmod g-cd sales.doc.com.

たとえば、hosts.org_dir.doc.com. テーブル内の name=abe エントリのグループから削除権を削除する場合は、次のようにします。

client% nischmod g-d '[name=abe],hosts.org_dir.doc.com.' 

列アクセス権を指定する

nistbladm コマンドは NIS+ テーブルに種々の操作を行うことができます。これについては nistbladm コマンドにほとんどの説明があります。このコマンドは -c と -u の 2 つのオプションを使用してセキュリティ関連のタスクを実行できます。

• -c オプション。nistbladm コマンドを使用して テーブルを作成する際に、-c オプションを使用すると最初の列アクセス権を指定できます。

• -u オプション。-u オプションを nistbladm コマンドとともに使用すると、列アクセス権を変更できます。

テーブル作成時の列権限設定

テーブルが作成された時、列にはテーブルオブジェクトと同じ権限が付与されます。このテーブルレベルの権限は環境変数 NIS_DEFAULTS で指定されるか、またはテーブルを作成したコマンドの一部で指定されます。nistbladm コマンドでテーブルを作成する際に -c オプションを使用すれば、最初の列アクセス権を指定できます。このオプションを使用するには、テーブルを作成しようとするディレクトリの作成権が必要です。テーブル作成時に列権限を指定するには、次のように入力します。

nistbladm -c type `columname=[flags] [,access]... tablename'

引数の意味は、それぞれ以下のとおりです。

• type は、テーブルの種類を示す文字列です。テーブルの type は何にでもできます。

• columnname は列名です。

• flags には、列の種類を指定します。使用できるフラグには次のものがあります。

  • S (検索可能)

  • I (大文字と小文字を区別しない)

  • C (暗号化)

  • B (2 進データ)

  • X (XDR 符号化データ)

• access は、コマンドによるアクセス権の指定で説明した構文を使用したこの列のアクセス権です。

• ... は、それぞれの型と権限のセットを持った複数の列を指定できることを示しています。

• tablename は、完全指定名で表した作成しようとするテーブル名です。

テーブルを作成する際、その列にはテーブルオブジェクトと同じ権限が付与されます。列に独自の権限を付与するには、列の型とコンマの後の各列の等号記号にアクセス権を追加し、列をスペースで区切ります。

column=type,   rights column= type, rights column =   type, rights

以下の例では、div 特性で depts という名前のテーブルが doc.com ディレクトリに作成されます。列は Name、Site および Manager の 3 つです。第 2、第 3 列のグループには、変更権が追加されます。

rootmaster% nistbladm -c div Name=S Site=S,g+m Manager=S,g+m depts.doc.com

nistbladm と -c オプションの詳細については、第 19 章「NIS+ テーブルの管理」を参照してください。

既存のテーブル列に権限を追加する

既存の NIS+ テーブルの列にアクセス権を追加するには、nistbladm -u オプション付きの nistbladm コマンドを使用します。このオプションを使用する場合、テーブル列の変更権が必要です。入力例を次に示します。

nistbladm -u [column=   access,...],tablename

引数の意味は、それぞれ以下のとおりです。

• column は列名です。

• access は、コマンドによるアクセス権の指定で説明した構文を使用したこの列のアクセス権です。

• ... は、それぞれの type と権限のセットを持った複数の列を指定できることを示しています。

• tablename は、完全指定名で表した作成しようとするテーブル名です。

権限を更新する列ごとに column=access のペアを使用します。複数の列を更新するにはコンマ (,) で区切り全体を角括弧 ( [] ) で囲みます。

[column=access,   column=access,    column=access]

このオプションの完全な構文については、第 2 章「NIS+ の紹介」を参照してください。

次の例は、hosts.org_dir.doc.com. テーブルの name および addr 列のグループに、作成権と変更権を追加するものです。

client% nistbladm -u `[name=g+rm,addr=g+rm],hosts.org_dir..doc.com.'

テーブル列から権限を削除する

NIS+ テーブル列のアクセス権を削除するには、上記 既存のテーブル列に権限を追加するで説明したように -u オプションを使用します。

次の例は、hosts.org_dir.doc.com. テーブルの hostname 列のグループの読み取り権と変更権を削除するものです。

client% nistbladm -u 'name=g-rm,hosts.org_dir.doc.com.' 

オブジェクトとエントリの所有権の変更

nischown コマンドは、1 つ以上のオブジェクトまたはエントリの所有者を変更します。このコマンドを使用するには、オブジェクトまたはエントリに対する変更権が必要です。テーブルの列の所有者はテーブルの所有者であるため、nischown コマンドでは列の所有者を変更できません。列の所有者を変更するには、テーブルの所有者を変更する必要があります。

nischown コマンドを使用してオブジェクトの所有者を変更する

オブジェクトの所有者を変更するには、次のように入力します。

nischown new-owner object

引数の意味は、それぞれ以下のとおりです。

• new-owner は、そのオブジェクトの新規の所有者のユーザー ID で完全指定します。

• object は、そのオブジェクトの完全指定名です。

オブジェクト名と新規所有者名にドメイン名を必ず追加します。

次の例は、doc.com. ドメイン内の hosts テーブルの所有者を、ホームドメインが doc.com. でユーザー名 lincoln であるユーザーに変更するものです。

client% nischown lincoln.doc.com. hosts.org_dir.doc.com.  

nischown コマンドを使用してテーブルエントリの所有者を変更する

テーブルエントリの所有者を変更する構文は、エントリを特定するのにインデックス付きエントリを使います。次に例を示します。この構文の詳細については、オブジェクトとテーブルエントリの構文を参照してください。

nischown new-owner [column=value,...],  tablename 

引数の意味は、それぞれ以下のとおりです。

• new-owner は、そのオブジェクトの新規の所有者のユーザー ID で完全指定します。

• column は、所有者を変更するエントリ (行) を特定する値を持った列名です。

• value は、所有者を変更するエントリ (行) を特定するデータ値です。

• ... は、所有者を変更する複数のエントリを示します。

• tablename は、所有者を変更するエントリを含むテーブルの完全指定名です。

所有者名とテーブル名にドメイン名を必ず追加します。

次の例は、doc.com. ドメインのホストテーブル内のエントリの所有者を、ホームドメインが doc.com. であるユーザー takeda に変更するものです。そのエントリの name 列の値は virginia です。

client% nischown takeda.doc.com. '[name=virginia],hosts.org_dir.doc.com.' 

オブジェクトまたはエントリグループの変更

nischgrp コマンドは、1 つ以上のオブジェクトまたはテーブルエントリのグループ所有者を変更します。このコマンドを使用するには、オブジェクトまたはエントリに対する変更権が必要です。テーブルの列に割り当てられたグループは、テーブルに割り当てられたグループと同じであるため、nischgrp コマンドは、列のグループを変更できません。列のグループ所有者を変更するには、テーブル所有者を変更する必要があります。

nischgrp コマンドを使用してオブジェクトのグループを変更する

オブジェクトのグループを変更するには、次の構文を使用します。

nischgrp group  object

引数の意味は、それぞれ以下のとおりです。

• group は、オブジェクトの新規のグループの完全指定名です。

• object は、オブジェクトの完全指定名です。

オブジェクト名と新規のグループ名にはドメイン名を必ず追加します。

次の例は、doc.com. ドメイン内の hosts テーブルのグループを admins.doc.com. に変更するものです。

client% nischgrp admins.doc.com. hosts.org_dir.doc.com.  

nischgrp コマンドを使用してテーブルエントリのグループを変更する

テーブルエントリのグループを変更する構文は、エントリを識別するためにインデックス付きのエントリを使用します (この構文については、オブジェクトとテーブルエントリの構文に詳細説明があります)。以下に構文を示します。

nischgrp new-group [column=value,...],  tablename

引数の意味は、それぞれ以下のとおりです。

• new-group は、オブジェクトの新規グループの完全指定名です。

• column は、変更される特定のエントリ (行) を識別する値を持った列名です。

• value は、変更されるグループの特定の エントリ (行) を識別するデータ値です。

• tablename は、変更されるグループのエントリを含むテーブルの完全指定名です。

• ... は、複数のエントリで変更するグループを指定できることを示します。

新規グループ名とテーブル名にはドメイン名を必ず追加します。

次の例は、doc.com. ドメインのホストテーブル内のエントリのグループを sales.doc.com. に変更するものです。そのエントリの name 列の値は virginia です。

client% nischgrp sales.doc.com. '[name=virginia],hosts.org_dir.doc.com.' 

第 16 章 パスワードの管理

この章では、一般ユーザー (NIS+ 主体) の観点から見た passwd コマンドの使用方法と、NIS+ 管理者によるパスワードシステムの管理方法を説明します。

NIS+ セキュリティタスクには、Solstice AdminSuite ツールが利用可能であればもっと簡単に実行できるものがあります。

NIS+ は、将来のリリースでサポートされない可能性があります。NIS+ から LDAP への移行支援ツールは、Solaris 9 オペレーティング環境で使用できます (『Solaris のシステム管理 (ネーミングとディレクトリサービス : DNS、NIS、LDAP 編)』を参照)。詳細については、http://www.sun.com/directory/nisplus/transition.html を参照してください。

パスワードの使用

マシンへのログインの際には、ユーザー名 (「ログイン ID」とも呼ばれる)、およびパスワードを入力する必要があります。ログイン ID は公開の情報ですが、パスワードを知っているのは所有者だけです。

ログインの方法

システムへのログインは以下の手順で行います。

1. Login: プロンプトで、ログイン ID を入力します。

2. Password: プロンプトで、パスワードを入力します。

   (秘密を守るため、入力してもパスワードは画面に表示されません)

   ログインに成功すると、本日のメッセージ (ない場合もある)、続いてコマンド行プロンプト、ウィンドウシステム、通常のアプリケーションなどが表示されます。

Login incorrect メッセージ

「Login incorrect」というメッセージは以下のことを意味します。

• 「誤ったログイン ID あるいはパスワードを入力した」。最も一般的な理由です。スペルを確認してもう一度やり直します。誤入力の回数は、ほとんどのシステムで「5」に制限されているので注意してください。

  • 誤入力の回数が制限を超えると、「Too many failures - try later」というメッセージが表示され、一定の時間が経過するまで再試行ができなくなります。

  • 指定された時間内にログインが成功しないと、「Too many tries; try again later」というメッセージが表示され、一定の時間が経過するまで再試行できなくなります。

• 「管理者がパスワードをロックしている」。管理者によってパスワードがロックされた場合、ロックを解除してもらうまで使用することができません。ログイン ID、パスワードともに正しく入力しているにもかかわらず「Login incorrect」メッセージが表示される場合は、システム管理者に問い合わせてください。

• 「パスワード使用権がシステム管理者によって取り消された」。ログイン ID、パスワードともに正しく入力しているにもかかわらず「Login incorrect」メッセージが表示される場合は、システム管理者に問い合わせてください。

will expire メッセージ

「Your password will expire in N days」メッセージ (または「Your password will expire within 24 hours」というメッセージ) は、「パスワードが、N 日あるいは 24 時間以内に有効期限に達する」ということを意味します。

このメッセージが表示されたら、パスワードをすぐに変更する必要があります (パスワードの変更方法を参照)。

Permission denied メッセージ

ログイン ID とパスワードを入力後、 「Permission denied」というメッセージが表示されて login: プロンプトに戻る場合があります。 これは、管理者がパスワードをロックしたか、管理者がユーザーのアカウントを終了したか、パスワード権限の有効期限が切れたために、ログインに失敗したことを意味します。このような場合、管理者がパスワードロックを解除するか、アカウントを復旧するまではログインができません。システム管理者に問い合わせてください。

パスワードの変更方法

セキュリティを確保するため、パスワードは定期的に変更してください (新しいパスワードを作成する場合の必要条件、および基準については、パスワードの選択を参照)。

現在の passwd コマンドでは、以前 nispasswd で行なっていた操作がすべて行えます。NIS+ の名前空間に特有な操作を行うには、passwd -r nisplus を使用します。

パスワードの変更は以下の手順で行います。

1. システムプロンプトから passwd コマンドを実行します。

2. Enter login password (多少異なる場合がある) プロンプトで、従来のパスワードを入力します。

   キー入力の内容は画面には表示されません。

   • 「Sorry: less than N days since the last change」というメッセージが表示されたら、「現在使用中のパスワードは、作成されてからまだ十分な時間が経過していないため変更できない」ということを意味します。この場合はシステムプロンプトに戻ります。システム管理者に「パスワードは、作成後何日経過すれば変更できるのか」を問い合わせてください。

   • 「You may not change this password」というメッセージが表示された場合は、変更がネットワーク管理者によって禁止されているということを意味します。

3. Enter new password プロンプトで、新しいパスワードを入力します

   キー入力の内容は画面には表示されません。

   この時点で、新しいパスワードが必要条件を満たしているかどうかがシステムによって確認されます。

   • 満たしている場合は再入力を求められます。

   • 満たしていない場合は、その旨を知らせるメッセージが表示されます。このときは、必要条件を満たす別のパスワードを入力する必要があります。

   パスワードの必要条件については、パスワードの必要条件を参照してください。

4. Re-enter new password プロンプトで、新しいパスワードを再入力します。

   キー入力の内容は画面には表示されません。

   1 回目と 2 回目で入力したパスワードが異なっていた場合は、手順 1 から繰り返すようにプロンプトが表示されます。

   ---

   注 –

   root のパスワードを変更した場合は、その直後に必ず chkey -p を実行する必要があります (詳細は、ルートからのルート鍵の変更、および、別のマシンからルート鍵を変更する手順を参照してください)。root のパスワードを変更したあと chkey -p を実行しないと、root で正常にログインできなくなります。

   ---

このメッセージは、「パスワードが有効期限を過ぎている」ということを意味します。つまり、パスワードを作成してから時間が経ちすぎているので、すぐに作成し直す必要があるということです (新しいパスワードを作成する場合の必要条件については、パスワードの選択を参照してください)。

この場合、新しいパスワードの作成は以下の手順で行います。

1. Enter login password (多少異なる場合がある) プロンプトで、従来のパスワードを入力します。

   キー入力の内容は画面には表示されません。

2. Enter new password プロンプトで、新しいパスワードを入力します。

   キー入力の内容は画面には表示されません。

3. Re-enter new password プロンプトで、新しいパスワードを再入力します。

   キー入力の内容は画面には表示されません。

パスワード変更の失敗

システムの中には、パスワード変更の試行回数、所要時間に制限を設けているものもあります (他の人が試行錯誤によって勝手にパスワードを変更してしまうのを防ぐため)。

パスワード変更、ログインの試行回数、または所要時間が指定の範囲を超えた場合は、「Too many failures - try later」、または「Too many tries: try again later」といったメッセージが表示されます。この種のメッセージが表示されると、一定の時間 (システム管理者が指定) が経過するまでログイン、パスワードの変更は行えなくなります。

パスワードの選択

コンピュータのセキュリティの侵害の例としては、「他のユーザーのパスワードを推測によって盗む」というものが多くみられます。passwd コマンドには、パスワードを推測しにくいものにするための基準がいくつか設けられていますが、ユーザーに関していくつかの情報を得るだけでパスワードがわかってしまう人もいるのです。したがって、「自分にとって覚えやすく他人にとって推測しにくい」というのが良いパスワードです。逆に悪いパスワードとは、「自分にとって覚えにくく (メモしないと覚えられない)、自分を知る他人にとっては推測しやすい」というものです。

パスワードの必要条件

パスワードの必要条件は以下のとおりです。

• 「長さ」。パスワードの長さは 6 文字以上にします (デフォルト)。また意味を持つのは最初の 8 文字だけです (つまり、「8 文字より長いパスワードを作成することはできるが、システムは最初の 8 文字のみをチェックする」ということです)。パスワードの長さの最小値 (文字数) はシステム管理者によって変更される可能性があり、システムによっては 6 文字ではない場合があります。

• 「文字」。英文字 2 つ以上 (大文字、小文字どちらでも良い) と数字または記号 (@、#、% など) 1 つ以上で構成します。つまり、dog#food、dog2food といったパスワードは使用できますが、dogfood というパスワードは使用できません。

• 「ログイン ID と同じにならないようにする」。パスワードをログイン ID と同じにすることはできません。またログイン ID の文字を並べ替えたものも使用できません (この場合、大文字と小文字は同じものとして考える)。大文字と小文字は区別されません。たとえば、ログイン ID が Claire2 の場合は、 e2clair はパスワードとして使用できません。

• 「古いパスワードと同じにならないようにする」。古いパスワードと同じにならないようにします。古いパスワードを、少なくとも 3 文字以上入れ替える必要があります (この場合、大文字と小文字は同じものとして考える)。古いパスワードが Dog#fooD なら、新しいパスワードにたとえば dog#Meat は使用できますが、daT#Food は使用できません。

悪いパスワードの例

悪いパスワードの例としては以下のようなものが考えられます。

• 自分の名前をもとにしたもの

• 家族やペットの名前

• 運転免許証の番号

• 電話番号

• 社会保険の番号

• 従業員番号

• 趣味に関係のある名前

• 季節に関係のある名前 (たとえば 12 月に Santa を使うなど)

• 普通の辞書に載っている単語

良いパスワードの例

良いパスワードの例としては以下のようなものが考えられます。

• フレーズに数字や記号を加えたもの (例：beam#meup)

• フレーズを構成する単語の頭文字に番号や記号を加えた意味のない言葉 (例：SomeWhere Over The RainBow の頭文字に 7 を加えた swotrb7)

• 単語の一部を数字や記号に置き換えたもの (例：snoopy ではなく、sn00py にする)

パスワードの管理

この節では、NIS+ 名前空間でパスワードを管理する方法について説明します。この節では、NIS+ セキュリティシステムと、そのログインパスワードについて十分に理解していることを想定しています (NIS+ セキュリティシステムについては、第 11 章「NIS+ のセキュリティの概要」を参照してください)。

現在の passwd コマンドでは、以前 nispasswd で行なっていた操作がすべて行えます。NIS+ の名前空間に特有な操作を行うには、passwd -r nisplus を使用します。

nsswitch.conf ファイルの必要条件

passwd コマンドの使用や、パスワードの使用期間に関する設定を正しく行うには、nsswitch.conf ファイル中の passwd エントリがすべてのマシンにおいて正しくなければなりません。passwd コマンドが「パスワード情報をどこに要求するか」および「パスワード情報をどこで更新するか」は、このエントリによって決定されます。

passwd エントリの設定として考えられるのは、以下の 5 種類だけです。

• passwd: files

• passwd: files nis

• passwd: files nisplus

• passwd: compat

• passwd: compatpasswd_compat: nisplus

使用しているネットワークのすべてのマシン上に存在する nsswitch.conf ファイルは、必ず上記の passwd 構成のうちの 1 つを使用していなければなりません。別の方法で、passwd エントリを構成した場合、ユーザーがログインできない可能性があります。

nispasswd コマンド

現在の passwd コマンドでは、以前 nispasswd で行なっていた操作がすべて行えます。コマンド行で実行するときは、nispasswd ではなく passwd を使用します。

旧バージョンとの互換性を確保するため、nispasswd も完全な形で残っている点に注意してください。

yppasswd コマンド

現在の passwd コマンドでは、以前 yppasswd で行なっていた操作がすべて行えます。コマンド行で実行するときは、yppasswd ではなく passwd を使用します。

旧バージョンとの互換性を確保するため、yppasswd も完全な形で残っている点に注意してください。

passwd コマンド

passwd コマンドでは、パスワードに関する様々な操作が行えます。現在の passwd コマンドは、nispasswd コマンドの代わりとして使用できます。従来 nispasswd で行なっていた操作にも、passwd コマンドを使用するようにしてください。passwd コマンドのフラグ、オプション、引数の詳細は、マニュアルページを参照してください。

一般ユーザーが passwd コマンドで行える操作には以下のものがあります。

• 自らのパスワードの変更

• 自らのパスワード情報の表示

管理者が passwd コマンドで行える操作には以下のものがあります。

• 他のユーザーにログイン時のパスワード変更を強制する

• 他のユーザーのパスワードをロック (使用不可能に) する

• 「パスワード作成後、どのくらいの期間変更禁止にするか」を指定する

• 「パスワードが間もなく無効になる」という警告を出すタイミングを指定する

• パスワードの有効期間を指定する

passwd コマンドと nsswitch.conf ファイル

passwd などのコマンドがパスワード情報をどこから得て、どこに保存するのかということは、nsswitch.conf ファイルで設定します。nsswitch.conf ファイルの passwd エントリの設定に使用する文字列はそれぞれ以下のことを意味します。

• nisplus。パスワード情報の獲得、変更、保存は、該当するドメインの passwd テーブルおよび cred テーブルで行う

• nis。パスワード情報の獲得、変更、保存は、passwd マップで行う

• files。パスワード情報の獲得、変更、保存は、/etc/passwd ファイルおよび /etc/shadow ファイルで行う

passwd -r オプション

passwd コマンドの -r nisplus、-r nis、-r files といった引数は、nsswitch.conf ファイルの設定よりも優先されます。これらの引数をつけて passwd コマンドを実行すると、「nsswitch.conf ファイルより優先される」ということを知らせる警告メッセージが表示されます。警告メッセージ表示後も操作を続行すると、nsswitch.conf ファイルのシーケンスは無視され、-r によって指定された場所でパスワード情報の更新が行われます。

たとえば、nsswitch.conf ファイルにおいて passwd エントリが以下のように指定されている場合を考えてみましょう。

passwd: files nisplus

この場合、passwd コマンドを -r を使用しないで実行すると、パスワード情報のソース (情報の獲得、変更、保存が行われる場所) は /etc/passwd ファイルになります。しかし -r nisplus オプションを使用して passwd コマンドを実行すると、パスワード情報のソースは /etc/passwd ファイルから NIS+ の passwd テーブルに変更されます。

-r オプションは、「検索シーケンスが誤っていて nsswitch.conf ファイルが使用できない」という場合にのみ使用するようにします。たとえば、2 カ所に格納されているパスワード情報を更新する必要がある場合、1 つ目については nsswitch.conf ファイルで指定されているソースを使用できますが、2 つ目については別のソースを使用する必要があります。

変更しようとすると、次のメッセージが表示されます。

Your specified repository is not defined in the nsswitch file!

このメッセージは、「パスワード情報の更新は、-r オプションで指定された場所で行なわれるが、nsswitch.conf ファイルでその場所がソースとして使用されるまでは更新の影響がまったく現れない」ということを意味します。たとえば、nsswitch.conf ファイルにおいて passwd: files nis という指定が行われているときに、-r nisplus オプションでパスワード使用期間の設定を行なったとします (つまり設定は NIS+ の passwd テーブルにおいて行われることになる)。パスワード情報のソースが nsswitch.conf ファイルにおいて NIS+ passwd テーブル以外の場所に指定されているため、この設定による影響はまったく現れません。

passwd コマンドと NIS+ 環境

この章で「NIS+ 環境」とは、「nsswitch.confファイルでパスワード情報のソースが nisplus に設定されている」、「passwd コマンドが -r nisplus という引数をつけて実行されている」という状況を指します。

passwd コマンドと資格

passwd コマンドは NIS+ 環境 (前節参照) で実行された場合、ユーザーに資格があってもなくても機能するよう設計されています。ただし資格のないユーザーが passwd コマンドで行えるのは、自らのパスワードの変更だけです。他のパスワード操作は、資格のある (認証された)、必要なアクセス権を持った (承認された) ユーザーだけが行えます。

passwd コマンドとアクセス権

承認およびアクセス権については、ユーザーがすべて適切な資格を持っているという前提で説明をします。

通常の NIS+ 環境では、passwd テーブルの所有者はいつでも制約なしにパスワード情報の変更ができます (デフォルトの場合)。つまり passwd テーブルの所有者は、読み取り、作成、変更、削除に関して完全に承認されている (アクセス権を与えられている) ということになります。また所有者は以下のことも行えます。

• nischown コマンドを使用して、テーブルの所有権を別のユーザーに与える

• テーブルのグループ、その他、未認証といったクラスに、読み取り権、作成権、変更権、削除権などを与える (この種の権利をその他クラス、未認証クラスに与えると NIS+ のセキュリティが弱くなる)

• 任意のクラスに与えられたアクセス権を、nisdefaults、nischmod、nistbladm などのコマンドを使用して変更する

与えられているアクセス権には関わりなく、その他クラス、未認証クラスのユーザーはすべてパスワードの使用期間の制約に従います。つまり、自分のパスワードであろうと他のユーザーのパスワードであろうと、作成されてから一定の時間が経過するまでは変更ができないということです。また有効期間の過ぎたパスワードを変更しなければならないという点も、グループ、その他、未認証といったクラスのメンバーすべてに共通です。しかしパスワード使用期間に関する上記のような制約は、passwd テーブルの所有者には適用されません。

NIS+ 環境で passwd コマンドを使用する場合、行おうとする操作に関する承認 (アクセス権) が必要です。

passwd コマンドと鍵

NIS+ 環境で passwd コマンドを使用して主体のパスワードを変更しようとすると、主体の非公開鍵が cred テーブル中で更新されます。

• cred テーブルの DES エントリに対してユーザーが変更権を持っていて、ログインパスワードと Secure RPC パスワードが同じであれば、passwd コマンドによって cred テーブルの非公開鍵が更新されます。

• cred テーブルの DES エントリに対する変更権がユーザーになく、ログインパスワードと Secure RPC パスワードが異なっている場合は、passwd コマンドによってパスワードだけが変更され、非公開鍵は変更されません。

  つまり cred テーブルの非公開鍵が、passwd テーブルに格納されているものとは異なったパスワードで作られることになります。この場合は、chkey コマンドを実行する、ログイン後に毎回 keylogin を実行するといった方法で、鍵を変更する必要があります。

passwd コマンドと他のドメイン

他のドメインの passwd テーブルに対して操作をするには、passwd コマンドを以下のように使用します。

passwd [options] -D domainname

nistbladm コマンド

nistbladm は、passwd テーブルをはじめとする NIS+ テーブルに関する情報を作成、変更、表示するのに使用するコマンドです。

nistbladm コマンドを使用してパスワード操作をするには、nistbladm を passwd テーブルのシャドウ列に適用する必要があります。nistbladm をシャドウ列に適用するのは複雑で微妙な作業になります。passwd コマンド、admintool、または Solstice AdminSuite ツールで容易に行える操作には、nistbladm コマンドを使用しない方が良いでしょう。

つまり以下のような操作には、nistbladm ではなく passwd コマンドや Solstice AdminSuite ツールを使用してください。

• パスワードの変更

• パスワードの使用期間の設定

• パスワード作成後から変更が可能になるまでの時間の設定

• 「パスワードが間もなく無効になる」という警告が表示されるタイミングの設定

• パスワードの使用期間に関する設定の解除

nistbladm コマンドには以下の機能があります。

• 新しい passwd テーブルエントリの作成

• 既存のエントリの削除

• passwd テーブル中の UID フィールド、GID フィールドの更新

• passwd テーブルの、アクセス権などセキュリティに関する属性の更新

• ユーザーアカウントに関して「どれだけの期間使用できるか」、「どれだけの期間使用されなければ無効になるか」を設定する (パスワード使用権の有効期限、ログインの間隔の最大値の指定を参照)

nistbladm と シャドウ列のフィールド

nistbladm コマンドでは、シャドウ列の様々なフィールドの値を指定することによってパスワードパラメータの設定を行います。シャドウ列のフィールドの値は、以下のような形式で設定します。

引数の意味は、それぞれ以下のとおりです。

• 「n1 最終更新日」。パスワードが最後に変更されたときの日付です。1970 年 1 月 1 日からの日数で表されます。このフィールドの値は、パスワードが変更されると自動的に更新されます (日数に関する詳細な情報は、nistbladm と日数に示されています)。このフィールドが空白であったり、指定されている値が 0 の場合は、過去に一度もパスワードの変更が行われていないことを意味します。

  このフィールドの値は、残りのフィールドの設定の基礎となることに注意してください。このフィールドの値が不当に変更されると、残りのフィールドの設定も不当なものになります。

• 「n2 最小値」は、パスワードが変更されてから、次の変更が可能になるまでの期間です。たとえば、パスワード作成時の最終変更日フィールドの値が 9201 (1970 年 1 月 1 日から 9201 日経過したことを示す) で、最小値フィールドの値が 8 だとすると、9209 日目まではパスワードの変更ができません (詳細は、パスワードの変更禁止期間の設定を参照)。

  この値としては以下の 3 とおりが考えられます。

  • 「0」または空白の場合は、変更禁止期間がないことを意味します。

  • 「0 より大きい数字」は、この数字がパスワードの変更禁止期間 (単位: 日) になります。

  • 「最大値 (n3) より大きい値」は、このフィールド値が最大フィールドの値より大きい場合、パスワードを変更できません。変更しようとすると、「You may not change this password」というメッセージが表示されます。

• 「n3 最大値」は、パスワードが作成されてから、使用できなくなるまでの日数を示します。この日数を過ぎると、ログインの際新しいパスワードの設定が強制されます。たとえば、パスワード作成時の最終変更日の値が 9201 の最大値が 30 である場合、9231 (9201+30) 日目が経過した後は、ログイン時に新しいパスワードの設定が強制されます (詳細は、パスワードの有効期間の設定を参照)。

  この値としては以下の 3 とおりが考えられます。

  • 「0」は、次回ログイン時のパスワード変更を強制する。使用期間に関する設定は解除される

  • 「0 より大きい値」は、パスワードの有効期間の日数を指定します。

  • 「-1」は、パスワードの使用期間に関する設定を解除します。つまり passwd -x -1 username というコマンドを実行すると、以前に行われたパスワードの有効期間の設定が解除されることになります。このフィールドを空白にしておくと、-1 として扱われます。

• 「n4 警告」は、「パスワードが間もなく無効になる」という警告メッセージが表示されるタイミングを示します。パスワードが作成されてからの日数で指定します。たとえば、最終変更日時フィールドの値が 9201 、最大値フィールドの値が 30、警告フィールドの値が 5 であると仮定します。この場合、日付が 9226 日 (9201+30-5=9226) 以降になると、ログインするたびに「パスワードを変更してください」という警告が表示されます。パスワードの警告時期の詳細については、警告期間の設定 を参照してください。

  この値としては以下の 2 とおりが考えられます。

  • 「0」は、警告メッセージが表示される期間がないことを示します。

  • 「0 より大きい値」は、この数字が、パスワードが作成されてから警告メッセージが表示されるまでの期間 (日数) になります。

• 「n5 間隔」は、ログインとログインの間隔 (日数) の最大値です。ここで指定された日数を超える期間ログインを行わないと、ログインができなくなります。たとえば、間隔に 6 を指定した場合、6 日間ログインを行わないと 7 日目にはログインができなくなります (詳細は、ログインの間隔の最大値の指定を参照)。

  この値としては以下の 2 とおりが考えられます。

  • 「マイナス 1 (-1)」は、最大ログイン間隔機能を解除します。任意の日数の間オフにすることができ、ログイン権限を失うことはありません。これはデフォルトです。

  • 「0 より大きい値」は、最大ログイン間隔 (日数) を指定します。

• 「n6 期限」は、パスワードの有効期限を示します。1970 年 1 月 1 日からの日数で表されます。この日を過ぎると、ログインができなくなります。たとえば、期限が 9739 (1995 年 9 月 1 日) に設定されている場合、1995 年 9 月 2 日 (GMT) になるとログインができなくなります。このときログインを試行すると 「Login incorrect」というメッセージが表示されます (詳細は、パスワード使用権の有効期限を参照)。

  この値としては以下の 2 とおりが考えられます。

  • 「-1」は、有効期限の設定を解除します。パスワードが有効期限を過ぎている場合でも、-1 を設定すると再び使えるようになります。有効期限を設定したくないときは、-1 を指定するようにしてください。

  • 「0 より大きい値」は、有効期限の日付 (「1970 年 1 月 1 日から数えて何日目か」) です。現在以前の日付を設定すると、パスワードはすぐに無効になります。

• 「n7 未使用」というフィールドは、現在使用されていません。値を設定しても無視されます。

• 「login」はユーザーのログイン ID を指定します。

nistbladm を使用して passwd テーブルのシャドウ列を設定する場合、すべてのフィールドに適切な値を指定する必要があります。空白のまま残したり、0 を入力したりしても「変更なし」という意味にはなりません。

ユーザー amy が、パスワードの最終変更日が 1995 年 5 月 1 日 (1970 年 1 月 1 日から数えて 9246 日目)、パスワード作成後の変更禁止期間が 7 日、パスワードの有効期間が 30 日、「パスワードが間もなく無効になる」という警告が表示されるのがパスワード作成から 26 日目以降、ログインとログインの間隔の最大値が 15 日、アカウントの有効期限が (1970 年 1 月 1 日から) 9255 日目という設定にするには、以下のように入力します。

nistbladm と日数

パスワードの使用期間に関するパラメータは、日数で表されるものがほとんどです。日数を指定する際には以下の規則を守る必要があります。

• 1970 年 1 月 1 日を 0 とします。つまり 1970 年 1 月 2 日は 1 になります。

• NIS+ では、日付の計算、カウントに GMT (Greenwich Mean Time) が使用されます。つまり日付が変更されるのは、GMT の午前 0 時です。

• 日数の指定には整数を使用します。分数は使用できません。

• パスワードのロックなどの動作は、指定された日付に行われます。たとえば、パスワード使用権の有効期限を1995 年 1 月 2 日 (1970 年 1 月 1 日から 9125日目) に設定した場合、この日は「ユーザーがパスワードを使用できる最後の日」となります。パスワードが使用できなくなるのは、次の日からです。

最終変更日、期限のどちらのフィールドも、入力するのは 1970 年 1 月 1 日から数えた日数です。たとえば、下記のようになります。

関連コマンド

passwd および nistbladm コマンドと類似の機能を持つコマンドは他にもあります。それぞれについて表 16–3 にまとめてあります。

パスワード情報の表示

ドメイン中のユーザーのパスワード情報を表示するには、passwd コマンドを使用します。情報は、全ユーザーについて同時に表示することも、ユーザーごとに表示することもできます。

自分のパスワード情報

passwd -s

ドメインの全ユーザーの情報

passwd -s -a

個々のユーザー

passwd -s username

表示できるのは、エントリおよび列のうち読み取り権を持っているものだけです。エントリの表示形式は以下のとおりです。

• 使用期間に関する情報が省略されたもの： username status

• 使用期間に関する情報が付加されたもの： username status mm/dd/yy min max warn expire inactive

別のドメインの passwd テーブルのエントリを表示するには、-D オプションを使用します。

ドメイン中の全ユーザー

passwd -s -a -D domainname

個々のユーザー

passwd -s -D domainname username

パスワードの変更

新しいパスワードを作成するときは、パスワードの必要条件に示された必要条件を満たすようにします。

自分のパスワードの変更

自分のパスワードを変更するには、以下のように入力します。

station1% passwd

「古いパスワードの入力」、「新しいパスワードの入力」、「新しいパスワードの再入力 (確認のため)」という順にプロンプトが表示されるので、それに従って作業します。

他人のパスワードの変更

他人のパスワードを変更するには、以下のように入力します。

同じドメイン内の他のユーザー

passwd username

他のドメインのユーザー

passwd -D domainname username 

NIS+ 環境 (passwd コマンドと NIS+ 環境参照) で passwd コマンドを使用して他人のパスワードを変更する場合、passwd テーブルにおける該当ユーザーエントリへの変更権が必要になります。つまり、該当する passwd テーブルに対して変更権を持つグループのメンバーになる必要があります。このとき、該当ユーザーの古いパスワードや自分のパスワードを入力する必要はありません。確認のため新しいパスワードの入力を求めるプロンプトが 2 回表示されます。一致しない場合は、さらに 2 回入力する必要があります。

root のパスワードの変更

passwd コマンドで root のパスワードを変更した場合は、その直後に chkey -p を実行する必要があります。chkey -p を実行しないと、root で正しくログインできなくなります。

root のパスワードの変更手順は以下のとおりです。

1. root でログインします。

2. passwd コマンドで root のパスワードを変更します。

   nispasswd は使用しないでください。

3. chkey -p を実行します。

   必ず -p オプションを使用します。

パスワードのロック

NIS+ 環境 (passwd コマンドと NIS+ 環境を参照) で passwd コマンドを使用してパスワードのロックができるのは、該当ユーザーの passwd テーブル中のエントリに対する変更権を持っている管理者 (グループのメンバー) です。パスワードがロックされると、そのアカウントは使用できなくなります。また、パスワードがロックされているユーザー名を使ってログインをしようとすると、「Login incorrect」というメッセージが表示されます。

該当ユーザーがすでにログインしている場合、パスワードをロックすることによる影響は現れないという点に注意してください。ただ、パスワードの入力が必要になる login、rlogin、ftp、telnet などの機能は使用できなくなります。

すでにログインしているユーザーのパスワードをロックしても、そのユーザーが passwd コマンドでパスワードを変更するとロックは解除されます。

以下のようなことが有効です。

• 休暇などで不在になっているユーザーのパスワードを一時的にロックする。他の人に不正に使用されることを防止できる

• セキュリティ上の問題が発生している可能性があれば、すぐに一部のユーザーのパスワードをロックする

• 解雇になったユーザーのパスワードをすぐにロックする。ユーザーのアカウントを削除するより速く容易に行える上、そのアカウントに格納されているデータをそのまま容易に保管できる

• UNIX プロセスにパスワードを設定している場合には、この種のパスワードもロックできる。パスワードがロックされてもプロセスの実行はできるが、プロセスを使用してログインすることは (たとえパスワードを知っていても) できなくなる。多くの場合、プロセスは NIS+ 主体の形では設定されない。しかしプロセスのパスワード情報は、/etc ディレクトリのファイルに保存される。このとき /etc に格納されたパスワードをロックするにはファイルモードで passwd コマンドを実行する必要がある。

パスワードのロックは以下のように行います。

passwd -l username

パスワードロックの解除

パスワードのロックは、パスワードを変更すれば解除されます。この場合、「変更」とは必ずしもパスワードを新しいものに変えるという意味ではなく、パスワード変更の手順を踏むということです (元とまったく同じパスワードに「変更する」ということも可能です)。ただし、新しいパスワードに変更することも可能です。

たとえば、jody というユーザーのパスワードのロックを解除するには、以下のように入力します。

station1% passwd jody

パスワードの使用期間に関する設定

設定により、パスワードの定期的な変更をユーザーに強制できます。

たとえば、以下のような設定が可能です。

• 次回のログインの際に強制的にパスワードを変更させる (詳細は、パスワードの強制的な変更を参照)

• パスワードの有効期間 (日数) を設定する (詳細は、パスワードの有効期間の設定を参照)

• パスワード作成後の変更禁止期間を設定する (詳細は、パスワードの変更禁止期間の設定を参照)

• パスワードの有効期間が終わる前に「パスワードが間もなく無効になる」という警告メッセージが (ログイン時に) 表示されるタイミングを設定する (詳細は、警告期間の設定を参照)

• ログインとログインの間隔の最大値 (日数) を指定する。指定された日数を超えてログインが行われないと、パスワードがロックされる (詳細は、ログインの間隔の最大値の指定を参照)

• パスワードの有効期限 (日付) を設定する。この日を過ぎると、該当ユーザーはシステムにログインできなくなる (詳細は、パスワード使用権の有効期限を参照)

さまざまな最大日数や期間に到達していても、それまでにすでにログインしているユーザーは、上記の機能には影響されないことを覚えておいてください。そのまま普通に動作し続けます。

影響が現れるのは、次回のログイン時か、ログインを必要とする機能 (以下に例を示す) を使用した時です。

• login

• rlogin

• telnet

• ftp

パスワードの使用期間に関する設定は、ユーザーごとに行います。パスワードの使用期間に関する必要条件はユーザーによって違っている可能性があります。ユーザーは、一般のデフォルト設定を適用することもできます。パラメータについての詳細については、パスワードの使用期間に関する設定を参照してください。

パスワードの強制的な変更

次回ログイン時のパスワード変更をユーザーに強制するには、以下の 2 種類の方法があります。

使用期間に関する設定を引き続き有効にする場合

passwd -f username

使用期間に関する設定を解除する場合

passwd -x 0 username

パスワードの有効期間の設定

パスワードの有効期間を設定するには、passwd コマンドの引数 max を使用します。有効期間は日数で指定します。有効期間が終了した後は、新しいパスワードをユーザーが作成しなければなりません。有効期間終了後に同じパスワードでログインしようとしても、「Your password has been expired for too long」というメッセージが表示され、新しいパスワードを作成しない限りログインを完了できません。

引数 max は以下の形式で使用します。

passwd -x max username 

引数の意味は、それぞれ以下のとおりです。

• username は、ユーザーのログイン ID

• max は、以下のうちいずれかになります。

  • 「0 より大きい値」は、パスワードの有効期間の日数

  • 「0」は、次回ログイン時のパスワード変更を強制する。使用期間に関する設定は解除される

  • 「-1」は、パスワードの使用期間に関する設定を解除します。つまり passwd -x -1 username と入力すると、使用期間に関して該当ユーザーに行われていた設定はすべて解除されます。

たとえば、schweik というユーザーに 45 日ごとのパスワード変更を強制するには、以下のように入力します。

station1% passwd -x 45 schweik

パスワードの変更禁止期間の設定

パスワード作成後の変更禁止期間を設定するには、引数 min を使用します。変更禁止期間が終了しないうちにパスワードを変更しようとすると、「Sorry less than N days since the last change」というメッセージが表示されます。

引数 min は以下の形式で使用します。

passwd -x max  -n min username

引数の意味は、それぞれ以下のとおりです。

• username は、ユーザーのログイン ID

• max は、パスワードの有効期間 (前のセクションを参照)

• min は、パスワード作成後の変更禁止期間

たとえば、ユーザー eponine のパスワードの有効期間を 45 日間、変更禁止期間を 7 日間に設定する場合は、以下のように入力します。

station1% passwd -x 45 -n 7 eponine

min 引数には以下の規則があります。

• min 引数は必ずしも使用しなくて良い (つまり、パスワード変更禁止期間は必ずしも指定しなくて良い)

• min 引数は、必ず -max 引数と組み合わせて使用する。つまり、変更禁止期間を設定するには、有効期間も設定する必要がある

• min に max より大きい値を設定すると (例：passwd -x 7 -n 8)、ユーザーはパスワードを変更できなくなる。変更しようとすると、「You may not change this password」というメッセージが表示される。min に max より大きな値を設定すると、次の 2 つの効果が得られる

  • ユーザーによるパスワードの変更を禁止する。つまり、管理特権を有する一部の人物以外は、パスワードを変更できなくなる。たとえば、複数のユーザーに共通のグループパスワードを割り当て、そのパスワードに対して min 値より大きな max 値を設定すると、グループ内のユーザーは誰一人としてパスワードを変更できなくなる

  • パスワードは max 値で設定される期限内のみ有効となる。しかも、min 値が max 値より大きいため、ユーザーはパスワードを変更できない。つまり、max 値の示す有効期限が満了する前にパスワードの期限延長を図る手だては、ユーザーには一切与えられない。実際、有効期限が満了した後は、管理者の介在なしにユーザーはログインできなくなる

警告期間の設定

パスワードの有効期限以前の一定期間、ログイン時に「Your password will expire in N days」(N は日数) というメッセージが表示されるようにするには、引数 warn を使用します。

たとえば、パスワードの有効期限が 30 日間 (引数 -max で指定する) で、warn が 7 に設定されている場合、パスワード作成後 24 日目のログイン時に「Your password will expire in 7 days」という警告メッセージが表示されます。また翌日 (パスワード作成後 25 日目) には、警告メッセージは「Your password will expire in 6 days」となります。

警告メッセージは、電子メールで送信されるものでも、ユーザーのコンソールウィンドウに表示されるものでもないという点に注意してください。表示されるのは、ユーザーのログイン時のみです。つまり指定の期間ユーザーがログインしなければ警告メッセージは表示されません。

warn の値は、max の値との「関連によって機能する」ものであるという点に注意してください。つまり、「max によって設定される有効期限から逆算されるもの」ということです。warn の値が 14 であれば、「Your password will expire in N days」というメッセージの表示が開始されるのは、有効期限の 2 週間前です。

warn の値は max の値との関連によって機能します。max 値の指定がある場合のみ有効です。そのため、max 値の指定がない場合は、warn 値は意味がなくなります。

引数 warn は以下の形式で使用します。

passwd -x max  -w   warn username

引数の意味は、それぞれ以下のとおりです。

• username は、ユーザーのログイン ID

• max は、パスワードの有効期限 (日数) (パスワードの有効期間の設定を参照)

• warn は、「有効期限の何日前から警告メッセージの表示を開始するか」を指定する

たとえば、nilovna というユーザーの、パスワードの有効期間を 45 日間とし、警告メッセージの表示を有効期限の 5 日前から開始する場合、以下のように入力します。

station1% passwd -x 45 -w 5 nilovna

warn 引数には以下の規則があります。

• warn 引数は必ずしも使用しなくて良い。warn の値を設定しなければ、警告メッセージは表示されない

• warn 引数は、必ず max 引数と組み合わせて使用する。つまり、警告メッセージの表示期間を指定するには、有効期間の指定が必要になる

Solstice AdminSuite を使用して、warm 値をユーザーのパスワード用に設定することもできます。

パスワードの使用期間に関する設定の解除

ユーザーのパスワードの有効期間を解除するには、以下の 2 つの方法があります。

有効期間を取り消す。パスワードはそのまま使用できる

passwd -x -1 username 

次回ログイン時にパスワードを強制的に変更させた後、有効期間を取り消す

passwd -x 0 username

上記の方法では、max の値を 0 か -1 に設定する (詳細については、パスワードの有効期間の設定を参照)

たとえば、ユーザー mendez のパスワードを次回ログイン時に強制的に変更させ、その後パスワードの有効期間を解除するには、以下のように入力します。

station% passwd -x 0 mendez

Solstice AdminSuite を使用して、このパラメータをユーザーのパスワード用に設定できます。

この値を設定するには、nistbladm コマンドを使用できます。たとえば、ユーザー otsu のパスワードの有効期間を取り消し、変更の必要がないようにするには、以下のように入力します。

station1% nistbladm -m `shadow=0:0:-1:0:0:0:0' [name=otsu],passwd.org_dir

nistbladm コマンドの使用方法の詳細については、nistbladm コマンドを参照してください。

パスワード使用権の有効期限

引数 expire には「ユーザーのパスワード使用権がいつ無効になるか」を日付で指定します。ユーザーのパスワード使用権が無効になると、そのユーザーは有効なパスワードを所有できなくなります。該当ユーザーのログインをこの日以降禁止し、システムから締め出します。

たとえば、ユーザー pete の有効期限を 1997 年 12 月 31 日に設定すると、どんなパスワードを使用しても 1998 年 1 月 1 日以降 pete という ID ではログインができなくなります。ログインをしようとしても、「Login incorrect」というメッセージが表示されます。

「有効期間」と「有効期限」の違い

パスワード使用権の有効期限は、パスワードの有効期間とは異なっています。

• 「パスワードの有効期間」。厳密に区別をする必要のない場合には、有効期間が終了した後も変更されないパスワードのことを「有効期限の過ぎたパスワード」と呼ぶことがあります。しかしこのパスワードは、もう一度だけログインに使用できます。ただしその際に変更を強制されます。

• 「パスワード使用権の有効期限」。ユーザーのパスワード「使用権」が無効になると、そのユーザーはすべてのパスワードでログインできなくなります。つまり、ネットワークにログインする権限の有効期限が切れたことになります。

有効期限の設定

パスワード使用権が無効になっても、その影響が現れるのは、該当ユーザーがログインをしようとするときだけです。該当ユーザーがすでにログインしていた場合には、パスワード使用権が無効になったことによる影響は現れません。ただし、rlogin、telnet などログインを必要とする機能は使用できなくなり、いったんログアウトするとログインできなくなります。以上のことから、パスワード使用権に有効期限を設ける場合、毎日のワークセッション終了時には必ずログアウトするようユーザー全員に指示してください。

Solstice AdminSuite ツールを使用して有効期限の設定ができるときは、nistbladm を使用しないでください。Solstice AdminSuite ツールの方が使いやすく、設定を誤る可能性が低くなります。

nistbladm コマンドでパスワード使用権の有効期限を指定するには、以下のように入力します。

nistbladm -m `shadow=n:n:n:n:n:n6:n' [name=login],passwd.org_dir

引数の意味は、それぞれ以下のとおりです。

• login は、ユーザーのログイン ID です。

• n は、シャドウ列の (n5 以外の) フィールドの値です。

• n6 は、ユーザーのパスワード使用権の有効期限 (日付) を設定します。「1970 年 1 月 1 日から数えて何日目か」で表します (表 16–2 を参照)。このフィールドに指定する値には、以下の 2 種類があります。

  • 「-1」は、有効期限の設定を解除します。ユーザーのパスワードがすでに有効期限を過ぎていても、-1 を設定することによって再び使用できるようになります。有効期限を設定したくないときは、初めから -1 を指定しておきます。

  • 「0 より大きい値」は、有効期限の日付 (「1970 年 1 月 1 日から数えて何日目か」) です。現在以前の日付を指定すると、ユーザーのパスワードはすぐに無効になります。

たとえば、ユーザー pete の有効期限を 1995 年 12 月 31 日に設定する場合は、以下のように入力します。

station1% nistbladm -m `shadow   =n:n:n:n:n:9493:n' \ 
[name=pete],passwd.org_dir 

空白のフィールドや、値の正しくないフィールドがあると機能しません。

パスワード使用権の有効期限の解除

有効期限を過ぎたパスワード使用権を再び使用できる状態にするには、nistbladm コマンドを使用して該当フィールド (n6) に -1 を指定します。例を以下に示します。

station1% nistbladm -m `shadow=   n:n:n:n:n:-1:n' \ 
[name=huck],passwd.org_dir

また、nistbladm で「n6」フィールドを将来の日付に設定し直すという方法も使用できます。

ログインの間隔の最大値の指定

引数 inactive には、「ログインからログインまでの間隔を最大何日あけることができるか」を指定します。この引数に指定された日数を超えてログインが行われなかった場合、該当ユーザーはマシンにログインできなくなります。ログインしようとすると、「Login incorrect」というメッセージが表示されます。

この設定はネットワーク全体ではなく、個々のマシンに対して行われます。したがって、NIS+ 環境においてログイン間隔の最大値を設定するには、該当ユーザーのエントリをホームドメインの passwd テーブルに指定します。この設定はネットワーク上のすべてのマシンで該当ユーザーに対して適用されます。

たとえば、ユーザー sam の最大ログイン間隔を 10 日間に設定した場合を考えてみましょう。sam は 1 月 1 日にマシン A とマシン B にログインをした後、ログアウトしました。続いて 3 日後の 1 月 4 日、sam はマシン B にログインした後ログアウトしました。さらに 9 日後の 1 月13日になると、sam はマシン B にはログインできますがマシン A にはログインできません。マシン B においては最終ログインから 9 日間しか経過していませんが、マシン A においては 13 日間が経過しているからです。

最大ログイン間隔の設定は、まだ一度もログインをしていないマシンには適用されないという点に注意してください。一度もログインをしていないマシンには、引数 inactive の設定および他のマシンへのログイン実績がどのようになっていようとログインが可能です。

「毎日の作業終了時には必ずログアウトをせよ」という指示がユーザーに対して行われていない場合、最大ログイン間隔の設定はしないでください。この設定はログインにだけ関係しており、他の形でシステムを使用する場合のことは考慮されていません。仮にユーザーが作業終了後もログインしたままの状態でシステムを放置しておくと、ログインが発生しないため指定のログイン間隔をすぐ超えてしまいます。指定のログイン間隔を超えた状態でリブートやログアウトをすると、再びログインできなくなります。

Solstice AdminSuite ツールを使用して最大ログイン間隔の設定ができるときは、nistbladm を使用しないでください。Solstice AdminSuite ツールの方が使いやすく、設定を誤る可能性が低くなります。

最大ログイン間隔の設定を nistbladm コマンドで行う場合は、以下の形式を使用します。

nistbladm -m `shadow= n:n:n:n:n5:n:n' [name=login], passwd.org_dir

引数の意味は、それぞれ以下のとおりです。

• login は、ユーザーのログイン ID です。

• n は、シャドウ列の (n5 以外の) フィールドの値です。

• n5 は、最大ログイン間隔 (日数) です。指定される値には、以下の 2 種類があります。

  • 「マイナス 1 (-1)」は、最大ログイン間隔機能を解除します。任意の日数の間オフにすることができ、ログイン権限を失うことはありません。これはデフォルトです。

  • 「0 より大きい値」は、最大ログイン間隔 (日数) を指定します。

たとえば、ユーザー sam の最大ログイン間隔を 7 日間に指定する場合は、以下のように入力します。

station1% nistbladm -m `shadow= n:n:n:n:n:7:n:n' [name=sam],passwd.org_dir 

最大ログイン間隔の設定を解除する (ログインできなくなったユーザーを再びログインできるようにする) には、nistbladm で inactive を -1 に指定します。

パスワードの使用規則の設定 (およびそのデフォルト)

パスワードの使用規則に関する設定およびそのデフォルトについて説明します。

/etc/defaults/passwd ファイル

パスワード情報の獲得先が nsswitch.conf ファイルで files に指定されているすべてのユーザーのパスワードについて、4 つのデフォルト設定を行うためのファイルです。/etc/defaults/passwd ファイルで行われたデフォルト設定は、/etc ディレクトリのファイルからパスワード情報を獲得しているユーザーにだけ適用されます。パスワード情報の獲得先が NIS マップあるいは NIS+ テーブルであるようなユーザーには適用されません。NIS+ サーバー上の /etc/defaults/passwd ファイルは、パスワード情報をローカルファイルから獲得しているローカルユーザーにだけ影響を与えます。NIS+ 環境または、nsswitch.conf ファイルでパスワード情報の獲得先が nis、nisplus に設定されているユーザーには影響を与えません。

/etc/defaults/passwd ファイルで行われる「パスワードに関する 4 つのデフォルト設定」とは、具体的には以下のものを指します。

• 有効期間 (週単位)

• 変更禁止期間 (週単位)

• 「パスワードが間もなく無効になる」という警告メッセージの表示される期間 (週単位)

• 最低文字数

/etc/defaults/passwd ファイルのデフォルト設定には、以下の規則があります。

• パスワード情報をローカルの /etc ファイルから得ているユーザーの場合、passwd コマンド、Solstice AdminSuite、admintool で個々に行われた設定の方が、/etc/defaults/passwd のデフォルト設定よりも優先します。つまり /etc/defaults/passwd ファイルのデフォルト設定は、passwd テーブル中のエントリで (/etc/defaults/passwd の設定に対応した) 個別の設定が行われていないユーザーにだけ適用されるということです。

• /etc/defaults/passwd ファイルのすべてのデフォルト設定は、パスワード長を除いて、週単位として表現されます。ただし、パスワードの有効期間は、日数として表現されます。

• MAXWEEKS、MINWEEKS、 および WARNWEEKS のデフォルト値は、 の最終変更日を起点として計算されます。ただし、各警告値は、有効期限を起点として逆算されます。

/etc/defaults/passwd ファイルには、デフォルトでは以下のエントリがすでに含まれています。

MAXWEEKS= 
MINWEEKS= 
PASSLENGTH=  

設定に必要な作業は、= の後に適切な数字を入力することだけです。= の後に数字が入っていないエントリは無効です。たとえば、MAXWEEKS に 4 を指定するには、以下のように入力します。

MAXWEEKS=4 
MINWEEKS= 
PASSLENGTH=  

有効期限 (週単位)

/etc/defaults/passwd ファイルの MAXWEEKS により、ユーザーのパスワードが有効な有効期限を週単位で設定できます。ユーザーのパスワードの有効期限を週単位で指定するためのエントリです。以下に示すとおり、"=" の後に適切な数字を入力するだけで指定ができます。

MAXWEEKS=N

N は週の数です。たとえば、MAXWEEKS=9 というようにします。

変更禁止期間 (週単位)

/etc/defaults/passwd ファイルの MINWEEKS デフォルト値には、ユーザーのパスワードの変更禁止期間を週単位で設定できます。パスワードの変更禁止期間を週単位で指定するためのエントリです。以下に示すとおり、"=" の後に適切な数字を入力するだけで指定ができます。

MINWEEKS=N

N は週の数です。たとえば、MINWEEKS=2 というようにします。

警告期間 (週単位)

/etc/defaults/passwd ファイルに WARNINWEEKS デフォルト値を追加し、パスワードの有効期間が切れて無効になる前に警告を表示する期間を、週単位で設定できます。たとえば、MAXWEEKS デフォルト値に 9 を設定したときに、パスワードが無効になる前の 2 週間に警告する場合は、MAXWEEKS に 7 を設定します。

MAXWEEKS のデフォルトを設定しない限り、WARNWEEKS のデフォルトを設定することはありません。

WARNWEEKS は、 MAXWEEKS に指定された有効期限ではなく、パスワードの最終変更日を起点と考えて設定することに注意してください。したがって WARNWEEKS に、MAXWEEKS 以上の値を設定することはできません。

WARNWEEKS のデフォルトは、MAXWEEKS のデフォルトも一緒に設定されていない限り無効です。

WARNWEEKS は、以下に示すとおり "=" の後に適切な数字を入力するだけで指定ができます。

WARNWEEKS=N

N は週の数です。たとえば、WARNWEEKS=1 というようにします。

最低文字数

passwd コマンドには、デフォルトで「パスワードの長さは 6 文字以上にする」という規則があります。しかし、/etc/defaults/passwd ファイルの PASSLENGTH を使用することによってこの規則を変更することが可能です。

パスワードの最低文字数を 6 以外の値にするには、以下に示すとおり PASSLENGTH= の後に適切な値を入力します。

PASSLENGTH=N

N は文字数です。たとえば、PASSLENGTH=7 というようにします。

パスワード変更時の制限

パスワード変更の際の入力試行回数と所要時間には、制限を設定できます。設定は rpc.nispasswdd デーモン起動時の引数で行います。

入力試行回数を制限したり、タイムウィンドウを設定したりすることにより、「権利のない人が、パスワードを試行錯誤で知ることのできるものに変えてしまう」という危険をある程度 (完璧ではない) 回避できます。

試行回数の制限

パスワード変更時の誤入力試行回数を制限するには、rpc.nispasswdd に -a number という引数 (number は試行回数) を指定します。rpc.nispasswdd を起動するには、NIS+ マスターサーバー上にスーパーユーザー特権が必要です。

誤入力試行回数を 4 に制限する (デフォルトは 3) 場合、以下のように入力します。

station1# rpc.nispasswdd -a 4

この場合、4 回目のパスワード入力が失敗すると、「Too many failures - try later」というメッセージが表示され、一定の時間が経過するまで該当ユーザーのパスワード変更はできなくなります。

所要時間の制限

パスワード変更時の所要時間 (ログインの所要時間) を制限するには、rpc.nispasswdd に -c minutes という引数 (minutes には時間を分単位で指定する) を指定します。rpc.nispasswdd を起動するには、NIS+ マスターサーバー上にスーパーユーザー特権が必要です。

たとえば、ユーザーが 2 分以内にログインしなければならないように設定するには、以下のように入力します。

station1# rpc.nispasswdd -c 2

この場合、2 分以内にパスワードの変更に成功しないとエラーメッセージが表示され、一定の時間が経過するまで該当ユーザーのパスワード変更はできなくなります。

第 17 章 NIS+ グループの管理

この章では、NIS+ グループとその管理方法について説明します。

NIS+ セキュリティグループのタスクには、Solstice AdminSuite ツールを利用するともっと簡単に実行できるものもあります。

NIS+ は、将来のリリースでサポートされない可能性があります。NIS+ から LDAP への移行支援ツールは、Solaris 9 オペレーティング環境で使用できます (『Solaris のシステム管理 (ネーミングとディレクトリサービス : DNS、NIS、LDAP 編)』を参照)。詳細については、http://www.sun.com/directory/nisplus/transition.html を参照してください。

Solaris グループ

Solaris/NIS+ 環境には、UNIX グループ、ネットグループ、NIS+ グループの 3 種類のグループがあります。

• 「UNIX グループ」。UNIX グループとは、特別な UNIX アクセス権を与えられたユーザーの集まりのことです。NIS+ 名前空間では、UNIX グループに関する情報は org_dir ディレクトリオブジェクト (group.org_dir) 内のグループテーブルに格納されます。UNIX グループのメンバーの追加、変更、または削除方法については、第 19 章「NIS+ テーブルの管理」を参照してください。

• 「ネットグループ」。ネットグループとは、他のマシン上でリモート操作を実行する権限を与えられているマシンとユーザーの集まりのことです。NIS+ 名前空間では、ネットグループに関する情報は org_dir ディレクトリオブジェクト (netgroup.org_dir) 内のグループテーブルに格納されます。ネット グループのメンバーの追加、変更、または削除方法については、第 19 章「NIS+ テーブルの管理」を参照してください。

• 「NIS+ グループ」。NIS+ グループとは、NIS+ オブジェクトに対する特別なアクセス権 (ネームスペースの管理を許されることが多い) を与えられている NIS+ ユーザーの集まりのことをいいます。NIS+ グループに関する情報は groups_dir ディレクトリオブジェクト内のテーブルに格納されます。

NIS+ グループ

NIS+ グループは、NIS+ オブジェクトに対するアクセス権を NIS+ の主体に割り当てるために考えられた概念です。(これらのアクセス権については、第 11 章「NIS+ のセキュリティの概要」を参照してください。NIS+ グループに関する情報は、NIS+ groups_dir ディレクトリオブジェクト内のテーブルに格納されます。各グループは個別のテーブルを持ち、グループ名とテーブル名はそれぞれ対応します。たとえば、admin グループに関する情報は admin.groups_dir テーブルに格納されます。

NIS+ グループを作成したら、どれか 1 つには admin という名前を付けることをお勧めします。そして、この admin グループには、NIS+ アクセス権を持たせるユーザーを割り当ててください。必ずしも admin という名前にしなければならないわけでもないのですが、NIS+ マニュアルでは、NIS+ 管理権限を持たせるユーザーのグループを admin と呼んでいます。異なるユーザーと異なる権限を組み合わせて複数の NIS+ グループを作成することもできます。

NIS+ グループのメンバー (ユーザー) の管理には、nisgrpadm コマンドを使います。グループテーブルの管理には、nisls コマンドと nischgrp コマンドを使います。グループテーブルに対して nistbladm コマンドを使うことはできないので注意してください。

NIS+ グループ関連のコマンドとその構文、オプションの詳細は、nis+(1) のマニュアルページを参照してください。

関連コマンド

nisgrpadm コマンドを使ってほとんどのグループ管理作業を実行できますが、グループ管理に関連するコマンドには次のものがあります。

以上のコマンドの詳細 (構文、オプションなど) は、nis+(1) のマニュアルページを参照してください。

NIS+ グループテーブルに対して nistbladm コマンドを使うことはできません。

NIS+ グループメンバーのタイプ

NIS+ グループには明示的 (explicit)、暗黙的 (implicit)、および再帰的 (recursive) という 3 タイプのメンバーがあります。またメンバー以外の主体にも、同様の 3 つのタイプがあります。メンバーのタイプは、メンバーを追加、削除する際に使用されます (nisgrpadm コマンドを参照)。

メンバーのタイプ

• 「明示的なもの」。個々の NIS+ 主体です。これらは、すべてのグループ管理コマンドで、主体名によって識別されます。主体名は、デフォルトドメインから入力される場合、完全指定名を使用する必要はありません。

• 「暗黙的なもの」。NIS+ ドメインに所属するすべての NIS+ 主体です。これらは、* 記号とドットで始まるドメイン名によって識別されます。選択した処理は、グループ内のすべてのメンバーに適用されます。

• 「再帰的なもの」。他の NIS+ グループのメンバーの、すべての NIS+ 主体です。これらは、@ 記号で始まる NIS+ グループ名によって識別されます。選択した処理は、グループ内のすべてのメンバーに適用されます。

NIS+ グループは、明示的、暗黙的、および再帰的の 3 つすべてのカテゴリでのメンバー以外も受け付けます。メンバー以外の主体とは、「メンバーになることができるが、指定によってグループから排除されているもの」を指します。

メンバー以外の主体のタイプ

メンバー以外の主体はマイナス記号で始まり、メンバー主体と区別されます。

• 「明示的なもの」- 名前の先頭に「-」だけをつけます。

• 「暗黙的なもの」-「-」の後に「*」、「.」をつけます。

• 「再帰的なもの」-「-」の後に「@」をつけます。

グループの構文

同じ主体について「グループに含まれる」という指定と「グループに含まれない」という指定があった場合、指定の順序に関係なく「含まれない」という指定が優先されます。たとえば、同じ主体について「グループに含まれる暗黙的なドメインのメンバーである」という指定と「グループに含まれない再帰的なグループのメンバーである」という指定の両方がある場合、後者の方が優先されます。

nisgrpadm コマンドを使用する場合、主体のタイプは表 17–2 のように指定します。

NIS+ グループについて niscat を使用する

niscat -o コマンドを使用して、NIS+ グループのオブジェクト属性を表示できます。

グループのオブジェクト属性を表示する方法

グループのオブジェクト属性を表示するには、そのグループが格納されている groups_dir ディレクトリへの読み取り権が必要です。ここでは、niscat -o とグループの完全指定名を使用します。この完全指定名には、次に示すようにその groups_dir サブディレクトリを含んでいなければなりません。

niscat -o group-name.groups_dir.domain-name

たとえば :

rootmaster# niscat -o sales.groups_dir.doc.com. 
Object Name : sales
Owner : rootmaster.doc.com.
Group : sales.doc.com.
Domain : groups_dir.doc.com.
Access Rights : ----rmcdr---r---
Time to Live : 1:0:0
Object Type : GROUP
Group Flags :
Group Members : rootmaster.doc.com.
  topadmin.doc.com.
  @.admin.doc.com.
  *.sales.doc.com. 

nisgrpadm -1 コマンドを使うと、メンバーリストはさらに整理されて表示されます。

グループ属性のいくつかは、環境変数 NIS_DEFAULTS から継承されます。ただし、このグループの作成時に環境変数が無効になっている場合を除きます。Group Flags フィールドは、現在使用されていません。グループメンバーのリストでは、* 記号はメンバーのドメインを、@ 記号はメンバーのグループをそれぞれ示します。

nisgrpadm コマンド

nisgrpadm コマンドは、NIS+ グループを作成したり、削除したり、さまざまな管理作業を実行します。nisgrpadm コマンドを使用するには、操作に必要なアクセス権を取得しなければなりません。

nisgrpadm には、グループ作業用とグループメンバー作業用に 2 つの形式があります。

グループの作成または削除、あるいはメンバーの表示

nisgrpadm -c group-name.domain-name
nisgrpadm -d group-name
nisgrpadm -l group-name

メンバーの追加または削除、あるいはメンバーがグループに所属するかどうかの判定 (member... には、表 17–2 に示した、6 種類のメンバーのどのような組み合わせでも指定できます)。

nisgrpadm -a group-name member... 
nisgrpadm -r group-name member...
nisgrpadm -t group-name member...

作成 (-c) 以外のすべての処理には、部分指定名 group-name を使用できます。ただし、-c オプションの場合でも、nisgrpadm では group-name 引数に groups_dir を使用する必要はありません。実際これは受け付けられません。

NIS+ グループを作成する

NIS+ グループを作成するには、グループのドメインの groups_dir ディレクトリに対する作成権が必要です。-c オプションと完全指定グループ名を使用します。

nisgrpadm -c group-name.domainname

グループを作成すると、指定した名前の NIS+ グループテーブルが groups_dir に作成されます。nisls コマンドを使うと、対応するテーブルが groups_dir に作成されているかどうかを確認できます。また、niscat コマンドを使うと、そのテーブル中のグループメンバーを一覧表示できます。

新しく作成したグループにはメンバーがありません。どのメンバーをどのグループに追加するかについては、NIS+ グループにメンバーを追加するを参照してください。

次の例では、admin という名前の 3 つのグループを作成します。最初のグループは、doc.com. ドメインに作成します。 2 番目のグループは、sales.doc.com. ドメインに作成します。3 番目のグループは、manf.doc.com. に作成します。これらはすべて、それぞれのドメインのマスターサーバーから作成されます。

rootmaster# nisgrpadm -c admin.doc.com.
Group admin.doc.com. created.
salesmaster# nisgrpadm -c admin.sales.doc.com.
Group admin.sales.doc.com. created.
manfmaster# nisgrpadm -c admin.manf.doc.com. 
Group admin.manf.doc.com. created.

作成されるグループは、変数 NIS_DEFAULTS で指定されたオブジェクト属性をすべて継承します。つまり、その所有者、所有グループ、アクセス権、生存期間、および検索パスです。これらのデフォルトを表示するには、nisdefaults コマンドを使用します (第 15 章「NIS+ のアクセス権の管理」を参照)。オプションなしで使用すると、次のように出力されます。

rootmaster# nisdefaults
Principal Name : rootmaster.doc.com.
Domain Name : doc.com.
Host Name : rootmaster.doc.com.
Group Name :
Access Rights : ----rmcdr---r---
Time to live : 12:0:0
Search Path : doc.com.

所有者は Principal Name: フィールドに表示されます。所有者グループは、環境変数 NIS_GROUP を設定した場合にだけ表示されます。たとえば、C シェルを想定して NIS_GROUP を fns_admins.doc.com に設定する場合は、次のように入力します。

rootmaster# setenv NIS_GROUP fns_admins.doc.com

もちろん、グループの作成時に -D オプションを使用することによって、これらのデフォルトはどれでも変更できます。

salesmaster# nisgrpadm -D group=special.sales.doc.com.-c 
admin.sales.doc.com. Group admin.sales.doc.com. created.

NIS+ グループを削除する

NIS+ グループを削除するには、グループのドメイン内の groups_dir ディレクトリに対する削除権が必要です。-d オプションを使用します。

nisgrpadm -d group-name

デフォルトドメインが正しく設定されている場合、完全指定グループ名を使用する必要はありません。ただし、別のドメイン内のグループを誤って削除しないように、まず (nisdefaults を使用して) チェックしなければなりません。次の例では test.sales.doc.com. グループを削除します。

salesmaster% nisgrpadm -d test.sales.doc.com.
Group test.sales.doc.com. destroyed.

NIS+ グループにメンバーを追加する

NIS+ グループにメンバーを追加するには、グループオブジェクトに対する変更権が必要です。-a オプションを使用します。

nisgrpadm -a group-name members. . .

NIS+ グループメンバーのタイプの記述どおり、主体 (明示的なメンバー)、ドメイン (暗黙的なメンバー)、およびグループ (再帰的なメンバー) を追加できます。デフォルトドメインに所属するメンバー名またはグループ名は、完全指定する必要がありません。この例では、デフォルトドメイン sales.doc.com. の NIS+ 主体 panza と valjean、および manf.doc.com. ドメインの主体 makeba を top-team.sales.doc.com. グループに追加します。

client% nisgrpadm -a Ateam panza valjean makeba.manf.doc.com. 
Added panza.sales.doc.com to group Ateam.sales.doc.com
Added valjean.sales.doc.com to group Ateam.sales.doc.com
Added makeba.manf.doc.com to group Ateam.sales.doc.com

この動作を確認するには、nisgrpadm -l オプションを使用します。「明示的なメンバー」のカテゴリにあるメンバーを探してください。

次の例では、doc.com. ドメイン内のすべての NIS+ 主体を staff.doc.com. グループに追加します。 これは doc.com. ドメイン内のクライアントから入力します。ドメイン名の前にある * 記号とドットに注意してください。

client% nisgrpadm -a Staff *.doc.com.
Added *.doc.com. to group Staff.manf.doc.com.

次の例では、NIS+ グループ admin.doc.com. を admin.manf.doc.com. グループに追加します。 これは manf.doc.com. ドメインのクライアントから入力します。グループ名の前にある @ 記号に注意してください。

client% nisgrpadm -a admin @admin.doc.com. 
Added @admin.doc.com. to group admin.manf.doc.com.

NIS+ グループのメンバーを表示する

NIS+ グループのメンバーを表示するには、グループオブジェクトに対する読み取り権が必要です。-l オプションを使用します。

nisgrpadm -l group-name 

次の例では、admin.manf.doc.com. グループのメンバーを表示します。これは manf.doc.com. グループ内のクライアントから入力します。

client% nisgrpadm -l admin
Group entry for admin.manf.doc.com. group:
  No explicit members
  No implicit members:
  Recursive members:
  @admin.doc.com.
  No explicit nonmembers
  No implicit nonmembers
  No recursive nonmembers

NIS+ グループからメンバーを削除する

NIS+ グループからメンバーを削除するには、グループオブジェクトに対する変更権が必要です。-l オプションを使用します。

nisgrpadm -r group-name members. . .

次の例では、Ateam.sales.doc.com グループから NIS+ 主体 allende と hugo.manf.doc.com. を削除します。 これは sales.doc.com.domain ドメイン内のクライアントから入力します。

client% nisgrpadm -r Ateam allende hugo.manf.doc.com. 
Removed allende.sales.doc.com. from group Ateam.sales.doc.com.
Removed hugo.manf.doc.com. from group Ateam.sales.doc.com.

次の例では、admin.manf.doc.com. グループから admin.doc.com. グループを削除します。 これは manf.doc.com. ドメイン内のクライアントから入力します。

client% nisgrpadm -r admin @admin.doc.com.
Removed @admin.doc.com. from group admin.manf.doc.com.

NIS+ グループのメンバーかどうかを調べる

ある NIS+ 主体が特定の NIS+ グループのメンバーであるどうかを調べるには、そのグループオブジェクトに対する読み取り権が必要です。-t オプションを使用します。

nisgrpadm -t group-name members. . .

次の例では、NIS+ 主体 topadmin が admin.doc.com. グループに所属するかどうかを調べます。 これは doc.com. ドメイン内のクライアントから入力します。

client% nisgrpadm -t admin topadmin
topadmin.doc.com. is a member of group admin.doc.com.

次の例では、sales.doc.com. ドメインの NIS+ 主体 jo が admin.sales.doc.com. グループに所属するかどうかを調べます。 これは doc.com. ドメイン内のクライアントから入力します。

client% nisgrpadm -t admin.sales.doc.com. jo.sales.doc.com. 
jo.sales.doc.com. is a member of group admin.sales.doc.com. 

第 18 章 NIS+ ディレクトリの管理

この章では、NIS+ ディレクトリ オブジェクトとその管理方法について説明します。

NIS+ は、将来のリリースでサポートされない可能性があります。NIS+ から LDAP への移行支援ツールは、Solaris 9 オペレーティング環境で使用できます (『Solaris のシステム管理 (ネーミングとディレクトリサービス : DNS、NIS、LDAP 編)』を参照)。詳細については、http://www.sun.com/directory/nisplus/transition.html を参照してください。

NIS+ ディレクトリ

NIS+ ディレクトリオブジェクトには、NIS+ ドメインに関連する情報が格納されます。NIS+ ドメインには、それぞれ NIS+ ディレクトリ構造が関連付けられます。NIS+ ディレクトリの詳細については、第 2 章「NIS+ の紹介」を参照してください。

NIS+ ディレクトリ関連のコマンドとその構文、オプションについては、nis+(1) のマニュアルページを参照してください。

ディレクトリに対して niscat コマンドを使用する

niscat -o コマンドを使えば、NIS+ ディレクトリのオブジェクト属性を表示できます。このコマンドを使うには、ディレクトリオブジェクトの読み取り権が必要です。

ディレクトリのオブジェクト属性を表示する

ディレクトリのオブジェクト属性を表示するには、niscat -o とディレクトリ名を使います。

niscat -o directory-name

たとえば :

rootmaster# niscat -o doc.com.
Object Name : doc
Owner : rootmaster.doc.com.
Group :
Domain : Com.
Access Rights : r---rmcdr---r---
Time to Live : 24:0:0
Object Type : DIRECTORY
.
.

nisls コマンドでディレクトリを表示する

nisls コマンドは、NIS+ ディレクトリの内容を表示します。このコマンドを使うには、ディレクトリオブジェクトに対する読み取り権が必要です。

簡潔形式での表示

nisls [-dgLmMR] directory-name

詳細形式での表示

nisls -l [-gm] [-dLMR] directory-name

ディレクトリの内容を表示する (簡潔形式)

ディレクトリ内容をデフォルトの短形式で表示するには、次に示すオプションの内の 1 つまたは複数と、ディレクトリ名を使います。ディレクトリ名を指定しない場合、NIS+ はデフォルトのディレクトリを使います。

nisls [-dLMR] directory-name

または

nisls [-dLMR]

たとえば、次の nisls の場合は、ルートドメイン doc.com. のルートマスターサーバーから入力します。

rootmaster% nisls doc.com.:
org_dir
groups_dir 

次に、ルートマスターサーバーから入力した例をもう 1 つ示します。

rootmaster% nisls -R sales.doc.com.
sales.doc.com.:
org_dir
groups_dir
groups_dir.sales.doc.com.:
admin
org_dir.sales.doc.com.:
auto_master
auto_home
bootparams
cred
.

ディレクトリの内容を表示する (詳細形式)

ディレクトリの内容を詳細形式で表示するには -l オプション、および次に示すオプションのうちの 1 つまたは複数を使います -g と -m のオプションは、表示される属性を変更します。ディレクトリ名を指定しない場合、NIS+ はデフォルトのディレクトリを使います。

nisls -l [-gm] [-dLMR] directory-name

または

nisls -l [-gm] [-dLMR]

次に示すのは、ルートドメイン doc.com. のマスターサーバーから入力した例です。

rootmaster% nisls -l
doc.com.
D r---rmcdr---r--- rootmaster.doc.com. date org_dir
D r---rmcdr---r--- rootmaster.doc.com. date groups_dir

nismkdir コマンド

この節では、nismkdir コマンドを使用して既存のドメインに非ルートサーバーを追加する方法を説明します。 nisserver スクリプトを使用すれば、より簡単に追加できます。方法については、第 4 章「スクリプトを使用した NIS+ の設定」を参照してください。

nismkdir コマンドは、ルート以外の NIS+ ディレクトリを作成し、これをマスターサーバーに関連付けます。ルートディレクトリを作成するには、nisinit コマンドで説明する nisinit -r コマンドを使います。nismkdir コマンドを使って、複製サーバーを既存のディレクトリに追加できます。

NIS+ ディレクトリを作成するには、いくつかの関連作業のほかに、いくつかの前提条件があります。

ディレクトリを作成するには、以下のように入力します。

nismkdir [-m master-server]  directory-name

複製を既存のディレクトリに追加するには、以下のように入力します。

nismkdir -s replica-server  directory-name
nismkdir -s replica-server  org_dir.directory-name
nismkdir -s replica-server groups_dir.directory-name 

ディレクトリを作成する

ディレクトリを作成するには、(ドメインのマスターサーバー上の) 親ディレクトリに対する作成権が必要です。まず -m オプションを使ってマスターサーバーを定義し、次に -s オプションを使って複製を定義します。

nismkdir -m master  directory
nismkdir -s replica  directory

nismkdir は必ず (複製サーバーではなく) マスターサーバー上で実行してください。nismkdir を複製サーバー上で実行すると、マスターサーバーおよび複製サーバー間の通信に問題が発生します。

この例では、sales.doc.com. ディレクトリを作成してから、そのマスターサーバー smaster.doc.com. と複製サーバー rep1.doc.com. を指定します。これはルートマスターサーバーから入力します。

rootmaster% nismkdir -m smaster.doc.com. sales.doc.com. 
rootmaster% nismkdir -m smaster.doc.com. org_dir.sales.doc.com.
rootmaster% nismkdir -m smaster.doc.com. groups_dir.sales.doc.com.
rootmaster% nismkdir -s rep1.doc.com. sales.doc.com.
rootmaster% nismkdir -s rep1.doc.com. org_dir.sales.doc.com.
rootmaster% nismkdir -s rep1.doc.com. groups_dir.sales.doc.com.

小規模またはテスト用の名前空間でないかぎりは推奨しませんが、nismkdir コマンドを使えば、独自のディレクトリを指定する代わりに、新しいディレクトリとして親ディレクトリのサーバーを使えます。次に 2 つの例を示します。

• 最初の例では、sales.doc.com. ディレクトリを作成し、これをその親ディレクトリのマスターと複製サーバーに関連付けます。

  rootmaster% nismkdir sales.doc.com

2 番目の例では、sales.doc.com. ディレクトリを作成し、独自のマスターサーバーである smaster.doc.com. を指定します。

rootmaster% nismkdir -m smaster.doc.com. sales.doc.com. 

複製サーバーは指定されないため、nismkdir を再び使用して複製を割り当てるまでは、新しいディレクトリにはマスターサーバーしかありません。sales.doc.com. ドメインがすでに存在する場合は、上記のように nismkdir コマンドを実行すると、salesmaster.doc.com. が新しいマスターサーバーになり、古いマスターサーバーは複製サーバーに格下げされます。

複製サーバーを既存のディレクトリに追加する

この章では nismkdir コマンドを使用して複製サーバーを既存のシステムに追加する方法を説明します。nisserver スクリプトを使用すると、より簡単に追加できます。

以下の点に注意してください。

• ルートドメインサーバーはルートドメイン (またはその一部) に置く

• サブドメインサーバーは、サブドメインの 1 つ上の階層の親ドメイン (またはその一部) に置く。たとえば、名前空間に prime という名前のルートドメインと sub1 という名前のサブドメインがある場合は、次のようになる

  • prime ドメインにサービスを提供するマスターサーバーと複製サーバーは、prime がルートドメインであるため、prime ドメインの一部になる

  • sub1 サブドメインにサービスを提供するマスターサーバーと複製サーバーも、prime が sub1 の親ドメインであるため、prime ドメインの一部になる

• マスターサーバーまたは複製サーバーから複数のドメインにサービスを提供することもできるが、そのような措置は避けた方がよい

新しい複製サーバーを既存のディレクトリに割り当てるには、-s オプションと、既存のディレクトリ名を使います。