Menu Close
IdM ユーザーグループのホストとアクセス制御ルールの管理
ユーザーおよびホストをグループで管理し、ホストベースのアクセス制御(HBAC)ルールおよびロールベースアクセス制御(RBAC)ルールを使用したアクセスの制御
概要
多様性を受け入れるオープンソースの強化
Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。まずは、マスター (master)、スレーブ (slave)、ブラックリスト (blacklist)、ホワイトリスト (whitelist) の 4 つの用語の置き換えから始めます。この取り組みは膨大な作業を要するため、今後の複数のリリースで段階的に用語の置き換えを実施して参ります。詳細は、弊社の CTO、Chris Wright のメッセージ を参照してください。
Red Hat ドキュメントへのフィードバックの提供
ご意見ご要望をお聞かせください。ドキュメントの改善点はございませんか。
特定の部分についての簡単なコメントをお寄せいただく場合は、以下をご確認ください。
- ドキュメントの表示が Multi-page HTML 形式になっていて、ドキュメントの右上隅に Feedback ボタンがあることを確認してください。
- マウスカーソルで、コメントを追加する部分を強調表示します。
- そのテキストの下に表示される Add Feedback ポップアップをクリックします。
- 表示される手順に従ってください。
Bugzilla を介してフィードバックを送信するには、新しいチケットを作成します。
- Bugzilla の Web サイトに移動します。
- Component で Documentation を選択します。
- Description フィールドに、ドキュメントの改善に関するご意見を記入してください。ドキュメントの該当部分へのリンクも記入してください。
- Submit Bug をクリックします。
第1章 IdM コマンドラインユーティリティーの概要
以下のセクションでは、Identity Management (IdM) コマンドラインユーティリティーの基本的な使用方法を説明します。
前提条件
IdM サーバーをインストールしていて、アクセス可能である。
詳細は「 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
コマンドを使用して、TOPIC
、COMMAND
、またはtopics
、またはcommands
を指定できます。-
トピック
で ipa help コマンドを実行できます。このコマンドipa help トピック
は、ユーザー
、証明書、サーバー
など、IPA ヘルプでカバーされているトピックの一覧を表示します。 -
TOPIC
gitops- capital: 大文字の TOPIC は変数です。したがって、ipa help user
などの特定のトピックを指定できます。 -
コマンド
ipa help
コマンドを入力できます。たとえば、user-add
、ca-enable
、server-show
など、IPA ヘルプでカバーされているコマンド一覧を表示できます。 -
COMMAND
TEMPLATES-gitopsThe COMMAND with capital characters は変数です。したがって、ipa help user-add
などの特定のコマンドを指定できます。
-
1.3. IPA ヘルプトピックの使用
以下の手順では、コマンドラインインターフェースで IPA ヘルプを使用する方法を説明します。
手順
- 端末を開き、IdM サーバーに接続します。
ヘルプに記載されているトピックの一覧を表示するには、
ipa help topics
を実行します。$ ipa help topics
トピックのいずれかを選択し、
ipa help [topic_name]
のパターンに従ってコマンドを作成します。topic_name
文字列の代わりに、前のステップで説明したトピックのいずれかを追加します。この例では、
user
トピックを使用します。$ ipa help user
IPA ヘルプ出力が長すぎてテキスト全体を表示できない場合は、以下の構文を使用します。
$ ipa help user | less
スクロールダウンすれば、ヘルプ全体を表示できます
IPA CLI は、ユーザー
トピックのヘルプページを表示します。概要を読むと、トピックのコマンドを使用するパターンに関して、多くの例を確認できます。
1.4. IPA ヘルプコマンドの使用
以下の手順では、コマンドラインインターフェースで IPA ヘルプコマンドを作成する方法を説明します。
手順
- 端末を開き、IdM サーバーに接続します。
ヘルプで使用できるコマンドの一覧を表示するには、
ipa help commands
コマンドを実行します。$ ipa help commands
コマンドのいずれかを選択し、
ipa help < COMMAND> のパターンに従って help コマンドを使用します
。<COMMAND> 文字列
の代わりに、直前の手順で表示したコマンドのいずれかを追加します。$ ipa help user-add
関連情報
-
ipa
の man ページ
1.5. IPA コマンドの構造
IPA CLI は、以下のタイプのコマンドを区別します。
- 組み込みコマンド gitops- gitopsBuilt-in コマンドはすべて IdM サーバーで利用できます。
- プラグインにより提供されたコマンド
IPA コマンドの構造を使用すると、さまざまなタイプのオブジェクトを管理できます。以下に例を示します。
- ユーザー
- ホスト
- DNS レコード
- 証明書
その他にも多数あります。
このようなほとんどのオブジェクトでは、IPA CLI に、以下を行うためのコマンドが含まれます。
-
追加 (
add
) -
修正 (
mod
) -
削除 (
del
) -
検索 (
find
) -
表示 (
show
)
コマンドの構造は次のとおりです。
ipa user-add
、ipa user-mod
、ipa user-del
、ipa user-find
、ipa user-show
ipa host-add
、ipa host-mod
、ipa host-del
、ipa host-find
、ipa host-show
ipa dnsrecord-add
、ipa dnsrecord-mod
、ipa dnsrecord-del
、ipa dnsrecord-find
、ipa dnrecord-show
ipa user-add [options]
でユーザーを作成できます。[options]
は任意です。ipa user-add
コマンドのみを使用する場合、スクリプトは、詳細を 1 つずつ要求します。
既存のオブジェクトを変更するには、オブジェクトを定義する必要があります。そのため、コマンドにはオブジェクト( ipa user-mod USER_NAME [options]
)も含まれます。
1.6. IPA コマンドでユーザーアカウントを IdM コマンドに追加
以下の手順では、コマンドラインを使用して、新しいユーザーを Identity Management(IdM)データベースに追加する方法を説明します。
前提条件
- IdM サーバーにユーザーアカウントを追加するには、管理者権限が必要です。
手順
- 端末を開き、IdM サーバーに接続します。
新しいユーザーを追加するコマンドを入力します。
$ ipa user-add
このコマンドは、ユーザーアカウントの作成に必要な基本データを提供するように要求するスクリプトを実行します。
- First name: フィールドに、新規ユーザーの名前を入力して、Enter キーを押します。
- Last name: フィールドに、新規ユーザーの苗字を入力し、Enter キーを押します。
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
構文とは異なります。たとえば、パスワードを追加するなど、変更を実行する既存のユーザーアカウントを定義する必要があるためです。
前提条件
- ユーザーアカウントを変更するには、管理者権限が必要です。
手順
- 端末を開き、IdM サーバーに接続します。
ipa user-mod
コマンドを入力し、変更するユーザーと、パスワードを追加するための--password
などのオプションを指定します。$ ipa user-mod euser --password
このコマンドは、新しいパスワードを追加できるスクリプトを実行します。
- 新しいパスワードを入力し、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 に対して認証できないアクティブな以前のユーザーです。保存済みユーザーには、アクティブユーザーのときに有効になっていたアカウントプロパティーの大部分が保持されていますが、ユーザーグループからは除外されています。
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 を参照してください。
手順
- 端末を開き、IdM サーバーに接続します。
ユーザーのログイン、ユーザーの名前、および名字を追加します。メールアドレスを追加することもできます。
$ 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 にログインする場合は、常にユーザー名を小文字で入力する必要があります。また、user と User など、大文字と小文字のみが異なるユーザー名を追加することはできません。
ユーザー名のデフォルトの長さは、最大 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 を参照してください。
手順
- 端末を開き、IdM サーバーに接続します。
次のコマンドで、ユーザーアカウントをアクティベートします。
$ 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 を参照してください。
手順
- 端末を開き、IdM サーバーに接続します。
次のコマンドで、ユーザーアカウントを保存します。
$ 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 を参照してください。
手順
- 端末を開き、IdM サーバーに接続します。
次のコマンドで、ユーザーアカウントを削除します。
$ 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 を参照してください。
手順
- 端末を開き、IdM サーバーに接続します。
次のコマンドで、ユーザーアカウントをアクティベートします。
$ 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 に対して認証できないアクティブな以前のユーザーです。保存済みユーザーには、アクティブユーザーのときに有効になっていたアカウントプロパティーの大部分が保持されていますが、ユーザーグループからは除外されています。
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、またはユーザー管理者ロールを管理する管理者権限
手順
- IdM Web UI にログインします。
ユーザー → ステージユーザー タブに移動します。
または、ユーザー → アクティブユーザー にユーザーアカウントを追加できますが、アカウントにユーザーグループを追加することはできません。
- + 追加 アイコンをクリックします。
- ステージユーザーの追加 ダイアログボックスで、新規ユーザーの 名前 と 名字 を入力します。
(必要に応じて) ユーザーログイン フィールドにログイン名を追加します。
空のままにすると、IdM サーバーは、名字の前に、名前の最初の 1 文字が追加された形式で、ログイン名を作成します。ログイン名には、32 文字まで使用できます。
- (必要に応じて) GID ドロップダウンメニューで、ユーザーに含まれるグループを選択します。
- [オプション] パスワード および パスワードの確認 フィールドに、パスワードを入力して確定し、両方が一致していることを確認します。
追加 ボタンをクリックします。
この時点では、ステージユーザー テーブルでユーザーアカウントを確認できます。
ユーザー名をクリックすると、電話番号、住所、職業の追加などの詳細設定を編集できます。
3.3. IdM Web UI でステージユーザーのアクティベート
ユーザーが IdM にログインし、ユーザーを IdM グループに追加する前に、ステージユーザーアカウントをアクティベートする必要があります。本セクションでは、ステージユーザーアカウントをアクティベートする方法を説明します。
前提条件
- IdM Web UI、またはユーザー管理者ロールを管理する管理者権限
- IdM に、1 つ以上のステージユーザーアカウント
手順
- IdM Web UI にログインします。
- ユーザー → ステージユーザー タブに移動します。
- 有効にするユーザーアカウントのチェックボックスをクリックします。
アクティベート ボタンをクリックします。
- 確認 ダイアログボックスで、OK ボタンをクリックします。
アクティベーションに成功したら、IdM Web UI により、ユーザーがアクティベートされ、ユーザーアカウントが アクティブユーザー に移動したことを示す緑色の確認が表示されます。このアカウントはアクティブで、ユーザーは IdM ドメインと IdM Web UI に対して認証できます。ユーザーは、初回ログイン時にパスワードを変更するように求められます。
このステージで、アクティブなユーザーアカウントをユーザーグループに追加できます。
3.4. Web UI でのユーザーアカウントの無効化
アクティブなユーザーアカウントを無効にできます。ユーザーアカウントを無効にすると、ユーザーアカウントはアカウントを非アクティブにできるため、そのユーザーアカウントを使用して Kerberos などの IdM サービスを認証および使用したり、タスクを実行することができません。
無効にしたユーザーアカウントはそのまま IdM に残り、関連する情報は何も変更しません。保存済みユーザーアカウントとは異なり、無効にしたユーザーアカウントはアクティブな状態のままとなり、ユーザーグループのメンバーになります。
ユーザーアカウントを無効にした後、既存の接続はユーザーの Kerberos TGT や他のチケットの有効期限が切れるまで有効です。チケットの期限が切れると、ユーザーが更新できなくなります。
前提条件
- IdM Web UI、またはユーザー管理者ロールを管理する管理者権限
手順
- IdM Web UI にログインします。
- ユーザー → アクティブユーザー タブに移動します。
- 無効にするユーザーアカウントのチェックボックスをクリックします。
無効 ボタンをクリックします。
- 確認 ダイアログボックスで、OK ボタンをクリックします。
無効化の手順に成功した場合は、アクティブユーザー テーブルの状態の列で確認できます。
3.5. Web UI でユーザーアカウントの有効化
IdM を使用して、無効にしたアクティブなユーザーアカウントを再度有効にできます。ユーザーアカウントを有効にすると、無効になったアカウントが有効になります。
前提条件
- IdM Web UI、またはユーザー管理者ロールを管理する管理者権限
手順
- IdM Web UI にログインします。
- ユーザー → アクティブユーザー タブに移動します。
- 有効にするユーザーアカウントのチェックボックスをクリックします。
有効 ボタンをクリックします。
- 確認 ダイアログボックスで、OK ボタンをクリックします。
変更に成功すると、アクティブユーザー テーブルの状態の列で確認できます。
3.6. IdM Web UI でアクティブなユーザーの保存
ユーザーアカウントを保存すると、アクティブユーザー タブからアカウントを削除した状態で、IdM でアカウントを維持できます。
従業員が退職する場合は、ユーザーアカウントを保存します。ユーザーアカウントを数週間または数か月間 (たとえば育児休暇) 無効にする場合は、ユーザーアカウントを無効にします。詳細は、Web UI でのユーザーアカウントの無効化 を参照してください。保存済みアカウントはアクティブではないため、そのユーザーが内部ネットワークにはアクセスできないものの、すべてのデータが含まれる状態でデータベース内に残ります。
復元したアカウントをアクティブモードに戻すことができます。
保存済みユーザーの一覧は、以前のユーザーアカウントの履歴を提供します。
前提条件
- IdM (Identity Management) Web UI、またはユーザー管理者ロールを管理する管理者権限
手順
- IdM Web UI にログインします。
- ユーザー → アクティブユーザー タブに移動します。
- 保存するユーザーアカウントのチェックボックスをクリックします。
削除 ボタンをクリックします。
- ユーザーの削除 ダイアログボックスで、削除モード ラジオボタンを、保存 に切り替えます。
削除 ボタンをクリックします。
これにより、そのユーザーアカウントは、保存済みユーザー に移動します。
保存済みユーザーを復元する必要がある場合は、「IdM Web UI でユーザーの復元」を参照してください。
3.7. IdM Web UI でユーザーの復元
IdM (Identity Management) を使用すると、保存済みユーザーアカウントをアクティブな状態で復元できます。
前提条件
- IdM Web UI、またはユーザー管理者ロールを管理する管理者権限
手順
- IdM Web UI にログインします。
- ユーザー → 保存済みユーザー タブに移動します。
- 復元するユーザーアカウントのチェックボックスをクリックします。
復元 ボタンをクリックします。
- 確認 ダイアログボックスで、OK ボタンをクリックします。
IdM Web UI は、緑色の確認を表示し、ユーザーアカウントを アクティブユーザー タブに移動します。
3.8. IdM Web UI でユーザーの削除
ユーザーの削除は元に戻せない操作であり、グループメンバーシップやパスワードなど、ユーザーアカウントが IdM データベースから完全に削除されます。ユーザーの外部設定 (システムアカウントやホームディレクトリーなど) は削除されませんが、IdM からはアクセスできなくなります。
以下を削除できます。
アクティブなユーザー - IdM Web UI では、以下のオプションを利用できます。
ユーザーを一時的に保存する
詳細は「IdM Web UI でアクティブなユーザーの保存」を参照してください。
- 永続的に削除する
- ステージユーザー - ステージユーザーを永続的に削除できます。
- 保存済みユーザー - 保存済みユーザーを永続的に削除できます。
以下の手順では、アクティブなユーザーの削除を説明します。以下のタブでも同じようにユーザーアカウントを削除できます。
- ステージユーザー タブ
- 保存済みユーザー タブ
前提条件
- IdM Web UI、またはユーザー管理者ロールを管理する管理者権限
手順
- IdM Web UI にログインします。
ユーザー → アクティブユーザー タブに移動します。
ユーザー → ステージユーザー または ユーザー → 保存済みユーザー でも、ユーザーアカウントを削除できます。
- 削除 アイコンをクリックします。
- ユーザーの削除 ダイアログボックスで、モードの削除 ラジオボタンを、削除 に切り替えます。
- 削除 ボタンをクリックします。
ユーザーアカウントが、IdM から完全に削除されました。
第4章 Ansible Playbook を使用したユーザーアカウントの管理
Ansible Playbook を使用して IdM のユーザーを管理できます。ユーザーのライフサイクル を示した後、本章では以下の操作に Ansible Playbook を使用する方法を説明します。
-
YML
ファイルに直接リストされている 単一ユーザーが存在することを確認 します。 -
YML
ファイルに直接リストされている 複数のユーザーが存在することを確認 します。 -
YML
ファイルから参照されるJSON
ファイルに一覧表示される 複数のユーザーが存在することを確認 します。 -
YML
ファイルに直接一覧表示されている ユーザーがないことを確認 します。
4.1. ユーザーのライフサイクル
Identity Management (IdM) は、次の 3 つのユーザーアカウント状態に対応します
- ステージ ユーザーは認証できません。これは初期状態です。アクティブユーザーに必要なユーザーアカウントプロパティーをすべて設定できるわけではありません (例: グループメンバーシップ)。
- アクティブ ユーザーは認証が可能です。必要なユーザーアカウントプロパティーはすべて、この状態で設定する必要があります。
- 保存済み ユーザーは、非アクティブであると見なされており、IdM に対して認証できないアクティブな以前のユーザーです。保存済みユーザーには、アクティブユーザーのときに有効になっていたアカウントプロパティーの大部分が保持されていますが、ユーザーグループからは除外されています。
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 にユーザーが存在することを確認する方法を説明します。
前提条件
- IdM 管理者パスワードを把握している。
- Ansible コントローラーに ansible-freeipa パッケージがインストールされている。
手順
inventory.file
などのインベントリーファイルを作成して、そのファイルにipaserver
を定義します。[ipaserver] server.idm.example.com
IdM に存在するユーザーのデータで Ansible Playbook ファイルを作成します。この手順を単純化するには、
/usr/share/doc/ansible-freeipa/playbooks/user/add-user.yml
ファイルのサンプルをコピーして変更できます。たとえば、idm_user という名前のユーザーを作成し、Password123 をユーザーパスワードとして追加するには、次のコマンドを実行します。--- - name: Playbook to handle users hosts: ipaserver become: true tasks: - name: Create user idm_user ipauser: ipaadmin_password: MySecret123 name: idm_user first: Alice last: Acme uid: 1000111 gid: 10011 phone: "+555123457" email: idm_user@acme.com passwordexpiration: "2023-01-19 23:59:59" password: "Password123" update_password: on_create
ユーザーを追加するには、以下のオプションを使用する必要があります。
- 名前: ログイン名
- first: 最初の name 文字列
- last: 最後の名前文字列
利用可能なユーザーオプションの完全な一覧は、
/usr/share/doc/ansible-freeipa/README-user.md
Markdown ファイルを参照してください。注記update_password: on_create
オプションを使用する場合、Ansible はユーザーの作成時にのみユーザーパスワードを作成します。ユーザーがパスワードで作成されている場合、Ansible は新しいパスワードを生成しません。Playbook を実行します。
$ ansible-playbook -v -i path_to_inventory_directory/inventory.file path_to_playbooks_directory/add-IdM-user.yml
検証手順
ipa user-show
コマンドを使用して、新しいユーザーアカウントが IdM に存在するかどうかを確認できます。admin として
ipaserver
にログインします。$ ssh admin@server.idm.example.com Password: [admin@server /]$
admin の Kerberos チケットを要求します。
$ kinit admin Password for admin@IDM.EXAMPLE.COM:
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 パッケージがインストールされている。
手順
inventory.file
などのインベントリーファイルを作成して、そのファイルにipaserver
を定義します。[ipaserver] server.idm.example.com
IdM に存在するユーザーのデータで Ansible Playbook ファイルを作成します。この手順を単純化するには、
/usr/share/doc/ansible-freeipa/playbooks/user/ensure-users-present.yml
ファイルのサンプルをコピーして変更できます。たとえば、ユーザー idm_user_1、idm_user_2、および idm_user_3 を作成し、Password123 を idm_user_1 のパスワードとして追加するには、次のコマンドを実行します。--- - name: Playbook to handle users hosts: ipaserver become: true tasks: - name: Create user idm_users ipauser: ipaadmin_password: MySecret123 users: - name: idm_user_1 first: Alice last: Acme uid: 10001 gid: 10011 phone: "+555123457" email: idm_user@acme.com passwordexpiration: "2023-01-19 23:59:59" password: "Password123" - name: idm_user_2 first: Bob last: Acme uid: 100011 gid: 10011 - name: idm_user_3 first: Eve last: Acme uid: 1000111 gid: 10011
注記update_password: on_create オプションを指定しないと、Ansible は Playbook が実行されるたびにユーザーパスワードを再設定します。最後にプレイブックが実行されてからユーザーがパスワードを変更した場合、Ansibleはパスワードを再設定します。
Playbook を実行します。
$ ansible-playbook -v -i path_to_inventory_directory/inventory.file path_to_playbooks_directory/add-users.yml
検証手順
ipa user-show
コマンドを使用して、ユーザーアカウントが IdM に存在するかどうかを確認できます。管理者として
ipaserver
にログインします。$ ssh administrator@server.idm.example.com Password: [admin@server /]$
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 パッケージがインストールされている。
手順
inventory.file
などのインベントリーファイルを作成して、そのファイルにipaserver
を定義します。[ipaserver] server.idm.example.com
必要なタスクで 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 }}"
users.json
ファイルを作成し、IdM ユーザーを追加します。この手順を簡素化するには、/usr/share/doc/ansible-freeipa/playbooks/user/users.json
ファイルのサンプルをコピーして変更できます。たとえば、ユーザー idm_user_1、idm_user_2、および idm_user_3 を作成し、Password123 を idm_user_1 のパスワードとして追加するには、次のコマンドを実行します。{ "users": [ { "name": "idm_user_1", "first": "Alice", "last": "Acme", "password": "Password123" }, { "name": "idm_user_2", "first": "Bob", "last": "Acme" }, { "name": "idm_user_3", "first": "Eve", "last": "Acme" } ] }
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 に存在するかどうかを確認できます。管理者として
ipaserver
にログインします。$ ssh administrator@server.idm.example.com Password: [admin@server /]$
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 パッケージがインストールされている。
手順
inventory.file
などのインベントリーファイルを作成して、そのファイルにipaserver
を定義します。[ipaserver] server.idm.example.com
IdM がないユーザーで Ansible Playbook ファイルを作成します。この手順を単純化するには、
/usr/share/doc/ansible-freeipa/playbooks/user/ensure-users-present.yml
ファイルのサンプルをコピーして変更できます。たとえば、ユーザー idm_user_1、idm_user_2、および idm_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
Playbook ファイルとインベントリーファイルを指定して Ansible Playbook を実行します。
$ ansible-playbook -v -i path_to_inventory_directory/inventory.file path_to_playbooks_directory/delete-users.yml
検証手順
ipa user-show
コマンドを使用して、ユーザーアカウントが IdM に存在しないことを確認できます。
管理者として
ipaserver
にログインします。$ ssh administrator@server.idm.example.com Password: [admin@server /]$
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 クライアントの IdM ユーザーへの sudo アクセスの許可
本セクションでは、Identity Management でユーザーにsudo
アクセス権を付与する方法を説明します。
5.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
コマンドに対して認証を行うことができます。
関連情報
- 「 sudo アクセスの管理 」を参照してください。
5.2. CLI での 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
のユーザーアカウントを作成し、ユーザーのパスワードを作成してそのアカウントのロックを解除している。CLI を使用して新しい IdM ユーザーを追加する方法は、「 コマンドラインでユーザーの追加」を参照し てください。 -
idmclient
ホストにローカルidm_user
アカウントが存在しない。idm_user
ユーザーは、ローカルの/etc/passwd
ファイルには表示されません。
手順
IdM の
管理者
として Kerberos チケットを取得します。[root@idmclient ~]# kinit admin
sudo
コマンドの IdM データベースに/usr/sbin/reboot
コマンドを追加します。[root@idmclient ~]# ipa sudocmd-add /usr/sbin/reboot ------------------------------------- Added Sudo Command "/usr/sbin/reboot" ------------------------------------- Sudo Command: /usr/sbin/reboot
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
/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 -------------------------
idm_user_reboot
ルールを IdMidmclient
ホストに適用します。[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 -------------------------
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 -------------------------
サーバーからクライアントへの変更の伝播には数分かかる場合があります。
検証手順
-
idmclient
ホストにidm_user
アカウントとしてログインします。 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
sudo
を使用してマシンを再起動します。プロンプトが表示されたら、idm_user
のパスワードを入力します。[idm_user@idmclient ~]$ sudo /usr/sbin/reboot [sudo] password for idm_user:
5.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
ファイルには表示されません。
手順
sudo
コマンドの IdM データベースに/usr/sbin/reboot
コマンドを追加します。- Policy → Sudo → Sudo Commands の順に移動します。
- 右上にある Add をクリックして、Add sudo command ダイアログボックスを開きます。
sudo
:/usr/sbin/reboot
を使用してユーザーが実行できるコマンドを入力します。図5.1 IdM sudo コマンドの追加
- Add をクリックします。
新しい
sudo
コマンドエントリーを使用して sudo ルールを作成し、idm_user が idmclient マシンを再起動できるようにします。- Policy → Sudo → Sudo ルールに移動します。
- 右上にある Add をクリックして、Add sudo rule ダイアログボックスを開きます。
-
sudo
ルールの名前を入力します (idm_user_reboot)。 - Add and Edit をクリックします。
ユーザーを指定します。
- Who セクションで、ラジオボタン Specified Users and Groups を選択します。
- サブセクション User category the rule applies to で Add をクリックして、Add users into sudo rule "idm_user_reboot" ダイアログボックスを開きます。
- Add users into sudo rule "idm_user_reboot" ダイアログボックスにある Available 列で、idm_user チェックボックスを選択し、これを Prospective 列に移動します。
- Add をクリックします。
ホストを指定します。
- Access this host セクションで、Specified Hosts and Groups ラジオボタンを確認します。
- サブセクション Host category this rule applies to で Add をクリックして、Add hosts into sudo rule "idm_user_reboot" ダイアログボックスを開きます。
- Add hosts into sudo rule "idm_user_reboot" ダイアログボックスにある Available 列で、idmclient.idm.example.com チェックボックスを選択し、これを Prospective 列に移動します。
- Add をクリックします。
コマンドを指定します。
- Run Commands セクションの Command category the rule applies to サブセクションで、Specified Commands and Groups ラジオボタンを確認します。
- サブセクション Sudo Allow Commands で Add をクリックして、Add allow sudo commands into sudo rule "idm_user_reboot" ダイアログボックスを開きます。
-
Add allow sudo commands into sudo rule "idm_user_reboot" ダイアログボックスにある Available 列で、
/usr/sbin/reboot
チェックボックスを選択し、これを Prospective 列に移動します。 - Add をクリックして、idm_sudo_reboot ページに戻ります。
図5.2 IdM sudo ルールの追加
- 左上隅にある Save をクリックします。
新しいルールはデフォルトで有効になります。
サーバーからクライアントへの変更の伝播には数分かかる場合があります。
検証手順
-
idmclient
にidm_user
としてログインします。 sudo
を使用してマシンを再起動します。プロンプトが表示されたら、idm_user
のパスワードを入力します。$ sudo /usr/sbin/reboot [sudo] password for idm_user:
sudo
ルールが正しく設定されている場合には、マシンが再起動します。
5.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
という名前のローカルサービスアカウントを作成している。
手順
IdM の
管理者
として Kerberos チケットを取得します。[root@idmclient ~]# kinit admin
/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
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
--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 の外部に配置できます。グループ名には%
接頭辞を追加しないでください。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 -------------------------
run_third-party-app_report
ルールを IdMidmclient
ホストに適用します。[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 -------------------------
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
サーバーからクライアントへの変更の伝播には数分かかる場合があります。
検証手順
-
idmclient
ホストにidm_user
アカウントとしてログインします。 新しい sudo ルールをテストします。
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
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.
5.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
という名前のローカルサービスアカウントを作成している。
手順
/opt/third-party-app/bin/report
コマンドを、sudo
コマンドの IdM データベースに追加します。- Policy → Sudo → Sudo Commands の順に移動します。
- 右上にある Add をクリックして、Add sudo command ダイアログボックスを開きます。
コマンド
/opt/third-party-app/bin/report
を入力します。- Add をクリックします。
新しい
sudo
コマンドエントリーを使用して、新しいsudo
ルールを作成します。- Policy → Sudo → Sudo ルールに移動します。
- 右上にある Add をクリックして、Add sudo rule ダイアログボックスを開きます。
sudo
ルールの名前 run_third-party-app_report を入力します。- Add and Edit をクリックします。
ユーザーを指定します。
- Who セクションで、ラジオボタン Specified Users and Groups を選択します。
- User category the rule applies to のサブセクションで Add をクリックして、Add users into sudo rule "run_third-party-app_report" ダイアログボックスを開きます。
Available 列の Add users into sudo rule "run_third-party-app_report" ダイアログボックスで、idm_user チェックボックスをオンにして、これを Prospective 列に移動します。
- Add をクリックします。
ホストを指定します。
- Access this host セクションで、Specified Hosts and Groups ラジオボタンを確認します。
- Host category this rule applies to サブセクションで Add をクリックして、 Add hosts into sudo rule "run_third-party-app_report" ダイアログボックスを開きます。
Available 列の Add hosts into sudo rule "run_third-party-app_report" ダイアログボックスで、idmclient.idm.example.com チェックボックスをオンにして、これを Prospective 列に移動します。
- Add をクリックします。
コマンドを指定します。
- Run Commands セクションの Command category the rule applies to サブセクションで、Specified Commands and Groups ラジオボタンを確認します。
- Sudo Allow Commands サブセクションで Add をクリックして、Add allow sudo commands into sudo rule "run_third-party-app_report" ダイアログボックスを開きます。
Available 列の Add allow sudo commands into sudo rule "run_third-party-app_report" ダイアログボックスで、
/opt/third-party-app/bin/report
チェックボックスをオンにして、これを Prospective 列に移動します。- Add をクリックして、run_third-party-app_report のページに戻ります。
RunAs ユーザーを指定します。
- As Whom で、指定したユーザーとグループ のラジオボタンを確認します。
- RunAs ユーザー サブセクションで Add をクリックして、Add RunAs users into sudo rule "run_third-party-app_report" ダイアログボックスを開きます。
Add RunAs users into sudo rule "run_third-party-app_report" ダイアログボックスで、External ボックスに
thirdpartyapp
サービスアカウントを入力し、これを Prospective 列に移動します。- Add をクリックして、run_third-party-app_report のページに戻ります。
- 左上隅にある Save をクリックします。
新しいルールはデフォルトで有効になります。
図5.3 sudo ルールの詳細

サーバーからクライアントへの変更の伝播には数分かかる場合があります。
検証手順
-
idmclient
ホストにidm_user
アカウントとしてログインします。 新しい sudo ルールをテストします。
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
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.
5.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
特権がある。
手順
-
/etc/sssd/sssd.conf
設定ファイルを開きます。 [domain/<domain_name>]
セクションに以下のエントリーを追加します。[domain/<domain_name>] pam_gssapi_services = sudo, sudo-i
-
/etc/sssd/sssd.conf
ファイルを保存して閉じます。 SSSD サービスを再起動して、設定の変更を読み込みます。
[root@idmclient ~]# systemctl restart sssd
-
/etc/pam.d/sudo
の PAM 設定ファイルを開きます。 以下のエントリーを、
/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
-
/etc/pam.d/sudo
ファイルを保存して閉じます。 -
/etc/pam.d/sudo-i
の PAM 設定ファイルを開きます。 以下のエントリーを、
/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
-
/etc/pam.d/sudo-i
ファイルを保存して閉じます。
検証手順
idm_user
アカウントとしてホストにログインします。[root@idm-client ~]# ssh -l idm_user@idm.example.com localhost idm_user@idm.example.com's password:
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
(オプション)
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:
パスワードを指定せずに
sudo
を使用してマシンを再起動します。[idm_user@idmclient ~]$ sudo /usr/sbin/reboot
関連情報
- IdM の用語一覧の GSSAPI エントリー
- IdM Web UI で IdM クライアントの IdM ユーザーへの sudo アクセスの許可
- CLI での IdM クライアントの IdM ユーザーへの sudo アクセス許可
-
pam_sss_gss(8)
の man ページ -
sssd.conf (5)
の man ページ
5.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
特権がある。
手順
-
/etc/sssd/sssd.conf
設定ファイルを開きます。 [domain/<domain_name>]
セクションに以下のエントリーを追加します。[domain/<domain_name>] pam_gssapi_services = sudo, sudo-i pam_gssapi_indicators_map = sudo:pkinit, sudo-i:pkinit
-
/etc/sssd/sssd.conf
ファイルを保存して閉じます。 SSSD サービスを再起動して、設定の変更を読み込みます。
[root@idmclient ~]# systemctl restart sssd
-
/etc/pam.d/sudo
の PAM 設定ファイルを開きます。 以下のエントリーを、
/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
-
/etc/pam.d/sudo
ファイルを保存して閉じます。 -
/etc/pam.d/sudo-i
の PAM 設定ファイルを開きます。 以下のエントリーを、
/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
-
/etc/pam.d/sudo-i
ファイルを保存して閉じます。
検証手順
idm_user
アカウントとしてホストにログインし、スマートカードで認証します。[root@idmclient ~]# ssh -l idm_user@idm.example.com localhost PIN for smart_card
スマートカードユーザーを使用して 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
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
パスワードを指定せずに
sudo
を使用してマシンを再起動します。[idm_user@idmclient ~]$ sudo /usr/sbin/reboot
関連情報
- PAM サービスの GSSAPI 認証を制御する SSSD オプション
- IdM 用語 一覧の GSSAPI エントリー
- スマートカード認証用の Identity Management の設定
- Kerberos 認証インジケーター
- IdM Web UI で IdM クライアントの IdM ユーザーへの sudo アクセスの許可
- CLI での IdM クライアントの IdM ユーザーへの sudo アクセス許可
-
pam_sss_gss(8)
の man ページ -
sssd.conf (5)
の man ページ
5.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 モジュールは、必要なサービスチケットを取得できるすべてのユーザーを認証します。
例
次のオプションでは、sudo
と sudo-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
ドメインの場合-
sudo
とsudo -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 ...
関連情報
5.9. sudo の GSSAPI 認証のトラブルシューティング
IdM から Kerberos チケットを使用して sudo
サービスに対する認証できない場合は、以下のシナリオを使用して設定のトラブルシューティングを行います。
前提条件
-
sudo
サービスの GSSAPI 認証が有効化されている。「IdM クライアントでの sudo の GSSAPI 認証の有効化」を参照してください。 -
/etc/sssd/sssd.conf
ファイルと、/etc/pam.d/
ディレクトリーの PAM ファイルを変更するためのroot
特権がある。
手順
以下のエラーが表示された場合、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
5.10. Ansible Playbook を使用した IdM クライアントでの IdM ユーザーの sudo アクセスの確保
Identity Management (IdM) では、特定の IdM ホストの IdM ユーザーアカウントに sudo
アクセスが付与されるようにできます。
この手順では、idm_user_reboot という名前の sudo
ルールが存在することを確認します。このルールは、idmclient マシンで /usr/sbin/reboot
コマンドを実行するパーミッションを idm_user に付与します。
前提条件
- Ansible コントローラーに ansible-freeipa パッケージがインストールされている。
- IdM 管理者パスワードを把握している。
- IdM に idm_user のユーザーアカウントが存在することを確認し、そのユーザーのパスワードを作成してアカウントをロック解除している。コマンドラインインターフェースを使用して新しい IdM ユーザーを追加する方法は、「コマンドラインで ユーザーの追加」を参照して ください。
-
idmclient には、ローカルの idm_user アカウントがありません。idm_user ユーザーは、idmclient の
/etc/passwd
ファイルに一覧表示されません。
手順
inventory.file
などのインベントリーファイルを作成し、そこにipaservers
を定義します。[ipaservers] server.idm.example.com
sudo
コマンドを追加します。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
Playbook を実行します。
$ ansible-playbook -v -i path_to_inventory_directory/inventory.file path_to_playbooks_directory/ensure-reboot-sudocmd-is-present.yml
コマンドを参照する
sudo
ルールを作成します。sudo
コマンドエントリーを使用して sudo ルールが存在することを確認するensure-sudorule-for-idmuser-on-idmclient-is-present.yml
Ansible Playbook を作成します。sudo ルールは、idm_user が idmclient マシンを再起動することを許可します。この手順を単純化するには、/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
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_user が sudo
を使用して idmclient を再起動して、IdM サーバーに存在する sudo
ルールが idmclient で機能することを確認します。サーバーに加えられた変更がクライアントで反映されるまで数分の時間がかかる場合があります。
- idmclient に idm_user としてログインします。
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
ファイルを参照してください。
第6章 ldapmodify を使用した IdM ユーザーを外部で管理
ldapmodify
ユーティリティーおよび ldapdelete
ユーティリティーを使用して、コマンドラインインターフェース (CLI) から Identity Management (IdM) LDAP を直接変更できます。このユーティリティーは、ディレクトリー内容の追加、編集、および削除に完全機能を提供します。これらのユーティリティーを使用して、サーバーの設定エントリーとユーザーエントリーのデータの両方を管理できます。このユーティリティーは、1 つまたは複数のディレクトリーを一括管理するためにスクリプトを作成するのに使用することもできます。
6.1. IdM ユーザーアカウントを外部で管理するためのテンプレート
本セクションでは、IdM におけるさまざまなユーザー管理操作のテンプレートを説明します。テンプレートには、以下のゴールを達成するために ldapmodify
を使用して変更する必要のある属性が表示されます。
- 新規 stage ユーザーの追加
- ユーザーの属性の変更
- ユーザーの有効化
- ユーザーの無効化
- ユーザーの保存
テンプレートは LDAP データ交換形式(LDIF)でフォーマットされます。LDIF は、LDAP ディレクトリーのコンテンツおよび更新リクエストを表す標準的なプレーンテキストデータ交換形式です。
テンプレートを使用して、プロビジョニングシステムの LDAP プロバイダーを設定して、IdM ユーザーアカウントを管理できます。
詳細な手順例は、以下のセクションを参照してください。
新規 stage ユーザーを追加するためのテンプレート
UID および GID が自動的に割り当てられた ユーザーを追加するためのテンプレート。作成したエントリーの識別名 (DN) は
uid=user_login
で開始する必要があります。dn: uid=user_login,cn=staged users,cn=accounts,cn=provisioning,dc=idm,dc=example,dc=com changetype: add objectClass: top objectClass: inetorgperson uid: user_login sn: surname givenName: first_name cn: full_name
UID と GID が静的に割り当てられている ユーザーを追加するためのテンプレート
dn: uid=user_login,cn=staged users,cn=accounts,cn=provisioning,dc=idm,dc=example,dc=com changetype: add objectClass: top objectClass: person objectClass: inetorgperson objectClass: organizationalperson objectClass: posixaccount uid: user_login uidNumber: UID_number gidNumber: GID_number sn: surname givenName: first_name cn: full_name homeDirectory: /home/user_login
stage ユーザーの追加時に IdM オブジェクトクラスを指定する必要はありません。IdM は、ユーザーのアクティベート後にこれらのクラスを自動的に追加します。
既存ユーザーを変更するためのテンプレート
ユーザーの属性の変更
dn: distinguished_name changetype: modify replace: attribute_to_modify attribute_to_modify: new_value
ユーザーの無効化
dn: distinguished_name changetype: modify replace: nsAccountLock nsAccountLock: TRUE
ユーザーの有効化
dn: distinguished_name changetype: modify replace: nsAccountLock nsAccountLock: FALSE
nssAccountLock
属性の更新は、stage ユーザーおよび保存済みユーザーには影響を与えません。更新操作が正常に完了しても、属性値はnssAccountLock: TRUE
のままになります。ユーザーの保持
dn: distinguished_name changetype: modrdn newrdn: uid=user_login deleteoldrdn: 0 newsuperior: cn=deleted users,cn=accounts,cn=provisioning,dc=idm,dc=example,dc=com
ユーザーを変更する前に、ユーザーのログインを検索してユーザーの識別名 (DN) を取得します。以下の例では、user_allowed_to_modify_user_entries ユーザーは、activator または IdM 管理者など、ユーザーおよびグループの情報の変更を許可されたユーザーです。この例のパスワードは、このユーザーのパスワードです。
[...]
# ldapsearch -LLL -x -D "uid=user_allowed_to_modify_user_entries,cn=users,cn=accounts,dc=idm,dc=example,dc=com" -w "Secret123" -H ldap://r8server.idm.example.com -b "cn=users,cn=accounts,dc=idm,dc=example,dc=com" uid=test_user
dn: uid=test_user,cn=users,cn=accounts,dc=idm,dc=example,dc=com
memberOf: cn=ipausers,cn=groups,cn=accounts,dc=idm,dc=example,dc=com
6.2. IdM グループアカウントを外部で管理するためのテンプレート
本セクションでは、IdM におけるさまざまなユーザーグループ管理操作のテンプレートを説明します。テンプレートには、以下の目的を達成するために ldapmodify
を使用して変更する必要のある属性が表示されます。
- 新規グループの作成
- 既存グループの削除
- グループへのメンバーの追加
- グループからメンバーの削除
テンプレートは LDAP データ交換形式(LDIF)でフォーマットされます。LDIF は、LDAP ディレクトリーのコンテンツおよび更新リクエストを表す標準的なプレーンテキストデータ交換形式です。
テンプレートを使用して、プロビジョニングシステムの LDAP プロバイダーを設定して、IdM グループアカウントを管理できます。
新規グループの作成
dn: cn=group_name,cn=groups,cn=accounts,dc=idm,dc=example,dc=com changetype: add objectClass: top objectClass: ipaobject objectClass: ipausergroup objectClass: groupofnames objectClass: nestedgroup objectClass: posixgroup uid: group_name cn: group_name gidNumber: GID_number
グループの変更
既存グループの削除
dn: group_distinguished_name changetype: delete
グループへのメンバーの追加
dn: group_distinguished_name changetype: modify add: member member: uid=user_login,cn=users,cn=accounts,dc=idm,dc=example,dc=com
stage または保存済みユーザーをグループに追加しないでください。更新操作が正常に完了しても、ユーザーはグループのメンバーとして更新されません。アクティブユーザーのみがグループに所属できます。
グループからメンバーの削除
dn: distinguished_name changetype: modify delete: member member: uid=user_login,cn=users,cn=accounts,dc=idm,dc=example,dc=com
グループを変更する前に、グループ名を使用して検索してグループの識別名 (DN) を取得します。
# ldapsearch -YGSSAPI -H ldap://server.idm.example.com -b "cn=groups,cn=accounts,dc=idm,dc=example,dc=com" "cn=group_name"
dn: cn=group_name,cn=groups,cn=accounts,dc=idm,dc=example,dc=com
ipaNTSecurityIdentifier: S-1-5-21-1650388524-2605035987-2578146103-11017
cn: testgroup
objectClass: top
objectClass: groupofnames
objectClass: nestedgroup
objectClass: ipausergroup
objectClass: ipaobject
objectClass: posixgroup
objectClass: ipantgroupattrs
ipaUniqueID: 569bf864-9d45-11ea-bea3-525400f6f085
gidNumber: 1997010017
6.3. ldapmodify での IdM ユーザーの保存
本セクションでは、ldapmodify
を使用して IdM ユーザーを保存する方法を説明します。つまり、従業員が退職した後にユーザーアカウントを非アクティブ化する方法を説明します。
前提条件
- ロールで IdM ユーザーとして認証を行い、ユーザーを保持できます。
手順
ユーザーを保存するロールを持つ IdM ユーザーとしてログインします。
$ kinit admin
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.
保存するユーザーの
dn
を入力します。dn: uid=user1,cn=users,cn=accounts,dc=idm,dc=example,dc=com
実行する変更のタイプとして modrdn を入力します。
changetype: modrdn
ユーザーの newrdn を指定します。
newrdn: uid=user1
ユーザーを保存することを示します。
deleteoldrdn: 0
新しい上位 DN を指定します。
newsuperior: cn=deleted users,cn=accounts,cn=provisioning,dc=idm,dc=example,dc=com
ユーザーを保存すると、そのエントリーをディレクトリー情報ツリー (DIT) 内の新しい場所に移動します。このため、新しい親エントリーの DN を新しい上位 DN として指定する必要があります。
Enter
を再度押して、これがエントリーの最後であることを確認します。[Enter] modifying rdn of entry "uid=user1,cn=users,cn=accounts,dc=idm,dc=example,dc=com"
- 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 ----------------------------
第7章 ユーザーの外部プロビジョニングのための IdM の設定
システム管理者は、Identity Management (IdM) が、ID 管理用の外部ソリューションでユーザーのプロビジョニングをサポートするように設定できます。
ipa
ユーティリティーを使用する代わりに、外部プロビジョニングシステムの管理者は ldapmodify
ユーティリティーを使用して IdM LDAP にアクセスできます。管理者は、ldapmodify を使用して CLI から、または LDIF ファイル を使用して、個々の stage ユーザーを追加できます。
IdM 管理者として、外部プロビジョニングシステムを完全に信頼して、検証済みのユーザーのみを追加することを前提とします。ただし、同時に、外部プロビジョニングシステムの管理者を User Administrator
の IdM ロールに割り当てて、新しいアクティブユーザーを直接追加する必要はありません。
外部プロビジョニングシステムで作成されたステージユーザーを自動的にアクティブユーザーに移動するように スクリプトを設定 できます。
本章では、以下の項を説明します。
- Identity Management(IdM)を準備 して、外部プロビジョニングシステムを使用して stage ユーザーを IdM に追加します。
- 外部プロビジョニングシステムが追加したユーザーをステージユーザーからアクティブユーザーに移動する スクリプトを作成 します。
外部プロビジョニングシステムを使用して IdM stage ユーザーを追加します。これには 2 つの方法があります。
7.1. stage ユーザーアカウントの自動アクティベーションに向けた IdM アカウントの準備
この手順では、外部プロビジョニングシステムが使用する 2 つの IdM ユーザーアカウントを設定する方法を説明します。適切なパスワードポリシーが指定されたグループにアカウントを追加すると、外部プロビジョニングシステムが IdM でユーザーのプロビジョニングを管理できるようになります。stage ユーザーを追加するために外部システムが使用するユーザーアカウントには provisionator という名前が付けられます。stage ユーザーを自動的にアクティベートするために使用されるユーザーアカウントは activator という名前です。
前提条件
- 手順を実行するホストが IdM に登録されます。
手順
IdM 管理者としてログインします。
$ kinit admin
stage ユーザーを追加する権限を持つ provisionator という名前のユーザーを作成します。
- provisionator ユーザーアカウントを追加します。
$ ipa user-add provisionator --first=provisioning --last=account --password
provisionator ユーザーに必要な権限を割り当てます。
stage ユーザーの追加を管理する
System Provisioning
というカスタムロールを作成します。$ ipa role-add --desc "Responsible for provisioning stage users" "System Provisioning"
Stage User Provisioning
の権限をロールに追加します。この権限により、stage ユーザーを追加することができます。$ ipa role-add-privilege "System Provisioning" --privileges="Stage User Provisioning"
provisionator ユーザーをロールに追加します。
$ ipa role-add-member --users=provisionator "System Provisioning"
- 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 [...]
ユーザーアカウントを管理する権限を持つ activator ユーザーを作成します。
activator ユーザーアカウントを追加します。
$ ipa user-add activator --first=activation --last=account --password
デフォルトの
User Administrator
ロールにユーザーを追加して、activator ユーザーに必要な権限を付与します。$ ipa role-add-member --users=activator "User Administrator"
アプリケーションアカウントのユーザーグループを作成します。
$ ipa group-add application-accounts
グループのパスワードポリシーを更新します。以下のポリシーは、アカウントのパスワードの有効期限やロックアウトを防ぎますが、複雑なパスワードを必要とすることでリスクの可能性を低減します。
$ ipa pwpolicy-add application-accounts --maxlife=10000 --minlife=0 --history=0 --minclasses=4 --minlength=8 --priority=1 --maxfail=0 --failinterval=1 --lockouttime=0
(必要に応じて) パスワードポリシーが IdM に存在することを確認します。
$ ipa pwpolicy-show application-accounts Group: application-accounts Max lifetime (days): 10000 Min lifetime (hours): 0 History size: 0 [...]
アプリケーションアカウントのグループにプロビジョニングアカウントおよびアクティベーションアカウントを追加します。
$ ipa group-add-member application-accounts --users={provisionator,activator}
ユーザーアカウントのパスワードを変更します。
$ kpasswd provisionator $ kpasswd activator
新しい IdM ユーザーのパスワードはすぐに失効するため、パスワードの変更が必要になります。
追加リソース:
- 「 コマンドラインでユーザーアカウントの管理」を 参照してください。
- 「 ユーザーへのパーミッションの委譲」を 参照してください。
- 「 IdM パスワードポリシーの 定義」を参照してください。
7.2. IdM stage ユーザーアカウントの自動アクティベーションの設定
この手順では、stage ユーザーをアクティベートするスクリプトを作成する方法を説明します。システムは、指定した間隔でスクリプトを自動的に実行します。これにより、新規ユーザーアカウントが自動的にアクティベートされ、作成直後に使用することができます。
この手順では、外部プロビジョニングシステムの所有者がユーザーをすでに検証し、スクリプトが IdM に追加する前に IdM 側で追加の検証を必要としていないことを前提としています。
IdM サーバーの 1 つでのみアクティベーションプロセスを有効にするだけで 十 分です。
前提条件
- provisionator アカウントおよび activator アカウントが IdM に存在している。詳細は「ステージユーザーアカウントの自動アクティベーション用の IdM アカウントの準備」を参照してください。
- 手順を実行している IdM サーバーに root 権限がある。
- IdM 管理者としてログインしている。
- 外部プロビジョニングシステムを信頼している。
手順
アカウントのアクティベーション用に keytab ファイルを生成します。
# ipa-getkeytab -s server.idm.example.com -p "activator" -k /etc/krb5.ipa-activation.keytab
複数の IdM サーバーでアクティベーションプロセスを有効にする場合は、1 つのサーバーで keytab ファイルのみを生成します。次に、キータブファイルを他のサーバーにコピーします。
以下の内容を含む
/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
ipa-activate-all
スクリプトのパーミッションおよび所有権を編集して、実行可能なファイルに変更します。# chmod 755 /usr/local/sbin/ipa-activate-all # chown root:root /usr/local/sbin/ipa-activate-all
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
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
新しい設定を再読み込みします。
# systemctl daemon-reload
ipa-activate-all.timer
を有効にします。# systemctl enable ipa-activate-all.timer
ipa-activate-all.timer
を起動します。# systemctl start ipa-activate-all.timer
(必要に応じて)
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.
7.3. LDIF ファイルで定義されている IdM stage ユーザーの追加
本セクションでは、外部プロビジョニングシステムの管理者が IdM LDAP にアクセスし、LDIF ファイルを使用して stage ユーザーを追加する方法を説明します。以下の例では、1 人のユーザーの追加を示していますが、複数のユーザーが一括モードで 1 つのファイルに追加できます。
前提条件
- IdM 管理者が、provisionator アカウントとパスワードを作成している。詳細は「ステージユーザーアカウントの自動アクティベーション用の IdM アカウントの準備」を参照してください。
- 外部管理者は provisionator アカウントのパスワードを知っている。
- LDAP サーバーから IdM サーバーに SSH 接続できる。
IdM stage ユーザーがユーザーライフサイクルの正しい処理を許可する必要がある属性の最小セットを提供できます。つまり、以下のようになります。
-
識別名
(dn) -
共通名
(cn) -
名字
(sn) -
uid
-
手順
外部サーバーで、新規ユーザーに関する情報が含まれる 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
外部サーバーから IdM サーバーへの LDIF ファイルを転送します。
$ scp add-stageidmuser.ldif provisionator@server.idm.example.com:/provisionator/ Password: add-stageidmuser.ldif 100% 364 217.6KB/s 00:00
SSH
プロトコルを使用して、provisionator として IdM サーバーに接続します。$ ssh provisionator@server.idm.example.com Password: [provisionator@server ~]$
IdM サーバーで、provisionator アカウントの Kerberos チケット保証チケット (TGT) を取得します。
[provisionator@server ~]$ kinit provisionator
-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"
7.4. ldapmodify を使用して CLI から IdM stage ユーザーを直接追加
本セクションでは、外部プロビジョニングシステムの管理者が Identity Management (IdM) LDAP にアクセスし、ldapmodify
ユーティリティーを使用して stage ユーザーを追加する方法を説明します。
前提条件
- IdM 管理者が、provisionator アカウントおよびパスワードを作成している。詳細は「ステージユーザーアカウントの自動アクティベーション用の IdM アカウントの準備」を参照してください。
- 外部管理者は provisionator アカウントのパスワードを知っている。
- LDAP サーバーから IdM サーバーに SSH 接続できる。
IdM stage ユーザーがユーザーライフサイクルの正しい処理を許可する必要がある属性の最小セットを提供できます。つまり、以下のようになります。
-
識別名
(dn) -
共通名
(cn) -
名字
(sn) -
uid
-
手順
IdM の ID および認証情報を使用して、
SSH
プロトコルを使用して IdM サーバーに接続します。$ ssh provisionator@server.idm.example.com Password: [provisionator@server ~]$
新規 stage ユーザーを追加するロールを持つ IdM ユーザーである provisionator アカウントの TGT を取得します。
$ kinit provisionator
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.
追加するユーザーの
dn
を入力します。dn: uid=stageuser,cn=staged users,cn=accounts,cn=provisioning,dc=idm,dc=example,dc=com
実行している変更のタイプとして add を入力します。
changetype: add
ユーザーのライフサイクルの正しい処理を許可するのに必要な LDAP オブジェクトクラスのカテゴリーを指定します。
objectClass: top objectClass: inetorgperson
追加のオブジェクトクラスを指定できます。
ユーザーの
uid
を入力します。uid: stageuser
ユーザーの
cn
を入力します。cn: Babs Jensen
ユーザーの名字を入力します。
sn: Jensen
Enter
を再度押して、これがエントリーの最後であることを確認します。[Enter] adding new entry "uid=stageuser,cn=staged users,cn=accounts,cn=provisioning,dc=idm,dc=example,dc=com"
- Ctrl + C を使用して接続を終了します。
検証手順
stage エントリーの内容を確認し、必要な POSIX 属性をプロビジョニングシステムがすべて追加し、ステージエントリーをアクティベートする準備ができていることを確認します。
新規 stage ユーザーの LDAP 属性を表示するには、
ipa stageuser-show --all --raw
コマンドを実行します。$ ipa stageuser-show stageuser --all --raw dn: uid=stageuser,cn=staged users,cn=accounts,cn=provisioning,dc=idm,dc=example,dc=com uid: stageuser sn: Jensen cn: Babs Jensen has_password: FALSE has_keytab: FALSE nsaccountlock: TRUE objectClass: top objectClass: inetorgperson objectClass: organizationalPerson objectClass: person
-
ユーザーは、
nsaccountlock
属性により明示的に無効になっていることに注意してください。
-
ユーザーは、
7.5. 関連情報
- 「 ldapmodify を使用した IdM ユーザーの外部管理 」を参照してください。
第8章 CLI を使用した IdM でのセルフサービスルールの管理
本章では、Identity Management (IdM) のセルフサービスルールを紹介し、コマンドラインインターフェース (CLI) でセルフサービスアクセスルールを作成および編集する方法を説明します。
8.1. IdM でのセルフサービスアクセス制御
セルフサービスのアクセス制御ルールは、Identity Management (IdM) エンティティーが IdM Directory Server エントリーで実行できる操作を定義します (例: IdM ユーザーが独自のパスワードを更新できるなど)。
この制御方法では、認証された IdM エンティティーがその LDAP エントリー内の特定の属性を編集できますが、エントリー全体での 追加
や 削除
の操作は許可されません。
セルフサービスのアクセス制御規則を使用する場合は注意が必要です。アクセス制御ルールを誤って構成すると、エンティティーの特権が誤って昇格する可能性があります。
8.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
8.3. CLI を使用したセルフサービスルールの編集
この手順では、コマンドラインインターフェース (CLI) を使用して IdM のセルフサービスアクセスルールを編集する方法を説明します。
前提条件
- IdM または ユーザー管理者 ロールを管理する管理者権限。
- アクティブな Kerberos チケット。詳細は、Using kinit to log in to IdM manually を参照してください。
手順
-
オプション:
ipa selfservice-find
コマンドを使用して、既存のセルフサービスルールを表示します。 -
オプション:
ipa selfservice-show
コマンドを使用して、変更するセルフサービスルールの詳細を表示します。 -
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
8.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
コマンドを使用して、すべてのセルフサービスルールを表示します。削除したばかりのルールがなくなっているはずです。
第9章 IdM Web UI を使用したセルフサービスルールの管理
本章では、Identity Management (IdM) のセルフサービスルールを紹介し、Web インターフェース (IdM Web UI) でセルフサービスアクセスルールを作成および編集する方法を説明します。
9.1. IdM でのセルフサービスアクセス制御
セルフサービスのアクセス制御ルールは、Identity Management (IdM) エンティティーが IdM Directory Server エントリーで実行できる操作を定義します (例: IdM ユーザーが独自のパスワードを更新できるなど)。
この制御方法では、認証された IdM エンティティーがその LDAP エントリー内の特定の属性を編集できますが、エントリー全体での 追加
や 削除
の操作は許可されません。
セルフサービスのアクセス制御規則を使用する場合は注意が必要です。アクセス制御ルールを誤って構成すると、エンティティーの特権が誤って昇格する可能性があります。
9.2. IdM Web UI を使用したセルフサービスルールの作成
この手順では、Web インターフェース(IdM Web UI)を使用して IdM にセルフサービスアクセスルールを作成する方法を説明します。
前提条件
- IdM または ユーザー管理者 ロールを管理する管理者権限。
- IdM Web UI にログインしている。詳細は「Web ブラウザーで IdM Web UI へのアクセス」を 参照してください。
手順
- IPA Server タブで Role-Based Access Control サブメニューを開き、Self Service Permissions を選択します。
セルフサービスアクセスルールの一覧の右上にある Add をクリックします。
Add Self Service Permission ウィンドウが開きます。Self-service name フィールドに新しいセルフサービスルールの名前を入力します。空白を使用できます。
- ユーザーが編集できるようにする属性の横にあるチェックボックスを選択します。
必要に応じて アクセスを提供する属性が一覧にない場合は、その一覧を追加できます。
- Add ボタンをクリックします。
- 以下の Add Custom Attribute ウィンドウの Attribute テキストフィールドに属性名を入力します。
- OK ボタンをクリックして属性を追加します。
- 新しい属性が選択されていることを確認します。
-
フォームの下部にある Add ボタンをクリックして、新しいセルフサービスルールを保存します。
または、Add and Edit ボタンをクリックしてセルフサービスルールを編集するか、Add and Add another ボタンをクリックしてさらにルールを保存および追加できます。
9.3. IdM Web UI を使用したセルフサービスルールの編集
この手順では、Web インターフェース (IdM Web UI) を使用して IdM にセルフサービスアクセスルールを編集する方法を説明します。
前提条件
- IdM または ユーザー管理者 ロールを管理する管理者権限。
- IdM Web UI にログインしている。詳細は「Web ブラウザーで IdM Web UI へのアクセス」を 参照してください。
手順
- IPA Server タブで Role-Based Access Control サブメニューを開き、Self Service Permissions を選択します。
変更するセルフサービスルールの名前をクリックします。
- 編集ページでは、セルフサービスルールに追加または削除する属性の一覧のみを編集できます。適切なチェックボックスを選択または選択解除します。
- Save ボタンをクリックして、セルフサービスルールへの変更を保存します。
9.4. IdM Web UI を使用したセルフサービスルールの削除
この手順では、Web インターフェース (IdM Web UI) を使用して IdM にセルフサービスアクセスルールを削除する方法を説明します。
前提条件
- IdM または ユーザー管理者 ロールを管理する管理者権限。
- IdM Web UI にログインしている。詳細は「Web ブラウザーで IdM Web UI へのアクセス」を 参照してください。
手順
- IPA Server タブで Role-Based Access Control サブメニューを開き、Self Service Permissions を選択します。
削除するルールの横にあるチェックボックスを選択し、一覧の右側にある Delete ボタンをクリックします。
- ダイアログが開き、Delete をクリックして確認します。
第10章 Ansible Playbook を使用した IdM でのセルフサービスルールの管理
本セクションでは、Identity Management (IdM) のセルフサービスルールを紹介し、Ansible Playbook を使用してセルフサービスアクセスルールを作成および編集する方法を説明します。セルフサービスのアクセス制御ルールにより、IdM エンティティーは IdM Directory Server エントリーで指定の操作を実行できます。
本セクションでは、以下のトピックについて説明します。
10.1. IdM でのセルフサービスアクセス制御
セルフサービスのアクセス制御ルールは、Identity Management (IdM) エンティティーが IdM Directory Server エントリーで実行できる操作を定義します (例: IdM ユーザーが独自のパスワードを更新できるなど)。
この制御方法では、認証された IdM エンティティーがその LDAP エントリー内の特定の属性を編集できますが、エントリー全体での 追加
や 削除
の操作は許可されません。
セルフサービスのアクセス制御規則を使用する場合は注意が必要です。アクセス制御ルールを誤って構成すると、エンティティーの特権が誤って昇格する可能性があります。
10.2. Ansible を使用してセルフサービスルールを存在させる手順
以下の手順では、Ansible Playbook を使用してセルフサービスルールを定義し、Identity Management (IdM) サーバーに存在させる方法を説明します。この例では、ユーザーが自分の名前の情報を管理できる 新しいルールでは、ユーザーに、自分の givenname
、displayname
、title
、および initials
属性を変更できるよ権限を付与します。たとえば、表示名や初期などを変更することができます。
前提条件
- IdM 管理者パスワードを把握している。
以下の要件を満たす Ansible コントロールノードを設定している。
- Ansible バージョン 2.8 以降を使用している。
- Ansible コントローラーに ansible-freeipa パッケージがインストールされている。
- ~/MyPlaybooks/ ディレクトリーに、このオプションを設定する IdM サーバーの完全修飾ドメイン名 (FQDN) で Ansible インベントリーファイル を作成している。
手順
~/ MyPlaybooks/ ディレクトリーに移動します。
$ cd ~/MyPlaybooks/
/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
-
Ansible Playbook ファイル (
selfservice-present-copy.yml
) を開きます。 ipaselfservice
タスクセクションに以下の変数を設定してファイルを調整します。-
ipaadmin_password
変数は IdM 管理者のパスワードに設定します。 -
name
変数は、新しいセルフサービスルールの名前に設定します。 -
permission
変数は、付与するパーミッションをコンマ区切りの一覧(read
およびwrite
)で設定します。 -
attribute
変数は、ユーザーが管理できる属性 (givenname
、displayname
、title
、および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
-
- ファイルを保存します。
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
ディレクトリーを参照してください。
10.3. Ansible を使用してセルフサービスルールがないことを確認する手順
以下の手順では、Ansible Playbook を使用して、指定したセルフサービスルールが IdM 設定に存在しないことを確認する方法を説明します。以下の例では、ユーザーが自分の名前の詳細 のセルフサービスルールが IdM に存在しないことを確認する方法を説明します。これにより、ユーザーは自分の表示名や初期などを変更できないようにします。
前提条件
- IdM 管理者パスワードを把握している。
以下の要件を満たす Ansible コントロールノードを設定している。
- Ansible バージョン 2.8 以降を使用している。
- Ansible コントローラーに ansible-freeipa パッケージがインストールされている。
- ~/MyPlaybooks/ ディレクトリーに、このオプションを設定する IdM サーバーの完全修飾ドメイン名 (FQDN) で Ansible インベントリーファイル を作成している。
手順
~/ MyPlaybooks/ ディレクトリーに移動します。
$ cd ~/MyPlaybooks/
/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
-
Ansible Playbook ファイル (
selfservice-absent-copy.yml
) を開きます。 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
-
- ファイルを保存します。
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 を参照してください。
10.4. Ansible を使用してセルフサービスルールに固有の属性を含める手順
以下の手順では、Ansible Playbook を使用して、既存のセルフサービスルールに特定の設定を追加する方法を説明します。この例では、ユーザーは自分の名前詳細を管理できる のセルフサービスルールに、surname
のメンバー属性が含まれるようにします。
前提条件
- IdM 管理者パスワードを把握している。
以下の要件を満たす Ansible コントロールノードを設定している。
- Ansible バージョン 2.8 以降を使用している。
- Ansible コントローラーに ansible-freeipa パッケージがインストールされている。
- ~/MyPlaybooks/ ディレクトリーに、このオプションを設定する IdM サーバーの完全修飾ドメイン名 (FQDN) で Ansible インベントリーファイル を作成している。
- ユーザーが独自の名前の詳細 セルフサービスルールが IdM に存在する。
手順
~/ MyPlaybooks/ ディレクトリーに移動します。
$ cd ~/MyPlaybooks/
/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
-
Ansible Playbook ファイル (
selfservice-member-present-copy.yml
) を開きます。 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
-
- ファイルを保存します。
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 を参照してください。
10.5. Ansible を使用してセルフサービスルールに固有の属性を含めいないようにする手順
以下の手順では、Ansible Playbook を使用して、セルフサービスルールに特定の設定が割り当てられないようにする方法を説明します。この Playbook を使用して、セルフサービスルールで不必要なアクセス権限を付与しないようにします。この例では、ユーザーが独自の名前の詳細を管理できる セルフサービスルールに givenname
と surname
のメンバー属性が含まれないようにします。
前提条件
- IdM 管理者パスワードを把握している。
以下の要件を満たす Ansible コントロールノードを設定している。
- Ansible バージョン 2.8 以降を使用している。
- Ansible コントローラーに ansible-freeipa パッケージがインストールされている。
- ~/MyPlaybooks/ ディレクトリーに、このオプションを設定する IdM サーバーの完全修飾ドメイン名 (FQDN) で Ansible インベントリーファイル を作成している。
- ユーザーが独自の名前の詳細 セルフサービスルールが IdM に存在する。
手順
~/ MyPlaybooks/ ディレクトリーに移動します。
$ cd ~/MyPlaybooks/
/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
-
Ansible Playbook ファイル (
selfservice-member-absent-copy.yml
) を開きます。 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
-
- ファイルを保存します。
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 を参照してください。
第11章 IdM CLI でのユーザーグループの管理
本章では、IdM CLI を使用したユーザーグループ管理について説明します。
ユーザーグループは、共通の特権、パスワードポリシーなどの持つユーザーのセットです。
Identity Management (IdM) のユーザーグループには以下が含まれます。
- IdM ユーザー
- 他の IdM ユーザーグループ
- 外部ユーザー (IdM の外部に存在するユーザー)
11.1. IdM のさまざまなグループタイプ
IdM は、以下のタイプのグループをサポートします。
- POSIX グループ (デフォルト)
POSIX グループは、メンバーの Linux POSIX 属性に対応します。Active Directory と対話するグループは POSIX 属性を使用できないことに注意してください。
POSIX 属性は、ユーザーを個別のエンティティーとして識別します。ユーザーに関連する POSIX 属性の例には、
uidNumber
(ユーザー番号 (UID))、およびgidNumber
(グループ番号 (GID)) が含まれます。- 非 POSIX グループ
非 POSIX グループは、POSIX 属性に対応していません。たとえば、これらのグループには GID が定義されていません。
このタイプのグループのすべてのメンバーは、IdM ドメインに属している必要があります。
- 外部グループ
外部グループを使用して、以下のような IdM ドメイン外の ID ストアに存在するグループメンバーを追加できます。
- ローカルシステム
- Active Directory ドメイン
- ディレクトリーサービス
外部グループは、POSIX 属性に対応していません。たとえば、これらのグループには GID が定義されていません。
表11.1 デフォルトで作成されたユーザーグループ
グループ名 | デフォルトのグループメンバー |
---|---|
| すべての IdM ユーザー |
|
管理権限を持つユーザー (デフォルトの |
| これは、特別な権限がなくなったレガシーグループです |
| Active Directory 信頼を管理する権限を持つユーザー |
ユーザーをユーザーグループに追加すると、ユーザーはグループに関連付けられた権限とポリシーを取得します。たとえば、ユーザーに管理権限を付与するには、ユーザーを admins
グループに追加します。
admins
グループを削除しないでください。admins
は IdM で必要な事前定義グループであるため、この操作により特定のコマンドで問題が生じます。
さらに、IdM で新しいユーザーが作成されるたびに、IdM は、デフォルトで ユーザーのプライベートグループ を作成します。プライベートグループの詳細は、「プライベートグループの ないユーザーの追加」を 参照してください。
11.2. 直接および間接のグループメンバー
IdM のユーザーグループ属性は、直接メンバーと間接メンバーの両方に適用されます。グループ B がグループ A のメンバーである場合、グループ B のすべてのユーザーはグループ A の間接メンバーと見なされます。
たとえば、以下の図では、以下のようになります。
- ユーザー 1 とユーザー 2 は、グループ A の 直接メンバー です。
- ユーザー 3、ユーザー 4、およびユーザー 5 は、グループ A の 間接メンバー です。
図11.1 直接および間接グループメンバーシップ

ユーザーグループ A にパスワードポリシーを設定すると、そのポリシーはユーザーグループ B のすべてのユーザーにも適用されます。
11.3. IdM CLI を使用したユーザーグループの追加
本セクションでは、IdM CLI を使用してユーザーグループを追加する方法を説明します。
前提条件
- 管理者としてログインしている必要があります。詳細は、Using kinit to log in to IdM manually を参照してください。
手順
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 グループのメンバーシップは、ローカルユーザーでは機能しません。
11.4. IdM CLI を使用したユーザーグループの検索
本セクションでは、IdM CLI を使用して既存のユーザーグループを検索する方法を説明します。
手順
ipa group-find
コマンドを使用して、すべてのユーザーグループを表示します。グループタイプを指定するには、ipa group-find
にオプションを追加します。-
ipa group-find --posix
コマンドを使用して、すべての POSIX グループを表示します。 -
ipa group-find --nonposix
コマンドを使用して、すべての非 POSIX グループを表示します。 ipa group-find --external
コマンドを使用して、すべての外部グループを表示します。異なるグループタイプの詳細は、IdM のさまざまなグループタイプ を参照してください。
-
11.5. IdM CLI を使用したユーザーグループの削除
本セクションでは、IdM CLI を使用してユーザーグループを削除する方法を説明します。グループを削除しても、IdM からグループメンバーは削除されないことに注意してください。
前提条件
- 管理者としてログインしている必要があります。詳細は、Using kinit to log in to IdM manually を参照してください。
手順
ipa group-del group_name
コマンドを使用してユーザーグループを削除します。たとえば、group_aを削除するには、次のコマンドを実行します。$ ipa group-del group_a -------------------------- Deleted group "group_a" --------------------------
11.6. IdM CLI でユーザーグループにメンバーの追加
本セクションでは、IdM CLI を使用してユーザーグループにメンバーを追加する方法を説明します。ユーザーおよびユーザーグループの両方をユーザーグループのメンバーとして追加できます。詳細は、IdM のさまざまなグループタイプ および 直接および間接のグループメンバー を参照してください。
前提条件
- 管理者としてログインしている必要があります。詳細は、Using kinit to log in to IdM manually を参照してください。
手順
ipa group-add-member
コマンドを使用して、ユーザーグループにメンバーを追加します。次のオプションを使用して、メンバーのタイプを指定します。
-
--users
は、IdM ユーザーを追加します -
--external
は、DOMAIN\user_name
形式またはuser_name@domain
形式で、IdM ドメイン外に存在するユーザーを追加します -
--groups
は、IdM ユーザーグループを追加します。
たとえば、group_b を group_a のメンバーとして追加するには、次のコマンドを実行します。
$ ipa group-add-member group_a --groups=group_b Group name: group_a GID: 1133400009 Member users: user_a Member groups: group_b Indirect Member users: user_b ------------------------- Number of members added 1 -------------------------
group_b のメンバーは、group_a の間接メンバーになりました。
-
グループを別のグループのメンバーとして追加する場合は、再帰グループを作成しないでください。たとえば、グループ A がグループ B のメンバーである場合は、グループ B をグループ A のメンバーとして追加しないでください。再帰的なグループにより予期しない動作が発生する可能性があります。
ユーザーグループにメンバーを追加した後、更新が Identity Management 環境のすべてのクライアントに広がるまでに時間がかかる場合があります。これは、特定のホストがユーザー、グループ、およびネットグループを解決するときに、System Security Services Daemon
(SSSD) が最初にキャッシュを調べて、サーバーで不足または期限切れのレコードのみを検索するためです。
11.7. ユーザープライベートグループなしでユーザーの追加
デフォルトでは、IdM で新しいユーザーが作成されるたびに、IdM がユーザーのプライベートグループ (UPG) を作成します。UPG は特定のグループタイプです。
- UPG の名前は、新しく作成されたユーザーと同じです。
- ユーザーは UPG の唯一のメンバーです。UPG には他のメンバーを含めることができません。
- プライベートグループの GID は、ユーザーの UID と一致します。
ただし、UPG を作成せずにユーザーを追加することは可能です。
11.7.1. ユーザープライベートグループのないユーザー
NIS グループまたは別のシステムグループが、ユーザープライベートグループに割り当てられる GID を既に使用している場合は、UPG を作成しないようにする必要があります。
これは、以下の 2 つの方法で実行できます。
- プライベートグループをグローバルに無効にすることなく、UPG なしで新しいユーザーを追加する。「プライベートグループがグローバルに有効になっている場合にユーザープライベートグループのないユーザーを追加」を参照してください。
- すべてのユーザーに対して UPG をグローバルに無効にしてから、新しいユーザーを追加する。「すべてのユーザーに対してユーザープライベートグループをグローバルで無効にする」および「ユーザープライベートグループをグローバルで無効にしている時のユーザーの追加」を参照してください。
どちらの場合も、IdM では、新しいユーザーを追加するときに GID を指定する必要があります。指定しないと、操作は失敗します。これは、IdM には新しいユーザーの GID が必要ですが、デフォルトのユーザーグループ ipausers
は非 POSIX グループであるため、関連付けられた GID がないためです。指定する GID は、既存のグループに対応する必要がありません。
GID を指定しても、新しいグループは作成されません。この属性は IdM に必要であるため、新しいユーザーに GID 属性のみを設定します。
11.7.2. プライベートグループがグローバルに有効になっている場合にユーザープライベートグループのないユーザーを追加
システムで UPG が有効になっている場合でも、ユーザープライベートグループ (UPG) を作成せずにユーザーを追加できます。これには、新しいユーザーの GID を手動で設定する必要があります。これが必要な理由の詳細については、ユーザープライベートグループのないユーザー を参照してください。
手順
IdM が UPG を作成しないようにするには、
ipa user-add
コマンドに--noprivate
オプションを追加します。コマンドを成功させるには、カスタム GID を指定する必要があることに注意してください。たとえば、GID 10000 の新しいユーザーを追加するには、次のコマンドを実行します。
$ ipa user-add jsmith --first=John --last=Smith --noprivate --gid 10000
11.7.3. すべてのユーザーに対してユーザープライベートグループをグローバルに無効にする
ユーザープライベートグループ (UPG) をグローバルに無効にできます。これにより、すべての新しいユーザーの UPG が作成されなくなります。既存のユーザーはこの変更の影響を受けません。
手順
管理者権限を取得します。
$ kinit admin
IdM は、Directory Server Managed Entries プラグインを使用してUPG を管理します。プラグインのインスタンスを一覧表示します。
$ ipa-managed-entries --list
IdM が UPG を作成しないようにするには、ユーザープライベートグループを管理するプラグインインスタンスを無効にします。
$ ipa-managed-entries -e "UPG Definition" disable Disabling Plugin
注記後で
UPG 定義
インスタンスを再有効にするには、ipa-managed-entries -e "UPG Definition" enable
コマンドを使用します。Directory Server を再起動して、新しい構成を読み込みます。
$ sudo systemctl restart dirsrv.target
UPG が無効になった後にユーザーを追加するには、GID を指定する必要があります。詳細は、「ユーザープライベートグループがグローバルで無効になっている場合のユーザーの追加」を参照してください。
検証手順
UPG がグローバルで無効になっているかどうかを確認するには、再度 disable コマンドを使用します。
$ ipa-managed-entries -e "UPG Definition" disable Plugin already disabled
11.7.4. ユーザープライベートグループがグローバルで無効になっている場合のユーザーの追加
ユーザープライベートグループ (UPG) がグローバルで無効になっている場合、IdM は GID を新しいユーザーに自動的に割り当てません。ユーザーを正常に追加するには、GID を手動で割り当てるか、automember を使用して割り当てる必要があります。これが必要な理由の詳細については、Users without a user private group を参照してください。
前提条件
- UPG は、すべてのユーザーに対してグローバルに無効にする必要があります。詳細は、「すべてのユーザーに対してユーザープライベートグループをグローバルに無効にする」をご覧ください。
手順
UPG の作成が無効になっているときに新しいユーザーの追加が成功することを確認するには、次のいずれかを選択します。
新しいユーザーを追加するときにカスタムの GID を指定します。GID は、既存のユーザーグループに対応する必要はありません。
たとえば、コマンドラインからユーザーを追加する場合は、
--gid
オプションをipa user-add
コマンドに追加します。- automember ルールを使用して、GID のある既存のグループにユーザーを追加します。
11.8. IdM CLI を使用して IdM ユーザーグループにメンバーマネージャーとしてユーザーまたはグループを追加する手順
本セクションでは、IdM CLI を使用して、ユーザーまたはグループをメンバーマネージャーとして IdM ユーザーグループに追加する方法を説明します。メンバーマネージャーは、ユーザーまたはグループを IdM ユーザーグループに追加できますが、グループの属性を変更できません。
前提条件
- 管理者としてログインしている必要があります。詳細は、Using kinit to log in to IdM manually を参照してください。
- メンバーマネージャーとして追加するユーザーまたはグループの名前と、メンバーマネージャーが管理するグループ名を用意する。
手順
ipa group-add-member-manager
コマンドを使用して、ユーザーをメンバーマネージャーとして IdM ユーザーグループに追加します。たとえば、ユーザー
test
をgroup_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 -------------------------
ユーザー
test
はgroup_a
のメンバーを管理できるようになりました。ipa group-add-member-manager
コマンドを使用して、グループをメンバーマネージャーとして IdM ユーザーグループに追加します。たとえば、 グループ
group_admins
をgroup_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_admins
はgroup_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
を参照してください。
11.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 インターフェースには表示されません。
11.10. IdM CLI を使用してユーザーグループからメンバーを削除
本セクションでは、IdM CLI を使用してユーザーグループからメンバーを削除する方法を説明します。
前提条件
- 管理者としてログインしている必要があります。詳細は、Using kinit to log in to IdM manually を参照してください。
手順
-
オプション。
ipa group-show
コマンドを使用して、削除するメンバーがグループに含まれていることを確認します。 ipa group-remove-member
コマンドを使用して、ユーザーグループからメンバーを削除します。以下のオプションを使用して、削除するメンバーを指定します。
-
--users
は、IdM ユーザーを削除します -
--external
は、DOMAIN\user_name
またはuser_name@domain
の形式で、IdM ドメイン外に存在するユーザーを削除します -
--groups
は、IdM ユーザーグループを削除します
たとえば、group_name という名前のグループから、user1、user2、および group1 を削除するには、次のコマンドを実行します。
$ ipa group-remove-member group_name --users=user1 --users=user2 --groups=group1
-
11.11. IdM CLI を使用してユーザーまたはグループを IdM ユーザーグループのメンバーマネージャーから取り消す手順
本セクションでは、IdM CLI を使用して、IdM ユーザーグループのメンバーマネージャーからユーザーまたはグループを取り消す方法を説明します。メンバーマネージャーは、IdM ユーザーグループからユーザーまたはグループを削除できますが、グループの属性を変更できません。
前提条件
- 管理者としてログインしている必要があります。詳細は、Using kinit to log in to IdM manually を参照してください。
- 削除する既存のメンバーマネージャーのユーザーまたはグループの名前と、そのメンバーマネージャーが管理するグループ名が必要です。
手順
ipa group-remove-member-manager
コマンドを使用してユーザーを IdM ユーザーグループのメンバーマネージャーから削除します。たとえば、ユーザー
test
をgroup_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 ---------------------------
ユーザー
test
はgroup_a
のメンバーを管理できなくなりました。ipa group-remove-member-manager
コマンドを使用してグループを IdM ユーザーグループのメンバーマネージャーから削除します。たとえば、 グループ
group_admins
をgroup_a
のメンバーマネージャーから削除します。$ ipa group-remove-member-manager group_a --groups=group_admins Group name: group_a GID: 1133400009 --------------------------- Number of members removed 1 ---------------------------
グループ
group_admins
はgroup_a
のメンバーを管理できなくなりました。
ユーザーグループからメンバーマネージャーを削除してから、更新が Identity Management 環境のすべてのクライアントに広がるまでに時間がかかる場合があります。
検証手順
ipa group-show
コマンドを使用して、ユーザーおよびグループがメンバーマネージャーから削除されたことを確認します。$ ipa group-show group_a Group name: group_a GID: 1133400009
関連情報
-
詳細は、
ipa group-remove-member-manager --help
を参照してください。
第12章 IdM Weg UI でのユーザーグループの管理
本章では、IdM Web UI を使用したユーザーグループ管理を説明します。
ユーザーグループは、共通の特権、パスワードポリシーなどの持つユーザーのセットです。
Identity Management (IdM) のユーザーグループには以下が含まれます。
- IdM ユーザー
- 他の IdM ユーザーグループ
- 外部ユーザー (IdM の外部に存在するユーザー)
12.1. IdM のさまざまなグループタイプ
IdM は、以下のタイプのグループをサポートします。
- POSIX グループ (デフォルト)
POSIX グループは、メンバーの Linux POSIX 属性に対応します。Active Directory と対話するグループは POSIX 属性を使用できないことに注意してください。
POSIX 属性は、ユーザーを個別のエンティティーとして識別します。ユーザーに関連する POSIX 属性の例には、
uidNumber
(ユーザー番号 (UID))、およびgidNumber
(グループ番号 (GID)) が含まれます。- 非 POSIX グループ
非 POSIX グループは、POSIX 属性に対応していません。たとえば、これらのグループには GID が定義されていません。
このタイプのグループのすべてのメンバーは、IdM ドメインに属している必要があります。
- 外部グループ
外部グループを使用して、以下のような IdM ドメイン外の ID ストアに存在するグループメンバーを追加できます。
- ローカルシステム
- Active Directory ドメイン
- ディレクトリーサービス
外部グループは、POSIX 属性に対応していません。たとえば、これらのグループには GID が定義されていません。
表12.1 デフォルトで作成されたユーザーグループ
グループ名 | デフォルトのグループメンバー |
---|---|
| すべての IdM ユーザー |
|
管理権限を持つユーザー (デフォルトの |
| これは、特別な権限がなくなったレガシーグループです |
| Active Directory 信頼を管理する権限を持つユーザー |
ユーザーをユーザーグループに追加すると、ユーザーはグループに関連付けられた権限とポリシーを取得します。たとえば、ユーザーに管理権限を付与するには、ユーザーを admins
グループに追加します。
admins
グループを削除しないでください。admins
は IdM で必要な事前定義グループであるため、この操作により特定のコマンドで問題が生じます。
さらに、IdM で新しいユーザーが作成されるたびに、IdM は、デフォルトで ユーザーのプライベートグループ を作成します。プライベートグループの詳細は、「プライベートグループの ないユーザーの追加」を 参照してください。
12.2. 直接および間接のグループメンバー
IdM のユーザーグループ属性は、直接メンバーと間接メンバーの両方に適用されます。グループ B がグループ A のメンバーである場合、グループ B のすべてのユーザーはグループ A の間接メンバーと見なされます。
たとえば、以下の図では、以下のようになります。
- ユーザー 1 とユーザー 2 は、グループ A の 直接メンバー です。
- ユーザー 3、ユーザー 4、およびユーザー 5 は、グループ A の 間接メンバー です。
図12.1 直接および間接グループメンバーシップ

ユーザーグループ A にパスワードポリシーを設定すると、そのポリシーはユーザーグループ B のすべてのユーザーにも適用されます。
12.3. IdM Web UI を使用したユーザーグループの追加
本セクションでは、IdM Web UI を使用してユーザーグループを追加する方法を説明します。
前提条件
- IdM Web UI にログインしている。
手順
- Identity → Groups の順にクリックし、左のサイドバーで User Groups を選択します。
- Add をクリックして、グループを追加します。
グループの情報を入力します。ユーザーグループタイプの詳細は、IdM のさまざまなグループタイプ を参照してください。
グループのカスタム GID を指定できます。これを行う場合は、ID の競合を避けるように注意してください。カスタム GID を指定しない場合、IdM は使用可能な ID 範囲から GID を自動的に割り当てます。
- Add をクリックして確定します。
12.4. IdM Web UI を使用したユーザーグループの削除
本セクションでは、IdM Web UI を使用してユーザーグループを削除する方法を説明します。グループを削除しても、IdM からグループメンバーは削除されないことに注意してください。
前提条件
- IdM Web UI にログインしている。
手順
- Identity → Groups の順にクリックし、User Groups を選択します。
- 削除するグループを選択します。
- Delete をクリックします。
- Delete をクリックして確定します。
12.5. IdM Web UI でユーザーグループにメンバーの追加
ユーザーおよびユーザーグループの両方をユーザーグループのメンバーとして追加できます。詳細は、IdM のさまざまなグループタイプ および 直接および間接のグループメンバー を参照してください。
前提条件
- IdM Web UI にログインしている。
手順
- Identity → Groups の順にクリックし、左のサイドバーで User Groups を選択します。
- グループ名をクリックします。
追加するグループメンバーのタイプ (Users, User Groups, または External) を選択します。
- Add をクリックします。
- 追加するメンバーの横にあるチェックボックスを 1 つ以上選択します。
右矢印をクリックして、選択したメンバーをグループに移動します。
- Add をクリックして確定します。
12.6. Web UI を使用して IdM ユーザーグループにメンバーマネージャーとしてユーザーまたはグループを追加する手順
本セクションでは、Web UI を使用して、ユーザーまたはグループをメンバーマネージャーとして IdM ユーザーグループに追加する方法を説明します。メンバーマネージャーは、ユーザーまたはグループを IdM ユーザーグループに追加できますが、グループの属性を変更できません。
前提条件
- IdM Web UI にログインしている。
- メンバーマネージャーとして追加するユーザーまたはグループの名前と、メンバーマネージャーが管理するグループ名を用意する。
手順
- Identity → Groups の順にクリックし、左のサイドバーで User Groups を選択します。
- グループ名をクリックします。
追加するグループメンバーマネージャーのタイプ (Users または User Groups) を選択します。
- Add をクリックします。
- 追加するメンバーの横にあるチェックボックスを 1 つ以上選択します。
右矢印をクリックして、選択したメンバーをグループに移動します。
- Add をクリックして確定します。
ユーザーグループにメンバーマネージャーを追加してから、更新が Identity Management 環境のすべてのクライアントに広がるまでに時間がかかる場合があります。
検証手順
新たに追加したユーザーまたはユーザーグループが、ユーザーまたはユーザーグループのメンバーマネージャーの一覧に追加されていることを確認します。
関連情報
-
詳細は、
ipa group-add-member-manager --help
を参照してください。
12.7. IdM Web UI を使用したグループメンバーの表示
本セクションでは、IdM Web UI を使用してグループのメンバーを表示する方法を説明します。直接グループメンバーと間接グループメンバーの両方を表示できます。詳細は、「直接および間接のグループメンバー」を参照してください。
前提条件
- IdM Web UI にログインしている。
手順
- Identity → Groupsを選択します。
- 左のサイドバーで User Groups を選択します。
- 表示するグループの名前をクリックします。
直接メンバーシップ と 間接メンバーシップ を切り替えます。
12.8. IdM Web UI を使用してユーザーグループからメンバーの削除
本セクションでは、IdM Web UI を使用してユーザーグループからメンバーを削除する方法を説明します。
前提条件
- IdM Web UI にログインしている。
手順
- Identity → Groups の順にクリックし、左のサイドバーで User Groups を選択します。
- グループ名をクリックします。
削除するグループメンバーのタイプ (Users, User Groups、または External) を選択します。
- 削除するメンバーの横にあるチェックボックスを選択します。
- Delete をクリックします。
- Delete をクリックして確定します。
12.9. Web UI を使用してユーザーまたはグループを IdM ユーザーグループのメンバーマネージャーから取り消す手順
本セクションでは、Web UI を使用して、IdM ユーザーグループのメンバーマネージャーからユーザーまたはグループを取り消す方法を説明します。メンバーマネージャーは、IdM ユーザーグループからユーザーまたはグループを削除できますが、グループの属性を変更できません。
前提条件
- IdM Web UI にログインしている。
- 削除する既存のメンバーマネージャーのユーザーまたはグループの名前と、そのメンバーマネージャーが管理するグループ名が必要です。
手順
- Identity → Groups の順にクリックし、左のサイドバーで User Groups を選択します。
- グループ名をクリックします。
削除するメンバーマネージャーのタイプ (Users または User Groups) を選択します。
- 削除するメンバーマネージャーの横にあるチェックボックスを選択します。
- Delete をクリックします。
- Delete をクリックして確定します。
ユーザーグループからメンバーマネージャーを削除してから、更新が Identity Management 環境のすべてのクライアントに広がるまでに時間がかかる場合があります。
検証手順
ユーザーまたはユーザーグループが、ユーザーまたはユーザーグループのメンバーマネージャーリストから削除されていることを確認します。
関連情報
-
詳細は、
ipa group-add-member-manager --help
を参照してください。
第13章 Ansible Playbook を使用したユーザーグループの管理
本セクションでは、Ansible Playbook を使用したユーザーグループの管理について紹介します。
ユーザーグループは、共通の特権、パスワードポリシーなどの持つユーザーのセットです。
Identity Management (IdM) のユーザーグループには以下が含まれます。
- IdM ユーザー
- 他の IdM ユーザーグループ
- 外部ユーザー (IdM の外部に存在するユーザー)
このセクションは、以下のトピックで構成されています。
13.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 が定義されていません。
表13.1 デフォルトで作成されたユーザーグループ
グループ名 | デフォルトのグループメンバー |
---|---|
| すべての IdM ユーザー |
|
管理権限を持つユーザー (デフォルトの |
| これは、特別な権限がなくなったレガシーグループです |
| Active Directory 信頼を管理する権限を持つユーザー |
ユーザーをユーザーグループに追加すると、ユーザーはグループに関連付けられた権限とポリシーを取得します。たとえば、ユーザーに管理権限を付与するには、ユーザーを admins
グループに追加します。
admins
グループを削除しないでください。admins
は IdM で必要な事前定義グループであるため、この操作により特定のコマンドで問題が生じます。
さらに、IdM で新しいユーザーが作成されるたびに、IdM は、デフォルトで ユーザーのプライベートグループ を作成します。プライベートグループの詳細は、「プライベートグループの ないユーザーの追加」を 参照してください。
13.2. 直接および間接のグループメンバー
IdM のユーザーグループ属性は、直接メンバーと間接メンバーの両方に適用されます。グループ B がグループ A のメンバーである場合、グループ B のすべてのユーザーはグループ A の間接メンバーと見なされます。
たとえば、以下の図では、以下のようになります。
- ユーザー 1 とユーザー 2 は、グループ A の 直接メンバー です。
- ユーザー 3、ユーザー 4、およびユーザー 5 は、グループ A の 間接メンバー です。
図13.1 直接および間接グループメンバーシップ

ユーザーグループ A にパスワードポリシーを設定すると、そのポリシーはユーザーグループ B のすべてのユーザーにも適用されます。
13.3. Ansible Playbook を使用した IdM グループおよびグループメンバーの存在の確保
以下の手順では、Ansible Playbook を使用して、IdM グループとグループメンバー (ユーザーとユーザーグループの両方) が存在することを確認する方法を説明します。
前提条件
- IdM 管理者パスワードを把握している。
- Ansible コントローラーに ansible-freeipa パッケージがインストールされている。
- Ansible Playbook で参照するユーザーが IdM に存在します。Ansible を使用してユーザーの存在を確認する方法は、Ansible Playbook を使用したユーザーアカウントの管理 を参照してください。
手順
inventory.file
などのインベントリーファイルを作成して、そのファイルにipaserver
を定義します。[ipaserver] server.idm.example.com
必要なユーザーおよびグループ情報を使用して 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
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 が間接メンバーとして含まれているかどうかを確認できます。
管理者として
ipaserver
にログインします。$ ssh admin@server.idm.example.com Password: [admin@server /]$
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 ファイルを参照してください。
13.4. Ansible Playbook を使用して IdM ユーザーグループにメンバーマネージャーを存在させる手順
以下の手順では、Ansible Playbook を使用して、ユーザーとユーザーグループ両方の IdM メンバーマネージャーが存在させる方法を説明します。
前提条件
- IdM 管理者パスワードを把握している。
- Ansible コントローラーに ansible-freeipa パッケージがインストールされている。
- メンバーマネージャーとして追加するユーザーまたはグループの名前と、メンバーマネージャーが管理するグループ名を用意する。
手順
inventory.file
などのインベントリーファイルを作成して、そのファイルにipaserver
を定義します。[ipaserver] server.idm.example.com
必要なユーザーおよびグループメンバー管理情報を使用して、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
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_admins が group_a のメンバーであることが確認できます。
管理者として
ipaserver
にログインします。$ ssh admin@server.idm.example.com Password: [admin@server /]$
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 ページを参照してください。
13.5. Ansible Playbook を使用して IdM ユーザーグループにメンバーマネージャーを存在させないようにする手順
以下の手順では、Ansible Playbook を使用して、ユーザーとユーザーグループ両方の IdM メンバーマネージャーが存在させないようにする方法を説明します。
前提条件
- IdM 管理者パスワードを把握している。
- Ansible コントローラーに ansible-freeipa パッケージがインストールされている。
- 削除する既存のメンバーマネージャーのユーザーまたはグループの名前と、そのメンバーマネージャーが管理するグループ名が必要です。
手順
inventory.file
などのインベントリーファイルを作成して、そのファイルにipaserver
を定義します。[ipaserver] server.idm.example.com
必要なユーザーおよびグループメンバー管理情報を使用して、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
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_admins が group_a のメンバーであることが確認できます。
管理者として
ipaserver
にログインします。$ ssh admin@server.idm.example.com Password: [admin@server /]$
group_a についての情報を表示します。
ipaserver]$ ipa group-show group_a Group name: group_a GID: 1133400009
関連情報
-
ipa host-remove-member-manager --help
を参照してください。 -
ipa
の man ページを参照してください。
第14章 IdM CLI を使用したグループメンバーシップの自動化
自動グループメンバーシップを使用すると、属性に基づいてユーザーとホストをグループに自動的に割り当てることができます。たとえば、以下を行うことができます。
- 従業員のマネージャー、ロケーション、またはその他の属性に基づいて従業員のユーザーエントリーをグループに分割します。
- クラス、ロケーション、またはその他の属性に基づいてホストを分割します。
- 全ユーザーまたは全ホストを 1 つのグローバルグループに追加します。
本章では、以下のトピックについて説明します。
14.1. 自動グループメンバーシップの利点
ユーザーの自動メンバーシップを使用すると、以下が可能になります。
グループメンバーシップの手動管理によるオーバーヘッドの削減
すべてのユーザーおよびグループを手作業で割り当てる必要がなくなりました。
ユーザーおよびホスト管理における一貫性の向上
ユーザーとホストは、厳密に定義され、自動的に評価される基準に基づいてグループに割り当てられます。
グループベースの設定管理を簡素化
さまざまな設定がグループに定義され、
sudo
ルール、自動マウント、またはアクセス制御などの個別のグループメンバーに適用されます。ユーザーとホストをグループに自動的に追加すると、この設定の管理が容易になります。
14.2. automember ルール
自動グループメンバーシップを設定する場合、管理者は automember ルールを定義します。automember ルールは、特定のユーザーまたはホストターゲットグループに適用されます。これは、一度に複数のグループに適用することはできません。
ルールの作成後、管理者は条件を追加します。これらは、ユーザーまたはホストをターゲットグループに含めるか、除外するかを指定します。
包含条件
ユーザーまたはホストのエントリーが包含条件を満たす場合、ターゲットグループに含まれます。
除外の条件
ユーザーまたはホストのエントリーが除外された状態を満たす場合、ターゲットグループには含まれません。
この条件は、Perl 互換正規表現 (PCRE) 形式の正規表現として指定されます。PCRE の詳細は、man ページの pcresyntax(3)
を参照してください。
IdM は、包含条件の前に除外条件を評価します。競合が発生した場合は、包含条件よりも除外条件が優先されます。
automember ルールは、今後作成されるすべてのエントリーに適用されます。これらのエントリーは指定されたターゲットグループに自動的に追加されます。エントリーが複数の automember ルールで指定された条件を満たすと、対応するグループすべてに追加されます。
既存のエントリーは新規ルールの影響を 受けません。既存のエントリーを変更する場合は、「IdM CLI を使用した既存のエントリーへの automember ルールの適用」を参照してください。
14.3. IdM CLI を使用した automember ルールの追加
本セクションでは、IdM CLI を使用して automember ルールを追加する方法を説明します。automember ルールの詳細は、「automember ルール」を参照してください。
automember ルールを追加した後に、「automember ルールへの条件の追加」で説明されている手順に従って条件を追加できます。
既存のエントリーは新規ルールの影響を 受けません。既存のエントリーを変更する場合は、「IdM CLI を使用した既存のエントリーへの automember ルールの適用」を参照してください。
前提条件
- 管理者としてログインしている必要があります。詳細は、Using kinit to log in to IdM manually を参照してください。
- 新しいルールのターゲットグループは IdM に存在している必要があります。
手順
-
ipa automember-add
コマンドを入力して、automember ルールを追加します。 プロンプトが表示されたら、以下を指定します。
- automember ルール。これはターゲットグループ名です。
- グループタイプ。これは、ルールがユーザーグループまたはホストグループをターゲットにするかどうかを指定します。ユーザーグループをターゲットにするには、group を入力します。ホストグループをターゲットに設定するには、ホストグループ を入力します。
たとえば、user_group という名前のユーザーグループの automember ルールを追加するには、以下を実行します。
$ ipa automember-add Automember Rule: user_group Grouping Type: group -------------------------------- Added automember rule "user_group" -------------------------------- Automember Rule: user_group
検証手順
- IdM CLI を使用して、既存の automember ルールを表示して、IdM に既存の automember ルールと条件を表示できます。
14.4. IdM CLI を使用した automember ルールへの条件の追加
本セクションでは、IdM CLI を使用して automember ルールに条件を追加する方法を説明します。automember ルールの詳細は、「automember ルール」を参照してください。
前提条件
- 管理者としてログインしている必要があります。詳細は、Using kinit to log in to IdM manually を参照してください。
- ターゲットルールは IdM に存在している必要があります。詳細は「IdM CLI を使用した automember ルールの追加」を参照してください。
手順
-
ipa automember-add-condition
コマンドを使用して、包含または除外の条件を定義します。 プロンプトが表示されたら、以下を指定します。
- automember ルール。これはターゲットルール名です。詳細は、「Automember rules」を参照してください。
- 属性キー。これは、フィルターが適用される entry 属性を指定します。たとえば、ユーザーの uid です。
- グループタイプ。これは、ルールがユーザーグループまたはホストグループをターゲットにするかどうかを指定します。ユーザーグループをターゲットにするには、group を入力します。ホストグループをターゲットに設定するには、ホストグループ を入力します。
- 包含正規表現 および 除外正規表現。正規表現として条件を指定します。ある条件のみを指定する場合は、他の条件が求められたら Enter を押します。
たとえば、以下の条件は、ユーザーログイン属性 (uid) のすべての値 (.*) を対象にしています。
$ ipa automember-add-condition Automember Rule: user_group Attribute Key: uid Grouping Type: group [Inclusive Regex]: .* [Exclusive Regex]: ---------------------------------- Added condition(s) to "user_group" ---------------------------------- Automember Rule: user_group Inclusive Regex: uid=.* ---------------------------- Number of conditions added 1 ----------------------------
別の例として、automembership ルールを使用して、Active Directory (AD) から同期したすべての Windows ユーザーをターゲットにできます。これを行うには、objectClass 属性で ntUser を持つすべてのユーザーをターゲットにする条件を作成します。これは、すべての AD ユーザーが共有します。
$ ipa automember-add-condition Automember Rule: ad_users Attribute Key: objectclass Grouping Type: group [Inclusive Regex]: ntUser [Exclusive Regex]: ------------------------------------- Added condition(s) to "ad_users" ------------------------------------- Automember Rule: ad_users Inclusive Regex: objectclass=ntUser ---------------------------- Number of conditions added 1 ----------------------------
検証手順
- IdM CLI を使用して、既存の automember ルールを表示して、IdM に既存の automember ルールと条件を表示できます。
14.5. IdM CLI を使用した既存の automember ルールの表示
本セクションでは、IdM CLI を使用して既存の automember ルールを表示する方法を説明します。
前提条件
- 管理者としてログインしている必要があります。詳細は、Using kinit to log in to IdM manually を参照してください。
手順
-
ipa automember-find
コマンドを入力します。 プロンプトが表示されたら、Grouping タイプ を指定します。
- ユーザーグループをターゲットにするには、group を入力します。
ホストグループをターゲットに設定するには、ホストグループ を入力します。
以下に例を示します。
$ ipa automember-find Grouping Type: group --------------- 1 rules matched --------------- Automember Rule: user_group Inclusive Regex: uid=.* ---------------------------- Number of entries returned 1 ----------------------------
14.6. IdM CLI を使用した automember ルールの削除
本セクションでは、IdM CLI を使用して automember ルールを削除する方法を説明します。
automember ルールを削除すると、ルールに関連付けられたすべての条件も削除されます。ルールから特定の条件のみを削除するには、「IdM CLI を使用して automember ルールから条件の削除」を参照してください。
前提条件
- 管理者としてログインしている必要があります。詳細は、Using kinit to log in to IdM manually を参照してください。
手順
-
ipa automember-del
コマンドを実行します。 プロンプトが表示されたら、以下を指定します。
- automember ルール。これは、削除するルールです。
- グループルール。これは、削除するルールがユーザーグループまたはホストグループのルールであるかどうかを指定します。group または hostgroup を入力します。
14.7. IdM CLI を使用した automember ルールからの条件の削除
本セクションでは、automember ルールから特定の条件を削除する方法を説明します。
前提条件
- 管理者としてログインしている必要があります。詳細は、Using kinit to log in to IdM manually を参照してください。
手順
-
ipa automember-remove-condition
コマンドを実行します。 プロンプトが表示されたら、以下を指定します。
- automember ルール。これは、条件を削除するルールの名前です。
- 属性キー。これはターゲットエントリー属性です。たとえば、ユーザーの uid です。
- グループタイプ。これは、削除する条件がユーザーグループまたはホストグループのどちらであるかを指定します。group または hostgroup を入力します。
包含正規表現 および 除外正規表現。削除する条件を指定します。ある条件のみを指定する場合は、他の条件が求められたら Enter を押します。
以下に例を示します。
$ ipa automember-remove-condition Automember Rule: user_group Attribute Key: uid Grouping Type: group [Inclusive Regex]: .* [Exclusive Regex]: ----------------------------------- Removed condition(s) from "user_group" ----------------------------------- Automember Rule: user_group ------------------------------ Number of conditions removed 1 ------------------------------
14.8. IdM CLI を使用して automember ルールを既存のエントリーに適用する
Automember ルールは、ルールの追加後に作成されたユーザーおよびホストエントリーに自動的に適用されます。ルールの追加前に存在するエントリーには、一時的な適用は行われません。
以前に追加したエントリーに automember ルールを適用するには、自動メンバーシップを手動で再構築する必要があります。自動メンバーシップを再構築すると、既存の automember ルールがすべて再評価され、すべてのユーザーまたはホストエントリーまたは特定のエントリーに適用されます。
エントリーがグループの包含条件に一致しない場合でも、自動メンバーシップを再構築しても、グループからユーザーまたはホストエントリーは削除 されません。手動で 削除するには、「IdM CLI を使用したユーザーグループからのメンバーの削除」または「CLI を使用 した IdM ホストグループメンバーの削除」を参照して ください。
前提条件
- 管理者としてログインしている必要があります。詳細は、「 kinit を使用した IdM の手動ログイン」を 参照してください。
手順
自動メンバーシップを再構築するには、
ipa automember-rebuild
コマンドを実行します。ターゲットに設定するエントリーを指定するには、以下のオプションを使用します。全ユーザーの自動メンバーシップを再構築するには、
--type=group
オプションを使用します。$ ipa automember-rebuild --type=group -------------------------------------------------------- Automember rebuild task finished. Processed (9) entries. --------------------------------------------------------
-
すべてのホストの自動メンバーシップを再構築するには、
--type=hostgroup
オプションを使用します。 指定したユーザーの自動メンバーシップを再構築するには、
--users=target_user
オプションを使用します。$ ipa automember-rebuild --users=target_user1 --users=target_user2 -------------------------------------------------------- Automember rebuild task finished. Processed (2) entries. --------------------------------------------------------
-
指定したホストの自動メンバーシップを再構築するには、
--hosts=client.idm.example.com
を使用します。
14.9. デフォルトの automember グループの設定
デフォルトの automember グループを設定すると、automember ルールに一致しない新規ユーザーまたはホストエントリーは自動的にこのデフォルトグループに追加されます。
前提条件
- 管理者としてログインしている必要があります。詳細は、Using kinit to log in to IdM manually を参照してください。
- デフォルトに設定するターゲットグループは IdM に存在します。
手順
-
ipa automember-default-group-set
コマンドを入力して、デフォルトの automember グループを設定します。 プロンプトが表示されたら、以下を指定します。
- ターゲットグループ名を指定する Default (fallback) Group。
グルーピングタイプ。ターゲットがユーザーグループか、ホストグループであるかを指定します。ユーザーグループをターゲットにするには、group を入力します。ホストグループをターゲットに設定するには、ホストグループ を入力します。
以下に例を示します。
$ ipa automember-default-group-set Default (fallback) Group: default_user_group Grouping Type: group --------------------------------------------------- Set default (fallback) group for automember "default_user_group" --------------------------------------------------- Default (fallback) Group: cn=default_user_group,cn=groups,cn=accounts,dc=example,dc=com
注記現在のデフォルトの automember グループを削除するには、
ipa automember-default-group-remove
コマンドを実行します。
検証手順
グループが正しく設定されていることを確認するには、
ipa automember-default-group-show
コマンドを実行します。コマンドは、現在のデフォルトの automember グループを表示します。以下に例を示します。$ ipa automember-default-group-show Grouping Type: group Default (fallback) Group: cn=default_user_group,cn=groups,cn=accounts,dc=example,dc=com
第15章 IdM Web UI でグループメンバーシップの自動化
自動グループメンバーシップを使用すると、属性に基づいてユーザーとホストをグループに自動的に割り当てることができます。たとえば、以下を行うことができます。
- 従業員のマネージャー、ロケーション、またはその他の属性に基づいて従業員のユーザーエントリーをグループに分割します。
- クラス、ロケーション、またはその他の属性に基づいてホストを分割します。
- 全ユーザーまたは全ホストを 1 つのグローバルグループに追加します。
本章では、以下のトピックについて説明します。
- 自動グループメンバーシップの利点
- automember ルール
- IdM Web UI で automember ルールの追加
- IdM Web UI で automember ルールへの条件の追加
- IdM Web UI で既存の automember ルールおよび条件の表示
- IdM Web UI で automember ルールの削除
- IdM Web UI で automember ルールから条件の削除
- IdM Web UI で automember ルールを既存エントリーに適用
- IdM Web UI でデフォルトのユーザーグループの設定
- IdM Web UI でデフォルトのホストグループの設定
15.1. 自動グループメンバーシップの利点
ユーザーの自動メンバーシップを使用すると、以下が可能になります。
グループメンバーシップの手動管理によるオーバーヘッドの削減
すべてのユーザーおよびグループを手作業で割り当てる必要がなくなりました。
ユーザーおよびホスト管理における一貫性の向上
ユーザーとホストは、厳密に定義され、自動的に評価される基準に基づいてグループに割り当てられます。
グループベースの設定管理を簡素化
さまざまな設定がグループに定義され、
sudo
ルール、自動マウント、またはアクセス制御などの個別のグループメンバーに適用されます。ユーザーとホストをグループに自動的に追加すると、この設定の管理が容易になります。
15.2. automember ルール
自動グループメンバーシップを設定する場合、管理者は automember ルールを定義します。automember ルールは、特定のユーザーまたはホストターゲットグループに適用されます。これは、一度に複数のグループに適用することはできません。
ルールの作成後、管理者は条件を追加します。これらは、ユーザーまたはホストをターゲットグループに含めるか、除外するかを指定します。
包含条件
ユーザーまたはホストのエントリーが包含条件を満たす場合、ターゲットグループに含まれます。
除外の条件
ユーザーまたはホストのエントリーが除外された状態を満たす場合、ターゲットグループには含まれません。
この条件は、Perl 互換正規表現 (PCRE) 形式の正規表現として指定されます。PCRE の詳細は、man ページの pcresyntax(3)
を参照してください。
IdM は、包含条件の前に除外条件を評価します。競合が発生した場合は、包含条件よりも除外条件が優先されます。
automember ルールは、今後作成されるすべてのエントリーに適用されます。これらのエントリーは指定されたターゲットグループに自動的に追加されます。エントリーが複数の automember ルールで指定された条件を満たすと、対応するグループすべてに追加されます。
既存のエントリーは新規ルールの影響を 受けません。既存のエントリーを変更する場合は、「IdM Web UI で automember ルールを既存エントリーに適用」を参照してください。
15.3. IdM Web UI で automember ルールの追加
本セクションでは、IdM Web UI を使用して automember ルールを追加する方法を説明します。automember ルールの詳細は、「automember ルール」を参照してください。
既存のエントリーは新規ルールの影響を 受けません。既存のエントリーを変更する場合は、「IdM Web UI で automember ルールを既存エントリーに適用」を参照してください。
前提条件
- IdM Web UI にログインしている。
-
admins
グループのメンバーである。 - 新しいルールのターゲットグループが IdM に存在する。
手順
- Identity → Automember をクリックして、User group rule または Host group rules を選択します。
- Add をクリックします。
Automember rule フィールドで、ルールを適用するグループを選択します。これはターゲットグループ名です。
- Add をクリックして確定します。
- 必要に応じて、「IdM Web UI で automember ルールへの条件の追加」で説明されている手順に従って、新しいルールに条件を追加できます。
15.4. IdM Web UI で automember ルールへの条件の追加
本セクションでは、IdM Web UI を使用して、automember ルールに条件を追加する方法を説明します。automember ルールの詳細は、「automember ルール」を参照してください。
前提条件
- IdM Web UI にログインしている。
-
admins
グループのメンバーである。 - ターゲットルールが IdM に存在する。
手順
- Identity → Automember をクリックして、User group rule または Host group rules を選択します。
- 条件を追加するルールをクリックします。
Inclusive セクションまたは Exclusive セクションで、Add をクリックします。
- Attribute フィールドで、必要な属性 (uid など) を選択します。
- Expression フィールドに正規表現を定義します。
Add をクリックします。
たとえば、以下の条件は、ユーザー ID (uid) 属性に値 (.*) が指定されているすべてのユーザーを対象とします。
15.5. IdM Web UI を使用した既存の automember ルールおよび条件の表示
本セクションでは、IdM Web UI を使用して、既存の automember ルールおよび条件を表示する方法を説明します。
前提条件
- IdM Web UI にログインしている。
-
admins
グループのメンバーである。
手順
- Identity → Automember をクリックして、User group rule または Host group rules を選択して、それぞれの automember ルールを表示します。
必要に応じて、ルールをクリックして、Inclusive セクションまたは Exclusive セクションにそのルールの条件を表示します。
15.6. IdM Web UI を使用した automember ルールの削除
本セクションでは、IdM Web UI を使用して automember ルールを削除する方法を説明します。
automember ルールを削除すると、ルールに関連付けられたすべての条件も削除されます。ルールから特定の条件のみを削除するには、「IdM Web UI を使用して automember ルールから条件を削除」を参照してください。
前提条件
- IdM Web UI にログインしている。
-
admins
グループのメンバーである。
手順
- Identity → Automember をクリックして、User group rule または Host group rules を選択して、それぞれの automember ルールを表示します。
- 削除するルールの横にあるチェックボックスを選択します。
Delete をクリックします。
- Delete をクリックして確定します。
15.7. IdM Web UI で automember ルールから条件の削除
本セクションでは、IdM Web UI を使用して、automember ルールから特定の条件を削除する方法を説明します。
前提条件
- IdM Web UI にログインしている。
-
admins
グループのメンバーである。
手順
- Identity → Automember をクリックして、User group rule または Host group rules を選択して、それぞれの automember ルールを表示します。
- ルールをクリックして、Inclusive セクションまたは Exclusive セクションでそのルールの条件を表示します。
- 削除する条件の横にあるチェックボックスを選択します。
Delete をクリックします。
- Delete をクリックして確定します。
15.8. IdM Web UI で automember ルールを既存エントリーに適用
Automember ルールは、ルールの追加後に作成されたユーザーおよびホストエントリーに自動的に適用されます。ルールの追加前に存在するエントリーには、一時的な適用は行われません。
以前に追加したエントリーに automember ルールを適用するには、自動メンバーシップを手動で再構築する必要があります。自動メンバーシップを再構築すると、既存の automember ルールがすべて再評価され、すべてのユーザーまたはホストエントリーまたは特定のエントリーに適用されます。
エントリーがグループの包含条件に一致しない場合でも、自動メンバーシップを再構築しても、グループからユーザーまたはホストエントリーは削除 されません。手動で 削除するには、「IdM Web UI を使用したユーザーグループからメンバーの削除」または「IdM Web UI でホストグループメンバーの削除」を 参照してください。
15.8.1. 全ユーザーまたは全ホストに対して自動メンバーシップの再構築
本セクションでは、ユーザーまたはホストのすべてのエントリーに対して自動メンバーシップを再構築する方法を説明します。
前提条件
- IdM Web UI にログインしている。
-
admins
グループのメンバーである。
手順
- Identity → Users または Hosts を選択します。
Actions → Rebuild auto membership をクリックします。
15.8.2. ユーザーまたはホスト 1 つに対する自動メンバーシップの再構築
本セクションでは、特定のユーザーエントリーまたはホストエントリーに対して自動メンバーシップを再構築する方法を説明します。
前提条件
- IdM Web UI にログインしている。
-
admins
グループのメンバーである。
手順
- Identity → Users または Hosts を選択します。
- 必要なユーザー名またはホスト名をクリックします。
Actions → Rebuild auto membership をクリックします。
15.9. IdM Web UI を使用したデフォルトのユーザーグループの設定
デフォルトのユーザーグループを設定する際には、automember ルールに一致しない新規ユーザーエントリーは自動的にこのデフォルトグループに追加されます。
前提条件
- IdM Web UI にログインしている。
-
admins
グループのメンバーである。 - デフォルトとして設定するターゲットユーザーグループが IdM に存在します。
手順
- Identity → Automember をクリックして、User group rules を選択します。
Default user group フィールドで、デフォルトのユーザーグループとして設定するグループを選択します。
15.10. IdM Web UI でデフォルトのホストグループの設定
デフォルトのホストグループを設定する際には、automember ルールに一致しない新規ホストエントリーが自動的にこのデフォルトグループに追加されます。
前提条件
- IdM Web UI にログインしている。
-
admins
グループのメンバーである。 - デフォルトとして設定されるターゲットホストグループが IdM にある。
手順
- Identity → Automember をクリックして、Host group rules を選択します。
Default host group フィールドで、デフォルトのホストグループとして設定するグループを選択します。
第16章 Ansible を使用した IdM のグループメンバーシップの自動化
自動グループメンバーシップを使用すると、ユーザーとホストのユーザーグループとホストグループを、その属性に基づいて自動的に割り当てることができます。たとえば、以下を行うことができます。
-
従業員のユーザーエントリーを、従業員のマネージャー、場所、役職などの属性に基づいてグループに分割します。コマンドラインに
ipa user-add --help
と入力すると、すべての属性を一覧表示できます。 -
ホストを、クラス、場所、またはその他の属性に基づいてグループに分割します。コマンドラインに
ipa host-add --help
と入力すると、すべての属性を一覧表示できます。 - 全ユーザーまたは全ホストを 1 つのグローバルグループに追加します。
Red Hat Ansible Engine を使用すると、Identity Management (IdM) で自動グループメンバーシップの管理を自動化できます。
本セクションでは、以下のトピックについて説明します。
16.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
権限があれば、ipaserver
、ipareplica
、ipaclient
、および 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
のパスワードを把握している。
手順
Ansible 設定および Playbook のディレクトリーをホームディレクトリーに作成します。
$ mkdir ~/MyPlaybooks/
~/MyPlaybooks/ ディレクトリーに移動します。
$ cd ~/MyPlaybooks
~/MyPlaybooks/ansible.cfg ファイルを以下の内容で作成します。
[defaults] inventory = /home/your_username/MyPlaybooks/inventory [privilege_escalation] become=True
~/MyPlaybooks/inventory ファイルを以下の内容で作成します。
[eu] server.idm.example.com [us] replica.idm.example.com [ipaserver:children] eu us
この設定は、これらの場所にあるホストの 2 つのホストグループ (eu と us) を定義します。さらに、この設定は、eu および us グループのすべてのホストを含む ipaserver ホストグループを定義します。
(必要に応じて) SSH 公開鍵および秘密鍵を作成します。テスト環境でのアクセスを簡素化するには、秘密鍵にパスワードを設定しないでください。
$ ssh-keygen
各管理対象ノードの IdM
admin
アカウントに SSH 公開鍵をコピーします。$ ssh-copy-id admin@server.idm.example.com $ ssh-copy-id admin@replica.idm.example.com
これらのコマンドを入力する場合は、IdM
admin
パスワードを入力する必要があります。
16.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 インベントリーファイル を作成している。
手順
~/MyPlaybooks/ ディレクトリーに移動します。
$ cd ~/MyPlaybooks/
/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
-
automember-group-present-copy.yml
ファイルを開いて編集します。 ipaautomember
タスクセクションで次の変数を設定して、ファイルを調整します。-
ipaadmin_password
変数は IdMadmin
のパスワードに設定します。 -
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
-
- ファイルを保存します。
Playbook ファイルとインベントリーファイルを指定して Ansible Playbook を実行します。
$ ansible-playbook -v -i inventory automember-group-present-copy.yml
関連情報
- 自動グループメンバーシップの利点 および automember ルール を参照してください。
- Ansible を使用した IdM ユーザーグループの automember ルールが存在することの確認 を参照してください。
-
/usr/share/doc/ansible-freeipa/
ディレクトリーのREADME-automember.md
ファイルを参照してください。 -
/usr/share/doc/ansible-freeipa/playbooks/automember
ディレクトリーを参照してください。
16.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 インベントリーファイル を作成している。
手順
~/MyPlaybooks/ ディレクトリーに移動します。
$ cd ~/MyPlaybooks/
/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
-
automember-usergroup-rule-present.yml
を開いて編集します。 次のパラメーターを変更して、ファイルを調整します。
- ユースケースに対応するように Playbook の名前を変更します (例: Automember user group rule member present)。
- ユースケースに合わせて、タスクの名前を変更します (例: Ensure an automember condition for a user group is present)。
ipaautomember
タスクセクションで、以下の変数を設定します。-
ipaadmin_password
変数は IdMadmin
のパスワードに設定します。 -
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: .*
- ファイルを保存します。
Playbook ファイルとインベントリーファイルを指定して Ansible Playbook を実行します。
$ ansible-playbook -v -i inventory automember-usergroup-rule-present.yml
検証手順
IdM 管理者としてログインします。
$ kinit admin
ユーザーを追加します。以下に例を示します。
$ 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 ...
関連情報
- IdM CLI を使用した既存エントリーへの automember ルールの適用 を参照してください。
- 自動グループメンバーシップの利点 および automember ルール を参照してください。
-
/usr/share/doc/ansible-freeipa/
ディレクトリーのREADME-automember.md
ファイルを参照してください。 -
/usr/share/doc/ansible-freeipa/playbooks/automember
ディレクトリーを参照してください。
16.4. Ansible を使用した IdM ユーザーグループの automember ルールに条件がないことの確認
以下の手順では、Ansible Playbook を使用して、Identity Management (IdM) グループのautomember
ルールに条件がないことを確認する方法を説明します。この例では、automember
ルールに条件がないことが保証されており、initials
がdp であるユーザーを含める必要があることを指定しています。automember ルールが testing_group グループに適用されます。条件を適用することにより、今後は、イニシャルがdpである IdM ユーザーがtesting_groupのメンバーにならないようにします。
前提条件
-
IdM
admin
のパスワードを把握している。 - testing_group ユーザーグループおよび automember ユーザーグループルールが IdM に存在します。
以下の要件を満たす Ansible コントロールノードを設定している。
- Ansible バージョン 2.8 以降を使用している。
- Ansible コントローラーに ansible-freeipa パッケージがインストールされている。
- ~/MyPlaybooks/ ディレクトリーに、このオプションを設定する IdM サーバーの完全修飾ドメイン名 (FQDN) で Ansible インベントリーファイル を作成している。
手順
~/MyPlaybooks/ ディレクトリーに移動します。
$ cd ~/MyPlaybooks/
/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
-
automember-usergroup-rule-absent.yml
を開いて編集します。 次のパラメーターを変更して、ファイルを調整します。
- ユースケースに対応するように Playbook の名前を変更します (例: Automember user group rule member absent)。
- ユースケースに合わせて、タスクの名前を変更します (例: Ensure an automember condition for a user group is absent)。
ipaautomember
タスクセクションで、以下の変数を設定します。-
ipaadmin_password
変数は IdMadmin
のパスワードに設定します。 -
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
- ファイルを保存します。
Playbook ファイルとインベントリーファイルを指定して Ansible Playbook を実行します。
$ ansible-playbook -v -i inventory automember-usergroup-rule-absent.yml
検証手順
IdM 管理者としてログインします。
$ kinit admin
automember グループを表示します。
$ ipa automember-show --type=group testing_group Automember Rule: testing_group
出力に Inclusive Regex: initials=dp
エントリーがない場合は、testing_group automember ルールに指定した条件が含まれていないことを確認します。
関連情報
- IdM CLI を使用した既存エントリーへの automember ルールの適用 を参照してください。
- 自動グループメンバーシップの利点 および automember ルール を参照してください。
-
/usr/share/doc/ansible-freeipa/
ディレクトリーのREADME-automember.md
ファイルを参照してください。 -
/usr/share/doc/ansible-freeipa/playbooks/automember
ディレクトリーを参照してください。
16.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 インベントリーファイル を作成している。
手順
~/MyPlaybooks/ ディレクトリーに移動します。
$ cd ~/MyPlaybooks/
/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
-
automember-group-absent-copy.yml
を開いて編集します。 ipaautomember
タスクセクションで次の変数を設定して、ファイルを調整します。-
ipaadmin_password
変数は IdMadmin
のパスワードに設定します。 -
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
-
- ファイルを保存します。
Playbook ファイルとインベントリーファイルを指定して Ansible Playbook を実行します。
$ ansible-playbook -v -i inventory automember-group-absent.yml
関連情報
- 自動グループメンバーシップの利点 および automember ルール を参照してください。
-
/usr/share/doc/ansible-freeipa/
ディレクトリーのREADME-automember.md
ファイルを参照してください。 -
/usr/share/doc/ansible-freeipa/playbooks/automember
ディレクトリーを参照してください。
16.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 インベントリーファイル を作成している。
手順
~/MyPlaybooks/ ディレクトリーに移動します。
$ cd ~/MyPlaybooks/
/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
-
automember-hostgroup-rule-present-copy.yml
を開いて編集します。 ipaautomember
タスクセクションで次の変数を設定して、ファイルを調整します。-
ipaadmin_password
変数は IdMadmin
のパスワードに設定します。 -
name
変数を primary_dns_domain_hosts に設定します。 -
automember_type
を hostgroup に設定します。 -
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
-
- ファイルを保存します。
Playbook ファイルとインベントリーファイルを指定して Ansible Playbook を実行します。
$ ansible-playbook -v -i inventory automember-hostgroup-rule-present-copy.yml
関連情報
- IdM CLI を使用した既存エントリーへの automember ルールの適用 を参照してください。
- 自動グループメンバーシップの利点 および automember ルール を参照してください。
-
/usr/share/doc/ansible-freeipa/
ディレクトリーのREADME-automember.md
ファイルを参照してください。 -
/usr/share/doc/ansible-freeipa/playbooks/automember
ディレクトリーを参照してください。
16.7. 関連情報
第17章 IdM CLI を使用してユーザーグループにパーミッションを委譲してユーザーを管理する手順
委譲は、セルフサービスルールおよびロールベースのアクセス制御 (RBAC) などの IdM のアクセス制御メソッドの 1 つです。委譲を使用して、あるユーザーのグループにパーミッションを割り当てて別のユーザーのグループのエントリーを管理できます。
本セクションでは、以下のトピックについて説明します。
17.1. 委譲ルール
委譲ルール を作成して、ユーザーグループにパーミッションを委譲してユーザーを管理できます。
委譲ルールを使用すると、特定のユーザーグループが、別のユーザーグループ内のユーザーの特定の属性に対して書き込み (編集) 操作を実行できます。このようなアクセス制御ルールは、委譲ルールで指定された属性のサブセットの編集に限定されており、エントリー全体の追加や削除、未指定の属性の制御はできません。
委譲ルールにより、IdM の既存のユーザーグループにパーミッションが付与されます。委任を使用すると、managers
ユーザーグループで employees
ユーザーグループでユーザーの選択された属性を管理できます。
17.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
17.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
----------------------------
17.4. IdM CLI を使用した委譲ルールの変更
本セクションでは、IdM CLI を使用して既存の委譲ルールを変更する方法を説明します。
--attrs
オプションは、サポートされる属性のリストをすべて上書きするため、属性の完全なリストと新しい属性を常に含めます。これは、--permissions
オプションにも適用されます。
前提条件
-
admins
グループのメンバーとしてログインしている。
手順
必要に応じて、
ipa delegation-mod
コマンドを実行します。たとえば、displayname
属性を基本的なマネージャー属性
の例に追加するには、次のコマンドを実行します。$ ipa delegation-mod "basic manager attributes" --attrs=businesscategory --attrs=departmentnumber --attrs=employeetype --attrs=employeenumber --attrs=displayname ---------------------------------------------- Modified delegation "basic manager attributes" ---------------------------------------------- Delegation name: basic manager attributes Permissions: read, write Attributes: businesscategory, departmentnumber, employeetype, employeenumber, displayname Member user group: employees User group: managers
17.5. IdM CLI を使用した委譲ルールの削除
本セクションでは、IdM CLI を使用して既存の委譲ルールを削除する方法を説明します。
前提条件
-
admins
グループのメンバーとしてログインしている。
手順
-
ipa delegation-del
コマンドを入力します。 プロンプトが表示されたら、削除する委譲ルールの名前を入力します。
$ ipa delegation-del Delegation name: basic manager attributes --------------------------------------------- Deleted delegation "basic manager attributes" ---------------------------------------------
第18章 Web UI を使用してユーザーグループにパーミッションを委譲してユーザーを管理する手順
委譲は、セルフサービスルールおよびロールベースのアクセス制御 (RBAC) などの IdM のアクセス制御メソッドの 1 つです。委譲を使用して、あるユーザーのグループにパーミッションを割り当てて別のユーザーのグループのエントリーを管理できます。
本セクションでは、以下のトピックについて説明します。
18.1. 委譲ルール
委譲ルール を作成して、ユーザーグループにパーミッションを委譲してユーザーを管理できます。
委譲ルールを使用すると、特定のユーザーグループが、別のユーザーグループ内のユーザーの特定の属性に対して書き込み (編集) 操作を実行できます。このようなアクセス制御ルールは、委譲ルールで指定された属性のサブセットの編集に限定されており、エントリー全体の追加や削除、未指定の属性の制御はできません。
委譲ルールにより、IdM の既存のユーザーグループにパーミッションが付与されます。委任を使用すると、managers
ユーザーグループで employees
ユーザーグループでユーザーの選択された属性を管理できます。
18.2. IdM WebUI を使用した委譲ルールの作成
本セクションでは、IdM WebUI を使用して委譲ルールを作成する方法を説明します。
前提条件
-
admins
グループのメンバーとして IdM Web UI にログインしている。
手順
- IPA Server メニューから、Role-Based Access Control → Delegations をクリックします。
Add をクリックします。
Add delegation ウィンドウで、以下を実行します。
- 新しい委譲ルールに名前を付けます。
- 指定の属性を表示する権限 (read)、および指定の属性を追加または変更する権限 (write) をユーザーに指定しているかどうかを示すチェックボックスを選択して、パーミッションを設定します。
- ユーザーグループドロップダウンメニューで、パーミッションを付与している グループを選択し、メンバーグループのユーザーエントリーを表示または編集します。
- Member user group ドロップダウンメニューで、委譲グループのメンバーが エントリーを編集できる グループを選択します。
属性ボックスで、パーミッションを付与する属性のチェックボックスを選択します。
- Add ボタンをクリックして、新規委譲ルールを保存します。
18.3. IdM WebUI を使用して既存の委任ルールの表示
本セクションでは、IdM WebUI を使用して既存の委譲ルールを表示する方法を説明します。
前提条件
-
admins
グループのメンバーとして IdM Web UI にログインしている。
手順
IPA Server メニューから、Role-Based Access Control → Delegations をクリックします。
18.4. IdM WebUI を使用した委譲ルールの変更
本セクションでは、IdM WebUI を使用して既存の委譲ルールを変更する方法を説明します。
前提条件
-
admins
グループのメンバーとして IdM Web UI にログインしている。
手順
IPA Server メニューから、Role-Based Access Control → Delegations をクリックします。
- 変更するルールをクリックします。
必要な変更を行います。
- ルールの名前を変更します。
- 指定の属性を表示する権限 (read)、および指定の属性を追加または変更する権限 (write) をユーザーに指定しているかどうかを示すチェックボックスを選択して、付与されたパーミッションを変更します。
- ユーザーグループドロップダウンメニューで、パーミッションを付与している グループを選択し、メンバーグループのユーザーエントリーを表示または編集します。
- Member user group ドロップダウンメニューで、委譲グループのメンバーが エントリーを編集できる グループを選択します。
属性ボックスで、パーミッションを付与する属性のチェックボックスを選択します。属性のパーミッションを削除するには、関連するチェックボックスの選択を解除します。
- Save ボタンをクリックして変更を保存します。
18.5. IdM WebUI を使用した委譲ルールの削除
本セクションでは、IdM WebUI を使用して既存の委譲ルールを削除する方法を説明します。
前提条件
-
admins
グループのメンバーとして IdM Web UI にログインしている。
手順
- IPA Server メニューから、Role-Based Access Control → Delegations をクリックします。
- 削除するルールの横にあるチェックボックスを選択します。
Delete をクリックします。
- Delete をクリックして確定します。
第19章 Ansible Playbook を使用してユーザーグループにパーミッションを委譲してユーザーを管理する手順
委譲は、セルフサービスルールおよびロールベースのアクセス制御 (RBAC) などの IdM のアクセス制御メソッドの 1 つです。委譲を使用して、あるユーザーのグループにパーミッションを割り当てて別のユーザーのグループのエントリーを管理できます。
本セクションでは、以下のトピックについて説明します。
19.1. 委譲ルール
委譲ルール を作成して、ユーザーグループにパーミッションを委譲してユーザーを管理できます。
委譲ルールを使用すると、特定のユーザーグループが、別のユーザーグループ内のユーザーの特定の属性に対して書き込み (編集) 操作を実行できます。このようなアクセス制御ルールは、委譲ルールで指定された属性のサブセットの編集に限定されており、エントリー全体の追加や削除、未指定の属性の制御はできません。
委譲ルールにより、IdM の既存のユーザーグループにパーミッションが付与されます。委任を使用すると、managers
ユーザーグループで employees
ユーザーグループでユーザーの選択された属性を管理できます。
19.2. IdM の Ansible インベントリーファイルの作成
Ansible を使用する場合は、ホームディレクトリーに Ansible Playbook 専用のサブディレクトリーを作成して、/usr/share/doc/ansible-freeipa/*
と /usr/share/doc/rhel-system-roles/*
サブディレクトリーからコピーして調整できるようにします。この方法には、以下の利点があります。
- すべての Playbook を 1 カ所で見つけることがでる。
-
root
権限を呼び出さずに Playbook を実行できる。
手順
Ansible 設定および Playbook のディレクトリーをホームディレクトリーに作成します。
$ mkdir ~/MyPlaybooks/
~/MyPlaybooks/ ディレクトリーに移動します。
$ cd ~/MyPlaybooks
~/MyPlaybooks/ansible.cfg ファイルを以下の内容で作成します。
[defaults] inventory = /home/<username>/MyPlaybooks/inventory [privilege_escalation] become=True
~/MyPlaybooks/inventory ファイルを以下の内容で作成します。
[eu] server.idm.example.com [us] replica.idm.example.com [ipaserver:children] eu us
この設定は、これらの場所にあるホストの 2 つのホストグループ (eu と us) を定義します。さらに、この設定は、eu および us グループのすべてのホストを含む ipaserver ホストグループを定義します。
19.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/ ディレクトリーにある。
手順
~/ MyPlaybooks/ ディレクトリーに移動します。
$ cd ~/MyPlaybooks/
/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
-
Ansible Playbook ファイル
delegation-present-copy.yml
を開きます。 ipadelegation
タスクセクションに以下の変数を設定して、ファイルを調整します。-
ipaadmin_password
変数は IdM 管理者のパスワードに設定します。 -
name
変数は新しい委譲ルールの名前に設定します。 -
permission
変数は、付与するパーミッションをコンマ区切りの一覧(read
およびwrite
)で設定します。 -
attribute
変数は、委譲されたユーザーグループが管理できる属性の一覧 (businesscategory
、departmentnumber
、employeenumber
および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
-
- ファイルを保存します。
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 を参照してください。
19.4. Ansible を使用して委譲ルールがないことを確認する手順
以下の手順では、Ansible Playbook を使用して、指定した委譲ルールが IdM 設定に存在しないことを確認する方法を説明します。以下の例では、カスタムの basic manager attributes 委譲ルールが IdM に存在しないことを確認する方法を説明します。
前提条件
- IdM 管理者パスワードを把握している。
以下の要件を満たす Ansible コントロールノードを設定している。
- Ansible バージョン 2.8 以降を使用している。
- Ansible コントローラーに ansible-freeipa パッケージがインストールされている。
- このオプションを設定する IdM サーバーの完全修飾ドメイン名 (FQDN) でAnsible インベントリーファイル を作成している。
- Ansible インベントリーファイルが ~/ MyPlaybooks/ ディレクトリーにある。
手順
~/ MyPlaybooks/ ディレクトリーに移動します。
$ cd ~/MyPlaybooks>/
/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
-
Ansible Playbook ファイル
delegation-absent-copy.yml
を開きます。 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
-
- ファイルを保存します。
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 を参照してください。
19.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 に存在する。
手順
~/ MyPlaybooks/ ディレクトリーに移動します。
$ cd ~/MyPlaybooks/
/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
-
Ansible Playbook ファイル
delegation-member-present-copy.yml
を開きます。 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
-
- ファイルを保存します。
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 を参照してください。
19.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 に存在する。
手順
~/ MyPlaybooks/ ディレクトリーに移動します。
$ cd ~/MyPlaybooks/
/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
-
Ansible Playbook ファイル
delegation-member-absent-copy.yml
を開きます。 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
-
- ファイルを保存します。
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 を参照してください。
第20章 CLI で IdM でのロールベースのアクセス制御の管理
本章では、Identity Management (IdM) にロールベースのアクセス制御を追加し、コマンドラインインターフェース (CLI) で以下の操作を説明します。
20.1. IdM のロールベースのアクセス制御
IdM のロールベースアクセス制御 (RBAC) は、セルフサービス制御および委譲アクセス制御と比較して、非常に異なる種類の権限をユーザーに付与します。
ロールベースのアクセス制御は、以下の 3 つの部分で構成されます。
- パーミッション は、ユーザーの追加または削除、グループの変更、読み取りアクセスの有効化など、特定のタスクを実行する権限を付与します。
- 特権 は、権限を組み合わせます。たとえば、新しいユーザーを追加するために必要なすべてのパーミッションです。
- ロール は、ユーザー、ユーザーグループ、ホスト、またはホストグループに特権のセットを付与します。
20.1.1. IdM のパーミッション
パーミッションは、ロールベースのアクセス制御の最低レベル単位であり、操作が適用される LDAP エントリーとともに操作を定義します。ブロックを構築するのと同様に、パーミッションは必要に応じて多くの権限に割り当てることができます。
1 つ以上の 権限 は許可される操作を定義します。
-
write
-
read
-
search
-
compare
-
add
-
delete
-
all
これらの操作は、3 つの基本的な ターゲット に適用されます。
-
subtree
- ドメイン名( DN) (この DN のサブツリー) -
ターゲットフィルター
: LDAP フィルター -
target
: ワイルドカードを使用したエントリーの指定が可能な DN
また、以下の便利なオプションは対応する属性を設定します。
-
タイプ
: オブジェクトのタイプ (ユーザー、グループなど) (subtree
およびtarget filter
を設定します)。 -
memberof
: グループのメンバー。ターゲットフィルター
を設定します。 -
targetgroup
: 特定のグループの変更 (グループメンバーシップの管理権限の付与など) を変更するアクセスを付与します (ターゲット
を設定します)。
IdM パーミッションを使用すると、どのユーザーがどのオブジェクトにアクセスできるか、さらにこのようなオブジェクトの属性にアクセスできるかどうかを制御できます。IdM を使用すると、個別の属性を許可または拒否したり、ユーザー、グループ、sudo などの特定の IdM 機能を、全匿名ユーザー、全認証済みユーザー、または特定の特権ユーザーグループ限定などと、全体的な表示設定を変更したりできます。
たとえば、このアプローチではパーミッション指定に柔軟性があるので、アクセスが必要な特定のセクションのみにユーザーまたはグループのアクセスを制限し、他のセクションをこれらのユーザーまたはグループには完全に表示されないように設定する場合に、管理者にとって便利です。
パーミッションには他のパーミッションを含めることはできません。
20.1.2. デフォルトの管理パーミッション
管理パーミッションは、IdM にデフォルトで提供されるパーミッションです。これは、以下の相違点で、ユーザーが作成した他のパーミッションのように動作します。
- これらの属性を削除したり、名前、場所、およびターゲット属性を変更したりすることはできません。
これには 3 つの属性セットがあります。
- デフォルト の属性。IdM で管理されているため、ユーザーは変更できません。
- 追加されている 属性 (ユーザーによって追加される追加属性)
- 除外されている 属性 (ユーザーが削除した属性)
管理されているパーミッションは、デフォルトの属性セットと追加されている属性セットには表示されますが、除外されている属性セットには表示されていないすべての属性に適用されます。
管理されているパーミッションを削除することはできませんが、そのバインドタイプをパーミッションに設定し、すべての権限から管理パーミッションを削除すると、そのパーミッションを効果的に無効にできます。
管理されたすべてのパーミッションの名前は System:
から始まります (例: System: Add Sudo rule
または System: Modify Services
)。以前のバージョンの IdM は、デフォルトのパーミッションに異なるスキームを使用していました。たとえば、ユーザーは削除できず、権限に割り当てるしかできませんでした。これらのデフォルトパーミッションのほとんどは管理パーミッションに切り替わっていますが、以下のパーミッションは引き続き以前のスキームを使用します。
- Automember Rebuild メンバーシップタスクの追加
- 設定サブエントリーの追加
- レプリカ合意の追加
- 証明書削除保留
- CA から証明書のステータスを取得します。
- DNA 範囲の読み取り
- DNA 範囲の変更
- PassSync マネージャーの設定の読み取り
- PassSync Manager 設定の変更
- レプリカ合意の読み取り
- レプリカ合意の変更
- レプリカ合意の削除
- LDBM データベース設定の読み取り
- 要求証明書
- CA ACL を無視する要求証明書
- 別のホストからの証明書の要求
- CA からの証明書の取得
- 証明書の取り消し
- IPA 設定の書き込み
コマンドラインから管理パーミッションを変更しようとし、変更できない属性を変更できないと、コマンドは失敗します。Web UI から管理パーミッションを変更しようとすると、変更できない属性が無効になります。
20.1.3. IdM の権限
特権は、ロールに適用されるパーミッションのグループです。
パーミッションは単一の操作を実行する権限を提供しますが、成功するには複数のパーミッションを必要とする特定の IdM タスクがあります。したがって、特権は、特定のタスクを実行するために必要な異なるパーミッションを組み合わせたものです。
たとえば、新しい IdM ユーザーにアカウントを設定するには、以下の権限が必要です。
- 新規ユーザーエントリーの作成
- ユーザーパスワードのリセット
- 新規ユーザーをデフォルトの IPA ユーザーグループに追加
これらの 3 つの低レベルのタスクを、ユーザーの追加 という名前のカスタム特権の形式で、権限がより高いレベルのタスクに組み合わせることで、システム管理者はロールを管理しやすくなります。IdM には、既にいくつかのデフォルト特権が含まれています。ユーザーとユーザーグループとは別に、権限はホストおよびホストグループ、およびネットワークサービスにも割り当てられます。これにより、特定のネットワークサービスを使用するホストセットのユーザーセットによって、操作をきめ細かく制御できます。
特権には、他の特権を含めることはできません。
20.1.4. IdM のロール
ロールは、ロールに指定したユーザーが所有する権限の一覧です。
実際には、パーミッションでは、指定の低階層のタスク (ユーザーエントリーの作成、グループへのエントリーの追加など)を実行する権限を付与し、特権では、高階層のタスク (指定のグループへの新規ユーザーの作成など) に必要なこれらのパーミッション 1 つ以上を組み合わせます。ロールは必要に応じて、管理者ロールでユーザーの追加、変更、削除ができるなど、特権をまとめます。
ロールは、許可されたアクションを分類するために使用されます。ロールは、特権昇格されないようにしたり、特権の分離を実装するツールとしては使用しません。
ロールに他のロールを含めることはできません。
20.1.5. Identity Management で事前定義されたロール
Red Hat Identity Management は、以下の事前定義済みのロールを提供します。
表20.1 Identity Management の定義済みロール
ロール | 特権 | 説明 |
---|---|---|
登録管理者 | ホストの登録 | クライアントまたはホスト、登録を行います。 |
helpdesk | Modify Users、Reset passwords、Modify Group メンバーシップ | 簡単なユーザー管理タスクの実行 |
IT セキュリティースペシャリスト | Netgroups 管理者、HBAC 管理者、Sudo 管理者 | ホストベースのアクセス制御、sudo ルールなどのセキュリティーポリシーの管理 |
IT スペシャリスト | ホスト管理者、ホストグループ管理者、サービス管理者、自動マウント管理者 | ホストの管理を行います。 |
セキュリティーアーキテクト | 委譲管理者、レプリケーション管理者、書き込み IPA 設定、パスワードポリシー管理者 | Identity Management 環境の管理、信頼の作成、レプリカ合意の作成 |
ユーザー管理者 | ユーザー管理者、グループ管理者、ステージユーザー管理者 | ユーザーおよびグループの作成を行います。 |
20.2. CLI での IdM パーミッションの管理
本セクションでは、コマンドラインインターフェース (CLI) を使用して Identity Management (IdM) パーミッションを管理する方法を説明します。
前提条件
- IdM または ユーザー管理者 ロールを管理する管理者権限。
- アクティブな Kerberos チケット。詳細は、Using kinit to log in to IdM manually を参照してください。
手順
ipa permission-add
コマンドを使用して、新しいパーミッションエントリーを作成します。
たとえば、dns admin という名前のパーミッションを追加するには、次のコマンドを実行します。$ ipa permission-add "dns admin"
以下のオプションでパーミッションのプロパティーを指定します。
--bindtype
は、バインドルールの種別を指定します。このオプションは、all
引数、anonymous
引数、およびpermission
引数を受け入れます。permission
バインドタイプは、ロール経由でこのパーミッションを付与されたユーザーのみがこれを実行できることを意味します。
以下に例を示します。$ ipa permission-add "dns admin" --bindtype=all
--bindtype
を指定しないと、permission
がデフォルト値になります。注記デフォルト以外のバインドルールタイプを持つパーミッションを権限に追加することはできません。また、デフォルト以外のバインドルールタイプに対する特権にあるパーミッションを設定することはできません。
--right
は、パーミッションによって付与される権限を一覧表示します。これは、非推奨の--permissions
オプションに代わるものです。使用できる値はadd
、delete
、read
、search
、compare
、write
、all
になります。複数の属性を設定するには、複数の
--right
オプションを使用するか、中括弧内にコンマ区切りリストを使用します。以下に例を示します。$ ipa permission-add "dns admin" --right=read --right=write
$ ipa permission-add "dns admin" --right={read,write}
注記add
およびdelete
はエントリーレベルの操作 (ユーザーの削除、グループの追加など) ですが、read
、search
、compare
、write
はより属性レベルです (userCertificate
に書き込むことはできますが、userPassword
を読み込むことはできません)。--attrs
は、パーミッションが付与される属性の一覧を提供します。
複数の属性を設定するには、複数の--attrs
オプションを使用するか、オプションを中括弧内にコンマ区切りリストで一覧表示します。以下に例を示します。$ ipa permission-add "dns admin" --attrs=description --attrs=automountKey
$ ipa permission-add "dns admin" --attrs={description,automountKey}
--attrs
で提供される属性が存在し、指定のオブジェクトタイプに許可される属性である必要があります。指定しないと、コマンドがスキーマ構文エラーで失敗します。--type
は、ユーザー、ホスト、サービスなどのパーミッションが適用されるエントリーオブジェクトタイプを定義します。各タイプには、許可された属性の独自のセットがあります。
以下に例を示します。$ ipa permission-add "manage service" --right=all --type=service --attrs=krbprincipalkey --attrs=krbprincipalname --attrs=managedby
--subtree
はサブツリーエントリーを提供します。フィルターはこのサブツリーエントリーの下にあるすべてのエントリーをターゲットにします。既存のサブツリーエントリーを指定します。--subtree
はワイルドカードや存在しないドメイン名 (DN) を受け入れません。ディレクトリーに DN を追加します。
IdM は簡素化されたフラットディレクトリーツリー構造を使用しているため、--subtree
を使用して自動マウントの場所 (他の設定のコンテナーまたは親エントリー) などの一部のエントリーをターゲットにすることができます。以下に例を示します。$ ipa permission-add "manage automount locations" --subtree="ldap://ldap.example.com:389/cn=automount,dc=example,dc=com" --right=write --attrs=automountmapname --attrs=automountkey --attrs=automountInformation
注記--type
オプションおよび--subtree
オプションは相互に排他的です。--subtree
の簡素化として--type
のフィルターを組み込むことができます (これにより、管理者の作業が簡単になります)。--filter
は LDAP フィルターを使用して、パーミッションが適用されるエントリーを特定します。
IdM は、指定のフィルターの有効性を自動的に確認します。このフィルターには、有効な LDAP フィルターを使用できます。以下に例を示します。$ ipa permission-add "manage Windows groups" --filter="(!(objectclass=posixgroup))" --right=write --attrs=description
--memberof
は、グループが存在することを確認した後に、指定したグループのメンバーにターゲットフィルターを設定します。たとえば、このパーミッションを持つユーザーを許可するには、エンジニアグループのメンバーのログインシェルを変更します。$ ipa permission-add ManageShell --right="write" --type=user --attr=loginshell --memberof=engineers
--targetgroup
は、グループが存在することを確認した後に、ターゲットを指定されたユーザーグループに設定します。たとえば、パーミッションを持つものに、(メンバーを追加または削除できるように) エンジニアグループに member 属性を書き込むには、次のコマンドを実行します。$ ipa permission-add ManageMembers --right="write" --subtree=cn=groups,cn=accounts,dc=example,dc=test --attr=member --targetgroup=engineers
必要に応じて、ターゲットドメイン名 (DN) を指定できます。
-
--target
は、パーミッションを適用する DN を指定します。ワイルドカードが許可されます。 -
--targetto
は、エントリーを移動できる DN サブツリーを指定します。 -
--targetfrom
は、エントリーを移動できる DN サブツリーを指定します。
-
20.3. 既存のパーミッションのコマンドオプション
必要に応じて、既存のパーミッションを変更するには、以下のバリアントを使用します。
-
既存のパーミッションを編集するには、
ipa permission-mod
コマンドを使用します。パーミッションの追加と同じコマンドオプションを使用できます。 -
既存のパーミッションを見つけるには、
ipa permission-find
コマンドを使用します。パーミッションの追加と同じコマンドオプションを使用できます。 特定のパーミッションを表示するには、
ipa permission-show
コマンドを使用します。--raw
引数は、生成される未編集の 389-ds ACI を表示します。以下に例を示します。$ ipa permission-show <permission> --raw
-
ipa permission-del
コマンドは、パーミッションを完全に削除します。
関連情報
-
ipa
の man ページを参照してください。 -
ipa help
コマンドを参照してください。
20.4. CLI での IdM 権限の管理
本セクションでは、コマンドラインインターフェース (CLI) を使用して Identity Management (IdM) 権限を管理する方法を説明します。
前提条件
- IdM または ユーザー管理者 ロールを管理する管理者権限。
- アクティブな Kerberos チケット。詳細は、「 kinit を使用した IdM の手動ログイン」を 参照してください。
- 既存のパーミッション。パーミッションの詳細は、「CLI での IdM パーミッションの管理」を参照してください。
手順
ipa privilege-add
コマンドを使用して、権限エントリーを追加します。
たとえば、説明付きの managing filesystems という名前を追加するには、次のコマンドを実行します。$ ipa privilege-add "managing filesystems" --desc="for filesystems"
privilege-add-permission
コマンドを使用して必要なパーミッションを特権グループに割り当てます。
たとえば、パーミッション managing automount および managing ftp services を、managing filesystems 権限に追加するには、次のコマンドを実行します。$ ipa privilege-add-permission "managing filesystems" --permissions="managing automount" --permissions="managing ftp services"
20.5. 既存の特権のコマンドオプション
必要に応じて、既存の権限を変更するには、以下のバリアントを使用します。
-
既存の権限を変更するには、
ipa privilege-mod
コマンドを使用します。 -
既存の権限を見つけるには、
ipa privilege-find
コマンドを使用します。 -
特定の特権を表示するには、
ipa privilege-show
コマンドを使用します。 -
ipa privilege-remove-permission
コマンドは、特権から 1 つ以上のパーミッションを削除します。 -
ipa privilege-del
コマンドは、権限を完全に削除します。
関連情報
-
ipa
の man ページを参照してください。 -
ipa help
コマンドを参照してください。
20.6. CLI での IdM ロールの管理
本セクションでは、コマンドラインインターフェース (CLI) を使用して Identity Management (IdM) ロールを管理する方法を説明します。
前提条件
- IdM または ユーザー管理者 ロールを管理する管理者権限。
- アクティブな Kerberos チケット。詳細は、Using kinit to log in to IdM manually を参照してください。
- 既存の権限。権限の詳細は、「CLI での IdM 権限の管理」を参照してください。
手順
ipa role-add
コマンドを使用して、新規ロールエントリーを追加します。$ ipa role-add --desc="User Administrator" useradmin ------------------------ Added role "useradmin" ------------------------ Role name: useradmin Description: User Administrator
ipa role-add-privilege
コマンドを使用して、必要な権限をロールに追加します。$ ipa role-add-privilege --privileges="user administrators" useradmin Role name: useradmin Description: User Administrator Privileges: user administrators ---------------------------- Number of privileges added 1 ----------------------------
ipa role-add-member
コマンドを使用して、必要なメンバーをロールに追加します。許可されるメンバータイプ: ユーザー、グループ、ホスト、およびホストグループ。
たとえば、useradmins という名前のグループを、以前に作成した useradmin ロールに追加するには、次のコマンドを実行します。$ ipa role-add-member --groups=useradmins useradmin Role name: useradmin Description: User Administrator Member groups: useradmins Privileges: user administrators ------------------------- Number of members added 1 -------------------------
20.7. 既存ロールのコマンドオプション
必要に応じて、既存のロールを変更するには、以下のバリアントを使用します。
-
既存のロールを変更するには、
ipa role-mod
コマンドを使用します。 -
既存のロールを見つけるには、
ipa role-find
コマンドを使用します。 -
特定のロールを表示するには、
ipa role-show
コマンドを使用します。 -
ロールからメンバーを削除するには、
ipa role-remove-member
コマンドを使用します。 -
ipa role-remove-privilege
コマンドは、ロールから 1 つ以上の権限を削除します。 -
ipa role-del
コマンドは、ロールを完全に削除します。
関連情報
-
ipa
man ページを参照してください。 -
ipa help
コマンドを参照してください。
第21章 IdM Web UI を使用したロールベースのアクセス制御の管理
本章では、Identity Management (IdM) でロールベースのアクセス制御を紹介し、Web インターフェース (Web UI) で以下の操作を説明します。
21.1. IdM のロールベースのアクセス制御
IdM のロールベースアクセス制御 (RBAC) は、セルフサービス制御および委譲アクセス制御と比較して、非常に異なる種類の権限をユーザーに付与します。
ロールベースのアクセス制御は、以下の 3 つの部分で構成されます。
- パーミッション は、ユーザーの追加または削除、グループの変更、読み取りアクセスの有効化など、特定のタスクを実行する権限を付与します。
- 特権 は、権限を組み合わせます。たとえば、新しいユーザーを追加するために必要なすべてのパーミッションです。
- ロール は、ユーザー、ユーザーグループ、ホスト、またはホストグループに特権のセットを付与します。
21.1.1. IdM のパーミッション
パーミッションは、ロールベースのアクセス制御の最低レベル単位であり、操作が適用される LDAP エントリーとともに操作を定義します。ブロックを構築するのと同様に、パーミッションは必要に応じて多くの権限に割り当てることができます。
1 つ以上の 権限 は許可される操作を定義します。
-
write
-
read
-
search
-
compare
-
add
-
delete
-
all
これらの操作は、3 つの基本的な ターゲット に適用されます。
-
subtree
- ドメイン名( DN) (この DN のサブツリー) -
ターゲットフィルター
: LDAP フィルター -
target
: ワイルドカードを使用したエントリーの指定が可能な DN
また、以下の便利なオプションは対応する属性を設定します。
-
タイプ
: オブジェクトのタイプ (ユーザー、グループなど) (subtree
およびtarget filter
を設定します)。 -
memberof
: グループのメンバー。ターゲットフィルター
を設定します。 -
targetgroup
: 特定のグループの変更 (グループメンバーシップの管理権限の付与など) を変更するアクセスを付与します (ターゲット
を設定します)。
IdM パーミッションを使用すると、どのユーザーがどのオブジェクトにアクセスできるか、さらにこのようなオブジェクトの属性にアクセスできるかどうかを制御できます。IdM を使用すると、個別の属性を許可または拒否したり、ユーザー、グループ、sudo などの特定の IdM 機能を、全匿名ユーザー、全認証済みユーザー、または特定の特権ユーザーグループ限定などと、全体的な表示設定を変更したりできます。
たとえば、このアプローチではパーミッション指定に柔軟性があるので、アクセスが必要な特定のセクションのみにユーザーまたはグループのアクセスを制限し、他のセクションをこれらのユーザーまたはグループには完全に表示されないように設定する場合に、管理者にとって便利です。
パーミッションには他のパーミッションを含めることはできません。
21.1.2. デフォルトの管理パーミッション
管理パーミッションは、IdM にデフォルトで提供されるパーミッションです。これは、以下の相違点で、ユーザーが作成した他のパーミッションのように動作します。
- これらの属性を削除したり、名前、場所、およびターゲット属性を変更したりすることはできません。
これには 3 つの属性セットがあります。
- デフォルト の属性。IdM で管理されているため、ユーザーは変更できません。
- 追加されている 属性 (ユーザーによって追加される追加属性)
- 除外されている 属性 (ユーザーが削除した属性)
管理されているパーミッションは、デフォルトの属性セットと追加されている属性セットには表示されますが、除外されている属性セットには表示されていないすべての属性に適用されます。
管理されているパーミッションを削除することはできませんが、そのバインドタイプをパーミッションに設定し、すべての権限から管理パーミッションを削除すると、そのパーミッションを効果的に無効にできます。
管理されたすべてのパーミッションの名前は System:
から始まります (例: System: Add Sudo rule
または System: Modify Services
)。以前のバージョンの IdM は、デフォルトのパーミッションに異なるスキームを使用していました。たとえば、ユーザーは削除できず、権限に割り当てるしかできませんでした。これらのデフォルトパーミッションのほとんどは管理パーミッションに切り替わっていますが、以下のパーミッションは引き続き以前のスキームを使用します。
- Automember Rebuild メンバーシップタスクの追加
- 設定サブエントリーの追加
- レプリカ合意の追加
- 証明書削除保留
- CA から証明書のステータスを取得します。
- DNA 範囲の読み取り
- DNA 範囲の変更
- PassSync マネージャーの設定の読み取り
- PassSync Manager 設定の変更
- レプリカ合意の読み取り
- レプリカ合意の変更
- レプリカ合意の削除
- LDBM データベース設定の読み取り
- 要求証明書
- CA ACL を無視する要求証明書
- 別のホストからの証明書の要求
- CA からの証明書の取得
- 証明書の取り消し
- IPA 設定の書き込み
コマンドラインから管理パーミッションを変更しようとし、変更できない属性を変更できないと、コマンドは失敗します。Web UI から管理パーミッションを変更しようとすると、変更できない属性が無効になります。
21.1.3. IdM の権限
特権は、ロールに適用されるパーミッションのグループです。
パーミッションは単一の操作を実行する権限を提供しますが、成功するには複数のパーミッションを必要とする特定の IdM タスクがあります。したがって、特権は、特定のタスクを実行するために必要な異なるパーミッションを組み合わせたものです。
たとえば、新しい IdM ユーザーにアカウントを設定するには、以下の権限が必要です。
- 新規ユーザーエントリーの作成
- ユーザーパスワードのリセット
- 新規ユーザーをデフォルトの IPA ユーザーグループに追加
これらの 3 つの低レベルのタスクを、ユーザーの追加 という名前のカスタム特権の形式で、権限がより高いレベルのタスクに組み合わせることで、システム管理者はロールを管理しやすくなります。IdM には、既にいくつかのデフォルト特権が含まれています。ユーザーとユーザーグループとは別に、権限はホストおよびホストグループ、およびネットワークサービスにも割り当てられます。これにより、特定のネットワークサービスを使用するホストセットのユーザーセットによって、操作をきめ細かく制御できます。
特権には、他の特権を含めることはできません。
21.1.4. IdM のロール
ロールは、ロールに指定したユーザーが所有する権限の一覧です。
実際には、パーミッションでは、指定の低階層のタスク (ユーザーエントリーの作成、グループへのエントリーの追加など)を実行する権限を付与し、特権では、高階層のタスク (指定のグループへの新規ユーザーの作成など) に必要なこれらのパーミッション 1 つ以上を組み合わせます。ロールは必要に応じて、管理者ロールでユーザーの追加、変更、削除ができるなど、特権をまとめます。
ロールは、許可されたアクションを分類するために使用されます。ロールは、特権昇格されないようにしたり、特権の分離を実装するツールとしては使用しません。
ロールに他のロールを含めることはできません。
21.1.5. Identity Management で事前定義されたロール
Red Hat Identity Management は、以下の事前定義済みのロールを提供します。
表21.1 Identity Management の定義済みロール
ロール | 特権 | 説明 |
---|---|---|
登録管理者 | ホストの登録 | クライアントまたはホスト、登録を行います。 |
helpdesk | Modify Users、Reset passwords、Modify Group メンバーシップ | 簡単なユーザー管理タスクの実行 |
IT セキュリティースペシャリスト | Netgroups 管理者、HBAC 管理者、Sudo 管理者 | ホストベースのアクセス制御、sudo ルールなどのセキュリティーポリシーの管理 |
IT スペシャリスト | ホスト管理者、ホストグループ管理者、サービス管理者、自動マウント管理者 | ホストの管理を行います。 |
セキュリティーアーキテクト | 委譲管理者、レプリケーション管理者、書き込み IPA 設定、パスワードポリシー管理者 | Identity Management 環境の管理、信頼の作成、レプリカ合意の作成 |
ユーザー管理者 | ユーザー管理者、グループ管理者、ステージユーザー管理者 | ユーザーおよびグループの作成を行います。 |
21.2. IdM Web UI でのパーミッションの管理
本セクションでは、Web インターフェース (IdM Web UI) を使用して、Identity Management (IdM) でパーミッションを管理する方法を説明します。
前提条件
- IdM または ユーザー管理者 ロールを管理する管理者権限。
- IdM Web UI にログインしている。詳細は「Web ブラウザーで IdM Web UI へのアクセス」を 参照してください。
手順
新しいパーミッションを追加するには、IPA Server タブで ロールベースのアクセス制御 サブメニューを開き、パーミッション を選択します。
パーミッションの一覧が開きます。パーミッションの一覧の上部にある Add ボタンをクリックします。
Add Permission フォームが開きます。新しいパーミッションの名前を指定し、そのプロパティーを適宜定義します。
適切なバインドルールタイプを選択します。
- permission はデフォルトのパーミッションタイプで、権限およびロール経由でアクセスを付与します。
- all は、パーミッションをすべての認証ユーザーに適用することを指定します。
anonymous は、認証されていないユーザーを含む、パーミッションがすべてのユーザーに適用されることを指定します。
注記デフォルト以外のバインドルールタイプを持つパーミッションを権限に追加することはできません。また、デフォルト以外のバインドルールタイプに対する特権にあるパーミッションを設定することはできません。
- 権限が付与されている権限で、このパーミッションで 付与する権限 を選択します。
パーミッションのターゲットエントリーを識別する方法を定義します。
- タイプ は、ユーザー、ホスト、またはサービスなどのエントリータイプを指定します。Type 設定の値を選択すると、そのエントリータイプのこの ACI からアクセス可能なすべての属性の一覧が Effective 属性 に表示されます。Type を定義すると、Subtree および Target DN が事前定義された値のいずれかに設定されます。
-
Subtree (必須) はサブツリーエントリーを指定します。このサブツリーエントリーの下にあるすべてのエントリーがターゲットになります。Subtree はワイルドカードや存在しないドメイン名 (DN) を許可しないため、既存のサブツリーエントリーを指定します。例:
cn=automount,dc=example,dc=com
-
追加のターゲットフィルター は LDAP フィルターを使用して、パーミッションが適用されるエントリーを特定します。フィルターには任意の有効な LDAP フィルターを使用できます (たとえば、
(!(objectclass=posixgroup))
) IdM は指定のフィルターの有効性を自動的にチェックします。無効なフィルターを入力すると、パーミッションを保存しようとすると、IdM はこれについて警告します。 -
ターゲット DN はドメイン名 (DN) を指定し、ワイルドカードを受け入れます。例:
uid=*,cn=users,cn=accounts,dc=com
- グループのメンバー は、指定したグループのメンバーにターゲットフィルターを設定します。フィルター設定を指定し、追加 をクリックすると、IdM がフィルターを検証します。すべてのパーミッション設定が正しい場合は、IdM が検索を実行します。パーミッション設定の一部が正しくない場合、IdM は、どの設定が正しく設定されているかを示すメッセージが表示されます。
パーミッションに属性を追加します。
- Type を設定する場合は、利用可能な ACI 属性の一覧から 有効な属性 を選択します。
Type を使用しない場合は、有効な属性 フィールドに属性を手動で書き込みます。一度に 1 つの属性を追加します。複数の属性を追加するには、Add をクリックして別の入力フィールドを追加します。
重要パーミッションの属性を設定しないと、パーミッションはデフォルトですべての属性が含まれます。
フォーム下部の Add ボタンでパーミッションの追加を終了します。
- 追加 ボタンをクリックしてパーミッションを保存し、パーミッションの一覧に戻ります。
- パーミッションを保存し、Add and Add another ボタンをクリックして、同じフォームに追加パーミッションを継続できます。
- Add and Edit ボタンを使用すると、新たに作成されたパーミッションを保存して編集を継続できます。
- オプション。また、パーミッションの一覧から名前をクリックして、パーミッション権限 ページを表示することで、既存のパーミッションのプロパティーを編集することもできます。
オプション。既存のパーミッションを削除する必要がある場合は、一覧で名前の横にあるチェックボックスにチェックマークを入れて、削除 ボタンをクリックして、パーミッションの削除 ダイアログを表示します。
注記デフォルトの管理パーミッションに対する操作は制限されています。変更できない属性は IdM Web UI で無効になり、管理パーミッションを完全に削除することはできません。
ただし、すべての特権から管理されているパーミッションを削除して、パーミッションにバインドタイプが設定されている管理されているパーミッションを効果的に無効にすることができます。
たとえば、パーミッションを持つものに、(メンバーを追加または削除できるように) エンジニアグループに member 属性を書き込むには、次のコマンドを実行します。
21.3. IdM WebUI での権限の管理
本セクションでは、Web インターフェース (IdM Web UI) を使用して IdM の権限を管理する方法を説明します。
前提条件
- IdM または ユーザー管理者 ロールを管理する管理者権限。
- IdM Web UI にログインしている。詳細は「Web ブラウザーで IdM Web UI へのアクセス」を 参照してください。
- 既存のパーミッション。パーミッションの詳細は、「IdM Web UI でのパーミッションの管理」を参照してください。
手順
新しい権限を追加するには、IPA Server タブで ロールベースのアクセス制御 サブメニューを開き、特権 を選択します。
特権の一覧が開きます。特権一覧の上部にある Add ボタンをクリックします。
Add Privilege フォームが開きます。特権の名前と説明を入力します。
- 新しい特権を保存し、権限設定ページに移動し、パーミッションを追加するには、Add and Edit ボタンをクリックします。
- 特権一覧の権限名をクリックして、特権のプロパティーを編集します。特権設定ページが開きます。
Permissions タブには、選択した権限に含まれるパーミッションの一覧が表示されます。一覧上部の Add ボタンをクリックして、権限を特権に追加します。
追加する各パーミッションの名前の横にあるチェックボックスにチェックマークを入れ、> ボタンを使用してパーミッションを Prospective 列に移動します。
- Add ボタンをクリックして確定します。
- オプション。パーミッションを削除する必要がある場合は、関連するパーミッションの横にあるチェックボックス (パーミッションからの権限の削除ダイアログ) を表示したら、削除 ボタンをクリックします。
- オプション。既存の特権を削除する必要がある場合は、一覧で名前の横にあるチェックボックス (Remove privileges ダイアログが開きます) の横にあるチェックボックスを閉じたら、Delete ボタンをクリックします。
21.4. IdM Web UI でのロールの管理
本セクションでは、Web インターフェース (IdM Web UI) を使用して、Identity Management (IdM) のロールを管理する方法を説明します。
前提条件
- IdM または ユーザー管理者 ロールを管理する管理者権限。
- IdM Web UI にログインしている。詳細は「Web ブラウザーで IdM Web UI へのアクセス」を 参照してください。
- 既存の権限。権限の詳細は、「IdM Web UI で権限の管理」を参照してください。
手順
新規ロールを追加するには、IPA Server タブの Role-Based Access Control サブメニューを開き、Roles を選択します。
ロールの一覧が開きます。ロールベースのアクセス制御手順のリストの上部にある Add ボタンをクリックします。
Add Role フォームが開きます。ロール名と説明を入力します。
- Add and Edit ボタンをクリックして新規ロールを保存し、ロール設定ページに移動し、権限およびユーザーを追加します。
- ロール一覧のロール名をクリックして、ロールのプロパティーを編集します。ロール設定ページが開きます。
関連するリストの上部にある Add ボタンをクリックして、Users、Users Groups、Hosts、Host Groups、または Services タブを使用してメンバーを追加します。
開いているウィンドウで、左側のメンバーを選択し、> ボタンを使用してそれらを Prospective 列に移動します。
Privileges タブの上部にある Add をクリックします。
左側の権限を選択し、> ボタンを使用してそれらを Prospective 列に移動します。
- Add ボタンをクリックして保存します。
- オプション。ロールから特権またはメンバーを削除する必要がある場合は、削除するエンティティーの名前の横にあるチェックボックスにチェックマークを入れてから Delete ボタンをクリックします。ダイアログが開きます。
- オプション。既存のロールを削除する必要がある場合は、一覧で名前の横にあるチェックボックスを編集した後に Delete ボタンをクリックすると、Remove roles ダイアログが表示します。
第22章 Ansible Playbook を使用して IdM を管理する環境の準備
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
権限があれば、ipaserver
、ipareplica
、ipaclient
、および 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
のパスワードを把握している。
手順
Ansible 設定および Playbook のディレクトリーをホームディレクトリーに作成します。
$ mkdir ~/MyPlaybooks/
~/MyPlaybooks/ ディレクトリーに移動します。
$ cd ~/MyPlaybooks
~/MyPlaybooks/ansible.cfg ファイルを以下の内容で作成します。
[defaults] inventory = /home/your_username/MyPlaybooks/inventory [privilege_escalation] become=True
~/MyPlaybooks/inventory ファイルを以下の内容で作成します。
[eu] server.idm.example.com [us] replica.idm.example.com [ipaserver:children] eu us
この設定は、これらの場所にあるホストの 2 つのホストグループ (eu と us) を定義します。さらに、この設定は、eu および us グループのすべてのホストを含む ipaserver ホストグループを定義します。
(必要に応じて) SSH 公開鍵および秘密鍵を作成します。テスト環境でのアクセスを簡素化するには、秘密鍵にパスワードを設定しないでください。
$ ssh-keygen
各管理対象ノードの IdM
admin
アカウントに SSH 公開鍵をコピーします。$ ssh-copy-id admin@server.idm.example.com $ ssh-copy-id admin@replica.idm.example.com
これらのコマンドでは、IdM
管理者
パスワードを入力します。
関連情報
- Ansible Playbook を使用した Identity Management サーバーのインストール を 参照してください。
- インベントリーの構築方法 を参照してください。
第23章 Ansible Playbook を使用した IdM でのロールベースアクセス制御の管理
ロールベースアクセス制御 (RBAC) は、ロールおよび権限関連を定義する、ポリシーに依存しないアクセス制御メカニズムです。Identity Management (IdM) の RBAC のコンポーネントは、ロール、権限、パーミッションです。
- パーミッション は、ユーザーの追加または削除、グループの変更、読み取りアクセスの有効化など、特定のタスクを実行する権限を付与します。
- 特権 は、権限を組み合わせます。たとえば、新しいユーザーを追加するために必要なすべてのパーミッションです。
- ロール は、ユーザー、ユーザーグループ、ホスト、またはホストグループに特権のセットを付与します。
特に大企業では、RBAC を使用すると、責任の領域を個別に設定する階層管理システムを作成できます。
本章では、Ansible Playbook を使用した RBAC の管理時に行う以下の操作について説明します。
- Ansible を使用して特権のある IdM RBAC ロールを存在させる手順
- Ansible を使用して IdM RBAC ロールを設定しないようにする手順
- Ansible を使用して、ユーザーグループに IdM RBAC ロールを割り当てる手順
- Ansible を使用して特定のユーザーに IdM RBAC ロールが割り当てられないようにする手順
- Ansible を使用してサービスを IdM RBAC ロールに所属させるように設定する手順
- Ansible を使用してホストを IdM RBAC ロールに所属させるように設定する手順
- Ansible を使用してホストグループを IdM RBAC ロールに所属させるように設定する手順
23.1. IdM のパーミッション
パーミッションは、ロールベースのアクセス制御の最低レベル単位であり、操作が適用される LDAP エントリーとともに操作を定義します。ブロックを構築するのと同様に、パーミッションは必要に応じて多くの権限に割り当てることができます。
1 つ以上の 権限 は許可される操作を定義します。
-
write
-
read
-
search
-
compare
-
add
-
delete
-
all
これらの操作は、3 つの基本的な ターゲット に適用されます。
-
subtree
- ドメイン名( DN) (この DN のサブツリー) -
ターゲットフィルター
: LDAP フィルター -
target
: ワイルドカードを使用したエントリーの指定が可能な DN
また、以下の便利なオプションは対応する属性を設定します。
-
タイプ
: オブジェクトのタイプ (ユーザー、グループなど) (subtree
およびtarget filter
を設定します)。 -
memberof
: グループのメンバー。ターゲットフィルター
を設定します。 -
targetgroup
: 特定のグループの変更 (グループメンバーシップの管理権限の付与など) を変更するアクセスを付与します (ターゲット
を設定します)。
IdM パーミッションを使用すると、どのユーザーがどのオブジェクトにアクセスできるか、さらにこのようなオブジェクトの属性にアクセスできるかどうかを制御できます。IdM を使用すると、個別の属性を許可または拒否したり、ユーザー、グループ、sudo などの特定の IdM 機能を、全匿名ユーザー、全認証済みユーザー、または特定の特権ユーザーグループ限定などと、全体的な表示設定を変更したりできます。
たとえば、このアプローチではパーミッション指定に柔軟性があるので、アクセスが必要な特定のセクションのみにユーザーまたはグループのアクセスを制限し、他のセクションをこれらのユーザーまたはグループには完全に表示されないように設定する場合に、管理者にとって便利です。
パーミッションには他のパーミッションを含めることはできません。
23.2. デフォルトの管理パーミッション
管理パーミッションは、IdM にデフォルトで提供されるパーミッションです。これは、以下の相違点で、ユーザーが作成した他のパーミッションのように動作します。
- これらの属性を削除したり、名前、場所、およびターゲット属性を変更したりすることはできません。
これには 3 つの属性セットがあります。
- デフォルト の属性。IdM で管理されているため、ユーザーは変更できません。
- 追加されている 属性 (ユーザーによって追加される追加属性)
- 除外されている 属性 (ユーザーが削除した属性)
管理されているパーミッションは、デフォルトの属性セットと追加されている属性セットには表示されますが、除外されている属性セットには表示されていないすべての属性に適用されます。
管理されているパーミッションを削除することはできませんが、そのバインドタイプをパーミッションに設定し、すべての権限から管理パーミッションを削除すると、そのパーミッションを効果的に無効にできます。
管理されたすべてのパーミッションの名前は System:
から始まります (例: System: Add Sudo rule
または System: Modify Services
)。以前のバージョンの IdM は、デフォルトのパーミッションに異なるスキームを使用していました。たとえば、ユーザーは削除できず、権限に割り当てるしかできませんでした。これらのデフォルトパーミッションのほとんどは管理パーミッションに切り替わっていますが、以下のパーミッションは引き続き以前のスキームを使用します。
- Automember Rebuild メンバーシップタスクの追加
- 設定サブエントリーの追加
- レプリカ合意の追加
- 証明書削除保留
- CA から証明書のステータスを取得します。
- DNA 範囲の読み取り
- DNA 範囲の変更
- PassSync マネージャーの設定の読み取り
- PassSync Manager 設定の変更
- レプリカ合意の読み取り
- レプリカ合意の変更
- レプリカ合意の削除
- LDBM データベース設定の読み取り
- 要求証明書
- CA ACL を無視する要求証明書
- 別のホストからの証明書の要求
- CA からの証明書の取得
- 証明書の取り消し
- IPA 設定の書き込み
コマンドラインから管理パーミッションを変更しようとし、変更できない属性を変更できないと、コマンドは失敗します。Web UI から管理パーミッションを変更しようとすると、変更できない属性が無効になります。
23.3. IdM の権限
特権は、ロールに適用されるパーミッションのグループです。
パーミッションは単一の操作を実行する権限を提供しますが、成功するには複数のパーミッションを必要とする特定の IdM タスクがあります。したがって、特権は、特定のタスクを実行するために必要な異なるパーミッションを組み合わせたものです。
たとえば、新しい IdM ユーザーにアカウントを設定するには、以下の権限が必要です。
- 新規ユーザーエントリーの作成
- ユーザーパスワードのリセット
- 新規ユーザーをデフォルトの IPA ユーザーグループに追加
これらの 3 つの低レベルのタスクを、ユーザーの追加 という名前のカスタム特権の形式で、権限がより高いレベルのタスクに組み合わせることで、システム管理者はロールを管理しやすくなります。IdM には、既にいくつかのデフォルト特権が含まれています。ユーザーとユーザーグループとは別に、権限はホストおよびホストグループ、およびネットワークサービスにも割り当てられます。これにより、特定のネットワークサービスを使用するホストセットのユーザーセットによって、操作をきめ細かく制御できます。
特権には、他の特権を含めることはできません。
23.4. IdM のロール
ロールは、ロールに指定したユーザーが所有する権限の一覧です。
実際には、パーミッションでは、指定の低階層のタスク (ユーザーエントリーの作成、グループへのエントリーの追加など)を実行する権限を付与し、特権では、高階層のタスク (指定のグループへの新規ユーザーの作成など) に必要なこれらのパーミッション 1 つ以上を組み合わせます。ロールは必要に応じて、管理者ロールでユーザーの追加、変更、削除ができるなど、特権をまとめます。
ロールは、許可されたアクションを分類するために使用されます。ロールは、特権昇格されないようにしたり、特権の分離を実装するツールとしては使用しません。
ロールに他のロールを含めることはできません。
23.5. Identity Management で事前定義されたロール
Red Hat Identity Management は、以下の事前定義済みのロールを提供します。
表23.1 Identity Management の定義済みロール
ロール | 特権 | 説明 |
---|---|---|
登録管理者 | ホストの登録 | クライアントまたはホスト、登録を行います。 |
helpdesk | Modify Users、Reset passwords、Modify Group メンバーシップ | 簡単なユーザー管理タスクの実行 |
IT セキュリティースペシャリスト | Netgroups 管理者、HBAC 管理者、Sudo 管理者 | ホストベースのアクセス制御、sudo ルールなどのセキュリティーポリシーの管理 |
IT スペシャリスト | ホスト管理者、ホストグループ管理者、サービス管理者、自動マウント管理者 | ホストの管理を行います。 |
セキュリティーアーキテクト | 委譲管理者、レプリケーション管理者、書き込み IPA 設定、パスワードポリシー管理者 | Identity Management 環境の管理、信頼の作成、レプリカ合意の作成 |
ユーザー管理者 | ユーザー管理者、グループ管理者、ステージユーザー管理者 | ユーザーおよびグループの作成を行います。 |
23.6. Ansible を使用して特権のある IdM RBAC ロールを存在させる手順
デフォルトのロール以外で、ロールベースのアクセス制御 (RBAC) を使用して Identity Management (IdM) のリソースを詳細にわたり制御するには、カスタムロールを作成します。
以下の手順では、Ansible Playbook を使用して、新しい IdM カスタムロールの特権を定義し、その存在を確認する方法を説明します。この例では、新しい user_and_host_administrator ロールには、デフォルトで IdM で存在する以下の特権を一意に組み合わせたものが含まれます。
-
Group Administrators
-
User Administrators
-
Stage User Administrators
-
Group Administrators
前提条件
- IdM 管理者パスワードを把握している。
- Ansible コントローラーに ansible-freeipa パッケージがインストールされている。
- 設定を行う IdM サーバーの完全修飾ドメイン名 (FQDN) で Ansible インベントリーファイル を作成している。
- Ansible インベントリーファイルが ~/ <MyPlaybooks>/ ディレクトリーにある。
手順
~/<MyPlaybooks>/ ディレクトリーに移動します。
$ cd ~/<MyPlaybooks>/
/usr/share/doc/ansible-freeipa/playbooks/role/
にあるrole-member-user-present.yml
ファイルのコピーを作成します。$ cp /usr/share/doc/ansible-freeipa/playbooks/role/role-member-user-present.yml role-member-user-present-copy.yml
-
Ansible Playbook ファイル (
role-member-user-present-copy.yml
) を開きます。 iparole
タスクセクションに以下の変数を設定して、ファイルを調整します。-
ipaadmin_password
変数は IdM 管理者のパスワードに設定します。 -
name
変数は新規ロールの名前に設定します。 -
特権
一覧は、新しいロールに追加する IdM 権限の名前に設定します。 -
必要に応じて、
user
変数は、新規ロールを付与するユーザーの名前に設定します。 -
必要に応じて、
group
変数は、新規ロールを付与するグループの名前に設定します。
以下は、今回の例で使用するように変更した Ansible Playbook ファイルです。
--- - name: Playbook to manage IPA role with members. hosts: ipaserver become: yes gather_facts: no tasks: - iparole: ipaadmin_password: Secret123 name: user_and_host_administrator user: idm_user01 group: idm_group01 privilege: - Group Administrators - User Administrators - Stage User Administrators - Group Administrators
-
- ファイルを保存します。
Playbook ファイルとインベントリーファイルを指定して Ansible Playbook を実行します。
$ ansible-playbook -v -i ~/<MyPlaybooks>/inventory role-member-user-present-copy.yml
関連情報
- Ansible Vault を使用したコンテンツの暗号化 を参照してください。
- IdM のロール を参照してください。
-
/usr/share/doc/ansible-freeipa/
ディレクトリーのREADME-role
ファイルを参照してください。 -
/usr/share/doc/ansible-freeipa/playbooks/iparole
ディレクトリーのサンプルの Playbook を参照してください。
23.7. Ansible を使用して IdM RBAC ロールを設定しないようにする手順
Identity Management (IdM) のロールベースアクセス制御 (RBAC) を管理するシステム管理者は、誤って管理者がユーザーに割り当てることがないように、使用しなくなったロールが削除されていることを確認する必要があります。
以下の手順では、Ansible Playbook を使用してロールが削除されていることを確認する方法を説明します。以下の例では、カスタムの user_and_host_administrator ロールが IdM に存在しないことを確認する方法を説明します。
前提条件
- IdM 管理者パスワードを把握している。
- Ansible コントローラーに ansible-freeipa パッケージがインストールされている。
- 設定を行う IdM サーバーの完全修飾ドメイン名 (FQDN) で Ansible インベントリーファイル を作成している。
- Ansible インベントリーファイルが ~/ <MyPlaybooks>/ ディレクトリーにある。
手順
~/<MyPlaybooks>/ ディレクトリーに移動します。
$ cd ~/<MyPlaybooks>/
/usr/share/doc/ansible-freeipa/playbooks/role/
にあるrole-is-absent.yml
ファイルのコピーを作成します。$ cp /usr/share/doc/ansible-freeipa/playbooks/role/role-is-absent.yml role-is-absent-copy.yml
-
Ansible Playbook ファイル (
role-is-absent-copy.yml
) を開きます。 iparole
タスクセクションに以下の変数を設定して、ファイルを調整します。-
ipaadmin_password
変数は IdM 管理者のパスワードに設定します。 -
name
変数は、ロールの名前に設定します。 -
state
変数は、absent
に設定されていることを確認します。
以下は、今回の例で使用するように変更した Ansible Playbook ファイルです。
--- - name: Playbook to manage IPA role with members. hosts: ipaserver become: yes gather_facts: no tasks: - iparole: ipaadmin_password: Secret123 name: user_and_host_administrator state: absent
-
- ファイルを保存します。
Playbook ファイルとインベントリーファイルを指定して Ansible Playbook を実行します。
$ ansible-playbook -v -i ~/<MyPlaybooks>/inventory role-is-absent-copy.yml
関連情報
- Ansible Vault を使用したコンテンツの暗号化 を参照してください。
- IdM のロール を参照してください。
-
/usr/share/doc/ansible-freeipa/
ディレクトリーのREADME-role
Markdown ファイルを参照してください。 -
/usr/share/doc/ansible-freeipa/playbooks/iparole
ディレクトリーのサンプルの Playbook を参照してください。
23.8. Ansible を使用して、ユーザーグループに IdM RBAC ロールを割り当てる手順
Identity Management (IdM) のロールベースアクセス制御 (RBAC) を管理するシステム管理者は、junior administrators など、特定のユーザーグループにロールを割り当てます。
以下の例では、Ansible Playbook を使用して、同梱の IdM RBAC helpdesk ロールを junior_sysadmins に割り当てる方法を説明します。
前提条件
- IdM 管理者パスワードを把握している。
- Ansible コントローラーに ansible-freeipa パッケージがインストールされている。
- 設定を行う IdM サーバーの完全修飾ドメイン名 (FQDN) で Ansible インベントリーファイル を作成している。
- Ansible インベントリーファイルが ~/ <MyPlaybooks>/ ディレクトリーにある。
手順
~/<MyPlaybooks>/ ディレクトリーに移動します。
$ cd ~/<MyPlaybooks>/
/usr/share/doc/ansible-freeipa/playbooks/role/
にあるrole-member-group-present.yml
ファイルのコピーを作成します。$ cp /usr/share/doc/ansible-freeipa/playbooks/role/role-member-group-present.yml role-member-group-present-copy.yml
-
Ansible Playbook ファイル (
role-member-group-present-copy.yml
) を開きます。 iparole
タスクセクションに以下の変数を設定して、ファイルを調整します。-
ipaadmin_password
変数は IdM 管理者のパスワードに設定します。 -
name
変数は、割り当てるロールの名前に設定します。 -
group
変数はグループ名に設定します。 -
action
変数はmember
に設定します。
以下は、今回の例で使用するように変更した Ansible Playbook ファイルです。
--- - name: Playbook to manage IPA role with members. hosts: ipaserver become: yes gather_facts: no tasks: - iparole: ipaadmin_password: Secret123 name: helpdesk group: junior_sysadmins action: member
-
- ファイルを保存します。
Playbook ファイルとインベントリーファイルを指定して Ansible Playbook を実行します。
$ ansible-playbook -v -i ~/<MyPlaybooks>/inventory role-member-group-present-copy.yml
関連情報
- Ansible Vault を使用したコンテンツの暗号化 を参照してください。
- IdM のロール を参照してください。
-
/usr/share/doc/ansible-freeipa/
ディレクトリーのREADME-role
Markdown ファイルを参照してください。 -
/usr/share/doc/ansible-freeipa/playbooks/iparole
ディレクトリーのサンプルの Playbook を参照してください。
23.9. Ansible を使用して特定のユーザーに IdM RBAC ロールが割り当てられないようにする手順
Identity Management (IdM) のロールベースアクセス制御 (RBAC) を管理するシステム管理者は、会社内で別の役職に異動した後など、特定のユーザーに RBAC ロールが割り当てられないようにすることもできます。
以下の手順では、Ansible Playbook を使用して、 user_01 および user_02 という名前のユーザーが helpdesk ロールに割り当てられないようにする方法を説明します。
前提条件
- IdM 管理者パスワードを把握している。
- Ansible コントローラーに ansible-freeipa パッケージがインストールされている。
- 設定を行う IdM サーバーの完全修飾ドメイン名 (FQDN) で Ansible インベントリーファイル を作成している。
- Ansible インベントリーファイルが ~/ <MyPlaybooks>/ ディレクトリーにある。
手順
~/<MyPlaybooks>/ ディレクトリーに移動します。
$ cd ~/<MyPlaybooks>/
/usr/share/doc/ansible-freeipa/playbooks/role/
にあるrole-member-user-absent.yml
ファイルのコピーを作成します。$ cp /usr/share/doc/ansible-freeipa/playbooks/role/role-member-user-absent.yml role-member-user-absent-copy.yml
-
Ansible Playbook ファイル (
role-member-user-absent-copy.yml
) を開きます。 iparole
タスクセクションに以下の変数を設定して、ファイルを調整します。-
ipaadmin_password
変数は IdM 管理者のパスワードに設定します。 -
name
変数は、割り当てるロールの名前に設定します。 -
user
一覧をユーザーの名前に設定します。 -
action
変数はmember
に設定します。 -
state
変数はabsent
に設定します。
以下は、今回の例で使用するように変更した Ansible Playbook ファイルです。
--- - name: Playbook to manage IPA role with members. hosts: ipaserver become: yes gather_facts: no tasks: - iparole: ipaadmin_password: Secret123 name: helpdesk user - user_01 - user_02 action: member state: absent
-
- ファイルを保存します。
Playbook ファイルとインベントリーファイルを指定して Ansible Playbook を実行します。
$ ansible-playbook -v -i ~/<MyPlaybooks>/inventory role-member-user-absent-copy.yml
関連情報
- Ansible Vault を使用したコンテンツの暗号化 を参照してください。
- IdM のロール を参照してください。
-
/usr/share/doc/ansible-freeipa/
ディレクトリーのREADME-role
Markdown ファイルを参照してください。 -
/usr/share/doc/ansible-freeipa/playbooks/iparole
ディレクトリーのサンプルの Playbook を参照してください。
23.10. Ansible を使用してサービスを IdM RBAC ロールに所属させるように設定する手順
Identity Management (IdM) のロールベースアクセス制御 (RBAC) を管理するシステム管理者は、IdM に登録されている特定のサービスが、特定のロールのメンバーになっていることを確認する必要がある場合があります。以下の例では、カスタムの web_administrator ロールを使用して client01.idm.example.com サーバー上で実行中の HTTP
サービスを管理できるようにする方法を説明します。
前提条件
- IdM 管理者パスワードを把握している。
- Ansible コントローラーに ansible-freeipa パッケージがインストールされている。
- 設定を行う IdM サーバーの完全修飾ドメイン名 (FQDN) で Ansible インベントリーファイル を作成している。
- Ansible インベントリーファイルが ~/ <MyPlaybooks>/ ディレクトリーにある。
- web_administrator ロールが IdM に存在する。
- HTTP/client01.idm.example.com@IDM.EXAMPLE.COM サービスが IdM に存在する。
手順
~/<MyPlaybooks>/ ディレクトリーに移動します。
$ cd ~/<MyPlaybooks>/
/usr/share/doc/ansible-freeipa/playbooks/role/
にあるrole-member-service-present.yml
ファイルのコピーを作成します。$ cp /usr/share/doc/ansible-freeipa/playbooks/role/role-member-service-present-absent.yml role-member-service-present-copy.yml
-
Ansible Playbook ファイル (
role-member-service-present-copy.yml
) を開きます。 iparole
タスクセクションに以下の変数を設定して、ファイルを調整します。-
ipaadmin_password
変数は IdM 管理者のパスワードに設定します。 -
name
変数は、割り当てるロールの名前に設定します。 -
service
一覧はサービス名に設定します。 -
action
変数はmember
に設定します。
以下は、今回の例で使用するように変更した Ansible Playbook ファイルです。
--- - name: Playbook to manage IPA role with members. hosts: ipaserver become: yes gather_facts: no tasks: - iparole: ipaadmin_password: Secret123 name: web_administrator service: - HTTP/client01.idm.example.com action: member
-
- ファイルを保存します。
Playbook ファイルとインベントリーファイルを指定して Ansible Playbook を実行します。
$ ansible-playbook -v -i ~/<MyPlaybooks>/inventory role-member-service-present-copy.yml
関連情報
- Ansible Vault を使用したコンテンツの暗号化 を参照してください。
- IdM のロール を参照してください。
-
/usr/share/doc/ansible-freeipa/
ディレクトリーのREADME-role
Markdown ファイルを参照してください。 -
/usr/share/doc/ansible-freeipa/playbooks/iparole
ディレクトリーのサンプルの Playbook を参照してください。
23.11. Ansible を使用してホストを IdM RBAC ロールに所属させるように設定する手順
Identity Management (IdM) でロールベースアクセス制御を管理するシステム管理者は、特定のホストまたはホストグループが特定のロールに関連付けられていることを確認する必要がある場合があります。以下の例では、カスタムの web_administrator ロールが HTTP
サービスを実行している client01.idm.example.com の IdM ホストを管理できるようにする方法を説明します。
前提条件
- IdM 管理者パスワードを把握している。
- Ansible コントローラーに ansible-freeipa パッケージがインストールされている。
- 設定を行う IdM サーバーの完全修飾ドメイン名 (FQDN) で Ansible インベントリーファイル を作成している。
- Ansible インベントリーファイルが ~/ <MyPlaybooks>/ ディレクトリーにある。
- web_administrator ロールが IdM に存在する。
- client01.idm.example.com ホストが IdM に存在する。
手順
~/<MyPlaybooks>/ ディレクトリーに移動します。
$ cd ~/<MyPlaybooks>/
/usr/share/doc/ansible-freeipa/playbooks/role/
にあるrole-member-host-present.yml
ファイルのコピーを作成します。$ cp /usr/share/doc/ansible-freeipa/playbooks/role/role-member-host-present.yml role-member-host-present-copy.yml
-
Ansible Playbook ファイル (
role-member-host-present-copy.yml
) を開きます。 iparole
タスクセクションに以下の変数を設定して、ファイルを調整します。-
ipaadmin_password
変数は IdM 管理者のパスワードに設定します。 -
name
変数は、割り当てるロールの名前に設定します。 -
host
一覧をホストの名前に設定します。
以下は、今回の例で使用するように変更した Ansible Playbook ファイルです。
--- - name: Playbook to manage IPA role with members. hosts: ipaserver become: yes gather_facts: no tasks: - iparole: ipaadmin_password: Secret123 name: web_administrator host: - client01.idm.example.com action: member
-
- ファイルを保存します。
Playbook ファイルとインベントリーファイルを指定して Ansible Playbook を実行します。
$ ansible-playbook -v -i ~/<MyPlaybooks>/inventory role-member-host-present-copy.yml
関連情報
- Ansible Vault を使用したコンテンツの暗号化 を参照してください。
- IdM のロール を参照してください。
-
/usr/share/doc/ansible-freeipa/
ディレクトリーのREADME-role
Markdown ファイルを参照してください。 -
/usr/share/doc/ansible-freeipa/playbooks/iparole
ディレクトリーのサンプルの Playbook を参照してください。
23.12. Ansible を使用してホストグループを IdM RBAC ロールに所属させるように設定する手順
Identity Management (IdM) でロールベースアクセス制御を管理するシステム管理者は、特定のホストまたはホストグループが特定のロールに関連付けられていることを確認する必要がある場合があります。以下の例では、カスタムの web_administrator ロールが HTTP
サービスを実行している IdM ホストの web_servers グループを管理できるようにする方法を説明します。
前提条件
- IdM 管理者パスワードを把握している。
- Ansible コントローラーに ansible-freeipa パッケージがインストールされている。
- 設定を行う IdM サーバーの完全修飾ドメイン名 (FQDN) で Ansible インベントリーファイル を作成している。
- Ansible インベントリーファイルが ~/ <MyPlaybooks>/ ディレクトリーにある。
- web_administrator ロールが IdM に存在する。
- web_servers ホストグループが IdM に存在する。
手順
~/<MyPlaybooks>/ ディレクトリーに移動します。
$ cd ~/<MyPlaybooks>/
/usr/share/doc/ansible-freeipa/playbooks/role/
にあるrole-member-hostgroup-present.yml
ファイルのコピーを作成します。$ cp /usr/share/doc/ansible-freeipa/playbooks/role/role-member-hostgroup-present.yml role-member-hostgroup-present-copy.yml
-
Ansible Playbook ファイル (
role-member-hostgroup-present-copy.yml
) を開きます。 iparole
タスクセクションに以下の変数を設定して、ファイルを調整します。-
ipaadmin_password
変数は IdM 管理者のパスワードに設定します。 -
name
変数は、割り当てるロールの名前に設定します。 -
hostgroup
一覧はホストグループ名に設定します。
以下は、今回の例で使用するように変更した Ansible Playbook ファイルです。
--- - name: Playbook to manage IPA role with members. hosts: ipaserver become: yes gather_facts: no tasks: - iparole: ipaadmin_password: Secret123 name: web_administrator hostgroup: - web_servers action: member
-
- ファイルを保存します。
Playbook ファイルとインベントリーファイルを指定して Ansible Playbook を実行します。
$ ansible-playbook -v -i ~/<MyPlaybooks>/inventory role-member-hostgroup-present-copy.yml
関連情報
- Ansible Vault を使用したコンテンツの暗号化 を参照してください。
- IdM のロール を参照してください。
-
/usr/share/doc/ansible-freeipa/
ディレクトリーのREADME-role
Markdown ファイルを参照してください。 -
/usr/share/doc/ansible-freeipa/playbooks/iparole
ディレクトリーのサンプルの Playbook を参照してください。
第24章 Ansible Playbook を使用した RBAC 権限の管理
ロールベースアクセス制御 (RBAC) は、ロール、権限およびパーミッションで定義する、ポリシーに依存しないアクセス制御メカニズムです。特に大企業では、RBAC を使用すると、責任の領域を個別に設定する階層管理システムを作成できます。
本章では、Ansible Playbook を使用して Identity Management (IdM) で RBAC 権限を管理する以下の操作について説明します。
前提条件
- RBAC の概念と原則 を理解している。
24.1. Ansible を使用してカスタムの IdM RBAC 特権を存在させる手順
Identity Management (IdM) のロールベースアクセス制御 (RBAC) でカスタム権限を完全に機能させるには、ステージごとに進めていく必要があります。
- パーミッションが割り当てられていない特権を作成します。
- 選択したパーミッションを特権に追加します。
以下の手順では、後でパーミッションを追加できるように、Ansible Playbook を使用して空の特権を作成する方法を説明します。この例では、ホスト管理に関連するすべての IdM パーミッションを組み合わせられるように full_host_administration という名前の特権を作成する方法を説明します。
前提条件
- IdM 管理者パスワードを把握している。
- Ansible コントローラーに ansible-freeipa パッケージがインストールされている。
- 設定を行う IdM サーバーの完全修飾ドメイン名 (FQDN) で Ansible インベントリーファイル を作成している。
- Ansible インベントリーファイルが ~/ MyPlaybooks/ ディレクトリーにある。
手順
~/ MyPlaybooks/ ディレクトリーに移動します。
$ cd ~/MyPlaybooks/
/usr/share/doc/ansible-freeipa/playbooks/privilege/
にあるprivilege-present.yml
ファイルのコピーを作成します。$ cp /usr/share/doc/ansible-freeipa/playbooks/privilege/privilege-present.yml privilege-present-copy.yml
-
Ansible Playbook ファイル (
privilege-present-copy.yml
) を開きます。 ipaprivilege
タスクセクションに以下の変数を設定してファイルを調整します。-
ipaadmin_password
変数は IdM 管理者のパスワードに設定します。 -
name
変数は、新しい特権 full_host_administration の名前に設定します。 -
必要に応じて、
description
変数を使用して特権を記述します。
以下は、今回の例で使用するように変更した Ansible Playbook ファイルです。
--- - name: Privilege present example hosts: ipaserver become: true tasks: - name: Ensure privilege full_host_administration is present ipaprivilege: ipaadmin_password: Secret123 name: full_host_administration description: This privilege combines all IdM permissions related to host administration
-
- ファイルを保存します。
Playbook ファイルとインベントリーファイルを指定して Ansible Playbook を実行します。
$ ansible-playbook -v -i inventory privilege-present-copy.yml
24.2. Ansible を使用してカスタムの IdM RBAC 特権にメンバーパーミッションを存在させる手順
Identity Management (IdM) のロールベースアクセス制御 (RBAC) でカスタム権限を完全に機能させるには、ステージごとに進めていく必要があります。
- パーミッションが割り当てられていない特権を作成します。
- 選択したパーミッションを特権に追加します。
以下の手順では、Ansible Playbook を使用して、前の手順で作成した特権にパーミッションを追加する方法を説明します。この例では、ホスト管理に関連する IdM パーミッションをすべて、full_host_administration という名前の特権に追加する方法を説明します。デフォルトでは、パーミッションは Host Enrollment
、Host Administrators
および Host Group Administrator
特権の間で分散されます。
前提条件
- IdM 管理者パスワードを把握している。
- Ansible コントローラーに ansible-freeipa パッケージがインストールされている。
- 設定を行う IdM サーバーの完全修飾ドメイン名 (FQDN) で Ansible インベントリーファイル を作成している。
- Ansible インベントリーファイルが ~/ MyPlaybooks/ ディレクトリーにある。
- full_host_administration 権限が存在する。Ansible を使用して特権を作成する方法は、「Ansible を使用してカスタムの IdM RBAC 特権の存在」を参照してください。
手順
~/ MyPlaybooks/ ディレクトリーに移動します。
$ cd ~/MyPlaybooks/
/usr/share/doc/ansible-freeipa/playbooks/privilege/
にあるprivilege-member-present.yml
ファイルのコピーを作成します。$ cp /usr/share/doc/ansible-freeipa/playbooks/privilege/privilege-member-present.yml privilege-member-present-copy.yml
-
Ansible Playbook ファイル (
privilege-member-present-copy.yml
) を開きます。 ipaprivilege
タスクセクションに以下の変数を設定してファイルを調整します。-
使用しているユースケースに合わせて、タスクの
名前
を調節します。 -
ipaadmin_password
変数は IdM 管理者のパスワードに設定します。 -
name
変数は、特権の名前に設定します。 -
permission
は、特権に追加するパーミッションの名前を設定します。 -
action
変数がmember
に設定されていることを確認します。
以下は、今回の例で使用するように変更した Ansible Playbook ファイルです。
--- - name: Privilege member present example hosts: ipaserver become: true tasks: - name: Ensure that permissions are present for the "full_host_administration" privilege ipaprivilege: ipaadmin_password: Secret123 name: full_host_administration permission: - "System: Add krbPrincipalName to a Host" - "System: Enroll a Host" - "System: Manage Host Certificates" - "System: Manage Host Enrollment Password" - "System: Manage Host Keytab" - "System: Manage Host Principals" - "Retrieve Certificates from the CA" - "Revoke Certificate" - "System: Add Hosts" - "System: Add krbPrincipalName to a Host" - "System: Enroll a Host" - "System: Manage Host Certificates" - "System: Manage Host Enrollment Password" - "System: Manage Host Keytab" - "System: Manage Host Keytab Permissions" - "System: Manage Host Principals" - "System: Manage Host SSH Public Keys" - "System: Manage Service Keytab" - "System: Manage Service Keytab Permissions" - "System: Modify Hosts" - "System: Remove Hosts" - "System: Add Hostgroups" - "System: Modify Hostgroup Membership" - "System: Modify Hostgroups" - "System: Remove Hostgroups"
-
使用しているユースケースに合わせて、タスクの
- ファイルを保存します。
Playbook ファイルとインベントリーファイルを指定して Ansible Playbook を実行します。
$ ansible-playbook -v -i inventory privilege-member-present-copy.yml
24.3. Ansible を使用して IdM RBAC 特権にパーミッションが含まれないようにする手順
Identity Management (IdM) のシステム管理者は、IdM のロールベースアクセス制御をカスタマイズできます。
以下の手順では、Ansible Playbook を使用して、特権からパーミッションを削除する方法を説明します。この例では、管理者がセキュリティー上のリスクを考慮するため、デフォルトの Certificate Administrators
特権から Request Certificates ignoring CA ACLs
を削除する方法を説明します。
前提条件
- IdM 管理者パスワードを把握している。
- Ansible コントローラーに ansible-freeipa パッケージがインストールされている。
- 設定を行う IdM サーバーの完全修飾ドメイン名 (FQDN) で Ansible インベントリーファイル を作成している。
- Ansible インベントリーファイルが ~/ MyPlaybooks/ ディレクトリーにある。
手順
~/ MyPlaybooks/ ディレクトリーに移動します。
$ cd ~/MyPlaybooks/
/usr/share/doc/ansible-freeipa/playbooks/privilege/
にあるprivilege-member-present.yml
ファイルのコピーを作成します。$ cp /usr/share/doc/ansible-freeipa/playbooks/privilege/privilege-member-absent.yml privilege-member-absent-copy.yml
-
Ansible Playbook ファイル (
privilege-member-absent-copy.yml
) を開きます。 ipaprivilege
タスクセクションに以下の変数を設定してファイルを調整します。-
使用しているユースケースに合わせて、タスクの
名前
を調節します。 -
ipaadmin_password
変数は IdM 管理者のパスワードに設定します。 -
name
変数は、特権の名前に設定します。 -
permission
の一覧は、特権から削除するパーミッションの名前に設定します。 -
action
変数がmember
に設定されていることを確認します。 -
state
変数はabsent
に設定されていることを確認します。
以下は、今回の例で使用するように変更した Ansible Playbook ファイルです。
--- - name: Privilege absent example hosts: ipaserver become: true tasks: - name: Ensure that the "Request Certificate ignoring CA ACLs" permission is absent from the "Certificate Administrators" privilege ipaprivilege: ipaadmin_password: Secret123 name: Certificate Administrators permission: - "Request Certificate ignoring CA ACLs" action: member state: absent
-
使用しているユースケースに合わせて、タスクの
- ファイルを保存します。
Playbook ファイルとインベントリーファイルを指定して Ansible Playbook を実行します。
$ ansible-playbook -v -i inventory privilege-member-absent-copy.yml
24.4. Ansible を使用してカスタムの IdM RBAC 権限の名前を変更する手順
Identity Management (IdM) のシステム管理者は、IdM のロールベースアクセス制御をカスタマイズできます。
以下の手順では、たとえば、パーミッションの一部を削除したなどの理由から、特権の名前を変更する方法を説明します。パーミッションを削除した結果、特権の名前は正確ではなくなりました。この例では、管理者は full_host_administration 特権の名前を limited_host_administration に変更します。
前提条件
- IdM 管理者パスワードを把握している。
- Ansible コントローラーに ansible-freeipa パッケージがインストールされている。
- 設定を行う IdM サーバーの完全修飾ドメイン名 (FQDN) で Ansible インベントリーファイル を作成している。
- Ansible インベントリーファイルが ~/ MyPlaybooks/ ディレクトリーにある。
- full_host_administration 権限が存在する。特権の追加方法は、「Ansible を使用してカスタムの IdM RBAC 権限を存在させる手順」を参照してください。
手順
~/ MyPlaybooks/ ディレクトリーに移動します。
$ cd ~/MyPlaybooks/
/usr/share/doc/ansible-freeipa/playbooks/privilege/
にあるprivilege-present.yml
ファイルのコピーを作成します。$ cp /usr/share/doc/ansible-freeipa/playbooks/privilege/privilege-present.yml rename-privilege.yml
-
Ansible Playbook ファイル (
rename-privilege.yml
) を開いて編集します。 ipaprivilege
タスクセクションに以下の変数を設定してファイルを調整します。-
ipaadmin_password
変数は IdM 管理者のパスワードに設定します。 -
name
変数は、現在の特権名に設定します。 -
rename
変数を追加して、特権の新しい名前に設定します。 -
state
変数を追加し、renamed
に設定します。
-
以下のように、Playbook 自体の名前を変更します。
--- - name: Rename a privilege hosts: ipaserver become: true
以下のように、Playbook のタスクの名前を変更します。
[...] tasks: - name: Ensure the full_host_administration privilege is renamed to limited_host_administration ipaprivilege: [...]
以下は、今回の例で使用するように変更した Ansible Playbook ファイルです。
--- - name: Rename a privilege hosts: ipaserver become: true tasks: - name: Ensure the full_host_administration privilege is renamed to limited_host_administration ipaprivilege: ipaadmin_password: Secret123 name: full_host_administration rename: limited_host_administration state: renamed
- ファイルを保存します。
Playbook ファイルとインベントリーファイルを指定して Ansible Playbook を実行します。
$ ansible-playbook -v -i inventory rename-privilege.yml
24.5. Ansible を使用して IdM RBAC 特権が含まれないようにする手順
Identity Management (IdM) のシステム管理者は、IdM のロールベースアクセス制御をカスタマイズできます。以下の手順では、Ansible Playbook を使用して RBAC 特権が削除されていることを確認する方法を説明します。この例では、CA administrator
特権が存在しないことを確認する方法を説明します。この手順が終わると、IdM で認証局を管理できるユーザーは admin
だけになります。
前提条件
- IdM 管理者パスワードを把握している。
- Ansible コントローラーに ansible-freeipa パッケージがインストールされている。
- 設定を行う IdM サーバーの完全修飾ドメイン名 (FQDN) で Ansible インベントリーファイル を作成している。
- Ansible インベントリーファイルが ~/ MyPlaybooks/ ディレクトリーにある。
手順
~/ MyPlaybooks/ ディレクトリーに移動します。
$ cd ~/MyPlaybooks/
/usr/share/doc/ansible-freeipa/playbooks/privilege/
ディレクトリーにあるprivilege-absent.yml
ファイルのコピーを作成します。$ cp /usr/share/doc/ansible-freeipa/playbooks/privilege/privilege-absent.yml privilege-absent-copy.yml
-
Ansible Playbook ファイル (
privilege-absent-copy.yml
) を開きます。 ipaprivilege
タスクセクションに以下の変数を設定してファイルを調整します。-
ipaadmin_password
変数は IdM 管理者のパスワードに設定します。 -
name
変数は、削除する権限の名前に設定します。 -
state
変数がabsent
に設定されていることを確認します。
-
以下のように、Playbook のタスクの名前を変更します。
[...] tasks: - name: Ensure privilege "CA administrator" is absent ipaprivilege: [...]
以下は、今回の例で使用するように変更した Ansible Playbook ファイルです。
--- - name: Privilege absent example hosts: ipaserver become: true tasks: - name: Ensure privilege "CA administrator" is absent ipaprivilege: ipaadmin_password: Secret123 name: CA administrator state: absent
- ファイルを保存します。
Playbook ファイルとインベントリーファイルを指定して Ansible Playbook を実行します。
$ ansible-playbook -v -i inventory privilege-absent-copy.yml
24.6. 関連情報
- IdM の特権 を参照してください。
- IdM のパーミッション を参照してください。
-
/usr/share/doc/ansible-freeipa/
ディレクトリーで利用可能なREADME-privilege
ファイルを参照してください。 -
/usr/share/doc/ansible-freeipa/playbooks/ipaprivilege
ディレクトリーのサンプルの Playbook を参照してください。
第25章 Ansible Playbook を使用した IdM での RBAC パーミッションの管理
ロールベースアクセス制御 (RBAC) は、ロール、権限およびパーミッションで定義する、ポリシーに依存しないアクセス制御メカニズムです。特に大企業では、RBAC を使用すると、責任の領域を個別に設定する階層管理システムを作成できます。
本章では、Ansible Playbook を使用して Identity Management (IdM) で RBAC パーミッションの管理時に行う、以下の操作について説明します。
前提条件
- RBAC の概念と原則 を理解している。
25.1. Ansible を使用して RBAC パーミッションを存在させる手順
Identity Management (IdM) のシステム管理者は、IdM のロールベースアクセス制御 (RBAC) をカスタマイズできます。
以下の手順では、Ansible Playbook を使用して、パーミッションを特権に追加できるように IdM にパーミッションを追加する方法を説明します。この例では、目的とする以下の状態を達成する方法を説明します。
-
MyPermission
パーミッションが存在する。 -
MyPermission
パーミッションだけがホストに適用できる。 パーミッションを含む特権を付与されたユーザーは、エントリーに対して以下の操作すべてを実行できます。
- Write
- Read
- 検索
- 比較
- 追加
- Delete
前提条件
- IdM 管理者パスワードを把握している。
- Ansible コントローラーに ansible-freeipa パッケージがインストールされている。
- この例では、サンプルの Playbook のコピーを保存する一元管理場所として ~/MyPlaybooks/ ディレクトリーを 作成して設定 していることを前提とします。
手順
~/ MyPlaybooks/ ディレクトリーに移動します。
$ cd ~/MyPlaybooks/
/usr/share/doc/ansible-freeipa/playbooks/permission/
ディレクトリーにあるpermission-present.yml
ファイルのコピーを作成します。$ cp /usr/share/doc/ansible-freeipa/playbooks/permission/permission-present.yml permission-present-copy.yml
-
Ansible Playbook ファイル (
permission-present-copy.yml
) を開きます。 ipapermission
タスクセクションに以下の変数を設定して、ファイルを調整します。-
使用しているユースケースに合わせて、タスクの
名前
を調節します。 -
ipaadmin_password
変数は IdM 管理者のパスワードに設定します。 -
name
変数はパーミッションの名前に設定します。 -
object_type
変数はhost
に設定します。 -
right
変数はall
に設定します。
以下は、今回の例で使用するように変更した Ansible Playbook ファイルです。
--- - name: Permission present example hosts: ipaserver become: true tasks: - name: Ensure that the "MyPermission" permission is present ipapermission: ipaadmin_password: Secret123 name: MyPermission object_type: host right: all
-
使用しているユースケースに合わせて、タスクの
- ファイルを保存します。
Playbook ファイルとインベントリーファイルを指定して Ansible Playbook を実行します。
$ ansible-playbook -v -i inventory permission-present-copy.yml
25.2. Ansible を使用して属性を含めて RBAC パーミッションを追加する手順
Identity Management (IdM) のシステム管理者は、IdM のロールベースアクセス制御 (RBAC) をカスタマイズできます。
以下の手順では、Ansible Playbook を使用して、パーミッションを特権に追加できるように IdM にパーミッションを追加する方法を説明します。この例では、目的とする以下の状態を達成する方法を説明します。
- MyPermission パーミッションが存在する。
- MyPermission パーミッションだけがホストの追加に使用できる。
パーミッションを含む特権を付与されたユーザーは、ホストのエントリーに対して以下の操作すべてを実行できる。
- Write
- Read
- 検索
- 比較
- 追加
- Delete
-
MyPermission パーミッションを含む特権のあるユーザーが作成したホストエントリーに
description
の値を追加できる。
IdM LDAP スキーマでは、パーミッションの作成または変更時に指定できる属性のタイプは制約されません。ただし、object_type
が host
の場合に attrs: car_licence
を指定すると、後でパーミッションを実行して、車のライセンス値をホストに追加使用とすると ipa: ERROR: attribute "car-license" not allowed
というエラーメッセージが表示されます。
前提条件
- IdM 管理者パスワードを把握している。