第 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