この文書は、スウェーデンのストックホルム王立技術研究所(Kungliga Tekniska H skolan)から配布されるKerberos4について文書化を試みたものです。この配布 版はeBonesを基にしてますが、色々な改良がされています。このプログラムは、 ごく最近のUNIX互換システムであればどこでも動くはずです。
UNIXに加えて、以下のプラットホームでも部分的には動作します：
基本的には、ANSI C コンパイラと、dbmライブラリ（サーバ側）と、 BSD ソケットのある POSIX 準拠のシステム上であれば動作するはずです。
ウェブページが http://www.pdc.kth.se/kth-krb/ にありますのでご利用
下さい。
もし、プログラムを構築できなかったり、構築したプログラムが思うように動か
なかったりした場合は、バグレポートを送って下さい。バグレポートの送り先は
<kth-krb-bugs@pdc.kth.se>にして下さい。必ず、どういうマシンとオ
ペーレティング・システム(バージョンも)とでプログラムを走らせたかと、何が
起きてそれについてどのようなことが起こっていたと思うかと、それを再現する
ための例、および、その例を実行した時の出力を付けて下さい。それから、もし、
その問題に対するパッチがあればそれも含むめた情報を下さい。すべてのパッチ
はdiff -uかdiff -cで作って下さい。バグレポートがより詳細で
あれば、その分、より早く我々もそれを再現し、理解し、修正することができま
す。
バグレポート以外の助言やコメントなども歓迎します。送り先は、
<kth-krb@nada.kth.se> です。
Now this Cerberus had three heads of dogs,
the tail of a dragon, and on his back the
heads of all sorts of snakes.
-- Pseudo-Apollodorus Library 2.5.12
ケルベロス(Kerberos) はネットワーク上でユーザとサービスを認証するためのシステムです。そのシステムはネットワークが "安全でない" という仮定にたって築かれています。たとえば、ネットワークを越えて送られたデータは抜き取られたり、変更されたり、アドレスを偽らされたりすることがあり得ます。それゆえ、ネットワークを越えたデータを認証目的に使うことはできません。
ケルベロスは信頼できる第三者機関のサービス(a trusted third-party service)です。これは、ネットワーク上のすべての実体(entities:ユーザとサービス、通常 プリンシパル(principals)と呼ばれる)により信頼される第三者機関(ケルベロス・サーバ)があることを意味します。 すべてのプリンシパルは、ケルベロス・サーバと秘密のパスワード(または鍵)を共有し、これでプリンシパルはケルベロス・サーバからのメッセージが本物であることを証明することが可能になります。こうして、ケルベロス・サーバ、ユーザおよびサービスを信任することで、お互いを認証し合うことができます。
ケルベロスの中で、プリンシパルは彼らが要請をする誰かに彼らであることを証明するために 切符(ticket) を使います。次の例では、A は認証交換のイニシエータ、通常はユーザで、そして、B は A が使いたいと願うサービスです。
特定のサービスのための切符を手に入れるために、A は切符の依頼をケルベロスサーバに送ります。その依頼は基本的に Aの名前と Bの名前とを含んでいます。ケルベロス・サーバは A と B の両方が正当なプリンシパルであることを確認します。
プリンシパルの正当性が証明されると、A と B の名前、A のネットワークアドレス(A@sub{addr})、現在の時刻 (@var{t@sub{issue}})、切符の寿命(life)、および、秘密の セッション鍵 (K@sub{AB}) を含むパケットを作ります。このパケットは B の秘密鍵で暗号化されます (@var{K@sub{B}})。実際の切符 (@var{T@sub{AB}}) は次のように見えます。
({A, B, A@sub{addr}, @var{t@sub{issue}}, life, @var{K@sub{AB}}}@var{K@sub{B}})
A への返信は、切符 (T@sub{AB})、B の名前、現在の時刻、切符の寿命、および、セッション鍵で、すべて A の秘密鍵 ({B, @var{t@sub{issue}}, life, @var{K@sub{AB}}, @var{T@sub{AB}}}@var{K@sub{A}}) で暗号化されます。A は後で使うためにその返信を解読し保持します。
メッセージを B へ送る前に、A は A の名前, A のアドレス, 現行時刻, および A に選ばれた "チェックサム" からなる認証子をつくります。それらは、すべて秘密のセッション鍵 ({A, A@sub{addr}, @var{t@sub{current}}, checksum}@var{K@sub{AB}}) で暗号化されてます。これはケルベロス・サーバから B によって受け取られる切符と供に送られます。受け取る際に、 B は B の秘密鍵でその切符の暗号を解読します。その切符には、認証子を暗号化したセッション鍵が含まれているので、ここで B は暗号化された認証子を解読できるようになります。A が本当に A であることを証明するために、B はここで切符の内容をその切符の認証子と比較しなければなりません。もしすべてが合致すれば、 B はここで、A が確かに認証されたと考えます。
一人の偽者 C がネットワークを越えて転送される認証子と切符とを盗むことができ、それを使って A に成りすますことができるとします。切符の中のアドレスと認証子が加えられて、この攻撃を達成することをより難かしくしてます。C が成功するためには、A と同じマシンを使うか、パケットのソース・アドレスを偽る必要があります。認証子に時刻印を含めることにより、 C が攻撃をするための十分な猶予は無くなります。
C が B のネットワーク・アドレスを偽装することができ、A が B (彼女)の信任状を送ると、C はそれをただ単に証明するふりをすることができます。C には B (彼女)が A に語りかけようとしていることがわかりません。
サーバ側に リプレー・キャッシュ を加えることは可能でしょう。考え方は、最後の数分間に送られた認証子を保存し、そうすると、誰かが既に使われたメッセージを再送しようとしたときに、B はそれを検知することができます。これは、幾分か(性能に関してほとんど)実用的でなく、Kerberos 4 には有りません； MIT Kerberos 5 は持っています。
B を認証するために、A は、セッション鍵にアクセスしようとしているのが B であることを証明する何かを B が 送り返すことを依頼するでしょう。この例が、A が認証子の一部として送るチェックサムです。ある典型的な手順はチェックサムに１を加え、それをセッション鍵で暗号化して A に送り返すことです。 これは、相互認証 と呼ばれます。
セッション鍵は暗号学的チェックサムを A と Bの間で送られるメッセージに加えるためにも使うことができます(メッセージ保全として知られます)。暗号化も加えられます(メッセージの内密性)。これがおそらくすべての場合において最良のアプローチです。
ケルベロスについての元の論文は、1988 年のJennifer Steiner, Clifford Neuman および Jeffrey I. Schiller による Kerberos: An Authentication Service for Open Network Systems です。
あまり技術的にならない記述は 1988年の Bill Bryant による Designing an Authentication System: a Dialogue in Four Scenes です。
これらの他、幾つかの文書が我々のウェブページ上で見つけられます。
配布されているソースコードから構築するか、あるいは、もしマシンに合った実行モジュール(binaries)が用意されていればそれをインストールするかを選択できます。
もちろん、ソースからの構築をお奨めしますが、コンパイル済みの実行モジュールを使った方がより簡単です。 マシンに合った実行モジュールが無かったり、特別な設定を行ないたいならば、ソースからコンパイルします。
このソフトウェアを構築するには、配布されたアーカイブを展開(un-tar) して、configure スクリプトを走らせます。
正しくコンパイルするためには、gcc のような、ANSI C コンパイラが必要です。他のコンパイラでも動きますが、あまりにも、"ANSI 準拠" に設定し過ぎると、一部のコードでは、標準インクルード・ファイルがないために失敗するでしょう。
構築を個々のツリーで行なうには、ツリーの基のディレクトリで configure を走らせますが、Make が VPATH を正しく理解するようにする必要があります。GNU Make ならうまくできます。
全てが構築できたら(構築をする場所により数分からあるいはもっと長い時間を要します)、make installにより(root で走らせて)全てを `/usr/athena' にインストールできます。他の場所にインストールすることも可能ですが、あまりお奨めしません。もし、そうしたければ、configure で `--prefix=/my/path' を付けて走らせます。
既定(default)の振舞を変えるためには、configure の際に以下のオプションを指定できます:
kadmind. このオプションには
パッチ ftp://ftp.pdc.kth.se/pub/krb/src/cracklib.patch の当たった cracklib が必要です。
http://www.socks.nec.com/ をご覧下さい。
ftp や kadminで可能にするには、どのバージョンの readline 使ってもできます。もし、readline をインストールされていても、configure でうまく見つけられないときにこのオプションを使います。configure は libedit も捜します。もし、ライブラリが見つからない時は、バンドルしてある editline を使うことになるでしょう。
popper のみがアクセスし、
login 時にメールをチェックします。
push
で、Hesiod のサポートをします。
このオプションにより、ヘシオド・ライブラリを使ってユーザのメールを郵便局に置こうとします。
kdestroy を作ります。
実行モジュールの配布は、`/usr/athena'にインストールされることを想定して、動かないもしれませんので他の場所にインストールすることは奨めしません。他の場所にインストールせざるを得ないときは、`/usr/athena' から、インストールされたディレクトリにシンボリックリンクを張ると良いでしょう。
インストールのとき root にUID設定(setuid)しなければならないプログラムは su だけです。
もし、
rlogin や rsh が root に UID設定(setuid)されてしまうと、ケルベロス化されたプログラムがなんらかの理由で失敗したときのように、ケルベロスを使わないプロトコルに戻ってしまいます。
古いプロトコルではセキュリティのために予約済のポートを使っているため、プログラムは root に UID設定されていなくてはなりません。もし、こうすることが必要無ければ、UID設定ビットを外すことを検討して下さい。
login は、いつも root が走らせるので、UID設定される必要はありません(ユーザは login ではなく su を使うべきです)。root に UID設定されないまま、ユーザが走らせたときは、何らかの手がかりとなる情報が表示されます。
ユーザが走らせることを意図したプログラムは `/usr/athena/bin' にあります。ユーザに `/usr/athena/bin' をパスに含めるよう知らせて下さい。あるいは、実行モジュールを適当な場所にコピー、または、シンボリック・リンクしてください。おそらく、使いたいプログラムは：
kauth/kinit,
klist, kdestroy, kpasswd, ftp,
telnet, rcp, rsh, rlogin, su,
rxtelnet, tenletxr, rxterm, および
xnlock でしょう。 もし AFS をお使いであれば、afslog と pagsh
もまた便利です。管理者は、`/usr/athena/sbin' にある kadmin と ksrvutil を使うと便利です。
telnetd と rlogind は login が
`/usr/athena/bin' (あるいは`--prefix' に指定したパス) にあることを前提にしていす。もし、なんらかの理由で login を移動したければ、
telnetd
と
rlogind
を `inetd.conf' の中に設定するときに、 `-L' 切替で新たな場所を指定しなければならないでしょう。
システムの既定の login をケルベロス化された login と置き換えることも可能なはずです。しかしながら、あるシステムでは login が、我々の login ではしないような、ある非常に重要な(我々がいくらやろうとしてもできないような)トリックを演じることを仮定してます。ですから、マシンの置換えを全て行なう前に何がおこるかを試してみましょう。また、提供されている認証モジュール(see section Authentication modules)の一つを使えることも試してみるべきです。
我々の使った login プログラムは、NetBSD の標準ログインプログラムの初期のころのもから派生したものです。それを沢山の奇怪なシステム(Solaris, SunOS, IRIX, AIX, その他)で使うために、他の多くのシステムの login の特徴をもって "改善"されました。そのうちの幾つかの特徴は本当に便利で、その他のシステムでも使いたくなるようなものです。
それぞれのユーザは認定ファイル`~user/.klogin'を持つことができます。 は、どのプリンシパルがそのユーザとしてログインできるかを決定します。IPと特権ポートを基にした認証でないことを除けば、`~user/.rhosts' と似ています。もし、このファイルが存在しなければ、`user@LOCALREALM' のユーザ自身のログインが許されます。それに追随するローカル・レルム(see section Install the configuration files)も、ここで与えられます。もし、ファイルが存在すれば、ローカルのユーザuser としてログインすることが許される、他のプリンシパルが含まれるべきです。
ほとんどのデーモン( rlogind,rshd, ftpd, telnetd, popper, kauthd, ならびに kxd ) は、このファイルと協議して
そのプリンシパルが、要求するサービスを受けることを許されるかを決定します。
また、
su でも、誰が root になることを許されているかについてのアクセス制御リスト (ACL) を維持する良い方法としても使われています。
`~root/.klogin' に次のもの：
nisse.root@FOO.SE lisa.root@FOO.SE
が含まれることを仮定します。nisse と lisa というユーザは、どちらも root インスタンスのパスワードを入力することにより root に su することができます。 もし、`~root/.klogin' に含まれないユーザは su に失敗し、誰が su できるかについての普通の方針に戻ります。
nisse と lisa は、自分たちの root インスタンスのチケットを持てば、たとえば、telnet で root 権限でログインすることができることもここに記しておきます。
異なる認証機構を持つことの問題は幾つかのベンダーにより認識されてます、そして、幾つかの解決策が加えられてきました。ほとんどの場合は、これらの解決策ではある種の共有モジュールを動作時にロードして内包します。これらのシステムの幾つかのモジュールは `lib/auth' で見つけられます。現時点では、Digital の SIA、 Solaris や Linux の PAM、 それと、 IRIX の (`lib/auth/afskauthlib' にある) login と xdm です。
SIA モジュールをインストールする方法はどのバージョンOSの上で走らせるかに依存します。Tru64 5.0 には `siacfg' という新しいコマンドがあり、この過程をとても単純にします。もし、このプログラムがあれば、ただ単につぎのように走らせるだけです:
siacfg -a KRB4 /usr/athena/lib/libsia_krb4.so
古いバージョン、あるいはすべてを自分の手で行いのであれば、以下のように行います（ただし、Tru64 5.0 ではたしかめていません）。
xdm のような任意のアプリケーションをリスタートさせます。)
ローカル・パスワードの(`root'のような)ユーザは安全にログインできるはずです。 Compaq(Digital) の xdm を使う時、(xdm が環境を壊す(zaps)ので)渡すべき `KRBTKFILE' 環境変数が渡されません。その代わりに、`/usr/lib/X11/xdm/Xsession' の中に `KRBTKFILE' を正しい値に設定し直さなくてはなりません。次のような行を加えます。
KRBTKFILE=/tmp/tkt`id -u`_`ps -o ppid= -p $$`; export KRBTKFILE
もし、CDE を使っているなら、dtlogin がどの追加環境をエキスポートするべきかを指定することを許します。`KRBTKFILE' をこのリストに加えるには、`/usr/dt/config/Xconfig' を編集して、`exportList' の定義を捜してください。おおよそ次のようになるでしょう。
Dtlogin.exportList: KRBTKFILE
Digital の `ENHANCED' (C2) セキュリティ、 およびケルベロスは二つのことなる問題を解決します。ローカルセキュリティを扱う C2 は、誰が何をできるかや監査、および、同様なことをする上でより良い制御を加えます。ケルベロスはネットワーク・セキュリティを取り扱います。
C2 セキュリティがケルベロスと供に動くようにするためには、以下のことをする必要があります。
現状では、 `su' が裏打うちフラグを受け付けませんので、思ったようには働きません。
また、ケロベロス化された ftp は C2 パスワードでは動きません。これは Digital の ftpd と我々のものを別のポートで使うことにより解決できます。
もしこれらの変更をすると、かなり確実に C2 システムの要求を完全には満たさ 無く なることを 忘れないで下さい。 もし、C2 が欲しくても、誰かが無理矢理使わせようとしない限り、しばらくはあきらめて下さい。もし、それ以上できないくらいシステムをもっと安全にしてセキュリティを高めたければ、おそらくもっと安全なシステムを手に入れるでしょう。既にはっきりと分かるようなパスワードを送ったりはしてないでしょう。
IRIX のサポートは Transarc の `afskauthlib.so' と互換のモジュールです。このライブラリを使う全てのプログラムは動くはずで、`login' と `xdm'を含むはずです。
インターフェースについてはあまり文書化されていませんが、`libkafs.so', `libkrb.so' および `libdes.so' を `/usr/lib' にコピーするか、`afskauthlib.so' を静的に結合して構築するようです。
ファイル `afskauthlib.so' 自身は `/usr/vice/etc' か `/usr/afsws/lib' かあるいは、(それがある)現行のディレクトリに置かれていても良いようです。
IRIX 6.4 以降のすべてのプログラムは (`xdm' と `login' とを含みます)N32 オブジェクト・フォーマットですが、それより古いバージョンでは O32 オブジェクトです。それらが動くためには、`afskauthlib.so' ライブラリがそれをロードしようとしているプログラムと同じオブジェクト・フォーマットでなくてはなりません。このためには、既定の N32 に加えて O32 のための構成と構築をする必要があるということです。
これ以外には、設定ファイルはありませんので "まさに動く" はずです。
現時点で PAM モジュールは Linux と SunOS5(いわゆるSolaris) でしかテストしていません。おそらく、ほかのシステムでも働くでしょうが試したことはありません。
このモジュールを構築するには、引数 `--enable-shared' を configure にわたさなくてはなりません。なぜなら、PAM モジュールは共有ライブラリとしてロードされなくてはならないからです。共有ライブラリは、 PAM モジュールが正しい操作をするために、実行時においても利用可能でなくてはなりません。PAM モジュールの構成エラーを追跡するために `debug' 引数を渡してもかまいません。
共有ライブラリを構築するのに対して、スタンドアローンの PAM モジュール、すなわち、Kerberosの共有ライブラリに依存しないモジュールを作ることも可能です。これを行うためには、アーカイブ (.a) ライブラリにポジション依存のコードが要求されます。以下のステップはスタンドアローンの PAM モジュールを構築するために使えます:
datan$ env CFLAGS=-fpic ./configure datan$ make datan$ cd lib/auth/pam datan$ make datan$ make install
configure に `--enable-shared' を渡すべきでないことに注意し、CFLAGS の設定に注意します。このモジュールは、たとえ Kerberos ライブラリがロードできなくても、機能するでしょう。
このモジュールを使うには次のようにすべきです：
PAM モジュールにケルベロス・パスワードを変更するためのサポートは現在ありません。代わりに、kpasswd を使って下さい。
この PAM モジュールは、
ftp://ftp.dementia.org/pub/pamにある Derrick J Brashear <shadow@dementia.org> の Kerberos PAM モジュールに多大な影響を受けています。
Who willed you? or whose will stands but mine?
There's none protector of the realm but I.
Break up the gates, I'll be your warrantize.
Shall I be flouted thus by dunghill grooms?
-- King Henry VI, 6.1
レルム(realm)は管理上の領域です。ケルベロス(kerberos)レルムは通常大文字で書かれた(1)インターネット(Internet)のドメイン名(domain name)です。特別な理由が無い限り、レルムにインターネット・ドメイン名と同じ名前を付けて下さい。そうすると、あなたもあなたの回りの他の人々も楽になります。
ケルベロス・サーバ・プログラム を走らせるマシンを選定する必要があります。もし、ケルベロスのデータベースが在留するホストが開け渡されると、そのレルム全体が開け渡されてしまうことになります。それゆえ、このマシンはできる限り安全でなければなりません。できれば、ケルベロス以外のサービスを走らせるべきではありません。安全に配慮する管理者のみがコンソールにログインすることを許されるべきです。
このマシンには信頼性もなくてはなりません。もし、それがダウンすると、スレーブ・サーバを設置して(see section Install a slave kerberos server)いない限り、全てののケルベロス化されたサービスが受けられなくなってしまいます。
ケルベロス・サーバを走らせるには、少しの CPU パワーと小さなディスクが必要なだけです。数百メガバイトの空きディスク空間を持つ古い PC で十分でしょう。ほとんどのディスク空間は様々な記録(log)のために使えるでしょう。
二つの重要な構成ファイル(configration files)：`/etc/krb.conf' と `/etc/krb.realms' とがあります。
`krb.conf' ファイルではどのマシンが異なるレルムのサーバかを定義します。このファイルの書式は：
THIS.REALM SUPP.LOCAL.REALM THIS.REALM kerberos.this.realm admin server THIS.REALM kerberos-1.this.realm SUPP.LOCAL.REALM kerberos.supp.local.realm admin server ANOTHER.REALM kerberos.another.realm
最初の行にはローカル・レルムの名前を定義します。その次からの数行はオプションで、副次的なローカル・レルムの名前です。 このファイルの残りの行は、知っているすべてのレルムのケルベロス・サーバとデータベース・アドミニストレーション・サーバの名前を定義しています。4行目のように書けば、このレルムのケルベロス・スレーブ・サーバを幾つでも定義できます。クライアントは `krb.conf' に列挙されているサーバの順番で接触を試みます。
最初の記載文の `admin server' 句は、これがマスタ・サーバ (パスワードの変更のような、データベースを更新しようとするときに接触するもの。)ということです。これはそれぞれのレルム毎に一意にすべきです。
元の MIT Kerberos4では(他のほとんどにおいてと同様に)、サーバの指定はホスト名の形をとるだけです。(ファイアウォールの内側のような)限られた場所でケルベロス・サーバを設置するために、既定ポート(750)以外のポートと UDP 以外のプロトコルのサポートが加えられました。
現在、記載の正式な構文は`[proto/]host[:port]'です。proto は`UDP' か `TCP' か `HTTP', かで、port は問いかけるポートです。proto の既定値は `UDP' で port には、`kerberos-iv' が `/etc/services' の中に定義されていればそれを、でなれば、750 を既定値とします。もし proto が `HTTP' であれば、既定ポートは 80 になります。`HTTP' の記載は URL 書式でも指定できます。
SRV レコードは BIND 4.9.5T2A 以降でサポートされています。ゾーン・ファイルの 記述例は次のようになります：
kerberos-iv.udp.foo.se. 1M IN SRV 1 0 750 kerberos-1.foo.se. kerberos-iv.udp.foo.se. 1M IN SRV 0 0 750 kerberos.foo.se.
ケルベロス・マスタ・サーバを指す CNAME `kerberos.REALM' を加えることを、強くお奨めします。
`krb.realms' ファイルは特定のホストがどのレルムに属するかを見つけ出すのに使われます。このファイルの例は以下の通りです：
this.realm THIS.REALM .this.realm THIS.REALM foo.com SOME.OTHER.REALM www.foo.com A.STRANGE.REALM .foo.com FOO.REALM
点('.')から始まる記載はドメイン名として、点で始まらない記載はホスト名として解釈されます。最初に合致した記載が使われます。`this.realm' の記載は`this.realm' という名前のホストがある場合にのみ必要です。
もし、合致するレルムが `krb.realms' の中に見つからなければ、正しいレルムのために DNS で捜します。たとえば、もしホスト `a.b.c' を捜しているとすると、最初は `krb4-realm.a.b.c' が試され、そして `krb4-realm.b.c' がという具合になります。その記載は次のように、レルム名を含む TXT レコードにするべきです。
krb4-realm.pdc.kth.se. 7200 TXT "NADA.KTH.SE"
もし、これがドメイン名に無ければ、最初の部分が大文字のものが試されます。
もとの簡素なケルベロスでは、サーバとレルムを得るための垢抜けた方法を持たないので、一般的には `krb.conf' と `krb.realms' をいつも最新にしておくことが良い考えです。
これらの一般に使うファイルに加えて、`/etc/krb.extra' は、通常は使わないものを内包します。それは、`variable = value' の組から成り、空行と (#) で始まる行は無視されます。
現在、定義されている変数を以下に示します。ブーリアン／フラッグの変数は `true' または `yes' もしくは ゼロ以外の正数です。
krb_mk_safe,
krb_rd_safe, krb_mk_priv, およびkrb_rd_priv によ
るテスト順番をひっくり返します。このテストはファイアウォールを使う時に問題を起こし得ます。
`services.append' の内容をを `/etc/services' または NIS-map に追加あるいは混合するべきです。出荷時設定の使わないケルベロスのポート定義は、混乱の可能性を避けるために削除して下さい。
ほとんどのプログラムは `/etc/services' にポート番号が見つからなければ、既定のポートとなるでしょうが、いずれにしろそこにあった方が便利です。
既にケルベロス・サーバを走らせるマシンとレルム名を選んでいるはずです。そのマシンはケルベロス・サーバをインストールする前に可能な限り安全にしてあるはずです(see section Choose a kerberos server)。ここでの例では、ケルベロス・サーバを`FOO.SE' というレルムで `hemlig.foo.se' と呼ばれるマシンにインストールすることにします。
ケルベロス・サーバのコンソールに root でログインします。 `/usr/athena/bin' と `/usr/athena/sbin' をコマンド・パスに加えます。 データベースを保存するためのディレクトリ`/var/kerberos' を作り (mkdir /var/kerberos)、kdb_initを走らせます。:
hemlig# mkdir /var/kerberos hemlig# kdb_init Realm name [default FOO.SE ]: You will be prompted for the database Master Password. It is important that you NOT FORGET this password. Enter Kerberos master password: Verifying password Enter Kerberos master password:
もし、構成ファイルを正しく設定していたならば、kdb_init は正しいレルムを既定値として選ぶはずです。でなければ、(うまい)推定をします。マスタ・パスワードを 入力します。
このパスワードはディスク上のケルベロス・データベースを暗号化するためと新しいランダム・キーを生成するためにだけ使われます。それを覚えておく必要はありません。kstash を走らせる時にもう一度打ち込むだけです。長くてでたらめなものを選びましょう。そして、同じパスワードを使って kstash を走らせます。:
hemlig# kstash Enter Kerberos master password: Current Kerberos master key version is 1. Master key entered. BEWARE! Wrote master key to /.k
同じマスタ・パスワードを入力すると、それはファイル `/.k' に保存され、そして、ケルベロス・サーバは必要になるとそれを読み出します。もしかすると、ディスクが潰れたり、スレーブ・サーバを設定したい思うでしょうから、マスタ・パスワードを書いたものを封筒に入れて封をして安全なところにおきましょう。
kdb_init データベースを最小の記載で初期化します:
kstash は、マスタ・パスワードを読んで、ファイル `/.k'に書き込むだけです。これによって、マスタ・パスワードを入力することなく、ケルベロス・サーバを起動することを可能にします。このファイル (`/.k') は、それが存在する "安全な" マシン上の root ユーザにのみ読み出しが可能です。
これで、最小のプリンシパルを含んだケルベロスのデータベースができました。次のステップではプリンシパルを更にもう少し加え、そして、きちんと動くことをテストして、それから、ケルベロス・サーバのコンソールを使わないでレルムの管理をすることができます。kdb_editを使ってケルベロス・サーバのデータベースを編集します。
kdb_edit はデータベースの編集に際し、立ち上げ(bootstrapping)と後戻り(fall-back)機構のために意図されたものです。普通の目的には、kadmin プログラムを使います(see section Add users to the database)。
次の例は `nisse.admin' をケルベロス・データベースの中に加えるところを示します。このプリンシパルはケルベロス・データベースを管理する時に `nisse' によって使われます。あとで `nisse' のための正常なプリンシパルがつくられます。`nisse' と `password' とを自分のユーザ名とパスワードとに置き換えて下さい。
hemlig# kdb_edit -n Opening database... Current Kerberos master key version is 1. Master key entered. BEWARE! Previous or default values are in [brackets] , enter return to leave the same, or new value. Principal name: <nisse> Instance: <admin> <Not found>, Create [y] ? <> Principal: nisse, Instance: admin, kdc_key_ver: 1 New Password: <password> Verifying password New Password: <password> Principal's new key version = 1 Expiration date (enter yyyy-mm-dd) [ 2000-01-01 ] ? <> Max ticket lifetime (*5 minutes) [ 255 ] ? <> Attributes [ 0 ] ? <> Edit O.K. Principal name: <>
kdb_edit は "Principal name" のプロンプトに return を打つまで繰り返します。これで、nisse を管理者として登録しました。
hemlig# /usr/athena/libexec/kerberos & Kerberos server starting Sleep forever on error Log file is /var/log/kerberos.log Current Kerberos master key version is 1. Master key entered. BEWARE! Current Kerberos master key version is 1 Local realm: FOO.SE
遂に、追加したプリンシパルとサーバが正しく動くことを証明することができます。
hemlig# kinit eBones International (hemlig.foo.se) Kerberos Initialization Kerberos name: <nisse.admin> Password: <password>
もし、kinit からなにもエラーを受け取らなければ、全て動いています。
(でなければ、 section Common error messages を御覧下さい。) klist
を使えば、kinit で得られた切符を検証できます：
hemlig# klist Ticket file: /tmp/tkt0 Principal: nisse.admin@FOO.SE Issued Expires Principal May 24 21:06:03 May 25 07:06:03 krbtgt.FOO.SE@FOO.SE
管理サーバ kadmind は、一連のファイルを使って誰が何の操作をする権利を持つかを決定します。それらのファイルは：
`admin_acl.add', `admin_acl.get', `admin_acl.del', および `admin_acl.mod'です。`nisse.admin@FOO.SE' をその内容に加えるには次のようにします:
hemlig# echo "nisse.admin@FOO.SE" >> /var/kerberos/admin_acl.add hemlig# echo "nisse.admin@FOO.SE" >> /var/kerberos/admin_acl.get hemlig# echo "nisse.admin@FOO.SE" >> /var/kerberos/admin_acl.mod hemlig# echo "nisse.admin@FOO.SE" >> /var/kerberos/admin_acl.del
後で、管理者権限をさらに多くのユーザを加えたければ、それぞれの管理用プリンシパルを作ってそれらを管理サーバの ACL に加えることを忘れないで下さい。
hemlig# /usr/athena/libexec/kadmind & KADM Server KADM0.0A initializing Please do not use 'kill -9' to kill this job, use a regular kill instead Current Kerberos master key version is 1. Master key entered. BEWARE!
kadmin クライアントを使ってユーザをデータベースに加えます：
hemlig# kadmin -p nisse.admin -m Welcome to the Kerberos Administration Program, version 2 Type "help" if you need it. admin: <add nisse> Admin password: <nisse.admin's password> Maximum ticket lifetime? (255) [Forever] Attributes? [0x00] Expiration date (enter yyyy-mm-dd) ? [Sat Jan 1 05:59:00 2000] Password for nisse: Verifying password Password for nisse: nisse added to database.
他のユーザも加えたければ同様に行ないます。次に、ユーザがデータベースの中にあることを検証し、そのユーザのデータベースの記載を確認します。
admin: <get nisse> Info in Database for nisse.: Max Life: 255 (Forever) Exp Date: Sat Jan 1 05:59:59 2000 Attribs: 00 key: 0 0 admin: <^D> Cleaning up and exiting.
スタートアップ・スクリプト(`/etc/rc' あるいはそれと同等なもの)にケルベロス・サーバと管理サーバを始動するために使われる行を加えます。
ケルベロス・クライアントのマシンをつくるのはほんの数段階です。最初に構成ファイルのケルベロス・サーバの変更をする必要があるでしょう。(see section Install the configuration files および see section Updating /etc/services。)さらに、`/usr/athena/bin' にあるプログラムを利用可能にする必要があります。これは、ユーザのパスに、それを加えるか、シンボリック・リンクにするか、あるいは、プログラムをコピーするかによってできます。
さらに、なんらかの方法で、クライアント上の時刻がケルベロス・サーバの時刻と同期していることを証明するべきでしょう。同調するサーバとクライアントとの両者の間で、許される時間の差は最大5分です。
時刻を同期させるのに良い方法の一つとして NTP (Network Time Protocol) があります。
http://www.eecis.udel.edu/~ntp/ を御覧下さい。
もし、root-アクセス権を持たないマシンでクライアント・プログラムを走らせる必要があるとしても、お望み通り、実行モジュールを使用するだけで構成を行なう必要はありません。特殊な使われ方は上記にて言及してます。 (see section Install the configuration files). もし、この場合に該当せず、 `krb.conf' や `krb.realms' を持つ必要があれば、それらを選んだディレクトリにコピーして、 環境変数 KRBCONFDIR をそのディレクトリ を指すように設定します。
クライアントの機能をテストするには、kinit プログラムを走らせます：
foo$ kinit eBones International (foo.foo.se) Kerberos Initialization Kerberos name: <nisse> Password: <password> foo$ klist Ticket file: /tmp/tkt4711 Principal: nisse@FOO.SE Issued Expires Principal May 24 21:06:03 May 25 07:06:03 krbtgt.FOO.SE@FOO.SE
これらには、rsh, rlogin, telnet, ftp, rxtelnetなどが含まれます。
まず、前節で述べられた段階に従ってクライアントを作り、その操作の検証を行ないます。次に、新しいデーモンを使うために、 `inetd.conf' を変更します。ファイル@pindex inetd.conf `etc/inetd.conf.changes' を見て、`inetd.conf' に施すお奨めを御覧下さい。
この時点では、どのマシンで何のサービスを走らせるかを決めているはずです。
ここでは、ケルベロス化されたバージョンと "旧式(old style)" バージョンが存在します。異なるバージョンは異なるポート番号を使いますので、何にも無しか、一方か、あるいは、両方を選べます。もし、強いて "旧式" の r* サービスを使いたくなければ、プログラムにそのポートへの接続を単に拒むかわりに、"Remote host requires Kerberos authentication" のテキストを出力させることができます。これは、`-v' オプションで有効となります。ケルベロス化されたサービスには暗号化と非暗号化のバージョンが存在します。暗号化サービスには "e" が名前の前に付き、プログラムは `-x' を暗号化を示唆するオプションとして受け付けます。
われわれの推奨は、ケルベロス化されたサービスのみを使い、古いポートには説明のためのメッセージを与えるものです。
telnet サービスはいつも同じポートを使って、どの認証方法が使われるべきかを交渉します。telnetd プログラムが
"-a user"オプション を持てば、ケルベロス化されて認証された接続のみ許します。もし、それを含まれなければ、明示文(clear text)パスワードの使用に後戻ります。明らかな理由で、このオプションを有効にすることを推奨します。もし、ワンタイム・パスワードを (see section One-Time Passwords) を使いたければ、"-a otp" オプションで OTPs かケルベロス化による接続を許すでしょう。
ftp サービスは telnet と同様に指定された一つのポートで動きます。既定では、ケルベロス認証された接続を許します。以下のオプションで、付加的なレベルを指定できます。
匿名(anonymous) ftp を走らせるとき、それをどのように設定するかを説明するftpd についてのオンライン・マニュアルを読むべきです。
ポストオフィス・プロトコル(POP) はメールをメール・ハブから取り込むのに使われます。
popper プログラムは、標準 POP3 プロトコルとケルベロス化された KPOP を実装してます。ケルベロス版のプロトコルで走らせるには `-k' を使って下さい。このサービスはメール・ハブだけで走らせるべきです。
kx はケルベロス認証されてかつ暗号化された接続の上で X を走らせることを許します。このプログラムは rxtelnet、 tenletxr、 および、 rxterm により使われます。
もし、X ライブラリが UNIX-ソケット を使うことを許されないような妙な類のオペレーティング・システムをお持ちの場合は、`-t' オプションを
kxd に指定する必要があります。それ以外は、デーモンを `inetd.conf' に加えるだけで十分なはずです。
このサービスは切符(ticket)をリモート・ホスト上に作ることを許します。これを可能にするには、`inetd.conf' に関係する行を挿入するだけです。
全てのユーザはケルベロス・サーバで登録されたパスワードを持っている必要があり、同様に全てのサービスはケルベロス・サーバとの共有鍵を持つ必要があります。そのサービス鍵は、通常は `/etc/srvtab' と呼ばれるファイルに保存されます。このファイルは鍵が暴かれるの避けるために root 以外の誰にも読まれないようにすべきです。ケルベロス・データベースの中のこのプリンシパルの名前は通常はサービス名とホスト名です。 このようなプリンシパルの例は、`pop.hostname' と `rcmd.hostname' です。(rcmd は "remote command" に由来します。) もっともよく使われる srvtab の幾つかの型と、それらを使うプログラムをここに列挙します。
これらの鍵を作るためには、ksrvutil プログラムを使うでしょう。
これを行なうには以下のようにします：
bar# ksrvutil -p nisse.admin get Name [rcmd]: <> Instance [bar]: <> Realm [FOO.SE]: <> Is this correct? (y,n) [y] <> Add more keys? (y,n) [n] <> Password for nisse.admin@FOO.SE: <nisse.admin's password> Written rcmd.bar rcmd.bar@FOO.SE Old keyfile in /etc/srvtab.old.
あるマシン (`foo') 上で切符を入手して、ケルベロス化サービスで次のマシン (`bar') にログインするために使います。もしうまく行けば、そのテストは以下のように見えます:
foo$ kinit nisse eBones International (foo.foo.se) Kerberos Initialization for "nisse" Password: <nisse's password> foo$ klist Ticket file: /tmp/tkt4711 Principal: nisse@FOO.SE Issued Expires Principal May 30 13:48:03 May 30 23:48:03 krbtgt.FOO.SE@FOO.SE foo$ telnet bar Trying 17.17.17.17... Connected to bar.foo.se Escape character is '^]'. [ Trying mutual KERBEROS4 ... ] [ Kerberos V4 accepts you ] [ Kerberos V4 challenge successful ] bar$
全てがうまく動いていることを確かめるのに、rsh, rcp, rlogin, rlogin -x やその他のコマンドで試してみることもできます。
マスタ・サーバが落ちた場合のことを考えて、少なくとも１つ以上のバックアップ(スレーブ)・サーバを持つことは望ましいことです。このようなスレーブ・サーバを好きな数だけ持つことは可能ですが、通常は余計な重複をさせるために三つ以上も持つことはありません。
最初に良いサーバ・マシンを選定します。see section Choose a kerberos server。
マスターで `rcmd.kerberos' (注記、文字通り "kerberos" とすべきです)プリンシパルを (`ksrvutil get' を使って) 加えます。
マスター上で走る kprop プログラムは、スレーブ・サーバ上で走っている
kpropd デーモンに認証を求めるときにこれを使います。スレーブ上の kpropd はマスターからの認証接続のために `rcmd.hostname' 鍵を使うでしょう。それゆえ、スレーブは srvtab にこれのための鍵を持つ必要があり、そして、もちろん、サーバーとして活動するために十分の構成ファイルを持つ必要もあります。これをどのように行なうかは section Install the kerberised services を参照して下さい。
総括すると、マスターは `rcmd.kerberos' のための鍵を持ち、そして、スレーブは`rcmd.hostname' の鍵を持つはずです。
スレーブはマスターに使ったものと同じ親鍵を必要とするでしょう。
マスタ・サーバでは、ケルベロス・スレーブ・サーバのホスト名を含むファイル、例えば `/var/kerberos/slaves'、を作ります。
kpropd をスレーブ・サーバ上で、 `kpropd -i' で、開始します。
マスタ・サーバ上では、データベースのダンプを作って、それを伝播します。
foo# kdb_util slave_dump /var/kerberos/slave_dump foo# kprop
これで、データベースのコピーをスレーブ・サーバ上に持つはずです。このことは、スレーブサーバ上で `kdb_util dump file' を発行して、元のマスタ・サーバ上のファイルと比較することによって証明することができます。記載が同じ順番にはないことに注意して下さい。
一例として、この手続きを一時間毎にクローンにより走らされる正規のスクリプトにより自動化するべきです。
マスターとスレーブは同じデータベースの複製を使うので、両者は同じ親鍵をを使う必要があります。kstash で、親鍵をスレーブに加えます。(see section Setup the server)
ケルベロス・サーバをスレーブで開始するには、まず最初にマスタ鍵をマスタ・サーバよりコピーしなければなりません。このためには、マスタ・パスワードを覚えておいて、`kstash' コマンドを発行するか、あるいは、単に鍵ファイルをマスタ・サーバからコピーすることにより可能です。もし、ファイルをコピーする場合は、安全な媒体で、ネットワークを通さないでコピーすることを忘れないで下さい。良い方法はフロッピーか紙に入れることです。始末し易いので紙の方が良いでしょう。
スレーブ・サーバ上では、ケルベロス・サーバは `-s' オプションで開始されるべきです。これは、たとえば最後のマスタ・サーバからのアップデートからの時間など、正常性の確認を可能にします。
データベースへの変更は全てマスタ上の kadmind により行なわれ、スレーブに伝えられますので、スレーブ上では kadmind を走らせる必要は ありません。
最後にスレーブ・サーバに `/etc/krb.conf' を加えます。クライアントはそのファイルに指定された順番でサーバに問い合わせることになります。
section Install the configuration files を御覧になって、CNAME をスレーブサーバに追加することを検討して下さい。
自分のレルム `MY.REALM' にいると仮定して、どのようにして他のレルム `OTHER.REALM' にあるサーバに認証を求めますか？ `MY.REALM' での正当な切符を持つことにより、そのレルムにてケルベロス化されたサービスと通信することを許します。しかしながら、他のレルムのコンピュータはあなたのレルムのケルベロス・サーバと秘密鍵を共有しません。
二つのレルムの間でお互いに信用しあえる共有鍵を加えることが可能です。telnet のようなクライアント・プログラムが相手のコンピュータが異なるレルムにあることを見つけると、ローカル・ケルベロス・サーバから、他のレルムへの発券許可証(TGT)を得ようと試みるでしょう。そして、発券許可証さえあれば、他のレルムのケルベロス・サーバからサービス券を取得できるでしょう。
この機能を与えるためには、それぞれのレルムのプリンシパルを相互に加えなければなりません。プリンシパルは、`MY.REALM' では `krbtgt.OTHER.REALM' で、そして、`OTHER.REALM' では `krbtgt.MY.REALM' のはずです。その異なる２つのプリンシパルは同じ（そして同じ鍵バージョン番号の）鍵を持つべきです。この鍵を安全に転送することを忘れないで下さい。これが要求されることのすべてです。
blubb$ klist Ticket file: /tmp/tkt3008 Principal: joda@NADA.KTH.SE Issued Expires Principal Jun 7 02:26:23 Jun 7 12:26:23 krbtgt.NADA.KTH.SE@NADA.KTH.SE blubb$ telnet agat.e.kth.se Trying 130.237.48.12... Connected to agat.e.kth.se. Escape character is '^]'. [ Trying mutual KERBEROS4 ... ] [ Kerberos V4 accepts you ] [ Kerberos V4 challenge successful ] Last login: Sun Jun 2 20:51:50 from emma.pdc.kth.se agat$ exit Connection closed by foreign host. blubb$ klist Ticket file: /tmp/tkt3008 Principal: joda@NADA.KTH.SE Issued Expires Principal Jun 7 02:26:23 Jun 7 12:26:23 krbtgt.NADA.KTH.SE@NADA.KTH.SE Jun 7 02:26:50 Jun 7 12:26:50 krbtgt.E.KTH.SE@NADA.KTH.SE Jun 7 02:26:51 Jun 7 12:26:51 rcmd.agat@E.KTH.SE
このパッケージには ワンタイム・パスワード (OTP) を使うためのサポートもあります。特に、login, ftpd それと popper でのサポートがあります。
ワンタイム・パスワード(OTP)は、その名前のとおり、一回だけ使えるパスワードです(使い捨てパスワードとも言います)。これは、誰かがネットワークを盗聴して盗んだパスワードを使おうとしても使えないことを意味します。
このパッケージの OTP は RFC 1938 をサポートします。この標準はよく知られている S/Key と後方互換でもあります。これを生成するプログラムは、HP 48 のものからクレイのものまで全てのマシンにわたりたくさんあります。
なぜ、ケルベロスの代わりに OTP を使いたがるのでしょうか？ OTPの利点は コンピュータの操作が必要無いことです。パスワードのリストをプリントアウトして持って行くことができますし、計算機か携帯型コンピュータを使って生成することもできます。
裏を返せば、OTP は透過型攻撃に対してのみあなたを守ります。最初の接続でのみ認証が行なわれます。それ以後は、誰でもあなたのセッションを盗聴できますので、OTP での接続を通して(パスワードのような)重要なデータは送ったり見たりするべきではありません。また、侵入者が、あなたの TCP セッションかつまたは紹介データを、途中で横取りするような攻撃については無防備です。言い替えると、OTP では、最初の認証のみを提供しますが、データの保全性も内密性もありません。
OTP はタプル(seed, sequence number, pass-phrase) からジェネレートされます。種(seed)と通番(sequence number) は挑戦状(challenge) の一部として表示されますので、それに対応したパスワードを生成するか、予め生成しておいたリストより取り出します。
最後に、OTP は簡単でどこでも使えますが、ケルベロスがするように、全ての脅威に対して保護されるわけではありません。ケルベロスが使えない時に使ってください。
OTP を初期化するには otp プログラムを使います。このプログラムはこのホスト上で現在のパスワード(ここでは100番目)とそれに関係する種(`foobar')を手元のファイルに記載します。
datan:>otp 100 foobar Pass-phrase: <pass-phrase> Verifying password Pass-phrase: <pass-phrase>
それらのリストを出力するには otpprint と呼ばれるプログラムがあります。
datan:>otpprint 100 foobar Pass-phrase: <pass-phrase> 91: SLAM BUY SUP DUSK SKY BEST 92: DEEM SIGH ROB RASH JUG MAT 93: DUET FISK HERS AREA TOLL SUP 94: WOW RAIN LEAK SARA MARK WING 95: COG YELL MILK CART ABE BAWL 96: GROW SILK GIST OMEN CAM ANNE 97: JAG QUAD NUT BEAT BHOY MAGI 98: ADAM USED GENE NIP EYE SIS 99: MY SUNG HERO AT DASH RAKE 100: CORN KNIT BOTH TOGO SOUL BOG
自分用に初期化された一連のワン-タイム・パスワードの一つを使おうとする時は、使用されるアルゴリズムと通番とそして種を挑戦状とともに受け取ります。これらを生成器に入力するか、リストから対応するパスワードを見つけて下さい。
login: assar assar's [ otp-md5 99 foobar ] Password: <MY SUNG HERO AT DASH RAKE>
パスワードの通番は otp に与えた番号より１だけ少ない数から始まり、それを使う毎に１づつ減って行きます。誰もあなたのパスワードを盗んで使っていないことを確かめるためには、現在の通番が何番かをいつも見ているべきです。番号が０に達したら、新しいパスワードのセットを入手する必要があります。
一度パスワードの綴を初期化してしまったら、上記のような挑戦状を受け取ったところで、どのようなパスワード・プロンプトに対してでも使うことができます。
ftpd, telnetd, および popper は、ケルベロス認証でない接続の時に、ワン-タイム・パスワードを要求するように設定することができます。オンライン・マニュアルで、これらのプログラムの現在のオプションを確認して下さい。
多くのコンパイラは ANSI 準拠にするためにスイッチを要します。kth4 は ANSI C で書かれていますので、使われるコンパイラの名前と ANSI 準拠にするために要求されるスイッチを指定する必要があります。これは、env コマンドを使って configureを走らせると最も簡単にできます。具体的に HP-UX の下で附属のコンパイラを使って構築するには次のように行ないます。
datan$ env CC="cc -Ae" ./configure
一般的には gcc が使えます。次の組合せでも配布パッケージをうまくコンパイルできたことが証明されています。
RedHat4.2 の下で libc 関数の gethostby*() は時々コアダンプします。もしこれらの問題にぶつかったら、ファイル `/etc/nsswitch.conf' のホストの記載が以下に示す行よりも複雑になっていないかを確認して下さい。
hosts: files dns
あるシステムは krb4 を正しく構築するのに必要な `/usr/include/ndbm.h' が無くなっています。`ndbm.h.Linux' をソース配布パッケージの隣に置いてあります。
ある Linux パッケージでは動かない `libdb' の報告があります。もしそれが起こったら、configure を走らせるときに --without-berkeley-db を使って下さい。
共有ライブラリを構築する際に GNU gcc/ld の組合せを使うときは、RUN_PATH 環境変数を /usr/athena/lib (対象 libdir) に設定する方が良いでしょう。そうしないと、LD_LIBRARY_PATH を 実行時に設定しない限り、PAM モジュールは動きません。
共有ライブラリの `/usr/lib/libndbm.sl' がすべてのシステムに存在するわけではありません。この問題にとって更に悪いことは、静的結合のためのアーカイブ版も無いことです。それゆえ、バイナリを構築するときは、"本当に移植性のある" GNU gdbm または Berkeley DB を最初にインストールしおいて、そのライブラリに対して結合を行なえることを確認してからにします。
Cray 上で rlogind は forkpty() が移植されるまでは動きません。それまでは、telnetd を使って下さい。
IRIXには３種類の異なる ABI:(Application Binary Interface) があり、それぞれ、古い 32 ビットのインターフェース( O32、あるいは、ただの 32 として知られる)と、新しい 32 ビットのインターフェース(N32)、および、64 ビットのインターフェース(64) です。 O32 と N32 は、どちらも 32 ビットですが、それぞれ異なる呼出規定となっており、並びの制約についても同様です。IRIX 6.4 からは、N32 フォーマットが既定となっています。 ABIはコンパイル時に選択しますが、`--with-mips-abi' 構成オプションで 指定できます。このオプションに与えることのできる引数は、`o32', `n32',あるいは, `64' で、N32 が既定です。3種類の異なる ABI:s のためのライブラリは、通常、それぞれ異なるディレクトリ(`lib', `lib32', あるいは `lib64')にインストールされます。
GCC は、異なる ABI では、既知の問題を抱えています。古い GCC では O32 だけを扱えますが、新しい GCC では N32 と 64 を扱えて O32 は扱えず、ある版の GCC においては、N32 の構造体並びが壊れています。
この異なる ABI による混乱のため、ある問題が引き起こされます。例えば、`afskauthlib.so' ライブラリは `xdm' や `login' と同じ ABI を使う必要があります。最も簡単な方法は、 `/usr/bin/X11/xdm' で走る `file' がどの ABI を使うのかを確認することです。
もう一つの問題は、Transarc の AFS を走らせようとする場合で、64-bit ABI をサポートしないため、64 ビットのアプリケーションからのトークンを入手することができません。もし、どうしてもしなくてはならないのでしたら、この機能を提供するためのカーネル・モジュールが ftp://ftp.pdc.kth.se/home/joda/irix-afs64.tar.gz にあります。
gcc version 2.7.2.* には、最適化をし過ぎると `appl/telnet/telnetd/sys_term.c' を間違えてコンパイルするバグがあります(もしかしたら `appl/bsd/forkpty.c' も)。
xlc プリプロセッサの幾つかの版では、(文書に書かれていない)`-qnolm'オプションを認識しません。もし、このオプションがそのプリプロセッサに(`/etc/ibmcxx.cfg' 構成ファイルを経由したりして)渡されれば、構成(configure)は失敗するでしょう。
この解決には構成ファイルからそのオプションを全体的に、あるいは、プリプロセッサ についてのみ取り除くことです：
$ cp /etc/ibmcxx.cfg /tmp
$ed /tmp/ibmcxx.cfg
8328
/nolm
options = -D_AIX,-D_AIX32,-D_AIX41,-D_AIX43,-D_IBMR2,-D_POWER,-bpT:0x10000000,-bpD:0x20000000,-qnolm
s/,-qnolm//p
options = -D_AIX,-D_AIX32,-D_AIX41,-D_AIX43,-D_IBMR2,-D_POWER,-bpT:0x10000000,-bpD:0x20000000
w
8321
q
$ env CC=xlc CPP="xlc -E -F/tmp/ibmcxx.cfg" configure
AFS 3.4 version 5.38 for AIX 4.3 にはバグがあり、幾つかの場合にカーネルをパニックに陥れます。login にはこれに対する対処もありますが、この問題は他のプログラムにも及ぶかも知れません。この問題は、version 5.55 で直ったようです。
パスワードを確認するプログラムは `passwd', OTP およびケルベロス・パスワード で動きます。もし、C2 セキュリティ(もしくはその他のパスワード・データベース)を使うならば、通常パスワードはどこかわからない所に保持します。もし、ケルベロスを C2 セキュリティで使いたいならば、どのような変更が必要かを考えなければならないでしょう。section Digital SIA を見て、Digital の SIA と C2 セキュリティについての議論も見て下さい。
ファイアウォールはファイアウォールのある側から来るある型のパケットが反対側に来るのを分別して締め出します。ファイアウォールはある種の問題をケルべロスのように解決すると仮定されます（基本的には認可されないネットワークの使用を阻みます）。違いは、ケルべロスが利用者を認証しようとするのに対し、ファイアウォールはネットワークを `安全' な内側と `安全でない' 外側とに分けることです。
ファイアウォールを使う人々は、UDP が部分的に `安全でない' プロトコルを使っているという理由から、 UDP は安全でないと考えます。ケルべロスは既定では UDP を使ってパケットを送ったり受け取ったりするので、ケルべロスとファイアウォールとが一緒ではあまりうまく動きません。
ファイアウォールの後ろ側からケルベロスを試そうとしている兆候は、切符を全く入手できません(kinit が悪名高い `Can't send request' エラーメッセージで終了します)。
これらの問題を解決するには幾つかの方法があります：
最後の２つの方法は攻撃的と考えられるでしょう（`正しい' 型のデータをそれぞれのポートに送るのではないので）。おそらく最善を尽くしてファイアウォールの管理者と議論することになるでしょう。
KDC と通信するときに他のプロトコルをどのように使うかについての情報については、section Install the configuration files を見て下さい
ファイアウォールは `内側' のアドレスを隠すことがよくありますので、全てのパケットがファイアウォールから来ているように見えます。クライアントのホストのアドレスが切符の中にコード化されてますので、これがトラブルを起こします。もし、切符を使おうとすれば `Incorrect network address' のようなエラーメッセージを受けとります。この問題の起きる理由は、話かけようとしているサーバが KDC から送られたのと異なるアドレスを見るためです。もし、この種のトラブルが起きたときの解決への最も近道は、おそらく切符を得るのに他の機構をためすことでしょう。管理者を説き伏せることができれば、サーバに異なる２つのアドレスを `/etc/krb.equiv' ファイルに加えてもらうべきです。
もっと不明瞭なエラーメッセージに幾つか出会うかも知れません：
telnet machine daytime を行なうことにより局所時間を調べることができます。この時間(再び、普通はキーワード)はタイムゾーン(time-zone)と夏時間(daylight savings)の補正を行なっています。もし、あなたの時刻を同期させ続けることが難しければ、NTP( section Install the client programs での議論も参照下さい)のような時刻合わせシステムの利用を考えて下さい。
Yes.
もう少し長い回答をすると、別に何も壊れるものはないと考えています。プロトコル そのものはテキスト形式の時間刻印は使っていないし、元の MIT コードにあった2桁の年号の問題も直されています(このほとんどはログファイルの問題でした)。FTP クライアントには、(既に取得したファイルより新しいファイルだけを持ってくる) newer コマンドにバグがありました。
Y2K問題というわけではないのですが、 もう一つあるといえば、古いプリンシパルの失効日付です。MIT のコードでは幾つかの新しいプリンシパルの失効日を 1999-12-31 にして ますので、そうした日付のものがないか、データベースを確認しておいたほうが良いでしょう。
ところが、Y2038 問題は何かが全く違います(しかしながら、おそらく著者達はそのころまでには引退してるでしょう。察するに、野苺がどこか素敵な暖かい場所で育っていることでしょう。)
この版は、元々 MIT アテネ・プロジェクト(Athena project)の人々が書いたコードを基に、開発されています。Kerberos 4 patch-level 9 は暗号化関数とその呼出しを取り除かれて、US から"Bones" 版として輸出されました。Eric Young は彼自身が持っている libdes でその呼出しを復元し、それが "eBones" 版となりました。
"rcmd" プログラム群は、元々カリフォルニア大学バークレー校(UCB)で開発されましたが、その後 FreeBSD や NetBSD などのプロジェクトで改良されました。
バークレーでは ftp, ftpd, telnet および telnetd も書かれました。telnet と telnetd の認証と暗号化のコードは David Borman(当時、Cray Research, Inc.) により加えられました。暗号化のコードは、これが輸出される時には削除され、その後 Juha Eskelinen, <esc@magic.fi> により再び付加されました。
popper も最初はバークレーのプログラムでした。
login も源は同じですが、オランダの Eindhoven University of Technology の Wietse Venema が書いたコードを受け入れてます。
movemail は (少なくとも部分的には) Jonathan Kamens<jik@security.ov.com> により書かれ、© 1986, 1991, 1992, 1993, 1994 Free Software Foundation, Inc. が著作権を有します。
xnlock は、元々 1985 年 Dan Heller が sunview のために書きました。その後 X 版も 1990 年に彼が書きました。
`libroken' の幾つかの関数もバークレーから NetBSD/FreeBSD を経て来たものです。
AIX の AFS モジュールのために動的読み込みを取り扱うコードは © 1992 HELIOS Software GmbH 30159 Hannover, Germany. が著作権を有します。
editline は Simmule Turner と Rich Salz が書きました。
バグ修正とコーディングは以下の方々の貢献によります:
<shadow@dementia.org>
<gertz@lysator.liu.se>
<svedja@lysator.liu.se>
<kent@lysator.liu.se>
<jas@pdc.kth.se>
<rom@incolumitas.se>
<flag@astrogator.se>
<lama@pdc.kth.se>
<coelho@cri.ensmp.fr>
<griffon+@cmu.edu>
<gsstark@mit.edu>
<lha@stacken.kth.se>
<d96-dst@nada.kth.se>
<map@stacken.kth.se>
<rb@stacken.kth.se>
<arve@nada.kth.se>
<wahlsten@pathfinder.com>
<d96-dst@nada.kth.se>
<toddr@rpi.edu>
<ake@cs.umu.se>
<thn@stacken.kth.se>
Ian Marsh <ianm@sics.se> はこのテキストから英語の悪い言い回しをとり除きました。
Ilja Hallberg <iha@incolumitas.se> が文書を清書するのを手伝ってくれています。
この作業は、部分的には、 SUNET と KTH の並列コンピュータセンター(Centre for Parallel Computers)の支援によりなされました。
Windows 95/NT への移植は KTH のコンピュータ会議室(Computer Council)の支援で Jgen Karlsson <d93-jka@nada.kth.se> によりなされました。
全てのバグは我々自身により取り除かれました。
This document was generated on 9 June 2002 using the texi2html translator version 1.51a.