この手順では、kinit ユーティリティーを使用して、Identity Management (IdM) 環境を手動で認証する方法を説明します。kinit ユーティリティーは、IdM ユーザーの代わりに Kerberos の TGT (Ticket-Granting Ticket) を取得して、キャッシュに格納します。

本セクションでは、アクティブなユーザーの Kerberos チケットが含まれている認証情報キャッシュを削除する方法を説明します。

本セクションでは、Identity Management (IdM) ユーザーが自身の Kerberos 認証情報を使用して、外部システムから IdM にログインするように外部システムを設定する方法を説明します。

外部システムの Kerberos 認証を有効にすることは、インフラストラクチャーに、複数のレルムまたは重複ドメインが含まれている場合に特に便利です。また、ipa-client-install を実行してシステムを IdM ドメインに登録していない場合にも便利です。

IdM ドメインのメンバーではないシステムから IdM への Kerberos 認証を有効にするには、IdM 固有の Kerberos 設定ファイルを外部システムに定義します。

外部システムのユーザーが、kinit ユーティリティーを使用して IdM サーバーで認証できるようになりました。

IdM サーバーに設定されている IdM サービスの状態を表示するには、次のコマンドを実行します。

[root@server ~]# ipactl status
Directory Service: RUNNING
krb5kdc Service: RUNNING
kadmin Service: RUNNING
named Service: RUNNING
httpd Service: RUNNING
ntpd Service: RUNNING
pki-tomcatd Service: RUNNING
smb Service: RUNNING
winbind Service: RUNNING
ipa-otpd Service: RUNNING
ipa-dnskeysyncd Service: RUNNING
ipa: INFO: The ipactl command was successful

この出力は、以下を示しています。

サーバーの ipactl status コマンドの出力は、IdM 設定により異なります。たとえば、IdM デプロイメントに DNS サーバーが含まれていない場合は、named サービスが一覧に表示されません。

サーバー全体、または個々のサービスのみを起動または停止できます。

IdM サーバー全体を起動、停止、または再起動する場合は、以下を参照してください。

個々の IdM サービスを起動、停止、または再起動する場合は、以下を参照してください。

ipactl ユーティリティーを使用して、IdM サーバー全体と、インストールしたサービスをすべて停止、起動 (開始)、または再起動 (再開) します。ipactl ユーティリティーを使用して、すべてのサービスを適切な順番で停止、開始、または再開します。有効な Kerberos チケットがなくても、ipactl コマンドは実行できます。

ipactl コマンド

IdM サーバー全体を起動するには、次のコマンドを実行します。

# ipactl start

IdM サーバー全体を停止するには、次のコマンドを実行します。

# ipactl stop

IdM サーバー全体を再起動するには、次のコマンドを実行します。

# ipactl restart

IdM を構成するすべてのサービスのステータスを表示するには、次のコマンドを実行します。

# ipactl status

IdM 設定ファイルを手動で変更することは推奨されていません。ただし、特定の状況では、管理者が特定のサービスを手動で設定する必要があります。このような場合は、systemctl ユーティリティーを使用して、個々の IdM サービスを停止、開始、または再開します。

たとえば、その他の IdM サービスを変更せずに、Directory Server の挙動をカスタマイズした場合は、systemctl を使用します。

# systemctl restart dirsrv@REALM-NAME.service

また、Active Directory と IdM の信頼を最初にデプロイする場合は、/etc/sssd/sssd.conf ファイルを変更して、以下を追加します。

/etc/sssd/sssd.conf ファイルに加えた変更を適用する場合は、次のコマンドを実行します。

# systemctl restart sssd.service

System Security Services Daemon (SSSD) は、設定を自動的に再読み込みまたは再適用しないため、systemctl restart sssd.service を実行する必要があります。

変更が、IdM の ID 範囲に影響を及ぼす場合は、サーバーを完全に再起動することが推奨されます。

便利な systemctl コマンド

特定の IdM サービスを開始するには、次のコマンドを実行します。

# systemctl start name.service

特定の IdM サービスを停止するには、次のコマンドを実行します。

# systemctl stop name.service

特定の IdM サービスを再開するには、次のコマンドを実行します。

# systemctl restart name.service

特定の IdM サービスの状態を表示するには、次のコマンドを実行します。

# systemctl status name.service

IPA コマンドラインインターフェース (CLI) は、Identity Management (IdM) の管理向けの基本的なコマンドラインインターフェースです。

これは、新しいユーザーを追加するために、ipa user-add コマンドなど、IdM の管理に使用する多数のサブコマンドに対応します。

IPA CLI では以下を行うことができます。

IPA ヘルプは、IdM サーバー用の組み込みドキュメントシステムです。

IPA コマンドラインインターフェース (CLI) は、読み込んだ IdM プラグインモジュールから、利用可能なヘルプトピックを生成します。IPA ヘルプを正常に実行する必要がある場合は、以下が必要になります。

オプションを指定せずに ipa help コマンドを実行すると、基本的なヘルプの使用方法と、一般的なコマンドの例が表示されます。

オプションを使用したヘルプの実行には、以下の構文があります。

$ ipa help [TOPIC | COMMAND | topics | commands]

次の手順は、コマンドラインインターフェースで IPA ヘルプの使用方法を説明します。

IPA CLI は、ユーザー トピックのヘルプページを表示します。概要を読むと、トピックのコマンドを使用するパターンに関して、多くの例を確認できます。

次の手順は、コマンドラインインターフェースで IPA ヘルプコマンドの作成方法を説明します。

IPA CLI は、以下のタイプのコマンドを区別します。

IPA コマンドの構造を使用すると、さまざまなタイプのオブジェクトを管理できます。以下に例を示します。

その他にも多数あります。

このようなほとんどのオブジェクトでは、IPA CLI に、以下を行うためのコマンドが含まれます。

コマンドの構造は次のとおりです。

ipa user-add、ipa user-mod、ipa user-del、ipa user-find、ipa user-show

ipa host-add、ipa host-mod、ipa host-del、ipa host-find、ipa host-show

ipa dnsrecord-add、ipa dnsrecord-mod、ipa dnsrecord-del、ipa dnsrecord-find、ipa dnrecord-show

ipa user-add [options] でユーザーを作成できます。[options] は任意です。ipa user-add コマンドのみを使用する場合、スクリプトは、詳細を 1 つずつ要求します。

既存のオブジェクトを変更するには、オブジェクトを定義する必要があります。そのため、コマンドには、オブジェクトも含まれます (ipa user-mod USER_NAME [options])。

ここでは、コマンドラインを使用して、新しいユーザーを Identity Management データベースに追加する方法を説明します。前提条件は以下のようになります。

ユーザー名を追加したら、ユーザーアカウントが IdM データベースに追加され、IPA CLI が以下のログを出力します。

----------------------
Added user "euser"
----------------------
User login: euser
First name: Example
Last name: User
Full name: Example User
Display name: Example User
Initials: EU
Home directory: /home/euser
GECOS: Example User
Login shell: /bin/sh
Principal name: euser@IDM.EXAMPLE.COM
Principal alias: euser@IDM.EXAMPLE.COM
Email address: euser@idm.example.com
UID: 427200006
GID: 427200006
Password: False
Member of groups: ipausers
Kerberos keys available: False

ここに表示されるように、ユーザーパスワードは、ユーザーアカウントに設定されていません。パスワードも追加するには、以下の構文で ipa user-add コマンドを使用します。

$ ipa user-add --first=Example --last=User --password

次に、IPA CLI はユーザー名とパスワードの追加または確認を要求します。

ユーザーがすでに作成されている場合は、ipa user-mod コマンドでパスワードだけを追加できます。

$ ipa help user-add

各ユーザーアカウントの多くのパラメーターを変更できます。たとえば、新しいパスワードをユーザーに追加できます。

基本的なコマンド構文は user-add 構文とは異なります。たとえば、パスワードを追加するなど、変更を実行する既存のユーザーアカウントを定義する必要があるためです。

ユーザー名を追加したら、ユーザーアカウントが IdM データベースに追加され、IPA CLI が以下のログを出力します。

----------------------
Modified user "euser"
----------------------
User login: euser
First name: Example
Last name: User
Home directory: /home/euser
Principal name: euser@IDM.EXAMPLE.COM
Principal alias: euser@IDM.EXAMPLE.COM
Email address: euser@idm.example.com
UID: 427200006
GID: 427200006
Password: True
Member of groups: ipausers
Kerberos keys available: True

これでユーザーパスワードがアカウントに対して設定され、ユーザーが IdM にログインできます。

$ ipa help user-mod

Identity Management (IdM) は、多値属性の値をリスト形式で保存します。

IdM は、多値リストを提供する次の方法に対応します。

上記の例では、パーミッションをオブジェクトに追加する permission-add コマンドを表示します。この例では、このオブジェクトは記載されていません。…​ の代わりに、パーミッションを追加するオブジェクトを追加する必要があります。

このような多値属性をコマンド行から更新すると、IdM は、前の値リストを新しいリストで完全に上書きします。したがって、多値属性を更新するときは、追加する 1 つの値だけでなく、新しいリスト全体を指定する必要があります。

上記のコマンドでは、パーミッションのリストには、読み取り、書き込み、および削除が含まれます。permission-mod コマンドでリストを更新する場合は、すべての値を追加する必要があります。すべての値を追加しないと、追加されていない値は削除されます。

例 1: - ipa permission-mod コマンドは、以前に追加した権限をすべて更新します。

$ ipa permission-mod --right=read --right=write --right=delete ...

または

$ ipa permission-mod --right={read,write,delete} ...

例 2  - ipa permission-mod コマンドは、コマンドに含まれないため、--right=delete 引数を削除します。

$ ipa permission-mod --right=read --right=write ...

または

$ ipa permission-mod --right={read,write} ...

特殊文字を含むコマンドライン引数を ipa コマンドに渡す場合は、この文字をバックスラッシュ (\) でエスケープします。たとえば、一般的な特殊文字には、山かっこ (< および >)、アンパサンド (&)、アスタリスク (*)、または垂直バー (|) があります。

たとえば、アスタリスク (*) をエスケープするには、次のコマンドを実行します。

$ ipa certprofile-show certificate_profile --out=exported\*profile.cfg

シェルが特殊文字を正しく解析できないため、エスケープしていない特殊文字をコマンドに含めると、予想通りに機能しなくなります。

特定のタイプの IdM エントリーを検索するのに役に立つ ipa *-find コマンドを説明します。

すべての find コマンドを表示するには、次の ipa help コマンドを使用します。

$ ipa help commands | grep find

特定のユーザーが IdM データベースに含まれているかどうかの確認が必要になる場合があります。次のコマンドを使用すると、ユーザーを一覧表示できます。

$ ipa user-find

指定の属性にキーワードが含まれるユーザーグループの一覧を表示するには、次のコマンドを実行します。

$ ipa group-find keyword

たとえば、ipa group-find admin コマンドは、名前または説明に文字列 admin が含まれるグループの一覧を表示します。

----------------
3 groups matched
----------------
   Group name: admins
   Description: Account administrators group
   GID: 427200002

   Group name: editors
   Description: Limited admins who can edit other users
   GID: 427200002

   Group name: trust admins
   Description: Trusts administrators group

ユーザーグループの検索の際には、特定のユーザーを含むグループに検索結果を絞り込むことも可能です。

$ ipa group-find --user=user_name

また、特定のユーザーを含まないグループを検索するには、次のコマンドを実行します。

$ ipa group-find --no-user=user_name

ipa *-show コマンドを使用して、特定の IdM エントリーの詳細を表示します。

IdM ユーザーの一覧を要求するなど、一部のクエリーでは、エントリー数が大量に返される場合があります。この検索操作を調整して、ipa user-find などの ipa *-find コマンドの実行時や、Web UI で対応する一覧を表示する際に、全体的なサーバーのパフォーマンスを向上できます。

この値が -1 に設定されていると、IdM は、検索時に制限を適用しません。

$ ipa user-find --sizelimit=200 --timelimit=120

IdM (Identity Management) Web UI は、IdM コマンドラインツールのグラフィカルな代替手段である、IdM 管理用の Web アプリケーションです。

IdM Web UI には、以下のユーザーとしてアクセスできます。

IdM (Identity Management) では、以下のブラウザーを使用して、Web UI に接続できます。

次の手順では、パスワードを使用して、IdM (Identity Management) Web UI に最初にログインする方法を説明します。

最初のログイン後に、IdM サーバーを認証するように設定できます。

ログインに成功したら、IdM サーバーの設定を開始できます。

Identity Management (IdM) は、シングルサインオンに対応する Kerberos プロトコルを使用します。シングルサインオン認証により、ユーザーが正しいユーザー名およびパスワードを一度入力すれば、再度システムに認証情報を求められることなく、Identity Management サービスにアクセスできます。

DNS および証明書の設定が適切に設定されている場合は、インストール直後に、IdM サーバーが Kerberos 認証を提供します。詳細は『Identity Management のインストール』を参照してください。

ホストで Kerberos 認証を使用するには、以下をインストールします。

この手順では、kinit ユーティリティーを使用して、Identity Management (IdM) 環境を手動で認証する方法を説明します。kinit ユーティリティーは、IdM ユーザーの代わりに Kerberos の TGT (Ticket-Granting Ticket) を取得して、キャッシュに格納します。

Kerberos チケットによる認証を有効にするには、ブラウザーの設定が必要になることもあります。

以下の手順は、IdM ドメインにアクセスする Kerberos ネゴシエーションに対応するのに役に立ちます。

Kerberos に対応する方法はブラウザーによって異なるため、異なる設定が必要です。IdM Web UI には、次のブラウザーに関するガイドラインが含まれています。

設定が完了したら、IdM Web UI に戻り、ログイン をクリックします。

この手順では、Kerberos の TGT (ticket-granting ticket) を使用して、IdM Web UI にログインする方法を説明します。

TGT は、事前定義された時間で有効期限が切れます。デフォルトの時間間隔は 24 時間で、IdM Web UI でそれを変更できます。

期限が切れたら、チケットを更新する必要があります。

本セクションでは、Identity Management (IdM) ユーザーが自身の Kerberos 認証情報を使用して、外部システムから IdM にログインするように外部システムを設定する方法を説明します。

外部システムの Kerberos 認証を有効にすることは、インフラストラクチャーに、複数のレルムまたは重複ドメインが含まれている場合に特に便利です。また、ipa-client-install を実行してシステムを IdM ドメインに登録していない場合にも便利です。

IdM ドメインのメンバーではないシステムから IdM への Kerberos 認証を有効にするには、IdM 固有の Kerberos 設定ファイルを外部システムに定義します。

外部システムのユーザーが、kinit ユーティリティーを使用して IdM サーバーで認証できるようになりました。

Active Directory ユーザーに対して Web UI ログインを有効にするには、デフォルトの信頼ビューで、Active Directory の各ユーザーに対して ID のオーバーライドを定義します。以下に例を示します。

[admin@server ~]$ ipa idoverrideuser-add 'Default Trust View' ad_user@ad.example.com

ワンタイムパスワードにより、認証セキュリティーに関する手順が追加されます。認証では、自身のパスワードと、自動生成されたワンタイムパスワードが使用されます。

ワンタイムパスワードを生成するには、ハードウェアまたはソフトウェアのトークンを使用できます。IdM は、ソフトウェアトークンとハードウェアトークンの両方をサポートします。

Identity Management は、以下にある、2 つの標準 OTP メカニズムに対応しています。

The IdM Web UI allows you to configure hardware or software device to generate one-time passwords.

ワンタイムパスワードは、ログインダイアログの専用フィールドで、通常のパスワードの直後に入力されます。

ユーザー設定で、OTP 認証を有効にできるのは管理者だけです。

この時点で、OTP 認証は IdM サーバーで有効になります。

ユーザー (1 人または複数) が、新しいトークン ID を自身のユーザーアカウントに割り当てる必要があります。

次のセクションは、IdM Web UI およびソフトウェアトークンジェネレーターに、トークンを追加するのに役立ちます。

これで、ワンタイムパスワードを生成して、IdM Web UI にログインできるようになりました。

この手順では、ワンタイムパスワード (OTP) を使用した IdM Web UI への最初のログインを説明します。

ログインが成功すると、IdM Web UI が表示されます。

OTP (ワンタイムパスワード) でのログインに失敗した場合、OTP トークンは正しく同期しません。

以下のテキストは、トークンの再同期を説明します。

同期に成功したら、IdM サーバーにログインできます。

Identity Management の管理者は、ユーザが次回ログインする時にパスワードを変更するように強制できます。これを設定すると、パスワードを変更しないと IdM Web UI にログインできなくなります。

パスワードの有効期限は、Web UI に初めてログインしたときに発生する可能性があります。

有効期限のパスワードのダイアログが表示されたら、手順の指示に従ってください。

パスワード変更が成功すると、通常のログインダイアログが表示されます。新しいパスワードでログインします。

IdM (Identity Management) は、以下のユーザーアカウントの状態に対応します。

IdM データベースからユーザーエントリーを永続的に削除できます。

新規管理者は、デフォルトの管理ユーザーなど、管理者権限を持つユーザーのみが作成できます。すべての管理者アカウントを誤って削除した場合は、Directory Manager が、Directory Server に新しい管理者を手動で作成する必要があります。

通常は、新入社員が働き始める前に、新しいユーザーアカウントを作成する必要があります。このようなステージアカウントにはアクセスできず、後でアクティベートする必要があります。

この時点では、ステージユーザー テーブルでユーザーアカウントを確認できます。

ユーザーが IdM にログインし、ユーザーを IdM グループに追加する前に、ステージユーザーアカウントをアクティベートする必要があります。本セクションでは、ステージユーザーアカウントをアクティベートする方法を説明します。

アクティベーションに成功したら、IdM Web UI により、ユーザーがアクティベートされ、ユーザーアカウントが アクティブユーザー に移動したことを示す緑色の確認が表示されます。このアカウントはアクティブで、ユーザーは IdM ドメインと IdM Web UI に対して認証できます。ユーザーは、初回ログイン時にパスワードを変更するように求められます。

アクティブなユーザーアカウントを無効にできます。ユーザーアカウントを無効にすると、ユーザーアカウントはアカウントを非アクティブにできるため、そのユーザーアカウントを使用して Kerberos などの IdM サービスを認証および使用したり、タスクを実行することができません。

無効にしたユーザーアカウントはそのまま IdM に残り、関連する情報は何も変更しません。保存済みユーザーアカウントとは異なり、無効にしたユーザーアカウントはアクティブな状態のままとなり、ユーザーグループのメンバーになります。

無効化の手順に成功した場合は、アクティブユーザー テーブルの状態の列で確認できます。

IdM を使用して、無効にしたアクティブなユーザーアカウントを再度有効にできます。ユーザーアカウントを有効にすると、無効になったアカウントが有効になります。

変更に成功すると、アクティブユーザー テーブルの状態の列で確認できます。

ユーザーアカウントを保存すると、アクティブユーザー タブからアカウントを削除した状態で、IdM でアカウントを維持できます。

従業員が退職する場合は、ユーザーアカウントを保存します。ユーザーアカウントを数週間または数か月間 (たとえば育児休暇) 無効にする場合は、ユーザーアカウントを無効にします。詳細は「Web UI でユーザーアカウントの無効化」を参照してください。保存済みアカウントはアクティブではないため、そのユーザーが内部ネットワークにはアクセスできないものの、すべてのデータが含まれる状態でデータベース内に残ります。

復元したアカウントをアクティブモードに戻すことができます。

これにより、そのユーザーアカウントは、保存済みユーザー に移動します。

保存済みユーザーを復元する必要がある場合は、「IdM Web UI でユーザーの復元」を参照してください。

IdM (Identity Management) を使用すると、保存済みユーザーアカウントをアクティブな状態で復元できます。

IdM Web UI は、緑色の確認を表示し、ユーザーアカウントを アクティブユーザー タブに移動します。

ユーザーの削除は元に戻せない操作であり、グループメンバーシップやパスワードなど、ユーザーアカウントが IdM データベースから完全に削除されます。ユーザーの外部設定 (システムアカウントやホームディレクトリーなど) は削除されませんが、IdM からはアクセスできなくなります。

以下を削除できます。

以下の手順では、アクティブなユーザーの削除を説明します。以下のタブでも同じようにユーザーアカウントを削除できます。

ユーザーアカウントが、IdM から完全に削除されました。

IdM (Identity Management) は、以下のユーザーアカウントの状態に対応します。

IdM データベースからユーザーエントリーを永続的に削除できます。

新規管理者は、デフォルトの管理ユーザーなど、管理者権限を持つユーザーのみが作成できます。すべての管理者アカウントを誤って削除した場合は、Directory Manager が、Directory Server に新しい管理者を手動で作成する必要があります。

以下のようにユーザーを追加できます。

以下の手順では、ipa user-add コマンドを使用して、アクティブなユーザーを IdM サーバーに追加する方法を説明します。

同様に、ipa stageuser-add コマンドでステージユーザーアカウントを作成できます。

IdM ユーザーアカウントを一覧表示して、新規ユーザーアカウントが正常に作成されたかどうかを確認できます。

$ ipa $ ipa user-find

このコマンドは、すべてのユーザーアカウントと、その詳細を一覧で表示します。

ステージからアクティブに移行してユーザーアカウントをアクティベートするには、ipa stageuser-activate コマンドを使用します。

IdM ユーザーアカウントを一覧表示して、新規ユーザーアカウントが正常に作成されたかどうかを確認できます。

$ ipa $ ipa user-find

このコマンドは、すべてのユーザーアカウントと、その詳細を一覧で表示します。

ユーザーアカウントを保存するには、ipa user-del コマンドまたは ipa stageuser-del コマンドを使用します。

IdM (Identity Management) を使用すると、ユーザーを永続的に削除できます。以下を削除できます。

複数のユーザーを削除するときは、--continue オプションを使用して、エラーに関係なくコマンドを続行します。成功および失敗した操作の概要は、コマンドが完了したときに標準出力ストリーム (stdout) に出力されます。

$ ipa user-del --continue user1 user2 user3

--continue を使用しないと、コマンドはエラーが発生するまでユーザーの削除を続行し、停止と終了を行います。

ユーザーアカウントは、IdM から永続的に削除されました。

保存済みユーザーは、以下のステータスに復元できます。

ユーザーアカウントを復元しても、そのアカウントの以前の属性がすべて復元されるわけではありません。たとえば、ユーザーのパスワードが復元されず、再設定する必要があります。

IdM ユーザーアカウントを一覧表示して、新規ユーザーアカウントが正常に作成されたかどうかを確認できます。

$ ipa $ ipa user-find

このコマンドは、すべてのユーザーアカウントと、その詳細を一覧で表示します。

Identity Management (IdM) は、以下の ID を管理します。

ホストはマシンを表します。ホストには、IdM LDAP に IdM ID となるエントリーがあります。これは IdM サーバーの 389 Directory Server のインスタンスです。

IdM LDAP のホストエントリーは、その他のホストとドメイン内のサービスとの関係を確立するために使用されます。この関係では、ドメイン内ホストの認可および制御の 委譲 が不可欠な要素です。ホストは、ホストベースのアクセス制御 (HBAC) ルールで使用できます。

IdM ドメインは、共通の ID 情報、共通ポリシー、および共有サービスを使用して、マシン間で共通性を確立します。ドメインのクライアントとしてのドメイン機能に属するマシンです。これは、ドメインが提供するサービスを使用することを意味します。IdM ドメインは、マシン専用の 3 つの主なサービスを提供します。

IdM のホストは、それらで実行しているサービスと密接に接続されています。

本セクションでは、ホストを IdM クライアントとして登録し、登録中および登録後に何が起こるかを説明します。本セクションでは、IdM ホストの登録と、IdM ユーザーの登録を比較します。また、本セクションでは、ホストで利用可能な代替タイプの認証も概説します。

ホストの登録は、以下のように構成されます。

2 つのアクションは、個別に実行することも一緒に実行することもできます。

個別に実行すると、異なるレベルの特権を持つ 2 人のユーザー間で 2 つのタスクを分割できます。これは、一括デプロイメントに役立ちます。

ipa-client-install コマンドは、2 つのアクションを一緒に実行できます。コマンドは、そのエントリーがまだ存在していない場合は IdM LDAP にホストエントリーを作成し、そのホストに Kerberos サービスと SSSD サービスの両方を設定します。このコマンドにより、ホストが IdM ドメイン内に移動し、接続先の IdM サーバーを識別できるようになります。IdM が管理する DNS ゾーンにホストが属する場合は、ipa-client-install でホストに DNS レコードも追加します。コマンドはクライアントで実行する必要があります。

このセクションでは、ホストの登録と有効化に関連する最も一般的な操作一覧を紹介し、前提条件、コンテキスト、および操作を実行した結果を説明します。

本セクションでは、Identity Management (IdM) のホストエントリーがどのようなもので、どのような属性を含めることができるかを説明します。

LDAP ホストエントリーは、IdM 内のクライアントに関するすべての関連情報が含まれます。

本セクションでは、コマンドラインインターフェース (CLI) を使用して Identity Management (IdM) にホストエントリーを追加する方法を説明します。

ホストエントリーは、host-add コマンドを使用して作成されます。このコマンドは、ホストエントリーを IdM Directory Server に追加します。CLI で ipa help host を入力し、man ページの ipa host で、host-add で利用可能なオプションの完全一覧を取得します。

ホストを IdM に追加する場合は、いくつかのシナリオがあります。

ここでは、Identity Management クライアントシステムのホスト名を変更する方法を説明します。

Identity Management クライアントの名前を変更するには、以下を行う必要があります。

[root@client]# hostnamectl set-hostname new-client-name.example.com

このセクションでは、Identity Management (IdM) でホストを無効にして再度有効にする方法を説明します。

$ kinit admin
$ ipa host-disable client.example.com

$  ipa-getkeytab -s server.example.com -p host/client.example.com -k /etc/krb5.keytab -D "cn=directory manager" -w password

Identity Management (IdM) は、以下の ID を管理します。

ホストはマシンを表します。ホストには、IdM LDAP に IdM ID となるエントリーがあります。これは IdM サーバーの 389 Directory Server のインスタンスです。

IdM LDAP のホストエントリーは、その他のホストとドメイン内のサービスとの関係を確立するために使用されます。この関係では、ドメイン内ホストの認可および制御の 委譲 が不可欠な要素です。ホストは、ホストベースのアクセス制御 (HBAC) ルールで使用できます。

IdM ドメインは、共通の ID 情報、共通ポリシー、および共有サービスを使用して、マシン間で共通性を確立します。ドメインのクライアントとしてのドメイン機能に属するマシンです。これは、ドメインが提供するサービスを使用することを意味します。IdM ドメインは、マシン専用の 3 つの主なサービスを提供します。

IdM のホストは、それらで実行しているサービスと密接に接続されています。

本セクションでは、ホストを IdM クライアントとして登録し、登録中および登録後に何が起こるかを説明します。本セクションでは、IdM ホストの登録と、IdM ユーザーの登録を比較します。また、本セクションでは、ホストで利用可能な代替タイプの認証も概説します。

ホストの登録は、以下のように構成されます。

2 つのアクションは、個別に実行することも一緒に実行することもできます。

個別に実行すると、異なるレベルの特権を持つ 2 人のユーザー間で 2 つのタスクを分割できます。これは、一括デプロイメントに役立ちます。

ipa-client-install コマンドは、2 つのアクションを一緒に実行できます。コマンドは、そのエントリーがまだ存在していない場合は IdM LDAP にホストエントリーを作成し、そのホストに Kerberos サービスと SSSD サービスの両方を設定します。このコマンドにより、ホストが IdM ドメイン内に移動し、接続先の IdM サーバーを識別できるようになります。IdM が管理する DNS ゾーンにホストが属する場合は、ipa-client-install でホストに DNS レコードも追加します。コマンドはクライアントで実行する必要があります。

本セクションでは、Identity Management (IdM) のホストエントリーがどのようなもので、どのような属性を含めることができるかを説明します。

LDAP ホストエントリーは、IdM 内のクライアントに関するすべての関連情報が含まれます。

認証局は信頼の階層で機能します。内部認証局 (CA) がある IdM 環境では、CA が署名している正しい証明書を、すべての IdM ホスト、ユーザー、およびサービスが信頼します。このルート CA とは別に、IdM は、ルート CA から証明書に署名する権限を付与されたサブ CA にも対応します。多くの場合、そのようなサブ CA が署名できる証明書は、特定の種類の証明書 (たとえば VPN 証明書) です。

証明書の観点からは、自己署名 IdM CA と、外部署名の間に違いがありません。

CA のロールは以下ようになります。

証明書は、Kerberos チケットが実行したのと同様の機能を実行します。Kerberos は、セキュアでないネットワーク上で通信するノードが、安全な方法で互いに ID を証明できるように、チケットベースで機能するコンピューターネットワーク認証プロトコルです。以下の表では、Kerberos および X.509 の証明書を比較します。

デフォルトでは、Identity Management の Kerberos は、通信相手の ID のみを保証します。

IdM でユーザーを認証する証明書を使用する利点は次のとおりです。

IdM のユーザーを認証する証明書を使用する問題点は次のとおりです。

IdM におけるスマートカード認証を含む証明書認証は、ユーザーが提示する証明書と、ユーザーの IdM プロファイルに保存されている証明書または証明書データを比較することによって進められます。

システムの設定

IdM プロファイルに格納されるものは証明書のみで、対応する秘密鍵ではありません。また、認証中に、ユーザーが、対応する秘密鍵の所有していることを表示する必要があります。ユーザーは、証明書と秘密鍵の両方が含まれる PKCS #12 ファイル、またはこれら 2 つのファイル (証明書が含まれるファイルと、秘密鍵が含まれているファイル) のいずれかを提示して行います。

したがって、ユーザープロファイルに証明書を読み込むなどのプロセスでは、秘密鍵を含まない証明書ファイルのみが使用できます。

同様に、システム管理者が外部の CA 証明書を提供している場合は、パブリックデータ (秘密鍵がない証明書) のみを提供します。スマートカード認証用の IdM サーバーまたは IdM クライアントを設定する ipa-advise ユーティリティーでは、外部 CA の証明書が含まれる入力ファイルが必要ですが、秘密鍵は必要ありません。

証明書のエンコーディング

2 つの一般的な証明書エンコーディング PEM (Privacy-enhanced Electronic Mail) および DER (Distinguished Encoding Rules) があります。base64 形式は PEM 形式とほぼ同じですが、ヘッダーおよびフッター (-----BEGIN CERTIFICATE----- および -----END CERTIFICATE-----) は含まれません。

DER を使用してエンコードされた証明書は、バイナリーファイルの X509 デジタル証明書です。証明書はバイナリーファイルで、人間は判読できません。DER ファイルは、ファイル名の拡張子 .der を使用することもありますが、ファイル名の拡張子 .crt および .cer が DER 証明書が含まれることもあります。鍵を含む DER ファイルの名前は .key です。

PEM Base64 を使用してエンコードされた証明書は、人間が判読できるファイルです。このファイルには、「-----BEGIN …」の行頭に付けられた ASCII (Base64) のデータが含まれます。PEM ファイルは、.pem ファイル拡張子を使用することもありますが、ファイル名の拡張子 .crt および .cer に PEM 証明書が含まれる場合もあります。鍵を含む PEM ファイルの名前は .key です。

ipa コマンドには、許可される証明書の種類に、さまざまな制限があります。たとえば、ipa user-add-cert コマンドでは、base64 形式でエンコードされた証明書のみが使用できますが、ipa-server-certinstall は、PEM、DER、PKCS #7、PKCS #8 および PKCS #12 の証明書が使用できます。

「IdM における証明書関連のコマンドおよび形式」 には、追加のipa コマンドと、そのコマンドで使用できる証明書形式の一覧を示しています。

ユーザー認証

ブラウザーのデータベースに秘密鍵と証明書の両方を保存することで、Web UI を使用して IdM にアクセスすると、証明書に対応する秘密鍵をユーザーが所有していることを証明します。

CLI を使用して IdM にアクセスすると、以下のいずれかの方法で、証明書に対応する秘密鍵をユーザーが所有していることを証明します。

便利な証明書コマンド

証明書データ (発行先や発行者など) を表示するには、次のコマンドを実行します。

$ openssl x509 -noout -text -in ca.pem

2 つの証明書で、異なる行を比較するには、次のコマンドを実行します。

$ diff cert1.crt cert2.crt

2 つの証明書の出力を 2 列で表示して、2 つの証明書で異なる行を比較するには、次のコマンドを実行します。

$ diff cert1.crt cert2.crt -y

このセクションでは、外部証明書がユーザーエントリーに追加される前に、適切にエンコードされおよび形式が正しいことを確認する方法を説明します。

ユーザー証明書をブラウザーにインポートする前に、証明書と対応する秘密鍵が PKCS #12 形式にあることを確認してください。その他の準備作業が必要な一般的な状況は、次の 2 つです。

その後、PEM 形式の CA 証明書と、PKCS #12 形式のユーザー証明書をブラウザーにインポートするには、「証明書認証を有効にするようにブラウザーを設定」 および 「Identity Management ユーザーとして証明書を使用して Identity Management の Web UI で認証」の手順に従います。

「IdM 証明書コマンドおよび形式」の表は、使用可能な形式で、IdM の証明書関連のコマンドを表示します。

LDAP 識別名 (DN) が、CN=Certificate Authority,DC=EXAMPLE,DC=ORG である EXAMPLE.ORG ドメインの認証局により証明書が発行されたユーザーに対してスマートカード認証を有効にする場合は、IdM サーバーが設定するスクリプトで実行できるように、認証局の証明書を取得する必要があります。たとえば、認証局により発行された証明書が含まれる Web ページから、その証明書をダウンロードできます。詳細は、「証明書認証を有効にするようにブラウザーを設定」の手順 1 ~ 4a を参照してください。

IdM 認証局が証明書を発行している IdM ユーザーに対してスマートカード認証を有効にするには、IdM CA が実行している IdM サーバーの /etc/ipa/ca.crt ファイルから CA 証明書を取得します。

本セクションでは、スマートカード認証に IdM サーバーを設定する方法を説明します。まず、PEM 形式の CA 証明書でファイルを取得してから、組み込みの ipa-advise スクリプトを実行します。最後に、システム設定を再読み込みます。

これで、スマートカード認証にサーバーが設定されました。

本セクションでは、スマートカード認証に IdM クライアントを設定する方法を説明します。この手順は、認証にスマートカードを使用しているときに接続する各 IdM システム、クライアント、またはサーバーで実行する必要があります。たとえば、ホスト A からホスト B への ssh 接続を有効にするには、スクリプトをホスト B で実行する必要があります。

管理者として、以下を使用して、この手順でスマートカード認証を有効にします。

この手順は、IdM Web UI に対する認証には必要ありません。IdM Web UI の認証には 2 つのホストが関係しますが、どちらも IdM クライアントである必要はありません。

以下の手順は、IdM マスターだけでなく、IdM クライアントでスマートカード認証を設定していることを前提としています。このため、2 台のコンピューターが必要です。設定スクリプトを生成する IdM マスターと、スクリプトを実行する IdM クライアントが必要になります。

これで、クライアントがスマートカード認証に対して設定されました。

この手順では、IdM のユーザーエントリーに外部証明書を追加する方法を説明します。

証明書全体をアップロードする代わりに、IdM のユーザーエントリーに証明書マッピングデータをアップロードすることもできます。システム管理者向けのスマートカード認証の設定を容易にするために、完全な証明書または証明書マッピングデータのいずれかが含まれるユーザーエントリーを、対応する証明書マッピングルールと併用できます。詳細は16章Identity Management に証明書マッピングルールを設定を参照してください。

このモジュールでは、スマートカード認証に Firefox ブラウザーを設定する方法を説明します。

Identity Management では、以下のブラウザーを使用して、Web UI に接続できます。

次の手順は、Mozilla Firefox 57.0.1 ブラウザーを設定する方法を説明します。

これで、ブラウザーは、読み込まれているセキュリティーデバイスを使用してスマートカードを認証する準備が整いました。

本セクションでは、IdM Web UI へのログインにスマートカードを使用する方法を説明します。

これで、IdM Web UI に正常にログインできるようになりました。

Identity Management (IdM) 管理者は、ユーザーが、証明書を使用して IdM 環境で認証できるように設定できます。

Identity Management (IdM) 管理者は、IdM 環境でユーザーの証明書を作成し、作成した証明書を、ユーザーの証明書認証を有効にする IdM クライアントにエクスポートできます。

証明書が機能するには、証明書が、それを使用して Identity Management (IdM) に認証を受けるユーザーにリンクされていることを確認する必要があります。

Identity Management の Web UI で証明書認証を機能させるには、証明書認証を有効にするホストで実行している Mozilla Firefox または Google Chrome のブラウザーに、ユーザー証明書および認証局 (CA) 証明書をインポートする必要があります。ホストが IdM ドメインに含まれている必要はありません。

Identity Management では、以下のブラウザーを使用して、Web UI に接続できます。

次の手順は、Mozilla Firefox 57.0.1 ブラウザーを設定する方法を説明します。

次の手順では、Identity Management クライアントのデスクトップに保存されている証明書を使用して、ユーザーが Identity Management (IdM) の Web UI を認証する方法を説明します。

これで、証明書に対応するユーザーとして認証されました。

IdM クライアントのコマンドラインインターフェース (CLI) で、IdM ユーザーに対して証明書認証を有効にするには、IdM ユーザーの証明書および秘密鍵を IdM クライアントにインポートします。ユーザー証明書の作成および転送の詳細は「新しいユーザー証明書を要求し、クライアントにエクスポート」を参照してください。

証明書マッピングルールは、Identity Management (IdM) 管理者が特定のユーザーの証明書にアクセスしない場合に、シナリオで証明書を使用して認証できるため便利な方法です。通常、このようなアクセスがない理由は、証明書が外部認証局によって発行されたためです。特別なユースケースは、IdM ドメインが信頼関係にある Active Directory (AD) の証明書システムが発行した証明書によって表されます。

証明書マッピングルールは、スマートカードを使用するユーザーが多く、IdM 環境が大きい場合にも便利です。このような場合、完全な証明書を追加すると複雑になります。ほとんどの場合、発行先と発行者は予測可能であるため、完全な証明書よりも簡単に追加できます。システム管理者は、証明書マッピングルールを作成し、特定のユーザーに証明書を発行する前に、ユーザーエントリーに証明書マッピングデータを追加できます。証明書が発行されると、完全な証明書が自分のエントリーにアップロードされていなくても、ユーザーは証明書を使用してログインできるようになります。

さらに、証明書は一定間隔で更新する必要があるため、証明書マッピングルールは管理のオーバーヘッドを軽減します。ユーザーの証明書を更新する際に、管理者がユーザーエントリーを更新する必要がありません。たとえば、マッピングが Subject と Issuer の値に基づいている場合、および新しい証明書の Subject と Issuer が以前と同じ場合は、マッピングは引き続き適用されます。一方で、完全な証明書を使用した場合、管理者は古い証明書に置き換わる新しい証明書をユーザーエントリーにアップロードする必要があります。

証明書マッピングを設定するには、以下を実行します。

その後、エンドユーザーが、ファイルシステム または スマートカード に保存されている証明書を提示する際に適切に認証されます。

# ipa certmaprule-add simple_rule --matchrule '<ISSUER>CN=Smart Card CA,O=EXAMPLE.ORG' --maprule '(ipacertmapdata=X509:<I>{issuer_dn!nss_x500}<S>{subject_dn!nss_x500})'

このユーザーストーリーでは、証明書認証が設定されているユーザーが IdM に保存されている場合に、システム管理者が IdM での証明書マッピングを有効にする必要がある手順を説明します。

このユーザーストーリーでは、IdM デプロイメントが Active Directory (AD) を信頼し、そのユーザーが AD に保存され、AD のユーザーエントリーに証明書全体が含まれる場合に、IdM で証明書マッピングを有効にするのに必要な手順を説明します。

このユーザーストーリーでは、IdM デプロイメントが Active Directory (AD) を信頼し、そのユーザーが AD に保存され、AD のユーザーエントリーに証明書マッピングデータが含まれる場合に、IdM で証明書マッピングを有効にするのに必要な手順を説明します。

このユーザーストーリーでは、IdM デプロイメントが Active Directory (AD) を信頼し、そのユーザーが AD に保存され、AD のユーザーエントリーに証明書全体または証明書マッピングデータが含まれる場合に、IdM で証明書マッピングを有効にするのに必要な手順を説明します。

複数の ID マッピングルールを 1 つのルールに結合するには、個々のマッピングルールの前に | (or) 文字を追加し、括弧 () で区切ります。以下に例を示します。

$ ipa certmaprule-add ad_cert_for_ipa_and_ad_users \ --maprule='(|(ipacertmapdata=X509:<I>{issuer_dn!nss_x500}<S>{subject_dn!nss_x500})(altSecurityIdentities=X509:<I>{issuer_dn!ad_x500}<S>{subject_dn!ad_x500}))' \ --matchrule='<ISSUER>CN=AD-ROOT-CA,DC=ad,DC=example,DC=com' \ --domain=ad.example.com

上記の例では、--maprule オプションのフィルター定義には、以下の基準が含まれます。

--maprule オプションのフィルターの定義では、論理演算子 | (or) が使用できるため、複数の基準を指定できます。この場合、ルールは、1 つ以上の基準を満たすユーザーアカウントをすべてマップします。

$ ipa certmaprule-add ipa_cert_for_ad_users \
  --maprule='(|(userCertificate;binary={cert!bin})(ipacertmapdata=X509:<I>{issuer_dn!nss_x500}<S>{subject_dn!nss_x500})(altSecurityIdentities=X509:<I>{issuer_dn!ad_x500}<S>{subject_dn!ad_x500}))' \
  --matchrule='<ISSUER>CN=Certificate Authority,O=REALM.EXAMPLE.COM' \
  --domain=idm.example.com --domain=ad.example.com

上記の例では、--maprule オプションのフィルター定義には、以下の基準が含まれます。

--maprule オプションのフィルターの定義では、論理演算子 | (or) が使用できるため、複数の基準を指定できます。この場合、ルールは、1 つ以上の基準を満たすユーザーアカウントをすべてマップします。

Identity Management (IdM) の認証局 (CA) 更新マスターサーバーは、IdM システム証明書を維持および更新し、非破壊的な IdM デプロイメントを確保します。

IdM システム証明書には、以下が含まれます。

システム証明書の特徴は、鍵がすべての CA レプリカで共有されることです。IdM サービス証明書 (LDAP 証明書、HTTP 証明書、および PKINIT 証明書など) には、さまざまな IdM CA サーバーに、さまざまなキーペアと発行先名があります。

IdM トポロジーでは、デフォルトで、最初のマスターの IdM CA サーバーが CA Renewal Master になります。

IdM CA は、アップストリームのドキュメントでは Dogtag と呼ばれています。

CA Renewal Master サーバーの役割

IdM CA 証明書、IdM CA サブシステム 証明書、および IdM RA 証明書は、IdM デプロイメントに重要です。各証明書は、/etc/pki/pki-tomcat/ ディレクトリーの NSS データベースおよび LDAP データベースのエントリーに保存されます。LDAP に保存されている証明書は、NSS データベースに保存されている証明書に一致する必要があります。一致しない場合は、IdM フレームワークと IdM CA、および IdM CA と LDAP との間に認証エラーが発生します。

すべての IdM CA レプリカは、すべてのシステム証明書への追跡リクエストがあります。統合 CA を備えた IdM デプロイメントに CA Renewal Master が含まれていない場合、システム証明書の更新要求は各 IdM CA サーバーによって個別に行われます。これにより、異なる CA レプリカにさまざまなシステム証明書が含まれるようになり、認証に失敗します。

CA レプリカの 1 つを更新マスターとすることで、システム証明書が必要に応じて一度だけ更新されるため、認証が失敗しないようになります。

CA レプリカにおける certmonger の役割

すべての IdM CA レプリカで実行している certmonger サービスは、dogtag-ipa-ca-renew-agent 更新ヘルパーを使用して、IdM システム証明書を追跡します。更新ヘルパープログラムは、CA Renewal Master 設定を読み取ります。CA Renewal Master 以外の各 CA レプリカで、更新ヘルパープログラムが、ca_renewal LDAP エントリーから最新のシステム証明書を取得します。certmonger の更新の試みが正確に行われる際に、非決定論により、CA Renewal Master が実際に証明書を更新する前に、dogtag-ipa-ca-renew-agent ヘルパーがシステム証明書の更新を試みることがあります。この状況が発生すると、CA レプリカの certmonger に、古くて、すぐに有効期限が切れる証明書が提供されます。certmonger は、これデータベースにすでに保存されているのと同じ証明書であることを認識し、CA Renewal Master から更新された証明書を取得できるまで、個々の試行の間に少し遅れて証明書の更新を試行し続けます。

IdM CA Renewal Master の適切な機能

埋め込み CA のある IdM デプロイメントは、IdM CA でインストールされた、または後で IdM CA マスターサーバーがインストールされた IdM デプロイメントです。組み込み CA を使用した IdM デプロイメントでは、常に更新マスターとして構成された CA レプリカが 1 つだけ必要になります。更新マスターサーバーはオンラインで完全に機能し、その他のサーバーで正しく複製する必要があります。

CA Renewal Master が非推奨になった場合や、オフラインの場合は、システム証明書が期限切れになった時に更新されません。更新されないすべてのマスターサーバーでは、証明書が期限切れになるまで現在のシステム証明書を再インストールし続けます。これが発生すると、証明書が失効した場合でも、その他の証明書の更新が失敗する可能性があるため、IdM デプロイメントが中断されます。

ipa server-del コマンド、ipa-replica-manage del コマンド、ipa-csreplica-manage del コマンド、または ipa-server-install --uninstall コマンドを使用して、現在の CA Renewal Master サーバーを削除すると、CA レプリカは、CA Renewal Master サーバーとして自動的に割り当てられます。このポリシーは、更新されたマスター設定を有効に保つようにします。

このポリシーは、以下の状況を対象としません。

本セクションでは、IdM CA Renewal Master を変更する方法を説明します。

CA Renewal Master を停止すると、システム管理者による影響を受けずに、新しい CA Renewal Master が、IdM CA サーバーの一覧から自動的に選択されます。

新しい IdM CA Renewal Master サーバーを選択できるようにするには、システム管理者が、現在の更新マスターの停止プロセスを開始する前に、手動で置き換える必要があります。

現在の CA Renewal Master 設定が無効な場合は、IdM CA Renewal Master のリセットが必要になることがあります。

この手順では、CA Renewal Master を変更またはリセットします。

この手順は、外部署名から、IdM 認証局 (CA) の自己署名証明書に切り替えます。自己署名の CA の場合、CA 証明書の更新は自動的に管理されます。システム管理者は、外部認証局に CSR を提出する必要はありません。

外部署名から自己署名の CA へ切り替える場合は、CA 証明書を置き換えます。以前の CA が署名する証明書は有効のままで、今でも使用されています。たとえば、LDAP 証明書の証明書チェーンは、自己署名の CA に移動した後も変更されません。

external_CA certificate > IdM CA certificate > LDAP certificate

このセクションでは、証明書署名要求 (CSR) に署名するために外部の認証局を使用して IdM CA 証明書を更新する方法を説明します。この設定では、IdM CA サーバーは、外部 CA のサブ CA です。外部の CA は、Active Directory Certificate Server (AD CS) を使用することができますが、必須ではありません。

外部認証局が AD CS の場合は、CSR に、IdM CA 証明書に必要なテンプレートを指定できます。証明書テンプレートは、証明書要求の受信時に CA が使用するポリシーおよびルールを定義します。AD の証明書テンプレートは、IdM の証明書プロファイルに対応します。

オブジェクト識別子 (OID) で特定の AD CS テンプレートを定義できます。OID は、分散アプリケーションのデータ要素、構文などを一意に識別するために、さまざまな発行機関が発行する一意の数値です。

または、特定の AD CS テンプレートを名前で定義することもできます。たとえば、IdM CA から AD CS に送信された CSR で使用されるデフォルトプロファイルの名前は subCA です。

CSR で OID または名前を指定してプロファイルを定義するには、external-ca-profile オプションを使用します。詳細は、man ページの ipa-cacert-manage を参照してください。

既製の証明書テンプレートを使用する以外に、AD CS でカスタム証明書テンプレートを作成し、CSR で使用できます。

本セクションでは、期限切れの IdM 証明書に ipa-cert-fix ツールを適用する方法を説明します。

この時点で、証明書が更新され、サービスが実行しています。次の手順は、IdM ドメイン内のその他のサーバーを確認します。

ipa-cert-fix ツールで、CA Renewal Master を更新したら、以下を行う必要があります。

これで、すべての IdM 証明書が更新され、正常に機能するようになりました。

certmonger の機能

Identity Management (IdM) が統合 IdM 認証局 (CA) とともにインストールされていると、certmonger サービスを使用してシステムおよびサービス証明書を追跡し、更新します。証明書の期限が切れると、certmonger は次の方法で更新プロセスを管理します。

certmonger が追跡する証明書の種類

証明書は、システム証明書とサービス証明書に分けることができます。

さまざまなサーバーのさまざまなキーペアと発行名を持つサービス証明書 (HTTP、LDAP、PKINIT など) とは異なり、IdM システム証明書とその鍵はすべての CA レプリカで共有されます。IdM システム証明書には、以下が含まれます。

certmonger サービスは、統合 CA を使用した IdM 環境のインストール時に要求された IdM システム証明書およびサービス証明書を追跡します。certmonger は、IdM ホストで実行しているその他のサービスに対して、システム管理者が手動で要求した証明書を追跡します。certmonger は、外部認証局の証明書またはユーザー証明書を追跡しません。

Certmonger のコンポーネント

certmonger サービスは、2 つの主要コンポーネントで構成されています。

具体的には、システム管理者は、getcert ユーティリティーを使用して以下のことができます。

ブラウザーと、IdM クライアントで実行している Web サービスとの間の通信が安全で暗号化されていることを確認するには、TLS 証明書を使用します。IdM CA から Web サービスの TLS 証明書を取得します。

本セクションでは、certmonger を使用して、IdM クライアントで実行するサービス (HTTP/webserver.idm.example.com@IDM.EXAMPLE.COM) の IdM 証明書を取得する方法を説明します。

certmonger 使用して証明書を自動的に要求するということは、certmonger 更新の期限が切れたときに証明書を管理および更新することを意味します。

certmonger がサービス証明書を要求したときに発生する内容を視覚的に表示するには、「サービス証明書を要求する certmonger の通信フロー」を参照してください。

本セクションの図では、各ステージで、certmonger が IdM CA サーバーからサービス証明書を要求する際に何が発生するかを説明します。シーケンスは次の図で構成されています。

図19.1「暗号化されていない通信」 は、最初の状況を示します。HTTPS 証明書なしで、Web サーバーとブラウザー間の通信は暗号化されません。

図19.1 暗号化されていない通信

図19.2「サービス証明書を要求する certmonger」では、システム管理者が certmonger を使用して、Apache Web サーバーの HTTPS 証明書を手動で要求する方法を説明します。Web サーバー証明書を要求する場合、certmonger は CA と直接対話しないことに注意してください。IdM 経由でプロキシーが設定されます。

図19.2 サービス証明書を要求する certmonger

図19.3「サービス証明書を発行する IdM CA」 は、Web サーバーの HTTPS 証明書を発行する IdM CA を表示します。

図19.3 サービス証明書を発行する IdM CA

図19.4「サービス証明書を適用する証明書」は、certmonger が、IdM クライアントの適切な場所に HTTPS 証明書を置くことを示しており、そう指示された場合は httpd サービスを再起動します。その後、Apache サーバーは HTTPS 証明書を使用して、Apache サーバーとブラウザー間のトラフィックを暗号化します。

図19.4 サービス証明書を適用する証明書

図19.5「古い証明書が有効期限に近づいているときに新しい証明書を要求する certmonger」では、証明書の有効期限の前に、IdM CA からサービス証明書の更新を自動的に要求する certmonger を示しています。IdM CA は、新しい証明書を発行します。

図19.5 古い証明書が有効期限に近づいているときに新しい証明書を要求する certmonger

certmonger サービスは、証明書要求を監視します。証明書要求が正常に署名されると、証明書が作成されます。certmonger は、生成される証明書を含む証明書要求を管理します。本セクションでは、certmonger が管理する特定の証明書要求の詳細を表示する方法を説明します。

本セクションでは、getcert stop-tracking コマンドおよび getcert start-tracking コマンドを使用して証明書を監視する方法を説明します。この 2 つのコマンドは、certmonger サービスで利用できます。証明書追跡を有効にすると、IdM CA が発行する証明書を、別の IdM クライアントのマシンにインポートすると特に便利です。証明書の追跡を有効にすることは、次のプロビジョニングシナリオの最終ステップでもあります。

証明書が失効日近くになると、certmonger デーモンは、CA ヘルパーを使用して更新コマンドを自動的に発行し、更新された証明書を取得し、以前の証明書を新しい証明書に置き換えます。

getcert resubmit コマンドを使用して、事前に証明書を手動で更新することもできます。これにより、SAN (Subject Alternative Name) を追加したりすると、証明書に含まれる情報を更新できます。

本セクションでは、証明書を手動で更新する方法を説明します。

この手順は、証明書の追跡が中断された後、certmonger が統合認証局で IdM デプロイメントに不可欠な IdM システム証明書の追跡を再開する方法を説明します。中断は、システム証明書の更新中に IdM ホストがIdM から登録解除されたか、レプリケーショントポロジーが正しく機能しないことが原因である可能性があります。この手順では、certmonger が IdM サービス証明書 (HTTP、LDAP、PKINIT) の追跡を再開する方法も説明します。

Red Hat Enterprise Linux (RHEL) 7 では、System Security Services Daemon (SSSD) で外部グループメンバーシップを使用すると、AD ユーザーとグループが POSIX 環境の IdM リソースにアクセスできるようになります。

IdM LDAP サーバーには、アクセス制御を付与する独自のメカニズムがあります。RHEL 8 には、AD ユーザーに対する ID ユーザーのオーバーライドを、IdM グループのメンバーとして追加できるようにする更新が導入されました。ID オーバーライドは、特定の Active Directory ユーザーまたはグループのプロパティーが特定の ID ビュー (この場合は Default Trust View) 内でどのように見えるかを記述するレコードです。この更新により、IdM LDAP サーバーは、IdM グループのアクセス制御ルールを AD ユーザーに適用できます。

AD ユーザーは、IdM UI のセルフサービス機能 (SSH キーのアップロード、個人のデータの変更など) を使用できるようになりました。AD 管理者は、アカウントおよびパスワードを 2 つ使用しなくても、IdM を完全に管理できるようになります。

Active Directory ユーザーが Identity Management CLI にログインし、自分のロールに適したコマンドを実行できることを確認します。

デフォルトでは、ipa-client-install コマンドを使用して登録した IdM クライアントでは、サービスプリンシパルで短縮ホスト名を使用することができません。たとえば、ユーザーがサービスにアクセスするときに、host/demo@EXAMPLE.COMではなく、host/demo.example.com@EXAMPLE.COM のみを使用できます。

本セクションでは、Kerberos プリンシパルにエイリアスを追加する方法を説明します。または、/etc/krb5.conf ファイルでホスト名の正規化を有効にできます。詳細は「クライアントのサービスプリンシパルでのホスト名の正規化の有効化」を参照してください。

ここでは、クライアントのサービスプリンシパルでホスト名の正規化を有効にする方法を説明します。

「ホストプリンシパルへのエイリアスの追加」で説明しているように、ホストプリンシパルのエイリアスを使用する場合は、正規化を有効にする必要はありません。

「クライアントのサービスプリンシパルでのホスト名の正規化の有効化」の説明にあるように、/etc/krb5.conf ファイルに dns_canonicalize_hostname = true を設定する場合は、サービスプリンシパルでホスト名を使用する際に以下のオプションを指定します。

IdM の Healthcheck ツールは、IdM 環境の健全性に影響を与える可能性がある問題を見つけるのに役立ちます。

Healthcheck は、以下に対応するモジュールで構成されます。

Healthcheck は、以下の出力を生成します。

Healthcheck の各テストにより、4 種類の結果を生成できます。

Healthcheck は、以下の方法で実行できます。

ログローテーションは新しいログファイルを毎日作成し、ファイルが日付別に編成されます。ログファイルは同じディレクトリーに保存されるため、日付に応じて特定のログファイルを選択できます。

ローテーションは、ログファイルの最大数が設定されていて、その数を超えると、最新のファイルが最も古いファイルを書き直し、名前を変更することを意味します。たとえば、ローテーションの数が 30 の場合は、31 番目のファイル (最も古いファイル) が新しいファイルにより置き換えられます。

ログローテーションは、膨大なログファイルを減らして整理するため、ログの分析に役立ちます。

本セクションでは、以下を使用してログローテーションを設定する方法を説明します。

systemd タイマーは、Healthcheck ツールを定期的に実行して、ログを生成します。デフォルト値は、毎日 4 am に設定されています。

crond サービスは、ログローテーションに使用されます。

デフォルトのログ名は healthcheck.log で、ローテーションされるログは healthcheck.log-YYYYMMDD 形式を使用します。

ログの生成を開始するには、IPA healthcheck サービスを起動します。

# systemctl start ipa-healthcheck

結果を確認するには、/var/log/ipa/healthcheck/ に移動して、ログが正しく作成されていることを確認します。

Healthcheck ツールには、IdM サービスが稼働していないかどうかを確認するテストが含まれます。このテストは、実行中ではないサービスが他のテストで不具合を引き起こす可能性があるため、重要です。したがって、全サービスが最初に実行されていることを確認します。次に、その他のテスト結果をすべて確認できます。

すべてのサービステストを表示するには、--list-sources オプションを指定して、ipa-healthcheck を実行します。

# ipa-healthcheck --list-sources

ipahealthcheck.meta.services ソースの下に、Healthcheck でテストしたサービスをすべて確認できます。

本セクションでは、Healthcheck ツールを使用して、Identity Management (IdM) サーバーで実行しているサービスのスタンドアロンの手動テストを説明します。

Healthcheck ツールには多くのテストが含まれており、その結果は次の方法で短くすることができます。

テストに成功すると、空の括弧が表示されます。

[ ]

サービスのいずれかが失敗した場合は、以下のような結果になります。

{
  "source": "ipahealthcheck.meta.services",
  "check": "httpd",
  "result": "ERROR",
  "kw": {
    "status": false,
    "msg": "httpd: not running"
  }
}

Healthcheck ツールには、IdM および AD 信頼の状況をテストするためのテストが複数含まれます。

すべての信頼テストを表示するには、--list-sources オプションを指定して ipa-healthcheck を実行します。

# ipa-healthcheck --list-sources

ipahealthcheck.ipa.trust ソースでテストをすべて見つけることができます。

本セクションでは、Healthcheck ツールを使用して、Identity Management (IdM) および Active Directory (AD) の信頼ヘルスチェックに関するスタンドアロンの手動テストを説明します。

Healthcheck ツールには多くのテストが含まれるため、以下の方法で結果を短くすることができます。

テストに成功すると、空の括弧が表示されます。

# ipa-healthcheck --source=ipahealthcheck.ipa.trust --failures-only
[]

Healthcheck ツールには、Identity Management (IdM) の certmonger が維持する証明書の状況を確認するさまざまなテストが含まれています。certmonger の詳細は、「certmonger を使用してサービスの IdM 証明書の取得」を参照してください。

このテストスイートは、有効期限、検証、信頼、およびその他の問題を確認します。根本的な問題 1 つに対して、複数のエラーが発生する可能性があります。

すべての証明書テストを表示するには、--list-sources オプションを指定して ipa-healthcheck を実行します。

# ipa-healthcheck --list-sources

すべてのテストは、ipahealthcheck.ipa.certs ソースの下にあります。

本セクションでは、Healthcheck ツールを使用した Identity Management (IdM) 証明書のヘルスチェックのスタンドアロンの手動テストを説明します。

Healthcheck ツールには多くのテストが含まれるため、以下の方法で結果を短くすることができます。

テストに成功すると、空の括弧が表示されます。

[]

失敗したテストでは、以下の出力が表示されます。

{
  "source": "ipahealthcheck.ipa.certs",
  "check": "IPACertfileExpirationCheck",
  "result": "ERROR",
  "kw": {
    "key": 1234,
    "dbdir": "/path/to/nssdb",
    "error": [error],
    "msg": "Unable to open NSS database '/path/to/nssdb': [error]"
  }
}

この IPACertfileExpirationCheck テストは、NSS データベースを開く際に失敗します。

Healthcheck ツールには、Dogtag 証明書を検証するさまざまなテストがあります。

すべてのテストを表示するには、--list-sources オプションを指定して ipa-healthcheck を実行します。

# ipa-healthcheck --list-sources

すべてのテストは、ipahealthcheck.dogtag.ca ソースの下にあります。

本セクションでは、Healthcheck ツールを使用して、Identity Management (IdM) 証明書のスタンドアロンの手動テストを説明します。

Healthcheck ツールには多くのテストが含まれるため、Dogtag テスト (--source=ipahealthcheck.dogtag.ca) のみを含めることで結果を絞り込むことができます。

テストに成功すると、以下のようになります。

{
  "source: ipahealthcheck.dogtag.ca",
  "check: DogtagCertsConfigCheck",
  "result: SUCCESS",
  "uuid: 9b366200-9ec8-4bd9-bb5e-9a280c803a9c",
  "when: 20191008135826Z",
  "duration: 0.252280",
  "kw:" {
    "key": "Server-Cert cert-pki-ca",
    "configfile":  "/var/lib/pki/pki-tomcat/conf/ca/CS.cfg"
    }
}

テストに失敗すると、以下のようになります。

{
  "source: ipahealthcheck.dogtag.ca",
  "check: DogtagCertsConfigCheck",
  "result: CRITICAL",
  "uuid: 59d66200-1447-4b3b-be01-89810c803a98",
  "when: 20191008135912Z",
  "duration: 0.002022",
  "kw:" {
    "exception": "NSDB /etc/pki/pki-tomcat/alias not initialized",
    }
}

Healthcheck ツールには、利用可能なディスク領域を確認するテストが含まれます。空きディスク容量が十分にないと、以下で問題が発生する可能性があります。

テストでは、以下のパスを確認します。

テストの一覧を表示するには、--list-sources オプションを指定して、ipa-healthcheck を実行します。

# ipa-healthcheck --list-sources

ファイルシステム容量の確認テストは、ipahealthcheck.system.filesystemspace ソースの下にあります。

本セクションでは、Healthcheck ツールを使用して、Identity Management (IdM) サーバーで利用可能なディスク容量のスタンドアロンの手動テストを説明します。

Healthcheck には多くのテストが含まれるため、次の方法で結果を絞り込むことができます。

テストに成功すると、空の括弧が表示されます。

[]

テストに失敗すると、たとえば、以下のような結果が表示されます。

{
  "source": "ipahealthcheck.system.filesystemspace",
  "check": "FileSystemSpaceCheck",
  "result": "ERROR",
  "kw": {
    "msg": "/var/lib/dirsrv: free space under threshold: 0 MiB < 1024 MiB",
    "store": "/var/lib/dirsrv",
    "free_space": 0,
    "threshold": 1024
  }
}

ここでは、/var/lib/dirsrv ディレクトリーの容量が不足しているためにテストに失敗したことが通知されます。

Healthcheck ツールは、Identity Management (IdM) によりインストールまたは設定される重要なファイルの所有権とパーミッションをテストします。

テストされたファイルの所有権またはパーミッションを変更すると、テストにより 結果 セクションに警告が返ります。必ずしも設定が機能しないことを意味するわけではありませんが、ファイルがデフォルト設定と異なることを意味します。

すべてのテストを表示するには、--list-sources オプションを指定して ipa-healthcheck を実行します。

# ipa-healthcheck --list-sources

ファイルパーミッションテストは、ipahealthcheck.ipa.files ソースの下にあります。

本セクションでは、Healthcheck ツールを使用して、Identity Management (IdM) サーバーの設定ファイルのスタンドアロンの手動テストを説明します。

Healthcheck ツールには、多くのテストが含まれます。結果を絞り込むには、以下を行います。

テストに成功すると、空の括弧が表示されます。

# ipa-healthcheck --source=ipahealthcheck.ipa.files --failures-only
[]

テストに失敗すると、以下の WARNING のような結果が表示されます。

{
  "source": "ipahealthcheck.ipa.files",
  "check": "IPAFileNSSDBCheck",
  "result": "WARNING",
  "kw": {
    "key": "_etc_dirsrv_slapd-EXAMPLE-TEST_pkcs11.txt_mode",
    "path": "/etc/dirsrv/slapd-EXAMPLE-TEST/pkcs11.txt",
    "type": "mode",
    "expected": "0640",
    "got": "0666",
    "msg": "Permissions of /etc/dirsrv/slapd-EXAMPLE-TEST/pkcs11.txt are 0666 and should be 0640"
  }
}

Healthcheck ツールは、Identity Management (IdM) トポロジーの設定をテストして、レプリケーションの競合問題を検索します。

テストの一覧を表示するには、--list-sources オプションを指定して、ipa-healthcheck を実行します。

# ipa-healthcheck --list-sources

トポロジーのテストは、ipahealthcheck.ipa.topology ソースおよび ipahealthcheck.ds.replication ソースの下にあります。

本セクションでは、Healthcheck ツールを使用して、Identity Management (IdM) レプリケーショントポロジーおよび設定に対するスタンドアロンの手動テストを説明します。

Healthcheck ツールには多くのテストが含まれるため、以下の方法で結果を短くすることができます。

以下のような 4 つの結果が取得できます。