検索

Identity Management の設定および管理

download PDF
Red Hat Enterprise Linux 8

IdM にログインし、サービス、ユーザー、ホスト、グループ、アクセス制御ルール、および証明書を管理します。

Red Hat Customer Content Services

概要

Red Hat Identity Management (IdM) の主な機能は、ユーザー、グループ、ホスト、アクセス制御ルール、および証明書の管理です。ただし、IdM で管理タスクを実行するには、その前にサービスにログインする必要があります。コマンドラインまたは IdM Web UI を使用してログインする場合は、IdM の認証方法として Kerberos およびワンタイムパスワードを使用できます。
統合または外部の認証局 (CA) を使用して、IdM で証明書を管理できます。Ansible Playbook などの多くのツールを使用して、証明書を要求、更新、および置き換えることができます。IdM サーバーの Web サーバー証明書と LDAP サーバー証明書を置き換えるには、手動アクションを実行する必要があります。

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

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

Identity Management では、次のような用語の置き換えが計画されています。

  • ブラックリスト から ブロックリスト
  • ホワイトリスト から 許可リスト
  • スレーブ から セカンダリー
  • マスター という言葉は、文脈に応じて、より正確な言葉に置き換えられています。

    • IdM マスター から IdM サーバー
    • CA 更新マスター から CA 更新サーバー
    • CRL マスター から CRL パブリッシャーサーバー
    • マルチマスター から マルチサプライヤー

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

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

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

  1. Jira の Web サイトにログインします。
  2. 上部のナビゲーションバーで Create をクリックします。
  3. Summary フィールドにわかりやすいタイトルを入力します。
  4. Description フィールドに、ドキュメントの改善に関するご意見を記入してください。ドキュメントの該当部分へのリンクも追加してください。
  5. ダイアログの下部にある Create をクリックします。

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

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

重要

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

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

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

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

注記

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

手順

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

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

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

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

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

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

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

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

ユーザーのアクティブな Kerberos チケットを含む認証情報キャッシュをクリアするには、次の手順に従います。

手順

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

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

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

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

Identity Management (IdM) ユーザーが Kerberos 認証情報を使用して外部システムから IdM にログインできるように外部システムを設定するには、この手順に従います。

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

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

前提条件

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

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

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

手順

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

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

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

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

    $ export KRB5_CONFIG=/etc/krb5_ipa.conf

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

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

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

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 は、Certificate System サービスにアクセスするコマンドラインインターフェイスです。

必要な証明書をすべて単独で作成して提供する場合は、統合 CA なしでサーバーをインストールすることもできます。

詳細は、CA サービスの計画 を参照してください。

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 との間の同期を管理します。

Identity Management サーバー: サービスの統合

IdM クライアントがホストするサービスのリスト

  • System Security Services Daemon: sssd サービス

SSSD (System Security Services Daemon) は、ユーザー認証およびキャッシュ認証情報を管理するクライアント側のアプリケーションです。キャッシュを使用すると、IdM サーバーが利用できなくなったり、クライアントがオフラインになったりした場合に、ローカルシステムが通常の認証操作を継続できるようになります。

詳細は SSSD とその利点について を参照してください。

  • certmonger: certmonger サービス

certmonger サービスは、クライアント上の証明書を監視、更新します。このサービスは、システム上のサービスに対して新しい証明書を要求できます。

詳細は、certmonger を使用したサービスの IdM 証明書の取得 を参照してください。

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 の IdentityServices タブで表示できます。

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

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

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

IdM ソフトウェアのバージョンを表示するには、次を参照してください。

2.3. Identity Management サーバー全体の起動と停止

ipa systemd サービスを使用して、IdM サーバー全体を、インストールしたすべてのサービスを停止、起動、または再起動します。systemctl ユーティリティーを使用して ipa systemd サービスを制御すると、すべてのサービスが適切な順序で停止、開始、または再起動されます。ipa systemd サービスは、IdM サービスを起動する前に RHEL IdM 設定もアップグレードし、IdM サービスの管理時に適切な SELinux コンテキストを使用します。systemctl ipa コマンドを実行するには、有効な Kerberos チケットは必要ありません。

ipa systemd service コマンド

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

# systemctl start ipa

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

# systemctl stop ipa

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

# systemctl restart ipa

IdM を設定するすべてのサービスのステータスを表示するには、ipactl ユーティリティーを使用します。

# ipactl status
重要
  • IdM サービスは、ipactl ユーティリティーで、起動、停止、または再起動しないでください。代わりに systemctl ipa コマンドを使用して、予測可能な環境で ipactl ユーティリティーを呼び出します。
  • ipactl コマンドは、IdM の Web UI では使用できません。

2.4. 個々の Identity Management サービスの開始および停止

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 ドメインサービスを再起動するには、常に systemctl restart ipa を使用します。IdM サーバーにインストールされているサービス間での依存関係により、サービスを開始および停止する順番は極めて重要です。ipa systemd サービスは、サービスが適切な順序で開始および停止されるようにします。

便利な systemctl コマンド

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

# systemctl start name.service

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

# systemctl stop name.service

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

# systemctl restart name.service

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

# systemctl status name.service
重要

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

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

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

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

 

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

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

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

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

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

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

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

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

Identity Management (IdM) コマンドラインユーティリティーの基本的な使用方法を説明します。

前提条件

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

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

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

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

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

3.2. IPA のヘルプとは

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

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

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

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

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

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

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

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

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

手順

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

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

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

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

    $ ipa help user | less

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

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

3.4. IPA help コマンドの使用

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

手順

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

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

    $ ipa help user-add

関連情報

  • ipa の man ページ

3.5. IPA コマンドの構造

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

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

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

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

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

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

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

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

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

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

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

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

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

3.6. IPA コマンドを使用した IdM へのユーザーアカウントの追加

以下の手順では、コマンドラインを使用して Identity Management (IdM) データベースに新しいユーザーを追加する方法について説明します。

前提条件

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

手順

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

    $ ipa user-add

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

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

    ユーザー名は、IdM データベース全体で一意にする必要があります。そのユーザー名がすでに存在するためにエラーが発生した場合は、ipa user-add コマンドでそのプロセスを再度実行し、別の一意のユーザー名を使用します。

ユーザー名を追加すると、ユーザーアカウントが IdM データベースに追加され、IPA コマンドラインインターフェイス (CLI) は以下の出力を出力します。

----------------------
Added user "euser"
----------------------
User login: euser
First name: Example
Last name: User
Full name: Example User
Display name: Example User
Initials: EU
Home directory: /home/euser
GECOS: Example User
Login shell: /bin/sh
Principal name: euser@IDM.EXAMPLE.COM
Principal alias: euser@IDM.EXAMPLE.COM
Email address: euser@idm.example.com
UID: 427200006
GID: 427200006
Password: False
Member of groups: ipausers
Kerberos keys available: False
注記

デフォルトでは、ユーザーアカウントにユーザーパスワードは設定されていません。ユーザーアカウントの作成中にパスワードを追加するには、次の構文で ipa user-add コマンドを使用します。

$ ipa user-add --first=Example --last=User --password

次に、IPA CLI は、ユーザー名とパスワードを追加または確認するように要求します。

ユーザーがすでに作成されている場合は、ipa user-mod コマンドでパスワードを追加できます。

関連情報

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

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

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

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

前提条件

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

手順

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

    $ ipa user-mod euser --password

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

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

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

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

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

関連情報

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

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 エントリーのリスト表示の概要

ipa *-find コマンドを使用すると、特定のタイプの IdM エントリーを検索できます。

すべての 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 で対応するリストを表示する際に、全体的なサーバーのパフォーマンスを向上できます。

検索サイズ制限

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

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

検索時間の制限

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

デフォルト - 2 秒

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

重要

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

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

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

  • グローバル
  • 特定のエントリーの場合

手順

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

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

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

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

以下の手順では、IdM Web UI でグローバル検索のサイズと時間制限を調整する方法について説明します。

手順

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

    Screenshot of the IdM Web UI highlighting the "IPA Server" tab from the top menu

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

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

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

    Screenshot of the IdM Web UI highlighting the Save button which is below the "Configuration" title at the top of the Configuration page

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

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

5.1. IdM Web UI とは

IdM (Identity Management) Web UI は、IdM 管理用の Web アプリケーションです。IdM Web UI には、以下のユーザーとしてアクセスできます。

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

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 が必要です。

Mozilla Firefox 68 以降でこの問題を解決するには、TLS PHA を有効にします。

  1. アドレスバーに about:config と入力して、Mozilla Firefox 設定メニューにアクセスします。
  2. 検索バーに security.tls.enable_post_handshake_auth と入力します。
  3. トグルボタンをクリックして、パラメーターを true に設定します。

現在 PHA をサポートしていない Chrome でこの問題を解決するには、TLS v1.3 を無効にします。

  1. /etc/httpd/conf.d/ssl.conf 設定ファイルを開きます。
  2. -TLSv1.3SSLProtocol オプションに追加します。

    SSLProtocol all -TLSv1 -TLSv1.1 -TLSv1.3
  3. httpd サービスを再起動します。

    service httpd restart

IdM は ssl.conf ファイルを管理するため、パッケージの更新時にそのコンテンツが上書きされる可能性があることに注意してください。IdM パッケージの更新後に、カスタム設定を確認します。

5.3. Web UI へのアクセス

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

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

手順

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

    https://server.example.com

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

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

    Screenshot of the IdM Web UI accessed within a web browser displaying a "Username" field and a "Password" field. There is a blue "Log in" button below and to the right of those two fields.

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

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

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

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

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

    A Screenshot of the IdM Web UI with the "Username" field filled in with "admin" and the "Password" field displays several black circles obfuscating the password by replacing the characters tat were typed in.

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

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

A screenshot of the first screen visible after logging in to the IdM Web UI. There are 5 tabs listed along the top of the screen: Identity - Policy - Authentication - Network Services - IPA Server. The Identity tab has been selected and it is displaying the Users page which is the first menu item among 6 choices just below the tabs: Users - Hosts - Services - Groups - ID Views - Automember. The Active users page displays a table of user logins and their information: First name - Last name - Status - UID - Email address - Telephone number - Job Title.

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

IdM Web UI への Kerberos ログインと、Kerberos 認証を使用した IdM へのアクセスを有効にするように環境を設定する方法について詳しく説明します。

前提条件

6.1. Identity Management における Kerberos 認証

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

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

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

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

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

注記

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

手順

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

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

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

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

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

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

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

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

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

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

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

  • Firefox
  • Chrome

手順

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

    A screenshot of the IdM Web UI log in page with empty entry fields for the Username and Password and a blue "Log in" button below those fields. Text to the right of the "Log in" button explains "to log in with Kerberos please make sure you have valid tickets (obtainable via kinit) and configured the browser correctly then click Log in." The URL for the word "configured" has been highlighted.

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

    A screenshot of a web browser with instructions for "Browser Kerberos Setup."

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

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

Kerberos Ticket-Granting Ticket (TGT) を使用して 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 認証用のブラウザーの設定 を参照してください。

    ユーザー名とパスワードが空白のフィールドの上にエラーが表示されている IdM Web UI ログイン画面のスクリーンショット。エラーメッセージに、"Authentication with Kerberos failed." と表示されています。

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

Identity Management (IdM) ユーザーが Kerberos 認証情報を使用して外部システムから IdM にログインできるように外部システムを設定するには、この手順に従います。

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

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

前提条件

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

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

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

手順

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

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

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

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

    $ export KRB5_CONFIG=/etc/krb5_ipa.conf

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

  3. /etc/krb5.conf.d/ ディレクトリーの Kerberos 設定部分を、外部システムにコピーします。
  4. Kerberos 認証用のブラウザーの設定 の説明に従って、外部システムでブラウザーを設定します。

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

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

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

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

第7章 ワンタイムパスワードを使用した Identity Management Web UI へのログイン

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

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

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

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

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 でのワンタイムパスワードの有効化

Identity Management (IdM) 管理者は、IdM ユーザーに対して 2 要素認証 (2FA) をシステム全体でまたは個別に有効にすることができます。ユーザーは、コマンドラインまたは Web UI ログインダイアログの専用フィールドで、通常のパスワードの後にワンタイムパスワード (OTP) を入力します。これらのパスワードの間にはスペースを入れません。

2FA を有効にしても、2FA が強制されるわけではありません。LDAP バインドに基づくログインを使用する場合、IdM ユーザーはパスワードを入力するだけで認証できます。ただし、krb5 ベースのログインを使用する場合は、2FA が強制されます。Red Hat は今後のリリースで設定オプションを提供して、管理者が次のいずれかを選択できるようにする予定です。

  • ユーザーが独自のトークンを設定できるようにします。この場合、krb5 ベースのログインでは 2FA が強制されますが、LDAP バインドでは依然として強制されません。
  • ユーザーが独自のトークンを設定できないようにします。この場合、2FA は LDAP バインドと krb5 ベースのログインの両方で強制されます。

IdM Web UI を使用して、個々の example.user IdM ユーザーに対して 2FA を有効にするには、以下の手順を完了します。

前提条件

  • 管理者権限

手順

  1. IdM admin 権限を使用して IdM Web UI にログインします。
  2. Identity → Users → Active users タブを開きます。

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

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

この時点で、IdM ユーザーに対して OTP 認証が有効になります。

次に、管理者権限を持つユーザーまたは example.user が、example.user アカウントに新しいトークン ID を割り当てる必要があります。

7.4. IdM での OTP バリデーション用の RADIUS サーバー設定

プロプライエタリーのワンタイムパスワード (OTP) ソリューションから Identity Management (IdM) ネイティブの OTP ソリューションへの大規模なデプロイメントの移行を可能にするために、IdM では、ユーザーのサブセットに対して OTP バリデーションをサードパーティーの RADIUS サーバーにオフロードすることができます。管理者は、各プロキシーが単一の RADIUS サーバーのみを参照できる RADIUS プロキシーのセットを作成します。複数のサーバーに対応する必要がある場合は、複数の RADIUS サーバーを参照する仮想 IP ソリューションを作成することが推奨されます。

このようなソリューションは、keepalived デーモンなどを使用して、RHEL IdM の外部でビルドする必要があります。次に、管理者はこれらのプロキシーセットのいずれかをユーザーに割り当てます。ユーザーが RADIUS プロキシーが設定されている限り、IdM は他のすべての認証メカニズムをバイパスします。

注記

IdM は、サードパーティーシステムのトークンに対するトークン管理または同期のサポートを提供しません。

OTP バリデーション用に RADIUS サーバーを設定し、プロキシーサーバーにユーザーを追加する手順を実行します。

前提条件

手順

  1. RADIUS プロキシーを追加します。

    $ ipa radiusproxy-add proxy_name --secret secret

    このコマンドは、必要な情報を挿入するように求められます。

    RADIUS プロキシーの設定には、クライアントとサーバーとの間の共通のシークレットを使用して認証情報をラップする必要があります。--secret パラメーターにこのシークレットを指定します。

  2. 追加したプロキシーにユーザーを割り当てます。

    ipa user-mod radiususer --radius=proxy_name
  3. 必要に応じて、RADIUS に送信するユーザー名を設定します。

    ipa user-mod radiususer --radius-username=radius_user

これにより、RADIUS プロキシーサーバーがユーザーの OTP 認証の処理を開始します。

ユーザーが IdM ネイティブ OTP システムに移行する準備ができたら、ユーザーの RADIUS プロキシー割り当てを削除するだけです。

7.4.1. 低速ネットワークで RADIUS サーバーを実行する場合の KDC タイムアウト値の変更

低速ネットワークで RADIUS プロキシーを実行している場合などの特定の状況では、ユーザーがトークンを入力するのを待機している間に接続がタイムアウトして、RADIUS サーバーが応答する前に Identity Management (IdM) Kerberos Distribution Center (KDC) が接続を閉じます。

KDC のタイムアウト設定を変更するには、以下を実行します。

  1. /var/kerberos/krb5kdc/kdc.conf ファイルの [otp] セクションで timeout パラメーターの値を変更します。たとえば、タイムアウトを 120 秒に設定するには、以下のようにします。

    [otp]
    DEFAULT = {
      timeout = 120
      ...
    }
  2. krb5kdc サービスを再起動します。

    # systemctl restart krb5kdc

関連情報

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

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

前提条件

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

手順

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

    Screenshot of the IdM Web UI highlighting the Add button near the upper-right of the OTP Tokens page which is a sub-page of the Authentication section

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

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

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

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

Screenshot of the FreeOTP application from a mobile telephone displaying two entries for OTP tokens. The first OTP token is for the example.user@IDM.EXAMPLE.COM domain and its entry displays a 6-digit OTP while its timer is running out.

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

ワンタイムパスワード (OTP) を使用して IdM Web UI に初めてログインする際には、この手順に従います。

前提条件

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

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

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

手順

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

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

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

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

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

A screenshot of the first screen visible after logging in to the IdM Web UI. There are 5 tabs listed along the top of the screen: Identity - Policy - Authentication - Network Services - IPA Server. The Identity tab has been selected and it is displaying the Users page which is the first menu item among 6 choices just below the tabs: Users - Hosts - Services - Groups - ID Views - Automember. The Active users page displays a table of user logins and their information: First name - Last name - Status - UID - Email address - Telephone number - Job Title.

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

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

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

前提条件

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

手順

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

    A screenshot of the IdM Web UI log in page. The "Username" and "Password" fields are empty. A link to "Sync OTP Token" at the bottom right next to the "Log In" button is highlighted.

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

    A screenshot of the screen to change the OTP token. The "Username" field has been filled in with "admin". The password in the "Password" field has been obfuscated with solid circles. The "First OTP" and "Second OTP" fields also have their 6-character entries obfuscated. The last field is labeled "Token ID" and has 16 hexadecimal characters such as "18c5d06cfcbd4927". There are "Cancel" and "Sync OTP Token" buttons at the bottom right.

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

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

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

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

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

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

前提条件

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

手順

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

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

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

    A screenshot of the IdM Web UI with a banner across the top that states "Your password has expired. Please enter a new password." The "Username" field displays "example.user" and cannot be edited. The following fields have been filled in but their contents have been replaced with dots to obfuscate the passwords: "Current Password" - "OTP" - "New Password" - "Verify Password."

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

7.9. OTP または RADIUS ユーザーとして IdM チケット許可チケットを取得する

OTP ユーザーとして Kerberos チケット保証チケット (TGT) を取得するには、匿名の Kerberos チケットを要求し、Flexible Authentication via Secure Tunneling (FAST) チャネルを有効にして、Kerberos クライアントと Kerberos Distribution Center (KDC) 間の安全な接続を提供します。

前提条件

  • IdM クライアントと IdM サーバーは RHEL 8.7 以降を使用します。
  • IdM クライアントと IdM サーバーは SSSD 2.7.0 以降を使用します。
  • 必要なユーザーアカウントに対して OTP が有効になりました。

手順

  1. 次のコマンドを実行して認証情報キャッシュを初期化します。

    [root@client ~]# kinit -n @IDM.EXAMPLE.COM -c FILE:armor.ccache

    このコマンドは、新しい Kerberos チケットを要求するたびに指定する必要がある armor.ccache ファイルを作成することに注意してください。

  2. 次のコマンドを実行して Kerberos チケットを要求します。

    [root@client ~]# kinit -T FILE:armor.ccache <username>@IDM.EXAMPLE.COM
    Enter your OTP Token Value.

検証

  • Kerberos チケット情報を表示します。

    [root@client ~]# klist -C
    Ticket cache: KCM:0:58420
    Default principal: <username>@IDM.EXAMPLE.COM
    
    Valid starting     Expires            Service principal
    05/09/22 07:48:23  05/10/22 07:03:07  krbtgt/IDM.EXAMPLE.COM@IDM.EXAMPLE.COM
    config: fast_avail(krbtgt/IDM.EXAMPLE.COM@IDM.EXAMPLE.COM) = yes
    08/17/2022 20:22:45  08/18/2022 20:22:43  krbtgt/IDM.EXAMPLE.COM@IDM.EXAMPLE.COM
    config: pa_type(krbtgt/IDM.EXAMPLE.COM@IDM.EXAMPLE.COM) = 141

    pa_type = 141 は OTP/RADIUS 認証を示します。

第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 サービスとサーバー間の情報フロー方法を説明し、環境で失敗した認証試行のトラブルシューティングを行うには、次を参照してください。

8.1. SSSD で IdM ユーザー情報を取得するデータフロー

以下の図は、getent passwd <idm_user_name> コマンドを使用して IdM ユーザー情報の要求時に IdM クライアントと IdM サーバーとの間の情報フローを簡単に説明します。

A diagram with numbered arrows representing the flow of information between an IdM client and an IdM server. The following numbered list describes each step in the process.

  1. getent コマンドは、libc ライブラリーから getpwnam 呼び出しをトリガーします。
  2. libc ライブラリーは、/etc/nsswitch.conf 設定ファイルを参照して、どのサービスがユーザー情報を提供するかを確認し、SSSD サービスのエントリー sss を検出します。
  3. libc ライブラリーは、nss_sss モジュールを開きます。
  4. nss_sss モジュールは、ユーザー情報のメモリーマップキャッシュを確認します。データがキャッシュに存在する場合は、nss_sss モジュールがそれを返します。
  5. ユーザー情報が memory-mapped キャッシュにない場合、リクエストは SSSD sssd_nss レスポンダープロセスに渡されます。
  6. SSSD サービスはキャッシュをチェックします。データがキャッシュに存在し、有効な場合は、sssd_nss レスポンダーがキャッシュからデータを読み取って、アプリケーションに返します。
  7. データがキャッシュにない場合や期限切れである場合、sssd_nss レスポンダーは適切なバックエンドプロセスに対してクエリーを実行し、応答を待機します。SSSD サービスは、sssd.conf 設定ファイルで id_provider=ipa を設定して有効にした、IdM 環境の IPA バックエンドを使用します。
  8. sssd_be バックエンドプロセスは IdM サーバーに接続して、IdM LDAP Directory Server から情報を要求します。
  9. IdM サーバーの SSSD バックエンドは、IdM クライアントの SSSD バックエンドプロセスに対応します。
  10. クライアントの SSSD バックエンドは、生成されるデータを SSSD キャッシュに保存し、キャッシュが更新されたレスポンダープロセスを警告します。
  11. sssd_nss フロントエンドレスプロセスが SSSD キャッシュから情報を取得します。
  12. sssd_nss レスポンダーは、nss_sss レスポンダーにユーザー情報を送信し、リクエストを完了します。
  13. 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 データベースとの間の通信にフォーカスします。

A diagram with numbered arrows representing the flow of information between an IdM client, an IdM server, and an AD Domain Controller. The following numbered list describes each step in the process.

  1. IdM クライアントは、AD ユーザー情報に関するローカルの SSSD キャッシュを検索します。
  2. IdM クライアントにユーザー情報がない場合や、情報が古い場合に、クライアントの SSSD サービスが IdM サーバーの extdom_extop プラグインに問い合わせて、LDAP 拡張操作を実行し、情報を要求します。
  3. IdM サーバーの SSSD サービスは、ローカルキャッシュで AD ユーザー情報を検索します。
  4. IdM サーバーに SSSD キャッシュにユーザー情報がない場合や、その情報が古い場合は、LDAP 検索を実行して、AD ドメインコントローラーからユーザー情報を要求します。
  5. IdM サーバーの SSSD サービスは、AD ドメインコントローラーから AD ユーザー情報を受け取り、キャッシュに保存します。
  6. extdom_extop プラグインは、LDAP 拡張操作を完了する IdM サーバーの SSSD サービスから情報を受信します。
  7. IdM クライアントの SSSD サービスは、LDAP 拡張操作から AD ユーザー情報を受信します。
  8. IdM クライアントは、AD ユーザー情報を SSSD キャッシュに保存し、要求したアプリケーションに情報を返します。

8.3. IdM で SSSD を使用してユーザーとして認証する場合にデータフロー

IdM サーバーまたはクライアントでユーザーとして認証するには、以下のコンポーネントが必要です。

  • sshd サービスなどの認証要求を開始するサービス
  • PAM (プラグ可能な認証モジュール) ライブラリーとそのモジュール。
  • SSSD サービス、そのレスポンダー、およびバックエンド。
  • スマートカード認証が設定されている場合は、スマートカードリーダー。
  • 認証サーバー:

    • IdM ユーザーは、IdM Kerberos Key Distribution Center (KDC) に対して認証されます。
    • Active Directory (AD) ユーザーは、AD ドメインコントローラー (DC) に対して認証されます。

以下の図は、コマンドラインの SSH サービスを介してホストにローカルでログインしようとすると、情報フローを簡単に認証する必要がある場合を示しています。

A diagram with numbered arrows representing the flow of information between an IdM client and an IdM server or AD Domain Controller during an authentication attempt. The following numbered list describes each step in the process.

  1. ssh コマンドで認証を試みると、libpam ライブラリーがトリガーされます。
  2. libpam ライブラリー は、認証の試行を要求するサービスに対応する /etc/pam.d/ ディレクトリーの PAM ファイルを参照します。この例では、ローカルホストの SSH サービス経由で認証されている例では、pam_sss.so ライブラリーは /etc/pam.d/system-auth 設定ファイルを確認し、SSSD PAM の pam_sss.so エントリーを検出します。

    auth    sufficient    pam_sss.so
  3. 利用可能な認証方法を判断するため、libpam ライブラリーは pam_sss モジュールを開き、SSSD サービスの sssd _pam PAM レスポンダーに SSS_PAM_PREAUTH リクエスト を送信します。
  4. スマートカード認証が設定されていると、SSSD サービスは一時的な p11_child プロセスを生成し、スマートカードを確認し、そこから証明書を取得します。
  5. ユーザーにスマートカード認証が設定されていると、sssd_pam レスポンダーは、スマートカードの証明書とユーザーを照合します。sssd_pam レスポンダーは、グループメンバーシップがアクセス制御に影響する可能性があるため、ユーザーが属するグループの検索も実行します。
  6. sssd_pam レスポンダーは、SSS_PAM_PREAUTH 要求を sssd_be バックエンドレスに送信し、パスワードや 2 要素認証などのサーバーがサポートする認証方法を表示します。SSSD サービスが IPA レスポンダーを使用する IdM 環境では、デフォルトの認証方法は Kerberos です。この例では、ユーザーは簡単な Kerberos パスワードで認証されます。
  7. sssd_be レスポンダーは一時的な krb5_child プロセスを起動します。
  8. krb5_child プロセスは、IdM サーバーの KDC に連絡して、利用可能な認証方法を確認します。
  9. KDC はリクエストに応答します。

    1. krb5_child プロセスは応答を評価し、結果を sssd_be バックエンドプロセスに送信します。
    2. sssd_be バックエンドプロセスが結果を受け取ります。
    3. sssd_pam レスポンダーは結果を受け取ります。
    4. pam_sss モジュールは結果を受け取ります。
  10. ユーザーにパスワード認証が設定されていると、pam_sss モジュールにより、パスワードの入力が求められます。スマートカード認証が設定されていると、pam_sss モジュールにより、スマートカードの PIN の入力が求められます。
  11. モジュールは、ユーザー名とパスワードを使用して SSS_PAM_ AUTHENTICATE 要求を送信します。これは以下が実行されます。

    1. sssd_pam レスポンダー。
    2. sssd_be バックエンドプロセス。
  12. sssd_be プロセスは、KDC に問い合わせる一時的な krb5_child プロセスを起動します。
  13. krb5_child process は、ユーザー名とパスワードを使用して KDC から Kerberos チケット保証チケット (TGT) の取得を試みます。
  14. krb5_child プロセスは、認証の試行の結果を受け取ります。
  15. krb5_child プロセス:

    1. TGT を認証情報キャッシュに保存します。
    2. sssd_be バックエンドプロセスに認証結果を返します。
  16. 認証結果は sssd_be プロセスから以下を行います。

    1. sssd_pam レスポンダー。
    2. pam_sss モジュール。
  17. pam_sss モジュールは、その他のアプリケーションが参照できるように、環境変数をユーザーの TGT の場所で設定します。

8.4. 認証問題の範囲の制限

ユーザーを正常に認証するには、ユーザー情報を保存するデータベースから SSSD サービスでユーザー情報を取得できる必要があります。以下の手順では、認証プロセスの異なるコンポーネントをテストする手順を説明します。これにより、ユーザーがログインできない場合に認証の問題のスコープを制限する方法を説明します。

手順

  1. 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
  2. クライアントが IP アドレスを使用してユーザーデータベースサーバーに接続できることを確認します。

    [user@client ~]$ ping <IP_address_of_the_database_server>

    この手順が失敗した場合は、ネットワークとファイアウォール設定が、IdM クライアントとサーバー間の直接通信が許可されていることを確認してください。firewalld の使用および設定 を参照してください。

  3. クライアントが、完全修飾ホスト名を使用して 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>

    このオプションを使用する場合は、そのオプションに記載されているサーバーと通信できることを確認します。

  4. クライアントが LDAP サーバーに対して認証でき、ldapsearch コマンドでユーザー情報を取得できることを確認します。

    1. LDAP サーバーが server.example.com などの IdM サーバーである場合は、ホストの Kerberos チケットを取得し、ホスト Kerberos プリンシパルで認証されるデータベース検索を実行します。

      [user@client ~]$ kinit -k 'host/client.example.com@EXAMPLE.COM'
      [user@client ~]$ ldapsearch -LLL -Y GSSAPI -h server.example.com -b “dc=example,dc=com” uid=<user_name>
    2. LDAP サーバーが server.example.com などの Active Directory (AD) Domain Controller (DC) サーバーである場合は、ホストの Kerberos チケットを取得し、ホスト Kerberos プリンシパルで認証されるデータベース検索を実行します。

      [user@client ~]$ kinit -k 'CLIENT$@AD.EXAMPLE.COM'
      [user@client ~]$ ldapsearch -LLL -Y GSSAPI -h server.ad.example.com -b “dc=example,dc=com” sAMAccountname=<user_name>
    3. 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 サーバーを検索できることを確認します。

  5. SSSD サービスは Kerberos 暗号化を使用するため、ログインできないユーザーとして Kerberos チケットを取得できます。

    1. LDAP サーバーが IdM サーバーの場合:

      [user@client ~]$ kinit <user_name>
    2. LDAP サーバーデータベースが AD サーバーの場合:

      [user@client ~]$ kinit <user_name@AD.EXAMPLE.COM>

    この手順が失敗した場合は、Kerberos サーバーが適切に動作し、すべてのサーバーが同期され、ユーザーアカウントがロックされていないことを確認します。

  6. コマンドラインに関するユーザー情報を取得できることを確認します。

    [user@client ~]$ getent passwd <user_name>
    [user@client ~]$ id <user_name>

    この手順が失敗した場合は、クライアントの SSSD サービスがユーザーデータベースから情報を受信できることを確認します。

    1. /var/log/messages ログファイルのエラーを確認します。
    2. SSSD サービスで詳細なロギングを有効にし、デバッグログを収集して、問題のソースに関するログを確認します。
    3. (オプション) Red Hat テクニカルサポートケースを作成し、収集したトラブルシューティング情報を提供します。
  7. ホストで sudo を実行することが許可されている場合は、sssctl ユーティリティーを使用して、ユーザーがログインを許可されていることを確認します。

    [user@client ~]$ sudo sssctl user-checks -a auth -s ssh <user_name>

    この手順が失敗した場合は、PAM 設定、IdM HBAC ルール、IdM RBAC ルールなどの承認設定を確認します。

    1. ユーザーの UID が、/etc/login.defs ファイルで定義されている UID_MIN 以上であることを確認してください。
    2. /var/log/secure ログファイルおよび /var/log/messages ログファイルで認証エラーを確認します。
    3. SSSD サービスで詳細なロギングを有効にし、デバッグログを収集して、問題のソースに関するログを確認します。
    4. (オプション) 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 パスワードが必要です。

手順

  1. テキストエディターで /etc/sssd/sssd.conf ファイルを開きます。
  2. 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
  3. sssd.conf ファイルを保存して閉じます。
  4. 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 パスワードが必要です。

手順

  1. IdM サーバーで詳細な SSSD デバッグロギングを有効にします。

    [root@server ~]# sssctl debug-level 6
  2. 認証問題が発生しているユーザーの SSSD キャッシュでオブジェクトを無効にするため、LDAP サーバーを省略し、SSSD がすでにキャッシュされている情報を取得しません。

    [root@server ~]# sssctl cache-expire -u idmuser
  3. 古い SSSD ログを削除して、トラブルシューティングのデータセットを最小限に抑える。

    [root@server ~]# sssctl logs-remove
  4. 認証問題が発生し、試行前後にタイムスタンプを収集する際に、ユーザーが認証問題が発生しようと試みます。これらのタイムスタンプは、データセットのスコープをさらに絞り込むことができます。

    [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
  5. (オプション) 詳細な SSSD ログの収集を続行しない場合は、デバッグレベルを下げます。

    [root@server ~]# sssctl debug-level 2
  6. 障害のある要求に関する情報を 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
  7. 認証問題の原因を判断できない場合は、以下を行います。

    1. 最近生成した SSSD ログを収集します。

      [root@server ~]# sssctl logs-fetch sssd-logs-Mar29.tar
    2. Red Hat テクニカルサポートケースを作成し、以下を提供します。

      1. SSSD ログ: sssd-logs-Mar29.tar
      2. ログに対応する要求のタイムスタンプおよびユーザー名を含むコンソールの出力。

        [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

8.9. SSSD サービスからデバッグログを収集し、IdM クライアントによる認証問題のトラブルシューティング

IdM クライアントに IdM ユーザーとして認証を試行する際に問題が発生した場合は、IdM サーバーでユーザー情報を取得できることを確認します。IdM サーバーでユーザー情報を取得できない場合は、(IdM サーバーから情報を取得する) IdM クライアントでそれを取得できなくなります。

認証の問題が IdM サーバーから生成されていないことを確認したら、IdM サーバーと IdM クライアントの両方から SSSD デバッグログを収集していました。

前提条件

  • IdM サーバーではなく、IdM クライアントで認証の問題のみがあります。
  • sssctl コマンドを実行して SSSD サービスを再起動するには、root パスワードが必要です。

手順

  1. クライアントで、テキストエディターで /etc/sssd/sssd.conf ファイルを開きます。
  2. クライアントでipa_server オプションをファイルの [domain] セクションに追加し、IdM サーバーに設定します。これにより、IdM クライアントは他の IdM サーバーの自動検出を避け、このテストを 1 つのクライアントおよびサーバー 1 台だけに制限します。

    [domain/example.com]
    ipa_server = server.example.com
    ...
  3. クライアントsssd.conf ファイルを保存して閉じます。
  4. クライアントで SSSD サービスを再起動して、設定の変更を読み込みます。

    [root@client ~]# systemctl restart sssd
  5. サーバーおよびクライアントで、詳細な SSSD デバッグロギングを有効にします。

    [root@server ~]# sssctl debug-level 6
    [root@client ~]# sssctl debug-level 6
  6. サーバーおよびクライアントで、認証問題が発生しているユーザーの SSSD キャッシュの検証オブジェクトでは、LDAP データベースを迂回せず、SSSD がすでにキャッシュされています。

    [root@server ~]# sssctl cache-expire -u idmuser
    [root@client ~]# sssctl cache-expire -u idmuser
  7. サーバーおよびクライアントで、古い SSSD ログを削除して、トラブルシューティングのデータセットを最小限に抑える。

    [root@server ~]# sssctl logs-remove
    [root@server ~]# sssctl logs-remove
  8. クライアントで、認証問題が発生し、試行前後にタイムスタンプを収集する際に、ユーザーが認証問題が発生しようと試みます。これらのタイムスタンプは、データセットのスコープをさらに絞り込むことができます。

    [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
  9. (オプション) サーバーおよびクライアント 詳細な SSSD ログの収集したくない場合はデバッグレベルを下げます。

    [root@server ~]# sssctl debug-level 0
    [root@client ~]# sssctl debug-level 0
  10. サーバーおよびクライアントで、失敗した要求に関する情報を SSSD ログを確認します。

    1. クライアントログのクライアントからの要求を確認します。
    2. サーバーログのクライアントからの要求を確認します。
    3. サーバーログでリクエストの結果を確認します。
    4. サーバーからリクエストの結果を受信するクライアントの結果を確認します。
  11. 認証問題の原因を判断できない場合は、以下を行います。

    1. IdM サーバーおよび IdM クライアントで最近生成した SSSD ログを収集します。ホスト名またはロールに応じてラベルを付けます。

      [root@server ~]# sssctl logs-fetch sssd-logs-server-Mar29.tar
      [root@client ~]# sssctl logs-fetch sssd-logs-client-Mar29.tar
    2. Red Hat テクニカルサポートケースを作成し、以下を提供します。

      1. SSSD デバッグログ:

        1. サーバーから sssd-logs-server-Mar29.tar
        2. クライアントからの sssd-logs-client-Mar29.tar
      2. ログに対応する要求のタイムスタンプおよびユーザー名を含むコンソールの出力。

        [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 権限を持っている。

手順

  1. SSSD ログファイルを確認するには、less ユーティリティーを使用してログファイルを開きます。たとえば、/var/log/sssd/sssd_example.com.log を表示するには、次のコマンドを実行します。

    [root@server ~]# less /var/log/sssd/sssd_example.com.log
  2. クライアント要求に関する情報は、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].

8.11. ログアナライザーツールを使用したクライアント要求の追跡

System Security Services Daemon (SSSD) には、複数の SSSD コンポーネントからのログファイル全体でリクエストを最初から最後まで追跡するために使用できるログ解析ツールが含まれています。

8.11.1. ログアナライザツールのしくみ

ログ解析ツールを使用すると、複数の SSSD コンポーネントからのログファイル全体で SSSD リクエストを最初から最後まで追跡できます。sssctl analyze コマンドを使用してアナライザーツールを実行します。

ログアナライザツールは、SSSD の NSS および PAM の問題をトラブルシューティングし、SSSD デバッグログをより簡単に確認するのに役立ちます。SSSD プロセス全体の特定のクライアントリクエストにのみ関連する SSSD ログを抽出して出力できます。

SSSD は、ユーザー認証 (sussh) 情報とは別に、ユーザーおよびグループの ID 情報 (idgetent) を追跡します。NSS レスポンダのクライアント ID(CID) は PAM レスポンダーの CID とは独立しており、NSS と PAM のリクエストを解析すると重複した数値が表示されます。--pam オプションを sssctl analyze コマンドとともに使用して、PAM リクエストを確認します。

注記

SSSD メモリーキャッシュから返されたリクエストはログに記録されず、ログアナライザツールで追跡できません。

関連情報

  • sudo sssctl analyze request --help
  • sudo sssctl analyze --help
  • sssd.conf man ページ
  • sssctl の man ページ

8.11.2. ログアナライザツールの実行

ログアナライザーツールを使用して SSSD でクライアントリクエストを追跡するには、次の手順に従います。

前提条件

  • ログ解析機能を有効にするには、/etc/sssd/sssd.conf ファイルの [$responder] セクション、および [domain/$domain] セクションで debug_level を 7 以上に設定する必要がある。
  • 分析するログは、libtevent チェーン ID をサポートする互換性のあるバージョンの SSSD、つまり RHEL 8.5 以降の SSSD からのものである必要がある。

手順

  1. ログアナライザツールを list モードで実行して、追跡しているリクエストのクライアント ID を特定し、-v オプションを追加して詳細な出力を表示します。

    # sssctl analyze request list -v

    SSSD に対して行われた最近のクライアントリクエストの詳細なリストが表示されます。

    注記

    PAM リクエストを分析する場合は、sssctl analyze request list コマンドを -pam オプション付きで実行します。

  2. show [unique client ID] オプションを指定してログアナライザツールを実行し、指定したクライアント ID 番号に関連するログを表示します。

    # sssctl analyze request show 20
  3. 必要に応じて、ログファイルに対してログアナライザツールを実行できます。次に例を示します。

    # sssctl analyze request --logdir=/tmp/var/log/sssd

関連情報

  • sssctl analyze request list --help
  • sssctl analyze request show --help
  • sssctl の man ページ。

8.12. 関連情報

第9章 Ansible Playbook を使用して IdM を管理する環境の準備

Identity Management (IdM) を管理するシステム管理者は、Red Hat Ansible Engine を使用する際に以下を行うことが推奨されます。

  • ホームディレクトリーに Ansible Playbook 専用のサブディレクトリー (例: ~/MyPlaybooks) を作成します。
  • /usr/share/doc/ansible-freeipa/*/usr/share/doc/rhel-system-roles/* ディレクトリーおよびサブディレクトリーから ~/MyPlaybooks ディレクトリーにサンプル Ansible Playbook をコピーして調整します。
  • ~/MyPlaybooks ディレクトリーにインベントリーファイルを追加します。

このプラクティスを使用すると、すべての Playbook を 1 か所で見つけることができます。

注記

マネージドノードで root 権限を呼び出さずに ansible-freeipa Playbook を実行できます。例外には、ipaserveripareplicaipaclientipasmartcard_serveripasmartcard_client、および ipabackup ansible-freeipa ロールを使用する Playbook が含まれます。これらのロールには、ディレクトリーおよび dnf ソフトウェアパッケージマネージャーへの特権アクセスが必要です。

Red Hat Enterprise Linux IdM ドキュメントの Playbook は、次の セキュリティー設定 を前提としています。

  • IdM admin は、管理ノードのリモート Ansible ユーザーです。
  • Ansible vault に暗号化された IdM admin パスワードを保存します。
  • Ansible vault を保護するパスワードをパスワードファイルに配置しました。
  • ローカルの ansible ユーザーを除く全員に対して、vault パスワードファイルへのアクセスをブロックします。
  • vault パスワードファイルを定期的に削除して再作成します。

別のセキュリティー設定 も検討してください。

9.1. Ansible Playbook を使用して IdM を管理するためのコントロールノードと管理ノードの準備

~/MyPlaybooks ディレクトリーを作成し、それを使用して Ansible Playbook を保存および実行できるように設定するには、次の手順に従います。

前提条件

  • 管理対象ノードに IdM サーバー (server.idm.example.com および replica.idm.example.com) をインストールしている。
  • DNS およびネットワークを設定し、コントロールノードから直接管理対象ノード (server.idm.example.com および replica.idm.example.com) にログインすることができる。
  • IdM admin のパスワードを把握している。

手順

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

    $ cd ~/MyPlaybooks
  2. ~/MyPlaybooks/ansible.cfg ファイルを以下の内容で作成します。

    [defaults]
    inventory = /home/your_username/MyPlaybooks/inventory
    remote_user = admin
  3. ~/MyPlaybooks/inventory ファイルを以下の内容で作成します。

    [eu]
    server.idm.example.com
    
    [us]
    replica.idm.example.com
    
    [ipaserver:children]
    eu
    us

    この設定は、これらの場所にあるホストの 2 つのホストグループ (euus) を定義します。さらに、この設定は、eu および us グループのすべてのホストを含む ipaserver ホストグループを定義します。

  4. [オプション] SSH 公開鍵および秘密鍵を作成します。テスト環境でのアクセスを簡素化するには、秘密鍵にパスワードを設定しないでください。

    $ ssh-keygen
  5. 各マネージドノードの IdM admin アカウントに SSH 公開鍵をコピーします。

    $ ssh-copy-id admin@server.idm.example.com
    $ ssh-copy-id admin@replica.idm.example.com

    これらのコマンドでは、IdM 管理者 パスワードを入力します。

  6. Vault パスワードを含む password_file ファイルを作成します。

    redhat
  7. ファイルを変更する権限を変更します。

    $ chmod 0600 password_file
  8. IdM の admin パスワードを保存する secret.yml Ansible Vault を作成します。

    1. Vault パスワードを保存するように password_file を設定します。

      $ ansible-vault create --vault-password-file=password_file secret.yml
    2. プロンプトが表示されたら、secret.yml ファイルの内容を入力します。

      ipaadmin_password: Secret123
注記

Playbook で暗号化された ipaadmin_password を使用するには、vars_file ディレクティブを使用する必要があります。たとえば、IdM ユーザーを削除する単純な Playbook は次のようになります。

---
- name: Playbook to handle users
  hosts: ipaserver

  vars_files:
  - /home/user_name/MyPlaybooks/secret.yml

  tasks:
  - name: Delete user robot
    ipauser:
      ipaadmin_password: "{{ ipaadmin_password }}"
      name: robot
      state: absent

Playbook を実行するときに、--vault-password-file=password_file オプションを追加して、Ansible に Vault パスワードを使用して ipaadmin_password を復号するように指示します。以下に例を示します。

ansible-playbook -i inventory --vault-password-file=password_file del-user.yml
警告

セキュリティー上の理由から、各セッションの終了時に Vault パスワードファイルを削除し、新しいセッションの開始時に手順 7 ~ 9 を繰り返します。

9.2. ansible-freeipa Playbook に必要な認証情報を提供するさまざまな方法

ansible-freeipa ロールおよびモジュールを使用する Playbook の実行に必要な認証情報を提供するための様々な方法には長所と短所があります。

Playbook にパスワードを平文で保存する

利点:

  • Playbook を実行するたびにプロンプトが表示されません。
  • 実装が簡単。

短所:

  • ファイルにアクセスできるすべてのユーザーがパスワードを読み取ることができます。内部または外部のリポジトリーなどで間違った権限を設定してファイルを共有すると、セキュリティーが損なわれる可能性があります。
  • 高いメンテナンス作業: パスワードが変更された場合は、すべての Playbook で変更する必要があります。

Playbook の実行時に対話的にパスワードを入力する

利点:

  • パスワードはどこにも保存されないため、誰もパスワードを盗むことはできません。
  • パスワードを簡単に更新できます。
  • 実装が簡単。

短所:

  • スクリプトで Ansible Playbook を使用している場合は、パスワードを対話的に入力する必要があると不便な場合があります。

パスワードを Ansible Vault に保存し、Vault パスワードをファイルに保存します。

利点:

  • ユーザーパスワードは暗号化されて保存されます。
  • 新しい Ansible Vault を作成することで、ユーザーパスワードを簡単に更新できます。
  • ansible-vault rekey --new-vault-password-file=NEW_VAULT_PASSWORD_FILE secret.yml コマンドを使用して、ansible Vault を保護するパスワードファイルを簡単に更新できます。
  • スクリプトで Ansible Playbook を使用している場合は、Ansible Vault を対話的に保護するパスワードを入力する必要がないのは便利です。

短所:

  • 機密性の高いプレーンテキストパスワードを含むファイルは、ファイルのアクセス許可やその他のセキュリティー対策によって保護することが重要です。

パスワードを Ansible Vault に保存し、Vault のパスワードを対話的に入力する

利点:

  • ユーザーパスワードは暗号化されて保存されます。
  • Vault のパスワードはどこにも保存されていないため、誰も盗むことはできません。
  • 新しい Ansible Vault を作成することで、ユーザーパスワードを簡単に更新できます。
  • ansible-vault rekey file_name コマンドを使用して、Vault パスワードも簡単に更新できます。

短所:

  • スクリプトで Ansible Playbook を使用している場合は、Vault のパスワードを対話的に入力する必要があると不便な場合があります。

第10章 Ansible Playbook でのグローバル IdM 設定

Ansible 設定 モジュールを使用すると、Identity Management (IdM) のグローバル設定パラメーターを取得および設定できます。

10.1. Ansible Playbook での IdM 設定の取得

以下の手順では、Ansible Playbook を使用して、現在のグローバル IdM 設定に関する情報を取得する方法を説明します。

前提条件

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

    • Ansible バージョン 2.14 以降を使用している。
    • Ansible コントローラーに ansible-freeipa パッケージがインストールされている。
    • この例では、~/MyPlaybooks/ ディレクトリーに、IdM サーバーの完全修飾ドメイン名 (FQDN) を使用して Ansible インベントリーファイル を作成したことを前提としている。
    • この例では、secret.yml Ansible vault に ipaadmin_password が保存されていることを前提としています。
  • ターゲットノード (ansible-freeipa モジュールが実行されるノード) が、IdM クライアント、サーバー、またはレプリカとして IdM ドメインに含まれている。

手順

  1. 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
    
      vars_files:
      - /home/user_name/MyPlaybooks/secret.yml
      tasks:
      - name: Query IPA global configuration
        ipaconfig:
          ipaadmin_password: "{{ ipaadmin_password }}"
        register: serverconfig
    
      - debug:
          msg: "{{ serverconfig }}"
  2. 以下を変更してファイルを調整します。

    • IdM 管理者のパスワード。
    • その他の値 (必要な場合)。
  3. ファイルを保存します。
  4. Ansible Playbook を実行します。Playbook ファイル、secret.yml ファイルを保護するパスワードを格納するファイル、およびインベントリーファイルを指定します。

    $ ansible-playbook --vault-password-file=password_file -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
        }
    }

10.2. Ansible Playbook での IdM CA 更新サーバーの設定

組み込みの認証局 (CA) を使用する Identity Management (IdM) デプロイメントでは、CA 更新サーバーが IdM システム証明書を維持および更新します。IdM デプロイメントを確実に堅牢化します。

IdM CA 更新サーバーロールの詳細は、IdM CA 更新サーバーの使用 を参照してください。

以下の手順では、Ansible Playbook を使用して IdM CA 更新サーバーを設定する方法を説明します。

前提条件

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

    • Ansible バージョン 2.14 以降を使用している。
    • Ansible コントローラーに ansible-freeipa パッケージがインストールされている。
    • この例では、~/MyPlaybooks/ ディレクトリーに、IdM サーバーの完全修飾ドメイン名 (FQDN) を使用して Ansible インベントリーファイル を作成したことを前提としている。
    • この例では、secret.yml Ansible vault に ipaadmin_password が保存されていることを前提としています。
  • ターゲットノード (ansible-freeipa モジュールが実行されるノード) が、IdM クライアント、サーバー、またはレプリカとして IdM ドメインに含まれている。

手順

  1. 必要に応じて、現在の IdM CA 更新サーバーを特定します。

    $ ipa config-show | grep 'CA renewal'
      IPA CA renewal master: server.idm.example.com
  2. inventory.file などのインベントリーファイルを作成して、そのファイルに ipaserver を定義します。

    [ipaserver]
    server.idm.example.com
  3. 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
      vars_files:
      - /home/user_name/MyPlaybooks/secret.yml
    
      tasks:
      - name: set ca_renewal_master_server
        ipaconfig:
          ipaadmin_password: "{{ ipaadmin_password }}"
          ca_renewal_master_server: carenewal.idm.example.com
  4. 以下を変更してファイルを調整します。

    • ipaadmin_password 変数で設定した IdM 管理者のパスワード
    • ca_renewal_master_server 変数で設定した CA 更新サーバーの名前。
  5. ファイルを保存します。
  6. Ansible Playbook を実行します。Playbook ファイル、secret.yml ファイルを保護するパスワードを格納するファイル、およびインベントリーファイルを指定します。

    $ ansible-playbook --vault-password-file=password_file -v -i path_to_inventory_directory/inventory.file /usr/share/doc/ansible-freeipa/playbooks/config/set-ca-renewal-master-server.yml

検証手順

CA 更新サーバーが変更されたことを確認します。

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

    $ ssh admin@server.idm.example.com
    Password:
    [admin@server /]$
  2. IdM CA 更新サーバーの ID を要求します。

    $ ipa config-show | grep ‘CA renewal’
    IPA CA renewal master:  carenewal.idm.example.com

    この出力には、carenewal.idm.example.com サーバーが新しい CA 更新サーバーであることが分かります。

10.3. Ansible Playbook での IdM ユーザーのデフォルトシェルの設定

シェルとは、コマンドを受け入れて変換するプログラムです。Red Hat Enterprise Linux (RHEL) では、bashshkshzshfish など、複数のシェルが利用できます。Bash (または /bin/bash) は、ほとんどの Linux システムで一般的なシェルです。通常は、RHEL のユーザーアカウントのデフォルトシェルです。

以下の手順では、Ansible Playbook を使用して、IdM ユーザーのデフォルトシェルとして別のシェルである sh を設定する方法を説明します。

前提条件

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

    • Ansible バージョン 2.14 以降を使用している。
    • Ansible コントローラーに ansible-freeipa パッケージがインストールされている。
    • この例では、~/MyPlaybooks/ ディレクトリーに、IdM サーバーの完全修飾ドメイン名 (FQDN) を使用して Ansible インベントリーファイル を作成したことを前提としている。
    • この例では、secret.yml Ansible vault に ipaadmin_password が保存されていることを前提としています。
  • ターゲットノード (ansible-freeipa モジュールが実行されるノード) が、IdM クライアント、サーバー、またはレプリカとして IdM ドメインに含まれている。

手順

  1. 必要に応じて、Ansible Playbook retrieve-config.yml を使用して、IdM ユーザーの現在のシェルを特定します。詳細は、Ansible Playbook での IdM 設定の取得 を参照してください。
  2. inventory.file などのインベントリーファイルを作成して、そのファイルに ipaserver を定義します。

    [ipaserver]
    server.idm.example.com
  3. 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
      vars_files:
      - /home/user_name/MyPlaybooks/secret.yml
    
      tasks:
      # Set defaultlogin and maxusername
      - ipaconfig:
          ipaadmin_password: "{{ ipaadmin_password }}"
          defaultshell: /bin/bash
          maxusername: 64
  4. 以下を変更してファイルを調整します。

    • ipaadmin_password 変数で設定した IdM 管理者のパスワード
    • defaultshell 変数で設定されている IdM ユーザーのデフォルトのシェルが /bin/sh に設定されます。
  5. ファイルを保存します。
  6. Ansible Playbook を実行します。Playbook ファイル、secret.yml ファイルを保護するパスワードを格納するファイル、およびインベントリーファイルを指定します。

    $ ansible-playbook --vault-password-file=password_file -v -i path_to_inventory_directory/inventory.file /usr/share/doc/ansible-freeipa/playbooks/config/ensure-config-options-are-set.yml

検証手順

IdM で新しいセッションを開始すると、デフォルトのユーザーシェルが変更されていることを確認できます。

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

    $ ssh admin@server.idm.example.com
    Password:
    [admin@server /]$
  2. 現在のシェルを表示します。

    [admin@server /]$ echo "$SHELL"
    /bin/sh

    ログインしているユーザーが sh シェルを使用している。

10.4. Ansible を使用した IdM ドメインの NETBIOS 名の設定

NetBIOS 名は、Microsoft Windows (SMB) タイプの共有およびメッセージングに使用されます。NetBIOS 名を使用して、ドライブをマップしたり、プリンターに接続したりできます。

以下の手順に従って、Ansible Playbook を使用して Identity Management (IdM) ドメインの NetBIOS 名を設定します。

前提条件

  • 次の要件を満たすように Ansible コントロールノードを設定している。

    • Ansible バージョン 2.14 以降を使用している。
    • ansible-freeipa パッケージをインストールしている。

想定条件

  • この例では、~/MyPlaybooks/ ディレクトリーに、IdM サーバーの完全修飾ドメイン名 (FQDN) を使用して Ansible インベントリーファイル を作成したことを前提としている。
  • この例では、secret.yml Ansible ボールトに ipaadmin_password が保存されており、ボールトファイルのパスワードを知っていることを前提としています。

手順

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

    $ cd ~/MyPlaybooks/
  2. netbios-domain-name-present.yml Ansible Playbook ファイルを作成します。
  3. 以下の内容をファイルに追加します。

    ---
    - name: Playbook to change IdM domain netbios name
      hosts: ipaserver
      become: no
      gather_facts: no
    
    
      vars_files:
      - /home/user_name/MyPlaybooks/secret.yml
    
      tasks:
        - name: Set IdM domain netbios name
          ipaconfig:
            ipaadmin_password: "{{ ipaadmin_password }}"
            netbios_name: IPADOM
  4. ファイルを保存します。
  5. Ansible Playbook を実行します。Playbook ファイル、secret.yml ファイルを保護するパスワードを格納するファイル、およびインベントリーファイルを指定します。

    $ ansible-playbook --vault-password-file=password_file -v -i inventory netbios-domain-name-present.yml

    プロンプトが表示されたら、ボールトファイルのパスワードを入力します。

10.5. Ansible を使用して IdM ユーザーとグループに SID があることを確認する

Identity Management (IdM) サーバーは、ローカルドメインの ID 範囲のデータに基づいて、一意のセキュリティー識別子 (SID) を IdM ユーザーおよびグループに内部的に割り当てることができます。SID は、ユーザーオブジェクトとグループオブジェクトに格納されます。

IdM ユーザーとグループに SID があることを確認する目的は、特権属性証明書 (PAC) の生成を許可することです。これは、IdM-IdM 信頼への最初のステップです。IdM ユーザーおよびグループが SID を持っている場合、IdM は PAC データを使用して Kerberos チケットを発行できます。

次の目標を達成するには、次の手順に従ってください。

  • 既存の IdM ユーザーおよびユーザーグループの SID を生成します。
  • IdM の新しいユーザーおよびグループの SID の生成を有効にします。

前提条件

  • 次の要件を満たすように Ansible コントロールノードを設定している。

    • Ansible バージョン 2.14 以降を使用している。
    • ansible-freeipa パッケージをインストールしている。

想定条件

  • この例では、~/MyPlaybooks/ ディレクトリーに、IdM サーバーの完全修飾ドメイン名 (FQDN) を使用して Ansible インベントリーファイル を作成したことを前提としている。
  • この例では、secret.yml Ansible ボールトに ipaadmin_password が保存されており、ボールトファイルのパスワードを知っていることを前提としています。

手順

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

    $ cd ~/MyPlaybooks/
  2. sids-for-users-and-groups-present.yml Ansible Playbook ファイルを作成します。
  3. 以下の内容をファイルに追加します。

    ---
    - name: Playbook to ensure SIDs are enabled and users and groups have SIDs
      hosts: ipaserver
      become: no
      gather_facts: no
    
      vars_files:
      - /home/user_name/MyPlaybooks/secret.yml
    
      tasks:
        - name: Enable SID and generate users and groups SIDS
          ipaconfig:
            ipaadmin_password: "{{ ipaadmin_password }}"
            enable_sid: true
            add_sids: true

    enable_sid 変数は、将来の IdM ユーザーおよびグループの SID 生成を有効にします。add_sids 変数は、既存の IdM ユーザーおよびグループの SID を生成します。

    注記

    add_sids: true を使用する場合は、enable_sid 変数を true に設定する必要もあります。

  4. ファイルを保存します。
  5. Ansible Playbook を実行します。Playbook ファイル、secret.yml ファイルを保護するパスワードを格納するファイル、およびインベントリーファイルを指定します。

    $ ansible-playbook --vault-password-file=password_file -v -i inventory sids-for-users-and-groups-present.yml

    プロンプトが表示されたら、ボールトファイルのパスワードを入力します。

10.6. 関連情報

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

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

IdM (Identity Management) のユーザーライフサイクルには、次のようないくつかの段階があります。

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

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

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

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

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

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

重要

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

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

警告

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

警告

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

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

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

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

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

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

注記

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

前提条件

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

手順

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

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

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

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

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

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

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

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

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

    $ ipa help user-add

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

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

$ ipa user-find

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

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

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

前提条件

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

手順

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

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

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

$ ipa user-find

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

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

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

前提条件

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

手順

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

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

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

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

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

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

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

$ ipa user-del --continue user1 user2 user3

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

前提条件

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

手順

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

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

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

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

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

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

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

前提条件

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

手順

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

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

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

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

検証手順

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

    $ ipa user-find

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

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

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

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

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

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

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

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

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

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

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

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

重要

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

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

警告

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

警告

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

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

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

注記

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

前提条件

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

手順

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

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

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

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

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

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

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

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

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

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

注記

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

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

ユーザーが IdM にログインする前、およびユーザーを IdM グループに追加する前に、この手順に従ってステージユーザーアカウントをアクティベートする必要があります。

前提条件

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

手順

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

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

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

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

  5. Confirmation ダイアログボックスで OK をクリックします。

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

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

注記

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

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

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

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

注記

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

前提条件

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

手順

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

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

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

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

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

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

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

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

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

前提条件

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

手順

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

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

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

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

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

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

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

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

注記

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

前提条件

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

手順

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

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

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

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

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

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

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

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

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

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

前提条件

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

手順

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

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

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

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

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

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

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

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

以下を削除できます。

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

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

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

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

前提条件

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

手順

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

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

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

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

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

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

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

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

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

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

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

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

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

重要

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

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

警告

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

警告

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

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

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

前提条件

  • IdM admin のパスワードを把握している。
  • 次の要件を満たすように Ansible コントロールノードを設定している。

    • Ansible バージョン 2.14 以降を使用している。
    • Ansible コントローラーに ansible-freeipa パッケージがインストールされている。
    • この例では、~/MyPlaybooks/ ディレクトリーに、IdM サーバーの完全修飾ドメイン名 (FQDN) を使用して Ansible インベントリーファイル を作成したことを前提としている。
    • この例では、secret.yml Ansible vault に ipaadmin_password が保存されていることを前提としています。
  • ターゲットノード (ansible-freeipa モジュールが実行されるノード) が、IdM クライアント、サーバー、またはレプリカとして IdM ドメインに含まれている。

手順

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

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

    ---
    - name: Playbook to handle users
      hosts: ipaserver
    
      vars_files:
      - /home/user_name/MyPlaybooks/secret.yml
      tasks:
      - name: Create user idm_user
        ipauser:
          ipaadmin_password: "{{ ipaadmin_password }}"
          name: idm_user
          first: Alice
          last: Acme
          uid: 1000111
          gid: 10011
          phone: "+555123457"
          email: idm_user@acme.com
          passwordexpiration: "2023-01-19 23:59:59"
          password: "Password123"
          update_password: on_create

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

    • 名前: ログイン名
    • first: 名前 (名) の文字列
    • last: 名前 (姓) の文字列

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

    注記

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

  3. Playbook を実行します。

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

検証手順

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

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

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

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

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

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

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

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

前提条件

  • IdM admin のパスワードを把握している。
  • 次の要件を満たすように Ansible コントロールノードを設定している。

    • Ansible バージョン 2.14 以降を使用している。
    • Ansible コントローラーに ansible-freeipa パッケージがインストールされている。
    • この例では、~/MyPlaybooks/ ディレクトリーに、IdM サーバーの完全修飾ドメイン名 (FQDN) を使用して Ansible インベントリーファイル を作成したことを前提としている。
    • この例では、secret.yml Ansible vault に ipaadmin_password が保存されていることを前提としています。
  • ターゲットノード (ansible-freeipa モジュールが実行されるノード) が、IdM クライアント、サーバー、またはレプリカとして IdM ドメインに含まれている。

手順

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

    [ipaserver]
    server.idm.example.com
  2. IdM に存在させるユーザーのデータを指定して Ansible Playbook ファイルを作成します。この手順は、/usr/share/doc/ansible-freeipa/playbooks/user/ensure-users-present.yml ファイルのサンプルをコピーして変更し、簡素化できます。たとえば、ユーザー idm_user_1idm_user_2idm_user_3 を作成し、idm_user_1 のパスワードを Password123 として追加します。

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

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

  3. Playbook を実行します。

    $ ansible-playbook --vault-password-file=password_file -v -i path_to_inventory_directory/inventory.file path_to_playbooks_directory/add-users.yml

検証手順

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

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

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

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

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

13.4. Ansible Playbook を使用して JSON ファイルに指定してある複数の IdM ユーザーを存在させる手順

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

前提条件

  • IdM admin のパスワードを把握している。
  • 次の要件を満たすように Ansible コントロールノードを設定している。

    • Ansible バージョン 2.14 以降を使用している。
    • Ansible コントローラーに ansible-freeipa パッケージがインストールされている。
    • この例では、~/MyPlaybooks/ ディレクトリーに、IdM サーバーの完全修飾ドメイン名 (FQDN) を使用して Ansible インベントリーファイル を作成したことを前提としている。
    • この例では、secret.yml Ansible vault に ipaadmin_password が保存されていることを前提としています。
  • ターゲットノード (ansible-freeipa モジュールが実行されるノード) が、IdM クライアント、サーバー、またはレプリカとして IdM ドメインに含まれている。

手順

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

    [ipaserver]
    server.idm.example.com
  2. 必要なタスクが含まれる Ansible Playbook ファイルを作成します。存在させるユーザーのデータが指定された JSON ファイルを参照します。この手順は、/usr/share/doc/ansible-freeipa/ensure-users-present-ymlfile.yml ファイルのサンプルをコピーして変更し、簡素化できます。

    ---
    - name: Ensure users' presence
      hosts: ipaserver
    
      vars_files:
      - /home/user_name/MyPlaybooks/secret.yml
      tasks:
      - name: Include users.json
        include_vars:
          file: users.json
    
      - name: Users present
        ipauser:
          ipaadmin_password: "{{ ipaadmin_password }}"
          users: "{{ users }}"
  3. users.json ファイルを作成し、IdM ユーザーを追加します。この手順を簡素化するには、/usr/share/doc/ansible-freeipa/playbooks/user/users.json ファイルのサンプルをコピーして変更できます。たとえば、ユーザー idm_user_1idm_user_2idm_user_3 を作成し、idm_user_1 のパスワードを Password123 として追加します。

    {
      "users": [
       {
        "name": "idm_user_1",
        "first": "Alice",
        "last": "Acme",
        "password": "Password123"
       },
       {
        "name": "idm_user_2",
        "first": "Bob",
        "last": "Acme"
       },
       {
        "name": "idm_user_3",
        "first": "Eve",
        "last": "Acme"
       }
      ]
    }
  4. Ansible Playbook を実行します。Playbook ファイル、secret.yml ファイルを保護するパスワードを格納するファイル、およびインベントリーファイルを指定します。

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

検証手順

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

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

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

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

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

13.5. Ansible Playbook を使用してユーザーが存在しないことを確認する手順

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

前提条件

  • IdM admin のパスワードを把握している。
  • 次の要件を満たすように Ansible コントロールノードを設定している。

    • Ansible バージョン 2.14 以降を使用している。
    • Ansible コントローラーに ansible-freeipa パッケージがインストールされている。
    • この例では、~/MyPlaybooks/ ディレクトリーに、IdM サーバーの完全修飾ドメイン名 (FQDN) を使用して Ansible インベントリーファイル を作成したことを前提としている。
    • この例では、secret.yml Ansible vault に ipaadmin_password が保存されていることを前提としています。
  • ターゲットノード (ansible-freeipa モジュールが実行されるノード) が、IdM クライアント、サーバー、またはレプリカとして IdM ドメインに含まれている。

手順

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

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

    ---
    - name: Playbook to handle users
      hosts: ipaserver
    
      vars_files:
      - /home/user_name/MyPlaybooks/secret.yml
      tasks:
      - name: Delete users idm_user_1, idm_user_2, idm_user_3
        ipauser:
          ipaadmin_password: "{{ ipaadmin_password }}"
          users:
          - name: idm_user_1
          - name: idm_user_2
          - name: idm_user_3
          state: absent
  3. Ansible Playbook を実行します。Playbook ファイル、secret.yml ファイルを保護するパスワードを格納するファイル、およびインベントリーファイルを指定します。

    $ ansible-playbook --vault-password-file=password_file -v -i path_to_inventory_directory/inventory.file path_to_playbooks_directory/delete-users.yml

検証手順

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

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

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

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

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

13.6. 関連情報

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

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

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

ユーザーグループは、共通の特権、パスワードポリシーなどの特性が指定された一連のユーザーです。

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 デフォルトで作成されたユーザーグループ
グループ名デフォルトのグループメンバー

ipausers

すべての IdM ユーザー

admins

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

editors

特権のないレガシーグループ

trust admins

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 (ユーザー 2 つ) およびグループ B (ユーザー 3 つ) のチャート。グループ B はグループ A 内でネスト化されているので、グループ A にはユーザーが合計 5 つ含まれます。

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

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

IdM CLI を使用してユーザーグループを追加するには、次の手順に従います。

前提条件

手順

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

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

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

    • --nonposix は、非 POSIX グループを作成します。
    • --external は、外部グループを作成します。

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

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

14.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 のさまざまなグループタイプ を参照してください。

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

IdM CLI を使用してユーザーグループを削除するには、には、次の手順に従います。グループを削除しても、IdM からグループメンバーは削除されないことに注意してください。

前提条件

手順

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

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

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

ユーザーおよびユーザーグループの両方をユーザーグループのメンバーとして追加できます。詳細は、IdM のさまざまなグループタイプ および 直接および間接のグループメンバー を参照してください。IdM CLI を使用してユーザーグループにメンバーを追加するには、次の手順に従います。

前提条件

手順

  • 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) が最初にキャッシュを調べて、サーバーで不足または期限切れのレコードのみを検索するためです。

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

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

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

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

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

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

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

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

注記

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

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

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

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

手順

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

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

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

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

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

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

    $ sudo systemctl restart dirsrv.target

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

検証手順

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

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

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

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

前提条件

手順

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

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

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

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

14.8. IdM CLI を使用して IdM ユーザーグループにメンバーマネージャーとしてユーザーまたはグループを追加する手順

IdM CLI を使用してユーザーまたはグループをメンバーマネージャーとして IdM ユーザーグループに追加するには、次の手順に従います。メンバーマネージャーは、ユーザーまたはグループを IdM ユーザーグループに追加できますが、グループの属性を変更できません。

前提条件

  • 管理者としてログインしている。詳細は、Using kinit to log in to IdM manually を参照してください。
  • メンバーマネージャーとして追加するユーザーまたはグループの名前と、メンバーマネージャーが管理するグループ名を用意する。

手順

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

    たとえば、ユーザー testgroup_a のメンバーマネージャーとして追加します。

    $ ipa group-add-member-manager group_a --users=test
    Group name: group_a
    GID: 1133400009
    Membership managed by users: test
    -------------------------
    Number of members added 1
    -------------------------

    ユーザー testgroup_a のメンバーを管理できるようになりました。

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

    たとえば、 グループ group_adminsgroup_a のメンバーマネージャーとして追加します。

    $ ipa group-add-member-manager group_a --groups=group_admins
    Group name: group_a
    GID: 1133400009
    Membership managed by groups: group_admins
    Membership managed by users: test
    -------------------------
    Number of members added 1
    -------------------------

    グループ group_adminsgroup_a のメンバーを管理できるようになりました。

注記

ユーザーグループにメンバーマネージャーを追加してから、更新が Identity Management 環境のすべてのクライアントに広がるまでに時間がかかる場合があります。

検証手順

  • ipa group-show コマンドを使用して、ユーザーおよびグループがメンバーマネージャーとして追加されたことを確認します。

    $ ipa group-show group_a
    Group name: group_a
    GID: 1133400009
    Membership managed by groups: group_admins
    Membership managed by users: test

関連情報

  • 詳細は、ipa group-add-member-manager --help を参照してください。

14.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 インターフェイスには表示されません。

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

IdM CLI を使用してユーザーグループからメンバーを削除するには、次の手順に従います。

前提条件

手順

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

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

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

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

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

14.11. IdM CLI を使用してユーザーまたはグループを IdM ユーザーグループのメンバーマネージャーから取り消す手順

IdM CLI を使用して IdM ユーザーグループのメンバーマネージャーからユーザーまたはグループを削除するには、次の手順に従います。メンバーマネージャーは、IdM ユーザーグループからユーザーまたはグループを削除できますが、グループの属性を変更できません。

前提条件

  • 管理者としてログインしている。詳細は、Using kinit to log in to IdM manually を参照してください。
  • 削除する既存のメンバーマネージャーのユーザーまたはグループの名前と、そのメンバーマネージャーが管理するグループ名が必要です。

手順

  • ipa group-remove-member-manager コマンドを使用してユーザーを IdM ユーザーグループのメンバーマネージャーから削除します。

    たとえば、ユーザー testgroup_a のメンバーマネージャーから削除します。

    $ ipa group-remove-member-manager group_a --users=test
    Group name: group_a
    GID: 1133400009
    Membership managed by groups: group_admins
    ---------------------------
    Number of members removed 1
    ---------------------------

    ユーザー testgroup_a のメンバーを管理できなくなりました。

  • ipa group-remove-member-manager コマンドを使用してグループを IdM ユーザーグループのメンバーマネージャーから削除します。

    たとえば、 グループ group_adminsgroup_a のメンバーマネージャーから削除します。

    $ ipa group-remove-member-manager group_a --groups=group_admins
    Group name: group_a
    GID: 1133400009
    ---------------------------
    Number of members removed 1
    ---------------------------

    グループ group_adminsgroup_a のメンバーを管理できなくなりました。

注記

ユーザーグループからメンバーマネージャーを削除してから、更新が Identity Management 環境のすべてのクライアントに広がるまでに時間がかかる場合があります。

検証手順

  • ipa group-show コマンドを使用して、ユーザーおよびグループがメンバーマネージャーから削除されたことを確認します。

    $ ipa group-show group_a
    Group name: group_a
    GID: 1133400009

関連情報

  • 詳細は、ipa group-remove-member-manager --help を参照してください。

14.12. IdM でのローカルグループとリモートグループのグループマージの有効化

グループは、Identity Management (IdM) や Active Directory (AD) などのドメインによって提供されて一元管理されるか、ローカルシステムの etc/group ファイルで管理されます。ほとんどの場合、ユーザーは一元管理されたストアに依存しています。しかし、ソフトウェアによっては、現在も既知のグループのメンバーシップに基づいてアクセス制御を管理している場合があります。

ドメインコントローラーおよびローカルの etc/group ファイルのグループを管理する場合は、グループのマージを有効にすることができます。ローカルファイルとリモートサービスの両方を確認するように nsswitch.conf ファイルを設定できます。グループが両方に存在する場合、メンバーユーザーのリストが結合され、単一の応答で返されます。

以下の手順では、ユーザー idmuser のグループのマージを有効にする方法について説明します。

手順

  1. /etc/nsswitch.conf ファイルに [SUCCESS=merge] を追加します。

    # Allow initgroups to default to the setting for group.
    initgroups: sss [SUCCESS=merge] files
  2. idmuser を IdM に追加します。

    # ipa user-add idmuser
    First name: idm
    Last name: user
    ---------------------
    Added user "idmuser"
    ---------------------
    User login: idmuser
    First name: idm
    Last name: user
    Full name: idm user
    Display name: idm user
    Initials: tu
    Home directory: /home/idmuser
    GECOS: idm user
    Login shell: /bin/sh
    Principal name: idmuser@IPA.TEST
    Principal alias: idmuser@IPA.TEST
    Email address: idmuser@ipa.test
    UID: 19000024
    GID: 19000024
    Password: False
    Member of groups: ipausers
    Kerberos keys available: False
  3. ローカルの audio グループの GID を確認します。

    $ getent group audio
    ---------------------
    audio:x:63
  4. audio グループを IdM に追加します。

    $ ipa group-add audio --gid 63
    -------------------
    Added group "audio"
    -------------------
    Group name: audio
    GID: 63
    注記

    audio グループを IdM に追加するときに定義する GID は、ローカルの audio グループの GID と同じである必要があります。

  5. idmuser ユーザーを IdM の audio グループに追加します。

    $ ipa group-add-member audio --users=idmuser
    Group name: audio
    GID: 63
    Member users: idmuser
    -------------------------
    Number of members added 1
    -------------------------

検証

  1. idmuser としてログインします。
  2. idmuser のセッションにローカルグループがあることを確認します。

    $ id idmuser
    uid=1867800003(idmuser) gid=1867800003(idmuser) groups=1867800003(idmuser),63(audio),10(wheel)

14.13. Ansible を使用して、IdM クライアントのローカルサウンドカードへのユーザー ID オーバーライドアクセス権を付与する

ansible-freeipa group および idoverrideuser モジュールを使用して、Identity Management (IdM) または Active Directory (AD) ユーザーを IdM クライアント上の audio ローカルグループのメンバーにすることができます。これにより、IdM または AD ユーザーに、ホスト上のサウンドカードへの特権アクセスが付与されます。この手順で使用する例では、最初の Playbook タスクで Default Trust View ID ビューに aduser@addomain.com ID オーバーライドを追加します。次の Playbook タスクで、RHEL ホスト上の audio ローカルグループの GID に対応する GID 63 の audio グループを IdM に作成します。同時に、aduser@addomain.com ID オーバーライドを IdM オーディオグループにメンバーとして追加します。

前提条件

  • 手順の最初の部分を実行する対象である IdM クライアントへの root アクセス権を持っている。この例では、これは client.idm.example.com です。
  • 次の要件を満たすように Ansible コントロールノードを設定している。

    • Ansible バージョン 2.14 以降を使用している。
    • Ansible コントローラーに ansible-freeipa パッケージがインストールされている。
    • RHEL 9.4 以降を使用している。
    • この例では、~/MyPlaybooks/ ディレクトリーに、IdM サーバーの完全修飾