Kerberos に対する最初の通信は、一般的なネットワークシステムにおけるログイン処理に似通っています。まずはユーザ名を入力します。この情報とチケット発行許諾サービスの名前が認証サーバ (Kerberos) に送信されます。認証サーバ側でユーザ名が既知のものであった場合は、クライアントとチケット発行許諾サーバとの間で使用される、乱数を利用したセッション鍵を発行します。あとは認証サーバがチケット発行許諾サーバに対するチケットを発行します。このチケットには下記のような情報が含まれていて、これら全てが認証サーバとチケット発行許諾サーバのみが知りうるセッション鍵で暗号化されます:

このチケットは、セッション鍵と共に暗号化された状態のまま、クライアント側に返却されます。ただし、この時点ではクライアントが使用する機密鍵を使用して暗号化を行います。機密鍵はユーザのパスワードを元にして作られるものであるため、 Kerberos とクライアントのみが知りうる情報となります。クライアント側では応答を受け取ったあと、利用者に対してパスワードを尋ねるようになります。クライアント内では、このパスワードを機密鍵に変換して、認証サーバから届いたデータを解読する処理を行います。必要な情報が 「開梱できた」 あとは、パスワードを自身のメモリ内から消去します。チケット内には有効期間が示されていることから、この有効期間が切れるまでの間に新しいチケットの発行を要求することで、クライアント側は認証を必要な期間だけ使い続けられることになります。

ネットワーク内のサーバが提供するサービスを利用するため、クライアント側のアプリケーションは、サーバに対して識別情報を提示する必要があります。そのため、アプリケーションはオーセンティケータを生成します。オーセンティケータには下記のような情報が含まれています:

これら全ての情報は、クライアント側で既に受信しているセッション鍵を利用して、暗号化が行われます。サーバ向けのオーセンティケータとチケットが揃ったら、あとはそれらをサーバに送信します。サーバはオーセンティケータを解読するためにセッション鍵のコピーを使用し、サービスを要求するクライアントに対して必要な情報を取得したあと、チケットに書かれている内容と比較します。これにより、サーバ側ではチケットとオーセンティケータが同じクライアントから送信されたものであるかを確認します。

サーバ側では特別なセキュリティを実装しない限り、この処理はリプレイ攻撃に対する標的となり得てしまいます。たとえば誰かが以前に送信したオーセンティケータとチケットを保存しておいて、後からそれを送信して認証をかいくぐる方法が考えられます。このような不正を防止する目的で、サーバ側では以前に受信したものと同じタイムスタンプのチケットは受け付けないようになっているほか、受信した時刻とタイムスタンプがあまりにも違いすぎる場合も、要求を受け付けないようになっています。

Kerberos の認証は両方向に使用することができます。つまり、認証はクライアント側にだけ求められるものではありません。サーバ側でも、サービスを要求するクライアントに対して、自分自身を認証する必要があります。そのため、サーバ側ではオーセンティケータ自身を送信します。クライアント側のオーセンティケータのチェックサムに 1 を加えたあと、サーバとクライアントとの間で共有されているセッション鍵で暗号化を行います。クライアント側ではこの応答をもとに、サーバの正当性を確認して後続の処理を行うかどうかを判別します。

チケットは特定のサーバに対して使用するために設計されています。そのため、異なるサービスに接続する際には、新しいチケットの発行を受ける必要があります。 Kerberos では、それぞれのサーバに対するチケットを取得する仕組みが用意されています。このサービスを 「チケット発行許諾サービス」 と呼びます。チケット発行許諾サービスは、それ自身が (ここまでに説明しているのと同じ) サービスであり、ここまでの説明と同じプロトコルでアクセスを行います。アプリケーション側で新しいチケットが必要になると、チケット発行許諾サーバにアクセスを行います。このリクエストには下記のような情報が含まれています:

他のサーバと同様に、チケット発行許諾サーバでもチケット発行許諾チケットと、オーセンティケータの内容を確認します。それらの情報がいずれも正当なものであった場合、チケット発行許諾サーバは元々のクライアントと新しく接続するサーバとの間で使用するセッション鍵を構築します。新しく接続するサーバに対するチケットには、下記のような情報が含まれています:

新しいチケットにも有効期間が設定されています。この有効期間はチケット発行許諾チケットと同じか、もしくはサービスごとの既定値のうち、いずれか早いほうが設定されます。クライアントは、チケット発行許諾サービスからこのチケットとセッション鍵を受け取ります。ただし、この時点では元々のチケット発行許諾チケットのセッション鍵で暗号化されています。そのため、クライアント側では利用者に対してパスワードを求めることなく、応答を解読できることになります。これにより、 Kerberos はユーザの手を煩わせることなくチケットを取得できることになります。

Kerberos の環境を正しく完全に動作させるには、下記の要件を満たさなければなりません:

下記の図に、 Kerberos のインフラストラクチャを構築するのに必要な、最小限のコンポーネントのみを配置した構成例を示します。実際の構成はネットワークの規模やトポロジに応じて決定してください。

図 6.1: Kerberos ネットワークトポロジ #

ヒント: サブネットルーティングの設定について

図6.1「Kerberos ネットワークトポロジ」 に示しているような構成を作成するには、 2 つのサブネット (192.168.1.0/24 および 192.168.2.0/24) の間を結ぶルータで、ルーティング (経路制御) を設定する必要があります。 YaST でルーティングを設定する場合は、 13.4.1.5項 「ルーティングの設定」 をお読みください。

Kerberos の世界では認証の管理単位をレルムと呼び、たとえば EXAMPLE.COM や単純に ACCOUNTING のように、名前を付けて区別します。 Kerberos は大文字と小文字を区別して扱う仕組みであることから、 example.com と EXAMPLE.COM は別々のレルムとして扱われます。いずれかお好きなほうをお使いください。ただし、一般的には大文字のレルムを使用します。

また、レルムには DNS ドメイン名 (もしくは ACCOUNTING.EXAMPLE.COM のようなサブドメイン) を使用するのが一般的です。このような構成にすることで、 KDC やその他の Kerberos サービスを DNS ドメイン名と一括で管理できるようになります。また、レルム名を DNS ドメイン名のサブドメインにしておくと、将来の追加時に便利になることでしょう。

ただし、 DNS のドメイン名とは異なり、 Kerberos は階層構造にはなっていません。そのため、たとえば EXAMPLE.COM 以下に 「下位のレルム」 として DEVELOPMENT と ACCOUNTING を作成しても、 EXAMPLE.COM のプリンシパルを引き継いで使用することはできません。このような構成では、 3 つの独立したレルムとして構成をすることになります。ただし、レルム間には相互認証を設定することができますので、一方のレルムに属するユーザがアクセスできるサーバが存在した場合、他方のレルムに属するユーザを許可するような設定を行うことができます。

なお、構成や説明をわかりやすくする目的から、下記の記述では組織内全体を表すレルム EXAMPLE.COM を 1 つだけ使用するものとして説明を行います。

Kerberos を使用するにあたって最初にすべきことは、鍵配送センター (KDC) として動作させるマシンの準備になります。このマシンには Kerberos のユーザデータベース (パスワードなどのユーザに関連する全ての情報) を保存します。

KDC はセキュリティインフラストラクチャで最も重要な構成部品です。そのセキュリティを突破されてしまうと、 Kerberos が保持し保護している全てのアカウント情報が漏洩することになってしまいます。また、漏洩した情報をもとに Kerberos 内の任意のユーザになりすますこともできてしまいます。そのため、このマシンに対するセキュリティは、最も強固な設定にしてください:

Kerberos を正しく動作させるには、組織内の全システムの時刻誤差が適切な範囲内に収まるよう、時刻を同期させる必要があります。これは他者が送信した認証情報を窃取したあと、再送信して権限を不正に得てしまうリプレイ攻撃を防ぐために重要となります。 Kerberos では、このような攻撃を防ぐための様々な仕組みを取り入れていますが、その中の 1 つに、チケット内にタイムスタンプを書き込む、というものがあります。サーバ側では、不正な再送信を防ぐため、現在時刻とは異なるタイムスタンプの書かれたチケットを拒否するようになっています。

もちろんネットワーク上を流れるにあたって、ある程度の時間は必要となることから、タイムスタンプの比較に際しても一定の猶予時間が設けられています。しかしながら、コンピュータの時計は、誤差という観点では非常に不正確なものです。 PC の時計が 1 週間のうちに 30 分程度進んだり遅れたりするようなことも、よくある話です。このような理由から、ネットワーク内の全てのコンピュータは、特定の中央の時刻情報源に対して同期を行う必要があります。

時刻同期を行うのに最も簡単な方法は、特定の 1 台のマシンに NTP タイムサーバをインストールして、残りのクライアントはその NTP タイムサーバに対して同期するように設定する方法です。同期する側のコンピュータについては、 NTP デーモンである chronyd をインストールして動作させることで、同期を行うことができます。なお、 KDC 自身も中央の時刻情報源と同期する必要があります。ただし、 KDC 自身で NTP デーモンを実行するのはリスクとなりうるため、 cron ジョブで chronyd -q を実行するよう設定するのが適切でしょう。 NTP クライアントの設定方法について、詳しくは 18.1項 「YaST を利用した NTP クライアントの設定」 をお読みください。

時刻同期を行うためのもう 1 つの方法としては、専用の NTP サーバを用意するか、もしくは KDC に直接電波時計や GPS 時計などのハードウエア時計を接続して時刻を管理する方法もあります。

なお、 Kerberos がタイムスタンプを比較する際の最大許容範囲を設定することもできます。 6.5.6.3項 「時計の許容誤差の設定」 の手順に従って、 krb5.conf ファイル内の clock skew の値を変更してください。

本章では、 KDC の初期設定とインストール、そして管理者のプリンシパルを作成するまでの手順を説明しています。具体的には、下記のような流れで作業を行います:

[libdefaults]
 dns_canonicalize_hostname = false
 rdns = false
 default_realm = example.com
 ticket_lifetime = 24h
 renew_lifetime = 7d

[realms]
  example.com = {
  kdc = kdc.example.com.:88
  admin_server = kdc.example.com
  default_domain = example.com
 }

 [logging]
 kdc = FILE:/var/log/krb5kdc.log
 admin_server = FILE:/var/log/kadmind.log
 default = SYSLOG:NOTICE:DAEMON

[domain_realm]
 .example.com = example.com
 example.com = example.com

> sudo kdb5_util create -r EXAMPLE.COM -s

Initializing database '/var/lib/kerberos/krb5kdc/principal' for realm 'EXAMPLE.COM',
master key name 'K/M@EXAMPLE.COM'
You are prompted for the database Master Password.
It is important that you NOT FORGET this password.
Enter KDC database master key:  1
Re-enter KDC database master key to verify:  2

> kadmin.local

kadmin> listprincs

K/M@EXAMPLE.COM
kadmin/admin@EXAMPLE.COM
kadmin/changepw@EXAMPLE.COM
krbtgt/EXAMPLE.COM@EXAMPLE.COM

> kadmin.local

kadmin> ank suzanne

suzanne@EXAMPLE.COM's Password: 1
Verifying password: 2

> sudo systemctl start krb5kdc
sudo systemctl start kadmind

> sudo systemctl enable krb5kdc kadmind

対応するインフラストラクチャ (DNS, NTP) を用意し、 KDC を正しく設定して開始することができたら、あとはクライアント側のマシンの設定になります。 Kerberos のクライアントを設定するには、下記で説明している 2 つの手作業のうち、いずれかを実施してください。

Kerberos を設定するにあたっては、 2 種類のアプローチをとることができます。 1 つは /etc/krb5.conf ファイルを利用したクライアントごとの手動の設定方法、もう 1 つは DNS を利用した動的な設定方法です。 DNS を利用する場合、 Kerberos のアプリケーションは DNS レコードを利用して KDC サービスがどこにあるのかを判断します。クライアントごとの設定を行う場合は、 krb5.conf 内に KDC サーバのホスト名を設定します (この場合、 KDC を別のホストに移動させるには、設定ファイルの更新を行うか、その他の方法で再設定を行う必要があります) 。

DNS ベースの設定のほうがより柔軟な構成を取ることができるほか、クライアントごとの設定作業も大幅に削減することができます。ですが、レルム名と DNS ドメイン名が一致しているか、もしくはレルム名が DNS ドメインのサブドメインでなければならなくなります。それ以外にも、ネームサーバを攻撃してダウンさせてしまったり、 DNS レコードを偽装させたりするなどの方法で、 Kerberos のインフラストラクチャを混乱させることができてしまいます。とはいえ、最大限に攻撃が成功したとしても、サービスの提供を妨害するまでのことしかできませんし、クライアントごとの設定でも、 krb5.conf 内に IP アドレスではなくホスト名を記述してしまうと、 DNS への攻撃による妨害は発生しうることになります。

[libdefaults]
        default_realm = EXAMPLE.COM

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

[domain_realm]
.example.com = EXAMPLE.COM
www.example.org = EXAMPLE.COM

_kerberos.www.example.org.  IN TXT "EXAMPLE.COM"

[libdefaults]
        clockskew = 60

KDC のコンソールに直接アクセスすることなく、リモートから Kerberos のデータベースにプリンシパルを追加または削除できるようにするには、 Kerberos の管理サーバに対して、どのプリンシパルからの編集を許可するのかを /var/lib/kerberos/krb5kdc/kadm5.acl ファイルで設定します。このファイルは ACL (アクセス制御リスト) ファイルと呼ばれ、様々な操作に対して細かく権限を設定することができます。詳しくは man 8 kadmind で表示されるマニュアルページをお読みください。

ここでは、あなた自身に対してデータベースの管理者権限を割り当てます。具体的には、下記の内容をファイルに追加してください:

suzanne/admin              *

なお、 suzanne の箇所はあなた自身を表すユーザ名に置き換えてください。設定内容を反映させるには、 kadmind を再起動する必要があります。

これで kadmin ツールを利用して Kerberos の管理作業を行うことができるようになります。まずは管理者ロールに対するチケットを取得して、 kadmin サーバの接続時にそのチケットを使用します:

> kadmin -p suzanne/admin
Authenticating as principal suzanne/admin@EXAMPLE.COM with password.
Password for suzanne/admin@EXAMPLE.COM:
kadmin:  getprivs
current privileges: GET ADD MODIFY DELETE
kadmin:

getprivs コマンドを使用すると、取得済みの権限を確認することができます。なお、上記に示されているもので全ての権限となります。

例として、 suzanne のプリンシパルを編集します:

> kadmin -p suzanne/admin
Authenticating as principal suzanne/admin@EXAMPLE.COM with password.
Password for suzanne/admin@EXAMPLE.COM:

kadmin:  getprinc suzanne
Principal: suzanne@EXAMPLE.COM
Expiration date: [never]
Last password change: Wed Jan 12 17:28:46 CET 2005
Password expiration date: [none]
Maximum ticket life: 0 days 10:00:00
Maximum renewable life: 7 days 00:00:00
Last modified: Wed Jan 12 17:47:17 CET 2005 (admin/admin@EXAMPLE.COM)
Last successful authentication: [never]
Last failed authentication: [never]
Failed password attempts: 0
Number of keys: 2
Key: vno 1, Triple DES cbc mode with HMAC/sha1, no salt
Key: vno 1, DES cbc mode with CRC-32, no salt
Attributes:
Policy: [none]

kadmin:  modify_principal -maxlife "8 hours" suzanne
Principal "suzanne@EXAMPLE.COM" modified.
kadmin:  getprinc suzanne
Principal: suzanne@EXAMPLE.COM
Expiration date: [never]
Last password change: Wed Jan 12 17:28:46 CET 2005
Password expiration date: [none]
Maximum ticket life: 0 days 08:00:00
Maximum renewable life: 7 days 00:00:00
Last modified: Wed Jan 12 17:59:49 CET 2005 (suzanne/admin@EXAMPLE.COM)
Last successful authentication: [never]
Last failed authentication: [never]
Failed password attempts: 0
Number of keys: 2
Key: vno 1, Triple DES cbc mode with HMAC/sha1, no salt
Key: vno 1, DES cbc mode with CRC-32, no salt
Attributes:
Policy: [none]
kadmin:

上記の変更では、チケットの最大有効期限を 8 時間に変更しています。 kadmin コマンドに関する詳細や、利用可能なオプションの一覧については、 krb5-doc パッケージ、もしくは man 8 kadmin で表示されるマニュアルページをお読みください。

ここまではユーザ認証の部分のみを説明してきましたが、 Kerberos に対応するサービスでは、サービス側もクライアントに対して認証を行う必要があります。そのため、レルム内で提供されるサービスに対しては、サービスそのものを表す特殊なサービスプリンシパルを Kerberos データベース内に作成しなければなりません。たとえば ldap.example.com が LDAP サービスを提供するような場合、 ldap/ldap.example.com@EXAMPLE.COM という名前のサービスプリンシパルを作成する必要があります。

サービスプリンシパルは サービス名/ホスト名@レルム の形式で表します。ここで、 ホスト名 にはホストの完全修飾名を指定します。

利用可能なサービス名は下記のとおりです:

サービスプリンシパルはユーザプリンシパルと似ていますが、明らかな違いが存在しています。それは、サービスプリンシパルが鍵で保護されているのに対して、ユーザプリンシパルはパスワードで保護されているという点です。ユーザが KDC からチケット発行許諾チケットを取得した場合、 Kerberos 側でチケットを解読する際にパスワード入力が必要となります。この仕組みをそのままサービスプリンシパルにも適用してしまうと、たとえばシステム管理者が SSH デーモン向けのチケットを取得する目的で、 8 時間おきにパスワードを入力しなければならなくなってしまうため、現実的ではなくなってしまいます。

その代わり、サービスプリンシパルの場合は初期チケットの解読に鍵を使用するようになっています。鍵は管理者が KDC から一度だけ取り出したあと、 keytab と呼ばれるファイルに保存しておくものです。これにより SSH デーモンは鍵を読み込んで、必要なタイミングで新しいチケットを自動的に取得するようになります。既定の keytab ファイルは /etc/krb5.keytab にあります。

たとえば jupiter.example.com に対するホストサービスプリンシパルを作成したい場合は、 kadmin セッション内で下記のようにコマンドを入力します:

> kadmin -p suzanne/admin
Authenticating as principal suzanne/admin@EXAMPLE.COM with password.
Password for suzanne/admin@EXAMPLE.COM:
kadmin:  addprinc -randkey host/jupiter.example.com
WARNING: no policy specified for host/jupiter.example.com@EXAMPLE.COM;
defaulting to no policy
Principal "host/jupiter.example.com@EXAMPLE.COM" created.

新しいプリンシパルに対してパスワードを設定する代わりに、 -randkey フラグを指定して、 kadmin でランダムな鍵を生成するように指定します。これは、このプリンシパルに対してユーザ操作を不要にするために必要なフラグとなります。これがマシンに対するサーバアカウントとなります。

最後に、鍵を抽出してローカルの keytab ファイル /etc/krb5.keytab に保管します。このファイルはスーパーユーザが所有するファイルであるため、下記の kadmin シェルを実行する際には、 root でなければなりません:

kadmin:  ktadd host/jupiter.example.com
Entry for principal host/jupiter.example.com with kvno 3, encryption type Triple
DES cbc mode with HMAC/sha1 added to keytab WRFILE:/etc/krb5.keytab.
Entry for principal host/jupiter.example.com with kvno 3, encryption type DES
cbc mode with CRC-32 added to keytab WRFILE:/etc/krb5.keytab.
kadmin:

全ての作業が完了したら、 kinit で取得した管理チケットを破棄するため、 kdestroy を実行します。

警告: 不完全な設定を行ってしまうとユーザが締め出されてしまう問題について

Kerberos を不完全に設定してしまうと、 root ユーザを含め全てのユーザが締め出されてしまうことがあります。このような問題が起こらないようにするには、既存の PAM 設定内に pam_krb5 を追加した あと 、 pam_krb5 モジュールに ignore_unknown_principals ディレクティブを追加してください。具体的には、下記を実行します:

> sudo pam-config --add --krb5-ignore_unknown_principals

これにより、 pam_krb5 モジュールがアカウントフェーズの失敗を引き起こすエラーを無視するようになります。

openSUSE® Leap には pam_krb5 と呼ばれる PAM モジュールが用意されています。このモジュールは Kerberos のログインとパスワード更新に対応しており、コンソールのログインや su 、もしくは GDM のようなグラフィカルログイン時に使用することができます。つまり、ユーザ側でパスワードを入力することで、ユーザに成り代わって初期の Kerberos チケットを取得するような、全ての用途に使用することができるモジュールです。 PAM で Kerberos に対応するように設定するには、下記のコマンドを実行します:

> sudo pam-config --add --krb5

上記のコマンドを実行すると、既存の PAM 設定ファイル内に pam_krb5 を追加し、適切な順序で呼び出されるように設定を調整します。 pam_krb5 に対してより詳しい設定を行いたい場合は、 /etc/krb5.conf ファイルを編集したあと、 PAM に既定のアプリケーションを追加してください。詳しくは man 5 pam_krb5 で表示されるマニュアルページをお読みください。

pam_krb5 モジュールは、 Kerberos のチケットをユーザ認証処理の一部として受け付けるような、ネットワークサービス向けには設計されていません。このような用途については、後続の章をお読みください。

OpenSSH ではプロトコルバージョン 1 および 2 の両方で Kerberos 認証に対応しています。バージョン 1 では Kerberos のチケットを送信するための特殊なプロトコルメッセージが用意されています。バージョン 2 では Kerberos を直接使用するようなことは行っておらず、その代わりに GSSAPI (General Security Services API; 汎用セキュリティサービス API) を使用するようになっています。これは Kerberos 限定のプログラミングインターフェイスではなく、 SPKM のような公開鍵認証システムなどでも使用することのできる、下位の認証システムの特異性を隠蔽するように設計されたインターフェイスです。ただし、現時点では GSSAPI ライブラリは Kerberos のみに対応しています。

sshd で Kerberos 認証を使用するには、 /etc/ssh/sshd_config ファイルを編集して下記のオプションを追加します:

# 下記はプロトコルバージョン 1 用
#
# KerberosAuthentication yes
# KerberosTicketCleanup yes

# 下記はプロトコルバージョン 2 用 (こちらをお使いください)
GSSAPIAuthentication yes
GSSAPICleanupCredentials yes

あとは sudo systemctl restart sshd を実行して、 SSH デーモンを再起動してください。

プロトコルバージョン 2 で Kerberos 認証を使用するには、クライアント側でも同様に有効化を行う必要があります。クライアント側ではシステム全体の設定ファイル /etc/ssh/ssh_config で設定することができるほか、 ユーザ単位でも ~/.ssh/config ファイルを編集することで設定を行うことができます。いずれのファイルの場合も、 GSSAPIAuthentication yes のオプションを追加することになります。

これで Kerberos 認証を使用して接続できるようになります。 klist を実行すると、有効なチケットの一覧を確認することができます。あとは SSH サーバに接続するだけです。 SSH プロトコルバージョン 1 を強制的に使用したい場合は、コマンドラインで -1 オプションを指定してください。

ヒント: さらなる情報

/usr/share/doc/packages/openssh/README.kerberos ファイルには、 OpenSSH と Kerberos の関係について、より詳しい説明が書かれています。

ヒント: プロトコルバージョン 2 向けの追加ディレクティブについて

GSSAPIKeyExchange の仕組み (RFC 4462) に対応しています。このディレクティブは、どのようにしてホスト鍵を交換するのかを指定します。詳しくは sshd_config のマニュアルページ ( man sshd_config ) をお読みください。

Kerberos が認証機能を提供するのに対して、 LDAP では認証と識別の両方を提供します。両方のサービスを同時に動作させることもできます。

接続の機密を保持する目的で、 389 Directory Server ではさまざまなデータの暗号化方式に対応しています。 SSL/TLS 接続や StartTLS 接続、そして SASL による認証にそれぞれ対応しています。Simple Authentication and Security Layer (SASL) は認証用に設計されたネットワークプロトコルです。 openSUSE Leap での SASL 実装は cyrus-sasl と呼ばれます。それに対して Kerberos 認証は、 cyrus-sasl-gssapi パッケージが提供する GSS-API (General Security Services API) で行われます。 GSS-API を使用することで、 389 Directory Server は Kerberos のチケットを利用して、セッションの認証とデータの暗号化を使用することができます。

SASL フレームワークを使用することで、サーバへの認証方式に異なる仕組みを使用することができます。たとえば Kerberos の場合、認証は常に相互的に動作します。つまり、 389 Directory Server サーバに対して認証を行っているだけでなく、 389 Directory Server 自身もあなたに対して認証を行っていることになります。これは特に、攻撃者が不正に作成した偽サーバにアクセスしたりせず、正しい LDAP サーバに接続していることを確認するために必要な仕組みです。

Kerberos から 389 Directory Server に接続するようにするには、 ldap/ldap.example.com というプリンシパルを作成して、それを keytab 内に追加する必要があります。 389 Directory Server が認証時に使用する認可情報は、 keytab によって他のサーバに送信されます。 389 Directory Server では keytab を KRB5_KTNAME という環境変数を介して割り当てます。

> kinit suzanne@EXAMPLE.COM

> ldapwhoami -Y GSSAPI -H ldap://ldapkdc.example.com
dn: uid=testuser,ou=People,dc=example,dc=com
    

sec=sys と Kerberos のセキュリティレベルとの間で、動作が大きく異なるのは、グループのメンバー関係に関する箇所です。 Unix や Linux では、ファイルシステムへのアクセスはプロセスから届くものであり、そのプロセスには特定のユーザとグループが結びつけられています。また、ユーザは複数のグループに対するメンバーとなることができます。このような仕組みから、ファイルへのアクセス権は所有者とグループをベースにして行われます。

sec=sys を指定した場合、ユーザ ID とグループ ID 、そして最大 16 種類までの補助グループが、各リクエスト内に書き込まれてサーバ側に送られます。

ユーザが 16 種類以上のグループに対するメンバーである場合、それより多くのグループ情報は失われます。そのため、通常はユーザからアクセスできていたはずのファイルに対して、 NFS 経由にするとアクセスができなくなってしまうことがあります。このような理由から、 NFS を使用する場合は、最大でも 16 種類までの補助グループとなるよう、うまく構成して回避を行ってください。

ユーザが newgrp コマンドや set-group-id のプログラムを実行すると、いずれのコマンドとも所属するグループのリストを変更することができますので、これによって NFS へのアクセス結果が即時に変わることがあります。

なお、 Kerberos ではグループに関する情報は全く送信されません。ユーザが (Kerberos の 「プリンシパル」 で) 認証されると、ユーザ ID とそのプリンシパルに対するグループリストを元にして、検索を行うだけです。つまり、ユーザが 16 種類以上のグループに対するメンバーであった場合、ファイルへのアクセス許可判断は、それら全てのグループメンバー情報をもとに行われることになります。しかしながら、ユーザがクライアント側でグループ ID を変更しても、サーバ側にはその変更が送信されないため、アクセス権の判断には影響しません。

多くの場合、多数のグループにアクセスできるようになったことで、大きな利益がもたらされますが、グループが変更できなくてもあまり実害はありません。ただし、 Kerberos を使用しているサイトの管理者はその情報を認識し、実際に問題を引き起こしたりすることがないようご注意ください。

セキュリティ確保の目的で Kerberos を使用すると、メッセージの暗号化や解読に際して、 CPU の負荷がかかるようになります。どれだけの CPU 性能が必要かや、通常時と比べてどれだけ負荷が高くなるのかは、ハードウエアや用途によって大きく異なります。もしもサーバやクライアント側の CPU 性能が限界に達しているような場合は、 sec=sys を Kerberos に切り替えることで、顕著な性能劣化が現れることになります。 CPU の性能に余裕がある場合であれば、この移行作業で性能が変わることはありません。 Kerberos を使用することによる性能変化は、実際のハードウエアと環境でテストしてお確かめください。

負荷を軽減するための唯一の選択は、保護品質の設定です。 sec=krb5p よりも sec=krb5 のほうがずっと負荷の軽い処理になりますが、上述のとおり強力な機密保持は行われなくなります。それ以外にも、 Kerberos が利用する暗号化方式を変更する手もあります。これによって CPU 要件をより低減させることができます。とはいえ、変更することによる影響をよくよくご検討のうえ、変更を行ってください。

NFS で Kerberos を使用するように設定する際の性能問題という観点では、 KDC (鍵配送センター) として知られている Kerberos の認証サーバの可用性についてもご検討ください。

NFS を使用すると、他のサービスに対して Kerberos を使用すると負荷が増えるのと同様に、ある程度の負荷上昇が発生します。あるユーザ (Kerberos のプリンシパル) がサービスに対してセッションを確立した場合、たとえば特定の NFS サーバが公開するファイルにアクセスした場合、クライアントは KDC との間でやり取りを実施する必要があります。やり取りの結果セッション鍵を取得できれば、サーバとクライアントはしばらく直接やり取りできるようになります。これは Kerberos の設定である ticket_lifetime の設定に依存して決まります。

Kerberos の KDC サーバの配置を設計するのに重要な項目は、可用性とピーク使用量です。

DNS や LDAP などの名前検索サービスなどの他のコアサービスと KDC サーバとの間は適度に 「近く」 なるように設計し、各クライアントに対する適度な可用性を提供するようにしてください。 Kerberos ではデータベースの伝搬のために柔軟なモデルを採用しているため、複数の KDC サーバを用意することができます。これにより、キャンパス単位やビル単位、キャビネット単位でも、必要なサーバをわかりやすく配置することができます。それぞれのクライアントが近くにある Kerberos サーバを検出できるようにするための適切な方式として、それぞれのビルなどに DNS を水平展開して、それぞれで異なる応答をするように設定するやり方があります。このような方式を採用できない場合は、 /etc/krb5.conf ファイルをビルごとに別々の値にするなどして、適度に分散させるように設計してください。

Kerberos KDC へのアクセスはあまり頻繁に発生しないことから、負荷として考慮すべきことはピークタイムとなります。たとえば 9:00 から 9:05 の間に多くの人々がログインするような場合、夜間に比べるとその時間帯は非常に多くの毎分リクエストを受け付けることになります。 Kerberos サーバの負荷は LDAP サーバの負荷よりも高くなりやすいのですが、桁違いというほどではありません。一般的には、 LDAP のレプリカと同じやり方で Kerberos のレプリカを配置したあと、さらにサーバを増設する必要があるかどうかを性能監視で判断するのが良いでしょう。

Kerberos KDC のサービスは、パスワードの変更や新しいユーザの作成などの処理を扱う必要があることから、容易には分散させることができません。これらの処理は、単一のマスター KDC で行わなければなりません。

これらに対する更新処理はそれほど多く発生しないため、負荷に対する要件もあまり厳しくありません。ですが、可用性という観点は重視する必要があります。可用性を考慮しておかないと、新しいユーザを作成したりパスワードを変更したりする際に時間がかかる場合があるほか、拠点によっては一時的にマスター KDC にアクセスできなくなってしまうこともあります。

組織が地理的に分散しているような場合で、各拠点に対する管理作業を拠点内で実施するような場合、それぞれ別々の Kerberos ドメインを作成して、それぞれの管理センターを 1 台ずつ構成するのがよいでしょう。それぞれのドメイン (拠点) には、それぞれのマスター KDC が存在することになります。一方のドメイン内のユーザが他のドメイン内のリソースにアクセスする場合でも、ドメイン間の信頼関係を設定することで解決することができます。

複数ドメインを扱う際の最も簡単な方法は、グローバルドメイン (例: EXAMPLE.COM) とローカルドメイン (例: ASIA.EXAMPLE.COM, EUROPE.EXAMPLE.COM など) をそれぞれ構築する方法です。グローバルドメインはそれぞれのローカルドメインを信頼するように設定し、それぞれのローカルドメインはグローバルドメインを信頼するように設定すれば、任意のドメイン間で完全な信頼を実現できますので、どのドメインに属するプリンシパルであっても、任意のサービスを利用できるようになります。なお、リソースに対して適切なアクセス許可を設定する作業については、ユーザ名の参照方法や NFS ファイルサーバの機能によって異なりますので、ここでは説明していません。