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 ドキュメントへのフィードバック (英語のみ)

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

  • 特定の文章に簡単なコメントを記入する場合は、以下の手順を行います。

    1. ドキュメントの表示が Multi-page HTML 形式になっていて、ドキュメントの右上端に Feedback ボタンがあることを確認してください。
    2. マウスカーソルで、コメントを追加する部分を強調表示します。
    3. そのテキストの下に表示される Add Feedback ポップアップをクリックします。
    4. 表示される手順に従ってください。
  • より詳細なフィードバックを行う場合は、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 サービスを起動、停止、または再起動する場合は、以下を参照してください。

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 に対応する設定を修正することです。

2.4. IdM ソフトウェアのバージョンを表示する方法

IdM バージョン番号は次の方法で表示できます。

  • IdM WebUI
  • ipa コマンド
  • rpm コマンド

 

WebUI を介したバージョンの表示

IdM WebUI では、右上のユーザー名メニューから About を選択して、ソフトウェアバージョンを表示できます。

IdM ソフトウェアバージョンの確認
ipa コマンドによるバージョンの表示

コマンドラインから、ipa --version コマンドを使用します。

[root@server ~]# ipa --version
VERSION: 4.8.0, API_VERSION: 2.233
rpm コマンドによるバージョンの表示

IdM サービスが適切に動作していない場合は、rpm ユーティリティーを使用して、現在インストールされている ipa-server パッケージのバージョン番号を確認できます。

[root@server ~]# rpm -q ipa-server
ipa-server-4.8.0-11.module+el8.1.0+4247+9f3fd721.x86_64

第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) データベースに追加する方法を説明します。

前提条件

  • 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 search limits

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

第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 login screen

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

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

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

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

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

    web ui login passwd

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

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

web ui users

第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 browser config link

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

    ipa browser config page

設定が完了したら、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 users

  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 tokens tab

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

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

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

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

freeotp token

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 users

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

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

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

前提条件

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

手順

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

    web ui login otp link

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

    web ui login otp configuration

  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 passwd expiration

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

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

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

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

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

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

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

84 RHEL IdM 0420 life cycle

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

重要

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

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

警告

admin ユーザーを削除しないでください。admin は IdM で必要な事前定義ユーザーであるため、この操作では特定のコマンドで問題が生じます。代替の admin ユーザーを定義して使用する場合は、管理者パーミッションを少なくとも 1 人のユーザーに付与した後に ipa user-disable admin で事前定義された admin ユーザーを無効にします。

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

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

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

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

前提条件

手順

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

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

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

$ ipa $ ipa user-find

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

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

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

前提条件

手順

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

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

8.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 から永続的に削除されました。

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

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

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

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

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

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

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

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

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

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

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

84 RHEL IdM 0420 life cycle

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

重要

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

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

警告

admin ユーザーを削除しないでください。admin は IdM で必要な事前定義ユーザーであるため、この操作では特定のコマンドで問題が生じます。代替の admin ユーザーを定義して使用する場合は、管理者パーミッションを少なくとも 1 人のユーザーに付与した後に ipa user-disable admin で事前定義された admin ユーザーを無効にします。

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

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

注記

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

前提条件

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

手順

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

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

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

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

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

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

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

    idm user add stage

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

idm users stage

注記

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

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

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

前提条件

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

手順

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

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

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

    idm users stage

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

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

idm users stage activated

注記

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

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

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

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

注記

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

前提条件

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

手順

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

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

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

    idm users disable

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

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

idm users disabled

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

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

前提条件

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

手順

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

    idm users disable

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

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

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

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

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

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

注記

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

前提条件

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

手順

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

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

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

    idm users active delete

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

    idm users preserving

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

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

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

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

前提条件

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

手順

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

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

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

    idm users preserved restore

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

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

9.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 から完全に削除されました。

第10章 Ansible Playbook を使用したユーザーアカウントの管理

Ansible Playbook を使用して IdM のユーザーを管理できます。本章では、以下の操作に Ansible Playbook を使用する方法について説明します。

10.1. Ansible Playbook を使用した IdM ユーザーの存在の確認

以下の手順では、Ansible Playbook を使用して IdM にユーザーが存在することを確認する方法を説明します。

前提条件

  • IdM 管理者パスワードを知っている。
  • ansible-freeipa パッケージが Ansible コントローラーにインストールされている。

手順

  1. inventory.file などのインベントリーファイルを作成し、そのファイルに ipaserver を定義します。

    [ipaserver]
    server.idm.example.com
  2. IdM に存在するユーザーのデータで Ansible Playbook ファイルを作成します。この手順を単純化するには、/usr/share/doc/ansible-freeipa/playbooks/user/add-user.yml ファイルのサンプルをコピーして変更できます。たとえば、idm_user という名前のユーザーを作成し、Password123 をユーザーパスワードとして追加するには、次のコマンドを実行します。

    ---
    - name: Playbook to handle users
      hosts: ipaserver
      become: true
    
      tasks:
      - name: Create user idm_user
        ipauser:
          ipaadmin_password: MySecret123
          name: idm_user
          first: Alice
          last: Acme
          uid: 1000111
          gid: 10011
          phone: "+555123457"
          email: idm_user@acme.com
          passwordexpiration: "2023-01-19 23:59:59"
          password: "Password123"
          update_password: on_create

    ユーザーを追加するには、以下のオプションを使用する必要があります。

    • 名前: ログイン名
    • first: 最初の name 文字列
    • last: 最後の名前文字列

    利用可能なユーザーオプションの完全な一覧は、/usr/share/doc/ansible-freeipa/README-user.md Markdown ファイルを参照してください。

    注記

    update_password: on_create オプションを使用する場合、Ansible はユーザーの作成時にのみユーザーパスワードを作成します。ユーザーがパスワードで作成されている場合、Ansible は新しいパスワードを生成しません。

  3. Playbook を実行します。

    $ ansible-playbook -v -i path_to_inventory_directory/inventory.file path_to_playbooks_directory/add-IdM-user.yml

検証手順

  • ipa user-show コマンドを使用して、新しいユーザーアカウントが IdM に存在するかどうかを確認できます。

    1. admin として ipaserver にログインします。

      $ ssh admin@server.idm.example.com
      Password:
      [admin@server /]$
    2. admin の Kerberos チケットを要求します。

      $ kinit admin
      Password for admin@IDM.EXAMPLE.COM:
    3. idm_user に関する情報を要求します。

      $ ipa user-show idm_user
        User login: idm_user
        First name: Alice
        Last name: Acme
        ....

    idm_userという名前のユーザー が IdM に存在する。

10.2. Ansible Playbook を使用した複数の IdM ユーザーの存在の確保

以下の手順では、Ansible Playbook を使用して IdM に複数のユーザーが存在することを確認する方法を説明します。

前提条件

  • IdM 管理者パスワードを知っている。
  • Ansible コントローラーに ansible-freeipa パッケージがインストールされている。

手順

  1. inventory.file などのインベントリーファイルを作成し、そのファイルに ipaserver を定義します。

    [ipaserver]
    server.idm.example.com
  2. IdM に存在するユーザーのデータで Ansible Playbook ファイルを作成します。この手順を単純化するには、/usr/share/doc/ansible-freeipa/playbooks/user/ensure-users-present.yml ファイルのサンプルをコピーして変更できます。たとえば、ユーザー idm_user_1idm_user_2、および idm_user_3 を作成し、Password123idm_user_1 のパスワードとして追加するには、次のコマンドを実行します。

    ---
    - name: Playbook to handle users
      hosts: ipaserver
      become: true
    
      tasks:
      - name: Create user idm_users
        ipauser:
          ipaadmin_password: MySecret123
          users:
          - name: idm_user_1
            first: Alice
            last: Acme
            uid: 10001
            gid: 10011
            phone: "+555123457"
            email: idm_user@acme.com
            passwordexpiration: "2023-01-19 23:59:59"
            password: "Password123"
          - name: idm_user_2
            first: Bob
            last: Acme
            uid: 100011
            gid: 10011
          - name: idm_user_3
            first: Eve
            last: Acme
            uid: 1000111
            gid: 10011
    注記

    update_password: on_create オプションを指定しないと、Ansible は Playbook が実行されるたびにユーザーパスワードを再設定します。最後にプレイブックが実行されてからユーザーがパスワードを変更した場合、Ansibleはパスワードを再設定します。

  3. Playbook を実行します。

    $ ansible-playbook -v -i path_to_inventory_directory/inventory.file path_to_playbooks_directory/add-users.yml

検証手順

  • ipa user-show コマンドを使用して、ユーザーアカウントが IdM に存在するかどうかを確認できます。

    1. 管理者として ipaserver にログインします。

      $ ssh administrator@server.idm.example.com
      Password:
      [admin@server /]$
    2. idm_user_1 に関する情報を表示します。

      $ ipa user-show idm_user_1
        User login: idm_user_1
        First name: Alice
        Last name: Acme
        Password: True
        ....

    idm_user_1 という名前のユーザーが IdM に存在する。

10.3. Ansible Playbook を使用して JSON ファイルから複数の IdM ユーザーが存在することを確認する

以下の手順では、Ansible Playbook を使用して IdM に複数のユーザーが存在することを確認する方法を説明します。ユーザーは JSON ファイルに保存されます。

前提条件

  • IdM 管理者パスワードを知っている。
  • Ansible コントローラーに ansible-freeipa パッケージがインストールされている。

手順

  1. inventory.file などのインベントリーファイルを作成し、そのファイルに ipaserver を定義します。

    [ipaserver]
    server.idm.example.com
  2. 必要なタスクで Ansible Playbook ファイルを作成します。確認するユーザーのデータで JSON ファイルを参照します。この手順を単純化するには、/usr/share/doc/ansible-freeipa/ensure-users-present-ymlfile.yml ファイルのサンプルをコピーして変更できます。

    ---
    - name: Ensure users' presence
      hosts: ipaserver
      become: true
    
      tasks:
      - name: Include users.json
        include_vars:
          file: users.json
    
      - name: Users present
        ipauser:
          ipaadmin_password: Secret123
          users: "{{ users }}"
  3. users.json ファイルを作成し、IdM ユーザーを追加します。この手順を簡素化するには、/usr/share/doc/ansible-freeipa/playbooks/user/users.json ファイルのサンプルをコピーして変更できます。たとえば、ユーザー idm_user_1idm_user_2、および idm_user_3 を作成し、Password123idm_user_1 のパスワードとして追加するには、次のコマンドを実行します。

    {
      "users": [
       {
        "name": "idm_user_1",
        "first": "Alice",
        "last": "Acme",
        "password": "Password123"
       },
       {
        "name": "idm_user_2",
        "first": "Bob",
        "last": "Acme"
       },
       {
        "name": "idm_user_3",
        "first": "Eve",
        "last": "Acme"
       }
      ]
    }
  4. Playbook ファイルとインベントリーファイルを指定して Ansible Playbook を実行します。

    $ ansible-playbook -v -i path_to_inventory_directory/inventory.file path_to_playbooks_directory/ensure-users-present-jsonfile.yml

検証手順

  • ipa user-show コマンドを使用して、ユーザーアカウントが IdM に存在するかどうかを確認できます。

    1. 管理者として ipaserver にログインします。

      $ ssh administrator@server.idm.example.com
      Password:
      [admin@server /]$
    2. idm_user_1 に関する情報を表示します。

      $ ipa user-show idm_user_1
        User login: idm_user_1
        First name: Alice
        Last name: Acme
        Password: True
        ....

    idm_user_1 という名前のユーザーが IdM に存在する。

10.4. Ansible Playbook を使用したユーザー不足の確認

以下の手順では、Ansible Playbook を使用して、特定のユーザーが IdM に存在しないことを確認する方法を説明します。

前提条件

  • IdM 管理者パスワードを知っている。
  • Ansible コントローラーに ansible-freeipa パッケージがインストールされている。

手順

  1. inventory.file などのインベントリーファイルを作成し、そのファイルに ipaserver を定義します。

    [ipaserver]
    server.idm.example.com
  2. IdM がないユーザーで Ansible Playbook ファイルを作成します。この手順を単純化するには、/usr/share/doc/ansible-freeipa/playbooks/user/ensure-users-present.yml ファイルのサンプルをコピーして変更できます。たとえば、ユーザー idm_user_1idm_user_2、および idm_user_3 を削除するには、次のコマンドを実行します。

    ---
    - name: Playbook to handle users
      hosts: ipaserver
      become: true
      gather_facts: false
    
      tasks:
      - name: Delete users idm_user_1, idm_user_2, idm_user_3
        ipauser:
          ipaadmin_password: MySecret123
          users:
          - name: idm_user_1
          - name: idm_user_2
          - name: idm_user_3
          state: absent
  3. Playbook ファイルとインベントリーファイルを指定して Ansible Playbook を実行します。

    $ ansible-playbook -v -i path_to_inventory_directory/inventory.file path_to_playbooks_directory/delete-users.yml

検証手順

ipa user-show コマンドを使用して、ユーザーアカウントが IdM に存在しないことを確認できます。

  1. 管理者として ipaserver にログインします。

    $ ssh administrator@server.idm.example.com
    Password:
    [admin@server /]$
  2. idm_user_1 に関する要求情報

    $ ipa user-show idm_user_1
    ipa: ERROR: idm_user_1: user not found

    idm_user_1 という名前のユーザーは IdM に存在しません。

関連情報

  • /usr/share/doc/ansible-freeipa/ ディレクトリーで利用可能な README-user.md Markdown ファイルのユーザーの保存、削除、有効化、無効化、ロック解除、削除など、その他の IdM ユーザー関連のアクションのサンプル Ansible Playbook を確認できます。このファイルには、ipauser 変数の定義も含まれます。
  • /usr/share/doc/ansible-freeipa/playbooks/user ディレクトリーにサンプル Ansible Playbook を表示することもできます。

第11章 IdM CLI でのユーザーグループの管理

本章では、IdM CLI を使用したユーザーグループ管理について説明します。

ユーザーグループは、共通の特権、パスワードポリシーなどの持つユーザーのセットです。

Identity Management (IdM) のユーザーグループには以下が含まれます。

  • IdM ユーザー
  • 他の IdM ユーザーグループ
  • 外部ユーザー (IdM の外部に存在するユーザー)

11.1. IdM のさまざまなグループタイプ

IdM は、以下のタイプのグループをサポートします。

POSIX グループ (デフォルト)

POSIX グループは、メンバーの Linux POSIX 属性に対応します。Active Directory と対話するグループは POSIX 属性を使用できないことに注意してください。

POSIX 属性は、ユーザーを個別のエンティティーとして識別します。ユーザーに関連する POSIX 属性の例には、uidNumber (ユーザー番号 (UID))、および gidNumber (グループ番号 (GID)) が含まれます。

非 POSIX グループ

非 POSIX グループは、POSIX 属性に対応していません。たとえば、これらのグループには GID が定義されていません。

このタイプのグループのすべてのメンバーは、IdM ドメインに属している必要があります。

外部グループ

外部グループを使用して、以下のような IdM ドメイン外の ID ストアに存在するグループメンバーを追加できます。

  • ローカルシステム
  • Active Directory ドメイン
  • ディレクトリーサービス

外部グループは、POSIX 属性に対応していません。たとえば、これらのグループには GID が定義されていません。

表11.1 デフォルトで作成されたユーザーグループ

グループ名デフォルトのグループメンバー

ipausers

すべての IdM ユーザー

admins

管理権限を持つユーザー (デフォルトの admin ユーザーを含む)

editors

これは、特別な権限がなくなったレガシーグループです

trust admins

Active Directory 信頼を管理する権限を持つユーザー

ユーザーをユーザーグループに追加すると、ユーザーはグループに関連付けられた権限とポリシーを取得します。たとえば、ユーザーに管理権限を付与するには、ユーザーを admins グループに追加します。

警告

admins グループを削除しないでください。admins は IdM で必要な事前定義グループであるため、この操作により特定のコマンドで問題が生じます。

さらに、IdM で新しいユーザーが作成されるたびに、IdM は、デフォルトで ユーザーのプライベートグループ を作成します。プライベートグループの詳細は、「プライベートグループのないユーザーの追加」を参照してください。

11.2. 直接および間接のグループメンバー

IdM のユーザーグループ属性は、直接メンバーと間接メンバーの両方に適用されます。グループ B がグループ A のメンバーである場合、グループ B のすべてのユーザーはグループ A の間接メンバーと見なされます。

たとえば、以下の図では、以下のようになります。

  • ユーザー 1 とユーザー 2 は、グループ A の 直接メンバー です。
  • ユーザー 3、ユーザー 4、およびユーザー 5 は、グループ A の 間接メンバー です。

図11.1 直接および間接グループメンバーシップ

84 RHEL IdM 0420 ユーザーグループ

ユーザーグループ A にパスワードポリシーを設定すると、そのポリシーはユーザーグループ B のすべてのユーザーにも適用されます。

11.3. IdM CLI を使用したユーザーグループの追加

本セクションでは、IdM CLI を使用してユーザーグループを追加する方法を説明します。

前提条件

手順

  • ipa group-add group_name コマンドを使用してユーザーグループを追加します。たとえば、group_a を作成するには、次のコマンドを実行します。

    $ ipa group-add group_a
    ---------------------
    Added group "group_a"
    ---------------------
      Group name: group_a
      GID: 1133400009

    デフォルトでは、ipa group-add は、POSIX ユーザーグループを追加します。別のグループタイプを指定するには、ipa group-add にオプションを追加します。

    ユーザーグループの追加時にカスタムの GID を指定するには、--gid=custom_GID オプションを使用します。これを行う場合は、ID の競合を避けるように注意してください。カスタム GID を指定しない場合、IdM は使用可能な ID 範囲から GID を自動的に割り当てます。

11.4. IdM CLI を使用したユーザーグループの検索

本セクションでは、IdM CLI を使用して既存のユーザーグループを検索する方法を説明します。

手順

  • ipa group-find コマンドを使用して、すべてのユーザーグループを表示します。グループタイプを指定するには、ipa group-find にオプションを追加します。

    • ipa group-find --posix コマンドを使用して、すべての POSIX グループを表示します。
    • ipa group-find --nonposix コマンドを使用して、すべての非 POSIX グループを表示します。
    • ipa group-find --external コマンドを使用して、すべての外部グループを表示します。

      グループタイプの詳細は「IdM のさまざまなグループタイプ」を参照してください。

11.5. IdM CLI を使用したユーザーグループの削除

本セクションでは、IdM CLI を使用してユーザーグループを削除する方法を説明します。グループを削除しても、IdM からグループメンバーは削除されないことに注意してください。

前提条件

手順

  • ipa group-del group_name コマンドを使用してユーザーグループを削除します。たとえば、group_aを削除するには、次のコマンドを実行します。

    $ ipa group-del group_a
    --------------------------
    Deleted group "group_a"
    --------------------------

11.6. IdM CLI でユーザーグループにメンバーの追加

本セクションでは、IdM CLI を使用してユーザーグループにメンバーを追加する方法を説明します。ユーザーおよびユーザーグループの両方をユーザーグループのメンバーとして追加できます。詳細は「IdM のさまざまなグループタイプ」および「直接および間接のグループメンバー」を参照してください。

前提条件

手順

  • ipa group-add-member コマンドを使用して、ユーザーグループにメンバーを追加します。

    次のオプションを使用して、メンバーのタイプを指定します。

    • --users は、IdM ユーザーを追加します
    • --external は、DOMAIN\user_name 形式または user_name@domain 形式で、IdM ドメイン外に存在するユーザーを追加します
    • --groups は、IdM ユーザーグループを追加します。

    たとえば、group_b を group_a のメンバーとして追加するには、次のコマンドを実行します。

    $ ipa group-add-member group_a --groups=group_b
    Group name: group_a
    GID: 1133400009
    Member users: user_a
    Member groups: group_b
    Indirect Member users: user_b
    -------------------------
    Number of members added 1
    -------------------------

    group_b のメンバーは、group_a の間接メンバーになりました。

重要

グループを別のグループのメンバーとして追加する場合は、再帰グループを作成しないでください。たとえば、グループ A がグループ B のメンバーである場合は、グループ B をグループ A のメンバーとして追加しないでください。再帰的なグループにより予期しない動作が発生する可能性があります。

注記

ユーザーグループにメンバーを追加した後、更新が Identity Management 環境のすべてのクライアントに広がるまでに時間がかかる場合があります。これは、特定のホストがユーザー、グループ、およびネットグループを解決するときに、System Security Services Daemon (SSSD) が最初にキャッシュを調べて、サーバーで不足または期限切れのレコードのみを検索するためです。

11.7. ユーザープライベートグループなしでユーザーの追加

デフォルトでは、IdM で新しいユーザーが作成されるたびに、IdM がユーザーのプライベートグループ (UPG) を作成します。UPG は特定のグループタイプです。

  • UPG の名前は、新しく作成されたユーザーと同じです。
  • ユーザーは UPG の唯一のメンバーです。UPG には他のメンバーを含めることができません。
  • プライベートグループの GID は、ユーザーの UID と一致します。

ただし、UPG を作成せずにユーザーを追加することは可能です。

11.7.1. ユーザープライベートグループのないユーザー

NIS グループまたは別のシステムグループが、ユーザープライベートグループに割り当てられる GID を既に使用している場合は、UPG を作成しないようにする必要があります。

これは、以下の 2 つの方法で実行できます。

どちらの場合も、IdM では、新しいユーザーを追加するときに GID を指定する必要があります。指定しないと、操作は失敗します。これは、IdM には新しいユーザーの GID が必要ですが、デフォルトのユーザーグループ ipausers は非 POSIX グループであるため、関連付けられた GID がないためです。指定する GID は、既存のグループに対応する必要がありません。

注記

GID を指定しても、新しいグループは作成されません。この属性は IdM に必要であるため、新しいユーザーに GID 属性のみを設定します。

11.7.2. プライベートグループがグローバルに有効になっている場合にユーザープライベートグループのないユーザーを追加

システムで UPG が有効になっている場合でも、ユーザープライベートグループ (UPG) を作成せずにユーザーを追加できます。これには、新しいユーザーの GID を手動で設定する必要があります。これが必要な理由の詳細は、「ユーザープライベートグループのないユーザー」を参照してください。

手順

  • IdM が UPG を作成しないようにするには、ipa user-add コマンドに --noprivate オプションを追加します。

    コマンドを成功させるには、カスタム GID を指定する必要があることに注意してください。たとえば、GID 10000 の新しいユーザーを追加するには、次のコマンドを実行します。

    $ ipa user-add jsmith --first=John --last=Smith --noprivate --gid 10000

11.7.3. すべてのユーザーに対してユーザープライベートグループをグローバルに無効にする

ユーザープライベートグループ (UPG) をグローバルに無効にできます。これにより、すべての新しいユーザーの UPG が作成されなくなります。既存のユーザーはこの変更の影響を受けません。

手順

  1. 管理者権限を取得します。

    $ kinit admin
  2. IdM は、Directory Server Managed Entries プラグインを使用してUPG を管理します。プラグインのインスタンスを一覧表示します。

    $ ipa-managed-entries --list
  3. IdM が UPG を作成しないようにするには、ユーザープライベートグループを管理するプラグインインスタンスを無効にします。

    $ ipa-managed-entries -e "UPG Definition" disable
    Disabling Plugin
    注記

    後で UPG 定義 インスタンスを再有効にするには、ipa-managed-entries -e "UPG Definition" enable コマンドを使用します。

  4. Directory Server を再起動して、新しい構成を読み込みます。

    $ sudo systemctl restart dirsrv.target

    UPG が無効になった後にユーザーを追加するには、GID を指定する必要があります。詳細は、「ユーザープライベートグループがグローバルで無効になっている場合のユーザーの追加」を参照してください。

検証手順

  • UPG がグローバルで無効になっているかどうかを確認するには、再度 disable コマンドを使用します。

    $ ipa-managed-entries -e "UPG Definition" disable
    Plugin already disabled

11.7.4. ユーザープライベートグループがグローバルで無効になっている場合のユーザーの追加

ユーザープライベートグループ (UPG) がグローバルで無効になっている場合、IdM は GID を新しいユーザーに自動的に割り当てません。ユーザーを正常に追加するには、GID を手動で割り当てるか、自動メンバールールを使用して割り当てる必要があります。これが必要な理由は、「ユーザープライベートグループのないユーザー」を参照してください。

前提条件

手順

  • UPG の作成が無効になっているときに新しいユーザーの追加が成功することを確認するには、次のいずれかを選択します。

    • 新しいユーザーを追加するときにカスタムの GID を指定します。GID は、既存のユーザーグループに対応する必要はありません。

      たとえば、コマンドラインからユーザーを追加する場合は、--gid オプションを ipa user-add コマンドに追加します。

    • automember ルールを使用して、GID を持つ既存のグループにユーザーを追加します。

11.8. IdM CLI を使用してグループメンバーの表示

本セクションでは、IdM CLI を使用してグループのメンバーを表示する方法を説明します。直接グループメンバーと間接グループメンバーの両方を表示できます。詳細は、「直接および間接のグループメンバー」を参照してください。

手順

  • グループのメンバーの一覧を表示するには、ipa group-show group_name コマンドを使用します。以下に例を示します。

    $ ipa group-show group_a
      ...
      Member users: user_a
      Member groups: group_b
      Indirect Member users: user_b
    注記

    間接メンバーの一覧には、信頼された Active Directory ドメインの外部ユーザーが含まれません。Active Directory 信頼ユーザーオブジェクトは、Identity Management 内に LDAP オブジェクトとして存在しないため、Identity Management インターフェースには表示されません。

11.9. IdM CLI を使用してユーザーグループからメンバーを削除

本セクションでは、IdM CLI を使用してユーザーグループからメンバーを削除する方法を説明します。

前提条件

手順

  1. 任意です。ipa group-show コマンドを使用して、削除するメンバーがグループに含まれていることを確認します。
  2. ipa group-remove-member コマンドを使用して、ユーザーグループからメンバーを削除します。

    以下のオプションを使用して、削除するメンバーを指定します。

    • --users は、IdM ユーザーを削除します
    • --external は、DOMAIN\user_name または user_name@domain の形式で、IdM ドメイン外に存在するユーザーを削除します
    • --groups は、IdM ユーザーグループを削除します

    たとえば、group_name という名前のグループから、user1user2、および group1 を削除するには、次のコマンドを実行します。

    $ ipa group-remove-member group_name --users=user1 --users=user2 --groups=group1

第12章 IdM Weg UI でのユーザーグループの管理

本章では、IdM Web UI を使用したユーザーグループ管理を説明します。

ユーザーグループは、共通の特権、パスワードポリシーなどの持つユーザーのセットです。

Identity Management (IdM) のユーザーグループには以下が含まれます。

  • IdM ユーザー
  • 他の IdM ユーザーグループ
  • 外部ユーザー (IdM の外部に存在するユーザー)

12.1. IdM のさまざまなグループタイプ

IdM は、以下のタイプのグループをサポートします。

POSIX グループ (デフォルト)

POSIX グループは、メンバーの Linux POSIX 属性に対応します。Active Directory と対話するグループは POSIX 属性を使用できないことに注意してください。

POSIX 属性は、ユーザーを個別のエンティティーとして識別します。ユーザーに関連する POSIX 属性の例には、uidNumber (ユーザー番号 (UID))、および gidNumber (グループ番号 (GID)) が含まれます。

非 POSIX グループ

非 POSIX グループは、POSIX 属性に対応していません。たとえば、これらのグループには GID が定義されていません。

このタイプのグループのすべてのメンバーは、IdM ドメインに属している必要があります。

外部グループ

外部グループを使用して、以下のような IdM ドメイン外の ID ストアに存在するグループメンバーを追加できます。

  • ローカルシステム
  • Active Directory ドメイン
  • ディレクトリーサービス

外部グループは、POSIX 属性に対応していません。たとえば、これらのグループには GID が定義されていません。

表12.1 デフォルトで作成されたユーザーグループ

グループ名デフォルトのグループメンバー

ipausers

すべての IdM ユーザー

admins

管理権限を持つユーザー (デフォルトの admin ユーザーを含む)

editors

これは、特別な権限がなくなったレガシーグループです

trust admins

Active Directory 信頼を管理する権限を持つユーザー

ユーザーをユーザーグループに追加すると、ユーザーはグループに関連付けられた権限とポリシーを取得します。たとえば、ユーザーに管理権限を付与するには、ユーザーを admins グループに追加します。

警告

admins グループを削除しないでください。admins は IdM で必要な事前定義グループであるため、この操作により特定のコマンドで問題が生じます。

さらに、IdM で新しいユーザーが作成されるたびに、IdM は、デフォルトで ユーザーのプライベートグループ を作成します。プライベートグループの詳細は、「プライベートグループのないユーザーの追加」を参照してください。

12.2. 直接および間接のグループメンバー

IdM のユーザーグループ属性は、直接メンバーと間接メンバーの両方に適用されます。グループ B がグループ A のメンバーである場合、グループ B のすべてのユーザーはグループ A の間接メンバーと見なされます。

たとえば、以下の図では、以下のようになります。

  • ユーザー 1 とユーザー 2 は、グループ A の 直接メンバー です。
  • ユーザー 3、ユーザー 4、およびユーザー 5 は、グループ A の 間接メンバー です。

図12.1 直接および間接グループメンバーシップ

84 RHEL IdM 0420 ユーザーグループ

ユーザーグループ A にパスワードポリシーを設定すると、そのポリシーはユーザーグループ B のすべてのユーザーにも適用されます。

12.3. IdM Web UI を使用したユーザーグループの追加

本セクションでは、IdM Web UI を使用してユーザーグループを追加する方法を説明します。

前提条件

  • IdM Web UI にログインしている。

手順

  1. Identity → Groups の順にクリックし、左のサイドバーで User Groups を選択します。
  2. Add をクリックして、グループを追加します。
  3. グループの情報を入力します。ユーザーグループタイプの詳細は「IdM のさまざまなグループタイプ」を参照してください。

    グループのカスタム GID を指定できます。これを行う場合は、ID の競合を避けるように注意してください。カスタム GID を指定しない場合、IdM は使用可能な ID 範囲から GID を自動的に割り当てます。

    ユーザーグループの追加ダイアログ
  4. Add をクリックして確定します。

12.4. IdM Web UI を使用したユーザーグループの削除

本セクションでは、IdM Web UI を使用してユーザーグループを削除する方法を説明します。グループを削除しても、IdM からグループメンバーは削除されないことに注意してください。

前提条件

  • IdM Web UI にログインしている。

手順

  1. Identity → Groups の順にクリックし、User Groups を選択します。
  2. 削除するグループを選択します。
  3. 削除 をクリックします。
  4. Delete をクリックして確定します。

12.5. IdM Web UI でユーザーグループにメンバーの追加

ユーザーおよびユーザーグループの両方をユーザーグループのメンバーとして追加できます。詳細は「IdM のさまざまなグループタイプ」および「直接および間接のグループメンバー」を参照してください。

前提条件

  • IdM Web UI にログインしている。

手順

  1. Identity → Groups の順にクリックし、左のサイドバーで User Groups を選択します。
  2. グループ名をクリックします。
  3. 追加するグループメンバーのタイプ (Users, User Groups, または External) を選択します。

    グループが更新したメンバーを追加
  4. Add をクリックします。
  5. 追加するメンバーの横にあるチェックボックスを 1 つ以上選択します。
  6. 右矢印をクリックして、選択したメンバーをグループに移動します。

    「グループにメンバーを追加」ダイアログ
  7. Add をクリックして確定します。

12.6. IdM Web UI を使用してグループメンバーの表示

本セクションでは、IdM Web UI を使用してグループのメンバーを表示する方法を説明します。直接グループメンバーと間接グループメンバーの両方を表示できます。詳細は、「直接および間接のグループメンバー」を参照してください。

前提条件

  • IdM Web UI にログインしている。

手順

  1. Identity → Groupsを選択します。
  2. 左のサイドバーで User Groups を選択します。
  3. 表示するグループの名前をクリックします。
  4. 直接メンバーシップ間接メンバーシップ を切り替えます。

    グループメニューの消去

12.7. IdM Web UI を使用してユーザーグループからメンバーの削除

本セクションでは、IdM Web UI を使用してユーザーグループからメンバーを削除する方法を説明します。

前提条件

  • IdM Web UI にログインしている。

手順

  1. Identity → Groups の順にクリックし、左のサイドバーで User Groups を選択します。
  2. グループ名をクリックします。
  3. 削除するグループメンバーのタイプ (Users, User Groups、または External) を選択します。

    グループが更新したメンバーを追加
  4. 削除するメンバーの横にあるチェックボックスを選択します。
  5. 削除 をクリックします。
  6. Delete をクリックして確定します。

第13章 Ansible Playbook を使用した IdM グループおよびグループメンバーの存在の確保

以下の手順では、Ansible Playbook を使用して、IdM グループとグループメンバー (ユーザーとユーザーグループの両方) が存在することを確認する方法を説明します。

前提条件

手順

  1. inventory.file などのインベントリーファイルを作成し、そのファイルに ipaserver を定義します。

    [ipaserver]
    server.idm.example.com
  2. 必要なユーザーおよびグループ情報を使用して Ansible Playbook ファイルを作成します。この手順を簡素化するには、/usr/share/doc/ansible-freeipa/playbooks/user/ ディレクトリーのサンプルをコピーして変更できます。たとえば、opssysops、および appops という名前のグループ、sysopsidm_user という名前のユーザーが存在し、opssysops および appops グループが存在することを確認するには、add-group.ymladd-groups-to-group.yml Playbook を新しい Playbook に統合できます。

    ---
    - name: Playbook to handle groups
      hosts: ipaserver
      become: true
    
      tasks:
      - name: Create group ops with gid 1234
        ipagroup:
          ipaadmin_password: Secret123
          name: ops
          gidnumber: 1234
    
      - name: Create group sysops
        ipagroup:
          ipaadmin_password: Secret123
          name: sysops
          user:
          - idm_user
    
      - name: Create group appops
        ipagroup:
          ipaadmin_password: Secret123
          name: appops
    
      - name: Add group members sysops and appops to group ops
        ipagroup:
          ipaadmin_password: Secret123
          name: ops
          group:
          - sysops
          - appops
  3. Playbook を実行します。

    $ ansible-playbook -v -i path_to_inventory_directory/inventory.file path_to_playbooks_directory/add-group-members.yml

検証手順

ipa group-show コマンドを使用すると、ops グループに sysops および appops がダイレクトメンバーとして含まれ、idm_user が間接メンバーとして含まれているかどうかを確認できます。

  1. 管理者として ipaserver にログインします。

    $ ssh admin@server.idm.example.com
    Password:
    [admin@server /]$
  2. ops についての情報を表示します。

    ipaserver]$ ipa group-show ops
      Group name: ops
      GID: 1234
      Member groups: sysops, appops
      Indirect Member users: idm_user

    appops および sysops グループ - idm_user ユーザーを含む後者は IdM に存在します。

関連情報

  • Ansible を使用してユーザーグループが存在することを確認する方法は、/usr/share/doc/ansible-freeipa/README-group.md Markdown ファイルを参照してください。

第14章 IdM CLI を使用したグループメンバーシップの自動化

自動グループメンバーシップを使用すると、属性に基づいてユーザーとホストをグループに自動的に割り当てることができます。たとえば、以下を行うことができます。

  • 従業員のマネージャー、ロケーション、またはその他の属性に基づいて従業員のユーザーエントリーをグループに分割します。
  • クラス、ロケーション、またはその他の属性に基づいてホストを分割します。
  • 全ユーザーまたは全ホストを 1 つのグローバルグループに追加します。

本章では、以下のトピックについて説明します。

14.1. 自動グループメンバーシップの利点

ユーザーの自動メンバーシップを使用すると、以下が可能になります。

  • グループメンバーシップの手動管理によるオーバーヘッドの削減

    すべてのユーザーおよびグループを手作業で割り当てる必要がなくなりました。

  • ユーザーおよびホスト管理における一貫性の向上

    ユーザーとホストは、厳密に定義され、自動的に評価される基準に基づいてグループに割り当てられます。

  • グループベースの設定管理を簡素化

    さまざまな設定がグループに定義され、sudo ルール、自動マウント、またはアクセス制御などの個別のグループメンバーに適用されます。ユーザーとホストをグループに自動的に追加すると、この設定の管理が容易になります。

14.2. automember ルール

自動グループメンバーシップを設定する場合、管理者は automember ルールを定義します。automember ルールは、特定のユーザーまたはホストターゲットグループに適用されます。これは、一度に複数のグループに適用することはできません。

ルールの作成後、管理者は条件を追加します。これらは、ユーザーまたはホストをターゲットグループに含めるか、除外するかを指定します。

  • 包含条件

    ユーザーまたはホストのエントリーが包含条件を満たす場合、ターゲットグループに含まれます。

  • 除外の条件

    ユーザーまたはホストのエントリーが除外された状態を満たす場合、ターゲットグループには含まれません。

この条件は、Perl 互換正規表現 (PCRE) 形式の正規表現として指定されます。PCRE の詳細は、man ページの pcresyntax(3) を参照してください。

注記

IdM は、包含条件の前に除外条件を評価します。競合が発生した場合は、包含条件よりも除外条件が優先されます。

automember ルールは、今後作成されるすべてのエントリーに適用されます。これらのエントリーは指定されたターゲットグループに自動的に追加されます。エントリーが複数の automember ルールで指定された条件を満たすと、対応するグループすべてに追加されます。

既存のエントリーは新規ルールの影響を 受けません。既存のエントリーを変更する場合は、「IdM CLI を使用した既存のエントリーへの automember ルールの適用」を参照してください。

14.3. IdM CLI を使用した automember ルールの追加

本セクションでは、IdM CLI を使用して automember ルールを追加する方法を説明します。automember ルールの詳細は、「automember ルール」を参照してください。

automember ルールを追加した後に、「automember ルールへの条件の追加」で説明されている手順に従って条件を追加できます。

注記

既存のエントリーは新規ルールの影響を 受けません。既存のエントリーを変更する場合は、「IdM CLI を使用した既存のエントリーへの automember ルールの適用」を参照してください。

前提条件

  • 管理者としてログインしている必要があります。詳細は「kinit による IdM への手動ログイン」を参照してください。
  • 新しいルールのターゲットグループは IdM に存在している必要があります。

手順

  1. ipa automember-add コマンドを入力して、automember ルールを追加します。
  2. プロンプトが表示されたら、以下を指定します。

    • automember ルール。これはターゲットグループ名です。
    • グループタイプ。これは、ルールがユーザーグループまたはホストグループをターゲットにするかどうかを指定します。ユーザーグループをターゲットにするには、group を入力します。ホストグループをターゲットに設定するには、ホストグループ を入力します。

    たとえば、user_group という名前のユーザーグループの automember ルールを追加するには、以下を実行します。

    $ ipa automember-add
    Automember Rule: user_group
    Grouping Type: group
    --------------------------------
    Added automember rule "user_group"
    --------------------------------
        Automember Rule: user_group

検証手順

14.4. IdM CLI を使用した automember ルールへの条件の追加

本セクションでは、IdM CLI を使用して automember ルールに条件を追加する方法を説明します。automember ルールの詳細は、「automember ルール」を参照してください。

前提条件

手順

  1. ipa automember-add-condition コマンドを使用して、包含または除外の条件を定義します。
  2. プロンプトが表示されたら、以下を指定します。

    • automember ルール。これはターゲットルール名です。詳細は、「Automember rules」を参照してください。
    • 属性キー。これは、フィルターが適用される entry 属性を指定します。たとえば、ユーザーの uid です。
    • グループタイプ。これは、ルールがユーザーグループまたはホストグループをターゲットにするかどうかを指定します。ユーザーグループをターゲットにするには、group を入力します。ホストグループをターゲットに設定するには、ホストグループ を入力します。
    • 包含正規表現 および 除外正規表現。正規表現として条件を指定します。ある条件のみを指定する場合は、他の条件が求められたら Enter を押します。

    たとえば、以下の条件は、ユーザーログイン属性 (uid) のすべての値 (.*) を対象にしています。

    $ ipa automember-add-condition
    Automember Rule: user_group
    Attribute Key: uid
    Grouping Type: group
    [Inclusive Regex]: .*
    [Exclusive Regex]:
    ----------------------------------
    Added condition(s) to "user_group"
    ----------------------------------
      Automember Rule: user_group
      Inclusive Regex: uid=.*
    ----------------------------
    Number of conditions added 1
    ----------------------------

    別の例として、automembership ルールを使用して、Active Directory (AD) から同期したすべての Windows ユーザーをターゲットにできます。これを行うには、objectClass 属性で ntUser を持つすべてのユーザーをターゲットにする条件を作成します。これは、すべての AD ユーザーが共有します。

    $ ipa automember-add-condition
    Automember Rule: ad_users
    Attribute Key: objectclass
    Grouping Type: group
    [Inclusive Regex]: ntUser
    [Exclusive Regex]:
    -------------------------------------
    Added condition(s) to "ad_users"
    -------------------------------------
      Automember Rule: ad_users
      Inclusive Regex: objectclass=ntUser
    ----------------------------
    Number of conditions added 1
    ----------------------------

検証手順

14.5. IdM CLI を使用した既存の automember ルールの表示

本セクションでは、IdM CLI を使用して既存の automember ルールを表示する方法を説明します。

前提条件

手順

  1. ipa automember-find コマンドを入力します。
  2. プロンプトが表示されたら、Grouping タイプ を指定します。

    • ユーザーグループをターゲットにするには、group を入力します。
    • ホストグループをターゲットに設定するには、ホストグループ を入力します。

      以下に例を示します。

    $ ipa automember-find
    Grouping Type: group
    ---------------
    1 rules matched
    ---------------
      Automember Rule: user_group
      Inclusive Regex: uid=.*
    ----------------------------
    Number of entries returned 1
    ----------------------------

14.6. IdM CLI を使用した automember ルールの削除

本セクションでは、IdM CLI を使用して automember ルールを削除する方法を説明します。

automember ルールを削除すると、ルールに関連付けられたすべての条件も削除されます。ルールから特定の条件のみを削除するには、「IdM CLI を使用して automember ルールから条件の削除」を参照してください。

前提条件

手順

  1. ipa automember-del コマンドを実行します。
  2. プロンプトが表示されたら、以下を指定します。

    • automember ルール。これは、削除するルールです。
    • グループルール。これは、削除するルールがユーザーグループまたはホストグループのルールであるかどうかを指定します。group または hostgroup を入力します。

14.7. IdM CLI を使用した automember ルールからの条件の削除

本セクションでは、automember ルールから特定の条件を削除する方法を説明します。

前提条件

手順

  1. ipa automember-remove-condition コマンドを実行します。
  2. プロンプトが表示されたら、以下を指定します。

    • automember ルール。これは、条件を削除するルールの名前です。
    • 属性キー。これはターゲットエントリー属性です。たとえば、ユーザーの uid です。
    • グループタイプ。これは、削除する条件がユーザーグループまたはホストグループのどちらであるかを指定します。group または hostgroup を入力します。
    • 包含正規表現 および 除外正規表現。削除する条件を指定します。ある条件のみを指定する場合は、他の条件が求められたら Enter を押します。

      以下に例を示します。

    $ ipa automember-remove-condition
    Automember Rule: user_group
    Attribute Key: uid
    Grouping Type: group
    [Inclusive Regex]: .*
    [Exclusive Regex]:
    -----------------------------------
    Removed condition(s) from "user_group"
    -----------------------------------
      Automember Rule: user_group
    ------------------------------
    Number of conditions removed 1
    ------------------------------

14.8. IdM CLI を使用して automember ルールを既存のエントリーに適用する

Automember ルールは、ルールの追加後に作成されたユーザーおよびホストエントリーに自動的に適用されます。ルールの追加前に存在するエントリーには、一時的な適用は行われません。

以前に追加したエントリーに automember ルールを適用するには、自動メンバーシップを手動で再構築する必要があります。自動メンバーシップを再構築すると、既存の automember ルールがすべて再評価され、すべてのユーザーまたはホストエントリーまたは特定のエントリーに適用されます。

注記

エントリーがグループの包含条件に一致しない場合でも、自動メンバーシップを再構築しても、グループからユーザーまたはホストエントリーは削除 されません。手動で削除するには、「IdM CLI を使用してユーザーグループからメンバーを削除する」か、「CLI を使用して IdM ホストグループメンバーを削除する」を参照してください。

前提条件

手順

  • 自動メンバーシップを再構築するには、ipa automember-rebuild コマンドを実行します。ターゲットに設定するエントリーを指定するには、以下のオプションを使用します。

    • 全ユーザーの自動メンバーシップを再構築するには、--type=group オプションを使用します。

      $ ipa automember-rebuild --type=group
      --------------------------------------------------------
      Automember rebuild task finished. Processed (9) entries.
      --------------------------------------------------------
    • すべてのホストの自動メンバーシップを再構築するには、--type=hostgroup オプションを使用します。
    • 指定したユーザーの自動メンバーシップを再構築するには、--users=target_user オプションを使用します。

      $ ipa automember-rebuild --users=target_user1 --users=target_user2
      --------------------------------------------------------
      Automember rebuild task finished. Processed (2) entries.
      --------------------------------------------------------
    • 指定したホストの自動メンバーシップを再構築するには、--hosts=client.idm.example.com を使用します。

14.9. デフォルトの automember グループの設定

デフォルトの automember グループを設定すると、automember ルールに一致しない新規ユーザーまたはホストエントリーは自動的にこのデフォルトグループに追加されます。

前提条件

手順

  1. ipa automember-default-group-set コマンドを入力して、デフォルトの automember グループを設定します。
  2. プロンプトが表示されたら、以下を指定します。

    • ターゲットグループ名を指定する Default (fallback) Group
    • グルーピングタイプ。ターゲットがユーザーグループか、ホストグループであるかを指定します。ユーザーグループをターゲットにするには、group を入力します。ホストグループをターゲットに設定するには、ホストグループ を入力します。

      以下に例を示します。

      $ ipa automember-default-group-set
      Default (fallback) Group: default_user_group
      Grouping Type: group
      ---------------------------------------------------
      Set default (fallback) group for automember "default_user_group"
      ---------------------------------------------------
        Default (fallback) Group: cn=default_user_group,cn=groups,cn=accounts,dc=example,dc=com
    注記

    現在のデフォルトの automember グループを削除するには、ipa automember-default-group-remove コマンドを実行します。

検証手順

  • グループが正しく設定されていることを確認するには、ipa automember-default-group-show コマンドを実行します。コマンドは、現在のデフォルトの automember グループを表示します。以下に例を示します。

    $ ipa automember-default-group-show
    Grouping Type: group
      Default (fallback) Group: cn=default_user_group,cn=groups,cn=accounts,dc=example,dc=com

第15章 IdM Web UI でグループメンバーシップの自動化

自動グループメンバーシップを使用すると、属性に基づいてユーザーとホストをグループに自動的に割り当てることができます。たとえば、以下を行うことができます。

  • 従業員のマネージャー、ロケーション、またはその他の属性に基づいて従業員のユーザーエントリーをグループに分割します。
  • クラス、ロケーション、またはその他の属性に基づいてホストを分割します。
  • 全ユーザーまたは全ホストを 1 つのグローバルグループに追加します。

本章では、以下のトピックについて説明します。

15.1. 自動グループメンバーシップの利点

ユーザーの自動メンバーシップを使用すると、以下が可能になります。

  • グループメンバーシップの手動管理によるオーバーヘッドの削減

    すべてのユーザーおよびグループを手作業で割り当てる必要がなくなりました。

  • ユーザーおよびホスト管理における一貫性の向上

    ユーザーとホストは、厳密に定義され、自動的に評価される基準に基づいてグループに割り当てられます。

  • グループベースの設定管理を簡素化

    さまざまな設定がグループに定義され、sudo ルール、自動マウント、またはアクセス制御などの個別のグループメンバーに適用されます。ユーザーとホストをグループに自動的に追加すると、この設定の管理が容易になります。

15.2. automember ルール

自動グループメンバーシップを設定する場合、管理者は automember ルールを定義します。automember ルールは、特定のユーザーまたはホストターゲットグループに適用されます。これは、一度に複数のグループに適用することはできません。

ルールの作成後、管理者は条件を追加します。これらは、ユーザーまたはホストをターゲットグループに含めるか、除外するかを指定します。

  • 包含条件

    ユーザーまたはホストのエントリーが包含条件を満たす場合、ターゲットグループに含まれます。

  • 除外の条件

    ユーザーまたはホストのエントリーが除外された状態を満たす場合、ターゲットグループには含まれません。

この条件は、Perl 互換正規表現 (PCRE) 形式の正規表現として指定されます。PCRE の詳細は、man ページの pcresyntax(3) を参照してください。

注記

IdM は、包含条件の前に除外条件を評価します。競合が発生した場合は、包含条件よりも除外条件が優先されます。

automember ルールは、今後作成されるすべてのエントリーに適用されます。これらのエントリーは指定されたターゲットグループに自動的に追加されます。エントリーが複数の automember ルールで指定された条件を満たすと、対応するグループすべてに追加されます。

既存のエントリーは新規ルールの影響を 受けません。既存のエントリーを変更する場合は、「IdM Web UI で automember ルールを既存エントリーに適用」を参照してください。

15.3. IdM Web UI で automember ルールの追加

本セクションでは、IdM Web UI を使用して automember ルールを追加する方法を説明します。automember ルールの詳細は、「automember ルール」を参照してください。

注記

既存のエントリーは新規ルールの影響を 受けません。既存のエントリーを変更する場合は、「IdM Web UI で automember ルールを既存エントリーに適用」を参照してください。

前提条件

  • IdM Web UI にログインしている。
  • admins グループのメンバーである。
  • 新しいルールのターゲットグループが IdM に存在する。

手順

  1. Identity → Automember をクリックして、User group rule または Host group rules を選択します。
  2. Add をクリックします。
  3. Automember rule フィールドで、ルールを適用するグループを選択します。これはターゲットグループ名です。

    automember rule add
  4. Add をクリックして確定します。
  5. 必要に応じて、「IdM Web UI で automember ルールへの条件の追加」で説明されている手順に従って、新しいルールに条件を追加できます。

15.4. IdM Web UI で automember ルールへの条件の追加

本セクションでは、IdM Web UI を使用して、automember ルールに条件を追加する方法を説明します。automember ルールの詳細は、「automember ルール」を参照してください。

前提条件

  • IdM Web UI にログインしている。
  • admins グループのメンバーである。
  • ターゲットルールが IdM に存在する。

手順

  1. Identity → Automember をクリックして、User group rule または Host group rules を選択します。
  2. 条件を追加するルールをクリックします。
  3. Inclusive セクションまたは Exclusive セクションで、Add をクリックします。

    automember 条件の追加
  4. Attribute フィールドで、必要な属性 (uid など) を選択します。
  5. Expression フィールドに正規表現を定義します。
  6. Add をクリックします。

    たとえば、以下の条件は、ユーザー ID (uid) 属性の値 (.*) を持つすべてのユーザーを対象とします。

    automember add

15.5. IdM Web UI で既存の automember ルールおよび条件の表示

本セクションでは、IdM Web UI を使用して、既存の automember ルールおよび条件を表示する方法を説明します。

前提条件

  • IdM Web UI にログインしている。
  • admins グループのメンバーである。

手順

  1. Identity → Automember をクリックして、User group rule または Host group rules を選択して、それぞれの automember ルールを表示します。
  2. 必要に応じて、ルールをクリックして、Inclusive セクションまたは Exclusive セクションにそのルールの条件を表示します。

    automember の条件

15.6. IdM Web UI で automember ルールの削除

本セクションでは、IdM Web UI を使用して automember ルールを削除する方法を説明します。

automember ルールを削除すると、ルールに関連付けられたすべての条件も削除されます。ルールから特定の条件のみを削除するには、「IdM Web UI を使用して automember ルールから条件を削除」を参照してください。

前提条件

  • IdM Web UI にログインしている。
  • admins グループのメンバーである。

手順

  1. Identity → Automember をクリックして、User group rule または Host group rules を選択して、それぞれの automember ルールを表示します。
  2. 削除するルールの横にあるチェックボックスを選択します。
  3. 削除 をクリックします。

    automember rule delete
  4. Delete をクリックして確定します。

15.7. IdM Web UI で automember ルールから条件の削除

本セクションでは、IdM Web UI を使用して、automember ルールから特定の条件を削除する方法を説明します。

前提条件

  • IdM Web UI にログインしている。
  • admins グループのメンバーである。

手順

  1. Identity → Automember をクリックして、User group rule または Host group rules を選択して、それぞれの automember ルールを表示します。
  2. ルールをクリックして、Inclusive セクションまたは Exclusive セクションでそのルールの条件を表示します。
  3. 削除する条件の横にあるチェックボックスを選択します。
  4. 削除 をクリックします。

    automember condition remove
  5. Delete をクリックして確定します。

15.8. IdM Web UI で automember ルールを既存エントリーに適用

Automember ルールは、ルールの追加後に作成されたユーザーおよびホストエントリーに自動的に適用されます。ルールの追加前に存在するエントリーには、一時的な適用は行われません。

以前に追加したエントリーに automember ルールを適用するには、自動メンバーシップを手動で再構築する必要があります。自動メンバーシップを再構築すると、既存の automember ルールがすべて再評価され、すべてのユーザーまたはホストエントリーまたは特定のエントリーに適用されます。

注記

エントリーがグループの包含条件に一致しない場合でも、自動メンバーシップを再構築しても、グループからユーザーまたはホストエントリーは削除 されません。手動で削除するには、「IdM Web UI を使用してユーザーグループからメンバーの削除」または「IdM Web UI でホストグループメンバーの削除」を参照してください。

15.8.1. 全ユーザーまたは全ホストに対して自動メンバーシップの再構築

本セクションでは、ユーザーまたはホストのすべてのエントリーに対して自動メンバーシップを再構築する方法を説明します。

前提条件

  • IdM Web UI にログインしている。
  • admins グループのメンバーである。

手順

  1. IdentityUsers または Hosts を選択します。
  2. ActionsRebuild auto membership をクリックします。

    automember 再構築

15.8.2. 1 つのユーザーまたはホストに対して自動メンバーシップの再構築

本セクションでは、特定のユーザーエントリーまたはホストエントリーに対して自動メンバーシップを再構築する方法を説明します。

前提条件

  • IdM Web UI にログインしている。
  • admins グループのメンバーである。

手順

  1. IdentityUsers または Hosts を選択します。
  2. 必要なユーザー名またはホスト名をクリックします。
  3. ActionsRebuild auto membership をクリックします。

    automember で 1 つを再構築

15.9. IdM Web UI でデフォルトのユーザーグループの設定

デフォルトのユーザーグループを設定する際には、automember ルールに一致しない新規ユーザーエントリーは自動的にこのデフォルトグループに追加されます。

前提条件

  • IdM Web UI にログインしている。
  • admins グループのメンバーである。
  • デフォルトとして設定するターゲットユーザーグループが IdM に存在します。

手順

  1. Identity → Automember をクリックして、User group rules を選択します。
  2. Default user group フィールドで、デフォルトのユーザーグループとして設定するグループを選択します。

    デフォルトユーザーグループの設定

15.10. IdM Web UI でデフォルトのホストグループの設定

デフォルトのホストグループを設定する際には、automember ルールに一致しない新規ホストエントリーが自動的にこのデフォルトグループに追加されます。

前提条件

  • IdM Web UI にログインしている。
  • admins グループのメンバーである。
  • デフォルトとして設定されるターゲットホストグループが IdM にある。

手順

  1. Identity → Automember をクリックして、Host group rules を選択します。
  2. Default host group フィールドで、デフォルトのホストグループとして設定するグループを選択します。

    デフォルトのホストグループの設定

第16章 CLI を使用した IdM でのセルフサービスルールの管理

本章では、Identity Management (IdM) のセルフサービスルールを紹介し、コマンドラインインターフェース (CLI) でセルフサービスアクセスルールを作成および編集する方法を説明します。

16.1. IdM でのセルフサービスアクセス制御

セルフサービスのアクセス制御ルールは、IdM エンティティーが IdM Directory Server エントリーで実行できる操作を定義します。たとえば、IdM ユーザーは独自のパスワードを更新できます。

この制御方法では、認証された IdM エンティティーがその LDAP エントリー内の特定の属性を編集できますが、エントリー全体での 追加削除 の操作は許可されません。

警告

セルフサービスのアクセス制御規則を使用する場合は注意が必要です。アクセス制御ルールを誤ってに構成すると、エンティティーの特権が誤って昇格する可能性があります。

16.2. CLI を使用したセルフサービスルールの作成

この手順では、コマンドラインインターフェース (CLI) を使用して IdM にセルフサービスアクセスルールを作成する方法を説明します。

前提条件

手順

  • セルフサービスルールを追加するには、ipa selfservice-add コマンドを使用して、以下の 2 つのオプションを指定します。

    --permissions
    アクセス制御命令 (ACI) が付与する 読み取り パーミッションおよび 書き込み パーミッションを設定します。
    --attrs
    この ACI がパーミッションを付与する属性の完全なリストを設定します。

たとえば、セルフサービスルールを作成して、ユーザーが独自の名前の詳細を変更できるようにするには、次のコマンドを実行します。

$ ipa selfservice-add "Users can manage their own name details" --permissions=write --attrs=givenname --attrs=displayname --attrs=title --attrs=initials
-----------------------------------------------------------
Added selfservice "Users can manage their own name details"
-----------------------------------------------------------
    Self-service name: Users can manage their own name details
    Permissions: write
    Attributes: givenname, displayname, title, initials

16.3. CLI を使用したセルフサービスルールの編集

この手順では、コマンドラインインターフェース (CLI) を使用して IdM のセルフサービスアクセスルールを編集する方法を説明します。

前提条件

手順

  1. オプション: ipa selfservice-find コマンドを使用して、既存のセルフサービスルールを表示します。
  2. オプション: ipa selfservice-show コマンドを使用して、変更するセルフサービスルールの詳細を表示します。
  3. ipa selfservice-mod コマンドを使用してセルフサービスルールを編集します。

以下に例を示します。

$ ipa selfservice-mod "Users can manage their own name details" --attrs=givenname --attrs=displayname --attrs=title --attrs=initials --attrs=surname
--------------------------------------------------------------
Modified selfservice "Users can manage their own name details"
--------------------------------------------------------------
Self-service name: Users can manage their own name details
Permissions: write
Attributes: givenname, displayname, title, initials
重要

ipa selfservice-mod コマンドを使用すると、以前に定義されたパーミッションと属性が上書きされるため、既存のパーミッションおよび属性の完全なリストを、定義する必要のある新しいパーミッションおよび属性に常に含めるようにしてください。

検証手順

  • ipa selfservice-show コマンドを使用して、編集したセルフサービスルールを表示します。
$ ipa selfservice-show "Users can manage their own name details"
--------------------------------------------------------------
Self-service name: Users can manage their own name details
Permissions: write
Attributes: givenname, displayname, title, initials

16.4. CLI を使用したセルフサービスルールの削除

この手順では、コマンドラインインターフェース (CLI) を使用して IdM でセルフサービスアクセスルールを削除する方法を説明します。

前提条件

手順

  • ipa selfservice-del コマンドを使用してセルフサービスルールを削除します。

以下に例を示します。

$ ipa selfservice-del "Users can manage their own name details"
-----------------------------------------------------------
Deleted selfservice "Users can manage their own name details"
-----------------------------------------------------------

検証手順

  • ipa selfservice-find コマンドを使用して、すべてのセルフサービスルールを表示します。削除したばかりのルールがなくなっているはずです。

第17章 IdM Web UI を使用したセルフサービスルールの管理

本章では、Identity Management (IdM) のセルフサービスルールを紹介し、Web インターフェース (IdM Web UI) でセルフサービスアクセスルールを作成および編集する方法を説明します。

17.1. IdM でのセルフサービスアクセス制御

セルフサービスのアクセス制御ルールは、IdM エンティティーが IdM Directory Server エントリーで実行できる操作を定義します。たとえば、IdM ユーザーは独自のパスワードを更新できます。

この制御方法では、認証された IdM エンティティーがその LDAP エントリー内の特定の属性を編集できますが、エントリー全体での 追加削除 の操作は許可されません。

警告

セルフサービスのアクセス制御規則を使用する場合は注意が必要です。アクセス制御ルールを誤ってに構成すると、エンティティーの特権が誤って昇格する可能性があります。

17.2. IdM Web UI を使用したセルフサービスルールの作成

この手順では、Web インターフェース(IdM Web UI)を使用して IdM にセルフサービスアクセスルールを作成する方法を説明します。

前提条件

手順

  1. IPA Server タブで Role-Based Access Control サブメニューを開き、Self Service Permissions を選択します。
  2. セルフサービスアクセスルールの一覧の右上にある Add をクリックします。

    Adding a self-service rule

  3. Add Self Service Permission ウィンドウが開きます。Self-service name フィールドに新しいセルフサービスルールの名前を入力します。空白を使用できます。

    Form for adding a self-service rule

  4. ユーザーが編集できるようにする属性の横にあるチェックボックスを選択します。
  5. 必要に応じて アクセスを提供する属性が一覧にない場合は、その一覧を追加できます。

    1. Add ボタンをクリックします。
    2. 以下の Add Custom Attribute ウィンドウの Attribute テキストフィールドに属性名を入力します。
    3. OK ボタンをクリックして属性を追加します。
    4. 新しい属性が選択されていることを確認します。
  6. フォームの下部にある Add ボタンをクリックして、新しいセルフサービスルールを保存します。
    または、Add and Edit ボタンをクリックしてセルフサービスルールを編集するか、Add and Add another ボタンをクリックしてさらにルールを保存および追加できます。

17.3. IdM Web UI を使用したセルフサービスルールの編集

この手順では、Web インターフェース (IdM Web UI) を使用して IdM にセルフサービスアクセスルールを編集する方法を説明します。

前提条件

手順

  1. IPA Server タブで Role-Based Access Control サブメニューを開き、Self Service Permissions を選択します。
  2. 変更するセルフサービスルールの名前をクリックします。

    Editing an existing self-service rule

  3. 編集ページでは、セルフサービスルールに追加または削除する属性の一覧のみを編集できます。適切なチェックボックスを選択または選択解除します。
  4. Save ボタンをクリックして、セルフサービスルールへの変更を保存します。

17.4. IdM Web UI を使用したセルフサービスルールの削除

この手順では、Web インターフェース (IdM Web UI) を使用して IdM にセルフサービスアクセスルールを削除する方法を説明します。

前提条件

手順

  1. IPA Server タブで Role-Based Access Control サブメニューを開き、Self Service Permissions を選択します。
  2. 削除するルールの横にあるチェックボックスを選択し、一覧の右側にある Delete ボタンをクリックします。

    Deleting a self-service rule

  3. ダイアログが開き、Delete をクリックして確認します。

第18章 IdM CLI を使用したユーザーにパーミッションの委譲

委譲は、セルフサービスルールおよびロールベースのアクセス制御とともに、IdM のアクセス制御メソッドの 1 つです。

委譲は、あるユーザーのグループに別のユーザーのエントリーを管理するパーミッションが割り当てられている点がロールと似ています。ただし、委譲された権限は、特定の属性の値の編集に限定されています。エントリー全体を追加または削除したり、未指定の属性に対する制御を実行することは許可されません。また、委譲された認証局のグループは、アクセス制御用に特別に作成されるロールではなく、既存の IdM ユーザーグループです。

本章では、以下のトピックについて説明します。

18.1. 委譲ルール

委譲ルールを作成して、ユーザーに対するパーミッションを委譲できます。

委譲ルールを使用すると、特定のユーザーグループが、別のユーザーグループ内のユーザーの特定の属性に対して書き込み (編集) 操作を実行できます。このようなアクセス制御ルールは、特定の属性の値の編集に限定されます。エントリー全体を追加または削除したり、未指定の属性を制御したりすることはできません。

委任ルールは、IdM の既存のユーザーグループを使用します。委任を使用すると、managers ユーザーグループで employees ユーザーグループでユーザーの選択された属性を管理できます。

18.2. IdM CLI を使用した委譲ルールの作成

本セクションでは、IdM CLI を使用して委譲ルールを作成する方法を説明します。

前提条件

  • admins グループのメンバーとしてログインしている。

手順

  • ipa delegation-add コマンドを入力します。以下のオプションを指定します。

    • --group - ユーザーグループ内のユーザーのエントリーに パーミッションを付与されている グループです。
    • --membergroup - 委任グループのメンバーが エントリーを編集できる グループです。
    • --permissions - 指定の属性を表示 (read) し、指定の属性を追加または変更 (write) する権限を持つかどうか。パーミッションを指定しないと、書き込み パーミッションのみが追加されます。
    • --attrs - メンバーグループのユーザーが表示または編集できる属性です。

    以下に例を示します。

$ ipa delegation-add "basic manager attributes" --permissions=read --permissions=write --attrs=businesscategory --attrs=departmentnumber --attrs=employeetype --attrs=employeenumber --group=managers --membergroup=employees
-------------------------------------------
Added delegation "basic manager attributes"
-------------------------------------------
  Delegation name: basic manager attributes
  Permissions: read, write
  Attributes: businesscategory, departmentnumber, employeetype, employeenumber
  Member user group: employees
  User group: managers

18.3. IdM CLI を使用した既存の委任ルールの表示

本セクションでは、IdM CLI を使用して既存の委任ルールを表示する方法を説明します。

前提条件

  • admins グループのメンバーとしてログインしている。

手順

  • ipa delegation-find コマンドを入力します。
$ ipa delegation-find
--------------------
1 delegation matched
--------------------
  Delegation name: basic manager attributes
  Permissions: read, write
  Attributes: businesscategory, departmentnumber, employeenumber, employeetype
  Member user group: employees
  User group: managers
----------------------------
Number of entries returned 1
----------------------------

18.4. IdM CLI を使用した委譲ルールの変更

本セクションでは、IdM CLI を使用して既存の委譲ルールを変更する方法を説明します。

重要

--attrs オプションは、サポートされる属性のリストをすべて上書きするため、属性の完全なリストと新しい属性を常に含めます。これは、--permissions オプションにも適用されます。

前提条件

  • admins グループのメンバーとしてログインしている。

手順

  • 必要に応じて、ipa delegation-mod コマンドを実行します。たとえば、displayname 属性を 基本的なマネージャー属性 の例に追加するには、次のコマンドを実行します。

    $ ipa delegation-mod "basic manager attributes" --attrs=businesscategory --attrs=departmentnumber --attrs=employeetype --attrs=employeenumber --attrs=displayname
    ----------------------------------------------
    Modified delegation "basic manager attributes"
    ----------------------------------------------
      Delegation name: basic manager attributes
      Permissions: read, write
      Attributes: businesscategory, departmentnumber, employeetype, employeenumber, displayname
      Member user group: employees
      User group: managers

18.5. IdM CLI を使用した委譲ルールの削除

本セクションでは、IdM CLI を使用して既存の委譲ルールを削除する方法を説明します。

前提条件

  • admins グループのメンバーとしてログインしている。

手順

  • ipa delegation-del コマンドを入力します。
  • プロンプトが表示されたら、削除する委譲ルールの名前を入力します。

    $ ipa delegation-del
    Delegation name: basic manager attributes
    ---------------------------------------------
    Deleted delegation "basic manager attributes"
    ---------------------------------------------

第19章 IdM WebUI を使用してユーザーにパーミッションを委譲する

委譲は、セルフサービスルールおよびロールベースのアクセス制御とともに、IdM のアクセス制御メソッドの 1 つです。

委譲は、あるユーザーのグループに別のユーザーのエントリーを管理するパーミッションが割り当てられている点がロールと似ています。ただし、委譲された権限は、特定の属性の値の編集に限定されています。エントリー全体を追加または削除したり、未指定の属性に対する制御を実行することは許可されません。また、委譲された認証局のグループは、アクセス制御用に特別に作成されるロールではなく、既存の IdM ユーザーグループです。

本章では、以下のトピックについて説明します。

19.1. 委譲ルール

委譲ルールを作成して、ユーザーに対するパーミッションを委譲できます。

委譲ルールを使用すると、特定のユーザーグループが、別のユーザーグループ内のユーザーの特定の属性に対して書き込み (編集) 操作を実行できます。このようなアクセス制御ルールは、特定の属性の値の編集に限定されます。エントリー全体を追加または削除したり、未指定の属性を制御したりすることはできません。

委任ルールは、IdM の既存のユーザーグループを使用します。委任を使用すると、managers ユーザーグループで employees ユーザーグループでユーザーの選択された属性を管理できます。

19.2. IdM WebUI を使用した委譲ルールの作成

本セクションでは、IdM WebUI を使用して委譲ルールを作成する方法を説明します。

前提条件

  • admins グループのメンバーとして IdM Web UI にログインしている。

手順

  1. IPA Server メニューから、Role-Based Access ControlDelegations をクリックします。
  2. Add をクリックします。

    委譲リストの追加
  3. Add delegation ウィンドウで、以下を実行します。

    1. 新しい委譲ルールに名前を付けます。
    2. 指定の属性を表示する権限 (read)、および指定の属性を追加または変更する権限 (write) をユーザーに指定しているかどうかを示すチェックボックスを選択して、パーミッションを変更します。
    3. ユーザーグループドロップダウンメニューで、パーミッションを付与している グループを選択し、メンバーグループのユーザーエントリーを表示または編集します。
    4. Member user group ドロップダウンメニューで、委譲グループのメンバーが エントリーを編集できる グループを選択します。
    5. 属性ボックスで、パーミッションを付与する属性のチェックボックスを選択します。

      委譲による UPDATED の追加
    6. Add ボタンをクリックして、新規委譲ルールを保存します。

19.3. IdM WebUI を使用して既存の委任ルールの表示

本セクションでは、IdM WebUI を使用して既存の委譲ルールを表示する方法を説明します。

前提条件

  • admins グループのメンバーとして IdM Web UI にログインしている。

手順

  1. IPA Server メニューから、Role-Based Access ControlDelegations をクリックします。

    委譲リスト

19.4. IdM WebUI を使用した委譲ルールの変更

本セクションでは、IdM WebUI を使用して既存の委譲ルールを変更する方法を説明します。

前提条件

  • admins グループのメンバーとして IdM Web UI にログインしている。

手順

  1. IPA Server メニューから、Role-Based Access ControlDelegations をクリックします。

    委譲リスト
  2. 変更するルールをクリックします。
  3. 必要な変更を行います。

    • ルールの名前を変更します。
    • 指定の属性を表示する権限 (read)、および指定の属性を追加または変更する権限 (write) をユーザーに指定しているかどうかを示すチェックボックスを選択して、パーミッションを変更します。
    • ユーザーグループドロップダウンメニューで、パーミッションを付与している グループを選択し、メンバーグループのユーザーエントリーを表示または編集します。
    • Member user group ドロップダウンメニューで、委譲グループのメンバーが エントリーを編集できる グループを選択します。
    • 属性ボックスで、パーミッションを付与する属性のチェックボックスを選択します。属性のパーミッションを削除するには、関連するチェックボックスの選択を解除します。

      委譲の変更
    • Save ボタンをクリックして変更を保存します。

19.5. IdM WebUI を使用した委譲ルールの削除

本セクションでは、IdM WebUI を使用して既存の委譲ルールを削除する方法を説明します。

前提条件

  • admins グループのメンバーとして IdM Web UI にログインしている。

手順

  1. IPA Server メニューから、Role-Based Access ControlDelegations をクリックします。
  2. 削除するルールの横にあるチェックボックスを選択します。
  3. 削除 をクリックします。

    委譲の削除
  4. Delete をクリックして確定します。

第20章 CLI で IdM でのロールベースのアクセス制御の管理

本章では、Identity Management (IdM) にロールベースのアクセス制御を追加し、コマンドラインインターフェース (CLI) で以下の操作を説明します。

20.1. IdM のロールベースのアクセス制御

IdM のロールベースアクセス制御 (RBAC) は、セルフサービス制御および委譲アクセス制御と比較して、非常に異なる種類の権限をユーザーに付与します。

ロールベースのアクセス制御は、以下の 3 つの部分で構成されます。

  • パーミッション は、ユーザーの追加または削除、グループの変更、読み取りアクセスの有効化など、特定のタスクを実行する権限を付与します。
  • 特権 は、権限を組み合わせます。たとえば、新しいユーザーを追加するために必要なすべてのパーミッションです。
  • ロール は、ユーザー、ユーザーグループ、ホスト、またはホストグループに特権のセットを付与します。

20.1.1. IdM の権限

パーミッションは、ロールベースのアクセス制御の最低レベル単位であり、操作が適用される LDAP エントリーとともに操作を定義します。ブロックを構築するのと同様に、パーミッションは必要に応じて多くの権限に割り当てることができます。
1 つ以上の 権限 は許可される操作を定義します。

  • write
  • read
  • search
  • compare
  • add
  • delete
  • all

これらの操作は、3 つの基本的な ターゲット に適用されます。

  • subtree - ドメイン名( DN) (この DN のサブツリー)
  • ターゲットフィルター: LDAP フィルター
  • target: ワイルドカードを使用したエントリーの指定が可能な DN

また、以下の便利なオプションは対応する属性を設定します。

  • タイプ: オブジェクトのタイプ (ユーザー、グループなど) (subtree および target filter を設定します)。
  • memberof: グループのメンバー。ターゲットフィルター を設定します。
  • targetgroup: 特定のグループの変更 (グループメンバーシップの管理権限の付与など) を変更するアクセスを付与します (ターゲットを設定します)。

IdM 権限を使用すると、どのユーザーがどのオブジェクトにアクセスできるか、さらにはこれらのオブジェクトの属性にアクセスできるかどうかを制御できます。IdM を使用すると、個々の属性をホワイトリストまたはブラックリストに登録したり、特定の IdM 機能 (ユーザー、グループ、sudo など) の全体の可視性を、すべての匿名ユーザー、すべての認証済みユーザー、または特権ユーザーの特定のグループに変更したりできます。
たとえば、このアプローチの柔軟性は、ユーザーまたはグループがアクセスする必要がある特定のセクションにのみユーザーまたはグループへのアクセスを制限し、他のセクションを完全に非表示にする場合に便利です。

注記

パーミッションには他のパーミッションを含めることはできません。

20.1.2. デフォルトの管理パーミッション

管理パーミッションは、IdM にデフォルトで提供されるパーミッションです。これは、以下の相違点で、ユーザーが作成した他のパーミッションのように動作します。

  • これらの属性を削除したり、名前、場所、およびターゲット属性を変更したりすることはできません。
  • これには 3 つの属性セットがあります。

    • デフォルト の属性。IdM で管理されているため、ユーザーは変更できません。
    • 追加されている 属性 (ユーザーによって追加される追加属性)
    • 除外されている 属性 (ユーザーが削除した属性)

管理されているパーミッションは、デフォルトの属性セットと追加されている属性セットには表示されますが、除外されている属性セットには表示されていないすべての属性に適用されます。

注記

管理されているパーミッションを削除することはできませんが、そのバインドタイプをパーミッションに設定し、すべての権限から管理パーミッションを削除すると、そのパーミッションを効果的に無効にできます。

管理されたすべてのパーミッションの名前は System: から始まります (例: System: Add Sudo rule または System: Modify Services)。以前のバージョンの IdM は、デフォルトのパーミッションに異なるスキームを使用していました。たとえば、ユーザーは削除できず、権限に割り当てるしかできませんでした。これらのデフォルトパーミッションのほとんどは管理パーミッションに切り替わっていますが、以下のパーミッションは引き続き以前のスキームを使用します。

  • Automember Rebuild メンバーシップタスクの追加
  • 設定サブエントリーの追加
  • レプリカ合意の追加
  • 証明書削除保留
  • CA から証明書のステータスを取得します。
  • DNA 範囲の読み取り
  • DNA 範囲の変更
  • PassSync マネージャーの設定の読み取り
  • PassSync Manager 設定の変更
  • レプリカ合意の読み込み
  • レプリカ合意の修正
  • レプリカ合意の削除
  • LDBM データベース設定の読み取り
  • 要求証明書
  • CA ACL を無視する要求証明書
  • 別のホストからの証明書の要求
  • CA からの証明書の取得
  • 証明書の取り消し
  • IPA 設定の書き込み
注記

コマンドラインから管理パーミッションを変更しようとし、変更できない属性を変更できないと、コマンドは失敗します。Web UI から管理パーミッションを変更しようとすると、変更できない属性が無効になります。

20.1.3. IdM の権限

特権は、ロールに適用されるパーミッションのグループです。
パーミッションは単一の操作を実行する権限を提供しますが、成功するには複数のパーミッションを必要とする特定の IdM タスクがあります。したがって、特権は、特定のタスクを実行するために必要な異なるパーミッションを組み合わせたものです。
たとえば、ユーザーを追加する場合は、以下のパーミッションが必要です。

  • 新規ユーザーエントリーの作成
  • ユーザーパスワードのリセット
  • 新規ユーザーをデフォルトの IPA ユーザーグループに追加

これらの 3 つの低レベルのタスクを、ユーザーの追加 という、権限がより高いレベルのタスクに組み合わせることで、ロールの管理が容易になります。ユーザーとユーザーグループとは別に、権限はホストおよびホストグループ、およびネットワークサービスにも割り当てられます。これにより、特定のネットワークサービスを使用するホストセットのユーザーセットによって、操作をきめ細かく制御できます。

注記

特権には、他の特権を含めることはできません。

20.1.4. IdM のロール

ロールは、ロールに指定したユーザーの権限の一覧です。
パーミッションにより、特定の低レベルのタスクの実行権限が付与されます (ユーザーの追加、グループの変更など)。特権は、1 つ以上のパーミッションを高レベルの抽象化に組み合わせます。たとえば、ユーザー管理者はユーザーを追加、削除、および変更できます。

注記

ロールに他のロールを含めることはできません。

20.1.5. Identity Management で事前定義されたロール

Red Hat Identity Management は、以下の事前定義済みのロールを提供します。

表20.1 Identity Management の定義済みロール

ロール特権説明

ヘルプデスク

Modify Users、Reset passwords、Modify Group メンバーシップ

簡単なユーザー管理タスクの実行

IT セキュリティースペシャリスト

Netgroups 管理者、HBAC 管理者、Sudo 管理者

ホストベースのアクセス制御、sudo ルールなどのセキュリティーポリシーの管理

IT スペシャリスト

ホスト管理者、ホストグループ管理者、サービス管理者、自動マウント管理者

ホストの管理を行います。

セキュリティーアーキテクト

委譲管理者、レプリケーション管理者、書き込み IPA 設定、パスワードポリシー管理者

Identity Management 環境の管理、信頼の作成、レプリカ合意の作成

ユーザー管理者

ユーザー管理者、グループ管理者、ステージユーザー管理者

ユーザーおよびグループの作成を行います。

20.2. CLI での IdM パーミッションの管理

本セクションでは、コマンドラインインターフェース (CLI) を使用して Identity Management (IdM) パーミッションを管理する方法を説明します。

前提条件

手順

  1. ipa permission-add コマンドを使用して、新しいパーミッションエントリーを作成します。
    たとえば、dns admin という名前のパーミッションを追加するには、次のコマンドを実行します。

    $ ipa permission-add "dns admin"
  2. 以下のオプションでパーミッションのプロパティーを指定します。

    • --bindtype は、バインドルールの種別を指定します。このオプションは、all 引数、anonymous 引数、および permission 引数を受け入れます。permission バインドタイプは、ロール経由でこのパーミッションを付与されたユーザーのみがこれを実行できることを意味します。
      以下に例を示します。

      $ ipa permission-add "dns admin" --bindtype=all

      --bindtype を指定しないと、permission がデフォルト値になります。

      注記

      デフォルト以外のバインドルールタイプを持つパーミッションを権限に追加することはできません。また、デフォルト以外のバインドルールタイプに対する特権にあるパーミッションを設定することはできません。

    • --right は、パーミッションによって付与される権限を一覧表示します。これは、非推奨の --permissions オプションに代わるものです。使用できる値は adddeletereadsearchcomparewriteall になります。

      複数の属性を設定するには、複数の --right オプションを使用するか、中括弧内にコンマ区切りリストを使用します。以下に例を示します。

      $ ipa permission-add "dns admin" --right=read --right=write
      $ ipa permission-add "dns admin" --right={read,write}
      注記

      add および delete はエントリーレベルの操作 (ユーザーの削除、グループの追加など) ですが、readsearchcomparewrite はより属性レベルです (userCertificate に書き込むことはできますが、userPassword を読み込むことはできません)。

    • --attrs は、パーミッションが付与される属性の一覧を提供します。
      複数の属性を設定するには、複数の --attrs オプションを使用するか、オプションを中括弧内にコンマ区切りリストで一覧表示します。以下に例を示します。

      $ ipa permission-add "dns admin" --attrs=description --attrs=automountKey
      $ ipa permission-add "dns admin" --attrs={description,automountKey}

      --attrs で提供される属性が存在し、指定のオブジェクトタイプに許可される属性である必要があります。指定しないと、コマンドがスキーマ構文エラーで失敗します。

    • --type は、ユーザー、ホスト、サービスなどのパーミッションが適用されるエントリーオブジェクトタイプを定義します。各タイプには、許可された属性の独自のセットがあります。
      以下に例を示します。

      $ ipa permission-add "manage service" --right=all --type=service --attrs=krbprincipalkey --attrs=krbprincipalname --attrs=managedby
    • --subtree はサブツリーエントリーを提供します。フィルターはこのサブツリーエントリーの下にあるすべてのエントリーをターゲットにします。既存のサブツリーエントリーを指定します。--subtree はワイルドカードや存在しないドメイン名 (DN) を受け入れません。ディレクトリーに DN を追加します。
      IdM は簡素化されたフラットディレクトリーツリー構造を使用しているため、--subtree を使用して自動マウントの場所 (他の設定のコンテナーまたは親エントリー) などの一部のエントリーをターゲットにすることができます。以下に例を示します。

      $ ipa permission-add "manage automount locations" --subtree="ldap://ldap.example.com:389/cn=automount,dc=example,dc=com" --right=write --attrs=automountmapname --attrs=automountkey --attrs=automountInformation
      注記

      --type オプションおよび --subtree オプションは相互に排他的です。--subtree の簡素化として --type のフィルターを組み込むことができます (これにより、管理者の作業が簡単になります)。

    • --filter は LDAP フィルターを使用して、パーミッションが適用されるエントリーを特定します。
      IdM は、指定のフィルターの有効性を自動的に確認します。このフィルターには、有効な LDAP フィルターを使用できます。以下に例を示します。

      $ ipa permission-add "manage Windows groups" --filter="(!(objectclass=posixgroup))" --right=write --attrs=description
    • --memberof は、グループが存在することを確認した後に、指定したグループのメンバーにターゲットフィルターを設定します。たとえば、このパーミッションを持つユーザーを許可するには、エンジニアグループのメンバーのログインシェルを変更します。

      $ ipa permission-add ManageShell --right="write" --type=user --attr=loginshell --memberof=engineers
    • --targetgroup は、グループが存在することを確認した後に、ターゲットを指定されたユーザーグループに設定します。たとえば、パーミッションを持つものに、(メンバーを追加または削除できるように) エンジニアグループに member 属性を書き込むには、次のコマンドを実行します。

      $ ipa permission-add ManageMembers --right="write" --subtree=cn=groups,cn=accounts,dc=example,dc=test --attr=member --targetgroup=engineers
    • 必要に応じて、ターゲットドメイン名 (DN) を指定できます。

      • --target は、パーミッションを適用する DN を指定します。ワイルドカードが許可されます。
      • --targetto は、エントリーを移動できる DN サブツリーを指定します。
      • --targetfrom は、エントリーを移動できる DN サブツリーを指定します。

20.3. 既存のパーミッションのコマンドオプション

必要に応じて、既存のパーミッションを変更するには、以下のバリアントを使用します。

  • 既存のパーミッションを編集するには、ipa permission-mod コマンドを使用します。パーミッションの追加と同じコマンドオプションを使用できます。
  • 既存のパーミッションを見つけるには、ipa permission-find コマンドを使用します。パーミッションの追加と同じコマンドオプションを使用できます。
  • 特定のパーミッションを表示するには、ipa permission-show コマンドを使用します。
    --raw 引数は、生成される未編集の 389-ds ACI を表示します。以下に例を示します。

     $ ipa permission-show <permission> --raw
  • ipa permission-del コマンドは、パーミッションを完全に削除します。

関連情報

ipa permission コマンドの詳細は、ipa の man ページおよび ipa help コマンドを参照してください。

20.4. CLI での IdM 権限の管理

本セクションでは、コマンドラインインターフェース (CLI) を使用して Identity Management (IdM) 権限を管理する方法を説明します。

前提条件

手順

  1. ipa privilege-add コマンドを使用して、権限エントリーを追加します。
    たとえば、説明付きの managing filesystems という名前を追加するには、次のコマンドを実行します。

    $ ipa privilege-add "managing filesystems" --desc="for filesystems"
  2. privilege-add-permission コマンドを使用して必要なパーミッションを特権グループに割り当てます。
    たとえば、パーミッション managing automount および managing ftp services を、managing filesystems 権限に追加するには、次のコマンドを実行します。

    $ ipa privilege-add-permission "managing filesystems" --permissions="managing automount" --permissions="managing ftp services"

20.5. 既存の特権のコマンドオプション

必要に応じて、既存の権限を変更するには、以下のバリアントを使用します。

  • 既存の権限を変更するには、ipa privilege-mod コマンドを使用します。
  • 既存の権限を見つけるには、ipa privilege-find コマンドを使用します。
  • 特定の特権を表示するには、ipa privilege-show コマンドを使用します。
  • ipa privilege-remove-permission コマンドは、特権から 1 つ以上のパーミッションを削除します。
  • ipa privilege-del コマンドは、権限を完全に削除します。

関連情報

ipa privilege コマンドの詳細は、ipa の man ページおよび ipa help コマンドを参照してください。

20.6. CLI での IdM ロールの管理

本セクションでは、コマンドラインインターフェース (CLI) を使用して Identity Management (IdM) ロールを管理する方法を説明します。

前提条件

手順

  1. ipa role-add コマンドを使用して、新規ロールエントリーを追加します。

    $ ipa role-add --desc="User Administrator" useradmin
    ------------------------
    Added role "useradmin"
    ------------------------
    Role name: useradmin
    Description: User Administrator
  2. ipa role-add-privilege コマンドを使用して、必要な権限をロールに追加します。

    $ ipa role-add-privilege --privileges="user administrators" useradmin
    Role name: useradmin
    Description: User Administrator
    Privileges: user administrators
    ----------------------------
    Number of privileges added 1
    ----------------------------
  3. ipa role-add-member コマンドを使用して、必要なメンバーをロールに追加します。許可されるメンバータイプ: ユーザー、グループ、ホスト、およびホストグループ。
    たとえば、useradmins という名前のグループを、以前に作成した useradmin ロールに追加するには、次のコマンドを実行します。

    $ ipa role-add-member --groups=useradmins useradmin
    Role name: useradmin
    Description: User Administrator
    Member groups: useradmins
    Privileges: user administrators
    -------------------------
    Number of members added 1
    -------------------------

20.7. 既存ロールのコマンドオプション

必要に応じて、既存のロールを変更するには、以下のバリアントを使用します。

  • 既存のロールを変更するには、ipa role-mod コマンドを使用します。
  • 既存のロールを見つけるには、ipa role-find コマンドを使用します。
  • 特定のロールを表示するには、ipa role-show コマンドを使用します。
  • ロールからメンバーを削除するには、ipa role-remove-member コマンドを使用します。
  • ipa role-remove-privilege コマンドは、ロールから 1 つ以上の権限を削除します。
  • ipa role-del コマンドは、ロールを完全に削除します。

関連情報

ipa role コマンドの詳細は、man ページの ipa および ipa help コマンドを参照してください。

第21章 IdM Web UI を使用したロールベースのアクセス制御の管理

本章では、Identity Management (IdM) でロールベースのアクセス制御を紹介し、Web インターフェース (Web UI) で以下の操作を説明します。

21.1. IdM のロールベースのアクセス制御

IdM のロールベースアクセス制御 (RBAC) は、セルフサービス制御および委譲アクセス制御と比較して、非常に異なる種類の権限をユーザーに付与します。

ロールベースのアクセス制御は、以下の 3 つの部分で構成されます。

  • パーミッション は、ユーザーの追加または削除、グループの変更、読み取りアクセスの有効化など、特定のタスクを実行する権限を付与します。
  • 特権 は、権限を組み合わせます。たとえば、新しいユーザーを追加するために必要なすべてのパーミッションです。
  • ロール は、ユーザー、ユーザーグループ、ホスト、またはホストグループに特権のセットを付与します。

21.1.1. IdM の権限

パーミッションは、ロールベースのアクセス制御の最低レベル単位であり、操作が適用される LDAP エントリーとともに操作を定義します。ブロックを構築するのと同様に、パーミッションは必要に応じて多くの権限に割り当てることができます。
1 つ以上の 権限 は許可される操作を定義します。

  • write
  • read
  • search
  • compare
  • add
  • delete
  • all

これらの操作は、3 つの基本的な ターゲット に適用されます。

  • subtree - ドメイン名( DN) (この DN のサブツリー)
  • ターゲットフィルター: LDAP フィルター
  • target: ワイルドカードを使用したエントリーの指定が可能な DN

また、以下の便利なオプションは対応する属性を設定します。

  • タイプ: オブジェクトのタイプ (ユーザー、グループなど) (subtree および target filter を設定します)。
  • memberof: グループのメンバー。ターゲットフィルター を設定します。
  • targetgroup: 特定のグループの変更 (グループメンバーシップの管理権限の付与など) を変更するアクセスを付与します (ターゲットを設定します)。

IdM 権限を使用すると、どのユーザーがどのオブジェクトにアクセスできるか、さらにはこれらのオブジェクトの属性にアクセスできるかどうかを制御できます。IdM を使用すると、個々の属性をホワイトリストまたはブラックリストに登録したり、特定の IdM 機能 (ユーザー、グループ、sudo など) の全体の可視性を、すべての匿名ユーザー、すべての認証済みユーザー、または特権ユーザーの特定のグループに変更したりできます。
たとえば、このアプローチの柔軟性は、ユーザーまたはグループがアクセスする必要がある特定のセクションにのみユーザーまたはグループへのアクセスを制限し、他のセクションを完全に非表示にする場合に便利です。

注記

パーミッションには他のパーミッションを含めることはできません。

21.1.2. デフォルトの管理パーミッション

管理パーミッションは、IdM にデフォルトで提供されるパーミッションです。これは、以下の相違点で、ユーザーが作成した他のパーミッションのように動作します。

  • これらの属性を削除したり、名前、場所、およびターゲット属性を変更したりすることはできません。
  • これには 3 つの属性セットがあります。

    • デフォルト の属性。IdM で管理されているため、ユーザーは変更できません。
    • 追加されている 属性 (ユーザーによって追加される追加属性)
    • 除外されている 属性 (ユーザーが削除した属性)

管理されているパーミッションは、デフォルトの属性セットと追加されている属性セットには表示されますが、除外されている属性セットには表示されていないすべての属性に適用されます。

注記

管理されているパーミッションを削除することはできませんが、そのバインドタイプをパーミッションに設定し、すべての権限から管理パーミッションを削除すると、そのパーミッションを効果的に無効にできます。

管理されたすべてのパーミッションの名前は System: から始まります (例: System: Add Sudo rule または System: Modify Services)。以前のバージョンの IdM は、デフォルトのパーミッションに異なるスキームを使用していました。たとえば、ユーザーは削除できず、権限に割り当てるしかできませんでした。これらのデフォルトパーミッションのほとんどは管理パーミッションに切り替わっていますが、以下のパーミッションは引き続き以前のスキームを使用します。

  • Automember Rebuild メンバーシップタスクの追加
  • 設定サブエントリーの追加
  • レプリカ合意の追加
  • 証明書削除保留
  • CA から証明書のステータスを取得します。
  • DNA 範囲の読み取り
  • DNA 範囲の変更
  • PassSync マネージャーの設定の読み取り
  • PassSync Manager 設定の変更
  • レプリカ合意の読み込み
  • レプリカ合意の修正
  • レプリカ合意の削除
  • LDBM データベース設定の読み取り
  • 要求証明書
  • CA ACL を無視する要求証明書
  • 別のホストからの証明書の要求
  • CA からの証明書の取得
  • 証明書の取り消し
  • IPA 設定の書き込み
注記

コマンドラインから管理パーミッションを変更しようとし、変更できない属性を変更できないと、コマンドは失敗します。Web UI から管理パーミッションを変更しようとすると、変更できない属性が無効になります。

21.1.3. IdM の権限

特権は、ロールに適用されるパーミッションのグループです。
パーミッションは単一の操作を実行する権限を提供しますが、成功するには複数のパーミッションを必要とする特定の IdM タスクがあります。したがって、特権は、特定のタスクを実行するために必要な異なるパーミッションを組み合わせたものです。
たとえば、ユーザーを追加する場合は、以下のパーミッションが必要です。

  • 新規ユーザーエントリーの作成
  • ユーザーパスワードのリセット
  • 新規ユーザーをデフォルトの IPA ユーザーグループに追加

これらの 3 つの低レベルのタスクを、ユーザーの追加 という、権限がより高いレベルのタスクに組み合わせることで、ロールの管理が容易になります。ユーザーとユーザーグループとは別に、権限はホストおよびホストグループ、およびネットワークサービスにも割り当てられます。これにより、特定のネットワークサービスを使用するホストセットのユーザーセットによって、操作をきめ細かく制御できます。

注記

特権には、他の特権を含めることはできません。

21.1.4. IdM のロール

ロールは、ロールに指定したユーザーの権限の一覧です。
パーミッションにより、特定の低レベルのタスクの実行権限が付与されます (ユーザーの追加、グループの変更など)。特権は、1 つ以上のパーミッションを高レベルの抽象化に組み合わせます。たとえば、ユーザー管理者はユーザーを追加、削除、および変更できます。

注記

ロールに他のロールを含めることはできません。

21.1.5. Identity Management で事前定義されたロール

Red Hat Identity Management は、以下の事前定義済みのロールを提供します。

表21.1 Identity Management の定義済みロール

ロール特権説明

ヘルプデスク

Modify Users、Reset passwords、Modify Group メンバーシップ

簡単なユーザー管理タスクの実行

IT セキュリティースペシャリスト

Netgroups 管理者、HBAC 管理者、Sudo 管理者

ホストベースのアクセス制御、sudo ルールなどのセキュリティーポリシーの管理

IT スペシャリスト

ホスト管理者、ホストグループ管理者、サービス管理者、自動マウント管理者

ホストの管理を行います。

セキュリティーアーキテクト

委譲管理者、レプリケーション管理者、書き込み IPA 設定、パスワードポリシー管理者

Identity Management 環境の管理、信頼の作成、レプリカ合意の作成

ユーザー管理者

ユーザー管理者、グループ管理者、ステージユーザー管理者

ユーザーおよびグループの作成を行います。

21.2. IdM Web UI でのパーミッションの管理

本セクションでは、Web インターフェース (IdM Web UI) を使用して、Identity Management (IdM) でパーミッションを管理する方法を説明します。

前提条件

手順

  1. 新しいパーミッションを追加するには、IPA Server タブで ロールベースのアクセス制御 サブメニューを開き、パーミッション を選択します。

    Permissions task

  2. パーミッションの一覧が開きます。パーミッションの一覧の上部にある Add ボタンをクリックします。

    Adding a new permission

  3. Add Permission フォームが開きます。新しいパーミッションの名前を指定し、そのプロパティーを適宜定義します。

    Form for adding a permission

  4. 適切なバインドルールタイプを選択します。

    • permission はデフォルトのパーミッションタイプで、権限およびロール経由でアクセスを付与します。
    • all は、パーミッションをすべての認証ユーザーに適用することを指定します。
    • anonymous は、認証されていないユーザーを含む、パーミッションがすべてのユーザーに適用されることを指定します。

      注記

      デフォルト以外のバインドルールタイプを持つパーミッションを権限に追加することはできません。また、デフォルト以外のバインドルールタイプに対する特権にあるパーミッションを設定することはできません。

  5. 権限が付与されている権限で、このパーミッションで 付与する権限 を選択します。
  6. パーミッションのターゲットエントリーを識別する方法を定義します。

    • タイプ は、ユーザー、ホスト、またはサービスなどのエントリータイプを指定します。Type 設定の値を選択すると、そのエントリータイプのこの ACI からアクセス可能なすべての属性の一覧が Effective 属性 に表示されます。Type を定義すると、Subtree および Target DN が事前定義された値のいずれかに設定されます。
    • Subtree (必須) はサブツリーエントリーを指定します。このサブツリーエントリーの下にあるすべてのエントリーがターゲットになります。Subtree はワイルドカードや存在しないドメイン名 (DN) を許可しないため、既存のサブツリーエントリーを指定します。例: cn=automount,dc=example,dc=com
    • 追加のターゲットフィルター は LDAP フィルターを使用して、パーミッションが適用されるエントリーを特定します。フィルターには任意の有効な LDAP フィルターを使用できます (たとえば、(!(objectclass=posixgroup))
      ) IdM は指定のフィルターの有効性を自動的にチェックします。無効なフィルターを入力すると、パーミッションを保存しようとすると、IdM はこれについて警告します。
    • ターゲット DN はドメイン名 (DN) を指定し、ワイルドカードを受け入れます。例: uid=*,cn=users,cn=accounts,dc=com
    • グループのメンバー は、指定したグループのメンバーにターゲットフィルターを設定します。フィルター設定を指定し、追加 をクリックすると、IdM がフィルターを検証します。すべてのパーミッション設定が正しい場合は、IdM が検索を実行します。パーミッション設定の一部が正しくない場合、IdM は、どの設定が正しく設定されているかを示すメッセージが表示されます。
  7. パーミッションに属性を追加します。

    • Type を設定する場合は、利用可能な ACI 属性の一覧から 有効な属性 を選択します。
    • Type を使用しない場合は、有効な属性 フィールドに属性を手動で書き込みます。一度に 1 つの属性を追加します。複数の属性を追加するには、Add をクリックして別の入力フィールドを追加します。

      重要

      パーミッションの属性を設定しないと、パーミッションはデフォルトですべての属性が含まれます。

  8. フォーム下部の Add ボタンでパーミッションの追加を終了します。

    • 追加 ボタンをクリックしてパーミッションを保存し、パーミッションの一覧に戻ります。
    • パーミッションを保存し、Add and Add another ボタンをクリックして、同じフォームに追加パーミッションを継続できます。
    • Add and Edit ボタンを使用すると、新たに作成されたパーミッションを保存して編集を継続できます。
  9. 任意です。また、パーミッションの一覧から名前をクリックして、パーミッション権限 ページを表示することで、既存のパーミッションのプロパティーを編集することもできます。
  10. 任意です。既存のパーミッションを削除する必要がある場合は、一覧で名前の横にあるチェックボックスにチェックマークを入れて、削除 ボタンをクリックして、パーミッションの削除 ダイアログを表示します。

    注記

    デフォルトの管理パーミッションに対する操作は制限されています。変更できない属性は IdM Web UI で無効になり、管理パーミッションを完全に削除することはできません。
    管理されているパーミッションを削除することはできませんが、そのバインドタイプをパーミッションに設定し、すべての権限から管理パーミッションを削除すると、そのパーミッションを効果的に無効にできます。

たとえば、パーミッションを持つものに、(メンバーを追加または削除できるように) エンジニアグループに member 属性を書き込むには、次のコマンドを実行します。
Example for adding a permission

21.3. IdM WebUI での権限の管理

本セクションでは、Web インターフェース (IdM Web UI) を使用して IdM の権限を管理する方法を説明します。

前提条件

手順

  1. 新しい権限を追加するには、IPA Server タブで ロールベースのアクセス制御 サブメニューを開き、特権 を選択します。

    Privileges task

  2. 特権の一覧が開きます。特権一覧の上部にある Add ボタンをクリックします。

    Adding a new privilege

  3. Add Privilege フォームが開きます。特権の名前と説明を入力します。

    Form for adding a privilege

  4. 新しい特権を保存し、権限設定ページに移動し、パーミッションを追加するには、Add and Edit ボタンをクリックします。
  5. 特権一覧の権限名をクリックして、特権のプロパティーを編集します。特権設定ページが開きます。
  6. Permissions タブには、選択した権限に含まれるパーミッションの一覧が表示されます。一覧上部の Add ボタンをクリックして、権限を特権に追加します。

    Adding Permissions

  7. 追加する各パーミッションの名前の横にあるチェックボックスにチェックマークを入れ、> ボタンを使用してパーミッションを Prospective 列に移動します。

    Selecting Permissions

  8. Add ボタンをクリックして確定します。
  9. 任意です。パーミッションを削除する必要がある場合は、関連するパーミッションの横にあるチェックボックス (パーミッションからの権限の削除ダイアログ) を表示したら、削除 ボタンをクリックします。
  10. 任意です。既存の特権を削除する必要がある場合は、一覧で名前の横にあるチェックボックス (Remove privileges ダイアログが開きます) の横にあるチェックボックスを閉じたら、Delete ボタンをクリックします。

21.4. IdM Web UI でのロールの管理

本セクションでは、Web インターフェース (IdM Web UI) を使用して、Identity Management (IdM) のロールを管理する方法を説明します。

前提条件

手順

  1. 新規ロールを追加するには、IPA Server タブの Role-Based Access Control サブメニューを開き、Roles を選択します。

    Roles task

  2. ロールの一覧が開きます。ロールベースのアクセス制御手順のリストの上部にある Add ボタンをクリックします。

    Adding a new role

  3. Add Role フォームが開きます。ロール名と説明を入力します。

    Form for adding a role

  4. Add and Edit ボタンをクリックして新規ロールを保存し、ロール設定ページに移動し、権限およびユーザーを追加します。
  5. ロール一覧のロール名をクリックして、ロールのプロパティーを編集します。ロール設定ページが開きます。
  6. 関連するリストの上部にある Add ボタンをクリックして、UsersUsers GroupsHostsHost Groups、または Services タブを使用してメンバーを追加します。

    Adding users

  7. 開いているウィンドウで、左側のメンバーを選択し、> ボタンを使用してそれらを Prospective 列に移動します。

    Selecting Users

  8. Privileges タブの上部にある Add をクリックします。

    Adding Privileges

  9. 左側の権限を選択し、> ボタンを使用してそれらを Prospective 列に移動します。

    Selecting Privileges

  10. Add ボタンをクリックして保存します。
  11. 任意です。ロールから特権またはメンバーを削除する必要がある場合は、削除するエンティティーの名前の横にあるチェックボックスにチェックマークを入れてから Delete ボタンをクリックします。ダイアログが開きます。
  12. 任意です。既存のロールを削除する必要がある場合は、一覧で名前の横にあるチェックボックスを編集した後に Delete ボタンをクリックすると、Remove roles ダイアログが表示します。

第22章 ID ビューを使用した IdM クライアントのユーザー属性値を上書きする

Identity Management (IdM) ユーザーが、IdM LDAP サーバーに保存されているユーザー属性またはグループ属性 (ログイン名、ホームディレクトリー、認証に使用する証明書、SSH 鍵など) を上書きする場合、IdM 管理者は IdM ID ビューを使用して、特定の IdM クライアントの値を再定義できます。たとえば、IdM へのログインに最も一般的に使用される IdM クライアントのユーザーに、別のホームディレクトリーを指定できます。

本章では、クライアントとして IdM に登録されたホストの IdM ユーザーに関連付けられた POSIX 属性値を再定義する方法を説明します。本章では、ユーザーログイン名とホームディレクトリーを再定義する方法を説明します。

本章では、以下のセクションを説明します。

22.1. ID ビュー

Identity Management (IdM) の ID ビューは、以下の情報を指定する IdM クライアント側のビューです。

  • 集中的に定義された POSIX ユーザーまたはグループ属性の新しい値
  • 新しい値が適用されるクライアントホスト。

ID ビューには、1 つ以上のオーバーライドが含まれます。上書きは、一元管理された POSIX 属性値の特定の代替です。

IdM サーバーでは、IdM クライアントに ID ビューのみを定義できます。IdM クライアントにクライアント側のオーバーライドをローカルで設定することはできません。

たとえば、ID ビューを使用して、以下のゴールを達成することができます。

  • 環境ごとに異なる属性値を定義します。たとえば、IdM 管理者または別の IdM ユーザーは、さまざまな IdM クライアントに異なるホームディレクトリーを持つことができます。/home/encrypted/username を、ある IdM クライアントでこのユーザーのホームディレクトリーに、別のクライアントの /dropbox/username に設定できます。この状況で ID ビューを使用すると、クライアントの /etc/sssd/sssd.conf ファイルにある fallback_homediroverride_homedir、または他のホームディレクトリー変数の変更など、すべてのユーザーに影響します。手順例は、 「IdM クライアントで IdM ユーザーのホームディレクトリーを上書きする ID ビューの追加」を参照してください。
  • 以前に生成された属性値を、ユーザーの UID の上書きなど、別の値に置き換えます。この機能は、たとえば、IdM ユーザーの UID を 1009 にするなど、通常は LDAP で行うのが困難なシステム全体の変更を実現する場合に便利です。IdM ID 範囲は、IdM ユーザー UID の生成に使用されます。1000 程度の低い値、または 10000 だとしても開始しません。IdM ユーザーがすべての IdM クライアントで UID 1009 のローカルユーザーの権限を借用する理由が存在する場合は、ID ビューを使用して、IdM でユーザーが作成したときに生成された IdM ユーザーの UID を上書きできます。
重要

ID ビューは、IdM サーバーではなく、IdM クライアントにのみ適用できます。

関連情報

  • Active Directory (AD) に関連する環境で ID ビューを使用することもできます。詳細は、『Windows 統合ガイド』「ID ビューの使用」の章を参照してください。
  • 集中管理ドメインの一部ではないホストの ID ビューを設定することもできます。詳細は、『システムレベルの認証ガイド』「SSSD クライアント側」を参照してください。

22.2. SSSD パフォーマンスにおける ID ビューによる悪影響の可能性

ID ビューを定義すると、IdM は必要なオーバーライド値を、IdM サーバーの System Security Services Daemon (SSSD) キャッシュに配置します。その後、IdM クライアントで実行している SSSD は、サーバーキャッシュからオーバーライド値を取得します。

特定の最適化と ID ビューを同時に実行できないため、ID ビューを適用すると、SSSD (System Security Services Daemon) のパフォーマンスに悪影響を与える可能性があります。たとえば、ID ビューは、SSSD がサーバー上でグループを検索するプロセスの最適化を防ぎます。

  • ID ビューを使用して、グループ名が上書きされる場合に、SSSD は、グループメンバー名の返された一覧のすべてのメンバーを確認する必要があります。
  • ID ビューがないと、SSSD は、グループオブジェクトのメンバー属性からのみユーザー名を収集します。

この負の効果は、SSSD キャッシュが空であるか、またはキャッシュをクリアすると、すべてのエントリーが無効になります。

22.3. ID ビューが上書きできる属性

ID ビューは、ユーザーおよびグループ ID の上書きで構成されます。オーバーライドは、新しい POSIX 属性値を定義します。

ユーザー ID およびグループ ID の上書きは、以下の POSIX 属性の新しい値を定義できます。

ユーザー属性
  • ログイン名 (uid)
  • GECOS エントリー (gecos)
  • UID 番号 (uidNumber)
  • GID 番号 (gidNumber)
  • ログインシェル (loginShell)
  • ホームディレクトリー (homeDirectory)
  • SSH 公開鍵 (ipaSshPubkey)
  • 証明書 (userCertificate)
グループ属性
  • グループ名 (cn)
  • グループ GID 番号 (gidNumber)

22.4. ID view コマンドのヘルプの取得

IdM コマンドラインインターフェース (CLI) で、Identity Management (IdM) ID ビューに関連するコマンドのヘルプを表示できます。

前提条件

  • IdM ユーザーの Kerberos チケットを取得している。

手順

  • ID ビューおよび上書きの管理に使用するコマンドをすべて表示するには、次のコマンドを実行します。

    $ ipa help idviews
    ID Views
    
    Manage ID Views
    
    IPA allows to override certain properties of users and groups[...]
    [...]
    Topic commands:
      idoverridegroup-add          Add a new Group ID override
      idoverridegroup-del          Delete a Group ID override
    [...]
  • 特定のコマンドの詳細なヘルプを表示するには、コマンドに --help オプションを追加します。

    $ ipa idview-add --help
    Usage: ipa [global-options] idview-add NAME [options]
    
    Add a new ID View.
    Options:
      -h, --help      show this help message and exit
      --desc=STR      Description
    [...]

22.5. ID ビューを使用して、特定のホストにある IdM ユーザーのログイン名を上書き

本セクションでは、特定の IdM ユーザーに関連付けられた POSIX 属性値を上書きする特定の Identity Management (IdM) クライアントに ID ビューを作成する方法を説明します。この手順では、idm_user という名前の IdM ユーザーが、user_1234 ログイン名を使用して host1 という名前の IdM クライアントにログインできるようにする ID ビューの例を使用します。

前提条件

  • admin などの必要な権限を持つユーザーとしてログインしている。

手順

  1. 新しい ID ビューを作成します。たとえば、example_for_host1 という名前の ID ビューを作成するには、次のコマンドを実行します。

    $ ipa idview-add example_for_host1
    ---------------------------
    Added ID View "example_for_host1"
    ---------------------------
      ID View Name: example_for_host1
  2. ユーザーオーバーライドを example_for_host1 ID ビューに追加します。ユーザーログインを上書きするには、以下を実行します。

    • ipa idoverrideuser-add コマンドを入力します。
    • ID ビューの名前を追加します。
    • ユーザー名 (アンカーとも呼ばれます) を追加します。
    • --login オプションを追加します。

      $ ipa idoverrideuser-add example_for_host1 idm_user --login=user_1234
      -----------------------------
      Added User ID override "idm_user"
      -----------------------------
        Anchor to override: idm_user
        User login: user_1234

      利用可能なオプションの一覧は、ipa idoverrideuser-add --help を実行します。

      注記

      ipa idoverrideuser-add --certificate コマンドは、指定された ID ビューのアカウントの既存証明書をすべて置き換えます。追加の証明書を追加するには、代わりに ipa idoverrideuser-add-cert コマンドを使用します。

      $ ipa idoverrideuser-add-cert example_for_host1 user --certificate="MIIEATCC..."
  3. 必要に応じて、ipa idoverrideuser-mod コマンドを使用すると、既存のユーザーのオーバーライドに新しい属性値を指定できます。
  4. example_for_host1host1.idm.example.com ホストに適用します。

    $ ipa idview-apply example_for_host1 --hosts=host1.idm.example.com
    -----------------------------
    Applied ID View "example_for_host1"
    -----------------------------
    hosts: host1.idm.example.com
    ---------------------------------------------
    Number of hosts the ID View was applied to: 1
    ---------------------------------------------
    注記

    ipa idview-apply コマンドでは、--hostgroups オプションも使用できます。このオプションは、ID ビューを、指定したホストグループに属するホストに適用しますが、ID ビューをホストグループ自体と関連付けません。代わりに、--hostgroups オプションは指定されたホストグループのメンバーを拡張して、--hosts オプションを個別に適用します。

    つまり、ホストが今後ホストグループに追加されると、ID ビューは新しいホストには適用されません。

  5. 新しい設定を host1.idm.example.com システムに適用するには、次のコマンドを実行します。

    1. root でシステムに対して SSH 接続します。

      $ ssh root@host1
      Password:
    2. SSSD キャッシュを削除します。

      root@host1 ~]# sss_cache -E
    3. SSSD デーモンを再起動します。
    root@host1 ~]# systemctl restart sssd

検証手順

  • user_1234 の認証情報がある場合は、その認証情報を使用して host1 で IdM にログインできます。

    1. ログイン名に user_1234 を使用して host1 に SSH を実行します。

      [root@r8server ~]# ssh user_1234@host1.idm.example.com
      Password:
      
      Last login: Sun Jun 21 22:34:25 2020 from 192.168.122.229
      [user_1234@host1 ~]$
    2. 作業ディレクトリーを表示します。

      [user_1234@host1 ~]$ pwd
      /home/idm_user/
  • host1 に root 認証情報がある場合は、idm_user および user_1234id コマンドの出力を確認できます。

    [root@host1 ~]# id idm_user
    uid=779800003(user_1234) gid=779800003(idm_user) groups=779800003(idm_user)
    [root@host1 ~]# user_1234
    uid=779800003(user_1234) gid=779800003(idm_user) groups=779800003(idm_user)

22.6. IdM ID ビューの変更

Identity Management (IdM)の ID ビューは、特定の IdM ユーザーに関連する POSIX 属性値を上書きします。本セクションでは、既存の ID ビューを変更する方法を説明します。具体的には、idm_user という名前のユーザーが IdM クライアントの host1.idm.example.com/home/idm_user/ ではなく、ユーザーのホームディレクトリーとして /home/user_1234/ ディレクトリーを使用できるように ID ビューを変更する方法を説明します。

前提条件

  • host1.idm.example.com への root アクセスがある。
  • admin などの必要な権限を持つユーザーとしてログインしている。
  • IdM クライアント host1 に適用される idm_user の ID ビューが設定されている。

手順

  1. root で、idm_user がユーザーのホームディレクトリーとして host1.idm.example.com で使用するディレクトリーを作成します。

    [root@host1 /]# mkdir /home/user_1234/
  2. ディレクトリーの所有権を変更します。

    [root@host1 /]# chown idm_user:idm_user /home/user_1234/
  3. ID ビューが現在適用されているホストを含め、ID ビューを表示します。example_for_host1 という名前の ID ビューを表示するには、次のコマンドを実行します。

    $ ipa idview-show example_for_host1 --all
      dn: cn=example_for_host1,cn=views,cn=accounts,dc=idm,dc=example,dc=com
      ID View Name: example_for_host1
      User object override: idm_user
      Hosts the view applies to: host1.idm.example.com
      objectclass: ipaIDView, top, nsContainer

    この出力は、現在 ID ビューが host1.idm.example.com に適用されることを示しています。

  4. example_for_host1 ID ビューのユーザーの上書きを変更します。ユーザーのホームディレクトリーを上書きするには、次のコマンドを実行します。

    • ipa idoverrideuser-add コマンドを入力します。
    • ID ビューの名前を追加します。
    • ユーザー名 (アンカーとも呼ばれます) を追加します。
    • --homedir オプションを追加します。

      $ ipa idoverrideuser-mod example_for_host1 idm_user --homedir=/home/user_1234
      -----------------------------
      Modified an User ID override "idm_user"
      -----------------------------
        Anchor to override: idm_user
        User login: user_1234
        Home directory: /home/user_1234/

    利用可能なオプションの一覧は、ipa idoverrideuser-mod --help を実行します。

  5. 新しい設定を host1.idm.example.com システムに適用するには、次のコマンドを実行します。

    1. root でシステムに対して SSH 接続します。

      $ ssh root@host1
      Password:
    2. SSSD キャッシュを削除します。

      root@host1 ~]# sss_cache -E
    3. SSSD デーモンを再起動します。
    root@host1 ~]# systemctl restart sssd

検証手順

  1. idm_user として host1 へのSSH:

    [root@r8server ~]# ssh idm_user@host1.idm.example.com
    Password:
    
    Last login: Sun Jun 21 22:34:25 2020 from 192.168.122.229
    [user_1234@host1 ~]$
  2. 作業ディレクトリーを出力します。

    [user_1234@host1 ~]$ pwd
    /home/user_1234/

22.7. IdM クライアントで IdM ユーザーのホームディレクトリーを上書きする ID ビューの追加

Identity Management (IdM)の ID ビューは、特定の IdM ユーザーに関連する POSIX 属性値を上書きします。本セクションでは、host1 という名前の IdM クライアントの idm_user に適用される ID ビューを作成し、ユーザーが /home/idm_user/ ではなく、ユーザーホームディレクトリーとして /home/user_1234/ ディレクトリーを使用できるようにする方法を説明します。

前提条件

  • host1.idm.example.com への root アクセスがある。
  • admin などの必要な権限を持つユーザーとしてログインしている。

手順

  1. root で、idm_user がユーザーのホームディレクトリーとして host1.idm.example.com で使用するディレクトリーを作成します。

    [root@host1 /]# mkdir /home/user_1234/
  2. ディレクトリーの所有権を変更します。

    [root@host1 /]# chown idm_user:idm_user /home/user_1234/
  3. ID ビューを作成します。たとえば、example_for_host1 という名前の ID ビューを作成するには、次のコマンドを実行します。

    $ ipa idview-add example_for_host1
    ---------------------------
    Added ID View "example_for_host1"
    ---------------------------
      ID View Name: example_for_host1
  4. ユーザーオーバーライドを example_for_host1 ID ビューに追加します。ユーザーのホームディレクトリーを上書きするには、次のコマンドを実行します。

    • ipa idoverrideuser-add コマンドを入力します。
    • ID ビューの名前を追加します。
    • ユーザー名 (アンカーとも呼ばれます) を追加します。
    • --homedir オプションを追加します。
    $ ipa idoverrideuser-add example_for_host1 idm_user --homedir=/home/user_1234
    -----------------------------
    Added User ID override "idm_user"
    -----------------------------
      Anchor to override: idm_user
      Home directory: /home/user_1234/
  5. example_for_host1host1.idm.example.com ホストに適用します。

    $ ipa idview-apply example_for_host1 --hosts=host1.idm.example.com
    -----------------------------
    Applied ID View "example_for_host1"
    -----------------------------
    hosts: host1.idm.example.com
    ---------------------------------------------
    Number of hosts the ID View was applied to: 1
    ---------------------------------------------
    注記

    ipa idview-apply コマンドでは、--hostgroups オプションも使用できます。このオプションは、ID ビューを、指定したホストグループに属するホストに適用しますが、ID ビューをホストグループ自体と関連付けません。代わりに、--hostgroups オプションは指定されたホストグループのメンバーを拡張して、--hosts オプションを個別に適用します。

    つまり、ホストが今後ホストグループに追加されると、ID ビューは新しいホストには適用されません。

  6. 新しい設定を host1.idm.example.com システムに適用するには、次のコマンドを実行します。

    1. root でシステムに対して SSH 接続します。

      $ ssh root@host1
      Password:
    2. SSSD キャッシュを削除します。

      root@host1 ~]# sss_cache -E
    3. SSSD デーモンを再起動します。
    root@host1 ~]# systemctl restart sssd

検証手順

  1. idm_user として host1 へのSSH:

    [root@r8server ~]# ssh idm_user@host1.idm.example.com
    Password:
    Activate the web console with: systemctl enable --now cockpit.socket
    
    Last login: Sun Jun 21 22:34:25 2020 from 192.168.122.229
    [idm_user@host1 /]$
  2. 作業ディレクトリーを出力します。

    [idm_user@host1 /]$ pwd
    /home/user_1234/

22.8. IdM ホストグループへの ID ビューの適用

ipa idview-apply コマンドは、--hostgroups オプションを受け入れます。ただし、このオプションは、ID ビューを、指定されたホストグループに属するホストに適用しますが、ID ビューをホストグループ自体に動的に関連付けることはありません。--hostgroups オプションは、指定したホストグループのメンバーを拡張して、--hosts オプションを個別に適用します。

新しいホストを後でホストグループに追加する場合は、--hosts オプションで ipa idview-apply コマンドを使用して、新しいホストに ID ビューを手動で適用する必要があります。

同様に、ホストグループからホストを削除すると、ID ビューは削除後にホストに割り当てられます。削除されたホストから ID ビューを適用を解除するには、ipa idview-unapply id_view_name --hosts=name_of_the_removed_host コマンドを実行する必要があります。

本セクションでは、以下のゴールを達成する方法を説明します。

  1. ホストグループを作成し、そのホストに追加する方法。
  2. ID ビューをホストグループに適用する方法。
  3. ホストグループに新規ホストを追加し、ID ビューを新しいホストに適用する方法。

前提条件

手順

  1. ホストグループを作成し、そのホストを追加します。

    1. ホストグループを作成します。たとえば、baltimore という名前のホストグループを作成するには、次のコマンドを実行します。

      [root@master ~]# ipa hostgroup-add --desc="Baltimore hosts" baltimore
      ---------------------------
      Added hostgroup "baltimore"
      ---------------------------
      Host-group: baltimore
      Description: Baltimore hosts
    2. ホストグループにホストを追加します。たとえば、host102 および host103baltimore ホストグループに追加するには、次のコマンドを実行します。

      [root@master ~]# ipa hostgroup-add-member --hosts={host102,host103} baltimore
      Host-group: baltimore
      Description: Baltimore hosts
      Member hosts: host102.idm.example.com, host103.idm.example.com
      -------------------------
      Number of members added 2
      -------------------------
  2. ホストグループのホストに ID ビューを適用します。たとえば、example_for_host1 ID ビューを ‍baltimore ホストグループに適用するには、次のコマンドを実行します。

    [root@master ~]# ipa idview-apply --hostgroups=baltimore
    ID View Name: example_for_host1
    -----------------------------------------
    Applied ID View "example_for_host1"
    -----------------------------------------
      hosts: host102.idm.example.com, host103.idm.example.com
    ---------------------------------------------
    Number of hosts the ID View was applied to: 2
    ---------------------------------------------
  3. ホストグループに新規ホストを追加し、ID ビューを新しいホストに適用します。

    1. ホストグループに新規ホストを追加します。たとえば、somehost.idm.example.com ホストを baltimore ホストグループに追加するには、次のコマンドを実行します。

      [root@master ~]# ipa hostgroup-add-member --hosts=somehost.idm.example.com baltimore
        Host-group: baltimore
        Description: Baltimore hosts
        Member hosts:  host102.idm.example.com, host103.idm.example.com,somehost.idm.example.com
      -------------------------
      Number of members added 1
      -------------------------
    2. 必要に応じて、ID ビュー情報を表示します。たとえば、example_for_host1 ID ビューの詳細を表示するには、次のコマンドを実行します。

      [root@master ~]# ipa idview-show example_for_host1 --all
        dn: cn=example_for_host1,cn=views,cn=accounts,dc=idm,dc=example,dc=com
        ID View Name: example_for_host1
      [...]
        Hosts the view applies to: host102.idm.example.com, host103.idm.example.com
        objectclass: ipaIDView, top, nsContainer

      この出力は、ID ビューが baltimore ホストグループ内の新たに追加されたホスト somehost.idm.example.com に適用されていないことを示しています。

    3. ID ビューを新規ホストに適用します。たとえば、ID ビュー example_for_host1somehost.idm.example.com に適用するには、次のコマンドを実行します。

      [root@master ~]# ipa idview-apply --host=somehost.idm.example.com
      ID View Name: example_for_host1
      -----------------------------------------
      Applied ID View "example_for_host1"
      -----------------------------------------
        hosts: somehost.idm.example.com
      ---------------------------------------------
      Number of hosts the ID View was applied to: 1
      ---------------------------------------------

検証手順

  • ID ビュー情報を再度表示します。

    [root@master ~]# ipa idview-show example_for_host1 --all
      dn: cn=example_for_host1,cn=views,cn=accounts,dc=idm,dc=example,dc=com
      ID View Name: example_for_host1
    [...]
      Hosts the view applies to: host102.idm.example.com, host103.idm.example.com, somehost.idm.example.com
      objectclass: ipaIDView, top, nsContainer

    この出力は、ID ビューが baltimore ホストグループ内の新たに追加されたホスト somehost.idm.example.com に適用されていることを示しています。

第23章 ID 範囲を手動で調整

IdM マスターは、一意のユーザー ID (UID) とグループ ID (GID) 番号を生成します。異なる ID 範囲を作成し、レプリカに割り当てることで、同じ ID 番号が生成されないようにします。デフォルトでは、このプロセスは自動的に実行されます。ただし、IdM マスターのインストール時に IdM ID 範囲を手動で調整したり、レプリカの DNA ID 範囲を手動で定義したりできます。

23.1. ID 範囲

ID 番号は ID 範囲 に分割されます。個別のサーバーとレプリカに別々の数値範囲を維持すると、エントリーに対して発行された ID 番号が別のサーバーまたはレプリカの別のエントリーで既に使用されている可能性がなくなります。

ID 範囲には、以下の 2 つのタイプがあります。

  • IdM マスターのインストール時に割り当てられる IdM ID 範囲。この範囲は作成後に変更することはできません。ただし、必要な場合は、元の IdM ID 範囲に加えて、新しい IdM ID 範囲も作成できます。詳細は、「自動 ID 範囲の割り当て」および「新しい IdM ID 範囲の追加」を参照してください。
  • ユーザーが変更できるDNA (Distributed Numeric Assignment) の ID 範囲。既存の IdM ID範囲内に収まるようにする必要があります。詳細は「DNA ID の範囲の手動調整」を参照してください。

    レプリカには、次の DNA ID 範囲を割り当てることもできます。レプリカは、現在の範囲内で ID の不足時に次の範囲を使用します。次の範囲は、レプリカが削除されると 自動的に割り当て られます。または、手動で設定 することもできます。

範囲は、ドメインのバックエンド 389 Directory Server インスタンスの一部として、DNA プラグインによってマスターとレプリカとの間で更新され、共有されます。

DNA の範囲定義は、サーバーで次に利用可能な番号 (DNA 範囲で一番小さい番号) と最大値 (DNA 範囲で一番大きい番号) の属性で設定されます。初期の下限範囲は、プラグインインスタンスの構成時に設定されます。その後、プラグインは下限値を更新します。利用可能な数を範囲に分割すると、サーバーは、互いに重複せずに、継続的に数字を割り当てることができます。

23.2. 自動 ID 範囲の割り当て

デフォルトでは、IdM マスターのインストール時に IdM ID 範囲が自動的に割り当てられます。Ipa-server-install 合計 10,000 の可能な範囲から 200,000 個の ID の範囲を無作為に選択して割り当てます。このようにランダムな範囲を選択すると、将来的に異なる 2 つの IdM ドメインを結合した場合に備えて ID が競合する可能性が大幅に削減します。

注記

この IdM ID 範囲は、作成後は修正できません。DNA (Distributed Numeric Assignment) の ID 範囲を手動で調整できるのは、「DNA ID の範囲の調整」で説明されているコマンドだけです。インストール時に、IdM ID 範囲に一致する DNA 範囲が自動的に作成されます。

1 つの IdM サーバーをインストールしている場合は、DNA ID 範囲全体を制御します。新規レプリカをインストールし、レプリカが独自の DNA ID 範囲を要求すると、マスターの初期 ID 範囲が分割され、マスターとレプリカの間で分散されます。レプリカは、初期マスターで残った使用可能な DNA ID 範囲のうち半分を受け取ります。次に、マスターとレプリカは、新規ユーザーまたはグループのエントリーに元の ID 範囲に対応する部分を使用します。また、レプリカが割り当てられた ID 範囲を使い果たしそうになり、ID が100 未満しか残っていない場合、レプリカは他の使用可能なサーバーに接続して、新しい DNA ID 範囲を要求します。

重要

レプリカをインストールしても、即座に ID 範囲を受け取ることはありません。レプリカは、DNA プラグインの初回使用時 (ユーザーの初回追加時など) に ID 範囲を受け取ります。この後、レプリカには ID 範囲が定義されていません。

レプリカが DNA ID 範囲を要求する前に最初のマスターが機能しなくなると、レプリカはマスターに連絡して ID 範囲を要求することができません。レプリカに新しいユーザーを追加しようとすると失敗します。このような場合は、無効にされたマスターに割り当てられている ID 範囲を確認 し、ID 範囲を手動でレプリカに割り当て ることができます。

23.3. サーバーのインストール中に IdM ID 範囲を手動で割り当てる

デフォルトの動作を上書きし、無作為に割り当てる代わりに、IdM ID 範囲を手動で設定できます。

重要

UID の値が 1000 以下の ID 範囲は設定しないでください。この値はシステム使用のために予約されています。また、0 値が含まれる ID 範囲は設定しないでください。SSSD サービスは ID の値 0 を処理しません。

手順

  • ipa-server-install では以下のオプションを使用することで、サーバーのインストール時に IdM ID 範囲を手動で定義できます。

    • --idstart は、UID および GID 番号の最初の値を提供します。
    • --idmax は、UID および GID 番号の最大値を提供します。デフォルトでは、この値は --idstart の最初の値に 199,999 を加えたものになります。

検証手順

  • ID 範囲が正しく割り当てられているかを確認するには、ipa idrange-find コマンドを使用して、割り当てられた IdM ID 範囲を表示します。

    # ipa idrange-find
    ---------------
    1 range matched
    ---------------
      Range name: IDM.EXAMPLE.COM_id_range
      First Posix ID of the range: 882200000
      Number of IDs in the range: 200000
      Range type: local domain range
    ----------------------------
    Number of entries returned 1
    ----------------------------

23.4. 新しい IdM ID 範囲の追加

場合によっては、元の IdM 範囲に加え、新しい IdM ID 範囲の作成が必要になる場合があります。たとえば、レプリカの ID が不足し、元の IdM ID 範囲を使い果たした場合などです。

重要

新しい IdM ID 範囲を追加しても、新しい DNA ID 範囲は自動的に作成されません。必要に応じて、新しい DNA ID 範囲を手動で割り当てる必要があります。方法は「DNA ID の範囲の手動調整」を参照してください。

手順

  • 新しい IdM ID 範囲を作成するには、ipa idrange-add コマンドを使用します。新しい範囲名、範囲の最初の ID 番号、および範囲サイズを指定する必要があります。
# ipa idrange-add IDM.EXAMPLE.COM_new_range --base-id=1000000 --range-size=200000
------------------------------------------
Added ID range "IDM.EXAMPLE.COM_new_range"
------------------------------------------
  Range name: IDM.EXAMPLE.COM_new_range
  First Posix ID of the range: 1000000
  Number of IDs in the range: 200000
  Range type: local domain range

検証手順

  • ipa idrange-find コマンドを使用すると、新しい範囲が正しく設定されているかどうかを確認できます。
# ipa idrange-find
----------------
2 ranges matched
----------------
  Range name: IDM.EXAMPLE.COM_id_range
  First Posix ID of the range: 882200000
  Number of IDs in the range: 200000
  Range type: local domain range

  Range name: IDM.EXAMPLE.COM_new_range
  First Posix ID of the range: 1000000
  Number of IDs in the range: 200000
  Range type: local domain range
----------------------------
Number of entries returned 2
----------------------------

23.5. 現在割り当てられている DNA ID 範囲の表示

サーバーで現在アクティブな DNA (Distributed Numeric Assignment) の ID 範囲と、割り当てられている次の DNA 範囲の両方を表示できます。

手順

  • トポロジー内のサーバーに設定されている DNA ID 範囲を表示するには、以下のコマンドを使用します。

    • ipa-replica-manage dnarange-show は、全サーバー (サーバーを指定した場合は指定されたサーバーでのみ) に設定されている現在の DNA ID 範囲を表示します。以下に例を示します。

      # ipa-replica-manage dnarange-show
      masterA.example.com: 1001-1500
      masterB.example.com: 1501-2000
      masterC.example.com: No range set
      
      # ipa-replica-manage dnarange-show masterA.example.com
      masterA.example.com: 1001-1500
    • ipa-replica-manage dnanextrange-show は、全サーバーに現在設定されている次の DNA ID 範囲を表示します。サーバーを指定した場合は、指定されたサーバー上でのみ表示されます。以下に例を示します。

      # ipa-replica-manage dnanextrange-show
      masterA.example.com: 2001-2500
      masterB.example.com: No on-deck range set
      masterC.example.com: No on-deck range set
      
      # ipa-replica-manage dnanextrange-show masterA.example.com
      masterA.example.com: 2001-2500

23.6. 自動 DNA ID 範囲拡張

機能しているレプリカを削除すると、ipa-replica-manage del コマンドは、そのレプリカに割り当てられた DNA ID 範囲を取得して、次の範囲として利用可能な別の IdM レプリカに追加します。これにより、DNA ID 範囲を効率的に使用できます。

レプリカを削除したら、「現在割り当てられている DNA ID 範囲の表示」で説明されているコマンドを使用して、他のサーバーに設定されている DNA ID 範囲を確認できます。

23.7. 手動 DNA ID 範囲の調整

特定の状況では、DNA (Distributed Numeric Assignment) の ID 範囲を手動で調整する必要があります。たとえば、以下のような場合です。

  • レプリカの ID が不足し、IdM ID 範囲がすべて使われている。

    レプリカに割り当てられた DNA ID 範囲を使い果たし、IdM 範囲で使用可能な空き ID がなくなったため、追加の ID の要求が失敗しました。

    この状況を解決するには、レプリカに割り当てられた DNA ID 範囲を拡張します。これは、以下の 2 つの方法で実行できます。

    • 別のレプリカに割り当てられる DNA ID 範囲を短くし、新たに利用可能な値を失効したレプリカに割り当てます。
    • 新しい IdM ID 範囲を作成し、作成した IdM 範囲内でレプリカに新しい DNA ID 範囲を設定します。

      新しい IdM ID 範囲を作成する方法は「新しい IdM ID 範囲の追加」を参照してください。

  • レプリカが機能しなくなった

    レプリカが停止して削除する必要がある場合、レプリカの DNA ID 範囲は自動的に取得されません。つまり、以前にレプリカに割り当てられていた DNA ID 範囲は使用できなくなります。DNA ID 範囲を復元し、他のレプリカで使用できるようにします。

    機能しなくなったレプリカに属する DNA ID 範囲を回復させ、別のサーバーに割り当てたい場合は、最初にID 範囲の値 を確認してから、その範囲を別のサーバーに手動で割り当てる必要があります。また、UID や GID が重複しないように、回復した範囲からの ID の値がユーザーまたはグループに割り当てられていないことを確認します。これは、既存のユーザーおよびグループの UID と GID を調べて実行できます。

「DNA ID 範囲を手動で調整」 のコマンドを使用して、レプリカの DNA ID 範囲を手動で調整できます。

注記

新しい DNA ID 範囲を割り当てると、サーバーまたはレプリカ上の既存のエントリーの UID は同じになります。現在の DNA ID 範囲を変更しても、IdM は過去に割り当てられた範囲の記録を保持するため、これにより問題が発生することはありません。

23.8. DNA ID 範囲を手動で調整

場合によっては、機能していないレプリカに割り当てられた DNA ID 範囲を再割り当てするなど、既存レプリカの DNA (Distributed Numeric Assignment) の ID 範囲を手動で調整しないといけない場合があります。詳細は「手動 DNA ID 範囲の調整」を参照してください。

DNA ID 範囲を手動で調整する場合は、新たに調整した範囲が IdM ID 範囲に含まれていることを確認してください。これは、ipa idrange-find コマンドを使用して確認できます。そうしないと、コマンドは失敗します。

重要

ID 範囲を重複しないように注意してください。サーバーまたはレプリカに割り当てた ID 範囲のいずれかが重複すると、2 つのサーバーが同じ ID 値を異なるエントリーに割り当てる可能性があります。

前提条件

手順

  • 指定のサーバーの現在の DNA ID 範囲を定義するには、ipa-replica-manage dnarange-set を使用します。

    # ipa-replica-manage dnarange-set masterA.example.com 1250-1499
  • 指定のサーバーの次の DNA ID 範囲を定義するには、ipa-replica-manage dnanextrange-set を使用します。

    # ipa-replica-manage dnanextrange-set masterB.example.com 1500-5000

検証手順

第24章 ユーザーの外部プロビジョニングのための IdM の設定

システム管理者は、Identity Management (IdM) が、ID 管理用の外部ソリューションでユーザーのプロビジョニングをサポートするように設定できます。

ipa ユーティリティーを使用する代わりに、外部プロビジョニングシステムの管理者は ldapmodify ユーティリティーを使用して IdM LDAP にアクセスできます。管理者は、ldapmodify を使用して CLI から、または LDIF ファイル を使用して、個々の stage ユーザーを追加できます。

IdM 管理者として、外部プロビジョニングシステムを完全に信頼して、検証済みのユーザーのみを追加することを前提とします。ただし、同時に、外部プロビジョニングシステムの管理者を User Administrator の IdM ロールに割り当てて、新しいアクティブユーザーを直接追加する必要はありません。

外部プロビジョニングシステムで作成されたステージユーザーを自動的にアクティブユーザーに移動するように スクリプトを設定 できます。

本章では、以下の項を説明します。

  1. Identity Management(IdM)を準備 して、外部プロビジョニングシステムを使用して stage ユーザーを IdM に追加します。
  2. 外部プロビジョニングシステムが追加したユーザーをステージユーザーからアクティブユーザーに移動する スクリプトを作成 します。
  3. 外部プロビジョニングシステムを使用して IdM stage ユーザーを追加します。これには 2 つの方法があります。

その他の資料

ldapmodify を完全な IdM 管理者 として使用し、より高い権限を必要とするユーザーおよびグループの管理操作を実行する例とテンプレートは、「ldapmodify の使用」を参照してください。

24.1. stage ユーザーアカウントの自動アクティベーションに向けた IdM アカウントの準備

この手順では、外部プロビジョニングシステムが使用する 2 つの IdM ユーザーアカウントを設定する方法を説明します。適切なパスワードポリシーが指定されたグループにアカウントを追加すると、外部プロビジョニングシステムが IdM でユーザーのプロビジョニングを管理できるようになります。stage ユーザーを追加するために外部システムが使用するユーザーアカウントには provisionator という名前が付けられます。stage ユーザーを自動的にアクティベートするために使用されるユーザーアカウントは activator という名前です。

前提条件

  • 手順を実行するホストが IdM に登録されます。

手順

  1. IdM 管理者としてログインします。

    $ kinit admin
  2. stage ユーザーを追加する権限を持つ provisionator という名前のユーザーを作成します。

    1. provisionator ユーザーアカウントを追加します。
    $ ipa user-add provisionator --first=provisioning --last=account --password
    1. provisionator ユーザーに必要な権限を割り当てます。

      1. stage ユーザーの追加を管理する System Provisioning というカスタムロールを作成します。

        $ ipa role-add --desc "Responsible for provisioning stage users" "System Provisioning"
      2. Stage User Provisioning の権限をロールに追加します。この権限により、stage ユーザーを追加することができます。

        $ ipa role-add-privilege "System Provisioning" --privileges="Stage User Provisioning"
      3. provisionator ユーザーをロールに追加します。

        $ ipa role-add-member --users=provisionator "System Provisioning"
      4. provisionator が IdM に存在することを確認します。
      $ ipa user-find provisionator --all --raw
      --------------
      1 user matched
      --------------
        dn: uid=provisionator,cn=users,cn=accounts,dc=idm,dc=example,dc=com
        uid: provisionator
        [...]
  3. ユーザーアカウントを管理する権限を持つ activator ユーザーを作成します。

    1. activator ユーザーアカウントを追加します。

      $ ipa user-add activator --first=activation --last=account --password
    2. デフォルトの User Administrator ロールにユーザーを追加して、activator ユーザーに必要な権限を付与します。

      $ ipa role-add-member --users=activator "User Administrator"
  4. アプリケーションアカウントのユーザーグループを作成します。

    $ ipa group-add application-accounts
  5. グループのパスワードポリシーを更新します。以下のポリシーは、アカウントのパスワードの有効期限やロックアウトを防ぎますが、複雑なパスワードを必要とすることでリスクの可能性を低減します。

    $ ipa pwpolicy-add application-accounts --maxlife=10000 --minlife=0 --history=0 --minclasses=4 --minlength=8 --priority=1 --maxfail=0 --failinterval=1 --lockouttime=0
  6. (必要に応じて) パスワードポリシーが IdM に存在することを確認します。

    $ ipa pwpolicy-show application-accounts
      Group: application-accounts
      Max lifetime (days): 10000
      Min lifetime (hours): 0
      History size: 0
    [...]
  7. アプリケーションアカウントのグループにプロビジョニングアカウントおよびアクティベーションアカウントを追加します。

    $ ipa group-add-member application-accounts --users={provisionator,activator}
  8. ユーザーアカウントのパスワードを変更します。

    $ kpasswd provisionator
    $ kpasswd activator

    新しい IdM ユーザーのパスワードはすぐに失効するため、パスワードの変更が必要になります。

関連情報

24.2. IdM stage ユーザーアカウントの自動アクティベーションの設定

この手順では、stage ユーザーをアクティベートするスクリプトを作成する方法を説明します。システムは、指定した間隔でスクリプトを自動的に実行します。これにより、新規ユーザーアカウントが自動的にアクティベートされ、作成直後に使用することができます。

重要

この手順では、外部プロビジョニングシステムの所有者がユーザーをすでに検証し、スクリプトが IdM に追加する前に IdM 側で追加の検証を必要としていないことを前提としています。

IdM サーバーの 1 つでのみアクティベーションプロセスを有効にするだけで 十 分です。

前提条件

手順

  1. アカウントのアクティベーション用に keytab ファイルを生成します。

    # ipa-getkeytab -s server.idm.example.com -p "activator" -k /etc/krb5.ipa-activation.keytab

    複数の IdM サーバーでアクティベーションプロセスを有効にする場合は、1 つのサーバーで keytab ファイルのみを生成します。次に、キータブファイルを他のサーバーにコピーします。

  2. 以下の内容を含む /usr/local/sbin/ipa-activate-all スクリプトを作成して全ユーザーをアクティベートします。

    #!/bin/bash
    
    kinit -k -i activator
    
    ipa stageuser-find --all --raw | grep "  uid:" | cut -d ":" -f 2 | while read uid; do ipa stageuser-activate ${uid}; done
  3. ipa-activate-all スクリプトのパーミッションおよび所有権を編集して、実行可能なファイルに変更します。

    # chmod 755 /usr/local/sbin/ipa-activate-all
    # chown root:root /usr/local/sbin/ipa-activate-all
  4. systemd ユニットファイル /etc/systemd/system/ipa-activate-all.service を作成して、以下の内容を追加します。

    [Unit]
    Description=Scan IdM every minute for any stage users that must be activated
    
    [Service]
    Environment=KRB5_CLIENT_KTNAME=/etc/krb5.ipa-activation.keytab
    Environment=KRB5CCNAME=FILE:/tmp/krb5cc_ipa-activate-all
    ExecStart=/usr/local/sbin/ipa-activate-all
  5. systemd タイマー /etc/systemd/system/ipa-activate-all.timer を作成して、以下の内容を追加します。

    [Unit]
    Description=Scan IdM every minute for any stage users that must be activated
    
    [Timer]
    OnBootSec=15min
    OnUnitActiveSec=1min
    
    [Install]
    WantedBy=multi-user.target
  6. 新しい設定を再読み込みします。

    # systemctl daemon-reload
  7. ipa-activate-all.timer を有効にします。

    # systemctl enable ipa-activate-all.timer
  8. ipa-activate-all.timer を起動します。

    # systemctl start ipa-activate-all.timer
  9. (必要に応じて) ipa-activate-all.timer デーモンが実行していることを確認します。

    # systemctl status ipa-activate-all.timer
    ● ipa-activate-all.timer - Scan IdM every minute for any stage users that must be activated
       Loaded: loaded (/etc/systemd/system/ipa-activate-all.timer; enabled; vendor preset: disabled)
       Active: active (waiting) since Wed 2020-06-10 16:34:55 CEST; 15s ago
      Trigger: Wed 2020-06-10 16:35:55 CEST; 44s left
    
    Jun 10 16:34:55 server.idm.example.com systemd[1]: Started Scan IdM every minute for any stage users that must be activated.

24.3. LDIF ファイルで定義されている IdM stage ユーザーの追加

本セクションでは、外部プロビジョニングシステムの管理者が IdM LDAP にアクセスし、LDIF ファイルを使用して stage ユーザーを追加する方法を説明します。以下の例では、1 人のユーザーの追加を示していますが、複数のユーザーが一括モードで 1 つのファイルに追加できます。

前提条件

  • IdM 管理者が、provisionator アカウントとパスワードを作成している。詳細は「ステージユーザーアカウントの自動アクティベーション用の IdM アカウントの準備」を参照してください。
  • 外部管理者は provisionator アカウントのパスワードを知っている。
  • LDAP サーバーから IdM サーバーに SSH 接続できる。
  • IdM stage ユーザーがユーザーライフサイクルの正しい処理を許可する必要がある属性の最小セットを提供できます。つまり、以下のようになります。

    • 識別名 (dn)
    • 共通名 (cn)
    • 名字 (sn)
    • uid

手順

  1. 外部サーバーで、新規ユーザーに関する情報が含まれる LDIF ファイルを作成します。

    dn: uid=stageidmuser,cn=staged users,cn=accounts,cn=provisioning,dc=idm,dc=example,dc=com
    changetype: add
    objectClass: top
    objectClass: inetorgperson
    uid: stageidmuser
    sn: surname
    givenName: first_name
    cn: full_name
  2. 外部サーバーから IdM サーバーへの LDIF ファイルを転送します。

    $ scp add-stageidmuser.ldif provisionator@server.idm.example.com:/provisionator/
    Password:
    add-stageidmuser.ldif                                                                                          100%  364   217.6KB/s   00:00
  3. SSH プロトコルを使用して、provisionator として IdM サーバーに接続します。

    $ ssh provisionator@server.idm.example.com
    Password:
    [provisionator@server ~]$
  4. IdM サーバーで、provisionator アカウントの Kerberos チケット保証チケット (TGT) を取得します。

    [provisionator@server ~]$ kinit provisionator
  5. -f オプションと LDIF ファイルの名前を指定して ldapadd コマンドを入力します。IdM サーバー名とポート番号を指定します。

    ~]$ ldapadd -h server.idm.example.com -p 389 -f  add-stageidmuser.ldif
    SASL/GSSAPI authentication started
    SASL username: provisionator@IDM.EXAMPLE.COM
    SASL SSF: 256
    SASL data security layer installed.
    adding the entry "uid=stageidmuser,cn=staged users,cn=accounts,cn=provisioning,dc=idm,dc=example,dc=com"

24.4. ldapmodify を使用して CLI から IdM stage ユーザーを直接追加

本セクションでは、外部プロビジョニングシステムの管理者が Identity Management (IdM) LDAP にアクセスし、ldapmodify ユーティリティーを使用して stage ユーザーを追加する方法を説明します。

前提条件

  • IdM 管理者が、provisionator アカウントおよびパスワードを作成している。詳細は「ステージユーザーアカウントの自動アクティベーション用の IdM アカウントの準備」を参照してください。
  • 外部管理者は provisionator アカウントのパスワードを知っている。
  • LDAP サーバーから IdM サーバーに SSH 接続できる。
  • IdM stage ユーザーがユーザーライフサイクルの正しい処理を許可する必要がある属性の最小セットを提供できます。つまり、以下のようになります。

    • 識別名 (dn)
    • 共通名 (cn)
    • 名字 (sn)
    • uid

手順

  1. IdM の ID および認証情報を使用して、SSH プロトコルを使用して IdM サーバーに接続します。

    $ ssh provisionator@server.idm.example.com
    Password:
    [provisionator@server ~]$
  2. 新規 stage ユーザーを追加するロールを持つ IdM ユーザーである provisionator アカウントの TGT を取得します。

    $ kinit provisionator
  3. ldapmodify コマンドを入力し、Generic Security Services API (GSSAPI) を認証に使用する Simple Authentication and Security Layer (SASL) メカニズムとして指定します。IdM サーバーとポート名を指定します。

    # ldapmodify -h server.idm.example.com -p 389 -Y GSSAPI
    SASL/GSSAPI authentication started
    SASL username: provisionator@IDM.EXAMPLE.COM
    SASL SSF: 56
    SASL data security layer installed.
  4. 追加するユーザーの dn を入力します。

    dn: uid=stageuser,cn=staged users,cn=accounts,cn=provisioning,dc=idm,dc=example,dc=com
  5. 実行している変更のタイプとして add を入力します。

    changetype: add
  6. ユーザーのライフサイクルの正しい処理を許可するのに必要な LDAP オブジェクトクラスのカテゴリーを指定します。

    objectClass: top
    objectClass: inetorgperson

    追加のオブジェクトクラスを指定できます。

  7. ユーザーの uid を入力します。

    uid: stageuser
  8. ユーザーの cn を入力します。

    cn: Babs Jensen
  9. ユーザーの名字を入力します。

    sn: Jensen
  10. Enter を再度押して、これがエントリーの最後であることを確認します。

    [Enter]
    
    adding new entry "uid=stageuser,cn=staged users,cn=accounts,cn=provisioning,dc=idm,dc=example,dc=com"
  11. Ctrl + C を使用して接続を終了します。

検証手順

stage エントリーの内容を確認し、必要な POSIX 属性をプロビジョニングシステムがすべて追加し、ステージエントリーをアクティベートする準備ができていることを確認します。

  • 新規 stage ユーザーの LDAP 属性を表示するには、ipa stageuser-show --all --raw コマンドを実行します。

    $ ipa stageuser-show stageuser --all --raw
      dn: uid=stageuser,cn=staged users,cn=accounts,cn=provisioning,dc=idm,dc=example,dc=com
      uid: stageuser
      sn: Jensen
      cn: Babs Jensen
      has_password: FALSE
      has_keytab: FALSE
      nsaccountlock: TRUE
      objectClass: top
      objectClass: inetorgperson
      objectClass: organizationalPerson
      objectClass: person
    1. ユーザーは、nsaccountlock 属性により明示的に無効になっていることに注意してください。

第25章 ldapmodify を使用した IdM ユーザーを外部で管理

ldapmodify ユーティリティーおよび ldapdelete ユーティリティーを使用して、コマンドラインインターフェース (CLI) から Identity Management (IdM) LDAP を直接変更できます。このユーティリティーは、ディレクトリー内容の追加、編集、および削除に完全機能を提供します。これらのユーティリティーを使用して、サーバーの設定エントリーとユーザーエントリーのデータの両方を管理できます。このユーティリティーは、1 つまたは複数のディレクトリーを一括管理するためにスクリプトを作成するのに使用することもできます。

25.1. IdM ユーザーアカウントを外部で管理するためのテンプレート

本セクションでは、IdM におけるさまざまなユーザー管理操作のテンプレートを説明します。テンプレートには、以下のゴールを達成するために ldapmodify を使用して変更する必要のある属性が表示されます。

  • 新規 stage ユーザーの追加
  • ユーザーの属性の変更
  • ユーザーの有効化
  • ユーザーの無効化
  • ユーザーの保存

テンプレートは LDAP データ交換形式(LDIF)でフォーマットされます。LDIF は、LDAP ディレクトリーのコンテンツおよび更新リクエストを表す標準的なプレーンテキストデータ交換形式です。

テンプレートを使用して、プロビジョニングシステムの LDAP プロバイダーを設定して、IdM ユーザーアカウントを管理できます。

詳細な手順例は、以下のセクションを参照してください。

新規 stage ユーザーを追加するためのテンプレート

  • UID および GID が自動的に割り当てられた ユーザーを追加するためのテンプレート。作成したエントリーの識別名 (DN) は uid=user_login で開始する必要があります。

    dn: uid=user_login,cn=staged users,cn=accounts,cn=provisioning,dc=idm,dc=example,dc=com
    changetype: add
    objectClass: top
    objectClass: inetorgperson
    uid: user_login
    sn: surname
    givenName: first_name
    cn: full_name
  • UID と GID が静的に割り当てられている ユーザーを追加するためのテンプレート

    dn: uid=user_login,cn=staged users,cn=accounts,cn=provisioning,dc=idm,dc=example,dc=com
    changetype: add
    objectClass: top
    objectClass: person
    objectClass: inetorgperson
    objectClass: organizationalperson
    objectClass: posixaccount
    uid: user_login
    uidNumber: UID_number
    gidNumber: GID_number
    sn: surname
    givenName: first_name
    cn: full_name
    homeDirectory: /home/user_login

    stage ユーザーの追加時に IdM オブジェクトクラスを指定する必要はありません。IdM は、ユーザーのアクティベート後にこれらのクラスを自動的に追加します。

既存ユーザーを変更するためのテンプレート

  • ユーザーの属性の変更

    dn: distinguished_name
    changetype: modify
    replace: attribute_to_modify
    attribute_to_modify: new_value
  • ユーザーの無効化

    dn: distinguished_name
    changetype: modify
    replace: nsAccountLock
    nsAccountLock: TRUE
  • ユーザーの有効化

    dn: distinguished_name
    changetype: modify
    replace: nsAccountLock
    nsAccountLock: FALSE

    nssAccountLock 属性の更新は、stage ユーザーおよび保存済みユーザーには影響を与えません。更新操作が正常に完了しても、属性値は nssAccountLock: TRUE のままになります。

  • ユーザーの保持

    dn: distinguished_name
    changetype: modrdn
    newrdn: uid=user_login
    deleteoldrdn: 0
    newsuperior: cn=deleted users,cn=accounts,cn=provisioning,dc=idm,dc=example,dc=com
注記

ユーザーを変更する前に、ユーザーのログインを検索してユーザーの識別名 (DN) を取得します。以下の例では、user_allowed_to_modify_user_entries ユーザーは、activator または IdM 管理者など、ユーザーおよびグループの情報の変更を許可されたユーザーです。この例のパスワードは、このユーザーのパスワードです。

[...]
# ldapsearch -LLL -x -D "uid=user_allowed_to_modify_user_entries,cn=users,cn=accounts,dc=idm,dc=example,dc=com" -w "Secret123" -H ldap://r8server.idm.example.com -b "cn=users,cn=accounts,dc=idm,dc=example,dc=com" uid=test_user
dn: uid=test_user,cn=users,cn=accounts,dc=idm,dc=example,dc=com
memberOf: cn=ipausers,cn=groups,cn=accounts,dc=idm,dc=example,dc=com

25.2. IdM グループアカウントを外部で管理するためのテンプレート

本セクションでは、IdM におけるさまざまなユーザーグループ管理操作のテンプレートを説明します。テンプレートには、以下の目的を達成するために ldapmodify を使用して変更する必要のある属性が表示されます。

  • 新規グループの作成
  • 既存グループの削除
  • グループへのメンバーの追加
  • グループからメンバーの削除

テンプレートは LDAP データ交換形式(LDIF)でフォーマットされます。LDIF は、LDAP ディレクトリーのコンテンツおよび更新リクエストを表す標準的なプレーンテキストデータ交換形式です。

テンプレートを使用して、プロビジョニングシステムの LDAP プロバイダーを設定して、IdM グループアカウントを管理できます。

新規グループの作成

dn: cn=group_name,cn=groups,cn=accounts,dc=idm,dc=example,dc=com
changetype: add
objectClass: top
objectClass: ipaobject
objectClass: ipausergroup
objectClass: groupofnames
objectClass: nestedgroup
objectClass: posixgroup
uid: group_name
cn: group_name
gidNumber: GID_number

グループの変更

  • 既存グループの削除

    dn: group_distinguished_name
    changetype: delete
  • グループへのメンバーの追加

    dn: group_distinguished_name
    changetype: modify
    add: member
    member: uid=user_login,cn=users,cn=accounts,dc=idm,dc=example,dc=com

    stage または保存済みユーザーをグループに追加しないでください。更新操作が正常に完了しても、ユーザーはグループのメンバーとして更新されません。アクティブユーザーのみがグループに所属できます。

  • グループからメンバーの削除

    dn: distinguished_name
    changetype: modify
    delete: member
    member: uid=user_login,cn=users,cn=accounts,dc=idm,dc=example,dc=com
注記

グループを変更する前に、グループ名を使用して検索してグループの識別名 (DN) を取得します。

# ldapsearch -YGSSAPI -H ldap://server.idm.example.com -b "cn=groups,cn=accounts,dc=idm,dc=example,dc=com" "cn=group_name"
dn: cn=group_name,cn=groups,cn=accounts,dc=idm,dc=example,dc=com
ipaNTSecurityIdentifier: S-1-5-21-1650388524-2605035987-2578146103-11017
cn: testgroup
objectClass: top
objectClass: groupofnames
objectClass: nestedgroup
objectClass: ipausergroup
objectClass: ipaobject
objectClass: posixgroup
objectClass: ipantgroupattrs
ipaUniqueID: 569bf864-9d45-11ea-bea3-525400f6f085
gidNumber: 1997010017

25.3. ldapmodify での IdM ユーザーの保存

本セクションでは、ldapmodify を使用して IdM ユーザーを保存する方法を説明します。つまり、従業員が退職した後にユーザーアカウントを非アクティブ化する方法を説明します。

前提条件

  • ロールで IdM ユーザーとして認証を行い、ユーザーを保持できます。

手順

  1. ユーザーを保存するロールを持つ IdM ユーザーとしてログインします。

    $ kinit admin
  2. ldapmodify コマンドを入力し、Generic Security Services API (GSSAPI) を認証に使用する Simple Authentication and Security Layer (SASL) メカニズムとして指定します。

    # ldapmodify -Y GSSAPI
    SASL/GSSAPI authentication started
    SASL username: admin@IDM.EXAMPLE.COM
    SASL SSF: 256
    SASL data security layer installed.
  3. 保存するユーザーの dn を入力します。

    dn: uid=user1,cn=users,cn=accounts,dc=idm,dc=example,dc=com
  4. 実行する変更のタイプとして modrdn を入力します。

    changetype: modrdn
  5. ユーザーの newrdn を指定します。

    newrdn: uid=user1
  6. ユーザーを保存することを示します。

    deleteoldrdn: 0
  7. 新しい上位 DN を指定します。

    newsuperior: cn=deleted users,cn=accounts,cn=provisioning,dc=idm,dc=example,dc=com

    ユーザーを保存すると、そのエントリーをディレクトリー情報ツリー (DIT) 内の新しい場所に移動します。このため、新しい親エントリーの DN を新しい上位 DN として指定する必要があります。

  8. Enter を再度押して、これがエントリーの最後であることを確認します。

    [Enter]
    
    modifying rdn of entry "uid=user1,cn=users,cn=accounts,dc=idm,dc=example,dc=com"
  9. Ctrl + C を使用して接続を終了します。

検証手順

  • 保存済みユーザーを一覧表示して、ユーザーが保持されていることを確認します。

    $ ipa user-find --preserved=true
    --------------
    1 user matched
    --------------
      User login: user1
      First name: First 1
      Last name: Last 1
      Home directory: /home/user1
      Login shell: /bin/sh
      Principal name: user1@IDM.EXAMPLE.COM
      Principal alias: user1@IDM.EXAMPLE.COM
      Email address: user1@idm.example.com
      UID: 1997010003
      GID: 1997010003
      Account disabled: True
      Preserved user: True
    ----------------------------
    Number of entries returned 1
    ----------------------------

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

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

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

26.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 プリンシパルが格納されます。

26.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 レコードも追加します。コマンドはクライアントで実行する必要があります。

26.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 サーバーはそのリクエストに応答できます。

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

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

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

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

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

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

    登録前

    $ ipa stageuser-add user_name [--password]

    $ ipa host-add host_name [--random]

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

    $ ipa stageuser-activate user_name

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

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

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

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

     ユーザーホスト

    認証のデフォルト手段

    パスワード

    キータブ

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

    $ kinit user_name

    [ホストへの切り替え]

    認証成功の結果

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

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

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

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

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

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

26.3. ホスト操作

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

表26.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

表26.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>) を無効にする必要があります。

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

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

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

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

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

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

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

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

表26.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 エントリーを動的に更新できるかどうかが設定されます。

26.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 リソースレコードにホストを追加します。

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

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

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

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

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

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

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

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

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

26.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 クライアントシステムの名前変更」を参照してください。

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

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

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

26.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:

関連情報

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

前提条件

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

手順

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

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

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

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

26.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 ~]$

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

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

警告

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

26.9.1. ホストの無効化

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

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

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

以下に例を示します。

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

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

重要

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

26.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 サーバーに認証します。

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

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

27.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 プリンシパルが格納されます。

27.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 レコードも追加します。コマンドはクライアントで実行する必要があります。

27.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 サーバーはそのリクエストに応答できます。

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

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

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

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

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

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

    登録前

    $ ipa stageuser-add user_name [--password]

    $ ipa host-add host_name [--random]

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

    $ ipa stageuser-activate user_name

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

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

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

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

     ユーザーホスト

    認証のデフォルト手段

    パスワード

    キータブ

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

    $ kinit user_name

    [ホストへの切り替え]

    認証成功の結果

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

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

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

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

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

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

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

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

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

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

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

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

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

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

表27.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 エントリーを動的に更新できるかどうかが設定されます。

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

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

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

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

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

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

    host add

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

    注記

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

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

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

    host attr

第28章 Ansible Playbook を使用したホストの管理

Ansible は、システムの設定、ソフトウェアのデプロイ、ローリング更新の実行に使用する自動化ツールです。Ansible には Identity Management (IdM) のサポートが含まれ、Ansible モジュールを使用してホスト管理を自動化できます。

本章では、Ansible Playbook を使用してホストおよびホストエントリーを管理する際に実行される以下の操作について説明します。

28.1. Ansible Playbook を使用した FQDN を使用した IdM ホストエントリーの存在の確認

本セクションでは、Ansible Playbook を使用して、Identity Management (IdM) にホストエントリーが存在することを確認する方法を説明します。ホストエントリーは、完全修飾ドメイン名 (FQDN) によってのみ定義されます。

以下の条件のいずれかが当てはまる場合は、ホストの FQDN 名を指定するだけで十分です。

  • IdM サーバーが DNS を管理するよう設定されていません。
  • ホストには静的 IP アドレスがないか、またはホストの設定時に IP アドレスが不明な状態です。FQDN によってのみ定義されたホストを追加すると、基本的に IdM DNS サービスにプレースホルダーエントリーが作成されます。たとえば、ラップトップは IdM クライアントとして事前設定されている場合がありますが、設定時には IP アドレスがありません。DNS サービスがレコードを動的に更新すると、ホストの現在の IP アドレスが検出され、DNS レコードが更新されます。
注記

Ansible を使用しないと、ipa host-add コマンドを使用してホストエントリーが IdM に作成されます。ホストを IdM に追加する結果は、IdM に存在するホストの状態です。Ansible の復元により、Ansible を使用してホストを IdM に追加するには、ホストの状態を present: state: present として定義する Playbook を作成する必要があります。

前提条件

  • IdM 管理者パスワードが分かっている。
  • ansible-freeipa パッケージが Ansible コントローラーにインストールされている。

手順

  1. inventory.file などのインベントリーファイルを作成し、そのファイルに ipaserver を定義します。

    [ipaserver]
    server.idm.example.com
  2. IdM に存在するホストの FQDN で Ansible Playbook ファイルを作成します。この手順を単純化するには、/usr/share/doc/ansible-freeipa/playbooks/host/add-host.yml ファイルのサンプルをコピーして変更できます。

    ---
    - name: Host present
      hosts: ipaserver
      become: true
    
      tasks:
      - name: Host host01.idm.example.com present
        ipahost:
          ipaadmin_password: Secret123
          name: host01.idm.example.com
          state: present
          force: yes
  3. Playbook を実行します。

    $ ansible-playbook -v -i path_to_inventory_directory/inventory.file path_to_playbooks_directory/ensure-host-is-present.yml
注記

この手順では、IdM LDAP サーバーにホストエントリーを作成しますが、ホストを IdM Kerberos レルムに登録しません。そのためには、ホストを IdM クライアントとしてデプロイする必要があります。詳細は「Ansible Playbook で Identity Management クライアントのインストール」を参照してください。

検証手順

  1. admin として IdM サーバーにログインします。

    $ ssh admin@server.idm.example.com
    Password:
  2. ipa host-show コマンドを入力し、ホストの名前を指定します。

    $ ipa host-show host01.idm.example.com
      Host name: host01.idm.example.com
      Principal name: host/host01.idm.example.com@IDM.EXAMPLE.COM
      Principal alias: host/host01.idm.example.com@IDM.EXAMPLE.COM
      Password: False
      Keytab: False
      Managed by: host01.idm.example.com

この出力では、host01.idm.example.com が IdM に存在することを確認します。

28.2. Ansible Playbook を使用して DNS 情報を含む IdM ホストエントリーが存在することを確認する

本セクションでは、Ansible Playbook を使用して、Identity Management (IdM) にホストエントリーが存在することを確認する方法を説明します。ホストエントリーは、完全修飾ドメイン名 (FQDN) およびそれらの IP アドレスで定義されます。

注記

Ansible を使用しないと、ipa host-add コマンドを使用してホストエントリーが IdM に作成されます。ホストを IdM に追加する結果は、IdM に存在するホストの状態です。Ansible の復元により、Ansible を使用してホストを IdM に追加するには、ホストの状態を present: state: present として定義する Playbook を作成する必要があります。

前提条件

  • IdM 管理者パスワードが分かっている。
  • ansible-freeipa パッケージが Ansible コントローラーにインストールされている。

手順

  1. inventory.file などのインベントリーファイルを作成し、そのファイルに ipaserver を定義します。

    [ipaserver]
    server.idm.example.com
  2. IdM に存在するホストの 完全修飾ドメイン名 (FQDN) で Ansible Playbook ファイルを作成します。また、IdM サーバーが DNS を管理するように設定され、ホストの IP アドレスが分かっている場合は、ip_address パラメーターの値を指定します。ホストが DNS リソースレコードに存在するには、IP アドレスが必要です。この手順を単純化するには、/usr/share/doc/ansible-freeipa/playbooks/host/host-present.yml ファイルのサンプルをコピーして変更できます。また、その他の追加情報を含めることもできます。

    ---
    - name: Host present
      hosts: ipaserver
      become: true
    
      tasks:
      - name: Ensure host01.idm.example.com is present
        ipahost:
          ipaadmin_password: ADMPassword123
          name: host01.idm.example.com
          description: Example host
          ip_address: 192.168.0.123
          locality: Lab
          ns_host_location: Lab
          ns_os_version: CentOS 7
          ns_hardware_platform: Lenovo T61
          mac_address:
          - "08:00:27:E3:B1:2D"
          - "52:54:00:BD:97:1E"
          state: present
  3. Playbook を実行します。

    $ ansible-playbook -v -i path_to_inventory_directory/inventory.file path_to_playbooks_directory/ensure-host-is-present.yml
注記

この手順では、IdM LDAP サーバーにホストエントリーを作成しますが、ホストを IdM Kerberos レルムに登録しません。そのためには、ホストを IdM クライアントとしてデプロイする必要があります。詳細は「Ansible Playbook で Identity Management クライアントのインストール」を参照してください。

検証手順

  1. admin として IdM サーバーにログインします。

    $ ssh admin@server.idm.example.com
    Password:
  2. ipa host-show コマンドを入力し、ホストの名前を指定します。

    $ ipa host-show host01.idm.example.com
      Host name: host01.idm.example.com
      Description: Example host
      Locality: Lab
      Location: Lab
      Platform: Lenovo T61
      Operating system: CentOS 7
      Principal name: host/host01.idm.example.com@IDM.EXAMPLE.COM
      Principal alias: host/host01.idm.example.com@IDM.EXAMPLE.COM
      MAC address: 08:00:27:E3:B1:2D, 52:54:00:BD:97:1E
      Password: False
      Keytab: False
      Managed by: host01.idm.example.com

この出力では、host01.idm.example.com が IdM に存在することを確認します。

28.3. Ansible Playbook を使用して無作為のパスワードで複数の IdM ホストエントリーが存在することを確認する

ipahost モジュールを使用すると、システム管理者は、単一の Ansible タスクのみを使用して、IdM に複数のホストエントリーが存在するか、または存在しないかを確認できます。本セクションでは、完全修飾ドメイン名 (FQDN) によってのみ定義される複数のホストエントリーが存在することを確認する方法を説明します。Ansible Playbook を実行すると、ホストのパスワードが無作為に生成されます。

注記

Ansible を使用しないと、ipa host-add コマンドを使用してホストエントリーが IdM に作成されます。ホストを IdM に追加する結果は、IdM に存在するホストの状態です。Ansible の復元により、Ansible を使用してホストを IdM に追加するには、ホストの状態を present: state: present として定義する Playbook を作成する必要があります。

前提条件

  • IdM 管理者パスワードが分かっている。
  • ansible-freeipa パッケージが Ansible コントローラーにインストールされている。

手順

  1. inventory.file などのインベントリーファイルを作成し、そのファイルに ipaserver を定義します。

    [ipaserver]
    server.idm.example.com
  2. IdM に存在するホストの 完全修飾ドメイン名 (FQDN) で Ansible Playbook ファイルを作成します。Ansible Playbook が IdM にホストがすでに存在し、update_passwordon_create に制限されている場合でも、各ホストの無作為なパスワード を生成するようにするには、random: yes および force: yes オプションを追加します。この手順を簡素化するには、/usr/share/doc/ansible-freeipa/README-host.md Markdown ファイルからサンプルをコピーして変更できます。

    ---
    - name: Ensure hosts with random password
      hosts: ipaserver
      become: true
    
      tasks:
      - name: Hosts host01.idm.example.com and host02.idm.example.com present with random passwords
        ipahost:
          ipaadmin_password: MyPassword123
          hosts:
          - name: host01.idm.example.com
            random: yes
            force: yes
          - name: host02.idm.example.com
            random: yes
            force: yes
        register: ipahost
  3. Playbook を実行します。

    $ ansible-playbook -v -i path_to_inventory_directory/inventory.file path_to_playbooks_directory/ensure-hosts-are-present.yml
    [...]
    TASK [Hosts host01.idm.example.com and host02.idm.example.com present with random passwords]
    changed: [r8server.idm.example.com] => {"changed": true, "host": {"host01.idm.example.com": {"randompassword": "0HoIRvjUdH0Ycbf6uYdWTxH"}, "host02.idm.example.com": {"randompassword": "5VdLgrf3wvojmACdHC3uA3s"}}}
注記

無作為にワンタイムパスワード (OTP) を使用して IdM クライアントとしてホストをデプロイするには、「Ansible Playbook を使用した IdM クライアント登録の認証オプション」または「ワンタイムパスワードを使用したクライアントのインストール: 対話型インストール」を参照してください。

検証手順

  1. admin として IdM サーバーにログインします。

    $ ssh admin@server.idm.example.com
    Password:
  2. ipa host-show コマンドを入力し、ホストのいずれかの名前を指定します。

    $ ipa host-show host01.idm.example.com
      Host name: host01.idm.example.com
      Password: True
      Keytab: False
      Managed by: host01.idm.example.com

この出力では、host01.idm.example.com がランダムパスワードで IdM に存在することを確認します。

28.4. Ansible Playbook を使用して、複数の IP アドレスを持つ IdM ホストエントリーが存在することを確認する

本セクションでは、Ansible Playbook を使用して、Identity Management (IdM) にホストエントリーが存在することを確認する方法を説明します。ホストエントリーは、完全修飾ドメイン名 (FQDN) と複数の IP アドレスで定義されます。

注記

Ansible ipahost モジュールは、ipa host ユーティリティーとは対照的に、ホストの IPv4 および IPv6 アドレスが複数存在するか、または存在しないことを確認します。ipa host-mod コマンドは IP アドレスを処理できません。

前提条件

  • IdM 管理者パスワードが分かっている。
  • ansible-freeipa パッケージが Ansible コントローラーにインストールされている。

手順

  1. inventory.file などのインベントリーファイルを作成し、そのファイルに ipaserver を定義します。

    [ipaserver]
    server.idm.example.com
  2. Ansible Playbook ファイルを作成します。ipahost 変数の 名前 として、確認する IdM に存在するホストの 完全修飾ドメイン名 (FQDN) を指定します。- ip_address 構文を使用して、個別の行に複数の IPv4 および IPv6 ip_address 値を指定します。この手順を単純化するには、/usr/share/doc/ansible-freeipa/playbooks/host/host-member-ipaddresses-present.yml ファイルのサンプルをコピーして変更できます。追加情報を含めることもできます。

    ---
    - name: Host member IP addresses present
      hosts: ipaserver
      become: true
    
      tasks:
      - name: Ensure host101.example.com IP addresses present
        ipahost:
          ipaadmin_password: Secret123
          name: host01.idm.example.com
          ip_address:
          - 192.168.0.123
          - fe80::20c:29ff:fe02:a1b3
          - 192.168.0.124
          - fe80::20c:29ff:fe02:a1b4
          force: yes
  3. Playbook を実行します。

    $ ansible-playbook -v -i path_to_inventory_directory/inventory.file path_to_playbooks_directory/ensure-host-with-multiple-IP-addreses-is-present.yml
注記

この手順では、IdM LDAP サーバーにホストエントリーを作成しますが、ホストを IdM Kerberos レルムに登録しません。そのためには、ホストを IdM クライアントとしてデプロイする必要があります。詳細は「Ansible Playbook で Identity Management クライアントのインストール」を参照してください。

検証手順

  1. admin として IdM サーバーにログインします。

    $ ssh admin@server.idm.example.com
    Password:
  2. ipa host-show コマンドを入力し、ホストの名前を指定します。

    $ ipa host-show host01.idm.example.com
      Principal name: host/host01.idm.example.com@IDM.EXAMPLE.COM
      Principal alias: host/host01.idm.example.com@IDM.EXAMPLE.COM
      Password: False
      Keytab: False
      Managed by: host01.idm.example.com

    この出力では、host01.idm.example.com が IdM に存在することを確認します。

  3. IdM DNS レコードにホストの複数の IP アドレスが存在することを確認するには、ipa dnsrecord-show コマンドを入力し、以下の情報を指定します。

    • IdM ドメインの名前
    • ホストの名前

      $ ipa dnsrecord-show idm.example.com host01
      [...]
        Record name: host01
        A record: 192.168.0.123, 192.168.0.124
        AAAA record: fe80::20c:29ff:fe02:a1b3, fe80::20c:29ff:fe02:a1b4

    この出力では、Playbook で指定された IPv4 アドレスおよび IPv6 アドレスがすべて host01.idm.example.com ホストエントリーに正しく関連付けられていることを確認します。

28.5. Ansible Playbook を使用して IdM ホストエントリーがないことを確認する

本セクションでは、Ansible Playbook を使用して、Identity Management (IdM) にホストエントリーがないことを確認する方法を説明します。

前提条件

  • IdM 管理者認証情報

手順

  1. inventory.file などのインベントリーファイルを作成し、そのファイルに ipaserver を定義します。

    [ipaserver]
    server.idm.example.com
  2. IdM がないホストの 完全修飾ドメイン名 (FQDN) で Ansible Playbook ファイルを作成します。IdM ドメインに DNS が統合されている場合は、updatedns: yes オプションを使用して、あらゆる種類のホストに関連するレコードを DNS から削除します。

    この手順を単純化するには、/usr/share/doc/ansible-freeipa/playbooks/host/delete-host.yml ファイルのサンプルをコピーして変更できます。

    ---
    - name: Host absent
      hosts: ipaserver
      become: true
    
      tasks:
      - name: Host host01.idm.example.com absent
        ipahost:
          ipaadmin_password: MyPassword123
          name: host01.idm.example.com
          updatedns: yes
          state: absent
  3. Playbook を実行します。

    $ ansible-playbook -v -i path_to_inventory_directory/inventory.file path_to_playbooks_directory/ensure-host-absent.yml
注記

この手順の結果は以下のようになります。

  • IdM Kerberos レルムにホストが存在していない。
  • IdM LDAP サーバーにホストエントリーが存在しません。

SSSD (System Security Services Daemon) などのシステムサービスの特定の IdM 設定をクライアントホスト自体から削除するには、クライアントで ipa-client-install --uninstall コマンドを実行する必要があります。詳細は「IdM クライアントのアンインストール」を参照してください。

検証手順

  1. admin として ipaserver にログインします。

    $ ssh admin@server.idm.example.com
    Password:
    [admin@server /]$
  2. host01.idm.example.com に関する情報を表示します。

    $ ipa host-show host01.idm.example.com
    ipa: ERROR: host01.idm.example.com: host not found

この出力は、ホストが IdM に存在しないことを確認します。

関連情報

  • /usr/share/doc/ansible-freeipa/README-host.md Markdown ファイルにホストが存在し、存在し、存在しないようにするために、ipahost 変数の定義とサンプルの Ansible Playbook を確認することができます。
  • 追加の Playbook は /usr/share/doc/ansible-freeipa/playbooks/host ディレクトリーにあります。

第29章 IdM CLI を使用したホストグループの管理

本章では、Identity Management (IdM) のホストグループを紹介し、コマンドラインインターフェース (CLI) でホストグループとそのメンバーを管理する以下の操作を説明します。

  • ホストグループおよびそのメンバーの表示
  • ホストグループの作成
  • ホストグループの削除
  • ホストグループメンバーの追加
  • ホストグループメンバーの削除

29.1. IdM のホストグループ

IdM ホストグループを使用すると、重要な管理タスク (特にアクセス制御) を一元管理できます。

ホストグループの定義

ホストグループは、一般的なアクセス制御ルールやその他の特性を持つ IdM ホストセットが含まれるエンティティーです。たとえば、企業の部門、物理的な場所、またはアクセス制御要件に基づいてホストグループを定義できます。

IdM のホストグループには以下が含まれます。

  • IdM サーバーおよびクライアント
  • その他の IdM ホストグループ

デフォルトで作成されたホストグループ

デフォルトでは、IdM サーバーは、全 IdM サーバーホストのホストグループ ipaservers を作成します。

直接および間接のグループメンバー

IdM のグループ属性は、直接メンバーと間接メンバーの両方に適用されます。ホストグループ B がホストグループ A のメンバーである場合、ホストグループ B のすべてのユーザーはホストグループ A の間接メンバーと見なされます。

29.2. CLI で IdM ホストグループの表示

本セクションでは、コマンドラインインターフェース (CLI) を使用して IdM ホストグループを表示する方法を説明します。

前提条件

手順

  1. ipa hostgroup-find コマンドを使用して、すべてのホストグループを検索します。

    $ ipa hostgroup-find
    -------------------
    1 hostgroup matched
    -------------------
      Host-group: ipaservers
      Description: IPA server hosts
    ----------------------------
    Number of entries returned 1
    ----------------------------

    ホストグループのすべての属性を表示するには、--all オプションを追加します。以下に例を示します。

    $ ipa hostgroup-find --all
    -------------------
    1 hostgroup matched
    -------------------
      dn: cn=ipaservers,cn=hostgroups,cn=accounts,dc=idm,dc=local
      Host-group: ipaservers
      Description: IPA server hosts
      Member hosts: xxx.xxx.xxx.xxx
      ipauniqueid: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
      objectclass: top, groupOfNames, nestedGroup, ipaobject, ipahostgroup
    ----------------------------
    Number of entries returned 1
    ----------------------------

29.3. CLI を使用した IdM ホストグループの作成

本セクションでは、コマンドラインインターフェース (CLI) を使用して IdM ホストグループを作成する方法を説明します。

前提条件

手順

  1. ipa hostgroup-add コマンドを使用してホストグループを追加します。
    たとえば、group_name という名前の IdM ホストグループを作成し、その説明を表示するには、次のコマンドを実行します。

    $ ipa hostgroup-add --desc 'My new host group' group_name
    ---------------------
    Added hostgroup "group_name"
    ---------------------
      Host-group: group_name
      Description: My new host group
    ---------------------

29.4. CLI で IdM ホストグループの削除

本セクションでは、コマンドラインインターフェース (CLI) を使用して IdM ホストグループを削除する方法を説明します。

前提条件

手順

  1. ipa hostgroup-del コマンドを使用してホストグループを削除します。
    たとえば、group_name という名前の IdM ホストグループを削除するには、次のコマンドを実行します。

    $ ipa hostgroup-del group_name
    --------------------------
    Deleted hostgroup "group_name"
    --------------------------
注記

グループを削除しても、IdM からグループメンバーは削除されません。

29.5. CLI で IdM ホストグループメンバーの追加

1 つのコマンドを使用して、ホストとホストグループを IdM ホストグループのメンバーとして追加できます。

前提条件

  • IdM、またはユーザー管理者ロールを管理する管理者権限
  • アクティブな Kerberos チケット。詳細は「kinit による IdM への手動ログイン」を参照してください。
  • 任意です。ipa hostgroup-find コマンドを使用して、ホストおよびホストグループを検索します。

手順

  1. ホストグループにメンバーを追加するには、ipa hostgroup-add-member を使用して、関連する情報を提供します。以下のオプションを使用して、追加するメンバーのタイプを指定できます。

    • --hosts オプションを使用して、ホストを IdM ホストグループに追加します。
      たとえば、example_member という名前のホストを group_name という名前のグループに追加するには、次のコマンドを実行します。

      $ ipa hostgroup-add-member group_name --hosts example_member
      Host-group: group_name
      Description: My host group
      Member hosts: example_member
      -------------------------
      Number of members added 1
      -------------------------
    • --hostgroups オプションを使用して、IdM ホストグループにホストグループを追加します。
      たとえば、nested_group という名前のホストグループを group_name という名前のグループに追加するには、次のコマンドを実行します。

      $ ipa hostgroup-add-member group_name --hostgroups nested_group
      Host-group: group_name
      Description: My host group
      Member host-groups: nested_group
      -------------------------
      Number of members added 1
      -------------------------
    • 以下の構文を使用すると、単一のコマンドで複数のホストと複数のホストグループを IdM ホストグループに追加できます。

      $ ipa hostgroup-add-member group_name --hosts={host1,host2} --hostgroups={group1,group2}
重要

ホストグループを別のホストグループのメンバーとして追加する場合は、再帰グループを作成しないでください。たとえば、グループ A がグループ B のメンバーである場合は、グループ B をグループ A のメンバーとして追加しないでください。再帰的なグループにより予期しない動作が発生する可能性があります。

29.6. CLI で IdM ホストグループメンバーの削除

1 つのコマンドを使用して、IdM ホストグループからホストとホストグループを削除できます。

前提条件

  • IdM、またはユーザー管理者ロールを管理する管理者権限
  • アクティブな Kerberos チケット。詳細は「kinit による IdM への手動ログイン」を参照してください。
  • 任意です。ipa group-show コマンドを使用して、削除するメンバーがグループに含まれていることを確認します。

手順

  1. ホストグループメンバーを削除するには、ipa hostgroup-remove-member コマンドを使用して、関連する情報を提供します。以下のオプションを使用して、削除するメンバーのタイプを指定できます。

    • --hosts オプションを使用して、IdM ホストグループからホストを削除します。
      たとえば、example_member という名前のホストを group_name という名前のグループから削除するには、次のコマンドを実行します。

      $ ipa hostgroup-remove-member group_name --hosts example_member
      Host-group: group_name
      Description: My host group
      -------------------------
      Number of members removed 1
      -------------------------
    • --hostgroups オプションを使用して、IdM ホストグループからホストグループを削除します。
      たとえば、group_name という名前のグループから nested_group という名前のホストグループを削除するには、次のコマンドを実行します。

      $ ipa hostgroup-remove-member group_name --hostgroups example_member
      Host-group: group_name
      Description: My host group
      -------------------------
      Number of members removed 1
      -------------------------
注記

グループを削除しても、IdM からグループメンバーは削除されません。

  • 以下の構文を使用すると、単一のコマンドで IdM ホストグループから複数のホストと複数のホストグループを削除できます。

    $ ipa hostgroup-remove-member group_name --hosts={host1,host2} --hostgroups={group1,group2}

第30章 IdM Web UI を使用したホストグループの管理

本章では、Identity Management (IdM) のホストグループを紹介し、Web インターフェース (Web UI) でホストグループとそのメンバーを管理する以下の操作を説明します。

  • ホストグループおよびそのメンバーの表示
  • ホストグループの作成
  • ホストグループの削除
  • ホストグループメンバーの追加
  • ホストグループメンバーの削除

30.1. IdM のホストグループ

IdM ホストグループを使用すると、重要な管理タスク (特にアクセス制御) を一元管理できます。

ホストグループの定義

ホストグループは、一般的なアクセス制御ルールやその他の特性を持つ IdM ホストセットが含まれるエンティティーです。たとえば、企業の部門、物理的な場所、またはアクセス制御要件に基づいてホストグループを定義できます。

IdM のホストグループには以下が含まれます。

  • IdM サーバーおよびクライアント
  • その他の IdM ホストグループ

デフォルトで作成されたホストグループ

デフォルトでは、IdM サーバーは、全 IdM サーバーホストのホストグループ ipaservers を作成します。

直接および間接のグループメンバー

IdM のグループ属性は、直接メンバーと間接メンバーの両方に適用されます。ホストグループ B がホストグループ A のメンバーである場合、ホストグループ B のすべてのユーザーはホストグループ A の間接メンバーと見なされます。

30.2. IdM Web UI でのホストグループの表示

本セクションでは、Web インターフェース (Web UI) を使用して IdM ホストグループを表示する方法を説明します。

前提条件

手順

  1. Identity → Groups をクリックし、Host Groups タブを選択します。

    • このページには、既存のホストグループとその説明が記載されています。
    • 特定のホストグループを検索できます。

    idm viewing host groups

  2. 一覧のグループをクリックして、このグループに属するホストを表示します。結果を直接または間接メンバーに制限できます。

    idm viewing host group members

  3. ホストグループ タブを選択して、このグループに属するホストグループを表示します (ネスト化されたホストグループ)。結果を直接または間接メンバーに制限できます。

    idm viewing host group members nested group

30.3. IdM Web UI でのホストグループの作成

本セクションでは、Web インターフェース (Web UI) を使用して IdM ホストグループを作成する方法を説明します。

前提条件

手順

  1. Identity → Groups をクリックし、Host Groups タブを選択します。
  2. Add をクリックします。ホストグループの追加 ダイアログが表示されます。
  3. Group: name (必須) および description (オプション) についての情報を指定します。
  4. Add をクリックして確定します。

    idm creating host groups

30.4. IdM Web UI でのホストグループの削除

本セクションでは、Web インターフェース (Web UI) を使用して IdM ホストグループを削除する方法を説明します。

前提条件

手順

  1. Identity → Groups をクリックし、Host Groups タブを選択します。
  2. 削除する IdM ホストグループを選択し、削除 をクリックします。確認ダイアログが表示されます。
  3. Delete をクリックして確定します。

    idm deleting host groups

注記

ホストグループを削除しても、IdM からグループメンバーは削除されません。

30.5. IdM Web UI でのホストグループメンバーの追加

本セクションでは、Web インターフェース (Web UI) を使用して IdM にホストグループメンバーを追加する方法を説明します。

前提条件

手順

  1. Identity → Groups をクリックし、Host Groups タブを選択します。
  2. メンバーを追加するグループの名前をクリックします。
  3. 追加するメンバーのタイプに応じて、ホスト または ホストグループ をクリックします。対応するダイアログが表示されます。
  4. 追加するホストまたはホストグループを選択し、> ボタンをクリックして Prospective コラムに移動します。
  5. Add をクリックして確定します。

    idm adding host group members

30.6. IdM Web UI でホストグループメンバーの削除

本セクションでは、Web インターフェース (Web UI) を使用して IdM でホストグループメンバーを削除する方法を説明します。

前提条件

手順

  1. Identity → Groups をクリックし、Host Groups タブを選択します。
  2. メンバーを削除するグループの名前をクリックします。
  3. 削除するメンバーのタイプに応じて、ホスト または ホストグループ をクリックします。
  4. 削除するメンバーの横にあるチェックボックスを選択します。
  5. 削除 をクリックします。確認ダイアログが表示されます。

    idm removing host group members

  6. Delete をクリックして確定します。選択したメンバーが削除されます。

第31章 Ansible Playbook を使用したホストグループの管理

本章では、Ansible を使用して、Identity Management (IdM) でホストグループに関連する以下の操作を実行する方法を説明します。

31.1. Ansible Playbook を使用した IdM ホストグループの存在の確認

本セクションでは、Ansible Playbook を使用して、Identity Management (IdM) にホストグループが存在することを確認する方法を説明します。

注記

Ansible を使用しないと、ipa hostgroup-add コマンドを使用して、ホストグループエントリーが IdM に作成されます。ホストグループを IdM に追加すると、IdM に存在するホストグループの状態になります。Ansible はべき等性に依存しているため、Ansible を使用してホストグループを IdM に追加するには、ホストグループの状態を present: state: present として定義する Playbook を作成する必要があります。

前提条件

  • IdM 管理者パスワードが分かっている。
  • Ansible コントローラーに ansible-freeipa パッケージがインストールされている。

手順

  1. inventory.file などのインベントリーファイル を作成し、ターゲットに設定する IdM サーバーの一覧と共に ipaserver を定義します。

    [ipaserver]
    server.idm.example.com
  2. 必要なホストグループ情報を使用して Ansible Playbook ファイルを作成します。たとえば、databases という名前のホストグループが存在することを確認するには、- ipahostgroup タスクで 名前: データベース を指定します。この手順を単純化するには、/usr/share/doc/ansible-freeipa/playbooks/user/ensure-hostgroup-is-present.yml ファイルのサンプルをコピーして変更できます。

    ---
    - name: Playbook to handle hostgroups
      hosts: ipaserver
      become: true
    
      tasks:
      # Ensure host-group databases is present
      - ipahostgroup:
          ipaadmin_password: Secret123
          name: databases
          state: present

    Playbook で state: present は、すでに存在しない限り、ホストグループを IdM に追加する要求を示します。

  3. Playbook を実行します。

    $ ansible-playbook -v -i path_to_inventory_directory/inventory.file path_to_playbooks_directory/ensure-hostgroup-is-present.yml

検証手順

  1. admin として ipaserver にログインします。

    $ ssh admin@server.idm.example.com
    Password:
    [admin@server /]$
  2. admin の Kerberos チケットを要求します。

    $ kinit admin
    Password for admin@IDM.EXAMPLE.COM:
  3. IdM に存在するホストグループに関する情報を表示します。

    $ ipa hostgroup-show databases
      Host-group: databases

データベース ホストグループが IdM に存在する。

31.2. Ansible Playbook を使用して IdM ホストグループにホストが存在することを確認する

本セクションでは、Ansible Playbook を使用して、Identity Management (IdM) のホストグループにホストが存在することを確認する方法を説明します。

前提条件

手順

  1. inventory.file などのインベントリーファイル を作成し、ターゲットに設定する IdM サーバーの一覧と共に ipaserver を定義します。

    [ipaserver]
    server.idm.example.com
  2. 必要なホスト情報を使用して Ansible Playbook ファイルを作成します。ipahostgroup 変数の name パラメーターを使用してホストグループの名前を指定します。ipahostgroup 変数の host パラメーターを使用してホストの名前を指定します。この手順を単純化するには、/usr/share/doc/ansible-freeipa/playbooks/hostgroup/ensure-hosts-and-hostgroups-are-present-in-hostgroup.yml ファイルのサンプルをコピーして変更することができます。

    ---
    - name: Playbook to handle hostgroups
      hosts: ipaserver
      become: true
    
      tasks:
      # Ensure host-group databases is present
      - ipahostgroup:
          ipaadmin_password: Secret123
          name: databases
          host:
          - db.idm.example.com
          action: member

    この Playbook は、db.idm.example.com ホストを データベース ホストグループに追加します。action: member 行は、Playbook が実行されると、データベース グループ自体の追加を試行しないことを示します。代わりに、db.idm.example.comデータベース に追加しようとします。

  3. Playbook を実行します。

    $ ansible-playbook -v -i path_to_inventory_directory/inventory.file path_to_playbooks_directory/ensure-hosts-or-hostgroups-are-present-in-hostgroup.yml

検証手順

  1. admin として ipaserver にログインします。

    $ ssh admin@server.idm.example.com
    Password:
    [admin@server /]$
  2. admin の Kerberos チケットを要求します。

    $ kinit admin
    Password for admin@IDM.EXAMPLE.COM:
  3. ホストグループに関する情報を表示して、どのホストが存在するかを確認します。

    $ ipa hostgroup-show databases
      Host-group: databases
      Member hosts: db.idm.example.com

db.idm.example.com ホストは、データベース ホストグループのメンバーとして存在します。

31.3. Ansible Playbook を使用した IdM ホストグループのネスト化

本セクションでは、Ansible Playbook を使用して、Identity Management (IdM) ホストグループにネスト化されたホストグループが存在することを確認する方法を説明します。

前提条件

手順

  1. inventory.file などのインベントリーファイル を作成し、ターゲットに設定する IdM サーバーの一覧と共に ipaserver を定義します。

    [ipaserver]
    server.idm.example.com
  2. 必要なホストグループ情報を使用して Ansible Playbook ファイルを作成します。ネストされたホストグループ A が、Ansible Playbook のホストグループ B に存在することを確認するには、name 変数を使用してホストグループ B の名前 - ipahostgroup 変数のいずれかを指定します。hostgroup 変数でネスト化されたホストグループ A の名前を指定します。この手順を単純化するには、/usr/share/doc/ansible-freeipa/playbooks/hostgroup/ensure-hosts-and-hostgroups-are-present-in-hostgroup.yml ファイルのサンプルをコピーして変更することができます。

    ---
    - name: Playbook to handle hostgroups
      hosts: ipaserver
      become: true
    
      tasks:
      # Ensure hosts and hostgroups are present in existing databases hostgroup
      - ipahostgroup:
          ipaadmin_password: Secret123
          name: databases
          hostgroup:
          - mysql-server
          - oracle-server
          action: member

    この Ansible Playbook は、データベース ホストグループに myqsl-server および oracle-server ホストグループが存在することを確認します。action: member 行は、Playbook が実行されると、データベース グループ自体を IdM に追加しようとはしません。

  3. Playbook を実行します。

    $ ansible-playbook -v -i path_to_inventory_directory/inventory.file path_to_playbooks_directory/ensure-hosts-or-hostgroups-are-present-in-hostgroup.yml

検証手順

  1. admin として ipaserver にログインします。

    $ ssh admin@server.idm.example.com
    Password:
    [admin@server /]$
  2. admin の Kerberos チケットを要求します。

    $ kinit admin
    Password for admin@IDM.EXAMPLE.COM:
  3. ネスト化されたホストグループが存在するホストグループに関する情報を表示します。

    $ ipa hostgroup-show databases
      Host-group: databases
      Member hosts: db.idm.example.com
      Member host-groups: mysql-server, oracle-server

mysql-server および oracle-server ホストグループは、データベース ホストグループに存在します。

31.4. Ansible Playbook を使用した IdM ホストグループからのホスト不足の確認

本セクションでは、Ansible Playbook を使用して、Identity Management (IdM) のホストグループにホストがないことを確認する方法を説明します。

前提条件

手順

  1. inventory.file などのインベントリーファイル を作成し、ターゲットに設定する IdM サーバーの一覧と共に ipaserver を定義します。

    [ipaserver]
    server.idm.example.com
  2. 必要なホストおよびホストグループ情報を使用して Ansible Playbook ファイルを作成します。ipahostgroup 変数の name パラメーターを使用してホストグループの名前を指定します。ipahostgroup 変数の host パラメーターを使用することを確認するホストグループがないホストの名前を指定します。この手順を単純化するには、/usr/share/doc/ansible-freeipa/playbooks/hostgroup/ensure-hosts-and-hostgroups-are-absent-in-hostgroup.yml ファイルのサンプルをコピーして変更することができます。

    ---
    - name: Playbook to handle hostgroups
      hosts: ipaserver
      become: true
    
      tasks:
      # Ensure host-group databases is absent
      - ipahostgroup:
          ipaadmin_password: Secret123
          name: databases
          host:
          - db.idm.example.com
          action: member
          state: absent

    この Playbook は、データベース ホストグループから db.idm.example.com ホストがないことを確認します。action: member 行は、Playbook が実行されると、データベース グループ自体の削除を試行しないことを示します。

  3. Playbook を実行します。

    $ ansible-playbook -v -i path_to_inventory_directory/inventory.file path_to_playbooks_directory/ensure-hosts-or-hostgroups-are-absent-in-hostgroup.yml

検証手順

  1. admin として ipaserver にログインします。

    $ ssh admin@server.idm.example.com
    Password:
    [admin@server /]$
  2. admin の Kerberos チケットを要求します。

    $ kinit admin
    Password for admin@IDM.EXAMPLE.COM:
  3. ホストグループと、そのホストグループに含まれるホストに関する情報を表示します。

    $ ipa hostgroup-show databases
      Host-group: databases
      Member host-groups: mysql-server, oracle-server

db.idm.example.com ホストは データベース ホストグループに存在しません。

31.5. Ansible Playbook を使用して IdM ホストグループからネスト化されたホストグループがないことを確認する

本セクションでは、Ansible Playbook を使用して、Identity Management (IdM) の外部ホストグループからネスト化されたホストグループがないことを確認する方法を説明します。

前提条件

手順

  1. inventory.file などのインベントリーファイル を作成し、ターゲットに設定する IdM サーバーの一覧と共に ipaserver を定義します。

    [ipaserver]
    server.idm.example.com
  2. 必要なホストグループ情報を使用して Ansible Playbook ファイルを作成します。- ipahostgroup 変数で、name 変数を使用して、外部ホストグループの名前を指定します。hostgroup 変数でネスト化されたホストグループの名前を指定します。この手順を単純化するには、/usr/share/doc/ansible-freeipa/playbooks/hostgroup/ensure-hosts-and-hostgroups-are-absent-in-hostgroup.yml ファイルのサンプルをコピーして変更することができます。

    ---
    - name: Playbook to handle hostgroups
      hosts: ipaserver
      become: true
    
      tasks:
      # Ensure hosts and hostgroups are absent in existing databases hostgroup
      - ipahostgroup:
          ipaadmin_password: Secret123
          name: databases
          hostgroup:
          - mysql-server
          - oracle-server
          action: member
          state: absent

    この Playbook は、mysql-server および oracle-server ホストグループが データベース ホストグループにないことを確認します。action: member 行は、Playbook が実行されると、データベース グループ自体が IdM から削除されるように試行されません。

  3. Playbook を実行します。

    $ ansible-playbook -v -i path_to_inventory_directory/inventory.file path_to_playbooks_directory/ensure-hosts-or-hostgroups-are-absent-in-hostgroup.yml

検証手順

  1. admin として ipaserver にログインします。

    $ ssh admin@server.idm.example.com
    Password:
    [admin@server /]$
  2. admin の Kerberos チケットを要求します。

    $ kinit admin
    Password for admin@IDM.EXAMPLE.COM:
  3. ネスト化されたホストグループが存在しないホストグループに関する情報を表示します。

    $ ipa hostgroup-show databases
      Host-group: databases

この出力では、mysql-server および oracle-server のネスト化されたホストグループが、外部 データベース のホストグループにないことを確認します。

31.6. Ansible Playbook を使用した IdM ホストグループの確保

本セクションでは、Ansible Playbook を使用して、Identity Management (IdM) にホストグループがないことを確認する方法を説明します。

注記

Ansible を使用しないと、ipa hostgroup-del コマンドを使用して、ホストグループエントリーが IdM から削除されます。IdM からホストグループを削除する結果は、IdM に存在しないホストグループの状態です。Ansible はべき等性に依存しているため、Ansible を使用して IdM からホストグループを削除するには、ホストグループの状態を absent: state: absent として定義する Playbook を作成する必要があります。

前提条件

  • IdM 管理者パスワードが分かっている。
  • Ansible コントローラーに ansible-freeipa パッケージがインストールされている。

手順

  1. inventory.file などのインベントリーファイル を作成し、ターゲットに設定する IdM サーバーの一覧と共に ipaserver を定義します。

    [ipaserver]
    server.idm.example.com
  2. 必要なホストグループ情報を使用して Ansible Playbook ファイルを作成します。この手順を単純化するには、/usr/share/doc/ansible-freeipa/playbooks/user/ensure-hostgroup-is-absent.yml ファイルのサンプルをコピーして変更できます。

    ---
    - name: Playbook to handle hostgroups
      hosts: ipaserver
      become: true
    
      tasks:
      # Ensure host-group databases is absent
      - ipahostgroup:
          ipaadmin_password: Secret123
          name: databases
          state: absent

    この Playbook は、IdM からの データベース ホストグループがないことを確認します。state: absent は、削除しない限り、IdM からホストグループを削除する要求を意味します。

  3. Playbook を実行します。

    $ ansible-playbook -v -i path_to_inventory_directory/inventory.file path_to_playbooks_directory/ensure-hostgroup-is-absent.yml

検証手順

  1. admin として ipaserver にログインします。

    $ ssh admin@server.idm.example.com
    Password:
    [admin@server /]$
  2. admin の Kerberos チケットを要求します。

    $ kinit admin
    Password for admin@IDM.EXAMPLE.COM:
  3. 確実に見つからないホストグループに関する情報を表示します。

    $ ipa hostgroup-show databases
    ipa: ERROR: databases: host group not found

データベース Iホストグループは IdM に存在しません。

第32章 Kerberos チケットポリシーの管理

Identity Management (IdM) の Kerberos チケットポリシーは、Kerberos チケットアクセス、期間、および更新の制限を設定します。IdM サーバーで実行している Key Distribution Center (KDC) の Kerberos チケットポリシーを設定できます。

本章では、以下の Kerberos チケット管理のトピックとタスクについて説明します。

32.1. IdM KDC の役割

Identity Management の認証メカニズムは、Key Distribution Center (KDC) が確立する Kerberos インフラストラクチャーを使用します。KDC は、認証情報を保存し、IdM ネットワーク内のエンティティーから発信されるデータの信頼性を確保する信頼できる認証局です。

各 IdM ユーザー、サービス、およびホストは Kerberos クライアントとして機能し、一意の Kerberos プリンシパル で識別されます。

  • ユーザーの場合: identifier@REALM (例: admin@EXAMPLE.COM)
  • サービスの場合: service/fully-qualified-hostname@REALM (http/master.example.com@EXAMPLE.COM など)
  • ホストの場合: host/fully-qualified-hostname@REALM (host/client.example.com@EXAMPLE.COM など)

以下のイメージは、Kerberos クライアント、KDC、およびクライアントが通信したい Kerberized アプリケーション間の通信の簡略化です。

Kerberos KDC の通信フロー
  1. Kerberos クライアントは、Kerberos プリンシパルとして認証することで KDC に自己識別します。たとえば、IdM ユーザーは kinit ユーザー名 を実行し、パスワードを提供します。
  2. KDC はデータベースのプリンシパルを確認し、クライアントを認証し、Kerberos チケットポリシー を評価してリクエストを付与するかどうかを判断します。
  3. KDC は、適切なチケットポリシーに従って、ライフサイクルおよび 認証インジケーター でチケット保証チケット (TGT) を発行します。
  4. TGT により、クライアントは KDC から サービスチケット を要求し、ターゲットホストで Kerberized サービスと通信します。
  5. KDC は、クライアントの TGT が有効であるかどうかを確認し、チケットポリシーに対してサービスチケット要求を評価します。
  6. KDC はクライアントに サービスチケット を発行します。
  7. サービスチケットを使用すると、クライアントはターゲットホストのサービスと暗号化された通信を開始できます。

32.2. IdM Kerberos チケットポリシータイプ

IdM Kerberos チケットポリシーは、以下のチケットポリシータイプを実装します。

接続ポリシー

異なるレベルのセキュリティーで Kerberized サービスを保護するには、Ticket-Granting ticket (TGT) の取得に使用するクライアントの事前認証メカニズムに基づいて、強制ルールを強制する接続ポリシーを定義できます。

たとえば、スマートカード認証を使用して client1.example.com に接続し、client2.example.comtestservice アプリケーションにアクセスするには 2 要素認証が必要になる場合があります。

接続ポリシーを実施するには、認証インジケーター をサービスに関連付けます。サービスチケット要求に必要な認証インジケーターを持つクライアントのみがこれらのサービスにアクセスできます。詳細は、「Kerberos 認証インジケーター」を参照してください。

チケットライフサイクルポリシー

各 Kerberos チケットには 有効期間 と潜在的な 更新期間 があります。チケットは最長期間に達する前に更新できますが、更新期間を超過することはできません。

デフォルトのグローバルチケットの有効期間は 1 日 (86400 秒) で、デフォルトのグローバル最大更新期間は 1 週間 (604800 秒) です。これらのグローバル値を調整するには、「グローバルチケットライフサイクルポリシーの設定」を参照してください。

独自のチケットライフサイクルポリシーを定義することもできます。

32.3. Kerberos 認証インジケーター

Kerberos Key Distribution Center (KDC) は、認証インジケーター を、クライアントがアイデンティティーを証明する事前認証メカニズムに基づいて TGT (Ticket-granting Ticket) に割り当てます。

otp
2 要素認証 (パスワード + ワンタイムパスワード)
radius
radius 認証 (通常は 802.1x 認証)
pkinit
PKINIT、スマートカード、または証明書での認証
hardened
強化パスワード (SPAKE または FAST)[1]

KDC は認証インジケーターを TGT からそこから取得するサービスチケットリクエストに割り当てます。KDC は、認証インジケーターに基づいて、サービスアクセス制御、チケットの最大有効期間、および更新可能な期間などのポリシーを強制します。

32.3.1. 認証インジケーターおよび IdM サービス

サービスまたはホストを認証インジケーターに関連付けると、対応する認証メカニズムを使用して TGT を取得したクライアントのみがアクセスできるようになります。KDC はアプリケーションやサービスではなく、サービスチケット要求の認証インジケーターをチェックし、Kerberos 接続ポリシーに基づいて要求を付与または拒否します。

たとえば、ホスト secure.example.com への接続に 2 要素認証を必要とするには、otp 認証インジケーターを host/secure.example.com@EXAMPLE.COM Kerberos プリンシパルに関連付けます。KDC から最初の TGT を取得するためにワンタイムパスワードを使用するユーザーのみがログインできます。

サービスまたはホストに認証インジケーターが割り当てられていない場合、そのサービスはメカニズムによって認証されたチケットを受け入れます。

関連情報



[1] 強化されたパスワードは、FAST (Secure Tunneling) 発信によるシングルパーティーの公開鍵認証済み鍵交換 (SPAKE) 事前認証および/または Flexible 認証を使用して、ブルートフォースパスワードディクショナリ攻撃に対して保護されます。

32.4. IdM サービスの認証インジケーターの強制

この手順では、IdM サービスを作成し、着信サービスチケット要求から特定の Kerberos 認証インジケーターを必要とするように設定する方法を説明します。

認証インジケーターと IdM サービスを関連付けることで、その特定の事前認証メカニズムを使用して初期の TGT (Ticket-Granting Ticket) を取得できるクライアントのみがサービスにアクセスできます。

32.4.1. IdM サービスエントリーおよびその Kerberos キータブの作成

IdM ホストで実行しているサービスの IdM に IdM サービス エントリーを追加すると、対応する Kerberos プリンシパルが作成され、サービスが SSL 証明書、Kerberos キータブ、またはその両方を要求できるようになります。

以下の手順では、IdM サービスエントリーを作成し、そのサービスとの通信を暗号化するための関連付けられた Kerberos キータブを生成する方法を説明します。

前提条件

  • サービスは、Kerberos プリンシパル、SSL 証明書、またはその両方を保存することができます。

手順

  1. ipa service-add コマンドで IdM サービスを追加して、これに関連付けられた Kerberos プリンシパルを作成します。たとえば、ホスト client.example.com で実行する testservice アプリケーションの IdM サービスエントリーを作成するには、次のコマンドを実行します。

    [root@client ~]# ipa service-add testservice/client.example.com
    -------------------------------------------------------------
    Modified service "testservice/client.example.com@EXAMPLE.COM"
    -------------------------------------------------------------
      Principal name: testservice/client.example.com@EXAMPLE.COM
      Principal alias: testservice/client.example.com@EXAMPLE.COM
      Managed by: client.example.com
  2. クライアント上のサービスの Kerberos キータブを生成し、保存します。

    [root@client ~]# ipa-getkeytab -k /etc/testservice.keytab -p testservice/client.example.com
    Keytab successfully retrieved and stored in: /etc/testservice.keytab

検証手順

  • ipa service-show コマンドを使用して、IdM サービスに関する情報を表示します。

    [root@server ~]# ipa service-show testservice/client.example.com
      Principal name: testservice/client.example.com@EXAMPLE.COM
      Principal alias: testservice/client.example.com@EXAMPLE.COM
      Keytab: True
      Managed by: client.example.com
  • klist コマンドを使用して、サービスの Kerberos キータブの内容を表示します。

    [root@server etc]# klist -ekt /etc/testservice.keytab
    Keytab name: FILE:/etc/testservice.keytab
    KVNO Timestamp           Principal
    ---- ------------------- ------------------------------------------------------
       2 04/01/2020 17:52:55 testservice/client.example.com@EXAMPLE.COM (aes256-cts-hmac-sha1-96)
       2 04/01/2020 17:52:55 testservice/client.example.com@EXAMPLE.COM (aes128-cts-hmac-sha1-96)
       2 04/01/2020 17:52:55 testservice/client.example.com@EXAMPLE.COM (camellia128-cts-cmac)
       2 04/01/2020 17:52:55 testservice/client.example.com@EXAMPLE.COM (camellia256-cts-cmac)

32.4.2. 認証インジケーターと IdM サービスとの関連付け

この手順では、受信サービスチケット要求から特定の Kerberos 認証インジケーターを必要とするようにサービスを設定する方法を説明します。

前提条件

警告

内部 IdM サービスに認証インジケーターを割り当て ない でください。以下の IdM サービスは、PKINIT およびマルチファクター認証方式で必要なインタラクティブな認証ステップを実行できません。

host/server.example.com@EXAMPLE.COM
HTTP/server.example.com@EXAMPLE.COM
ldap/server.example.com@EXAMPLE.COM
DNS/server.example.com@EXAMPLE.COM
cifs/server.example.com@EXAMPLE.COM

手順

  • ipa service-mod コマンドを使用して、--auth-ind 引数で識別されるサービスに必要な認証インジケーターを指定します。

    認証方法--auth-ind

    2 要素認証

    otp

    radius 認証

    radius

    PKINIT、スマートカード、または証明書での認証

    pkinit

    強化パスワード (SPAKE または FAST)

    hardened

    たとえば、ホスト client.example.com 上の testservice プリンシパルのサービスチケットを取得するために、スマートカードまたは OTP 認証でユーザーを認証することを要求するには、次のコマンドを実行します。

    [root@server ~]# ipa service-mod testservice/client.example.com@EXAMPLE.COM --auth-ind otp --auth-ind pkinit
    -------------------------------------------------------------
    Modified service "testservice/client.example.com@EXAMPLE.COM"
    -------------------------------------------------------------
      Principal name: testservice/client.example.com@EXAMPLE.COM
      Principal alias: testservice/client.example.com@EXAMPLE.COM
      Authentication Indicators: otp, pkinit
      Managed by: client.example.com
注記

サービスからすべての認証インジケーターを削除するには、インジケーターの空のリストを指定します。

[root@server ~]# ipa service-mod testservice/client.example.com@EXAMPLE.COM --auth-ind ''
------------------------------------------------------
Modified service "testservice/client.example.com@EXAMPLE.COM"
------------------------------------------------------
  Principal name: testservice/client.example.com@EXAMPLE.COM
  Principal alias: testservice/client.example.com@EXAMPLE.COM
  Managed by: client.example.com

検証手順

  • ipa service-show コマンドを使用して、必要な認証インジケーターを含む、IdM サービスに関する情報を表示します。

    [root@server ~]# ipa service-show testservice/client.example.com
      Principal name: testservice/client.example.com@EXAMPLE.COM
      Principal alias: testservice/client.example.com@EXAMPLE.COM
      Authentication Indicators: otp, pkinit
      Keytab: True
      Managed by: client.example.com

関連情報

32.4.3. IdM サービスの Kerberos サービスチケットの取得

以下の手順では、IdM サービスの Kerberos サービスチケットを取得する方法を説明します。この手順を使用して、Kerberos チケットポリシーをテストすることができます。

前提条件

手順

  • サービスチケットを取得するには、kvno コマンドに -S オプションを指定して、IdM サービスの名前と管理するホストの完全修飾ドメイン名を指定します。

    [root@server ~]# kvno -S testservice client.example.com
    testservice/client.example.com@EXAMPLE.COM: kvno = 1
注記

IdM サービスにアクセスして現行の TGT (Ticket-granting Ticket) にアクセスする必要がある場合は、kdestroy コマンドで現在の Kerberos 認証情報キャッシュを削除し、新しい TGT を取得します。

[root@server ~]# kdestroy

たとえば、パスワードを使用して認証し、pkinit 認証インジケーターが関連付けられた IdM サービスにアクセスする必要がある場合は、現在の認証情報キャッシュを破棄し、スマートカードで再認証します。Kerberos 認証インジケーター を参照してください。

検証手順

  • klist コマンドを使用して、サービスチケットがデフォルトの Kerberos 認証情報キャッシュにあることを確認します。

    [root@server etc]# klist_
    Ticket cache: KCM:1000
    Default principal: admin@EXAMPLE.COM
    
    Valid starting       Expires              Service principal
    04/01/2020 12:52:42  04/02/2020 12:52:39  krbtgt/EXAMPLE.COM@EXAMPLE.COM
    04/01/2020 12:54:07 04/02/2020 12:52:39 testservice/client.example.com@EXAMPLE.COM

32.4.4. 関連情報

32.5. グローバルチケットライフサイクルポリシーの設定

グローバルチケットポリシーは、すべてのサービスチケットとユーザーごとのチケットポリシーが定義されていないユーザーに適用されます。

以下の手順では、ipa krbtpolicy-mod コマンドを使用して、グローバル Kerberos チケットポリシーのチケットの最大有効期間と最大更新期間を調整する方法を説明します。

ipa krbtpolicy-mod コマンドを使用する場合は、以下の引数のいずれかを指定します。

  • --maxlife - チケットの最大有効期間 (秒単位)
  • --maxrenew - 更新可能な最大期間 (秒単位)

手順

  • グローバルチケットポリシーを変更するには、以下を実行します。

    [root@server ~]# ipa krbtpolicy-mod --maxlife=$((8*60*60)) --maxrenew=$((24*60*60))
      Max life: 28800
      Max renew: 86400

    この例では、最大有効期間は 8 時間 (8 * 60 分 * 60 秒) に設定され、更新期間の最大期間は 1 日 (24 * 60 分 * 60 秒) に設定されています。

  • オプション: グローバルの Kerberos チケットポリシーをデフォルトのインストール値にリセットするには、以下を実行します。

    [root@server ~]# ipa krbtpolicy-reset
      Max life: 86400
      Max renew: 604800

検証手順

  • グローバルチケットポリシーを表示します。

    [root@server ~]# ipa krbtpolicy-show
      Max life: 28800
      Max renew: 86640

関連情報

32.6. 認証インジケーターごとのグローバルチケットポリシーの設定

この手順では、各認証インジケーターのグローバルチケットの最大有効期間および更新可能な期間を調整する方法を説明します。これらの設定は、ユーザーごとのチケットポリシーが定義されていないユーザーに適用されます。

ipa krbtpolicy-mod コマンドを使用して、Kerberos チケットのグローバル有効期間または更新可能な期間を指定します。これは、それらに割り当てられた 認証インジケーター によって異なります。

手順

  • たとえば、グローバルな 2 要素のチケットの有効期間と更新期間の値を 1 週に設定するには、グローバルスマートカードチケットの有効期間と更新期間の値を 2 週に設定します。

    [root@server ~]# ipa krbtpolicy-mod --otp-maxlife=604800 --otp-maxrenew=604800 --pkinit-maxlife=172800 --pkinit-maxrenew=172800

検証手順

  • グローバルチケットポリシーを表示します。

    [root@server ~]# ipa krbtpolicy-show
      Max life: 86400
      OTP max life: 604800
      PKINIT max life: 172800
      Max renew: 604800
      OTP max renew: 604800
      PKINIT max renew: 172800

    OTP および PKINIT の値は、グローバルなデフォルトの Max ライフサイクル および Max renew 値とは異なることに注意してください。

関連情報

32.7. ユーザーのデフォルトチケットポリシーの設定

単一のユーザーにのみ適用される一意の Kerberos チケットポリシーを定義できます。これらのユーザーごとの設定は、すべての認証インジケーターに対してグローバルチケットポリシーを上書きします。

ipa krbtpolicy-mod username コマンドを使用して、最低でも以下のいずれかの引数を指定します。

  • --maxlife - チケットの最大有効期間 (秒単位)
  • --maxrenew - 更新可能な最大期間 (秒単位)

手順

  • たとえば、IdM 管理者 ユーザーの最大チケット期間を 2 日に、更新期間を 2 週に設定するには、次のコマンドを実行します。

    [root@server ~]# ipa krbtpolicy-mod admin --maxlife=172800 --maxrenew=1209600
      Max life: 172800
      Max renew: 1209600
  • オプション: ユーザーのチケットポリシーをリセットするには、以下を実行します。

    [root@server ~]# ipa krbtpolicy-reset admin

検証手順

  • ユーザーに適用される有効な Kerberos チケットポリシーを表示します。

    [root@server ~]# ipa krbtpolicy-show admin
      Max life: 172800
      Max renew: 1209600

関連情報

32.8. ユーザーの個々の認証インジケーターチケットポリシーの設定

管理者は、認証インジケーターごとに異なるユーザーの Kerberos チケットポリシーを定義できます。たとえば、IdM 管理者 ユーザーが OTP 認証で取得した 2 日間チケットを更新できるようにポリシーと、スマートカード認証で取得した 1 週間のチケットを更新できるようにポリシーを設定できます。

これらの認証インジケーター設定は、ユーザーの デフォルトのチケットポリシー、グローバル デフォルトチケットポリシー、および グローバル 認証インジケーターチケットポリシーを上書きします。

ipa krbtpolicy-mod username コマンドを使用して、ユーザー Kerberos チケットのカスタム最大有効期間および更新可能な期間の最大値を設定します。この値は、ユーザーに割り当てられた 認証インジケーター によって異なります。

手順

  • たとえば、ワンタイムパスワード認証で取得した場合に IdM 管理者 ユーザーが Kerberos チケットを更新できるようにするには、--otp-maxrenew オプションを設定します。

    [root@server ~]# ipa krbtpolicy-mod admin --otp-maxrenew=$((2*24*60*60))
      OTP max renew: 172800
  • オプション: ユーザーのチケットポリシーをリセットするには、以下を実行します。

    [root@server ~]# ipa krbtpolicy-reset username

検証手順

  • ユーザーに適用される有効な Kerberos チケットポリシーを表示します。

    [root@server ~]# ipa krbtpolicy-show admin
      Max life: 28800
      Max renew: 86640

関連情報

32.9. krbtpolicy-mod コマンドの認証インジケーターオプション

以下の引数で認証インジケーターの値を指定します。

表32.1 krbtpolicy-mod コマンドの認証インジケーターオプション

認証インジケーター最大有効期間の引数更新期間の最大値の引数

otp

--otp-maxlife

--otp-maxrenew

radius

--radius-maxlife

--radius-maxrenew

pkinit

--pkinit-maxlife

--pkinit-maxrenew

hardened

--hardened-maxlife

--hardened-maxrenew

第33章 IdM パスワードポリシーの定義

本章では、Identity Management (IdM) パスワードポリシーと、Ansible Playbook を使用して IdM に新規パスワードポリシーを追加する方法を説明します。

33.1. パスワードポリシーとは

パスワードポリシーは、パスワードが満たさなければならない一連のルールです。たとえば、パスワードポリシーでは、パスワードの最小限の長さと最大有効期間を定義できます。このポリシーの影響を受けるすべてのユーザーには、十分な長いパスワードを設定し、指定した条件を満たすのに十分な頻度を変更する必要があります。これにより、パスワードポリシーにより、ユーザーのパスワードを検出および誤用するリスクが軽減されます。

33.2. IdM のパスワードポリシー

パスワードは、Identity Management (IdM) ユーザーが IdM Kerberos ドメインに対して認証する最も一般的な方法です。パスワードポリシーは、これらの IdM ユーザーパスワードが満たする必要のある要件を定義します。

注記

IdM パスワードポリシーは基礎となる LDAP ディレクトリーで設定されますが、Kerberos Key Distribution Center (KDC) はパスワードポリシーを強制します。

パスワードポリシー属性 は、IdM でパスワードポリシーを定義するために使用できる属性を一覧表示します。

表33.1 パスワードポリシーの属性

属性説明

Max lifetime

パスワードのリセットが必要になるまでの、パスワードの有効日数の上限です。

Max lifetime = 90

ユーザーパスワードは 90 日間のみ有効です。その後、IdM は変更を求めるプロンプトを表示します。

Min lifetime

パスワード変更操作間で渡す必要のある最小時間 (時間)。

Min lifetime = 1

ユーザーがパスワードを変更したら、再度変更する前に少なくとも 1 時間待機する必要があります。

履歴サイズ

保存される以前のパスワードの数。ユーザーは、パスワード履歴からパスワードを再利用できませんが、保存されていない古いパスワードを再利用できます。

History size = 0

この場合、パスワード履歴は空になり、ユーザーは以前のパスワードのいずれかを再利用できます。

文字クラス

パスワードで使用する文字クラスの数。文字クラスは次のとおりです。

* 大文字

* 小文字

* Digits

* コンマ (,)、ピリオド (.)、アスタリスク (*) などの特殊文字

* 他の UTF-8 文字

文字を複数回使用すると、文字クラスが 1 つずつ減少します。以下に例を示します。

* Secret1 には、大文字、小文字、数字の 3 つの文字クラスがあります。

* Secret111 には、大文字、小文字、数字、および -1 ペナルティの 2 つの文字クラスがあります。1 を 繰り返し使用できます。

Character classes = 0

必要なクラスのデフォルト数は 0 です。番号を設定するには、--minclasses オプションを指定して ipa pwpolicy-mod コマンドを実行します。

この表の下にある 重要 注記も参照してください。

最小の長さ

パスワードの最小文字数。

Min length = 8

8 文字未満のパスワードは使用できません。

Max failures

IdM がユーザーアカウントをロックするまでのログイン試行失敗の最大数。

Max failures = 6

ユーザーが間違ったパスワードを 7 回入力すると、IdM はユーザーアカウントをロックします。

Failure reset interval

失敗したログイン試行回数を IdM がリセットするまでの時間 (秒単位)。

Failure reset interval = 60

Max failures で定義されたログイン試行回数が 1 分以上経過すると、ユーザーはユーザーアカウントのロックを危険にさらすことなく再ログインを試みることができます。

ロックアウト期間

Max failures で定義された回数のログイン試行に失敗した後にユーザーアカウントがロックされる時間 (秒単位)。

Lockout duration = 600

アカウントがロックされているユーザーは、10 分間ログインできません。

重要

国際文字や記号にアクセスできないハードウェアセットがある場合には、文字クラス要件に英語と共通記号を使用してください。パスワードの文字クラスポリシーの詳細は、Red Hat ナレッジベースの「What characters are valid in a password?」を参照してください。

33.3. Ansible Playbook を使用して IdM にパスワードポリシーが存在することを確認する

本セクションでは、Ansible Playbook を使用して、Identity Management (IdM) にパスワードポリシーが存在することを確認する方法を説明します。

IdM におけるデフォルトの global_policy パスワードポリシーでは、パスワード内の異なる文字クラスの数は 0 に設定されます。履歴サイズも 0 に設定されます。

以下の手順に従って、Ansible Playbook を使用して、IdM グループにより強力なパスワードポリシーを適用します。

注記

IdM グループのパスワードポリシーのみを定義できます。個々のユーザーのパスワードポリシーを定義することはできません。

前提条件

  • Ansible コントローラーに ansible-freeipa パッケージがインストールされている。
  • IdM 管理者パスワードが分かっている。
  • IdM にパスワードポリシーが存在することを確認するグループ。

手順

  1. inventory.file などのインベントリーファイルを作成し、[ipaserver] セクションに IdM サーバーの FQDN を定義します。

    [ipaserver]
    server.idm.example.com
  2. 存在するパスワードポリシーを定義する Ansible Playbook ファイルを作成します。この手順を単純化するには、/usr/share/doc/ansible-freeipa/playbooks/pwpolicy/pwpolicy_present.yml ファイルの例をコピーして変更します。

    ---
    - name: Tests
      hosts: ipaserver
      become: true
      gather_facts: false
    
      tasks:
      - name: Ensure presence of pwpolicy for group ops
        ipapwpolicy:
          ipaadmin_password: Secret123
          name: ops
          minlife: 7
          maxlife: 49
          history: 5
          priority: 1
          lockouttime: 300
          minlength: 8
          minclasses: 4
          maxfail: 3
          failinterval: 5

    個別の変数の意味は、「パスワードポリシーの属性」を参照してください。

  3. Playbook を実行します。

    $ ansible-playbook -v -i path_to_inventory_directory/inventory.file path_to_playbooks_directory_/new_pwpolicy_present.yml

Ansible Playbook を使用して、ops グループのパスワードポリシーが IdM に存在することを確認している。

重要

ops パスワードポリシーの優先度は 1に設定され、global_policy パスワードポリシーには優先度が設定されません。このため、ops ポリシーは ops グループの global_policy に自動的に置き換えられ、即座に実施されます。

global_policy は、ユーザーにポリシーが設定されていないとフォールバックポリシーとして機能し、そのポリシーよりも優先することはできません。

関連情報

  • Ansible を使用して IdM でパスワードポリシーを定義する方法および Playbook 変数の詳細は、/usr/share/doc/ansible-freeipa/ ディレクトリーにある README-pwpolicy.md Markdown ファイルを参照してください。
  • IdM でパスワードポリシーの優先度がどのように機能するかの詳細は、RHEL 7 ドキュメントの「パスワードポリシーの優先度」を参照してください。

第34章 IdM クライアントの IdM ユーザーへの sudo アクセスの許可

34.1. IdM クライアントの sudo アクセス

システム管理者は、root 以外のユーザーに、通常 root ユーザー用に予約されている管理コマンドを実行できるようにする sudo アクセスを付与できます。その結果、ユーザーが、通常、root ユーザー用に予約される管理コマンドを実行する場合は、コマンドの前に sudo を付けることができます。パスワードを入力すると、そのコマンドは root ユーザーとして実行されます。

Red Hat Enterprise Linux (RHEL) 8 ホストが Identity Management (IdM) クライアントとして登録されている場合は、以下の方法で、どの IdM ユーザーがホストでどのコマンドを実行できるかを定義する sudo ルールを指定できます。

  • /etc/sudoers ファイルでローカルに
  • IdM で中心的に

本章では、IdM Web UI を使用して IdM クライアント用の中心的な sudo ルールを作成する方法を説明します。RHEL 8 ホストでローカルの sudo ルールを作成する方法は、「sudo アクセスの管理」を参照してください。

IdM コマンドラインインターフェースを使用して、中心的な IdM の sudo ルールを定義することもできます。

34.2. IdM Web UI で IdM クライアントの IdM ユーザーへの sudo アクセスの許可

Identity Management (IdM) では、特定の IdM ホストの IdM ユーザーアカウントの特定コマンドに sudo アクセスを付与できます。最初に sudo コマンドを追加してから、複数のコマンドに対して sudo ルールを作成します。

idmclient マシンで /usr/sbin/reboot コマンドを実行する権限を idm_user に付与する idm_user_reboot sudo ルールを作成するには、この手順を行います。

前提条件

  • IdM 管理者としてログインしている。
  • IdM で idm_user のユーザーアカウントを作成し、ユーザーのパスワードを作成してそのアカウントのロックを解除している。コマンドラインインターフェースを使用して新しい IdM ユーザーを追加する方法は、「コマンドラインでユーザーの追加」を参照してください。
  • idmclient にローカルの idm_userアカウントが作成されていません。Idm_user ユーザーは、ローカルの /etc/passwd ファイルには表示されません。

手順

  1. sudo コマンドの IdM データベースに /usr/sbin/reboot コマンドを追加します。

    1. PolicySudoSudo Commands の順に移動します。
    2. 右上にある Add をクリックして、Add sudo command ダイアログボックスを開きます。
    3. sudo: /usr/sbin/reboot を使用してユーザーが実行できるコマンドを入力します。

      図34.1 IdM sudo コマンドの追加

      IdM sudo コマンドの追加
    4. Add をクリックします。
  2. 新しい sudo コマンドエントリーを使用して sudo ルールを作成し、idm_useridmclient マシンを再起動できるようにします。

    1. PolicySudoSudo ルールに移動します。
    2. 右上にある Add をクリックして、Add sudo rule ダイアログボックスを開きます。
    3. sudo ルールの名前を入力します (idm_user_reboot)。
    4. Add and Edit をクリックします。
    5. ユーザーを指定します。

      1. Who セクションで、ラジオボタン Specified Users and Groups を選択します。
      2. サブセクション User category the rule applies toAdd をクリックして、Add users into sudo rule "idm_user_reboot" ダイアログボックスを開きます。
      3. Add users into sudo rule "idm_user_reboot" ダイアログボックスにある Available 列で、idm_user チェックボックスを選択し、Prospective 列に移動します。
      4. Add をクリックします。
    6. ホストを指定します。

      1. Access this host セクションで、Specified Hosts and Groups ラジオボタンを確認します。
      2. サブセクション Host category this rule applies toAdd をクリックして、Add hosts into sudo rule "idm_user_reboot" ダイアログボックスを開きます。
      3. Add hosts into sudo rule "idm_user_reboot" ダイアログボックスにある Available 列で、idmclient.idm.example.com チェックボックスを選択し、Prospective 列に移動します。
      4. Add をクリックします。
      1. コマンドを指定します。

        1. Run Commands セクションの Command category the rule applies to サブセクションで、Specified Commands and Groups ラジオボタンを確認します。
        2. サブセクション Sudo Allow CommandsAdd をクリックして、Add allow sudo commands into sudo rule "idm_user_reboot" ダイアログボックスを開きます。
        3. Add allow sudo commands into sudo rule "idm_user_reboot" ダイアログボックスにある Available 列で、/usr/sbin/reboot チェックボックスを選択し、Prospective 列に移動します。
        4. Add をクリックして、idm_sudo_reboot ページに戻ります。

          図34.2 IdM sudo ルールの追加

          IdM sudo ルール WebUI
    7. 左上にある Save をクリックします。

新しいルールはデフォルトで有効になります。

検証手順

idm_usersudo を使用して idmclient を再起動できることを確認して、IdM サーバーに設定した sudoルールが idmclient で機能することを確認します。サーバーからクライアントへの変更の伝播には数分かかる場合があることに注意してください。

  1. idmclientidm_user としてログインします。
  2. sudo を使用してマシンを再起動します。プロンプトが表示されたら、idm_user のパスワードを入力します。

    $ sudo /usr/sbin/reboot
    [sudo] password for idm_user:

sudo が正しく設定されていると、マシンが再起動します。

34.3. Ansible Playbook を使用した IdM クライアントでの IdM ユーザーの sudo アクセスの確保

Identity Management (IdM) では、特定の IdM ホストの IdM ユーザーアカウントに sudo アクセスが付与されるようにできます。

この手順では、idm_user_reboot という名前の sudo ルールが存在することを確認します。このルールは、idmclient マシンで /usr/sbin/reboot コマンドを実行するパーミッションを idm_user に付与します。

前提条件

手順

  1. inventory.file などのインベントリーファイルを作成し、そこに ipaservers を定義します。

    [ipaservers]
    server.idm.example.com
  2. sudo コマンドを追加します。

    1. ensure-reboot-sudocmd-is-present.yml Ansible Playbook を作成し、sudo コマンドの IdM データベースに /usr/sbin/reboot コマンドが存在するようにします。この手順を単純化するには、/usr/share/doc/ansible-freeipa/playbooks/sudocmd/ensure-sudocmd-is-present.yml ファイルのサンプルをコピーして変更できます。

      ---
      - name: Playbook to manage sudo command
        hosts: ipaserver
        become: true
      
        tasks:
        # Ensure sudo command is present
        - ipasudocmd:
            ipaadmin_password: Secret123
            name: /usr/sbin/reboot
            state: present
    2. Playbook を実行します。

      $ ansible-playbook -v -i path_to_inventory_directory/inventory.file path_to_playbooks_directory/ensure-reboot-sudocmd-is-present.yml
  3. コマンドを参照する sudo ルールを作成します。

    1. sudo コマンドエントリーを使用して sudo ルールが存在することを確認する ensure-sudorule-for-idmuser-on-idmclient-is-present.yml Ansible Playbook を作成します。sudo ルールは、idm_useridmclient マシンを再起動することを許可します。この手順を単純化するには、/usr/share/doc/ansible-freeipa/playbooks/sudorule/ensure-sudorule-is-present.yml ファイルのサンプルをコピーして変更できます。

      ---
      - name: Tests
        hosts: ipaserver
        become: true
      
        tasks:
        # Ensure a sudorule is present granting idm_user the permission to run /usr/sbin/reboot on idmclient
        - ipasudorule:
            ipaadmin_password: Secret123
            name: idm_user_reboot
            description: A test sudo rule.
            allow_sudocmd: /usr/sbin/reboot
            host: idmclient.idm.example.com
            user: idm_user
            state: present
    2. Playbook を実行します。

      $ ansible-playbook -v -i path_to_inventory_directory/inventory.file path_to_playbooks_directory/ensure-sudorule-for-idmuser-on-idmclient-is-present.yml

検証手順

idm_usersudo を使用して idmclient を再起動して、IdM サーバーに存在する sudo ルールが idmclient で機能することを確認します。サーバーに加えられた変更がクライアントで反映されるまで数分の時間がかかる場合があります。

  1. idmclientidm_user としてログインします。
  2. sudo を使用してマシンを再起動します。プロンプトが表示されたら、idm_user のパスワードを入力します。

    $ sudo /usr/sbin/reboot
    [sudo] password for idm_user:

sudo が正しく設定されている場合、マシンが再起動します。

その他の資料

  • Playbook 変数の説明を含む Ansible Playbook を使用して IdM の sudo コマンド、コマンドグループ、およびルールを適用する方法は、/usr/share/doc/ansible-freeipa/ ディレクトリーで利用可能な README-sudocmd.md、README-sudocmdgroup.md、および README-sudorule.md Markdown ファイルを参照してください。

第35章 Ansible Playbook を使用して IdM にホストベースのアクセス制御ルールが存在することを確認する

本章では、Identity Management (IdM) のホストベースのアクセスポリシーと Ansible を使用して定義する方法を説明します。

Ansible は、システムの設定、ソフトウェアのデプロイ、ローリング更新の実行に使用する自動化ツールです。これには、Identity Management (IdM) のサポートが含まれます。

35.1. IdM のホストベースのアクセス制御ルール

ホストベースのアクセス制御 (HBAC) ルールは、サービスグループ内のサービスまたはサービスを使用して、どのユーザーまたはグループがどのホストまたはホストグループにアクセスできるかを定義します。システム管理者は、HBAC ルールを使用して以下の目標を達成できます。

  • ドメイン内の指定されたシステムへのアクセスを、特定のユーザーグループのメンバーに制限します。
  • ドメイン内のシステムにアクセスするために特定のサービスのみを使用できます。

デフォルトでは、IdM は allow_all という名前のデフォルトの HBAC ルールで設定されます。これは、IdM ドメイン内のすべて の関連サービスを介して、全ユーザーの全ホストへのユニバーサルアクセスを意味します。

デフォルトの allow_all ルールを独自の HBAC ルールセットに置き換えることで、異なるホストへのアクセスを微調整できます。アクセス制御管理を集中化し、簡素化するには、個別のユーザー、ホスト、またはサービスの代わりに、ユーザーグループ、ホストグループ、またはサービスグループに HBAC ルールを適用できます。

35.2. Ansible Playbook を使用して IdM に HBAC ルールが存在することを確認する

本セクションでは、Ansible Playbook を使用して、Identity Management (IdM) にホストベースのアクセス制御 (HBAC) ルールが存在することを確認する方法を説明します。

前提条件

手順

  1. inventory.file などのインベントリーファイルを作成し、そのファイルに ipaserver を定義します。

    [ipaserver]
    server.idm.example.com
  2. 確認する HBAC ポリシーを定義する Ansible Playbook ファイルを作成します。この手順を単純化するには、/usr/share/doc/ansible-freeipa/playbooks/hbacrule/ensure-hbacrule-allhosts-present.yml ファイルのサンプルをコピーして変更できます。

    ---
    - name: Playbook to handle hbacrules
      hosts: ipaserver
      become: true
    
      tasks:
      # Ensure idm_user can access client.idm.example.com via the sshd service
      - ipahbacrule:
          ipaadmin_password: Secret123
          name: login
          user: idm_user
          host: client.idm.example.com
          hbacsvc:
          - sshd
          state: present
  3. Playbook を実行します。

    $ ansible-playbook -v -i path_to_inventory_directory/inventory.file path_to_playbooks_directory/ensure-new-hbacrule-present.yml

検証手順

  1. 管理者として IdM Web UI にログインします。
  2. PolicyHost-Based-Access-ControlHBAC Test と選択します。
  3. Who タブで idm_user を選択します。
  4. Accessing タブで client.idm.example.com を選択します。
  5. Via サービス タブで sshd を選択します。
  6. Rules タブで login を選択します。
  7. Run test タブで Run test ボタンをクリックします。ACCESS GRANTED が表示されると、HBAC ルールが正常に実装されます。

関連情報

  • HBAC サービス、サービスグループ、および Ansible を使用したルールの設定に関する詳細情報および例は、README-hbacsvc.md、README-hbacsvcgroup.md、および README-hbacrule.md Markdown ファイルを参照してください。これらのファイルは、/usr/share/doc/ansible-freeipa ディレクトリーにあります。また、/usr/share/doc/ansible-freeipa/playbooks ディレクトリーの関連サブディレクトリーで利用可能な Playbook も参照してください。

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

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

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

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

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

36.1. IdM の認証局

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

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

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

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

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

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

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

特徴

Kerberos

X.509

認証

はい

はい

プライバシー

任意

はい

インテグリティー

任意

はい

関係する暗号の種類

対称

非対称

デフォルトの有効性

短い (1 日)

長い (2 年)

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

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

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

  • 通常、スマートカードの秘密鍵を保護