Menu Close
Red Hat Training
A Red Hat training course is available for RHEL 8
Identity Management の設定および管理
Red Hat Enterprise Linux 8 で Identity Management の設定、管理、および維持
概要
多様性を受け入れるオープンソースの強化
Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。まずは、マスター (master)、スレーブ (slave)、ブラックリスト (blacklist)、ホワイトリスト (whitelist) の 4 つの用語の置き換えから始めます。この取り組みは膨大な作業を要するため、今後の複数のリリースで段階的に用語の置き換えを実施して参ります。詳細は、弊社 の CTO、Chris Wright のメッセージ を参照してください。
Identity Management では、以下のような用語の置き換えが含まれます。
- ブラックリストからブロックリスト
- ホワイトリストから許可リスト
- スレーブからセカンダリー
単語 マスター は、コンテキストに応じて、より正確な言語に置き換えられます。
- マスターからIdM サーバー
- CA 更新マスターからCA 更新サーバー
- CRL マスターからCRL パブリッシャーサーバー
- マルチマスターからマルチサプライヤー
Red Hat ドキュメントへのフィードバック (英語のみ)
ご意見ご要望をお聞かせください。ドキュメントの改善点はございませんか。
特定の部分についての簡単なコメントをお寄せいただく場合は、以下をご確認ください。
- ドキュメントの表示が Multi-page HTML 形式になっていて、ドキュメントの右上隅に Feedback ボタンがあることを確認してください。
- マウスカーソルで、コメントを追加する部分を強調表示します。
- そのテキストの下に表示される Add Feedback ポップアップをクリックします。
- 表示される手順に従ってください。
Bugzilla を介してフィードバックを送信するには、新しいチケットを作成します。
- Bugzilla の Web サイトにアクセスします。
- Component で Documentation を選択します。
- Description フィールドに、ドキュメントの改善に関するご意見を記入してください。ドキュメントの該当部分へのリンクも記入してください。
- Submit Bug をクリックします。
第1章 コマンドラインから Identity Management へのログイン
Identity Management (IdM) では、Kerberos プロトコルを使用してシングルサインオンに対応します。シングルサインオンとは、ユーザーが正しいユーザー名およびパスワードを一度だけ入力すれば、システムが認証情報を再度求めることなく、IdM サービスにアクセスできるという機能です。
IdM では、ユーザーが、対応する Kerberos プリンシパル名を使用して IdM クライアントマシンのデスクトップ環境にログインすると、SSSD (System Security Services Daemon) が、そのユーザーの TGT (Ticket-Granting Ticket) を自動的に取得します。これは、ログインしてから、kinit ユーティリティーを使用して IdM リソースにアクセスする必要がなくなることを意味します。
Kerberos 認証情報キャッシュを削除している場合、または Kerberos TGT の有効期限が切れている場合に IdM リソースにアクセスするには、手動で Kerberos チケットを要求する必要があります。以下のセクションでは、IdM で Kerberos を使用している場合の基本的なユーザー操作を説明します。
1.1. kinit による IdM への手動ログイン
この手順では、kinit ユーティリティーを使用して、Identity Management (IdM) 環境を手動で認証する方法を説明します。kinit ユーティリティーは、IdM ユーザーの代わりに Kerberos の TGT (Ticket-Granting Ticket) を取得して、キャッシュに格納します。
この手順は、最初の Kerberos TGT を破棄したか、有効期限が切れている場合にのみ使用します。ローカルマシンに、IdM ユーザーとしてログインすると、IdM に自動的にログインします。これは、ログイン後に IdM リソースにアクセスするのに kinit ユーティリティーを使用する必要がないことを示しています。
手順
IdM へのログイン
ローカルシステムに現在ログインしているユーザーのユーザー名で、(ユーザー名を指定せずに) kinit を使用します。たとえば、ローカルシステムにログインしているユーザーが
example_user
の場合は、次のコマンドを実行します。[example_user@server ~]$ kinit Password for example_user@EXAMPLE.COM: [example_user@server ~]$
ローカルユーザーのユーザー名と、IdM のユーザーエントリーが一致しないと、認証に失敗します。
[example_user@server ~]$ kinit kinit: Client 'example_user@EXAMPLE.COM' not found in Kerberos database while getting initial credentials
ローカルユーザー名に対応しない Kerberos プリンシパルを使用して、
kinit
ユーティリティーに必要なユーザー名を渡します。たとえば、admin
ユーザーとしてログインするには、次のコマンドを実行します。[example_user@server ~]$ kinit admin Password for admin@EXAMPLE.COM: [example_user@server ~]$
必要に応じて、ログインが成功したことを確認するには、klist ユーティリティーを使用して、キャッシュした TGT を表示します。以下の例では、キャッシュに
example_user
プリンシパルのチケットが含まれています。これは、このホストでは IdM サービスにアクセスするのは、example_user
にのみ許可されていることを示しています。$ klist Ticket cache: KEYRING:persistent:0:0 Default principal: example_user@EXAMPLE.COM Valid starting Expires Service principal 11/10/2019 08:35:45 11/10/2019 18:35:45 krbtgt/EXAMPLE.COM@EXAMPLE.COM
1.2. アクティブなユーザーの Kerberos チケットの破棄
本セクションでは、アクティブなユーザーの Kerberos チケットが含まれている認証情報キャッシュを削除する方法を説明します。
手順
Kerberos チケットを破棄するには、次のコマンドを実行します。
[example_user@server ~]$ kdestroy
必要に応じて、Kerberos チケットが破棄されたことを確認するには、次のコマンドを実行します。
[example_user@server ~]$ klist klist: Credentials cache keyring 'persistent:0:0' not found
1.3. Kerberos 認証用の外部システムの設定
本セクションでは、Identity Management (IdM) ユーザーが自身の Kerberos 認証情報を使用して、外部システムから IdM にログインするように外部システムを設定する方法を説明します。
外部システムの Kerberos 認証を有効にすることは、インフラストラクチャーに、複数のレルムまたは重複ドメインが含まれている場合に特に便利です。また、ipa-client-install
を実行してシステムを IdM ドメインに登録していない場合にも便利です。
IdM ドメインのメンバーではないシステムから IdM への Kerberos 認証を有効にするには、IdM 固有の Kerberos 設定ファイルを外部システムに定義します。
前提条件
外部システムに
krb5-workstation
パッケージがインストールされている。パッケージがインストールされているかどうかを確認するには、次の CLI コマンドを使用します。
# yum list installed krb5-workstation Installed Packages krb5-workstation.x86_64 1.16.1-19.el8 @BaseOS
手順
IdM サーバーから外部システムに
/etc/krb5.conf
ファイルをコピーします。以下に例を示します。# scp /etc/krb5.conf root@externalsystem.example.com:/etc/krb5_ipa.conf
警告外部マシンにある既存の
krb5.conf
ファイルは上書きしないでください。外部システムで、コピーした IdM の Kerberos 設定ファイルを使用するように、端末セッションを設定します。
$ export KRB5_CONFIG=/etc/krb5_ipa.conf
KRB5_CONFIG
変数は、ログアウトまで一時的に存在します。ログアウト時に削除されないように、この変数のファイル名を変えてエクスポートします。-
/etc/krb5.conf.d/
ディレクトリーの Kerberos 設定部分を、外部システムにコピーします。
外部システムのユーザーが、kinit
ユーティリティーを使用して IdM サーバーで認証できるようになりました。
1.4. 関連情報
-
krb5.conf(5)
の man ページ -
kinit(1)
の man ページ -
klist(1)
の man ページ -
kdestroy(1)
の man ページ
第2章 Identity Management サービスの表示、開始、および停止
Identity Management (IdM) サーバーは、ドメインコントローラー (DC) として機能する Red Hat Enterprise Linux システムです。IdM サーバーでさまざまなサービスが実行していますが、中でも注目すべきは Directory Server、Certificate Authority (CA)、DNS、および Kerberos です。
2.1. IdM サービス
本セクションでは、IdM サーバーおよびクライアントにインストールして実行できるサービスについて説明します。
IdM サーバーがホストするサービスの一覧
以下のサービスの多くは、IdM サーバーへのインストールが必須というわけではありません。たとえば、認証局 (CA) や DNS サーバーなどのサービスは、IdM ドメイン内にない外部サーバーにインストールできます。
- Kerberos
-
krb5kdc
サービスおよびkadmin
サービス
IdM は、シングルサインオンに対応する Kerberos プロトコルを使用します。Kerberos では、正しいユーザー名とパスワードを一度提示するだけで済み、システムから認証情報を再度求められることなく IdM サービスにアクセスできます。
Kerberos は 2 つの部分に分類されます。
-
krb5kdc
サービス。Kerberos 認証サービスおよびキー配布センター (KDC) デーモンです。 -
kadmin
サービス。Kerberos V5 データベース管理プログラムです。
IdM で Kerberos を使用して認証する方法は、「コマンドラインからの Identity Management へのログイン」および「Web UI で IdM にログイン: Kerberos チケットの使用 」を参照してください。
- LDAP ディレクトリーサーバー
-
dirsrv
サービス
IdM の LDAP ディレクトリーサーバー インスタンスは、 Kerberos、ユーザーアカウント、ホストエントリー、サービス、ポリシー、DNS などの情報をはじめとした、IdM 情報をすべて保存します。LDAP ディレクトリーサーバーインスタンスは、Red Hat Directory Server と同じテクノロジーをベースにしています。ただし、IdM 固有のタスクに合わせて調整されます。
- 認証局
-
pki-tomcatd
サービス
統合 認証局 (CA) は、Red Hat Certificate System と同じテクノロジーをベースにしています。pki
は、証明書システムサービスにアクセスするコマンドラインインターフェースです。
必要な証明書をすべて単独で作成して提供する場合は、統合 CA なしでサーバーをインストールすることもできます。
詳細は、Planning your CA services を参照してください。
- DNS (Domain Name System)
-
named
サービス
IdM は、動的サービス検出に DNS を使用します。IdM クライアントのインストールユーティリティーは、DNS からの情報を使用して、クライアントマシンを自動的に設定できます。クライアントを IdM ドメインに登録したら、クライアントは DNS を使用してドメイン内の IdM サーバーおよびサービスを検索します。Red Hat Enterprise Linux の DNS (Domain Name System) プロトコルの BIND
(Berkeley Internet Name Domain)実装には、名前付き
の DNS サーバーが含まれています。named-pkcs11
は、PKCS#11 暗号化標準に対するネイティブサポートありで構築された BIND DNS サーバーのバージョンです。
詳細は、Planning your DNS services and host names を参照してください。
- Apache HTTP サーバー
-
httpd
サービス
Apache HTTP Web サーバー には、IdM Web UI があり、認証局とその他の IdM サービスの間の通信も管理します。
- Samba / Winbind
-
SMB
サービスおよびwinbind
サービス
Samba は、Red Hat Enterprise Linux に、Common Internet File System (CIFS) プロトコルとも呼ばれる Server Message Block (SMB) プロトコルを実装します。smb サービス経由で SMB プロトコルを使用すると、ファイル共有や共有プリンターなどのサーバーのリソースにアクセスできます。Active Directory (AD) 環境で信頼を設定している場合には、'Winbind' サービスが IdM サーバーと AD サーバー間の通信を管理します。
- ワンタイムパスワード (OTP) 認証
-
ipa-otpd
サービス
ワンタイムパスワード (OTP) は、2 要素認証の一部として、認証トークンがセッション 1 回だけ使用できるように生成するパスワードです。OTP 認証は、ipa-otpd
サービスを介して Red Hat Enterprise Linux に実装されています。
詳細は「ワンタイムパスワードを使用して Identity Management Web UI へのログイン」を参照してください。
- OpenDNSSEC
-
ipa-dnskeysyncd
サービス
OpenDNSSEC は、DNSSEC (DNS Security Extensions) キーおよびゾーンの署名の記録プロセスを自動化する DNS マネージャーです。ipa-dnskeysyncd
サービスは、IdM Directory Server と OpenDNSSEC との間の同期を管理します。

IdM クライアントがホストするサービスの一覧
-
System Security Services Daemon:
sssd
サービス
SSSD (System Security Services Daemon) は、ユーザー認証およびキャッシュ認証情報を管理するクライアント側のアプリケーションです。キャッシュを使用すると、IdM サーバーが利用できなくなったり、クライアントがオフラインになったりした場合に、ローカルシステムが通常の認証操作を継続できるようになります。
詳細は「SSSD とその利点について」を参照してください。
-
certmonger:
certmonger
サービス
certmonger
サービスは、クライアント上の証明書を監視、更新します。このサービスは、システム上のサービスに対して新しい証明書を要求できます。
詳細は、「certmonger を使用したサービスの IdM 証明書の取得」を参照してください。

2.2. IdM サービスの状態の表示
IdM サーバーに設定されている IdM サービスの状態を表示するには、ipactl status
コマンドを実行します。
[root@server ~]# ipactl status
Directory Service: RUNNING
krb5kdc Service: RUNNING
kadmin Service: RUNNING
named Service: RUNNING
httpd Service: RUNNING
pki-tomcatd Service: RUNNING
smb Service: RUNNING
winbind Service: RUNNING
ipa-otpd Service: RUNNING
ipa-dnskeysyncd Service: RUNNING
ipa: INFO: The ipactl command was successful
サーバーの ipactl status
コマンドの出力は、IdM 設定により異なります。たとえば、IdM デプロイメントに DNS サーバーが含まれていない場合は、named
サービスが一覧に表示されません。
IdM の Web UI を使用して、特定の IdM サーバーで実行しているすべての IdM サービスの状態を表示することはできません。Kerberos に対応し、複数のサーバーで実行しているサービスは、IdM の Web UI の Identity
→ Services
タブで表示できます。
サーバー全体、または個々のサービスのみを起動または停止できます。
IdM サーバー全体を起動、停止、または再起動する場合は、以下を参照してください。
個々の IdM サービスを起動、停止、または再起動する場合は、以下を参照してください。
IdM ソフトウェアのバージョンを表示するには、次を参照してください。
2.3. Identity Management サーバー全体の起動と停止 - ipactl
ユーティリティー
ipactl
ユーティリティーを使用して、IdM サーバー全体と、インストールしたサービスをすべて停止、起動 (開始)、または再起動 (再開) します。ipactl
ユーティリティーを使用して、すべてのサービスを適切な順番で停止、開始、または再開します。有効な Kerberos チケットがなくても、ipactl
コマンドは実行できます。
ipactl
コマンド
IdM サーバー全体を起動するには、次のコマンドを実行します。
# ipactl start
IdM サーバー全体を停止するには、次のコマンドを実行します。
# ipactl stop
IdM サーバー全体を再起動するには、次のコマンドを実行します。
# ipactl restart
IdM を構成するすべてのサービスのステータスを表示するには、次のコマンドを実行します。
# ipactl status
ipactl
コマンドは、IdM の Web UI では使用できません。
2.4. 個々の Identity Management サービスの開始および停止 - systemctl
ユーティリティー
IdM 設定ファイルを手動で変更することは推奨されていません。ただし、特定の状況では、管理者が特定のサービスを手動で設定する必要があります。このような場合は、systemctl
ユーティリティーを使用して、個々の IdM サービスを停止、開始、または再開します。
たとえば、その他の IdM サービスを変更せずに、Directory Server の挙動をカスタマイズした場合は、systemctl
を使用します。
# systemctl restart dirsrv@REALM-NAME.service
また、Active Directory と IdM の信頼を最初にデプロイする場合は、/etc/sssd/sssd.conf
ファイルを変更して、以下を追加します。
- リモートサーバーのレイテンシーが長い環境で、タイムアウト設定オプションを調整するための特定のパラメーター
- Active Directory サイトのアフィニティーを調整するための特定のパラメーター
- グローバルの IdM 設定では提供されない特定の設定オプションのオーバーライド
/etc/sssd/sssd.conf
ファイルに加えた変更を適用する場合は、次のコマンドを実行します。
# systemctl restart sssd.service
System Security Services Daemon (SSSD) は、設定を自動的に再読み込みまたは再適用しないため、systemctl restart sssd.service
を実行する必要があります。
変更が、IdM の ID 範囲に影響を及ぼす場合は、サーバーを完全に再起動することが推奨されます。
複数の IdM ドメインサービスを再開する場合は、常に ipactl
を使用してください。IdM サーバーにインストールされているサービス間での依存関係により、サービスを開始および停止する順番は極めて重要です。ipactl
ユーティリティーは、サービスが適切な順番で開始および停止するようにします。
便利な systemctl
コマンド
特定の IdM サービスを開始するには、次のコマンドを実行します。
# systemctl start name.service
特定の IdM サービスを停止するには、次のコマンドを実行します。
# systemctl stop name.service
特定の IdM サービスを再開するには、次のコマンドを実行します。
# systemctl restart name.service
特定の IdM サービスの状態を表示するには、次のコマンドを実行します。
# systemctl status name.service
IdM の Web UI を使用して、IdM サーバーで実行している個々のサービスを開始または停止することはできません。Web UI で可能なのは、Identity
→ Services
に移動してサービスを選択し、Kerberos に対応する設定を修正することです。
2.5. IdM ソフトウェアのバージョンを表示する方法
IdM バージョン番号は次の方法で表示できます。
- IdM WebUI
-
ipa
コマンド -
rpm
コマンド
- WebUI を介したバージョンの表示
IdM WebUI では、右上のユーザー名メニューから
About
を選択して、ソフトウェアバージョンを表示できます。ipa
コマンドによるバージョンの表示コマンドラインから、
ipa --version
コマンドを使用します。[root@server ~]# ipa --version VERSION: 4.8.0, API_VERSION: 2.233
rpm
コマンドによるバージョンの表示IdM サービスが適切に動作していない場合は、
rpm
ユーティリティーを使用して、現在インストールされているipa-server
パッケージのバージョン番号を確認できます。[root@server ~]# rpm -q ipa-server ipa-server-4.8.0-11.module+el8.1.0+4247+9f3fd721.x86_64
第3章 IdM コマンドラインユーティリティーの概要
以下のセクションでは、Identity Management (IdM) コマンドラインユーティリティーの基本的な使用方法を説明します。
前提条件
IdM サーバーをインストールしていて、アクセス可能である。
詳細は『Identity Management のインストール』を参照してください。
IPA コマンドラインインターフェースを使用する場合は、有効な Kerberos チケットを使用して IdM に対してを認証している。
有効な Kerberos チケットを取得する方法は、「コマンドラインから Identity Management へのログイン」を参照してください。
3.1. IPA コマンドラインインターフェースとは
IPA コマンドラインインターフェース (CLI) は、Identity Management (IdM) の管理向けの基本的なコマンドラインインターフェースです。
これは、新しいユーザーを追加するために、ipa user-add
コマンドなど、IdM の管理に使用する多数のサブコマンドに対応します。
IPA CLI では以下を行うことができます。
- ネットワーク内のユーザー、グループ、ホスト、その他のオブジェクトを追加、管理、または削除する。
- 証明書を管理する。
- エントリーを検索する。
- オブジェクトを表示し、オブジェクト一覧を表示する。
- アクセス権を設定する。
- 正しいコマンド構文でヘルプを取得する。
3.2. IPA のヘルプとは
IPA ヘルプは、IdM サーバー用の組み込みドキュメントシステムです。
IPA コマンドラインインターフェース (CLI) は、読み込んだ IdM プラグインモジュールから、利用可能なヘルプトピックを生成します。IPA ヘルプを正常に実行する必要がある場合は、以下が必要になります。
- IdM サーバーがインストールされ、実行している。
- 有効な Kerberos チケットで認証されている。
オプションを指定せずに ipa help
コマンドを実行すると、基本的なヘルプの使用方法と、一般的なコマンドの例が表示されます。
オプションを使用したヘルプの実行には、以下の構文があります。
$ ipa help [TOPIC | COMMAND | topics | commands]
-
[]
- 括弧は、すべてのパラメーターが任意であることを示しており、ipa help
のみを入力すれば、コマンドが実行できます。 -
|
- パイプ文字は または の意味になります。そのため、基本的なipa help
コマンドで TOPIC または COMMAND、もしくは topics または commandsを使用できます。 -
topics
-ipa help topics
コマンドを実行でき、適切に実行できます。このコマンドは、IPA ヘルプでカバーしたトピックの一覧 (user
、cert
、server
など多数) を表示します。 -
TOPIC
- 大文字の TOPIC は変数を意味します。したがって、ipa help user
など、特定のトピックを使用できます。 -
commands
-ipa help commands
コマンドを実行すると、正しく実行できます。このコマンドは、IPA ヘルプ (user-add
、ca-enable
、server-show
など多数) でカバーされるコマンドの一覧を表示します。 -
COMMAND
- 大文字の COMMAND は変数を意味するため、ipa help user-add
など、特定のコマンドを使用できます。
3.3. IPA ヘルプトピックの使用
次の手順は、コマンドラインインターフェースで IPA ヘルプの使用方法を説明します。
手順
- 端末を開き、IdM サーバーに接続します。
ヘルプに記載されているトピックの一覧を表示するには、
ipa help topics
を実行します。$ ipa help topics
以下のいずれかのトピックを選択して、以下のパターンに従ってコマンドを実行します。
ipa help [topic_name]
は、topic_name
文字列ではなく、上の手順で取得したリストからトピックのいずれかを追加します。この例では、
user
トピックを使用します。$ ipa help user
IPA help コマンドが長すぎるため、テキスト全体を表示できない場合は、以下の構文を使用します。
$ ipa help user | less
スクロールダウンすれば、ヘルプ全体を表示できます
IPA CLI は、ユーザー
トピックのヘルプページを表示します。概要を読むと、トピックのコマンドを使用するパターンに関して、多くの例を確認できます。
3.4. IPA ヘルプコマンドの使用
次の手順は、コマンドラインインターフェースで IPA ヘルプコマンドの作成方法を説明します。
手順
- 端末を開き、IdM サーバーに接続します。
ヘルプで使用できるコマンドの一覧を表示するには、
ipa help commands
コマンドを実行します。$ ipa help commands
コマンドのいずれかを選択し、次のように help コマンドを作成します。
<COMMAND>
文字列の代わりに、ipa help <COMMAND>
を使用すると、直前の手順に一覧表示されているコマンドのいずれかを追加します。$ ipa help user-add
関連情報
-
ipa
の man ページ
3.5. IPA コマンドの構造
IPA CLI は、以下のタイプのコマンドを区別します。
- 組み込みコマンド - 組み込みコマンドはすべて、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]
)。
3.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
コマンドを実行してください。
3.7. IPA コマンドで IdM のユーザーアカウントの変更
各ユーザーアカウントの多くのパラメーターを変更できます。たとえば、新しいパスワードをユーザーに追加できます。
基本的なコマンド構文は user-add
構文とは異なります。たとえば、パスワードを追加するなど、変更を実行する既存のユーザーアカウントを定義する必要があるためです。
前提条件
- IdM サーバーでユーザーアカウントを変更するために、管理者権限を有している。
手順
- 端末を開き、IdM サーバーに接続します。
パスワードを追加するコマンドを入力します。
$ ipa user-mod euser --password
このコマンドは、新しいパスワードを追加できるスクリプトを実行します。
- 新しいパスワードを入力し、Enter キーを押します。
ユーザー名を追加したら、ユーザーアカウントが IdM データベースに追加され、IPA CLI が以下のログを出力します。
---------------------- Modified user "euser" ---------------------- User login: euser First name: Example Last name: User Home directory: /home/euser Principal name: euser@IDM.EXAMPLE.COM Principal alias: euser@IDM.EXAMPLE.COM Email address: euser@idm.example.com UID: 427200006 GID: 427200006 Password: True Member of groups: ipausers Kerberos keys available: True
これでユーザーパスワードがアカウントに対して設定され、ユーザーが IdM にログインできます。
関連情報
-
パラメーターの詳細は、
ipa help user-mod
コマンドを実行してください。
3.8. IdM ユーティリティーに値をリスト形式で提供する方法
Identity Management (IdM) は、多値属性の値をリスト形式で保存します。
IdM は、多値リストを提供する次の方法に対応します。
同じコマンド呼び出しで、同じコマンドライン引数を複数回指定します。
$ ipa permission-add --right=read --permissions=write --permissions=delete ...
または、一覧を中括弧で囲むこともできます。この場合、シェルは展開を実行します。
$ ipa permission-add --right={read,write,delete} ...
上記の例では、パーミッションをオブジェクトに追加する permission-add
コマンドを表示します。この例では、このオブジェクトは記載されていません。…
の代わりに、権限を追加するオブジェクトーを追加する必要があります。
このような多値属性をコマンド行から更新すると、IdM は、前の値リストを新しいリストで完全に上書きします。したがって、多値属性を更新するときは、追加する 1 つの値だけでなく、新しいリスト全体を指定する必要があります。
上記のコマンドでは、パーミッションのリストには、読み取り、書き込み、および削除が含まれます。permission-mod
コマンドでリストを更新する場合は、すべての値を追加する必要があります。すべての値を追加しないと、追加されていない値は削除されます。
例 1: - ipa permission-mod
コマンドは、以前に追加した権限をすべて更新します。
$ ipa permission-mod --right=read --right=write --right=delete ...
または
$ ipa permission-mod --right={read,write,delete} ...
例 2 - ipa permission-mod
コマンドは、コマンドに含まれないため、--right=delete
引数を削除します。
$ ipa permission-mod --right=read --right=write ...
または
$ ipa permission-mod --right={read,write} ...
3.9. IdM ユーティリティーで特殊文字を使用する方法
特殊文字を含むコマンドライン引数を ipa
コマンドに渡す場合は、この文字をバックスラッシュ (\) でエスケープします。たとえば、一般的な特殊文字には、山かっこ (< および >)、アンパサンド (&)、アスタリスク (*)、または垂直バー (|) があります。
たとえば、アスタリスク (*) をエスケープするには、次のコマンドを実行します。
$ ipa certprofile-show certificate_profile --out=exported\*profile.cfg
シェルが特殊文字を正しく解析できないため、エスケープしていない特殊文字をコマンドに含めると、予想通りに機能しなくなります。
第4章 コマンドラインから Identity Management エントリーの検索
次のセクションでは、オブジェクトの検索または表示に役立つ IPA コマンドの使用方法を説明します。
4.1. IdM エントリーの一覧表示の概要
特定のタイプの IdM エントリーを検索するのに役に立つ ipa *-find
コマンドを説明します。
すべての find
コマンドを表示するには、次の ipa help コマンドを使用します。
$ ipa help commands | grep find
特定のユーザーが IdM データベースに含まれているかどうかの確認が必要になる場合があります。次のコマンドを使用すると、ユーザーを一覧表示できます。
$ ipa user-find
指定の属性にキーワードが含まれるユーザーグループの一覧を表示するには、次のコマンドを実行します。
$ ipa group-find keyword
たとえば、ipa group-find admin
コマンドは、名前または説明に文字列 admin
が含まれるグループの一覧を表示します。
---------------- 3 groups matched ---------------- Group name: admins Description: Account administrators group GID: 427200002 Group name: editors Description: Limited admins who can edit other users GID: 427200002 Group name: trust admins Description: Trusts administrators group
ユーザーグループの検索の際には、特定のユーザーを含むグループに検索結果を絞り込むことも可能です。
$ ipa group-find --user=user_name
また、特定のユーザーを含まないグループを検索するには、次のコマンドを実行します。
$ ipa group-find --no-user=user_name
4.2. 特定のエントリーの詳細の表示
ipa *-show
コマンドを使用して、特定の IdM エントリーの詳細を表示します。
手順
ホスト server.example.com に関する詳細を表示します。
$ ipa host-show server.example.com Host name: server.example.com Principal name: host/server.example.com@EXAMPLE.COM ...
4.3. 検索サイズおよび時間制限の調整
IdM ユーザーの一覧を要求するなど、一部のクエリーでは、エントリー数が大量に返される場合があります。この検索操作を調整して、ipa user-find
などの ipa *-find
コマンドの実行時や、Web UI で対応する一覧を表示する際に、全体的なサーバーのパフォーマンスを向上できます。
- Search size limit
クライアントの CLI または IdM Web UI にアクセスするブラウザーからサーバーに送信されるリクエストで返される最大エントリー数を定義します。
デフォルト - 100 エントリー
- Search time limit
検索の実行までにサーバーが待機する最大時間 (秒) を定義します。検索がこの制限に到達したら、サーバーは検索を停止し、停止するまでの期間に検出されたエントリーを返します。
デフォルト - 2 秒
この値が -1
に設定されていると、IdM は、検索時に制限を適用しません。
検索のサイズや時間制限を高く設定しすぎると、サーバーのパフォーマンスに影響を及ぼすことがあります。
4.3.1. コマンドラインで検索サイズおよび時間制限の調整
以下の手順では、コマンドラインで検索サイズと時間制限を調整する方法について説明します。
- システム全体
- 特定のエントリーの場合
手順
現在の検索時間およびサイズ制限を CLI で表示するには、
ipa config-show
コマンドを使用します。$ ipa config-show Search time limit: 2 Search size limit: 100
すべてのクエリーに対して グローバルに 制限を調整するには、
ipa config-mod
コマンドを使用して、--searchrecordslimit
および--searchtimelimit
のオプションを追加します。以下に例を示します。$ ipa config-mod --searchrecordslimit=500 --searchtimelimit=5
-
特定のクエリに対してのみ 一時的に 制限を調整するには、コマンドに
--sizelimit
または--timelimit
オプションを追加してください。以下に例を示します。
$ ipa user-find --sizelimit=200 --timelimit=120
4.3.2. Web UI で検索サイズおよび時間制限の調整
以下の手順では、IdM Web UI でグローバル検索のサイズと時間制限を調整する方法について説明します。
手順
- IdM Web UI にログインします。
IPA Server をクリックします。
- IPA Server タブで、Configuration をクリックします。
Search Options エリアに必要な値を設定します。
デフォルト値は以下の通りです。
- 検索サイズの制限 - 100 エントリー
- 検索時間の制限 - 2 秒
ページ上部にある Save をクリックします。
第5章 Web ブラウザーで IdM Web UI へのアクセス
次のセクションでは、IdM (Identity Management) Web UI の概要と、そのアクセス方法を説明します。
5.1. IdM Web UI とは
IdM (Identity Management) Web UI は、IdM コマンドラインツールのグラフィカルな代替手段である、IdM 管理用の Web アプリケーションです。
IdM Web UI には、以下のユーザーとしてアクセスできます。
- IdM ユーザー - IdM サーバーでユーザーに付与されている権限に応じて制限されている一連の操作。基本的に、アクティブな IdM ユーザーは IdM サーバーにログインして自身のアカウントを設定できます。その他のユーザーまたは IdM サーバーの設定は変更できません。
- 管理者 - IdM サーバーへのフルアクセス権
- Active Directory ユーザー - ユーザーに付与されている権限に応じた一連の操作Active Directory ユーザーは、Identity Management の管理者になれません。詳細は「AD ユーザーを有効にして IdM を管理する」を参照してください。
5.2. Web UI へのアクセスに対応している Web ブラウザー
Identity Management (IdM) は、Web UI への接続に、以下のブラウザーをサポートします。
- Mozilla Firefox 38 以降
- Google Chrome 46 以降
ブラウザーで TLS v1.3 を使用しようとすると、スマートカードで IdM Web UI にアクセスできなくなる場合があります。
[ssl:error] [pid 125757:tid 140436077168384] [client 999.999.999.999:99999] AH: verify client post handshake
[ssl:error] [pid 125757:tid 140436077168384] [client 999.999.999.999:99999] AH10158: cannot perform post-handshake authentication
[ssl:error] [pid 125757:tid 140436077168384] SSL Library Error: error:14268117:SSL routines:SSL_verify_client_post_handshake:extension not received
これは、最新バージョンのブラウザーで TLS Post-Handshake Authentication (PHA) がデフォルトで有効になっていないか、PHA をサポートしていないためです。スマートカード認証で IdM Web UI にアクセスする場合など、Web サイトの一部にのみ TLS クライアント証明書を必要とする場合は、PHA が必要です。
この問題を解決するには、/etc/httpd/conf.d/ssl.conf
設定ファイルの SSLProtocol
オプションに -TLSv1.3
を追加して、TLS v1.3 を無効にします。
SSLProtocol all -TLSv1 -TLSv1.1 -TLSv1.3
IdM はssl.conf
ファイルを管理するため、パッケージの更新時にそのコンテンツが上書きされる可能性があることに注意してください。IdM パッケージの更新後に、カスタム設定を確認します。
5.3. Web UI へのアクセス
次の手順では、パスワードを使用して、IdM (Identity Management) Web UI に最初にログインする方法を説明します。
最初のログイン後に、IdM サーバーを認証するように設定できます。
Kerberos チケット
詳細は、Kerberos authentication in Identity Management を参照してください。
スマートカード
詳細は、「スマートカード認証用の IdM サーバーの設定」を参照してください。
ワンタイムパスワード (OTP) - パスワードと組み合わせることができ、Kerberos 認証に利用されます。
詳細は、One time password (OTP) authentication in Identity Management を参照してください。
手順
ブラウザーのアドレスバーに、IdM サーバーの URL を入力します。名前は次の例のようになります。
https://server.example.com
server.example.com
を、IdM サーバーの DNS 名に変更するだけです。これで、ブラウザーに IdM Web UI ログイン画面が開きます。
- サーバーが応答しない、またはログイン画面が開かない場合は、接続している IdM サーバーの DNS 設定を確認してください。
自己署名証明書を使用する場合は、ブラウザーに警告が表示されます。証明書を確認し、セキュリティー例外を許可して、ログインを続行します。
セキュリティーの例外を回避するために、認証局が署名した証明書をインストールします。
Web UI ログイン画面で、IdM サーバーのインストール時に追加した管理者アカウントの認証情報を入力します。
詳細は「Identity Management サーバーのインストール: 統合 DNS と統合 CA の場合」を参照してください。
IdM サーバーに、個人アカウントの認証情報がすでに入力されている場合は、それを入力できます。
- Log in をクリックします。
ログインに成功したら、IdM サーバーの設定を開始できます。
第6章 Web UI で IdM にログイン: Kerberos チケットの使用
以下のセクションでは、IdM Web UI への Kerberos ログインを有効にする環境の初期設定と、Kerberos 認証を使用した IdM へのアクセスを説明します。
前提条件
ネットワーク環境にインストールしている IdM サーバー
詳細は『Red Hat Enterprise Linux 8 の Identity Management のインストール』を参照してください。
6.1. Identity Management における Kerberos 認証
Identity Management (IdM) は、シングルサインオンに対応する Kerberos プロトコルを使用します。シングルサインオン認証により、ユーザーが正しいユーザー名およびパスワードを一度入力すれば、再度システムに認証情報を求められることなく、Identity Management サービスにアクセスできます。
DNS および証明書の設定が適切に設定されている場合は、インストール直後に、IdM サーバーが Kerberos 認証を提供します。詳細は『Identity Management のインストール』を参照してください。
ホストで Kerberos 認証を使用するには、以下をインストールします。
IdM クライアント
詳細は『Identity Management クライアントをインストールするためのシステムの準備』を参照してください。
- krb5conf パッケージ
6.2. kinit による IdM への手動ログイン
この手順では、kinit ユーティリティーを使用して、Identity Management (IdM) 環境を手動で認証する方法を説明します。kinit ユーティリティーは、IdM ユーザーの代わりに Kerberos の TGT (Ticket-Granting Ticket) を取得して、キャッシュに格納します。
この手順は、最初の Kerberos TGT を破棄したか、有効期限が切れている場合にのみ使用します。ローカルマシンに、IdM ユーザーとしてログインすると、IdM に自動的にログインします。これは、ログイン後に IdM リソースにアクセスするのに kinit ユーティリティーを使用する必要がないことを示しています。
手順
IdM へのログイン
ローカルシステムに現在ログインしているユーザーのユーザー名で、(ユーザー名を指定せずに) kinit を使用します。たとえば、ローカルシステムにログインしているユーザーが
example_user
の場合は、次のコマンドを実行します。[example_user@server ~]$ kinit Password for example_user@EXAMPLE.COM: [example_user@server ~]$
ローカルユーザーのユーザー名と、IdM のユーザーエントリーが一致しないと、認証に失敗します。
[example_user@server ~]$ kinit kinit: Client 'example_user@EXAMPLE.COM' not found in Kerberos database while getting initial credentials
ローカルユーザー名に対応しない Kerberos プリンシパルを使用して、
kinit
ユーティリティーに必要なユーザー名を渡します。たとえば、admin
ユーザーとしてログインするには、次のコマンドを実行します。[example_user@server ~]$ kinit admin Password for admin@EXAMPLE.COM: [example_user@server ~]$
必要に応じて、ログインが成功したことを確認するには、klist ユーティリティーを使用して、キャッシュした TGT を表示します。以下の例では、キャッシュに
example_user
プリンシパルのチケットが含まれています。これは、このホストでは IdM サービスにアクセスするのは、example_user
にのみ許可されていることを示しています。$ klist Ticket cache: KEYRING:persistent:0:0 Default principal: example_user@EXAMPLE.COM Valid starting Expires Service principal 11/10/2019 08:35:45 11/10/2019 18:35:45 krbtgt/EXAMPLE.COM@EXAMPLE.COM
6.3. Kerberos 認証用のブラウザーの設定
Kerberos チケットによる認証を有効にするには、ブラウザーの設定が必要になることもあります。
以下の手順は、IdM ドメインにアクセスする Kerberos ネゴシエーションに対応するのに役に立ちます。
Kerberos に対応する方法はブラウザーによって異なるため、異なる設定が必要です。IdM Web UI には、次のブラウザーに関するガイドラインが含まれています。
- Firefox
- Chrome
手順
- Web ブラウザーで、WebUI ログインダイアログを開きます。
Web UI のログイン画面で、ブラウザー設定のリンクをクリックします。
設定ページの手順に従います。
設定が完了したら、IdM Web UI に戻り、ログイン をクリックします。
6.4. Kerberos チケットで Web UI へのログイン
この手順では、Kerberos の TGT (ticket-granting ticket) を使用して、IdM Web UI にログインする方法を説明します。
TGT は、事前定義された時間で有効期限が切れます。デフォルトの時間間隔は 24 時間で、IdM Web UI でそれを変更できます。
期限が切れたら、チケットを更新する必要があります。
- kinit コマンドの使用
- Web UI ログインダイアログで、IdM ログイン認証情報を使用
手順
IdM Web UI を開きます。
Kerberos 認証が正しく機能し、有効なチケットがある場合は、自動的に認証されて Web UI が開きます。
チケットの有効期限が切れている場合は、最初に資格情報を使用して認証する必要があります。ただし、次からはログインダイアログを開かずに IdM Web UI が自動的に開きます。
エラーメッセージ
Authentication with Kerberos failed
が表示された場合は、ブラウザーが Kerberos 認証用に設定されていることを確認してください。Kerberos 認証用のブラウザーの設定 を参照してください。
6.5. Kerberos 認証用の外部システムの設定
本セクションでは、Identity Management (IdM) ユーザーが自身の Kerberos 認証情報を使用して、外部システムから IdM にログインするように外部システムを設定する方法を説明します。
外部システムの Kerberos 認証を有効にすることは、インフラストラクチャーに、複数のレルムまたは重複ドメインが含まれている場合に特に便利です。また、ipa-client-install
を実行してシステムを IdM ドメインに登録していない場合にも便利です。
IdM ドメインのメンバーではないシステムから IdM への Kerberos 認証を有効にするには、IdM 固有の Kerberos 設定ファイルを外部システムに定義します。
前提条件
外部システムに
krb5-workstation
パッケージがインストールされている。パッケージがインストールされているかどうかを確認するには、次の CLI コマンドを使用します。
# yum list installed krb5-workstation Installed Packages krb5-workstation.x86_64 1.16.1-19.el8 @BaseOS
手順
IdM サーバーから外部システムに
/etc/krb5.conf
ファイルをコピーします。以下に例を示します。# scp /etc/krb5.conf root@externalsystem.example.com:/etc/krb5_ipa.conf
警告外部マシンにある既存の
krb5.conf
ファイルは上書きしないでください。外部システムで、コピーした IdM の Kerberos 設定ファイルを使用するように、端末セッションを設定します。
$ export KRB5_CONFIG=/etc/krb5_ipa.conf
KRB5_CONFIG
変数は、ログアウトまで一時的に存在します。ログアウト時に削除されないように、この変数のファイル名を変えてエクスポートします。-
/etc/krb5.conf.d/
ディレクトリーの Kerberos 設定部分を、外部システムにコピーします。 - Kerberos 認証用のブラウザーの設定 の説明に従って、外部システムでブラウザーを設定します。
外部システムのユーザーが、kinit
ユーティリティーを使用して IdM サーバーで認証できるようになりました。
6.6. Active Directory ユーザーの Web UI ログイン
Active Directory ユーザーに対して Web UI ログインを有効にするには、デフォルトの信頼ビュー で、Active Directory の各ユーザーに対して ID のオーバーライドを定義します。以下に例を示します。
[admin@server ~]$ ipa idoverrideuser-add 'Default Trust View' ad_user@ad.example.com
第7章 ワンタイムパスワードを使用した Identity Management Web UI へのログイン
IdM Web UI へのアクセスは、いくつかの方法を使用して保護できます。基本的なものはパスワード認証です。
パスワード認証のセキュリティーを向上させるために、2 つ目の手順を追加して、自動生成ワンタイムパスワード (OTP) を要求できます。最も一般的な使用方法は、ユーザーアカウントに関連付けられたパスワードと、ハードウェアまたはソフトウェアのトークンにより生成された期限付きワンタイムパスワードを組み合わせることです。
以下のセクションでは、次のことができます。
- IdM で OTP 認証がどう機能するかを理解する。
- IdM サーバーで OTP 認証を設定する。
- OTP トークンを作成し、そのトークンを、電話の FreeOTP アプリと同期する。
- ユーザーパスワードとワンタイムパスワードの組み合わせて、IdM Web UI に対して認証する。
- Web UI でトークンを再同期する。
7.1. 前提条件
7.2. Identity Management におけるワンタイムパスワード (OTP) 認証
ワンタイムパスワードにより、認証セキュリティーに関する手順が追加されます。認証では、自身のパスワードと、自動生成されたワンタイムパスワードが使用されます。
ワンタイムパスワードを生成するには、ハードウェアまたはソフトウェアのトークンを使用できます。IdM は、ソフトウェアトークンとハードウェアトークンの両方をサポートします。
Identity Management は、以下にある、2 つの標準 OTP メカニズムに対応しています。
- HMAC ベースのワンタイムパスワード (HOTP) アルゴリズムは、カウンターに基づいています。HMAC は、Hashed Message Authentication Code (ハッシュメッセージ認証コード) を表しています。
- 時間ベースのワンタイムパスワード (TOTP) アルゴリズムは、時間ベースの移動要素に対応する HOTP の拡張機能です。
IdM は、Active Directory 信頼ユーザーの OTP ログインに対応していません。
7.3. Web UI でワンタイムパスワードの有効化
IdM Web UI では、ワンタイムパスワードを生成するようにハードウェアまたはソフトウェアデバイスを設定できます。
ワンタイムパスワードは、ログインダイアログの専用フィールドで、通常のパスワードの直後に入力されます。
ユーザー設定で、OTP 認証を有効にできるのは管理者だけです。
前提条件
- 管理権限
手順
- ユーザー名およびパスワードを使用して IdM Web UI にログインします。
Identity → Users → Active users タブを開きます。
- ユーザー名をクリックして、ユーザー設定を開きます。
- User authentication types で、Two factor authentication (password + OTP) を選択します。
- Save をクリックします。
この時点で、OTP 認証は IdM サーバーで有効になります。
ユーザー (1 人または複数) が、新しいトークン ID を自身のユーザーアカウントに割り当てる必要があります。
7.4. Web UI で OTP トークンの追加
次のセクションは、IdM Web UI およびソフトウェアトークンジェネレーターに、トークンを追加するのに役立ちます。
前提条件
- IdM サーバーでアクティブなユーザーアカウント。
- 管理者が、IdM Web UI の特定のユーザーアカウントに対して OTP を有効にしている。
- FreeOTP などの OTP トークンを生成するソフトウェアデバイス。
手順
- ユーザー名とパスワードを使用して IdM Web UI にログインします。
- Authentication → OTP Tokens タブを開いて、携帯電話でトークンを作成します。
Add をクリックします。
Add OTP token ダイアログボックスに何も入力せず、Add をクリックします。
この段階で、IdM サーバーはデフォルトパラメーターを使用してトークンを作成し、QR コード付きページを開きます。
- QR コードを携帯電話にコピーします。
- OK をクリックして QR コードを閉じます。
これで、ワンタイムパスワードを生成して、IdM Web UI にログインできるようになりました。
7.5. ワンタイムパスワードで Web UI にログイン
この手順では、ワンタイムパスワード (OTP) を使用した IdM Web UI への最初のログインを説明します。
前提条件
OTP 認証を使用しているユーザーアカウントに対して、Identity Management サーバーで OTP 設定が有効になっている。管理者およびユーザー自身が、OTP を有効にできる。
OTP 設定を有効にする場合は、Web UI でワンタイムパスワードの有効化 を参照してください。
- 設定された OTP トークンを生成するハードウェアまたはソフトウェアのデバイス
手順
- Identity Management ログイン画面で、自身のユーザー名、または IdM サーバー管理者アカウントのユーザー名を入力します。
- 上記で入力したユーザーのパスワードを追加します。
- デバイスでワンタイムパスワードを生成します。
- パスワードの直後にワンタイムパスワードを入力します (空白文字は追加しない)。
Log in をクリックします。
認証に失敗した場合は、OTP トークンを同期します。
CA が自己署名証明書を使用する場合は、ブラウザーに警告が表示されます。証明書を確認し、セキュリティー例外を許可して、ログインを続行します。
IdM Web UI が開かない場合は、Identity Management サーバーの DNS 設定を確認します。
ログインが成功すると、IdM Web UI が表示されます。
7.6. Web UI で OTP トークンの同期
OTP (ワンタイムパスワード) でのログインに失敗した場合、OTP トークンは正しく同期しません。
以下のテキストは、トークンの再同期を説明します。
前提条件
- ログイン画面を開いている。
- 設定した OTP トークンを生成するデバイス。
手順
IdM Web UI ログイン画面で、Sync OTP Token をクリックします。
- ログイン画面で、ユーザー名と、Identity Management パスワードを入力します。
- ワンタイムパスワードを生成し、First OTP フィールドに入力します。
- ワンタイムパスワードをもう一度生成し、Second OTP フィールドに入力します。
必要に応じて、トークン ID を入力してします。
- Sync OTP Token をクリックします。
同期に成功したら、IdM サーバーにログインできます。
7.7. 期限切れパスワードの変更
Identity Management の管理者は、ユーザが次回ログインする時にパスワードを変更するように強制できます。これを設定すると、パスワードを変更しないと IdM Web UI にログインできなくなります。
パスワードの有効期限は、Web UI に初めてログインしたときに発生する可能性があります。
有効期限のパスワードのダイアログが表示されたら、手順の指示に従ってください。
前提条件
- ログイン画面を開いている。
- IdM サーバーへのアクティブなアカウント。
手順
- パスワード有効期限のログイン画面に、ユーザー名を入力します。
- 上記で入力したユーザーのパスワードを追加します。
ワンタイムパスワード認証を使用する場合は、OTP フィールドにワンタイムパスワードを生成します。
OTP 認証を有効にしていない場合は、このフィールドを空白のままにします。
- 確認のために新しいパスワードを 2 回入力します。
Reset Password をクリックします。
パスワード変更が成功すると、通常のログインダイアログが表示されます。新しいパスワードでログインします。
第8章 IdM で SSSD を使用した認証のトラブルシューティング
Identity Management (IdM) 環境の認証には、さまざまなコンポーネントが含まれます。
IdM クライアントで、以下を行います。
- SSSD サービス
- Name Services Switch (NSS)
- PAM (プラグ可能な認証モジュール)
IdM サーバーで、以下を行います。
- SSSD サービス
- IdM Directory Server。
- IdM Kerberos Key Distribution Center (KDC)
Active Directory (AD) ユーザーとして認証している場合は、以下を行います。
- AD ドメインコントローラー上の Directory Server。
- AD ドメインコントローラー上の Kerberos サーバー
ユーザーを認証するには、SSSD サービスで以下の機能を実行できる必要があります。
- 認証サーバーからユーザー情報を取得します。
- ユーザーに認証情報を求められ、それらの認証情報を認証サーバーに渡し、結果を処理します。
以下のセクションでは、ユーザー情報を保存する SSSD サービスとサーバー間の情報フロー方法を説明し、環境で失敗した認証試行のトラブルシューティングを行うことができます。
- SSSD で IdM ユーザー情報を取得するデータフロー
- SSSD で AD ユーザー情報を取得する際のデータフロー
- IdM で SSSD を使用してユーザーとして認証する場合にデータフロー
- 認証問題の範囲の制限
- SSSD ログファイルおよびログレベル
- sssd.conf ファイルで SSSD の詳細なロギングの有効化
- sssctl コマンドを使用した SSSD の詳細なロギングの有効化
- SSSD サービスからデバッグログを収集し、IdM サーバーによる認証問題のトラブルシューティング
- SSSD サービスからデバッグログを収集し、IdM クライアントによる認証問題のトラブルシューティング
- SSSD バックエンドでのクライアント要求の追跡
8.1. SSSD で IdM ユーザー情報を取得するデータフロー
以下の図は、getent passwd <idm_user_name>
コマンドを使用して IdM ユーザー情報の要求時に IdM クライアントと IdM サーバーとの間の情報フローを簡単に説明します。
-
getent
コマンドは、libc
ライブラリーからgetpwnam
呼び出しをトリガーします。 -
libc
ライブラリーは、/etc/nsswitch.conf
設定ファイルを参照して、どのサービスがユーザー情報を提供するかを確認し、SSSD サービスのエントリーsss
を検出します。 -
libc
ライブラリーは、nss_sss
モジュールを開きます。 -
nss_sss モジュールは、ユーザー情報のメモリーマップキャッシュを確認します。データがキャッシュに存在する場合は、
nss_sss
モジュールがそれを返します。 -
ユーザー情報が memory-mapped キャッシュにない場合、リクエストは SSSD
sssd_nss
レスポンダープロセスに渡されます。 -
SSSD サービスはキャッシュをチェックします。データがキャッシュに存在し、有効な場合は、
sssd_nss
レスポンダーがキャッシュからデータを読み取って、アプリケーションに返します。 -
データがキャッシュにない場合や期限切れである場合、
sssd_nss
レスポンダーは適切なバックエンドプロセスに対してクエリーを実行し、応答を待機します。SSSD サービスは、sssd.conf
設定ファイルでid_provider=ipa
を設定して有効にした、IdM 環境の IPA バックエンドを使用します。 -
sssd_be
バックエンドプロセスは IdM サーバーに接続して、IdM LDAP Directory Server から情報を要求します。 - IdM サーバーの SSSD バックエンドは、IdM クライアントの SSSD バックエンドプロセスに対応します。
- クライアントの SSSD バックエンドは、生成されるデータを SSSD キャッシュに保存し、キャッシュが更新されたレスポンダープロセスを警告します。
-
sssd_nss
フロントエンドレスプロセスが SSSD キャッシュから情報を取得します。 -
sssd_nss
レスポンダーは、nss_sss
レスポンダーにユーザー情報を送信し、リクエストを完了します。 -
libc
ライブラリーは、要求したアプリケーションにユーザー情報を返します。
8.2. SSSD で AD ユーザー情報を取得する際のデータフロー
IdM 環境と Active Directory( AD) ドメインとの間でフォレスト間の信頼を確立した場合は、IdM クライアントの AD ユーザー情報を取得する際に情報フローが、AD ユーザーデータベースへの追加の手順とともに、IdM クライアントの AD ユーザー情報の取得時に非常に似ています。
以下の図は、getent passwd <ad_user_name@ad.example.com>
コマンドを使用してユーザーが AD ユーザーに関する情報を要求する際に、情報フローを簡素化します。この図には、SSSD で IdM ユーザー情報を取得するデータフロー が含まれません。IdM クライアントの SSSD サービス、IdM サーバーの SSSD サービス、および AD ドメインコントローラー上の LDAP データベースとの間の通信にフォーカスします。
- IdM クライアントは、AD ユーザー情報に関するローカルの SSSD キャッシュを検索します。
-
IdM クライアントにユーザー情報がない場合や、情報が古い場合に、クライアントの SSSD サービスが IdM サーバーの
extdom_extop
プラグインに問い合わせて、LDAP 拡張操作を実行し、情報を要求します。 - IdM サーバーの SSSD サービスは、ローカルキャッシュで AD ユーザー情報を検索します。
- IdM サーバーに SSSD キャッシュにユーザー情報がない場合や、その情報が古い場合は、LDAP 検索を実行して、AD ドメインコントローラーからユーザー情報を要求します。
- IdM サーバーの SSSD サービスは、AD ドメインコントローラーから AD ユーザー情報を受け取り、キャッシュに保存します。
-
extdom_extop
プラグインは、LDAP 拡張操作を完了する IdM サーバーの SSSD サービスから情報を受信します。 - IdM クライアントの SSSD サービスは、LDAP 拡張操作から AD ユーザー情報を受信します。
- IdM クライアントは、AD ユーザー情報を SSSD キャッシュに保存し、要求したアプリケーションに情報を返します。
8.3. IdM で SSSD を使用してユーザーとして認証する場合にデータフロー
IdM サーバーまたはクライアントでユーザーとして認証するには、以下のコンポーネントが必要です。
- sshd サービスなどの認証要求を開始するサービス
- PAM (プラグ可能な認証モジュール) ライブラリーとそのモジュール。
- SSSD サービス、そのレスポンダー、およびバックエンド。
- スマートカード認証が設定されている場合は、スマートカードリーダー。
認証サーバー:
- IdM ユーザーは、IdM Kerberos Key Distribution Center (KDC) に対して認証されます。
- Active Directory (AD) ユーザーは、AD ドメインコントローラー (DC) に対して認証されます。
以下の図は、コマンドラインの SSH サービスを介してホストにローカルでログインしようとすると、情報フローを簡単に認証する必要がある場合を示しています。
-
ssh
コマンドで認証を試みると、libpam
ライブラリーがトリガーされます。 libpam
ライブラリー は、認証の試行を要求するサービスに対応する/etc/pam.d/
ディレクトリーの PAM ファイルを参照します。この例では、ローカルホストの SSH サービス経由で認証されている例では、pam_sss.so
ライブラリーは/etc/pam.d/system-auth
設定ファイルを確認し、SSSD PAM のpam_sss.so
エントリーを検出します。auth sufficient pam_sss.so
-
利用可能な認証方法を判断するため、
libpam
ライブラリーはpam_sss
モジュールを開き、SSSD サービスのsssd _pam
PAM レスポンダーにSSS_PAM_PREAUTH
リクエスト を送信します。 -
スマートカード認証が設定されていると、SSSD サービスは一時的な
p11_child
プロセスを生成し、スマートカードを確認し、そこから証明書を取得します。 -
ユーザーにスマートカード認証が設定されていると、
sssd_pam
レスポンダーは、スマートカードの証明書とユーザーを照合します。sssd_pam
レスポンダーは、グループメンバーシップがアクセス制御に影響する可能性があるため、ユーザーが属するグループの検索も実行します。 -
sssd_pam
レスポンダーは、SSS_PAM_PREAUTH
要求をsssd_be
バックエンドレスに送信し、パスワードや 2 要素認証などのサーバーがサポートする認証方法を表示します。SSSD サービスが IPA レスポンダーを使用する IdM 環境では、デフォルトの認証方法は Kerberos です。この例では、ユーザーは簡単な Kerberos パスワードで認証されます。 -
sssd_be
レスポンダーは一時的なkrb5_child
プロセスを起動します。 -
krb5_child
プロセスは、IdM サーバーの KDC に連絡して、利用可能な認証方法を確認します。 KDC はリクエストに応答します。
-
krb5_child
プロセスは応答を評価し、結果をsssd_be
バックエンドプロセスに送信します。 -
sssd_be
バックエンドプロセスが結果を受け取ります。 -
sssd_pam
レスポンダーは結果を受け取ります。 -
pam_sss
モジュールは結果を受け取ります。
-
-
ユーザーにパスワード認証が設定されていると、
pam_sss
モジュールにより、パスワードの入力が求められます。スマートカード認証が設定されていると、pam_sss
モジュールにより、スマートカードの PIN の入力が求められます。 モジュールは、ユーザー名とパスワードを使用して
SSS_PAM_
AUTHENTICATE 要求を送信します。これは以下が実行されます。-
sssd_pam
レスポンダー。 -
sssd_be
バックエンドプロセス。
-
-
sssd_be
プロセスは、KDC に問い合わせる一時的なkrb5_child
プロセスを起動します。 -
krb5_child
process は、ユーザー名とパスワードを使用して KDC から Kerberos チケット保証チケット (TGT) の取得を試みます。 -
krb5_child
プロセスは、認証の試行の結果を受け取ります。 krb5_child
プロセス:- TGT を認証情報キャッシュに保存します。
-
sssd_be
バックエンドプロセスに認証結果を返します。
認証結果は
sssd_be
プロセスから以下を行います。-
sssd_pam
レスポンダー。 -
pam_sss
モジュール。
-
-
pam_sss
モジュールは、その他のアプリケーションが参照できるように、環境変数をユーザーの TGT の場所で設定します。
8.4. 認証問題の範囲の制限
ユーザーを正常に認証するには、ユーザー情報を保存するデータベースから SSSD サービスでユーザー情報を取得できる必要があります。以下の手順では、認証プロセスの異なるコンポーネントをテストする手順を説明します。これにより、ユーザーがログインできない場合に認証の問題のスコープを制限する方法を説明します。
手順
SSSD サービスおよびそのプロセスが実行していることを確認します。
[root@client ~]# pstree -a | grep sssd |-sssd -i --logger=files | |-sssd_be --domain implicit_files --uid 0 --gid 0 --logger=files | |-sssd_be --domain example.com --uid 0 --gid 0 --logger=files | |-sssd_ifp --uid 0 --gid 0 --logger=files | |-sssd_nss --uid 0 --gid 0 --logger=files | |-sssd_pac --uid 0 --gid 0 --logger=files | |-sssd_pam --uid 0 --gid 0 --logger=files | |-sssd_ssh --uid 0 --gid 0 --logger=files | `-sssd_sudo --uid 0 --gid 0 --logger=files |-sssd_kcm --uid 0 --gid 0 --logger=files
クライアントが IP アドレスを使用してユーザーデータベースサーバーに接続できることを確認します。
[user@client ~]$ ping <IP_address_of_the_database_server>
この手順が失敗した場合は、ネットワークとファイアウォール設定が、IdM クライアントとサーバー間の直接通信が許可されていることを確認してください。「firewalld の使用および設定」を参照してください。
クライアントが、完全修飾ホスト名を使用して IdM LDAP サーバー (IdM ユーザー用) または AD ドメインコントローラー (AD ユーザーの場合) を検出して連絡できることを確認します。
[user@client ~]$ dig -t SRV _ldap._tcp.example.com @<name_server> [user@client ~]$ ping <fully_qualified_host_name_of_the_server>
この手順が失敗した場合は、
/etc/resolv.conf
ファイルを含む Dynamic Name Service (DNS) の設定を確認してください。「DNS サーバーの順序の設定」を参照してください。注記デフォルトでは、SSSD サービスは DNS サービス (SRV) レコードを介して LDAP サーバーと AD DC を自動的に検出しようとします。
sssd.conf
設定ファイルで以下のオプションを設定すると、SSSD サービスが特定のサーバーを使用するように制限できます。-
ipa_server = <fully_qualified_host_name_of_the_server>
-
ad_server = <fully_qualified_host_name_of_the_server>
-
ldap_uri = <fully_qualified_host_name_of_the_server>
このオプションを使用する場合は、そのオプションに記載されているサーバーと通信できることを確認します。
-
クライアントが LDAP サーバーに対して認証でき、
ldapsearch
コマンドでユーザー情報を取得できることを確認します。LDAP サーバーが
server.example.com
などの IdM サーバーである場合は、ホストの Kerberos チケットを取得し、ホスト Kerberos プリンシパルで認証されるデータベース検索を実行します。[user@client ~]$ kinit -t 'host/client.example.com@EXAMPLE.COM' [user@client ~]$ ldapsearch -LLL -Y GSSAPI -h server.example.com -b “dc=example,dc=com” uid=<user_name>
LDAP サーバーが
server.example.com
などの Active Directory (AD) Domain Controller (DC) サーバーである場合は、ホストの Kerberos チケットを取得し、ホスト Kerberos プリンシパルで認証されるデータベース検索を実行します。[user@client ~]$ kinit -t 'CLIENT$@AD.EXAMPLE.COM' [user@client ~]$ ldapsearch -LLL -Y GSSAPI -h server.ad.example.com -b “dc=example,dc=com” sAMAccountname=<user_name>
LDAP サーバーがプレーン LDAP サーバーであり、
sssd.conf
ファイルにldap_default_bind_dn
およびldap_default_authtok
オプションを設定した場合は、同じldap_default_bind_dn
アカウントとして認証されます。[user@client ~]$ ldapsearch -xLLL -D "cn=ldap_default_bind_dn_value" -W -h ldapserver.example.com -b “dc=example,dc=com” uid=<user_name>
この手順が失敗した場合は、データベース設定で、ホストが LDAP サーバーを検索できることを確認します。
SSSD サービスは Kerberos 暗号化を使用するため、ログインできないユーザーとして Kerberos チケットを取得できます。
LDAP サーバーが IdM サーバーの場合:
[user@client ~]$ kinit <user_name>
LDAP サーバーデータベースが AD サーバーの場合:
[user@client ~]$ kinit <user_name@AD.EXAMPLE.COM>
この手順が失敗した場合は、Kerberos サーバーが適切に動作し、すべてのサーバーが同期され、ユーザーアカウントがロックされていないことを確認します。
コマンドラインでユーザー情報を取得できることを確認します。
[user@client ~]$ getent passwd <user_name> [user@client ~]$ id <user_name>
この手順が失敗した場合は、クライアントの SSSD サービスがユーザーデータベースから情報を受信できることを確認します。
-
/var/log/messages
ログファイルのエラーを確認します。 - SSSD サービスで詳細なロギングを有効にし、デバッグログを収集して、問題のソースに関するログを確認します。
- (オプション) Red Hat テクニカルサポートケースを作成し、収集したトラブルシューティング情報を提供します。
-
sssctl
ユーティリティーを使用して、ユーザーがログインできることを確認します。[user@client ~]$ sssctl user-checks -a auth -s ssh <user_name>
この手順が失敗した場合は、PAM 設定、IdM HBAC ルール、IdM RBAC ルールなどの承認設定を確認します。
-
/var/log/secure
ログファイルおよび/var/log/messages
ログファイルで認証エラーを確認します。 - SSSD サービスで詳細なロギングを有効にし、デバッグログを収集して、問題のソースに関するログを確認します。
- (オプション) Red Hat テクニカルサポートケースを作成し、収集したトラブルシューティング情報を提供します。
-
8.5. SSSD ログファイルおよびログレベル
それぞれの SSSD サービスは、/var/log/sssd/
ディレクトリーに独自のログファイルを記録します。example.com
IdM ドメインの IdM サーバーのログファイルは、以下のようになります。
[root@server ~]# ls -l /var/log/sssd/ total 620 -rw-------. 1 root root 0 Mar 29 09:21 krb5_child.log -rw-------. 1 root root 14324 Mar 29 09:50 ldap_child.log -rw-------. 1 root root 212870 Mar 29 09:50 sssd_example.com.log -rw-------. 1 root root 0 Mar 29 09:21 sssd_ifp.log -rw-------. 1 root root 0 Mar 29 09:21 sssd_implicit_files.log -rw-------. 1 root root 0 Mar 29 09:21 sssd.log -rw-------. 1 root root 219873 Mar 29 10:03 sssd_nss.log -rw-------. 1 root root 0 Mar 29 09:21 sssd_pac.log -rw-------. 1 root root 13105 Mar 29 09:21 sssd_pam.log -rw-------. 1 root root 9390 Mar 29 09:21 sssd_ssh.log -rw-------. 1 root root 0 Mar 29 09:21 sssd_sudo.log
8.5.1. SSSD ログファイルの目的
krb5_child.log
- Kerberos 認証に関連する有効期限の短いヘルパープロセスのログファイル。
ldap_child.log
- LDAP サーバーとの通信用の Kerberos チケットの取得に関連する短期ヘルパープロセスのログファイル。
sssd_<example.com>.log
sssd.conf
ファイルのドメインセクションごとに、SSSD サービスは LDAP サーバーとの通信に関する情報を別のログファイルに記録します。たとえば、example.com
という名前の IdM ドメインがある環境では、SSSD サービスはsssd_example.com.log
という名前のファイルのログにその情報を記録します。ホストがad.example.com
という名前の AD ドメインと直接統合されている場合は、sssd_ad.example.com.log
という名前のファイルのログに情報が記録されます。注記IdM 環境と、AD ドメインを持つフォレスト間の信頼があると、AD ドメインに関する情報は引き続き IdM ドメインのログファイルに記録されます。
同様に、ホストが AD ドメインに直接統合されている場合は、プライマリードメインのログファイルに、子ドメインに関する情報が書き込まれます。
selinux_child.log
- SELinux 情報を取得および設定する短期間ヘルパープロセスのログファイル。
sssd.log
- SSSD を監視して、レスポンダーおよびバックエンドプロセスと通信するためのログファイル。
sssd_ifp.log
- InfoPipe レスポンダーのログファイル。システムバスからアクセス可能なパブリック D-Bus インターフェースを提供します。
sssd_nss.log
- ユーザーおよびグループ情報を取得する Name Services Switch (NSS) レスポンダーのログファイル。
sssd_pac.log
- AD Kerberos チケットから PAC を収集する Microsoft Privilege Attribute Certificate (PAC) レスポンダー用のログファイルは、PAC から PAC に関する情報を取得します。これにより、AD ユーザーを直接要求しないようにします。
sssd_pam.log
- PAM (Pluggable Authentication Module) レスポンダー用のログファイルです。
sssd_ssh.log
- SSH レスポンダープロセスのログファイル。
8.5.2. SSSD ロギングレベル
デバッグレベルを設定すると、それ下のすべてのデバッグレベルが有効になります。たとえば、debug レベルを 6 に設定すると、デバッグレベル 0 から 5 も有効になります。
表8.1 SSSD ロギングレベル
レベル | 説明 |
---|---|
0 | 致命的な障害が発生しました。SSSD サービスが起動しなかったり、終了しないようにするエラー。これは、RHEL 8.3 以前のデフォルトのデバッグログレベルです。 |
1 | 重大なエラーSSSD サービスを終了しないものの、主要な機能は 1 つ以上正しく機能しません。 |
2 | 深刻なエラー。特定の要求または操作が失敗したことを示すエラー。これは、RHEL 8.4 以降のデフォルトのデバッグログレベルです。 |
3 | マイナーな障害が発生しました。レベル 2 で操作の失敗がキャプチャーされたエラー。 |
4 | 設定。 |
5 | 関数 データ。 |
6 | 操作関数のメッセージを追跡します。 |
7 | 内部制御 関数のメッセージトレース。 |
8 | 関数内部 変数の内容。 |
9 | 非常に 低いレベルのトレース 情報。 |
8.6. sssd.conf ファイルで SSSD の詳細なロギングの有効化
デフォルトでは、RHEL 8.4 以降の SSSD サービスは、重大な失敗 (デバッグレベル 2) のみをログに記録しますが、認証問題のトラブルシューティングに必要な詳細レベルではログに記録されません。
SSSD サービスの再起動時に詳細なロギングを有効にするには、/etc/sssd/sssd.conf
設定ファイルの各セクションに debug_level=<integer>
オプションを追加します。ここで、<integer>
の値は 0 から 9 の数字になります。デバッグレベルは最大 3 つのログで、最大 3 つのログで、レベル 8 以上では、多くの詳細なログメッセージを提供します。レベル 6 は、認証の問題のデバッグに役立ちます。
前提条件
-
sssd.conf
設定ファイルを編集し、SSSD サービスを再起動するには、root パスワードが必要です。
手順
-
テキストエディターで
/etc/sssd/sssd.conf
ファイルを開きます。 debug_level
オプションをファイルのすべてのセクションに追加し、デバッグレベルを、選択した詳細に設定します。[domain/example.com] debug_level = 6 id_provider = ipa ... [sssd] debug_level = 6 services = nss, pam, ifp, ssh, sudo domains = example.com [nss] debug_level = 6 [pam] debug_level = 6 [sudo] debug_level = 6 [ssh] debug_level = 6 [pac] debug_level = 6 [ifp] debug_level = 6
-
sssd.conf
ファイルを保存して閉じます。 SSSD サービスを再起動して、新しい設定を読み込みます。
[root@server ~]# systemctl restart sssd
関連情報
8.7. sssctl コマンドを使用した SSSD の詳細なロギングの有効化
デフォルトでは、RHEL 8.4 以降の SSSD サービスは、重大な失敗 (デバッグレベル 2) のみをログに記録しますが、認証問題のトラブルシューティングに必要な詳細レベルではログに記録されません。
sssctl debug-level <integer>
コマンドを使用して、コマンドラインで SSSD サービスのデバッグレベルを変更できます。ここで、<integer>
の値は 0 から 9 の数字になります。デバッグレベルは最大 3 つのログで、最大 3 つのログで、レベル 8 以上では、多くの詳細なログメッセージを提供します。レベル 6 は、認証の問題のデバッグに役立ちます。
前提条件
-
sssctl
コマンドを実行するには、root パスワードが必要です。
手順
sssctl debug-level コマンドを使用して、希望の詳細度に対して選択したデバッグレベルを設定します。
[root@server ~]# sssctl debug-level 6
関連情報
8.8. SSSD サービスからデバッグログを収集し、IdM サーバーによる認証問題のトラブルシューティング
IdM ユーザーが IdM サーバーへの認証を試行する際に問題が発生した場合は、サーバー上の SSSD サービスで詳細なデバッグロギングを有効にし、ユーザーに関する情報の取得を試行するログを収集します。
前提条件
-
sssctl
コマンドを実行して SSSD サービスを再起動するには、root パスワードが必要です。
手順
IdM サーバーで詳細な SSSD デバッグロギングを有効にします。
[root@server ~]# sssctl debug-level 6
認証問題が発生しているユーザーの SSSD キャッシュでオブジェクトを無効にするため、LDAP サーバーを省略し、SSSD がすでにキャッシュされている情報を取得しません。
[root@server ~]# sssctl cache-expire -u idmuser
古い SSSD ログを削除して、トラブルシューティングのデータセットを最小限に抑える。
[root@server ~]# sssctl logs-remove
認証問題が発生し、試行前後にタイムスタンプを収集する際に、ユーザーが認証問題が発生しようと試みます。これらのタイムスタンプは、データセットのスコープをさらに絞り込むことができます。
[root@server sssd]# date; su idmuser; date Mon Mar 29 15:33:48 EDT 2021 su: user idmuser does not exist Mon Mar 29 15:33:49 EDT 2021
(オプション) 詳細な SSSD ログの収集を続行しない場合は、デバッグレベルを下げます。
[root@server ~]# sssctl debug-level 2
障害のある要求に関する情報を SSSD ログで確認します。たとえば、
/var/log/sssd/sssd_example.com.log
ファイルを確認すると、SSSD サービスがcn=accounts,dc=example,dc=com
LDAP サブツリーでユーザーを見つけられなかったことを示しています。これは、ユーザーが存在しないか、または別の場所に存在することを示しています。(Mon Mar 29 15:33:48 2021) [sssd[be[example.com]]] [dp_get_account_info_send] (0x0200): Got request for [0x1][BE_REQ_USER][name=idmuser@example.com] ... (Mon Mar 29 15:33:48 2021) [sssd[be[example.com]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(&(uid=idmuser)(objectclass=posixAccount)(uid=)(&(uidNumber=)(!(uidNumber=0))))][cn=accounts,dc=example,dc=com]. (Mon Mar 29 15:33:48 2021) [sssd[be[example.com]]] [sdap_get_generic_op_finished] (0x0400): Search result: Success(0), no errmsg set (Mon Mar 29 15:33:48 2021) [sssd[be[example.com]]] [sdap_search_user_process] (0x0400): Search for users, returned 0 results. (Mon Mar 29 15:33:48 2021) [sssd[be[example.com]]] [sysdb_search_by_name] (0x0400): No such entry (Mon Mar 29 15:33:48 2021) [sssd[be[example.com]]] [sysdb_delete_user] (0x0400): Error: 2 (No such file or directory) (Mon Mar 29 15:33:48 2021) [sssd[be[example.com]]] [sysdb_search_by_name] (0x0400): No such entry (Mon Mar 29 15:33:49 2021) [sssd[be[example.com]]] [ipa_id_get_account_info_orig_done] (0x0080): Object not found, ending request
認証問題の原因を判断できない場合は、以下を行います。
最近生成した SSSD ログを収集します。
[root@server ~]# sssctl logs-fetch sssd-logs-Mar29.tar
Red Hat テクニカルサポートケースを作成し、以下を提供します。
-
SSSD ログ:
sssd-logs-Mar29.tar
ログに対応する要求のタイムスタンプおよびユーザー名を含むコンソールの出力。
[root@server sssd]# date; id idmuser; date Mon Mar 29 15:33:48 EDT 2021 id: ‘idmuser’: no such user Mon Mar 29 15:33:49 EDT 2021
-
SSSD ログ:
8.9. SSSD サービスからデバッグログを収集し、IdM クライアントによる認証問題のトラブルシューティング
IdM クライアントに IdM ユーザーとして認証を試行する際に問題が発生した場合は、IdM サーバーでユーザー情報を取得できることを確認します。IdM サーバーでユーザー情報を取得できない場合は、(IdM サーバーから情報を取得する) IdM クライアントでそれを取得できなくなります。
認証の問題が IdM サーバーから生成されていないことを確認したら、IdM サーバーと IdM クライアントの両方から SSSD デバッグログを収集していました。
前提条件
- IdM サーバーではなく、IdM クライアントで認証の問題のみがあります。
-
sssctl
コマンドを実行して SSSD サービスを再起動するには、root パスワードが必要です。
手順
-
クライアントで、テキストエディターで
/etc/sssd/sssd.conf
ファイルを開きます。 クライアントで、
ipa_server
オプションをファイルの[domain]
セクションに追加し、IdM サーバーに設定します。これにより、IdM クライアントは他の IdM サーバーの自動検出を避け、このテストを 1 つのクライアントおよびサーバー 1 台だけに制限します。[domain/example.com] ipa_server = server.example.com ...
-
クライアントで
sssd.conf
ファイルを保存して閉じます。 クライアントで SSSD サービスを再起動して、設定の変更を読み込みます。
[root@client ~]# systemctl restart sssd
サーバーおよびクライアントで、詳細な SSSD デバッグロギングを有効にします。
[root@server ~]# sssctl debug-level 6
[root@client ~]# sssctl debug-level 6
サーバーおよびクライアントで、認証問題が発生しているユーザーの SSSD キャッシュの検証オブジェクトでは、LDAP データベースを迂回せず、SSSD がすでにキャッシュされています。
[root@server ~]# sssctl cache-expire -u idmuser
[root@client ~]# sssctl cache-expire -u idmuser
サーバーおよびクライアントで、古い SSSD ログを削除して、トラブルシューティングのデータセットを最小限に抑える。
[root@server ~]# sssctl logs-remove
[root@server ~]# sssctl logs-remove
クライアントで、認証問題が発生し、試行前後にタイムスタンプを収集する際に、ユーザーが認証問題が発生しようと試みます。これらのタイムスタンプは、データセットのスコープをさらに絞り込むことができます。
[root@client sssd]# date; su idmuser; date Mon Mar 29 16:20:13 EDT 2021 su: user idmuser does not exist Mon Mar 29 16:20:14 EDT 2021
(オプション) サーバーおよびクライアント 詳細な SSSD ログの収集したくない場合はデバッグレベルを下げます。
[root@server ~]# sssctl debug-level 0
[root@client ~]# sssctl debug-level 0
サーバーおよびクライアントで、失敗した要求に関する情報を SSSD ログを確認します。
- クライアントログのクライアントからの要求を確認します。
- サーバーログのクライアントからの要求を確認します。
- サーバーログでリクエストの結果を確認します。
- サーバーからリクエストの結果を受信するクライアントの結果を確認します。
認証問題の原因を判断できない場合は、以下を行います。
IdM サーバーおよび IdM クライアントで最近生成した SSSD ログを収集します。ホスト名またはロールに応じてラベルを付けます。
[root@server ~]# sssctl logs-fetch sssd-logs-server-Mar29.tar
[root@client ~]# sssctl logs-fetch sssd-logs-client-Mar29.tar
Red Hat テクニカルサポートケースを作成し、以下を提供します。
SSSD デバッグログ:
-
サーバーから
sssd-logs-server-Mar29.tar
-
クライアントからの
sssd-logs-client-Mar29.tar
-
サーバーから
ログに対応する要求のタイムスタンプおよびユーザー名を含むコンソールの出力。
[root@client sssd]# date; su idmuser; date Mon Mar 29 16:20:13 EDT 2021 su: user idmuser does not exist Mon Mar 29 16:20:14 EDT 2021
8.10. SSSD バックエンドでのクライアント要求の追跡
SSSD は要求を非同期に処理します。別の要求のメッセージが同じログファイルに追加されるため、一意の要求識別子とクライアント ID を使用して、バックエンドログ内のクライアント要求を追跡できます。一意のリクエスト識別子は、RID#<integer>
の形式でデバッグログに追加され、クライアント ID はフォーム[CID #<integer]
に追加されます。これにより、個々の要求に関連するログを分離でき、複数のSSSDコンポーネントからのログファイル全体でリクエストを最初から最後まで追跡できます。
前提条件
- デバッグロギングを有効にし、IdM クライアントから要求が送信されている。
- SSSD ログファイルの内容を表示するための root 権限を持っている。
手順
SSSD ログファイルを確認するには、
less
ユーティリティーを使用してログファイルを開きます。たとえば、/var/log/sssd/sssd_example.com.log
を表示するには、次のコマンドを実行します。[root@server ~]# less /var/log/sssd/sssd_example.com.log
クライアント要求に関する情報は、SSSD ログを確認します。
(2021-07-26 18:26:37): [be[testidm.com]] [dp_req_destructor] (0x0400): [RID#3] Number of active DP request: 0 (2021-07-26 18:26:37): [be[testidm.com]] [dp_req_reply_std] (0x1000): [RID#3] DP Request AccountDomain #3: Returning [Internal Error]: 3,1432158301,GetAccountDomain() not supported (2021-07-26 18:26:37): [be[testidm.com]] [dp_attach_req] (0x0400): [RID#4] DP Request Account #4: REQ_TRACE: New request. [sssd.nss CID #1] Flags [0x0001]. (2021-07-26 18:26:37): [be[testidm.com]] [dp_attach_req] (0x0400): [RID#4] Number of active DP request: 1
SSSD ログファイルからのこの出力例は、2 つの異なる要求について一意の識別子の
RID#3
およびRID#4
を示しています。
ただし、SSSD クライアントインターフェースへの 1 つのクライアント要求が、バックエンドで複数の要求をトリガーすることが多いため、クライアント要求とバックエンドの要求との間に 1 対 1 の相関関係がなくなります。バックエンド内の複数のリクエストには異なる RID 番号がありますが、最初の各バックエンドリクエストには一意のクライアント ID が含まれているため、管理者は単一のクライアントリクエストに対して複数の RID 番号を追跡できます。
以下の例は、1 つのクライアントリクエスト[sssd.nss CID #1]
と、バックエンドで生成された複数のリクエスト ([RID#5]
から [RID#13]
) を示しています。
(2021-10-29 13:24:16): [be[ad.vm]] [dp_attach_req] (0x0400): [RID#5] DP Request [Account #5]: REQ_TRACE: New request. [sssd.nss CID #1] Flags [0x0001]. (2021-10-29 13:24:16): [be[ad.vm]] [dp_attach_req] (0x0400): [RID#6] DP Request [AccountDomain #6]: REQ_TRACE: New request. [sssd.nss CID #1] Flags [0x0001]. (2021-10-29 13:24:16): [be[ad.vm]] [dp_attach_req] (0x0400): [RID#7] DP Request [Account #7]: REQ_TRACE: New request. [sssd.nss CID #1] Flags [0x0001]. (2021-10-29 13:24:17): [be[ad.vm]] [dp_attach_req] (0x0400): [RID#8] DP Request [Initgroups #8]: REQ_TRACE: New request. [sssd.nss CID #1] Flags [0x0001]. (2021-10-29 13:24:17): [be[ad.vm]] [dp_attach_req] (0x0400): [RID#9] DP Request [Account #9]: REQ_TRACE: New request. [sssd.nss CID #1] Flags [0x0001]. (2021-10-29 13:24:17): [be[ad.vm]] [dp_attach_req] (0x0400): [RID#10] DP Request [Account #10]: REQ_TRACE: New request. [sssd.nss CID #1] Flags [0x0001]. (2021-10-29 13:24:17): [be[ad.vm]] [dp_attach_req] (0x0400): [RID#11] DP Request [Account #11]: REQ_TRACE: New request. [sssd.nss CID #1] Flags [0x0001]. (2021-10-29 13:24:17): [be[ad.vm]] [dp_attach_req] (0x0400): [RID#12] DP Request [Account #12]: REQ_TRACE: New request. [sssd.nss CID #1] Flags [0x0001]. (2021-10-29 13:24:17): [be[ad.vm]] [dp_attach_req] (0x0400): [RID#13] DP Request [Account #13]: REQ_TRACE: New request. [sssd.nss CID #1] Flags [0x0001].
第9章 Ansible Playbook でグローバル IdM 設定の構成
Ansible 設定
モジュールを使用すると、Identity Management (IdM) のグローバル設定パラメーターを取得および設定できます。
本章では、以下のセクションを説明します。
9.1. Ansible Playbook で IdM 設定の取得
以下の手順では、Ansible Playbook を使用して、現在のグローバル IdM 設定に関する情報を取得する方法を説明します。
前提条件
- IdM 管理者パスワードを把握している。
- Ansible コントローラーに ansible-freeipa パッケージがインストールされている。
手順
inventory.file
などのインベントリーファイルを作成して、IdM 設定を取得する IdM サーバーを[ipaserver]
セクションに定義します。たとえば、Ansible に対して server.idm.example.com からデータを取得するよう指示するには、次のコマンドを実行します。[ipaserver] server.idm.example.com
Ansible Playbook ファイル
/usr/share/doc/ansible-freeipa/playbooks/config/retrieve-config.yml
を開いて編集します。--- - name: Playbook to handle global IdM configuration hosts: ipaserver become: no gather_facts: no tasks: - name: Query IPA global configuration ipaconfig: ipaadmin_password: Secret123 register: serverconfig - debug: msg: "{{ serverconfig }}"
以下を変更してファイルを調整します。
- IdM 管理者のパスワード
- その他の値 (必要な場合)。
- ファイルを保存します。
Playbook ファイルとインベントリーファイルを指定して Ansible Playbook を実行します。
$ ansible-playbook -v -i path_to_inventory_directory/inventory.file /usr/share/doc/ansible-freeipa/playbooks/config/retrieve-config.yml [...] TASK [debug] ok: [server.idm.example.com] => { "msg": { "ansible_facts": { "discovered_interpreter_ }, "changed": false, "config": { "ca_renewal_master_server": "server.idm.example.com", "configstring": [ "AllowNThash", "KDC:Disable Last Success" ], "defaultgroup": "ipausers", "defaultshell": "/bin/bash", "emaildomain": "idm.example.com", "enable_migration": false, "groupsearch": [ "cn", "description" ], "homedirectory": "/home", "maxhostname": "64", "maxusername": "64", "pac_type": [ "MS-PAC", "nfs:NONE" ], "pwdexpnotify": "4", "searchrecordslimit": "100", "searchtimelimit": "2", "selinuxusermapdefault": "unconfined_u:s0-s0:c0.c1023", "selinuxusermaporder": [ "guest_u:s0$xguest_u:s0$user_ ], "usersearch": [ "uid", "givenname", "sn", "telephonenumber", "ou", "title" ] }, "failed": false } }
9.2. Ansible Playbook での IdM CA 更新サーバーの設定
組み込みの認証局 (CA) を使用する Identity Management (IdM) デプロイメントでは、CA 更新サーバーが IdM システム証明書を維持および更新します。IdM デプロイメントを確実に堅牢化します。
IdM CA 更新サーバーロールの詳細は、「IdM CA 更新サーバーの使用」を参照してください。
以下の手順では、Ansible Playbook を使用して IdM CA 更新サーバーを設定する方法を説明します。
前提条件
- IdM 管理者パスワードを把握している。
- Ansible コントローラーに ansible-freeipa パッケージがインストールされている。
手順
必要に応じて、現在の IdM CA 更新サーバーを特定します。
$ ipa config-show | grep 'CA renewal' IPA CA renewal master: server.idm.example.com
inventory.file
などのインベントリーファイルを作成し、そのファイルにipaserver
を定義します。[ipaserver] server.idm.example.com
Ansible Playbook ファイル
/usr/share/doc/ansible-freeipa/playbooks/config/set-ca-renewal-master-server.yml
を開いて編集します。--- - name: Playbook to handle global DNS configuration hosts: ipaserver become: no gather_facts: no tasks: - name: set ca_renewal_master_server ipaconfig: ipaadmin_password: SomeADMINpassword ca_renewal_master_server: carenewal.idm.example.com
以下を変更してファイルを調整します。
-
ipaadmin_password
変数で設定した IdM 管理者のパスワード -
ca_renewal_master_server
変数で設定した CA 更新サーバーの名前。
-
- ファイルを保存します。
Ansible Playbook を実行します。Playbook ファイルとインベントリーファイルを指定します。
$ ansible-playbook -v -i path_to_inventory_directory/inventory.file /usr/share/doc/ansible-freeipa/playbooks/config/set-ca-renewal-master-server.yml
検証手順
CA 更新サーバーが変更されたことを確認します。
IdM 管理者として
ipaserver
にログインします。$ ssh admin@server.idm.example.com Password: [admin@server /]$
IdM CA 更新サーバーの ID を要求します。
$ ipa config-show | grep ‘CA renewal’ IPA CA renewal master: carenewal.idm.example.com
この出力には、carenewal.idm.example.com サーバーが新しい CA 更新サーバーであることが分かります。
9.3. Ansible Playbook での IdM ユーザーのデフォルトシェルの設定
シェルは、コマンドを受け入れ、解釈するプログラムです。bash
、sh
、ksh
、zsh
、fish
などの Red Hat Enterprise Linux (RHEL) では、いくつかのシェルが利用できます。Bash
(または /bin/bash
) は、ほとんどの Linux システムで一般的なシェルです。通常は、RHEL のユーザーアカウントのデフォルトシェルです。
以下の手順では、Ansible Playbook を使用して、IdM ユーザーのデフォルトシェルとして別のシェルである sh
を設定する方法を説明します。
前提条件
- IdM 管理者パスワードを把握している。
- Ansible コントローラーに ansible-freeipa パッケージがインストールされている。
手順
-
必要に応じて、Ansible Playbook
retrieve-config.yml
を使用して、IdM ユーザーの現在のシェルを特定します。詳細は、「Ansible Playbook で IdM 設定の取得」を参照してください。 inventory.file
などのインベントリーファイルを作成して、そのファイルにipaserver
を定義します。[ipaserver] server.idm.example.com
Ansible Playbook
/usr/share/doc/ansible-freeipa/playbooks/config/ensure-config-options-are-set.yml
ファイルを開いて編集します。--- - name: Playbook to ensure some config options are set hosts: ipaserver become: true tasks: # Set defaultlogin and maxusername - ipaconfig: ipaadmin_password: Secret123 defaultshell: /bin/bash maxusername: 64
以下を変更してファイルを調整します。
-
ipaadmin_password
変数で設定した IdM 管理者のパスワード -
defaultshell
変数で設定されている IdM ユーザーのデフォルトのシェルが/bin/sh
に設定されます。
-
- ファイルを保存します。
Ansible Playbook を実行します。Playbook ファイルとインベントリーファイルを指定します。
$ ansible-playbook -v -i path_to_inventory_directory/inventory.file /usr/share/doc/ansible-freeipa/playbooks/config/ensure-config-options-are-set.yml
検証手順
IdM で新しいセッションを開始すると、デフォルトのユーザーシェルが変更されていることを確認できます。
IdM 管理者として
ipaserver
にログインします。$ ssh admin@server.idm.example.com Password: [admin@server /]$
現在のシェルを表示します。
[admin@server /]$ echo "$SHELL" /bin/sh
ログインしているユーザーが
sh
シェルを使用している。
9.4. 関連情報
-
/usr/share/doc/ansible-freeipa/
ディレクトリーのREADME-config.md
を参照してください。 -
/usr/share/doc/ansible-freeipa/playbooks/config
ディレクトリーのサンプルの Playbook を参照してください。
第10章 コマンドラインでユーザーアカウントの管理
本章では、IdM (Identity Management) のユーザーライフサイクルに関する基本的な説明を紹介します。以下のセクションでは、次の方法を紹介します。
- ユーザーアカウントを作成する
- ステージユーザーアカウントをアクティベートする
- ユーザーアカウントを保存する
- アクティブユーザー、ステージユーザー、または保存済みユーザーのアカウントを削除する
- 保存済みユーザーアカウントの復元
10.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 グループのメンバーシップは、ローカルユーザーでは機能しません。
10.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
このコマンドは、すべてのユーザーアカウントと、その詳細を一覧で表示します。
10.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
このコマンドは、すべてのユーザーアカウントと、その詳細を一覧で表示します。
10.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" --------------------
注記ユーザーアカウントが削除されたという出力が表示されたにもかかわらず、アカウントは保持されています。
10.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 から永続的に削除されました。
10.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
このコマンドは、すべてのユーザーアカウントと、その詳細を一覧で表示します。
第11章 IdM Web UI でユーザーアカウントの管理
Identity Management (IdM) は、さまざまなユーザーのワークライフ状況を管理するのに役立つ 複数のステージ を提供します。
- ユーザーアカウントの作成
従業員が新しい会社で働き始める前に ステージユーザーアカウントを作成 し、従業員の初出勤日に合わせてアカウントをアクティベートできるように準備します。
この手順を省略し、アクティブなユーザーアカウントを直接作成できるようにします。この手順は、ステージユーザーアカウントの作成に類似しています。
- ユーザーアカウントをアクティベートする
- 従業員の最初の就業日に アカウントをアクティベート します。
- ユーザーアカウントを無効にする
- ユーザーが数か月間育児休暇を取得する場合は、一時的にアカウントを無効にする 必要があります。
- ユーザーアカウントを有効にする
- ユーザーが戻ってきたら、アカウントを再度有効にする 必要があります。
- ユーザーアカウントを保存する
- ユーザーが会社を辞める場合は、しばらくしてから会社に戻ってくる可能性を考慮して、アカウントを復元することができる状態で削除する 必要があります。
- ユーザーアカウントを復元する
- 2 年後にユーザーが復職する場合は、保存済みアカウントを復元 する必要があります。
- ユーザーアカウントを削除する
- その社員を解雇した場合 (戻ってくる可能性がない場合) は、バックアップを行わずに アカウントを削除 します。
11.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 グループのメンバーシップは、ローカルユーザーでは機能しません。
11.2. Web UI でユーザーの追加
通常は、新入社員が働き始める前に、新しいユーザーアカウントを作成する必要があります。このようなステージアカウントにはアクセスできず、後でアクティベートする必要があります。
または、直接、アクティブなユーザーアカウントを作成できます。アクティブユーザーを追加する場合は、以下の手順に従って、アクティブユーザー タブでユーザーアカウントを追加します。
前提条件
- IdM、またはユーザー管理者ロールを管理する管理者権限
手順
IdM Web UI にログインします。
詳細は「Web ブラウザーで IdM Web UI へのアクセス」を参照してください。
ユーザー → ステージユーザー タブに移動します。
または、ユーザー → アクティブユーザー にユーザーアカウントを追加できますが、アカウントにユーザーグループを追加することはできません。
- + 追加 アイコンをクリックします。
- ステージユーザーの追加 ダイアログボックスで、新規ユーザーの 名前 と 名字 を入力します。
(必要に応じて) ユーザーログイン フィールドにログイン名を追加します。
空のままにすると、IdM サーバーは、名字の前に、名前の最初の 1 文字が追加された形式で、ログイン名を作成します。ログイン名には、32 文字まで使用できます。
- (必要に応じて) GID ドロップダウンメニューで、ユーザーに含まれるグループを選択します。
- [オプション] パスワード および パスワードの確認 フィールドに、パスワードを入力して確定し、両方が一致していることを確認します。
追加 ボタンをクリックします。
この時点では、ステージユーザー テーブルでユーザーアカウントを確認できます。
ユーザー名をクリックすると、電話番号、住所、職業の追加などの詳細設定を編集できます。
11.3. IdM Web UI でステージユーザーのアクティベート
ユーザーが IdM にログインし、ユーザーを IdM グループに追加する前に、ステージユーザーアカウントをアクティベートする必要があります。本セクションでは、ステージユーザーアカウントをアクティベートする方法を説明します。
前提条件
- IdM Web UI、またはユーザー管理者ロールを管理する管理者権限
- IdM に、1 つ以上のステージユーザーアカウント
手順
IdM Web UI にログインします。
詳細は「Web ブラウザーで IdM Web UI へのアクセス」を参照してください。
- ユーザー → ステージユーザー タブに移動します。
- 有効にするユーザーアカウントのチェックボックスをクリックします。
アクティベート ボタンをクリックします。
- 確認 ダイアログボックスで、OK ボタンをクリックします。
アクティベーションに成功したら、IdM Web UI により、ユーザーがアクティベートされ、ユーザーアカウントが アクティブユーザー に移動したことを示す緑色の確認が表示されます。このアカウントはアクティブで、ユーザーは IdM ドメインと IdM Web UI に対して認証できます。ユーザーは、初回ログイン時にパスワードを変更するように求められます。
このステージで、アクティブなユーザーアカウントをユーザーグループに追加できます。
11.4. Web UI でのユーザーアカウントの無効化
アクティブなユーザーアカウントを無効にできます。ユーザーアカウントを無効にすると、ユーザーアカウントはアカウントを非アクティブにできるため、そのユーザーアカウントを使用して Kerberos などの IdM サービスを認証および使用したり、タスクを実行することができません。
無効にしたユーザーアカウントはそのまま IdM に残り、関連する情報は何も変更しません。保存済みユーザーアカウントとは異なり、無効にしたユーザーアカウントはアクティブな状態のままとなり、ユーザーグループのメンバーになります。
ユーザーアカウントを無効にした後、既存の接続はユーザーの Kerberos TGT や他のチケットの有効期限が切れるまで有効です。チケットの期限が切れると、ユーザーが更新できなくなります。
前提条件
- IdM Web UI、またはユーザー管理者ロールを管理する管理者権限
手順
IdM Web UI にログインします。
詳細は「Web ブラウザーで IdM Web UI へのアクセス」を参照してください。
- ユーザー → アクティブユーザー タブに移動します。
- 無効にするユーザーアカウントのチェックボックスをクリックします。
無効 ボタンをクリックします。
- 確認 ダイアログボックスで、OK ボタンをクリックします。
無効化の手順に成功した場合は、アクティブユーザー テーブルの状態の列で確認できます。
11.5. Web UI でユーザーアカウントの有効化
IdM を使用して、無効にしたアクティブなユーザーアカウントを再度有効にできます。ユーザーアカウントを有効にすると、無効になったアカウントが有効になります。
前提条件
- IdM Web UI、またはユーザー管理者ロールを管理する管理者権限
手順
- IdM Web UI にログインします。
- ユーザー → アクティブユーザー タブに移動します。
- 有効にするユーザーアカウントのチェックボックスをクリックします。
有効 ボタンをクリックします。
- 確認 ダイアログボックスで、OK ボタンをクリックします。
変更に成功すると、アクティブユーザー テーブルの状態の列で確認できます。
11.6. IdM Web UI でアクティブなユーザーの保存
ユーザーアカウントを保存すると、アクティブユーザー タブからアカウントを削除した状態で、IdM でアカウントを維持できます。
従業員が退職する場合は、ユーザーアカウントを保存します。ユーザーアカウントを数週間または数か月間 (たとえば育児休暇) 無効にする場合は、ユーザーアカウントを無効にします。詳細は、Web UI でのユーザーアカウントの無効化 を参照してください。保存済みアカウントはアクティブではないため、そのユーザーが内部ネットワークにはアクセスできないものの、すべてのデータが含まれる状態でデータベース内に残ります。
復元したアカウントをアクティブモードに戻すことができます。
保存済みユーザーの一覧は、以前のユーザーアカウントの履歴を提供します。
前提条件
- IdM (Identity Management) Web UI、またはユーザー管理者ロールを管理する管理者権限
手順
IdM Web UI にログインします。
詳細は「Web ブラウザーで IdM Web UI へのアクセス」を参照してください。
- ユーザー → アクティブユーザー タブに移動します。
- 保存するユーザーアカウントのチェックボックスをクリックします。
削除 ボタンをクリックします。
- ユーザーの削除 ダイアログボックスで、削除モード ラジオボタンを、保存 に切り替えます。
削除 ボタンをクリックします。
これにより、そのユーザーアカウントは、保存済みユーザー に移動します。
保存済みユーザーを復元する必要がある場合は、「IdM Web UI でユーザーの復元」を参照してください。
11.7. IdM Web UI でユーザーの復元
IdM (Identity Management) を使用すると、保存済みユーザーアカウントをアクティブな状態で復元できます。
前提条件
- IdM Web UI、またはユーザー管理者ロールを管理する管理者権限
手順
IdM Web UI にログインします。
詳細は「Web ブラウザーで IdM Web UI へのアクセス」を参照してください。
- ユーザー → 保存済みユーザー タブに移動します。
- 復元するユーザーアカウントのチェックボックスをクリックします。
復元 ボタンをクリックします。
- 確認 ダイアログボックスで、OK ボタンをクリックします。
IdM Web UI は、緑色の確認を表示し、ユーザーアカウントを アクティブユーザー タブに移動します。
11.8. IdM Web UI でユーザーの削除
ユーザーの削除は元に戻せない操作であり、グループメンバーシップやパスワードなど、ユーザーアカウントが IdM データベースから完全に削除されます。ユーザーの外部設定 (システムアカウントやホームディレクトリーなど) は削除されませんが、IdM からはアクセスできなくなります。
以下を削除できます。
アクティブなユーザー - IdM Web UI では、以下のオプションを利用できます。
ユーザーを一時的に保存する
詳細は「IdM Web UI でアクティブなユーザーの保存」を参照してください。
- 永続的に削除する
- ステージユーザー - ステージユーザーを永続的に削除できます。
- 保存済みユーザー - 保存済みユーザーを永続的に削除できます。
以下の手順では、アクティブなユーザーの削除を説明します。以下のタブでも同じようにユーザーアカウントを削除できます。
- ステージユーザー タブ
- 保存済みユーザー タブ
前提条件
- IdM Web UI、またはユーザー管理者ロールを管理する管理者権限
手順
IdM Web UI にログインします。
詳細は「Web ブラウザーで IdM Web UI へのアクセス」を参照してください。
ユーザー → アクティブユーザー タブに移動します。
ユーザー → ステージユーザー または ユーザー → 保存済みユーザー でも、ユーザーアカウントを削除できます。
- 削除 アイコンをクリックします。
- ユーザーの削除 ダイアログボックスで、モードの削除 ラジオボタンを、削除 に切り替えます。
- 削除 ボタンをクリックします。
ユーザーアカウントが、IdM から完全に削除されました。
第12章 Ansible Playbook を使用したユーザーアカウントの管理
Ansible Playbook を使用して IdM のユーザーを管理できます。ユーザーのライフサイクル を示した後、本章では以下の操作に Ansible Playbook を使用する方法を説明します。
-
YML
ファイルに直接リストされている 単一ユーザーが存在することを確認 します。 -
YML
ファイルに直接リストされている 複数のユーザーが存在することを確認 します。 -
YML
ファイルから参照されるJSON
ファイルに一覧表示される 複数のユーザーが存在することを確認 します。 -
YML
ファイルに直接一覧表示されている ユーザーがないことを確認 します。
12.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 グループのメンバーシップは、ローカルユーザーでは機能しません。
12.2. Ansible Playbook を使用した IdM ユーザーの存在の確認
以下の手順では、Ansible Playbook を使用して IdM にユーザーが存在することを確認する方法を説明します。
前提条件
- IdM 管理者パスワードを把握している。
- ansible-freeipa パッケージが Ansible コントローラーにインストールされている。
手順
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 に存在する。
12.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 に存在する。
12.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 に存在する。
12.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 に存在しません。
12.6. 関連情報
-
/usr/share/doc/ansible-freeipa/
ディレクトリーのREADME-user.md
Markdown ファイルを参照してください。 -
/usr/share/doc/ansible-freeipa/playbooks/user
ディレクトリーのサンプルの Ansible Playbook を参照してください。
第13章 IdM CLI でのユーザーグループの管理
本章では、IdM CLI を使用したユーザーグループ管理について説明します。
ユーザーグループは、共通の特権、パスワードポリシーなどの持つユーザーのセットです。
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. 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 グループのメンバーシップは、ローカルユーザーでは機能しません。
13.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 のさまざまなグループタイプ を参照してください。
-
13.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" --------------------------
13.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) が最初にキャッシュを調べて、サーバーで不足または期限切れのレコードのみを検索するためです。
13.7. ユーザープライベートグループなしでユーザーの追加
デフォルトでは、IdM で新しいユーザーが作成されるたびに、IdM がユーザーのプライベートグループ (UPG) を作成します。UPG は特定のグループタイプです。
- UPG の名前は、新しく作成されたユーザーと同じです。
- ユーザーは UPG の唯一のメンバーです。UPG には他のメンバーを含めることができません。
- プライベートグループの GID は、ユーザーの UID と一致します。
ただし、UPG を作成せずにユーザーを追加することは可能です。
13.7.1. ユーザープライベートグループのないユーザー
NIS グループまたは別のシステムグループが、ユーザープライベートグループに割り当てられる GID を既に使用している場合は、UPG を作成しないようにする必要があります。
これは、以下の 2 つの方法で実行できます。
- プライベートグループをグローバルに無効にすることなく、UPG なしで新しいユーザーを追加する。「プライベートグループがグローバルに有効になっている場合にユーザープライベートグループのないユーザーを追加」を参照してください。
- すべてのユーザーに対して UPG をグローバルに無効にしてから、新しいユーザーを追加する。「すべてのユーザーに対してユーザープライベートグループをグローバルで無効にする」および「ユーザープライベートグループをグローバルで無効にしている時のユーザーの追加」を参照してください。
どちらの場合も、IdM では、新しいユーザーを追加するときに GID を指定する必要があります。指定しないと、操作は失敗します。これは、IdM には新しいユーザーの GID が必要ですが、デフォルトのユーザーグループ ipausers
は非 POSIX グループであるため、関連付けられた GID がないためです。指定する GID は、既存のグループに対応する必要がありません。
GID を指定しても、新しいグループは作成されません。この属性は IdM に必要であるため、新しいユーザーに GID 属性のみを設定します。
13.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
13.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
13.7.4. ユーザープライベートグループがグローバルで無効になっている場合のユーザーの追加
ユーザープライベートグループ (UPG) がグローバルで無効になっている場合、IdM は GID を新しいユーザーに自動的に割り当てません。ユーザーを正常に追加するには、GID を手動で割り当てるか、automember を使用して割り当てる必要があります。これが必要な理由の詳細については、Users without a user private group を参照してください。
前提条件
- UPG は、すべてのユーザーに対してグローバルに無効にする必要があります。詳細は、「すべてのユーザーに対してユーザープライベートグループをグローバルに無効にする」をご覧ください。
手順
UPG の作成が無効になっているときに新しいユーザーの追加が成功することを確認するには、次のいずれかを選択します。
新しいユーザーを追加するときにカスタムの GID を指定します。GID は、既存のユーザーグループに対応する必要はありません。
たとえば、コマンドラインからユーザーを追加する場合は、
--gid
オプションをipa user-add
コマンドに追加します。- automember ルールを使用して、GID のある既存のグループにユーザーを追加します。
13.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
を参照してください。
13.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 インターフェースには表示されません。
13.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
-
13.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
を参照してください。
第14章 IdM Weg UI でのユーザーグループの管理
本章では、IdM Web UI を使用したユーザーグループ管理を説明します。
ユーザーグループは、共通の特権、パスワードポリシーなどの持つユーザーのセットです。
Identity Management (IdM) のユーザーグループには以下が含まれます。
- IdM ユーザー
- 他の IdM ユーザーグループ
- 外部ユーザー (IdM の外部に存在するユーザー)
14.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 が定義されていません。
表14.1 デフォルトで作成されたユーザーグループ
グループ名 | デフォルトのグループメンバー |
---|---|
| すべての IdM ユーザー |
|
管理権限を持つユーザー (デフォルトの |
| これは、特別な権限がなくなったレガシーグループです |
| Active Directory 信頼を管理する権限を持つユーザー |
ユーザーをユーザーグループに追加すると、ユーザーはグループに関連付けられた権限とポリシーを取得します。たとえば、ユーザーに管理権限を付与するには、ユーザーを admins
グループに追加します。
admins
グループを削除しないでください。admins
は IdM で必要な事前定義グループであるため、この操作により特定のコマンドで問題が生じます。
さらに、IdM で新しいユーザーが作成されるたびに、IdM は、デフォルトで ユーザーのプライベートグループ を作成します。プライベートグループの詳細は、「プライベートグループのないユーザーの追加」を参照してください。
14.2. 直接および間接のグループメンバー
IdM のユーザーグループ属性は、直接メンバーと間接メンバーの両方に適用されます。グループ B がグループ A のメンバーである場合、グループ B のすべてのユーザーはグループ A の間接メンバーと見なされます。
たとえば、以下の図では、以下のようになります。
- ユーザー 1 とユーザー 2 は、グループ A の 直接メンバー です。
- ユーザー 3、ユーザー 4、およびユーザー 5 は、グループ A の 間接メンバー です。
図14.1 直接および間接グループメンバーシップ

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

ユーザーグループ A にパスワードポリシーを設定すると、そのポリシーはユーザーグループ B のすべてのユーザーにも適用されます。
15.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 ファイルを参照してください。
15.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 ページを参照してください。
15.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 ページを参照してください。
第16章 IdM CLI を使用したグループメンバーシップの自動化
自動グループメンバーシップを使用すると、属性に基づいてユーザーとホストをグループに自動的に割り当てることができます。たとえば、以下を行うことができます。
- 従業員のマネージャー、ロケーション、またはその他の属性に基づいて従業員のユーザーエントリーをグループに分割します。
- クラス、ロケーション、またはその他の属性に基づいてホストを分割します。
- 全ユーザーまたは全ホストを 1 つのグローバルグループに追加します。
本章では、以下のトピックについて説明します。
16.1. 自動グループメンバーシップの利点
ユーザーの自動メンバーシップを使用すると、以下が可能になります。
グループメンバーシップの手動管理によるオーバーヘッドの削減
すべてのユーザーおよびグループを手作業で割り当てる必要がなくなりました。
ユーザーおよびホスト管理における一貫性の向上
ユーザーとホストは、厳密に定義され、自動的に評価される基準に基づいてグループに割り当てられます。
グループベースの設定管理を簡素化
さまざまな設定がグループに定義され、
sudo
ルール、自動マウント、またはアクセス制御などの個別のグループメンバーに適用されます。ユーザーとホストをグループに自動的に追加すると、この設定の管理が容易になります。
16.2. automember ルール
自動グループメンバーシップを設定する場合、管理者は automember ルールを定義します。automember ルールは、特定のユーザーまたはホストターゲットグループに適用されます。これは、一度に複数のグループに適用することはできません。
ルールの作成後、管理者は条件を追加します。これらは、ユーザーまたはホストをターゲットグループに含めるか、除外するかを指定します。
包含条件
ユーザーまたはホストのエントリーが包含条件を満たす場合、ターゲットグループに含まれます。
除外の条件
ユーザーまたはホストのエントリーが除外された状態を満たす場合、ターゲットグループには含まれません。
この条件は、Perl 互換正規表現 (PCRE) 形式の正規表現として指定されます。PCRE の詳細は、man ページの pcresyntax(3)
を参照してください。
IdM は、包含条件の前に除外条件を評価します。競合が発生した場合は、包含条件よりも除外条件が優先されます。
automember ルールは、今後作成されるすべてのエントリーに適用されます。これらのエントリーは指定されたターゲットグループに自動的に追加されます。エントリーが複数の automember ルールで指定された条件を満たすと、対応するグループすべてに追加されます。
既存のエントリーは新規ルールの影響を 受けません。既存のエントリーを変更する場合は、「IdM CLI を使用した既存のエントリーへの automember ルールの適用」を参照してください。
16.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 ルールと条件を表示できます。
16.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 ルールと条件を表示できます。
16.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 ----------------------------
16.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 を入力します。
16.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 ------------------------------
16.8. IdM CLI を使用して automember ルールを既存のエントリーに適用する
Automember ルールは、ルールの追加後に作成されたユーザーおよびホストエントリーに自動的に適用されます。ルールの追加前に存在するエントリーには、一時的な適用は行われません。
以前に追加したエントリーに automember ルールを適用するには、自動メンバーシップを手動で再構築する必要があります。自動メンバーシップを再構築すると、既存の automember ルールがすべて再評価され、すべてのユーザーまたはホストエントリーまたは特定のエントリーに適用されます。
エントリーがグループの包含条件に一致しない場合でも、自動メンバーシップを再構築しても、グループからユーザーまたはホストエントリーは削除 されません。手動で削除するには、「IdM CLI を使用したユーザーグループからのメンバーのを削除」か、「CLI を使用した IdM ホストグループメンバーの削除」を参照してください。
前提条件
- 管理者としてログインしている必要があります。詳細は、Using kinit to log in to IdM manually を参照してください。
手順
自動メンバーシップを再構築するには、
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
を使用します。
16.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
第17章 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 でデフォルトのホストグループの設定
17.1. 自動グループメンバーシップの利点
ユーザーの自動メンバーシップを使用すると、以下が可能になります。
グループメンバーシップの手動管理によるオーバーヘッドの削減
すべてのユーザーおよびグループを手作業で割り当てる必要がなくなりました。
ユーザーおよびホスト管理における一貫性の向上
ユーザーとホストは、厳密に定義され、自動的に評価される基準に基づいてグループに割り当てられます。
グループベースの設定管理を簡素化
さまざまな設定がグループに定義され、
sudo
ルール、自動マウント、またはアクセス制御などの個別のグループメンバーに適用されます。ユーザーとホストをグループに自動的に追加すると、この設定の管理が容易になります。
17.2. automember ルール
自動グループメンバーシップを設定する場合、管理者は automember ルールを定義します。automember ルールは、特定のユーザーまたはホストターゲットグループに適用されます。これは、一度に複数のグループに適用することはできません。
ルールの作成後、管理者は条件を追加します。これらは、ユーザーまたはホストをターゲットグループに含めるか、除外するかを指定します。
包含条件
ユーザーまたはホストのエントリーが包含条件を満たす場合、ターゲットグループに含まれます。
除外の条件
ユーザーまたはホストのエントリーが除外された状態を満たす場合、ターゲットグループには含まれません。
この条件は、Perl 互換正規表現 (PCRE) 形式の正規表現として指定されます。PCRE の詳細は、man ページの pcresyntax(3)
を参照してください。
IdM は、包含条件の前に除外条件を評価します。競合が発生した場合は、包含条件よりも除外条件が優先されます。
automember ルールは、今後作成されるすべてのエントリーに適用されます。これらのエントリーは指定されたターゲットグループに自動的に追加されます。エントリーが複数の automember ルールで指定された条件を満たすと、対応するグループすべてに追加されます。
既存のエントリーは新規ルールの影響を 受けません。既存のエントリーを変更する場合は、「IdM Web UI で automember ルールを既存エントリーに適用」を参照してください。
17.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 ルールへの条件の追加」で説明されている手順に従って、新しいルールに条件を追加できます。
17.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) 属性に値 (.*) が指定されているすべてのユーザーを対象とします。
17.5. IdM Web UI を使用した既存の automember ルールおよび条件の表示
本セクションでは、IdM Web UI を使用して、既存の automember ルールおよび条件を表示する方法を説明します。
前提条件
- IdM Web UI にログインしている。
-
admins
グループのメンバーである。
手順
- Identity → Automember をクリックして、User group rule または Host group rules を選択して、それぞれの automember ルールを表示します。
必要に応じて、ルールをクリックして、Inclusive セクションまたは Exclusive セクションにそのルールの条件を表示します。
17.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 をクリックして確定します。
17.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 をクリックして確定します。
17.8. IdM Web UI で automember ルールを既存エントリーに適用
Automember ルールは、ルールの追加後に作成されたユーザーおよびホストエントリーに自動的に適用されます。ルールの追加前に存在するエントリーには、一時的な適用は行われません。
以前に追加したエントリーに automember ルールを適用するには、自動メンバーシップを手動で再構築する必要があります。自動メンバーシップを再構築すると、既存の automember ルールがすべて再評価され、すべてのユーザーまたはホストエントリーまたは特定のエントリーに適用されます。
エントリーがグループの包含条件に一致しない場合でも、自動メンバーシップを再構築しても、グループからユーザーまたはホストエントリーは削除 されません。手動で削除するには、「IdM Web UI を使用したユーザーグループからメンバーの削除」または「IdM Web UI 使用したホストグループメンバーの削除」を参照してください。
17.8.1. 全ユーザーまたは全ホストに対して自動メンバーシップの再構築
本セクションでは、ユーザーまたはホストのすべてのエントリーに対して自動メンバーシップを再構築する方法を説明します。
前提条件
- IdM Web UI にログインしている。
-
admins
グループのメンバーである。
手順
- Identity → Users または Hosts を選択します。
Actions → Rebuild auto membership をクリックします。
17.8.2. ユーザーまたはホスト 1 つに対する自動メンバーシップの再構築
本セクションでは、特定のユーザーエントリーまたはホストエントリーに対して自動メンバーシップを再構築する方法を説明します。
前提条件
- IdM Web UI にログインしている。
-
admins
グループのメンバーである。
手順
- Identity → Users または Hosts を選択します。
- 必要なユーザー名またはホスト名をクリックします。
Actions → Rebuild auto membership をクリックします。
17.9. IdM Web UI を使用したデフォルトのユーザーグループの設定
デフォルトのユーザーグループを設定する際には、automember ルールに一致しない新規ユーザーエントリーは自動的にこのデフォルトグループに追加されます。
前提条件
- IdM Web UI にログインしている。
-
admins
グループのメンバーである。 - デフォルトとして設定するターゲットユーザーグループが IdM に存在します。
手順
- Identity → Automember をクリックして、User group rules を選択します。
Default user group フィールドで、デフォルトのユーザーグループとして設定するグループを選択します。
17.10. IdM Web UI でデフォルトのホストグループの設定
デフォルトのホストグループを設定する際には、automember ルールに一致しない新規ホストエントリーが自動的にこのデフォルトグループに追加されます。
前提条件
- IdM Web UI にログインしている。
-
admins
グループのメンバーである。 - デフォルトとして設定されるターゲットホストグループが IdM にある。
手順
- Identity → Automember をクリックして、Host group rules を選択します。
Default host group フィールドで、デフォルトのホストグループとして設定するグループを選択します。
第18章 Ansible を使用した IdM のグループメンバーシップの自動化
自動グループメンバーシップを使用すると、ユーザーとホストのユーザーグループとホストグループを、その属性に基づいて自動的に割り当てることができます。たとえば、以下を行うことができます。
-
従業員のユーザーエントリーを、従業員のマネージャー、場所、役職などの属性に基づいてグループに分割します。コマンドラインに
ipa user-add --help
と入力すると、すべての属性を一覧表示できます。 -
ホストを、クラス、場所、またはその他の属性に基づいてグループに分割します。コマンドラインに
ipa host-add --help
と入力すると、すべての属性を一覧表示できます。 - 全ユーザーまたは全ホストを 1 つのグローバルグループに追加します。
Red Hat Ansible Engine を使用すると、Identity Management (IdM) で自動グループメンバーシップの管理を自動化できます。
本セクションでは、以下のトピックについて説明します。
18.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
パスワードを入力する必要があります。
18.2. Ansible を使用した IdM ユーザーグループの automember ルールが存在することの確認
以下の手順では、Ansible Playbook を使用して、Identity Management (IdM) グループの automember
ルールが存在することを確認する方法について説明しますこの例では、testing_group ユーザーグループに対して automember
ルールの存在が保証されます。
前提条件
-
IdM
admin
のパスワードを把握している。 - testing_group ユーザーグループが IdM に存在します。
以下の要件を満たす Ansible コントロールノードを設定している。
- Ansible バージョン 2.8 以降を使用している。
- 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
ディレクトリーを参照してください。
18.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-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
ディレクトリーを参照してください。
18.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-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
ディレクトリーを参照してください。
18.5. Ansible を使用した IdM ユーザーグループの automember ルールがないことの確認
以下の手順では、Ansible Playbook を使用して、Identity Management (IdM) グループにautomember
ルールがないことを確認する方法を説明します。この例では、testing_group グループに automember
ルールがないことが保証されます。
automember ルールを削除すると、ルールに関連付けられたすべての条件も削除されます。ルールから特定の条件のみを削除するには、Ansible を使用した IdM ユーザーグループの automember ルールに条件がないことの確認 を参照してください。
前提条件
-
IdM
admin
のパスワードを把握している。 以下の要件を満たす Ansible コントロールノードを設定している。
- Ansible バージョン 2.8 以降を使用している。
- 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
ディレクトリーを参照してください。
18.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-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
ディレクトリーを参照してください。
18.7. 関連情報
第19章 IdM のアクセス制御
アクセス制御は、ホストやサービスなどの他のユーザーまたはオブジェクトに対して操作を実行するためにユーザーに付与された権限またはアクセス許可を定義します。Identity Management (IdM) では、いくつかのアクセス制御領域を提供して、どのようなアクセスが付与され、誰に付与されているかを明確にします。その一環として、IdM は、ドメイン内のリソースへのアクセス制御と、IdM 設定そのものへのアクセス制御とを区別します。
本章では、IdM ユーザーが、ドメイン内のリソースおよび IdM 設定そのものの両方で利用できるさまざまな内部アクセス制御メカニズムの概要を説明します。
19.1. IdM のアクセス制御命令
Identity Management (IdM) のアクセス制御構造は、389 Directory Server のアクセス制御に基づいています。アクセス制御命令 (ACI) を使用すると、他のエントリー経由で特定の IdM ユーザーのアクセスを許可または拒否できます。IdM ユーザーを含むすべてのエントリーは LDAP に保存されます。
ACI には、以下の 3 つの部分があります
- アクター
- 何かを実行するためのパーミッションが付与されているエンティティーです。LDAP アクセス制御モデルでは、たとえば、ユーザーが識別名 (DN) を使用してディレクトリーにバインドする場合にのみ ACI ルールを適用するように指定できます。このような指定は、バインドルール と呼ばれます。これは、ユーザーが誰であるかを定義し、オプションで、特定の時刻または特定のマシンへの試行の制限など、バインドの試行に他の制限を要求できます。
- Target
- Actor が操作を実行できるエントリー。
- 操作タイプ
- Actor が実行できるアクションのタイプを決定します。最も一般的な操作は、追加、削除、書き込み、読み取り、および検索です。IdM では、管理者以外のユーザーの読み取りおよび検索の権限は制限されており、IdM の CLI よりも IdM の Web UI の方でさらに制限されています。
LDAP 操作を試行すると、以下が発生します。
- IdM クライアントは、バインド操作の一環として、ユーザー認証情報を IdM サーバーに送信します。
- IdM サーバーの DS は、ユーザー認証情報を確認します。
- IdM サーバーの DS は、ユーザーアカウントを確認して、要求された操作を実行するパーミッションをユーザーが持っているかどうかを確認します。
19.2. IdM のアクセス制御方法
Identity Management (IdM) では、アクセス制御方法が以下のカテゴリーに分類されます。
- セルフサービスルール
- ユーザーがユーザー自身の個人エントリーに対して実行できる操作を定義します。このアクセス制御タイプでは、ユーザーエントリー内の特定の属性に対してのみ書き込みパーミッションを許可します。ユーザーは、特定の属性の値を更新できますが、そのような属性を追加または削除することはできません。
- 委譲ルール
- 委譲ルールを使用すると、特定のユーザーグループが、別のユーザーグループ内のユーザーの特定の属性に対して書き込み (編集) 操作を実行できます。セルフサービスルールと同様、この形式のアクセス制御ルールは、特定の属性の値の編集に限られます。エントリー全体を追加または削除したり、指定されていない属性を制御したりする機能は付与されません。
- ロールベースのアクセス制御
特別なアクセス制御グループを作成し、IdM ドメイン内のすべてのタイプのエンティティーに対して、より広範囲な権限を付与します。ロールには編集、追加、および削除の権限が付与されるので、選択された属性だけでなくエントリー全体に対する完全な制御が付与されます。
特定のロール (
Enrollment Administrator
、IT Security Specialist
、およびIT Specialist
など) は、デフォルトで IdM ですでに使用できます。追加のロールを作成して、ホスト、自動マウント設定、netgroup、DNS 設定、IdM 設定などの任意のタイプのエントリーを管理できます。
第20章 CLI を使用した IdM でのセルフサービスルールの管理
本章では、Identity Management (IdM) のセルフサービスルールを紹介し、コマンドラインインターフェース (CLI) でセルフサービスアクセスルールを作成および編集する方法を説明します。
20.1. IdM でのセルフサービスアクセス制御
セルフサービスのアクセス制御ルールは、Identity Management (IdM) エンティティーが IdM Directory Server エントリーで実行できる操作を定義します (例: IdM ユーザーが独自のパスワードを更新できるなど)。
この制御方法では、認証された IdM エンティティーがその LDAP エントリー内の特定の属性を編集できますが、エントリー全体での 追加
や 削除
の操作は許可されません。
セルフサービスのアクセス制御規則を使用する場合は注意が必要です。アクセス制御ルールを誤って構成すると、エンティティーの特権が誤って昇格する可能性があります。
20.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
20.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
20.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
コマンドを使用して、すべてのセルフサービスルールを表示します。削除したばかりのルールがなくなっているはずです。
第21章 IdM Web UI を使用したセルフサービスルールの管理
本章では、Identity Management (IdM) のセルフサービスルールを紹介し、Web インターフェース (IdM Web UI) でセルフサービスアクセスルールを作成および編集する方法を説明します。
21.1. IdM でのセルフサービスアクセス制御
セルフサービスのアクセス制御ルールは、Identity Management (IdM) エンティティーが IdM Directory Server エントリーで実行できる操作を定義します (例: IdM ユーザーが独自のパスワードを更新できるなど)。
この制御方法では、認証された IdM エンティティーがその LDAP エントリー内の特定の属性を編集できますが、エントリー全体での 追加
や 削除
の操作は許可されません。
セルフサービスのアクセス制御規則を使用する場合は注意が必要です。アクセス制御ルールを誤って構成すると、エンティティーの特権が誤って昇格する可能性があります。
21.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 ボタンをクリックしてさらにルールを保存および追加できます。
21.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 ボタンをクリックして、セルフサービスルールへの変更を保存します。
21.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 をクリックして確認します。
第22章 Ansible Playbook を使用した IdM でのセルフサービスルールの管理
本セクションでは、Identity Management (IdM) のセルフサービスルールを紹介し、Ansible Playbook を使用してセルフサービスアクセスルールを作成および編集する方法を説明します。セルフサービスのアクセス制御ルールにより、IdM エンティティーは IdM Directory Server エントリーで指定の操作を実行できます。
本セクションでは、以下のトピックについて説明します。
22.1. IdM でのセルフサービスアクセス制御
セルフサービスのアクセス制御ルールは、Identity Management (IdM) エンティティーが IdM Directory Server エントリーで実行できる操作を定義します (例: IdM ユーザーが独自のパスワードを更新できるなど)。
この制御方法では、認証された IdM エンティティーがその LDAP エントリー内の特定の属性を編集できますが、エントリー全体での 追加
や 削除
の操作は許可されません。
セルフサービスのアクセス制御規則を使用する場合は注意が必要です。アクセス制御ルールを誤って構成すると、エンティティーの特権が誤って昇格する可能性があります。
22.2. Ansible を使用してセルフサービスルールを存在させる手順
以下の手順では、Ansible Playbook を使用してセルフサービスルールを定義し、Identity Management (IdM) サーバーに存在させる方法を説明します。この例では、ユーザーが自分の名前の情報を管理できる 新しいルールでは、ユーザーに、自分の givenname
、displayname
、title
、および initials
属性を変更できるよ権限を付与します。たとえば、表示名や初期などを変更することができます。
前提条件
- IdM 管理者パスワードを把握している。
以下の要件を満たす Ansible コントロールノードを設定している。
- Ansible バージョン 2.8 以降を使用している。
- 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
ディレクトリーを参照してください。
22.3. Ansible を使用してセルフサービスルールがないことを確認する手順
以下の手順では、Ansible Playbook を使用して、指定したセルフサービスルールが IdM 設定に存在しないことを確認する方法を説明します。以下の例では、ユーザーが自分の名前の詳細 のセルフサービスルールが IdM に存在しないことを確認する方法を説明します。これにより、ユーザーは自分の表示名や初期などを変更できないようにします。
前提条件
- IdM 管理者パスワードを把握している。
以下の要件を満たす Ansible コントロールノードを設定している。
- Ansible バージョン 2.8 以降を使用している。
- 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 を参照してください。
22.4. Ansible を使用してセルフサービスルールに固有の属性を含める手順
以下の手順では、Ansible Playbook を使用して、既存のセルフサービスルールに特定の設定を追加する方法を説明します。この例では、ユーザーは自分の名前詳細を管理できる のセルフサービスルールに、surname
のメンバー属性が含まれるようにします。
前提条件
- IdM 管理者パスワードを把握している。
以下の要件を満たす Ansible コントロールノードを設定している。
- Ansible バージョン 2.8 以降を使用している。
- 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 を参照してください。
22.5. Ansible を使用してセルフサービスルールに固有の属性を含めいないようにする手順
以下の手順では、Ansible Playbook を使用して、セルフサービスルールに特定の設定が割り当てられないようにする方法を説明します。この Playbook を使用して、セルフサービスルールで不必要なアクセス権限を付与しないようにします。この例では、ユーザーが独自の名前の詳細を管理できる セルフサービスルールに givenname
と surname
のメンバー属性が含まれないようにします。
前提条件
- IdM 管理者パスワードを把握している。
以下の要件を満たす Ansible コントロールノードを設定している。
- Ansible バージョン 2.8 以降を使用している。
- 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 ファイルとインベ