test

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

パート VI Kerberos サービス

このパートでは、Kerberos サービスの構成、管理、および使用方法について説明します。

第 21 章 Kerberos サービスについて

この章では、Kerberos サービスについて説明します。この章の内容は次のとおりです。

Kerberos サービスとは

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

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

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

Kerberos サービスには、Solaris アプリケーションを実行するための柔軟性が備わっています。NFS サービス、telnet、ftp などのネットワークサービスに関して、Kerberos に基づく要求と Kerberos 以外の要求に対応できるようにサービスを構成できます。このため、Kerberos サービスが有効になっていないシステムで動作する Solaris アプリケーションも正しく動作します。もちろん、Kerberos に基づくネットワーク要求だけを許可するように Kerberos サービスを設定することもできます。

Kerberos サービスは、Generic Security Service Application Programming Interface (GSS-API) を使用するアプリケーションの使用時に、認証、整合性、およびプライバシのために Kerberos を使用することができるセキュリティーメカニズムを備えています。ただし、ほかのセキュリティーメカニズムが開発されている場合には、アプリケーションで使用されるセキュリティーメカニズムを Kerberos サービスに限定しておく必要はありません。Kerberos サービスは、GSS-API にモジュールとして統合できるように設計されているため、GSS-API を使用するアプリケーションは、必要に応じたセキュリティーメカニズムを使用できます。

Kerberos サービスの動作

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

Kerberos セッションが起動されたあとは、ユーザーから見ると Kerberos サービスが意識されることはほとんどありません。rsh や ftp などのコマンドは、ほぼ変わりなく動作します。Kerberos セッションの初期化には通常、ログインと Kerberos パスワードの入力しか必要ありません。

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

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

注 –

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

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

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

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

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

図 21–1 Kerberos セッションの初期認証

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

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

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

    チケット認可チケットに類似した例として、4 つのスキー場で使える 3 日間のスキーパスを挙げます。ユーザーは、パスが期限切れになるまで、このパスを任意のスキー場で提示して、そのスキー場のリフトチケットを受け取ります。リフトチケットを入手したら、そのスキー場で好きなだけスキーをすることができます。翌日別のスキー場に行った場合は、またパスを提示して、そのスキー場のリフトチケットを入手します。ただし、Kerberos に基づくコマンドは、ユーザーが週末スキーパスを所有していることをユーザーに通知し、ユーザーに代わってリフトチケットを入手します。したがって、ユーザー自身がトランザクションを実行する必要はありません。

  2. KDC は TGT を作成し、それを暗号化してクライアントに送信します。クライアントは、自身のパスワードを使用して TGT を復号化します。

  3. クライアントは、有効な TGT を入手したので、TGT が期限切れになるまで、rlogin、telnet などあらゆる種類のネットワーク操作チケットを要求できます。この TGT の有効期限は通常、数時間です。クライアントは一意のネットワーク操作を実行するたびに、TGT は KDC にその操作のチケットを要求します。

初期認証後の Kerberos 認証

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

図 21–2 Kerberos 認証を使用してサービスへのアクセスを取得する

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

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

  2. KDC は、そのサービスのチケットをクライアントに送信します。

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

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

  3. クライアントはサーバーにチケットを送信します。

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

  4. サーバーはクライアントにアクセス権を許可します。

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

Kerberos 遠隔アプリケーション

joe などのユーザーは、次の Kerberos に基づく (Kerberos 化された) コマンドを使用できます。

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

これらのコマンドについては、「Kerberos ユーザーコマンド」で詳しく説明します。

Kerberos 主体

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

主体名は慣習により「一次」、「インスタンス」、「レルム」という 3 つの部分から なります。joe/admin@ENG.EXAMPLE.COM は一般的な Kerberos 主体の例です。上記の例では、

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

Kerberos レルム

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

図 21–3 Kerberos レルム

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

Kerberos サーバー

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

レルムにはまた、Kerberos アプリケーションサーバー も含めることができます。このサーバーは、Kerberos サービス (ftp、telnet、rsh、NFS など) へのアクセスを提供します。SEAM 1.0 または 1.0.1 がインストールされている場合、レルムに Kerberos ネットワークアプリケーションサーバーが含まれている可能性がありますが、このソフトウェアはこれらのリリースには含まれていませんでした。

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

図 21–4 一般的な Kerberos レルム

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

Kerberos セキュリティーサービス

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

開発者は、RPCSEC_GSS プログラミングインタフェースを使用することにより、セキュリティーサービスを選択可能な RPC ベースのアプリケーションを設計できます。

複数の Kerberos リリースの構成要素

Kerberos サービスの構成要素は、多数のリリースに組み込まれています。当初、Kerberos サービスと、Kerberos サービスをサポートするベースオペレーティングシステムへの変更は、“Sun Enterprise Authentication Mechanism” (SEAM) という製品名でリリースされました。SEAM 製品の大部分が Solaris ソフトウェアに組み込まれるようになると、SEAM リリースの内容は減りました。Solaris 10 リリースで、SEAM 製品のすべての構成要素が組み込まれたので、SEAM 製品の必要性はなくなりました。SEAM という製品名は、歴史的な理由で文書中に存在しています。

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

表 21–1 Kerberos リリースの内容

リリース名 

内容 

Solaris Easy Access Server 3.0 の SEAM 1.0 

Solaris 2.6 および Solaris 7 用の Kerberos サービスの完全リリース 

Solaris 8 の Kerberos サービス 

Kerberos クライアントソフトウェアのみ 

Solaris 8 Admin Pack の SEAM 1.0.1 

Solaris 8 用の Kerberos KDC と遠隔アプリケーション 

Solaris 9 の Kerberos サービス 

Kerberos KDC とクライアントソフトウェアのみ 

SEAM 1.0.2 

Solaris 9 用の Kerberos 遠隔アプリケーション 

Solaris 10 の Kerberos サービス 

機能が拡張された Kerberos サービスの完全リリース 

Kerberos の構成要素

MIT から提供される Kerberos V5 製品と同様に、Solaris Kerberos サービスには次の構成要素が含まれます。

さらに、Solaris Kerberos サービスには次の構成要素が含まれています。

Solaris 10 5/08 リリースでの Kerberos の追加機能

Solaris 10 5/08 リリースから、次のような拡張機能が使用できます。

Solaris 10 8/07 リリースでの Kerberos の追加機能

Solaris 10 8/07 リリースでは、MIT Kerberos V5 アプリケーションプログラミングインタフェース (krb5-api) がサポートされています。詳細は、libkrb5(3LIB) および krb5-config(1) のマニュアルページを参照してください。また、mit.edu にある MIT Kerberos V5 プロジェクトの Web ページも参照し、詳細ドキュメントが利用可能になった時点でそれらを入手してください。

krb5-api が使用可能になりましたが、GSS-API は独立したセキュリティーメカニズムであり、IETF 標準でもあるため、GSS-API を使ってネットワークの認証、完全性、プライバシを実現することを強くお勧めします。詳細は、libgss(3LIB) のマニュアルページを参照してください。

Solaris 10 6/06 リリースでの Kerberos の追加機能

Solaris 10 6/06 リリースから、ktkt_warnd デーモンは、資格の有効期限が近づいてきたとき、ユーザーに警告するだけでなく、資格を自動的に更新するようになりました。資格を自動的に更新するには、ユーザーがログインしている必要があります。

Solaris 10 3/05 リリースでの Kerberos の拡張機能

Solaris 10 リリースに含まれる Kerberos の機能拡張は、次のとおりです。そのうちのいくつかは、以前の Software Express リリースで採用され、Solaris 10 Beta リリースで更新されたものです。

Solaris 9 の Kerberos 構成要素

Solaris 9 には、遠隔アプリケーションを除いて、「Kerberos の構成要素」の構成要素がすべて含まれています。

SEAM 1.0.2 の構成要素

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

Solaris 8 の Kerberos 構成要素

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

SEAM 1.0.1 の構成要素

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

SEAM 1.0 の構成要素

SEAM 1.0 リリースには、「Kerberos の構成要素」のすべての項目のほか、次の項目が含まれています。

第 22 章 Kerberos サービスの計画

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

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

Kerberos の配備を計画する理由

Kerberos サービスをインストールする前に、いくつかの構成についての問題を解決する必要があります。初期インストール後に構成を変更することは不可能ではありませんが、変更によっては実装が困難な場合があります。また、変更によっては、KDCを再構築しなければならないことがあります。このため、Kerberos の構成を計画するときは、長期的な目標を考慮することをお勧めします。

Kerberos の基盤の配備には、KDC のインストール、ホストの鍵の作成、ユーザーの移行などの作業が含まれます。Kerberos の配備の再構成は最初の配備と同じくらいの労力を要するので、入念に計画し、再構成しなければならない事態を避けるようにしてください。

Kerberos レルムの計画

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

レルム名

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

レルムの数

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

Kerberos レルムと管理ドメインがそろっているようにすることをお勧めします。Kerberos V レルムは、対応する DNS ドメインの複数のサブドメインにまたがることができます。

レルムの階層

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

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

ホスト名のレルムへのマッピング

ホスト名のレルム名へのマッピングは、krb5.conf ファイルの domain_realm セクションに定義します。これらのマッピングは、必要に応じてドメイン全体およびホスト単位に定義できます。

DNS は、KDC に関する情報の検索にも使用できます。DNS を使用すると、変更を行うたびに全クライアントについて krb5.conf ファイルを編集する必要がないため、情報を変更しやすくなります。詳細は、krb5.conf(4) のマニュアルページを参照してください。

Solaris Express Developer Edition 1/08 および Solaris 10 5/08 リリースの時点で、Solaris Kerberos クライアントは Active Directory サーバーとより適切に相互運用できるようになりました。Active Directory サーバーは、ホストのマッピングにレルムを提供するように構成できます。

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

Kerberos サービスを使用しているときは、すべてのホストで DNS が有効である必要があります。DNS では、主体名に各ホストの完全指定のドメイン名 (FQDN) を含める必要があります。たとえば、ホスト名が boston、DNS ドメイン名が example.com、およびレルム名が EXAMPLE.COM の場合、ホストの主体名は host/boston.example.com@EXAMPLE.COM にするようにしてください。このマニュアルの例では、DNS を構成する必要があり、各ホストの FQDN を使用しています。

Kerberos サービスは DNS を介してホストの別名を正規化し、関連するサービスのサービス主体を構築する際には正規化された形式 (正規名) を使用します。そのため、サービス主体を作成する場合、サービス主体名のホスト名コンポーネントは、サービスをホストするシステムのホスト名の正規化形式にする必要があります。

次の例では、Kerberos サービスでホスト名を正規化する方法を示します。ユーザーがコマンド「ssh alpha.example.com」を実行するとします。ここで、alpha.example.com は正規名 beta.example.com の DNS ホストの別名です。ssh が Kerberos を呼び出し、alpha.example.com のホストサービスチケットを要求する場合、Kerberos サービスは、alpha.example.com を beta.example.com に正規化し、KDC からサービス主体「host/beta.example.com」のチケットを要求します。

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

また、サービス管理機能は、DNS クライアントサービスが実行されていない場合に多くのデーモンまたはコマンドが起動しないように構成されています。kdb5_util、kadmind、kpropd デーモン、および kprop コマンドは、DNS サービスに依存するように構成されています。Kerberos サービスおよび SMF を使用して利用可能な機能を完全に活用するには、すべてのホスト上で DNS クライアントサービスを有効にする必要があります。

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 データベースのコピーが保存されるため、スレーブが多くなるほど、セキュリティー侵害の危険性が高くなります。

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

GSS 資格の UNIX 資格へのマッピング

Kerberos サービスは、GSS 資格名から UNIX ユーザー ID (UID) へのマッピングを、NFS などこのマッピングを必要とする GSS アプリケーションのために提供します。GSS 資格名は Kerberos サービスを使用する場合の Kerberos 主体名と等価です。デフォルトのマッピングアルゴリズムでは、1 構成要素の Kerberos 主体名をとり、主体の一次名であるその構成要素を使用して、UID を検索します。検索は、デフォルトレルム、または /etc/krb5/krb5.conf の auth_to_local_realm パラメータを使用することで許可された任意のレルムで行われます。たとえば、ユーザー主体名 bob@EXAMPLE.COM は、パスワードテーブルを使用して、bob という名前の UNIX ユーザーの UID にマッピングされます。主体名が admin のインスタンスコンポーネントを含むため、ユーザー主体名 bob/admin@EXAMPLE.COM はマッピングされません。ユーザー資格のデフォルトマッピングが十分な場合、GSS 資格テーブルにデータを入れておく必要がありません。以前のリリースでは、NFS サービスを機能させるために、GSS 資格テーブルにデータを入れておく必要がありました。デフォルトマッピングでは十分でない場合、たとえばインスタンスコンポーネントを含む主体名をマッピングする場合などは、そのほかの方法を使用すべきです。詳細については、次のトピックを参照してください。

Kerberos レルムへのユーザーの自動的な移行

PAM フレームワークを使用して、デフォルトの Kerberos レルムに有効なユーザーアカウントを持たない UNIX ユーザーを自動的に移行することができます。具体的には、pam_krb5_migrate モジュールを PAM サービスの認証スタックで使用します。Kerberos 主体を持たないユーザーがパスワードを使用してシステムへのログインを行うたびに、そのユーザーに対して Kerberos 主体が自動的に作成されるように、サービスを設定します。新しい主体パスワードは UNIX パスワードと同じにします。pam_krb5_migrate モジュールの使用方法については、「Kerberos レルム内のユーザーを自動的に移行するように構成する方法」を参照してください。

使用するデータベースの伝播システム

マスター KDC に格納されているデータベースは、定期的にスレーブ KDC に伝播する必要があります。データベースの伝播は増分的に構成することができます。増分処理によって、データベース全体ではなく、更新された情報だけがスレーブ KDC に伝播されます。データベースの伝播の詳細については、「Kerberos データベースの管理」を参照してください。

増分伝播を使用しない場合、最初に解決すべき問題の 1 つは、スレーブ KDC の更新頻度です。すべてのクライアントが最新の情報を使用できるようにしておく必要性について、更新の完了にかかる時間と比較検討する必要があります。

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

レルム内でのクロックの同期

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

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

クライアントの構成オプション

Solaris 10 の新機能の 1 つに、kclient 設定ユーティリティーがあります。このユーティリティーは、対話型モードまたは非対話型モードで実行できます。対話型モードでは、ユーザーは、Kerberos 固有のパラメータ値を要求されます。このパラメータ値によって、クライアントの設定時に既存のインストールを変更することができます。非対話型モードでは、前もってパラメータ値が設定されたファイルが使用されます。また、非対話型モードではコマンド行オプションも使用できます。対話型モードでも非対話型モードでも手動の処理よりも手順が少なくてすむので、プロセスが迅速化され、ミスが起こりにくくなります。

Solaris 10 5/08 リリースでは、構成不要の Kerberos クライアントが可能になるように変更されました。環境内で次の規則に従うと、Solaris Kerberos クライアントには明示的な構成手順が必要なくなります。

場合によっては、Kerberos クライアントを明示的に構成する方がよいことがあります。

クライアントの設定プロセス全体の詳細については、「Kerberos クライアントの構成」を参照してください。

クライアントログインのセキュリティーの改善

Solaris 10 11/06 リリースでは、クライアントのログイン時に pam_krb5 モジュールを使用して、最新の TGT を発行した KDC と /etc/krb5/krb5.keytab に保存されているクライアントのホスト主体を発行した KDC が同じであることを確認します。pam_krb5 モジュールは、認証スタックで構成されるときに KDC を確認します。クライアントのホスト主体を保存しない DHCP クライアントなど、一部の構成ではこの確認を無効にする必要があります。この確認をオフに設定するには、krb5.conf ファイルの verify_ap_req_nofail オプションを false に設定する必要があります。詳細は、「チケット認可チケット (TGT) の確認を無効にする方法」を参照してください。

KDC の構成オプション

Solaris 10 5/08 リリースからは、LDAP を使用して Kerberos のデータベースファイルを管理する機能のサポートが追加されました。手順については、「LDAP データサーバーを使用するように KDC を構成する方法」を参照してください。LDAP を使用すると、Solaris Kerberos データベースと既存の DS セットアップをより適切に調整する必要があるサイトの管理が簡略化されます。

Kerberos の暗号化タイプ

暗号化タイプとは、Kerberos サービスで使用される、暗号化アルゴリズム、暗号化モード、およびハッシュアルゴリズムを特定する識別子です。Kerberos サービスの鍵は、暗号化タイプに関連付けられ、サービスが鍵を使って暗号化処理を行うときに使用される暗号化アルゴリズムと暗号化モードを特定します。サポートされる暗号化タイプは次のとおりです。

注 –

Solaris 10 8/07 より前のリリースでは、別売の Strong Cryptographic パッケージがインストールされている場合は、Kerberos サービスで aes256-cts-hmac-sha1-96 暗号化タイプを使用できます。

暗号化タイプを変更する場合は、新しい主体データベースの作成時に行います。KDC、サーバー、クライアント間の相互作用のために、既存のデータベースでの暗号化タイプの変更は困難です。データベースを再作成しない場合は、これらのパラメータは設定しないでおいてください。詳細については、「Kerberos 暗号化タイプの使用」を参照してください。

注 –

Solaris 10 が動作していないマスター KDC がインストールされている場合は、マスター KDC をアップグレードする前に、スレーブ KDC を Solaris 10 にアップグレードする必要があります。Solaris 10 のマスター KDC では、古いスレーブが処理できない新しい暗号化タイプが使用されます。

Kerberos グラフィカル管理ツールでのオンラインヘルプ URL

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

URL は、Kerberos サービスを使用するようにホストを構成するときに krb5.conf ファイルで指定します。URL には、このマニュアルの「主体とポリシーの管理 (手順)」の「グラフィカルな Kerberos 管理ツール」を指定してください。必要に応じて、別の HTML ページを選択することもできます。

第 23 章 Kerberos サービスの構成 (手順)

この章では、KDC サーバー、ネットワークアプリケーションサーバー、NFS サーバー、および Kerberos クライアントの構成手順について説明します。手順の多くはスーパーユーザーアクセスを必要とするため、この作業はシステム管理者や上級ユーザーが行なってください。レルム間の構成手順など、KDC サーバーに関するトピックについても説明します。

この章の内容は次のとおりです。

Kerberos サービスの構成 (作業マップ)

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

作業 

説明 

参照先 

1. Kerberos インストールを計画します。 

ソフトウェア構成処理を開始する前に、構成についての問題を解決します。事前に計画することで、結果的に時間やその他のリソースを節約できます。 

第 22 章Kerberos サービスの計画

2. (省略可能) NTP をインストールします。 

NTP ソフトウェアなどのクロック同期プロトコルを構成します。Kerberos サービスが正常に動作するには、レルムに含まれるすべてのシステムのクロックを同期化する必要があります。 

「KDC と Kerberos クライアントのクロックの同期化」

3. KDC サーバーを構成します。 

レルムにマスター KDC サーバー、スレーブ KDC サーバー、および KDC データベースを構成および構築します。 

「KDC サーバーの構成」

4. (省略可能) KDC のセキュリティーを強化します。 

KDC サーバーに対するセキュリティー侵害を回避します。 

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

5. (省略可能) 入れ替え可能な KDC を構成します。 

マスター KDC とスレーブ KDC を簡単に入れ替えできるようにします。 

「入れ替え可能なスレーブ KDC を構成する方法」

追加の Kerberos サービスの構成 (作業マップ)

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

作業 

説明 

参照先 

レルム間認証を構成します。 

レルム間の通信を使用可能にします。 

「レルム間認証の構成」

Kerberos アプリケーションサーバーを構成します。 

サーバーが ftp、telnet、rsh などのサービスを Kerberos 認証を使ってサポートできるようにします。

「Kerberos ネットワークアプリケーションサーバーの構成」

Kerberos クライアントを構成します。 

クライアントが Kerberos サービスを使用できるようにします。 

「Kerberos クライアントの構成」

Kerberos NFS サーバーを構成します。 

Kerberos 認証を必要とするファイルシステムを、サーバーが共有できるようにします。 

「Kerberos NFS サーバーの構成」

アプリケーションサーバーのセキュリティーを強化します。 

認証されたトランザクションのみにアクセスを制限して、アプリケーションサーバーのセキュリティーを強化します。 

「Kerberos アプリケーションのみを有効にする方法」

KDC サーバーの構成

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

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

表 23–1 KDC サーバーの構成 (作業マップ)

作業 

説明 

参照先 

マスター KDC サーバーを構成します。 

より複雑なインストールに必要な手動のプロセスを使用して、レルムにマスター KDC サーバーとデータベースを構成および構築します。 

「マスター KDC を手動で構成する方法」

 

手動のプロセスを使用し、さらに KDC 用に LDAP を使用して、レルムにマスター KDC サーバーとデータベースを構成および構築します。 

「LDAP データサーバーを使用するように KDC を構成する方法」

スレーブ KDC サーバーを構成します。 

より複雑なインストールに必要な手動のプロセスを使用して、レルムにスレーブ KDC サーバーを構成および構築します。 

「スレーブ KDC を手動で構成する方法」

KDC サーバー上の主体鍵を更新します。 

新しい暗号化タイプを使用して KDC サーバー上のセッション鍵を更新します。 

「マスターサーバー上でチケット認可サービス鍵を更新する方法」

Procedureマスター KDC を手動で構成する方法

この手順では、増分伝播を構成します。さらに、次の構成パラメータを使用します。

始める前に

この手順を実行するには、ホストが DNS を使用するように構成されている必要があります。マスター KDC を入れ替え可能にする場合の手順については、「マスター KDC とスレーブ KDC の入れ替え」を参照してください。

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

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

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


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

[realms]
        EXAMPLE.COM = {
        kdc = kdc1.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
        }

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

    注 –

    暗号化タイプを制限する場合は、default_tkt_enctypes または default_tgs_enctypes の行を設定します。暗号化タイプの制限に関する詳細は、「Kerberos 暗号化タイプの使用」を参照してください。

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

    レルム名を変更する必要があります。このファイルの詳細は、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
                sunw_dbprop_enable = true
                sunw_dbprop_master_ulogsize = 1000
                }

    この例では、realms セクションのレルム名定義を変更しました。また、realms セクションで、増分伝播できるようにする行とログ内に保持する KDC マスターの更新数を選択する行を追加しました。

    注 –

    暗号化タイプを制限する場合は、permitted_enctypes、supported_enctypes、または master_key_type の行を設定します。暗号化タイプの制限に関する詳細は、「Kerberos 暗号化タイプの使用」を参照してください。

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

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


    kdc1 # /usr/sbin/kdb5_util create -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: <Type the key>
Re-enter KDC database master key to verify: <Type it again>

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

    作成された /etc/krb5/kadm5.acl ファイルには、KDC を管理できる主体名がすべて含まれている必要があります。


    kws/admin@EXAMPLE.COM   *

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

  6. kadmin.local コマンドを起動し、主体を追加します。

    次の手順では、Kerberos サービスで使用される主体を作成します。


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

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

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


      kadmin.local: addprinc kws/admin
Enter password for principal kws/admin@EXAMPLE.COM:<Type the password>
Re-enter password for principal kws/admin@EXAMPLE.COM: <Type it again>
Principal "kws/admin@EXAMPLE.COM" created.
kadmin.local:

    2. kiprop 主体を作成します。

      kiprop 主体はマスター KDC からの更新の承認に使用されます。


      kadmin.local: addprinc -randkey kiprop/kdc1.example.com
Principal "kiprop/kdc1.example.com@EXAMPLE.COM" created.
kadmin.local:

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

      このコマンドシーケンスは、kadmin/<FQDN> および changepw/<FQDN> の主体エントリを保持する特別なキータブファイルを作成します。これらの主体は、kadmind サービスと、変更されるパスワードに必要です。主体のインスタンスがホスト名のときは、/etc/resolv.conf ファイル内のドメイン名が大文字であるか小文字であるかに関係なく、FQDN は小文字で指定する必要があります。kadmin/changepw 主体は、Solaris リリースが稼働していないクライアントからのパスワードを変更するために使用されます。


      kadmin.local: ktadd -k /etc/krb5/kadm5.keytab kadmin/kdc1.example.com
Entry for principal kadmin/kdc1.example.com with kvno 3, encryption type AES-256 CTS mode
          with 96-bit SHA-1 HMAC added to keytab WRFILE:/etc/krb5/kadm5.keytab.
Entry for principal kadmin/kdc1.example.com with kvno 3, encryption type AES-128 CTS mode
          with 96-bit SHA-1 HMAC added to keytab WRFILE:/etc/krb5/kadm5.keytab.
Entry for principal kadmin/kdc1.example.com with kvno 3, encryption type Triple DES cbc
          mode with HMAC/sha1 added to keytab WRFILE:/etc/krb5/kadm5.keytab.
Entry for principal kadmin/kdc1.example.com with kvno 3, encryption type ArcFour
          with HMAC/md5 added to keytab WRFILE:/etc/krb5/kadm5.keytab.
Entry for principal kadmin/kdc1.example.com with kvno 3, encryption type DES cbc mode
          with RSA-MD5 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 AES-256 CTS mode
          with 96-bit SHA-1 HMAC added to keytab WRFILE:/etc/krb5/kadm5.keytab.
Entry for principal changepw/kdc1.example.com with kvno 3, encryption type AES-128 CTS mode
          with 96-bit SHA-1 HMAC added to keytab WRFILE:/etc/krb5/kadm5.keytab.
Entry for principal changepw/kdc1.example.com with kvno 3, encryption type Triple DES cbc
          mode with HMAC/sha1 added to keytab WRFILE:/etc/krb5/kadm5.keytab.
Entry for principal changepw/kdc1.example.com with kvno 3, encryption type ArcFour
          with HMAC/md5 added to keytab WRFILE:/etc/krb5/kadm5.keytab.
Entry for principal changepw/kdc1.example.com with kvno 3, encryption type DES cbc mode
          with RSA-MD5 added to keytab WRFILE:/etc/krb5/kadm5.keytab.
kadmin.local: ktadd -k /etc/krb5/kadm5.keytab kadmin/changepw
Entry for principal kadmin/changepw with kvno 3, encryption type AES-256 CTS mode
          with 96-bit SHA-1 HMAC added to keytab WRFILE:/etc/krb5/kadm5.keytab.
Entry for principal kadmin/changepw with kvno 3, encryption type AES-128 CTS mode
          with 96-bit SHA-1 HMAC added to keytab WRFILE:/etc/krb5/kadm5.keytab.
Entry for principal kadmin/changepw with kvno 3, encryption type Triple DES cbc
          mode with HMAC/sha1 added to keytab WRFILE:/etc/krb5/kadm5.keytab.
Entry for principal kadmin/changepw with kvno 3, encryption type ArcFour
          with HMAC/md5 added to keytab WRFILE:/etc/krb5/kadm5.keytab.
Entry for principal kadmin/changepw with kvno 3, encryption type DES cbc mode
          with RSA-MD5 added to keytab WRFILE:/etc/krb5/kadm5.keytab.
kadmin.local:

    4. マスター KDC サーバーの kiprop 主体を kadmind キータブファイルに追加します。

      kadm5.keytab ファイルに kiprop 主体を追加すると、増分伝播が開始されるときに、kadmind コマンドが自身を認証できます。


      kadmin.local: ktadd -k /etc/krb5/kadm5.keytab kiprop/kdc1.example.com
Entry for principal kiprop/kdc1.example.com with kvno 3, encryption type AES-256 CTS mode
          with 96-bit SHA-1 HMAC added to keytab WRFILE:/etc/krb5/kadm5.keytab.
Entry for principal kiprop/kdc1.example.com with kvno 3, encryption type AES-128 CTS mode
          with 96-bit SHA-1 HMAC added to keytab WRFILE:/etc/krb5/kadm5.keytab.
Entry for principal kiprop/kdc1.example.com with kvno 3, encryption type Triple DES cbc
          mode with HMAC/sha1 added to keytab WRFILE:/etc/krb5/kadm5.keytab.
Entry for principal kiprop/kdc1.example.com with kvno 3, encryption type ArcFour
          with HMAC/md5 added to keytab WRFILE:/etc/krb5/kadm5.keytab.
Entry for principal kiprop/kdc1.example.com with kvno 3, encryption type DES cbc mode
          with RSA-MD5 added to keytab WRFILE:/etc/krb5/kadm5.keytab.
kadmin.local:

    5. kadmin.local を終了します。

      以降の手順で必要になる主体をすべて追加しました。


      kadmin.local: quit

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


    kdc1 # svcadm enable -r network/security/krb5kdc
kdc1 # svcadm enable -r network/security/kadmin

  8. kadmin を起動して、主体をさらに追加します。

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


    kdc1 # /usr/sbin/kadmin -p kws/admin
Enter password: <Type kws/admin password>
kadmin:

    1. マスター KDC の host 主体を作成します。

      ホスト主体は、変更をスレーブ KDC に伝播するために、kprop などの Kerberos アプリケーションで使用されます。この主体はまた、ssh などのアプリケーションを使用して、KDC サーバーにセキュリティー保護された遠隔アクセスを提供するためにも使用されます。主体のインスタンスがホスト名のときは、/etc/resolv.conf ファイル内のドメイン名が大文字であるか小文字であるかに関係なく、FQDN は小文字で指定する必要があります。


      kadmin: addprinc -randkey host/kdc1.example.com
Principal "host/kdc1.example.com@EXAMPLE.COM" created.
kadmin:

    2. (省略可能) kclient 主体を作成します。

      この主体は、Kerberos クライアントのインストール中に kclient ユーティリティーで使用されます。このユーティリティーを使用しない場合は、主体に追加する必要はありません。kclient ユーティリティーのユーザーは、このパスワードを使用する必要があります。


      kadmin: addprinc clntconfig/admin
Enter password for principal clntconfig/admin@EXAMPLE.COM:<Type the password>
Re-enter password for principal clntconfig/admin@EXAMPLE.COM: <Type it again>
Principal "clntconfig/admin@EXAMPLE.COM" created.
kadmin:

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

      キータブファイルにホスト主体を追加すると、sshd などのアプリケーションサーバーによってこの主体が自動的に使用されるようになります。


      kadmin: ktadd host/kdc1.example.com
Entry for principal host/kdc1.example.com with kvno 3, encryption type AES-256 CTS mode
          with 96-bit SHA-1 HMAC added to keytab WRFILE:/etc/krb5/krb5.keytab.
Entry for principal host/kdc1.example.com with kvno 3, encryption type AES-128 CTS mode
          with 96-bit SHA-1 HMAC added to keytab WRFILE:/etc/krb5/krb5.keytab.
Entry for principal host/kdc1.example.com with kvno 3, encryption type Triple DES cbc
          mode with HMAC/sha1 added to keytab WRFILE:/etc/krb5/krb5.keytab.
Entry for principal host/kdc1.example.com with kvno 3, encryption type ArcFour
          with HMAC/md5 added to keytab WRFILE:/etc/krb5/krb5.keytab.
Entry for principal host/kdc1.example.com with kvno 3, encryption type DES cbc mode
          with RSA-MD5 added to keytab WRFILE:/etc/krb5/krb5.keytab.
kadmin:

    4. kadmin を終了します。


      kadmin: quit

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

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

  10. スレーブ KDC の構成

    冗長性を確保するには、スレーブ KDC を必ず 1 つ以上インストールするようにしてください。 手順については、「スレーブ KDC を手動で構成する方法」を参照してください。

ProcedureLDAP データサーバーを使用するように KDC を構成する方法

Solaris 10 5/08 リリースから、次の手順を使用して、LDAP データサーバーを使用するように KDC を構成できるようになりました。

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

始める前に

この手順を実行する場合も、ホストが DNS を使用するように構成されている必要があります。パフォーマンスを向上させるためには、KDC と LDAP ディレクトリサービスを同じサーバーにインストールしてください。さらに、ディレクトリサーバーも稼働させるようにしてください。次の手順は、Sun Java Directory Server Enterprise Edition リリースを使用しているサーバーで機能します。

  1. KDC 上でスーパーユーザーになります。

  2. ディレクトリサーバーの証明書を作成し、その証明書をインポートします。

    次の手順では、Directory Server 6.1 自己署名付き証明書を使用するように S10 KDC を構成します。証明書の期限が切れている場合は、『Sun Java System Directory Server Enterprise Edition 6.2 管理ガイド』の「自己署名済み証明書を管理する」の手順に従って証明書を更新してください。

    1. 自己署名付きのディレクトリサーバー証明書をエクスポートします。


      # /usr/sfw/bin/certutil -L -n defaultCert -d /export/sun-ds6.1/directory/alias \
        -P 'slapd-' -a > /var/tmp/ds_cert.pem

    2. ローカルの証明書データベースを作成します。


      # /usr/sfw/bin/certutil -N -d /var/ldap

    3. ディレクトリサーバー証明書をローカルの証明書データベースに追加します。


      # /usr/sfw/bin/certutil -A -n defaultCert -i /var/tmp/ds_cert -a -t CT -d /var/ldap

    4. ディレクトリサーバー証明書をインポートします。


      # pktool setpin keystore=nss dir=/var/ldap
# chmod a+r /var/ldap/*.db
# pktool import keystore=nss objtype=cert trust="CT" infile=/tmp/defaultCert.certutil.der \
        label=defaultCert dir=/var/ldap

  3. 必要に応じて、LDAP ディレクトリにデータを設定します。

  4. 既存のスキーマに Solaris Kerberos スキーマを追加します。


    # ldapmodify -h dsserver.example.com -D "cn=directory manager" -f /usr/share/lib/ldif/kerberos.ldif

  5. LDAP ディレクトリ内に Kerberos コンテナを作成します。

    krb5.conf ファイルに次のエントリを追加します。

    1. データベースの種類を定義します。

      realms セクションに database_module を定義するエントリを追加します。


      database_module = LDAP

    2. データベースのモジュールを定義します。


      [dbmodules]
    LDAP = {
        ldap_kerberos_container_dn = "cn=krbcontainer,dc=example,dc=com"
        db_library = kldap
        ldap_kdc_dn = "cn=kdc service,ou=profile,dc=example,dc=com"
        ldap_kadmind_dn = "cn=kadmin service,ou=profile,dc=example,dc=com"
        ldap_cert_path = /var/ldap
        ldap_servers = ldaps://dsserver.example.com
    }

    3. LDAP ディレクトリ内に KDC を作成します。

      このコマンドによって、krbcontainer とその他のいくつかのオブジェクトが作成されます。また、/var/krb5/.k5.EXAMPLE.COM マスター鍵の stash ファイルも作成されます。


      # kdb5_ldap_util -D "cn=directory manager" create -P abcd1234 -r EXAMPLE.COM -s

  6. KDC のバインド識別名 (DN) のパスワードを隠します。

    これらのパスワードは、DS にバインドするときに KDC によって使用されます。KDC は、その KDC が使用しているアクセスの種類に応じて異なる役割を使用します。


    # kdb5_ldap_util stashsrvpw "cn=kdc service,ou=profile,dc=example,dc=com"
# kdb5_ldap_util stashsrvpw "cn=kadmin service,ou=profile,dc=example,dc=com"

  7. KDC サービスの役割を追加します。

    1. 次に示すような内容を含む kdc_roles.ldif ファイルを作成します。


      dn: cn=kdc service,ou=profile,dc=example,dc=com
cn: kdc service
sn: kdc service
objectclass: top
objectclass: person
userpassword: test123

dn: cn=kadmin service,ou=profile,dc=example,dc=com
cn: kadmin service
sn: kadmin service
objectclass: top
objectclass: person
userpassword: test123

    2. LDAP ディレクトリ内に役割のエントリを作成します。


      # ldapmodify -a -h dsserver.example.com -D "cn=directory manager" -f kdc_roles.ldif

  8. KDC に関連する役割の ACL を設定します。


    # cat << EOF | ldapmodify -h dsserver.example.com -D "cn=directory manager" 
# Set kadmin ACL for everything under krbcontainer.
dn: cn=krbcontainer,dc=example,dc=com
changetype: modify
add: aci
aci: (target="ldap:///cn=krbcontainer,dc=example,dc=com")(targetattr="krb*")(version 3.0;\
      acl kadmin_ACL; allow (all)\
      userdn = "ldap:///cn=kadmin service,ou=profile,dc=example,dc=com";)

# Set kadmin ACL for everything under the people subtree if there are
# mix-in entries for krb princs:
dn: ou=people,dc=example,dc=com
changetype: modify
add: aci
aci: (target="ldap:///ou=people,dc=example,dc=com")(targetattr="krb*")(version 3.0;\
      acl kadmin_ACL; allow (all)\
      userdn = "ldap:///cn=kadmin service,ou=profile,dc=example,dc=com";)
EOF

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

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


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

[realms]
        EXAMPLE.COM = {
        kdc = kdc1.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
        }

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

    注 –

    暗号化タイプを制限する場合は、default_tkt_enctypes または default_tgs_enctypes の行を設定します。暗号化タイプの制限に関する詳細は、「Kerberos 暗号化タイプの使用」を参照してください。

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

    レルム名を変更する必要があります。このファイルの詳細は、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
                sunw_dbprop_enable = true
                sunw_dbprop_master_ulogsize = 1000
                }

    この例では、realms セクションのレルム名定義を変更しました。また、realms セクションで、増分伝播できるようにする行とログ内に保持する KDC マスターの更新数を選択する行を追加しました。

    注 –

    暗号化タイプを制限する場合は、permitted_enctypes、supported_enctypes、または master_key_type の行を設定します。暗号化タイプの制限に関する詳細は、「Kerberos 暗号化タイプの使用」を参照してください。

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

    作成された /etc/krb5/kadm5.acl ファイルには、KDC を管理できる主体名がすべて含まれている必要があります。 


    kws/admin@EXAMPLE.COM   *

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

  12. kadmin.local コマンドを起動し、主体を追加します。

    次の手順では、Kerberos サービスで使用される主体を作成します。


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

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

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


      kadmin.local: addprinc kws/admin
Enter password for principal kws/admin@EXAMPLE.COM:<Type the password>
Re-enter password for principal kws/admin@EXAMPLE.COM: <Type it again>
Principal "kws/admin@EXAMPLE.COM" created.
kadmin.local:

    2. 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 AES-256 CTS mode
          with 96-bit SHA-1 HMAC added to keytab WRFILE:/etc/krb5/kadm5.keytab.
Entry for principal kadmin/kdc1.example.com with kvno 3, encryption type AES-128 CTS mode
          with 96-bit SHA-1 HMAC added to keytab WRFILE:/etc/krb5/kadm5.keytab.
Entry for principal kadmin/kdc1.example.com with kvno 3, encryption type Triple DES cbc
          mode with HMAC/sha1 added to keytab WRFILE:/etc/krb5/kadm5.keytab.
Entry for principal kadmin/kdc1.example.com with kvno 3, encryption type ArcFour
          with HMAC/md5 added to keytab WRFILE:/etc/krb5/kadm5.keytab.
Entry for principal kadmin/kdc1.example.com with kvno 3, encryption type DES cbc mode
          with RSA-MD5 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 AES-256 CTS mode
          with 96-bit SHA-1 HMAC added to keytab WRFILE:/etc/krb5/kadm5.keytab.
Entry for principal changepw/kdc1.example.com with kvno 3, encryption type AES-128 CTS mode
          with 96-bit SHA-1 HMAC added to keytab WRFILE:/etc/krb5/kadm5.keytab.
Entry for principal changepw/kdc1.example.com with kvno 3, encryption type Triple DES cbc
          mode with HMAC/sha1 added to keytab WRFILE:/etc/krb5/kadm5.keytab.
Entry for principal changepw/kdc1.example.com with kvno 3, encryption type ArcFour
          with HMAC/md5 added to keytab WRFILE:/etc/krb5/kadm5.keytab.
Entry for principal changepw/kdc1.example.com with kvno 3, encryption type DES cbc mode
          with RSA-MD5 added to keytab WRFILE:/etc/krb5/kadm5.keytab.
kadmin.local: ktadd -k /etc/krb5/kadm5.keytab kadmin/changepw
Entry for principal kadmin/changepw with kvno 3, encryption type AES-256 CTS mode
          with 96-bit SHA-1 HMAC added to keytab WRFILE:/etc/krb5/kadm5.keytab.
Entry for principal kadmin/changepw with kvno 3, encryption type AES-128 CTS mode
          with 96-bit SHA-1 HMAC added to keytab WRFILE:/etc/krb5/kadm5.keytab.
Entry for principal kadmin/changepw with kvno 3, encryption type Triple DES cbc
          mode with HMAC/sha1 added to keytab WRFILE:/etc/krb5/kadm5.keytab.
Entry for principal kadmin/changepw with kvno 3, encryption type ArcFour
          with HMAC/md5 added to keytab WRFILE:/etc/krb5/kadm5.keytab.
Entry for principal kadmin/changepw with kvno 3, encryption type DES cbc mode
          with RSA-MD5 added to keytab WRFILE:/etc/krb5/kadm5.keytab.
kadmin.local:

    3. kadmin.local を終了します。

      以降の手順で必要になる主体をすべて追加しました。


      kadmin.local: quit

  13. (省略可能) Kerberos サービスの LDAP 依存性を構成します。

    LDAP および KDC サーバーが同一のホスト上で稼働しており、LDAP サービスが SMF FMRI を使って構成されている場合は、Kerberos デーモンの LDAP サービスに対する依存性を追加します。これにより、LDAP サービスが再起動すると KDC サービスも再起動するようになります。

    1. krb5kdc サービスへの依存性を追加します。


      # svccfg -s security/krb5kdc
svc:/network/security/krb5kdc> addpg dsins1 dependency
svc:/network/security/krb5kdc> setprop dsins1/entities = \
    fmri: "svc:/application/sun/ds:ds--var-opt-SUNWdsee-dsins1"
svc:/network/security/krb5kdc> setprop dsins1/grouping = astring: "require_all"
svc:/network/security/krb5kdc> setprop dsins1/restart_on = astring: "restart"
svc:/network/security/krb5kdc> setprop dsins1/type = astring: "service"
svc:/network/security/krb5kdc> exit

    2. kadmin サービスへの依存性を追加します。


      # svccfg -s security/kadmin
svc:/network/security/kadmin> addpg dsins1 dependency
svc:/network/security/kadmin> setprop dsins1/entities =\
    fmri: "svc:/application/sun/ds:ds--var-opt-SUNWdsee-dsins1"
svc:/network/security/kadmin> setprop dsins1/grouping = astring: "require_all"
svc:/network/security/kadmin> setprop dsins1/restart_on = astring: "restart"
svc:/network/security/kadmin> setprop dsins1/type = astring: "service"
svc:/network/security/kadmin> exit

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


    kdc1 # svcadm enable -r network/security/krb5kdc
kdc1 # svcadm enable -r network/security/kadmin

  15. kadmin を起動して、主体をさらに追加します。

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


    kdc1 # /usr/sbin/kadmin -p kws/admin
Enter password: <Type kws/admin password>
kadmin:

    1. マスター KDC の host 主体を作成します。

      ホスト主体は、klist や kprop などの Kerberos アプリケーションで使用されます。Solaris 10 クライアントは、認証された NFS ファイルシステムをマウントするときに、この主体を使用します。主体のインスタンスがホスト名のときは、/etc/resolv.conf ファイル内のドメイン名が大文字であるか小文字であるかに関係なく、FQDN は小文字で指定する必要があります。


      kadmin: addprinc -randkey host/kdc1.example.com
Principal "host/kdc1.example.com@EXAMPLE.COM" created.
kadmin:

    2. (省略可能) kclient 主体を作成します。

      この主体は、Kerberos クライアントのインストール中に kclient ユーティリティーで使用されます。このユーティリティーを使用しない場合は、主体に追加する必要はありません。kclient ユーティリティーのユーザーは、このパスワードを使用する必要があります。


      kadmin: addprinc clntconfig/admin
Enter password for principal clntconfig/admin@EXAMPLE.COM:<Type the password>
Re-enter password for principal clntconfig/admin@EXAMPLE.COM: <Type it again>
Principal "clntconfig/admin@EXAMPLE.COM" created.
kadmin:

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

      キータブファイルに追加したホスト主体が、自動的に使用されます。


      kadmin: ktadd host/kdc1.example.com
Entry for principal host/kdc1.example.com with kvno 3, encryption type AES-256 CTS mode
          with 96-bit SHA-1 HMAC added to keytab WRFILE:/etc/krb5/krb5.keytab.
Entry for principal host/kdc1.example.com with kvno 3, encryption type AES-128 CTS mode
          with 96-bit SHA-1 HMAC added to keytab WRFILE:/etc/krb5/krb5.keytab.
Entry for principal host/kdc1.example.com with kvno 3, encryption type Triple DES cbc
          mode with HMAC/sha1 added to keytab WRFILE:/etc/krb5/krb5.keytab.
Entry for principal host/kdc1.example.com with kvno 3, encryption type ArcFour
          with HMAC/md5 added to keytab WRFILE:/etc/krb5/krb5.keytab.
Entry for principal host/kdc1.example.com with kvno 3, encryption type DES cbc mode
          with RSA-MD5 added to keytab WRFILE:/etc/krb5/krb5.keytab.
kadmin:

    4. kadmin を終了します。


      kadmin: quit

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

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

  17. スレーブ KDC の構成

    冗長性を確保するには、スレーブ KDC を必ず 1 つ以上インストールするようにしてください。 手順については、「スレーブ KDC を手動で構成する方法」を参照してください。

Procedureスレーブ KDC を手動で構成する方法

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

始める前に

マスター KDC が構成済みである必要があります。スレーブ KDC を入れ替え可能にする手順については、「マスター KDC とスレーブ KDC の入れ替え」を参照してください。

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

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

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


    kdc1 # /usr/sbin/kadmin -p kws/admin
Enter password: <Type kws/admin password>
kadmin:

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

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


      kadmin: addprinc -randkey host/kdc2.example.com
Principal "host/kdc2.example.com@EXAMPLE.COM" created.
kadmin:

    2. マスター KDC 上で、kiprop 主体を作成します。

      kiprop 主体は、マスター KDC からの増分伝播を承認するために使用されます。


      kadmin: addprinc -randkey kiprop/kdc2.example.com
Principal "kiprop/kdc2.example.com@EXAMPLE.COM" created.
kadmin:

    3. kadmin を終了します。


      kadmin: quit

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

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


    kdc1 # cat /etc/krb5/krb5.conf
 .
 .
[realms]
                EXAMPLE.COM = {
                kdc = kdc1.example.com
                kdc = kdc2.example.com
                admin_server = kdc1.example.com
        }

  4. マスター KDC 上で、kadm5.acl に kiprop エントリを追加します。

    このエントリにより、マスター KDC が kdc2 サーバー用の増分伝播の要求を受け取ることができるようになります。


    kdc1 # cat /etc/krb5/kadm5.acl
*/admin@EXAMPLE.COM *
kiprop/kdc2.example.com@EXAMPLE.COM p

  5. マスター KDC 上で、kadmind を再起動し、kadm5.acl ファイルの新しいエントリを使用します。


    kdc1 # svcadm restart network/security/kadmin

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

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

    • /etc/krb5/krb5.conf

    • /etc/krb5/kdc.conf

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

    この情報は、すべてのスレーブ KDC サーバー上で更新する必要があります。


    kdc2 # cat /etc/krb5/kpropd.acl
host/kdc1.example.com@EXAMPLE.COM
host/kdc2.example.com@EXAMPLE.COM

  8. すべてのスレーブ KDC 上で、Kerberos アクセス制御リストファイル kadm5.acl が反映されていないことを確認してください。

    修正前の kadm5.acl ファイルは次のようになっています。


    kdc2 # cat /etc/krb5/kadm5.acl
*/admin@___default_realm___ *

    ファイルに kiprop のエントリがある場合は、それを削除します。

  9. 新しいスレーブ上で、kdc.conf のエントリを変更します。

    sunw_dbprop_master_ulogsize エントリを sunw_dbprop_slave_poll を定義するエントリと置き換えます。エントリは、ポーリング時間を 2 分に設定します。


    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
                sunw_dbprop_enable = true
                sunw_dbprop_slave_poll = 2m
        }

  10. 新しいスレーブ上で、kadmin コマンドを起動します。

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


    kdc2 # /usr/sbin/kadmin -p kws/admin
Enter password: <Type kws/admin password>
kadmin:

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

      このエントリにより kprop などの Kerberos アプリケーションが機能します。主体のインスタンスがホスト名のときは、/etc/resolv.conf ファイル内のドメイン名が大文字であるか小文字であるかに関係なく、FQDN は小文字で指定する必要があります。


      kadmin: ktadd host/kdc2.example.com
Entry for principal host/kdc2.example.com with kvno 3, encryption type AES-256 CTS mode
          with 96-bit SHA-1 HMAC added to keytab WRFILE:/etc/krb5/krb5.keytab.
Entry for principal host/kdc2.example.com with kvno 3, encryption type AES-128 CTS mode
          with 96-bit SHA-1 HMAC added to keytab WRFILE:/etc/krb5/krb5.keytab.
Entry for principal host/kdc2.example.com with kvno 3, encryption type Triple DES cbc
          mode with HMAC/sha1 added to keytab WRFILE:/etc/krb5/krb5.keytab.
Entry for principal host/kdc2.example.com with kvno 3, encryption type ArcFour
          with HMAC/md5 added to keytab WRFILE:/etc/krb5/krb5.keytab.
Entry for principal host/kdc2.example.com with kvno 3, encryption type DES cbc mode
          with RSA-MD5 added to keytab WRFILE:/etc/krb5/krb5.keytab.
kadmin:

    2. スレーブ KDC のキータブファイルに kiprop 主体を追加します。

      krb5.keytab に kiprop 主体を追加すると、増分伝播が開始されるときに、kprpod コマンドが自身を認証できるようになります。


      kadmin: ktadd kiprop/kdc2.example.com
Entry for principal kiprop/kdc2.example.com with kvno 3, encryption type AES-256 CTS mode
          with 96-bit SHA-1 HMAC added to keytab WRFILE:/etc/krb5/krb5.keytab.
Entry for principal kiprop/kdc2.example.com with kvno 3, encryption type AES-128 CTS mode
          with 96-bit SHA-1 HMAC added to keytab WRFILE:/etc/krb5/krb5.keytab.
Entry for principal kiprop/kdc2.example.com with kvno 3, encryption type Triple DES cbc
          mode with HMAC/sha1 added to keytab WRFILE:/etc/krb5/krb5.keytab.
Entry for principal kiprop/kdc2.example.com with kvno 3, encryption type ArcFour
          with HMAC/md5 added to keytab WRFILE:/etc/krb5/krb5.keytab.
Entry for principal kiprop/kdc2.example.com with kvno 3, encryption type DES cbc mode
          with RSA-MD5 added to keytab WRFILE:/etc/krb5/krb5.keytab.
kadmin:

    3. kadmin を終了します。


      kadmin: quit

  11. 新しいスレーブ上で、Kerberos 伝播デーモンを起動します。


    kdc2 # /usr/lib/krb5/kpropd

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


    kdc2 # /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: <Type the key>

  13. Kerberos 伝播デーモンを終了します。


    kdc2 # pkill kpropd

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

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

  15. 新しいスレーブ上で、KDC デーモン (krb5kdc) を起動します。

    krb5kdc サービスが有効なときは、システムがスレーブとして構成されていると kpropd も起動します。


    kdc2 # svcadm enable network/security/krb5kdc

Procedureマスターサーバー上でチケット認可サービス鍵を更新する方法

Solaris 10 リリース以前に作成された Solaris KDC サービスで、チケット認可サービス (TGS) 主体が DES 鍵のみを持つ場合、この鍵により、チケット認可チケット (TGT) セッション鍵の暗号化タイプは DES に限定されます。より強力なほかの暗号化タイプにも対応する Solaris 10 に Solaris KDC をアップデートすると、KDC で生成されるすべてのセッション鍵について暗号化を強化できるようになります。ただし、既存の TGS 主体の鍵を新しい暗号化タイプに対応するよう更新しなければ、TGT セッション鍵は DES に限定されたままになります。次の手順では、この鍵を更新して、ほかの暗号化タイプも使用できるようにします。

  1. TGS サービス主体鍵を更新します。


    kdc1 % /usr/sbin/kadmin -p kws/admin
Enter password: <Type kws/admin password>
kadmin: cpw -randkey krbtgt/EXAMPLE.COM@EXAMPLE.COM
例 23–1 マスターサーバーから主体鍵を更新する

KDC マスターに root としてログオンした場合、次のコマンドを使用して TGS サービス主体を更新できます。


kdc1 # kadmin.local -q 'cpw -randkey krbtgt/EXAMPLE.COM@EXAMPLE.COM'

レルム間認証の構成

複数のレルムを接続して、レルム間でユーザーを認証することができます。レルム間の認証は、2 つのレルム間で共有される秘密鍵を作成することによって実行されます。レルム間の関係には、階層関係または直接接続があります (「レルムの階層」を参照)。

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

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

始める前に

マスター KDC の各レルムが構成済みである必要があります。認証プロセスを十分にテストするには、複数の Kerberos クライアントが構成されている必要があります。

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

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

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


    # /usr/sbin/kadmin -p kws/admin
Enter password: <Type kws/admin password>
kadmin: addprinc krbtgt/ENG.EAST.EXAMPLE.COM@EAST.EXAMPLE.COM
Enter password for principal krgtgt/ENG.EAST.EXAMPLE.COM@EAST.EXAMPLE.COM: <Type password>
kadmin: addprinc krbtgt/EAST.EXAMPLE.COM@ENG.EAST.EXAMPLE.COM
Enter password for principal krgtgt/EAST.EXAMPLE.COM@ENG.EAST.EXAMPLE.COM: <Type password>
kadmin: quit
    注 –

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

  3. 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 構成ファイルは先頭から末尾方向に検索されるため、サブドメインは最初に定義してください。

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

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

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

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

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

始める前に

マスター KDC の各レルムが構成済みである必要があります。認証プロセスを十分にテストするには、複数の Kerberos クライアントが構成されている必要があります。

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

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

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


    # /usr/sbin/kadmin -p kws/admin
Enter password: <Type kws/admin password>
kadmin: addprinc krbtgt/ENG.EAST.EXAMPLE.COM@SALES.WEST.EXAMPLE.COM
Enter password for principal 
  krgtgt/ENG.EAST.EXAMPLE.COM@SALES.WEST.EXAMPLE.COM: <Type the password>
kadmin: addprinc krbtgt/SALES.WEST.EXAMPLE.COM@ENG.EAST.EXAMPLE.COM
Enter password for principal 
  krgtgt/SALES.WEST.EXAMPLE.COM@ENG.EAST.EXAMPLE.COM: <Type the password>
kadmin: quit
    注 –

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

  3. Kerberos 構成ファイルにエントリを追加して、遠隔レルムへの直接パスを定義します。

    この例は、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 = .
    }

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

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

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

Kerberos ネットワークアプリケーションサーバーの構成

ネットワークアプリケーションサーバーとは、次のいずれかのネットワークアプリケーションを 1 つ以上使ってアクセスを提供するホストのことです。 ftp、rcp、rlogin、rsh、ssh、telnet。いくつかの手順を実行するだけで、これらのコマンドの Kerberos バージョンをサーバー上で有効にすることができます。

ProcedureKerberos ネットワークアプリケーションサーバーを構成する方法

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

始める前に

この手順を行う場合には、マスター KDC がすでに構成されていなければなりません。このプロセスを十分にテストするには、複数の Kerberos クライアントが構成されている必要があります。

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

    NTP については、「KDC と Kerberos クライアントのクロックの同期化」を参照してください。

  2. 新しいサーバーの主体を追加し、そのサーバーのキータブを更新します。

    次のコマンドは、ホスト主体の存在有無を報告します。


    boston # klist -k |grep host
4 host/boston.example.com@EXAMPLE.COM
4 host/boston.example.com@EXAMPLE.COM
4 host/boston.example.com@EXAMPLE.COM
4 host/boston.example.com@EXAMPLE.COM

    このコマンドを実行しても主体が返されなかった場合、次の手順に従って新しい主体を作成します。

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


    boston # /usr/sbin/kadmin -p kws/admin
Enter password: <Type kws/admin password>
kadmin:

    1. サーバーの host 主体を作成します。

      host 主体を使用する目的は次のとおりです。

      • rsh や ssh など、遠隔コマンドの使用時にトラフィックを認証します。

      • pam_krb5 により、host 主体を使用してユーザーの Kerberos 資格が信頼できる KDC から取得されたことを確認し、KDC へのなりすまし攻撃を防ぎます。

      • root ユーザーが root 主体の存在なしで Kerberos 資格を自動的に取得できるようにします。これは、共有で Kerberos 資格が必要な場合に手動の NFS マウントを実行するのに役立つことがあります。

      リモートアプリケーションを使用するトラフィックに Kerberos サービスによる認証が必要な場合は、この主体が必要です。サーバーに複数のホスト名が割り当てられている場合は、ホスト名の FQDN 形式を使用してホスト名ごとに主体を作成します。


      kadmin: addprinc -randkey host/boston.example.com
Principal "host/boston.example.com" created.
kadmin:

    2. サーバーの host 主体をサーバーのキータブに追加します。

      kadmin コマンドが実行中でないときは、次のようにコマンドを再起動します。 /usr/sbin/kadmin -p kws/admin

      サーバーに複数のホスト名が割り当てられている場合は、ホスト名ごとに主体をキータブに追加します。


      kadmin: ktadd host/boston.example.com
Entry for principal host/boston.example.com with kvno 3, encryption type AES-256 CTS mode
          with 96-bit SHA-1 HMAC added to keytab WRFILE:/etc/krb5/krb5.keytab.
Entry for principal host/boston.example.com with kvno 3, encryption type AES-128 CTS mode
          with 96-bit SHA-1 HMAC added to keytab WRFILE:/etc/krb5/krb5.keytab.
Entry for principal host/boston.example.com with kvno 3, encryption type Triple DES cbc
          mode with HMAC/sha1 added to keytab WRFILE:/etc/krb5/krb5.keytab.
Entry for principal host/boston.example.com with kvno 3, encryption type ArcFour
          with HMAC/md5 added to keytab WRFILE:/etc/krb5/krb5.keytab.
Entry for principal host/boston.example.com with kvno 3, encryption type DES cbc mode
          with RSA-MD5 added to keytab WRFILE:/etc/krb5/krb5.keytab.
kadmin:

    3. kadmin を終了します。


      kadmin: quit

Kerberos NFS サーバーの構成

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

表 23–2 Kerberos NFS サーバーの構成 (作業マップ)

作業 

説明 

参照先 

Kerberos NFS サーバーを構成します。 

Kerberos 認証を必要とするファイルシステムを、サーバーが共有できるようにします。 

「Kerberos NFS サーバーを構成する方法」

資格テーブルを作成します。 

デフォルトのマッピングが十分でない場合、GSS 資格から UNIX ユーザー ID へのマッピングに使用できる資格テーブルを生成します。 

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

ユーザー資格を UNIX UID に割り当てる資格テーブルを変更します。 

資格テーブルの情報を更新します。 

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

類似する 2 つのレルム間の資格マッピングを作成します。 

レルムがパスワードファイルを共有している場合に、あるレルムから別のレルムに UID をマッピングする方法を説明します。 

「レルム間の資格マッピングを提供する方法」

Kerberos 認証を使用してファイルシステムを共有します。 

セキュリティーモードを使用してファイルシステムを共有し、Kerberos 認証を常に行います。 

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

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

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

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

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

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

    Network Time Protocol (NTP) のインストールと使用は必要はありません。ただし、認証が正常終了するには、すべてのクロックが、krb5.conf ファイル内の clockskew 関係指定子で定義されている最大の誤差以内で KDC サーバー上の時刻と同期化されている必要があります。NTP については、「KDC と Kerberos クライアントのクロックの同期化」を参照してください。

  3. NFS サーバーを Kerberos クライアントとして構成します。

    「Kerberos クライアントの構成」の手順に従ってください。

  4. kadmin を起動します。

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


    denver # /usr/sbin/kadmin -p kws/admin
Enter password: <Type kws/admin password>
kadmin:

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

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

      NFS データへのアクセスに使用されるシステム上の一意のインタフェースごとに、上記の手順を繰り返します。ホストに一意の名前を持ったインタフェースが複数存在する場合、一意の名前は、それぞれに NFS サービス主体を持つ必要があります。


      kadmin: addprinc -randkey nfs/denver.example.com
Principal "nfs/denver.example.com" created.
kadmin:

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

      手順 a で作成した一意のサービス主体ごとに、この手順を繰り返します。


      kadmin: ktadd nfs/denver.example.com
Entry for principal nfs/denver.example.com with kvno 3, encryption type AES-256 CTS mode
          with 96-bit SHA-1 HMAC added to keytab WRFILE:/etc/krb5/krb5.keytab.
Entry for principal nfs/denver.example.com with kvno 3, encryption type AES-128 CTS mode
          with 96-bit SHA-1 HMAC added to keytab WRFILE:/etc/krb5/krb5.keytab.
Entry for principal nfs/denver.example.com with kvno 3, encryption type Triple DES cbc
          mode with HMAC/sha1 added to keytab WRFILE:/etc/krb5/krb5.keytab.
Entry for principal nfs denver.example.com with kvno 3, encryption type ArcFour
          with HMAC/md5 added to keytab WRFILE:/etc/krb5/krb5.keytab.
Entry for principal nfs/denver.example.com with kvno 3, encryption type DES cbc mode
          with RSA-MD5 added to keytab WRFILE:/etc/krb5/krb5.keytab.
kadmin:

    3. kadmin を終了します。


      kadmin: quit

  5. (省略可能) 必要に応じて、特殊な GSS 資格マップを作成します。

    通常、Kerberos サービスは、GSS 資格と UNIX UID 間の適切な対応表を生成します。デフォルトのマッピングについては、「GSS 資格の UNIX 資格へのマッピング」を参照してください。デフォルトのマッピングが十分でない場合は、「資格テーブルを作成する方法」を参照してください。

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

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

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

gsscred 資格テーブルは、Kerberos 主体を UID に割り当てるために NFS サーバーが使用します。デフォルトでは、主体名の一次の部分が UNIX のログイン名に一致します。NFS クライアントが Kerberos 認証を使用して NFS サーバーからファイルシステムをマウントするには、デフォルトのマッピングが十分でない場合、このテーブルを作成する必要があります。

  1. /etc/gss/gsscred.conf を編集してセキュリティーメカニズムを変更します。

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

  2. gsscred コマンドを使用して資格テーブルを作成します。


    # gsscred -m kerberos_v5 -a

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

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

始める前に

この手順を行うには、gsscred テーブルがすでに NFS サーバーに作成済みである必要があります。手順については、「資格テーブルを作成する方法」を参照してください。

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

  2. gsscred コマンドを使用して、エントリを資格テーブルに追加します。


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

    使用するセキュリティーメカニズムを定義します。

    name

    KDC に定義されている、ユーザーの主体名を定義します。

    uid

    パスワードデータベースに定義されている、ユーザーの UID を定義します。

    -a

    UID を主体名の割り当てに追加します。

例 23–2 資格テーブルに複数の構成要素主体を追加する

次の例では、 sandy/admin という名前の主体にエントリを 1 つ追加し、UID 3736 に割り当てます。


# gsscred -m kerberos_v5 -n sandy/admin -u 3736 -a
例 23–3 異なるドメインの主体を資格テーブルに追加する

次の例では、sandy/admin@EXAMPLE.COM という名前の主体にエントリを 1 つ追加し、UID 3736 に割り当てます。


# gsscred -m kerberos_v5 -n sandy/admin@EXAMPLE.COM -u 3736 -a

Procedureレルム間の資格マッピングを提供する方法

この手順では、同じパスワードファイルを使用するレルム間の適切な資格マッピングを提供します。この例では、CORP.EXAMPLE.COM レルムと SALES.EXAMPLE.COM レルムは同じパスワードファイル使用します。bob@CORP.EXAMPLE.COM と bob@SALES.EXAMPLE.COM の資格は同じ UID にマッピングされます。

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

  2. クライアントシステム上で、エントリを krb5.conf ファイルに追加します。


    # cat /etc/krb5/krb5.conf
[libdefaults]
        default_realm = CORP.EXAMPLE.COM
 .
[realms]
    CORP.EXAMPLE.COM = {
        .
        auth_to_local_realm = SALES.EXAMPLE.COM
        .
    }
例 23–4 同じパスワードファイルを使用してレルム間で資格をマッピングする

この例では、同じパスワードファイルを使用するレルム間の適切な資格マッピングを提供します。この例では、CORP.EXAMPLE.COM レルムと SALES.EXAMPLE.COM レルムは同じパスワードファイル使用します。bob@CORP.EXAMPLE.COM と bob@SALES.EXAMPLE.COM の資格は同じ UID にマッピングされます。クライアントシステム上で、エントリを krb5.conf ファイルに追加します。


# cat /etc/krb5/krb5.conf
[libdefaults]
        default_realm = CORP.EXAMPLE.COM
 .
[realms]
    CORP.EXAMPLE.COM = {
        .
        auth_to_local_realm = SALES.EXAMPLE.COM
        .
    }
注意事項

資格マッピングの問題を障害追跡する手順については、「GSS 資格の UNIX 資格へのマッピングの監視」を参照してください。

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

この手順により、さまざまなセキュリティーモードまたはフレーバを使用して、NFS サーバーが NFS に安全にアクセスできるようになります。クライアントがセキュリティーフレーバについて NFS サーバーとネゴシエーションを行うとき、クライアントがアクセスしたサーバーが提供する最初のフレーバが使用されます。このフレーバは、NFS サーバーが共有するファイルシステムにおける後続のクライアント要求すべてに使用されます。

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

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

    klist コマンドを指定すると、キータブファイルが存在するかどうかが出力され、その主体が表示されます。キータブファイルが存在しない場合、または NFS サービス主体が存在しない場合は、「Kerberos NFS サーバーを構成する方法」のすべての手順が完了していることを検証する必要があります。


    # klist -k
Keytab name: FILE:/etc/krb5/krb5.keytab
KVNO Principal
---- ---------------------------------------------------------
   3 nfs/denver.example.com@EXAMPLE.COM
   3 nfs/denver.example.com@EXAMPLE.COM
   3 nfs/denver.example.com@EXAMPLE.COM
   3 nfs/denver.example.com@EXAMPLE.COM

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

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


    # cat /etc/nfssec.conf
 .
 .
#
# Uncomment the following lines to use Kerberos V5 with NFS
#
krb5            390003  kerberos_v5     default -               # RPCSEC_GSS
krb5i           390004  kerberos_v5     default integrity       # RPCSEC_GSS
krb5p           390005  kerberos_v5     default privacy         # RPCSEC_GSS

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


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

    ファイルシステムを共有するときに使用するセキュリティーモードを指定します。複数のセキュリティーモードを使用するときは、デフォルトとして、リストの最初のモードが使用されます。

    file-system

    共有するファイルシステムへのパスを定義します。

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

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

    1 つまたは複数の share コマンドをはじめて実行する場合、NFS デーモンが動作していないことがあります。次のコマンドでデーモンを再起動します。


    # svcadm restart network/nfs/server

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

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


    file-system  auto_home  -nosuid,sec=mode

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

    代わりに、mount コマンドにセキュリティーモードを指定できますが、オートマウンタは利用できません。


    # mount -F nfs -o sec=mode file-system
例 23–5 1 つの Kerberos セキュリティーモードでファイルシステムを共有する

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


# grep krb /etc/dfs/dfstab
share -F nfs -o sec=krb5 /export/home
例 23–6 複数の Kerberos セキュリティーモードでファイルシステムを共有する

次の例では、3 つの Kerberos セキュリティーモードがすべて選択されています。クライアントと NFS サーバーの間で、どのモードを使用するかのネゴシエーションが行われます。コマンドの最初のモードが失敗すると、次のモードが試行されます。詳細は、nfssec(5) のマニュアルページを参照してください。


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

Kerberos クライアントの構成

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

Kerberos クライアントの構成 (作業マップ)

次の作業マップは、Kerberos クライアントの設定に関連するすべての手順が含まれます。各行には、作業識別名、その作業を行う理由、および作業へのリンクが含まれます。

作業 

説明 

参照先 

Kerberos クライアントのインストールプロファイルを確立します。 

Kerberos クライアントの自動インストールに使用されるクライアントのインストールプロファイルを生成します。 

「Kerberos クライアントのインストールプロファイルの作成方法」

Kerberos クライアントを構成します。 

手動で Kerberos クライアントをインストールします。各クライアントのインストールに独自のインストールパラメータが必要な場合に、この手順を使用します。 

「Kerberos クライアントを手動で構成する方法」

 

自動的に Kerberos クライアントをインストールします。各クライアントのインストールパラメータが同じ場合に、この手順を使用します。 

「Kerberos クライアントを自動的に構成する方法」

 

対話的に Kerberos クライアントをインストールします。2、3 のインストールパラメータを変更する必要がある場合にだけ、この手順を使用します。 

「Kerberos クライアントを対話的に構成する方法」

クライアントが root ユーザーとして NFS ファイルシステムにアクセスすることを許可します

root アクセス付きで共有される NFS ファイルシステムをクライアントがマウントできるように、root 主体をクライアント上に作成します。また、cron ジョブを実行できるように、NFS ファイルシステムへの非対話的な root アクセスをクライアントがセットアップすることを許可します。

「Kerberos によって保護された NFS ファイルシステムに root ユーザーとしてアクセスする方法」

クライアントのチケット認可チケット (TGT) を発行した KDC の確認を無効にします。 

ローカルのキータブファイルにホスト主体を保存しないクライアントが、TGT を発行した KDC とホスト主体を発行した KDC が同じサーバーであることを確認するセキュリティー検査を省略できるようにします。 

「チケット認可チケット (TGT) の確認を無効にする方法」

ProcedureKerberos クライアントのインストールプロファイルの作成方法

この手順は、Kerberos クライアントをインストールする際に使用される kclient プロファイルを作成します。kclient プロファイルを使用することにより、入力エラーの可能性を減らします。また、プロファイルを使用すると、対話型のプロセスと比べて、ユーザーの介入も減ります。

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

  2. kclient インストールプロファイルを作成します。

    kclient プロファイルの例は、次のようになります。


    client# cat /net/denver.example.com/export/install/profile
REALM EXAMPLE.COM
KDC kdc1.example.com
ADMIN clntconfig
FILEPATH /net/denver.example.com/export/install/krb5.conf
NFS 1
DNSLOOKUP none

ProcedureKerberos クライアントを自動的に構成する方法

始める前に

この手順では、インストールプロファイルを使用します。 「Kerberos クライアントのインストールプロファイルの作成方法」を参照してください。

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

  2. kclient インストールスクリプトを実行します。

    プロセスを完了するには、clntconfig 主体のパスワードを入力する必要があります。


    client# /usr/sbin/kclient -p /net/denver.example.com/export/install/profile

Starting client setup
---------------------------------------------------

kdc1.example.com

Setting up /etc/krb5/krb5.conf.

Obtaining TGT for clntconfig/admin ...
Password for clntconfig/admin@EXAMPLE.COM: <Type the password>

nfs/client.example.com entry ADDED to KDC database.
nfs/client.example.com entry ADDED to keytab.

host/client.example.com entry ADDED to KDC database.
host/client.example.com entry ADDED to keytab.

Copied /net/denver.example.com/export/install/krb5.conf.

---------------------------------------------------
Setup COMPLETE.

client#
例 23–7 コマンド行指定の優先を利用して Kerberos クライアントを自動的に構成する

次の例は、インストールプロファイルに設定されている DNSARG パラメータと KDC パラメータに対しコマンド行での指定が優先します。


# /usr/sbin/kclient -p /net/denver.example.com/export/install/profile\
-d dns_fallback -k kdc2.example.com

Starting client setup
---------------------------------------------------

kdc1.example.com

Setting up /etc/krb5/krb5.conf.

Obtaining TGT for clntconfig/admin ...
Password for clntconfig/admin@EXAMPLE.COM: <Type the password>

nfs/client.example.com entry ADDED to KDC database.
nfs/client.example.com entry ADDED to keytab.

host/client.example.com entry ADDED to KDC database.
host/client.example.com entry ADDED to keytab.

Copied /net/denver.example.com/export/install/krb5.conf.

---------------------------------------------------
Setup COMPLETE.

client#

ProcedureKerberos クライアントを対話的に構成する方法

この手順では、インストールプロファイルなしで kclient インストールユーティリティーを使用します。

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

  2. kclient インストールスクリプトを実行します。

    インストールには、次の情報が必要です。

    • Kerberos レルム名

    • KDC マスターホスト名

    • 管理主体名

    • 管理主体のパスワード

例 23–8 kclient インストールユーティリティーの実行

次の出力は、kclient コマンドの実行結果を示しています。


client# /usr/sbin/kclient

Starting client setup
---------------------------------------------------

Do you want to use DNS for kerberos lookups ? [y/n]: n
        No action performed.
Enter the Kerberos realm: EXAMPLE.COM
Specify the KDC hostname for the above realm: kdc1.example.com

Setting up /etc/krb5/krb5.conf.

Enter the krb5 administrative principal to be used: clntconfig/admin
Obtaining TGT for clntconfig/admin ...
Password for clntconfig/admin@EXAMPLE.COM: <Type the password>
Do you plan on doing Kerberized nfs ? [y/n]: n

host/client.example.com entry ADDED to KDC database.
host/client.example.com entry ADDED to keytab.

Do you want to copy over the master krb5.conf file ? [y/n]: y
Enter the pathname of the file to be copied: \
/net/denver.example.com/export/install/krb5.conf

Copied /net/denver.example.com/export/install/krb5.conf.

---------------------------------------------------
Setup COMPLETE !
#

ProcedureKerberos クライアントを手動で構成する方法

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

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

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

    デフォルトの Kerberos ファイルを変更する場合は、レルム名とサーバー名を変更する必要があります。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
    注 –

    暗号化タイプを制限する場合は、default_tkt_enctypes または default_tgs_enctypes の行を設定します。暗号化タイプの制限に関する詳細は、「Kerberos 暗号化タイプの使用」を参照してください。

  3. (省略可能) KDC の検出に使用されるプロセスを変更します。

    Solaris 10 5/08 リリース以降のデフォルトでは、Kerberos レルムから KDC へのマッピングが決定される順序は次のとおりです。

    • krb5.conf 内の realms セクションの定義。

    • DNS 内の SRV レコードの検索による。

    krb5.conf ファイルの libdefaults セクションに dns_lookup_kdc または dns_fallback を追加して、この動作を変更できます。詳細は、krb5.conf(4) のマニュアルページを参照してください。常にリフェラルが最初に試行されます。

  4. (省略可能) ホストのレルムの決定に使用されるプロセスを変更します。

    Solaris 10 5/08 リリース以降のデフォルトでは、ホストからレルムへのマッピングが決定される順序は次のとおりです。

    • KDC がリフェラルをサポートしている場合は、KDC からクライアントに、ホストが属しているレルムが通知されることがある。

    • krb5.conf ファイル内の domain_realm の定義による。

    • ホストの DNS ドメイン名。

    • デフォルトレルム。

    krb5.conf ファイルの libdefaults セクションに dns_lookup_kdc または dns_fallback を追加して、この動作を変更できます。詳細は、krb5.conf(4) のマニュアルページを参照してください。常にリフェラルが最初に試行されます。

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

    Network Time Protocol (NTP) のインストールと使用は必要はありません。ただし、認証が正常終了するには、すべてのクロックが、krb5.conf ファイル内の clockskew 関係指定子で定義されている最大の誤差以内で KDC サーバー上の時刻と同期化されている必要があります。NTP については、「KDC と Kerberos クライアントのクロックの同期化」を参照してください。

  6. kadmin を起動します。

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


    denver # /usr/sbin/kadmin -p kws/admin
Enter password: <Type kws/admin password>
kadmin:

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

      このホストに関連付けられているユーザーに主体が割り当てられていない場合だけ、ユーザー主体を作成します。


      kadmin: addprinc mre
Enter password for principal mre@EXAMPLE.COM: <Type the password>
Re-enter password for principal mre@EXAMPLE.COM: <Type it again>
kadmin:

    2. (省略可能) root 主体を作成し、その主体をサーバーのキータブファイルに追加します。

      この手順は、クライアントが NFS サービスによってマウントされたファイルシステムに root アクセスを持つために必要です。また、cron ジョブを root として実行する場合など、非対話的な root アクセスが必要な場合にもこの手順が必要になります。

      クライアントが NFS サービスを使用してマウントされている遠隔ファイルシステムへの root アクセスを必要としない場合は、この手順をスキップできます。root 主体は 2 つの構成要素主体とすべきであり、二番目の構成要素は Kerberos クライアントシステムのホスト名にして、レルム幅の root 主体の作成を回避します。主体のインスタンスがホスト名のときは、/etc/resolv.conf ファイル内のドメイン名が大文字であるか小文字であるかに関係なく、FQDN は小文字で指定する必要があります。


      kadmin: addprinc -randkey root/client.example.com
Principal "root/client.example.com" created.
kadmin: ktadd root/client.example.com
Entry for principal root/client.example.com with kvno 3, encryption type AES-256 CTS mode
          with 96-bit SHA-1 HMAC added to keytab WRFILE:/etc/krb5/krb5.keytab.
Entry for principal root/client.example.com with kvno 3, encryption type AES-128 CTS mode
          with 96-bit SHA-1 HMAC added to keytab WRFILE:/etc/krb5/krb5.keytab.
Entry for principal root/client.example.com with kvno 3, encryption type Triple DES cbc
          mode with HMAC/sha1 added to keytab WRFILE:/etc/krb5/krb5.keytab.
Entry for principal root/client.example.com with kvno 3, encryption type ArcFour
          with HMAC/md5 added to keytab WRFILE:/etc/krb5/krb5.keytab.
Entry for principal root/client.example.com with kvno 3, encryption type DES cbc mode
          with RSA-MD5 added to keytab WRFILE:/etc/krb5/krb5.keytab.
kadmin:

    3. host 主体を作成し、その主体をサーバーのキータブファイルに追加します。

      host 主体は、認証を提供するために遠隔アクセスサービスによって使用されます。キータブファイルにまだ資格が存在しない場合は、この主体によって root が資格を取得できるようになります。


      kadmin: addprinc -randkey host/denver.example.com
Principal "host/denver.example.com@EXAMPLE.COM" created.
kadmin: ktadd host/denver.example.com
Entry for principal host/denver.example.com with kvno 3, encryption type AES-256 CTS mode
          with 96-bit SHA-1 HMAC added to keytab WRFILE:/etc/krb5/krb5.keytab.
Entry for principal host/denver.example.com with kvno 3, encryption type AES-128 CTS mode
          with 96-bit SHA-1 HMAC added to keytab WRFILE:/etc/krb5/krb5.keytab.
Entry for principal host/denver.example.com with kvno 3, encryption type Triple DES cbc
          mode with HMAC/sha1 added to keytab WRFILE:/etc/krb5/krb5.keytab.
Entry for principal host/denver.example.com with kvno 3, encryption type ArcFour
          with HMAC/md5 added to keytab WRFILE:/etc/krb5/krb5.keytab.
Entry for principal host/denver.example.com with kvno 3, encryption type DES cbc mode
          with RSA-MD5 added to keytab WRFILE:/etc/krb5/krb5.keytab.
kadmin:

    4. (省略可能) サーバーの NFS サービス主体をサーバーのキータブファイルに追加します。

      この手順が必要になるのは、クライアントが Kerberos 認証を使用する NFS ファイルシステムにアクセスする必要がある場合だけです。


      kadmin: ktadd nfs/denver.example.com
Entry for principal nfs/denver.example.com with kvno 3, encryption type AES-256 CTS mode
          with 96-bit SHA-1 HMAC added to keytab WRFILE:/etc/krb5/krb5.keytab.
Entry for principal nfs/denver.example.com with kvno 3, encryption type AES-128 CTS mode
          with 96-bit SHA-1 HMAC added to keytab WRFILE:/etc/krb5/krb5.keytab.
Entry for principal nfs/denver.example.com with kvno 3, encryption type Triple DES cbc
          mode with HMAC/sha1 added to keytab WRFILE:/etc/krb5/krb5.keytab.
Entry for principal nfs/denver.example.com with kvno 3, encryption type ArcFour
          with HMAC/md5 added to keytab WRFILE:/etc/krb5/krb5.keytab.
Entry for principal nfs/denver.example.com with kvno 3, encryption type DES cbc mode
          with RSA-MD5 added to keytab WRFILE:/etc/krb5/krb5.keytab.
kadmin:

    5. kadmin を終了します。


      kadmin: quit

  7. (省略可能) NFS での Kerberos を有効にします。

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

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


      # cat /etc/nfssec.conf
 .
 .
#
# Uncomment the following lines to use Kerberos V5 with NFS
#
krb5            390003  kerberos_v5     default -               # RPCSEC_GSS
krb5i           390004  kerberos_v5     default integrity       # RPCSEC_GSS
krb5p           390005  kerberos_v5     default privacy         # RPCSEC_GSS

    2. DNS を有効にします。

      /etc/resolv.conf ファイルがまだ作成されていない場合は、このファイルを作成します。サービス主体の正規化は DNS に依存して正規化を実行するためです。詳細は、resolv.conf(4) のマニュアルページを参照してください。

    3. gssd サービスを再開します。

      /etc/resolv.conf ファイルを作成または変更したら、gssd デーモンを再起動して、すべての変更を再読み込みする必要があります。


      # svcadm restart network/rpc/gss

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

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

例 23–9 Solaris 以外の KDC を使用するように Kerberos クライアントを設定する

Solaris 以外の KDC を使用するように Kerberos クライアントを設定することができます。この場合、/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
        }
例 23–10 ホスト名とドメイン名を Kerberos レルムにマッピングするための DNS TXT レコード


@ IN SOA kdc1.example.com root.kdc1.example.com (
                                1989020501   ;serial
                                10800        ;refresh
                                3600         ;retry
                                3600000      ;expire
                                86400 )      ;minimum

                        IN      NS      kdc1.example.com.
kdc1                    IN      A       192.146.86.20
kdc2                    IN      A       192.146.86.21

_kerberos.example.com.             IN      TXT     "EXAMPLE.COM"
_kerberos.kdc1.example.com.        IN      TXT     "EXAMPLE.COM"
_kerberos.kdc2.example.com.        IN      TXT     "EXAMPLE.COM"
例 23–11 Kerberos サーバーの場所を記録する DNS SRV レコード

この例は、KDC、admin サーバー、および kpasswd サーバーの場所を記録するレコードを定義します。


@ IN SOA kdc1.example.com root.kdc1.example.com (
                                1989020501   ;serial
                                10800        ;refresh
                                3600         ;retry
                                3600000      ;expire
                                86400 )      ;minimum

                                   IN      NS      kdc1.example.com.
kdc1                               IN      A       192.146.86.20
kdc2                               IN      A       192.146.86.21

_kerberos._udp.EXAMPLE.COM         IN      SRV 0 0 88  kdc2.example.com
_kerberos._tcp.EXAMPLE.COM         IN      SRV 0 0 88  kdc2.example.com
_kerberos._udp.EXAMPLE.COM         IN      SRV 1 0 88  kdc1.example.com
_kerberos._tcp.EXAMPLE.COM         IN      SRV 1 0 88  kdc1.example.com
_kerberos-adm._tcp.EXAMPLE.COM     IN      SRV 0 0 749 kdc1.example.com
_kpasswd._udp.EXAMPLE.COM          IN      SRV 0 0 749 kdc1.example.com

Procedureチケット認可チケット (TGT) の確認を無効にする方法

この手順では、ローカルの /etc/krb5/krb5.keytab ファイルに保存されているホスト主体の KDC とチケット認可チケットを発行した KDC が同じであることを確認するセキュリティー検査を無効にします。この検査は DNS の偽装攻撃を防止します。ただし、一部のクライアント構成では、ホスト主体を使用できない場合があるため、クライアントが機能できるようにこの検査を無効にする必要があります。次のような構成では、この検査を無効にする必要があります。

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

  2. krb5.conf ファイルを変更します。

    verify_ap_req_nofail オプションが false に設定されている場合、TGT の確認処理は無効になっています。このオプションの詳細については、krb5.conf(4) のマニュアルページを参照してください。


    client # cat /etc/krb5/krb5.conf
[libdefaults]
        default_realm = EXAMPLE.COM
        verify_ap_req_nofail = false
  ...
    注 –

    verify_ap_req_nofail オプションは、krb5.conf ファイルの [libdefaults] セクションまたは [realms] セクションに入力できます。このオプションを [libdefaults] セクションに入力すると、設定はすべてのレルムに使用されます。このオプションを [realms] セクションに入力すると、設定は定義したレルムだけに適用されます。

ProcedureKerberos によって保護された NFS ファイルシステムに root ユーザーとしてアクセスする方法

この手順を実行すると、クライアントは root の ID 特権による Kerberos 認証を必要とする、NFS ファイルシステムにアクセスできるようになります。特に、NFS ファイルシステムが次のようなオプションによって共有されている場合です。-o sec=krb5,root=client1.sun.com

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

  2. kadmin を起動します。

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


    denver # /usr/sbin/kadmin -p kws/admin
Enter password: <Type kws/admin password>
kadmin:

    1. NFS クライアントの root 主体を作成します。

      この主体は、Kerberos 認証を必要とする、NFS マウントされたファイルシステムにスーパーユーザーと同様にアクセスするために使用されます。root 主体は 2 つの構成要素主体とすべきであり、二番目の構成要素は Kerberos クライアントシステムのホスト名にして、レルム幅の root 主体の作成を回避します。主体のインスタンスがホスト名のときは、/etc/resolv.conf ファイル内のドメイン名が大文字であるか小文字であるかに関係なく、FQDN は小文字で指定する必要があります。


      kadmin: addprinc -randkey root/client.example.com
Principal "root/client.example.com" created.
kadmin:

    2. サーバーのキータブファイルに root 主体を追加します。

      NFS サービスを使ってマウントされたファイルシステムにクライアントが root アクセスできるように root 主体を追加する場合にこの手順は必要になります。また、cron ジョブを root として実行する場合など、非対話的な root アクセスが必要な場合にもこの手順が必要になります。


      kadmin: ktadd root/client.example.com
Entry for principal root/client.example.com with kvno 3, encryption type AES-256 CTS mode
          with 96-bit SHA-1 HMAC added to keytab WRFILE:/etc/krb5/krb5.keytab.
Entry for principal root/client.example.com with kvno 3, encryption type AES-128 CTS mode
          with 96-bit SHA-1 HMAC added to keytab WRFILE:/etc/krb5/krb5.keytab.
Entry for principal root/client.example.com with kvno 3, encryption type Triple DES cbc
          mode with HMAC/sha1 added to keytab WRFILE:/etc/krb5/krb5.keytab.
Entry for principal root/client.example.com with kvno 3, encryption type ArcFour
          with HMAC/md5 added to keytab WRFILE:/etc/krb5/krb5.keytab.
Entry for principal root/client.example.com with kvno 3, encryption type DES cbc mode
          with RSA-MD5 added to keytab WRFILE:/etc/krb5/krb5.keytab.
kadmin:

    3. kadmin を終了します。


      kadmin: quit

ProcedureKerberos レルム内のユーザーを自動的に移行するように構成する方法

Kerberos 主体を持たないユーザーを、既存の Kerberos レルムに自動的に移行できます。移行を行うには、/etc/pam.conf のサーバーの認証スタックにある pam_krb5_migrate モジュールの積み重ねにより使用されているサービス用の PAM フレームワークを使用します。

この例では、dtlogin と other の PAM サービス名が構成され、自動移行を使用します。この手順では、次の構成パラメータを使用します。

始める前に

レルム EXAMPLE.COM の Kerberos クライアントとして server1 を設定します。詳細は、「Kerberos クライアントの構成」を参照してください。

  1. server1 のホストサービス主体が存在するかどうかを確認します。

    server1 の keytab ファイル内のホストサービス主体は、マスター KDC にサーバーを認証するために使用されます。


    server1 # klist -k
Keytab name: FILE:/etc/krb5/krb5.keytab
	KVNO Principal
	---- ------------------------------------------------
	   3 host/server1.example.com@EXAMPLE.COM
	   3 host/server1.example.com@EXAMPLE.COM
	   3 host/server1.example.com@EXAMPLE.COM
	   3 host/server1.example.com@EXAMPLE.COM

  2. PAM 構成ファイルを変更します。

    1. dtlogin サービスのエントリを追加します。


      # cat /etc/pam.conf
 .
 .
#
# dtlogin service (explicit because of pam_krb5_migrate)
#
dtlogin       auth requisite          pam_authtok_get.so.1
dtlogin       auth required           pam_dhkeys.so.1
dtlogin       auth required           pam_unix_cred.so.1
dtlogin       auth sufficient         pam_krb5.so.1
dtlogin       auth requisite          pam_unix_auth.so.1
dtlogin       auth optional           pam_krb5_migrate.so.1

    2. (省略可能) 必要に応じて、即座のパスワードの変更を強制します。

      新しく作成された Kerberos アカウントは、即座の Kerberos パスワードの変更を強制するために、パスワードの有効期限が現在時刻 (今) に設定されています。有効期限を現在時刻に設定するには、pam_krb5_migrate モジュールを使用する行に expire_pw オプションを追加します。詳細は、pam_krb5_migrate(5) のマニュアルページを参照してください。


      # cat /etc/pam.conf
 .
 .
dtlogin  auth optional           pam_krb5_migrate.so.1 expire_pw

    3. pam_krb5 モジュールをアカウントスタックに追加します。

      この追加により、Kerberos のパスワードの有効期限でアクセスをブロックできるようになります。


      # cat /etc/pam.conf
 .
 .
#
# Default definition for Account management
# Used when service name is not explicitly mentioned for account management
#
other   account requisite       pam_roles.so.1
other   account required        pam_krb5.so.1
other   account required        pam_unix_account.so.1

    4. pam_krb5 モジュールをパスワードスタックに追加します。

      この追加により、パスワードが期限切れになったらパスワードを更新できるようになります。


      # cat /etc/pam.conf
 .
 .
#
# Default definition for Password management
# Used when service name is not explicitly mentioned for password management
#
other   password required       pam_dhkeys.so.1
other   password requisite      pam_authtok_get.so.1
other   password requisite      pam_authtok_check.so.1
other   password sufficient     pam_krb5.so.1
other   password required       pam_authtok_store.so.1

  3. マスター KDC 上で、アクセス制御ファイルを更新します。

    次のエントリが、root 以外のすべてのユーザーの host/server1.example.com サービス主体に対して、次のエントリは特権の付与、移行、および照会を行います。移行すべきでないユーザーは、kadm5.acl ファイル内で、U 特権を使って示されます。これらのエントリは、permit all または ui エントリの前に置く必要があります。詳細は、kadm5.acl(4) のマニュアルページを参照してください。


    kdc1 # cat /etc/krb5/kadm5.acl
host/server1.example.com@EXAMPLE.COM U root
host/server1.example.com@EXAMPLE.COM ui *
*/admin@EXAMPLE.COM *

  4. マスター KDC 上で、Kerberos 管理デーモンを再起動します。

    この手順により、kadmind デーモンが新しい kadm5.acl エントリを使用できるようになります。


    kdc1 # svcadm restart network/security/kadmin

  5. マスター KDC 上で、pam.conf ファイルにエントリを追加します。

    次のエントリにより、kadmind デーモンが k5migrate PAM サービスを使用して、移行に必要なアカウントの UNIX ユーザーパスワードを検査できるようになります。


    # grep k5migrate /etc/pam.conf
k5migrate        auth    required        pam_unix_auth.so.1
k5migrate        account required        pam_unix_account.so.1

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

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

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

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

注 –

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

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

注 –

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

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

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

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

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

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

  1. ネットワークに NTP サーバーを設定します。NTP サーバーは、マスター KDC 以外であればどのシステムでも設定できます。NTP サーバーの作業については、『Solaris のシステム管理 (ネットワークサービス)』の「NTP の管理 (作業)」を参照してください。

  2. ネットワークの KDC と Kerberos クライアントを構成するときに、それらを NTP サーバーの NTP クライアントとして設定します。NTP クライアントの作業については、『Solaris のシステム管理 (ネットワークサービス)』の「NTP の管理 (作業)」を参照してください。

マスター KDC とスレーブ KDC の入れ替え

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

Procedure入れ替え可能なスレーブ KDC を構成する方法

この手順は、マスター KDC に入れ替え可能なスレーブ KDC に対して実行します。この手順は、増分伝播を使用していることを想定しています。

  1. KDC をインストールするときに、マスター KDC および入れ替え可能なスレーブ KDC に対して別名を使用します。

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

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

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

  3. マスター 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

Procedureマスター KDC とスレーブ KDC を入れ替えする方法

この手順では、旧マスター KDC サーバー名は、kdc1 です。新しいマスター KDC となるスレーブ KDC の名前は、kdc4 です。この手順は、増分伝播を使用していることを想定しています。

始める前に

この手順を実行するには、スレーブ KDC が入れ替え可能なスレーブとして設定されている必要があります。詳細は、「入れ替え可能なスレーブ KDC を構成する方法」を参照してください。

  1. 新しいマスター KDC 上で、kadmin を起動します。


    kdc4 # /usr/sbin/kadmin -p kws/admin
Enter password: <Type kws/admin password>
kadmin:

    1. kadmind サービスの新しい主体を作成します。

      次の例では、addprinc が 2 行で表示されていますが、1 行に入力する必要があります。


      kadmin: addprinc -randkey -allow_tgs_req +password_changing_service -clearpolicy \
       changepw/kdc4.example.com
Principal "changepw/kdc4.example.com@ENG.SUN.COM" created.
kadmin: addprinc -randkey -allow_tgs_req -clearpolicy kadmin/kdc4.example.com
Principal "kadmin/kdc4.example.com@EXAMPLE.COM" created.
kadmin:

    2. キータブファイルを作成します。


      kadmin: ktadd -k /etc/krb5/kadm5.keytab kadmin/kdc4.example.com
Entry for principal kadmin/kdc4.example.com with kvno 3, encryption type AES-256 CTS mode
          with 96-bit SHA-1 HMAC added to keytab WRFILE:/etc/krb5/kadm5.keytab.
Entry for principal kadmin/kdc4.example.com with kvno 3, encryption type AES-128 CTS mode
          with 96-bit SHA-1 HMAC added to keytab WRFILE:/etc/krb5/kadm5.keytab.
Entry for principal kadmin/kdc4.example.com with kvno 3, encryption type Triple DES cbc
          mode with HMAC/sha1 added to keytab WRFILE:/etc/krb5/kadm5.keytab.
Entry for principal kadmin/kdc4.example.com with kvno 3, encryption type ArcFour
          with HMAC/md5 added to keytab WRFILE:/etc/krb5/kadm5.keytab.
Entry for principal kadmin/kdc4.example.com with kvno 3, encryption type DES cbc mode
          with RSA-MD5 added to keytab WRFILE:/etc/krb5/kadm5.keytab.
kadmin: ktadd -k /etc/krb5/kadm5.keytab changepw/kdc4.example.com
Entry for principal changepw/kdc4.example.com with kvno 3, encryption type AES-256 CTS mode
          with 96-bit SHA-1 HMAC added to keytab WRFILE:/etc/krb5/kadm5.keytab.
Entry for principal changepw/kdc4.example.com with kvno 3, encryption type AES-128 CTS mode
          with 96-bit SHA-1 HMAC added to keytab WRFILE:/etc/krb5/kadm5.keytab.
Entry for principal changepw/kdc4.example.com with kvno 3, encryption type Triple DES cbc
          mode with HMAC/sha1 added to keytab WRFILE:/etc/krb5/kadm5.keytab.
Entry for principal changepw/kdc4.example.com with kvno 3, encryption type ArcFour
          with HMAC/md5 added to keytab WRFILE:/etc/krb5/kadm5.keytab.
Entry for principal changepw/kdc4.example.com with kvno 3, encryption type DES cbc mode
          with RSA-MD5 added to keytab WRFILE:/etc/krb5/kadm5.keytab.
kadmin: ktadd -k /etc/krb5/kadm5.keytab kadmin/changepw
Entry for principal kadmin/changepw with kvno 3, encryption type AES-256 CTS mode
          with 96-bit SHA-1 HMAC added to keytab WRFILE:/etc/krb5/kadm5.keytab.
Entry for principal kadmin/changepw with kvno 3, encryption type AES-128 CTS mode
          with 96-bit SHA-1 HMAC added to keytab WRFILE:/etc/krb5/kadm5.keytab.
Entry for principal kadmin/changepw with kvno 3, encryption type Triple DES cbc
          mode with HMAC/sha1 added to keytab WRFILE:/etc/krb5/kadm5.keytab.
Entry for principal kadmin/changepw with kvno 3, encryption type ArcFour
          with HMAC/md5 added to keytab WRFILE:/etc/krb5/kadm5.keytab.
Entry for principal kadmin/changepw with kvno 3, encryption type DES cbc mode
          with RSA-MD5 added to keytab WRFILE:/etc/krb5/kadm5.keytab.
kadmin:

    3. kadmin を終了します。


      kadmin: quit

  2. 新しいマスター KDC 上で、同期を強制します。

    次の手順は、スレーブサーバー上で強制的に KDC を完全に更新します。


    kdc4 # svcadm disable network/security/krb5kdc
kdc4 # rm /var/krb5/principal.ulog

  3. 新しいマスター KDC 上で、更新が完了したことを確認します。


    kdc4 # /usr/sbin/kproplog -h

  4. 新しいマスター KDC 上で、KDC サービスを再開します。


    kdc4 # svcadm enable -r network/security/krb5kdc

  5. 新しいマスター KDC 上で、更新ログを消去します。

    この手順は、新しいマスター KDC サーバーの更新ログを再度初期化します。


    kdc4 # svcadm disable network/security/krb5kdc
kdc4 # rm /var/krb5/principal.ulog

  6. 旧マスター KDC 上で、kadmind プロセスとkrb5kdc プロセスを終了します。

    kadmind プロセスを終了するときは、旧 KDC データベースに対する変更は行わないでください。


    kdc1 # svcadm disable network/security/kadmin
kdc1 # svcadm disable network/security/krb5kdc

  7. 旧マスター KDC 上で、伝播を要求するポーリング時間を指定します。

    /etc/krb5/kdc.conf 内の sunw_dbprop_master_ulogsize エントリをコメントにして、sunw_dbprop_slave_poll を定義するエントリを追加します。エントリは、ポーリング時間を 2 分に設定します。


    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
                sunw_dbprop_enable = true
#               sunw_dbprop_master_ulogsize = 1000
                sunw_dbprop_slave_poll = 2m
        }

  8. 旧マスター KDC 上で、マスター KDC コマンドと kadm5.acl ファイルを移動します。

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


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

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

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


    masterkdc IN CNAME kdc4

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

    次のコマンドを実行して、新しい別名情報を再ロードします。


    # svcadm refresh network/dns/server

  11. 新しいマスター KDC 上で、マスター KDC コマンドとスレーブ kpropd.acl ファイルを移動します。


    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
kdc4 # mv /etc/krb5/kpropd.acl /etc/krb5/kpropd.acl.save

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

    作成された /etc/krb5/kadm5.acl ファイルには、KDC を管理できる主体名がすべて含まれている必要があります。このファイルには、増分伝播を要求するすべてのスレーブもリストされている必要があります。詳細は、kadm5.acl(4) のマニュアルページを参照してください。


    kdc4 # cat /etc/krb5/kadm5.acl
kws/admin@EXAMPLE.COM   *
kiprop/kdc1.example.com@EXAMPLE.COM p

  13. 新しいマスター KDC 上で、kdc.conf ファイル内の更新ログのサイズを指定します。

    sunw_dbprop_slave_poll エントリをコメントにして、sunw_dbprop_master_ulogsize を定義するエントリを追加します。エントリは、ログサイズを 1000 エントリに設定します。


    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
                sunw_dbprop_enable = true
#               sunw_dbprop_slave_poll = 2m
                sunw_dbprop_master_ulogsize = 1000
        }

  14. 新しいマスター KDC 上で、kiprop 主体を kadmind キータブファイルに追加します。


    kdc4 # kadmin.local
kadmin.local: ktadd -k /etc/krb5/kadm5.keytab kiprop/kdc4.example.com
Entry for principal kiprop/kdc4.example.com with kvno 3, encryption type AES-256 CTS mode
          with 96-bit SHA-1 HMAC added to keytab WRFILE:/etc/krb5/kadm5.keytab.
Entry for principal kiprop/kdc4.example.com with kvno 3, encryption type AES-128 CTS mode
          with 96-bit SHA-1 HMAC added to keytab WRFILE:/etc/krb5/kadm5.keytab.
Entry for principal kiprop/kdc4.example.com with kvno 3, encryption type Triple DES cbc
          mode with HMAC/sha1 added to keytab WRFILE:/etc/krb5/kadm5.keytab.
Entry for principal kiprop/kdc4.example.com with kvno 3, encryption type ArcFour
          with HMAC/md5 added to keytab WRFILE:/etc/krb5/kadm5.keytab.
Entry for principal kiprop/kdc4.example.com with kvno 3, encryption type DES cbc mode
          with RSA-MD5 added to keytab WRFILE:/etc/krb5/kadm5.keytab.
kadmin.local: quit

  15. 新しいマスター KDC 上で、kadmind と krb5kdc を実行します。


    kdc4 # svcadm enable -r network/security/krb5kdc
kdc4 # svcadm enable -r network/security/kadmin

  16. 旧マスター KDC 上で、kiprop サービス主体を追加します。

    krb5.keytab ファイルに kiprop 主体を追加すると、増分伝播サービスに対してkpropd デーモンが自身を認証できるようになります。


    kdc1 # /usr/sbin/kadmin -p kws/admin
Authenticating as pricipal kws/admin@EXAMPLE.COM with password.
Enter password: <Type kws/admin password>
kadmin: ktadd kiprop/kdc1.example.com
Entry for principal kiprop/kdc1.example.com with kvno 3, encryption type AES-256 CTS mode
          with 96-bit SHA-1 HMAC added to keytab WRFILE:/etc/krb5/krb5.keytab.
Entry for principal kiprop/kdc1.example.com with kvno 3, encryption type AES-128 CTS mode
          with 96-bit SHA-1 HMAC added to keytab WRFILE:/etc/krb5/krb5.keytab.
Entry for principal kiprop/kdc1.example.com with kvno 3, encryption type Triple DES cbc
          mode with HMAC/sha1 added to keytab WRFILE:/etc/krb5/krb5.keytab.
Entry for principal kiprop/kdc1.example.com with kvno 3, encryption type ArcFour
          with HMAC/md5 added to keytab WRFILE:/etc/krb5/krb5.keytab.
Entry for principal kiprop/kdc1.example.com with kvno 3, encryption type DES cbc mode
          with RSA-MD5 added to keytab WRFILE:/etc/krb5/krb5.keytab.
kadmin: quit

  17. 旧マスター KDC 上で、krb5.conf にリストされた各 KDC のエントリを伝播構成ファイル kpropd.acl に追加します。


    kdc1 # cat /etc/krb5/kpropd.acl
host/kdc1.example.com@EXAMPLE.COM
host/kdc2.example.com@EXAMPLE.COM
host/kdc3.example.com@EXAMPLE.COM
host/kdc4.example.com@EXAMPLE.COM

  18. 旧マスター KDC 上で、kpropd と krb5kdc を実行します。

    krb5kdc デーモンが起動すると、システムがスレーブとして構成されている場合、kpropd も起動します。


    kdc1 # svcadm enable network/security/krb5kdc

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 の主体名だけを指定する必要があります。

ただし、このマニュアルの Kerberos のインストールおよびインストール後の構成手順では、マスター 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 データベースは、伝播が完了するまでロックされます。

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

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

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


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

    バックアップする各主体とポリシー名を出力します。

    dbname

    バックアップするデータベース名を定義します。ファイルの絶対パスを指定できます。-d オプションを指定しない場合、デフォルトのデータベース名は /var/krb5/principal となります。

    filename

    データベースのバックアップに使用するファイルを定義します。ファイルの絶対パスを指定できます。ファイルを指定しなかった場合、データベースは標準出力にダンプされます。

    principals

    バックアップする主体を 1 つ以上定義します (区切り文字は空白)。主体名は完全指定形式にする必要があります。主体を指定しなかった場合、データベース全体がバックアップされます。

例 23–12 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

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

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

  2. マスター上で、KDC デーモンを終了します。


    kdc1 # svcadm disable network/security/krb5kdc
kdc1 # svcadm disable network/security/kadmin

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


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

    復元する各主体とポリシー名を出力します。

    dbname

    復元するデータベース名を定義します。ファイルの絶対パスを指定できます。-d オプションを指定しない場合、デフォルトのデータベース名は /var/krb5/principal となります。

    -update

    既存のデータベースを更新します。指定しない場合、新しいデータベースが作成されるか、既存のデータベースが上書きされます。

    filename

    データベースの復元に使用するファイルを定義します。ファイルの絶対パスを指定できます。

  4. KDC デーモンを起動します。


    kdc1 # svcadm enable -r network/security/krb5kdc
kdc1 # svcadm enable -r network/security/kadmin
例 23–13 Kerberos データベースの復元

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


# kdb5_util load -d database1 dumpfile

Procedureサーバーのアップグレード後に Kerberos データベースを変換する方法

Solaris 8 または Solaris 9 リリースが稼働するサーバー上で KDC データベースが作成されている場合、データベースを変換すると、改善されたデータベースのフォーマットを利用することができます。

始める前に

データベースが古いフォーマットを使用していることを確認してください。

  1. マスター上で、KDC デーモンを終了します。


    kdc1 # svcadm disable network/security/krb5kdc
kdc1 # svcadm disable network/security/kadmin

  2. データベースの一時的なコピーを格納するためのディレクトリを作成します。


    kdc1 # mkdir /var/krb5/tmp
kdc1 # chmod 700 /var/krb5/tmp

  3. KDC データベースをダンプします。


    kdc1 # kdb5_util dump /var/krb5/tmp/prdb.txt

  4. 現在のデータベースファイルのコピーを保存します。


    kdc1 # cd /var/krb5
kdc1 # mv princ* tmp/

  5. データベースをロードします。


    kdc1 # kdb5_util load /var/krb5/tmp/prdb.txt

  6. KDC デーモンを起動します。


    kdc1 # svcadm enable -r network/security/krb5kdc
kdc1 # svcadm enable -r network/security/kadmin

Procedureマスター KDC を再構成して増分伝播を使用する方法

この手順を使って、増分伝播を使用するように既存のマスター KDC を再構成します。この手順では、次の構成パラメータを使用します。

  1. 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
                sunw_dbprop_enable = true
                sunw_dbprop_master_ulogsize = 1000
        }

  2. kiprop 主体を作成します。

    kiprop 主体は、マスター KDC サーバーの認証とマスター KDC からの更新の認証に使用されます。


    kdc1 # /usr/sbin/kadmin -p kws/admin
Enter password: <Type kws/admin password>
kadmin: addprinc -randkey kiprop/kdc1.example.com
Principal "kiprop/kdc1.example.com@EXAMPLE.COM" created.
kadmin: addprinc -randkey kiprop/kdc2.example.com
Principal "kiprop/kdc2.example.com@EXAMPLE.COM" created.
kadmin:

  3. kadmind キータブファイルに kiprop 主体を追加します。

    kadm5.keytab に kiprop 主体を追加すると、起動時に kadmind コマンドが自身を認証できます。


    kadmin: ktadd -k /etc/krb5/kadm5.keytab kiprop/kdc1.example.com
Entry for principal kiprop/kdc1.example.com with kvno 3, encryption type AES-256 CTS mode
          with 96-bit SHA-1 HMAC added to keytab WRFILE:/etc/krb5/kadm5.keytab.
Entry for principal kiprop/kdc1.example.com with kvno 3, encryption type AES-128 CTS mode
          with 96-bit SHA-1 HMAC added to keytab WRFILE:/etc/krb5/kadm5.keytab.
Entry for principal kiprop/kdc1.example.com with kvno 3, encryption type Triple DES cbc
          mode with HMAC/sha1 added to keytab WRFILE:/etc/krb5/kadm5.keytab.
Entry for principal kiprop/kdc1.example.com with kvno 3, encryption type ArcFour
          with HMAC/md5 added to keytab WRFILE:/etc/krb5/kadm5.keytab.
Entry for principal kiprop/kdc1.example.com with kvno 3, encryption type DES cbc mode
          with RSA-MD5 added to keytab WRFILE:/etc/krb5/kadm5.keytab.
kadmin: quit

  4. マスター KDC 上で、kadm5.acl に kiprop エントリを追加します。

    このエントリにより、マスター KDC が kdc2 サーバーから増分伝播の要求を受け取ることができるようになります。


    kdc1 # cat /etc/krb5/kadm5.acl
*/admin@EXAMPLE.COM *
kiprop/kdc2.example.com@EXAMPLE.COM p

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

    この手順により、マスター KDC が KDC データベースのコピーを伝播しなくなります。


    kdc1 # crontab -e
#ident  "@(#)root       1.20    01/11/06 SMI"
#
# The root crontab should be used to perform accounting data collection.
#
# The rtc command is run to adjust the real time clock if and when
# daylight savings time changes.
#
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 kdc2.example.sun.com #SUNWkr5ma

  6. kadmind を再起動します。


    kdc1 # svcadm restart network/security/kadmin

  7. 増分伝播を使用するすべてのスレーブ KDC サーバーを再構成します。

    詳細な手順については、「スレーブ KDC を再構成して増分伝播を使用する方法」を参照してください。

Procedureスレーブ KDC を再構成して増分伝播を使用する方法

  1. krb5.conf にエントリを追加します。

    新しいエントリにより、増分伝播が有効にされ、ポーリング時間が 2 分に設定されます。


    kdc2 # cat /etc/krb5/krb5.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
                sunw_dbprop_enable = true
                sunw_dbprop_slave_poll = 2m
        }

  2. krb5.keytab ファイルに kiprop 主体を追加します。


    kdc2 # /usr/sbin/kadmin -p kws/admin
Enter password: <Type kws/admin password>
kadmin: ktadd kiprop/kdc2.example.com
Entry for principal kiprop/kdc2.example.com with kvno 3, encryption type AES-256 CTS mode
          with 96-bit SHA-1 HMAC added to keytab WRFILE:/etc/krb5/krb5.keytab.
Entry for principal kiprop/kdc2.example.com with kvno 3, encryption type AES-128 CTS mode
          with 96-bit SHA-1 HMAC added to keytab WRFILE:/etc/krb5/krb5.keytab.
Entry for principal kiprop/kdc2.example.com with kvno 3, encryption type Triple DES cbc
          mode with HMAC/sha1 added to keytab WRFILE:/etc/krb5/krb5.keytab.
Entry for principal kiprop/kdc2.example.com with kvno 3, encryption type ArcFour
          with HMAC/md5 added to keytab WRFILE:/etc/krb5/krb5.keytab.
Entry for principal kiprop/kdc2.example.com with kvno 3, encryption type DES cbc mode
          with RSA-MD5 added to keytab WRFILE:/etc/krb5/krb5.keytab.
kadmin: quit

  3. kpropd を無効にします。


    kdc2 # svcadm disable network/security/krb5_prop

  4. KDC サーバーを再起動します。


    kdc2 # svcadm restart network/security/krb5kdc

Procedure完全伝播を使用するようにスレーブ KDC を構成する方法

この手順は Solaris 10 リリースを実行しているスレーブ KDC サーバーを再構成して完全伝播を使用する方法を示しています。通常、この手順は、マスター KDC サーバーが Solaris 9 リリースまたはそれ以前のリリースのいずれかを実行している場合にのみ使用する必要があります。この場合、マスター KDC サーバーは増分伝播をサポートできないので、伝播が機能するようにスレーブを構成する必要があります。

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

始める前に

マスター KDC が構成済みである必要があります。スレーブ KDC を入れ替え可能にする手順については、「マスター KDC とスレーブ KDC の入れ替え」を参照してください。

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

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

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


    kdc1 # /usr/sbin/kadmin -p kws/admin
Enter password: <Type kws/admin password>
kadmin:

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

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


      kadmin: addprinc -randkey host/kdc3.example.com
Principal "host/kdc3@EXAMPLE.COM" created.
kadmin:

    2. kadmin を終了します。


      kadmin: quit

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

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


    kdc1 # cat /etc/krb5/krb5.conf
 .
 .
[realms]
                EXAMPLE.COM = {
                kdc = kdc1.example.com
                kdc = kdc2.example.com
                kdc = kdc3.example.com
                admin_server = kdc1.example.com
        }

  4. マスター KDC 上で、マスター 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

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

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

    • /etc/krb5/krb5.conf

    • /etc/krb5/kdc.conf

    • /etc/krb5/kpropd.acl

  6. すべてのスレーブ KDC 上で、Kerberos アクセス制御リストファイル kadm5.acl が反映されていないことを確認してください。

    修正前の kadm5.acl ファイルは次のようになっています。


    kdc2 # cat /etc/krb5/kadm5.acl
*/admin@___default_realm___ *

    ファイルに kiprop のエントリがある場合は、それを削除します。

  7. 新しいスレーブ上で、kadmin コマンドを起動します。

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


    kdc2 # /usr/sbin/kadmin -p kws/admin
Enter password: <Type kws/admin password>
kadmin:

    1. kadmin を使用して、スレーブの host 主体をスレーブのキータブファイルに追加します。

      このエントリにより kprop などの Kerberos アプリケーションが機能します。主体のインスタンスがホスト名のときは、/etc/resolv.conf ファイル内のドメイン名が大文字であるか小文字であるかに関係なく、FQDN は小文字で指定する必要があります。


      kadmin: ktadd host/kdc3.example.com
Entry for principal host/kdc3.example.com with kvno 3, encryption type AES-256 CTS mode
          with 96-bit SHA-1 HMAC added to keytab WRFILE:/etc/krb5/krb5.keytab.
Entry for principal host/kdc3.example.com with kvno 3, encryption type AES-128 CTS mode
          with 96-bit SHA-1 HMAC added to keytab WRFILE:/etc/krb5/krb5.keytab.
Entry for principal host/kdc3.example.com with kvno 3, encryption type Triple DES cbc
          mode with HMAC/sha1 added to keytab WRFILE:/etc/krb5/krb5.keytab.
Entry for principal host/kdc3.example.com with kvno 3, encryption type ArcFour
          with HMAC/md5 added to keytab WRFILE:/etc/krb5/krb5.keytab.
Entry for principal host/kdc3.example.com with kvno 3, encryption type DES cbc mode
          with RSA-MD5 added to keytab WRFILE:/etc/krb5/krb5.keytab.
kadmin:

    2. kadmin を終了します。


      kadmin: quit

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

    各スレーブ KDC サーバーの名前を kprop_script 行の末尾に追加します。


    10 3 * * * /usr/lib/krb5/kprop_script kdc2.example.com kdc3.example.com

    バックアップの時刻を変更する場合もあるでしょう。このエントリは、バックアップ処理を毎日午前 3:10 に開始します。

  9. 新しいスレーブ上で、Kerberos 伝播デーモンを起動します。


    kdc3 # svcadm enable network/security/krb5_prop

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

    データベースのバックアップコピーがすでに使用可能な場合は、別のバックアップを完成させる必要はありません。詳細は、「Kerberos データベースをスレーブ KDC に手動で伝播する方法」を参照してください。


    kdc1 # /usr/lib/krb5/kprop_script kdc3.example.com
Database propagation to kdc3.example.com: SUCCEEDED

  11. 新しいスレーブ上で、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: <Type the key>

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

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

  13. 新しいスレーブ上で、KDC デーモン (krb5kdc) を起動します。


    kdc3 # svcadm enable network/security/krb5kdc

ProcedureKDC サーバーが同期しているかを検査する方法

増分伝播が構成されている場合、この手順は、スレーブ KDC 上の情報が更新されたかを確認します。

  1. KDC マスターサーバー上で、kproplog コマンドを実行します。


    kdc1 # /usr/sbin/kproplog -h

  2. KDC スレーブサーバー上で、kproplog コマンドを実行します。


    kdc2 # /usr/sbin/kproplog -h

  3. 最終シリアル番号と最終時刻表示の値が一致するかを確認します。

例 23–14 KDC サーバーが同期しているかを検査する

次の例は、マスター KDC サーバー上での kproplog コマンドの実行結果です。


kdc1 # /usr/sbin/kproplog -h

Kerberos update log (/var/krb5/principal.ulog)
Update log dump:
    Log version #: 1
    Log state: Stable
    Entry block size: 2048
    Number of entries: 2500
    First serial #: 137966
    Last serial #: 140465
    First time stamp: Fri Nov 28 00:59:27 2004
    Last time stamp: Fri Nov 28 01:06:13 2004

次の例は、スレーブ KDC サーバー上での kproplog コマンドの実行結果です。


kdc2 # /usr/sbin/kproplog -h

Kerberos update log (/var/krb5/principal.ulog)
Update log dump:
    Log version #: 1
    Log state: Stable
    Entry block size: 2048
    Number of entries: 0
    First serial #: None
    Last serial #: 140465
    First time stamp: None
    Last time stamp: Fri Nov 28 01:06:13 2004

最終シリアル番号と最終時刻表示が同じであることに注意してください。これは、スレーブがマスター KDC サーバーと同期していることを示しています。

スレーブ KDC サーバーの出力で、スレーブ KDC サーバーの更新ログに更新エントリがないことに注意してください。エントリがないのは、スレーブ KDC サーバーはマスター KDC サーバーとは異なり、一連の更新を保持しないためです。また、最初のシリアル番号と最初の時刻表示は関連情報でないため、KDC スレーブサーバーはそれらの情報を取り込みません。

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

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

注 –

増分伝播を使用する場合は、この手順を使用しないでください。

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

  2. (省略可能) kdb5_util コマンドを使用して、データベースをバックアップします。


    # /usr/sbin/kdb5_util dump /var/krb5/slave_datatrans

  3. kprop コマンドを使用して、データベースをスレーブ KDC に伝播します。


    # /usr/lib/krb5/kprop -f /var/krb5/slave_datatrans slave-KDC
例 23–15 kprop_script を使用してスレーブ KDC に Kerberos データベースを手動で伝播する

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


# /usr/lib/krb5/kprop_script slave-KDC

並列伝播の設定

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

注 –

増分伝播を使用する場合は、この手順を使用しないでください。

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

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

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

図は、2 つの伝播スレーブを持ったマスター KDC を表示しています。各伝播スレーブは、それぞれのスレーブにマスター KDC データベースを伝播します。

並列伝播を設定するための構成手順

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

  1. マスター KDC 上で、cron ジョブ内の kprop_script エントリを変更して、次の伝播先のスレーブ KDC ( 伝播スレーブ) だけを引数に指定します。

  2. 伝播スレーブごとに、kprop_script エントリをその cron ジョブに追加し、伝播先のスレーブを引数に指定します。並列伝播を正しく行うには、伝播スレーブが新しい Kerberos データベースから伝播されたあとに、cron ジョブが実行されるように設定する必要があります。

    注 –

    伝播スレーブにかかる伝播時間は、ネットワークの帯域幅や Kerberos データベースのサイズなどの要因によって異なります。

  3. スレーブ KDC ごとに、伝播に必要なアクセス権を設定します。伝播元の KDC のホスト主体名を各スレーブ KDC の kpropd.acl ファイルに追加します。

例 23–16 並列伝播の設定

図 23–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 ファイルを削除する必要があります。

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

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

  2. stash ファイルを削除します。


    # rm stash-file

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

    注 –

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

LDAP ディレクトリサーバーでの KDC の管理

LDAP ディレクトリサーバーを使用した KDC 管理作業のほとんどは、DB2 サーバーを使用した場合と同じです。LDAP を使用した処理に特有の新しい作業がいくつかあります。

表 23–3 LDAP を使用するための KDC サーバーの構成 (作業マップ)

タスク 

説明 

参照先 

マスター KDC を構成します。 

手動のプロセスを使用し、さらに KDC 用に LDAP を使用して、レルムにマスター KDC サーバーとデータベースを構成および構築します。 

「LDAP データサーバーを使用するように KDC を構成する方法」

Kerberos 主体属性を Kerberos 以外のオブジェクトクラス型と結び付けます 

Kerberos レコードで格納された情報をほかの LDAP データベースと共有できるようになります。 

「Kerberos 主体属性を Kerberos 以外のオブジェクトクラス型に結び付ける方法」

レルムを破棄します。 

レルムに関連付けられたデータをすべて削除します。 

「LDAP ディレクトリサーバーでレルムを破棄する方法」

ProcedureKerberos 主体属性を Kerberos 以外のオブジェクトクラス型に結び付ける方法

この手順により、Kerberos 主体属性を Kerberos 以外のオブジェクトクラス型に関連付けることができます。この手順では、krbprincipalaux、krbTicketPolicyAux、および krbPrincipalName 属性が people オブジェクトクラスに関連付けられます。

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

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

  2. people オブジェクトクラスの各エントリを用意します。

    エントリごとに次の手順を繰り返します。


    cat << EOF | ldapmodify -h dsserver.example.com -D "cn=directory manager"
dn: uid=willf,ou=people,dc=example,dc=com
changetype: modify
objectClass: krbprincipalaux
objectClass: krbTicketPolicyAux
krbPrincipalName: willf@EXAMPLE.COM
EOF

  3. サブツリー属性をレルムコンテナに追加します。

    この手順により、デフォルトの EXAMPLE.COM コンテナだけでなく、ou=people,dc=example,dc=com コンテナでも主体エントリを検索できるようになります。


    # kdb5_ldap_util -D "cn=directory manager" modify \
            -subtrees 'ou=people,dc=example,dc=com' -r EXAMPLE.COM

  4. (省略可能) KDC レコードが DB2 に格納されている場合は、DB2 エントリを移行します。

    1. DB2 エントリをダンプします。


      # kdb5_util dump > dumpfile

    2. データベースを LDAP サーバーにロードします。


      # kdb5_util load -update dumpfile

  5. (省略可能) 主体属性を KDC に追加します。


    # kadmin.local -q 'addprinc willf'

ProcedureLDAP ディレクトリサーバーでレルムを破棄する方法

この手順は、別の LDAP ディレクトリサーバーがレルムを処理するように構成されている場合に使用できます。

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

  2. レルムを破棄します。


    # kdb5_ldap_util -D "cn=directory manager" destroy

Kerberos サーバー上のセキュリティーの強化

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

表 23–4 Kerberos サーバーのセキュリティーの強化 (作業マップ)

タスク 

説明 

説明 

Kerberos 認証を使用してアクセスを有効にします。 

ネットワークアクセスを制限し、サーバーで Kerberos 認証のみが許可されるようにします。 

「Kerberos アプリケーションのみを有効にする方法」

KDC サーバーへのアクセスを制限します。 

KDC サーバーとそのデータのセキュリティーを強化します。 

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

辞書ファイルを使用してパスワードセキュリティーを強化します。 

新しいパスワードを辞書と照合してパスワードのセキュリティーを強化します。 

「辞書ファイルを使用してパスワードセキュリティーを強化する方法」

ProcedureKerberos アプリケーションのみを有効にする方法

この手順を実行すると、telnet、ftp、rcp、rsh、および rlogin を実行しているサーバーへのネットワークアクセスが、Kerberos 認証されたトランザクションだけを使用するネットワークアクセスに制限されます。

  1. telnet サービスの exec プロパティーを変更します。

    telnet の exec プロパティーに -a user オプションを追加すると、有効な認証情報を提供できるユーザーにアクセスが制限されます。


    # inetadm -m svc:/network/telnet:default exec="/usr/sbin/in.telnetd -a user"

  2. (省略可能) まだ構成されていない場合は、telnet サービスのexec のプロパティーを変更します。

    ftp の exec プロパティーに -a オプションを追加すると、Kerberos 認証された接続のみが許可されます。


    # inetadm -m svc:/network/ftp:default exec="/usr/sbin/in.ftpd -a"

  3. 他のサービスを無効にします。

    in.rshd と in.rlogind デーモンを無効にする必要があります。


    # svcadm disable network/shell
# svcadm disable network/login:rlogin

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

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

  1. 必要に応じて、遠隔サービスを無効にします。

    KDC サーバーをセキュリティー保護するために、不要なネットワークサービスをすべて無効にします。構成によっては、いくつかのサービスは既に無効になっています。svcs コマンドを使用して、サービス状態を確認します。ほとんどの環境では、KDC がマスターの場合に動作している必要のあるサービスは krb5kdc と kadmin のみです。ループバック TLI を使用するサービス (ticlts、ticotsord、および ticots) は、有効にしておくことができます。 


    # svcadm disable network/comsat
# svcadm disable network/dtspc/tcp
# svcadm disable network/finger
# svcadm disable network/login:rlogin
# svcadm disable network/rexec
# svcadm disable network/shell
# svcadm disable network/talk
# svcadm disable network/tname
# svcadm disable network/uucp
# svcadm disable network/rpc_100068_2-5/rpc_udp

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

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

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

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

Procedure辞書ファイルを使用してパスワードセキュリティーを強化する方法

Kerberos サービスで辞書ファイルを使用することにより、新しい資格の作成時に辞書内の単語がパスワードとして使用されるのを防ぐことができます。辞書の用語がパスワードとして使用されないようにすると、パスワードの推測が困難になります。デフォルトでは /var/krb5/kadm5.dict ファイルが使用されますが、これは空です。

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

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

    行を追加して、サービスで辞書ファイルが使用されるようにする必要があります。この例では、spell ユーティリティーに含まれる辞書を使用します。構成ファイルの詳細は、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
                sunw_dbprop_enable = true
                sunw_dbprop_master_ulogsize = 1000
                dict_file = /usr/share/lib/dict/words
                }

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


    kdc1 # svcadm restart -r network/security/krb5kdc
kdc1 # svcadm restart -r network/security/kadmin

第 24 章 Kerberos エラーメッセージと障害追跡

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

Kerberos のエラーメッセージ

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

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 を終了して再起動してください。それでも問題が解決しない場合は、バグを報告してください。

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

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


All authentication systems disabled; connection refused (すべての認証システムが無効です。接続が拒否されました。)

原因:

このバージョンの rlogind は認証メカニズムをサポートしていません。

対処方法:

rlogind の起動時に -k オプションが指定されていることを確認してください。


Another authentication mechanism must be used to access this host (このホストにアクセスするには、別の認証メカニズムを使用する必要があります。)

原因:

認証を実行できませんでした。

対処方法:

クライアントが Kerberos V5 メカニズムを使って認証を行なっていることを確認してください。


Authentication negotiation has failed, which is required for encryption. Good bye. (暗号化に必要となる認証のネゴシエーションが失敗しました。処理を中断します。) 

原因:

認証で、サーバーとのネゴシエーションが失敗しました。

対処方法:

telnet と toggle authdebug コマンドを実行して認証デバッグ機能を開始し、そのデバッグメッセージからさらなる手掛かりを得てください。また、所有している資格が有効であることも確認してください。


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

原因:

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

対処方法:

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


Bad lifetime value (有効期限値が無効です。)

原因:

指定した有効期限値が無効または間違った形式です。

対処方法:

指定した値が、kinit(1) のマニュアルページの時刻形式のセクションに適合していることを確認してください。


Bad start time value (開始時刻の値が無効です。)

原因:

指定した開始時刻が無効または間違った形式です。

対処方法:

指定した値が、kinit(1) のマニュアルページの時刻形式のセクションに適合していることを確認してください。


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

原因:

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

対処方法:

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


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

原因:

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

対処方法:

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


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

原因:

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

対処方法:

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


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

原因:

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

対処方法:

KDC に stash ファイルが存在することを確認してください。存在しない場合は、kdb5_util コマンドを使用して stash ファイルを作成し、再度 krb5kdc コマンドを実行します。


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

原因:

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

対処方法:

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


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

原因:

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

対処方法:

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


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

原因:

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

対処方法:

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


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

原因:

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

対処方法:

krb5.conf ファイルが、正しい場所に配置されていることを確認してください。また、このファイルに正しいアクセス権が与えられていることを確認してください。このファイルに対する書き込み権は root、読み込み権はすべてのユーザーに与える必要があります。


Client did not supply required checksum--connection rejected (必要なチェックサム情報がクライアントから提供されませんでした。接続が拒否されました。)

原因:

チェックサム付き認証で、クライアントとのネゴシエーションに失敗しました。クライアントが、初期接続をサポートしない旧 Kerberos V5 プロトコルを使用している可能性があります。

対処方法:

クライアントが、初期接続をサポートする Kerberos V5 プロトコルを使用していることを確認してください。


Client/server realm mismatch in initial ticket request (初期チケット要求でクライアント/サーバーレルムが一致していません。)

原因:

初期チケット要求で、クライアントとサーバーのレルムが一致していません。

対処方法:

通信しているサーバーがクライアントと同じレルムに配置されていること、またはレルム構成が正しいことを確認してください。


Client or server has a null key (クライアントまたはサーバーの鍵が空です。)

原因:

クライアントまたはサーバーの鍵が空です。

対処方法:

kadmin の cpw コマンドを使用して、主体の鍵の値を入力してください。


Communication failure with server while initializing kadmin interface (kadmin インタフェースを初期化中に、サーバーとの通信の失敗です。)

原因:

管理サーバーとして指定したホスト (マスター KDC) 上で、kadmind デーモンが動作していません。

対処方法:

マスター KDC に正しいホスト名が指定されていることを確認してください。ホスト名が正しい場合は、指定したマスター KDC 上で kadmind が動作していることを確認してください。


Credentials cache file permissions incorrect (資格キャッシュファイルのアクセス権が正しくありません。)

原因:

資格キャッシュ (/tmp/krb5cc_uid) に対する読み取り権または書き込み権が適切ではありません。

対処方法:

資格キャッシュに対する読み取り権および書き込み権があることを確認してください。


Credentials cache I/O operation failed XXX (資格キャッシュ入出力操作が失敗しました。XXX)

原因:

システムの資格キャッシュ (/tmp/krb5cc_uid) に書き込むときに、Kerberos で問題が発生しました。

対処方法:

資格キャッシュが削除されていないことを確認し、df コマンドを使用してデバイスの空き領域を確認してください。


Decrypt integrity check failed (復号化で整合性チェックが失敗しました。)

原因:

チケットが無効である可能性があります。

対処方法:

次の条件をいずれも確認してください。

  • 資格が有効であることを確認してください。kdestroy を使用してチケットを破棄し、kinit を使用して新しいチケットを作成します。

  • 対象ホストのキータブファイルに対して、正しいバージョンのサービス鍵が割り当てられていることを確認してください。kadmin を使用して、Kerberos データベースのサービス主体 (host/FQDN-hostname など) の鍵バージョン番号を表示します。対象ホスト上で klist -k を使用して、鍵バージョン番号がその番号であることを確認します。


Encryption could not be enabled. Good bye. (暗号化を有効化できませんでした。処理を中止します。)

原因:

暗号化で、サーバーとのネゴシエーションに失敗しました。

対処方法:

telnet と toggle encdebug コマンドを実行して認証デバッグ機能を開始し、そのデバッグメッセージからさらなる手掛かりを得てください。


failed to obtain credentials cache (資格キャッシュを取得できませんでした。)

原因:

kadmin の初期化中に、kadmin が admin 主体の資格を取得しようとしましたが、失敗しました。

対処方法:

kadmin を実行したときに、正しい主体とパスワードを使用したことを確認してください。


Field is too long for this implementation (この実装ではフィールドが長すぎます。)

原因:

Kerberos アプリケーションから送信されたメッセージのサイズが長すぎます。このエラーは、トランスポートプロトコルが UDP の場合に発生します。UDP では、デフォルトの最大メッセージ長は 65535 バイトです。また、Kerberos サービスから送信されるプロトコルメッセージの各フィールドにも制限があります。

対処方法:

KDC サーバーの /etc/krb5/kdc.conf ファイルでトランスポートを UDP に制限していないことを確認してください。


GSS-API (or Kerberos) error (GSS-API (または Kerberos) エラー)

原因:

このメッセージは、汎用 GSS-API または Kerberos のエラーメッセージで、いくつかの問題の組み合わせによって発生した可能性があります。

対処方法:

/var/krb5/kdc.log ファイルを確認して、このエラーが発生したときに詳細なエラーメッセージが記録されているかどうかを確認してください。


Hostname cannot be canonicalized (ホスト名を展開できません。)

原因:

Kerberos がホスト名を完全指定できません。

対処方法:

このホスト名が DNS に定義されていることと、ホスト名とアドレス間の双方向のマッピングについて整合性を確認してください。


Illegal cross-realm ticket (レルム間のチケットが無効です。)

原因:

送信されたチケットのレルム間関係が正しくありません。レルム間に正しい信頼関係が設定されていない可能性があります。

対処方法:

使用しているレルム間の信頼関係が正しいことを確認してください。


Improper format of Kerberos configuration file (Kerberos 構成ファイルのフォーマットが不適切です。)

原因:

Kerberos 構成ファイルに無効なエントリがあります。

対処方法:

krb5.conf ファイル内のすべての関係式に、= 記号と値が使用されていることを確認してください。また、各下位セクションが角カッコで囲まれていることも確認してください。


Inappropriate type of checksum in message (メッセージのチェックサムのタイプが不適切です。)

原因:

このメッセージに無効なチェックサムタイプが含まれています。

対処方法:

krb5.conf および kdc.conf ファイルに指定されているチェックサムタイプが有効であることを確認してください。


Incorrect net address (ネットアドレスが間違っています。)

原因:

ネットワークアドレスが一致しません。転送されたチケット内のネットワークアドレスが、チケットが処理されたときのネットワークアドレスと一致しません。このメッセージは、チケットの転送時に発生します。

対処方法:

ネットワークアドレスが正しいことを確認してください。kdestroy を使用してチケットを破棄し、kinit を使用して新しいチケットを作成します。


Invalid credential was supplied (無効な資格が指定されました。)


Service key not available (サービス鍵が使用できません。)

原因:

資格キャッシュ内のサービスチケットが間違っている可能性があります。

対処方法:

現在の資格キャッシュを破棄して、このサービスを使用する前に kinit を再実行してください。


Invalid flag for file lock mode (ファイルロックモードのフラグが無効です。)

原因:

Kerberos の内部エラーが発生しました。

対処方法:

バグを報告してください。


Invalid message type specified for encoding (符号化に対し無効なメッセージタイプが指定されました。)

原因:

Kerberos アプリケーションから送信されたメッセージ形式を、Kerberos が認識できません。

対処方法:

使用するサイトまたはベンダーで開発した Kerberos アプリケーションを使用している場合は、Kerberos が正しく使用されていることを確認してください。


Invalid number of character classes (文字クラス数が正しくありません。)

原因:

主体に指定したパスワードに、主体のポリシーによって適用された数のパスワードクラスが含まれていません。

対処方法:

ポリシーに指定されている最小パスワードクラス数を使用して、パスワードを指定してください。


KADM err: Memory allocation failure (KADM エラー: メモリー割り当ての失敗です。)

原因:

kadmin の実行に必要なメモリーが不足しています。

対処方法:

メモリーを解放してから、kadmin を再実行してください。


kadmin: Bad encryption type while changing host/<FQDN>'s key (host/<FQDN> のキーの変更中に不正な暗号化タイプが見つかりました。)

原因:

Solaris 10 8/07 リリースの基本リリースには、デフォルトの暗号化タイプがいくつか追加されました。以前のバージョンの Solaris ソフトウェアを実行している KDC がサポートしない暗号化タイプをクライアントが要求する場合があります。

対処方法:

この問題を解決するための対処方法がいくつか用意されています。もっとも簡単に実行できる方法を次に示します。

  1. SUNWcry および SUNWcryr パッケージを KDC サーバーに追加します。これにより、KDC がサポートする暗号化タイプの数が増えます。

  2. aes256 暗号化タイプを含まないように、クライアント上の krb5.conf の permitted_enctypes を設定します。この手順は、新しいクライアントが追加されるごとに実行する必要があります。


KDC can't fulfill requested option (KDC は要求したオプションを処理できません。)

原因:

要求されたオプションを KDC が許可しませんでした。遅延または転送可能オプションが要求されましたが、KDC が許可しませんでした。または、TGT の更新が要求されましたが、更新可能な TGT が存在しない可能性があります。

対処方法:

KDC が許可しないオプションまたは使用できない種類のチケットを要求していないかどうかを確認してください。


KDC policy rejects request (KDC ポリシーは要求を拒否します。)

原因:

KDC ポリシーが要求を許可しませんでした。たとえば、KDC に対する要求に IP アドレスが含まれていないことがあります。あるいは、要求は転送されたが、KDC が許可しなかった可能性があります。

対処方法:

正しいオプションを指定して kinit を実行していることを確認してください。必要に応じて、主体に関連付けられたポリシーを変更するか、要求が許可されるように主体の属性を変更します。ポリシーまたは主体を変更するには、kadmin を使用します。


KDC reply did not match expectations (KDC 応答は予期したものと一致しませんでした。)

原因:

KDC の応答に予期した主体名が含まれていないか、応答内のその他の値が正しくありません。

対処方法:

通信先の KDC が RFC 1510 に準拠していること、送信している要求が Kerberos V5 要求であること、または KDC が有効であることを確認してください。


kdestroy:Could not obtain principal name from cache (キャッシュから主体名を取得できません。)

原因:

資格キャッシュが欠落しているか、または破壊されています。

対処方法:

指定したキャッシュ位置が正しいことを確認してください。必要に応じて、kinit を使用して削除し、新しい TGT を取得してください。


kdestroy:Could not obtain principal name from cache (キャッシュの破棄中に資格キャッシュが見つかりませんでした。)

原因:

資格キャッシュ (/tmp/krb5c_uid) が欠落しているか、または破壊されています。

対処方法:

指定したキャッシュ位置が正しいことを確認してください。必要に応じて、kinit を使用して削除し、新しい TGT を取得してください。


kdestroy:Could not obtain principal name from cache (TGT 期限切れの警告が削除されません。)

原因:

資格キャッシュが欠落しているか、または破壊されています。

対処方法:

指定したキャッシュ位置が正しいことを確認してください。必要に応じて、kinit を使用して削除し、新しい TGT を取得してください。


Kerberos authentication failed (Kerberos 認証に失敗しました。)

原因:

Kerberos パスワードが正しくないか、または UNIX パスワードと一致していません。

対処方法:

パスワードが一致していない場合は、Kerberos 認証に成功する別のパスワードを指定する必要があります。ユーザーが元のパスワードを忘れた可能性があります。


Kerberos V5 refuses authentication (Kerberos V5 によって認証が拒否されました。)

原因:

認証で、サーバーとのネゴシエーションが失敗しました。

対処方法:

telnet と toggle authdebug コマンドを実行して認証デバッグ機能を開始し、そのデバッグメッセージからさらなる手掛かりを得てください。また、所有している資格が有効であることも確認してください。


Key table entry not found (鍵テーブルエントリが見つかりません。)

原因:

ネットワークアプリケーションサーバーのキータブファイルに、サービス主体のエントリがありません。

対処方法:

サーバーのキータブファイルに適切なサービス主体を追加して、Kerberos サービスを提供できるようにしてください。


Key version number for principal in key table is incorrect (鍵テーブルの主体の鍵バージョン番号が正しくありません。)

原因:

キータブファイルと Kerberos データベース内の主体の鍵バージョンが異なります。サービスの鍵が変更されたか、旧サービスチケットを使用している可能性があります。

対処方法:

kadmin などによってサービスの鍵が変更されている場合は、新しい鍵を抽出して、サービスが動作しているホストのキータブファイルに格納する必要があります。

または、旧サービスチケットを使用しているため、鍵が古い可能性があります。kdestroy コマンドを実行し、次に kinit コマンドを再度実行してください。


kinit: gethostname failed (gethostname が失敗しました。)

原因:

ローカルネットワーク構成でのエラーは、kinit が失敗する原因になります。

対処方法:

ホストが正しく構成されていることを確認してください。


login: load_modules: can not open module /usr/lib/security/pam_krb5.so.1 (load_modules: /usr/lib/security/pam_krb5.so.1 モジュールを開けません。)

原因:

Kerberos PAM モジュールが存在しないか、有効な実行可能バイナリではありません。

対処方法:

Kerberos PAM モジュールが /usr/lib/security ディレクトリに存在し、有効な実行可能バイナリであることを確認してください。また、/etc/pam.conf ファイルに pam_krb5.so.1 への正しいパスが指定されていることも確認してください。


Looping detected inside krb5_get_in_tkt (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 サービスを再度初期化してください。

Kerberos 共通エラーメッセージ (N - Z)

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


No credentials cache file found (資格キャッシュファイルが見つかりません。)

原因:

Kerberos が資格キャッシュ (/tmp/krb5cc_uid) を見つけることができません。

対処方法:

資格ファイルが存在し、読み込み可能であることを確認してください。存在しない場合は、kinit を再度実行します。


No credentials were supplied, or the credentials were unavailable or inaccessible (資格が提供されていません。あるいは、資格を使用またはアクセスできません。)


No credentials cache found (資格キャッシュが見つかりません。)

原因:

ユーザーの資格キャッシュが間違っているか、または存在しません。

対処方法:

ユーザーは、サービスを開始する前に、kinit を実行する必要があります。


No credentials were supplied, or the credentials were unavailable or inaccessible (資格が提供されていません。あるいは、資格を使用またはアクセスできません。)


No principal in keytab matches desired name (キータブ内の主体が目的の名前と一致しません。)

原因:

サーバーの認証中にエラーが発生しました。

対処方法:

ホスト主体またはサービス主体が、サーバーのキータブファイル内にあることを確認してください。


Operation requires “privilege” privilege (操作には privilege 特権が必要です。)

原因:

使用された admin 主体に対して、kadm5.acl ファイルに設定されている適切な特権が割り当てられていません。

対処方法:

適切な特権を持つ主体を使用してください。または、kadm5.acl ファイルを変更して、使用した主体に適切な特権を割り当てます。通常は、名前の一部に /admin が含まれる主体には、適切な特権が割り当てられています。


PAM-KRB5 (auth): krb5_verify_init_creds failed: Key table entry not found (PAM-KRB5 (auth): krb5_verify_init_creds に失敗しました: Key table entry not found (鍵テーブルエントリが見つかりません。)

原因:

遠隔アプリケーションは、ローカル /etc/krb5/krb5.keytab ファイル内にあるホストのサービス主体を読み込もうとしましたが、サービス主体が存在しませんでした。

対処方法:

ホストのキータブファイルにホストのサービス主体を追加してください。


Password is in the password dictionary (パスワードはパスワード辞書にあります。)

原因:

指定したパスワードが使用中のパスワード辞書にすでに存在します。選択したパスワードが適切ではありません。

対処方法:

パスワードクラスを組み合わせたパスワードを選択してください。


Permission denied in replay cache code (再実行キャッシュコードでアクセス権がありません。)

原因:

システムの再実行キャッシュを開けませんでした。サーバーは、現在のユーザー ID と異なるユーザー ID で最初に実行された可能性があります。

対処方法:

再実行キャッシュに適切なアクセス権が割り当てられていることを確認してください。再実行キャッシュは、Kerberos サーバーアプリケーションが動作するホストに格納されます。再実行キャッシュファイルは、root ではないユーザーの場合は /var/krb5/rcache/rc_service_name_uid という名前です。root ユーザーの再実行キャッシュは、 /var/krb5/rcache/root/rc_service_name です。


Protocol version mismatch (プロトコルバージョンが一致していません。)

原因:

Kerberos V4 要求が KDC に送信された可能性があります。Kerberos サービスでは、Kerberos V5 プロトコルだけがサポートされます。

対処方法:

アプリケーションが Kerberos V5 プロトコルを使用していることを確認してください。


Request is a replay (要求は再送です。)

原因:

この要求は、すでにこのサーバーに送信され、処理が完了しています。チケットが盗まれた可能性があり、ほかのユーザーがチケットを再使用しようとしています。

対処方法:

しばらくしてから要求を再発行してください。


Requested principal and ticket don't match (要求した主体とチケットは一致しません。)

原因:

接続するサービス主体と使用するサービスチケットが一致しません。

対処方法:

DNS が適切に機能することを確認してください。別のベンダーのソフトウェアを使用する場合は、そのソフトウェアが主体名を正しく使用していることを確認します。


Requested protocol version not supported (要求したプロトコルバージョンはサポートされていません。)

原因:

Kerberos V4 要求が KDC に送信された可能性があります。Kerberos サービスでは、Kerberos V5 プロトコルだけがサポートされます。

対処方法:

アプリケーションが Kerberos V5 プロトコルを使用していることを確認してください。


Server refused to negotiate authentication, which is required for encryption. Good bye.  

原因:

遠隔アプリケーションは、クライアントからの Kerberos 認証を受け取ることができないか、またはそのように構成されていません。

対処方法:

認証をネゴシエーションできるアプリケーションを提供するか、認証を有効にする適切なフラグを使用してアプリケーションを設定します。


Server refused to negotiate encryption. Good bye.  

原因:

暗号化で、サーバーとのネゴシエーションに失敗しました。

対処方法:

telnet と toggle encdebug コマンドを実行して認証デバッグ機能を開始し、そのデバッグメッセージからさらなる手掛かりを得てください。


Server rejected authentication (during sendauth exchange) (サーバーが認証を拒否しました (sendauth 交換で)。)

原因:

通信しようとしているサーバーが認証を拒否しました。ほとんどの場合、このエラーは Kerberos データベースを伝播するときに発生します。kpropd.acl ファイル、DNS、またはキータブファイルに問題が発生している可能性があります。

対処方法:

kprop 以外のアプリケーションを実行しているときにこのエラーが発生した場合は、サーバーのキータブファルが正しいかどうかを調査してください。


The ticket isn't for us (チケットはわれわれのものではありません。)


Ticket/authenticator don't match (チケット/ オーセンティケータが一致しません。)

原因:

チケットとオーセンティケータが一致しません。要求内の主体名がサービス主体の名前と一致しなかった可能性があります。その原因は、サービスが非 FQDN 名を期待しているときにチケットが主体の FQDN 名とともに送信された、サービスが FQDN 名を期待しているときに非 FDQN 名が送信された、のいずれかです。

対処方法:

kprop 以外のアプリケーションを実行しているときにこのエラーが発生した場合は、サーバーのキータブファルが正しいかどうかを調査してください。


Ticket expired (チケットの有効期限が切れました。)

原因:

チケットが期限切れになっています。

対処方法:

kdestroy を使用してチケットを破棄し、kinit を使用して新しいチケットを作成します。


Ticket is ineligible for postdating (チケットには遅延処理の資格がありません。)

原因:

この主体は、チケットの遅延を許可していません。

対処方法:

kadmin を使用して主体を変更し、遅延を許可してください。


Ticket not yet valid (チケットはまだ有効ではありません。)

原因:

遅延チケットはまだ有効ではありません。

対処方法:

正しい日付で新しいチケットを作成するか、現在のチケットが有効になるまで待ちます。


Truncated input file detected (不完全な入力ファイルを検出しました。)

原因:

操作に使用されたデータベースダンプファイルが完全ではありません。

対処方法:

ダンプファイルを作成し直すか、別のデータベースダンプファイルを使用します。


Unable to securely authenticate user ... exit (ユーザーを安全に認証できません。処理を終了します。)

原因:

認証で、サーバーとのネゴシエーションが失敗しました。

対処方法:

telnet と toggle authdebug コマンドを実行して認証デバッグ機能を開始し、そのデバッグメッセージからさらなる手掛かりを得てください。また、所有している資格が有効であることも確認してください。


Wrong principal in request (要求した主体は正しくありません。)

原因:

チケットの主体名が無効です。DNS または FQDN の問題が発生している可能性があります。

対処方法:

サービスの主体とチケットの主体が一致していることを確認してください。

Kerberos の障害追跡

この節では、Kerberos ソフトウェアの障害追跡について説明します。

krb5.conf ファイルの書式の問題

krb5.conf ファイルの書式が正しくない場合、次のエラーメッセージが端末またはログファイルに表示されることがあります。 


Improper format of Kerberos /etc/krb5/krb5.conf configuration file while initializing krb5 library

krb5.conf ファイルの書式に問題があると、関連するサービスへの接続が容易になる危険があります。この問題を解決しないと、Kerberos 機能を使用できません。

Kerberos データベースの伝播の問題

Kerberos データベースの伝播が失敗した場合、スレーブ KDC とマスター KDC との間で、およびマスター KDC からスレーブ KDC サーバーへ、/usr/bin/rlogin -x を試してみてください。

KDC がアクセスを制限するように設定されていた場合、 rlogin が無効となり、このコマンドを使って問題を解決することができません。KDC で rlogin を有効にするには、eklogin サービスを有効にする必要があります。


# svcadm enable svc:/network/login:eklogin

問題の障害追跡を終了したあと、eklogin サービスを無効にする必要があります。

rlogin が正常に動作しなかった場合、問題の原因は KDC のキータブファイルにある可能性が高くなります。rlogin が正常に動作した場合、問題の原因はキータブファイルやネームサービスにはありません。というのも、rlogin と伝播ソフトウェアは同じ host/host-name 主体を使用しているからです。この場合、kpropd.acl ファイルが正しいことを確認してください。

Kerberos NFS ファイルシステムのマウントの問題

この例の設定では、インタフェースごとに 1 つの参照が割り当てられます。また、サーバーのキータブファイル内で、3 つのサービス主体の代わりに、1 つのサービス主体を使用できます。

root の認証の問題

使用するシステムのスーパーユーザーになるときの認証に失敗し、ホストのキータブファイルに root 主体がすでに追加されている場合は、2 つの問題を確認する必要があります。まず、キータブファイル内の root 主体が、そのインスタンスとして完全指定形式名であることを確認します。完全指定形式名の場合は、/etc/resolv.conf ファイルを確認して、システムが DNS クライアントとして正しく設定されていることを確認してください。

GSS 資格の UNIX 資格へのマッピングの監視

資格マッピングを監視するには、最初に、/etc/gss/gsscred.conf ファイルの次の行をコメント解除します。


SYSLOG_UID_MAPPING=yes

次に、gssd サービスに/etc/gss/gsscred.conf ファイルから情報を取得するように指示します。


# pkill -HUP gssd

これで、gssd が資格マッピングを要求するときにそれを監視できるようになります。syslog.conf ファイルが debug 重要度を扱う auth システム機能用に構成されている場合、syslogdを使用してマッピングを記録できます。

第 25 章 Kerberos 主体とポリシーの管理 (手順)

この章では、主体とそれに関連するポリシーを管理する手順について説明します。また、ホストのキータブファイルの管理方法についても説明します。

この章は、主体とポリシーを管理する必要のあるユーザーを対象にしています。主体とポリシーを計画するときの考慮事項など、主体とポリシーについて理解している必要があります。第 21 章Kerberos サービスについてと第 22 章Kerberos サービスの計画を参照してください。

この章で説明する情報は次のとおりです。

Kerberos 主体とポリシーの管理方法

マスター KDC の Kerberos データベースには、使用するレルムの Kerberos 主体、そのパスワード、ポリシーなどの管理情報がすべて含まれています。主体を作成または削除したり、主体の属性を変更したりするには、kadmin または gkadmin コマンドのいずれかを使用します。

kadmin コマンドには、対話型のコマンド行インタフェースが用意されています。このインタフェースを使用して、Kerberos 主体、ポリシー、およびキータブファイルを管理することができます。kadmin コマンドには、次の 2 つの種類があります。

Kerberos を使用してユーザーを認証する点を除いて、2 つの kadmin の機能は同じです。kadmin に必要なデータベースを設定するときは、kadmin.local を使用します。

Solaris リリースには、SEAM 管理ツール (gkadmin) も用意されています。このツールは対話型のグラフィカルユーザーインタフェース (GUI) で、基本的に kadmin コマンドと同じ機能を持ちます。詳細は、「SEAM 管理ツール」を参照してください。

SEAM 管理ツール

SEAM 管理ツール (SEAM ツール) は、対話型グラフィカルユーザーインタフェース (GUI) で、Kerberos 主体とポリシーを管理することができます。このツールは、kadmin コマンドと同じ機能を持ちます。ただし、キータブファイルの管理はサポートしません。キータブファイルを管理するには、kadmin コマンドを使用する必要があります (「キータブファイルの管理」を参照)。

kadmin コマンドと同様に、SEAM Toolは、Kerberos 認証と暗号化された RPC を使用して、ネットワーク上の任意の場所から安全に操作することができます。SEAM ツールでは、次の操作を行うことができます。

SEAM ツールでは、コンテキストヘルプと一般的なオンラインヘルプも利用できます。

SEAM ツールを使用して実行できる操作について、次の作業マップで説明します。

また、SEAM ツールで指定または表示できる主体属性とポリシー属性については、「SEAM ツールパネルの説明」を参照してください。

SEAM ツールに対応するコマンド行

この節では、SEAM ツールと同じ機能を提供する kadmin コマンドを示します。これらのコマンドは、X ウィンドウシステムで実行しなくても使用できます。この章のほとんどの手順では、SEAM ツールを使用します。ただし、多くの手順では、対応するコマンド行の使用例も挙げています。

表 25–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」メニューから、次の要素をプリンタまたはファイルに送信できます。

「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」メニューを使用します。サーバーから一覧が読み込まれ、キャッシュを更新することができます。

ProcedureSEAM ツールを起動する方法

  1. gkadmin コマンドを使用して SEAM ツールを起動します。


    $ /usr/sbin/gkadmin

    「SEAM Administration Login」ウィンドウが表示されます。

    「SEAM Administration Login」というタイトルのダイアログボックスに、「Principal Name」、「Password」、「Realm」、「Master KDC」の 4 フィールドが表示されています。「了解 (OK)」および「Start Over」ボタンが表示されています。

  2. デフォルト値を使用しない場合は、新しいデフォルト値を指定します。

    ウィンドウには、デフォルト値が自動的に表示されています。デフォルトの主体名は、USER 環境変数の現在の ID に /admin が付加されて作成されます (username/admin)。デフォルトの「Realm」フィールドおよび「Master KDC」フィールドは、/etc/krb5/krb5.conf ファイルから選択されます。デフォルト値を再度取得する場合は、「Start Over」をクリックします。

    注 –

    各「Principal Name」が実行できる管理操作は、Kerberos ACL ファイルの /etc/krb5/kadm5.acl で規定されます。権限の制限については、「Kerberos 管理権限を制限して SEAM ツールを使用する」を参照してください。

  3. 指定した主体名のパスワードを入力します。

  4. 「了解 (OK)」をクリックします。

    ウィンドウが表示され、すべての主体が示されます。

Kerberos 主体の管理

この節では、SEAM ツールを使用して主体を管理する手順について説明します。また、対応するコマンド行がある場合は、その例も示します。

Kerberos 主体の管理 (作業マップ)

作業 

説明 

参照先 

主体の一覧を表示します。 

「Principals」タブをクリックして、主体の一覧を表示します。 

「Kerberos 主体の一覧を表示する方法」

主体の属性を表示します。 

「Principal List」の「Principal」を選択し、「Modify」ボタンをクリックして、主体の属性を表示します。 

「Kerberos 主体の属性を表示する方法」

新しい主体を作成します。 

「Principal List」パネルの「Create New」ボタンをクリックして、新しい主体を作成します。 

「新しい Kerberos 主体を作成する方法」

主体を複製します。 

「Principal List」から複製する主体を選択し、「Duplicate」ボタンをクリックして、主体を複製します。 

「Kerberos 主体を複製する方法」

主体を変更します。 

「Principal List」から変更する主体を選択し、「Modify」ボタンをクリックして、主体を変更します。 

主体名は変更できません。主体名を変更するときは、主体を複製し、新しい名前を指定して保存してから、古い主体を削除する必要があります。 

「Kerberos 主体を変更する方法」

主体を削除します。 

「Principal List」から削除する主体を選択し、「Delete」ボタンをクリックして、主体を削除します。 

「Kerberos 主体を削除する方法」

新しい主体を作成するときのデフォルトを設定します。 

「Edit」メニューから「Properties」を選択して、新しい主体を作成するときのデフォルトを設定します。 

「新しい Kerberos 主体を作成するときのデフォルトを設定する方法」

Kerberos 管理権限 (kadm5.acl ファイル) を変更します。

コマンド行のみ。Kerberos 管理権限により、主体が Kerberos データベースに対して実行できる操作 (追加、変更など) が決定されます。

各主体の Kerberos 管理権限を変更するときは、/etc/krb5/kadm5.acl ファイルを編集する必要があります。

「Kerberos 管理権限を変更する方法」

新しい Kerberos 主体の自動作成

SEAM Toolは簡単に使用できますが、新しい主体を自動作成することができません。10 個または 100 個などの新しい主体を短時間で作成する場合は、自動作成を利用すると便利です。Bourne シェルスクリプトで kadmin.local コマンドを使用すると、主体を自動作成できます。

次のシェルスクリプト行は、新しい主体を自動作成する方法の例を示します。


awk '{ print "ank +needchange -pw", $2, $1 }' < /tmp/princnames | 
        time /usr/sbin/kadmin.local> /dev/null

この例は、見やすいように 2 行に分割しています。このスクリプトは、princnames というファイルを読み込んで、そこに含まれている主体名とそのパスワードを Kerberos データベースに追加します。princnames ファイルをあらかじめ作成する必要があります。このファイルの各行には、主体とそのパスワードを 1 つ以上の空白で区切って指定します。主体に +needchange オプションを指定すると、ユーザーがその主体を使用して初めてログインしたときに、新しいパスワードを要求するプロンプトが表示されます。この方法を使用すると、princnames ファイル内のパスワードのセキュリティーが向上します。

より複雑なスクリプトも作成できます。たとえば、ネームサービスの情報を使用して、主体名に対応するユーザー名の一覧を取得できます。必要な作業とその方法は、使用環境要件とスクリプト使用技術によって決まります。

ProcedureKerberos 主体の一覧を表示する方法

対応するコマンド行の例は、この手順のあとに示します。

  1. 必要に応じて、SEAM ツールを起動します。

    詳細は、「SEAM ツールを起動する方法」を参照してください。


    $ /usr/sbin/gkadmin

  2. 「Principals」タブをクリックします。

    主体の一覧が表示されます。

    「Seam Administration Tool」というタイトルのダイアログボックスに、主体の一覧と一覧のフィルタが表示されています。「Modify」、「Create New」、「Delete」、「Duplicate」ボタンが表示されています。

  3. 特定の主体を表示するか、主体の部分リストを表示します。

    「Filter」フィールドにフィルタ文字列を入力して、Return キーを押します。フィルタが正常終了すると、フィルタに一致する主体の一覧が表示されます。

    フィルタ文字列は、1 文字以上の文字列である必要があります。フィルタメカニズムでは大文字と小文字が区別されるため、大文字と小文字を正しく指定する必要があります。たとえば、フィルタ文字列に ge と入力すると、主体名に文字列 ge を含む主体 (george、edge など) だけが表示されます。

    すべての主体を表示するには、「Clear Filter」をクリックします。

例 25–1 Kerberos 主体の一覧の表示 (コマンド行)

次の例では、kadmin の list_principals コマンドを使用して、kadmin* と一致するすべての主体を表示します。list_principals コマンドでは、ワイルドカードを使用できます。


kadmin: list_principals kadmin*
kadmin/changepw@EXAMPLE.COM
kadmin/kdc1.example.con@EXAMPLE.COM
kadmin/history@EXAMPLE.COM
kadmin: quit

ProcedureKerberos 主体の属性を表示する方法

対応するコマンド行の例は、この手順のあとに示します。

  1. 必要に応じて、SEAM ツールを起動します。

    詳細は、「SEAM ツールを起動する方法」を参照してください。


    $ /usr/sbin/gkadmin

  2. 「Principals」タブをクリックします。

  3. 表示する主体を一覧から選択して、「Modify」をクリックします。

    「Principal Basic」パネルが表示され、主体の属性の一部が示されます。

  4. 「Next」をクリックして、主体のすべての属性を表示します。

    属性情報は、3 つのウィンドウに表示されます。「Help」メニューから「Context-Sensitive Help」を選択すると、各ウィンドウの属性に関する情報が表示されます。主体のすべての属性の説明については、「SEAM ツールパネルの説明」を参照してください。

  5. 表示を終了する場合は、「Cancel」をクリックします。

例 25–2 Kerberos 主体の属性の表示

次の例は、jdb/admin 主体を表示したときの最初のウィンドウです。

「SEAM Administration Tool」というタイトルのダイアログボックスに、jdb/admin 主体のアカウントデータが表示されています。アカウントデータの有効期限とコメントが表示されています。
例 25–3 Kerberos 主体の属性の表示 (コマンド行)

次の例では、kadmin の get_principal コマンドを使用して、jdb/admin 主体の属性を表示します。


kadmin: getprinc jdb/admin
Principal: jdb/admin@EXAMPLE.COM

Expiration date: [never]
Last password change: [never]

Password expiration date: Wed Apr 14 11:53:10 PDT 2011
Maximum ticket life: 1 day 16:00:00
Maximum renewable life: 1 day 16:00:00
Last modified: Mon Sep 28 13:32:23 PST 2009 (host/admin@EXAMPLE.COM)
Last successful authentication: [never]
Last failed authentication: [never]
Failed password attempts: 0
Number of keys: 1
Key: vno 1, AES-256 CTS mode with 96-bit SHA-1 HMAC, no salt
Key: vno 1, AES-128 CTS mode with 96-bit SHA-1 HMAC, no salt
Key: vno 1, Triple DES with HMAC/sha1, no salt
Key: vno 1, ArcFour with HMAC/md5, no salt
Key: vno 1, DES cbc mode with RSA-MD5, no salt
Attributes: REQUIRES_HW_AUTH
Policy: [none]
kadmin: quit

Procedure新しい Kerberos 主体を作成する方法

対応するコマンド行の例は、この手順のあとに示します。

  1. 必要に応じて、SEAM ツールを起動します。

    詳細は、「SEAM ツールを起動する方法」を参照してください。

    注 –

    新しい主体を作成するときに、新しいポリシーが必要な場合は、新しいポリシーを作成してから新しい主体を作成する必要があります。「新しい Kerberos ポリシーを作成する方法」を参照してください。


    $ /usr/sbin/gkadmin

  2. 「Principals」タブをクリックします。

  3. 「New」をクリックします。

    「Principal Basics」パネルが表示され、主体の属性の一部が示されます。

  4. 主体名とパスワードを指定します。

    主体名とパスワードは必須です。

  5. 主体の暗号化タイプを指定します。

    暗号化鍵タイプフィールドの右にあるボックスをクリックして、使用可能なすべての暗号化鍵タイプを表示する新しいウィンドウを開きます。必須の暗号化タイプを選択してから、「OK」をクリックします。

    「SEAM Encryption Type List Helper」というタイトルのダイアログボックスに、インストール済みのすべての暗号化タイプが表示されます。

  6. 主体のポリシーを指定します。

  7. 主体の属性に値を指定します。「Next」をクリックして、属性の値を必要に応じて指定します。

    属性情報は、3 つのウィンドウに表示されます。「Help」メニューから「Context-Sensitive Help」を選択すると、各ウィンドウの属性に関する情報が表示されます。主体のすべての属性の説明については、「SEAM ツールパネルの説明」を参照してください。

  8. 主体を保存する場合は、「Save」をクリックします。または、最後のパネルで「Done」をクリックします。

  9. 必要に応じて、新しい主体の Kerberos 管理権限を /etc/krb5/kadm5.acl ファイルに設定します。

    詳細は、「Kerberos 管理権限を変更する方法」を参照してください。

例 25–4 新しい Kerberos 主体の作成

次の例は、pak という新しい主体を作成するときの「Principal Basics」パネルです。ポリシーには、testuser が設定されています。

「SEAM Administration Tool」というタイトルのダイアログボックスに、pak 主体のアカウントデータが表示されています。パスワード、アカウントの有効期限、および testuser のポリシーが表示されています。
例 25–5 新しい Kerberos 主体の作成 (コマンド行)

次の例では、kadmin の add_principal コマンドを使用して、 pak という新しい主体を作成します。この主体のポリシーには、testuser が設定されています。


kadmin: add_principal -policy testuser pak
Enter password for principal "pak@EXAMPLE.COM": <Type the password>
Re-enter password for principal "pak@EXAMPLE.COM": <Type the password again>
Principal "pak@EXAMPLE.COM" created.
kadmin: quit

ProcedureKerberos 主体を複製する方法

この手順では、既存の主体の一部またはすべてを使用して、新しい主体を作成する方法について説明します。この手順に対応するコマンド行はありません。

  1. 必要に応じて、SEAM ツールを起動します。

    詳細は、「SEAM ツールを起動する方法」を参照してください。


    $ /usr/sbin/gkadmin

  2. 「Principals」タブをクリックします。

  3. 複製する主体を一覧から選択して、「Duplicate」をクリックします。

    「Principal Basics」パネルが表示されます。選択した主体のすべての属性が複製されます。ただし、「Principal Name」と「Password」フィールドは複製されず、空で表示されます。

  4. 主体名とパスワードを指定します。

    主体名とパスワードは必須です。選択した主体をそのまま複製するときは、「Save」をクリックして、手順 7 に進みます。

  5. 主体の属性に別の値を指定します。「Next」をクリックして、属性の値を必要に応じて指定します。

    属性情報は、3 つのウィンドウに表示されます。「Help」メニューから「Context-Sensitive Help」を選択すると、各ウィンドウの属性に関する情報が表示されます。主体のすべての属性の説明については、「SEAM ツールパネルの説明」を参照してください。

  6. 主体を保存する場合は、「Save」をクリックします。または、最後のパネルで「Done」をクリックします。

  7. 必要に応じて、主体の Kerberos 管理権限を /etc/krb5/kadm5.acl ファイルに設定します。

    詳細は、「Kerberos 管理権限を変更する方法」を参照してください。

ProcedureKerberos 主体を変更する方法

対応するコマンド行の例は、この手順のあとに示します。

  1. 必要に応じて、SEAM ツールを起動します。

    詳細は、「SEAM ツールを起動する方法」を参照してください。


    $ /usr/sbin/gkadmin

  2. 「Principals」タブをクリックします。

  3. 変更する主体を一覧から選択して、「Modify」をクリックします。

    「Principal Basic」パネルが表示され、主体の属性の一部が示されます。

  4. 主体の属性を変更します。「Next」をクリックして、必要に応じて属性を変更します。

    属性情報は、3 つのウィンドウに表示されます。「Help」メニューから「Context-Sensitive Help」を選択すると、各ウィンドウの属性に関する情報が表示されます。主体のすべての属性の説明については、「SEAM ツールパネルの説明」を参照してください。

    注 –

    主体名は変更できません。主体名を変更するときは、主体を複製し、新しい名前を指定して保存してから、古い主体を削除する必要があります。

  5. 主体を保存する場合は、「Save」をクリックします。または、最後のパネルで「Done」をクリックします。

  6. /etc/krb5/kadm5.acl ファイルで、主体の Kerberos 管理権限を変更します。

    詳細は、「Kerberos 管理権限を変更する方法」を参照してください。

例 25–6 Kerberos 主体のパスワードの変更 (コマンド行)

次の例では、kadmin の change_password コマンドを使用して、jdb 主体のパスワードを変更します。change_password コマンドでは、主体のパスワード履歴に存在するパスワードには変更できません。


kadmin: change_password jdb
Enter password for principal "jdb": <Type the new password>
Re-enter password for principal "jdb": <Type the password again>
Password for "jdb@EXAMPLE.COM" changed.
kadmin: quit

主体のその他の属性を変更するには、kadmin の modify_principal コマンドを使用する必要があります。

ProcedureKerberos 主体を削除する方法

対応するコマンド行の例は、この手順のあとに示します。

  1. 必要に応じて、SEAM ツールを起動します。

    詳細は、「SEAM ツールを起動する方法」を参照してください。


    $ /usr/sbin/gkadmin

  2. 「Principals」タブをクリックします。

  3. 削除する主体を一覧から選択して、「Delete」をクリックします。

    削除を確定すると、主体が削除されます。

  4. Kerberos アクセス制御リスト (ACL) ファイル /etc/krb5/kadm5.acl から主体を削除します。

    詳細は、「Kerberos 管理権限を変更する方法」を参照してください。

例 25–7 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

Procedure新しい Kerberos 主体を作成するときのデフォルトを設定する方法

この手順に対応するコマンド行はありません。

  1. 必要に応じて、SEAM ツールを起動します。

    詳細は、「SEAM ツールを起動する方法」を参照してください。


    $ /usr/sbin/gkadmin

  2. 「Edit」メニューから「Properties」を選択します。

    「Properties」ウィンドウが表示されます。

    「Properties」というタイトルのダイアログボックスに、新しい主体とリストコントロールのデフォルトが表示されています。主体のデフォルトには、セキュリティーやその他のオプションが含まれます。

  3. 新しい主体を作成するときに使用するデフォルトを選択します。

    「Help」メニューから「Context-Sensitive Help」を選択すると、各ウィンドウの属性に関する情報が表示されます。

  4. 「Save」をクリックします。

ProcedureKerberos 管理権限を変更する方法

使用する環境には、多くのユーザー主体が登録されていると思われます。しかし、Kerberos データベースの管理者は通常、少数のユーザーだけに割り当てます。Kerberos データベースを管理する権限は、Kerberos アクセス制御リスト (ACL) ファイル (kadm5.acl) によって判断されます。kadm5.acl ファイルを使用すると、主体ごとに権限を設定できます。主体名にワイルドカード (*) を使用すると、複数の主体に権限を指定できます。

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

  2. /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 に適用されます。主体名の任意の場所にワイルドカード (*) を使用できます。主体をグループ化するときに使用します。

例 25–8 Kerberos 管理権限の変更

kadm5.acl ファイル内の次のエントリは、EXAMPLE.COM レルム内で admin インスタンスを持つ すべての主体に対して、Kerberos データベース上のすべての権限を与えます。


*/admin@EXAMPLE.COM *

kadm5.acl ファイル内の次のエントリは、jdb@EXAMPLE.COM 主体に対して、root インスタンスを持つすべての主体に関する追加、一覧表示、および照会の権限を与えます。


jdb@EXAMPLE.COM ali */root@EXAMPLE.COM

Kerberos 主体の管理

この節では、SEAM ツールを使用してポリシーを管理する手順について説明します。また、対応するコマンド行がある場合は、その例も示します。

Kerberos ポリシーの管理 (作業マップ)

作業 

説明 

参照先 

ポリシーの一覧を表示します。 

「Policies」タブをクリックして、ポリシーの一覧を表示します。 

「Kerberos ポリシーの一覧を表示する方法」

ポリシーの属性を表示します。 

「Policy List」からポリシーを選択し、「Modify」ボタンをクリックして、ポリシーの属性を表示します。 

「Kerberos ポリシーの属性を表示する方法」

新しいポリシーを作成します。 

「Policy List」パネルの「Create New」ボタンをクリックして、新しいポリシーを作成します。 

「新しい Kerberos ポリシーを作成する方法」

ポリシーを複製します。 

複製するポリシーを「Policy List」ポリシーから選択し、「Duplicate」ボタンをクリックして、ポリシーを複製します。 

「Kerberos ポリシーを複製する方法」

ポリシーを変更します。 

変更するポリシーを「Policy List」ポリシーから選択し、「Modify」ボタンをクリックして、ポリシーを変更します。 

ポリシー名は変更できません。ポリシー名を変更するときは、ポリシーを複製し、新しい名前を指定して保存してから、古いポリシーを削除する必要があります。 

「Kerberos ポリシーを変更する方法」

ポリシーを削除します。 

削除するポリシーを「Policy List」ポリシーから選択し、「Delete」ボタンをクリックして、ポリシーを削除します。 

「Kerberos ポリシーを削除する方法」

ProcedureKerberos ポリシーの一覧を表示する方法

対応するコマンド行の例は、この手順のあとに示します。

  1. 必要に応じて、SEAM ツールを起動します。

    詳細は、「SEAM ツールを起動する方法」を参照してください。


    $ /usr/sbin/gkadmin

  2. 「Policies」タブをクリックします。

    ポリシーの一覧が表示されます。

    「SEAM Administration Tool」というタイトルのダイアログボックスに、ポリシーの一覧とポリシーのフィルタが表示されています。「Modify」、「Create New」、「Delete」、「Duplicate」ボタンが表示されています。

  3. 特定のポリシーを表示するか、ポリシーの部分リストを表示します。

    「Filter」フィールドにフィルタ文字列を入力して、Return キーを押します。フィルタが正常終了すると、フィルタに一致するポリシーの一覧が表示されます。

    フィルタ文字列は、1 文字以上の文字列である必要があります。フィルタメカニズムでは大文字と小文字が区別されるため、大文字と小文字を正しく指定する必要があります。たとえば、フィルタ文字列に ge と入力すると、ポリシー名に文字列 ge を含むポリシー (george、edge など) だけが表示されます。

    すべてのポリシーを表示するには、「Clear Filter」をクリックします。

例 25–9 Kerberos ポリシーの一覧の表示 (コマンド行)

次の例では、kadmin の list_policies コマンドを使用して、*user* と一致するすべてのポリシーを表示します。list_policies コマンドでは、ワイルドカードを使用できます。


kadmin: list_policies *user*
testuser
enguser
kadmin: quit

ProcedureKerberos ポリシーの属性を表示する方法

対応するコマンド行の例は、この手順のあとに示します。

  1. 必要に応じて、SEAM ツールを起動します。

    詳細は、「SEAM ツールを起動する方法」を参照してください。


    $ /usr/sbin/gkadmin

  2. 「Policies」タブをクリックします。

  3. 表示するポリシーを一覧から選択して、「Modify」をクリックします。

    「Policy Details」パネルが表示されます。

  4. 表示を終了する場合は、「Cancel」をクリックします。

例 25–10 Kerberos ポリシーの属性の表示

次の例は、test ポリシーを表示したときの「Policy Details」パネルです。

「SEAM Administration Tool」というタイトルのダイアログボックスに、enguser ポリシーのポリシー詳細が表示されています。「Save」、「Previous」、「Done」、および「Cancel」ボタンが表示されています。
例 25–11 Kerberos ポリシーの属性の表示 (コマンド行)

次の例では、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

「Reference count」は、このポリシーを使用する主体の数です。

Procedure新しい Kerberos ポリシーを作成する方法

対応するコマンド行の例は、この手順のあとに示します。

  1. 必要に応じて、SEAM ツールを起動します。

    詳細は、「SEAM ツールを起動する方法」を参照してください。


    $ /usr/sbin/gkadmin

  2. 「Policies」タブをクリックします。

  3. 「New」をクリックします。

    「Policy Details」パネルが表示されます。

  4. 「Policy Name」フィールドにポリシー名を指定します。

    ポリシー名は必須です。

  5. ポリシーの属性の値を指定します。

    「Help」メニューから「Context-Sensitive Help」を選択すると、このウィンドウの属性に関する情報が表示されます。ポリシーのすべての属性の説明については、表 25–5 を参照してください。

  6. 「Save」をクリックしてポリシーを保存するか、「Done」をクリックします。

例 25–12 新しい Kerberos ポリシーの作成

次の例では、build11 という新しいポリシーを作成します。「Minimum Password Classes」は、3 に設定されています。

「SEAM Administration Tool」というタイトルのダイアログボックスに、build11 ポリシーのポリシー詳細が表示されています。「Save」、「Previous」、「Done」、および「Cancel」ボタンが表示されています。
例 25–13 新しい Kerberos ポリシーの作成 (コマンド行)

次の例では、kadmin の add_policy コマンドを使用して、build11 ポリシーを作成します。このポリシーのパスワードには、3 種類以上の文字クラスが必要です。


$ kadmin
kadmin: add_policy -minclasses 3 build11
kadmin: quit

ProcedureKerberos ポリシーを複製する方法

この手順では、既存のポリシーの一部またはすべてを使用して、新しいポリシーを作成する方法について説明します。この手順に対応するコマンド行はありません。

  1. 必要に応じて、SEAM ツールを起動します。

    詳細は、「SEAM ツールを起動する方法」を参照してください。


    $ /usr/sbin/gkadmin

  2. 「Policies」タブをクリックします。

  3. 複製するポリシーを一覧から選択して、「Duplicate」をクリックします。

    「Policy Details」パネルが表示されます。選択したフィールドのすべての属性が複製されます。ただし、「Policy Name」フィールドは空で表示されます。

  4. 複製するポリシー名を「Policy Name」フィールドに指定します。

    ポリシー名は必須です。選択したポリシーをそのまま複製するには、手順 6 に進みます。

  5. ポリシーの属性に別の値を指定します。

    「Help」メニューから「Context-Sensitive Help」を選択すると、このウィンドウの属性に関する情報が表示されます。ポリシーのすべての属性の説明については、表 25–5 を参照してください。

  6. 「Save」をクリックしてポリシーを保存するか、「Done」をクリックします。

ProcedureKerberos ポリシーを変更する方法

対応するコマンド行の例は、この手順のあとに示します。

  1. 必要に応じて、SEAM ツールを起動します。

    詳細は、「SEAM ツールを起動する方法」を参照してください。


    $ /usr/sbin/gkadmin

  2. 「Policies」タブをクリックします。

  3. 変更するポリシーを一覧から選択して「Modify」をクリックします。

    「Policy Details」パネルが表示されます。

  4. ポリシーの属性を変更します。

    「Help」メニューから「Context-Sensitive Help」を選択すると、このウィンドウの属性に関する情報が表示されます。ポリシーのすべての属性の説明については、表 25–5 を参照してください。

    注 –

    ポリシー名は変更できません。ポリシー名を変更するときは、ポリシーを複製し、新しい名前を指定して保存してから、古いポリシーを削除する必要があります。

  5. 「Save」をクリックしてポリシーを保存するか、「Done」をクリックします。

例 25–14 Kerberos ポリシーの変更 (コマンド行)

次の例では、kadmin の modify_policy コマンドを使用して、build11 ポリシーの最小パスワード長を 5 文字に変更します。


$ kadmin
kadmin: modify_policy -minlength 5 build11
kadmin: quit

ProcedureKerberos ポリシーを削除する方法

対応するコマンド行の例は、この手順のあとに示します。

注 –

ポリシーを削除する前に、現在使用しているすべての主体からそのポリシーを取り消す必要があります。ポリシーを取り消すには、その主体の「Policy」属性を変更する必要があります。任意の主体が使用しているポリシーは、削除できません。

  1. 必要に応じて、SEAM ツールを起動します。

    詳細は、「SEAM ツールを起動する方法」を参照してください。


    $ /usr/sbin/gkadmin

  2. 「Policies」タブをクリックします。

  3. 削除するポリシーを一覧から選択して、「Delete」をクリックします。

    削除を確定すると、ポリシーが削除されます。

例 25–15 Kerberos ポリシーの削除 (コマンド行)

次の例では、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 ツールパネルの説明

この節では、SEAM ツールで指定または表示できる主体とポリシーの属性について説明します。属性は、表示されるパネルごとに分類されています。

表 25–2 SEAM ツールの「Principal Basics」パネルの属性

属性 

説明 

Principal Name 

主体名 (完全指定形式の主体名の primary/instance 部分)。主体は、KDC がチケットを割り当てることができる一意の ID です。

主体を変更しても、主体名は編集できません。 

パスワード 

主体のパスワード。「Generate Random Password」ボタンを使用して、主体のランダムパスワードを作成できます。 

Policy 

主体に使用できるポリシーのメニュー。 

Account Expires 

主体のアカウントが期限切れになる日時。アカウントが期限切れになると、主体はチケット認可チケット (TGT) を取得できず、ログインできなくなります。 

Last Principal Change  

主体の情報が最後に変更された日付。(読み取り専用) 

Last Changed By 

この主体のアカウントを最後に変更した主体名。(読み取り専用) 

Comments 

主体に関連するコメント (「一時アカウント」など)。 

表 25–3 SEAM ツールの「Principal Details」パネルの属性

属性 

説明 

Last Success 

主体が最後に正常にログインした日時。(読み取り専用) 

Last Failure 

主体が最後にログインに失敗した日時。(読み取り専用) 

Failure Count 

主体のログインが失敗した回数。(読み取り専用) 

Last Password Change 

主体のパスワードが最後に変更された日時。(読み取り専用) 

Password Expires 

主体の現在のパスワードが期限切れになる日時。 

Key Version 

主体の鍵のバージョン番号。この属性は通常、パスワードが危険にさらされた場合にだけ変更されます。 

Maximum Lifetime (seconds) 

チケットを主体が使用できる最大期間 (更新しない場合)。 

Maximum Renewal (seconds) 

既存のチケットを主体が更新できる最大期間。 

表 25–4 SEAM ツールの「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 を使用して別のサービスのチケットを取得できます。ただし、チケット認可チケット (TGT) を取得することはできません。 

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 を主体に送信する前に、主体の事前認証を必要としません。 

表 25–5 SEAM ツールの「Policy Basics」区画の属性

属性 

説明 

ポリシー名 

ポリシー名。ポリシーとは、主体のパスワードとチケットを管理する一連のルールのことです。 

ポリシーを変更しても、ポリシー名は編集できません。 

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 ツールの使い方が異なります。表 25–6 は、Kerberos 管理権限に基づいた SEAM ツールの変更の一覧です。

一覧表示権限がない場合、SEAM ツールの表示がもっとも大きく変わります。この場合、操作する主体とポリシーの一覧が「List」パネルに表示されません。代わりに、「List」パネルの「Name」フィールドを使用して、操作する主体またはポリシーを指定する必要があります。

SEAM ツールにログインしても、必要な権限がない場合は、次のメッセージが表示されて「SEAM Administration Login」ウィンドウに戻ります。


Insufficient privileges to use gkadmin: ADMCIL. Please try using another principal.

主体が Kerberos データベースを管理する権限を変更する方法については、「Kerberos 管理権限を変更する方法」を参照してください。

表 25–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 主体をホストのキータブファイルに追加する特別な場合もあります。Kerberos クライアント上のユーザーが root と同等のアクセスを必要とする Kerberos NFS ファイルシステムをマウントするようにするには、クライアントの root 主体をクライアントのキータブファイルに追加する必要があります。追加しなかった場合、root アクセスで Kerberos NFS ファイルシステムをマウントするたびに、ユーザーは kinit コマンドをスーパーユーザーとして使用して、クライアントの root 主体の資格を取得する必要があります。これは、オートマウンタを使用している場合でも同様です。

注 –

マスター KDC を設定するときは、kadmind および changepw 主体を kadm5.keytab ファイルに追加する必要があります。

キータブファイルを管理するときに、ktutil コマンドも使用できます。この対話型のコマンドは、Kerberos 管理権限がなくても、ローカルホストのキータブファイルを管理できます。kadmin は Kerberos データベースと対話しますが、ktutil は対話しないためです。つまり、主体をキータブファイルに追加したあとに ktutil を使用すると、キータブファイル内のキー一覧を表示したり、サービスの認証を一時的に無効にしたりできます。

注 –

kadmin の ktadd コマンドを使用してキータブファイル内の主体を変更すると、新しい鍵が生成され、キータブファイルに追加されます。

キータブファイルの管理 (作業マップ)

作業 

説明 

参照先 

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

kadmin の ktadd コマンドを使用して、サービス主体をキータブファイルに追加します。

「Kerberos サービス主体をキータブファイルに追加する方法」

キータブファイルからサービス主体を削除します。 

kadmin の ktremove コマンドを使用して、キータブファイルからサービスを削除します。

「キータブファイルからサービス主体を削除する方法」

キータブファイル内のキー一覧 (主体の一覧) を表示します。 

ktutil コマンドを使用して、キータブファイル内のキー一覧を表示します。

「キータブファイル内のキー一覧 (主体) を表示する方法」

ホスト上でのサービスの認証を一時的に無効にします。 

この手順を行うと、kadmin 権限がなくても、ホスト上でのサービスの認証を一時的に無効にできます。

ktutil を使用してサーバーのキータブファイルからサービス主体を削除する前に、元のキータブファイルを一時的な位置にコピーする必要があります。サービスを再度有効にする場合は、元のキータブファイルを適切な場所に戻す必要があります。

「ホスト上のサービスの認証を一時的に無効にする方法」

ProcedureKerberos サービス主体をキータブファイルに追加する方法

  1. 主体がすでに Kerberos データベースに登録されていることを確認します。

    詳細は、「Kerberos 主体の一覧を表示する方法」を参照してください。

  2. キータブファイルに主体を追加するホスト上でスーパーユーザーになります。

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


    # /usr/sbin/kadmin

  4. ktadd コマンドを使用して、キータブファイルに主体を追加します。


    kadmin: ktadd [-e enctype] [-k keytab] [-q] [principal | -glob principal-exp]
    -e enctype

    krb5.conf ファイルに定義された暗号化タイプの一覧を上書きします。

    -k keytab

    キータブファイルを指定します。デフォルトでは、/etc/krb5/krb5.keytab が使用されます。

    -q

    冗長な情報を表示しません。

    principal

    キータブファイルに追加する主体を指定します。追加できるサービス主体は、次のとおりです。 host、root、nfs、および ftp。

    -glob principal-exp

    主体表現を指定します。principal-exp に一致するすべての主体が、キータブファイルに追加されます。主体表現の規則は、kadmin の list_principals コマンドと同じです。

  5. kadmin コマンドを終了します。


    kadmin: quit
例 25–16 サービス主体のキータブファイルへの追加

次の例では、kadmin/kdc1.example.com および changepw/kdc1.example.com 主体をマスター KDC のキータブファイルに追加しています。この例のキータブファイルは、kdc.conf ファイルで指定されている必要があります。


kdc1 # /usr/sbin/kadmin.local
kadmin.local: ktadd -k /etc/krb5/kadm5.keytab kadmin/kdc1.example.com changepw/kdc1.example.com
Entry for principal kadmin/kdc1.example.com with kvno 3, encryption type AES-256 CTS mode
          with 96-bit SHA-1 HMAC added to keytab WRFILE:/etc/krb5/kadm5.keytab.
Entry for principal kadmin/kdc1.example.com with kvno 3, encryption type AES-128 CTS mode
          with 96-bit SHA-1 HMAC added to keytab WRFILE:/etc/krb5/kadm5.keytab.
Entry for principal kadmin/kdc1.example.com with kvno 3, encryption type Triple DES cbc
          mode with HMAC/sha1 added to keytab WRFILE:/etc/krb5/kadm5.keytab.
Entry for principal kadmin/kdc1.example.com with kvno 3, encryption type ArcFour
          with HMAC/md5 added to keytab WRFILE:/etc/krb5/kadm5.keytab.
Entry for principal kadmin/kdc1.example.com with kvno 3, encryption type DES cbc mode
          with RSA-MD5 added to keytab WRFILE:/etc/krb5/kadm5.keytab.
Entry for principal changepw/kdc1.example.com with kvno 3, encryption type AES-256 CTS
          mode with 96-bit SHA-1 HMAC added to keytab WRFILE:/etc/krb5/kadm5.keytab.
Entry for principal changepw/kdc1.example.com with kvno 3, encryption type AES-128 CTS
          mode with 96-bit SHA-1 HMAC added to keytab WRFILE:/etc/krb5/kadm5.keytab.
Entry for principal changepw/kdc1.example.com with kvno 3, encryption type Triple DES cbc
          mode with HMAC/sha1 added to keytab WRFILE:/etc/krb5/kadm5.keytab.
Entry for principal changepw/kdc1.example.com with kvno 3, encryption type ArcFour
          with HMAC/md5 added to keytab WRFILE:/etc/krb5/kadm5.keytab.
Entry for principal changepw/kdc1.example.com with kvno 3, encryption type DES cbc mode
          with RSA-MD5 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
Entry for principal host/denver.example.com with kvno 3, encryption type AES-256 CTS
          mode with 96-bit SHA-1 HMAC added to keytab WRFILE:/etc/krb5/krb5.keytab.
Entry for principal host/denver.example.com with kvno 3, encryption type AES-128 CTS mode
          with 96-bit SHA-1 HMAC added to keytab WRFILE:/etc/krb5/krb5.keytab.
Entry for principal host/denver.example.com with kvno 3, encryption type Triple DES cbc mode
          with HMAC/sha1 added to keytab WRFILE:/etc/krb5/krb5.keytab.
Entry for principal host/denver.example.com with kvno 3, encryption type ArcFour
          with HMAC/md5 added to keytab WRFILE:/etc/krb5/krb5.keytab.
Entry for principal host/denver.example.com with kvno 3, encryption type DES cbc mode
          with RSA-MD5 added to keytab WRFILE:/etc/krb5/krb5.keytab.
kadmin: quit

Procedureキータブファイルからサービス主体を削除する方法

  1. キータブファイルから削除するサービス主体が登録されているホスト上でスーパーユーザーになります。

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


    # /usr/sbin/kadmin

  3. (省略可能) キータブファイル内の現在の主体 (鍵) の一覧を表示するには、ktutil コマンドを使用します。

    詳細な手順は、「キータブファイル内のキー一覧 (主体) を表示する方法」を参照してください。

  4. ktremove コマンドを使用して、キータブファイルから主体を削除します。


    kadmin: ktremove [-k keytab] [-q] principal [kvno | all | old ]
    -k keytab

    キータブファイルを指定します。デフォルトでは、/etc/krb5/krb5.keytab が使用されます。

    -q

    冗長な情報を表示しません。

    principal

    キータブファイルから削除する主体を指定します。

    kvno

    指定された主体のうち、鍵のバージョン番号が kvno と一致する主体のすべてのエントリを削除します。

    all

    指定された主体のすべてのエントリを削除します。

    old

    指定した主体のすべてのエントリを削除します。ただし、鍵のバージョン番号が最上位の主体は削除しません。

  5. kadmin コマンドを終了します。


    kadmin: quit
例 25–17 キータブファイルからのサービス主体の削除

次の例では、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

Procedureキータブファイル内のキー一覧 (主体) を表示する方法

  1. キータブファイルが存在するホスト上でスーパーユーザーになります。

    注 –

    ほかのユーザーが所有するキータブファイルを作成することもできますが、キータブファイルのデフォルトの位置を使用するには root 所有権が必要です。

  2. ktutil コマンドを起動します。


    # /usr/bin/ktutil

  3. read_kt コマンドを使用して、キータブファイルをキー一覧バッファーに読み込みます。


    ktutil: read_kt keytab

  4. list コマンドを使用して、キー一覧バッファーを表示します。


    ktutil: list

    現在のキー一覧バッファーが表示されます。

  5. ktutil コマンドを終了します。


    ktutil: quit
例 25–18 キータブファイル内のキー一覧 (主体) の表示

次の例では、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

Procedureホスト上のサービスの認証を一時的に無効にする方法

ネットワークアプリケーションサーバー上の rlogin や ftp など、サービスの認証メカニズムを一時的に無効にしなければならない場合があります。たとえば、保守作業中は、ユーザーがシステムにログインできないようにする必要があります。ktutil コマンドを使用してサーバーのキータブファイルからサービス主体を削除することにより、サービスの認証を一時的に無効にすることができます。このとき、kadmin 権限は必要ありません。認証を再度有効にするには、保存した元のキータブファイルを元の位置にコピーするだけです。

注 –

デフォルトでは、ほとんどのサービスが認証を要求するように設定されています。そのように設定されていないときは、サービスの認証を無効にした場合でもサービスは動作します。

  1. キータブファイルが存在するホスト上でスーパーユーザーになります。

    注 –

    ほかのユーザーが所有するキータブファイルを作成することもできますが、キータブファイルのデフォルトの位置を使用するには root 所有権が必要です。

  2. 現在のキータブファイルを一時ファイルに保存します。

  3. ktutil コマンドを起動します。


    # /usr/bin/ktutil

  4. read_kt コマンドを使用して、キータブファイルをキー一覧バッファーに読み込みます。


    ktutil: read_kt keytab

  5. list コマンドを使用して、キー一覧バッファーを表示します。


    ktutil: list

    現在のキー一覧バッファーが表示されます。無効にするサービスのスロット番号を記録します。

  6. ホストのサービスを一時的に無効にするには、delete_entry コマンドを使用して、キー一覧バッファーから特定のサービス主体を削除します。


    ktutil: delete_entry slot-number

    この例では、slot-number に、削除するサービス主体のスロット番号を指定します。スロット番号は、list コマンドで表示できます。

  7. write_kt コマンドを使用して、新しいキー一覧バッファーをキータブファイルに書き込みます。


    ktutil: write_kt new-keytab

  8. ktutil コマンドを終了します。


    ktutil: quit

  9. 新しいキータブファイルの名前を変更します。


    # mv new-keytab keytab

  10. サービスを再度有効にする場合は、一時的な (元の) キータブファイルを元の場所にコピーします。

例 25–19 ホスト上のサービスを一時的に無効にする

次の例では、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/new.krb5.keytab
    ktutil: quit
denver # cp /etc/krb5/new.krb5.keytab /etc/krb5/krb5.keytab

第 26 章 Kerberos アプリケーションの使用 (手順)

この章は、Kerberos サービスが構成されているシステムのユーザーを対象としています。この章では、提供されている Kerberos コマンドとサービスの使用方法について説明します。この章を読み進めるには、これらのコマンド (Kerberos 以外) にすでに慣れ親しんでいる必要があります。

この章は一般的なユーザーを対象としているため、 チケットの取得、表示、および廃棄について説明します。また、Kerberos パスワードの選択または変更についても説明します。

この章の内容は次のとおりです。

Solaris Kerberos 製品の概要については、第 21 章Kerberos サービスについてを参照してください。

Kerberos チケットの管理

この節では、チケットの取得、表示、および破棄を行う方法を説明します。チケットの概要については、「Kerberos サービスの動作」を参照してください。

チケットを意識する必要があるか

すべての SEAM リリースまたは Solaris 10 リリースがインストールされている場合、Kerberos は login に組み込まれており、チケットの取得はログイン時に自動的に行われます。Kerberos に対応するコマンドの rsh、rcp、rdist、telnet、および rlogin は通常、チケットのコピーをほかのマシンに転送するように設定されています。そうすると、ユーザーがチケットを明示的に要求しなくても、それらのマシンにアクセスできるようになるからです。これがデフォルトの動作ですが、特定のユーザーの構成はこの自動転送を含んでいない場合があります。チケットの転送については、「Kerberos コマンドの概要」および 「Kerberos チケットの転送」を参照してください。

チケットの有効期限については、「チケットの有効期限」を参照してください。

Kerberos チケットの作成

通常、PAM が適切に設定されている場合、ログインするとチケットが自動的に作成されるため、チケットを取得するために特別な作業をする必要はありません。ただし、チケットが期限切れになった場合は、チケットを作成する必要があります。また、デフォルトの主体のほかに別の主体を使用する必要がある場合 (たとえば、rlogin -l を使って他人としてマシンにログインする) があります。

チケットを作成するには、kinit コマンドを使用します。


% /usr/bin/kinit

kinit コマンドからはパスワードの入力を求めるプロンプトが表示されます。kinit コマンドの詳細な構文については、kinit(1) のマニュアルページを参照してください。

例 26–1 Kerberos チケットの作成

次の例では、ユーザー jennifer が自分のシステムにチケットを作成します。


% kinit
Password for jennifer@ENG.EXAMPLE.COM:  <Type password>

次の例では、ユーザー david が -l オプションを使用して 3 時間有効なチケットを作成します。


% kinit -l 3h david@EXAMPLE.ORG
Password for david@EXAMPLE.ORG:  <Type password>

次の例では、ユーザー david は、-f オプションを使用して、転送可能チケットを作成します。たとえば、この転送可能チケットを使用して、2 つ目のシステムにログインして、3 つ目のシステムに telnet を実行できます。


% kinit -f david@EXAMPLE.ORG
Password for david@EXAMPLE.ORG:     <Type password>

転送チケットをどのように使用するかについては、「Kerberos チケットの転送」および 「チケットの種類」を参照してください。

Kerberos チケットの表示

すべてのチケットが同じ属性を持つわけではありません。チケットの属性には、「転送可能 (Forwardable)」、「遅延 (Postdated)」などがあります。また、1 つのチケットに「転送可能」と「遅延」の両方が指定されていることもあります。現在のチケットが何で、どのような属性を持つかを知るには、klist コマンドで -f オプションを使用します。


% /usr/bin/klist -f

次の記号はチケットに関連付けられる属性です。klist によって表示されます。

A

事前認証済み

D

遅延可能 (Postdatable)

d

遅延 (Postdated)

F

転送可能 (Forwardable)

f

転送済み (Forwarded)

I

初期 (Initial)

i

無効 (Invalid)

P

プロキシ可能 (Proxiable)

p

プロキシ (Proxy)

R

更新可能 (Renewable)

チケットに指定できる属性については、「チケットの種類」を参照してください。

例 26–2 Kerberos チケットの表示

次の例は、ユーザー jennifer の初期チケットが転送可能 (F) と遅延 (d) のプロパティーを持っていて、まだ検証されていないこと (i) を示します。 


% /usr/bin/klist -f
Ticket cache: /tmp/krb5cc_74287
Default principal: jennifer@EXAMPLE.COM
 
Valid starting                 Expires                 Service principal
09 Mar 04 15:09:51  09 Mar 04 21:09:51  nfs/EXAMPLE.COM@EXAMPLE.COM
        renew until 10 Mar 04 15:12:51, Flags: Fdi

次の例は、ユーザー david が別のホストから自分のホストに転送済み (f) チケットを 2 つ持っていることを示します。これらのチケットは転送可能 (F) です。 


% klist -f
Ticket cache: /tmp/krb5cc_74287
Default principal: david@EXAMPLE.COM
 
Valid starting                 Expires                 Service principal
07 Mar 04 06:09:51  09 Mar 04 23:33:51  host/EXAMPLE.COM@EXAMPLE.COM
        renew until 10 Mar 04 17:09:51, Flags: fF
 
Valid starting                 Expires                 Service principal
08 Mar 04 08:09:51  09 Mar 04 12:54:51  nfs/EXAMPLE.COM@EXAMPLE.COM
        renew until 10 Mar 04 15:22:51, Flags: fF

次の例は、-e オプションを使用してセッション鍵の暗号化タイプとチケットを表示させる方法を示しています。-a オプションを使用すると、ネームサービスが変換を行える場合、ホストアドレスをホスト名に変換できます。


% klist -fea
Ticket cache: /tmp/krb5cc_74287
Default principal: david@EXAMPLE.COM
 
Valid starting                 Expires                 Service principal
07 Mar 04 06:09:51  09 Mar 04 23:33:51  krbtgt/EXAMPLE.COM@EXAMPLE.COM
        renew until 10 Mar 04 17:09:51, Flags: FRIA
        Etype(skey, tkt): DES cbc mode with RSA-MD5, DES cbc mode with CRC-32
        Addresses: client.example.com

Kerberos チケットの破棄

現在のセッション中に取得したすべての Kerberos チケットを破棄するには、kdestroy コマンドを使用します。このコマンドは、資格キャッシュを破棄して、すべての資格とチケットを破棄します。通常、これは必要ありませんが、kdestroy コマンドを実行すると、ログインしていないときに資格キャッシュが継続して存在する可能性を減らすことができます。

チケットを破棄するには、kdestroy コマンドを使用します。


% /usr/bin/kdestroy

kdestroy コマンドは、そのユーザーのすべてのチケットを破棄します。このコマンドを使用して、特定のチケットを選択して破棄することはできません。

システムを離れるときに侵入者が権限を使用する危険がある場合は、kdestroy を使用してチケットを破棄するか、スクリーンセーバーを使って画面をロックする必要があります。

Kerberos パスワード管理

Kerberos サービスが構成されている場合、パスワードを 2 つ持つことになります。 通常の Solaris パスワードと Kerberos パスワードです。これらのパスワードは同じでも、異なっていても構いません。

パスワード選択のヒント

パスワードには、キーボードから入力できるほとんどの文字を使用できます。ただし、Ctrl キーと Return キーは使用できません。良いパスワードとは、覚えやすく、しかも他人が簡単に推定できないパスワードです。悪いパスワードの例を次に示します。

良いパスワードとは 8 文字以上の長さで、大文字、小文字、数字、句読記号などが混在しているものです。次に例を示します。

注意 – 注意 –

これらの例は使用しないでください。マニュアルの例に使用されているパスワードは侵入者が最初に試みるパスワードです。

パスワードの変更方法

PAM が適切に設定されている場合、Kerberos パスワードは次の 2 つの方法で変更できます。

パスワードを変更しても、変更がシステム全体に伝播されるまでには、ある程度の時間が必要です (特に大規模なネットワークでは)。システムの設定方法によりますが、この時間は数分から 1 時間以上になることがあります。パスワードを変更したあとすぐに新しい Kerberos チケットを取得する場合は、新しいパスワードをまず試してください。新しいパスワードが有効でない場合は、以前のパスワードを使用して再度試してください。

Kerberos V5 プロトコルでは、システム管理者が有効なパスワードの基準をユーザーごとに設定できます。この基準は、ユーザーごとの「ポリシー」に定義できます。デフォルトのポリシーを使用することもできます。ポリシーの詳細については、「Kerberos 主体の管理」を参照してください。

たとえば、ユーザー jennifer の jenpol ポリシーでは、パスワードは 8 文字以上で、2 種類以上の文字で構成されると定義されているとします。その場合、パスワードとして「sloth」を入力すると、kpasswd によって拒否されます。


% kpasswd
kpasswd: Changing password for jennifer@ENG.EXAMPLE.COM.
Old password:   <Jennifer types her existing password>
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 types  'sloth'>
New password (again):  <Jennifer re-types '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 types her existing password>
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 types  'slothrop49'>
New password (again):  <Jennifer re-types 'slothrop49'>
Kerberos password changed.
例 26–3 パスワードの変更方法

次の例では、ユーザー david が passwd を使用して、UNIX および Kerberos のパスワードを変更します。 


% passwd
	passwd:  Changing password for david
	Enter login (NIS+) password:                <Type the current UNIX password>
	New password:                        <Type the new UNIX password>
	Re-enter password:                   <Confirm the new UNIX password>
	Old KRB5 password:                   <Type the current Kerberos password>
	New KRB5 password:                   <Type the new Kerberos password>
	Re-enter new KRB5 password:          <Confirm the new Kerberos password>

passwd では、UNIX パスワードと Kerberos パスワードの両方が要求されることに注意してください。この動作は、デフォルトの設定です。この場合、ユーザー david は kpasswd を使用して、次の例で示すように Kerberos パスワードを変更する必要があります。

次の例では、ユーザー david が kpasswd を使用して、Kerberos パスワードだけを変更します。


% kpasswd
kpasswd: Changing password for david@ENG.EXAMPLE.COM.
Old password:           <Type the current Kerberos password>
New password:           <Type the new Kerberos password>
New password (again):   <Confirm the new Kerberos password>
Kerberos password changed.

次の例では、ユーザー david が、Kerberos 主体 david/admin (有効な UNIX ユーザーではない) のパスワードを変更します。kpasswd を使用する必要があります。


% kpasswd david/admin
kpasswd:  Changing password for david/admin.
Old password:           <Type the current Kerberos password>
New password:           <Type the new Kerberos password>
New password (again):   <Type the new Kerberos password>
Kerberos password changed.

アカウントへのアクセス認可

他人があなたのアカウントを使用して (あなたとして) ログインする必要がある場合、Kerberos を使用すれば、パスワードを公表せずにそれを実現できます。それには、ホームディレクトリに .k5login ファイルを格納します。.k5login ファイルは、アクセス認可を与える各ユーザーに対応する、1 つ以上の Kerberos 主体の一覧です(1 つの主体を 1 行に入力する必要があります)。

ユーザー david が次のような .k5login ファイルをホームディレクトリに格納しているとします。


jennifer@ENG.EXAMPLE.COM
joe@EXAMPLE.ORG

このファイルによって、ユーザー jennifer と joe は david として振る舞うことができます。ただしそれには、その二人がすでにそれぞれのレルムにおいて Kerberos チケットを取得している必要があります。たとえば、jennifer は david として、david のマシン (boston) に david 自身のパスワードを入力せずに遠隔ログインできます。

図 26–1 アカウントへのアクセスを認可する .k5login ファイルの使用

この図については、前の本文中で説明しています。

david のホームディレクトリが、Kerberos V5 プロトコル経由で別の (3 つ目の) マシンから NFS マウントされている場合、jennifer がそのホームディレクトリにアクセスするには、彼女が転送チケットを所持している必要があります。転送可能チケットの使用例については、「Kerberos チケットの作成」を参照してください。

ネットワーク上のほかのマシンにログインする必要がある場合、それらのマシン上の .k5login ファイル内に自分の Kerberos 主体を追加します。

.k5login ファイルの使用は、次の理由により、パスワードを公表するよりも安全です。

.k5login ファイルの一般的な使い方の 1 つは、このファイルを root のホームディレクトリに格納し、ファイル内に記述された Kerberos 主体にそのマシンの root アクセス権限を与える、というものです。この設定により、システム管理者は、スーパーユーザーのパスワードを公表したり、そのパスワードをネットワーク上で入力したりせずに、ローカルで root になることも、root として遠隔ログインすることもできるようになります。

例 26–4 アカウントへのアクセスを認可する .k5login ファイルの使用

jennifer が、マシン boston.example.com に root としてログインするとします。彼女の主体名は boston.example.com 上の root ホームディレクトリ内の .k5login ファイルに含まれているため、彼女はここでもパスワードを入力する必要がありません。


% rlogin boston.example.com -l root -x
This rlogin session is using DES encryption for all data transmissions.
Last login: Thu Jun 20 16:20:50 from daffodil
SunOS Release 5.7 (GENERIC) #2: Tue Nov 14 18:09:31 EST 1998
boston[root]%

Kerberos ユーザーコマンド

Kerberos V5 製品は「シングルサインオン」システムです。つまり、1 度だけパスワードを入力する必要があるという意味です。Kerberos V5 プログラムがユーザーに代わって認証 (オプションで暗号化も) 行います。これは、Kerberos が、既存のよく知られたネットワークプログラム群ごとに構築されているためです。Kerberos V5 アプリケーションは、既存の UNIX ネットワークプログラムに Kerberos 機能を追加したバージョンです。

たとえば、ある Kerberos プログラムを使って特定の遠隔ホストに接続する場合、そのプログラム、KDC、その遠隔ホストの 3 者は、一連のネゴシエーションをすばやく実行します。これらのネゴシエーションが正常終了した場合、そのプログラムは遠隔ホストに対し、そのユーザーの身元をユーザーに代わって証明したことになり、遠隔ホストはそのユーザーにアクセスを認可します。

Kerberos コマンドは最初に、Kerberos を使用して認証しようとする点に注意してください。Kerberos 認証が失敗すると、エラーが発生するか、UNIX 認証が試みられますが、どちらになるかは、コマンドに指定されるオプションによって決まります。詳細は、各 Kerberos コマンドのマニュアルページの「Kerberos Security」節を参照してください。

Kerberos コマンドの概要

Kerberos ネットワークサービスは、インターネット上のほかのマシンと接続するプログラムです。これらには、次のプログラムがあります。

これらのプログラムは、Kerberos チケットを透過的に使って認証 (と暗号化) のネゴシエーションを遠隔ホストと行うための機能も備えています。それらを使用する際の変化といえば、多くの場合、パスワードを入力する必要がなくなったことに気付くことぐらいです。このとき、Kerberos がユーザーに代わってユーザーの身元証明を行なってくれています。

Kerberos V5 ネットワークプログラムは、次の機能を実現するオプションを備えています。

注 –

この節では、読者がすでにこれらの Kerberos 以外のプログラムに慣れ親しんでいることを前提に、Kerberos V5 パッケージによって追加された Kerberos 機能だけに的を絞って説明しています。ここで説明するコマンドの詳細については、各コマンドのマニュアルページを参照してください。

次の Kerberos オプションが、ftp、rcp、rlogin、rsh、および telnet に追加されています。

-a

既存のチケットを使用して自動ログインしようとします。getlogin() によって返されたユーザー名を使用します。ただし、現在のユーザー ID と異なる場合には使用しません。詳細は、telnet(1) のマニュアルページを参照してください。

-f

「再転送不可能な」チケットを遠隔ホストに転送します。このオプションは、-F オプションと互いに排他の関係にあります。つまり、これらを同一コマンド内で同時に使用することはできません。

3 つ目のホスト上のほかの Kerberos に基づくサービスに自身を認証する必要がある場合、チケットを転送します。たとえば、ほかのマシンに遠隔ログインして、そこから 3 つ目のマシンに遠隔ログインします。

遠隔ホスト上のホームディレクトリが Kerberos V5 を使用して NFS マウントされている場合、転送可能チケットを使用する必要があります。そうしなかった場合、ホームディレクトリにアクセスできません。つまり、最初、システム 1 にログインするものとします。システム 3 からホームディレクトリをマウントしたホームマシン、システム 2 にシステム 1 から遠隔ログインします。rlogin で-f または -F オプションを使用しない場合、チケットがシステム 3 に転送されないため、ホームディレクトリを取得できません。

kinit はデフォルトで、転送可能なチケット認可チケット (TGT) を取得します。ただし、このような構成を変更することは可能です。

チケットの転送の詳細は、「Kerberos チケットの転送」を参照してください。

-F

「再転送可能な」TGT のコピーを遠隔システムに転送します。このオプションは、-f と似ていますが、さらに先のマシン (たとえば 4 つ目や 5 つ目のマシン) へのアクセスを可能とする点が異なります。したがって、-F オプションは -f オプションのスーパーセットであると考えられます。-F オプションと -f オプションは、互いに排他の関係にあります。つまり、これらを同一コマンド内で同時に使用することはできません。

チケットの転送の詳細は、「Kerberos チケットの転送」を参照してください。

-k realm

krb5.conf ファイルを使用してレルム自身を決定する代わりに、特定の realm 内の遠隔ホストのチケットを要求します。

-K

チケットを使用して遠隔ホストへの認証を行いますが、自動ログインは行いません。

-m mechanism

/etc/gss/mech ファイルの記載どおりに、使用する GSS-API セキュリティーメカニズムを指定します。デフォルトは kerberos_v5。

-x

このセッションを暗号化します。

-X auth-type

auth-type タイプの認証を無効にします。

次の表は、コマンド固有のオプションを示します。「X」は、コマンドがそのオプションを持つことを示します。

表 26–1 ネットワークコマンドの Kerberos オプション

 

ftp

rcp

rlogin

rsh

telnet

-a

 

 

 

 

X 

-f

X 

 

X 

X 

X 

-F

 

 

X 

X 

X 

-k

 

X 

X 

X 

X 

-K

 

 

 

 

X 

-m

X 

 

 

 

 

-x

X 

X 

X 

X 

X 

-X

 

 

 

 

X 

さらに、ftp では、ftp のプロンプト対してコマンドを入力することでにセッションの保護レベルを設定できます。

clear

保護レベルを「clear」(保護なし) に設定します。この保護レベルがデフォルトです。

private

保護レベルを「private」に設定します。データ転送は、暗号化により機密性と完全性が保護されます。ただし、この機密サービスは、Kerberos ユーザーによっては利用できない可能性もあります。

safe

保護レベルを「safe」に設定します。データ転送は、暗号チェックサムによって完全性が保護されます。

ftp プロンプトで protect と入力したあとに上記に示した保護レベル (clear、private、または safe) のいずれかを入力して、保護レベルを設定することもできます。

Kerberos チケットの転送

「Kerberos コマンドの概要」で説明したように、一部のコマンドで -f または -F オプションを使用するとチケットを転送できます。チケットを転送すると、ネットワークトランザクションの「チェーン化」が可能となります。たとえば、あるマシンに遠隔ログインして、そこから別のマシンに遠隔ログインできます。-f オプションではチケットを転送することができますが、-F オプションでは転送済みのチケットを再転送することが可能です。

図 26–2 で、ユーザー david は kinit を使用して、転送不可能なチケット認可チケット (TGT) を取得します。-f オプションを指定しなかったため、チケットは転送不可能なチケットです。シナリオ 1 では、マシン B に遠隔ログインできますが、それ以上遠隔ログインできません。シナリオ 2 の rlogin -f コマンドは失敗します。なぜなら、彼は転送不可能なチケットを転送しようとしているからです。

図 26–2 転送不可能なチケットの使用

この図については、前の本文中で説明しています。

実際にはデフォルトで、kinit が転送可能なチケットを取得するように Kerberos 構成ファイルが設定されます。ただし、ユーザーの構成はこれと異なっても構いません。説明するために、TGT が kinit -f で起動されない限り、kinit は転送可能な TGT を取得できないと想定します。kinit には、-F オプションがないことに注意してください。TGT は、転送可能、転送不可能のいずれかです。

図 26–3 で、ユーザー david は、kinit -f を使用して、転送可能な TGT を取得します。シナリオ 3 では、rlogin で転送可能なチケットを使用するため、マシン C に到達できます。シナリオ 4 の 2 回目の rlogin は失敗します。なぜなら、このチケットは再転送可能ではないからです。シナリオ 5 のように -F オプションを代わりに使用すれば、2 回目の rlogin は成功し、チケットがマシン D に再転送されます。

図 26–3 転送可能チケットの使用

この図については、前の本文中で説明しています。

Kerberos コマンドの使用 (例)

次の例は、Kerberos コマンドのオプションの使用方法を示しています。

例 26–5 telnet で -a、-f、および -x オプションを使用する

この例では、ユーザー david はすでにログインしており、マシン denver.example.com に telnet しようとしています。彼は、-f オプションを使って既存のチケットを転送し、-x オプションを使ってセッションを暗号化し、-a オプションを使って自動ログインを実行します。3 つ目のホストのサービスを使用する予定はないため、ここでは -F ではなく -f を使用しています。


% telnet -a -f -x denver.example.com 
Trying 128.0.0.5... 
Connected to denver.example.com. Escape character is '^]'. 
[ Kerberos V5 accepts you as "david@eng.example.com" ] 
[ Kerberos V5 accepted forwarded credentials ] 
SunOS 5.9: Tue May 21 00:31:42 EDT 2004  Welcome to SunOS 
%

david のマシンが、Kerberos を使用して denver.example.com に対する彼の認証を行い、さらに自動ログインしている点に注意してください。彼は、暗号化されたセッションと、いつでも利用可能なチケットのコピーとを手に入れましたが、パスワードを入力する必要は一度もありませんでした。Kerberos 以外のバージョンの telnet を使用している場合、パスワードの入力を要求され、そのパスワードは暗号化されていないネットワーク上で送信されます。その時点で侵入者がネットワークトラフィックを監視していると、侵入者は david のパスワードを知ることになります。

Kerberos チケットを転送した場合、telnet (およびここで説明したその他のコマンド) は、終了時にそのチケットを破棄します。

例 26–6 rlogin で -F オプションを使用する

ここでは、ユーザー jennifer が自身のマシン boston.example.com にログインするものとします。-F オプションを使用して既存のチケットを転送し、-x オプションを使用してセッションを暗号化します。-f ではなく -F を選択します。これは boston にログインしたあとで、再転送されるチケットが必要な別のネットワークトランザクションを実行するためです。また、既存のチケットを転送するので、パスワードを入力する必要はありません。


% rlogin boston.example.com -F -x
This rlogin session is using encryption for all transmissions.
Last login Mon May 19 15:19:49 from daffodil 
SunOS Release 5.9 (GENERIC) #2 Tue Nov 14 18:09:3 EST 2003 
%
例 26–7 ftp で保護レベルを設定する

joe が ftp を使用して、マシン denver.example.com のディレクトリ ~joe/MAIL から自分宛てのメールを取得します。ただし、セッションを暗号化します。やり取りは次のようになります。


% ftp -f denver.example.com
Connected to denver.example.com
220 denver.example.org FTP server (Version 6.0) ready.
334 Using authentication type GSSAPI; ADAT must follow
GSSAPI accepted as authentication type 
GSSAPI authentication succeeded Name (daffodil.example.org:joe) 
232 GSSAPI user joe@MELPOMENE.EXAMPLE.COM is authorized as joe
230 User joe logged in.
Remote system type is UNIX.
Using BINARY mode to transfer files.
ftp> protect private
200 Protection level set to Private
ftp> cd ~joe/MAIL
250 CWD command successful.
ftp> get RMAIL
227 Entering Passive Mode (128,0,0,5,16,49)
150 Opening BINARY mode data connection for RMAIL (158336 bytes).
226 Transfer complete. 158336 bytes received in 1.9 seconds (1.4e+02 Kbytes/s)
ftp> quit
%

セッションを暗号化するために、joe は保護レベルを private に設定しています。

第 27 章 Kerberos サービス (参照)

この章では、Kerberos 製品に組み込まれている多数のファイル、コマンド、およびデーモンを示します。また、Kerberos 認証の機能についても詳細に説明します。

この章の内容は次のとおりです。

Kerberos ファイル

表 27–1 Kerberos ファイル

ファイル名 

説明 

~/.gkadmin

SEAM 管理ツールで新しい主体を作成するときのデフォルト値

~/.k5login

Kerberos アカウントに対してアクセス権を許可する主体のリスト

/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

Kerberos 主体データベース

/var/krb5/principal.kadm5

Kerberos 管理データベース。ポリシー情報を含みます

/var/krb5/principal.kadm5.lock

Kerberos 管理データベースのロックファイル

/var/krb5/principal.ok

Kerberos 主体データベースの初期化ファイル。Kerberos データベースの初期化が正常終了すると作成されます

/var/krb5/principal.ulog

Kerberos 更新ログ。増分伝播の更新を含みます

/var/krb5/slave_datatrans

KDC のバックアップファイルで、kprop_script スクリプトが伝播時に使用します

/var/krb5/slave_datatrans_slave

slave に完全更新が行われるときに作成される一時ダンプファイル

Kerberos コマンド

この節では、Kerberos 製品に含まれているコマンドの一部を示します。

表 27–2 Kerberos コマンド

コマンド 

説明 

/usr/bin/ftp

ファイル転送プロトコルプログラム

/usr/bin/kdestroy

Kerberos チケットを破棄します

/usr/bin/kinit

Kerberos チケット認可チケットを取得し、キャッシュに格納します

/usr/bin/klist

現在の Kerberos チケットを表示します

/usr/bin/kpasswd

Kerberos パスワードを変更します

/usr/bin/ktutil

Kerberos キータブファイルを管理します

/usr/bin/rcp

遠隔ファイルコピープログラム

/usr/bin/rdist

遠隔ファイル配布プログラム

/usr/bin/rlogin

遠隔ログインプログラム

/usr/bin/rsh

遠隔シェルプログラム

/usr/bin/telnet

Kerberos telnet プログラム

/usr/lib/krb5/kprop

Kerberos データベース伝播プログラム

/usr/sbin/gkadmin

Kerberos データベース管理 GUI プログラム。主体とポリシーの管理に使用されます

/usr/sbin/gsscred

gsscred テーブルエントリを管理します

/usr/sbin/kadmin

遠隔 Kerberos データベース管理プログラム (Kerberos 認証とともに実行)。主体、ポリシー、およびキータブファイルの管理に使用されます

/usr/sbin/kadmin.local

ローカル Kerberos データベース管理プログラム (Kerberos 認証なしで動作するが、マスター KDC 上で実行する必要がある)。主体、ポリシー、およびキータブファイルの管理に使用されます

/usr/sbin/kclient

Kerberos クライアントのインストールスクリプト。インストールプロファイルとともに、またはなしで使用されます

/usr/sbin/kdb5_ldap_util

Kerberos データベースの LDAP コンテナを作成します

/usr/sbin/kdb5_util

Kerberos データベースと stash ファイルを作成します

/usr/sbin/kgcmgr

Kerberos のマスター KDC とスレーブ KDC を構成します

/usr/sbin/kproplog

更新ログ内の更新エントリの概要を一覧表示します

Kerberos デーモン

次の表は、Kerberos 製品で使用されるデーモンの一覧です。

表 27–3 Kerberos デーモン

デーモン 

説明 

/usr/sbin/in.ftpd

ファイル転送プロトコルデーモン

/usr/lib/krb5/kadmind

Kerberos データベース管理デーモン

/usr/lib/krb5/kpropd

Kerberos データベース伝播デーモン

/usr/lib/krb5/krb5kdc

Kerberos チケット処理デーモン

/usr/lib/krb5/ktkt_warnd

Kerberos チケットの有効期限切れの警告と自動更新のデーモン

/usr/sbin/in.rlogind

遠隔ログインデーモン

/usr/sbin/in.rshd

遠隔シェルデーモン

/usr/sbin/in.telnetd

telnet デーモン

Kerberos の用語

この節では、Kerberos の用語とその定義について説明します。これらの用語は、Kerberos のマニュアル全体で使用されます。Kerberos の概念を理解するには、これらの用語を理解する必要があります。

Kerberos 固有の用語

KDC を管理するには、この節で説明する用語を理解する必要があります。

「鍵配布センター (Key Distribution Center、KDC)」は、資格の発行を担当する Kerberos の構成要素です。資格は、KDC データベースに格納されている情報に基づいて作成されます。各レルムには 2 つ以上の KDC サーバー (マスターと 1 つ以上のスレーブ) が必要です。すべての KDC が資格を生成できますが、KDC データベースを変更できるのはマスター KDC だけです。

KDC のマスター鍵は stash ファイル に含まれます。サーバーがリブートされると、この鍵を使用して KDC が自動的に認証されて、kadmind と krb5kdc コマンドが起動されます。このファイルにはマスター鍵が入っているため、このファイルやバックアップは安全な場所に保管する必要があります。ファイルは、root の読み取り専用のアクセス権で作成されます。ファイルをセキュリティー保護するには、アクセス権を変更しないでください。ファイルの保護が破られると、この鍵を使用して KDC データベースのアクセスや変更が可能になります。

認証固有の用語

認証処理を理解するには、この節で説明する用語を理解する必要があります。プログラマやシステム管理者はこれらの用語に精通している必要があります。

「クライアント 」は、ユーザーのワークステーションで動作するソフトウェアです。クライアントで動作する Kerberos ソフトウェアは、処理中に多数の要求を作成します。このため、Kerberos ソフトウェアとユーザーの動作を区別することが重要です。

「サーバー」と「サービス」はよく同じ意味で使われます。明確に定義すると、「サーバー」は、Kerberos ソフトウェアが動作する物理システムです。「サービス」とは、サーバー上でサポートされる特定の機能 (ftp や nfs) です。サーバーがサービスの一部として記述されることがよくありますが、これはこれらの用語の定義をあいまいにします。このマニュアルでは、サーバーという用語は、物理システムを指します。サービスという用語は、ソフトウェアを指します。

Kerberos 製品は、2 種類の鍵を使用します。1 つはパスワード由来の鍵です。パスワード由来の鍵は、各ユーザー主体に与えられ、そのユーザーと KDC だけに知られています。Kerberos 製品が使用するもう 1 つの鍵は、パスワードとの関連性がないランダム鍵です。そのため、ユーザー主体による使用には適しません。通常、ランダム鍵は、キータブにエントリがあり、KDC によって作成されるセッション鍵を持つサービス主体で使用されます。サービスは非対話形式での実行を許可するキータブファイル内の鍵にアクセスできるため、サービス主体はランダム鍵を使用できます。セッション鍵は、クライアントとサービス間のトランザクションを保護するために KDC によって生成され、クライアントとサービス間で共有されます。

「チケット」は、ユーザーの識別情報をサーバーやサービスに安全に渡すために使用される情報パケットです。チケットは、単一クライアントと特定サーバー上の特定サービスだけに有効です。チケットには、次のものが含まれます。

これらのすべてのデータは、サーバーのサービス鍵に暗号化されます。KDC は、次に説明する資格に組み込まれたチケットを発行します。チケットは、発行されてから有効期限まで再使用できます。

「 資格」は、チケットとそれに対応するセッション鍵を含む情報パケットです。資格は要求する主体の鍵で暗号化されます。一般的に、KDC はクライアントからのチケット要求に応じて資格を生成します。

「オーセンティケータ (authenticator)」は、クライアントのユーザー主体を認証するためにサーバーが使用する情報です。 オーセンティケータは、ユーザーの主体名、タイムスタンプ、およびその他のデータを含みます。チケットとは異なり、オーセンティケータは一度しか使用できません。通常、サービスへのアクセスが要求されたときに使用されます。オーセンティケータは、クライアントとサーバーが共有するセッション鍵を使用して暗号化されます。通常、クライアントが、オーセンティケータを作成し、サーバーまたはサービスに対して認証するためにサーバーまたはサービスのチケットとともに送信します。

チケットの種類

チケットには、チケットがどのように使用されるかを決めるプロパティーがあります。これらのプロパティーは、チケットの作成時にチケットに割り当てられます。ただし、チケットのプロパティーはあとから変更できます。たとえば、チケットは、転送可能から転送済みに変更できます。チケットのプロパティーを表示するには、klist コマンドを使用します「Kerberos チケットの表示」を参照してください。

チケットは、次の 1 つまたは複数のプロパティーで表されます。

転送可能/転送済み

転送可能チケットはホストからホストに転送されます。これによって、クライアントは再び認証を受ける必要がありません。たとえば、ユーザー david がユーザー jennifer のマシンで転送可能チケットを取得した場合、david は自分のマシンにログインするときに新しいチケットを取得する必要はありません (再び認証を受けることもありません)。転送可能チケットの例については、例 26–1 を参照してください。

初期

初期チケットは、チケット認可チケットを使わずに直接発行されるチケットです。パスワードを変更するアプリケーションなどの一部のサービスでは、クライアントが非公開鍵を知っていることを確認するために、初期と指定されたチケットを要求することができます。初期チケットは、チケット認可チケットを使用せずに、クライアントが最近認証されたことを証明します。チケット認可チケットの場合は、認証されてから時間が経っている可能性があります。

無効

無効チケットは、まだ使用可能になっていない遅延チケットです。無効チケットは、有効になるまでアプリケーションサーバーから拒否されます。これを有効にするには、開始時期が過ぎたあと、チケット認可サービス要求で VALIDATE フラグをオンにしてクライアントがこのチケットを KDC に提示する必要があります。

遅延可能/遅延

遅延チケットは、作成されても指定された時期まで有効にならないチケットです。たとえばこのようなチケットは、夜遅く実行するバッチジョブに使用するのに便利です。チケットが盗まれてもバッチジョブが実行される予定の時刻まで使用できないためです。遅延チケットは、無効チケットとして発行され、開始時刻を過ぎて、クライアントが KDC による検査を要求したときに有効になります。遅延チケットは通常、チケット認可チケットの有効期限まで有効です。ただし、チケットに更新可能が指定されている場合、その最長有効期限は通常、チケット認可チケットの最長有効期限と同じに設定されます。

プロキシ可能/プロキシ

場合によっては、サービスがそれ自身のために操作できることが主体にとって必要な場合があります。チケットを作成するときには、プロキシの主体名を指定する必要があります。Solaris リリースでは、プロキシ可能またはプロキシチケットをサポートしていません。

プロキシ可能チケットは転送チケットに似ていますが、プロキシ可能チケットが 1 つのサービスに対してだけ有効であることに対し、転送可能チケットはサービスに対しクライアントの識別情報の完全な使用を許可します。したがって、転送可能チケットは一種のスーパープロキシと考えられます。

更新可能

チケットに非常に長い有効期限を与えるとセキュリティーを損なうおそれがあるため、チケットを「更新可能」にすることができます。更新可能チケットには 2 つの有効期限があります。 1 つはチケットの現在のインスタンスの有効期限で、もう 1 つは任意のチケットの最長有効期限 (1 週間) です。クライアントがチケットの使用を継続するときは、最初の有効期限が切れる前にチケットの有効期限を更新します。たとえば、すべてのチケットの最長有効期限が 10 時間のときに、あるチケットが 1 時間だけ有効だとします。このチケットを保持するクライアントが 1 時間を超えて使用する場合は、その時間内にチケットの有効期限を更新する必要があります。チケットが最長有効期限 (10 時間) に達すると、チケットの有効期限が自動的に切れ、それ以上更新できなくなります。

チケットの属性を表示する方法については、「Kerberos チケットの表示」を参照してください。

チケットの有効期限

主体がチケットを取得すると、チケット認可チケット (TGT) であっても、チケットの有効期限は次の中で最も小さい値に設定されます。

図 27–1 は、TGT の有効期限の決定方法と 4 つの有効期限値の指定元を示しています。この図は TGT の有効期限がどのようにして決まるかを示しますが、基本的には、どの主体がチケットを取得する場合でも同じです。違いは、kinit で有効期限値を指定しないことと、krbtgt/realm主体の代わりに、チケットを提供するサービス主体が最長有効期限値を提供することだけです。

図 27–1 TGT の有効期限の決定方法

kinit コマンド、ユーザー主体、サイトデフォルト、チケット許可者のいずれかによって与えられる最小値が、チケットの有効期限となります。

更新可能チケットの有効期限も次の 4 つの最小値で決まります。ただし、この場合は更新可能有効期限が使用されます。

Kerberos 主体名

チケットは主体名で識別され、主体名はユーザーやサービスを識別します。次の表に主体名の例を示します。

表 27–4 Kerberos 主体名の例

Principal Name 

説明 

changepw/kdc1.example.com@EXAMPLE.COM

パスワードを変更するときに、KDC にアクセスできるマスター KDC の主体。 

clntconfig/admin@EXAMPLE.COM

kclient インストールユーティリティーで使用される主体。

ftp/boston.example.com@EXAMPLE.COM

ftp サービスによって使用される主体。この主体は host 主体の代わりに使用できます。

host/boston.example.com@EXAMPLE.COM

Kerberos アプリケーション (klist、kprop など) およびサービス (ftp、telnet など) によって使用される主体。この主体は host またはサービス主体と呼ばれます。主体は NFS マウントの認証に使用されます。この主体はまた、クライアントが受け取った TGT が正しい KDC から発行されたものであることを確認するためにも使用されます。

K/M@EXAMPLE.COM

マスター鍵名の主体。各マスター KDC には、1 つのマスター鍵名の主体が関連付けられます。 

kadmin/history@EXAMPLE.COM

この主体に含まれる鍵を使用して、ほかの主体のパスワード履歴が保管されます。各マスター KDC には、これらの主体のいずれかが割り当てられます。 

kadmin/kdc1.example.com@EXAMPLE.COM

kadmind を使用して KDC にアクセスできるマスター KDC サーバーの主体。

kadmin/changepw.example.com@EXAMPLE.COM

Solaris リリースが動作していないクライアントからのパスワード変更要求の受け入れに使用される主体。 

krbtgt/EXAMPLE.COM@EXAMPLE.COM

この主体を使用して、チケット認可チケットを生成します。 

krbtgt/EAST.EXAMPLE.COM@WEST.EXAMPLE.COM

この主体は、レルム間チケット認可チケットの例です。 

nfs/boston.example.com@EXAMPLE.COM

NFS サービスによって使用される主体。この主体は host 主体の代わりに使用できます。

root/boston.example.com@EXAMPLE.COM

クライアントの root アカウントに関連付けられた主体。この主体は、root 主体と呼ばれ、NFS がマウントされたファイルシステムへの root アクセスを提供します。

username@EXAMPLE.COM

ユーザー用の主体。 

username/admin@EXAMPLE.COM

KDC データベースを管理するために使用できる admin 主体。

Kerberos 認証システムの動作方法

アプリケーションを使用して遠隔システムにログインするには、識別情報を証明するチケットとそれに対応するセッション鍵を指定する必要があります。セッション鍵には、ユーザーやアクセスするサービスに特有の情報が含まれています。ユーザーすべてのチケットとセッション鍵は、ユーザーが最初にログインするときに KDC によって作成されます。チケットとそれに対応するセッション鍵が 1 つの資格となります。複数のネットワークサービスを使用する場合には、ユーザーは多数の資格を収集できます。ユーザーは特定のサーバーで動作するサービスごとに 1 つの資格を必要とします。たとえば、boston というサーバー上の ftp サービスにアクセスするには 1 つの資格が必要です。別のサーバー上の ftp サービスにアクセスするには、別の資格が必要です。

資格の作成や格納は透過的に行われます。資格は KDC によって作成され、要求者に送信されます。資格は、受信されると資格キャッシュに格納されます。

Kerberos サービスによる DNS および nsswitch.conf ファイルとの対話処理方法

Kerberos サービスは、ホスト名の解決に DNS を使用するようにコンパイルされています。ホスト名を解決する場合、 nsswitch.conf ファイルへの参照は一切行われません。

Kerberos によるサービスへのアクセス

特定のサーバー上の特定のサービスにアクセスする場合、ユーザーは 2 つの資格を取得する必要があります。最初は TGT として知られるチケット認可チケットに対する資格です。チケット認可サービスは、この資格の暗号を解除すると、ユーザーからアクセスを要求されているサーバーの資格をさらに作成します。ユーザーは、この 2 つめの資格を使用してサーバー上のサービスへのアクセスを要求します。サーバーがこの資格の暗号を解除すると、ユーザーはアクセスを許可されます。次の節では、このプロセスを詳細に説明します。

チケット認可サービスに対する資格の取得

  1. 認証処理を開始するために、クライアントが特定のユーザー主体の要求を認証サーバーに送信します。この要求の送信では暗号は使用されません。要求にはセキュリティーにかかわる情報が含まれていないため、暗号を使う必要はありません。

  2. 認証サービスは要求を受信すると、ユーザーの主体名を KDC データベースから検索します。主体がデータベースのエントリに一致すると、認証サービスはその主体の非公開鍵を取得します。次に認証サービスは、クライアントとチケット認可サービスが使用するセッション鍵 (セッション鍵 1) とチケット認可サービス用のチケット (チケット 1) を生成します。このチケットを「チケット認可チケット (TGT)」ともいいます。セッション鍵とチケットはユーザーの非公開鍵を使って暗号化され、情報がクライアントに返送されます。

  3. クライアントは、ユーザー主体の非公開鍵を使用して、この情報からセッション鍵 1 とチケット 1 の暗号を解除します。非公開鍵を知っているのはユーザーと KDC データベースだけである必要があるため、パケットの情報は安全に保たれなければなりません。クライアントはこの情報を資格キャッシュに格納します。

この処理中に、ユーザーは通常、パスワードを要求されます。非公開鍵を作成するために使用された、KDC データベースに格納されているパスワードが、ユーザーが指定したパスワードと同じであると、認証サービスから送信された情報は正しく復号化されます。これでクライアントは、チケット認可サービスに対して使用する資格を取得します。次にクライアントはサーバーに対する資格を要求します。

図 27–2 チケット認可サービスに対する資格の取得

クライアントは、サーバーへアクセスする資格を KDC に要求し、受け取った資格をパスワードで復号化します。

サーバーに対する資格の取得

  1. 特定のサーバーにアクセスするには、クライアントがその前にサーバーに対する資格を認証サービスから取得している必要があります。「チケット認可サービスに対する資格の取得」を参照してください。次にクライアントは、チケット認可サービスに要求を送信します。この要求には、サービス主体名、チケット 1 およびセッション鍵 1 で暗号化されたオーセンティケータが含まれています。チケット 1 は、チケット認可サービスのサービス鍵を使用して認証サービスによって暗号化されたものです。

  2. チケット認可サービスはチケット認可サービスのサービス鍵を知っているため、チケット 1 の暗号を解除できます。チケット 1 の情報にはセッション鍵 1 が含まれているため、チケット認可サービスはオーセンティケータの暗号を解除できます。この時点で、ユーザー主体はチケット認可サービスによって認証されます。

  3. 認証が正常に終了すると、チケット認可サービスは、ユーザー主体とサーバーに対するセッション鍵 (セッション鍵 2) とサーバーに対するチケット (チケット 2) を生成します。次にセッション鍵 2 とチケット 2 はセッション鍵 1 を使って暗号化されます。セッション鍵 1 を知っているのはクライアントとチケット認可サービスだけであるため、この情報は安全であり、ネットワークを介して安全に送信されます。

  4. クライアントはこの情報パケットを受信すると、前に資格キャッシュに格納したセッション鍵 1 を使用して情報を復号化します。クライアントは、サーバーに対して使用する資格を取得したことになります。次にクライアントは、そのサーバーの特定のサービスにアクセスする要求を行います。

図 27–3 サーバーに対する資格の取得

クライアントは、まずセッション鍵 1 で暗号化した要求を KDC に送信し、次に受け取った資格を同じセッション鍵で復号化します。

特定のサービスへのアクセス権の取得

  1. クライアントが特定のサービスへのアクセスを要求するには、まず認証サーバーからチケット認可サービスに対する資格を取得し、チケット認可サービスからサーバー資格を取得する必要があります。「チケット認可サービスに対する資格の取得」および 「サーバーに対する資格の取得」を参照してください。次に、クライアントは、チケット 2 と別のオーセンティケータを含む要求をサーバーに送信します。オーセンティケータはセッション鍵 2 を使用して暗号化されます。

  2. チケット 2 は、サービスのサービス鍵を使用してチケット認可サービスによって暗号化されています。サービス鍵はサービス主体が知っているため、サービスはチケット 2 を復号化し、セッション鍵 2 を取得できます。次に、セッション鍵 2 を使用してオーセンティケータが復号化されます。オーセンティケータが正しく復号化されると、サービスへのアクセスがクライアントに許可されます。

図 27–4 特定のサービスへのアクセス権の取得

クライアントは、チケット 2 と、セッション鍵 2 で暗号化されたオーセンティケータとを使用して、サーバーへのアクセス権を取得します。

Kerberos 暗号化タイプの使用

暗号化タイプは、暗号処理が実行されるときに使用する暗号アルゴリズムとモードを特定します。aes、des3-cbc-sha1、および rc4–hmac 暗号化タイプによって、より強固な暗号処理のために使用される鍵を作成できます。これらの強固な操作により、Kerberos サービスのセキュリティー全体が向上します。

注 –

Solaris 10 8/07 より前のリリースでは、別売の Strong Cryptographic パッケージがインストールされている場合は、Kerberos サービスで aes256-cts-hmac-sha1-96 暗号化タイプを使用できます。

クライアントが KDC にチケットを要求する場合、KDC はクライアントとサーバーで互換性のある暗号化タイプの鍵を使用する必要があります。Kerberos プロトコルでは、KDC がチケット応答のクライアント部分に対して特定の暗号化タイプを使用するようクライアントが要求することができます。しかし、サーバーが KDC に対して暗号化タイプを指定することはできません。

注 –

Solaris 10 が動作していないマスター KDC がインストールされている場合は、マスター KDC をアップグレードする前に、スレーブ KDC を Solaris 10 にアップグレードする必要があります。Solaris 10 のマスター KDC では、古いスレーブが処理できない新しい暗号化タイプが使用されます。

次に、暗号化タイプを変更する前に考慮する必要があるいくつかの問題を説明します。

gsscred テーブルの使用

デフォルトのマッピングでは十分でないとき、NFS サーバーは gsscred テーブルを使用して、Kerberos ユーザーを識別します。NFS サービスは、UNIX ID を使用してユーザーを識別します。UNIX ID は、ユーザー主体または資格には含まれません。gsscred テーブルは、パスワードファイルから得られる GSS 資格を UNIX ID に追加してマッピングするテーブルです。このテーブルは、KDC データベースを生成したあとに作成および開始する必要があります。詳細は、 「GSS 資格の UNIX 資格へのマッピング」を参照してください。

クライアントの要求が到着すると、NFS サービスは主体名を UNIX ID にマッピングしようとします。このマッピングに失敗した場合、gsscred テーブルが確認されます。

Solaris Kerberos と MIT Kerberos の大きな違い

Solaris 10 バージョンの Kerberos サービスは MIT Kerberos version 1.2.1 に基づいています。次に、Solaris 10 リリースに含まれ、MIT 1.2.1 バージョンには含まれない拡張機能を示します。

このバージョンには MIT 1.2.1 以後のバグ修正もいくつか含まれています。特に、1.2.5 btree のバグ修正および 1.3 TCP サポートが追加されました。