Menu Close
Settings Close

Language and Page Formatting Options

IdM ユーザーグループのホストとアクセス制御ルールの管理

Red Hat Enterprise Linux 9

ユーザーとホストの設定、グループでの管理、およびホストベース (HBAC) とロールベースのアクセス制御 (RBAC) ルールによるアクセスの制御

概要

このドキュメントコレクションでは、Red Hat Enterprise Linux 8 の Identity Management でユーザー、グループ、およびホストを作成し、HBAC および RBAC ルールを介してこれらのホストへのアクセスを管理する方法について説明します。

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。まずは、マスター (master)、スレーブ (slave)、ブラックリスト (blacklist)、ホワイトリスト (whitelist) の 4 つの用語の置き換えから始めます。この取り組みは膨大な作業を要するため、今後の複数のリリースで段階的に用語の置き換えを実施して参ります。詳細は、弊社の CTO、Chris Wright のメッセージ を参照してください。

Red Hat ドキュメントへのフィードバック

当社のドキュメントに関するご意見やご感想をお寄せください。また、改善点があればお知らせください。

特定の文章に関するコメントの送信

  1. Multi-page HTML 形式でドキュメントを表示し、ページが完全にロードされてから右上隅に Feedback ボタンが表示されていることを確認します。
  2. カーソルを使用して、コメントを追加するテキスト部分を強調表示します。
  3. 強調表示されたテキストの近くに表示される Add Feedback ボタンをクリックします。
  4. フィードバックを追加し、Submit をクリックします。

Bugzilla からのフィードバック送信 (アカウントが必要)

  1. Bugzilla の Web サイトにログインします。
  2. Version メニューから正しいバージョンを選択します。
  3. Summary フィールドにわかりやすいタイトルを入力します。
  4. Description フィールドに、ドキュメントの改善に関するご意見を記入してください。ドキュメントの該当部分へのリンクも追加してください。
  5. Submit Bug をクリックします。

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

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

前提条件

  • IdM サーバーをインストールしていて、アクセス可能である。

    詳細は、Installing Identity Management を参照してください。

  • IPA コマンドラインインターフェイスを使用する場合は、有効な Kerberos チケットを使用して IdM に対してを認証している。

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

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

新しいユーザーを追加するための ipa user-add コマンドなど、IdM を管理するための多くのサブコマンドがサポートされています。

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

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

1.2. IPA のヘルプとは

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

IPA コマンドラインインターフェイス (CLI) は、読み込んだ IdM プラグインモジュールから、利用可能なヘルプトピックを生成します。IPA ヘルプユーティリティーを使用するには、以下が必要です。

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

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

さまざまな ipa help のユースケースに対して、次のオプションを使用できます。

$ ipa help [TOPIC | COMMAND | topics | commands]
  • [] - 括弧は、すべてのパラメーターが任意であることを示しており、ipa help のみを入力すれば、コマンドが実行できます。
  • |  - パイプ文字は または の意味になります。したがって、基本的な ipa help コマンドを使用して、TOPICCOMMANDtopics または commands を指定できます。

    • topics — コマンド ipa help topics を実行して、IPA ヘルプでカバーされている usercertserver などのトピックのリストを表示できます。
    • TOPIC — 大文字の TOPIC は変数になります。したがって、特定のトピック (ipa help user など) を指定できます。
    • commands — コマンド ipa help commands を入力して、user-addca-enableserver-show などの IPA ヘルプでカバーされているコマンドのリストを表示できます。
    • COMMAND — 大文字の COMMAND は変数になります。したがって、ipa help user-add などの特定のコマンドを指定できます。

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

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

手順

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

    $ ipa help topics
  3. トピックの 1 つを選択し、ipa help [topic_name] のパターンに従ってコマンドを作成します。topic_name 文字列の代わりに、前の手順でリストしたトピックの 1 つを追加します。

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

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

    $ ipa help user | less

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

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

1.4. IPA help コマンドの使用

次の手順では、コマンドラインインターフェイスで IPA help コマンドを作成する方法について説明します。

手順

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

    $ ipa help commands
  3. コマンドの 1 つを選択し、ipa help <COMMAND> のパターンに従ってヘルプコマンドを作成します。<COMMAND> 文字列の代わりに、前の手順でリストしたコマンドの 1 つを追加します。

    $ ipa help user-add

関連情報

  • ipa の man ページ

1.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] も含まれます。

1.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 コマンドでパスワードを追加できます。

関連情報

  • パラメーターの詳細は、ipa help user-add コマンドを実行してください。

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

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

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

前提条件

  • ユーザーアカウントを変更するには、管理者権限が必要です。

手順

  1. 端末を開き、IdM サーバーに接続します。
  2. ipa user-mod コマンドを入力し、変更するユーザーと、パスワードを追加するための --password などのオプションを指定します。

    $ ipa user-mod euser --password

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

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

IPA CLI は次の出力を出力します。

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

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

関連情報

  • パラメーターの詳細は、ipa help user-mod コマンドを実行してください。

1.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} ...

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

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

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

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

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

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

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

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

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

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

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

A flow chart displaying 4 items: Active users - Stage users - Preserved users - Deleted users. Arrows communicate the relationships between each kind of user: Active users can be "preserved" as Preserved users. Preserved users can be "restored" as Active users. Preserved users can be "staged" as Stage users and Stage users can be "activated" into Active users. All users can be deleted to become "Deleted users".

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

重要

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

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

警告

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

警告

ローカルユーザーを IdM に追加しないでください。Name Service Switch (NSS) は、ローカルユーザーとグループを解決する前に、IdM ユーザーとグループを常に解決します。つまり、たとえば IdM グループのメンバーシップは、ローカルユーザーでは機能しません。

2.2. コマンドラインを使用したユーザーの追加

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

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

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

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

注記

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

前提条件

  • IdM、またはユーザー管理者ロールを管理する管理者権限
  • Kerberos チケットを取得している。詳細は、Using kinit to log in to IdM manually を参照してください。

手順

  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 user-find

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

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

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

前提条件

  • IdM、またはユーザー管理者ロールを管理する管理者権限
  • Kerberos チケットを取得している。詳細は、Using kinit to log in to IdM manually を参照してください。

手順

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

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

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

$ ipa user-find

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

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

ユーザーアカウントを削除しても、保存しておくことはできますが、後で復元するオプションはそのままにしておきます。ユーザーアカウントを保持するには、ipa user-del コマンドまたは ipa stageuser-del コマンドで、--preserve オプションを使用します。

前提条件

  • IdM、またはユーザー管理者ロールを管理する管理者権限
  • Kerberos チケットを取得している。詳細は、Using kinit to log in to IdM manually を参照してください。

手順

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

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

    ユーザーアカウントが削除されたという出力が表示されたにもかかわらず、アカウントは保持されています。

2.5. コマンドラインを使用したユーザーの削除

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

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

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

$ ipa user-del --continue user1 user2 user3

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

前提条件

  • IdM、またはユーザー管理者ロールを管理する管理者権限
  • Kerberos チケットを取得している。詳細は、Using kinit to log in to IdM manually を参照してください。

手順

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

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

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

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

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

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

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

前提条件

  • IdM、またはユーザー管理者ロールを管理する管理者権限
  • Kerberos チケットを取得している。詳細は、Using kinit to log in to IdM manually を参照してください。

手順

  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 user-find

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

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

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

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

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

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

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

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

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

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

A flow chart displaying 4 items: Active users - Stage users - Preserved users - Deleted users. Arrows communicate the relationships between each kind of user: Active users can be "preserved" as Preserved users. Preserved users can be "restored" as Active users. Preserved users can be "staged" as Stage users and Stage users can be "activated" into Active users. All users can be deleted to become "Deleted users".

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

重要

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

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

警告

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

警告

ローカルユーザーを IdM に追加しないでください。Name Service Switch (NSS) は、ローカルユーザーとグループを解決する前に、IdM ユーザーとグループを常に解決します。つまり、たとえば IdM グループのメンバーシップは、ローカルユーザーでは機能しません。

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

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

注記

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

前提条件

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

手順

  1. IdM Web UI にログインします。
  2. ユーザー → ステージユーザー タブに移動します。

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

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

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

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

    Screenshot of the "Add stage user" pop-up window with the "New Password" the "Verify Password" fields filled in. The "Add" button is at the bottom left.

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

Screenshot of the IdM Web UI showing user entries in the Stage Users table. This is selected from the Identity tab - the Users sub-tab - and the Stage users category listed on the left.

注記

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

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

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

前提条件

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

手順

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

    Screenshot of the IdM Web UI showing user entries in the "Stage Users" table. This is selected from the Identity tab - the Users sub-tab - and the Stage users category listed on the left.

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

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

Screenshot of the IdM Web UI showing the "staged.user" user entry in the "Active Users" table. Its status is "enabled."

注記

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

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

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

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

注記

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

前提条件

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

手順

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

    Screenshot of the "Active Users" page with a table displaying attributes for several users such as User login - First name - Last name - Status - UID - Email address - Telephone Number - Job Title. The entry for the "euser" account has been highlighted and so have the "Enable" and "Disable" buttons at the top right.

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

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

Screenshot of the same "Active Users" page with the table displaying attributes for several users. The "euser" account is now greyed-out and shows "Disabled" in its "Status" column.

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

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

前提条件

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

手順

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

    Screenshot of the "Active Users" page with a table displaying attributes for several users such as User login - First name - Last name - Status - UID - Email address - Telephone Number - Job Title. The entry for the "euser" account has been highlighted and so have the "Enable" and "Disable" buttons at the top right.

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

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

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

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

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

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

注記

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

前提条件

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

手順

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

    A screenshot of the "Active Users" page displaying a table of users. The checkbox for the entry for the "preserved.user" account has been checked and the "Delete" button at the top is highlighted.

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

    A screenshot of a pop-up window titled "Remove users." The contents say "Are you sure you want to delete selected entries?" and specifies "preserved.user" below. There is a label "Delete mode" with two radial options: "delete" and "preserve" (which is selected). There are "Delete" and "Cancel" buttons at the bottom right corner of the window.

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

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

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

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

前提条件

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

手順

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

    A screenshot of the "Preserved users" page displaying a table of users and their attributes. The checkbox next to one user entry is checked and the "Restore" button at the top right is highlighted.

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

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

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

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

以下を削除できます。

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

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

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

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

前提条件

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

手順

  1. IdM Web UI にログインします。
  2. ユーザー → アクティブユーザー タブに移動します。

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

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

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

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

Ansible Playbook を使用して IdM のユーザーを管理できます。ユーザーのライフサイクル を示した後、本章では以下の操作に Ansible Playbook を使用する方法を説明します。

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

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

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

A flow chart displaying 4 items: Active users - Stage users - Preserved users - Deleted users. Arrows communicate the relationships between each kind of user: Active users can be "preserved" as Preserved users. Preserved users can be "restored" as Active users. Preserved users can be "staged" as Stage users and Stage users can be "activated" into Active users. All users can be deleted to become "Deleted users".

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

重要

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

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

警告

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

警告

ローカルユーザーを IdM に追加しないでください。Name Service Switch (NSS) は、ローカルユーザーとグループを解決する前に、IdM ユーザーとグループを常に解決します。つまり、たとえば IdM グループのメンバーシップは、ローカルユーザーでは機能しません。

4.2. Ansible Playbook を使用して IdM ユーザーを存在させる手順

以下の手順では、Ansible Playbook を使用して IdM にユーザーを 1 つ存在させる方法を説明します。

前提条件

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

手順

  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: 名前 (名) の文字列
    • 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 に存在しています。

4.3. 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_2idm_user_3 を作成し、idm_user_1 のパスワードを Password123 として追加します。

    ---
    - 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 が実行されるたびにユーザーパスワードを再設定します。最後に 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 に存在しています。

4.4. 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: MySecret123
          users: "{{ users }}"
  3. users.json ファイルを作成し、IdM ユーザーを追加します。この手順を簡素化するには、/usr/share/doc/ansible-freeipa/playbooks/user/users.json ファイルのサンプルをコピーして変更できます。たとえば、ユーザー idm_user_1idm_user_2idm_user_3 を作成し、idm_user_1 のパスワードを Password123 として追加します。

    {
      "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 に存在しています。

4.5. 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_2idm_user_3 を削除するには、次のコマンドを実行します。

    ---
    - name: Playbook to handle users
      hosts: ipaserver
      become: true
    
      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 に存在しません。

4.6. 関連情報

  • /usr/share/doc/ansible-freeipa/ ディレクトリーの README-user.md Markdown ファイルを参照してください。
  • /usr/share/doc/ansible-freeipa/playbooks/user ディレクトリーのサンプルの Ansible Playbook を参照してください。

第5章 IdM でのユーザーパスワードの管理

5.1. IdM ユーザーパスワードは誰がどのように変更するのか

他のユーザーのパスワードを変更するパーミッションのない通常ユーザーは、独自の個人パスワードのみを変更できます。新しいパスワードは、そのユーザーがメンバーとなっているグループに適用される IdM パスワードポリシーに合致する必要があります。パスワードポリシーの設定方法の詳細は、IdM パスワードポリシーの定義 を参照してください。

管理者およびパスワード変更権限を持つユーザーは、新しいユーザーに初期パスワードを設定し、既存のユーザーのパスワードをリセットできます。これらのパスワードには、以下が該当します。

注記

LDAP Directory Manager(DM) ユーザーは、LDAP ツールを使用してユーザーパスワードを変更できます。新しいパスワードは、任意の IdM パスワードポリシーを上書きできます。DM によって設定されたパスワードは最初のログイン後に有効期限が切れません。

5.2. IdM Web UI でのユーザーパスワードの変更

Identity Management (IdM) ユーザーは、IdM Web UI でユーザーパスワードを変更できます。

前提条件

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

手順

  1. 右上隅の User name → Change password をクリックします。

    図5.1 パスワードのリセット

    ユーザーが自分の pwd を変更する
  2. 現在のパスワードおよび新しいパスワードを入力します。

5.3. IdM Web UI での別のユーザーのパスワードのリセット

Identity Management (IdM) の管理ユーザーは、IdM Web UI で他のユーザーのパスワードを変更できます。

前提条件

  • 管理ユーザーとして IdM Web UI にログインしている。

手順

  1. IdentityUsers を選択します。
  2. 編集するユーザー名をクリックします。
  3. ActionsReset password をクリックします。

    図5.2 パスワードのリセット

    pwd reset1
  4. 新しいパスワードを入力し、Reset Password をクリックします。

    図5.3 新しいパスワードの確認

    pwd reset2

5.4. Directory Manager ユーザーパスワードのリセット

Identity Management (IdM) Directory Manager のパスワードを紛失した場合は、リセットできます。

前提条件

  • IdM サーバーに root にアクセスできる。

手順

  1. pwdhash コマンドを使用して、新しいパスワードハッシュを生成します。以下に例を示します。

    # pwdhash -D /etc/dirsrv/slapd-IDM-EXAMPLE-COM password
    {PBKDF2_SHA256}AAAgABU0bKhyjY53NcxY33ueoPjOUWtl4iyYN5uW...

    Directory Server 設定へのパスを指定すると、nsslapd-rootpwstoragescheme 属性に設定されたパスワードストレージスキームが自動的に使用され、新しいパスワードを暗号化します。

  2. トポロジー内のすべての IdM サーバーで、以下の手順を実行します。

    1. サーバーにインストールされている IdM サービスをすべて停止します。

      # ipactl stop
    2. /etc/dirsrv/IDM-EXAMPLE-COM/dse.ldif ファイルーを編集し、nsslapd-rootpw 属性を、pwdhash コマンドで生成された値に設定します。

      nsslapd-rootpw: {PBKDF2_SHA256}AAAgABU0bKhyjY53NcxY33ueoPjOUWtl4iyYN5uW...
    3. サーバーにインストールされている IdM サービスをすべて起動します。
    # ipactl start

5.5. IdM CLI でのユーザーパスワードの変更または別のユーザーのパスワードのリセット

Identity Management (IdM) コマンドラインインターフェイス (CLI) を使用して、ユーザーパスワードを変更できます。管理ユーザーの場合は、CLI を使用して別のユーザーのパスワードをリセットできます。

前提条件

  • IdM ユーザーの TGT (Ticket-Granting Ticket) を取得している。
  • 別のユーザーのパスワードをリセットする場合は、IdM の管理ユーザーの TGT を取得している必要がある。

手順

  • ユーザーの名前と --password オプションを指定して、ipa user-mod コマンドを入力します。このコマンドにより、新しいパスワードの入力が求められます。

    $ ipa user-mod idm_user --password
    Password:
    Enter Password again to verify:
    --------------------
    Modified user "idm_user"
    --------------------
    ...
注記

ipa user-mod の代わりに ipa passwd idm_user を使用することもできます。

5.6. 次回のログイン時にパスワード変更を求められることなく、IdM でパスワードリセットを有効にする

デフォルトでは、管理者が別のユーザーのパスワードをリセットすると、初回のログインに成功したらパスワードが期限切れになります。IdM Directory Manager では、各 IdM 管理者に次の特権を指定できます。

  • 初回ログイン後にパスワードの変更をユーザーに要求することなく、パスワードの変更操作を行うことができます。
  • 強度や履歴の強制が適用されないようにパスワードポリシーをバイパスします。
警告

パスワードポリシーをバイパスすると、セキュリティー上の脅威になる可能性があります。これらの追加の特権を付与するユーザーを選択するときは注意してください。

前提条件

  • Directory Manager のパスワードを把握している。

手順

  1. ドメイン内のすべての Identity Management (IdM) サーバーで、次の変更を行います。

    1. ldapmodify コマンドを実行して、LDAP エントリーを変更します。IdM サーバーの名前と 389 ポートを指定し、Enter キーを押します。

      $ ldapmodify -x -D "cn=Directory Manager" -W -h server.idm.example.com -p 389
      Enter LDAP Password:
    2. Directory Manager パスワードを入力します。
    3. ipa_pwd_extop パスワード同期エントリーの識別名を入力し、Enter キーを押します。

      dn: cn=ipa_pwd_extop,cn=plugins,cn=config
    4. 変更の modify 型を指定し、Enter キーを押します。

      changetype: modify
    5. LDAP が実行する修正のタイプと、その属性を指定します。Enter キーを押します。

      add: passSyncManagersDNs
    6. passSyncManagersDNs 属性に管理ユーザーアカウントを指定します。属性は多値です。たとえば、admin ユーザーに、Directory Manager の電源をリセットするパスワードを付与するには、次のコマンドを実行します。

      passSyncManagersDNs: \
      uid=admin,cn=users,cn=accounts,dc=example,dc=com
    7. Enter キーを 2 回押して、エントリーの編集を停止します。

手順全体を以下に示します。

$ ldapmodify -x -D "cn=Directory Manager" -W -h server.idm.example.com -p 389
Enter LDAP Password:
dn: cn=ipa_pwd_extop,cn=plugins,cn=config
changetype: modify
add: passSyncManagersDNs
passSyncManagersDNs: uid=admin,cn=users,cn=accounts,dc=example,dc=com

passSyncManagerDNs に一覧表示されている admin ユーザーに、追加特権が追加されました。

5.7. IdM ユーザーのアカウントがロックされているかどうかの確認

Identity Management (IdM) 管理者は、IdM ユーザーのアカウントがロックされているかどうかを確認できます。そのためには、ユーザーの最大許容ログイン試行回数と、ユーザーの実際の失敗ログイン回数を比較する必要があります。

前提条件

  • IdM の管理ユーザーの TGT (Ticket-Granting Ticket) を取得している。

手順

  1. ユーザーアカウントのステータスを表示して、失敗したログインの数を確認します。

    $ ipa user-status example_user
    -----------------------
    Account disabled: False
    -----------------------
      Server: idm.example.com
      Failed logins: 8
      Last successful authentication: N/A
      Last failed authentication: 20220229080317Z
      Time now: 2022-02-29T08:04:46Z
    ----------------------------
    Number of entries returned 1
    ----------------------------
  2. 特定のユーザーに許可されたログイン試行回数を表示します。

    1. IdM 管理者として IdM Web UI にログインします。
    2. Identity → Users → Active users タブを開きます。

    A screenshot of the IdM Web UI displaying the "Active Users" page which is a sub-page of the Users sub-menu from the Identity tab.

    1. ユーザー名をクリックして、ユーザー設定を開きます。
    2. パスワードポリシー セクションで、Max failures アイテムを探します。
  3. ipa user-status コマンドの出力に表示されているログイン失敗回数と、IdM Web UI に表示されているMax failures 数を比較します。ログインに失敗した回数が、許可されている最大ログイン試行回数と等しい場合、ユーザーアカウントはロックされます。

5.8. IIdM でのパスワード失敗後のユーザーアカウントのロック解除

ユーザーが間違ったパスワードを一定回数使用してログインしようとすると、Identity Management (IdM) はユーザーアカウントをロックするため、ユーザーはログインできなくなります。セキュリティー上の理由から、IdM では、ユーザーアカウントがロックされていることを示す警告メッセージは表示されません。代わりに、CLI プロンプトがユーザーにパスワードを何度も要求し続ける場合があります。

IdM は、指定した時間が経過した後にユーザーアカウントを自動的にアンロックします。または、以下の手順でユーザーアカウントのロックを手動で解除することもできます。

前提条件

  • IdM 管理ユーザーの Ticket-Granting Ticket を取得している。

手順

  • ユーザーアカウントのロックを解除するには、ipa user-unlock コマンドを実行します。

    $ ipa user-unlock idm_user
    -----------------------
    Unlocked account "idm_user"
    -----------------------

    この後、ユーザーは再度ログインできるようになります。

5.9. IdM のユーザーに対する、最後に成功した Kerberos 認証の追跡の有効化

パフォーマンス上の理由から、Red Hat Enterprise Linux 8 で実行している Identity Management (IdM) には、ユーザーが最後に成功した Kerberos 認証のタイムスタンプが保存されません。そのため、ipa user-status などの特定のコマンドではタイムスタンプが表示されません。

前提条件

  • IdM の管理ユーザーの TGT (Ticket-Granting Ticket) を取得している。
  • 手順を実行している IdM サーバーへの root アクセス権限がある。

手順

  1. 現在有効なパスワードプラグイン機能を表示します。

    # ipa config-show | grep "Password plugin features"
      Password plugin features: AllowNThash, KDC:Disable Last Success

    この出力は、KDC:Disable Last Success プラグインが有効になっていることを示しています。このプラグインにより、最後に成功した Kerberos 認証試行が ipa user-status 出力に表示されなくなります。

  2. 現在有効な ipa config-mod コマンドに、すべての機能の --ipaconfigstring=feature パラメーターを追加します (KDC:Disable Last Success を除く)。

    # ipa config-mod --ipaconfigstring='AllowNThash'

    このコマンドは、AllowNThash プラグインのみを有効にします。複数の機能を有効にするには、機能ごとに --ipaconfigstring=feature パラメーターを個別に指定します。

  3. IdM を再起動します。

    # ipactl restart

第6章 IdM パスワードポリシーの定義

本章では、Identity Management (IdM) パスワードポリシーについて、また、Ansible Playbook を使用して IdM に新規パスワードポリシーを追加する方法を説明します。

6.1. パスワードポリシーとは

パスワードポリシーは、パスワードが満たす必要のある一連のルールです。たとえば、パスワードポリシーでは、パスワードの最小長と最大有効期間を定義できます。このポリシーの対象となる全ユーザーには、十分に長いパスワードを設定して、指定の条件を満たす頻度でパスワードを変更する必要があります。このようにパスワードポリシーを使用することで、ユーザーのパスワードが検出されて悪用されるリスクが軽減されます。

6.2. IdM のパスワードポリシー

パスワードは、Identity Management (IdM) ユーザーが IdM Kerberos ドメインに対して認証する最も一般的な方法です。パスワードポリシーでは、このような IdM ユーザーのパスワードが満たす必要条件を定義します。

注記

IdM パスワードポリシーは基礎となる LDAP ディレクトリーで設定されますが、Kerberos Key Distribution Center (KDC) はパスワードポリシーを強制的に使用します。

パスワードポリシー属性 は、IdM でのパスワードポリシーの定義に使用できる属性を一覧表示します。

表6.1 パスワードポリシーの属性

属性説明

Max lifetime

パスワードのリセットが必要になるまでの、パスワードの有効期間 (日) の上限です。

Max lifetime = 90

ユーザーパスワードは 90 日間のみ有効です。有効期限が経過すると、IdM は変更を求めるプロンプトを表示します。

Min lifetime

パスワードを変更してから次に変更操作を行うまでに最小限開ける必要のある時間。

Min lifetime = 1

ユーザーがパスワードの変更後に、次に変更するまでに最低でも 1 時間待機する必要があります。

History size

保存される以前のパスワード数。パスワードの履歴にあるパスワードを再利用できませんが、保存されていない以前のものは使用できます。

History size = 0

この場合、パスワード履歴は空になり、ユーザーは以前のパスワードをどれでも再利用できます。

Character classes

パスワードで使用する必要のある文字クラスの数。文字クラスは次のとおりです。

* 大文字

* 小文字

* 数字

* コンマ (,)、ピリオド (.)、アスタリスク (*) などの特殊文字

* 他の UTF-8 文字

1 つの文字を複数回連続で使用すると、文字クラスが 1 つ減少します。以下に例を示します。

* Secret1 には、大文字、小文字、数字の 3 つの文字クラスがあります。

* Secret111 には、大文字、小文字、数字が含まれていますが、1 を 繰り返し使用使用したため、ペナルティが -1 で文字クラスが 2 つになりります。

Character classes = 0

必要なクラスのデフォルト数は 0 です。番号を設定するには、--minclasses オプションを指定して ipa pwpolicy-mod コマンドを実行します。

この表の下に記載されている 重要 の注意事項も併せて参照してください。

Min length

パスワードの最小長。

追加のパスワードポリシーオプション のいずれかが設定されている場合、Min length オプションに設定されている値に関係なく、パスワードの最小長は 6 文字になります。

Min length = 8

8 文字未満のパスワードは使用できません。

Max failures

IdM がユーザーアカウントをロックするまでのログイン試行の最大失敗数。

Max failures = 6

ユーザーがパスワードを誤って 7 回入力すると、IdM はユーザーアカウントをロックします。

Failure reset interval

失敗したログイン試行回数を IdM がリセットするまでの時間 (秒単位)。

Failure reset interval = 60

Max failures で定義されたログイン試行回数が 1 分以上経過すると、ユーザーはユーザーアカウントがロックされる心配なく再ログインを試みることができます。

Lockout duration

Max failures で定義された回数のログイン試行に失敗した後にユーザーアカウントがロックされる時間 (秒単位)。

Lockout duration = 600

アカウントがロックされると、10 分間ログインできません。

重要

国際文字や記号を使用できないハードウェアセットが各種ある場合には、文字クラス要件に英語と共通記号を使用してください。パスワードの文字クラスポリシーの詳細は、Red Hat ナレッジベースの What characters are valid in a password? を参照してください。

6.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
    
      tasks:
      - name: Ensure presence of pwpolicy for group ops
        ipapwpolicy:
          ipaadmin_password: MySecret123
          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 は、ユーザーにポリシーが設定されていない場合のフォールバックポリシーとして機能し、グループポリシーよりも優先されることはありません。

関連情報

  • /usr/share/doc/ansible-freeipa/ ディレクトリーの README-pwpolicy.md ファイルを参照してください。
  • Password policy priorities を参照してください。

6.4. IdM での追加のパスワードポリシーオプション

Identity Management (IdM) 管理者は、libpwquality 機能セットに基づく追加のパスワードポリシーオプションを有効にすることで、デフォルトのパスワード要件を強化できます。追加のパスワードポリシーオプションには、以下が含まれます。

--maxrepeat
新しいパスワードに使用できる、連続する同一文字数の上限を指定します。
--maxsequence
新しいパスワードにおける単調な文字シーケンスの最大長を指定します。このような配列の例は、12345 または fedcb です。このようなパスワードのほとんどは、簡素化チェックに合格しません。唯一の例外は、シーケンスがパスワードのごく一部である場合です。
--dictcheck
ゼロ以外の場合は、パスワード (修正可能) が辞書の単語と一致するかどうかを確認します。現在、libpwquality は、cracklib ライブラリーを使用してディクショナリーの確認を実行しています。
--usercheck
ゼロ以外の場合は、パスワード (修正可能) に、何らかの形式でユーザー名が含まれているかどうかを確認します。ユーザー名が 3 文字より短い場合は実行されません。

既存のパスワードには、追加のパスワードポリシーオプションを適用できません。追加オプションのいずれかを適用すると、IdM は、パスワードの最小文字数である --minlength オプションを自動的に 6 文字に設定します。

注記

RHEL 7、RHEL 8、RHEL 9 サーバーが混在する環境では、RHEL 8.4 以降で実行されているサーバーにのみ追加のパスワードポリシー設定を適用できます。ユーザーが IdM クライアントにログインし、IdM クライアントが RHEL 8.3 以前で実行している IdM サーバーと通信している場合は、システム管理者が設定した新しいパスワードポリシーの要件は適用されません。一貫した動作を確保するには、すべてのサーバーを RHEL 8.4 以降にアップグレードまたは更新します。

関連情報:

6.5. IdM グループへの追加のパスワードポリシーオプションの適用

本セクションでは、Identity Management (IdM) で追加のパスワードポリシーオプションを適用する方法を説明します。ここでは、新しいパスワードにユーザー名が含まれていないことと、パスワードに同じ文字が連続して 2 文字以内になるようにすることで、マネージャー グループのパスワードポリシーを強化する方法を説明します。

前提条件

  • IdM 管理者としてログインしている。
  • マネージャー グループが IdM に存在している。
  • マネージャー パスワードポリシーが IdM に存在している。

手順

  1. マネージャー グループのユーザーが提案するすべての新しいパスワードに、ユーザー名の確認を適用します。

    $ ipa pwpolicy-mod --usercheck=True managers
    注記

    パスワードポリシーの名前を指定しないと、デフォルトの global_policy が変更されます。

  2. マネージャー パスワードポリシーで、同一の連続した文字の上限を 2 に設定します。

    $ ipa pwpolicy-mod --maxrepeat=2 managers

    パスワードに、同一の連続した文字が 2 文字を超える場合は、パスワードが使用できなくなります。たとえば、eR873mUi111YJQ の組み合わせは、連続して 3 つの 1 を含むため、使用できません。

検証

  1. test_user という名前のテストユーザーを追加します。

    $ ipa user-add test_user
    First name: test
    Last name: user
    ----------------------------
    Added user "test_user"
    ----------------------------
  2. テストユーザーを マネージャー グループに追加します。

    1. IdM Web UI で、IdentityGroupsUser Groups をクリックします。
    2. managers をクリックします。
    3. Add をクリックします。
    4. Add users into user group 'managers' ページで、test_user をチェックします。
    5. > 矢印をクリックして、ユーザーを Prospective 列に移動します。
    6. Add をクリックします。
  3. テストユーザーのパスワードをリセットします。

    1. IdentityUsers に移動します。
    2. test_user をクリックします。
    3. Actions メニューで、Reset Password をクリックします。
    4. ユーザーの一時パスワードを入力します。
  4. コマンドラインで、test_user の Kerberos Ticket-Granting Ticket (TGT) を取得してみてください。

    $ kinit test_user
    1. 一時パスワードを入力します。
    2. パスワードを変更する必要があることがシステムから通知されます。test_user のユーザー名を含むパスワードを入力します。

      Password expired. You must change it now.
      Enter new password:
      Enter it again:
      注記

      Kerberos には、詳細なエラーパスワードポリシーの報告はなく、特定のケースでは、パスワードが拒否された理由を明確に示していません。

    3. 入力したパスワードが拒否されたことがシステムから通知されます。連続して 3 文字以上の同一文字を含むパスワードを入力します。

      Password change rejected: Password not changed.
      Unspecified password quality failure while trying to change password.
      Please try again.
      
      Enter new password:
      Enter it again:
    4. 入力したパスワードが拒否されたことがシステムから通知されます。マネージャー パスワードポリシーの基準を満たすパスワードを入力します。

      Password change rejected: Password not changed.
      Unspecified password quality failure while trying to change password.
      Please try again.
      
      Enter new password:
      Enter it again:
  5. 取得した TGT を表示します。

    $ klist
    Ticket cache: KCM:0:33945
    Default principal: test_user@IDM.EXAMPLE.COM
    
    Valid starting       Expires              Service principal
    07/07/2021 12:44:44  07/08/2021 12:44:44  krbtgt@IDM.EXAMPLE.COM@IDM.EXAMPLE.COM

マネージャー のパスワードポリシーが、マネージャー グループのユーザーに対して正しく機能するようになりました。

第7章 パスワード失効に関する通知の管理

ipa-client-epn パッケージに含まれる Expiring Password Notification (EPN) ツールを使用して、設定期間内にパスワードが失効する Identity Management (IdM) ユーザーの一覧を構築できます。EPN ツールをインストール、設定、および使用するには、該当のセクションを参照してください。

7.1. Expiring Password Notification (EPN) ツールの概要

Expiring Password Notification (EPN) ツールは、設定期間内にパスワードが失効する Identity Management (IdM) ユーザーの一覧の作成に使用可能なスタンドアロンツールです。

IdM 管理者は、EPN を使用して以下を行うことができます。

  • 対象ユーザーの一覧を JSON 形式で表示する。これは、ドライランモードを実行時に作成されます。
  • 特定の日または日付の範囲に送信される電子メール数を計算する。
  • パスワード期限切れのメール通知をユーザーに送信する。
  • Ipa-epn.timer が EPN ツールを毎日実行し、定義済みの未来の日付範囲内にパスワードが執行するユーザーに対してメールを送信するように設定する。
  • メール通知をカスタマイズして、ユーザーに送信する。
注記

ユーザーアカウントが無効な場合には、パスワードが期限切れなってもメール通知は送信されません。

7.2. Expiring Password Notification ツールのインストール

この手順では、EPN (Expiring Password Notification) ツールをインストールする方法を説明します。

前提条件

  • スマートホストで設定したローカルの Postfix SMTP サーバーを使用して、Identity Management (IdM) レプリカまたは IdM クライアントに EPN ツールをインストールします。

手順

  • EPN ツールをインストールします。

    # dnf install ipa-client-epn

7.3. EPN ツールを実行してパスワードが失効するユーザーへのメール送信

この手順では、Expiring Password Notification (EPN) ツールを実行してパスワードが失効するユーザーにメールを送信する方法を説明します。

注記

EPN ツールはステートレスです。特定の日付にパスワードが失効するユーザーに対してメールの送信に失敗した場合には、EPN ツールには失敗したユーザーの一覧は保存されません。

前提条件

手順

  1. epn.conf 設定ファイルを更新して、今後パスワードが失効するユーザーに通知されるように、EPN ツールのオプションを設定します。

    # vi /etc/ipa/epn.conf
  2. 必要に応じて notify_ttls を更新します。デフォルトでは、28、14、7、3 および 1 日以内にパスワードが期限切れになるユーザーに通知します。

    notify_ttls = 28, 14, 7, 3, 1
  3. SMTP サーバーおよびポートを設定します。

    smtp_server = localhost
    smtp_port = 25
  4. メールで失効通知を送信するメールアドレスを指定します。配信に失敗したメールは以下のアドレスに返されます。

    mail_from =admin-email@example.com
  5. /etc/ipa/epn.conf ファイルを保存します。
  6. --dry-run オプションなしでツールを実行した場合には、EPN ツールをドライランモードで実行し、パスワード失効メールの通知を送信するユーザーの一覧を生成します。

    ipa-epn --dry-run
    [
        {
         "uid": "user5",
         "cn": "user 5",
         "krbpasswordexpiration": "2020-04-17 15:51:53",
         "mail": "['user5@ipa.test']"
        }
    ]
    [
        {
         "uid": "user6",
         "cn": "user 6",
         "krbpasswordexpiration": "2020-12-17 15:51:53",
         "mail": "['user5@ipa.test']"
         }
    ]
    The IPA-EPN command was successful
    注記

    返されたユーザーの一覧が非常に大きく、かつ --dry-run オプションなしでツールを実行すると、メールサーバーで問題が発生する可能性があります。

  7. ドライランモードで EPN ツールを実行時に返された全ユーザーの一覧に失効メールを送信するには、--dry-run オプションをなしで EPN ツールを実行します。

    ipa-epn
    [
      {
         "uid": "user5",
         "cn": "user 5",
         "krbpasswordexpiration": "2020-10-01 15:51:53",
         "mail": "['user5@ipa.test']"
      }
    ]
    [
      {
        "uid": "user6",
        "cn": "user 6",
        "krbpasswordexpiration": "2020-12-17 15:51:53",
        "mail": "['user5@ipa.test']"
      }
    ]
    The IPA-EPN command was successful
  8. EPN を監視システムに追加して、--from-nbdays および --to-nbdays オプションで EPN を呼び出し、特定の時間内に期限切れになるユーザーパスワード数を確認できます。

    # ipa-epn --from-nbdays 8 --to-nbdays 12
    注記

    --from-nbdays および --to-nbdays で EPN ツールを呼び出すと、自動的にドライランモードで実行されます。

検証手順

  • EPN ツールを実行し、メール通知が送信されていることを確認します。

関連情報

  • ipa-epn の man ページを参照してください。
  • epn.conf の man ページを参照してください。

7.4. ipa-epn.timer を有効にして、パスワードが失効する全ユーザーへのメールの送信

この手順では、ipa-epn.timer を使用して、EPN (Expiring Password Notification) ツールを実行して、パスワードの期限が切れるユーザーにメールを送信する方法を説明します。ipa-epn.timerepn.conf ファイルを解析し、そのファイルに設定された未来の日付範囲内にパスワードの期限が切れるユーザーにメールを送信します。

前提条件

手順

  • ipa-epn.timer を起動します。

    systemctl start ipa-epn.timer

タイマーを起動すると、デフォルトでは、EPN ツールは毎日午前 1 時に実行されます。

関連情報

  • ipa-epn の man ページを参照してください。

7.5. Expiring Password Notification (EPN) のメールテンプレートの変更

この手順では、Expiring Password Notification (EPN) のメールメッセージのテンプレートをカスタマイズする方法を説明します。

前提条件

  • ipa-client-epn パッケージがインストールされている。

手順

  1. EPN メッセージテンプレートを開きます。

    # vi /etc/ipa/epn/expire_msg.template
  2. 必要に応じてテンプレートテキストを更新します。

    Hi {{ fullname }},
    
    Your password will expire on {{ expiration }}.
    
    Please change it as soon as possible.

    テンプレートでは以下の変数を使用できます。

    • User ID: uid
    • Full name: fullname
    • First name: first
    • Last name: last
    • Password expiration date: expiration
  3. メッセージテンプレートファイルを保存します。

検証手順

  • EPN ツールを実行し、メール通知に更新したテキストが含まれていることを確認します。

関連情報

  • ipa-epn の man ページを参照してください。

第8章 IdM クライアントの IdM ユーザーへの sudo アクセスの許可

本セクションでは、Identity Management でユーザーに sudo アクセス権を付与する方法を説明します。

8.1. IdM クライアントの sudo アクセス

システム管理者は、root 以外のユーザーに、通常 root ユーザー用に予約されている管理コマンドを実行できるようにする sudo アクセスを付与できます。その結果、ユーザーが、通常、root ユーザー用に予約される管理コマンドを実行する場合は、コマンドの前に sudo を付けることができます。パスワードを入力すると、そのコマンドは root ユーザーとして実行されます。データベースサービスアカウントなどの別のユーザーまたはグループとして sudo コマンドを実行するには、sudo ルールの RunAs エイリアス を設定できます。

Red Hat Enterprise Linux (RHEL) 8 ホストが Identity Management (IdM) クライアントとして登録されている場合は、以下の方法で、どの IdM ユーザーがホストでどのコマンドを実行できるかを定義する sudo ルールを指定できます。

  • ローカルの /etc/sudoers ファイル
  • IdM での一元設定

このセクションでは、コマンドラインインターフェイス (CLI) および IdM Web UI を使用して、IdM クライアントの sudo 集約ルール を作成する方法を説明します。

Generic Security Service Application Programming Interface (GSSAPI) を使用して sudo のパスワードレス認証を設定することもできます。これは、UNIX ベースのオペレーティングシステムがネイティブで Kerberos サービスにアクセスして認証する方法です。pam_sss_gss.so Pluggable Authentication Module (PAM) を使用して SSSD サービスを介して GSSAPI 認証を呼び出し、有効な Kerberos チケットを使用して sudo コマンドに対して認証を行うことができます。

関連情報

8.2. CLI での IdM クライアントの IdM ユーザーへの sudo アクセス許可

Identity Management (IdM) では、特定の IdM ホストで IdM ユーザーアカウントの特定コマンドに sudo アクセスを付与できます。最初に sudo コマンドを追加してから、1 つまたは複数のコマンドに対して sudo ルールを作成します。

たとえば、idmclient マシンで /usr/sbin/reboot コマンドを実行する権限を idm_user に付与する idm_user_rebootsudo ルールを作成するには、以下の手順を実行します。

前提条件

  • IdM 管理者としてログインしている。
  • IdM で idm_user のユーザーアカウントを作成し、ユーザーのパスワードを作成してそのアカウントのロックを解除している。CLI を使用して新しい IdM ユーザーを追加する方法の詳細は、コマンドラインを使用したユーザーの追加 を参照してください。
  • idmclient ホストにローカル idm_user アカウントが存在しない。idm_user ユーザーは、ローカルの /etc/passwd ファイルには表示されません。

手順

  1. IdM の 管理者 として Kerberos チケットを取得します。

    [root@idmclient ~]# kinit admin
  2. sudo コマンドの IdM データベースに /usr/sbin/reboot コマンドを追加します。

    [root@idmclient ~]# ipa sudocmd-add /usr/sbin/reboot
    -------------------------------------
    Added Sudo Command "/usr/sbin/reboot"
    -------------------------------------
      Sudo Command: /usr/sbin/reboot
  3. idm_user_reboot という名前の sudo ルールを作成します。

    [root@idmclient ~]# ipa sudorule-add idm_user_reboot
    ---------------------------------
    Added Sudo Rule "idm_user_reboot"
    ---------------------------------
      Rule name: idm_user_reboot
      Enabled: TRUE
  4. /usr/sbin/reboot コマンドを idm_user_reboot ルールに追加します。

    [root@idmclient ~]# ipa sudorule-add-allow-command idm_user_reboot --sudocmds '/usr/sbin/reboot'
      Rule name: idm_user_reboot
      Enabled: TRUE
      Sudo Allow Commands: /usr/sbin/reboot
    -------------------------
    Number of members added 1
    -------------------------
  5. idm_user_reboot ルールを IdM idmclient ホストに適用します。

    [root@idmclient ~]# ipa sudorule-add-host idm_user_reboot --hosts idmclient.idm.example.com
    Rule name: idm_user_reboot
    Enabled: TRUE
    Hosts: idmclient.idm.example.com
    Sudo Allow Commands: /usr/sbin/reboot
    -------------------------
    Number of members added 1
    -------------------------
  6. idm_user アカウントを idm_ user_reboot ルールに追加します。

    [root@idmclient ~]# ipa sudorule-add-user idm_user_reboot --users idm_user
    Rule name: idm_user_reboot
    Enabled: TRUE
    Users: idm_user
    Hosts: idmclient.idm.example.com
    Sudo Allow Commands: /usr/sbin/reboot
    -------------------------
    Number of members added 1
    -------------------------
注記

サーバーからクライアントへの変更の伝播には数分かかる場合があります。

検証手順

  1. idmclient ホストに idm_user アカウントとしてログインします。
  2. idm_user アカウントが実行可能な sudo ルールを表示します。

    [idm_user@idmclient ~]$ sudo -l
    Matching Defaults entries for idm_user on idmclient:
        !visiblepw, always_set_home, match_group_by_gid, always_query_group_plugin,
        env_reset, env_keep="COLORS DISPLAY HOSTNAME HISTSIZE KDEDIR LS_COLORS",
        env_keep+="MAIL PS1 PS2 QTDIR USERNAME LANG LC_ADDRESS LC_CTYPE",
        env_keep+="LC_COLLATE LC_IDENTIFICATION LC_MEASUREMENT LC_MESSAGES",
        env_keep+="LC_MONETARY LC_NAME LC_NUMERIC LC_PAPER LC_TELEPHONE",
        env_keep+="LC_TIME LC_ALL LANGUAGE LINGUAS _XKB_CHARSET XAUTHORITY KRB5CCNAME",
        secure_path=/sbin\:/bin\:/usr/sbin\:/usr/bin
    
    User idm_user may run the following commands on idmclient:
        (root) /usr/sbin/reboot
  3. sudo を使用してマシンを再起動します。プロンプトが表示されたら、idm_user のパスワードを入力します。

    [idm_user@idmclient ~]$ sudo /usr/sbin/reboot
    [sudo] password for idm_user:

8.3. IdM Web UI を使用した IdM クライアントでの IdM ユーザーへの sudo アクセス権の付与

Identity Management (IdM) では、特定の IdM ホストで IdM ユーザーアカウントの特定コマンドに sudo アクセスを付与できます。最初に sudo コマンドを追加してから、1 つまたは複数のコマンドに対して 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 を使用してユーザーが実行できるコマンドを入力します。

      図8.1 IdM sudo コマンドの追加

      ラベルが sudo コマンドの追加のポップアップウィンドウのスクリーンショット。 Sudo command という必須フィールドに "/usr/sbin/reboot" という内容が入力されており、Description フィールドは空白です。ウィンドウの右下のボタンには "Add" - "Add and Add Another" - "Add and Edit" - "Cancel" の 4 つのボタンがあります。
    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 to のサブセクションで Add をクリックして、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 to サブセクションで Add をクリックして、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 をクリックします。
    7. コマンドを指定します。

      1. Run Commands セクションの Command category the rule applies to サブセクションで、Specified Commands and Groups ラジオボタンにチェックを入れます。
      2. Sudo Allow Commands サブセクションで Add をクリックして、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 ページに戻ります。

      図8.2 IdM sudo ルールの追加

      追加した sudo ルールの概要のスクリーンショット。ルールの適用先のユーザーの表には Who セクションがあり、ルールの適用先のホストの表には、Access this host セクションがあります。また、ルールに関連するコマンドの表には Run Commands セクションがあります。
    8. 左上隅にある Save をクリックします。

新しいルールはデフォルトで有効になります。

注記

サーバーからクライアントへの変更の伝播には数分かかる場合があります。

検証手順

  1. idmclientidm_user としてログインします。
  2. sudo を使用してマシンを再起動します。プロンプトが表示されたら、idm_user のパスワードを入力します。

    $ sudo /usr/sbin/reboot
    [sudo] password for idm_user:

sudo ルールが正しく設定されている場合には、マシンが再起動します。

8.4. IdM クライアントでサービスアカウントとしてコマンドを実行する CLI での sudo ルールの作成

IdM では、RunAs エイリアス を使用して、sudo ルールを設定し、別のユーザーまたはグループとして sudo コマンドを実行できます。たとえば、データベースアプリケーションをホストする IdM クライアントが存在し、そのアプリケーションに対応するローカルサービスアカウントとしてコマンドを実行する必要があるとします。

この例を使用して、run_third-party-app_report と呼ばれるコマンドラインに sudo ルールを作成し、idm_user アカウントが idmclient ホストの thirdpartyapp サービスアカウントとして /opt/third-party-app/bin/report コマンドを実行できるようにします。

前提条件

  • IdM 管理者としてログインしている。
  • IdM で idm_user のユーザーアカウントを作成し、ユーザーのパスワードを作成してそのアカウントのロックを解除している。CLI を使用して新しい IdM ユーザーを追加する方法の詳細は、コマンドラインを使用したユーザーの追加 を参照してください。
  • idmclient ホストにローカル idm_user アカウントが存在しない。idm_user ユーザーは、ローカルの /etc/passwd ファイルには表示されません。
  • idmclient ホストに、third-party-app という名前のカスタムアプリケーションがインストールされている。
  • third-party-app アプリケーションの report コマンドが、/opt/third-party-app/bin/report ディレクトリーにインストールされている。
  • third-party-app アプリケーションにコマンドを実行するために、thirdpartyapp という名前のローカルサービスアカウントを作成している。

手順

  1. IdM の 管理者 として Kerberos チケットを取得します。

    [root@idmclient ~]# kinit admin
  2. /opt/third-party-app/bin/report コマンドを、sudo コマンドの IdM データベースに追加します。

    [root@idmclient ~]# ipa sudocmd-add /opt/third-party-app/bin/report
    ----------------------------------------------------
    Added Sudo Command "/opt/third-party-app/bin/report"
    ----------------------------------------------------
      Sudo Command: /opt/third-party-app/bin/report
  3. run_third-party-app_report という名前の sudo ルールを作成します。

    [root@idmclient ~]# ipa sudorule-add run_third-party-app_report
    --------------------------------------------
    Added Sudo Rule "run_third-party-app_report"
    --------------------------------------------
      Rule name: run_third-party-app_report
      Enabled: TRUE
  4. --users=<user> オプションを使用して、sudorule-add-runasuser コマンドに RunAs ユーザーを指定します。

    [root@idmclient ~]# ipa sudorule-add-runasuser run_third-party-app_report --users=thirdpartyapp
      Rule name: run_third-party-app_report
      Enabled: TRUE
      RunAs External User: thirdpartyapp
    -------------------------
    Number of members added 1
    -------------------------

    ユーザー (または --groups=* オプションで指定したグループ) は、ローカルサービスアカウントや Active Directory ユーザーなどの IdM の外部に配置できます。グループ名には % 接頭辞を追加しないでください。

  5. idm_user_reboot ルールに /opt/third-party-app/bin/report コマンドを追加します。

    [root@idmclient ~]# ipa sudorule-add-allow-command run_third-party-app_report --sudocmds '/opt/third-party-app/bin/report'
    Rule name: run_third-party-app_report
    Enabled: TRUE
    Sudo Allow Commands: /opt/third-party-app/bin/report
    RunAs External User: thirdpartyapp
    -------------------------
    Number of members added 1
    -------------------------
  6. run_third-party-app_report ルールを IdM idmclient ホストに適用します。

    [root@idmclient ~]# ipa sudorule-add-host run_third-party-app_report --hosts idmclient.idm.example.com
    Rule name: run_third-party-app_report
    Enabled: TRUE
    Hosts: idmclient.idm.example.com
    Sudo Allow Commands: /opt/third-party-app/bin/report
    RunAs External User: thirdpartyapp
    -------------------------
    Number of members added 1
    -------------------------
  7. idm_user アカウントーを run_third-party-app_report ルールに追加します。

    [root@idmclient ~]# ipa sudorule-add-user run_third-party-app_report --users idm_user
    Rule name: run_third-party-app_report
    Enabled: TRUE
    Users: idm_user
    Hosts: idmclient.idm.example.com
    Sudo Allow Commands: /opt/third-party-app/bin/report
    RunAs External User: thirdpartyapp
    -------------------------
    Number of members added 1
注記

サーバーからクライアントへの変更の伝播には数分かかる場合があります。

検証手順

  1. idmclient ホストに idm_user アカウントとしてログインします。
  2. 新しい sudo ルールをテストします。

    1. idm_user アカウントが実行可能な sudo ルールを表示します。

      [idm_user@idmclient ~]$ sudo -l
      Matching Defaults entries for idm_user@idm.example.com on idmclient:
          !visiblepw, always_set_home, match_group_by_gid, always_query_group_plugin,
          env_reset, env_keep="COLORS DISPLAY HOSTNAME HISTSIZE KDEDIR LS_COLORS",
          env_keep+="MAIL PS1 PS2 QTDIR USERNAME LANG LC_ADDRESS LC_CTYPE",
          env_keep+="LC_COLLATE LC_IDENTIFICATION LC_MEASUREMENT LC_MESSAGES",
          env_keep+="LC_MONETARY LC_NAME LC_NUMERIC LC_PAPER LC_TELEPHONE",
          env_keep+="LC_TIME LC_ALL LANGUAGE LINGUAS _XKB_CHARSET XAUTHORITY KRB5CCNAME",
          secure_path=/sbin\:/bin\:/usr/sbin\:/usr/bin
      
      User idm_user@idm.example.com may run the following commands on idmclient:
          (thirdpartyapp) /opt/third-party-app/bin/report
    2. report コマンドを thirdpartyapp サービスアカウントとして実行します。

      [idm_user@idmclient ~]$ sudo -u thirdpartyapp /opt/third-party-app/bin/report
      [sudo] password for idm_user@idm.example.com:
      Executing report...
      Report successful.

8.5. IdM クライアントでサービスアカウントとしてコマンドを実行する IdM WebUI での sudo ルールの作成

IdM では、RunAs エイリアス を使用して、sudo ルールを設定し、別のユーザーまたはグループとして sudo コマンドを実行できます。たとえば、データベースアプリケーションをホストする IdM クライアントが存在し、そのアプリケーションに対応するローカルサービスアカウントとしてコマンドを実行する必要があるとします。

この例を使用して、run_third-party-app_report という IdM WebUI に sudo ルールを作成し、idm_user アカウントが idmclient ホストで thirdpartyapp サービスアカウントとして /opt/third-party-app/bin/report コマンドを実行できるようにします。

前提条件

  • IdM 管理者としてログインしている。
  • IdM で idm_user のユーザーアカウントを作成し、ユーザーのパスワードを作成してそのアカウントのロックを解除している。CLI を使用して新しい IdM ユーザーを追加する方法の詳細は、コマンドラインを使用したユーザーの追加 を参照してください。
  • idmclient ホストにローカル idm_user アカウントが存在しない。idm_user ユーザーは、ローカルの /etc/passwd ファイルには表示されません。
  • idmclient ホストに、third-party-app という名前のカスタムアプリケーションがインストールされている。
  • third-party-app アプリケーションの report コマンドが、/opt/third-party-app/bin/report ディレクトリーにインストールされている。
  • third-party-app アプリケーションにコマンドを実行するために、thirdpartyapp という名前のローカルサービスアカウントを作成している。

手順

  1. /opt/third-party-app/bin/report コマンドを、sudo コマンドの IdM データベースに追加します。

    1. PolicySudoSudo Commands の順に移動します。
    2. 右上にある Add をクリックして、Add sudo command ダイアログボックスを開きます。
    3. コマンド /opt/third-party-app/bin/report を入力します。

      ラベルが sudo コマンドの追加のポップアップウィンドウのスクリーンショット。 "/opt/third-party-app/bin/report" の内容で、"Sudo command" というラベルが付いた必須フィールドがあります。Description フィールドは空白です。ウィンドウの右下のボタンには "Add" - "Add and Add Another" - "Add and Edit" - "Cancel" の 4 つのボタンがあります。
    4. Add をクリックします。
  2. 新しい sudo コマンドエントリーを使用して、新しい sudo ルールを作成します。

    1. PolicySudoSudo ルールに移動します。
    2. 右上にある Add をクリックして、Add sudo rule ダイアログボックスを開きます。
    3. sudo ルールの名前 run_third-party-app_report を入力します。

      "Add sudo rule" というラベルが付いたポップアップウィンドウのスクリーンショット。 "run_third-party-app_report" という内容の "Rule name" のラベルが付いた必須フィールドがあります。ウィンドウの右下のボタンには "Add" - "Add and Add Another" - "Add and Edit" - "Cancel" の 4 つのボタンがあります。
    4. Add and Edit をクリックします。
    5. ユーザーを指定します。

      1. Who セクションで、Specified Users and Groups のラジオボタンを選択します。
      2. User category the rule applies to のサブセクションで Add をクリックして、Add users into sudo rule "run_third-party-app_report" ダイアログボックスを開きます。
      3. Available 列の Add users into sudo rule "run_third-party-app_report" ダイアログボックスで、idm_user チェックボックスをオンにして、これを Prospective 列に移動します。

        "Add users into sudo rule" というラベルが付いたポップアップウィンドウのスクリーンショット。 左側の Available 一覧からユーザーを選択し、これらを右側の Prospective 列に移動できます。ウィンドウの右下には、"Add" - "Cancel" の 2 つのボタンがあります。
      4. Add をクリックします。
    6. ホストを指定します。

      1. Access this host セクションで、Specified Hosts and Groups ラジオボタンを確認します。
      2. Host category this rule applies to サブセクションで Add をクリックして、 Add hosts into sudo rule "run_third-party-app_report" ダイアログボックスを開きます。
      3. Available 列の Add hosts into sudo rule "run_third-party-app_report" ダイアログボックスで、idmclient.idm.example.com チェックボックスをオンにして、これを Prospective 列に移動します。

        "Add hosts into sudo rule" というラベルが付いたポップアップウィンドウのスクリーンショット。 左側の Available 一覧からホストを選択し、これらを右側の Prospective 列に移動できます。ウィンドウの右下には、"Add" - "Cancel" の 2 つのボタンがあります。
      4. Add をクリックします。
    7. コマンドを指定します。

      1. Run Commands セクションの Command category the rule applies to サブセクションで、Specified Commands and Groups ラジオボタンにチェックを入れます。
      2. Sudo Allow Commands サブセクションで Add をクリックして、Add allow sudo commands into sudo rule "run_third-party-app_report" ダイアログボックスを開きます。
      3. Available 列の Add allow sudo commands into sudo rule "run_third-party-app_report" ダイアログボックスで、/opt/third-party-app/bin/report チェックボックスをオンにして、これを Prospective 列に移動します。

        "Add allow sudo commands into sudo rule" というラベルが付いたポップアップウィンドウのスクリーンショット。 左側の Available 一覧から sudo コマンドを選択し、これらを右側の Prospective 列に移動できます。ウィンドウの右下には、"Add" - "Cancel" の 2 つのボタンがあります。
      4. Add をクリックして、run_third-party-app_report のページに戻ります。
    8. RunAs ユーザーを指定します。

      1. As Whom で、指定したユーザーとグループ のラジオボタンを確認します。
      2. RunAs ユーザー サブセクションで Add をクリックして、Add RunAs users into sudo rule "run_third-party-app_report" ダイアログボックスを開きます。
      3. Add RunAs users into sudo rule "run_third-party-app_report" ダイアログボックスで、External ボックスに thirdpartyapp サービスアカウントを入力し、これを Prospective 列に移動します。

        外部ユーザーとして "thirdpartyapp" サービスアカウントを指定できるダイアログボックスのスクリーンショット。
      4. Add をクリックして、run_third-party-app_report のページに戻ります。
    9. 左上隅にある Save をクリックします。

新しいルールはデフォルトで有効になります。

図8.3 sudo ルールの詳細

追加した sudo ルールの概要のスクリーンショット。"Who" セクションには、"idm_user" のエントリーがあります。 "Access this host" セクションには "idmclient.idm.example.com" があります。 "Run Commands" セクションには、"/opt/third-party-app/bin/report" コマンドがあります。"As Whom" セクションには、"thirdpartyapp" アカウントが一覧表示されます。
注記

サーバーからクライアントへの変更の伝播には数分かかる場合があります。

検証手順

  1. idmclient ホストに idm_user アカウントとしてログインします。
  2. 新しい sudo ルールをテストします。

    1. idm_user アカウントが実行可能な sudo ルールを表示します。

      [idm_user@idmclient ~]$ sudo -l
      Matching Defaults entries for idm_user@idm.example.com on idmclient:
          !visiblepw, always_set_home, match_group_by_gid, always_query_group_plugin,
          env_reset, env_keep="COLORS DISPLAY HOSTNAME HISTSIZE KDEDIR LS_COLORS",
          env_keep+="MAIL PS1 PS2 QTDIR USERNAME LANG LC_ADDRESS LC_CTYPE",
          env_keep+="LC_COLLATE LC_IDENTIFICATION LC_MEASUREMENT LC_MESSAGES",
          env_keep+="LC_MONETARY LC_NAME LC_NUMERIC LC_PAPER LC_TELEPHONE",
          env_keep+="LC_TIME LC_ALL LANGUAGE LINGUAS _XKB_CHARSET XAUTHORITY KRB5CCNAME",
          secure_path=/sbin\:/bin\:/usr/sbin\:/usr/bin
      
      User idm_user@idm.example.com may run the following commands on idmclient:
          (thirdpartyapp) /opt/third-party-app/bin/report
    2. report コマンドを thirdpartyapp サービスアカウントとして実行します。

      [idm_user@idmclient ~]$ sudo -u thirdpartyapp /opt/third-party-app/bin/report
      [sudo] password for idm_user@idm.example.com:
      Executing report...
      Report successful.

8.6. IdM クライアントでの sudo の GSSAPI 認証の有効化

以下の手順では、pam_sss_gss.so PAM モジュールを介して、sudo コマンドおよび sudo -i コマンドの IdM クライアントで、Generic Security Service Application Program Interface (GSSAPI) 認証を有効にする方法を説明します。この設定により、IdM ユーザーは Kerberos チケットを使用して sudo コマンドに対する認証が可能になります。

前提条件

  • IdM ホストに適用する IdM ユーザーの sudo ルールを作成している。この例では、idmclient ホストで /usr/sbin/reboot コマンドを実行するパーミッションを idm_user アカウントに付与する idm_user_reboot sudo ルールが作成済みです。
  • /etc/sssd/sssd.conf ファイルと、/etc/pam.d/ ディレクトリーの PAM ファイルを変更するための root 特権がある。

手順

  1. /etc/sssd/sssd.conf 設定ファイルを開きます。
  2. [domain/<domain_name>] セクションに以下のエントリーを追加します。

    [domain/<domain_name>]
    pam_gssapi_services = sudo, sudo-i
  3. /etc/sssd/sssd.conf ファイルを保存して閉じます。
  4. SSSD サービスを再起動して、設定の変更を読み込みます。

    [root@idmclient ~]# systemctl restart sssd
  5. /etc/pam.d/sudo の PAM 設定ファイルを開きます。
  6. 以下のエントリーを、/etc/pam.d/sudo ファイルの auth セクションの最初の行に追加します。

    #%PAM-1.0
    auth sufficient pam_sss_gss.so
    auth       include      system-auth
    account    include      system-auth
    password   include      system-auth
    session    include      system-auth
  7. /etc/pam.d/sudo ファイルを保存して閉じます。
  8. /etc/pam.d/sudo-i の PAM 設定ファイルを開きます。
  9. 以下のエントリーを、/etc/pam.d/sudo-i ファイルの auth セクションの最初の行に追加します。

    #%PAM-1.0
    auth sufficient pam_sss_gss.so
    auth       include      sudo
    account    include      sudo
    password   include      sudo
    session    optional     pam_keyinit.so force revoke
    session    include      sudo
  10. /etc/pam.d/sudo-i ファイルを保存して閉じます。

検証手順

  1. idm_user アカウントとしてホストにログインします。

    [root@idm-client ~]# ssh -l idm_user@idm.example.com localhost
    idm_user@idm.example.com's password:
  2. idm_user アカウントで Ticket-Granting Ticket があることを確認します。

    [idmuser@idmclient ~]$ klist
    Ticket cache: KCM:1366201107
    Default principal: idm_user@IDM.EXAMPLE.COM
    
    Valid starting       Expires              Service principal
    01/08/2021 09:11:48  01/08/2021 19:11:48  krbtgt/IDM.EXAMPLE.COM@IDM.EXAMPLE.COM
    	renew until 01/15/2021 09:11:44
  3. (オプション) idm_user アカウントの Kerberos 認証情報がない場合は、現在の Kerberos 認証情報を破棄し、正しい認証情報を要求します。

    [idm_user@idmclient ~]$ kdestroy -A
    
    [idm_user@idmclient ~]$ kinit idm_user@IDM.EXAMPLE.COM
    Password for idm_user@idm.example.com:
  4. パスワードを指定せずに sudo を使用してマシンを再起動します。

    [idm_user@idmclient ~]$ sudo /usr/sbin/reboot

8.7. IdM クライアントでの GSSAPI 認証の有効化および sudo の Kerberos 認証インジケーターの有効化

以下の手順では、pam_sss_gss.so PAM モジュールを介して、sudo コマンドおよび sudo -i コマンドの IdM クライアントで、Generic Security Service Application Program Interface (GSSAPI) 認証を有効にする方法を説明します。また、スマートカードを使用してログインしたユーザーのみが Kerberos チケットでこれらのコマンドに対して認証されます。

注記

この手順をテンプレートとして使用し、他の PAM 対応サービスに対して SSSD で GSSAPI 認証を設定して、さらに特定の認証インジケーターが Kerberos チケットにアタッチされているユーザーだけにアクセスを限定することができます。

前提条件

  • IdM ホストに適用する IdM ユーザーの sudo ルールを作成している。この例では、idmclient ホストで /usr/sbin/reboot コマンドを実行するパーミッションを idm_user アカウントに付与する idm_user_reboot sudo ルールが作成済みです。
  • idmclient ホストにスマートカード認証を設定している。
  • /etc/sssd/sssd.conf ファイルと、/etc/pam.d/ ディレクトリーの PAM ファイルを変更するための root 特権がある。

手順

  1. /etc/sssd/sssd.conf 設定ファイルを開きます。
  2. [domain/<domain_name>] セクションに以下のエントリーを追加します。

    [domain/<domain_name>]
    pam_gssapi_services = sudo, sudo-i
    pam_gssapi_indicators_map = sudo:pkinit, sudo-i:pkinit
  3. /etc/sssd/sssd.conf ファイルを保存して閉じます。
  4. SSSD サービスを再起動して、設定の変更を読み込みます。

    [root@idmclient ~]# systemctl restart sssd
  5. /etc/pam.d/sudo の PAM 設定ファイルを開きます。
  6. 以下のエントリーを、/etc/pam.d/sudo ファイルの auth セクションの最初の行に追加します。

    #%PAM-1.0
    auth sufficient pam_sss_gss.so
    auth       include      system-auth
    account    include      system-auth
    password   include      system-auth
    session    include      system-auth
  7. /etc/pam.d/sudo ファイルを保存して閉じます。
  8. /etc/pam.d/sudo-i の PAM 設定ファイルを開きます。
  9. 以下のエントリーを、/etc/pam.d/sudo-i ファイルの auth セクションの最初の行に追加します。

    #%PAM-1.0
    auth sufficient pam_sss_gss.so
    auth       include      sudo
    account    include      sudo
    password   include      sudo
    session    optional     pam_keyinit.so force revoke
    session    include      sudo
  10. /etc/pam.d/sudo-i ファイルを保存して閉じます。

検証手順

  1. idm_user アカウントとしてホストにログインし、スマートカードで認証します。

    [root@idmclient ~]# ssh -l idm_user@idm.example.com localhost
    PIN for smart_card
  2. スマートカードユーザーを使用して Ticket-Granting Ticket があることを確認します。

    [idm_user@idmclient ~]$ klist
    Ticket cache: KEYRING:persistent:1358900015:krb_cache_TObtNMd
    Default principal: idm_user@IDM.EXAMPLE.COM
    
    Valid starting       Expires              Service principal
    02/15/2021 16:29:48  02/16/2021 02:29:48  krbtgt/IDM.EXAMPLE.COM@IDM.EXAMPLE.COM
    	renew until 02/22/2021 16:29:44
  3. idm_user アカウントが実行可能な sudo ルールを表示します。

    [idm_user@idmclient ~]$ sudo -l
    Matching Defaults entries for idmuser on idmclient:
        !visiblepw, always_set_home, match_group_by_gid, always_query_group_plugin,
        env_reset, env_keep="COLORS DISPLAY HOSTNAME HISTSIZE KDEDIR LS_COLORS",
        env_keep+="MAIL PS1 PS2 QTDIR USERNAME LANG LC_ADDRESS LC_CTYPE",
        env_keep+="LC_COLLATE LC_IDENTIFICATION LC_MEASUREMENT LC_MESSAGES",
        env_keep+="LC_MONETARY LC_NAME LC_NUMERIC LC_PAPER LC_TELEPHONE",
        env_keep+="LC_TIME LC_ALL LANGUAGE LINGUAS _XKB_CHARSET XAUTHORITY KRB5CCNAME",
        secure_path=/sbin\:/bin\:/usr/sbin\:/usr/bin
    
    User idm_user may run the following commands on idmclient:
        (root) /usr/sbin/reboot
  4. パスワードを指定せずに sudo を使用してマシンを再起動します。

    [idm_user@idmclient ~]$ sudo /usr/sbin/reboot

8.8. PAM サービスの GSSAPI 認証を制御する SSSD オプション

/etc/sssd/sssd.conf 設定ファイルに以下のオプションを使用すると、SSSD サービス内の GSSAPI 設定を調整できます。

pam_gssapi_services
SSSD を使用した GSSAPI 認証はデフォルトで無効になっています。このオプションを使用すると、PAM モジュール pam_sss_gss.so を使用して GSSAPI 認証を試すことができる PAM サービスをコンマ区切りの一覧で指定できます。GSSAPI 認証を明示的に無効にするには、このオプションを - に設定します。
pam_gssapi_indicators_map

このオプションは、Identity Management (IdM) ドメインにのみ適用されます。このオプションを使用して、サービスへの PAM のアクセスを付与するのに必要な Kerberos 認証インジケーターを一覧表示します。ペアの形式は <PAM_service>:_<required_authentication_indicator>_ でなければなりません。

有効な認証インジケーターは以下のとおりです。

  • OTP - 2 要素認証
  • radius - RADIUS 認証
  • pkinit - PKINIT、スマートカード、または証明書での認証
  • hardened - 強化パスワード
pam_gssapi_check_upn
このオプションはデフォルトで有効となっており、true に設定されています。このオプションを有効にすると、SSSD サービスでは Kerberos 認証情報と同じユーザー名が必要になります。false の場合には、pam_sss_gss.so の PAM モジュールは、必要なサービスチケットを取得できるすべてのユーザーを認証します。

次のオプションでは、sudosudo-i サービスの Kerberos 認証を有効にします。この認証では、sudo ユーザーはワンタイムパスワードで認証する必要があり、ユーザー名と Kerberos プリンシパルが同じでなければなりません。この設定は [pam] セクションにあるため、すべてのドメインに適用されます。

[pam]
pam_gssapi_services = sudo, sudo-i
pam_gssapi_indicators_map = sudo:otp
pam_gssapi_check_upn = true

これらのオプションを個別の [domain] セクションで設定して、[pam] セクションのグローバル値を上書きすることもできます。次のオプションは、異なる GSSAPI 設定を各ドメインに適用します。

idm.example.com ドメインの場合
  • sudosudo -i サービスの GSSAPI 認証を有効にする。
  • sudo コマンドには、証明書またはスマートカード認証オーセンティケーターが必要である。
  • sudo -i コマンドにはワンタイムパスワード認証が必要である。
  • ユーザー名と Kerberos プリンシパルを常に一致させる必要がある。
ad.example.com ドメインの場合
  • sudo サービスに対してのみ GSSAPI 認証を有効にする。
  • ユーザー名とプリンシパルを強制的に一致させない。
[domain/idm.example.com]
pam_gssapi_services = sudo, sudo-i
pam_gssapi_indicators_map = sudo:pkinit, sudo-i:otp
pam_gssapi_check_upn = true
...

[domain/ad.example.com]
pam_gssapi_services = sudo
pam_gssapi_check_upn = false
...

8.9. sudo の GSSAPI 認証のトラブルシューティング

IdM から Kerberos チケットを使用して sudo サービスに対する認証できない場合は、以下のシナリオを使用して設定のトラブルシューティングを行います。

前提条件

手順

  • 以下のエラーが表示された場合、Kerberos サービスはホスト名をもとに、サービスチケットに合わせて正しいレルムを解決できない可能性があります。

    Server not found in Kerberos database

    このような場合は、/etc/krb5.conf の Kerberos 設定ファイルの [domain_realm] セクションにホスト名を直接追加します。

    [idm-user@idm-client ~]$ cat /etc/krb5.conf
    ...
    
    [domain_realm]
     .example.com = EXAMPLE.COM
     example.com = EXAMPLE.COM
     server.example.com = EXAMPLE.COM
  • 以下のエラーが表示される場合には、Kerberos 認証情報がありません。

    No Kerberos credentials available

    このような場合は、kinit ユーティリティーを使用して Kerberos 認証情報を取得するか、SSSD で認証します。

    [idm-user@idm-client ~]$ kinit idm-user@IDM.EXAMPLE.COM
    Password for idm-user@idm.example.com:
  • /var/log/sssd/sssd_pam.log ログファイルに以下のエラーのいずれかが表示される場合には、Kerberos 認証情報と、現在ログインしたユーザーのユーザー名とが一致しません。

    User with UPN [<UPN>] was not found.
    
    UPN [<UPN>] does not match target user [<username>].

    このような場合は、SSSD で認証されたことを確認するか、/etc/sssd/sssd.conf ファイルで pam_gssapi_check_upn オプションを無効にすることを検討してください。

    [idm-user@idm-client ~]$ cat /etc/sssd/sssd.conf
    ...
    
    pam_gssapi_check_upn = false
  • 他のトラブルシューティングを行う場合は、PAM モジュール pam_sss_gss.so のデバッグ出力を有効してください。

    • /etc/pam.d/sudo/etc/pam.d/sudo-i など、PAM ファイルに pam_sss_gss.so の全エントリーの最後に debug オプションを追加します。

      [root@idm-client ~]# cat /etc/pam.d/sudo
      #%PAM-1.0
      auth       sufficient   pam_sss_gss.so   debug
      auth       include      system-auth
      account    include      system-auth
      password   include      system-auth
      session    include      system-auth
      [root@idm-client ~]# cat /etc/pam.d/sudo-i
      #%PAM-1.0
      auth       sufficient   pam_sss_gss.so   debug
      auth       include      sudo
      account    include      sudo
      password   include      sudo
      session    optional     pam_keyinit.so force revoke
      session    include      sudo
    • pam_sss_gss.so モジュールで認証を試み、コンソールの出力を確認します。この例では、ユーザーには Kerberos 認証情報がありません。

      [idm-user@idm-client ~]$ sudo ls -l /etc/sssd/sssd.conf
      pam_sss_gss: Initializing GSSAPI authentication with SSSD
      pam_sss_gss: Switching euid from 0 to 1366201107
      pam_sss_gss: Trying to establish security context
      pam_sss_gss: SSSD User name: idm-user@idm.example.com
      pam_sss_gss: User domain: idm.example.com
      pam_sss_gss: User principal:
      pam_sss_gss: Target name: host@idm.example.com
      pam_sss_gss: Using ccache: KCM:
      pam_sss_gss: Acquiring credentials, principal name will be derived
      pam_sss_gss: Unable to read credentials from [KCM:] [maj:0xd0000, min:0x96c73ac3]
      pam_sss_gss: GSSAPI: Unspecified GSS failure.  Minor code may provide more information
      pam_sss_gss: GSSAPI: No credentials cache found
      pam_sss_gss: Switching euid from 1366200907 to 0
      pam_sss_gss: System error [5]: Input/output error

8.10. 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 つまたは複数追加します。

    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: MySecret123
            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: MySecret123
            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 が正しく設定されている場合には、マシンが再起動します。

関連情報

  • /usr/share/doc/ansible-freeipa/ ディレクトリーの README-sudocmd.md ファイル、README-sudocmdgroup.md ファイル、および README-sudorule.md ファイルを参照してください。

第9章 ldapmodify を使用した IdM ユーザーの外部管理

ldapmodify ユーティリティーおよび ldapdelete ユーティリティーを使用して、コマンドラインインターフェイス (CLI) から Identity Management (IdM) LDAP を直接変更できます。このユーティリティーは、ディレクトリー内容の完全な追加、編集、および削除機能を提供します。これらのユーティリティーを使用して、サーバーの設定エントリーとユーザーエントリーのデータ両方を管理できます。このユーティリティーは、1 つまたは複数のディレクトリーを一括管理するためのスクリプトの記述にも使用できます。

9.1. IdM ユーザーアカウントを外部で管理するためのテンプレート

本セクションでは、IdM でのさまざまなユーザー管理操作のテンプレートについて説明します。これらのテンプレートでは、以下の目的を達成するために ldapmodify を使用して変更する必要のある属性がどれであるかが分かります。

  • 新規ステージユーザーの追加
  • ユーザーの属性変更
  • ユーザーの有効化
  • ユーザーの無効化
  • ユーザーの保存

テンプレートは LDAP データ交換形式 (LDIF) でフォーマットされます。LDIF は、LDAP ディレクトリーのコンテンツおよび更新リクエストを表す標準的なプレーンテキストデータ交換形式です。

テンプレートを使用し、プロビジョニングシステムの LDAP プロバイダーを設定して、IdM ユーザーアカウントを管理できます。

詳細な手順例は、以下のセクションを参照してください。

新規ステージユーザーを追加するためのテンプレート

  • 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

    ステージユーザーの追加時に 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 属性を更新してもステージユーザーおよび保存済みユーザーには影響はありません。更新操作が正常に完了しても、属性値は 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

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

    ステージまたは保存済みユーザーをグループに追加しないでください。更新操作が正常に完了しても、ユーザーはグループのメンバーとしては更新されません。アクティブなユーザーのみがグループに所属できます。

  • グループからのメンバーの削除

    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

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

第10章 ユーザーの外部プロビジョニングのための IdM 設定

システム管理者は、Identity Management (IdM) が、ID 管理用の外部ソリューションでユーザーのプロビジョニングをサポートするように設定できます。

ipa ユーティリティーを使用する代わりに、外部プロビジョニングシステムの管理者は ldapmodify ユーティリティーを使用して IdM LDAP にアクセスできます。管理者は、ldapmodify を使用して CLI から、または LDIF ファイル を使用して、個々のステージユーザーを追加できます。

IdM 管理者が外部プロビジョニングシステムを完全に信頼して、検証済みのユーザーだけを追加することを前提とします。ただし、新たにアクティブユーザーを直接追加できるように、外部プロビジョニングシステムの管理者に User Administrator の IdM ロールを割り当てなくても構いません。

外部プロビジョニングシステムで作成されたステージユーザーを自動的にアクティブユーザーに移動するように スクリプトを設定 できます。

本章には、以下の項が含まれます。

  1. Identity Management (IdM) の準備 して外部プロビジョニングシステムを使用してステージユーザーを IdM に追加する。
  2. 外部プロビジョニングシステムが追加したユーザーをステージユーザーからアクティブユーザーに移動する スクリプトを作成 する。
  3. 外部プロビジョニングシステムを使用して IdM ステージユーザーを追加する。これには 2 つの方法があります。

10.1. ステージユーザーアカウントの自動アクティベーションに向けた IdM アカウントの準備

以下の手順では、外部プロビジョニングシステムが使用する 2 つの IdM ユーザーアカウントを設定する方法を説明します。適切なパスワードポリシーが指定されたグループにアカウントを追加すると、外部プロビジョニングシステムが IdM でユーザーのプロビジョニングを管理できるようになります。以下では、ステージユーザーの追加用に外部システムが使用するユーザーアカウントには provisionator という名前が付けられます。ステージユーザーを自動アクティベートする時に使用されるユーザーアカウントは activator という名前です。

前提条件

  • 以下の手順を実行するホストが IdM に登録されている。

手順

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

    $ kinit admin
  2. ステージユーザーを追加する特権指定して provisionator という名前のユーザーを作成します。

    1. provisionator ユーザーアカウントを追加します。
    $ ipa user-add provisionator --first=provisioning --last=account --password
    1. provisionator ユーザーに必要な特権を割り当てます。

      1. ステージユーザーの追加を管理する System Provisioning というカスタムロールを作成します。

        $ ipa role-add --desc "Responsible for provisioning stage users" "System Provisioning"
      2. Stage User Provisioning の特権をロールに追加します。この特権により、ステージユーザーを追加できます。

        $ 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 ユーザーのパスワードはすぐに失効するため、パスワードの変更が必要になります。

関連情報:

10.2. IdM ステージユーザーアカウントの自動アクティベーションの設定

この手順では、ステージユーザーをアクティベートするスクリプトを作成する方法を説明します。システムは、指定した間隔でスクリプトを自動的に実行します。これにより、新規ユーザーアカウントが自動的にアクティベートされ、作成直後に使用できます。

重要

以下の手順では、外部プロビジョニングシステムの所有者がユーザーをすでに検証しており、スクリプトが IdM への追加前に IdM 側で追加の検証を必要としていないことを前提としています。

IdM サーバーの 1 つでのみアクティベーションプロセスを有効にするだけで十分です。

前提条件

手順

  1. アカウントのアクティベーション用に keytab ファイルを生成します。

    # ipa-getkeytab -s server.idm.example.com -p "activator" -k /etc/krb5.ipa-activation.keytab

    複数の IdM サーバーでアクティベーションプロセスを有効にする場合は、1 つのサーバーだけで keytab ファイルを生成します。次に、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.

10.3. LDIF ファイルで定義されている IdM stage ユーザーの追加

本セクションでは、外部プロビジョニングシステムの管理者が IdM LDAP にアクセスし、LDIF ファイルを使用してステージユーザーを追加する方法を説明します。以下の例では、ユーザーを 1 つ追加していますが、一括モードで 1 つのファイルに複数のユーザーを追加できます。

前提条件

  • IdM 管理者が、provisionator アカウントとパスワードを作成している。詳細は ステージユーザーアカウントの自動アクティベーション用の IdM アカウントの準備 を参照してください。
  • 外部管理者が provisionator アカウントのパスワードを知っている。
  • LDAP サーバーから IdM サーバーに SSH 接続できる。
  • 以下のような、ユーザーのライフサイクルを正しく処理できるように IdM ステージユーザーに割り当てる必要のある最小限の属性セットを提供できる。

    • 識別名 (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 ticket-granting ticket (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"

10.4. ldapmodify を使用した CLI からの IdM stage ユーザーの直接追加

本セクションでは、外部プロビジョニングシステムの管理者が Identity Management (IdM) LDAP にアクセスし、ldapmodify ユーティリティーを使用してステージユーザーを追加する方法を説明します。

前提条件

  • IdM 管理者が、provisionator アカウントおよびパスワードを作成している。詳細は ステージユーザーアカウントの自動アクティベーション用の IdM アカウントの準備 を参照してください。
  • 外部管理者が provisionator アカウントのパスワードを知っている。
  • LDAP サーバーから IdM サーバーに SSH 接続できる。
  • 以下のような、ユーザーのライフサイクルを正しく処理できるように IdM ステージユーザーに割り当てる必要のある最小限の属性セットを提供できる。

    • 識別名 (dn)
    • 共通名 (cn)
    • 名前 (姓) (sn)
    • uid

手順

  1. IdM の ID および認証情報を使用して、SSH プロトコルを使用して IdM サーバーに接続します。

    $ ssh provisionator@server.idm.example.com
    Password:
    [provisionator@server ~]$
  2. 新規ステージユーザーを追加するロールを持つ 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 を使用して接続を終了します。

検証手順

ステージエントリーの内容を検証し、プロビジョニングシステムにより、必要な全 POSIX 属性が追加され、ステージエントリーのアクティベートの準備ができていることを確認します。

  • 新規ステージユーザーの 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 属性を使用して明示的に無効化されている点に注意してください。

10.5. 関連情報

第11章 PAC 情報による Kerberos セキュリティーの強化

以下のセクションでは、RHEL 8.5 以降にデフォルトで、Identity Management (IdM) が特権属性証明書 (PAC) 情報を使用する方法について説明します。また、RHEL 8.5 より前にインストールされた IdM デプロイメントで、セキュリティー識別子 (SID) を有効にすることもできます。

11.1. IdM での特権属性証明書 (PAC) の使用

セキュリティーを強化するために、RHEL Identity Management (IdM) は、新しいデプロイメントでデフォルトで特権属性証明書 (PAC) 情報を含む Kerberos チケットを発行するようになりました。PAC には、セキュリティー識別子 (SID)、グループメンバーシップ、ホームディレクトリー情報など、Kerberos プリンシパルに関する豊富な情報が含まれています。

Microsoft Active Directory (AD) がデフォルトで使用する SID は、再利用されることのないグローバルに一意の識別子です。SID は複数の名前空間を表します。各ドメインには、各オブジェクトの SID の接頭辞である SID があります。

RHEL 8.5 以降、IdM サーバーまたはレプリカをインストールすると、インストールスクリプトはデフォルトでユーザーおよびグループの SID を生成します。これにより、IdM が PAC データを操作できるようになります。RHEL 8.5 より前に IdM をインストールし、AD ドメインとの信頼を設定していない場合は、IdM オブジェクトの SID が生成されていない可能性があります。IdM オブジェクトの SID の生成に関する詳細は、IdM でのセキュリティー識別子 (SID) の有効化 を参照してください。

Kerberos チケットの PAC 情報を評価することで、リソースアクセスをより詳細に制御できます。たとえば、あるドメインの管理者アカウントは、他のドメインの管理者アカウントとは一意に異なる SID を持っています。AD ドメインへの信頼がある IdM 環境では、UID が 0 のすべての Linux root アカウントなど、さまざまな場所で繰り返される可能性のある単純なユーザー名や UID ではなく、グローバルに一意の SID に基づいてアクセス制御を設定できます。

11.2. IdM でのセキュリティー識別子 (SID) の有効化

RHEL 8.5 より前に IdM をインストールし、AD ドメインとの信頼を設定していない場合は、IdM オブジェクトのセキュリティー識別子 (SID) が生成されていない可能性があります。これは、以前は SID を生成する場合、ipa-adtrust-install コマンドを実行して 信頼コントローラー ロールを IdM サーバーに追加することが唯一の方法だったためです。

RHEL 8.6 以降、IdM の Kerberos では、IdM オブジェクトに SID が必要です。これは、特権属性証明書 (PAC) 情報に基づくセキュリティーに必要です。

前提条件

  • RHEL 8.5 より前に IdM をインストールしている。
  • Active Directory ドメインとの信頼の設定の一部である ipa-sidgen タスクを実行していない。
  • IdM 管理者アカウントとして認証可能である。

手順

  • SID の使用を有効にし、SIDgen タスクをトリガーして、既存のユーザーとグループの SID を生成します。このタスクはリソースを大量に消費する可能性があります。

    [root@server ~]# ipa config-mod --enable-sid --add-sids

検証

  • IdM admin ユーザーアカウントエントリーに、-500 で終わる SID (ドメイン管理者用に予約されている SID) のある ipantsecurityidentifier 属性があることを確認します。

    [root@server ~]# ipa user-show admin --all | grep ipantsecurityidentifier
      ipantsecurityidentifier: S-1-5-21-2633809701-976279387-419745629-500

第12章 Kerberos チケットポリシーの管理

Identity Management (IdM) の Kerberos チケットポリシーは、Kerberos チケットアクセス、期間、および更新に対する制限を設定します。IdM サーバーで実行している Key Distribution Center (KDC) の Kerberos チケットポリシーを設定できます。

本章では、以下の Kerberos チケット管理のトピックとタスクについて説明します。

12.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/server.example.com@EXAMPLE.COM)
  • ホストの場合: host/fully-qualified-hostname@REALM (例: host/client.example.com@EXAMPLE.COM)

以下の図では、Kerberos クライアント、KDC、およびクライアントの通信先となる Kerberos を使用するアプリケーション間の通信を簡単にまとめています。

Kerberos KDC の通信フロー
  1. Kerberos クライアントは、Kerberos プリンシパルとして認証することで KDC に対して身分を証明します。たとえば、IdM ユーザーは kinit ユーザー名 を実行し、パスワードを指定します。
  2. KDC はデータベースのプリンシパルを確認し、クライアントを認証し、Kerberos チケットポリシー を評価してリクエストを付与するかどうかを判断します。
  3. KDC は、適切なチケットポリシーに従って、ライフサイクルおよび 認証インジケーター で Ticket-Granting Ticket (TGT) を発行します。
  4. TGT により、クライアントは KDC から サービスチケット を要求し、ターゲットホストで Kerberos を使用するサービスと通信します。
  5. KDC は、クライアントの TGT が有効であるかどうかを確認し、チケットポリシーに対してサービスチケット要求を評価します。
  6. KDC はクライアントに サービスチケット を発行します。
  7. サービスチケットを使用すると、クライアントはターゲットホストのサービスと暗号化された通信を開始できます。

12.2. IdM Kerberos チケットポリシータイプ

IdM Kerberos チケットポリシーは、以下のチケットポリシータイプを実装します。

接続ポリシー

異なるレベルのセキュリティーで Kerberos を使用するサービスを保護するには、接続ポリシーを定義して、TGT (Ticket-granting ticket) の取得にクライアントが使用する事前認証メカニズムをもとにルールを有効にすることができます。

たとえば client1.example.com に接続するには、スマートカード認証が、client2.example.comtestservice アプリケーションにアクセスするには、2 要素認証が必要です。

接続ポリシーを有効するには、認証インジケーター をサービスに関連付けます。必要な認証インジケーターがサービスチケット要求に含まれるクライアントのみがこれらのサービスにアクセスできます。詳細は、Kerberos 認証インジケーター を参照してください。

チケットライフサイクルポリシー

各 Kerberos チケットには 有効期間 と潜在的な 更新期間 があります。チケットは最長期間に達する前に更新できますが、更新期間の超過後には更新できません。

デフォルトのグローバルチケットの有効期間は 1 日 (86400 秒) で、デフォルトのグローバル最大更新期間は 1 週間 (604800 秒) です。これらのグローバル値を調整するには、グローバルチケットライフサイクルポリシーの設定 を参照してください。

独自のチケットライフサイクルポリシーを定義することもできます。

12.3. Kerberos 認証インジケーター

Kerberos Key Distribution Center (KDC) は、認証インジケーター を、ID の証明にクライアントが使用する事前認証メカニズムに基づいて TGT (Ticket-granting Ticket) に割り当てます。

otp
2 要素認証 (パスワード + ワンタイムパスワード)
radius
radius 認証 (通常は 802.1x 認証)
pkinit
PKINIT 、スマートカード、または証明書での認証
hardened
強化パスワード (SPAKE または FAST)[1]

次に KDC は、TGT からの認証インジケーターを、TGT から取得するサービスチケット要求に割り当てます。KDC は、認証インジケーターに基づいて、サービスアクセス制御、チケットの最大有効期間、および更新可能な期間などのポリシーを有効にします。

認証インジケーターおよび IdM サービス

サービスまたはホストを認証インジケーターに関連付けると、対応する認証メカニズムを使用して TGT を取得したクライアントのみがアクセスできるようになります。KDC はアプリケーションやサービスではなく、サービスチケット要求の認証インジケーターをチェックし、Kerberos 接続ポリシーに基づいて要求を付与または拒否します。

たとえば、仮想プライベートネットワーク (VPN) に接続するために 2 要素認証を要求するには、otp 認証インジケーターをそのサービスに関連付けます。KDC から最初の TGT を取得するのにワンタイムパスワードを使用したユーザーのみが VPN にログインできます。

図12.1 otp 認証インジケータを必要とする VPN サービスの例

認証インジケーター

サービスまたはホストに認証インジケーターが割り当てられていない場合には、メカニズムに関係なく認証されたチケットを受け入れます。



[1] 強化されたパスワードは、Single-Party Public-Key Authenticated Key Exchange (SPAKE) の事前認証または Flexible Authentication via Secure Tunneling (FAST) 防御を使用して、総当たりパスワード辞書攻撃を受けないようにセキュリティー保護されています。

12.4. IdM サービスの認証インジケーターの有効化

Identity Management (IdM) がサポートする認証メカニズムは、認証強度によって異なります。たとえば、標準パスワードと組み合わせて、ワンタイムパスワード (OTP) を使用して、最初の Kerberos Ticket-Granting Ticket (TGT) を取得することは、標準パスワードのみを使用する認証よりも安全と見なされます。

認証インジケーターを特定の IdM サービスに関連付けることで、IdM 管理者として、これらの特定の事前認証メカニズムを使用して最初の Ticket-Granting Ticket (TGT) を取得したユーザーのみがサービスにアクセスできるようにサービスを設定できます。

この方法では、以下のように異なる IdM サービスを設定できます。

  • ワンタイムパスワード (OTP) などのより強力な認証方法を使用して最初の TGT を取得したユーザーのみが、VPN などのセキュリティーにとって重要なサービスにアクセスできます。
  • パスワードなど、より簡単な認証方法を使用して初期の TGT を取得したユーザーは、ローカルログインなどの重要でないサービスにのみアクセスできます。

図12.2 異なる技術を使用した認証の例

認証インジケーター

以下の手順では、IdM サービスを作成し、着信サービスチケット要求から特定の Kerberos 認証インジケーターを必要とするように設定する方法を説明します。

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

検証手順

  1. 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
  2. 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)

12.4.2. IdM CLI を使用した IdM サービスへの認証インジケーターの関連付け

Identity Management (Id M) 管理者は、クライアントアプリケーションによって提示されるサービスチケットに特定の認証インジケーターが含まれていることを要求するようにホストまたはサービスを設定できます。たとえば、Kerberos Ticket-Granting Ticket (TGT) を取得する際に、パスワードで有効な IdM 2 要素認証トークンを使用したユーザーのみが、そのホストまたはサービスにアクセスできるようにできます。

以下の手順では、受信サービスチケット要求から特定の 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

    たとえば、スマートカードまたは OTP 認証で認証したユーザーには client.example.com ホストの testservice プリンシパルを取得させるようにするには、以下を実行します。

    [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

12.4.3. IdM Web UI を使用した IdM サービスへの認証インジケーターの関連付け

Identity Management (IdM) 管理者は、ホストまたはサービスが、クライアントアプリケーションが提示するサービスチケットを特定の認証インジケーターを含むように設定できます。たとえば、Kerberos Ticket-Granting Ticket (TGT) を取得する際に、パスワードで有効な IdM 2 要素認証トークンを使用したユーザーのみが、そのホストまたはサービスにアクセスできるようにできます。

この手順では、IdM Web UI を使用して、着信チケット要求から特定の Kerberos 認証インジケーターを必要とするようにホストまたはサービスを設定する方法を説明します。

前提条件

  • 管理ユーザーとして IdM Web UI にログインしている。

手順

  1. IdentityHosts または IdentityServices を選択します。
  2. 必要なホストまたはサービスの名前をクリックします。
  3. Authentication indicators で、必要な認証方法を選択します。

    • たとえば、OTP を選択すると、Kerberos TGT を取得する際に、パスワードで有効な IdM 2 要素認証トークンを使用したユーザーのみが、ホストまたはサービスにアクセスできるようになります。
    • OTPRADIUS の両方を選択した場合は、Kerberos TGT を取得する際に有効な IdM 二要素認証トークンとパスワードを使用したユーザー および Kerberos TGT の取得に RADIUS サーバーを使用したユーザーの両方が、アクセスを許可されます。
  4. ページ上部にある Save をクリックします。

12.4.4. IdM サービスの Kerberos サービスチケットの取得

以下の手順では、IdM サービスの Kerberos サービスチケットを取得する方法を説明します。この手順を使用して、特定の Kerberos 認証インジケーターが Ticket-Granting Ticket (TGT) に存在することを強制するなど、Kerberos チケットポリシーをテストできます。

前提条件

手順

  • サービスチケットを取得するには、kvno コマンドに -S オプションを指定して、IdM サービスの名前と管理するホストの完全修飾ドメイン名を指定します。

    [root@server ~]# kvno -S testservice client.example.com
    testservice/client.example.com@EXAMPLE.COM: kvno = 1
注記

IdM サービスにアクセスする必要があり、現在の Ticket-Granting Ticket (TGT) に必要な Kerberos 認証インジケーターが関連付けられていない場合は、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

12.4.5. 関連情報

12.5. グローバルチケットライフサイクルポリシーの設定

グローバルチケットポリシーは、すべてのサービスチケットとユーザーごとのチケットポリシーが定義されていないユーザーに適用されます。

以下の手順では、ipa krbtpolicy-mod コマンドを使用して、グローバル Kerberos チケットポリシーのチケットの最大有効期間と最大更新期間を調整する方法を説明します。

ipa krbtpolicy-mod コマンドを使用する場合は、以下の引数のいずれかを指定します。

  • --maxlife - チケットの最大有効期間 (秒単位)
  • --maxrenew - 更新可能な最大期間 (秒単位)

手順

  1. グローバルチケットポリシーを変更するには、以下を実行します。

    [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 秒) に設定されています。

  2. オプション: グローバルの Kerberos チケットポリシーをデフォルトのインストール値にリセットするには、以下を実行します。

    [root@server ~]# ipa krbtpolicy-reset
      Max life: 86400
      Max renew: 604800

検証手順

  • グローバルチケットポリシーを表示します。

    [root@server ~]# ipa krbtpolicy-show
      Max life: 28800
      Max renew: 86640

12.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 life および Max renew 値とは異なることに注意してください。

12.7. ユーザーのデフォルトチケットポリシーの設定

一意の Kerberos チケットポリシーを定義して、単一のユーザーだけに適用できます。これらのユーザーごとの設定は、すべての認証インジケーターに対してグローバルチケットポリシーをオーバーライドします。

ipa krbtpolicy-mod username コマンドを使用して、最低でも以下のいずれかの引数を指定します。

  • --maxlife - チケットの最大有効期間 (秒単位)
  • --maxrenew - 更新可能な最大期間 (秒単位)

手順

  1. たとえば、IdM 管理者 ユーザーの最大チケット期間を 2 日に、最大更新期間を 2 週に設定するには、次のコマンドを実行します。

    [root@server ~]# ipa krbtpolicy-mod admin --maxlife=172800 --maxrenew=1209600
      Max life: 172800
      Max renew: 1209600
  2. オプション: ユーザーのチケットポリシーをリセットするには、以下を実行します。

    [root@server ~]# ipa krbtpolicy-reset admin

検証手順

  • ユーザーに適用される有効な Kerberos チケットポリシーを表示します。

    [root@server ~]# ipa krbtpolicy-show admin
      Max life: 172800
      Max renew: 1209600

12.8. ユーザーの個別認証インジケーターチケットポリシーの設定

管理者は、ユーザーに、認証インジケーター別に異なる Kerberos チケットポリシーを定義できます。たとえば、IdM 管理者 ユーザーは、チケットを OTP 認証で取得した場合には 2 日間、スマートカード認証で取得した場合には 1 週間更新できるようにポリシーを設定できます。

これらの認証インジケーター設定は、ユーザーの デフォルトのチケットポリシー、グローバル デフォルトチケットポリシー、および グローバル 認証インジケーターチケットポリシーをオーバーライドします。

ipa krbtpolicy-mod username コマンドを使用して、それぞれに割り当てられた 認証インジケーター に合わせて、ユーザー Kerberos チケットのカスタム最大有効期間および最大の更新可能期間を設定します。

手順

  1. たとえば、ワンタイムパスワード認証でチケットを取得した場合に IdM admin ユーザーが 2 日間 Kerberos チケットを更新できるようにするには、--otp-maxrenew オプションを設定します。

    [root@server ~]# ipa krbtpolicy-mod admin --otp-maxrenew=$((2*24*60*60))
      OTP max renew: 172800
  2. オプション: ユーザーのチケットポリシーをリセットするには、以下を実行します。

    [root@server ~]# ipa krbtpolicy-reset username

検証手順

  • ユーザーに適用される有効な Kerberos チケットポリシーを表示します。

    [root@server ~]# ipa krbtpolicy-show admin
      Max life: 28800
      Max renew: 86640

12.9. krbtpolicy-mod コマンドの認証インジケーターオプション

以下の引数で認証インジケーターの値を指定します。

表12.1 krbtpolicy-mod コマンドの認証インジケーターオプション

認証インジケーター最大有効期間の引数最大更新期間の引数

otp

--otp-maxlife

--otp-maxrenew

radius

--radius-maxlife

--radius-maxrenew

pkinit

--pkinit-maxlife

--pkinit-maxrenew

hardened

--hardened-maxlife

--hardened-maxrenew

第13章 IdM Kerberos キータブファイルの維持

以下のドキュメントでは、Kerberos キータブファイルとは何か、および Identity Management (IdM) がそれらを使用してサービスが Kerberos で安全に認証できるようにする方法について説明します。

この情報を使用して、これらの機密ファイルを保護する必要がある理由を理解し、IdM サービス間の通信の問題をトラブルシューティングできます。

このセクションでは、以下のトピックについて説明します。

13.1. Identity Management が Kerberos キータブファイルを使用する方法

Kerberos キータブは、Kerberos プリンシパルとそれに対応する暗号化キーを含むファイルです。ホスト、サービス、ユーザー、およびスクリプトは、キータブを使用して、人間の介入を必要とせずに、Kerberos Key Distribution Center (KDC) に対して安全に認証することができます。

IdM サーバー上のすべての IdM サービスには、Kerberos データベースに格納された一意の Kerberos プリンシパルがあります。たとえば、IdM サーバー east.idm.example.com および west.idm.example.com が DNS サービスを提供する場合、IdM はこれらのサービスを識別するために 2 つの一意の DNS Kerberos プリンシパルを作成します。これらは、命名規則 <service>/host.domain.com@REALM.COM に従います:

  • DNS/east.idm.example.com@IDM.EXAMPLE.COM
  • DNS/west.idm.example.com@IDM.EXAMPLE.COM

IdM は、Kerberos キーのローカルコピーをキーバージョン番号 (KVNO) とともに保存するために、これらのサービスごとにサーバー上にキータブを作成します。たとえば、デフォルトのキータブファイル /etc/krb5.keytab には host プリンシパルが格納されます。このプリンシパルは、Kerberos レルム内のそのマシンを表し、ログイン認証に使用されます。KDC は、aes256-cts-hmac-sha1-96 および aes128-cts-hmac-sha1-96 など、サポートするさまざまな暗号化アルゴリズムの暗号化キーを生成します。

klist コマンドを使用して、キータブファイルの内容を表示できます。

[root@idmserver ~]# klist -ekt /etc/krb5.keytab
Keytab name: FILE:/etc/krb5.keytab
KVNO Timestamp           Principal
---- ------------------- ------------------------------------------------------
   2 02/24/2022 20:28:09 host/idmserver.idm.example.com@IDM.EXAMPLE.COM (aes256-cts-hmac-sha1-96)
   2 02/24/2022 20:28:09 host/idmserver.idm.example.com@IDM.EXAMPLE.COM (aes128-cts-hmac-sha1-96)
   2 02/24/2022 20:28:09 host/idmserver.idm.example.com@IDM.EXAMPLE.COM (camellia128-cts-cmac)
   2 02/24/2022 20:28:09 host/idmserver.idm.example.com@IDM.EXAMPLE.COM (camellia256-cts-cmac)

13.2. Kerberos キータブファイルが IdM データベースと同期していることの確認

Kerberos パスワードを変更すると、IdM は対応する新しい Kerberos キーを自動的に生成し、そのキーバージョン番号 (KVNO) を増やします。Kerberos キータブが新しいキーと KVNO で更新されていない場合、そのキータブに依存して有効なキーを取得するサービスは、Kerberos キー配布センター (KDC) に対して認証できない可能性があります。

IdM サービスの 1 つが別のサービスと通信できない場合は、次の手順を使用して、Kerberos キータブファイルが IdM データベースに保存されているキーと同期していることを確認します。それらが同期していない場合は、更新されたキーと KVNO を使用して Kerberos キータブを取得します。この例では、IdM サーバーの更新された DNS プリンシパルを比較して取得します。

前提条件

  • キータブファイルを取得するには、IdM 管理者アカウントとして認証する必要がある。
  • 他のユーザーが所有するキータブファイルを変更するには、root アカウントとして認証する必要がある。

手順

  1. 検証しているキータブでプリンシパルの KVNO を表示します。次の例では、/etc/named.keytab ファイルに、KVNO が 2 の DNS/server1.idm.example.com@EXAMPLE.COM プリンシパルのキーがあります。

    [root@server1 ~]# klist -ekt /etc/named.keytab
    Keytab name: FILE:/etc/named.keytab
    KVNO Timestamp           Principal
    ---- ------------------- ------------------------------------------------------
       2 11/26/2021 13:51:11 DNS/server1.idm.example.com@EXAMPLE.COM (aes256-cts-hmac-sha1-96)
       2 11/26/2021 13:51:11 DNS/server1.idm.example.com@EXAMPLE.COM (aes128-cts-hmac-sha1-96)
       2 11/26/2021 13:51:11 DNS/server1.idm.example.com@EXAMPLE.COM (camellia128-cts-cmac)
       2 11/26/2021 13:51:11 DNS/server1.idm.example.com@EXAMPLE.COM (camellia256-cts-cmac)
  2. IdM データベースに保存されているプリンシパルの KVNO を表示します。この例では、IdM データベースのキーの KVNO がキータブの KVNO と一致しません。

    [root@server1 ~]# kvno DNS/server1.idm.example.com@EXAMPLE.COM
    DNS/server1.idm.example.com@EXAMPLE.COM: kvno = 3
  3. IdM 管理者アカウントとして認証します。

    [root@server1 ~]# kinit admin
    Password for admin@IDM.EXAMPLE.COM:
  4. プリンシパルの更新された Kerberos キーを取得し、キータブに保存します。root ユーザーとしてこのステップを実行して、named ユーザーが所有する /etc/named.keytab ファイルを変更できるようにします。

    [root@server1 ~]# ipa-getkeytab -s server1.idm.example.com -p DNS/server1.idm.example.com -k /etc/named.keytab

検証

  1. プリンシパルの更新された KVNO をキータブに表示します。

    [root@server1 ~]# klist -ekt /etc/named.keytab
    Keytab name: FILE:/etc/named.keytab
    KVNO Timestamp           Principal
    ---- ------------------- ------------------------------------------------------
       4 08/17/2022 14:42:11 DNS/server1.idm.example.com@EXAMPLE.COM (aes256-cts-hmac-sha1-96)
       4 08/17/2022 14:42:11 DNS/server1.idm.example.com@EXAMPLE.COM (aes128-cts-hmac-sha1-96)
       4 08/17/2022 14:42:11 DNS/server1.idm.example.com@EXAMPLE.COM (camellia128-cts-cmac)
       4 08/17/2022 14:42:11 DNS/server1.idm.example.com@EXAMPLE.COM (camellia256-cts-cmac)
  2. IdM データベースに保存されているプリンシパルの KVNO を表示し、キータブの KVNO と一致することを確認します。

    [root@server1 ~]# kvno DNS/server1.idm.example.com@EXAMPLE.COM
    DNS/server1.idm.example.com@EXAMPLE.COM: kvno = 4

13.3. IdM Kerberos キータブファイルとその内容のリスト

以下の表は、IdM Kerberos キータブファイルの場所、内容、および目的を示しています。

表13.1 テーブル

キータブの場所内容目的

/etc/krb5.keytab

host プリンシパル

ログイン時にユーザーの認証情報を確認します (nfs プリンシパルがない場合に NFS によって使用されます)。

/etc/dirsrv/ds.keytab

ldap プリンシパル

IdM データベースに対してユーザーを認証し、IdM レプリカ間でデータベースの内容を安全に複製します。

/var/lib/ipa/gssproxy/http.keytab

HTTP プリンシパル

Apache サーバーに対して認証します。

/etc/named.keytab

DNS プリンシパル

DNS レコードを安全に更新します。

/etc/ipa/dnssec/ipa-dnskeysyncd.keytab

ipa-dnskeysyncd principal

OpenDNSSEC と LDAP の同期を維持します。

/etc/pki/pki-tomcat/dogtag.keytab

dogtag プリンシパル

認証局 (CA) と通信します。

/etc/samba/samba.keytab

cifs プリンシパルと host プリンシパル

Samba サービスと通信します。

/var/lib/sss/keytabs/ad-domain.com.keytab

HOSTNAME$@AD-DOMAIN.COM 形式の Active Directory (AD) ドメインコントローラー (DC) プリンシパル

IdM-AD 信頼を介して AD DC と通信します。

第14章 IdM での KDC プロキシーの使用

一部の管理者は、デプロイメントでデフォルトの Kerberos ポートにアクセスできないようにすることを選択する場合があります。ユーザー、ホスト、およびサービスが Kerberos 認証情報を取得できるようにするために、HTTPS ポート 443 を介して Kerberos と通信するプロキシーとして HTTPS サービスを使用できます。

Identity Management (IdM) では、Kerberos Key Distribution Center Proxy (KKDCP) がこの機能を提供します。

IdM サーバーでは、KKDCP はデフォルトで有効で、https://server.idm.example.com/KdcProxy で利用できます。IdM クライアントでは、KDCP にアクセスするために、その Kerberos 設定を変更する必要があります。

14.1. KKDCP を使用するための IdM クライアントの設定

Identity Management (IdM) システム管理者は、IdM サーバーで Kerberos Key Distribution Center Proxy (KKDCP) を使用するように IdM クライアントを設定できます。これは、デフォルトの Kerberos ポートが IdM サーバーでアクセスできず、HTTPS ポート 443 が Kerberos サービスにアクセスする唯一の方法である場合に役立ちます。

前提条件

  • IdM クライアントへの root アクセス権限がある。

手順

  1. /etc/krb5.conf ファイルを開いて編集します。
  2. [realms] セクションで、kdcadmin_server、および kpasswd_server オプションの KKDCP の URL を入力します。

    [realms]
    EXAMPLE.COM = {
      kdc = https://kdc.example.com/KdcProxy
      admin_server = https://kdc.example.com/KdcProxy
      kpasswd_server = https://kdc.example.com/KdcProxy
      default_domain = example.com
    }

    冗長性の場合は、パラメーター kdcadmin_server、および kpasswd_server を複数回追加して、別の KDCP サーバーを示すことができます。

  3. sssd を再起動して、変更を有効にします。

    ~]# systemctl restart sssd

14.2. IdM サーバーで KKDCP が有効になっていることの確認

Identity Management (Id M) サーバーでは、属性と値のペア ipaConfigString=kdcProxyEnabled がディレクトリーに存在する場合、Apache Web サーバーが起動するたびに Kerberos Key Distribution Center Proxy (KKDCP) が自動的に有効になります。この場合は、シンボリックリンク /etc/httpd/conf.d/ipa-kdc-proxy.conf が作成されます。

非特権ユーザーであっても、IdM サーバーで KKDCP が有効になっているかどうかを確認できます。

手順

  • シンボリックリンクが存在することを確認します。
$ ls -l /etc/httpd/conf.d/ipa-kdc-proxy.conf
lrwxrwxrwx. 1 root root 36 Jun 21  2020 /etc/httpd/conf.d/ipa-kdc-proxy.conf -> /etc/ipa/kdcproxy/ipa-kdc-proxy.conf

この出力は、KKDCP が有効になっていることを確認します。

14.3. IdM サーバーでの KDCP の無効化

Identity Management (IdM) システム管理者は、IdM サーバーで Kerberos Key Distribution Center Proxy (KKDCP) を無効にできます。

前提条件

  • IdM サーバーへの root アクセス権限がある。

手順

  1. ディレクトリーから ipaConfigString=kdcProxyEnabled 属性と値のペアを削除します。

    # ipa-ldap-updater /usr/share/ipa/kdcproxy-disable.uldif
    Update complete
    The ipa-ldap-updater command was successful
  2. httpd サービスを再起動します。

    # systemctl restart httpd.service

現在の IdM サーバーで、KDCP が無効になりました。

検証手順

  • シンボリックリンクが存在しないことを確認します。

    $ ls -l /etc/httpd/conf.d/ipa-kdc-proxy.conf
    ls: cannot access '/etc/httpd/conf.d/ipa-kdc-proxy.conf': No such file or directory

14.4. IdM サーバーでの KDCP の再有効化

IdM サーバーでは、Kerberos Key Distribution Center Proxy (KKDCP) はデフォルトで有効で、https://server.idm.example.com/KdcProxy で利用できます。

KDCP がサーバーで無効になっている場合は、再度有効にできます。

前提条件

  • IdM サーバーへの root アクセス権限がある。

手順

  1. ipaConfigString=kdcProxyEnabled 属性と値のペアをディレクトリーに追加します。

    # ipa-ldap-updater /usr/share/ipa/kdcproxy-enable.uldif
    Update complete
    The ipa-ldap-updater command was successful
  2. httpd サービスを再起動します。

    # systemctl restart httpd.service

現在の IdM サーバーで KDCP が有効になりました。

検証手順

  • シンボリックリンクが存在することを確認します。

    $ ls -l /etc/httpd/conf.d/ipa-kdc-proxy.conf
    lrwxrwxrwx. 1 root root 36 Jun 21  2020 /etc/httpd/conf.d/ipa-kdc-proxy.conf -> /etc/ipa/kdcproxy/ipa-kdc-proxy.conf

14.5. KKDCP サーバー I の設定

以下の設定により、複数の Kerberos サーバーが使用される IdM KKDCP と Active Directory (AD) レルム間のトランスポートプロトコルとして TCP を使用できるようになります。

前提条件

  • root アクセスがある。

手順

  1. /etc/ipa/kdcproxy/kdcproxy.conf ファイルの [global] セクションにある use_dns パラメーターを false に設定します。

    [global]
    use_dns = false
  2. プロキシーされたレルム情報を /etc/ipa/kdcproxy/kdcproxy.conf ファイルに入れます。たとえば、プロキシーを使用する [AD.EXAMPLE.COM] レルムの場合、次のようにレルム設定パラメーターを一覧表示します。

    [AD.EXAMPLE.COM]
    kerberos = kerberos+tcp://1.2.3.4:88 kerberos+tcp://5.6.7.8:88
    kpasswd = kpasswd+tcp://1.2.3.4:464 kpasswd+tcp://5.6.7.8:464
    重要

    特定のオプションが複数回指定される可能性がある /etc/krb5.conf および kdc.conf とは対照的に、レルム設定パラメーターは、スペースで区切られた複数のサーバーをリストする必要があります。

  3. Identity Management (IdM) サービスを再起動します。

    # ipactl restart

関連情報

14.6. KKDCP サーバー II の設定

次のサーバー設定は、DNS サービスレコードに依存して、通信する Active Directory (AD) サーバーを検索します。

前提条件

  • root アクセスがある。

手順

  1. /etc/ipa/kdcproxy/kdcproxy.conf ファイルの global セクションで、use_dns パラメーターを true に設定します。

    [global]
    configs = mit
    use_dns = true

    configs パラメーターを使用すると、他の設定モジュールをロードできます。この場合、設定は MIT libkrb5 ライブラリーから読み取られます。

  2. オプション: DNS サービスレコードを使用したくない場合は、明示的な AD サーバーを /etc/krb5.conf ファイルの [realms] セクションに追加します。たとえば、プロキシーを使用するレルムが AD.EXAMPLE.COM の場合は、以下を追加します。

    [realms]
    AD.EXAMPLE.COM = {
        kdc = ad-server.ad.example.com
        kpasswd_server = ad-server.ad.example.com
    }
  3. Identity Management (IdM) サービスを再起動します。

    # ipactl restart

関連情報

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

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

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

セルフサービスのアクセス制御ルールは、Identity Management (IdM) エンティティーが IdM Directory Server エントリーで実行できる操作を定義します (例: IdM ユーザーが独自のパスワードを更新できるなど)。

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

警告

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

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

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

前提条件

  • IdM、または ユーザー管理者 ロールを管理する管理者権限
  • 有効な Kerberos チケット。詳細は、Using kinit to log in to IdM manually を参照してください。

手順

  • セルフサービスルールを追加するには、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

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

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

前提条件

  • IdM、または ユーザー管理者 ロールを管理する管理者権限
  • 有効な Kerberos チケット。詳細は、Using kinit to log in to IdM manually を参照してください。

手順

  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

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

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

前提条件

  • IdM、または ユーザー管理者 ロールを管理する管理者権限
  • 有効な Kerberos チケット。詳細は、Using kinit to log in to IdM manually を参照してください。

手順

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

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

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

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

セルフサービスのアクセス制御ルールは、Identity Management (IdM) エンティティーが IdM Directory Server エントリーで実行できる操作を定義します (例: IdM ユーザーが独自のパスワードを更新できるなど)。

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

警告

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

16.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 ボタンをクリックしてさらにルールを保存および追加できます。

16.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 ボタンをクリックして、セルフサービスルールへの変更を保存します。

16.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 をクリックして確認します。

第17章 Ansible Playbook を使用した IdM でのセルフサービスルールの管理

本セクションでは、Identity Management (IdM) のセルフサービスルールを紹介し、Ansible Playbook を使用してセルフサービスアクセスルールを作成および編集する方法を説明します。セルフサービスのアクセス制御ルールにより、IdM エンティティーは IdM Directory Server エントリーで指定の操作を実行できます。

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

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

セルフサービスのアクセス制御ルールは、Identity Management (IdM) エンティティーが IdM Directory Server エントリーで実行できる操作を定義します (例: IdM ユーザーが独自のパスワードを更新できるなど)。

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

警告

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

17.2. Ansible を使用してセルフサービスルールを存在させる手順

以下の手順では、Ansible Playbook を使用してセルフサービスルールを定義し、Identity Management (IdM) サーバーに存在させる方法を説明します。この例では、ユーザーが自分の名前の情報を管理できる 新しいルールでは、ユーザーに、自分の givennamedisplaynametitle、および initials 属性を変更できるよ権限を付与します。たとえば、表示名や初期などを変更することができます。

前提条件

  • IdM 管理者パスワードを把握している。
  • 以下の要件を満たす Ansible コントロールノードを設定している。

    • Ansible バージョン 2.8 以降を使用している。
    • Ansible コントローラーに ansible-freeipa パッケージがインストールされている。
    • ~/MyPlaybooks/ ディレクトリーに、このオプションを設定する IdM サーバーの完全修飾ドメイン名 (FQDN) で Ansible インベントリーファイル を作成している。

手順

  1. ~/ MyPlaybooks/ ディレクトリーに移動します。

    $ cd ~/MyPlaybooks/
  2. /usr/share/doc/ansible-freeipa/playbooks/selfservice/ ディレクトリーにある selfservice-present.yml のコピーを作成します。

    $ cp /usr/share/doc/ansible-freeipa/playbooks/selfservice/selfservice-present.yml selfservice-present-copy.yml
  3. Ansible Playbook ファイル (selfservice-present-copy.yml) を開きます。
  4. ipaselfservice タスクセクションに以下の変数を設定してファイルを調整します。

    • ipaadmin_password 変数は IdM 管理者のパスワードに設定します。
    • name 変数は、新しいセルフサービスルールの名前に設定します。
    • permission 変数は、付与するパーミッションをコンマ区切りの一覧 (read および write) で設定します。
    • attribute 変数は、ユーザーが管理できる属性 (givennamedisplaynametitle、および initials) を一覧として設定します。

    以下は、今回の例で使用するように変更した Ansible Playbook ファイルです。

    ---
    - name: Self-service present
      hosts: ipaserver
      become: true
    
      tasks:
      - name: Ensure self-service rule "Users can manage their own name details" is present
        ipaselfservice:
          ipaadmin_password: Secret123
          name: "Users can manage their own name details"
          permission: read, write
          attribute:
          - givenname
          - displayname
          - title
          - initials
  5. ファイルを保存します。
  6. Playbook ファイルとインベントリーファイルを指定して Ansible Playbook を実行します。

    $ ansible-playbook -v -i inventory selfservice-present-copy.yml

関連情報

  • IdM でのセルフサービスアクセス制御 を参照してください。
  • /usr/share/doc/ansible-freeipa/ ディレクトリーの README-selfservice.md ファイルを参照してください。
  • /usr/share/doc/ansible-freeipa/playbooks/selfservice ディレクトリーを参照してください。

17.3. Ansible を使用してセルフサービスルールがないことを確認する手順

以下の手順では、Ansible Playbook を使用して、指定したセルフサービスルールが IdM 設定に存在しないことを確認する方法を説明します。以下の例では、ユーザーが自分の名前の詳細 のセルフサービスルールが IdM に存在しないことを確認する方法を説明します。これにより、ユーザーは自分の表示名や初期などを変更できないようにします。

前提条件

  • IdM 管理者パスワードを把握している。
  • 以下の要件を満たす Ansible コントロールノードを設定している。

    • Ansible バージョン 2.8 以降を使用している。
    • Ansible コントローラーに ansible-freeipa パッケージがインストールされている。
    • ~/MyPlaybooks/ ディレクトリーに、このオプションを設定する IdM サーバーの完全修飾ドメイン名 (FQDN) で Ansible インベントリーファイル を作成している。

手順

  1. ~/ MyPlaybooks/ ディレクトリーに移動します。

    $ cd ~/MyPlaybooks/
  2. /usr/share/doc/ansible-freeipa/playbooks/selfservice/ ディレクトリーにある selfservice-absent.yml ファイルのコピーを作成します。

    $ cp /usr/share/doc/ansible-freeipa/playbooks/selfservice/selfservice-absent.yml selfservice-absent-copy.yml
  3. Ansible Playbook ファイル (selfservice-absent-copy.yml) を開きます。
  4. ipaselfservice タスクセクションに以下の変数を設定してファイルを調整します。

    • ipaadmin_password 変数は IdM 管理者のパスワードに設定します。
    • name 変数は、セルフサービスルールの名前に設定します。
    • state 変数は absent に設定します。

    以下は、今回の例で使用するように変更した Ansible Playbook ファイルです。

    ---
    - name: Self-service absent
      hosts: ipaserver
      become: true
    
      tasks:
      - name: Ensure self-service rule "Users can manage their own name details" is absent
        ipaselfservice:
          ipaadmin_password: Secret123
          name: "Users can manage their own name details"
          state: absent
  5. ファイルを保存します。
  6. Playbook ファイルとインベントリーファイルを指定して Ansible Playbook を実行します。

    $ ansible-playbook -v -i inventory selfservice-absent-copy.yml

関連情報

  • IdM でのセルフサービスアクセス制御 を参照してください。
  • /usr/share/doc/ansible-freeipa/ ディレクトリーの README-selfservice.md ファイルを参照してください。
  • /usr/share/doc/ansible-freeipa/playbooks/selfservice ディレクトリーのサンプルの Playbook を参照してください。

17.4. Ansible を使用してセルフサービスルールに固有の属性を含める手順

以下の手順では、Ansible Playbook を使用して、既存のセルフサービスルールに特定の設定を追加する方法を説明します。この例では、ユーザーは自分の名前詳細を管理できる のセルフサービスルールに、surname のメンバー属性が含まれるようにします。

前提条件

  • IdM 管理者パスワードを把握している。
  • 以下の要件を満たす Ansible コントロールノードを設定している。

    • Ansible バージョン 2.8 以降を使用している。
    • Ansible コントローラーに ansible-freeipa パッケージがインストールされている。
    • ~/MyPlaybooks/ ディレクトリーに、このオプションを設定する IdM サーバーの完全修飾ドメイン名 (FQDN) で Ansible インベントリーファイル を作成している。
  • ユーザーが独自の名前の詳細 セルフサービスルールが IdM に存在する。

手順

  1. ~/ MyPlaybooks/ ディレクトリーに移動します。

    $ cd ~/MyPlaybooks/
  2. /usr/share/doc/ansible-freeipa/playbooks/selfservice/ ディレクトリーにある selfservice-member-present.yml ファイルのコピーを作成します。

    $ cp /usr/share/doc/ansible-freeipa/playbooks/selfservice/selfservice-member-present.yml selfservice-member-present-copy.yml
  3. Ansible Playbook ファイル (selfservice-member-present-copy.yml) を開きます。
  4. ipaselfservice タスクセクションに以下の変数を設定してファイルを調整します。

    • ipaadmin_password 変数は IdM 管理者のパスワードに設定します。
    • name 変数は、変更するセルフサービスルールの名前に設定します。
    • attribte 変数は surname に設定します。
    • action 変数は member に設定します。

    以下は、今回の例で使用するように変更した Ansible Playbook ファイルです。

    ---
    - name: Self-service member present
      hosts: ipaserver
      become: true
    
      tasks:
      - name: Ensure selfservice "Users can manage their own name details" member attribute surname is present
        ipaselfservice:
          ipaadmin_password: Secret123
          name: "Users can manage their own name details"
          attribute:
          - surname
          action: member
  5. ファイルを保存します。
  6. Playbook ファイルとインベントリーファイルを指定して Ansible Playbook を実行します。

    $ ansible-playbook -v -i inventory selfservice-member-present-copy.yml

関連情報

  • IdM でのセルフサービスアクセス制御 を参照してください。
  • /usr/share/doc/ansible-freeipa/ ディレクトリーで利用可能な README-selfservice.md ファイルを参照してください。
  • /usr/share/doc/ansible-freeipa/playbooks/selfservice ディレクトリーのサンプルの Playbook を参照してください。

17.5. Ansible を使用してセルフサービスルールに固有の属性を含めいないようにする手順

以下の手順では、Ansible Playbook を使用して、セルフサービスルールに特定の設定が割り当てられないようにする方法を説明します。この Playbook を使用して、セルフサービスルールで不必要なアクセス権限を付与しないようにします。この例では、ユーザーが独自の名前の詳細を管理できる セルフサービスルールに givennamesurname のメンバー属性が含まれないようにします。

前提条件

  • IdM 管理者パスワードを把握している。
  • 以下の要件を満たす Ansible コントロールノードを設定している。

    • Ansible バージョン 2.8 以降を使用している。
    • Ansible コントローラーに ansible-freeipa パッケージがインストールされている。
    • ~/MyPlaybooks/ ディレクトリーに、このオプションを設定する IdM サーバーの完全修飾ドメイン名 (FQDN) で Ansible インベントリーファイル を作成している。
  • ユーザーが独自の名前の詳細 セルフサービスルールが IdM に存在する。

手順

  1. ~/ MyPlaybooks/ ディレクトリーに移動します。

    $ cd ~/MyPlaybooks/
  2. /usr/share/doc/ansible-freeipa/playbooks/selfservice/ ディレクトリーにある selfservice-member-absent.yml ファイルのコピーを作成します。

    $ cp /usr/share/doc/ansible-freeipa/playbooks/selfservice/selfservice-member-absent.yml selfservice-member-absent-copy.yml
  3. Ansible Playbook ファイル (selfservice-member-absent-copy.yml) を開きます。
  4. ipaselfservice タスクセクションに以下の変数を設定してファイルを調整します。

    • ipaadmin_password 変数は IdM 管理者のパスワードに設定します。
    • name 変数は、変更するセルフサービスルールの名前に設定します。
    • 属性 変数は givenname および surname に設定します。
    • action 変数は member に設定します。
    • state 変数は absent に設定します。

    以下は、今回の例で使用するように変更した Ansible Playbook ファイルです。

    ---
    - name: Self-service member absent
      hosts: ipaserver
      become: true
    
      tasks:
      - name: Ensure selfservice "Users can manage their own name details" member attributes givenname and surname are absent
        ipaselfservice:
          ipaadmin_password: Secret123
          name: "Users can manage their own name details"
          attribute:
          - givenname
          - surname
          action: member
          state: absent
  5. ファイルを保存します。
  6. Playbook ファイルとインベントリーファイルを指定して Ansible Playbook を実行します。

    $ ansible-playbook -v -i inventory selfservice-member-absent-copy.yml

関連情報

  • IdM でのセルフサービスアクセス制御 を参照してください。
  • /usr/share/doc/ansible-freeipa/ ディレクトリーの README-selfservice.md ファイルを参照してください。
  • /usr/share/doc/ansible-freeipa/playbooks/selfservice ディレクトリーのサンプルの Playbook を参照してください。

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

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

ユーザーグループは、共通の特権、パスワードポリシーなどの特性が指定された一連のユーザーです。

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

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

18.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 が定義されていません。

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

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

ipausers

すべての IdM ユーザー

admins

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

editors

特権のないレガシーグループ

trust admins

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

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

警告

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

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

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

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

たとえば、以下の図の場合:

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

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

グループ A (ユーザー 2 つ) およびグループ B (ユーザー 3 つ) のチャート。グループ B はグループ A 内でネスト化されているので、グループ A にはユーザーが合計 5 つ含まれます。

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

18.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 にオプションを追加します。

    • --nonposix は、非 POSIX グループを作成します。
    • --external は、外部グループを作成します。

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

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

警告

ローカルグループを IdM に追加しないでください。Name Service Switch (NSS) は、ローカルユーザーとグループを解決する前に、IdM ユーザーとグループを常に解決します。つまり、たとえば IdM グループのメンバーシップは、ローカルユーザーでは機能しません。

18.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 のさまざまなグループタイプ を参照してください。

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

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

前提条件

手順

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

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

18.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) が最初にキャッシュを調べて、サーバーで不足または期限切れのレコードのみを検索するためです。

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

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

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

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

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

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

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

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

注記

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

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

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

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

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

前提条件

手順

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

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

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

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

18.8. IdM CLI を使用して IdM ユーザーグループにメンバーマネージャーとしてユーザーまたはグループを追加する手順

本セクションでは、IdM CLI を使用して、ユーザーまたはグループをメンバーマネージャーとして IdM ユーザーグループに追加する方法を説明します。メンバーマネージャーは、ユーザーまたはグループを IdM ユーザーグループに追加できますが、グループの属性を変更できません。

前提条件

  • 管理者としてログインしている。詳細は、Using kinit to log in to IdM manually を参照してください。
  • メンバーマネージャーとして追加するユーザーまたはグループの名前と、メンバーマネージャーが管理するグループ名を用意する。

手順

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

    たとえば、ユーザー testgroup_a のメンバーマネージャーとして追加します。

    $ ipa group-add-member-manager group_a --users=test
    Group name: group_a
    GID: 1133400009
    Membership managed by users: test
    -------------------------
    Number of members added 1
    -------------------------

    ユーザー testgroup_a のメンバーを管理できるようになりました。

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

    たとえば、 グループ group_adminsgroup_a のメンバーマネージャーとして追加します。

    $ ipa group-add-member-manager group_a --groups=group_admins
    Group name: group_a
    GID: 1133400009
    Membership managed by groups: group_admins
    Membership managed by users: test
    -------------------------
    Number of members added 1
    -------------------------

    グループ group_adminsgroup_a のメンバーを管理できるようになりました。

注記

ユーザーグループにメンバーマネージャーを追加してから、更新が Identity Management 環境のすべてのクライアントに広がるまでに時間がかかる場合があります。

検証手順

  • ipa group-show コマンドを使用して、ユーザーおよびグループがメンバーマネージャーとして追加されたことを確認します。

    $ ipa group-show group_a
    Group name: group_a
    GID: 1133400009
    Membership managed by groups: group_admins
    Membership managed by users: test

関連情報

  • 詳細は、ipa group-add-member-manager --help を参照してください。

18.9. 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 インターフェイスには表示されません。

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

18.11. IdM CLI を使用してユーザーまたはグループを IdM ユーザーグループのメンバーマネージャーから取り消す手順

本セクションでは、IdM CLI を使用して、IdM ユーザーグループのメンバーマネージャーからユーザーまたはグループを取り消す方法を説明します。メンバーマネージャーは、IdM ユーザーグループからユーザーまたはグループを削除できますが、グループの属性を変更できません。

前提条件

  • 管理者としてログインしている。詳細は、Using kinit to log in to IdM manually を参照してください。
  • 削除する既存のメンバーマネージャーのユーザーまたはグループの名前と、そのメンバーマネージャーが管理するグループ名が必要です。

手順

  • ipa group-remove-member-manager コマンドを使用してユーザーを IdM ユーザーグループのメンバーマネージャーから削除します。

    たとえば、ユーザー testgroup_a のメンバーマネージャーから削除します。

    $ ipa group-remove-member-manager group_a --users=test
    Group name: group_a
    GID: 1133400009
    Membership managed by groups: group_admins
    ---------------------------
    Number of members removed 1
    ---------------------------

    ユーザー testgroup_a のメンバーを管理できなくなりました。

  • ipa group-remove-member-manager コマンドを使用してグループを IdM ユーザーグループのメンバーマネージャーから削除します。

    たとえば、 グループ group_adminsgroup_a のメンバーマネージャーから削除します。

    $ ipa group-remove-member-manager group_a --groups=group_admins
    Group name: group_a
    GID: 1133400009
    ---------------------------
    Number of members removed 1
    ---------------------------

    グループ group_adminsgroup_a のメンバーを管理できなくなりました。

注記

ユーザーグループからメンバーマネージャーを削除してから、更新が Identity Management 環境のすべてのクライアントに広がるまでに時間がかかる場合があります。

検証手順

  • ipa group-show コマンドを使用して、ユーザーおよびグループがメンバーマネージャーから削除されたことを確認します。

    $ ipa group-show group_a
    Group name: group_a
    GID: 1133400009

関連情報

  • 詳細は、ipa group-remove-member-manager --help を参照してください。

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

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

ユーザーグループは、共通の特権、パスワードポリシーなどの特性が指定された一連のユーザーです。

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

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

19.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 が定義されていません。

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

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

ipausers

すべての IdM ユーザー

admins

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

editors

特権のないレガシーグループ

trust admins

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

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

警告

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

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

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

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

たとえば、以下の図の場合:

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

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

グループ A (ユーザー 2 つ) およびグループ B (ユーザー 3 つ) のチャート。グループ B はグループ A 内でネスト化されているので、グループ A にはユーザーが合計 5 つ含まれます。

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

19.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 を自動的に割り当てます。

    ユーザーグループの追加ポップアップウィンドウ、グループ名 (必須フィールド)、説明、グループタイプ、GID のフィールドのスクリーンショット。追加ボタンは下部にあります。
  4. Add をクリックして確定します。

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

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

前提条件

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

手順

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

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

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

前提条件

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

手順

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

    ユーザーグループページのスクリーンショット。追加可能なグループメンバーのカテゴリー 3 つ (ユーザー、ユーザーグループ、外部ユーザー) に使用するボタン 3 つ。
  4. Add をクリックします。
  5. 追加するメンバーの横にあるチェックボックスを 1 つ以上選択します。
  6. 右矢印をクリックして、選択したメンバーをグループに移動します。

    ユーザーグループ group_a へのユーザーの追加ポップアップウィンドウ。このウィンドウの左側に利用可能なユーザーログインの欄がありチェックできるようになっています。右側に右矢印があり、Prospective 一覧にユーザーを追加できます。
  7. Add をクリックして確定します。

19.6. Web UI を使用して IdM ユーザーグループにメンバーマネージャーとしてユーザーまたはグループを追加する手順

本セクションでは、Web UI を使用して、ユーザーまたはグループをメンバーマネージャーとして IdM ユーザーグループに追加する方法を説明します。メンバーマネージャーは、ユーザーまたはグループを IdM ユーザーグループに追加できますが、グループの属性を変更できません。

前提条件

  • IdM Web UI にログインしている。
  • メンバーマネージャーとして追加するユーザーまたはグループの名前と、メンバーマネージャーが管理するグループ名を用意する。

手順

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

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

    グループがメンバーマネージャーユーザーを追加
  7. Add をクリックして確定します。
注記

ユーザーグループにメンバーマネージャーを追加してから、更新が Identity Management 環境のすべてのクライアントに広がるまでに時間がかかる場合があります。

検証手順

  • 新たに追加したユーザーまたはユーザーグループが、ユーザーまたはユーザーグループのメンバーマネージャーの一覧に追加されていることを確認します。

    グループメンバーマネージャーの追加

関連情報

  • 詳細は、ipa group-add-member-manager --help を参照してください。

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

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

前提条件

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

手順

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

    結果の表示の横にある Direct Membership および Indirect Membership オプション。そのオプションの横にあるラジオボタンのスクリーンショット。

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

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

前提条件

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

手順

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

    ユーザーグループページのスクリーンショット。追加可能なグループメンバーのカテゴリー 3 つ (ユーザー、ユーザーグループ、外部ユーザー) に使用するボタン 3 つ。
  4. 削除するメンバーの横にあるチェックボックスを選択します。
  5. Delete をクリックします。
  6. Delete をクリックして確定します。

19.9. Web UI を使用してユーザーまたはグループを IdM ユーザーグループのメンバーマネージャーから取り消す手順

本セクションでは、Web UI を使用して、IdM ユーザーグループのメンバーマネージャーからユーザーまたはグループを取り消す方法を説明します。メンバーマネージャーは、IdM ユーザーグループからユーザーまたはグループを削除できますが、グループの属性を変更できません。

前提条件

  • IdM Web UI にログインしている。
  • 削除する既存のメンバーマネージャーのユーザーまたはグループの名前と、そのメンバーマネージャーが管理するグループ名が必要です。

手順

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

    グループの追加メンバーマネージャー
  4. 削除するメンバーマネージャーの横にあるチェックボックスを選択します。
  5. Delete をクリックします。
  6. Delete をクリックして確定します。
注記

ユーザーグループからメンバーマネージャーを削除してから、更新が Identity Management 環境のすべてのクライアントに広がるまでに時間がかかる場合があります。

検証手順

  • ユーザーまたはユーザーグループが、ユーザーまたはユーザーグループのメンバーマネージャーリストから削除されていることを確認します。

    グループメンバーマネージャー削除

関連情報

  • 詳細は、ipa group-add-member-manager --help を参照してください。

第20章 Ansible Playbook を使用したユーザーグループの管理

本セクションでは、Ansible Playbook を使用したユーザーグループの管理について紹介します。

ユーザーグループは、共通の特権、パスワードポリシーなどの特性が指定された一連のユーザーです。

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

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

このセクションは、以下のトピックで設定されています。

20.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 が定義されていません。

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

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

ipausers

すべての IdM ユーザー

admins

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

editors

特権のないレガシーグループ

trust admins

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

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

警告

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

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

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

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

たとえば、以下の図の場合:

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

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

グループ A (ユーザー 2 つ) およびグループ B (ユーザー 3 つ) のチャート。グループ B はグループ A 内でネスト化されているので、グループ A にはユーザーが合計 5 つ含まれます。

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

20.3. Ansible Playbook を使用して IdM グループおよびグループメンバーを存在させる手順

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

前提条件

手順

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

    [ipaserver]
    server.idm.example.com
  2. 必要なユーザーおよびグループ情報を使用して Ansible Playbook ファイルを作成します。

    ---
    - name: Playbook to handle groups
      hosts: ipaserver
      become: true
    
      tasks:
      - name: Create group ops with gid 1234
        ipagroup:
          ipaadmin_password: MySecret123
          name: ops
          gidnumber: 1234
    
      - name: Create group sysops
        ipagroup:
          ipaadmin_password: MySecret123
          name: sysops
          user:
          - idm_user
    
      - name: Create group appops
        ipagroup:
          ipaadmin_password: MySecret123
          name: appops
    
      - name: Add group members sysops and appops to group ops
        ipagroup:
          ipaadmin_password: MySecret123
          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 に存在します。

関連情報

  • /usr/share/doc/ansible-freeipa/README-group.md Markdown ファイルを参照してください。

20.4. Ansible Playbook を使用して IdM ユーザーグループにメンバーマネージャーを存在させる手順

以下の手順では、Ansible Playbook を使用して、ユーザーとユーザーグループ両方の IdM メンバーマネージャーが存在させる方法を説明します。

前提条件

  • IdM 管理者パスワードを把握している。
  • Ansible コントローラーに ansible-freeipa パッケージがインストールされている。
  • メンバーマネージャーとして追加するユーザーまたはグループの名前と、メンバーマネージャーが管理するグループ名を用意する。

手順

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

    [ipaserver]
    server.idm.example.com
  2. 必要なユーザーおよびグループメンバー管理情報を使用して、Ansible Playbook ファイルを作成します。

    ---
    - name: Playbook to handle membership management
      hosts: ipaserver
      become: true
    
      tasks:
      - name: Ensure user test is present for group_a
        ipagroup:
          ipaadmin_password: MySecret123
          name: group_a
          membermanager_user: test
    
      - name: Ensure group_admins is present for group_a
        ipagroup:
          ipaadmin_password: MySecret123
          name: group_a
          membermanager_group: group_admins
  3. Playbook を実行します。

    $ ansible-playbook -v -i path_to_inventory_directory/inventory.file path_to_playbooks_directory/add-member-managers-user-groups.yml

検証手順

ipa group-show コマンドを使用すると、group_a グループにメンバーマネージャーの test が含まれており、group_adminsgroup_a のメンバーであることが確認できます。

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

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

    ipaserver]$ ipa group-show group_a
      Group name: group_a
      GID: 1133400009
      Membership managed by groups: group_admins
      Membership managed by users: test

関連情報

  • ipa host-add-member-manager --help を参照してください。
  • ipa の man ページを参照してください。

20.5. Ansible Playbook を使用して IdM ユーザーグループにメンバーマネージャーを存在させないようにする手順

以下の手順では、Ansible Playbook を使用して、ユーザーとユーザーグループ両方の IdM メンバーマネージャーが存在させないようにする方法を説明します。

前提条件

  • IdM 管理者パスワードを把握している。
  • Ansible コントローラーに ansible-freeipa パッケージがインストールされている。
  • 削除する既存のメンバーマネージャーのユーザーまたはグループの名前と、そのメンバーマネージャーが管理するグループ名が必要です。

手順

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

    [ipaserver]
    server.idm.example.com
  2. 必要なユーザーおよびグループメンバー管理情報を使用して、Ansible Playbook ファイルを作成します。

    ---
    - name: Playbook to handle membership management
      hosts: ipaserver
      become: true
    
      tasks:
      - name: Ensure member manager user and group members are absent for group_a
        ipagroup:
          ipaadmin_password: MySecret123
          name: group_a
          membermanager_user: test
          membermanager_group: group_admins
          action: member
          state: absent
  3. Playbook を実行します。

    $ ansible-playbook -v -i path_to_inventory_directory/inventory.file path_to_playbooks_directory/ensure-member-managers-are-absent.yml

検証手順

ipa group-show コマンドを使用すると、group_a グループにメンバーマネージャーの test が含まれておらず、group_adminsgroup_a のメンバーであることが確認できます。

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

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

    ipaserver]$ ipa group-show group_a
      Group name: group_a
      GID: 1133400009

関連情報

  • ipa host-remove-member-manager --help を参照してください。
  • ipa の man ページを参照してください。

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

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

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

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

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

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

  • グループメンバーシップの手動管理してオーバーヘッドを削減する

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

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

    ユーザーとホストは、厳密に定義された基準かつ自動評価された基準をもとにグループに割り当てられます。

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

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

21.2. automember ルール

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

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

  • 包含条件

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

  • 除外条件

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

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

注記

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

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

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

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

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

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

注記

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

前提条件

  • 管理者としてログインしている。詳細は、Using kinit to log in to IdM manually を参照してください。
  • 新しいルールの対象グループは IdM に存在している必要があります。

手順

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

    • Automember rule。これはターゲットグループ名です。
    • Grouping Type。これは、ルールがユーザーグループまたはホストグループを対象にするかどうかを指定します。ユーザーグループを対象に設定するには、group と入力します。ホストグループを対象に設定するには、hostgroup と入力します。

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

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

検証手順

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

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

前提条件

手順

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

    • Automember rule。これはターゲットルール名です。詳細は、Automember ルール を参照してください。
    • Attribute Key.これは、フィルターの適用先となるエントリー属性を指定します。たとえば、ユーザーの uid です。
    • Grouping Type。これは、ルールがユーザーグループまたはホストグループを対象にするかどうかを指定します。ユーザーグループを対象に設定するには、group と入力します。ホストグループを対象に設定するには、hostgroup と入力します。
    • Inclusive regex および Exclusive regex。これらは、正規表現として条件を指定します。条件を 1 つだけ指定する場合は、他の条件の入力を求められたら 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
    ----------------------------

検証手順

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

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

前提条件

手順

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

    • ユーザーグループを対象に設定するには、group と入力します。
    • ホストグループを対象に設定するには、hostgroup と入力します。

      以下に例を示します。

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

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

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

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

前提条件

手順

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

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

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

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

前提条件

手順

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

    • Automember rule。これは、条件を削除するルールの名前です。
    • Attribute Key.これはターゲットエントリー属性です。たとえば、ユーザーの uid です。
    • Grouping Type。これは、ユーザーグループまたはホストグループのどちらの条件を削除するかを指定します。group または hostgroup を入力します。
    • Inclusive regex および Exclusive regex。この正規表現で、削除する条件を指定します。条件を 1 つだけ指定する場合は、他の条件の入力を求められたら 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
    ------------------------------

21.8. IdM CLI を使用した automember ルールの既存のエントリーへの適用

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 を使用します。

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

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

前提条件

  • 管理者としてログインしている。詳細は、Using kinit to log in to IdM manually を参照してください。
  • デフォルトとして設定されるターゲットグループが IdM にある。

手順

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

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

      以下に例を示します。

      $ 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

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

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

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

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

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

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

  • グループメンバーシップの手動管理してオーバーヘッドを削減する

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

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

    ユーザーとホストは、厳密に定義された基準かつ自動評価された基準をもとにグループに割り当てられます。

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

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

22.2. automember ルール

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

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

  • 包含条件

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

  • 除外条件

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

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

注記

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

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

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

22.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 ルールのドロップダウンフィールドが表示されています。
  4. Add をクリックして確定します。
  5. 必要に応じて、IdM Web UI を使用した automember ルールへの条件の追加 で説明されている手順に従って、新しいルールに条件を追加できます。

22.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 をクリックします。

    ユーザーグループルールで user_group ルールの属性が表示されているスクリーンショット。Inclusive セクションには Attribute と Expression のコラムがあり、そのコラムには属性 uid と式 .*のエントリーが含まれています。下部には Exclusive セクションがあり、このセクションには Attribute と Expression のコラムを含むテーブルがありますが、エントリーはありません。
  4. Attribute フィールドで、必要な属性 (uid など) を選択します。
  5. Expression フィールドに正規表現を定義します。
  6. Add をクリックします。

    たとえば、以下の条件は、ユーザー ID (uid) 属性に値 (.*) が指定されているすべてのユーザーを対象とします。

    automember への条件の追加ポップアップウィンドウのスクリーンショット。Attribute (uid が選択済み) のドロップダウンメニューと、対応する Expression (必須フィールドで、.* が入力済み) のフィールドが表示されています。Add ボタンは、ウィンドウの下部にあります。

22.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 セクションにそのルールの条件を表示します。

    ユーザーグループルール "user_group" の詳細のスクリーンショット。 General のセクションがあり、そこには Automember ルールの名前と Description セクションが表示されます。 下部には Inclusive セクションがあり、その中のテーブルには Attribute と Expression のラベルが付いたエントリーが表示されています。 この表には、エントリーが 1 つあり、属性に uid 、式に .* が入力されています。一番下には、Inclusive テーブルの構造と同じテーブルを含む Exclusive セクションがありますが、エントリーはありません。

22.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. Delete をクリックします。

    User group rules ページのスクリーンショット。このページには automember ルールの表が表示されています。user_group エントリーのチェックボックスが選択されており、Delete ボタンが強調表示されています。
  4. Delete をクリックして確定します。

22.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. Delete をクリックします。

    User group rule ページで user_group の情報が表示されているスクリーンショット。Inclusive セクションのチェックボックにはチェックが入っており、Inclusive セクションの Delete ボタンがハイライトされています。
  5. Delete をクリックして確定します。

22.8. IdM Web UI を使用した automember ルールの既存エントリーへの適用

Automember ルールは、ルールの追加後に作成されたユーザーおよびホストエントリーに自動的に適用されます。Automember ルールは、ルールの追加前に既存のエントリーに対して遡って適用されることはありません。

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

注記

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

22.8.1. 全ユーザーまたは全ホストの自動メンバーシップの再構築

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

前提条件

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

手順

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

    Actions ドロップダウンメニューの Rebuild auto membership のオプションがハイライトされているスクリーンショット。

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

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

前提条件

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

手順

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

    Actions ドロップダウンメニューのコンテンツで多数あるオプションの中で Rebuild auto membership オプションがハイライトされているスクリーンショット

22.9. IdM Web UI を使用したデフォルトのユーザーグループの設定

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

前提条件

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

手順

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

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

22.10. IdM Web UI を使用したデフォルトのホストグループの設定

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

前提条件

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

手順

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

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

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

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

  • 従業員のユーザーエントリーを、従業員のマネージャー、場所、役職などの属性に基づいてグループに分割します。コマンドラインに ipa user-add --help と入力すると、すべての属性を一覧表示できます。
  • ホストを、クラス、場所、またはその他の属性に基づいてグループに分割します。コマンドラインに ipa host-add --help と入力すると、すべての属性を一覧表示できます。
  • 全ユーザーまたは全ホストを 1 つのグローバルグループに追加する。

Red Hat Ansible Engine を使用すると、Identity Management (IdM) で自動グループメンバーシップの管理を自動化できます。

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

23.1. IdM 管理用の Ansible コントロールノードの準備

Identity Management (IdM) を管理するシステム管理者は、Red Hat Ansible Engine を使用する際に以下を行うことが推奨されます。

  • ホームディレクトリーに Ansible Playbook 専用のサブディレクトリー (例: ~/MyPlaybooks) を作成します。
  • /usr/share/doc/ansible-freeipa/*/usr/share/doc/rhel-system-roles/* ディレクトリーおよびサブディレクトリーから ~/MyPlaybooks ディレクトリーにサンプル Ansible Playbook をコピーして調整します。
  • ~/MyPlaybooks ディレクトリーにインベントリーファイルを追加します。

この方法に従うことで、すべての Playbook を 1 カ所で見つけることができます。また、root 権限を呼び出さなくても Playbook を実行できます。

注記

管理対象ノードで root 権限があれば、ipaserveripareplicaipaclient、および ipabackup ansible-freeipa ロールを実行できます。これらのロールには、ディレクトリーおよび dnf ソフトウェアパッケージマネージャーへの特権アクセスが必要です。

本セクションでは、~/MyPlaybooks ディレクトリーを作成し、このディレクトリーに Ansible Playbook を保存して実行できるように設定する方法を説明します。

前提条件

  • 管理ノードに IdM サーバー (server.idm.example.com および replica.idm.example.com) をインストールしている。
  • DNS およびネットワークを設定し、コントロールノードから直接管理ノード (server.idm.example.com および replica. idm.example.com) にログインすることができる。
  • IdM admin のパスワードを把握している。

手順

  1. Ansible 設定および Playbook のディレクトリーをホームディレクトリーに作成します。

    $ mkdir ~/MyPlaybooks/
  2. ~/MyPlaybooks/ ディレクトリーに移動します。

    $ cd ~/MyPlaybooks
  3. ~/MyPlaybooks/ansible.cfg ファイルを以下の内容で作成します。

    [defaults]
    inventory = /home/your_username/MyPlaybooks/inventory
    
    [privilege_escalation]
    become=True
  4. ~/MyPlaybooks/inventory ファイルを以下の内容で作成します。

    [eu]
    server.idm.example.com
    
    [us]
    replica.idm.example.com
    
    [ipaserver:children]
    eu
    us

    この設定は、これらの場所にあるホストの 2 つのホストグループ (euus) を定義します。さらに、この設定は、eu および us グループのすべてのホストを含む ipaserver ホストグループを定義します。

  5. (必要に応じて) SSH 公開鍵および秘密鍵を作成します。テスト環境でのアクセスを簡素化するには、秘密鍵にパスワードを設定しないでください。

    $ ssh-keygen
  6. 各管理対象ノードの IdM admin アカウントに SSH 公開鍵をコピーします。

    $ ssh-copy-id admin@server.idm.example.com
    $ ssh-copy-id admin@replica.idm.example.com

    これらのコマンドを入力する場合は、IdM admin パスワードを入力する必要があります。

23.2. Ansible を使用した IdM ユーザーグループの automember ルールが存在することの確認

以下の手順では、Ansible Playbook を使用して、Identity Management (IdM) グループの automember ルールが存在することを確認する方法について説明しますこの例では、testing_group ユーザーグループに対して automember ルールの存在が保証されます。

前提条件

  • IdM admin のパスワードを把握している。
  • testing_group ユーザーグループが IdM に存在します。
  • 以下の要件を満たす Ansible コントロールノードを設定している。

    • Ansible バージョン 2.8 以降を使用している。
    • Ansible コントローラーに ansible-freeipa パッケージがインストールされている。
    • ~/MyPlaybooks/ ディレクトリーに、このオプションを設定する IdM サーバーの完全修飾ドメイン名 (FQDN) で Ansible インベントリーファイル を作成している。

手順

  1. ~/MyPlaybooks/ ディレクトリーに移動します。

    $ cd ~/MyPlaybooks/
  2. /usr/share/doc/ansible-freeipa/playbooks/automember/ ディレクトリーにある automember-group-present.yml Ansible Playbook ファイルをコピーします。

    $ cp /usr/share/doc/ansible-freeipa/playbooks/automember/automember-group-present.yml automember-group-present-copy.yml
  3. automember-group-present-copy.yml ファイルを開いて編集します。
  4. ipaautomember タスクセクションで次の変数を設定して、ファイルを調整します。

    • ipaadmin_password 変数は IdM admin のパスワードに設定します。
    • name 変数を testing_group に設定します。
    • automember_type 変数を group に設定します。
    • state 変数は present に設定されていることを確認します。

    以下は、今回の例で使用するように変更した Ansible Playbook ファイルです。

    ---
    - name: Automember group present example
      hosts: ipaserver
      become: true
      tasks:
      - name: Ensure group automember rule admins is present
        ipaautomember:
          ipaadmin_password: Secret123
          name: testing_group
          automember_type: group
          state: present
  5. ファイルを保存します。
  6. Playbook ファイルとインベントリーファイルを指定して Ansible Playbook を実行します。

    $ ansible-playbook -v -i inventory automember-group-present-copy.yml

関連情報

23.3. Ansible を使用した、IdM ユーザーグループの automember ルールに指定した条件が存在することの確認

以下の手順では、Ansible Playbook を使用して、Identity Management (IdM) グループの automember ルールに、指定した条件が存在することを確認する方法について説明しますこの例では、testing_group グループに対して、automember ルールに UID 関連の条件が存在することが保証されます。.* 条件を指定することで、今後使用する IdM ユーザーがすべて自動的に testing_group のメンバーになるようにします。

前提条件

  • IdM admin のパスワードを把握している。
  • testing_group ユーザーグループおよび automember ユーザーグループルールが IdM に存在します。
  • 以下の要件を満たす Ansible コントロールノードを設定している。

    • Ansible バージョン 2.8 以降を使用している。
    • Ansible コントローラーに ansible-freeipa パッケージがインストールされている。
    • ~/MyPlaybooks/ ディレクトリーに、このオプションを設定する IdM サーバーの完全修飾ドメイン名 (FQDN) で Ansible インベントリーファイル を作成している。

手順

  1. ~/MyPlaybooks/ ディレクトリーに移動します。

    $ cd ~/MyPlaybooks/
  2. /usr/share/doc/ansible-freeipa/playbooks/automember/ ディレクトリーにある automember-hostgroup-rule-present.yml Ansible Playbook ファイルをコピーして、名前を付けます (automember-usergroup-rule-present.yml など)。

    $ cp /usr/share/doc/ansible-freeipa/playbooks/automember/automember-hostgroup-rule-present.yml automember-usergroup-rule-present.yml
  3. automember-usergroup-rule-present.yml を開いて編集します。
  4. 次のパラメーターを変更して、ファイルを調整します。

    • ユースケースに対応するように Playbook の名前を変更します (例: Automember user group rule member present)。
    • ユースケースに合わせて、タスクの名前を変更します (例: Ensure an automember condition for a user group is present)。
    • ipaautomember タスクセクションで、以下の変数を設定します。

      • ipaadmin_password 変数は IdM admin のパスワードに設定します。
      • name 変数を testing_group に設定します。
      • automember_type 変数を group に設定します。
      • state 変数は present に設定されていることを確認します。
      • action 変数が member に設定されていることを確認します。
      • inclusive key 変数を UID に設定します。
      • inclusive expression 変数を .* に設定します。

    以下は、今回の例で使用するように変更した Ansible Playbook ファイルです。

    ---
    - name: Automember user group rule member present
      hosts: ipaserver
      become: true
      tasks:
      - name: Ensure an automember condition for a user group is present
        ipaautomember:
          ipaadmin_password: Secret123
          name: testing_group
          automember_type: group
          state: present
          action: member
          inclusive:
            - key: UID
              expression: .*
  5. ファイルを保存します。
  6. Playbook ファイルとインベントリーファイルを指定して Ansible Playbook を実行します。

    $ ansible-playbook -v -i inventory automember-usergroup-rule-present.yml

検証手順

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

    $ kinit admin
  2. ユーザーを追加します。以下に例を示します。

    $ ipa user-add user101 --first user --last 101
    -----------------------
    Added user "user101"
    -----------------------
      User login: user101
      First name: user
      Last name: 101
      ...
      Member of groups: ipausers, testing_group
      ...

関連情報

23.4. Ansible を使用した IdM ユーザーグループの automember ルールに条件がないことの確認

以下の手順では、Ansible Playbook を使用して、Identity Management (IdM) グループの automember ルールに条件がないことを確認する方法を説明します。この例では、automember ルールに条件がないことが保証されており、initialsdp であるユーザーを含める必要があることを指定しています。automember ルールが testing_group グループに適用されます。条件を適用することにより、今後は、イニシャルがdpである IdM ユーザーがtesting_groupのメンバーにならないようにします。

前提条件

  • IdM admin のパスワードを把握している。
  • testing_group ユーザーグループおよび automember ユーザーグループルールが IdM に存在します。
  • 以下の要件を満たす Ansible コントロールノードを設定している。

    • Ansible バージョン 2.8 以降を使用している。
    • Ansible コントローラーに ansible-freeipa パッケージがインストールされている。
    • ~/MyPlaybooks/ ディレクトリーに、このオプションを設定する IdM サーバーの完全修飾ドメイン名 (FQDN) で Ansible インベントリーファイル を作成している。

手順

  1. ~/MyPlaybooks/ ディレクトリーに移動します。

    $ cd ~/MyPlaybooks/
  2. /usr/share/doc/ansible-freeipa/playbooks/automember/ ディレクトリーにある automember-hostgroup-rule-absent.yml Ansible Playbook ファイルをコピーして、名前を付けます (automember-usergroup-rule-absent.yml など)。

    $ cp /usr/share/doc/ansible-freeipa/playbooks/automember/automember-hostgroup-rule-absent.yml automember-usergroup-rule-absent.yml
  3. automember-usergroup-rule-absent.yml を開いて編集します。
  4. 次のパラメーターを変更して、ファイルを調整します。

    • ユースケースに対応するように Playbook の名前を変更します (例: Automember user group rule member absent)。
    • ユースケースに合わせて、タスクの名前を変更します (例: Ensure an automember condition for a user group is absent)。
    • ipaautomember タスクセクションで、以下の変数を設定します。

      • ipaadmin_password 変数は IdM admin のパスワードに設定します。
      • name 変数を testing_group に設定します。
      • automember_type 変数を group に設定します。
      • state 変数は、absent に設定されていることを確認します。
      • action 変数が member に設定されていることを確認します。
      • inclusive key 変数を initials に設定します。
      • inclusive expression 変数を dp に設定します。

    以下は、今回の例で使用するように変更した Ansible Playbook ファイルです。

    ---
    - name: Automember user group rule member absent
      hosts: ipaserver
      become: true
      tasks:
      - name: Ensure an automember condition for a user group is absent
        ipaautomember:
          ipaadmin_password: Secret123
          name: testing_group
          automember_type: group
          state: absent
          action: member
          inclusive:
            - key: initials
              expression: dp
  5. ファイルを保存します。
  6. Playbook ファイルとインベントリーファイルを指定して Ansible Playbook を実行します。

    $ ansible-playbook -v -i inventory automember-usergroup-rule-absent.yml

検証手順

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

    $ kinit admin
  2. automember グループを表示します。

    $ ipa automember-show --type=group testing_group
     Automember Rule: testing_group

出力に Inclusive Regex: initials=dp エントリーがない場合は、testing_group automember ルールに指定した条件が含まれていないことを確認します。

関連情報

23.5. Ansible を使用した IdM ユーザーグループの automember ルールがないことの確認

以下の手順では、Ansible Playbook を使用して、Identity Management (IdM) グループに automember ルールがないことを確認する方法を説明します。この例では、testing_group グループに automember ルールがないことが保証されます。

注記

automember ルールを削除すると、そのルールに関連付けられた条件もすべて削除されます。ルールから特定の条件のみを削除するには、Ansible を使用した IdM ユーザーグループの automember ルールに条件がないことの確認 を参照してください。

前提条件

  • IdM admin のパスワードを把握している。
  • 以下の要件を満たす Ansible コントロールノードを設定している。

    • Ansible バージョン 2.8 以降を使用している。
    • Ansible コントローラーに ansible-freeipa パッケージがインストールされている。
    • ~/MyPlaybooks/ ディレクトリーに、このオプションを設定する IdM サーバーの完全修飾ドメイン名 (FQDN) で Ansible インベントリーファイル を作成している。

手順

  1. ~/MyPlaybooks/ ディレクトリーに移動します。

    $ cd ~/MyPlaybooks/
  2. /usr/share/doc/ansible-freeipa/playbooks/automember/ ディレクトリーにある automember-group-absent.yml Ansible Playbook ファイルをコピーします。

    $ cp /usr/share/doc/ansible-freeipa/playbooks/automember/automember-group-absent.yml automember-group-absent-copy.yml
  3. automember-group-absent-copy.yml を開いて編集します。
  4. ipaautomember タスクセクションで次の変数を設定して、ファイルを調整します。

    • ipaadmin_password 変数は IdM admin のパスワードに設定します。
    • name 変数を testing_group に設定します。
    • automember_type 変数を group に設定します。
    • state 変数は、absent に設定されていることを確認します。

    以下は、今回の例で使用するように変更した Ansible Playbook ファイルです。

    ---
    - name: Automember group absent example
      hosts: ipaserver
      become: true
      tasks:
      - name: Ensure group automember rule admins is absent
        ipaautomember:
          ipaadmin_password: Secret123
          name: testing_group
          automember_type: group
          state: absent
  5. ファイルを保存します。
  6. Playbook ファイルとインベントリーファイルを指定して Ansible Playbook を実行します。

    $ ansible-playbook -v -i inventory automember-group-absent.yml

関連情報

23.6. Ansible を使用した IdM ホストグループの automember ルールに条件が存在することの確認

本セクションでは、Ansible を使用して、IdM ホストグループの automember ルールに条件が存在することを確認する方法を説明します。この例では、FQDN.*.idm.example.com のホストが、primary_dns_domain_hosts ホストグループのメンバーであることと、FQDN.*.example.org であるホストが primary_dns_domain_hosts ホストグループのメンバーではないことを確認する方法を説明します。

前提条件

  • IdM admin のパスワードを把握している。
  • primary_dns_domain_hosts ホストグループおよび automember ホストグループルールが IdM に存在します。
  • 以下の要件を満たす Ansible コントロールノードを設定している。

    • Ansible バージョン 2.8 以降を使用している。
    • Ansible コントローラーに ansible-freeipa パッケージがインストールされている。
    • ~/MyPlaybooks/ ディレクトリーに、このオプションを設定する IdM サーバーの完全修飾ドメイン名 (FQDN) で Ansible インベントリーファイル を作成している。

手順

  1. ~/MyPlaybooks/ ディレクトリーに移動します。

    $ cd ~/MyPlaybooks/
  2. /usr/share/doc/ansible-freeipa/playbooks/automember/ ディレクトリーにある automember-hostgroup-rule-present.yml Ansible Playbook ファイルをコピーします。

    $ cp /usr/share/doc/ansible-freeipa/playbooks/automember/automember-hostgroup-rule-present.yml automember-hostgroup-rule-present-copy.yml
  3. automember-hostgroup-rule-present-copy.yml を開いて編集します。
  4. ipaautomember タスクセクションで次の変数を設定して、ファイルを調整します。

    • ipaadmin_password 変数は IdM admin のパスワードに設定します。
    • name 変数を primary_dns_domain_hosts に設定します。
    • automember_typehostgroup に設定します。
    • state 変数は present に設定されていることを確認します。
    • action 変数が member に設定されていることを確認します。
    • inclusive key 変数が fqdn に設定されていることを確認します。
    • 対応する inclusive expression 変数を.*.idm.example.comに設定します。
    • exclusive key 変数を UID に設定します。
    • 対応する exclusive expression 変数を .*.example.org に設定します。

    以下は、今回の例で使用するように変更した Ansible Playbook ファイルです。

    ---
    - name: Automember user group rule member present
      hosts: ipaserver
      become: true
      tasks:
      - name: Ensure an automember condition for a user group is present
        ipaautomember:
          ipaadmin_password: Secret123
          name: primary_dns_domain_hosts
          automember_type: hostgroup
          state: present
          action: member
          inclusive:
            - key: fqdn
              expression: .*.idm.example.com
          exclusive:
            - key: fqdn
              expression: .*.example.org
  5. ファイルを保存します。
  6. Playbook ファイルとインベントリーファイルを指定して Ansible Playbook を実行します。

    $ ansible-playbook -v -i inventory automember-hostgroup-rule-present-copy.yml

関連情報

23.7. 関連情報

第24章 IdM CLI を使用してユーザーグループにパーミッションを委譲してユーザーを管理する手順

委譲は、セルフサービスルールおよびロールベースのアクセス制御 (RBAC) などの IdM のアクセス制御メソッドの 1 つです。委譲を使用して、あるユーザーのグループにパーミッションを割り当てて別のユーザーのグループのエントリーを管理できます。

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

24.1. 委譲ルール

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

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

委譲ルールにより、IdM の既存のユーザーグループにパーミッションが付与されます。委任を使用すると、managers ユーザーグループで employees ユーザーグループでユーザーの選択された属性を管理できます。

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

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

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

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

重要

--attrs オプションはそれまでにサポートされていた属性をすべて上書きするので、新規属性に加えて属性の完全一覧を常に含めるようにしてください。これは、--permissions オプションにも適用されます。

前提条件

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

手順

  • 必要に応じて、任意の変更を加えて ipa delegation-mod コマンドを実行します。たとえば、displayname 属性を basic manager attributes のルールの例に追加するには、次のコマンドを実行します。

    $ 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

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

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

前提条件

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

手順

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

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

第25章 Web UI を使用してユーザーグループにパーミッションを委譲してユーザーを管理する手順

委譲は、セルフサービスルールおよびロールベースのアクセス制御 (RBAC) などの IdM のアクセス制御メソッドの 1 つです。委譲を使用して、あるユーザーのグループにパーミッションを割り当てて別のユーザーのグループのエントリーを管理できます。

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

25.1. 委譲ルール

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

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

委譲ルールにより、IdM の既存のユーザーグループにパーミッションが付与されます。委任を使用すると、managers ユーザーグループで employees ユーザーグループでユーザーの選択された属性を管理できます。

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

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

前提条件

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

手順

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

    IdM Web UI のスクリーンショット。IPA Server タブの Role-Based Access Control ドロップダウンサブメニューの内容が表示されています。ロールベースのアクセス制御ドロップダウンメニューには、Roles - Privileges - Permissions - Self Service Permissions - Delegations の 5 つのオプションがあります。
  3. Add delegation ウィンドウで、以下を実行します。

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

      Add delegation ポップアップウィンドウのスクリーンショット。このウィンドウでは委譲の詳細を入力できます。エントリーオプションには、委譲名のテキストフィールドと、読み取りおよび書き込みパーミッションのチェックボックスが含まれます。また、ユーザーグループのドロップダウンメニュー、メンバーユーザーグループのドロップダウンメニュー、属性のチェックボックス多数 (departmentnumber - employeenumber - businesscategory - employeetype) もあります。
    6. Add ボタンをクリックして、新規委譲ルールを保存します。

25.3. IdM WebUI を使用した既存の委譲ルールの表示

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

前提条件

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

手順

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

    IdM Web UI のスクリーンショット。IPA Server タブのロールベースのアクセス制御サブメニューの Delegations ページが表示されています。また、テーブルには、委譲名で整理された委譲の項目が表示されています。

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

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

前提条件

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

手順

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

    IdM Web UI のスクリーンショット。IPA Server タブの ロールベースのアクセス制御のサブページが表示されています。委譲のページには、基本的なマネージャー属性委譲名のエントリーを含むテーブルが表示されています。
  2. 変更するルールをクリックします。
  3. 必要な変更を行います。

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

      委譲ページには、委譲名 - パーミッション (必須。例: 読み取り、書き込み) - ユーザーグループ (必須。例: マネージャー) - メンバーユーザーグループ (必須。例: 授業員) および属性 (必須。employeetype - businesscategory - departmentnumber - displayname - employeenumber - homedirectory) など、 "basic manager attributes" 委譲の詳細が表示されています。左上の save ボタンが強調表示されています。
    • Save ボタンをクリックして変更を保存します。

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

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

前提条件

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

手順

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

    IPA Server タブの Role-Based Access Control サブメニューのスクリーンショット。委譲ページには委譲名の表と Basic manager attributes エントリーにチェックが入ったチェックボックスが表示されています。Delete ボタンが強調表示されています。
  4. Delete をクリックして確定します。

第26章 Ansible Playbook を使用してユーザーグループにパーミッションを委譲してユーザーを管理する手順

委譲は、セルフサービスルールおよびロールベースのアクセス制御 (RBAC) などの IdM のアクセス制御メソッドの 1 つです。委譲を使用して、あるユーザーのグループにパーミッションを割り当てて別のユーザーのグループのエントリーを管理できます。

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

26.1. 委譲ルール

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

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

委譲ルールにより、IdM の既存のユーザーグループにパーミッションが付与されます。委任を使用すると、managers ユーザーグループで employees ユーザーグループでユーザーの選択された属性を管理できます。

26.2. IdM の Ansible インベントリーファイルの作成

Ansible を使用する場合は、ホームディレクトリーに Ansible Playbook 専用のサブディレクトリーを作成して、/usr/share/doc/ansible-freeipa/*/usr/share/doc/rhel-system-roles/* サブディレクトリーからコピーして調整できるようにします。この方法には、以下の利点があります。

  • すべての Playbook を 1 カ所で見つけることがでる。
  • root 権限を呼び出さずに Playbook を実行できる。

手順

  1. Ansible 設定および Playbook のディレクトリーをホームディレクトリーに作成します。

    $ mkdir ~/MyPlaybooks/
  2. ~/MyPlaybooks/ ディレクトリーに移動します。

    $ cd ~/MyPlaybooks
  3. ~/MyPlaybooks/ansible.cfg ファイルを以下の内容で作成します。

    [defaults]
    inventory = /home/<username>/MyPlaybooks/inventory
    
    [privilege_escalation]
    become=True
  4. ~/MyPlaybooks/inventory ファイルを以下の内容で作成します。

    [eu]
    server.idm.example.com
    
    [us]
    replica.idm.example.com
    
    [ipaserver:children]
    eu
    us

    この設定は、これらの場所にあるホストの 2 つのホストグループ (euus) を定義します。さらに、この設定は、eu および us グループのすべてのホストを含む ipaserver ホストグループを定義します。

26.3. Ansible を使用して委譲ルールを存在させる手順

以下の手順では、Ansible Playbook を使用して、新しい IdM 委譲ルールの特権を定義して、その存在を確認する方法を説明します。この例では、新しい basic manager attributes 委譲ルールにより、managers グループが employees グループのメンバーに対して以下の属性の読み取りと書き込みを行うことができます。

  • businesscategory
  • departmentnumber
  • employeenumber
  • employeetype

前提条件

  • IdM 管理者パスワードを把握している。
  • 以下の要件を満たす Ansible コントロールノードを設定している。

    • Ansible バージョン 2.8 以降を使用している。
    • Ansible コントローラーに ansible-freeipa パッケージがインストールされている。
    • このオプションを設定する IdM サーバーの完全修飾ドメイン名 (FQDN) で Ansible インベントリーファイル を作成している。
    • Ansible インベントリーファイルが ~/ MyPlaybooks/ ディレクトリーにある。

手順

  1. ~/ MyPlaybooks/ ディレクトリーに移動します。

    $ cd ~/MyPlaybooks/
  2. /usr/share/doc/ansible-freeipa/playbooks/delegation/ にある delegation-present.yml ファイルのコピーを作成します。

    $ cp /usr/share/doc/ansible-freeipa/playbooks/delegation/delegation-present.yml delegation-present-copy.yml
  3. Ansible Playbook ファイル delegation-present-copy.yml を開きます。
  4. ipadelegation タスクセクションに以下の変数を設定して、ファイルを調整します。

    • ipaadmin_password 変数は IdM 管理者のパスワードに設定します。
    • name 変数は新しい委譲ルールの名前に設定します。
    • permission 変数は、付与するパーミッションをコンマ区切りの一覧 (read および write) で設定します。
    • attribute 変数は、委譲されたユーザーグループが管理できる属性の一覧 (businesscategorydepartmentnumberemployeenumber および employeetype) に変数を設定します。
    • group 変数は、属性の表示や変更権限を付与したグループの名前に設定します。
    • membergroup 変数は、属性の表示または変更が可能なグループ名に設定します。

    以下は、今回の例で使用するように変更した Ansible Playbook ファイルです。

    ---
    - name: Playbook to manage a delegation rule
      hosts: ipaserver
      become: true
    
      tasks:
      - name: Ensure delegation "basic manager attributes" is present
        ipadelegation:
          ipaadmin_password: Secret123
          name: "basic manager attributes"
          permission: read, write
          attribute:
          - businesscategory
          - departmentnumber
          - employeenumber
          - employeetype
          group: managers
          membergroup: employees
  5. ファイルを保存します。
  6. Playbook ファイルとインベントリーファイルを指定して Ansible Playbook を実行します。

    $ ansible-playbook -v -i ~/MyPlaybooks/inventory delegation-present-copy.yml

関連情報

  • 委譲ルール を参照してください。
  • /usr/share/doc/ansible-freeipa/ ディレクトリーの README-delegation.md ファイルを参照してください。
  • /usr/share/doc/ansible-freeipa/playbooks/ipadelegation ディレクトリーのサンプルの Playbook を参照してください。

26.4. Ansible を使用して委譲ルールがないことを確認する手順

以下の手順では、Ansible Playbook を使用して、指定した委譲ルールが IdM 設定に存在しないことを確認する方法を説明します。以下の例では、カスタムの basic manager attributes 委譲ルールが IdM に存在しないことを確認する方法を説明します。

前提条件

  • IdM 管理者パスワードを把握している。
  • 以下の要件を満たす Ansible コントロールノードを設定している。

    • Ansible バージョン 2.8 以降を使用している。
    • Ansible コントローラーに ansible-freeipa パッケージがインストールされている。
    • このオプションを設定する IdM サーバーの完全修飾ドメイン名 (FQDN) で Ansible インベントリーファイル を作成している。
    • Ansible インベントリーファイルが ~/ MyPlaybooks/ ディレクトリーにある。

手順

  1. ~/ MyPlaybooks/ ディレクトリーに移動します。

    $ cd ~/MyPlaybooks>/
  2. /usr/share/doc/ansible-freeipa/playbooks/delegation/ ディレクトリーにある delegation-absent.yml ファイルのコピーを作成します。

    $ cp /usr/share/doc/ansible-freeipa/playbooks/delegation/delegation-present.yml delegation-absent-copy.yml
  3. Ansible Playbook ファイル delegation-absent-copy.yml を開きます。
  4. ipadelegation タスクセクションに以下の変数を設定して、ファイルを調整します。

    • ipaadmin_password 変数は IdM 管理者のパスワードに設定します。
    • name 変数は委譲ルールの名前に設定します。
    • state 変数は absent に設定します。

    以下は、今回の例で使用するように変更した Ansible Playbook ファイルです。

    ---
    - name: Delegation absent
      hosts: ipaserver
      become: true
    
      tasks:
      - name: Ensure delegation "basic manager attributes" is absent
        ipadelegation:
          ipaadmin_password: Secret123
          name: "basic manager attributes"
          state: absent
  5. ファイルを保存します。
  6. Playbook ファイルとインベントリーファイルを指定して Ansible Playbook を実行します。

    $ ansible-playbook -v -i ~/MyPlaybooks/inventory delegation-absent-copy.yml

関連情報

  • 委譲ルール を参照してください。
  • /usr/share/doc/ansible-freeipa/ ディレクトリーの README-delegation.md ファイルを参照してください。
  • /usr/share/doc/ansible-freeipa/playbooks/ipadelegation ディレクトリーのサンプルの Playbook を参照してください。

26.5. Ansible を使用して委譲ルールに特定の属性を含める手順

以下の手順では、Ansible Playbook を使用して、委譲ルールに特定の設定を指定する方法を説明します。この Playbook を使用して、以前に作成した委譲ロールを変更できます。この例では、basic manager attributes 委譲ルールに departmentnumber メンバー属性のみが含まれるようにします。

前提条件

  • IdM 管理者パスワードを把握している。
  • 以下の要件を満たす Ansible コントロールノードを設定している。

    • Ansible バージョン 2.8 以降を使用している。
    • Ansible コントローラーに ansible-freeipa パッケージがインストールされている。
    • このオプションを設定する IdM サーバーの完全修飾ドメイン名 (FQDN) で Ansible インベントリーファイル を作成している。
    • Ansible インベントリーファイルが ~/ MyPlaybooks/ ディレクトリーにある。
  • basic manager attributes 委譲ルールが IdM に存在する。

手順

  1. ~/ MyPlaybooks/ ディレクトリーに移動します。

    $ cd ~/MyPlaybooks/
  2. /usr/share/doc/ansible-freeipa/playbooks/delegation/ にある delegation-member-present.yml ファイルのコピーを作成します。

    $ cp /usr/share/doc/ansible-freeipa/playbooks/delegation/delegation-member-present.yml delegation-member-present-copy.yml
  3. Ansible Playbook ファイル delegation-member-present-copy.yml を開きます。
  4. ipadelegation タスクセクションに以下の変数を設定して、ファイルを調整します。

    • ipaadmin_password 変数は IdM 管理者のパスワードに設定します。
    • name 変数は、変更する委譲ルールの名前に設定します。
    • attribute 変数は departmentnumber に設定します。
    • action 変数は member に設定します。

    以下は、今回の例で使用するように変更した Ansible Playbook ファイルです。

    ---
    - name: Delegation member present
      hosts: ipaserver
      become: true
    
      tasks:
      - name: Ensure delegation "basic manager attributes" member attribute departmentnumber is present
        ipadelegation:
          ipaadmin_password: Secret123
          name: "basic manager attributes"
          attribute:
          - departmentnumber
          action: member
  5. ファイルを保存します。
  6. Playbook ファイルとインベントリーファイルを指定して Ansible Playbook を実行します。

    $ ansible-playbook -v -i ~/MyPlaybooks/inventory delegation-member-present-copy.yml

関連情報

  • 委譲ルール を参照してください。
  • /usr/share/doc/ansible-freeipa/ ディレクトリーの README-delegation.md ファイルを参照してください。
  • /usr/share/doc/ansible-freeipa/playbooks/ipadelegation ディレクトリーのサンプルの Playbook を参照してください。

26.6. Ansible を使用して委譲ルールに特定の属性を含めないようにする手順

以下の手順では、Ansible Playbook を使用して、委譲ルールに特定の設定が割り当てられないようにする方法を説明します。この Playbook を使用して、委譲ロールが不必要なアクセス権限を付与しないようします。この例では、basic manager attributes 委譲ルールに employeenumber および employeetype メンバー属性が含まれないようにします。

前提条件

  • IdM 管理者パスワードを把握している。
  • 以下の要件を満たす Ansible コントロールノードを設定している。

    • Ansible バージョン 2.8 以降を使用している。
    • Ansible コントローラーに ansible-freeipa パッケージがインストールされている。
    • このオプションを設定する IdM サーバーの完全修飾ドメイン名 (FQDN) で Ansible インベントリーファイル を作成している。
    • Ansible インベントリーファイルが ~/ MyPlaybooks/ ディレクトリーにある。
  • basic manager attributes 委譲ルールが IdM に存在する。

手順

  1. ~/ MyPlaybooks/ ディレクトリーに移動します。

    $ cd ~/MyPlaybooks/
  2. /usr/share/doc/ansible-freeipa/playbooks/delegation/ にある delegation-member-absent.yml ファイルのコピーを作成します。

    $ cp /usr/share/doc/ansible-freeipa/playbooks/delegation/delegation-member-absent.yml delegation-member-absent-copy.yml
  3. Ansible Playbook ファイル delegation-member-absent-copy.yml を開きます。
  4. ipadelegation タスクセクションに以下の変数を設定して、ファイルを調整します。

    • ipaadmin_password 変数は IdM 管理者のパスワードに設定します。
    • name 変数は、変更する委譲ルールの名前に設定します。
    • attribute 変数は employeenumber および employeetype に設定します。
    • action 変数は member に設定します。
    • state 変数は absent に設定します。

    以下は、今回の例で使用するように変更した Ansible Playbook ファイルです。

    ---
    - name: Delegation member absent
      hosts: ipaserver
      become: true
    
      tasks:
      - name: Ensure delegation "basic manager attributes" member attributes employeenumber and employeetype are absent
        ipadelegation:
          ipaadmin_password: Secret123
          name: "basic manager attributes"
          attribute:
          - employeenumber
          - employeetype
          action: member
          state: absent
  5. ファイルを保存します。
  6. Playbook ファイルとインベントリーファイルを指定して Ansible Playbook を実行します。

    $ ansible-playbook -v -i ~/MyPlaybooks/inventory delegation-member-absent-copy.yml

関連情報

  • 委譲ルール を参照してください。
  • /usr/share/doc/ansible-freeipa/ ディレクトリーの README-delegation.md ファイルを参照してください。
  • /usr/share/doc/ansible-freeipa/playbooks/ipadelegation ディレクトリーのサンプルの Playbook を参照してください。

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

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

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

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

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

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

27.1.1. IdM のパーミッション

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

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

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

  • subtree: ドメイン名 (DN) (この DN のサブツリー)
  • target filter: LDAP フィルター
  • target: DN。ワイルドカードでエントリーを指定可能。

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

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

IdM パーミッションを使用すると、どのユーザーがどのオブジェクトにアクセスできるか、さらにこのようなオブジェクトの属性にアクセスできるかどうかを制御できます。IdM を使用すると、個別の属性を許可または拒否したり、ユーザー、グループ、sudo などの特定の IdM 機能を、全匿名ユーザー、全認証済みユーザー、または特定の特権ユーザーグループ限定などと、全体的な表示設定を変更したりできます。
たとえば、このアプローチではパーミッション指定に柔軟性があるので、アクセスが必要な特定のセクションのみにユーザーまたはグループのアクセスを制限し、他のセクションをこれらのユーザーまたはグループには完全に表示されないように設定する場合に、管理者にとって便利です。

注記

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

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

管理パーミッションは、IdM にデフォルトで含まれているパーミッションです。このパーミッションはユーザーが作成した他のパーミッションと同様に機能しますが、以下の相違点があります。

  • この管理パーミッションは削除できず、名前、場所、ターゲットの属性を変更できません。
  • このパーミッションには 3 つの属性セットがあります。

    • デフォルト の属性。IdM で管理されているため、ユーザーは変更できません。
    • 包含 属性。ユーザーが別途