Red Hat Training

A Red Hat training course is available for RHEL 8

Identity Management の設定および管理

Red Hat Enterprise Linux 8

Red Hat Enterprise Linux 8 で Identity Management の設定、管理、および維持

Red Hat Customer Content Services

概要

本書は、Red Hat Enterprise Linux 8 で Identity Management を効果的に設定、管理、および維持する方法を説明します。

Red Hat ドキュメントへのフィードバック (英語のみ)

ご意見ご要望をお聞かせください。ドキュメントの改善点はございませんか。改善点を報告する場合は、以下のように行います。

  • 特定の文章に簡単なコメントを記入する場合は、ドキュメントが Multi-page HTML 形式になっているのを確認してください。コメントを追加する部分を強調表示し、そのテキストの下に表示される Add Feedback ポップアップをクリックし、表示された手順に従ってください。
  • より詳細なフィードバックを行う場合は、Bugzilla のチケットを作成します。

    1. Bugzilla の Web サイトにアクセスします。
    2. Component で Documentation を選択します。
    3. Description フィールドに、ドキュメントの改善に関するご意見を記入してください。ドキュメントの該当部分へのリンクも記入してください。
    4. Submit Bug をクリックします。

第1章 コマンドラインから Identity Management へのログイン

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

重要

IdM では、ユーザーが、対応する Kerberos プリンシパル名を使用して IdM クライアントマシンのデスクトップ環境にログインすると、SSSD (System Security Services Daemon) が、そのユーザーの TGT (Ticket-Granting Ticket) を自動的に取得します。これは、ログインしてから、kinit ユーティリティーを使用して IdM リソースにアクセスする必要がなくなることを意味します。

Kerberos 認証情報キャッシュを削除している場合、または Kerberos TGT の有効期限が切れている場合に IdM リソースにアクセスするには、手動で Kerberos チケットを要求する必要があります。以下のセクションでは、IdM で Kerberos を使用している場合の基本的なユーザー操作を説明します。

1.1. kinit による IdM への手動ログイン

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

注記

この手順は、最初の Kerberos TGT を破棄したか、有効期限が切れている場合にのみ使用します。ローカルマシンに、IdM ユーザーとしてログインすると、IdM に自動的にログインします。これは、ログイン後に IdM リソースにアクセスするのに kinit ユーティリティーを使用する必要がないことを示しています。

手順

  1. IdM へのログイン

    • ローカルシステムに現在ログインしているユーザーのユーザー名で、(ユーザー名を指定せずに) kinit を使用します。たとえば、ローカルシステムにログインしているユーザーが example_user の場合は、次のコマンドを実行します。

      [example_user@server ~]$ kinit
      Password for example_user@EXAMPLE.COM:
      [example_user@server ~]$

      ローカルユーザーのユーザー名と、IdM のユーザーエントリーが一致しないと、認証に失敗します。

      [example_user@server ~]$ kinit
      kinit: Client 'example_user@EXAMPLE.COM' not found in Kerberos database while getting initial credentials
    • ローカルユーザー名に対応しない Kerberos プリンシパルを使用して、kinit ユーティリティーに必要なユーザー名を渡します。たとえば、admin ユーザーとしてログインするには、次のコマンドを実行します。

      [example_user@server ~]$ kinit admin
      Password for admin@EXAMPLE.COM:
      [example_user@server ~]$
  2. 必要に応じて、ログインが成功したことを確認するには、klist ユーティリティーを使用して、キャッシュした TGT を表示します。以下の例では、キャッシュに example_user プリンシパルのチケットが含まれています。これは、このホストでは IdM サービスにアクセスするのは、example_user にのみ許可されていることを示しています。

    $ klist
    Ticket cache: KEYRING:persistent:0:0
    Default principal: example_user@EXAMPLE.COM
    
    Valid starting     	Expires            	Service principal
    11/10/2019 08:35:45  	11/10/2019 18:35:45  	krbtgt/EXAMPLE.COM@EXAMPLE.COM

1.2. アクティブなユーザーの Kerberos チケットの破棄

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

手順

  1. Kerberos チケットを破棄するには、次のコマンドを実行します。

    [example_user@server ~]$ kdestroy
  2. 必要に応じて、Kerberos チケットが破棄されたことを確認するには、次のコマンドを実行します。

    [example_user@server ~]$ klist
    klist: Credentials cache keyring 'persistent:0:0' not found

1.3. Kerberos 認証用の外部システムの設定

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

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

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

前提条件

  • 外部システムに krb5-workstation パッケージがインストールされている。

    パッケージがインストールされているかどうかを確認するには、次の CLI コマンドを使用します。

    # yum list installed krb5-workstation
    Installed Packages
    krb5-workstation.x86_64    1.16.1-19.el8     @BaseOS

手順

  1. IdM サーバーから外部システムに /etc/krb5.conf ファイルをコピーします。以下に例を示します。

    # scp /etc/krb5.conf root@externalsystem.example.com:/etc/krb5_ipa.conf
    警告

    外部マシンにある既存の krb5.conf ファイルは上書きしないでください。

  2. 外部システムで、コピーした IdM の Kerberos 設定ファイルを使用するように、端末セッションを設定します。

    $ export KRB5_CONFIG=/etc/krb5_ipa.conf

    KRB5_CONFIG 変数は、ログアウトまで一時的に存在します。ログアウト時に削除されないように、この変数のファイル名を変えてエクスポートします。

  3. /etc/krb5.conf.d/ ディレクトリーの Kerberos 設定部分を、外部システムにコピーします。

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

関連情報

  • Kerberos の詳細は、man ページの krb5.conf(5)kinit(1)klist(1)、および kdestroy(1) を参照してください。

第2章 Identity Management サービスの表示、開始、および停止

Identity Management (IdM) サーバーは、ドメインコントローラー (DC) として機能する Red Hat Enterprise Linux システムです。IdM サーバーでさまざまなサービスが実行していますが、中でも注目すべきは Directory Server、Certificate Authority (CA)、DNS、および Kerberos です。

2.1. 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

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

  • Kerberos サービスは、krb5kdc および kadmin の 2 つに分かれます。krb5kdc サービスは、Kerberos バージョン 5 の認証サービスおよびキー配布センター (KDC) デーモンになります。kadmin サービスは、Kerberos V5 データベース管理プログラムです。
  • named サービスは、インターネットのドメインネームシステム (DNS) を参照します。
  • pki は、証明書システムサービスにアクセスするコマンドラインインターフェースです。pki-tomcatd プログラムは、証明書を参照する Identity Management 操作を処理します。

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

注記

IdM の Web UI を使用して、特定の IdM サーバーで実行しているすべての IdM サービスの状態を表示することはできません。Kerberos に対応し、複数のサーバーで実行しているサービスは、IdM の Web UI の IdentityServices タブで表示できます。

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

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

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

2.2. Identity Management サーバー全体の起動および停止: ipactl ユーティリティー

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

ipactl コマンド

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

# ipactl start

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

# ipactl stop

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

# ipactl restart

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

# ipactl status
重要

ipactl コマンドは、IdM の Web UI では使用できません。

2.3. 個々の Identity Management サービスの開始および停止: systemctl ユーティリティー

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

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

# systemctl restart dirsrv@REALM-NAME.service

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

  • リモートサーバーのレイテンシーが長い環境で、タイムアウト設定オプションを調整するための特定のパラメーター
  • Active Directory サイトのアフィニティーを調整するための特定のパラメーター
  • グローバルの IdM 設定では提供されない特定の設定オプションのオーバーライド

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

# systemctl restart sssd.service

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

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

重要

複数の IdM ドメインサービスを再開する場合は、常に ipactl を使用してください。IdM サーバーにインストールされているサービス間での依存関係により、サービスを開始および停止する順番は極めて重要です。ipactl ユーティリティーは、サービスが適切な順番で開始および停止するようにします。

便利な systemctl コマンド

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

# systemctl start name.service

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

# systemctl stop name.service

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

# systemctl restart name.service

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

# systemctl status name.service
重要

IdM の Web UI を使用して、IdM サーバーで実行している個々のサービスを開始または停止することはできません。Web UI で可能なのは、IdentityServices に移動してサービスを選択し、Kerberos に対応する設定を修正することです。

第3章 IdM コマンドラインユーティリティーの概要

以下のセクションでは、Identity Management (IdM) コマンドラインユーティリティーの基本的な使用方法を説明します。

前提条件

3.1. IPA コマンドラインインターフェースとは

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

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

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

  • ネットワーク内のユーザー、グループ、ホスト、その他のオブジェクトを追加、管理、または削除する。
  • 証明書を管理する。
  • エントリーを検索する。
  • オブジェクトを表示し、オブジェクト一覧を表示する。
  • アクセス権を設定する。
  • 正しいコマンド構文でヘルプを取得する。

3.2. IPA のヘルプとは

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

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

  • IdM サーバーがインストールされ、実行している。
  • 有効な Kerberos チケットで認証されている。

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

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

$ ipa help [TOPIC | COMMAND | topics | commands]
  • [] - 括弧は、すべてのパラメーターが任意であることを示しており、ipa help のみを入力すれば、コマンドが実行できます。
  • |  - パイプ文字は または の意味になります。そのため、基本的な ipa help コマンドで TOPIC または COMMAND、もしくは topics または commandsを使用できます。
  • topics - ipa help topics コマンドを実行でき、適切に実行できます。このコマンドは、IPA ヘルプでカバーしたトピックの一覧 (usercertserver など多数) を表示します。
  • TOPIC - 大文字の TOPIC は変数を意味します。したがって、ipa help user など、特定のトピックを使用できます。
  • commands - ipa help commands コマンドを実行すると、正しく実行できます。このコマンドは、IPA ヘルプ (user-addca-enableserver-show など多数) でカバーされるコマンドの一覧を表示します。
  • COMMAND -  大文字の COMMAND は変数を意味するため、ipa help user-add など、特定のコマンドを使用できます。

3.3. IPA ヘルプトピックの使用

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

手順

  1. 端末を開き、IdM サーバーに接続します。
  2. ヘルプに記載されているトピックの一覧を表示するには、ipa help topics を実行します。

    $ ipa help topics
  3. 以下のいずれかのトピックを選択して、以下のパターンに従ってコマンドを実行します。ipa help [topic_name] は、topic_name 文字列ではなく、上の手順で取得したリストからトピックのいずれかを追加します。

    この例では、user トピックを使用します。

    $ ipa help user
  4. IPA help コマンドが長すぎるため、テキスト全体を表示できない場合は、以下の構文を使用します。

    $ ipa help user | less

    スクロールダウンすれば、ヘルプ全体を表示できます

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

3.4. IPA ヘルプコマンドの使用

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

手順

  1. 端末を開き、IdM サーバーに接続します。
  2. ヘルプで使用できるコマンドの一覧を表示するには、ipa help commands コマンドを実行します。

    $ ipa help commands
  3. コマンドのいずれかを選択し、次のように help コマンドを作成します。<COMMAND> 文字列の代わりに、ipa help <COMMAND> を使用すると、直前の手順に一覧表示されているコマンドのいずれかを追加します。

    $ ipa help user-add

関連情報

  • 詳細は man ipa ページを参照してください。

3.5. IPA コマンドの構造

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

  • 組み込みコマンド - 組み込みコマンドはすべて、IdM サーバーで利用できます。
  • プラグインにより提供されたコマンド

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

  • ユーザー
  • ホスト
  • DNS レコード
  • 証明書

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

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

  • 追加 (add)
  • 修正 (mod)
  • 削除 (del)
  • 検索 (find)
  • 表示 (show)

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

ipa user-addipa user-modipa user-delipa user-findipa user-show

ipa host-addipa host-modipa host-delipa host-findipa host-show

ipa dnsrecord-addipa dnsrecord-modipa dnsrecord-delipa dnsrecord-findipa dnrecord-show

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

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

3.6. IPA コマンドでユーザーアカウントを IdM コマンドに追加

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

  • IdM サーバーにユーザーアカウントを追加するには、管理者権限が必要です。

手順

  1. 端末を開き、IdM サーバーに接続します。
  2. 新しいユーザーを追加するコマンドを入力します。

    $ ipa user-add

    このコマンドは、ユーザーアカウントの作成に必要な基本的なデータを追加できるスクリプトを実行します。

  3. First name: フィールドに、新規ユーザーの名前を入力して、Enter キーを押します。
  4. Last name: フィールドに、新規ユーザーの苗字を入力し、Enter キーを押します。
  5. User login [suggested user name]: にユーザー名を入力します。また、提案されたユーザー名を使用する場合は、Enter キーを押します。

    ユーザー名は、IdM データベース全体で一意にする必要があります。エラーが発生した場合は、ipa user-add コマンドで最初からやり直すか、別のユーザー名を試してください。

ユーザー名を追加したら、ユーザーアカウントが 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 コマンドでパスワードだけを追加できます。

関連情報

パラメーターの詳細を表示するには、コマンドラインで、以下の help コマンドを実行します。

$ ipa help user-add

3.7. IPA コマンドで IdM のユーザーアカウントの変更

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

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

前提条件

  • IdM サーバーでユーザーアカウントを変更するために、管理者権限を有している。

手順

  1. 端末を開き、IdM サーバーに接続します。
  2. パスワードを追加するコマンドを入力します。

    $ ipa user-mod euser --password

    このコマンドは、新しいパスワードを追加できるスクリプトを実行します。

  3. 新しいパスワードを入力し、Enter キーを押します。

ユーザー名を追加したら、ユーザーアカウントが 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 にログインできます。

関連情報

パラメーターの詳細を表示するには、コマンドラインで、以下の help コマンドを実行します。

$ ipa help user-mod

3.8. IdM ユーティリティーに値をリスト形式で提供する方法

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

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

  • 同じコマンド呼び出しで、同じコマンドライン引数を複数回指定します。

    $ ipa permission-add --right=read --permissions=write --permissions=delete ...
  • または、一覧を中括弧で囲むこともできます。この場合、シェルは展開を実行します。

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

上記の例では、パーミッションをオブジェクトに追加する 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} ...

3.9. IdM ユーティリティーで特殊文字を使用する方法

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

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

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

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

第4章 コマンドラインから Identity Management エントリーの検索

次のセクションでは、オブジェクトの検索または表示に役立つ IPA コマンドの使用方法を説明します。

4.1. IdM エントリーの一覧表示の概要

特定のタイプの 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

4.2. 特定のエントリーの詳細の表示

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

手順

  • ホスト server.example.com に関する詳細を表示します。

    $ ipa host-show server.example.com
    
    Host name: server.example.com
    Principal name: host/server.example.com@EXAMPLE.COM
    ...

4.3. 検索サイズおよび時間制限の調整

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

Search size limit

クライアントの CLI または IdM Web UI にアクセスするブラウザーからサーバーに送信されるリクエストで返される最大エントリー数を定義します。

デフォルト - 100 エントリー

Search time limit

検索の実行までにサーバーが待機する最大時間 (秒) を定義します。検索がこの制限に到達したら、サーバーは検索を停止し、停止するまでの期間に検出されたエントリーを返します。

デフォルト - 2 秒

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

重要

検索のサイズや時間制限を高く設定しすぎると、サーバーのパフォーマンスに影響を及ぼすことがあります。

4.3.1. コマンドラインで検索サイズおよび時間制限の調整

以下では、コマンドラインで検索サイズと時間制限を調整する方法を説明します。

  • システム全体
  • 特定のエントリーの場合

手順

  1. CLI で現在の検索時間とサイズ制限を表示するには、ipa config-show コマンドを実行します。

    $ ipa config-show
    
    Search time limit: 2
    Search size limit: 100
  2. 全クエリーに対してグローバルに制限を調整するには、ipa config-mod コマンドを使用して、--searchrecordslimit オプションおよび --searchtimelimit オプションを指定します。以下に例を示します。

    $ ipa config-mod --searchrecordslimit=500 --searchtimelimit=5
  3. 特定のクエリーに対してのみ制限を調整するには、コマンドに --sizelimit オプションまたは --timelimit オプションを指定します。以下に例を示します。
$ ipa user-find --sizelimit=200 --timelimit=120

4.3.2. Web UI で検索サイズおよび時間制限の調整

以下のテキストは、IdM Web UI で検索サイズと時間制限を調整する方法を説明します。

  • システム全体
  • 特定のエントリーの場合

手順

全クエリーに対して、グローバルに制限を調節するには、以下を行います。

  1. IdM Web UI にログインします。
  2. IPA Server をクリックします。

    Web UI ipaserver

  3. IPA Server タブで、Configuration をクリックします。
  4. Search Options エリアに必要な値を設定します。

    デフォルト値は以下の通りです。

    • 検索サイズの制限 - 100 エントリー
    • 検索時間の制限 - 2 秒
  5. ページ上部にある Save をクリックします。

    Web UI 検索制限

値を保存したら、エントリーを検索し、結果を確認します。

第5章 Web ブラウザーで IdM Web UI へのアクセス

次のセクションでは、IdM (Identity Management) Web UI の概要と、そのアクセス方法を説明します。

5.1. IdM Web UI とは

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

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

  • IdM ユーザー - IdM サーバーでユーザーに付与されている権限に応じて制限されている一連の操作。基本的に、アクティブな IdM ユーザーは IdM サーバーにログインして自身のアカウントを設定できます。その他のユーザーまたは IdM サーバーの設定は変更できません。
  • 管理者 - IdM サーバーへのフルアクセス権
  • Active Directory ユーザー - ユーザーに付与されている権限に応じて制限されている一連の操作

    Active Directory ユーザーは、Identity Management の管理者になれません。

5.2. Web UI へのアクセスに対応している Web ブラウザー

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

  • Mozilla Firefox 38 以降
  • Google Chrome 46 以降

5.3. Web UI へのアクセス

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

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

手順

  1. ブラウザーのアドレスバーに、IdM サーバーの URL を入力します。名前は次の例のようになります。

    https://server.example.com

    server.example.com を、IdM サーバーの DNS 名に変更するだけです。

    これで、ブラウザーに IdM Web UI ログイン画面が開きます。

    Web UI のログイン画面

    • サーバーが応答しない、またはログイン画面が開かない場合は、接続している IdM サーバーの DNS 設定を確認してください。
    • 自己署名証明書を使用する場合は、ブラウザーに警告が表示されます。証明書を確認し、セキュリティー例外を許可して、ログインを続行します。

      セキュリティーの例外を回避するために、認証局が署名した証明書をインストールします。

  2. Web UI ログイン画面で、IdM サーバーのインストール時に追加した管理者アカウントの認証情報を入力します。

    詳細は『Identity Management サーバーのインストール: 統合 DNS と統合 CA の場合』を参照してください。

    IdM サーバーに、個人アカウントの認証情報がすでに入力されている場合は、それを入力できます。

    Web UI のログインパスワード

  3. Log in をクリックします。

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

Web UI ユーザー

第6章 Web UI で IdM にログイン: Kerberos チケットの使用

以下のセクションでは、IdM Web UI への Kerberos ログインを有効にする環境の初期設定と、Kerberos 認証を使用した IdM へのアクセスを説明します。

前提条件

6.1. Identity Management における Kerberos 認証

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

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

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

6.2. kinit による IdM への手動ログイン

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

注記

この手順は、最初の Kerberos TGT を破棄したか、有効期限が切れている場合にのみ使用します。ローカルマシンに、IdM ユーザーとしてログインすると、IdM に自動的にログインします。これは、ログイン後に IdM リソースにアクセスするのに kinit ユーティリティーを使用する必要がないことを示しています。

手順

  1. IdM へのログイン

    • ローカルシステムに現在ログインしているユーザーのユーザー名で、(ユーザー名を指定せずに) kinit を使用します。たとえば、ローカルシステムにログインしているユーザーが example_user の場合は、次のコマンドを実行します。

      [example_user@server ~]$ kinit
      Password for example_user@EXAMPLE.COM:
      [example_user@server ~]$

      ローカルユーザーのユーザー名と、IdM のユーザーエントリーが一致しないと、認証に失敗します。

      [example_user@server ~]$ kinit
      kinit: Client 'example_user@EXAMPLE.COM' not found in Kerberos database while getting initial credentials
    • ローカルユーザー名に対応しない Kerberos プリンシパルを使用して、kinit ユーティリティーに必要なユーザー名を渡します。たとえば、admin ユーザーとしてログインするには、次のコマンドを実行します。

      [example_user@server ~]$ kinit admin
      Password for admin@EXAMPLE.COM:
      [example_user@server ~]$
  2. 必要に応じて、ログインが成功したことを確認するには、klist ユーティリティーを使用して、キャッシュした TGT を表示します。以下の例では、キャッシュに example_user プリンシパルのチケットが含まれています。これは、このホストでは IdM サービスにアクセスするのは、example_user にのみ許可されていることを示しています。

    $ klist
    Ticket cache: KEYRING:persistent:0:0
    Default principal: example_user@EXAMPLE.COM
    
    Valid starting     	Expires            	Service principal
    11/10/2019 08:35:45  	11/10/2019 18:35:45  	krbtgt/EXAMPLE.COM@EXAMPLE.COM

6.3. Kerberos 認証用のブラウザーの設定

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

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

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

  • Firefox
  • Chrome

手順

  1. Web ブラウザーで、WebUI ログインダイアログを開きます。
  2. Web UI のログイン画面で、ブラウザー設定のリンクをクリックします。

    IPA ブラウザーの設定リンク

  3. 設定ページの手順に従います。

    IPA ブラウザーの設定ページ

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

6.4. Kerberos チケットで Web UI へのログイン

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

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

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

  • kinit コマンドの使用
  • Web UI ログインダイアログで、IdM ログイン認証情報を使用

手順

  • IdM Web UI を開きます。

    Kerberos 認証が正しく機能し、有効なチケットがある場合は、自動的に認証されて Web UI が開きます。

    チケットの有効期限が切れている場合は、最初に資格情報を使用して認証する必要があります。ただし、次からはログインダイアログを開かずに IdM Web UI が自動的に開きます。

    エラーメッセージ Authentication with Kerberos failed が表示された場合は、ブラウザーが Kerberos 認証用に設定されていることを確認してください。「Kerberos 認証用のブラウザーの設定」を参照してください。

    Firefox の Kerberos 認証に失敗

6.5. Kerberos 認証用の外部システムの設定

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

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

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

前提条件

  • 外部システムに krb5-workstation パッケージがインストールされている。

    パッケージがインストールされているかどうかを確認するには、次の CLI コマンドを使用します。

    # yum list installed krb5-workstation
    Installed Packages
    krb5-workstation.x86_64    1.16.1-19.el8     @BaseOS

手順

  1. IdM サーバーから外部システムに /etc/krb5.conf ファイルをコピーします。以下に例を示します。

    # scp /etc/krb5.conf root@externalsystem.example.com:/etc/krb5_ipa.conf
    警告

    外部マシンにある既存の krb5.conf ファイルは上書きしないでください。

  2. 外部システムで、コピーした IdM の Kerberos 設定ファイルを使用するように、端末セッションを設定します。

    $ export KRB5_CONFIG=/etc/krb5_ipa.conf

    KRB5_CONFIG 変数は、ログアウトまで一時的に存在します。ログアウト時に削除されないように、この変数のファイル名を変えてエクスポートします。

  3. /etc/krb5.conf.d/ ディレクトリーの Kerberos 設定部分を、外部システムにコピーします。
  4. 「Kerberos 認証用のブラウザーの設定」に記載されているように、外部システムにブラウザーを設定します。

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

6.6. Active Directory ユーザー用 Web UI ログイン

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

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

第7章 ワンタイムパスワードで Identity Management Web UI にログイン

IdM Web UI へのアクセスは、いくつかの方法を使用して保護できます。基本的なものはパスワード認証です。

パスワード認証のセキュリティーを向上させるために、2 つ目の手順を追加して、自動生成ワンタイムパスワード (OTP) を要求できます。最も一般的な使用方法は、ユーザーアカウントに関連付けられたパスワードと、ハードウェアまたはソフトウェアのトークンにより生成された期限付きワンタイムパスワードを組み合わせることです。

以下のセクションでは、次のことができます。

  • IdM で OTP 認証がどう機能するかを理解する。
  • IdM サーバーで OTP 認証を設定する。
  • OTP トークンを作成し、そのトークンを、電話の FreeOTP アプリと同期する。
  • ユーザーパスワードとワンタイムパスワードの組み合わせて、IdM Web UI に対して認証する。
  • Web UI でトークンを再同期する。

7.1. 前提条件

7.2. Identity Management におけるワンタイムパスワード (OTP) 認証

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

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

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

  • HMAC ベースのワンタイムパスワード (HOTP) アルゴリズムは、カウンターに基づいています。HMAC は、Hashed Message Authentication Code (ハッシュメッセージ認証コード) を表しています。
  • 時間ベースのワンタイムパスワード (TOTP) アルゴリズムは、時間ベースの移動要素に対応する HOTP の拡張機能です。
重要

IdM は、Active Directory 信頼ユーザーの OTP ログインに対応していません。

7.3. Web UI でワンタイムパスワードの有効化

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

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

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

前提条件

  • 管理権限

手順

  1. ユーザー名およびパスワードを使用して IdM Web UI にログインします。
  2. Identity → Users → Active users タブを開きます。

    Web UI ユーザー

  3. ユーザー名をクリックして、ユーザー設定を開きます。
  4. User authentication types で、Two factor authentication (password + OTP) を選択します。
  5. Save をクリックします。

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

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

7.4. Web UI で OTP トークンの追加

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

前提条件

  • IdM サーバーでアクティブなユーザーアカウント。
  • 管理者が、IdM Web UI の特定のユーザーアカウントに対して OTP を有効にしている。
  • FreeOTP などの OTP トークンを生成するソフトウェアデバイス。

手順

  1. ユーザー名とパスワードを使用して IdM Web UI にログインします。
  2. Authentication → OTP Tokens タブを開いて、携帯電話でトークンを作成します。
  3. Add をクリックします。

    Web UI の トークンタブ

  4. Add OTP token ダイアログボックスに何も入力せず、Add をクリックします。

    この段階で、IdM サーバーはデフォルトパラメーターを使用してトークンを作成し、QR コード付きページを開きます。

  5. QR コードを携帯電話にコピーします。
  6. OK をクリックして QR コードを閉じます。

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

freeotp トークン

7.5. ワンタイムパスワードで Web UI にログイン

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

前提条件

  • OTP 認証を使用しているユーザーアカウントに対して、Identity Management サーバーで OTP 設定が有効になっている。管理者およびユーザー自身が、OTP を有効にできる。

    OTP 設定を有効にする場合は、「Web UI でワンタイムパスワードの有効化」を参照してください。

  • 設定された OTP トークンを生成するハードウェアまたはソフトウェアのデバイス

手順

  1. Identity Management ログイン画面で、自身のユーザー名、または IdM サーバー管理者アカウントのユーザー名を入力します。
  2. 上記で入力したユーザーのパスワードを追加します。
  3. デバイスでワンタイムパスワードを生成します。
  4. パスワードの直後にワンタイムパスワードを入力します (空白文字は追加しない)。
  5. Log in をクリックします。

    認証に失敗した場合は、OTP トークンを同期します。

    CA が自己署名証明書を使用する場合は、ブラウザーに警告が表示されます。証明書を確認し、セキュリティー例外を許可して、ログインを続行します。

    IdM Web UI が開かない場合は、Identity Management サーバーの DNS 設定を確認します。

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

Web UI ユーザー

7.6. Web UI で OTP トークンの同期

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

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

前提条件

  • ログイン画面を開いている。
  • 設定した OTP トークンを生成するデバイス。

手順

  1. IdM Web UI ログイン画面で、Sync OTP Token をクリックします。

    Web UI ログインの otp リンク

  2. ログイン画面で、ユーザー名と、Identity Management パスワードを入力します。
  3. ワンタイムパスワードを生成し、First OTP フィールドに入力します。
  4. ワンタイムパスワードをもう一度生成し、Second OTP フィールドに入力します。
  5. 必要に応じて、トークン ID を入力してします。

    Web UI ログインの otp 設定

  6. Sync OTP Token をクリックします。

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

7.7. 期限切れパスワードの変更

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

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

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

前提条件

  • ログイン画面を開いている。
  • IdM サーバーへのアクティブなアカウント。

手順

  1. パスワード有効期限のログイン画面に、ユーザー名を入力します。
  2. 上記で入力したユーザーのパスワードを追加します。
  3. ワンタイムパスワード認証を使用する場合は、OTP フィールドにワンタイムパスワードを生成します。

    OTP 認証を有効にしていない場合は、このフィールドを空白のままにします。

  4. 確認のために新しいパスワードを 2 回入力します。
  5. Reset Password をクリックします。

    Web UI パスワードの有効期限

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

第8章 IdM Web UI でユーザーアカウントの管理

Identity Management (IdM) は、さまざまなユーザーのワークライフ状況を管理するのに役立つ 複数のステージ を提供します。

ユーザーアカウントの作成

従業員が新しい会社で働き始める前に ステージユーザーアカウントを作成 し、従業員の初出勤日に合わせてアカウントをアクティベートできるように準備します。

この手順を省略し、アクティブなユーザーアカウントを直接作成できるようにします。この手順は、ステージユーザーアカウントの作成に類似しています。

ユーザーアカウントをアクティベートする
従業員の最初の就業日に アカウントをアクティベート します。
ユーザーアカウントを無効にする
ユーザーが数か月間育児休暇を取得する場合は、一時的にアカウントを無効にする 必要があります。
ユーザーアカウントを有効にする
ユーザーが戻ってきたら、アカウントを再度有効にする 必要があります。
ユーザーアカウントを保存する
ユーザーが会社を辞める場合は、しばらくしてから会社に戻ってくる可能性を考慮して、アカウントを復元することができる状態で削除する 必要があります。
ユーザーアカウントを復元する
2 年後にユーザーが復職する場合は、保存済みアカウントを復元 する必要があります。
ユーザーアカウントを削除する
その社員を解雇した場合 (戻ってくる可能性がない場合) は、バックアップを行わずに アカウントを削除 します。

8.1. ユーザーのライフサイクル

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

  • ステージ ユーザーは認証できません。これは初期状態です。アクティブユーザーに必要なユーザーアカウントプロパティーをすべて設定できるわけではありません (例: グループメンバーシップ)。
  • アクティブ ユーザーは認証が可能です。必要なユーザーアカウントプロパティーはすべて、この状態で設定する必要があります。
  • 保存済み ユーザーは、非アクティブであると見なされており、IdM に対して認証できないアクティブな以前のユーザーです。保存済みユーザーには、アクティブユーザーのときに有効になっていたアカウントプロパティーの大部分が保持されていますが、ユーザーグループからは除外されています。

IdM ユーザーのライフサイクル

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

重要

削除したユーザーアカウントを復元することはできません。ユーザーアカウントを削除すると、そのアカウントに関連する情報がすべて永続的に失われます。

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

8.2. Web UI でユーザーの追加

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

注記

または、直接、アクティブなユーザーアカウントを作成できます。アクティブユーザーを追加する場合は、以下の手順に従って、アクティブユーザー タブでユーザーアカウントを追加します。

前提条件

  • IdM、またはユーザー管理者ロールを管理する管理者権限

手順

  1. IdM Web UI にログインします。

    詳細は「Web ブラウザーで IdM Web UI へのアクセス」を参照してください。

  2. ユーザー → ステージユーザー タブに移動します。

    または、ユーザー → アクティブユーザー にユーザーアカウントを追加できますが、アカウントにユーザーグループを追加することはできません。

  3. + 追加 アイコンをクリックします。
  4. ステージユーザーの追加 ダイアログボックスで、新規ユーザーの 名前名字 を入力します。
  5. (必要に応じて) ユーザーログイン フィールドにログイン名を追加します。

    空のままにすると、IdM サーバーは、名字の前に、名前の最初の 1 文字が追加された形式で、ログイン名を作成します。ログイン名には、32 文字まで使用できます。

  6. (必要に応じて) GID ドロップダウンメニューで、ユーザーに含まれるグループを選択します。
  7. (必要に応じて) パスワード フィールドおよび パスワードの確認 フィールドに入力します。
  8. 追加 ボタンをクリックします。

    IdM ユーザーがステージを追加

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

IdM ユーザーのステージ

注記

ユーザー名をクリックすると、電話番号、住所、職業の追加などの詳細設定を編集できます。

8.3. IdM Web UI でステージユーザーのアクティベート

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

前提条件

  • IdM Web UI、またはユーザー管理者ロールを管理する管理者権限
  • IdM に、1 つ以上のステージユーザーアカウント

手順

  1. IdM Web UI にログインします。

    詳細は「Web ブラウザーで IdM Web UI へのアクセス」を参照してください。

  2. ユーザー → ステージユーザー タブに移動します。
  3. 有効にするユーザーアカウントのチェックボックスをクリックします。
  4. アクティベート ボタンをクリックします。

    IdM ユーザーのステージ

  5. 確認 ダイアログボックスで、OK ボタンをクリックします。

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

IdM ユーザーのステージがアクティベート

注記

このステージで、アクティブなユーザーアカウントをユーザーグループに追加できます。

8.4. Web UI でユーザーアカウントの無効化

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

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

注記

ユーザーアカウントを無効にした後、既存の接続はユーザーの Kerberos TGT や他のチケットの有効期限が切れるまで有効です。チケットの期限が切れると、ユーザーが更新できなくなります。

前提条件

  • IdM Web UI、またはユーザー管理者ロールを管理する管理者権限

手順

  1. IdM Web UI にログインします。

    詳細は「Web ブラウザーで IdM Web UI へのアクセス」を参照してください。

  2. ユーザー → アクティブユーザー タブに移動します。
  3. 無効にするユーザーアカウントのチェックボックスをクリックします。
  4. 無効 ボタンをクリックします。

    IdM ユーザーの無効化

  5. 確認 ダイアログボックスで、OK ボタンをクリックします。

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

IdM ユーザーが無効化

8.5. Web UI でユーザーアカウントの有効化

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

前提条件

  • IdM Web UI、またはユーザー管理者ロールを管理する管理者権限

手順

  1. IdM Web UI にログインします。
  2. ユーザー → アクティブユーザー タブに移動します。
  3. 有効にするユーザーアカウントのチェックボックスをクリックします。
  4. 有効 ボタンをクリックします。

    IdM ユーザーの無効化

  5. 確認 ダイアログボックスで、OK ボタンをクリックします。

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

8.6. IdM Web UI でアクティブなユーザーの保存

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

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

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

注記

保存済みユーザーの一覧は、以前のユーザーアカウントの履歴を提供します。

前提条件

  • IdM (Identity Management) Web UI、またはユーザー管理者ロールを管理する管理者権限

手順

  1. IdM Web UI にログインします。

    詳細は「Web ブラウザーで IdM Web UI へのアクセス」を参照してください。

  2. ユーザー → アクティブユーザー タブに移動します。
  3. 保存するユーザーアカウントのチェックボックスをクリックします。
  4. 削除 ボタンをクリックします。

    IdM のアクティブユーザーの削除

  5. ユーザーの削除 ダイアログボックスで、削除モード ラジオボタンを、保存 に切り替えます。
  6. 削除 ボタンをクリックします。

    IdM ユーザーの保存

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

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

8.7. IdM Web UI でユーザーの復元

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

前提条件

  • IdM Web UI、またはユーザー管理者ロールを管理する管理者権限

手順

  1. IdM Web UI にログインします。

    詳細は「Web ブラウザーで IdM Web UI へのアクセス」を参照してください。

  2. ユーザー → 保存済みユーザー タブに移動します。
  3. 復元するユーザーアカウントのチェックボックスをクリックします。
  4. 復元 ボタンをクリックします。

    保存済み IdM ユーザーを復元

  5. 確認 ダイアログボックスで、OK ボタンをクリックします。

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

8.8. IdM Web UI でユーザーの削除

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

以下を削除できます。

  • アクティブなユーザー - IdM Web UI では、以下のオプションを利用できます。

  • ステージユーザー - ステージユーザーを永続的に削除できます。
  • 保存済みユーザー - 保存済みユーザーを永続的に削除できます。

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

  • ステージユーザー タブ
  • 保存済みユーザー タブ

前提条件

  • IdM Web UI、またはユーザー管理者ロールを管理する管理者権限

手順

  1. IdM Web UI にログインします。

    詳細は「Web ブラウザーで IdM Web UI へのアクセス」を参照してください。

  2. ユーザー → アクティブユーザー タブに移動します。

    ユーザー → ステージユーザー または ユーザー → 保存済みユーザー でも、ユーザーアカウントを削除できます。

  3. 削除 アイコンをクリックします。
  4. ユーザーの削除 ダイアログボックスで、モードの削除 ラジオボタンを、削除 に切り替えます。
  5. 削除 ボタンをクリックします。

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

第9章 コマンドラインでユーザーアカウントの管理

本章では、IdM (Identity Management) のユーザーライフサイクルに関する基本的な説明を紹介します。以下のセクションでは、次の方法を紹介します。

  • ユーザーアカウントを作成する
  • ステージユーザーアカウントをアクティベートする
  • ユーザーアカウントを保存する
  • アクティブユーザー、ステージユーザー、または保存済みユーザーのアカウントを削除する
  • 保存済みユーザーアカウントの復元

9.1. ユーザーのライフサイクル

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

  • ステージ ユーザーは認証できません。これは初期状態です。アクティブユーザーに必要なユーザーアカウントプロパティーをすべて設定できるわけではありません (例: グループメンバーシップ)。
  • アクティブ ユーザーは認証が可能です。必要なユーザーアカウントプロパティーはすべて、この状態で設定する必要があります。
  • 保存済み ユーザーは、非アクティブであると見なされており、IdM に対して認証できないアクティブな以前のユーザーです。保存済みユーザーには、アクティブユーザーのときに有効になっていたアカウントプロパティーの大部分が保持されていますが、ユーザーグループからは除外されています。

IdM ユーザーのライフサイクル

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

重要

削除したユーザーアカウントを復元することはできません。ユーザーアカウントを削除すると、そのアカウントに関連する情報がすべて永続的に失われます。

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

9.2. コマンドラインでユーザーの追加

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

  • アクティブ - ユーザーがアクティブに使用できるユーザーアカウント
  • ステージ - ユーザーは、このアカウントを使用できません。新規ユーザーアカウントを準備する場合は、このタイプを使用します。ユーザーがアカウントを使用する準備ができると、アクティベートできます。

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

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

注記

IdM は、一意のユーザー ID (UID) を新しいユーザーアカウントに自動的に割り当てます。手動で行うこともできますが、サーバーは UID 番号が一意かどうかを検証しません。このため、複数のユーザーエントリーに同じ ID 番号が割り当てられる可能性があります。Red Hat は、複数のエントリーに同じ UID を割り当てることがないようにすることを推奨します。

前提条件

手順

  1. 端末を開き、IdM サーバーに接続します。
  2. ユーザーのログイン、ユーザーの名前、および名字を追加します。メールアドレスを追加することもできます。

    $ ipa user-add user_login --first=first_name --last=last_name --email=email_address

    IdM は、以下の正規表現で説明できるユーザー名をサポートします。

    [a-zA-Z0-9_.][a-zA-Z0-9_.-]{0,252}[a-zA-Z0-9_.$-]?
    注記

    ユーザー名の末尾がドル記号 ($) で終わる場合は、Samba 3.x マシンでのサポートが有効になります。

    大文字を含むユーザー名を追加すると、IdM が名前を保存する際に自動的に小文字に変換されます。したがって、IdM にログインする場合は、常にユーザー名を小文字で入力する必要があります。また、userUser など、大文字と小文字のみが異なるユーザー名を追加することはできません。

    ユーザー名のデフォルトの長さは、最大 32 文字です。これを変更するには、ipa config-mod --maxusername コマンドを使用します。たとえば、ユーザー名の最大長を 64 文字にするには、次のコマンドを実行します。

    $ ipa config-mod --maxusername=64
     Maximum username length: 64
     ...

    ipa user-add コマンドには、多くのパラメーターが含まれます。一覧を表示するには、ipa help コマンドを使用します。

    $ ipa help user-add

    ipa help コマンドの詳細は、「IPA のヘルプとは」を参照してください。

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

$ ipa $ ipa user-find

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

9.3. コマンドラインでユーザーのアクティベート

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

前提条件

手順

  1. 端末を開き、IdM サーバーに接続します。
  2. 次のコマンドで、ユーザーアカウントをアクティベートします。

    $ ipa stageuser-activate user_login
    -------------------------
    Stage user user_login activated
    -------------------------
    ...

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

$ ipa $ ipa user-find

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

9.4. コマンドラインでユーザーの保存

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

前提条件

手順

  1. 端末を開き、IdM サーバーに接続します。
  2. 次のコマンドで、ユーザーアカウントを保存します。

    $ ipa user-del --preserve user_login
    --------------------
    Deleted user "user_login"
    --------------------

9.5. コマンドラインでユーザーの追加

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

  • アクティブユーザーの場合 - ipa user-del
  • ステージユーザーの場合 - ipa stageuser-del
  • 保存済みユーザーの場合 - ipa user-del

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

$ ipa user-del --continue user1 user2 user3

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

前提条件

手順

  1. 端末を開き、IdM サーバーに接続します。
  2. 次のコマンドで、ユーザーアカウントを削除します。

    $ ipa user-del user_login
    --------------------
    Deleted user "user_login"
    --------------------

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

9.6. コマンドラインでユーザーの復元

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

  • アクティブユーザー - ipa user-undel
  • ステージユーザー - ipa user-stage

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

前提条件

手順

  1. 端末を開き、IdM サーバーに接続します。
  2. 次のコマンドで、ユーザーアカウントをアクティベートします。

    $ ipa user-undel user_login
    ------------------------------
    Undeleted user account "user_login"
    ------------------------------

    または、ユーザーアカウントをステージユーザーとして復元することもできます。

    $ ipa user-stage user_login
    ------------------------------
    Staged user account "user_login"
    ------------------------------

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

$ ipa $ ipa user-find

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

第10章 IdM CLI でのホストの管理

本章では、Identity Management (IdM) の ホスト および ホストエントリー と、IdM CLI でホストとホストエントリーを管理する際に以下の操作が実行されます。

本章には、前提条件、コンテキスト、および操作の結果の 概要表 も含まれています。

10.1. IdM のホスト

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

  • ユーザー
  • サービス
  • ホスト

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

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

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

  • DNS
  • Kerberos
  • 証明書の管理

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

  • サービスエントリーは、ホストに関連付けられています。
  • ホストには、ホストとサービスの両方の Kerberos プリンシパルが格納されます。

10.2. ホスト登録

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

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

  • IdM LDAP でホストエントリーを作成する - 場合によっては、IdM CLI で ipa host-add コマンド、または同等の IdM Web UI 操作 を使用します。
  • ホストで IdM サービス (System Security Services Daemon (SSSD)、Kerberos、certmonger など) を設定し、ホストを IdM ドメインに参加させる。

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

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

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

10.2.1. ホストの登録に必要なユーザー権限

ホスト登録操作では、権限のないユーザーが不要なマシンを IdM ドメインに追加しないように、認証が必要になります。必要な特権は、次のようないくつかの要因によって異なります。

  • ホストエントリーが ipa-client-install の実行とは別に作成される場合
  • ワンタイムパスワード (OTP) が登録に使用される場合
必要に応じて IdM LDAP にホストエントリーを手動で作成するためのユーザー特権

CLI コマンド ipa host-add または IdM Web UI を使用して、IdM LDAP にホストエントリーを作成するのに必要なユーザー特権は ホストの管理者 です。ホスト管理者 の特権は、IT スペシャリスト ロールから取得できます。

クライアントを IdM ドメインに参加させるためのユーザー特権

ホストは、ipa-client-install コマンドの実行時に IdM クライアントとして設定されます。ipa-client-install コマンドの実行に必要な認証情報のレベルは、以下のような登録シナリオのどれに該当するかによって異なります。

登録後、IdM ホストは、IdM リソースにアクセスできるように、新しいセッションをすべて認証します。IdM サーバーがマシンを信頼し、そのマシンにインストールされているクライアントソフトウェアからの IdM 接続を受け入れるには、マシン認証が必要です。クライアントを認証すると、IdM サーバーはそのリクエストに応答できます。

10.2.2. IdM ホストとユーザーの登録と認証: 比較

IdM のユーザーとホストには、多くの類似点があります。本セクションでは、登録ステージで見られるいくつかの類似点と、デプロイメントステージでの認証に関する類似点を説明します。

  • 登録ステージ (表10.1「ユーザーおよびホストの登録」):

    • 管理者は、ユーザーまたはホストが実際に IdM に参加する前に、ユーザーとホストの LDAP エントリーを作成できます。コマンドは、ステージユーザーの場合は ipa stageuser-add で、ホストの場合は ipa host-add です。
    • ホストで ipa-client-install コマンドを実行すると、キーテーブル (または略してキータブ)、(ある程度ユーザーパスワードに類似する) 対称キーを含むファイルが作成され、ホストが IdM レルムに参加します。同様に、ユーザーはアカウントをアクティベートする際にパスワードを作成するように求められ、IdM レルムに参加します。
    • ユーザーパスワードは、ユーザーのデフォルトの認証方法ですが、キータブはホストのデフォルトの認証方法です。キータブは、ホストのファイルに保存されます。

    表10.1 ユーザーおよびホストの登録

    アクションユーザーホスト

    登録前

    $ ipa stageuser-add user_name [--password]

    $ ipa host-add host_name [--random]

    アカウントのアクティブ化

    $ ipa stageuser-activate user_name

    $ ipa-client install [--password] (ホスト自体で実行する必要があります)

  • デプロイメントステージ (表10.2「ユーザーおよびホストセッションの認証」):

    • ユーザーが新しいセッションを開始すると、ユーザーはパスワードを使用して認証を行います。同様に、切り替え時に、ホストがそのキータブファイルを提示して認証を行います。SSSD (System Security Services Daemon) は、このプロセスをバックグラウンドで管理します。
    • 認証が成功すると、ユーザーまたはホストは、Kerberos チケット発行許諾チケット (TGT) を取得します。
    • 次に、TGT を使用して、特定のサービスの特定のチケットを取得します。

    表10.2 ユーザーおよびホストセッションの認証

     ユーザーホスト

    認証のデフォルト手段

    パスワード

    キータブ

    セッションの開始 (通常のユーザー)

    $ kinit user_name

    [ホストへの切り替え]

    認証成功の結果

    TGT は、特定サービスへのアクセスの取得に使用されます。

    TGT は、特定サービスへのアクセスの取得に使用されます。

TGT およびその他の Kerberos チケットは、サーバーにより定義された Kerberos サービスおよびポリシーの一部として生成されます。Kerberos チケットの最初の付与、Kerberos 認証情報の更新、および Kerberos セッションの破棄もすべて IdM サービスにより自動的に処理されます。

10.2.3. IdM ホストの代替認証オプション

キータブとは別に、IdM は、その他の 2 つのタイプのマシン認証にも対応しています。

  • SSH 鍵。ホストの SSH 公開キーが作成され、ホストエントリーにアップロードされます。そこから、SSSD (System Security Services Daemon) は IdM を ID プロバイダーとして使用し、OpenSSH およびその他のサービスと一緒に機能して、IdM の中央にある公開鍵を参照できます。
  • 機械の証明書。この場合、マシンは IdM サーバーの認証局により発行され、IdM の Directory Server に保存されている SSL 証明書を使用します。次に、証明書はマシンに送信され、サーバーに対する認証時に提示されます。クライアントでは、証明書は certmonger というサービスにより管理されます。

10.3. ホスト操作

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

表10.3 ホスト操作パート 1

アクションアクションの前提条件コマンド実行が妥当な時期システム管理者によりアクションの実行方法と実行するコマンド

クライアントの登録

詳細は、『Identity Management のインストール』「Identity Management クライアントをインストールするためのシステムの準備」を参照してください。

ホストが IdM レルムに参加する時

IdM ドメインでマシンをクライアントとして登録する場合は、2 つのプロセスがあります。ipa host-add コマンドを実行すると、クライアントにホストエントリーが作成されて (389 Directory Server インスタンスに格納されます) から、クライアントをプロビジョニングするキータブが作成されます。プロセスは、いずれも ipa-client-install コマンドで自動的に実行されます。この手順は個別に実行することもできます。これにより、管理者は、クライアントを実際に構成する前にマシンと IdM を準備できます。これにより、一括デプロイメントなど、より柔軟な設定シナリオが可能になります。

クライアントの無効化

ホストに、IdM のエントリーが必要です。ホストにはアクティブなキータブが必要です。

(メンテナンス目的などで) IdM レルムからホストを一時的に削除する時

ipa host-disable host_name

クライアントの有効化

ホストに、IdM のエントリーが必要です。

一時的に無効にしたホストが再びアクティブになるようにする時

ipa-getkeytab

クライアントの再登録

ホストに IdM へのエントリーが必要です。

元のホストが失われていて、同じホスト名でホストがインストールされている時

ipa-client-install --keytab または ipa-client-install --force-join

クライアントの登録解除

ホストに、IdM のエントリーが必要です。

IdM レルムからホストを永続的に削除する時

ipa-client-install --uninstall

表10.4 ホスト操作パート 2

アクション管理者はコマンドを実行するマシンアクションの実行時に発生する動作、ホストが IdM で機能する場合の結果、および導入または削除される制限

クライアントの登録

2 ステップでの登録の場合 - ipa host-add は、任意の IdM クライアントで実行できます。ipa-client-install の次のステップは、クライアント自体で実行する必要があります。

デフォルトでは、SSSD が認証と認可のために IdM サーバーに接続するように設定します。必要に応じて、PAM (Pluggable Authentication Module) と NSS (Name Switching Service) を、Kerberos および LDAP を介して IdM サーバーと連携するように設定することができます。

クライアントの無効化

IdM の任意のマシン (ホスト自体も含む)。

ホストの Kerberos 鍵および SSL 証明書が無効にされており、ホストで実行しているすべてのサービスが無効になります。

クライアントの有効化

IdM のマシン。無効なホストで実行する場合は、LDAP 認証情報を提供する必要があります。

ホストの Kerberos 鍵と SSL 証明書が再び有効になり、ホストで実行しているすべての IdM サービスが再度有効になります。

クライアントの再登録

再登録するホスト。LDAP 認証情報を提供する必要があります。

ホスト用に新しい Kerberos キーが生成され、以前のキーが置き換えられます。

クライアントの登録解除

登録解除するホスト。

このコマンドは IdM の設定を解除し、マシンを以前の状態に戻そうとします。このプロセスには、IdM サーバーからホストの登録を解除するステップが含まれます。登録解除には、IdM サーバーでプリンシパルキーを無効にすることで構成されます。/etc/krb5.keytab (host/<fqdn>@REALM) のマシンプリンシパルは、登録解除する IdM サーバーに認証するのに使用されます。このプリンシパルが存在しない場合は登録解除に失敗します。管理者はホストプリンシパル (ipa host-disable <fqdn>) を無効にする必要があります。

10.4. IdM LDAP のホストエントリー

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

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

  • ホストに関連付けられたサービスエントリー
  • ホストとサービスのプリンシパル
  • アクセス制御ルール
  • 物理的な場所やオペレーティングシステムなどのマシン情報
注記

IdM Web UI の IdentityHosts タブには、IdM LDAP に保存されている特定のホストに関する情報がすべて表示されないことに注意してください。

10.4.1. ホストエントリー設定プロパティー

ホストエントリーには、ホストに関する情報 (物理的な場所、MACアドレス、鍵、証明書など、システム設定を除く) を含めることができます。

この情報は、ホストエントリーが手動で作成された場合に、作成時に設定できます。また、この情報のほとんどは、ホストがそのドメインに登録してからホストエントリーに追加できます。

表10.5 ホスト設定プロパティー

UI フィールドコマンドラインオプション説明

説明

--desc=description

ホストの説明。

局所性

--locality=locality

ホストの地理的な場所。

場所

--location=location

データセンターのラックなど、ホストの物理的な場所。

プラットフォーム

--platform=string

ホストのハードウェアまたはアーキテクチャー。

オペレーティングシステム

--os=string

ホストのオペレーティングシステムとバージョン。

MAC アドレス

--macaddress=address

ホストの MAC アドレス。これは多値属性です。MAC アドレスは、NIS プラグインにより、ホスト用の NIS の ethers マップを作成するために使用されます。

SSH 公開鍵

--sshpubkey=string

ホストの完全 SSH 公開鍵。これは複数値の属性であるため、複数の鍵を設定できます。

プリンシパル名 (編集不可)

--principalname=principal

ホストの Kerberos プリンシパル名。-p に別のプリンシパルを明示的に設定しない限り、クライアントのインストール時にホスト名がデフォルトになります。これはコマンドラインツールを使用して変更できますが、UI で変更することはできません。

ワンタイムパスワードの設定

--password=string

このオプションは、一括登録で使用できるホストのパスワードを設定します。

-

--random

このオプションは、一括登録で使用されるランダムパスワードを生成します。

-

--certificate=string

ホストの証明書ブロブ。

-

--updatedns

これにより、IP アドレスが変更した場合に、ホストが DNS エントリーを動的に更新できるかどうかが設定されます。

10.5. IdM CLI で IdM ホストエントリーの追加

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

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

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

  • 最も基本的な方法として、クライアントホスト名を指定してクライアントを Kerberos レルムに追加し、IdM LDAP サーバーにエントリーを作成します。

    $ ipa host-add client1.example.com
  • DNS を管理するために IdM サーバーを設定している場合は、--ip-address オプションを使用して DNS リソースレコードにホストを追加します。

    例10.1 静的 IP アドレスを持つホストエントリーの作成

    $ ipa host-add --ip-address=192.168.166.31 client1.example.com
  • 追加するホストに静的 IP アドレスがない場合や、クライアントの設定時に IP アドレスが不明な場合は、ipa host-add コマンドで --force オプションを使用します。

    例10.2 DHCP でホストエントリーの作成

    $ ipa host-add --force client1.example.com

    たとえば、ラップトップは IdM クライアントとして事前設定されている場合がありますが、設定時には IP アドレスがありません。--force を使用すると、基本的に IdM DNS サービスにプレースホルダーエントリーが作成されます。DNS サービスがレコードを動的に更新すると、ホストの現在の IP アドレスが検出され、DNS レコードが更新されます。

10.6. IdM CLI でホストエントリーの削除

  • host-del コマンドを使用して、ホストレコードを削除します。IdM ドメインに DNS が統合されている場合は、--updatedns オプションを使用して、あらゆる種類のホストに関連するレコードを DNS から削除します。

    $ ipa host-del --updatedns client1.example.com

10.7. Identity Management クライアントの再登録

10.7.1. IdM でクライアントの再登録

本セクションでは、Identity Management (IdM) クライアントを再登録する方法を説明します。

クライアントのハードウェア障害などの理由で、クライアントマシンが破壊され、IdM サーバーとの接続が失われた場合は、キータブがあればクライアントを再登録できます。この場合、同じホスト名でクライアントを IdM 環境に戻します。

再登録の間、クライアントは新しい Kerberos キーと SSH キーを生成しますが、LDAP データベースのクライアントのアイデンティティーは変更されません。再登録後、ホストは、IdM サーバーとの接続を失う前と同じ FQDN を持つ同じ LDAP オブジェクトに、キーとその他の情報を保持します。

重要

ドメインエントリーがアクティブなクライアントのみを再登録できます。クライアントをアンインストール (ipa-client-install --uninstall を使用) した場合や、ホストエントリーを無効 (ipa host-disable を使用) にした場合は再登録できません。

クライアントの名前を変更すると、再登録することができません。これは、Identity Management では LDAP にあるクライアントのエントリーのキー属性はクライアントのホスト名 FQDN であるためです。クライアントの再登録中はクライアントの LDAP オブジェクトは変更されませんが、クライアントの名前を変更すると、クライアントの鍵とその他の情報は新しい FQDN を持つ異なる LDAP オブジェクトに格納されます。そのため、IdM からホストをアンインストールし、ホストのホスト名を変更して、新しい名前で IdM クライアントとしてインストールするのが、クライアントの名前を変更する唯一の方法です。クライアントの名前を変更する方法は、「Identity Management クライアントシステムの名前変更」を参照してください。

10.7.1.1. クライアント再登録中に行われること

Identity Management は再登録中に以下を行います。

  • 元のホスト証明書を破棄します。
  • 新規の SSH 鍵を作成します。
  • 新規のキータブを生成します。

10.7.2. ユーザー認証情報でクライアントの再登録: 対話的な再登録

この手順では、権限のあるユーザーの認証情報を使用して、Identity Management クライアントを対話的に再登録する方法を説明します。

  1. 同じホスト名のクライアントマシンを再作成します。
  2. クライアントマシンで ipa-client-install --force-join コマンドを実行します。

    # ipa-client-install --force-join
  3. スクリプトにより、アイデンティティーがクライアントの再登録に使用されるユーザーの入力が求められます。たとえば、登録監理者 (Enrollment Administrator) ロールを持つ hostadmin ユーザーなどが該当します。

    User authorized to enroll computers: hostadmin
    Password for hostadmin@EXAMPLE.COM:

関連情報

10.7.3. クライアントのキータブでクライアントの再登録: 非対話的な再登録

前提条件

  • /tmp/root などのディレクトリーに元のクライアントキータブファイルをバックアップします。

手順

この手順では、クライアントシステムのキータブファイルを使用して、Identity Management クライアントを非対話的に再登録する方法を説明します。たとえば、クライアントのキータブを使用した再登録は自動インストールに適しています。

  1. 同じホスト名のクライアントマシンを再作成します。
  2. キータブファイルをバックアップした場所から再作成したクライアントマシンの /etc/ ディレクトリーにコピーします。
  3. ipa-client-install ユーティリティーを使用してクライアントを再登録し、--keytab オプションでキータブの場所を指定します。

    # ipa-client-install --keytab /etc/krb5.keytab
    注記

    登録を開始するために認証する場合は、--keytab オプションで指定するキータブのみが使用されます。再登録中、IdM はクライアントに対して新しいキータブを生成します。

10.7.4. インストール後の Identity Management クライアントのテスト

コマンドラインインターフェースにより、ipa-client-install が正常に実行されたことが通知されますが、独自のテストを行うこともできます。

Identity Management クライアントが、サーバー上で定義されたユーザーに関する情報を取得できることをテストするには、サーバー上で定義されたユーザーを解決できることをチェックします。たとえば、デフォルトの admin ユーザーをチェックするには、以下を実行します。

[user@client1 ~]$ id admin
uid=1254400000(admin) gid=1254400000(admins) groups=1254400000(admins)

認証が適切に機能することをテストするには、別の IdM ユーザーで su - を実行します。

[user@client1 ~]$ su - idm_user
Last login: Thu Oct 18 18:39:11 CEST 2018 from 192.168.122.1 on pts/0
[idm_user@client1 ~]$

10.8. Identity Management クライアントシステムの名前変更

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

警告

クライアントの名前は手動で変更します。ホスト名の変更が絶対に必要である場合のみ実行してください。

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

  1. ホストを準備します。詳細は「前提条件」を参照してください。
  2. ホストから IdM クライアントをアンインストールします。詳細は「Identity Management クライアントのアンインストール」を参照してください。
  3. ホストの名前を変更します。詳細は「ホストシステムの名前変更」を参照してください。
  4. 新しい名前でホストに IdM クライアントをインストールします。詳細は「Identity Management クライアントの再インストール」を参照してください。
  5. IdM クライアントのインストール後にホストを設定します。詳細は「サービスの再追加、証明書の再生成、およびホストグループの再追加」を参照してください。

10.8.1. 前提条件

現在のクライアントをアンインストールする前に、クライアントの設定を書き留めます。新しいホスト名のマシンを再登録した後にこの設定を適用します

  • マシンで実行されているサービスを特定します。

    • ipa service-find コマンドを使用して、証明書のあるサービスを特定して出力します。

      $ ipa service-find old-client-name.example.com
    • さらに、各ホストには ipa service-find の出力に表示されないデフォルトの host service があります。ホストサービスのサービスプリンシパルは ホストプリンシパル とも呼ばれ、host/old-client-name.example.com になります。
  • ipa service-find old-client-name.example.com により表示されるすべてのサービスプリンシパルは、old-client-name.example.com 上の対応するキータブの場所を決定します。

    # find / -name "*.keytab"

    クライアントシステムの各サービスには、ldap/old-client-name.example.com@EXAMPLE.COM のように service_name/host_name@REALM の形式を取る Kerberos プリンシパルがあります。

  • マシンが所属するすべてのホストグループを特定します。

    # ipa hostgroup-find old-client-name.example.com

10.8.2. Identity Management クライアントのアンインストール

クライアントをアンインストールすると、クライアントは Identity Management ドメインから削除され、SSSD (System Security Services Daemon) などのシステムサービスの Identity Management 設定もすべて削除されます。これにより、クライアントシステムの以前の設定が復元します。

手順

  1. ipa-client-install --uninstall コマンドを実行します。

    [root@client]# ipa-client-install --uninstall
  2. クライアントホストの DNS エントリーを、手動でサーバーから削除します。

    [root@server]# ipa dnsrecord-del
    Record name: old-client-client
    Zone name: idm.example.com
    No option to delete specific record provided.
    Delete all? Yes/No (default No): yes
    ------------------------
    Deleted record "old-client-name"
  3. /etc/krb5.keytab 以外のキータブについては、古いプリンシパルを削除します。

    [root@client ~]# ipa-rmkeytab -k /path/to/keytab -r EXAMPLE.COM
  4. IdM サーバーで、ホストエントリーを削除します。これにより、すべてのサービスが削除され、そのホストに発行されたすべての証明書が無効になります。

    [root@server ~]# ipa host-del client.example.com

10.8.3. ホストシステムの名前変更

必要に応じてマシンの名前を変更します。以下に例を示します。

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

これで、新しいホスト名で、Identity Management クライアントを Identity Management ドメインに再インストールできるようになります。

10.8.4. Identity Management クライアントの再インストール

『Identity Management のインストール』「Identity Management クライアントのインストール: 基本的なシナリオ」で説明されている手順に従って、名前を変更したホストにクライアントをインストールします。

10.8.5. サービスの再追加、証明書の再生成、およびホストグループの再追加

  1. Identity Management サーバーで、「前提条件」に定義された各サービスに新しいキータブを追加します。

    [root@server ~]# ipa service-add service_name/new-client-name
  2. 「前提条件」で割り当てた証明書のあるサービスに対して証明書を生成します。これには、以下を行います。

    • Identity Management の管理ツールを使用
    • certmonger ユーティリティーを使用
  3. 「前提条件」で特定されたホストグループにクライアントを再追加します。

10.9. ホストエントリーの無効化と再有効化

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

10.9.1. ホストの無効化

IdM でホストエントリーを無効にするには、この手順を完了します。

ドメインサービス、ホスト、およびユーザーはアクティブなホストにアクセスできます。メンテナンス上の理由などで、アクティブなホストを一時的に削除することが必要になる場合があります。このような状況でホストを削除すると、ホストエントリーと、関連するすべての設定が完全に削除されるため、望ましくありません。代わりに、ホストを無効にするオプションを選択してください。

ホストを無効にすると、ドメインからドメインユーザーを永続的に削除せずに、そのドメインにアクセスできなくなります。これには、host-disable コマンドを使用します。ホストを無効にすると、ホストで現在アクティブなキータブが強制終了します。

以下に例を示します。

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

ホストを無効にすると、ホストはすべての IdM ユーザー、ホスト、およびサービスが利用できなくなりました。

重要

ホストエントリーを無効にすると、そのホストが無効になるだけではありません。そのホストで設定されているすべてのサービスも無効にします。

10.9.2. ホストの再有効化

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

ホストを無効にすると、アクティブなキータブが強制的に終了し、設定エントリーを変更せずにホストが IdM ドメインから削除されます。

ホストを再度有効にするには、以下を追加して、ipa-getkeytab コマンドを使用します。

  • キータブを要求する IdM サーバーを指定する -s オプション
  • プリンシパル名を指定する -p オプション
  • キータブを保存するファイルを指定する -k オプション

たとえば、client.example.comserver.example.com から新規ホストキータブを要求し、キータブを /etc/krb5.keytab ファイルに保存するには、次のコマンドを実行します。

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

管理者の認証情報を使用して、-D "uid=admin,cn=users,cn=accounts,dc=example,dc=com" を指定することもできます。認証情報は、ホストのキータブの作成を許可されたユーザーに対応することが重要です。

ipa-getkeytab コマンドがアクティブな IdM クライアントまたはサーバーで実行する場合は、ユーザーが、kinit admin などを使用して TGT を取得した場合に、LDAP 認証情報 (-D および -w) を使用せずに実行できます。無効化されたホストでコマンドを直接実行するには、LDAP 認証情報を提供して IdM サーバーに認証します。

第11章 IdM Web UI でホストエントリーの追加

この章では、Identity Management (IdM) のホストと、IdM Web UI でホストエントリーを追加する操作を説明します。

11.1. IdM のホスト

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

  • ユーザー
  • サービス
  • ホスト

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

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

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

  • DNS
  • Kerberos
  • 証明書の管理

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

  • サービスエントリーは、ホストに関連付けられています。
  • ホストには、ホストとサービスの両方の Kerberos プリンシパルが格納されます。

11.2. ホスト登録

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

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

  • IdM LDAP でホストエントリーを作成する - 場合によっては、IdM CLI で ipa host-add コマンド、または同等の IdM Web UI 操作 を使用します。
  • ホストで IdM サービス (System Security Services Daemon (SSSD)、Kerberos、certmonger など) を設定し、ホストを IdM ドメインに参加させる。

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

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

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

11.2.1. ホストの登録に必要なユーザー権限

ホスト登録操作では、権限のないユーザーが不要なマシンを IdM ドメインに追加しないように、認証が必要になります。必要な特権は、次のようないくつかの要因によって異なります。

  • ホストエントリーが ipa-client-install の実行とは別に作成される場合
  • ワンタイムパスワード (OTP) が登録に使用される場合
必要に応じて IdM LDAP にホストエントリーを手動で作成するためのユーザー特権

CLI コマンド ipa host-add または IdM Web UI を使用して、IdM LDAP にホストエントリーを作成するのに必要なユーザー特権は ホストの管理者 です。ホスト管理者 の特権は、IT スペシャリスト ロールから取得できます。

クライアントを IdM ドメインに参加させるためのユーザー特権

ホストは、ipa-client-install コマンドの実行時に IdM クライアントとして設定されます。ipa-client-install コマンドの実行に必要な認証情報のレベルは、以下のような登録シナリオのどれに該当するかによって異なります。

登録後、IdM ホストは、IdM リソースにアクセスできるように、新しいセッションをすべて認証します。IdM サーバーがマシンを信頼し、そのマシンにインストールされているクライアントソフトウェアからの IdM 接続を受け入れるには、マシン認証が必要です。クライアントを認証すると、IdM サーバーはそのリクエストに応答できます。

11.2.2. IdM ホストとユーザーの登録と認証: 比較

IdM のユーザーとホストには、多くの類似点があります。本セクションでは、登録ステージで見られるいくつかの類似点と、デプロイメントステージでの認証に関する類似点を説明します。

  • 登録ステージ (表11.1「ユーザーおよびホストの登録」):

    • 管理者は、ユーザーまたはホストが実際に IdM に参加する前に、ユーザーとホストの LDAP エントリーを作成できます。コマンドは、ステージユーザーの場合は ipa stageuser-add で、ホストの場合は ipa host-add です。
    • ホストで ipa-client-install コマンドを実行すると、キーテーブル (または略してキータブ)、(ある程度ユーザーパスワードに類似する) 対称キーを含むファイルが作成され、ホストが IdM レルムに参加します。同様に、ユーザーはアカウントをアクティベートする際にパスワードを作成するように求められ、IdM レルムに参加します。
    • ユーザーパスワードは、ユーザーのデフォルトの認証方法ですが、キータブはホストのデフォルトの認証方法です。キータブは、ホストのファイルに保存されます。

    表11.1 ユーザーおよびホストの登録

    アクションユーザーホスト

    登録前

    $ ipa stageuser-add user_name [--password]

    $ ipa host-add host_name [--random]

    アカウントのアクティブ化

    $ ipa stageuser-activate user_name

    $ ipa-client install [--password] (ホスト自体で実行する必要があります)

  • デプロイメントステージ (表11.2「ユーザーおよびホストセッションの認証」):

    • ユーザーが新しいセッションを開始すると、ユーザーはパスワードを使用して認証を行います。同様に、切り替え時に、ホストがそのキータブファイルを提示して認証を行います。SSSD (System Security Services Daemon) は、このプロセスをバックグラウンドで管理します。
    • 認証が成功すると、ユーザーまたはホストは、Kerberos チケット発行許諾チケット (TGT) を取得します。
    • 次に、TGT を使用して、特定のサービスの特定のチケットを取得します。

    表11.2 ユーザーおよびホストセッションの認証

     ユーザーホスト

    認証のデフォルト手段

    パスワード

    キータブ

    セッションの開始 (通常のユーザー)

    $ kinit user_name

    [ホストへの切り替え]

    認証成功の結果

    TGT は、特定サービスへのアクセスの取得に使用されます。

    TGT は、特定サービスへのアクセスの取得に使用されます。

TGT およびその他の Kerberos チケットは、サーバーにより定義された Kerberos サービスおよびポリシーの一部として生成されます。Kerberos チケットの最初の付与、Kerberos 認証情報の更新、および Kerberos セッションの破棄もすべて IdM サービスにより自動的に処理されます。

11.2.3. IdM ホストの代替認証オプション

キータブとは別に、IdM は、その他の 2 つのタイプのマシン認証にも対応しています。

  • SSH 鍵。ホストの SSH 公開キーが作成され、ホストエントリーにアップロードされます。そこから、SSSD (System Security Services Daemon) は IdM を ID プロバイダーとして使用し、OpenSSH およびその他のサービスと一緒に機能して、IdM の中央にある公開鍵を参照できます。
  • 機械の証明書。この場合、マシンは IdM サーバーの認証局により発行され、IdM の Directory Server に保存されている SSL 証明書を使用します。次に、証明書はマシンに送信され、サーバーに対する認証時に提示されます。クライアントでは、証明書は certmonger というサービスにより管理されます。

11.3. IdM LDAP のホストエントリー

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

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

  • ホストに関連付けられたサービスエントリー
  • ホストとサービスのプリンシパル
  • アクセス制御ルール
  • 物理的な場所やオペレーティングシステムなどのマシン情報
注記

IdM Web UI の IdentityHosts タブには、IdM LDAP に保存されている特定のホストに関する情報がすべて表示されないことに注意してください。

11.3.1. ホストエントリー設定プロパティー

ホストエントリーには、ホストに関する情報 (物理的な場所、MACアドレス、鍵、証明書など、システム設定を除く) を含めることができます。

この情報は、ホストエントリーが手動で作成された場合に、作成時に設定できます。また、この情報のほとんどは、ホストがそのドメインに登録してからホストエントリーに追加できます。

表11.3 ホスト設定プロパティー

UI フィールドコマンドラインオプション説明

説明

--desc=description

ホストの説明。

局所性

--locality=locality

ホストの地理的な場所。

場所

--location=location

データセンターのラックなど、ホストの物理的な場所。

プラットフォーム

--platform=string

ホストのハードウェアまたはアーキテクチャー。

オペレーティングシステム

--os=string

ホストのオペレーティングシステムとバージョン。

MAC アドレス

--macaddress=address

ホストの MAC アドレス。これは多値属性です。MAC アドレスは、NIS プラグインにより、ホスト用の NIS の ethers マップを作成するために使用されます。

SSH 公開鍵

--sshpubkey=string

ホストの完全 SSH 公開鍵。これは複数値の属性であるため、複数の鍵を設定できます。

プリンシパル名 (編集不可)

--principalname=principal

ホストの Kerberos プリンシパル名。-p に別のプリンシパルを明示的に設定しない限り、クライアントのインストール時にホスト名がデフォルトになります。これはコマンドラインツールを使用して変更できますが、UI で変更することはできません。

ワンタイムパスワードの設定

--password=string

このオプションは、一括登録で使用できるホストのパスワードを設定します。

-

--random

このオプションは、一括登録で使用されるランダムパスワードを生成します。

-

--certificate=string

ホストの証明書ブロブ。

-

--updatedns

これにより、IP アドレスが変更した場合に、ホストが DNS エントリーを動的に更新できるかどうかが設定されます。

11.4. Web UI でホストエントリーの追加

  1. Identity タブを開き、サブタブの ホスト を選択します。
  2. ホスト一覧の上部にある 追加 をクリックします。

    図11.1 ホストエントリーの追加

    hosts list
  3. マシンの名前を入力し、ドロップダウンリストで、設定済みのゾーンの中からドメインを選択します。ホストに静的 IP アドレスが割り当てられている場合は、ホストエントリーにそのアドレスを追加して、DNS エントリーが完全に作成されるようにします。

    Class フィールドには、現時点では特定の目的はありません。

    図11.2 ホストウィザードの追加

    host add

    DNS ゾーンは IdM で作成できます。IdM サーバーが DNS サーバーを管理しない場合は、通常のテキストフィールドなど、メニューエリアでゾーンを手動で入力できます。

    注記

    ホストが DNS 経由で解決できるかどうかの確認を行わないようにするには、強制 チェックボックスを選択します。

  4. 追加および編集 ボタンをクリックして、拡張されたエントリーページに直接選択し、その他の属性情報を入力します。ホストのハードウェアと物理的な場所に関する情報は、ホストエントリーに追加できます。

    図11.3 拡張されたエントリーページ

    host attr

第12章 Identity Management の公開鍵証明書

この章では、Identity Management (IdM) で、ユーザー、ホスト、およびサービスを認証するのに使用する X.509 公開鍵証明書を紹介します。X.509 証明書は、認証のほかに、デジタル署名と暗号化も可能にし、プライバシー、完全性、否認不可を実現します。

証明書には、以下の情報が含まれます。

  • 証明書が認証する発行先
  • 証明書に署名 (検証) した人、つまり発行者
  • 証明書の有効性の開始と終了
  • 証明書の有効な用途
  • 発行先の公開鍵

公開鍵により暗号化したメッセージは、対応した秘密鍵により複号できます。証明書と、それに含まれる公開鍵は、自由に利用できるようにできますが、ユーザー、ホスト、またはマシンは、その秘密鍵を秘密にしておく必要があります。

12.1. IdM の認証局

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

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

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

  • デジタル証明書を発効し、検証する。
  • 証明書に署名して、証明書がそれを提示するユーザー、ホスト、またはサービスに属することを証明する。
  • 内部 CA を使用する IdM 環境では、証明書の更新マスターであり、証明書失効リスト (CRL) を維持する CA が最高権限となる。

12.2. 証明書および Kerberos の比較

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

表12.1 証明書および Kerberos の比較

特徴

Kerberos

X.509

認証

はい

はい

プライバシー

任意

はい

インテグリティー

任意

はい

関係する暗号の種類

対称

非対称

デフォルトの有効性

短い (1 日)

長い (2 年)

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

12.3. IdM でユーザーを認証する証明書を使用する利点と問題点

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

  • 通常、スマートカードの秘密鍵を保護する PIN は、通常のパスワードよりも簡単で覚えやすいものになります。
  • デバイスによっては、スマートカードに保存されている秘密鍵をエクスポートできません。これによりセキュリティーが強化されます。
  • スマートカードはログアウトを自動化できます。IdM は、ユーザーがリーダーからスマートカードを取り外すと、ユーザーをログアウトするように設定できます。
  • 秘密鍵を盗むには、スマートカードへの物理的なアクセスが必要で、スマートカードはハッキング攻撃に対して安全になります。
  • スマートカード認証は 2 要素認証です。つまり、所有しているもの (カード) と、知っているもの (PIN) の両方が必要です。
  • スマートカードは、電子メールの暗号化など、他の目的に使用できる鍵を提供するため、パスワードよりも柔軟性があります。
  • IdM クライアントである共有マシンでスマートカードを使用しても、通常、システム管理者に対して追加で発生する問題はありません。実際、スマートカード認証は共有マシンにとって理想的な選択肢です。

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

  • スマートカードまたは証明書を紛失したり忘れることで、実質的にロックアウトされる可能性があります。
  • PIN を複数回誤入力すると、カードがロックされる可能性があります。
  • 一般に、セキュリティー担当者や承認者などによる要求と承認の間には中間ステップがあります。セキュリティー担当者または管理者が、IdM で ipa cert-request コマンドを実行する必要があります。
  • スマートカードとリーダーは、ベンダーとドライバーに固有である傾向があります。多くのリーダーはさまざまなカードに使用できますが、一部のベンダーのスマートカードは、別のベンダーのリーダーや、その目的で設計されていないリーダーでは機能しない場合があります。
  • 証明書とスマートカードの学習曲線は、この分野の経験がない場合には困難に聞こえるかもしれません。

第13章 IdM と機能する証明書形式への変換

このユーザーストーリーでは、IdM システム管理者が、特定の IdM コマンドで証明書の正しい形式を使用するようにする方法を説明します。これは、たとえば以下の状況で役に立ちます。

13.1. 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 および .cerDER 証明書が含まれることもあります。鍵を含む DER ファイルの名前は .key です。

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

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

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

エンコーディング形式人間が判別可能一般的なファイル名の拡張子エンコーディング形式を使用できる IdM コマンドの例

PEM/base64

はい

.pem、.crt、.cer

ipa user-add-cert、ipa-server-certinstall など

DER

いいえ

.der、.crt、.cer

ipa-server-certinstall など

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

ユーザー認証

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

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

  • ユーザーは、kinit -X コマンドの X509_user_identity パラメーターの値として、証明書と鍵の両方が含まれるスマートカードに接続するスマートカードモジュールへのパスを追加します。

    $ kinit -X X509_user_identity='PKCS11:opensc-pkcs11.so' idm_user
  • ユーザーは、kinit -X コマンドの X509_user_identity パラメーターの値として、証明書が含まれるファイルと、秘密鍵が含まれるファイルの 2 つを追加します。

    $ kinit -X X509_user_identity='FILE:`/path/to/cert.pem,/path/to/cert.key`' idm_user

便利な証明書コマンド

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

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

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

$ diff cert1.crt cert2.crt

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

$ diff cert1.crt cert2.crt -y

13.2. IdM ユーザーアカウントに読み込む外部証明書の変換

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

前提条件

  • 証明書が Active Directory 認証局によって発行され、PEM エンコーディングを使用する場合は、PEM ファイルが UNIX 形式に変換されていることを確認します。ファイルを変換するには、dos2unix パッケージが提供する dos2unix ユーティリティーを使用します。

13.2.1. IdM CLI での外部証明書の変換および IdM ユーザーアカウントへの読み込み

IdM CLI では、最初の行および最後の行 (-----BEGIN CERTIFICATE----- および -----END CERTIFICATE-----) が削除された PEM 証明書のみが使用できます。

手順

  1. 証明書を PEM 形式に変換します。

    • 証明書が DER 形式の場合は、次のようになります。

      $ openssl x509 -in cert.crt -inform der -outform pem -out cert.pem
    • ファイルが PKCS #12 形式で、共通のファイル名の拡張子が .pfx および .p12 で、証明書、秘密鍵、およびその他のデータが含まれている場合は、openssl pkcs12 ユーティリティーを使用して証明書を展開します。プロンプトが表示されたら、そのファイルに保存されている秘密鍵をパスワードで保護します。

      $ openssl pkcs12 -in cert_and_key.p12 -clcerts -nokeys -out cert.pem
      Enter Import Password:
  2. 管理者の認証情報を取得します。

    $ kinit admin
  3. 以下のいずれかの方法で、IdM CLI を使用して証明書をユーザーアカウントに追加します。

    • 文字列を ipa user-add-cert コマンドに追加する前に、sed ユーティリティーを使用して PEM ファイルの最初の行および最後の行 (-----BEGIN CERTIFICATE----- および -----END CERTIFICATE-----) を削除します。

      $ ipa user-add-cert some_user --certificate="$(sed -e '/BEGIN CERTIFICATE/d;/END CERTIFICATE/d' cert.pem)"
    • 最初の行と最後の行(-----BEGIN CERTIFICATE----- および -----END CERTIFICATE-----) がない証明書ファイルのコンテンツを、ipa user-add-cert コマンドにコピーして貼り付けます。

      $ ipa user-add-cert some_user --certificate=MIIDlzCCAn+gAwIBAgIBATANBgkqhki...
      注記

      最初の行および最後の行 (-----BEGIN CERTIFICATE----- および -----END CERTIFICATE-----) を削除せずに、直接証明書を含む PEM ファイルを、ipa user-add-cert コマンドへの入力として直接渡すことはできません。

      $ ipa user-add-cert some_user --cert=some_user_cert.pem

      このコマンドの結果、「ipa: ERROR: Base64 decoding failed: Incorrect padding」エラーメッセージが表示されます。

  4. 必要に応じて、システムで証明書が許可されているかどうかを確認するには、次のコマンドを実行します。

    [idm_user@r8server]$ ipa user-show some_user

13.2.2. IdM ユーザーアカウントに読み込むために、IdM Web UI の外部証明書を変換

手順

  1. CLI を使用して、証明書を PEM 形式に変換します。

    • 証明書が DER 形式の場合は、次のようになります。

      $ openssl x509 -in cert.crt -inform der -outform pem -out cert.pem
    • ファイルが PKCS #12 形式で、共通のファイル名の拡張子が .pfx および .p12 で、証明書、秘密鍵、およびその他のデータが含まれている場合は、openssl pkcs12 ユーティリティーを使用して証明書を展開します。プロンプトが表示されたら、そのファイルに保存されている秘密鍵をパスワードで保護します。

      $ openssl pkcs12 -in cert_and_key.p12 -clcerts -nokeys -out cert.pem
      Enter Import Password:
  2. エディターで証明書を開き、コンテンツをコピーします。IdM Web UI には PEM 形式および base64 形式が使用できるため、ヘッダー行「-----BEGIN CERTIFICATE-----」およびフッター行「-----END CERTIFICATE-----」を含めることができます。
  3. IdM Web UI で、セキュリティー担当者としてログインします。
  4. IdentityUserssome_user の順に選択します。
  5. 証明書 の横にある 追加 をクリックします。
  6. 表示されるウインドウに、PEM 形式のコンテンツを貼り付けます。
  7. Add をクリックします。

証明書がシステムに受け入れられる場合は、ユーザープロファイルの 証明書 間で一覧に表示されるのを確認できます。

13.3. 証明書をブラウザーに読み込むための準備

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

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

13.3.1. NSS データベースから PKCS #12 ファイルへの証明書と秘密鍵のエクスポート

手順

  1. 証明書を、NSS データベースから PKCS12 形式にエクスポートするには、pk12util コマンドを使用します。たとえば、~/certdb ディレクトリーに保存されている NSS データベースから、~/some_user.p12 ファイルに、some_user ニックネームを持つ証明書をエクスポートする場合は、次のコマンドを実行します。

    $ pk12util -d ~/certdb -o ~/some_user.p12 -n some_user
    Enter Password or Pin for "NSS Certificate DB":
    Enter password for PKCS12 file:
    Re-enter password:
    pk12util: PKCS12 EXPORT SUCCESSFUL
  2. .p12 ファイルに適切なパーミッションを設定します。

    # chmod 600 ~/some_user.p12

    PKCS #12 ファイルには秘密鍵も含まれるため、その他のユーザーがファイルを使用できないように保護する必要があります。それ以外の場合は、ユーザー権限になりすますことができます。

13.3.2. 証明書と秘密鍵の PEM ファイルを PKCS #12 ファイルに統合

このセクションでは、個別の PEM ファイルに保存されている証明書、および対応する鍵を、PKCS #12 ファイルに統合する方法を説明します。

手順

  • certfile.cer に保存されている証明書と、certfile.key に保存されている鍵を、証明書および鍵の両方が含まれる certfile.p12 ファイルに追加します。

    $ openssl pkcs12 -export -in certfile.cer -inkey certfile.key -out certfile.p12

13.4. IdM における証明書関連のコマンドおよび形式

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

表13.2 IdM 証明書コマンドおよび形式

コマンド使用できる形式備考

ipa user-add-cert some_user --certificate

base64 PEM 証明書

 

ipa-server-certinstall

PEM および DER 証明書、PKCS#7 証明書チェーン、PKCS#8 および生の秘密鍵、PKCS#12 証明書および秘密鍵

 

ipa-cacert-manage install

DER、PEM、PKCS#7

 

ipa-cacert-manage renew --external-cert-file

PEM および DER 証明書、PKCS#7 証明書チェーン

 

ipa-ca-install --external-cert-file

PEM および DER 証明書、PKCS#7 証明書チェーン

 

ipa cert-show <cert serial> --certificate-out /path/to/file.pem

該当なし

<cert_serial> シリアル番号がある証明書で、PEM でエンコードされた file.pem ファイルを作成します。

ipa cert-show <cert serial> --certificate-out /path/to/file.pem

該当なし

<cert_serial> シリアル番号がある証明書で、PEM でエンコードされた file.pem ファイルを作成します。--chain オプションを使用すると、PEM ファイルに、証明書チェーンを含む証明書が含まれます。

ipa cert-request --certificate-out=FILE /path/to/req.csr

該当なし

新しい証明書で、PEM 形式の req.csr ファイルを作成します。

ipa cert-request --certificate-out=FILE /path/to/req.csr

該当なし

新しい証明書で、PEM 形式の req.csr ファイルを作成します。--chain オプションを使用すると、PEM ファイルに、証明書チェーンを含む証明書が含まれます。

第14章 スマートカード認証用の Identity Management の設定

スマートカードに基づいた認証は、パスワードの代替手段です。ユーザー認証情報は、秘密鍵と証明書の形式でスマートカードに格納され、特別なソフトウェアやハードウェアを使用してその鍵にアクセスします。ユーザーは、スマートカードをリーダーまたは USB ソケットに配置し、ログインやパスワードを提供する代わりに、スマートカードの PIN コードを提示します。

Identity Management (IdM) では、以下によるスマートカード認証に対応しています。

  • IdM 認証局が発行するユーザー証明書
  • 外部認証局が発行するユーザー証明書

このユーザーストーリーでは、両方のタイプの証明書に対して、IdM でスマートカード認証を設定する方法を説明します。ユーザーストーリーでは、smartcard_ca.pem CA 証明書は、信頼された外部の認証局の証明書を含むファイルです。

ユーザーストーリーには次のようなモジュールが含まれています。

「スマートカード認証用の IdM サーバーの設定」

「スマートカード認証用の IdM クライアントの設定」

「IdM のユーザーエントリーへの証明書の追加」

「スマートカード認証用にブラウザーを設定」

「スマートカードを使用して IdM へのログイン」

14.1. スマートカード認証用の 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 サーバーへの root アクセス権限がある。

手順

  1. 設定を行うディレクトリーを作成します。

    [root@server]# mkdir ~/SmartCard/
  2. そのディレクトリーに移動します。

    [root@server]# cd ~/SmartCard/
  3. PEM 形式のファイル (.pem.crt、および .cer) ファイルに保存されている、関連する CA 証明書を取得します。IdM 認証局の証明書は、/etc/ipa/ca.crt ファイルにあります。便宜上、設定を行うディレクトリーに証明書をコピーします。

    [root@server SmartCard]# cp /etc/ipa/ca.crt ~/SmartCard/
    [root@server SmartCard]# cp /tmp/smartcard_ca.pem ~/SmartCard/
  4. 必要に応じて、外部の認証局の証明書を使用する場合は、openssl x509 ユーティリティーを使用して PEM 形式のファイルの内容を表示し、Issuer および Subject の値が正しいことを確認します。

    [root@server SmartCard]# openssl x509 -noout -text -in smartcard_ca.pem | more
  5. 管理者の権限を使用して、組み込みの ipa-advise ユーティリティーで設定スクリプトを生成します。

    [root@server SmartCard]# kinit admin
    [root@server SmartCard]# sudo ipa-advise config-server-for-smart-card-auth > config-server-for-smart-card-auth.sh

    config-server-for-smart-card-auth.sh スクリプトは、以下の操作を実行します。

    • IdM Apache HTTP サーバーを設定します。
    • キー配布センター (KDC) の Kerberos (PKINIT) で、初回認証用の公開鍵暗号化機能を有効にします。
    • スマートカード認可要求を受け入れるように IdM Web UI を設定します。
  6. スクリプトを実行し、CA 証明書が含まれる PEM ファイルを引数として追加します。

    [root@server SmartCard]# chmod +x config-server-for-smart-card-auth.sh
    [root@server SmartCard]# ./config-server-for-smart-card-auth.sh smartcard_ca.pem ca.crt
    Ticket cache:KEYRING:persistent:0:0
    Default principal: admin@IDM.EXAMPLE.COM
    [...]
    Systemwide CA database updated.
    The ipa-certupdate command was successful
  7. 必要に応じて、ユーザー証明書を発行した認証局が Online Certificate Status Protocol (OCSP) レスポンダーを提供しない場合は、IdM Web UI への認証に対する OCSP チェックを無効にすることが必要になる場合があります。

    1. /etc/httpd/conf.d/ssl.conf ファイルで SSLOCSPEnable パラメーターを off に設定します。

      SSLOCSPEnable off
    2. 変更をすぐに有効にするには、Apache デーモン (httpd) を再起動します。

      [root@server SmartCard]# sudo systemctl restart httpd
    警告

    IdM CA が発行したユーザー証明書のみを使用する場合は、OCSP チェックを無効にしないでください。OCSP レスポンダーは IdM に含まれます。

    ユーザー証明書を発行した CA が、OCSP サービスリクエストをリッスンする場所に関する情報がユーザー証明書に含まれていない場合に、OCSP チェックを有効にしたまま、ユーザー証明書が IdM サーバーにより拒否されないようにする方法は、Apache mod_ssl 設定オプションSSLOCSPDefaultResponder ディレクティブを参照してください。

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

注記

トポロジー全体でスマートカード認証を有効にするには、各 IdM サーバーで手順を実行します。

14.2. スマートカード認証用の IdM クライアントの設定

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

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

  • ssh プロトコル
  • コンソールのログイン
  • Gnome Display Manager (GDM)
  • su コマンド

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

  • マシン - 場合によっては IdM ドメイン外にあります (ブラウザーが実行されている場合)
  • httpd が実行している IdM サーバー

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

前提条件

手順

  1. IdM マスターで、管理者権限を使用して、ipa-advise で設定スクリプトを生成します。

    [root@server SmartCard]# kinit admin
    [root@server SmartCard]# ipa-advise config-client-for-smart-card-auth > config-client-for-smart-card-auth.sh

    config-client-for-smart-card-auth.sh スクリプトは、以下の操作を実行します。

    • スマートカードデーモンを設定する。
    • システム全体のトラストストアを設定する。
    • System Security Services Daemon (SSSD) を設定して、スマートカードのログインをデスクトップに許可する。
  2. IdM マスターから、IdM クライアントマシンの任意のディレクトリーに、スクリプトをコピーします。

    [root@server SmartCard]# scp config-client-for-smart-card-auth.sh root@client.idm.example.com:/root/SmartCard/
    Password:
    config-client-for-smart-card-auth.sh        100%   2419       3.5MB/s   00:00
  3. 便宜上、IdM マスターから、上の手順で使用した IdM クライアントマシンのディレクトリーに、PEM 形式の CA 証明書ファイルをコピーします。

    [root@server SmartCard]# scp {smartcard_ca.pem,ca.crt} root@client.idm.example.com:/root/SmartCard/
    Password:
    smartcard_ca.pem                    100%   1237     9.6KB/s   00:00
    ca.crt                              100%   2514    19.6KB/s   00:00
  4. クライアントマシンで、スクリプトを実行し、CA 証明書を含む PEM ファイルを引数として追加します。

    [root@client SmartCard]# kinit admin
    [root@client SmartCard]# chmod +x config-client-for-smart-card-auth.sh
    [root@client SmartCard]# ./config-client-for-smart-card-auth.sh smartcard_ca.pem ca.crt
    Ticket cache:KEYRING:persistent:0:0
    Default principal: admin@IDM.EXAMPLE.COM
    [...]
    Systemwide CA database updated.
    The ipa-certupdate command was successful

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

14.3. IdM のユーザーエントリーへの証明書の追加

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

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

注記

ユーザーの証明書が IdM 認証局により発行された場合、証明書はユーザーエントリーにすでに保存されているため、本セクションを省略できます。

14.3.1. IdM Web UI のユーザーエントリーへの証明書の追加

前提条件

  • ユーザーエントリーに追加できる証明書がある。

手順

  1. 別のユーザーに証明書を追加する場合は、管理者として IdM Web UI にログインします。独自のプロファイルに証明書を追加する場合は、管理者の認証情報が必要ありません。
  2. UsersActive userssc_user の順に移動します。
  3. Certificate オプションを探して、Add をクリックします。
  4. コマンドラインインターフェース で、cat ユーティリティーまたはテキストエディターを使用して、証明書を表示します。

    [user@client SmartCard]$ cat sc_user_certificate.pem
  5. CLI で、証明書をコピーし、Web UI で開いたウィンドウにこれを貼り付けます。
  6. Add をクリックします。

    図14.1 IdM IdM Web UI で新しい証明書の追加

    IDM が証明書を追加

sc_user エントリーに外部証明書が含まれるようになりました。

14.3.2. IdM CLI でユーザーエントリーへの証明書の追加

前提条件

  • ユーザーエントリーに追加できる証明書がある。

手順

  1. 別のユーザーに証明書を追加する場合は、管理者として IdM Web UI にログインします。

    [user@client SmartCard]$ kinit admin

    独自のプロファイルに証明書を追加する場合は、管理者の認証情報は必要ありません。

    [user@client SmartCard]$ kinit sc_user
  2. ヘッダーとフッターのある証明書を含む環境変数を作成し、1 行に連結します。これは、ipa user-add-cert コマンドで必要な形式です。

    [user@client SmartCard]$ export CERT=`openssl x509 -outform der -in sc_user_certificate.pem | base64 -w0 -`
  3. ipa user-add-cert コマンドを使用して、sc_user のプロファイルに証明書を追加します。

    [user@client SmartCard]$ ipa user-add-cert sc_user --certificate=$CERT

sc_user エントリーに外部証明書が含まれるようになりました。

14.4. スマートカード認証用にブラウザーを設定

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

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

  • Mozilla Firefox 38 以降
  • Google Chrome 46 以降

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

前提条件

  • 「スマートカード認証用の IdM サーバーの設定」に従って、IdM サーバーがスマートカード認証用に設定されている。
  • スマートカードが、スマートカード認証用にブラウザーを設定するホストの USB スロットに挿入されている。
  • スマートカードでは、IdM ユーザーの証明書と秘密鍵の両方が保存されている。スマートカードに証明書および鍵をインポートする方法は、スマートカードベンダーのドキュメントを参照してください。
  • IdM のユーザーエントリーにはスマートカードに保存されている証明書が含まれている。IdM ユーザーのユーザーエントリーに証明書をアップロードする方法は、「IdM のユーザーエントリーへの証明書の追加」を参照してください。

手順

  1. Firefox を開き、設定 をクリックします。

    図14.2 Firefox の設定

    Firefox の設定
  2. プライバシーとセキュリティー に移動します。
  3. セキュリティーデバイス をクリックします。

    図14.3 セキュリティーデバイス

    セキュリティーデバイス
  4. 新しい デバイスマネージャー ダイアログウィンドウの 読み込み をクリックします。

    図14.4 セキュリティーデバイスの読み込み

    モジュールの読み込み
  5. 新しい PKCS#11 デバイスドライバー ダイアログウィンドウで、OpenSC などのモジュール名を入力します。モジュールファイル名を入力します。OpenSC のモジュールは、/usr/lib64/opensc-pkcs11.so ファイルにあります。

    図14.5 セキュリティーデバイス情報の入力

    pkcs11 モジュール名
  6. 必要に応じて、このモジュールが Firefox にログインできることを確認します。

    1. 左側のペインで PIV Card Holder pin (PIV_II) をクリックし、右側のペインで ログインをクリックします。

      図14.6 セキュリティーデバイスを使用してログインします。

      pkcs11 モジュールへのログイン
    2. スマートカードの PIN を入力して、OK をクリックします。

      図14.7 スマートカードの PIN の入力

      IdM PIN ダイアログ

      成功すると、ログインボタン が灰色になります。

      図14.8 読み込まれたセキュリティーデバイスモジュール

      読み込まれた pkcs11 モジュール
  7. OK をクリックします。

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

14.5. スマートカードを使用して IdM へのログイン

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

前提条件

  • Web ブラウザーが、スマートカード認証を使用できるように設定されている。
  • IdM サーバーが、スマートカード認証用に設定されている。
  • IdM サーバーが、スマートカードにインストールした証明書を認識している。
  • 証明書へのアクセスに必要な PIN がある。
  • スマートカードがリーダーにプラグインされている。

手順

  1. ブラウザーで IdM Web UI を開きます。
  2. Log In Using Certificate をクリックします。

    IPA ログインのスマートカード

  3. Password Required ダイアログボックスが開いたら、証明書のロックを解除する PIN を追加して、OK ボタンをクリックします。

    User Identification Request ダイアログボックスが開きます。

    スマートカードに複数の証明書が含まれている場合は、Choose a certificate to present as identification の下にあるドロップダウンリストで、認証に使用する証明書を選択します。

  4. OK ボタンをクリックします。

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

Web UI ユーザー

第15章 IdM クライアントのデスクトップに保存されている証明書を使用した認証の設定

Identity Management (IdM) を設定すると、IdM システム管理者は、認証局 (CA) がユーザーに発行した証明書を使用して、IdM Web UI とコマンドラインインターフェース (CLI) に対してユーザーを認証できます。

Web ブラウザーは、IdM ドメイン外のシステムで実行できます。

このユーザーストーリーの手順では、IdM クライアントのデスクトップに保存された証明書を使用して、Identitiy Management の Web UI と CLI へのログインを効果的に設定およびテストする方法を説明します。このユーザーストーリーでは、以下の点に注意してください。

注記

Identity Management ユーザーのみが、証明書を使用して Web UI にログインできます。Active Directory ユーザーは、ユーザー名とパスワードを使用してログインできます。

15.1. Web UI の証明書認証に対する Identity Management サーバーの設定

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

手順

Identity Management 管理者が、以下を行います。

  1. Identity Management サーバーで管理者権限を取得し、サーバーを設定するシェルスクリプトを作成します。

    1. ipa-advise config-server-for-smart-card-auth コマンドを実行し、その出力をファイル (例: server_certificate_script.sh) に保存します。

      # kinit admin
      # ipa-advise config-server-for-smart-card-auth > server_certificate_script.sh
    2. chmod ユーティリティーを使用して、実行パーミッションをファイルに追加します。

      # chmod +x server_certificate_script.sh
  2. Identity Management ドメインの全サーバーで、server_certificate_script.sh スクリプトを実行します。

    1. 証明書認証を有効にするユーザーの証明書を発行した唯一の認証局が IdM CA である場合は、IdM Certificate Authority 証明書へのパス (/etc/ipa/ca.crt) を使用します。

      # ./server_certificate_script.sh /etc/ipa/ca.crt
    2. 証明書認証を有効にするユーザーの証明書を外部の複数の CA が署名した場合は、関連する CA 証明書へのパスを使用します。

      # ./server_certificate_script.sh /tmp/ca1.pem /tmp/ca2.pem
注記

トポロジー全体でユーザーの証明書認証を有効にする場合は、今後新たにシステムに追加する各レプリカに対して、必ずスクリプトを実行してください。

15.2. 新しいユーザー証明書を要求し、クライアントにエクスポート

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

注記

証明書を使用して認証するユーザーがすでに証明書を持っている場合は、本セクションを飛ばして次に進みます。

手順

  1. 必要に応じて、新しいディレクトリー (例: ~/certdb/) を作成し、証明書の一時データベースを作成します。要求されたら、NSS 証明書の DB パスワードを作成し、後続の手順で生成される証明書への鍵を暗号化します。

    # mkdir ~/certdb/
    # certutil -N -d ~/certdb/
    Enter a password which will be used to encrypt your keys.
    The password should be at least 8 characters long,
    and should contain at least one non-alphabetic character.
    
    Enter new password:
    Re-enter password:
  2. 証明書署名要求 (CSR) を作成し、その出力をファイルにリダイレクトします。たとえば、IDM.EXAMPLE.COM レルムの idm_user ユーザーの 4096 ビット証明書に対して、certificate_request.csr という名前の CSR を作成する場合は、判別を簡単にするために、証明書の秘密鍵のニックネームを idm_user に設定し、発行先を CN=idm_user,O=IDM.EXAMPLE.COM に設定します。

    # certutil -R -d ~/certdb/ -a -g 4096 -n idm_user -s "CN=idm_user,O=IDM.EXAMPLE.COM" > certificate_request.csr
  3. プロンプトが表示されたら、certutil を使用して一時データベースを作成したときに入力したパスワードを入力します。その後、止めるように言われるまで、ランダムにタイピングし続けます。

    Enter Password or Pin for "NSS Certificate DB":
    
    A random seed must be generated that will be used in the
    creation of your key.  One of the easiest ways to create a
    random seed is to use the timing of keystrokes on a keyboard.
    
    To begin, type keys on the keyboard until this progress meter
    is full.  DO NOT USE THE AUTOREPEAT FUNCTION ON YOUR KEYBOARD!
    
    
    Continue typing until the progress meter is full:
  4. 証明書要求ファイルをサーバーに送信します。新しく発行した証明書に関連付ける Kerberos プリンシパルと、証明書を保存する出力ファイルを指定し、必要に応じて証明書のプロファイルを指定します。たとえば、IECUserRoles プロファイル (idm_user@IDM.EXAMPLE.COM プリンシパルに追加したユーザーロール拡張を持つプロファイル) の証明書を取得して、それを ~/idm_user.pem ファイルに保存する場合は、次のコマンドを実行します。

    # ipa cert-request certificate_request.csr --principal=idm_user@IDM.EXAMPLE.COM --profile-id=IECUserRoles --certificate-out=~/idm_user.pem
  5. 証明書を NSS データベースに追加します。証明書が NSS データベースの秘密鍵に一致するように、CSR を作成する際に使用したニックネームを設定するには、-n オプションを使用します。-t オプションは信頼レベルを設定します。詳細は、man ページの certutil(1) を参照してください。-i オプションは、入力証明書ファイルを指定します。たとえば、idm_user ニックネームを持つ証明書を NSS データベースに追加するには、次のコマンドを実行します。証明書は、~/certdb/ データベースの ~/idm_user.pem ファイルに保存されます。

    # certutil -A -d ~/certdb/ -n idm_user -t "P,," -i ~/idm_user.pem
  6. NSS データベースの鍵で、ニックネームが (orphan) と表示されていないことを確認します。たとえば、~/certdb/ データベースに保存されている証明書で、対応する鍵が存在することを確認するには、以下のコマンドを実行します。

    # certutil -K -d ~/certdb/
    < 0> rsa      5ad14d41463b87a095b1896cf0068ccc467df395   NSS Certificate DB:[replaceable]idm_user
  7. 証明書を、NSS データベースから PKCS12 形式にエクスポートするには、pk12util コマンドを使用します。たとえば、NSS データベース /root/certdb から ~/idm_user.p12 ファイルへ、idm_user ニックネームを持つ証明書をエクスポートする場合は、次のコマンドを実行します。

    # pk12util -d ~/certdb -o ~/idm_user.p12 -n idm_user
    Enter Password or Pin for "NSS Certificate DB":
    Enter password for PKCS12 file:
    Re-enter password:
    pk12util: PKCS12 EXPORT SUCCESSFUL
  8. idm_user の証明書認証を有効にするホストに、証明書を転送します。

    # scp ~/idm_user.p12 idm_user@client.idm.example.com:/home/idm_user/
  9. セキュリティー上の理由から、証明書が転送されたホストの、.pkcs12 ファイルが格納されているディレクトリーに、「other」グループがアクセスできないようにします。

    # chmod o-rwx /home/idm_user/
  10. セキュリティー上の理由から、一時 NSS データベースおよび .pkcs12 ファイルを、サーバーから削除します。

    # rm ~/certdb/
    # rm ~/idm_user.p12

15.3. 証明書とユーザーが互いにリンクしていることを確認

注記

ユーザーの証明書が IdM CA により発行されている場合は、本セクションを飛ばして先に進みます。

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

15.4. 証明書認証を有効にするようにブラウザーを設定

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

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

  • Mozilla Firefox 38 以降
  • Google Chrome 46 以降

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

手順

  1. Firefox を開き、設定プライバシーとセキュリティ に移動します。

    設定のプライバシーおよびセキュリティセクション

    プライバシーとセキュリティー
  2. 証明書を表示 をクリックします。

    プライバシーおよびセキュリティーで証明書を表示

    証明書の表示
  3. あなたの証明書 タブで、インポート をクリックします。PKCS12 形式のユーザー証明書を見つけて開きます。OK をクリックし、OK をクリックします。
  4. Identity Management 認証局が、Firefox で信頼できる認証局として認識されていることを確認します。

    1. IdM CA 証明書をローカルに保存します。

      • Firefox アドレスバーに IdM サーバーの名前を入力し、IdM の Web UI に移動します。接続が安全ではないことを警告するページで、詳細 をクリックします。

        安全ではない接続

        接続が IDM をセキュア化しない
      • 例外を追加 します。表示 をクリックします。

        証明書の詳細の表示

        CA 証明書 の IDM の表示
      • 詳細 タブで、認証局 フィールドを強調表示します。

        CA 証明書のエクスポート

        CA 証明書のエクスポート
      • エクスポート をクリックします。CA 証明書を、CertificateAuthority.crt ファイルとして保存し、閉じる をクリックして、キャンセル をクリックします。
    2. IdM CA 証明書を、信頼できる認証局の証明書として Firefox にインポートします。

      • Firefox を起動し、設定に移動して、プライバシーおよびセキュリティに移動します。

        設定のプライバシーおよびセキュリティセクション

        プライバシーとセキュリティー
      • 証明書を表示 をクリックします。

        プライバシーおよびセキュリティーで証明書を表示

        証明書の表示
      • 認証機関 タブで、インポート をクリックします。CertificateAuthority.crt ファイルで、上の手順で保存した CA 証明書を見つけて開きます。証明書を信頼し、Web サイトを識別したら、OK をクリックし、OK をクリックします。
  5. 「Identity Management ユーザーとして証明書を使用して Identity Management の Web UI で認証」に進みます。

15.5. Identity Management ユーザーとして証明書を使用して Identity Management の Web UI で認証

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

手順

  1. ブラウザーで、Identity Management の Web UI (例: https://server.idm.example.com/ipa/ui) に移動します。
  2. Login Using Certificate をクリックします。

    Identity Management の Web UI で Login Using Certificate

    スマートカードログイン
  3. ユーザーの証明書がすでに選択されているはずです。Remember this decision の選択を解除して、OK をクリックします。

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

関連情報

  • スマートカードに保存された証明書を使用して IdM Web UI への認証を行う方法は、参照してください。

15.6. 証明書を使用して CLI への認証を可能にするように IdM クライアントを設定

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

手順

  • IdM クライアントにログインし、ユーザーの証明書と秘密鍵を含む .p12 ファイルを用意します。Kerberos TGT (Ticket Granting Ticket) ファイルを取得してキャッシュを取得するには、-X オプションに X509_username:/path/to/file.p12 属性を使用し、ユーザーのプリンシパルで kinit コマンドを実行して、ユーザーの X509 識別情報の場所を指定します。たとえば、~/idm_user.p12 ファイルに保存されている識別情報を使用して idm_user の TGT を取得するには、次のコマンドを実行します。

    $ kinit -X X509_idm_user='PKCS12:~/idm_user.p12' idm_user
    注記

    このコマンドは、.pem ファイル形式 (kinit -X X509_username='FILE:/path/to/cert.pem,/path/to/key' user_principal) にも対応しています。

第16章 Identity Management に証明書マッピングルールを設定

16.1. スマートカードにおける認証を設定するための証明書マッピングルール

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

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

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

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

  1. 管理者は、証明書マッピングデータ (通常は発行者と題名)、または完全な証明書をユーザーアカウントに読み込む必要があります。
  2. ユーザーが IdM へのログインを問題なく行えるようにするために、管理者が証明書マッピングルールを作成する必要があります。

    1. アカウントに、証明書マッピングデータエントリーが含まれる
    2. 証明書マッピングデータエントリーが、証明書の情報と一致する

    マッピングルールを構成する個々のコンポーネントの詳細と、そのコンポーネントの取得方法および使用方法は、「IdM での ID マッピングルールのコンポーネント」および「一致するルールで使用する証明書の発行者の取得」を参照してください。

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

16.1.1. Active Directory ドメインとの信頼に対する証明書マッピングルール

本セクションでは、IdM デプロイメントが Active Directory (AD) ドメインと信頼関係にある場合に可能な、別の証明書マッピングのユースケースを簡単に説明します。

証明書マッピングルールは、信頼された AD 証明書システムが発行したスマートカード証明書を持つユーザーに対して、IdM リソースにアクセスするのに便利な方法です。AD 設定によっては、以下の状況が考えられます。

16.1.2. IdM における ID マッピングルールのコンポーネント

本セクションでは、IdM の ID マッピングルール のコンポーネントと、その設定方法を説明します。各コンポーネントには、上書きできるデフォルト値があります。コンポーネントは、Web UI または CLI のいずれかで定義できます。CLI では、ipa certmaprule-add コマンドを使用して、ID マッピングルールが作成されます。

マッピングルール

マッピングルールコンポーネントでは、証明書を 1 人または複数のユーザーアカウントに関連付けます (または マップ します)。ルールは、証明書を目的のユーザーアカウントに関連付ける LDAP 検索フィルターを定義します。

さまざまな認証局 (CA) が発行する証明書にはさまざまなプロパティーがあり、さまざまなドメインで使用される可能性があります。そのため、IdM はマッピングルールを無条件に適用せず、適切な証明書にのみ適用されます。適切な証明書は、マッチングルール を使用して定義されます。

マッピングルールのオプションを空のままにすると、証明書は、DER でエンコードされたバイナリーファイルとして、userCertificate 属性で検索されることに注意してください。

--maprule オプションを使用して、CLI でマッピングルールを定義します。

マッチングルール

マッチングルールコンポーネントは、マッピングルールを適用する証明書を選択します。デフォルトのマッチングルールは、digitalSignature 鍵 の使用と、clientAuth 拡張鍵 の使用で、証明書と一致します。

--matchrule オプションを使用して、CLI にマッチングルールを定義します。

ドメインリスト

ドメイン一覧は、ID マッピングルールの処理時に IdM がユーザーを検索する ID ドメインを指定します。このオプションを指定しないと、IdM は、IdM クライアントが所属しているローカルドメイン内でのみユーザーを検索します。

--domain オプションを使用して CLI にドメインを定義します。

優先度

複数のルールが証明書に適用される場合は、最も優先度が高いルールが優先されます。その他のルールはすべて無視されます。

  • 数値が低いほど、ID マッピングルールの優先度が高くなります。たとえば、優先度 1 のルールは、優先度 2 のルールよりも高く設定されています。
  • ルールに優先度の値が定義されていないと、優先度が最も低くなります。

--priority オプションを使用して、CLI にマッピングルールの優先度を定義します。

証明書マッピングルールの例 1

CLI を使用して、その証明書の Subject が IdM のユーザーアカウントの certmapdata エントリーと一致している場合に限り、EXAMPLE.ORG 組織の スマートカード CA が発行する証明書を認証局が認証できるようにする証明書マッピングルール simple_rule を定義するには、次のコマンドを実行します。

# 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})'

16.1.3. マッチングルールで使用する証明書から発行者の取得

この手順では、証明書から発行者情報を取得して、証明書マッピングルールのマッチングルールにコピーする方法を説明します。マッチングルールで必要な発行者の形式を取得するには、openssl x509 ユーティリティーを使用します。

前提条件

  • .pem 形式または .crt 形式のユーザー証明書がある。

手順

  1. 証明書からユーザー情報を取得します。以下のように、openssl x509 証明書の表示および署名ユーティリティーを使用します。

    • リクエストのエンコードされたバージョンの出力を防ぐ -noout オプション
    • 発行者名を出力する -issuer オプション
    • 証明書を読み込む入力ファイル名を指定する -in オプション
    • RFC2253 値と共に -nameopt オプションを指定して、最初に最も具体的な相対識別名 (RDN) で出力を表示します。

      入力ファイルに Identity Management 証明書が含まれる場合は、コマンドの出力で、組織 情報を使用して発行者が定義されていることを示しています。

      # openssl x509 -noout -issuer -in idm_user.crt -nameopt RFC2253
      issuer=CN=Certificate Authority,O=REALM.EXAMPLE.COM

      入力ファイルに Active Directory 証明書が含まれる場合は、コマンドの出力で、ドメインコンポーネント の情報を使用して発行者が定義されていることを示しています。

      # openssl x509 -noout -issuer -in ad_user.crt -nameopt RFC2253
      issuer=CN=AD-WIN2012R2-CA,DC=AD,DC=EXAMPLE,DC=COM
  2. 必要に応じて、証明書発行者が、ad.example.com ドメインから展開した AD-WIN2012R2-CA であることを指定するマッチングルールに基づいて、CLI で新しいマッピングルールを作成する場合は、証明書の発行先が、IdM のユーザーアカウントにある certmapdata エントリーと一致する必要があります。

    # ipa certmaprule-add simple_rule --matchrule '<ISSUER>CN=AD-WIN2012R2-CA,DC=AD,DC=EXAMPLE,DC=COM' --maprule '(ipacertmapdata=X509:<I>{issuer_dn!nss_x500}<S>{subject_dn!nss_x500})'

関連情報

マッチングルールおよびマッピングルールで対応している形式の詳細と、優先順位およびドメインフィールドの説明は、man ページの sss-certmap(5) を参照してください。

16.2. IdM に保存されたユーザーの証明書マッピングの設定

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

前提条件

  • IdM にユーザーがアカウントがある。
  • 管理者が、ユーザーエントリーに追加する証明書全体または証明書マッピングデータのいずれかを所有している。

16.2.1. IdM での証明書マッピングルールの追加

このセクションでは、マッピングルールおよび証明書マッピングデータエントリーで指定された条件に一致する証明書を持つ IdM ユーザーが IdM に対して認証できるように、証明書マッピングルールを設定する方法を説明します。

16.2.1.1. IdM IdM Web UI で証明書マッピングルールの追加

  1. 管理者として IdM Web UI にログインします。
  2. AuthenticationCertificate Identity Mapping RulesCertificate Identity Mapping Rules の順に移動します。
  3. Add をクリックします。

    図16.1 IdM IdM Web UI で新しい証明書マッピングルールの追加

    新しい certmaprule を追加
  4. ルール名を入力します。
  5. マッピングルールを入力します。たとえば、IdM に提示された証明書の Issuer およびSubject エントリーを Idm で検索し、提示された証明書に含まれるこの 2 つのエントリーで見つかった情報に基づいて認証するかどうかを決定するには、次のコマンドを実行します。

    (ipacertmapdata=X509:<I>{issuer_dn!nss_x500}<S>{subject_dn!nss_x500})
  6. マッチングルールを入力します。たとえば、EXAMPLE.ORG 組織の スマートカード CA が発行する証明書のみが IdM に対して認証できるようにするには、次のコマンドを実行します。

    <ISSUER>CN=Smart Card CA,O=EXAMPLE.ORG

    図16.2 IdM Web UI への証明書マッピングルールの詳細の入力

    certmaprule 詳細の追加 1
  7. ダイアログボックスの下部にある Add をクリックして、ルールを追加し、ダイアログボックスを閉じます。
  8. System Security Services Daemon (SSSD) は、証明書マッピングルールを定期的に再読み込みします。新たに作成したルールがすぐに読み込まれるようにする場合は、次のコマンドを実行して SSSD を再起動します。

    # systemctl restart sssd

これで、証明書マッピングルールセットが設定され、スマートカードの証明書で検出されたマッピングルールで指定されたデータの種類と、IdM ユーザーエントリーの証明書マッピングデータを比較します。一致するファイルが見つかると、一致するユーザーが認証されます。

16.2.1.2. IdM CLI での証明書マッピングルールの追加

  1. 管理者の認証情報を取得します。

    # kinit admin
  2. マッピングルールを入力し、マッピングルールの基となっているマッチングルールを入力します。たとえば、提示する証明書内の Issuer および Subject のエントリーを IdM で検索し、提示された証明書に含まれるこの 2 つのエントリーで見つかった情報に基づいて認証するかどうかを決定し、EXAMPLE.ORG 組織の Smart Card CA が発行する証明書のみを認識するには、次のコマンドを実行します。

    # ipa certmaprule-add rule_name --matchrule '<ISSUER>CN=Smart Card CA,O=EXAMPLE.ORG' --maprule '(ipacertmapdata=X509:<I>{issuer_dn!nss_x500}<S>{subject_dn!nss_x500})'
    -------------------------------------------------------
    Added Certificate Identity Mapping Rule "rule_name"
    -------------------------------------------------------
      Rule name: rule_name
      Mapping rule: (ipacertmapdata=X509:<I>{issuer_dn!nss_x500}<S>{subject_dn!nss_x500})
      Matching rule: <ISSUER>CN=Smart Card CA,O=EXAMPLE.ORG
      Enabled: TRUE
  3. System Security Services Daemon (SSSD) は、証明書マッピングルールを定期的に再読み込みします。新たに作成したルールがすぐに読み込まれるようにする場合は、次のコマンドを実行して SSSD を再起動します。

    # systemctl restart sssd

これで、証明書マッピングルールセットが設定され、スマートカードの証明書で検出されたマッピングルールで指定されたデータの種類と、IdM ユーザーエントリーの証明書マッピングデータを比較します。一致するファイルが見つかると、一致するユーザーが認証されます。

16.2.2. IdM のユーザーエントリーへの証明書マッピングデータの追加

本セクションでは、証明書マッピングデータエントリーで指定された値が含まれている場合に限り、ユーザーが複数の証明書を使用して認証できるように、IdM ユーザーエントリーへの証明書マッピングデータを入力する方法を説明します。

16.2.2.1. IdM Web UI のユーザーエントリーへの証明書マッピングデータの追加

  1. 管理者として IdM Web UI にログインします。
  2. UsersActive usersidm_user に移動します。
  3. Certificate mapping data オプションを見つけ、Add をクリックします。
  4. 利用できる idm_user の証明書がある場合は、次のコマンドを実行します。

    1. コマンドラインインターフェースで、cat ユーティリティーまたはテキストエディターで証明書を表示します。

      [root@server ~]# cat idm_user_certificate.pem
      -----BEGIN CERTIFICATE-----
      MIIFFTCCA/2gAwIBAgIBEjANBgkqhkiG9w0BAQsFADA6MRgwFgYDVQQKDA9JRE0u
      RVhBTVBMRS5DT00xHjAcBgNVBAMMFUNlcnRpZmljYXRlIEF1dGhvcml0eTAeFw0x
      ODA5MDIxODE1MzlaFw0yMDA5MDIxODE1MzlaMCwxGDAWBgNVBAoMD0lETS5FWEFN
      [...output truncated...]
    2. 証明書をコピーします。
    3. IdM Web UI で、Certificate の横にある Add をクリックして、開いたウィンドウに証明書を貼り付けます。

      図16.3 ユーザーの証明書マッピングデータの追加 - 証明書

      ユーザーが証明書を追加

      または、利用できる idm_user の証明書がなくても、証明書の 発行者 および 発行先 を知っている場合は、Issuer and subject のラジオボタンをオンにして、該当するボックスに値を入力します。

      図16.4 ユーザーの証明書マッピングデータの追加 - 発行者および発行先

      ユーザーが証明書データを追加
  5. Add をクリックします。
  6. 必要に応じて、.pem 形式の証明書全体へのアクセスがある場合は、ユーザーと証明書がリンクされていることを確認します。

    1. sss_cache ユーティリティーを使用して、SSSD キャッシュで idm_user の記録を無効にし、idm_user 情報を再読み込みします。

      # sss_cache -u idm_user
    2. ipa certmap-match コマンドに、IdM ユーザーの証明書が含まれるファイルの名前を付けて実行します。

      # ipa certmap-match idm_user_cert.pem
      --------------
      1 user matched
      --------------
       Domain: IDM.EXAMPLE.COM
       User logins: idm_user
      ----------------------------
      Number of entries returned 1
      ----------------------------

      この出力では、証明書マッピングデータが idm_user に追加され、「IdM の証明書マッピングルールの追加」で定義された、対応するマッピングルールが存在することを確認します。これは、定義した証明書マッピングデータに一致する証明書を使用して、idm_user として認証できることを意味します。

16.2.2.2. IdM CLI のユーザーエントリーへの証明書マッピングデータの追加

  1. 管理者の認証情報を取得します。

    # kinit admin
  2. 利用できる idm_user の証明書がある場合は、ipa user-add-cert コマンドを使用して、証明書をユーザーアカウントに追加します。

    # CERT=`cat idm_user_cert.pem | tail -n +2| head -n -1 | tr -d '\r\n'\`
    # ipa user-add-certmapdata idm_user --certificate $CERT

    または、利用できる idm_user の証明書がなく、idm_user の証明書の 発行者 および 発行先 が分かっている場合は、次のコマンドを実行します。

    # ipa user-add-certmapdata idm_user --subject "O=EXAMPLE.ORG,CN=test" --issuer "CN=Smart Card CA,O=EXAMPLE.ORG"
    --------------------------------------------
    Added certificate mappings to user "idm_user"
    --------------------------------------------
      User login: idm_user
      Certificate mapping data: X509:<I>O=EXAMPLE.ORG,CN=Smart Card CA<S>CN=test,O=EXAMPLE.ORG
  3. 必要に応じて、.pem 形式の証明書全体へのアクセスがある場合は、ユーザーと証明書がリンクされていることを確認します。

    1. sss_cache ユーティリティーを使用して、SSSD キャッシュで idm_user の記録を無効にし、idm_user 情報を再読み込みします。

      # sss_cache -u idm_user
    2. ipa certmap-match コマンドに、IdM ユーザーの証明書が含まれるファイルの名前を付けて実行します。

      # ipa certmap-match idm_user_cert.pem
      --------------
      1 user matched
      --------------
       Domain: IDM.EXAMPLE.COM
       User logins: idm_user
      ----------------------------
      Number of entries returned 1
      ----------------------------

      この出力では、証明書マッピングデータが idm_user に追加され、「IdM の証明書マッピングルールの追加」で定義された、対応するマッピングルールが存在することを確認します。これは、定義した証明書マッピングデータに一致する証明書を使用して、idm_user として認証できることを意味します。

16.3. AD ユーザーエントリーに証明書全体が含まれるユーザーに証明書マッピングを設定

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

前提条件

  • IdM にユーザーアカウントがない。
  • ユーザーに、証明書を含む AD のアカウントがある。
  • IdM 管理者が、IdM 証明書マッピングルールが基になっているデータにアクセスできる。

16.3.1. AD エントリーに証明書全体が含まれるユーザーに証明書マッピングルールを追加

16.3.1.1. IdM IdM Web UI で証明書マッピングルールの追加

  1. 管理者として IdM Web UI にログインします。
  2. AuthenticationCertificate Identity Mapping RulesCertificate Identity Mapping Rules の順に移動します。
  3. Add をクリックします。

    図16.5 IdM IdM Web UI で新しい証明書マッピングルールの追加

    新しい certmaprule を追加
  4. ルール名を入力します。
  5. マッピングルールを入力します。認証のために IdM に提示された証明書全体を、AD で利用可能な証明書全体と比較するには、次のコマンドを実行します。

    (userCertificate;binary={cert!bin})
  6. マッチングルールを入力します。たとえば、AD.EXAMPLE.COM ドメインの AD-ROOT-CA が発行する証明書のみを認証できるようにするには、次のコマンドを実行します。

    <ISSUER>CN=AD-ROOT-CA,DC=ad,DC=example,DC=com

    図16.6 AD に保存されている証明書があるユーザーの証明書マッピングルール

    certmaprule が AD 証明書を追加
  7. Add をクリックします。
  8. System Security Services Daemon (SSSD) は、証明書マッピングルールを定期的に再読み込みします。新たに作成したルールがすぐに読み込まれるようにするには、CLI で SSSD を再起動します。

    # systemctl restart sssd

16.3.1.2. IdM CLI での証明書マッピングルールの追加

  1. 管理者の認証情報を取得します。

    # kinit admin
  2. マッピングルールを入力し、マッピングルールの基となっているマッチングルールを入力します。AD で利用可能な証明書と比較する、認証用に提示される証明書全体を取得して、AD.EXAMPLE.COM ドメインの AD-ROOT-CA により発行された証明書のみの認証を許可するには、次のコマンドを実行します。

    # ipa certmaprule-add simpleADrule --matchrule '<ISSUER>CN=AD-ROOT-CA,DC=ad,DC=example,DC=com' --maprule '(userCertificate;binary={cert!bin})' --domain ad.example.com
    -------------------------------------------------------
    Added Certificate Identity Mapping Rule "simpleADrule"
    -------------------------------------------------------
      Rule name: simpleADrule
      Mapping rule: (userCertificate;binary={cert!bin})
      Matching rule: <ISSUER>CN=AD-ROOT-CA,DC=ad,DC=example,DC=com
      Domain name: ad.example.com
      Enabled: TRUE
  3. System Security Services Daemon (SSSD) は、証明書マッピングルールを定期的に再読み込みします。新たに作成したルールがすぐに読み込まれるようにする場合は、次のコマンドを実行して SSSD を再起動します。

    # systemctl restart sssd

16.4. ユーザー証明書をユーザーアカウントにマッピングするように AD が設定されている場合に、証明書マッピングの設定

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

前提条件

  • IdM にユーザーアカウントがない。
  • このユーザーに、altSecurityIdentities 属性を含む AD にアカウントがある。AD は、IdM の certmapdata 属性に相当します。
  • IdM 管理者が、IdM 証明書マッピングルールが基になっているデータにアクセスできる。

16.4.1. 信頼された AD ドメインがユーザー証明書をマッピングするように設定されている場合には、証明書マッピングルールの追加

16.4.1.1. IdM IdM Web UI で証明書マッピングルールの追加

  1. 管理者として IdM Web UI にログインします。
  2. AuthenticationCertificate Identity Mapping RulesCertificate Identity Mapping Rules の順に移動します。
  3. Add をクリックします。

    図16.7 IdM IdM Web UI で新しい証明書マッピングルールの追加

    新しい certmaprule を追加
  4. ルール名を入力します。
  5. マッピングルールを入力します。たとえば、提示された証明書で Issuer エントリーおよび Subject エントリーを AD DC で検索し、提示された証明書に含まれるこの 2 つのエントリーで見つかった情報に基づいて認証するかどうかを決定するには、次のコマンドを実行します。

    (altSecurityIdentities=X509:<I>{issuer_dn!ad_x500}<S>{subject_dn!ad_x500})
  6. マッチングルールを入力します。たとえば、AD.EXAMPLE.COM ドメインの AD-ROOT-CA が発行する証明書のみを認証できるようにするには、次のコマンドを実行します。

    <ISSUER>CN=AD-ROOT-CA,DC=ad,DC=example,DC=com
  7. ドメインを入力します。

    ad.example.com

    図16.8 AD がマッピング用に設定されている場合の証明書マッピングルール

    certmaprule が詳細の AD マップを追加
  8. Add をクリックします。
  9. System Security Services Daemon (SSSD) は、証明書マッピングルールを定期的に再読み込みします。新たに作成したルールがすぐに読み込まれるようにするには、CLI で SSSD を再起動します。

    # systemctl restart sssd

16.4.1.2. IdM CLI での証明書マッピングルールの追加

  1. 管理者の認証情報を取得します。

    # kinit admin
  2. マッピングルールを入力し、マッピングルールの基となっているマッチングルールを入力します。たとえば、提示する証明書の Issuer エントリーおよび Subject エントリーを AD で検索し、AD.EXAMPLE.COM ドメインの AD-ROOT-CA により発行された証明書のみを許可するには、次のコマンドを実行します。

    # ipa certmaprule-add ad_configured_for_mapping_rule --matchrule '<ISSUER>CN=AD-ROOT-CA,DC=ad,DC=example,DC=com' --maprule '(altSecurityIdentities=X509:<I>{issuer_dn!ad_x500}<S>{subject_dn!ad_x500})' --domain=ad.example.com
    -------------------------------------------------------
    Added Certificate Identity Mapping Rule "ad_configured_for_mapping_rule"
    -------------------------------------------------------
      Rule name: ad_configured_for_mapping_rule
      Mapping rule: (altSecurityIdentities=X509:<I>{issuer_dn!ad_x500}<S>{subject_dn!ad_x500})
      Matching rule: <ISSUER>CN=AD-ROOT-CA,DC=ad,DC=example,DC=com
      Domain name: ad.example.com
      Enabled: TRUE
  3. System Security Services Daemon (SSSD) は、証明書マッピングルールを定期的に再読み込みします。新たに作成したルールがすぐに読み込まれるようにする場合は、次のコマンドを実行して SSSD を再起動します。

    # systemctl restart sssd

16.4.2. AD で証明書マッピングデータの確認

altSecurityIdentities 属性は、IdM の certmapdata ユーザー属性と同等の Active Directory (AD) です。信頼されている AD ドメインが、ユーザーアカウントにユーザー証明書をマッピングするように設定されている時に IdM で証明書マッピングを設定する場合は、IdM システム管理者が、AD のユーザーエントリーに altSecurityIdentities 属性が正しく設定されていることを確認する必要があります。

AD に保存されているユーザーに対して、AD が正しい情報が含まれていることを確認する場合は、ldapsearch コマンドを使用します。

  • たとえば、ad_user のユーザーエントリーに altSecurityIdentities 属性が設定されており、ad_user が AD の認証に使用する証明書が、ad.example.com ドメインの AD-ROOT-CA により発行され、発行先が <S>DC=com,DC=example,DC=ad,CN=Users,CN=ad_user であることを matchrule が規定していることを、adserver.ad.example.com サーバーに確認する場合は、次のコマンド実行します。

    $ ldapsearch -o ldif-wrap=no -LLL -h adserver.ad.example.com \
    -p 389 -D cn=Administrator,cn=users,dc=ad,dc=example,dc=com \
    -W -b cn=users,dc=ad,dc=example,dc=com "(cn=ad_user)" \
    altSecurityIdentities
    Enter LDAP Password:
    dn: CN=ad_user,CN=Users,DC=ad,DC=example,DC=com
    altSecurityIdentities: X509:<I>DC=com,DC=example,DC=ad,CN=AD-ROOT-CA<S>DC=com,DC=example,DC=ad,CN=Users,CN=ad_user

16.5. AD ユーザーエントリーに証明書やマッピングデータが含まれていない場合に、証明書マッピングの設定

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

前提条件

  • IdM にユーザーアカウントがない。
  • ユーザーのアカウントがある AD に、証明書全体、または altSecurityIdentities 属性、IdM certmapdata 属性で AD に相当するものがない。
  • IdM 管理者が、IdM に、AD ユーザーの ユーザー ID オーバーライド に追加する AD ユーザー証明書全体を所有している。

16.5.1. AD ユーザーエントリーに、証明書またはマッピングデータがない場合に証明書マッピングルールの追加

16.5.1.1. IdM IdM Web UI で証明書マッピングルールの追加

  1. 管理者として IdM Web UI にログインします。
  2. AuthenticationCertificate Identity Mapping RulesCertificate Identity Mapping Rules の順に移動します。
  3. Add をクリックします。

    図16.9 IdM IdM Web UI で新しい証明書マッピングルールの追加

    新しい certmaprule を追加
  4. ルール名を入力します。
  5. マッピングルールを入力します。認証するために IdM に提示された証明書全体を、IdM の AD ユーザーエントリーのユーザー ID オーバーライドエントリーに保存されている証明書と比較できるようにするには、次のコマンドを実行します。

    (userCertificate;binary={cert!bin})
  6. マッチングルールを入力します。たとえば、AD.EXAMPLE.COM ドメインの AD-ROOT-CA が発行する証明書のみを認証できるようにするには、次のコマンドを実行します。

    <ISSUER>CN=AD-ROOT-CA,DC=ad,DC=example,DC=com
  7. ドメイン名を入力します。たとえば、ad.example.com ドメインでユーザーを検索するには、以下を実行します。

    図16.10 AD に証明書やマッピングデータが保存されていないユーザーに対する証明書マッピングルール

    certmaprule が AD 証明書を追加
  8. Add をクリックします。
  9. System Security Services Daemon (SSSD) は、証明書マッピングルールを定期的に再読み込みします。新たに作成したルールがすぐに読み込まれるようにするには、CLI で SSSD を再起動します。

    # systemctl restart sssd

16.5.1.2. IdM CLI での証明書マッピングルールの追加

  1. 管理者の認証情報を取得します。

    # kinit admin
  2. マッピングルールを入力し、マッピングルールの基となっているマッチングルールを入力します。IdM の AD ユーザーエントリーのユーザー ID オーバーライドエントリーに保存されている証明書と比較する、認証用に提示される証明書全体を取得して、AD.EXAMPLE.COM ドメインの AD-ROOT-CA により発行された証明書のみを認証できるようにするには、以下のコマンドを実行します。

    # ipa certmaprule-add simpleADrule --matchrule '<ISSUER>CN=AD-ROOT-CA,DC=ad,DC=example,DC=com' --maprule '(userCertificate;binary={cert!bin})' --domain ad.example.com
    -------------------------------------------------------
    Added Certificate Identity Mapping Rule "simpleADrule"
    -------------------------------------------------------
      Rule name: simpleADrule
      Mapping rule: (userCertificate;binary={cert!bin})
      Matching rule: <ISSUER>CN=AD-ROOT-CA,DC=ad,DC=example,DC=com
      Domain name: ad.example.com
      Enabled: TRUE
  3. System Security Services Daemon (SSSD) は、証明書マッピングルールを定期的に再読み込みします。新たに作成したルールがすぐに読み込まれるようにする場合は、次のコマンドを実行して SSSD を再起動します。

    # systemctl restart sssd

16.5.2. AD のユーザーエントリーに、証明書またはマッピングデータが含まれない場合に、AD ユーザーの ID オーバーライドに証明書を追加

16.5.2.1. IdM Web UI で、AD ユーザーの ID オーバーライドに証明書を追加

  1. IdentityID ViewsDefault Trust View の順に選択します。
  2. Add をクリックします。

    図16.11 IdM IdM Web UI で新規ユーザー ID オーバーライドの追加

    新しい useridoverride の追加
  3. User to override フィールドに、ad_user@ad.example.com と入力します。
  4. ad_user の証明書を、Certificate フィールドにコピーアンドペーストします。

    図16.12 AD ユーザーにユーザー ID オーバーライドの設定

    useridoverride が詳細を追加
  5. Add をクリックします。
  6. 必要に応じて、ユーザーと証明書がリンクされていることを確認します。

    1. sss_cache ユーティリティーを使用して、SSSD キャッシュで ad_user@ad.example.com のレコードを無効にし、ad_user@ad.example.com 情報の再読み込みを強制します。

      # sss_cache -u ad_user@ad.example.com
    2. AD ユーザーの証明書が含まれるファイルの名前で、ipa certmap-match コマンドを実行します。

      # ipa certmap-match ad_user_cert.pem
      --------------
      1 user matched
      --------------
       Domain: AD.EXAMPLE.COM
       User logins: ad_user@ad.example.com
      ----------------------------
      Number of entries returned 1
      ----------------------------

      この出力では、ad_user@ad.example.com に証明書マッピングデータが追加され、「AD ユーザーエントリーに証明書やマッピングデータがない場合は、証明書マッピングルールを追加」に定義した対応するマッピングルールが存在することを確認します。これは、定義した証明書マッピングデータに一致する証明書を使用して、ad_user@ad.example.com として認証できることを意味します。

16.5.2.2. IdM CLI で、AD ユーザーの ID オーバーライドに証明書を追加する

  1. 管理者の認証情報を取得します。

    # kinit admin
  2. ipa idoverrideuser-add-cert コマンドを使用して、ad_user@ad.example.com の証明書をユーザーアカウントに追加します。

    # CERT=`cat ad_user_cert.pem | tail -n +2| head -n -1 | tr -d '\r\n'\`
    # ipa idoverrideuser-add-cert ad_user@ad.example.com --certificate $CERT
  3. 必要に応じて、ユーザーと証明書がリンクされていることを確認します。

    1. sss_cache ユーティリティーを使用して、SSSD キャッシュで ad_user@ad.example.com のレコードを無効にし、ad_user@ad.example.com 情報の再読み込みを強制します。

      # sss_cache -u ad_user@ad.example.com
    2. AD ユーザーの証明書が含まれるファイルの名前で、ipa certmap-match コマンドを実行します。

      # ipa certmap-match ad_user_cert.pem
      --------------
      1 user matched
      --------------
       Domain: AD.EXAMPLE.COM
       User logins: ad_user@ad.example.com
      ----------------------------
      Number of entries returned 1
      ----------------------------

      この出力では、ad_user@ad.example.com に証明書マッピングデータが追加され、「AD ユーザーエントリーに証明書やマッピングデータがない場合は、証明書マッピングルールを追加」に定義した対応するマッピングルールが存在することを確認します。これは、定義した証明書マッピングデータに一致する証明書を使用して、ad_user@ad.example.com として認証できることを意味します。

16.6. 複数のアイデンティティーマッピングルールを 1 つに結合

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

証明書マッピングフィルターの例 1

$ 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 つ以上の基準を満たすユーザーアカウントをすべてマップします。

証明書マッピングフィルターの例 2

$ 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 つ以上の基準を満たすユーザーアカウントをすべてマップします。

第17章 IdM CA Renewal Master の使用

17.1. IdM CA Renewal Master の概要

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

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

  • IdM CA 認証
  • OCSP 署名証明書
  • IdM CA サブシステム 証明書
  • IdM CA 監査署名 証明書
  • IdM 更新エージェント (RA) 証明書
  • KRA トランスポート証明書およびストレージ証明書

システム証明書の特徴は、鍵がすべての 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 サーバーとして自動的に割り当てられます。このポリシーは、更新されたマスター設定を有効に保つようにします。

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

  • オフライン更新マスター

    • 更新マスターが長期間オフラインである場合、更新ウィンドウを閉じる可能性があるため、証明書が期限切れになります。現行の更新マスターがオフラインになり、長期間利用不可になった場合は、新規の CA Renewal Master を手動で割り当てる ことを検討してください。
  • レプリケーションの問題

    • 更新マスターと他の CA レプリカとの間でレプリケーションの問題が存在する場合は、更新が成功する可能性もありますが、その他の CA レプリカが、期限切れになる前に更新された証明書を取得できなくなる可能性があります。この問題を回避するには、レプリカ合意が正しく機能することを確認してください。詳細は、RHEL 7の 『Linux ドメイン ID、認証、およびポリシーガイド』一般的 または 特定 のレプリケーションのトラブルシューティングガイドラインを参照してください。

17.2. IdM 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 管理者認証情報がある。

手順

  1. IdM 管理者認証情報を取得します。

    ~]$ kinit admin
    Password for admin@IDM.EXAMPLE.COM:
  2. 任意で、デプロイメント内のどの IdM サーバーが新しい CA Renewal Master になるのに必要な CA のロールを持っているかを確認するには、次のコマンドを実行します。

    ~]$ ipa server-role-find --role 'CA server'
    ----------------------
    2 server roles matched
    ----------------------
      Server name: server.idm.example.com
      Role name: CA server
      Role status: enabled
    
      Server name: replica.idm.example.com
      Role name: CA server
      Role status: enabled
    ----------------------------
    Number of entries returned 2
    ----------------------------

    出力には、デプロイメントに CA サーバーが 2 台あることが示されています。

  3. 必要に応じて、どの CA サーバーが CA の現在の更新マスターであるかを確認するには、次のコマンドを実行します。

    ~]$ ipa config-show | grep 'CA renewal master'
      IPA CA renewal master: server.idm.example.com

    この出力は、現在の更新マスターが server.idm.example.com であることを示しています。

  4. 更新マスター設定を変更するには、--ca-renewal-master-server オプションを指定して ipa config-mod ユーティリティーを使用します。

    ~]$ ipa config-mod --ca-renewal-master-server replica.idm.example.com | grep 'CA renewal master'
      IPA CA renewal master: replica.idm.example.com
    重要

    以下を使用して、新規 CA Renewal Master に切り替えることもできます。

    • ipa-cacert-manage --renew コマンド。このコマンドは CA 証明書を更新し、さらに 新しい CA Renewal Master を実行する CA サーバーを作成します。
    • ipa-cert-fix コマンド。このコマンドは、期限切れの CA システム証明書を更新します。これにより、破損したデプロイメントが修正され、さらに 新しい CA Renewal Master を実行する CA サーバーが作成されます。

      詳細は 「IdM がオフライン時に期限切れのシステム証明書の更新」を参照してください。

17.3. IdM で外部から自己署名証明書への切り替え

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

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

external_CA certificate > IdM CA certificate > LDAP certificate

前提条件

  • IdM CA Renewal Master への root アクセスがある。
  • IdM 管理者認証情報がある。

手順

  1. IdM CA Renewal Master で、CA 証明書を自己署名として更新します。

    ~]# ipa-cacert-manage renew --self-signed
    Renewing CA certificate, please wait
    CA certificate successfully renewed
    The ipa-cacert-manage command was successful
  2. すべての IdM サーバーおよびクライアントで、サーバーの証明書でローカルの IdM 証明書データベースを更新します。

    [client ~]$ kinit admin
    [client ~]$ ipa-certupdate
    Systemwide CA database updated.
    Systemwide CA database updated.
    The ipa-certupdate command was successful
  3. 必要に応じて、更新が成功したかどうかを確認して、新しい CA 証明書を /etc/ipa/ca.crt ファイルに追加します。

    [client ~]$ openssl crl2pkcs7 -nocrl -certfile /etc/ipa/ca.crt | openssl pkcs7 -print_certs -text -noout
    [...]
    Certificate:
        Data:
            Version: 3 (0x2)
            Serial Number: 39 (0x27)
            Signature Algorithm: sha256WithRSAEncryption
            Issuer: O=IDM.EXAMPLE.COM, CN=Certificate Authority
            Validity
                Not Before: Jul  1 16:32:45 2019 GMT
                Not After : Jul  1 16:32:45 2039 GMT
            Subject: O=IDM.EXAMPLE.COM, CN=Certificate Authority
    [...]

    この出力は、新規 CA 証明書が古い CA 証明書と共にリストされているため、更新が正常に行われたことを示しています。

17.4. 外部署名の証明書で IdM CA Renewal Master の更新

このセクションでは、証明書署名要求 (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 CA Renewal Master への root アクセスがある。
  • IdM 管理者認証情報がある。

手順

この手順では、現在の CA 証明書が自己署名の証明書であるか、または外部署名であるかに関係なく、外部署名を使用して IdM CA の証明書を更新します。

  1. 外部 CA に送信される CSR を作成します。

    • 外部 CA が AD CS の場合は、--external-ca-type=ms-cs オプションを使用します。デフォルトの subCA テンプレート以外のテンプレートが必要な場合は、--external-ca-profile を使用してこれを指定します。

      ~]# ipa-cacert-manage renew --external-ca --external-ca-type=ms-cs [--external-ca-profile=PROFILE]
      Exporting CA certificate signing request, please wait
      The next step is to get /var/lib/ipa/ca.csr signed by your CA and re-run ipa-cacert-manage as:
      ipa-cacert-manage renew --external-cert-file=/path/to/signed_certificate --external-cert-file=/path/to/external_ca_certificate
      The ipa-cacert-manage command was successful
    • 外部 CA が AD CS ではない場合は、以下のようになります。

      ~]# ipa-cacert-manage renew --external-ca
      Exporting CA certificate signing request, please wait
      The next step is to get /var/lib/ipa/ca.csr signed by your CA and re-run ipa-cacert-manage as:
      ipa-cacert-manage renew --external-cert-file=/path/to/signed_certificate --external-cert-file=/path/to/external_ca_certificate
      The ipa-cacert-manage command was successful

      この出力は、CSR が作成され、/var/lib/ipa/ca.csr ファイルに保存されていることを示しています。

  2. /var/lib/ipa/ca.csr にある CSR を外部 CA に送信します。このプロセスは、外部 CA として使用するサービスにより異なります。
  3. 発行した証明書と、ベース 64 でエンコードされたブロブで CA を発行する CA 証明書チェーンを取得します。以下に例を示します。

    • 外部 CA が AD CS ではない場合の PEM ファイル
    • 外部 CA が AD CS の場合の Base_64 証明書

      プロセスは、各証明書サービスによって異なります。通常は Web ページか通知メールにダウンロードリンクがあり、管理者が、必要なすべての証明書をダウンロードできるようになっています。

      外部 CA が AD CS で、Microsoft Windows 認証局管理ウィンドウから既知のテンプレートで CSR を送信した場合、AD CS は証明書を直ちに発行し、その証明書を保存する「証明書の保存」ダイアログが AD CS Web インターフェースに表示されます。

  4. ipa-cacert-manage renew コマンドを再度実行し、完全な証明書チェーンを提供するのに必要な CA 証明書ファイルをすべて追加します。--external-cert-file オプションを複数回使用して、必要な数だけファイルを指定します。

    ~]# ipa-cacert-manage renew --external-cert-file=/path/to/signed_certificate --external-cert-file=/path/to/external_ca_certificate_1 --external-cert-file=/path/to/external_ca_certificate_2
  5. すべての IdM サーバーおよびクライアントで、サーバーの証明書でローカルの IdM 証明書データベースを更新します。

    [client ~]$ kinit admin
    [client ~]$ ipa-certupdate
    Systemwide CA database updated.
    Systemwide CA database updated.
    The ipa-certupdate command was successful
  6. 必要に応じて、更新が成功したかどうかを確認して、新しい CA 証明書を /etc/ipa/ca.crt ファイルに追加します。

    [client ~]$ openssl crl2pkcs7 -nocrl -certfile /etc/ipa/ca.crt | openssl pkcs7 -print_certs -text -noout
    [...]
    Certificate:
        Data:
            Version: 3 (0x2)
            Serial Number: 39 (0x27)
            Signature Algorithm: sha256WithRSAEncryption
            Issuer: O=IDM.EXAMPLE.COM, CN=Certificate Authority
            Validity
                Not Before: Jul  1 16:32:45 2019 GMT
                Not After : Jul  1 16:32:45 2039 GMT
            Subject: O=IDM.EXAMPLE.COM, CN=Certificate Authority
    [...]

    この出力は、新規 CA 証明書が古い CA 証明書と共にリストされているため、更新が正常に行われたことを示しています。

第18章 IdM がオフライン時に期限切れのシステム証明書の更新

システム証明書の期限が切れると、Identity Management (IdM) が起動できません。IdM は、ipa-cert-fix ツールを使用して IdM がオフラインの場合のシステム証明書の更新に対応します。

前提条件

  • IdM が、Red Hat Enterprise Linux 8.1 以降にのみインストールされている。

18.1. CA Renewal Master での期限切れのシステム証明書の更新

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

重要

CA Renewal Master ではないCA (認証局) ホストで ipa-cert-fix ツールを実行し、ユーティリティーが共有証明書を更新すると、そのホストは自動的にドメイン内の新しい CA Renewal Master になります。不整合を避けるために、ドメインには常に CA Renewal Master を 1 つだけ設定する必要があります。

前提条件

  • 管理者権限でサーバーにログインしている。

手順

  1. ipa-cert-fix ツールを起動して、システムを分析し、更新を必要とする期限切れの証明書の一覧を表示します。

    # ipa-cert-fix
    ...
    The following certificates will be renewed:
    
    Dogtag sslserver certificate:
      Subject: CN=ca1.example.com,O=EXAMPLE.COM 201905222205
      Serial:  13
      Expires: 2019-05-12 05:55:47
    ...
    Enter "yes" to proceed:
  2. 更新プロセスを開始するには、yes を入力します。

    Enter "yes" to proceed: yes
    Proceeding.
    Renewed Dogtag sslserver certificate:
      Subject: CN=ca1.example.com,O=EXAMPLE.COM 201905222205
      Serial:  268369925
      Expires: 2021-08-14 02:19:33
    ...
    
    Becoming renewal master.
    The ipa-cert-fix command was successful

    ipa-cert-fix が期限切れの証明書をすべて更新する前に、最大 1 分かかる場合があります。

  3. 必要に応じて、すべてのサービスが現在実行していることを確認します。

    # ipactl status
    Directory Service: RUNNING
    krb5kdc Service: RUNNING
    kadmin Service: RUNNING
    httpd Service: RUNNING
    ipa-custodia Service: RUNNING
    pki-tomcatd Service: RUNNING
    ipa-otpd Service: RUNNING
    ipa: INFO: The ipactl command was successful

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

18.2. 更新後の IdM ドメイン内の他の IdM サーバーの検証

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

  • ドメインのその他の Identity Management (IdM) サーバーをすべて再起動する。
  • certmonger が証明書を更新したかどうかを確認する。
  • 期限切れのシステム証明書でその他の認証局 (CA) レプリカがある場合は、証明書も ipa-cert-fix ツールで更新する。

前提条件

  • 管理者権限でサーバーにログインしている。

手順

  1. --force パラメーターで IdM を再起動します。

    # ipactl restart --force

    --force パラメーターを使用すると、ipactl ユーティリティーは個々のサービスの起動失敗を無視します。たとえば、サーバーに期限切れの証明書を持つ CA もあると、pki-tomcat サービスが起動に失敗します。--force パラメーターを使用しているため、これが予想され、無視されます。

  2. 再起動後に、certmonger サービスが証明書を更新することを確認します (証明書の状態は MONITORING になります)。

    # getcert list | egrep '^Request|status:|subject:'
    Request ID '20190522120745':
            status: MONITORING
            subject: CN=IPA RA,O=EXAMPLE.COM 201905222205
    Request ID '20190522120834':
            status: MONITORING
            subject: CN=Certificate Authority,O=EXAMPLE.COM 201905222205
    ...

    certmonger がレプリカ上で共有証明書を更新する前に時間がかかる場合があります。

  3. サーバーも CA の場合、上記のコマンドは、pki-tomcat サービスが使用する証明書の CA_UNREACHABLE を報告します。

    Request ID '20190522120835':
            status: CA_UNREACHABLE
            subject: CN=ca2.example.com,O=EXAMPLE.COM 201905222205
    ...
  4. この証明書を更新するには、ipa-cert-fix ユーティリティーを使用します。

    # ipa-cert-fix
    Dogtag sslserver certificate:
      Subject: CN=ca2.example.com,O=EXAMPLE.COM
      Serial:  3
      Expires: 2019-05-11 12:07:11
    
    Enter "yes" to proceed: yes
    Proceeding.
    Renewed Dogtag sslserver certificate:
      Subject: CN=ca2.example.com,O=EXAMPLE.COM 201905222205
      Serial:  15
      Expires: 2019-08-14 04:25:05
    
    The ipa-cert-fix command was successful

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

第19章 certmonger でサービスの IdM 証明書の取得

19.1. Certmonger の概要

certmonger の機能

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

  • 元の要求で提供されたオプションを使用して、証明書署名要求 (CSR) を再生成する。
  • IdM API の cert-request コマンドを使用して、CSR を IdM CA に送信する。
  • IdM CA から証明書を受け取る。
  • 元の要求で指定されている場合は、事前保存コマンドを実行する。
  • 更新要求で指定された場所 (NSS データベースまたはファイル内) に新しい証明書をインストールする。
  • 元の要求で指定されている場合は、post-save コマンドを実行する。たとえば、post-save コマンドは、関連するサービスを再起動するように certmonger に指示し、サービスが新しい証明書が取得できるようにします。

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

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

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

  • IdM CA 認証
  • OCSP 署名証明書
  • IdM CA サブシステム 証明書
  • IdM CA 監査署名 証明書
  • IdM 更新エージェント (RA) 証明書
  • KRA トランスポート証明書およびストレージ証明書

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

Certmonger のコンポーネント

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

  • certmonger デーモン - 証明書の一覧を追跡し、更新コマンドを実行するエンジンです。
  • コマンドラインインターフェース (CLI) のgetcert ユーティリティー。これにより、システム管理者は certmonger デーモンにアクティブにコマンドを送信できます。

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

19.2. certmonger でサービスの IdM 証明書の取得

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

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

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

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

前提条件

  • Web サーバーが、IdM クライアントとして登録されている。
  • 手順を実行している IdM クライアントへのルートアクセスがある。
  • 証明書を要求しているサービスは、前もって IdM に用意する必要はない。

手順

  1. HTTP サービスが稼働している IdM クライアント webserver.idm.example.com で、以下を指定する HTTP/webserver.idm.example.com@IDM.EXAMPLE.COM プリンシパルに対応するサービスの証明書を要求します。

    • 証明書は、ローカルの /etc/pki/tls/certs/httpd.pem ファイルに保存されます。
    • 秘密鍵は、ローカルの /etc/pki/tls/private/httpd.key ファイルに保存されます。
    • SubjectAltName の extensionRequest が、webserver.idm.example.com の DNS 名の署名要求に追加されます。

      # ipa-getcert request -K HTTP/webserver.idm.example.com -k /etc/pki/tls/private/httpd.key -f /etc/pki/tls/certs/httpd.pem -D webserver.idm.example.com -C "systemctl restart httpd"
      New signing request "20190604065735" added.

      上記のコマンドでは、以下のようになります。

      • ipa-getcert request コマンドは、証明書が IdM CA から取得することを示しています。ipa-getcert request コマンドは、getcert request -c IPA のショートカットです。
      • -C オプションは、証明書の取得後に httpd サービスを再起動するように certmonger に指示します。
      • -D オプションは、要求に追加する DNS 値 SubjectAltName を指定します。
      • 特定のプロファイルで証明書を発行するように指定する場合は、-T オプションを使用します。
      • 指定した CA から名前付き発行者を使用して証明書を要求するには、-X ISSUER オプションを使用します。
      注記

      RHEL 8 は、RHEL 7 で使用されるものとは異なる SSL モジュール (Apache) を使用します。SSL モジュールは、NSS ではなく OpenSSL に依存しています。このため、RHEL 8 では、NSS データベースを使用して HTTPS 証明書と秘密鍵を保存することができません。

  2. 必要に応じて、リクエストの状況を確認するには、次のコマンドを実行します。

    # ipa-getcert list -f /etc/pki/tls/certs/httpd.pem
    Number of certificates and requests being tracked: 3.
    Request ID '20190604065735':
        status: MONITORING
        stuck: no
        key pair storage: type=FILE,location='/etc/pki/tls/private/httpd.key'
        certificate: type=FILE,location='/etc/pki/tls/certs/httpd.crt'
        CA: IPA
    [...]

    この出力は、要求が MONITORING 状況であることを表しています。これは、証明書が取得されていることを示しています。キーペアと証明書の場所は、要求された場所です。

19.3. サービス証明書を要求する certmonger の通信フロー

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

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

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

Certmonger サービス証明書 1


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

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

Certmonger サービス証明書 2


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

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

Certmonger サービス証明書 3


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

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

Certmonger サービス証明書 4


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

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

certmonger サービス証明書 5


19.4. certmonger が追跡する証明書要求の詳細を表示

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

手順

  • 証明書要求の指定方法が分からない場合は、特定の証明書要求のみの詳細を一覧表示します。たとえば、次を指定できます。

    • リクエスト ID
    • 証明書の場所
    • 証明書のニックネーム

      たとえば、要求 ID が 20190408143846 である証明書の詳細を表示するには、-v オプションを使用して、証明書のリクエストが失敗した場合にエラーの詳細をすべて表示します。

      # getcert list -i 20190408143846 -v
      Number of certificates and requests being tracked: 16.
      Request ID '20190408143846':
      	status: MONITORING
      	stuck: no
      	key pair storage: type=NSSDB,location='/etc/dirsrv/slapd-IDM-EXAMPLE-COM',nickname='Server-Cert',token='NSS Certificate DB',pinfile='/etc/dirsrv/slapd-IDM-EXAMPLE-COM/pwdfile.txt'
      	certificate: type=NSSDB,location='/etc/dirsrv/slapd-IDM-EXAMPLE-COM',nickname='Server-Cert',token='NSS Certificate DB'
      	CA: IPA
      	issuer: CN=Certificate Authority,O=IDM.EXAMPLE.COM
      	subject: CN=r8server.idm.example.com,O=IDM.EXAMPLE.COM
      	expires: 2021-04-08 16:38:47 CEST
      	dns: r8server.idm.example.com
      	principal name: ldap/server.idm.example.com@IDM.EXAMPLE.COM
      	key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment
      	eku: id-kp-serverAuth,id-kp-clientAuth
      	pre-save command:
      	post-save command: /usr/libexec/ipa/certmonger/restart_dirsrv IDM-EXAMPLE-COM
      	track: yes
      	auto-renew: yes

    この出力では、証明書に関する情報の一部が表示されます。以下に例を示します。

    • 証明書の場所 - 上記の例では、/etc/dirsrv/slapd-IDM-EXAMPLE-COM ディレクトリーの NSS データベースです。
    • 証明書のニックネーム - 上記の例では Server-Cert になります。
    • ピンを保存しているファイル - 上記の例では /etc/dirsrv/slapd-IDM-EXAMPLE-COM/pwdfile.txt になります。
    • 証明書の更新に使用される認証局 - 上記の例では IPA CA です。
    • 有効期限 - 上記の例では 2021-04-08 16:38:47 CEST になります。
    • 証明書のステータス - 上記の例の MONITORING 状態は、証明書が有効であり、追跡されていることを意味します。
    • post-save コマンド - 上記の例では、LDAP サービスの再起動です。
  • 証明書要求の指定方法が分からない場合は、certmonger が監視または取得しようとしているすべての証明書の詳細を一覧表示します。

    # getcert list

関連情報

  • 表示される証明書の要求を指定するさまざまなオプションを表示するには、man ページの getcert list を参照してください。

19.5. 証明書追跡の開始および停止

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

  1. IdM サーバーでは、存在していないシステムの証明書を作成する。
  2. 新しいシステムを作成する。
  3. 新しいシステムを IdM クライアントとして登録する。
  4. IdM クライアントの IdM サーバーから、証明書および鍵をインポートする。
  5. certmonger を使用して証明書の追跡を開始し、有効期限が切れる時に証明書を更新するようにする。

手順

  • 要求 ID が 20190408143846 の証明書の監視を無効にするには、次のコマンドを実行します。

    # getcert stop-tracking -i 20190408143846

    その他のオプションは、man ページの getcert stop-tracking を参照してください。

  • /tmp/some_cert.crt ファイルに保存されている証明書の監視を有効にするには、次のコマンドを実行します。秘密鍵が /tmp/some_key.key ファイルに保存されます。

    # getcert start-tracking -c IPA -f /tmp/some_cert.crt -k /tmp/some_key.key

    certmonger は、証明書を発行した CA タイプを自動的に特定できません。そのため、IdM CA が証明書を発行した場合は、getcert start-tracking コマンドに IPA 値を付けて -c オプションを追加します。-c オプションを追加しないと、certmonger が NEED_CA 状態になります。

    その他のオプションは、man ページの getcert start-tracking を参照してください。

注記

この 2 つのコマンドは証明書を操作しません。たとえば、getcert stop-tracking は、証明書を削除しなかったり、NSS データベースまたはファイルシステムから削除したりせず、監視する証明書の一覧から証明書を削除します。同様に、getcert start-tracking は、監視された証明書の一覧に証明書のみを追加します。

19.6. 証明書を手動で更新

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

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

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

手順

  • リクエスト ID が 20190408143846 の証明書を更新するには、次のコマンドを実行します。

    # getcert resubmit -i 20190408143846

    特定の証明書の要求 ID を取得するには、getcert list コマンドを使用します。詳細は、man ページの getcert list を参照してください。

19.7. certmonger が CA レプリカでの IdM 証明書の追跡を再開

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

前提条件

  • システム証明書の追跡を再開するホストは、IdM CA でもある IdM サーバーですが、IdM CA Renewal Master ではありません。

手順

  1. サブシステムの CA 証明書の PIN を取得します。

    # grep 'internal=' /var/lib/pki/pki-tomcat/conf/password.conf
  2. サブシステムの CA 証明書に追跡を追加します。次のコマンドの [internal PIN] を、直前の手順で取得した PIN に置き換えます。

    # getcert start-tracking -d /etc/pki/pki-tomcat/alias -n "caSigningCert cert-pki-ca" -c 'dogtag-ipa-ca-renew-agent' -P [internal PIN] -B /usr/libexec/ipa/certmonger/stop_pkicad -C '/usr/libexec/ipa/certmonger/renew_ca_cert "caSigningCert cert-pki-ca"'
    
    # getcert start-tracking -d /etc/pki/pki-tomcat/alias -n "auditSigningCert cert-pki-ca" -c 'dogtag-ipa-ca-renew-agent' -P [internal PIN] -B /usr/libexec/ipa/certmonger/stop_pkicad -C '/usr/libexec/ipa/certmonger/renew_ca_cert "auditSigningCert cert-pki-ca"'
    
    # getcert start-tracking -d /etc/pki/pki-tomcat/alias -n "ocspSigningCert cert-pki-ca" -c 'dogtag-ipa-ca-renew-agent' -P [internal PIN] -B /usr/libexec/ipa/certmonger/stop_pkicad -C '/usr/libexec/ipa/certmonger/renew_ca_cert "ocspSigningCert cert-pki-ca"'
    
    # getcert start-tracking -d /etc/pki/pki-tomcat/alias -n "subsystemCert cert-pki-ca" -c 'dogtag-ipa-ca-renew-agent' -P [internal PIN] -B /usr/libexec/ipa/certmonger/stop_pkicad -C '/usr/libexec/ipa/certmonger/renew_ca_cert "subsystemCert cert-pki-ca"'
    
    # getcert start-tracking -d /etc/pki/pki-tomcat/alias -n "Server-Cert cert-pki-ca" -c 'dogtag-ipa-ca-renew-agent' -P [internal PIN] -B /usr/libexec/ipa/certmonger/stop_pkicad -C '/usr/libexec/ipa/certmonger/renew_ca_cert "Server-Cert cert-pki-ca"'
  3. 残りの IdM 証明書、HTTP 証明書、LDAP 証明書、IPA 更新エージェント 証明書、および PKINIT 証明書の追跡を追加します。

    # getcert start-tracking -f /var/lib/ipa/certs/httpd.crt -k /var/lib/ipa/private/httpd.key -p /var/lib/ipa/passwds/idm.example.com-443-RSA -c IPA -C /usr/libexec/ipa/certmonger/restart_httpd
    
    # getcert start-tracking -d /etc/dirsrv/slapd-IDM-EXAMPLE-COM -n "Server-Cert" -c IPA -p /etc/dirsrv/slapd-IDM-EXAMPLE-COM/pwdfile.txt -C '/usr/libexec/ipa/certmonger/restart_dirsrv "IDM-EXAMPLE-COM"'
    
    # getcert start-tracking -f /var/lib/ipa/ra-agent.pem -k /var/lib/ipa/ra-agent.key -c dogtag-ipa-ca-renew-agent -B /usr/libexec/ipa/certmonger/renew_ra_cert_pre -C /usr/libexec/ipa/certmonger/renew_ra_cert
    
    # getcert start-tracking -f /var/kerberos/krb5kdc/kdc.crt -k /var/kerberos/krb5kdc/kdc.key -c dogtag-ipa-ca-renew-agent -B /usr/libexec/ipa/certmonger/renew_ra_cert_pre -C /usr/libexec/ipa/certmonger/renew_kdc_cert
  4. certmonger を再起動します。

    # systemctl restart certmonger
  5. certmonger の起動後 1 分待ってから、新しい証明書の状況を確認します。

    # getcert list

関連情報

第20章 IdM を管理する AD ユーザーの有効化

20.1. AD ユーザーの ID のオーバーライド

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 を完全に管理できるようになります。

注記

IdM の一部の機能は、AD ユーザーには現在利用できません。たとえば、IdM の admins グループに所属する AD ユーザーが、IdM ユーザーのパスワードを設定することはできません。

20.2. IdM を管理する AD ユーザーを有効にする ID オーバーライドの使用

前提条件

  • IdM サーバーで idm:DL1 ストリームが有効になっていて、このストリームで配信される RPM に切り替えている。

    # yum module enable idm:DL1
    # yum distro-sync
  • idm:DL1/adtrust プロファイルが IdM サーバーにインストールされている。

    # yum module install idm:DL1/adtrust

    このプロファイルに、ipa-idoverride-memberof パッケージなど、Active Directory と信頼関係を結ぶ IdM サーバーのインストールに必要なパッケージがすべて含まれている。

  • Identity Management 環境が設定され動作している。詳細は『Identity Management のインストール』を参照してください。
  • Identity Management 環境と Active Directory との間の信頼関係が設定され動作している。

手順

この手順では、Active Directory (AD) ユーザーの ID オーバーライドを作成して使用し、Identity Management (IdM) ユーザーと同じ権限を付与する方法を説明します。この手順は、信頼コントローラーまたは信頼エージェントとして設定した IdM サーバーで行います。信頼コントローラーおよび信頼エージェントの詳細は、 『Identity Management の計画』「信頼コントローラーおよび信頼エージェント」を参照してください。

  1. IdM 管理者として、Default Trust View で AD ユーザーの ID オーバーライドを作成します。たとえば、ad_user@ad.example.com ユーザーの ID オーバーライドを作成するには、次のコマンドを実行します。

    # kinit admin
    # ipa idoverrideuser-add 'default trust view' ad_user@ad.example.com
  2. Default Trust View から IdM グループに、ID オーバーライドをメンバーとして追加します。問題のグループが IdM ロールのメンバーである場合に、ID オーバーライドで示した AD ユーザーは、IdM API (コマンドラインインターフェース、IdM の Web UI など) を使用する場合に、ロールにより付与されたすべての権限を取得します。たとえば、ad_user@ad.example.com ユーザーの ID オーバーライドを admins グループに追加するには、次のコマンドを実行します。

    # ipa group-add-member admins --idoverrideusers=ad_user@ad.example.com

20.3. AD ユーザーとして IdM コマンドラインインターフェース (CLI) の管理

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

  1. IdM 管理者の、現在の Kerberos チケットを破棄します。

    # kdestroy -A
    注記

    MIT Kerberos の GSSAPI 実装が優先的にターゲットサービスの領域 (この場合は IdM レルム) から認証情報を選択するため、Kerberos チケットの破棄が必要です。認証情報のキャッシュコレクション (つまりタイプが KCM:、KEYRING:、または DIR: の認証情報キャッシュ) が使用されている場合は、IdM API へのアクセスに、AD ユーザーの認証情報ではなく、取得しておいた admin またはその他の IdM プリンシパルの認証情報が使用されます。

  2. ID オーバーライドが作成された AD ユーザーの Kerberos 認証情報を入手します。

    # kinit ad_user@AD.EXAMPLE.COM
    Password for ad_user@AD.EXAMPLE.COM:
  3. AD ユーザーの ID オーバーライド使用する、IdM グループのメンバーシップから生じるパーミッションが、そのグループ内の任意の IdM ユーザーと同じものであることをテストします。AD ユーザーの ID オーバーライドが admins グループに追加されている場合、AD ユーザーは、たとえば IdM にグループを作成できます。

    # ipa group-add some-new-group
    ----------------------------
    Added group "some-new-group"
    ----------------------------
      Group name: some-new-group
      GID: 1997000011

第21章 IdM で標準 DNS ホスト名の使用

DNS 正規化は、潜在的なセキュリティーリスクを回避するために、IdM クライアントでデフォルトで無効になっています。たとえば、攻撃者がドメインの DNS サーバーとホストを制御すると、短いホスト名の demomalicious.example.com に解決される可能性があります。この場合、ユーザーは想定とは異なるサーバーに接続します。

本セクションでは、IdM クライアントで正規化されたホスト名を使用する方法を説明します。

21.1. ホストプリンシパルへのエイリアスの追加

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

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

前提条件

  • IdM クライアントがインストールされている。
  • ホスト名が、ネットワーク内で一意の名前である。

手順

  1. admin ユーザーとして、IdM に対して認証します。

    $ kinit admin
  2. エイリアスをホストプリンシパルに追加します。たとえば、demo エイリアスを、demo.examle.com ホストプリンシパルに追加するには、次のコマンドを実行します。

    $ ipa host-add-principal demo.example.com --principal=demo

21.2. クライアントのサービスプリンシパルでのホスト名の正規化の有効化

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

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

前提条件

  • IdM クライアントがインストールされている。
  • root ユーザーとして IdM クライアントにログインしている。
  • ホスト名が、ネットワーク内で一意の名前である。

手順

  1. /etc/krb5.conf ファイルの [libdefaults] セクションで、dns_canonicalize_hostname パラメーターを false に設定します。

    [libdefaults]
    ...
    dns_canonicalize_hostname = true

21.3. DNS ホスト名の正規化を有効にしてホスト名を使用するためのオプション

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

  • IdM 環境では、host/demo.example.com@EXAMPLE.COM などのサービスプリンシパルで完全なホスト名を使用できます。
  • IdM がない環境では、RHEL ホストを Active Directory (AD) ドメインのメンバーとする場合に、AD ドメインコントローラー (DC) が、Active Directory に登録されているマシンの NetBIOS 名のサービスプリンシパルを自動的に作成するため、考慮が必要な事項は必要ありません。

第22章 IdM Healthcheck 情報の収集

Healthcheck は、Identity Management で発生する可能性がある問題を特定するのを助ける手動コマンドラインツールとして設計されました。

本章では、30 日間のローテーションで Healthcheck の出力に基づいてログのコレクションを作成する方法を説明します。

前提条件

  • Healthcheck ツールは、RHEL 8.1 以降でのみ利用できます。

22.1. IdM のヘルスチェック

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

注記

Healthcheck ツールは、Kerberos 認証なしで使用できるコマンドラインツールです。

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

  • レプリケーションの問題
  • 証明書の検証
  • CA インフラストラクチャー
  • IdM および AD 信頼の問題
  • ファイルのパーミッションと所有権

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

  • コマンドラインで、人間が判読できる出力
  • JSON 形式で、マシンが判読できる出力

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

  • SUCCESS
  • WARNING
  • ERROR
  • CRITICAL

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

  • 手動

    # ipa-healthcheck

    すべてのオプションは、man ページの man ipa-healthcheck を参照してください。

  • ログローテーションの自動使用

22.2. ログローテーション

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

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

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

22.3. IdM Healthcheck でログローテーションの設定

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

  • systemd タイマー
  • crond サービス

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

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

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

前提条件

  • root でコマンドを実行できる。

手順

  1. systemd タイマーを有効にします。

    # systemctl enable ipa-healthcheck.timer
    Created symlink /etc/systemd/system/multi-user.target.wants/ipa-healthcheck.timer -> /usr/lib/systemd/system/ipa-healthcheck.timer.
  2. systemd タイマーを起動します。

    # systemctl start ipa-healthcheck.timer
  3. /etc/logrotate.d/ipahealthcheck ファイルを開いて、保存すべきログの数を設定します。

    デフォルトでは、ログローテーションは 30 日間設定されます。

  4. /etc/logrotate.d/ipahealthcheck ファイルで、ログへのパスを設定します。

    デフォルトでは、ログは /var/log/ipa/healthcheck/ ディレクトリーに保存されます。

  5. /etc/logrotate.d/ipahealthcheck ファイルで、ログ生成の時間を設定します。

    デフォルトでは、ログは毎日 4 am に作成されます。

  6. ログローテーションを使用するには、crond サービスが有効になっており、実行していることを確認します。

    # systemctl enable crond
    # systemctl start crond

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

# systemctl start ipa-healthcheck

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

第23章 IdM Healthcheck でサービスの確認

本セクションでは、Healthcheck ツールを使用して、Identity Management (IdM) サーバーが使用する監視サービスを説明します。

詳細は「IdM のヘルスチェック」を参照してください。

前提条件

  • Healthcheck ツールは、RHEL 8.1 以降でのみ利用できます。

23.1. サービスの Healthcheck テスト

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

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

# ipa-healthcheck --list-sources

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

  • certmonger
  • dirsrv
  • gssproxy
  • httpd
  • ipa_custodia
  • ipa_dnskeysyncd
  • ipa_otpd
  • kadmin
  • krb5kdc
  • named
  • pki_tomcatd
  • sssd
注記

問題を確認したい場合は、すべての IdM マスターサーバーで上記のテストを実行します。

23.2. Healthcheck でサービスのスクリーニング

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

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

  • 成功したテストをすべて除外する - --failures-only
  • サービステストのみを含める - --source=ipahealthcheck.meta.services

手順

  • サービスに関する警告、エラー、および重大な問題で Healthcheck を実行するには、次のコマンドを実行します。

    # ipa-healthcheck --source=ipahealthcheck.meta.services --failures-only

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

[ ]

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

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

関連情報

  • 詳細な参照を確認するには、コマンドラインで man ipa-healthcheck を実行します。

第24章 Healthcheck ツールで IdM および AD の信頼設定の確認

本セクションでは、Identity Management (IdM) の Healthcheck ツールを理解および使用して、IdM と Active Directory 信頼に関する問題を特定する方法を説明します。

詳細は「IdM のヘルスチェック」を参照してください。

前提条件

  • Healthcheck ツールは、RHEL 8.1 以降でのみ利用できます。

24.1. IdM および AD の 信頼 Healthcheck のテスト

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

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

# ipa-healthcheck --list-sources

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

IPATrustAgentCheck
このテストは、マシンが信頼エージェントとして設定されている場合に、SSSD 設定を確認します。/etc/sssd/sssd.conf 内の各ドメインで、id_provider=ipa は、ipa_server_modeTrue であることを確認します。
IPATrustDomainsCheck
このテストでは、sssctl domain-list のドメインの一覧を、IPA ドメインを除く ipa trust-find のドメインの一覧と比較して、信頼ドメインが SSSD ドメインと一致するかどうかを確認します。
IPATrustCatalogCheck

このテストでは、AD ユーザー Administrator@REALM を解決します。これにより、sssctl domain-status の出力に、AD Global カタログと AD Domain Controller の値が追加されます。

各信頼ドメインに対して、SID + 500 (管理者) の ID でユーザーを検索し、sssctl domain-status <domain> --active-server の出力を確認して、ドメインがアクティブであることを確認します。

IPAsidgenpluginCheck
このテストは、IPA 389-ds インスタンスで sidgen プラグインが有効になっていることを確認します。このテストでは、cn=plugins,cn=configIPA SIDGEN プラグインおよび ipa-sidgen-task プラグインに、nsslapd-pluginEnabled オプションが含まれていることを検証しています。
IPATrustAgentMemberCheck
このテストでは、現在のホストが cn=adtrust agents,cn=sysaccounts,cn=etc,SUFFIX のメンバーであることを確認します。
IPATrustControllerPrincipalCheck
このテストでは、現在のホストが cn=adtrust agents,cn=sysaccounts,cn=etc,SUFFIX のメンバーであることを確認します。
IPATrustControllerServiceCheck
このテストは、現在のホストが ipactl で ADTRUST サービスを開始することを確認します。
IPATrustControllerConfCheck
このテストでは、ldapi は、net conf リストの出力で passdb バックエンドに対して有効になっていることを確認します。
IPATrustControllerGroupSIDCheck
このテストは、admins グループの SID が 512 (Domain Admins RID) で終わることを確認します。
IPATrustPackageCheck
このテストは、信頼コントローラーと AD 信頼が有効になっていない場合に、trust-ad パッケージがインストールされていることを確認します。
注記

問題を確認する場合は、すべての IdM マスターサーバーで上記のテストを実行します。

24.2. Healthcheck ツールを使用した信頼のスクリーニング

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

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

  • 成功したテストをすべて除外する - --failures-only
  • 信頼テストのみを含める - --source=ipahealthcheck.ipa.trust

手順

  • 信頼における警告、エラー、および重大な問題ついて Healthcheck を実行するには、次のコマンドを実行します。

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

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

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

関連情報

  • 詳細な参照を確認するには、コマンドラインで man ipa-healthcheck を実行します。

第25章 IdM Healthcheck で証明書の検証

本セクションでは、Identity Management (IdM) で Healthcheck ツールを理解して、certmonger が維持する IPA 証明書の問題を特定する方法を説明します。

詳細は「IdM のヘルスチェック」を参照してください。

前提条件

  • Healthcheck ツールは、RHEL 8.1 以降でのみ利用できます。

25.1. IdM 証明書の Healthcheck テスト

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

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

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

# ipa-healthcheck --list-sources

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

IPACertmongerExpirationCheck

このテストは、certmonger の有効期限を確認します。

証明書の有効期限が切れている場合は、エラーが報告されます。

証明書の有効期限が間近な場合は、警告が表示されます。デフォルトでは、このテストは、証明書の有効期限が 28 日以内のものを対象としています。

/etc/ipahealthcheck/ipahealthcheck.conf ファイルで日数を設定できます。ファイルを開くと、デフォルトセクションにある cert_expiration_days オプションを変更します。

注記

certmonger は証明書の有効期限に関する独自のビューを読み込んで維持します。この確認では、ディスク上の証明書は検証されません。

IPACertfileExpirationCheck

このテストは、証明書ファイルまたは NSS データベースを開けないかを確認します。このテストでは、有効期限も確認します。したがって、エラー出力または警告の出力で、msg 属性を慎重に読み取ります。このメッセージは問題を指定します。

注記

このテストでは、ディスク上の証明書が確認されます。証明書がない、読み取りができないなどの問題が発生した場合は、別のエラーを出力することもできます。

IPACertNSSTrust
このテストは、NSS データベースに保存されている証明書の信頼を比較します。NSS データベースで期待される、追跡された証明書では、信頼が、期待される値と比較され、一致しないとエラーが発生します。
IPANSSChainValidation
このテストは、NSS 証明書の証明書チェーンを検証します。テストは、certutil -V -u V -e -d [dbdir] -n [nickname] を実行します。
IPAOpenSSLChainValidation

このテストは、OpenSSL 証明書の証明書チェーンを検証します。NSSChain 検証を比較するには、以下を実行する OpenSSL コマンドになります。

openssl verify -verbose -show_chain -CAfile /etc/ipa/ca.crt [cert file]
IPARAAgent
このテストは、ディスクの証明書を、uid=ipara,ou=People,o=ipaca の LDAP の同等のレコードと比較します。
IPACertRevocation
このテストは certmonger を使用して、証明書が取り消されていないことを確認します。したがって、テストでは certmonger でのみメンテナンスされる証明書に接続している問題を見つけることができます。
IPACertmongerCA

このテストでは、certmonger の Certificate Authority (CA) の設定を検証します。IdM は、CA を使用しない証明書を発行できません。

certmonger は、CA ヘルパーのセットを維持します。IdM には、IdM を介して証明書を発行し、ホストまたはサービスの証明書に対して、ホストまたはユーザーのプリンシパルとして認証する IPA という名前の CA があります。

また、CA サブシステム証明書を更新する dogtag-ipa-ca-renew-agent および dogtag-ipa-ca-renew-agent-reuse があります。

注記

問題を確認する場合は、すべての IdM マスターサーバーで上記のテストを実行します。

25.2. Healthcheck ツールで証明書のスクリーニング

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

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

  • 成功したテストをすべて除外する - --failures-only
  • 証明書テストのみを含める - --source=ipahealthcheck.ipa.certs

前提条件

  • Healthcheck テストは root ユーザーで実行する。

手順

  • 証明書に関する警告、エラー、および重大な問題で Healthcheck を実行するには、次のコマンドを実行します。

    # ipa-healthcheck --source=ipahealthcheck.ipa.certs --failures-only

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

[]

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

{
  "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 データベースを開く際に失敗します。

関連情報

  • 詳細な参照を確認するには、コマンドラインで man ipa-healthcheck を実行します。

第26章 Healthcheck で Dogtag 証明書の検証

本セクションでは、Identity Management (IdM) の Healthcheck ツールを説明し、Dogtag 証明書の問題を特定します。

詳細は「IdM のヘルスチェック」を参照してください。

前提条件

  • Healthcheck ツールは、RHEL 8.1 以降でのみ利用できます。

26.1. DogTag の Healthcheck テスト

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

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

# ipa-healthcheck --list-sources

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

DogtagCertsConfigCheck

このテストは、その NSS データベースの CA (認証局) 証明書を、CS.cfg に保存されているものと同じ値と比較します。一致しないと、CA は起動できません。

具体的には、以下を確認します。

  • ca.audit_signing.cert の場合は auditSigningCert cert-pki-ca
  • ca.ocsp_signing.cert の場合は ocspSigningCert cert-pki-ca
  • ca.signing.cert の場合は caSigningCert cert-pki-ca
  • ca.subsystem.cert の場合は subsystemCert cert-pki-ca
  • ca.sslserver.cert の場合は Server-Cert cert-pki-ca

Key Recovery Authority (KRA) がインストールされている場合は、以下になります。

  • ca.connector.KRA.transportCert の場合は transportCert cert-pki-kra
DogtagCertsConnectivityCheck

このテストでは、接続性を検証します。このテストは、以下の確認を行う ipa cert-show 1 コマンドと同等です。

  • Apache の PKI プロキシー設定
  • CA を見つけることができる IdM
  • RA エージェントクライアント証明書
  • 要求に対する CA 返信の正確性

テストは、cert-show を実行し、CA から期待される結果 (証明書または「not fount」) を返すため、シリアル番号 #1 の証明書を確認します。

注記

問題を確認する場合は、すべての IdM マスターサーバーで上記のテストを実行します。

26.2. Healthcheck で Dogtag 証明書のスクリーニング

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

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

手順

  • Healthcheck を Dogtag 証明書に制限して実行するには、次のコマンドを実行します。

    # ipa-healthcheck --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",
    }
}

関連情報

  • 詳細な参照を確認するには、コマンドラインで man ipa-healthcheck を実行します。

第27章 IdM Healthcheck でディスク領域の確認

本セクションでは、Healthcheck ツールを使用して Identity Management サーバーの空きディスク容量を監視する方法を説明します。

詳細は「IdM のヘルスチェック」を参照してください。

前提条件

  • Healthcheck ツールは、RHEL 8.1 以降でのみ利用できます。

27.1. ディスク領域のヘルスチェックのテスト

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

  • ロギング
  • 実行
  • バックアップ

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

表27.1 テスト済みのパス

テストで確認されるパス最小ディスク領域 (MB)

/var/lib/dirsrv/

1024

/var/lib/ipa/backup/

512

/var/log/

1024

var/log/audit/

512

/var/tmp/

512

/tmp/

512

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

# ipa-healthcheck --list-sources

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

FileSystemSpaceCheck

このテストでは、次の方法で使用可能なディスク容量を確認します。

  • 最低限必要な生の空きバイト。
  • パーセント - 空きディスクの最小容量は 20% にハードコーディングされています。

27.2. Healthcheck ツールでディスク領域のスクリーニング

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

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

  • 成功したテストをすべて除外する - --failures-only
  • 容量の確認テストのみを含める - --source=ipahealthcheck.system.filesystemspace

手順

  • ディスク領域に関する警告、エラー、および重大な問題で Healthcheck を実行するには、次のコマンドを実行します。

    # ipa-healthcheck --source=ipahealthcheck.system.filesystemspace --failures-only

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

[]

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

{
  "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 ディレクトリーの容量が不足しているためにテストに失敗したことが通知されます。

関連情報

  • 詳細な参照を確認するには、コマンドラインで man ipa-healthcheck を実行します。

第28章 Healthcheck で IdM 設定ファイルの権限の確認

本セクションでは、Healthcheck ツールを使用して、Identity Management (IdM) 設定ファイルをテストする方法を説明します。

詳細は「IdM のヘルスチェック」を参照してください。

前提条件

  • Healthcheck ツールは、RHEL 8.1 以降でのみ利用できます。

28.1. ファイルパーミッションの Healthcheck テスト

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

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

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

# ipa-healthcheck --list-sources

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

IPAFileNSSDBCheck
このテストは、389-ds NSS データベースと認証局 (CA) データベースを確認します。389-ds データベースは、/etc/dirsrv/slapd-<dashed-REALM> にあり、CA データベースは /etc/pki/pki-tomcat/alias/ にあります。
IPAFileCheck

このテストは以下のファイルを確認します。

  • /var/lib/ipa/ra-agent.{key|pem}
  • /var/lib/ipa/certs/httpd.pem
  • /var/lib/ipa/private/httpd.key
  • /etc/httpd/alias/ipasession.key
  • /etc/dirsrv/ds.keytab
  • /etc/ipa/ca.crt
  • /etc/ipa/custodia/server.keys

    PKINIT が有効になっている場合は、以下のファイルを確認します。

  • /var/lib/ipa/certs/kdc.pem
  • /var/lib/ipa/private/kdc.key

    DNS が設定されている場合は、以下のファイルを確認します。

  • /etc/named.keytab
  • /etc/ipa/dnssec/ipa-dnskeysyncd.keytab
TomcatFileCheck

このテストは、CA が設定されている場合に、いくつかの tomcat 固有のファイルを確認します。

  • /etc/pki/pki-tomcat/password.conf
  • /var/lib/pki/pki-tomcat/conf/ca/CS.cfg
  • /etc/pki/pki-tomcat/server.xml
注記

問題を確認する場合は、すべての IdM マスターサーバーで上記のテストを実行します。

28.2. Healthcheck で設定ファイルのスクリーニング

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

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

  • 成功したテストをすべて除外する - --failures-only
  • 所有者テストとパーミッションテストのみを含める - --source=ipahealthcheck.ipa.files

手順

  1. 警告、エラー、重大な問題のみを表示しながら、IdM 設定ファイルの所有権とパーミッションで Healthcheck テストを実行するには、次のように入力します。

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

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

# 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"
  }
}

関連情報

  • 詳細な参照資料を確認するには、コマンドラインで man ipa-healthcheck を開きます。

第29章 Healthcheck で IdM レプリケーションの確認

本セクションでは、Healthcheck ツールを使用して Identity Management (IdM) レプリケーションをテストする方法を説明します。

詳細は「IdM のヘルスチェック」を参照してください。

前提条件

  • Healthcheck ツールは、RHEL 8.1 以降でのみ利用できます。

29.1. レプリケーションの Healthcheck テスト

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

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

# ipa-healthcheck --list-sources

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

IPATopologyDomainCheck

このテストでは、以下が検証されます。

  • トポロジーが切断されておらず、すべてのサーバー間にレプリケーションパスがあるかどうか。
  • サーバーに推奨される数以上のレプリカ合意がない場合。

    テストに失敗すると、テストは、接続エラーや、レプリカ合意が多すぎるなど、エラーを返します。

    テストに成功すると、テストにより設定済みのドメインが返されます。

    注記

    テストは、ドメインおよび ca 接尾辞の両方で ipa topologysuffix-verify コマンドを実行します (認証局がこのマスターに設定されていることを前提とします)。

ReplicationConflictCheck
テストにより、(&(!(objectclass=nstombstone))(nsds5ReplConflict=*)) に一致する LDAP エントリーを検索します。
注記

問題を確認する場合は、すべての IdM マスターサーバーで上記のテストを実行します。

29.2. Healthcheck でレプリケーションのスクリーニング

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

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

  • レプリケーションの競合テスト - --source=ipahealthcheck.ds.replication
  • 正確なトポロジーテスト - --source=ipahealthcheck.ipa.topology

前提条件

  • Healthcheck テストは root ユーザーで実行する。

手順

  • Healthcheck のレプリケーションの競合とトポロジーの確認を実行するには、次のコマンドを実行します。

    # ipa-healthcheck --source=ipahealthcheck.ds.replication --source=ipahealthcheck.ipa.topology

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

  • SUCCESS  - テストが成功

    {
      "source": "ipahealthcheck.ipa.topology",
      "check": "IPATopologyDomainCheck",
      "result": "SUCCESS",
      "kw": {
        "suffix": "domain"
      }
    }
  • WARNING - テストには合格したが、問題の可能性あり
  • ERROR - テストが失敗

    {
      "source": "ipahealthcheck.ipa.topology",
      "check": "IPATopologyDomainCheck",
      "result": "ERROR",
      "uuid": d6ce3332-92da-423d-9818-e79f49ed321f
      "when": 20191007115449Z
      "duration": 0.005943
      "kw": {
        "msg": "topologysuffix-verify domain failed, server2 is not connected (server2_139664377356472 in MainThread)"
      }
    }
  • CRITICAL - テストが失敗し、IdM サーバー機能に影響が及ぶ

関連情報

  • 詳細な参照を確認するには、コマンドラインで man ipa-healthcheck を開きます。

第30章 非表示レプリカの降格または昇格

レプリカのインストール後、レプリカの表示状態を変更できます。

非表示のレプリカの詳細は、「非表示のレプリカモード」を参照してください。

レプリカが CA Renewal Master である場合は、サービスを別のレプリカに移動します。詳細は「IdM CA Renewal Master の変更およびリセット」を参照してください。

注記

非表示のレプリカ機能は、Red Hat Enterprise Linux 8.1 以降でテクノロジープレビューとして利用でき、サポート対象外となります。

手順

  • レプリカを非表示にするには、次のコマンドを実行します。

    # ipa server-state replica.idm.example.com --state=hidden

    次のコマンドを実行すれば、レプリカを表示できます

    # ipa server-state replica.idm.example.com --state=enabled

法律上の通知

Copyright © 2019 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.