Ansible を使用した Identity Management のインストールおよび管理

Red Hat Enterprise Linux 8

Red Hat Ansible Engine を使用した Red Hat Enterprise Linux 8 での Identity Management のインストール、設定、管理、および維持

概要

本書は、Ansible Playbook を使用して Red Hat Enterprise Linux 8 で Identity Management をインストール、設定、管理、および維持する方法を説明します。

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

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

Identity Management では、以下のような用語の置き換えが含まれます。

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

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

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

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

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

    1. ドキュメントの表示が Multi-page HTML 形式になっていて、ドキュメントの右上端に Feedback ボタンがあることを確認してください。
    2. マウスカーソルで、コメントを追加する部分を強調表示します。
    3. そのテキストの下に表示される Add Feedback ポップアップをクリックします。
    4. 表示される手順に従ってください。
  • より詳細なフィードバックを行う場合は、Bugzilla のチケットを作成します。

    1. Bugzilla の Web サイトにアクセスします。
    2. Component で Documentation を選択します。
    3. Description フィールドに、ドキュメントの改善に関するご意見を記入してください。ドキュメントの該当部分へのリンクも記入してください。
    4. Submit Bug をクリックします。

第1章 Ansible の用語

本書の章では、公式の Ansible 用語を使用します。用語に精通していない場合は、次に進む前に、公式の Ansible アップストリームドキュメント を参照してください。特に、以下のセクションを確認してください。

  • Ansible のセクションの基本概念 は、Ansible で最も一般的に使用される概念の概要を説明します。
  • ユーザーガイド では、コマンドラインの使用、インベントリーでの作業、タスク、プレイ、Playbook の実行など、Ansible の使用時の最も一般的な状況や質問の概要を説明します。
  • インベントリーの構築方法では、インベントリーの設計方法のヒントがあります。インベントリーは、Ansible がインフラストラクチャー内の複数の管理ノードまたはホストに対して機能するために使用する一覧またはリストです。
  • Playbook の紹介 では、Ansible Playbook の概念が導入され、設定の管理、マシンのデプロイ、および複雑なアプリケーションのデプロイメントを行う反復可能なシステムとして Ansible Playbook の概念が導入されています。
  • Ansible ロール セクションでは、既知のファイル構造に基づいて変数、タスク、およびハンドラーの読み込みを自動化する方法を説明します。
  • 「用語 」では、Ansible ドキュメントの他の用語が使用されています。

第2章 Ansible Playbook で Identity Management サーバーのインストール

2.1. Ansible と、IdM をインストールする利点

Ansible は、システムの設定、ソフトウェアのデプロイ、ローリング更新の実行に使用する自動化ツールです。Ansible には Identity Management (IdM) のサポートが含まれるため、Ansible モジュールを使用して、IdM サーバー、レプリカ、クライアント、または IdM トポロジー全体の設定などのインストールタスクを自動化できます。

IdM のインストールに Ansible を使用する利点

以下の一覧は、手動インストールとは対照的に、Ansible を使用して Identity Management をインストールする利点を示しています。

  • 管理ノードにログインする必要はありません。
  • デプロイする各ホストに個別に設定する必要はありません。代わりに、完全なクラスターをデプロイするためのインベントリーファイルを 1 つ使用できます。
  • ユーザーおよびホストを追加するなど、後で管理タスクにインベントリーファイルを再利用できます。IdM には関係のないタスクであっても、インベントリーファイルを再利用できます。

2.2. Ansible Playbook で IdM サーバーのインストール

以下のセクションでは、Ansible を使用してシステムを IdM サーバーとして設定する方法を説明します。システムを IdM サーバーとして設定すると、IdM ドメインを確立し、システムが IdM クライアントに IdM サービスを提供できるようになります。デプロイメントは、Ansible ロール ipaserver により管理されます。

注記

Ansible を使用して IdM サーバーをインストールする前に、Ansible と IdM の概念を理解するようにしてください。本章で使用されている以下の用語を理解します。

  • Ansible ロール
  • Ansible ノード
  • Ansible インベントリー
  • Ansible タスク
  • Ansible モジュール
  • Ansible プレイおよび Playbook

概要

インストールは、以下の手順で構成されます。

2.3. ansible-freeipa パッケージのインストール

前提条件

管理対象ノード で以下を行っている。

  • 管理ノードが、静的 IP アドレスと作業パッケージマネージャーを備えた Red Hat Enterprise Linux 8 システムである。

コントローラー で以下を行っている。

  • コントローラーが、有効なサブスクリプションを備えた Red Hat Enterprise Linux システムである。そうでない場合は、公式の Ansible ドキュメントの『Installation guide』で、代替のインストール方法を参照してください。
  • コントローラーから、SSH プロトコルで管理ノードに到達できる。管理ノードが、コントローラーの /root/.ssh/known_hosts ファイルの一覧に記載されていることを確認します。

手順

Ansible コントローラーで以下の手順を実行します。

  1. 必要なリポジトリーを有効にします。

    # subscription-manager repos --enable ansible-2.8-for-rhel-8-x86_64-rpms
  2. Ansible をインストールします。

    # yum install ansible
  3. IdM Ansible ロールをインストールします。

    # yum install ansible-freeipa

    ロールが /usr/share/ansible/roles/ ディレクトリーにインストールされます。

2.4. ファイルシステム内の Ansible ロールの場所

デフォルトでは、ansible-freeipa ロールは /usr/share/ansible/roles/ ディレクトリーにインストールされます。ansible-freeipa パッケージの構造は以下のとおりです。

  • /usr/share/ansible/roles/ ディレクトリーには、Ansible コントローラーの ipaserver ロール、ipareplica ロール、および ipaclient ロールが保存されています。各ロールディレクトリーには、サンプル、基本的な概要、ライセンス、および Markdown ファイルの README.md のロールに関する情報が保存されています。

    [root@server]# ls -1 /usr/share/ansible/roles/
    ipaclient
    ipareplica
    ipaserver
  • /usr/share/doc/ansible-freeipa/ ディレクトリーには、Markdown ファイルの README.md に、各ロールおよびトポロジーに関する情報が保存されています。また、playbooks/ サブディレクトリーも保存されています (以下を参照)。

    [root@server]# ls -1 /usr/share/doc/ansible-freeipa/
    playbooks
    README-client.md
    README.md
    README-replica.md
    README-server.md
    README-topology.md
  • /usr/share/doc/ansible-freeipa/playbooks/ ディレクトリーは、Playbook のサンプルを保存します。

    [root@server]# ls -1 /usr/share/doc/ansible-freeipa/playbooks/
    install-client.yml
    install-cluster.yml
    install-replica.yml
    install-server.yml
    uninstall-client.yml
    uninstall-cluster.yml
    uninstall-replica.yml
    uninstall-server.yml

2.5. Ansible Playbook を使用して、統合 CA を root CA として備えた IdM サーバーをデプロイメント

2.5.1. 統合 CA を root CA として備えたデプロイメント向けにパラメーターの設定

以下の手順に従って、統合 CA を root CA として備えた IdMサーバーをインストールするためのインベントリーファイルを設定します。

手順

  1. 編集するインベントリーファイルを開きます。IdM サーバーとして使用するホストの完全修飾ドメイン名 (FQDN) を指定します。FQDN が以下の基準を満たしていることを確認してください。

    • 英数字およびハイフン (-) のみが使用できる。たとえば、アンダーラインは使用できないため、DNS の障害が発生する原因となる可能性があります。
    • ホスト名がすべて小文字である。
  2. IdM ドメインおよびレルムの情報を指定します。
  3. IdM サーバーに統合 DNS を使用するかどうか、および /etc/resolv.conf ファイルからフォワーダーを使用するかどうかを指定します。
  4. adminDirectory Manager のパスワードを指定します。Ansible Vault を使用してパスワードを保存し、Playbook ファイルから Vault ファイルを参照します。あるいは、安全性は低くなりますが、インベントリーファイルにパスワードを直接指定します。
  5. (オプション)IdM サーバーが使用するカスタム firewalld ゾーンを指定します。カスタムゾーンを設定しない場合、IdM はサービスをデフォルトの firewalld ゾーンに追加します。事前定義されたデフォルトゾーンは public です。

    重要

    指定した firewalld ゾーンが存在し、永続的である。

    必要なサーバー情報を含むインベントリーファイルの例 (パスワードを除く)

    [ipaserver]
    server.idm.example.com
    
    [ipaserver:vars]
    ipaserver_domain=idm.example.com
    ipaserver_realm=IDM.EXAMPLE.COM
    ipaserver_setup_dns=yes
    ipaserver_auto_forwarders=yes
    [...]

    必要なサーバー情報を含むインベントリーファイルの例 (パスワードを含む)

    [ipaserver]
    server.idm.example.com
    
    [ipaserver:vars]
    ipaserver_domain=idm.example.com
    ipaserver_realm=IDM.EXAMPLE.COM
    ipaserver_setup_dns=yes
    ipaserver_auto_forwarders=yes
    ipaadmin_password=MySecretPassword123
    ipadm_password=MySecretPassword234
    
    [...]

    カスタム firewalld ゾーンを含むインベントリーファイルの例

    [ipaserver]
    server.idm.example.com
    
    [ipaserver:vars]
    ipaserver_domain=idm.example.com
    ipaserver_realm=IDM.EXAMPLE.COM
    ipaserver_setup_dns=yes
    ipaserver_auto_forwarders=yes
    ipaadmin_password=MySecretPassword123
    ipadm_password=MySecretPassword234
    ipaserver_firewalld_zone=custom zone

    Ansible Vault ファイルに保存された admin パスワードおよび Directory Manager パスワードを使用して IdM サーバーを設定する Playbook の例

    ---
    - name: Playbook to configure IPA server
      hosts: ipaserver
      become: true
      vars_files:
      - playbook_sensitive_data.yml
    
      roles:
      - role: ipaserver
        state: present

    インベントリーファイルの admin パスワードおよび Directory Manager パスワードを使用して IdM サーバーを設定する Playbook の例

    ---
    - name: Playbook to configure IPA server
      hosts: ipaserver
      become: true
    
      roles:
      - role: ipaserver
        state: present

IdM サーバーのインストールと利用可能なオプションの詳細は、https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html-single/installing_identity_management/index#installing-idm を参照してください。

2.5.2. Ansible Playbook を使用して、統合 CA を root CA として備えた IdM サーバーをデプロイメント

以下の手順に従って、Ansible Playbook を使用して、統合された認証局 (CA) を備えた IdM サーバーをデプロイします。

手順

  • ansible-playbook コマンドを、Playbook ファイルの名前 (install-server.yml など) で実行します。-i オプションでインベントリーファイルを指定します。

    $ ansible-playbook -v -i <path_to_inventory_directory>/hosts <path_to_playbooks_directory>/install-server.yml

    -v オプション、-vv オプション、または -vvv オプションを使用して、詳細のレベルを指定します。

    コマンドラインインターフェース (CLI) で Ansible Playbook スクリプトの出力を表示できます。次の出力は、失敗したタスクが 0 個のため、スクリプトが正常に実行されたことを示しています。

    PLAY RECAP
    server.idm.example.com : ok=18   changed=10   unreachable=0    failed=0    skipped=21   rescued=0    ignored=0

Ansible Playbook を使用して、ホストに IdM サーバーをインストールしました。

2.6. Ansible Playbook を使用して、外部 CA を root CA として備えた IdM サーバーのデプロイメント

2.6.1. 外部 CA を root CA として備えたデプロイメントのパラメーターの設定

以下の手順に従って、外部 CA を root CA を備えた IdM サーバーをインストールするためのインベントリーファイルを設定します。

手順

  1. 編集するインベントリーファイルを開きます。IdM サーバーとして使用するホストの完全修飾ドメイン名 (FQDN) を指定します。FQDN が以下の基準を満たしていることを確認してください。

    • 英数字およびハイフン (-) のみが使用できる。たとえば、アンダーラインは使用できないため、DNS の障害が発生する原因となる可能性があります。
    • ホスト名がすべて小文字である。
  2. IdM ドメインおよびレルムの情報を指定します。
  3. IdM サーバーに統合 DNS を使用するかどうか、および /etc/resolv.conf ファイルからフォワーダーを使用するかどうかを指定します。
  4. adminDirectory Manager のパスワードを指定します。Ansible Vault を使用してパスワードを保存し、Playbook ファイルから Vault ファイルを参照します。あるいは、安全性は低くなりますが、インベントリーファイルにパスワードを直接指定します。
  5. (オプション)IdM サーバーが使用するカスタム firewalld ゾーンを指定します。カスタムゾーンを設定しない場合、IdM はサービスをデフォルトの firewalld ゾーンに追加します。事前定義されたデフォルトゾーンは public です。

    重要

    指定した firewalld ゾーンが存在し、永続的である。

    必要なサーバー情報を含むインベントリーファイルの例 (パスワードを除く)

    [ipaserver]
    server.idm.example.com
    
    [ipaserver:vars]
    ipaserver_domain=idm.example.com
    ipaserver_realm=IDM.EXAMPLE.COM
    ipaserver_setup_dns=yes
    ipaserver_auto_forwarders=yes
    [...]

    必要なサーバー情報を含むインベントリーファイルの例 (パスワードを含む)

    [ipaserver]
    server.idm.example.com
    
    [ipaserver:vars]
    ipaserver_domain=idm.example.com
    ipaserver_realm=IDM.EXAMPLE.COM
    ipaserver_setup_dns=yes
    ipaserver_auto_forwarders=yes
    ipaadmin_password=MySecretPassword123
    ipadm_password=MySecretPassword234
    
    [...]

    カスタム firewalld ゾーンを含むインベントリーファイルの例

    [ipaserver]
    server.idm.example.com
    
    [ipaserver:vars]
    ipaserver_domain=idm.example.com
    ipaserver_realm=IDM.EXAMPLE.COM
    ipaserver_setup_dns=yes
    ipaserver_auto_forwarders=yes
    ipaadmin_password=MySecretPassword123
    ipadm_password=MySecretPassword234
    ipaserver_firewalld_zone=custom zone
    
    [...]

  6. インストールの最初ステップ用の Playbook を作成します。証明書署名要求 (CSR) を生成し、それをコントローラーから管理対象ノードにコピーする指示を入力します。

    ---
    - name: Playbook to configure IPA server Step 1
      hosts: ipaserver
      become: true
      vars_files:
      - playbook_sensitive_data.yml
      vars:
        ipaserver_external_ca: yes
    
      roles:
      - role: ipaserver
        state: present
    
      post_tasks:
      - name: Copy CSR /root/ipa.csr from node to "{{ groups.ipaserver[0] + '-ipa.csr' }}"
        fetch:
          src: /root/ipa.csr
          dest: "{{ groups.ipaserver[0] + '-ipa.csr' }}"
          flat: yes
  7. インストールの最終ステップ用に、別の Playbook を作成します。

    ---
    - name: Playbook to configure IPA server Step -1
      hosts: ipaserver
      become: true
      vars_files:
      - playbook_sensitive_data.yml
      vars:
        ipaserver_external_cert_files: "/root/chain.crt"
    
      pre_tasks:
      - name: Copy "{{ groups.ipaserver[0] + '-chain.crt' }}" to /root/chain.crt on node
        copy:
          src: "{{ groups.ipaserver[0] + '-chain.crt' }}"
          dest: "/root/chain.crt"
          force: yes
    
      roles:
      - role: ipaserver
        state: present

外部署名 CA を備えた IdM サーバーをインストールする際に利用できるオプションの詳細は、https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html-single/installing_identity_management/index#installing-an-ipa-server-with-external-ca_installing-identity-management を参照してください。

2.6.2. Ansible Playbook を使用して、外部 CA を root CA として備えた IdM サーバーのデプロイメント

以下の手順に従って、Ansible Playbook を使用して、外部認証局 (CA) を備えた IdM サーバーをデプロイします。

手順

  1. ansible-playbook コマンドに、インストールの最初ステップの指示を含む Playbook ファイルの名前 (install-server-step1.yml など) を指定して実行します。-i オプションでインベントリーファイルを指定します。

    $ ansible-playbook -v -i <path_to_inventory_directory>/host.server <path_to_playbooks_directory>/install-server-step1.yml

    -v オプション、-vv オプション、または -vvv オプションを使用して、詳細のレベルを指定します。

    コマンドラインインターフェース (CLI) で Ansible Playbook スクリプトの出力を表示できます。次の出力は、失敗したタスクが 0 個のため、スクリプトが正常に実行されたことを示しています。

    PLAY RECAP
    server.idm.example.com : ok=18   changed=10   unreachable=0    failed=0    skipped=21   rescued=0    ignored=0
  2. コントローラー上の ipa.csr 証明書署名要求ファイルを見つけ、これを外部 CA に送信します。
  3. 外部 CA が署名した IdM CA 証明書をコントローラーファイルシステムに配置して、次のステップの Playbook で見つけられるようにします。
  4. ansible-playbook コマンドに、インストールの最終ステップの指示を含む Playbook ファイルの名前 (install-server-step2.yml など) を指定して実行します。-i オプションでインベントリーファイルを指定します。

    $ ansible-playbook -v -i <path_to_inventory_directory>/host.server <path_to_playbooks_directory>/install-server-step2.yml

Ansible Playbook を使用して、外部署名 CA で IdM サーバーをホストにインストールしている。

第3章 Ansible Playbook で Identity Management レプリカのインストール

3.1. Ansible Playbook で IdM レプリカのインストール

以下のセクションでは、Ansible を使用してシステムを IdM レプリカとして設定する方法を説明します。システムを IdM レプリカとして設定すると、IdM ドメインに登録され、ドメインの IdM サーバーにある IdM サービスをシステムが使用できるようになります。

デプロイメントは、Ansible ロール ipareplica で管理されます。このロールは、自動検出モードを使用して、IdM サーバー、ドメイン、およびその他の設定を識別できます。ただし、複数のレプリカを階層のようなモデルでデプロイし、そのレプリカのグループを異なるタイミングでデプロイする場合には、グループごとに特定のサーバーまたはレプリカを定義する必要があります。

注記

Ansible を使用して IdM レプリカをインストールする前に、Ansible と IdM の概念を理解しているようにしてください。本章で使用されている以下の用語を理解します。

  • Ansible ロール
  • Ansible ノード
  • Ansible インベントリー
  • Ansible タスク
  • Ansible モジュール
  • Ansible プレイおよび Playbook

概要

インストールは、以下の手順で構成されます。

前提条件

  • Ansible コントロールノードに ansible-freeipa パッケージがインストールされている。

3.2. IdM レプリカデプロイメントのパラメーターの設定

ターゲットホストを IdM レプリカとしてデプロイする前に、以下の設定を構成します。

3.2.1. IdM レプリカをインストールするためのベース変数、サーバー変数、およびクライアント変数の指定

IdM レプリカをインストールするためのインベントリーファイルを設定するには、以下の手順を完了します。

手順

  1. 編集するインベントリーファイルを開きます。IdM レプリカとなるホストの完全修飾ドメイン名 (FQDN) を指定します。FQDN は有効な DNS 名である必要があります。

    • 数字、アルファベット、およびハイフンのみを使用できる。たとえば、アンダーラインは使用できないため、DNS の障害が発生する原因となる可能性があります。
    • ホスト名がすべて小文字である。

      レプリカの FQDN のみが定義されている単純なインベントリーホストファイルの例

      [ipareplicas]
      replica1.idm.example.com
      replica2.idm.example.com
      replica3.idm.example.com
      [...]

      IdM サーバーがデプロイされており、SRV レコードが IdM DNS ゾーンに適切に設定されている場合、スクリプトはその他に必要な値をすべて自動的に検出します。

  2. 必要に応じて、以下のシナリオの中から最も近いものを選んで、インベントリーファイルに追加情報を提供します。

    • シナリオ 1

      自動検出を回避し、[ipareplicas] セクションに記載されているすべてのレプリカが特定の IdM サーバーを使用するようにするには、インベントリーファイルの [ipaservers] セクションにそのサーバーを設定します。

      IdM サーバーとレプリカの FQDN が定義されているインベントリーホストファイルの例

      [ipaservers]
      server.idm.example.com
      
      [ipareplicas]
      replica1.idm.example.com
      replica2.idm.example.com
      replica3.idm.example.com
      [...]

    • シナリオ 2

      または、自動検出を回避して、特定のサーバーで特定のレプリカをデプロイする場合は、インベントリーファイルの [ipareplicas] セクションに、特定のレプリカのサーバーを個別に設定します。

      特定のレプリカ用に特定の IdM サーバーが定義されたインベントリーファイルの例

      [ipaservers]
      server.idm.example.com
      replica1.idm.example.com
      
      [ipareplicas]
      replica2.idm.example.com
      replica3.idm.example.com ipareplica_servers=replica1.idm.example.com

      上記の例では、replica3.idm.example.com が、すでにデプロイされた replica1.idm.example.com を複製元として使用します。

    • シナリオ 3

      1 つのバッチに複数のレプリカをデプロイする場合は、多層レプリカのデプロイメントが役に立ちます。インベントリーファイルにレプリカの特定グループ (例: [ipareplicas_tier1] および [ipareplicas_tier2]) を定義し、Playbook install-replica.yml で各グループに個別のプレイを設計します。

      レプリカ階層が定義されているインベントリーファイルの例

      [ipaservers]
      server.idm.example.com
      
      [ipareplicas_tier1]
      replica1.idm.example.com
      
      [ipareplicas_tier2]
      replica2.idm.example.com \ ipareplica_servers=replica1.idm.example.com,server.idm.example.com

      ipareplica_servers の最初のエントリーが使用されます。次のエントリーは、フォールバックオプションとして使用されます。IdM レプリカのデプロイに複数の層を使用する場合は、最初に tier1 からレプリカをデプロイし、次に tier2 からレプリカをデプロイするように、Playbook に個別のタスクが必要です。

      レプリカグループごとに異なるプレイを定義した Playbook ファイルの例

      ---
      - name: Playbook to configure IPA replicas (tier1)
        hosts: ipareplicas_tier1
        become: true
      
        roles:
        - role: ipareplica
          state: present
      
      - name: Playbook to configure IPA replicas (tier2)
        hosts: ipareplicas_tier2
        become: true
      
        roles:
        - role: ipareplica
          state: present

    • シナリオ 4

      レプリカがデフォルトの firewalld ゾーンではなく、指定した firewalld ゾーンを使用する場合は、インベントリーファイルで指定できます。これは、たとえば、デフォルトとして設定されたパブリックゾーンの代わりに、IdM インストールに内部 firewalld ゾーンを使用する場合に便利です。

      カスタムゾーンを設定しない場合、IdM はサービスをデフォルトの firewalld ゾーンに追加します。事前定義されたデフォルトゾーンは public です。

      重要

      指定した firewalld ゾーンが存在し、永続的である。

      カスタム firewalld ゾーンを使用した単純なインベントリーホストファイルの例

      [ipaservers]
      server.idm.example.com
      
      [ipareplicas]
      replica1.idm.example.com
      replica2.idm.example.com
      replica3.idm.example.com
      [...]
      
      [ipareplicas:vars]
      ipareplica_firewalld_zone=custom zone

3.2.2. Ansible Playbook を使用して IdM レプリカをインストールするための認証情報の指定

この手順は、IdM レプリカのインストールに認可を設定します。

手順

  1. レプリカをデプロイする権限のあるユーザーのパスワード (IdM の admin など) を指定します。

    • Red Hat は、Ansible Vault を使用してパスワードを保存し、Playbook ファイルから Vault ファイルを参照する (install-replica.yml など) ことを推奨します。

      Ansible Vault ファイルのインベントリーファイルおよびパスワードのプリンシパルを使用した Playbook ファイルの例

      - name: Playbook to configure IPA replicas
        hosts: ipareplicas
        become: true
        vars_files:
        - playbook_sensitive_data.yml
      
        roles:
        - role: ipareplica
          state: present

      Ansible Vault の使用方法は、公式の Ansible Vault ドキュメントを参照してください。

    • あまり安全ではありませんが、インベントリーファイルで admin の認証情報を直接提供します。インベントリーファイルの [ipareplicas:vars] セクションで ipaadmin_password オプションを使用します。インベントリーファイルと、Playbook ファイル install-replica.yml は以下のようになります。

      インベントリーの hosts.replica ファイルの例

      [...]
      [ipareplicas:vars]
      ipaadmin_password=Secret123

      インベントリーファイルのプリンシパルおよびパスワードを使用した Playbook の例

      - name: Playbook to configure IPA replicas
        hosts: ipareplicas
        become: true
      
        roles:
        - role: ipareplica
          state: present

    • または、安全性は低くなりますが、レプリカをインベントリーファイルに直接デプロイすることを許可されている別のユーザーの資格情報を提供します。別の認証ユーザーを指定するには、ユーザー名に ipaadmin_principal オプションを使用し、パスワードに ipaadmin_password オプションを使用します。インベントリーファイルと、Playbook ファイル install-replica.yml は以下のようになります。

      インベントリーの hosts.replica ファイルの例

      [...]
      [ipareplicas:vars]
      ipaadmin_principal=my_admin
      ipaadmin_password=my_admin_secret123

      インベントリーファイルのプリンシパルおよびパスワードを使用した Playbook の例

      - name: Playbook to configure IPA replicas
        hosts: ipareplicas
        become: true
      
        roles:
        - role: ipareplica
          state: present

関連情報

  • Ansible ロール ipareplica で使用できるオプションの詳細は、Markdown ファイル /usr/share/ansible/roles/ipareplica/README.md を参照してください。

3.3. Ansible Playbook で IdM レプリカのデプロイメント

以下の手順に従って、Ansible Playbook を使用して IdM レプリカをデプロイします。

手順

  • Ansible Playbook を使用して IdM レプリカをインストールするには、ansible-playbook コマンドに Playbook ファイルの名前 (install-replica.yml など) を使用します。-i オプションでインベントリーファイルを指定します。

    $ ansible-playbook -v -i <path_to_inventory_directory>/hosts.replica <path_to_playbooks_directory>/install-replica.yml

    -v オプション、-vv オプション、または -vvv オプションを使用して、詳細のレベルを指定します。

    Ansible には、Ansible Playbook スクリプトの実行が通知されます。次の出力は、失敗したタスクが 0 個のため、スクリプトが正常に実行されたことを示しています。

    PLAY RECAP
    replica.idm.example.com : ok=18   changed=10   unreachable=0    failed=0    skipped=21   rescued=0    ignored=0

これで、IdM レプリカがインストールされました。

第4章 Ansible Playbook で Identity Management クライアントのインストール

4.1. Ansible Playbook で IdM クライアントのインストール

ここでは、Ansible を使用して、システムを Identity Management (IdM) クライアントとして設定する方法を説明します。システムを IdM クライアントとして設定すると、IdM ドメインに登録され、システムがドメインの IdM サーバーで IdM サービスを使用できるようになります。

デプロイメントは、Ansible ロール ipaclient により管理されます。デフォルトでは、ロールは自動検出モードを使用して、IdM サーバー、ドメイン、およびその他の設定を特定します。ロールは、Ansible Playbook がインベントリーファイルなどに指定した設定を使用するように変更できます。

注記

Ansible を使用して IdM クライアントをインストールする前に、Ansible と IdM の概念を理解しているようにしてください。本章で使用されている以下の用語を理解します。

  • Ansible ロール
  • Ansible ノード
  • Ansible インベントリー
  • Ansible タスク
  • Ansible モジュール
  • Ansible プレイおよび Playbook

概要

インストールは、以下の手順で構成されます。

本章では、「IdM クライアントのアンインストール方法」を説明します。

前提条件

  • Ansible コントロールノードに ansible-freeipa パッケージがインストールされている。

4.2. IdM クライアントデプロイメントのパラメーターの設定

ターゲットホストを IdM クライアントとしてデプロイする前に、コントロールノードで デプロイメント手順 を設定します。さらに、計画している以下のオプションに応じて、ターゲットホストパラメーターを設定します。

4.2.1. 自動検出クライアントインストールモードでインベントリーファイルのパラメーターの設定

Ansible Playbook を使用して Identity Management クライアントをインストールするには、インベントリーファイル (inventory/hosts など) に以下の情報を指定します。

  • ホストに関する情報
  • タスクの認可

インベントリーファイルは、所有するインベントリープラグインに応じて、多数ある形式のいずれかになります。INI-like 形式は Ansible のデフォルトで、以下の例で使用されています。

注記

RHEL のグラフィカルユーザーインターフェースでスマートカードを使用するには、Ansible Playbook に ipaclient_mkhomedir 変数を追加するようにしてください。

手順

  1. IdM クライアントになるホストの完全修飾ホスト名 (FQDN) を指定します。完全修飾ドメイン名は、有効な DNS 名である必要があります。

    • 数字、アルファベット、およびハイフンのみを使用できる。たとえば、アンダーラインは使用できないため、DNS の障害が発生する原因となる可能性があります。
    • ホスト名がすべて小文字である。大文字は使用できません。

      SRV レコードが IdM DNS ゾーンで正しく設定されている場合は、スクリプトが自動的に必要な値をすべて検出します。

    クライアントの FQDN のみが定義されている単純なインベントリーホストファイルの例

    [ipaclients]
    client.idm.example.com
    [...]

  2. クライアントを登録するための認証情報を指定します。以下の認証方法を使用できます。

    • クライアントを登録する権限のあるユーザーのパスワード。以下はデフォルトのオプションになります。

      • Red Hat は、Ansible Vault を使用してパスワードを保存し、Playbook ファイル (install-client.yml など) から Vault ファイルを直接参照することを推奨します。

        Ansible Vault ファイルのインベントリーファイルおよびパスワードのプリンシパルを使用した Playbook ファイルの例

        - name: Playbook to configure IPA clients with username/password
          hosts: ipaclients
          become: true
          vars_files:
          - playbook_sensitive_data.yml
        
          roles:
          - role: ipaclient
            state: present

      • あまり安全ではありませんが、inventory/hosts ファイルの [ipaclients:vars] セクションに ipaadmin_password オプションを使用して、admin の認証情報を提供します。また、別の認証ユーザーを指定するには、ユーザー名に ipaadmin_principal オプション、パスワードに ipaadmin_password オプションを使用します。inventory/hosts インベントリーファイルと、Playbook ファイル install-client.yml は以下のようになります。

        インベントリーホストファイルの例

        [...]
        [ipaclients:vars]
        ipaadmin_principal=my_admin
        ipaadmin_password=Secret123

        インベントリーファイルのプリンシパルおよびパスワードを使用した Playbook の例

        - name: Playbook to unconfigure IPA clients
          hosts: ipaclients
          become: true
        
          roles:
          - role: ipaclient
            state: true

    • 以前登録した クライアントキータブ が利用できる場合は、以下を行います。

      • このオプションは、システムが Identity Management クライアントとして登録されたことがある場合に使用できます。この認証方法を使用するには、#ipaclient_keytab オプションのコメントを解除して、キータブを保存するファイルへのパスを指定します (例: inventory/hosts[ipaclient:vars] セクション)。
    • 登録時に生成される ランダムなワンタイムパスワード (OTP)。この認証方法を使用するには、インベントリーファイルの ipaclient_use_otp=yes オプションを使用します。たとえば、inventory/hosts ファイルの [ipaclients:vars] セクションで ipaclient_use_otp=yes オプションのコメントを解除できます。OTP では、以下のいずれかのオプションも指定する必要があります。

      • クライアントを登録する権限のあるユーザーのパスワード (例: inventory/hosts ファイルの [ipaclients:vars] セクションに ipaadmin_password の値を指定)。
      • 管理者キータブ (例: inventory/hosts[ipaclients:vars] セクションに ipaadmin_keytab の値を指定)。

関連情報

  • Ansible ロール ipaclient で使用できるオプションの詳細は、README ファイル /usr/share/ansible/roles/ipaclient/README.md を参照してください。

4.2.2. クライアントのインストール時に自動検出ができない場合に備えてインベントリーファイルのパラメーターの設定

Ansible Playbook を使用して Identity Management クライアントをインストールするには、インベントリーファイル (inventory/hosts など) に以下の情報を指定します。

  • ホストと、IdM サーバーおよび IdM ドメインまたは IdM レルムに関する情報
  • タスクの認可

インベントリーファイルは、所有するインベントリープラグインに応じて、多数ある形式のいずれかになります。INI-like 形式は Ansible のデフォルトで、以下の例で使用されています。

注記

RHEL のグラフィカルユーザーインターフェースでスマートカードを使用するには、Ansible Playbook に ipaclient_mkhomedir 変数を追加するようにしてください。

手順

  1. IdM クライアントになるホストの完全修飾ホスト名 (FQDN) を指定します。完全修飾ドメイン名は、有効な DNS 名である必要があります。

    • 数字、アルファベット、およびハイフンのみを使用できる。たとえば、アンダーラインは使用できないため、DNS の障害が発生する原因となる可能性があります。
    • ホスト名がすべて小文字である。大文字は使用できません。
  2. inventory/hosts ファイルの関連セクションに、他のオプションを指定します。

    • [ipaservers] セクションのサーバーの FQDN は、クライアントが登録される IdM サーバーを示します。
    • 以下のいずれかのオプションを使用できます。

      • クライアントが登録される IdM サーバーの DNS ドメイン名を指定する [ipaclients:vars] セクションの ipaclient_domain オプション
      • IdM サーバーが制御する Kerberos レルムの名前を示す [ipaclients:vars] セクションの ipaclient_realm オプション

        クライアント FQDN、サーバーの FQDN、およびドメインが定義されているインベントリーホストファイルの例

        [ipaclients]
        client.idm.example.com
        
        [ipaservers]
        server.idm.example.com
        
        [ipaclients:vars]
        ipaclient_domain=idm.example.com
        [...]

  3. クライアントを登録するための認証情報を指定します。以下の認証方法を使用できます。

    • クライアントを登録する権限のあるユーザーのパスワード。以下はデフォルトのオプションになります。

      • Red Hat は、Ansible Vault を使用してパスワードを保存し、Playbook ファイル (install-client.yml など) から Vault ファイルを直接参照することを推奨します。

        Ansible Vault ファイルのインベントリーファイルおよびパスワードのプリンシパルを使用した Playbook ファイルの例

        - name: Playbook to configure IPA clients with username/password
          hosts: ipaclients
          become: true
          vars_files:
          - playbook_sensitive_data.yml
        
          roles:
          - role: ipaclient
            state: present

      • あまり安全ではありませんが、inventory/hosts ファイルの [ipaclients:vars] セクションに ipaadmin_password オプションを使用して、admin の認証情報を提供します。また、別の認証ユーザーを指定するには、ユーザー名に ipaadmin_principal オプション、パスワードに ipaadmin_password オプションを使用します。これにより、Playbook ファイル install-client.yml は、以下のようになります。

        インベントリーホストファイルの例

        [...]
        [ipaclients:vars]
        ipaadmin_principal=my_admin
        ipaadmin_password=Secret123

        インベントリーファイルのプリンシパルおよびパスワードを使用した Playbook の例

        - name: Playbook to unconfigure IPA clients
          hosts: ipaclients
          become: true
        
          roles:
          - role: ipaclient
            state: true

    • 以前登録した クライアントキータブ が利用できる場合は、以下を行います。

      • このオプションは、システムが Identity Management クライアントとして登録されたことがある場合に使用できます。この認証方法を使用するには、ipaclient_keytab オプションをコメント解除します。たとえば、inventory/hosts[ipaclient:vars] セクションにあるように、キータブを格納しているファイルへのパスを指定します。
    • 登録時に生成される ランダムなワンタイムパスワード (OTP)。この認証方法を使用するには、インベントリーファイルの ipaclient_use_otp=yes オプションを使用します。たとえば、inventory/hosts ファイルの [ipaclients:vars] セクションで、#ipaclient_use_otp=yes オプションをコメント解除できます。OTP では、以下のいずれかのオプションも指定する必要があります。

      • クライアントを登録する権限のあるユーザーのパスワード (例: inventory/hosts ファイルの [ipaclients:vars] セクションに ipaadmin_password の値を指定)。
      • 管理者キータブ (例: inventory/hosts[ipaclients:vars] セクションに ipaadmin_keytab の値を指定)。

関連情報

  • Ansible ロール ipaclient で使用できるオプションの詳細は、README ファイル /usr/share/ansible/roles/ipaclient/README.md を参照してください。

4.2.3. install-client.yml ファイルのパラメーターの確認

Playbook ファイル install-client.yml には、IdM クライアントのデプロイメント手順が含まれています。

  • ファイルを開き、Playbook の命令がデプロイメントのプランニング内容に対応するかどうかを確認します。通常、内容は以下のようになります。

    ---
    - name: Playbook to configure IPA clients with username/password
      hosts: ipaclients
      become: true
    
      roles:
      - role: ipaclient
        state: present

    以下は、個々のエントリーが意味するものです。

    • hosts エントリーは、ipa-client-install スクリプトを実行するホストの FQDNs を ansaibleスクリプトが検索する inventory/hosts のセクションを指定します。
    • become: true エントリーは、ipa-client-install スクリプトの実行時に root の認証情報が呼び出されるように指定します。
    • role: ipaclient エントリーは、ホストにインストールされるロールを指定します。この場合は ipa クライアントロールになります。
    • state: present エントリーは、アンインストール (absent) ではなくクライアントをインストールするように指定します。

4.2.4. Ansible Playbook で IdM クライアント登録の認可オプション

この参照セクションでは、インベントリーおよび Playbook の例とともに、IdM クライアント登録の個々の認可オプションを示します。

表4.1 Ansible で IdM クライアント登録の認可オプション

認可オプション備考インベントリーファイルの例Playbook ファイル install-client.yml の例

クライアントを登録する権限のあるユーザーのパスワード - オプション 1

Ansible vault に保存されているパスワード

[ipaclients:vars]
[...]
- name: Playbook to configure IPA clients with username/password
  hosts: ipaclients
  become: true
  vars_files:
  - playbook_sensitive_data.yml

  roles:
  - role: ipaclient
    state: present

クライアントを登録する権限のあるユーザーのパスワード - オプション 2

インタベントリーファイルに格納されるパスワード

[ipaclients:vars]
ipaadmin_password=Secret123
- name: Playbook to configure IPA clients
  hosts: ipaclients
  become: true

  roles:
  - role: ipaclient
    state: true

ランダムなワンタイムパスワード (OTP) - オプション 1

OTP および管理者パスワード

[ipaclients:vars]
ipaadmin_password=Secret123
ipaclient_use_otp=yes
- name: Playbook to configure IPA clients
  hosts: ipaclients
  become: true

  roles:
  - role: ipaclient
    state: true

ランダムなワンタイムパスワード (OTP) - オプション 2

OTP および管理者キータブ

[ipaclients:vars]
ipaadmin_keytab=/tmp/admin.keytab
ipaclient_use_otp=yes
- name: Playbook to configure IPA clients
  hosts: ipaclients
  become: true

  roles:
  - role: ipaclient
    state: true

前回登録時のクライアントキータブ

 
[ipaclients:vars]
ipaclient_keytab=/tmp/krb5.keytab
- name: Playbook to configure IPA clients
  hosts: ipaclients
  become: true

  roles:
  - role: ipaclient
    state: true

4.3. Ansible Playbook で IdM クライアントのデプロイメント

Ansible Playbook を使用して IdM 環境に IdM クライアントをデプロイするには、この手順を完了します。

手順

  • Ansible Playbook を使用して IdM クライアントをインストールする場合は、ansible-playbook コマンドに Playbook ファイルの名前 (install-client.yml など) を指定します。-i オプションでインベントリーファイルを指定します。

    $ ansible-playbook -v -i inventory/hosts install-client.yml

    -v オプション、-vv オプション、または -vvv オプションを使用して、詳細のレベルを指定します。

    Ansible には、Ansible Playbook スクリプトの実行が通知されます。次の出力は、失敗したタスクがないため、スクリプトが正常に実行されたことを示しています。

    PLAY RECAP
    client1.idm.example.com : ok=18 changed=10 unreachable=0 failed=0 skipped=21 rescued=0 ignored=0
    注記

    Ansible は、さまざまな色を使用して、実行中のプロセスに関するさまざまな情報を提供します。/etc/ansible/ansible.cfg ファイルの [colors] セクションで、デフォルトの色を変更できます。

    [colors]
    [...]
    #error = red
    #debug = dark gray
    #deprecate = purple
    #skip = cyan
    #unreachable = red
    #ok = green
    #changed = yellow
    [...]

Ansible Playbook を使用して、ホストに IdM クライアントをインストールしました。

4.4. Ansible インストール後の Identity Management クライアントのテスト

コマンドラインインターフェース (CLI) により、ansible-playbook コマンドが成功したことが表示されますが、独自のテストを行うこともできます。

Identity Management クライアントが、サーバーに定義したユーザーに関する情報を取得できることをテストするには、サーバーに定義したユーザーを解決できることを確認します。たとえば、デフォルトの admin ユーザーを確認するには、次のコマンドを実行します。

[user@client1 ~]$ id admin
uid=1254400000(admin) gid=1254400000(admins) groups=1254400000(admins)

認証が適切に機能していることをテストするには、別の既存 IdM ユーザーで su - を実行します。

[user@client1 ~]$ su - idm_user
Last login: Thu Oct 18 18:39:11 CEST 2018 from 192.168.122.1 on pts/0
[idm_user@client1 ~]$

4.5. Ansible Playbook での IdM クライアントのアンインストール

以下の手順に従って、Ansible Playbook を使用して IdM クライアントと機能していたホストをアンインストールします。

前提条件

  • IdM 管理者の認証情報

手順

  • IdM クライアントをアンインストールするには、uninstall-client.yml など Playbook ファイルの名前を指定して ansible-playbook コマンドを実行します。-i オプションでインベントリーファイルを指定し、必要に応じて -v-vv または -vvv オプションを使用して詳細レベルを指定します。

    $ ansible-playbook -v -i inventory/hosts uninstall-client.yml
重要

クライアントをアンインストールすると、基本的な IdM 設定のみがホストから削除されますが、クライアントの再インストールを行うことになった場合に備え、ホストに設定ファイルが残されます。また、アンインストールには以下の制限があります。

  • IdM LDAP サーバーからクライアントホストエントリーは削除されない。アンインストールすると、ホストの登録が解除されるだけである。
  • クライアントにあるサービスは、IdM から削除されない。
  • クライアントの DNS エントリーは、IdM サーバーから削除されない。
  • /etc/krb5.keytab を除き、以前の Keytab のプリンシパルは削除されない。

アンインストールを行うと、IdM CA がホスト向けに発行した証明書がすべて削除されることに注意してください。

関連情報

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

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

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

このプラクティスを使用すると、すべての Playbook を 1 カ所で見つけることができます。また、root 権限を呼び出しなくても Playbook を実行できます。

注記

管理対象ノードで root 権限があれば、ipaserveripareplicaipaclient、および ipabackup ansible-freeipa ロールを実行できます。これらのロールには、ディレクトリーおよび dnf ソフトウェアパッケージマネージャーへの特権アクセスが必要です。

本セクションでは、~/MyPlaybooks ディレクトリーを作成し、このディレクトリーに Ansible Playbook を保存して実行できるように設定する方法を説明します。

前提条件

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

手順

  1. Ansible 設定および Playbook のディレクトリーをホームディレクトリーに作成します。

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

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

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

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

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

  5. (必要に応じて) SSH 公開鍵および秘密鍵を作成します。テスト環境でのアクセスを簡素化するには、秘密鍵にパスワードを設定しないでください。

    $ ssh-keygen
  6. 各管理対象ノードの IdM admin アカウントに SSH 公開鍵をコピーします。

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

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

関連情報

第6章 Ansible Playbook でグローバル IdM 設定の構成

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

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

6.1. Ansible Playbook で IdM 設定の取得

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

前提条件

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

手順

  1. inventory.file などのインベントリーファイルを作成して、IdM 設定を取得する IdM サーバーを [ipaserver] セクションに定義します。たとえば、Ansible に対して server.idm.example.com からデータを取得するよう指示するには、次のコマンドを実行します。

    [ipaserver]
    server.idm.example.com
  2. Ansible Playbook ファイル /usr/share/doc/ansible-freeipa/playbooks/config/retrieve-config.yml を開いて編集します。

    ---
    - name: Playbook to handle global IdM configuration
      hosts: ipaserver
      become: no
      gather_facts: no
    
      tasks:
      - name: Query IPA global configuration
        ipaconfig:
          ipaadmin_password: Secret123
        register: serverconfig
    
      - debug:
          msg: "{{ serverconfig }}"
  3. 以下を変更してファイルを調整します。

    • IdM 管理者のパスワード
    • その他の値 (必要な場合)。
  4. ファイルを保存します。
  5. Playbook ファイルとインベントリーファイルを指定して Ansible Playbook を実行します。

    $ ansible-playbook -v -i path_to_inventory_directory/inventory.file /usr/share/doc/ansible-freeipa/playbooks/config/retrieve-config.yml
    [...]
    TASK [debug]
    ok: [server.idm.example.com] => {
        "msg": {
            "ansible_facts": {
                "discovered_interpreter_
            },
            "changed": false,
            "config": {
                "ca_renewal_master_server": "server.idm.example.com",
                "configstring": [
                    "AllowNThash",
                    "KDC:Disable Last Success"
                ],
                "defaultgroup": "ipausers",
                "defaultshell": "/bin/bash",
                "emaildomain": "idm.example.com",
                "enable_migration": false,
                "groupsearch": [
                    "cn",
                    "description"
                ],
                "homedirectory": "/home",
                "maxhostname": "64",
                "maxusername": "64",
                "pac_type": [
                    "MS-PAC",
                    "nfs:NONE"
                ],
                "pwdexpnotify": "4",
                "searchrecordslimit": "100",
                "searchtimelimit": "2",
                "selinuxusermapdefault": "unconfined_u:s0-s0:c0.c1023",
                "selinuxusermaporder": [
                    "guest_u:s0$xguest_u:s0$user_
                ],
                "usersearch": [
                    "uid",
                    "givenname",
                    "sn",
                    "telephonenumber",
                    "ou",
                    "title"
                ]
            },
            "failed": false
        }
    }

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

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

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

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

前提条件

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

手順

  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
    
      tasks:
      - name: set ca_renewal_master_server
        ipaconfig:
          ipaadmin_password: SomeADMINpassword
          ca_renewal_master_server: carenewal.idm.example.com
  4. 以下を変更してファイルを調整します。

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

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

検証手順

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

  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 更新サーバーであることが分かります。

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

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

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

前提条件

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

手順

  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
      become: true
    
      tasks:
      # Set defaultlogin and maxusername
      - ipaconfig:
          ipaadmin_password: Secret123
          defaultshell: /bin/bash
          maxusername: 64
  4. 以下を変更してファイルを調整します。

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

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

検証手順

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

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

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

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

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

関連情報

  • /usr/share/doc/ansible-freeipa/ ディレクトリーにある Markdown ファイル README-config.md に、グローバルな IdM 設定を設定するための Ansible Playbook サンプルと、可能な変数の一覧が表示されます。
  • /usr/share/doc/ansible-freeipa/playbooks/config ディレクトリーに、さまざまな IdM 設定関連操作用の Ansible Playbook のサンプルを確認できます。

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

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

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

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

  • ステージ ユーザーは認証できません。これは初期状態です。アクティブユーザーに必要なユーザーアカウントプロパティーをすべて設定できるわけではありません (例: グループメンバーシップ)。
  • アクティブ ユーザーは認証が可能です。必要なユーザーアカウントプロパティーはすべて、この状態で設定する必要があります。
  • 保存済み ユーザーは、非アクティブであると見なされており、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 に追加しないでください。NSS(Name Service Switch)は、ローカルユーザーおよびグループを解決する前に、常に IdM ユーザーおよびグループを解決します。これは、たとえば、IdM グループメンバーシップがローカルユーザーでは機能しません。

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

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

前提条件

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

手順

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

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

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

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

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

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

    注記

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

  3. Playbook を実行します。

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

検証手順

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

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

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

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

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

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

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

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

前提条件

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

手順

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

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

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

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

  3. Playbook を実行します。

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

検証手順

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

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

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

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

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

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

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

前提条件

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

手順

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

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

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

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

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

検証手順

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

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

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

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

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

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

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

前提条件

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

手順

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

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

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

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

検証手順

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

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

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

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

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

関連情報

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

第8章 Ansible Playbook を使用したユーザーグループの管理

本セクションでは、Ansible Playbook を使用したユーザーグループ管理を説明します。

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

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

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

このセクションには以下のトピックが含まれます。

8.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 が定義されていません。

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

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

ipausers

すべての IdM ユーザー

admins

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

editors

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

trust admins

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

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

警告

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

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

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

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

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

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

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

A chart with Group A (with 2 users) and Group B (with 3 users). Group B is nested inside Group A so Group A contains a total of 5 users.

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

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

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

前提条件

手順

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

    [ipaserver]
    server.idm.example.com
  2. 必要なユーザーおよびグループ情報を使用して Ansible Playbook ファイルを作成します。

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

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

検証手順

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

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

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

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

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

関連情報

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

8.4. Ansible Playbook を使用して IdM ユーザーグループにメンバーマネージャーを存在させる手順

以下の手順では、Ansible Playbook を使用して、ユーザーとユーザーグループ両方の IdM メンバーマネージャーが存在させる方法を説明します。

前提条件

  • IdM 管理者パスワードが分かっている。
  • Ansible コントローラーに ansible-freeipa パッケージがインストールされている。
  • メンバーマネージャーとして追加するユーザーまたはグループの名前と、メンバーマネージャーが管理するグループ名を用意する。

手順

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

    [ipaserver]
    server.idm.example.com
  2. 必要なユーザーおよびグループメンバー管理情報を使用して、Ansible Playbook ファイルを作成します。

    ---
    - name: Playbook to handle membership management
      hosts: ipaserver
      become: true
    
      tasks:
      - name: Ensure user test is present for group_a
        ipagroup:
          ipaadmin_password: MySecret123
          name: group_a
          membermanager_user: test
    
      - name: Ensure group_admins is present for group_a
        ipagroup:
          ipaadmin_password: MySecret123
          name: group_a
          membermanager_group: group_admins
  3. Playbook を実行します。

    $ ansible-playbook -v -i path_to_inventory_directory/inventory.file path_to_playbooks_directory/add-member-managers-user-groups.yml

検証手順

ipa group-show コマンドを使用すると、group_a グループにメンバーマネージャーの test が含まれており、group_adminsgroup_a のメンバーであることが確認できます。

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

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

    ipaserver]$ ipa group-show group_a
      Group name: group_a
      GID: 1133400009
      Membership managed by groups: group_admins
      Membership managed by users: test

関連情報

  • ipa host-add-member-manager --help を参照してください。
  • ipa の man ページを参照してください。

8.5. Ansible Playbook を使用して IdM ユーザーグループにメンバーマネージャーを存在させないようにする手順

以下の手順では、Ansible Playbook を使用して、ユーザーとユーザーグループ両方の IdM メンバーマネージャーが存在させないようにする方法を説明します。

前提条件

  • IdM 管理者パスワードが分かっている。
  • Ansible コントローラーに ansible-freeipa パッケージがインストールされている。
  • 削除する既存のメンバーマネージャーのユーザーまたはグループの名前と、そのメンバーマネージャーが管理するグループ名が必要です。

手順

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

    [ipaserver]
    server.idm.example.com
  2. 必要なユーザーおよびグループメンバー管理情報を使用して、Ansible Playbook ファイルを作成します。

    ---
    - name: Playbook to handle membership management
      hosts: ipaserver
      become: true
    
      tasks:
      - name: Ensure member manager user and group members are absent for group_a
        ipagroup:
          ipaadmin_password: MySecret123
          name: group_a
          membermanager_user: test
          membermanager_group: group_admins
          action: member
          state: absent
  3. Playbook を実行します。

    $ ansible-playbook -v -i path_to_inventory_directory/inventory.file path_to_playbooks_directory/ensure-member-managers-are-absent.yml

検証手順

ipa group-show コマンドを使用すると、group_a グループにメンバーマネージャーの test が含まれておらず、group_adminsgroup_a のメンバーであることが確認できます。

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

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

    ipaserver]$ ipa group-show group_a
      Group name: group_a
      GID: 1133400009

関連情報

  • ipa host-remove-member-manager --help を参照してください。
  • ipa の man ページを参照してください。

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

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

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

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

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

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

警告

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

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

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

前提条件

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

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

手順

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

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

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

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

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

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

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

関連情報

  • セルフサービスルールの概念の詳細は、「IdM でのセルフサービスアクセス制御」を参照してください。
  • ipaselfservice モジュールを使用するその他の Ansible Playbook の例については、以下を参照してください。

    • /usr/share/doc/ansible-freeipa/ ディレクトリーにある README-selfservice.md ファイルこのファイルには ipaselfservice 変数の定義も含まれます。
    • /usr/share/doc/ansible-freeipa/playbooks/selfservice ディレクトリー。

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

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

前提条件

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

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

手順

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

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

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

    • ipaadmin_password 変数は IdM 管理者のパスワードに設定します。
    • name 変数は、セルフサービスルールの名前に設定します。
    • state 変数は absent に設定します。

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

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

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

関連情報

  • セルフサービスルールの概念の詳細は、「IdM でのセルフサービスアクセス制御」を参照してください。
  • ipaselfservice モジュールを使用するその他の Ansible Playbook の例については、以下を参照してください。

    • /usr/share/doc/ansible-freeipa/ ディレクトリーにある README-selfservice.md ファイルこのファイルには ipaselfservice 変数の定義も含まれます。
    • /usr/share/doc/ansible-freeipa/playbooks/selfservice ディレクトリー。

9.4. Ansible を使用してセルフサービスルールに固有の属性を含める手順

以下の手順では、Ansible Playbook を使用して、既存のセルフサービスルールに特定の設定を追加する方法を説明します。この例では、ユーザーは自分の名前詳細を管理できる のセルフサービスルールに、surname のメンバー属性が含まれるようにします。

前提条件

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

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

手順

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

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

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

    • ipaadmin_password 変数は IdM 管理者のパスワードに設定します。
    • name 変数は、変更するセルフサービスルールの名前に設定します。
    • attribte 変数は surname に設定します。
    • action 変数は member に設定します。

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

    ---
    - name: Self-service member present
      hosts: ipaserver
      become: true
    
      tasks:
      - name: Ensure selfservice "Users can manage their own name details" member attribute surname is present
        ipaselfservice:
          ipaadmin_password: Secret123
          name: "Users can manage their own name details"
          attribute:
          - surname
          action: member
  5. ファイルを保存します。
  6. Playbook ファイルとインベントリーファイルを指定して Ansible Playbook を実行します。

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

関連情報

  • セルフサービスルールの概念の詳細は、「IdM でのセルフサービスアクセス制御」を参照してください。
  • ipaselfservice モジュールを使用するその他の Ansible Playbook の例については、以下を参照してください。

    • /usr/share/doc/ansible-freeipa/ ディレクトリーにある README-selfservice.md ファイルこのファイルには ipaselfservice 変数の定義も含まれます。
    • /usr/share/doc/ansible-freeipa/playbooks/selfservice ディレクトリー。

9.5. Ansible を使用してセルフサービスルールに固有の属性を含めいないようにする手順

以下の手順では、Ansible Playbook を使用して、セルフサービスルールに特定の設定が割り当てられないようにする方法を説明します。この Playbook を使用して、セルフサービスルールで不必要なアクセス権限を付与しないようにします。この例では、ユーザーが独自の名前の詳細を管理できる セルフサービスルールに givennamesurname のメンバー属性が含まれないようにします。

前提条件

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

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

手順

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

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

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

    • ipaadmin_password 変数は IdM 管理者のパスワードに設定します。
    • name 変数は、変更するセルフサービスルールの名前に設定します。
    • 属性 変数は givenname および surname に設定します。
    • action 変数は member に設定します。
    • state 変数は absent に設定します。

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

    ---
    - name: Self-service member absent
      hosts: ipaserver
      become: true
    
      tasks:
      - name: Ensure selfservice "Users can manage their own name details" member attributes givenname and surname are absent
        ipaselfservice:
          ipaadmin_password: Secret123
          name: "Users can manage their own name details"
          attribute:
          - givenname
          - surname
          action: member
          state: absent
  5. ファイルを保存します。
  6. Playbook ファイルとインベントリーファイルを指定して Ansible Playbook を実行します。

    $ ansible-playbook -v -i inventory selfservice-member-absent-copy.yml

関連情報

  • セルフサービスルールの概念の詳細は、「IdM でのセルフサービスアクセス制御」を参照してください。
  • ipaselfservice モジュールを使用するその他の Ansible Playbook の例については、以下を参照してください。

    • /usr/share/doc/ansible-freeipa/ ディレクトリーにある README-selfservice.md ファイルこのファイルには ipaselfservice 変数の定義も含まれます。
    • /usr/share/doc/ansible-freeipa/playbooks/selfservice ディレクトリー。

第10章 Ansible Playbook を使用してユーザーグループにパーミッションを委譲してユーザーを管理する手順

委譲は、セルフサービスルールおよびロールベースのアクセス制御 (RBAC) などの IdM のアクセス制御メソッドの 1 つです。委譲を使用して、あるユーザーのグループにパーミッションを割り当てて別のユーザーのグループのエントリーを管理できます。

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

10.1. 委譲ルール

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

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

委譲ルールにより、IdM の既存のユーザーグループにパーミッションが付与されます。委任を使用すると、managers ユーザーグループで employees ユーザーグループでユーザーの選択された属性を管理できます。

10.2. IdM の Ansible インベントリーファイルの作成

Ansible を使用する場合は、ホームディレクトリーに Ansible Playbook 専用のサブディレクトリーを作成して、/usr/share/doc/ansible-freeipa/*/usr/share/doc/rhel-system-roles/* サブディレクトリーからコピーして調整できるようにします。この方法には、以下の利点があります。

  • すべての Playbook を 1 カ所で見つけることがでる。
  • root 権限を呼び出さずに Playbook を実行できる。

手順

  1. Ansible 設定および Playbook のディレクトリーをホームディレクトリーに作成します。

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

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

    [defaults]
    inventory = /home/<username>/MyPlaybooks/inventory
    
    [privilege_escalation]
    become=True
  4. ~/MyPlaybooks/inventory ファイルを以下の内容で作成します。

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

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

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

以下の手順では、Ansible Playbook を使用して、新しい IdM 委譲ルールの特権を定義して、その存在を確認する方法を説明します。この例では、新しい basic manager attributes 委譲ルールにより、managers グループが employees グループのメンバーに対して以下の属性の読み取りと書き込みを行うことができます。

  • businesscategory
  • departmentnumber
  • employeenumber
  • employeetype

前提条件

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

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

手順

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

    $ cd ~/MyPlaybooks/
  2. /usr/share/doc/ansible-freeipa/playbooks/delegation/ にある delegation-present.yml ファイルのコピーを作成します。

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

    • ipaadmin_password 変数は IdM 管理者のパスワードに設定します。
    • name 変数は新しい委譲ルールの名前に設定します。
    • permission 変数は、付与するパーミッションをコンマ区切りの一覧(read および write)で設定します。
    • attribute 変数は、委譲されたユーザーグループが管理できる属性の一覧 (businesscategorydepartmentnumberemployeenumber および employeetype) に変数を設定します。
    • group 変数は、属性の表示や変更権限を付与したグループの名前に設定します。
    • membergroup 変数は、属性の表示または変更が可能なグループ名に設定します。

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

    ---
    - name: Playbook to manage a delegation rule
      hosts: ipaserver
      become: true
    
      tasks:
      - name: Ensure delegation "basic manager attributes" is present
        ipadelegation:
          ipaadmin_password: Secret123
          name: "basic manager attributes"
          permission: read, write
          attribute:
          - businesscategory
          - departmentnumber
          - employeenumber
          - employeetype
          group: managers
          membergroup: employees
  5. ファイルを保存します。
  6. Playbook ファイルとインベントリーファイルを指定して Ansible Playbook を実行します。

    $ ansible-playbook -v -i ~/MyPlaybooks/inventory delegation-present-copy.yml

関連情報

  • 委譲ルールの概念の詳細は、「委譲ルール」を参照してください。
  • ipadelegation モジュールを使用する他の Ansible Playbook の例は、以下を参照してください。

    • /usr/share/doc/ansible-freeipa/ ディレクトリーにある README-delegation.md ファイル。このファイルには、ipadelegation 変数の定義も含まれます。
    • /usr/share/doc/ansible-freeipa/playbooks/ipadelegation ディレクトリー

10.4. Ansible を使用して委譲ルールがないことを確認する手順

以下の手順では、Ansible Playbook を使用して、指定した委譲ルールが IdM 設定に存在しないことを確認する方法を説明します。以下の例では、カスタムの basic manager attributes 委譲ルールが IdM に存在しないことを確認する方法を説明します。

前提条件

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

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

手順

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

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

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

    • ipaadmin_password 変数は IdM 管理者のパスワードに設定します。
    • name 変数は委譲ルールの名前に設定します。
    • state 変数は absent に設定します。

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

    ---
    - name: Delegation absent
      hosts: ipaserver
      become: true
    
      tasks:
      - name: Ensure delegation "basic manager attributes" is absent
        ipadelegation:
          ipaadmin_password: Secret123
          name: "basic manager attributes"
          state: absent
  5. ファイルを保存します。
  6. Playbook ファイルとインベントリーファイルを指定して Ansible Playbook を実行します。

    $ ansible-playbook -v -i ~/MyPlaybooks/inventory delegation-absent-copy.yml

関連情報

  • 委譲ルールの概念の詳細は、「委譲ルール」を参照してください。
  • ipadelegation モジュールを使用する他の Ansible Playbook の例は、以下を参照してください。

    • /usr/share/doc/ansible-freeipa/ ディレクトリーにある README-delegation.md ファイル。このファイルには、ipadelegation 変数の定義も含まれます。
    • /usr/share/doc/ansible-freeipa/playbooks/ipadelegation ディレクトリー

10.5. Ansible を使用して委譲ルールに特定の属性を含める手順

以下の手順では、Ansible Playbook を使用して、委譲ルールに特定の設定を指定する方法を説明します。この Playbook を使用して、以前に作成した委譲ロールを変更できます。この例では、basic manager attributes 委譲ルールに departmentnumber メンバー属性のみが含まれるようにします。

前提条件

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

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

手順

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

    $ cd ~/MyPlaybooks/
  2. /usr/share/doc/ansible-freeipa/playbooks/delegation/ にある delegation-member-present.yml ファイルのコピーを作成します。

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

    • ipaadmin_password 変数は IdM 管理者のパスワードに設定します。
    • name 変数は、変更する委譲ルールの名前に設定します。
    • attribute 変数は departmentnumber に設定します。
    • action 変数は member に設定します。

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

    ---
    - name: Delegation member present
      hosts: ipaserver
      become: true
    
      tasks:
      - name: Ensure delegation "basic manager attributes" member attribute departmentnumber is present
        ipadelegation:
          ipaadmin_password: Secret123
          name: "basic manager attributes"
          attribute:
          - departmentnumber
          action: member
  5. ファイルを保存します。
  6. Playbook ファイルとインベントリーファイルを指定して Ansible Playbook を実行します。

    $ ansible-playbook -v -i ~/MyPlaybooks/inventory delegation-member-present-copy.yml

関連情報

  • 委譲ルールの概念の詳細は、「委譲ルール」を参照してください。
  • ipadelegation モジュールを使用する他の Ansible Playbook の例は、以下を参照してください。

    • /usr/share/doc/ansible-freeipa/ ディレクトリーにある README-delegation.md ファイル。このファイルには、ipadelegation 変数の定義も含まれます。
    • /usr/share/doc/ansible-freeipa/playbooks/ipadelegation ディレクトリー

10.6. Ansible を使用して委譲ルールに特定の属性を含めないようにする手順

以下の手順では、Ansible Playbook を使用して、委譲ルールに特定の設定が割り当てられないようにする方法を説明します。この Playbook を使用して、委譲ロールが不必要なアクセス権限を付与しないようします。この例では、basic manager attributes 委譲ルールに employeenumber および employeetype メンバー属性が含まれないようにします。

前提条件

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

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

手順

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

    $ cd ~/MyPlaybooks/
  2. /usr/share/doc/ansible-freeipa/playbooks/delegation/ にある delegation-member-absent.yml ファイルのコピーを作成します。

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

    • ipaadmin_password 変数は IdM 管理者のパスワードに設定します。
    • name 変数は、変更する委譲ルールの名前に設定します。
    • attribute 変数は employeenumber および employeetype に設定します。
    • action 変数は member に設定します。
    • state 変数は absent に設定します。

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

    ---
    - name: Delegation member absent
      hosts: ipaserver
      become: true
    
      tasks:
      - name: Ensure delegation "basic manager attributes" member attributes employeenumber and employeetype are absent
        ipadelegation:
          ipaadmin_password: Secret123
          name: "basic manager attributes"
          attribute:
          - employeenumber
          - employeetype
          action: member
          state: absent
  5. ファイルを保存します。
  6. Playbook ファイルとインベントリーファイルを指定して Ansible Playbook を実行します。

    $ ansible-playbook -v -i ~/MyPlaybooks/inventory delegation-member-absent-copy.yml

関連情報

  • 委譲ルールの概念の詳細は、「委譲ルール」を参照してください。
  • ipadelegation モジュールを使用する他の Ansible Playbook の例は、以下を参照してください。

    • /usr/share/doc/ansible-freeipa/ ディレクトリーにある README-delegation.md ファイル。このファイルには、ipadelegation 変数の定義も含まれます。
    • /usr/share/doc/ansible-freeipa/playbooks/ipadelegation ディレクトリー

第11章 Ansible Playbook を使用した IdM でのロールベースアクセス制御の管理

ロールベースアクセス制御 (RBAC) は、ロールおよび権限関連を定義する、ポリシーに依存しないアクセス制御メカニズムです。Identity Management (IdM) の RBAC のコンポーネントは、ロール、権限、パーミッションです。

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

特に大企業では、RBAC を使用すると、責任の領域を個別に設定する階層管理システムを作成できます。

本章では、Ansible Playbook を使用した RBAC の管理時に行う以下の操作について説明します。

11.1. IdM の権限

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

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

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

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

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

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

IdM パーミッションを使用すると、どのユーザーがどのオブジェクトにアクセスできるか、さらにこのようなオブジェクトの属性にアクセスできるかどうかを制御できます。IdM を使用すると、個別の属性を許可または拒否したり、ユーザー、グループ、sudo などの特定の IdM 機能を、全匿名ユーザー、全認証済みユーザー、または特定の特権ユーザーグループ限定などと、全体的な表示設定を変更したりできます。
たとえば、このアプローチではパーミッション指定に柔軟性があるので、アクセスが必要な特定のセクションのみにユーザーまたはグループのアクセスを制限し、他のセクションをこれらのユーザーまたはグループには完全に表示されないように設定する場合に、管理者にとって便利です。

注記

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

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

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

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

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

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

注記

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

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

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

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

11.3. IdM の権限

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

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

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

注記

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

11.4. IdM のロール

ロールは、ロールに指定したユーザーが所有する権限の一覧です。
実際には、パーミッションでは、指定の低階層のタスク (ユーザーエントリーの作成、グループへのエントリーの追加など)を実行する権限を付与し、特権では、高階層のタスク (指定のグループへの新規ユーザーの作成など) に必要なこれらのパーミッション 1 つ以上を組み合わせます。ロールは必要に応じて、管理者ロールでユーザーの追加、変更、削除ができるなど、特権をまとめます。

重要

ロールは、許可されたアクションを分類するために使用されます。ロールは、特権昇格されないようにしたり、特権の分離を実装するツールとしては使用しません。

注記

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

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

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

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

ロール特権説明

ヘルプデスク

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

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

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

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

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

IT スペシャリスト

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

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

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

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

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

ユーザー管理者

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

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

11.6. Ansible を使用して特権のある IdM RBAC ロールを存在させる手順

デフォルトのロール以外で、ロールベースのアクセス制御 (RBAC) を使用して Identity Management (IdM) のリソースを詳細にわたり制御するには、カスタムロールを作成します。

以下の手順では、Ansible Playbook を使用して、新しい IdM カスタムロールの特権を定義し、その存在を確認する方法を説明します。この例では、新しい user_and_host_administrator ロールには、デフォルトで IdM で存在する以下の特権を一意に組み合わせたものが含まれます。

  • Group Administrators
  • User Administrators
  • Stage User Administrators
  • Group Administrators

前提条件

  • IdM 管理者パスワードが分かっている。
  • Ansible コントロールノードに ansible-freeipa パッケージがインストールされている。
  • 設定を行う IdM サーバーの完全修飾ドメイン名 (FQDN) で Ansible インベントリーファイル を作成している。
  • Ansible インベントリーファイルが ~/ <MyPlaybooks>/ ディレクトリーにある。

手順

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

    $ cd ~/<MyPlaybooks>/
  2. /usr/share/doc/ansible-freeipa/playbooks/role/ にある role-member-user-present.yml ファイルのコピーを作成します。

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

    • ipaadmin_password 変数は IdM 管理者のパスワードに設定します。
    • name 変数は新規ロールの名前に設定します。
    • 特権 一覧は、新しいロールに追加する IdM 権限の名前に設定します。
    • 必要に応じて、user 変数は、新規ロールを付与するユーザーの名前に設定します。
    • 必要に応じて、group 変数は、新規ロールを付与するグループの名前に設定します。

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

    ---
    - name: Playbook to manage IPA role with members.
      hosts: ipaserver
      become: yes
      gather_facts: no
    
      tasks:
      - iparole:
          ipaadmin_password: Secret123
          name: user_and_host_administrator
          user: idm_user01
          group: idm_group01
          privilege:
          - Group Administrators
          - User Administrators
          - Stage User Administrators
          - Group Administrators
  5. ファイルを保存します。
  6. Playbook ファイルとインベントリーファイルを指定して Ansible Playbook を実行します。

    $ ansible-playbook -v -i ~/<MyPlaybooks>/inventory role-member-user-present-copy.yml

関連情報

  • Ansible Vault を使用してパスワードを別のファイルに保存したり、Playbook ファイルの変数として暗号化する場合は、「Ansible Vault を使用したコンテンツの暗号化」を参照してください。
  • IdM でのロールの概念については「IdM のロール」を参照してください。
  • iparole モジュールを使用する他の Ansible Playbook の例については、以下を参照してください。

    • /usr/share/doc/ansible-freeipa/ にある README-role ファイル。このファイルには iparole 変数の定義も含まれます。
    • /usr/share/doc/ansible-freeipa/playbooks/iparole ディレクトリー。

11.7. Ansible を使用して IdM RBAC ロールを設定しないようにする手順

Identity Management (IdM) のロールベースアクセス制御 (RBAC) を管理するシステム管理者は、誤って管理者がユーザーに割り当てることがないように、使用しなくなったロールが削除されていることを確認する必要があります。

以下の手順では、Ansible Playbook を使用してロールが削除されていることを確認する方法を説明します。以下の例では、カスタムの user_and_host_administrator ロールが IdM に存在しないことを確認する方法を説明します。

前提条件

  • IdM 管理者パスワードが分かっている。
  • Ansible コントロールノードに ansible-freeipa パッケージがインストールされている。
  • 設定を行う IdM サーバーの完全修飾ドメイン名 (FQDN) で Ansible インベントリーファイル を作成している。
  • Ansible インベントリーファイルが ~/ <MyPlaybooks>/ ディレクトリーにある。

手順

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

    $ cd ~/<MyPlaybooks>/
  2. /usr/share/doc/ansible-freeipa/playbooks/role/ にある role-is-absent.yml ファイルのコピーを作成します。

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

    • ipaadmin_password 変数は IdM 管理者のパスワードに設定します。
    • name 変数は、ロールの名前に設定します。
    • state 変数は、absent に設定されていることを確認します。

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

    ---
    - name: Playbook to manage IPA role with members.
      hosts: ipaserver
      become: yes
      gather_facts: no
    
      tasks:
      - iparole:
          ipaadmin_password: Secret123
          name: user_and_host_administrator
          state: absent
  5. ファイルを保存します。
  6. Playbook ファイルとインベントリーファイルを指定して Ansible Playbook を実行します。

    $ ansible-playbook -v -i ~/<MyPlaybooks>/inventory role-is-absent-copy.yml

関連情報

  • Ansible Vault を使用してパスワードを別のファイルに保存したり、Playbook ファイルの変数として暗号化する場合は、「Ansible Vault を使用したコンテンツの暗号化」を参照してください。
  • IdM でのロールの概念については「IdM のロール」を参照してください。
  • iparole モジュールを使用する他の Ansible Playbook の例については、以下を参照してください。

    • /usr/share/doc/ansible-freeipa/ ディレクトリーにある README-role Markdown ファイル。このファイルには iparole 変数の定義も含まれます。
    • /usr/share/doc/ansible-freeipa/playbooks/iparole ディレクトリー。

11.8. Ansible を使用して、ユーザーグループに IdM RBAC ロールを割り当てる手順

Identity Management (IdM) のロールベースアクセス制御 (RBAC) を管理するシステム管理者は、junior administrators など、特定のユーザーグループにロールを割り当てます。

以下の例では、Ansible Playbook を使用して、同梱の IdM RBAC helpdesk ロールを junior_sysadmins に割り当てる方法を説明します。

前提条件

  • IdM 管理者パスワードが分かっている。
  • Ansible コントロールノードに ansible-freeipa パッケージがインストールされている。
  • 設定を行う IdM サーバーの完全修飾ドメイン名 (FQDN) で Ansible インベントリーファイル を作成している。
  • Ansible インベントリーファイルが ~/ <MyPlaybooks>/ ディレクトリーにある。

手順

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

    $ cd ~/<MyPlaybooks>/
  2. /usr/share/doc/ansible-freeipa/playbooks/role/ にある role-member-group-present.yml ファイルのコピーを作成します。

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

    • ipaadmin_password 変数は IdM 管理者のパスワードに設定します。
    • name 変数は、割り当てるロールの名前に設定します。
    • group 変数はグループ名に設定します。
    • action 変数は member に設定します。

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

    ---
    - name: Playbook to manage IPA role with members.
      hosts: ipaserver
      become: yes
      gather_facts: no
    
      tasks:
      - iparole:
          ipaadmin_password: Secret123
          name: helpdesk
          group: junior_sysadmins
          action: member
  5. ファイルを保存します。
  6. Playbook ファイルとインベントリーファイルを指定して Ansible Playbook を実行します。

    $ ansible-playbook -v -i ~/<MyPlaybooks>/inventory role-member-group-present-copy.yml

関連情報

  • Ansible Vault を使用してパスワードを別のファイルに保存したり、Playbook ファイルの変数として暗号化する場合は、「Ansible Vault を使用したコンテンツの暗号化」を参照してください。
  • IdM でのロールの概念については「IdM のロール」を参照してください。
  • iparole モジュールを使用する他の Ansible Playbook の例については、/usr/share/doc/ansible-freeipa/ ディレクトリーにある README-role Markdown ファイルを参照してください。このファイルには iparole 変数の定義も含まれます。
  • iparole モジュールを使用する他の Ansible Playbook の例については、/usr/share/doc/ansible-freeipa/playbooks/iparole ディレクトリーを参照してください。

11.9. Ansible を使用して特定のユーザーに IdM RBAC ロールが割り当てられないようにする手順

Identity Management (IdM) のロールベースアクセス制御 (RBAC) を管理するシステム管理者は、会社内で別の役職に異動した後など、特定のユーザーに RBAC ロールが割り当てられないようにすることもできます。

以下の手順では、Ansible Playbook を使用して、 user_01 および user_02 という名前のユーザーが helpdesk ロールに割り当てられないようにする方法を説明します。

前提条件

  • IdM 管理者パスワードが分かっている。
  • Ansible コントロールノードに ansible-freeipa パッケージがインストールされている。
  • 設定を行う IdM サーバーの完全修飾ドメイン名 (FQDN) で Ansible インベントリーファイル を作成している。
  • Ansible インベントリーファイルが ~/ <MyPlaybooks>/ ディレクトリーにある。

手順

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

    $ cd ~/<MyPlaybooks>/
  2. /usr/share/doc/ansible-freeipa/playbooks/role/ にある role-member-user-absent.yml ファイルのコピーを作成します。

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

    • ipaadmin_password 変数は IdM 管理者のパスワードに設定します。
    • name 変数は、割り当てるロールの名前に設定します。
    • user 一覧をユーザーの名前に設定します。
    • action 変数は member に設定します。
    • state 変数は absent に設定します。

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

    ---
    - name: Playbook to manage IPA role with members.
      hosts: ipaserver
      become: yes
      gather_facts: no
    
      tasks:
      - iparole:
          ipaadmin_password: Secret123
          name: helpdesk
          user
          - user_01
          - user_02
          action: member
          state: absent
  5. ファイルを保存します。
  6. Playbook ファイルとインベントリーファイルを指定して Ansible Playbook を実行します。

    $ ansible-playbook -v -i ~/<MyPlaybooks>/inventory role-member-user-absent-copy.yml

関連情報

  • Ansible Vault を使用してパスワードを別のファイルに保存したり、Playbook ファイルの変数として暗号化する場合は、「Ansible Vault を使用したコンテンツの暗号化」を参照してください。
  • IdM でのロールの概念については「IdM のロール」を参照してください。
  • iparole モジュールを使用する他の Ansible Playbook の例については、/usr/share/doc/ansible-freeipa/ ディレクトリーにある README-role Markdown ファイルを参照してください。このファイルには iparole 変数の定義も含まれます。
  • iparole モジュールを使用する他の Ansible Playbook の例については、/usr/share/doc/ansible-freeipa/playbooks/iparole ディレクトリーを参照してください。

11.10. Ansible を使用してサービスを IdM RBAC ロールに所属させるように設定する手順

Identity Management (IdM) のロールベースアクセス制御 (RBAC) を管理するシステム管理者は、IdM に登録されている特定のサービスが、特定のロールのメンバーになっていることを確認する必要がある場合があります。以下の例では、カスタムの web_administrator ロールを使用して client01.idm.example.com サーバー上で実行中の HTTP サービスを管理できるようにする方法を説明します。

前提条件

  • IdM 管理者パスワードが分かっている。
  • Ansible コントロールノードに ansible-freeipa パッケージがインストールされている。
  • 設定を行う IdM サーバーの完全修飾ドメイン名 (FQDN) で Ansible インベントリーファイル を作成している。
  • Ansible インベントリーファイルが ~/ <MyPlaybooks>/ ディレクトリーにある。
  • web_administrator ロールが IdM に存在する。
  • HTTP/client01.idm.example.com@IDM.EXAMPLE.COM サービスが IdM に存在する。

手順

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

    $ cd ~/<MyPlaybooks>/
  2. /usr/share/doc/ansible-freeipa/playbooks/role/ にある role-member-service-present.yml ファイルのコピーを作成します。

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

    • ipaadmin_password 変数は IdM 管理者のパスワードに設定します。
    • name 変数は、割り当てるロールの名前に設定します。
    • service 一覧はサービス名に設定します。
    • action 変数は member に設定します。

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

    ---
    - name: Playbook to manage IPA role with members.
      hosts: ipaserver
      become: yes
      gather_facts: no
    
      tasks:
      - iparole:
          ipaadmin_password: Secret123
          name: web_administrator
          service:
          - HTTP/client01.idm.example.com
          action: member
  5. ファイルを保存します。
  6. Playbook ファイルとインベントリーファイルを指定して Ansible Playbook を実行します。

    $ ansible-playbook -v -i ~/<MyPlaybooks>/inventory role-member-service-present-copy.yml

関連情報

  • Ansible Vault を使用してパスワードを別のファイルに保存したり、Playbook ファイルの変数として暗号化する場合は、「Ansible Vault を使用したコンテンツの暗号化」を参照してください。
  • IdM でのロールの概念については「IdM のロール」を参照してください。
  • iparole モジュールを使用する他の Ansible Playbook の例については、/usr/share/doc/ansible-freeipa/ ディレクトリーにある README-role Markdown ファイルを参照してください。このファイルには iparole 変数の定義も含まれます。
  • iparole モジュールを使用する他の Ansible Playbook の例については、/usr/share/doc/ansible-freeipa/playbooks/iparole ディレクトリーを参照してください。

11.11. Ansible を使用してホストを IdM RBAC ロールに所属させるように設定する手順

Identity Management (IdM) でロールベースアクセス制御を管理するシステム管理者は、特定のホストまたはホストグループが特定のロールに関連付けられていることを確認する必要がある場合があります。以下の例では、カスタムの web_administrator ロールが HTTP サービスを実行している client01.idm.example.com の IdM ホストを管理できるようにする方法を説明します。

前提条件

  • IdM 管理者パスワードが分かっている。
  • Ansible コントロールノードに ansible-freeipa パッケージがインストールされている。
  • 設定を行う IdM サーバーの完全修飾ドメイン名 (FQDN) で Ansible インベントリーファイル を作成している。
  • Ansible インベントリーファイルが ~/ <MyPlaybooks>/ ディレクトリーにある。
  • web_administrator ロールが IdM に存在する。
  • client01.idm.example.com ホストが IdM に存在する。

手順

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

    $ cd ~/<MyPlaybooks>/
  2. /usr/share/doc/ansible-freeipa/playbooks/role/ にある role-member-host-present.yml ファイルのコピーを作成します。

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

    • ipaadmin_password 変数は IdM 管理者のパスワードに設定します。
    • name 変数は、割り当てるロールの名前に設定します。
    • host 一覧をホストの名前に設定します。

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

    ---
    - name: Playbook to manage IPA role with members.
      hosts: ipaserver
      become: yes
      gather_facts: no
    
      tasks:
      - iparole:
          ipaadmin_password: Secret123
          name: web_administrator
          host:
          - client01.idm.example.com
          action: member
  5. ファイルを保存します。
  6. Playbook ファイルとインベントリーファイルを指定して Ansible Playbook を実行します。

    $ ansible-playbook -v -i ~/<MyPlaybooks>/inventory role-member-host-present-copy.yml

関連情報

  • Ansible Vault を使用してパスワードを別のファイルに保存したり、Playbook ファイルの変数として暗号化する場合は、「Ansible Vault を使用したコンテンツの暗号化」を参照してください。
  • IdM でのロールの概念については「IdM のロール」を参照してください。
  • iparole モジュールを使用する他の Ansible Playbook の例については、/usr/share/doc/ansible-freeipa/ ディレクトリーにある README-role Markdown ファイルを参照してください。このファイルには iparole 変数の定義も含まれます。
  • iparole モジュールを使用する他の Ansible Playbook の例については、/usr/share/doc/ansible-freeipa/playbooks/iparole ディレクトリーを参照してください。

11.12. Ansible を使用してホストグループを IdM RBAC ロールに所属させるように設定する手順

Identity Management (IdM) でロールベースアクセス制御を管理するシステム管理者は、特定のホストまたはホストグループが特定のロールに関連付けられていることを確認する必要がある場合があります。以下の例では、カスタムの web_administrator ロールが HTTP サービスを実行している IdM ホストの web_servers グループを管理できるようにする方法を説明します。

前提条件

  • IdM 管理者パスワードが分かっている。
  • Ansible コントロールノードに ansible-freeipa パッケージがインストールされている。
  • 設定を行う IdM サーバーの完全修飾ドメイン名 (FQDN) で Ansible インベントリーファイル を作成している。
  • Ansible インベントリーファイルが ~/ <MyPlaybooks>/ ディレクトリーにある。
  • web_administrator ロールが IdM に存在する。
  • web_servers ホストグループが IdM に存在する。

手順

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

    $ cd ~/<MyPlaybooks>/
  2. /usr/share/doc/ansible-freeipa/playbooks/role/ にある role-member-hostgroup-present.yml ファイルのコピーを作成します。

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

    • ipaadmin_password 変数は IdM 管理者のパスワードに設定します。
    • name 変数は、割り当てるロールの名前に設定します。
    • hostgroup 一覧はホストグループ名に設定します。

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

    ---
    - name: Playbook to manage IPA role with members.
      hosts: ipaserver
      become: yes
      gather_facts: no
    
      tasks:
      - iparole:
          ipaadmin_password: Secret123
          name: web_administrator
          hostgroup:
          - web_servers
          action: member
  5. ファイルを保存します。
  6. Playbook ファイルとインベントリーファイルを指定して Ansible Playbook を実行します。

    $ ansible-playbook -v -i ~/<MyPlaybooks>/inventory role-member-hostgroup-present-copy.yml

関連情報

  • Ansible Vault を使用してパスワードを別のファイルに保存したり、Playbook ファイルの変数として暗号化する場合は、「Ansible Vault を使用したコンテンツの暗号化」を参照してください。
  • IdM でのロールの概念については「IdM のロール」を参照してください。
  • iparole モジュールを使用する他の Ansible Playbook の例については、/usr/share/doc/ansible-freeipa/ ディレクトリーにある README-role Markdown ファイルを参照してください。このファイルには iparole 変数の定義も含まれます。
  • iparole モジュールを使用する他の Ansible Playbook の例については、/usr/share/doc/ansible-freeipa/playbooks/iparole ディレクトリーを参照してください。

第12章 Ansible Playbook を使用した RBAC 権限の管理

ロールベースアクセス制御 (RBAC) は、ロール、権限およびパーミッションで定義する、ポリシーに依存しないアクセス制御メカニズムです。特に大企業では、RBAC を使用すると、責任の領域を個別に設定する階層管理システムを作成できます。

本章では、Ansible Playbook を使用して Identity Management (IdM) で RBAC 権限を管理する以下の操作について説明します。

前提条件

12.1. Ansible を使用してカスタムの IdM RBAC 特権を存在させる手順

Identity Management (IdM) のロールベースアクセス制御 (RBAC) でカスタム権限を完全に機能させるには、ステージごとに進めていく必要があります。

  1. パーミッションが割り当てられていない特権を作成します。
  2. 選択したパーミッションを特権に追加します。

以下の手順では、後でパーミッションを追加できるように、Ansible Playbook を使用して空の特権を作成する方法を説明します。この例では、ホスト管理に関連するすべての IdM パーミッションを組み合わせられるように full_host_administration という名前の特権を作成する方法を説明します。

前提条件

  • IdM 管理者パスワードが分かっている。
  • Ansible コントロールノードに ansible-freeipa パッケージがインストールされている。
  • 設定を行う IdM サーバーの完全修飾ドメイン名 (FQDN) で Ansible インベントリーファイル を作成している。
  • Ansible インベントリーファイルが ~/ MyPlaybooks/ ディレクトリーにある。

手順

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

    $ cd ~/MyPlaybooks/
  2. /usr/share/doc/ansible-freeipa/playbooks/privilege/ にある privilege-present.yml ファイルのコピーを作成します。

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

    • ipaadmin_password 変数は IdM 管理者のパスワードに設定します。
    • name 変数は、新しい特権 full_host_administration の名前に設定します。
    • 必要に応じて、description 変数を使用して特権を記述します。

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

    ---
    - name: Privilege present example
      hosts: ipaserver
      become: true
    
      tasks:
      - name: Ensure privilege full_host_administration is present
        ipaprivilege:
          ipaadmin_password: Secret123
          name: full_host_administration
          description: This privilege combines all IdM permissions related to host administration
  5. ファイルを保存します。
  6. Playbook ファイルとインベントリーファイルを指定して Ansible Playbook を実行します。

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

12.2. Ansible を使用してカスタムの IdM RBAC 特権にメンバーパーミッションを存在させる手順

Identity Management (IdM) のロールベースアクセス制御 (RBAC) でカスタム権限を完全に機能させるには、ステージごとに進めていく必要があります。

  1. パーミッションが割り当てられていない特権を作成します。
  2. 選択したパーミッションを特権に追加します。

以下の手順では、Ansible Playbook を使用して、前の手順で作成した特権にパーミッションを追加する方法を説明します。この例では、ホスト管理に関連する IdM パーミッションをすべて、full_host_administration という名前の特権に追加する方法を説明します。デフォルトでは、パーミッションは Host EnrollmentHost Administrators および Host Group Administrator 特権の間で分散されます。

前提条件

  • IdM 管理者パスワードが分かっている。
  • Ansible コントロールノードに ansible-freeipa パッケージがインストールされている。
  • 設定を行う IdM サーバーの完全修飾ドメイン名 (FQDN) で Ansible インベントリーファイル を作成している。
  • Ansible インベントリーファイルが ~/ MyPlaybooks/ ディレクトリーにある。
  • full_host_administration 権限が存在する。Ansible を使用して特権を作成する方法は、「Ansible を使用してカスタムの IdM RBAC 特権の存在」を参照してください。

手順

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

    $ cd ~/MyPlaybooks/
  2. /usr/share/doc/ansible-freeipa/playbooks/privilege/ にある privilege-member-present.yml ファイルのコピーを作成します。

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

    • 使用しているユースケースに合わせて、タスクの 名前 を調節します。
    • ipaadmin_password 変数は IdM 管理者のパスワードに設定します。
    • name 変数は、特権の名前に設定します。
    • permission は、特権に追加するパーミッションの名前を設定します。
    • action 変数が member に設定されていることを確認します。

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

    ---
    - name: Privilege member present example
      hosts: ipaserver
      become: true
    
      tasks:
      - name: Ensure that permissions are present for the "full_host_administration" privilege
        ipaprivilege:
          ipaadmin_password: Secret123
          name: full_host_administration
          permission:
          - "System: Add krbPrincipalName to a Host"
          - "System: Enroll a Host"
          - "System: Manage Host Certificates"
          - "System: Manage Host Enrollment Password"
          - "System: Manage Host Keytab"
          - "System: Manage Host Principals"
          - "Retrieve Certificates from the CA"
          - "Revoke Certificate"
          - "System: Add Hosts"
          - "System: Add krbPrincipalName to a Host"
          - "System: Enroll a Host"
          - "System: Manage Host Certificates"
          - "System: Manage Host Enrollment Password"
          - "System: Manage Host Keytab"
          - "System: Manage Host Keytab Permissions"
          - "System: Manage Host Principals"
          - "System: Manage Host SSH Public Keys"
          - "System: Manage Service Keytab"
          - "System: Manage Service Keytab Permissions"
          - "System: Modify Hosts"
          - "System: Remove Hosts"
          - "System: Add Hostgroups"
          - "System: Modify Hostgroup Membership"
          - "System: Modify Hostgroups"
          - "System: Remove Hostgroups"
  5. ファイルを保存します。
  6. Playbook ファイルとインベントリーファイルを指定して Ansible Playbook を実行します。

    $ ansible-playbook -v -i inventory privilege-member-present-copy.yml

12.3. Ansible を使用して IdM RBAC 特権にパーミッションが含まれないようにする手順

Identity Management (IdM) のシステム管理者は、IdM のロールベースアクセス制御をカスタマイズできます。

以下の手順では、Ansible Playbook を使用して、特権からパーミッションを削除する方法を説明します。この例では、管理者がセキュリティー上のリスクを考慮するため、デフォルトの Certificate Administrators 特権から Request Certificates ignoring CA ACLs を削除する方法を説明します。

前提条件

  • IdM 管理者パスワードが分かっている。
  • Ansible コントロールノードに ansible-freeipa パッケージがインストールされている。
  • 設定を行う IdM サーバーの完全修飾ドメイン名 (FQDN) で Ansible インベントリーファイル を作成している。
  • Ansible インベントリーファイルが ~/ MyPlaybooks/ ディレクトリーにある。

手順

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

    $ cd ~/MyPlaybooks/
  2. /usr/share/doc/ansible-freeipa/playbooks/privilege/ にある privilege-member-present.yml ファイルのコピーを作成します。

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

    • 使用しているユースケースに合わせて、タスクの 名前 を調節します。
    • ipaadmin_password 変数は IdM 管理者のパスワードに設定します。
    • name 変数は、特権の名前に設定します。
    • permission の一覧は、特権から削除するパーミッションの名前に設定します。
    • action 変数が member に設定されていることを確認します。
    • state 変数は absent に設定されていることを確認します。

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

    ---
    - name: Privilege absent example
      hosts: ipaserver
      become: true
    
      tasks:
      - name: Ensure that the "Request Certificate ignoring CA ACLs" permission is absent from the "Certificate Administrators" privilege
        ipaprivilege:
          ipaadmin_password: Secret123
          name: Certificate Administrators
          permission:
          - "Request Certificate ignoring CA ACLs"
          action: member
          state: absent
  5. ファイルを保存します。
  6. Playbook ファイルとインベントリーファイルを指定して Ansible Playbook を実行します。

    $ ansible-playbook -v -i inventory privilege-member-absent-copy.yml

12.4. Ansible を使用してカスタムの IdM RBAC 権限の名前を変更する手順

Identity Management (IdM) のシステム管理者は、IdM のロールベースアクセス制御をカスタマイズできます。

以下の手順では、たとえば、パーミッションの一部を削除したなどの理由から、特権の名前を変更する方法を説明します。パーミッションを削除した結果、特権の名前は正確ではなくなりました。この例では、管理者は full_host_administration 特権の名前を limited_host_administration に変更します。

前提条件

手順

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

    $ cd ~/MyPlaybooks/
  2. /usr/share/doc/ansible-freeipa/playbooks/privilege/ にある privilege-present.yml ファイルのコピーを作成します。

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

    • ipaadmin_password 変数は IdM 管理者のパスワードに設定します。
    • name 変数は、現在の特権名に設定します。
    • rename 変数を追加して、特権の新しい名前に設定します。
    • state 変数を追加し、 renamed に設定します。
  5. 以下のように、Playbook 自体の名前を変更します。

    ---
    - name: Rename a privilege
      hosts: ipaserver
      become: true
  6. 以下のように、Playbook のタスクの名前を変更します。

    [...]
    tasks:
    - name: Ensure the full_host_administration privilege is renamed to limited_host_administration
      ipaprivilege:
      [...]

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

    ---
    - name: Rename a privilege
      hosts: ipaserver
      become: true
    
      tasks:
      - name: Ensure the full_host_administration privilege is renamed to limited_host_administration
        ipaprivilege:
          ipaadmin_password: Secret123
          name: full_host_administration
          rename: limited_host_administration
          state: renamed
  7. ファイルを保存します。
  8. Playbook ファイルとインベントリーファイルを指定して Ansible Playbook を実行します。

    $ ansible-playbook -v -i inventory rename-privilege.yml

12.5. Ansible を使用して IdM RBAC 特権が含まれないようにする手順

Identity Management (IdM) のシステム管理者は、IdM のロールベースアクセス制御をカスタマイズできます。以下の手順では、Ansible Playbook を使用して RBAC 特権が削除されていることを確認する方法を説明します。この例では、CA administrator 特権が存在しないことを確認する方法を説明します。この手順が終わると、IdM で認証局を管理できるユーザーは admin だけになります。

前提条件

  • IdM 管理者パスワードが分かっている。
  • Ansible コントロールノードに ansible-freeipa パッケージがインストールされている。
  • 設定を行う IdM サーバーの完全修飾ドメイン名 (FQDN) で Ansible インベントリーファイル を作成している。
  • Ansible インベントリーファイルが ~/ MyPlaybooks/ ディレクトリーにある。

手順

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

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

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

    • ipaadmin_password 変数は IdM 管理者のパスワードに設定します。
    • name 変数は、削除する権限の名前に設定します。
    • state 変数が absent に設定されていることを確認します。
  5. 以下のように、Playbook のタスクの名前を変更します。

    [...]
    tasks:
    - name: Ensure privilege "CA administrator" is absent
      ipaprivilege:
      [...]

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

    ---
    - name: Privilege absent example
      hosts: ipaserver
      become: true
    
      tasks:
      - name: Ensure privilege "CA administrator" is absent
        ipaprivilege:
          ipaadmin_password: Secret123
          name: CA administrator
          state: absent
  6. ファイルを保存します。
  7. Playbook ファイルとインベントリーファイルを指定して Ansible Playbook を実行します。

    $ ansible-playbook -v -i inventory privilege-absent-copy.yml

関連情報

  • IdM RBAC での特権の概念の詳細は、「IdM の権限」を参照してください。
  • IdM RBAC でのパーミッションの概念の詳細は、「IdM のパーミッション」を参照してください。
  • ipaprivilege モジュールを使用する他の Ansible Playbook の例については、/usr/share/doc/ansible-freeipa/ ディレクトリーにある README-privilege Markdown ファイルを参照してください。このファイルには ipaprivilege 変数の定義も含まれます。
  • ipaprivilege モジュールを使用する他の Ansible Playbook の例については、/usr/share/doc/ansible-freeipa/playbooks/ipaprivilege ディレクトリーを参照してください。

第13章 Ansible Playbook を使用した IdM での RBAC パーミッションの管理

ロールベースアクセス制御 (RBAC) は、ロール、権限およびパーミッションで定義する、ポリシーに依存しないアクセス制御メカニズムです。特に大企業では、RBAC を使用すると、責任の領域を個別に設定する階層管理システムを作成できます。

本章では、Ansible Playbook を使用して Identity Management (IdM) で RBAC パーミッションの管理時に行う、以下の操作について説明します。

前提条件

13.1. Ansible を使用して RBAC パーミッションを存在させる手順

Identity Management (IdM) のシステム管理者は、IdM のロールベースアクセス制御をカスタマイズできます。

以下の手順では、Ansible Playbook を使用して、パーミッションを特権に追加できるように IdM にパーミッションを追加する方法を説明します。この例では、目的とする以下の状態を達成する方法を説明します。

  • MyPermission パーミッションが存在する。
  • MyPermission パーミッションだけがホストに適用できる。
  • パーミッションを含む特権を付与されたユーザーは、エントリーに対して以下の操作すべてを実行できます。

    • 書き込み
    • 読み取り
    • 検索
    • 比較
    • 追加
    • Delete

前提条件

  • IdM 管理者パスワードが分かっている。
  • Ansible コントロールノードに ansible-freeipa パッケージがインストールされている。
  • この例では、~/MyPlaybooks/ ディレクトリーを中央サイトとして 作成して設定 し、サンプル Playbook のコピーを保存することを前提とします。

手順

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

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

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

    • 使用しているユースケースに合わせて、タスクの 名前 を調節します。
    • ipaadmin_password 変数は IdM 管理者のパスワードに設定します。
    • name 変数はパーミッションの名前に設定します。
    • object_type 変数は host に設定します。
    • right 変数は all に設定します。

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

    ---
    - name: Permission present example
      hosts: ipaserver
      become: true
    
      tasks:
      - name: Ensure that the "MyPermission" permission is present
        ipapermission:
          ipaadmin_password: Secret123
          name: MyPermission
          object_type: host
          right: all
  5. ファイルを保存します。
  6. Playbook ファイルとインベントリーファイルを指定して Ansible Playbook を実行します。

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

13.2. Ansible を使用して属性を含めて RBAC パーミッションを追加する手順

Identity Management (IdM) のシステム管理者は、IdM のロールベースアクセス制御をカスタマイズできます。

以下の手順では、Ansible Playbook を使用して、パーミッションを特権に追加できるように IdM にパーミッションを追加する方法を説明します。この例では、目的とする以下の状態を達成する方法を説明します。

  • MyPermission パーミッションが存在する。
  • MyPermission パーミッションだけがホストの追加に使用できる。
  • パーミッションを含む特権を付与されたユーザーは、ホストのエントリーに対して以下の操作すべてを実行できる。

    • 書き込み
    • 読み取り
    • 検索
    • 比較
    • 追加
    • Delete
  • MyPermission パーミッションを含む特権のあるユーザーが作成したホストエントリーに description の値を追加できる。
注記

IdM LDAP スキーマでは、パーミッションの作成または変更時に指定できる属性のタイプは制約されません。ただし、object_typehost の場合に attrs: car_licence を指定すると、後でパーミッションを実行して、車のライセンス値をホストに追加使用とすると ipa: ERROR: attribute "car-license" not allowed というエラーメッセージが表示されます。

前提条件

  • IdM 管理者パスワードが分かっている。
  • Ansible コントロールノードに ansible-freeipa パッケージがインストールされている。
  • この例では、~/MyPlaybooks/ ディレクトリーを中央サイトとして 作成して設定 し、サンプル Playbook のコピーを保存することを前提とします。

手順

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

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

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

    • 使用しているユースケースに合わせて、タスクの 名前 を調節します。
    • ipaadmin_password 変数は IdM 管理者のパスワードに設定します。
    • name 変数はパーミッションの名前に設定します。
    • object_type 変数は host に設定します。
    • right 変数は all に設定します。
    • attrs 変数は description に設定します。

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

    ---
    - name: Permission present example
      hosts: ipaserver
      become: true
    
      tasks:
      - name: Ensure that the "MyPermission" permission is present with an attribute
        ipapermission:
          ipaadmin_password: Secret123
          name: MyPermission
          object_type: host
          right: all
          attrs: description
  5. ファイルを保存します。
  6. Playbook ファイルとインベントリーファイルを指定して Ansible Playbook を実行します。

    $ ansible-playbook -v -i inventory permission-present-with-attribute.yml

関連情報

13.3. Ansible を使用して RBAC パーミッションをバインドする手順

Identity Management (IdM) のシステム管理者は、IdM のロールベースアクセス制御をカスタマイズできます。

以下の手順では、Ansible Playbook を使用して、パーミッションを特権に追加できないように IdM からパーミッションを削除する方法を説明します。

前提条件

  • IdM 管理者パスワードが分かっている。
  • Ansible コントロールノードに ansible-freeipa パッケージがインストールされている。
  • この例では、~/MyPlaybooks/ ディレクトリーを中央サイトとして 作成して設定 し、サンプル Playbook のコピーを保存することを前提とします。

手順

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

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

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

    • 使用しているユースケースに合わせて、タスクの 名前 を調節します。
    • ipaadmin_password 変数は IdM 管理者のパスワードに設定します。
    • name 変数はパーミッションの名前に設定します。

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

    ---
    - name: Permission absent example
      hosts: ipaserver
      become: true
    
      tasks:
      - name: Ensure that the "MyPermission" permission is absent
        ipapermission:
          ipaadmin_password: Secret123
          name: MyPermission
          state: absent
  5. ファイルを保存します。
  6. Playbook ファイルとインベントリーファイルを指定して Ansible Playbook を実行します。

    $ ansible-playbook -v -i inventory permission-absent-copy.yml

13.4. Ansible を使用して属性を IdM RBAC パーミッションをメンバーにする手順

Identity Management (IdM) のシステム管理者は、IdM のロールベースアクセス制御をカスタマイズできます。

以下の手順では、Ansible Playbook を使用して、属性が IdM の RBAC パーミッションのメンバーであることを確認する方法を説明します。この手順を行うと、パーミッションのあるユーザーは、属性のあるエントリーを作成できます。

この例では、MyPermission パーミッションを含む特権を持つユーザーにより作成されたホストエントリーに、gecos および description の値を設定する方法を説明します。

注記

IdM LDAP スキーマでは、パーミッションの作成または変更時に指定できる属性のタイプは制約されません。ただし、object_typehost の場合に attrs: car_licence を指定すると、後でパーミッションを実行して、車のライセンス値をホストに追加使用とすると ipa: ERROR: attribute "car-license" not allowed というエラーメッセージが表示されます。

前提条件

  • IdM 管理者パスワードが分かっている。
  • Ansible コントロールノードに ansible-freeipa パッケージがインストールされている。
  • この例では、~/MyPlaybooks/ ディレクトリーを中央サイトとして 作成して設定 し、サンプル Playbook のコピーを保存することを前提とします。
  • MyPermission パーミッションが存在する。

手順

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

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

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

    • 使用しているユースケースに合わせて、タスクの 名前 を調節します。
    • ipaadmin_password 変数は IdM 管理者のパスワードに設定します。
    • name 変数はパーミッションの名前に設定します。
    • attrs 一覧を description および gecos 変数に設定します。
    • action 変数が member に設定されていることを確認します。

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

    ---
    - name: Permission member present example
      hosts: ipaserver
      become: true
    
      tasks:
      - name: Ensure that the "gecos" and "description" attributes are present in "MyPermission"
        ipapermission:
          ipaadmin_password: Secret123
          name: MyPermission
          attrs:
          - description
          - gecos
          action: member
  5. ファイルを保存します。
  6. Playbook ファイルとインベントリーファイルを指定して Ansible Playbook を実行します。

    $ ansible-playbook -v -i inventory permission-member-present-copy.yml

13.5. Ansible を使用して属性が IdM RBAC パーミッションのメンバーに含まれないようにする手順

Identity Management (IdM) のシステム管理者は、IdM のロールベースアクセス制御をカスタマイズできます。

以下の手順では、Ansible Playbook を使用して、属性が IdM の RBAC パーミッションに含まれないようにする方法を説明します。この手順を実行すると、パーミッションのあるユーザーが IdM LDAP にエントリーを作成すると、そのエントリーで、値に属性を関連付けて設定できません。

この例では、目的とする以下の状態を達成する方法を説明します。

  • MyPermission パーミッションが存在する。
  • MyPermission パーミッションを含む特権のあるユーザーが作成したホストエントリーに description 属性を使用できない。

前提条件

  • IdM 管理者パスワードが分かっている。
  • Ansible コントロールノードに ansible-freeipa パッケージがインストールされている。
  • この例では、~/MyPlaybooks/ ディレクトリーを中央サイトとして 作成して設定 し、サンプル Playbook のコピーを保存することを前提とします。
  • MyPermission パーミッションが存在する。

手順

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

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

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

    • 使用しているユースケースに合わせて、タスクの 名前 を調節します。
    • ipaadmin_password 変数は IdM 管理者のパスワードに設定します。
    • name 変数はパーミッションの名前に設定します。
    • attrs 変数は description に設定します。
    • action 変数は member に設定します。
    • state 変数が absentに設定されていることを確認します。

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

    ---
    - name: Permission absent example
      hosts: ipaserver
      become: true
    
      tasks:
      - name: Ensure that an attribute is not a member of "MyPermission"
        ipapermission:
          ipaadmin_password: Secret123
          name: MyPermission
          attrs: description
          action: member
          state: absent
  5. ファイルを保存します。
  6. Playbook ファイルとインベントリーファイルを指定して Ansible Playbook を実行します。

    $ ansible-playbook -v -i inventory permission-member-absent-copy.yml

13.6. Ansible を使用して IdM RBAC パーミッションの名前を変更する手順

Identity Management (IdM) のシステム管理者は、IdM のロールベースアクセス制御をカスタマイズできます。

以下の手順では、Ansible Playbook を使用してパーミッションの名前を変更する方法を説明します。この例では、MyPermission の名前を MyNewPermission に変更する方法を説明します。

前提条件

  • IdM 管理者パスワードが分かっている。
  • Ansible コントロールノードに ansible-freeipa パッケージがインストールされている。
  • この例では、~/MyPlaybooks/ ディレクトリーを中央サイトとして 作成して設定 し、サンプル Playbook のコピーを保存することを前提とします。
  • MyPermission が IdM に存在する。
  • MyNewPermission が IdM に存在しない。

手順

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

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

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

    • 使用しているユースケースに合わせて、タスクの 名前 を調節します。
    • ipaadmin_password 変数は IdM 管理者のパスワードに設定します。
    • name 変数はパーミッションの名前に設定します。

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

    ---
    - name: Permission present example
      hosts: ipaserver
      become: true
    
      tasks:
      - name: Rename the "MyPermission" permission
        ipapermission:
          ipaadmin_password: Secret123
          name: MyPermission
          rename: MyNewPermission
          state: renamed
  5. ファイルを保存します。
  6. Playbook ファイルとインベントリーファイルを指定して Ansible Playbook を実行します。

    $ ansible-playbook -v -i inventory permission-renamed-copy.yml

13.7. 関連情報

  • IdM RBAC でのパーミッションの概念の詳細は、「IdM のパーミッション」を参照してください。
  • IdM RBAC での特権の概念の詳細は、「IdM の権限」を参照してください。
  • ipapermission モジュールを使用する他の Ansible Playbook の例については、/usr/share/doc/ansible-freeipa/ ディレクトリーにある README-permission Markdown ファイルを参照してください。このファイルには ipapermission 変数の定義も含まれます。
  • ipapermission モジュールを使用する他の Ansible Playbook の例については、/usr/share/doc/ansible-freeipa/playbooks/ipapermission ディレクトリーを参照してください。

第14章 Ansible を使用した IdM でのレプリケーショントポロジーの管理

複数の Identity Management (IdM) サーバーを維持し、冗長性の目的で相互に複製して、サーバーの損失を軽減または防止することができます。たとえば、1 台のサーバーに障害が発生しても、その他のサーバーがドメインにサービスを提供し続けます。障害が発生していないサーバーの 1 台から新しいレプリカを作成し、失われたサーバーを回復することもできます。

IdM サーバーに保存されているデータは、レプリカ合意に基づいて複製されます。2 台のサーバーでレプリカ合意が設定されている場合は、データを共有します。レプリケートされるデータはトポロジーの suffix に保存されます。2 つのレプリカにサフィックス間でレプリカ合意があると、サフィックスはトポロジー segment を形成します。

本章では、Red Hat Ansible Engine を使用して IdM レプリカ合意、トポロジーセグメント、およびトポロジーサフィックスを管理する方法を説明します。本章は以下のセクションで構成されます。

14.1. Ansible を使用して、レプリカ合意が IdM に存在することを確認

Identity Management (IdM) サーバーに保存されているデータは、レプリカ合意に基づいて複製されます。2 台のサーバーでレプリカ合意が設定されている場合は、データを共有します。レプリカ合意は常に双方向のものです。最初のレプリカからサーバーから別のレプリカにデータが複製されるだけでなく、別ののレプリカから最初のレプリカにもデータが複製されます。

本セクションでは、Ansible Playbook を使用して、server.idm.example.comreplica.idm.example.com との間で domain タイプのレプリカ合意が存在することを確認する方法を説明します。

前提条件

  • トポロジー内のレプリカの接続」に記載されている IdM トポロジーを設計するための推奨事項を理解してください。
  • IdM 管理者 のパスワードを知っている。
  • 以下の要件を満たす Ansible コントロールノードを設定している。

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

手順

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

    $ cd ~/MyPlaybooks/
  2. /usr/share/doc/ansible -freeipa/playbooks/topology/ ディレクトリーにある add-topologysegment.yml Ansible Playbook ファイルをコピーします。

    $ cp /usr/share/doc/ansible-freeipa/playbooks/topology/add-topologysegment.yml add-topologysegment-copy.yml
  3. add-topologysegment-copy.yml ファイルを開いて編集します。
  4. ipatopologysegment タスクセクションに以下の変数を設定して、ファイルを調整します。

    • ipaadmin_password 変数は IdM admin のパスワードに設定します。
    • 追加するセグメントのタイプに応じて、suffix 変数を domain または ca のいずれかに設定します。
    • left の変数をレプリカ合意の左ノードに設定する IdM サーバーの名前に設定します。
    • レプリカ合意の適切なノードとなる IdM サーバーの名前に right 変数を設定します。
    • state 変数は present に設定されていることを確認します。

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

    ---
    - name: Playbook to handle topologysegment
      hosts: ipaserver
      become: true
    
      tasks:
    - name: Add topology segment
        ipatopologysegment:
          ipaadmin_password: Secret123
          suffix: domain
          left: server.idm.example.com
          right: replica.idm.example.com
          state: present
  5. ファイルを保存します。
  6. Playbook ファイルとインベントリーファイルを指定して Ansible Playbook を実行します。

    $ ansible-playbook -v -i inventory add-topologysegment-copy.yml

関連情報

  • トポロジー合意、サフィックス、およびセグメントの概念の詳細は、「レプリカ合意、トポロジーサフィックス、およびトポロジーセグメント」を参照してください。
  • ipatopologysegment モジュールを使用する他の Ansible Playbook の例は、以下を参照してください。

    • /usr/share/doc/ansible-freeipa/ ディレクトリーの README-topology.md ファイルこのファイルには ipatopologysegment 変数の定義も含まれます。
    • /usr/share/doc/ansible-freeipa/playbooks/topology ディレクトリー。

14.2. Ansible を使用して複数の IdM レプリカ間でレプリカ合意を存在させる手順

Identity Management (IdM) サーバーに保存されているデータは、レプリカ合意に基づいて複製されます。2 台のサーバーでレプリカ合意が設定されている場合は、データを共有します。レプリカ合意は常に双方向のものです。最初のレプリカからサーバーから別のレプリカにデータが複製されるだけでなく、別ののレプリカから最初のレプリカにもデータが複製されます。

本セクションでは、IdM の複数のレプリカのペア間でレプリカ合意が存在することを確認する方法を説明します。

前提条件

  • トポロジー内のレプリカの接続」に記載されている IdM トポロジーを設計するための推奨事項を理解してください。
  • IdM 管理者 のパスワードを知っている。
  • 以下の要件を満たす Ansible コントロールノードを設定している。

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

手順

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

    $ cd ~/MyPlaybooks/
  2. /usr/share/doc/ansible -freeipa/playbooks/topology/ ディレクトリーにある add-topologysegments.yml Ansible Playbook ファイルをコピーします。

    $ cp /usr/share/doc/ansible-freeipa/playbooks/topology/add-topologysegments.yml add-topologysegments-copy.yml
  3. add-topologysegments-copy.yml ファイルを開いて編集します。
  4. vars セクションに以下の変数を設定して、ファイルを調整します。

    • ipaadmin_password 変数は IdM admin のパスワードに設定します。
    • すべてのトポロジーセグメントについて、ipatopology_segments セクションに行を追加し、以下の変数を設定します。

      • 追加するセグメントのタイプに応じて、suffix 変数を domain または ca のいずれかに設定します。
      • left の変数をレプリカ合意の左ノードに設定する IdM サーバーの名前に設定します。
      • レプリカ合意の適切なノードとなる IdM サーバーの名前に right 変数を設定します。
  5. add-topologysegments-copy.yml ファイルの tasks セクションで、state 変数が present に設定されていることを確認します。

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

    ---
    - name: Add topology segments
      hosts: ipaserver
      become: true
      gather_facts: false
    
      vars:
        ipaadmin_password: Secret123
        ipatopology_segments:
        - {suffix: domain, left: replica1.idm.example.com , right: replica2.idm.example.com }
        - {suffix: domain, left: replica2.idm.example.com , right: replica3.idm.example.com }
        - {suffix: domain, left: replica3.idm.example.com , right: replica4.idm.example.com }
        - {suffix: domain+ca, left: replica4.idm.example.com , right: replica1.idm.example.com }
    
      tasks:
      - name: Add topology segment
        ipatopologysegment:
          ipaadmin_password: "{{ ipaadmin_password }}"
          suffix: "{{ item.suffix }}"
          name: "{{ item.name | default(omit) }}"
          left: "{{ item.left }}"
          right: "{{ item.right }}"
          state: present
          #state: absent
          #state: checked
          #state: reinitialized
        loop: "{{ ipatopology_segments | default([]) }}"
  6. ファイルを保存します。
  7. Playbook ファイルとインベントリーファイルを指定して Ansible Playbook を実行します。

    $ ansible-playbook -v -i inventory add-topologysegments-copy.yml

関連情報

  • トポロジー合意、サフィックス、およびセグメントの概念の詳細は、「レプリカ合意、トポロジーサフィックス、およびトポロジーセグメント」を参照してください。
  • ipatopologysegment モジュールを使用する他の Ansible Playbook の例は、以下を参照してください。

    • /usr/share/doc/ansible-freeipa/ ディレクトリーの README-topology.md ファイルこのファイルには ipatopologysegment 変数の定義も含まれます。
    • /usr/share/doc/ansible-freeipa/playbooks/topology ディレクトリー。

14.3. Ansible を使用して 2 つのレプリカ間でレプリカ合意が存在するかどうかの確認

Identity Management (IdM) サーバーに保存されているデータは、レプリカ合意に基づいて複製されます。2 台のサーバーでレプリカ合意が設定されている場合は、データを共有します。レプリカ合意は常に双方向のものです。最初のレプリカからサーバーから別のレプリカにデータが複製されるだけでなく、別ののレプリカから最初のレプリカにもデータが複製されます。

本セクションでは、IdM の複数のレプリカのペア間でレプリカ合意が存在することを確認する方法を説明します。

前提条件

  • トポロジー内のレプリカの接続」に記載されている Identity Management (IdM) トポロジーを設計するための推奨事項を理解してください。
  • IdM 管理者 のパスワードを知っている。
  • 以下の要件を満たす Ansible コントロールノードを設定している。

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

手順

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

    $ cd ~/MyPlaybooks/
  2. /usr/share/doc/ansible -freeipa/playbooks/topology/ ディレクトリーにある check-topologysegments.yml Ansible Playbook ファイルをコピーします。

    $ cp /usr/share/doc/ansible-freeipa/playbooks/topology/check-topologysegments.yml check-topologysegments-copy.yml
  3. check-topologysegments-copy.yml ファイルを開いて編集します。
  4. vars セクションに以下の変数を設定して、ファイルを調整します。

    • ipaadmin_password 変数は IdM admin のパスワードに設定します。
    • すべてのトポロジーセグメントについて、ipatopology_segments セクションに行を追加し、以下の変数を設定します。

      • 追加するセグメントのタイプに応じて、suffix 変数を domain または ca のいずれかに設定します。
      • left の変数をレプリカ合意の左ノードに設定する IdM サーバーの名前に設定します。
      • レプリカ合意の適切なノードとなる IdM サーバーの名前に right 変数を設定します。
  5. check-topologysegments-copy.yml ファイルの tasks セクションで、state 変数が present に設定されていることを確認します。

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

    ---
    - name: Add topology segments
      hosts: ipaserver
      become: true
      gather_facts: false
    
      vars:
        ipaadmin_password: Secret123
        ipatopology_segments:
        - {suffix: domain, left: replica1.idm.example.com, right: replica2.idm.example.com }
        - {suffix: domain, left: replica2.idm.example.com , right: replica3.idm.example.com }
        - {suffix: domain, left: replica3.idm.example.com , right: replica4.idm.example.com }
        - {suffix: domain+ca, left: replica4.idm.example.com , right: replica1.idm.example.com }
    
      tasks:
      - name: Check topology segment
        ipatopologysegment:
          ipaadmin_password: "{{ ipaadmin_password }}"
          suffix: "{{ item.suffix }}"
          name: "{{ item.name | default(omit) }}"
          left: "{{ item.left }}"
          right: "{{ item.right }}"
          state: checked
        loop: "{{ ipatopology_segments | default([]) }}"
  6. ファイルを保存します。
  7. Playbook ファイルとインベントリーファイルを指定して Ansible Playbook を実行します。

    $ ansible-playbook -v -i inventory check-topologysegments-copy.yml

関連情報

  • トポロジー合意、サフィックス、およびセグメントの概念の詳細は、「レプリカ合意、トポロジーサフィックス、およびトポロジーセグメント」を参照してください。
  • ipatopologysegment モジュールを使用する他の Ansible Playbook の例は、以下を参照してください。

    • /usr/share/doc/ansible-freeipa/ ディレクトリーの README-topology.md ファイルこのファイルには ipatopologysegment 変数の定義も含まれます。
    • /usr/share/doc/ansible-freeipa/playbooks/topology ディレクトリー。

14.4. Ansible を使用してトポロジーの接尾辞が IdM に存在することを確認

Identity Management (IdM) のレプリカ合意のコンテキストでは、トポロジーサフィックスはレプリケートされるデータを保存します。IdM は、domainca の 2 種類のトポロジーサフィックスに対応します。それぞれのサフィックスは、個別のバックエンドである個別のレプリケーショントポロジーを表します。レプリカ合意が設定されると、同じタイプのトポロジーサフィックスを 2 つの異なるサーバーに結合します。

domain 接尾辞には、ユーザー、グループ、ポリシーなどのドメイン関連のデータがすべて含まれます。ca 接尾辞には、Certificate System コンポーネントのデータが含まれます。これは認証局 (CA) がインストールされているサーバーにのみ存在します。

本セクションでは、Ansible Playbook を使用して、トポロジーの接尾辞が IdM に存在するようにする方法を説明します。この例では、domain 接尾辞が IdM に存在することを確認する方法を説明します。

前提条件

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

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

手順

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

    $ cd ~/MyPlaybooks/
  2. /usr/share/doc/ansible-freeipa/playbooks/topology/ ディレクトリーにある verify-topologysuffix.yml Ansible Playbook ファイルをコピーします。

    $ cp /usr/share/doc/ansible-freeipa/playbooks/topology/ verify-topologysuffix.yml verify-topologysuffix-copy.yml
  3. Ansible Playbook ファイル verify-topologysuffix-copy.yml を開きます。
  4. ipatopologysuffix セクションに以下の変数を設定して、ファイルを調整します。

    • ipaadmin_password 変数は IdM admin のパスワードに設定します。
    • suffix 変数は domain に設定し ます。ca サフィックスが存在することを確認する場合は、変数を ca に設定します。
    • state 変数が verified に設定されていることを確認します。他のオプションは使用できません。

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

    ---
    - name: Playbook to handle topologysuffix
      hosts: ipaserver
      become: true
    
      tasks:
      - name: Verify topology suffix
        ipatopologysuffix:
          ipaadmin_password: Secret123
          suffix: domain
          state: verified
  5. ファイルを保存します。
  6. Playbook ファイルとインベントリーファイルを指定して Ansible Playbook を実行します。

    $ ansible-playbook -v -i inventory verify-topologysuffix-copy.yml

関連情報

  • トポロジー合意、サフィックス、およびセグメントの概念の詳細は、「レプリカ合意、トポロジーサフィックス、およびトポロジーセグメント」を参照してください。
  • ipatopologysegment モジュールを使用する他の Ansible Playbook の例は、以下を参照してください。

    • /usr/share/doc/ansible-freeipa/ ディレクトリーの README-topology.md ファイルこのファイルには ipatopologysuffix 変数の定義も含まれます。
    • /usr/share/doc/ansible-freeipa/playbooks/topology ディレクトリー。

14.5. Ansible を使用した IdM レプリカの再初期化

レプリカが長期間オフラインである場合や、そのデータベースが破損している場合は、初期化できます。初期化により、更新一覧のデータでレプリカが更新されます。たとえば、バックアップからの権威復元が必要な場合に使用できます。

注記

レプリケーションの更新とは対照的に、レプリカが変更エントリーのみを送信する間、データベース全体を再初期化します。

コマンドを実行するローカルホストは、再初期化されたレプリカです。データの取得元となるレプリカを指定するには、direction オプションを使用します。

本セクションでは、Ansible Playbook を使用して、server.idm.example.com から replica.idm.example.comdomain データを再初期化する方法を説明します。

前提条件

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

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

手順

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

    $ cd ~/MyPlaybooks/
  2. /usr/share/doc/ansible -freeipa/playbooks/topology/ ディレクトリーにある reinitialize-topologysegment.yml Ansible Playbook ファイルをコピーします。

    $ cp /usr/share/doc/ansible-freeipa/playbooks/topology/reinitialize-topologysegment.yml reinitialize-topologysegment-copy.yml
  3. reinitialize-topologysegment-copy.yml ファイルを開いて編集します。
  4. ipatopologysegment セクションに以下の変数を設定して、ファイルを調整します。

    • ipaadmin_password 変数は IdM admin のパスワードに設定します。
    • suffix 変数は domain に設定し ます。ca データを再初期化する場合は、変数を ca に設定します。
    • left の変数をレプリカ合意の左ノードに設定します。
    • レプリカ合意の right なノードに正しい変数を設定します。
    • direction 変数は再初期化されるデータの方向に設定します。left-to-right は、左のノードから適切なノードにデータフローがあることを意味します。
    • state 変数が reinitialized に設定されていることを確認します。

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

      ---
      - name: Playbook to handle topologysegment
        hosts: ipaserver
        become: true
      
        tasks:
        - name: Reinitialize topology segment
          ipatopologysegment:
            ipaadmin_password: Secret123
            suffix: domain
            left: server.idm.example.com
            right: replica.idm.example.com
            direction: left-to-right
            state: reinitialized
  5. ファイルを保存します。
  6. Playbook ファイルとインベントリーファイルを指定して Ansible Playbook を実行します。

    $ ansible-playbook -v -i inventory reinitialize-topologysegment-copy.yml

関連情報

  • トポロジー合意、サフィックス、およびセグメントの概念の詳細は、「レプリカ合意、トポロジーサフィックス、およびトポロジーセグメント」を参照してください。
  • ipatopologysegment モジュールを使用する他の Ansible Playbook の例は、以下を参照してください。

    • /usr/share/doc/ansible-freeipa/ ディレクトリーの README-topology.md ファイルこのファイルには ipatopologysegment 変数の定義も含まれます。
    • /usr/share/doc/ansible-freeipa/playbooks/topology ディレクトリー。

14.6. Ansible を使用して IdM にレプリカ合意がないことを確認する手順

Identity Management (IdM) サーバーに保存されているデータは、レプリカ合意に基づいて複製されます。2 台のサーバーでレプリカ合意が設定されている場合は、データを共有します。レプリカ合意は常に双方向のものです。最初のレプリカからサーバーから別のレプリカにデータが複製されるだけでなく、別ののレプリカから最初のレプリカにもデータが複製されます。

本セクションでは、2 つのレプリカ間でレプリカ合意が IdM に存在しないことを確認する方法を説明します。この例では、domain タイプのレプリカ合意が、replica01.idm.example.comreplica02.idm.example.com 間で存在させないようにする方法を説明します。

前提条件

  • トポロジー内のレプリカの接続」に記載されている IdM トポロジーを設計するための推奨事項を理解してください。
  • IdM 管理者 のパスワードを知っている。
  • 以下の要件を満たす Ansible コントロールノードを設定している。

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

手順

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

    $ cd ~/MyPlaybooks/
  2. /usr/share/doc/ansible -freeipa/playbooks/topology/ ディレクトリーにある delete-topologysegment.yml Ansible Playbook ファイルをコピーします。

    $ cp /usr/share/doc/ansible-freeipa/playbooks/topology/delete-topologysegment.yml delete-topologysegment-copy.yml
  3. delete-topologysegment-copy.yml ファイルを開いて編集します。
  4. ipatopologysegment タスクセクションに以下の変数を設定して、ファイルを調整します。

    • ipaadmin_password 変数は IdM admin のパスワードに設定します。
    • suffix 変数は domain に設定し ます。また、ca データが左右ノードと右のノード間で複製されないようにするには、変数を ca に設定します。
    • left の変数を、レプリカ合意の左ノードである IdM サーバーの名前に設定します。
    • 右側 の変数を、レプリカ合意の右のノードである IdM サーバーの名前に設定します。
    • state 変数は、absent に設定されていることを確認します。

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

    ---
    - name: Playbook to handle topologysegment
      hosts: ipaserver
      become: true
    
      tasks:
    - name: Delete topology segment
        ipatopologysegment:
          ipaadmin_password: Secret123
          suffix: domain
          left: replica01.idm.example.com
          right: replica02.idm.example.com:
          state: absent
  5. ファイルを保存します。
  6. Playbook ファイルとインベントリーファイルを指定して Ansible Playbook を実行します。

    $ ansible-playbook -v -i inventory delete-topologysegment-copy.yml

関連情報

  • トポロジー合意、サフィックス、およびセグメントの概念の詳細は、「レプリカ合意、トポロジーサフィックス、およびトポロジーセグメント」を参照してください。
  • ipatopologysegment モジュールを使用する他の Ansible Playbook の例は、以下を参照してください。

    • /usr/share/doc/ansible-freeipa/ ディレクトリーの README-topology.md ファイルこのファイルには ipatopologysegment 変数の定義も含まれます。
    • /usr/share/doc/ansible-freeipa/playbooks/topology ディレクトリー。

14.7. 関連情報

第15章 Ansible Playbook を使用したホストの管理

Ansible は、システムの設定、ソフトウェアのデプロイ、ローリング更新の実行に使用する自動化ツールです。Ansible には Identity Management (IdM) のサポートが含まれ、Ansible モジュールを使用してホスト管理を自動化できます。

本章では、Ansible Playbook を使用してホストおよびホストエントリーを管理するときに実行される概念および操作について説明します。

15.1. IdM のホスト

Identity Management (IdM) は、以下の ID を管理します。

  • ユーザー
  • サービス
  • ホスト

ホストはマシンを表します。ホストには、IdM LDAP に IdM ID となるエントリーがあります。これは IdM サーバーの 389 Directory Server のインスタンスです。

IdM LDAP のホストエントリーは、その他のホストとドメイン内のサービスとの関係を確立するために使用されます。この関係では、ドメイン内ホストの認可および制御の 委譲 が不可欠な要素です。ホストは、ホストベースのアクセス制御 (HBAC) ルールで使用できます。

IdM ドメインは、共通の ID 情報、共通ポリシー、および共有サービスを使用して、マシン間で共通性を確立します。ドメインのクライアントとしてのドメイン機能に属するマシンです。これは、ドメインが提供するサービスを使用することを意味します。IdM ドメインは、マシン専用の 3 つの主なサービスを提供します。

  • DNS
  • Kerberos
  • 証明書の管理

IdM のホストは、そのホストで実行しているサービスと密接に接続されています。

  • サービスエントリーは、ホストに関連付けられています。
  • ホストには、ホストとサービスの両方の Kerberos プリンシパルが格納されます。

15.2. ホスト登録

本セクションでは、ホストを IdM クライアントとして登録し、登録中および登録後に何が起こるかを説明します。本セクションでは、IdM ホストの登録と、IdM ユーザーの登録を比較します。また、本セクションでは、ホストで利用可能な代替タイプの認証も概説します。

ホストの登録は、以下のように構成されます。

  • IdM LDAP でホストエントリーを作成する - 場合によっては、IdM CLI で ipa host-add コマンド、または同等の IdM Web UI 操作 を使用します。
  • ホストで IdM サービス (System Security Services Daemon (SSSD)、Kerberos、certmonger など) を設定し、ホストを IdM ドメインに参加させる。

2 つのアクションは、個別に実行することも一緒に実行することもできます。

個別に実行すると、異なるレベルの特権を持つ 2 人のユーザー間で 2 つのタスクを分割できます。これは、一括デプロイメントに役立ちます。

ipa-client-install コマンドは、2 つのアクションを一緒に実行できます。コマンドは、そのエントリーがまだ存在していない場合は IdM LDAP にホストエントリーを作成し、そのホストに Kerberos サービスと SSSD サービスの両方を設定します。このコマンドにより、ホストが IdM ドメイン内に移動し、接続先の IdM サーバーを識別できるようになります。IdM が管理する DNS ゾーンにホストが属する場合は、ipa-client-install でホストに DNS レコードも追加します。コマンドはクライアントで実行する必要があります。

15.2.1. ホストの登録に必要なユーザー権限

ホスト登録操作では、権限のないユーザーが不要なマシンを IdM ドメインに追加しないように、認証が必要になります。必要な特権は、次のようないくつかの要因によって異なります。

  • ホストエントリーが ipa-client-install の実行とは別に作成される場合
  • ワンタイムパスワード (OTP) が登録に使用される場合
必要に応じて IdM LDAP にホストエントリーを手動で作成するためのユーザー特権

CLI コマンド ipa host-add または IdM Web UI を使用して、IdM LDAP にホストエントリーを作成するのに必要なユーザー特権は ホストの管理者 です。ホスト管理者 の特権は、IT スペシャリスト ロールから取得できます。

クライアントを IdM ドメインに参加させるためのユーザー特権

ホストは、ipa-client-install コマンドの実行時に IdM クライアントとして設定されます。ipa-client-install コマンドの実行に必要な認証情報のレベルは、以下のような登録シナリオのどれに該当するかによって異なります。

登録後、IdM ホストは、IdM リソースにアクセスできるように、新しいセッションをすべて認証します。IdM サーバーがマシンを信頼し、そのマシンにインストールされているクライアントソフトウェアからの IdM 接続を受け入れるには、マシン認証が必要です。クライアントを認証すると、IdM サーバーはそのリクエストに応答できます。

15.2.2. IdM ホストとユーザーの登録と認証: 比較

IdM のユーザーとホストには、多くの類似点があります。本セクションでは、登録ステージで見られるいくつかの類似点と、デプロイメントステージでの認証に関する類似点を説明します。

  • 登録ステージ (表15.1「ユーザーおよびホストの登録」):

    • 管理者は、ユーザーまたはホストが実際に IdM に参加する前に、ユーザーとホストの LDAP エントリーを作成できます。コマンドは、ステージユーザーの場合は ipa stageuser-add で、ホストの場合は ipa host-add です。
    • ホストで ipa-client-install コマンドを実行すると、キーテーブル (または略してキータブ)、(ある程度ユーザーパスワードに類似する) 対称キーを含むファイルが作成され、ホストが IdM レルムに参加します。同様に、ユーザーはアカウントをアクティベートする際にパスワードを作成するように求められ、IdM レルムに参加します。
    • ユーザーパスワードは、ユーザーのデフォルトの認証方法ですが、キータブはホストのデフォルトの認証方法です。キータブは、ホストのファイルに保存されます。

    表15.1 ユーザーおよびホストの登録

    アクションユーザーホスト

    登録前

    $ ipa stageuser-add user_name [--password]

    $ ipa host-add host_name [--random]

    アカウントのアクティブ化

    $ ipa stageuser-activate user_name

    $ ipa-client install [--password] (ホスト自体で実行する必要があります)

  • デプロイメントステージ (表15.2「ユーザーおよびホストセッションの認証」):

    • ユーザーが新しいセッションを開始すると、ユーザーはパスワードを使用して認証を行います。同様に、切り替え時に、ホストがそのキータブファイルを提示して認証を行います。SSSD (System Security Services Daemon) は、このプロセスをバックグラウンドで管理します。
    • 認証が成功すると、ユーザーまたはホストは、Kerberos チケット発行許諾チケット (TGT) を取得します。
    • 次に、TGT を使用して、特定のサービスの特定のチケットを取得します。

    表15.2 ユーザーおよびホストセッションの認証

     ユーザーホスト

    認証のデフォルト手段

    パスワード

    キータブ

    セッションの開始 (通常のユーザー)

    $ kinit user_name

    [ホストへの切り替え]

    認証成功の結果

    TGT は、特定サービスへのアクセスの取得に使用されます。

    TGT は、特定サービスへのアクセスの取得に使用されます。

TGT およびその他の Kerberos チケットは、サーバーにより定義された Kerberos サービスおよびポリシーの一部として生成されます。Kerberos チケットの最初の付与、Kerberos 認証情報の更新、および Kerberos セッションの破棄もすべて IdM サービスにより自動的に処理されます。

15.2.3. IdM ホストの代替認証オプション

キータブとは別に、IdM は、その他の 2 つのタイプのマシン認証にも対応しています。

  • SSH 鍵。ホストの SSH 公開キーが作成され、ホストエントリーにアップロードされます。そこから、SSSD (System Security Services Daemon) は IdM を ID プロバイダーとして使用し、OpenSSH およびその他のサービスと一緒に機能して、IdM の中央にある公開鍵を参照できます。
  • 機械の証明書。この場合、マシンは IdM サーバーの認証局により発行され、IdM の Directory Server に保存されている SSL 証明書を使用します。次に、証明書はマシンに送信され、サーバーに対する認証時に提示されます。クライアントでは、証明書は certmonger というサービスにより管理されます。

15.3. Ansible Playbook を使用した FQDN を使用した IdM ホストエントリーの存在の確認

本セクションでは、Ansible Playbook を使用して、Identity Management (IdM) にホストエントリーが存在することを確認する方法を説明します。ホストエントリーは、完全修飾ドメイン名 (FQDN) によってのみ定義されます。

以下の条件のいずれかが当てはまる場合は、ホストの FQDN 名を指定するだけで十分です。

  • IdM サーバーが DNS を管理するよう設定されていません。
  • ホストには静的 IP アドレスがないか、またはホストの設定時に IP アドレスが不明な状態です。FQDN によってのみ定義されたホストを追加すると、基本的に IdM DNS サービスにプレースホルダーエントリーが作成されます。たとえば、ラップトップは IdM クライアントとして事前設定されている場合がありますが、設定時には IP アドレスがありません。DNS サービスがレコードを動的に更新すると、ホストの現在の IP アドレスが検出され、DNS レコードが更新されます。
注記

Ansible を使用しないと、ipa host-add コマンドを使用してホストエントリーが IdM に作成されます。ホストを IdM に追加する結果は、IdM に存在するホストの状態です。Ansible の復元により、Ansible を使用してホストを IdM に追加するには、ホストの状態を present: state: present として定義する Playbook を作成する必要があります。

前提条件

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

手順

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

    [ipaserver]
    server.idm.example.com
  2. IdM に存在するホストの FQDN で Ansible Playbook ファイルを作成します。この手順を単純化するには、/usr/share/doc/ansible-freeipa/playbooks/host/add-host.yml ファイルのサンプルをコピーして変更できます。

    ---
    - name: Host present
      hosts: ipaserver
      become: true
    
      tasks:
      - name: Host host01.idm.example.com present
        ipahost:
          ipaadmin_password: MySecret123
          name: host01.idm.example.com
          state: present
          force: yes
  3. Playbook を実行します。

    $ ansible-playbook -v -i path_to_inventory_directory/inventory.file path_to_playbooks_directory/ensure-host-is-present.yml
注記

この手順では、IdM LDAP サーバーにホストエントリーを作成しますが、ホストを IdM Kerberos レルムに登録しません。そのためには、ホストを IdM クライアントとしてデプロイする必要があります。詳細は「Ansible Playbook で Identity Management クライアントのインストール」を参照してください。

検証手順

  1. admin として IdM サーバーにログインします。

    $ ssh admin@server.idm.example.com
    Password:
  2. ipa host-show コマンドを入力し、ホストの名前を指定します。

    $ ipa host-show host01.idm.example.com
      Host name: host01.idm.example.com
      Principal name: host/host01.idm.example.com@IDM.EXAMPLE.COM
      Principal alias: host/host01.idm.example.com@IDM.EXAMPLE.COM
      Password: False
      Keytab: False
      Managed by: host01.idm.example.com

この出力では、host01.idm.example.com が IdM に存在することを確認します。

15.4. Ansible Playbook を使用して DNS 情報を含む IdM ホストエントリーが存在することを確認する

本セクションでは、Ansible Playbook を使用して、Identity Management (IdM) にホストエントリーが存在することを確認する方法を説明します。ホストエントリーは、完全修飾ドメイン名 (FQDN) およびそれらの IP アドレスで定義されます。

注記

Ansible を使用しないと、ipa host-add コマンドを使用してホストエントリーが IdM に作成されます。ホストを IdM に追加する結果は、IdM に存在するホストの状態です。Ansible の復元により、Ansible を使用してホストを IdM に追加するには、ホストの状態を present: state: present として定義する Playbook を作成する必要があります。

前提条件

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

手順

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

    [ipaserver]
    server.idm.example.com
  2. IdM に存在するホストの 完全修飾ドメイン名 (FQDN) で Ansible Playbook ファイルを作成します。また、IdM サーバーが DNS を管理するように設定され、ホストの IP アドレスが分かっている場合は、ip_address パラメーターの値を指定します。ホストが DNS リソースレコードに存在するには、IP アドレスが必要です。この手順を単純化するには、/usr/share/doc/ansible-freeipa/playbooks/host/host-present.yml ファイルのサンプルをコピーして変更できます。また、その他の追加情報を含めることもできます。

    ---
    - name: Host present
      hosts: ipaserver
      become: true
    
      tasks:
      - name: Ensure host01.idm.example.com is present
        ipahost:
          ipaadmin_password: MySecret123
          name: host01.idm.example.com
          description: Example host
          ip_address: 192.168.0.123
          locality: Lab
          ns_host_location: Lab
          ns_os_version: CentOS 7
          ns_hardware_platform: Lenovo T61
          mac_address:
          - "08:00:27:E3:B1:2D"
          - "52:54:00:BD:97:1E"
          state: present
  3. Playbook を実行します。

    $ ansible-playbook -v -i path_to_inventory_directory/inventory.file path_to_playbooks_directory/ensure-host-is-present.yml
注記

この手順では、IdM LDAP サーバーにホストエントリーを作成しますが、ホストを IdM Kerberos レルムに登録しません。そのためには、ホストを IdM クライアントとしてデプロイする必要があります。詳細は「Ansible Playbook で Identity Management クライアントのインストール」を参照してください。

検証手順

  1. admin として IdM サーバーにログインします。

    $ ssh admin@server.idm.example.com
    Password:
  2. ipa host-show コマンドを入力し、ホストの名前を指定します。

    $ ipa host-show host01.idm.example.com
      Host name: host01.idm.example.com
      Description: Example host
      Locality: Lab
      Location: Lab
      Platform: Lenovo T61
      Operating system: CentOS 7
      Principal name: host/host01.idm.example.com@IDM.EXAMPLE.COM
      Principal alias: host/host01.idm.example.com@IDM.EXAMPLE.COM
      MAC address: 08:00:27:E3:B1:2D, 52:54:00:BD:97:1E
      Password: False
      Keytab: False
      Managed by: host01.idm.example.com

この出力では、host01.idm.example.com が IdM に存在することを確認します。

15.5. Ansible Playbook を使用して無作為のパスワードで複数の IdM ホストエントリーが存在することを確認する

ipahost モジュールを使用すると、システム管理者は、単一の Ansible タスクのみを使用して、IdM に複数のホストエントリーが存在するか、または存在しないかを確認できます。本セクションでは、完全修飾ドメイン名 (FQDN) によってのみ定義される複数のホストエントリーが存在することを確認する方法を説明します。Ansible Playbook を実行すると、ホストのパスワードが無作為に生成されます。

注記

Ansible を使用しないと、ipa host-add コマンドを使用してホストエントリーが IdM に作成されます。ホストを IdM に追加する結果は、IdM に存在するホストの状態です。Ansible の復元により、Ansible を使用してホストを IdM に追加するには、ホストの状態を present: state: present として定義する Playbook を作成する必要があります。

前提条件

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

手順

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

    [ipaserver]
    server.idm.example.com
  2. IdM に存在するホストの 完全修飾ドメイン名 (FQDN) で Ansible Playbook ファイルを作成します。Ansible Playbook が IdM にホストがすでに存在し、update_passwordon_create に制限されている場合でも、各ホストの無作為なパスワード を生成するようにするには、random: yes および force: yes オプションを追加します。この手順を簡素化するには、/usr/share/doc/ansible-freeipa/README-host.md Markdown ファイルからサンプルをコピーして変更できます。

    ---
    - name: Ensure hosts with random password
      hosts: ipaserver
      become: true
    
      tasks:
      - name: Hosts host01.idm.example.com and host02.idm.example.com present with random passwords
        ipahost:
          ipaadmin_password: MySecret123
          hosts:
          - name: host01.idm.example.com
            random: yes
            force: yes
          - name: host02.idm.example.com
            random: yes
            force: yes
        register: ipahost
  3. Playbook を実行します。

    $ ansible-playbook -v -i path_to_inventory_directory/inventory.file path_to_playbooks_directory/ensure-hosts-are-present.yml
    [...]
    TASK [Hosts host01.idm.example.com and host02.idm.example.com present with random passwords]
    changed: [r8server.idm.example.com] => {"changed": true, "host": {"host01.idm.example.com": {"randompassword": "0HoIRvjUdH0Ycbf6uYdWTxH"}, "host02.idm.example.com": {"randompassword": "5VdLgrf3wvojmACdHC3uA3s"}}}
注記

無作為にワンタイムパスワード (OTP) を使用して IdM クライアントとしてホストをデプロイするには、「Ansible Playbook を使用した IdM クライアント登録の認証オプション」または「ワンタイムパスワードを使用したクライアントのインストール: 対話型インストール」を参照してください。

検証手順

  1. admin として IdM サーバーにログインします。

    $ ssh admin@server.idm.example.com
    Password:
  2. ipa host-show コマンドを入力し、ホストのいずれかの名前を指定します。

    $ ipa host-show host01.idm.example.com
      Host name: host01.idm.example.com
      Password: True
      Keytab: False
      Managed by: host01.idm.example.com

この出力では、host01.idm.example.com がランダムパスワードで IdM に存在することを確認します。

15.6. Ansible Playbook を使用して、複数の IP アドレスを持つ IdM ホストエントリーが存在することを確認する

本セクションでは、Ansible Playbook を使用して、Identity Management (IdM) にホストエントリーが存在することを確認する方法を説明します。ホストエントリーは、完全修飾ドメイン名 (FQDN) と複数の IP アドレスで定義されます。

注記

Ansible ipahost モジュールは、ipa host ユーティリティーとは対照的に、ホストの IPv4 および IPv6 アドレスが複数存在するか、または存在しないことを確認します。ipa host-mod コマンドは IP アドレスを処理できません。

前提条件

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

手順

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

    [ipaserver]
    server.idm.example.com
  2. Ansible Playbook ファイルを作成します。ipahost 変数の 名前 として、確認する IdM に存在するホストの 完全修飾ドメイン名 (FQDN) を指定します。- ip_address 構文を使用して、個別の行に複数の IPv4 および IPv6 ip_address 値を指定します。この手順を単純化するには、/usr/share/doc/ansible-freeipa/playbooks/host/host-member-ipaddresses-present.yml ファイルのサンプルをコピーして変更できます。追加情報を含めることもできます。

    ---
    - name: Host member IP addresses present
      hosts: ipaserver
      become: true
    
      tasks:
      - name: Ensure host101.example.com IP addresses present
        ipahost:
          ipaadmin_password: MySecret123
          name: host01.idm.example.com
          ip_address:
          - 192.168.0.123
          - fe80::20c:29ff:fe02:a1b3
          - 192.168.0.124
          - fe80::20c:29ff:fe02:a1b4
          force: yes
  3. Playbook を実行します。

    $ ansible-playbook -v -i path_to_inventory_directory/inventory.file path_to_playbooks_directory/ensure-host-with-multiple-IP-addreses-is-present.yml
注記

この手順では、IdM LDAP サーバーにホストエントリーを作成しますが、ホストを IdM Kerberos レルムに登録しません。そのためには、ホストを IdM クライアントとしてデプロイする必要があります。詳細は「Ansible Playbook で Identity Management クライアントのインストール」を参照してください。

検証手順

  1. admin として IdM サーバーにログインします。

    $ ssh admin@server.idm.example.com
    Password:
  2. ipa host-show コマンドを入力し、ホストの名前を指定します。

    $ ipa host-show host01.idm.example.com
      Principal name: host/host01.idm.example.com@IDM.EXAMPLE.COM
      Principal alias: host/host01.idm.example.com@IDM.EXAMPLE.COM
      Password: False
      Keytab: False
      Managed by: host01.idm.example.com

    この出力では、host01.idm.example.com が IdM に存在することを確認します。

  3. IdM DNS レコードにホストの複数の IP アドレスが存在することを確認するには、ipa dnsrecord-show コマンドを入力し、以下の情報を指定します。

    • IdM ドメインの名前
    • ホストの名前

      $ ipa dnsrecord-show idm.example.com host01
      [...]
        Record name: host01
        A record: 192.168.0.123, 192.168.0.124
        AAAA record: fe80::20c:29ff:fe02:a1b3, fe80::20c:29ff:fe02:a1b4

    この出力では、Playbook で指定された IPv4 アドレスおよび IPv6 アドレスがすべて host01.idm.example.com ホストエントリーに正しく関連付けられていることを確認します。

15.7. Ansible Playbook を使用して IdM ホストエントリーがないことを確認する

本セクションでは、Ansible Playbook を使用して、Identity Management (IdM) にホストエントリーがないことを確認する方法を説明します。

前提条件

  • IdM 管理者認証情報

手順

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

    [ipaserver]
    server.idm.example.com
  2. IdM がないホストの 完全修飾ドメイン名 (FQDN) で Ansible Playbook ファイルを作成します。IdM ドメインに DNS が統合されている場合は、updatedns: yes オプションを使用して、あらゆる種類のホストに関連するレコードを DNS から削除します。

    この手順を単純化するには、/usr/share/doc/ansible-freeipa/playbooks/host/delete-host.yml ファイルのサンプルをコピーして変更できます。

    ---
    - name: Host absent
      hosts: ipaserver
      become: true
    
      tasks:
      - name: Host host01.idm.example.com absent
        ipahost:
          ipaadmin_password: MySecret123
          name: host01.idm.example.com
          updatedns: yes
          state: absent
  3. Playbook を実行します。

    $ ansible-playbook -v -i path_to_inventory_directory/inventory.file path_to_playbooks_directory/ensure-host-absent.yml
注記

この手順の結果は以下のようになります。

  • IdM Kerberos レルムにホストが存在していない。
  • IdM LDAP サーバーにホストエントリーが存在しません。

SSSD (System Security Services Daemon) などのシステムサービスの特定の IdM 設定をクライアントホスト自体から削除するには、クライアントで ipa-client-install --uninstall コマンドを実行する必要があります。詳細は「IdM クライアントのアンインストール」を参照してください。

検証手順

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

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

    $ ipa host-show host01.idm.example.com
    ipa: ERROR: host01.idm.example.com: host not found

この出力は、ホストが IdM に存在しないことを確認します。

関連情報

  • /usr/share/doc/ansible-freeipa/README-host.md Markdown ファイルにホストが存在し、存在し、存在しないようにするために、ipahost 変数の定義とサンプルの Ansible Playbook を確認することができます。
  • 追加の Playbook は /usr/share/doc/ansible-freeipa/playbooks/host ディレクトリーにあります。

第16章 Ansible Playbook を使用したホストグループの管理

本章では、Identity Management(IdM)のホストグループ を紹介し、Ansible を使用して、Identity Management(IdM)でホストグループに関連する以下の操作を実行する方法を説明します。

16.1. IdM のホストグループ

IdM ホストグループを使用すると、重要な管理タスク (特にアクセス制御) を一元管理できます。

ホストグループの定義

ホストグループは、一般的なアクセス制御ルールやその他の特性を持つ IdM ホストセットが含まれるエンティティーです。たとえば、企業の部門、物理的な場所、またはアクセス制御要件に基づいてホストグループを定義できます。

IdM のホストグループには以下が含まれます。

  • IdM サーバーおよびクライアント
  • その他の IdM ホストグループ

デフォルトで作成されたホストグループ

デフォルトでは、IdM サーバーは、全 IdM サーバーホストのホストグループ ipaservers を作成します。

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

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

16.2. Ansible Playbook を使用した IdM ホストグループの存在の確認

本セクションでは、Ansible Playbook を使用して、Identity Management (IdM) にホストグループが存在することを確認する方法を説明します。

注記

Ansible を使用しないと、ipa hostgroup-add コマンドを使用して、ホストグループエントリーが IdM に作成されます。ホストグループを IdM に追加すると、IdM に存在するホストグループの状態になります。Ansible はべき等性に依存しているため、Ansible を使用してホストグループを IdM に追加するには、ホストグループの状態を present: state: present として定義する Playbook を作成する必要があります。

前提条件

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

手順

  1. inventory.file などのインベントリーファイル を作成し、ターゲットに設定する IdM サーバーの一覧と共に ipaserver を定義します。

    [ipaserver]
    server.idm.example.com
  2. 必要なホストグループ情報を使用して Ansible Playbook ファイルを作成します。たとえば、databases という名前のホストグループが存在することを確認するには、- ipahostgroup タスクで 名前: データベース を指定します。この手順を単純化するには、/usr/share/doc/ansible-freeipa/playbooks/user/ensure-hostgroup-is-present.yml ファイルのサンプルをコピーして変更できます。

    ---
    - name: Playbook to handle hostgroups
      hosts: ipaserver
      become: true
    
      tasks:
      # Ensure host-group databases is present
      - ipahostgroup:
          ipaadmin_password: MySecret123
          name: databases
          state: present

    Playbook で state: present は、すでに存在しない限り、ホストグループを IdM に追加する要求を示します。

  3. Playbook を実行します。

    $ ansible-playbook -v -i path_to_inventory_directory/inventory.file path_to_playbooks_directory/ensure-hostgroup-is-present.yml

検証手順

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

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

    $ kinit admin
    Password for admin@IDM.EXAMPLE.COM:
  3. IdM に存在するホストグループに関する情報を表示します。

    $ ipa hostgroup-show databases
      Host-group: databases

データベース ホストグループが IdM に存在する。

16.3. Ansible Playbook を使用して IdM ホストグループにホストが存在することを確認する

本セクションでは、Ansible Playbook を使用して、Identity Management (IdM) のホストグループにホストが存在することを確認する方法を説明します。

前提条件

手順

  1. inventory.file などのインベントリーファイル を作成し、ターゲットに設定する IdM サーバーの一覧と共に ipaserver を定義します。

    [ipaserver]
    server.idm.example.com
  2. 必要なホスト情報を使用して Ansible Playbook ファイルを作成します。ipahostgroup 変数の name パラメーターを使用してホストグループの名前を指定します。ipahostgroup 変数の host パラメーターを使用してホストの名前を指定します。この手順を単純化するには、/usr/share/doc/ansible-freeipa/playbooks/hostgroup/ensure-hosts-and-hostgroups-are-present-in-hostgroup.yml ファイルのサンプルをコピーして変更することができます。

    ---
    - name: Playbook to handle hostgroups
      hosts: ipaserver
      become: true
    
      tasks:
      # Ensure host-group databases is present
      - ipahostgroup:
          ipaadmin_password: MySecret123
          name: databases
          host:
          - db.idm.example.com
          action: member

    この Playbook は、db.idm.example.com ホストを データベース ホストグループに追加します。action: member 行は、Playbook が実行されると、データベース グループ自体の追加を試行しないことを示します。代わりに、db.idm.example.comデータベース に追加しようとします。

  3. Playbook を実行します。

    $ ansible-playbook -v -i path_to_inventory_directory/inventory.file path_to_playbooks_directory/ensure-hosts-or-hostgroups-are-present-in-hostgroup.yml

検証手順

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

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

    $ kinit admin
    Password for admin@IDM.EXAMPLE.COM:
  3. ホストグループに関する情報を表示して、どのホストが存在するかを確認します。

    $ ipa hostgroup-show databases
      Host-group: databases
      Member hosts: db.idm.example.com

db.idm.example.com ホストは、データベース ホストグループのメンバーとして存在します。

16.4. Ansible Playbook を使用した IdM ホストグループのネスト化

本セクションでは、Ansible Playbook を使用して、Identity Management (IdM) ホストグループにネスト化されたホストグループが存在することを確認する方法を説明します。

前提条件

手順

  1. inventory.file などのインベントリーファイル を作成し、ターゲットに設定する IdM サーバーの一覧と共に ipaserver を定義します。

    [ipaserver]
    server.idm.example.com
  2. 必要なホストグループ情報を使用して Ansible Playbook ファイルを作成します。ネストされたホストグループ A が、Ansible Playbook のホストグループ B に存在することを確認するには、name 変数を使用してホストグループ B の名前 - ipahostgroup 変数のいずれかを指定します。hostgroup 変数でネスト化されたホストグループ A の名前を指定します。この手順を単純化するには、/usr/share/doc/ansible-freeipa/playbooks/hostgroup/ensure-hosts-and-hostgroups-are-present-in-hostgroup.yml ファイルのサンプルをコピーして変更することができます。

    ---
    - name: Playbook to handle hostgroups
      hosts: ipaserver
      become: true
    
      tasks:
      # Ensure hosts and hostgroups are present in existing databases hostgroup
      - ipahostgroup:
          ipaadmin_password: MySecret123
          name: databases
          hostgroup:
          - mysql-server
          - oracle-server
          action: member

    この Ansible Playbook は、データベース ホストグループに myqsl-server および oracle-server ホストグループが存在することを確認します。action: member 行は、Playbook が実行されると、データベース グループ自体を IdM に追加しようとはしません。

  3. Playbook を実行します。

    $ ansible-playbook -v -i path_to_inventory_directory/inventory.file path_to_playbooks_directory/ensure-hosts-or-hostgroups-are-present-in-hostgroup.yml

検証手順

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

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

    $ kinit admin
    Password for admin@IDM.EXAMPLE.COM:
  3. ネスト化されたホストグループが存在するホストグループに関する情報を表示します。

    $ ipa hostgroup-show databases
      Host-group: databases
      Member hosts: db.idm.example.com
      Member host-groups: mysql-server, oracle-server

mysql-server および oracle-server ホストグループは、databases ホストグループに存在します。

16.5. Ansible Playbook を使用して IdM ホストグループにメンバーマネージャーを存在させる手順

以下の手順では、Ansible Playbook を使用して、IdM ホストおよびホストグループにメンバーマネージャーを存在させる方法を説明します。

前提条件

  • IdM 管理者パスワードが分かっている。
  • Ansible コントローラーに ansible-freeipa パッケージがインストールされている。
  • メンバーマネージャーとして追加するホストまたはホストグループの名前と、管理するホストグループ名が必要です。

手順

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

    [ipaserver]
    server.idm.example.com
  2. 必要なホストおよびホストグループ情報を使用して Ansible Playbook ファイルを作成します。

    ---
    
    - name: Playbook to handle host group membership management
      hosts: ipaserver
      become: true
    
      tasks:
      - name: Ensure member manager user example_member is present for group_name
          ipahostgroup:
            ipaadmin_password: MySecret123
            name: group_name
            membermanager_user: example_member
    
      - name: Ensure member manager group project_admins is present for group_name
          ipahostgroup:
            ipaadmin_password: MySecret123
            name: group_name
            membermanager_group: project_admins
  3. Playbook を実行します。

    $ ansible-playbook -v -i path_to_inventory_directory/inventory.file path_to_playbooks_directory/add-member-managers-host-groups.yml

検証手順

ipa group-show コマンドを使用して group_name グループのメンバーマネージャーとして example_memberproject_admins が含まれていることを確認できます。

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

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

    ipaserver]$ ipa hostgroup-show group_name
      Host-group: group_name
      Member hosts: server.idm.example.com
      Member host-groups: testhostgroup2
      Membership managed by groups: project_admins
      Membership managed by users: example_member

関連情報

  • ipa hostgroup-add-member-manager --help を参照してください。
  • ipa の man ページを参照してください。

16.6. Ansible Playbook を使用して IdM ホストグループにホストを存在させないようにする方法

本セクションでは、Ansible Playbook を使用して、Identity Management (IdM) のホストグループにホストがないことを確認する方法を説明します。

前提条件

手順

  1. inventory.file などのインベントリーファイル を作成し、ターゲットに設定する IdM サーバーの一覧と共に ipaserver を定義します。

    [ipaserver]
    server.idm.example.com
  2. 必要なホストおよびホストグループ情報を使用して Ansible Playbook ファイルを作成します。ipahostgroup 変数の name パラメーターを使用してホストグループの名前を指定します。ipahostgroup 変数の host パラメーターを使用することを確認するホストグループがないホストの名前を指定します。この手順を単純化するには、/usr/share/doc/ansible-freeipa/playbooks/hostgroup/ensure-hosts-and-hostgroups-are-absent-in-hostgroup.yml ファイルのサンプルをコピーして変更することができます。

    ---
    - name: Playbook to handle hostgroups
      hosts: ipaserver
      become: true
    
      tasks:
      # Ensure host-group databases is absent
      - ipahostgroup:
          ipaadmin_password: MySecret123
          name: databases
          host:
          - db.idm.example.com
          action: member
          state: absent

    この Playbook は、データベース ホストグループから db.idm.example.com ホストがないことを確認します。action: member 行は、Playbook が実行されると、データベース グループ自体の削除を試行しないことを示します。

  3. Playbook を実行します。

    $ ansible-playbook -v -i path_to_inventory_directory/inventory.file path_to_playbooks_directory/ensure-hosts-or-hostgroups-are-absent-in-hostgroup.yml

検証手順

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

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

    $ kinit admin
    Password for admin@IDM.EXAMPLE.COM:
  3. ホストグループと、そのホストグループに含まれるホストに関する情報を表示します。

    $ ipa hostgroup-show databases
      Host-group: databases
      Member host-groups: mysql-server, oracle-server

db.idm.example.com ホストは データベース ホストグループに存在しません。

16.7. Ansible Playbook を使用して IdM ホストグループからネスト化されたホストグループがないことを確認する

本セクションでは、Ansible Playbook を使用して、Identity Management (IdM) の外部ホストグループからネスト化されたホストグループがないことを確認する方法を説明します。

前提条件

手順

  1. inventory.file などのインベントリーファイル を作成し、ターゲットに設定する IdM サーバーの一覧と共に ipaserver を定義します。

    [ipaserver]
    server.idm.example.com
  2. 必要なホストグループ情報を使用して Ansible Playbook ファイルを作成します。- ipahostgroup 変数で、name 変数を使用して、外部ホストグループの名前を指定します。hostgroup 変数でネスト化されたホストグループの名前を指定します。この手順を単純化するには、/usr/share/doc/ansible-freeipa/playbooks/hostgroup/ensure-hosts-and-hostgroups-are-absent-in-hostgroup.yml ファイルのサンプルをコピーして変更することができます。

    ---
    - name: Playbook to handle hostgroups
      hosts: ipaserver
      become: true
    
      tasks:
      # Ensure hosts and hostgroups are absent in existing databases hostgroup
      - ipahostgroup:
          ipaadmin_password: MySecret123
          name: databases
          hostgroup:
          - mysql-server
          - oracle-server
          action: member
          state: absent

    この Playbook は、mysql-server および oracle-server ホストグループが データベース ホストグループにないことを確認します。action: member 行は、Playbook が実行されると、データベース グループ自体が IdM から削除されるように試行されません。

  3. Playbook を実行します。

    $ ansible-playbook -v -i path_to_inventory_directory/inventory.file path_to_playbooks_directory/ensure-hosts-or-hostgroups-are-absent-in-hostgroup.yml

検証手順

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

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

    $ kinit admin
    Password for admin@IDM.EXAMPLE.COM:
  3. ネスト化されたホストグループが存在しないホストグループに関する情報を表示します。

    $ ipa hostgroup-show databases
      Host-group: databases

この出力では、mysql-server および oracle-server のネスト化されたホストグループが、外部 databases のホストグループにないことを確認します。

16.8. Ansible Playbook を使用して IdM ホストグループを存在させないようにする方法

本セクションでは、Ansible Playbook を使用して、Identity Management (IdM) にホストグループを存在させないようにする方法を説明します。

注記

Ansible を使用しないと、ipa hostgroup-del コマンドを使用して、ホストグループエントリーが IdM から削除されます。IdM からホストグループを削除する結果は、IdM に存在しないホストグループの状態です。Ansible はべき等性に依存しているため、Ansible を使用して IdM からホストグループを削除するには、ホストグループの状態を absent: state: absent として定義する Playbook を作成する必要があります。

前提条件

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

手順

  1. inventory.file などのインベントリーファイル を作成し、ターゲットに設定する IdM サーバーの一覧と共に ipaserver を定義します。

    [ipaserver]
    server.idm.example.com
  2. 必要なホストグループ情報を使用して Ansible Playbook ファイルを作成します。この手順を単純化するには、/usr/share/doc/ansible-freeipa/playbooks/user/ensure-hostgroup-is-absent.yml ファイルのサンプルをコピーして変更できます。

    ---
    - name: Playbook to handle hostgroups
      hosts: ipaserver
      become: true
    
      tasks:
      - Ensure host-group databases is absent
        ipahostgroup:
          ipaadmin_password: MySecret123
          name: databases
          state: absent

    この Playbook は、IdM からの データベース ホストグループがないことを確認します。state: absent は、削除しない限り、IdM からホストグループを削除する要求を意味します。

  3. Playbook を実行します。

    $ ansible-playbook -v -i path_to_inventory_directory/inventory.file path_to_playbooks_directory/ensure-hostgroup-is-absent.yml

検証手順

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

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

    $ kinit admin
    Password for admin@IDM.EXAMPLE.COM:
  3. 確実に見つからないホストグループに関する情報を表示します。

    $ ipa hostgroup-show databases
    ipa: ERROR: databases: host group not found

databases ホストグループが IdM に存在しません。

16.9. Ansible Playbook を使用して IdM ホストグループからホストを存在させないようにする方法

以下の手順では、Ansible Playbook を使用して、IdM ホストおよびホストグループにメンバーマネージャーを存在させないようにする方法を説明します。

前提条件

  • IdM 管理者パスワードが分かっている。
  • Ansible コントローラーに ansible-freeipa パッケージがインストールされている。
  • メンバーマネージャーから削除するユーザーまたはユーザーグループの名前と、管理するホストグループの名前が必要です。

手順

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

    [ipaserver]
    server.idm.example.com
  2. 必要なホストおよびホストグループ情報を使用して Ansible Playbook ファイルを作成します。

    ---
    
    - name: Playbook to handle host group membership management
      hosts: ipaserver
      become: true
    
      tasks:
      - name: Ensure member manager host and host group members are absent for group_name
        ipahostgroup:
          ipaadmin_password: MySecret123
          name: group_name
          membermanager_user: example_member
          membermanager_group: project_admins
          action: member
          state: absent
  3. Playbook を実行します。

    $ ansible-playbook -v -i path_to_inventory_directory/inventory.file path_to_playbooks_directory/ensure-member-managers-host-groups-are-absent.yml

検証手順

ipa group-show コマンドを使用して、group_name グループに example_member または project_admins がメンバーマネージャーとして含まれているかどうかを確認できます。

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

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

    ipaserver]$ ipa hostgroup-show group_name
      Host-group: group_name
      Member hosts: server.idm.example.com
      Member host-groups: testhostgroup2

関連情報

  • ipa hostgroup-add-member-manager --help を参照してください。
  • ipa の man ページを参照してください。

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

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

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

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

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

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

注記

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

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

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

属性説明

Max lifetime

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

Max lifetime = 90

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

Min lifetime

パスワード変更操作間で渡す必要のある最小時間 (時間)。

Min lifetime = 1

ユーザーがパスワードを変更したら、再度変更する前に少なくとも 1 時間待機する必要があります。

履歴サイズ

保存される以前のパスワードの数。ユーザーは、パスワード履歴からパスワードを再利用できませんが、保存されていない古いパスワードを再利用できます。

History size = 0

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

文字クラス

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

* 大文字

* 小文字

* Digits

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

* 他の UTF-8 文字

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

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

* Secret111 には、大文字、小文字、数字、および -1 ペナルティの 2 つの文字クラスがあります。1 を 繰り返し使用できます。

Character classes = 0

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

この表の下にある 重要 の注記も参照してください。

Min length

パスワードの最小文字数。

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

Min length = 8

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

Max failures

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

Max failures = 6

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

Failure reset interval

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

Failure reset interval = 60

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

ロックアウト期間

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

Lockout duration = 600

アカウントがロックされているユーザーは、10 分間ログインできません。

重要

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

17.3. Ansible Playbook を使用して IdM にパスワードポリシーが存在することを確認する

本セクションでは、Ansible Playbook を使用して、Identity Management (IdM) にパスワードポリシーが存在することを確認する方法を説明します。

IdM におけるデフォルトの global_policy パスワードポリシーでは、パスワード内の異なる文字クラスの数は 0 に設定されます。履歴サイズも 0 に設定されます。

以下の手順に従って、Ansible Playbook を使用して、IdM グループにより強力なパスワードポリシーを適用します。

注記

IdM グループのパスワードポリシーのみを定義できます。個々のユーザーのパスワードポリシーを定義することはできません。

前提条件

  • Ansible コントローラーに ansible-freeipa パッケージがインストールされている。
  • IdM 管理者パスワードが分かっている。
  • IdM にパスワードポリシーが存在することを確認するグループ。

手順

  1. inventory.file などのインベントリーファイルを作成し、[ipaserver] セクションに IdM サーバーの FQDN を定義します。

    [ipaserver]
    server.idm.example.com
  2. 存在するパスワードポリシーを定義する Ansible Playbook ファイルを作成します。この手順を単純化するには、/usr/share/doc/ansible-freeipa/playbooks/pwpolicy/pwpolicy_present.yml ファイルの例をコピーして変更します。

    ---
    - name: Tests
      hosts: ipaserver
      become: true
    
      tasks:
      - name: Ensure presence of pwpolicy for group ops
        ipapwpolicy:
          ipaadmin_password: MySecret123
          name: ops
          minlife: 7
          maxlife: 49
          history: 5
          priority: 1
          lockouttime: 300
          minlength: 8
          minclasses: 4
          maxfail: 3
          failinterval: 5

    個別の変数の意味は、「パスワードポリシーの属性」を参照してください。

  3. Playbook を実行します。

    $ ansible-playbook -v -i path_to_inventory_directory/inventory.file path_to_playbooks_directory_/new_pwpolicy_present.yml

Ansible Playbook を使用して、ops グループのパスワードポリシーが IdM に存在することを確認している。

重要

ops パスワードポリシーの優先度は 1に設定され、global_policy パスワードポリシーには優先度が設定されません。このため、ops ポリシーは ops グループの global_policy に自動的に置き換えられ、即座に実施されます。

global_policy は、ユーザーにポリシーが設定されていないとフォールバックポリシーとして機能し、そのポリシーよりも優先することはできません。

関連情報

  • Ansible を使用して IdM でパスワードポリシーを定義する方法および Playbook 変数の詳細は、/usr/share/doc/ansible-freeipa/ ディレクトリーにある README-pwpolicy.md Markdown ファイルを参照してください。
  • IdM でパスワードポリシーの優先度がどのように機能するかの詳細は、RHEL 7 ドキュメントの「パスワードポリシーの優先度」を参照してください。

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

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

--maxrepeat オプション
新しいパスワードで許可される同一文字の最大数を指定します。
--maxsequence オプション
新規パスワード内の単調増加文字シーケンスの最大長を指定します。このようなシーケンスの例は 12345 または fedcb です。このようなほとんどのパスワードは単純チェックを渡しません。唯一の例外は、シーケンスがパスワードのマイナー部分のみである場合です。
--dictcheck オプション
ゼロ以外は、変更可能なパスワードをチェックし、ディクショナリー内の単語と一致します。現在 libpwquality は cracklib ライブラリーを使用してディクショナリーチェックを実行します。
--usercheck オプション
ゼロ以外は、変更可能なパスワードに、何らかの形式でユーザー名が含まれているかどうかを確認します。ユーザー名は 3 文字未満です。

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

注記

RHEL 7 および RHEL 8 サーバーを使用する混在環境では、RHEL 8.4 以降で実行しているサーバーに対してのみ、追加のパスワードポリシー設定を実施することができます。

その他のリソース:

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

本セクションでは、Identity Management(IdM)で追加のパスワードポリシーオプションを適用する方法を説明します。この例では、新しいパスワードにユーザー固有のユーザー名が含まれておらず、パスワードに成功 2 つを超える文字が含まれていないことを確認することで、managers グループのパスワードポリシーを強化する方法を説明します。

前提条件

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

手順

  1. Manager グループのユーザーが提案するすべてのパスワードに、ユーザー名の確認を適用します

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

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

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

    $ ipa pwpolicy-mod --maxrepeat=2 managers

    連続文字が 2 個以上含まれる場合は、パスワードが許可されないようになりました。たとえば、eR873mUi111YJQ の組み合わせは、3 つの成功に 1つ含まれているため、受け入れられません。

検証

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

    $ ipa user-add test_user
    First name: test
    Last name: user
    ----------------------------
    Added user "test_user"
    ----------------------------
  2. test ユーザーを managers グループに追加します。

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

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

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

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

      Kerberos には、詳細なエラーパスワードポリシーレポートがありません。特定のケースでは、パスワードが拒否された明確な理由はありません。

    3. システムは、入力したパスワードが拒否されたことを通知します。成功に 3 つ以上の同一文字が含まれるパスワードを入力します。

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

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

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

managers パスワードポリシーが managers グループのユーザーに適切に機能するようになりました。

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

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

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

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

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

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

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

関連情報

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

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

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

前提条件

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

手順

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

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

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

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

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

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

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

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

検証手順

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

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

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

18.3. IdM Web UI を使用した IdM クライアントの IdM ユーザーへの sudo アクセス許可

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

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

前提条件

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

手順

  1. sudo コマンドの IdM データベースに /usr/sbin/reboot コマンドを追加します。

    1. PolicySudoSudo Commands の順に移動します。
    2. 右上にある Add をクリックして、Add sudo command ダイアログボックスを開きます。
    3. sudo: /usr/sbin/reboot を使用してユーザーが実行できるコマンドを入力します。

      図18.1 IdM sudo コマンドの追加

      A screenshot of a pop-up window labeled "Add sudo command." There is a required field labeled "Sudo command" with contents "/usr/sbin/reboot". A "Description" field is empty. The bottom-right of the window has four buttons: "Add" - "Add and Add Another" - "Add and Edit" - "Cancel".
    4. Add をクリックします。
  2. 新しい sudo コマンドエントリーを使用して sudo ルールを作成し、idm_useridmclient マシンを再起動できるようにします。

    1. PolicySudoSudo ルールに移動します。
    2. 右上にある Add をクリックして、Add sudo rule ダイアログボックスを開きます。
    3. sudo ルールの名前を入力します (idm_user_reboot)。
    4. Add and Edit をクリックします。
    5. ユーザーを指定します。

      1. Who セクションで、ラジオボタン Specified Users and Groups を選択します。
      2. サブセクション User category the rule applies toAdd をクリックして、Add users into sudo rule "idm_user_reboot" ダイアログボックスを開きます。
      3. Add users into sudo rule "idm_user_reboot" ダイアログボックスにある Available 列で、idm_user チェックボックスを選択し、Prospective 列に移動します。
      4. Add をクリックします。
    6. ホストを指定します。

      1. Access this host セクションで、Specified Hosts and Groups ラジオボタンを確認します。
      2. サブセクション Host category this rule applies toAdd をクリックして、Add hosts into sudo rule "idm_user_reboot" ダイアログボックスを開きます。
      3. Add hosts into sudo rule "idm_user_reboot" ダイアログボックスにある Available 列で、idmclient.idm.example.com チェックボックスを選択し、Prospective 列に移動します。
      4. Add をクリックします。
    7. コマンドを指定します。

      1. Run Commands セクションの Command category the rule applies to サブセクションで、Specified Commands and Groups ラジオボタンを確認します。
      2. サブセクション Sudo Allow CommandsAdd をクリックして、Add allow sudo commands into sudo rule "idm_user_reboot" ダイアログボックスを開きます。
      3. Add allow sudo commands into sudo rule "idm_user_reboot" ダイアログボックスにある Available 列で、/usr/sbin/reboot チェックボックスを選択し、Prospective 列に移動します。
      4. Add をクリックして、idm_sudo_reboot ページに戻ります。

    IdM sudo ルールの追加

    + image::IdM-sudo-rule-WebUI.png[A screenshot of the sudo ルールの概要(追加した sudo ルールの概要)ルールの適用先のユーザーの表には「Who」セクションがあり、ルールの適用先のホストの表には、「Access this host」セクションがあります。ルールに関連するコマンドの表には、「Run Commands」セクションがあります。]

    1. 左上にある Save をクリックします。

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

注記

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

検証手順

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

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

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

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

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

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

前提条件

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

手順

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

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

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

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

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

    ユーザー(または --groups=* オプションで指定したグループ)は、ローカルのサービスアカウントや Active Directory ユーザーなど、IdM の外部にすることができます。グループ名には % プレフィックスを追加しないでください。

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

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

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

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

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

検証手順

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

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

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

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

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

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

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

前提条件

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

手順

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

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

      A screenshot of a pop-up window labeled "Add sudo command." There is a required field labeled "Sudo command" with contents "/opt/third-party-app/bin/report". A "Description" field is empty. The bottom-right of the window has four buttons: "Add" - "Add and Add Another" - "Add and Edit" - "Cancel".
    4. Add をクリックします。
  2. 新しい sudo コマンドエントリーを使用して、新しい sudo ルールを作成します。

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

      A screenshot of a pop-up window labeled "Add sudo rule." There is a required field labeled "Rule name" with contents "run_third-party-app_report". The bottom-right of the window has four buttons: "Add" - "Add and Add Another" - "Add and Edit" - "Cancel".
    4. Add and Edit をクリックします。
    5. ユーザーを指定します。

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

        A screenshot of a pop-up window labeled "Add users into sudo rule." You can select users from an Available list on the left and move them to a Prospective column on the right. The bottom-right of the window has two buttons: "Add" - "Cancel".
      4. Add をクリックします。
    6. ホストを指定します。

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

        A screenshot of a pop-up window labeled "Add hosts into sudo rule." You can select hosts from an Available list on the left and move them to a Prospective column on the right. The bottom-right of the window has two buttons: "Add" - "Cancel".
      4. Add をクリックします。
    7. コマンドを指定します。

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

        A screenshot of a pop-up window labeled "Add allow sudo commands into sudo rule." You can select sudo commands from an Available list on the left and move them to a Prospective column on the right. The bottom-right of the window has two buttons: "Add" - "Cancel".
      4. Add をクリックして、run_third-party-app_report ページに戻ります。
    8. RunAs ユーザーを指定します。

      1. As Whom セクションで、Specified Users and Groups ラジオボタンを確認します。
      2. RunAs Users サブセクションで Add をクリックし、Add RunAs ユーザーを sudo ルール "run_third-party-app_report" ダイアログボックスを開きます。
      3. Add RunAs ユーザーを sudo ルール "run_third-party-app_report" ダイアログボックスで、External ボックスに サードパーティーのサービスアカウント を入力し、Prospective 列に移動します

        A screenshot of a dialog box where you can specify the "thirdpartyapp" service account as an external user.
      4. Add をクリックして、run_third-party-app_report ページに戻ります。
    9. 左上にある Save をクリックします。

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

図18.2 sudo ルールの詳細

A screenshot of an overview of the sudo rule that was added. The "Who" section has an entry for "idm_user." The "Access this host" section has "idmclient.idm.example.com." The "Run Commands" section has the "/opt/third-party-app/bin/report" command. The "As Whom" section lists the "thirdpartyapp" account.
注記

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

検証手順

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

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

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

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

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

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

前提条件

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

手順

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

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

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

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

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

検証手順

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

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

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

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

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

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

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

注記

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

前提条件

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

手順

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

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

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

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

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

検証手順

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

前提条件

手順

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

    Server not found in Kerberos database

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

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

    No Kerberos credentials available

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

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

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

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

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

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

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

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

18.10. Ansible Playbook を使用した IdM クライアントでの IdM ユーザーの sudo アクセスの確保

Identity Management (IdM) では、特定の IdM ホストの IdM ユーザーアカウントに sudo アクセスが付与されるようにできます。

この手順では、idm_user_reboot という名前の sudo ルールが存在することを確認します。このルールは、idmclient マシンで /usr/sbin/reboot コマンドを実行するパーミッションを idm_user に付与します。

前提条件

手順

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

    [ipaservers]
    server.idm.example.com
  2. sudo コマンドを追加します。

    1. ensure-reboot-sudocmd-is-present.yml Ansible Playbook を作成し、sudo コマンドの IdM データベースに /usr/sbin/reboot コマンドが存在するようにします。この手順を単純化するには、/usr/share/doc/ansible-freeipa/playbooks/sudocmd/ensure-sudocmd-is-present.yml ファイルのサンプルをコピーして変更できます。

      ---
      - name: Playbook to manage sudo command
        hosts: ipaserver
        become: true
      
        tasks:
        # Ensure sudo command is present
        - ipasudocmd:
            ipaadmin_password: MySecret123
            name: /usr/sbin/reboot
            state: present
    2. Playbook を実行します。

      $ ansible-playbook -v -i path_to_inventory_directory/inventory.file path_to_playbooks_directory/ensure-reboot-sudocmd-is-present.yml
  3. コマンドを参照する sudo ルールを作成します。

    1. sudo コマンドエントリーを使用して sudo ルールが存在することを確認する ensure-sudorule-for-idmuser-on-idmclient-is-present.yml Ansible Playbook を作成します。sudo ルールは、idm_useridmclient マシンを再起動することを許可します。この手順を単純化するには、/usr/share/doc/ansible-freeipa/playbooks/sudorule/ensure-sudorule-is-present.yml ファイルのサンプルをコピーして変更できます。

      ---
      - name: Tests
        hosts: ipaserver
        become: true
      
        tasks:
        # Ensure a sudorule is present granting idm_user the permission to run /usr/sbin/reboot on idmclient
        - ipasudorule:
            ipaadmin_password: MySecret123
            name: idm_user_reboot
            description: A test sudo rule.
            allow_sudocmd: /usr/sbin/reboot
            host: idmclient.idm.example.com
            user: idm_user
            state: present
    2. Playbook を実行します。

      $ ansible-playbook -v -i path_to_inventory_directory/inventory.file path_to_playbooks_directory/ensure-sudorule-for-idmuser-on-idmclient-is-present.yml

検証手順

idm_usersudo を使用して idmclient を再起動して、IdM サーバーに存在する sudo ルールが idmclient で機能することを確認します。サーバーに加えられた変更がクライアントで反映されるまで数分の時間がかかる場合があります。

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

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

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

その他の資料

  • Playbook 変数の説明を含む Ansible Playbook を使用して IdM の sudo コマンド、コマンドグループ、およびルールを適用する方法は、/usr/share/doc/ansible-freeipa/ ディレクトリーで利用可能な README-sudocmd.md、README-sudocmdgroup.md、および README-sudorule.md Markdown ファイルを参照してください。

第19章 Ansible Playbook を使用して IdM にホストベースのアクセス制御ルールが存在することを確認する

本章では、Identity Management (IdM) のホストベースのアクセスポリシーと Ansible を使用して定義する方法を説明します。

Ansible は、システムの設定、ソフトウェアのデプロイ、ローリング更新の実行に使用する自動化ツールです。これには、Identity Management (IdM) のサポートが含まれます。

19.1. IdM のホストベースのアクセス制御ルール

ホストベースのアクセス制御 (HBAC) ルールは、サービスグループ内のサービスまたはサービスを使用して、どのユーザーまたはグループがどのホストまたはホストグループにアクセスできるかを定義します。システム管理者は、HBAC ルールを使用して以下の目標を達成できます。

  • ドメイン内の指定されたシステムへのアクセスを、特定のユーザーグループのメンバーに制限します。
  • ドメイン内のシステムにアクセスするために特定のサービスのみを使用できます。

デフォルトでは、IdM は allow_all という名前のデフォルトの HBAC ルールで設定されます。これは、IdM ドメイン内のすべて の関連サービスを介して、全ユーザーの全ホストへのユニバーサルアクセスを意味します。

デフォルトの allow_all ルールを独自の HBAC ルールセットに置き換えることで、異なるホストへのアクセスを微調整できます。アクセス制御管理を集中化し、簡素化するには、個別のユーザー、ホスト、またはサービスの代わりに、ユーザーグループ、ホストグループ、またはサービスグループに HBAC ルールを適用できます。

19.2. Ansible Playbook を使用して IdM に HBAC ルールが存在することを確認する

本セクションでは、Ansible Playbook を使用して、Identity Management (IdM) にホストベースのアクセス制御 (HBAC) ルールが存在することを確認する方法を説明します。

前提条件

手順

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

    [ipaserver]
    server.idm.example.com
  2. 確認する HBAC ポリシーを定義する Ansible Playbook ファイルを作成します。この手順を単純化するには、/usr/share/doc/ansible-freeipa/playbooks/hbacrule/ensure-hbacrule-allhosts-present.yml ファイルのサンプルをコピーして変更できます。

    ---
    - name: Playbook to handle hbacrules
      hosts: ipaserver
      become: true
    
      tasks:
      # Ensure idm_user can access client.idm.example.com via the sshd service
      - ipahbacrule:
          ipaadmin_password: MySecret123
          name: login
          user: idm_user
          host: client.idm.example.com
          hbacsvc:
          - sshd
          state: present
  3. Playbook を実行します。

    $ ansible-playbook -v -i path_to_inventory_directory/inventory.file path_to_playbooks_directory/ensure-new-hbacrule-present.yml

検証手順

  1. 管理者として IdM Web UI にログインします。
  2. PolicyHost-Based-Access-ControlHBAC Test と選択します。
  3. Who タブで idm_user を選択します。
  4. Accessing タブで client.idm.example.com を選択します。
  5. Via サービス タブで sshd を選択します。
  6. Rules タブで login を選択します。
  7. Run test タブで Run test ボタンをクリックします。ACCESS GRANTED が表示されると、HBAC ルールが正常に実装されます。

関連情報

  • HBAC サービス、サービスグループ、および Ansible を使用したルールの設定に関する詳細情報および例は、README-hbacsvc.md、README-hbacsvcgroup.md、および README-hbacrule.md Markdown ファイルを参照してください。これらのファイルは、/usr/share/doc/ansible-freeipa ディレクトリーにあります。また、/usr/share/doc/ansible-freeipa/playbooks ディレクトリーの関連サブディレクトリーで利用可能な Playbook も参照してください。

第20章 IdM の vault

本章では、Identity Management(IdM)の vault について説明します。本章では、以下のトピックを紹介します。

20.1. vault およびその利点

vault は、機密データをすべてセキュアに保存しつつも、1 箇所で都合よく Identity Management (IdM) を使用するのに便利な機能です。 このセクションでは、さまざまなタイプの vault とその用途についてまた、要件に合った vault の選び方について説明します。

vault とは、シークレットの保存、取得、共有、および復旧を行うための (IdM の) セキュアな場所を指し、シークレットは、通常は一部のユーザーまたはエンティティーグループのみがアクセスできる、認証情報などの機密データを指します。たとえば、シークレットには以下が含まれます。

  • パスワード
  • 暗証番号
  • SSH 秘密鍵

vault はパスワードマネージャーと類似しています。valut を使用する場合、通常、パスワードマネージャーと同様に、ロックを解除するためのプライマリーのパスワードを 1 つ生成し、記憶して、vault に保存されている情報にアクセスする必要があります。ただし、標準の vault を指定することも可能です。標準の vault では、vault に保存されているシークレットにアクセスするためにパスワードを入力する必要はありません。

注記

IdM の vault は、認証情報を保存して、IdM 関連以外の外部サービスに対して認証を可能にすることを目的としています。

IdM vault には他にも、次のような重要な特徴があります。

  • vault にアクセスできるのは、vault の所有者と、vault メンバーとして vault の所有者が選択した IdM ユーザーだけです。また、IdM 管理者も vault にアクセスできます。
  • ユーザーに vault を作成する権限がない場合には、IdM 管理者が vault を作成し、そのユーザーを所有者として設定できます。
  • ユーザーおよびサービスは、IdM ドメインに登録されているマシンからであれば、vault に保存されているシークレットにアクセスできます。
  • vault 1 つに追加できるシークレットは 1 つのみです (例: ファイル 1 つ)。ただし、ファイル自体には、パスワード、キータブ、証明書など複数のシークレットを含めることができます。
注記

Vault は、IdM Web UI ではなく、IdM コマンドライン (CLI) からしか利用できません。

20.2. Vault の所有者、メンバー、および管理者

Identity Management (IdM) で識別される vault ユーザータイプは以下のとおりです。

Vault 所有者

vault 所有者は、vault の基本的な管理権限のあるユーザーまたはサービスです。たとえば、vault の所有者は vault のプロパティーを変更したり、新しい vault メンバーを追加したりできます。

各 vault には最低でも所有者が 1 人必要です。vault には複数の所有者を指定することもできます。

Vault メンバー
vault メンバーは、別のユーザーまたはサービスが作成した vault にアクセスできるユーザーまたはサービスです。
Vault 管理者

vault 管理者は全 vault に制限なくアクセスでき、vault の操作をすべて実行できます。

注記

対称と非対称 vault は、パスワードまたは鍵で保護されており、特別なアクセス制御ルールが適用されます (Vault タイプ を参照)。管理者は、以下を行うためにこの特別なルールを満たす必要があります。

  • 対称および非対称 vault のシークレットにアクセスする。
  • vault パスワードまたはキーを変更またはリセットする。

vault 管理者は、vault administrators 特権を持つユーザーです。IdM のロールベースアクセス制御 (RBAC) のコンテキストでの特権とは、ロールに適用できるパーミッションのグループのことです。

Vault ユーザー

vault ユーザーは、vault のあるコンテナー内のユーザーです。Vault ユーザー 情報は、ipa vault-show などの特定のコマンドの出力に表示されます。

$ ipa vault-show my_vault
  Vault name: my_vault
  Type: standard
  Owner users: user
  Vault user: user

vault コンテナーおよびユーザー vault の詳細は、「Vault コンテナー」を参照してください。

関連情報

20.3. 標準、対称および非対称 vault

IdM では、セキュリティーおよびアクセス制御のレベルをもとに vault を以下のタイプに分類します。

標準 vault
Vault の所有者と vault メンバーは、パスワードやキーを使用せずにシークレットをアーカイブして取得できます。
対称 vault
vault のシークレットは対称キーを使用して保護されます。Vault の所有者とメンバーは、シークレットをアーカイブして取得できますが、vault パスワードを指定する必要があります。
非対称 vault
vault のシークレットは非対称キーを使用して保護されます。ユーザーは公開鍵でシークレットをアーカイブし、秘密鍵でシークレットを取得します。vault メンバーはシークレットのアーカイブのみが可能ですが、vault 所有者はシークレットのアーカイブと取得の両方が可能です。

20.4. ユーザー、サービスおよび共有 vault

IdM では、所有権をもとに vault を複数のタイプに分類します。以下の表 には、各タイプ、所有者、および使用方法に関する情報が含まれます。

表20.1 所有権に基づく IdM vault

タイプ説明所有者備考

ユーザー vault

ユーザーのプライベート vault

ユーザー x 1

IdM 管理者が許可すれば、ユーザーは 1 つまたは複数のユーザー vault を所有できます。

サービス vault

サービスのプライベート vault

サービス x 1

IdM 管理者が許可すれば、ユーザーは 1 つまたは複数のサービス vault を所有できます。

共有 vault

複数のユーザーおよびグループで共有される vault

vault を作成した vault の管理者

IdM 管理者が許可すれば、ユーザーおよびサービスは 1 つまたは複数のユーザー vault を所有できます。vault の作成者以外に、vault 管理者が vault に対して完全なアクセス権があります。

20.5. Vault コンテナー

vault コンテナーは vault のコレクションです。以下の表 は、Identity Management (IdM) が提供するデフォルトの vault コンテナーの一覧です。

表20.2 IdM のデフォルトの vault コンテナー

タイプ説明目的

ユーザーコンテナー

ユーザーのプライベートコンテナー

特定ユーザーのユーザー vault を格納します。

サービスコンテナー

サービスのプライベートコンテナー

特定のサービスのサービス vault を格納します。

共有コンテナー

複数のユーザーおよびサービスのコンテナー

複数のユーザーまたはサービスで共有可能な vault を格納します。

IdM では、ユーザーまたはサービスのプライベート vault が初めて作成されると、ユーザーまたはサービスごとにユーザーコンテナーおよびサービスコンテナーを自動的に作成します。ユーザーまたはサービスが削除されると、IdM はコンテナーとそのコンテンツを削除します。

20.6. 基本的な IdM vault コマンド

本セクションでは、Identity Management (IdM) vault の管理に使用できる基本的なコマンドについて説明します。以下の表 には、ipa vault-* コマンドとその目的が記載されています。

注記

ipa vault-* コマンドを実行する前に、IdM ドメインのサーバー 1 台以上に Key Recovery Authority (KRA) 証明書システムコンポーネントをインストールします。詳細は「IdM での Key Recovery Authority (KRA) のインストール」を参照してください。

表20.3 基本的な IdM vault コマンドおよび説明

コマンド目的

ipa help vault

IdM vault コマンドおよびサンプル vault コマンドの概念などの情報を表示します。

ipa vault-add --helpipa vault-find --help

特定の ipa vault-* コマンドに --help オプションを追加すると、このコマンドで利用可能なオプションと詳細なヘルプが表示されます。

ipa vault-show user_vault --user idm_user

vault メンバーとして vault にアクセスする場合は、vault 所有者を指定する必要があります。vault 所有者を指定しない場合には、IdM により vault が見つからない旨が通知されます。

[admin@server ~]$ ipa vault-show user_vault
ipa: ERROR: user_vault: vault not found

ipa vault-show shared_vault --shared

共有 vault にアクセスする場合には、アクセスする vault が共有 vault であることを指定する必要があります。それ以外の場合は、IdM により vault が見つからない旨が通知されます。

[admin@server ~]$ ipa vault-show shared_vault
ipa: ERROR: shared_vault: vault not found

20.7. IdM での Key Recovery Authority (KRA) のインストール

本セクションでは、Key Recovery Authority (KRA) Certificate System (CS) コンポーネントをインストールして、Identity Management (IdM) で vault を有効にする方法を説明します。

前提条件

  • IdM 管理者としてログインしている。
  • IdM クライアントに root としてログインしている。

手順

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

    # ipa-kra-install
重要

非表示のレプリカに、IdM クラスターの最初の KRA をインストールできます。ただし、追加の KRA をインストールするには、非表示レプリカを一時的にアクティベートしてから、表示されているレプリカに KRA のクローンをインストールする必要があります。その後に、最初に非表示レプリカを再度非表示にできます。

注記

vault サービスを高可用性に設定するには、IdM サーバー 2 台以上に KRA をインストールします。

関連情報

第21章 Ansible を使用した IdM ユーザー vault の管理: シークレットの保存および取得

本章では、Ansible vault モジュールを使用して Identity Management でユーザー vault を管理する方法を説明します。具体的には、ユーザーが Ansible Playbook を使用して以下の 3 つのアクションを実行する方法を説明しています。

異なる IdM クライアント 2 台から保存と取得が可能です。

前提条件

21.1. Ansible を使用して IdM に標準ユーザー vault を存在させる手順

本セクションでは、Identity Management (IdM) ユーザーが Ansible Playbook を使用して 1 つ以上のプライベート vault コンテナーを含む Vault コンテナーを作成し、機密情報を安全に保存する方法を説明します。以下の手順で使用する例では、idm_user ユーザーmy_vault という名前の標準タイプの vault を作成します。標準タイプの vault では、ファイルへのアクセス時に idm_user を認証する必要がありません。IdM_user は、ユーザーがログインしている IdM クライアントからファイルを取得できます。

前提条件

  • Ansible コントローラー (手順の内容を実行するホスト) に ansible-freeipa パッケージがインストールされている。
  • idm_user のパスワードを知っている。

手順

  1. /usr/share/doc/ansible-freeipa/playbooks/vault ディレクトリーに移動します。

    $ cd /usr/share/doc/ansible-freeipa/playbooks/vault
  2. inventory.file などの、インベントリーファイルを作成します。

    $ touch inventory.file
  3. inventory.file を開き、[ipaserver] セクションに、設定する IdM サーバーを定義します。たとえば、Ansible に対して server.idm.example.com を設定するよう指示するには、次のコマンドを実行します。

    [ipaserver]
    server.idm.example.com
  4. Ansible Playbook の ensure-standard-vault-is-present.yml ファイルのコピーを作成します。以下に例を示します。

    $ cp ensure-standard-vault-is-present.yml ensure-standard-vault-is-present-copy.yml
  5. ensure-standard-vault-is-present-copy.yml ファイルを開いて編集します。
  6. ipavault タスクセクションに以下の変数を設定して、ファイルを調整します。

    • ipaadmin_principal 変数は idm_user に設定します。
    • ipaadmin_password 変数は idm_user のパスワードに設定します。
    • user 変数は idm_user に設定します。
    • name 変数は my_vault に設定します。
    • vault_type 変数は standard に設定します。

      今回の例で使用するように変更した Ansible Playbook ファイル:

    ---
    - name: Tests
      hosts: ipaserver
      become: true
      gather_facts: false
    
      tasks:
      - ipavault:
          ipaadmin_principal: idm_user
          ipaadmin_password: idm_user_password
          user: idm_user
          name: my_vault
          vault_type: standard
  7. ファイルを保存します。
  8. Playbook を実行します。

    $ ansible-playbook -v -i inventory.file ensure-standard-vault-is-present-copy.yml

21.2. Ansible を使用して IdM の標準ユーザー vault でシークレットをアーカイブする手順

本セクションでは、Identity Management (IdM) ユーザーが Ansible Playbook を使用して、個人 vault に機密情報を保存する方法を説明します。この例では、idm_user ユーザーは my_vault という名前の vault に password.txt という名前で機密情報が含まれるファイルをアーカイブします。

前提条件

  • Ansible コントローラー (手順の内容を実行するホスト) に ansible-freeipa パッケージがインストールされている。
  • idm_user のパスワードを知っている。
  • IdM_user が所有者であるか、または my_vault のメンバーユーザーである。
  • password.txt (my_vault にアーカイブするシークレット) にアクセスできる。

手順

  1. /usr/share/doc/ansible-freeipa/playbooks/vault ディレクトリーに移動します。

    $ cd /usr/share/doc/ansible-freeipa/playbooks/vault
  2. インベントリーファイルを開き、設定する IdM サーバーが [ipaserver] セクションに記載されていることを確認します。たとえば、Ansible に対して server.idm.example.com を設定するよう指示するには、次のコマンドを実行します。

    [ipaserver]
    server.idm.example.com
  3. Ansible Playbook の data-archive-in-symmetric-vault.yml ファイルのコピーを作成して「symmetric」を「standard」に置き換えます。以下に例を示します。

    $ cp data-archive-in-symmetric-vault.yml data-archive-in-standard-vault-copy.yml
  4. data-archive-in-standard-vault-copy.yml ファイルを開いて編集します。
  5. ipavault タスクセクションに以下の変数を設定して、ファイルを調整します。

    • ipaadmin_principal 変数は idm_user に設定します。
    • ipaadmin_password 変数は idm_user のパスワードに設定します。
    • user 変数は idm_user に設定します。
    • name 変数は my_vault に設定します。
    • in 変数は機密情報が含まれるファイルへのパスに設定します。
    • アクション 変数は member に設定します。

      今回の例で使用するように変更した Ansible Playbook ファイル:

    ---
    - name: Tests
      hosts: ipaserver
      become: true
      gather_facts: false
    
      tasks:
      - ipavault:
          ipaadmin_principal: idm_user
          ipaadmin_password: idm_user_password
          user: idm_user
          name: my_vault
          in: /usr/share/doc/ansible-freeipa/playbooks/vault/password.txt
          action: member
  6. ファイルを保存します。
  7. Playbook を実行します。

    $ ansible-playbook -v -i inventory.file data-archive-in-standard-vault-copy.yml

21.3. Ansible を使用して IdM の標準ユーザー vault からシークレットを取得する手順

本セクションでは、Identity Management (IdM) ユーザーが Ansible Playbook を使用して、ユーザーの個人 vault からシークレットを取得する方法を説明します。以下の手順で使用する例では、idm_user ユーザーは、my_vault という名前の標準タイプの vault から機密データを含むファイルを取得して、host01 という名前の IdM クライアントに配置します。ファイルへのアクセス時に IdM_user を認証する必要はありません。IdM_user は Ansible を使用して、Ansible がインストールされている IdM クライアントからファイルを取得できます。

前提条件

  • Ansible コントローラーに ansible-freeipa パッケージがインストールされている。これは、この手順の内容を実行するホストです。
  • idm_user のパスワードを知っている。
  • IdM_usermy_vault の所有者である。
  • IdM_usermy_vault にシークレットを保存している。
  • Ansible が、シークレットを取得して配置する先の IdM ホストのディレクトリーに書き込みができる。
  • IdM_user はシークレットを取得して配置する先の IdM ホストのディレクトリーから読み取りができる。

手順

  1. /usr/share/doc/ansible-freeipa/playbooks/vault ディレクトリーに移動します。

    $ cd /usr/share/doc/ansible-freeipa/playbooks/vault
  2. インベントリーファイルを開き、明確に定義されたセクションで、シークレットを取得する IdM クライアントを記載します。たとえば、Ansible に対して host01.idm.example.com にシークレットを取得して配置するよう指示するには、次のコマンドを実行します。

    [ipahost]
    host01.idm.example.com
  3. Ansible Playbook ファイル (retrive-data-symmetric-vault.yml) のコピーを作成します。「symbolicmetric」を「Standard」に置き換えます。以下に例を示します。

    $ cp retrive-data-symmetric-vault.yml retrieve-data-standard-vault.yml-copy.yml
  4. retrieve-data-standard-vault.yml-copy.yml ファイルを開いて編集します。
  5. hosts 変数は ipahost に設定して、ファイルを調整します。
  6. ipavault タスクセクションに以下の変数を設定して、ファイルを調整します。

    • ipaadmin_principal 変数は idm_user に設定します。
    • ipaadmin_password 変数は idm_user のパスワードに設定します。
    • user 変数は idm_user に設定します。
    • name 変数は my_vault に設定します。
    • out 変数は、シークレットをエクスポートするファイルの完全パスに設定します。
    • state 変数は retrieved に設定します。

      今回の例で使用するように変更した Ansible Playbook ファイル:

    ---
    - name: Tests
      hosts: ipahost
      become: true
      gather_facts: false
    
      tasks:
      - ipavault:
          ipaadmin_principal: idm_user
          ipaadmin_password: idm_user_password
          user: idm_user
          name: my_vault
          out: /tmp/password_exported.txt
          state: retrieved
  7. ファイルを保存します。
  8. Playbook を実行します。

    $ ansible-playbook -v -i inventory.file retrieve-data-standard-vault.yml-copy.yml

検証手順

  1. host01user01 として SSH 接続します。

    $ ssh user01@host01.idm.example.com
  2. Ansible Playbook ファイルに out 変数で指定したファイルを表示します。

    $ vim /tmp/password_exported.txt

これで、エクスポートされたシークレットが表示されます。

  • Ansible を使用して IdM vault およびユーザーシークレットを管理する方法および、Playbook 変数の情報は、/usr/share/doc/ansible-freeipa/ ディレクトリーで利用可能な README-vault.md Markdown ファイルおよび /usr/share/doc/ansible-freeipa/playbooks/vault/ で利用可能なサンプルの Playbook を参照してください。

第22章 Ansible を使用した IdM サービス vault の管理: シークレットの保存および取得

本セクションでは、管理者が ansible-freeipa vault モジュールを使用してサービスシークレットを一元的にセキュアに保存する方法を説明します。

この例で使用される vault は非対称であるため、管理者は以下の手順を実行する必要があります。

  1. openssl ユーティリティーなどを使用して秘密鍵を生成する。
  2. 秘密鍵をもとに公開鍵を生成する。

サービスシークレットは、管理者が vault にアーカイブする時に公開鍵を使用して暗号化されます。その後、ドメイン内の特定のマシンでホストされるサービスインスタンスが、秘密鍵を使用してシークレットを取得します。シークレットにアクセスできるのは、サービスと管理者のみです。

シークレットが漏洩した場合には、管理者はサービス Vault でシークレットを置き換えて、漏洩されていないサービスインスタンスに配布しなおすことができます。

前提条件

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

本手順での以下の用語について説明します。

  • admin は、サービスパスワードを管理する管理者です。
  • private-key-to-an-externally-signed-certificate.pem は、サービスシークレットを含むファイルです (ここでは外部署名証明書への秘密鍵)。この秘密鍵と、vault からのシークレットの取得に使用する秘密鍵と混同しないようにしてください。
  • secret_vault は、サービスシークレット保存向けに作成された vault です。
  • HTTP/webserver1.idm.example.com は vault の所有者となるサービスです。
  • HTTP/webserver2.idm.example.com および HTTP/webserver3.idm.example.com は vault メンバーサービスです。
  • service-public.pem は、password_vault に保存されているパスワードの暗号化に使用するサービスの公開鍵です。
  • service-private.pem は、secret_vault に保存されているパスワードの復号化に使用するサービスの秘密鍵です。

22.1. Ansible を使用して IdM に非対称サービス vault を存在させる手順

本セクションでは、Identity Management (IdM) の管理者が Ansible Playbook を使用して 1 つ以上のプライベート vault コンテナーを含むサービス Vault コンテナーを作成して、機密情報を安全に保存する方法を説明します。以下の手順で使用する例では、管理者は secret_vault という名前の非対称 vault を作成します。こうすることで、Vault メンバーは秘密鍵を使用して認証を行い、vault のシークレットを取得する必要があります。vault メンバーは、IdM クライアントからファイルを取得できます。

前提条件

  • Ansible コントローラーに ansible-freeipa パッケージがインストールされている。これは、この手順の内容を実行するホストです。
  • IdM 管理者 パスワードが分かっている。

手順

  1. /usr/share/doc/ansible-freeipa/playbooks/vault ディレクトリーに移動します。

    $ cd /usr/share/doc/ansible-freeipa/playbooks/vault
  2. サービスインスタンスの公開鍵を取得します。たとえば、openssl ユーティリティーを使用する場合は以下を行います。

    1. service-private.pem 秘密鍵を生成します。

      $ openssl genrsa -out service-private.pem 2048
      Generating RSA private key, 2048 bit long modulus
      .+++
      ...........................................+++
      e is 65537 (0x10001)
    2. 秘密鍵をもとに service-public.pem 公開鍵を生成します。

      $ openssl rsa -in service-private.pem -out service-public.pem -pubout
      writing RSA key
  3. オプション: inventory.file など、存在しない場合はインベントリーファイルを作成します。

    $ touch inventory.file
  4. インベントリーファイルを開き、[ipaserver] セクションに、設定する IdM サーバーを定義します。たとえば、Ansible に対して server.idm.example.com を設定するよう指示するには、次のコマンドを実行します。

    [ipaserver]
    server.idm.example.com
  5. Ansible Playbook ファイル ensure-asymmetric-vault-is-present.yml のコピーを作成します。以下に例を示します。

    $ cp ensure-asymmetric-vault-is-present.yml ensure-asymmetric-service-vault-is-present-copy.yml
  6. ensure-asymmetric-vault-is-present-copy.yml ファイルを開いて編集します。
  7. Ansible コントローラーから server.idm.example.com サーバーに service-public.pem の公開鍵をコピーするタスクを追加します。
  8. ipavault タスクセクションに以下の変数を設定して、残りのファイルを変更します。

    • ipaadmin_password 変数は IdM 管理者パスワードに設定します。
    • secret_vault などの name 変数を使用して vault の名前を定義します。
    • vault_type 変数は asymmetric に設定します。
    • サービス 変数は、vault を所有するサービスのプリンシパル (例: HTTP/webserver1.idm.example.com) に設定します。
    • public_key_file は、公開鍵の場所に設定します。

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

    ---
    - name: Tests
      hosts: ipaserver
      become: true
      gather_facts: false
      tasks:
      - name: Copy public key to ipaserver.
        copy:
          src: /path/to/service-public.pem
          dest: /usr/share/doc/ansible-freeipa/playbooks/vault/service-public.pem
          mode: 0600
      - name: Add data to vault, from a LOCAL file.
        ipavault:
          ipaadmin_password: Secret123
          name: secret_vault
          vault_type: asymmetric
          service: HTTP/webserver1.idm.example.com
          public_key_file: /usr/share/doc/ansible-freeipa/playbooks/vault/service-public.pem
  9. ファイルを保存します。
  10. Playbook を実行します。

    $ ansible-playbook -v -i inventory.file ensure-asymmetric-service-vault-is-present-copy.yml

22.2. Ansible を使用した非対称 vault へのメンバーサービスの追加

本セクションでは、Identity Management (IdM) の管理者が Ansible Playbook を使用してメンバーサービスをサービス vault に追加し、メンバーサービスにより、vault に保存されているシークレットをすべて取得できるようにする方法を説明します。以下の手順で使用する例では、IdM の管理者は HTTP/webserver2.idm.example.comHTTP/webserver3.idm.example.com のサービスプリンシパルを HTTP/webserver1.idm.example.com が所有する secret_vault vault に追加します。

前提条件

  • Ansible コントローラーに ansible-freeipa パッケージがインストールされている。これは、この手順の内容を実行するホストです。
  • IdM 管理者 パスワードが分かっている。
  • サービスシークレットの保存先の 非対称 vault を作成している。

手順

  1. /usr/share/doc/ansible-freeipa/playbooks/vault ディレクトリーに移動します。

    $ cd /usr/share/doc/ansible-freeipa/playbooks/vault
  2. オプション: inventory.file など、存在しない場合はインベントリーファイルを作成します。

    $ touch inventory.file
  3. インベントリーファイルを開き、[ipaserver] セクションに、設定する IdM サーバーを定義します。たとえば、Ansible に対して server.idm.example.com を設定するよう指示するには、次のコマンドを実行します。

    [ipaserver]
    server.idm.example.com
  4. Ansible Playbook ファイル (data-archive-in-asymmetric-vault.yml) を作成します。以下に例を示します。

    $ cp data-archive-in-asymmetric-vault.yml add-services-to-an-asymmetric-vault.yml
  5. data-archive-in-asymmetric-vault-copy.yml ファイルを開いて編集します。
  6. ファイルを変更するには、ipavault タスクセクションに以下の変数を設定します。

    • ipaadmin_password 変数は IdM 管理者パスワードに設定します。
    • name 変数は vault の名前 (例: secret_vault) に設定します。
    • サービス 変数は vault のサービス所有者に設定します (例: HTTP/webserver1.idm.example.com)。
    • services 変数を使用して、vault シークレットにアクセスできる サービス を定義します。
    • action 変数は member に設定します。

      今回の例で使用するように変更した Ansible Playbook ファイル:

    ---
    - name: Tests
      hosts: ipaserver
      become: true
      gather_facts: false
    
      tasks:
      - ipavault:
          ipaadmin_password: Secret123
          name: secret_vault
          service: HTTP/webserver1.idm.example.com
          services:
          - HTTP/webserver2.idm.example.com
          - HTTP/webserver3.idm.example.com
          action: member
  7. ファイルを保存します。
  8. Playbook を実行します。

    $ ansible-playbook -v -i inventory.file add-services-to-an-asymmetric-vault.yml

22.3. Ansible を使用した非対称 vault への IdM サービスシークレットの保存

本セクションでは、Identity Management (IdM) 管理者が Ansible Playbook を使用してサービス vault にシークレットを保存して、サービスが後からシークレットを取得できるようにする方法を説明します。以下の手順で使用する例では、管理者は secret_vault という名前の非対称 vault にシークレットが含まれる PEM ファイルを保存します。こうすることで、サービスは秘密鍵を使用して認証を行い、vault からシークレットを取得する必要があります。vault メンバーは、IdM クライアントからファイルを取得できます。

前提条件

  • Ansible コントローラーに ansible-freeipa パッケージがインストールされている。これは、この手順の内容を実行するホストです。
  • IdM 管理者 パスワードが分かっている。
  • サービスシークレットの保存先の 非対称 vault を作成している。
  • シークレットが /usr/share/doc/ansible-freeipa/playbooks/vault/private-key-to-an-externally-signed-certificate.pem ファイルなど、Ansible コントローラーのローカルに保存されている。

手順

  1. /usr/share/doc/ansible-freeipa/playbooks/vault ディレクトリーに移動します。

    $ cd /usr/share/doc/ansible-freeipa/playbooks/vault
  2. オプション: inventory.file など、存在しない場合はインベントリーファイルを作成します。

    $ touch inventory.file
  3. インベントリーファイルを開き、[ipaserver] セクションに、設定する IdM サーバーを定義します。たとえば、Ansible に対して server.idm.example.com を設定するよう指示するには、次のコマンドを実行します。

    [ipaserver]
    server.idm.example.com
  4. Ansible Playbook ファイル (data-archive-in-asymmetric-vault.yml) を作成します。以下に例を示します。

    $ cp data-archive-in-asymmetric-vault.yml data-archive-in-asymmetric-vault-copy.yml
  5. data-archive-in-asymmetric-vault-copy.yml ファイルを開いて編集します。
  6. ファイルを変更するには、ipavault タスクセクションに以下の変数を設定します。

    • ipaadmin_password 変数は IdM 管理者パスワードに設定します。
    • name 変数は vault の名前 (例: secret_vault) に設定します。
    • サービス 変数は vault のサービス所有者に設定します (例: HTTP/webserver1.idm.example.com)。
    • in 変数は "{{ lookup('file', 'private-key-to-an-externally-signed-certificate.pem')| b64encode }}" に設定します。この設定では、Ansible が IdM サーバーではなく、Ansible コントローラーの作業ディレクトリーから秘密鍵のあるファイルを取得するようになります。
    • action 変数は member に設定します。

      今回の例で使用するように変更した Ansible Playbook ファイル:

    ---
    - name: Tests
      hosts: ipaserver
      become: true
      gather_facts: false
    
      tasks:
      - ipavault:
          ipaadmin_password: Secret123
          name: secret_vault
          service: HTTP/webserver1.idm.example.com
          in: "{{ lookup('file', 'private-key-to-an-externally-signed-certificate.pem') | b64encode }}"
          action: member
  7. ファイルを保存します。
  8. Playbook を実行します。

    $ ansible-playbook -v -i inventory.file data-archive-in-asymmetric-vault-copy.yml

22.4. Ansible を使用した IdM サービスのサービスシークレットの取得

本セクションでは、Identity Management (IdM) ユーザーが Ansible Playbook を使用して、サービスの代わりにサービス vault からシークレットを取得する方法を説明します。以下の手順で使用する例では、Playbook を実行して secret_vault という名前の PEM ファイルを取得し、Ansible インベントリーファイルに ipaservers として記載されている全ホストの指定の場所に保存します。

サービスは、キータブを使用して IdM に対して、さらに秘密鍵を使用して vault に対して認証を実行します。ansible-freeipa がインストールされている IdM クライアントから、サービスの代わりにファイルを取得できます。

前提条件

  • Ansible コントローラーに ansible-freeipa パッケージがインストールされている。これは、この手順の内容を実行するホストです。
  • IdM 管理者パスワードが分かっている。
  • サービスシークレットの保存先の 非対称 vault を作成している。
  • vault にシークレットをアーカイブ している。
  • Ansible コントローラーで private_key_file 変数が指定する場所にサービス vault のシークレットの取得に使用する秘密鍵が保存されている。

手順

  1. /usr/share/doc/ansible-freeipa/playbooks/vault ディレクトリーに移動します。

    $ cd /usr/share/doc/ansible-freeipa/playbooks/vault
  2. オプション: inventory.file など、存在しない場合はインベントリーファイルを作成します。

    $ touch inventory.file
  3. インベントリーファイルを開き、以下のホストを定義します。

    • [ipaserver] セクションで、使用する IdM サーバーを定義します。
    • [webservers] セクションで、シークレットを取得するホストを定義します。たとえば Ansible に対して webserver1.idm.example.comwebserver2.idm.example.com および webserver3.idm.example.com にシークレットを取得するように指示するには以下を実行します。
    [ipaserver]
    server.idm.example.com
    
    [webservers]
    webserver1.idm.example.com
    webserver2.idm.example.com
    webserver3.idm.example.com
  4. Ansible Playbookファイル (retrieve-data-asymmetric-vault.yml) のコピーを作成します。以下に例を示します。

    $ cp retrieve-data-asymmetric-vault.yml retrieve-data-asymmetric-vault-copy.yml
  5. retrieve-data-asymmetric-vault-copy.yml ファイルを開いて編集します。
  6. ファイルを変更するには、ipavault タスクセクションに以下の変数を設定します。

    • ipaadmin_password 変数は IdM 管理者パスワードに設定します。
    • name 変数は vault の名前 (例: secret_vault) に設定します。
    • サービス 変数は vault のサービス所有者に設定します (例: HTTP/webserver1.idm.example.com)。
    • private_key_file 変数は、サービス vault のシークレットの取得に使用する秘密鍵の場所に設定します。
    • out 変数は、現在の作業ディレクトリーなど、private-key-to-an-externally-signed-certificate.pem シークレットの取得先となる IdM サーバーの場所に設定します。
    • action 変数は member に設定します。

      今回の例で使用するように変更した Ansible Playbook ファイル:

    ---
    - name: Retrieve data from vault
      hosts: ipaserver
      become: no
      gather_facts: false
    
      tasks:
      - name: Retrieve data from the service vault
        ipavault:
          ipaadmin_password: Secret123
          name: secret_vault
          service: HTTP/webserver1.idm.example.com
          vault_type: asymmetric
          private_key: "{{ lookup('file', 'service-private.pem') | b64encode }}"
          out: private-key-to-an-externally-signed-certificate.pem
          state: retrieved
  7. Playbook に、IdM サーバーから Ansible コントローラーにデータファイルを取得するセクションを追加します。

    ---
    - name: Retrieve data from vault
      hosts: ipaserver
      become: no
      gather_facts: false
      tasks:
    [...]
      - name: Retrieve data file
        fetch:
          src: private-key-to-an-externally-signed-certificate.pem
          dest: ./
          flat: yes
          mode: 0600
  8. インベントリーファイルの webservers セクションに記載されている Web サーバーに、Ansible コントローラーから取得した private-key-to-an-externally-signed-certificate.pem ファイルを転送するセクションを Playbook に追加します。

    ---
    - name: Send data file to webservers
      become: no
      gather_facts: no
      hosts: webservers
      tasks:
      - name: Send data to webservers
        copy:
          src: private-key-to-an-externally-signed-certificate.pem
          dest: /etc/pki/tls/private/httpd.key
          mode: 0444
  9. ファイルを保存します。
  10. Playbook を実行します。

    $ ansible-playbook -v -i inventory.file retrieve-data-asymmetric-vault-copy.yml

22.5. シークレットが漏洩した場合の Ansible での IdM サービス vault シークレットの変更

本セクションでは、サービスインスタンスの情報が漏洩した場合に、Identity Management (IdM) の管理者が Ansible Playbook を再利用して、サービス vault に保存されているシークレットを変更する方法を説明します。以下の例のシナリオでは、シークレットを保存する非対称 vault への鍵は漏洩されておらず、webserver3.idm.example.com で取得したシークレットの情報が漏洩した場合を前提としています。この例では、管理者は 非対称 vault でシークレットを保存する時 および IdM ホストに非対称 vault からシークレットを取得する時 に Ansible Playbook を再利用します。この手順のはじめに、IdM 管理者は新規シークレットを含む新しい PEM ファイルを非対称 vault に保存し、不正アクセスのあった Web サーバー (webserver3.idm.example.com) に新しいシークレットを配置しないようにインベントリーファイルを調節し、もう一度この 2 つの手順を実行します。

前提条件

  • Ansible コントローラーに ansible-freeipa パッケージがインストールされている。これは、この手順の内容を実行するホストです。
  • IdM 管理者 パスワードが分かっている。
  • サービスシークレットの保存先の 非対称 vault を作成している。
  • IdM ホストで実行中の Web サービスの httpd 鍵を新たに生成し、不正アクセスのあった以前の鍵を置き換えている。
  • 新しい httpd キーが /usr/share/doc/ansible-freeipa/playbooks/vault/private-key-to-an-externally-signed-certificate.pem ファイルなど、Ansible コントローラーのローカルに保存されている。

手順

  1. /usr/share/doc/ansible-freeipa/playbooks/vault ディレクトリーに移動します。

    $ cd /usr/share/doc/ansible-freeipa/playbooks/vault
  2. インベントリーファイルを開き、以下のホストが正しく定義されていることを確認します。

    • [ipaserver] セクションの IdM サーバー
    • [webservers] セクションのシークレット取得先のホスト。たとえば Ansible に対して webserver1.idm.example.comwebserver2.idm.example.com にシークレットを取得するように指示するには、以下を入力します。

      [ipaserver]
      server.idm.example.com
      
      [webservers]
      webserver1.idm.example.com
      webserver2.idm.example.com
    重要

    このリストに不正アクセスのあった Web サーバーが含まれないようにしてください (現在の例では webserver3.idm.example.com)。

  3. data-archive-in-asymmetric-vault-copy.yml ファイルを開いて編集します。
  4. ファイルを変更するには、ipavault タスクセクションに以下の変数を設定します。

    • ipaadmin_password 変数は IdM 管理者パスワードに設定します。
    • name 変数は vault の名前 (例: secret_vault) に設定します。
    • サービス 変数は vault のサービス所有者に設定します (例: HTTP/webserver.idm.example.com)。
    • in 変数は "{{ lookup('file', 'new-private-key-to-an-externally-signed-certificate.pem')| b64encode }}" に設定します。この設定では、Ansible が IdM サーバーではなく、Ansible コントローラーの作業ディレクトリーから秘密鍵のあるファイルを取得するようになります。
    • action 変数は member に設定します。

      今回の例で使用するように変更した Ansible Playbook ファイル:

    ---
    - name: Tests
      hosts: ipaserver
      become: true
      gather_facts: false
    
      tasks:
      - ipavault:
          ipaadmin_password: Secret123
          name: secret_vault
          service: HTTP/webserver.idm.example.com
          in: "{{ lookup('file', 'new-private-key-to-an-externally-signed-certificate.pem') | b64encode }}"
          action: member
  5. ファイルを保存します。
  6. Playbook を実行します。

    $ ansible-playbook -v -i inventory.file data-archive-in-asymmetric-vault-copy.yml
  7. retrieve-data-asymmetric-vault-copy.yml ファイルを開いて編集します。
  8. ファイルを変更するには、ipavault タスクセクションに以下の変数を設定します。

    • ipaadmin_password 変数は IdM 管理者パスワードに設定します。
    • name 変数は vault の名前 (例: secret_vault) に設定します。
    • サービス 変数は vault のサービス所有者に設定します (例: HTTP/webserver1.idm.example.com)。
    • private_key_file 変数は、サービス vault のシークレットの取得に使用する秘密鍵の場所に設定します。
    • out 変数は、現在の作業ディレクトリーなど、new-private-key-to-an-externally-signed-certificate.pem シークレットの取得先となる IdM サーバーの場所に設定します。
    • action 変数は member に設定します。

      今回の例で使用するように変更した Ansible Playbook ファイル:

    ---
    - name: Retrieve data from vault
      hosts: ipaserver
      become: no
      gather_facts: false
    
      tasks:
      - name: Retrieve data from the service vault
        ipavault:
          ipaadmin_password: Secret123
          name: secret_vault
          service: HTTP/webserver1.idm.example.com
          vault_type: asymmetric
          private_key: "{{ lookup('file', 'service-private.pem') | b64encode }}"
          out: new-private-key-to-an-externally-signed-certificate.pem
          state: retrieved
  9. Playbook に、IdM サーバーから Ansible コントローラーにデータファイルを取得するセクションを追加します。

    ---
    - name: Retrieve data from vault
      hosts: ipaserver
      become: yes
      gather_facts: false
      tasks:
    [...]
      - name: Retrieve data file
        fetch:
          src: new-private-key-to-an-externally-signed-certificate.pem
          dest: ./
          flat: yes
          mode: 0600
  10. インベントリーファイルの webservers セクションに記載されている Web サーバーに、Ansible コントローラーから取得した new-private-key-to-an-externally-signed-certificate.pem ファイルを転送するセクションを Playbook に追加します。

    ---
    - name: Send data file to webservers
      become: yes
      gather_facts: no
      hosts: webservers
      tasks:
      - name: Send data to webservers
        copy:
          src: new-private-key-to-an-externally-signed-certificate.pem
          dest: /etc/pki/tls/private/httpd.key
          mode: 0444
  11. ファイルを保存します。
  12. Playbook を実行します。

    $ ansible-playbook -v -i inventory.file retrieve-data-asymmetric-vault-copy.yml

関連情報

  • Ansible を使用して IdM vault およびサービスシークレットを管理する方法および、Playbook 変数の情報は、/usr/share/doc/ansible-freeipa/ ディレクトリーで利用可能な README-vault.md Markdown ファイルおよび /usr/share/doc/ansible-freeipa/playbooks/vault/ で利用可能なサンプルの Playbook を参照してください。

第23章 Ansible を使用して IdM にサービスを配置させる手順およびさせない手順

Ansible サービス モジュールを使用すると、Identity Management (IdM) 管理者は、IdM ネイティブではない特定のサービスが IdM に存在するか、存在しないかを確認できます。たとえば、サービス モジュールを使用すると以下を行うことができます。

23.1. Ansible Playbook を使用して IdM に HTTP サービスを存在させる手順

本セクションでは、Ansible Playbook を使用して IdM に HTTP サーバーを存在させる方法を説明します。

前提条件

  • HTTP サービスをホストするシステムが IdM クライアントである。
  • IdM 管理者パスワードがある。

手順

  1. inventory.file などのインベントリーファイルを作成します。

    $ touch inventory.file
  2. inventory.file を開き、[ipaserver] セクションに、設定する IdM サーバーを定義します。たとえば、Ansible に対して server.idm.example.com を設定するよう指示するには、以下を入力します。

    [ipaserver]
    server.idm.example.com
  3. Ansible Playbook ファイル (/usr/share/doc/ansible-freeipa/playbooks/service/service-is-present.yml) のコピーを作成します。以下に例を示します。

    $ cp /usr/share/doc/ansible-freeipa/playbooks/service/service-is-present.yml /usr/share/doc/ansible-freeipa/playbooks/service/service-is-present-copy.yml
  4. Ansible Playbook ファイル (/usr/share/doc/ansible-freeipa/playbooks/service/service-is-present-copy.yml) を開きます。

    ---
    - name: Playbook to manage IPA service.
      hosts: ipaserver
      become: true
      gather_facts: false
    
      tasks:
      # Ensure service is present
      - ipaservice:
          ipaadmin_password: Secret123
          name: HTTP/client.idm.example.com
  5. ファイルを調整します。

    • ipaadmin_password 変数で定義されている IdM 管理者パスワードを変更します。
    • ipaservice タスクの name 変数で定義されているように、HTTP サービスが実行されている IdM クライアントの名前を変更します。
  6. ファイルを保存して終了します。
  7. Playbook ファイルとインベントリーファイルを指定して Ansible Playbook を実行します。

    $ ansible-playbook -v -i path_to_inventory_directory/inventory.file /usr/share/doc/ansible-freeipa/playbooks/service/service-is-present-copy.yml

検証手順

  1. 管理者として IdM Web UI にログインします。
  2. IdentityServices に移動します。

Services 一覧に HTTP/client.idm.example.com@IDM.EXAMPLE.COM がある場合は、Ansible Playbook は IdM に正常に追加されています。

関連情報

23.2. Ansible Playbook を使用して、IdM 以外のクライアントの IdM で HTTP サービスを存在させる手順

本セクションでは、Ansible Playbook を使用して IdM クライアント以外のホスト上にある IdM に HTTP サーバーを存在させる方法を説明します。HTTP サーバーを IdM に追加して、ホストを IdM に追加することもできます。

前提条件

手順

  1. inventory.file などのインベントリーファイルを作成します。

    $ touch inventory.file
  2. inventory.file を開き、[ipaserver] セクションに、設定する IdM サーバーを定義します。たとえば、Ansible に対して server.idm.example.com を設定するよう指示するには、以下を入力します。

    [ipaserver]
    server.idm.example.com
  3. Ansible Playbook ファイル (/usr/share/doc/ansible-freeipa/playbooks/service/service-is-present-using-host-check.yml) のコピーを作成します。以下に例を示します。

    $ cp /usr/share/doc/ansible-freeipa/playbooks/service/service-is-present-without-host-check.yml /usr/share/doc/ansible-freeipa/playbooks/service/service-is-present-without-host-check-copy.yml
  4. コピーしたファイル (/usr/share/doc/ansible-freeipa/playbooks/service/service-is-present-using-host-check-copy.yml) を開きます。ipaservice タスクで ipaadmin_passwordname 変数の場所を特定します。

    ---
    - name: Playbook to manage IPA service.
      hosts: ipaserver
      become: true
      gather_facts: false
    
      tasks:
      # Ensure service is present
      - ipaservice:
          ipaadmin_password: MyPassword123
          name: HTTP/www2.example.com
          skip_host_check: yes
  5. ファイルを調整します。

    • ipaadmin_password 変数は IdM 管理者パスワードに設定します。
    • name 変数は、HTTP サービスが実行されているホストの名前に設定します。
  6. ファイルを保存して終了します。
  7. Playbook ファイルとインベントリーファイルを指定して Ansible Playbook を実行します。

    $ ansible-playbook -v -i path_to_inventory_directory/inventory.file /usr/share/doc/ansible-freeipa/playbooks/service/service-is-present-using-host-check-copy.yml

検証手順

  1. 管理者として IdM Web UI にログインします。
  2. IdentityServices に移動します。

HTTP/client.idm.example.com@IDM.EXAMPLE.COMServices リストに表示されています。

関連情報

23.3. Ansible Playbook を使用して、DNS を使用せずに IdM クライアントで HTTP サービスを存在させる手順

本セクションでは、Ansible Playbook を使用して HTTP サーバーが DNS エントリーのない IdM クライアントで実行されるようにする方法を説明します。このシナリオでは、IdM ホストに DNS A エントリーがないことを前提としています (IPv4 の代わりに IPv6 を使用する場合には DNS AAAA エントリーがない)。

前提条件

  • HTTP サービスをホストするシステムが IdM に登録されている。
  • ホストの DNS A または DNS AAAA レコードを存在させない。ホストの DNS レコードが存在する場合には、ホストの DNS レコードが存在する場合は、「Ansible Playbook を使用して IdM に HTTP サービスを存在させる手順」に従うようにしてください。
  • IdM 管理者パスワードがある。

手順

  1. inventory.file などのインベントリーファイルを作成します。

    $ touch inventory.file
  2. inventory.file を開き、[ipaserver] セクションに、設定する IdM サーバーを定義します。たとえば、Ansible に対して server.idm.example.com を設定するよう指示するには、以下を入力します。

    [ipaserver]
    server.idm.example.com
  3. Ansible Playbook ファイル (/usr/share/doc/ansible-freeipa/playbooks/service/service-is-present-with-host-force.yml) のコピーを作成します。以下に例を示します。

    $ cp /usr/share/doc/ansible-freeipa/playbooks/service/service-is-present-with-host-force.yml /usr/share/doc/ansible-freeipa/playbooks/service/service-is-present-with-host-force-copy.yml
  4. コピーしたファイル /usr/share/doc/ansible-freeipa/playbooks/service/service-is-present-with-host-force-copy.yml を開きます。ipaservice タスクで ipaadmin_passwordname 変数の場所を特定します。

    ---
    - name: Playbook to manage IPA service.
      hosts: ipaserver
      become: true
      gather_facts: false
    
      tasks:
      # Ensure service is present
      - ipaservice:
          ipaadmin_password: MyPassword123
          name: HTTP/ihavenodns.info
          force: yes
  5. ファイルを調整します。

    • ipaadmin_password 変数は IdM 管理者パスワードに設定します。
    • name 変数は、HTTP サービスが実行されているホストの名前に設定します。
  6. ファイルを保存して終了します。
  7. Playbook ファイルとインベントリーファイルを指定して Ansible Playbook を実行します。

    $ ansible-playbook -v -i path_to_inventory_directory/inventory.file /usr/share/doc/ansible-freeipa/playbooks/service/service-is-present-with-host-force-copy.yml

検証手順

  1. 管理者として IdM Web UI にログインします。
  2. IdentityServices に移動します。

HTTP/client.idm.example.com@IDM.EXAMPLE.COMServices リストに表示されています。

関連情報

23.4. Ansible Playbook を使用して IdM サービスエントリーに外部署名証明書を存在させる手順

本セクションでは、ansible-freeipa サービス モジュールを使用して、外部の認証局 (CA) が HTTP サービスの IdM エントリーにアタッチされるようにする方法を説明します。IdM CA が自己署名の証明書を使用する場合には、IdM CA ではなく外部 CA が署名した HTTP サービスの証明書を使用すると便利です。

前提条件

手順

  1. inventory.file などのインベントリーファイルを作成します。

    $ touch inventory.file
  2. inventory.file を開き、[ipaserver] セクションに、設定する IdM サーバーを定義します。たとえば、Ansible に対して server.idm.example.com を設定するよう指示するには、以下を入力します。

    [ipaserver]
    server.idm.example.com
  3. 以下のように /usr/share/doc/ansible-freeipa/playbooks/service/service-member-certificate-present.yml ファイルのコピーを作成します。

    $ cp /usr/share/doc/ansible-freeipa/playbooks/service/service-member-certificate-present.yml /usr/share/doc/ansible-freeipa/playbooks/service/service-member-certificate-present-copy.yml
  4. オプション: 証明書の形式が Privacy Enhanced Mail (PEM) の場合には、証明書を識別名エンコーディングルール (DER) 形式に変換し、コマンドラインインターフェース (CLI) でより簡単に処理できるようにします。

    $ openssl x509 -outform der -in cert1.pem -out cert1.der
  5. base64 を使用して DER ファイルを復号化します。ラッピングを無効にするには、-w0 オプションを使用します。

    $ base64 cert1.der -w0
    MIIC/zCCAeegAwIBAgIUV74O+4kXeg21o4vxfRRtyJm...
  6. 標準出力からクリップボードに証明書をコピーします。
  7. /usr/share/doc/ansible-freeipa/playbooks/service/service-member-certificate-present-copy.yml ファイルを開き、このファイルの内容を編集および表示します。

    ---
    - name: Service certificate present.
      hosts: ipaserver
      become: true
      gather_facts: false
    
      tasks:
      # Ensure service certificate is present
      - ipaservice:
          ipaadmin_password: MyPassword123
          name: HTTP/www.example.com
          certificate: |
            - MIICBjCCAW8CFHnm32VcXaUDGfEGdDL/...
          [...]
          action: member
          state: present
  8. ファイルを調整します。

    • certificate 変数を使用して定義した証明書は、CLI からコピーした証明書に置き換えます。上記のように「|」パイプ文字と certificate: 変数を併用する場合は、1 行に入力せずに、このように証明書を入力してください。これで、証明書の読み取りが容易になります。
    • ipaadmin_password 変数で定義されている IdM 管理者パスワードを変更します。
    • HTTP サービスを実行する IdM クライアントの名前 (name 変数で定義) を変更します。
    • その他の関連する変数を変更します。
  9. ファイルを保存して終了します。
  10. Playbook ファイルとインベントリーファイルを指定して Ansible Playbook を実行します。

    $ ansible-playbook -v -i path_to_inventory_directory/inventory.file /usr/share/doc/ansible-freeipa/playbooks/service/service-member-certificate-present-copy.yml

検証手順

  1. 管理者として IdM Web UI にログインします。
  2. IdentityServices に移動します。
  3. HTTP/client.idm.example.com など、新しく追加した証明書が指定されたサービス名をクリックします。

右側の サービス証明書 セクションで、新たに追加した証明書を確認できるようになりました。

23.5. Ansible Playbook を使用して IdM ユーザー、グループ、ホスト、またはホストグループでサービスのキータブを作成できるようにする手順

キータブは、Kerberos プリンシパルと暗号化鍵のペアを含むファイルです。キータブファイルは通常、人の介入なしで、またはプレーンテキストファイルに保存されたパスワードを使用せずに、スクリプトで自動的に Kerberos で認証を行えるようにするために使用します。その後、スクリプトは取得した認証情報を使用してリモートシステムに保存されているファイルにアクセスできます。

Identity Management (IdM) 管理者は、他のユーザーが、IdM で実行しているサービスのキータブを取得したり、作成したりできるようにします。特定のユーザーおよびユーザーグループがキータブを作成できるようにすると、IdM 管理者パスワードを共有せずにサービスの管理を委譲できます。このように委譲することで、システムを詳細にわたり管理できます。

本セクションでは、特定の IdM ユーザー、ユーザーグループ、ホスト、およびホストグループが IdM クライアントで実行している HTTP サービスのキータブを作成できるようにする方法を説明します。具体的には、IdM ユーザー user01 が、client.idm.example.com という名前の IdM クライアントで実行中の HTTP サービスのキータブを作成できるように設定する方法を説明します。

前提条件

  • IdM 管理者パスワードが分かっている。
  • Ansible コントローラーに ansible-freeipa パッケージがインストールされている。
  • HTTP サービスを IdM に登録している。
  • HTTP サービスをホストするシステムが IdM クライアントである。
  • キータブの作成を許可する IdM ユーザーおよびユーザーグループが IdM に存在する。
  • キータブの作成を許可する IdM ホストおよびホストグループが IdM に存在する。

手順

  1. inventory.file などのインベントリーファイルを作成します。

    $ touch inventory.file
  2. inventory.file を開き、[ipaserver] セクションに、設定する IdM サーバーを定義します。たとえば、Ansible に対して server.idm.example.com を設定するよう指示するには、以下を入力します。

    [ipaserver]
    server.idm.example.com
  3. Ansible Playbook ファイル (/usr/share/doc/ansible-freeipa/playbooks/service/service-member-allow_create_keytab-present.yml) のコピーを作成します。以下に例を示します。

    $ cp /usr/share/doc/ansible-freeipa/playbooks/service/service-member-allow_create_keytab-present.yml /usr/share/doc/ansible-freeipa/playbooks/service/service-member-allow_create_keytab-present-copy.yml
  4. Ansible Playbook ファイル (/usr/share/doc/ansible-freeipa/playbooks/service/service-member-allow_create_keytab-present-copy.yml) を開きます。
  5. 以下を変更してファイルを調整します。

    • ipaadmin_password 変数で指定した IdM 管理者パスワード。
    • HTTP サービスが実行されている IdM クライアントの名前。現在の例では、HTTP/client.idm.example.com です。
    • allow_create_keytab_user: セクションに記載されている IdM ユーザー名。現在の例では user01 です。
    • allow_create_keytab_group: セクションに記載されている IdM ユーザーグループ名。
    • allow_create_keytab_host: セクションに記載されている IdM ホスト名。
    • allow_create_keytab_hostgroup: セクションに記載されている IdM ホストグループ名。
    • tasks セクションの name 変数で指定されているタスク名。

      現在の例に合わせて調節すると、コピーされたファイルは以下のようになります。

    ---
    - name: Service member allow_create_keytab present
      hosts: ipaserver
      become: true
    
      tasks:
      - name: Service HTTP/client.idm.example.com members allow_create_keytab present for user01
        ipaservice:
          ipaadmin_password: Secret123
          name: HTTP/client.idm.example.com
          allow_create_keytab_user:
          - user01
          action: member
  6. ファイルを保存します。
  7. Playbook ファイルとインベントリーファイルを指定して Ansible Playbook を実行します。

    $ ansible-playbook -v -i path_to_inventory_directory/inventory.file /usr/share/doc/ansible-freeipa/playbooks/service/service-member-allow_create_keytab-present-copy.yml

検証手順

  1. 特定の HTTP サービスのキータブを作成する権限のある IdM ユーザーで、IdM サーバーに SSH 接続します。

    $ ssh user01@server.idm.example.com
    Password:
  2. ipa-getkeytab コマンドを使用して、HTTP サービスの新規キータブを生成します。

    $ ipa-getkeytab -s server.idm.example.com -p HTTP/client.idm.example.com -k /etc/httpd/conf/krb5.keytab

    -s オプションは、キータブを生成するキー配布センター (KDC) サーバーを指定します。

    -p オプションは、作成するキータブのプリンシパルを指定します。

    -k オプションは、新規キーを追加するキータブファイルを指定します。ファイルが存在しない場合には、作成されます。

このコマンドでエラーが表示されない場合は、user01 で、HTTP/client.idm.example.com のキータブが正常に作成されています。

23.6. Ansible Playbook を使用して IdM ユーザー、グループ、ホスト、またはホストグループでサービスのキータブを取得できるようにする手順

キータブは、Kerberos プリンシパルと暗号化鍵のペアを含むファイルです。キータブファイルは通常、人の介入なしで、またはプレーンテキストファイルに保存されたパスワードを使用せずに、スクリプトで自動的に Kerberos で認証を行えるようにするために使用します。その後、スクリプトは取得した認証情報を使用してリモートシステムに保存されているファイルにアクセスできます。

IdM 管理者は、他のユーザーが、IdM で実行しているサービスのキータブを取得したり、作成したりできるようにします。

本セクションでは、特定の IdM ユーザー、ユーザーグループ、ホスト、およびホストグループが IdM クライアントで実行している HTTP サービスのキータブを取得できるようにする方法を説明します。具体的には IdM ユーザー user01 が、client.idm.example.com で実行する HTTP サービスのキータブを取得できるように設定する方法を説明します。

前提条件

  • IdM 管理者パスワードが分かっている。
  • Ansible コントローラーに ansible-freeipa パッケージがインストールされている。
  • HTTP サービスを IdM に登録している。
  • キータブの取得を許可する IdM ユーザーおよびグループが IdM に存在する。
  • キータブの取得を許可する IdM ホストおよびホストグループが IdM に存在する。

手順

  1. inventory.file などのインベントリーファイルを作成します。

    $ touch inventory.file
  2. inventory.file を開き、[ipaserver] セクションに、設定する IdM サーバーを定義します。たとえば、Ansible に対して server.idm.example.com を設定するよう指示するには、以下を入力します。

    [ipaserver]
    server.idm.example.com
  3. Ansible Playbook ファイル (/usr/share/doc/ansible-freeipa/playbooks/service/service-member-allow_retrieve_keytab-present.yml) のコピーを作成します。以下に例を示します。

    $ cp /usr/share/doc/ansible-freeipa/playbooks/service/service-member-allow_retrieve_keytab-present.yml /usr/share/doc/ansible-freeipa/playbooks/service/service-member-allow_retrieve_keytab-present-copy.yml
  4. コピーしたファイル /usr/share/doc/ansible-freeipa/playbooks/service/service-member-allow_retrieve_keytab-present-copy.yml を開きます。
  5. ファイルを調整します。

    • ipaadmin_password 変数は IdM 管理者パスワードに設定します。
    • ipaservice タスクの name 変数は、HTTP サービスのプリンシパルに設定します。現在の例では、HTTP/client.idm.example.com です。
    • allow_retrieve_keytab_group: セクションで IdM ユーザーの名前を指定します。現在の例では user01 です。
    • allow_retrieve_keytab_group: セクションで、IdM ユーザーグループの名前を指定します。
    • allow_retrieve_keytab_group: セクションで IdM ホストの名前を指定します。
    • allow_retrieve_keytab_group: セクションで IdM ホストグループの名前を指定します。
    • tasks セクションの name 変数を使用して、タスク名を指定します。

      現在の例に合わせて調節すると、コピーされたファイルは以下のようになります。

    ---
    - name: Service member allow_retrieve_keytab present
      hosts: ipaserver
      become: true
    
      tasks:
      - name: Service HTTP/client.idm.example.com members allow_retrieve_keytab present for user01
        ipaservice:
          ipaadmin_password: Secret123
          name: HTTP/client.idm.example.com
          allow_retrieve_keytab_user:
          - user01
          action: member
  6. ファイルを保存します。
  7. Playbook ファイルとインベントリーファイルを指定して Ansible Playbook を実行します。

    $ ansible-playbook -v -i path_to_inventory_directory/inventory.file /usr/share/doc/ansible-freeipa/playbooks/service/service-member-allow_retrieve_keytab-present-copy.yml

検証手順

  1. HTTP サービスのキータブ取得権限がある IdM ユーザーとして、IdM サーバーに SSH 接続します。

    $ ssh user01@server.idm.example.com
    Password:
  2. -r オプションを指定して ipa-getkeytab コマンドを使用してキータブを取得します。

    $ ipa-getkeytab -r -s server.idm.example.com -p HTTP/client.idm.example.com -k /etc/httpd/conf/krb5.keytab

    -s オプションは、キータブの取得元となるキー配布センター (KDC) サーバーを指定します。

    -p オプションは、キータブを取得するプリンシパルを指定します。

    -k オプションは、取得した鍵を追加するキータブファイルを指定します。ファイルが存在しない場合には、作成されます。

このコマンドでエラーが表示されない場合は、user01HTTP/client.idm.example.com のキータブが正常に取得されています。

23.7. Ansible Playbook を使用してサービスの Kerberos プリンシパルのエイリアスを存在させる手順

シナリオによっては、IdM ユーザー、ホストまたはサービスが Kerberos アプリケーションに対して Kerberos プリンシパルエイリアスを使用して認証できるように IdM 管理者が設定すると便利です。次のようなシナリオになります。

  • ユーザー名の変更後に、ユーザーが以前のユーザー名と新しいユーザー名の両方でシステムにログインできるようにする。
  • IdM Kerberos レルムがメールドメインと異なる場合でも、ユーザーはメールアドレスを使用してログインする必要がある。

本セクションでは、client.idm.example.com で実行する HTTP サービスの HTTP/mycompany.idm.example.com のプリンシパルエイリアスを作成する方法を説明します。

前提条件

手順

  1. inventory.file などのインベントリーファイルを作成します。

    $ touch inventory.file
  2. inventory.file を開き、[ipaserver] セクションに、設定する IdM サーバーを定義します。たとえば、Ansible に対して server.idm.example.com を設定するよう指示するには、以下を入力します。

    [ipaserver]
    server.idm.example.com
  3. Ansible Playbook ファイル (/usr/share/doc/ansible-freeipa/playbooks/service/service-member-principal-present.yml) のコピーを作成します。以下に例を示します。

    $ cp /usr/share/doc/ansible-freeipa/playbooks/service/service-member-principal-present.yml /usr/share/doc/ansible-freeipa/playbooks/service/service-member-principal-present-copy.yml
  4. Ansible Playbook ファイル (/usr/share/doc/ansible-freeipa/playbooks/service/service-member-principal-present-copy.yml) を開きます。
  5. 以下を変更してファイルを調整します。

    • ipaadmin_password 変数で指定した IdM 管理者パスワード。
    • name 変数で指定したサービス名。これは、サービスの標準プリンシパル名です。現在の例では HTTP/client.idm.example.com です。
    • principal 変数で指定した Keroberosプリンシパルエイリアス。これは、name 変数で定義したサービスに追加するエイリアスです。現在の例では、host/mycompany.idm.example.com です。
    • tasks セクションの name 変数で指定されているタスク名。

      現在の例に合わせて調節すると、コピーされたファイルは以下のようになります。

    ---
    - name: Service member principal present
      hosts: ipaserver
      become: true
    
      tasks:
      - name: Service HTTP/client.idm.example.com member principals host/mycompany.idm.exmaple.com present
        ipaservice:
          ipaadmin_password: Secret123
          name: HTTP/client.idm.example.com
          principal:
            - host/mycompany.idm.example.com
          action: member
  6. ファイルを保存します。
  7. Playbook ファイルとインベントリーファイルを指定して Ansible Playbook を実行します。

    $ ansible-playbook -v -i path_to_inventory_directory/inventory.file /usr/share/doc/ansible-freeipa/playbooks/service/service-member-principal-present-copy.yml

Playbook を実行すると、到達できないタスクが 0 件、失敗したタスクが 0 件になる場合には、HTTP/client.idm.example.com サービスの host/mycompany.idm.example.com Kerberos プリンシパルが正常に作成されています。

関連情報

23.8. Ansible Playbook を使用して IdM に HTTP サービスを存在させないようにする手順

本セクションでは、IdM からサービスの登録を解除する方法を説明します。より具体的には、Ansible Playbook を使用して、IdM にある HTTP/client.idm.example.com という名前の HTTP サーバーを削除する方法を説明します。

前提条件

  • IdM 管理者パスワードがある。

手順

  1. inventory.file などのインベントリーファイルを作成します。

    $ touch inventory.file
  2. inventory.file を開き、[ipaserver] セクションに、設定する IdM サーバーを定義します。たとえば、Ansible に対して server.idm.example.com を設定するよう指示するには、以下を入力します。

    [ipaserver]
    server.idm.example.com
  3. Ansible Playbook ファイル (/usr/share/doc/ansible-freeipa/playbooks/service/service-is-absent.yml) のコピーを作成します。以下に例を示します。

    $ cp /usr/share/doc/ansible-freeipa/playbooks/service/service-is-absent.yml /usr/share/doc/ansible-freeipa/playbooks/service/service-is-absent-copy.yml
  4. Ansible Playbook ファイル (/usr/share/doc/ansible-freeipa/playbooks/service/service-is-absent-copy.yml) を開きます。
  5. 以下を変更してファイルを調整します。

    • ipaadmin_password 変数で定義されている IdM 管理者パスワード。
    • ipaservice タスクの name 変数で定義されている、HTTP サービスの Kerberos プリンシパル。

      現在の例に合わせて調節すると、コピーされたファイルは以下のようになります。

    ---
    - name: Playbook to manage IPA service.
      hosts: ipaserver
      become: true
      gather_facts: false
    
      tasks:
      # Ensure service is absent
      - ipaservice:
          ipaadmin_password: Secret123
          name: HTTP/client.idm.example.com
          state: absent
  6. ファイルを保存して終了します。
  7. Playbook ファイルとインベントリーファイルを指定して Ansible Playbook を実行します。

    $ ansible-playbook -v -i path_to_inventory_directory/inventory.file /usr/share/doc/ansible-freeipa/playbooks/service/service-is-absent-copy.yml

検証手順

  1. 管理者として IdM Web UI にログインします。
  2. IdentityServices に移動します。

Services リストに HTTP/client.idm.example.com@IDM.EXAMPLE.COM サービスが表示されていない場合には、IdM から正常に削除されています。

関連情報

  • 利用可能な変数の一覧など、IdM へのサービスの追加や削除を行う Ansible Playbook のサンプルは、/usr/share/doc/ansible-freeipa/ ディレクトリーの README-service.md マークダウンファイルで確認できます。
  • IdM へのサービスの追加や削除を行う Ansible Playbook のサンプルは、/usr/share/doc/ansible-freeipa/playbooks/config ディレクトリーで確認できます。

第24章 Ansible Playbook を使用した IdM でのグローバル DNS 設定の管理

Red Hat Ansible Engine の dnsconfig モジュールを使用して、Identity Management (IdM) DNS のグローバル設定を構成できます。グローバル DNS 設定で定義したオプションは、すべての IdM DNS サーバーに適用されます。ただし、グローバル設定は、特定の IdM DNS ゾーンの設定よりも優先度が低くなります。

dnsconfig モジュールは以下の変数をサポートします。

  • グローバルフォワーダー (特に通信に使用する IP アドレスとポート)
  • グローバル転送ポリシー: only、first、または noneDNS 転送ポリシーの上記のタイプの詳細は、「IdM の DNS 転送ポリシー」を参照してください。
  • 正引きルックアップおよび逆引きルックアップゾーンの同期。

前提条件

 

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

24.1. IdM を使用して /etc/resolv.conf のグローバルフォワーダーが NetworkManager に削除されないようにする方法

統合 DNS で Identity Management (IdM) をインストールすると、/etc/resolv.conf ファイルが localhost アドレス (127.0.0.1) を参照するように設定されます。

# Generated by NetworkManager
search idm.example.com
nameserver 127.0.0.1

DHCP (Dynamic Host Configuration Protocol) を使用するネットワークなど、環境によっては、/etc/resolv.conf ファイルへの変更が NetworkManager サービスにより元に戻されてしまう場合があります。IdM DNS のインストールプロセスでは、以下のように NetworkManager サービスも設定し、DNS 設定を永続化します。

  1. DNS インストールスクリプトを使用して、/etc/NetworkManager/conf.d/zzzz-ipa.conf NetworkManager 設定ファイルを作成し、検索の順序と DNS サーバー一覧を制御します。

    # auto-generated by IPA installer
    [main]
    dns=default
    
    [global-dns]
    searches=$DOMAIN
    
    [global-dns-domain-*]
    servers=127.0.0.1
  2. NetworkManager サービスが再読み込みされ、/etc/NetworkManager/conf.d/ ディレクトリーにある以前のファイルの設定を使用して /etc/resolv.conf ファイルを作成します。今回の場合は、zzz-ipa.conf ファイルです。
重要

/etc/resolv.conf ファイルは手動で変更しないでください。

24.2. Ansible を使用して IdM に DNS グローバルフォワーダーを存在させる手順

本セクションでは、Identity Management (IdM) 管理者が Ansible Playbook を使用して IdM に DNS グローバルフォワーダーを追加する方法を説明します。以下の例では、IdM 管理者は、ポート 53 にインターネットプロトコル (IP) v4 アドレスが 7.7.9.9、IPv6 アドレスが 2001:db8::1:0 で指定されている DNS サーバーに、DNS グローバルフォワーダーが配置されるようにします。

前提条件

  • Ansible コントローラーに ansible-freeipa パッケージがインストールされている。これは、この手順の内容を実行するホストです。
  • IdM 管理者パスワードが分かっている。

手順

  1. /usr/share/doc/ansible-freeipa/playbooks/dnsconfig ディレクトリーに移動します。

    $ cd /usr/share/doc/ansible-freeipa/playbooks/dnsconfig
  2. インベントリーファイルを開き、設定する IdM サーバーが [ipaserver] セクションに記載されていることを確認します。たとえば、Ansible に対して server.idm.example.com を設定するよう指示するには、以下を入力します。

    [ipaserver]
    server.idm.example.com
  3. Ansible Playbook ファイル (forwarders-absent.yml) のコピーを作成します。以下に例を示します。

    $ cp forwarders-absent.yml ensure-presence-of-a-global-forwarder.yml
  4. ensure-presence-of-a-global-forwarder.yml ファイルを開いて編集します。
  5. 以下の変数を設定してファイルを調整します。

    1. Playbook の name 変数は、IdM DNS にグローバルフォワーダーを追加する Playbook の設定に変更します。
    2. tasks セクションで、タスクの nameEnsure the presence of a DNS global forwarder to 7.7.9.9 and 2001:db8::1:0 on port 53 に変更します。
    3. ipadnsconfigforwarders セクションで以下を行います。

      1. 最初の ip_address の値は、グローバルフォワーダーの IPv4 アドレス (7.7.9.9) に変更します。
      2. 2 番目の ip_address の値は、グローバルフォワーダーの IPv6 アドレス (2001:db8::1:0) に変更します。
      3. port の値が 53 に設定されていることを確認します。
    4. statepresent に変更します。

      今回の例で使用するように変更した Ansible Playbook ファイル:

    ---
    - name: Playbook to ensure the presence of a global forwarder in IdM DNS
      hosts: ipaserver
      become: true
    
      tasks:
      - name: Ensure the presence of a DNS global forwarder to 7.7.9.9 and 2001:db8::1:0 on port 53
        ipadnsconfig:
          forwarders:
            - ip_address: 7.7.9.9
            - ip_address: 2001:db8::1:0
              port: 53
          state: present
  6. ファイルを保存します。
  7. Playbook を実行します。

    $ ansible-playbook -v -i inventory.file ensure-presence-of-a-global-forwarder.yml

関連情報

  • ansible-freeipa ipadnsconfig モジュールの Ansible Playbook の他のサンプルは、/usr/share/doc/ansible-freeipa/ ディレクトリーの README-dnsconfig.md Markdown ファイルで確認できます。このファイルには、ipadnsconfig 変数の定義も含まれます。

24.3. Ansible を使用して IdM に DNS グローバルフォワーダーを存在させないようにする手順

本セクションでは、Identity Management (IdM) 管理者が Ansible Playbook を使用して、IdM から DNS グローバルフォワーダーを削除する方法を説明します。以下の例では、IdM 管理者は、ポート 53 にインターネットプロトコル (IP) v4 アドレスが 8.8.6.6、IPv6 アドレスが 2001:4860:4860::8800 で指定されている DNS サーバーに DNS グローバルフォワーダーが配置されないようにします。

前提条件

  • Ansible コントローラーに ansible-freeipa パッケージがインストールされている。これは、この手順の内容を実行するホストです。
  • IdM 管理者パスワードが分かっている。

手順

  1. /usr/share/doc/ansible-freeipa/playbooks/dnsconfig ディレクトリーに移動します。

    $ cd /usr/share/doc/ansible-freeipa/playbooks/dnsconfig
  2. インベントリーファイルを開き、設定する IdM サーバーが [ipaserver] セクションに記載されていることを確認します。たとえば、Ansible に対して server.idm.example.com を設定するよう指示するには、以下を入力します。

    [ipaserver]
    server.idm.example.com
  3. Ansible Playbook ファイル (forwarders-absent.yml) のコピーを作成します。以下に例を示します。

    $ cp forwarders-absent.yml ensure-absence-of-a-global-forwarder.yml
  4. ensure-absence-of-a-global-forwarder.yml ファイルを開いて編集します。
  5. 以下の変数を設定してファイルを調整します。

    1. Playbook の name 変数は、IdM DNS でグローバルフォワーダーを配置しない Playbook の設定に変更します。
    2. tasks セクションで、タスクの nameEnsure the absence of a DNS global forwarder to 8.8.6.6 and 2001:4860:4860::8800 on port 53 に変更します。
    3. ipadnsconfigforwarders セクションで以下を行います。

      1. 最初の ip_address の値は、グローバルフォワーダーの IPv4 アドレス (8.8.6.6) に変更します。
      2. 2 番目の ip_address の値は、グローバルフォワーダーの IPv6 アドレス (2001:4860:4860::8800) に変更します。
      3. port の値が 53 に設定されていることを確認します。
    4. stateabsent に設定されていることを確認します。

      今回の例で使用するように変更した Ansible Playbook ファイル:

    ---
    - name: Playbook to ensure the absence of a global forwarder in IdM DNS
      hosts: ipaserver
      become: true
    
      tasks:
      - name: Ensure the absence of a DNS global forwarder to 8.8.6.6 and 2001:4860:4860::8800 on port 53
        ipadnsconfig:
          forwarders:
            - ip_address: 8.8.6.6
            - ip_address: 2001:4860:4860::8800
              port: 53
          state: absent
  6. ファイルを保存します。
  7. Playbook を実行します。

    $ ansible-playbook -v -i inventory.file ensure-absence-of-a-global-forwarder.yml

関連情報

  • ansible-freeipa ipadnsconfig モジュールの Ansible Playbook の他のサンプルは、/usr/share/doc/ansible-freeipa/ ディレクトリーの README-dnsconfig.md Markdown ファイルで確認できます。このファイルには、ipadnsconfig 変数の定義も含まれます。

24.4. IdM での DNS 転送ポリシー

IdM は、first および only の BIND 転送ポリシーと、IdM 固有の転送ポリシー none をサポートします。

forward first (デフォルト)
IdM BIND サービスは、DNS クエリーを設定済みのフォワーダーに転送します。サーバーエラーやタイムアウトが原因でクエリーに失敗すると、BIND はインターネット上のサーバーを使用して再帰解決にフォールバックします。forward first ポリシーはデフォルトのポリシーで、DNS トラフィックの最適化に適しています。
Forward only
IdM BIND サービスは、DNS クエリーを設定済みのフォワーダーに転送します。サーバーエラーやタイムアウトが原因でクエリーに失敗すると、BIND はエラーをクライアントに返します。分割された DNS 設定の環境では、forward only ポリシーが推奨されます。
None (転送の無効化)
DNS クエリーは、none 転送ポリシーで転送されません。グローバル転送設定をゾーン別に上書きする場合にのみ、転送の無効化は有用です。このオプションは、IdM の BIND 設定で空のフォワーダー一覧を指定するのと同じです。
注記

転送を使用して、IdM のデータと、他の DNS サーバーのデータと統合できません。IdM DNS のプライマリーゾーン内にある特定のサブゾーンのクエリーのみを転送できます。

デフォルトでは、IdM サーバーが権威サーバーとなっているゾーンに、クエリーされた DNS 名が所属する場合には、BIND サービスは、クエリーを別のサーバーに転送しません。このような場合は、クエリーされた DNS 名が IdM データベースに見つからない場合は、NXDOMAIN との応答が返されます。転送は使用されません。

例24.1 サンプルシナリオ

IdM サーバーは、test.example の権威サーバーです。DNS ゾーン。BIND は、IP アドレス 192.0.2.254 でクエリーを DNS サーバーに転送するように設定されています。

クライアントが nonexistent.test.example のクエリーを送信する場合DNS 名である BIND は、IdM サーバーが test.example. ゾーンの権威サーバーであることを検出して、クエリーを 192.0.2.254. サーバーには転送しません。その結果、DNS クライアントは NXDomain エラーメッセージを受け取り、クエリーされたドメインが存在しないことをユーザーに通知します。

24.5. Ansible Playbook を使用して forward first ポリシーを IdM DNS グローバル設定で指定する手順

本セクションでは、Identity Management (IdM) 管理者が Ansible Playbook を使用して、IdM DNS のグローバル転送ポリシーが forward first に設定されるようにする方法を説明します。

forward first DNS 転送ポリシーを使用する場合には、DNS クエリーは設定済みのフォワーダーに転送されます。サーバーエラーやタイムアウトが原因でクエリーに失敗すると、BIND はインターネット上のサーバーを使用して再帰解決にフォールバックします。Forward first ポリシーはデフォルトのポリシーです。トラフィックの最適化に適しています。

前提条件

  • Ansible コントローラー (この手順を実行するホスト) に ansible-freeipa パッケージがインストールされている。詳細は、「ansible-freeipa パッケージのインストール 」を参照してください。
  • IdM 管理者パスワードが分かっている。
  • IdM 環境に統合 DNS サーバーが含まれている。

手順

  1. /usr/share/doc/ansible-freeipa/playbooks/dnsconfig ディレクトリーに移動します。

    $ cd /usr/share/doc/ansible-freeipa/playbooks/dnsconfig
  2. インベントリーファイルを開き、設定する IdM サーバーが [ipaserver] セクションに記載されていることを確認します。たとえば、Ansible に対して server.idm.example.com を設定するよう指示するには、以下を入力します。

    [ipaserver]
    server.idm.example.com
  3. Ansible Playbook ファイル (set-configuration.yml) のコピーを作成します。以下に例を示します。

    $ cp set-configuration.yml set-forward-policy-to-first.yml
  4. set-forward-policy-to-first.yml ファイルを開いて編集します。
  5. ipadnsconfig タスクセクションに以下の変数を設定して、ファイルを調整します。

    • ipaadmin_password 変数は IdM 管理者パスワードに設定します。
    • forward_policy 変数は first に設定します。

      元の Playbook で関連性の他の行はすべて削除します。以下は、今回の例で使用するように変更した Ansible Playbook ファイルです。

    ---
    - name: Playbook to set global forwarding policy to first
      hosts: ipaserver
      become: true
    
      tasks:
      - name: Set global forwarding policy to first.
        ipadnsconfig:
          ipaadmin_password: Secret123
          forward_policy: first
  6. ファイルを保存します。
  7. Playbook を実行します。

    $ ansible-playbook -v -i inventory.file set-forward-policy-to-first.yml

関連情報

  • IdM DNS で利用可能な転送ポリシーの種類の詳細は、「IdM の DNS 転送ポリシー」を参照してください。
  • ansible-freeipa ipadnsconfig モジュールを使用した他の Ansible Playbook の例については、/usr/share/doc/ansible-freeipa/ ディレクトリーの README-dnsconfig.md Markdown ファイルを参照してください。このファイルには ipadnsconfig 変数の定義も含まれます。
  • ipadnsconfig モジュールを使用した他の Ansible Playbook の例は /usr/share/doc/ansible-freeipa/playbooks/dnsconfig ディレクトリーを参照してください。

24.6. Ansible Playbook を使用して IdM DNS でグローバルフォワーダーを無効にする手順

本セクションでは、Identity Management (IdM) 管理者が Ansible Playbook を使用して、IdM DNS でグローバルフォワーダーを無効にする方法を説明します。グローバルフォワーダーの無効化は、forward_policy 変数を none に設定します。

グローバルフォワーダーを無効にすると、DNS クエリーは転送されません。グローバル転送設定をゾーン別に上書きする場合にのみ、転送の無効化は有用です。このオプションは、IdM の BIND 設定で空のフォワーダー一覧を指定するのと同じです。

前提条件

  • Ansible コントローラー (この手順を実行するホスト) に ansible-freeipa パッケージがインストールされている。詳細は、「ansible-freeipa パッケージのインストール 」を参照してください。
  • IdM 管理者パスワードが分かっている。
  • IdM 環境に統合 DNS サーバーが含まれている。

手順

  1. /usr/share/doc/ansible-freeipa/playbooks/dnsconfig ディレクトリーに移動します。

    $ cd /usr/share/doc/ansible-freeipa/playbooks/dnsconfig
  2. インベントリーファイルを開き、設定する IdM サーバーが [ipaserver] セクションに記載されていることを確認します。たとえば、Ansible に対して server.idm.example.com を設定するよう指示するには、以下を入力します。

    [ipaserver]
    server.idm.example.com
  3. Ansible Playbook ファイル (disable-global-forwarders.yml) のコピーを作成します。以下に例を示します。

    $ cp disable-global-forwarders.yml disable-global-forwarders-copy.yml
  4. disable-global-forwarders-copy.yml ファイルを開いて編集します。
  5. ipadnsconfig タスクセクションに以下の変数を設定して、ファイルを調整します。

    • ipaadmin_password 変数は IdM 管理者パスワードに設定します。
    • forward_policy 変数を none に設定します。

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

    ---
    - name: Playbook to disable global DNS forwarders
      hosts: ipaserver
      become: true
    
      tasks:
      - name: Disable global forwarders.
        ipadnsconfig:
          ipaadmin_password: Secret123
          forward_policy: none
  6. ファイルを保存します。
  7. Playbook を実行します。

    $ ansible-playbook -v -i inventory.file disable-global-forwarders-copy.yml

関連情報

  • IdM DNS で利用可能な転送ポリシーの種類の詳細は、「IdM の DNS 転送ポリシー」を参照してください。
  • ansible-freeipa ipadnsconfig モジュールを使用した他の Ansible Playbook の例については、/usr/share/doc/ansible-freeipa/ ディレクトリーの README-dnsconfig.md Markdown ファイルを参照してください。このファイルには ipadnsconfig 変数の定義も含まれます。
  • ipadnsconfig モジュールを使用した他の Ansible Playbook の例は /usr/share/doc/ansible-freeipa/playbooks/dnsconfig ディレクトリーを参照してください。

24.7. Ansible Playbook を使用して IdM DNS で正引きおよび逆引きルックアップゾーンの同期を無効にする手順

本セクションでは、Identity Management (IdM) 管理者が Ansible Playbook を使用して、正引きおよび逆引きルックアップゾーンが IdM DNS で同期されないようにする方法を説明します。

前提条件

  • Ansible コントローラー (この手順を実行するホスト) に ansible-freeipa パッケージがインストールされている。詳細は、「ansible-freeipa パッケージのインストール 」を参照してください。
  • IdM 管理者パスワードが分かっている。
  • IdM 環境に統合 DNS サーバーが含まれている。

手順

  1. /usr/share/doc/ansible-freeipa/playbooks/dnsconfig ディレクトリーに移動します。

    $ cd /usr/share/doc/ansible-freeipa/playbooks/dnsconfig
  2. インベントリーファイルを開き、設定する IdM サーバーが [ipaserver] セクションに記載されていることを確認します。たとえば、Ansible に対して server.idm.example.com を設定するよう指示するには、以下を入力します。

    [ipaserver]
    server.idm.example.com
  3. Ansible Playbook ファイル (disallow-reverse-sync.yml) のコピーを作成します。以下に例を示します。

    $ cp disallow-reverse-sync.yml disallow-reverse-sync-copy.yml
  4. disallow-reverse-sync-copy.yml ファイルを開きます。
  5. ipadnsconfig タスクセクションに以下の変数を設定して、ファイルを調整します。

    • ipaadmin_password 変数は IdM 管理者パスワードに設定します。
    • allow_sync_ptr 変数を no に設定します。

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

    ---
    - name: Playbook to disallow reverse record synchronization
      hosts: ipaserver
      become: true
    
      tasks:
      - name: Disallow reverse record synchronization.
        ipadnsconfig:
          ipaadmin_password: Secret123
          allow_sync_ptr: no
  6. ファイルを保存します。
  7. Playbook を実行します。

    $ ansible-playbook -v -i inventory.file disallow-reverse-sync-copy.yml

関連情報

  • ansible-freeipa ipadnsconfig モジュールを使用した他の Ansible Playbook の例については、/usr/share/doc/ansible-freeipa/ ディレクトリーの README-dnsconfig.md Markdown ファイルを参照してください。このファイルには ipadnsconfig 変数の定義も含まれます。
  • ipadnsconfig モジュールを使用した他の Ansible Playbook の例は /usr/share/doc/ansible-freeipa/playbooks/dnsconfig ディレクトリーを参照してください。

第25章 Ansible Playbook を使用した IdM DNS ゾーンの管理

Identity Management (IdM) 管理者は、ansible-freeipa パッケージに含まれる dnszone モジュールを使用して IdM DNS ゾーンの動作を管理できます。本章では、以下のトピックおよび手順を説明します。

前提条件

25.1. サポート対象の DNS ゾーンタイプ

Identity Management (IdM) は、2 種類の DNS ゾーン (primary および forward) をサポートします。本セクションでは、この 2 種類のゾーンについて、また DNS 転送のシナリオ例を説明します。

注記

本ガイドでは、ゾーンタイプには BIND の用語を使用し、Microsoft Windows DNS で使用する用語とは異なります。BIND のプライマリーゾーンは、Microsoft Windows DNS の 正引きルックアップゾーン逆引きルックアップゾーン と同じ目的で使用されます。BIND の正引きゾーンは、Microsoft Windows DNS の 条件付きフォワーダー と同じ目的で使用されます。

プライマリー DNS ゾーン

プライマリー DNS ゾーンには、権威 DNS データが含まれ、DNS を動的に更新できます。この動作は、標準 BIND 設定の type master 設定と同じです。プライマリーゾーンは、ipa dnszone-* コマンドを使用して管理できます。

標準 DNS ルールに準拠するには、プライマリーゾーンすべてに start of authority (SOA) と nameserver (NS) レコードを含める必要があります。IdM では、DNS ゾーンの作成時にこれらのレコードが自動的に生成されますが、NS レコードを親ゾーンに手動でコピーして適切な委譲を作成する必要があります。

標準の BIND の動作に合わせて、権威サーバーではない名前のクエリーは、他の DNS サーバーに転送されます。DNS サーバー (別称: フォワーダー) は、クエリーに対して権威がある場合と、ない場合があります。

例25.1 DNS 転送のシナリオ例

IdM サーバーには test.example. プライマリーゾーンが含まれています。このゾーンには、sub.test.example. 名前の NS 委譲レコードが含まれます。さらに、test.example. ゾーンは、sub.text.example サブゾーンのフォワーダー IP アドレス 192.0.2.254 で設定されます。

クライアントが nonexistent.test.example. の名前をクエリーすると、NXDomain の応答を受け取りますが、IdM サーバーはこの名前に対して権威があるため、転送は発生しません。

反対に、host1.sub.test.example. の名前をクエリーすると、IdM サーバーはこの名前に対して権威がないので、設定済みのフォワーダー (192.0.2.254) に転送されます。

正引き DNS ゾーン

IdM の観点からは、正引き DNS ゾーンには権威データは含まれません。実際、正引きの「ゾーン」には、通常以下情報 2 つのみが含まれます。

  • ドメイン名
  • ドメインに関連付けられた DNS サーバーの IP アドレス

定義済みのドメインに所属する名前のクエリーはすべて、指定の IP アドレスに転送されます。この動作は、標準 BIND 設定の type forward 設定と同じです。正引きゾーンは、ipa dnsforwardzone-* コマンドを使用して管理できます。

正引き DNS ゾーンは、IdM-Active Directory (AD) 信頼のコンテキストで特に便利です。IdM DNS サーバーが idm.example.com ゾーンに対して、AD DNS サーバーが ad.example.com ゾーンに対して権威がある場合には、ad.example.comidm.example.com プライマリーゾーンの DNS 正引きゾーンになります。つまり、IP アドレスが somehost.ad.example.com の IdM クライアントからクエリーが送信されると、ad.example.com IdM DNS 正引きゾーンに指定の AD ドメインコントローラーに転送されます。

25.2. プライマリー IdM DNS ゾーンの設定属性

Identity Management (IdM) は、更新期間、転送設定、キャッシュ設定など、特定のデフォルト設定を指定して新しいゾーンを作成します。IdM DNS ゾーン属性 では、デフォルトのゾーン設定の属性を確認できます。これは、以下のオプションのいずれかを使用して変更できます。

ここではゾーンの実際の情報を設定するほか、DNS サーバーが start of authority (SOA) レコードエントリーを処理する方法と、DNS ネームサーバーからの記録を更新する方法を定義します。

表25.1 IdM DNS ゾーン属性

属性ansible-freeipa 変数説明

権威ネームサーバー

name_server

プライマリー DNS ネームサーバーのドメイン名 (別称: SOA MNAME) を設定します。

デフォルトでは、各 IdM サーバーは SOA MNAME フィールドで自己アドバタイズします。そのため、--name-server を使用して LDAP に保存されている値は無視されます。

管理者の電子メールアドレス

admin_email

ゾーン管理者が使用する電子メールアドレスを設定します。デフォルトでは、ホストの root アカウントになります。

SOA serial

serial

SOA レコードにシリアル番号を設定します。IdM ではバージョン番号が自動的に設定され、この番号のユーザーによる変更は想定されていません。

SOA refresh

refresh

セカンダリー DNS サーバーがプライマリ DNS サーバーから更新を要求するまでの待機時間を秒単位で設定します。

SOA retry

retry

失敗した更新操作を再試行するまでに待機する時間を秒単位で設定します。

SOA expire

expire

セカンダリー DNS サーバーが操作の試行を終了するまでに、更新操作を実行する時間を秒単位で設定します。

SOA minimum

minimum

RFC 2308 に準拠し、ネガティブキャッシュの TTL (TTL) 値を秒単位で設定します。

SOA time to live

ttl

ゾーン apex のレコードの TTL を秒単位で設定します。たとえば、example.com ゾーンでは、名前が example.com の全レコード (A、NS または SOA) は設定されますが、test.example.com などの他のドメイン名には影響はありません。

デフォルトの TTL

default_ttl

これまでに個別の Time To Live (TTL) 値が設定されたことのないゾーンで、すべての値のネガティブキャッシュのデフォルト TTL を秒単位で設定します。変更を有効にするには、すべての IdM DNS サーバーで named-pkcs11 サービスを再起動する必要があります。

BIND 更新ポリシー

update_policy

DNS ゾーンでクライアントに許可されるパーミッションを設定します。

Dynamic update

dynamic_update=TRUE|FALSE

クライアントの DNS レコードへの動的更新を有効にします。

false に設定すると、IdM クライアントマシンは IP アドレスを追加または更新できなくなる点に注意してください。

Allow transfer

allow_transfer=string

指定のゾーンを転送できる IP アドレスまたはネットワーク名のセミコロン区切りの一覧を指定します。

デフォルトでは、ゾーン転送は無効です。allow_transfer のデフォルト値は none です。

Allow query

allow_query

DNS クエリーを発行できる IP アドレスまたはネットワーク名のセミコロン区切りの一覧を指定します。

Allow PTR sync

allow_sync_ptr=1|0

ゾーンの A または AAAA レコード (正引きレコード) が自動的に PTR (逆引き) レコードと同期されるかどうかを設定します。

Zone forwarder

forwarder=IP_address

DNS ゾーン向けに特別に設定されたフォワーダーを指定します。これは、IdM ドメインで使用されるグローバルフォワーダーとは別のものです。

複数のフォワーダーを指定する場愛には、オプションを複数回使用します。

Forward policy

forward_policy=none|only|first

転送ポリシーを指定します。サポート対象のポリシーに関する情報は、「IdM での DNS 転送ポリシー」を参照してください。

関連情報

  • ansible-freeipa ipadnszone モジュールの他の定義は、/usr/share/doc/ansible-freeipa/ ディレクトリーの README-dnszone.md Markdown ファイルで確認できます。

25.3. Ansible を使用した IdM DNS でのプライマリーゾーンの作成

本セクションでは、Identity Management (IdM) の管理者が Ansible Playbook を使用して、プライマリー DNS ゾーンを存在させる手順を説明します。以下の手順で使用する例では、IdM 管理者は zone.idm.example.com の DNS ゾーンを追加します。

前提条件

  • Ansible コントローラーに ansible-freeipa パッケージがインストールされている。これは、この手順の内容を実行するホストです。
  • IdM 管理者パスワードが分かっている。

手順

  1. /usr/share/doc/ansible-freeipa/playbooks/dnszone ディレクトリーに移動します。

    $ cd /usr/share/doc/ansible-freeipa/playbooks/dnszone
  2. インベントリーファイルを開き、設定する IdM サーバーが [ipaserver] セクションに記載されていることを確認します。たとえば、Ansible に対して server.idm.example.com を設定するよう指示するには、以下を入力します。

    [ipaserver]
    server.idm.example.com
  3. Ansible Playbook ファイルのコピー (dnszone-present.yml) を作成します。以下に例を示します。

    $ cp dnszone-present.yml dnszone-present-copy.yml
  4. dnszone-present-copy.yml ファイルを開いて編集します。
  5. ipadnszone タスクセクションに以下の変数を設定してファイルを調整します。

    • ipaadmin_password 変数は IdM 管理者パスワードに設定します。
    • zone_name 変数は zone.idm.example.com に設定します。

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

    ---
    - name: Ensure dnszone present
      hosts: ipaserver
      become: true
    
      tasks:
      - name: Ensure zone is present.
        ipadnszone:
          ipaadmin_password: Secret123
          zone_name: zone.idm.example.com
          state: present
  6. ファイルを保存します。
  7. Playbook を実行します。

    $ ansible-playbook -v -i inventory.file dnszone-present-copy.yml

関連情報

  • DNS ゾーンの詳細は、「サポート対象の DNS ゾーンタイプ」を参照してください。
  • ansible-freeipa ipadnszone モジュールの Ansible Playbook の他のサンプルは、/usr/share/doc/ansible-freeipa/ ディレクトリーの README-dnszone.md Markdown ファイルで確認できます。このファイルには ipadnszone 変数の定義も含まれます。
  • /usr/share/doc/ansible-freeipa/playbooks/dnszone ディレクトリーで、ipadnszone モジュール向けの Ansible Playbook のサンプルを確認できます。

25.4. Ansible Playbook を使用して、変数が複数ある IdM にプライマリー DNS ゾーンを存在させる手順

本セクションでは、Identity Management (IdM) の管理者が Ansible Playbook を使用して、プライマリー DNS ゾーンを存在させる手順を説明します。以下の手順で使用する例では、IdM 管理者は zone.idm.example.com の DNS ゾーンを追加します。Ansible Playbook は、ゾーンのパラメーターを複数設定します。

前提条件

  • Ansible コントローラーに ansible-freeipa パッケージがインストールされている。これは、この手順の内容を実行するホストです。
  • IdM 管理者パスワードが分かっている。

手順

  1. /usr/share/doc/ansible-freeipa/playbooks/dnszone ディレクトリーに移動します。

    $ cd /usr/share/doc/ansible-freeipa/playbooks/dnszone
  2. インベントリーファイルを開き、設定する IdM サーバーが [ipaserver] セクションに記載されていることを確認します。たとえば、Ansible に対して server.idm.example.com を設定するよう指示するには、以下を入力します。

    [ipaserver]
    server.idm.example.com
  3. Ansible Playbook ファイルのコピー (dnszone-all-params.yml) を作成します。以下に例を示します。

    $ cp dnszone-all-params.yml dnszone-all-params-copy.yml
  4. dnszone-all-params-copy.yml ファイルを開いて編集します。
  5. ipadnszone タスクセクションに以下の変数を設定してファイルを調整します。

    • ipaadmin_password 変数は IdM 管理者パスワードに設定します。
    • zone_name 変数は zone.idm.example.com に設定します。
    • 正引きレコードと逆引きレコードを同期できるように場合は (A および AAAA レコードを PTR レコードと同期)、allow_sync_ptr 変数を true に設定します。
    • dynamic_update 変数は、true に設定して、IdM クライアントマシンが IP アドレスを追加または更新できるようにします。
    • dnssec 変数は、true に設定して、ゾーン内のレコードのインラインの DNSSEC 署名を許可します。
    • allow_transfer 変数は、ゾーン内のセカンダリーネームサーバーの IP アドレスに設定します。
    • allow_query 変数は、クエリーを発行できる IP アドレスまたはネットワークに設定します。
    • forwarders 変数は、グローバルフォワーダー の IP アドレスに設定します。
    • serial 変数は SOA レコードのシリアル番号に設定します。
    • ゾーン内の DNS レコードの refreshretryexpireminimumttl および default_ttl の値を定義します。
    • nsec3param_rec 変数を使用して、ゾーンの NSEC3PARAM レコードを定義します。
    • skip_overlap_check 変数は、true に設定して、既存のゾーンと重複していても DNS を強制的に作成します。
    • skip_nameserver_check は、true に設定して、ネームサーバーが解決できない場合でも DNS ゾーンを強制的に作成します。

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

    ---
    - name: Ensure dnszone present
      hosts: ipaserver
      become: true
    
      tasks:
      - name: Ensure zone is present.
        ipadnszone:
          ipaadmin_password: Secret123
          zone_name: zone.idm.example.com
          allow_sync_ptr: true
          dynamic_update: true
          dnssec: true
          allow_transfer:
            - 1.1.1.1
            - 2.2.2.2
          allow_query:
            - 1.1.1.1
            - 2.2.2.2
          forwarders:
            - ip_address: 8.8.8.8
            - ip_address: 8.8.4.4
              port: 52
          serial: 1234
          refresh: 3600
          retry: 900
          expire: 1209600
          minimum: 3600
          ttl: 60
          default_ttl: 90
          name_server: server.idm.example.com.
          admin_email: admin.admin@idm.example.com
          nsec3param_rec: "1 7 100 0123456789abcdef"
          skip_overlap_check: true
          skip_nameserver_check: true
          state: present
  6. ファイルを保存します。
  7. Playbook を実行します。

    $ ansible-playbook -v -i inventory.file dnszone-all-params-copy.yml

関連情報

  • DNS ゾーンの詳細は、「サポート対象の DNS ゾーンタイプ」を参照してください。
  • IdM で設定できる DNS ゾーン属性の詳細は、「プライマリー IdM DNS ゾーンの設定属性」を参照してください。
  • ansible-freeipa ipadnszone モジュールの Ansible Playbook の他のサンプルは、/usr/share/doc/ansible-freeipa/ ディレクトリーの README-dnszone.md Markdown ファイルで確認できます。このファイルには ipadnszone 変数の定義も含まれます。
  • /usr/share/doc/ansible-freeipa/playbooks/dnszone ディレクトリーで、ipadnszone モジュール向けの Ansible Playbook のサンプルを確認できます。

25.5. IP アドレスが指定されている場合に Ansible Playbook を使用して逆引き DNS ルックアップのゾーンを存在させる手順

本セクションでは、Identity Management (IdM) の管理者が Ansible Playbook を使用して、逆引き DNS ゾーンを存在させる手順を説明します。以下の手順で使用する例では、IdM 管理者は、IdM ホストの IP アドレスおよび接頭辞長を使用して、逆引き DNS ルックアップゾーンを追加します。

name_from_ip 変数を使用して DNS サーバーの IP アドレスの接頭辞の長さを指定すると、ゾーン名を制御できます。接頭辞の長さを指定しない場合には、システムが DNS サーバーにゾーンに関するクエリーを出し、192.168.1.2name_from_ip の値をもとに、このクエリーで、以下の DNS ゾーンのいずれかを返します。

  • 1.168.192.in-addr.arpa.
  • 168.192.in-addr.arpa.
  • 192.in-addr.arpa.

クエリーが返すゾーンは想定しているゾーンとは異なる可能性があるため、ゾーンが誤って削除されないように state オプションが present に設定されている場合のみ、name_from_ip を使用できます。

前提条件

  • Ansible コントローラーに ansible-freeipa パッケージがインストールされている。これは、この手順の内容を実行するホストです。
  • IdM 管理者パスワードが分かっている。

手順

  1. /usr/share/doc/ansible-freeipa/playbooks/dnszone ディレクトリーに移動します。

    $ cd /usr/share/doc/ansible-freeipa/playbooks/dnszone
  2. インベントリーファイルを開き、設定する IdM サーバーが [ipaserver] セクションに記載されていることを確認します。たとえば、Ansible に対して server.idm.example.com を設定するよう指示するには、以下を入力します。

    [ipaserver]
    server.idm.example.com
  3. Ansible Playbook ファイルのコピー (dnszone-reverse-from-ip.yml) を作成します。以下に例を示します。

    $ cp dnszone-reverse-from-ip.yml dnszone-reverse-from-ip-copy.yml
  4. dnszone-reverse-from-ip-copy.yml ファイルを開いて編集します。
  5. ipadnszone タスクセクションに以下の変数を設定してファイルを調整します。

    • ipaadmin_password 変数は IdM 管理者パスワードに設定します。
    • name_from_ip 変数は IdM ネームサーバーの IP に設定し、接頭辞の長さを指定します。

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

      ---
      - name: Ensure dnszone present
        hosts: ipaserver
        become: true
      
        tasks:
        - name: Ensure zone for reverse DNS lookup is present.
          ipadnszone:
            ipaadmin_password: Secret123
            name_from_ip: 192.168.1.2/24
            state: present
          register: result
        - name: Display inferred zone name.
          debug:
            msg: "Zone name: {{ result.dnszone.name }}"

    この Playbook は、IP アドレス 192.168.1.2 と接頭辞長 24 をもとに、逆引き DNS ルックアップのゾーンを作成します。次に、Playbook は生成されたゾーン名を表示します。

  6. ファイルを保存します。
  7. Playbook を実行します。

    $ ansible-playbook -v -i inventory.file dnszone-reverse-from-ip-copy.yml

関連情報

  • DNS ゾーンの詳細は、「サポート対象の DNS ゾーンタイプ」を参照してください。
  • ansible-freeipa ipadnszone モジュールの Ansible Playbook の他のサンプルは、/usr/share/doc/ansible-freeipa/ ディレクトリーの README-dnszone.md Markdown ファイルで確認できます。このファイルには ipadnszone 変数の定義も含まれます。
  • /usr/share/doc/ansible-freeipa/playbooks/dnszone ディレクトリーで、ipadnszone モジュール向けの Ansible Playbook のサンプルを確認できます。

第26章 IdM での DNS の場所の管理

Identity Management (IdM) 管理者は、ansible-freeipa パッケージで利用可能な location モジュールを使用して IdM DNS の場所を管理できます。本章では、以下のトピックおよび手順を説明します。

26.1. DNS ベースのサービス検出

DNS ベースのサービス検出は、クライアントが DNS プロトコルを使用するプロセスで、LDAPKerberos など、特定のサービスを提供するネットワークでサーバーを見つけ出します。一般的な操作の 1 つとして、クライアントが最寄りのネットワークインフラストラクチャー内にある認証サーバーを特定できるようにすることが挙げられます。理由は、スループットが向上してネットワークレイテンシーが短縮されるので全体的なコスト削減を図ることができるためです。

サービス検出の主な利点は以下のとおりです。

  • 近くにあるサーバーの名前を明示的に設定する必要がない。
  • DNS サーバーをポリシーの中央プロバイダーとして使用する。同じ DNS サーバーを使用するクライアントは、サービスプロバイダーと優先順序に関する同じポリシーにアクセスできます。

Identity Management (IdM) ドメインには、LDAPKerberos、およびその他のサービスに DNS サービスレコード (SRV レコード) があります。たとえば、次のコマンドは、IdM DNS ドメインで TCP ベースの Kerberos サービスを提供するホストの DNS サーバーをクエリーします。

例26.1 DNS の場所に関する独立した結果

$ dig -t SRV +short _kerberos._tcp.idm.example.com
0 100 88 idmserver-01.idm.example.com.
0 100 88 idmserver-02.idm.example.com.

出力には、以下の情報が含まれます。

  • 0 (優先度): ターゲットホストの優先度。値が小さいほど優先度が高くなります。
  • 100 (加重)。優先順位が同じエントリーの相対的な重みを指定します。詳細は RFC 2782, section 3 を参照してください。
  • 88 (ポート番号): サービスのポート番号
  • サービスを提供するホストの正規名。

この例では、2 つのホスト名が返され、優先順位と重みが同じです。この場合には、クライアントは結果リストから無作為にエントリーを使用します。

クライアントの場合、DNS の場所で設定された DNS サーバーをクエリーするように設定されていたため、出力は異なります。場所が割り当てられた IdM サーバーの場合は、カスタマイズした値が返されます。以下の例では、クライアントは場所 germany の DNS サーバーにクエリーするように設定されています。

例26.2 DNS の場所ベースの結果

$ dig -t SRV +short _kerberos._tcp.idm.example.com
_kerberos._tcp.germany._locations.idm.example.com.
0 100 88 idmserver-01.idm.example.com.
50 100 88 idmserver-02.idm.example.com.

IdM DNS サーバーは、ローカルサーバーを優先する DNS の場所固有の SRV レコードを参照する DNS エイリアス (CNAME) を自動的に返します。この CNAME レコードは、出力の最初の行に表示されます。この例では、idm server-01.idm.example.com のホストの優先度の値が最も小さいため、推奨されます。idmserver-02.idm.example.com の優先度の値が高く、推奨されるホストが使用できない場合にバックアップとしてのみ使用されます。

26.2. DNS の場所のデプロイに関する考慮事項

Identity Management (IdM) は、統合 DNS を使用する際に、場所固有のサービス (SRV) レコードを生成できます。各 IdM DNS サーバーはロケーション固有の SRV レコードを生成するため、DNS の場所ごとに 1 つ以上の IdM DNS サーバーをインストールする必要があります。

クライアントの DNS の場所に対するアフィニティーは、クライアントが受け取った DNS レコードでのみ定義されます。そのため、DNS のサービス検出を行うクライアントが、IdM DNS サーバーからの場所固有のレコードを解決した場合には、IdM DNS サーバーと IdM 以外の DNS コンシューマーサーバーと recursor を組み合わせることができます。

IdM サービスおよび IdM DNS サービス以外のほとんどのデプロイメントでは、DNS recursor はラウンドトリップタイム (RTT) メトリックを使用して、最寄りの IdM DNS サーバーを自動的に選択します。通常、IdM DNS サーバーを使用するクライアントが、最寄りの DNS の場所のレコードを取得し、最寄りの DNS サーバーの最適なセットを使用するようになります。

26.3. DNS の Time to live (TTL)

クライアントは、ゾーンの設定に指定された期間の DNS リソースレコードをキャッシュできます。このキャッシュにより、クライアントは Time to Live (TTL) 値の有効期限が切れるまで変更を受け取れない場合があります。Identity Management (IdM) のデフォルトの TTL 値は 1 日 です。

クライ