NIS+ のセキュリティの問題

この節では、パスワード、資格、暗号、その他セキュリティに関係した一般的な問題を取り上げます。

セキュリティ問題の症状

処理内容に関係する次の表現が含まれているエラーメッセージが表示されます。

• Authentication error

• Authentication denied

• Cannot get public key

• Chkey failed

• Insufficient permission to

• Login incorrect

• Keyserv fails to encrypt

• No public key

• Permission denied

• Password [problems]

ユーザーまたはスーパーユーザーは、名前空間に関係する作業を行うことができません (NIS+ の所有権とアクセス権の問題を参照)。

「Login Incorrect」というメッセージが表示された

原因としてもっとも多いのが、パスワードの誤入力です。もう一度入力するようユーザーに指示してください。「記憶しているパスワードが正しいか」、「パスワードでは大文字と小文字が区別されることを理解しているか」、「アルファベットの o と数字の 0、アルファベットの l と数字の 1 などを混同していないか」といったことについても確認してください。

「login incorrect」メッセージの原因としては他に以下のようなものが考えられます。

• パスワードが管理者によってロックされている (パスワードのロック、パスワードロックの解除を参照)。

• 指定の日数以上ログインが行われなかったため、パスワードがロックされた (ログインの間隔の最大値の指定 を参照)。

• パスワードが有効期限を過ぎた (パスワード使用権の有効期限 を参照)。

パスワードについては、第 16 章「パスワードの管理」を参照してください。

パスワードがロック状態、期限切れ、または無効である

「Permission denied, password expired」といったタイプのメッセージは、「ユーザーのパスワードが有効期限を過ぎた」、「またはパスワード使用権が無効になった」といった理由で表示されることが最も多くなっています。詳細については、第 16 章「パスワードの管理」を参照してください。

• パスワードの有効期間の設定を参照

• パスワード使用権の有効期限を参照

資格情報が古い

資格、アクセス権ともに正しいにもかかわらず、クライアントの要求が拒否されるという場合もあります。これは、名前空間のどこかに古い情報が存在することが原因である可能性があります。

資格情報の保存と更新

公開鍵など、資格に関する情報は、名前空間内の様々な場所に保存されています。NIS+ は、情報を格納しているオブジェクトの生存期間に応じてこの情報を定期的に更新しますが、場合によっては、更新の間に同期が失われることがあります。その結果、一部の操作が行えなくなります。表 24–2 は、資格に関する情報を保存するすべてのオブジェクト、テーブル、ファイルと、そのリセットの方法を示したものです。

古くなったキャッシュに保存された鍵の更新

情報が古くなる原因として最も多いのが、サーバーの公開鍵のバージョンが古くなることです。一般に、この問題を解決するには、アクセスするドメインに対して nisupdkeys を実行します (nisupdkeys コマンドの使用方法の詳細は、第 12 章「NIS+ 資格の管理」を参照)。

鍵の中にはファイルやキャッシュに保存されているものもあるため、nisupdkeys ですべての問題を解決できるわけではありません。鍵を手作業で更新しなければならない場合もあります。この場合は、「サーバーの公開鍵の内容は、公開鍵が作成された後どのように名前空間オブジェクトに伝えられるのか」ということについて理解する必要があります。サーバーの公開鍵の伝播には、一般に以下の 5 つの段階があります。それぞれの詳細について説明します。

1: サーバーの公開鍵が作成される

NIS+ サーバーはまず第 1 に、NIS+ クライアントです。つまり、NIS+ サーバーの公開鍵は、NIS+ クライアントの公開鍵と同様に、 nisaddcred コマンドによって生成されます。 公開鍵はその後、サーバーが実際にサポートするドメインではなく、サーバーのホームドメインの cred テーブルに保存されます。

2: 公開鍵の内容がディレクトリオブジェクトに伝えられる

NIS+ ドメインと NIS+ サーバーの設定後は、サーバーとドメインを関係づけることができます。この「関係づけ」は、nismkdir コマンドで行います。nismkdir コマンドによってサーバーとディレクトリの関係づけが行われる際、サーバーの公開鍵も cred テーブルからドメインのディレクトリオブジェクトにコピーされます。たとえば、サーバーが doc.com. ルートドメインのクライアントで、sales.doc.com. ドメインのマスターサーバーになっているという場合を考えてみましょう。

図 24–1 ディレクトリオブジェクトへの公開鍵の伝播

公開鍵は cred.org_dir.doc.com. ドメインから、ディレクトリオブジェクト sales.doc.com. にコピーされます。以上のことは、niscat -o sales.doc.com. というコマンドを使用して確認できます。

3: ディレクトリオブジェクトの内容がクライアントファイルに伝えられる

nisinit ユーティリティまたは nisclient スクリプトを使用すれば、すべての NIS+ クライアントを初期化できます。

他の類似のコマンドと同様、nisinit (または nisclient) では、コールドスタートファイル /var/nis/NIS_COLDSTART が作成されます。コールドスタートファイルは、クライアントのディレクトリキャッシュ /var/nis/NIS_SHARED_DIRCACHE の初期化に使用されます。コールドスタートファイルには、クライアントのドメイン中のディレクトリオブジェクトのコピーが含まれています。ディレクトリオブジェクトには、すでにサーバーの公開鍵のコピーが含まれているため、これで公開鍵の内容はクライアントのコールドスタートファイルに伝えられたことになります。

また、クライアントがホームドメインの外のサーバーに対して要求をした場合、リモートドメインのディレクトリオブジェクトのコピーが、クライアントの NIS_SHARED_DIRCACHE ファイルに保存されます。クライアントのキャッシュの内容は、nisshowcache コマンドを使用して調べることができます。

複製サーバーがドメインに追加されるか、サーバーの鍵が更新されるまでは、鍵の伝播はこの段階にとどまります。

4: 複製サーバーがドメインに追加された場合の処理

複製サーバーがドメインに追加されると、nisping コマンド (nisping コマンド を参照) によって NIS+ テーブル (cred テーブルを含む) が新しい複製サーバーにダウンロードされます。これによって、元のサーバーの公開鍵も複製サーバーの cred テーブルに保存されます。

5: サーバーの公開鍵が更新された場合の処理

サーバーの DES 資格 (サーバーのルート ID) を変更すると、公開鍵も変更されます。その結果、サーバー用に cred テーブルに保存される公開鍵が、以下の場所に保存されるものと矛盾します。

• 複製サーバーの cred テーブル (数分の間)

• サーバーがサポートするドメイン中の、メインディレクトリオブジェクト (生存期間終了まで)

• サーバーがサポートするドメイン中の、クライアントの NIS_COLDSTART ファイルおよび NIS_SHARED_DIRCACHE ファイル (生存期間終了まで、通常 12 時間)

• サーバーがサポートするドメインに要求をしたクライアントの、NIS_SHARED_DIRCACHE ファイル (生存期間終了まで)

サーバーの鍵は、ほとんどの場所において数分〜 12 時間で自動的に更新されます。すぐに更新するには、以下のコマンドを使用します。

nis_cachemgr の再起動は、既存の nis_cachemgr を終了してから行います。

無効になった資格

主体 (ユーザーかマシン) の資格が無効になっている場合は、その主体は nisls のようなコマンドも含め、名前空間の操作や処理を行うことができなくなってしまいます。資格が無効になると、未認証クラスに割り当てられるアクセス権も含め、すべてのアクセス権が失われるからです。

「症状」

ユーザーまたはスーパーユーザーが、名前空間に関係する作業を行うことができなくなります。名前空間のどのような操作を行なっても、「permission denied」というタイプのエラーメッセージが表示されます。ユーザーまたはスーパーユーザーは、nisls を実行することも不可能になります。

「考えられる原因」

鍵の破損、物理的な破損、古い資格、その他何らかの不適切な点が、/etc/.rootkey ファイルの中にあります。

「診断」

snoop を使用して、不適切な資格を識別します。

あるいは、その主体がリスト表示できる場合は、その主体としてログインを行い、主体が間違いなく承認されているはずのオブジェクトを対象として、NIS+ コマンドを実行します。たとえば、ほとんどの場合、未認証クラスにオブジェクトの読み込みは承認されているはずです。そこで、cred テーブルの中にリストされている主体は、nisls コマンドを正しく実行できるはずです。このコマンドを実行しても「permission denied」エラーが発生する場合は、おそらく、その主体の資格は無効になっています。

「対策」

• 「一般のユーザー」の場合、keylogout を実行してから、次に keylogin を実行して、その主体のログインを試みます。

• 「root」すなわち「スーパーユーザー」の場合、keylogout -f を実行してから、 keylogin -r を実行します。

Keyserv のエラー

keyserv が、セッションを暗号化できません。このタイプの問題には、いくつかの原因が考えられます。

「考えられる原因と対策」

• クライアントが keylogin を実行していません。keylogin を実行したかどうか確認します。クライアントが正しく keylogin を実行したかどうかを確かめるには、(そのクライアントで) nisdefaults -v を実行します。Principal Name という行に「not authenticated」というメッセージが返れば、クライアントが正しく keylogin を実行していないことになります。

• クライアント (またはホスト) が、LOCAL や DES のような適切な資格を持っていません。クライアントの cred テーブルを対象にして niscat を実行し、クライアントが適切な資格を持っているかどうか確認します。必要に応じて、NIS+ 主体の資格情報を作成する方法に従って資格を追加します。

• keyserv デーモンが動作していません。ps コマンドを使用して、keyserv が動作しているかどうか確認します。動作していない場合は、このデーモンを起動してから keylogin を実行します。

• keyserv が動作している場合は、Secure RPC や NIS+ のコールを行う終始動作しているはずのプロセスが、まだ動作していません。たとえば、automountd、rpc.nisd、sendmail などが動作していません。これらのプロセスが正しく動作しているかどうか確認します。動作していない場合は再起動します。

マシンが以前は NIS+ のクライアントだった

このマシンが、同じドメインの中で NIS+ のクライアントとして初期設定されている場合は、試みに keylogin -r を実行し、Secure RPC パスワードプロンプトでスーパーユーザーのログインパスワードを入力します。

cred テーブルにエントリがない

cred テーブルの中に主体 (ユーザーまたはホスト) の NIS+ のパスワードが存在することを確認するために、主体のホームドメインの中で次のコマンドを実行します。

nisgrep -A cname=principal cred.org_dir.domainname

nisgrep を別のドメインで実行する場合は、domainname には完全な名前を指定する必要があります。

ドメイン名が変更されている

ドメイン名は変更すべきではありません。

既存のドメイン名を変更すると、認証の問題が発生するはずです。ネットワーク全体で、オブジェクトの中に完全指定のドメイン名が埋め込まれているからです。

ドメイン名を変更しないでください。既にドメイン名を変更してしまい、認証の問題や、ドメイン名に関係する「malformed」や「illegal」などの表現が含まれているメッセージが表示されている場合は、ドメイン名を元の名前に戻します。ドメイン名を変更したい場合は、次の手順に従ってください。「新しい名前」を使用して「新しいドメイン」を作成し、新しいドメインでマシンをサーバーやクライアントとして設定し、これらが正しく動作していることを確認した上で、古いドメインを削除します。

マシンを新しいドメインに変更する

NIS+ のクライアントとなっているマシンを、他のドメインのクライアントに変更したい場合は、/etc/.rootkey ファイルを削除し、ネットワーク管理者から受け取ったパスワードか nisclient スクリプトから取り出したパスワードを使用して、nispopulate スクリプトを実行し直します。

/etc/passwd ファイルの中にある NIS+ のパスワードとログインパスワード

NIS+ のパスワードは、NIS+ の passwd テーブルの中に格納されています。ログインパスワードは、NIS+ の passwd テーブルか、各ユーザーの /etc/passwd ファイルの中に格納されています。ユーザーパスワードと NIS+ のパスワードは、同じでも違っていてもかまいません。/etc/passwd ファイル内のパスワードを変更するには、nsswitch.conf ファイルでの設定を「files」にするか、「-r files」というフラグを指定するかして passwd コマンドを実行する必要があります。

nsswitch.conf ファイルは、どの目的にどのファイルを使用するか指定します。nsswitch.conf ファイルが、システムの照会に対して誤った場所を指示している場合は、パスワードやアクセス権のエラーが発生するはずです。

Secure RPC パスワードとログインパスワードが異なる

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

この場合、主体はシステムにログインすることはできますが、NIS+ においては未認証クラスとして扱われます。キーサーバーが、そのユーザーの非公開鍵を復号化されていない状態のまま持っているからです。NIS+ 環境では多くの場合、未認承クラスによる NIS+ オブジェクトへのアクセス (作成、削除、変更) が拒否されるため、この状態でユーザーが NIS+ オブジェクトにアクセスしようとしても「permission denied」といったタイプのエラーになってしまいます。

「ネットワークパスワード」と「Secure RPC パスワード」は、このコンテキストでは同義語として扱われる場合があります。ネットワークパスワードの入力を求められたら Secure RPC パスワードを入力します。

認証クラスを「未認承」以外にするには、ユーザーがこの状況で keylogin プログラムを実行し、パスワード入力を求める keylogin プロンプトが表示されたときに主体の Secure RPC パスワードを入力する必要があります (キーログインを参照)。

しかし keylogin を実行しても、現在のログインセッション以外には無効で、一時的な解決にしかなりません。キーサーバーはこの方法によって、復号化された形でユーザーの非公開鍵を持つようになるのですが、ユーザーの cred テーブル中の非公開鍵が Secure RPC パスワード (ユーザーのログインパスワードとは異なっている) を使用して暗号化されているという点に変わりはないからです。ログインし直してしまえば、状況はまったく元どおりになってしまいます。根本的に問題を解決するためには、cred テーブルの非公開鍵を、Secure RPC パスワードではなくログイン ID に基づいたものに変更する必要があります。この作業は、chkey プログラムを使用して行います (NIS+ 主体の鍵の変更を参照)。

Secure RPC パスワードとログインパスワードが異なっているという問題を根本的に解決するには、具体的には以下の作業を行います。

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

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

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

/etc/.rootkey ファイルがすでに存在している

「症状」

「insufficient permission」や、「permission denied」などの、様々なエラーメッセージ

「考えられる原因」

サーバーやクライアントの設定や初期設定を行なったときに、/etc/.rootkey ファイルがすでに存在していました。以前そのマシンに NIS+ をインストールしたことがあり、NIS+ を削除したとき、または NIS や /etc への変更を行なったときに、.rootkey ファイルを削除しなかったためにこのような状態が起こります。

「診断」

/etc ディレクトリで ls -l と nisls -l org_dir を実行し、/etc/.rootkey の日付を、cred テーブルの日付と比較します。/etc/.rootkey の日付が明らかに cred テーブルより古い場合は、ファイルがあらかじめ存在していたことが考えられます。

「対策」

問題のあるマシンで、root として keylogin -r コマンドを実行し、そのマシンをもう一度クライアントとして設定し直します。

root のパスワードを変更したための問題

「症状」

マシンの root のパスワードを変更した結果、変更結果が反映されなかったか、スーパーユーザーとしてログインできなくなりました。

「考えられる原因」

セキュリティ上の理由から、passwd テーブルの中に、UserID 0 という項目を、設けるべきではありません。

ルートのパスワードを変更した際、ルートに対して chkey -p を実行していなかったり、何らかの問題が発生したことにより、変更が正しく行われませんでした。

「対策」

管理特権を持つユーザー (つまり、管理特権が割り当てられているグループに所属するメンバー) としてログインし、passwd を使用して、元のパスワードに戻します。元のパスワードが正しく機能するかどうか確かめてください。正しく機能すれば、passwd を使用してパスワードを変更した後、chkey -p を実行します。

NIS+ の名前空間の設定が終わり、すでに動作している状態でも、ルートマスターのマシンを使って root のパスワードを変更することは可能です。しかし、ルートマスターの鍵は変更しないでください。これらは、サブドメイン内のすべてのクライアント、複製サーバー、サーバーの中のすべてのディレクトリオブジェクトに埋め込まれているからです。chkey をルートで実行する際、必ず -p オプションを指定するようにすれば、ルートマスターの鍵を変更する必要はなくなります。