このパートでは、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 サービスが意識されることはほとんどありません。rsh や ftp などのコマンドは、ほぼ変わりなく動作します。Kerberos セッションの初期化には通常、ログインと Kerberos パスワードの入力しか必要ありません。
Kerberos システムは、「チケット」の概念を中心に動作します。チケットは、ユーザー、および NFS サービスなどのサービスを特定する一連の電子情報です。運転免許証が運転する人と免許の種類を表すのと同じように、チケットもユーザーとユーザーのネットワークアクセス権を表します。Kerberos に基づくトランザクションを実行する (ほかのマシンへの遠隔ログインなど) と、「鍵配布センター (KDC)」に対してチケットの要求が透過的に送信されます。KDC はデータベースにアクセスしてそのユーザーを認証し、そのマシンへのアクセスを許可するチケットを返します。「透過的」とは、チケットを明示的に要求する必要がないという意味です。この要求は rlogin コマンドの中で行われます。特定のサービスのチケットを取得できるのは認証されたクライアントだけで、別のクライアントが識別情報を仮定して rlogin を使用することはできません。
チケットには一定の属性が与えられています。たとえば、チケットには、新しい認証処理を行わなくても別のマシンで使用できる「転送可能」の属性があります。また、指定の日付まで有効にならない「遅延」の属性もあります。どのユーザーがどの種類のチケットを取得できるかを指定するなど、チケットをどのように使用するかは、「ポリシー」によって設定されます。ポリシーは、Kerberos サービスのインストールや管理の際に決定します。
「資格」と「チケット」という用語は、頻繁に使用されます。広い意味の Kerberos では、これらの用語は同じ意味で使われることがありますが、技術的には資格は、チケットとそのセッションに対する「セッション鍵」からなります。この違いについては、 「Kerberos によるサービスへのアクセス」で詳しく説明します。
次の節では、Kerberos 認証プロセスについて詳細に説明します。
Kerberos 認証には、後続の認証を準備する初期認証と、後続の認証の 2 つのフェーズが あります。
次の図では、初期認証の手順を示します。
クライアント (ユーザー、または NFS などのサービス) は、KDC に TGT を要求して Kerberos セッションを開始します。ほとんどの場合、この要求はログイン時に自動的に実行されます。
TGT は、ほかの特定のサービスのチケットを取得するために必要です。TGT は、パスポートに似ています。パスポートと同様に、TGT はユーザーを識別して、さまざまなビザの取得をユーザーに許可します。ここでいうビザ (チケット) は、外国に入国するためのものではなく、遠隔マシンやネットワークサービスにアクセスするためのものです。パスポートやビザと同様に、TGT などのチケットには有効期限があります。ただし、Kerberos コマンドは、ユーザーがパスポートを所有していることを通知し、ユーザーに代わってビザを取得します。ユーザー自身がトランザクションを実行する必要はありません。
チケット認可チケットに類似した例として、4 つのスキー場で使える 3 日間のスキーパスを挙げます。ユーザーは、パスが期限切れになるまで、このパスを任意のスキー場で提示して、そのスキー場のリフトチケットを受け取ります。リフトチケットを入手したら、そのスキー場で好きなだけスキーをすることができます。翌日別のスキー場に行った場合は、またパスを提示して、そのスキー場のリフトチケットを入手します。ただし、Kerberos に基づくコマンドは、ユーザーが週末スキーパスを所有していることをユーザーに通知し、ユーザーに代わってリフトチケットを入手します。したがって、ユーザー自身がトランザクションを実行する必要はありません。
KDC は TGT を作成し、それを暗号化してクライアントに送信します。クライアントは、自身のパスワードを使用して TGT を復号化します。
クライアントは、有効な TGT を入手したので、TGT が期限切れになるまで、rlogin、telnet などあらゆる種類のネットワーク操作チケットを要求できます。この TGT の有効期限は通常、数時間です。クライアントは一意のネットワーク操作を実行するたびに、TGT は KDC にその操作のチケットを要求します。
クライアントが初期認証を受け取ると、後続の認証はそれぞれ次の図のように実行されます。
クライアントは、別のマシンに遠隔ログインするなど、特定のサービスのチケットを KDC に要求するために、識別情報の証拠として自身の TGT を KDC に送信します。
KDC は、そのサービスのチケットをクライアントに送信します。
たとえば、ユーザー joe が、krb5 認証を要する共有を行っている NFS ファイルシステムにアクセスするとします。このユーザーはすでに認証されている (すでに TGT を持っている) ため、そのファイルにアクセスを試みると、NFS クライアントシステムは NFS サービスのチケットを KDC から自動的および透過的に取得します。
たとえば、ユーザー joe がサーバー boston 上で rlogin を使用するとします。このユーザーはすでに認証されている (つまり、すでにチケット認可チケットを持っている) ため、rlogin コマンドの一部として自動的かつ透過的にチケットを取得します。このチケットが期限切れになるまで、このユーザーは必要に応じて boston に遠隔ログインできます。joe がマシン denver に遠隔ログインする場合は、手順 1 の方法で別のチケットを取得します。
クライアントはサーバーにチケットを送信します。
NFS サービスを使用している場合、NFS クライアントは自動的および透過的に NFS サービスのチケットを NFS サーバーに送信します。
サーバーはクライアントにアクセス権を許可します。
これらの手順では、サーバーと KDC 間の通信は発生していないように見えます。しかし、サーバーは KDC と通信していて、最初のクライアントと同様に、KDC に自身を登録しています。わかりやすくするために、その部分は省略しています。
joe などのユーザーは、次の Kerberos に基づく (Kerberos 化された) コマンドを使用できます。
ftp
rcp
rdist
rlogin
rsh
ssh
telnet
これらのアプリケーションは、同じ名前の Solaris アプリケーションと同じです。ただし、トランザクションを認証するときに Kerberos 主体を使用できるようにアプリケーションを拡張することにより、Kerberos に基づくセキュリティーを提供します。主体の詳細については、「Kerberos 主体」を参照してください。
これらのコマンドについては、「Kerberos ユーザーコマンド」で詳しく説明します。
Kerberos サービス内のクライアントは、その「主体 (プリンシパル)」で識別されます。主体は、KDC がチケットを割り当てることができる一意の ID です。主体には、joe などのユーザー、または nfs、telnet などのサービスがあります。
主体名は慣習により「一次」、「インスタンス」、「レルム」という 3 つの部分から なります。joe/admin@ENG.EXAMPLE.COM は一般的な Kerberos 主体の例です。上記の例では、
joe が一次です。一次には、この例のようなユーザー名や nfs などのサービスを指定します。また、host を指定することもできます。host を指定すると、ftp、rcp、rlogin などのさまざまなネットワークサービスを提供する、サービス主体として設定されます。
admin はインスタンスです。インスタンスは、ユーザー主体の場合はオプションですが、サービス主体では必須です。たとえば、ユーザー joe が必要に応じてシステム管理者の権限を使用する場合は、joe/admin と通常のユーザー ID を使い分けることができます。同じように、joe が 2 つのホストにアカウントを持っている場合、joe/denver.example.com と joe/boston.example.com など、異なるインスタンスで 2 つの主体名を使用することができます。Kerberos サービスでは、joe と joe/admin はまったく別の主体として扱われます。
サービス主体では、インスタンスは完全指定されたホスト名です。bigmachine.eng.example.com はこのようなインスタンスの例です。この例の一次とインスタンスは、ftp/bigmachine.eng.example.com や host/bigmachine.eng.example.com と表します。
ENG.EXAMPLE.COM は Kerberos レルムです。レルムについては、「Kerberos レルム」を参照してください。
次に有効な主体名を示します。
joe
joe/admin
joe/admin@ENG.EXAMPLE.COM
nfs/host.eng.example.com@ENG.EXAMPLE.COM
host/eng.example.com@ENG.EXAMPLE.COM
「レルム」とはドメインのようなもので、同じ「マスター KDC」の下にあるシステムをグループとして定義する論理ネットワークです。図 21–3 では、レルム間の関係を示します。階層構造のレルムでは、1 つのレルムがほかのレルムの上位集合になります。階層ではない (直接接続の) レルムでは、2 つのレルム間のマッピングを定義する必要があります。Kerberos サービスでは、レルム間で共通の認証が可能です。その場合、各レルムの KDC に、他のレルムの主体エントリだけが必要になります。Kerberos のこの機能は、「レルム間認証」と呼ばれます。
各レルムには、主体データベースのマスターコピーを保守するサーバーが含まれる必要があります。このサーバーを「マスター KDC サーバー」と呼びます。また各レルムには、主体データベースの重複コピーを保持する「スレーブ KDC サーバー」が少なくとも 1 つ必要です。マスター KDC サーバーおよびスレーブ KDC サーバーは、認証の確立に使用されるチケットを作成します。
レルムにはまた、Kerberos アプリケーションサーバー も含めることができます。このサーバーは、Kerberos サービス (ftp、telnet、rsh、NFS など) へのアクセスを提供します。SEAM 1.0 または 1.0.1 がインストールされている場合、レルムに Kerberos ネットワークアプリケーションサーバーが含まれている可能性がありますが、このソフトウェアはこれらのリリースには含まれていませんでした。
Kerberos サービスは、ユーザーの認証を行うほかに、次の 2 つのセキュリティーサービスを提供します。
「整合性」 – 認証が、あるネットワーク上のクライアントが本人であるかどうかを確認するのと同様に、整合性は、クライアントの送信データが有効で、伝送の間に改ざんされていないことを確認します。整合性の確認は、データの暗号チェックサムによって行われます。整合性にはユーザー認証も含まれます。
「プライバシ」 – プライバシによって、セキュリティーがさらに向上します。プライバシは、伝送データの整合性を検証するだけでなく、伝送前にデータを暗号化して盗聴を防ぎます。プライバシにもユーザー認証が含まれます。
開発者は、RPCSEC_GSS プログラミングインタフェースを使用することにより、セキュリティーサービスを選択可能な RPC ベースのアプリケーションを設計できます。
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 サービスの完全リリース |
MIT から提供される Kerberos V5 製品と同様に、Solaris Kerberos サービスには次の構成要素が含まれます。
鍵配布センター (KDC):
Kerberos データベース管理デーモン – kadmind。
Kerberos チケット処理デーモン – krb5kdc。
データベース管理プログラム – kadmin (マスターのみ)、kadmin.local、および kdb5_util。
データベース伝播ソフトウェア – kprop (スレーブのみ) および kpropd。
資格を管理するためのユーザープログラム – kinit、klist、および kdestroy。
Kerberos パスワードを変更するユーザープログラム – kpasswd。
遠隔アプリケーション – ftp、 rcp、 rdist、 rlogin、rsh、 ssh、および telnet。
遠隔アプリケーションデーモン – ftpd、rlogind、rshd、sshd、および telnetd。
キータブ管理ユーティリティー – ktutil。
Generic Security Service Application Programming Interface (GSS-API) – アプリケーションは、この API を利用して、複数のセキュリティーメカニズムを使用できます。新しいメカニズムを追加するたびに、アプリケーションをコンパイルし直す必要がありません。GSS-API では、アプリケーションを多くのオペレーティングシステムに移植可能にできる標準インタフェースが使用されています。GSS-API を使用すると、認証サービスだけでなく、整合性およびプライバシセキュリティーサービスをアプリケーションに組み込むことができます。ftp と ssh は、どちらも GSS-API を使用しています。
RPCSEC_GSS Application Programming Interface (API) – NFS サービスが Kerberos 認証を使用することができます。RPCSEC_GSS は、使用しているメカニズムに依存しないセキュリティーサービスを提供するセキュリティー様式です。RPCSEC_GSS は、GSS-API 層の最上位に位置しています。GSS_API ベースのセキュリティーメカニズムは、プラグイン可能なので、RPCSEC_GSS を使用するアプリケーションで使用できます。
さらに、Solaris Kerberos サービスには次の構成要素が含まれています。
Kerberos グラフィカル管理ツール (gkadmin) – 主体および主体ポリシーを管理することができます。この Java テクノロジベースの GUI は、kadmin コマンドに代わる機能です。
PAM 用の Kerberos V5 サービスモジュール – Kerberos サービスのための認証、アカウント管理、セッション管理、およびパスワード管理を提供します。このモジュールを使用すると、Kerberos 認証をユーザーが意識しなくても済むようになります。
カーネルモジュール – NFS サービスで使用する kerberos サービスのカーネルベースの実装を提供します。これにより、パフォーマンスが大幅に向上します。
Solaris 10 5/08 リリースから、次のような拡張機能が使用できます。
Solaris Kerberos ソフトウェアが MIT 1.4 バージョンと同期化されました。具体的には、KDC のソフトウェアである kinit コマンドと Kerberos メカニズムが更新されました。
ディレクトリサーバーから LDAP を使用して Kerberos 主体とポリシーのレコードにアクセスする機能のサポートが追加されました。この変更により管理が簡略化されるため、KDC と DS の配備によっては可用性が向上する場合があります。LDAP 関連の手順の一覧については、「LDAP ディレクトリサーバーでの KDC の管理」を参照してください。
このリリースには、追加の設定が不要な Solaris クライアントのサポートが追加されました。Kerberos サービスと一部のデフォルト設定が変更されました。適切に構成された環境では、Solaris 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 リリースから、ktkt_warnd デーモンは、資格の有効期限が近づいてきたとき、ユーザーに警告するだけでなく、資格を自動的に更新するようになりました。資格を自動的に更新するには、ユーザーがログインしている必要があります。
Solaris 10 リリースに含まれる Kerberos の機能拡張は、次のとおりです。そのうちのいくつかは、以前の Software Express リリースで採用され、Solaris 10 Beta リリースで更新されたものです。
Kerberos プロトコルを、ftp、rcp、rdist、rlogin、rsh、ssh、および telnet などの遠隔アプリケーションでサポートします。詳細は、各コマンドまたはデーモンのマニュアルページおよび krb5_auth_rules(5) のマニュアルページを参照してください。
Kerberos 主体データベースが、毎回データベース全体を転送するのではなく、増分更新によって転送されます。増分更新には、次のような利点があります。
サーバー間でのデータベースの整合性が増す
必要なリソース (ネットワーク、CPU など) が少なくてすむ
更新をよりタイムリーに伝播させることができる
伝播を自動化することができる
Kerberos クライアントの自動構成に役立つ新しいスクリプトが使用できます。このスクリプトは、管理者が Kerberos クライアントを迅速かつ容易に設定するのを支援します。新しいスクリプトの使用手順については、「Kerberos クライアントの構成」を参照してください。また、詳細については kclient(1M) のマニュアルページを参照してください。
いくつかの新しい暗号化タイプが Kerberos サービスに追加されました。これらの新しい暗号化タイプによって、セキュリティーが向上し、それらの暗号化タイプをサポートするほかの Kerberos 実装との互換性が強化されます。詳細は、「Kerberos 暗号化タイプの使用」を参照してください。追加された暗号化タイプは次のとおりです。
AES 暗号化タイプは、Kerberos セッションの高速かつ高セキュリティーの暗号化に使用されます。
ARCFOUR-HMAC は、ほかの Kerberos 実装との互換性を強化します。
SHA1 での Triple DES (3DES) は、セキュリティーを向上させます。この暗号化タイプにより、この暗号化タイプをサポートする他の Kerberos 実装との相互運用性の強化も図れます。
暗号化タイプは、暗号化フレームワークを介して有効になります。このフレームワークは、Kerberos サービスにハードウェアによって高速化された暗号化を提供できます。
KDC ソフトウェア、ユーザーコマンド、およびユーザーアプリケーションが、TCP ネットワークプロトコルの使用をサポートします。これにより、動作が堅牢になり、Microsoft の Active Directory など、ほかの Kerberos 実装と相互運用性が強化されます。KDC は、従来の UDP ポートと TCP ポートの両方で待機し、どちらのプロトコルを使用する要求にも応答できます。ユーザーコマンドとユーザーアプリケーションは、要求が KDC に送られると、まず UDP を試し、失敗した場合は TCP を試します。
kinit コマンド、klist コマンド、および kprop コマンドなど、KDC ソフトウェアで IPv6 がサポートされます。IPv6 アドレスがデフォルトでサポートされます。IPv6 のサポートを有効にするために変更する構成パラメータはありません。IPv6 は、kadmin コマンドおよび kadmind コマンドではサポートされません。
新しい -e オプションが kadmin コマンドのいくつかのサブコマンドに含まれました。この新しいオプションにより、主体の作成中に暗号化タイプを選択できます。詳細は、kadmin(1M) のマニュアルページを参照してください。
pam_krb5 モジュールに、PAM フレームワークを使って Kerberos 資格キャッシュを管理する機能が追加されました。詳細は、pam_krb5(5) のマニュアルページを参照してください。
DNS 検索を使用することにより、Kerberos KDC、admin サーバー、kpasswd サーバー、およびホスト名またはドメイン名のレルムへのマッピングの自動検出がサポートされます。この拡張機能により、Kerberos クライアントのインストールに必要な手順のいくつかが必要なくなります。Kerberos クライアントは、構成ファイルを読み取る代わりに DNS を使用して、KDC サーバーを検出することができます。詳細は、krb5.conf(4) のマニュアルページを参照してください。
pam_krb5_migrate と呼ばれる新しい PAM モジュールが追加されました。この新しいモジュールは、ユーザーが Kerberos アカウントを持たない場合にローカルの Kerberos レルムに自動的に移行するのを支援します。詳細は、pam_krb5_migrate(5) のマニュアルページを参照してください。
~/.k5login ファイルが GSS アプリケーションの ftp および ssh で使用できます。詳細は、gss_auth_rules(5) のマニュアルページを参照してください。
kproplog ユーティリティーが更新され、ログエントリごとにすべての属性名を出力できます。詳細は、kproplog(1M) のマニュアルページを参照してください。
krb5.conf ファイルの構成オプションを使用して、厳格な TGT 検証機能を無効にできるようになりました。詳細は、krb5.conf(4) のマニュアルページを参照してください。
パスワード変更ユーティリティーが拡張され、Solaris Kerberos V5 管理サーバーが、Solaris ソフトウェアを実行していないクライアントからのパスワード変更要求を受け付けることができます。詳細は、kadmind(1M) のマニュアルページを参照してください。
再実行キャッシュのデフォルトの場所が、RAM ベースのファイルシステムから /var/krb5/rcache/ の持続的記憶領域に移動しました。新しい場所では、システムがリブートされた場合に再実行から保護されます。rcache コードに対してパフォーマンスが強化されました。ただし、固定域の使用によって、再実行キャッシュ全体のパフォーマンスは落ちる場合があります。
再実行キャッシュをファイルまたはメモリのみの記憶域を使用するように構成することができます。鍵テーブルおよび資格キャッシュの種類または場所に対して構成可能な環境変数の詳細については、krb5envvar(5) のマニュアルページを参照してください。
GSS 資格テーブルが Kerberos の GSS メカニズムで必要ではなくなりました。詳細は、「GSS 資格の UNIX 資格へのマッピング」、または gsscred(1M)、gssd(1M)、および gsscred.conf(4) のマニュアルページを参照してください。
Kerberos ユーティリティーの kinit と ktutil が、MIT Kerberos バージョン 1.2.1 に準拠するようになりました。この変更により、kinit コマンドに新しいオプションが追加され、ktutil コマンドに新しいサブコマンドが追加されました。詳細は、kinit(1) および ktutil(1) のマニュアルページを参照してください。
Solaris の Kerberos 鍵配布センター (KDC) および kadmind が、MIT の Kerberos バージョン 1.2.1 ベースに基づいて変更されました。KDC では、現在のハッシュベースのデータベースよりも高い信頼性を備えた二分木ベースのデータベースがデフォルトで使用されます。詳細は、kdb5_util(1M) のマニュアルページを参照してください。
kpropd、kadmind、krb5kdc および ktkt_warnd デーモンがサービス管理機能によって管理されます。このサービスに関する有効化、無効化、再起動などの管理アクションは svcadm コマンドを使用して実行できます。すべてのデーモンのサービスの状態は、svcs コマンドを使用して照会することができます。サービス管理機能の概要については、『Solaris のシステム管理 (基本編)』の第 18 章「サービスの管理 (概要)」を参照してください。
Solaris 9 には、遠隔アプリケーションを除いて、「Kerberos の構成要素」の構成要素がすべて含まれています。
SEAM 1.0.2 には、遠隔アプリケーションが含まれています。SEAM 1.0 の構成要素のうちで、Solaris 9 リリースに組み込まれていないのはこれらのアプリケーションだけです。遠隔アプリケーションの構成要素は次のとおりです。
クライアントアプリケーション – ftp、rcp、 rlogin、rsh、および telnet
サーバーデーモン – ftpd、 rlogind、rshd、および telnetd
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 には、次の構成要素が含まれます。
チケットを取得、表示、破棄するユーザープログラム – kinit、klist、および kdestroy。
Kerberos パスワードを変更するユーザープログラム – kpasswd。
鍵テーブル管理ユーティリティー – ktutil。
PAM の拡張 – アプリケーションはさまざまな認証メカニズムを使用できます。PAM を使用すると、ログインとログアウトをユーザーが意識する必要をなくすことができます。
GSS_API プラグイン – Kerberos プロトコルおよび暗号サポートを提供します。
NFS クライアントおよびサーバーのサポート。
SEAM 1.0.1 には、Solaris 8 に含まれていない SEAM 1.0 の構成要素がすべて含まれています。次の構成要素が含まれています。
鍵配布センター (KDC) (マスター):
Kerberos データベース管理デーモン – kadmind
Kerberos チケット処理デーモン – krb5kdc
スレーブ KDC。
データベース管理プログラム – kadmin、kadmin.local。
データベース伝播ソフトウェア – kprop。
遠隔アプリケーション – ftp、rcp、rlogin、rsh、および telnet。
遠隔アプリケーションデーモン – ftpd、rlogind、rshd、および telnetd。
管理ユーティリティー – kdb5_util。
Kerberos グラフィカル管理ツール (gkadmin) – 主体および主体ポリシーを管理することができます。この Java テクノロジベースの GUI は、kadmin コマンドに代わる機能です。
事前構成手順 – SEAM 1.0.1 のインストールおよび構成のパラメータを設定することによって、SEAM インストールを自動化できます。この手順は、特に複数のインストールを行うときに適しています。
いくつかのライブラリ。
SEAM 1.0 リリースには、「Kerberos の構成要素」のすべての項目のほか、次の項目が含まれています。
ユーティリティー (gsscred) とデーモン (gssd) – これらのプログラムは、UNIX のユーザー ID (UID) と主体名のマッピングに役立ちます。これらのプログラムが必要なのは、NFS サーバーがユーザーを識別するときに、主体名ではなく UNIX UID を使用しており、主体名と UNIX UID は形式が異なっているためです。
Generic Security Service Application Programming Interface (GSS-API) – アプリケーションは、この API を利用して、複数のセキュリティーメカニズムを使用できます。新しいメカニズムを追加するたびに、アプリケーションをコンパイルし直す必要がありません。GSS-API はマシンに依存しないため、インターネット上のアプリケーションに適しています。GSS-API を使用すると、認証サービスだけでなく、整合性およびプライバシセキュリティーサービスをアプリケーションに組み込むことができます。
RPCSEC_GSS Application Programming Interface (API) – NFS サービスが Kerberos 認証を使用することができます。RPCSEC_GSS は、使用しているメカニズムに依存しないセキュリティーサービスを提供するセキュリティー様式です。RPCSEC_GSS は、GSS-API 層の最上位に位置しています。GSS_API ベースのセキュリティーメカニズムは、プラグイン可能なので、RPCSEC_GSS を使用するアプリケーションで使用できます。
事前構成手順 – SEAM 1.0 のインストールおよび構成のパラメータを設定することによって、インストールを自動化できます。この手順は、特に複数のインストールを行うときに適しています。
この章は、Kerberos サービスのインストールと保守を行うシステム管理者を対象としています。この章では、Kerberos サービスをインストールまたは構成する前に、システム管理者が解決しておく必要があるインストールと構成の項目について説明します。
システム管理者やテクニカルサポート担当者が検討する必要がある項目は次のとおりです。
Kerberos サービスをインストールする前に、いくつかの構成についての問題を解決する必要があります。初期インストール後に構成を変更することは不可能ではありませんが、変更によっては実装が困難な場合があります。また、変更によっては、KDCを再構築しなければならないことがあります。このため、Kerberos の構成を計画するときは、長期的な目標を考慮することをお勧めします。
Kerberos の基盤の配備には、KDC のインストール、ホストの鍵の作成、ユーザーの移行などの作業が含まれます。Kerberos の配備の再構成は最初の配備と同じくらいの労力を要するので、入念に計画し、再構成しなければならない事態を避けるようにしてください。
レルム は、ドメインに似た論理ネットワークです。レルムは、同一マスター KDC に登録されるシステムのグループを定義します。DNS ドメイン名を設定する場合と同様に、レルム名、レルムの数、および各レルムの大きさは、Kerberos サービスを構成する前に解決する必要があります。また、レルム間認証を行う場合は、レルム間の関係も定義する必要があります。
レルム名には、任意の ASCII 文字列を使用できます。レルム名には通常、DNS ドメイン名と同じ名前を指定します。違いはレルム名は大文字で指定することです。この命名規則を利用すると、すでに使い慣れている名前を使用しながら、Kerberos サービスのレルム名と DNS 名前空間のドメイン名を区別することができます。DNS を使用しない場合、または別の文字列を使用する場合は、任意の文字列を使用できます。ただし、構成プロセスがより複雑になります。レルム名を付けるときは、標準のインターネット命名構造に準拠することをお勧めします。
インストールするレルムの数は、次の要因によって異なります。
サポートするクライアント数。1 つのレルムに配置するクライアントが多すぎると、管理が複雑になり、レルムの分割が必要になることがあります。サポートできるクライアント数は、主に次の要因によって決まります。
各クライアントが生成する Kerberos トラフィックの量
物理ネットワークの帯域幅
ホストの処理速度
インストールごとに制限が違ってくるため、最大クライアント数を決定する規則はありません。
クライアント間の距離。クライアントが地理的に異なる領域に配置されている場合は、小さなレルムをいくつか設定することが望ましい方法です。
KDC としてインストールできるホスト数。各レルムには、マスターサーバー用とスレーブサーバー用に、2 つ以上の KDC サーバーを持つべきです。
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 クライアントサービスを有効にする必要があります。
デフォルトでは、ポート 88 とポート 750 を KDC が使用し、ポート 749 を KDC 管理デーモンが使用します。別のポート番号を使用することもできます。ただし、ポート番号を変更する場合は、各クライアントの /etc/services および /etc/krb5/krb5.conf ファイルを変更する必要があります。また、これらのファイルに加えて、各 KDC の /etc/krb5/kdc.conf ファイルも更新する必要があります。
スレーブ KDC は、マスター KDC と同様に、クライアントの資格を生成します。マスターが使用できなくなると、スレーブ KDC がバックアップとして使用されます。各レルムには、1 つ以上のスレーブ KDC が必要です。次の要因により、スレーブ KDC を追加する必要がある場合が考えられます。
レルム内の物理セグメント数。通常は、レルム内のほかのセグメントが動作しない場合でも、少なくとも各セグメントで機能するように、ネットワークを設定する必要があります。この設定を実現するには、KDC をすべてのセグメントからアクセス可能にする必要があります。この場合、KDC はマスターまたはスレーブのどちらでも構いません。
レルム内のクライアント数。スレーブ KDC サーバーを追加すると、現在のサーバーの負荷を軽減することができます。
スレーブ KDC の数に制限はありません。ただし、KDC データベースは、各サーバーに伝播する必要があります。このため、インストールした KDC サーバーが多くなるにつれて、レルム全体のデータ更新時間が長くなります。また、各スレーブには KDC データベースのコピーが保存されるため、スレーブが多くなるほど、セキュリティー侵害の危険性が高くなります。
1 つまたは複数のスレーブ KDC をマスター KDC と入れ替えするように構成することができます。このように 1 つ以上のスレーブ KDC をシステムに事前に構成しておくと、マスター KDC になんらかの理由で障害が発生した場合でも、マスター KDC と簡単に入れ替えすることができます。スワップ可能なスレーブ KDC の構成方法については、「マスター KDC とスレーブ KDC の入れ替え」を参照してください。
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 資格テーブルにデータを入れておく必要がありました。デフォルトマッピングでは十分でない場合、たとえばインスタンスコンポーネントを含む主体名をマッピングする場合などは、そのほかの方法を使用すべきです。詳細については、次のトピックを参照してください。
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 クライアントには明示的な構成手順が必要なくなります。
DNS が、KDC 用の SRV レコードを返すように構成されている。
レルム名が DNS ドメイン名に一致するか、または KDC がリフェラルをサポートする。
Kerberos クライアントがキータブを必要としない。
場合によっては、Kerberos クライアントを明示的に構成する方がよいことがあります。
リフェラルが使用されていない場合、構成不要のロジックは、レルムを決定するためにホストの DNS ドメイン名に依存します。これにより若干のセキュリティーリスクが導入されますが、このリスクは dns_lookup_realm を有効にするよりはるかに軽微です。
pam_krb5 モジュールは、キータブ内のホスト鍵のエントリに依存します。この要件は krb5.conf ファイルで無効にすることができますが、セキュリティー上の理由からそれはお勧めできません。krb5.conf(4) のマニュアルページを参照してください。
構成不要のプロセスは直接の構成に比べて非効率的であり、しかも DNS に大きく依存します。このプロセスは、直接構成されたクライアントに比べて多数の DNS 検索を実行します。
クライアントの設定プロセス全体の詳細については、「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) の確認を無効にする方法」を参照してください。
Solaris 10 5/08 リリースからは、LDAP を使用して Kerberos のデータベースファイルを管理する機能のサポートが追加されました。手順については、「LDAP データサーバーを使用するように KDC を構成する方法」を参照してください。LDAP を使用すると、Solaris Kerberos データベースと既存の DS セットアップをより適切に調整する必要があるサイトの管理が簡略化されます。
暗号化タイプとは、Kerberos サービスで使用される、暗号化アルゴリズム、暗号化モード、およびハッシュアルゴリズムを特定する識別子です。Kerberos サービスの鍵は、暗号化タイプに関連付けられ、サービスが鍵を使って暗号化処理を行うときに使用される暗号化アルゴリズムと暗号化モードを特定します。サポートされる暗号化タイプは次のとおりです。
des-cbc-md5
des-cbc-crc
des3-cbc-sha1-kd
arcfour-hmac-md5
arcfour-hmac-md5-exp
aes128-cts-hmac-sha1-96
aes256-cts-hmac-sha1-96
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 グラフィカル管理ツール gkadmin ではオンラインヘルプ URL が使用されるため、「Help Contents」メニューが機能するように URL を適切に定義する必要があります。このマニュアルの HTML 版は、任意のサーバーにインストールできます。また、http://docs.sun.com から任意のマニュアルを使用することもできます。
URL は、Kerberos サービスを使用するようにホストを構成するときに krb5.conf ファイルで指定します。URL には、このマニュアルの「主体とポリシーの管理 (手順)」の「グラフィカルな Kerberos 管理ツール」を指定してください。必要に応じて、別の HTML ページを選択することもできます。
この章では、KDC サーバー、ネットワークアプリケーションサーバー、NFS サーバー、および Kerberos クライアントの構成手順について説明します。手順の多くはスーパーユーザーアクセスを必要とするため、この作業はシステム管理者や上級ユーザーが行なってください。レルム間の構成手順など、KDC サーバーに関するトピックについても説明します。
この章の内容は次のとおりです。
構成手順は、その個々の手順がほかの手順に依存するため、特定の順序で実行する必要があります。多くの場合、これらの手順に従うことにより、Kerberos サービスに必要なサービスを設定できます。その他の手順は互いに依存しないため、任意のタイミングで実行できます。次の作業マップで、推奨する Kerberos のインストール順序を示します。
作業 |
説明 |
参照先 |
---|---|---|
1. Kerberos インストールを計画します。 |
ソフトウェア構成処理を開始する前に、構成についての問題を解決します。事前に計画することで、結果的に時間やその他のリソースを節約できます。 | |
2. (省略可能) NTP をインストールします。 |
NTP ソフトウェアなどのクロック同期プロトコルを構成します。Kerberos サービスが正常に動作するには、レルムに含まれるすべてのシステムのクロックを同期化する必要があります。 | |
3. KDC サーバーを構成します。 |
レルムにマスター KDC サーバー、スレーブ KDC サーバー、および KDC データベースを構成および構築します。 | |
4. (省略可能) KDC のセキュリティーを強化します。 |
KDC サーバーに対するセキュリティー侵害を回避します。 | |
5. (省略可能) 入れ替え可能な KDC を構成します。 |
マスター KDC とスレーブ KDC を簡単に入れ替えできるようにします。 |
作業 |
説明 |
参照先 |
---|---|---|
レルム間認証を構成します。 |
レルム間の通信を使用可能にします。 | |
Kerberos アプリケーションサーバーを構成します。 |
サーバーが ftp、telnet、rsh などのサービスを Kerberos 認証を使ってサポートできるようにします。 | |
Kerberos クライアントを構成します。 |
クライアントが Kerberos サービスを使用できるようにします。 | |
Kerberos NFS サーバーを構成します。 |
Kerberos 認証を必要とするファイルシステムを、サーバーが共有できるようにします。 | |
アプリケーションサーバーのセキュリティーを強化します。 |
認証されたトランザクションのみにアクセスを制限して、アプリケーションサーバーのセキュリティーを強化します。 |
Kerberos ソフトウェアをインストールしたあと、KDC サーバーを構成する必要があります。資格を発行するには、1 つのマスター KDC と 1 つ以上のスレーブ KDC を構成する必要があります。KDC が発行する資格は、Kerberos サービスの基本要素であるため、KDC をインストールしないと、ほかの処理を行うことはできません。
マスター KDC とスレーブ KDC の最も大きな違いは、マスター KDC だけがデータベース管理要求を処理できることです。たとえば、パスワードの変更や新しい主体の追加は、マスター KDC で行います。これらの変更は、スレーブ KDC に伝播されます。資格の生成は、スレーブ KDC とマスター KDC が行います。この機能は、マスター KDC が応答できない場合に、冗長性を確保します。
表 23–1 KDC サーバーの構成 (作業マップ)
作業 |
説明 |
参照先 |
---|---|---|
マスター KDC サーバーを構成します。 |
より複雑なインストールに必要な手動のプロセスを使用して、レルムにマスター KDC サーバーとデータベースを構成および構築します。 | |
手動のプロセスを使用し、さらに KDC 用に LDAP を使用して、レルムにマスター KDC サーバーとデータベースを構成および構築します。 | ||
スレーブ KDC サーバーを構成します。 |
より複雑なインストールに必要な手動のプロセスを使用して、レルムにスレーブ KDC サーバーを構成および構築します。 | |
KDC サーバー上の主体鍵を更新します。 |
新しい暗号化タイプを使用して KDC サーバー上のセッション鍵を更新します。 |
この手順では、増分伝播を構成します。さらに、次の構成パラメータを使用します。
レルム名 = EXAMPLE.COM
DNS ドメイン名 = example.com
マスター KDC = kdc1.example.com
admin 主体 = kws/admin
オンラインヘルプ URL = http://denver:8888/ab2/coll.384.1/SEAM/@AB2PageView/6956
この URL は「Kerberos グラフィカル管理ツール」のセクションを指すように調整してください (「Kerberos グラフィカル管理ツールでのオンラインヘルプ URL」を参照)。
この手順を実行するには、ホストが DNS を使用するように構成されている必要があります。マスター KDC を入れ替え可能にする場合の手順については、「マスター KDC とスレーブ KDC の入れ替え」を参照してください。
マスター KDC 上でスーパーユーザーになります。
Kerberos 構成ファイル (krb5.conf) を編集します。
レルム名とサーバー名を変更する必要があります。このファイルの詳細は、krb5.conf(4) のマニュアルページを参照してください。
kdc1 # cat /etc/krb5/krb5.conf [libdefaults] default_realm = EXAMPLE.COM [realms] EXAMPLE.COM = { kdc = kdc1.example.com 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 暗号化タイプの使用」を参照してください。
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 暗号化タイプの使用」を参照してください。
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> |
Kerberos アクセス制御リストファイル (kadm5.acl) を編集します。
作成された /etc/krb5/kadm5.acl ファイルには、KDC を管理できる主体名がすべて含まれている必要があります。
kws/admin@EXAMPLE.COM * |
エントリにより、EXAMPLE.COM レルム内の kws/admin 主体に対して、KDC 内の主体またはポリシーを変更する機能が与えられます。デフォルトのインストールでは、アスタリスク (*) が指定され、すべての admin 主体に変更権限が与えられます。このデフォルトの指定では、セキュリティーが低下する可能性があります。そのため、admin 主体すべてを列挙すると、セキュリティーが向上します。詳細は、kadm5.acl(4) のマニュアルページを参照してください。
kadmin.local コマンドを起動し、主体を追加します。
次の手順では、Kerberos サービスで使用される主体を作成します。
kdc1 # /usr/sbin/kadmin.local kadmin.local: |
必要な数の admin 主体を追加できます。KDC 構成処理を完了するには、1 つ以上の admin 主体を追加する必要があります。この例では、kws/admin 主体を追加します。「kws」の代わりに、適切な主体名で置き換えてください。
kadmin.local: addprinc kws/admin Enter password for principal kws/admin@EXAMPLE.COM:<Type the password> Re-enter password for principal kws/admin@EXAMPLE.COM: <Type it again> Principal "kws/admin@EXAMPLE.COM" created. kadmin.local: |
kiprop 主体を作成します。
kiprop 主体はマスター KDC からの更新の承認に使用されます。
kadmin.local: addprinc -randkey kiprop/kdc1.example.com Principal "kiprop/kdc1.example.com@EXAMPLE.COM" created. kadmin.local: |
このコマンドシーケンスは、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: |
マスター 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: |
kadmin.local を終了します。
以降の手順で必要になる主体をすべて追加しました。
kadmin.local: quit |
Kerberos デーモンを起動します。
kdc1 # svcadm enable -r network/security/krb5kdc kdc1 # svcadm enable -r network/security/kadmin |
kadmin を起動して、主体をさらに追加します。
この時点で、Kerberos グラフィカル管理ツールを使用して、主体を追加できます。追加するには、上記の手順で作成した admin 主体名を使用してログインする必要があります。ただし、次のコマンド行の例では、簡略化されています。
kdc1 # /usr/sbin/kadmin -p kws/admin Enter password: <Type kws/admin password> kadmin: |
ホスト主体は、変更をスレーブ 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: |
この主体は、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: |
マスター 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: |
kadmin を終了します。
kadmin: quit |
(省略可能) NTP などのクロック同期メカニズムを使用して、マスター KDC のクロックを同期化します。
Network Time Protocol (NTP) のインストールと使用は必要はありません。ただし、認証が正常終了するには、krb5.conf ファイルの libdefaults セクションに定義されているデフォルト時間内に収まるよう、すべてのクロックを調整する必要があります。NTP については、「KDC と Kerberos クライアントのクロックの同期化」を参照してください。
スレーブ KDC の構成
冗長性を確保するには、スレーブ KDC を必ず 1 つ以上インストールするようにしてください。 手順については、「スレーブ KDC を手動で構成する方法」を参照してください。
Solaris 10 5/08 リリースから、次の手順を使用して、LDAP データサーバーを使用するように KDC を構成できるようになりました。
この手順では、次の構成パラメータを使用します。
レルム名 = EXAMPLE.COM
DNS ドメイン名 = example.com
マスター KDC = kdc1.example.com
ディレクトリサーバー = dsserver.example.com
admin 主体 = kws/admin
LDAP サービスの FMRI = svc:/application/sun/ds:ds--var-opt-SUNWdsee-dsins1
オンラインヘルプ URL = http://denver:8888/ab2/coll.384.1/SEAM/@AB2PageView/6956
この URL は「Kerberos グラフィカル管理ツール」のセクションを指すように調整してください (「Kerberos グラフィカル管理ツールでのオンラインヘルプ URL」を参照)。
この手順を実行する場合も、ホストが DNS を使用するように構成されている必要があります。パフォーマンスを向上させるためには、KDC と LDAP ディレクトリサービスを同じサーバーにインストールしてください。さらに、ディレクトリサーバーも稼働させるようにしてください。次の手順は、Sun Java Directory Server Enterprise Edition リリースを使用しているサーバーで機能します。
KDC 上でスーパーユーザーになります。
ディレクトリサーバーの証明書を作成し、その証明書をインポートします。
次の手順では、Directory Server 6.1 自己署名付き証明書を使用するように S10 KDC を構成します。証明書の期限が切れている場合は、『Sun Java System Directory Server Enterprise Edition 6.2 管理ガイド』の「自己署名済み証明書を管理する」の手順に従って証明書を更新してください。
自己署名付きのディレクトリサーバー証明書をエクスポートします。
# /usr/sfw/bin/certutil -L -n defaultCert -d /export/sun-ds6.1/directory/alias \ -P 'slapd-' -a > /var/tmp/ds_cert.pem |
ローカルの証明書データベースを作成します。
# /usr/sfw/bin/certutil -N -d /var/ldap |
ディレクトリサーバー証明書をローカルの証明書データベースに追加します。
# /usr/sfw/bin/certutil -A -n defaultCert -i /var/tmp/ds_cert -a -t CT -d /var/ldap |
ディレクトリサーバー証明書をインポートします。
# 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 |
必要に応じて、LDAP ディレクトリにデータを設定します。
既存のスキーマに Solaris Kerberos スキーマを追加します。
# ldapmodify -h dsserver.example.com -D "cn=directory manager" -f /usr/share/lib/ldif/kerberos.ldif |
LDAP ディレクトリ内に Kerberos コンテナを作成します。
krb5.conf ファイルに次のエントリを追加します。
データベースの種類を定義します。
realms セクションに database_module を定義するエントリを追加します。
database_module = LDAP |
データベースのモジュールを定義します。
[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 } |
LDAP ディレクトリ内に KDC を作成します。
このコマンドによって、krbcontainer とその他のいくつかのオブジェクトが作成されます。また、/var/krb5/.k5.EXAMPLE.COM マスター鍵の stash ファイルも作成されます。
# kdb5_ldap_util -D "cn=directory manager" create -P abcd1234 -r EXAMPLE.COM -s |
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" |
KDC サービスの役割を追加します。
次に示すような内容を含む 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 |
LDAP ディレクトリ内に役割のエントリを作成します。
# ldapmodify -a -h dsserver.example.com -D "cn=directory manager" -f kdc_roles.ldif |
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 |
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 暗号化タイプの使用」を参照してください。
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 暗号化タイプの使用」を参照してください。
Kerberos アクセス制御リストファイル (kadm5.acl) を編集します。
作成された /etc/krb5/kadm5.acl ファイルには、KDC を管理できる主体名がすべて含まれている必要があります。
kws/admin@EXAMPLE.COM * |
エントリにより、EXAMPLE.COM レルム内の kws/admin 主体に対して、KDC 内の主体またはポリシーを変更する機能が与えられます。デフォルトのインストールでは、アスタリスク (*) が指定され、すべての admin 主体に変更権限が与えられます。このデフォルトの指定では、セキュリティーが低下する可能性があります。そのため、admin 主体すべてを列挙すると、セキュリティーが向上します。詳細は、kadm5.acl(4) のマニュアルページを参照してください。
kadmin.local コマンドを起動し、主体を追加します。
次の手順では、Kerberos サービスで使用される主体を作成します。
kdc1 # /usr/sbin/kadmin.local kadmin.local: |
必要な数の admin 主体を追加できます。KDC 構成処理を完了するには、1 つ以上の admin 主体を追加する必要があります。この例では、kws/admin 主体を追加します。「kws」の代わりに、適切な主体名で置き換えてください。
kadmin.local: addprinc kws/admin Enter password for principal kws/admin@EXAMPLE.COM:<Type the password> Re-enter password for principal kws/admin@EXAMPLE.COM: <Type it again> Principal "kws/admin@EXAMPLE.COM" created. kadmin.local: |
このコマンドシーケンスは、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: |
kadmin.local を終了します。
以降の手順で必要になる主体をすべて追加しました。
kadmin.local: quit |
(省略可能) Kerberos サービスの LDAP 依存性を構成します。
LDAP および KDC サーバーが同一のホスト上で稼働しており、LDAP サービスが SMF FMRI を使って構成されている場合は、Kerberos デーモンの LDAP サービスに対する依存性を追加します。これにより、LDAP サービスが再起動すると KDC サービスも再起動するようになります。
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 |
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 |
Kerberos デーモンを起動します。
kdc1 # svcadm enable -r network/security/krb5kdc kdc1 # svcadm enable -r network/security/kadmin |
kadmin を起動して、主体をさらに追加します。
この時点で、Kerberos グラフィカル管理ツールを使用して、主体を追加できます。追加するには、上記の手順で作成した admin 主体名を使用してログインする必要があります。ただし、次のコマンド行の例では、簡略化されています。
kdc1 # /usr/sbin/kadmin -p kws/admin Enter password: <Type kws/admin password> kadmin: |
ホスト主体は、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: |
この主体は、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: |
マスター 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: |
kadmin を終了します。
kadmin: quit |
(省略可能) NTP などのクロック同期メカニズムを使用して、マスター KDC のクロックを同期化します。
Network Time Protocol (NTP) のインストールと使用は必要はありません。ただし、認証が正常終了するには、krb5.conf ファイルの libdefaults セクションに定義されているデフォルト時間内に収まるよう、すべてのクロックを調整する必要があります。NTP については、「KDC と Kerberos クライアントのクロックの同期化」を参照してください。
スレーブ KDC の構成
冗長性を確保するには、スレーブ KDC を必ず 1 つ以上インストールするようにしてください。 手順については、「スレーブ KDC を手動で構成する方法」を参照してください。
この手順では、kdc2 という名前の新しいスレーブ KDC を構成します。また、増分伝播も構成します。この手順では、次の構成パラメータを使用します。
レルム名 = EXAMPLE.COM
DNS ドメイン名 = example.com
マスター KDC = kdc1.example.com
スレーブ KDC = kdc2.example.com
admin 主体 = kws/admin
マスター KDC が構成済みである必要があります。スレーブ KDC を入れ替え可能にする手順については、「マスター KDC とスレーブ KDC の入れ替え」を参照してください。
マスター KDC 上でスーパーユーザーになります。
マスター KDC 上で kadmin を起動します。
マスター KDC を構成するときに作成した admin 主体名を使用して、ログインする必要があります。
kdc1 # /usr/sbin/kadmin -p kws/admin Enter password: <Type kws/admin password> kadmin: |
マスター KDC のデータベースにスレーブホスト主体が存在しない場合は、追加します。
スレーブが機能するには、ホスト主体が必要です。主体のインスタンスがホスト名のときは、/etc/resolv.conf ファイル内のドメイン名が大文字であるか小文字であるかに関係なく、FQDN は小文字で指定する必要があります。
kadmin: addprinc -randkey host/kdc2.example.com Principal "host/kdc2.example.com@EXAMPLE.COM" created. kadmin: |
マスター KDC 上で、kiprop 主体を作成します。
kiprop 主体は、マスター KDC からの増分伝播を承認するために使用されます。
kadmin: addprinc -randkey kiprop/kdc2.example.com Principal "kiprop/kdc2.example.com@EXAMPLE.COM" created. kadmin: |
kadmin を終了します。
kadmin: quit |
マスター 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 } |
マスター KDC 上で、kadm5.acl に kiprop エントリを追加します。
このエントリにより、マスター KDC が kdc2 サーバー用の増分伝播の要求を受け取ることができるようになります。
kdc1 # cat /etc/krb5/kadm5.acl */admin@EXAMPLE.COM * kiprop/kdc2.example.com@EXAMPLE.COM p |
マスター KDC 上で、kadmind を再起動し、kadm5.acl ファイルの新しいエントリを使用します。
kdc1 # svcadm restart network/security/kadmin |
すべてのスレーブ KDC 上で、KDC 管理ファイルをマスター KDC サーバーからコピーします。
この手順は、マスター KDC サーバーが、各 KDC サーバーに必要な情報を更新したため、すべてのスレーブ KDC 上で実行する必要があります。ftp などの転送メカニズムを使用して、マスター KDC から次のファイルのコピーを取得できます。
/etc/krb5/krb5.conf
/etc/krb5/kdc.conf
すべてのスレーブ KDC 上で、マスター KDC のエントリと各スレーブ KDC のエントリをデータベース伝播構成ファイル kpropd.acl に追加します。
この情報は、すべてのスレーブ KDC サーバー上で更新する必要があります。
kdc2 # cat /etc/krb5/kpropd.acl host/kdc1.example.com@EXAMPLE.COM host/kdc2.example.com@EXAMPLE.COM |
すべてのスレーブ KDC 上で、Kerberos アクセス制御リストファイル kadm5.acl が反映されていないことを確認してください。
修正前の kadm5.acl ファイルは次のようになっています。
kdc2 # cat /etc/krb5/kadm5.acl */admin@___default_realm___ * |
ファイルに kiprop のエントリがある場合は、それを削除します。
新しいスレーブ上で、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 } |
新しいスレーブ上で、kadmin コマンドを起動します。
マスター KDC を構成するときに作成した admin 主体名を使用して、ログインする必要があります。
kdc2 # /usr/sbin/kadmin -p kws/admin Enter password: <Type kws/admin password> kadmin: |
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: |
スレーブ 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: |
kadmin を終了します。
kadmin: quit |
新しいスレーブ上で、Kerberos 伝播デーモンを起動します。
kdc2 # /usr/lib/krb5/kpropd |
新しいスレーブ上で、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> |
Kerberos 伝播デーモンを終了します。
kdc2 # pkill kpropd |
(省略可能) 新しいスレーブ KDC 上で、NTP などのクロック同期メカニズムを使用して、マスター KDC のクロックを同期化します。
Network Time Protocol (NTP) のインストールと使用は必要はありません。ただし、認証が正常終了するには、krb5.conf ファイルの libdefaults セクションに定義されているデフォルト時間内に収まるよう、すべてのクロックを調整する必要があります。NTP については、「KDC と Kerberos クライアントのクロックの同期化」を参照してください。
新しいスレーブ上で、KDC デーモン (krb5kdc) を起動します。
krb5kdc サービスが有効なときは、システムがスレーブとして構成されていると kpropd も起動します。
kdc2 # svcadm enable network/security/krb5kdc |
Solaris 10 リリース以前に作成された Solaris KDC サービスで、チケット認可サービス (TGS) 主体が DES 鍵のみを持つ場合、この鍵により、チケット認可チケット (TGT) セッション鍵の暗号化タイプは DES に限定されます。より強力なほかの暗号化タイプにも対応する Solaris 10 に Solaris KDC をアップデートすると、KDC で生成されるすべてのセッション鍵について暗号化を強化できるようになります。ただし、既存の TGS 主体の鍵を新しい暗号化タイプに対応するよう更新しなければ、TGT セッション鍵は DES に限定されたままになります。次の手順では、この鍵を更新して、ほかの暗号化タイプも使用できるようにします。
TGS サービス主体鍵を更新します。
kdc1 % /usr/sbin/kadmin -p kws/admin Enter password: <Type kws/admin password> kadmin: cpw -randkey krbtgt/EXAMPLE.COM@EXAMPLE.COM |
KDC マスターに root としてログオンした場合、次のコマンドを使用して TGS サービス主体を更新できます。
kdc1 # kadmin.local -q 'cpw -randkey krbtgt/EXAMPLE.COM@EXAMPLE.COM' |
複数のレルムを接続して、レルム間でユーザーを認証することができます。レルム間の認証は、2 つのレルム間で共有される秘密鍵を作成することによって実行されます。レルム間の関係には、階層関係または直接接続があります (「レルムの階層」を参照)。
この手順の例では、ENG.EAST.EXAMPLE.COM レルムと EAST.EXAMPLE.COM レルムを使用します。レルム間認証は、双方向に確立されます。この手順は、2 つのレルムのマスター KDC 上で完了する必要があります。
マスター KDC の各レルムが構成済みである必要があります。認証プロセスを十分にテストするには、複数の Kerberos クライアントが構成されている必要があります。
最初のマスター KDC 上でスーパーユーザーになります。
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 つのレルムで同じである必要があります。
Kerberos 構成ファイル (krb5.conf) にエントリを追加して、すべてのレルムのドメイン名を定義します。
# cat /etc/krb5/krb5.conf [libdefaults] . . [domain_realm] .eng.east.example.com = ENG.EAST.EXAMPLE.COM .east.example.com = EAST.EXAMPLE.COM |
この例では、ENG.EAST.EXAMPLE.COM レルムと EAST.EXAMPLE.COM レルムのドメイン名を定義しています。Kerberos 構成ファイルは先頭から末尾方向に検索されるため、サブドメインは最初に定義してください。
Kerberos 構成ファイルをこのレルムのすべてのクライアントにコピーします。
レルム間認証が動作するには、すべてのシステム (スレーブ KDC などのサーバーを含む) に新しいバージョンの Kerberos 構成ファイル (/etc/krb5/krb5.conf) がインストールされている必要があります。
もう一方のレルムで上記の全手順を繰り返します。
この手順では、ENG.EAST.EXAMPLE.COM レルムと SALES.WEST.EXAMPLE.COM レルムを使用します。レルム間認証は、双方向に確立されます。この手順は、2 つのレルムのマスター KDC 上で完了する必要があります。
マスター KDC の各レルムが構成済みである必要があります。認証プロセスを十分にテストするには、複数の Kerberos クライアントが構成されている必要があります。
いずれかのマスター KDC サーバー上でスーパーユーザーになります。
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 つのレルムで同じである必要があります。
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 = . } |
Kerberos 構成ファイルを現在のレルムのすべてのクライアントにコピーします。
レルム間認証が動作するには、すべてのシステム (スレーブ KDC などのサーバーを含む) に新しいバージョンの Kerberos 構成ファイル (/etc/krb5/krb5.conf) がインストールされている必要があります。
もう一方のレルムで上記の全手順を繰り返します。
ネットワークアプリケーションサーバーとは、次のいずれかのネットワークアプリケーションを 1 つ以上使ってアクセスを提供するホストのことです。 ftp、rcp、rlogin、rsh、ssh、telnet。いくつかの手順を実行するだけで、これらのコマンドの Kerberos バージョンをサーバー上で有効にすることができます。
この手順では、次の構成パラメータを使用します。
アプリケーションサーバー = boston
admin 主体 = kws/admin
DNS ドメイン名 = example.com
レルム名 = EXAMPLE.COM
この手順を行う場合には、マスター KDC がすでに構成されていなければなりません。このプロセスを十分にテストするには、複数の Kerberos クライアントが構成されている必要があります。
(省略可能) NTP クライアントなどのクロック同期メカニズムをインストールします。
NTP については、「KDC と Kerberos クライアントのクロックの同期化」を参照してください。
新しいサーバーの主体を追加し、そのサーバーのキータブを更新します。
次のコマンドは、ホスト主体の存在有無を報告します。
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: |
サーバーの 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: |
サーバーの 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: |
kadmin を終了します。
kadmin: quit |
NFS サービスは UNIX ユーザー ID (UID) を使用してユーザーを識別しており、GSS 資格の主体を直接に使用することはできません。そのため、資格の主体を UID に対応付けるために、ユーザー資格の主体を UNIX UID に割り当てる資格テーブルを作成する必要があります。デフォルトの資格マッピングの詳細については、「GSS 資格の UNIX 資格へのマッピング」を参照してください。この節では、Kerberos NFS サーバーの構成手順、資格テーブルの管理手順、および NFS マウントしたファイルシステムに対して Kerberos セキュリティーモードを有効にする手順を中心に説明します。次の表は、この節で説明する作業の一覧です。
表 23–2 Kerberos NFS サーバーの構成 (作業マップ)
作業 |
説明 |
参照先 |
---|---|---|
Kerberos NFS サーバーを構成します。 |
Kerberos 認証を必要とするファイルシステムを、サーバーが共有できるようにします。 | |
資格テーブルを作成します。 |
デフォルトのマッピングが十分でない場合、GSS 資格から UNIX ユーザー ID へのマッピングに使用できる資格テーブルを生成します。 | |
ユーザー資格を UNIX UID に割り当てる資格テーブルを変更します。 |
資格テーブルの情報を更新します。 | |
類似する 2 つのレルム間の資格マッピングを作成します。 |
レルムがパスワードファイルを共有している場合に、あるレルムから別のレルムに UID をマッピングする方法を説明します。 | |
Kerberos 認証を使用してファイルシステムを共有します。 |
セキュリティーモードを使用してファイルシステムを共有し、Kerberos 認証を常に行います。 |
この手順では、次の構成パラメータを使用します。
レルム名 = EXAMPLE.COM
DNS ドメイン名 = example.com
NFS サーバー = denver.example.com
admin 主体 = kws/admin
Kerberos NFS サーバーを構成するための前提条件を完了します。
マスター KDC が構成済みである必要があります。処理を十分にテストするには、複数のクライアントが必要です。
(省略可能) NTP クライアントなどのクロック同期メカニズムをインストールします。
Network Time Protocol (NTP) のインストールと使用は必要はありません。ただし、認証が正常終了するには、すべてのクロックが、krb5.conf ファイル内の clockskew 関係指定子で定義されている最大の誤差以内で KDC サーバー上の時刻と同期化されている必要があります。NTP については、「KDC と Kerberos クライアントのクロックの同期化」を参照してください。
NFS サーバーを Kerberos クライアントとして構成します。
「Kerberos クライアントの構成」の手順に従ってください。
kadmin を起動します。
Kerberos グラフィカル管理ツールを使って主体を追加する方法については、「新しい Kerberos 主体を作成する方法」を参照してください。追加するときは、マスター KDC を構成するときに作成した admin 主体名を使用してログインする必要があります。ただし、次の例では、コマンド行を使用して、必要な主体を追加しています。
denver # /usr/sbin/kadmin -p kws/admin Enter password: <Type kws/admin password> kadmin: |
サーバーの NFS サービス主体を作成します。
主体のインスタンスがホスト名のときは、/etc/resolv.conf ファイル内のドメイン名が大文字であるか小文字であるかに関係なく、FQDN は小文字で指定する必要があります。
NFS データへのアクセスに使用されるシステム上の一意のインタフェースごとに、上記の手順を繰り返します。ホストに一意の名前を持ったインタフェースが複数存在する場合、一意の名前は、それぞれに NFS サービス主体を持つ必要があります。
kadmin: addprinc -randkey nfs/denver.example.com Principal "nfs/denver.example.com" created. kadmin: |
サーバーの 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: |
kadmin を終了します。
kadmin: quit |
(省略可能) 必要に応じて、特殊な GSS 資格マップを作成します。
通常、Kerberos サービスは、GSS 資格と UNIX UID 間の適切な対応表を生成します。デフォルトのマッピングについては、「GSS 資格の UNIX 資格へのマッピング」を参照してください。デフォルトのマッピングが十分でない場合は、「資格テーブルを作成する方法」を参照してください。
NFS ファイルシステムを Kerberos セキュリティーモードで共有します。
詳細は、「複数の Kerberos セキュリティーモードで安全な NFS 環境を設定する方法」を参照してください。
gsscred 資格テーブルは、Kerberos 主体を UID に割り当てるために NFS サーバーが使用します。デフォルトでは、主体名の一次の部分が UNIX のログイン名に一致します。NFS クライアントが Kerberos 認証を使用して NFS サーバーからファイルシステムをマウントするには、デフォルトのマッピングが十分でない場合、このテーブルを作成する必要があります。
/etc/gss/gsscred.conf を編集してセキュリティーメカニズムを変更します。
このメカニズムを files に変更します。
gsscred コマンドを使用して資格テーブルを作成します。
# gsscred -m kerberos_v5 -a |
gsscred コマンドは、/etc/nsswitch.conf ファイル内の passwd エントリに指定されているすべてのソースから、情報を収集します。資格テーブルにローカルのパスワードエントリを入れたくない場合は、files エントリを一時的に削除しなければならないことがあります。詳細は、gsscred(1M) のマニュアルページを参照してください。
この手順を行うには、gsscred テーブルがすでに NFS サーバーに作成済みである必要があります。手順については、「資格テーブルを作成する方法」を参照してください。
NFS サーバー上でスーパーユーザーになります。
gsscred コマンドを使用して、エントリを資格テーブルに追加します。
# gsscred -m mech [ -n name [ -u uid ]] -a |
使用するセキュリティーメカニズムを定義します。
KDC に定義されている、ユーザーの主体名を定義します。
パスワードデータベースに定義されている、ユーザーの UID を定義します。
UID を主体名の割り当てに追加します。
次の例では、 sandy/admin という名前の主体にエントリを 1 つ追加し、UID 3736 に割り当てます。
# gsscred -m kerberos_v5 -n sandy/admin -u 3736 -a |
次の例では、sandy/admin@EXAMPLE.COM という名前の主体にエントリを 1 つ追加し、UID 3736 に割り当てます。
# gsscred -m kerberos_v5 -n sandy/admin@EXAMPLE.COM -u 3736 -a |
この手順では、同じパスワードファイルを使用するレルム間の適切な資格マッピングを提供します。この例では、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 . } |
この例では、同じパスワードファイルを使用するレルム間の適切な資格マッピングを提供します。この例では、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 資格へのマッピングの監視」を参照してください。
この手順により、さまざまなセキュリティーモードまたはフレーバを使用して、NFS サーバーが NFS に安全にアクセスできるようになります。クライアントがセキュリティーフレーバについて NFS サーバーとネゴシエーションを行うとき、クライアントがアクセスしたサーバーが提供する最初のフレーバが使用されます。このフレーバは、NFS サーバーが共有するファイルシステムにおける後続のクライアント要求すべてに使用されます。
NFS サーバー上でスーパーユーザーになります。
キータブファイルに 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 |
/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 |
/etc/dfs/dfstab ファイルを編集し、必要なセキュリティーモードを sec= オプションに指定して、適切なエントリに追加します。
share -F nfs -o sec=mode file-system |
ファイルシステムを共有するときに使用するセキュリティーモードを指定します。複数のセキュリティーモードを使用するときは、デフォルトとして、リストの最初のモードが使用されます。
共有するファイルシステムへのパスを定義します。
指定されたファイルシステムのファイルにアクセスするすべてのクライアントは、Kerberos 認証が必要です。ファイルにアクセスするには、NFS クライアント上にユーザー主体が認証される必要があります。
NFS サービスがサーバー上で動作していることを確認します。
1 つまたは複数の share コマンドをはじめて実行する場合、NFS デーモンが動作していないことがあります。次のコマンドでデーモンを再起動します。
# svcadm restart network/nfs/server |
(省略可能) オートマウンタを使用する場合は、auto_master データベースを編集して、デフォルト以外のセキュリティーモードを選択してください。
ファイルシステムのアクセスにオートマウンタを使用しない場合やデフォルトの選択をセキュリティーモードとして使用する場合は、この手順を行う必要はありません。
file-system auto_home -nosuid,sec=mode |
(省略可能) 手動で mount コマンドを実行し、デフォルト以外のモードを使用してファイルシステムにアクセスします。
代わりに、mount コマンドにセキュリティーモードを指定できますが、オートマウンタは利用できません。
# mount -F nfs -o sec=mode file-system |
この例の dfstab ファイルの行は、NFS サービスを使用してファイルにアクセスするには、Kerberos 認証が成功する必要があることを示しています。
# grep krb /etc/dfs/dfstab share -F nfs -o sec=krb5 /export/home |
次の例では、3 つの Kerberos セキュリティーモードがすべて選択されています。クライアントと NFS サーバーの間で、どのモードを使用するかのネゴシエーションが行われます。コマンドの最初のモードが失敗すると、次のモードが試行されます。詳細は、nfssec(5) のマニュアルページを参照してください。
# grep krb /etc/dfs/dfstab share -F nfs -o sec=krb5:krb5i:krb5p /export/home |
Kerberos クライアントは、Kerberos サービスを使用する同じネットワーク上のすべてのホスト (KDC サーバーを除く) です。この節では、Kerberos クライアントのインストール手順と、root 認証を使用して NFS ファイルシステムをマウントする方法について説明します。
次の作業マップは、Kerberos クライアントの設定に関連するすべての手順が含まれます。各行には、作業識別名、その作業を行う理由、および作業へのリンクが含まれます。
作業 |
説明 |
参照先 |
---|---|---|
Kerberos クライアントのインストールプロファイルを確立します。 |
Kerberos クライアントの自動インストールに使用されるクライアントのインストールプロファイルを生成します。 | |
Kerberos クライアントを構成します。 |
手動で Kerberos クライアントをインストールします。各クライアントのインストールに独自のインストールパラメータが必要な場合に、この手順を使用します。 | |
自動的に Kerberos クライアントをインストールします。各クライアントのインストールパラメータが同じ場合に、この手順を使用します。 | ||
対話的に Kerberos クライアントをインストールします。2、3 のインストールパラメータを変更する必要がある場合にだけ、この手順を使用します。 | ||
クライアントが root ユーザーとして NFS ファイルシステムにアクセスすることを許可します |
root アクセス付きで共有される NFS ファイルシステムをクライアントがマウントできるように、root 主体をクライアント上に作成します。また、cron ジョブを実行できるように、NFS ファイルシステムへの非対話的な root アクセスをクライアントがセットアップすることを許可します。 | |
クライアントのチケット認可チケット (TGT) を発行した KDC の確認を無効にします。 |
ローカルのキータブファイルにホスト主体を保存しないクライアントが、TGT を発行した KDC とホスト主体を発行した KDC が同じサーバーであることを確認するセキュリティー検査を省略できるようにします。 |
この手順は、Kerberos クライアントをインストールする際に使用される kclient プロファイルを作成します。kclient プロファイルを使用することにより、入力エラーの可能性を減らします。また、プロファイルを使用すると、対話型のプロセスと比べて、ユーザーの介入も減ります。
スーパーユーザーになります。
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 |
この手順では、インストールプロファイルを使用します。 「Kerberos クライアントのインストールプロファイルの作成方法」を参照してください。
スーパーユーザーになります。
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# |
次の例は、インストールプロファイルに設定されている 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# |
この手順では、インストールプロファイルなしで kclient インストールユーティリティーを使用します。
スーパーユーザーになります。
kclient インストールスクリプトを実行します。
インストールには、次の情報が必要です。
Kerberos レルム名
KDC マスターホスト名
管理主体名
管理主体のパスワード
次の出力は、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 ! # |
この手順では、次の構成パラメータを使用します。
レルム名 = EXAMPLE.COM
DNS ドメイン名 = example.com
マスター KDC = kdc1.example.com
スレーブ KDC = kdc2.example.com
NFS サーバー = denver.example.com
クライアント = client.example.com
admin 主体 = kws/admin
ユーザー主体 = mre
オンラインヘルプ URL = http://denver:8888/ab2/coll.384.1/SEAM/@AB2PageView/6956
この URL は「Kerberos グラフィカル管理ツール」のセクションを指すように調整してください (「Kerberos グラフィカル管理ツールでのオンラインヘルプ URL」を参照)。
スーパーユーザーになります。
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 暗号化タイプの使用」を参照してください。
(省略可能) KDC の検出に使用されるプロセスを変更します。
Solaris 10 5/08 リリース以降のデフォルトでは、Kerberos レルムから KDC へのマッピングが決定される順序は次のとおりです。
krb5.conf 内の realms セクションの定義。
DNS 内の SRV レコードの検索による。
krb5.conf ファイルの libdefaults セクションに dns_lookup_kdc または dns_fallback を追加して、この動作を変更できます。詳細は、krb5.conf(4) のマニュアルページを参照してください。常にリフェラルが最初に試行されます。
(省略可能) ホストのレルムの決定に使用されるプロセスを変更します。
Solaris 10 5/08 リリース以降のデフォルトでは、ホストからレルムへのマッピングが決定される順序は次のとおりです。
KDC がリフェラルをサポートしている場合は、KDC からクライアントに、ホストが属しているレルムが通知されることがある。
krb5.conf ファイル内の domain_realm の定義による。
ホストの DNS ドメイン名。
デフォルトレルム。
krb5.conf ファイルの libdefaults セクションに dns_lookup_kdc または dns_fallback を追加して、この動作を変更できます。詳細は、krb5.conf(4) のマニュアルページを参照してください。常にリフェラルが最初に試行されます。
(省略可能) NTP などのクロック同期メカニズムを使用して、クライアントのクロックをマスター KDC のクロックと同期化します。
Network Time Protocol (NTP) のインストールと使用は必要はありません。ただし、認証が正常終了するには、すべてのクロックが、krb5.conf ファイル内の clockskew 関係指定子で定義されている最大の誤差以内で KDC サーバー上の時刻と同期化されている必要があります。NTP については、「KDC と Kerberos クライアントのクロックの同期化」を参照してください。
kadmin を起動します。
Kerberos グラフィカル管理ツールを使って主体を追加する方法については、「新しい Kerberos 主体を作成する方法」を参照してください。追加するときは、マスター KDC を構成するときに作成した admin 主体名を使用してログインする必要があります。ただし、次の例では、コマンド行を使用して、必要な主体を追加しています。
denver # /usr/sbin/kadmin -p kws/admin Enter password: <Type kws/admin password> kadmin: |
(省略可能) ユーザー主体が存在しない場合は、ユーザー主体を作成します。
このホストに関連付けられているユーザーに主体が割り当てられていない場合だけ、ユーザー主体を作成します。
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: |
(省略可能) 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: |
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: |
(省略可能) サーバーの 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: |
kadmin を終了します。
kadmin: quit |
(省略可能) NFS での Kerberos を有効にします。
/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 |
DNS を有効にします。
/etc/resolv.conf ファイルがまだ作成されていない場合は、このファイルを作成します。サービス主体の正規化は DNS に依存して正規化を実行するためです。詳細は、resolv.conf(4) のマニュアルページを参照してください。
gssd サービスを再開します。
/etc/resolv.conf ファイルを作成または変更したら、gssd デーモンを再起動して、すべての変更を再読み込みする必要があります。
# svcadm restart network/rpc/gss |
クライアントから 自動的に TGT を更新するか、または Kerberos チケットの有効期限切れをユーザーに警告する場合は、/etc/krb5/warn.conf ファイルにエントリを作成します。
詳細は、warn.conf(4) のマニュアルページを参照してください。
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 } |
@ 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" |
この例は、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 |
この手順では、ローカルの /etc/krb5/krb5.keytab ファイルに保存されているホスト主体の KDC とチケット認可チケットを発行した KDC が同じであることを確認するセキュリティー検査を無効にします。この検査は DNS の偽装攻撃を防止します。ただし、一部のクライアント構成では、ホスト主体を使用できない場合があるため、クライアントが機能できるようにこの検査を無効にする必要があります。次のような構成では、この検査を無効にする必要があります。
クライアントの IP アドレスが動的に割り当てられる。DHCP クライアントなど。
クライアントはサービスをホストするように構成されていないため、ホスト主体が作成されていない。
クライアントにホスト鍵が保存されていない。
スーパーユーザーになります。
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] セクションに入力すると、設定は定義したレルムだけに適用されます。
この手順を実行すると、クライアントは root の ID 特権による Kerberos 認証を必要とする、NFS ファイルシステムにアクセスできるようになります。特に、NFS ファイルシステムが次のようなオプションによって共有されている場合です。-o sec=krb5,root=client1.sun.com
スーパーユーザーになります。
kadmin を起動します。
Kerberos グラフィカル管理ツールを使って主体を追加する方法については、「新しい Kerberos 主体を作成する方法」を参照してください。追加するときは、マスター KDC を構成するときに作成した admin 主体名を使用してログインする必要があります。ただし、次の例では、コマンド行を使用して、必要な主体を追加しています。
denver # /usr/sbin/kadmin -p kws/admin Enter password: <Type kws/admin password> kadmin: |
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: |
サーバーのキータブファイルに 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: |
kadmin を終了します。
kadmin: quit |
Kerberos 主体を持たないユーザーを、既存の Kerberos レルムに自動的に移行できます。移行を行うには、/etc/pam.conf のサーバーの認証スタックにある pam_krb5_migrate モジュールの積み重ねにより使用されているサービス用の PAM フレームワークを使用します。
この例では、dtlogin と other の PAM サービス名が構成され、自動移行を使用します。この手順では、次の構成パラメータを使用します。
レルム名 = EXAMPLE.COM
マスター KDC = kdc1.example.com
移行サービスをホストするマシン = server1.example.com
移行サービス主体 = host/server1.example.com
レルム EXAMPLE.COM の Kerberos クライアントとして server1 を設定します。詳細は、「Kerberos クライアントの構成」を参照してください。
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 |
PAM 構成ファイルを変更します。
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 |
(省略可能) 必要に応じて、即座のパスワードの変更を強制します。
新しく作成された 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 |
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 |
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 |
マスター 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 * |
マスター KDC 上で、Kerberos 管理デーモンを再起動します。
この手順により、kadmind デーモンが新しい kadm5.acl エントリを使用できるようになります。
kdc1 # svcadm restart network/security/kadmin |
マスター 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 |
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 のクライアントサーバー実装の例です。
KDC および Kerberos クライアントがクロックを同期化するには、次の手順を実行します。
ネットワークに NTP サーバーを設定します。NTP サーバーは、マスター KDC 以外であればどのシステムでも設定できます。NTP サーバーの作業については、『Solaris のシステム管理 (ネットワークサービス)』の「NTP の管理 (作業)」を参照してください。
ネットワークの KDC と Kerberos クライアントを構成するときに、それらを NTP サーバーの NTP クライアントとして設定します。NTP クライアントの作業については、『Solaris のシステム管理 (ネットワークサービス)』の「NTP の管理 (作業)」を参照してください。
マスター KDC とスレーブ KDC を入れ替えるときは、この節で説明する手順を行います。マスター KDC とスレーブ KDC の入れ替えは、マスター KDC に何らかの理由で障害が発生した場合、またはマスター KDC を再インストールする必要がある場合 (新しいハードウェアをインストールした場合など) にだけ行ってください。
この手順は、マスター KDC に入れ替え可能なスレーブ KDC に対して実行します。この手順は、増分伝播を使用していることを想定しています。
KDC をインストールするときに、マスター KDC および入れ替え可能なスレーブ KDC に対して別名を使用します。
KDC に対してホスト名を定義するときは、各システムの別名が DNS に登録されている必要があります。/etc/krb5/krb5.conf ファイルにホストを定義するときも、別名を使用します。
手順に従って、スレーブ KDC をインストールします。
入れ替えするサーバーは、レルム内でスレーブ KDC として動作している必要があります。手順については、「スレーブ KDC を手動で構成する方法」を参照してください。
マスター KDC コマンドを移動します。
このスレーブ KDC からマスター KDC コマンドが実行されることを防ぐために、kprop、kadmind、および kadmin.local コマンドを別の場所に移動します。
kdc4 # mv /usr/lib/krb5/kprop /usr/lib/krb5/kprop.save kdc4 # mv /usr/lib/krb5/kadmind /usr/lib/krb5/kadmind.save kdc4 # mv /usr/sbin/kadmin.local /usr/sbin/kadmin.local.save |
この手順では、旧マスター KDC サーバー名は、kdc1 です。新しいマスター KDC となるスレーブ KDC の名前は、kdc4 です。この手順は、増分伝播を使用していることを想定しています。
この手順を実行するには、スレーブ KDC が入れ替え可能なスレーブとして設定されている必要があります。詳細は、「入れ替え可能なスレーブ KDC を構成する方法」を参照してください。
新しいマスター KDC 上で、kadmin を起動します。
kdc4 # /usr/sbin/kadmin -p kws/admin Enter password: <Type kws/admin password> kadmin: |
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: |
キータブファイルを作成します。
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: |
kadmin を終了します。
kadmin: quit |
新しいマスター KDC 上で、同期を強制します。
次の手順は、スレーブサーバー上で強制的に KDC を完全に更新します。
kdc4 # svcadm disable network/security/krb5kdc kdc4 # rm /var/krb5/principal.ulog |
新しいマスター KDC 上で、更新が完了したことを確認します。
kdc4 # /usr/sbin/kproplog -h |
新しいマスター KDC 上で、KDC サービスを再開します。
kdc4 # svcadm enable -r network/security/krb5kdc |
新しいマスター KDC 上で、更新ログを消去します。
この手順は、新しいマスター KDC サーバーの更新ログを再度初期化します。
kdc4 # svcadm disable network/security/krb5kdc kdc4 # rm /var/krb5/principal.ulog |
旧マスター KDC 上で、kadmind プロセスとkrb5kdc プロセスを終了します。
kadmind プロセスを終了するときは、旧 KDC データベースに対する変更は行わないでください。
kdc1 # svcadm disable network/security/kadmin kdc1 # svcadm disable network/security/krb5kdc |
旧マスター 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 } |
旧マスター 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 |
DNS サーバー上で、マスター KDC の別名を変更します。
サーバーを変更するために、example.com ゾーンファイルを編集して masterkdc のエントリを変更します。
masterkdc IN CNAME kdc4 |
DNS サーバー上で、インターネットドメインネームサーバーを再起動します。
次のコマンドを実行して、新しい別名情報を再ロードします。
# svcadm refresh network/dns/server |
新しいマスター 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 |
新しいマスター 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 |
新しいマスター 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 } |
新しいマスター 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 |
新しいマスター KDC 上で、kadmind と krb5kdc を実行します。
kdc4 # svcadm enable -r network/security/krb5kdc kdc4 # svcadm enable -r network/security/kadmin |
旧マスター 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 |
旧マスター 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 |
旧マスター KDC 上で、kpropd と krb5kdc を実行します。
krb5kdc デーモンが起動すると、システムがスレーブとして構成されている場合、kpropd も起動します。
kdc1 # svcadm enable network/security/krb5kdc |
Kerberos データベースは、Kerberos の最も重要な構成要素であるため、適切に管理する必要があります。この節では、データベースのバックアップと復元、増分または並列伝播の設定、stash ファイルの管理など、Kerberos データベースの管理についていくつかの手順を説明します。データベースを初期設定する手順については、「マスター KDC を手動で構成する方法」を参照してください。
マスター 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 には更新が反映されません。この更新は失われます。このため、定期的に実行される伝播の前に重要な更新を追加した場合は、データの損失を回避するために手動でデータベースを伝播する必要があります。
スレーブ KDC の kpropd.acl ファイルの各行には、ホスト主体名と、伝播された最新のデータベースの受信元となるシステムが指定されています。マスター KDC を使用してすべてのスレーブ KDC に伝播する場合は、各スレーブ KDC の kpropd.acl ファイルに対してマスター KDC の主体名だけを指定する必要があります。
ただし、このマニュアルの Kerberos のインストールおよびインストール後の構成手順では、マスター KDC とスレーブ KDC に対して同じ kpropd.acl ファイルを追加するように説明しています。このファイルには、すべての KDC ホスト主体名が含まれます。この構成を使用すると、伝播元の KDC が一時的に使用できなくなったときでも、任意の KDC から伝播することができます。また、すべての KDC に同一のコピーを保持すると、構成の管理が容易になります。
kprop_script コマンドは、kprop コマンドを使用して Kerberos データベースをほかの KDC に伝播します。kprop_script コマンドをスレーブ KDC 上で実行すると、そのスレーブ KDC の Kerberos データベースのコピーがほかの KDC に伝播されます。kprop_script には、ホスト名のリストを引数として指定します。区切り文字は空白です。指定したホスト名は、伝播先の KDC になります。
kprop_script を実行すると、Kerberos データベースのバックアップが /var/krb5/slave_datatrans ファイルに作成され、指定した KDC にそのファイルがコピーされます。Kerberos データベースは、伝播が完了するまでロックされます。
マスター KDC 上でスーパーユーザーになります。
kdb5_util の dump コマンドを使用して、Kerberos データベースをバックアップします。
# /usr/sbin/kdb5_util dump [-verbose] [-d dbname] [filename [principals...]] |
バックアップする各主体とポリシー名を出力します。
バックアップするデータベース名を定義します。ファイルの絶対パスを指定できます。-d オプションを指定しない場合、デフォルトのデータベース名は /var/krb5/principal となります。
データベースのバックアップに使用するファイルを定義します。ファイルの絶対パスを指定できます。ファイルを指定しなかった場合、データベースは標準出力にダンプされます。
バックアップする主体を 1 つ以上定義します (区切り文字は空白)。主体名は完全指定形式にする必要があります。主体を指定しなかった場合、データベース全体がバックアップされます。
次の例では、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 |
マスター KDC 上でスーパーユーザーになります。
マスター上で、KDC デーモンを終了します。
kdc1 # svcadm disable network/security/krb5kdc kdc1 # svcadm disable network/security/kadmin |
kdb_util コマンドの load コマンドを使用して、Kerberos データベースを復元します。
# /usr/sbin/kdb5_util load [-verbose] [-d dbname] [-update] [filename] |
復元する各主体とポリシー名を出力します。
復元するデータベース名を定義します。ファイルの絶対パスを指定できます。-d オプションを指定しない場合、デフォルトのデータベース名は /var/krb5/principal となります。
既存のデータベースを更新します。指定しない場合、新しいデータベースが作成されるか、既存のデータベースが上書きされます。
データベースの復元に使用するファイルを定義します。ファイルの絶対パスを指定できます。
KDC デーモンを起動します。
kdc1 # svcadm enable -r network/security/krb5kdc kdc1 # svcadm enable -r network/security/kadmin |
次の例では、database1 というデータベースが、dumpfile ファイルから現在のディレクトリに復元されます。-update オプションが指定されていないため、復元によって新しいデータベースが作成されます。
# kdb5_util load -d database1 dumpfile |
Solaris 8 または Solaris 9 リリースが稼働するサーバー上で KDC データベースが作成されている場合、データベースを変換すると、改善されたデータベースのフォーマットを利用することができます。
データベースが古いフォーマットを使用していることを確認してください。
マスター上で、KDC デーモンを終了します。
kdc1 # svcadm disable network/security/krb5kdc kdc1 # svcadm disable network/security/kadmin |
データベースの一時的なコピーを格納するためのディレクトリを作成します。
kdc1 # mkdir /var/krb5/tmp kdc1 # chmod 700 /var/krb5/tmp |
KDC データベースをダンプします。
kdc1 # kdb5_util dump /var/krb5/tmp/prdb.txt |
現在のデータベースファイルのコピーを保存します。
kdc1 # cd /var/krb5 kdc1 # mv princ* tmp/ |
データベースをロードします。
kdc1 # kdb5_util load /var/krb5/tmp/prdb.txt |
KDC デーモンを起動します。
kdc1 # svcadm enable -r network/security/krb5kdc kdc1 # svcadm enable -r network/security/kadmin |
この手順を使って、増分伝播を使用するように既存のマスター KDC を再構成します。この手順では、次の構成パラメータを使用します。
レルム名 = EXAMPLE.COM
DNS ドメイン名 = example.com
マスター KDC = kdc1.example.com
スレーブ KDC = kdc2.example.com
admin 主体 = kws/admin
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 } |
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: |
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 |
マスター KDC 上で、kadm5.acl に kiprop エントリを追加します。
このエントリにより、マスター KDC が kdc2 サーバーから増分伝播の要求を受け取ることができるようになります。
kdc1 # cat /etc/krb5/kadm5.acl */admin@EXAMPLE.COM * kiprop/kdc2.example.com@EXAMPLE.COM p |
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 |
kadmind を再起動します。
kdc1 # svcadm restart network/security/kadmin |
増分伝播を使用するすべてのスレーブ KDC サーバーを再構成します。
詳細な手順については、「スレーブ KDC を再構成して増分伝播を使用する方法」を参照してください。
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 } |
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 |
kpropd を無効にします。
kdc2 # svcadm disable network/security/krb5_prop |
KDC サーバーを再起動します。
kdc2 # svcadm restart network/security/krb5kdc |
この手順は Solaris 10 リリースを実行しているスレーブ KDC サーバーを再構成して完全伝播を使用する方法を示しています。通常、この手順は、マスター KDC サーバーが Solaris 9 リリースまたはそれ以前のリリースのいずれかを実行している場合にのみ使用する必要があります。この場合、マスター KDC サーバーは増分伝播をサポートできないので、伝播が機能するようにスレーブを構成する必要があります。
この手順では、kdc3 という名前のスレーブ KDC を構成します。この手順では、次の構成パラメータを使用します。
レルム名 = EXAMPLE.COM
DNS ドメイン名 = example.com
マスター KDC = kdc1.example.com
スレーブ KDC = kdc2.example.com and kdc3.example.com
admin 主体 = kws/admin
オンラインヘルプ URL = http://denver:8888/ab2/coll.384.1/SEAM/@AB2PageView/6956
この URL は「Kerberos グラフィカル管理ツール」のセクションを指すように調整してください (「Kerberos グラフィカル管理ツールでのオンラインヘルプ URL」を参照)。
マスター KDC が構成済みである必要があります。スレーブ KDC を入れ替え可能にする手順については、「マスター KDC とスレーブ KDC の入れ替え」を参照してください。
マスター KDC 上でスーパーユーザーになります。
マスター KDC 上で kadmin を起動します。
マスター KDC を構成するときに作成した admin 主体名を使用して、ログインする必要があります。
kdc1 # /usr/sbin/kadmin -p kws/admin Enter password: <Type kws/admin password> kadmin: |
マスター 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 } |
マスター 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 |
すべてのスレーブ KDC 上で、KDC 管理ファイルをマスター KDC サーバーからコピーします。
この手順は、マスター KDC サーバーが、各 KDC サーバーに必要な情報を更新したため、すべてのスレーブ KDC 上で実行する必要があります。ftp などの転送メカニズムを使用して、マスター KDC から次のファイルのコピーを取得できます。
/etc/krb5/krb5.conf
/etc/krb5/kdc.conf
/etc/krb5/kpropd.acl
すべてのスレーブ KDC 上で、Kerberos アクセス制御リストファイル kadm5.acl が反映されていないことを確認してください。
修正前の kadm5.acl ファイルは次のようになっています。
kdc2 # cat /etc/krb5/kadm5.acl */admin@___default_realm___ * |
ファイルに kiprop のエントリがある場合は、それを削除します。
新しいスレーブ上で、kadmin コマンドを起動します。
マスター KDC を構成するときに作成した admin 主体名を使用して、ログインする必要があります。
kdc2 # /usr/sbin/kadmin -p kws/admin Enter password: <Type kws/admin password> kadmin: |
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: |
kadmin を終了します。
kadmin: quit |
マスター 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 に開始します。
新しいスレーブ上で、Kerberos 伝播デーモンを起動します。
kdc3 # svcadm enable network/security/krb5_prop |
マスター KDC 上で、kprop_script を使ってデータベースをバックアップし、伝播します。
データベースのバックアップコピーがすでに使用可能な場合は、別のバックアップを完成させる必要はありません。詳細は、「Kerberos データベースをスレーブ KDC に手動で伝播する方法」を参照してください。
kdc1 # /usr/lib/krb5/kprop_script kdc3.example.com Database propagation to kdc3.example.com: SUCCEEDED |
新しいスレーブ上で、kdb5_util を使用して stash ファイルを作成します。
kdc3 # /usr/sbin/kdb5_util stash kdb5_util: Cannot find/read stored master key while reading master key kdb5_util: Warning: proceeding without master key Enter KDC database master key: <Type the key> |
(省略可能) 新しいスレーブ KDC 上で、NTP などのクロック同期メカニズムを使用して、マスター KDC のクロックを同期化します。
Network Time Protocol (NTP) のインストールと使用は必要はありません。ただし、認証が正常終了するには、krb5.conf ファイルの libdefaults セクションに定義されているデフォルト時間内に収まるよう、すべてのクロックを調整する必要があります。NTP については、「KDC と Kerberos クライアントのクロックの同期化」を参照してください。
新しいスレーブ上で、KDC デーモン (krb5kdc) を起動します。
kdc3 # svcadm enable network/security/krb5kdc |
増分伝播が構成されている場合、この手順は、スレーブ KDC 上の情報が更新されたかを確認します。
KDC マスターサーバー上で、kproplog コマンドを実行します。
kdc1 # /usr/sbin/kproplog -h |
KDC スレーブサーバー上で、kproplog コマンドを実行します。
kdc2 # /usr/sbin/kproplog -h |
最終シリアル番号と最終時刻表示の値が一致するかを確認します。
次の例は、マスター 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 スレーブサーバーはそれらの情報を取り込みません。
この手順では、kprop コマンドを使用して、Kerberos データベースを伝播します。定期的に実行する cron ジョブ以外に、スレーブ KDC とマスター KDC を同期化する必要がある場合は、この手順を行います。kprop_script と異なり、kprop を使用した場合は、現在のデータベースバックアップだけを伝播できます。伝播する前に、Kerberos データベースの新しいバックアップは作成されません。
増分伝播を使用する場合は、この手順を使用しないでください。
マスター KDC 上でスーパーユーザーになります。
(省略可能) kdb5_util コマンドを使用して、データベースをバックアップします。
# /usr/sbin/kdb5_util dump /var/krb5/slave_datatrans |
kprop コマンドを使用して、データベースをスレーブ KDC に伝播します。
# /usr/lib/krb5/kprop -f /var/krb5/slave_datatrans slave-KDC |
定期的に実行する cron ジョブ以外に、データベースをバックアップし、そのファイルをスレーブ KDC に伝播する場合は、次のように kprop_script コマンドを使用することもできます。
# /usr/lib/krb5/kprop_script slave-KDC |
ほとんどの場合、マスター KDC は、Kerberos データベースをスレーブ KDC に伝播するときにだけ使用されます。使用するサイトに複数のスレーブ KDC が存在する場合は、伝播処理の負荷を分散させることもできます。この概念は、「並列伝播」と呼ばれます。
増分伝播を使用する場合は、この手順を使用しないでください。
並列伝播を利用すると、複数のスレーブ KDC 間でマスター KDC の伝播処理を分散できます。処理を分散すると、伝播をより早く実行でき、マスター KDC の作業を軽減することができます。
たとえば、使用するサイトに 1 つのマスター KDC と 6 つのスレーブ KDC があるとします (図 23–2 を参照)。slave-1 から slave-3 で 1 つの論理グループを構成し、slave-4 から slave-6 で別の論理グループを構成しています。並列伝播を設定するには、マスター KDC がデータベースを slave-1 と slave-4 に伝播し、これらのスレーブ KDC がグループ内のスレーブ KDC にデータベースを伝播するようにします。
ここでは、並列伝播の詳細な手順は説明しませんが、並列伝播を有効にする構成手順の概要を示します。手順は次のとおりです。
マスター KDC 上で、cron ジョブ内の kprop_script エントリを変更して、次の伝播先のスレーブ KDC ( 伝播スレーブ) だけを引数に指定します。
伝播スレーブごとに、kprop_script エントリをその cron ジョブに追加し、伝播先のスレーブを引数に指定します。並列伝播を正しく行うには、伝播スレーブが新しい Kerberos データベースから伝播されたあとに、cron ジョブが実行されるように設定する必要があります。
伝播スレーブにかかる伝播時間は、ネットワークの帯域幅や Kerberos データベースのサイズなどの要因によって異なります。
スレーブ KDC ごとに、伝播に必要なアクセス権を設定します。伝播元の KDC のホスト主体名を各スレーブ KDC の kpropd.acl ファイルに追加します。
図 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 ファイル」には、Kerberos データベースのマスター鍵が含まれます。このファイルは、Kerberos データベースを作成すると自動的に作成されます。stash ファイルが壊れた場合は、kdb5_util ユーティリティーの stash コマンドを使用して、置き換えることができます。kdb5_util の destroy コマンドを使用して Kerberos データベースを削除したときは、stash ファイルも削除する必要があります。データベースを削除しても、stash ファイルは自動的に削除されないため、クリーンアップを完了するには、stash ファイルを削除する必要があります。
stash ファイルが配置されている KDC の上でスーパーユーザーになります。
stash ファイルを削除します。
# rm stash-file |
この例では、stash-file は stash ファイルのパスを示します。デフォルトでは、stash ファイルは /var/krb5/.k5.realm にあります。
stash ファイルを再作成する場合は、kdb5_util コマンドの -f オプションを使用します。
LDAP ディレクトリサーバーを使用した KDC 管理作業のほとんどは、DB2 サーバーを使用した場合と同じです。LDAP を使用した処理に特有の新しい作業がいくつかあります。
表 23–3 LDAP を使用するための KDC サーバーの構成 (作業マップ)
タスク |
説明 |
参照先 |
---|---|---|
マスター KDC を構成します。 |
手動のプロセスを使用し、さらに KDC 用に LDAP を使用して、レルムにマスター KDC サーバーとデータベースを構成および構築します。 | |
Kerberos 主体属性を Kerberos 以外のオブジェクトクラス型と結び付けます |
Kerberos レコードで格納された情報をほかの LDAP データベースと共有できるようになります。 | |
レルムを破棄します。 |
レルムに関連付けられたデータをすべて削除します。 |
この手順により、Kerberos 主体属性を Kerberos 以外のオブジェクトクラス型に関連付けることができます。この手順では、krbprincipalaux、krbTicketPolicyAux、および krbPrincipalName 属性が people オブジェクトクラスに関連付けられます。
この手順では、次の構成パラメータを使用します。
ディレクトリサーバー = dsserver.example.com
ユーザー主体 = willf@EXAMPLE.COM
スーパーユーザーになります。
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 |
サブツリー属性をレルムコンテナに追加します。
この手順により、デフォルトの 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 |
(省略可能) KDC レコードが DB2 に格納されている場合は、DB2 エントリを移行します。
(省略可能) 主体属性を KDC に追加します。
# kadmin.local -q 'addprinc willf' |
この手順は、別の LDAP ディレクトリサーバーがレルムを処理するように構成されている場合に使用できます。
Kerberos アプリケーションサーバーと KDC サーバーのセキュリティーを強化するには、次の手順に従ってください。
表 23–4 Kerberos サーバーのセキュリティーの強化 (作業マップ)
タスク |
説明 |
説明 |
---|---|---|
Kerberos 認証を使用してアクセスを有効にします。 |
ネットワークアクセスを制限し、サーバーで Kerberos 認証のみが許可されるようにします。 | |
KDC サーバーへのアクセスを制限します。 |
KDC サーバーとそのデータのセキュリティーを強化します。 | |
辞書ファイルを使用してパスワードセキュリティーを強化します。 |
新しいパスワードを辞書と照合してパスワードのセキュリティーを強化します。 |
この手順を実行すると、telnet、ftp、rcp、rsh、および rlogin を実行しているサーバーへのネットワークアクセスが、Kerberos 認証されたトランザクションだけを使用するネットワークアクセスに制限されます。
telnet サービスの exec プロパティーを変更します。
telnet の exec プロパティーに -a user オプションを追加すると、有効な認証情報を提供できるユーザーにアクセスが制限されます。
# inetadm -m svc:/network/telnet:default exec="/usr/sbin/in.telnetd -a user" |
(省略可能) まだ構成されていない場合は、telnet サービスのexec のプロパティーを変更します。
ftp の exec プロパティーに -a オプションを追加すると、Kerberos 認証された接続のみが許可されます。
# inetadm -m svc:/network/ftp:default exec="/usr/sbin/in.ftpd -a" |
他のサービスを無効にします。
in.rshd と in.rlogind デーモンを無効にする必要があります。
# svcadm disable network/shell # svcadm disable network/login:rlogin |
マスター KDC およびスレーブ KDC には、KDC データベースのローカルコピーがあります。データベースを保護するためにこれらのサーバーへのアクセス権を制限することは、Kerberos 全体のセキュリティーにとって重要です。
必要に応じて、遠隔サービスを無効にします。
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 |
KDC をサポートするハードウェアに対するアクセスを制限します。
物理的なアクセスを制限するために、KDC とそのモニターは安全な場所に設置します。このサーバーへのアクセスを完全に制限することが目的です。
KDC データベースのバックアップを、ローカルディスクまたはスレーブ KDC に格納します。
KDC のバックアップをテープに作成する場合、そのテープのセキュリティーを十分に確保してください。キータブファイルのコピーも、同様に作成します。これらのファイルをローカルファイルシステムに格納する場合は、できるだけほかのシステムと共有しないでください。格納先のファイルシステムは、マスター KDC または任意のスレーブ KDC から選択できます。
Kerberos サービスで辞書ファイルを使用することにより、新しい資格の作成時に辞書内の単語がパスワードとして使用されるのを防ぐことができます。辞書の用語がパスワードとして使用されないようにすると、パスワードの推測が困難になります。デフォルトでは /var/krb5/kadm5.dict ファイルが使用されますが、これは空です。
マスター KDC 上でスーパーユーザーになります。
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 } |
Kerberos デーモンを再起動します。
kdc1 # svcadm restart -r network/security/krb5kdc kdc1 # svcadm restart -r network/security/kadmin |
この章では、Kerberos サービスを使用するときに発生するエラーメッセージの解決策を説明します。また、さまざまな問題を解決するためのヒントについても説明します。次に、この章で説明するエラーメッセージと障害追跡方法の一覧を示します。
この節では、Kerberos のエラーメッセージ、エラーの発生原因、およびその対処方法について説明します。
主体またはポリシーのリストにアクセスできません; 「名前」フィールドを使用してください。(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 コマンド、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 がサポートしない暗号化タイプをクライアントが要求する場合があります。
対処方法:この問題を解決するための対処方法がいくつか用意されています。もっとも簡単に実行できる方法を次に示します。
SUNWcry および SUNWcryr パッケージを KDC サーバーに追加します。これにより、KDC がサポートする暗号化タイプの数が増えます。
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 コマンド、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 ソフトウェアの障害追跡について説明します。
krb5.conf ファイルの書式が正しくない場合、次のエラーメッセージが端末またはログファイルに表示されることがあります。
Improper format of Kerberos /etc/krb5/krb5.conf configuration file while initializing krb5 library |
krb5.conf ファイルの書式に問題があると、関連するサービスへの接続が容易になる危険があります。この問題を解決しないと、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 ファイルシステムのマウントに失敗した場合には、NFS サーバーに /var/rcache/root ファイルが存在することを確認してください。ファイルシステムの所有者が root でない場合は、削除してから再度マウントします。
Kerberos NFS ファイルシステムへのアクセスに問題がある場合は、使用するシステムと NFS サーバー上で gssd サービスが有効になっていることを確認してください。
Kerberos NFS ファイルシステムにアクセスしようとしたときに invalid argument または bad directory のエラーメッセージが表示された場合は、NFS ファイルシステムをマウントするときに完全指定形式の DNS 名を使用していない可能性があります。マウントされているホストが、サーバーのキータブファイル内のサービス主体名に含まれるホスト名と一致していません。
また、複数の Ethernet インタフェースを実装したサーバーに DNS を設定するときに、ホスト単位に複数のアドレスレコードを割り当てずに、インタフェース単位に名前を割り当てた場合にも、この問題が発生します。Kerberos サービスの場合は、次のようにホスト単位に複数のアドレスレコードを設定する必要があります。 [Ken Hornstein, “Kerberos FAQ,” [http://www.cmf.nrl.navy.mil/CCS/people/kenh/kerberos-faq.html#kerbdns], accessed 10 March 2010.] :
my.host.name. A 1.2.3.4 A 1.2.4.4 A 1.2.5.4 my-en0.host.name. A 1.2.3.4 my-en1.host.name. A 1.2.4.4 my-en2.host.name. A 1.2.5.4 4.3.2.1 PTR my.host.name. 4.4.2.1 PTR my.host.name. 4.5.2.1 PTR my.host.name.
この例の設定では、インタフェースごとに 1 つの参照が割り当てられます。また、サーバーのキータブファイル内で、3 つのサービス主体の代わりに、1 つのサービス主体を使用できます。
使用するシステムのスーパーユーザーになるときの認証に失敗し、ホストのキータブファイルに root 主体がすでに追加されている場合は、2 つの問題を確認する必要があります。まず、キータブファイル内の root 主体が、そのインスタンスとして完全指定形式名であることを確認します。完全指定形式名の場合は、/etc/resolv.conf ファイルを確認して、システムが DNS クライアントとして正しく設定されていることを確認してください。
資格マッピングを監視するには、最初に、/etc/gss/gsscred.conf ファイルの次の行をコメント解除します。
SYSLOG_UID_MAPPING=yes |
次に、gssd サービスに/etc/gss/gsscred.conf ファイルから情報を取得するように指示します。
# pkill -HUP gssd |
これで、gssd が資格マッピングを要求するときにそれを監視できるようになります。syslog.conf ファイルが debug 重要度を扱う auth システム機能用に構成されている場合、syslogdを使用してマッピングを記録できます。
この章では、主体とそれに関連するポリシーを管理する手順について説明します。また、ホストのキータブファイルの管理方法についても説明します。
この章は、主体とポリシーを管理する必要のあるユーザーを対象にしています。主体とポリシーを計画するときの考慮事項など、主体とポリシーについて理解している必要があります。第 21 章Kerberos サービスについてと第 22 章Kerberos サービスの計画を参照してください。
この章で説明する情報は次のとおりです。
マスター KDC の Kerberos データベースには、使用するレルムの Kerberos 主体、そのパスワード、ポリシーなどの管理情報がすべて含まれています。主体を作成または削除したり、主体の属性を変更したりするには、kadmin または gkadmin コマンドのいずれかを使用します。
kadmin コマンドには、対話型のコマンド行インタフェースが用意されています。このインタフェースを使用して、Kerberos 主体、ポリシー、およびキータブファイルを管理することができます。kadmin コマンドには、次の 2 つの種類があります。
Kerberos を使用してユーザーを認証する点を除いて、2 つの kadmin の機能は同じです。kadmin に必要なデータベースを設定するときは、kadmin.local を使用します。
Solaris リリースには、SEAM 管理ツール (gkadmin) も用意されています。このツールは対話型のグラフィカルユーザーインタフェース (GUI) で、基本的に kadmin コマンドと同じ機能を持ちます。詳細は、「SEAM 管理ツール」を参照してください。
SEAM 管理ツール (SEAM ツール) は、対話型グラフィカルユーザーインタフェース (GUI) で、Kerberos 主体とポリシーを管理することができます。このツールは、kadmin コマンドと同じ機能を持ちます。ただし、キータブファイルの管理はサポートしません。キータブファイルを管理するには、kadmin コマンドを使用する必要があります (「キータブファイルの管理」を参照)。
kadmin コマンドと同様に、SEAM Toolは、Kerberos 認証と暗号化された RPC を使用して、ネットワーク上の任意の場所から安全に操作することができます。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 ツールが変更するファイルは、$HOME/.gkadmin ファイルだけです。このファイルには、新しい主体を作成するときのデフォルト値が含まれます。このファイルを更新するには、「Edit」メニューから「Properties」を選択します。
SEAM ツールには、印刷機能とオンラインヘルプ機能が用意されています。「Print」メニューから、次の要素をプリンタまたはファイルに送信できます。
指定したマスター KDC で使用できる主体の一覧
指定したマスター KDC で使用できるポリシーの一覧
現在選択されている主体または読み込まれている主体
「Help」メニューから、コンテキストヘルプと通常のヘルプを使用できます。「Help」メニューから「Context-Sensitive Help」を選択すると、「Context-Sensitive Help」ウィンドウが表示され、ツールがヘルプモードに切り替わります。ヘルプモードのウィンドウで、任意のフィールド、ラベル、またはボタンをクリックすると、「Help」ウィンドウにその項目のヘルプが表示されます。ツールの通常モードに戻るには、「Help」ウィンドウで「Dismiss」をクリックします。
また、「Help Contents」を選択すると、HTML ブラウザが開き、この章で説明している概要や操作情報が表示されます。
登録した主体とポリシーが増加するにつれて、SEAM ツールが主体とポリシーを読み込んでそれらの一覧を表示する時間が長くなります。このため、ツールによる作業効率が低下します。この問題には、いくつかの対応方法があります。
まず、一覧を読み込む時間を完全になくすために、SEAM ツールに一覧を読み込まないようにします。この方法を設定するには、「Edit」メニューから「Properties」を選択し、「Show Lists」フィールドのチェックマークをはずします。一覧を読み込まない場合、一覧は表示されないため、一覧を使用して主体またはポリシーを選択できなくなります。代わりに、表示された新しい「Name」フィールドに主体またはポリシー名を入力し、その主体またはポリシーに適用する操作を選択する必要があります。名前を入力する操作は、一覧から項目を選択する操作と同じ効果を持ちます。
大規模な一覧を使用するときは、キャッシュを利用することもできます。SEAM ツールのデフォルトの動作として、一定量の一覧がキャッシュに格納されるように設定されています。SEAM ツールは、最初に一覧をキャッシュに読み込む必要がありますが、そのあとは一覧を再度読み込まずにキャッシュを使用できます。この方法では、サーバーから時間をかけて何回も一覧を読み込む必要がありません。
一覧がキャッシュに格納されるように設定するには、「Edit」メニューから「Properties」を選択します。キャッシュの設定には、次の 2 つの方法があります。一覧をキャッシュに永続的に格納するか、制限時間を指定します。制限時間を指定した場合は、その時間が経過すると、ツールはサーバーの一覧をキャッシュに再度読み込みます。
一覧をキャッシュに格納しても、一覧から主体とポリシーを選択することができます。このため、一覧を読み込まない最初の方法と異なり、SEAM ツールの利用には影響しません。また、キャッシュを利用した場合でも、ほかの主体とポリシーの変更を確認できなくなることがあります。ただし、使用している主体とポリシーを変更したときは最新の一覧が表示されます。主体とポリシーを変更すると、サーバーとキャッシュの一覧が更新されるためです。キャッシュを更新して、ほかの主体とポリシーの変更を確認し、最新の一覧を取得するには、任意のタイミングで「Refresh」メニューを使用します。サーバーから一覧が読み込まれ、キャッシュを更新することができます。
gkadmin コマンドを使用して SEAM ツールを起動します。
$ /usr/sbin/gkadmin |
デフォルト値を使用しない場合は、新しいデフォルト値を指定します。
ウィンドウには、デフォルト値が自動的に表示されています。デフォルトの主体名は、USER 環境変数の現在の ID に /admin が付加されて作成されます (username/admin)。デフォルトの「Realm」フィールドおよび「Master KDC」フィールドは、/etc/krb5/krb5.conf ファイルから選択されます。デフォルト値を再度取得する場合は、「Start Over」をクリックします。
各「Principal Name」が実行できる管理操作は、Kerberos ACL ファイルの /etc/krb5/kadm5.acl で規定されます。権限の制限については、「Kerberos 管理権限を制限して SEAM ツールを使用する」を参照してください。
指定した主体名のパスワードを入力します。
「了解 (OK)」をクリックします。
ウィンドウが表示され、すべての主体が示されます。
この節では、SEAM ツールを使用して主体を管理する手順について説明します。また、対応するコマンド行がある場合は、その例も示します。
作業 |
説明 |
参照先 |
---|---|---|
主体の一覧を表示します。 |
「Principals」タブをクリックして、主体の一覧を表示します。 | |
主体の属性を表示します。 |
「Principal List」の「Principal」を選択し、「Modify」ボタンをクリックして、主体の属性を表示します。 | |
新しい主体を作成します。 |
「Principal List」パネルの「Create New」ボタンをクリックして、新しい主体を作成します。 | |
主体を複製します。 |
「Principal List」から複製する主体を選択し、「Duplicate」ボタンをクリックして、主体を複製します。 | |
主体を変更します。 |
「Principal List」から変更する主体を選択し、「Modify」ボタンをクリックして、主体を変更します。 主体名は変更できません。主体名を変更するときは、主体を複製し、新しい名前を指定して保存してから、古い主体を削除する必要があります。 | |
主体を削除します。 |
「Principal List」から削除する主体を選択し、「Delete」ボタンをクリックして、主体を削除します。 | |
新しい主体を作成するときのデフォルトを設定します。 |
「Edit」メニューから「Properties」を選択して、新しい主体を作成するときのデフォルトを設定します。 | |
Kerberos 管理権限 (kadm5.acl ファイル) を変更します。 |
コマンド行のみ。Kerberos 管理権限により、主体が Kerberos データベースに対して実行できる操作 (追加、変更など) が決定されます。 各主体の Kerberos 管理権限を変更するときは、/etc/krb5/kadm5.acl ファイルを編集する必要があります。 |
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 ファイル内のパスワードのセキュリティーが向上します。
より複雑なスクリプトも作成できます。たとえば、ネームサービスの情報を使用して、主体名に対応するユーザー名の一覧を取得できます。必要な作業とその方法は、使用環境要件とスクリプト使用技術によって決まります。
対応するコマンド行の例は、この手順のあとに示します。
必要に応じて、SEAM ツールを起動します。
詳細は、「SEAM ツールを起動する方法」を参照してください。
$ /usr/sbin/gkadmin |
「Principals」タブをクリックします。
主体の一覧が表示されます。
特定の主体を表示するか、主体の部分リストを表示します。
「Filter」フィールドにフィルタ文字列を入力して、Return キーを押します。フィルタが正常終了すると、フィルタに一致する主体の一覧が表示されます。
フィルタ文字列は、1 文字以上の文字列である必要があります。フィルタメカニズムでは大文字と小文字が区別されるため、大文字と小文字を正しく指定する必要があります。たとえば、フィルタ文字列に ge と入力すると、主体名に文字列 ge を含む主体 (george、edge など) だけが表示されます。
すべての主体を表示するには、「Clear Filter」をクリックします。
次の例では、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 |
対応するコマンド行の例は、この手順のあとに示します。
必要に応じて、SEAM ツールを起動します。
詳細は、「SEAM ツールを起動する方法」を参照してください。
$ /usr/sbin/gkadmin |
「Principals」タブをクリックします。
表示する主体を一覧から選択して、「Modify」をクリックします。
「Principal Basic」パネルが表示され、主体の属性の一部が示されます。
「Next」をクリックして、主体のすべての属性を表示します。
属性情報は、3 つのウィンドウに表示されます。「Help」メニューから「Context-Sensitive Help」を選択すると、各ウィンドウの属性に関する情報が表示されます。主体のすべての属性の説明については、「SEAM ツールパネルの説明」を参照してください。
表示を終了する場合は、「Cancel」をクリックします。
次の例は、jdb/admin 主体を表示したときの最初のウィンドウです。
次の例では、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 |
対応するコマンド行の例は、この手順のあとに示します。
必要に応じて、SEAM ツールを起動します。
詳細は、「SEAM ツールを起動する方法」を参照してください。
新しい主体を作成するときに、新しいポリシーが必要な場合は、新しいポリシーを作成してから新しい主体を作成する必要があります。「新しい Kerberos ポリシーを作成する方法」を参照してください。
$ /usr/sbin/gkadmin |
「Principals」タブをクリックします。
「New」をクリックします。
「Principal Basics」パネルが表示され、主体の属性の一部が示されます。
主体名とパスワードを指定します。
主体名とパスワードは必須です。
主体の暗号化タイプを指定します。
暗号化鍵タイプフィールドの右にあるボックスをクリックして、使用可能なすべての暗号化鍵タイプを表示する新しいウィンドウを開きます。必須の暗号化タイプを選択してから、「OK」をクリックします。
主体のポリシーを指定します。
主体の属性に値を指定します。「Next」をクリックして、属性の値を必要に応じて指定します。
属性情報は、3 つのウィンドウに表示されます。「Help」メニューから「Context-Sensitive Help」を選択すると、各ウィンドウの属性に関する情報が表示されます。主体のすべての属性の説明については、「SEAM ツールパネルの説明」を参照してください。
主体を保存する場合は、「Save」をクリックします。または、最後のパネルで「Done」をクリックします。
必要に応じて、新しい主体の Kerberos 管理権限を /etc/krb5/kadm5.acl ファイルに設定します。
詳細は、「Kerberos 管理権限を変更する方法」を参照してください。
次の例は、pak という新しい主体を作成するときの「Principal Basics」パネルです。ポリシーには、testuser が設定されています。
次の例では、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 |
この手順では、既存の主体の一部またはすべてを使用して、新しい主体を作成する方法について説明します。この手順に対応するコマンド行はありません。
必要に応じて、SEAM ツールを起動します。
詳細は、「SEAM ツールを起動する方法」を参照してください。
$ /usr/sbin/gkadmin |
「Principals」タブをクリックします。
複製する主体を一覧から選択して、「Duplicate」をクリックします。
「Principal Basics」パネルが表示されます。選択した主体のすべての属性が複製されます。ただし、「Principal Name」と「Password」フィールドは複製されず、空で表示されます。
主体名とパスワードを指定します。
主体名とパスワードは必須です。選択した主体をそのまま複製するときは、「Save」をクリックして、手順 7 に進みます。
主体の属性に別の値を指定します。「Next」をクリックして、属性の値を必要に応じて指定します。
属性情報は、3 つのウィンドウに表示されます。「Help」メニューから「Context-Sensitive Help」を選択すると、各ウィンドウの属性に関する情報が表示されます。主体のすべての属性の説明については、「SEAM ツールパネルの説明」を参照してください。
主体を保存する場合は、「Save」をクリックします。または、最後のパネルで「Done」をクリックします。
必要に応じて、主体の Kerberos 管理権限を /etc/krb5/kadm5.acl ファイルに設定します。
詳細は、「Kerberos 管理権限を変更する方法」を参照してください。
対応するコマンド行の例は、この手順のあとに示します。
必要に応じて、SEAM ツールを起動します。
詳細は、「SEAM ツールを起動する方法」を参照してください。
$ /usr/sbin/gkadmin |
「Principals」タブをクリックします。
変更する主体を一覧から選択して、「Modify」をクリックします。
「Principal Basic」パネルが表示され、主体の属性の一部が示されます。
主体の属性を変更します。「Next」をクリックして、必要に応じて属性を変更します。
属性情報は、3 つのウィンドウに表示されます。「Help」メニューから「Context-Sensitive Help」を選択すると、各ウィンドウの属性に関する情報が表示されます。主体のすべての属性の説明については、「SEAM ツールパネルの説明」を参照してください。
主体名は変更できません。主体名を変更するときは、主体を複製し、新しい名前を指定して保存してから、古い主体を削除する必要があります。
主体を保存する場合は、「Save」をクリックします。または、最後のパネルで「Done」をクリックします。
/etc/krb5/kadm5.acl ファイルで、主体の Kerberos 管理権限を変更します。
詳細は、「Kerberos 管理権限を変更する方法」を参照してください。
次の例では、kadmin の change_password コマンドを使用して、jdb 主体のパスワードを変更します。change_password コマンドでは、主体のパスワード履歴に存在するパスワードには変更できません。
kadmin: change_password jdb Enter password for principal "jdb": <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 コマンドを使用する必要があります。
対応するコマンド行の例は、この手順のあとに示します。
必要に応じて、SEAM ツールを起動します。
詳細は、「SEAM ツールを起動する方法」を参照してください。
$ /usr/sbin/gkadmin |
「Principals」タブをクリックします。
削除する主体を一覧から選択して、「Delete」をクリックします。
削除を確定すると、主体が削除されます。
Kerberos アクセス制御リスト (ACL) ファイル /etc/krb5/kadm5.acl から主体を削除します。
詳細は、「Kerberos 管理権限を変更する方法」を参照してください。
次の例では、kadmin の delete_principal コマンドを使用して、jdb 主体を削除します。
kadmin: delete_principal pak Are you sure you want to delete the principal "pak@EXAMPLE.COM"? (yes/no): yes Principal "pak@EXAMPLE.COM" deleted. Make sure that you have removed this principal from all ACLs before reusing. kadmin: quit |
この手順に対応するコマンド行はありません。
必要に応じて、SEAM ツールを起動します。
詳細は、「SEAM ツールを起動する方法」を参照してください。
$ /usr/sbin/gkadmin |
「Edit」メニューから「Properties」を選択します。
「Properties」ウィンドウが表示されます。
新しい主体を作成するときに使用するデフォルトを選択します。
「Help」メニューから「Context-Sensitive Help」を選択すると、各ウィンドウの属性に関する情報が表示されます。
「Save」をクリックします。
使用する環境には、多くのユーザー主体が登録されていると思われます。しかし、Kerberos データベースの管理者は通常、少数のユーザーだけに割り当てます。Kerberos データベースを管理する権限は、Kerberos アクセス制御リスト (ACL) ファイル (kadm5.acl) によって判断されます。kadm5.acl ファイルを使用すると、主体ごとに権限を設定できます。主体名にワイルドカード (*) を使用すると、複数の主体に権限を指定できます。
マスター KDC 上でスーパーユーザーになります。
/etc/krb5/kadm5.acl ファイルを編集します。
kadm5.acl ファイルのエントリは、次の書式で記述する必要があります。
principal privileges [principal-target] |
principal |
権限を与える主体を指定します。主体名の任意の場所にワイルドカード (*) を使用できます。複数の主体グループに同じ権限を与えるときに使用します。たとえば、admin インスタンスを持つすべての主体を指定する場合は、*/admin@realm を使用します。 admin インスタンスは通常、個別の権限 (Kerberos データベースへの管理アクセス権など) を個別の Kerberos 主体に許可するときに使用します。たとえば、ユーザー jdb が、jdb/admin という管理目的の主体を持つとします。この場合、ユーザー jdb は、この権限を実際に使用するときにだけ、jdb/admin チケットを取得します。 |
|
privileges |
主体が実行できる操作または実行できない操作を指定します。このフィールドは、次に示す 1 つまたは複数の文字列 (またはその大文字) の組み合わせから構成されます。大文字の指定、または指定なしは許可されません。小文字の指定は許可されます。 |
|
|
a |
主体またはポリシーの追加を許可する/しない。 |
|
d |
主体またはポリシーの削除を許可する/しない。 |
|
m |
主体またはポリシーの変更を許可する/しない。 |
|
c |
主体のパスワードの変更を許可する/しない。 |
|
i |
Kerberos データベースの照会を許可する/しない。 |
|
l |
Kerberos データベース内の主体またはポリシーの一覧表示を許可する/しない。 |
|
x または * |
すべての権限 (admcil) を許可する。 |
principal-target |
このフィールドに主体を指定すると、principal の操作が principal-target の場合にだけ、privileges が principal に適用されます。主体名の任意の場所にワイルドカード (*) を使用できます。主体をグループ化するときに使用します。 |
kadm5.acl ファイル内の次のエントリは、EXAMPLE.COM レルム内で admin インスタンスを持つ すべての主体に対して、Kerberos データベース上のすべての権限を与えます。
*/admin@EXAMPLE.COM * |
kadm5.acl ファイル内の次のエントリは、jdb@EXAMPLE.COM 主体に対して、root インスタンスを持つすべての主体に関する追加、一覧表示、および照会の権限を与えます。
jdb@EXAMPLE.COM ali */root@EXAMPLE.COM |
この節では、SEAM ツールを使用してポリシーを管理する手順について説明します。また、対応するコマンド行がある場合は、その例も示します。
作業 |
説明 |
参照先 |
---|---|---|
ポリシーの一覧を表示します。 |
「Policies」タブをクリックして、ポリシーの一覧を表示します。 | |
ポリシーの属性を表示します。 |
「Policy List」からポリシーを選択し、「Modify」ボタンをクリックして、ポリシーの属性を表示します。 | |
新しいポリシーを作成します。 |
「Policy List」パネルの「Create New」ボタンをクリックして、新しいポリシーを作成します。 | |
ポリシーを複製します。 |
複製するポリシーを「Policy List」ポリシーから選択し、「Duplicate」ボタンをクリックして、ポリシーを複製します。 | |
ポリシーを変更します。 |
変更するポリシーを「Policy List」ポリシーから選択し、「Modify」ボタンをクリックして、ポリシーを変更します。 ポリシー名は変更できません。ポリシー名を変更するときは、ポリシーを複製し、新しい名前を指定して保存してから、古いポリシーを削除する必要があります。 | |
ポリシーを削除します。 |
削除するポリシーを「Policy List」ポリシーから選択し、「Delete」ボタンをクリックして、ポリシーを削除します。 |
対応するコマンド行の例は、この手順のあとに示します。
必要に応じて、SEAM ツールを起動します。
詳細は、「SEAM ツールを起動する方法」を参照してください。
$ /usr/sbin/gkadmin |
「Policies」タブをクリックします。
ポリシーの一覧が表示されます。
特定のポリシーを表示するか、ポリシーの部分リストを表示します。
「Filter」フィールドにフィルタ文字列を入力して、Return キーを押します。フィルタが正常終了すると、フィルタに一致するポリシーの一覧が表示されます。
フィルタ文字列は、1 文字以上の文字列である必要があります。フィルタメカニズムでは大文字と小文字が区別されるため、大文字と小文字を正しく指定する必要があります。たとえば、フィルタ文字列に ge と入力すると、ポリシー名に文字列 ge を含むポリシー (george、edge など) だけが表示されます。
すべてのポリシーを表示するには、「Clear Filter」をクリックします。
次の例では、kadmin の list_policies コマンドを使用して、*user* と一致するすべてのポリシーを表示します。list_policies コマンドでは、ワイルドカードを使用できます。
kadmin: list_policies *user* testuser enguser kadmin: quit |
対応するコマンド行の例は、この手順のあとに示します。
必要に応じて、SEAM ツールを起動します。
詳細は、「SEAM ツールを起動する方法」を参照してください。
$ /usr/sbin/gkadmin |
「Policies」タブをクリックします。
表示するポリシーを一覧から選択して、「Modify」をクリックします。
「Policy Details」パネルが表示されます。
表示を終了する場合は、「Cancel」をクリックします。
次の例は、test ポリシーを表示したときの「Policy Details」パネルです。
次の例では、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」は、このポリシーを使用する主体の数です。
対応するコマンド行の例は、この手順のあとに示します。
必要に応じて、SEAM ツールを起動します。
詳細は、「SEAM ツールを起動する方法」を参照してください。
$ /usr/sbin/gkadmin |
「Policies」タブをクリックします。
「New」をクリックします。
「Policy Details」パネルが表示されます。
「Policy Name」フィールドにポリシー名を指定します。
ポリシー名は必須です。
ポリシーの属性の値を指定します。
「Help」メニューから「Context-Sensitive Help」を選択すると、このウィンドウの属性に関する情報が表示されます。ポリシーのすべての属性の説明については、表 25–5 を参照してください。
「Save」をクリックしてポリシーを保存するか、「Done」をクリックします。
次の例では、build11 という新しいポリシーを作成します。「Minimum Password Classes」は、3 に設定されています。
次の例では、kadmin の add_policy コマンドを使用して、build11 ポリシーを作成します。このポリシーのパスワードには、3 種類以上の文字クラスが必要です。
$ kadmin kadmin: add_policy -minclasses 3 build11 kadmin: quit |
この手順では、既存のポリシーの一部またはすべてを使用して、新しいポリシーを作成する方法について説明します。この手順に対応するコマンド行はありません。
必要に応じて、SEAM ツールを起動します。
詳細は、「SEAM ツールを起動する方法」を参照してください。
$ /usr/sbin/gkadmin |
「Policies」タブをクリックします。
複製するポリシーを一覧から選択して、「Duplicate」をクリックします。
「Policy Details」パネルが表示されます。選択したフィールドのすべての属性が複製されます。ただし、「Policy Name」フィールドは空で表示されます。
複製するポリシー名を「Policy Name」フィールドに指定します。
ポリシー名は必須です。選択したポリシーをそのまま複製するには、手順 6 に進みます。
ポリシーの属性に別の値を指定します。
「Help」メニューから「Context-Sensitive Help」を選択すると、このウィンドウの属性に関する情報が表示されます。ポリシーのすべての属性の説明については、表 25–5 を参照してください。
「Save」をクリックしてポリシーを保存するか、「Done」をクリックします。
対応するコマンド行の例は、この手順のあとに示します。
必要に応じて、SEAM ツールを起動します。
詳細は、「SEAM ツールを起動する方法」を参照してください。
$ /usr/sbin/gkadmin |
「Policies」タブをクリックします。
変更するポリシーを一覧から選択して「Modify」をクリックします。
「Policy Details」パネルが表示されます。
ポリシーの属性を変更します。
「Help」メニューから「Context-Sensitive Help」を選択すると、このウィンドウの属性に関する情報が表示されます。ポリシーのすべての属性の説明については、表 25–5 を参照してください。
ポリシー名は変更できません。ポリシー名を変更するときは、ポリシーを複製し、新しい名前を指定して保存してから、古いポリシーを削除する必要があります。
「Save」をクリックしてポリシーを保存するか、「Done」をクリックします。
次の例では、kadmin の modify_policy コマンドを使用して、build11 ポリシーの最小パスワード長を 5 文字に変更します。
$ kadmin kadmin: modify_policy -minlength 5 build11 kadmin: quit |
対応するコマンド行の例は、この手順のあとに示します。
ポリシーを削除する前に、現在使用しているすべての主体からそのポリシーを取り消す必要があります。ポリシーを取り消すには、その主体の「Policy」属性を変更する必要があります。任意の主体が使用しているポリシーは、削除できません。
必要に応じて、SEAM ツールを起動します。
詳細は、「SEAM ツールを起動する方法」を参照してください。
$ /usr/sbin/gkadmin |
「Policies」タブをクリックします。
削除するポリシーを一覧から選択して、「Delete」をクリックします。
削除を確定すると、ポリシーが削除されます。
次の例では、kadmin の delete_policy コマンドを使用して、build11 ポリシーを削除します。
kadmin: delete_policy build11 Are you sure you want to delete the policy "build11"? (yes/no): yes kadmin: quit |
ポリシーを削除する前に、現在使用しているすべての主体からそのポリシーを取り消す必要があります。ポリシーを取り消すには、関係する主体に対して kadmin の modify_principal -policy コマンドを使用する必要があります。そのポリシーが主体に使用されている場合は、delete_policy コマンドは失敗します。
この節では、SEAM ツールの各パネルについて説明します。SEAM ツールで制限された権限を使用する方法についても説明します。
この節では、SEAM ツールで指定または表示できる主体とポリシーの属性について説明します。属性は、表示されるパネルごとに分類されています。
表 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 |
このポリシーが現在適用されている主体の数。(読み取り専用) |
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 コマンドを使用して、サービス主体をキータブファイルに追加します。 | |
キータブファイルからサービス主体を削除します。 |
kadmin の ktremove コマンドを使用して、キータブファイルからサービスを削除します。 | |
キータブファイル内のキー一覧 (主体の一覧) を表示します。 |
ktutil コマンドを使用して、キータブファイル内のキー一覧を表示します。 | |
ホスト上でのサービスの認証を一時的に無効にします。 |
この手順を行うと、kadmin 権限がなくても、ホスト上でのサービスの認証を一時的に無効にできます。 ktutil を使用してサーバーのキータブファイルからサービス主体を削除する前に、元のキータブファイルを一時的な位置にコピーする必要があります。サービスを再度有効にする場合は、元のキータブファイルを適切な場所に戻す必要があります。 |
主体がすでに Kerberos データベースに登録されていることを確認します。
詳細は、「Kerberos 主体の一覧を表示する方法」を参照してください。
キータブファイルに主体を追加するホスト上でスーパーユーザーになります。
kadmin コマンドを起動します。
# /usr/sbin/kadmin |
ktadd コマンドを使用して、キータブファイルに主体を追加します。
kadmin: ktadd [-e enctype] [-k keytab] [-q] [principal | -glob principal-exp] |
krb5.conf ファイルに定義された暗号化タイプの一覧を上書きします。
キータブファイルを指定します。デフォルトでは、/etc/krb5/krb5.keytab が使用されます。
冗長な情報を表示しません。
キータブファイルに追加する主体を指定します。追加できるサービス主体は、次のとおりです。 host、root、nfs、および ftp。
主体表現を指定します。principal-exp に一致するすべての主体が、キータブファイルに追加されます。主体表現の規則は、kadmin の list_principals コマンドと同じです。
kadmin コマンドを終了します。
kadmin: quit |
次の例では、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 |
キータブファイルから削除するサービス主体が登録されているホスト上でスーパーユーザーになります。
kadmin コマンドを起動します。
# /usr/sbin/kadmin |
(省略可能) キータブファイル内の現在の主体 (鍵) の一覧を表示するには、ktutil コマンドを使用します。
詳細な手順は、「キータブファイル内のキー一覧 (主体) を表示する方法」を参照してください。
ktremove コマンドを使用して、キータブファイルから主体を削除します。
kadmin: ktremove [-k keytab] [-q] principal [kvno | all | old ] |
キータブファイルを指定します。デフォルトでは、/etc/krb5/krb5.keytab が使用されます。
冗長な情報を表示しません。
キータブファイルから削除する主体を指定します。
指定された主体のうち、鍵のバージョン番号が kvno と一致する主体のすべてのエントリを削除します。
指定された主体のすべてのエントリを削除します。
指定した主体のすべてのエントリを削除します。ただし、鍵のバージョン番号が最上位の主体は削除しません。
kadmin コマンドを終了します。
kadmin: quit |
次の例では、denver の host 主体を denver のキータブファイルから削除します。
denver # /usr/sbin/kadmin kadmin: ktremove host/denver.example.com@EXAMPLE.COM kadmin: Entry for principal host/denver.example.com@EXAMPLE.COM with kvno 3 removed from keytab WRFILE:/etc/krb5/krb5.keytab. kadmin: quit |
キータブファイルが存在するホスト上でスーパーユーザーになります。
ほかのユーザーが所有するキータブファイルを作成することもできますが、キータブファイルのデフォルトの位置を使用するには root 所有権が必要です。
ktutil コマンドを起動します。
# /usr/bin/ktutil |
read_kt コマンドを使用して、キータブファイルをキー一覧バッファーに読み込みます。
ktutil: read_kt keytab |
list コマンドを使用して、キー一覧バッファーを表示します。
ktutil: list |
現在のキー一覧バッファーが表示されます。
ktutil コマンドを終了します。
ktutil: quit |
次の例では、denver ホストの /etc/krb5/krb5.keytab ファイル内のキー一覧を表示します。
denver # /usr/bin/ktutil ktutil: read_kt /etc/krb5/krb5.keytab ktutil: list slot KVNO Principal ---- ---- --------------------------------------- 1 5 host/denver@EXAMPLE.COM ktutil: quit |
ネットワークアプリケーションサーバー上の rlogin や ftp など、サービスの認証メカニズムを一時的に無効にしなければならない場合があります。たとえば、保守作業中は、ユーザーがシステムにログインできないようにする必要があります。ktutil コマンドを使用してサーバーのキータブファイルからサービス主体を削除することにより、サービスの認証を一時的に無効にすることができます。このとき、kadmin 権限は必要ありません。認証を再度有効にするには、保存した元のキータブファイルを元の位置にコピーするだけです。
デフォルトでは、ほとんどのサービスが認証を要求するように設定されています。そのように設定されていないときは、サービスの認証を無効にした場合でもサービスは動作します。
キータブファイルが存在するホスト上でスーパーユーザーになります。
ほかのユーザーが所有するキータブファイルを作成することもできますが、キータブファイルのデフォルトの位置を使用するには root 所有権が必要です。
現在のキータブファイルを一時ファイルに保存します。
ktutil コマンドを起動します。
# /usr/bin/ktutil |
read_kt コマンドを使用して、キータブファイルをキー一覧バッファーに読み込みます。
ktutil: read_kt keytab |
list コマンドを使用して、キー一覧バッファーを表示します。
ktutil: list |
現在のキー一覧バッファーが表示されます。無効にするサービスのスロット番号を記録します。
ホストのサービスを一時的に無効にするには、delete_entry コマンドを使用して、キー一覧バッファーから特定のサービス主体を削除します。
ktutil: delete_entry slot-number |
この例では、slot-number に、削除するサービス主体のスロット番号を指定します。スロット番号は、list コマンドで表示できます。
write_kt コマンドを使用して、新しいキー一覧バッファーをキータブファイルに書き込みます。
ktutil: write_kt new-keytab |
ktutil コマンドを終了します。
ktutil: quit |
新しいキータブファイルの名前を変更します。
# mv new-keytab keytab |
サービスを再度有効にする場合は、一時的な (元の) キータブファイルを元の場所にコピーします。
次の例では、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 |
この章は、Kerberos サービスが構成されているシステムのユーザーを対象としています。この章では、提供されている Kerberos コマンドとサービスの使用方法について説明します。この章を読み進めるには、これらのコマンド (Kerberos 以外) にすでに慣れ親しんでいる必要があります。
この章は一般的なユーザーを対象としているため、 チケットの取得、表示、および廃棄について説明します。また、Kerberos パスワードの選択または変更についても説明します。
この章の内容は次のとおりです。
Solaris Kerberos 製品の概要については、第 21 章Kerberos サービスについてを参照してください。
この節では、チケットの取得、表示、および破棄を行う方法を説明します。チケットの概要については、「Kerberos サービスの動作」を参照してください。
すべての SEAM リリースまたは Solaris 10 リリースがインストールされている場合、Kerberos は login に組み込まれており、チケットの取得はログイン時に自動的に行われます。Kerberos に対応するコマンドの rsh、rcp、rdist、telnet、および rlogin は通常、チケットのコピーをほかのマシンに転送するように設定されています。そうすると、ユーザーがチケットを明示的に要求しなくても、それらのマシンにアクセスできるようになるからです。これがデフォルトの動作ですが、特定のユーザーの構成はこの自動転送を含んでいない場合があります。チケットの転送については、「Kerberos コマンドの概要」および 「Kerberos チケットの転送」を参照してください。
チケットの有効期限については、「チケットの有効期限」を参照してください。
通常、PAM が適切に設定されている場合、ログインするとチケットが自動的に作成されるため、チケットを取得するために特別な作業をする必要はありません。ただし、チケットが期限切れになった場合は、チケットを作成する必要があります。また、デフォルトの主体のほかに別の主体を使用する必要がある場合 (たとえば、rlogin -l を使って他人としてマシンにログインする) があります。
チケットを作成するには、kinit コマンドを使用します。
% /usr/bin/kinit |
kinit コマンドからはパスワードの入力を求めるプロンプトが表示されます。kinit コマンドの詳細な構文については、kinit(1) のマニュアルページを参照してください。
次の例では、ユーザー 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 チケットの転送」および 「チケットの種類」を参照してください。
すべてのチケットが同じ属性を持つわけではありません。チケットの属性には、「転送可能 (Forwardable)」、「遅延 (Postdated)」などがあります。また、1 つのチケットに「転送可能」と「遅延」の両方が指定されていることもあります。現在のチケットが何で、どのような属性を持つかを知るには、klist コマンドで -f オプションを使用します。
% /usr/bin/klist -f |
次の記号はチケットに関連付けられる属性です。klist によって表示されます。
事前認証済み
遅延可能 (Postdatable)
遅延 (Postdated)
転送可能 (Forwardable)
転送済み (Forwarded)
初期 (Initial)
無効 (Invalid)
プロキシ可能 (Proxiable)
プロキシ (Proxy)
更新可能 (Renewable)
チケットに指定できる属性については、「チケットの種類」を参照してください。
次の例は、ユーザー 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 チケットを破棄するには、kdestroy コマンドを使用します。このコマンドは、資格キャッシュを破棄して、すべての資格とチケットを破棄します。通常、これは必要ありませんが、kdestroy コマンドを実行すると、ログインしていないときに資格キャッシュが継続して存在する可能性を減らすことができます。
チケットを破棄するには、kdestroy コマンドを使用します。
% /usr/bin/kdestroy |
kdestroy コマンドは、そのユーザーのすべてのチケットを破棄します。このコマンドを使用して、特定のチケットを選択して破棄することはできません。
システムを離れるときに侵入者が権限を使用する危険がある場合は、kdestroy を使用してチケットを破棄するか、スクリーンセーバーを使って画面をロックする必要があります。
Kerberos サービスが構成されている場合、パスワードを 2 つ持つことになります。 通常の Solaris パスワードと Kerberos パスワードです。これらのパスワードは同じでも、異なっていても構いません。
パスワードには、キーボードから入力できるほとんどの文字を使用できます。ただし、Ctrl キーと Return キーは使用できません。良いパスワードとは、覚えやすく、しかも他人が簡単に推定できないパスワードです。悪いパスワードの例を次に示します。
辞書に出てくる言葉
よく見られるありふれた名前
有名な人やキャラクタの名前
ユーザーの氏名またはユーザー名 (たとえば、名前を逆に綴る、2 度繰り返す)
配偶者の名前、子供の名前、ペットの名前
自分の誕生日や親戚の誕生日
社会保険番号、運転免許証番号、パスポート番号、またはこれに類した身分証明書番号
このマニュアルやほかのマニュアルに出てくるサンプルパスワード
良いパスワードとは 8 文字以上の長さで、大文字、小文字、数字、句読記号などが混在しているものです。次に例を示します。
「I2LMHinSF」などの短縮形。(「I too left my heart in San Francisco」と覚える)
「WumpaBun」、「WangDangdoodle!」など、発音しやすい意味のない語句
「6o'cluck」、「RrriotGrrrlsRrrule!」など、わざとスペルを間違えた語句
これらの例は使用しないでください。マニュアルの例に使用されているパスワードは侵入者が最初に試みるパスワードです。
PAM が適切に設定されている場合、Kerberos パスワードは次の 2 つの方法で変更できます。
通常の UNIX の passwd コマンド。Kerberos サービスが構成されていると、Solaris の passwd コマンドでも新しい Kerberos パスワードを求めるプロンプトが自動的に表示されます。
kpasswd の代わりに passwd を使用する利点は、UNIX と Kerbeors 両方のパスワードを同時に設定できることです。ただし、一般的には passwd コマンドで両方のパスワードを同時に変更する必要はありません。UNIX パスワードだけを変更して Kerberos パスワードは変更しなかったり、その逆であっても構いません。
passwd コマンドの動作は、PAM モジュールの構成方法によって異なります。構成によっては、両方のパスワードを変更しなければならない場合があります。あるサイトでは UNIX パスワードの変更が必須であり、別のサイトでは Kerberos パスワードの変更が必須であるという場合があります。
kpasswd コマンド。kpasswd コマンドは、passwd コマンドと似ています。ただし、kpasswd コマンドでは、Kerberos パスワード以外は変更できません。UNIX パスワードを変更する場合は、passwd コマンドを使用する必要があります。
もう 1 つの違いは、kpasswd コマンドでは、有効な UNIX ユーザーではない Kerberos 主体のパスワードを変更できる点です。たとえば、david/admin は Kerberos 主体ですが、実際の UNIX ユーザーではありません。したがって、この場合は、passwd コマンドの代わりに kpasswd コマンドを使用する必要があります。
パスワードを変更しても、変更がシステム全体に伝播されるまでには、ある程度の時間が必要です (特に大規模なネットワークでは)。システムの設定方法によりますが、この時間は数分から 1 時間以上になることがあります。パスワードを変更したあとすぐに新しい Kerberos チケットを取得する場合は、新しいパスワードをまず試してください。新しいパスワードが有効でない場合は、以前のパスワードを使用して再度試してください。
Kerberos V5 プロトコルでは、システム管理者が有効なパスワードの基準をユーザーごとに設定できます。この基準は、ユーザーごとの「ポリシー」に定義できます。デフォルトのポリシーを使用することもできます。ポリシーの詳細については、「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. |
次の例では、ユーザー 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 自身のパスワードを入力せずに遠隔ログインできます。
david のホームディレクトリが、Kerberos V5 プロトコル経由で別の (3 つ目の) マシンから NFS マウントされている場合、jennifer がそのホームディレクトリにアクセスするには、彼女が転送チケットを所持している必要があります。転送可能チケットの使用例については、「Kerberos チケットの作成」を参照してください。
ネットワーク上のほかのマシンにログインする必要がある場合、それらのマシン上の .k5login ファイル内に自分の Kerberos 主体を追加します。
.k5login ファイルの使用は、次の理由により、パスワードを公表するよりも安全です。
.k5login ファイルから特定の主体を削除することで、特定ユーザーのアクセス認可をいつでも無効にできます。
ホームディレクトリ内の .k5login ファイルにある名前の付いたユーザーの主体は、そのマシン (NFS 上などで .k5login ファイルを共有している場合には一連のマシン) 上のアカウントへの完全なアクセス権を持ちます。ただし、Kerberos サービスは、そのユーザー ID に基づいてアクセスを承認します。つまり、jennifer は、joe のマシンにログインして、そこで作業を行えます。ただし、ftp や rlogin などの Kerberos プログラムを使用する場合は、自分自身のアカウントで使用します。
Kerberos は、チケットを取得したユーザーのログを保持しているため、システム管理者は、特定の時刻に特定のユーザー ID を使用できるユーザーを、必要に応じて調べることができます。
.k5login ファイルの一般的な使い方の 1 つは、このファイルを root のホームディレクトリに格納し、ファイル内に記述された Kerberos 主体にそのマシンの root アクセス権限を与える、というものです。この設定により、システム管理者は、スーパーユーザーのパスワードを公表したり、そのパスワードをネットワーク上で入力したりせずに、ローカルで root になることも、root として遠隔ログインすることもできるようになります。
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 V5 製品は「シングルサインオン」システムです。つまり、1 度だけパスワードを入力する必要があるという意味です。Kerberos V5 プログラムがユーザーに代わって認証 (オプションで暗号化も) 行います。これは、Kerberos が、既存のよく知られたネットワークプログラム群ごとに構築されているためです。Kerberos V5 アプリケーションは、既存の UNIX ネットワークプログラムに Kerberos 機能を追加したバージョンです。
たとえば、ある Kerberos プログラムを使って特定の遠隔ホストに接続する場合、そのプログラム、KDC、その遠隔ホストの 3 者は、一連のネゴシエーションをすばやく実行します。これらのネゴシエーションが正常終了した場合、そのプログラムは遠隔ホストに対し、そのユーザーの身元をユーザーに代わって証明したことになり、遠隔ホストはそのユーザーにアクセスを認可します。
Kerberos コマンドは最初に、Kerberos を使用して認証しようとする点に注意してください。Kerberos 認証が失敗すると、エラーが発生するか、UNIX 認証が試みられますが、どちらになるかは、コマンドに指定されるオプションによって決まります。詳細は、各 Kerberos コマンドのマニュアルページの「Kerberos Security」節を参照してください。
Kerberos ネットワークサービスは、インターネット上のほかのマシンと接続するプログラムです。これらには、次のプログラムがあります。
ftp
rcp
rdist
rlogin
rsh
ssh
telnet
これらのプログラムは、Kerberos チケットを透過的に使って認証 (と暗号化) のネゴシエーションを遠隔ホストと行うための機能も備えています。それらを使用する際の変化といえば、多くの場合、パスワードを入力する必要がなくなったことに気付くことぐらいです。このとき、Kerberos がユーザーに代わってユーザーの身元証明を行なってくれています。
Kerberos V5 ネットワークプログラムは、次の機能を実現するオプションを備えています。
別のホストへチケットを転送します (最初に転送可能チケットを取得していた場合)。
ユーザーと遠隔ホスト間で送受信されるデータを暗号化します。
この節では、読者がすでにこれらの Kerberos 以外のプログラムに慣れ親しんでいることを前提に、Kerberos V5 パッケージによって追加された Kerberos 機能だけに的を絞って説明しています。ここで説明するコマンドの詳細については、各コマンドのマニュアルページを参照してください。
次の Kerberos オプションが、ftp、rcp、rlogin、rsh、および telnet に追加されています。
既存のチケットを使用して自動ログインしようとします。getlogin() によって返されたユーザー名を使用します。ただし、現在のユーザー ID と異なる場合には使用しません。詳細は、telnet(1) のマニュアルページを参照してください。
「再転送不可能な」チケットを遠隔ホストに転送します。このオプションは、-F オプションと互いに排他の関係にあります。つまり、これらを同一コマンド内で同時に使用することはできません。
3 つ目のホスト上のほかの Kerberos に基づくサービスに自身を認証する必要がある場合、チケットを転送します。たとえば、ほかのマシンに遠隔ログインして、そこから 3 つ目のマシンに遠隔ログインします。
遠隔ホスト上のホームディレクトリが Kerberos V5 を使用して NFS マウントされている場合、転送可能チケットを使用する必要があります。そうしなかった場合、ホームディレクトリにアクセスできません。つまり、最初、システム 1 にログインするものとします。システム 3 からホームディレクトリをマウントしたホームマシン、システム 2 にシステム 1 から遠隔ログインします。rlogin で-f または -F オプションを使用しない場合、チケットがシステム 3 に転送されないため、ホームディレクトリを取得できません。
kinit はデフォルトで、転送可能なチケット認可チケット (TGT) を取得します。ただし、このような構成を変更することは可能です。
チケットの転送の詳細は、「Kerberos チケットの転送」を参照してください。
「再転送可能な」TGT のコピーを遠隔システムに転送します。このオプションは、-f と似ていますが、さらに先のマシン (たとえば 4 つ目や 5 つ目のマシン) へのアクセスを可能とする点が異なります。したがって、-F オプションは -f オプションのスーパーセットであると考えられます。-F オプションと -f オプションは、互いに排他の関係にあります。つまり、これらを同一コマンド内で同時に使用することはできません。
チケットの転送の詳細は、「Kerberos チケットの転送」を参照してください。
krb5.conf ファイルを使用してレルム自身を決定する代わりに、特定の realm 内の遠隔ホストのチケットを要求します。
/etc/gss/mech ファイルの記載どおりに、使用する GSS-API セキュリティーメカニズムを指定します。デフォルトは kerberos_v5。
次の表は、コマンド固有のオプションを示します。「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 のプロンプト対してコマンドを入力することでにセッションの保護レベルを設定できます。
保護レベルを「private」に設定します。データ転送は、暗号化により機密性と完全性が保護されます。ただし、この機密サービスは、Kerberos ユーザーによっては利用できない可能性もあります。
ftp プロンプトで protect と入力したあとに上記に示した保護レベル (clear、private、または safe) のいずれかを入力して、保護レベルを設定することもできます。
「Kerberos コマンドの概要」で説明したように、一部のコマンドで -f または -F オプションを使用するとチケットを転送できます。チケットを転送すると、ネットワークトランザクションの「チェーン化」が可能となります。たとえば、あるマシンに遠隔ログインして、そこから別のマシンに遠隔ログインできます。-f オプションではチケットを転送することができますが、-F オプションでは転送済みのチケットを再転送することが可能です。
図 26–2 で、ユーザー david は kinit を使用して、転送不可能なチケット認可チケット (TGT) を取得します。-f オプションを指定しなかったため、チケットは転送不可能なチケットです。シナリオ 1 では、マシン B に遠隔ログインできますが、それ以上遠隔ログインできません。シナリオ 2 の rlogin -f コマンドは失敗します。なぜなら、彼は転送不可能なチケットを転送しようとしているからです。
実際にはデフォルトで、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 に再転送されます。
次の例は、Kerberos コマンドのオプションの使用方法を示しています。
この例では、ユーザー 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 (およびここで説明したその他のコマンド) は、終了時にそのチケットを破棄します。
ここでは、ユーザー 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 % |
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 に設定しています。
この章では、Kerberos 製品に組み込まれている多数のファイル、コマンド、およびデーモンを示します。また、Kerberos 認証の機能についても詳細に説明します。
この章の内容は次のとおりです。
ファイル名 |
説明 |
---|---|
~/.gkadmin | |
~/.k5login | |
/etc/krb5/kadm5.acl | |
/etc/krb5/kadm5.keytab | |
/etc/krb5/kdc.conf | |
/etc/krb5/kpropd.acl | |
/etc/krb5/krb5.conf | |
/etc/krb5/krb5.keytab | |
/etc/krb5/warn.conf | |
/etc/pam.conf | |
/tmp/krb5cc_uid | |
/tmp/ovsec_adm.xxxxxx | |
/var/krb5/.k5.REALM | |
/var/krb5/kadmin.log | |
/var/krb5/kdc.log | |
/var/krb5/principal | |
/var/krb5/principal.kadm5 | |
/var/krb5/principal.kadm5.lock | |
/var/krb5/principal.ok | |
/var/krb5/principal.ulog | |
/var/krb5/slave_datatrans | |
/var/krb5/slave_datatrans_slave |
この節では、Kerberos 製品に含まれているコマンドの一部を示します。
表 27–2 Kerberos コマンド
次の表は、Kerberos 製品で使用されるデーモンの一覧です。
表 27–3 Kerberos デーモン
デーモン |
説明 |
---|---|
/usr/sbin/in.ftpd | |
/usr/lib/krb5/kadmind | |
/usr/lib/krb5/kpropd | |
/usr/lib/krb5/krb5kdc | |
/usr/lib/krb5/ktkt_warnd | |
/usr/sbin/in.rlogind | |
/usr/sbin/in.rshd | |
/usr/sbin/in.telnetd |
この節では、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 によって生成され、クライアントとサービス間で共有されます。
「チケット」は、ユーザーの識別情報をサーバーやサービスに安全に渡すために使用される情報パケットです。チケットは、単一クライアントと特定サーバー上の特定サービスだけに有効です。チケットには、次のものが含まれます。
サービスの主体名
ユーザーの主体名
ユーザーのホストの IP アドレス
タイムスタンプ
チケットの有効期限を定義する値
セッション鍵のコピー
これらのすべてのデータは、サーバーのサービス鍵に暗号化されます。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) であっても、チケットの有効期限は次の中で最も小さい値に設定されます。
kinit を使用してチケットを取得する場合、kinit の -l オプションに指定した有効期限値。デフォルトで、kinit は最長有効期限値を使用します。
チケットを提供するサービス主体に対し Kerberos データベースに指定されている最長有効期限値。kinit の場合、サービス主体は krbtgt/realm。
チケットを要求するユーザー主体に対し Kerberos データベースに指定されている最長有効期限値。
図 27–1 は、TGT の有効期限の決定方法と 4 つの有効期限値の指定元を示しています。この図は TGT の有効期限がどのようにして決まるかを示しますが、基本的には、どの主体がチケットを取得する場合でも同じです。違いは、kinit で有効期限値を指定しないことと、krbtgt/realm主体の代わりに、チケットを提供するサービス主体が最長有効期限値を提供することだけです。
更新可能チケットの有効期限も次の 4 つの最小値で決まります。ただし、この場合は更新可能有効期限が使用されます。
kinit を使用してチケットを取得または更新する場合、kinit の -r オプションに指定した更新可能有効期限値。
チケットを提供するサービス主体に対し Kerberos データベースに指定されている更新可能最長有効期限値。kinit の場合、サービス主体は krbtgt/realm。
チケットを要求するユーザー主体に対し 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 主体。 |
アプリケーションを使用して遠隔システムにログインするには、識別情報を証明するチケットとそれに対応するセッション鍵を指定する必要があります。セッション鍵には、ユーザーやアクセスするサービスに特有の情報が含まれています。ユーザーすべてのチケットとセッション鍵は、ユーザーが最初にログインするときに KDC によって作成されます。チケットとそれに対応するセッション鍵が 1 つの資格となります。複数のネットワークサービスを使用する場合には、ユーザーは多数の資格を収集できます。ユーザーは特定のサーバーで動作するサービスごとに 1 つの資格を必要とします。たとえば、boston というサーバー上の ftp サービスにアクセスするには 1 つの資格が必要です。別のサーバー上の ftp サービスにアクセスするには、別の資格が必要です。
資格の作成や格納は透過的に行われます。資格は KDC によって作成され、要求者に送信されます。資格は、受信されると資格キャッシュに格納されます。
Kerberos サービスは、ホスト名の解決に DNS を使用するようにコンパイルされています。ホスト名を解決する場合、 nsswitch.conf ファイルへの参照は一切行われません。
特定のサーバー上の特定のサービスにアクセスする場合、ユーザーは 2 つの資格を取得する必要があります。最初は TGT として知られるチケット認可チケットに対する資格です。チケット認可サービスは、この資格の暗号を解除すると、ユーザーからアクセスを要求されているサーバーの資格をさらに作成します。ユーザーは、この 2 つめの資格を使用してサーバー上のサービスへのアクセスを要求します。サーバーがこの資格の暗号を解除すると、ユーザーはアクセスを許可されます。次の節では、このプロセスを詳細に説明します。
認証処理を開始するために、クライアントが特定のユーザー主体の要求を認証サーバーに送信します。この要求の送信では暗号は使用されません。要求にはセキュリティーにかかわる情報が含まれていないため、暗号を使う必要はありません。
認証サービスは要求を受信すると、ユーザーの主体名を KDC データベースから検索します。主体がデータベースのエントリに一致すると、認証サービスはその主体の非公開鍵を取得します。次に認証サービスは、クライアントとチケット認可サービスが使用するセッション鍵 (セッション鍵 1) とチケット認可サービス用のチケット (チケット 1) を生成します。このチケットを「チケット認可チケット (TGT)」ともいいます。セッション鍵とチケットはユーザーの非公開鍵を使って暗号化され、情報がクライアントに返送されます。
クライアントは、ユーザー主体の非公開鍵を使用して、この情報からセッション鍵 1 とチケット 1 の暗号を解除します。非公開鍵を知っているのはユーザーと KDC データベースだけである必要があるため、パケットの情報は安全に保たれなければなりません。クライアントはこの情報を資格キャッシュに格納します。
この処理中に、ユーザーは通常、パスワードを要求されます。非公開鍵を作成するために使用された、KDC データベースに格納されているパスワードが、ユーザーが指定したパスワードと同じであると、認証サービスから送信された情報は正しく復号化されます。これでクライアントは、チケット認可サービスに対して使用する資格を取得します。次にクライアントはサーバーに対する資格を要求します。
特定のサーバーにアクセスするには、クライアントがその前にサーバーに対する資格を認証サービスから取得している必要があります。「チケット認可サービスに対する資格の取得」を参照してください。次にクライアントは、チケット認可サービスに要求を送信します。この要求には、サービス主体名、チケット 1 およびセッション鍵 1 で暗号化されたオーセンティケータが含まれています。チケット 1 は、チケット認可サービスのサービス鍵を使用して認証サービスによって暗号化されたものです。
チケット認可サービスはチケット認可サービスのサービス鍵を知っているため、チケット 1 の暗号を解除できます。チケット 1 の情報にはセッション鍵 1 が含まれているため、チケット認可サービスはオーセンティケータの暗号を解除できます。この時点で、ユーザー主体はチケット認可サービスによって認証されます。
認証が正常に終了すると、チケット認可サービスは、ユーザー主体とサーバーに対するセッション鍵 (セッション鍵 2) とサーバーに対するチケット (チケット 2) を生成します。次にセッション鍵 2 とチケット 2 はセッション鍵 1 を使って暗号化されます。セッション鍵 1 を知っているのはクライアントとチケット認可サービスだけであるため、この情報は安全であり、ネットワークを介して安全に送信されます。
クライアントはこの情報パケットを受信すると、前に資格キャッシュに格納したセッション鍵 1 を使用して情報を復号化します。クライアントは、サーバーに対して使用する資格を取得したことになります。次にクライアントは、そのサーバーの特定のサービスにアクセスする要求を行います。
クライアントが特定のサービスへのアクセスを要求するには、まず認証サーバーからチケット認可サービスに対する資格を取得し、チケット認可サービスからサーバー資格を取得する必要があります。「チケット認可サービスに対する資格の取得」および 「サーバーに対する資格の取得」を参照してください。次に、クライアントは、チケット 2 と別のオーセンティケータを含む要求をサーバーに送信します。オーセンティケータはセッション鍵 2 を使用して暗号化されます。
チケット 2 は、サービスのサービス鍵を使用してチケット認可サービスによって暗号化されています。サービス鍵はサービス主体が知っているため、サービスはチケット 2 を復号化し、セッション鍵 2 を取得できます。次に、セッション鍵 2 を使用してオーセンティケータが復号化されます。オーセンティケータが正しく復号化されると、サービスへのアクセスがクライアントに許可されます。
暗号化タイプは、暗号処理が実行されるときに使用する暗号アルゴリズムとモードを特定します。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 では、古いスレーブが処理できない新しい暗号化タイプが使用されます。
次に、暗号化タイプを変更する前に考慮する必要があるいくつかの問題を説明します。
KDC では、主体データベースのサーバー主体エントリに関連する最初の鍵/暗号化タイプはサーバーがサポートしていると想定します。
KDC 上で、主体に対して生成される鍵が、主体が認証されるシステムと互換性があるかを確認してください。デフォルトで、kadmin コマンドは、サポートされるすべての暗号化タイプの鍵を生成します。主体を使用するシステムがこの暗号化タイプのデフォルトのセットをサポートしていない場合、主体の作成時に暗号化タイプを制限する必要があります。暗号化タイプは、kadmin addprinc で -e フラグを使用するか、または kdc.conf ファイルの supported_enctypes パラメータを設定することで、そのサブセットに制限することができます。Kerberos レルムの大部分のシステムがデフォルトの暗号化タイプのサブセットをサポートしている場合に、supported_enctypes パラメータを使用します。supported_enctypes の設定では、 kadmin addprinc が特定のレルムに対して主体を作成するときに使用する暗号化タイプのデフォルトのセットが指定されます。一般的に、これら 2 つの方法のうち 1 つを使用して、Kerberos が使用する暗号化タイプを制御します。
システムがサポートする暗号化タイプを決定するときは、システムで実行する Kerberos のバージョンと、サーバー主体の作成対象のサーバーアプリケーションがサポートする暗号アルゴリズムとを考慮します。たとえば、nfs/hostname サービス主体を作成するときは、ホスト上の NFS サーバーがサポートするタイプに暗号化タイプを制限します。Solaris 10 リリースでは、サポートされるすべての Kerberos 暗号化タイプが NFS サーバーでもサポートされることに注意してください。
kdc.conf ファイルの master_key_enctype パラメータを使用して、主体データベースのエントリを暗号化するマスター鍵の暗号化タイプを制御できます。KDC 主体データベースが既に作成済みの場合は、このパラメータを使用しないでください。データベースの作成時に master_key_enctype パラメータを使用して、デフォルトのマスター鍵の暗号化タイプを des-cbc-crc からより強固な暗号化タイプに変更できます。スレーブ KDC を設定するときに、すべてのスレーブ KDC が選択された暗号化タイプをサポートし、それらの kdc.conf に同一の master_key_enctype エントリがあることを確認してください。また、supported_enctypes が kdc.conf で設定されている場合は、master_key_enctype が supported_enctypes の暗号化タイプのうちの 1 つに設定されていることも確認してください。これらの問題のいずれかが適切に処理されない場合、マスター KDC はスレーブ KDC と連携できない可能性があります。
クライアント上で、krb5.conf のパラメータのいくつかを使用して、KDC からチケットを取得するときにクライアントが要求する暗号化タイプを制御できます。default_tkt_enctypes パラメータには、クライアントが KDC からチケット認可チケット (TGT) を要求するときに使用する暗号化タイプを指定します。TGT は、より効果的な方法でほかのサーバーチケットを取得するためにクライアントにより使用されます。default_tkt_enctypes を設定すると、クライアントが TGT を使用してサーバーチケットを要求する (TGS 要求と呼ばれる) ときに、クライアントと KDC 間の通信を保護するために使用される暗号化タイプを一部制御できます。default_tkt_enctypes に指定された暗号化タイプは、KDC 上に格納された主体データベース内の主体鍵の暗号タイプのうち少なくとも 1 つに一致する必要があることに注意してください。一致しない場合、TGT 要求は失敗します。多くの場合、default_tkt_enctypes を設定しないようにします。このパラメータは、相互運用性の問題の原因になるためです。デフォルトで、クライアントコードは、サポートされるすべての暗号化タイプと KDC が、KDC により主体データベースで検出された鍵に基づく暗号化タイプを選択するように要求します。
default_tgs_enctypes パラメータは、サーバーチケットの取得に使用される TGS 要求でクライアントが要求する暗号化タイプを制限します。このパラメータは、クライアントとサーバーが共有するセッション鍵を作成するときに KDC が使用する暗号化タイプも制限します。たとえば、NFS をセキュリティー保護するときに 3DES 暗号化だけを使用するには、default_tgs_enctypes = des3-cbc-sha1 と設定します。クライアントとサーバーの主体が、主体データベース内に des-3-cbc-sha1 鍵を持っていることを確認してください。default_tkt_enctype と同様に、多くの場合でこの設定をしないようにします。資格が KDC とサーバーの両方で適切に設定されていないと、相互運用性の問題の原因となるためです。
サーバー上で、kdc.conf の permitted_enctypes を使用して、サーバーが受け入れる暗号化タイプを制御できます。さらに、keytab エントリを作成するときに使用される暗号化タイプを指定できます。一般的に、これらの方法のいずれかを使用して暗号化タイプを制御したり、代わりに、使用する暗号化タイプを KDC に決定させたりしないようにします。KDC はサーバーアプリケーションと通信しないで、使用する鍵や暗号化タイプを決定するためです。
デフォルトのマッピングでは十分でないとき、NFS サーバーは gsscred テーブルを使用して、Kerberos ユーザーを識別します。NFS サービスは、UNIX ID を使用してユーザーを識別します。UNIX ID は、ユーザー主体または資格には含まれません。gsscred テーブルは、パスワードファイルから得られる GSS 資格を UNIX ID に追加してマッピングするテーブルです。このテーブルは、KDC データベースを生成したあとに作成および開始する必要があります。詳細は、 「GSS 資格の UNIX 資格へのマッピング」を参照してください。
クライアントの要求が到着すると、NFS サービスは主体名を UNIX ID にマッピングしようとします。このマッピングに失敗した場合、gsscred テーブルが確認されます。
Solaris 10 バージョンの Kerberos サービスは MIT Kerberos version 1.2.1 に基づいています。次に、Solaris 10 リリースに含まれ、MIT 1.2.1 バージョンには含まれない拡張機能を示します。
Solaris 遠隔アプリケーションの Kerberos サポート
KDC データベースの増分伝播
クライアント構成スクリプト
地域対応のエラーメッセージ
BSM 監査レコードのサポート
GSS-API を使用する Kerberos のスレッドに対して安全な使用法
暗号用暗号化フレームワークの使用
このバージョンには MIT 1.2.1 以後のバグ修正もいくつか含まれています。特に、1.2.5 btree のバグ修正および 1.3 TCP サポートが追加されました。