管理の手引き


サーバー暗号化鍵の管理

この章では、AFS でのセキュア通信に欠かせない、所属するセルのサーバー暗号化鍵の管理方法について説明します。


説明の要約

この章では、以下のタスクを、その隣に示されたコマンドを使用して実行するための方法について説明します。
新規サーバー暗号化鍵を追加する bos addkey および kas setpassword
認証データベース内の鍵のチェックサムを検査する kas examine
KeyFile 内の鍵のチェックサムを検査する bos listkeys
古いサーバー暗号化鍵を削除する bos removekey


サーバー暗号化鍵について

暗号化鍵は、情報のパケットを暗号化および複号するために使用する 8 進数のストリングです。AFS では、サーバー暗号化鍵は、AFS サーバー・プロセスとそのクライアント間で転送される情報を保護するために使用される鍵です。サーバー暗号化鍵は、本質的にサーバー・プロセスに対するパスワードであり、ユーザー・パスワードと同様に認証データベースに保管されます。

AFS ファイル・スペース内の情報を権限のないユーザーのアクセスから保護する最も基本的な方法は、セルのサーバー暗号化鍵を適切に管理することです。

鍵および相互認証: 概要

サーバー暗号化鍵は、 AFS 内のクライアントとサーバー・プロセスとの間の相互認証において中心的な役割を果たします。相互認証の詳細な説明については、相互認証の詳細を参照してください。

クライアントが AFS サーバーと通信する場合、クライアントはまず認証サーバーのチケット付与サービス (TGS) モジュールと通信します。TGS は、クライアントの確認検査 (間接的にそのクライアントが表す人物のパスワードに基づく) を行った後で、クライアントにサーバー・チケットを付与します。このチケットは、サーバーの暗号化鍵によって暗号化されます。 (TGS はまた、 セッション鍵 と呼ばれる 2 番目の暗号化鍵を作成し、サーバーとクライアント間の単一の通信に使用します。サーバー・チケットおよびセッション鍵は、その他の情報も含めて、一まとまりでトークンとして言及されます。)

クライアントは、サーバー暗号化鍵を知らないため、サーバー・チケットを読み取ることができません。ただし、クライアントはサーバー・チケットと一緒にサービス要求を AFS サーバーに送信します。これは、サーバー・チケットがクライアントが既に TGS によって認証されていることを AFS サーバー・プロセスに示すからです。 AFS サーバーは、TGS が有効なクライアントのみにチケットを付与することに依存しています。クライアントがサーバーの暗号化鍵で暗号化されたチケットを持っているという事実は、そのクライアントが有効であることをサーバーに対して示します。一方、クライアントは、本物の AFS サーバーのみがチケットを複号するために必要なサーバー暗号化鍵を知っていることを前提とします。チケットを復号し、その内容を理解するサーバーの機能は、サーバーが本物であるとクライアントに証明するものです。

AFS サーバー暗号化鍵の保守

セルのサーバー暗号化鍵の保守にあたっては、以下に留意してください。


サーバー暗号化鍵の表示

いずれかのファイル・サーバー・マシンの /usr/afs/etc/KeyFile ファイルにあるサーバー暗号化鍵を表示するには、bos listkeys コマンドを使用します。認証データベースの afs 項目にある鍵を表示するには、kas examine コマンドを使用します。

コマンドはデフォルトでは、鍵を構成する 8 進数の実際の文字列を表示することはなく、鍵に定数を暗号化することにより発生する 10 進数である チェックサム を表示します。これにより、権限のないユーザーが実際の鍵に容易にはアクセスし、これを誤って使用したり、保護された通信から盗み出したりすることがないようにしています。

bos listkeys および kas examine コマンドにより所定の鍵の同一のチェックサムが生成されるため、一般的には実際の鍵ではなくチェックサムの表示で十分です。チェックサムによっては分からないような形で鍵が正しくないことが疑われる場合は、セル内全体で認証に問題が発生している可能性があります。最も簡単な解決法は、 サーバー暗号化鍵の追加 または サーバー暗号化鍵の緊急事態の取り扱い の手順で新規にサーバー暗号化鍵を作成するものです。この他に bos listkeys コマンドを発行する一般的な理由としては、次の鍵を選択する準備として、現在使用している鍵バージョン番号を表示することがあげられます。この場合も、鍵そのものは関係ないので、チェックサムで十分です。

実際の 8 進数を表示する必要があれば、-showkey 引き数を bos listkeyskas examine コマンドの両方に組み込みます。

KeyFile ファイルの表示

  1. /usr/afs/etc/UserList ファイルにリストされているユーザーとして認証されていることを検証します。必要な場合には、bos listusers コマンドを発行します。このコマンドについては、UserList ファイルのユーザーの表示で詳しく説明しています。

       % bos listusers <machine name>
    
  2. bos listkeys コマンドを発行し、 1 つのマシンの /usr/afs/etc/KeyFile ファイルの内容を表示します。

       % bos listkeys <machine name> [-showkey]
    

    ここで、

    listk
    listkeys の受け入れ可能な省略形です。

    machine name
    ファイル・サーバー・マシン名です。通常は、セルが正しく機能するためには KeyFile ファイルがすべてのマシンで同一であるよう要求されるので、いずれのマシンの指定も可能です。

    -showkey
    それぞれの鍵を構成する 8 進数を表示します。

以下の例では、出力に実際の 8 進数ではなくそれぞれのサーバー暗号化鍵のチェックサムが表示されています。最後から 2 番目の行には、管理者が最後にファイルを変更した日時が示され、最終行には出力が管理者が完了したことが示されています。

   % bos listkeys fs1.abc.com
   key 0 has cksum 972037177
   key 1 has cksum 2825165022
   Keys last changed on Wed Jan 13 11:20:29 1999.
   All done.

認証データベースの afs 鍵の表示

  1. kas examine コマンドを発行して、認証データベースの afs 項目を表示します。

    認証サーバーは、既存の AFS トークンを受け入れるのではなく、独自の認証を実行します。デフォルトでは、認証サーバーは、管理者のローカル (UNIX) 識別を認証します。この識別は AFS 特権管理者に対応しません。 -admin 引き数を組み込み、認証データベース項目に ADMIN フラグを持つ識別を指定します。項目にフラグがあることを確認するには、ADMIN フラグがオンになっていることを確認するで説明するように、kas examine コマンドを発行します。

       % kas examine afs [-showkey]  \
                         -admin <admin principal to use for authentication>
        Administrator's (admin_user) password: admin_password
    

    ここで、

    e
    examine の最も短い受け入れ可能な省略形です。

    afs
    afs 項目を指定します。

    -showkey
    鍵を構成する 8 進数を表示します。

    -admin
    認証データベース項目に ADMIN フラグを持つ管理アカウントを指定します (admin など)。password プロンプトはアカウントを admin_user として表示します。適切なパスワードを、admin_password として入力します。

以下の例では、admin ユーザーが -showkey フラグを使用せずに afs 項目を表示します。2 番目の行は、括弧に囲まれた鍵のバージョン番号および鍵のチェックサムを示します。last mod 文字列で始まる行は、指示された管理者が鍵を変更した日付を示しています。この日付と、 bos listkeys コマンドが報告する日付には関連がなくても構いません。後者の日付は、鍵の追加だけではなく、KeyFile ファイルを変更すると更新されるためです。 kas examine コマンドの出力の他の行に関する詳細は、AFS Administration Reference の解説ページを参照してください。

   % kas examine afs  -admin admin
   Administrator's (admin) password: admin_password
   User data for afs
    key (1) cksum is 2825165022, last cpw: no date
    password will never expire.
    An unlimited number of unsuccessful authentications is permitted.
    entry expires on never. Max ticket lifetime 100.00 hours.
    last mod on Wed Jan 13 11:21:36 1999 by admin
    permit password reuse

サーバー暗号化鍵の追加

前述のとおり、AFS がサーバー暗号化鍵を 2 つの場所に記録します。

  1. 各ファイル・サーバー・マシンのローカル・ディスク上のファイル /usr/afs/etc/KeyFile 内に、各マシン上で実行する AFS サーバー・プロセス用として。
  2. 認証データベース内の afs 項目に、トークン作成時にチケット付与サービス (TGS) 用として。

サーバー・プロセスと TGS が同一の AFS サーバー暗号化鍵を使用するようにするために、この節に記載するすべてのステップを中断せずに実行してください。

以下の説明には、すべてのデータベース・サーバー・マシンでデータベース・プロセス (認証、バックアップ、保護、およびボリューム・ロケーション・サーバー) を再始動するステップが含まれています。データベース・サーバー・プロセスが開始すると、これは KeyFile ファイル中、最大の鍵バージョン番号を持つサーバー暗号化鍵を読み取り、これを使用してデータベースの同期化および定数の保持のための送信メッセージを保護します。プロセスは、 KeyFile ファイルから鍵が除去された場合でも存続時間中は同一の鍵を使用し、これは長期におよぶことがあります。ただし、ピア・データベース・サーバーの 1 つが再始動して、他が再始動しない場合、プロセスはもはや同一の鍵を使用しないため、定数およびデータベース同期が中断されます。再始動したプロセスは、現在最大の鍵バージョン番号を持つ鍵を使用し、他のプロセスはその開始時に読み込んだ鍵を使用しています。こうした問題を避けるには、新規の鍵を追加する場合は、すべてのデータベース・プロセスを再始動するのが最も安全な方法です。

新規鍵を追加したら、KeyFile ファイルから古い鍵を除去し、混乱しないようにします。ただし、クライアントまたはサーバー・プロセスがまだ使用している鍵を除去しないように注意してください。詳細については、サーバー暗号化鍵の削除 を参照してください。

新規サーバー暗号化鍵の追加方法

  1. /usr/afs/etc/UserList ファイルにリストされているユーザーとして認証されていることを検証します。必要な場合には、bos listusers コマンドを発行します。このコマンドについては、UserList ファイルのユーザーの表示で詳しく説明しています。

       % bos listusers <machine name>
    
  2. bos listkeys コマンドを発行して、新しい鍵のバージョン番号を選択する最初のステップとして、既に使用されている鍵バージョン番号を表示します。

       % bos listkeys <machine name>
    

    ここで、

    listk
    listkeys の受け入れ可能な省略形です。

    machine name
    任意のファイル・サーバー・マシンを指定します。
  3. 2 のステップの出力、および以下の要件に基づいて、新しい鍵のバージョン番号を選択します。
  4. bos addkey コマンドを発行し、KeyFile ファイルに新規の AFS サーバー暗号化鍵を作成します。

    米国版の AFS を実行し、更新サーバーを使用してシステム制御マシンの /usr/afs/etc ディレクトリーの内容を配布する場合は、machine name 引き数をシステム制御マシンに置き換えます。 (システム制御マシンはどれかを忘れてしまった場合には、システム制御マシンを特定するには を参照してください。)

    国際版の AFS を実行する場合、あるいは更新サーバーを使用しない場合は、machine name 引き数を順に各サーバー・マシンに置き換えて、bos addkey コマンドを繰り返します。

    新規鍵に対応する文字列が表示されないようにするには、コマンド行から -key 引き数を省略します。代わりに省略した際に表示されるプロンプトで文字列を入力します。以下の構文指定を参照してください。

       % bos addkey  -server <machine name> -kvno <key version number>
       input key: afs_password
       Retype input key: afs_password
    

    ここで、

    addk
    addkey の受け入れ可能な省略形です。

    -server
    更新サーバーを使用している場合は、セルのシステム制御マシン、または使用していない場合は、それぞれのサーバー・マシンを指定します。

    -kvno
    新しい鍵のバージョン番号を、 0 (ゼロ) から 255 までの範囲の整数として指定します。

    番号を忘れないようにしてください。この番号は、 6 のステップでも再度使用します。 AFS の米国版を使用している場合は、このコマンドを発行するときには必ず同じ番号をタイプしてください。

    afs_password
    1 文字から約 1,000 文字までの長さの、ユーザー・パスワードに類似した文字ストリングです。セキュリティーを向上させるには、アルファベット以外の文字を組み込み、文字列を実用的な範囲で長くします (これを入力する必要があるのは、このステップと 6 のステップだけです)。 AFS の国際版を使用している場合は、このコマンドをタイプするときには、必ず同じストリングを使用してください。

    8 進数のストリングを直接入力しないでください。BOS サーバーは、その文字ストリングをスクランブルして、暗号化鍵としての使用に適した 8 進数に変換し、その後で KeyFile ファイルに記録します。

  5. 更新サーバーを使用している場合は、更新サーバーが新しい KeyFile ファイルをすべてのサーバー・マシンに配布している間、数分間待ちます。必要な最大待機期間は、任意のサーバー・マシンに対する upclientetc プロセスの初期化コマンドで指定する -t 引き数に提供する最大値です。デフォルトの時間は 5 分です。

    すべてのマシンが同じ KeyFile ファイルを持つかどうかを確認するには、各ファイル・サーバー・マシンに対して bos listkeys コマンドを発行して、新規鍵のチェックサムがすべてのマシンについて同じになるか検証します。

       % bos listkeys <machine name>
    

    更新サーバーを使用しない場合は、 4 のステップを 5 分以内で完了するようにしてください。

  6. kas setpassword コマンドを発行して、認証データベースの afs 項目に同じ鍵を入力します。

    認証サーバーは、既存の AFS トークンを受け入れるのではなく、独自の認証を実行します。デフォルトでは、認証サーバーは、管理者のローカル (UNIX) 識別を認証します。この識別は AFS 特権管理者に対応しません。 -admin 引き数を組み込み、認証データベース項目に ADMIN フラグを持つ識別を指定します。項目にフラグがあることを確認するには、ADMIN フラグがオンになっていることを確認するで説明するように、kas examine コマンドを発行します。

       % kas setpassword -name afs -kvno <kvno>  \
                         -admin <admin principal to use for authentication>
       Administrator's (admin_user) password: admin_password
       new_password: afs_password
       Verifying, please re-enter new_password: afs_password
    

    ここで、

    sp
    setpassword の受け入れ可能な別名です (setp は受け入れ可能な最も短い省略形です)。

    -name afs
    新規鍵を afs 項目に作成します。

    -kvno
    4 のステップと同じ鍵バージョン番号を指定します。

    -admin
    認証データベース項目に ADMIN フラグを持つ管理アカウントを指定します (admin など)。password プロンプトはアカウントを admin_user として表示します。適切なパスワードを、admin_password として入力します。

    afs_password
    4 のステップで入力したものと同じ文字列です。
  7. (オプション) KeyFile ファイルおよび認証データベースの afs 項目で作成した鍵が同一であり、同じ鍵バージョン番号を持つことを検査する場合は、 サーバー暗号化鍵の表示 の手順に従ってください。
  8. bos restart コマンドを発行して、すべてのデータベース・サーバー・マシンでデータベース・サーバー・プロセスを再始動します。これにより、現在最大のバージョン番号を持つ KeyFile ファイル中の鍵が使用されるようになります。

    それぞれのデータベース・サーバー・マシンについて、最下位の IP アドレスを持つものから開始して、このコマンドを連続して繰り返します。

       % bos restart <machine name> buserver kaserver ptserver vlserver
    

    ここで、

    res
    restart の受け入れ可能な最も短い省略形です。

    machine name
    それぞれのデータベース・サーバー・マシンを順に命名します。

    buserver kaserver ptserver vlserver
    それぞれ、バックアップ・サーバー、認証サーバー、保護サーバー、およびボリューム・ロケーション (VL) サーバーを指定します。

サーバー暗号化鍵の削除

/usr/afs/etc/KeyFile ファイルから古い鍵を定期的に除去し、これを適切なサイズに保持することができます。セル機能を混乱させることがないよう、古い鍵の除去は、その鍵を使用して暗号化し、ユーザーまたはクライアント・プロセスが保持しているトークンがすべて期限切れになるまでは行わないようにしてください。新規鍵の追加後は、最低でもセル内で使用する最長のトークン存続時間の間は待ってから古い鍵を除去してください。 AFS バージョン 3.1 で作成された認証データベースのユーザー項目の場合、デフォルトのトークン存続時間は 25 時間、AFS バージョン 3.0 で作成された項目は、100 時間となっています。

認証データベースの afs 項目は、鍵フィールドを空にすることができないため、この項目から鍵を削除するコマンドはありません。 kas setpassword コマンドを使用して、 afs キーを置き換えますが、これは 新規サーバー暗号化鍵の追加方法 に詳細が説明されている完全な手順の一部です。

現在 認証データベースの afs 項目にある KeyFile ファイルからは鍵を削除しないでください。 AFS サーバー・プロセスは、クライアントが示すチケットの暗号化ができなくなります。

KeyFile ファイルの鍵の除去

  1. /usr/afs/etc/UserList ファイルにリストされているユーザーとして認証されていることを検証します。必要な場合には、bos listusers コマンドを発行します。このコマンドについては、UserList ファイルのユーザーの表示で詳しく説明しています。

       % bos listusers <machine name>
    
  2. bos listkeys コマンドを発行し、除去する鍵のそれぞれの鍵バージョン番号を表示します。出力には、新しい鍵が KeyFile ファイルに入れられてから最低 25 時間経過したかどうかが示されます。bos listkeys コマンドの完全な説明については、KeyFile ファイルの表示 を参照してください。

       % bos listkeys <machine name>
    
  3. kas examine コマンドを発行し、現在認証データベース の afs 項目にある鍵が、 KeyFile ファイルから除去するいずれの鍵とも同じ鍵バージョン番号を持たないことを確認します。 kas examine コマンドの詳細は、 認証データベースの afs 鍵の表示 を参照してください。

       % kas examine afs  -admin <admin principal to use for authentication>
       Administrator's (admin_user) password: admin_password
    
  4. bos removekey コマンドを発行し、KeyFile ファイルから 1 つ以上のサーバー暗号化鍵を削除します。

    米国版の AFS を実行し、更新サーバーを使用してシステム制御マシンの /usr/afs/etc ディレクトリーの内容を配布する場合は、machine name 引き数をシステム制御マシンに置き換えます。 (システム制御マシンはどれかを忘れてしまった場合には、システム制御マシンを特定するには を参照してください。)

    国際版の AFS を実行する場合、あるいは更新サーバーを使用しない場合は、machine name 引き数を順に各サーバー・マシンに置き換えて、bos removekey コマンドを繰り返します。

       % bos removekey <machine name> <key version number>
    

    ここで、

    removek
    removekey の受け入れ可能な省略形です。

    machine name
    更新サーバーを使用している場合は、セルのシステム制御マシン、または使用していない場合は、それぞれのサーバー・マシンを指定します。

    key version number
    削除する各鍵のバージョン番号を指定します。

サーバー暗号化鍵の緊急事態の取り扱い

まれに、クライアントあるいはピア・サーバー・プロセスが提供するサーバー・チケットを、AFS サーバー・プロセスが復号できなくなることがあります。サーバー・プロセスが、それらのチケットが偽造されたものであるか、または有効期限切れのものであると判断し、任意のアクションの実行を拒絶するため、セル内の活動は停止します。このような事態は 1 つまたはいくつかのマシンで発生する可能性がありますが、より多くのマシンがかかわる場合は影響がより深刻になります。

サーバー暗号化鍵問題の 1 つの一般的な原因は、クライアントのチケットがサーバー・プロセスが認識しない鍵を使用して暗号化される場合です。通常これは、サーバー・マシン上の /usr/afs/etc/KeyFile に、認証サーバーのチケット付与サービス (TGS) モジュールがサーバー・チケットを暗号化するのに使用する afs 認証データベース項目の鍵が含まれていないことを意味します。

別の可能性は、異なるマシン上の KeyFile ファイルが同じ鍵を持たない場合です。この場合、サーバー・プロセス間の通信は不可能になります。たとえば、異なるデータベース・サーバー・マシン上のデータベース・サーバー・プロセスのインスタンスが同じサーバー暗号化鍵を使用しない場合は、 AFS の複製データベース機構 (Ubik) は中断します。

bos コマンドをローカル・セル内のファイル・サーバー・マシンに送信したときに、次のメッセージを送信することがあると、これはサーバー暗号化化鍵のミスマッチの兆候です。 (ただし、bos コマンドを外部セル内のファイル・サーバー・マシンに送信したときに -cell 引き数を指定しなかった場合も、このメッセージを受信することに注意してください。)

   bos: failed to contact host's bosserver (security object was passed a bad ticket).

サーバー暗号化鍵の緊急事態の解決方法は、すべてのファイル・サーバー・マシン上の認証データベースおよび KeyFile の両方に新しい AFS サーバー暗号化鍵を入れることです。これにより、TGS およびすべてのサーバー・プロセスが再度同じ鍵を共有するようになります。

鍵の緊急事態の処理では、特別なアクションが要求されます。これらのアクションを使用する理由が以下の機能グループに説明されています。実際の手順は、後続の説明に記載されています。

相互認証が行えない

鍵の緊急事態を取り扱っているときには、サーバー・プロセスがユーザーとの間で相互認証を行おうとすることを避ける必要があります。なぜなら、ユーザーのトークンをサーバー・プロセスが解読できない可能性があるからです。相互認証を行わない場合は、サーバー・プロセスはユーザーに一致 anonymous を割り当てます。相互認証を行わないようにするには、unlog コマンドを使用してトークンを破棄し、 -noauth フラグが使用可能なコマンドにこれを組み込みます。

手動で許可検査を使用不可にする

相互認証を行わない場合は、サーバー・プロセスがユーザーを anonymous であると認識するため、許可検査をオフにする必要があります。サーバー・プロセスは、許可検査を使用不可にした場合のみ anonymous が鍵の作成などの特権が必要なアクションを実行することを許可します。

緊急事態では、手動でファイル /usr/afs/local/NoAuth を作成して許可検査を使用不可にします。通常は、代わりに bos setauth コマンドを使用します。

各マシン上で迅速に作業する

許可検査を使用不可にすると、その影響を受けるマシン上のサーバー・プロセスがどのユーザーに対してもアクションを取るため、セキュリティーが重大な危機にさらされます。許可検査を使用不可にする際には、中断しないセッションですべてのステップをできる限り迅速に完了し、必要な期間のみ実行する必要があります。

コンソールで作業する

認可検査を使用不可にするそれぞれのサーバー・マシンのコンソールで作業をすることにより、ユーザーがそこで作業をしている間は、他のユーザーは誰もそのコンソールにログオンすることはありません。他のユーザーがそのマシンにリモートに接続 (たとえば telnet プログラムを使用するなど) することを防ぐわけではないため、迅速に作業することが重要です。完全なセキュリティーを確保するためには、ネットワーク通信を使用不可にしますが、これは多くの環境では実行可能な選択ではありません。 セル内のセキュリティー改善 で推奨しているように、サーバー・マシンに常時リモート接続できる人数を制限すると、全般的なセキュリティーを向上させることができます。

個々の KeyFile ファイルを変更する

更新サーバーを使用して /usr/afs/etc ディレクトリーの内容を配布すると、緊急事態になるのは、個々のマシン上の KeyFile ファイルを変更するころ合いになった場合のみになります。各マシンのファイルを更新する必要があるのは、不一致となったキーにより、システム制御マシンの upserver プロセスが、他のサーバー・マシン上の upclientetc プロセスと相互認証できなくなり、upserver プロセスがその KeyFile ファイルを upclientetc プロセスに配布するのを拒否するからです。

更新サーバーが正常に作動しているように見えても、それを確認する唯一の方法は、システム制御マシン上の鍵を変更して、標準遅延時間を待って upclientetc プロセスがそのキーを取り出すかどうかを確認することです。緊急事態では、標準遅延時間の間待機することは普通意味がありません。単に各サーバー・マシン上のファイルを別々に更新するほうがより効果的です。また、更新サーバーがファイルを正しく配布する場合でも、キーの不一致のために他のプロセスに問題が発生する可能性もあります。以下の説明では、最初にシステム制御マシンに新規の鍵ファイルを追加しています。更新サーバーが作動していれば、それぞれのサーバー上で個々に行った変更と同じ変更を配布することになります。

所属するセルが更新サーバーを使用しない、または AFS 国際版を使用する場合は、常にサーバー・マシン上の鍵を個別に変更します。以下の説明もまた役立ちます。

2 つのコンポーネント・プロシージャー

以下の説明では、頻繁に使用される 2 つのサブプロシージャー、許可検査の使用不可および許可検査の再使用可能化を記載します。分かりやすいように、ここではプロシージャーを詳細に説明します。必要である場合は、プロシージャーを参照します。

緊急事態において許可検査を使用不可にする

  1. まだの場合は、su コマンドを発行し、マシン上でローカル・スーパーユーザー root になります。

       % su root
       Password: root_password
    
  2. ファイル /usr/afs/local/NoAuth を作成して、許可検査を使用不可にします。

       # touch /usr/afs/local/NoAuth
    
  3. トークンが互換性のない鍵で暗号化された場合、いくつかのコマンドが実行されない可能性があるため、トークンを破棄します。

       # unlog
    

緊急事態において許可検査を再度使用可能にする

  1. まだの場合は、su コマンドを発行し、マシン上でローカル・スーパーユーザー root になります。

       % su root
       Password: root_password
    
  2. /usr/afs/local/NoAuth ファイルを除去します。

       # rm /usr/afs/local/NoAuth
    
  3. system:administrators グループに含まれ、 /usr/afs/etc/UserList ファイルにリストされる管理 ID として認証をする。

       # klog <admin_user>
       Password: <admin_password>
    
  4. 問題がなければ、 unlog コマンドを発行してユーザーのトークンを破棄した後で、マシンのコンソールからログアウトします (または使用するリモート接続をクローズします)。

緊急事態における新規サーバー暗号化鍵の作成方法

  1. システム制御マシン上で緊急事態において許可検査を使用不可にする の説明に従い、許可検査を使用不可にします。
  2. bos listkeys コマンドを発行して、新しい鍵のバージョン番号を選択する最初のステップとして、KeyFile ファイルで使用されている鍵バージョン番号を表示します。

       # bos listkeys <machine name> -noauth
    

    ここで、

    listk
    listkeys の受け入れ可能な省略形です。

    machine name
    ファイル・サーバー・マシンを指定します。

    -noauth
    BOS サーバーとの相互認証をバイパスします。鍵の緊急事態により、相互認証が正常に行われない場合に、これを組み込みます。
  3. 2 のステップで調べた事柄、および以下の要件に基づいて、新しい鍵のバージョン番号を選択します。
  4. システム制御マシン上でbos addkey コマンドを発行し、 KeyFile ファイルに新しい AFS サーバー暗号化鍵を作成します。

       # bos addkey <machine name> -kvno <key version number> -noauth
       input key: afs_password
       Retype input key: afs_password
    

    ここで、

    addk
    addkey の受け入れ可能な省略形です。

    machine name
    KeyFile ファイルに新しい鍵を定義するファイル・サーバー・マシンの名前です。

    -kvno
    3 のステップで選択した鍵のバージョン番号を選択します。 0 (ゼロ) から 255 までの範囲の整数です。 78、および 13 のステップでは、同じ数を指定する必要があります。

    -noauth
    BOS サーバーとの相互認証をバイパスします。鍵の緊急事態により、相互認証が正常に行われない場合に、これを組み込みます。

    afs_password
    1 文字から約 1,000 文字までの長さの、ユーザー・パスワードに類似した文字ストリングです。セキュリティー向上のため、実用的である範囲で文字列を長くし、アルファベット以外の文字を含めます。

    8 進数のストリングを直接タイプしないでください。 BOS サーバーは、その文字ストリングをスクランブルして、暗号化鍵としての使用に適した 8 進数に変換し、その後で KeyFile ファイルに記録します。

    ストリングを忘れないようにしてください。これを再度、78、および 13 のステップで使用します。

  5. 所属するセル内のすべてのデータベース・サーバー・マシン上で (システム制御マシン以外)、 緊急事態において許可検査を使用不可にする の指示に従い許可検査を使用不可にします。システム制御マシンがデータベース・サーバー・マシンの場合は、既に 1 のステップで許可検査を使用不可にしているので、手順を繰り返さないでください。 (どのマシンがデータベース・サーバー・マシンであるかを確認する必要がある場合は、 データベース・サーバー・マシンを特定するには で説明している bos listhosts コマンドを使用してください。)
  6. 5 のステップを終了した後で最低 90 秒待ち、それぞれのデータベース・サーバーのプロセス (認証サーバー、バックアップ・サーバー、保護サーバー、およびボリューム配置サーバー) が新規の同期サイトの選択を完了するようにします。その上で udebug コマンドを発行し、選択が正しく行われたかを確認します。以下のコマンドを発行します。 server machine のそれぞれのデータベース・サーバー・マシン名を順に置換します。システム制御マシンがデータベース・サーバー・マシンであれば、これを組み込みます。

       # udebug <server machine> buserver
       # udebug <server machine> kaserver
       # udebug <server machine> ptserver
       # udebug <server machine> vlserver
    

    それぞれのプロセスについて、すべてのデータベース・サーバー・マシンからの出力は、そのサイトがプロセスに対する同期サイトかという点において一致している必要があります。ただし、同じマシンをそれぞれ 4 つのプロセスの同期サイトにする必要はありません。それぞれのプロセスにつき、 1 つのマシンのみの出力が以下の文字列を含むようにします。

       I am sync site ...
    

    他のマシンの出力は、代わりに以下の行を含みます。

       I am not sync site
    

    および以降の行 (文字列 Sync host に始まり、同期サイトであると表示されるマシンの IP アドレスを指定) を含む必要があります。

    出力がこれらの要件と一致しない場合、またはその他の点で問題があると思われる場合は、 AFS プロダクト・サポートに連絡してサポートを受けてください。

  7. 所属するセル内のすべてのデータベース・サーバー・マシン上で (システム制御マシン以外)、 4 のステップで説明している bos addkey コマンドを実行します。必ずそのステップで使用したものと同じ値を、afs_password および kvno で使用してください
  8. kas setpassword コマンドを発行して、認証データベースの afs 項目に新規の鍵を定義します。これは、4 および 7 のステップで作成したキーに一致しなくてはなりません。

       # kas setpassword  -name afs  -kvno <key version number> -noauth
       new_password: afs_password
       Verifying, please re-enter new_password: afs_password
    

    ここで、

    sp
    setpassword の受け入れ可能な別名です (setp は受け入れ可能な最も短い省略形です)。

    -kvno
    4 のステップで指定したものと同じ鍵バージョン番号です。

    afs_password
    4 のステップで afs_password として指定したものと同じ文字列です。文字ストリングは画面にそのまま表示されません。
  9. 所属するセル内のすべてのデータベース・サーバー・マシン上で (システム制御マシンがデータベース・サーバー・マシンであればこれも含む)、 緊急事態において許可検査を再度使用可能にする の説明に従い許可検査を再度使用可能にします。システム制御マシンがデータベース・サーバー・マシンでない場合、この手順は 11 のステップまで実行しないでください。
  10. 6 のステップを繰り返し、 9 のステップで再始動してから各データベース・サーバー・プロセスが適切に同期サイトを選択したかどうかを検査します。
  11. システム制御マシン上で (これがデータベース・サーバー・マシンでない場合)、 緊急事態において許可検査を再度使用可能にする の指示に従い許可検査を再度使用可能にします。これがデータベース・サーバー・マシンであれば、既に 9 のステップで手順を実行しています。
  12. すべて残りの (単純) ファイル・サーバー・マシンで緊急事態において許可検査を使用不可にする の手順に従い許可検査を使用不可にします。
  13. すべての残りの (単純) ファイル・サーバー・マシンでbos addkey コマンドを発行します。 4 のステップを参照してください。必ずそのステップで使用したものと同じ値を、afs_password および kvno で使用してください
  14. すべての残りの (単純) ファイル・サーバー・マシンで緊急事態において許可検査を再度使用可能にする の指示に従い許可検査を再度使用可能にします。


[ ページのトップ | 前ページ | 次ページ | 目次 | 索引 ]



(C) IBM Corporation 2000. All Rights Reserved