Solaris のシステム管理 (セキュリティサービス)

パート III 認証サービスと安全な通信

第 9 章「認証サービスの使用 (手順)」	Diffie-Hellman 認証について説明します。
第 10 章「PAM の使用」	Pluggable Authentication Module (PAM) フレームワークについて説明します。
第 11 章「Solaris Secure Shell の使用 (手順)」	Solaris Secure Shell の概要と詳細な手順について説明します。
第 12 章「Solaris Secure Shell の管理 (参照)」	Solaris Secure Shell の構成に使用するファイルについて説明します。
第 13 章「SEAM について」	Sun Enterprise Authentication Mechanism (SEAM) の概要について説明します。
第 14 章「SEAM の計画」	SEAM の構成に必要な情報と、構成する前に解決しなければならない問題の一覧を示します。
第 15 章「SEAM の構成 (手順)」	SEAM を構成する手順について説明します。
第 16 章「SEAM エラーメッセージと障害追跡」	SEAM のエラーメッセージ、そのメッセージを生成した条件の修正方法、およびいくつかのエラー条件に対する障害追跡について説明します。
第 17 章「主体とポリシーの管理 (手順)」	`gkadmin` GUI とコマンド行を使用して SEAM の主体とポリシーを管理する手順について説明します。
第 18 章「SEAM の使用 (手順)」	SEAM のユーザー操作手順について説明します。
第 19 章「SEAM (参照)」	SEAM の参照情報を示します。

第 9 章認証サービスの使用 (手順)

この章では、Secure RPC で使用できる Diffie-Hellman 認証メカニズムについて説明します。

この章で説明する手順は次のとおりです。

Secure RPC の概要

Secure RPC は、サービスを要求するホストとユーザーを認証するための認証方式です。Secure RPC では、Diffie-Hellman 認証メカニズムを使用しています。この認証メカニズムは DES 暗号化を使用します。Secure RPC を使用するアプリケーションには、NFS と NIS+ ネームサービスがあります。

NFS サービスと Secure RPC

NFS を使用すると、複数のホストがネットワーク上でファイルを共有できます。NFS サービスでは、サーバーは、複数のクライアントから利用できるデータとリソースを保持します。クライアントは、サーバーがクライアントと共有するファイルシステムにアクセスできます。クライアントマシンにログインしたユーザーは、ファイルシステムをサーバーからマウントすることによって、そのファイルシステムにアクセスできます。このとき、クライアントマシン上のユーザーには、ファイルはクライアントのローカルファイルシステム上にあるように見えます。NFS の最も一般的な使用形態の 1 つは、システムを各オフィスにインストールして、すべてのユーザーファイルを 1 箇所で集中管理することです。mount -nosuid オプションなどのいくつかの NFS 機能を使用すると、権限を持たないユーザーがデバイスやファイルシステムにアクセスすることを禁止できます。

NFS サービスでは Secure RPC を使用して、要求を出したユーザーをネットワーク上で認証します。このプロセスは、Secure NFS と呼ばれます。AUTH_DH 認証メカニズムは、Diffie-Hellman 認証で DES 暗号化を使用し、認証されたアクセスを保障します。AUTH_DH メカニズムは、AUTH_DES とも呼びます。

Secure NFS の設定と管理については、『Solaris のシステム管理 (資源管理とネットワークサービス)』の「Secure NFS システムの管理」を参照してください。
NIS+ テーブルの設定と cred テーブルへの名前の入力については、『Solaris のシステム管理 (ネーミングとディレクトリサービス : DNS、NIS、LDAP 編)』を参照してください。
RPC 認証手順の概要については、Diffie-Hellman 認証の実装を参照してください。

DES 暗号化

データ暗号化規格 (Data Encryption Standard、DES) 暗号化機能は 56 ビットの鍵を使用して、データを暗号化します。資格を持つ 2 人のユーザー、すなわちプリンシパルが同じ DES 鍵を知っている場合、その鍵を使用してテキストを暗号化または復号化することによって、プライベートに通信できます。DES は比較的高速な暗号化メカニズムです。DES チップは暗号化をより高速にします。ただし、チップがなくても、ソフトウェアで代用できます。

DES 鍵を使用する上での問題点は、同じ鍵で暗号化された多数のテキストメッセージを侵入者が収集することによって、鍵が発見されメッセージが解読される危険性があるということです。このため、Secure NFS などのセキュリティシステムは鍵を頻繁に変更します。

Kerberos 認証

Kerberos は、マサチューセッツ工科大学 (MIT) で開発された認証システムです。Kerberos は DES 暗号を使用します。Kerberos V4 は、Secure RPC ではサポートされていません。クライアント側には、RPCSEC_GSS を使用する Kerberos V5 がこのリリースに実装されています。詳細は、第 13 章「SEAM について」を参照してください。

Diffie-Hellman 認証

Diffie-Hellman (DH) のユーザー認証方式は簡単には破られません。クライアントとサーバーは、独自の非公開鍵と公開鍵を使って共通鍵を作り出します。非公開鍵は秘密鍵とも呼ばれます。クライアントとサーバーは、相互に合意した暗号化機能 (DES など) と共通鍵を使って相互に通信します。この方式は、以前の Solaris リリースの DES 認証と同じです。

認証では、送信側のシステムの共通鍵を使用して現在の時刻を暗号化する機能を利用します。受信側のシステムは、その現在の時刻を復号し、自分の時刻と照合します。クライアントとサーバーで時刻が同期していることを確認してください。

公開鍵と非公開鍵は、NIS または NIS+ のデータベースに格納されます。NIS では、これらの鍵を publickey マップに格納します。NIS+ では、cred テーブルに格納します。これらのファイルには、すべてのユーザーの公開鍵と非公開鍵が入っています。

システム管理者は、NIS マップまたは NIS+ のテーブルを設定して、ユーザーごとに公開鍵と非公開鍵を生成する必要があります。非公開鍵は、ユーザーのパスワードで暗号化されて格納されます。これにより、その非公開鍵はそのユーザーだけが知っていることになります。

Diffie-Hellman 認証の実装

この節では、DH 認証 (AUTH_DH) を使用するクライアントサーバーセッションにおける一連のトランザクションを説明します。

公開鍵と秘密鍵の生成

システム管理者は、認証を開始する前に、 newkey または nisaddcred コマンドを実行して公開鍵と秘密鍵を生成します。ユーザーごとに一意の公開鍵と秘密鍵が与えられます。公開鍵は、公開データベースに格納されます。秘密鍵は、暗号化された形式で、同じデータベースに格納されます。公開鍵と秘密鍵のペアを変更するには、chkey コマンドを使用します。

`keylogin` コマンドの実行

通常、ログインパスワードは Secure RPC パスワードと同じです。この場合、keylogin コマンドは必要ありません。ただし、これらのパスワードが異なる場合は、ユーザーはログインするときに keylogin コマンドを明示的に実行する必要があります。

keylogin コマンドを入力すると、Secure RPC パスワードの入力を求めるプロンプトが表示されます。コマンドは、このパスワードを使って秘密鍵を復号化します。次に keylogin コマンドは、復号化された秘密鍵をキーサーバーと呼ばれるプログラムに渡します。キーサーバーは、各コンピュータ上でローカルインスタンスを伴う RPC サービスです。キーサーバーは、復号化された秘密鍵を格納し、ユーザーとサーバーが Secure RPC トランザクションを開始するのを待機します。

ログインパスワードと RPC パスワードが一致している場合は、ログインプロセスは秘密鍵をキーサーバーに渡します。これらのパスワードが異なり、ユーザーが常に keylogin コマンドを実行する必要がある場合は、keylogin コマンドをユーザーの環境構成ファイル ( ~/.login、 ~/.cshrc、 ~/.profile ファイルなど) に設定することができます。この場合、ユーザーがログインしたときに、keylogin コマンドが自動的に実行されます。

対話鍵の生成

ユーザーがサーバーとトランザクションを開始すると、次の処理が行われます。

キーサーバーはランダムに対話鍵を生成します。
カーネルはこの対話鍵を使用して、クライアントのタイムスタンプの暗号化などを行います。
キーサーバーは、公開鍵データベースからサーバーの公開鍵を検索します。詳細は publickey(4) のマニュアルページを参照してください。
キーサーバーはクライアントの秘密鍵とサーバーの公開鍵を使用して、共通鍵を作成します。
キーサーバーは共通鍵を使用して対話鍵を暗号化します。

サーバーとの最初の接触

次に、暗号化したタイムスタンプと暗号化した対話鍵を含む伝送データがサーバーに送信されます。伝送データには資格とベリファイアが含まれます。資格は、次の 3 つの構成要素を持ちます。

クライアントのネット名
共通鍵で暗号化された対話鍵
対話鍵で暗号化された「ウィンドウ」

この場合の「ウィンドウ」とは、サーバーの時刻とクライアントのタイムスタンプとの間で許容される時間差のことで、クライアントが指定します。サーバーの時刻とクライアントのタイムスタンプとの間の差がウィンドウより大きい場合、サーバーはクライアントの要求を拒否します。通常の状態では、クライアントは RPC セッションを開始する前にサーバーと同期を取るため、クライアントの要求は拒否されません。

クライアントベリファイアは、次の要素で構成されます。

暗号化されたタイムスタンプ
指定したウィンドウの暗号化されたベリファイアから 1 を引いた値

ウィンドウベリファイアは、他人がユーザーになりすますのを防ぐために使用されます。なりすましを試みる人は、資格やベリファイアの暗号化された各フィールドに正しい情報の代わりにランダムなビットを記入するプログラムを作成します。サーバーはこの対話鍵を任意のランダム鍵に復号化し、それを使用してウィンドウとタイムスタンプを復号化しようと試みます。結果は、乱数が生成されるだけです。しかし、数千回の試行を重ねるうちには、このランダムなウィンドウとタイムスタンプのペアが認証システムを通過することが十分ありえます。ウィンドウベリファイアは、正しい資格の解読をより困難にします。

対話鍵の復号化

サーバーがクライアントから伝送データを受信すると、次の処理が行われます。

キーサーバーは、公開鍵データベース内でクライアントの公開鍵を検索します。
キーサーバーはクライアントの公開鍵とサーバーの秘密鍵を使用して、共通鍵を計算します。この共通鍵はクライアントが計算したものと同じです。共通鍵の計算は、秘密鍵を知っている必要があるため、そのサーバーとクライアント以外は計算できません。
カーネルは共通鍵を使用して、対話鍵を復号化します。
カーネルはキーサーバーを呼び出して、復号化された対話鍵によりクライアントのタイムスタンプを復号化します。

サーバーへの格納情報

サーバーは、クライアントのタイムスタンプを復号化したあと、次の 4 つの情報を資格テーブルに格納します。

クライアントのコンピュータ名
対話鍵
ウィンドウ
クライアントのタイムスタンプ

サーバーは、最初の 3 つの情報を将来の使用のために格納します。サーバーはタイムスタンプを格納して、同じタイムスタンプが再度使用できないようにします。サーバーは、最後に参照したタイムスタンプよりも時間的に後のタイムスタンプだけを受け付けるため、同じタイムスタンプのトランザクションはすべて拒否されることが保証されます。

注 –

この手順において暗黙的に仮定されているのは呼び出し側の名前であり、何らかの方法でこの名前を認証する必要があります。キーサーバーは、呼び出し側を認証するときに、DES 認証を使用できません。DES 認証を使用すると、デッドロックが発生するためです。キーサーバーは、ユーザー ID (UID) ごとに秘密鍵を格納し、ローカルのルートプロセスへの要求だけを許可することによってこの問題を解決します。

ベリファイアをクライントに返す

サーバーは、ベリファイアをクライアントに返します。ベリファイアには、次の構成要素が含まれます。

サーバーが自分の資格キャッシュに記録するインデックス ID
クライアントのタイムスタンプから 1 を引いた値。対話鍵によって暗号化される

タイムスタンプから 1 を引くのは、タイムスタンプを無効化するためです。これによって、タイムスタンプをクライアントのベリファイアとして再利用できなくなります。

クライアントによるサーバーの認証

クライアントがベリファイアを受信し、そのサーバーを認証します。クライアントは、このベリファイアを送信できるのはサーバーだけであることを知っています。その理由は、クライアントが送信したタイムスタンプの内容を知っているのはサーバーだけだからです。

追加のトランザクション

一番目以降のすべてのトランザクションごとに、クライアントは 2 番目のトランザクションでインデックス ID をサーバーに返し、もう 1 つの暗号化されたタイムスタンプを送信します。サーバーは、クライアントのタイムスタンプから 1 を引いた値を対話鍵で暗号化して、返信します。

Diffie-Hellman 認証の管理

システム管理者は、ネットワークを安全にするためのポリシーをネットワーク上に実装できます。必要なセキュリティのレベルはサイトによって異なります。この節では、ネットワークセキュリティに関連するいくつかの作業手順を説明します。

キーサーバーを再起動する方法

スーパーユーザーになるか、同等の役割を引き受けます。

keyserv デーモンが動作しているか確認します。

# ps -ef | grep keyserv
root   100      1  16   Apr 11    ?         0:00 /usr/sbin/keyserv
root  2215   2211   5   09:57:28  pts/0     0:00 grep keyserv

プロセスが動作していない場合は、キーサーバーを起動します。
# /usr/sbin/keyserv

Diffie-Hellman 認証のために NIS+ の資格に `root` 鍵を設定する方法

NIS+ セキュリティの詳細については、『Solaris のシステム管理 (ネーミングとディレクトリサービス : FNS、NIS+ 編)』を参照してください。

スーパーユーザーになるか、同等の役割を引き受けます。

/etc/nsswitch.conf ファイルを編集して、次の行を追加します。
publickey: nisplus

NIS+ クライアントを起動します。
# nisinit -cH hostname
hostname は、そのテーブルにクライアントマシン用のエントリを持つ、信頼されている NIS+ サーバー名です。

次のコマンドを入力して、クライアントを cred テーブルに追加します。
# nisaddcred local # nisaddcred des

keylogin コマンドを使用して、設定を確認します。

パスワードを求めるプロンプトが出たら、この手順は正常に終了しています。

例 — NIS+ クライアント上で `root` の新しい鍵を設定する

次の例は、ホスト pluto を使用して、earth を NIS+ クライアントとして設定しています。警告は無視できます。keylogin コマンドが受け付けられて、earth が Secure NIS+ クライアントとして正しく設定されていることを確認しています。

# nisinit -cH pluto
NIS Server/Client setup utility.
This machine is in the North.Abc.COM. directory.
Setting up NIS+ client ...
All done.
# nisaddcred local
# nisaddcred des 
DES principal name : unix.earth@North.Abc.COM
Adding new key for unix.earth@North.Abc.Com (earth.North.Abc.COM.)
 
Network password: xxx Press Return
Warning, password differs from login password.
Retype password: xxx Press Return
 
# keylogin
Password:
#

Diffie-Hellman 認証のために NIS+ の資格を使用する新しいユーザー鍵を設定する方法

次のコマンドを入力して、ユーザーをルートマスターサーバー上の cred テーブルに追加します。
# nisaddcred -p unix.UID@domain-name -P username.domain-name. des
この場合、username.domain-name の終わりにピリオド (.) を付けてください。

クライアントとしてログインし、keylogin コマンドを入力して、設定を確認します。

例 — NIS+ ユーザー用の新しい鍵を設定する

次の例は、george という名前のユーザーに DES 承認がどのように与えられるかを示しています。

# nisaddcred -p unix.1234@North.Abc.com -P george.North.Abc.COM. des
DES principal name : unix.1234@North.Abc.COM
Adding new key for unix.1234@North.Abc.COM (george.North.Abc.COM.)

Password:
Retype password:

# rlogin rootmaster -l george
# keylogin
Password:
#

Diffie-Hellman 認証と NIS の資格を使用して `root` 鍵を設定する方法

クライアント上でスーパーユーザーになるか、同等の役割を引き受けます。

/etc/nsswitch.conf ファイルを編集して、次の行を追加します。
publickey: nis

newkey コマンドを使用して、新しい鍵のペアを作成します。
# newkey -h hostname
hostname は、クライアント名です。

例 — NIS クライアント上で `root` の新しい鍵を設定する

次の例では、earth を Secure NIS クライアントとして設定します。

# newkey -h earth
Adding new key for unix.earth@North.Abc.COM
New Password:
Retype password:
Please wait for the database to get updated...
Your new key has been successfully stored away.
#

Diffie-Hellman 認証と NIS の資格を使用する新しいユーザー鍵を設定する方法

スーパーユーザーとして NIS マスターサーバーにログインするか、同等の役割を引き受けます。

NIS マスターサーバーにログインしたときにユーザーの新しい鍵を作成できるのは、システム管理者だけです。

ユーザーの新しい鍵を作成します。

# newkey -u username

username はユーザー名です。システムはパスワードを求めるプロンプトを出します。汎用パスワードを入力できます。非公開鍵は、汎用パスワードを使用して暗号化されて格納されます。

# newkey -u george
Adding new key for unix.12345@Abc.North.Acme.COM
New Password:
Retype password:
Please wait for the database to get updated...
Your new key has been successfully stored away.
#

ログインして chkey -p コマンドを入力するように、ユーザーに伝えます。

このコマンドでは、そのユーザーは自分だけが知っているパスワードを使用して、自分の非公開鍵を暗号化し直すことができます。

earth% chkey -p
Updating nis publickey database.
Reencrypting key for unix.12345@Abc.North.Acme.COM
Please enter the Secure-RPC password for george:
Please enter the login password for george:
Sending key change request to pluto...
#

注 –

chkey コマンドを使用すると、新しい鍵のペアをユーザーに作成できます。

Diffie-Hellman 認証でファイルを共有およびマウントする方法

前提条件

Diffie-Hellman の publickey 認証がネットワークで有効である必要があります。Diffie-Hellman 認証のために NIS+ の資格に root 鍵を設定する方法および Diffie-Hellman 認証と NIS の資格を使用して root 鍵を設定する方法を参照してください。

Diffie-Hellman 認証でファイルシステムを共有する

スーパーユーザーになるか、同等の役割を引き受けます。

Diffie-Hellman 認証でファイルシステムを共有します。
# share -F nfs -o sec=dh /filesystem

Diffie-Hellman 認証でファイルシステムをマウントする

スーパーユーザーになるか、同等の役割を引き受けます。

Diffie-Hellman 認証でファイルシステムをマウントします。
# mount -F nfs -o sec=dh server:resource mountpoint
-o sec=dh オプションは、AUTH_DH 認証でファイルシステムをマウントします。

第 10 章 PAM の使用

この章では、Pluggable Authentication Module (PAM) フレームワークについて説明します。PAM は、認証サービスを「プラグイン」する方法を提供して、複数の認証サービスを使用できるようにします。

PAM (概要)

Pluggable Authentication Module (PAM) フレームワークを使用すると、login、ftp、telnet などのシステムエントリサービスを変更しなくても、新しい認証技術を「プラグイン」できるようになります。また、PAM を使用すると、UNIX ログインを Kerberos のような他のセキュリティメカニズムと統合できます。また、アカウント、セッション、およびパスワードの管理メカニズムも「プラグイン」できます。

PAM を使用する利点

PAM を使用すると、システムエントリサービス (ftp、login、telnet、rsh など) のユーザー認証を構成できます。PAM には次の利点があります。

柔軟な構成ポリシー
- アプリケーションごとの認証ポリシー
- デフォルトの認証メカニズムを選択する機能
- 高度なセキュリティシステムにおける複数のパスワード
一般ユーザーにも使いやすい
- メカニズムが異なってもパスワードが同じであれば、パスワードを再入力する必要がない
- ユーザーが複数のコマンドを入力しなくても、複数の認証方式のパスワードを求めるプロンプトを表示できる
オプションパラメータをユーザー認証サービスに渡す機能

PAM の構成要素

PAM ソフトウェアは、ライブラリ、いくつかのモジュール、および構成ファイルで構成されます。いくつかのコマンドまたはデーモンの新しいバージョンは、PAM インタフェースを利用できます。

次の図は、アプリケーション、PAM ライブラリ、pam.conf ファイル、および PAM モジュール間の関係を示します。

図 10–1 PAM の動作

PAM ライブラリが PAM モジュールとアプリケーションの間に位置しています。

アプリケーション (ftp、telnet、および login) は、PAM ライブラリを使用して構成ポリシーを呼び出します。pam.conf ファイルは、使用するモジュールを定義して、各アプリケーションがモジュールを使用する順番を定義します。モジュールからの応答は、ライブラリ経由でアプリケーションに戻されます。

次の節では、PAM の構成要素とアプリケーションの関係について説明します。

PAM ライブラリ

PAM ライブラリは、適切なモジュールをロードし、スタッキング処理を管理するためのフレームワークを提供します。また、すべてのモジュールがプラグインできる汎用構造になっています。詳細は、pam(3PAM) のマニュアルページを参照してください。

パスワードマッピング機能

スタッキング機能では、ユーザーが複数のパスワードを覚えておく必要があります。「パスワードマッピング機能」を使用すると、基本パスワードから他のパスワードを復号できるので、ユーザーが複数のパスワードを覚えたり入力したりする必要はありません。各認証メカニズム間でパスワードの同期を取るためのオプションもあります。ただし、スタック内で使用される最も安全性の低いパスワード方式によってメカニズムのセキュリティが制限されてしまうため、この方法ではセキュリティの危険性が増すおそれがあります。

Solaris 9 リリースにおける PAM への変更

Solaris 9 では、PAM サービスがいくつかの点で拡張されています。ここでは、最も重要な変更点について説明します。

スタッキングを適切に行うために、pam_unix モジュールが個々の単一サービスモジュールに分割されました。これらのモジュールの機能は、pam_unix モジュールと同等です。これらの機能は、次の各モジュールで提供されます。
- pam_authtok_get
- pam_authtok_check
- pam_authtok_store
- pam_unix_auth
- pam_dhkeys
- pam_passwd_auth
新しいモジュールについては、PAM モジュールを参照してください。
ssh サービス名が追加されました。PAM サービスについては、PAM で有効なサービス名を参照してください。
PAM 構成ファイルが更新されました。構成ファイルについては、一般的な pam.conf ファイルを参照してください。

Solaris 9 Update 2 リリースにおける PAM への変更

Update 2 には、新しいバインディング制御フラグが含まれています。このフラグの導入によって、追加の認証をスキップすることが可能になります。ただし、スキップするためには、そのサービスモジュールが正常に終わるだけでなく、その前に実行されたすべての必須モジュールが正常に終わっていなければなりません。この制御フラグについては、pam.conf(4) のマニュアルページと PAM 制御フラグを参照してください。

PAM (手順)

この節では、PAM のフレームワークを完全に機能させるために必要な作業について説明します。特に、PAM 構成ファイルに関連するセキュリティのいくつかの問題について注意する必要があります。

PAM (作業マップ)

作業	説明	参照先
PAM のインストールを計画する	ソフトウェア構成処理を開始する前に、構成を検討および決定する	PAM の計画
新しい PAM モジュールを追加する	必要に応じて、サイト固有のモジュールを作成およびインストールし、汎用ソフトウェアにない要件に対応する。この手順はインストール処理を含む	PAM モジュールを追加する方法
`~/.rhosts` によるアクセスを拒否する	`~/.rhosts` によるアクセスを拒否して、セキュリティを強化する手順	PAM を使用して、リモートシステムからの非承認アクセスを防ぐ方法
エラーレポートを開始する	`syslog` を使用して PAM エラーメッセージのレポートを開始する	PAM のエラーレポートを開始する方法

PAM の計画

ユーザーの環境に最適な PAM の使用方法を決定するために、次の問題から始めます。

何が必要か、特にどのモジュールを選択するかを決定する
特別な注意が必要なサービスを確認する。適宜、OTHER を使用する
モジュールを実行する順番を決定する
各モジュールに対する制御フラグを選択する
各モジュールに必要なオプションを選択する

ここで、PAM 構成ファイルを変更する前に次のことを考慮することをお勧めします。

すべてのアプリケーションを指定しなくてもいいように、モジュールタイプごとに OTHER エントリを使用する
sufficient 制御フラグと optional 制御フラグのセキュリティへの影響を確認する
モジュールに関連するマニュアルページを参照する。これらのマニュアルページには、各モジュールの機能、使用可能なオプション、スタック内のモジュール間の相互作用などの説明がある

注意 –
PAM 構成ファイルの構成を間違えたり壊したりすると、スーパーユーザーでもログインできなくなる可能性があります。この場合、sulogin コマンドは PAM を使用しないので、スーパーユーザーは、マシンをシングルユーザーモードでブートして問題を解決する必要があります。

/etc/pam.conf ファイルを変更したあと、スーパーユーザーとしてログインしている間にできる限り調査します。変更によって影響を受ける可能性があるコマンドは、すべてテストしてください。たとえば、新しいモジュールを telnet サービスに追加した場合、telnet コマンドを使用して、行なった変更が期待どおりに動作しているかどうかを検証します。

PAM モジュールを追加する方法

スーパーユーザーになるか、同等の役割を引き受けます。

使用する制御フラグとオプションを決定します。

モジュールについては、PAM モジュールを参照してください。

新しいモジュールを /usr/lib/security/sparcv9 にコピーします。

Solaris 8 の場合は、/usr/lib/security にコピーします。

モジュールファイルの所有者が root で、そのアクセス権が 555 になるように、アクセス権を設定します。

PAM 構成ファイル /etc/pam.conf を編集して、このモジュールを適切なサービスに追加します。

検証

構成ファイルが間違って構成されているおそれもあるので、システムをリブートする前にテストを行う必要があります。システムをリブートする前に、rlogin、su、および telnet を実行してください。サービスは、システムをブートしたときに 1 度だけ生成されるデーモンである場合があります。その場合には、システムをリブートしてから、モジュールが追加されていることを確認する必要があります。

PAM を使用して、リモートシステムからの非承認アクセスを防ぐ方法

PAM 構成ファイルから「rlogin auth rhosts_auth.so.1」エントリを削除します。この手順によって、rlogin セッション中、 ~/.rhosts ファイルは読み取られなくなり、ローカルシステムに認証されていないリモートシステムからのアクセスを防止できます。~/.rhosts ファイルまたは /etc/hosts.equiv ファイルの存在またはその内容にかかわらず、すべての rlogin アクセスにはパスワードが必要になります。

注 –

~/.rhosts ファイルへのその他の非承認アクセスを防ぐには、rsh サービスも無効にする必要があります。サービスを無効にする最良の方法は、/etc/inetd.conf ファイルからサービスエントリを削除することです。PAM 構成ファイルを変更しても、サービスを無効にはできません。

PAM のエラーレポートを開始する方法

/etc/syslog.conf ファイルを編集して、PAM エラーレポートに次のエントリを必要に応じて追加します。
- auth.alert — すぐに修正する必要がある状態についてのメッセージ
- auth.crit – 致命的なメッセージ
- auth.err – エラーメッセージ
- auth.info – 情報提供用メッセージ
- auth.debug – デバッグメッセージ

syslog デーモンを再起動するか、SIGHUP シグナルを syslog デーモンに送信して、PAM のエラー報告を有効にします。

例 — PAM のエラーレポートを開始する

次の例では、すべての警告メッセージを画面に表示します。致命的なメッセージはスーパーユーザーに電子メールで送信されます。情報メッセージとデバッグ用メッセージは、/var/log/pamlog ファイルに追加されます。

auth.alert	/dev/console
auth.crit	'root'
auth.info;auth.debug	/var/log/pamlog

ログ内の各行は、タイムスタンプ、メッセージを生成したシステム名、およびメッセージ本体で構成されます。pamlog ファイルには、大量の情報が記録される可能性があります。

PAM (参照)

PAM は、実行時に取り外しが可能なモジュールを使用して、システムエントリサービスの認証を提供します。スタッキング機能を利用すると、複数のサービスを使用してユーザーを認証できます。また、パスワードマッピング機能を利用すると、ユーザーは複数のパスワードを覚える必要がなくなります。

PAM モジュール

各 PAM モジュールは、特定のメカニズムを実装します。PAM 認証を設定するときは、モジュールとモジュールタイプの両方を指定する必要があります。モジュールタイプは、モジュールが実行する処理を定義します。複数のモジュールタイプ (認証、アカウント管理、セッション管理、またはパスワード管理) を各モジュールに関連付けることができます。

次の表では、各 PAM モジュールについて、モジュール名、モジュールファイル名、および説明を示します。各モジュールのパスは、インストールされている Solaris で使用できる命令によって異なります。モジュールのデフォルトのパスは、/usr/lib/security/ $ISA です。$ISA の値は、sparc または i386 です。詳細は、isalist(5) のマニュアルページを参照してください。

表 10–1 PAM モジュール


モジュール名とモジュールファイル名	説明
`authtok_check` `pam_authtok_check.so.1`	パスワード管理をサポートする。このモジュールは、パスワードのさまざまなチェックを行う。たとえば、パスワードの長さをチェックしたり、ログイン名を循環的にシフトしたものとパスワードを比較してその複雑さを検証したり、あるいは新しいパスワードと古いパスワードを比較して変更された文字数をチェックしたりして、ユーザーが単純なパスワードを使用しないように支援する。詳細は、`pam_authtok_check(5)` のマニュアルページを参照
`authtok_get` `pam_authtok_get.so.1`	認証およびパスワード用にパスワードプロンプト機能を提供する。詳細は、`pam_authtok_get(5)` のマニュアルページを参照
`authtok_store` `pam_authtok_store.so.1`	認証だけをサポートする。このモジュールは、ユーザーの認証トークンを更新する。正常に更新したトークンは、指定されたレポジトリまたはデフォルトのレポジトリに格納する。詳細は、`pam_authtok_store(5)` のマニュアルページを参照
`dhkeys` `pam_dhkeys.so.1`	認証で使用する Diffie-Hellman 鍵の管理をサポートする。このモジュールは、Secure RPC 認証と Secure RPC 認証トークンの管理をサポートする。詳細は、`pam_dhkeys(5)` のマニュアルページを参照
`dial_auth` `pam_dial_auth.so.1`	認証だけで使用する。このモジュールは、`/etc/dialups` ファイルと `/etc/d_passwd` ファイルに格納されたデータを、認証用として使用する。主に `login` コマンドで使用される。詳細は、`pam_dial_auth(5)` のマニュアルページを参照
`krb5` `pam_krb5_auth.so.1`	認証、アカウント管理、セッション管理、およびパスワード管理をサポートする。認証には Kerberos 資格が使用される。詳細は、`pam_krb5(5)` のマニュアルページを参照
`ldap` `pam_ldap.so.1`	認証とパスワード管理をサポートする。LDAP サーバーのデータの認証に使用される。詳細は、`pam_ldap(5)` のマニュアルページを参照
`projects` `pam_projects.so.1`	アカウント管理をサポートする。詳細は、`pam_projects(5)` のマニュアルページを参照
`rhosts_auth` `pam_rhosts_auth.so.1`	認証だけで使用する。このモジュールは、`ruserok()` ルーチンによって `~/.rhosts` および `/etc/host.equiv` ファイルに格納されたデータを使用する。主に `rlogin` と `rsh` コマンドで使用する。詳細は、`pam_rhosts_auth(5)` のマニュアルページを参照
`roles` `pam_roles.so.1`	アカウント管理だけをサポートする。RBAC の `user_attr` データベースが、ユーザーが引き受けることができる役割を決定する。詳細は、`pam_roles(5)` のマニュアルページを参照
`sample` `pam_sample.so.1`	認証、アカウント管理、セッション管理、およびパスワード管理をサポートする。テストに使用する。詳細は、`pam_sample(5)` のマニュアルページを参照
`smartcard` `pam_smartcard.so.1`	認証だけをサポートする。詳細は、`pam_smartcard(5)` のマニュアルページを参照
`unix` `pam_unix.so.1`	認証、アカウント管理、セッション管理、およびパスワード管理をサポートする。このモジュールでは、4 種類すべてのモジュールタイプを定義できる。UNIX パスワードを認証に使用する。 Solaris 環境では、パスワードを取得するための適切なネームサービスの選択は、`/etc/nsswitch.conf` ファイルで制御する。詳細は、`pam_unix(5)` のマニュアルページを参照
`unix_account` `pam_unix_account.so.1`	アカウント管理をサポートする。このモジュールは、`nsswitch.conf` ファイルに指定されたレジストリのパスワード有効期限情報を取得して、パスワードおよびユーザーアカウントの期限が切れていないことを確認する。詳細は、`pam_unix_account(5)` のマニュアルページを参照
`unix_auth` `pam_unix_auth.so.1`	認証をサポートする。このモジュールは、PAM ハンドルに含まれているパスワードを検証する。このモジュールはまた、ユーザーのパスワードが、指定されたレポジトリまたはデフォルトのレポジトリに格納されているパスワードと一致しているか確認する。詳細は、`pam_unix_auth(5)` のマニュアルページを参照
`unix_session` `pam_unix_session.so.1`	セッション管理をサポートする。このモジュールは、セッション管理を開始するために、`/var/adm/lastlog` ファイルを更新する。詳細は、`pam_unix_session(5)` のマニュアルページを参照

セキュリティ上の理由から、これらのモジュールファイルの所有者は root である必要があり、また、group と other に書き込み権があってはなりません。ファイルの所有者が root でない場合、PAM はモジュールをロードしません。

PAM モジュールのタイプ

モジュールタイプはモジュールのインタフェースを定義するため、PAM モジュールのタイプを理解する必要があります。実行時 PAM モジュールには、次の 4 つのタイプがあります。

「認証モジュール」はユーザーの認証を行う。さらに、このモジュールでは、資格を設定、更新、または削除できる。そのほか、認証モジュールは、ユーザーを識別するための管理ツールを提供する
「アカウントモジュール」は、パスワードの有効期限、アカウントの有効期限、およびアクセス時間制限を確認する。アカウントモジュールは、認証モジュールでユーザーを識別したあと、そのユーザーにアクセス権を与えるべきかどうかを決定する。
「セッションモジュール」は、認証セッションの開閉を管理する。セッションモジュールは、動作を記録したり、セッション終了後のクリーンアップを実行したりできる。
「パスワードモジュール」によって、実際のパスワードを変更する。

PAM 構成ファイル

PAM 構成ファイル /etc/pam.conf は、使用する認証サービスとその使用順序を決定します。このファイルを編集すると、システムエントリアプリケーションごとに認証メカニズムを選択できます。

PAM 構成ファイルの構文

PAM 構成ファイルは、次の構文のエントリで構成されます。

service_name module_type control_flag module_path module_options

`service_name`	サービス名 (`ftp`、`login`、`telnet` など)
`module_type`	サービスのモジュールタイプ。詳細は、PAM モジュールのタイプを参照
`control_flag`	モジュールの継続または失敗の動作を決定する
`module_path`	サービスを実装するライブラリオブジェクトへのパスを指定する
`module_options`	サービスモジュールに渡すオプションを指定する

pam.conf ファイルにコメントを追加するには、コメント行の最初に # (ポンド記号) を入力します。フィールドを区切るには、空白またはタブを使用します。

注 –

行のフィールド数が 4 つ未満の場合、module_type または control_flag に無効な値が指定されている場合、または指定したモジュールが存在しない場合は、PAM 構成ファイル内のエントリは無視されます。

PAM で有効なサービス名

下記の表に、次の項目を示します。

有効なサービス名
そのサービスで使用できるモジュールタイプ
そのサービス名に関連するデーモンまたはコマンド

サービスによっては適用できないモジュールタイプがあります。たとえば、passsrd モジュールタイプは、passwd コマンドだけに適用できます。また、passwd コマンドは認証と関連がないため、このサービスに関連付けられた auth モジュールタイプはありません。

表 10–2 /etc/pam.conf ファイルの有効なサービス名


サービス名	デーモンまたはコマンド	適用可能なモジュールタイプ
`cron`	`/usr/sbin/cron`	`auth、account`
`dtlogin`	`/usr/dt/bin/dtlogin`	`auth、account、session`
`dtsession`	`/usr/dt/bin/dtsession`	`auth`
`ftp`	`/usr/sbin/in.ftpd`	`auth、account、session`
`init`	`/usr/sbin/init`	`session`
`login`	`/usr/bin/login`	`auth、account、session`
`passwd`	`/usr/bin/passwd`	`password`
`ppp`	`/usr/bin/ppp`	`auth、account、session`
`rexd`	`/usr/sbin/rpc.rexd`	`account、session`
`rlogin`	`/usr/sbin/in.rlogind`	`auth、account、session`
`rsh`	`/usr/sbin/in.rshd`	`auth、account、session`
`sac`	`/usr/lib/saf/sac`	`session`
`ssh`	`/usr/bin/ssh`	`auth、account、session`
`su`	`/usr/bin/su`	`auth、account`
`telnet`	`/usr/sbin/in.telnetd`	`auth、account、session`
`ttymon`	`/usr/lib/saf/ttymon`	`session`
`uucp`	`/usr/sbin/in.uucpd`	`auth、account、session`

PAM 制御フラグ

モジュールの続行動作または失敗動作を決定するには、PAM 構成ファイル /etc/pam.conf のエントリごとに「制御フラグ」を選択する必要があります。スタック内の各モジュールは、要求の成功や失敗を決定できます。

続行動作では、後続のモジュールをチェックするかどうかを定義します。特定のモジュールの応答によっては、追加モジュールをスキップできます。

失敗動作では、エラーメッセージのログや報告をどのように行うかを定義します。失敗には任意 (optional) と必須 (required) があります。必須の場合は、他のモジュールが正常であっても要求は必ず失敗に終わります。任意の場合は、要求が必ず失敗に終わるとは限りません。

これらのフラグはすべてのモジュールタイプに適用されますが、次の説明では、これらのフラグは認証モジュールで使用されていると仮定します。制御フラグは、次のとおりです。

binding – この制御フラグが適用されたモジュールが成功し、かつそれ以前の必須モジュールの中に失敗したものがない場合は、残りのモジュールをスキップします。失敗が返された場合は、必須の失敗を記録し、スタックの処理を続けます。

binding 制御フラグは、そのモジュールが成功した場合にそれ以後のモジュールのチェックを行わないことを除けば、 required 制御フラグに似ています。このフラグが適用されたモジュールで失敗が 1 つでもあると、ほかのモジュールからの応答がどうであれ、要求は成功とはみなされません。このフラグが適用されたモジュールが成功すると、それ以前の必須モジュールの中に失敗したものがなければ、要求は成功とみなされます。
required – この制御フラグが適用されたモジュールが成功した場合は、必須の成功を記録し、後続モジュールのチェックを続けます。モジュールが失敗した場合は、これが最初の必須の失敗であれば、エラーメッセージを保存してからスタックのチェックを続けます。これが最初の失敗でなければ、スタックのチェックを続けます。

要求が成功するために特定のモジュールの成功が欠かせない場合は、required 制御フラグを使用すべきです。このフラグが適用されたモジュールで失敗が 1 つでもあると、ほかのモジュールからの応答がどうであれ、要求は成功とはみなされません。このフラグが適用されたモジュールの 1 つが成功しても、要求の成功を意味するわけではありません。要求が成功するためには、スタックのすべての必須モジュールからの応答が成功でなければなりません。
requisite – この制御フラグが適用されたモジュールが成功した場合は、必須の成功を記録し、後続のモジュールのチェックを続けます。モジュールが失敗した場合は、必須の失敗を記録し、最初の必須の失敗であるというエラーメッセージを返し、それ以後のチェックをスキップします。

requisite 制御フラグは、モジュールが失敗した場合にそれ以後のモジュールのチェックを行わないことを除けば、 required 制御フラグに似ています。このフラグが適用されたモジュールで失敗が 1 つでもあると、ほかのモジュールからの応答がどうであれ、要求は成功とはみなされません。このフラグが適用されたモジュールの 1 つが成功しても、要求の成功を意味するわけではありません。要求が成功するためには、スタックのすべての必須モジュールからの応答が成功でなければなりません。
optional – この制御フラグが適用されたモジュールが成功した場合は、任意の成功を記録し、スタックのチェックを続けます。モジュールが失敗した場合は、任意の失敗を記録し、スタックのチェックを続けます。

optional 制御フラグは、ユーザーを認証するにはスタック内の他のモジュールのどれかが成功すれば十分であるという場合に使用します。このフラグは特定のモジュールが成功するということがそれほど重要でない場合に使用します。要求の成功または失敗は、ほかの必須の失敗または成功によって決まります。

ユーザーが作業を行ううえでアクセス権を持つ必要があるモジュールは、optional フラグを付けないでください。
sufficient – この制御フラグが適用されたモジュールが成功し、かつそれ以前の必須モジュールの中に失敗したものがない場合は、残りのモジュールをスキップします。モジュールが失敗した場合は、任意の失敗を記録し、スタックのチェックを続けます。

sufficient 制御フラグは、モジュールが成功した場合にそれ以後のモジュールのチェックを行わないことを除けば、 optional 制御フラグに似ています。このフラグが適用されたモジュールが成功すると、それ以前の必須モジュールの中に失敗したものがなければ、要求は成功とみなされます。このフラグが適用されたモジュールが失敗すると、成功したモジュールが以前になければ、要求は失敗とみなされます。

これらの制御フラグの詳細については、次の節を参照してください。次の節では、デフォルトの /etc/pam.conf ファイルについて説明します。

一般的な `pam.conf` ファイル

一般的な /etc/pam.conf ファイルには、次の動作が指定されています。

login コマンドを実行したときは、pam_authtok_get、pam_dhkeys、pam_auth_unix、および pam_dial_auth モジュールの認証が成功する必要があります。
rlogin コマンドを実行したときは、pam_rhost_auth の認証に失敗した場合、pam_authtok_get、pam_dhkeys、および pam_auth_unix モジュールの認証が成功する必要があります。
sufficient 制御フラグは、 rlogin コマンドを実行したとき、pam_rhost_auth モジュールによる認証が成功すれば十分であることを意味します。次のエントリは無視されます。
認証を必要とするその他のコマンドが実行されたときは、ほとんどの場合、pam_authtok_get、 pam_dhkeys、および pam_auth_unix モジュールの認証が成功する必要があります。
rsh コマンドが実行されたときは、pam_rhost_auth モジュールの認証には sufficient フラグが適用されます。pam_rhost_auth モジュールの認証が成功した場合は、それ以外の認証は必要ありません。

OTHER サービス名を使用すると、認証を必要とするがこのファイルには含まれていない他のコマンドに対するデフォルトとして設定できます。OTHER オプションを使用すると、同じモジュールを使用する多数のコマンドを 1 つのエントリだけでカバーできるため、ファイルの管理が簡単になります。また、OTHER サービス名を「すべてを捕捉する」と言う意味で使用すると、1 つのモジュールですべてのアクセスをカバーできます。通常、OTHER エントリは、各モジュールタイプのセクションの最後に指定します。

通常、module_path のエントリには「ルートからのパス名」を指定します。module_path に入力したファイル名がスラッシュ (/) で始まらない場合、そのファイル名の前にパス /usr/lib/security/$ISA が付きます。モジュールが他のディレクトリにある場合は、フルパスを使用する必要があります。module_options の値は、そのモジュールのマニュアルページに記載されています。たとえば、UNIX モジュールは、pam_unix(5) のマニュアルページに記載されています。

login   auth required           pam_authtok_get.so.1
login   auth required           pam_dhkeys.so.1
login   auth required           pam_unix_auth.so.1
login   auth required           pam_dial_auth.so.1

この例の login サービスでは、4 つの認証モジュールの認証がすべて必須になっています。login コマンドは、いずれかのモジュールからエラーが返されると失敗します。

第 11 章 Solaris Secure Shell の使用 (手順)

Solaris Secure Shell を使用すると、セキュリティ保護されていないネットワーク上のリモートホストに、安全にアクセスすることができます。Solaris Secure Shell には、リモートログインおよびリモートファイル転送を行うコマンドが組み込まれています。この章の内容は次のとおりです。

Solaris Secure Shell の概要

Solaris Secure Shell の認証は、パスワードまたは公開鍵、あるいはその両方を使用して行われます。すべてのネットワークトラフィックは暗号化されます。このため、Solaris Secure Shell では、悪意を持つ侵入者が傍受した通信を読んだり、偽装したりすることはできません。

Solaris Secure Shell は、オンデマンドタイプの仮想プライベートネットワーク (VPN) として使用することもできます。VPN では、暗号化されたネットワークを介して、ローカルマシンとリモートマシン間で、 X Window System のトラフィックを転送したり個々のポート番号を接続したりできます。

Solaris Secure Shell では、次の操作を行うことができます。

セキュリティ保護されていないネットワークを介して、別のホストに安全にログインする
2 つのホスト間でファイルを安全にコピーする
リモートホスト上でコマンドを安全に実行する

Solaris Secure Shell では、2 つのバージョンの Secure Shell プロトコルを利用できます。バージョン 1 は、Secure Shell プロトコルのオリジナルバージョンです。バージョン 2 は、安全性が向上し、バージョン 1 の基本的なセキュリティ設計上の欠点が修正されています。バージョン 1 は、バージョン 2 へ移行するユーザーを支援する目的だけに提供しています。バージョン 1 は、できるだけ使用しないでください。

注 –

このマニュアルでは、v1 はバージョン 1、v2 はバージョン 2 を表しています。

Solaris Secure Shell 認証の要件は、次のとおりです。

ユーザー認証 – ユーザーは、次のいずれかによって認証されます。

パスワード – ユーザーは、ログインプロセスアカウントのパスワードを入力します。

公開鍵 – ユーザーは、公開鍵と非公開鍵のペアを作成します。これらは、ローカルホストに格納されます。リモートホストには公開鍵が渡されます。公開鍵は、認証を完了するために必要です。

非公開鍵を管理するホストから、認証を行うホストに必要な公開鍵が渡されます。公開鍵認証は、パスワード認証よりも強力な認証メカニズムです。これは、非公開鍵がネットワーク上を移動しないためです。公開鍵と非公開鍵のペアは、ユーザーのホームディレクトリの .ssh サブディレクトリの下に格納されます。次の表に、公開鍵と非公開鍵を格納する ID ファイルのデフォルト名を示します。

表 11–1 SSH ID ファイルの命名規則


非公開鍵、公開鍵	暗号化方式とプロトコルのバージョン
`identity`、`identity.pub`	RSA v1
`id_rsa`、`id_rsa.pub`	RSA v2
`id_dsa`、`id_dsa.pub`	DSA v2

ホスト認証 – ホスト認証では、ローカルホストの公開鍵に対するアクセス権をリモートホストに与える必要があります。ローカルホストの公開鍵のコピーは、リモートホストの $HOME/.ssh/known_hosts に格納されます。

次の表は、認証方式、互換性のあるプロトコルのバージョン、ローカルホストとリモートホストの要件、およびセキュリティレベルの一覧です。デフォルトの認証方式は、パスワードベースの認証です。

表 11–2 Solaris Secure Shell の認証方式


認証方式 (プロトコルのバージョン)	ローカルホストの要件	リモートホストの要件	セキュリティレベル
パスワードベース (v1 または v2)	ユーザーアカウント	ユーザーアカウント	中
RSA/DSA 公開鍵 (v2)	ユーザーアカウント `$HOME/.ssh/id_rsa` または `$HOME/.ssh/id_dsa` に非公開鍵 `$HOME/.ssh/id_rsa.pub` または `$HOME/.ssh/id_dsa.pub` に公開鍵	ユーザーアカウント `$HOME/.ssh/authorized_keys` にユーザーの公開鍵 (`id_rsa.pub` または `id_dsa.pub` )	強
RSA 公開鍵 (v1)	ユーザーアカウント `$HOME/.ssh/identity` に非公開鍵 `$HOME/.ssh/identity.pub` に公開鍵	ユーザーアカウント `$HOME/.ssh/authorized_keys` にユーザーの公開鍵 (`identity.pub` )	強
`.rhosts` と RSA (v1)	ユーザーアカウント	ユーザーアカウント `/etc/hosts.equiv`、 `/etc/shosts.equiv`、`$HOME/.rhosts`、または `$HOME/.shosts` にローカルホスト名 `$HOME/.ssh/known_hosts` または `/etc/ssh/ssh_known_hosts` にローカルホスト公開鍵	中
`.rhosts` のみ (v1 または v2)	ユーザーアカウント	ユーザーアカウント `/etc/hosts.equiv`、 `/etc/shosts.equiv`、`$HOME/.rhosts`、または `$HOME/.shosts` にローカルホスト名	弱

Solaris Secure Shell の使用 (作業マップ)

作業	説明	参照先
公開鍵と非公開鍵のペアを作成する	公開鍵と非公開鍵のペアを使用することは、ユーザー自身を証明し、通信を暗号化するのに望ましい方法である	公開鍵と非公開鍵のペアを作成する方法
Solaris Secure Shell を使用してログインする	暗号化された Secure Shell 通信を有効にするには、`rsh` を使用する場合と同様の方法で、リモートログインする	Solaris Secure Shell を使用して別のホストにログインする方法
パスワードを使用せずに Solaris Secure Shell を使用してログインする	`ssh-agent` を使用してパスワードを入力しなくても、Secure Shell を使用してログインできる。`ssh-agent` コマンドは、手動でまたは起動時スクリプトから実行できる	パスワードを使用せずに `ssh-agent` コマンドを使用してログインする方法
パスワードを使用せずに Solaris Secure Shell を使用してログインする		`ssh-agent` コマンドが自動的に動作するように設定する方法
Solaris Secure Shell にポート転送する	TCP 経由の Secure Shell 接続で使用するローカルポートまたはリモートポートを指定できる	Solaris Secure Shell のポート転送を使用する方法
Solaris Secure Shell を使用してファイルをコピーする	リモートファイルを安全にコピーできる	Solaris Secure Shell を使用してファイルをコピーする方法
Solaris Secure Shell を使用してファイルを転送する	`ftp` と同様に、Secure Shell が稼動するリモートホストに転送用コマンドを使用してログインできる	`sftp` コマンドを使用したファイルのリモート転送
ファイアウォールの内部のホストから外部のホストに接続する	Secure Shell には、HTTP または SOCKS5 と互換性のあるコマンドが組み込まれている。これらのコマンドは構成ファイル内やコマンド行で指定できる	ファイアウォール外部のホストにデフォルト接続を設定する方法例 — コマンド行からファイアウォール外部のホストに接続する

Solaris Secure Shell の使用

公開鍵と非公開鍵のペアを作成する方法

Solaris Secure Shell の公開鍵と非公開鍵のペアを作成するときの、標準的な手順について説明します。追加のオプションについては、ssh-keygen(1) のマニュアルページを参照してください。

鍵の生成プログラムを起動します。

myLocalHost% ssh-keygen
Generating public/private rsa key pair.
...

鍵が格納されるファイルのパスを入力します。

デフォルトでは、RSA v2 の鍵を表すファイル名 id_rsa がカッコ内に表示されます。このファイルを選択するときは、Return キーを押します。また、別のファイル名を入力することもできます。
Enter file in which to save the key(/home/johndoe/.ssh/id_rsa): <Return キーを押す>
公開鍵の名前が自動的に作成されます。公開鍵名の末尾に文字列 .pub が追加されます。

鍵に使用するパスフレーズを入力します。

このパスフレーズは、非公開鍵を暗号化するときに使用されます。パスフレーズは、10 〜 30 文字の英数字を混在させて指定してください。単純な英語の文や英語の名前の使用は避けてください。空文字入力は、パスフレーズを使用しないことを意味します。空文字入力は、ユーザーアカウントには極力避けてください。入力したパスフレーズは表示されません。
Enter passphrase(empty for no passphrase): <パスフレーズを入力>

確認のためにパスフレーズを再入力します。

Enter same passphrase again: <パスフレーズを入力>
Your identification has been saved in /home/jdohnoe/.ssh/id_rsa.
Your public key has been saved in /home/johndoe/.ssh/id_rsa.pub.
The key fingerprint is:
0e:fb:3d:57:71:73:bf:58:b8:eb:f3:a3:aa:df:e0:d1 johndoe@myLocalHost

結果を確認します。

鍵のフィンガープリント (コロンで区切られた 2 桁の 16 進数値列) が表示されます。鍵へのパスが正しいことを確認します。この例では、パスは /home/johndoe/.ssh/id_rsa.pub です。この時点で公開鍵と非公開鍵のペアが作成されました。

通信先のホスト上で authorized_keys ファイルを設定します。
1. id_rsa.pub ファイルを通信先ホストにコピーします。次のコマンドを入力します (ただし、バックスラッシュなしで 1 行に入力)。
  myLocalHost% cat $HOME/.ssh/id_rsa.pub | ssh myRemoteHost \ 'cat>> .ssh/authorized_keys && echo "Key uploaded successfully."'
2. プロンプトが表示されたら、ログインパスワードを入力します。
  
  ファイルのコピーが完了すると、“Key uploaded successfully.” というメッセージが表示されます。

Solaris Secure Shell を使用して別のホストにログインする方法

ssh コマンドを使用して、リモートホストの名前を指定します。
myLocalHost% ssh myRemoteHost
ssh コマンドを初めて実行した場合、次のように、リモートホストの認証を求めるプロンプトが表示されます。
The authenticity of host 'myRemoteHost' can't be established. RSA key fingerprint in md5 is: 04:9f:bd:fc:3d:3e:d2:e7:49:fd:6e:18:4f:9c:26 Are you sure you want to continue connecting(yes/no)?
このプロンプトは正常です。yes を入力して処理を続行します。このリモートホストで ssh を使用したことがあるのにこのプロンプトが表示される場合は、正常ではありません。セキュリティ違反が発生していないか確認する必要があります。

Solaris Secure Shell のパスフレーズとアカウントのパスワードを要求するプロンプトが表示されたら、これらを入力します。

Enter passphrase for key '/home/johndoe/.ssh/id_rsa': <Return キーを押す> 
johndoe@myRemoteHost's password: <Return キーを押す>
Last login: Fri Jul 20 14:24:10 2001 from myLocalHost
myRemoteHost%

リモートホストでトランザクションを実行します。ユーザーが送信するコマンドはすべて暗号化されます。ユーザーが受信する応答はすべて暗号化されます。

注 –

パスフレーズを後で変更する場合は、 ssh-keygen コマンドに -p オプションを指定して使用します。

リモートセッションが完了したら、exit を入力するか、通常の方法でシェルを終了します。
myRemoteHost% exit myRemoteHost% logout Connection to myRemoteHost closed myLocalHost%

パスワードを使用せずに `ssh-agent` コマンドを使用してログインする方法

Solaris Secure Shell を使用するときに、パスフレーズとパスワードを省略する場合は、エージェントデーモンを使用します。セッションを開始するときに、ssh-agent コマンドを使用してください。次に、エージェントを使用して非公開鍵を格納するために、ssh-add コマンドを使用します。ホストごとにアカウントが異なる場合は、セッションで使用する非公開鍵を追加します。

エージェントの起動は、次の手順で説明するように、必要に応じて手動で行うことができます。各セッションを開始するときに、エージェントが自動的に動作するように設定することもできます (ssh-agent コマンドが自動的に動作するように設定する方法を参照)。

エージェントデーモンを起動します。

ssh-agent コマンドがエージェントデーモンを起動し、そのプロセス ID が表示されます。
myLocalHost% eval `ssh-agent` Agent pid 9892 myLocalHost%

使用する非公開鍵をエージェントデーモンに追加します。

ssh-add コマンドがエージェントデーモンに非公開鍵を追加します。このため、後続の Secure Shell の操作では、パスフレーズを要求するプロンプトは表示されません。
myLocalHost% ssh-add Enter passphrase for /home/johndoe/.ssh/id_rsa: Identity added: /home/johndoe/.ssh/id_rsa(/home/johndoe/.ssh/id_rsa) myLocalHost%

Solaris Secure Shell セッションを起動します。
myLocalHost% ssh myRemoteHost

例 — `ssh-add` オプションを使用する

ssh-add を使用して、別の鍵をデーモンに追加することもできます。たとえば、DSA v2、RSA v2、および RSA v1 の鍵を同時に使用したい場合があります。デーモンに格納されているすべての鍵を表示するには、-l オプションを使用します。デーモンから 1 つの鍵を削除するには、-d オプションを使用します。すべての鍵を削除するには、-D オプションを使用します。

myLocalHost% eval `ssh-agent`
Agent pid 3347
myLocalHost% ssh-add
Enter passphrase for /home/johndoe/.ssh/id_rsa:
Identity added: /home/johndoe/.ssh/id_rsa(/home/johndoe/.ssh/id_rsa)
myLocalHost% ssh-add /home/johndoe/.ssh/id_dsa
Enter passphrase for /home/johndoe/.ssh/id_dsa: <パスフレーズを入力>
Identity added:
/home/johndoe/.ssh/id_dsa(/home/johndoe/.ssh/id_dsa)
myLocalHost% ssh-add -l
md5 1024 0e:fb:3d:53:71:77:bf:57:b8:eb:f7:a7:aa:df:e0:d1
/home/johndoe/.ssh/id_rsa(RSA)
md5 1024 c1:d3:21:5e:40:60:c5:73:d8:87:09:3a:fa:5f:32:53
/home/johndoe/.ssh/id_dsa(DSA)
myLocalHost% ssh-add -d
Identity removed:
/home/johndoe/.ssh/id_rsa(/home/johndoe/.ssh/id_rsa.pub)
/home/johndoe/.ssh/id_dsa(DSA)

`ssh-agent` コマンドが自動的に動作するように設定する方法

Secure Shell を使用するときにパスフレーズとパスワードを入力しないようにするには、エージェントデーモン ssh-agent を起動します。このエージェントデーモンは、.dtprofile スクリプトから起動できます。

エージェントデーモンを自動的に起動するには、$HOME/.dtprofile スクリプトの最後に次の行を追加します。
if [ "$SSH_AUTH_SOCK" = "" -a -x /usr/bin/ssh-agent ]; then eval `/usr/bin/ssh-agent` fi

CDE セッションを終了するときに Secure Shell エージェントデーモンを終了するには、$HOME/.dt/sessions/sessionexit スクリプトに次の行を追加します。
if [ "$SSH_AGENT_PID" != "" -a -x /usr/bin/ssh-agent ]; then /usr/bin/ssh-agent -k fi
このエントリにより、CDE セッションが終了したあとで、Secure Shell エージェントは使用できなくなります。

Solaris Secure Shell セッションを起動します。
myLocalHost% ssh myRemoteHost
パスフレーズのプロンプトは表示されません。

Solaris Secure Shell のポート転送を使用する方法

リモートホストに転送されるローカルポートを指定することができます。指定すると、ソケットはローカル側で、そのポートを待機します。このポートからリモートホストへの接続は、セキュリティ保護されたチャネルを介して行われます。たとえば、IMAP4 で電子メールを安全にリモート受信するためにポート 143 を指定します。また、リモート側のポートを指定することもできます。

注 –

Secure Shell ポート転送では TCP 接続を使用する必要があります。Secure Shell は UDP 接続をサポートしていません。

ローカルポートを転送元として設定するには、2 つのポートを指定します。待機するローカルポートを指定し、転送先のリモートホストとポートを指定します。

myLocalHost% ssh -L localPort:remoteHost:remotePort

リモートポートをセキュリティ保護された接続の受信元として設定するには、2 つのポートを指定します。待機するリモートポートを指定し、転送先のローカルホストとポートを指定します。

myLocalHost% ssh -R remotePort:localHost:localPort

例 — ローカルポート転送を使用してメールを受信する

次の例は、ローカルポート転送を使用して、リモートサーバーからのメールを安全に受信する方法を示しています。

myLocalHost% ssh -L 9143:myRemoteHost:143 myRemoteHost

このコマンドは、myLocalHost のポート 9143 を myRemoteHost のポート 143 (IMAP v2 のサーバーポート) に接続を転送します。ユーザーがメールアプリケーションを起動するときは、ローカルポート番号を指定する必要があります。dtmail コマンドの使用例を図 11–1 に示します。

この例と例 — リモートポート転送を使用してファイアウォールの外部と通信するで使用されている localhost は、ユーザーのローカルホストを指定するキーワードです。localhost キーワードと myLocalHost を混同しないでください。myLocalHost 変数は、この章の例で使用するローカルホストを表す仮のホスト名です。

図 11–1 電子メールに使用するポート転送を指定する

「Mailer - Login」ダイアログボックス。「IMAP Server」フィールドには、サーバー名、「:」、続けてポート番号が入力されています。

例 — リモートポート転送を使用してファイアウォールの外部と通信する

この例では、エンタープライズ環境のユーザーが、外部ネットワーク上のホストから企業のファイアウォール内部のホストに接続を転送する方法を示しています。

myLocalHost% ssh -R 9022:myLocalHost:22 myOutsideHost

このコマンドは、myOutsideHost 上のポート 9022 への接続をローカルホストのポート 22 (sshd サーバー) に転送します。

myOutsideHost% ssh -p 9022 localhost
myLocalHost%

このコマンドを使用すると、リモート転送接続が確立されたあとで、ssh コマンドを使用してリモートホストから安全に接続できます。

Solaris Secure Shell を使用してファイルをコピーする方法

scp コマンドを使用して、暗号化されたファイルをホスト間でコピーします。暗号化されたファイルは、ローカルホストとリモートホストとの間、または 2 つのリモートホスト間でコピーできます。scp コマンドは、rcp コマンドと同様に動作しますが、パスワードを要求するプロンプトを表示する点で異なります。詳細は、scp(1) のマニュアルページを参照してください。

セキュリティ保護されたコピープログラムを起動します。

ソースファイル、リモートコピー先のユーザー名、およびコピー先ディレクトリを指定します。
myLocalHost% scp myfile.1 johndoe@myRemoteHost:~

Solaris Secure Shell パスフレーズを要求するプロンプト表示で、パスフレーズを入力します。
Enter passphrase for key '/home/johndoe/.ssh/id_rsa': <Return キーを押す> myfile.1 25% |******* | 640 KB 0:20 ETA myfile.1
パスフレーズを入力すると、進行状況インジケータが表示されます。上記の出力の 2 行目が進行状況インジケータです。進行状況インジケータには、次の項目が表示されます。
- ファイル名
- その時点で転送が完了しているファイルの割合 (%)
- 転送が完了した割合 (%) に対応したアスタリスク (*)
- 転送が完了したデータの量
- ファイル全体が転送されるまでの推定時間 (ETA)。推定残り時間

`sftp` コマンドを使用したファイルのリモート転送

sftp コマンドの動作は、ftp と類似していますが、使用するサブコマンドセットが異なります。次の表に、代表的なサブコマンドを示します。

表 11–3 対話型 sftp のサブコマンド


カテゴリ	サブコマンド	説明
移動	`cd` `path`	リモートディレクトリを `path` に変更する
移動	`lcd` `path`	ローカルディレクトリを `path` に変更する
所有権	`chgrp` `group` `file`	`file` のグループを `group` (数値 GID) に変更する
所有権	`chmod` `mode` `file`	`file` のアクセス権を変更する
ファイルのコピー	`get` `remote_file` [`local-path` ]	リモートファイルを取得し、それをローカルホストに格納する
	`put` `local_file` [`remote_path` ]	ローカルファイルをリモートホストに格納する
	`rename` `old_filenew_file`	ローカルファイルの名前を変更する
ディレクトリのリスト表示	`ls` [`path`]	リモートディレクトリの内容を一覧表示する
ディレクトリの作成	`mkdir` `path`	リモートディレクトリを作成する
その他	`exit`、`quit`	`sftp` コマンドを終了する

ファイアウォール外部のホストにデフォルト接続を設定する方法

Solaris Secure Shell を使用して、ファイアウォール内部のホストからファイアウォール外部のホストに接続することができます。接続するには、構成ファイル内またはコマンド行オプションに ssh のプロキシコマンドを指定します。詳細は、例 — コマンド行からファイアウォール外部のホストに接続するを参照してください。

通常は、個人用構成ファイル $HOME/.ssh/config または管理構成ファイル/etc/ssh/ssh_config を使用して、ssh の対話操作をカスタマイズできます(ssh_config(4) のマニュアルページを参照)。プロキシコマンドには2 種類あり、一方が HTTP 接続用、もう一方が SOCKS5 接続用です。

構成ファイルにプロキシコマンドとホストを指定します。

次の構文を使用して、必要なプロキシコマンドとホストの数に応じて行を追加します。
[Host outside_host] ProxyCommand proxy_command [-h proxy_server] \ [-p proxy_port] outside_host|%h outside_port|%p
次に、各引数について説明します。
Host outside_host

コマンド行でリモートホスト名を指定した場合、プロキシコマンド指定をインスタンスに限定する。outside_host でワイルドカードを使用した場合、一連のホストに対して指定が適用される

proxy_command
プロキシコマンドを指定する。次のいずれかを指定できる。
- HTTP 接続の場合は、/usr/lib/ssh/ssh-http-proxy-connect
- SOCKS5 接続の場合は、/usr/lib/ssh/ssh-socks5-proxy-connect
-h proxy_server と-p proxy_port

これらのオプションは、プロキシサーバーとプロキシポートをそれぞれ指定する。これらのオプションは、HTTPPROXY、HTTPPROXYPORT、SOCKS5_PORT、SOCKS5_SERVER、http_proxy などの、プロキシサーバーとプロキシポートを指定するどのような環境変数よりも優先される。http_proxy 変数は URL を指定する。これらのオプションを指定しない場合、適切な環境変数を設定する必要がある。ssh-socks5-proxy-connect(1) と ssh-http-proxy-connect(1) のマニュアルページを参照

outside_host

接続先のホストを指定する。%h を使うとコマンド行からホストを指定できる。

outside_port

接続先のポートを指定する。%p を使うとコマンド行からポートを指定できる。Host outside_host オプションを使わずに %h と %p を指定した場合、ssh コマンドが呼び出されるたびに、引数に指定されたホストにプロキシコマンドが適用されます。

外部のホストを指定して、Solaris Secure Shell を実行します。

たとえば、次のように入力します。
myLocalHost% ssh myOutsideHost
このコマンドは、個人用構成ファイル内で myOutsideHost のプロキシコマンド指定を検索します。指定が検出されない場合、このコマンドは、システム全体の構成ファイル ssh_config から検索します。プロキシコマンドが ssh に置き換わります。

例 — コマンド行からファイアウォール外部のホストに接続する

ssh コマンドの -o オプションには、ssh 構成ファイル内で使用できる任意の行を入力できます。ここでは、前述の例のプロキシコマンド指定を使用します。

構成ファイルにプロキシコマンドとホストを指定します。
ssh コマンドを実行します。-o オプションにプロキシコマンドを指定してください。たとえば、次のように入力します。
% ssh -o'Proxycommand=/usr/lib/ssh/ssh-http-proxy-connect \ -h myProxyServer -p 8080 myOutsideHost 22' myOutsideHost
このコマンドは、ssh を HTTP プロキシコマンドに置き換え、ポート 8080 と myProxyServer をプロキシサーバーとして使用し、 myOutsideHost のポート 22 に接続します。

第 12 章 Solaris Secure Shell の管理 (参照)

この章では、システム管理者から見た Solaris Secure Shell の機能とその構成方法について説明します。この章の内容は次のとおりです。

標準的な Solaris Secure Shell セッション

Solaris Secure Shell デーモン (sshd) は通常、/etc/init.d/sshd スクリプトによりブート時に起動されます。デーモンは、クライアントからの接続を待機します。Solaris Secure Shell セッションは、ssh、scp、または sftp コマンドが実行されると開始します。接続を受信するたびに、新しい sshd デーモンがフォークされます。フォークされたデーモンは、鍵の交換、暗号化、認証、コマンドの実行、およびクライアントとのデータ交換を行います。Secure Shell セッションの特性は、クライアント構成ファイルとサーバー構成ファイルによって決定されます。また、コマンド行パラメータを使用することもできます。クライアントとサーバーは、相互に認証する必要があります。認証に成功したあと、ユーザーはコマンドをリモートで実行でき、ホスト間でデータをコピーできます。

セッションの特性

サーバー側の sshd デーモンの動作は、/etc/ssh/sshd_config ファイルのキーワードを設定することで変更できます。sshd が起動しているときに、コマンド行オプションを使用することもできます。たとえば、sshd_config により、サーバーにアクセスするときに使用する認証タイプを変更できます。

クライアント側の動作は、Solaris Secure Shell のパラメータで変更できます。パラメータの優先順位は次のとおりです。

コマンド行オプション
ユーザーの構成ファイル ($HOME/.ssh/config)
システム全体の構成ファイル (/etc/ssh/ssh_config )

たとえば、Cipher として blowfish に設定されているシステム全体の構成を変更するには、コマンド行に -c 3des を指定します。

認証

Solaris Secure Shell の認証は、次の手順で行われます。

ユーザーが、ssh、scp、または sftp コマンドを実行します。
クライアントとサーバーは、共有セッション鍵に合意します。

v1 のリモートホストは、ホスト (RSA) 鍵とサーバー (RSA) 鍵をクライアントに送信します。サーバー鍵は通常、1 時間ごとに生成され、メモリーだけに格納されます。クライアントは、リモートホスト鍵がローカルホストの $HOME/.ssh/known_hosts ファイルに格納されていることを確認します。次にクライアントは、256 ビットの乱数を生成して、リモートホストのホスト鍵とサーバー鍵を暗号化します。暗号化された乱数は、セッション内での後続のすべての通信を暗号化するときに、セッション鍵として使用されます。

v2 のリモートホストは、ホスト鍵の DSA を使用し、サーバー鍵を生成しません。代わりに共有セッション鍵を、Diffie-Hellman 方式で合意したときに生成します。
ローカルホストとリモートホストは、相互に認証します。

v1 のクライアントでは、.rhosts、rhosts とRSA、RAS challenge-response、またはパスワードベースの認証を使用できます。v2 では、.rhosts、DSA、およびパスワードベースの認証だけを使用できます。

コマンドの実行とデータの転送

認証が完了したら、ユーザーは通常、シェルまたはコマンド実行を要求して Solaris Secure Shell を使用します。ssh のオプションを使用すれば、擬似端末を配置したり、X11 あるいは TCP/IP の接続を転送したり、セキュリティ保護された接続上で ssh-agent を有効にしたりすることができます。ユーザーセッションの基本手順は次のとおりです。

ユーザーがシェルまたはコマンドの実行を要求し、セッションモードを開始します。

セッションモードでは、データは端末を通してクライアント側に送受信され、シェルまたはコマンドを介してサーバー側に送受信されます。
ユーザープログラムを終了します。
すべての X11 および TCP/IP 接続の転送を停止します。ただし、既存の X11 と TCP/IP 接続は、すべて開いたままです。
サーバーはコマンド終了をクライアントに送信し、両サイドの接続が終了します。

Solaris Secure Shell を構成する

Solaris Secure Shell セッションの特性は、構成ファイルで変更できます。コマンド行のオプションを使用することで、このデフォルト設定を変更できます。

Solaris Secure Shell クライアントの構成

ほとんどの場合、Solaris Secure Shell セッションのクライアント側の特性は、システムの構成ファイル (/etc/ssh/ssh_config) によって決定されます。このファイルは、システム管理者が設定します。$HOME/.ssh/config 内のユーザーの構成は、システムの構成ファイル内の設定より優先されます。さらに、コマンド行での指定は、これらの構成ファイルより優先されます。

コマンド行オプションはクライアント側の要求ですが、サーバー側の /etc/ssh/sshd_config ファイルによって許可または拒否されます (ssh_config(4) のマニュアルページを参照)。構成ファイルのキーワードとコマンドオプションについては、次の節で説明します。詳細は、ssh(1)、scp(1)、sftp(1)、および ssh_config(4) のマニュアルページを参照してください。2 つのユーザー構成ファイルの中で Host キーワードには、ホストまたはワイルドカード表現を指定します。このキーワードは、次の Host キーワードが出現するまで、後続のすべてのキーワードに適用されます。

ホスト固有のパラメータ

ローカルホストごとに異なる Solaris Secure Shell 特性を使用する場合、システム管理者は /etc/ssh/ssh_config ファイルにホストまたはその正規表現形式とともにいくつかのパラメータセットを定義します。ファイル内のエントリを、 Host キーワードでグループ化してください。Host キーワードを使用しない場合、クライアント構成ファイル内のエントリは、ユーザーが使用しているローカルホストに適用されます。

クライアント側の認証パラメータ

認証方式を決定するには、次のキーワードのいずれかに「yes」を設定します。

DSAAuthentication
PasswordAuthentication
RhostsAuthentication
RhostsRSAAuthentication

キーワード UseRsh は、rlogin と rsh コマンドを使用することを指定します。このキーワードは、多くの場合、Secure Shell がサポートされないときに使用します。

キーワード Protocol には、Solaris Secure Shell プロトコルのバージョン (v1 または v2) を設定します。両方のバージョンを指定する場合は、コンマで区切ります。最初のバージョンの使用に失敗した場合は、2 番目のバージョンが使用されます。

キーワード IdentityFile には、ユーザーの非公開鍵を格納する代替ファイル名を指定します。

キーワード Cipher には、v1 の暗号化アルゴリズム (blowfish または 3des) を指定します。キーワード Ciphers には、v2 の暗号化アルゴリズム (3des-cbc、blowfish-cbc、および aes128–cbc) の優先順序を指定します。ssh および scp コマンドの -c オプションは、コマンド行で暗号化アルゴリズムを指定するときに使用します。

既知のホストファイルパラメータ

既知のホストファイル (/etc/ssh/ssh_known_hosts および $HOME/.ssh/known_hosts) には、すべてのホストの公開鍵が含まれています。この公開鍵は、クライアントが Solaris Secure Shell を使用してホストと通信するときに使用されます。GlobalKnownHostsFile キーワードには、/etc/ssh/ssh_known_hosts の代替ファイルを指定します。UserKnownHostsFile キーワードには、$HOME/.ssh/known_hosts の代替ファイルを指定します。

StrictHostKeyChecking キーワードを指定した場合は、新しいホストを既知のホストファイルに追加するときは手動で行う必要があります。また、公開鍵が変更されたり、公開鍵が既知のホストファイルに存在しないホストは拒否されます。キーワード CheckHostIP を指定すると、DNS のスプーフィングによって鍵が変更された場合に、既知のホストファイルに指定されているホストの IP アドレスが確認されます。

クライアント側の X11 転送とポート転送パラメータ

LocalForward キーワードには、リモートホスト上の特定のポートに転送するローカル TCP/IP ポートを指定します。セキュリティ保護されたチャネルが使用されます。GatewayPorts キーワードを指定すると、ローカル転送されたポートにリモートホストが接続することを可能にします。

ssh コマンドでポート転送するときは、次のオプションを使用できます。

-L - リモートホスト上の特定のポートに転送するローカルポートを指定する
-R - ローカルホストおよび特定のポートに転送するリモートポートを指定する

ForwardX11 キーワードを指定すると、 DISPLAY 環境変数が設定されたリモートホストに X11 接続がリダイレクトされます。XAuthLocation キーワードには、xauth プログラムの場所を指定します。

クライアント側の接続とその他のパラメータ

NumberOfPasswordPrompts キーワードには、パスワードを要求する回数を指定します。指定した回数が終了すると、Solaris Secure Shell が終了します。ConnectionAttempts キーワードには、接続試行回数 (1 秒間に 1 回試行) を指定します。この回数が終了すると、Solaris Secure Shell が終了します。ただし、FallBackToRsh キーワードが設定されている場合は、rsh に戻ります。

Compression キーワードを指定すると、転送データが圧縮されます。CompressionLevel キーワードには、圧縮レベル (1 - 9) を設定します。圧縮率とそれを行う時間にはトレードオフの関係があります。

User には、代替ユーザー名を指定します。Hostname には、リモートホストの代替名を指定します。ProxyCommand には、Solaris Secure Shell を起動する代替コマンド名を指定します。プロキシサーバーに接続できるコマンドはすべてここに指定できます。指定するコマンドは、標準入力から読み込んで標準出力に書き込む必要があります。

Batchmode を指定すると、パスワードプロンプトが無効になります。パスワードプロンプトは、スクリプトなどのバッチジョブに使用します。

KeepAlive を指定すると、ホストがクラッシュしたときに、ネットワークの問題が発生したことを示すメッセージが出力されます。LogLevel には、ssh メッセージの冗長レベルを設定します。

EscapeChar には、特殊文字をプレーンテキストとして表示するときに、接頭辞として使用する単一文字を定義します。

Solaris Secure Shell サーバーの構成

サーバー側の Solaris Secure Shell セッションの特性は、/etc/ssh/sshd_config ファイルによって管理されます。このファイルは、システム管理者が設定します。

サーバー側の認証パラメータ

使用できる認証方式のキーワードは、以下のとおりです。

DSAAuthentication
PasswordAuthentication
RhostsAuthentication
RhostsRSAAuthentication
RSAAuthentication

HostKey および HostDSAKey には、デフォルトのファイル名を使用しないときに、ホスト公開鍵を格納するファイルを指定します。KeyRegenerationInterval には、サーバー鍵を再生成する頻度を指定します。

Protocol には、バージョンを指定します。Ciphers には、v2 の暗号化アルゴリズムを定義します。ServerKeyBits には、サーバーの鍵のビット数を定義します。

ポートと転送パラメータ

AllowTCPForwarding には、TCP 転送を許可するかどうかを指定します。

GatewayPorts を指定すると、クライアントに転送されたポートにリモートホストが接続されます。Port には、sshd が待機するポート番号を指定します。ListenAddress には、sshd が待機するローカルアドレスを指定します。ListenAddress を指定しない場合、 sshd はデフォルトですべてのアドレスで待機します。

X11Forwarding を指定すると、X11 転送が有効になります。X11DisplayOffset には、転送に使用できる最初の表示番号を指定します。このキーワードを指定すると、sshd が実際の X11 サーバーに干渉しなくなります。XAuthLocation には、xauth プログラムの場所を指定します。

セッション制御パラメータ

KeepAlive を指定すると、接続が切断したときおよびホストがクラッシュしたときに、メッセージが表示されます。LogLevel には、sshd メッセージの冗長レベルを設定します。SyslogFacility には、ログに記録する sshd メッセージの機能コードを指定します。

サーバー接続とその他のパラメータ

AllowGroups、AllowUsers、DenyGroups、および DenyUsers キーワードを使用して、ssh を使用できるユーザーと使用できないユーザーを制御します。

LoginGraceTime、MaxStartups、PermitRootLogin、および PermitEmptyPasswords キーワードを使用して、ログインするユーザーを制御します。StrictModes を指定すると、sshd は、ユーザーがログインする前にファイルのモードと所有権およびホームディレクトリを確認します。UseLogin には、対話型ログインセッションで login を使用するかどうかを指定します。このキーワードは有効にする必要はありません。Solaris 環境ではできるだけ使用しないでください。

Subsystem を指定すると、sftp に使用するファイル転送デーモンが構成されます。

サイト全体で既知のホストを管理する

ホスト間の対話を安全に行うには、ローカルホストの /etc/ssh/ssh_known_hosts ファイルにサーバーの公開鍵を格納する必要があります。 /etc/ssh/ssh_known_hosts ファイルを更新するときに、スクリプトを使用すると簡単に行うことができますが、セキュリティが大幅に低下するため、できるだけ使用しないでください。

/etc/ssh/ssh_known_hosts ファイルを配布するときは、次のようなセキュリテイ保護されたメカニズムで行う必要があります。

Solaris Secure Shell、IPsec、または Kerberos を使用した ftp などのセキュリティ保護された接続を使用して、既知の信頼できるマシンから配布する
システムインストール時に配布する

known_hosts ファイルに偽の公開鍵を挿入してアクセス権を取得しようとする侵入者をできる限り阻止するには、 ssh_known_hosts ファイルの既知の信頼できるソースとして、JumpStart サーバーを使用します。ssh_known_hosts ファイルは、インストール中に配布できるほか、各ホストで定期的にスクリプト (scp を使用して最新バージョンを取り込む) を実行して配布することもできます。この方法は、JumpStart サーバーの公開鍵がすでに各ホストに保管されているため安全です。

Solaris Secure Shell ファイル

次の表は、重要な Solaris Secure Shell ファイルと推奨される UNIX アクセス権を示します。

表 12–1 Solaris Secure Shell ファイル


ファイル名	説明	推奨アクセス権と所有者
`/etc/ssh/sshd_config`	`sshd` (Secure Shell デーモン) の構成データを含む	`-rw-r--r-- root`
`/etc/ssh/ssh_host_key`	ホスト非公開鍵を含む	`-rw------- root`
`/etc/ssh_host_key.pub`	ホスト公開鍵を含む。ホスト鍵をローカル `known_hosts` ファイルにコピーするときに使用する	`-rw-r--r-- root`
`/var/run/sshd.pid`	Secure Shell デーモン `sshd` のプロセス ID を含む。このデーモンは接続を待機する (複数のデーモンが存在する場合は、起動された最後のデーモンを含む)	`rw-r--r-- root`
`$HOME/.ssh/authorized_keys`	v1 の場合は、ユーザーアカウントにログインするときに使用できる RSA 鍵を指定する。v2 の場合は、使用できる DSA と RSA 鍵を指定する	`-rw-rw-r-- johndoe`
`/etc/ssh/ssh_known_hosts`	すべてのホストのホスト公開鍵を含む。クライアントはこれらの公開鍵を使用して、セキュリティ保護された通信を行う。このファイルはシステム管理者が用意する	`-rw-r--r-- root`
`$HOME/.ssh/known_hosts`	すべてのホストのホスト公開鍵を含む。クライアントはこれらの公開鍵を使用して、セキュリティ保護された通信を行う。このファイルは自動的に管理される。ユーザーが未知のホストに接続すると、リモートホスト鍵がファイルに追加される	`-rw-r--r-- johndoe`
`/etc/nologin`	このファイルが存在する場合、`sshd` は `root` ログイン以外のユーザーを拒否する。ファイルの内容は、ログインしようとするユーザーに表示される	`-rw-r--r-- root`
`$HOME/.rhosts`	ホスト名とユーザー名のペアを含む。ユーザーは、対応するホストにパスワードを使用しないでログインできる。このファイルは、Secure Shell、`rlogind`、および `rshd` デーモンで使用される	`-rw-r—r-- johndoe`
`$HOME/.shosts`	ホスト名とユーザー名のペアを含む。ユーザーは、対応するホストにパスワードを使用せずに Secure Shell だけを使用してログインできる	`-rw-r—r-- johndoe`
`/etc/hosts.equiv`	`.rhosts` 認証と Secure Shell 認証で使用されるホストを含む	`-rw-r--r-- root`
`/etc/ssh/shosts.equiv`	Secure Shell 認証で使用されるホストを含む	`-rw-r--r-- root`
`$HOME/.ssh/environment`	ログイン時に割り当てを行う初期化に使用する	`-rw------- johndoe`
`$HOME/.ssh/rc`	ユーザーのシェルを起動前に実行する初期化ルーチン	`-rw------- johndoe`
`/etc/ssh/sshrc`	システム管理者がすべてのユーザー用に用意したホスト固有の初期化ルーチン	`-rw-r--r-- root`

次の表は、主要な Solaris Secure Shell コマンドの要約です。

表 12–2 Solaris Secure Shell コマンド


コマンド名	説明
`ssh`	リモートマシンにログインし、リモートマシン上でコマンドを実行するプログラム。このコマンドは、 `rlogin` と `rsh` に代わるコマンドである。セキュリティ保護されていないネットワークを介して信頼できないホスト間でセキュリティ保護された暗号化通信を行うときに使用する。X11 接続と任意の TCP/IP ポートも、セキュリティ保護されたチャネルを介して転送される
`sshd`	Secure Shell が待機するデーモン。このデーモンは、クライアントからの接続を待機する。セキュリティ保護されていないネットワークを介して 2 つの信頼できないホスト間でセキュリティ保護された暗号化通信を行うときに使用する。
`ssh-keygen`	`ssh` の認証鍵を生成および管理する
`ssh-agent`	公開鍵認証時に使用される非公開鍵を格納するプログラム。`ssh-agent` は、X セッションまたはログインセッションの開始時に起動する。ほかのすべてのウィンドウまたはプログラムは、`ssh-agent` プログラムのクライアントとして起動する。環境変数を使用すれば、ユーザーが `ssh` を使用してほかのマシンにログインするときに、エージェントを検出して認証に自動的に使用することができる
`ssh-add`	RSA または DSA ID (鍵) を認証エージェント `ssh-agent` に追加する
scp	`ssh` を使用してデータ転送するときに、ネットワーク上のホスト間でファイルを安全にコピーする。`rcp` と異なり、`scp` はパスワードまたはパスフレーズを要求する (認証に必要な場合)
sftp	対話型ファイル転送プログラム。`ftp` と同様に、暗号化された `ssh` トランスポートを介してすべての操作を実行する。`sftp` は、指定したホスト名に接続してログインし、対話型コマンドモードに入る

第 13 章 SEAM について

この章では、Sun Enterprise Authentication Mechanism (SEAM) について説明します。

SEAM とは

SEAM は、ネットワークを介してセキュリティ保護されたトランザクションを提供するクライアントおよびサーバーのアーキテクチャです。SEAM では、強力なユーザー認証とともに、データの完全性とデータのプライバシを提供します。認証により、ネットワークトランザクションの送信者と受信者の識別情報が正しいことが保証されます。さらに SEAM を使用して、送受信するデータの完全性が検査され (「完全性」)、伝送時にデータが暗号化されます (「プライバシ」) 。SEAM を使用して、他のマシンにログインしてコマンドを実行したり、データを交換したりファイルを安全に転送したりできます。SEAM は承認サービスも提供するため、システム管理者はサービスやマシンへのアクセスを制限できます。また、SEAM ユーザーは、自分のアカウントに他人がアクセスするのを制限できます。

SEAM は「シングルサインオン」システムです。つまり、SEAM からセッションについて一度だけ認証を受ければ、そのセッションでは、それ以後のすべてのトランザクションが自動的に認証されます。いったん SEAM から認証されたユーザーは、ftp、rsh などの SEAM ベースのコマンドを使用したり、NFS ファイルシステム上のデータにアクセスしたりするたびに認証が要求されることはありません。つまり、これらのサービスを使用するたびに、ネットワークを介してパスワードを送り、傍受される危険を冒す必要がありません。

SEAM は、マサチューセッツ工科大学 (MIT) で開発された Kerberos V5 ネットワーク認証プロトコルに基づいています。そのため、Kerberos V5 を使用したことがあるユーザーは、SEAM にはすぐ慣れるはずです。Kerberos V5 はネットワークセキュリティの事実上の業界標準であるため、SEAM はほかのシステムとの相互運用性に優れています。つまり、SEAM は Kerberos V5 を使用するシステムと協調して動作するため、異機種システム混在のネットワークであってもトランザクションのセキュリティが保護されます。さらに SEAM では、複数のドメイン間でも単一のドメイン内でも認証やセキュリティの機能を使用できます。

注 –

SEAM は、Kerberos V5 に準拠しており、Kerberos V5 との相互運用を実現するために設計されています。このマニュアルでは、「Kerberos」と「SEAM」という用語は、「Kerberos のレルム」や「SEAM ベースのユーティリティ」など、区別しないで使用されることがあります。また、「Kerberos」と「Kerberos V5」も区別しないで使用されています。必要に応じて「Kerberos」と「Kerberos V5」を区別しています。

SEAM には、Solaris アプリケーションを実行するための柔軟性が備わっています。SEAM は、NFS サービス、telnet、および ftp などのネットワークサービスを SEAM ベースと SEAM ベースでない両方式の要求に対応できるように構成できます。このため、SEAM がインストールされていないシステムで動作する現在の Solaris アプリケーションも正しく動作します。もちろん、SEAM ベースのネットワーク要求だけを許可するように SEAM を設定することもできます。

さらに、他のセキュリティメカニズムが開発された場合には、アプリケーションで使用するセキュリティメカニズムを SEAM に限定しておく必要はありません。SEAM は、Generic Security Service (GSS) API にモジュールとして統合できるように設計されているため、GSS-API を使用するアプリケーションは、必要に応じたセキュリティメカニズムを使用できます。

SEAM の動作

この節では SEAM 認証システムの概要について説明します。詳細は、認証システムの動作方法を参照してください。

ユーザーの観点からいえば、SEAM は、SEAM セッションが起動されたあとはほとんど意識しません。rsh や ftp などのコマンドは、通常の方式で適切に動作します。SEAM セッションの初期化には通常、ログインと Kerberos パスワードの入力しか必要ありません。

SEAM システムは、チケットの概念を中心に動作します。チケットは、ユーザー ID や NFS などのサービス ID となる一連の電子情報です。運転免許証が運転する人と免許の種類を表すのと同じように、チケットもユーザーとユーザーのネットワークアクセス権を表します。SEAM ベースのトランザクションを実行する (ほかのマシンへの rlogin など) と、鍵配布センター (KDC) に対してチケットの要求が透過的に送信されます。KDC はデータベースにアクセスしてそのユーザーを認証し、そのマシンへのアクセス権を許可するチケットを返します。「透過的」とは、明示的にチケットを要求する必要がないことを意味します。この要求は rlogin コマンドの中で行われます。特定のサービスのチケットを取得できるのは認証されたクライアントだけで、別のクライアントが識別情報を仮定して rlogin を使用することはできません。

チケットには一定の属性が与えられています。たとえば、チケットには「転送可能」(新しい認証処理を行わなくても別のマシンで使用できる) や「遅延」(指定の日付まで有効にならない) の属性があります。どのユーザーがどの種類のチケットを取得できるかなど、チケットをどのように使用するかは、SEAM のインストールや管理の際に決める「方針」によって設定されます。

注 –

「資格」と「チケット」という用語は、頻繁に使用されます。広い意味の Kerberos では、これらの用語は同じ意味で使われることがありますが、技術的には資格はチケットとそのセッションに対する「セッション鍵」からなります。この違いについては、SEAM によるサービスへのアクセスで詳しく説明します。

次の節では、SEAM 認証プロセスについて詳細に説明します。

初期認証: チケット認可チケット (TGT)

Kerberos 認証には、後続の認証を準備する初期認証と、後続の認証の 2 つのフェーズがあります。　

次の図では、初期認証の手順を示します。

図 13–1 SEAM セッションの初期認証

クライアントは、まず KDC に TGT を要求し、次に KDC から受け取った TGT を復号化します。

クライアント (ユーザー、または NFS などのサービス) は、KDC に TGT を要求して SEAM セッションを開始します。ほとんどの場合、この要求はログイン時に自動的に実行されます。

TGT は、ほかの特定のサービスのチケットを取得するために必要です。TGT は、パスポートに似ています。パスポートと同様に、TGT はユーザーを識別して、さまざまなビザの取得をユーザーに許可します。ここでいうビザ (チケット) は、外国に入国するためのものではなく、リモートマシンやネットワークサービスにアクセスするためのものです。パスポートやビザと同様に、TGT などのチケットには有効期限があります。ただし、Kerberos コマンドは、ユーザーがパスポートを所有していることを通知し、ユーザーに代わってビザを取得します。ユーザー自身がトランザクションを実行する必要はありません。

チケット認可チケットに類似した例として、4 つのスキー場で使える 3 日間のスキーパスを挙げます。ユーザーはこのパスを任意のスキー場で提示して (期限切れでない場合)、そのスキー場のチケットを受け取ります。リフトチケットを入手したら、そのスキー場で好きなだけスキーをすることができます。翌日別のスキー場に行った場合は、またパスを提示して、そのスキー場のリフトチケットを入手します。ただし、SEAM ベースのコマンドは、週末スキーパスを所有していることをユーザーに通知し、ユーザーに代わってリフトチケットを入手します。ユーザー自身がこのトランザクションを実行する必要はありません。
KDC は TGT を作成し、それを暗号化してクライアントに送信します。クライアントは、自身のパスワードを使用して TGT を復号化します。
クライアントは、有効な TGT を入手したので、TGT が期限切れになるまで、rlogin、telnet などあらゆる種類のネットワーク操作チケットを要求できます。この TGT の有効期限は通常、数時間です。クライアントは一意のネットワーク操作を実行するたびに、TGT は KDC にその操作のチケットを要求します。

後続の認証

クライアントが初期認証を受け取ると、各認証は次の図のように実行されます。

図 13–2 サービスへのアクセスを取得する

クライアントは、まず KDC にチケットを要求するため TGT を送り、次に受け取ったチケットを使用してサーバーにアクセスします。

クライアントは、特定のサービス (別のマシンに rlogin するなど) のチケットを KDC に要求するために、識別情報の証拠として自身の TGT を KDC に送信します。
KDC は、そのサービスのチケットをクライアントに送信します。

たとえば、ユーザー joe が、必要とする krb5 認証と共有関係にある NFS ファイルシステムにアクセスするとします。このユーザーはすでに認証されている (すでに TGT を持っている) ため、そのファイルにアクセスを試みると、NFS クライアントシステムは NFS サービスのチケットを KDC から自動的および透過的に取得します。

たとえば、ユーザー joe がサーバー boston 上で rlogin を使用するとします。このユーザーはすでに認証されている (つまり、すでにチケット認可チケットを持っている) ため、rlogin コマンドの一部として自動的かつ透過的にチケットを取得します。このチケットが期限切れになるまで、このユーザーは必要に応じて boston に rlogin できます。 joe がマシン denver に rlogin する場合は、手順 1 の方法で別のチケットを入手します。
クライアントはサーバーにチケットを送信します。

NFS サービスを使用している場合、NFS クライアントは自動的および透過的に NFS サービスのチケットを NFS サーバーに送信します。
サーバーはクライアントにアクセス権を許可します。

これらの手順では、サーバーと KDC 間の通信は発生していないように見えます。しかし、サーバーは KDC と通信していて、最初のクライアントと同様に、KDC に自身を登録しています。わかりやすくするために、その部分は省略しています。

SEAM リモートアプリケーション

ユーザーは、次の SEAM ベースの (Kerberos 化された) コマンドを使用できます。　

ftp
rcp
rlogin
rsh
telnet

これらのアプリケーションは、同じ名前の Solaris アプリケーションと同じです。ただし、トランザクションを認証するときに Kerberos 主体を使用し、Kerberos ベースのセキュリティを提供します。主体の詳細は、主体を参照してください。

主体

SEAM 内のクライアントはその「主体 (プリンシパル)」で識別されます。主体とは、KDC がチケットを割り当てることができる一意の識別情報です。主体には、joe などのユーザー、または nfs、telnet などのサービスがあります。

主体名は慣習により「一次」、「インスタンス」、「レルム」という 3 つの部分からなります。joe/admin@ENG.EXAMPLE.COM は一般的な SEAM 主体の例です。各文字列は次の意味を持ちます。

joe が一次です。一次には、この例のようなユーザー名や nfs などのサービスを指定します。また、host を指定することもできます。host を指定すると、ftp、rcp、rlogin などのさまざまなネットワークサービスを提供する、サービス主体として設定されます。
admin はインスタンスです。インスタンスは、ユーザー主体の場合はオプションですが、サービス主体では必須です。たとえば、ユーザー joe が必要に応じてシステム管理者の権限を使用する場合は、joe/admin と通常のユーザー ID を使い分けることができます。同じように、joe が 2 つのホストにアカウントを持っている場合、異なるインスタンスで 2 つの主体名を使用することができます (たとえば、joe/denver.example.com と joe/boston.example.com)。SEAM では、joe と joe/admin は全く別のプリンシパルとして扱われます。

サービス主体では、インスタンスは完全修飾されたホスト名です。bigmachine.eng.example.com はこのようなインスタンスの例です。したがって、一次とインスタンスは、たとえば、ftp/bigmachine.eng.example.com や host/bigmachine.eng.example.com と表します。
ENG.EXAMPLE.COM は SEAM レルムです。レルムについては、レルムを参照してください。

次に有効な主体名を示します。

joe
joe/admin
joe/admin@ENG.EXAMPLE.COM
ftp/host.eng.example.com@ENG.EXAMPLE.COM
host/eng.example.com@ENG.EXAMPLE.COM

レルム

レルムとはドメインのようなもので、同じ「マスター KDC」の下にあるシステムをグループとして定義する論理ネットワークです。図 13–3 では、レルム間の関係を示します。階層構造のレルムでは、1 つのレルムがほかのレルムの上位集合になります。階層ではない (直接接続の) レルムでは、2 つのレルム間の割り当てを定義する必要があります。SEAM では、レルム間で共通の認証が可能です。その場合、各レルムの KDC に、他のレルムの主体エントリだけが必要になります。この機能は、レルム間認証と呼ばれます。

図 13–3 レルム

「ENG.EXAMPLE.COM」レルムが、「SEAMCO.COM」とは階層関係がなく、「EXAMPLE.COM」とは階層関係があることを示しています。

レルムとサーバー

各レルムには、主体データベースのマスターコピーを保守するサーバーが含まれる必要があります。このサーバーを「マスター KDC サーバー」と呼びます。また各レルムには、主体データベースの重複コピーを保持する「スレーブ KDC サーバー」が少なくとも 1 つ必要です。マスター KDC サーバーおよびスレーブ KDC サーバーは、認証の確立に使用されるチケットを作成します。

レルムはさらに 2 種類の SEAM サーバーを持つことができます。SEAM ネットワークアプリケーションサーバーは、Kerberos 対応のアプリケーション (ftp、telnet、rsh など) へのアクセスを提供するサーバーです。レルムは、NFS サーバーも持つことができます。NFS サーバーは Kerberos 認証を使用する NFS サービスを提供します。SEAM 1.0 または SEAM 1.0.1 をインストールすると、レルムには、Kerberos アプリケーション (ftp、telnet、rsh など) からアクセスされる SEAM ネットワークのアプリケーションサーバーがインストールされます。

次の図では、レルムの構成例を示します。

図 13–4 一般的なレルム

一般的なレルム「EXAMPLE.COM」です。1 つのマスター KDC、3 つのクライアント、2 つのスレーブ KDC、および 2 つのアプリケーションサーバーからなっています。

SEAM セキュリティサービス

SEAM は、ユーザーの認証を行うほかに、次の 2 つのセキュリティサービスを提供します。

「完全性」 – 認証が、あるネットワーク上のクライアントが本人であるかどうかを確認するのと同様に、完全性は、クライアントの送信データが有効で、伝送の間に改ざんされていないことを確認します。完全性の確認は、データの暗号チェックサムによって行われます。完全性にはユーザー認証も含まれます。
「プライバシ」 – プライバシによって、セキュリティがさらに向上します。プライバシは、伝送データの完全性を検証するだけでなく、伝送前にデータを暗号化して盗聴を防ぎます。プライバシにも認証が含まれます。

SEAM に組み込まれている Kerberos アプリケーションの中で実行時にセキュリティサービスを変更できるのは、ftp コマンドだけです。開発者は、RPCSEC_GSS プログラミングインタフェースを使用することにより、セキュリティサービスを選択可能な RPC ベースのアプリケーションを設計できます。

SEAM のリリース

SEAM 製品の構成要素は、4 つのリリースに組み込まれています。次の表は、各リリースに組み込まれている構成要素の一覧です。次の節では、すべての構成要素について説明します。

表 13–1 SEAM リリースの内容


リリース名	内容
Solaris Easy Access Server (SEAS) 3.0 の SEAM 1.0	Solaris 2.6 および Solaris 7 用の SEAM の完全リリース
Solaris 8 の SEAM	SEAM クライアントソフトウェアのみ
Solaris 8 Admin Pack の SEAM 1.0.1	Solaris 8 用の SEAM KDC とリモートアプリケーション
Solaris 9 の SEAM	SEAM KDC とクライアントソフトウェアのみ
SEAM 1.0.2	Solaris 9 用の SEAM リモートアプリケーション

SEAM 1.0 の構成要素

MIT から提供される Kerberos V5 と同様に、SEAM には次の構成要素が含まれます。

鍵配布センター (KDC) (マスター)
- Kerberos データベース管理デーモン – kadmind
- Kerberos チケット処理デーモン – krb5kdc
スレーブ KDC
データベース管理プログラム – kadmin、kadmin.local
データベース伝播ソフトウェア – kprop
チケットの取得、表示、破棄を行うユーザープログラム – kinit、klist、kdestroy と SEAM パスワードを変更するユーザープログラム – kpasswd
アプリケーション – ftp、rcp、rlogin、rsh、telnet およびこれらのアプリケーションのデーモン – ftpd、rlogind、rshd、telnetd
管理ユーティリティ – ktutil、kdb5_util
いくつかのライブラリ

さらに、SEAM には次の構成要素が含まれています。

SEAM 管理ツール (gkadmin) – KDC を管理する。システム管理者は、この Java^TM テクノロジベースの GUI を使用して、通常は kadmin コマンドで実行する作業を実行できる
Pluggable Authentication Module (PAM) – PAM により、アプリケーションはさまざまな認証メカニズムを使用できる。PAM を使用すると、ログインとログアウトをユーザーが意識する必要がなくなる
ユーティリティ (gsscred) とデーモン (gssd) – これらのプログラムは、UNIX ユーザー ID (UID) と主体名の割り当てに使用する。これらのプログラムが必要なのは、SEAM NFS サーバーがユーザーを識別するときに、主体名ではなく UNIX UID を使用しており、主体名と UNIX UID は形式が異なっているためである
Generic Security Service Application Programming Interface (GSS-API) – アプリケーションは、この API を利用して、複数のセキュリティメカニズムを使用できる。新しいメカニズムを追加するたびに、アプリケーションをコンパイルし直す必要がない。GSS-API はマシンに依存しないため、インターネット上のアプリケーションに適している。GSS-API を使用すると、認証サービスだけでなく、完全性およびプライバシセキュリティサービスをアプリケーションに組み込むことができる
RPCSEC_GSS Application Programming Interface (API) – NFS サービスが Kerberos 認証を使用することができる。RPCSEC_GSS は、使用しているメカニズムに依存しないセキュリティサービスを提供する新しいセキュリティフレーバである。RPCSEC_GSS は、GSS-API 層の「最上位」に位置している。GSS_API ベースのセキュリティメカニズムは、プラグイン可能なので、RPCSEC_GSS を使用するアプリケーションで使用できる
事前構成手順 – SEAM のインストールおよび構成パラメータを設定し、SEAM インストールを自動化できる。この手順は、特に複数のインストールを行うときに適している
カーネルの変更 – パフォーマンスを向上させることができる

Solaris 8 の SEAM 構成要素

Solaris 8 に含まれている SEAM はクライアント側の部分だけで、SEAM の構成要素の多くは含まれていません。Solaris 8 が動作するシステムであれば、SEAM を別にインストールしなくても SEAM クライアントとしては動作します。これらの SEAM クライアント機能を使用するには、SEAS 3.0 または Solaris 8 Admin Pack、MIT ディストリビューション、あるいは Windows 2000 の KDC をインストールする必要があります。クライアント側の構成要素は、構成済み KDC がないとチケットを配布できません。Solaris 8 には、次の構成要素が含まれます。

チケットを取得、表示、破棄するユーザープログラム – kinit、klist、kdestroy
SEAM パスワードを変更するユーザープログラム – kpasswd
鍵テーブル管理ユーティリティ – ktutil
PAM の拡張 – アプリケーションはさまざまな認証メカニズムを使用できる。PAM を使用すると、ログインとログアウトをユーザーが意識する必要がなくなる
GSS_API プラグイン – Kerberos プロトコルおよび暗号サポートを提供する
NFS クライアントおよびサーバーのサポート

SEAM 1.0.1 の構成要素

SEAM 1.0.1 には、Solaris 8 に含まれていない SEAM 1.0 の構成要素がすべて含まれています。次の構成要素が含まれています。

鍵配布センター (KDC) (マスター)
- Kerberos データベース管理デーモン – kadmind
- Kerberos チケット処理デーモン – krb5kdc
スレーブ KDC
データベース管理プログラム – kadmin、kadmin.local
データベース伝播ソフトウェア – kprop
アプリケーション – ftp、rcp、rlogin、rsh、telnet およびこれらのアプリケーションのデーモン – ftpd、rlogind、rshd、telnetd
管理ユーティリティ – kdb5_util
SEAM 管理ツール (gkadmin) – KDC を管理する。システム管理者は、この Java テクノロジベースの GUI を使用して、通常は kadmin コマンドで実行する操作を実行できる
事前構成手順 – SEAM のインストールおよび構成パラメータを設定し、SEAM インストールを自動化できる。この手順は、特に複数のインストールを行うときに適している
いくつかのライブラリ

Solaris 9 の SEAM 構成要素

Solaris 9 には、リモートアプリケーションと事前構成手順を除いて、SEAM 1.0 の構成要素がすべて含まれています。

SEAM 1.0.2 の構成要素

SEAM 1.0.2 には、リモートアプリケーションが含まれています。SEAM 1.0 の構成要素のうちで、Solaris 9 リリースに組み込まれていないのはこれらのアプリケーションだけです。リモートアプリケーションの構成要素は次のとおりです。

クライアントアプリケーション – ftp、rcp、 rlogin、rsh、および telnet
サーバーデーモン – ftpd、 rlogind、rshd、および telnetd

第 14 章 SEAM の計画

この章は、SEAM のインストールとシステム管理を行うシステム管理者を対象としています。この章では、SEAM をインストールまたは構成する前に、システム管理者が解決しておく必要があるインストールと構成の問題について説明します。

システム管理者やテクニカルサポート担当者が解決する必要がある問題は次のとおりです。

SEAM を計画する理由

SEAM をインストールする前に、いくつかの構成についての問題を解決する必要があります。初期インストール後に構成を変更することもできますが、新しいクライアントがシステムに追加されるにつれて、変更が困難になります。また、変更によっては、すべてのシステムを再インストールしなければならないことがあります。このため、SEAM の構成を計画するときは、長期的な目標を考慮することをお勧めします。

レルム

レルムは、ドメインに似た論理ネットワークです。レルムには、同一マスター KDC に登録されるシステムのグループを定義します。DNS ドメイン名を設定する場合と同様に、レルム名、レルムの数、および各レルムの大きさは、SEAM を構成する前に解決する必要があります。また、レルム間認証を行う場合は、レルム間の関係も定義する必要があります。

レルム名

レルム名には、任意の ASCII 文字列を使用できます。レルム名には通常、DNS ドメイン名と同じ名前を大文字で指定します。この命名規則を利用すると、すでに使い慣れている名前を使用しながら、SEAM のレルム名と DNS 名前空間のドメイン名を区別することができます。DNS を使用しない場合、または別の文字列を使用する場合は、任意の文字列を使用できます。ただし、構成プロセスがより複雑になります。レルム名を付けるときは、標準のインターネット命名構造に準拠することをお勧めします。

レルムの数

インストールするレルムの数は、次の要因によって異なります。

サポートするクライアント数。 1 つのレルムに配置するクライアントが多すぎると、管理が複雑になり、レルムの分割が必要になることがある。サポートできるクライアント数は、主に次の要因によって決まる
- 各クライアントが生成する SEAM トラフィックの量
- 物理ネットワークの帯域幅
- ホストの処理速度
インストールごとに制限が違ってくるため、最大クライアント数を決定する規則はない
クライアントとの距離。クライアントが地理的に異なる領域に配置されている場合は、小さなレルムをいくつか設定することが望ましい
KDC としてインストールできるホスト数。各レルムには、複数の KDC サーバー (マスターとスレーブ) が必要である

レルムの階層

複数のレルムを構成してレルム間認証を行う場合は、レルム間の接続方法を決定する必要があります。レルム間に階層関係を設定すると、関連付けたドメインに自動パスが作成されます。このとき、階層チェーン内のすべてのレルムが適切に構成されている必要があります。自動パスを利用すると、管理負荷を軽減することができます。ただし、ドメインのレベルが多い場合は、多くのトランザクションが発生するため、デフォルトのパスは使用しないことをお勧めします。

ドメイン間を直接接続することもできます。直接接続は、2 つの階層ドメイン間にレベルが多すぎる場合または階層関係が設定されていない場合に、使用します。直接接続は、使用するすべてのホストの /etc/krb5/krb5.conf ファイルに接続を定義する必要があります。このため、追加作業が必要になります。概要については、レルムを参照してください。複数のレルムを構成する手順については、レルム間認証の構成を参照してください。

ホスト名のレルムへの割り当て

ホスト名のレルム名への割り当ては、krb5.conf ファイルの domain_realm セクションに定義します。これらの割り当ては、必要に応じてドメイン全体およびホスト単位に定義できます。詳細は、krb5.conf(4) のマニュアルページを参照してください。

クライアントとサービス主体の名前

SEAM を使用する場合、DNS サービスを事前に構成して、すべてのホスト上ですでに実行していることを強くお勧めします。DNS を使用する場合は、システム全体で有効または無効にする必要があります。DNS を有効にした場合、主体名には、各ホストの完全指定ホスト名 (FQDN) を含める必要があります。たとえば、ホスト名が boston、DNS ドメイン名が example.com、レルム名が EXAMPLE.COM であった場合、ホストの主体名は host/boston.example.com@EXAMPLE.COM にする必要があります。このマニュアルの例では、各ホストの FQDN を使用しています。

ホストの FQDN を含む主体名は、/etc/resolv.conf ファイルの DNS ドメイン名を表す文字列と一致していることが重要です。SEAM では、主体に FQDN を入力するときに、DNS ドメイン名は小文字にする必要があります。DNS ドメイン名には大文字と小文字を使用できますが、ホスト主体を作成する場合は小文字だけを使用します。たとえば、DNS ドメイン名には、example.com や Example.COM などの形式が使用できますが、ホストの主体名は、host/boston.example.com@EXAMPLE.COM でなければなりません。

SEAM は DNS サービスがなくても動作しますが、その場合、一部の主要な機能 (レルム間通信など) は動作しません。DNS を構成しない場合は、単純なホスト名がインスタンス名として使用することができます。この場合、主体名は host/boston@EXAMPLE.COM となります。DNS をあとで有効にした場合は、KDC データベースのすべてのホスト主体を削除して置換する必要があります。

KDC と管理サービス用のポート

デフォルトでは、ポート 88 とポート 750 を KDC が使用し、ポート 749 を KDC 管理デーモンが使用します。別のポート番号を使用することもできます。ただし、ポート番号を変更する場合は、各クライアントの /etc/services および /etc/krb5/krb5.conf ファイルを変更する必要があります。また、各 KDC の /etc/krb5/kdc.conf ファイルも更新する必要があります。

スレーブ KDC

スレーブ KDC は、マスター KDC と同様に、クライアントの資格を生成します。マスターが使用できなくなると、スレーブ KDC がバックアップとして使用されます。各レルムには、1 つ以上のスレーブ KDC が必要です。次の要因により、スレーブ KDC を追加する必要がある場合が考えられます。

レルム内の物理セグメント数。通常は、レルム内のほかのセグメントが動作しない場合でも、各セグメントが少なくとも最小限の機能だけは動作するように、ネットワークを設定する必要がある。この設定を実現するには、KDC をすべてのセグメントからアクセス可能にする必要がある。この場合、KDC はマスターまたはスレーブのどちらでもよい
レルム内のクライアント数。スレーブ KDC サーバーを追加すると、現在のサーバーの負荷を軽減することができる

スレーブ KDC の数に制限はありません。ただし、KDC データベースは、各サーバーに伝播する必要があります。このため、インストールした KDC サーバーが多くなるにつれて、レルム全体のデータ更新時間が長くなります。また、各スレーブには KDC データベースのコピーが保存されるため、スレーブが多くなるほど、セキュリティ違反の危険性が高くなります。

1 つまたは複数のスレーブ KDC をマスター KDC とスワップするように構成することができます。このように 1 つ以上のスレーブ KDC をシステムに事前に構成しておくと、マスター KDC になんらかの理由で障害が発生した場合でも、マスター KDC と簡単にスワップすることができます。スワップ可能なスレーブ KDC の構成方法については、マスター KDC とスレーブ KDC のスワップを参照してください。

データベースの伝播

マスター KDC に格納されているデータベースは、定期的にスレーブ KDC に伝播する必要があります。最初に解決しなければならない問題の 1 つは、スレーブ KDC の更新頻度です。すべてのクライアントに対する最新情報の伝播頻度を決定するときは、更新の完了に必要な時間を考慮する必要があります。データベースの伝播の詳細は、Kerberos データベースの管理を参照してください。

1 つのレルムに多くの KDC が配置されている場合は、1 つまたは複数のスレーブからもデータを伝播すると、伝播プロセスを並行して行うことができます。この方法を利用すると、データの更新時間は少なくなりますが、レルムの管理は複雑になります。

クロックの同期

Kerberos 認証システムに参加するすべてのホストは、指定した最大時間内で内部クロックを同期化する必要があります。「クロックスキュー」と呼ばれるこの機能も、Kerberos セキュリティ検査の 1 つです。参加しているホスト間でクロックスキューを超過すると、要求が拒否されます。

すべてのクロックを同期化するときは、Network Time Protocol (NTP) ソフトウェアを使用します。詳細は、KDC と SEAM クライアントのクロックの同期化を参照してください。クロックの同期化には、ほかにも方法があり、NTP は必須ではありません。任意の同期化形式を使用して、クロックスキューによるアクセス障害を回避してください。

オンラインヘルプ URL

SEAM のシステム管理ツールでは、オンラインヘルプ URL が使用されるため、「Help Contents」メニューが機能するように URL を適切に定義する必要があります。このマニュアルの HTML 版は、任意のサーバーにインストールできます。また、 http://docs.sun.com から任意のマニュアルを使用することもできます。

URL には、このマニュアルの「主体とポリシーの管理」の「SEAM 管理ツール」を指定してください。必要に応じて、別の HTML ページを選択することもできます。

第 15 章 SEAM の構成 (手順)

この章では、ネットワークアプリケーションサーバーの構成と手順およびインストール手順について説明します。

SEAM の構成 (作業マップ)

構成手順は、その個々の手順がほかの手順に依存するため、規定の順序で実行する必要があります。多くの場合、これらの手順に従うことにより、 SEAM に必要なサービスを設定できます。その他の手順は互いに依存しないため、任意のタイミングで実行できます。次の作業マップで、推奨する SEAM のインストール順序を示します。

表 15–1 第一段階: SEAM の構成順序


作業	説明	参照先
1. SEAM インストールの計画	ソフトウェア構成処理を開始する前に、構成についての問題を解決する。事前に計画することで、結果的に時間やその他のリソースを節約できる	第 14 章「SEAM の計画」
2. (省略可能) NTP のインストール	NTP ソフトウェアなどのクロック同期プロトコルを構成する。SEAM が正常に動作するには、レルムに含まれるすべてのシステムのクロックを同期化する必要がある	KDC と SEAM クライアントのクロックの同期化
3. マスター KDC の構成	レルムに対してマスター KDC とデータベースを構成および構築する	マスター KDC を構成する方法
4. (省略可能) スレーブ KDC の構成	レルムに対してスレーブ KDC を構成および構築する	スレーブ KDC を構成する方法
5. (省略可能) KDC のセキュリティ強化	KDC サーバーに対するセキュリティ違反を回避する	KDC サーバーへのアクセスを制限する方法
6. (省略可能) スワップ可能な KDC の構成	マスター KDC とスレーブ KDC を簡単にスワップできるようにする	スワップ可能なスレーブ KDC を構成する方法

必要な手順が完了したあと、必要に応じて次の手順を行います。

表 15–2 次の段階: 追加の SEAM 作業


作業	説明	参照先
レルム間認証の構成	レルム間の通信を使用可能にする	レルム間認証の構成
SEAM クライアントの構成	クライアントが SEAM サービスを使用できるようにする	SEAM クライアントの構成
SEAM NFS サーバーの構成	Kerberos 認証を必要とするファイルシステムを、サーバーが共有できるようにする	SEAM NFS サーバーの構成

KDC サーバーの構成

SEAM ソフトウェアをインストールしたあと、KDC サーバーを構成する必要があります。資格を発行するには、1 つのマスター KDC と 1 つ以上のスレーブ KDC を構成する必要があります。KDC が発行する資格は、SEAM の基本要素であるため、KDC をインストールしないと、ほかの処理を行うことはできません。

マスター KDC とスレーブ KDC の最も大きな違いは、マスター KDC だけがデータベース管理要求を処理できることです。たとえば、パスワードの変更や新しい主体の追加は、マスター KDC で行います。これらの変更は、スレーブ KDC に伝播されます。資格の生成は、スレーブ KDC とマスター KDC が行います。この機能は、マスター KDC が応答できない場合に、冗長性を確保します。

マスター KDC を構成する方法

この手順では、次の構成パラメータを使用します。

レルム名 = EXAMPLE.COM
DNS ドメイン名 = example.com
マスター KDC = kdc1.example.com
スレーブ KDC = kdc2.example.com
admin 主体 = kws/admin
オンラインヘルプ URL = http://denver:8888/ab2/coll.384.1/SEAM/@AB2PageView/6956

注 –
この URL は、「SEAM 管理ツール」の節を指すように調整してください (オンラインヘルプ URLを参照)。

マスター KDC を構成するための前提条件を完了します。

この手順を実行するには、DNS が動作している必要があります。マスター KDC をスワップ可能にする場合の命名手順については、マスター KDC とスレーブ KDC のスワップを参照してください。

マスター KDC 上でスーパーユーザーになります。

Kerberos 構成ファイル (krb5.conf) を編集します。

レルム名とサーバー名を変更する必要があります。このファイルの詳細は、krb5.conf(4) のマニュアルページを参照してください。

kdc1 # cat /etc/krb5/krb5.conf
[libdefaults]
        default_realm = EXAMPLE.COM

[realms]
                EXAMPLE.COM = {
                kdc = kdc1.example.com
                kdc = kdc2.example.com
                admin_server = kdc1.example.com
        }

[domain_realm]
        .example.com = EXAMPLE.COM
#
# ドメイン名とレルム名が同じ場合、 
# このエントリは必要ない
#
[logging]
        default = FILE:/var/krb5/kdc.log
        kdc = FILE:/var/krb5/kdc.log

[appdefaults]
    gkadmin = {
        help_url = http://denver:8888/ab2/coll.384.1/SEAM/@AB2PageView/6956
        }

この例では、domain_realm、 kdc、admin_server、およびすべての domain_realm エントリの行を変更しました。また、help_url を定義する行を編集しました。

KDC 構成ファイル (kdc.conf) を編集します。

レルム名を変更する必要があります。KDC 構成ファイルの詳細は、kdc.conf(4) のマニュアルページを参照してください。

kdc1 # cat /etc/krb5/kdc.conf
[kdcdefaults]
        kdc_ports = 88,750

[realms]
        EXAMPLE.COM= {
                profile = /etc/krb5/krb5.conf
                database_name = /var/krb5/principal
                admin_keytab = /etc/krb5/kadm5.keytab
                acl_file = /etc/krb5/kadm5.acl
                kadmind_port = 749
                max_life = 8h 0m 0s
                max_renewable_life = 7d 0h 0m 0s
        }

この例では、realms セクションのレルム名定義を変更しました。

kdb5_util コマンドを使用して、KDC データベースを作成します。

kdb5_util は、KDC データベースを作成するコマンドです。-s オプションを指定すると、kadmind と krb5kdc デーモンが起動する前に、KDC の認証に使用される stash ファイルが作成されます。

kdc1 # /usr/sbin/kdb5_util create -r EXAMPLE.COM -s
Initializing database '/var/krb5/principal' for realm 'EXAMPLE.COM'
master key name 'K/M@EXAMPLE.COM'
You will be prompted for the database Master Password.
It is important that you NOT FORGET this password.
Enter KDC database master key: <鍵を入力する>
Re-enter KDC database master key to verify: <鍵を再度入力する>

レルム名がサーバーの名前空間のドメイン名と同じ場合は、レルム名を指定する -r オプションは必要はありません。

Kerberos アクセス制御リストファイル (kadm5.acl) を編集します。

/etc/krb5/kadm5.acl ファイルには、KDC を管理できる主体名がすべて含まれている必要があります。最初のエントリは、次のようになります。
kws/admin@EXAMPLE.COM *
このエントリにより、 EXAMPLE.COM レルム内の kws/admin 主体に対して、KDC 内の主体またはポリシーを変更する機能が与えられます。デフォルトのインストールでは、アスタリスク (*) が指定され、すべての admin 主体に変更権限が与えられます。このデフォルトの指定では、セキュリティが低下する可能性があります。そのため、admin 主体をすべてリストに含めると、セキュリティが向上します。詳細は、kadm5.acl(4) のマニュアルページを参照してください。

kadmin.local コマンドを起動します。

次の手順では、SEAM で使用される主体を作成します。

kdc1 # /usr/sbin/kadmin.local
kadmin.local:

データベースに管理主体を追加します。

必要な数の admin 主体を追加できます。KDC 構成処理を完了するには、1 つ以上の admin 主体を追加する必要があります。この例では、kws/admin 主体を追加します。「kws」の代わりに、適切な主体名を置き換えてください。

kadmin.local: addprinc kws/admin
Enter password for principal kws/admin@EXAMPLE.COM: <パスワードを入力する>
Re-enter password for principal kws/admin@EXAMPLE.COM: <パスワードを再度入力する>
Principal "kws/admin@EXAMPLE.COM" created.
kadmin.local:

kadmind サービスのキータブファイルを作成します。

このコマンドシーケンスは、kadmin および changepw 主体のエントリを保持するキータブを作成します。これらの主体は、kadmind サービスに必要です。主体のインスタンスがホスト名のときは、/etc/resolv.conf ファイル内のドメイン名が大文字であるか小文字であるかにかかわらず、FQDN は小文字で入力する必要があります。

kadmin.local: ktadd -k /etc/krb5/kadm5.keytab kadmin/kdc1.example.com
Entry for principal kadmin/kdc1.example.com with kvno 3, encryption type DES-CBC-CRC
          added to keytab WRFILE:/etc/krb5/kadm5.keytab.
kadmin.local: ktadd -k /etc/krb5/kadm5.keytab changepw/kdc1.example.com
Entry for principal changepw/kdc1.example.com with kvno 3, encryption type DES-CBC-CRC 
          added to keytab WRFILE:/etc/krb5/kadm5.keytab.
kadmin.local:

kadmin.local を終了します。

次の手順で必要になる主体をすべて追加しました。
kadmin.local: quit

Kerberos デーモンを起動します。

kdc1 # /etc/init.d/kdc start
kdc1 # /etc/init.d/kdc.master start

kadmin を起動します。

この時点で、SEAM 管理ツールを使用して、主体を追加します。追加するには、上記の手順で作成した admin 主体名を使用してログインする必要があります。ただし、以下のコマンド行の例では、簡略化されています。

kdc1 # /usr/sbin/kadmin -p kws/admin
Enter password: <kws/admin パスワードを入力する>
kadmin:

マスター KDC のホスト主体を作成します。

ホスト主体は、klist や kprop などの Kerberos アプリケーションで使用されます。主体のインスタンスがホスト名のときは、/etc/resolv.conf ファイル内のドメイン名が大文字であるか小文字であるかにかかわらず、FQDN は小文字で入力する必要があります。
kadmin: addprinc -randkey host/kdc1.example.com Principal "host/kdc1.example.com@EXAMPLE.COM" created. kadmin:

(省略可能) マスター KDC の root 主体を作成します。

この主体は、認証済みの NFS マウントで使用されます。そのため、この主体は、マスター KDC 上にある必要はありません。主体のインスタンスがホスト名のときは、/etc/resolv.conf ファイル内のドメイン名が大文字であるか小文字であるかにかかわらず、FQDN は小文字で入力する必要があります。

kadmin: addprinc root/kdc1.example.com
Enter password for principal root/kdc1.example.com@EXAMPLE.COM: <パスワードを入力する>
Re-enter password for principal root/kdc1.example.com@EXAMPLE.COM: <パスワードを再度入力する>
Principal "root/kdc1.example.com@EXAMPLE.COM" created.
kadmin:

マスター KDC のキータブファイルにマスター KDC のホスト主体を追加します。

キータブファイルに追加したホスト主体が、自動的に使用されます。
kadmin: ktadd host/kdc1.example.com kadmin: Entry for principal host/kdc1.example.com with kvno 3, encryption type DES-CBC-CRC added to keytab WRFILE:/etc/krb5/krb5.keytab kadmin:

kadmin を終了します。
kadmin: quit

各 KDC のエントリを伝播構成ファイル (kpropd.acl) に追加します。

このファイルの詳細は、kprop(1M) のマニュアルページを参照してください。
kdc1 # cat /etc/krb5/kpropd.acl host/kdc1.example.com@EXAMPLE.COM host/kdc2.example.com@EXAMPLE.COM

(省略可能) NTP などのクロック同期メカニズムを使用して、マスター KDC のクロックを同期化します。

NTP のインストールと使用は、必須ではありません。ただし、認証が正常終了するには、krb5.conf ファイルの libdefaults セクションに定義されているデフォルト時間内にすべてのクロックが収まるようにする必要があります。NTP については、KDC と SEAM クライアントのクロックの同期化を参照してください。

スレーブ KDC を構成する方法

この手順では、kdc3 という名前の新しいスレーブ KDC を構成します。この手順では、次の構成パラメータを使用します。

レルム名 = EXAMPLE.COM
DNS ドメイン名 = example.com
マスター KDC = kdc1.example.com
スレーブ KDC = kdc2.example.com と kdc3.example.com
admin 主体 = kws/admin
オンラインヘルプ URL = http://denver:8888/ab2/coll.384.1/SEAM/@AB2PageView/6956

注 –
この URL は、「SEAM 管理ツール」の節を指すように調整してください (オンラインヘルプ URLを参照)。

スレーブ KDC を構成するための前提条件を完了します。

マスター KDC が構成済みである必要があります。スレーブ KDC をスワップ可能にする場合の手順については、マスター KDC とスレーブ KDC のスワップを参照してください。

マスター KDC 上でスーパーユーザーになります。

マスター KDC 上で kadmin を起動します。

マスター KDC を構成するときに作成した admin 主体名を使用して、ログインする必要があります。

kdc1 # /usr/sbin/kadmin -p kws/admin
Enter password: <kws/admin パスワードを入力する>
kadmin:

マスター KDC のデータベースにスレーブホスト主体が存在しない場合は、追加します。

スレーブが機能するには、ホスト主体が必要です。主体のインスタンスがホスト名のときは、/etc/resolv.conf ファイル内のドメイン名が大文字であるか小文字であるかに関係なく、FQDN は小文字で入力する必要があります。
kadmin: addprinc -randkey host/kdc3.example.com Principal "host/kdc3@EXAMPLE.COM" created. kadmin:

(省略可能) マスター KDC 上で、スレーブ KDC の root 主体を作成します。

この主体が必要なのは、認証済みのファイルシステムをスレーブが NFS マウントする場合だけです。主体のインスタンスがホスト名のときは、/etc/resolv.conf ファイル内のドメイン名が大文字であるか小文字であるかに関係なく、FQDN は小文字で入力する必要があります。

kadmin: addprinc root/kdc3.example.com
Enter password for principal root/kdc3.example.com@EXAMPLE.COM: <パスワードを入力する>
Re-enter password for principal root/kdc3.example.com@EXAMPLE.COM: <パスワードを再度入力する>
Principal "root/kdc3.example.com@EXAMPLE.COM" created.
kadmin:

kadmin を終了します。
kadmin: quit

マスター KDC 上で、Kerberos 構成ファイル (krb5.conf) を編集します。

各スレーブのエントリを追加する必要があります。このファイルの詳細は、krb5.conf(4) のマニュアルページを参照してください。

kdc1 # cat /etc/krb5/krb5.conf
[libdefaults]
        default_realm = EXAMPLE.COM

[realms]
                EXAMPLE.COM = {
                kdc = kdc1.example.com
                kdc = kdc2.example.com
                kdc = kdc3.example.com
                admin_server = kdc1.example.com
        }

[domain_realm]
        .example.com = EXAMPLE.COM
#
# ドメイン名とレルム名が同じ場合 
# このエントリは不要
#        
[logging]
        default = FILE:/var/krb5/kdc.log
        kdc = FILE:/var/krb5/kdc.log

[appdefaults]
    gkadmin = {
        help_url = http://denver:8888/ab2/coll.384.1/SEAM/@AB2PageView/6956

マスター KDC 上で、各スレーブ KDC のエントリをデータベース伝播構成ファイル (kpropd.acl) に追加します。

データベース伝播構成ファイルの詳細は、kprop(1M) のマニュアルページを参照してください。
kdc1 # cat /etc/krb5/kpropd.acl host/kdc1.example.com@EXAMPLE.COM host/kdc2.example.com@EXAMPLE.COM host/kdc3.example.com@EXAMPLE.COM

すべてのスレーブ KDC 上で、マスター KDC サーバーから KDC 管理ファイルをコピーします。

この手順は、マスター KDC サーバーが、各 KDC サーバーに必要な情報を更新したため、すべてのスレーブ KDC 上で実行する必要があります。ftp などの転送メカニズムを使用して、マスター KDC から次のファイルのコピーを取得できます。
- /etc/krb5/krb5.conf
- /etc/krb5/kdc.conf
- /etc/krb5/kpropd.acl

新しいスレーブ上で kadmin を使用して、スレーブのホスト主体をスレーブのキータブファイルに追加します。

マスター KDC を構成するときに作成したadmin 主体名を使用してログインする必要があります。ログインすると、kprop などの Kerberos アプリケーションが機能します。主体のインスタンスがホスト名のときは、/etc/resolv.conf ファイル内のドメイン名が大文字であるか小文字であるかに関係なく、FQDN は小文字で入力する必要があります。

kdc3 # /usr/sbin/kadmin -p kws/admin
Enter password: <kws/admin パスワードを入力する>
kadmin: ktadd host/kdc3.example.com
kadmin: Entry for principal host/kdc3.example.com with
  kvno 3, encryption type DES-CBC-CRC added to keytab
  WRFILE:/etc/krb5/krb5.keytab
kadmin: quit

マスター KDC 上で、スレーブ KDC 名を cron ジョブに追加します。このジョブは、crontab -e を実行して、自動的にバックアップを実行します。

kprop_script 行の末尾に、各スレーブ KDC のサーバー名を追加します。
10 3 * * * /usr/lib/krb5/kprop_script kdc2.example.com kdc3.example.com
バックアップの時刻を変更することもできます。この構成では、バックアップ処理を毎日午前 3 時 10 分に開始します。

マスター KDC 上のデータベースを、 kprop_script を使用してバックアップし、伝播します。

データベースのバックアップコピーがすでに作成されている場合は、ここでバックアップを作成する必要はありません。詳細は、Kerberos データベースをスレーブ KDC に手動で伝播する方法を参照してください。　
kdc1 # /usr/lib/krb5/kprop_script kdc3.example.com Database propagation to kdc3.example.com: SUCCEEDED

新しいスレーブ上で、kdb5_util を使用して stash ファイルを作成します。

kdc3 # /usr/sbin/kdb5_util stash
kdb5_util: Cannot find/read stored master key while reading master key
kdb5_util: Warning: proceeding without master key

Enter KDC database master key: <鍵を入力する>

(省略可能) 新しいスレーブ KDC 上で、NTP などのクロック同期メカニズムを使用して、マスター KDC のクロックと同期化します。

ネットワーク時間プロトコル (NTP) のインストールと使用は、必須ではありません。ただし、認証が正常終了するには、krb5.conf ファイルの libdefaults セクションに定義されているデフォルト時間内にすべてのクロックが収まるようにする必要があります。NTP については、KDC と SEAM クライアントのクロックの同期化を参照してください。

新しいスレーブ上で、KDC デーモン (krb5kdc) を起動します。
kdc3 # /etc/init.d/kdc start

レルム間認証の構成

複数のレルムを接続して、レルム間でユーザーを認証することができます。いくつかの方法がありますが、通常は、秘密鍵を作成し、2 つのレルム間で共有します。レルム間の関係には、階層関係または直接接続があります (レルムの階層を参照)。

階層関係のレルム間認証を設定する方法

この手順の例では、 ENG.EAST.EXAMPLE.COM レルムと EAST.EXAMPLE.COM レルムを使用します。レルム間認証は、双方向に確立されます。この手順は、2 つのレルムのマスター KDC 上で完了する必要があります。

階層関係のレルム間認証の前提条件を完了します。

マスター KDC の各レルムが構成済みである必要があります。認証処理を十分にテストするには、複数のクライアントまたはスレーブ KDCをインストールしている必要があります。

最初のマスター KDC 上でスーパーユーザーになります。

2 つのレルムに対して、TGT のサービス主体を作成します。

マスター KDC を構成したときに作成した admin 主体名を使用して、ログインする必要があります。

# /usr/sbin/kadmin -p kws/admin
Enter password: <kws/admin パスワードを入力する>
kadmin: addprinc krbtgt/ENG.EAST.EXAMPLE.COM@EAST.EXAMPLE.COM
Enter password for principal krgtgt/ENG.EAST.EXAMPLE.COM@EAST.EXAMPLE.COM: <パスワードを入力する>
kadmin: addprinc krbtgt/EAST.EXAMPLE.COM@ENG.EAST.EXAMPLE.COM
Enter password for principal krgtgt/EAST.EXAMPLE.COM@ENG.EAST.EXAMPLE.COM: <パスワードを入力する>
kadmin: quit

注 –

各サービス主体のパスワードは、2 つの KDC で同一である必要があります。そのため、サービス主体 krbtgt/ENG.EAST.EXAMPLE.COM@EAST.EXAMPLE.COM のパスワードは、2 つのレルムで同じである必要があります。

Kerberos 構成ファイル (krb5.conf) にエントリを追加して、すべてのレルムのドメイン名を定義します。
# cat /etc/krb5/krb5.conf [libdefaults] . . [domain_realm] .eng.east.example.com = ENG.EAST.EXAMPLE.COM .east.example.com = EAST.EXAMPLE.COM
この例では、ENG.EAST.EXAMPLE.COM レルムと EAST.EXAMPLE.COM レルムのドメイン名を定義しています。Kerberos 構成ファイルは先頭から末尾方向に検索されるため、サブドメインは最初に定義してください。

Kerberos 構成ファイルをこのレルムのすべてのクライアントにコピーします。

レルム間認証が動作するには、すべてのシステム (スレーブ KDC などのサーバーを含む) に新しいバージョンの Kerberos 構成ファイル (/etc/krb5/krb5.conf) がインストールされている必要があります。

もう一方のレルムで上記の手順を繰り返します。

直接接続のレルム間認証を確立する方法

この手順では、ENG.EAST.EXAMPLE.COM レルムと SALES.WEST.EXAMPLE.COM レルムを使用します。レルム間認証は、双方向に確立されます。この手順は、2 つのレルムのマスター KDC 上で完了する必要があります。

直接接続のレルム間認証の前提条件を完了します。

マスター KDC の各レルムが構成済みである必要があります。認証処理を十分にテストするには、複数のクライアントまたはスレーブ KDCをインストールしている必要があります。

いずれかのマスター KDC サーバー上でスーパーユーザーになります。

2 つのレルムに対して、TGT のサービス主体を作成します。

マスター KDC を構成したときに作成した admin 主体名を使用して、ログインする必要があります。

# /usr/sbin/kadmin -p kws/admin
Enter password: <kws/admin パスワードを入力する>
kadmin: addprinc krbtgt/ENG.EAST.EXAMPLE.COM@SALES.WEST.EXAMPLE.COM
Enter password for principal 
  krgtgt/ENG.EAST.EXAMPLE.COM@SALES.WEST.EXAMPLE.COM: <パスワードを入力する>
kadmin: addprinc krbtgt/SALES.WEST.EXAMPLE.COM@ENG.EAST.EXAMPLE.COM
Enter password for principal 
  krgtgt/SALES.WEST.EXAMPLE.COM@ENG.EAST.EXAMPLE.COM: <パスワードを入力する>
kadmin: quit

注 –

各サービス主体のパスワードは、2 つの KDC で同一である必要があります。そのため、サービス主体 krbtgt/ENG.EAST.EXAMPLE.COM@SALES.WEST.EXAMPLE.COM のパスワードは、2 つのレルムで同じである必要があります。

Kerberos 構成ファイル (krb5.conf) にエントリを追加して、リモートレルムへの直接パスを定義します。

この例は、ENG.EAST.EXAMPLE.COM レルムのクライアントを示しています。SALES.WEST.EXAMPLE.COM レルムで適切な定義をするには、レルム名をスワップする必要があります。

# cat /etc/krb5/krb5.conf
[libdefaults]
 .
 .
[capaths]
    ENG.EAST.EXAMPLE.COM = {
        SALES.WEST.EXAMPLE.COM = .
    }

    SALES.WEST.EXAMPLE.COM = {
         ENG.EAST.EXAMPLE.COM = .
    }

Kerberos 構成ファイルを現在のレルムのすべてのクライアントにコピーします。

レルム間認証が動作するには、すべてのシステム (スレーブ KDC などのサーバーを含む) に新しいバージョンの Kerberos 構成ファイル (krb5.conf) がインストールされている必要があります。

もう一方のレルムで上記の手順を繰り返します。

SEAM NFS サーバーの構成

NFS サービスは、UNIX ユーザー ID (UID) を使用してユーザーを識別しますが、主体を直接使用することはできません。そのため、主体を UID に対応付けるために、ユーザー主体を UNIX UID に割り当てる資格テーブルを作成する必要があります。この節では、SEAM NFS サーバーの構成手順、資格テーブルの管理手順、および NFS マウントしたファイルシステムに対して Kerberos セキュリティモードを有効にする手順を中心に説明します。次の表は、この節で説明する作業の一覧です。

表 15–3 SEAM NFS サーバーの構成 (作業マップ)


作業	説明	参照先
SEAM NFS サーバーを構成する	Kerberos 認証を必要とするファイルシステムを、サーバーが共有できるようにする	SEAM NFS サーバーを構成する方法
資格テーブルを作成する	資格テーブルを生成する	資格テーブルを作成する方法
ユーザー主体を UNIX UID に割り当てる資格テーブルを変更する	資格テーブルの情報を更新する	資格テーブルに 1 つのエントリを追加する方法
Kerberos 認証を使用してファイルシステムを共有する	セキュリティモードを使用してファイルシステムを共有し、Kerberos 認証を常に行う	複数の Kerberos セキュリティモードで安全な NFS 環境を設定する方法

SEAM NFS サーバーを構成する方法

この手順では、次の構成パラメータを使用します。

レルム名 = EXAMPLE.COM
DNS ドメイン名 = example.com
NFS サーバー = denver.example.com
admin 主体 = kws/admin

SEAM NFS サーバーを構成するための前提条件を完了します。

マスター KDC が構成されている必要があります。処理を十分にテストするには、複数のクライアントが必要です。

(省略可能) NTP クライアントなどのクロック同期メカニズムをインストールします。

NTP のインストールと使用は、必須ではありません。ただし、認証が正常終了するには、krb5.conf ファイルの libdefaults セクションに定義されているデフォルト時間内に、すべてのクロックを調整する必要があります。NTP については、KDC と SEAM クライアントのクロックの同期化を参照してください。

kadmin を起動します。

SEAM 管理ツールを使って主体を追加する方法については、新しい主体を作成する方法を参照してください。追加するときは、マスター KDC を構成するときに作成した admin 主体名を使用してログインする必要があります。ただし、次の例では、コマンド行を使用して、必要な主体を追加しています。

denver # /usr/sbin/kadmin -p kws/admin
Enter password: <kws/admin パスワードを入力する>
kadmin:

サーバーの NFS サービス主体を作成します。

主体のインスタンスがホスト名のときは、/etc/resolv.conf ファイル内のドメイン名が大文字であるか小文字であるかに関係なく、FQDN は小文字で入力する必要があります。
kadmin: addprinc -randkey nfs/denver.example.com Principal "nfs/denver.example.com" created. kadmin:

(省略可能) NFS サーバーの root 主体を作成します。

kadmin: addprinc root/denver.example.com
Enter password for principal root/denver.example.com@EXAMPLE.COM: <パスワードを入力する>
Re-enter password for principal root/denver.example.com@EXAMPLE.COM: <パスワードを再度入力する>
Principal "root/denver.example.com@EXAMPLE.COM" created.
kadmin:

サーバーの NFS サービス主体をサーバーのキータブファイルに追加します。

kadmin: ktadd nfs/denver.example.com
kadmin: Entry for principal nfs/denver.example.com with
  kvno 3, encryption type DES-CBC-CRC added to keytab
  WRFILE:/etc/krb5/krb5.keytab
kadmin:

kadmin を終了します。
kadmin: quit

gsscred テーブルを作成します。

詳細は、資格テーブルを作成する方法を参照してください。

NFS ファイルシステムを Kerberos セキュリティモードで共有します。

詳細は、複数の Kerberos セキュリティモードで安全な NFS 環境を設定する方法を参照してください。

クライアントごとに、ユーザー主体と root 主体を認証します。

資格テーブルを作成する方法

gsscred 資格テーブルは、SEAM 主体を UID に割り当てるために NFS サーバーが使用します。NFS クライアントが Kerberos 認証を使用して NFS サーバーからファイルシステムをマウントするには、このテーブルを作成して使用可能にする必要があります。

/etc/gss/gsscred.conf を編集してこのメカニズムを変更します。

このメカニズムを files に変更します。

gsscred を使用して資格テーブルを作成します。
# gsscred -m kerberos_v5 -a
gsscred コマンドは、 /etc/nsswitch.conf ファイル内の passwd エントリに指定されているすべてのソースから、情報を収集します。資格テーブルにローカルのパスワードエントリを入れたくない場合は、files エントリを一時的に削除しなければならないことがあります。詳細は、gsscred(1M) のマニュアルページを参照してください。

資格テーブルに 1 つのエントリを追加する方法

この手順を行うには、gsscred テーブルがすでに NFS サーバーに作成済みである必要があります。

NFS サーバーでスーパーユーザーになります。

gsscred を使用してエントリをテーブルに追加します。

# gsscred -m mech [ -n name [ -u uid ]] -a

`mech`	使用するセキュリティメカニズムを定義する
`name`	KDC に定義されている、ユーザーの主体名を定義する
`uid`	パスワードデータベースに定義されている、ユーザーの UID を定義する
`-a`	UID を主体名の割り当てに追加する

例 — 資格テーブルに 1 つのエントリを追加する

次の例では、sandy という名前のユーザーエントリを追加し、UID 3736 に割り当てます。UID をコマンド行に指定しない場合は、パスワードファイルの UID が使用されます。

# gsscred -m kerberos_v5 -n sandy -u 3736 -a

複数の Kerberos セキュリティモードで安全な NFS 環境を設定する方法

NFS サーバー上でスーパーユーザーになります。

キータブファイルに NFS サービス主体が存在することを確認します。

klist コマンドを指定すると、キータブファイルが存在するかどうかが出力され、その主体が表示されます。キータブファイルが存在しない場合、または NFS サービス主体が存在しない場合は、SEAM NFS サーバーを構成する方法のすべての手順が完了していることを検証する必要があります。
# klist -k Keytab name: FILE:/etc/krb5/krb5.keytab KVNO Principal ---- --------------------------------------------------------- 3 nfs/denver.example.com@EXAMPLE.COM

/etc/nfssec.conf ファイル内の Kerberos セキュリティモードを有効にします。

/etc/nfssec.conf ファイルを編集して、Kerberos セキュリティモードの先頭にある “#” を削除します。

# cat /etc/nfssec.conf
 .
 .
#
# NFS の Kerberos V5 を使用するために次の行をコメントからはずす
#
krb5            390003  kerberos_v5     default -               # RPCSEC_GSS
krb5i           390004  kerberos_v5     default integrity       # RPCSEC_GSS
krb5p           390005  kerberos_v5     default privacy         # RPCSEC_GSS

/etc/dfs/dfstab ファイルを編集します。必要なセキュリティモードを sec= オプションに指定して、適切なエントリに追加します。

share -F nfs -o sec=mode file-system

`mode`	共有するときに使用するセキュリティモードを指定する。複数のセキュリティモードを使用するときは、デフォルトとして、リストの最初のモードがオートマウンタによって使用される
`file-system`	共有するファイルシステムへのパスを定義する

指定されたファイルシステムのファイルにアクセスするすべてのクライアントは、Kerberos 認証が必要です。ファイルにアクセスするには、NFS クライアント上のユーザー主体と root 主体が両方とも認証される必要があります。

NFS サービスがサーバー上で動作していることを確認します。

share コマンドまたは share コマンドセットを初めて実行する場合、NFS デーモンが動作していないことがあります。次のコマンドでデーモンを終了し、再起動してください。
# /etc/init.d/nfs.server stop # /etc/init.d/nfs.server start

(省略可能) オートマウンタを使用する場合は、auto_master データベースを編集して、デフォルト以外のセキュリティモードを選択してください。

ファイルシステムのアクセスにオートマウンタを使用しない場合やデフォルトの選択をセキュリティモードとして使用する場合は、この手順を行う必要はありません。
file-system auto_home -nosuid,sec=mode

(省略可能) 手動で mount コマンドを実行し、デフォルト以外のモードを使用してファイルシステムにアクセスします。

この代わりに、mount コマンドにセキュリティモードを指定できますが、オートマウンタは利用できません。
# mount -F nfs -o sec=mode file-system

例 — 1 つの Kerberos セキュリティモードでファイルシステムを共有する

この例の dfstab ファイルの行は、NFS サービスを使用してファイルにアクセスするには、Kerberos 認証が正常終了する必要があることを示しています。

# grep krb /etc/dfs/dfstab
share -F nfs -o sec=krb5 /export/home

例 — 複数の Kerberos セキュリティモードでファイルシステムを共有する

次の例では、3 つの Kerberos セキュリティモードがすべて選択されています。マウント要求にセキュリティモードが指定されていない場合は、NFS V3 のすべてのクライアントに対して、最初のモードが使用されます (この場合は krb5)。詳細は、nfssec.conf(4) のマニュアルページを参照してください。

# grep krb /etc/dfs/dfstab
share -F nfs -o sec=krb5:krb5i:krb5p /export/home

SEAM クライアントの構成

SEAM クライアントは、SEAM サービスを使用する同じネットワーク上のすべてのホスト (KDC サーバーを除く) です。この節では、SEAM クライアントのインストール手順と、root 認証を使用して NFS ファイルシステムをマウントする方法について説明します。

SEAM クライアントを構成する方法

この手順では、次の構成パラメータを使用します。

レルム名 = EXAMPLE.COM
DNS ドメイン名 = example.com
マスター KDC = kdc1.example.com
スレーブ KDC = kdc2.example.com
クライアント = client.example.com
admin 主体 = kws/admin
ユーザー主体 = mre
オンラインヘルプ URL = http://denver:8888/ab2/coll.384.1/SEAM/@AB2PageView/6956

注 –
この URL は、「SEAM 管理ツール」の節を指すように調整してください (オンラインヘルプ URLを参照)。

スーパーユーザーになります。

Kerberos 構成ファイル (krb5.conf) を編集します。

このファイルを SEAM のデフォルト版から変更するには、レルム名とサーバー名を変更する必要があります。gkadmin のヘルプファイルへのパスも指定する必要があります。

kdc1 # cat /etc/krb5/krb5.conf
[libdefaults]
        default_realm = EXAMPLE.COM

[realms]
                EXAMPLE.COM = {
                kdc = kdc1.example.com
                kdc = kdc2.example.com
                admin_server = kdc1.example.com
        }

[domain_realm]
        .example.com = EXAMPLE.COM
#
# if the domain name and realm name are equivalent, 
# this entry is not needed
#
[logging]
        default = FILE:/var/krb5/kdc.log
        kdc = FILE:/var/krb5/kdc.log

[appdefaults]
    gkadmin = {
        help_url = http://denver:8888/ab2/coll.384.1/SEAM/@AB2PageView/6956

(省略可能) NTP などのクロック同期メカニズムを使用して、クライアントのクロックをマスター KDC のクロックと同期化します。

NTP のインストールと使用は、必須ではありません。ただし、認証が正常終了するには、krb5.conf ファイルの libdefaults セクションに定義されているデフォルト時間内に、すべてのクロックを調整する必要があります。NTP については、KDC と SEAM クライアントのクロックの同期化を参照してください。

(省略可能) ユーザー主体が存在しない場合は、ユーザー主体を作成します。

このホストに関連付けられているユーザーに主体が割り当てられていない場合だけ、ユーザー主体を作成します。SEAM 管理ツールの使用方法については、新しい主体を作成する方法を参照してください。以下は、コマンド行の例です。

client1 # /usr/sbin/kadmin -p kws/admin
Enter password: <kws/admin パスワードを入力する>
kadmin: addprinc mre
Enter password for principal mre@EXAMPLE.COM: <パスワードを入力する>
Re-enter password for principal mre@EXAMPLE.COM: <パスワードを再度入力する>
kadmin:

root 主体を作成します。

主体のインスタンスがホスト名のときは、/etc/resolv.conf ファイル内のドメイン名が大文字であるか小文字であるかに関係なく、FQDN は小文字で入力する必要があります。

kadmin: addprinc root/client1.example.com
Enter password for principal root/client1.example.com@EXAMPLE.COM: <パスワードを入力する>
Re-enter password for principal root/client1.example.com@EXAMPLE.COM: <パスワードを再度入力する>
kadmin: quit

(省略可能) NFS で Kerberos を使用するには、 /etc/nfssec.conf ファイル内の Kerberos セキュリティモードを有効にします。

/etc/nfssec.conf ファイルを編集して、Kerberos セキュリティモードの先頭にある “#” を削除します。

# cat /etc/nfssec.conf
 .
 .
#
# NFS の Kerberos V5 を使用するために次の行をコメントからはずす
#
krb5            390003  kerberos_v5     default -               # RPCSEC_GSS
krb5i           390004  kerberos_v5     default integrity       # RPCSEC_GSS
krb5p           390005  kerberos_v5     default privacy         # RPCSEC_GSS

(省略可能) SEAM クライアント上のユーザーが Kerberos NFS ファイルシステムを自動的にマウントして Kerberos 認証を使用する場合は、root ユーザーを認証する必要があります。

この処理を最も安全に実行するには、kinit コマンドを使用します。ただし、Kerberos によって保護されているファイルシステムをマウントするときは、 root として kinit を使用する必要があります。代わりに、キータブファイルを使用することもできます。キータブファイルの要件の詳細については、NFS ファイルシステムをマウントするように root 認証を設定するを参照してください。

client1 # /usr/bin/kinit root/client1.example.com
Password for root/client1.example.com@EXAMPLE.COM: <パスワードを入力する>

キータブファイルを使用するには、kadmin を使用して root 主体をクライアントのキータブに追加します。

client1 # /usr/sbin/kadmin -p kws/admin
Enter password: <kws/admin パスワードを入力する>
kadmin: ktadd root/client1.example.com
kadmin: Entry for principal root/client.example.com with
  kvno 3, encryption type DES-CBC-CRC added to keytab
  WRFILE:/etc/krb5/krb5.keytab
kadmin: quit

クライアントから Kerberos チケットの有効期限切れをユーザーに警告する場合は、/etc/krb5/warn.conf ファイルにエントリを作成します。

詳細は、warn.conf(4) のマニュアルページを参照してください。

例 - SEAM 以外の KDC を使用するように SEAM クライアントを設定する

SEAM 以外の KDC を使用するように SEAM クライアントを設定することができます。この場合、/etc/krb5/krb5.conf ファイルの realms セクションに、1 行を追加する必要があります。この行を追加すると、クライアントが Kerberos パスワード変更サーバーとの通信に使用するプロトコルが変更されます。この行の書式は次のとおりです。

[realms]
                EXAMPLE.COM = {
                kdc = kdc1.example.com
                kdc = kdc2.example.com
                admin_server = kdc1.example.com
                kpasswd_protocol = SET_CHANGE
        }

NFS ファイルシステムをマウントするように `root` 認証を設定する

Kerberos 以外の NFS ファイルシステムにアクセスする場合は、root として NFS ファイルシステムをマウントするか、ユーザーがファイルシステムにアクセスしたときにオートマウンタを介して自動的にアクセスできます。後者の場合、root アクセス権は必要ありません。

Kerberos NFS ファイルシステムをマウントする場合もほとんど同じですが、操作が複雑になります。Kerberos NFS ファイルシステムをマウントするには、root として kinit コマンドを使用し、クライアントの root 主体の資格を取得する必要があります。クライアントの root 主体は通常、クライアントのキータブに登録されていないためです。この手順は、オートマウンタが設定されているときでも必要です。また、すべてのユーザーがシステムの root パスワードと root 主体のパスワードを知っている必要があります。

この手順を省略するには、クライアントの root 主体をクライアントのキータブファイルに追加し、root の資格を自動的に与えるようにします。この方法を利用すると、ユーザーは kinit コマンドを実行しなくても NFS ファイルシステムをマウントでき、使いやすさが向上しますが、セキュリティが低下します。たとえば、キータブ内の root 主体を使用してシステムへのアクセス権を取得した場合、root の資格を取得できます。このため、セキュリティ対策を適切に行う必要があります。詳細は、キータブファイルの管理を参照してください。

KDC と SEAM クライアントのクロックの同期化

Kerberos 認証システムに参加するすべてのホストは、指定した最大時間内で内部クロックを同期化する必要があります (「クロックスキュー」) 。同時に、Kerberos セキュリティを検査することにもなります。参加しているホスト間のクロックスキューが超過すると、クライアントの要求が拒否されます。

アプリケーションサーバーが再実行要求を認識し拒否する目的で、すべての Kerberos プロトコルメッセージをどのくらいの間追跡管理する必要があるかも、クロックスキューで決まります。そのため、クロックスキュー値が長いほど、アプリケーションサーバーが収集する情報も多くなります。

最大クロックスキューのデフォルト値は、300 秒 (5 分) です。このデフォルトは、krb5.conf ファイルの libdefaults セクションで変更できます。

注 –

セキュリティ上の理由から、クロックスキュー値は 300 秒より大きくしないでください。

KDC と SEAM クライアント間で同期化したクロックを管理することは重要であるため、NTP ソフトウェアを使用して同期化します。デラウェア大学が作成した NTP パブリックドメインソフトウェアが Solaris 2.6 以降の Solaris ソフトウェアに含まれています。

注 –

クロックを同期化するときは、rdate コマンドと cron ジョブを使用することもできます。この方法は、NTP より簡単に使用できます。ただし、ここでは NTP を中心に説明します。ネットワークを使用してクロックを同期化する場合は、クロック同期化プロトコル自体も安全である必要があります。

NTP を使用すると、正確な時間とネットワーククロック同期をネットワーク環境で管理できます。NTP は基本的にはクライアントサーバー実装の状態をとります。1 つのシステムをマスタークロック (NTP サーバー) として指定します。次に、その他のすべてのシステム (NTP クライアント) をマスタークロックと同期するように設定します。

クロックを同期化するために、NTP は xntpd デーモンを使用して、インターネット標準時サーバーに合わせて UNIX システムの時刻を設定および管理します。次の図は、NTP のクライアントサーバー実装の例です。

図 15–1 NTP を使用したクロック同期

NTP サーバーがマスタークロックとなり、NTP クライアントと Kerberos クライアントが xntpd デーモンを実行しています。

KDC および SEAM クライアントがクロックを同期化するには、次の手順を実行します。

ネットワークに NTP サーバーを設定します。NTP サーバーは、マスター KDC 以外であればどのシステムでも設定できます。NTP サーバーの作業については、『Solaris のシステム管理 (資源管理とネットワークサービス)』の「NTP の管理 (作業)」を参照してださい。
ネットワークの KDC と SEAM クライアントを構成するときに、それらを NTP サーバーの NTP クライアントとして設定します。NTP クライアントの作業については、『Solaris のシステム管理 (資源管理とネットワークサービス)』の「NTP の管理 (作業)」を参照してください。

マスター KDC とスレーブ KDC のスワップ

マスター KDC とスレーブ KDC をスワップするときは、この節で説明する手順を行います。マスター KDC とスレーブ KDC のスワップは、マスター KDC に何らかの理由で障害が発生した場合、またはマスター KDC を再インストールする必要がある場合 (新しいハードウェアをインストールした場合など) にだけ行なってください。

スワップ可能なスレーブ KDC を構成する方法

この手順は、マスター KDC にスワップ可能なスレーブ KDC に対して実行します。

KDC をインストールするときに、マスター KDC およびスワップ可能なスレーブ KDC に対して別名を使用します。

KDC に対してホスト名を定義するときは、各システムの別名が DNS に登録されている必要があります。/etc/krb5/krb5.conf ファイルにホストを定義するときも、別名を使用します。

手順に従って、スレーブ KDC をインストールします。

スワップするサーバーは、レルム内でスレーブ KDC として動作している必要があります。手順については、スレーブ KDC を構成する方法を参照してください。

マスター KDC コマンドを移動します。

このスレーブ KDC からマスター KDC コマンドが実行されるのを回避するために、kprop、kadmind、および kadmin.local コマンドを予約した場所に移動します。
kdc4 # mv /usr/lib/krb5/kprop /usr/lib/krb5/kprop.save kdc4 # mv /usr/lib/krb5/kadmind /usr/lib/krb5/kadmind.save kdc4 # mv /usr/sbin/kadmin.local /usr/sbin/kadmin.local.save

root の crontab ファイルの kprop 行をコメントにします。

スレーブ KDC が KDC データベースのコピーを伝播しなくなります。

kdc4 # crontab -e
#ident  "@(#)root       1.20    01/11/06 SMI"
#
# root の crontab はアカウントデータ収集を実行するために使用する
#
# rtc コマンドは、夏時間を変更する場合に実時間クロックを
# 調整するために実行する
#
10 3 * * * /usr/sbin/logadm
15 3 * * 0 /usr/lib/fs/nfs/nfsfind
1 2 * * * [ -x /usr/sbin/rtc ] && /usr/sbin/rtc -c> /dev/null 2>&1
30 3 * * * [ -x /usr/lib/gss/gsscred_clean ] && /usr/lib/gss/gsscred_clean
#10 3 * * * /usr/lib/krb5kprop_script kdc1.example.sun.com #SUNWkr5ma

マスター KDC とスレーブ KDC をスワップする方法

この手順を実行するには、スレーブ KDC がスワップ可能なスレーブとして設定されている必要があります (スワップ可能なスレーブ KDC を構成する方法を参照)。この手順では、旧マスター KDC サーバー名は、kdc1 です。新しいマスター KDC となるスレーブ KDC の名前は、kdc4 です。

旧マスター KDC 上で、kadmind プロセスを終了します。
kdc1 # /etc/init.d/kdc.master stop
kadmind プロセスを終了するときは、旧 KDC データベースに対する変更は行わないでください。

旧マスター KDC 上で、root の crontab ファイルの kprop 行をコメントにします。

kdc1 # crontab -e
#ident  "@(#)root       1.20    01/11/06 SMI"
#
# root の crontab はアカウントデータ収集を実行するために使用する
#
# rtc コマンドは、夏時間を変更する場合に実時間クロックを
# 調整するために実行する
#
10 3 * * * /usr/sbin/logadm
15 3 * * 0 /usr/lib/fs/nfs/nfsfind
1 2 * * * [ -x /usr/sbin/rtc ] && /usr/sbin/rtc -c> /dev/null 2>&1
30 3 * * * [ -x /usr/lib/gss/gsscred_clean ] && /usr/lib/gss/gsscred_clean
#10 3 * * * /usr/lib/krb5/kprop_script kdc2.example.sun.com #SUNWkr5ma

旧マスター KDC が KDC データベースのコピーを伝播しなくなります。

旧マスター KDC 上で、kprop_script を実行してデータベースをバックアップし、伝播します。
kdc1 # /usr/lib/krb5/kprop_script kdc4.example.com Database propagation to kdc4.example.com: SUCCEEDED

旧マスター KDC 上で、マスター KDC コマンドを移動します。

マスター KDC コマンドが実行されるのを回避するために、kprop、kadmind、および kadmin.local コマンドを予約した場所に移動します。

kdc4 # mv /usr/lib/krb5/kprop /usr/lib/krb5/kprop.save
kdc4 # mv /usr/lib/krb5/kadmind /usr/lib/krb5/kadmind.save
kdc4 # mv /usr/sbin/kadmin.local /usr/sbin/kadmin.local.save
kdc4 # mv /etc/krb5/kadm5.acl /etc/krb5/kadm5.acl.save

DNS サーバー上で、マスター KDC の別名を変更します。

サーバーを変更するために、example.com ゾーンファイルを編集して masterkdc のエントリを変更します。
masterkdc IN CNAME kdc4

DNS サーバー上で、インターネットドメインネームサーバーを再起動します。

両方のサーバー上で次のコマンドを実行して、新しい別名情報を取得します。
# pkill -1 in.named

新しいマスター KDC 上で、マスター KDC コマンドを移動します。

kdc4 # mv /usr/lib/krb5/kprop.save /usr/lib/krb5/kprop
kdc4 # mv /usr/lib/krb5/kadmind.save /usr/lib/krb5/kadmind
kdc4 # mv /usr/sbin/kadmin.local.save /usr/sbin/kadmin.local

新しいマスター KDC 上で、Kerberos アクセス制御リストファイル ( kadm5.acl) を編集します。

/etc/krb5/kadm5.acl ファイルには、KDC を管理できる主体名がすべて含まれている必要があります。最初のエントリは、次のようになります。
kws/admin@EXAMPLE.COM *
このエントリにより、 EXAMPLE.COM レルム内の kws/admin 主体に対して、KDC 内の主体またはポリシーを変更する機能が与えられます。デフォルトのインストールでは、アスタリスク (*) が指定され、すべての admin 主体に変更権限が与えられます。このデフォルトの指定では、セキュリティが低下する可能性があります。そのため、admin 主体をすべてリストに含めると、セキュリティが向上します。詳細は、kadm5.acl(4) のマニュアルページを参照してください。

新しいマスター KDC 上で、kadmin.local を使用して kadmin のキータブファイルを作成します。

このコマンドシーケンスは、admin および changepw 主体のエントリを格納するためのキータブを作成します。これらの主体は、kadmind サービスに必要です。

kdc4 # /usr/sbin/kadmin.local
kadmin.local: ktadd -k /etc/krb5/kadm5.keytab kadmin/kdc4.example.com
Entry for principal kadmin/kdc4.example.com with kvno 3, encryption type DES-CBC-CRC
          added to keytab WRFILE:/etc/krb5/kadm5.keytab.
kadmin.local: ktadd -k /etc/krb5/kadm5.keytab changepw/kdc4.example.com
Entry for principal changepw/kdc4.example.com with kvno 3, encryption type DES-CBC-CRC 
          added to keytab WRFILE:/etc/krb5/kadm5.keytab.
kadmin.local: quit

新しいマスター KDC 上で、kadmind を起動します。
kdc4 # /etc/init.d/kdc.master start

root の crontab ファイル内の kprop 行を有効にします。

kdc4 # crontab -e
#ident  "@(#)root       1.19    98/07/06 SMI"
#
# root の crontab はアカウントデータ収集を実行するために使用する
#
# rtc コマンドは、夏時間を変更する場合に実時間クロックを
# 調整するために実行する
#
10 3 * * * /usr/sbin/logadm
15 3 * * 0 /usr/lib/fs/nfs/nfsfind
1 2 * * * [ -x /usr/sbin/rtc ] && /usr/sbin/rtc -c> /dev/null 2>&1
30 3 * * * [ -x /usr/lib/gss/gsscred_clean ] && /usr/lib/gss/gsscred_clean
10 3 * * * /usr/lib/krb5/kprop_script kdc1.example.sun.com #SUNWkr5ma

Kerberos データベースの管理

Kerberos データベースは、Kerberos の最も重要な構成要素であるため、適切に管理する必要があります。この節では、データベースのバックアップと復元、並列伝播の設定、stash ファイルの管理など、Kerberos データベースの管理についていくつかの手順を説明します。データベースを初期設定する手順については、マスター KDC を構成する方法を参照してください。

Kerberos データベースのバックアップと伝播

マスター KDC の Kerberos データベースをスレーブ KDC に伝播する処理は、構成処理の中で最も重要なものの 1 つです。伝播の頻度が少ないと、マスター KDC とスレーブ KDC が同期しなくなります。マスター KDC に障害が発生した場合、スレーブ KDC は最新のデータベース情報を取得できません。また、負荷を分散するためにスレーブ KDC がマスター KDC として構成されている場合も、そのスレーブ KDC をマスター KDC として使用するクライアントは最新情報を取得できません。このため、Kerberos データベースの変更頻度に基づいて、伝播頻度を適切に設定する必要があります。

マスター KDC を構成するときは、cron ジョブ内に kprop_script コマンドを設定して、Kerberos データベースを /var/krb5/slave_datatrans ダンプファイルに自動的にバックアップし、それをスレーブ KDC に伝播します。ただし、他のファイルと同様に、Kerberos データベースは壊れることがあります。スレーブ KDC のデータが壊れた場合でも、次回のデータベース自動伝播によって最新のコピーがインストールされるため、影響が発生しないこともあります。ただし、マスター KDC のデータが壊れた場合は、壊れたデータベースが次回の伝播ですべてのスレーブ KDC に伝播されます。また、壊れたデータがバックアップされると、マスター KDC 上の壊れていない前回のバックアップファイルが上書きされます。

この場合、安全なバックアップコピーが存在しないため、cron ジョブを設定して slave_datatrans ダンプファイルを定期的に別の場所にコピーするか、kdb5_util の dump コマンドを使用して別のバックアップコピーを作成することも必要です。これにより、データベースが壊れても、kdb5_util の load コマンドを使用して、マスター KDC の最新のバックアップを復元することができます。

次の点も重要です。データベースダンプファイルには主体鍵が含まれているため、許可されないユーザーがアクセスできないように、ファイルを保護する必要があります。デフォルトでは、データベースダンプファイルの読み取り権および書き込み権は、root にだけ与えられます。許可されないアクセスから保護するには、 kprop コマンドだけを使用して、データベースダンプファイルを伝播します。この場合、転送するデータが暗号化されます。また、kprop はデータをスレーブ KDC だけに伝播するため、データベースダンプファイルが間違って許可されないホストに送信される可能性が最小限になります。

注意 –

Kerberos データベースが伝播されたあとに更新され、次の伝播の前にデータベースが壊れた場合は、スレーブ KDC には更新が反映されません。この更新は失われます。このため、定期的に実行される伝播の前に重要な更新を追加した場合は、データの損失を回避するために手動でデータベースを伝播する必要があります。

`kpropd.acl` ファイル

KDC の kpropd.acl ファイルの各行には、ホスト主体名と、伝播された最新のデータベースの受信元となるシステムが指定されています。マスター KDC を使用してすべてのスレーブ KDC に伝播する場合は、各スレーブ KDC の kpropd.acl ファイルに対してマスター KDC の主体名だけを指定する必要があります。

ただし、このマニュアルの SEAM のインストールおよびインストール後の構成手順では、マスター KDC とスレーブ KDC に対して同じ kpropd.acl ファイルを追加するように説明しています。このファイルには、すべての KDC ホスト主体名が含まれます。この構成を使用すると、伝播元の KDC が一時的に使用できなくなったときでも、任意の KDC から伝播することができます。また、すべての KDC に同一のコピーを保持すると、構成の管理が容易になります。

`kprop_script` コマンド

kprop_script コマンドは、kprop コマンドを使用して Kerberos データベースをほかの KDC に伝播します。 kprop_script コマンドをスレーブ KDC 上で実行すると、そのスレーブ KDC の Kerberos データベースのコピーがほかの KDC に伝播されます。kprop_script には、ホスト名のリストを引数として指定します。区切り文字は空白です。指定したホスト名は、伝播先の KDC になります。

kprop_script を実行すると、Kerberos データベースのバックアップが /var/krb5/slave_datatrans ファイルに作成され、指定した KDC にそのファイルがコピーされます。Kerberos データベースは、伝播が完了するまでロックされます。

Kerberos データベースをバックアップする方法

マスター KDC 上でスーパーユーザーになります。

kdb5_util の dump コマンドを使用して、Kerberos データベースをバックアップします。

# /usr/sbin/kdb5_util dump [-verbose] [-d dbname] [filename [principals...]]

`-verbose`	バックアップする各主体とポリシー名を出力する
`dbname`	バックアップするデータベース名を定義する。指定したデータベース名には、`.db` が付加される。ファイルの絶対パスを指定できる。`-d` オプションを指定しない場合、デフォルトのデータベース名は `/var/krb5/principal` となる。実際には、`/var/krb5/principal.db` という名前に変換される
`filename`	データベースのバックアップに使用するファイルを定義する。ファイルの絶対パスを指定できる。ファイルを指定しなかった場合、データベースは標準出力にダンプされる
`principal`	バックアップする主体を 1 つ以上定義する (区切り文字は空白)。主体名は完全指定形式にする必要がある。主体を指定しなかった場合、データベース全体がバックアップされる

例 — Kerberos データベースのバックアップ

次の例では、Kerberos データベースは dumpfile と呼ばれるファイルにバックアップされます。-verbose オプションが指定されているため、各主体はバックアップされるときに出力されます。

# kdb5_util dump -verbose dumpfile 
kadmin/kdc1.eng.example.com@ENG.EXAMPLE.COM 
krbtgt/eng.example.com@ENG.EXAMPLE.COM 
kadmin/history@ENG.EXAMPLE.COM 
pak/admin@ENG.EXAMPLE.COM 
pak@ENG.EXAMPLE.COM
changepw/kdc1.eng.example.com@ENG.EXAMPLE.COM

次の例では、pak および pak/admin 主体が Kerberos データベースからバックアップされます。

# kdb5_util dump -verbose dumpfile pak/admin@ENG.EXAMPLE.COM pak@ENG.EXAMPLE.COM
pak/admin@ENG.EXAMPLE.COM
pak@ENG.EXAMPLE.COM

Kerberos データベースを復元する方法

マスター KDC 上でスーパーユーザーになります。

kdb_util の load コマンドを使用して、Kerberos データベースを復元します。

# /usr/sbin/kdb5_util load [-verbose] [-d dbname] [-update] [filename]

`-verbose`	復元する各主体とポリシー名を出力する
`dbname`	復元するデータベース名を定義する。指定したデータベース名には、`.db` が付加される。ファイルの絶対パスを指定できる。`-d` オプションを指定しない場合、デフォルトのデータベース名は `/var/krb5/principal` となる。実際には、`/var/krb5/principal.db` という名前に変換される
`-update`	既存のデータベースを更新する。指定しない場合、新しいデータベースが作成されるか、既存のデータベースが上書きされる
`filename`	データベースの復元に使用するファイルを定義する。ファイルの絶対パスを指定できる。

例 — Kerberos データベースの復元

次の例では、database1.db というデータベースが、dumpfile ファイルから現在のディレクトリに復元されます。-update オプションが指定されていないため、復元によって新しいデータベースが作成されます。

# kdb5_util load -d database1 dumpfile

Kerberos データベースをスレーブ KDC に手動で伝播する方法

この手順では、kprop コマンドを使用して、Kerberos データベースを伝播します。定期的に実行する cron ジョブ以外に、スレーブ KDC とマスター KDC を同期化する必要がある場合は、この手順を行います。また、kprop_script と異なり、kprop を使用した場合は、現在のデータベースバックアップだけを伝播できます。伝播する前に、Kerberos データベースの新しいバックアップは作成されません。

マスター KDC 上でスーパーユーザーになります。

(省略可能) kdb5_util コマンドを使用して、データベースをバックアップします。
# /usr/sbin/kdb5_util dump /var/krb5/slave_datatrans

kprop コマンドを使用して、データベースをスレーブ KDC に伝播します。
# /usr/lib/krb5/kprop -f /var/krb5/slave_datatrans slave_KDC

定期的に実行する cron ジョブ以外に、データベースをバックアップし、そのファイルをスレーブ KDC に伝播する場合は、次のように kprop_script コマンドを使用することもできます。

# /usr/lib/krb5/kprop_script slave_KDC

並列伝播の設定

ほとんどの場合、マスター KDC は、Kerberos データベースをスレーブ KDC に伝播するときにだけ使用されます。使用するサイトに複数のスレーブ KDC が存在する場合は、伝播処理の負荷を分散させることもできます。この概念は、「並列伝播」と呼ばれます。

並列伝播を利用すると、複数のスレーブ KDC 間でマスター KDC の伝播処理を分散できます。処理を分散すると、伝播をより早く実行でき、マスター KDC の作業を軽減することができます。

たとえば、使用するサイトに 1 つのマスター KDC と 6 個のスレーブ KDC があるとします (図 15–2 参照)。 slave-1 から slave-3 で 1 つの論理グループを構成し、slave-4 から slave-6 で別の論理グループを構成しています。並列伝播を設定するには、マスター KDC がデータベースを slave-1 と slave-4 に伝播し、これらのスレーブ KDC がグループ内のスレーブ KDC にデータベースを伝播するようにします。

図 15–2 並列伝播の構成例

2 つの伝播スレーブを持つマスター KDC です。伝播スレーブはさらにそれぞれが持つ 2 つのスレーブに、マスター KDC データベースを伝播します。

並列伝播を設定する方法

ここでは、並列伝播の詳細な手順は説明しませんが、並列伝播を有効にする構成手順の概要を示します。

マスター KDC 上で、cron ジョブ内の kprop_script エントリを変更して、次の伝播先のスレーブ KDC (伝播スレーブ) だけを引数に指定します。
伝播スレーブごとに、kprop_script エントリをその cron ジョブに追加し、伝播先のスレーブを引数に指定します。並列伝播を正しく行うには、伝播スレーブが新しい Kerberos データベースから伝播されたあとに、cron ジョブが実行されるように設定する必要があります。

注 –
伝播スレーブにかかる伝播時間は、ネットワークの帯域幅やデータベースのサイズなどの要因によって異なります。
スレーブ KDC ごとに、伝播に必要なアクセス権を設定します。伝播元の KDC のホスト主体名を各スレーブ KDC の kpropd.acl ファイルに追加します。

例 — 並列伝播の設定

図 15–2 のマスター KDC の kprop_script エントリは、次のようになります。

0 3 * * * /usr/lib/krb5/kprop_script slave-1.example.com slave-4.example.com

slave-1 の kprop_script エントリは、次のようになります。

0 4 * * * /usr/lib/krb5/kprop_script slave-2.example.com slave-3.example.com

このスレーブの伝播は、マスターからの伝播が完了してから 1 時間後に開始します。

伝播スレーブの kpropd.acl ファイルには、次のエントリが含まれます。

host/master.example.com@EXAMPLE.COM

slave-1 から伝播されるスレーブ KDC の kpropd.acl ファイルには、次のエントリが含まれます。

host/slave-1.example.com@EXAMPLE.COM

stash ファイルの管理

stash ファイルには、Kerberos データベースのマスター鍵が含まれます。このファイルは、Kerberos データベースを作成すると自動的に作成されます。stash ファイルが壊れた場合は、 kdb5_util ユーティリティの stash コマンドを使用して、置き換えることができます。kdb5_util の destroy コマンドを使用して Kerberos データベースを削除したときは、stash ファイルも削除する必要があります。データベースを削除しても、stash ファイルは自動的に削除されないため、クリーンアップを完了するには、このファイルを削除する必要があります。

stash ファイルを削除する方法

stash ファイルが配置されている KDC の上でスーパーユーザーになります。

stash ファイルを削除します。
# rm stash-file
この例では、stash-file は stash ファイルのパスを示します。デフォルトでは、stash ファイルは /var/krb5/.k5.realm にあります。

stash ファイルを再作成する場合は、kdb5_util コマンドの -f オプションを使用します。

セキュリティの強化

SEAM アプリケーションサーバーと KDC サーバーのセキュリティを強化するには、次の手順に従ってください。

KDC サーバーへのアクセスを制限する方法

マスター KDC およびスレーブ KDC には、KDC データベースのローカルコピーがあります。データベースを保護するためにこれらのサーバーへのアクセス権を制限することは、SEAM 全体のセキュリティにとって重要です。

/etc/inetd.conf ファイルでリモートサービスを無効にします。

KDC サーバーをセキュリティ保護するために、 /etc/inetd.conf ファイル内でリモートサービスを起動するエントリをコメントにして、不要なネットワークサービスをすべて無効にします。ほとんどの環境では、time と krdb5_kprop サービス以外は、無効にしてかまいません。ループバック TLI を使用するサービス (ticlts、ticotsord、および ticots) は、有効にしておくことができます。編集後のファイルは、次のようになります (簡単に示すために、ほとんどのコメントは削除されている)。

kdc1 # cat /etc/inetd.conf
#
#ident  "@(#)inetd.conf 1.33    98/06/02 SMI"   /* SVr4.0 1.5   */
  .
  .
#name     dgram   udp     wait    root    /usr/sbin/in.tnamed     in.tnamed
#
#shell    stream  tcp     nowait  root    /usr/sbin/in.rshd       in.rshd
#login    stream  tcp     nowait  root    /usr/sbin/in.rlogind    in.rlogind
#exec     stream  tcp     nowait  root    /usr/sbin/in.rexecd     in.rexecd
#comsat   dgram   udp     wait    root    /usr/sbin/in.comsat     in.comsat
#talk     dgram   udp     wait    root    /usr/sbin/in.talkd      in.talkd
#
#uucp     stream  tcp     nowait  root    /usr/sbin/in.uucpd      in.uucpd
#
#finger   stream  tcp     nowait  nobody  /usr/sbin/in.fingerd    in.fingerd
#
# Time サービスはクロック同期で使用される
#
time      stream  tcp     nowait  root    internal
time      dgram   udp     wait    root    internal
# 
  .
  .
#
100234/1  tli rpc/ticotsord wait  root    /usr/lib/gss/gssd     gssd 
#dtspc    stream  tcp     nowait  root    /usr/dt/bin/dtspcd      /usr/dt/bin/dtspcd
#100068/2-5 dgram rpc/udp wait    root    /usr/dt/bin/rpc.cmsd    rpc.cmsd
100134/1 tli rpc/ticotsord wait   root    /usr/lib/ktkt_warnd kwarnd
krb5_prop stream  tcp     nowait  root    /usr/lib/krb5/kpropd  kpropd

変更が完了したら、KDCをリブートします。

KDC をサポートするハードウェアに対するアクセスを制限します。

物理的なアクセスを制限するために、KDC とそのモニターは安全な場所に設置します。このサーバーへのアクセスを完全に制限することが目的です。

KDC データベースのバックアップを、ローカルディスクまたはスレーブ KDC に格納します。

KDC のバックアップをテープに作成する場合、そのテープのセキュリティを十分に確保してください。キータブファイルのコピーも、同様に作成します。これらのファイルをローカルファイルシステムに格納する場合は、できるだけほかのシステムと共有しないでください。格納先のファイルシステムは、マスター KDC または任意のスレーブ KDC から選択できます。

第 16 章 SEAM エラーメッセージと障害追跡

この章では、SEAM を使用するときに発生するエラーメッセージの解決策と、さまざま問題を解決するためのヒントについて説明します。次に、この章で説明するエラーメッセージと障害追跡方法の一覧を示します。

SEAM のエラーメッセージ

この節では、SEAM のエラーメッセージ、エラーの発生原因、およびその対処方法について説明します。

SEAM 管理ツールのエラーメッセージ

プリンシパルまたはポリシーのリストにアクセスできません; 「名前」フィールドを使用してください(Unable to view the list of principals or policies; use the Name field.)

原因:

ログインに使用した admin 主体には、Kerberos ACL ファイル (kadm5.acl) のリスト特権 (l) がありません。このため、主体リストまたはポリシーリストを表示できません。

対処方法:

主体名およびポリシー名を「名前 (Name)」フィールドに入力するか、適切な特権を持つ主体を使用してログインする必要があります。

JNI: Java array creation failed JNI: Java class lookup failed JNI: Java field lookup failed JNI: Java method lookup failed JNI: Java object lookup failed JNI: Java object field lookup failed JNI: Java string access failed JNI: Java string creation failed

原因:

SEAM 管理ツール (gkadmin) で使用される Java Native Interface で重大な問題が発生しました。

対処方法:

gkadmin を終了して再起動してください。それでも問題が解決しない場合は、バグを報告してください。

SEAM 共通エラーメッセージ (A - M)

この節では、SEAM コマンド、SEAM デーモン、PAM フレームワーク、GSS インタフェース、NFS サービス、および Kerberos ライブラリに共通するエラーメッセージを、英語版メッセージのアルファベット順 (A - M) に示します。

major_error minor_error 名前をインポート中に gssapi エラー (major_error minor_error gssapi error importing name)

原因:

サービス名をインポートしているときに、エラーが発生しました。

対処方法:

サービス主体がホストのキータブファイル内に存在することを確認してください。

kadmin インタフェースを初期化中に、krb5 admin サーバーホスト名が無効です。(Bad krb5 admin server hostname while initializing kadmin interface)

原因:

krb5.conf ファイルの admin_server に、無効なホスト名が設定されています。

対処方法:

krb5.conf ファイルの admin_server 行に、マスター KDC の正しいホスト名を指定してください。

要求されたレルムの KDC に接続できません。(Cannot contact any KDC for requested realm)

原因:

要求されたレルムの KDC が応答しません。

対処方法:

1 つ以上の KDC (マスターまたはスレーブ) にアクセスできること、または krb5kdc デーモンが KDC 上で動作していることを確認してください。/etc/krb5/krb5.conf ファイルに指定されている構成済みの KDC (kdc = kdc_name) を確認してください。

ホスト用のレルムを決定できません。(Cannot determine realm for host)

原因:

Kerberos がホストのレルム名を判断できません。

対処方法:

デフォルトのレルム名を指定するか、Kerberos 構成ファイル (krb5.conf) にドメイン名の割り当てを設定してください。

要求されたレルムの KDC が見つかりません。(Cannot find KDC for requested realm)

原因:

要求されたレルムに KDC が見つかりません。

対処方法:

Kerberos 構成ファイル (krb5.conf) の realm セクションに KDC が指定されていることを確認してください。

レルム realm_name を初期化できません。(cannot initialize realm realm_name)

原因:

KDC に stash ファイルが存在しない可能性があります。

対処方法:

KDC に stash ファイルが存在することを確認してください。存在しない場合は、kdb5_util コマンドを使用して stash ファイルを作成し、再度 krb5kdc コマンドを実行します。krb5kdc を起動するには、/etc/init.d/kdc スクリプトを実行するのが最も簡単です。

要求されたレルムの KDC を解決できません。(Cannot resolve KDC for requested realm)

原因:

Kerberos がレルムの KDC を判断できません。

対処方法:

Kerberos 構成ファイル (krb5.conf) の realm セクションに KDC が指定されていることを確認してください。

パスワードは再利用できません。(Cannot reuse password)

原因:

入力したパスワードは、以前にこの主体によって使用されています。

対処方法:

以前に使用されたことのないパスワードを選択してください。KDC データベースに主体ごとに保持されているパスワード番号は、選択しないでください。このポリシーは、主体のポリシーによって適用されます。

転送された資格を取得できません。(Can't get forwarded credentials)

原因:

資格の転送ができません。

対処方法:

この主体に転送可能な資格を設定してください。

Kerberos 構成ファイルを開けません / 見つかりません。(Can't open/find Kerberos configuration file)

原因:

Kerberos 構成ファイル (krb5.conf) を使用できません。

対処方法:

krb5.conf ファイルが、正しい場所に配置されていることを確認してください。また、このファイルに正しいアクセス権が与えられていることを確認してください。このファイルに対する書き込み権は root、読み込み権はすべてのユーザーに与える必要があります。

初期チケット要求でクライアント / サーバーレルムが一致していません。(Client/server realm mismatch in initial ticket request)

原因:

初期チケット要求で、クライアントとサーバーのレルムが一致していません。

対処方法:

通信しているサーバーがクライアントと同じレルムに配置されていること、またはレルム構成が正しいことを確認してください。

クライアントまたはサーバーの鍵が null です。(Client or server has a null key)

原因:

クライアントまたはサーバーの鍵が空です。

対処方法:

kadmin の cpw コマンドを使用して、主体の鍵の値を入力してください。

kadmin インタフェースを初期化中に、サーバーとの通信の失敗です。(Communication failure with server while initializing kadmin interface)

原因:

管理サーバーとして入力したホスト (マスター KDC ) 上で、kadmind デーモンが動作していません。

対処方法:

マスター KDC に正しいホスト名が指定されていることを確認してください。ホスト名が正しい場合は、指定したマスター KDC 上で kadmind が動作していることを確認してください。

資格キャッシュファイルのアクセス権が正しくありません。(Credentials cache file permissions incorrect)

原因:

資格キャッシュ (/tmp/krb5cc_uid) に対する読み取り権または書き込み権が適切ではありません。

対処方法:

資格キャッシュに対する読み取り権および書き込み権があることを確認してください。

資格キャッシュ入出力操作が失敗しました。XXX (Credentials cache I/O operation failed XXX)

原因:

システムの資格キャッシュ (/tmp/krb5cc_ uid) に書き込むときに、Kerberos で問題が発生しました。

対処方法:

資格キャッシュが削除されていないことを確認し、df コマンドを使用してデバイスの空き領域を確認してください。

復号化で整合性チェックが失敗しました。(Decrypt integrity check failed)

原因:

チケットが無効である可能性があります。

対処方法:

資格が有効であることを確認してください。kdestroy を使用してチケットを破棄し、kinit を使用して新しいチケットを作成してください。
対象ホストのキータブファイルに対して、正しいバージョンのサービス鍵が割り当てられていることを確認してください。kadmin を使用して、Kerberos データベースのサービス主体 (host/ FQDN_hostname など) の鍵バージョン番号を表示します。対象ホスト上で klist -k を使用して、鍵バージョン番号がその番号であることを確認します。

df: ファイルシステムを statvfs できません: 引数が正しくありません。(df: cannot statvfs filesystem: Invalid argument)

原因:

適切な root 資格がないため、df コマンドを実行しても、現在マウントされている Kerberos NFS ファイルシステムにアクセスできません。マウントされている Kerberos ファイルシステムの資格を破棄しても、ファイルシステムは自動的にマウント解除されません。

対処方法:

Kerberos ファイルシステムにアクセスするには、新しい root 資格を作成する必要があります。この Kerberos ファイルシステムにアクセスする必要がない場合は、ファイルのマウントを解除してください。

資格キャッシュを取得できませんでした。(failed to obtain credentials cache)

原因:

kadmin の初期化中に、kadmin が admin 主体の資格を取得しようとしましたが、失敗しました。

対処方法:

kadmin を実行したときに、正しい主体とパスワードを使用したことを確認してください。

この実装ではフィールドが長すぎます。(Field is too long for this implementation)

原因:

Kerberos アプリケーションから送信されたメッセージのサイズが長すぎます。Kerberos が処理できる最大メッセージ長は、65,535 バイトです。また、Kerberos から送信されるプロトコルメッセージの各フィールドにも制限があります。

対処方法:

Kerberos アプリケーションから送信されたメッセージサイズが有効範囲であることを確認してください。

GSS-API (または Kerberos) エラー (GSS-API (or Kerberos) error)

原因:

このメッセージは、汎用 GSS-API または Kerberos のエラーメッセージで、いくつかの問題の組み合わせによって発生した可能性があります。

対処方法:

/etc/krb5/kdc.log ファイルを確認して、このエラーが発生したときに詳細な GSS-API エラーメッセージが記録されているかどうかを確認してください。

ホスト名を展開できません。(Hostname cannot be canonicalized)

原因:

Kerberos がホスト名を完全指定できません。

対処方法:

このホスト名が DNS に定義され、ホスト名とアドレス間の双方向の割り当てについて整合性を確認してください。

レルム間のチケットが無効です。(Illegal cross-realm ticket)

原因:

送信されたチケットのレルム間関係が正しくありません。レルム間に正しい信頼関係が設定されていない可能性があります。

対処方法:

使用しているレルム間の信頼関係が正しいことを確認してください。

Kerberos 構成ファイルのフォーマットが不適切です。(Improper format of Kerberos configuration file)

原因:

Kerberos 構成ファイル (krb5.conf) に無効なエントリがあります。

対処方法:

krb5.conf ファイル内のすべての関係式に、“=” 記号と値が使用されていることを確認してください。また、各下位セクションがカッコで囲まれていることも確認してください。

メッセージのチェックサムのタイプが不適切です。(Inappropriate type of checksum in message)

原因:

このメッセージに無効なチェックサムタイプが含まれています。

対処方法:

krb5.conf および kdc.conf ファイルに指定されているチェックサムタイプが有効であることを確認してください。

ネットアドレスが間違っています。(Incorrect net address)

原因:

ネットワークアドレスが一致しません。転送されたチケット内のネットワークアドレスが、チケットが処理されたときのネットワークアドレスと一致しません。このメッセージは、チケットの転送時に発生します。

対処方法:

ネットワークアドレスが正しいことを確認してください。kdestroy を使用してチケットを破棄し、kinit を使用して新しいチケットを作成します。

ファイルロックモードのフラグが無効です。(Invalid flag for file lock mode)

原因:

Kerberos の内部エラーが発生しました。

対処方法:

バグを報告してください。

符号化に対し無効なメッセージタイプが指定されました。(Invalid message type specified for encoding)

原因:

Kerberos アプリケーションから送信されたメッセージ形式を、Kerberos が認識できません。

対処方法:

使用するサイトまたはベンダーで開発した Kerberos アプリケーションを使用している場合は、Kerberos が正しく使用されていることを確認してください。

文字クラス数が正しくありません。(Invalid number of character classes)

原因:

主体に入力したパスワードに、主体のポリシーによって適用された数のパスワードクラスが含まれていません。

対処方法:

ポリシーに指定されている最小パスワードクラス数を使用して、パスワードを入力してください。

KADM エラー: メモリー割り当ての失敗です。(KADM err: Memory allocation failure)

原因:

kadmin の実行に必要なメモリーが不足しています。

対処方法:

メモリーを解放してから、kadmin を再実行してください。

KDC は要求したオプションを処理できません。(KDC can't fulfill requested option)

原因:

要求されたオプションを KDC が許可しませんでした。遅延または転送可能オプションが要求されましたが、KDC が許可しませんでした。または、TGT の更新が要求されましたが、更新可能な TGT が存在しない可能性があります。

対処方法:

KDC が許可しないオプションまたは使用できない種類のチケットを要求していないかどうかを確認してください。

KDC ポリシーは要求を拒否します。(KDC policy rejects request)

原因:

KDC ポリシーが要求を許可しませんでした。たとえば、KDC に対する要求に IP アドレスが含まれていなかったり、要求された転送を KDC が許可しなかった可能性があります。

対処方法:

正しいオプションを指定して kinit を実行していることを確認してください。必要に応じて、主体に関連付けられたポリシーを変更するか、要求が許可されるように主体の属性を変更します。ポリシーまたは主体を変更するには、kadmin を使用します。

KDC 応答は予期したものと一致しませんでした。(KDC reply did not match expectations)

原因:

KDC の応答に予期した主体名が含まれていないか、応答内のその他の値が正しくありません。

対処方法:

通信先の KDC が RFC1510 に準拠していること、送信している要求が Kerberos V5 要求であること、または KDC が有効であることを確認してください。

鍵テーブルエントリが見つかりません。(Key table entry not found)

原因:

ネットワークアプリケーションサーバーのキータブファイルに、サービス主体のエントリがありません。

対処方法:

サーバーのキータブファイルに適切なサービス主体を追加して、Kerberos サービスを提供できるようにしてください。

鍵テーブルのプリンシパルの鍵バージョン番号が正しくありません。(Key version number for principal in key table is incorrect)

原因:

キータブファイルと Kerberos データベース内の主体の鍵バージョンが異なります。サービスの鍵が変更されたか、旧サービスチケットを使用している可能性があります。

対処方法:

kadmin などによってサービスの鍵が変更されている場合は、新しい鍵を抽出して、サービスが動作しているホストのキータブファイルに格納する必要があります。

または、旧サービスチケットを使用しているため、鍵が古い可能性があります。kdestroy コマンドを実行し、次に kinit コマンドを再度実行してください。

login: load_modules: /usr/lib/security/pam_krb5.so.1 モジュールを開けません。(login: load_modules: can not open module /usr/lib/security/pam_krb5.so.1)

原因:

Kerberos PAM モジュールが存在しないか、有効な実行可能バイナリではありません。

対処方法:

Kerberos PAM モジュールが /usr/lib/security ディレクトリに存在し、有効な実行可能バイナリであることを確認してください。また、/etc/pam.conf ファイルに pam_krb5.so.1 への正しいパスが指定されていることも確認してください。

krb5_get_in_tkt 内部でループが検出されました。(Looping detected inside krb5_get_in_tkt)

原因:

Kerberos が初期チケットを複数回取得しようとしましたが、失敗しました。

対処方法:

認証要求に対して 1 つ以上の KDC が応答していることを確認してください。

マスター鍵がデータベースと一致しません。(Master key does not match database）

原因:

読み込まれたデータベースのダンプが、マスター鍵 (/var/krb5/.k5. REALM に配置されている) を含むデータベースから作成されませんでした。

対処方法:

読み込まれたデータベースダンプ内のマスター鍵が、 /var/krb5/.k5.REALM に配置されているマスター鍵と一致していることを確認してください。

一致する資格が見つかりません。(Matching credential not found)

原因:

要求に一致する資格が見つかりませんでした。資格キャッシュで使用できない資格を要求しています。

対処方法:

kdestroy を使用してチケットを破棄し、kinit を使用して新しいチケットを作成してください。

メッセージの順序が違います。(Message out of order)

原因:

順次送信されたメッセージが順不同で着信しました。一部のメッセージが転送中に失われました。

対処方法:

Kerberos セッションを再度初期化してください。

メッセージストリームが変更されました。(Message stream modified)

原因:

計算されたチェックサムとメッセージのチェックサムが一致しませんでした。転送中のメッセージが変更された可能性があります。セキュリティ違反が発生している可能性があります。

対処方法:

メッセージがネットワーク経由で正しく送信されていることを確認してください。このメッセージが送信中に改変された可能性もあるため、 kdestroy を使用してチケットを破棄し、使用している Kerberos サービスを再度初期化してください。

SEAM 共通エラーメッセージ (N - Z)

この節では、SEAM コマンド、SEAM デーモン、PAM フレームワーク、GSS インタフェース、NFS サービス、および Kerberos ライブラリに共通するエラーメッセージを、英語版メッセージのアルファベット順 (N - Z) に示します。

資格キャッシュファイルが見つかりません。(No credentials cache file found)

原因:

Kerberos が資格キャッシュ (/tmp/krb5cc_uid) を見つけることができません。

対処方法:

資格ファイルが存在し、読み込み可能であることを確認してください。存在しない場合は、kinit を再度実行します。

操作には “privilege” 特権が必要です。(Operation requires “privilege” privilege)

原因:

使用された admin 主体に対して、kadm5.acl ファイルに設定されている適切な特権が割り当てられていません。

対処方法:

適切な特権を持つ主体を使用してください。または、kadm5.acl ファイルを変更して、使用した主体に適切な特権を割り当てます。通常は、名前の一部に /admin が含まれる主体には、適切な特権が割り当てられています。

PAM-KRB5: Kerberos V5 認証に失敗しました: パスワードが正しくありません。(PAM-KRB5: Kerberos V5 authentication failed: password incorrect)

原因:

UNIX パスワードと Kerberos パスワードが一致していません。ほとんどの Kerberos 以外のコマンド (login など) では、PAM を介して Kerberos に自動的に認証されるように、UNIX パスワードに指定したパスワードが使用されます。パスワードが異なる場合、Kerberos 認証は失敗します。

対処方法:

パスワードを要求されたら、Kerberos パスワードを入力します。

パスワードはパスワード辞書にあります。(Password is in the password dictionary)

原因:

入力したパスワードがパスワードディレクトリにすでに存在し、使用されています。選択したパスワードが適切ではありません。

対処方法:

パスワードクラスを組み合わせたパスワードを選択してください。

リプレイキャッシュコードでアクセス権がありません。(Permission denied in replay cache code)

原因:

システムの再実行キャッシュを開けませんでした。このサーバーは、現在のユーザー ID と異なるユーザー ID で最初に実行された可能性があります。

対処方法:

再実行キャッシュに適切なアクセス権が割り当てられていることを確認してください。再実行キャッシュは、Kerberos サーバーアプリケーションが動作するホストに格納されます (/usr/tmp/rc_ service_name)。現在の再実行キャッシュのアクセス権を変更する代わりに、再実行キャッシュを削除してから、Kerberos サーバーアプリケーションを別のユーザー ID で実行することもできます。

プロトコルバージョンが一致していません。(Protocol version mismatch)

原因:

Kerberos V4 要求が KDC に送信された可能性があります。SEAM では、Kerberos V5 プロトコルだけがサポートされます。

対処方法:

アプリケーションが Kerberos V5 プロトコルを使用していることを確認してください。

要求は再送です。(Request is a replay)

原因:

この要求は、すでにこのサーバーに送信され、処理が完了しています。チケットが盗まれた可能性があり、ほかのユーザーがチケットを再使用しようとしています。

対処方法:

しばらくしてから要求を再発行してください。

要求したプリンシパルとチケットは一致しません。(Requested principal and ticket don't match)

原因:

接続するサービス主体と使用するサービスチケットが一致しません。

対処方法:

DNS が適切に機能することを確認してください。別のベンダーのソフトウェアを使用する場合は、そのソフトウェアが主体名を正しく使用していることを確認します。

要求したプロトコルバージョンはサポートされていません。(Requested protocol version not supported)

原因:

Kerberos V4 要求が KDC に送信された可能性があります。SEAM では、Kerberos V5 プロトコルだけがサポートされます。

対処方法:

アプリケーションが Kerberos V5 プロトコルを使用していることを確認してください。

kadmin インタフェースを初期化中に、必須のパラメータが krb5.conf にありません。(Required parameters in krb5.conf missing while initializing kadmin interface)

原因:

krb5.conf ファイル内のパラメータ (admin_server パラメータなど) が存在しません。

対処方法:

存在しないパラメータを判断して、krb5.conf ファイルに追加します。

サーバーが認証を拒否しました (sendauth 交換で)。(Server rejected authentication (during sendauth exchange))

原因:

通信しようとしているサーバーが認証を拒否しました。ほとんどの場合、このエラーは Kerberos データベースを伝播するときに発生します。kpropd.acl ファイル、DNS、またはキータブファイルに問題が発生している可能性があります。

対処方法:

kprop 以外のアプリケーションを実行しているときにこのエラーが発生した場合は、サーバーのキータブファルが正しいかどうかを調査してください。

GSS サービス nfs@<host> の設定が失敗しました。NFS サービス資格を確認してください。(Set gss service nfs@<host> failed. Check nfs service credential)

原因:

このメッセージは、share コマンドが「無効な引数」メッセージを表示して失敗したあとに、syslog により生成されます。キータブファイルが存在しないか、キータブファイル内に NFS サービス主体が存在しない可能性があります。

対処方法:

問題を特定するために、 klist -k を実行してキータブファイルが存在することを確認し、キータブファイル内にホストの NFS サービス主体が存在することを確認してください。

チケットはわれわれのものではありません。(The ticket isn't for us) チケット / オーセンティケータが一致しません。(Ticket/authenticator don't match)

原因:

チケットとオーセンティケータ (authenticator) が一致しません。要求内の主体名が、サービス主体の名前と一致していない可能性があります。送信されたチケットの主体が FQDN 名で、サービスが予期した主体が FQDN 以外の名前の場合 (またはこの逆の場合) に、この問題が発生します。

対処方法:

チケットの有効期限が切れました。(Ticket expired)

原因:

チケットが期限切れになっています。

対処方法:

kdestroy を使用してチケットを破棄し、kinit を使用して新しいチケットを作成してください。

チケットには遅延処理の資格がありません。(Ticket is ineligible for postdating)

原因:

この主体は、チケットの遅延を許可していません。

対処方法:

kadmin を使用して主体を変更し、遅延を許可してください。

チケットはまだ有効ではありません。(Ticket not yet valid)

原因:

遅延チケットはまだ有効でありません。

対処方法:

正しい日付で新しいチケットを作成するか、現在のチケットが有効になるまで待ちます。

不完全な入力ファイルを検出しました。(Truncated input file detected)

原因:

操作に使用されたデータベースダンプファイルが完全ではありません。

対処方法:

ダンプファイルを作成し直すか、別のデータベースダンプファイルを使用します。

要求したプリンシパルは正しくありません。(Wrong principal in request)

原因:

チケットの主体名が無効です。DNS または FQDN の問題が発生している可能性があります。

対処方法:

サービスの主体とチケットの主体が一致していることを確認してください。

SEAM の障害追跡

この節では、SEAM ソフトウェアの障害追跡について説明します。

Kerberos NFS ファイルシステムのマウントの問題

Kerberos NFS ファイルシステムのマウントに失敗した場合は、NFS サーバーに /var/tmp/rc_nfs ファイルが存在することを確認してください。ファイルシステムの所有者が root でない場合は、削除してから再度マウントします。
Kerberos NFS ファイルシステムへのアクセスに問題がある場合は、使用するシステムと NFS サーバーの inetd.conf ファイル内に gssd のエントリが存在することを確認してください。
Kerberos NFS ファイルシステムにアクセスしようとしたときに invalid argument または bad directory のエラーメッセージが表示された場合は、NFS ファイルシステムをマウントするときに完全指定形式の DNS 名を使用していない可能性があります。マウントされているホストが、サーバーのキータブファイル内のサービス主体名に含まれるホスト名と一致していません。

また、複数の Ethernet インタフェースを実装したサーバーに DNS を設定するときに、ホスト単位に複数のアドレスレコードを割り当てずに、インタフェース単位に名前を割り当てた場合にも、この問題が発生します。SEAM の場合は、次のようにホスト単位に複数のアドレスレコードを設定する必要があります。 [Ken Hornstein, “Kerberos FAQ,” [http://www.nrl.navy.mil/CCS/people/kenh/kerberos-faq.html], accessed 11 December 1998.] :
```
my.host.name.   A       1.2.3.4
                A       1.2.4.4
                A       1.2.5.4

my-en0.host.name.       A       1.2.3.4
my-en1.host.name.       A       1.2.4.4
my-en2.host.name.       A       1.2.5.4

4.3.2.1         PTR     my.host.name.
4.4.2.1         PTR     my.host.name.
4.5.2.1         PTR     my.host.name.
```

この例の設定では、インタフェースごとに 1 つの参照が割り当てられます。また、サーバーのキータブファイル内で、3 つのサービス主体の代わりに、1 つのサービス主体を使用できます。

`root` の認証の問題

使用するシステムのスーパーユーザーになるときの認証に失敗し、ホストのキータブファイルに root 主体がすでに追加されている場合は、2 つの問題を確認する必要があります。まず、キータブファイル内の root 主体が、そのインスタンスとして完全指定形式名であることを確認します。完全指定形式名の場合は、/etc/resolv.conf ファイルを確認して、システムが DNS クライアントとして正しく設定されていることを確認してください。

第 17 章主体とポリシーの管理 (手順)

この章では、主体とそれに関連するポリシーを管理する手順について説明します。また、ホストのキータブファイルの管理方法についても説明します。

この章は、主体とポリシーを管理する必要のあるユーザーを対象にしています。主体とポリシーを計画するときの考慮事項など、主体とポリシーについて理解している必要があります。第 13 章「SEAM について」および第 14 章「SEAM の計画」を参照してください。

この章で説明する情報は次のとおりです。

主体とポリシーの管理方法

マスター KDC の Kerberos データベースには、使用するレルムの Kerberos 主体、そのパスワード、ポリシーなどの管理情報がすべて含まれています。主体を作成または削除したり、主体の属性を変更したりするには、kadmin または gkadmin コマンドを使用します。

kadmin コマンドには、対話型のコマンド行インタフェースが用意されています。このインタフェースを使用して、Kerberos 主体、ポリシー、およびキータブファイルを管理することができます。kadmin コマンドには、次の 2 つの種類があります。

kadmin - Kerberos 認証を使用して、ネットワーク上の任意の場所から安全に操作できる
kadmin.local - マスター KDC 上で直接実行する必要がある

Kerberos を使用してユーザーを認証する点を除いて、2 つの kadmin の機能は同じです。kadmin に必要なデータベースを設定するときは、kadmin.local を使用します。

SEAM には、SEAM 管理ツール (gkadmin) も用意されています。このツールは対話型のグラフィカルユーザーインタフェース (GUI) で、基本的に kadmin コマンドと同じ機能を持ちます。詳細は、SEAM 管理ツールを参照してください。

SEAM 管理ツール

SEAM 管理ツールは、対話型グラフィカルユーザーインタフェース (GUI) で、Kerberos 主体とポリシーを管理することができます。このツールは、kadmin コマンドと同じ機能を持ちます。ただし、キータブファイルの管理はサポートしません。キータブファイルを管理するには、kadmin コマンドを使用する必要があります (キータブファイルの管理を参照)。

kadmin コマンドと同様に、SEAM ツールは、Kerberos 認証と暗号化された RPC を使用して、ネットワーク上の任意の場所から安全に操作することができます。SEAM ツールでは、次の操作を行うことができます。

デフォルト値または既存の主体をベースに新しい主体を作成する
既存のポリシーをベースに新しいポリシーを作成する
主体のコメントを追加する
新しい主体を作成するときのデフォルト値を設定する
ツールを終了しないで別の主体としてログインする
主体一覧とポリシー一覧を印刷または保存する
主体一覧とポリシー一覧を表示および検索する

SEAM ツールでは、コンテキストヘルプと一般的なオンラインヘルプも利用できます。

SEAM ツールを使用して実行できる操作について、次の作業マップで説明します。

また、SEAM ツールで指定または表示できる主体属性とポリシー属性については、SEAM ツールパネルの説明を参照してください。

SEAM ツールに対応するコマンド行

この節では、SEAM ツールと同じ機能を提供する kadmin コマンドを示します。これらのコマンドは、X Window System で実行しなくても使用できます。この章のほとんどの手順では、SEAM ツールを使用します。ただし、多くの手順では、対応するコマンド行の使用例も挙げています。

表 17–1 SEAM ツールに対応するコマンド行


SEAM ツールの手順	対応する `kadmin` コマンド
主体の一覧の表示	`list_principals` または `get_principals`
主体の属性の表示	`get_principal`
新しい主体の作成	`add_principal`
主体の複製	対応するコマンド行なし
主体の変更	`modify_principal` または `change_password`
主体の削除	`delete_principal`
新しい主体を作成するときのデフォルトの設定	対応するコマンド行なし
ポリシーの一覧の表示	`list_policies` または `get_policies`
ポリシーの属性の表示	`get_policy`
新しいポリシーの作成	`add_policy`
ポリシーの複製	対応するコマンド行なし
ポリシーの変更	`modify_policy`
ポリシーの削除	`delete_policy`

SEAM ツールによって変更されるファイル

SEAM ツールが変更するファイルは、$HOME/.gkadmin ファイルだけです。このファイルには、新しい主体を作成するときのデフォルト値が含まれます。このファイルを更新するには、「Edit」メニューから「Properties」を選択します。

SEAM ツールの印刷機能とオンラインヘルプ機能

SEAM ツールには、印刷機能とオンラインヘルプ機能が用意されています。「Print」メニューから、次の要素をプリンタまたはファイルに送信できます。

指定したマスター KDC で使用できる主体の一覧
指定したマスター KDC で使用できるポリシーの一覧
現在選択されている主体または読み込まれている主体
現在選択されているポリシーまたは読み込まれているポリシー

「Help」メニューから、コンテキストヘルプと通常のヘルプを使用できます。「Help」メニューから「Context-Sensitive Help」を選択すると、「Context-Sensitive Help」ウィンドウが表示され、ツールがヘルプモードに切り替わります。ヘルプモードのウィンドウで、任意のフィールド、ラベル、またはボタンをクリックすると、「Help」ウィンドウにその項目のヘルプが表示されます。ツールの通常モードに戻るには、「Help」ウィンドウで「Dismiss」をクリックします。

「Help Contents」を選択すると、HTML ブラウザが開き、この章で説明している概要や操作情報が表示されます。

SEAM ツールで大規模な一覧を使用する

登録した主体とポリシーが増加するにつれて、SEAM ツールが主体とポリシーを読み込んでそれらの一覧を表示する時間が長くなります。このため、ツールによる作業効率が低下します。この問題には、いくつかの対応方法があります。

まず、一覧を読み込む時間を完全になくすために、SEAM ツールに一覧を読み込まないようにします。この方法を設定するには、「Edit」メニューから「Properties」を選択し、「Show Lists」フィールドのチェックマークをはずします。一覧を読み込まない場合、一覧は表示されないため、一覧を使用して主体またはポリシーを選択できなくなります。代わりに、表示された新しい「Name」フィールドに主体またはポリシー名を入力し、その主体またはポリシーに適用する操作を選択する必要があります。名前を入力する操作は、一覧から項目を選択する操作と同じ効果を持ちます。

大規模な一覧を使用するときは、キャッシュを利用することもできます。SEAM ツールのデフォルトの動作として、一定量の一覧がキャッシュに格納されるように設定されています。SEAM ツールは、最初に一覧をキャッシュに読み込む必要がありますが、そのあとは一覧を再度読み込まずにキャッシュを使用できます。この方法では、サーバーから時間をかけて何回も一覧を読み込む必要がありません。

一覧がキャッシュに格納されるように設定するには、「Edit」メニューから「Properties」を選択します。キャッシュの設定には、次の 2 つの方法があります。一覧をキャッシュに永続的に格納するか、制限時間を指定します。制限時間を指定した場合は、その時間が経過すると、ツールはサーバーの一覧をキャッシュに再度読み込みます。

一覧をキャッシュに格納しても、一覧から主体とポリシーを選択することができます。このため、一覧を読み込まない最初の方法と異なり、SEAM ツールの利用には影響しません。また、キャッシュを利用した場合でも、ほかの主体とポリシーの変更を確認できなくなることがあります。ただし、使用している主体とポリシーを変更したときは最新の一覧が表示されます。主体とポリシーを変更すると、サーバーとキャッシュの一覧が更新されるためです。キャッシュを更新して、ほかの主体とポリシーの変更を確認し、最新の一覧を取得するには、任意のタイミングで「Refresh」メニューを使用します。サーバーから一覧が読み込まれ、キャッシュを更新することができます。

SEAM ツールを起動する方法

gkadmin コマンドを使用して SEAM ツールを起動します。
$ /usr/sbin/gkadmin
「SEAM Administration Login」ウィンドウが表示されます。

デフォルト値を使用しない場合は、新しいデフォルト値を指定します。

ウィンドウには、デフォルト値が自動的に表示されます。デフォルトの主体名は、USER 環境変数の現在の ID に /admin が付加されて作成されます (username/admin)。デフォルトの「Realm」フィールドおよび「Master KDC」フィールドは、/etc/krb5/krb5.conf ファイルから選択されます。デフォルト値を再度取得する場合は、「Start Over」をクリックします。

注 –
各「Principal Name」が実行できる管理操作は、Kerberos ACL ファイルの /etc/krb5/kadm5.acl で規定されます。権限の制限については、Kerberos 管理権限を制限して SEAM ツールを使用するを参照してください。

指定した主体名のパスワードを入力します。

「了解 (OK)」をクリックします。

次のウィンドウが表示されます。

主体の管理

この節では、SEAM ツールを使用して主体を管理する手順について説明します。また、対応するコマンド行がある場合は、その例も示します。

主体の管理 (作業マップ)

作業	説明	参照先
主体の一覧の表示	「Principals」タブをクリックして、主体の一覧を表示する	主体の一覧を表示する方法
主体の属性の表示	「Principal List」の「Principal」を選択し、「Modify」ボタンをクリックして、主体の属性を表示する	主体の属性を表示する方法
新しい主体の作成	「Principal List」パネルの「Create New」ボタンをクリックして、新しい主体を作成する	新しい主体を作成する方法
主体の複製	「Principal List」から複製する主体を選択し、「Duplicate」ボタンをクリックして、主体を複製する	主体を複製する方法
主体の変更	「Principal List」から変更する主体を選択し、「Modify」ボタンをクリックして、主体を変更する主体名は変更できない。主体名を変更するときは、主体を複製し、新しい名前を指定して保存してから、古い主体を削除する必要がある	主体を変更する方法
主体の削除	「Principal List」から削除する主体を選択し、「Delete」ボタンをクリックして、主体を削除する	主体を削除する方法
新しい主体を作成するときのデフォルトの設定	「Edit」メニューから「Properties」を選択して、新しい主体を作成するときのデフォルトを設定する	新しい主体を作成するときのデフォルトを設定する方法
Kerberos 管理権限の変更 (`kadm5.acl` ファイル)	コマンド行のみ。 Kerberos 管理権限により、主体が Kerberos データベースに対して実行できる操作 (追加、変更など) が決定される。各主体の Kerberos 管理権限を変更するときは、`/etc/krb5/kadm5.acl` ファイルを編集する必要がある	Kerberos 管理権限を変更する方法

新しい主体の自動作成

SEAM ツールは簡単に使用できますが、新しい主体を自動作成することができません。10 個または 100 個などの新しい主体を短時間で作成する場合は、自動作成を利用すると便利です。Bourne シェルスクリプトで kadmin.local コマンドを使用すると、主体を自動作成できます。

次のシェルスクリプト行は、新しい主体を自動作成する方法の例を示します。

sed -e 's/^\(.*\)$/ank +needchange -pw \1 \1/' < princnames |
        time /usr/sbin/kadmin.local> /dev/null

この例は、見やすいように 2 行に分割しています。このスクリプトは、princnames というファイルを読み込んで、そこに含まれている主体名とそのパスワードを Kerberos データベースに追加します。princnames ファイルをあらかじめ作成する必要があります。このファイルの各行には、主体とそのパスワードを 1 つ以上の空白で区切って指定します。主体に +needchange オプションを指定すると、ユーザーがその主体を使用して初めてログインしたときに、新しいパスワードを要求するプロンプトが表示されます。この方法を使用すると、princnames ファイル内のパスワードのセキュリティが向上します。

より複雑なスクリプトも作成できます。たとえば、ネームサービスの情報を使用して、主体名に対応するユーザー名の一覧を取得できます。必要な作業とその方法は、使用環境要件とスクリプト使用技術によって決まります。

主体の一覧を表示する方法

対応するコマンド行の例は、この手順のあとに示します。

必要に応じて、SEAM ツールを起動します。

詳細は、SEAM ツールを起動する方法を参照してください。

「Principals」タブをクリックします。

主体の一覧が表示されます。

特定の主体を表示するか、主体の部分リストを表示します。

「Filter」フィールドにフィルタ文字列を入力して、Return キーを押します。フィルタが正常終了すると、フィルタに一致する主体の一覧が表示されます。

フィルタ文字列は、1 文字以上の文字列である必要があります。フィルタメカニズムでは大文字と小文字が区別されるため、大文字と小文字を正しく指定する必要があります。たとえば、フィルタ文字列に ge と入力すると、主体名に文字列 ge を含む主体 (george、edge など) だけが表示されます。

すべての主体を表示するには、「Clear Filter」をクリックします。

例 — 主体の一覧の表示 (コマンド行)

次の例では、kadmin の list_principals コマンドを使用して、 test* と一致するすべての主体を表示します。list_principals コマンドでは、ワイルドカードを使用できます。

kadmin: list_principals test*
test1@EXAMPLE.COM
test2@EXAMPLE.COM
kadmin: quit

主体の属性を表示する方法

対応するコマンド行の例は、この手順のあとに示します。

必要に応じて、SEAM ツールを起動します。

詳細は、SEAM ツールを起動する方法を参照してください。

「Principals」タブをクリックします。

表示する主体を一覧から選択して、「Modify」をクリックします。

「Principal Basic」パネルが表示され、主体の属性の一部が示されます。

「Next」をクリックして、主体のすべての属性を表示します。

属性情報は、3 つのウィンドウに表示されます。「Help」メニューから「Context-Sensitive Help」を選択すると、各ウィンドウの属性に関する情報が表示されます。主体のすべての属性の説明については、SEAM ツールパネルの説明を参照してください。

表示を終了する場合は、「Cancel」をクリックします。

例 — 主体の属性の表示

次の例は、jdb/admin 主体を表示したときの最初のウィンドウです。

「SEAM Administration Tool」ウィンドウに、jdb/admin 主体のアカウントデータが表示されています。アカウントの期限とコメントが含まれています。

例 — 主体の属性の表示 (コマンド行)

次の例では、kadmin の get_principal コマンドを使用して、jdb/admin 主体の属性を表示します。

kadmin: getprinc jdb/admin
Principal: jdb/admin@EXAMPLE.COM
Expiration date: Fri Aug 25 17:19:05 PDT 2000
Last password change: [never]
Password expiration date: Wed Apr 14 11:53:10 PDT 1999
Maximum ticket life: 1 day 16:00:00
Maximum renewable life: 1 day 16:00:00
Last modified: Thu Jan 14 11:54:09 PST 1999 (admin/admin@EXAMPLE.COM)
Last successful authentication: [never]
Last failed authentication: [never]
Failed password attempts: 0
Number of keys: 1
Key: vno 1, DES cbc mode with CRC-32, no salt
Attributes: REQUIRES_HW_AUTH
Policy: [none]
kadmin: quit

新しい主体を作成する方法

対応するコマンド行の例は、この手順のあとに示します。

必要に応じて、SEAM ツールを起動します。

詳細は、SEAM ツールを起動する方法を参照してください。

注 –
新しい主体を作成するときに、新しいポリシーが必要な場合は、新しいポリシーを作成してから新しい主体を作成する必要があります。新しいポリシーを作成する方法を参照してください。

「Principals」タブをクリックします。

「New」をクリックします。

「Principal Basics」パネルが表示され、主体の属性の一部が示されます。

主体名とパスワードを指定します。

主体名とパスワードは必須です。

主体の属性に値を指定します。「Next」をクリックして、属性の値を必要に応じて指定します。

属性情報は、3 つのウィンドウに表示されます。「Help」メニューから「Context-Sensitive Help」を選択すると、各ウィンドウの属性に関する情報が表示されます。主体のすべての属性の説明については、SEAM ツールパネルの説明を参照してください。

主体を保存する場合は、「Save」をクリックします。または、最後のパネルで「Done」をクリックします。

必要に応じて、新しい主体の Kerberos 管理権限を /etc/krb5/kadm5.acl ファイルに設定します。

詳細は、Kerberos 管理権限を変更する方法を参照してください。

例 — 新しい主体の作成

次の例は、pak という新しい主体を作成するときの「Principal Basics」パネルです。ポリシーには、testuser が設定されています。

「SEAM Administration Tool」ウィンドウに、pak 主体のアカウントデータが表示されています。パスワード、アカウントの期限、「testuser」ポリシーなどです。

例 — 新しい主体の作成 (コマンド行)

次の例では、kadmin の add_principal コマンドを使用して、 pak という新しい主体を作成します。この主体のポリシーには、testuser が設定されています。

kadmin: add_principal -policy testuser pak
Enter password for principal "pak@EXAMPLE.COM": <パスワードを入力する>
Re-enter password for principal "pak@EXAMPLE.COM": <パスワードを再入力する>
Principal "pak@EXAMPLE.COM" created.
kadmin: quit

主体を複製する方法

この手順では、既存の主体の一部またはすべてを使用して、新しい主体を作成する方法について説明します。この手順に対応するコマンド行はありません。

必要に応じて、SEAM ツールを起動します。

詳細は、SEAM ツールを起動する方法を参照してください。

「Principals」タブをクリックします。

複製する主体を一覧から選択して、「Duplicate」をクリックします。

「Principal Basics」パネルが表示されます。選択した主体のすべての属性が複製されます。ただし、「Principal Name」と「Password」フィールドは複製されず、空で表示されます。

主体名とパスワードを指定します。

主体名とパスワードは必須です。選択した主体をそのまま複製するときは、「Save」をクリックして、手順 7 に進みます。

主体の属性に別の値を指定します。「Next」をクリックして、属性の値を必要に応じて指定します。

属性情報は、3 つのウィンドウに表示されます。「Help」メニューから「Context-Sensitive Help」を選択すると、各ウィンドウの属性に関する情報が表示されます。主体のすべての属性の説明については、SEAM ツールパネルの説明を参照してください。

主体を保存する場合は、「Save」をクリックします。または、最後のパネルで「Done」をクリックします。

必要に応じて、主体の Kerberos 管理権限を /etc/krb5/kadm5.acl ファイルに設定します。

詳細は、Kerberos 管理権限を変更する方法を参照してください。

主体を変更する方法

対応するコマンド行の例は、この手順のあとに示します。

必要に応じて、SEAM ツールを起動します。

詳細は、SEAM ツールを起動する方法を参照してください。

「Principals」タブをクリックします。

変更する主体を一覧から選択して、「Modify」をクリックします。

「Principal Basic」パネルが表示され、主体の属性の一部が示されます。

主体の属性を変更します。「Next」をクリックして、必要に応じて属性を変更します。

属性情報は、3 つのウィンドウに表示されます。「Help」メニューから「Context-Sensitive Help」を選択すると、各ウィンドウの属性に関する情報が表示されます。主体のすべての属性の説明については、SEAM ツールパネルの説明を参照してください。

注 –
主体名は変更できません。主体名を変更するときは、主体を複製し、新しい名前を指定して保存してから、古い主体を削除する必要があります。

主体を保存する場合は、「Save」をクリックします。または、最後のパネルで「Done」をクリックします。

/etc/krb5/kadm5.acl ファイルで、主体の Kerberos 管理権限を変更します。

詳細は、Kerberos 管理権限を変更する方法を参照してください。

例 — 主体のパスワードの変更 (コマンド行)

次の例では、kadmin の change_password コマンドを使用して、jdb 主体のパスワードを変更します。change_password コマンドでは、主体のパスワード履歴に存在するパスワードには変更できません。

kadmin: change_password jdb
Enter password for principal "jdb": <新しいパスワードを入力する>
Re-enter password for principal "jdb": <パスワードを再度入力する>
Password for "jdb@EXAMPLE.COM" changed.
kadmin: quit

主体のその他の属性を変更するには、kadmin の modify_principal コマンドを使用する必要があります。

主体を削除する方法

対応するコマンド行の例は、この手順のあとに示します。

必要に応じて、SEAM ツールを起動します。

詳細は、SEAM ツールを起動する方法を参照してください。

「Principals」タブをクリックします。

削除する主体を一覧から選択して、「Delete」をクリックします。

削除を確定すると、主体が削除されます。

Kerberos アクセス制御リスト (ACL) ファイル /etc/krb5/kadm5.acl から主体を削除します。

詳細は、Kerberos 管理権限を変更する方法を参照してください。

例 — 主体を削除する (コマンド行)

次の例では、kadminの delete_principal コマンドを使用して、jdb 主体を削除します。

kadmin: delete_principal pak
Are you sure you want to delete the principal "pak@EXAMPLE.COM"? (yes/no): yes
Principal "pak@EXAMPLE.COM" deleted.
Make sure that you have removed this principal from all ACLs before reusing.
kadmin: quit

新しい主体を作成するときのデフォルトを設定する方法

この手順に対応するコマンド行はありません。

必要に応じて、SEAM ツールを起動します。

詳細は、SEAM ツールを起動する方法を参照してください。

「Edit」メニューから「Properties」を選択します。

「Properties」ウィンドウが表示されます。

新しい主体を作成するときのデフォルトを選択します。

「Help」メニューから「Context-Sensitive Help」を選択すると、各ウィンドウの属性に関する情報が表示されます。

「Save」をクリックします。

Kerberos 管理権限を変更する方法

使用する環境には、多くのユーザー主体が登録されていると思われます。しかし、Kerberos データベースの管理者は通常、少数のユーザーだけに割り当てます。Kerberos データベースを管理する権限は、Kerberos アクセス制御リスト (ACL) ファイル (kadm5.acl) によって判断されます。kadm5.acl ファイルを使用すると、主体ごとに権限を設定できます。主体名にワイルドカード (*) を使用すると、複数の主体に権限を指定できます。

マスター KDC 上でスーパーユーザーになります。

/etc/krb5/kadm5.acl ファイルを編集します。

kadm5.acl ファイルのエントリは、次の書式で記述してください。

principal   privileges  [principal-target]

`principal`	権限を与える主体を指定する。主体名の任意の場所にワイルドカード () を使用できる。複数の主体グループに同じ権限を与えるときに使用する。たとえば、`admin` インスタンスを持つすべての主体を指定する場合は、 `/admin@realm` を使用する `admin` インスタンスは通常、個別の権限 (Kerberos データベースへの管理アクセス権など) を個別の Kerberos 主体に許可するときに使用する。たとえば、ユーザー `jdb` が、`jdb/admin` という管理目的の主体を持つとする。この場合、ユーザー `jdb` は、この権限を実際に使用するときにだけ、`jdb/admin` チケットを取得する
`privileges`	主体が実行できる操作または実行できない操作を指定する。このフィールドは、次に示す 1 つまたは複数の文字列 (またはその大文字) の組み合わせから構成される。大文字の指定、または指定なしは許可されない。小文字の指定は許可される
	`a`	主体またはポリシーの追加を許可する/しない
	`d`	主体またはポリシーの削除を許可する/しない
	`m`	主体またはポリシーの変更を許可する/しない
	`c`	主体のパスワードの変更を許可する/しない
	`i`	Kerberos データベースの照会を許可する/しない
	`l`	Kerberos データベース内の主体またはポリシーの一覧表示を許可する/しない
	`x` または `*`	すべての権限 (`admcil`) を許可する
`principal-target`	このフィールドに主体を指定すると、`principal` の操作が `principal_target` の場合にだけ、`privileges` が `principal` に適用される。主体名の任意の場所にワイルドカード (*) を使用できる。主体をグループ化するときに使用する

例 — Kerberos 管理権限の変更

kadm5.acl ファイル内の次のエントリは、EXAMPLE.COM レルム内で admin インスタンスを持つすべての主体に対して、Kerberos データベース上のすべての権限を与えます。

*/admin@EXAMPLE.COM *

kadm5.acl ファイル内の次のエントリは、jdb@EXAMPLE.COM 主体に対して、root インスタンスを持つすべての主体に関する追加、一覧表示、および照会の権限を与えます。

jdb@EXAMPLE.COM ali */root@EXAMPLE.COM

ポリシーの管理

この節では、SEAM ツールを使用してポリシーを管理する手順について説明します。また、対応するコマンド行がある場合は、その例も示します。

ポリシーの管理 (作業マップ)

作業	説明	参照先
ポリシーの一覧の表示	「Policies」タブをクリックして、ポリシーの一覧を表示する	ポリシーの一覧を表示する方法
ポリシーの属性の表示	「Policy List」からポリシーを選択し、「Modify」ボタンをクリックして、ポリシーの属性を表示する	ポリシーの属性を表示する方法
新しいポリシーの作成	「Policy List」パネルの「Create New」ボタンをクリックして、新しいポリシーを作成する	新しいポリシーを作成する方法
ポリシーの複製	複製するポリシーを「Policy List」ポリシーから選択し、「Duplicate」ボタンをクリックして、ポリシーを複製する	ポリシーを複製する方法
ポリシーの変更	変更するポリシーを「Policy List」ポリシーから選択し、「Modify」ボタンをクリックして、ポリシーを変更するポリシー名は変更できない。ポリシー名を変更するときは、ポリシーを複製し、新しい名前を指定して保存してから、古いポリシーを削除する必要がある	ポリシーを変更する方法
ポリシーの削除	削除するポリシーを「Policy List」ポリシーから選択し、「Delete」ボタンをクリックして、ポリシーを削除する	ポリシーを削除する方法

ポリシーの一覧を表示する方法

対応するコマンド行の例は、この手順のあとに示します。

必要に応じて、SEAM ツールを起動します。

詳細は、SEAM ツールを起動する方法を参照してください。

「Policies」タブをクリックします。

ポリシーの一覧が表示されます。

特定のポリシーを表示するか、ポリシーの部分リストを表示します。

「Filter」フィールドにフィルタ文字列を入力して、Return キーを押します。フィルタが正常終了すると、フィルタに一致するポリシーの一覧が表示されます。

フィルタ文字列は、1 文字以上の文字列である必要があります。フィルタメカニズムでは大文字と小文字が区別されるため、大文字と小文字を正しく指定する必要があります。たとえば、フィルタ文字列に ge と入力すると、ポリシー名に文字列 ge を含むポリシー (george、edge など) だけが表示されます。

すべてのポリシーを表示するには、「Clear Filter」をクリックします。

例 — ポリシーの一覧の表示 (コマンド行)

次の例では、kadmin の list_policies コマンドを使用して、*user* と一致するすべてのポリシーを表示します。list_policies コマンドでは、ワイルドカードを使用できます。

kadmin: list_policies *user*
testuser
enguser
kadmin: quit

ポリシーの属性を表示する方法

対応するコマンド行の例は、この手順のあとに示します。

必要に応じて、SEAM ツールを起動します。

詳細は、SEAM ツールを起動する方法を参照してください。

「Policies」タブをクリックします。

表示するポリシーを一覧から選択して、「Modify」をクリックします。

「Policy Details」パネルが表示されます。

表示を終了する場合は、「Cancel」をクリックします。

例 — ポリシーの属性の表示

次の例は、test ポリシーを表示したときの「Policy Details」パネルです。

「SEAM Administration Tool」ウィンドウに、「enguser」ポリシーの詳細が表示されています。「Save」「Previous」「Done」「Cancel」ボタンもあります。

例 — ポリシーの属性の表示 (コマンド行)

次の例では、kadmin の get_policy コマンドを使用して、enguser ポリシーの属性を表示します。

kadmin: get_policy enguser
Policy: enguser
Maximum password life: 2592000
Minimum password life: 0
Minimum password length: 8
Minimum number of password character classes: 2
Number of old keys kept: 3
Reference count: 0
kadmin: quit

参照数は、このポリシーを使用する主体の数です。

新しいポリシーを作成する方法

対応するコマンド行の例は、この手順のあとに示します。

必要に応じて、SEAM ツールを起動します。

詳細は、SEAM ツールを起動する方法を参照してください。

「Policies」タブをクリックします。

「New」をクリックします。

「Policy Details」パネルが表示されます。

「Policy Name」フィールドにポリシー名を指定します。

ポリシー名は必須です。

ポリシーの属性の値を指定します。

「Help」メニューから「Context-Sensitive Help」を選択すると、このウィンドウの属性に関する情報が表示されます。ポリシーのすべての属性の説明については、表 17–5 を参照してください。

「Save」をクリックしてポリシーを保存するか、「Done」をクリックします。

例 — 新しいポリシーの作成

次の例では、build11 という新しいポリシーを作成します。「Minimum Password Classes」は、3 に設定されています。

「SEAM Administration Tool」ウィンドウに、「build11」ポリシーの詳細が表示されています。「Save」「Previous」「Done」「Cancel」ボタンもあります。

例 — 新しいポリシーの作成 (コマンド行)

次の例では、kadminの add_policy コマンドを使用して、build11 ポリシーを作成します。このポリシーのパスワードには、3 種類以上の文字クラスが必要です。

$ kadmin
kadmin: add_policy -minclasses 3 build11
kadmin: quit

ポリシーを複製する方法

この手順では、既存のポリシーの一部またはすべてを使用して、新しいポリシーを作成する方法について説明します。この手順に対応するコマンド行はありません。

必要に応じて、SEAM ツールを起動します。

詳細は、SEAM ツールを起動する方法を参照してください。

「Policies」タブをクリックします。

複製するポリシーを一覧から選択して、「Duplicate」をクリックします。

「Policy Details」パネルが表示されます。選択したフィールドのすべての属性が複製されます。ただし、「Policy Name」フィールドは空で表示されます。

複製するポリシー名を「Policy Name」フィールドに指定します。

ポリシー名は必須です。選択したポリシーをそのまま複製するには、「Save」をクリックして手順 6 に進みます

ポリシーの属性に別の値を指定します。

「Help」メニューから「Context-Sensitive Help」を選択すると、このウィンドウの属性に関する情報が表示されます。ポリシーのすべての属性の説明については、表 17–5 を参照してください。

「Save」をクリックしてポリシーを保存するか、「Done」をクリックします。

ポリシーを変更する方法

対応するコマンド行の例は、この手順のあとに示します。

必要に応じて、SEAM ツールを起動します。

詳細は、SEAM ツールを起動する方法を参照してください。

「Policies」タブをクリックします。

変更するポリシーを一覧から選択して「Modify」をクリックします。

「Policy Details」パネルが表示されます。

ポリシーの属性を変更します。

「Help」メニューから「Context-Sensitive Help」を選択すると、このウィンドウの属性に関する情報が表示されます。ポリシーのすべての属性の説明については、表 17–5 を参照してください。

注 –
ポリシー名は変更できません。ポリシー名を変更するときは、ポリシーを複製し、新しい名前を指定して保存してから、古いポリシーを削除する必要があります。

「Save」をクリックしてポリシーを保存するか、「Done」をクリックします。

例 — ポリシーの変更 (コマンド行)

次の例では、kadmin の modify_policy コマンドを使用して、build11 ポリシーの最小パスワード長を 5 文字に変更します。

$ kadmin
kadmin: modify_policy -minlength 5 build11
kadmin: quit

ポリシーを削除する方法

対応するコマンド行の例は、この手順のあとに示します。

必要に応じて、SEAM ツールを起動します。

詳細は、SEAM ツールを起動する方法を参照してください。

「Policies」タブをクリックします。

注 –
ポリシーを削除する前に、現在使用しているすべての主体からそのポリシーを取り消す必要があります。ポリシーを取り消すには、その主体の「Policy」属性を変更する必要があります。任意の主体が使用しているポリシーは、削除できません。

削除するポリシーを一覧から選択して、「Delete」をクリックします。

削除を確定すると、ポリシーが削除されます。

例 — ポリシーの削除 (コマンド行)

次の例では、kadmin の delete_policy コマンドを使用して、build11 ポリシーを削除します。

kadmin: delete_policy build11 
Are you sure you want to delete the policy "build11"? (yes/no): yes
kadmin: quit

ポリシーを削除する前に、現在使用しているすべての主体からそのポリシーを取り消す必要があります。ポリシーを取り消すには、関係する主体に対して kadmin の modify_principal -policy コマンドを使用する必要があります。そのポリシーが主体に使用されている場合は、delete_policy コマンドは失敗します。

SEAM ツール参照

この節では、SEAM ツールの参照情報について説明します。

SEAM ツールパネルの説明

この節では、SEAM ツールで指定または表示できる主体とポリシーの属性について説明します。属性は、表示されるパネルごとに分類されています。

表 17–2 「Principal Basics」パネルの属性


属性	説明
Principal Name	主体名 (完全指定形式の主体名の `primary`/`instance` 部分)主体は、KDC がチケットを割り当てることができる一意の ID 主体を変更しようとしても、主体名は編集できない
Password	主体のパスワード。「Generate Random Password」ボタンを使用して、主体のランダムパスワードを作成できる
Policy	主体に使用できるポリシーのメニュー
Account Expires	主体のアカウントが期限切れになる日時。アカウントが期限切れになると、主体はチケット認可チケット (TGT) を取得できず、ログインできなくなる
Last Principal Change	主体の情報が最後に変更された日付 (読み取り専用)
Last Changed By	この主体のアカウントを最後に変更した主体名 (読み取り専用)
Comments	主体に関連するコメント (「一時アカウント」など)

表 17–3 「Principal Details」パネルの属性


属性	説明
Last Success	主体が最後に正常にログインした日時 (読み取り専用)
Last Failure	主体が最後にログインに失敗した日時 (読み取り専用)
Failure Count	主体のログインが失敗した回数 (読み取り専用)
Last Password Change	主体のパスワードが最後に変更された日時 (読み取り専用)
Password Expires	主体の現在のパスワードが期限切れになる日時
Key Version	主体の鍵のバージョン番号。この属性は通常、パスワードが危険にさらされた場合にだけ変更される
Maximum Lifetime (seconds)	チケットを主体が使用できる最大期間 (更新しない場合)
Maximum Renewal (seconds)	既存のチケットを主体が更新できる最大期間

表 17–4 「Principal Flags」パネルの属性


属性 (ラジオボタン)	説明
Disable Account	チェックすると、その主体はログインできなくなる。この属性は、主体のアカウントを一時的に凍結するときに使用する
Require Password Change	チェックすると、主体の現在のパスワードが期限切れとなり、ユーザーは `kpasswd` コマンドを使用して新しいパスワードを作成しなければならない。この属性は、セキュリティ違反が発生し、古いパスワードを置換する必要があるときに使用する
Allow Postdated Tickets	チェックすると、主体は遅延チケットを取得できるたとえば、`cron` ジョブを数時間後に実行する場合は、遅延チケットを使用する必要がある。ただし、チケットの有効期限が短い場合は、事前にチケットを取得できない
Allow Forwardable Tickets	チェックすると、主体は転送可能チケットを取得できる転送可能チケットは、リモートホストに転送されて、シングルサインオンセッションを実現する。たとえば、転送可能チケットを使用して、ユーザー自身の `ftp` 認証または `rsh` 認証が完了すると、NFS サービスなどのほかのサービスを利用するときに、新たにパスワードを要求されない
Allow Renewable Tickets	チェックすると、主体が更新可能チケットを取得できる主体は、チケットが更新可能な場合、有効期限日時を自動的に延長することができる。つまり、最初のチケットの期限が切れても、新しいチケットを取得する必要がない。現在の NFS サービスは、チケットを新しくするチケットサービスである
Allow Proxiable Tickets	チェックすると、主体は代理可能チケットを取得できる代理可能チケットを使用すると、クライアントの代わりにサービスがクライアントの操作を実行できる。サービスは、代理可能チケットを使用すると、クライアントの ID を使用して別のサービスのチケットを取得できる。ただし、チケット認可チケットを取得することはできない
Allow Service Tickets	チェックすると、サービスチケットを特定の主体に発行できるサービスチケットの発行は、`kadmin/hostname` および `changepw/hostname` 主体に許可してはならない。これらの主体は、KDC データベース以外は更新してはならない
Allow TGT-Based Authentication	チェックすると、このサービス主体は別の主体にサービスを提供できる。つまり、KDC は、サービス主体にサービスチケットを発行できるこの属性は、サービス主体にだけ使用できる。チェックを解除すると、サービスチケットをサービス主体に対して発行できない
Allow Duplicate Authentication	チェックすると、このユーザー主体はほかのユーザー主体のサービスチケットを取得できるこの属性は、ユーザー主体にだけ使用できる。チェックを解除すると、ユーザー主体はサービス主体のサービスチケットを取得できるが、ほかのユーザー主体のサービスチケットは取得できない
Required Preauthentication	チェックすると、KDC が要求されたチケット認可チケット (TGT) を主体に送信する前に、その主体が TGT を要求している主体であることを KDC のソフトウェアが認証する。この事前認証は通常、DES カードなどの特別のパスワードを使用して行われるチェックを解除すると、KDC は要求された TGT を主体に送信する前に、主体の事前認証を必要としない
Required Hardware Authentication	チェックすると、KDC が要求されたチケット認可チケット (TGT) を主体に送信する前に、その主体が TGT を要求している主体であることを KDC のハードウェアが認証する。ハードウェア事前認証は、たとえば Java リングのリーダー上で行われるチェックを解除すると、KDC は要求された TGT を主体に送信する前に、主体の事前認証を必要としない

表 17–5 「Policy Basics」区画の属性


属性	説明
Policy Name	ポリシー名。ポリシーとは、主体のパスワードとチケットを管理する一連のルールのことであるポリシーを変更しようとしても、ポリシー名は編集できない
Minimum Password Length	主体の最小パスワード長
Minimum Password Classes	主体のパスワードに必要な異なる文字タイプの数たとえば、最小クラス値が 2 の場合は、パスワードに 2 種類以上の文字タイプを使用する必要がある。たとえば、英字と数字を使用して "hi2mom" と入力する必要がある。値が 3 の場合は、パスワードに 3 種類以上の文字タイプを使用する必要がある。たとえば、英字、数字、および句読点を使用して "hi2mom!" と入力する必要がある値が 1 の場合は、パスワード文字タイプの数に制限が設定されない
Saved Password History	主体に使用された過去のパスワードの数と、過去のパスワードの一覧。これらのパスワードは再使用できない
Minimum Password Lifetime (seconds)	パスワードの最小使用期間。この期間が経過しないとパスワードを変更できない
Maximum Password Lifetime (seconds)	パスワードの最大使用期間。この期間が経過したらパスワードを変更する必要がある
Principals Using This Policy	このポリシーが現在適用されている主体の数 (読み取り専用)

Kerberos 管理権限を制限して SEAM ツールを使用する

admin 主体が Kerberos データベースの管理権限をすべて持っている場合は、SEAM 管理ツールの機能をすべて使用できます。ただし、Kerberos 管理権限は、制限することもできます。たとえば、主体の一覧だけを表示できるようにしたり、主体のパスワードを変更できるようにしたりできます。Kerberos 管理権限を制限した場合でも、SEAM ツールを使用できます。ただし、許可された Kerberos 管理権限によって、SEAM ツールの使い方が異なります。表 17–6 は、Kerberos 管理権限に基づいた SEAM ツールの変更の一覧です。

一覧表示権限がない場合、SEAM ツールの使い方が最も大きく変わります。この場合、操作する主体とポリシーの一覧が「List」パネルに表示されません。代わりに、「List」パネルの「Name」フィールドを使用して、操作する主体またはポリシーを指定する必要があります。

SEAM ツールにログインしても、必要な権限がない場合は、次のメッセージが表示されて「SEAM Administration Login」ウィンドウに戻ります。

Insufficient privileges to use gkadmin: ADMCIL. Please try using another principal.

主体が Kerberos データベースを管理する権限を変更する方法については、Kerberos 管理権限を変更する方法を参照してください。

表 17–6 Kerberos 管理権限を制限して SEAM を使用する


許可しない権限	SEAM ツールの変更
`a` (追加)	「Principal List」および「Policy List」パネルの「Create New」と「Duplicate」ボタンを使用できない。追加権限がない場合は、新しい主体またはポリシーを作成または複製できない
`d` (削除)	「Principal List」および「Policy List」パネルの「Delete」ボタンを使用できない。削除権限がない場合は、主体またはポリシーを削除できない
`m` (変更)	「Principal List」および「Policy List」パネルの「Modify」ボタンを使用できない。変更権限がない場合は、主体またはポリシーを変更できないまた、「Modify」ボタンを使用できない場合、パスワードの変更権限を持っていても、主体のパスワードを変更できない
`c` (パスワードの変更)	「Principal Basics」パネルの「Password」フィールドが読み取り専用になり、変更できない。パスワードの変更権限がない場合、主体のパスワードを変更できないパスワードの変更権限を持っている場合でも、主体のパスワードを変更するときは、さらに変更権限が必要になる
`i` (データベースの照会)	「Principal List」および「Policy List」パネルの「Modify」と「Duplicate」ボタンを使用できない。照会権限がない場合は、主体またはポリシーを変更または複製できないまた、「Modify」ボタンを使用できない場合、パスワードの変更権限を持っていても、主体のパスワードを変更できない
`l` (一覧)	「List」パネルで主体とポリシーの一覧を表示できない。一覧権限がない場合は、「List」パネルの「Name」フィールドを使用して、操作する主体またはポリシーを指定する必要がある

キータブファイルの管理

サービスを提供するすべてのホストには、「キータブ」 (鍵テーブルの短縮名) と呼ばれるローカルファイルが必要です。キータブには、「サービス鍵」と呼ばれる該当するサービスの主体が格納されます。サービス鍵は、KDC に対してサービス自身を認証するときに使用され、Kerberos とそのサービスだけが認識します。たとえば、Kerberos NFS サーバーを使用する場合、このサーバーには nfs サービス主体を含むキータブが必要です。

キータブファイルにサービス鍵を追加するには、kadmin の ktadd コマンドを使用して、ホストのキータブファイルに該当するサービス主体を追加します。サービス主体をキータブファイルに追加するときは、Kerberos データベースにあらかじめ主体を登録し、kadmin が主体の存在を確認できるようにする必要があります。マスター KDC では、キータブファイルのデフォルトの位置は /etc/krb5/kadm5.keytab です。Kerberos サービスを提供するアプリケーションサーバーでは、キータブファイルのデフォルトの位置は /etc/krb5/krb5.keytab です。

キータブはユーザーのパスワードに似ています。ユーザーの場合は、自分のパスワードを保護することが重要ですが、アプリケーションサーバーの場合は、キータブファイルを保護することが重要です。キータブファイルは常時ローカルディスクに格納し、root ユーザー以外は読み取れないようにしてください。また、キータブファイルは、セキュリティ保護されていないネットワークを介して送信しないでください。

root 主体をホストのキータブファイルに追加することがあります。SEAM クライアント上のユーザーが Kerberos NFS ファイルシステムを自動的にマウントして Kerberos 認証を使用する場合は、クライアントの root 主体をクライアントのキータブファイルに追加する必要があります。追加しなかった場合、Kerberos NFS ファイルシステムをマウントするたびに、ユーザーは kinit コマンドをスーパーユーザーとして使用して、クライアントの root 主体の資格を取得する必要があります。これは、オートマウンタを使用している場合でも同様です。詳細は、NFS ファイルシステムをマウントするように root 認証を設定するを参照してください。

注 –

マスター KDC を設定するときは、kadmind および changepw 主体を kadm5.keytab ファイルに追加する必要があります。この手順によって、KDC は管理者の Kerberos チケットを復号化して、管理者にデータベースへのアクセス権を与えるかどうかを決定することができます。

キータブファイルを管理するときに、ktutil コマンドも使用できます。ktutil は対話型のコマンドで、Kerberos 管理権限がなくても、ローカルホストのキータブファイルを管理できます。これは、kadmin は Kerberos データベースと対話しますが、ktutil は対話しないためです。つまり、主体をキータブファイルに追加したあとに ktutil を使用すると、キータブファイル内のキー一覧を表示したり、サービスの認証を一時的に無効にしたりできます。

キータブファイルの管理 (作業マップ)

作業	説明	参照先
サービス主体をキータブファイルに追加する	`kadmin` の `ktadd` コマンドを使用して、サービス主体をキータブファイルに追加する	サービス主体をキータブファイルに追加する方法
キータブファイルからサービス主体を削除する	`kadmin` の `ktremove` コマンドを使用して、キータブファイルからサービスを削除する	キータブファイルからサービス主体を削除する方法
キータブファイル内のキー一覧 (主体) を表示する	`ktutil` コマンドを使用して、キータブファイル内のキー一覧を表示する	キータブファイル内のキー一覧 (主体) を表示する方法
ホスト上でのサービスの認証を一時的に無効にする	この手順を行うと、`kadmin` 権限がなくても、ホスト上でのサービスの認証を一時的に無効にできる `ktutil` を使用してサーバーのキータブファイルからサービス主体を削除する前に、元のキータブファイルを一時的な位置にコピーする必要がある。サービスを再度有効にする場合は、元のキータブファイルを適切な場所に戻す必要がある	ホスト上のサービスの認証を一時的に無効にする方法

サービス主体をキータブファイルに追加する方法

主体がすでに Kerberos データベースに登録されていることを確認します。

詳細は、主体の一覧を表示する方法を参照してください。

キータブファイルに主体を追加するホスト上でスーパーユーザーになります。

kadmin コマンドを起動します。
# /usr/sbin/kadmin

ktadd コマンドを使用して、キータブファイルに主体を追加します。

kadmin: ktadd [-k keytab] [-q] [principal | -glob principal-exp]

`-k` `keytab`	キータブファイルを指定する。デフォルトでは、`/etc/krb5/krb5.keytab` が使用される
`-q`	冗長な情報を表示しない
`principal`	キータブファイルに追加する主体を指定する。 `host`、`root`、`nfs`、および `ftp` のサービス主体を追加できる
`-glob` `principal-exp`	主体表現を指定する。主体表現に一致するすべての主体が、キータブファイルに追加される。主体表現の規則は、`kadmin` の `list_principals` コマンドと同じである

kadmin コマンドを終了します。
kadmin: quit

例 — サービス主体をキータブファイルに追加する

次の例では、kadmin/admin および kadmin/changepw 主体をマスター KDC のキータブファイルに追加します。この例のキータブファイルは、kdc.conf ファイルで指定されている必要があります。

kdc1 # /usr/sbin/kadmin.local
kadmin.local: ktadd -k /etc/krb5/kadm5.keytab kadmin/admin kadmin/changepw
Entry for principal kadmin/admin@EXAMPLE.COM with kvno 3, encryption type DES-CBC-CRC
  added to keytab WRFILE:/etc/krb5/kadm5.keytab.
Entry for principal kadmin/changepw@EXAMPLE.COM with kvno 3, encryption type DES-CBC-CRC
  added to keytab WRFILE:/etc/krb5/kadm5.keytab.
kadmin.local: quit

次の例では、denver の host 主体を denver のキータブファイルに追加し、KDC が denver のネットワークサービスを認証できるようにします。

denver # /usr/sbin/kadmin
kadmin: ktadd host/denver@example.com@EXAMPLE.COM
kadmin: Entry for principal host/denver@example.com@EXAMPLE.COM with kvno 2,
  encryption type DES-CBC-CRC added to keytab WRFILE:/etc/krb5/krb5.keytab.
kadmin: quit

キータブファイルからサービス主体を削除する方法

キータブファイルから削除するサービス主体が登録されているホスト上でスーパーユーザーになります。

kadmin コマンドを起動します。
# /usr/sbin/kadmin

(省略可能) キータブファイル内の現在の主体 (鍵) の一覧を表示するには、ktutil コマンドを使用します。

詳細は、キータブファイル内のキー一覧 (主体) を表示する方法を参照してください。

ktremove コマンドを使用して、キータブファイルから主体を削除します。

kadmin: ktremove [-k keytab] [-q] principal [kvno | all | old ]

`-k` `keytab`	キータブファイルを指定する。デフォルトでは、`/etc/krb5/krb5.keytab` が使用される
`-q`	冗長な情報を表示しない
`principal`	キータブファイルから削除する主体を指定する
`kvno`	指定された主体のうち、鍵のバージョン番号が `kvno` と一致する主体のすべてのエントリを削除する
`all`	指定された主体のすべてのエントリを削除する
`old`	指定した主体のすべてのエントリを削除する。ただし、鍵のバージョン番号が最上位の主体は削除しない

kadmin コマンドを終了します。
kadmin: quit

例 — キータブファイルからサービス主体を削除する

次の例では、denver の host 主体を denver のキータブファイルから削除します。

denver # /usr/sbin/kadmin
kadmin: ktremove host/denver.example.com@EXAMPLE.COM
kadmin: Entry for principal host/denver.example.com@EXAMPLE.COM with kvno 3
  removed from keytab WRFILE:/etc/krb5/krb5.keytab.
kadmin: quit

キータブファイル内のキー一覧 (主体) を表示する方法

キータブファイルが存在するホスト上でスーパーユーザーになります。

注 –
ほかのユーザーが所有するキータブファイルを作成することもできますが、キータブファイルのデフォルトの位置には root 所有権が必要です。

ktutil コマンドを起動します。
# /usr/bin/ktutil

read_kt コマンドを使用して、キータブファイルをキー一覧バッファーに読み込みます。
ktutil: read_kt keytab

list コマンドを使用して、キー一覧バッファーを表示します。
ktutil: list
現在のキー一覧バッファーが表示されます。

ktutil コマンドを終了します。
ktutil: quit

例 — キータブファイル内のキー一覧 (主体) を表示する

次の例では、denver ホストの /etc/krb5/krb5.keytab ファイル内のキー一覧を表示します。

denver # /usr/bin/ktutil
    ktutil: read_kt /etc/krb5/krb5.keytab
    ktutil: list
slot KVNO Principal
---- ---- ---------------------------------------
   1    5 host/denver@EXAMPLE.COM
    ktutil: quit

ホスト上のサービスの認証を一時的に無効にする方法

ネットワークアプリケーションサーバー上の rlogin や ftp など、サービスの認証メカニズムを一時的に無効にしなければならない場合があります。たとえば、保守作業中は、ユーザーがシステムにログインできないようにする必要があります。ktutil コマンドを使用してサーバーのキータブファイルからサービス主体を削除することにより、サービスの認証を一時的に無効にすることができます。このとき、kadmin 権限は必要ありません。認証を再度有効にするには、保存した元のキータブファイルを元の位置にコピーするだけです。

注 –

デフォルトでは、ほとんどのサービスが認証を要求するように設定されています。そのように設定されていないときは、サービスの認証を無効にした場合でもサービスは動作します。

キータブファイルが存在するホスト上でスーパーユーザーになります。

注 –
ほかのユーザーが所有するキータブファイルを作成することもできますが、キータブファイルのデフォルトの位置には root 所有権が必要です。

現在のキータブファイルを一時ファイルに保存します。

ktutil コマンドを起動します。
# /usr/bin/ktutil

read_kt コマンドを使用して、キータブファイルをキー一覧バッファーに読み込みます。
ktutil: read_kt keytab

list コマンドを使用して、キー一覧バッファーを表示します。
ktutil: list
現在のキー一覧バッファーが表示されます。無効にするサービスのスロット番号を記録します。

ホストのサービスを一時的に無効にするには、delete_entry コマンドを使用して、キー一覧バッファーから目的のサービス主体を削除します。
ktutil: delete_entry slot-number
この例では、slot-number に、削除するサービス主体のスロット番号を指定します。スロット番号は、list コマンドで表示できます。

write_kt コマンドを使用して、キー一覧バッファーをキータブファイルに書き込みます。
ktutil: write_kt keytab

ktutil コマンドを終了します。
ktutil: quit

サービスを再度有効にする場合は、一時的な (元の) キータブファイルを元の場所にコピーします。

例 — ホスト上のサービスを一時的に無効にする

次の例では、denver ホスト上の host サービスを一時的に無効にします。denver 上のホストサービスを再度有効にするには、krb5.keytab.temp ファイルを /etc/krb5/krb5.keytab ファイルにコピーします。

denver # cp /etc/krb5/krb5.keytab /etc/krb5/krb5.keytab.temp
denver # /usr/bin/ktutil
    ktutil:read_kt /etc/krb5/krb5.keytab
    ktutil:list
slot KVNO Principal
---- ---- ---------------------------------------
   1    8 root/denver@EXAMPLE.COM
   2    5 host/denver@EXAMPLE.COM
    ktutil:delete_entry 2
    ktutil:list
slot KVNO Principal
---- ---- --------------------------------------
   1    8 root/denver@EXAMPLE.COM
    ktutil:write_kt /etc/krb5/krb5.keytab
    ktutil: quit

第 18 章 SEAM の使用 (手順)

この章は、SEAM がインストールされているシステムのユーザーを対象としています。この章では、チケットの取得、表示、および破棄について説明します。また、Kerberos パスワードの選択または変更についても説明します。

この章の内容は次のとおりです。

SEAM の概要については、第 13 章「SEAM について」を参照してください。

チケットの管理

この節では、チケットの取得、表示、および破棄を行う方法を説明します。チケットの概要については、SEAM の動作を参照してください。

チケットを意識する必要があるか

SEAM 1.0 または SEAM 1.0.1 がインストールされている場合、Kerberos は login コマンドに組み込まれており、チケットの取得はログイン時に自動的に行われます。

また、ほとんどの Kerberos コマンドは、終了時にチケットを自動的に破棄します。ただし、念のために、コマンドが終了したときに Kerberos チケットを明示的に破棄したい場合は、kdestroy を使用します。kdestroy の詳細は、チケットを破棄する方法を参照してください。

チケットの有効期限については、チケットの有効期限を参照してください。

チケットを作成する方法

通常は、ログインするとチケットが自動的に作成されるため、チケットを取得するために特別な作業をする必要はありません。ただし、チケットが期限切れになった場合は、チケットを作成する必要があります。

チケットを作成するには、kinit コマンドを使用します。

% /usr/bin/kinit

kinit からはパスワードの入力を求めるプロンプトが表示されます。kinit コマンドの詳細な構文については、kinit(1) のマニュアルページを参照してください。

例 — チケットを作成する

この例では、ユーザー jennifer が自分のシステムにチケットを作成します。

% kinit
Password for jennifer@ENG.EXAMPLE.COM:  <パスワードを入力する>

次の例では、ユーザー david が -l オプションを使用して 3 時間有効なチケットを作成します。

% kinit -l 3h david@EXAMPLE.ORG
Password for david@EXAMPLE.ORG:  <パスワードを入力する>

次の例では、ユーザー david は、 -f を使用して転送可能チケットを作成します。この転送可能チケットを使用すると、ユーザーは、たとえば、別のシステムにログインできます。

% kinit -f david@EXAMPLE.ORG
Password for david@EXAMPLE.ORG:     <パスワードを入力する>

転送チケットをどのように使用するかについては、チケットの種類を参照してください。

チケットを表示する方法

すべてのチケットが同じ属性を持つわけではありません。チケットの属性には、「転送可能 (Forwardable)」、「遅延 (Postdated)」などがあります。また、1 つのチケットに「転送可能」と「遅延」の両方が指定されていることもあります。現在のチケットが何で、どのような属性を持つかを知るには、klist コマンドで -f オプションを使用します。

% /usr/bin/klist -f

次の記号はチケットに関連付けられる属性です。klist によって表示されます。

F	転送可能 (Forwardable)
f	転送済み (Forwarded)
P	プロキシ可能 (Proxiable)
p	プロキシ (Proxy)
D	遅延可能 (Postdatable)
d	遅延 (Postdated)
R	更新可能 (Renewable)
I	初期 (Initial)
i	無効 (Invalid)

チケットに指定できる属性については、チケットの種類を参照してください。

例 — チケットを表示する

次の例は、ユーザー jennifer の初期チケットが転送可能 (F) と遅延 (d) のプロパティを持っていて、まだ検証されていないこと (i) を示します。

% /usr/bin/klist -f
Ticket cache: /tmp/krb5cc_74287
Default principal: jenniferm@ENG.EXAMPLE.COM
 
Valid starting                 Expires                 Service principal
09 Mar 99 15:09:51  09 Mar 99 21:09:51  nfs/EXAMPLE.SUN.COM@EXAMPLE.SUN.COM
        renew until 10 Mar 99 15:12:51, Flags: Fdi

次の例は、ユーザー david が別のホストから自分のホストに転送済み (f) チケットを 2 つ持っていることを示します。これらのチケットは転送可能 (F) です。

% klist -f
Ticket cache: /tmp/krb5cc_74287
Default principal: david@EXAMPLE.SUN.COM
 
Valid starting                 Expires                 Service principal
07 Mar 99 06:09:51  09 Mar 99 23:33:51  host/EXAMPLE.COM@EXAMPLE.COM
        renew until 10 Mar 99 17:09:51, Flags: fF
 
Valid starting                 Expires                 Service principal
08 Mar 99 08:09:51  09 Mar 99 12:54:51  nfs/EXAMPLE.COM@EXAMPLE.COM
        renew until 10 Mar 99 15:22:51, Flags: fF

チケットを破棄する方法

チケットは通常、チケットを作成したコマンドが終了すると自動的に破棄されます。ただし、念のために、コマンドが終了したときに Kerberos チケットを明示的に破棄したい場合があります。チケットは盗まれることもあります。盗まれたチケットが復号化されると、期限切れになるまで使用される可能性があります。

チケットを破棄するには、kdestroy コマンドを使用します。

% /usr/bin/kdestroy

kdestroy はそのユーザーのすべてのチケットを破棄します。このコマンドを使用して、特定のチケットを選択して破棄することはできません。

システムを離れるときに侵入者が権限を使用する危険がある場合は、kdestroy を使用してチケットを破棄するか、スクリーンセーバーを使って画面をロックする必要があります。

注 –

チケットを確実に破棄する 1 つの方法は、ホームディレクトリの .logout ファイルに kdestroy コマンドを追加することです。

通常はデフォルトで PAM モジュールが構成されているため、チケットはログアウト時に自動的に破棄されます。よって、.login ファイルに kdestroy への呼び出しを追加する必要はありません。ただし、PAM モジュールが構成されていない場合や、構成されているかどうかわからない場合は、システムを終了するときにチケットを確実に破棄するために、kdestroy を .login ファイルに追加します。

パスワード管理

SEAM をインストールすると、2 つのパスワードを持つことになります。通常の Solaris パスワードと Kerberos パスワードです。これらのパスワードは同じでも、異なっていてもかまいません。

通常、Kerberos 以外のコマンド (login など) は、PAM を使用して Kerberos と UNIX の両方で認証するように設定できます。2 つのパスワードが異なっている場合は、ログインで適切な認証を得るために両方のパスワードを入力する必要があります。2 つのパスワードが同じ場合は、UNIX 用に入力した最初のパスワードが Kerberos で使用されます。

ただし、UNIX と Kerberos に同じパスワードを使用すると、セキュリティを損うおそれがあります。つまり、他人が Kerberos パスワードを入手した場合、UNIX パスワードも安全ではありません。しかし、UNIX と Kerberos に同じパスワードを使用したとしても、Kerberos 環境ではパスワードがネットワークを超えて送信されることはないため、Kerberos 認証のないサイトに比べて安全です。通常、どの方法を選ぶかは、サイトごとの方針に従います。

Kerberos では、Kerberos パスワードだけを使用して、ユーザーの識別を検証します。Kerberos では、パスワードの所有者以外のユーザーに Kerberos パスワードを知られた場合、セキュリティが保証されなくなります。そのユーザーが所有者になることができるためです。そのユーザーは、パスワードの所有者として電子メールを送信したり、所有者のファイルの読み込み、編集、または削除を行ったり、所有者として別のホストにログインしたりできます。この場合、正しいユーザーを識別することは不可能です。したがって、適切なパスワードを選択し、その秘密を保持することは極めて重要です。パスワードは、システム管理者を含め誰にも教えてはいけません。また、パスワードは頻繁に変更してください。他人に知られた可能性のある場合は特に変更が必要です。

パスワード選択のヒント

パスワードには、キーボードから入力できるほとんどの文字を使用できます。ただし、Ctrl キーと Return キーは使用できません。良いパスワードとは、覚えやすく、しかも他人が簡単に推定できないパスワードです。悪いパスワードの例を次に示します。

辞書に出てくる言葉
よく見られるありふれた名前
有名な人やキャラクタの名前
ユーザーの氏名またはユーザー名 (たとえば、名前を逆に綴る、2 度繰り返す)
配偶者の名前、子供の名前、ペットの名前
自分の誕生日や親戚の誕生日
社会保険番号、運転免許書番号、パスポート番号、またはこれに類した身分証明書番号
このマニュアルやほかのマニュアルに出てくるサンプルパスワード

良いパスワードとは 8 文字以上の長さで、大文字、小文字、数字、句読記号などが混在しているものです。次に例を示します。

「I2LMHinSF」などの短縮形。(「I too left my heart in San Francisco」と覚える)
「WumpaBun」、「WangDangdoodle!」など、発音しやすい意味のない語句
「6o'cluck」、「RrriotGrrrlsRrrule!」など、わざとスペルを間違えた語句

注意 –

これらの例は使用しないでください。マニュアルの例に使用されているパスワードは侵入者が最初に試みるパスワードです。

パスワードの変更方法

Kerberos パスワードは次の 2 つの方法で変更できます。

通常の UNIX の passwd コマンド。SEAM がインストールされていると、Solaris の passwd コマンドでも新しい Kerberos パスワードを求めるプロンプトが自動的に表示されます。

kpasswd の代わりに passwd を使用する利点は、UNIX と Kerbeors 両方のパスワードを同時に設定できることです。ただし、一般的には passwd コマンドで両方のパスワードを同時に変更する必要はありません。UNIX パスワードだけを変更して Kerberos パスワードは変更しなかったり、その逆であっても構いません。

注 –
passwd コマンドの動作は、PAM モジュールの構成方法によって異なります。構成によっては、両方のパスワードを変更しなければならない場合があります。あるサイトでは UNIX パスワードの変更が必須であり、別のサイトでは Kerberos パスワードの変更が必須であるという場合があります。
kpasswd パスワードコマンド。kpasswd コマンドは、passwd コマンドと似ています。ただし、kpasswd コマンドでは、Kerberos パスワード以外は変更できません。UNIX パスワードを変更する場合は、passwd コマンドを使用する必要があります。

もう 1 つの違いは、kpasswd コマンドでは、有効な UNIX ユーザーではない Kerberos 主体のパスワードを変更できる点です。たとえば、david/admin は Kerberos 主体ですが、実際の UNIX ユーザーではありません。したがって、この場合は、passwd コマンドの代わりに kpasswd コマンドを使用する必要があります。

パスワードを変更しても、変更がシステム全体に伝播されるまでには、ある程度の時間が必要です (特に大規模なネットワークでは)。システムの設定方法によりますが、この時間は数分から 1 時間以上になることがあります。パスワードを変更したあとすぐに新しい Kerberos チケットを取得する場合は、新しいパスワードをまず試してください。新しいパスワードが有効でない場合は、以前のパスワードを使用して再度試してください。

Kerberos V5 では、システム管理者が有効なパスワードの基準をユーザーごとに設定できます。この基準は、ユーザーごとの「ポリシー」に定義できます。デフォルトのポリシーを使用することもできます。ポリシーの詳細は、ポリシーの管理を参照してください。

たとえば、ユーザー jennifer の jenpol ポリシーでは、パスワードは 8 文字以上で、2 種類以上の文字が混在すると定義されているとします。その場合、パスワードとして「sloth」を入力すると、kpasswd によって拒否されます。

% kpasswd
kpasswd: Changing password for jennifer@ENG.EXAMPLE.COM.
Old password:   <jennifer が既存のパスワードを入力する>
kpasswd: jennifer@ENG.EXAMPLE.COM's password is controlled by
the policy jenpol
which requires a minimum of 8 characters from at least 2 classes 
(the five classes are lowercase, uppercase, numbers, punctuation,
and all other characters).
New password: <jennifer が「sloth」と入力する>
New password (again):  <jennifer が再び「sloth」と入力する>
kpasswd: New password is too short.
Please choose a password which is at least 4 characters long.

次に、jennifer はパスワードとして「slothrop49」を入力します。「slothrop49」は長さが 8 文字以上で、2 種類の文字 (数字と小文字) が混在しているため基準に合っています。

% kpasswd
kpasswd: Changing password for jennifer@ENG.EXAMPLE.COM.
Old password:  <jennifer が既存のパスワードを入力する>
kpasswd: jennifer@ENG.EXAMPLE.COM's password is controlled by
the policy jenpol
which requires a minimum of 8 characters from at least 2 classes 
(the five classes are lowercase, uppercase, numbers, punctuation,
and all other characters).
New password:  <jennifer が「slothrop49」と入力する>
New password (again):  <jennifer が「slothrop49」と再度入力する>
Kerberos password changed.

例 — パスワードを変更する

次の例では、ユーザー david が passwd を使用して、UNIX および Kerberos のパスワードを変更します。

% passwd
	passwd:  Changing password for david
	Enter login (NIS+) password:         <現在の UNIX パスワードを入力する>

	New password:                        <新しい UNIX パスワードを入力する>

	Re-enter password:                   <新しい UNIX パスワードを確認する>

	Old KRB5 password:                   <現在の Kerberos パスワードを入力する>

	New KRB5 password:                   <新しい Kerberos パスワードを入力する>

	Re-enter new KRB5 password:          <新しい Kerberos パスワードを確認する>

この例では、passwd により、UNIX パスワードと Kerberos パスワードが要求されます。ただし、PAM モジュールで try_first_pass が設定されていると、Kerberos パスワードは自動的に UNIX パスワードと同じ内容に設定されます。これはデフォルトの設定です。この場合、ユーザー david は kpasswd を使用して、次の例で示すように Kerberos パスワードを変更する必要があります。

次の例では、ユーザー david が kpasswd を使用して、Kerberos パスワードだけを変更します。

% kpasswd
kpasswd: Changing password for david@ENG.EXAMPLE.COM.
Old password:           <現在の Kerberos パスワードを入力する>

New password:           <新しい Kerberos パスワードを入力する>

New password (again):   <新しい Kerberos パスワードを確認する>

Kerberos password changed.

次の例では、ユーザー david が、Kerberos 主体 david/admin (有効な UNIX ユーザーではない) のパスワードを変更します。kpasswd を使用する必要があります。

% kpasswd david/admin
kpasswd:  Changing password for david/admin.
Old password:		   	     <現在の Kerberos パスワードを入力する>

New password:			       <新しい Kerberos パスワードを入力する>

New password (again):	   <新しい Kerberos パスワードを再度入力する>

Kerberos password changed.

第 19 章 SEAM (参照)

この章では、SEAM 製品に組み込まれている多数のファイル、コマンド、およびデーモンについて一覧表示します。また、Kerberos 認証システムの機能についても詳細に説明します。

この章の内容は次のとおりです。

SEAM ファイル

表 19–1 SEAM ファイル


ファイル名	説明
`~/.gkadmin`	SEAM 管理ツールで新しい主体を作成するときのデフォルト値
`~/.k5login`	Kerberos アカウントに対してアクセス権を許可する主体のリスト
`/etc/init.d/kdc`	`krb5kdc` を起動または停止する `init` スクリプト
`/etc/init.d/kdc.master`	`kadmind` を起動または停止する `init` スクリプト
`/etc/krb5/kadm5.acl`	Kerberos アクセス制御リストファイル。KDC 管理者の主体名とその Kerberos 管理特権を含む
`/etc/krb5/kadm5.keytab`	マスター KDC 上の `kadmin` サービスのキータブファイル
`/etc/krb5/kdc.conf`	KDC 構成ファイル
`/etc/krb5/kpropd.acl`	Kerberos データベース伝播構成ファイル
`/etc/krb5/krb5.conf`	Kerberos レルム構成ファイル
`/etc/krb5/krb5.keytab`	ネットワークアプリケーションサーバー用キータブファイル
`/etc/krb5/warn.conf`	Kerberos 警告構成ファイル
`/etc/pam.conf`	PAM 構成ファイル
`/tmp/krb5cc_uid`	デフォルト資格キャッシュ (`uid` はユーザーの 10 進 UID)
`/tmp/ovsec_adm.xxxxxx`	パスワード変更操作の間だけ有効な一時資格キャッシュ (`xxxxxx` はランダムな文字列)
`/var/krb5/.k5.REALM`	KDC stash ファイル。KDC マスター鍵の暗号化されたコピーを含む
`/var/krb5/kadmin.log`	`kadmind` のログファイル
`/var/krb5/kdc.log`	KDC のログファイル
`/var/krb5/principal.db`	Kerberos 主体データベース
`/var/krb5/principal.kadm5`	Kerberos 管理データベース。ポリシー情報を含む
`/var/krb5/principal.kadm5.lock`	Kerberos 管理データベースのロックファイル
`/var/krb5/principal.ok`	Kerberos 主体データベースの初期化ファイル。Kerberos データベースの初期化が正常終了すると作成される
`/var/krb5/slave_datatrans`	KDC のバックアップファイルで、`kprop_script` スクリプトが伝播時に使用する

PAM 構成ファイル

デフォルトの PAM 構成ファイルには、認証サービス、アカウント管理、セッション管理、およびパスワード管理の各モジュールに対するエントリが含まれています。

認証モジュールについては、SEAM 1.0 または 1.0.1 がインストールされている場合、rlogin、 login、dtlogin の新しいエントリが作成されます。これらのエントリの例を、以下に示します。これらのサービスはすべて PAM ライブラリ /usr/lib/security/pam_krb5.so.1 を使用して Kerberos 認証を行います。

これらのエントリでは try_first_pass オプションが使用されています。この場合、ユーザーの最初のパスワードを使用して認証が行われます。最初のパスワードを使用すると、複数のメカニズムが記述されていても、ユーザーは別のパスワードを入力する必要がありません。

# cat /etc/pam.conf
 .
 .
rlogin auth optional /usr/lib/security/pam_krb5.so.1 try_first_pass
login auth optional /usr/lib/security/pam_krb5.so.1 try_first_pass
dtlogin auth optional /usr/lib/security/pam_krb5.so.1 try_first_pass
other auth optional /usr/lib/security/pam_krb5.so.1 try_first_pass

アカウント管理モジュールの場合、Kerberos ライブラリを使用する dtlogin の新しいエントリが次のように作成されます。other エントリはデフォルトの規則を提供するために 1 つ含まれています。現時点では、other エントリによって何の動作も行われません。

dtlogin account optional /usr/lib/security/pam_krb5.so.1 
other account optional /usr/lib/security/pam_krb5.so.1

次に /etc/pam.conf ファイルの最後の 2 つのエントリを示します。セッション管理の other エントリではユーザー資格を破棄します。パスワード管理の新しい other エントリでは Kerberos ライブラリを選択します。

other session optional /usr/lib/security/pam_krb5.so.1 
other password optional /usr/lib/security/pam_krb5.so.1 try_first_pass

SEAM コマンド

この節では、SEAM 製品に含まれているコマンドの一部を示します。

表 19–2 SEAM コマンド


コマンド	説明
`/usr/lib/krb5/kprop`	Kerberos データベース伝播プログラム
`/usr/sbin/gkadmin`	Kerberos データベース管理 GUI プログラム。主体とポリシーの管理に使用される
`/usr/sbin/kadmin`	リモート Kerberos データベース管理プログラム (Kerberos 認証で実行される)。主体、ポリシー、およびキータブファイルの管理に使用される
`/usr/sbin/kadmin.local`	ローカル Kerberos データベース管理プログラム (Kerberos 認証がなくても動作するが、マスター KDC 上で実行する必要がある)。主体、ポリシー、およびキータブファイルの管理に使用される
`/usr/sbin/kdb5_util`	Kerberos データベースと stash ファイルを作成する

SEAM デーモン

次の表は、SEAM 製品で使用されるデーモンの一覧です。

表 19–3 SEAM デーモン


デーモン	説明
`/usr/lib/krb5/kadmind`	Kerberos データベース管理デーモン
`/usr/lib/krb5/kpropd`	Kerberos データベース伝播デーモン
`/usr/lib/krb5/krb5kdc`	Kerberos チケット処理デーモン

SEAM の用語

この節では、用語とその定義について説明します。これらの用語は、SEAM のマニュアル全体で使用されます。SEAM の概念を理解するには、これらの用語を理解する必要があります。

Kerberos 固有の用語

KDC を管理するには、この節で説明する用語を理解する必要があります。

「鍵配布センター (Key Distribution Center、KDC)」は、資格の発行を担当する SEAM の構成要素です。資格は、KDC データベースに格納されている情報に基づいて作成されます。各レルムには 2 つ以上の KDC サーバー (マスターと 1 つ以上のスレーブ) が必要です。すべての KDC が資格を生成できますが、KDC データベースを変更できるのはマスター KDC だけです。

KDC のマスター鍵を暗号化したコピーは「stash ファイル」に含まれます。サーバーがリブートされると、この鍵を使用して KDC が自動的に認証されて、kadmind と krb5kdc コマンドが起動されます。このファイルにはマスター鍵が入っているため、このファイルやバックアップは安全な場所に保管する必要があります。暗号が破られると、この鍵を使用して KDC データベースのアクセスや変更が可能になります。

認証固有の用語

認証処理を理解するには、この節で説明する用語を理解する必要があります。プログラマやシステム管理者はこれらの用語に精通している必要があります。

「クライアント」は、ユーザーのワークステーションで動作するソフトウェアです。クライアントで動作する SEAM ソフトウェアは、処理中に多数の要求を作成します。このため、SEAM ソフトウェアとユーザーの動作を区別することが重要です。

「サーバー」と「サービス」はよく同じ意味で使われます。明確に定義すると、「サーバー」は、SEAM ソフトウェアが動作する物理システムです。「サービス」は、サーバー上でサポートされる特定の機能 (nfs など) です。サーバーがサービスの一部として記述されることがよくありますが、これはこれらの用語の定義をあいまいにします。このマニュアルでは、サーバーという用語は、物理システムを指し、サービスという用語は、ソフトウェアを指します。

SEAM 製品には 3 種類の鍵があります。1 つは「非公開鍵」です。この鍵は各ユーザー (主体) に与えられ、主体のユーザーと KDC だけに知られています。ユーザー主体に対しては、鍵はユーザーのパスワードに基づいています。サーバーとサービスに対する鍵は「サービス鍵」と呼ばれます。サービス鍵は非公開鍵と同じ目的で使われますが、これはサーバーとサービスによって使用されます。3 つ目の鍵は「セッション鍵」です。セッション鍵は、認証サービスまたはチケット認可サービスによって生成されます。セッション鍵は、クライアントとサービス間のトランザクションのセキュリティを保護するために生成されます。

「チケット」は、ユーザーの識別情報をサーバーやサービスに安全に渡すために使用される情報パケットです。チケットは、単一クライアントと特定サーバー上の特定サービスだけに有効です。チケットには、サービスの主体名、ユーザーの主体名、ユーザーのホストの IP アドレス、タイムスタンプ、チケットの有効期限を定義する値などが含まれます。チケットは、クライアントとサービスによって使用されるランダムセッション鍵を使用して作成されます。チケットは、作成されてから有効期限まで再使用できます。

「資格」は、対応するセッション鍵とチケットを含む情報パケットです。一般に資格は、資格を暗号化するソフトウェアにより、非公開鍵かサービス鍵を使用して暗号化されます。

「オーセンティケータ（authenticator)」はさらに別の種類の情報です。これをチケットとともに使用すると、ユーザー主体の認証に使用できます。オーセンティケータには、ユーザーの主体名、ユーザーのホストの IP アドレス、タイムスタンプが含まれます。チケットとは異なり、オーセンティケータは一度しか使用できません。通常、サービスへのアクセスが要求されたときに使用されます。オーセンティケータは、そのクライアントとそのサーバーのセッション鍵を使用して暗号化されます。

チケットの種類

チケットには、チケットがどのように使用されるかを決めるプロパティがあります。これらのプロパティは、チケットの作成時にチケットに割り当てられます。ただし、チケットのプロパティはあとから変更できます。たとえば、チケットのプロパティを「転送可能」から「転送済み」に変更できます。チケットのプロパティを表示するには、klist コマンドを使用します (チケットを表示する方法を参照)。

チケットは、次の 1 つまたは複数のプロパティで表されます。

転送可能 / 転送済み

転送可能チケットはホストからホストに転送されます。これによって、クライアントは再び認証を受ける必要がありません。たとえば、ユーザー david がユーザー jennifer のマシンで転送可能チケットを取得した場合、david は自分のマシンにログインするときに新しいチケットを取得する必要はありません (再び認証を受けることもありません)。転送可能チケットの例については、例 — チケットを作成するを参照してください。

初期

初期チケットは、チケット認可チケットを使わずに直接発行されるチケットです。パスワードを変更するアプリケーションなどの一部のサービスでは、クライアントが非公開鍵を知っていることを確認するために、「初期」と指定されたチケットを要求することができます。初期チケットは、チケット認可チケットを使用せずに、クライアントが最近認証されたことを証明します。チケット認可チケットの場合は、認証されてから時間が経っている可能性があります。

無効

無効チケットは、まだ使用可能になっていない遅延チケットです。無効チケットは、有効になるまでアプリケーションサーバーから拒否されます。これを有効にするには、開始時期が過ぎたあと、TGS 要求で VALIDATE フラグをオンにしてクライアントがこのチケットを KDC に提示する必要があります。

遅延可能 / 遅延

遅延チケットは、作成されても指定された時期まで有効にならないチケットです。たとえばこのようなチケットは、夜遅く実行するバッチジョブに使用するのに便利です。チケットが盗まれてもバッチジョブが実行されるまで使用できないためです。「遅延」チケットは「無効」チケットとして発行されます。開始時期がきてクライアントが KDC から検証を受けるまでは、無効チケットのままです。遅延チケットは通常、チケット認可チケットの有効期限まで有効です。ただし、チケットに「更新可能」が指定されている場合、その有効期限は通常、チケット認可チケットの有効期限に設定されます。

プロキシ可能 / プロキシ

場合によっては、サービスがそれ自身のために操作できることが主体にとって必要な場合があります。たとえば、主体がサービスを要求して、サーバーとクライアント以外のホストで印刷ジョブを実行するとします。サービスにはクライアントの ID を使用する権限が必要になりますが、その権限はこの操作だけに制限する必要があります。その場合、サービスは、クライアントの「プロキシ」として動作するといいます。チケットを作成するときには、プロキシの主体名を指定する必要があります。

「プロキシ可能」チケットは「転送可能」チケットに似ていますが、プロキシ可能チケットが 1 つのサービスに対してだけ有効であることに対し、転送可能チケットはサービスに対しクライアントの識別情報の完全な使用を許可します。したがって、転送可能チケットは一種のスーパープロキシと考えられます。

更新可能

チケットに非常に長い有効期限を与えるとセキュリティを損なうおそれがあるため、チケットを「更新可能」にすることができます。更新可能チケットには 2 つの有効期限があります。1 つはチケットの現在のインスタンスの有効期限で、もう 1 つは任意のチケットの最長有効期限です。クライアントがチケットの使用を継続したいときは、最初の有効期限が切れる前にチケットの有効期限を更新します。たとえば、すべてのチケットの最長有効期限が 10 時間のときに、あるチケットが 1 時間だけ有効だとします。このチケットを保持するクライアントが 1 時間を超えて使用したい場合は、その時間内にチケットの有効期限を更新する必要があります。チケットが最長有効期限 (10 時間) に達すると、チケットの有効期限が自動的に切れ、それ以上更新できなくなります。

チケットを表示してその属性を見る方法については、チケットを表示する方法を参照してください。

チケットの有効期限

主体がチケットを取得すると、チケット認可チケットであっても、チケットの有効期限は次の中で最も小さい値に設定されます。

kinit を使用してチケットを取得する場合、kinit の -l オプションに指定した有効期限値
kdc.conf ファイルで指定される最長有効期限値 (max_life)
チケットを提供するサービス主体に対し Kerberos データベースに指定されている最長有効期限値。 kinit の場合、サービス主体は krbtgt/realm
チケットを要求するユーザー主体に対し Kerberos データベースに指定されている最長有効期限値

図 19–1 は、TGT の有効期限の決定方法と 4 つの有効期限値の指定元を示しています。この図は TGT の有効期限がどのようにして決まるかを示しますが、基本的には、どの主体がチケットを取得する場合でも同じです。違いは、kinit で有効期限値を指定しないことと、krbtgt/realm 主体の代わりに、チケットを提供するサービス主体が最長有効期限値を提供することです。

図 19–1 TGT の有効期限の決定方法

kinit コマンド、ユーザー主体、サイトデフォルト、チケット認可者のどれかによって与えられる最小値が、チケットの有効期限となります。

「更新可能」チケットの有効期限も次の 4 つの最小値で決まります。ただし、この場合は更新可能有効期限が使用されます。

kinit を使用してチケットを取得または更新する場合、kinit の -r オプションに指定した更新可能有効期限値
kdc.conf ファイルに指定された更新可能最長有効期限値 (max_renewable_life)
チケットを提供するサービス主体に対し Kerberos データベースに指定されている更新可能最長有効期限値。 kinit の場合、サービス主体は krbtgt/realm
チケットを要求するユーザー主体に対し Kerberos データベースに指定されている更新可能最長有効期限値

主体名

チケットは主体名で識別され、主体名はユーザーやサービスを識別します。次の表に主体名の例を示します。

表 19–4 主体名の例


主体名	説明
`root/boston.example.com@EXAMPLE.COM`	NFS クライアントの `root` アカウントに関連付けられた主体。`root` 主体と呼ばれ、認証された NFS マウントを正常終了する場合に必要
`host/boston.example.com@EXAMPLE.COM`	ネットワークアプリケーションサーバー (`ftpd` や `telnetd` など) によって使用される主体。この主体は、`pam_krb5` 認証モジュールでも使用される。この主体は `host` またはサービス主体と呼ばれる
`username@EXAMPLE.COM`	ユーザー用の主体
`username/admin@EXAMPLE.COM`	KDC データベースを管理するために使用できる `admin` 主体
`nfs/boston.example.com@EXAMPLE.COM`	NFS サービスによって使用される主体。この主体は `host` 主体の代わりに使用できる
`K/M@EXAMPLE.COM`	マスター鍵名の主体。各マスター KDC には、1 つのマスター鍵名の主体が関連付けられる
`kadmin/history@EXAMPLE.COM`	この主体に含まれる鍵を使用して、ほかの主体のパスワード履歴が保管される。各マスター KDC には、これらの主体のいずれかが割り当てられる
`kadmin/kdc1.example.com@EXAMPLE.COM`	`kadmind` を使用して KDC にアクセスできるマスター KDC サーバーの主体
`changepw/kdc1.example.com@EXAMPLE.COM`	パスワードを変更するときに、KDC にアクセスできるマスター KDC の主体
`krbtgt/EXAMPLE.COM@EXAMPLE.COM`	この主体を使用して、チケット認可チケットを生成する

認証システムの動作方法

アプリケーションを使用してリモートシステムにログインするには、識別情報を証明するチケットとそれに対応するセッション鍵を指定する必要があります。セッション鍵には、ユーザーやアクセスするサービスに特有の情報が含まれています。ユーザーすべてのチケットとセッション鍵は、ユーザーが最初にログインするときに KDC によって作成されます。チケットとそれに対応するセッション鍵が 1 つの資格となります。複数のネットワークサービスを使用する場合には、ユーザーは多数の資格を収集できます。ユーザーは特定のサーバーで動作するサービスごとに 1 つの資格を必要とします。たとえば、boston というサーバー上の ftp サービスにアクセスするには 1 つの資格が必要です。別のサーバー上の ftp サービスにアクセスするには、別の資格が必要です。

資格の作成や格納は透過的に行われます。資格は KDC によって作成され、要求者に送信されます。資格は、受信されると資格キャッシュに格納されます。

SEAM によるサービスへのアクセス

特定のサーバー上の特定のサービスにアクセスする場合、ユーザーは 2 つの資格を取得する必要があります。最初は TGT として知られるチケット認可サービスに対する資格です。チケット認可サービスは、この資格の暗号を解除すると、ユーザーからアクセスを要求されているサーバーの資格をさらに作成します。ユーザーは、この 2 つめの資格を使用してサーバー上のサービスへのアクセスを要求します。サーバーがこの資格の暗号を解除すると、ユーザーはアクセスを許可されます。次の節では、このプロセスを詳細に説明します。

チケット許可サービスに対する資格の取得

認証処理を開始するために、クライアントが特定のユーザー主体の要求を認証サーバーに送信します。この要求の送信では暗号は使用されません。要求にはセキュリティにかかわる情報が含まれていないため、暗号を使う必要はありません。
認証サービスは要求を受信すると、ユーザーの主体名を KDC データベースから検索します。一致する主体が見つかると、認証サービスはその主体の非公開鍵を取得します。次に認証サービスは、クライアントとチケット許可サービスが使用するセッション鍵 (セッション鍵 1) とチケット許可サービス用のチケット (チケット 1) を生成します。このチケットはチケット認可チケット (TGT) ともいいます。セッション鍵とチケットはユーザーの非公開鍵を使って暗号化され、情報がクライアントに返送されます。
クライアントは、ユーザー主体の非公開鍵を使用して、この情報からセッション鍵 1 とチケット１の暗号を解除します。非公開鍵を知っているのはユーザーと KDC データベースだけである必要があるため、パケットの情報は安全に保たれなければなりません。クライアントはこの情報を資格キャッシュに格納します。

この処理中に、ユーザーは通常、パスワードを要求されます。非公開鍵を作成するために KDC データベースから取り出されたパスワードが、入力したパスワードと同じであると、認証サービスから送信された情報は正しく復号化されます。これでクライアントは、チケット許可サービスに対して使用する資格を取得します。次にクライアントはサーバーに対する資格を要求します。

図 19–2 チケット許可サービスに対する資格の取得

クライアントは、サーバーへアクセスする資格を KDC に要求し、受け取った資格をパスワードで復号化します。

サーバーに対する資格の取得

特定のサーバーにアクセスするには、クライアントがその前にサーバーに対する資格を認証サービスから取得している必要があります。チケット許可サービスに対する資格の取得を参照してください。次にクライアントは、チケット許可サービスに要求を送信します。この要求には、サービス主体名、チケット 1 およびセッション鍵 1 で暗号化されたオーセンティケータが含まれています。チケット 1 は、チケット許可サービスのサービス鍵を使用して認証サービスによって暗号化されたものです。
チケット許可サービスはチケット許可サービスのサービス鍵を知っているため、チケット 1 の暗号を解除できます。チケット 1 の情報にはセッション鍵 1 が含まれているため、チケット許可サービスはオーセンティケータの暗号を解除できます。この時点で、ユーザー主体はチケット許可サービスによって認証されます。
認証が正常に終了すると、チケット許可サービスは、ユーザー主体とサーバーに対するセッション鍵 (セッション鍵 2) とサーバーに対するチケット (チケット 2) を生成します。次にセッション鍵 2 とチケット 2 はセッション鍵 1 を使って暗号化されます。セッション鍵 1 を知っているのはクライアントとチケット許可サービスだけであるため、この情報は安全であり、ネットワークを介して安全に送信されます。
クライアントはこの情報パケットを受信すると、前に資格キャッシュに格納したセッション鍵 1 を使用して情報を復号化します。クライアントは、サーバーに対して使用する資格を取得したことになります。次にクライアントは、そのサーバーの特定のサービスにアクセスする要求を行います。

図 19–3 サーバーに対する資格の取得

クライアントは、まずセッション鍵 1 で暗号化した要求を KDC に送信し、次に受け取った資格を同じセッション鍵で復号化します。

特定のサービスへのアクセス権の取得

クライアントが特定のサービスへのアクセスを要求するには、まず認証サーバーからチケット許可サービスに対する資格を取得し、チケット許可サービスからサーバー資格を取得する必要があります。チケット許可サービスに対する資格の取得およびサーバーに対する資格の取得を参照してください。クライアントは、チケット 2 と別のオーセンティケータを含む要求をサーバーに送信します。オーセンティケータはセッション鍵 2 を使用して暗号化されます。
チケット 2 は、サービスのサービス鍵を使用してチケット許可サービスによって暗号化されています。サービス鍵はサービス主体が知っているため、サービスはチケット 2 を復号化し、セッション鍵 2 を取得できます。次に、セッション鍵 2 を使用してオーセンティケータが復号化されます。オーセンティケータが正しく復号化されると、サービスへのアクセスがクライアントに許可されます。

図 19–4 特定のサービスへのアクセス権の取得

クライアントは、チケット 2 と、セッション鍵 2 で暗号化されたオーセンティケータとを使用して、サーバーへのアクセス権を取得します。

`gsscred` テーブルの使用

gsscred テーブルは、NFS サーバーが SEAM ユーザーを識別するときに使用します。NFS サービスは、UNIX ID を使用してユーザーを識別します。UNIX ID は、ユーザー主体または資格には含まれません。gsscred テーブルは、パスワードファイルから得られる UNIX ID と主体名を割り当てるテーブルです。このテーブルは、KDC データベースを生成したあとに作成および開始する必要があります。

クライアントの要求が到着すると、NFS サービスは主体名を UNIX ID に割り当てようとします。この割り当てに失敗した場合、gsscred テーブルが参照されます。kerberos_v5 メカニズムでは、root/hostname 主体は自動的に UID 0 に割り当てられるため、gsscred テーブルは参照されません。したがって、gsscred テーブルを使用して root を特別な UID に割り当てることはできません。

パート III 認証サービスと安全な通信

第 9 章 認証サービスの使用 (手順)

Secure RPC の概要

NFS サービスと Secure RPC

DES 暗号化

Kerberos 認証

Diffie-Hellman 認証

Diffie-Hellman 認証の実装

公開鍵と秘密鍵の生成

keylogin コマンドの実行

対話鍵の生成

サーバーとの最初の接触

対話鍵の復号化

サーバーへの格納情報

ベリファイアをクライントに返す

クライアントによるサーバーの認証

追加のトランザクション

Diffie-Hellman 認証の管理

キーサーバーを再起動する方法

Diffie-Hellman 認証のために NIS+ の資格に root 鍵を設定する方法

例 — NIS+ クライアント上で root の新しい鍵を設定する

Diffie-Hellman 認証のために NIS+ の資格を使用する新しいユーザー鍵を設定する方法

例 — NIS+ ユーザー用の新しい鍵を設定する

Diffie-Hellman 認証と NIS の資格を使用して root 鍵を設定する方法

例 — NIS クライアント上で root の新しい鍵を設定する

Diffie-Hellman 認証と NIS の資格を使用する新しいユーザー鍵を設定する方法

Diffie-Hellman 認証でファイルを共有およびマウントする方法

前提条件

Diffie-Hellman 認証でファイルシステムを共有する

Diffie-Hellman 認証でファイルシステムをマウントする

第 10 章 PAM の使用

PAM (概要)

PAM を使用する利点

PAM の構成要素

図 10–1 PAM の動作

PAM ライブラリ

パスワードマッピング機能

Solaris 9 リリースにおける PAM への変更

Solaris 9 Update 2 リリースにおける PAM への変更

PAM (手順)

PAM (作業マップ)

PAM の計画

PAM モジュールを追加する方法

検証

PAM を使用して、リモートシステムからの非承認アクセスを防ぐ方法

PAM のエラーレポートを開始する方法

例 — PAM のエラーレポートを開始する

PAM (参照)

PAM モジュール

PAM モジュールのタイプ

PAM 構成ファイル

PAM 構成ファイルの構文

PAM で有効なサービス名

PAM 制御フラグ

一般的な pam.conf ファイル

第 11 章 Solaris Secure Shell の使用 (手順)

Solaris Secure Shell の概要

Solaris Secure Shell の使用 (作業マップ)

Solaris Secure Shell の使用

公開鍵と非公開鍵のペアを作成する方法

Solaris Secure Shell を使用して別のホストにログインする方法

パスワードを使用せずに ssh-agent コマンドを使用してログインする方法

例 — ssh-add オプションを使用する

ssh-agent コマンドが自動的に動作するように設定する方法

Solaris Secure Shell のポート転送を使用する方法

例 — ローカルポート転送を使用してメールを受信する

図 11–1 電子メールに使用するポート転送を指定する

例 — リモートポート転送を使用してファイアウォールの外部と通信する

Solaris Secure Shell を使用してファイルをコピーする方法

sftp コマンドを使用したファイルのリモート転送

ファイアウォール外部のホストにデフォルト接続を設定する方法

例 — コマンド行からファイアウォール外部のホストに接続する

第 12 章 Solaris Secure Shell の管理 (参照)

標準的な Solaris Secure Shell セッション

セッションの特性

認証

コマンドの実行とデータの転送

Solaris Secure Shell を構成する

Solaris Secure Shell クライアントの構成

ホスト固有のパラメータ

第 9 章認証サービスの使用 (手順)

`keylogin` コマンドの実行

Diffie-Hellman 認証のために NIS+ の資格に `root` 鍵を設定する方法

例 — NIS+ クライアント上で `root` の新しい鍵を設定する

Diffie-Hellman 認証と NIS の資格を使用して `root` 鍵を設定する方法

例 — NIS クライアント上で `root` の新しい鍵を設定する

一般的な `pam.conf` ファイル

パスワードを使用せずに `ssh-agent` コマンドを使用してログインする方法

例 — `ssh-add` オプションを使用する

`ssh-agent` コマンドが自動的に動作するように設定する方法

`sftp` コマンドを使用したファイルのリモート転送

NFS ファイルシステムをマウントするように `root` 認証を設定する