パート III NIS+ の管理

パート III では NIS+ の名前空間の管理方法を説明します。

• 第 7 章「NIS+ 資格の管理」

• 第 8 章「NIS+ 鍵の管理」

• 第 9 章「拡張セキュリティ資格の管理」

• 第 10 章「NIS+ のアクセス権の管理」

• 第 11 章「パスワードの管理」

• 第 12 章「NIS+ グループの管理」

• 第 13 章「NIS+ ディレクトリの管理」

• 第 14 章「NIS+ テーブルの管理」

• 第 15 章「サーバー使用のカスタマイズ」

• 第 16 章「NIS+ のバックアップと復元」

• 第 17 章「NIS+ の削除」

第 7 章 NIS+ 資格の管理

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

• 「資格の機能」

• 「資格と資格情報」

• 「認証」

• 「主体の認証方法」

• 「DES 資格の詳細」

• 「資格関連情報の格納場所」

• 「cred テーブルの詳細」

• 「資格情報の作成」

• 「nisaddcred コマンド」

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

• 「Secure RPC ネット名と NIS+ 主体名」

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

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

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

• 「資格情報を削除する方法」

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

NIS+ 資格について

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

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

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

資格の機能

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

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

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

NIS+ 名前空間のセキュリティ保全のために、NIS+ 資格および認証機能がどのように承認およびアクセス権を使用するかについては、第 6 章「セキュリティの概要」を参照してください。

資格と資格情報

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

• 「資格情報」

  DES 資格を作成するのに使われるデータであり、サーバーが当該資格をチェックするのに使われる

• 「DES 資格」

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

認証

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

• 「主体の DES 資格情報」

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

  • 「主体名」

    ユーザーの完全ログイン ID もしくはマシンの完全ホスト名

  • 「主体の Secure RPC ネット名」

    各主体はユニークな Secure RPC ネット名を持っています (Secure RPCネット名の詳細は、「DES 資格の Secure RPC ネット名」を参照)

  • 「主体の公開鍵」

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

• 「主体の LOCAL 資格」

• 「サーバーの公開鍵」

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

• 「主体の公開鍵のキーサーバーの複製」

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

主体の認証方法

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

• 「準備フェーズ」

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

• 「ログインフェーズ」

  ユーザーがログインした時にシステムが行う動作

• 「要求フェーズ」

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

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

資格準備フェーズ

NIS+ 管理者がユーザーに資格情報を作成する最も容易な方法は、『Solaris ネーミングの設定と構成』に述べられている、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 資格情報を持っていた場合、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 資格の作成方法

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

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

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

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

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

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

図 7-2 DES 資格の作成

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

主体のログインパスワードがユーザーの Secure RPC パスワードと異なる場合、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 コマンド」と 「資格に関する情報が古くなっている」の項を参照)。

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

資格関連情報の格納場所

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

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

cred テーブルの詳細

主体の資格情報は「cred テーブル」に格納されています。cred テーブルは NIS+ が標準で持つ 16 のテーブルの 1 つです。各ドメインに cred テーブルが 1 つあり、そのドメインに属しているクライアントワークステーションとログインを許されたクライアントユーザー (そのドメインの主体) の資格情報が格納されています。cred テーブルはそれらドメインの org_dir サブディレクトリにあります。

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

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

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

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

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

• 「LOCAL」

  認証種類が LOCAL の場合、他の列は主体のユーザー名、UID、および GID となり、最後の列は空白になります。

• 「DES」

  認証種類が DES の場合、他の列は主体の Secure RPC ネット名、公開鍵、および暗号化された非公開鍵となります。これらの鍵は、他の情報と共に DES 資格を暗号化したり、復号化するのに使われます。

資格情報の作成

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

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

• nisclient スクリプトを使用します。1 つの主体の資格を容易に作成し変更できます。便利な方法なので、個々の資格を管理する方法として推奨します。『Solaris ネーミングの設定と構成』のパート I「ネーミングの紹介」に nisclient スクリプトを使用して資格情報を作成する方法を示しています。

• nispopulate スクリプトを使用します。これはすでに NIS+ マップもしくは /etc ファイルに資格情報を格納してある１つ以上の主体の資格を作成変更する便利な方法です。これは、NIS+ 主体グループの資格を管理する方法として推奨します。『Solaris ネーミングの設定と構成』のパート I「ネーミングの紹介」に nispopulate スクリプトを使用して資格情報を作成する方法を示しています。

• 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 コマンドを使って資格情報を作成する方法

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 パスワードで暗号化された後に非公開データに置かれます。

図 7-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 が必要です。ワークステーションを識別する場合は、ワークステーションのホスト名が必要です (nisaddcred コマンドとともに使用する場合は、常に -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 の使い方 - 例

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

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

rootmaster#nisaddcred -p unix.119@doc.com -P eiji.doc.com. des
Adding key pair for unix.119@doc.com (eiji.doc.com.).

Enter eiji's login password:  
nisaddcred: WARNING: password differs from login passwd

rootmaster%chkey -p
Updating nisplus publickey database
Generating new key for'unix.119@doc.com'.

まず、通常の方法で 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 で、ルートドメインに所属しています。したがって、この資格はルートマスターサーバーから作成されます。この例では、ルートマスターにルートとしてログインしている間に資格情報を作成します。しかし、有効な資格情報と適切なアクセス権をすでに持っている場合、自分のユーザー名でログインしているときに、資格を作成できます。

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 の詳細は、第 14 章「NIS+ テーブルの管理」を参照してください。

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

第 8 章 NIS+ 鍵の管理

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

• 「キーログイン」

• 「NIS+ 主体の鍵の変更」

• 「公開鍵の更新」

• 「nisupdkeys コマンド」

• 「公開鍵の引数の更新と例」

• 「IP アドレスの更新」

Solstice AdminSuite ツールを利用した方が容易に NIS+ セキュリティタスクを実行できます。

NIS+ 鍵について

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

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

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

キーログイン

主体がログインする時、パスワードの入力を求めるプロンプトが現れます。このパスワードはユーザーがセキュリティゲートをパスし、ネットワークにアクセスするために必要なものです。ログインプロセスは、ユーザーのホームドメインの 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 を実行し、次に chkey -p を実行します。表 8-1 では、主体ユーザーの keylogin と chkey の実行方法を示します。

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

鍵の変更

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

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

ルートからルート鍵を変更する

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

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

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

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

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

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

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

othermachine% nisaddcred -p principal -P nisprincipal des

othermachine% nisupdkeys dirs

othermachine% keylogin -r

othermachine% nisinit -cH

• 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 を使用してディレクトリオブジェクト内の古い公開鍵を更新できます。

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

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

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

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

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

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

公開鍵の引数の更新と例

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

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

rootmaster# /usr/lib/nis/nisupdkeys
Fetch Public key for server rootmaster.doc.com.
netname='unix.rootmaster@doc.com'
Updating rootmaster.doc.com.'s public key.
Public key: public-key

IP アドレスの更新

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

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

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

rootmaster# nisupdkeys -a  domain

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

rootmaster# nisupdkeys -a -H  server

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

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

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

• 最も簡単に個々のクライアントの鍵情報を更新するには、クライアント側で nisclient スクリプトを実行します。『Solaris ネーミングの設定と構成』を参照してください。

• 別の方法で個々のクライアントの鍵情報を更新するには、クライアント側で 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 コマンド」を参照してください。

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

• 「Diffie-Hellman 拡張鍵」

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

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

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

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

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

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

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

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

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

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

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

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

• 「アクセス権の連鎖」

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

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

• 「アクセス権の格納場所」

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

• 「デフォルトのアクセス権」

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

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

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

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

• 「デフォルトを無効にする」

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

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

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

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

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

NIS+ アクセス権

NIS+ アクセス権とは、どの NIS+ ユーザーがどの操作を行うことができるか、どの情報にアクセスすることができるかを決めたものです。ここでの説明は、読者が NIS+ セキュリティシステム全般に関する知識を有し、NIS+ セキュリティシステムにおけるアクセス権の役割を理解していることを前提としています (詳細は第 6 章「セキュリティの概要」を参照)。

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

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

承認とアクセス権が NIS+ 資格および認証とどのように関連して NIS+ 名前空間のセキュリティを維持しているかについては、「NIS+ の承認とアクセス - 紹介」および第 6 章「セキュリティの概要」を参照してください。

承認クラス - 復習

「承認クラス」に説明のあるように、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 オプションはいくつかの NIS+ コマンドに用いられます。NIS+ オブジェクトを作成するコマンドに -D オプションを使用すると、NIS_DEFAULTS 環境変数が指定したデフォルト権限を上書きします。(詳細は、「デフォルトを無効にする」を参照してください。

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

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

• nischmod コマンド

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

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

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

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

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

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

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

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

• 「テーブル」

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

  ---

  注 -

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

  ---

• 「列」

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

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

  列のグループはテーブルのグループやエントリのグループと同じにはなりません。これらはまったく異なるグループです。

• 「エントリ (行)」

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

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

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

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

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

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

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

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

異なるレベルの権限

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

種々の権限とレベルに関係した機能を次の表 10-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 文字はその他に、それぞれ与えられたアクセス権を表します。

図 10-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 は次のデフォルト値を指定します。

• 所有者

• グループ

• アクセス権

• 生存期間

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

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

• owner=所有者名

• group=グループ名

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

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

表 10-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 オプションの詳細は、第 14 章「NIS+ テーブルの管理」を参照してください。

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

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

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

• column は列名です。

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

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

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

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

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

(このオプションの完全な構文については、「nistbladm コマンド」を参照してください。)

次の例は、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.' 

第 11 章 パスワードの管理

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

• 「ログイン」

• 「Login incorrect メッセージ」

• 「password expired メッセージ」

• 「will expire メッセージ」

• 「Permission denied メッセージ」

• 「パスワードの変更」

• 「パスワードの選択」

• 「nsswitch.conf ファイルの必要条件」

• 「nispasswd コマンド」

• 「yppasswd コマンド」

• 「passwd コマンド」

• 「nistbladm コマンド」

• 「関連コマンド」

• 「パスワード情報の表示」

• 「パスワードの変更」

• 「パスワードのロック」

• 「パスワードの使用期間に関する設定」

• 「パスワードの強制的な変更」

• 「パスワードの変更禁止期間の設定」

• 「パスワードの有効期間の設定」

• 「警告期間の設定」

• 「パスワードの使用期間に関する設定の解除」

• 「パスワード使用権の有効期限」

• 「ログインの間隔の最大値の指定」

• 「パスワードの使用規則の設定 (およびそのデフォルト) 」

• 「/etc/defaults/passwd ファイル」

• 「パスワード変更時の制限」

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

パスワードの使用

マシンへのログインの際には、ユーザー名 (「ログイン 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」メッセージが表示される場合は、システム管理者に問い合わせてください。

password expired メッセージ

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

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

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

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

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

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

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

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

will expire メッセージ

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

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

Permission denied メッセージ

ログイン ID およびパスワードを入力したあと、このメッセージが表示されて 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 で正常にログインできなくなります。

   ---

パスワード変更の失敗

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

パスワード変更、ログインの試行回数、または所要時間が指定の範囲を超えた場合は、「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 が Claire2 の場合、たとえば e2clair をパスワードとして使用できません。

• 「古いパスワードと同じにならないようにします」。古いパスワードを、少なくとも 3 文字以上入れ替える必要があります (この場合、大文字と小文字は同じものとして考える)。古いパスワードが Dog#fooD なら、新しいパスワードにたとえば dog#Meat は使用できますが、daT#Food は使用できません。

悪いパスワードの例

悪いパスワードの例としては以下のようなものが考えられます。

• 自分の名前をもとにしたもの

• 家族やペットの名前

• 運転免許証の番号

• 電話番号

• 社会保険の番号

• 従業員番号

• 趣味に関係のある名前

• 季節に関係のある名前 (たとえば 12 月に Santa を使うなど)

• 普通の辞書に載っている単語

普通に使われる言葉をそのままパスワードに使用しないようにします。辞書に載っていたら使えないものと思ってください。

良いパスワードの例

良いパスワードの例としては以下のようなものが考えられます。

• フレーズに数字や記号を加えたもの (例：beam#meup)

• フレーズを構成する単語の頭文字に番号や記号を加えた意味のない言葉 (例：SomeWhere Over The RainBow の頭文字に 7 を加えた swotrb7)

• 単語の一部を数字や記号に置き換えたもの (例：snoopy ではなく、sn00py にする)

パスワードの管理

ここでは、NIS+ 名前空間の中でパスワードを管理する方法について説明します。この説明は、読者が NIS+ セキュリティシステム全般に関する知識を有し、NIS+ セキュリティシステムにおけるログインパスワードの役割を理解していることを前提としています (詳細は、第 6 章「セキュリティの概要」を参照)。

現在の 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: compat

  passwd_compat: nisplus

ネットワーク上のすべてのワークステーションの nsswitch.conf ファイルで、上記の passwd エントリの設定のうちいずれかを使用する必要があります。上記の 5 つ以外の設定をすると、ログインができなくなります。

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) 日が経過した後は、ログインの度に「パスワードが間もなく無効になる」という警告メッセージが表示されます (詳細は、「警告期間の設定」を参照)。

  この値としては以下の 2 とおりが考えられます。

  • 「0」は、警告メッセージが表示される期間がないことを示します。

  • 「0 より大きい値」は、この数字が、パスワードが作成されてから警告メッセージが表示されるまでの期間 (日数) になります。

• 「n5 間隔」は、ログインとログインの間隔 (日数) の最大値です。ここで指定された日数を超える期間ログインを行わないと、ログインができなくなります。たとえば、間隔に 6 を指定した場合、6 日間ログインを行わないと 7 日目にはログインができなくなります (詳細は、「ログインの間隔の最大値の指定」を参照)。

  この値としては以下の 2 とおりが考えられます。

  • 「-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 日目という設定にするには、以下のように入力します。

master# nistbladm -m shadow=9246:7:30:5:15:9255:0 [name=amy], passwd.ord_dir

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 コマンドと類似の機能を持つコマンドは他にもあります。それぞれについて表 11-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

パスワードの使用期間に関する設定は、ユーザーごとに行います。パスワードの使用期間に関する必要条件はユーザーによって違っている可能性があります。ユーザー一般にデフォルト設定を適用することもできます。詳細は、「/etc/defaults/passwd ファイル」を参照してください。

パスワードの強制的な変更

次回ログイン時のパスワード変更をユーザーに強制するには、以下の 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 の指定がない場合は意味がなくなります。

引数 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 は、シャドウ列の (n6 を除くフィールドの) 値です。

• n6 は、ユーザーのパスワード使用権の有効期限 (日付) を設定します。「1970 年 1 月 1 日から数えて何日目か」で表します (表 11-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 テーブルに指定します。この設定はネットワーク上のすべてのマシンで該当ユーザーに対して適用されます。しかし、最後にログインをした日付はマシンごとに異なるため、個別に (各マシンの /var/adm/utmp ファイルに) 記録されます。

たとえば、ユーザー 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」は、デフォルト設定です。最大ログイン間隔の設定を解除します。この設定の場合、ログインされない期間が何日続いてもパスワード使用権が失われることはありません。

  • 「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 の設定に対応した) 個別の設定が行われていないユーザーにだけ適用されるということです。

• パスワードの長さを除き、すべての設定は週単位で行われます (個々のパスワードの使用期間についての設定は、日単位で行われていた点に注意)

• MAXWEEKS、MINWEEKS、WARNWEEKS は、パスワードの最終変更日を起点として設定します (nistbladm などでは warn の起点を max としていた点に注意)。

/etc/defaults/passwd ファイルには、デフォルトでは以下のエントリがすでに含まれています。

MAXWEEKS= 
MINWEEKS= 
PASSLENGTH=  

設定に必要な作業は、= の後に適切な数字を入力することだけです。= の後に数字が入っていないエントリは無効です。たとえば、MAXWEEKS に 4 を指定するには、以下のように入力します。

MAXWEEKS=4 
MINWEEKS= 
PASSLENGTH=  

有効期限 (週単位)

ユーザーのパスワードの有効期間を週単位で指定するためのエントリです。以下に示すとおり、"=" の後に適切な数字を入力するだけで指定ができます。

MAXWEEKS=N

N は週の数です。たとえば、MAXWEEKS=9 というようにします。

変更禁止期間 (週単位)

パスワードの変更禁止期間を週単位で指定するためのエントリです。以下に示すとおり、"=" の後に適切な数字を入力するだけで指定ができます。

MINWEEKS=N

N は週の数です。たとえば、MINWEEKS=2 というようにします。

警告期間 (週単位)

同時に MAXWEEKS のデフォルトを設定していない限り、WARNWEEKS のデフォルトを設定しても問題はありません。

パスワードが無効になる前に、「パスワードが間もなく無効になる」という警告メッセージの表示が開始されるタイミングを指定するエントリです。たとえば、MAXWEEKS の値を 9 に指定していて、パスワードが無効になる 2 週間前に警告メッセージの表示を開始したいときは、WARNWEEKS を 7 に設定します。

WARNWEEKS は、MAXWEEKS に指定された有効期限ではなく、パスワードの最終変更日を起点と考えて設定することに注意してください。したがって WARNWEEKS に、MAXWEEKS 以上の値を設定することはできません。

WARNWEEKS のデフォルトは、MAXWEEKS のデフォルトも一緒に設定されていない限り無効です。

WARNWEEKS は、以下に示すとおり "=" の後に適切な数字を入力するだけで指定ができます。

WARNWEEKS=N

N は週の数です。たとえば、WARNWEEKS=1 というようにします。

最低文字数

passwd コマンドには、デフォルトで「パスワードの長さは６文字以上にする」という規則があります。しかし、/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 分以内にパスワードの変更に成功しないとエラーメッセージが表示され、一定の時間が経過するまで該当ユーザーのパスワード変更はできなくなります。

第 12 章 NIS+ グループの管理

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

• 「NIS+ グループメンバーのタイプ」

• 「グループのオブジェクト属性を表示する方法」

• 「NIS+ グループを作成する」

• 「NIS+ グループを削除する」

• 「NIS+ グループにメンバーを追加する」

• 「NIS+ グループのメンバーを表示する」

• 「NIS+ グループからメンバーを削除する」

• 「NIS+ グループのメンバーかどうかを調べる」

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

Solaris グループ

Solaris/NIS+ 環境には、UNIX グループ、ネットグループ、NIS+ グループの 3 種類のグループがあります。

• 「UNIX グループ」

  UNIX グループとは、特別な UNIX アクセス権を与えられたユーザーの集まりのことです。NIS+ 名前空間では、UNIX グループに関する情報は org_dir ディレクトリオブジェクト (group.org_dir) 内のグループテーブルに格納されます。UNIXグループメンバーの追加、修正、削除の方法については、第 14 章「NIS+ テーブルの管理」を、グループテーブルの詳細は、「group テーブル 」をそれぞれ参照してください。

• 「ネットグループ」

  ネットグループとは、ワークステーションとユーザー (他のワークステーション上でリモート操作を実行する権限を与えられている) の集まりのことです。NIS+ 名前空間では、ネットグループに関する情報は org_dir ディレクトリオブジェクト (netgroup.org_dir) 内のグループテーブルに格納されます。ネットグループメンバーの追加、修正、削除の方法については第 14 章「NIS+ テーブルの管理」を、ネットグループテーブルの詳細は、「netgroup テーブル」をそれぞれ参照してください。

• 「NIS+ グループ」

  NIS+ グループとは、NIS+ オブジェクトに対する特別なアクセス権 (ネームスペースの管理を許されることが多い) を与えられている NIS+ ユーザーの集まりのことをいいます。NIS+ グループに関する情報は groups_dir ディレクトリオブジェクト内のテーブルに格納されます。

NIS+ グループ

NIS+ グループは、NIS+ オブジェクトに対するアクセス権を NIS+ の主体に割り当てるために考えられた概念です。(これらのアクセス権については、第 6 章「セキュリティの概要」を参照してください。) 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 コマンドを使用する場合、主体のタイプは表 12-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... には、表 12-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. ドメインに、次のグループは 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 コマンドを使用します (第 10 章「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 を、グループ Ateam.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+ グループからメンバーを削除するには、グループオブジェクトに対する変更権が必要です。-r オプションを使用します。

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. 

第 13 章 NIS+ ディレクトリの管理

この章では、NIS+ ディレクトリのオブジェクトとその管理方法を説明します。

• 「ディレクトリのオブジェクト属性を表示する」

• 「ディレクトリの内容を表示する (簡潔形式) 」

• 「ディレクトリの内容を表示する (詳細形式)」

• 「ディレクトリを作成する」

• 「複製サーバーを既存のディレクトリに追加する」

• 「ディレクトリを削除する」

• 「複製サーバーをディレクトリから切り離す」

• 「ディレクトリ以外のオブジェクトを削除する」

• 「NIS 互換の NIS+ デーモンを起動する」

• 「DNS 転送 NIS 互換デーモンを起動する」

• 「NIS+ デーモンを停止する」

• 「クライアントを初期設定する」

• 「ルートマスターサーバーを初期設定する」

• 「キャッシュマネージャの起動と停止」

• 「NIS+ キャッシュの内容を表示する」

• 「ping とチェックポイントを実行する」

• 「最新更新時間を表示する」

• 「ディレクトリにチェックポイントを実行する」

• 「オブジェクトの生存期間を変更する」

• 「テーブルエントリの生存期間を変更する」

NIS+ ディレクトリ

NIS+ ディレクトリオブジェクトは、NIS+ ドメインに関する情報を格納するために使われます。NIS+ ドメインごとに個別の NIS+ ディレクトリ構造があります。NIS+ ディレクトリの詳細は、第 4 章「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 スクリプトを使うともっと簡単に非ルートサーバーを追加できますが、その方法については『Solaris ネーミングの設定と構成』で説明します。

nismkdir コマンドは、ルート以外の NIS+ ディレクトリを作成し、これをマスターサーバーに関連付けます。ルートディレクトリを作成するには、「nisinit コマンド」で説明する nisinit -r コマンドを使います。nismkdir コマンドを使って、複製サーバーを既存のディレクトリに追加できます。

NIS+ ディレクトリを作成するには、いくつかの関連作業のほかに、いくつかの前提条件があります。詳細は、『Solaris ネーミングの設定と構成』を参照してください。

ディレクトリを作成するには、以下のように入力します。

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 は必ず (複製サーバーではなく) マスターサーバー上で実行してください。複製サーバーで実行すると、マスターサーバーと複製サーバーの間で通信上の問題が発生します。

次の例では、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 コマンドを使用して複製サーバーを既存のシステムに追加する方法を説明します。簡単な方法としては、『Solaris ネーミングの設定と構成』で説明している nisserver スクリプトを使う方法があります。

以下の点に注意してください。

• ルートドメインサーバーはルートドメイン (またはその一部) に置く

• サブドメインサーバーは、サブドメインの 1 つ上の階層の親ドメイン (またはその一部) に置く。たとえば、名前空間に prime という名前のルートドメインと sub1 という名前のサブドメインがある場合は、次のようになる

  • prime ドメインにサービスを提供するマスターサーバーと複製サーバーは、prime がルートドメインであるため、prime ドメインの一部になる

  • sub1 サブドメインにサービスを提供するマスターサーバーと複製サーバーも、prime が sub1 の親ドメインであるため、prime ドメインの一部になる

• マスターサーバーまたは複製サーバーから複数のドメインにサービスを提供することもできるが、そのような措置は避けた方がよい

新しい複製サーバーを既存のディレクトリに割り当てるには、-s オプションと、既存のディレクトリ名を使います。

nismkdir -s replica-server existing-directory-name 
nismkdir -s replica-server org_dir.existing-directory-name
nismkdir -s replica-server groups_dir.existing-directory-name 

nismkdir コマンドは、ディレクトリがすでに存在することを知っているため、再び作成しません。単に、追加の複製サーバーを割り当てるだけです。たとえば、新しい複製サーバーマシン名が rep1 である場合は、以下のように入力します。

rootmaster% nismkdir -s rep1.doc.com. doc.com. 
rootmaster% nismkdir -s rep1.doc.com. org_dir.doc.com.
rootmaster% nismkdir -s rep1.doc.com. groups_dir.doc.com.

nismkdir は必ず (複製サーバーではなく) マスターサーバー上で実行してください。複製サーバーで実行すると、マスターサーバーと複製サーバーの間で通信上の問題が発生します。

先述のように nismkdir を 3 回繰り返して実行した後は、以下の 3 つのディレクトリでマスターサーバーから nisping を実行する必要があります。

rootmaster# nisping doc.com.
rootmaster# nisping org_dir.doc.com.
rootmaster# nisping group_dir.doc.com.

この結果は以下のようになります。

rootmaster# nisping doc.com.
Pinging replicas serving directory doc.com. :
Master server is rootmaster.doc.com.
 Last update occurred at Wed Nov 18 19:54:38 1995
Replica server is rep1.doc.com.
 Last update seen was Wed Nov 18 11:24:32 1995
 Pinging ... rep1.doc.com

マスターサーバーの cron ファイルに、nisping コマンドが少なくとも 24 時間に一度 (この 3 つのディレクトリに対して) 実行されるよう設定しておくことをお勧めします。

nisrmdir コマンド

nisrmdir コマンドでは、ディレクトリを削除したり、ディレクトリと複製サーバーを切り離すことができます。ディレクトリを削除、またはディレクトリと複製サーバーを切り離すと、その NIS+ ドメインに対しては、マシンは NIS+ 複製サーバーとしては機能しなくなります。

ディレクトリの削除では、まずマスターサーバーと複製サーバーをディレクトリから切り離し、次にそのディレクトリを削除します。

• ディレクトリを削除するには、その親ディレクトリに対する削除権が必要です。

• ディレクトリから複製サーバーを切り離すには、そのディレクトリに対する変更権が必要です。

nisrmdir コマンドの実行で問題が生じる場合は、「複製の失敗からの NIS+ ディレクトリの削除または分離」を参照してください。

ディレクトリを削除する

ディレクトリ全体を削除し、そのマスターサーバーと複製サーバーを切り離すには、nisrmdir コマンドをオプションなしで実行します。

nisrmdir directory-name
nisping  domain

次の例では、doc.com. ディレクトリの下の manf.doc.com. ディレクトリを削除します。

rootmaster% nisrmdir manf.doc.com.
rootmaster% nisping doc.com.

複製サーバーをディレクトリから切り離す

複製サーバーをディレクトリから切り離すには、まず、ディレクトリの org_dir と groups_dir サブディレクトリを削除します。その時は、nisrmdir コマンドに -s オプションを付けて実行します。サブディレクトリが削除されたら、親ドメインに戻って nisping を実行してください。

nisrmdir -s replicaname org_dir  domain
nisrmdir -s replicaname groups_dir .domain
nisrmdir -s replicaname domain
nisping domain 

次の例では、manfreplica1 サーバーを manf.doc.com. ディレクトリから切り離します。

rootmaster% nisrmdir -s manfreplica1 org_dir.manf.doc.com. 
rootmaster% nisrmdir -s manfreplica1 groups_dir.manf.doc.com.
rootmaster% nisrmdir -s manfreplica1 manf.doc.com.
rootmaster% nisping manf.doc.com.

nisrmdir -s コマンドを実行したが、切り離し対象の複製サーバーがダウンしていた、または通信が途絶していたという場合、「Cannot remove replica name: attempt to remove a non-empty table」というエラーメッセージが出されます。このような場合は、マスターサーバー上で nisrmdir -f -s replicaname コマンドを実行すれば、強制的に切り離すことができます。ただし、nisrmdir -f -s コマンドでダウン状態の複製サーバーを切り離した場合、その複製サーバーがオンラインに復帰したらただちに nisrmdir -f -s コマンドを再実行して複製サーバーの /var/nis ファイルシステムの中を整理する必要があります。この nisrmdir -f -s replicaname コマンドの再実行を怠ると、複製サーバーに古い情報が残り、問題が生じる原因にもなりかねません。

nisrm コマンド

nisrm コマンドは、標準の rm システムコマンドと似ています。このコマンドは、ディレクトリと空でないテーブルを除いて、名前空間からすべての NIS+ オブジェクトを削除します。nisrm コマンドを使うには、オブジェクトに対する削除権が必要です。しかし、この権利がない場合、-f オプションを使うことができます。このオプションは、アクセス権がなくても動作を強行しようと試みます。

nisgrpadm -d コマンド (「NIS+ グループを削除する」を参照) を使えばグループオブジェクトを削除でき、nistbladm -r または nistbladm -R (「テーブルを削除する」を参照) を使えばテーブルを空にできます。

nisrm [-if] object-name

ディレクトリ以外のオブジェクトを削除する

ディレクトリ以外のオブジェクトを削除するには、nisrm コマンドを使い、オブジェクト名を指定します。

nisrm object-name...

次の例では、名前空間からグループとテーブルを削除します。

rootmaster% nisrm -i admins.doc.com. groups.org_dir.doc.com. 
Remove admins.doc.com.? y
Remove groups.org_dir.doc.com.? y

rpc.nisd コマンド

rpc.nisd コマンドは、NIS+ デーモンを起動します。このデーモンは NIS 互換モードで実行でき、NIS クライアントからの要求にも応答できます。NIS+ デーモンを起動するにはアクセス権は不要ですが、そのすべての前提条件と関連作業を知っておく必要があります。これらについては、『Solaris ネーミングの設定と構成』を参照してください。

デフォルトでは、NIS+ デーモンはセキュリティレベル 2 で起動します。

デーモンを起動するには、以下のように入力します。

rpc.nisd

デーモンを NIS 互換モードで起動するには、以下のように入力します。

rpc.nisd -Y [-B]

DNS 転送機能によって NIS 互換デーモンを起動するには、以下のように入力します。

rpc.nisd -Y -B

DNS 転送機能によって NIS+ 互換デーモンを起動する

rpc.nisd

ルートマスター以外の任意のサーバーで NIS+ デーモンを起動するには、このコマンドをオプションなしで実行します。

デーモンは、デフォルトであるセキュリティレベル 2 で起動します。セキュリティレベル 0 でデーモンを起動するには、-S フラグを使います。

rpc.nisd -S 0

NIS 互換の NIS+ デーモンを起動する

ルートマスターを含む任意のサーバーで、NIS+ デーモンを NIS 互換モードで起動できます。-Y (大文字) オプションを使います。

rpc.nisd -Y

サーバーが再起動された場合にデーモンを NIS 互換モードで再起動させるには、サーバーの /etc/init.d/rpc ファイル内で EMULYP=Y を含む行をコメント解除しなければなりません。

DNS 転送 NIS 互換デーモンを起動する

NIS 互換モードで実行している NIS+ デーモンに DNS 転送機能を追加するには、rpc.nisd に -B オプションを追加します。

rpc.nisd -Y -B

サーバーが再起動された場合に、デーモンを DNS 転送 NIS 互換モードで再起動させるには、サーバーの /etc/init.d/rpc ファイル内の EMULYP=-Y を含む行をコメント解除し、次のように変更しなければなりません。

EMULYP -Y -B

NIS+ デーモンを停止する

NIS+ デーモンを停止するには、その実行モードが通常であろうと NIS 互換であろうと、他のデーモンと同じようにプロセスを終了させます。最初にそのプロセス ID を見つけ、次にプロセスを終了させます。次に例を示します。

rootmaster# ps -e | grep rpc.nisd
root 1081 1 61 16:43:33 ? 0:01 rpc.nisd -S 0
root 1087 1004 11 16:44:09 pts/1 0:00 grep rpc.nisd
rootmaster# kill 1081

nisinit コマンド

この節では、nisinit コマンドを使用してワークステーションクライアントを初期設定する方法について説明します。クライアントの初期設定は、nisclient スクリプトを使用するとさらに容易に行えます (『Solaris ネーミングの設定と構成』を参照)。

nisinit コマンドは、NIS+ クライアントとなるワークステーションを初期設定します。rpc.nisd コマンドと同様、nisinit コマンドを使うにはアクセス権は不要ですが、その前提条件と関連作業を知っておく必要があります。これらについては、『Solaris ネーミングの設定と構成』を参照してください。

クライアントを初期設定する

クライアントを初期設定するには、次の 3 つの方法があります。

• ホスト名による方法

• ブロードキャストによる方法

• コールドスタートファイルによる方法

前提条件と関連作業は、方法によってそれぞれ異なります。たとえば、ホスト名によってクライアントを初期設定するには、その前にクライアントの /etc/hosts ファイルまたは /etc/inet/ipnodesファイルに、使用するホスト名を登録しなければなりません。また nsswitch.conf ファイルの hosts の最初の選択肢として、files を指定する必要があります。IPv6 アドレスには、hosts の最初の選択肢としてipnodes を指定してください。 前提条件や関連作業を含め、各方法の詳細は、『Solaris ネーミングの設定と構成』を参照してください。nisinit コマンドを使う手順を次にまとめてみます。

ホスト名によってクライアントを初期設定するには、-c と -H のオプションを使い、クライアントがそのコールドスタートファイルを取得するサーバー名を指定します。