DES 資格は次の内容で構成されます。
主体の「Secure RPC ネット名」
「確認 (verification)」フィールド
次の 「DES 資格確認フィールド」を参照
「Secure RPC ネット名」
資格のこの部分は NIS+ の主体を特定するのに使用します。Secure RPC ネット名はすべて次の 3 つの要素で構成されます。
「接頭辞」
接頭辞は常に unix になります。
「識別子」
主体がクライアントユーザーの場合、ID フィールドはユーザーの UID です。主体がクライアントワークステーションの場合、ID フィールドはワークステーションのホスト名になります。
「ドメイン名」
主体の DES 資格を含んでいるドメイン名がドメイン名になります (主体のホームドメイン)。
NIS+ 主体名は常にドット (.) で終わりますが、Secure RPC ネット名はドット (.) で終わらないことに注意してください。
主体 |
接頭辞 |
識別子 |
ドメイン |
例 |
---|---|---|---|---|
ユーザー |
unix |
UID |
ユーザーのパスワードエントリと DES 資格そのもののあるドメイン |
unix.24601@sales.doc.com |
ワークステーション |
unix |
ホスト名 |
ドメイン名はワークステーションが domainname コマンドを実行すると返される |
unix.machine7@sales.doc.com |
確認フィールドは資格を確かめるために使用するフィールドです。cred テーブルに格納された資格情報に基づいて作成されます。
確認フィールドの構成は次のとおりです。
主体の非公開鍵と NIS+ サーバーの公開鍵に基づく、暗号化された主体の DES 鍵 (「要求フェーズ - 詳細説明」参照)
暗号化されたタイムスタンプ
タイムウィンドウ
図 7-2 を参照してください。 DES 資格を作成するには、keylogin コマンドを実行する必要がありますが、これは主体が資格を作成する前に実行します。keylogin コマンド (単に「keylogin」とする場合が多い) は、NIS+ 主体がログインする時に自動的に実行されます。
主体のログインパスワードが Secure RPC パスワードと異なる場合は、keylogin コマンドは成功しないことに注意してください。詳しくは、「Secure RPC パスワードとログインパスワードの問題」を参照してください。
keylogin コマンドの目的は、主体が自身の非公開鍵にアクセスできるようにすることにあります。 keylogin コマンドを実行すると、cred テーブルから主体の非公開鍵を取り込み (fetch)、主体の Secure RPC パスワード (非公開鍵は主体の「Secure RPC パスワード」を使って最初に暗号化される) を使ってそれを復号化し、将来の NIS+ 要求に備えてキーサーバーに格納します。
主体が DES 資格を作成するには、主体が要求を送る相手サーバーの公開鍵が必要です。この情報は主体のディレクトリオブジェクトに格納されています。主体がこの情報を獲得すれば資格の確認フィールドを作成できます。
まず、主体が種々の資格情報を暗号化するためにランダム DES 鍵を作成します。主体は自分の非公開鍵 (キーサーバーに格納されている) とサーバーの公開鍵を使って、ランダム DES 鍵を作成し暗号化するための共通鍵を作成します。次に DES 鍵で暗号化したタイムスタンプを作成し、それを確認フィールドで他の資格関連情報の中に入れます。
主体のログインパスワードがユーザーの 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 パスワードがログインパスワードと異なる問題を永久的に解決するには、ユーザー (もしくはユーザーに対応している管理者) が次の手順を実行してください。
ログインパスワードを使ってログインします。
キーサーバーにある復号化された非公開鍵を一時的に獲得するために、keylogin プログラムを実行し、NIS+ アクセス権を得ます。
chkey -p を実行し、cred テーブル内の暗号化された非公開鍵を、ユーザーログインパスワードに基づいたものに永久的に変更します。
logout コマンドを使って、システムからログオフします。
正しい資格を作成し、正しいアクセス権を与えられたのに、主体の要求が拒否される場合があります。この原因のほとんどは、サーバーの公開鍵が古いバージョンだった時に作られた、古いオブジェクトが残っていることにあります。この問題は通常次の方法で解決します。
アクセスしようとしているドメインで、nisupdkeys を実行します。(この種の問題解決の情報については、「nisupdkeys コマンド」と 「資格に関する情報が古くなっている」の項を参照)。
マシンの nis_cachmgr を終了します。次に /var/nis/NIS_SHARED_DIRCACHE を削除してから、nis_cachemgr を再起動します。