Kerberos との最初の通信は、通常のネットワークシステムにおけるログイン処理と とても似ていて、ユーザ名を入力します。この情報とチケット発行サービスの名称 が認証サーバ (Kerberos) に送信されます。認証サーバがそのユーザ名を知って いた場合は、今後使用するセッション鍵を乱数から生成し、クライアントとチケット 発行サーバに送信します。あとは認証サーバが、チケット発行サーバのチケットを 用意します。このチケットは、認証サーバとチケット発行サーバだけが知る セッション鍵ですべて暗号化され、下記の情報が含まれています:

このチケットはセッション鍵とともにクライアントに送り返されますが、 この時点ではクライアントからの機密鍵を利用します。この機密鍵は Kerberos とクライアントだけが知るもので、これはユーザのパスワードから生成される ものです。クライアントがその応答を受け取ると、パスワードを尋ねられます。 このパスワードは鍵に変換されたあと、認証サーバが送信したパケットを復号 するのに使用され、ようやく暗号という 「包装を解く」 ことが できることになります。また、パスワードはクライアントのメモリから消去 されます。チケットに書かれた有効期限が切れるまでの間に、そのチケットの 鍵を利用して次のチケットを取得することで、クライアントはその正当性を 維持できることになります。

ネットワーク内にあるサーバのサービスに対して要求を送信する際は、まず クライアントアプリケーションがサーバに対して自身の識別情報を証明する 必要があります。そのため、アプリケーションは認証情報を生成します。 認証情報には下記の情報が含まれています:

これらの情報は、このサーバ用にクライアントが受信したセッション鍵で、 すべて暗号化されます。その後、認証情報とチケットはサーバ側に送信されます。 サーバ側ではセッション鍵のコピーを利用して認証情報の解読を行ないます。 この解読によってクライアントが必要としているサービスについて必要な情報を すべて得ることができるほか、チケット内に含まれている情報とも比較を行なう ことができます。サーバ側ではチケットと認証情報が、いずれも同じ クライアントから発信されたものであることを確認します。

サーバ側で何らかのセキュリティ対応が行なわれていない場合、処理の中でも この段階がリプレイ攻撃として格好の標的になりかねません。誰かがネットワーク 越しに盗聴した情報を元に、要求を再送信できてしまいます。これを排除する ため、サーバ側では以前に受け付けたタイムスタンプおよびチケットを持つ 要求を受け付けないようにしています。これに加えて、要求を行なった時点とは 大きく異なる要求についても、無視されるようになっています。

Kerberos の認証は双方向に利用することができます。クライアントがサーバに 対して自身の正当性を主張するだけでなく、サーバがクライアントに対して正当性 を主張することができます。そのため、サーバ側でも認証情報を送信します。 クライアントの認証情報として受け取った中にあるチェックサムに対し、これを 追加してサーバとクライアント間で共有されているセッション鍵で暗号化します。 これにより、クライアントはサーバの正当性を応答の形で確認することができる ため、これで相互の認証が完成したことになります。

チケットは同時に 1 つのサーバでのみ使用されるように設計されています。 これは、クライアント側で他のサービスを利用するような場合には、新しい チケットを取得しなければならないことを意味しています。 Kerberos では サーバごとにチケットを取得する仕組みが備わっていて、これを 「チケット発行サービス」 と呼んでいます。チケット発行 サービスはその名の通りサービス (他のサービスと同様の位置づけ) で、 他のサービスと同じアクセスプロトコルを利用します。アプリケーションが ある特定のサービスにアクセスする必要がある場合は、まずチケット発行 サーバに対して通信を行ないます。この要求には下記のものが含まれています:

他のサーバと同様に、チケット発行サーバもチケット許可チケットと認証情報を 確認します。これらが正しいものであると判断された場合は、チケット発行サーバ は元々のクライアントとサーバとの間で使用する新しいセッション鍵を生成します。 あとは新しいサーバに対するチケットを構築します。このチケットには下記のもの が含まれます:

新しいチケットには有効期間が設定されていて、それぞれチケット許可チケット の残り有効期限か、サービスに対する有効期限のいずれか小さいほうが割り当て られます。クライアントは、チケット発行サービスが送信したチケットと セッション鍵を受け取りますが、この時点での応答は元々のセッション許可 チケットから生成されるセッション鍵で暗号化されています。クライアントは 新しいサービスに通信する際、ユーザのパスワード無しでこの応答を解読する ことができます。これにより、 Kerberos はユーザ側に問い合わせを行なう ことなく、チケットを継続的に取得できるようになっています。

Windows 2000 には Kerberos 5 の Microsoft 版の実装が含まれています。 openSUSE® では Kerberos 5 の MIT 版の実装を使用していますので、 詳しい情報やガイドについては、 MIT のドキュメンテーション 6.5項 「さらなる情報」 をお読みください。

Kerberos を完全に機能させるためには、 Kerberos を利用する環境が下記の 要件を満たしていなければなりません:

下記の図では、 Kerberos の仕組みを構築するにあたって最小限のものを 揃えた場合の例を示しています。ネットワークの規模や配置環境に合わせて、 下記の設計を調整すべきものです。

図6.1 Kerberos のネットワーク構造¶

	サブネットルーティングの設定
図6.1「Kerberos のネットワーク構造」 のような構成で構築する際は、 2 つの サブネット (192.168.1.0/24 と 192.168.2.0/24) の間でルーティングを 設定してください。 YaST でのルーティング設定方法について、詳しくは 項 「ルーティング (経路制御) の設定」 (第13章 ネットワークの基礎, ↑リファレンス) をお読みください。

Kerberos による認証の範囲のことを、領域 (realm) と呼びます。これは名前 によって識別するもので、たとえば EXAMPLE.COM のような 形式をとる場合があるほか、単に ACCOUNTING のような 名前にする場合もあります。 Kerberos は大文字と小文字を区別する仕組みで あるため、 example.com と EXAMPLE.COM は別々の領域を意味することになります。大文字と小文字のどちらを使用しても かまいませんが、一般的には領域名に大文字を使用します。

DNS のドメイン名 (または ACCOUNTING.EXAMPLE.COM のような サブドメイン) を使用するのも良い考えです。下記に示しているとおり、 Kerberos のクライアントで DNS を設定し、 KDC やその他の Kerberos サービスを発見する ように設定すると、設定を単純化することができます。これを行なうには、領域の 名称を DNS のサブドメインとして設定するのがよいでしょう。

なお、 DNS の名前領域とは異なり、 Kerberos は階層構造をとることができません。 たとえば EXAMPLE.COM という領域があるとすると、 DEVELOPMENT や ACCOUNTING のような 「副領域」 をその下に作成し、それらを EXAMPLE.COM にあるプリンシパルの副次的な領域とすることはできません。その代わり、これらを 3 種類の個別の領域とし、ユーザに対して領域をまたがる認証を設定し、 一方の領域のユーザやサーバを他方のユーザやサーバと協調的に動作させることが できます。

単純化のため、下記の説明では企業全体で 1 つの領域を設定するものと仮定します。 この章の残りの部分では、 EXAMPLE.COM という領域を使用する ものとして説明します。

Kerberos を使用するために最初に用意しなければならないことは、鍵配布センター (KDC と略します) として動作するマシンです。このマシンは Kerberos のユーザ とパスワードなど、すべての情報に関するデータベースを保持します。

KDC はセキュリティ面で最も重要な部分です。もしも誰かがそれに侵入できてしまう と、 Kerberos で保護しているすべてのユーザアカウントとデータ構造を取得できて しまいます。 Kerberos のデータベースにアクセスできてしまえば、そのデータ ベースに書かれている任意のプリンシパルに偽装することもできてしまいます。 そのため、このマシンに対するセキュリティはできるだけ厳しく設定する必要が あります:

Kerberos が正しく動作するようにするため、ネットワーク内の全サーバについて、 システム時刻を特定の時刻発信源で同期できていることを確認してください。 これは Kerberos で認証情報のリプレイを防ぐために、重要な項目です。 攻撃者がネットワーク上を流れる Kerberos の認証情報を盗聴すると、それを 利用してそのユーザを偽装することができてしまうためです。 Kerberos では これを防ぐために複数の防御を備えています。その防御のうちの 1 つがタイム スタンプです。これをチケット内に書き込んでおくことで、チケットを受信する サーバが現在時刻とは異なるチケットを受け取った場合、これを無視することで リプレイを防いでいます。

また、 Kerberos ではタイムスタンプの比較にあたって、一定量の余裕を持たせて います。しかしながら、コンピュータの時刻はその正確性を維持するのに不十分な 作りになっています。場合によっては 1 週間で 30 分も狂うような場合さえ あります。このような理由から、ネットワーク内に存在するすべてのホストでは 特定の時刻発信源による同期を設定してください。

これを実現するのに最も簡単な方法は、いずれか 1 台のサーバに NTP 時刻サーバを インストールすることです。また、残りのマシンではクライアントモードで NTP デーモンを動作させるか、もしくは 1 日 1 回程度 ntpdate を動作させるか (こちらの方法は少数のクライアントしか存在していない場合に 限られます) を設定します。 KDC それ自身についても、同じ時刻発信源に対して 同期を設定する必要があります。 NTP デーモンをそのマシンで動作させるのは セキュリティリスクとなりうるものであるため、 cron を利用して 1 日 1 回 程度の同期を設定するのがよいでしょう。 NTP クライアントの設定について、 詳しくは 項 「YaST を利用した NTP クライアントの設定」 (第17章 NTP を利用した時刻同期, ↑リファレンス) に書かれています。

また、別の方法として、専用の NTP サーバを用意してそこにハードウエアの 時刻参照源を設定し、ここから NTP デーモンによる時刻同期を設定する方法が あります。

また、 Kerberos に対してタイムスタンプの比較の際、時刻の最大誤差を調整 する方法もあります。この値 (clock skew (時刻誤差) と呼びます) は krb5.conf ファイルから設定することが できます。詳しくは 6.4.6.2.3項 「時計の誤差の調整」 をお読みください。

この章では、 KDC のインストールと初期設定、および管理者プリンシパルの 作成方法について述べています。この作業は複数の手順から構成されています:

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 will be prompted for the database Master Password.
It is important that you NOT FORGET this password.
Enter KDC database master key:  
Re-enter KDC database master key to verify:  

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 geeko

geeko@EXAMPLE.COM's Password: 
Verifying password: 

DNS や NTP などのインフラが整っていて、かつ KDC の設定と起動が完了して いれば、ようやくクライアントマシン側の設定を行なうことができます。 YaST を利用して Kerberos クライアントを設定するか、もしくは下記に示す 2 つの手作業で実施することができます。

6.4.6.1. YaST を利用した Kerberos クライアントの設定¶

Kerberos クライアントとして動作させるにあたって、関連する全ての設定を 手作業で変更するよりも、 YaST にその作業を行なわせたほうが便利です。 Kerberos クライアントは、お使いのマシンをインストールする際に設定する ことができるほか、インストール済みのマシンでも設定することができます。 具体的には下記の手順で行ないます:

1. root でログインし、 ネットワークサービス+Kerberos クライアント を選択します (図6.2「YaST: Kerberos クライアントの基本設定」) 。

2. Kerberos を使用する を選択します。

3. DNS ベースの Kerberos クライアントを設定するには、下記の手順で行ないます:

   1. DNS ベースの固定の Kerberos クライアントを設定します。

      	DNS サポートの使用
      DNS サーバが Kerberos 関連のデータを提供していない場合は、 実行時に DNS から設定データを取得する のオプションを 選択することはできません。

   2. チケット関連の問題や OpenSSH への対応、時刻同期や拡張 PAM 設定などを 行なう場合は、 詳細設定 を押します。

4. 固定の Kerberos クライアントを設定するには、下記の手順で行ないます:

   1. まずはお使いの環境に合わせて、 既定のドメイン, 既定の領域, KDC サーバアドレス をそれぞれ設定します。

   2. チケット関連の問題や OpenSSH への対応、時刻同期や拡張 PAM 設定などを 行なう場合は、 詳細設定 を押します。

図6.2 YaST: Kerberos クライアントの基本設定¶

詳細設定 ダイアログでチケット関連のオプションを 設定する (図6.3「YaST: Kerberos クライアントの高度な設定」) には、 下記のいずれかを設定します:

• まずは 既定のライフタイム と 既定の更新可能なライフタイム について、日／時／分 単位で設定します (それぞれ数字の後に空白を開けずに d, h, m を入力すると、それぞれ日／時／分単位での設定になります。

• 完全な識別情報を転送できるようにする (チケットを他のホストで使用する 場合) には、 転送可能フラグ を選択します。

• また、特定のチケットを転送できるようにするには、 代理可能フラグ を選択します。

• お使いの OpenSSH に対して、 Kerberos 認証への対応を行なわせたい場合 は、関連するチェックボックスに印を入れます。これにより、クライアントは SSH サーバに対し、 Kerberos チケットを利用するようになります。

• Kerberos 認証について特定のユーザアカウントの範囲を除外したい場合は、 最小ユーザ ID の値を指定します。この値は、たとえば システム管理者 (root) を ログインさせたくない場合などに利用します。

• タイムスタンプとお使いのホスト時刻との間で、許される時刻差を設定する には、 クロックのズレ の値を設定します。

• NTP サーバを利用したシステム時刻の同期を行ないたい場合は、 NTP の設定 ボタンを押します。このボタンを押すと、 項 「YaST を利用した NTP クライアントの設定」 (第17章 NTP を利用した時刻同期, ↑リファレンス) で説明している YaST NTP クライアントダイアログが表示されます。設定が完了すると、 YaST は全ての必要な設定を行なった後、 Kerberos クライアントが利用できる ようになります。

図6.3 YaST: Kerberos クライアントの高度な設定¶

熟練者向け PAM 設定 と PAM サービス のタブでの設定方法について、詳しくは公式のドキュメンテーション (6.5項 「さらなる情報」 に参照先が書かれています) と man 5 krb5.conf のマニュアルページ (krb5-doc パッケージに含まれています) を お読みください。

[libdefaults]
        default_realm = EXAMPLE.COM

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

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

_kerberos.www.foobar.com.  IN TXT "EXAMPLE.COM"

[libdefaults]
        clockskew = 60

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

ここでは自分自身に対して権限を追加し、データベースを管理できるようにする ものとします。下記の行をファイルに追加します:

geeko/admin              *

ここで geeko は自分自身のユーザ名に置き換えて ください。設定を反映させるには、 kadmind を 再起動する必要があります。

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

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

getprivs コマンドを利用することで、その時点で持って いる権限を確認することができます。上記の例では、全ての権限を持っている ことを示しています。

ここではたとえば、 geeko のプリンシパルを修正すると します:

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

kadmin:  getprinc geeko
Principal: geeko@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" geeko
Principal "geeko@EXAMPLE.COM" modified.
kadmin:  getprinc joe
Principal: geeko@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 (geeko/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 パッケージ内をご覧ください。 または、 http://web.mit.edu/kerberos/www/krb5-1.8/krb5-1.8.3/doc/krb5-admin.html#Kadmin%20Options や man8 kadmin のマニュアルページにも 記述があります。

ここまでの章では、ユーザの認証情報のみを取り扱ってきました。 Kerberos 互換の サービスでは、サービスそれ自身がクライアントに対して認証を行なう必要も あります。そのため、サービス側のプリンシパルについても、提供範囲の領域にある Kerberos データベースに登録しておかなければなりません。たとえば ldap.example.com で LDAP サービスを提供している場合、サービスプリンシパルとして ldap/ldap.example.com@EXAMPLE.COM を登録し、全クライアントに 対して認証できるようにする必要があります。

サービスプリンシパルの表記は、 サービス/ホスト名@領域 のように記述します。ここで hostname には、ホストの 完全修飾ドメイン名を記述します。

サービス記述子として利用可能なものは下記のとおりです:

サービスプリンシパルはユーザプリンシパルに似ていますが、大きく異なる箇所 があります。ユーザプリンシパルの鍵はパスワードで保護されていて、ユーザが KDC からチケット許可チケットを受け取ると、チケットを復号化するために パスワードの入力が必要になります。このような仕組みはサービスプリンシパル には非常に不便なものになってしまい、このままであったとすると、たとえば SSH デーモンを動作させている場合、 8 時間ごとにパスワードの入力が必要に なってしまいます。

サービスプリンシパルでは、初期のチケットを復号化するのに必要な鍵は管理者 が KDC から一度だけ取り出すものとし、 keytab と 呼ばれるローカルファイルに保管します。 SSH デーモンのようなサービスで あれば、この鍵を読み込んで使用し、必要であれば新しいチケットを自動的に 取得します。 keytab ファイルは、既定では /etc/krb5.keytab に配置されています。

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

kadmin -p geeko/admin
Authenticating as principal geeko/admin@EXAMPLE.COM with password.
Password for geeko/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:

上記の処理が完了したら、忘れずに kdestroy コマンドを 利用し、 kinit で取得した管理チケットを破棄してください。

openSUSE® では pam_krb5 という PAM モジュールが 同梱されていて、これを利用することで Kerberos のログインとパスワード更新を 行なうことができるようになっています。このモジュールは、コンソールでの ログインや su, KDM などのグラフィカルなログインアプリケーション (ユーザがパスワードを提供し、認証対象のアプリケーションに対して初期の Kerberos チケットを取得させたい場合) で利用することができます。 Kerberos に対応するよう PAM を設定するには、下記のコマンドを入力します:

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 固有のプログラミングインターフェイスというわけではなく、 Kerberos や SPKM のような公開鍵認証システムなどのような、認証システムの特異性を隠蔽するため の仕組みです。ただし、同梱の GSSAPI では Kerberos にのみ対応しています。

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

# プロトコルバージョン 1 向けの設定 
#
# KerberosAuthentication yes
# KerberosTicketCleanup yes

# プロトコルバージョン 2 向けの設定 - できればこちらを利用してください
GSSAPIAuthentication yes
GSSAPICleanupCredentials yes

設定を変更したら、 rcsshd restart と入力して 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 の作用についてより詳しい説明が 書かれています。

Kerberos を使用する場合、ユーザの情報 (ユーザ ID, グループ, ホーム ディレクトリなど) をネットワーク内に配布するには、 LDAP を利用するのが 唯一の方法です。 LDAP を利用するにあたっては、パケットの盗聴やその他の 攻撃から防御するため、強度な暗号化メカニズムを設定する必要があります。 1 つの解決策として、 LDAP の通信そのものに対しても Kerberos を利用する 方法があります。

OpenLDAP では多くの認証手順を SASL 経由で実装しています。 SASL とは Simple Authentication Session Layer の略で、シンプルな認証機能を提供する ものです。 SASL は基本的には認証に使用するよう設計されたネットワーク プロトコルですが、 SASL の実装は cyrus-sasl と呼ばれるもので、数多くの 認証方法に対応した実装になっています。なお、 Kerberos の認証は GSSAPI (General Security Services API) 経由で行ないます。既定では GSSAPI の SASL プラグインはインストールされていないため、 LDAP を利用する際には YaST から cyrus-sasl-gssapi パッケージを インストールしてください。

Kerberos に対して OpenLDAP サーバへの接続を有効にするには、 ldap/ldap.example.com という名称のプリンシパルを作成し、 これを keytab 内に追加します。

既定では、 LDAP サーバ slapd は ldap のユーザおよびグループで 動作し、 keytab ファイルは root でのみ読み込むことができるようになっています。そのため、 LDAP 側の設定を 変更して root で動作するように 設定するか、もしくは keytab ファイルを ldap グループから読み込むことができるように設定する必要があります。後者は /etc/sysconfig/openldap ファイル内で OPENLDAP_KRB5_KEYTAB の変数に対し、 keytab ファイルの 場所を指定し、かつ OPENLDAP_CHOWN_DIRS の変数に対して yes を設定した場合、 OpenLDAP の起動スクリプト (/etc/init.d/ldap) が自動的に設定します。これらの 設定はあらかじめ設定済みのため、特に変更を行なう必要はありません。 また、 OPENLDAP_KRB5_KEYTAB に何も指定しない場合は、 /etc/krb5.keytab 以下にある既定の keytab が使用され、 下記のように権限を手作業で設定しなければなりません。

slapd を root で起動するには、 /etc/sysconfig/openldap ファイルを編集します。それぞれ OPENLDAP_USER と OPENLDAP_GROUP の値に対して、行頭にコメント (#) マークを入れてコメントアウトしてください。

グループ LDAP に対して keytab ファイルの読み込みができるようにするには、 下記のように実行します:

chgrp ldap /etc/krb5.keytab
chmod 640 /etc/krb5.keytab

もう一つの (そしておそらく最適であると思われる) 方法として、 OpenLDAP に対して 独自の keytab ファイルを用意する方法があります。これを行なうには kadmin を 起動し、 ldap/ldap.example.com のプリンシパルを追加した後、下記のようなコマンドを 入力します:

ktadd -k /etc/openldap/ldap.keytab ldap/ldap.example.com@EXAMPLE.COM

その後、下記のように実行します:

chown ldap.ldap /etc/openldap/ldap.keytab 
chmod 600 /etc/openldap/ldap.keytab

さらに、異なる keytab ファイルを使用するように OpenLDAP 側を設定する には、 /etc/sysconfig/openldap 内にある下記の 変数を変更します:

OPENLDAP_KRB5_KEYTAB="/etc/openldap/ldap.keytab"

最後に rcldap restart のコマンドを実行し、 LDAP サーバを再起動すれば完了です。

ldapsearch -b ou=people,dc=example,dc=com '(uid=geeko)'

SASL/GSSAPI authentication started
SASL SSF: 56
SASL installing layers
[...]

# geeko, people, example.com
dn: uid=geeko,ou=people,dc=example,dc=com
uid: geeko
cn: Olaf Kirch
[...]

# 全てのものをうまく動作させるために必要な設定です
access to dn.base="" by * read
# 各ユーザに対して、自身のログインシェルを変更できるようにする設定
access to dn="*,ou=people,dc=example,dc=com" attrs=loginShell
       by self write
# 各ユーザが全てのものを読み込めるようにする設定
access to *
       by users read

authz-regexp
   uid=(.*),cn=GSSAPI,cn=auth 
   uid=$1,ou=people,dc=example,dc=com