Red Hat Training

A Red Hat training course is available for RHEL 8

Identity Management のインストール

Red Hat Enterprise Linux 8

Identity Management の使用

概要

本書は、Red Hat Enterprise Linux 8 (RHEL) に Identity Management をインストールする方法と、RHEL 7 からアップグレードする方法を説明します。

オープンソースをより包摂的に

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 をクリックします。

パート I. Identity Management のインストール

第1章 IdM サーバーをインストールするためのシステムの準備

ここでは、Identity Managementt (IdM) サーバーのインストール要件を取り上げます。インストールを行う前に、システムがその要件を満たしていることを確認してください。

1.1. IdM サーバーのインストール時の認可要件

ホストコンピューターに Identity Management (IdM) サーバーをインストールするには、root 特権が必要です。

1.2. ハードウェア推奨事項

ハードウェアでは、RAM の容量を適切に確保することが最も重要になります。システムに十分な RAM があるようにしてください。一般的な RAM の要件は次のとおりです。

  • 10,000 ユーザーおよび 100 グループには、最低 4 GB の RAM と 4 GB のスワップ領域を割り当てます。
  • 100,000 ユーザーおよび 50,000 グループには、最低 16 GB の RAM と 4 GB のスワップ領域を割り当てます。

大規模なデプロイメントでは、データのほとんどがキャッシュに保存されるため、ディスクスペースを増やすよりも RAM を増やす方が効果的です。通常、RAM を追加すると、キャッシュにより大きなデプロイメントのパフォーマンスが向上します。

注記

基本的なユーザーエントリーまたは証明書のあるシンプルなホストエントリーのサイズは約 5 ~ 10 KB になります。

1.3. IdM のカスタム設定要件

DNS、Kerberos、Apache、Directory Server などのサービスのカスタム設定を行わずに、クリーンなシステムに Identity Managementt (IdM) をインストールします。

IdM サーバーのインストールは、システムファイルを上書きして、IdM ドメインを設定します。IdM は、元のシステムファイルを /var/lib/ipa/sysrestore/ にバックアップします。ライフサイクルの最後に Identity Management サーバーをアンインストールすると、このファイルが復元します。

IdM における IPv6 要件

IdM システムでは、カーネル内で IPv6 プロトコルが有効になっている必要があります。IPv6 が無効になっていると、IdM サービスが使用する CLDAP プラグインが初期化に失敗します。

注記

ネットワーク上で IPv6 を有効にする必要はありません。

IdM における暗号化タイプのサポート

Red Hat Enterprise Linux (RHEL) は、Kerberos プロトコルのバージョン 5 を使用します。これは、Advanced Encryption Standard (AES)、Camel、Data Encryption Standard (DES) などの暗号化タイプをサポートします。

サポートされる暗号化タイプの一覧

IdM サーバーおよびクライアントの Kerberos ライブラリーは、より多くの暗号化タイプに対応している可能性がありますが、IdM Kerberos Distribution Center (KDC) は以下の暗号化タイプのみに対応します。

  • aes256-cts:normal
  • aes256-cts:special (default)
  • aes128-cts:normal
  • aes128-cts:special (デフォルト)
  • aes128-sha2:normal
  • aes128-sha2:special
  • aes256-sha2:normal
  • aes256-sha2:special
  • camellia128-cts-cmac:normal
  • camellia128-cts-cmac:special
  • camellia256-cts-cmac:normal
  • camellia256-cts-cmac:special

RC4 暗号化タイプがデフォルトで無効

以下の RC4 暗号化は、新しい暗号化タイプ AES-128 および AES-256 よりも安全ではないと見なされるため、RHEL 8 ではデフォルトで非推奨となり、無効にされています。

  • arcfour-hmac:normal
  • arcfour-hmac:special

古い Active Directory 環境との互換性のために RC4 サポートを手動で有効にする方法は、「AD および RHEL で一般的な暗号化タイプに対応」を参照してください。

DES および 3DES 暗号化のサポートが削除される

セキュリティー上の理由から、DES アルゴリズムへの対応は RHEL 7 では非推奨となりました。RHEL 8.3.0 での Kerberos パッケージのリベースにより、RHEL 8 からシングル DES (DES) およびトリプル DES (3DES) 暗号化タイプのサポートが削除されました。

注記

標準の RHEL 8 IdM インストールでは、DES または 3DES 暗号化タイプはデフォルトでは使用されず、Kerberos のアップグレードによる影響を受けません。

DES や 3DES 暗号化 のみ を使用するようにサービスまたはユーザーを手動で設定すると (レガシークライアントなど)、最新の Kerberos パッケージに更新した後にサービスが中断される可能性があります。

  • Kerberos 認証エラー
  • unknown enctype 暗号化エラー
  • DES で暗号化されたデータベースマスターキー(K/M)を使用する KDC が起動に失敗する

Red Hat では、お使いの環境で DES または 3DES 暗号化を使用しないことを推奨します。

注記

DES および 3DES 暗号化タイプは、環境で使用するように設定している場合に限り無効にする必要があります。

IdM でのシステム全体の暗号化ポリシーへの対応

IdM は、DEFAULT システム全体の暗号化ポリシーを使用します。このポリシーは、現在の脅威モデルに安全な設定を提供します。TLS プロトコル 1.2 と 1.3、IKEv2 プロトコル、および SSH2 プロトコルが使用できます。RSA 鍵と Diffie-Hellman パラメーターは長さが 2048 ビット以上であれば許容されます。このポリシーでは、DES、3DES、RC4、DSA、TLS v1.0、およびその他の弱いアルゴリズムを使用できません。

注記

FUTURE システム全体の暗号化ポリシーの使用中は、IdM サーバーをインストールできません。IdM サーバーをインストールする場合は、DEFAULT システム全体の暗号化ポリシーを使用していることを確認してください。

FIPS コンプライアンス

RHEL 8.3.0 以降では、連邦情報処理規格 (FIPS) モードが有効になっているシステムに、新しい IdM サーバーまたはレプリカをインストールできます。

FIPS モードで IdM をインストールするには、ホストで FIPS モードを有効にしてから、IdM をインストールします。IdM インストールスクリプトは、FIPS が有効かどうかを検出し、IdM が FIPS 140-2 に準拠する暗号化タイプのみを使用するように設定します。

  • aes256-cts:normal
  • aes256-cts:special
  • aes128-cts:normal
  • aes128-cts:special
  • aes128-sha2:normal
  • aes128-sha2:special
  • aes256-sha2:normal
  • aes256-sha2:special

IdM 環境が FIPS に準拠するには、すべて の IdM レプリカで FIPS モードが有効になっている必要があります。

特にクライアントを IdM レプリカにプロモートする場合、Red Hat ではIdM クライアントでも FIPS を有効にすることを推奨します。最終的には、管理者が FIPS 要件を満たす方法を判別する必要があります。Red Hat は FIPS 基準を強要しません。

FIPS モードが有効なフォレスト間の信頼のサポート

FIPS モードが有効な場合に Active Directory (AD) ドメインでフォレスト間の信頼を確立するには、以下の要件を満たす必要があります。

  • RHEL 8.4.0 以降の IdM サーバーを使用する。
  • 信頼の設定時に、AD 管理アカウントで認証する必要がある。FIPS モードが有効な場合には、共有シークレットを使用して信頼を確立することはできません。
重要

RADIUS 認証は FIPS に準拠していません。RADIUS プロトコルは MD5 ハッシュ機能を使用してクライアントとサーバー間のパスワードを暗号化し、FIPS モードでは、OpenSSL は MD5 ダイジェストアルゴリズムの使用を無効にするためです。ただし、RADIUS サーバーが IdM サーバーと同じホストで実行されている場合は、「How to configure FreeRADIUS authentication in FIPS mode」で説明されている手順を実行して、問題を回避してMD5 を有効にすることができます。

関連情報

1.4. IdM のタイムサービス要件

以下のセクションでは、chronyd を使用して、IdM ホストを中央タイムソースと同期させる方法を説明します。

1.4.1. IdM で chronyd を同期に使用する方法

IdM の基礎となる認証メカニズムである Kerberos は、プロトコルの一部としてタイムスタンプを使用します。IdM クライアントのシステム時間が、KDC (Key Distribution Center) のシステム時間と比べて 5 分以上ずれると、Kerberos 認証に失敗します。

IdM インストールスクリプトは、IdM サーバーおよびクライアントが中央タイムソースと同期したままになるように、chronyd Network Time Protocol (NTP) クライアントソフトウェアを自動設定します。

IdM インストールコマンドに NTP オプションを指定しないと、インストーラーは、ネットワークの NTP サーバーを参照する _ntp._udp DNS サービス (SRV) レコードを検索し、その IP アドレスで chrony を設定します。_ntp._udp SRV レコードがない場合は、chronydchrony パッケージに同梱の設定を使用します。

注記

RHEL 8 では chronyd が優先されるため、ntpd は非推奨となっており、IdM サーバーは Network Time Protocol (NTP) サーバーとして設定されず、NTP クライアントとしてのみ設定されます。RHEL 7 の NTP サーバー の IdM サーバーロールも、RHEL 8 では非推奨になりました。

1.4.2. IdM インストールコマンドの NTP 設定オプションの一覧

IdM インストールコマンド (ipa-server-installipa-replica-installipa-client-install) のいずれかを指定して、設定時に chronyd クライアントソフトウェアを設定できます。

表1.1 IdM インストールコマンドの NTP 設定オプションの一覧

オプション動作

--ntp-server

これを使用して NTP サーバーを 1 つ指定します。複数回使用して、複数のサーバーを指定できます。

--ntp-pool

複数の NTP サーバーのプールを指定して、1 つのホスト名として解決する場合には、これを使用します。

-N, --no-ntp

chronyd の設定、起動、有効化はしないでください。

1.4.3. IdM が NTP タイムサーバーを参照できるようにする方法

この手順では、Network Time Protocol (NTP) タイムサーバーとの同期できるように、IdM で必要とされる設定があるかどうかを確認します。

前提条件

  • お使いの環境で NTP タイムサーバーを設定している。この例では、以前に設定したタイムサーバーのホスト名は ntpserver.example.com です。

手順

  1. 環境内で NTP サーバーの DNS サービス (SRV) レコード検索を実行します。

    [user@server ~]$ dig +short -t SRV _ntp._udp.example.com
    0 100 123 ntpserver.example.com.
  2. 以前の dig 検索でタイムサーバーが返されない場合は、ポート 123 でタイムサーバーを参照する _ntp._udp SRV レコードを追加します。このプロセスは、お使いの DNS ソリューションにより異なります。

検証手順

  • _ntp._udp SRV レコードの検索時に、DNS がポート 123 でタイムサーバーのエントリーが返されることを確認します。

    [user@server ~]$ dig +short -t SRV _ntp._udp.example.com
    0 100 123 ntpserver.example.com.

1.4.4. 関連情報

1.5. IdM のホスト名および DNS 要件

本セクションでは、サーバーシステムとレプリカシステムのホスト名と DNS 要件を説明します。また、システムが要件を満たしていることを検証する方法も説明します。

ここで取り上げている要件は、統合 DNS の有無に関わらず、すべての Identity Management (IdM) サーバーに適用されます。

警告

DNS レコードは、稼働中の LDAP ディレクトリーサービス、Kerberos、Active Directory 統合など、ほぼすべての IdM ドメイン機能で必須となります。以下の点を確認し、十分注意してください。

  • テスト済みの機能する DNS サービスが利用可能である。
  • サービスが適切に設定されている。

この要件は、統合 DNS の 有無に関わらず、IdM サーバーに適用されます。

サーバーのホスト名の検証

ホスト名は、完全修飾ドメイン名 (例: server.idm.example.com) である必要があります。

重要

.company など、単一ラベルのドメイン名を使用しないでください。IdMドメインは、トップレベルドメインと、1 つ以上のサブドメイン (example.comcompany.example.com など) で構成する必要があります。

完全修飾ドメイン名は、以下の条件を満たす必要があります。

  • 数字、アルファベット文字、およびハイフン (-) のみが使用される有効な DNS 名である。ホスト名でアンダーライン (_) を使用すると DNS が正常に動作しません。
  • すべてが小文字である。大文字は使用できません。
  • ループバックアドレスに解決されない。127.0.0.1 ではなく、システムのパブリック IP アドレスに解決される必要があります。

ホスト名を検証するには、インストールするシステムで hostname ユーティリティーを使用します。

# hostname
server.idm.example.com

hostname の出力は、localhost または localhost6 以外である必要があります。

正引きおよび逆引きの DNS 設定の確認
  1. サーバーの IP アドレスを取得します。

    1. ip addr show コマンドを実行すると、IPv4 アドレスと IPv6 アドレスの両方が表示されます。以下の例では、スコープがグローバルであるため、対応する IPv6 アドレスは 2001:DB8::1111 となります。

      [root@server ~]# ip addr show
      ...
      2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
      	link/ether 00:1a:4a:10:4e:33 brd ff:ff:ff:ff:ff:ff
      	inet 192.0.2.1/24 brd 192.0.2.255 scope global dynamic eth0
      		valid_lft 106694sec preferred_lft 106694sec
      	inet6 2001:DB8::1111/32 scope global dynamic
       		valid_lft 2591521sec preferred_lft 604321sec
      	inet6 fe80::56ee:75ff:fe2b:def6/64 scope link
      	       valid_lft forever preferred_lft forever
      ...
  2. dig ユーティリティーを使用して、正引き DNS 設定を確認します。

    1. dig +short server.idm.example.com A コマンドを実行します。返される IPv4 アドレスは、ip addr show により返される IP アドレスと一致する必要があります。

      [root@server ~]# dig +short server.idm.example.com A
      192.0.2.1
    2. dig +short server.idm.example.com AAAA コマンドを実行します。このコマンドに返されるアドレスは、ip addr show により返される IPv6 アドレスと一致する必要があります。

      [root@server ~]# dig +short server.idm.example.com AAAA
      2001:DB8::1111
      注記

      dig により AAAA レコードの出力が返されなくても、設定が間違っているわけではありません。出力されないのは、DNS にシステムの IPv6 アドレスが設定されていないためです。ネットワークで IPv6 プロトコルを使用する予定がない場合は、この状況でもインストールを続行できます。

  3. 逆引き DNS 設定 (PTR レコード) を確認します。dig ユーティリティーを使用し、IP アドレスを追加します。

    以下のコマンドで別のホスト名が表示されたり、ホスト名が表示されない場合、逆引き DNS 設定は正しくありません。

    1. dig +short -x IPv4_address コマンドを実行します。出力には、サーバーホスト名が表示されるはずです。以下に例を示します。

      [root@server ~]# dig +short -x 192.0.2.1
      server.idm.example.com
    2. 前の手順で実行した dig +short -x server.idm.example.com AAAA コマンドにより IPv6 アドレスが返された場合は、dig を使用して IPv6 アドレスのクエリーを実行します。出力には、サーバーホスト名が表示されるはずです。以下に例を示します。

      [root@server ~]# dig +short -x 2001:DB8::1111
      server.idm.example.com
      注記

      前の手順で dig +short server.idm.example.com AAAA コマンドにより IPv6 アドレスが返されなかった場合は、AAAA レコードのクエリーを実行しても、何も出力されません。この場合、これは正常な動作で、誤った設定を示すものではありません。

      警告

      逆引き DNS (PTR レコード) の検索が複数のホスト名を返すと、httpd、および IdM に関連付けられた他のソフトウェアで予期しない動作が表示される場合があります。Red Hat は、1 つの IP につき 1 つの PTR レコードを設定することを強く推奨します。

DNS フォワーダーの規格準拠の確認 (統合 DNS の場合のみ必要)

IdM DNS サーバーで使用するすべての DNS フォワーダーが EDNS0 (Extension Mechanisms for DNS) および DNSSEC (DNS Security Extensions) の規格に準拠していることを確認します。具体的には、フォワーダーごとに、次のコマンドの出力を確認します。

$ dig +dnssec @IP_address_of_the_DNS_forwarder . SOA

コマンドの出力には、以下の情報が含まれます。

  • 状態 - NOERROR
  • フラグ - ra
  • EDNS フラグ - do
  • ANSWER セクションには RRSIG レコードが必要です。

出力に上記のいずれかの項目がない場合は、使用している DNS フォワーダーのドキュメントに従い、EDNS0 と DNSSEC に対応し、ともに有効になっていることを確認してください。BIND サーバーの最新バージョンでは、dnssec-enable yes; オプションが /etc/named.conf ファイルに設定されている必要があります。

dig により生成された出力の例

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48655
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096

;; ANSWER SECTION:
. 31679 IN SOA a.root-servers.net. nstld.verisign-grs.com. 2015100701 1800 900 604800 86400
. 31679 IN RRSIG SOA 8 0 86400 20151017170000 20151007160000 62530 . GNVz7SQs [...]
/etc/hosts ファイルの確認

/etc/hosts ファイルが以下のいずれかの条件を満たすことを確認します。

  • このファイルには、ホストのエントリーが含まれません。ホストの IPv4 および IPv6 の localhost エントリー一覧のみを表示します。
  • このファイルには、ホストのエントリーが含まれ、ファイルには以下の条件がすべて満たされます。

    • 最初の 2 つのエントリーは、IPv4 および IPv6 の localhost エントリーです。
    • その次のエントリーは、IdM サーバーの IPv4 アドレスとホスト名を指定します。
    • IdM サーバーの FQDN は、IdM サーバーの省略名の前に指定します。
    • IdM サーバーのホスト名は、localhost エントリーには含まれません。

    以下は、適切に設定された /etc/hosts ファイルの例になります。

127.0.0.1   localhost localhost.localdomain \
localhost4 localhost4.localdomain4
::1         localhost localhost.localdomain \
localhost6 localhost6.localdomain6
192.0.2.1	server.idm.example.com	server
2001:DB8::1111	server.idm.example.com	server

1.6. IdM のポート要件

Identity Management (IdM) は、複数の ポート を使用して、そのサービスと対話します。IdM サーバーが動作するには、このようなポートを開いて IdM サーバーへの着信接続に利用できるようにする必要があります。別のサービスで現在使用されているポートや、ファイアウォール によりブロックされているポートは使用しないでください。

表1.2 IdM ポート

サービスポートプロトコル

HTTP/HTTPS

80、443

TCP

LDAP/LDAPS

389、636

TCP

Kerberos

88、464

TCP および UDP

DNS

53

TCP および UDP (任意)

NTP

123

UDP (任意)

さらに、内部で使用されるポート 8080、8443、および 749 が未使用である必要があります。これらのポートは開かず、ファイアウォールによりブロックされたままにしてください。

表1.3 firewalld サービス

サービス名詳細は、次を参照してください。

freeipa-ldap

/usr/lib/firewalld/services/freeipa-ldap.xml

freeipa-ldaps

/usr/lib/firewalld/services/freeipa-ldaps.xml

dns

/usr/lib/firewalld/services/dns.xml

1.7. IdM で必要なポートの開放

手順

  1. firewalld サービスが実行中である必要があります。

    • firewalld が実行中であることを確認するには、次のコマンドを実行します。

      # systemctl status firewalld.service
    • firewalld を起動し、システム起動時に自動的に起動するように設定するには、次のコマンドを実行します。

      # systemctl start firewalld.service
      # systemctl enable firewalld.service
  2. firewall-cmd ユーティリティーを使用して必要なポートを開きます。以下のいずれかのオプションを選択します。

    1. firewall-cmd --add-port コマンドを使用して個別のポートをファイアウォールに追加します。たとえば、デフォルトゾーンでポートを開くには、次のコマンドを実行します。

      # firewall-cmd --permanent --add-port={80/tcp,443/tcp,389/tcp,636/tcp,88/tcp,88/udp,464/tcp,464/udp,53/tcp,53/udp,123/udp}
    2. firewall-cmd --add-service コマンドを使用して、firewalld サービスをファイアウォールに追加します。たとえば、デフォルトゾーンでポートを開くには、次のコマンドを実行します。

      # firewall-cmd --permanent --add-service={freeipa-ldap,freeipa-ldaps,dns}

      firewall-cmd を使用してシステムでポートを開く方法は、man ページの firewall-cmd(1) を参照してください。

  3. firewall-cmd 設定を再ロードして、変更が即座に反映されるようにします。

    # firewall-cmd --reload

    実稼働システムで firewalld を再ロードすると、DNS の接続がタイムアウトになる可能性があることに注意してください。必要な場合は、以下の例のように firewall-cmd コマンドで --runtime-to-permanent オプションを指定して、タイムアウトが発生しないようにし、変更を永続化します。

    # firewall-cmd --runtime-to-permanent
  4. オプション:ポートが現在利用可能であるかを確認するには、nc ユーティリティー、telnet ユーティリティー、または nmap ユーティリティーを使用して、ポートへの接続またはポートスキャンの実行を行います。
注記

さらに、着信および送信トラフィックの両方でネットワークベースのファイアウォールを開く必要があることに注意してください。

1.8. IdM サーバーに必要なパッケージのインストール

RHEL 8 では、Identity Management (IdM) サーバーのインストールに必要なパッケージはモジュールとして同梱されています。IdM サーバーモジュールストリームは DL1 ストリームと呼ばれ、このストリームからパッケージをダウンロードする前に、このストリームを有効にする必要があります。以下の手順は、IdM の環境設定に必要なパッケージのダウンロード方法を示しています。

前提条件

  • RHEL システムを新しくインストールしている。
  • 必要なリポジトリーを利用できるようにしている。

    RHSM を使用して特定のリポジトリーを有効または無効にする方法は、「Red Hat Subscription Manager でオプションの設定」を参照してください。

    • RHEL システムがクラウドで実行している場合は、登録を省略します。必要なリポジトリーは、Red Hat Update Infrastructure (RHUI) から入手できます。
  • IdM モジュールストリームを有効にしていない。

手順

  1. idm:DL1 ストリームを有効にします。

    # yum module enable idm:DL1
  2. idm:DL1 ストリーム経由で配信される RPM に切り替えます。

    # yum distro-sync
  3. IdM の要件に応じて、以下のいずれかのオプションを選択します。

    • 統合 DNS のない IdM サーバーのインストールに必要なパッケージをダウンロードします。

      # yum module install idm:DL1/server
    • 統合 DNS のある IdM サーバーのインストールに必要なパッケージをダウンロードするには、次のコマンドを実行します。

      # yum module install idm:DL1/dns
    • Active Directory と信頼関係のある IdM サーバーのインストールに必要なパッケージをダウンロードするには、次のコマンドを実行します。

      # yum module install idm:DL1/adtrust
    • adtrust プロファイルや dns プロファイルからパッケージをダウンロードするには、次のコマンドを実行します。

      # yum module install idm:DL1/{dns,adtrust}
    • IdM クライアントのインストールに必要なパッケージをダウンロードするには、次のコマンドを実行します。

      # yum module install idm:DL1/client
重要

別のストリームが有効になっていて、そのストリームからパッケージをダウンロードしたあとに、新しいモジュールストリームに切り替える場合は、インストール済みの関連コンテンツをすべて明示的に削除し、現在のモジュールストリームを無効にしてから、新しいモジュールストリームを有効にする必要があります。現在のストリームを無効にせずに新しいストリームを有効にしようとすると、エラーが発生します。続行方法の詳細は「後続のストリームへの切り替え」を参照してください。

警告

モジュールからパッケージを個別にインストールすることは可能ですが、そのモジュールの「API」外のパッケージをインストールすると、Red Hat のサポート範囲は、そのモジュールに関連する場合に制限されます。たとえば、bind-dyndb-ldap をリポジトリーから直接インストールして、カスタムの 389 Directory Server セットアップで使用する場合に発生した問題は、IdM でも発生する場合を除きサポートされません。

第2章 IdM サーバーのインストール: 統合 DNS と統合 CA を root CA として使用する場合

統合 DNS のある新しい Identity Management (IdM) サーバーをインストールすると、次のような利点があります。

  • ネイティブの IdM ツールを使用すると、メンテナンスおよび DNS レコードの管理のほとんどを自動化できます。たとえば、DNS SRV レコードは、セットアップ中に自動的に作成され、その後は自動的に更新されます。
  • IdM サーバーのインストール時にグローバルフォワーダーを設定すると、インターネットとの安定した接続を確立できます。グローバルフォワーダーは、Active Directory との信頼関係にも便利です。
  • IdM ドメインからのメールが、IdM ドメイン外のメールサーバーによってスパムと見なされないように、DNS 逆ゾーンを設定できます。

統合 DNS のある IdM のインストールにはいくつかの制限があります。

  • IdM DNS は、一般用途の DNS サーバーとして使用することは想定されていません。高度な DNS 機能の一部はサポートされていません。

本章では、認証局 (CA) をルート CA として新しい IdM サーバーをインストールする方法を説明します。

注記

ipa-server-install コマンドのデフォルト設定は、統合 CA をルート CA とします。--external-ca--ca-less が指定された場合など、CA オプションがない場合、IdM サーバーは統合 CA とインストールされます。

2.1. 対話型インストール

ipa-server-install ユーティリティーを使用して対話型インストールを実行している間、レルム、管理者のパスワード、Directory Manager のパスワードなど、システムの基本設定を指定するように求められます。

ipa-server-install インストールスクリプトにより、/var/log/ipaserver-install.log にログファイルが作成されます。ログは、インストールに失敗した時の問題特定に役立ちます。

手順

  1. ipa-server-install ユーティリティーを実行します。

    # ipa-server-install
  2. スクリプトにより、統合 DNS サービスの設定が求められます。yes を入力します。

    Do you want to configure integrated DNS (BIND)? [no]: yes
  3. このスクリプトでは、いくつかの設定を入力することが求められます。括弧で囲まれた値が推奨されるデフォルト値になります。

    • デフォルト値を使用する場合は Enter を押します。
    • カスタム値を指定する場合は、指定する値を入力します。

      Server host name [server.example.com]:
      Please confirm the domain name [example.com]:
      Please provide a realm name [EXAMPLE.COM]:
      警告

      名前は慎重に指定してください。インストール完了後に変更することはできません。

  4. Directory Server のスーパーユーザー (cn=Directory Manager) のパスワードと、Identity Management (IdM) の管理者システムユーザーアカウント (admin) のパスワードを入力します。

    Directory Manager password:
    IPA admin password:
  5. スクリプトにより、サーバーごとのDNS フォワーダー設定のプロンプトが表示されます。

    Do you want to configure DNS forwarders? [yes]:
    • サーバーごとのDNS フォワーダーを設定するには、yes を入力して表示されたコマンドラインの指示に従います。インストールプロセスにより、IdM LDAPにフォワーダーの IP アドレスが追加されます。

      • フォワードポリシーのデフォルト設定は、man ページの ipa-dns-install(1) に記載される --forward-policy の説明を参照してください。
    • DNS 転送を使用しない場合は、no と入力します。

      DNS フォワーダーがないと、IdM ドメインのホストは、インフラストラクチャー内にある他の内部 DNS ドメインから名前を解決できません。ホストは、DNS クエリーを解決するためにパブリック DNS サーバーでのみ残ります。

  6. そのサーバーと関連する IP アドレスの DNS 逆引き (PTR) レコードを設定する必要性を確認するスクリプトプロンプトが出されます。

    Do you want to search for missing reverse zones? [yes]:

    検索を実行して欠落している逆引きゾーンが見つかると、PTR レコードの逆引きゾーンを作成するかどうかが尋ねられます。

    Do you want to create reverse zone for IP 192.0.2.1 [yes]:
    Please specify the reverse zone name [2.0.192.in-addr.arpa.]:
    Using reverse zone(s) 2.0.192.in-addr.arpa.
    注記

    任意で、逆引きゾーンの管理に IdM を使用できます。代わりに、この目的で外部 DNS サービスを使用することもできます。

  7. サーバー設定をする場合は、yes と入力します。

    Continue to configure the system with these values? [no]: yes
  8. インストールスクリプトにより、サーバーが設定されます。動作が完了するまで待ちます。
  9. インストールスクリプトが完了したら、次の方法で DNS レコードを更新します。

    1. 親ドメインから ldM DNS ドメインに DNS 委譲を追加します。たとえば、IdM DNS ドメインが idm.example.com の場合は、ネームサーバー (NS) レコードを親ドメイン example.com に追加します。

      重要

      IdM DNS サーバーをインストールするたびに、この手順を繰り返します。

    2. タイムサーバーの _ntp._udp サービス(SRV) レコードを IdM DNS に追加します。IdM DNS に新たにインストールした IdM サーバーのタイムサーバーの SRV レコードが存在すると、今後のレプリカおよびクライアントインストールが、このプライマリー IdM サーバーが使用するタイムサーバーと同期するように自動的に設定されます。

2.2. 非対話型インストール

ipa-server-install インストールスクリプトにより、/var/log/ipaserver-install.log にログファイルが作成されます。ログは、インストールに失敗した時の問題特定に役立ちます。

手順

  1. オプションで必要な情報をすべて指定して、ipa-server-install ユーティリティーを実行します。非対話型インストールで最低限必要なオプションは次のとおりです。

    • --realm - Kerberos レルム名を指定します。
    • --ds-password - Directory Server のスーパーユーザーである Directory Manager (DM) のパスワードを指定します。
    • --admin-password - Identity Management (IdM) の管理者である admin のパスワードを指定します。
    • --unattended - インストールプロセスでホスト名およびドメイン名のデフォルトオプションを選択するようにします。

    統合 DNS のあるサーバーをインストールする場合は、以下のオプションも追加します。

    • --setup-dns - 統合 DNS名を設定します。
    • --forwarder または --no-forwarders - DNS フォワーダーを設定するかを指定します。
    • --auto-reverse または --no-reverse - IdM DNS で作成する必要がある逆引き DNS ゾーンの自動検出を設定するかどうかを指定します。

    以下に例を示します。

    # ipa-server-install --realm EXAMPLE.COM --ds-password DM_password --admin-password admin_password --unattended --setup-dns --forwarder 192.0.2.1 --no-reverse
  2. インストールスクリプトが完了したら、次の方法で DNS レコードを更新します。

    1. 親ドメインから ldM DNS ドメインに DNS 委譲を追加します。たとえば、IdM DNS ドメインが idm.example.com の場合は、ネームサーバー (NS) レコードを親ドメイン example.com に追加します。

      重要

      IdM DNS サーバーをインストールするたびに、この手順を繰り返します。

    2. タイムサーバーの _ntp._udp サービス(SRV) レコードを IdM DNS に追加します。IdM DNS に新たにインストールした IdM サーバーのタイムサーバーの SRV レコードが存在すると、今後のレプリカおよびクライアントインストールが、このプライマリー IdM サーバーが使用するタイムサーバーと同期するように自動的に設定されます。

関連情報

  • ipa-server-install で使用できるオプションの完全リストを表示するには、ipa-server-install --help コマンドを実行します。

第3章 IdM サーバーのインストール: 統合 DNS と外部 CA を root CA として使用する場合

統合 DNS のある新しい Identity Management (IdM) サーバーをインストールすると、次のような利点があります。

  • ネイティブの IdM ツールを使用すると、メンテナンスおよび DNS レコードの管理のほとんどを自動化できます。たとえば、DNS SRV レコードは、セットアップ中に自動的に作成され、その後は自動的に更新されます。
  • IdM サーバーのインストール時にグローバルフォワーダーを設定すると、インターネットとの安定した接続を確立できます。グローバルフォワーダーは、Active Directory との信頼関係にも便利です。
  • IdM ドメインからのメールが、IdM ドメイン外のメールサーバーによってスパムと見なされないように、DNS 逆ゾーンを設定できます。

統合 DNS のある IdM のインストールにはいくつかの制限があります。

  • IdM DNS は、一般用途の DNS サーバーとして使用することは想定されていません。高度な DNS 機能の一部はサポートされていません。

本章では、外部の認証局 (CA) をルート CA として新しい IdM サーバーをインストールする方法を説明します。

3.1. 対話型インストール

ipa-server-install ユーティリティーを使用して対話型インストールを実行している間、レルム、管理者のパスワード、Directory Manager のパスワードなど、システムの基本設定を指定するように求められます。

ipa-server-install インストールスクリプトにより、/var/log/ipaserver-install.log にログファイルが作成されます。ログは、インストールに失敗した時の問題特定に役立ちます。

この手順では、以下に該当するサーバーのインストール方法を説明します。

  • 統合 DNS のあるサーバー
  • 外部認証局 (CA) をルート CA とするサーバー

前提条件

  • 使用する外部 CA のタイプを決定している (--external-ca-type オプション)。詳細は、man ページの ipa-server-install(1) を参照してください。
  • もしくは、Active Directory Certificate Service (AD CS) テンプレートを指定して --external-ca-profile オプションを選択することもできます。たとえば、AD CS のインストール固有のオブジェクト識別子を指定するには、次のコマンドを実行します。

    [root@server ~]# ipa-server-install --external-ca --external-ca-type=ms-cs --external-ca-profile=1.3.6.1.4.1.311.21.8.8950086.10656446.2706058.12775672.480128.147.7130143.4405632:1

手順

  1. --external-ca オプションを使用して ipa-server-install ユーティリティーを実行します。

    # ipa-server-install --external-ca

    Microsoft Certificate Services の CA を使用している場合は、--external-ca-type オプションも使用してください。詳細は、ipa-server-install(1) の man ページを参照してください。

  2. スクリプトにより、統合 DNS サービスの設定が求められます。yes または no を入力します。この手順では、統合 DNS のあるサーバーをインストールします。

    Do you want to configure integrated DNS (BIND)? [no]: yes
    注記

    統合 DNS のないサーバーをインストールする場合は、以下の手順にある DNS 設定のプロンプトが表示されません。DNS のないサーバーをインストールする手順の詳細は、5章IdM サーバーのインストール: 統合 DNS がなく統合 CA が root CA としてある場合 を参照してください。

  3. このスクリプトでは、いくつかの設定を入力することが求められます。括弧で囲まれた値が推奨されるデフォルト値になります。

    • デフォルト値を使用する場合は Enter を押します。
    • カスタム値を指定する場合は、指定する値を入力します。

      Server host name [server.example.com]:
      Please confirm the domain name [example.com]:
      Please provide a realm name [EXAMPLE.COM]:
      警告

      名前は慎重に指定してください。インストール完了後に変更することはできません。

  4. Directory Server のスーパーユーザー (cn=Directory Manager) のパスワードと、Identity Management (IdM) の管理者システムユーザーアカウント (admin) のパスワードを入力します。

    Directory Manager password:
    IPA admin password:
  5. スクリプトにより、サーバーごとのDNS フォワーダー設定のプロンプトが表示されます。

    Do you want to configure DNS forwarders? [yes]:
    • サーバーごとのDNS フォワーダーを設定するには、yes を入力して表示されたコマンドラインの指示に従います。インストールプロセスにより、IdM LDAPにフォワーダーの IP アドレスが追加されます。

      • フォワードポリシーのデフォルト設定は、man ページの ipa-dns-install(1) に記載される --forward-policy の説明を参照してください。
    • DNS 転送を使用しない場合は、no と入力します。

      DNS フォワーダーがないと、IdM ドメインのホストは、インフラストラクチャー内にある他の内部 DNS ドメインから名前を解決できません。ホストは、DNS クエリーを解決するためにパブリック DNS サーバーでのみ残ります。

  6. そのサーバーと関連する IP アドレスの DNS 逆引き (PTR) レコードを設定する必要性を確認するスクリプトプロンプトが出されます。

    Do you want to search for missing reverse zones? [yes]:

    検索を実行して欠落している逆引きゾーンが見つかると、PTR レコードの逆引きゾーンを作成するかどうかが尋ねられます。

    Do you want to create reverse zone for IP 192.0.2.1 [yes]:
    Please specify the reverse zone name [2.0.192.in-addr.arpa.]:
    Using reverse zone(s) 2.0.192.in-addr.arpa.
    注記

    任意で、逆引きゾーンの管理に IdM を使用できます。代わりに、この目的で外部 DNS サービスを使用することもできます。

  7. サーバー設定をする場合は、yes と入力します。

    Continue to configure the system with these values? [no]: yes
  8. Certificate System インスタンスの設定時、このユーティリティーが証明書署名要求 (CSR) の場所 (/root/ipa.csr) を出力します。

    ...
    
    Configuring certificate server (pki-tomcatd): Estimated time 3 minutes 30 seconds
      [1/8]: creating certificate server user
      [2/8]: configuring certificate server instance
    The next step is to get /root/ipa.csr signed by your CA and re-run /sbin/ipa-server-install as:
    /sbin/ipa-server-install --external-cert-file=/path/to/signed_certificate --external-cert-file=/path/to/external_ca_certificate

    この場合は、以下を行います。

    1. /root/ipa.csr にある CSR を外部 CA に提出します。このプロセスは、外部 CA として使用するサービスにより異なります。
    2. 発行した証明書と、Base64 エンコードされたブロブ (PEM ファイルか Windows CA からの Base_64 証明書) で CA を発行する CA 証明書チェーンを取得します。繰り返しになりますが、プロセスは各証明書サービスによって異なります。通常は Web ページか通知メールにダウンロードリンクがあり、管理者が必要なすべての証明書をダウンロードできるようになっています。

      重要

      CA 証明書のみではなく、CA 用の完全な証明書チェーンを取得してください。

    3. 新たに発行された CA 証明書と CA チェーンファイルの場所と名前を指定して ipa-server-install を再度実行します。以下に例を示します。

      # ipa-server-install --external-cert-file=/tmp/servercert20170601.pem --external-cert-file=/tmp/cacert.pem
  9. インストールスクリプトにより、サーバーが設定されます。動作が完了するまで待ちます。
  10. インストールスクリプトが完了したら、次の方法で DNS レコードを更新します。

    1. 親ドメインから ldM DNS ドメインに DNS 委譲を追加します。たとえば、IdM DNS ドメインが idm.example.com の場合は、ネームサーバー (NS) レコードを親ドメイン example.com に追加します。

      重要

      IdM DNS サーバーをインストールするたびに、この手順を繰り返します。

    2. タイムサーバーの _ntp._udp サービス(SRV) レコードを IdM DNS に追加します。IdM DNS に新たにインストールした IdM サーバーのタイムサーバーの SRV レコードが存在すると、今後のレプリカおよびクライアントインストールが、このプライマリー IdM サーバーが使用するタイムサーバーと同期するように自動的に設定されます。
注記

ipa-server-install --external-ca コマンドは、次のエラーにより失敗する場合があります。

ipa         : CRITICAL failed to configure ca instance Command '/usr/sbin/pkispawn -s CA -f /tmp/configuration_file' returned non-zero exit status 1
Configuration of CA failed

この失敗は、*_proxy 環境変数が設定されていると発生します。問題の解決方法は、「トラブルシューティング: 外部 CA インストールの失敗」を参照してください。

3.2. トラブルシューティング: 外部 CA インストールの失敗

ipa-server-install --external-ca コマンドが、次のエラーにより失敗します。

ipa         : CRITICAL failed to configure ca instance Command '/usr/sbin/pkispawn -s CA -f /tmp/configuration_file' returned non-zero exit status 1
Configuration of CA failed

env|grep proxy を実行すると、以下のような変数が表示されます。

# env|grep proxy
http_proxy=http://example.com:8080
ftp_proxy=http://example.com:8080
https_proxy=http://example.com:8080

エラー内容:

*_proxy 環境変数が原因でサーバーをインストールできません。

解決方法:

  1. 次のシェルスクリプトを使用して *_proxy 環境変数の設定を解除します。

    # for i in ftp http https; do unset ${i}_proxy; done
  2. pkidestroy ユーティリティーを実行して、インストールに失敗した認証局 (CA) サブシステムを削除します。

    # pkidestroy -s CA -i pki-tomcat; rm -rf /var/log/pki/pki-tomcat /etc/sysconfig/pki-tomcat /etc/sysconfig/pki/tomcat/pki-tomcat /var/lib/pki/pki-tomcat /etc/pki/pki-tomcat /root/ipa.csr
  3. インストールに失敗した Identity Management (IdM) サーバーを削除します。

    # ipa-server-install --uninstall
  4. ipa-server-install --external-ca を再度実行します。

第4章 IdM サーバーのインストール: 統合 DNS があり外部 CA がない場合

統合 DNS のある新しい Identity Management (IdM) サーバーをインストールすると、次のような利点があります。

  • ネイティブの IdM ツールを使用すると、メンテナンスおよび DNS レコードの管理のほとんどを自動化できます。たとえば、DNS SRV レコードは、セットアップ中に自動的に作成され、その後は自動的に更新されます。
  • IdM サーバーのインストール時にグローバルフォワーダーを設定すると、インターネットとの安定した接続を確立できます。グローバルフォワーダーは、Active Directory との信頼関係にも便利です。
  • IdM ドメインからのメールが、IdM ドメイン外のメールサーバーによってスパムと見なされないように、DNS 逆ゾーンを設定できます。

統合 DNS のある IdM のインストールにはいくつかの制限があります。

  • IdM DNS は、一般用途の DNS サーバーとして使用することは想定されていません。高度な DNS 機能の一部はサポートされていません。

本章では、認証局 (CA) がない場合に新しい IdMt サーバーをインストールする方法を説明します。

4.1. CA なしで IdM サーバーをインストールするために必要な証明書

ここでは、以下について記述します。

  • 認証局 (CA) なしで Identity Management (IdM) サーバーをインストールするために必要な証明書
  • それらの証明書を ipa-server-install ユーティリティーに提供するのに使用されるコマンドラインオプション
重要

インポートした証明書ファイルには、LDAP サーバーおよび Apache サーバーの証明書を発行した CA の完全な証明書チェーンが含まれている必要があるため、自己署名のサードパーティーサーバー証明書を使用してサーバーまたはレプリカをインストールすることはできません。

LDAP サーバー証明書および秘密鍵
  • --dirsrv-cert-file - LDAP サーバー証明書の証明書ファイルおよび秘密鍵ファイルを提供します。
  • --dirsrv-pin - --dirsrv-cert-file に指定されたファイルにある秘密鍵にアクセスするパスワードを提供します。
Apache サーバー証明書および秘密鍵
  • --http-cert-file - Apache サーバー証明書の証明書および秘密鍵ファイルを提供します。
  • --http-pin - --http-cert-file に指定したファイルにある秘密鍵にアクセスするパスワードを提供します。
LDAP および Apache のサーバー証明書を発行した CA の完全な CA 証明書チェーン
  • --dirsrv-cert-file および --http-cert-file - 完全な CA 証明書チェーンまたはその一部が含まれる証明書ファイルを提供します。

以下の形式の --dirsrv-cert-file オプションおよび --http-cert-file オプションを指定して、ファイルを指定できます。

  • PEM (Privacy-Enhanced Mail) がエンコードした証明書 (RFC 7468)。Identity Management インストーラーは、連結した PEM エンコードオブジェクトを受け付けることに注意してください。
  • 識別名エンコーディングルール (DER)
  • PKCS #7 証明書チェーンオブジェクト
  • PKCS #8 秘密鍵オブジェクト
  • PKCS #12 アーカイブ

--dirsrv-cert-file オプションおよび --http-cert-file オプションを複数回指定して、複数のファイルを指定できます。

完全な CA 証明書チェーンを提供する証明書ファイル (一部の環境では必要ありません)
  • --ca-cert-file - LDAP、Apache Server、および Kerberos KDC の証明書を発行した CA の CA 証明書が含まれるファイル。このオプションは、他のオプションにより提供される証明書ファイルに CA 証明書が存在しない場合に使用します。

--ca-cert-file を使用して提供されるファイルと、--dirsrv-cert-file--http-cert-file を使用して提供されるファイルには、LDAP および Apache のサーバー証明書を発行した CA の完全 CA 証明書チェーンが含まれる必要があります。

Kerberos 鍵配布センター (KDC) の PKINIT 証明書および秘密鍵 (任意)
  • --pkinit-cert-file - Kerberos KDC SSL の証明書および秘密鍵を提供します。
  • --pkinit-pin - --pkinit-cert-file に指定されたファイルにある Kerberos KDC の秘密鍵にアクセスするパスワードを提供します。
  • --no-pkinit - pkinit 設定手順を無効にします。

PKINIT 証明書を提供しないと、ipa-server-install は自己署名証明書を使用するローカル KDC で IdM サーバーを設定します。

関連情報

  • このオプションで使用できる証明書ファイル形式に関する詳細は、man ページの ipa-server-install(1) を参照してください。
  • RHEL IdM PKINIT 証明書を作成するために必要な PKINIT 拡張機能の詳細は、RHEL IdM PKINIT KDC certificate and extensions を参照してください。

4.2. 対話型インストール

ipa-server-install ユーティリティーを使用して対話型インストールを実行している間、レルム、管理者のパスワード、Directory Manager のパスワードなど、システムの基本設定を指定するように求められます。

ipa-server-install インストールスクリプトにより、/var/log/ipaserver-install.log にログファイルが作成されます。ログは、インストールに失敗した時の問題特定に役立ちます。

手順

  1. ipa-server-install ユーティリティーを実行し、必要な証明書をすべて提供します。以下に例を示します。

    [root@server ~]# ipa-server-install \
        --http-cert-file /tmp/server.crt \
        --http-cert-file /tmp/server.key \
        --http-pin secret \
        --dirsrv-cert-file /tmp/server.crt \
        --dirsrv-cert-file /tmp/server.key \
        --dirsrv-pin secret \
        --ca-cert-file ca.crt

    提供される証明書の詳細は、「CA なしで IdM サーバーをインストールするために必要な証明書」を参照してください。

  2. スクリプトにより、統合 DNS サービスの設定が求められます。yes または no を入力します。この手順では、統合 DNS のあるサーバーをインストールします。

    Do you want to configure integrated DNS (BIND)? [no]: yes
    注記

    統合 DNS のないサーバーをインストールする場合は、以下の手順にある DNS 設定のプロンプトが表示されません。DNS のないサーバーをインストールする手順の詳細は、「IdM サーバーのインストール: 統合 DNS がなく統合 CA が root CA としてある場合」を参照してください。

  3. このスクリプトでは、いくつかの設定を入力することが求められます。括弧で囲まれた値が推奨されるデフォルト値になります。

    • デフォルト値を使用する場合は Enter を押します。
    • カスタム値を指定する場合は、指定する値を入力します。

      Server host name [server.example.com]:
      Please confirm the domain name [example.com]:
      Please provide a realm name [EXAMPLE.COM]:
      警告

      名前は慎重に指定してください。インストール完了後に変更することはできません。

  4. Directory Server のスーパーユーザー (cn=Directory Manager) のパスワードと、Identity Management (IdM) の管理者システムユーザーアカウント (admin) のパスワードを入力します。

    Directory Manager password:
    IPA admin password:
  5. スクリプトにより、サーバーごとのDNS フォワーダー設定のプロンプトが表示されます。

    Do you want to configure DNS forwarders? [yes]:
    • サーバーごとのDNS フォワーダーを設定するには、yes を入力して表示されたコマンドラインの指示に従います。インストールプロセスにより、IdM LDAPにフォワーダーの IP アドレスが追加されます。

      • フォワードポリシーのデフォルト設定は、man ページの ipa-dns-install(1) に記載される --forward-policy の説明を参照してください。
    • DNS 転送を使用しない場合は、no と入力します。

      DNS フォワーダーがないと、IdM ドメインのホストは、インフラストラクチャー内にある他の内部 DNS ドメインから名前を解決できません。ホストは、DNS クエリーを解決するためにパブリック DNS サーバーでのみ残ります。

  6. そのサーバーと関連する IP アドレスの DNS 逆引き (PTR) レコードを設定する必要性を確認するスクリプトプロンプトが出されます。

    Do you want to search for missing reverse zones? [yes]:

    検索を実行して欠落している逆引きゾーンが見つかると、PTR レコードの逆引きゾーンを作成するかどうかが尋ねられます。

    Do you want to create reverse zone for IP 192.0.2.1 [yes]:
    Please specify the reverse zone name [2.0.192.in-addr.arpa.]:
    Using reverse zone(s) 2.0.192.in-addr.arpa.
    注記

    任意で、逆引きゾーンの管理に IdM を使用できます。代わりに、この目的で外部 DNS サービスを使用することもできます。

  7. サーバー設定をする場合は、yes と入力します。

    Continue to configure the system with these values? [no]: yes
  8. インストールスクリプトにより、サーバーが設定されます。動作が完了するまで待ちます。
  9. インストールスクリプトが完了したら、次の方法で DNS レコードを更新します。

    1. 親ドメインから ldM DNS ドメインに DNS 委譲を追加します。たとえば、IdM DNS ドメインが idm.example.com の場合は、ネームサーバー (NS) レコードを親ドメイン example.com に追加します。

      重要

      IdM DNS サーバーをインストールするたびに、この手順を繰り返します。

    2. タイムサーバーの _ntp._udp サービス(SRV) レコードを IdM DNS に追加します。IdM DNS に新たにインストールした IdM サーバーのタイムサーバーの SRV レコードが存在すると、今後のレプリカおよびクライアントインストールが、このプライマリー IdM サーバーが使用するタイムサーバーと同期するように自動的に設定されます。

第5章 IdM サーバーのインストール: 統合 DNS がなく統合 CA が root CA としてある場合

本章では、統合 DNS を使用しないで新しい Identity Management (IdM) サーバーをインストールする方法を説明します。

注記

Red Hat では、IdM デプロイメントにおける基本的な使用のために IdM 統合 DNS をインストールすることを強く推奨します。IdM サーバーが DNS も管理する場合には、DNS とネイティブの IdM ツールが密接に統合されるため、DNS レコード管理の一部が自動化できます。

詳細は、「Planning your DNS services and host names」を参照してください。

5.1. 対話型インストール

ipa-server-install ユーティリティーを使用して対話型インストールを実行している間、レルム、管理者のパスワード、Directory Manager のパスワードなど、システムの基本設定を指定するように求められます。

ipa-server-install インストールスクリプトにより、/var/log/ipaserver-install.log にログファイルが作成されます。ログは、インストールに失敗した時の問題特定に役立ちます。

この手順では、以下のサーバーをインストールします。

  • 統合 DNS のないサーバー
  • 統合 Identity Management (IdM) の認証局 (CA) をルート CA とするサーバー (デフォルトの CA 設定)

手順

  1. ipa-server-install ユーティリティーを実行します。

    # ipa-server-install
  2. スクリプトにより、統合 DNS サービスの設定が求められます。Enter を押して、no オプションを選択します。

    Do you want to configure integrated DNS (BIND)? [no]:
  3. このスクリプトでは、いくつかの設定を入力することが求められます。括弧で囲まれた値が推奨されるデフォルト値になります。

    • デフォルト値を使用する場合は Enter を押します。
    • カスタム値を指定する場合は、指定する値を入力します。

      Server host name [server.example.com]:
      Please confirm the domain name [example.com]:
      Please provide a realm name [EXAMPLE.COM]:
      警告

      名前は慎重に指定してください。インストール完了後に変更することはできません。

  4. Directory Server のスーパーユーザー (cn=Directory Manager) のパスワードと、IdM の管理者システムユーザーアカウント (admin) のパスワードを入力します。

    Directory Manager password:
    IPA admin password:
  5. サーバー設定をする場合は、yes と入力します。

    Continue to configure the system with these values? [no]: yes
  6. インストールスクリプトにより、サーバーが設定されます。動作が完了するまで待ちます。
  7. インストールスクリプトは、以下の出力例の DNS リソースレコード でファイル (/tmp/ipa.system.records.UFRPto.db) を生成します。これらのレコードを既存の外部 DNS サーバーに追加します。DNS レコードの更新プロセスは、特定の DNS ソリューションによって異なります。

    ...
    Restarting the KDC
    Please add records in this file to your DNS system: /tmp/ipa.system.records.UFRBto.db
    Restarting the web server
    ...
    重要

    既存の DNS サーバーに DNS レコードを追加するまで、サーバーのインストールは完了しません。

関連情報

5.2. 非対話型インストール

この手順では、以下のサーバーをインストールします。

  • 統合 DNS のないサーバー
  • 統合 Identity Management (IdM) の認証局 (CA) をルート CA とするサーバー (デフォルトの CA 設定)
注記

ipa-server-install インストールスクリプトにより、/var/log/ipaserver-install.log にログファイルが作成されます。ログは、インストールに失敗した時の問題特定に役立ちます。

手順

  1. 必要に応じて必要な情報をすべて指定して、ipa-server-install ユーティリティーを実行します。非対話型インストールで最低限必要なオプションは次のとおりです。

    • --realm - Kerberos レルム名を指定します。
    • --ds-password - Directory Server のスーパーユーザーである Directory Manager (DM) のパスワードを指定します。
    • --admin-password - IdM 管理者である admin のパスワードを指定します。
    • --unattended - インストールプロセスでホスト名およびドメイン名のデフォルトオプションを選択するようにします。

    以下に例を示します。

    # ipa-server-install --realm EXAMPLE.COM --ds-password DM_password --admin-password admin_password --unattended
  2. インストールスクリプトは、以下の出力例の DNS リソースレコード でファイル (/tmp/ipa.system.records.UFRPto.db) を生成します。これらのレコードを既存の外部 DNS サーバーに追加します。DNS レコードの更新プロセスは、特定の DNS ソリューションによって異なります。

    ...
    Restarting the KDC
    Please add records in this file to your DNS system: /tmp/ipa.system.records.UFRBto.db
    Restarting the web server
    ...
    重要

    既存の DNS サーバーに DNS レコードを追加するまで、サーバーのインストールは完了しません。

関連情報

  • DNS システムに追加する必要がある DNS リソースレコードの詳細は、外部 DNS システムの IdM DNS レコード を参照してください。
  • ipa-server-install で使用できるオプションの完全リストを表示するには、ipa-server-install --help コマンドを実行します。

5.3. 外部 DNS システムの IdM DNS レコード

統合 DNS を使用せずに IdM サーバーをインストールした後、IdM サーバーの LDAP リソースレコードおよび Kerberos DNS リソースレコードを外部 DNS システムに追加する必要があります。

ipa-server-install インストールスクリプトは、ファイル名が /tmp/ipa.system.records.<random_characters>.db 形式の DNS リソースレコードの一覧を含むファイルを生成し、そのレコードを追加する手順を表示します。

Please add records in this file to your DNS system: /tmp/ipa.system.records.6zdjqxh3.db

以下は、ファイルの内容の例になります。

_kerberos-master._tcp.example.com. 86400 IN SRV 0 100 88 server.example.com.
_kerberos-master._udp.example.com. 86400 IN SRV 0 100 88 server.example.com.
_kerberos._tcp.example.com. 86400 IN SRV 0 100 88 server.example.com.
_kerberos._udp.example.com. 86400 IN SRV 0 100 88 server.example.com.
_kerberos.example.com. 86400 IN TXT "EXAMPLE.COM"
_kpasswd._tcp.example.com. 86400 IN SRV 0 100 464 server.example.com.
_kpasswd._udp.example.com. 86400 IN SRV 0 100 464 server.example.com.
_ldap._tcp.example.com. 86400 IN SRV 0 100 389 server.example.com.
注記

IdM サーバーの LDAP リソースレコードおよび Kerberos DNS リソースレコードを DNS システムに追加したら、DNS 管理ツールが ipa-ca の PTR レコードを追加していないことを確認します。DNS に ipa-ca の PTR レコードが存在すると、その後の IdM レプリカのインストールに失敗する場合があります。

第6章 IdM サーバーのインストール: 統合 DNS なしで外部 CA を root CA として使用する場合

本章では、統合 DNS なしで、外部認証局 (CA) をルート CA として使用する Identity Management (IdM) サーバーを新規インストールする方法を説明します。

注記

Red Hat では、IdM デプロイメントにおける基本的な使用のために IdM 統合 DNS をインストールすることを強く推奨します。IdM サーバーが DNS も管理する場合には、DNS とネイティブの IdM ツールが密接に統合されるため、DNS レコード管理の一部が自動化できます。

詳細は、「Planning your DNS services and host names」を参照してください。

6.1. ルート CA として外部 CA と共に IdM CA をインストールする際に使用されるオプション

以下の条件のいずれかが該当する場合、ルート CA として外部 CA と共に Identity Management IdM 認証局(CA)をインストールすることができます。

  • ipa-server-install コマンドを使用して、新しい IdM サーバーまたはレプリカをインストールしようとしている。
  • ipa-ca-install コマンドを使用して、CA コンポーネントを既存の IdM サーバーにインストールしようとしている。

本セクションでは、ルート CA として外部 CA と共に IdM CA をインストールする際に証明書署名要求(CSR)を作成するのに使用できる両方のコマンドのオプションを説明します。

--external-ca-type=TYPE
外部 CA のタイプ。設定可能な値は generic および ms-cs です。デフォルト値は generic です。生成される CSR に Microsoft Certificate Services (MS CS)で必要なテンプレート名を追加するには、ms-cs を使用します。デフォルト以外のプロファイルを使用するには、--external-ca-type=ms-cs と共に --external-ca-profile オプションを使用します。
--external-ca-profile=PROFILE_SPEC

IdM CA の証明書を発行する際にMS CS が適用する証明書プロファイルまたはテンプレートを指定します。

--external-ca-profile オプションは、--external-ca-type が ms-cs の場合にのみ使用できます。

MS CS テンプレートは、以下のいずれかの方法で特定できます。

  • <oid>:<majorVersion>[:<minorVersion>]:証明書テンプレートは、オブジェクト識別子(OID)およびメジャーバージョンで指定できます。任意でマイナーバージョンを指定することもできます。
  • <name>:証明書テンプレートは、名前で指定できます。名前には : 文字を含めることができず、OID を指定できません。そうでなければ、OID ベースのテンプレート指定子構文が優先されます。
  • default:この指定子を使用する場合には、テンプレート名 SubCA が使用されます。

特定のシナリオでは、Active Directory (AD)管理者は、AD CS に組み込まれているテンプレートである Subordinate 認証局 (SCA)テンプレートを使用して、組織のニーズにより適した一意のテンプレートを作成できます。たとえば、新しいテンプレートでは有効期間や拡張機能をカスタマイズできます。関連付けられたオブジェクト識別子(OID)は、AD 証明書テンプレート コンソールにあります。

AD 管理者が元の組み込みテンプレートを無効にしている場合は、IdM CA の証明書を要求する際に新しいテンプレートの OID または名前を指定する必要があります。AD 管理者に、新しいテンプレートの名前または OID を提供するよう依頼します。

元の SCA AD CS テンプレートがまだ有効にされている場合は、追加で--external-ca-profile オプションを使用せずに --external-ca-type=ms-cs を指定して使用できます。この場合、subCA 外部CA プロファイルが使用されます。これは、SCA AD CS テンプレートに対応するデフォルトの IdM テンプレートです。

6.2. 対話型インストール

ipa-server-install ユーティリティーを使用して対話型インストールを実行している間、レルム、管理者のパスワード、Directory Manager のパスワードなど、システムの基本設定を指定するように求められます。

ipa-server-install インストールスクリプトにより、/var/log/ipaserver-install.log にログファイルが作成されます。ログは、インストールに失敗した時の問題特定に役立ちます。

この手順では、以下に該当するサーバーのインストール方法を説明します。

  • 統合 DNS のないサーバー
  • 外部認証局 (CA) をルート CA とするサーバー

手順

  1. --external-ca オプションを使用して ipa-server-install ユーティリティーを実行します。

    • Microsoft Certificate Services (MS CS) CA を使用している場合は、--external-ca-type および --external-ca-profile オプションも使用します。たとえば、 1.3.6.1.4.1.311.21.8.8950086.10656446.2706058.12775672.480128.147.7130143.4405632:1 Object Identifier (OID)テンプレートを使用して署名証明書が発行される CA と共に IdM サーバーをインストールするには、以下を実行します。

      [root@server ~]# ipa-server-install --external-ca --external-ca-type=ms-cs --external-ca-profile=1.3.6.1.4.1.311.21.8.8950086.10656446.2706058.12775672.480128.147.7130143.4405632:1

      --external-ca-type および --external-ca-profile オプションの詳細は、「ルート CA として外部 CA と共に IdM CA をインストールする際に使用されるオプション」を参照してください。

    • MS CS を使用して IdM CA の署名証明書を生成していない場合は、他のオプションは必要ありません。

      # ipa-server-install --external-ca
  2. スクリプトにより、統合 DNS サービスの設定が求められます。Enter を押して、no オプションを選択します。

    Do you want to configure integrated DNS (BIND)? [no]:
  3. このスクリプトでは、いくつかの設定を入力することが求められます。括弧で囲まれた値が推奨されるデフォルト値になります。

    • デフォルト値を使用する場合は Enter を押します。
    • カスタム値を指定する場合は、指定する値を入力します。

      Server host name [server.example.com]:
      Please confirm the domain name [example.com]:
      Please provide a realm name [EXAMPLE.COM]:
      警告

      名前は慎重に指定してください。インストール完了後に変更することはできません。

  4. Directory Server のスーパーユーザー (cn=Directory Manager) のパスワードと、IdM の管理者システムユーザーアカウント (admin) のパスワードを入力します。

    Directory Manager password:
    IPA admin password:
  5. サーバー設定をする場合は、yes と入力します。

    Continue to configure the system with these values? [no]: yes
  6. Certificate System インスタンスの設定時、このユーティリティーが証明書署名要求 (CSR) の場所 (/root/ipa.csr) を出力します。

    ...
    
    Configuring certificate server (pki-tomcatd): Estimated time 3 minutes 30 seconds
      [1/8]: creating certificate server user
      [2/8]: configuring certificate server instance
    The next step is to get /root/ipa.csr signed by your CA and re-run /sbin/ipa-server-install as:
    /sbin/ipa-server-install --external-cert-file=/path/to/signed_certificate --external-cert-file=/path/to/external_ca_certificate

    この場合は、以下を行います。

    1. /root/ipa.csr にある CSR を外部 CA に提出します。このプロセスは、外部 CA として使用するサービスにより異なります。
    2. 発行した証明書と、Base64 エンコードされたブロブ (PEM ファイルか Windows CA からの Base_64 証明書) で CA を発行する CA 証明書チェーンを取得します。繰り返しになりますが、プロセスは各証明書サービスによって異なります。通常は Web ページか通知メールにダウンロードリンクがあり、管理者が必要なすべての証明書をダウンロードできるようになっています。

      重要

      CA 証明書のみではなく、CA 用の完全な証明書チェーンを取得してください。

    3. 新たに発行された CA 証明書と CA チェーンファイルの場所と名前を指定して ipa-server-install を再度実行します。以下に例を示します。

      # ipa-server-install --external-cert-file=/tmp/servercert20170601.pem --external-cert-file=/tmp/cacert.pem
  7. インストールスクリプトにより、サーバーが設定されます。動作が完了するまで待ちます。
  8. インストールスクリプトは、以下の出力例の DNS リソースレコード でファイル (/tmp/ipa.system.records.UFRPto.db) を生成します。これらのレコードを既存の外部 DNS サーバーに追加します。DNS レコードの更新プロセスは、特定の DNS ソリューションによって異なります。

    ...
    Restarting the KDC
    Please add records in this file to your DNS system: /tmp/ipa.system.records.UFRBto.db
    Restarting the web server
    ...
    重要

    既存の DNS サーバーに DNS レコードを追加するまで、サーバーのインストールは完了しません。

関連情報

  • DNS システムに追加する必要がある DNS リソースレコードの詳細は、外部 DNS システムの IdM DNS レコード を参照してください。
  • ipa-server-install --external-ca コマンドは、次のエラーにより失敗する場合があります。

    ipa         : CRITICAL failed to configure ca instance Command '/usr/sbin/pkispawn -s CA -f /tmp/pass:quotes[configuration_file]' returned non-zero exit status 1
    Configuration of CA failed

    この失敗は、*_proxy 環境変数が設定されていると発生します。問題の解決方法は、「トラブルシューティング: 外部 CA インストールの失敗」を参照してください。

6.3. 非対話型インストール

この手順では、以下のサーバーをインストールします。

  • 統合 DNS のないサーバー
  • 外部認証局 (CA) をルート CA とするサーバー
注記

ipa-server-install インストールスクリプトにより、/var/log/ipaserver-install.log にログファイルが作成されます。ログは、インストールに失敗した時の問題特定に役立ちます。

前提条件

  • 使用する外部 CA のタイプを決定している (--external-ca-type オプション)。詳細は、man ページの ipa-server-install(1) を参照してください。
  • もしくは、Active Directory Certificate Service (AD CS) テンプレートを指定して --external-ca-profile オプションを選択することもできます。たとえば、AD CS のインストール固有のオブジェクト識別子を指定するには、次のコマンドを実行します。

    [root@server ~]# ipa-server-install --external-ca --external-ca-type=ms-cs --external-ca-profile=1.3.6.1.4.1.311.21.8.8950086.10656446.2706058.12775672.480128.147.7130143.4405632:1

手順

  1. 必要に応じて必要な情報をすべて指定して、ipa-server-install ユーティリティーを実行します。外部 CA をルート CA として使用する IdM サーバーを非対話的にインストールする場合の最小要件オプションは以下のとおりです。

    • --external-ca - 外部 CA をルート CA として指定します。
    • --realm - Kerberos レルム名を指定します。
    • --ds-password - Directory Server のスーパーユーザーである Directory Manager (DM) のパスワードを指定します。
    • --admin-password - IdM 管理者である admin のパスワードを指定します。
    • --unattended - インストールプロセスでホスト名およびドメイン名のデフォルトオプションを選択するようにします。

      以下に例を示します。

      # ipa-server-install --external-ca --realm EXAMPLE.COM --ds-password DM_password --admin-password admin_password --unattended

    Microsoft Certificate Services の CA を使用している場合は、--external-ca-type オプションも使用してください。詳細は、ipa-server-install(1) の man ページを参照してください。

  2. Certificate System インスタンスの設定時、このユーティリティーが証明書署名要求 (CSR) の場所 (/root/ipa.csr) を出力します。

    ...
    
    Configuring certificate server (pki-tomcatd). Estimated time: 3 minutes
      [1/11]: configuring certificate server instance
    The next step is to get /root/ipa.csr signed by your CA and re-run /usr/sbin/ipa-server-install as:
    /usr/sbin/ipa-server-install --external-cert-file=/path/to/signed_certificate --external-cert-file=/path/to/external_ca_certificate
    The ipa-server-install command was successful

    この場合は、以下を行います。

    1. /root/ipa.csr にある CSR を外部 CA に提出します。このプロセスは、外部 CA として使用するサービスにより異なります。
    2. 発行した証明書と、Base64 エンコードされたブロブ (PEM ファイルか Windows CA からの Base_64 証明書) で CA を発行する CA 証明書チェーンを取得します。繰り返しになりますが、プロセスは各証明書サービスによって異なります。通常は Web ページか通知メールにダウンロードリンクがあり、管理者が必要なすべての証明書をダウンロードできるようになっています。

      重要

      CA 証明書のみではなく、CA 用の完全な証明書チェーンを取得してください。

    3. 新たに発行された CA 証明書と CA チェーンファイルの場所と名前を指定して ipa-server-install を再度実行します。以下に例を示します。

      # ipa-server-install --external-cert-file=/tmp/servercert20170601.pem --external-cert-file=/tmp/cacert.pem --realm EXAMPLE.COM --ds-password DM_password --admin-password admin_password --unattended
  3. インストールスクリプトにより、サーバーが設定されます。動作が完了するまで待ちます。
  4. インストールスクリプトは、以下の出力例の DNS リソースレコードでファイル (/tmp/ipa.system.records.UFRPto.db) を生成します。これらのレコードを既存の外部 DNS サーバーに追加します。DNS レコードの更新プロセスは、特定の DNS ソリューションによって異なります。

    ...
    Restarting the KDC
    Please add records in this file to your DNS system: /tmp/ipa.system.records.UFRBto.db
    Restarting the web server
    ...
重要

既存の DNS サーバーに DNS レコードを追加するまで、サーバーのインストールは完了しません。

関連情報

6.4. 外部 DNS システムの IdM DNS レコード

統合 DNS を使用せずに IdM サーバーをインストールした後、IdM サーバーの LDAP リソースレコードおよび Kerberos DNS リソースレコードを外部 DNS システムに追加する必要があります。

ipa-server-install インストールスクリプトは、ファイル名が /tmp/ipa.system.records.<random_characters>.db 形式の DNS リソースレコードの一覧を含むファイルを生成し、そのレコードを追加する手順を表示します。

Please add records in this file to your DNS system: /tmp/ipa.system.records.6zdjqxh3.db

以下は、ファイルの内容の例になります。

_kerberos-master._tcp.example.com. 86400 IN SRV 0 100 88 server.example.com.
_kerberos-master._udp.example.com. 86400 IN SRV 0 100 88 server.example.com.
_kerberos._tcp.example.com. 86400 IN SRV 0 100 88 server.example.com.
_kerberos._udp.example.com. 86400 IN SRV 0 100 88 server.example.com.
_kerberos.example.com. 86400 IN TXT "EXAMPLE.COM"
_kpasswd._tcp.example.com. 86400 IN SRV 0 100 464 server.example.com.
_kpasswd._udp.example.com. 86400 IN SRV 0 100 464 server.example.com.
_ldap._tcp.example.com. 86400 IN SRV 0 100 389 server.example.com.
注記

IdM サーバーの LDAP リソースレコードおよび Kerberos DNS リソースレコードを DNS システムに追加したら、DNS 管理ツールが ipa-ca の PTR レコードを追加していないことを確認します。DNS に ipa-ca の PTR レコードが存在すると、その後の IdM レプリカのインストールに失敗する場合があります。

第7章 LDIF ファイルからのカスタムデータベース設定を使用した IdM サーバーまたはレプリカのインストール

カスタムの Directory Server 設定を使用して、IdM サーバーおよび IdM レプリカをインストールできます。以下の手順では、データベース設定で LDAP データ交換形式(LDIF)ファイルを作成し、これらの設定を IdM サーバーおよびレプリカのインストールコマンドに渡す方法を説明します。

前提条件

手順

  1. カスタムデータベース設定でテキストファイルを作成します。ダッシュ(-)を使用して個別の LDAP 属性の変更。

    dn: cn=config
    changetype: modify
    replace: nsslapd-maxbersize
    nsslapd-maxbersize=419430400
    -
    replace: nsslapd-maxdescriptors
    nsslapd-maxdescriptors=8192
  2. --dirsrv-config-file パラメーターを使用して、LDIF ファイルをインストールスクリプトに渡します。

    1. IdM サーバーをインストールするには、次のコマンドを実行します。

      # ipa-server-install --dirsrv-config-file filename.ldif
    2. IdM レプリカをインストールするには、以下を実行します。

      # ipa-replica-install --dirsrv-config-file filename.ldif

第8章 ipa-server-install コマンドおよび ipa-replica-install コマンドのオプション

ipa-server-install コマンドおよび ipa-replica-install コマンドには、対話型インストール時に要求されない追加情報を提供するのに使用できる引数が多数あります。このオプションを使用して、無人インストールをスクリプト化することもできます。以下の表は、最も一般的なオプションの一部を示しています。オプションの完全なリストは、man ページの ipa-server-install(1) および ipa-replica-install(1) を参照してください。

表8.1 ipa-server-install コマンドおよび ipa-replica-install コマンドのオプション

引数説明

-a <ipa_admin_password>

Kerberos レルムに対して認証を行うための管理 IdM 管理者 アカウントのパスワード

-d, --debug

詳細の出力については、デバッグロギングを有効にします。

--dirsrv-config-file <LDIF_file_name>

ディレクトリーサーバーインスタンスの設定の修正に使用される LDIF ファイルへのパス。

--hostname=server.idm.example.com

IdM サーバーマシンの完全修飾ドメイン名。数字、小文字のアルファベット、およびハイフン(-)のみを使用できます。

--idmax=<number>

IdM サーバーで割り当て可能な ID の最大値を設定します。デフォルト値は ID 開始値 + 199999 です。

--idstart=<number>

IdM サーバーで割り当て可能な ID の最小値または開始値を設定します。デフォルト値は無作為に選択されます。

--ip-address 127.0.0.1

サーバーの IP アドレスを指定します。このオプションは、ローカルインターフェースに関連付けられた IP アドレスのみを受け入れます。

-n example.com

IdM ドメインに使用する LDAP サーバードメインの名前。通常、これは IdM サーバーのホスト名に基づいています。

-p <directory_manager_password>

LDAP サービスのスーパーユーザー( cn=Directory Manager )のパスワード。

-P <kerberos_main_password>

KDC 管理者のパスワード。値を指定しない場合、これは無作為に生成されます。

-r <KERBEROS_REALM_NAME>

大文字で IdM ドメイン用に作成する Kerberos レルムの名前(例: EXAMPLE.COM )。

--setup-ca

このレプリカに CA をインストールして設定します。CA が設定されていない場合、証明書操作は CA がインストールされている状態で別のレプリカに転送されます。

--forwarder=192.0.2.1

DNS サービスで使用する DNS フォワーダーを指定します。複数のフォワーダーを指定するには、このオプションを複数回使用します。

--no-forwarders

フォワーダーではなく DNS サービスを使用するルートサーバーを使用します。

--no-reverse

DNS ドメインの設定時に、逆引き DNS ゾーンを作成しません。(すでに逆引き DNS ゾーンが設定されている場合は、既存の逆引き DNS ゾーンが使用されます。) このオプションを使用しない場合には、デフォルト値は true になるので、インストールスクリプトで逆引き DNS を設定することを前提としています。

--setup-dns

IdM ドメイン内に DNS サービスを設定するように、インストールスクリプトに指示します。統合 DNS サービスの使用は任意であるため、インストールスクリプトでこのオプションが指定されていない場合には、DNS は設定されません。

-U, --unattended

ユーザー入力を要求しない無人インストールセッションを有効にします。

関連情報

  • ipa-server-install(1) man page
  • ipa-replica-install(1)の man ページ

第9章 IdM サーバーのインストールに関するトラブルシューティング

次のセクションでは、失敗した IdM サーバーのインストールについての情報を収集する方法を説明します。また、一般的なインストールの問題を解決する方法を説明します。

9.1. IdM サーバーインストールエラーログの確認

Identity Management (IdM) サーバーをインストールすると、以下のログファイルにデバッグ情報が追加されます。

  • /var/log/ipaserver-install.log
  • /var/log/httpd/error_log
  • /var/log/dirsrv/slapd-INSTANCE-NAME/access
  • /var/log/dirsrv/slapd-INSTANCE-NAME/errors

ログファイルの最後の行は成功または失敗を報告し、ERROR および DEBUG エントリーが追加のコンテキストを提供します。

失敗した IdM サーバーのインストールをトラブルシューティングするには、ログファイルの末尾でエラーを確認し、この情報を使用して、対応する問題を解決します。

前提条件

  • IdM ログファイルの内容を表示するには、root 権限が必要です。

手順

  1. tail コマンドを使用して、ログファイルの最後の行を表示します。以下の例では、/var/log/ipaserver-install.log の最後の 10 行を表示しています。

    [user@server ~]$ sudo tail -n 10 /var/log/ipaserver-install.log
    [sudo] password for user:
    value = gen.send(prev_value)
    File "/usr/lib/python3.6/site-packages/ipapython/install/common.py", line 65, in _install
    for unused in self._installer(self.parent):
    File "/usr/lib/python3.6/site-packages/ipaserver/install/server/init.py", line 564, in main
    master_install(self)
    File "/usr/lib/python3.6/site-packages/ipaserver/install/server/install.py", line 291, in decorated
    raise ScriptError()
    
    2020-05-27T22:59:41Z DEBUG The ipa-server-install command failed, exception: ScriptError:
    2020-05-27T22:59:41Z ERROR The ipa-server-install command failed. See /var/log/ipaserver-install.log for more information
  2. ログファイルを対話的に確認するには、less ユーティリティーを使用してログファイルの末尾を開き、 および キーを使用して移動します。以下の例では、/var/log/ipaserver-install.log ファイルを対話的に開きます。

    [user@server ~]$ sudo less -N +G /var/log/ipaserver-install.log
  3. このレビュープロセスを残りのログファイルで繰り返すことにより、追加のトラブルシューティング情報を収集します。

    [user@server ~]$ sudo less -N +G /var/log/httpd/error_log
    
    [user@server ~]$ sudo less -N +G /var/log/dirsrv/slapd-INSTANCE-NAME/access
    
    [user@server ~]$ sudo less -N +G /var/log/dirsrv/slapd-INSTANCE-NAME/errors

関連情報

  • 失敗した IdM サーバーのインストールを解決できず、Red Hat テクニカルサポートサブスクリプションがある場合は、Red Hat カスタマーポータル でテクニカルサポートケースを作成し、サーバーの sosreport を提供します。
  • sosreport ユーティリティーは、設定の詳細、ログ、およびシステム情報を RHEL システムから収集します。sosreport ユーティリティーの詳細は、「Red Hat Enterprise Linux 上での sosreport の役割と取得方法」を参照してください。

9.2. IdM CA インストールエラーの確認

Identity Management (IdM) サーバーに認証局 (CA) サービスをインストールすると、デバッグ情報が以下の場所 (推奨される優先順位) に追加されます。

場所説明

/var/log/pki/pki-ca-spawn.$TIME_OF_INSTALLATION.log

高レベルの問題と、pkispawn インストールプロセスの Python トレース

journalctl -u pki-tomcatd@pki-tomcat output

pki-tomcatd@pki-tomcat サービスからのエラー

/var/log/pki/pki-tomcat/ca/debug.$DATE.log

公開鍵インフラストラクチャー (PKI) 製品のアクティビティーの大規模な JAVA スタックトレース

/var/log/pki/pki-tomcat/ca/signedAudit/ca_audit log file

PKI 製品の監査ログ

  • /var/log/pki/pki-tomcat/ca/system
  • /var/log/pki/pki-tomcat/ca/transactions
  • /var/log/pki/pki-tomcat/catalina.$DATE.log

証明書を使用するサービスプリンシパル、ホスト、およびその他のエンティティーの証明書操作の低レベルのデバッグデータ

注記

オプションの CA コンポーネントのインストール中に IdM サーバー全体のインストールが失敗すると、CA の詳細がログに記録されません。メッセージは /var/log/ipaserver-install.log ファイルに記録され、インストールプロセスが全体的な失敗を示すようになります。Red Hat は、CA インストールの失敗に固有のログファイルを確認することを推奨します。

この動作の唯一の例外は、CA サービスをインストールし、ルート CA が外部 CA の場合です。外部 CA の証明書に問題がある場合は、エラーが /var/log/ipaserver-install.log に記録されます。

失敗した IdM CA インストールをトラブルシューティングするには、これらのログファイルの末尾でエラーを確認し、この情報を使用して、対応する問題を解決します。

前提条件

  • IdM ログファイルの内容を表示するには、root 権限が必要です。

手順

  1. ログファイルを対話的に確認するには、less ユーティリティーを使用してログファイルの末尾を開き、 および キーを使用して移動し、ScriptError を検索します。以下の例では、/var/log/pki/pki-ca-spawn.$TIME_OF_INSTALLATION.log を開きます。

    [user@server ~]$ sudo less -N +G /var/log/pki/pki-ca-spawn.20200527185902.log
  2. 上記のすべてのログファイルを使用してこの確認プロセスを繰り返して、追加のトラブルシューティング情報を収集します。

関連情報

  • 失敗した IdM サーバーのインストールを解決できず、Red Hat テクニカルサポートサブスクリプションがある場合は、Red Hat カスタマーポータル でテクニカルサポートケースを作成し、サーバーの sosreport を提供します。
  • sosreport ユーティリティーは、設定の詳細、ログ、およびシステム情報を RHEL システムから収集します。sosreport ユーティリティーの詳細は、「Red Hat Enterprise Linux 上での sosreport の役割と取得方法」を参照してください。

9.3. 部分的な IdM サーバーインストールの削除

IdM サーバーのインストールに失敗した場合は、設定ファイルを残すことができます。IdM サーバーのインストールに失敗した追加で、インストールスクリプトで IPA がすでに設定されていることが報告されます。

[root@server ~]# ipa-server-install

The log file for this installation can be found in /var/log/ipaserver-install.log
IPA server is already configured on this system.
If you want to reinstall the IPA server, please uninstall it first using 'ipa-server-install --uninstall'.
The ipa-server-install command failed. See /var/log/ipaserver-install.log for more information

この問題を解決するには、部分的な IdM サーバー設定をアンインストールし、インストールプロセスを再試行します。

前提条件

  • root 権限があること。

手順

  1. IdM サーバーとして設定するホストから、IdM サーバーソフトウェアをアンインストールします。

    [root@server ~]# ipa-server-install --uninstall
  2. 繰り返しインストールに失敗したため、IdM サーバーのインストールに問題が生じた場合は、オペレーティングシステムを再インストールします。

    IdM サーバーのインストール要件の 1 つは、カスタマイズなしでクリーンなシステムです。インストールに失敗した場合は、予期せずにシステムファイルを変更することで、ホストの整合性が侵害される可能性があります。

関連情報

9.4. 関連情報

第10章 IdM サーバーのアンインストール

この手順では、server123.idm.example.com という名前のIdentity Management (IdM)サーバーをアンインストールする方法を説明します。

前提条件

  • サーバーへの root アクセス権限がある。
  • サーバーで、IdM 管理者の認証情報を取得している。

手順

  1. IdM 環境で統合 DNS が使用されている場合は、server123.idm.example.com が唯一の 有効な DNS サーバーではないことを確認してください。

    [root@server123 ~]# ipa server-role-find --role 'DNS server'
    ----------------------
    2 server roles matched
    ----------------------
      Server name: server456.idm.example.com
      Role name: DNS server
      Role status: enabled
    [...]
    ----------------------------
    Number of entries returned 2
    ----------------------------

    トポロジー内の残りの DNS サーバーが server123 だけの場合は、DNS サーバーロールを別の IdM サーバーに追加します。詳細は、ipa-dns-install(1) man ページを参照してください。

  2. IdM 環境で統合認証局(CA)が使用されている場合は、以下を行います。

    1. server123.idm.example.com が唯一の 有効な CA サーバーではないことを確認します。

      [root@server123 ~]# ipa server-role-find --role 'CA server'
      ----------------------
      2 server roles matched
      ----------------------
        Server name: server123.idm.example.com
        Role name: CA server
        Role status: enabled
      
        Server name: r8server.idm.example.com
        Role name: CA server
        Role status: enabled
      ----------------------------
      Number of entries returned 2
      ----------------------------

      トポロジー内の残りの CA サーバーが server123 だけの場合は、CA サーバーロールを別の IdM サーバーに追加します。詳細は、ipa-ca-install(1) man ページを参照してください。

    2. IdM 環境で vault を有効にしている場合は、server123.idm.example.com が唯一の 有効な Key Recovery Authority (KRA)サーバーではないことを確認します。

      [root@server123 ~]# ipa server-role-find --role 'KRA server'
      ----------------------
      2 server roles matched
      ----------------------
        Server name: server123.idm.example.com
        Role name: KRA server
        Role status: enabled
      
        Server name: r8server.idm.example.com
        Role name: KRA server
        Role status: enabled
      ----------------------------
      Number of entries returned 2
      ----------------------------

      トポロジー内の残りの KRA サーバーが server123 だけの場合は、KRA サーバーロールを別の IdM サーバーに追加します。詳細は、man ipa-kra-install(1) を参照してください。

    3. server123.idm.example.com が CA 更新サーバーではないことを確認します。

      [root@server123 ~]# ipa config-show | grep 'CA renewal'
        IPA CA renewal master: r8server.idm.example.com

      server123 が CA 更新サーバーである場合は、CA 更新サーバーロールを別のサーバーに移動する方法の詳細について、Changing and resetting IdM CA renewal serverを参照してください。

    4. server123.idm.example.com が現在の証明書失効リスト(CRL)パブリッシャーではないことを確認します。

      [root@server123 ~]# ipa-crlgen-manage status
      CRL generation: disabled

      出力に、CRL の生成が server123 で有効になっていることが示されている場合は、CRL パブリッシャーロールを別のサーバーに移動する方法の詳細について、Generating CRL on an IdM CA serverを参照してください。

  3. トポロジー内の別の IdM サーバーに接続します。

    $ ssh idm_user@another_server
  4. サーバーで、IdM 管理者の認証情報を取得します。

    [idm_user@another_server ~]$ kinit admin
  5. サーバーで、トポロジーから server123.idm.example.com を削除します。

    [root@another_server ~]$ ipa server-del server123.idm.example.com
  6. server123.idm.example.com に戻り、既存の IdM インストールをアンインストールします。

    [root@server123 ~]# ipa-server-install --uninstall
    ...
    Are you sure you want to continue with the uninstall procedure? [no]: yes
  7. server123.idm.example.com を参照するすべてのネームサーバー (NS) の DNS レコードが DNS ゾーンから削除されていることを確認します。使用する DNS が IdM により管理される統合 DNS であるか、外部 DNS であるかに関わらず、確認を行なってください。IdM から DNS レコードを削除する方法は、 Deleting DNS records in the IdM CLIを参照してください。

第11章 IdM サーバーの名前変更

既存の Identity Management (IdM) サーバーのホスト名は変更できません。異なる名前のレプリカでサーバーを置き換えます。

手順

  1. 既存のサーバーの代わりになる新しいレプリカをインストールし、このレプリカに必要なホスト名と IP アドレスが指定されるようにします。詳細は、「IdM レプリカのインストール」を参照してください。

    重要

    アンインストールするサーバーが証明書失効リスト (CRL) パブリッシャーサーバーである場合は、続行する前に別のサーバーを CRL パブリッシャーサーバーに指定してください。移行手順のコンテキストでこの設定を行う方法は、以下のセクションを参照してください。

  2. 既存の IdM サーバーインスタンスを停止します。

    [root@old_server ~]# ipactl stop
  3. IdM サーバーのアンインストールの説明に従って、既存のサーバーをアンインストールします。

第12章 IdM クライアントをインストールするためのシステムの準備

本章では、Identity Management (IdM) クライアントをインストールするのに必要なシステムの条件を説明します。

12.1. IdM クライアントの DNS 要件

デフォルトでは、クライアントインストーラーは、ホスト名の親であるすべてのドメインの DNS SRV レコード _ldap._tcp.DOMAIN を検索します。たとえば、クライアントマシンのホスト名が client1.idm.example.com である場合は、インストーラーが _ldap._tcp.idm.example.com_ldap._tcp.example.com、および _ldap._tcp.com の DNS SRV レコードから IdM サーバーのホスト名を取得しようとします。その後、検出されたドメインを使用して、クライアントコンポーネント (SSSD や Kerberos 5 設定など) をマシン上で設定します。

しかし、IdM クライアントのホスト名を、プライマリー DNS ドメインの一部にする必要はありません。クライアントマシンのホスト名が IdM サーバーのサブドメインでない場合は、IdM ドメインを ipa-client-install コマンドの --domain オプションとして渡します。これにより、クライアントのインストール後に、SSSD コンポーネントと Kerberos コンポーネントの両方の設定ファイルにドメインが設定され、IdM サーバーの自動検出に使用されます。

関連情報

12.2. IdM クライアントのポート要件

Identity Management (IdM) クライアントは、IdM サーバーの複数のポートに接続し、サービスと通信します。

IdM クライアントでこれらのポートを 送信方向 に開く必要があります。firewalld などの、送信パケットにフィルターを設定しないファイアウォールを使用している場合は、ポートを送信方向で使用できます。

関連情報

12.3. IdM クライアントの IPv6 要件

Identity Management (IdM) では、IdM に登録するホストのカーネルで IPv6 プロトコルを有効にする必要はありません。たとえば、内部ネットワークで IPv4 プロトコルのみを使用する場合には、System Security Services Daemon (SSSD) が IPv4 だけを使用して IdM サーバーと通信するように設定できます。/etc/sssd/sssd.conf ファイルの [domain/NAME] セクションに次の行を追加して、これを設定できます。

lookup_family_order = ipv4_only

関連情報

  • lookup_family_order オプションの詳細は、sssd.conf(5) の man ページを参照してください。

12.4. IdM クライアントのインストールに必要なパッケージ

RHEL 8 では、Identity Management (IdM) クライアントのインストールに必要なパッケージはモジュールとして同梱されます。以下の 2 つの IdM ストリームが IdM クライアントパッケージを提供します。

12.4.1. idm:client ストリームからの IdM クライアントパッケージのインストール

idm:client ストリームは、idm モジュールのデフォルトのストリームです。お使いのマシンにサーバーコンポーネントをインストールする必要がない場合は、このストリームを使用して IdM クライアントパッケージをダウンロードします。長期サポート対象の IdM クライアントソフトウェアを一貫して使用する必要があり、サーバーコンポーネントが必要でない場合は、idm:client ストリームの使用が推奨されます。

重要

以前に idm:DL1 ストリームを有効にし、そこからパッケージをダウンロードした場合は、idm:client ストリームに切り替える際に、関連するインストール済みコンテンツをすべて排他的に削除し、idm:DL1 を無効にしてから、idm:client ストリームを有効にする必要があります。現在のストリームを無効にせずに新しいストリームを有効にしようとすると、エラーが発生します。続行方法の詳細は「後続のストリームへの切り替え」を参照してください。

手順

  • IdM クライアントのインストールに必要なパッケージをダウンロードするには、次のコマンドを実行します。

    # yum module install idm

12.4.2. idm:DL1 ストリームからの IdM クライアントパッケージのインストール

idm:DL1 からパッケージをダウンロードするには、このストリームを有効にする必要があります。マシン上に IdM サーバーコンポーネントをインストールする必要がある場合は、このストリームを使用して IdM クライアントパッケージをダウンロードしてください。

重要

以前に idm:client ストリームを有効にし、そこからパッケージをダウンロードした場合は、idm:DL1 ストリームに切り替える際に、関連するインストール済みコンテンツをすべて排他的に削除し、idm:client を無効にしてから、idm:DL1 ストリームを有効にする必要があります。現在のストリームを無効にせずに新しいストリームを有効にしようとすると、エラーが発生します。続行方法の詳細は「後続のストリームへの切り替え」を参照してください。

手順

  1. idm:DL1 ストリーム経由で配信される RPM に切り替えるには、次のコマンドを実行します。

    # yum module enable idm:DL1
    # yum distro-sync
  2. IdM クライアントのインストールに必要なパッケージをダウンロードするには、次のコマンドを実行します。

    # yum module install idm:DL1/client

第13章 IdM クライアントのインストール: 基本的なシナリオ

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

Identity Management (IdM) クライアントを正しくインストールするには、クライアントの登録に使用できる認証情報を指定する必要があります。以下の認証方法を使用できます。

13.1. 前提条件

IdM クライアントをインストールする前に、すべての前提条件を満たしていることを確認してください。IdM クライアントをインストールするためのシステムの準備を参照してください。

13.2. ユーザー認証情報でクライアントのインストール: 対話的なインストール

この手順では、登録権限のあるユーザーの認証情報を使用してシステムをドメインに登録し、Identity Management (IdM) クライアントを対話的にインストールする方法を説明します。

前提条件

  • クライアントを IdM ドメインに登録する権限を持つユーザーの認証情報がある。たとえば、登録管理者 (Enrollment Administrator) ロールを持つ hostadmin ユーザーなどが該当します。

手順

  1. IdM クライアントとして設定するシステムで ipa-client-install ユーティリティーを実行します。

    # ipa-client-install --mkhomedir

    以下のいずれか条件に該当する場合は、--enable-dns-updates オプションを追加して、クライアントシステムの IP アドレスで DNS レコードを更新します。

    • クライアントを登録する IdM サーバーが、統合 DNS とともにインストールされた場合。
    • ネットワーク上の DNS サーバーが、GSS-TSIG プロトコルを用いた DNS エントリー更新を受け入れる場合。
    # ipa-client-install --enable-dns-updates --mkhomedir

    DNS 更新を有効にすると、クライアントが以下の条件に当てはまる場合に便利です。

    • クライアントに、DHCP (Dynamic Host Configuration Protocol) を使用して発行した動的 IP アドレスがある。
    • クライアントに、静的 IP アドレスが割り当てられたばかりで、IdM サーバーがそのアドレスを認識していない。
  2. インストールスクリプトは、DNS レコードなどの必要な設定をすべて自動的に取得しようとします。

    • IdM DNS ゾーンで SRV レコードが正しく設定されていると、スクリプトはその他に必要な値をすべて自動的に検出し、表示します。yes を入力して確定します。

      Client hostname: client.example.com
      Realm: EXAMPLE.COM
      DNS Domain: example.com
      IPA Server: server.example.com
      BaseDN: dc=example,dc=com
      
      Continue to configure the system with these values? [no]: yes
    • システムを別の値でインストールする場合は no を入力します。その後、ipa-client-install を再度実行し、コマンドラインオプションを ipa-client-install に追加して必要な値を指定します。以下に例を示します。

      • --hostname
      • --realm
      • --domain
      • --server
      • --mkhomedir
      重要

      完全修飾ドメイン名は、有効な DNS 名である必要があります。

      • 数字、アルファベット、およびハイフン(-)のみを使用できる。たとえば、アンダーラインは使用できないため、DNS の障害が発生する原因となる可能性があります。
      • ホスト名がすべて小文字である。大文字は使用できません。
    • スクリプトが一部の設定を自動的に取得できなかった場合は、値を入力するように求められます。
  3. スクリプトにより、アイデンティティーがクライアントの登録に使用されるユーザーの入力が求められます。たとえば、登録管理者 (Enrollment Administrator) ロールを持つ hostadmin ユーザーなどが該当します。

    User authorized to enroll computers: hostadmin
    Password for hostadmin@EXAMPLE.COM:
  4. インストールスクリプトにより、クライアントが設定されます。動作が完了するまで待ちます。

    Client configuration complete.

関連情報

  • クライアントインストールスクリプトが DNS レコードを検索する方法は、man ページの ipa-client-install(1) にある DNS Autodiscovery セクションを参照してください。

13.3. ワンタイムパスワードでクライアントのインストール: 対話的なインストール

この手順では、ワンタイムパスワードを使用してシステムをドメインに登録し、Identity Management (IdM) クライアントを対話的にインストールする方法を説明します。

前提条件

  • ドメインのサーバーに、クライアントシステムを IdM ホストとして追加している。ipa host-add コマンドに --random オプションを使用して、登録のワンタイムパスワードを無作為に生成します。

    $ ipa host-add client.example.com --random
     --------------------------------------------------
     Added host "client.example.com"
     --------------------------------------------------
      Host name: client.example.com
      Random password: W5YpARl=7M.n
      Password: True
      Keytab: False
      Managed by: server.example.com
    注記

    生成されたパスワードは、IdM ドメインへのマシン登録に使用した後は無効になります。登録の完了後、このパスワードは適切なホストキータブに置き換えられます。

手順

  1. IdM クライアントとして設定するシステムで ipa-client-install ユーティリティーを実行します。

    --password オプションを使用して、無作為に生成されたワンタイムパスワードを提供します。パスワードに特殊文字が含まれることが多いため、パスワードを一重引用符 (') で囲みます。

    # ipa-client-install --mkhomedir --password=password

    以下のいずれか条件に該当する場合は、--enable-dns-updates オプションを追加して、クライアントシステムの IP アドレスで DNS レコードを更新します。

    • クライアントを登録する IdM サーバーが、統合 DNS とともにインストールされた場合。
    • ネットワーク上の DNS サーバーが、GSS-TSIG プロトコルを用いた DNS エントリー更新を受け入れる場合。
    # ipa-client-install --password 'W5YpARl=7M.n' --enable-dns-updates --mkhomedir

    DNS 更新を有効にすると、クライアントが以下の条件に当てはまる場合に便利です。

    • クライアントに、DHCP (Dynamic Host Configuration Protocol) を使用して発行した動的 IP アドレスがある。
    • クライアントに、静的 IP アドレスが割り当てられたばかりで、IdM サーバーがそのアドレスを認識していない。
  2. インストールスクリプトは、DNS レコードなどの必要な設定をすべて自動的に取得しようとします。

    • IdM DNS ゾーンで SRV レコードが正しく設定されていると、スクリプトはその他に必要な値をすべて自動的に検出し、表示します。yes を入力して確定します。

      Client hostname: client.example.com
      Realm: EXAMPLE.COM
      DNS Domain: example.com
      IPA Server: server.example.com
      BaseDN: dc=example,dc=com
      
      Continue to configure the system with these values? [no]: yes
    • システムを別の値でインストールする場合は no を入力します。その後、ipa-client-install を再度実行し、コマンドラインオプションを ipa-client-install に追加して必要な値を指定します。以下に例を示します。

      • --hostname
      • --realm
      • --domain
      • --server
      • --mkhomedir
      重要

      完全修飾ドメイン名は、有効な DNS 名である必要があります。

      • 数字、アルファベット、およびハイフン(-)のみを使用できる。たとえば、アンダーラインは使用できないため、DNS の障害が発生する原因となる可能性があります。
      • ホスト名がすべて小文字である。大文字は使用できません。
    • スクリプトが一部の設定を自動的に取得できなかった場合は、値を入力するように求められます。
  3. インストールスクリプトにより、クライアントが設定されます。動作が完了するまで待ちます。

    Client configuration complete.

関連情報

  • クライアントインストールスクリプトが DNS レコードを検索する方法は、man ページの ipa-client-install(1) にある DNS Autodiscovery セクションを参照してください。

13.4. クライアントのインストール: 非対話的なインストール

非対話的なインストールでは、コマンドラインオプションを使用して、ipa-client-install ユーティリティーに必要な情報をすべて提供する必要があります。ここでは、非対話的なインストールに最低限必要なオプションを説明します。

クライアント登録の認証方法のオプション

利用可能なオプションは以下のとおりです。

  • --principal および --password - クライアントを登録する権限のあるユーザーの認証情報を指定します。
  • --random - クライアントに対して無作為に生成されたワンタイムパスワードを指定します。
  • --keytab - 前回登録時のキータブを指定します。
無人インストールのオプション

--unattended オプション - ユーザーによる確認を必要とせずにインストールを実行できるようにします。

SRV レコードが IdM DNS ゾーンで正しく設定されている場合は、スクリプトが自動的に必要な値をすべて検出します。スクリプトが自動的に値を検出できない場合は、以下のようなコマンドラインオプションを使用して指定してください。

  • --hostname - クライアントマシンの静的完全修飾ドメイン名 (FQDN) を指定します。

    重要

    FQDN は有効な DNS 名である必要があります。

    • 数字、アルファベット、およびハイフンのみを使用できる。たとえば、アンダーラインは使用できないため、DNS の障害が発生する原因となる可能性があります。
    • ホスト名がすべて小文字である。大文字は使用できません。
  • --domain - 既存の IdM デプロイメントのプライマリー DNS ドメインを指定します (例: example.com)。この名前は、IdM Kerberos レルム名を小文字で表しています。
  • --server - 接続する IdM サーバーの FQDN を指定します。このオプションが使用されると、Kerberos の DNS 自動検出が無効になり、KDC および管理サーバーの固定リストが設定されます。通常の状態では、サーバーの一覧はプライマリー IdM DNS ドメインから取得されるため、このオプションは必須ではありません。
  • --realm - 既存の IdM デプロイメントの Kerberos レルムを指定します。通常、IdM インストールで使用するプライマリー DNS ドメインを大文字で表したものです。通常の状態では、レルム名は IdM サーバーから取得されるため、このオプションは必須ではありません。

非対話的なインストールを行う基本的な ipa-client-install コマンドの例は次のとおりです。

# ipa-client-install --password 'W5YpARl=7M.n' --mkhomedir --unattended

 

非対話的なインストールを行う、追加のオプションを指定した ipa-client-install コマンドの例は次のとおりです。

# ipa-client-install --password 'W5YpARl=7M.n' --domain idm.example.com --server server.idm.example.com --realm IDM.EXAMPLE.COM --mkhomedir --unattended

関連情報

  • ipa-client-install により許可されるオプションの完全リストは、man ページの ipa-client-install(1) を参照してください。

13.5. クライアントインストール後に事前設定された IdM の削除

ipa-client-install スクリプトは、/etc/openldap/ldap.conf ファイルおよび /etc/sssd/sssd.conf ファイルから、以前の LDAP 設定および System Security Services Daemon (SSSD) 設定を削除します。クライアントをインストールする前にこれらのファイルの設定を変更すると、スクリプトにより新しいクライアントの値が追加されますが、コメントアウトされます。以下に例を示します。

BASE   dc=example,dc=com
URI    ldap://ldap.example.com

#URI ldaps://server.example.com # modified by IPA
#BASE dc=ipa,dc=example,dc=com # modified by IPA

Identity Management (IdM) の新しい設定値を適用するには、以下を行います。

  1. /etc/openldap/ldap.conf および /etc/sssd/sssd.conf を開きます。
  2. 以前の設定を削除します。
  3. 新しい IdM 設定のコメントを解除します。
  4. システム全体の LDAP 設定に依存するサーバープロセスの中には、再起動しないと変更が適用されない場合があります。openldap ライブラリーを使用するアプリケーションでは通常、起動時に設定がインポートされます。

13.6. IdM クライアントのテスト

コマンドラインインターフェースにより、ipa-client-install が正常に実行されたことが通知されますが、独自のテストを行うこともできます。

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

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

認証が適切に機能することをテストするには、root 以外のユーザーで su を実行し、root になります。

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

13.7. IdM クライアントのインストール時に実行する接続

IdM クライアントのインストール時に実行する要求には、Identity Management (IdM) のクライアントインストールツールである ipa-client-install により実行される操作の一覧が記載されています。

表13.1 IdM クライアントのインストール時に実行する要求

操作使用プロトコル目的

クライアントシステムに設定した DNS リゾルバーに対する DNS 解決

DNS

IdM サーバーの IP アドレスを検出。(任意) A/AAAA および SSHFP レコードを追加。

IdM レプリカ上のポート 88 (TCP/TCP6 および UDP/UDP6) への要求

Kerberos

Kerberos チケットの取得。

検出または設定された IdM サーバー上の IdM Apache ベースの Web サービスへの JSON-RPC 呼び出し

HTTPS

IdM クライアント登録。LDAP の方法が失敗した場合に CA 証明書チェーンを取得。必要な場合は証明書の発行を要求。

SASL GSSAPI 認証、プレーン LDAP、またはこの両方を使用した、IdM サーバー上のポート 389 (TCP/TCP6) への要求

LDAP

IdM クライアント登録、SSSD プロセスによるアイデンティティーの取得、ホストプリンシパルの Kerberos キーの取得。

ネットワークタイムプロトコル (NTP) の検出および解決 (任意)

NTP

クライアントシステムと NTP サーバー間の時間を同期。

13.8. インストール後のデプロイメント実行時の IdM クライアントのサーバーとの通信

Identity Management (IdM) フレームワークのクライアント側は 2 つの異なるアプリケーションで実装されます。

  • ipa コマンドラインインターフェース (CLI)
  • ブラウザーベースの Web UI

ブラウザーベースの Web UI は任意です。

CLI のポストインストール操作 は、IdM クライアントのポストインストールのデプロイメント実行時に CLI により実行される操作を表示します。Web UI のポストインストール操作 は、IdM クライアントのポストインストールのデプロイメント実行時に Web UI により実行される操作を表示します。

IdM クライアント (System Security Services Daemon (SSSD) および certmonger) で 2 つのデーモンを実行します。SSSD の通信パターンCertmonger の通信パターン は、このデーモンが IdM サーバーおよび Active Directory サーバーで利用可能なサービスと通信する方法を説明しています。

表13.2 CLI のポストインストール操作

操作使用プロトコル目的

クライアントシステムに設定した DNS リゾルバーに対する DNS 解決

DNS

IdM サーバーの IP アドレス検出。

IdM レプリカ上のポート 88 (TCP/TCP6 および UDP/UDP6) およびポート 464 (TCP/TCP6 および UDP/UDP6) への要求

Kerberos

Kerberos チケットの取得。Kerberos パスワードの変更。IdM Web UI への認証。

検出または設定された IdM サーバー上の IdM Apache ベースの Web サービスへの JSON-RPC 呼び出し

HTTPS

ipa ユーティリティーの使用。

表13.3 Web UI のポストインストール操作

操作使用プロトコル目的

検出または設定された IdM サーバー上の IdM Apache ベースの Web サービスへの JSON-RPC 呼び出し

HTTPS

IdM Web UI ページの取得。

13.8.1. SSSD 通信パターン

システムセキュリティーサービスデーモン (System Security Services Daemon: SSSD) は、リモートディレクトリーと認証メカニズムにアクセスするシステムサービスです。Identity Management (IdM) クライアントに設定すると、認証、認可、その他の ID 情報、およびその他のポリシー情報を提供する IdM サーバーに接続します。IdM サーバーと Active Directory (AD) が信頼関係にある場合、SSSD は AD にも接続し、Kerberos プロトコルを使用して AD ユーザーの認証を実行します。デフォルトでは SSSD は Kerberos を使用してローカル以外のユーザーを認証します。特別な状況では、代わりに LDAP プロトコルを使用するように SSSD を設定することがあります。

SSSD は、複数のサーバーと通信するように設定できます。IdM サーバーとの通信時における IdM クライアントの SSSD の通信パターンActive Directory ドメインコントローラーとの通信時における信頼エージェントとして機能する IdM サーバー上の SSSD の通信パターンでは、ldM での SSD の一般的な通信パターンを示しています。

表13.4 IdM サーバーとの通信時における IdM クライアントの SSSD の通信パターン

操作使用プロトコル目的

クライアントシステムに設定した DNS リゾルバーに対する DNS 解決

DNS

IdM サーバーの IP アドレス検出。

Identity Management レプリカおよび Active Directory ドメインコントローラー上のポート 88 (TCP/TCP6 と UDP/UDP6)、464 (TCP/TCP6 と UDP/UDP6)、および 749 (TCP/TCP6) への要求

Kerberos

Kerberos チケットの取得。Kerberos パスワードの変更。

SASL GSSAPI 認証、プレーン LDAP、またはこの両方を使用した、IdM サーバー上のポート 389 (TCP/TCP6) への要求

LDAP

IdM ユーザーおよびホストの情報を取得。HBAC および sudo ルールのダウンロード。マップ、SELinux ユーザーコンテキスト、SSH 公開鍵、および IdM LDAP に保存されるその他の情報の自動マウント。

(任意) スマートカード認証の場合、OCSP (Online Certificate Status Protocol) レスポンダーへの要求 (設定されている場合)。通常、ポート 80 で行われますが、クライアント証明書にある OCSP レスポンダー URL の実際の値により異なります。

HTTP

スマートカードにインストールされた証明書の状態に関する情報の取得。

表13.5 Active Directory ドメインコントローラーとの通信時における信頼エージェントとして機能する IdM サーバー上の SSSD の通信パターン

操作使用プロトコル目的

クライアントシステムに設定した DNS リゾルバーに対する DNS 解決

DNS

IdM サーバーの IP アドレス検出。

Identity Management レプリカおよび Active Directory ドメインコントローラー上のポート 88 (TCP/TCP6 と UDP/UDP6)、464 (TCP/TCP6 と UDP/UDP6)、および 749 (TCP/TCP6) への要求

Kerberos

Kerberos チケットの取得。Kerberos パスワードの変更。Kerberos をリモートで管理。

ポート 389 (TCP/TCP6 および UDP/UDP6) およびポート 3268 (TCP/TCP6) への要求

LDAP

Active Directory ユーザーおよびグループ情報のクエリー。Active Directory ドメインコントローラーの検出。

(任意) スマートカード認証の場合、OCSP (Online Certificate Status Protocol) レスポンダーへの要求 (設定されている場合)。通常、ポート 80 で行われますが、クライアント証明書にある OCSP レスポンダー URL の実際の値により異なります。

HTTP

スマートカードにインストールされた証明書の状態に関する情報の取得。

13.8.2. Certmonger の通信パターン

Certmonger は、Identity Management (IdM) サーバーおよび IdM クライアント上で実行するデーモンで、ホスト上のサービスに関連する SSL 証明書の更新を適時更新できるようにします。表13.6「Certmonger の通信パターン」 には、IdM マスター上で IdM クライアントの certmonger ユーティリティーにより実行される操作が説明されています。

表13.6 Certmonger の通信パターン

操作使用プロトコル目的

クライアントシステムに設定した DNS リゾルバーに対する DNS 解決

DNS

IdM サーバーの IP アドレス検出。

IdM レプリカ上のポート 88 (TCP/TCP6 および UDP/UDP6) およびポート 464 (TCP/TCP6 および UDP/UDP6) への要求

Kerberos

Kerberos チケットの取得。

検出または設定された IdM サーバー上の IdM Apache ベースの Web サービスへの JSON-RPC 呼び出し

HTTPS

新しい証明書の要求。

IdM サーバーのポート 8080 (TCP/TCP6) でのアクセス

HTTP

OCSP (Online Certificate Status Protocol) レスポンダーおよび証明書の状態の取得。

(最初にインストールされたサーバーまたは証明書の追跡が移動したサーバー上) IdM サーバーのポート 8443 (TCP/TCP6) でのアクセス

HTTPS

IdM サーバー上での認証局の管理 (IdM サーバーおよびレプリカのインストール時のみ)

第14章 キックスタートによる IdM クライアントのインストール

キックスタートの登録により、Red Hat Enterprise Linux のインストール時に新しいシステムが自動的に Identity Management (IdM) ドメインに追加されます。

14.1. キックスタートによるクライアントのインストール

この手順では、キックスタートファイルを使用して Identity Management (IdM) クライアントをインストールする方法を説明します。

前提条件

  • キックスタートの登録前に sshd サービスを開始しない。クライアントを登録する前に sshd を開始すると、SSH キーが自動的に生成されますが、「クライアントインストール用のキックスタートファイル」 のキックスタートファイルは同じ目的でスクリプトを使用し、これが推奨される方法になります。

手順

  1. IdM サーバーでホストエントリーを事前作成し、エントリーの一時パスワードを設定します。

    $ ipa host-add client.example.com --password=secret

    キックスタートがこのパスワードを使用して、クライアントのインストール時に認証し、最初の認証試行後に無効にします。クライアントが正常にインストールされると、キータブを使用して認証が行われます。

  2. 「クライアントインストール用のキックスタートファイル」 に記載されている内容でキックスタートファイルを作成します。network コマンドを使用して、ネットワークがキックスタートファイルで適切に設定されているようにしてください。
  3. キックスタートファイルを使用して、IdM クライアントをインストールします。

14.2. クライアントインストール用のキックスタートファイル

ここでは、Identity Management (IdM) クライアントのインストールに使用できるキックスタートファイルの内容を説明します。

インストールするパッケージ一覧に含まれる ipa-client パッケージ

キックスタートファイルの %packages セクションに、ipa-client パッケージを追加します。以下に例を示します。

%packages
...
ipa-client
...
IdM クライアントのインストール後の手順

インストール後の手順には以下が含まれている必要があります。

  • 登録前に SSH キーが確実に生成されるようにする手順
  • 以下を指定して ipa-client-install ユーティリティーを実行する手順

たとえば、ワンタイムパスワードを使用し、DNS からではなくコマンドラインから必要なオプションを取得するキックスタートインストールのポストインストール手順は次のようになります。

%post --log=/root/ks-post.log

# Generate SSH keys; ipa-client-install uploads them to the IdM server by default
/usr/libexec/openssh/sshd-keygen rsa

# Run the client install script
/usr/sbin/ipa-client-install --hostname=client.example.com --domain=EXAMPLE.COM --enable-dns-updates --mkhomedir -w secret --realm=EXAMPLE.COM --server=server.example.com

任意で、キックスタートファイルに以下のような他のオプションを含めることもできます。

  • 非対話的なインストールでは、--unattended オプションを ipa-client-install に追加します。
  • クライアントのインストールスクリプトがマシンの証明書を要求できるようにするには、以下を行います。

    • --request-cert オプションを ipa-client-install に追加します。
    • キックスタートの chroot 環境で、getcert ユーティリティーおよび ipa-client-install ユーティリティーの両方に対して /dev/null にシステムバスのアドレスを設定します。これには、キックスタートファイルのポストインストール手順で ipa-client-install 手順の前に次の行を追加します。

      # env DBUS_SYSTEM_BUS_ADDRESS=unix:path=/dev/null getcert list
      # env DBUS_SYSTEM_BUS_ADDRESS=unix:path=/dev/null ipa-client-install

14.3. IdM クライアントのテスト

コマンドラインインターフェースにより、ipa-client-install が正常に実行されたことが通知されますが、独自のテストを行うこともできます。

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

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

認証が適切に機能することをテストするには、root 以外のユーザーで su を実行し、root になります。

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

第15章 IdM クライアントのインストールに関するトラブルシューティング

次のセクションでは、失敗した IdM クライアントのインストールについての情報を収集する方法を説明します。また、一般的なインストールの問題を解決する方法を説明します。

15.1. IdM クライアントのインストールエラーの確認

Identity Management(IdM)クライアントをインストールすると、デバッグ情報が /var/log/ipaclient-install.log に追加されます。クライアントのインストールに失敗した場合、インストーラーは障害をログに記録し、変更をロールバックしてホストに変更を加えます。インストールが失敗する理由は、インストーラーがロールバック手順も記録するため、ログファイルの末尾には存在しない可能性があります。

失敗した IdM クライアントのインストールをトラブルシューティングするには、/ var/log/ipaclient-install.log ファイルの ScriptError とラベルが付いた行を確認し、この情報を使用して、対応する問題を解決します。

前提条件

  • IdM ログファイルの内容を表示するには、root 権限が必要です。

手順

  1. grep ユーティリティーを使用して、/var/log/ipaserver-install.log ファイルから キーワード ScriptError を取得します。

    [user@server ~]$ sudo grep ScriptError /var/log/ipaclient-install.log
    [sudo] password for user:
    2020-05-28T18:24:50Z DEBUG The ipa-client-install command failed, exception: ScriptError: One of password / principal / keytab is required.
  2. ログファイルを対話的に確認するには、less ユーティリティーを使用してログファイルの末尾を開き、 および キーを使用して移動します。

    [user@server ~]$ sudo less -N +G /var/log/ipaclient-install.log

関連情報

  • 失敗した IdM クライアントのインストールを解決できず、Red Hat テクニカルサポートサブスクリプションがある場合は、Red Hat カスタマーポータル でテクニカルサポートケースを作成し、クライアントの sosreport を提供します。
  • sosreport ユーティリティーは、設定の詳細、ログ、およびシステム情報を RHEL システムから収集します。sosreport ユーティリティーの詳細は、「Red Hat Enterprise Linux 上での sosreport の役割と取得方法」を参照してください。

15.2. クライアントインストールが DNS レコードの更新に失敗した場合の問題の解決

IdM クライアントインストーラーは、nsupdate コマンドで PTR、SSHFP、および追加の DNS レコードを作成します。ただし、クライアントソフトウェアのインストールおよび設定後にクライアントが DNS レコードを更新できない場合、インストールプロセスは失敗します。

この問題を修正するには、/var/log/client-install.log で設定を確認し、DNS エラーを確認します。

前提条件

  • IdM 環境の DNS ソリューションとして IdM DNS を使用している。

手順

  1. クライアントが有効になっている DNS ゾーンの動的更新を確認します。

    [user@server ~]$ ipa dnszone-mod idm.example.com. --dynamic-update=TRUE
  2. DNS サービスを実行している IdM サーバーで、TCP プロトコルと UDP プロトコルの両方でポート 53 が開かれていることを確認します。

    [user@server ~]$ sudo firewall-cmd --permanent --add-port=53/tcp --add-port=53/udp
    [sudo] password for user:
    success
    [user@server ~]$ firewall-cmd --runtime-to-permanent
    success
  3. grep ユーティリティーを使用して、/var/log/client-install.log から nsupdate コマンドの内容を取得し、どの DNS レコードの更新に失敗しているかを確認します。

    [user@server ~]$ sudo grep nsupdate /var/log/ipaclient-install.log

関連情報

  • 失敗したインストールを解決できず、Red Hat テクニカルサポートサブスクリプションがある場合は、Red Hat カスタマーポータル でテクニカルサポートケースを作成し、クライアントの sosreport を提供します。
  • sosreport ユーティリティーは、設定の詳細、ログ、およびシステム情報を RHEL システムから収集します。sosreport ユーティリティーの詳細は、「Red Hat Enterprise Linux 上での sosreport の役割と取得方法」を参照してください。

15.3. クライアントのインストールが IdM Kerberos レルムへの参加に失敗した場合の問題の解決

クライアントが IdM Kerberos レルムに参加できない場合、IdM クライアントのインストールプロセスに失敗します。

Joining realm failed: Failed to add key to the keytab
child exited with 11

Installation failed. Rolling back changes.

この失敗の原因は、空の Kerberos キータブが原因です。

前提条件

  • システムファイルを削除するには、root 権限が必要です。

手順

  1. /etc/krb5.keytab を削除します。

    [user@client ~]$ sudo rm /etc/krb5.keytab
    [sudo] password for user:
    [user@client ~]$ ls /etc/krb5.keytab
    ls: cannot access '/etc/krb5.keytab': No such file or directory
  2. IdM クライアントのインストールを再試行します。

関連情報

  • 失敗したインストールを解決できず、Red Hat テクニカルサポートサブスクリプションがある場合は、Red Hat カスタマーポータル でテクニカルサポートケースを作成し、クライアントの sosreport を提供します。
  • sosreport ユーティリティーは、設定の詳細、ログ、およびシステム情報を RHEL システムから収集します。sosreport ユーティリティーの詳細は、「Red Hat Enterprise Linux 上での sosreport の役割と取得方法」を参照してください。

15.4. 関連情報

第16章 IdM クライアントの再登録

16.1. IdM におけるクライアントの再登録

本セクションでは、Identity Management (IdM) クライアントを再登録する方法を説明します。

クライアントのハードウェア障害などの理由で、クライアントマシンが破壊され、IdM サーバーとの接続が失われた場合は、キータブがあればクライアントを再登録できます。この場合は、同じホスト名でクライアントを IdM 環境に戻します。

再登録の間、クライアントは新しい鍵 (Kerberos および SSH ) を生成しますが、LDAP データベースのクライアントのアイデンティティーは変更されません。再登録後、ホストは、IdM サーバーとの接続を失う前と同じ FQDN を持つ同じ LDAP オブジェクトに、キーとその他の情報を保持します。

重要

ドメインエントリーがアクティブなクライアントのみを再登録できます。クライアントをアンインストール (ipa-client-install --uninstall を使用) した場合や、ホストエントリーを無効 (ipa host-disable を使用) にした場合は再登録できません。

クライアントの名前を変更すると、再登録することができません。これは、IdM では、LDAP にあるクライアントのエントリーのキー属性がクライアントのホスト名 (FQDN) であるためです。クライアントの再登録中はクライアントの LDAP オブジェクトは変更されませんが、クライアントの名前を変更すると、クライアントの鍵とその他の情報は新しい FQDN を持つ異なる LDAP オブジェクトに格納されます。そのため、IdM からホストをアンインストールし、ホストのホスト名を変更して、新しい名前で IdM クライアントとしてインストールするのが、クライアントの名前を変更する唯一の方法です。クライアントの名前を変更する方法はIdM クライアントシステムの名前変更を参照してください。

16.1.1. クライアント再登録中に行われること

再登録時に、IdM は以下を行います。

  • 元のホスト証明書を破棄する。
  • 新規の SSH 鍵を作成する。
  • 新規のキータブを生成する。

16.2. ユーザー認証情報でクライアントの再登録: 対話的な再登録

この手順では、権限のあるユーザーの認証情報を使用して、Identity Management (IdM) クライアントを対話的に再登録する方法を説明します。

  1. 同じホスト名のクライアントマシンを再作成します。
  2. クライアントマシンで ipa-client-install --force-join コマンドを実行します。

    # ipa-client-install --force-join
  3. スクリプトにより、アイデンティティーがクライアントの再登録に使用されるユーザーの入力が求められます。たとえば、登録管理者 (Enrollment Administrator) ロールを持つ hostadmin ユーザーなどが該当します。

    User authorized to enroll computers: hostadmin
    Password for hostadmin@EXAMPLE.COM:

関連情報

16.3. クライアントのキータブでクライアントの再登録: 非対話的な再登録

前提条件

  • /tmp/root などのディレクトリーに元のクライアントキータブファイルをバックアップします。

手順

この手順では、クライアントシステムのキータブファイルを使用して、Identity Management (IdM) クライアントを非対話的に再登録する方法を説明します。たとえば、クライアントのキータブを使用した再登録は自動インストールに適しています。

  1. 同じホスト名のクライアントマシンを再作成します。
  2. バックアップした場所から、再作成したクライアントマシンの /etc/ ディレクトリーにキータブファイルをコピーします。
  3. ipa-client-install ユーティリティーを使用してクライアントを再登録し、--keytab オプションでキータブの場所を指定します。

    # ipa-client-install --keytab /etc/krb5.keytab
    注記

    登録を開始するために認証する場合は、--keytab オプションで指定するキータブのみが使用されます。再登録中、IdM はクライアントに対して新しいキータブを生成します。

16.4. IdM クライアントのテスト

コマンドラインインターフェースにより、ipa-client-install が正常に実行されたことが通知されますが、独自のテストを行うこともできます。

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

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

認証が適切に機能することをテストするには、root 以外のユーザーで su を実行し、root になります。

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

第17章 IdM クライアントのアンインストール

管理者は、環境から Identity Management (IdM) クライアントを削除できます。

17.1. IdM クライアントのアンインストール

クライアントをアンインストールすると、クライアントが Identity Management (IdM) ドメインから削除され、SSSD (System Security Services Daemon) などの特定のシステムサービスの IdM 設定もすべて削除されます。これにより、クライアントシステムの以前の設定が復元します。

手順

  1. ipa-client-install --uninstall コマンドを入力します。

    [root@client ~]# ipa-client-install --uninstall
  2. (オプション) IdM ユーザーの Kerberos Ticket-granting Ticket (TGT) を取得できないことを確認します。

    [root@client ~]# kinit admin
    kinit: Client 'admin@EXAMPLE.COM' not found in Kerberos database while getting initial credentials
    [root@client ~]#

    Kerberos TGT チケットが正常に返された場合には、IdM クライアントのアンインストール: 以前に複数回インストールを行った場合の追加手順にあるアンインストール手順を実行してください。

  3. クライアントで、特定した Keytab から以前の Kerberos プリンシパル (/etc/krb5.keytab を除く) を削除します。

    [root@client ~]# ipa-rmkeytab -k /path/to/keytab -r EXAMPLE.COM
  4. IdM サーバーで、IdM からクライアントホストの DNS エントリーをすべて削除します。

    [root@server ~]# ipa dnsrecord-del
    Record name: old-client-name
    Zone name: idm.example.com
    No option to delete specific record provided.
    Delete all? Yes/No (default No): yes
    ------------------------
    Deleted record "old-client-name"
  5. IdM サーバーで、IdM LDAP サーバーからクライアントホストエントリーを削除します。これにより、すべてのサービスが削除され、そのホストに発行されたすべての証明書が無効になります。

    [root@server ~]# ipa host-del client.idm.example.com
    重要

    クライアントホストエントリーを、別の IP アドレスまたは別のホスト名を使用して今後再登録する場合に、IdM LDAP サーバーからクライアントホストエントリーを削除することが重要です。

17.2. IdM クライアントのアンインストール: 以前に複数回インストールを行った場合の追加手順

ホストを Identity Management (IdM) クライアントとして複数回、インストールしてアンインストールすると、アンインストール手順で IdM Kerberos 設定が復元されない可能性があります。

このような場合は、IdM Kerberos 設定を手動で削除する必要があります。極端なケースでは、オペレーティングシステムを再インストールする必要があります。

前提条件

  • ipa-client-install --uninstall コマンドを使用して、ホストから IdM クライアント設定をアンインストールしている。ただし、IdM サーバーから IdM ユーザーの Kerberos Ticket-granting Ticket (TGT) をまだ取得できます。
  • /var/lib/ipa-client/sysrestore ディレクトリーが空で、ディレクトリー内のファイルを使用してシステムの以前の IdM クライアント設定を復元できないことを確認している。

手順

  1. /etc/krb5.conf.ipa ファイルを確認します。

    • /etc/krb5.conf.ipa ファイルの内容が、IdM クライアントのインストール前の krb5.conf ファイルの内容と同じ場合は、以下の手順を実行します。

      1. /etc/krb5.conf ファイルを削除します。

        # rm /etc/krb5.conf
      2. /etc/krb5.conf.ipa ファイルの名前を /etc/krb5.conf に変更します。

        # mv /etc/krb5.conf.ipa /etc/krb5.conf
    • /etc/krb5.conf.ipa ファイルの内容が、IdM クライアントのインストール前の krb5.conf ファイルの内容と同じでない場合には、オペレーティングシステムのインストール直後の状態には Kerberos 設定を復元できます。
    1. krb5-libs パッケージを再インストールします。

      # yum reinstall krb5-libs

      このコマンドは、依存関係として krb5-workstation パッケージと、/etc/krb5.conf ファイルの元のバージョンを再インストールします。

  2. var/log/ipaclient-install.log ファイルが存在する場合は削除します。

検証手順

  • IdM ユーザー認証情報の取得を試みます。取得には失敗するはずです。

    [root@r8server ~]# kinit admin
    kinit: Client 'admin@EXAMPLE.COM' not found in Kerberos database while getting initial credentials
    [root@r8server ~]#

/etc/krb5.conf ファイルは、出荷時状態に復元されています。したがって、ホスト上の IdM ユーザーの Kerberos TGT を取得できません。

第18章 IdM クライアントシステムの名前変更

ここでは、Identity Management (IdM) クライアントシステムのホスト名を変更する方法を説明します。

警告

クライアントの名前は手動で変更します。ホスト名の変更が絶対に必要である場合のみ実行してください。

IdM クライアントの名前を変更するには、以下を行います。

  1. ホストを準備します。詳細は、名前を変更するための IdM クライアントの準備を参照してください。
  2. ホストから IdM クライアントをアンインストールします。詳しくはクライアントのアンインストール を参照してください。
  3. ホストの名前を変更します。詳しくはクライアントの名前の変更 を参照してください。
  4. 新しい名前でホストに IdM クライアントをインストールします。詳しくはクライアントの再インストール を参照してください。
  5. IdM クライアントのインストール後にホストを設定します。詳しくはサービスの再追加、証明書の再生成、およびホストグループの再追加 を参照してください。

18.1. 名前を変更するための IdM クライアントの準備

現在のクライアントをアンインストールする前に、クライアントの設定を書き留めます。新しいホスト名のマシンを再登録した後にこの設定を適用します

  • マシンで実行しているサービスを特定します。

    • ipa service-find コマンドを使用して、証明書のあるサービスを特定して出力します。

      $ ipa service-find old-client-name.example.com
    • さらに、各ホストには ipa service-find の出力に表示されないデフォルトの host service があります。ホストサービスのサービスプリンシパルは ホストプリンシパル とも呼ばれ、host/old-client-name.example.com になります。
  • ipa service-find old-client-name.example.com により表示されるすべてのサービスプリンシパルは、old-client-name.example.com 上の対応するキータブの場所を決定します。

    # find / -name "*.keytab"

    クライアントシステムの各サービスには、ldap/old-client-name.example.com@EXAMPLE.COM のように service_name/host_name@REALM の形式を取る Kerberos プリンシパルがあります。

  • マシンが所属するすべてのホストグループを特定します。

    # ipa hostgroup-find old-client-name.example.com

18.2. IdM クライアントのアンインストール

クライアントをアンインストールすると、クライアントが Identity Management (IdM) ドメインから削除され、SSSD (System Security Services Daemon) などの特定のシステムサービスの IdM 設定もすべて削除されます。これにより、クライアントシステムの以前の設定が復元します。

手順

  1. ipa-client-install --uninstall コマンドを入力します。

    [root@client ~]# ipa-client-install --uninstall
  2. (オプション) IdM ユーザーの Kerberos Ticket-granting Ticket (TGT) を取得できないことを確認します。

    [root@client ~]# kinit admin
    kinit: Client 'admin@EXAMPLE.COM' not found in Kerberos database while getting initial credentials
    [root@client ~]#

    Kerberos TGT チケットが正常に返された場合には、IdM クライアントのアンインストール: 以前に複数回インストールを行った場合の追加手順にあるアンインストール手順を実行してください。

  3. クライアントで、特定した Keytab から以前の Kerberos プリンシパル (/etc/krb5.keytab を除く) を削除します。

    [root@client ~]# ipa-rmkeytab -k /path/to/keytab -r EXAMPLE.COM
  4. IdM サーバーで、IdM からクライアントホストの DNS エントリーをすべて削除します。

    [root@server ~]# ipa dnsrecord-del
    Record name: old-client-name
    Zone name: idm.example.com
    No option to delete specific record provided.
    Delete all? Yes/No (default No): yes
    ------------------------
    Deleted record "old-client-name"
  5. IdM サーバーで、IdM LDAP サーバーからクライアントホストエントリーを削除します。これにより、すべてのサービスが削除され、そのホストに発行されたすべての証明書が無効になります。

    [root@server ~]# ipa host-del client.idm.example.com
    重要

    クライアントホストエントリーを、別の IP アドレスまたは別のホスト名を使用して今後再登録する場合に、IdM LDAP サーバーからクライアントホストエントリーを削除することが重要です。

18.3. IdM クライアントのアンインストール: 以前に複数回インストールを行った場合の追加手順

ホストを Identity Management (IdM) クライアントとして複数回、インストールしてアンインストールすると、アンインストール手順で IdM Kerberos 設定が復元されない可能性があります。

このような場合は、IdM Kerberos 設定を手動で削除する必要があります。極端なケースでは、オペレーティングシステムを再インストールする必要があります。

前提条件

  • ipa-client-install --uninstall コマンドを使用して、ホストから IdM クライアント設定をアンインストールしている。ただし、IdM サーバーから IdM ユーザーの Kerberos Ticket-granting Ticket (TGT) をまだ取得できます。
  • /var/lib/ipa-client/sysrestore ディレクトリーが空で、ディレクトリー内のファイルを使用してシステムの以前の IdM クライアント設定を復元できないことを確認している。

手順

  1. /etc/krb5.conf.ipa ファイルを確認します。

    • /etc/krb5.conf.ipa ファイルの内容が、IdM クライアントのインストール前の krb5.conf ファイルの内容と同じ場合は、以下の手順を実行します。

      1. /etc/krb5.conf ファイルを削除します。

        # rm /etc/krb5.conf
      2. /etc/krb5.conf.ipa ファイルの名前を /etc/krb5.conf に変更します。

        # mv /etc/krb5.conf.ipa /etc/krb5.conf
    • /etc/krb5.conf.ipa ファイルの内容が、IdM クライアントのインストール前の krb5.conf ファイルの内容と同じでない場合には、オペレーティングシステムのインストール直後の状態には Kerberos 設定を復元できます。
    1. krb5-libs パッケージを再インストールします。

      # yum reinstall krb5-libs

      このコマンドは、依存関係として krb5-workstation パッケージと、/etc/krb5.conf ファイルの元のバージョンを再インストールします。

  2. var/log/ipaclient-install.log ファイルが存在する場合は削除します。

検証手順

  • IdM ユーザー認証情報の取得を試みます。取得には失敗するはずです。

    [root@r8server ~]# kinit admin
    kinit: Client 'admin@EXAMPLE.COM' not found in Kerberos database while getting initial credentials
    [root@r8server ~]#

/etc/krb5.conf ファイルは、出荷時状態に復元されています。したがって、ホスト上の IdM ユーザーの Kerberos TGT を取得できません。

18.4. ホストシステムの名前変更

必要に応じてマシンの名前を変更します。以下に例を示します。

# hostnamectl set-hostname new-client-name.example.com

これで、新しいホスト名で、Identity Management (IdM) クライアントを IdM ドメインに再インストールできるようになります。

18.5. IdM クライアントの再インストール

クライアントのインストール」の手順に従って、名前を変更したホストにクライアントをインストールします。

18.6. サービスの再追加、証明書の再生成、およびホストグループの再追加

  1. Identity Management (IdM) サーバーで、名前を変更するための IdM クライアントの準備に定義された各サービスに新しいキータブを追加します。

    [root@server ~]# ipa service-add service_name/new-client-name
  2. 名前を変更するための IdM クライアントの準備で割り当てた証明書のあるサービスに対して証明書を生成します。これには、以下を行います。

    • IdM 管理ツールの使用
    • certmonger ユーティリティーの使用
  3. 名前を変更するための IdM クライアントの準備で特定されたホストグループにクライアントを再追加します。

第19章 IdM レプリカをインストールするためのシステムの準備

ここでは、Identity Management (IdM) レプリカのインストール要件を取り上げます。インストールを行う前に、システムがその要件を満たしていることを確認してください。

19.1. レプリカバージョンの要件

Red Hat Enterprise Linux (RHEL) 8 レプリカは、RHEL 7.4 以降で実行している Identity Management (IdM) サーバーとのみ機能します。RHEL 8 で実行している IdM レプリカを既存のデプロイメントに導入する前に、すべての IdM サーバーを RHEL 7.4 以降にアップグレードし、ドメインレベルを 1 に変更します。

さらに、レプリカが、同じまたはそれ以降のバージョンの IdM を実行している必要があります。以下に例を示します。

  • Red Hat Enterprise Linux 8 に IdM サーバーをインストールし、IdM 4.x パッケージを使用している。
  • レプリカが Red Hat Enterprise Linux 8 以降にインストールされ、バージョン 4.x 以降の IdM を使用している。

これにより、設定が適切にサーバーからレプリカにコピーされます。

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

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

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

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

 

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

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

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

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

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

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

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

19.3. IdM クライアントでのレプリカのインストールの認可

ipa-replica-install ユーティリティーを実行して既存の Identity Management (IdM) クライアントをレプリカのインストールする場合は、以下の 方法 1 または 方法 2 を選択して、レプリカのインストールを認証します。以下のいずれかが当てはまる場合は、方法 1 を選択します。

  • 上級システム管理者に手順の初期部分を実行させ、下級システム管理者にその他の作業を実行させたい場合。
  • レプリカのインストールを自動化する。
方法 1 - ipaservers ホストグループ
  1. IdM 管理者として IdM ホストにログインします。

    $ kinit admin
  2. クライアントマシンを ipaservers ホストグループに追加します。

    $ ipa hostgroup-add-member ipaservers --hosts client.idm.example.com
      Host-group: ipaservers
      Description: IPA server hosts
      Member hosts: server.idm.example.com, client.idm.example.com
    -------------------------
    Number of members added 1
    -------------------------
注記

ipaservers グループのメンバーシップは、管理者の認証情報と同様に、マシンに昇格した特権を付与します。したがって、次の手順では、ipa-replica-install ユーティリティーを、経験豊富ではないシステム管理者が、ホストで正常に実行できます。

方法 2 - 特権ユーザーの認証情報

特権ユーザーの認証情報を提供することで、レプリカのインストールを認可するには、以下のいずれかの方法を選択します。

  • ipa-replica-install ユーティリティーを起動したら、Identity Management (IdM) から認証情報の入力を求められます。これはデフォルトの動作です。
  • ipa-replica-install ユーティリティーを実行する直前に、特権ユーザーとしてクライアントにログインします。デフォルトの特権ユーザーは admin です。

    $ kinit admin

関連情報

19.4. IdM に登録されていないシステムでのレプリカのインストールの認可

Identity Management (IdM) ドメインに登録されていないシステムでレプリカのインストールを行う場合、ipa-replica-install ユーティリティーはまずシステムをクライアントとして登録してから、レプリカコンポーネントをインストールします。このシナリオでは、以下の 方法 1 または 方法 2 を選択して、レプリカのインストールを認証します。以下のいずれかが当てはまる場合は、方法 1 を選択します。

  • 上級システム管理者に手順の初期部分を実行させ、下級システム管理者にその他の作業を実行させたい場合。
  • レプリカのインストールを自動化する。
方法 1 - IdM サーバーで生成されたランダムなパスワード

ドメイン内の任意のサーバーで、次のコマンドを入力します。

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

    $ kinit admin
  2. 外部システムを IdM ホストとして追加します。ipa host-add コマンドに --random オプションを使用して、後続のレプリカのインストールに使用される無作為なワンタイムパスワードを生成します。

    $ ipa host-add replica.example.com --random
    --------------------------------------------------
    Added host "replica.example.com"
    --------------------------------------------------
      Host name: replica.example.com
      Random password: W5YpARl=7M.n
      Password: True
      Keytab: False
      Managed by: server.example.com

    生成されたパスワードは、IdM ドメインへのマシン登録に使用した後は無効になります。登録の完了後、このパスワードは適切なホストキータブに置き換えられます。

  3. システムを ipaservers ホストグループに追加します。

    $ ipa hostgroup-add-member ipaservers --hosts replica.example.com
      Host-group: ipaservers
      Description: IPA server hosts
      Member hosts: server.example.com, replica.example.com
    -------------------------
    Number of members added 1
    -------------------------
注記

ipaservers グループのメンバーシップは、管理者の認証情報と同様に、マシンに昇格した特権を付与します。したがって、次の手順では、生成されたランダムパスワードを提供する経験豊富ではないシステム管理者により、ホストでipa-replica-install ユーティリティーを正常に実行できます。

方法 2 - 特権ユーザーの認証情報

この方法を使用し、特権ユーザーの認証情報を提供してレプリカのインストールを承認してください。デフォルトの特権ユーザーは admin です。

IdM レプリカインストールユーティリティーを実行する前に、アクションは必要ありません。インストール時に、ipa-replica-install コマンドにプリンシパル名およびパスワードのオプション (--principal admin --admin-password パスワード) を直接追加します。

関連情報

第20章 IdM レプリカのインストール

次のセクションでは、Identity Management (IdM) レプリカをインストールする方法を説明します。レプリカのインストールプロセスでは、既存のサーバーの設定をコピーし、その設定を基にしてレプリカをインストールします。

前提条件

注記

一度に IdM レプリカをインストールします。同時に複数のレプリカをインストールすることはサポートされません。

手順

各タイプのレプリカのインストール手順は、以下を参照してください。

レプリカのインストール手順をトラブルシューティングするには、以下を参照してください。

インストール後は、以下を参照してください。

20.1. 統合 DNS および CA を使用した IdM レプリカのインストール

この手順では、Identity Management (IdM) レプリカのインストールを説明します。

  • 統合 DNS あるサーバー
  • 認証局 (CA) あり

これは、たとえば、統合 CA で IdM サーバーをインストールした後に、耐障害性のために CA サービスを複製します。

重要

CA のあるレプリカを設定する場合は、レプリカの CA 設定がサーバーの CA 設定を反映する必要があります。

たとえば、サーバーに統合された IdM CA がルート CA として含まれている場合は、新しいレプリカも統合 CA をルート CA としてインストールする必要があります。この場合、他の CA 設定は使用できません。

ipa-replica-install コマンドに --setup-ca オプションを含めると、初期サーバーの CA 設定がコピーされます。

前提条件

手順

  1. 以下のオプションを使用して、ipa-replica-install を実行します。

    • レプリカを DNS サーバーとして設定する--setup-dns
    • --forwarder - サーバーごとのフォワーダーを指定します。サーバーごとのフォワーダーを使用しない場合は --no-forwarder を指定します。フェイルオーバーのためにサーバーごとのフォワーダーを複数指定するには、--forwarder を複数回使用します。

      注記

      ipa-replica-install ユーティリティーは、--no-reverse--no-host-dns などの DNS 設定に関する複数のオプションを受け入れます。詳細は、man ページの ipa-replica-install(1) を参照してください。

    • レプリカに CA を含める--setup-ca

    たとえば、IdM サーバーが管理していないすべての DNS 要求を、IP アドレス 192.0.2.1 で実行している DNS サーバーに転送する統合 DNS サーバーおよび CA にレプリカをセットアップするには、次のコマンドを実行します。

    # ipa-replica-install --setup-dns --forwarder 192.0.2.1 --setup-ca
  2. インストールスクリプトが完了したら、親ドメインから IdM DNS ドメインに DNS 委譲を追加します。たとえば、IdM DNS ドメインが ipa.example.com の場合は、ネームサーバー (NS) レコードを親ドメイン example.com に追加します。

    重要

    IdM DNS サーバーをインストールするたびに、この手順を繰り返します。

20.2. 統合 DNS を使用し CA を省略した IdM レプリカのインストール

この手順では、Identity Management (IdM) レプリカのインストールを説明します。

  • 統合 DNS あるサーバー
  • 認証局 (CA) が既にインストールされている IdM 環境に CA がない場合。レプリカは、すべての証明書操作を、CA がインストールされている IdM サーバーに転送します。

前提条件

手順

  1. 以下のオプションを使用して、ipa-replica-install を実行します。

    • レプリカを DNS サーバーとして設定する--setup-dns
    • --forwarder - サーバーごとのフォワーダーを指定します。サーバーごとのフォワーダーを使用しない場合は --no-forwarder を指定します。フェイルオーバーのためにサーバーごとのフォワーダーを複数指定するには、--forwarder を複数回使用します。

    たとえば、IdM サーバーが管理していないすべての DNS 要求を、IP アドレス 192.0.2.1 で実行している DNS サーバーに転送する統合 DNS サーバーにレプリカをセットアップするには、次のコマンドを実行します。

    # ipa-replica-install --setup-dns --forwarder 192.0.2.1
    注記

    ipa-replica-install ユーティリティーは、--no-reverse--no-host-dns などの DNS 設定に関する複数のオプションを受け入れます。詳細は、man ページの ipa-replica-install(1) を参照してください。

  2. インストールスクリプトが完了したら、親ドメインから IdM DNS ドメインに DNS 委譲を追加します。たとえば、IdM DNS ドメインが ipa.example.com の場合は、ネームサーバー (NS) レコードを親ドメイン example.com に追加します。

    重要

    IdM DNS サーバーをインストールするたびに、この手順を繰り返します。

20.3. 統合 DNS を省略し CA を使用した IdM レプリカのインストール

この手順では、Identity Management (IdM) レプリカのインストールを説明します。

  • 統合 DNS のないサーバー
  • 認証局 (CA) あり
重要

CA のあるレプリカを設定する場合は、レプリカの CA 設定がサーバーの CA 設定を反映する必要があります。

たとえば、サーバーに統合された IdM CA がルート CA として含まれている場合は、新しいレプリカも統合 CA をルート CA としてインストールする必要があります。この場合、他の CA 設定は使用できません。

ipa-replica-install コマンドに --setup-ca オプションを含めると、初期サーバーの CA 設定がコピーされます。

前提条件

手順

  1. --setup-ca オプションを指定して ipa-replica-install を実行します。

    # ipa-replica-install --setup-ca
  2. 新規作成された IdM DNS サービスレコードを DNS サーバーに追加します。

    1. IdM DNS サービスレコードを nsupdate 形式のファイルにエクスポートします。

      $ ipa dns-update-system-records --dry-run --out dns_records_file.nsupdate
    2. nsupdate ユーティリティーおよび dns_records_file.nsupdate ファイルを使用して DNS サーバーに DNS 更新リクエストを送信します。詳細は、RHEL 7 ドキュメントの「nsupdate を使用した外部 DNS レコード更新」を参照してください。または、DNS レコードの追加については、お使いの DNS サーバーのドキュメントを参照してください。

20.4. 統合 DNS および CA を使用しない IdM レプリカのインストール

この手順では、Identity Management (IdM) レプリカのインストールを説明します。

  • 統合 DNS のないサーバー
  • 必要な証明書を手動で用意し、認証局 (CA) なし。最初のサーバーが CA なしでインストールされていることを前提とします。
重要

インポートした証明書ファイルには、LDAP サーバーおよび Apache サーバーの証明書を発行した CA の完全な証明書チェーンが含まれている必要があるため、自己署名のサードパーティーサーバー証明書を使用してサーバーまたはレプリカをインストールすることはできません。

前提条件

手順

  • ipa-replica-install を実行して、次のオプションを追加して必要な証明書ファイルを指定します。

    • --dirsrv-cert-file
    • --dirsrv-pin
    • --http-cert-file
    • --http-pin

    このようなオプションを使用して提供されるファイルに関する詳細は、「CA なしで IdM サーバーをインストールするために必要な証明書」 を参照してください。

    以下に例を示します。

    # ipa-replica-install \
        --dirsrv-cert-file /tmp/server.crt \
        --dirsrv-cert-file /tmp/server.key \
        --dirsrv-pin secret \
        --http-cert-file /tmp/server.crt \
        --http-cert-file /tmp/server.key \
        --http-pin secret
    注記

    --ca-cert-file オプションを追加しないでください。ipa-replica-install ユーティリティーは、インストールした最初のサーバーから証明書のこの部分を自動的に取得します。

20.5. IdM 非表示レプリカのインストール

非表示の (予期しない) レプリカは、実行中で利用可能なサービスをすべて備えた Identity Management (IdM) サーバーです。ただし、DNS に SRV レコードがなく、LDAP サーバーロールが有効になっていません。そのため、クライアントはサービス検出を使用して非表示のレプリカを検出することができません。

非表示のレプリカの詳細は、The hidden replica modeを参照してください。

前提条件

手順

  • 非表示のレプリカをインストールするには、次のコマンドを実行します。

    ipa-replica-install --hidden-replica

このコマンドは、DNS SRV レコードがなく、LDAP サーバーのロールが無効になっているレプリカをインストールすることに注意してください。

また、既存のレプリカモードを非表示にすることもできます。詳細は「非表示レプリカの降格または昇格」を参照してください。

20.6. IdM レプリカのテスト

レプリカの作成後、レプリカが想定どおりにデータを複製するかどうかを確認します。以下の手順を使用できます。

手順

  1. 新しいレプリカでユーザーを作成します。

    [admin@new_replica ~]$ ipa user-add test_user
  2. ユーザーが他のレプリカでも表示されるようにします。

    [admin@another_replica ~]$ ipa user-show test_user

20.7. IdM レプリカのインストール時に実行する接続

IdM レプリカのインストール時に実行する要求には、Identity Management (IdM) のレプリカインストールツールである ipa-replica-install により実行される操作の一覧が記載されています。

表20.1 IdM レプリカのインストール時に実行する要求

操作使用プロトコル目的

クライアントシステムに設定した DNS リゾルバーに対する DNS 解決

DNS

IdM サーバーの IP アドレス検出。

検出された IdM サーバーのポート 88 (TCP/TCP6 および UDP/UDP6) への要求

Kerberos

Kerberos チケットの取得。

検出または設定された IdM サーバー上の IdM Apache ベースの Web サービスへの JSON-RPC 呼び出し

HTTPS

IdM クライアントの登録。必要な場合はレプリカキーの取得および証明書の発行。

SASL GSSAPI 認証、プレーン LDAP、またはこれら両方を使用した、IdM サーバー上のポート 389 (TCP/TCP6) への要求

LDAP

IdM クライアントの登録。CA 証明書チェーンの取得。LDAP データの複製。

IdM サーバー上のポート 22 (TCP/TCP6) への要求

SSH

接続が機能していることを確認。

(任意) IdM サーバーのポート 8443 (TCP/TCP6) でのアクセス

HTTPS

IdM サーバー上での認証局の管理 (IdM サーバーおよびレプリカのインストール時のみ)

第21章 IdM レプリカのインストールに関するトラブルシューティング

以下のセクションでは、失敗した IdM レプリカのインストールに関する情報を収集するプロセスと、一般的なインストールの問題を解決する方法を説明します。

21.1. IdM レプリカのインストールエラーの確認

Identity Management (IdM) レプリカをインストールすると、レプリカの以下のログファイルにデバッグ情報が追加されます。

  • /var/log/ipareplica-install.log
  • /var/log/ipareplica-conncheck.log
  • /var/log/ipaclient-install.log
  • /var/log/httpd/error_log
  • /var/log/dirsrv/slapd-INSTANCE-NAME/access
  • /var/log/dirsrv/slapd-INSTANCE-NAME/errors
  • /var/log/ipaserver-install.log

レプリカのインストールプロセスでは、レプリカが接続している IdM サーバー の次のログファイルにデバッグ情報を追加します。

  • /var/log/httpd/error_log
  • /var/log/dirsrv/slapd-INSTANCE-NAME/access
  • /var/log/dirsrv/slapd-INSTANCE-NAME/errors

各ログファイルの最後の行は成功または失敗を報告し、ERROR および DEBUG エントリーが追加のコンテキストを提供します。

失敗した IdM レプリカインストールをトラブルシューティングするには、両方のホスト (レプリカおよびサーバー) のこれらのログファイルの末尾でエラーを確認し、この情報を使用して、対応する問題を解決します。

前提条件

  • IdM ログファイルの内容を表示するには、root 権限が必要です。

手順

  1. tail コマンドを使用して、プライマリーログファイル /var/log/ipareplica-install.log からの最新のエラーを表示します。以下の例は、最後の 10 行を表示しています。

    [user@replica ~]$ sudo tail -n 10 /var/log/ipareplica-install.log
    [sudo] password for user:
      func(installer)
    File "/usr/lib/python3.6/site-packages/ipaserver/install/server/replicainstall.py", line 424, in decorated
      func(installer)
    File "/usr/lib/python3.6/site-packages/ipaserver/install/server/replicainstall.py", line 785, in promote_check
      ensure_enrolled(installer)
    File "/usr/lib/python3.6/site-packages/ipaserver/install/server/replicainstall.py", line 740, in ensure_enrolled
      raise ScriptError("Configuration of client side components failed!")
    
    2020-05-28T18:24:51Z DEBUG The ipa-replica-install command failed, exception: ScriptError: Configuration of client side components failed!
    2020-05-28T18:24:51Z ERROR Configuration of client side components failed!
    2020-05-28T18:24:51Z ERROR The ipa-replica-install command failed. See /var/log/ipareplica-install.log for more information
  2. ログファイルを対話的に確認するには、less ユーティリティーを使用してログファイルの末尾を開き、 および キーを使用して移動します。

    [user@replica ~]$ sudo less -N +G /var/log/ipareplica-install.log
  3. (オプション) /var/log/ipareplica-install.log は、レプリカのインストールの主なログファイルです。レプリカおよびサーバーの追加のファイルを使用して、このレビュープロセスを繰り返して、追加のトラブルシューティング情報を収集できます。

    レプリカで以下を行います。

    [user@replica ~]$ sudo less -N +G /var/log/ipareplica-conncheck.log
    [user@replica ~]$ sudo less -N +G /var/log/ipaclient-install.log
    [user@replica ~]$ sudo less -N +G /var/log/httpd/error_log
    [user@replica ~]$ sudo less -N +G /var/log/dirsrv/slapd-INSTANCE-NAME/access
    [user@replica ~]$ sudo less -N +G /var/log/dirsrv/slapd-INSTANCE-NAME/errors
    [user@replica ~]$ sudo less -N +G /var/log/ipaserver-install.log

    サーバー上では以下の設定になります。

    [user@server ~]$ sudo less -N +G /var/log/httpd/error_log
    [user@server ~]$ sudo less -N +G /var/log/dirsrv/slapd-INSTANCE-NAME/access
    [user@server ~]$ sudo less -N +G /var/log/dirsrv/slapd-INSTANCE-NAME/errors

関連情報

  • 失敗した IdM レプリカのインストールを解決できず、Red Hat テクニカルサポートサブスクリプションがある場合は、Red Hat カスタマーポータル でテクニカルサポートケースを作成し、レプリカの sosreport サーバーとレプリカの sosreport を提供します。
  • sosreport ユーティリティーは、設定の詳細、ログ、およびシステム情報を RHEL システムから収集します。sosreport ユーティリティーの詳細は、「Red Hat Enterprise Linux 上での sosreport の役割と取得方法」を参照してください。

21.2. IdM CA インストールエラーの確認

Identity Management (IdM) レプリカに認証局 (CA) サービスをインストールすると、レプリカの複数の場所にデバッグ情報と、レプリカが通信する IdM サーバーが追加されます。

表21.1 レプリカで (推奨される優先順位)。

場所説明

/var/log/pki/pki-ca-spawn.$TIME_OF_INSTALLATION.log

高レベルの問題と、pkispawn インストールプロセスの Python トレース

journalctl -u pki-tomcatd@pki-tomcat output

pki-tomcatd@pki-tomcat サービスからのエラー

/var/log/pki/pki-tomcat/ca/debug.$DATE.log

公開鍵インフラストラクチャー (PKI) 製品のアクティビティーの大規模な JAVA スタックトレース

/var/log/pki/pki-tomcat/ca/signedAudit/ca_audit

PKI 製品の監査ログ

  • /var/log/pki/pki-tomcat/ca/system
  • /var/log/pki/pki-tomcat/ca/transactions
  • /var/log/pki/pki-tomcat/catalina.$DATE.log

証明書を使用するサービスプリンシパル、ホスト、およびその他のエンティティーの証明書操作の低レベルのデバッグデータ

レプリカが接続するサーバーで、以下を行います。

  • /var/log/httpd/error_log ログファイル

既存の IdM レプリカに CA サービスをインストールすると、以下のログファイルにデバッグ情報が書き込まれます。

  • /var/log/ipareplica-ca-install.log ログファイル
注記

オプションの CA コンポーネントのインストール中に IdM レプリカ全体のインストールが失敗すると、CA の詳細がログに記録されません。メッセージは /var/log/ipareplica-install.log ファイルに記録され、インストールプロセスが全体的な失敗を示すようになります。Red Hat は、CA インストールの失敗に固有のログファイルを確認することを推奨します。

この動作の唯一の例外は、CA サービスをインストールし、ルート CA が外部 CA の場合です。外部 CA の証明書に問題がある場合は、エラーは /var/log/ipareplica-install.log に記録されます。

失敗した IdM CA インストールをトラブルシューティングするには、これらのログファイルの末尾でエラーを確認し、この情報を使用して、対応する問題を解決します。

前提条件

  • IdM ログファイルの内容を表示するには、root 権限が必要です。

手順

  1. ログファイルを対話的に確認するには、less ユーティリティーを使用してログファイルの末尾を開き、 および キーを使用して移動し、ScriptError を検索します。以下の例では、/var/log/pki/pki-ca-spawn.$TIME_OF_INSTALLATION.log を開きます。

    [user@server ~]$ sudo less -N +G /var/log/pki/pki-ca-spawn.20200527185902.log
  2. 上記のすべてのログファイルを使用してこの確認プロセスを繰り返して、追加のトラブルシューティング情報を収集します。

関連情報

  • 失敗したインストールを解決できず、Red Hat テクニカルサポートサブスクリプションがある場合は、Red Hat カスタマーポータル でテクニカルサポートケースを作成し、レプリカの sosreport とサーバーの sosreport を提供します。
  • sosreport ユーティリティーは、設定の詳細、ログ、およびシステム情報を RHEL システムから収集します。sosreport ユーティリティーの詳細は、「Red Hat Enterprise Linux 上での sosreport の役割と取得方法」を参照してください。

21.3. 部分的な IdM レプリカインストールの削除

IdM レプリカのインストールに失敗した場合は、設定ファイルの一部が残される可能性があります。IdM レプリカのインストールを試みる追加の試行に失敗し、インストールスクリプトで IPA がすでに設定されていると報告されます。

[root@server ~]# ipa-replica-install
Your system may be partly configured.
Run /usr/sbin/ipa-server-install --uninstall to clean up.

IPA server is already configured on this system.
If you want to reinstall the IPA server, please uninstall it first using 'ipa-server-install --uninstall'.
The ipa-replica-install command failed. See /var/log/ipareplica-install.log for more information

この問題を解決するには、レプリカから IdM ソフトウェアをアンインストールし、IdM トポロジーからレプリカを削除し、インストールプロセスを再試行します。

前提条件

  • root 権限があること。

手順

  1. IdM レプリカとして設定するホストで IdM サーバーソフトウェアをアンインストールします。

    [root@replica ~]# ipa-server-install --uninstall
  2. トポロジー内の他のすべてのサーバーで ipa server-del コマンドを使用して、適切にインストールしていないレプリカへの参照を削除します。

    [root@other-replica ~]# ipa server-del replica.idm.example.com
  3. レプリカのインストールを試行します。
  4. インストールを繰り返し失敗するため、IdM レプリカのインストールを続ける場合は、オペレーティングシステムを再インストールします。

    IdM レプリカのインストール要件の 1 つは、カスタマイズなしでクリーンなシステムです。インストールに失敗した場合は、予期せずにシステムファイルを変更することで、ホストの整合性が侵害される可能性があります。

関連情報

21.4. 無効な認証情報エラーの解決

IdM レプリカのインストールが Invalid credentials エラーで失敗すると、ホスト上のシステムクロックが相互に同期しなくなる可能性があります。

[27/40]: setting up initial replication
Starting replication, please wait until this has completed.
Update in progress, 15 seconds elapsed
[ldap://server.example.com:389] reports: Update failed! Status: [49 - LDAP error: Invalid credentials]

[error] RuntimeError: Failed to start replication
Your system may be partly configured.
Run /usr/sbin/ipa-server-install --uninstall to clean up.

ipa.ipapython.install.cli.install_tool(CompatServerReplicaInstall): ERROR    Failed to start replication
ipa.ipapython.install.cli.install_tool(CompatServerReplicaInstall): ERROR    The ipa-replica-install command failed. See /var/log/ipareplica-install.log for more information

--no-ntp または -N オプションを使用して、クロックが同期されていない間にレプリカのインストールを試みると、サービスは Kerberos で認証できないため、インストールに失敗します。

この問題を解決するには、両方のホストのクロックを同期し、インストールプロセスを再試行します。

前提条件

  • システム時間を変更するには、root 権限が必要です。

手順

  1. システムクロックは、手動または chronyd により同期します。

    • 手動同期:

      サーバー上のシステム時間を表示し、この時間と一致するようにレプリカの時間設定します。

      [user@server ~]$ date
      Thu May 28 21:03:57 EDT 2020
      
      [user@replica ~]$ sudo timedatectl set-time '2020-05-28 21:04:00'
    • chronyd と同期します。

      chrony ツールでシステム時間を設定および設定するには、「Chrony スイートを使用した NTP の設定」を参照してください。

  2. IdM レプリカのインストールを再試行します。

関連情報

  • 失敗した IdM レプリカのインストールを解決できず、Red Hat テクニカルサポートサブスクリプションがある場合は、Red Hat カスタマーポータル でテクニカルサポートケースを作成し、レプリカの sosreport サーバーとレプリカの sosreport を提供します。
  • sosreport ユーティリティーは、設定の詳細、ログ、およびシステム情報を RHEL システムから収集します。sosreport ユーティリティーの詳細は、「Red Hat Enterprise Linux 上での sosreport の役割と取得方法」を参照してください。

21.5. 関連情報

第22章 IdM レプリカのアンインストール

IdM管理者は、トポロジーから Identity Management (IdM) レプリカを削除できます。詳細は「IdM サーバーのアンインストール」を参照してください。

第23章 既存の IdM サーバーへの DNS のインストール

本セクションでは、最初にDNS サービスをインストールしなかった Identity Management (IdM)サーバーに DNS サービスをインストールする方法を説明します。

前提条件

手順

  1. (必要に応じて)DNS が IdM サーバーにまだインストールされていないことを確認します。

    [root@r8server ~]# ipa server-role-show r8server.idm.example.com
    Role name: DNS server
      Server name: r8server.idm.example.com
      Role name: DNS server
      Role status: absent

    この出力で、IdM DNS がサーバーで利用できないことが確認できます。

  2. idm:DL1 ストリームを有効にします。

    [root@r8server ~]# yum module enable idm:DL1
  3. ipa-dns-server パッケージとその依存関係をダウンロードします。

    [root@r8server ~]# yum module install idm:DL1/dns
  4. スクリプトを起動して、サーバーに DNS をインストールします。

    [root@r8server ~]# ipa-dns-install
    1. スクリプトにより、サーバーごとのDNS フォワーダー設定のプロンプトが表示されます。

      Do you want to configure DNS forwarders? [yes]:
      • サーバーごとのDNS フォワーダーを設定するには、yes を入力して表示されたコマンドラインの指示に従います。インストールプロセスにより、IdM LDAPにフォワーダーの IP アドレスが追加されます。

        • フォワードポリシーのデフォルト設定は、man ページの ipa-dns-install(1) に記載される --forward-policy の説明を参照してください。
      • DNS 転送を使用しない場合は、no と入力します。

        DNS フォワーダーがないと、IdM ドメインのホストは、インフラストラクチャー内にある他の内部 DNS ドメインから名前を解決できません。ホストは、DNS クエリーを解決するためにパブリック DNS サーバーでのみ残ります。

    2. そのサーバーと関連する IP アドレスの DNS 逆引き (PTR) レコードを設定する必要性を確認するスクリプトプロンプトが出されます。

      Do you want to search for missing reverse zones? [yes]:

      検索を実行して欠落している逆引きゾーンが見つかると、PTR レコードの逆引きゾーンを作成するかどうかが尋ねられます。

      Do you want to create reverse zone for IP 192.0.2.1 [yes]:
      Please specify the reverse zone name [2.0.192.in-addr.arpa.]:
      Using reverse zone(s) 2.0.192.in-addr.arpa.
      注記

      任意で、逆引きゾーンの管理に IdM を使用できます。代わりに、この目的で外部 DNS サービスを使用することもできます。

関連情報

  • man ipa-dns-install(1)

第24章 レプリケーショントポロジーの管理

本章では、Identity Management(IdM)ドメイン内のサーバー間のレプリケーションを管理する方法を説明します。

24.1. レプリカ合意、トポロジーサフィックス、およびトポロジーセグメントの説明

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

レプリカ合意

管理者が、既存のサーバーに基づいてレプリカを作成すると、Identity Management (IdM) は、初期サーバーとレプリカとの間に レプリカ合意 を作成します。レプリカ合意は、データと設定が 2 台のサーバー間で継続的に複製されることを保証します。

IdM は、複数の読み取り/書き込みレプリカ複製 を使用します。この設定では、レプリカ合意に参加しているすべてのレプリカが更新の受信と提供を行うので、サプライヤーとコンシューマーとみなされます。レプリカ合意は常に双方向です。

図24.1 サーバーとレプリカ合意

サーバー 2 台の間に 2 つのレプリカ合意があるイメージ: Directory Server データベースに関連するデータのレプリカ合意と、証明書システムデータに関連する証明書レプリカ合意

IdM は、2 種類のレプリカ合意を使用します。

ドメインのレプリカ合意
この合意は、識別情報を複製します。
証明書のレプリカ合意
この合意は、証明書情報を複製します。

両方の複製チャンネルは独立しています。2 台のサーバー間で、いずれかまたは両方の種類のレプリカ合意を設定できます。たとえば、サーバー A とサーバー B にドメインレプリカ合意のみが構成されている場合は、証明書情報ではなく ID 情報だけが複製されます。

トポロジーサフィックス

トポロジーサフィックスは、レプリケートされるデータを保存します。IdM は、domainca の 2 種類のトポロジーサフィックスに対応します。それぞれのサフィックスは、個別のサーバーである個別のレプリケーショントポロジーを表します。

レプリカ合意が設定されると、同じタイプのトポロジーサフィックスを 2 つの異なるサーバーに結合します。

domain サフィックス: dc=example,dc=com

domain 接尾辞には、ドメイン関連のデータがすべて含まれています。

2 つのレプリカの domain サフィックス間でレプリカ合意が設定されると、ユーザー、グループ、およびポリシーなどのディレクトリーデータが共有されます。

ca 接尾辞: o=ipaca

ca 接尾辞には、Certificate System コンポーネントのデータが含まれます。これは認証局 (CA) がインストールされているサーバーにのみ存在します。

2 つのレプリカの ca サフィックス間でレプリカ合意が設定されると、証明書データが共有されます。

図24.2 トポロジーサフィックス

トポロジーサフィックス

新規レプリカのインストール時には、ipa-replica-install スクリプトが 2 つのサーバー間に初期トポロジーレプリカ合意をセットアップします。

例24.1 トポロジーサフィックスの表示

ipa topologysuffix-find コマンドでトポロジーサフィックスの一覧が表示されます。

$ ipa topologysuffix-find
---------------------------
2 topology suffixes matched
---------------------------
  Suffix name: ca
  Managed LDAP suffix DN: o=ipaca

  Suffix name: domain
  Managed LDAP suffix DN: dc=example,dc=com
----------------------------
Number of entries returned 2
----------------------------

トポロジーセグメント

2 つのレプリカのサフィックス間でレプリカ合意があると、サフィックスは トポロジーセグメント を形成します。各トポロジーセグメントは、左ノード右ノード で構成されます。ノードは、レプリカ合意に参加しているサーバーを表します。

IdM のトポロジーセグメントは常に双方向です。各セグメントは、サーバー A からサーバー B、およびサーバー B からサーバー A への 2 つのレプリカ合意を表します。そのため、データは両方の方向でレプリケートされます。

図24.3 トポロジーセグメント

トポロジーセグメント

例24.2 トポロジーセグメントの表示

ipa topologysegment-find コマンドで、ドメインまたは CA サフィックスに設定されたトポロジーセグメントが表示されます。たとえば、ドメイン接尾辞の場合は、以下のようになります。

$ ipa topologysegment-find
Suffix name: domain
-----------------
1 segment matched
-----------------
  Segment name: server1.example.com-to-server2.example.com
  Left node: server1.example.com
  Right node: server2.example.com
  Connectivity: both
----------------------------
Number of entries returned 1
----------------------------

この例では、ドメイン関連のデータのみが server1.example.comserver2.example.com の 2 つのサーバー間で複製されます。

特定セグメントの詳細を表示するには、ipa topologysegment-show コマンドを使用します。

$ ipa topologysegment-show
Suffix name: domain
Segment name: server1.example.com-to-server2.example.com
  Segment name: server1.example.com-to-server2.example.com
  Left node: server1.example.com
  Right node: server2.example.com
  Connectivity: both

24.2. トポロジーグラフを使用したレプリケーショントポロジーの管理

Web UI のトポロジーグラフは、ドメイン内のサーバー間の関係を表示します。Web UI を使用すると、トポロジーの表現を操作および変換できます。

トポロジーグラフへのアクセス

トポロジーグラフにアクセスするには、以下を実行します。

  1. IPA ServerTopologyTopology Graph を選択します。
  2. トポロジーに加えた変更がグラフに反映されていない場合は、Refresh をクリックします。

トポロジーグラフの解釈

ドメインのレプリカ合意に参加しているサーバーは、オレンジ色の矢印によって接続されます。CAのレプリカ合意に参加しているサーバーは、青色の矢印によって接続されます。

トポロジーグラフの例: 推奨されるトポロジー

fig.mng-top-rec は、4 つのサーバーで推奨されるトポロジーの例を 1 つ示しています。各サーバーは少なくとも 2 台のサーバーに接続されており、複数のサーバーが CA マスターになります。

図24.4 推奨されるトポロジーの例

mng top rec
トポロジーグラフの例:推奨されないトポロジー

fig.mng-top-singleserver1 は単一障害点になります。その他のすべてのサーバーは、このサーバーとのレプリカ合意がありますが、他のサーバーとは合意がありません。したがって、server1 が失敗すると、他のすべてのサーバーは分離されます。

このようなトポロジーの作成は避けてください。

図24.5 推奨されないトポロジーの例:単一障害点

mng top single

トポロジービューのカスタマイズ

マウスをドラッグして、個別のトポロジーノードを移動できます。

図24.6 トポロジーグラフのノードの移動

グラフのカスタマイズ 1

マウスのホイールを使用して、トポロジーグラフを拡大および縮小できます。

図24.7 トポロジーグラフのズーム

グラフのカスタマイズ 2

マウスの左ボタンを保持することで、トポロジーグラフのキャンバスを移動できます。

図24.8 トポロジーグラフのキャンバスの移動

グラフのカスタマイズ 3

24.3. Web UI を使用した 2 台のサーバー間のレプリケーションの設定

Identity Management (IdM)の Web インターフェースを使用すると、2 つのサーバーを選択し、そのサーバー間に新しいレプリカ合意を作成できます。

前提条件

  • IdM 管理者認証情報がある。

手順

  1. トポロジーグラフで、サーバーノードの 1 つにマウスを合わせます。

    図24.9 ドメインまたは CA オプション

    mng top domain ca
  2. 作成するトポロジーセグメントのタイプに応じて、domainまたは円のca部分をクリックします。
  3. 新しいレプリカ合意を表す新しい矢印が、マウスポインターの下に表示されます。マウスを他のサーバーノードに移動し、そこでクリックします。

    図24.10 新規セグメントの作成

    mng top drag
  4. Add Topology Segment ウィンドウで Add をクリックして、新規セグメントのプロパティーを確認します。

2 台のサーバー間の新しいトポロジーセグメントは、サーバーをレプリカ合意に参加させます。トポロジーグラフには、更新されたレプリケーショントポロジーが表示されるようになりました。

図24.11 新規に作成されたセグメント

mng top three

24.4. Web UI を使用した 2 台のサーバー間のレプリケーションの停止

Identity Management (IdM)の Web インターフェースを使用して、サーバーからレプリカ合意を削除できます。

前提条件

  • IdM 管理者認証情報がある。

手順

  1. 削除するレプリカ合意を表す矢印をクリックします。これにより、矢印がハイライト表示されます。

    図24.12 トポロジーセグメントのハイライト表示

    mng top highlight
  2. Delete をクリックします。
  3. Confirmation ウィンドウで OK をクリックします。

IdM は、2 台のサーバー間のトポロジーセグメントを削除します。これにより、そのレプリカ合意が削除されます。トポロジーグラフには、更新されたレプリケーショントポロジーが表示されるようになりました。

図24.13 トポロジーセグメントの削除

mng top delete segment

24.5. CLI を使用した 2 つのサーバー間のレプリケーションの設定

ipa topologysegment-add コマンドを使用して、2 台のサーバー間のレプリカ合意を設定できます。

前提条件

  • IdM 管理者認証情報がある。

手順

  1. ipa topologysegment-add コマンドを使用して、2 つのサーバーのトポロジーセグメントを作成します。プロンプトが表示されたら、以下を指定します。

    • 必要なトポロジーサフィックス: domain または ca
    • 2 つのサーバーを表す、左ノードと右のノード
    • オプションで、セグメントのカスタム名

      以下に例を示します。

      $ ipa topologysegment-add
      Suffix name: domain
      Left node: server1.example.com
      Right node: server2.example.com
      Segment name [server1.example.com-to-server2.example.com]: new_segment
      ---------------------------
      Added segment "new_segment"
      ---------------------------
        Segment name: new_segment
        Left node: server1.example.com
        Right node: server2.example.com
        Connectivity: both

      新しいセグメントを追加すると、サーバーをレプリカ合意に参加させます。

  2. オプション:ipa topologysegment-show コマンドを使用して、新しいセグメントが設定されたことを確認します。

    $ ipa topologysegment-show
    Suffix name: domain
    Segment name: new_segment
      Segment name: new_segment
      Left node: server1.example.com
      Right node: server2.example.com
      Connectivity: both

24.6. CLI を使用した 2 つのサーバー間のレプリケーションの停止

ipa topology_segment-del コマンドを使用して、コマンドラインからレプリカ合意を終了できます。

前提条件

  • IdM 管理者認証情報がある。

手順

  1. レプリケーションを停止するには、サーバー間の対応するレプリケーションセグメントを削除する必要があります。これを実行するには、セグメント名を知っている必要があります。

    名前が分からない場合は、ipa topologysegment-find コマンドを使用してすべてのセグメントを表示し、出力で必要なセグメントを見つけます。プロンプトが表示されたら、必要なトポロジーサフィックス(domain または ca)を指定します。以下に例を示します。

    $ ipa topologysegment-find
    Suffix name: domain
    ------------------
    8 segments matched
    ------------------
      Segment name: new_segment
      Left node: server1.example.com
      Right node: server2.example.com
      Connectivity: both
    
    ...
    
    ----------------------------
    Number of entries returned 8
    ----------------------------
  2. ipa topologysegment-del コマンドを使用して、2 台のサーバー間のトポロジーセグメントを削除します。

    $ ipa topologysegment-del
    Suffix name: domain
    Segment name: new_segment
    -----------------------------
    Deleted segment "new_segment"
    -----------------------------

    セグメントを削除すると、レプリカ合意が削除されます。

  3. オプション:ipa topologysegment-find コマンドを使用して、セグメントが表示されなくなったことを確認します。

    $ ipa topologysegment-find
    Suffix name: domain
    ------------------
    7 segments matched
    ------------------
      Segment name: server2.example.com-to-server3.example.com
      Left node: server2.example.com
      Right node: server3.example.com
      Connectivity: both
    
    ...
    
    ----------------------------
    Number of entries returned 7
    ----------------------------

24.7. Web UI を使用したトポロジーからのサーバーの削除

Identity Management (IdM)の Web インターフェースを使用して、トポロジーからサーバーを削除できます。

前提条件

  • IdM 管理者認証情報がある。
  • 削除するサーバーが、残りのトポロジーで他のサーバーに接続する唯一のサーバーではない。唯一のサーバーであれば他のサーバーが分離され、その状況は許可されません。
  • 削除するサーバーが、最後の CA または DNS サーバー ではない
警告

サーバーの削除は元に戻せないアクションです。サーバーを削除すると、トポロジーに戻す唯一の方法は、マシンに新しいレプリカをインストールすることです。

手順

サーバーコンポーネントをマシンからアンインストールせずにトポロジーからサーバーを削除するには、以下を実行します。

  1. IPA ServerTopologyIPA Servers を選択します。
  2. 削除するサーバーの名前をクリックします。

    図24.14 サーバーの選択

    mng top delete
  3. Delete Server をクリックします。

24.8. CLI を使用したトポロジーからのサーバーの削除

コマンドラインインターフェースを使用して、トポロジーからサーバーを削除できます。

前提条件

  • IdM 管理者認証情報がある。
  • 削除するサーバーが、残りのトポロジーで他のサーバーに接続する唯一のサーバーではない。唯一のサーバーであれば他のサーバーが分離され、その状況は許可されません。
  • 削除するサーバーが、最後の CA または DNS サーバー ではない
重要

サーバーの削除は元に戻せないアクションです。サーバーを削除すると、トポロジーに戻す唯一の方法は、マシンに新しいレプリカをインストールすることです。

手順

server1.example.com を削除するには、次のコマンドを実行します。

  1. 別のサーバーで ipa server-del コマンドを実行して、server1.example.com を削除します。このコマンドは、サーバーを参照するすべてのトポロジーセグメントを削除します。

    [user@server2 ~]$ ipa server-del
    Server name: server1.example.com
    Removing server1.example.com from replication topology, please wait...
    ----------------------------------------------------------
    Deleted IPA server "server1.example.com"
    ----------------------------------------------------------
  2. オプション: server1.example.com で、ipa server-install --uninstall コマンドを実行して、マシンからサーバーコンポーネントをアンインストールします。

    [root@server1 ~]# ipa server-install --uninstall

24.9. Web UI を使用した IdM サーバーでのサーバーロールの表示

IdM サーバーにインストールされるサービスに基づいて、さまざまな サーバーロール を実行できます。以下に例を示します。

  • CA サーバー
  • DNS サーバー
  • キーリカバリー認証局(KRA)サーバー

サポートされるサーバーロールの完全なリストは、IPA ServerTopologyServer Rolesを参照してください。

注記
  • Role status が absent の場合は、トポロジー内でそのロールを実行しているサーバーがないことを示しています。
  • Role status が enabled の場合は、トポロジー内でそのロールを実行しているサーバーが 1 台以上あることを示しています。

図24.15 Web UI でのサーバーロール

server role absent

24.10. CLI を使用した IdM サーバーでのサーバーロールの表示

IdM サーバーにインストールされるサービスに基づいて、さまざまな サーバーロール を実行できます。以下に例を示します。

  • CA サーバー
  • DNS サーバー
  • キーリカバリー認証局(KRA)サーバー

以下のコマンドを使用して、トポロジー内でどのサーバーがどのロールを実行するかを表示できます。

  • ipa config-show コマンドを実行すると、すべての CA サーバーおよび現行の CA 更新サーバーが表示されます。
$ ipa config-show
  ...
  IPA masters: server1.example.com, server2.example.com, server3.example.com
  IPA CA servers: server1.example.com, server2.example.com
  IPA CA renewal master: server1.example.com
  • ipa server-show コマンドは、特定のサーバーで有効なロールの一覧を表示します。たとえば、server.example.com で有効にしたロールの一覧は、以下のようになります。
$ ipa server-show
Server name: server.example.com
  ...
  Enabled server roles: CA server, DNS server, KRA server
  • ipa server-find --servrole は、特定のサーバーロールが有効になっているすべてのサーバーを検索します。たとえば、すべての CA サーバーを検索するには、以下を実行します。
$ ipa server-find --servrole "CA server"
---------------------
2 IPA servers matched
---------------------
  Server name: server1.example.com
  ...

  Server name: server2.example.com
  ...
----------------------------
Number of entries returned 2
----------------------------

24.11. レプリカの CA 更新サーバーおよび CRL パブリッシャーサーバーへのプロモート

IdM デプロイメントで組み込み認証局(CA)を使用する場合は、IdM CA サーバーの 1 つがCA サブシステム証明書の更新を管理する CA 更新サーバーとして機能します。IdM CA サーバーの 1 つは、証明書失効リストを生成する IdM CRL パブリッシャーサーバーとしても機能します。デフォルトでは、CA 更新サーバーおよび CRL パブリッシャーサーバーロールは、システム管理者が ipa-server-install または ipa-ca-install コマンドを使用して CA ロールをインストールした最初のサーバーにインストールされます。

前提条件

  • IdM 管理者認証情報がある。

24.12. 非表示レプリカの降格または昇格

レプリカのインストール後、レプリカの表示状態を設定できます。

非表示のレプリカの詳細は、The hidden replica modeを参照してください。

レプリカが CA 更新サーバーである場合は、このレプリカを非表示にする前に、サービスを別のレプリカに移動します。

詳細はChanging and resetting IdM CA renewal serverを参照してください。

注記

RHEL 8.1 で導入された非表示のレプリカ機能は、RHEL 8.2 以降で完全にサポートされています。

手順

  • レプリカを非表示にするには、次のコマンドを実行します。

    # ipa server-state replica.idm.example.com --state=hidden

    次のコマンドを実行すれば、レプリカを表示できます

    # ipa server-state replica.idm.example.com --state=enabled

第25章 IdM Healthcheck ツールのインストールおよび実行

本章では、IdM Healthcheck ツールと、そのインストールおよび実行方法を説明します。

前提条件

  • Healthcheck ツールは、RHEL 8.1 以降でのみ利用できます。

25.1. IdM の Healthcheck

IdM (Identity Management) の Healthcheck ツールは、IdM 環境の健全性に影響を与える可能性がある問題を見つけるのに役立ちます。

注記

Healthcheck ツールは、Kerberos 認証なしで使用できるコマンドラインツールです。

モジュールは独立しています

Healthcheck は、以下をテストする独立したモジュールで構成されています。

  • レプリケーションの問題
  • 証明書の有効性
  • 認証局インフラストラクチャーの問題
  • IdM および Active Directory の信頼の問題
  • 正しいファイル許可と所有権設定

2 つの出力形式

ヘルスチェックでは、以下の出力が生成されます。これは、output-type オプションを使用して設定できます。

  • JSON: マシンが判読できる出力 (デフォルト)
  • human: 人間が判読できる出力

--output-file オプションで別の出力先ファイルを指定できます。

結果

Healthcheck の各モジュールは、次のいずれかの結果を返します。

SUCCESS
期待どおりに構成されています。
WARNING
エラーではありませんが、注目または評価すると良いでしょう。
ERROR
期待どおりに構成されていません。
CRITICAL
予想どおりに構成されておらず、影響を受ける可能性が高くなっています。

25.2. IdM Healthcheck のインストール

本セクションでは、IdM Healthcheck ツールのインストール方法を説明します。

手順

  • ipa-healthcheck パッケージをインストールします。

    [root@server ~]# yum install ipa-healthcheck
    注記

    RHEL 8.1 および 8.2 システムでは、代わりに yum install /usr/bin/ipa-healthcheck コマンドを使用します。

検証手順

  • --failures-only オプションを使用して、ipa-healthcheck にエラーのみを報告させます。IdM インストールを完全に使用しても、空の結果 [] が返されます。

    [root@server ~]# ipa-healthcheck --failures-only
    []

関連情報

  • ipa-healthcheck --help を使用して、サポートされるすべての引数を表示します。

25.3. IdM Healthcheck の実行

Healthcheck は、ログローテーション を使用して手動で実行することも、自動で実行できます。

前提条件

手順

  • Healthcheck を手動で実行するには、ipa-healthcheck コマンドを実行します。

    [root@server ~]# ipa-healthcheck

関連情報

すべてのオプションは、man ページの man ipa-healthcheck を参照してください。

25.4. 関連情報

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

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

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

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

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

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

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

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

注記

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

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

概要

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

26.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/ ディレクトリーにインストールされます。

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

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

ansible-playbookユーティリティーの実行 の前に、以下のいずれかの手順を選択して、シナリオに対応するパラメーターを設定します。

26.5.1. 統合 DNS と、root CA としての統合 CA を使用したデプロイメントのパラメーターの設定

以下の手順に従って、IdM 統合 DNS ソリューションを使用する環境で、統合 CA を持つ IdM サーバーを root CA としてインストールするようにインベントリーファイルを設定します。

手順

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

    • 英数字およびハイフン (-) のみが使用できる。たとえば、アンダーラインは使用できないため、DNS の障害が発生する原因となる可能性があります。
    • ホスト名がすべて小文字である。
  2. IdM ドメインおよびレルムの情報を指定します。
  3. 以下のオプションを追加して、統合 DNS を使用することを指定します。

    ipaserver_setup_dns=yes
  4. DNS 転送設定を指定します。以下のいずれかのオプションを選択します。

    • インストーラーが/etc/resolv.conf ファイルからのフォワーダーを使用する場合は、ipaserver_auto_forwarders=yes オプションを使用します。/etc/resolv.conf ファイルで指定する nameserver が localhost 127.0.0.1 アドレスである場合、または仮想プライベートネットワークにあり、使用している DNS サーバーが通常パブリックインターネットから到達できない場合は、このオプションを使用することが推奨されません。
    • ipaserver_forwarders を使用して、フォワーダーを手動で指定します。インストールプロセスにより、インストールした IdM サーバーの /etc/named.conf ファイルに、フォワーダーの IP アドレスが追加されます。
    • 代わりに使用する root DNS サーバーを設定する場合は、ipaserver_no_forwarders=yes オプションを使用します。

      注記
      DNS フォワーダーがないと、ご使用の環境は隔離され、インフラストラクチャー内の他の DNS ドメインからは名前が解決されません。
  5. DNS の逆引きレコードとゾーンの設定を指定します。次のいずれかのオプションを選択します。

    • ゾーンがすでに解決可能であっても、ipaserver_allow_zone_overlap=yes オプションを使用して (リバース) ゾーンの作成を許可します。
    • ipaserver_reverse_zones オプションを使用して、手動でリバースゾーンを指定します。
    • インストーラーが DNS ゾーンを逆引きで作成しない場合は、ipaserver_no_reverse=yes オプションを使用します。

      注記
      任意で、逆引きゾーンの管理に IdM を使用できます。代わりに、この目的で外部 DNS サービスを使用することもできます。
  6. adminDirectory Manager のパスワードを指定します。Ansible Vault を使用してパスワードを保存し、Playbook ファイルから Vault ファイルを参照します。あるいは、安全性は低くなりますが、インベントリーファイルにパスワードを直接指定します。
  7. (必要に応じて) IdM サーバーで使用する個別のfirewalldゾーンを指定します。カスタムゾーンを設定しないと、サービスがデフォルトの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

関連情報

  • フォワードポリシーのデフォルト設定は、man ページの ipa-dns-install(1) に記載される --forward-policy の説明を参照してください。
  • ipaserver ロールが使用する DNS 変数の詳細は、/usr/share/doc/ansible-freeipa ディレクトリーの README-server.md ファイルにある DNS Variables セクションを参照してください。

26.5.2. 外部 DNS と、root CA としての統合 CA を使用したデプロイメントのパラメーターの設定

以下の手順に従って、外部 DNS ソリューションを使用する環境で、統合 CA の IdM サーバーを root CA としてインストールするようにインベントリーファイルを設定します。

手順

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

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

    重要

    指定するfirewalldゾーンは存在し、永続的でなければなりません。

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

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

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

    [ipaserver]
    server.idm.example.com
    
    [ipaserver:vars]
    ipaserver_domain=idm.example.com
    ipaserver_realm=IDM.EXAMPLE.COM
    ipaserver_setup_dns=no
    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=no
    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

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

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

手順

  1. 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
  2. 以下のいずれかのオプションを選択します。

    • IdM デプロイメントで外部 DNS を使用する場合: /tmp/ipa.system.records.UFRPto.db ファイルに含まれる DNS リソースレコードを、既存の外部 DNS サーバーに追加します。DNS レコードの更新プロセスは、特定の DNS ソリューションによって異なります。

      ...
      Restarting the KDC
      Please add records in this file to your DNS system: /tmp/ipa.system.records.UFRBto.db
      Restarting the web server
      ...
    重要

    既存の DNS サーバーに DNS レコードを追加するまで、サーバーのインストールは完了しません。

    • IdM デプロイメントで統合 DNS を使用している場合は、次のコマンドを実行します。

      • 親ドメインから ldM DNS ドメインに DNS 委譲を追加します。たとえば、IdM DNS ドメインが idm.example.com の場合は、ネームサーバー (NS) レコードを親ドメイン example.com に追加します。

        重要

        IdM DNS サーバーをインストールするたびに、この手順を繰り返します。

      • タイムサーバーの _ntp._udp サービス(SRV) レコードを IdM DNS に追加します。IdM DNS に新たにインストールした IdM サーバーのタイムサーバーの SRV レコードが存在すると、今後のレプリカおよびクライアントインストールが、このプライマリー IdM サーバーが使用するタイムサーバーと同期するように自動的に設定されます。

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

ansible-playbookユーティリティーの実行 の前に、以下のいずれかの手順を選択して、シナリオに対応するパラメーターを設定します。

26.6.1. 統合 DNS と、ルート CA としての外部 CA を使用したデプロイメントのパラメーターの設定

以下の手順に従って、IdM 統合 DNS ソリューションを使用する環境で、外部 CA を持つ IdM サーバーを root CA としてインストールするようにインベントリーファイルを設定します。

手順

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

    • 英数字およびハイフン (-) のみが使用できる。たとえば、アンダーラインは使用できないため、DNS の障害が発生する原因となる可能性があります。
    • ホスト名がすべて小文字である。
  2. IdM ドメインおよびレルムの情報を指定します。
  3. 以下のオプションを追加して、統合 DNS を使用することを指定します。

    ipaserver_setup_dns=yes
  4. DNS 転送設定を指定します。以下のいずれかのオプションを選択します。

    • インストールプロセスで /etc/resolv.conf ファイルのフォワーダーを使用する場合は、ipaserver_auto_forwarders=yes を使用します。/etc/resolv.conf ファイルで指定する nameserver が localhost 127.0.0.1 アドレスである場合、または仮想プライベートネットワークにあり、使用している DNS サーバーが通常パブリックインターネットから到達できない場合は、このオプションを使用することが推奨されません。
    • ipaserver_forwarders を使用して、フォワーダーを手動で指定します。インストールプロセスにより、インストールした IdM サーバーの /etc/named.conf ファイルに、フォワーダーの IP アドレスが追加されます。
    • 代わりに使用する root DNS サーバーを設定する場合は、ipaserver_no_forwarders=yes オプションを使用します。

      注記
      DNS フォワーダーがないと、ご使用の環境は隔離され、インフラストラクチャー内の他の DNS ドメインからは名前が解決されません。
  5. DNS の逆引きレコードとゾーンの設定を指定します。次のいずれかのオプションを選択します。

    • ゾーンがすでに解決可能であっても、ipaserver_allow_zone_overlap=yes オプションを使用して (リバース) ゾーンの作成を許可します。
    • ipaserver_reverse_zones オプションを使用して、手動でリバースゾーンを指定します。
    • インストールプロセスで DNS ゾーンの逆引きを作成しない場合は、ipaserver_no_reverse=yes オプションを使用します。

      注記
      任意で、逆引きゾーンの管理に IdM を使用できます。代わりに、この目的で外部 DNS サービスを使用することもできます。
  6. adminDirectory Manager のパスワードを指定します。Ansible Vault を使用してパスワードを保存し、Playbook ファイルから Vault ファイルを参照します。あるいは、安全性は低くなりますが、インベントリーファイルにパスワードを直接指定します。
  7. (必要に応じて) IdM サーバーで使用する個別のfirewalldゾーンを指定します。カスタムゾーンを設定しないと、サービスがデフォルトの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
    
    [...]

  8. インストールの最初ステップ用の 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
  9. インストールの最終ステップ用に、別の 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

関連情報

  • フォワードポリシーのデフォルト設定は、man ページの ipa-dns-install(1) に記載される --forward-policy の説明を参照してください。
  • ipaserver ロールが使用する DNS 変数の詳細は、/usr/share/doc/ansible-freeipa ディレクトリーの README-server.md ファイルにある DNS Variables セクションを参照してください。

26.6.2. 外部 DNS と、ルート CA としての外部 CA を使用したデプロイメントのパラメーターの設定

以下の手順に従って、外部 DNS ソリューションを使用する環境で、外部 CA を持つ IdM サーバーを root CA としてインストールするようにインベントリーファイルを設定します。

手順

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

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

    重要

    指定するfirewalldゾーンは存在し、永続的でなければなりません。

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

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

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

    [ipaserver]
    server.idm.example.com
    
    [ipaserver:vars]
    ipaserver_domain=idm.example.com
    ipaserver_realm=IDM.EXAMPLE.COM
    ipaserver_setup_dns=no
    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=no
    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

関連情報

26.6.3. 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
  5. 以下のいずれかのオプションを選択します。

    • IdM デプロイメントで外部 DNS を使用する場合: /tmp/ipa.system.records.UFRPto.db ファイルに含まれる DNS リソースレコードを、既存の外部 DNS サーバーに追加します。DNS レコードの更新プロセスは、特定の DNS ソリューションによって異なります。

      ...
      Restarting the KDC
      Please add records in this file to your DNS system: /tmp/ipa.system.records.UFRBto.db
      Restarting the web server
      ...
    重要

    既存の DNS サーバーに DNS レコードを追加するまで、サーバーのインストールは完了しません。

    • IdM デプロイメントで統合 DNS を使用している場合は、次のコマンドを実行します。

      • 親ドメインから ldM DNS ドメインに DNS 委譲を追加します。たとえば、IdM DNS ドメインが idm.example.com の場合は、ネームサーバー (NS) レコードを親ドメイン example.com に追加します。

        重要

        IdM DNS サーバーをインストールするたびに、この手順を繰り返します。

      • タイムサーバーの _ntp._udp サービス(SRV) レコードを IdM DNS に追加します。IdM DNS に新たにインストールした IdM サーバーのタイムサーバーの SRV レコードが存在すると、今後のレプリカおよびクライアントインストールが、このプライマリー IdM サーバーが使用するタイムサーバーと同期するように自動的に設定されます。

26.7. 関連情報

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

27.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 パッケージがインストールされている。

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

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

27.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ゾーンを使用するようにする場合は、インベントリーファイルに指定できます。これは、たとえば、デフォルトとして設定されているパブリックゾーンの代わりに、IdM インストールに内部firewalldゾーンを使用する場合に役立ちます。

      カスタムゾーンを設定しないと、サービスがデフォルトの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

    • シナリオ 5

      レプリカが IdM DNS サービスをホストするようにする場合は、ipareplica_setup_dns=yes 行を [ipareplicas:vars] セクションに追加します。また、サーバーごとの DNS フォワーダーを使用するかどうかを指定します。

      • サーバーごとのフォワーダーを設定するには、ipareplica_forwarders 変数と文字列の一覧を [ipareplicas:vars] セクションに追加します (例: ipareplica_forwarders=192.0.2.1,192.0.2.2)。
      • サーバーごとにフォワーダーを設定しない場合は、ipareplica_no_forwarders=yes の行を [ipareplicas:vars] セクションに追加します。
      • レプリカの /etc/resolv.conf ファイルに一覧表示されているフォワーダーに基づいてサーバーごとにフォワーダーを設定するには、[ipareplicas:vars] セクションに ipareplica_auto_forwarders を追加します。

        レプリカに DNS とサーバーごとのフォワーダーを設定する手順を含むインベントリーファイルの例

        [ipaservers]
        server.idm.example.com
        
        [ipareplicas]
        replica1.idm.example.com
        replica2.idm.example.com
        replica3.idm.example.com
        [...]
        
        [ipareplicas:vars]
        ipareplica_setup_dns=yes
        ipareplica_forwarders=192.0.2.1,192.0.2.2

関連情報

  • ipareplica変数の詳細は、/usr/share/ansible/roles/ipareplica/README.md Markdown ファイルを参照してください。

27.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 を参照してください。

27.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 レプリカがインストールされました。

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

28.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 パッケージがインストールされている。

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

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

28.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 を参照してください。

28.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 を参照してください。

28.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) ではなくクライアントをインストールするように指定します。

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

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

表28.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

28.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 クライアントをインストールしました。

28.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 ~]$

28.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 がホスト向けに発行した証明書がすべて削除されることに注意してください。

関連情報

パート II. IdM および AD の統合

第29章 IdM と AD との間の信頼のインストール

本章では、Identity Management (IdM) サーバーと Active Directory (AD) が同じフォレストにある場合に、両サーバー間に信頼を確立する方法を説明します。

前提条件

  • 「Planning a cross-forest trust between Identity Management and Active Directory」を読んでいる。
  • ドメインコントローラーとともに、AD がインストールされている。
  • IdM サーバーがインストールされ、実行している。

  • Kerberos では、通信に最大 5 分の遅延が必要になるため、AD サーバーおよび IdM サーバーの両方でクロックが同期されている必要があります。
  • NetBIOS 名は、Active Directory ドメインの特定に不可欠であるため、各サーバーで一意の NetBIOS 名を信頼に配置します。

    • Active Directory または IdM ドメインの NetBIOS 名は通常、対応する DNS ドメインの最初の部分になります。DNS ドメインが ad.example.com の場合、NetBIOS 名は通常 AD になります。ただし、必須ではありません。重要なのは、NetBIOS 名がピリオドなしの 1 つの単語であるということです。NetBIOS 名は最長 15 文字です。
  • IdM システムでは、カーネル内で IPv6 プロトコルが有効になっている必要があります。

    • IPv6 が無効になっていると、IdM サービスが使用する CLDAP プラグインが初期化に失敗します。

29.1. サポート対象の Windows Server バージョン

RHEL 8.4 では、Identity Management (IdM) は、Windows Server 2008 R2 以前のバージョンを実行している Active Directory ドメインコントローラーとの間で Active Directory への信頼を確立することに対応していません。RHEL IdM との信頼関係を確立する際に、SMB 暗号化が必要になりました。これは、Windows Server 2012 以降でのみ対応しています。

以下のフォレストおよびドメイン機能レベルを使用する Active Directory (AD) フォレストとの信頼関係を確立できます。

  • フォレスト機能レベルの範囲 - Windows Server 2012 ~ Windows Server 2016
  • ドメイン機能レベルの範囲: Windows Server 2012 - Windows Server 2016

Identity Management (IdM) は、以下のオペレーティングシステムを実行している Active Directory ドメインコントローラーとの信頼の確立に対応しています。

  • Windows Server 2012
  • Windows Server 2012 R2
  • Windows Server 2016
  • Windows Server 2019

29.2. 信頼の仕組み

Identity Management (IdM) と Active Directory (AD) の間の信頼は、レルム間の Kerberos 信頼で確立されます。このソリューションでは、Kerberos 機能を使用して、異なる ID ソース間で信頼関係を確立します。したがって、すべての AD ユーザーは次のことができます。

  • ログインして、Linux システムおよびリソースにアクセスする。
  • シングルサインオン (SSO) を使用する。

IdM オブジェクトはすべて、信頼の IdM で管理されます。

AD オブジェクトはすべて、信頼の AD で管理されます。

複雑な環境では、1 つの IdM フォレストを、複数の AD フォレストに接続できます。この設定により、組織のさまざまな機能の作業を、より適切に分離できます。Linux 管理者は Linux インフラストラクチャーを完全に制御できますが、AD 管理者はユーザーと、ユーザーに関連するポリシーに集中できます。このような場合、IdM が制御する Linux レルムは、AD リソースドメインまたはレルムに似ていますが、Linux システムが含まれています。

AD の観点から観ると、Identity Management は、1 つの AD ドメインを持つ個別の AD フォレストを表します。AD フォレストの root ドメインと IdM ドメインとの間にフォレスト間の信頼が確立されると、AD フォレストドメインのユーザーは、IdM ドメインの Linux マシンおよびサービスと相互作用できます。

注記

信頼環境では、IdM は ID ビューを使用して、IdM サーバーの AD ユーザーの POSIX 属性を設定できます。

29.3. AD 管理者権限

AD (Active Directory) と IdM (Identity Management) との間で信頼を構築する場合は、適切な AD 権限のある AD 管理者アカウントを使用する必要があります。

このような AD 管理者は、以下のいずれかのグループのメンバーである必要があります。

  • AD フォレスト内のエンタープライズ管理グループ
  • AD フォレスト用のフォレストルートドメインのドメイン管理グループ

関連情報

29.4. AD および RHEL で一般的な暗号化タイプに対応

デフォルトでは、Identity Management は RC4、AES-128、および AES-256 の Kerberos 暗号化タイプに対応するレルム間の信頼を確立します。

RC4 暗号化は、新しい暗号化タイプ AES-128 および AES-256 よりも安全ではないと見なされるため、デフォルトで非推奨となり、無効にされています。一方、Active Directory (AD) ユーザーの認証情報と AD ドメイン間の信頼は RC4 暗号化をサポートしており、AES 暗号化タイプに対応していない可能性があります。

一般的な暗号化タイプがないと、IdM と AD 子ドメインとの間の通信が機能しないか、一部の AD アカウントが認証できない可能性があります。この状況を修正するには、以下の設定のいずれかを変更します。

  • Active Directory で AES 暗号化サポートを有効にする (推奨オプション) - AD フォレストの AD ドメイン間で信頼されるようにするには、Microsoft の記事 「AD DS: Security: Kerberos "Unsupported etype" error when accessing a resource in a trusted domain」を参照してください。
  • RC4 サポートを RHEL で有効化: AD ドメインコントローラーに対する認証が行われるすべての IdM 信頼コントローラー、信頼エージェント、およびクライアント。

    1. update-crypto-policies コマンドを使用して、DEFAULT 暗号化ポリシーに加え AD-SUPPORT 暗号化サブポリシーを有効にします。

      [root@host ~]# update-crypto-policies --set DEFAULT:AD-SUPPORT
      Setting system policy to DEFAULT:AD-SUPPORT
      Note: System-wide crypto policies are applied on application start-up.
      It is recommended to restart the system for the change of policies
      to fully take place.
    2. ホストを再起動します。
重要

AD-SUPPORT 暗号化サブポリシーは、RHEL 8.3 以降でのみ利用できます。

  • RHEL 8.2 以前は RC4 のサポートを有効にするには、cipher = RC4-128+ でカスタム暗号化モジュールポリシーを作成および有効にします。詳細は、ポリシー修飾子を使用したシステム全体の暗号化ポリシーのカスタマイズを参照してください。
  • RHEL 8.0 および RHEL 8.1 で RC4 のサポートを有効にするには、/etc/crypto-policies/back-ends/krb5.config ファイルの permitted_enctypes オプションに +rc4 を追加します。

    [libdefaults]
    permitted_enctypes = aes256-cts-hmac-sha1-96 aes256-cts-hmac-sha384-192 camellia256-cts-cmac aes128-cts-hmac-sha1-96 aes128-cts-hmac-sha256-128 camellia128-cts-cmac +rc4

関連情報

29.5. IdM と AD との間の通信に必要なポート

Active Directory (AD) 環境と Identity Management (IdM) 環境間の通信を有効にするには、AD ドメインコントローラーおよび IdM サーバーのファイアウォールで次のポートを開きます。

表29.1 AD 信頼に必要なポート

サービスポートプロトコル

エンドポイント解決ポートマッパー

135

TCP

NetBIOS-DGM

138

TCP および UDP

NetBIOS-SSN

139

TCP および UDP

Microsoft-DS

445

TCP および UDP

動的 RPC

49152-65535

TCP

AD グローバルカタログ

3268

TCP

LDAP

389

TCP および UDP

注記

信頼のために IdM サーバーで TCP ポートの 389 を開く必要はありませんが、IdM サーバーと通信しているクライアントに必要です。

ポートを開くには、以下の方法を使用できます。

  • Firewalld サービス - 特定ポートを有効にするか、そのポートが含まれる以下のサービスを有効にすることができます。

    • freeipa 信頼の設定
    • LDAP を用いた FreeIPA
    • Kerberos
    • DNS

    詳細は「CLI を使用したポートの制御」を参照してください。

注記

freeipa-trust Firewalld サービスには現在 1024-1300 の RPC ポート範囲が含まれていますが、この範囲は Windows Server 2008 以降では 49152 ~ 65535 に更新されました。Firewalld サービス freeipa-trust が更新され、この新しい範囲が反映されるようになりました。この問題は、Bug 1850418 - update freeipa-trust.xml definition to include correct dynamic RPC range で追跡されています。

このバグが解決されるまで、Firewalld サービス freeipa-trust の有効化に加えて、TCP ポート範囲は 49152-65535 を手動で開きます。

  • RHEL Web コンソール。firewalld サービスに基づくファイアウォール設定を含む UI です。

    A screenshot of the RHEL web console displaying firewall settings in the Networking section. There is a list of "Allowed Services" listing several services and their associated TCP and UDP ports.

    Web コンソールを使用したファイアウォール設定の詳細は、「Web コンソールを使用したファイアウォールでのサービスの有効化」を参照してください。

    注記

    FreeIPA Trust Setup サービスには現在 1024-1300 の RPC ポート範囲が含まれていますが、この範囲は Windows Server 2008 以降では 49152 ~ 65535 に更新されました。FreeIPA Trust Setup ファイアウォールサービス定義が更新され、この問題は Bug 1850418 - update freeipa-trust.xml definition to include correct dynamic RPC range で追跡されています。

    このバグが解決されるまで、RHEL Web コンソールで FreeIPA Trust Setup サービスを有効にする他に、TCP ポート範囲は 49152-65535 を手動で開きます。

表29.2 信頼の IdM サーバーで必要なポート

サービスポートプロトコル

Kerberos

88、464

TCP および UDP

LDAP

389

TCP

DNS

53

TCP および UDP

表29.3 AD 信頼で IdM クライアントに必要なポート

サービスポートプロトコル

Kerberos

88

UDP および TCP

注記

libkrb5 ライブラリーは UDP を使用し、KDC (Key Distribution Centre) から送信されるデータが大きすぎると、TCP プロトコルにフォールバックします。Active Directory は、PAC (Privilege Attribute Certificate) を Kerberos チケットに割り当てます。これによりサイズが増加し、TCP プロトコルを使用する必要があります。要求のフォールバックと再送信を回避するため、デフォルトでは、Red Hat Enterprise Linux 7.4 以降の SSSD ではユーザー認証に TCP が使用されます。libkrb5 が TCP を使用する前にサイズを設定する場合は、/etc/krb.5.conf ファイルに udp_preference_limit を設定します。詳細は、man ページの krb5.conf(5) を参照してください。

関連情報

29.6. 信頼用の DNS およびレルムの設定の構成

信頼で Identity Management (IdM) と Active Directory (AD) を接続する前に、サーバーが相互に認識し、ドメイン名を正しく解決できるようにする必要があります。ここでは、以下の間でドメイン名を使用できるように DNS を設定する方法を説明します。

  • 統合 DNS サーバーおよび認証局を使用する 1 台のプライマリー IdM サーバー
  • 1 台の AD ドメインコントローラー

DNS 設定には以下が必要です。

  • IdM サーバーに DNS ゾーンの設定
  • AD での条件付き DNS 転送の設定
  • DNS 設定の正確性の確認

29.6.1. 一意のプライマリー DNS ドメイン

Windows では、すべてのドメインが Kerberos レルムと DNS ドメインを同時に設定します。ドメインコントローラーが管理するすべてのドメインには、独自の専用 DNS ゾーンが必要です。Identity Management (IdM) がフォレストとして Active Directory (AD) に信頼される場合も同様です。AD は、IdM に独自の DNS ドメインがあることを想定します。信頼の設定を機能させるには、DNS ドメインを Linux 環境専用にする必要があります。

各システムには、独自の固有プライマリー DNS ドメインが設定されている必要があります。以下に例を示します。

  • ad.example.com (AD の場合) および idm.example.com (IdM の場合)
  • example.com (AD の場合) および idm.example.com (IdM の場合)
  • ad.example.com (AD の場合) および example.com (IdM の場合)

最も便利な管理ソリューションは、各 DNS ドメインが統合 DNS サーバーで管理されている環境ですが、規格に準拠した DNS サーバーも使用できます。

Kerberos レルム名は、プライマリー DNS ドメイン名を大文字にしたもの
Kerberos レルム名は、プライマリー DNS ドメイン名と同じで、すべて大文字にする必要があります。たとえば、AD のドメイン名が ad.example.com で、IdM のドメイン名が idm.example.com の場合、Kerberos レルム名は AD.EXAMPLE.COM および IDM.EXAMPLE.COM になります。
DNS レコードが信頼内の全 DNS ドメインから解決可能である
すべてのマシンが、信頼関係内で関連するすべての DNS ドメインの DNS レコードを解決できるようにする必要があります。
IdM ドメインおよび AD DNS ドメイン
IdM に参加しているシステムは、複数の DNS ドメインに分散できます。Red Hat では、Active Directory が所有するクライアントとは異なる DNS ゾーンに IdM クライアントをデプロイすることを推奨しています。プライマリー IdM DNS ドメインには、AD 信頼に対応するのに適切な SRV レコードが必要です。
注記

IdM と Active Directory との間の信頼がある一部の環境では、Active Directory DNS ドメインの一部であるホストに IdM クライアントをインストールできます。ホストは、これにより、Linux に焦点を合わせた IdM の機能の恩恵を受けることができます。これは推奨される設定ではなく、いくつかの制限があります。詳細は Active Directory DNS ドメインで IdM クライアントの設定 を参照してください。

次のコマンドを実行して、システム設定に必要な固有の SRV レコードの一覧を取得できます。

$ ipa dns-update-system-records --dry-run

生成される一覧は、たとえば以下のようになります。

IPA DNS records:
  _kerberos-master._tcp.idm.example.com. 86400 IN SRV 0 100 88 server.idm.example.com.
  _kerberos-master._udp.idm.example.com. 86400 IN SRV 0 100 88 server.idm.example.com.
  _kerberos._tcp.idm.example.com. 86400 IN SRV 0 100 88 server.idm.example.com.
  _kerberos._tcp.idm.example.com. 86400 IN SRV 0 100 88 server.idm.example.com.
  _kerberos.idm.example.com. 86400 IN TXT "IDM.EXAMPLE.COM"
  _kpasswd._tcp.idm.example.com. 86400 IN SRV 0 100 464 server.idm.example.com.
  _kpasswd._udp.idm.example.com. 86400 IN SRV 0 100 464 server.idm.example.com.
  _ldap._tcp.idm.example.com. 86400 IN SRV 0 100 389 server.idm.example.com.
  _ipa-ca.idm.example.com. 86400 IN A 192.168.122.2

同じ IdM レルムにあるその他の DNS ドメインでは、AD への信頼を設定する際に SRV レコードを設定する必要はありません。これは、AD ドメインコントローラーが、KDC の検索に SRV レコードではなく、信頼の名前接尾辞のルーティング情報を使用するためです。

29.6.2. IdM Web UI での DNS 正引きゾーンの設定

本セクションでは、IdM Web UI を使用して、新しい DNS 正引きゾーンを Identity Management (IdM) サーバーに追加する方法を説明します。

DNS 正引きゾーンを使用すると、特定のゾーンの DNS クエリーを別の DNS サーバーに転送できます。たとえば、Active Directory (AD)ドメインの DNS クエリーを AD DNS サーバーに転送することができます。

前提条件

  • 管理者権限のあるユーザーアカウントを使用して IdM Web UI にアクセスする。
  • DNS サーバーを正しく設定している。

手順

  1. 管理者権限で IdM Web UI にログインします。詳細は「Web ブラウザーで IdM Web UI へのアクセス」を参照してください。
  2. Network Services タブをクリックします。
  3. DNS タブをクリックします。
  4. ドロップダウンメニューで、DNS Forward Zones 項目をクリックします。

    Screenshot of the IdM Web UI displaying the contents of the DNS drop-down sub-menu of the "Network Services" tab. The DNS drop-down menu has four options: DNS Zones - DNS Forward Zones - DNS Servers - DNS Global Configuration. "DNS Forward Zones" is highlighted.

  5. 追加 ボタンをクリックします。
  6. Add DNS forward zone ダイアログボックスにゾーン名を追加します。
  7. Zone forwarders 項目で、Add ボタンをクリックします。
  8. Zone forwarders フィールドに、新しい正引きゾーンを作成するサーバーの IP アドレスを追加します。
  9. 追加 ボタンをクリックします。

    Screenshot of the "Add DNS forward zone" pop-up window with text entry fields for "Zone name" - "Reverse zone IP network" - "Zone forwarders." The "Forward policy" option has three radial buttons for "forward first" - "forward only" - "forward disabled." There is a checkbox for "Skip overlap check" and there are four buttons at the bottom: "Add" - "Add and Add Another" - "Add and Edit" - "Cancel."

正引きゾーンが DNS 設定に追加されており、DNS 正引きゾーン設定で確認できます。Web UI は、ポップアップメッセージ DNS Forward Zone successfully added. で、成功を通知します。

注記

設定に新しい正引きゾーンを追加した後に、Web UI にDNSSEC 検証の失敗に関する警告が表示される場合があります。

Screenshot displaying a popup window that reads "DNSSEC validation failed - record ad.example.com SOA failed DNSSEC validation on server 192.168.122.2. Please verify your DNSSEC configuration or disable DNSSEC validation on all IPA servers."

DNSSEC (Domain Name System Security Extensions) は、DNS データをデジタル署名で保護し、攻撃から DNS を保護します。このサービスは、IdM サーバーでデフォルトで有効になっています。リモート DNS サーバーが DNSSEC を使用していないため、警告が表示されます。Red Hat は、リモート DNS サーバーで DNSSEC を有効にすることを推奨します。

リモートサーバーで DNSSEC 検証を有効にできない場合は、IdM サーバーで DNSSEC を無効にすることができます。

  1. 編集する適切な設定ファイルを選択します。

    • IdM サーバーが RHEL 8.0 または RHEL 8.1 を使用している場合は、/etc/named.conf ファイルを開きます。
    • IdM サーバーが RHEL 8.2 以降を使用している場合は、/etc/named/ipa-options-ext.conf ファイルを開きます。
  2. 以下の DNSSEC パラメーターを追加します。

    dnssec-enable no;
    dnssec-validation no;
  3. 設定ファイルを保存して閉じます。
  4. DNS サービスを再起動します。

    # systemctl restart named-pkcs11

検証手順

  • nslookup コマンドを、リモート DNS サーバーの名前で使用します。

    $ nslookup ad.example.com
    Server:        192.168.122.2
    Address:       192.168.122.2#53
    
    No-authoritative answer:
    Name:          ad.example.com
    Address:       192.168.122.3

    ドメイン転送が正しく設定されている場合、nslookup 要求はリモート DNS サーバーの IP アドレスを表示します。

29.6.3. CLI での DNS 正引きゾーンの設定

本セクションでは、コマンドラインインターフェース(CLI)を使用して、新しい DNS 正引きゾーンを Identity Management (IdM) サーバーに追加する方法を説明します。

DNS 正引きゾーンを使用すると、特定のゾーンの DNS クエリーを別の DNS サーバーに転送できます。たとえば、Active Directory (AD)ドメインの DNS クエリーを AD DNS サーバーに転送することができます。

前提条件

  • 管理者権限のあるユーザーアカウントを使用して CLI にアクセスする。
  • DNS サーバーを正しく設定している。

手順

  • AD ドメインの DNS 正引きゾーンを作成し、--forwarder オプションを使用してリモート DNS サーバーの IP アドレスを指定します。

    # ipa dnsforwardzone-add ad.example.com --forwarder=192.168.122.3 --forward-policy=first
注記

設定に新しい正引きゾーンを追加した後に、/var/log/messages システムログに DNSSEC 検証の失敗に関する警告が表示される場合があります。

named-pkcs11[2572]: no valid DS resolving 'host.ad.example.com/A/IN':  192.168.100.25#53

DNSSEC (Domain Name System Security Extensions) は、DNS データをデジタル署名で保護し、攻撃から DNS を保護します。このサービスは、IdM サーバーでデフォルトで有効になっています。リモート DNS サーバーが DNSSEC を使用していないため、警告が表示されます。Red Hat は、リモート DNS サーバーで DNSSEC を有効にすることを推奨します。

リモートサーバーで DNSSEC 検証を有効にできない場合は、IdM サーバーで DNSSEC を無効にすることができます。

  1. 編集する適切な設定ファイルを選択します。

    • IdM サーバーが RHEL 8.0 または RHEL 8.1 を使用している場合は、/etc/named.conf ファイルを開きます。
    • IdM サーバーが RHEL 8.2 以降を使用している場合は、/etc/named/ipa-options-ext.conf ファイルを開きます。
  2. 以下の DNSSEC パラメーターを追加します。

    dnssec-enable no;
    dnssec-validation no;
  3. 設定ファイルを保存して閉じます。
  4. DNS サービスを再起動します。

    # systemctl restart named-pkcs11

検証手順

  • nslookup コマンドを、リモート DNS サーバーの名前で使用します。

    $ nslookup ad.example.com
    Server:        192.168.122.2
    Address:       192.168.122.2#53
    
    No-authoritative answer:
    Name:          ad.example.com
    Address:       192.168.122.3

    ドメイン転送が正しく設定されている場合、nslookup 要求はリモート DNS サーバーの IP アドレスを表示します。

29.6.4. AD での DNS 転送の設定

本セクションでは、Identity Management (IdM) サーバーの Active Directory (AD) に DNS 転送を設定する方法を説明します。

前提条件

  • AD を使用する Windows Server がインストールされている。
  • 両方のサーバーで DNS ポートが開いている。

手順

  1. Windows サーバーにログインします。
  2. Server Manager を開きます。
  3. DNS Manager を開きます。
  4. Conditional Forwarders で、以下を含む新しい条件フォワーダーを追加します。

    • IdM サーバーの IP アドレス
    • server.idm.example.com などの完全修飾ドメイン名
  5. 設定を保存します。

29.6.5. DNS 設定の確認

信頼を設定する前に、Identity Management (IdM) サーバーおよび Active Directory (AD) サーバーが自身を解決でき、相互に解決できることを確認します。

前提条件

  • sudo パーミッションでログインする必要があります。

手順

  1. UDP サービスレコードの Kerberos、および TCP サービスレコード上の LDAP に、DNS クエリーを実行します。

    [admin@server ~]# dig +short -t SRV _kerberos._udp.idm.example.com.
    0 100 88 server.idm.example.com.
    
    [admin@server ~]# dig +short -t SRV _ldap._tcp.idm.example.com.
    0 100 389 server.idm.example.com.

    コマンドは、すべての IdM サーバーを一覧で表示する必要があります。

  2. IdM Kerberos レルム名を使用して、TXT レコードに DNS クエリーを実行します。取得した値は、IdM のインストール時に指定した Kerberos レルムと一致することが予想されます。

    [admin@server ~]# dig +short -t TXT _kerberos.idm.example.com.
    "IDM.EXAMPLE.COM"

    前の手順で想定されるレコードがすべて返されなかった場合は、欠落しているレコードで DNS 設定を更新します。

    • IdM 環境で統合 DNS サーバーを使用する場合は、システムレコードを更新するオプションを指定せずに ipa dns-update-system-records コマンドを実行します。

      [admin@server ~]$ ipa dns-update-system-records
    • IdM 環境で統合 DNS サーバーを使用しない場合は、以下を行います。

      1. IdM サーバーで、IdM DNS レコードをファイルにエクスポートします。

        [admin@server ~]$ ipa dns-update-system-records --dry-run --out dns_records_file.nsupdate

        このコマンドは、関連する IdM DNS レコードで dns_records_file.nsupdate という名前のファイルを作成します。

      2. nsupdate ユーティリティーおよび dns_records_file.nsupdate ファイルを使用して DNS サーバーに DNS 更新リクエストを送信します。詳細は、RHEL 7 ドキュメントの「nsupdate を使用した外部 DNS レコード更新」を参照してください。または、DNS レコードの追加については、お使いの DNS サーバーのドキュメントを参照してください。
  3. IdM が、TCP サービスレコードの Kerberos および LDAP サービスレコードで DNS クエリーを実行するコマンドで、AD のサービスレコードを解決できることを確認します。

    [admin@server ~]# dig +short -t SRV _kerberos._tcp.dc._msdcs.ad.example.com.
    0 100 88 addc1.ad.example.com.
    
    [admin@server ~]# dig +short -t SRV _ldap._tcp.dc._msdcs.ad.example.com.
    0 100 389 addc1.ad.example.com.

29.7. Active Directory DNS ドメインで IdM クライアントの設定

Active Directory が制御する DNS ドメインにクライアントシステムがあり、そのクライアントが RHEL 機能の恩恵を受けるために IdM Server に参加できるようにする必要がある場合は、Active Directory DNS ドメインのホスト名を使用してクライアントにアクセスするようにユーザーを設定できます。

重要

これは推奨される設定ではなく、いくつかの制限があります。Red Hat は、Active Directory が所有する DNS ゾーンとは異なる DNS ゾーンに常に IdM クライアントを展開し、IdM ホスト名を介して IdM クライアントにアクセスすることをお勧めします。

IdM クライアントの設定は、Kerberos でシングルサインオンを必要とするかどうかによって異なります。

29.7.1. Kerberos シングルサインオンを使用しない IdM クライアントの設定

パスワード認証は、IdM クライアントが Active Directory DNS ドメインに存在する場合に、IdM クライアントのリソースにアクセスするためにユーザーが利用できる唯一の認証方法です。この手順では、Kerberos シングルサインオンを使用せずにクライアントを設定する方法を説明します。

手順

  1. --domain=IPA_DNS_Domain を指定して IdM クライアントをインストールし、SSSD (System Security Services Daemon) が IdM サーバーと通信できるようにします。

    [root@idm-client.ad.example.com ~]# ipa-client-install --domain=idm.example.com

    このオプションは、Active Directory DNS ドメインの SRV レコードの自動検出を無効にします。

  2. /etc/krb5.conf 設定ファイルの [domain_realm] セクションで、Active Directory ドメインの既存のマッピングを見つけます。

    .ad.example.com = IDM.EXAMPLE.COM
    ad.example.com = IDM.EXAMPLE.COM
  3. 両方の行を、Active Directory DNS ゾーンの Linux クライアントの完全修飾ドメイン名 (FQDN) を IdM レルムにマッピングするエントリーに置き換えます。

    idm-client.ad.example.com = IDM.EXAMPLE.COM

    デフォルトのマッピングを置き換えても、Kerberos が Active Directory ドメインの要求を IdM Kerberos Distribution Center (KDC) に送信しないようにします。Kerberos は、SRV DNS レコードを介して自動検出を使用して KDC を見つけます。

29.7.2. シングルサインオンなしで SSL 証明書の要求

SSL ベースのサービスでは、元 (A/AAAA) のレコードと CNAME レコードの両方が証明書に含まれている必要があるため、すべてのシステムホスト名に対応する dNSName 拡張レコードを持つ証明書が必要です。現在、IdM は、IdM データベース内のオブジェクトをホストする証明書のみを発行します。

シングルサインオンが利用できない説明されたセットアップでは、IdM は、データベースに FQDN のホストオブジェクトをすでに持っており、certmonger はこの名前を使用して証明書を要求できます。

前提条件

手順

  • certmonger を使用して、FQDN を使用して証明書をリクエストします。

    [root@idm-client.ad.example.com ~]# ipa-getcert request -r \
          -f /etc/httpd/alias/server.crt \
          -k /etc/httpd/alias/server.key \
          -N CN=ipa-client.ad.example.com \
          -D ipa-client.ad.example.com \
          -K host/idm-client.ad.example.com@IDM.EXAMPLE.COM \
          -U id-kp-serverAuth

certmonger サービスは、/etc/krb5.keytab ファイルに保存されているデフォルトのホストキーを使用して、IdM 認証局 (CA) に対して認証を行います。

29.7.3. Kerberos シングルサインオンで IdM クライアントの設定

IdM クライアントのリソースにアクセスするために Kerberos シングルサインオンが必要な場合、クライアントは idm-client.idm.example.com などの IdM DNS ドメイン内になければなりません。IdM クライアントの A/AAAA レコードを参照する Active Directory DNS ドメインで CNAME レコード idm-client.ad.example.com を作成する必要があります。

Kerberos ベースのアプリケーションサーバーの場合、MIT Kerberos は、アプリケーションのキータブで利用可能なホストベースのプリンシパルの受け入れを可能にする方法をサポートします。

手順

  • IdM クライアントでは、/etc/krb5.conf 設定ファイルの [libdefaults] セクションにある次のオプションを設定して、Kerberos サーバーのターゲットに使用される Kerberos プリンシパルに関する厳格なチェックを無効にします。

    ignore_acceptor_hostname = true

29.7.4. シングルサインオンで SSL 証明書の要求

SSL ベースのサービスでは、元 (A/AAAA) のレコードと CNAME レコードの両方が証明書に含まれている必要があるため、すべてのシステムホスト名に対応する dNSName 拡張レコードを持つ証明書が必要です。現在、IdM は、IdM データベース内のオブジェクトをホストする証明書のみを発行します。

この手順では、IdM で ipa-client.example.com 用のホストオブジェクトを作成し、実際の IdM マシンのホストオブジェクトがこのホストを管理できるようにする方法を説明します。

前提条件

手順

  1. IdM サーバーに新しいホストオブジェクトを作成します。

    [root@idm-server.idm.example.com ~]# ipa host-add idm-client.ad.example.com --force

    ホスト名は CNAME であり、A/AAAA レコードではないため、--force オプションを使用します。

  2. IdM サーバーで、IdM DNS ホスト名が、IdM データベースの Active Directory ホストエントリーを管理できるようにします。

    [root@idm-server.idm.example.com ~]# ipa host-add-managedby idm-client.ad.example.com \
          --hosts=idm-client.idm.example.com
  3. これで、Active Directory DNS ドメイン内のホスト名にdNSName拡張レコードを使用して、IdM クライアントの SSL 証明書を要求できるようになります。

    [root@idm-client.idm.example.com ~]# ipa-getcert request -r \
          -f /etc/httpd/alias/server.crt \
          -k /etc/httpd/alias/server.key \
          -N CN=`hostname --fqdn` \
          -D `hostname --fqdn` \
          -D idm-client.ad.example.com \
          -K host/idm-client.idm.example.com@IDM.EXAMPLE.COM \
          -U id-kp-serverAuth

29.8. 信頼の設定

本セクションでは、コマンドラインを使用して、IdM に Identity Management (IdM)/Active Directory (AD) 信頼を設定する方法を説明します。

前提条件

29.8.1. 信頼用の IdM サーバーの準備

AD との信頼を確立する前に、IdM サーバーで ipa-adtrust-install ユーティリティーを使用して IdM ドメインを準備する必要があります。

注記

ipa-adtrust-install コマンドを自動的に実行するシステムは、AD 信頼コントローラーになります。ただし、ipa-adtrust-install は、IdM サーバーで 1 回のみ実行する必要があります。

前提条件

  • IdM サーバーがインストールされている。
  • パッケージをインストールし、IdM サービスを再起動するには、root 権限が必要です。

手順

  1. 必要なパッケージをインストールします。

    [root@ipaserver ~]# yum install ipa-server-trust-ad samba-client
  2. IdM 管理ユーザーとして認証します。

    [root@ipaserver ~]# kinit admin
  3. ipa-adtrust-install ユーティリティーを実行します。

    [root@ipaserver ~]# ipa-adtrust-install

    統合 DNS サーバーとともに IdM がインストールされていると、DNS サービスレコードが自動的に作成されます。

    IdM が統合 DNS サーバーなしで IdM をインストールすると、ipa-adtrust-install は、続行する前に DNS に手動で追加する必要があるサービスレコードのリストを出力します。

  4. スクリプトにより、/etc/samba/smb.conf がすでに存在し、書き換えられることが求められます。

    WARNING: The smb.conf already exists. Running ipa-adtrust-install will break your existing Samba configuration.
    
    Do you wish to continue? [no]: yes
  5. このスクリプトは、従来の Linux クライアントが信頼できるユーザーと連携できるようにする互換性プラグインである slapi-nis プラグインを設定するように求めるプロンプトを表示します。

    Do you want to enable support for trusted domains in Schema Compatibility plugin?
    This will allow clients older than SSSD 1.9 and non-Linux clients to work with trusted users.
    
    Enable trusted domains support in slapi-nis? [no]: yes
  6. プロンプトが表示されたら、IdM ドメインの NetBIOS 名を入力するか、Enter を押して提案された名前を使用します。

    Trust is configured but no NetBIOS domain name found, setting it now.
    Enter the NetBIOS name for the IPA domain.
    Only up to 15 uppercase ASCII letters, digits and dashes are allowed.
    Example: EXAMPLE.
    
    NetBIOS domain name [IDM]:
  7. SID 生成タスクを実行して、既存ユーザーに SID を作成するように求められます。

    Do you want to run the ipa-sidgen task? [no]: yes

    これはリソースを集中的に使用するタスクであるため、ユーザー数が多い場合は別のタイミングで実行できます。

  8. (必要に応じて) デフォルトでは、Windows Server 2008 以降では、動的 RPC ポートの範囲は 49152-65535 として定義されます。ご使用の環境に異なる動的 RPC ポート範囲を定義する必要がある場合は、Samba が異なるポートを使用するように設定し、ファイアウォール設定でそのポートを開くように設定します。以下の例では、ポート範囲を 55000-65000 に設定します。

    [root@ipaserver ~]# net conf setparm global 'rpc server dynamic port range' 55000-65000
    [root@ipaserver ~]# firewall-cmd --add-port=55000-65000/tcp
    [root@ipaserver ~]# firewall-cmd --runtime-to-permanent
  9. 「信頼の DNS 設定の確認」に従って、DNS が適切に設定されていることを確認します。

    重要

    Red Hat では、IdM または AD が統合 DNS サーバーを使用しない場合に、ipa-adtrust-install を実行してから 信頼に対する DNS 設定の確認 に従って DNS 設定を検証することが強く推奨されます。

  10. ipa サービスを再起動します。

    [root@ipaserver ~]# ipactl restart
  11. smbclient ユーティリティーを使用して、Samba が IdM からの Kerberos 認証に応答することを確認します。

    [root@ipaserver ~]# smbclient -L server.idm.example.com -k
    lp_load_ex: changing to config backend registry
        Sharename       Type      Comment
        ---------       ----      -------
        IPC$            IPC       IPC Service (Samba 4.12.3)
    ...

29.8.2. コマンドラインで信頼関係の設定

本セクションでは、コマンドラインを使用して信頼関係を設定する方法を説明します。Identity Management (IdM) サーバーには、3 種類の信頼関係を設定できます。

  • 一方向の信頼 は、default オプションを指定します。一方向の信頼により、Active Directory (AD) ユーザーおよびグループは IdM のリソースにアクセスできますが、その逆はできません。IdM ドメインは AD フォレストを信頼しますが、AD フォレストは IdM ドメインを信頼しません。
  • 双方向の信頼 は、AD ユーザーおよびグループが IdM のリソースにアクセスできるようになります。

    信頼境界を使用して Kerberos プロトコルに S4U2Self および S4U2Proxy の Microsoft 拡張を必要とする、Microsoft SQL Server などのソリューションに、双方向の信頼を設定する必要があります。RHEL IdM ホスト上にあるアプリケーションは、AD ユーザーに関する S4U2Self または S4U2Proxy の情報を Active Directory ドメインコントローラーから要求する場合があり、双方向の信頼でこの機能が提供されます。

    この双方向の信頼機能では、IdM ユーザーは Windows システムにログインできないだけでなく、IdM の双方向信頼では、AD の一方向信頼ソリューションと比較して、権限が追加でユーザーに付与されるわけではありません。

    • 双方向の信頼を作成するには、コマンドに --two-way=true オプションを追加します。
  • 外部の信頼 - 異なるフォレスト内の IdM ドメインと AD ドメインとの間の信頼関係です。フォレストの信頼では常に IdM と Active Directory フォレストのルートドメインとの間で信頼関係を確立する必要がありますが、IdM からフォレスト内の任意のドメインへの外部の信頼関係も確立できます。管理上または組織上の理由で、フォレストの root ドメイン間でフォレストの信頼を確立できない場合に限り、これが推奨されます。

    • 外部の信頼を作成するには、コマンドに --external=true オプションを追加します。

本セクションでは、以下の手順に従って、一方向の信頼関係を作成する方法を説明します。

前提条件

手順

  • ipa trust-add コマンドを使用して、AD ドメインと IdM ドメインに信頼関係を作成します。

    • SSSD が SID に基づいて AD ユーザーの UID および GID を自動的に生成するようにするには、Active Directory ドメイン ID 範囲タイプとの信頼関係を作成します。これが最も一般的な設定です。

      [root@server ~]# ipa trust-add --type=ad ad.example.com --admin <ad_admin_username> --password --range-type=ipa-ad-trust
    • Active Directory でユーザーに POSIX 属性を設定し(uidNumber や gidNumber などの)、SSSD がこの情報を処理する必要がある場合は、POSIX 属性 ID 範囲タイプの Active Directory ドメインとの信頼関係 を作成します。

      [root@server ~]# ipa trust-add --type=ad ad.example.com --admin <ad_admin_username> --password --range-type=ipa-ad-trust-posix
警告

信頼の作成時に ID Range タイプを指定しないと、IdM はフォレストルートドメインの AD ドメインコントローラーから詳細を要求することで、適切な範囲タイプを自動的に選択しようとします。IdM が POSIX 属性を検出しない場合は、信頼インストールスクリプトで Active Directory ドメイン ID 範囲を選択します。

IdM がフォレストルートドメインの POSIX 属性を検出すると、信頼インストールスクリプトは POSIX 属性 ID 範囲を持つ Active Directory ドメイン を選択し、UID と GID が AD に正しく定義されていることを前提としています。AD で POSIX 属性が正しく設定されていない場合は、AD ユーザーを解決できません。

たとえば、IdM システムへのアクセスが必要なユーザーおよびグループがフォレストルートドメインの一部ではなく、フォレストドメインの子ドメインにある場合は、インストールスクリプトで子 AD ドメインで定義されている POSIX 属性が検出されない可能性があります。この場合、Red Hat は、信頼の確立時に POSIX ID 範囲タイプを明示的に選択することを推奨します。

29.8.3. IdM Web UI で信頼関係の設定

本セクションでは、IdM Web UI を使用して、IdM で Identity Management (IdM) /Active Directory (AD) の信頼関係を設定する方法を説明します。

前提条件

  • DNS が正しく設定されている。IdM サーバーおよび AD サーバーはどちらも、相手の名前を解決できる。
  • 対応しているバージョンの AD および IdM がデプロイされている。
  • Kerberos チケットを取得している。
  • Web UI で信頼を作成する前に、信頼用の IdM サーバーの準備 に従って、信頼用に IdM サーバーを準備している。
  • IdM 管理者としてログインしている。

手順

  1. 管理者権限で IdM Web UI にログインします。詳細は「Web ブラウザーで IdM Web UI へのアクセス」を参照してください。
  2. IdM Web UI で、IPA Server タブをクリックします。
  3. IPA Server タブで、Trusts タブをクリックします。
  4. ドロップダウンメニューで、Trusts オプションを選択します。

    ipa trust trusts

  5. Add ボタンをクリックします。
  6. Add Trust ダイアログボックスで、Active Directory ドメインの名前を入力します。
  7. Account フィールドおよび Password フィールドに、Active Directory 管理者の管理者認証情報を追加します。

    ipa trust add

  8. (必要に応じて) AD ユーザーおよびグループが IdM のリソースにアクセスできるようにする場合は、双方向信頼 を選択します。ただし、IdM の双方向の信頼では、AD の一方向の信頼ソリューションと比較して、ユーザーに追加の権限が付与されません。デフォルトのフォレスト間信頼の SID フィルタリング設定により、両方のソリューションの安全性は同じであると見なされます。
  9. (必要に応じて) AD フォレストのルートドメインではない AD ドメインで信頼 を設定する場合は、外部 信頼を選択します。フォレストの信頼では、常に IdM と Active Directory フォレストのルートドメインとの間で信頼関係を確立する必要がありますが、IdM から AD フォレスト内の任意のドメインへの外部の信頼を確立できます。
  10. (オプション) デフォルトでは、信頼インストールスクリプトは適切な ID 範囲タイプを検出しようとします。以下のオプションのいずれかを選択して、ID 範囲タイプを明示的に設定することもできます。

    1. SSSD が SID に基づいて AD ユーザーの UID および GID を自動的に生成するようにするには、Active Directory ドメイン ID 範囲タイプを選択します。これが最も一般的な設定です。
    2. Active Directory でユーザーに POSIX 属性を設定し(uidNumber gidNumberなどの)、SSSD がこの情報を処理する必要がある場合は、POSIX 属性 ID 範囲タイプの Active Directory ドメイン を選択します。

      The Range Type section of the IdM WebUI displays 3 radio buttons to choose the appropriate range type - Detect

      警告

      デフォルトの Detect オプションに Range type 設定のままにすると、IdM はフォレストルートドメインの AD ドメインコントローラーから詳細を要求し、適切な範囲タイプを自動的に選択しようとします。IdM が POSIX 属性を検出しない場合は、信頼インストールスクリプトで Active Directory ドメイン ID 範囲を選択します。

      IdM がフォレストルートドメインの POSIX 属性を検出すると、信頼インストールスクリプトは POSIX 属性 ID 範囲を持つ Active Directory ドメイン を選択し、UID と GID が AD に正しく定義されていることを前提としています。AD で POSIX 属性が正しく設定されていない場合は、AD ユーザーを解決できません。

      たとえば、IdM システムへのアクセスが必要なユーザーおよびグループがフォレストルートドメインの一部ではなく、フォレストドメインの子ドメインにある場合は、インストールスクリプトで子 AD ドメインで定義されている POSIX 属性が検出されない可能性があります。この場合、Red Hat は、信頼の確立時に POSIX ID 範囲タイプを明示的に選択することを推奨します。

  11. Add をクリックします。

検証手順

  • 信頼が IdM サーバーに正常に追加されると、IdM Web UI で緑色のポップアップ画面が表示されます。これは、以下を示しています。

    • ドメイン名が存在する。
    • Windows Server のユーザー名およびパスワードが正しく追加されている。

      idm trust added

これで、信頼接続と Kerberos 認証のテストを続行します。

29.8.4. Kerberos 設定の確認

Kerberos 設定を確認するには、Identity Management (IdM) ユーザーのチケットを取得できるかどうか、および IdM ユーザーがサービスチケットを要求できるかどうかを検証します。

手順

  1. Active Directory (AD) ユーザーのチケットを要求します。

    [root@ipaserver ~]# kinit user@AD.EXAMPLE.COM
  2. IdM ドメイン内のサービスのサービスチケットを要求します。

    [root@server ~]# kvno -S host server.idm.example.com

    AD サービスチケットが正常に許可されると、その他の要求されたすべてのチケットと共に記載されたレルム間の TGT (Ticket-Granting Ticket) があります。TGT の名前は、krbtgt/IPA.DOMAIN@AD.DOMAIN です。

[root@server ]# klist
Ticket cache: KEYRING:persistent:0:krb_ccache_hRtox00
Default principal: user@AD.EXAMPLE.COM

Valid starting       Expires              Service principal
03.05.2016 18:31:06  04.05.2016 04:31:01  host/server.idm.example.com@IDM.EXAMPLE.COM
	renew until 04.05.2016 18:31:00
03.05.2016 18:31:06 04.05.2016 04:31:01 krbtgt/IDM.EXAMPLE.COM@AD.EXAMPLE.COM
	renew until 04.05.2016 18:31:00
03.05.2016 18:31:01  04.05.2016 04:31:01  krbtgt/AD.EXAMPLE.COM@AD.EXAMPLE.COM
	renew until 04.05.2016 18:31:00

localauth プラグインは、Kerberos プリンシパルをローカルの System Security Services Daemon (SSSD) ユーザー名にマッピングします。これにより、AD ユーザーは Kerberos 認証を使用し、GSSAPI 認証に対応する Linux サービスに直接アクセスできます。

29.8.5. IdM で信頼設定の確認

信頼を設定する前に、Identity Management (IdM) サーバーおよび Active Directory (AD) サーバーが自身を解決でき、相互に解決できることを確認します。

前提条件

  • 管理者権限でログインしている。

手順

  1. UDP サービスレコード上の MS DC Kerberos、および TCP サービスレコード上の LDAP に、DNS クエリーを実行します。

    [root@server ~]# dig +short -t SRV _kerberos._udp.dc._msdcs.idm.example.com.
    0 100 88 server.idm.example.com.
    
    [root@server ~]# dig +short -t SRV _ldap._tcp.dc._msdcs.idm.example.com.
    0 100 389 server.idm.example.com.

    以下のコマンドは、ipa-adtrust-install を実行した IdM サーバーを一覧表示します。ipa-adtrust-install が IdM サーバーで実行していない場合、通常は最初の信頼関係を確立する前に出力が空になります。

  2. TCP サービスレコード上の Kerberos と LDAP で DNS クエリーを実行して、IdM が AD のサービスレコードを解決できることを確認します。

    [root@server ~]# dig +short -t SRV _kerberos._tcp.dc._msdcs.ad.example.com.
    0 100 88 addc1.ad.example.com.
    
    [root@ipaserver ~]# dig +short -t SRV _ldap._tcp.dc._msdcs.ad.example.com.
    0 100 389 addc1.ad.example.com.

.

29.8.6. AD で信頼設定の確認

信頼の設定後に、以下を確認します。

  • Identity Management (IdM) がホストするサービスが、Active Directory (AD) サーバーから解決できる。
  • AD サービスは、AD サーバーで解決できる。

前提条件

  • 管理者権限でログインしている。

手順

  1. AD サーバーに、サービスレコードを検索する nslookup.exe ユーティリティーを設定します。

    C:\>nslookup.exe
    > set type=SRV
  2. UDP サービスレコード上の Kerberos、および TCP サービスレコード上の LDAP に、ドメイン名を入力します。

    > _kerberos._udp.idm.example.com.
    _kerberos._udp.idm.example.com.       SRV service location:
        priority                = 0
        weight                  = 100
        port                    = 88
        svr hostname   = server.idm.example.com
    > _ldap._tcp.idm.example.com
    _ldap._tcp.idm.example.com       SRV service location:
        priority                = 0
        weight                  = 100
        port                    = 389
        svr hostname   = server.idm.example.com
  3. サービスの種類を TXT に変更し、IdM Kerberos レルム名で TXT レコードに DNS クエリーを実行します。

    C:\>nslookup.exe
    > set type=TXT
    > _kerberos.idm.example.com.
    _kerberos.idm.example.com.        text =
    
        "IDM.EXAMPLE.COM"
  4. UDP サービスレコード上の MS DC Kerberos、および TCP サービスレコード上の LDAP に、DNS クエリーを実行します。

    C:\>nslookup.exe
    > set type=SRV
    > _kerberos._udp.dc._msdcs.idm.example.com.
    _kerberos._udp.dc._msdcs.idm.example.com.        SRV service location:
        priority = 0
        weight = 100
        port = 88
        svr hostname = server.idm.example.com
    > _ldap._tcp.dc._msdcs.idm.example.com.
    _ldap._tcp.dc._msdcs.idm.example.com.        SRV service location:
        priority = 0
        weight = 100
        port = 389
        svr hostname = server.idm.example.com

    Active Directory は、その他の AD ドメインコントローラーや IdM 信頼コントローラーなど、AD 固有のプロトコル要求に応答できるドメインコントローラーの検出のみを想定します。ipa-adtrust-install ツールを使用して、IdM サーバーを信頼コントローラーに昇格し、どのサーバーが信頼コントローラーであるかを確認するには、ipa server-role-find --role 'AD trust controller' コマンドを使用します。

  5. AD サービスが AD サーバーで解決可能であることを検証します。

    C:\>nslookup.exe
    > set type=SRV
  6. UDP サービスレコード上の Kerberos、および TCP サービスレコード上の LDAP に、ドメイン名を入力します。

    > _kerberos._udp.dc._msdcs.ad.example.com.
    _kerberos._udp.dc._msdcs.ad.example.com. 	SRV service location:
        priority = 0
        weight = 100
        port = 88
        svr hostname = addc1.ad.example.com
    > _ldap._tcp.dc._msdcs.ad.example.com.
    _ldap._tcp.dc._msdcs.ad.example.com. 	SRV service location:
        priority = 0
        weight = 100
        port = 389
        svr hostname = addc1.ad.example.com

29.8.7. 信頼エージェントの作成

信頼エージェントは、AD ドメインコントローラーに対して ID ルックアップを実行できる IdM サーバーです。

たとえば、Active Directory と信頼できる IdM サーバーのレプリカを作成する場合は、そのレプリカを信頼エージェントとして設定できます。レプリカには、AD 信頼エージェントロールが自動的にインストールされていません。

前提条件

  • IdM は、Active Directory 信頼でインストールされます。
  • sssd-tools パッケージがインストールされている。

手順

  1. 既存の信頼コントローラーで、ipa-adtrust-install --add-agents コマンドを実行します。

    [root@existing_trust_controller]# ipa-adtrust-install --add-agents

    このコマンドは、対話型設定セッションを開始し、エージェントの設定に必要な情報の入力を求めます。

  2. 信頼エージェントで IdM サービスを再起動します。

    [root@new_trust_agent]# ipactl restart
  3. 信頼エージェントの SSSD キャッシュからすべてのエントリーを削除します。

    [root@new_trust_agent]# sssctl cache-remove
  4. レプリカに AD 信頼エージェントロールがインストールされていることを確認します。

    [root@existing_trust_controller]# ipa server-show new_replica.idm.example.com
    ...
    Enabled server roles: CA server, NTP server, AD trust agent

関連情報

  • --add-agents オプションの詳細は、man ページの ipa-adtrust-install(1) を参照してください。
  • 信頼エージェントの詳細は、『Planning Identity Management』の「Trust controllers and trust agents」を参照してください。

29.8.8. CLI での POSIX ID 範囲の自動プライベートグループマッピングの有効化

デフォルトでは、AD に保存されている POSIX データに依存する POSIX 信頼を確立している場合は、SSSD は Active Directory(AD)ユーザーのプライベートグループをマッピングしません。AD ユーザーにプライマリーグループが設定されていない場合、IdM はそれらを解決できません。

この手順では、コマンドラインで auto_private_groups SSSD パラメーターに ハイブリッド オプションを設定して、ID 範囲の自動プライベートグループマッピングを有効にする方法を説明します。これにより、IdM は、AD にプライマリーグループが設定されていない AD ユーザーを解決できます。

前提条件

  • IdM 環境と AD 環境間に、POSIX フォレスト間の信頼を正常に確立している。

手順

  1. すべての ID 範囲を表示し、変更する AD ID 範囲を書き留めます。

    [root@server ~]# ipa idrange-find
    ----------------
    2 ranges matched
    ----------------
      Range name: IDM.EXAMPLE.COM_id_range
      First Posix ID of the range: 882200000
      Number of IDs in the range: 200000
      Range type: local domain range
    
      Range name: AD.EXAMPLE.COM_id_range
      First Posix ID of the range: 1337000000
      Number of IDs in the range: 200000
      Domain SID of the trusted domain: S-1-5-21-4123312420-990666102-3578675309
      Range type: Active Directory trust range with POSIX attributes
    ----------------------------
    Number of entries returned 2
    ----------------------------
  2. ipa idrange-mod コマンドを使用して、AD ID 範囲の自動プライベートグループ動作を調整します。

    [root@server ~]# ipa idrange-mod --auto-private-groups=hybrid AD.EXAMPLE.COM_id_range
  3. SSSD キャッシュをリセットして、新しい設定を有効にします。

    [root@server ~]# sss_cache -E

29.8.9. IdM WebUI の POSIX ID 範囲の自動プライベートグループマッピングの有効化

デフォルトでは、AD に保存されている POSIX データに依存する POSIX 信頼を確立している場合は、SSSD は Active Directory(AD)ユーザーのプライベートグループをマッピングしません。AD ユーザーにプライマリーグループが設定されていない場合、IdM はそれらを解決できません。

この手順では、Identity Management(IdM)WebUI で auto_private_groups SSSD パラメーターに ハイブリッド オプションを設定することで、ID 範囲の自動プライベートグループマッピングを有効にする方法を説明します。これにより、IdM は、AD にプライマリーグループが設定されていない AD ユーザーを解決できます。

前提条件

  • IdM 環境と AD 環境間に、POSIX フォレスト間の信頼を正常に確立している。

手順

  1. ユーザー名とパスワードを使用して IdM Web UI にログインします。
  2. IPA ServerID Ranges タブを開きます。
  3. AD.EXAMPLE.COM_id_range など、変更する ID 範囲を選択します。
  4. Auto private groups ドロップダウンメニューから、ハイブリッド オプションを選択します。

    Screenshot of the ID Ranges tab of the IPA Server section of the IdM WebUI. A user selects the hybrid option from the Auth private groups dropdown menu.

  5. Save ボタンをクリックして変更を保存します。

29.9. コマンドラインを使用した信頼の削除

本セクションでは、コマンドラインインターフェースを使用して、IdM に Identity Management (IdM)/Active Directory (AD) 信頼を削除する方法を説明します。

前提条件

手順

  1. ipa trust-del コマンドを使用して、IdM から信頼設定を削除します。

    [root@server ~]# ipa trust-del ad_domain_name
    ------------------------------
    Deleted trust "ad_domain_name"
    ------------------------------
  2. Active Directory 設定から信頼オブジェクトを削除します。

検証手順

  • ipa trust-show を実行して、信頼が削除されたことを確認します。

    [root@server ~]# ipa trust-show ad.example.com
    ipa: ERROR: ad.example.com: trust not found

29.10. IdM Web UI で信頼の削除

本セクションでは、IdM Web UI を使用して、Identity Management (IdM)/Active Directory (AD) の信頼を削除する方法を説明します。

前提条件

手順

  1. 管理者権限で IdM Web UI にログインします。詳細は「Web ブラウザーで IdM Web UI へのアクセス」を参照してください。
  2. IdM Web UI で、IPA Server タブをクリックします。
  3. IPA Server タブで、Trusts タブをクリックします。
  4. 削除する信頼を選択します。

    A screenshot of the IdM Web UI displaying the "Trusts" page which is a subpage of the "IPA Server" tab. This page has a table listing "Realm names" and checkbox next to the first entry of "AD.EXAMPLE.COM" is checked.

  5. Delete ボタンをクリックします。
  6. Remove trusts ダイアログボックスで、Delete をクリックします。

    A screenshot of a pop-up window titled "Remove trusts." The content of the warning is "Are you sure you want to delete selected entries?" and lists "AD.EXAMPLE.COM" below. There are "Delete" and "Cancel" buttons at the bottom right.

  7. Active Directory 設定から信頼オブジェクトを削除します。

検証手順

  • 信頼が正常に削除されていると、Web UI はテキストが付いた緑色のポップアップを表示します。

    A screenshot of the IdM Web UI displaying the "Trusts" page with a pop-up window at the top that says "1 item(s) deleted." The table on the "Trusts" page does not have any entries.

パート III. RHEL 7 から RHEL 8 へ IdM を移行し、最新に維持

第30章 RHEL 7 サーバーから RHEL 8 サーバーへの IdM 環境の移行

RHEL 7 IdM 環境を RHEL 8 にアップグレードするには、最初に新しい RHEL 8 IdM レプリカを RHEL 7 IdM 環境に追加し、RHEL 7 サーバーをリタイアさせる必要があります。

警告

RHEL 8 への RHEL 7 IdM サーバーのインプレースアップグレードはサポートしていません。

このセクションでは、すべての Identity Management (IdM) のデータおよび設定を、RHEL (Red Hat Enterprise Linux) 7 サーバーから RHEL 8 サーバーへ 移行 する方法を説明します。

移行手順には、以下が含まれます。

  1. RHEL 8 IdM サーバーを設定し、現在の RHEL 7 IdM 環境にレプリカとして追加します。詳細は「RHEL 8 レプリカのインストール」を参照してください。
  2. RHEL 8 サーバーを認証局 (CA) 更新サーバーにする。詳細は「RHEL 8 IdM サーバーへの CA 更新サーバーロールの割り当て」を参照してください。
  3. RHEL 7 サーバーで証明書失効リスト (CRL) の生成を停止し、CRL 要求を RHEL 8 にリダイレクトする。詳細は「RHEL 7 IdM CA サーバーでの CRL 生成の停止」を参照してください。
  4. RHEL 8 サーバーで CRL の生成を開始する。詳細は「新しい RHEL 8 IdM CA サーバーでの CRL 生成の開始」を参照してください。
  5. 元の RHEL 7 CA 更新サーバーを停止して使用を中止する。詳細は「RHEL 7 サーバーの停止および使用停止」を参照してください。

手順では、以下を前提としています。

  • rhel8.example.com は、新しい CA 更新サーバーとなる RHEL 8 システムです。
  • rhel7.example.com は、元の RHEL 7 CA 更新サーバーです。マスター CA 更新サーバーである Red Hat Enterprise Linux 7 サーバーを特定するには、任意の IdM サーバーで次のコマンドを実行します。

    [root@rhel7 ~]# ipa config-show | grep "CA renewal"
    IPA CA renewal master: rhel7.example.com

    IdM デプロイメントに CA がない場合、RHEL 7 で実行している IdM サーバーは rhel7.example.com になります。

注記

IdM デプロイメントで組み込み認証局 (CA) しか使用する場合に限り、以下のセクションの手順を実行します。

30.1. RHEL 7 から 8 への IdM の移行の前提条件

rhel7.example.com で、以下を行います。

  1. システムを最新の RHEL 7 バージョンへアップグレードしている。
  2. ドメインのドメインレベルが 1 に設定されていることを確認します。詳細は、RHEL 7 の『Linux Domain Identity, Authentication, and Policy Guide』の「Displaying and Raising the Domain Level」を参照してください。
  3. ipa-* パッケージを最新バージョンへ更新している。

    [root@rhel7 ~]# yum update ipa-*
    警告

    複数の Identity Management (IdM) サーバーをアップグレードする場合は、各アップグレードの間隔は少なくとも 10 分あけてください。

    複数のサーバーで同時または間隔をあまりあけないでアップグレードを行うと、トポロジー全体でアップグレード後のデータ変更を複製する時間が足りず、複製イベントが競合する可能性があります。

rhel8.example.com で、以下を行います。

  1. 最新バージョンの Red Hat Enterprise Linux がシステムにインストールされている。詳細は『Performing a standard RHEL installation』を参照してください。
  2. システムが、rhel7.example.com IdM サーバーが権威のあるドメインに登録されている IdM クライアントであることを確認します。詳細は、IdM クライアントのインストール: 基本的なシナリオを参照してください。
  3. システムが IdM サーバーのインストールに関する要件を満たしていることを確認します。
  4. 時刻サーバー rhel7.example.com が以下と同期していることを確認します。

    [root@rhel7 ~]# ntpstat
    synchronised to NTP server (ntp.example.com) at stratum 3
       time correct to within 42 ms
       polling server every 1024 s
    重要

    RHEL 8 では IdM は独自の時刻サーバーを提供しません。つまり、rhel8.example.com に IdM をインストールしても、ホストに NTP サーバーはインストールされません。したがって、ntp.example.com などの別の NTP サーバーを使用する必要があります。詳細はMigrating to chronyおよびIdM のタイムサービス要件を参照してください。

    rhel7.example.com は NTP サーバーロールで使用できますが、移行プロセスの一環としてサーバーの使用を停止します。したがって、rhel8.example.com は、代わりに ntp.example.com と直接同期する必要があります。これは、インストールプロセス時に指定できます。

  5. システムで IdM レプリカのインストールが許可されていることを確認します。
  6. ipa-* パッケージを最新バージョンへ更新している。

    [root@rhel7 ~]# yum update ipa-*

関連情報

  • 新しい IdM プライマリーサーバー rhel8.example.com にインストールするサーバーロールを決定するには、以下のリンクを参照してください。

  • RHEL 8 で IdM の特定のサーバーロールをインストールするには、特定の IdM モジュールストリームからパッケージをダウンロードする必要があります(dM サーバーに必要なパッケージのインストール)。
  • システムを RHEL 7 から RHEL 8 にアップグレードするには、『Upgrading from RHEL 7 to RHEL 8』を参照してください。

30.2. RHEL 8 レプリカのインストール

  1. RHEL 7 環境に存在するサーバーの一覧を表示します。

    [root@rhel7 ~]# ipa server-role-find --status enabled --server rhel7.example.com
    ----------------------
    3 server roles matched
    ----------------------
      Server name: rhel7.example.com
      Role name: CA server
      Role status: enabled
    
      Server name: rhel7.example.com
      Role name: DNS server
      Role status: enabled
    
      Server name: rhel7.example.com
      Role name: NTP server
      Role status: enabled
    [... output truncated ...]
  2. (必要に応じて)rhel8.example.comrhel7.example.com が使用しているものと同じサーバーごとのフォワーダーを使用する場合は、rhel7.example.com のサーバーごとのフォワーダーを確認します。

    [root@rhel7 ~]# ipa dnsserver-show rhel7.example.com
    -----------------------------
    1 DNS server matched
    -----------------------------
      Server name: rhel7.example.com
      SOA mname: rhel7.example.com.
      Forwarders: 192.0.2.20
      Forward policy: only
    --------------------------------------------------
    Number of entries returned 1
    --------------------------------------------------
  3. IdM RHEL 7 サーバーのレプリカとして rhel8.example.com に IdM サーバーをインストールします。これには、NTP サーバーロールを除き、rhel7.example.com のサーバーロールをすべて含みます。上記の例からロールをインストールするには、ipa-replica-install コマンドで以下のオプションを使用します。

    • --setup-ca: Certificate System コンポーネントを設定する
    • --setup-dns および --forwarder:統合 DNS サーバーを設定し、IdM ドメインの外に出る DNS クエリーを処理するようにサーバーごとのフォワーダーを設定する

      注記

      また、IdM デプロイメントが Active Directory (AD) と信頼関係にある場合は、--setup-adtrust オプションを ipa-replica-install コマンドに追加し、rhel8.example.com に AD 信頼機能を設定します。

    • --ntp-server: NTP サーバーを指定する、または --ntp-pool: NTP サーバーのプールを指定する

      重要

      NTP サーバーを手動で指定しない場合は、DNS レコードから自動的に設定されます。これにより、rhel8.example.comrhel7.example.com と同期することになります。これにより、RHEL 7 サーバーが使用できなくなると問題が発生します。

      IP アドレスが 192.0.2.20 のサーバーごとのフォワーダーを使用し ntp.example.com NTP サーバーと同期する、IP アドレスが 192.0.2.1 の IdM サーバーを設定するには、次のコマンドを実行します。

      [root@rhel8 ~]# ipa-replica-install --setup-ca --ip-address 192.0.2.1 --setup-dns --forwarder 192.0.2.20 --ntp-server ntp.example.com

      DNS が正常に機能している場合は、rhel8.example.com が DNS の自動検出を使用してそれを見つけるため、RHEL 7 IdM サーバー自体を指定する必要はありません。

  4. 必要に応じて、外部NTP タイムサーバーの _ntp._udp サービス (SRV) レコードを、新しくインストールした IdM サーバーの DNS (rhel8.example.com) に追加します。RHEL 8 では IdM が独自の時刻サービスを提供しないため、この設定を行うことが推奨されます。IdM DNS に時刻サーバーの SRV レコードが存在すると、今後のRHEL 8レプリカおよびクライアントインストールが、rhel8.example.comが使用する時刻サーバーと同期するように自動的に設定されます。これは、--ntp-server または --ntp-pool オプションがインストールコマンドラインインターフェース(CLI)で指定されていない限り、ipa-client-install_ntp._udp DNS エントリーを検索するためです。

検証

  1. IdM サービスが rhel8.example.com で稼働していることを確認します。

    [root@rhel8 ~]# ipactl status
    Directory Service: RUNNING
    [... output truncated ...]
    ipa: INFO: The ipactl command was successful
  2. NTP サーバーロールを除き、rhel8.example.com のサーバーロールが、rhel7.example.com と同じであることを確認します。

    [root@rhel8 ~]$ kinit admin
    [root@rhel8 ~]$ ipa server-role-find --status enabled --server rhel8.example.com
    ----------------------
    2 server roles matched
    ----------------------
      Server name: rhel8.example.com
      Role name: CA server
      Role status: enabled
    
      Server name: rhel8.example.com
      Role name: DNS server
      Role status: enabled
  3. 必要に応じて、rhel7.example.comrhel8.example.com 間のレプリカ合意の詳細を表示します。

    [root@rhel8 ~]# ipa-csreplica-manage list --verbose rhel8.example.com
    Directory Manager password:
    
    rhel7.example.com
    last init status: None
    last init ended: 1970-01-01 00:00:00+00:00
    last update status: Error (0) Replica acquired successfully: Incremental update succeeded
    last update ended: 2019-02-13 13:55:13+00:00
  4. (必要に応じて)IdM デプロイメントが AD と信頼関係にある場合は、それが機能していることを確認します。

    1. Kerberos 設定を確認します
    2. rhel8.example.com で AD ユーザーの解決を試みます。

      [root@rhel8 ~]# id aduser@ad.domain
  5. rhel8.example.comNTP サーバーと同期されていることを確認します。

    [root@rhel8 ~]# chronyc tracking
    Reference ID    : CB00710F (ntp.example.com)
    Stratum         : 3
    Ref time (UTC)  : Tue Nov 16 09:49:17 2021
    [... output truncated ...]

30.3. RHEL 8 IdM サーバーへの CA 更新サーバーロールの割り当て

注記

IdM デプロイメントで組み込み認証局 (CA) を使用する場合にのみ、本セクションの手順を行います。

rhel8.example.com で、新しい CA 更新サーバーとして rhel8.example.com を設定します。

  1. CA サブシステム証明書の更新を処理するように rhel8.example.com を設定します。

    [root@rhel8 ~]# ipa config-mod --ca-renewal-master-server rhel8.example.com
      ...
      IPA masters: rhel7.example.com, rhel8.example.com
      IPA CA servers: rhel7.example.com, rhel8.example.com
      IPA NTP servers: rhel7.example.com, rhel8.example.com
      IPA CA renewal master: rhel8.example.com

    出力で更新が成功したことを確認します。

  2. rhel8.example.com で、証明書アップデータータスクを有効にします。

    1. /etc/pki/pki-tomcat/ca/CS.cfg 設定ファイルを開いて編集します。
    2. ca.certStatusUpdateInterval エントリーを削除するか、または適切な間隔(秒単位)に設定します。デフォルト値は 600 です。
    3. /etc/pki/pki-tomcat/ca/CS.cfg 設定ファイルを保存して閉じます。
    4. IdM サービスを再起動します。

      [user@rhel8 ~]$ ipactl restart
  3. rhel7.example.com で、証明書アップデータータスクを無効にします。

    1. /etc/pki/pki-tomcat/ca/CS.cfg 設定ファイルを開いて編集します。
    2. ca.certStatusUpdateInterval0 に変更するか、または以下のエントリーを追加します(存在しない場合)。

      ca.certStatusUpdateInterval=0
    3. /etc/pki/pki-tomcat/ca/CS.cfg 設定ファイルを保存して閉じます。
    4. IdM サービスを再起動します。

      [user@rhel7 ~]$ ipactl restart

30.4. RHEL 7 IdM CA サーバーでの CRL 生成の停止

注記

IdM デプロイメントで組み込み認証局 (CA) を使用する場合にのみ、本セクションの手順を行います。

本セクションでは、ipa-crlgen-manage コマンドを使用して、rhel7.example.com CA サーバーで証明書失効リスト (CRL) の生成を停止する方法を説明します。

前提条件

  • root としてログインしている。

手順

  1. 必要に応じて、rhel7.example.com が CRL を生成しているかどうかを確認します。

    [root@rhel7 ~]# ipa-crlgen-manage status
    CRL generation: enabled
    Last CRL update: 2019-10-31 12:00:00
    Last CRL Number: 6
    The ipa-crlgen-manage command was successful
  2. rhel7.example.com サーバー上で CRL の生成を停止します。

    [root@rhel7 ~]# ipa-crlgen-manage disable
    Stopping pki-tomcatd
    Editing /var/lib/pki/pki-tomcat/conf/ca/CS.cfg
    Starting pki-tomcatd
    Editing /etc/httpd/conf.d/ipa-pki-proxy.conf
    Restarting httpd
    CRL generation disabled on the local host. Please make sure to configure CRL generation on another master with ipa-crlgen-manage enable.
    The ipa-crlgen-manage command was successful
  3. 必要に応じて、rhel7.example.com サーバーが CRL の生成を停止しているかどうかを確認します。

    [root@rhel7 ~]# ipa-crlgen-manage status

rhel7.example.com サーバーが CRL の生成を停止しました。次の手順では、rhel8.example.com で CRL の生成を有効にします。

30.5. 新しい RHEL 8 IdM CA サーバーでの CRL 生成の開始

注記

IdM デプロイメントで組み込み認証局 (CA) を使用する場合にのみ、本セクションの手順を行います。

前提条件

  • rhel8.example.com マシンに root としてログインしている必要があります。

手順

  1. rhel8.example.com で CRL の生成を開始するには、ipa-crlgen-manage enable コマンドを使用します。

    [root@rhel8 ~]# ipa-crlgen-manage enable
    Stopping pki-tomcatd
    Editing /var/lib/pki/pki-tomcat/conf/ca/CS.cfg
    Starting pki-tomcatd
    Editing /etc/httpd/conf.d/ipa-pki-proxy.conf
    Restarting httpd
    Forcing CRL update
    CRL generation enabled on the local host. Please make sure to have only a single CRL generation master.
    The ipa-crlgen-manage command was successful
  2. CRL 生成が有効になっているかどうかを確認するには、ipa-crlgen-manage status コマンドを使用します。

    [root@rhel8 ~]# ipa-crlgen-manage status
    CRL generation: enabled
    Last CRL update: 2019-10-31 12:10:00
    Last CRL Number: 7
    The ipa-crlgen-manage command was successful

30.6. RHEL 7 サーバーの停止および使用停止

  1. 最新の変更を含むすべてのデータが rhel7.example.com から rhel8.example.com に正しく移行されていることを確認します。以下に例を示します。

    1. rhel7.example.com に新しいユーザーを追加します。

      [root@rhel7 ~]# ipa user-add random_user
      First name: random
      Last name: user
    2. ユーザーが rhel8.example.com に複製されていることを確認します。

      [root@rhel8 ~]# ipa user-find random_user
      --------------
      1 user matched
      --------------
        User login: random_user
        First name: random
        Last name: user
  2. rhel7.example.com 上の全 IdM サービスを停止して、新しい rhel8.example.com サーバーへのドメイン検索を実施します。

    [root@rhel7 ~]# ipactl stop
    Stopping CA Service
    Stopping pki-ca:                                           [  OK  ]
    Stopping HTTP Service
    Stopping httpd:                                            [  OK  ]
    Stopping MEMCACHE Service
    Stopping ipa_memcached:                                    [  OK  ]
    Stopping DNS Service
    Stopping named: .                                          [  OK  ]
    Stopping KPASSWD Service
    Stopping Kerberos 5 Admin Server:                          [  OK  ]
    Stopping KDC Service
    Stopping Kerberos 5 KDC:                                   [  OK  ]
    Stopping Directory Service
    Shutting down dirsrv:
        EXAMPLE-COM...                                         [  OK  ]
        PKI-IPA...                                             [  OK  ]

    この後に、ipa ユーティリティーを使用すると、Remote Procedure Call (RPC) で新規サーバーに接続します。

  3. RHEL 8 サーバーで削除コマンドを実行して、トポロジーから RHEL 7 サーバーを削除します。詳細は「IdM サーバーのアンインストール」を参照してください。

第31章 IdM の更新およびダウンロード

yum ユーティリティーを使用して、システムの Identity Management (IdM) パッケージを更新できます。

  • プロファイルに関連し、利用可能な更新がある IdM パッケージをすべて更新するには、次のコマンドを実行します。

    # yum upgrade ipa-*
    重要

    更新をインストールする前に、RHEL システムに関連するこれまでにリリース済みのエラータをすべて適用していることを確認します。

  • 有効になっているリポジトリーから、プロファイルで利用可能な最新バージョンに合わせて、パッケージをインストールまたは更新します。

    # yum distro-sync ipa-*

少なくとも 1 台のサーバーで IdM パッケージを更新すると、トポロジー内のその他のすべてのサーバーでパッケージを更新しなくても、更新されたスキーマを受け取ります。これは、新しいスキーマを使用する新しいエントリーを、その他のサーバー間で確実に複製できます。

警告

複数の IdM サーバーを更新する場合は、サーバーを更新してから別のサーバーを更新するまで、10 分以上お待ちください。ただし、サーバーの更新が成功するまでに必要な時間は、展開されたトポロジー、接続のレイテンシー、更新で生成した変更の数により異なります。

複数のサーバーで、同時、またはあまり間隔をあけずに更新を行うと、トポロジー全体でアップグレード後のデータ変更を複製する時間が足りず、複製イベントが競合する可能性があります。

IdM パッケージを手動でダウンロードすることはサポートされていません。yum distro-sync を使用して、モジュールのパッケージを更新およびダウンロードします。

重要

ipa-* パッケージで yum downgrade コマンドを実行しないでください。

関連情報

  • yum ユーティリティーの使用方法は、man ページの yum(8) を参照してください。

第32章 RHEL 7 から RHEL 8 への IdM クライアントのアップグレード

IdM サーバーとは異なり、IdM クライアントの RHEL 7 から RHEL 8 へのインプレースアップグレードはサポート対象です。

RHEL 8 では、IdM 環境の認証を担当するサービスである System Security Services Daemon (SSSD) から一般的でないオプションおよび未使用の機能が削除されました。これらのオプションを削除する手順については、以下のセクションを参照してください。

32.1. RHEL 8 へのアップグレード後の SSSD 設定の更新

Red Hat Enterprise Linux (RHEL) 7 から RHEL 8 に Identity Management (IdM) クライアントをアップグレードすると、アップグレードアプリケーション (leapp) が SSSD 設定オプションがサポート対象外になったことをを示す警告が表示されることがあります。

以下の手順では、これらの問題に対処するために SSSD 設定を更新する方法を説明します。

前提条件

  • IdM クライアントが RHEL 7 から RHEL 8 にアップグレードしている。
  • /etc/sssd/sssd.conf を編集する root 権限がある。

32.1.1. ローカル ID プロバイダーから ファイル ID プロバイダーへの切り替え

以下のエラーが表示される場合は、ローカル ID プロバイダーは ファイル ID プロバイダーに置き換えます。

SSSD Domain "example.com": local provider is no longer supported and the domain will be ignored.
Local provider is no longer supported.

手順

  1. ローカル ID プロバイダーで取得したユーザーおよびグループは、/etc/passwd/etc/group ファイルにも含まれていることを確認します。このファイルに存在していると、ファイル プロバイダーがユーザーおよびグループにアクセスできるようになります。

    1. ユーザーを作成する必要がある場合は、useradd コマンドを使用します。UID を指定する必要がある場合は、-u オプションを追加します。

      [root@client ~]# useradd -u 3001 username
    2. グループを作成する必要がある場合は、groupadd コマンドを使用します。GID を指定する必要がある場合は、-g オプションを追加します。

      [root@client ~]# groupadd -g 5001 groupname
  2. テキストエディターで /etc/sssd/sssd.conf 設定ファイルを開きます。
  3. id_provider=localid_provider=files に置き換えます。

    [domain/example.com]
    id_provider = files
    ...
  4. /etc/sssd/sssd.conf 設定ファイルを保存します。
  5. SSSD を再起動して、設定の変更を読み込みます。

    [root@client ~]# systemctl restart sssd

32.1.2. 非推奨のオプションの削除

非推奨のオプションに関する以下のエラーのいずれかが表示される場合は、このようなオプションを /etc/sssd/sssd.conf 設定ファイルからを削除することを推奨します。

SSSD Domain "example.com": option ldap_groups_use_matching_rule_in_chain has no longer any effect
Option ldap_groups_use_matching_rule_in_chain was removed and it will be ignored.
SSSD Domain "example.com": option ldap_initgroups_use_matching_rule_in_chain has no longer any effect
Option ldap_initgroups_use_matching_rule_in_chain was removed and it will be ignored.

手順

  1. テキストエディターで /etc/sssd/sssd.conf 設定ファイルを開きます。
  2. ldap_groups_use_matching_rule_in_chain または ldap_initgroups_use_matching_rule_in_chain オプションが存在する場合は削除します。
  3. /etc/sssd/sssd.conf 設定ファイルを保存します。
  4. SSSD を再起動して、設定の変更を読み込みます。

    [root@client ~]# systemctl restart sssd

32.1.3. sudo ルールでのワイルドカードの使用の有効化

以下の警告は、RHEL 8 のデフォルトでワイルドカードが含まれる sudo ルールは機能しないことを示します。これは、ldap_sudo_include_regexp オプションがデフォルトで false に設定されるようになったためです。

SSSD Domain "example.com": sudo rules containing wildcards will stop working.
Default value of ldap_sudo_include_regexp changed from true to false for performance reason.

sudo ルールでワイルドカードを使用して、ワイルドカードの検索を有効化する場合は、ldap_sudo_include_regexp オプションを true に設定してください。

注記

Red Hat では sudo ルールでワイルドカードを使用した検索の利用は推奨していません。

ldap_sudo_include_regexp オプションが true に設定されている場合には、SSSD は sudoHost 属性にワイルドカードが含まれるすべての sudo ルールをダウンロードするため、LDAP 検索パフォーマンスに悪影響があります。

手順

  1. テキストエディターで /etc/sssd/sssd.conf 設定ファイルを開きます。
  2. example.com ドメインで ldap_sudo_include_regexp=true と設定します。

    [domain/example.com]
    ...
    ldap_sudo_include_regexp = true
    ...
  3. /etc/sssd/sssd.conf 設定ファイルを保存します。
  4. SSSD を再起動して、設定の変更を読み込みます。

    [root@client ~]# systemctl restart sssd

32.2. RHEL 8 で削除された SSSD 機能の一覧

以下の SSSD 機能は、RHEL 8 では削除されました。

ローカル ID プロバイダーが削除される
ローカル SSSD キャッシュからユーザー情報を提供していた ローカル ID プロバイダーが RHEL 7 で非推奨になり、RHEL 8 でサポート対象外になりました。/etc/sssd/sssd.conf 設定でドメインが id_provider=local に指定されている場合には、SSSD はこのドメインを無視して通常どおりに起動します。
ローカル ドメインのユーザーおよびグループを管理するコマンドラインツールが削除される

ローカル ドメインだけが対象の以下のコマンドが削除されました。

  • sss_useradd
  • sss_userdel
  • sss_groupadd
  • sss_groupdel
ldap_groups_use_matching_rule_in_chain オプションのサポートが削除される
この Active Directory 固有のオプションは、パフォーマンスに好影響がないので、RHEL 8 sssd.conf 設定では無視されます。
ldap_initgroups_use_matching_rule_in_chain オプションのサポートが削除される
この Active Directory 固有のオプションは、パフォーマンスに好影響がないので、RHEL 8 sssd.conf 設定では無視されます。
ldap_sudo_include_regexp オプションがデフォルトで false に設定されるように
RHEL 7 では、このオプションはデフォルトで true に設定されていました。このオプションが true に設定されている場合には、SSSD は sudoHost 属性にワイルドカードが含まれるすべての sudo ルールをダウンロードするため、LDAP 検索パフォーマンスに悪影響があります。
sssd-secrets レスポンダーが削除される
Kerberos Cache Manager (KCM) は sssd-secrets レスポンダーに依存しなくなり、他の IdM プロセスで使用されないため、削除されました。

32.3. 関連情報

パート IV. 外部ソースから IdM への移行

第33章 LDAP ディレクトリーから IdM への移行

ID および認証ルックアップ用に LDAP サーバーをデプロイしている場合は、ルックアップサービスを Identity Management (IdM) に移行できます。IdM では、以下のタスクに役立つ移行ツールを利用できます。

  • データを失うことなく、パスワードやグループメンバーシップなどのユーザーアカウントを転送するタスク。
  • クライアントで高価な設定更新を回避するタスク。

ここで説明する移行プロセスは、LDAP に 1 つ、IdM に 1 つの名前空間がある単純な導入シナリオを想定しています。複数の名前空間やカスタムスキーマがある場合など、より複雑な環境については、Red Hat サポートサービスにお問い合わせください。

33.1. LDAP から IdM への移行に関する考慮事項

LDAP サーバーから Identity Management (IdM) に移行するプロセスには、以下の段階があります。

  • クライアントの移行このステージは慎重に計画してください。現在のインフラストラクチャーの各クライアントが使用するサービスを判断します。これには、Kerberos や Systems Security Services Daemon (SSSD) などが含まれます。次に、最終的な IdM デプロイメントで使用できるサービスを決定します。詳細は、Planning the client configuration when migrating from LDAP to IdM を参照してください。
  • データ の移行
  • パスワード の移行このステージは慎重に計画してください。IdM では、パスワードのほかに、すべてのユーザーアカウントに Kerberos ハッシュが必要です。パスワードに関する考慮事項と移行パスの一部は、Planning password migration when migrating from LDAP to IdM で説明しています。

最初にサーバー部分を移行してからクライアントを移行するか、または最初にクライアントを移行してからサーバーを移行することができます。2 つのタイプの移行の詳細は、LDAP to IdM migration sequence を参照してください。

重要

実際に LDAP 環境の移行に入る前に、LDAP のテスト環境を設定して移行プロセスを検証することを強く推奨します。環境をテストする場合は、以下を行います。

  1. IdM でテストユーザーを作成し、移行したユーザーの出力を、テストユーザーの出力と比較します。移行したユーザーに、テストユーザーに存在する属性およびオブジェクトクラスの最小セットが含まれていることを確認します。
  2. IdM にあるように、移行したユーザーの出力を、元の LDAP サーバーにあるように、ソースユーザーと比較します。インポートされた属性が2回コピーされていないこと、およびそれらが正しい値を持っていることを確認してください。

33.2. LDAP から IdM への移行時のクライアント設定の計画

Identity Management は、さまざまなレベルの機能性、柔軟性、安全性で多数の異なるクライアント設定に対応することができます。オペレーティングシステムと、IT メンテナンスの優先度に基づいて、各クライアントに最適な設定を決定します。クライアントの機能領域も考慮してください。開発マシンは通常、実稼働サーバーやユーザーラップトップとは異なる設定を必要とします。

重要

ほとんどの環境では、クライアントが IdM ドメインに接続する方法が混在しています。管理者は各クライアント別に最適となるシナリオを決定しなければなりません。

33.2.1. 初期の移行前のクライアント設定

Identity Management (IdM) でクライアント設定の詳細を決定する前に、現在の移行前設定の詳細を確立します。

移行予定の LDAP デプロイメントの初期の状態の場合、ほとんど全てに ID および認証サービスを提供している LDAP サービスがあります。

図33.1 基本的な LDAP ディレクトリーとクライアント設定

IPA 移行の初期状態

Linux および Unix のクライアントは PAM_LDAP と NSS_LDAP ライブラリーを使って、LDAP サービスに直接接続します。これらのライブラリーにより、クライアントは、/etc/passwd または /etc/shadow にデータが格納されているかのように LDAP ディレクトリーからユーザー情報を取得できます。現実的には ID 検索に LDAP、認証に Kerberos や別の設定を使用している場合など、インフラストラクチャーはもう少し複雑になる場合があります。

LDAP ディレクトリーと Identity Management (IdM) サーバーの間には、特にスキーマサポートとディレクトリーツリーに構造的な違いがあります。これらの相違に関する詳細な背景は、Contrasting IdM with a Standard LDAP Directory を参照してください。このような相違は、特にディレクトリーツリーのデータに影響を及ぼし、エントリー名に影響を及ぼします。ただし、この相違はクライアントの設定、およびクライアントの IdM への移行にはほとんど影響を及ぼしません。

33.2.3. 推奨設定以外で対応している設定

Mac、Solaris、HP-UX、AIX、Scientific Linux などの Unix および Linux システムでは IdM で管理されるすべてのサービスに対応していますが SSSD は使用しません。同様に、古い Red Hat Enterprise Linux (RHEL) バージョン (特に 6.1 および 5.6) は SSSD に対応していますが、IdM を ID プロバイダーとしてサポートしていない古いバージョンがあります。

システムで最新バージョンの SSSD を使用できない場合は、以下の方法でクライアントを設定できます。

  • クライアントは、nss_ldap を使用して、ID 検索で LDAP ディレクトリーサーバーであるかのように IdM サーバーに接続します。
  • クライアントは、pam_krb5 を使用して、通常の Kerberos KDC であるかのように IdM サーバーに接続します。

IdM サーバーを ID プロバイダーおよび Kerberos 認証ドメインとして使用するように古いバージョンの SSSD を持つ RHEL クライアントを設定する方法は、RHEL 7 System-Level Authentication GuideConfiguring identity and authentication providers for SSSD セクションを参照してください。

図33.3 LDAP および Kerberos を使用するクライアントおよび IdM

migr ldap

一般的には、クライアントで可能な限り安全な設定を使用することがベストプラクティスとなります。これは、ID の SSSD または LDAP、および認証の Kerberos を意味します。ただし、メンテナンス状況や IT 構造によっては、最も単純な例 (クライアントで nss_ldap ライブラリーおよび pam_ldap ライブラリーを使用して ID と認証の両方を提供するように LDAP を設定) に頼る必要があります。

33.3. LDAP から IdM への移行時のパスワードの移行の計画

ユーザーを LDAP から Identity Management (IdM) に移行する前に決定すべき重大な問題は、ユーザーパスワードを移行するかどうかです。以下のタイプが使用できます。

パスワードを使用しないユーザーの移行

より迅速に実行できますが、管理者とユーザーによるより多くの手作業が必要です。特定の状況では、これが唯一の選択肢となります (元の LDAP 環境にクリアテキストのユーザーパスワードが保存されている 場合やパスワードが IdM で定義されているパスワードポリシーの要件を満たしていない 場合など)。

パスワードを使用せずにユーザーアカウントを移行する場合は、すべてのユーザーパスワードをリセットします。移行したユーザーには、最初のログイン時に変更する一時パスワードが割り当てられます。パスワードのリセット方法は、Changing and resetting user passwords を参照してください。

パスワードを使用したユーザーの移行

移行はよりスムーズになりますが、移行および移行プロセスで LDAP ディレクトリーと IdM を並列に管理することも必要になります。これは、IdM がデフォルトで認証に Kerberos を使用し、各ユーザーには、標準ユーザーパスワードのほかに、IdM Directory Server に保存されている Kerberos ハッシュが必要であるためです。このハッシュを生成するには、IdM サーバー側でユーザーのパスワードがクリアテキストで利用可能である必要があります。新しいユーザーパスワードを作成すると、パスワードはハッシュされて IdM に保存される前に、クリアテキストで利用できるようになります。ただし、ユーザーを LDAP ディレクトリーから移行する場合には関連するユーザーパスワードがすでにハッシュ化されているため該当する Kerberos キーは生成できません。

重要

デフォルトでは、ユーザーアカウントが存在しても、Kerberos ハッシュが発生するまで、ユーザーは IdM ドメインに認証したり、IdM リソースにアクセスしたりできません。回避策の 1 つが利用できます。Kerberos 認証の代わりに、IdM で LDAP 認証を使用します。この回避策では、ユーザーに Kerberos ハッシュは必要ありません。ただし、この回避策により IdM の機能が制限されるため、推奨できません。

ユーザーは、パスワードを使用して移行できます。

33.3.1. Methods for migrating passwords when migrating LDAP to IdM

ユーザーにパスワードの変更を強制せずに、ユーザーアカウントを LDAP から Identity Management (IdM) に移行するには、以下の方法を使用できます。

方法 1: 移行 Web ページの使用

ユーザーに、IdM Web UI (https://ipaserver.example.com/ipa/migration) のスペシャルページに LDAP 認証情報を一度入力するように指示します。バックグラウンドで実行しているスクリプトが、クリアテキストパスワードをキャプチャーして、パスワードと適切な Kerberos ハッシュを使用してユーザーアカウントを適切に更新します。

方法 2 (推奨) - SSSD の使用

SSSD (System Security Services Daemon) を使用して必要なユーザーキーを生成することで、移行によるユーザーへの影響を軽減します。大量のユーザーを導入する場合やユーザーにパスワード変更の面倒をかけさせない場合に最適なシナリオです。

ワークフロー

  1. ユーザーが SSSD でマシンにログインします。
  2. SSSD は、IdM サーバーに対して Kerberos 認証の実行を試みます。
  3. ユーザーがシステムに存在していも Kerberos ハッシュがないため key type is not supported エラーで認証に失敗します。
  4. SSSD は、セキュアな接続でプレーンテキストの LDAP バインドを実行します。
  5. IdM はこのバインド要求をインターセプトします。ユーザーが Kerberos プリンシパルは持っているのに Kerberos ハッシュを持っていない場合、IdM ID プロバイダーはハッシュを生成してユーザーのエンティティーに格納します。
  6. 認証に成功すると SSSD は IdM との接続を切断し Kerberos 認証を再試行します。この場合、エンティティーにハッシュが存在しているため要求は成功します。

方法 2 では、ユーザーにはプロセス全体が表示されません。ユーザーは、パスワードが LDAP から IdM に移動したことに気が付かずにクライアントサービスにログインします。

33.3.2. Planning the migration of cleartext LDAP passwords

ほとんどのデプロイメントでは暗号化された LDAP パスワードが格納されますが、ユーザーまたは環境によってユーザーエンティティーにクリアテキストのパスワードが使用される場合があります。

ユーザーを LDAP サーバーから IdM サーバーに移行する場合、IdM ではクリアテキストパスワードが許可されていないため、クリアテキストパスワードは移行されません。代わりに、Kerberos プリンシパルがユーザーごとに作成され、キータブは true に設定されます。また、パスワードは期限が切れたときに設定されます。つまり、IdM では、次回のログイン時にユーザーがパスワードをリセットする必要があります。詳細は、Planning the migration of LDAP passwords that do not meet the IdM requirements を参照してください。

33.3.3. Planning the migration of LDAP passwords that do not meet the IdM requirements

元のディレクトリーのユーザーパスワードが、Identity Management (IdM) で定義されているパスワードポリシーに一致しない場合、そのパスワードは移行後に無効になります。

パスワードのリセットは、ユーザーが kinit と入力して IdM ドメイン内の Kerberos チケット付与チケット (TGT) を最初に取得しようとするときに自動的に行われます。ユーザーはパスワードの変更を強制されます。

[migrated_idm_user@idmclient ~]$ kinit
Password for migrated_idm_user@IDM.EXAMPLE.COM:
Password expired.  You must change it now.
Enter new password:
Enter it again:

33.4. 移行における考慮事項と要件

LDAP サーバーから Identity Management (IdM) への移行を計画している場合は、LDAP 環境が IdM の移行スクリプトで機能できることを確認してください。

33.4.1. 移行に対応している LDAP サーバー

LDAP サーバーから Identity Management への移行プロセスは、特別なスクリプト ipa migrate-ds を使用して移行を実行します。このスクリプトには、LDAP ディレクトリーと LDAP エントリーの構造に関する特定の要件があります。移行に対応しているのは複数の共通ディレクトリーを含む LDAPv3 準拠のディレクトリーサービスのみになります。

  • Sun ONE Directory Server
  • Apache Directory Server
  • OpenLDAP

LDAP サーバーから IdM への移行は、Red Hat Directory Server および OpenLDAP でテストされています。

注記

Microsoft Active Directory の場合、移行用スクリプトを使った移行には対応していません。これは、LDAPv3-コンプライアントディレクトリーではないためです。Active Directory からの移行については、Red Hat Professional Services にお問い合わせください。

33.4.2. 移行のための LDAP 環境要件

LDAP サーバーと Identity Management (IdM) にはさまざまな設定シナリオが存在し、これが移行プロセスの円滑さに影響します。本章で説明している移行例の場合、以下に示すような環境を想定しています。

  • 1 つの LDAP ディレクトリードメインが、1 つの IdM レルムに移行中です。統合はありません。
  • ユーザーパスワードは、LDAP ディレクトリーにハッシュ形式で保存されます。対応しているハッシュの一覧は、Red Hat Directory Server Documentation の Red Hat Directory Server 10 で利用可能な Configuration, Command, and File Reference タイトルの Password Storage Schemes セクションを参照してください。
  • LDAP ディレクトリーインスタンスは ID 格納および認証方法の両方になります。クライアントマシンは、pam_ldap または nss_ldap を使用して LDAP サーバーに接続するように設定されます。
  • エントリーは標準の LDAP スキーマのみを使用します。カスタムオブジェクトクラスまたはカスタム属性を含むエントリーは、IdM に移行されません。
  • migrate-ds は、以下のアカウントのみを移行します。

    • gidNumber 属性を含むもの。この属性は、posixAccount オブジェクトクラスに必要です。
    • sn 属性を含むもの。この属性は、person オブジェクトクラスに必要です。

33.4.3. 移行のための IdM システム要件

中程度のサイズのディレクトリー (約 10,000 ユーザー、および 10 グループ) では、移行を続行するのに十分な強力なターゲット IdM システムが必要です。移行の最小要件は以下のとおりです。

  • 4 コア
  • 4 GB のメモリー
  • 30GB のディスク領域
  • 2MB の SASL バッファサイズ。これは IdM サーバーのデフォルトです。

    移行エラーが発生した場合は、バッファーサイズを大きくします。

    [root@ipaserver ~]# ldapmodify -x -D 'cn=directory manager' -w password -h ipaserver.example.com -p 389
    
    dn: cn=config
    changetype: modify
    replace: nsslapd-sasl-max-buffer-size
    nsslapd-sasl-max-buffer-size: 4194304
    
    modifying entry "cn=config"

    nsslapd-sasl-max-buffer-size をバイト単位で設定します。

33.4.4. sudo ルールに関する考慮事項

LDAP で sudo を使用している場合は、LDAP に保存されているsudoルールを Identity Management (IdM) に手動で移行する必要があります。Red Hat では、IdM のネットグループをホストグループとして再作成することを推奨しています。IdM は、SSSD sudoプロバイダーを使用しないsudo設定で、従来のネットグループとしてホストグループを自動的に表示します。

33.4.5. LDAP から IdM への移行ツール

LDAP ディレクトリーのデータが正しくフォーマット化され、ldM サーバーに適切にインポートされるように、Identity Management (IdM) は特定の ipa migrate-ds コマンドを使って移行プロセスを進めます。ipa migrate-ds を使用する場合は、--bind-dn オプションで指定するリモートシステムユーザーに、userPassword 属性への読み取りアクセスが必要です。読み取りアクセスがないと、パスワードが移行されません。

Identity Management サーバーは移行モードで実行するように設定してから、移行スクリプトを使用することができます。詳しくは、Migrating an LDAP server to IdMを参照してください。

33.4.6. LDAP から IdM への移行パフォーマンスの改善

LDAP の移行は、基本的には、IdM サーバー内の 389 Directory Server (DS) インスタンスに対する特殊なインポート操作です。インポート操作のパフォーマンスを向上させるために、389 DS インスタンスをチューニングすると、移行パフォーマンス全体を改善できます。

インポートのパフォーマンスに直接影響を与えるパラメーターは、以下の 2 つです。

  • nsslapd-cachememsize 属性。エントリーキャッシュに使用できるサイズを定義します。これは、キャッシュメモリーの合計サイズの 80% に自動的に設定されるバッファーです。大規模なインポート操作の場合は、このパラメーターを増やし、メモリーキャッシュ自体も増やすことができます。これにより、多数のエントリーや、大きな属性を持つエントリーを処理する際に、ディレクトリーサービスの効率が向上します。

    dsconf コマンドを使用して属性を変更する方法の詳細は、Adjusting the entry cache size を参照してください。

  • システムulimit設定オプションは、システムユーザーに許可されるプロセスの最大数を設定します。大規模なデータベースの処理が制限を超える可能性があります。これが発生した場合は、値を上げます。

    [root@server ~]# ulimit -u 4096

33.4.7. LDAP から IdM への移行シーケンス

IdM に移行する場合は、主に 4 つの手順がありますが、順序は、サーバークライアント のどちらを最初に移行するかによって異なります。

重要

クライアントファーストおよびサーバーファーストの両方の移行では、一般的な移行手順が提供されますが、すべての環境で機能するとは限りません。実際の LDAP 環境を移行する前に、テスト用の LDAP 環境を設定して移行プロセスの検証を行ってください。

クライアントファースト移行

SSSD は、Identity Management (IdM) サーバーが設定される際に、クライアント設定を変更するために使用されます。

  1. SSSD をディプロイします。
  2. クライアントが現在の LDAP サーバーに接続し IdM にフェールオーバーするよう再設定を行います。
  3. IdM サーバーをインストールします。
  4. IdM ipa migrate-ds スクリプトを使用してユーザーデータを移行します。これによりデータが LDAP ディレクトリーからエクスポートされ、IdM スキーマ用にフォーマット化されて IdM にインポートされます。
  5. LDAP サーバーをオフラインにし、クライアントが IdM に透過的にフェイルオーバーできるようにします。
サーバーファースト移行

LDAP から IdM への移行が最初に行われます。

  1. IdM サーバーをインストールします。
  2. IdM ipa migrate-ds スクリプトを使用してユーザーデータを移行します。これによりデータが LDAP ディレクトリーからエクスポートされ、IdM スキーマ用にフォーマット化されて IdM にインポートされます。
  3. オプション:SSSD をディプロイします。
  4. クライアントが IdM に接続するよう再設定を行います。LDAP サーバーと単純に差し替えることはできません。IdM ディレクトリーツリー (およびユーザーエントリーの DN) は以前のディレクトリーツリーとは異なります。

    クライアントの再設定は必要ですが、直ちに再設定を行う必要はありません。更新したクライアントは IdM サーバーをポイントし、他のクライアントは旧 LDAP ディレクトリーをポイントするためデータ移植後に適度なテストと移行段階を持たせることができます。

    注記

    LDAP ディレクトリーと IdM サーバーを長期に渡っては並行稼動させないでください。2 つのサービス間でユーザーデータの整合性が失われる危険を招くことになります。

33.5. LDAP から IdM への移行のカスタマイズ

ipa migrate-ds コマンドを使用して、LDAP サーバーから Identity Management (IdM) に認証サービスと認可サービスを移行できます。一番単純な例では移行するディレクトリーの LDAP URL を取得し、共通デフォルト設定をもとにデータをエクスポートします。

別の ipa migrate-ds コマンドオプションを使用すると、移行プロセスをカスタマイズし、データの識別およびエクスポート方法をカスタマイズできます。LDAP ディレクトリーツリーに一意の構造がある場合、またはエントリー内の特定のエントリーまたは属性を除外する必要がある場合は、移行をカスタマイズします。

33.5.1. LDAP から IdM への移行時にバインド DN およびベース DN をカスタマイズする例

ipa migrate-ds コマンドを使用して、LDAP から Identity Management (IdM) に移行します。一番単純な例では移行するディレクトリーの LDAP URL を取得し、共通デフォルト設定をもとにデータをエクスポートします。このセクションでは、デフォルト設定の変更例を説明します。

# ipa migrate-ds ldap://ldap.example.com:389
バインド DN のカスタマイズ

デフォルトでは、DN "cn=Directory Manager" は、リモート LDAP ディレクトリーにバインドするために使用されます。--bind-dn オプションを使用して、カスタムバインド DN を指定します。

# ipa migrate-ds ldap://ldap.example.com:389 --bind-dn=cn=Manager,dc=example,dc=com
命名コンテキストのカスタマイズ

LDAP サーバーの命名コンテキストが IdM で使用されているものと異なる場合は、オブジェクトのベース DN が変換されます。たとえば、uid=user,ou=people,dc=ldap,dc=example,dc=com は、uid=user,ou=people,dc=idm,dc=example,dc=com に移行されます。--base-dn を使用して、コンテナーサブツリーのターゲットを変更し、移行にリモート LDAP サーバーで使用するベース DN を設定できます。

# ipa migrate-ds --base-dn="ou=people,dc=example,dc=com" ldap://ldap.example.com:389

関連情報

  • ipa migrate-ds --help

33.5.2. 特定のサブツリーの移行

デフォルトのディレクトリー構造の場合、人のエントリーは ou=People サブツリーに配置され、グループのエントリーは ou=Groups サブツリーに配置されます。こうしたサブツリーは異なるタイプのディレクトリーデータ用のコンテナーエントリーになります。migrate-ds コマンドでオプションが渡されていない場合、ユーティリティーは、指定の LDAP ディレクトリーが ou=People および ou=Groups 構造を使用していることを前提とします。

多くのデプロイメントは完全に異なるディレクトリー構造をしている場合があります。または、元のディレクトリーツリーの特定部分のみをエクスポートする場合もあります。管理者は、以下のオプションを使用して、ソース LDAP サーバーの別のユーザーまたはグループのサブツリーの RDN を指定できます。

  • --user-container
  • --group-container
注記

いずれの場合も、サブツリーは相対識別名 (RDN) でなければならず、ベース DN に相対的である必要があります。たとえば、--user-container=ou=Employees を使用して、>ou=Employees,dc=example,dc=com ディレクトリーツリーを移行できます。

以下に例を示します。

[ipaserver ~]# ipa migrate-ds --user-container=ou=employees \
--group-container="ou=employee groups" ldap://ldap.example.com:389

必要に応じて、--scope オプションを ipa migrate-ds コマンドに追加して、スコープを設定します。

  • onelevel: デフォルト。指定したコンテナーのエントリーのみが移行されます。
  • subtree: 指定したコンテナーおよびすべてのサブコンテナーのエントリーが移行されます。
  • base: 指定されたオブジェクト自体のみが移行されます。

33.5.3. エントリーの追加と除外

デフォルトでは、ipa migrate-ds スクリプトは、person オブジェクトクラスを持つすべてのユーザーエントリーと、groupOfUniqueNames オブジェクトクラスまたは groupOfNames オブジェクトクラスを持つすべてのグループエントリーをインポートします。

一部の移行パスでは、特定のタイプのユーザーとグループのみをエクスポートする必要がある場合や、あるいは特定のユーザーとグループを除外する必要がある場合があります。ユーザーまたはグループのエントリーを検索する際に、検索するオブジェクトクラスを設定することで、含めるユーザーとグループのタイプを選択できます。

このオプションは、さまざまなユーザータイプにカスタムオブジェクトクラスを使用する場合にとりわけ役立ちます。たとえば、次のコマンドは、カスタムfullTimeEmployee オブジェクトクラスを持つユーザーのみを移行します。

[root@ipaserver ~]# ipa migrate-ds --user-objectclass=fullTimeEmployee ldap://ldap.example.com:389

グループの種類が異なるため、これは、ユーザーグループなどの特定の種類のグループのみを移行し、証明書グループなどの他の種類のグループを除外する場合にも非常に役立ちます。以下に例を示します。

[root@ipaserver ~]# ipa migrate-ds --group-objectclass=groupOfNames --group-objectclass=groupOfUniqueNames ldap://ldap.example.com:389

オブジェクトクラスに基づいて移行するユーザーとグループのエントリを指定すると、他のすべてのユーザーとグループが移行から暗黙的に除外されます。

また、ごく少数のエントリー以外、すべてのユーザーとグループのエントリーを移行する場合にも便利です。そのタイプの他のすべてを移行するときに、特定のユーザーまたはグループアカウントを除外できます。たとえば、これは趣味のグループと 2 人のユーザーのみを除外します。

[root@ipaserver ~]# ipa migrate-ds --exclude-groups="Golfers Group" --exclude-users=idmuser101 --exclude-users=idmuser102 ldap://ldap.example.com:389

exclude ステートメントは、uid でパターンに一致するユーザーと、cn 属性でパターンに一致するグループに適用されます。

一般的なオブジェクトクラスを移行できますが、そのクラスの特定のエントリーは除外できます。たとえば、これには特に fullTimeEmployee オブジェクトクラスを持つユーザーが含まれますが、3 つのマネージャーは除外されます。

[root@ipaserver ~]# ipa migrate-ds --user-objectclass=fullTimeEmployee --exclude-users=jsmith --exclude-users=bjensen --exclude-users=mreynolds ldap://ldap.example.com:389

33.5.4. エントリー属性の除外

デフォルトではユーザーやグループエントリーのすべての属性とオブジェクトクラスが移行されます。特定のシナリオでは、帯域幅とネットワークの制約のため、または属性データが関連しなくなったために、これは現実的ではない場合があります。たとえば、ユーザーが Identity Management (IdM) ドメインに参加する際に新しいユーザー証明書が割り当てられる場合は、userCertificate 属性を移行しても意味がありません。

migrate-ds コマンドで以下のオプションを使用すると、特定のオブジェクトクラスおよび属性を無視できます。

  • --user-ignore-objectclass
  • --user-ignore-attribute
  • --group-ignore-objectclass
  • --group-ignore-attribute

たとえば、ユーザーの userCertificate 属性および strongAuthenticationUser オブジェクトクラスとグループの groupOfCertificates オブジェクトクラスを除外するには、次のコマンドを実行します。

[root@ipaserver ~]# ipa migrate-ds --user-ignore-attribute=userCertificate --user-ignore-objectclass=strongAuthenticationUser --group-ignore-objectclass=groupOfCertificates ldap://ldap.example.com:389
注記

必要な属性が無視されていないか必ず確認します。また、オブジェクトクラスを除外する場合は、そのオブジェクトクラスのみがサポートする属性を必ず除外してください。

33.5.5. LDAP から IdM への移行時に使用するスキーマとスキーマ互換機能

Identity Management (IdM) は、RFC2307bis スキーマを使用して、ユーザー、ホスト、ホストグループ、およびその他のネットワーク ID を定義します。ただし、移行のソースとして使用する LDAP サーバーが、代わりに RFC2307 スキーマを使用する場合は、ipa migrate-ds コマンドで --schema オプションを指定します。

[root@ipaserver ~]# ipa migrate-ds --schema=RFC2307 ldap://ldap.example.com:389

また、IdM には組み込みのスキーマの互換機能 があるため、RFC2307bis に対応していないシステムのデータを IdM が再フォーマットできます。compat プラグインはデフォルトで有効になっています。つまり、ディレクトリーサーバーは、ユーザーとグループの代替ビューを計算し、cn=users,cn=compat,dc=example,dc=com コンテナーエントリーにこのビューを提供します。これは、システムの起動時にエントリーの内容を事前に計算して、必要に応じてエントリーを更新することで行われます。

システムのオーバーヘッドを低減するために、この機能は移行中に無効にすることが推奨されます。

33.6. LDAP サーバーの IdM への移行

ipa migrate-ds コマンドを使用して、LDAP サーバーから Identity Management (IdM) に認証サービスと認可サービスを移行できます。

警告

この例は一般的な移行手順のため、あらゆる環境に対応するわけではありません。

実際に LDAP 環境の移行に入る前に、LDAP のテスト環境を設定して移行プロセスを検証することを強く推奨します。環境をテストする場合は、以下を行います。

  1. IdM でテストユーザーを作成し、移行したユーザーの出力を、テストユーザーの出力と比較します。
  2. IdM にあるように、移行したユーザーの出力を、元の LDAP サーバーにあるように、ソースユーザーと比較します。

詳細なガイダンスは、以下の 検証 のセクションを参照してください。

前提条件

手順

  1. IdM がインストールされていない場合: 既存の LDAP ディレクトリーがインストールされているマシンとは別のマシンに、IdM サーバー (カスタム LDAP ディレクトリースキーマを含む) をインストールします。詳細は、Installing Identity Management を参照してください。

    注記

    カスタムユーザースキーマまたはカスタムグループスキーマの IdM でのサポートは限られています。互換性のないオブジェクト定義があると、移行中に問題が発生する可能性があります。

  2. パフォーマンスの理由から、互換性プラグインを無効にします。

    # ipa-compat-manage disable

    スキーマ互換性機能の詳細と、移行時にスキーマ互換性機能を無効にする利点は、The schema to use when migrating from LDAP to IdM and the schema compat feature を参照してください。

  3. IdM Directory Server インスタンスを再起動します。

    # systemctl restart dirsrv.target
  4. IdM サーバーが移行を許可できるように設定します。

    # ipa config-mod --enable-migration=TRUE

    --enable-migration を TRUE に設定すると、以下のようになります。

    • LDAP の追加操作時に、ハッシュ前のパスワードを許可します。
    • 初期 Kerberos 認証に失敗した場合に、パスワードの移行シーケンスを試行するように SSSD を設定します。詳細は、Using SSSD when migrating passwords from LDAP to IdM の Workflow セクションを参照してください。
  5. ユースケースに応じたオプションを指定して、IdM 移行スクリプト ipa migrate-ds を実行します。詳細は、Customizing the migration from LDAP to IdM を参照してください。

    # ipa migrate-ds --your-options ldap://ldap.example.com:389
    注記

    上記のいずれかの手順で compat プラグインを無効にしなかった場合は、--with-compat オプションを ipa migrate-ds に追加します。

    # ipa migrate-ds --your-options --with-compat ldap://ldap.example.com:389
  6. 互換性プラグインを再度有効にします。

    # ipa-compat-manage enable
  7. IdM Directory Server を再起動します。

    # systemctl restart dirsrv.target
  8. すべてのユーザーのパスワードが移行したら、移行モードを無効にします。

    # ipa config-mod --enable-migration=FALSE
  9. [オプション] すべてのユーザーが移行されたら、非 SSSD クライアントを再設定して、LDAP認証(pam_ldap)ではなくKerberos認証(pam_krb5)を使用します。詳細は、System-level Authentication Guide の Configuring a Kerberos Client を参照してください。
  10. ユーザーにハッシュされた Kerberos パスワードを生成させます。Planning password migration when migrating from LDAP to IdM で説明されている方法のいずれかを選択します。

    • SSSD メソッドを決定した場合は、以下を行います。

      • SSSD がインストールされているクライアントを、LDAP ディレクトリーから IdM ディレクトリーに移動し、IdM でクライアントとして登録します。これにより必要なキーと証明書がダウンロードされます。

        Red Hat Enterprise Linux クライアントでは、この ipa-client-install コマンドを使用して実行できます。以下に例を示します。

        # ipa-client-install --enable-dns-update
    • IdM 移行 Web ページ メソッドを決定した場合は、以下を行います。

      • 移行 Web ページを使用して IdM にログインするようにユーザーに指示します。

        https://ipaserver.example.com/ipa/migration
  11. ユーザーの移行プロセスを監視するには、パスワードは持っているが Kerberos プリンシパルキーはまだないユーザーアカウントを表示するよう既存の LDAP ディレクトリーに問い合わせます。

    $ ldapsearch -LL -x -D 'cn=Directory Manager' -w secret -b 'cn=users,cn=accounts,dc=example,dc=com' '(&(!(krbprincipalkey=))(userpassword=))' uid
    注記

    フィルターの前後に一重引用符を付けてシェルで解釈されないようにします。

  12. クライアントとユーザーすべての移行が完了したら LDAP ディレクトリーを廃止します。

検証

  1. ipa user-add を使用して、IdM にテストユーザーを作成します。移行したユーザーの出力を、テストユーザーの出力と比較します。移行したユーザーに、テストユーザーに存在する属性およびオブジェクトクラスの最小セットが含まれていることを確認します。以下に例を示します。

    $ ipa user-show --all testing_user
    dn: uid=testing_user,cn=users,cn=accounts,dc=idm,dc=example,dc=com
    User login: testing_user
    First name: testing
    Last name: user
    Full name: testing user
    Display name: testing user
    Initials: tu
    Home directory: /home/testing_user
    GECOS: testing user
    Login shell: /bin/sh
    Principal name: testing_user@IDM.EXAMPLE.COM
    Principal alias: testing_user@IDM.EXAMPLE.COM
    Email address: testing_user@idm.example.com
    UID: 1689700012
    GID: 1689700012
    Account disabled: False
    Preserved user: False
    Password: False
    Member of groups: ipausers
    Kerberos keys available: False
    ipauniqueid: 843b1ac8-6e38-11ec-8dfe-5254005aad3e
    mepmanagedentry: cn=testing_user,cn=groups,cn=accounts,dc=idm,dc=example,dc=com
    objectclass: top, person, organizationalperson, inetorgperson, inetuser, posixaccount, krbprincipalaux, krbticketpolicyaux, ipaobject,
                 ipasshuser, ipaSshGroupOfPubKeys, mepOriginEntry
  2. IdM にあるように、移行したユーザーの出力を、元の LDAP サーバーにあるように、ソースユーザーと比較します。インポートされた属性が2回コピーされていないこと、およびそれらが正しい値を持っていることを確認してください。

33.7. Migrating from LDAP to IdM over SSL

ipa migrate-ds コマンドを使用して、LDAP サーバーから Identity Management (IdM) に認証サービスと認可サービスを移行できます。本セクションでは、移行中に送信するデータを暗号化する方法を説明します。

警告

この例は一般的な移行手順のため、あらゆる環境に対応するわけではありません。

実際に LDAP 環境の移行に入る前に、LDAP のテスト環境を設定して移行プロセスを検証することを強く推奨します。環境をテストする場合は、以下を行います。

  1. IdM でテストユーザーを作成し、移行したユーザーの出力を、テストユーザーの出力と比較します。
  2. IdM にあるように、移行したユーザーの出力を、元の LDAP サーバーにあるように、ソースユーザーと比較します。

詳細なガイダンスは、以下の 検証 のセクションを参照してください。

前提条件

手順

  1. リモート LDAP サーバー証明書を発行した CA の証明書を、今後使用する IdM サーバーのファイルに保存します。たとえば、/tmp/remote.crt です。
  2. Migrating an LDAP server to IdM に記載されている手順に従います。ただし、移行時に暗号化された LDAP 接続の場合、URL で ldaps プロトコルを使用し、ipa migrate-ds コマンドに --ca-cert-file オプションを渡します。以下に例を示します。

    # ipa migrate-ds --ca-cert-file=/tmp/remote.crt --your-other-options ldaps://ldap.example.com:636

検証

  1. ipa user-add を使用して、IdM にテストユーザーを作成します。移行したユーザーの出力を、テストユーザーの出力と比較します。移行したユーザーに、テストユーザーに存在する属性およびオブジェクトクラスの最小セットが含まれていることを確認します。以下に例を示します。

    $ ipa user-show --all testing_user
    dn: uid=testing_user,cn=users,cn=accounts,dc=idm,dc=example,dc=com
    User login: testing_user
    First name: testing
    Last name: user
    Full name: testing user
    Display name: testing user
    Initials: tu
    Home directory: /home/testing_user
    GECOS: testing user
    Login shell: /bin/sh
    Principal name: testing_user@IDM.EXAMPLE.COM
    Principal alias: testing_user@IDM.EXAMPLE.COM
    Email address: testing_user@idm.example.com
    UID: 1689700012
    GID: 1689700012
    Account disabled: False
    Preserved user: False
    Password: False
    Member of groups: ipausers
    Kerberos keys available: False
    ipauniqueid: 843b1ac8-6e38-11ec-8dfe-5254005aad3e
    mepmanagedentry: cn=testing_user,cn=groups,cn=accounts,dc=idm,dc=example,dc=com
    objectclass: top, person, organizationalperson, inetorgperson, inetuser, posixaccount, krbprincipalaux, krbticketpolicyaux, ipaobject,
                 ipasshuser, ipaSshGroupOfPubKeys, mepOriginEntry
  2. IdM にあるように、移行したユーザーの出力を、元の LDAP サーバーにあるように、ソースユーザーと比較します。インポートされた属性が2回コピーされていないこと、およびそれらが正しい値を持っていることを確認してください。