HEIMDAL ・序論: ・Kerberosとは何か?: ・構築とインストール: ・レルムの設定: ・詳しい場所の検索におけるもの: ・Kerberos 4の問題: ・Windows2000compatability: ・謝辞: ------------------------------------------------------------------------------- 序論 Heimdalとは何か？ HeimdalはKerberos 5のフリーの実装である.目的は次の通り: ・だれでも自由に使用することができる実装であること. ・RFC1510(今後のアップデートされたRFCも含む)に矛盾しない限り、既存の実装と互換性のあるプロトコルになっていること。 ・合理的にM.I.T KerberosV5 APIと互換性があること。 ・GSS-API(RFC1964)上にKerberos V5のサポートがあること。 ・最も重要で役に立つアプリケーション・プログラム(rsh,telnet, popperなど)を含んでいる。 ・Kerberos V4への十分な後方互換性があること。 現状 Heimdalには以下の特徴がある(このことは、すぐに全てが働くことを意味するものではない): ・暗号化/復号化/ASN.1のすべて/DER関連のstub生成器とライブラリ ・簡単なアプリケーションを動かせるlibkrb5のライブラリ ・アプリケーションを構築するため必要な全ての機能を含むGSS-APIライブラリ ・Eric Youngの`libdes' ・`kinit', `klist', `kdestroy' ・`telnet', `telnetd' ・`rsh', `rshd' ・`popper', `push'(movemailと同等) ・`ftp', および`ftpd' ・AFSへの認承のために必要なlibkafsライブラリとそれを使うafslogプログラム ・いくつかの簡単なテストプログラム ・ほとんどのものをサポートするKDC, オプションでKerberos V4とkaserverもサポートする ・マスターKDCとスレーブKDCとの間でデータベースを分配する簡単なプログラム ・パスワードを変えるkpasswddデーモン、パスワードを変えるためのライブラリ機能と簡単なクライアント ・ある種の管理システム ・多くのアプリケーションでのKerberos V4のサポート バグレポート もし、このソフトウェアでバグを見つけたならば、それが実装されていない コードの一部ではなく、本物のバグであることを確かめなさい。 バグレポートはheimdal-bugs@pdc.kth.seに送るべきである。 実行にあたっ て、どんなマシンでどんなOS(バージョンを含む)を使っていたかと、しようと したこと、バグによって発生したこと、そのバグの発生したことについてあな たが考たこと、我々で再現させるための例、あなたがその例を試したときの出 力、また、もしあなたが解決策をみつけたならその問題に対するpatchの情報 を含めておく。パッチは、diff -uかdiff -cで作る。 提案やコメントおよびその他なんでも、バグレポート以外の情報も歓迎する。 メーリングリスト Heimdalに関する話題のメーリングリストが2つある。 heimdal-announce@sics.se は低流量の発表リストで、 heimdal-discuss@sics.se は一般的な議論のためにある。申し込むためには、 メッセージをmajordomo@sics.seに送くってください。 ------------------------------------------------------------------------------- Kerberosとは何か？ これなるケルベロスは三つの犬の頭と竜の尻尾を持ち、背中にはありとあらゆる蛇の頭をはやしている。--Pseudo-Apollodorus Library 2.5.12 Kerberosは, ネットワーク上でユーザとサービスを認証するためのシステムで ある。 それはネットワークが「安全ではない」という仮定のもとに構築され ている。 例えば, ネットワーク上を送られるデータは盗み聞くことも, 変更 することもできて, また, アドレスを偽ることさえできる。したがって, 認証 目的に使用することはできない。 Kerberosは信頼された第三者機関のサービスである。このことは、ネットワー ク上のすべての実在物(通常プリンシパルと呼ばれるユーザとサービス)から信 頼された第三者機関(kerberosサーバ)であることを意味する。すべてのプリン シパルはkerberosサーバと秘密のパスワード(すなわち鍵)を共有して、プリン シパルがkerberosサーバからのメッセージが正統であることを確かめることを 可能にする。このようにkerberosサーバを信頼することで、ユーザとサービス は互いを認証し合うことができる。 基本的なメカニズム 注意:この議論はKerberosバージョン4についてであが、バージョン5の働きも ほぼ同様である。 Kerberosでは、プリンシパルたちは彼らが主張するところの者であることを立 証するためににチケットを使用する。 以下の例では、Aは認証交換の開始者で通常はユーザであり, BはAが利用した いサービスである。 特定のサービスのチケットを得るために、まずAはチケット要求をkerberosサー バに送る。要求はAとBの名前(他のフィールドに伴う)を含んでいる. そして、 kerberosサーバは AとBの両方が正当なプリンシパルであることを確認する。 プリンシパルの正当性について確かめると、AとBの名前、Aのネットワークア ドレス(A)、現在の時刻(t)、チケットの有効期限(life)、秘密 のセッション鍵(K)を含むパケットを作成する。このパケットはBの秘密の 鍵(K)で暗号化される。実際のチケット(T)は次： ({A, B, A, t, life, K}K) のようになっている。 Aへの返答は、チケット(T)、Bの名前, 現在の時刻、チケットの有効期限 セッション鍵をまとめてAの秘密の鍵で暗号化した次のようなチケットから成 る。 ({B, t, life, K, T}K) Aはこの返答を復号化して後の使用のために保有する。 AはメッセージをBに送る前に、Aの名前、Aのアドレス、現在の時間、Aが選ん だ「チェックサム」("checksum")をまとめて、秘密のセッション鍵で暗号化し、 次のような認証子を作成する。 ({A, A, t, checksum}K) この認証子はkerberosサーバからBが受けとったチケットと共に送られる。 Bはこれを受理すると、Bの秘密の鍵を使用ってチケットを復号化する。 このチケットには認証子を暗号化したセッション鍵が含まれているので、 Bはこの認証子も復号化することができる。 Aが本当にAであることを確かめるために、Bはチケットの内容を認証子のもの と比べなければならない. 何もかもが合致した時点でBは、Aが適切に認証さ れたものとみなす。 2種類の攻撃 Aに扮して 詐欺師Cは、ネットワークを介して伝えられる認証子やチケットを盗み、Aに扮 してそれらを使用することができるだろう。この攻撃の実行をより難しくする ために、アドレスがチケットと認証子とに加えられた。Cが成功するためには、 Aと同じマシンを使うか、パケットのソースアドレスを偽らなければならない。 さらにタイムスタンプを認証子に含めることで、Cには攻撃を仕掛けるための 余裕が無くなる。 Bに扮して CはBのネットワークアドレスをハイジャックすることができて, Aが自分の 信任状を提出したときに、Cはそれらを確かめるふりをしても、CはAと話し ていることには気がつかない。 防衛戦術 サーバ側にリプレーキャッシュを加えることは可能だろう。考え方は、数分の 間に送られた認証子を保存するのだが、Bは一度使用されたメッセージを誰か が再送しようと試みていることを検出することができる。これはいくらか非実 用的であり(ほとんど成功の望みは無い)、Kerberos 4の一部にはないが、MIT Kerberos 5はそれを含んでいる. Bを認証するために, AはBがセッション鍵にアクセスしたことを立証する何か を送り返すことを要求するかもしれない。一つの例はAが認証子の一部として 送ったチェックサムがある。典型的な手順の一つは、チェックサムに1を加え てセッション鍵で暗号化し、それをAに送り返すことだ。このやりかたを相互 認証という。 セッション鍵は、AとBの間で送られるメッセージに暗号方式のチェックサムを 追加するために使うこともできる（メッセージの保全として知られている）。 また、暗号化を加えることもできる（メッセージの機密性）。この方法が どんな場合でも最も良いアプローチである. 詳しく知るために Kerberosに関して原典となる論文は1988年に発表された、 Kerberos: An Authentication Service for Open Network Systems で、Jennifer Steiner, Clifford Neuman そして Jeffrey I.Schiller らに よって書かれた。 あまり技術的ではない著述は、Bill Bryantによる、 Designing an Authentication System: a Dialogue in Four Scenes に見い出せる。 これらの、文書は我々のwebページにて 見つけることもできる。 -------------------------------------------------------------------------------- 構築(Building)とインストール(Installing) Heimdalは、GNU Autoconf を使用して、特定のホストのための構成 (configure)を行い、GNU Automake を使い makefiles を管理する。もし、初 めてこれらのツールを使うのであれば、簡単なインストラクションは、トップ レベルのディレクトリで configure スクリプトを走らせ、終了したときの状 態をみてみることだ。 この配布物をソースディレクトリとは別のディレクトリで構築したければ、 GNU make のように正しく VPATH が実装された make が必要である。 この配布物を構築するには以下のものが必要である: ・gccなどの「緩い」ANSI C モードをサポートするコンパイラ。 ・lex か flex ・awk ・yacc か bison ・ソケット・ライブラリ ・サーバ側を構築するための NDBM か Berkeley DB。 何もかもが構築されれば、make install を実行する事によってインストール することができる。デフォルトのインストール場所は /usr/heimdal である が、--prefix=/some/other/place のようなオプションで configure 走らせる 事によってこれを変えることができる。 もし、デフォルトの振舞いを変える必要があるのなら、 configure は以下の オプションを受け付ける。 --without-berkeley-db DB には NDBM の前のものが好まれるが、何らかの理由で代わりに NDBM を使 用したいときにこのオプションを使用できる。 --with-krb4=dir Kerberos4 のライブラリとヘッダーの位置を与える。これにより、アプリケー ション(telnet, rsh, popper など)と KDC の中で Kerberos4 のサポートを可 能にする。自動的には /usr/athena の下をチェックする。ライブラリとヘッ ダを別々の場所に保存している場合は、このオプションの変わりにそれぞれへ のパスを --with-krb4-lib=dir や --with-krb4-include=dir のオプションに 与えることができる。rshd と popper でバージョン 4 のクライアントをサポー トするためには、我々のもっとも最近の Kerberos4 配布版を必要とする。 --enable-kaserver KDCで実験的な kaserver サポートを可能にする。これは、AFS の "KDC" で 使用されるプロトコルで、Kerberos4 のサポートを必要とする。 --enable-kaserver-db hprop の kaserver データベースを読むための実験的なサポートを可能にす る。これは、kaserver から Heimdal KDC へ移植するときに役に立つ。 --enable-dce DCEの証明書とトークンを手に入れるためのサポートを可能にする。さらに詳 しく情報を得るためには appl/dceutilsのREADME ファイルを見ること。 --disable-otp デフォルトでいくつかのアプリケーション・プログラムは使捨てパスワード (OTP: One-Time Password)) をサポートするように構築される。そのサポート を不能にするには、このオプションを使用すること。 --enable-osfc2 OSF/Digital Unix/Tru64 で C2 のサポートを幾分可能にする。あなたが自分 のC2モードによるOSFオペレーティングシステムを C2 モードで走らせている ときはこのオプションを使用する。 --with-readline=dir GNU Readline ライブラリへのパスを与えると、いくつかのプログラムで使 用される。readlineライブラリが見つからなければ、(より単純な)editline ライブラリが代わりに使用される。 --with-hesiod=dir push で hesiod のサポートを可能にする。 --enable-netinfo 構成情報を見つけるために netinfo を使用するサポートを加える。おそら く、NextStep/Mac OS X上でのみ役に立つ(働く)。 --without-ipv6 IPv6のサポートを不能にする。 --with-openldap データベースを LDAP に格納するサポートで Heimdal をコンパイルする。 OpenLDAP を必要とする。さらに詳しい情報は、 を見ること。 --enable-bigendian --enable-littleendian 通常、構築過程でマシンがビッグエンディアンであるかリトルエンディアン であるかを自動的に判断する。クロス-コンパイルを行うときは失敗すること があるので、関連するこの二つのオプションを使う。 --with-mips-abi=abi Irixには、使用することができる3つの異なったABI (32, n32, または64) が ある。このオプションは自動選択を上書きする。 ------------------------------------------------------------------------------- レルムの設定 ・構成ファイル: ・データベースの作成: ・keytabs: ・リモート管理: ・パスワード変更: ・クライアントとサーバのテスト: ・スレーブサーバ: ・増分伝搬: レルム(realm)とは管理上の領域のことで、通常、Kerberos レルムの名前に はインターネットドメイン名を大文字にしたものを使う。特に強い理由がない ならば, レルムはインターネットドメイン名と同じにしておく。そうすること で、あなたや他の皆さんが平穏無事に暮せるというものだ。 ------------------------------------------------------------------------------- 構成(configuration)ファイル レルムを設定するためは、最初に構築ファイル /etc/krb5.conf を作成しな ければならない。krb5.conf ファイルには多くの構成オプションを含むことが ができるが、そのいくつかをここで紹介する。 配布物(distribution)のなかにサンプルとして供給された krb5.conf がある。 構成ファイルはセクションから成る階層構造で、各セクションは結付け(変数 割当てかサブセクションのどちらか)のリストを含んむ。一つのセクションは ([section-name])から始まる。結付けは、左側とイコール(=)と右側(左側タグ が一つ以上の空白でイコール記号と切り離されなければならない)から成る。 サブセクションはイコールの記号の後に最初の空白以外の文字として { を持 つ。他のすべての結付けは変数割り当てとして扱われ、行の終わりまでが変数 の値として反映される。 [section1] a-subsection = { var = value1 other-var = value with {} sub-sub-section = { var = 123 } } var = some other value [section2] var = yet another value このマニュアルでは、スラッシュ(/)によって区切られた文字列で、セクショ ンと結び付ける名前を表す。例えば、other-var 変数は section1/a-subsection/other-var という具合いになる。構成ファイルの内容 に関する詳細な情報については、krb5.conf のマニュアルページを参照すると、 いくつかのさらに重要なセクションについて簡潔に記述されている。 libdefaults セクションはデフォルト・レルムやkdc応答時間切れなどのライ ブラリの構成パラメータを含む。 realms セクションは、自分達のKDCを隠す 場所のような、特定のレルムについての情報を含む。このセクションは Kerberos4 の krb.confファイルと同じ目的で供されるが、さらにもっと多く の情報を含むことができる。最終の、 domain_realm セクションはドメインか らレルムへのマッピングのリストを含み、Kerberos4 の krb.r4ealms ファイ ルに相当する。 レルムの設定を続づけるためには、以下と同じような内容の状態で構成ファ イルを作成しなければならない。 [libdefaults] default_realm = MY.REALM [realms] MY.REALM = { kdc = my.kdc } [domain_realm] .my.domain = MY.REALM ドメイン名と等しいレルム名を使用するならば、libdefaults と domain_realm のセクションを省略することができる。レルムのSRV-レコードを持っているか、 または、Kerberos サーバが kerberos.my.realm という CNAME を持っているなら、 realms セクションも省略することができる。 ------------------------------------------------------------------------------- データベースの作成. データベースlibraryが/var/heimdalのデータベースを探すので, あなたはたぶんその ディレクトリを作成するべきである. すべてのprincipalsのキーはデータベースに収納される.あなたが, 選ぶならば, マスタ キーでこれらをコード化することができる.しかし, あなたはただ一度それに入るために, このキー(または, パスワード)を覚えている必要はなくて, それはファイル (/var/heimdal/ m-key)の中に格納されるだろう.あなたがマスタキーが欲しいならば, kstashを起動させて, このマスタキーを作成しなさい: # kstash Master key: Verifying password - Master key: kadmin プログラムを使うデータベースを初期化するには, -lオプション(ローカルデータ ベースモードを可能にする)で行う.まず最初に, init MY.REALMコマンドを発行しなさい. これはそのデータベースを作成し, そのレルムのためにフォルト principalsを挿入する. あなたが1つのデータベースに1つ以上のレルムを持つことができるので, initはどんな古い データベースも無効にしない. データベースを作成する前に, initは最大チケットの有効期限についてあなたにいくつかの 質問をするだろう. データベースを作成した後に, あなたはたぶんそれに自分を加えるべきである.あなたが 付け加わったデータベースでこれを行う.議論としてprincipalの名前とみなす.principalが レルムを含むべきであるので, デフォルトのレルムをセットアップしないと, あなたは, 明らかにそのレルムを含む必要があるだろう. # kadmin -l kadmin> init MY.REALM Realm max ticket life [unlimited]: Realm max renewableticket life [unlimited]: kadmin> add me Max ticket life [unlimited]: Max renewablelife [unlimited]: Attributes []: Password: Verifying password - Password: 今度は,KDCを始動,そして, チケットを手に入れてみなさい. # kdc & # kinit me me@MY.REALMS's Password: # klist Credentials cache: /tmp/krb5cc_0 Principal: me@MY.REALM Issued Expires Principal Aug 25 07:25:55 Aug 25 17:25:55 krbtgt/ MY.REALM@MY.REALM 強い好奇心を持っているなら, あなたは, データベースにおけるすべての項目を記載するの にdump コマンドを使用することができる. それは以下の例と同様のものに見えるだろう(こ こでの項目が活版印刷の理由で先端を省略さえれていることに注意しなさい): kadmin>dump me@MY.REALM 1:0:1:0b01d3cb7c293b57:-:0:7:8aec316b9d1629e3baf8 ... kadmin/admin@MY.REALM 1:0:1:e5c8a2675b37a443:-:0:7:cb913ebf85 ... krbtgt/MY.REALM@MY.REALM 1:0:1:52b53b61c875ce16:-:0:7:c8943be ... kadmin/changepw@MY.REALM 1:0:1:f48c8af2b340e9fb:-:0:7:e3e6088 ... ------------------------------------------------------------------------------- keytabs データベースからサービスチケットを抽出して, keytabにそれを入れるために, あなたは (無作為のキーを手に入れる--random- key flagを使う)ankでデータベースにあるprincipal を最初に作成しなければならない そして, ext_keytabでそれを抽出する. kadmin> add --random-key host/my.host.name Max ticket life [unlimited]: Max renewable life [unlimited]: Attributes []: kadmin> ext host/my.host.name # ktutil list Version Type Principal 1 des-cbc-md5 host/my.host.name@MY.REALM 1 des-cbc-md4 host/my.host.name@MY.REALM 1 des-cbc-crc host/my.host.name@MY.REALM 1 des3-cbc-sha1 host/my.host.name@MY.REALM ------------------------------------------------------------------------------- リモート管理 管理サーバ(kadmind)はinetd(お勧めでない)によって始められるか, または正常なデーモンと して起動させることができる.inetdからそれを始めたいと思っているならば,あなたは以下で あなたの/etc/inetd.confのものと同様のラインを加えるべきである. kerberos-adm stream tcp nowait root /usr/heimdal/libexec/kadmind kadmind あなたは, 749/tcpとしてあなたの/etc/servicesにkerberos-admを加える必要があるかもし れない. adminサーバへのアクセスがacl-ファイルによって制御される, (default /var/heimdal/kadmind.acl.)アクセスファイルにおけるライン以下の構文を持っている. principal [priv1,priv2,...] [glob-pattern] あなたがprincipalに割り当てることができる特権は以下の通りである. add, hange-password(or cpw for short), delete, get, list, and modify,すべてである 特別な特権. これらのすべては, およそkadmin の異なったコマンドに対応している. glob-patternがライン上に与えられるならば, それはprincipalがパターンに合う対象を当て はめるだけの権利を制限する.そのパターンはshell globbingで使用したそれらと同様なもの である.を見なさい. ------------------------------------------------------------------------------- パスワード変化 ユーザにパスワード変更を許容するために, あなたはkpasswddを起動させるべきである. それはinetdから起動しない. あなたは, 464/udpとしてあなたの/etc/servicesにkpasswdを加える必要があるかもしれない. パスワード品質保証 ユーザが良いパスワードをもつことは重要である,さらにそれらの推測をより困難にすること をして,オフライン攻撃(プレ認承はオフライン攻撃に対して何らかの防御を提供する)を避け る.ユーザが良いパスワードを選ぶのを確実にするために, あなたはkpasswddのパスワード品 質管理を可能にすることができる. それら自身の制御はkpasswddによって使用される共有の libraryで行われる.これらで制御を構成するには, あなたの/etc/krb5.conf に以下と同様の ラインを加えなさい: [password_quality] check_library = library check_ function = function 共有されたlibrary libraryでのfunction機能は提案された新しいパスワードを必要とするだ ろう.機能は以下として宣言されるべきである. const char * function(krb5_context context, krb5_principal principal, krb5_data *pwd); 機能は, pwdがprincipalにとって良いパスワードであることかを確かめるべきで,もし, そうならばNULLを返しなさい.低品質があるのが考えられるならば, そのパスワードが使用さ れるべきでない理由を強い説明で返すべきである. cracklib libraryを使用するパスワードの上質のチェック機能のためのコードをソースコード distributionのうちのkpasswd/sample_password_ check.cで見つけることができる.それは パッチがで利用可能な状態で構築さ れたcracklib libraryを必要とする. どんなパスワードの上質のチェック機能も構成されない場合にだけ, それが少なくとも 6文字の長さであることが確かめられる. ------------------------------------------------------------------------------- クライアントとサーバーのテスト. 現在, あなたはすべてのクライアントとサーバを起動させることができる.それらを使用する 方法に関する情報について適切な人のページを参照しなさい. ------------------------------------------------------------------------------- スレーブサーバ,Incremental propagation, クライアントとサーバのテスト,レルムの セットアップ マスターサーバが失敗するといけないので, 少なくとも1つのバックアップ(スレーブ)サ ーバを持っているのは望ましい.そのような多くのスレーブサーバを持つことは可能であ るが,通常,3つ以上は必要ない. すべてのユーザへ同じサービスを提供するために,レルムのすべてのKerberosサーバには同 じデータベースがある.hpropプログラムは, マスターの上で起動しており,hpropdの processを起動しているslave にデータベースを伝える. すべてのスレーブにはprincipalをもったkeytab,すなわちhprop/hostname が必要である.以下 の通りktutilコマンドでそれを加えて, propdを始めなさい: slave# ktutil get -p foo/admin host/`hostname` slave# hpropd スレーブを認承するためにマスターはprincipalのkadmin/hpropを使用する.このprincipal はkadmin-l initを起動させたときに, 加えられるが, あなたがいかなる理由でもデータ ベースにそれを持っていないならば,kadmin-lでそれを加えてください. 次に, マスターの上でhpropを起動させなさい: master# hprop slave これは何もかもが適切に働くことを確認するための手動での例だった.手動でそれをすること は, もちろんまちがっている方法であり, これを自動化するために,あなたはslabe(s)上での inetdからhpropd を始めて, 定期的にデータベースを伝えるためにマスター上でhprop を定 期的に起動させたくなるだろう.cronから1時間に一度伝播を始めることは,たぶん名案である. ------------------------------------------------------------------------------- Incremental propagation Heimdalでのincremental propagationをするための, より新しくてまだいくらか実験し ているメカニズムがある. 定期的に全体のデータベースを送る代わりに, マスターの上で 起こる変化をスレーブに送る.バージョンの番号がデータベースへのあらゆる変化に割り 当てられて, マスターはすべての変化の記録を手元に保存している.スレーブは, どれが 最新のバージョンだったことかを知っていて, そのようにしてsyncにそれらがあるかない かを決定することができる.すべての変化のログはマスターの上に保たれて, スレーブが ログで最も古い方より古いversionerにいるとき, 全体のデータベースは送られなければ ならない. Protocol-wiseは, すべてのスレーブがマスターに接続して, 挨拶としてそれらが持って いる(IHAVEメッセージ)の最新のバージョンをそれに伝える.そしてマスターは, マスター(一連のFORYOUメッセージ)かTELLYOUEVERYTHINGメッセージの全体のデータベー スでそのバージョンと最新版の間のすべての変化を送ることによって, 応じる. incremental propagationの構成. マスターの上を起動するプログラムはipropd-マスターですべてのクライアントは ipropd-slaveを起動させる. データベースが伝達されるべきであるすべてのスレーブを含む マスターにファイル/var/heimdal/slavesを作成しなさい.各ラインはprincipal(例えば, iprop/hemligare.foo.se@FOO.SE)のフルネームを含んでいる. あなたはiprop/tcpをあなたの/etc/servicesに既に212と定義させている.そうでなければ, あるいは何らかの特有の理由で異なったポートを使用する必要があるなら,あなたは --port機能を使用することができる.あなたに1つのサーバから分配するために相互レルム があるとき, これは役に立つ. そして, あなたは, あなたが構成ファイルで加えたこれらのprincipal を作成す る必要がある.マスターとすべてのスレーブのために一つiprop/ hostnameを作成しなさい. master# /usr/heimdal/sbin/ktutil get iprop/`hostname` 次の段階はipropd-マスターの過程をマスターサーバで始めることである.ipropd-マスター は,それらがスレーブに伝わることができるために,いつ変更がデータベースに行われたのか を知るためにUNIX- socket/var/heimdal/signalの上で働く.また, それがこの信号を上げな いいくつかの方法によって変更されたかどうかがわかるために定期的にバージョンの番号を テストする(30秒毎に)安全対策がある. 次に, ipropd-slaveをすべてのスレーブ上で始めなさい: master# /usr/heimdal/libexec/ipropd-master & slave# /usr/heimdal/ libexec/ipropd-slave master& ------------------------------------------------------------------------------- より良い場所の検索におけるもの 事態をCiscosに動かせること Cisco IOSの現在のバージョンには、Kerberos 5を通る認証のサポートがいくつかある。 あなたがログインするとき(boring)、あなたのルータにアクセスするためにKerberosを使 用することでtelnetに認証されるとき(less boring)にルータにticketを持たせることに より、これらは両方を使用することができる。以下はIOS 11.2(12)でテストされて、もの は他のバージョンについて異なるかもしれない。古いバージョンはバグがあるのが知られ ている。 この仕事を作るため、Kerberosを使用するためにrouterを最初に構成しなければならない だろう(これはドキュメントで説明される)。サンプル構成は以下の通り。 aaa new-model aaa authentication login default krb5-telnet krb5 enable aaa authorization exec krb5-instance kerberos local-realm FOO.SE kerberos srvtab entry host/router.foo.se 0 891725446 4 1 8 012345678901234567 kerberos server FOO.SE 10.0.0.1 kerberos instance map admin 15 これは、ログインするとき、ルーターがkerberisedされたtelnetで認証しようとすべきだ ということを意味する。それが失敗するならば、Kerberosチケット交換(ローカル・デー タベース、RADIUS、または他の何かに類似したような)によって平易なテキスト・パスワ ードを検査しようとしなさい、そしてその失敗がローカルをためすならば、パスワードを 使用可能にしなさい。'login default'認証メカニズムを指定するとき慎重でないならば、 まったくログインできないかもしれない。 'srvtab'線の上のprincipalの後の数は、principal type、timestamp(数秒で1970年以後)、 重要なバージョン数(4)、keytype(1＝des)、key length(常にdesによる8)とそれからキー である。 Heimdal KDCにチケットを生産させるように、Ciscoが解読することができることがKDCの encode_as_rep_as_tgs_rep flagをつけなければならないかもしれない。ルータが des-cbc-crcを除いて何も扱うことができないと指定しなければならないだろう。 kadminのdel_enctypeコマンドでこれをすることができる。 これはすべてうまくいくが、しかし暗号化(U.Sだけで利用できる)でIOS版がない限り、そ れは本当に少しの問題も解決しない。ワイヤーの上にパスワードを送る必要はないが、telnet 接続が保護されないので、誰かがあなたのセッションを一人占めすることがさらに可能で ある。誰かがtelnetプロトコルへの保全を加えるまで、これは修復されないだろう。 動く解決策がCiscoのコンソールに本当のオペレーティングシステムをもったマシンとし て取り付けられるだろう。 -------------------------------------------------------------------------------- Kerberos 4の問題 バージョンでコンパイルされるならば、KDCはKerberos 4のクライアントからの要求に役 立つことができる。あなたがこれが働くようにしなければならないことが2、3ある。 ・主要な変換問題 ・バージョン4のデータベースを変える -------------------------------------------------------------------------------- principalの変換問題 まず最初に, Kerberos 4とKerberos 5のprincipalは異なっている。バージョン4のprincipal は"name"、"instance"、"realm" から成る。バージョン5のprincipalは1つ、またはより 多くのコンポーネントや"realm"("name"と"instance"は1番目と2番目のコンポーネントに まだそれぞれ使用されている)がある。また若干のケースとして、バージョン4人のprincipal の"name"は、対応するバージョン5のprincipalの最初の構成要素とは異なる。1つの顕著 な例は"host"タイプのprincipalである。そこでバージョン4 の"name"はrcmd(remoteコマ ンド用)であり、バージョン5の"name"はhostである。例としてhostnameを持っているprincipal のclassのために、(他の主要な違いはあるが)、Kerberos4はhostnameの最初のコンポーネ ントだけを使用するが、Kerberos5は十分に資格を与えられたhostnameを使用する。 このため、正しくバージョン4のprincipalをバージョン5人のprincipalに変換することは 難しいか、不可能である。例をあげるために、principalのrcmd.fooを変えたいと仮定し なさい。 rcmd nameは、instanceがhostnameであることを示している(例え例外があるとしても)。 instanceのfooをhostnameに正しく変えるために、どのhostについて言及しているのかを 知らなければならない。あなたは(realmからの)追加すべきドメイン名から推測したり、 possibleなhostnameのリスト持たなければならないことで、このことができる。最も簡単 なケースとして、最初のルールを用いることでほとんどのprincipalをカバーすることが できる。もしいくつかのドメインに単一のrealmを共有させると、大抵これは動かない。 例外が一つもなければ、例外のためにlookupテーブルをもって来ることができる。 複雑なシナリオでは、ある種のhost lookupメカニズムを必要とするだろう。これにDNS を使用したくなるが、DNSはエラーになり、安全でない。 幸い、KDCには切り札がある。：それは、principalがデータベースに存在するかどうか容 易に見える。KDCは、バージョン4を取り扱うとき、principalに変換するのに krb5_425_conv_principal_ext を使用するだろう。 -------------------------------------------------------------------------------- バージョン4データベースの変換について 既存のバージョン4データベースを変えたいならば、principal変換問題もまた起こる。 データベースを変えることに決めるなら、たった一つこの変換をしなければならないだけ である。バージョン4のKDCのslaveとしてバージョン5のKDCを走らせることは、可能であ る。この場合、データベースが伝播されるたびに、この変換は起こるだろう。この変換を するとき、探すべき2、3のものがある。データベースに古いentryリがあると、これらのentry は変換されないだろう。これらのprincipalがそれ以上使用されないか、またはprincipal が変換されないのが原因かもしれない。 またprincipalのmappingの問題もあるかもしれない。例えば、DNS lookupsを使用してい て、'foo'が'bar'のためのCNAMEであるところの rcmd.fooとrcmd.bar 2つのprincipal が あれば、結果としてprincipalは同じになるだろう。変換機能がどれが正しいのかわから ないので、これらの対立は手動で解決されなければならないだろう。 変換の例 以下のhostとserviceのセットは与えられている: foo.se rcmd mail.foo.se rcmd, pop ftp.bar.se rcmd, ftp 以下のprincipalから成るデータベースがある: rcmd.foo, rcmd.mail, pop.mail, rcmd.ftp, ftp.ftp. これらの特別なprincipalも得たほうがよい：gone.foo.se にある rcmd.gone や rcmd.old-mail は現在過ぎ去ったmachineであり、old-mail.foo.se は mail.foo.se のためのCNAMEである古いメールmachineだった。 このデータベースを変えるとき、完了するために以下の変換が欲しい: rcmd.foo host/foo.se rcmd.mail host/mail.foo.se pop.mail pop/mail.foo.se rcmd.ftp host/ftp.bar.se ftp.ftp ftp/ftp.bar.se rcmd.gone removed rcmd.old-mail removed krb5.confは次のようなものである： [realms] FOO.SE = { v4_name_convert = { host = { ftp = ftp pop = pop rcmd = host } } v4_instance_convert = { foo = foo.se ftp = ftp.bar.se } default_domain = foo.se } v4_name_convertセクションは、どのnameがhostnameからなるinstanceを持って考慮され るべきである。そしてそれは、nameがどのように変わらなければならないか(例えばrcmd はhostに変換されなければならない)についても示している。v4_instance_convert はhostname がどのように資格を与えられなければならないのかを示している(これは丁度変装したhost- fileである)。v4_instance_convertでカバーされていないhost-instanceは、 default_domain のコンテンツを追加することによって資格を与えられる。 実際にこの例では動かない。むしろそれは well に働く。どの hostnames が有効で、ど れが有効でないのか知る方法がないので、それはうまく rcmd.gone をhost/gone.foo.se に変換するだろう。これは大きな問題ではない。しかし２、３年の間kerberos realm を 走らすならば、チャンスは大きく、相当数の'junk'principalがある。 これを望まないないならば、default_domain の記述を取り除くことができるが、v4_instance_ convert セクションのすべてのhostのためにentryを加えなければならないだろう。 これをする代わりに、DNSを使用してinstance を変えることができる。これは問題のない 解決策でないが、たぶん多くの static host entry を加えるよりも簡単である。 DNS lookupを有効にするために、[libdefaults]セクションで v4_instance_resolve をつ けるべきである。 データベースの変換 データベース変換がhpropで行われる。 hprop.keytab の kyetab に kadmin/hprop key があると仮定する場合、データベースを(hpropdを走らせるべきである)slave-serverと呼 ばれるmachineに伝播するためにこのコマンドを走らせることができる。 hprop -4 -E -k hprop.keytab slave-server バージョン4のKadmin kadmind はバージョン4として kadmind を機能させることができて、ほとんどの操作をす ることができる。しかしいくつかの制限がある。(バージョン4以来、kadminプロトコル特 にそうである。)一つの例として、principalを作り、パスワードを変えるときにdos キー を押すだけであるということである。(最新のパスワードclientに、パスワードを送る。 よって、パスワードの本質をチェックすることは可能である。)これのために、dos キー でprincipalを作成することだけができて、少しのflagもセットすることができないか、 他のどの特別な要素もすることができない。 これを働かせるようにするため、inetdに別のentryを加えなければならない(バージョン4 がport749でなく、port751を使用するので)。 -------------------------------------------------------------------------------- Windows2000compatability マイクロソフトからのWindows2000(以前、Windows NT5として知られている)はKerberos 5 を実装する。しかしながら、それらの実装にはいくつかの癖、特色、およびバグがある。 本章はWindows2000に対してHeimdalを試そうとしている間に見つけているものについての 短い概要である。Windows2000におけるKerberos実装の別の大きい問題は、利用可能なド キュメンテーションは、それらが動く方法よりむしろ動くことに集中している。そして本 当にどのように動くかについて理解することには役立たない。 この情報はHeimdal0.3aとWindows2000Professionalに適用されるべきである。それはもち ろん絶えず対象であり、示唆された推測から成り立っている。うまくいけば、それはまだ いくぶん役に立つ。 ・Heimdal KDCを使用するためのWindows2000の構成: ・Windows2000とHeimdal KDCの間のInter-Realm key(trust): ・account mappingの作成: ・暗号化タイプ: ・認可データ: ・Windows2000KDCの癖: ・Windows2000に関しての役立つリンク： -------------------------------------------------------------------------------- Heimdal KDCを使用するためのWindows2000の構成 Windows2000ProfessionalのCD-ROMで、SUPPORT/TOOLS/SUPPORT.CAB のファイルを利用で きる ksetup.exe と呼ばれるコマンドラインのプログラムを必要とする。このプログラム は、WorkstationでKerberos設定を行うのに使用される。 Ksetupはdomain情報を登録キーの下に格納する: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\LSA\Kerberos\Domains. Heimdalのkadminプログラムを使用して、Kerberos realmでのhost principalの作成法。 unix% kadmin kadmin> ank -pw password host/datan.my.domain あなたはNTdomainのメンバーと対照的にworkgroupのメンバーとしてWorkstationを構成し なければならない。そして以下のようにrealmのKDCサーバを指定しなければならない。 C:> ksetup /setdomain MY.REALM C:> ksetup /addkdc MY.REALM kdc.my.domain マシンパスワードを設定し、localのkeytabを作成しなさい。 C:> ksetup /setmachpassword password ワークステーションはリブートされなければならない。 localのNTユーザとKerberos principalの間のmappingは指定されなければならず、2つの 選択がある。 C:> ksetup /mapuser user@MY.REALM nt_user これはユーザを特定のprincipalにmapし、realmでNTユーザデータベースより他のusername を持つことを許容する。 またこうも書ける。 C:> ksetup /mapuser * * Windowsマシンは対応するprincipal にユーザをmapするだろう。例えば、principal nisse@ MY.REALMへのnisse のように。(これはたぶん望むものである。) -------------------------------------------------------------------------------- Windows2000とHeimdal KDCの間のInter-Realm key(trust): また、以下で参照されているマイクロソフトからのStep-by-Stepガイドを見なさい。 Windows2000をインストールして、ドメインのための新しいコントローラ(Active Directory Server)を作成しなさい。 デフォルトで、trustはnon-transitiveになるだろう。これはユーザーだけが直接trust されたドメインから認証するかもしれないことを意味している。netdom.exe ツールを使 用することによって、これはtransitiveに変えることができる。 ksetupを用いるnon-Windows realmにKDCを見つけるためにどんなホストの上でWindows 2000 を見分ける必要がある。そしてConfiguring Windows 2000 to use a Heimdal KDCを見な さい。 これはMapped Namesを用いてcross-realmにログインすることを望むすべてのコンピュー タに必要です。 それからWindows kdcでinter-realm キーを加える必要がある。Domain Tree Management ツールを起動しなさい。(ProgramsのAdministrative toolsのActive Directory Domains and Trustsで見つけられる)。 あなたのドメインのプロパティを右クリックし、Trustタブを選択しなさい。適切なtrust のウインドウ上のAddを押して、ドメイン名とパスワードを入力しなさい。その後non-Windows Kerberos realmであるならば、OKを押しなさい。 両方にtrustを加えるのを忘れてはならない。 またHeimdal KDCにinter-realmキーを加える必要がある。あらかじめkrb5.confに必要な 設定がある。 [libdefaults] default_etypes = des-cbc-crc default_etypes_des = des-cbc-crc さもなければWindows 2000から発生するもので理解されないchecksumタイプが出力される。 (Quirks of Windows 2000 KDC参照) 別の問題がある。Windows2000は、以下に似ている何でもオフにする必要があるかもしれ ないKerberos 4を理解するようにみえないので、少なくともそれはprincipalを加えてい る間、Windows2000とキーを共有するだろう。 [kadmin] use_v4_salt=yes ともセットしなければならない。 またそれがいったん行われると、必要とされているinter-realmキーを加えることができる。 kadmin add krbtgt/NT.REALM.EXAMPLE.COM@EXAMPLE.COM kadmin add krbtgt/REALM.EXAMPLE.COM@NT.EXAMPLE.COM 両方のキーに同じパスワードを使用しなさい。 新しいrealm-trust(ksetupを走らせた後の)を試みる前にリブートするのを忘れてはなら ない。動くように見えるかもしれないが、パケットはnon-Windows KDCには決して送られ ていない。 -------------------------------------------------------------------------------- account mappingの作成 Active Directory Users and Computers ツールを起動しなさい。メニューのすぐ左下のView メニューを選択して(Alt+V)、Advanced Featuresを選択する。name mappingをするユーザ の上で右クリックして、name mapingを選びなさい。 Kerberos Namesのタブをクリックして、non-Windows ドメインから新しいprincipalを加える。 -------------------------------------------------------------------------------- 暗号化タイプ Windows2000はMD4に基づいた標準のDES暗号化(des-cbc-crcとdes-cbc-md5)と、draft-brezak- win2k-krb-rc4-hmac-03.txt に記述されると仮定され、文書化されているMD4とrc4に基づ いたそれ自身の独占暗号化の両方をサポートしている。新しいユーザは、MD4とDESキーの 両方を得るだろう。NT4データベースから変換されたユーザは、MD4 パスワードを持って いるだけであり、そしてDESキーを手に入れるためにパスワードの変化を必要とするだろ う。 Heimdalはこれらの暗号化タイプの両方を実現するが、DESが規格であり, hmac-codeがい くらか新しいので、それはよりよく動きそうである。 -------------------------------------------------------------------------------- 認可データ Windows2000KDCはticketの中に余分な認可データも加える。何がこれをするための引き金 になるかは不明である。このデータの形式は、マイクロソフトからの「secret」ライセン スの許可の元だけで利用できるだけである。そしてそれは実装することを禁止する。 よりよくそれを理解できるデータを得る単純な方法が、ここで記述される。 1.SDK documentationでSSPIを使用することに関するclientの例を見つける。 2.小文字にするためにソースコードで“AuthSamp"を変える。 3.プログラムを組立てる。 4.知られたパスワードを用いて"authsamp"principalをデータベースに追加 する。DESキー があるのを確認する。 5.principalのために、keyをkeytabに加えるために ktutil add を走らせる。 6.適切なところにあるファイル appl/test/nt_gss_server -p 2000 -s authsamp --dump-auth=file を走らせる。 7.ファイルにおいて認可データを認証し、投げ出すべきだ。 8.データを分析するのに、lib/asn1/asn1_print のツールは幾分役に立つ。 -------------------------------------------------------------------------------- Windows2000KDCの癖 saltとWindows2000を用いていくつかの問題がある。空のsaltを使用することは、そして それはKerberos 4たった一つをサポートしており、それゆえにKerberos4のcompatible salt は動かないと知られているのだが、実験され、ユーザが報告することができる。よってkey 周りに必要とされているすべての異なったタイプのsaltを用いて保たなければならない。 マイクロソフトはまたchecksumのアルゴリズムの rsa-md4-des と rsa-md5-des を実現す るのを忘れたように思える。des-cbc-md5 key が使用されるならば、これはCreate account mappings に参照されるName mapping によって失敗することができる。KDC return を des- cbc-crc だけにするために、kadmin del_enctypeコマンドを使用してkdcからdes-cbc-md5 key を削除しなければならない。 kadmin del_enctype lha des-cbc-md5 また、以下のentryもkrb5.confファイルに追加するべきである。 [libdefaults] default_etypes = des-cbc-crc default_etypes_des = des-cbc-crc これらの構成オプションは、サポートされていないタイプのchecksumsが発生しないこと を確認する。 -------------------------------------------------------------------------------- Windows2000に関しての役立つリンク マイクロソフトのウェブサイトにKerberosに関する多くのテキストがある。ここで、なん とか見つけることができたおもしろいドキュメントの短いリストがある。 ・Step-by-Step Guide to Kerberos 5 (krb5 1.0) Interoperability - Kerberos GSS-API (in Windows-ize SSPI), Windows as a client in a non-Windows KDC realm, adding unix clients toa Windows 2000 KDC, and adding cross-realm trust (See Inter-Realm keys (trust) between Windows 2000 and a Heimdal KDC.). ・Windows 2000 Kerberos Authentication - White paper thatdescribes how Kerberos is used in Windows 2000. ・Overview of kerberos - Links to useful other links. ・Klist for windows - Describes where to get a klist for Windows 2000. ・Event logging for kerberos- . Basicly it saythat you can add a registry key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters \LogLevel with value DWORD equal to 1, and then you'll getlogging in the Event Logger. 他の役に立つプログラムはこれらを含んでいる。 ・pwdump2 -------------------------------------------------------------------------------- 承認 Eric Youngは“libdes"を書いた。 カリフォルニア大学Berkeley校は初めにtelnetおよびtelnetdを書いた。telnetとtelnetd の認証と暗号化コードはDavid Borman(そしてCray Research,Inc)によって加えられた。 暗号化コードはこれが輸出されたとき取り除かれ、Juha Eskelinen、esc@magic.fiにより 加えられた。 popperは当初Berkeleyプログラムでもあった。 librokenの機能のいくつかは、NetBSD/FreeBSDを通してBerkeleyから来る。 editlineはSimmule TurnerとRich Salzより書かれた。 以下のBugfixes、documentation、encouragement、codeは寄付された。 Derrick J Brashear shadow@dementia.org Ken Hornstein kenh@cmf.nrl.navy.mil Johan Ihr駭 (文字化けしていました) johani@pdc.kth.se Love Hnquist-strand(文字化けしていました。) e96_lho@e.kth.se Magnus Ahltorp map@stacken.kth.se Mark Eichin eichin@cygnus.com Marc Horowitz marc@cygnus.com Luke Howard lukeh@xedoc.com.au Brandon S. Allbery KF8NH allbery@kf8nh.apk.net Jun-ichiro itojun Hagino itojun@kame.net Daniel Kouril kouril@informatics.muni.cz Ake Sandgren ake@cs.umu.se Michal Vocu michal@karlin.mff.cuni.cz Miroslav Ruda ruda@ics.muni.cz Brian A May bmay@snoopy.apana.org.au Chaskiel M Grundman cg2v@andrew.cmu.edu そしてここに言及されなかった人々が我々を許すことを望んでいる。 すべてのバグが自分達で導入された。