| ナビゲーションリンクをスキップ | |
| 印刷ビューの終了 | |
|
Oracle Solaris 11.1 の管理: セキュリティーサービス Oracle Solaris 11.1 Information Library (日本語) |
| ナビゲーションリンクをスキップ | |
| 印刷ビューの終了 | |
|
|
Oracle Solaris 11.1 の管理: セキュリティーサービス Oracle Solaris 11.1 Information Library (日本語) |
パート II システム、ファイル、およびデバイスのセキュリティー
10. Oracle Solaris のセキュリティー属性 (参照)
LDAP データサーバーを使用するように KDC を構成する方法
マスターサーバー上でチケット認可サービス鍵をリフレッシュする方法
Kerberos ネットワークアプリケーションサーバーの構成
Kerberos ネットワークアプリケーションサーバーを構成する方法
FTP の実行時に Generic Security Service を Kerberos とともに使用する方法
複数の Kerberos セキュリティーモードで安全な NFS 環境を設定する方法
Kerberos クライアントのインストールプロファイルの作成方法
Active Directory サーバー用に Kerberos クライアントを構成する方法
Kerberos によって保護された NFS ファイルシステムに root ユーザーとしてアクセスする方法
Kerberos レルム内のユーザーを自動的に移行するように構成する方法
すべてのチケット認可チケット (TGT) を自動的に更新する方法
KDC と Kerberos クライアントのクロックの同期化
Kerberos 主体属性を Kerberos 以外のオブジェクトクラス型に結び付ける方法
辞書ファイルを使用してパスワードセキュリティーを強化する方法
22. Kerberos エラーメッセージとトラブルシューティング
Kerberos データベースは、Kerberos のもっとも重要なコンポーネントであるため、適切に管理する必要があります。このセクションでは、データベースのバックアップと復元、増分または並列伝播の設定、stash ファイルの管理など、Kerberos データベースの管理についていくつかの手順を説明します。データベースを初期設定する手順については、「マスター KDC を手動で構成する方法」を参照してください。
マスター KDC の Kerberos データベースをスレーブ KDC に伝播する処理は、構成タスクの中で最も重要なものの 1 つです。伝播の頻度が低いと、マスター KDC とスレーブ KDC が同期しなくなります。マスター KDC に障害が発生した場合、スレーブ KDC は最新のデータベース情報を持たないことになります。また、負荷を分散するためにスレーブ KDC がマスター KDC として構成されている場合も、そのスレーブ KDC をマスター KDC として使用するクライアントは最新情報を取得できません。このため、Kerberos データベースの変更頻度に基づいて、伝播頻度を適切に構成する必要があります。増分伝播は手動による伝播より優先されます。これは、データベースを手動で伝播すると管理のオーバーヘッドがより大きくなるためです。また、データベースを完全に伝播する場合は、効率が悪いためです。
マスター KDC を構成するときは、cron ジョブ内に kprop_script コマンドを設定して、Kerberos データベースを /var/krb5/slave_datatrans ダンプファイルに自動的にバックアップし、それをスレーブ KDC に伝播します。ただし、他のファイルと同様に、Kerberos データベースは壊れることがあります。スレーブ KDC のデータが壊れた場合でも、次回のデータベース自動伝播によって最新のコピーがインストールされるため、影響が発生しないこともあります。ただし、マスター KDC のデータが壊れた場合は、壊れたデータベースが次回の伝播ですべてのスレーブ KDC に伝播されます。また、壊れたデータがバックアップされると、マスター KDC 上の壊れていない前回のバックアップファイルが上書きされます。
この場合、「安全な」バックアップコピーが存在しないため、cron ジョブを設定して slave_datatrans ダンプファイルを定期的に別の場所にコピーするか、kdb5_util の dump コマンドを使用して別のバックアップコピーを作成することも必要です。これにより、データベースが壊れても、kdb5_util の load コマンドを使用して、マスター KDC の最新のバックアップを復元できます。
次の点も重要です。データベースダンプファイルには主体鍵が含まれているため、許可されないユーザーがアクセスできないように、ファイルを保護する必要があります。デフォルトでは、データベースダンプファイルの読み取り権および書き込み権は、root にのみ与えられます。無許可のアクセスから保護するには、kprop コマンドのみを使用してデータベースダンプファイルを伝播します。これにより、転送されるデータが暗号化されます。また、kprop はデータをスレーブ KDC だけに伝播するため、データベースダンプファイルが間違って許可されないホストに送信される可能性が最小限になります。
 | 注意 - Kerberos データベースが伝播されたあとに更新され、次の伝播の前にデータベースが壊れた場合は、スレーブ KDC には更新が反映されません。この更新は失われます。このため、定期的に実行される伝播の前に重要な更新を追加した場合は、データの損失を回避するために手動でデータベースを伝播する必要があります。 |
スレーブ KDC の kpropd.acl ファイルの各行には、ホスト主体名と、伝播された最新のデータベースの受信元となるシステムが指定されています。マスター KDC を使用してすべてのスレーブ KDC に伝播する場合は、各スレーブ KDC の kpropd.acl ファイルに対してマスター KDC の主体名だけを指定する必要があります。
ただし、このドキュメントの Kerberos のインストールおよびインストール後の構成手順では、マスター KDC とスレーブ KDC に対して同じ kpropd.acl ファイルを追加するように説明しています。このファイルには、すべての KDC ホスト主体名が含まれます。この構成を使用すると、伝播元の KDC が一時的に使用できなくなったときでも、任意の KDC から伝播することができます。また、すべての KDC に同一のコピーを保持すると、構成の管理が容易になります。
kprop_script コマンドは、kprop コマンドを使用して Kerberos データベースをほかの KDC に伝播します。kprop_script コマンドをスレーブ KDC 上で実行すると、そのスレーブ KDC の Kerberos データベースのコピーがほかの KDC に伝播されます。kprop_script には、ホスト名のリストを引数として指定します。区切り文字は空白です。指定したホスト名は、伝播先の KDC になります。
kprop_script を実行すると、Kerberos データベースのバックアップが /var/krb5/slave_datatrans ファイルに作成され、指定した KDC にそのファイルがコピーされます。Kerberos データベースは、伝播が完了するまでロックされます。
始める前に
root 役割になる必要があります。詳細は、「割り当てられている管理権限を使用する方法」を参照してください。
# /usr/sbin/kdb5_util dump [-verbose] [-d dbname] [filename [principals...]]
バックアップする各主体とポリシー名を出力します。
バックアップするデータベース名を定義します。ファイルの絶対パスを指定できます。-d オプションを指定しない場合、デフォルトのデータベース名は /var/krb5/principal となります。
データベースのバックアップに使用するファイルを定義します。ファイルの絶対パスを指定できます。ファイルを指定しなかった場合、データベースは標準出力にダンプされます。
バックアップする主体を 1 つ以上定義します (区切り文字は空白)。主体名は完全指定形式にする必要があります。主体を指定しなかった場合、データベース全体がバックアップされます。
例 21-19 Kerberos データベースのバックアップ
次の例では、Kerberos データベースは dumpfile と呼ばれるファイルにバックアップされます。-verbose オプションが指定されているため、各主体はバックアップされるときに出力されます。
# kdb5_util dump -verbose dumpfile kadmin/kdc1.eng.example.com@ENG.EXAMPLE.COM krbtgt/ENG.EXAMPLE.COM@ENG.EXAMPLE.COM kadmin/history@ENG.EXAMPLE.COM pak/admin@ENG.EXAMPLE.COM pak@ENG.EXAMPLE.COM changepw/kdc1.eng.example.com@ENG.EXAMPLE.COM
次の例では、pak および pak/admin 主体が、Kerberos データベースからバックアップされます。
# kdb5_util dump -verbose dumpfile pak/admin@ENG.EXAMPLE.COM pak@ENG.EXAMPLE.COM pak/admin@ENG.EXAMPLE.COM pak@ENG.EXAMPLE.COM
始める前に
KDC マスター上で root 役割になる必要があります。詳細は、「割り当てられている管理権限を使用する方法」を参照してください。
kdc1 # svcadm disable network/security/krb5kdc kdc1 # svcadm disable network/security/kadmin
# /usr/sbin/kdb5_util load [-verbose] [-d dbname] [-update] [filename]
復元する各主体とポリシー名を出力します。
復元するデータベース名を定義します。ファイルの絶対パスを指定できます。-d オプションを指定しない場合、デフォルトのデータベース名は /var/krb5/principal となります。
既存のデータベースを更新します。指定しない場合、新しいデータベースが作成されるか、既存のデータベースが上書きされます。
データベースの復元に使用するファイルを定義します。ファイルの絶対パスを指定できます。
kdc1 # svcadm enable -r network/security/krb5kdc kdc1 # svcadm enable -r network/security/kadmin
例 21-20 Kerberos データベースの復元
次の例では、database1 というデータベースが、dumpfile ファイルから現在のディレクトリに復元されます。-update オプションが指定されていないため、復元によって新しいデータベースが作成されます。
# kdb5_util load -d database1 dumpfile
Solaris 8 または Solaris 9 リリースが稼働するサーバー上で KDC データベースが作成されている場合、データベースを変換すると、改善されたデータベースのフォーマットを利用できます。
始める前に
データベースが古いフォーマットを使用していることを確認してください。
KDC マスター上で root 役割になる必要があります。詳細は、「割り当てられている管理権限を使用する方法」を参照してください。
kdc1 # svcadm disable network/security/krb5kdc kdc1 # svcadm disable network/security/kadmin
kdc1 # mkdir /var/krb5/tmp kdc1 # chmod 700 /var/krb5/tmp
kdc1 # kdb5_util dump /var/krb5/tmp/prdb.txt
kdc1 # cd /var/krb5 kdc1 # mv princ* tmp/
kdc1 # kdb5_util load /var/krb5/tmp/prdb.txt
kdc1 # svcadm enable -r network/security/krb5kdc kdc1 # svcadm enable -r network/security/kadmin
この手順を使って、増分伝播を使用するように既存のマスター KDC を再構成します。この手順では、次の構成パラメータを使用します。
レルム名 = EXAMPLE.COM
DNS ドメイン名 = example.com
マスター KDC = kdc1.example.com
スレーブ KDC = kdc2.example.com
admin 主体 = kws/admin
始める前に
root 役割になる必要があります。詳細は、「割り当てられている管理権限を使用する方法」を参照してください。
増分伝播を有効にして、ログ内に保持する KDC マスターの更新数を選択する必要があります。詳細は、kdc.conf(4) のマニュアルページを参照してください。
kdc1 # cat /etc/krb5/kdc.conf
[kdcdefaults]
kdc_ports = 88,750
[realms]
EXAMPLE.COM= {
profile = /etc/krb5/krb5.conf
database_name = /var/krb5/principal
acl_file = /etc/krb5/kadm5.acl
kadmind_port = 749
max_life = 8h 0m 0s
max_renewable_life = 7d 0h 0m 0s
sunw_dbprop_enable = true
sunw_dbprop_master_ulogsize = 1000
}kiprop 主体は、マスター KDC サーバーの認証とマスター KDC からの更新の認証に使用されます。
kdc1 # /usr/sbin/kadmin -p kws/admin Enter password: <Type kws/admin password> kadmin: addprinc -randkey kiprop/kdc1.example.com Principal "kiprop/kdc1.example.com@EXAMPLE.COM" created. kadmin: addprinc -randkey kiprop/kdc2.example.com Principal "kiprop/kdc2.example.com@EXAMPLE.COM" created. kadmin:
このエントリにより、マスター KDC が kdc2 サーバーから増分伝播の要求を受け取ることができるようになります。
kdc1 # cat /etc/krb5/kadm5.acl */admin@EXAMPLE.COM * kiprop/kdc2.example.com@EXAMPLE.COM p
この手順により、マスター KDC が KDC データベースのコピーを伝播しなくなります。
kdc1 # crontab -e #ident "@(#)root 1.20 01/11/06 SMI" # # The root crontab should be used to perform accounting data collection. # # The rtc command is run to adjust the real time clock if and when # daylight savings time changes. # 10 3 * * * /usr/sbin/logadm 15 3 * * 0 /usr/lib/fs/nfs/nfsfind 1 2 * * * [ -x /usr/sbin/rtc ] && /usr/sbin/rtc -c > /dev/null 2>&1 30 3 * * * [ -x /usr/lib/gss/gsscred_clean ] && /usr/lib/gss/gsscred_clean #10 3 * * * /usr/lib/krb5kprop_script kdc2.example.sun.com #SUNWkr5ma
kdc1 # svcadm restart network/security/kadmin
詳細な手順については、「スレーブ KDC を再構成して増分伝播を使用する方法」を参照してください。
始める前に
root 役割になる必要があります。詳細は、「割り当てられている管理権限を使用する方法」を参照してください。
最初の新しいエントリにより、増分伝播が有効になります。2 番目の新しいエントリにより、ポーリング時間が 2 分に設定されます。
kdc2 # cat /etc/krb5/kdc.conf
[kdcdefaults]
kdc_ports = 88,750
[realms]
EXAMPLE.COM= {
profile = /etc/krb5/krb5.conf
database_name = /var/krb5/principal
acl_file = /etc/krb5/kadm5.acl
kadmind_port = 749
max_life = 8h 0m 0s
max_renewable_life = 7d 0h 0m 0s
sunw_dbprop_enable = true
sunw_dbprop_slave_poll = 2m
}kdc2 # /usr/sbin/kadmin -p kws/admin
Enter password: <Type kws/admin password>
kadmin: ktadd kiprop/kdc2.example.com
Entry for principal kiprop/kdc2.example.com with kvno 3, encryption type AES-256 CTS mode
with 96-bit SHA-1 HMAC added to keytab WRFILE:/etc/krb5/krb5.keytab.
Entry for principal kiprop/kdc2.example.com with kvno 3, encryption type AES-128 CTS mode
with 96-bit SHA-1 HMAC added to keytab WRFILE:/etc/krb5/krb5.keytab.
Entry for principal kiprop/kdc2.example.com with kvno 3, encryption type Triple DES cbc
mode with HMAC/sha1 added to keytab WRFILE:/etc/krb5/krb5.keytab.
Entry for principal kiprop/kdc2.example.com with kvno 3, encryption type ArcFour
with HMAC/md5 added to keytab WRFILE:/etc/krb5/krb5.keytab.
Entry for principal kiprop/kdc2.example.com with kvno 3, encryption type DES cbc mode
with RSA-MD5 added to keytab WRFILE:/etc/krb5/krb5.keytab.
kadmin: quitkdc2 # svcadm restart network/security/krb5_prop
この手順は、完全伝播を使用するように、Solaris 10 リリースが動作しているスレーブ KDC サーバーを再構成する方法を示しています。通常、この手順は、マスター KDC サーバーで Solaris 9 リリースまたはそれ以前のリリースのいずれかが動作している場合にのみ使用します。この場合、マスター KDC サーバーは増分伝播をサポートできないので、伝播が機能するようにスレーブを構成する必要があります。
この手順では、kdc3 という名前のスレーブ KDC を構成します。この手順では、次の構成パラメータを使用します。
レルム名 = EXAMPLE.COM
DNS ドメイン名 = example.com
マスター KDC = kdc1.example.com
スレーブ KDC = kdc2.example.com および kdc3.example.com
admin 主体 = kws/admin
オンラインヘルプ URL = http://docs.oracle.com/cd/E23824_01/html/821-1456/aadmin-23.html
始める前に
マスター KDC が構成済みである必要があります。スレーブ KDC を入れ替え可能にする手順については、「マスター KDC とスレーブ KDC の入れ替え」を参照してください。
マスター KDC 上で root 役割になる必要があります。詳細は、「割り当てられている管理権限を使用する方法」を参照してください。
マスター KDC を構成するときに作成した admin 主体名を使用して、ログインする必要があります。
kdc1 # /usr/sbin/kadmin -p kws/admin Enter password: <Type kws/admin password> kadmin:
各スレーブ用にエントリを追加する必要があります。このファイルの詳細は、krb5.conf(4) のマニュアルページを参照してください。
kdc1 # cat /etc/krb5/krb5.conf
.
.
[realms]
EXAMPLE.COM = {
kdc = kdc1.example.com
kdc = kdc2.example.com
kdc = kdc3.example.com
admin_server = kdc1.example.com
}このファイルの詳細は、kprop(1M) のマニュアルページを参照してください。
kdc1 # cat /etc/krb5/kpropd.acl host/kdc1.example.com@EXAMPLE.COM host/kdc2.example.com@EXAMPLE.COM host/kdc3.example.com@EXAMPLE.COM
この手順は、マスター KDC サーバーが、各 KDC サーバーに必要な情報を更新したため、すべてのスレーブ KDC 上で実行する必要があります。ftp などの転送メカニズムを使用して、マスター KDC から次のファイルのコピーを取得できます。
/etc/krb5/krb5.conf
/etc/krb5/kdc.conf
/etc/krb5/kpropd.acl
修正前の kadm5.acl ファイルは次のようになっています。
kdc2 # cat /etc/krb5/kadm5.acl */admin@___default_realm___ *
ファイルに kiprop のエントリがある場合は、それを削除します。
マスター KDC を構成するときに作成した admin 主体名を使用して、ログインする必要があります。
kdc2 # /usr/sbin/kadmin -p kws/admin Enter password: <Type kws/admin password> kadmin:
このエントリにより kprop などの Kerberos アプリケーションが機能します。主体のインスタンスがホスト名のときは、ネームサービス内のドメイン名が大文字であるか小文字であるかに関係なく、FQDN は小文字で指定する必要があります。
kadmin: ktadd host/kdc3.example.com
Entry for principal host/kdc3.example.com with kvno 3, encryption type AES-256 CTS mode
with 96-bit SHA-1 HMAC added to keytab WRFILE:/etc/krb5/krb5.keytab.
Entry for principal host/kdc3.example.com with kvno 3, encryption type AES-128 CTS mode
with 96-bit SHA-1 HMAC added to keytab WRFILE:/etc/krb5/krb5.keytab.
Entry for principal host/kdc3.example.com with kvno 3, encryption type Triple DES cbc
mode with HMAC/sha1 added to keytab WRFILE:/etc/krb5/krb5.keytab.
Entry for principal host/kdc3.example.com with kvno 3, encryption type ArcFour
with HMAC/md5 added to keytab WRFILE:/etc/krb5/krb5.keytab.
Entry for principal host/kdc3.example.com with kvno 3, encryption type DES cbc mode
with RSA-MD5 added to keytab WRFILE:/etc/krb5/krb5.keytab.
kadmin: kadmin: quit
各スレーブ KDC サーバーの名前を kprop_script 行の末尾に追加します。
10 3 * * * /usr/lib/krb5/kprop_script kdc2.example.com kdc3.example.com
バックアップの時間を変更する場合もあるでしょう。このエントリは、バックアップ処理を毎日午前 3:10 に開始します。
kdc3 # svcadm enable network/security/krb5_prop
データベースのバックアップコピーがすでに使用可能な場合は、別のバックアップを完成させる必要はありません。詳細は、「Kerberos データベースをスレーブ KDC に手動で伝播する方法」を参照してください。
kdc1 # /usr/lib/krb5/kprop_script kdc3.example.com Database propagation to kdc3.example.com: SUCCEEDED
kdc3 # /usr/sbin/kdb5_util stash kdb5_util: Cannot find/read stored master key while reading master key kdb5_util: Warning: proceeding without master key Enter KDC database master key: <Type the key>
Network Time Protocol (NTP) のインストールと使用は必要はありません。ただし、認証が正常終了するには、krb5.conf ファイルの libdefaults セクションに定義されているデフォルト時間内に収まるよう、すべてのクロックを調整する必要があります。NTP については、「KDC と Kerberos クライアントのクロックの同期化」を参照してください。
kdc3 # svcadm enable network/security/krb5kdc
増分伝播が構成されている場合、この手順は、スレーブ KDC 上の情報が更新されたかを確認します。
始める前に
root 役割になる必要があります。詳細は、「割り当てられている管理権限を使用する方法」を参照してください。
kdc1 # /usr/sbin/kproplog -h
kdc2 # /usr/sbin/kproplog -h
例 21-21 KDC サーバーが同期しているかを検査する
次の例は、マスター KDC サーバー上での kproplog コマンドの実行結果です。
kdc1 # /usr/sbin/kproplog -h
Kerberos update log (/var/krb5/principal.ulog)
Update log dump:
Log version #: 1
Log state: Stable
Entry block size: 2048
Number of entries: 2500
First serial #: 137966
Last serial #: 140465
First time stamp: Fri Nov 28 00:59:27 2004
Last time stamp: Fri Nov 28 01:06:13 2004
次の例は、スレーブ KDC サーバー上での kproplog コマンドの実行結果です。
kdc2 # /usr/sbin/kproplog -h
Kerberos update log (/var/krb5/principal.ulog)
Update log dump:
Log version #: 1
Log state: Stable
Entry block size: 2048
Number of entries: 0
First serial #: None
Last serial #: 140465
First time stamp: None
Last time stamp: Fri Nov 28 01:06:13 2004
最終シリアル番号と最終時間表示が同じであることに注意してください。これは、スレーブがマスター KDC サーバーと同期していることを示しています。
スレーブ KDC サーバーの出力で、スレーブ KDC サーバーの更新ログに更新エントリがないことに注意してください。エントリがないのは、スレーブ KDC サーバーはマスター KDC サーバーとは異なり、一連の更新を保持しないためです。また、最初のシリアル番号と最初の時間表示は関連情報でないため、KDC スレーブサーバーはそれらの情報を取り込みません。
この手順では、kprop コマンドを使用して、Kerberos データベースを伝播します。定期的に実行する cron ジョブ以外に、スレーブ KDC とマスター KDC を同期化する必要がある場合は、この手順を行います。kprop_script と異なり、kprop を使用した場合は、現在のデータベースバックアップのみを伝播できますが、伝播する前に Kerberos データベースの新しいバックアップは作成されません。
注 - 増分伝播を使用する場合は、この手順を使用しないでください。
始める前に
root 役割になる必要があります。詳細は、「割り当てられている管理権限を使用する方法」を参照してください。
# /usr/sbin/kdb5_util dump /var/krb5/slave_datatrans
# /usr/lib/krb5/kprop -f /var/krb5/slave_datatrans slave-KDC
例 21-22 kprop_script を使用してスレーブ KDC に Kerberos データベースを手動で伝播する
定期的に実行する cron ジョブ以外に、データベースをバックアップし、それをスレーブ KDC に伝播する場合は、次のように kprop_script コマンドを使用することもできます。
# /usr/lib/krb5/kprop_script slave-KDC
ほとんどの場合、マスター KDC は、Kerberos データベースをスレーブ KDC に伝播するときにだけ使用されます。使用するサイトに複数のスレーブ KDC が存在する場合は、伝播処理の負荷を分散させることもできます。この概念は、「並列伝播」と呼ばれます。
注 - 増分伝播を使用する場合は、この手順を使用しないでください。
並列伝播を利用すると、複数のスレーブ KDC 間でマスター KDC の伝播処理を分散できます。処理を分散すると、伝播をより早く実行でき、マスター KDC の作業を軽減することができます。
たとえば、使用するサイトに 1 つのマスター KDC と 6 つのスレーブ KDC があるとします (図 21-2 を参照)。slave-1 から slave-3 で 1 つの論理グループを構成し、slave-4 から slave-6 で別の論理グループを構成しています。並列伝播を設定するには、マスター KDC がデータベースを slave-1 と slave-4 に伝播するようにします。これらのスレーブ KDC がグループ内のスレーブ KDC にデータベースを伝播するようにします。
図 21-2 並列伝播の構成例
ここでは、並列伝播の詳細な手順は説明しませんが、並列伝播を有効にする構成手順の概要を示します。手順は次のとおりです。
マスター KDC 上で、cron ジョブ内の kprop_script エントリを変更して、次の伝播先のスレーブ KDC ( 伝播スレーブ) だけを引数に指定します。
伝播スレーブごとに、kprop_script エントリをその cron ジョブに追加し、伝播先のスレーブを引数に指定します。並列伝播を正しく行うには、伝播スレーブが新しい Kerberos データベースから伝播されたあとに、cron ジョブが実行されるように設定する必要があります。
注 - 伝播スレーブにかかる伝播時間は、ネットワークの帯域幅や Kerberos データベースのサイズなどの要因によって異なります。
スレーブ KDC ごとに、伝播に必要なアクセス権を設定します。伝播元の KDC のホスト主体名を各スレーブ KDC の kpropd.acl ファイルに追加します。
例 21-23 並列伝播の設定
図 21-2 の例を使用すると、マスター KDC の kprop_script エントリは次のようになります。
0 3 * * * /usr/lib/krb5/kprop_script slave-1.example.com slave-4.example.com
slave-1 の kprop_script エントリは、次のようになります。
0 4 * * * /usr/lib/krb5/kprop_script slave-2.example.com slave-3.example.com
このスレーブの伝播は、マスターからの伝播が完了してから 1 時間後に開始します。
伝播スレーブの kpropd.acl ファイルには、次のエントリが含まれます。
host/master.example.com@EXAMPLE.COM
slave-1 から伝播されるスレーブ KDC の kpropd.acl ファイルには、次のエントリが含まれます。
host/slave-1.example.com@EXAMPLE.COM
「stash ファイル」には、Kerberos データベースのマスター鍵が含まれます。このファイルは、Kerberos データベースを作成すると自動的に作成されます。stash ファイルが壊れた場合は、kdb5_util ユーティリティーの stash コマンドを使用して、置き換えることができます。kdb5_util の destroy コマンドを使用して Kerberos データベースを削除したあとのみ、stash ファイルを削除する必要があります。データベースを削除しても、stash ファイルは自動的に削除されないため、クリーンアップを完了するには、stash ファイルを削除する必要があります。
始める前に
root 役割になる必要があります。詳細は、「割り当てられている管理権限を使用する方法」を参照してください。
# rm stash-file
この例では、stash-file は stash ファイルのパスを示します。デフォルトでは、stash ファイルは /var/krb5/.k5.realm にあります。
注 - stash ファイルを再作成する場合は、kdb5_util コマンドの -f オプションを使用します。
始める前に
root 役割になる必要があります。詳細は、「割り当てられている管理権限を使用する方法」を参照してください。
このコマンドでは、ランダムに生成された新しいマスター鍵を追加します。-s オプションは、新しいマスター鍵がデフォルトのキータブに格納されるよう要求します。
# kdb5_util add_mkey -s Creating new master key for master key principal 'K/M@EXAMPLE.COM' You will be prompted for a new database Master Password. It is important that you NOT FORGET this password. Enter KDC database master key: <Type the password> Re-enter KDC database master key to verify: <Type it again>
# kdb5_util list_mkeys Master keys for Principal: K/M@EXAMPLE.COM KNVO: 2, Enctype: AES-128 CTS mode with 96-bit SHA-1 HMAC, No activate time set KNVO: 1, Enctype: DES cbc mode with RSA-MD5, Active on: Wed Dec 31 18:00:00 CST 2001 *
この出力内のアスタリスクは、現在アクティブになっているマスター鍵を特定します。
# date Fri Jul 1 17:57:00 CDT 2011 # kdb5_util use_mkey 2 'now+2days' # kdb5_util list_mkeys Master keys for Principal: K/M@EXAMPLE.COM KNVO: 2, Enctype: AES-128 CTS mode with 96-bit SHA-1 HMAC, Active on: Sun Jul 03 17:57:15 CDT 2011 KNVO: 1, Enctype: DES cbc mode with RSA-MD5, Active on: Wed Dec 31 18:00:00 CST 2001 *
この例では、新しいマスター鍵がすべての KDC に伝播される時間を見越して、日付は 2 日後に設定されています。この日付は、環境に合わせて適宜調整してください。
# kadmin.local -q 'getprinc jimf' |egrep 'Principal|MKey' Authenticating as principal root/admin@EXAMPLE.COM with password. Principal: jimf@EXAMPLE.COM MKey: vno 2
この例では、MKey: vno 2 は、新しく作成されたマスター鍵 2 によって主体の秘密鍵が保護されていることを示しています。
コマンドの終わりにパターンの引数を追加した場合は、そのパターンに一致する主体が更新されます。更新される主体を特定するには、このコマンドに -n オプションを追加します。
# kdb5_util update_princ_encryption -f -v Principals whose keys WOULD BE re-encrypted to master key vno 2: updating: host/kdc1.example.com@EXAMPLE.COM skipping: jimf@EXAMPLE.COM updating: kadmin/changepw@EXAMPLE.COM updating: kadmin/history@EXAMPLE.COM updating: kdc/admin@EXAMPLE.COM updating: host/kdc2.example.com@EXAMPLE.COM 6 principals processed: 5 updated, 1 already current
主体の秘密鍵の保護にマスター鍵が使用されなくなった場合は、マスター鍵主体からそれを削除できます。いずれかの主体で引き続き使用されている鍵はこのコマンドで削除されません。適切なマスター鍵が削除されることを確認するには、このコマンドに -n オプションを追加します。
# kdb5_util purge_mkeys -f -v Purging the follwing master key(s) from K/M@EXAMPLE.COM: KNVO: 1 1 key(s) purged.
# kdb5_util list_mkeys Master keys for Principal: K/M@EXAMPLE.COM KNVO: 2, Enctype: AES-128 CTS mode with 96-bit SHA-1 HMAC, Active on: Sun Jul 03 17:57:15 CDT 2011 *
# kdb5_util stash Using existing stashed keys to update stash file.
# klist -kt /var/krb5/.k5.EXAMPLE.COM Keytab name: FILE:.k5.EXAMPLE.COM KVNO Timestamp Principal ---- ---------------- --------------------------------------------------------- 2 05/07/2011 15:08 K/M@EXAMPLE.COM
|