test

Solaris ネーミングの管理

第 7 章 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 資格をどのように作成しそれがどのように機能するのかを理解するには、実際の資格と資格を作成しチェックするのに使われる情報とを区別する必要があります。

認証

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

主体の認証方法

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

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

資格準備フェーズ

NIS+ 管理者がユーザーに資格情報を作成する最も容易な方法は、『Solaris ネーミングの設定と構成』に述べられている、nisclient スクリプトを使う方法です。この節では、NIS+ のコマンド一式を使用してクライアント情報を作成する方法について説明します。

NIS+ 主体がログインする前に、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 資格は次の内容で構成されます。

DES 資格の Secure RPC ネット名

注 -

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

表 7-1 Secure RPC ネット名のフォーマット

主体 

接頭辞 

識別子 

ドメイン 

例 

ユーザー 

unix

UID 

ユーザーのパスワードエントリと DES 資格そのもののあるドメイン 

unix.24601@sales.doc.com

ワークステーション 

unix

ホスト名 

ドメイン名はワークステーションが domainname コマンドを実行すると返される

unix.machine7@sales.doc.com

DES 資格確認フィールド

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

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

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 コマンドで主体の非公開鍵を作成

Graphic

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

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

図 7-2 DES 資格の作成

Graphic

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 コマンドを使って、システムからログオフします。

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

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

資格関連情報の格納場所

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

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

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

項目 

格納している情報 

リセットまたは変更の方法 

cred テーブル

NIS+ 主体の秘密非公開鍵と公開鍵。これらの鍵のマスターコピーとなっている 

nisaddcred を使用して、新しい資格を作成する。既存の資格を更新する。chkey も使用可

ディレクトリオブジェクト 

サポートする各サーバーの公開鍵のコピー 

ディレクトリオブジェクトに対して /usr/lib/nis/nisupdkeys コマンドを実行する

キーサーバー 

現在ログインしている NIS+ 主体の秘密鍵 

クライアントユーザーの場合は keylogin を、クライアントワークステーションの場合は keylogin -r を実行する

NIS+ デーモン 

ディレクトリオブジェクトのコピー。これはサーバーの公開鍵のコピーを持つ 

rpc.nisd デーモンとキャッシュマネージャを終了し、/var/nis から NIS_SHARED_DIRCACHE を削除する。その後両方を再起動する

ディレクトリキャッシュ 

ディレクトリオブジェクトのコピー。これはサーバーの公開鍵のコピーを持つ 

NIS+ キャッシュマネージャのプロセスを終了し、nis_cachemgr -i コマンドで再起動する。-i オプションは、コールドスタートファイルからディレクトリキャッシュを再設定し、キャッシュマネージャを再起動する

コールドスタートファイル 

ディレクトリオブジェクトのコピー。これは、サーバーの公開鍵のコピーを持つ 

ルートマスターでは、NIS+ デーモンのプロセスを終了してから再起動する。デーモンは、既存の NIS_COLD_START ファイルに新しい情報を再ロードする。クライアントでは、まず/var/nis から NIS_COLD_START と NIS_SHARED_DIRCACHE ファイル削除し、次にキャッシュマネージャのプロセスを終了する。その後、nisinit -c でクライアントを再び初期設定する。クライアントの信頼できるサーバーは、クライアントワークステーションの NIS_COLD_START ファイルに新しい情報を再ロードする

passwd テーブル

ユーザーのパスワード 

passwd -r nisplus コマンドを使用する。このコマンドは、NIS+ passwd テーブル内のパスワードを変更し、cred テーブル内のパスワードを更新する

passwd ファイル

ユーザーのパスワード、またはワークステーションのスーパーユーザーパスワード 

passwd -r nisplus コマンドを使用する。スーパーユーザーとしてログインしていても、自分のユーザー名でログインしていてもよい

passwd マップ (NIS)

ユーザーのパスワード 

passwd -r nisplus コマンドを使用する

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 つの列があります。

表 7-3 cred テーブルの資格情報
 

NIS+主体名 

認証の種類 

認証名 

公開データ 

非公開データ 

列名 

cname

auth_type

auth_name

public_data

private_data

ユーザー 

完全主体名 

LOCAL 

UID 

GID list 

 

マシン 

完全主体名 

DES 

Secure RPCネット名 

公開鍵 

暗号化された非公開鍵 

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

資格情報の作成

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

nisaddcred コマンド

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

注 -

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

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

関連コマンド

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

表 7-4 その他の資格関連コマンド

コマンド 

説明 

参照ページ 

niscat -o

ディレクトリの属性を一覧表示する。ディレクトリのサーバーの非公開鍵フィールドをチェックすることで、ディレクトリオブジェクトに非公開鍵が格納されているかわかる 

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

nismatch-

cred テーブル上で実行すると主体の資格情報を表示する

「nismatch と nisgrep コマンド」

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 による主体キーの作成方法

Graphic

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

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

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

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

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

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

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

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

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

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

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

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

LOCAL 資格


nisaddcred -p uid -P principal-name local

DES 資格


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

次の原則を銘記してください。

ユーザー主体 - 例

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 という名前のルートマスターサーバーから彼の資格情報を入力します。

表 7-5 管理者の資格情報を作成する作業

作業 

コマンド 

eiji の LOCAL 資格情報を作成する

rootmaster# nisaddcred -p 119 -P eiji.doc.com. local

eiji の DES 資格情報を作成する

 

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

eiji のダミーパスワードを入力する

 

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

ダミーパスワードを再度入力する 

Retype password:

使用したダミーパスワードを eiji に伝える

 

eiji がルートマスターにログイン

rootmaster% login: eiji

eiji が本当のログインパスワードを入力

Password:

eiji はエラーメッセージを受けたが、ログインは許可される

Password does not decrypt secret key for unix.119@doc.com.

eiji がログインを実行

rootmaster% keylogin

eiji がダミーパスワードを入力

Password: dummy-password

eiji が chkey を実行

 

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

eiji が本当のログインパスワードを入力

Enter login password:

eiji が本当のログインパスワードを再入力

Retype password: Done.

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

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

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

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

LOCAL 資格情報


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

DES 資格情報


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

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


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

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

ワークステーションでの例

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


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