この章では、NIS+ 資格とその管理方法について説明します。
NIS+ セキュリティタスクの中には、可能であれば Solstice AdminSuite ツールを使用した方が簡単に実行できるものがあります。
NIS+ 資格は、NIS+ のユーザーを識別するために使用します。この章では、NIS+ セキュリティシステム全体と、特にシステムで資格が果たす役割について、十分理解しているユーザーを想定しています (詳しくは、第 6 章「セキュリティの概要」を参照)。
これらタスクを実行するのに使われるコマンドの構文、オプションなどの詳細は、NIS+ のマニュアルを参照してください。
この章では、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+ 主体の資格情報を作成する方法」を参照)。
サーバーの公開鍵を作成します (「公開鍵の更新」を参照)。
主体がシステムにログインする時、次のステップが自動的に実行されます。
主体のログインパスワードが Secure RPC パスワードと異なる場合、 keylogin コマンドはパスワードを復号化できず、「cannot decrypt」などのエラーとなるか、メッセージなしでコマンドが失敗します。この問題の解説は、「Secure RPC パスワードとログインパスワードの問題」を参照してください。
復号化された非公開暗号鍵はユーザーが keylogout コマンドを実行するまでキーサーバーに格納されます。ユーザーが keylogout を実行せずにログアウトした (またはログアウトせずに帰宅してしまった) 場合には、復号化された非公開鍵がサーバーに格納されたままになっています。もしユーザーマシンのルート権限を持った誰かがユーザーログイン ID に su コマンドを使った場合、その人間はユーザーの復号化された非公開鍵を使用でき、ユーザーのアクセス承認を使って NIS+ オブジェクトにアクセスできることになります。このような事態を避けるため、ユーザーが業務を終了する時は確実に keylogout コマンドを使ってログアウトするように注意する必要があります。同様にもしユーザーがログオフする場合は、業務に戻る時はログバックするだけで良いのです。もしユーザーが確実にログオフしなかった場合、業務に戻る時に確実に keylogin を実行する必要があります。
NIS+ 主体の要求が NIS+ オブジェクトにアクセスするつど、その主体を認証するために NIS+ ソフトウエアは複数段階のプロセスを実行します。
NIS+ はオブジェクトドメインの cred テーブルをチェックします。
もし主体が LOCAL 資格情報を持っていた場合、LOCAL 資格にあるドメイン情報を使い、主体のホームドメイン cred テーブルを見つけます。ここでは必要な情報を獲得します。
もし主体が資格情報を持っていなかった場合、残りのプロセスは実行されず、主体の承認アクセスクラスには未認証クラスが与えられます。
ユーザーのホームドメインの cred テーブルから、NIS+ がユーザーの DES 資格を取得します。ユーザーパスワードを使って非公開暗号鍵が復号化され、キーサーバーに格納されます。
キーサーバーが、主体の復号化された非公開鍵とオブジェクトのサーバー (オブジェクトが格納されているサーバー) の公開鍵を使って、「共通鍵」を作成します。
共通鍵を使って暗号化された「DES 鍵」が作成されます。これは、Secure RPC が乱数を発生させ、これを共通鍵を使って暗号化することで行われます。このため、DES 鍵は「乱数鍵」もしくは「乱数 DES 鍵」として参照される場合があります。
NIS+ が 15 秒のタイムウィンドウ (DES 鍵を使って暗号化される) を作成します。この「ウィンドウ」はタイムスタンプとサーバーの内部クロックとの間で許容される最長時間になります。
NIS+ が主体の DES 資格を作成します。これは次のもので構成されます。
NIS+ が NIS+ オブジェクトの格納されているサーバーに次の情報を渡します。
アクセス要求
主体の DES 資格
ウィンドウ判定子 (暗号化済)。ウィンドウ判定子は暗号化されたウィンドウに 1 を加えたもの
オブジェクトのサーバーがこの情報を受信します。
オブジェクトのサーバーが、資格の中の Secure RPC ネット名の一部を使って、主体のホームドメインにある cred テーブル内にある主体の公開鍵をチェックします。
サーバーが主体の公開鍵とサーバーの非公開鍵を使ってもう一度共通鍵を作成します。この共通鍵は主体の非公開鍵とサーバーの公開鍵を使って作成されている共通鍵と一致する必要があります。
共通鍵を使って、主体の資格の一部として受信している DES 鍵を暗号化します。
サーバーが、新しく復号化した DES 鍵を使って主体のタイムスタンプを復号化し、ウィンドウ判定子を使ってそれをチェックします。
サーバーが、復号化しチェックしたタイムスタンプと自分の内部時計とを比較し、次のプロセスを実行します。
サーバーとの時間差がウィンドウ許容値を越えていた場合、要求は拒否され、プロセスが中止されて、エラーメッセージが表示されます。たとえば、タイムスタンプが 9:00 am であり、ウィンドウが 1 分であったとします。もしその要求をサーバーが受信して復号化したのが 9:01 am であれば、その要求は拒否されます。
タイムスタンプがウィンドウ許容値内である場合、サーバーは主体から前に受信した要求のタイムスタンプよりも大きいかチェックします。これによって、NIS+ 要求を正しい順序で処理しているか確認できます。
順序誤りの要求はエラーメッセージとともに拒否されます。たとえば、タイムスタンプが 9:00 am でありその主体から最後に受信した要求のタイムスタンプが 9:02 am だった場合、その要求は拒否されます。
最後に受信した要求と同じタイムスタンプであった場合もエラーメッセージが表示されて拒否されます。これによって、要求を 2 度処理することはなくなります。たとえば、タイムスタンプが 9:00 am であり最後にその主体から受信した要求のタイムスタンプも 9:00 am だった場合、この要求は拒否されます。
タイムスタンプがウィンドウ許容値内であり、その主体からの最後の要求よりも大きかった場合に、サーバーはその要求を受け入れます。
サーバーが、要求をコンパイルし、タイムスタンプをその主体から受信した最後のものとして格納し、要求に基づいて動作します。
要求に対する応答としてサーバーから受信した情報が信頼できるサーバーからのものであるかを主体が確認できるようにするため、サーバーは主体の DES 鍵を使ってタイムスタンプを暗号化し、データとともに主体に送り返します。
主体側では、主体の DES 鍵を使って送り返されたタイムスタンプを復号化します。
復号化が成功した場合は、サーバーからの情報を要求者へ戻します。
何らかの理由で復号化に失敗した場合は、エラーメッセージが表示されます。
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 を再起動します。
この節では、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 テーブルは NIS+ が標準で持つ 16 のテーブルの 1 つです。各ドメインに cred テーブルが 1 つあり、そのドメインに属しているクライアントワークステーションとログインを許されたクライアントユーザー (そのドメインの主体) の資格情報が格納されています。cred テーブルはそれらドメインの org_dir サブディレクトリにあります。
cred テーブルをリンクしないでください。各 org_dir ディレクトリはそれ自身の cred テーブルを持つ必要があります。他の org_dir の cred テーブルとのリンクも使用しません。
ドメイン内のすべてのマシンにログインできるユーザーすべての LOCAL 資格情報が cred テーブルに格納されています。cred テーブルにはまた、ホームドメインとしてとしてドメインを持っているユーザーの DES 資格情報も格納されています。
cred テーブルの内容は niscat コマンドを使って見ることができます。第 13 章「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ネット名 |
公開鍵 |
暗号化された非公開鍵 |
「LOCAL」
認証種類が LOCAL の場合、他の列は主体のユーザー名、UID、および GID となり、最後の列は空白になります。
「DES」
認証種類が DES の場合、他の列は主体の Secure RPC ネット名、公開鍵、および暗号化された非公開鍵となります。これらの鍵は、他の情報と共に DES 資格を暗号化したり、復号化するのに使われます。
資格情報を作成したり管理したりするには次の方法があります。
Solstice AdminSuite ツールを使用します。このツールを使用すると容易に資格を管理できます。個々の資格を管理する場合はこのツールの使用を推奨します。
nisclient スクリプトを使用します。1 つの主体の資格を容易に作成し変更できます。便利な方法なので、個々の資格を管理する方法として推奨します。『Solaris ネーミングの設定と構成』の Part I に nisclient スクリプトを使用して資格情報を作成する方法をステップで示しています。
nispopulate スクリプトを使用します。これはすでに NIS+ マップもしくは /etc ファイルに資格情報を格納してある1つ以上の主体の資格を作成変更する便利な方法です。これは、NIS+ 主体グループの資格を管理する方法として推奨します。『Solaris ネーミングの設定と構成』の Part I に nispopulate スクリプトを使用して資格情報を作成する方法をステップで示しています。
nisaddcred コマンドを使用します。次の節では、nisaddcred コマンドを使って資格と資格情報を作成する方法を説明します。
nisaddcred コマンドは資格情報を作成するコマンドです。
nispopulate と nisclient スクリプトを使って資格情報を作成できます。これらスクリプトは nisaddcred コマンドよりも容易に使えて効果的なものです。ネットワークが特別な機能を必要とするのでなければ、スクリプトを使用してください。
nisaddcred コマンドは、LOCAL 資格と DES 資格情報の作成、更新、および削除を行います。資格情報を作成するには、適切なドメインの cred テーブルに対する作成権が必要です。資格を更新するには、cred テーブル、または少なくとも cred テーブルの特定エントリに対する変更権が必要です。資格を削除するには、cred テーブル、または cred テーブルのエントリに対する削除権が必要です。
LOCAL 資格
nisaddcred -p uid -P principal-name local
DES 資格
nisaddcred -p rpc-netname -P principal-name des
この章で説明する nisaddcred コマンドに加えて、資格に関して有用な情報を提供するコマンドが 2 つ用意されています。
表 7-4 その他の資格関連コマンド
コマンド |
説明 |
参照ページ |
---|---|---|
niscat -o |
ディレクトリの属性を一覧表示する。ディレクトリのサーバーの非公開鍵フィールドをチェックすることで、ディレクトリオブジェクトに非公開鍵が格納されているかわかる | |
nismatch- |
cred テーブル上で実行すると主体の資格情報を表示する |
LOCAL 資格情報を作成するために nisaddcred コマンドを使用すると、nisaddcred コマンドは主体のログインレコードから主体ユーザーの UID (および GID) を抽出し、ドメインの cred テーブルに置きます。
DES 資格情報を作成するのに使用した場合、nisaddcred は 2 つのプロセスを実行します。
主体の secure RPC ネット名を作成します。Secure RPC ネット名は、パスワードレコードから取得した主体のユーザー ID 番号とドメイン名 (たとえば、unix.1050@doc.com) を結合して作成されます。
主体の非公開鍵と公開鍵を生成します。
nisaddcred が非公開鍵を暗号化するには、Secure RPC パスワードが必要です。nisaddcred コマンドを引数 -des で呼び出すと、主体の Secure RPC パスワードの入力を要求されます。通常このパスワードは主体のログインパスワードと同じです。 (異なる場合は、「Secure RPC パスワードとログインパスワードの問題」に示す手順に従ってさらに操作が必要となります。)
nisaddcred コマンドは 1 対の乱数 (ディフィ − ヘルマン方式を使った 192 ビットの認証鍵) を作成します。この鍵はディフィ − ヘルマンの鍵ペア (key-pair) または省略して単に「鍵ペア」と呼びます。
この鍵ペアの一方が「非公開鍵」であり、もう一方が「公開鍵」になります。公開鍵は cred テーブルの公開データフィールドに置かれます。非公開鍵は主体の secure RPC パスワードで暗号化された後に非公開データに置かれます。
デフォルトでは、cred テーブルをすべての 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+ の資格情報はドメインの設定後いつでも作成できます。すなわち、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 コマンドを使って変更できます。)
ユーザーのログインパスワードを知らない場合、次に説明するようにダミーパスワードを使うことができます。
表 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:
パスワードプロンプトに対しては、クライアントワークステーションのスーパーユーザーパスワードを入力してください。もちろん、ダミーパスワードを使用することもできます。このダミーパスワードは、その主体ワークステーションにスーパーユーザーとしてログインすれば、後で変更できます。
以下のいくつかのセクションでは、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 の詳細は、第 13 章「NIS+ テーブルの管理」を参照してください。
rootmaster# nismatch morena.doc.com. cred.org_dir salesmaster# nismatch morena.doc.com. cred.org_dir