検索

Linux ドメイン ID、認証、およびポリシーガイド

download PDF
Red Hat Enterprise Linux 7

Linux 環境での Red Hat Identity Management の使用

Florian Delehaye

Red Hat Customer Content Services

Marc Muehlfeld

Red Hat Customer Content Services

Filip Hanzelka

Red Hat Customer Content Services

Lucie Maňásková

Red Hat Customer Content Services

Aneta Šteflová Petrová

Red Hat Customer Content Services

Tomáš Čapek

Red Hat Customer Content Services

Ella Deon Ballard

Red Hat Customer Content Services

概要

ユーザーとマシン両方の ID およびポリシー管理は、ほとんどのエンタープライズ環境の中核となる機能です。Identity Management は、ID ドメインを作成する方法を提供し、このドメインにより、マシンはドメインへの登録と、シングルサインオンおよび認証サービスに必要となる ID 情報に即座にアクセスすることができるようになります。また、承認およびアクセスを管理するポリシー設定も可能になります。
このガイドに加えて、Red Hat Enterprise Linux Identity Management に関するその他の機能およびサービスについては、以下のガイドを参照してください。

システムレベルの認証ガイド

システムレベルの認証ガイド』 では、authconfig ユーティリティー、System Security Services Daemon (SSSD) サービス、Pluggable Authentication Module(PAM) フレームワーク、Kerberos、certmonger ユーティリティー、およびアプリケーションのシングルサインオン (SSO) など、ローカルシステムにおける認証の設定に使用できるアプリケーションおよびサービスについて説明します。

Windows 統合ガイド

Windows 統合ガイド』 では、Identity Management を使用して Linux ドメインを Microsoft Windows Active Directory (AD) と統合する方法を説明します。このガイドでは、特に、直接的および間接的な AD 統合、SSSD を使用した Common Internet File System (CIFS) へのアクセス、および realmd システムのさまざまな側面について説明します。


パート I. Red Hat Identity Management の概要

本章では、Red Hat Identity Management の目的を説明します。また、Identity Management ドメイン (およびこのドメインに含まれるクライアントおよびサーバーのマシン) に関する基本的な情報も提供します。

第1章 Red Hat Identity Management の概要

1.1. Red Hat Identity Management の目的

Red Hat Identity Management (IdM) は、Linux ベースのドメイン内で ID ストア、認証ポリシー、および認可ポリシーを一元管理する方法を提供します。IdM は、異なるサービスを個別に管理するオーバーヘッドと、異なるマシンで異なるツールを使用するオーバーヘッドを大幅に削減します。
IdM は、以下に対応する数少ない集中型 ID、ポリシー、および認証ソフトウェアです。
  • Linux オペレーティングシステム環境の高度な機能
  • Linux マシンの大規模なグループの一元化
  • Active Directory とのネイティブな統合
IdM は、Linux ベースおよび Linux 制御のドメインを作成します。
  • IdM は、既存のネイティブ Linux ツールとプロトコルを基盤とします。独自のプロセスと設定がありますが、その基盤となる技術は Linux システムで十分に確立されおり、Linux 管理者から信頼されています。
  • IdM サーバーおよびクライアントは Red Hat Enterprise Linux マシンです。ただし、IdM は Windows クライアントを直接サポートしていない場合でも、Active Directory 環境との統合が可能です。
    注記
    本ガイドでは、Linux 環境のみを対象とした IdM の使用方法を説明します。Active Directory との統合に関する詳細は、Windows Integration Guideを参照してください。
    Linux マシンの Active Directory 環境への統合を可能にする Samba スイートの詳細は、『Windows 統合ガイド』のUsing Samba for Active Directory Integrationを参照してください。Samba をサーバーとして使用する場合は、サーバーを IdM ドメインに統合し、IdM または信頼された Active Directory ドメインに対して Samba サーバーに接続するユーザーを認証できないことに注意してください。

1.1.1. IdM による利点の例

複数の Linux サーバーによる ID およびポリシーの管理
IdM を使用しない場合 - 各サーバーが個別に管理されます。パスワードはすべてローカルマシンに保存されます。IT 管理者は、すべてのマシンでユーザーを管理し、認証ポリシーおよび認可ポリシーを別々に設定し、ローカルパスワードを維持します。
IdM を使用する場合 - IT 管理者は以下が可能になります。
  • ID を一か所で管理 - IdM サーバー
  • 複数のマシンで同時にポリシーを均一に適用
  • ホストベースのアクセス制御、委譲などのルールを使用してユーザーに異なるアクセスレベルを設定
  • 権限昇格ルールの一元管理
  • ホームディレクトリーのマウント方法の定義
エンタープライズシングルサインオン
IdM を使用しない場合 - ユーザーはシステムにログインし、サービスやアプリケーションにアクセスする度にパスワードを求められます。これらのパスワードは異なる場合もあるため、アプリケーションごとに使用する認証情報を覚えている必要があります。
IdM を使用する場合 - システムにログインすると、認証情報を繰り返し聞かれることなく、複数のサービスやアプリケーションにアクセスできます。これにより、以下が可能になります。
  • ユーザービリティーの向上
  • パスワードを書き留めたり安全でない場所に保存したりすることによるセキュリティーリスクの低減
  • ユーザーの生産性向上
Linux と Windows の混合環境の管理
IdM を使用しない場合 - Windows システムは Active Directory フォレストで管理されますが、開発、実稼働環境などのチームには多くの Linux システムがあります。Linux システムは、Active Directory 環境から除外されます。
IdM を使用する場合 - IT 管理者は以下が可能になります。
  • ネイティブの Linux ツールを使用して Linux システムを管理する
  • Linux システムを Windows システムと統合して、一元化されたユーザーストアを確保する
  • Linux ベースを容易に拡張する
  • Linux および Active Directory マシンの別々に管理し、Linux および Windows の管理者が環境を直接制御できる

1.1.2. Identity Management と標準 LDAP ディレクトリーの比較

Red Hat Directory Server などの標準 LDAP ディレクトリーは汎用ディレクトリーで、幅広いユースケースに適用するようにカスタマイズできます。
  • スキーマー - ユーザー、マシン、ネットワークエンティティー、物理的設備、建物といった非常に幅広いエントリー用にカスタマイズ可能な柔軟性のあるスキーマー
  • 典型的な使用例 - インターネット上でサービスを提供するビジネスアプリケーションなど、他のアプリケーションのデータを保存するバックエンドのディレクトリー
Identity Management (IdM) には、ID とその ID に関連する認証および認可ポリシーを管理するという特定の目的があります。
  • スキーマー - ユーザーやマシンの ID のエントリーといった特定の目的に関連するエントリーセットを定義する特定のスキーマ
  • 典型的な使用例 - 企業やプロジェクトの境界内におけるアイデンティティーを管理する ID および認証サーバー
Red Hat Directory Server と IdM では、基礎となるディレクトリーサーバーの技術は同じです。ただし、IdM は ID を管理するように最適化されています。これにより全般的な拡張性は制限されますが、シンプルな設定、リソース管理の自動化の改善、ID 管理における効率性の向上などの利点がもたらされます。
関連情報

1.2. Identity Management ドメイン

Identity Management (IdM) ドメインは、同じ設定、ポリシー、およびアイデンティティーストアを共有するマシンのグループで設定されます。この共有プロパティーにより、ドメイン内のマシンは相互に認識、連携できます。
IdM の観点では、ドメインには以下のタイプのマシンが含まれます。
  • IdM サーバー。ドメインコントローラーとして動作する。
  • サーバーに登録されている IdM クライアント
IdM サーバーは、それ自体に登録している IdM クライアントでもあるため、サーバーマシンはクライアントと同じ機能を提供します。
IdM は、IdM サーバーおよびクライアントとしての Red Hat Enterprise Linux マシンに対応します。
注記
本ガイドでは、Linux 環境で IdM を使用する方法を説明します。Active Directory との統合に関する詳細は、Windows Integration Guideを参照してください。

1.2.1. Identity Management サーバー

IdM サーバーは、ID 情報およびポリシー情報の中央リポジトリーとして機能します。また、ドメインメンバーが使用するサービスをホストします。IdM は、IdM 関連の全サービスを一元的に管理する管理ツールを提供します (IdM Web UI およびコマンドラインユーティリティー)。
IdM サーバーのインストールの詳細は、2章Identity Management サーバーのインストールおよびアンインストール を参照してください。
冗長性と負荷分散をサポートするため、データと設定を IdM サーバーから別のサーバーに複製できます (初期サーバーの レプリカ)。サーバーとそのレプリカを設定して、各種サービスをクライアントに提供できます。IdM レプリカの詳細は、4章Identity Management のレプリカのインストールとアンインストール を参照してください。
1.2.1.1. IdM サーバーがホストするサービス
以下のサービスの多くは、IdM サーバーへのインストールが必須というわけではありません。たとえば、認証局 (CA)、DNS サーバー、または Network Time Protocol (NTP) サーバーなどのサービスは、IdM ドメイン外の外部サーバーにインストールできます。
Kerberos: krb5kdc および kadmin
IdM は、シングルサインオンに対応する Kerberos プロトコルを使用します。Kerberos では、正しいユーザー名とパスワードを一度提示するだけで済み、システムから認証情報を再度求められることなく IdM サービスにアクセスできます。
  • Kerberos は 2 つの部分に分類されます。
    • krb5kdc サービス。Kerberos 認証サービスおよびキー配布センター (KDC) デーモンです。
    • kadmin サービス。Kerberos V5 データベース管理プログラムです。
    Kerberos の仕組みの詳細については、『システムレベルの認証ガイド』 のKerberos の使用を参照してください。
  • IdM で Kerberos を使用して認証する方法は、「Kerberos を使用した IdM へのログイン」 を参照してください。
  • IdM で Kerberos を管理する方法は、29章Kerberos ドメインの管理 を参照してください。
LDAP ディレクトリーサーバー: dirsrv
IdM の内部 LDAP ディレクトリーサーバー インスタンスは、 Kerberos、ユーザーアカウント、ホストエントリー、サービス、ポリシー、DNS などの情報をはじめとした、IdM 情報をすべて保存します。
LDAP ディレクトリーサーバーインスタンスは、Red Hat Directory Server と同じテクノロジーをベースにしています。ただし、IdM 固有のタスクに合わせて調整されます。
注記
本ガイドでは、このコンポーネントを Directory Server と呼びます。
認証局: pki-tomcatd
統合 認証局 (CA) は、Red Hat Certificate System と同じテクノロジーをベースにしています。pki は、証明書システムサービスにアクセスするコマンドラインインターフェイスです。
注記
本書では、実装について言及するときはこのコンポーネントを証明書システムと、実装が提供するサービスを言及するときは証明局と呼びます。
Red Hat Certificate System、スタンドアロン Red Hat 製品の詳細は、Product Documentation for Red Hat Certificate Systemを参照してください。
DNS (Domain Name System): 名前
IdM は、動的サービス検出に DNS を使用します。IdM クライアントのインストールユーティリティーは、DNS からの情報を使用して、クライアントマシンを自動的に設定できます。クライアントを IdM ドメインに登録したら、クライアントは DNS を使用してドメイン内の IdM サーバーおよびサービスを検索します。
Red Hat Enterprise Linux の DNS (Domain Name System) プロトコルの BIND (Berkeley Internet Name Domain) 実装には、名前付き の DNS サーバーが含まれています。named-pkcs11 は、PKCS#11 暗号化標準に対するネイティブサポートありで構築された BIND DNS サーバーのバージョンです。
ネットワークタイムプロトコル: ntpd
多くのサービスでは、特定の差異内でサーバーとクライアントが同一のシステムタイムを保持している必要があります。たとえば、Kerberos チケットはタイムスタンプを使用して有効性を判断し、リプレイ攻撃を防ぎます。サーバーとクライアントの時間の差異が許可された範囲内から逸脱すると、Kerberos チケットは無効になります。
デフォルトでは、IdM は Network Time Protocol (NTP) を使用し、ntpd サービスを介してネットワークでクロックを同期します。NTP では、中央サーバーが権威クロックとして機能し、クライアントはサーバークロックと同じ時刻を使用するように同期します。IdM サーバーは、サーバーのインストールプロセス時に IdM ドメインの NTP サーバーとして設定されます。
注記
仮想マシンにインストールされる IdM サーバーで NTP サーバーを実行すると、一部の環境で時間同期が不正確になることがあります。問題が発生する可能性を回避するには、仮想マシンにインストールされている IdM サーバーで NTP を実行しないでください。仮想マシンで NTP サーバーの信頼性に関する詳細は、こちらのナレッジベースソリューションを参照してください。
Apache HTTP Server: httpd
Apache HTTP Web サーバー には、IdM Web UI があり、認証局とその他の IdM サービスの間の通信も管理します。
Samba / Winbind: smbwinbind
Samba は、Red Hat Enterprise Linux に、Common Internet File System (CIFS) プロトコルとも呼ばれる Server Message Block (SMB) プロトコルを実装します。smb サービス経由で SMB プロトコルを使用すると、ファイル共有や共有プリンターなどのサーバーのリソースにアクセスできます。Active Directory (AD) 環境で信頼を設定している場合には、Winbind サービスが IdM サーバーと AD サーバー間の通信を管理します。
  • 詳細は、『System Administrator's Guide』のSambaを参照してください。
  • 詳細は、『System-Level Authentication Guide』のWinbindを参照してください。
ワンタイムパスワード (OTP) 認証: ipa-otpd
ワンタイムパスワード (OTP) は、2 要素認証の一部として、認証トークンがセッション 1 回だけ使用できるように生成するパスワードです。OTP 認証は、ipa-otpd サービスを介して Red Hat Enterprise Linux に実装されています。
custodia: ipa-custodia
Custodia はシークレットサービスプロバイダーで、パスワード、キー、トークン、証明書などのシークレット資料へのアクセスを保存し、共有します。
OpenDNSSEC: ipa-dnskeysyncd
OpenDNSSEC は、DNSSEC (DNS Security Extensions) キーおよびゾーンの署名の記録プロセスを自動化する DNS マネージャーです。ipa-dnskeysyncd serv サービスは、IdM Directory Server と OpenDNSSEC との間の同期を管理します。

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

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

1.2.2. Identity Management クライアント

IdM クライアントは、IdM ドメイン内で動作するように設定されたマシンです。ドメインリソースにアクセスするために IdM サーバーと対話します。たとえば、クライアントは、サーバーに設定した Kerberos ドメインに属し、サーバーが発行する証明書およびチケットを受け取り、その他の一元管理サービスを使用して認証および認可を行います。
IdM クライアントでは、ドメインの一部として操作するための専用のクライアントソフトウェアは必要ありません。必要なのは、Kerberos や DNS など、特定のサービスおよびライブラリーのシステム設定を適切に指定するだけです。この設定では、クライアントマシンが IdM サービスを使用するように指定します。
IdM クライアントのインストールは、3章Identity Management クライアントのインストールおよびアンインストール を参照してください。
1.2.2.1. IdM クライアントがホストするサービス
System Security Services Daemon: sssd
SSSD (System Security Services Daemon) は、ユーザー認証およびキャッシュ認証情報を管理するクライアント側のアプリケーションです。
キャッシュを使用すると、IdM サーバーが利用できなくなったり、クライアントがオフラインになったりした場合に、ローカルシステムが通常の認証操作を継続できるようになります。
詳細は、『System-Level Authentication Guide』のConfiguring SSSDを参照してください。SSSD は、Windows Active Directory (AD) にも対応しています。AD で SSSD を使用する方法は、『Windows Integration Guide』のUsing Active Directory as an Identity Provider for SSSDを参照してください。
certmonger
certmonger サービスは、クライアント上の証明書を監視、更新します。このサービスは、システム上のサービスに対して新しい証明書を要求できます。
詳細は、『System-Level Authentication Guide』のWorking with certmongerを参照してください。

図1.2 IdM サービス間の対話

IdM サービス間の対話

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

このパートでは、ID 管理 デプロイメントのプランニング方法と、ID 管理 サーバー、クライアント、およびレプリカのインストール方法を説明します。

第2章 Identity Management サーバーのインストールおよびアンインストール

Identity Management (IdM) サーバー は ドメインコントローラーで、IdM ドメインを定義し、管理します。IdM サーバーを設定するには、以下を行う必要があります。
  1. 必要なパッケージをインストールしている。
  2. 設定スクリプトを使用してマシンを設定します。
Red Hat は、ドメイン内に複数のドメインコントローラーを設定して、負荷分散と冗長性を確保することを強く推奨します。これらの追加サーバーは、初期マスター IdM サーバーの レプリカ です。
本章では、最初に初期の IdM サーバーをインストールする方法を説明します。初期サーバーからレプリカをインストールする方法は、4章Identity Management のレプリカのインストールとアンインストール を参照してください。

2.1. サーバーのインストールの前提条件

2.1.1. 最小ハードウェア要件

Identity Management (IdM) を実行するには、サーバーに少なくとも以下のハードウェア設定が必要です。
  • 1 x (仮想) CPU コア
  • 2 GB RAM
    少ないメモリーで IdM をインストールできる場合でも、IdM の更新などの一部の操作には 4 GB 以上の RAM が必要です。
  • 10 GB のハードディスク
重要
データベースに保存されているデータ量によっては、IdM にはより多くのリソースが必要になります (特に RAM)。詳細は、「ハードウェア推奨事項」を参照してください。必要なハードウェアリソースは、サーバーの実稼働環境のワークロード、または Active Directory で信頼が設定されている場合など、他の要素に依存します。

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

ハードウェアでは、RAM の容量を適切に確保することが最も重要になります。必要な RAM 容量を判断するには、以下の推奨事項を考慮してください。
  • 10,000 ユーザーおよび 100 グループには、最低 3 GB の RAM と 1 GB のスワップ領域を割り当てます。
  • 100,000 ユーザーおよび 50,000 グループには、最低 16 GB の RAM と 4 GB のスワップ領域を割り当てます。
注記
基本的なユーザーエントリーまたは証明書のあるシンプルなホストエントリーのサイズは、約 5 - 10 KiB です。
大規模なデプロイメントでは、データのほとんどがキャッシュに保存されるため、ディスクスペースを増やすよりも RAM を増やす方が効果的です。
パフォーマンスを向上させるために、基礎となる Directory Server を調整してパフォーマンスを向上させることができます。詳細は、『Red Hat Directory Server パフォーマンスチューニングガイド』 を参照してください。

2.1.3. システム要件

Identity Management は、Red Hat Enterprise Linux 7 でサポートされています。DNS、Kerberos、Directory Server などのサービスのカスタム設定を行わずに、クリーンなシステムに IdM サーバーをインストールします。
重要
パフォーマンスおよび安定性の理由から、Red Hat は、IdM サーバーに他のアプリケーションやサービスをインストールしないことを推奨します。たとえば、特に LDAP オブジェクトの数が多くなると、IdM サーバーはシステムからなくなる可能性があります。また、IdM はシステムに統合され、サードパーティーのアプリケーションが IdM に依存する設定ファイルを変更すると、IdM が破損される可能性があります。
IdM サーバーのインストールは、システムファイルを上書きして、IdM ドメインを設定します。IdM は、元のシステムファイルを /var/lib/ipa/sysrestore/ にバックアップします。
Name Service Cache Daemon (NSCD) 要件
Red Hat は、Identity Management マシンで NSCD を無効にすることを推奨します。または、NSCD を無効にできない場合は、SSSD でキャッシュされないマップの NSCD のみを有効にします。
NSCD と SSSD サービスはいずれもキャッシュを実行し、システムが両方のサービスを同時に使用すると問題が発生する可能性があります。NSCD と SSSD 間の競合を回避する方法については、System-Level Authentication Guideを参照してください。
システムで IPv6 を有効にする必要がある
IdM サーバーで、カーネルで IPv6 プロトコルが有効になっている必要があります。IPv6 は、Red Hat Enterprise Linux 7 システムでデフォルトで有効になっている点に注意してください。
IPv6 を無効にする場合は、Red Hat ナレッジベースの How do I disable or enable the IPv6 protocol in Red Hat Enterprise Linux? で説明されているように、IPv6 プロトコルを再度有効にします。
注記
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 ページを参照してください。

2.1.4. FIPS 環境にサーバーをインストールする場合の前提条件

Red Hat Enterprise Linux 7.4 以降を使用して環境を設定する環境では、以下を行います。
  • 連邦情報処理規格 (FIPS) モードが有効になっているシステムに、新しい IdM サーバーまたはレプリカを設定できます。インストールスクリプトは、FIPS が有効になっているシステムを自動的に検出し、管理者の介入なしに IdM を設定します。
    オペレーティングシステムで FIPS を有効にするには、『セキュリティーガイド』のFIPS モードの有効化を参照してください。
    重要
    以下を行うことはできません。
    • FIPS モードを無効にしてからインストールした既存の IdM サーバーで FIPS モードを有効にする。
    • FIPS モードを無効にして既存の IdM サーバーを使用する場合に FIPS モードでレプリカをインストールする。
Red Hat Enterprise Linux 7.3 以前を使用して設定された環境では、以下を行います。
  • IdM では FIPS モードをサポートされません。IdM サーバーまたはレプリカをインストールする前に FIPS を無効にしてインストール後に有効にしないでください。
FIPS モードの詳細は、『セキュリティーガイド』の連邦情報処理標準 (FIPS)を参照してください。

2.1.5. ホスト名および DNS 設定

警告
以下の点を確認し、十分注意してください。
  • テスト済みの機能する DNS サービスが利用可能である。
  • サービスが適切に設定されている。
この要件は、統合 DNS サービスがある IdM サーバーと、DNS なしでインストールした IdM サーバーに適用されます。DNS レコードは、稼働中の LDAP ディレクトリーサービス、Kerberos、Active Directory 統合など、ほぼすべての IdM ドメイン機能で必須となります。
プライマリー DNS ドメインと Kerberos レルムはインストール後に変更できないことに注意してください。
.company など、単一ラベルのドメイン名を使用しないでください。IdM ドメインは、トップレベルドメインと、1 つ以上のサブドメイン (example.comcompany.example.com など) で設定する必要があります。
サーバーホストは、DNS サーバーが IdM 内に統合されているか、外部でホストされるかに関係なく、DNS を適切に設定する必要があります。
Identity Management では、サービスレコードに別の DNS ドメインを使用する必要があります。DNS レベルの競合を回避するため、プライマリー IdM DNS ドメイン (IdM Kerberos 名の小文字バージョン) では、他の IdM や AD ドメインなどの他のシステムと共有できません。
プライマリー IdM DNS ドメインには、標準の IdM サービス用の独自の SRV レコードを含める必要があります。必要なレコードは以下のとおりです。
  • _kerberos._tcp.domain_name と _kerberos._udp.domain_name 両方の SRV レコード
  • _ldap._tcp.domain_name の SRV レコード
  • _kerberos.domain_name の TXT レコード
登録済みのクライアントで ipa コマンドラインツール経由で提供されるサービスを検索すると、/etc/ipa/default.conf ファイルの xmlrpc_uri パラメーターで指定したサーバーを検索します。必要な場合には、同じファイルにある domain パラメーターに指定している IdM DNS ドメイン名も検索し、そのドメインの _ldap._tcp.domain_name SRV レコードを確認して、検索しているサーバーを特定します。/etc/ipa/default.conf ファイルにドメインがない場合に、クライアントはファイルの xmlrpc_uri パラメーターに設定したサーバーとのみ通信します。
IdM クライアントおよびサーバーのホスト名は、プライマリー DNS ドメインの一部にする必要はありません。ただし、Active Directory (AD) を使用する信頼環境では、IdM サーバーのホスト名は IdM 所有ドメイン、IdM レルムに関連付けられたドメインに所属する必要があり、AD 所有ドメイン、信頼された AD レルムに関連付けられたドメインには含めないようにする必要があります。信頼の観点から見ると、この関連付けは レルムドメイン を使用して管理されます。
Active Directory DNS ドメインからのホスト名を使用して IdM クライアントにアクセスするようにユーザーを設定し、クライアント自体が IdM に参加するように設定する方法は、『Windows 統合ガイド』 のActive Directory DNS ドメインの IdM クライアントを参照してください。
サーバーのホスト名の確認
ホスト名は、完全修飾ドメイン名 (例: server.example.com) である必要があります。
重要
.company など、単一ラベルのドメイン名を使用しないでください。IdM ドメインは、トップレベルドメインと、1 つ以上のサブドメイン (example.com や company.example.com など) で設定する必要があります。
完全修飾ドメイン名は、以下の条件を満たす必要があります。
  • 数字、アルファベット文字、およびハイフン (-) のみが使用される有効な DNS 名である。ホスト名でアンダーライン (_) を使用すると DNS が正常に動作しません。
  • すべてが小文字である。大文字は使用できません。
  • 完全修飾ドメイン名は、ループバックアドレスを解決できません。127.0.0.1 ではなく、マシンの公開 IP アドレスを解決する必要があります。
その他の推奨命名プラクティスは『Red Hat Enterprise Linux Security Guide』のRecommended Naming Practicesを参照してください。
マシンのホスト名を確認するには、hostname ユーティリティーを使用します。
[root@server ~]# hostname
server.example.com
hostname の出力は、localhost または localhost6 以外である必要があります。
正引きおよび逆引き DNS 設定の確認
  1. サーバーの IP アドレスを取得します。ip addr show コマンドを実行すると、IPv4 アドレスと IPv6 アドレスの両方が表示されます。
    • IPv4 アドレスは、inet で始まる行に表示されます。以下の例では、設定した IPv4 アドレスは 192.0.2.1 です。
    • IPv6 アドレスは、inet6 で始まる行に表示されます。この手順は、scope global の 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.example.com A コマンドを実行します。返される IPv4 アドレスは、ip addr show により返される IP アドレスと一致する必要があります。
      [root@server ~]# dig +short server.example.com A
      192.0.2.1
      
    2. dig +short server.example.com AAAA コマンドを実行します。このコマンドにアドレスを返されるアドレスは、ip addr show で返される IPv6 アドレスと一致する必要があります。
      [root@server ~]# dig +short server.example.com AAAA
      2001:DB8::1111
      
      注記
      AAAA レコードの出力が返されないからといって、設定が間違っているわけではありません。出力されないのは、サーバーのマシンの DNS に IPv6 アドレスが設定されていないことを意味します。ネットワークで IPv6 プロトコルを使用する予定がない場合は、この状況でもインストールを続行できます。
  3. dig ユーティリティーを使用して、逆引き DNS 設定 (PTR レコード) を確認し、IP アドレスを追加します。
    1. dig +short -x IPv4 address コマンドを実行します。コマンド出力には、サーバーのホスト名が表示される必要があります。以下に例を示します。
      [root@server ~]# dig +short -x 192.0.2.1
      server.example.com
      
    2. 前の手順で dig +short -x server.example.com AAAA コマンドにより IPv6 アドレスが返されていた場合は、dig を使用して、IPv6 アドレスのクエリーを行います。ここでも、サーバーのホスト名がコマンド出力に表示される必要があります。以下に例を示します。
      [root@server ~]# dig +short -x 2001:DB8::1111
      server.example.com
      
      注記
      前の手順で dig +short server.example.com AAAA コマンドにより IPv6 アドレスが返されなかった場合は、AAAA レコードのクエリーを実行しても、何も出力されません。この場合、これは正常な動作で、誤った設定を示すものではありません。
    前の手順の dig +short server.example.com で IP アドレスが返されても異なるホスト名が表示されたり、ホスト名が表示されない場合は、逆引き DNS 設定が正しくありません。
DNS フォワーダーの標準コンプライアンスの確認
統合 DNS で IdM を設定する場合は、DNSSEC (DNS Security Extensions) レコード検証の使用を推奨します。他のサーバーから署名済み DNS レコードを検証することで、偽装アドレスから IdM インストールを保護します。ただし、DNSSEC の検証は、IdM を正常にインストールするためのハード要件ではありません。
IdM インストーラーは、デフォルトで DNSSEC レコードの検証を有効にします。DNSSEC の検証に成功すると、DNSSEC が適切に設定されているフォワーダーが必要です。インストール時に、IdM はグローバルフォワーダーを確認し、フォワーダーが DNSSEC に対応していない場合は、フォワーダーで DNSSEC 検証が無効になります。
IdM DNS サーバーで使用するすべての DNS フォワーダーが Extension Mechanisms for DNS (EDNS0) および DNSSEC の規格に準拠していることを確認します。
$ 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 ファイルに設定されている必要があります。
たとえば、想定される出力は次のようになります。
;; ->>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 ファイルは手動で変更しないでください。以前に /etc/hosts を変更したことがある場合は、コンテンツが以下のルールに準拠していることを確認してください。
以下は、適切に設定された /etc/hosts ファイルの例になります。ホストの IPv4 および IPv6 の localhost エントリーを適切にリスト表示し、その後に IdM サーバーの IP アドレスとホスト名を最初のエントリーとしてリスト表示します。IdM サーバーのホスト名は、localhost エントリーには追加できないことに注意してください。
127.0.0.1	localhost.localdomain	localhost
::1		localhost6.localdomain6	localhost6
192.0.2.1	server.example.com	server
2001:DB8::1111	server.example.com	server

2.1.6. ポートの要件

IdM はサービスとの通信に多くのポートを使用します。IdM を機能させるには、これらのポートを開放して利用できるようにしておく必要があります。別のサービスを使用したり、ファイアウォールでブロックしたりしないようにしてください。
必須ポートのリスト
表2.1 Identity Management ポート
サービス ポート プロトコル
HTTP/HTTPS 80、443 TCP
LDAP/LDAPS 389、636 TCP
Kerberos 88、464 TCP および UDP
DNS 53 TCP および UDP
NTP 123 UDP
注記
IdM はポート 80 および 389 を使用しますが問題ありません。
  • ポート 80 (HTTP) は、Online Certificate Status Protocol (OCSP) 応答および証明書失効リスト (CRL) の提供に使用されます。いずれもデジタル署名されているため、中間者攻撃に対してセキュリティーが保護されます。
  • ポート 389 (LDAP) は、暗号化に STARTTLS および GSSAPI を使用します。
さらに、IdM はポート 8080 でリッスンでき、一部のインストールはポート 8443 および 749 でもリッスンできます。ただし、これらの 3 つのポートは内部でのみ使用されます。IdM が開放したままであっても、外部からアクセスできません。ポート 8080、8443、および 749 を開放せず、ファイアウォールでブロックした状態にすることが推奨されます。
firewalld サービスのリスト
表2.2 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. 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,list_of_ports}
    2. firewall-cmd --add-service コマンドを使用して、firewalld サービスをファイアウォールに追加します。たとえば、デフォルトゾーンでポートを開くには、次のコマンドを実行します。
      # firewall-cmd --permanent --add-service={freeipa-ldap,list_of_services}
    firewall-cmd を使用してシステムでポートを開く方法は、『Security Guide』のModifying Settings in Runtime and Permanent Configuration using CLIか、firewall-cmd(1)の man ページを参照してください。
  3. firewall-cmd 設定を再ロードして、変更が即座に反映されるようにします。
    # firewall-cmd --reload
    実稼働システムで firewalld を再ロードすると、DNS の接続がタイムアウトになる可能性があることに注意してください。『Security Guide』のModifying Settings in Runtime and Permanent Configuration using CLIも参照してください。必要な場合は、以下の例のように firewall-cmd コマンドで --runtime-to-permanent オプションを指定して、タイムアウトが発生しないようにし、変更を永続化します。
    # firewall-cmd --runtime-to-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}
  4. オプション:ポートが現在利用可能であるかを確認するには、nctelnet または nmap ユーティリティーを使用して、ポートへの接続またはポートスキャンの実行を行います。
注記
さらに、着信および送信トラフィックの両方でネットワークベースのファイアウォールを開く必要があることに注意してください。

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

統合 DNS サービスのないサーバーに必要なパッケージをインストールするには、以下を実行します。
# yum install ipa-server
統合 DNS サービスを使用するサーバーに必要なパッケージをインストールするには、以下を実行します。
# yum install ipa-server ipa-server-dns
注記
DNS がユースケースに適しているかどうかを確認するには、「統合 DNS を使用するかどうかの決定」 を参照してください。
ipa-server パッケージは、以下のように、依存関係として他に必要なパッケージを自動的にインストールします。
  • Directory Server LDAP サービスの 389-ds-base
  • Kerberos サービスの krb5-server パッケージ
  • IdM 固有の各種ツール

2.3. IdM サーバーのインストール: 概要

注記
以下のセクションのインストール手順と例は合わせて使用できます。手順と例を組み合わせて、必要な結果を得ることができます。たとえば、統合 DNS と、外部でホストされるルート CA のあるサーバーをインストールできます。
ipa-server-install ユーティリティーは、IdM サーバーをインストールし、設定します。
サーバーをインストールする前に、以下のセクションを参照してください。
ipa-server-install ユーティリティーは、非対話型インストールモードで、自動化および無人サーバーの設定が可能です。詳細は、「非対話形式でのサーバーのインストール」を参照してください。
ipa-server-install インストールスクリプトにより、/var/log/ipaserver-install.log にログファイルが作成されます。ログは、インストールに失敗した時の問題特定に役立ちます。

2.3.1. 統合 DNS を使用するかどうかの決定

IdM は、統合 DNS があるサーバーまたは統合 DNS のないサーバーのインストールに対応します。
統合 DNS サービスを備えた IdM サーバー
IdM が提供する統合 DNS サーバーは、汎用 DNS サーバーとして使用するように設計されていません。IdM のデプロイメントとメンテナンスに関連する機能のみに対応します。高度な DNS 機能の一部には対応していません。
Red Hat では、IdM デプロイメントにおける基本的な使用のために IdM 統合 DNS を強く推奨します。IdM サーバーが DNS も管理する場合には、DNS とネイティブの IdM ツールが密接に統合されるため、DNS レコード管理の一部が自動化できます。
IdM サーバーがマスター DNS サーバーとして使用されている場合でも、その他の外部 DNS サーバーはスレーブサーバーとしても使用できます。
たとえば、環境がすでに Active Directory 統合 DNS サーバーなどの別の DNS サーバーを使用している場合には、IdM のプライマリードメインのみを IdM 統合 DNS に委譲できます。DNS ゾーンを IdM 統合 DNS に移行する必要はありません。
注記
SAN (Subject Alternative Name) 拡張機能の IP アドレスを使用して IdM クライアントの証明書を発行する必要がある場合は、IdM 統合 DNS サービスを使用する必要があります。
統合 DNS のあるサーバーをインストールするには、「統合 DNS を使用したサーバーのインストール」 を参照してください。
統合 DNS サービスのない IdM サーバー
外部 DNS サーバーは、DNS サービスを提供するために使用されます。以下の状況では、DNS を使用せずに IdM サーバーをインストールすることを検討してください。
  • IdM DNS のスコープを超える高度な DNS 機能が必要な場合
  • 外部の DNS サーバーを使用できるようにする、適切に確立された DNS インフラストラクチャーがある環境
統合 DNS のないサーバーをインストールするには、 「統合 DNS を使用しないサーバーのインストール」 を参照してください。
重要
お使いのシステムが 「ホスト名および DNS 設定」 に記載されている DNS 要件を満たしていることを確認してください。
統合または外部 DNS のメンテナンス要件
統合 DNS サーバーを使用する場合には、ほとんどの DNS レコードのメンテナンスは自動化されます。必要な作業は以下のとおりです。
  • 親ドメインから IdM サーバーに正しい委譲を設定する
    たとえば、IdM ドメイン名が ipa.example.com の場合は、example.com ドメインから適切に委譲する必要があります。
    注記
    以下のコマンドを使用して委譲を確認できます。
    # dig @IP_address +norecurse +short ipa.example.com. NS
    ip_address は、example.com DNS ドメインを管理するサーバーの IP アドレスです。委譲が正しい場合は、このコマンドは DNS サーバーがインストールされている IdM サーバーを表示します。
外部 DNS サーバーを使用する場合は、以下を行う必要があります。
  • DNS サーバーに新規ドメインを手動で作成する
  • IdM インストーラーが生成したゾーンファイルのレコードをもとに新しいドメインを手動で入力する
  • レプリカのインストールまたは削除後にレコードを手動で更新する。また、Active Directory 信頼が設定された後など、サービス設定の変更後にレコードを手動で更新する。
DNS アンプ攻撃の防止
IdM 統合 DNS サーバーのデフォルト設定により、すべてのクライアントが DNS サーバーに再帰クエリーを発行できます。信頼できないクライアントが含まれるネットワークにサーバーがデプロイされている場合は、サーバー設定を変更して、承認されたクライアントにのみ再帰を制限します。[1]
承認されたクライアントのみが再帰クエリーを発行できるようにするには、サーバーの /etc/named.conf ファイルに適切なアクセス制御リスト (ACL) ステートメントを追加します。以下に例を示します。
acl authorized { 192.0.2.0/24; 198.51.100.0/24; };
options {
  allow-query { any; };
  allow-recursion { authorized; };
};

2.3.2. 使用する CA 設定の決定

IdM は、統合 IdM 認証局 (CA) を使用した、または使用しないサーバーのインストールに対応します。
統合 IdM CA を使用するサーバー
これは、ほとんどのデプロイメントに適したデフォルト設定です。証明書システムは、CA 署名 証明書を使用して、IdM ドメインで証明書を作成して署名します。
警告
Red Hat は、複数のサーバーに CA サービスをインストールすることを強く推奨します。CA サービスを含む初期サーバーのレプリカのインストールは、「CA のあるレプリカのインストール」 を参照してください。
CA を 1 台のサーバーにのみインストールすると、CA サーバーが失敗した場合に CA 設定を復元できる機会なしに CA 設定が失われるリスクがあります。詳細は「失われた CA サーバーの復旧」を参照してください。
IdM CA 署名証明書は、自己署名 と呼ばれるルート CA か、外部 CA で署名することもできます。
IdM CA はルート CA です。
これがデフォルト設定になります。
この設定でサーバーをインストールするには、「統合 DNS を使用したサーバーのインストール」 および 「統合 DNS を使用しないサーバーのインストール」 を参照してください。
外部 CA はルート CA です。
IdM CA は、外部 CA の下位局になります。ただし、IdM ドメインのすべての証明書は、証明書システムインスタンスにより引き続き発行されます。
外部 CA は、Verisign や Thawte などの企業 CA またはサードパーティーの CA です。外部 CA は、ルート CA または下位 CA です。IdM ドメイン内で発行された証明書には、証明書を発行できるドメインなど、外部ルート CA 証明書または中間 CA 証明書が指定する制限が適用される可能性があります。
外部ホストのルート CA を備えたサーバーをインストールするには、「外部 CA をルート CA として使用するサーバーのインストール」 を参照してください。
CA を使用しないサーバー
この設定オプションは、インフラストラクチャー内の制限がサーバーに証明書サービスをインストールできない場合など、非常にまれなケースに適しています。
インストール前に、サードパーティーの認証局からこれらの証明書を要求する必要があります。
  • LDAP サーバー証明書および秘密鍵
  • Apache サーバー証明書および秘密鍵
  • LDAP および Apache のサーバー証明書を発行した CA の完全な CA 証明書チェーン
警告
統合 IdM CA を使用せずに証明書を管理すると、メンテナンスの負担が大きくなります。たとえば、IdM サーバーの Apache Web サーバーおよび LDAP サーバー証明書を手動で管理する必要があります。これには、以下のものが含まれます。
  • 証明書を作成してアップロードする。
  • 証明書の有効期限を監視する。certmonger サービスでは、統合 CA を使用せずに IdM がインストールされている場合には証明書は追跡されない点に注意してください。
  • 有効期限が切れる前に証明書を更新してサービスが停止されないようにする。
統合 CA のないサーバーをインストールするには、「CA なしでのインストール」を参照してください。
注記
CA を使用せずに IdM ドメインをインストールする場合は、後で CA サービスをインストールできます。既存の IdM ドメインに CA をインストールするには、「既存の IdM ドメインへの CA のインストール」 を参照してください。

2.3.3. 統合 DNS を使用したサーバーのインストール

注記
DNS または CA 設定が適切かどうかが不明な場合は、「統合 DNS を使用するかどうかの決定」 および 「使用する CA 設定の決定」 を参照してください。
統合 DNS のあるサーバーをインストールするには、インストールプロセス時に以下の情報を指定します。
DNS フォワーダー
以下の DNS フォワーダー設定がサポートされます。
  • 1 つ以上のフォワーダー (非対話型インストールの --forwarder オプション)
  • フォワーダーなし (非対話型インストールの --no-forwarders オプション)
DNS 転送を使用するかどうか不明な場合は、「DNS 転送の管理」 を参照してください。
逆引き DNS ゾーン
以下の逆引き DNS ゾーン設定がサポートされます。
  • IdM DNS で作成する必要がある逆引きゾーンの自動検出 (対話型インストールの場合は --auto-reverse オプションのデフォルト設定)
  • 逆引きゾーンの自動検出なし (対話型インストールの --no-reverse オプション)
--auto-reverse オプションが設定されている場合には、--allow-zone-overlap オプションは無視されます。オプションの組み合わせの使用:
$ ipa-server-install --auto-reverse --allow-zone-overlap
そのため、別の DNS サーバーなどで、既存の DNS ゾーンと重複する 逆引きゾーン は作成されません。
非対話的なインストールでは --setup-dns オプションも追加します。

例2.1 統合 DNS を使用したサーバーのインストール

この手順では、以下のサーバーをインストールします。
  • 統合 DNS のあるサーバー
  • 統合 IdM CA をルート CA とするサーバー (デフォルトの CA 設定)
  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]:
    警告
    Red Hat では、Kerberos レルム名がプライマリー DNS ドメイン名と同じで、すべて大文字にすることを強く推奨します。たとえば、プライマリー DNS ドメインが ipa.example.com の場合は、Kerberos レルム名として IPA.EXAMPLE.COM を使用します。
    異なる命名プラクティスを使用すると、Active Directory の信頼を使用できなくなるなど、悪影響をもたらします。
  4. Directory Server のスーパーユーザー (cn=Directory Manager)、および IdM システムユーザーアカウント (admin) のパスワードを入力します。
    Directory Manager password:
    IPA admin password:
  5. DNS フォワーダー設定のスクリプトプロンプトが表示されます。
    Do you want to configure DNS forwarders? [yes]:
    • DNS フォワーダーを設定するには、yes を入力して表示されたコマンドラインの指示に従います。
      インストールプロセスにより、インストールした IdM サーバーの /etc/named.conf ファイルに、フォワーダーの IP アドレスが追加されます。
      • 転送ポリシーのデフォルト設定については、ipa-dns-install(1) man ページの --forward-policy の説明を参照してください。
      • 詳細は、「フォワードポリシー」 も参照してください。
    • DNS 転送を使用しない場合は、no と入力します。
  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. 親ドメインから ldM DNS ドメインに DNS 委譲を追加します。たとえば、IdM DNS ドメインが ipa.example.com の場合は、ネームサーバー (NS) レコードを親ドメイン example.com に追加します。
    重要
    この手順は、IdM DNS サーバーをインストールするたびに繰り返す必要があります。
このスクリプトでは、CA 証明書をバックアップして必要なネットワークポートが開いていることの確認が推奨されます。IdM ポートの要件と、これらのポートを開く方法は、「ポートの要件」 を参照してください。
新しいサーバーをテストするには、以下を行います。
  1. admin 認証情報を使用して Kerberos レルムに対して認証します。これにより、admin が適切に設定され、Kerberos レルムにアクセスできることを確認します。
    # kinit admin
  2. ipa user-find などのコマンドを実行します。新しいサーバーでは、このコマンドは、設定したユーザー (admin) のみを出力します。
    # ipa user-find admin
    --------------
    1 user matched
    --------------
    User login: admin 
    Last name: Administrator 
    Home directory: /home/admin 
    Login shell: /bin/bash 
    UID: 939000000 
    GID: 939000000 
    Account disabled: False 
    Password: True 
    Kerberos keys available: True 
    ----------------------------
    Number of entries returned 1
    ----------------------------

2.3.4. 統合 DNS を使用しないサーバーのインストール

注記
DNS または CA 設定が適切かどうかが不明な場合は、「統合 DNS を使用するかどうかの決定」 および 「使用する CA 設定の決定」 を参照してください。
統合 DNS を使用せずにサーバーをインストールするには、DNS 関連のオプションを指定せずに ipa-server-install ユーティリティーを実行します。

例2.2 統合 DNS を使用しないサーバーのインストール

この手順では、以下のサーバーをインストールします。
  • 統合 DNS のないサーバー
  • 統合 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]:
    警告
    Red Hat では、Kerberos レルム名がプライマリー DNS ドメイン名と同じで、すべて大文字にすることを強く推奨します。たとえば、プライマリー DNS ドメインが ipa.example.com の場合は、Kerberos レルム名として IPA.EXAMPLE.COM を使用します。
    異なる命名プラクティスを使用すると、Active Directory の信頼を使用できなくなるなど、悪影響をもたらします。
  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 レコードを追加するまで、サーバーのインストールは完了しません。
このスクリプトでは、CA 証明書をバックアップして必要なネットワークポートが開いていることの確認が推奨されます。IdM ポートの要件と、これらのポートを開く方法は、「ポートの要件」 を参照してください。
新しいサーバーをテストするには、以下を行います。
  1. admin 認証情報を使用して Kerberos レルムに対して認証します。これにより、admin が適切に設定され、Kerberos レルムにアクセスできることを確認します。
    # kinit admin
  2. ipa user-find などのコマンドを実行します。新しいサーバーでは、このコマンドは、設定したユーザー (admin) のみを出力します。
    # ipa user-find admin
    --------------
    1 user matched
    --------------
    User login: admin 
    Last name: Administrator 
    Home directory: /home/admin 
    Login shell: /bin/bash 
    UID: 939000000 
    GID: 939000000 
    Account disabled: False 
    Password: True 
    Kerberos keys available: True 
    ----------------------------
    Number of entries returned 1
    ----------------------------

2.3.5. 外部 CA をルート CA として使用するサーバーのインストール

注記
DNS または CA 設定が適切かどうかが不明な場合は、「統合 DNS を使用するかどうかの決定」 および 「使用する CA 設定の決定」 を参照してください。
サーバーをインストールし、外部 CA をルート CA として連携させるには、ipa-server-install ユーティリティーでこのオプションを指定します。
  • --external-ca は、外部 CA を使用するように指定します。
  • --external-ca-type は、外部 CA のタイプを指定します。詳細は ipa-server-install(1) の man ページを参照してください。
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 として使用するサービスにより異なります。
    重要
    証明書の適切な拡張を要求する必要があります。Identity Management 用に生成された CA 署名証明書は、有効な CA 証明書である必要があります。そのためには、基本的な制約エクステンションの CA パラメーターを true に設定する必要があります。詳細は、RFC 5280 の『基本的な制約』 のセクションを参照してください。
  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/servercert20110601.pem --external-cert-file=/tmp/cacert.pem
注記
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 のインストールに失敗する」 を参照してください。

2.3.6. CA なしでのインストール

注記
DNS または CA 設定が適切かどうかが不明な場合は、「統合 DNS を使用するかどうかの決定」 および 「使用する CA 設定の決定」 を参照してください。
CA を使用せずにサーバーをインストールするには、ipa-server-install ユーティリティーにオプションを追加して、必要な証明書を手動で指定する必要があります。これ以外のインストール手順はほぼ、「統合 DNS を使用したサーバーのインストール」 または 「統合 DNS を使用しないサーバーのインストール」 と同じです。
重要
自己署名のサードパーティーサーバー証明書を使用してサーバーまたはレプリカをインストールすることはできません。
CA なしで IdM サーバーをインストールするために必要な証明書
CA なしで IdM サーバーをインストールするには、以下の証明書を指定する必要があります。
  • 以下のオプションを使用して 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)。IdM インストーラーでは、連結した PEM エンコードオブジェクトを使用できることに注意してください。
      • 識別名エンコーディングルール (DER)
      • PKCS #7 証明書チェーンオブジェクト
      • PKCS #8 秘密鍵オブジェクト
      • PKCS #12 アーカイブ
      --dirsrv-cert-file オプションおよび --http-cert-file オプションを複数回指定して、複数のファイルを指定できます。
  • 必要に応じて、このオプションを使用して完全な CA 証明書チェーンを完了するための証明書ファイルを指定します。
    • --ca-cert-file - このオプションは複数回追加できます。
  • オプションで、このオプションを使用して外部 Kerberos 鍵配布センター (KDC) の PKINIT 証明書を提供する証明書ファイルを指定します。
    • --pkinit-cert-file - Kerberos KDC SSL の証明書および秘密鍵を提供します。
    • --pkinit-pin - Kerberos KDC の秘密鍵のロックを解除するパスワード。
    PKINIT 証明書を提供しないと、ipa-server-install は自己署名証明書を使用するローカル KDC で IdM サーバーを設定します。詳細は、27章IdM の Kerberos PKINIT 認証を参照してください。
--ca-cert-file を使用して提供されるファイルと、--dirsrv-cert-file--http-cert-file を使用して提供されるファイルには、LDAP および Apache のサーバー証明書を発行した CA の完全 CA 証明書チェーンが含まれる必要があります。
このオプションで使用できる証明書ファイル形式の詳細は、ipa-server-install(1) man ページを参照してください。
注記
表示されたコマンドラインオプションは、--external-ca オプションと互換性がありません。
注記
Identity Management の以前のバージョンでは、--root-ca-file オプションを使用してルート CA 証明書の PEM ファイルを指定していました。信頼される CA は常に DS および HTTP サーバー証明書の発行者であるため、これは不要になりました。IdM は、--dirsrv-cert-file--http-cert-file および --ca-cert-file で指定された証明書をもとに、ルート CA 証明書を自動的に認識するようになりました。

例2.3 CA なしで IdM サーバーをインストールするコマンドの例

[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

2.3.7. 非対話形式でのサーバーのインストール

注記
DNS または CA 設定が適切かどうかが不明な場合は、「統合 DNS を使用するかどうかの決定」 および 「使用する CA 設定の決定」 を参照してください。
非対話型インストールで最低限必要なオプションは次のとおりです。
  • --ds-password - Directory Server のスーパーユーザーである Directory Manager (DM) のパスワードを指定します。
  • --admin-password - IdM 管理者である admin のパスワードを指定します。
  • --realm - Kerberos レルム名を指定します。
  • --unattended - インストールプロセスでホスト名およびドメイン名のデフォルトオプションを選択するようにします。
必要に応じて、これらの設定にカスタム値を指定できます。
  • --hostname: サーバーホスト名
  • --domain: ドメイン名
--dirsrv-config-file パラメーターを使用して、カスタム値を持つ LDIF ファイルへのパスを指定すると、デフォルトの Directory Server 設定を変更することもできます。詳細は、『Release Notes for Red Hat Enterprise Linux 7.3』のIdM now supports setting individual Directory Server options during server or replica installationを参照してください。
警告
Red Hat では、Kerberos レルム名がプライマリー DNS ドメイン名と同じで、すべて大文字にすることを強く推奨します。たとえば、プライマリー DNS ドメインが ipa.example.com の場合は、Kerberos レルム名として IPA.EXAMPLE.COM を使用します。
異なる命名プラクティスを使用すると、Active Directory の信頼を使用できなくなるなど、悪影響をもたらします。
ipa-server-install で使用できるオプションの完全リストを表示するには、ipa-server-install --help コマンドを実行します。

例2.4 非対話式の基本的なインストール

  1. ipa-server-install ユーティリティーを実行し、必要な設定を指定します。たとえば、以下は、統合 DNS あり、統合 CA なしで、サーバーをインストールします。
    # ipa-server-install --realm EXAMPLE.COM --ds-password DM_password --admin-password admin_password --unattended
  2. 設定スクリプトで、サーバーが設定されるようになりました。動作が完了するまで待ちます。
  3. インストールスクリプトは、以下の出力例の 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 レコードを追加するまで、サーバーのインストールは完了しません。
このスクリプトでは、CA 証明書をバックアップして必要なネットワークポートが開いていることの確認が推奨されます。IdM ポートの要件と、これらのポートを開く方法は、「ポートの要件」 を参照してください。
新しいサーバーをテストするには、以下を行います。
  1. admin 認証情報を使用して Kerberos レルムに対して認証します。これにより、admin が適切に設定され、Kerberos レルムにアクセスできることを確認します。
    # kinit admin
  2. ipa user-find などのコマンドを実行します。新しいサーバーでは、このコマンドは、設定したユーザー (admin) のみを出力します。
    # ipa user-find admin
    --------------
    1 user matched
    --------------
    User login: admin 
    Last name: Administrator 
    Home directory: /home/admin 
    Login shell: /bin/bash 
    UID: 939000000 
    GID: 939000000 
    Account disabled: False 
    Password: True 
    Kerberos keys available: True 
    ----------------------------
    Number of entries returned 1
    ----------------------------


[1] 詳細は、DNS Amplification Attacks ページを参照してください。

2.4. IdM サーバーのアンインストール

注記
ドメインレベル 0 では、この手順は異なります。「レプリカの削除」を参照してください。
前提条件
  • 認証局 (CA)、鍵回復機関 (KRA)、または DNS Security Extensions (DNSSEC) サーバーとして機能するサーバーをアンインストールする前に、これらのサービスがドメインの別のサーバーで実行していることを確認している。
    警告
    CA サーバー、KRA サーバー、または DNSSEC サーバーとして機能する唯一のレプリカを削除すると、Identity Management 機能に深刻な不具合が発生する可能性があります。
手順
server.example.com をアンインストールするには、以下を実行します。
  1. 別のサーバーで ipa server-del コマンドを使用して、トポロジーから server.example.com を削除します。
    [root@another_server ~]# ipa server-del server.example.com
  2. server.example.com で、ipa-server-install --uninstall コマンドを使用します。
    [root@server ~]# ipa-server-install --uninstall
  3. server .example.com を参照するすべてのネームサーバー (NS)DNS レコードが DNS ゾーンから削除されていることを確認します。使用する DNS が IdM により管理される統合 DNS であるか、外部 DNS であるかに関わらず、確認を行なってください。

2.5. サーバーの名前変更

IdM サーバーのホスト名は、設定後に変更できません。ただし、サーバーを別の名前でレプリカに置き換えることができます。
  1. CA および必要な新しいホスト名または IP アドレスを使用して、サーバーの新しいレプリカを作成します。この操作は、4章Identity Management のレプリカのインストールとアンインストール に説明があります。
  2. 最初の IdM サーバーインスタンスを停止します。
    [root@old_server ~]# ipactl stop
  3. 他のすべてのレプリカおよびクライアントが以前と同じように機能していることを確認します。
  4. 「IdM サーバーのアンインストール」 の説明に従って、初期 IdM サーバーをアンインストールします。

第3章 Identity Management クライアントのインストールおよびアンインストール

本章では、サーバーに登録されているクライアントマシンとして Identity Management (IdM) ドメインに参加するようにシステムを設定する方法を説明します。
注記
IdM ドメインのクライアントおよびサーバーの詳細は、「Identity Management ドメイン」 を参照してください。

3.1. クライアントのインストールの前提条件

DNS 要件
適切な DNS 委譲を採用します。IdM の DNS 要件に関する詳細は、「ホスト名および DNS 設定」 を参照してください。
クライアントの resolv.conf ファイルは変更しないでください。
ポートの要件
IdM クライアントは、IdM サーバーの複数のポートに接続し、サービスと通信します。このポートは、受信方向の IdM サーバー で開放する必要があります。IdM が必要とするポートの詳細は、「ポートの要件」 を参照してください。
クライアントで、これらのポートを送信方向で開きます。firewalld などの、送信パケットにフィルターを設定しないファイアウォールを使用している場合は、ポートを送信方向で使用できます。
Name Service Cache Daemon (NSCD) 要件
Red Hat は、Identity Management マシンで NSCD を無効にすることを推奨します。または、NSCD を無効にできない場合は、SSSD でキャッシュされないマップの NSCD のみを有効にします。
NSCD と SSSD サービスはいずれもキャッシュを実行し、システムが両方のサービスを同時に使用すると問題が発生する可能性があります。NSCD と SSSD 間の競合を回避する方法については、System-Level Authentication Guideを参照してください。

3.1.1. IdM クライアントのインストールをサポートする RHEL のバージョン

IdM サーバーが RHEL 7 の最新のマイナーバージョンで実行されている Identity Management (IdM) デプロイメントでは、以下のバージョンの最新のマイナーバージョンで実行されているクライアントがサポートされます。
  • RHEL 7
    RHEL 8
    RHEL 9
注記
IdM デプロイメントを FIPS 準拠にする予定の場合、{RH} は環境を RHEL 9 に移行することを強く推奨します。RHEL 9 は、FIPS 140-3 で認定された最初の RHEL メジャーバージョンです。

3.1.2. FIPS 環境にクライアントをインストールする場合の前提条件

Red Hat Enterprise Linux 7.4 以降を使用して環境を設定する環境では、以下を行います。
  • 連邦情報処理規格 (FIPS) モードが有効になっているシステムに、新しいクライアントを設定できます。インストールスクリプトは、FIPS が有効になっているシステムを自動的に検出し、管理者の介入なしに IdM を設定します。
    オペレーティングシステムで FIPS を有効にするには、『セキュリティーガイド』のFIPS モードの有効化を参照してください。
Red Hat Enterprise Linux 7.3 以前を使用して設定された環境では、以下を行います。
  • IdM では FIPS モードをサポートされません。IdM クライアントをインストールする前にシステムで FIPS を無効にし、インストール後に有効にしないでください。
FIPS モードの詳細は、『セキュリティーガイド』の連邦情報処理標準 (FIPS)を参照してください。

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

ipa-client パッケージをインストールします。
# yum install ipa-client
ipa-client パッケージは、System Security Services Daemon (SSSD) パッケージなど、依存関係として他に必要なパッケージを自動的にインストールします。

3.3. クライアントのインストール:

ipa-client-install ユーティリティーは、IdM クライアントをインストールし、設定します。インストールプロセスには、クライアントの登録に使用できる認証情報を指定する必要があります。以下の認証方法が、サポートの対象となります。
クライアントを登録する権限のあるユーザーの認証情報 (例: admin)
デフォルトでは、ipa-client-install にはこのオプションが必要です。例は、「クライアントの対話型インストール」 を参照してください。
ユーザーの認証情報を直接 ipa-client-install に指定するには、--principal オプションおよび --password オプションを使用します。
サーバーで無作為に事前生成されるワンタイムパスワード
この認証方法を使用するには、--random オプションを ipa-client-install オプションに追加します。例3.1「無作為のパスワードを使用したクライアントの非対話型インストール」を参照してください。
前回登録時のプリンシパル
この認証方法を使用するには、--keytab オプションを ipa-client-install に追加します。詳細は「クライアントの IdM ドメインへの再登録」を参照してください。
詳細は ipa-client-install(1) の man ページを参照してください。
以下のセクションでは、基本的なインストールシナリオを説明します。ipa-client-install の使用と、許可されるオプションの完全なリストの詳細は、ipa-client-install(1) man ページを参照してください。

3.3.1. クライアントの対話型インストール

以下の手順では、クライアントをインストールしますが、必要に応じてユーザー入力が求められます。ユーザーは、クライアントをドメインに登録する権限のあるユーザーの認証情報 (admin ユーザーなど) を提供します。
  1. ipa-client-install ユーティリティーを実行します。
    以下のいずれかに該当する場合は --enable-dns-updates オプションを追加して、クライアントマシンの IP アドレスで DNS レコードを更新します。
    • クライアントを登録する IdM サーバーが、統合 DNS とともにインストールされた場合。
    • ネットワーク上の DNS サーバーが、GSS-TSIG プロトコルを用いた DNS エントリー更新を受け入れる場合。
    --no-krb5-offline-passwords オプションを追加して、SSSD キャッシュに Kerberos パスワードの保存を無効にします。
  2. インストールスクリプトは、すべての必要な設定を自動的に取得しようとします。
    1. お使いのシステムで 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
      別の値を使用してシステムをインストールする場合は、現在のインストールをキャンセルします。その後、ipa-client-install を再度実行し、コマンドラインオプションを使用して必要な値を指定します。
      詳細は、ipa-client-install(1) man ページの DNS Autodiscovery セクションを参照してください。
    2. スクリプトが一部の設定を自動的に取得できなかった場合は、値を入力するように求められます。
      重要
      .company など、単一ラベルのドメイン名を使用しないでください。IdM ドメインは、トップレベルドメインと、1 つ以上のサブドメイン (example.com や company.example.com など) で設定する必要があります。
      完全修飾ドメイン名は、以下の条件を満たす必要があります。
      • 数字、アルファベット文字、およびハイフン (-) のみが使用される有効な DNS 名である。ホスト名でアンダーライン (_) を使用すると DNS が正常に動作しません。
      • すべてが小文字である。大文字は使用できません。
      • 完全修飾ドメイン名は、ループバックアドレスを解決できません。127.0.0.1 ではなく、マシンの公開 IP アドレスを解決する必要があります。
      その他の推奨命名プラクティスは『Red Hat Enterprise Linux Security Guide』のRecommended Naming Practicesを参照してください。
  3. スクリプトにより、アイデンティティーがクライアントの登録に使用されるユーザーの入力が求められます。デフォルトでは、これは admin ユーザーです。
    User authorized to enroll computers: admin
    Password for admin@EXAMPLE.COM
  4. インストールスクリプトにより、クライアントが設定されます。動作が完了するまで待ちます。
    Client configuration complete.
  5. ipa-client-automount ユーティリティーを実行します。このユーティリティーは、IdM に NFS を自動的に設定します。詳細は「NFS の自動設定」を参照してください。

3.3.2. クライアントの非対話型インストール

非対話的なインストールでは、コマンドラインオプションを使用して、ipa-client-install ユーティリティーに必要な情報をすべて指定します。非対話型インストールで最低限必要なオプションは次のとおりです。
  • クライアントの登録に使用される認証情報を指定するオプション。詳細は 「クライアントのインストール:」 を参照してください。
  • --unattended - ユーザー確認を必要とせずにインストールを実行できるようにします。
お使いのシステムで DNS ゾーンと SRV レコードが正しく設定されていれば、スクリプトは他に必要となる値をすべて自動的に検出します。スクリプトが自動的に値を検出できない場合は、コマンドラインオプションを使用して指定します。
  • --hostname - クライアントマシンの静的ホスト名を指定します。
    重要
    .company など、単一ラベルのドメイン名を使用しないでください。IdM ドメインは、トップレベルドメインと、1 つ以上のサブドメイン (example.com や company.example.com など) で設定する必要があります。
    完全修飾ドメイン名は、以下の条件を満たす必要があります。
    • 数字、アルファベット文字、およびハイフン (-) のみが使用される有効な DNS 名である。ホスト名でアンダーライン (_) を使用すると DNS が正常に動作しません。
    • すべてが小文字である。大文字は使用できません。
    • 完全修飾ドメイン名は、ループバックアドレスを解決できません。127.0.0.1 ではなく、マシンの公開 IP アドレスを解決する必要があります。
    その他の推奨命名プラクティスは『Red Hat Enterprise Linux Security Guide』のRecommended Naming Practicesを参照してください。
  • --server - クライアントが登録される IdM サーバーのホスト名を指定します。
  • --domain - クライアントが登録される IdM サーバーの DNS ドメイン名を指定します。
  • --realm - Kerberos レルム名を指定します。
以下のいずれかに該当する場合は --enable-dns-updates オプションを追加して、クライアントマシンの IP アドレスで DNS レコードを更新します。
  • クライアントを登録する IdM サーバーが、統合 DNS とともにインストールされた場合。
  • ネットワーク上の DNS サーバーが、GSS-TSIG プロトコルを用いた DNS エントリー更新を受け入れる場合。
--no-krb5-offline-passwords オプションを追加して、SSSD キャッシュに Kerberos パスワードの保存を無効にします。
ipa-client-install により許可されるオプションの完全リストは、ipa-client-install(1) の man ページを参照してください。

例3.1 無作為のパスワードを使用したクライアントの非対話型インストール

この手順では、ユーザーに入力を要求せずにクライアントをインストールします。このプロセスでは、サーバー上で無作為に、登録の認証に使用するワンタイムパスワードを事前生成します。
  1. 既存のサーバーの場合:
    1. 管理者としてログインします。
      $ kinit admin
    2. 新しいマシンを 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 ドメインへのマシン登録に使用した後は無効になります。登録の完了後、このパスワードは適切なホストキータブに置き換えられます。
  2. クライアントをインストールするマシンで、ipa-client-install を実行し、以下のオプションを使用します。
    • --password - ipa host-add の出力の無作為なパスワード
      注記
      このパスワードには通常、特殊文字が含まれています。そのため、特殊文字は一重引用符 (') で囲みます。
    • --unattended - ユーザー確認を必要とせずにインストールを実行できるようにします。
    お使いのシステムで DNS ゾーンと SRV レコードが正しく設定されていれば、スクリプトは他に必要となる値をすべて自動的に検出します。スクリプトが自動的に値を検出できない場合は、コマンドラインオプションを使用して指定します。
    以下に例を示します。
    # ipa-client-install --password 'W5YpARl=7M.n' --domain example.com --server server.example.com --unattended
  3. ipa-client-automount ユーティリティーを実行します。このユーティリティーは、IdM に NFS を自動的に設定します。詳細は「NFS の自動設定」を参照してください。

3.4. キックスタートでの IdM クライアントの設定

キックスタートの登録により、Red Hat Enterprise Linux のインストール時に新しいシステムが自動的に IdM ドメインに追加されます。キックスタートの詳細は、『インストールガイド』のキックスタートを使用したインストールを参照してください。
クライアントのキックスタートインストールの準備には、以下の手順が含まれます。

3.4.1. IdM サーバーでクライアントホストエントリーの事前作成

  1. admin としてログインします。
    $ kinit admin
  2. IdM サーバーでホストエントリーを作成し、エントリーの一時パスワードを設定します。
    $ ipa host-add client.example.com --password=secret
    キックスタートがこのパスワードを使用して、クライアントのインストール時に認証し、最初の認証試行後に無効にします。クライアントが正常にインストールされると、キータブを使用して認証が行われます。

3.4.2. クライアントのキックスタートファイルの作成

IdM クライアントの設定に使用するキックスタートファイルには、以下を追加する必要があります。
  • インストールするパッケージリストに含まれる ipa-client パッケージ
    %packages
    @ X Window System
    @ Desktop
    @ Sound and Video
    ipa-client
    ...
    詳細は、『インストールガイド』のパッケージの選択を参照してください。
  • インストール後の手順:
    • 登録前に SSH キーが生成されていることを確認します。
    • 以下を指定して ipa-client-install ユーティリティーを実行します。
      以下に例を示します。
      %post --log=/root/ks-post.log
      
      # Generate SSH keys to ensure that ipa-client-install uploads them to the IdM server
      /usr/sbin/sshd-keygen
      
      # 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 オプションも追加します。
    クライアントのインストールスクリプトがマシンの証明書を要求できるようにするには、以下を行います。
    • --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
    注記
    Red Hat は、キックスタートの登録前に sshd サービスを起動することは推奨していません。登録前に sshd を起動すると、クライアントは自動的に SSH 鍵を生成するので、上記のスクリプトの使用が推奨されます。
    詳細は、『インストールガイド』のインストール後のスクリプトを参照してください。
キックスタートの使用方法は、『インストールガイド』のキックスタートインストールの実行を参照してください。キックスタートファイルの例は、Sample Kickstart Configurationsを参照してください。

3.5. クライアントのインストール後の考慮事項

3.5.1. Identity Management 設定の削除

ipa-client-install スクリプトは、/etc/openldap/ldap.conf ファイルおよび /etc/sssd/sssd.conf ファイルから、以前の LDAP 設定および 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 の新しい設定値を適用するには、以下を行います。
  1. /etc/openldap/ldap.conf および /etc/sssd/sssd.conf を開きます。
  2. 以前の設定を削除します。
  3. 新しい Identity Management 設定をアンコメントします。
  4. システム全体の LDAP 設定に依存するサーバープロセスの中には、再起動しないと変更が適用されない場合があります。openldap ライブラリーを使用するアプリケーションでは通常、起動時に設定がインポートされます。

3.6. 新規クライアントのテスト

クライアントが、サーバーで定義したユーザーに関する情報を取得できることを確認します。たとえば、デフォルトの admin ユーザーを確認するには、次のコマンドを実行します。
[user@client ~]$ id admin
uid=1254400000(admin) gid=1254400000(admins) groups=1254400000(admins)

3.7. クライアントのアンインストール

クライアントをアンインストールすると、クライアントが IdM ドメインから削除され、SSSD などのシステムサービス用の IdM 固有の設定がすべて削除されます。これにより、クライアントマシンの以前の設定が復元されます。
  1. ipa-client-install --uninstall コマンドを実行します。
    # ipa-client-install --uninstall
  2. クライアントホストの DNS エントリーを、手動でサーバーから削除します。「DNS ゾーンからレコードを削除する」を参照してください。

3.8. クライアントの IdM ドメインへの再登録

クライアント仮想マシンが破棄され、そのキータブがある場合は、クライアントを再登録できます。
注記
ドメインエントリーがアクティブなクライアントのみを再登録できます。クライアントをアンインストール (ipa-client-install --uninstall を使用) した場合や、ホストエントリーを無効 (ipa host-disable を使用) にした場合は再登録できません。
再登録中に IdM は以下を実行します。
  • 元のホスト証明書を破棄する。
  • 新しいホスト証明書を生成する。
  • 新規の SSH 鍵を作成する。
  • 新規のキータブを生成する。

3.8.1. 管理者アカウントを使用したクライアントの対話的な再登録

  1. 同じホスト名のクライアントマシンを再作成します。
  2. クライアントマシンで ipa-client-install --force-join コマンドを実行します。
    # ipa-client-install --force-join
  3. スクリプトにより、アイデンティティーがクライアントの登録に使用されるユーザーの入力が求められます。デフォルトでは、これは admin ユーザーです。
    User authorized to enroll computers: admin
    Password for admin@EXAMPLE.COM

3.8.2. クライアントキータブを使用したクライアントの非対話的な再登録

クライアントキータブを使用した再登録は、自動インストールや管理者パスワードを使用できない場合などの他の状況で適しています。
  1. /tmp/root などのディレクトリーに元のクライアントキータブファイルをバックアップします。
  2. 同じホスト名のクライアントマシンを再作成します。
  3. クライアントを再登録し、--keytab オプションを使用してキータブの場所を指定します。
    # ipa-client-install --keytab /tmp/krb5.keytab
    注記
    登録を開始するために認証する場合は、--keytab オプションで指定するキータブのみが使用されます。再登録中、IdM はクライアントに対して新しいキータブを生成します。

3.9. クライアントマシンの名前変更

本セクションでは、IdM クライアントの名前を変更する方法を説明します。このプロセスでは、以下の操作を行います。
警告
クライアントの名前は手動で変更します。Red Hat は、絶対に必要な場合を除き、ホスト名の変更は推奨しません。
現在のサービスとキータブ設定の特定
現在のクライアントをアンインストールする前に、クライアントの設定を書き留めます。新しいホスト名のマシンを再登録した後にこの設定を適用します
  1. マシンで実行しているサービスを特定します。
    1. ipa service-find コマンドを使用して、証明書のあるサービスを特定して出力します。
      $ ipa service-find client.example.com
    2. さらに、各ホストには ipa service-find の出力に表示されないデフォルトの host service があります。ホストサービスのサービスプリンシパルは ホストプリンシパル とも呼ばれ、host/client.example.com になります。
  2. マシンが所属するすべてのホストグループを特定します。
    # ipa hostgroup-find client.example.com
  3. ipa service-find client.example.com で表示されるすべてのサービスプリンシパルは、client.example.com で対応するキータブの場所を決定します。
    クライアントシステム上の各サービスには、ldap /client.example.com@EXAMPLE.COM など service_name/hostname@REALM の形式で Kerberos プリンシパルがあります。
IdM ドメインからのクライアントマシンの削除
  1. IdM ドメインからクライアントマシンの登録を解除します。「クライアントのアンインストール」を参照してください。
  2. /etc/krb5.keytab 以外の各キータブについては、古いプリンシパルを削除します。
    [root@client ~]# ipa-rmkeytab -k /path/to/keytab -r EXAMPLE.COM
    「キータブの削除」を参照してください。
  3. IdM サーバーで、ホストエントリーを削除します。これにより、すべてのサービスが削除され、そのホストに発行されたすべての証明書が無効になります。
    [root@server ~]# ipa host-del client.example.com
この時点で、ホストは IdM から完全に削除されました。
新規ホスト名でのクライアントの再登録
  1. 必要に応じてマシンの名前を変更します。
  2. マシンを IdM クライアントとして再登録します。「クライアントの IdM ドメインへの再登録」を参照してください。
  3. IdM サーバーで、「現在のサービスとキータブ設定の特定」 で特定された各サービスに新しいキータブを追加します。
    [root@server ~]# ipa service-add service_name/new_host_name
  4. 「現在のサービスとキータブ設定の特定」で割り当てた証明書のあるサービスに対して証明書を生成します。これには、以下を行います。
  5. 「現在のサービスとキータブ設定の特定」で特定されたホストグループにクライアントを再追加します。「ユーザーまたはホストグループメンバーの追加と削除」を参照してください。

第4章 Identity Management のレプリカのインストールとアンインストール

レプリカは、既存の Identity Management サーバーの設定をクローンすることで、作成されます。そのため、サーバーとそのレプリカは同一のコア設定を共有します。レプリカのインストールプロセスでは、既存のサーバー設定をコピーし、その設定に基づいてレプリカをインストールします。
ナレッジベースソリューションの Backup and Restore in IdM/IPAで説明されているように、複数のサーバーレプリカを確保することが推奨されるバックアップソリューションです。
注記
もう 1 つのバックアップソリューションは、レプリカから IdM デプロイメントを再構築できない場合に主に推奨していますが、9章Identity Management のバックアップおよび復元 で記載されているように ipa-backup ユーティリティーになります。

4.1. IdM レプリカの説明

多数のクライアントにサービスの可用性や冗長性を確保するために、レプリカ と呼ばれる複数の IdM サーバーを 1 つのドメインにデプロイできます。レプリカは、各 IdM サーバーに機能的に同じである最初の IdM サーバーのクローンで、ユーザー、マシン、証明書、および設定されたポリシーについて同じ内部情報を共有します。
ただし、一度に、環境内のサーバー 1 台のみが対応できる一意のサーバーロールは 2 つあります。
  • CA Renewalation Server: このサーバーは、認証局 (CA) サブシステム証明書の更新を管理します。
  • CRL Generation Server: このサーバーは、証明書失効リスト (CRL) を生成します。
デフォルトでは、最初にインストールした CA サーバーは CA Renewal Server ロールと CRL Generation Server ロールの両方に対応します。たとえば、最初にインストールしたサーバーの使用を停止する必要がある場合などこのロールをトポロジー内の他の CA サーバーに移行できます。どちらのロールも同じサーバーで対応する必要があります。
注記
IdM トポロジーのマシンの種類の詳細は、「Identity Management ドメイン」 を参照してください。
レプリケーション は、レプリカ間でデータをコピーするプロセスです。レプリカ間の情報は、マルチマスターレプリケーション を使用して共有されます。レプリカ合意に参加しているレプリカはすべて、更新を受信するので、データマスターとみなされます。

図4.1 サーバーとレプリカの合意

サーバーとレプリカの合意

4.2. レプリカのデプロイメントに関する考慮事項

4.2.1. トポロジーでのサーバーサービスの分散

IdM サーバーは、認証局 (CA) や DNS など、多数のサービスを実行できます。レプリカは、作成したサーバーと同じサービスを実行できますが、必須ではありません。
たとえば、最初のサーバーが DNS を実行する場合でも、DNS サービスなしでレプリカをインストールできます。同様に、DNS を使用せずに最初のサーバーがインストールされた場合でも、レプリカを DNS サーバーとして設定できます。

図4.2 サービスが異なるレプリカ

サービスが異なるレプリカ
レプリカ上の CA サービス
CA なしでレプリカを設定すると、証明書操作の全要求が、トポロジー内の CA サーバーに転送されます。
警告
Red Hat は、複数のサーバーに CA サービスをインストールすることを強く推奨します。CA サービスを含む初期サーバーのレプリカのインストールは、「CA のあるレプリカのインストール」 を参照してください。
CA を 1 台のサーバーにのみインストールすると、CA サーバーが失敗した場合に CA 設定を復元できる機会なしに CA 設定が失われるリスクがあります。詳細は「失われた CA サーバーの復旧」を参照してください。
レプリカに CA を設定する場合は、その設定が最初のサーバーの CA 設定を反映する必要があります。
  • たとえば、サーバーに統合された IdM CA がルート CA として含まれている場合は、レプリカも統合 CA をルート CA としてインストールする必要があります。
  • サポートされている CA 設定オプションは、「使用する CA 設定の決定」 を参照してください。

4.2.2. レプリカトポロジーの推奨事項

Red Hat では、以下のガイドラインに従うことを推奨します。
1 つの IdM ドメインに 60 を超えるレプリカを設定する
Red Hat は、レプリカが 60 台以下の環境をサポートすることを保証します。
レプリカごとに 少なくても 2 つ多くても 4 つ のレプリカ合意を設定する
追加のレプリカ合意を設定すると、初期レプリカとマスターサーバーとの間だけでなく、他のレプリカ間でも情報が複製されます。
  • サーバー A からレプリカ B を作成し、サーバー A からレプリカ C を作成する場合に、レプリカ B と C は直接連結されていないので、レプリカ B からのデータが先にサーバー A に複製されてから、レプリカ C に伝播する必要があります。

    図4.3 レプリカ B および C はレプリカ合意には参加しない

    レプリカ B および C はレプリカ合意には参加しない
    レプリカ B とレプリカ C の間に追加のレプリカ合意を設定すると、データは直接複製され、データの可用性、一貫性、フェイルオーバーの耐性、およびパフォーマンスが改善されます。

    図4.4 レプリカ B および C はレプリカ合意に参加している

    レプリカ B および C はレプリカ合意に参加している
    レプリカ合意の管理に関する詳細は、6章レプリケーショントポロジーの管理 を参照してください。
レプリカごとに 4 つ以上のレプリカ合意を設定する必要はありません。サーバーごとに多数のレプリカ合意を行っても、1 つのマスターでは、一度に 1 つのコンシューマーサーバーしか更新できないので、その他の合意はアイドル状態で、待機していることになります。また、レプリカ合意を設定しすぎると、全体的なパフォーマンスに影響を及ぼす可能性があります。
注記
ipa topologysuffix-verify コマンドは、トポロジーが最も重要な推奨事項を満たしているかどうかを確認します。詳細は、ipa topologysuffix-verify --help を実行します。
このコマンドには、トポロジーの接尾辞を指定する必要があります。詳細は「レプリカ合意、トポロジー接尾辞、およびトポロジーセグメントの説明」を参照してください。

図4.5 トポロジーの例

トポロジーの例
4.2.2.1. 密接なセルトポロジー
最も回復性の高いトポロジーの 1 つとして、セル内にサーバーが少数あるサーバーとレプリカのセル設定を作成します。
  • 各セルは 密接なセル です。密接なセルでは、すべてのサーバーにはレプリカ合意があります。
  • 各サーバーには、セル 外の 別のサーバーとレプリカ合意があります。これにより、すべてのセルがドメイン内の他のすべてのセルに疎結合されるようになります。
密接なセルトポロジーを実現するには、以下を行います。
  • 各メインオフィス、データセンター、地域に、少なくとも 1 つの IdM サーバーを用意します。可能であれは、2 台の IdM サーバーを用意します。
  • 各データセンターに用意するサーバーは 4 台までとします。
  • 小規模なオフィスでは、レプリカを使用する代わりに、SSSD を使用して認証情報をキャッシュし、オフサイトの IdM サーバーをデータバックエンドとしてキャッシュします。

4.2.3. 非表示のレプリカモード

デフォルトでは、新しいレプリカを設定すると、インストーラーは DNS にサービス (SRV) リソースレコードを自動的に作成します。このレコードにより、クライアントはレプリカとそのサービスを自動検出できます。非表示のレプリカは、稼働中および利用できるすべてのサービスを持つ IdM サーバーです。ただし、DNS に SRV レコードがなく、LDAP サーバーロールが有効になっていません。そのため、クライアントはサービス検出を使用して非表示のレプリカを検出することができません。
注記
非表示のレプリカ機能は、テクノロジープレビューとして Red Hat Enterprise Linux 7.7 以降で利用でき、サポート対象外となります。
非表示のレプリカは、主にクライアントを中断できる専用のサービス用に設計されています。たとえば、IdM の完全バックアップは、マスターまたはレプリカ上のすべての IdM サービスをシャットダウンする必要があります。非表示のレプリカを使用するクライアントはないため、管理者はクライアントに影響を与えることなく、このホスト上のサービスを一時的にシャットダウンできます。その他のユースケースには、大量インポートや詳細なクエリーなど、IdM API または LDAP サーバーの高負荷操作が含まれます。
レプリカを非表示としてインストールするには、--hidden-replica パラメーターを ipa-replica-install コマンドに渡します。レプリカのインストールに関する詳細は、「レプリカの作成: 概要」 を参照してください。
または、既存のレプリカの状態を変更することもできます。詳細は、「非表示のレプリカのデモートおよびプロモート」を参照してください。

4.3. レプリカのインストールの前提条件

レプリカのインストール要件は、IdM サーバーの場合と同じです。レプリカマシンが 「サーバーのインストールの前提条件」 に記載の前提条件をすべて満たしていることを確認してください。
一般的なサーバー要件に加えて、以下の条件を満たしている必要があります。
レプリカは、同じまたはそれ以降のバージョンの IdM を実行している必要があります。
たとえば、マスターサーバーが Red Hat Enterprise Linux 7 で実行され、IdM 4.4 パッケージを使用する場合は、レプリカが Red Hat Enterprise Linux 7 以降で実行され、IdM バージョン 4.4 以降を使用する必要があります。これにより、設定が適切にサーバーからレプリカにコピーされます。
重要
IdM は、以前のバージョンのマスター以外のレプリカ作成に対応していません。以前のバージョンを使用してレプリカを作成しようとすると、インストールに失敗します。
レプリカには、追加でポートを開放する必要があります。
「ポートの要件」 に記載されている標準の IdM サーバーポート要件に加えて、以下の条件にも対応してください。
  • ドメインレベル 0 で、レプリカのセットアッププロセスで TCP ポート 22 をマスターサーバーで開いたままにします。このポートは、マスターサーバーへの接続に SSH を使用するのに必要です。
    注記
    ドメインレベルの詳細は、7章ドメインレベルの表示と引き上げ を参照してください。
  • サーバーの 1 つが Red Hat Enterprise Linux 6 で実行され、CA がインストールされている場合は、レプリカの設定中および後に TCP ポート 7389 を開放したままにします。Red Hat Enterprise Linux 7 だけの環境では、ポート 7389 は必要ありません。
firewall-cmd ユーティリティーを使用してポートを開く方法は、「ポートの要件」 を参照してください。

4.4. レプリカのインストールに必要なパッケージ

レプリカパッケージ要件は、サーバーパッケージの要件と同じです。「IdM サーバーのインストールに必要なパッケージ」を参照してください。

4.5. レプリカの作成: 概要

ipa-replica-install ユーティリティーを使用して、既存の IdM サーバーから新しいレプリカをインストールします。Identity Management レプリカは一度に 1 つずつインストールしてください。同時に複数のレプリカをインストールすることはサポートされません。
注記
本章では、Red Hat Enterprise Linux 7.3 で導入された、レプリカの簡素化インストールについて説明します。この手順で必要なドメインレベルは 1 です (7章ドメインレベルの表示と引き上げを参照)。
ドメインレベル 0 でレプリカをインストールする方法は、??? を参照してください。
新しいレプリカをインストールできます。
このいずれの状況でも、ipa-replica-install にオプションを追加すると、レプリカをカスタマイズできます。「ipa-replica-install を使用したユースケースに対するレプリカの設定」 を参照してください。
レプリカを非表示としてインストールするには、--hidden-replica パラメーターを ipa-replica-install に渡します。非表示のレプリカの詳細は、「非表示のレプリカモード」 を参照してください。
重要
複製中の IdM サーバーが Active Directory と信頼関係がある場合は、ipa-replica-install を実行した後にレプリカを信頼エージェントとして設定します。『Windows Integration Guide』のTrust Controllers and Trust Agentsを参照してください。
既存のクライアントのレプリカへのプロモート
既存のクライアントにレプリカをインストールするには、クライアントのプロモートが許可されていることを確認する必要があります。これを行うには、以下のいずれかを選択します。
特権ユーザーの認証情報を指定する
デフォルトの特権ユーザーは admin です。ユーザーの認証情報を指定する方法は複数あります。これにより、以下が可能になります。
  • IdM により、対話的に認証情報を取得するようにプロンプトが表示されます。
    注記
    これは、特権ユーザーの認証情報を指定するデフォルトの方法です。ipa-replica-install の実行時に認証情報が利用できない場合には、インストールで自動的にプロンプトが表示されます。
  • クライアントで ipa-replica-install を実行する前にユーザーとしてログインします。
    $ kinit admin
  • ユーザーのプリンシパル名とパスワードを ipa-replica-install に直接追加します。
    # ipa-replica-install --principal admin --admin-password admin_password
クライアントを ipaservers ホストグループに追加する
ipaservers のメンバーシップは、マシンの権限を特権ユーザーの認証情報と同様の権限に昇格します。ユーザーの認証情報を指定する必要はありません。
クライアントではないマシンへのレプリカのインストール
IdM ドメインに登録されていないマシンで実行すると、ipa-replica-install は最初にマシンをクライアントとして登録してから、レプリカコンポーネントをインストールします。
この状況でレプリカをインストールするには、以下のいずれかを選択します。
特権ユーザーの認証情報を指定する
デフォルトの特権ユーザーは admin です。認証情報を指定するには、プリンシパル名とパスワードを ipa-replica-install に直接追加します。
# ipa-replica-install --principal admin --admin-password admin_password
クライアントのパスワードを無作為に指定する
レプリカをインストールする前に、サーバーで無作為のパスワードを生成する必要があります。インストール時にユーザーの認証情報を指定する必要はありません。
デフォルトでは、レプリカはクライアントインストーラーで検出された最初の IdM サーバーに対してインストールされます。特定のサーバーに対してレプリカをインストールするには、ipa-replica-install に以下のオプションを追加します。
  • --server - サーバーの完全修飾ドメイン名 (FQDN)
  • --domain - IdM DNS ドメイン
ipa-replica-install を使用したユースケースに対するレプリカの設定
オプションなしで実行すると、ipa-replica-install は基本的なサーバーサービスのみを設定します。DNS や認証局 (CA) などの追加のサービスをインストールするには、ipa-replica-install にオプションを追加します。
警告
Red Hat は、複数のサーバーに CA サービスをインストールすることを強く推奨します。CA サービスを含む初期サーバーのレプリカのインストールは、「CA のあるレプリカのインストール」 を参照してください。
CA を 1 台のサーバーにのみインストールすると、CA サーバーが失敗した場合に CA 設定を復元できる機会なしに CA 設定が失われるリスクがあります。詳細は「失われた CA サーバーの復旧」を参照してください。
最も主要なオプションを使用したレプリカのインストールに関するシナリオ例については以下を参照してください。
--dirsrv-config-file パラメーターを使用して、カスタム値を持つ LDIF ファイルへのパスを指定すると、デフォルトの Directory Server 設定を変更することもできます。詳細は、『Release Notes for Red Hat Enterprise Linux 7.3』のIdM now supports setting individual Directory Server options during server or replica installationを参照してください。
レプリカの設定に使用するオプションの完全リストは、ipa-replica-install(1) の man ページを参照してください。

4.5.1. ホストキータブを使用したクライアントのレプリカへのプロモート

この手順では、独自のホストキータブを使用して既存の IdM クライアントがレプリカにプロモートされ、プロモーションが認可されます。
この手順では、管理者または Directory Manager (DM) の認証情報を指定する必要はありません。そのため、機密情報がコマンドラインで公開されないため、安全性が向上します。
  1. 既存のサーバーの場合:
    1. 管理者としてログインします。
      $ kinit admin
    2. クライアントマシンを ipaservers ホストグループに追加します。
      $ ipa hostgroup-add-member ipaservers --hosts client.example.com
        Host-group: ipaservers
        Description: IPA server hosts
        Member hosts: server.example.com, client.example.com
      -------------------------
      Number of members added 1
      -------------------------
      ipaservers のメンバーシップは、マシンの権限を管理者の認証情報と同様の権限に昇格します。
  2. クライアントで ipa-replica-install ユーティリティーを実行します。
    # ipa-replica-install
  3. オプションで、複製する IdM サーバーに Active Directory と信頼関係がある場合は、信頼エージェントまたは信頼コントローラーとしてレプリカを設定します。詳細は、『Windows Integration Guide』のTrust Controllers and Trust Agentsを参照してください。

4.5.2. 無作為のパスワードを使用したレプリカのインストール

この手順では、IdM クライアントではないマシンにレプリカをゼロからインストールします。登録を承認するには、クライアント登録 1 回だけに有効なクライアント固有に作成せれた無作為のパスワードを使用します。
この手順では、管理者または Directory Manager (DM) の認証情報を指定する必要はありません。そのため、機密情報がコマンドラインで公開されないため、安全性が向上します。
  1. 既存のサーバーの場合:
    1. 管理者としてログインします。
      $ kinit admin
    2. 新しいマシンを 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 ドメインへのマシン登録に使用した後は無効になります。登録の完了後、このパスワードは適切なホストキータブに置き換えられます。
    3. マシンを ipaservers のホストグループに追加します。
      $ ipa hostgroup-add-member ipaservers --hosts client.example.com
        Host-group: ipaservers
        Description: IPA server hosts
        Member hosts: server.example.com, client.example.com
      -------------------------
      Number of members added 1
      -------------------------
      ipaservers のメンバーは、必須サーバーサービスの設定に必要な特権にマシンを昇格します。
  2. レプリカをインストールするマシンで、ipa-replica-install を実行し、--password オプションを使用して無作為のパスワードを指定します。特殊文字が含まれるため、パスワードを一重引用符 (') で囲みます。
    # ipa-replica-install --password 'W5YpARl=7M.n'
  3. オプションで、複製する IdM サーバーに Active Directory と信頼関係がある場合は、信頼エージェントまたは信頼コントローラーとしてレプリカを設定します。詳細は、『Windows Integration Guide』のTrust Controllers and Trust Agentsを参照してください。

4.5.3. DNS のあるレプリカのインストール

この手順は、IdM ドメインに所属していないマシン、およびクライアントでレプリカをインストールする場合に使用します。詳細は「レプリカの作成: 概要」を参照してください。
  1. 以下のオプションを使用して、ipa-replica-install を実行します。
    • --setup-dns - DNS ゾーンが存在しない場合は作成し、レプリカを DNS サーバーとして設定します。
    • --forwarder - フォワーダーを指定します。フォワーダーを使用しない場合は --no-forwarder を指定します。
      フェイルオーバーのために複数のフォワーダーを指定するには、--forwarder を複数回使用します。
    以下に例を示します。
    # ipa-replica-install --setup-dns --forwarder 192.0.2.1
    注記
    ipa-replica-install ユーティリティーは、--no-reverse--no-host-dns などの DNS 設定に関する複数のオプションを受け入れます。詳細は ipa-replica-install(1) の man ページを参照してください。
  2. DNS を有効にして最初のサーバーが作成した場合には、適切な DNS エントリーでレプリカが自動的に作成されます。これらのエントリーにより、IdM クライアントが新しいサーバーを検出できるようになります。
    初期サーバーで DNS が有効になっていない場合は、DNS レコードを手動で追加します。ドメインサービスには、以下の DNS レコードが必要です。
    • _ldap._tcp
    • _kerberos._tcp
    • _kerberos._udp
    • _kerberos-master._tcp
    • _kerberos-master._udp
    • _ntp._udp
    • _kpasswd._tcp
    • _kpasswd._udp
    この例では、エントリーが存在することを確認する方法を説明します。
    1. DOMAIN 変数および NAMESERVER 変数に適切な値を設定します。
      # DOMAIN=example.com
      # NAMESERVER=replica
    2. 以下のコマンドを使用して、DNS エントリーを確認します。
      # for i in _ldap._tcp _kerberos._tcp _kerberos._udp _kerberos-master._tcp _kerberos-master._udp _ntp._udp ; do
      dig @${NAMESERVER} ${i}.${DOMAIN} srv +nocmd +noquestion +nocomments +nostats +noaa +noadditional +noauthority
      done | egrep "^_"
      
      _ldap._tcp.example.com. 86400     IN    SRV     0 100 389 server1.example.com.
      _ldap._tcp.example.com. 86400     IN    SRV     0 100 389 server2.example.com.
      _kerberos._tcp.example.com. 86400 IN    SRV     0 100 88  server1.example.com.
      ...
  3. 親ドメインから ldM DNS ドメインに DNS 委譲を追加します。たとえば、IdM DNS ドメインが ipa.example.com の場合は、ネームサーバー (NS) レコードを親ドメイン example.com に追加します。
    重要
    この手順は、IdM DNS サーバーをインストールするたびに繰り返す必要があります。
  4. 任意ですが、推奨されます。レプリカが利用できなくなった場合に、他の DNS サーバーをバックアップサーバーとして手動で追加します。「ネームサーバーの追加設定」を参照してください。これは、新しいレプリカが IdM ドメインの最初の DNS サーバーになる場合に特に推奨されます。
  5. オプションで、複製する IdM サーバーに Active Directory と信頼関係がある場合は、信頼エージェントまたは信頼コントローラーとしてレプリカを設定します。詳細は、『Windows Integration Guide』のTrust Controllers and Trust Agentsを参照してください。

4.5.4. CA のあるレプリカのインストール

この手順は、IdM ドメインに所属していないマシン、およびクライアントでレプリカをインストールする場合に使用します。詳細は「レプリカの作成: 概要」を参照してください。
  1. --setup-ca オプションを指定して ipa-replica-install を実行します。
    [root@replica ~]# ipa-replica-install --setup-ca
  2. --setup-ca オプションは、サーバーの IdM CA がルート CA であるか、外部 CA に従属しているかに関係なく、最初のサーバーの設定から CA 設定をコピーします。
    注記
    サポート対象の CA 設定の詳細は、「使用する CA 設定の決定」 を参照してください。
  3. オプションで、複製する IdM サーバーに Active Directory と信頼関係がある場合は、信頼エージェントまたは信頼コントローラーとしてレプリカを設定します。詳細は、『Windows Integration Guide』のTrust Controllers and Trust Agentsを参照してください。

4.5.5. CA のないサーバーからのレプリカのインストール

この手順は、IdM ドメインに所属していないマシン、およびクライアントでレプリカをインストールする場合に使用します。詳細は「レプリカの作成: 概要」を参照してください。
重要
自己署名のサードパーティーサーバー証明書を使用してサーバーまたはレプリカをインストールすることはできません。
  1. ipa-replica-install を実行して、次のオプションを追加して必要な証明書ファイルを指定します。
    • --dirsrv-cert-file
    • --dirsrv-pin
    • --http-cert-file
    • --http-pin
    このようなオプションを使用して提供されるファイルに関する詳細は、「CA なしでのインストール」 を参照してください。
    以下に例を示します。
    [root@replica ~]# 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 ユーティリティーは、マスターサーバーから証明書のこの部分の情報を自動的に取得します。
  2. オプションで、複製する IdM サーバーに Active Directory と信頼関係がある場合は、信頼エージェントまたは信頼コントローラーとしてレプリカを設定します。詳細は、『Windows Integration Guide』のTrust Controllers and Trust Agentsを参照してください。

4.6. 新規レプリカのテスト

レプリカの作成後にレプリケーションが想定どおりに機能するかどうかを確認するには、以下を実行します。
  1. サーバーのいずれかでユーザーを作成します。
    [admin@server1 ~]$ ipa user-add test_user --first=Test --last=User
  2. ユーザーが他のサーバーで表示されることを確認します。
    [admin@server2 ~]$ ipa user-show test_user

4.7. レプリカのアンインストール

パート III. 管理: サーバーの管理

本パートでは、アイデンティティー管理 サーバーとサービスの管理、アイデンティティー管理 ドメインのサーバー間のレプリケーションなどの管理関連のトピックと、アイデンティティー管理 トポロジーの詳細を説明し、システムの アイデンティティー管理 パッケージを更新する方法を説明します。さらに、このパートでは、アイデンティティー管理のデプロイメントに影響を与える障害が発生した場合に、アイデンティティー管理 システムのバックアップを手動で作成して復元する方法を説明します。最後の章では、さまざまな内部アクセス制御メカニズムの詳細を説明します。

第5章 IdM サーバーおよびサービスの基本的な管理

本章では、IdM に対して認証する方法など、IdM サーバーおよびサービスの管理に使用できる Identity Management のコマンドラインおよび UI ツールを説明します。

5.1. IdM サーバーの起動と停止

Directory Server、認証局 (CA)、DNS、Kerberos など、さまざまなサービスが IdM サーバーとともにインストールされます。ipactl ユーティリティーを使用して、IdM サーバー全体と、インストールしたサービスをすべて停止、起動 (開始)、または再起動 (再開) します。
IdM サーバー全体を起動するには、次のコマンドを実行します。
# ipactl start
IdM サーバー全体を停止するには、次のコマンドを実行します。
# ipactl stop
IdM サーバー全体を再起動するには、次のコマンドを実行します。
# ipactl restart
個々のサービスを停止、起動、または再起動するだけの場合は、システム管理者のガイドで説明されている systemctl ユーティリティーを使用します。たとえば、systemctl を使用した個別のサービスの管理は、Directory Server の動作をカスタマイズする場合に便利です。設定の変更には Directory Server インスタンスを再起動する必要がありますが、すべての IdM サービスを再起動する必要はありません。
重要
Red Hat は、複数の IdM ドメインサービスを再起動するには、常に ipactl を使用することを推奨しています。IdM サーバーにインストールされているサービス間での依存関係により、サービスを開始および停止する順番は極めて重要です。ipactl ユーティリティーは、サービスが適切な順番で開始および停止するようにします。

5.2. Kerberos を使用した IdM へのログイン

IdM は、シングルサインオンに対応する Kerberos プロトコルを使用します。Kerberos では、正しいユーザー名とパスワードを一度提示するだけで済み、システムから認証情報を再度求められることなく IdM サービスにアクセスできます。
デフォルトでは、IdM ドメインのメンバーであるマシンのみが、Kerberos を使用して IdM に対して認証できます。ただし、Kerberos 認証用に外部システムを設定することもできます。詳細は、「Web UI への Kerberos 認証のための外部システムの設定」 を参照してください。
kinit の使用
コマンドラインから IdM にログインするには、kinit ユーティリティーを使用します。
注記
kinit を使用するには、krb5-workstation パッケージをインストールする必要があります。
ユーザー名を指定せずに実行する場合は、ローカルシステムに現在ログインしているユーザーのユーザー名で kinit を使用して IdM にログインします。たとえば、ローカルシステムで local_user としてログインしている場合は、kinit を実行すると、local_user IdM ユーザーとして認証を試みます。
[local_user@server ~]$ kinit
Password for local_user@EXAMPLE.COM:
注記
ローカルユーザーのユーザー名と、IdM のユーザーエントリーが一致しないと、認証に失敗します。
別の IdM ユーザーとしてログインするには、必要なユーザー名をパラメーターとして kinit ユーティリティーに渡します。たとえば、admin ユーザーとしてログインするには、次のコマンドを実行します。
[local_user@server ~]$ kinit admin
Password for admin@EXAMPLE.COM:
Kerberos チケットの自動取得
IdM クライアントマシンのデスクトップ環境に正常にログインした後に、ユーザーの TGT を自動取得するように、pam_krb5 の PAM (Pluggable Authentication Module) および SSSD を設定することができます。これにより、ログイン後に kinit の実行は必要ありません。
ID および認証プロバイダーとして SSSD で IdM を設定した IdM システムでは、ユーザーが対応する Kerberos プリンシパル名でログインした後に TGT を自動的に取得します。
pam_krb5 の設定に関する詳細は、pam_krb5(8) man ページを参照してください。PAM に関する一般的な情報は、システムレベルの認証ガイドを参照してください。
複数の Kerberos チケットの保存
デフォルトでは、Kerberos は、ログインしたユーザーごとに認証情報キャッシュにチケットを 1 つだけ保存します。ユーザーが kinit を実行すると、Kerberos は、現在保存されているチケットを新しいチケットで上書きします。たとえば、kinit を使用して user_A として認証すると、user_B として再度認証した後に user_A のチケットが失われます。
ユーザーの別の TGT を取得して保存するには、異なる認証情報キャッシュを設定します。これにより、以前のキャッシュの内容が上書きされないようにします。これは、以下のいずれかの方法で実行できます。
  • export KRB5CCNAME=path_to_different_cache コマンドを実行してから、kinit を使用してチケットを取得します。
  • kinit -c path_to_different_cache コマンドを実行してから、KRB5CCNAME 変数をリセットします。
デフォルトの認証情報キャッシュに保存されている元の TGT を復元するには、以下を実行します。
  1. kdestroy コマンドを実行します。
  2. unset $KRB5CCNAME コマンドを使用して、デフォルトの認証キャッシュの場所を復元します。
現在ログインしているユーザーの確認
現在保存されている TGT が、認証に使用されることを確認するには、klist ユーティリティーを使用して、キャッシュされたチケットをリスト表示します。以下の例では、キャッシュに user_A のチケットが含まれています。これは、現在 IdM サービスにアクセスすることができる user_A のみになります。
$ klist
Ticket cache: KEYRING:persistent:0:0
Default principal: user_A@EXAMPLE.COM

Valid starting     	Expires            	Service principal
11/10/2015 08:35:45  	11/10/2015 18:35:45  	krbtgt/EXAMPLE.COM@EXAMPLE.COM

5.3. IdM コマンドラインユーティリティー

IdM の基本的なコマンドラインスクリプトの名前は ipa です。ipa スクリプトは、多数のサブコマンドの親スクリプトです。これらのサブコマンドは、IdM の管理に使用されます。たとえば、ipa user-add コマンドは、新しいユーザーを追加します。
$ ipa user-add user_name
コマンドライン管理には、UI での管理に比べていくつかの利点があります。たとえば、コマンドラインユーティリティーを使用すると、手動で介入することなく、管理タスクを自動化して、一貫した方法で繰り返し実行することができます。さらに、ほとんどの管理操作はコマンドラインと Web UI の両方で利用できますが、一部のタスクはコマンドラインからのみ実行できます。
注記
本セクションでは、ipa サブコマンドの概要のみを説明します。詳細は、IdM 管理の特定のエリア専用の他のセクションを参照してください。たとえば、ipa サブコマンドを使用してユーザーエントリーを管理する方法は、11章ユーザーアカウントの管理 を参照してください。

5.3.1. ipa コマンドのヘルプの取得

ipa スクリプトは、特定のサブコマンドのヘルプ (トピック) を表示できます。利用可能なトピックのリストを表示するには、ipa help topics コマンドを使用します。
$ ipa help topics

automember         Auto Membership Rule.
automount          Automount
caacl              Manage CA ACL rules.
...
特定のトピックのヘルプを表示するには、ipa help topic_name コマンドを使用します。たとえば、automember トピックに関する情報を表示するには、以下を実行します。
$ ipa help automember

Auto Membership Rule.

Bring clarity to the membership of hosts and users by configuring inclusive
or exclusive regex patterns, you can automatically assign a new entries into
a group or hostgroup based upon attribute information.

...

EXAMPLES:

 Add the initial group or hostgroup:
   ipa hostgroup-add --desc="Web Servers" webservers
   ipa group-add --desc="Developers" devel
...
ipa スクリプトは、利用可能な ipa コマンドのリストを表示することもできます。これには、ipa help commands コマンドを使用します。
$ ipa help commands
automember-add                         Add an automember rule.
automember-add-condition               Add conditions to an automember rule.
...
ipa コマンドの詳細は、コマンドに --help オプションを追加します。以下に例を示します。
$ ipa automember-add --help

Usage: ipa [global-options] automember-add AUTOMEMBER-RULE [options]

Add an automember rule.
Options:
  -h, --help            show this help message and exit
  --desc=STR            A description of this auto member rule
...
ipa ユーティリティーの詳細は、ipa(1) の man ページを参照してください。

5.3.2. 値のリストの設定

IdM は、エントリー属性をリストに保存します。以下に例を示します。
ipaUserSearchFields: uid,givenname,sn,telephonenumber,ou,title
属性のリストへの更新は、前のリストを上書きします。たとえば、1 つの属性だけを指定してその属性を追加しようとすると、以前に定義したリストがすべて新しい 1 つの属性に置き換えられます。したがって、属性のリストを変更する場合は、更新されたリスト全体を指定する必要があります。
IdM は、属性のリストを指定する以下の方法に対応します。
  • 同じコマンド呼び出しで、同じコマンドライン引数を複数回指定します。以下に例を示します。
    $ ipa permission-add --permissions=read --permissions=write --permissions=delete
  • リストを中括弧で囲むことで、シェルが拡張を行うことができます。以下に例を示します。
    $ ipa permission-add --permissions={read,write,delete}

5.3.3. 特殊文字の使用

ipa コマンドで、山括弧 (< および >)、アンパサンド (&)、アステリスク (*)、パイプ (|) などの特殊文字が含まれるコマンドラインの引数を指定すると、バックスラッシュ (\) を使用してこのような特殊文字をエスケープする必要があります。たとえば、アスタリスク (*) をエスケープするには、次のコマンドを実行します。
$ ipa certprofile-show certificate_profile --out=exported\*profile.cfg
シェルが特殊文字を正しく解析できないため、エスケープしていない特殊文字をコマンドに含めると、予想通りに機能しなくなります。

5.3.4. IdM エントリーの検索

IdM エントリーのリスト表示
ipa *-find コマンドを使用して、特定のタイプの IdM エントリーを検索します。以下に例を示します。
  • 全ユーザーをリスト表示するには、以下を実行します。
    $ ipa user-find
    ---------------
    4 users matched
    ---------------
      ...
  • 指定の属性に keyword が含まれるユーザーグループのリストを表示するには、次のコマンドを実行します。
    $ ipa group-find keyword
    ----------------
    2 groups matched
    ----------------
      ...
    IdM がユーザーおよびグループを検索する属性を設定するには、「ユーザーおよびユーザーグループの検索属性の設定」 を参照してください。
ユーザーグループの検索の際には、特定のユーザーを含むグループに検索結果を絞り込むことも可能です。
$ ipa group-find --user=user_name
特定のユーザーを含まないグループを検索することもできます。
$ ipa group-find --no-user=user_name
特定のエントリーの詳細の表示
ipa *-show コマンドを使用して、特定の IdM エントリーの詳細を表示します。以下に例を示します。
$ ipa host-show server.example.com
 Host name: server.example.com
 Principal name: host/server.example.com@EXAMPLE.COM
 ...
5.3.4.1. 検索サイズおよび時間制限の調整
ユーザーリストの表示など、検索結果によっては、非常に多くのエントリーを返す場合があります。この検索操作を調整して、ipa user-find などの ipa *-find コマンドの実行時や、Web UI で対応するリストを表示する際に、全体的なサーバーのパフォーマンスを向上できます。
検索サイズの制限
  • クライアント、Idm コマンドラインツール、または IdM Web UI からサーバーに送信されるリクエストで返される最大エントリー数を定義します。
  • デフォルト値:100 エントリー
検索時間の制限
  • サーバーが検索の実行を待つ最大時間を定義します。検索がこの制限に到達したら、サーバーは検索を停止し、停止するまでの期間に検出されたエントリーを返します。
  • デフォルト値:2 秒
この値が -1 に設定されていると、IdM は、検索時に制限を適用しません。
重要
検索のサイズや時間制限を高く設定しすぎると、サーバーのパフォーマンスに影響を及ぼすことがあります。
Web UI: 検索サイズおよび時間制限の調整
全クエリーに対して、グローバルに制限を調節するには、以下を行います。
  1. IPA ServerConfiguration を選択します。
  2. Search Options エリアに必要な値を設定します。
  3. ページ上部にある Save をクリックします。
コマンドライン: 検索サイズおよび時間制限の調整
全クエリーに対してグローバルに制限を調整するには、ipa config-mod コマンドを使用して、--searchrecordslimit オプションおよび --searchtimelimit オプションを指定します。以下に例を示します。
$ ipa config-mod --searchrecordslimit=500 --searchtimelimit=5
コマンドラインから、特定のクエリーに対してのみ制限を調整することもできます。これを行うには、--sizelimit オプションまたは --timelimit オプションをコマンドに追加します。以下に例を示します。
$ ipa user-find --sizelimit=200 --timelimit=120
重要
ipa config-mod コマンドを使用して、--searchrecordslimit オプションまたは --searchtimelimit オプションを指定してサイズまたは時間制限を調整すると、ipa user-find などの ipa コマンドによって返されたエントリーの数に影響することに注意してください。
これらの制限に加えて、Directory Server レベルで設定される設定も考慮され、より厳しい制限が適用される場合があります。Directory Server の制限に関する詳細は、Red Hat Directory Server 管理ガイド を参照してください。

5.4. IdM Web UI

Identity Management の Web UI は、IdM 管理用の Web アプリケーションです。これには、ipa コマンドラインユーティリティーの機能の大部分が含まれます。そのため、UI またはコマンドラインのどちらから IdM を管理するかを選択できます。
注記
ログインしているユーザーが利用できる管理操作は、ユーザーのアクセス権限によって異なります。管理者権限を持つ admin ユーザーおよびその他のユーザーの場合は、すべての管理タスクが利用可能になります。通常ユーザーは、自身のユーザーアカウントに関連する限定された一連の操作のみを利用できます。

5.4.1. サポート対象の Web ブラウザー

Identity Management では、以下のブラウザーを使用して、Web UI に接続できます。
  • Mozilla Firefox 38 以降
  • Google Chrome 46 以降

5.4.2. Web UI へのアクセスおよび認証

Web UI には、IdM サーバーおよびクライアントマシンの両方、および IdM ドメイン外のマシンからもアクセスできます。ただし、ドメイン以外のマシンから UI にアクセスするには、IdM 以外のシステムを IdM Kerberos ドメインに接続できるように設定する必要があります。詳細は、「Web UI への Kerberos 認証のための外部システムの設定」 を参照してください。
5.4.2.1. Web UI へのアクセス
Web UI にアクセスするには、ブラウザーのアドレスバーに IdM サーバーの URL を入力します。
https://server.example.com
これで、ブラウザーに IdM Web UI ログイン画面が開きます。

図5.1 Web UI のログイン画面

Web UI のログイン画面
5.4.2.2. 利用可能なログイン方法
ユーザーは、以下の方法で Web UI に対して認証できます。
アクティブな Kerberos チケットの使用
kinit ユーティリティーで有効な TGT を取得した場合は、ログイン をクリックすると自動的にユーザーを認証します。Kerberos 認証に対応するようにブラウザーを適切に設定する必要があります。
Kerberos TGT を取得する方法は、「Kerberos を使用した IdM へのログイン」 を参照してください。ブラウザーの設定に関する詳細は、「Kerberos 認証用のブラウザーの設定」 を参照してください。
ユーザー名とパスワードの指定
ユーザー名とパスワードを使用して認証するには、Web UI のログイン画面にユーザー名とパスワードを入力します。
IdM は、ワンタイムパスワード (OTP) 認証にも対応しています。詳細な情報は、「ワンタイムパスワード」 を参照してください。
スマートカードの使用
ユーザーが正常に認証されると、IdM 管理ウィンドウが開きます。

図5.2 IdM Web UI レイアウト

IdM Web UI レイアウト
5.4.2.3. Web UI セッションの長さ
ユーザー名とパスワードを使用して IdM Web UI にログインすると、セッションの長さはログイン操作時に取得した Kerberos チケットの有効期限と同じになります。
5.4.2.4. AD ユーザーとしての IdM Web UI への認証
Active Directory(AD) ユーザーは、ユーザー名とパスワードを使用して IdM Web UI にログインできます。Web UI では、AD ユーザーは、管理者権限に関連する管理操作を実行できる IdM ユーザーとは異なり、自分のユーザーアカウントに関連する限定された操作のみを実行できます。
AD ユーザーに Web UI ログインを有効にするには、IdM 管理者は、Default Trust View で各 AD ユーザーの ID オーバーライドを定義する必要があります。以下に例を示します。
[admin@server ~]$ ipa idoverrideuser-add 'Default Trust View' ad_user@ad.example.com
AD の ID ビューの詳細は、『Windows Integration Guide』のUsing ID Views in Active Directory Environmentsを参照してください。

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

Kerberos 認証情報での認証を有効にするには、IdM ドメインにアクセスするための Kerberos ネゴシエーションに対応するようにブラウザーを設定する必要があります。ブラウザーが Kerberos 認証に対して適切に設定されていない場合は、IdM Web UI のログイン画面で Login をクリックするとエラーメッセージが表示されます。

図5.3 Kerberos 認証エラーメッセージ

Kerberos 認証エラーメッセージ
Kerberos 認証用に、ブラウザーを以下の 3 つの方法で設定できます。
注記
System-Level Authentication Guide』には、Troubleshooting Firefox Kerberos Configurationが含まれます。Kerberos 認証が想定どおりに機能していない場合は、トラブルシューティングガイドで、他のアドバイスを参照してください。
Web UI での Firefox の自動設定
IdM Web UI から Firefox を自動的に設定するには、以下を実施します。
  1. Web UI のログイン画面で、ブラウザー設定のリンクをクリックします。
  2. Firefox 設定のリンクを選択して、Firefox 設定ページを開きます。
  3. Firefox 設定ページの手順に従います。
コマンドラインからの Firefox の自動設定
Firefox は、IdM クライアントのインストール時にコマンドラインから設定できます。これには、ipa-client-install ユーティリティーを使用して IdM クライアントをインストールする場合は --configure-firefox オプションを使用します。
# ipa-client-install --configure-firefox
--configure-firefox オプションは、シングルサインオン (SSO) で Kerberos を有効にするデフォルトの Firefox 設定でグローバル設定ファイルを作成します。
手動のブラウザー設定
ブラウザーを手動で設定するには、以下を実行します。
  1. Web UI のログイン画面で、ブラウザー設定のリンクをクリックします。
  2. 手動のブラウザー設定のリンクを選択します。
  3. ブラウザーを設定する手順を探し、手順に従ってください。

5.4.4. Web UI への Kerberos 認証のための外部システムの設定

IdM ドメインのメンバーではないシステムから Web UI への Kerberos 認証を有効にするには、IdM 固有の Kerberos 設定ファイルを外部マシンに定義する必要があります。外部システムの Kerberos 認証を有効にすることは、インフラストラクチャーに、複数のレルムまたは重複ドメインが含まれている場合に特に便利です。
Kerberos 設定ファイルを作成するには、以下を実行します。
  1. IdM サーバーから外部マシンに /etc/krb5.conf ファイルをコピーします。以下に例を示します。
    # scp /etc/krb5.conf root@externalmachine.example.com:/etc/krb5_ipa.conf
    警告
    外部マシンにある既存の krb5.conf ファイルは上書きしないでください。
  2. 外部マシン上で、端末のセッションがコピーされた IdM Kerberos 設定ファイルを使用するよう設定します。
    $ export KRB5_CONFIG=/etc/krb5_ipa.conf
  3. 「Kerberos 認証用のブラウザーの設定」 の説明に従って、外部マシンにブラウザーを設定します。
外部システムのユーザーが、kinit ユーティリティーを使用して IdM サーバードメインで認証できるようになりました。

5.4.5. プロキシーサーバーおよび Web UI でのポート転送

Web UI にアクセスするためにプロキシーサーバーを使用する場合は、IdM で追加の設定は必要ありません。
ポート転送は IdM サーバーではサポートされていませんが、IdM ではプロキシーサーバーを使用できるので、OpenSSH と SOCKS オプションでプロキシー転送を使用して、ポート転送に似た操作を設定できます。ただし、プロキシーサーバーを使用できるため、OpenSSH および SOCKS オプションで、プロキシー転送を使用して、ポート転送に似た操作を設定できます。これは、ssh ユーティリティーの -D オプションで設定できます。-D の使用方法は、ssh(1) の man ページを参照してください。

第6章 レプリケーショントポロジーの管理

本章では、Identity Management(IdM) ドメイン内のサーバー間のレプリケーションを管理する方法を説明します。
注記
本章では、Red Hat Enterprise Linux 7.3 で導入された簡素化されたトポロジー管理について説明します。この手順で必要なドメインレベルは 1 です (7章ドメインレベルの表示と引き上げを参照)。
ドメインレベル 0 でのトポロジーの管理に関するドキュメントは、「レプリカおよびレプリカ合意の管理」 を参照してください。
初期レプリカのインストールとレプリケーションに関する基本情報は、4章Identity Management のレプリカのインストールとアンインストール を参照してください。

6.1. レプリカ合意、トポロジー接尾辞、およびトポロジーセグメントの説明

レプリカ合意
IdM サーバーに保存されているデータは、レプリカ合意に基づいて複製されます。2 台のサーバーでレプリカ合意が設定されている場合は、データを共有します。
レプリカ合意は常に双方向のものです。最初のレプリカからサーバーから別のレプリカにデータが複製されるだけでなく、別ののレプリカから最初のレプリカにもデータが複製されます。
注記
詳細は、「IdM レプリカの説明」 を参照してください。
トポロジー接尾辞
トポロジーの接尾辞は、レプリケートされるデータを保存します。IdM は、domainca の 2 種類のトポロジー接尾辞に対応します。それぞれの接尾辞は、個別のバックエンドである個別のレプリケーショントポロジーを表します。
レプリカ合意が設定されると、同じタイプのトポロジー接尾辞を 2 つの異なるサーバーに結合します。
domain 接尾辞: dc=example,dc=com
domain 接尾辞には、ドメイン関連のデータがすべて含まれています。
2 つのレプリカの domain 接尾辞間でレプリカ合意が設定されると、ユーザー、グループ、およびポリシーなどのディレクトリーデータが共有されます。
ca 接尾辞: o=ipaca
ca 接尾辞には、Certificate System コンポーネントのデータが含まれます。これは認証局 (CA) がインストールされているサーバーにのみ存在します。
2 つのレプリカの ca 接尾辞間でレプリカ合意が設定されると、証明書データが共有されます。

図6.1 トポロジー接尾辞

トポロジー接尾辞
新規レプリカのインストール時には、ipa-replica-install スクリプトが 2 つのサーバー間に初期トポロジーセグメントをセットアップします。

例6.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 つのレプリカの接尾辞間でレプリカ合意があると、接尾辞は topology segment を形成します。各トポロジーセグメントは、左ノード右ノード で設定されます。ノードは、レプリカ合意に参加しているサーバーを表します。
IdM のトポロジーセグメントは常に双方向です。各セグメントは、サーバー A からサーバー B、およびサーバー B からサーバー A への 2 つのレプリカ合意を表します。そのため、データは両方の方向でレプリケートされます。

図6.2 トポロジーセグメント

トポロジーセグメント

例6.2 トポロジーセグメントの表示

ipa topologysegment-find コマンドで、domain または 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.comserver1.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

6.2. Web UI: トポロジーグラフを使用したレプリケーショントポロジーの管理

トポロジーグラフへのアクセス
Web UI のトポロジーグラフは、ドメイン内のサーバー間の関係を表示します。
  1. IPA ServerTopologyGraph を選択します。
  2. トポロジーに加えた変更がグラフに反映されていない場合は、Refresh をクリックします。
トポロジービューのカスタマイズ
マウスをドラッグして、個別のトポロジーノードを移動できます。

図6.3 トポロジーグラフのノードの移動

トポロジーグラフのノードの移動
マウスのホイールを使用して、トポロジーグラフを拡大および縮小できます。

図6.4 トポロジーグラフのズーム

トポロジーグラフのズーム
マウスの左ボタンを保持することで、トポロジーグラフのキャンバスを移動できます。

図6.5 トポロジーグラフのキャンバスの移動

トポロジーグラフのキャンバスの移動
トポロジーグラフの解釈
ドメインのレプリカ合意に参加しているサーバーは、オレンジ色の矢印によって接続されます。CA のレプリカ合意に参加しているサーバーは、青色の矢印によって接続されます。
トポロジーグラフの例: 推奨されるトポロジー
図6.6「推奨されるトポロジーの例」 は、4 つのサーバーで推奨されるトポロジーの例を 1 つ示しています。各サーバーは少なくとも 2 台のサーバーに接続されており、複数のサーバーが CA マスターになります。

図6.6 推奨されるトポロジーの例

推奨されるトポロジーの例
トポロジーグラフの例: 推奨されないトポロジー
図6.7「推奨されないトポロジーの例: 単一障害点」server1 は単一障害点になります。その他のすべてのサーバーは、このサーバーとのレプリカ合意がありますが、他のサーバーとは合意がありません。したがって、server1 が失敗すると、他のすべてのサーバーは分離されます。
このようなトポロジーの作成は避けてください。

図6.7 推奨されないトポロジーの例: 単一障害点

推奨されないトポロジーの例: 単一障害点
トポロジーの推奨事項の詳細は、「レプリカのデプロイメントに関する考慮事項」 を参照してください。

6.2.1. 2 台のサーバー間のレプリケーションの設定

  1. トポロジーグラフで、サーバーノードの 1 つにマウスを合わせます。

    図6.8 ドメインまたは CA オプション

    ドメインまたは CA オプション
  2. 作成するトポロジーセグメントのタイプに応じて、domainまたは円のca部分をクリックします。
  3. 新しいレプリカ合意を表す新しい矢印が、マウスポインターの下に表示されます。マウスを他のサーバーノードに移動し、そこでクリックします。

    図6.9 新規セグメントの作成

    新規セグメントの作成
  4. Add Topology Segment ウィンドウで Add をクリックして、新規セグメントのプロパティーを確認します。
IdM は、2 台のサーバーの間に新しいトポロジーセグメントを作成します。これにより、サーバーをレプリカ合意に参加させます。トポロジーグラフには、更新されたレプリケーショントポロジーが表示されるようになりました。

図6.10 作成された新規セグメント

作成された新規セグメント

6.2.2. 2 台のサーバー間のレプリケーションの停止

  1. 削除するレプリカ合意を表す矢印をクリックします。これにより、矢印がハイライト表示されます。

    図6.11 ハイライト表示されたトポロジーセグメント

    ハイライト表示されたトポロジーセグメント
  2. Delete をクリックします。
  3. Confirmation ウィンドウで OK をクリックします。
IdM は、2 台のサーバー間のトポロジーセグメントを削除します。これにより、そのレプリカ合意が削除されます。トポロジーグラフには、更新されたレプリケーショントポロジーが表示されるようになりました。

図6.12 削除されたトポロジーセグメント

削除されたトポロジーセグメント

6.3. コマンドライン: ipa topology* コマンドを使用したトポロジーの管理

6.3.1. トポロジー管理コマンドのヘルプの取得

レプリケーショントポロジーの管理に使用するすべてのコマンドを表示するには、次のコマンドを実行します。
$ ipa help topology
特定のコマンドの詳細なヘルプを表示するには、それを --help オプションを指定して実行します。
$ ipa topologysuffix-show --help

6.3.2. 2 台のサーバー間のレプリケーションの設定

  1. ipa topologysegment-add コマンドを使用して、2 つのサーバーのトポロジーセグメントを作成します。プロンプトが表示されたら、以下を指定します。
    • 必要なトポロジー接尾辞: domain または ca
      注記
      ca 接尾辞間のセグメントを作成する場合は、両方のサーバーに CA がインストールされている必要があります。「既存の IdM ドメインへの 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

6.3.3. 2 台のサーバー間のレプリケーションの停止

  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. 2 サーバー間のトポロジーセグメントを削除するには、ipa topologysegment-del コマンドを使用します。
    $ 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
    ----------------------------

6.4. トポロジーからのサーバーの削除

以下のいずれかが該当する場合、IdM ではトポロジーからサーバーを削除できません。
  • 削除するサーバーが、残りのトポロジーと他のサーバーに接続する唯一のサーバーである。この場合、他のサーバーが分離され、これは許可されません。
  • 削除するサーバーが、最後の CA または DNS サーバーである。
このような状況では、エラーで試行に失敗します。たとえば、コマンドラインで以下を行います。
$ ipa server-del
Server name: server1.example.com
Removing server1.example.com from replication topology, please wait...
ipa: ERROR: Server removal aborted:

Removal of 'server1.example.com' leads to disconnected topology in suffix 'domain':
Topology does not allow server server2.example.com to replicate with servers:
  server3.example.com
  server4.example.com
...

6.4.1. Web UI: トポロジーからのサーバーの削除

サーバーコンポーネントをマシンからアンインストールせずにトポロジーからサーバーを削除するには、以下を実行します。
  1. IPA ServerTopologyIPA Server を選択します。
  2. 削除するサーバーの名前をクリックします。

    図6.13 サーバーの選択

    サーバーの選択
  3. Delete Server をクリックします。

6.4.2. コマンドライン: トポロジーからのサーバーの削除

重要
サーバーの削除は元に戻せないアクションです。サーバーを削除すると、トポロジーに戻す唯一の方法は、マシンに新しいレプリカをインストールすることです。
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

6.5. サーバーロールの管理

IdM サーバーにインストールされるサービスに基づいて、さまざまな サーバーロール を実行できます。例:CA サーバー、DNS サーバー、またはキーリカバリー認証局 (KRA) サーバーなどです。

6.5.1. サーバーロールの表示

Web UI: サーバーロールの表示
サポートされるサーバーロールの完全なリストは、IPA ServerTopologyServer Roles を参照してください。
  • Role status が absent の場合は、トポロジー内でそのロールを実行しているサーバーがないことを示しています。
  • Role status が enabled の場合は、トポロジー内でそのロールを実行しているサーバーが 1 台以上あることを示しています。

図6.14 Web UI でのサーバーロール

Web UI でのサーバーロール
コマンドライン: サーバーロールの表示
ipa config-show コマンドを実行すると、すべての CA サーバー、NTP サーバー、および現行の 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 NTP servers: server1.example.com, server2.example.com, server3.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, NTP 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
----------------------------

6.5.2. レプリカのマスター CA サーバーへのプロモート

注記
本セクションでは、ドメインレベル 1 で CA Renewal Master を変更する方法を説明します (7章ドメインレベルの表示と引き上げを参照)。ドメインレベル 0 で CA Renewal Master を変更する方法は、「レプリカのマスター CA サーバーへのプロモート」 を参照してください。
IdM デプロイメントで組み込み認証局 (CA) を使用する場合は、IdM CA サーバーの 1 つがマスター CA として機能します。これは、CA サブシステム証明書の更新を管理し、証明書失効リスト (CRL) を生成します。デフォルトでは、マスター CA は、システム管理者が ipa-server-install コマンドまたは ipa-ca-install コマンドを使用して CA ロールをインストールした最初のサーバーです。
マスター CA サーバーをオフラインに移行または廃止する予定の場合には、別の CA サーバーをプロモートして、新しい CA 更新マスターとして置き換えます。
  1. CA サブシステム証明書の更新を処理するようにレプリカを設定します。
  2. CRL を生成するようにレプリカを設定します。「CRL を生成するサーバーの変更」を参照してください。
  3. 以前のマスター CA サーバーの使用を終了する前に、新規マスターが適切に機能していることを確認します。「新規マスター CA サーバーが正しく設定されたことの確認」を参照してください。
6.5.2.1. 現在の CA 更新マスターの変更
Web UI: 現在の CA 更新マスターの変更
  1. IPA ServerConfiguration を選択します。
  2. IPA CA Renewal Master フィールドで、新しい CA Renewal Master を選択します。
コマンドライン: 現在の CA 更新マスターの変更
ipa config-mod --ca-renewal-master-server コマンドを使用します。
$ ipa config-mod --ca-renewal-master-server new_ca_renewal_master.example.com
  ...
  IPA masters: old_ca_renewal_master.example.com, new_ca_renewal_master.example.com
  IPA CA servers: old_ca_renewal_master.example.com, new_ca_renewal_master.example.com
  IPA NTP servers: old_ca_renewal_master.example.com, new_ca_renewal_master.example.com
  IPA CA renewal master: new_ca_renewal_master.example.com
出力で更新が成功したことを確認します。
6.5.2.2. CRL を生成するサーバーの変更
証明書失効リスト (CRL) を生成するサーバーを変更するには、以下を実行します。
  1. 現在の CRL 生成マスターが分からない場合は、各 IdM 認証局 (CA) で ipa-crlgen-manage status コマンドを使用して、CRL 生成が有効になっているかどうかを確認します。
    # ipa-crlgen-manage status
    CRL generation: enabled
  2. 現在の CRL 生成マスターで、この機能を無効にします。
    # ipa-crlgen-manage disable
  3. 新しい CRL 生成マスターとして設定する他の CA ホストで、この機能を有効にします。
    # ipa-crlgen-manage enable
6.5.2.3. 新規マスター CA サーバーが正しく設定されたことの確認
/var/lib/ipa/pki-ca/publish/MasterCRL.bin ファイルが新規マスター CA サーバーにあることを確認します。
このファイルは、ca.crl.MasterCRL.autoUpdateInterval パラメーターを使用して /etc/pki/pki-tomcat/ca/CS.cfg ファイルで定義した間隔に基づいて生成されます。デフォルト値は 240 分 (4 時間) です。
注記
ca.crl.MasterCRL.autoUpdateInterval パラメーターを更新すると、すでにスケジュールされている CRL の次回更新後に変更が有効になります。
ファイルが存在する場合には、新規マスター CA サーバーが正しく設定され、以前の CA マスターシステムを安全に廃止できます。

6.5.3. IdM サーバーからの IdM CA サービスのアンインストール

Red Hat では、トポロジーに CA ロールが割り当てられた Identity Management (IdM)レプリカの最大数を用意することを推奨します。したがって、4 つ以上のレプリカがあり、冗長な証明書のレプリケーションによりパフォーマンスの問題が発生する場合は、IdM レプリカから冗長な CA サービスインスタンスを削除します。そのためには、当該 IdM レプリカの使用を完全に停止してから、CA サービスを使用せずに IdM を再インストールする必要があります。
重要
IdM レプリカに CA ロールを 追加 することはできますが、IdM では、IdM レプリカから CA ロールのみを 削除 する方法はありません。ipa-ca-install コマンドには --uninstall オプションがありません。
  1. 冗長 CA サービスを特定し、このサービスをホストする IdM レプリカ上の 「IdM サーバーのアンインストール」 の手順に従います。
  2. 同じホストで、ユースケースに応じて 「外部 CA をルート CA として使用するサーバーのインストール」 または 「CA なしでのインストール」 の手順に従います。

6.5.4. 非表示のレプリカのデモートおよびプロモート

レプリカのインストール後、レプリカの表示状態を変更できます。
  • 表示されるレプリカを非表示のレプリカにデモートするには、以下を実施します。
    1. レプリカが CA Renewal Master である場合は、サービスを別のレプリカに移動します。詳細は、「現在の CA 更新マスターの変更」を参照してください。
    2. レプリカの状態を hidden に変更します。
      # ipa server-state replica.idm.example.com --state=hidden
  • 非表示のレプリカを表示されるレプリカにプロモートするには、次のコマンドを入力します。
    # ipa server-state replica.idm.example.com --state=enabled
注記
非表示のレプリカ機能は、テクノロジープレビューとして Red Hat Enterprise Linux 7.7 以降で利用でき、サポート対象外となります。

第7章 ドメインレベルの表示と引き上げ

ドメインレベルは、IdM トポロジーで利用可能な操作および機能を示します。
ドメインレベル 1
利用可能な機能の例:
重要
ドメインレベル 1 は、IdM バージョン 4.4 で Red Hat Enterprise Linux 7.3 で導入されました。ドメインレベル 1 の機能を使用するには、すべてのレプリカが Red Hat Enterprise Linux 7.3 以降を実行している必要があります。
最初のサーバーが Red Hat Enterprise Linux 7.3 でインストールされている場合、ドメインのドメインレベルは自動的に 1 に設定されます。
すべてのサーバーを以前のバージョンから IdM バージョン 4.4 にアップグレードすると、ドメインレベルは自動的に引き上げられません。ドメインレベル 1 の機能を使用する場合は、「ドメインレベルの引き上げ」 の説明に従ってドメインレベルを手動で増やします。
ドメインレベル 0
利用可能な機能の例:

7.1. 現在のドメインレベルの表示

コマンドライン: 現在のドメインレベルの表示
  1. 管理者としてログインします。
    $ kinit admin
  2. ipa domainlevel-get コマンドを実行します。
    $ ipa domainlevel-get
    -----------------------
    Current domain level: 0
    -----------------------
Web UI: 現在のドメインレベルの表示
IPA ServerTopologyDomain Level を選択します。

7.2. ドメインレベルの引き上げ

重要
これは元に戻すことができない操作です。ドメインレベルを 0 から 1 に増やしたら、1 から 0 にダウングレードすることはできません。
コマンドライン: ドメインレベルの引き上げ
  1. 管理者としてログインします。
    $ kinit admin
  2. ipa domainlevel-set コマンドを実行して、必要なレベルを指定します。
    $ ipa domainlevel-set 1
    -----------------------
    Current domain level: 1
    -----------------------
Web UI: ドメインレベルの引き上げ
  1. IPA ServerTopologyDomain Level を選択します。
  2. Set Domain Levelをクリックします。

第8章 Identity Management の更新および移行

8.1. Identity Management の更新

yum ユーティリティーを使用して、システムの Identity Management パッケージを更新できます。
警告
更新をインストールする前に、RHEL システムに関連するこれまでにリリース済みのエラータをすべて適用していることを確認します。詳細は、RHEL システムにパッケージの更新を適用する方法 を参照してください。KCS の記事。
さらに、7.3 などの新しい Red Hat Enterprise Linux バージョンが利用可能になると、yum は Identity Management サーバーまたはクライアントをこのバージョンにアップグレードします。
注記
本セクションでは、Identity Management を Red Hat Enterprise Linux 6 から Red Hat Enterprise Linux 7 に移行することは説明しません。移行する場合は、「Red Hat Enterprise Linux 6 からバージョン 7 への Identity Management の移行」 を参照してください。

8.1.1. Identity Management の更新に関する考慮事項

  • 少なくとも 1 台のサーバーで Identity Management パッケージを更新すると、トポロジー内のその他のすべてのサーバーでパッケージを更新しなくても、更新されたスキーマを受け取ります。これは、新しいスキーマを使用する新しいエントリーを、その他のサーバー間で確実に複製できます。
  • Identity Management パッケージのダウングレードはサポートされていません。
    重要
    ipa-* パッケージで yum downgrade コマンドを実行しないでください。
  • Red Hat は、次のバージョンにアップグレードすることのみを推奨します。たとえば、Red Hat Enterprise Linux 7.4 の Identity Management にアップグレードする場合は、Red Hat Enterprise Linux 7.3 の Identity Management からアップグレードすることを推奨します。以前のバージョンからアップグレードすると、問題が発生する可能性があります。

8.1.2. yum を使用した Identity Management パッケージの更新

サーバーまたはクライアントの Identity Management パッケージをすべて更新するには、次のコマンドを実行します。
# yum update ipa-*
警告
複数の Identity Management サーバーをアップグレードする場合は、各アップグレードの間隔は少なくとも 10 分あけてください。
複数のサーバーで同時または間隔をあまりあけないでアップグレードを行うと、トポロジー全体でアップグレード後のデータ変更を複製する時間が足りず、複製イベントが競合する可能性があります。
関連情報
  • yum ユーティリティーの使用方法は、『システム管理者のガイド』のYumを参照してください。
重要
CVE-2014-3566 のため SSLv3 (Secure Socket Layer version 3) プロトコルは mod_nss モジュールで無効にする必要があります。次の手順に従い、無効になっていることを確認してください。
  1. /etc/httpd/conf.d/nss.conf ファイルを編集し、NSSProtocol パラメーターを TLSv1.0 (後方互換性用)、TLSv1.1、および TLSv1.2 に設定します。
    NSSProtocol TLSv1.0,TLSv1.1,TLSv1.2
  2. httpd サービスを再起動します。
    # systemctl restart httpd.service
Red Hat Enterprise Linux 7 の Identity Management では、メインパッケージのアップグレードを行うため yum update ipa-* コマンドを起動すると上記の手順が自動的に行われます。

8.2. Red Hat Enterprise Linux 6 からバージョン 7 への Identity Management の移行

この手順では、すべてのデータおよび設定を Red Hat Enterprise Linux 6 Identity Management から Red Hat Enterprise Linux 7 サーバーに移行する方法を説明します。移行手順には、以下が含まれます。
  • Red Hat Enterprise Linux 6 ベースの認証局 (CA) マスターサーバーを Red Hat Enterprise Linux 7 に移行する。
  • すべてのサービスを新しい Red Hat Enterprise Linux 7 サーバーに移行する。これらのサービスには、CRL および証明書の作成、DNS 管理、または Kerberos KDC の管理が含まれます。
  • 元の Red Hat Enterprise Linux 6 CA マスターの使用を終了する。
手順では、以下を前提としています。
  • rhel7.example.com は、新しい CA マスターとなる Red Hat Enterprise Linux 7 システムです。
    重要
    現在サポートされているマイナーバージョンは RHEL 7.9 のみです。システムに RHEL 7.9 がインストールされていることを確認してください。
  • rhel6.example.com は、元の Red Hat Enterprise Linux 6 CA マスターです。
    注記
    マスター CA サーバーである Red Hat Enterprise Linux 6 サーバーを特定するには、certmonger サービスが renew_ca_cert コマンドを追跡するサーバーを決定します。すべての Red Hat Enterprise Linux 6 サーバーでこのコマンドを実行します。
    [root@rhel6 ~]# getcert list -d /var/lib/pki-ca/alias -n "subsystemCert cert-pki-ca" | grep post-save
    post-save command: /usr/lib64/ipa/certmonger/renew_ca_cert "subsystemCert cert-pki-ca"
    renew_ca_cert を実行する保存後アクションは CA マスターに対してのみ定義されます。

8.2.1. Red Hat Enterprise Linux 6 から 7 への Identity Management の移行の前提条件

  • rhel6.example.com システムを最新の Red Hat Enterprise Linux 6 バージョンに更新します。
  • rhel6.example.com システムで、ipa-* パッケージをアップグレードします。
    [root@rhel6 ~]# yum update ipa-*
    この手順では、RHBA-2015:0231-2アドバイザリーが適用されていることも確認します。このアドバイザリーは、2.3-6.el6_6 バージョンのbind-dyndb-ldapパッケージを提供し、Red Hat Enterprise Linux 6.6 拡張更新サポート (EUS) で使用できます。
    警告
    以前のバージョンの bind-dyndb-ldap を使用すると、Red Hat Enterprise Linux 6.6 DNS サーバーおよび Red Hat Enterprise Linux 7 DNS サーバー間の DNS 正引きゾーンに一貫性がない動作が生じます。
  • rhel7.example.com システムが 「サーバーのインストールの前提条件」 および 「レプリカのインストールの前提条件」 の要件を満たしていることを確認します。
  • rhel7.example.com システムで、必要なパッケージをインストールします。「IdM サーバーのインストールに必要なパッケージ」を参照してください。

8.2.2. Red Hat Enterprise Linux 6 での Identity Management スキーマの更新

copy-schema-to-ca.py スキーマ更新スクリプトは、rhel7.example.com レプリカのインストールに rhel6.example.com を準備します。Identity Management バージョン 3.1 とそれ以降のバージョン間のスキーマの変更により、スキーマを更新する必要があります。
  1. copy-schema-to-ca.py スキーマ更新スクリプトを rhel7.example.com システムから rhel6.example.com システムにコピーします。以下に例を示します。
    [root@rhel7 ~]# scp /usr/share/ipa/copy-schema-to-ca.py root@rhel6:/root/
  2. rhel6.example.com で更新された copy-schema-to-ca.py スクリプトを実行します。
    [root@rhel6 ~]# python copy-schema-to-ca.py
    ipa         : INFO     Installed /etc/dirsrv/slapd-PKI-IPA//schema/60kerberos.ldif
    [... output truncated ...]
    ipa         : INFO     Schema updated successfully
  3. Red Hat Enterprise Linux 7 レプリカに接続する前に、認証局を実行するすべての Red Hat Enterprise Linux 6 IdM レプリカで手順を繰り返します。

8.2.3. Red Hat Enterprise Linux 7 レプリカのインストール

  1. rhel6.example.com システムで、rhel7.example.com レプリカをインストールするために使用するレプリカファイルを作成します。たとえば、IP アドレスが 192.0.2.1 である rhel7.example.com のレプリカファイルを作成するには、次のコマンドを実行します。
    [root@rhel6 ~]# ipa-replica-prepare rhel7.example.com --ip-address 192.0.2.1
    
    Directory Manager (existing master) password:
    Preparing replica for rhel7.example.com from rhel6.example.com
    [... output truncated ...]
    The ipa-replica-prepare command was successful
    「レプリカ情報ファイル」 および 「レプリカの作成」 も参照してください。
  2. rhel6.example.com から rhel7.example.com に、レプリカ情報ファイルをコピーします。
    [root@rhel6 ~]# scp /var/lib/ipa/replica-info-replica.example.com.gpg root@rhel7:/var/lib/ipa/
  3. 統合 CA のある新しいレプリカを Red Hat Enterprise Linux 7.6 以降にインストールする場合は、/etc/httpd/conf.d/nss.conf ファイルの NSSCipherSuite パラメーターの最後に以下のエントリーを追加します。
    +ecdhe_rsa_aes_128_sha,+ecdhe_rsa_aes_256_sha
    Red Hat Enterprise Linux 7.6 以降では、特定の暗号は IdM CA ではデフォルトで有効ではなくなりました。このエントリーを設定に追加せずに、Red Hat Enterprise Linux 6 で実行しているマスターのレプリカとして、統合 CA のある IdM サーバーを Red Hat Enterprise Linux 7.6 でセットアップすると、CRITICAL Failed to configure CA instance エラーが発生して失敗します。
  4. レプリカ ファイルを使用して rhel7.example.com レプリカをインストールします。たとえば、次のコマンドでは、以下のオプションを使用しています。
    • Certificate System コンポーネントを設定する --setup-ca
    • 統合 DNS サーバーを設定し、フォワーダーを設定する --setup-dns および --forwarder
    • --ip-address - rhel7.example.com システムの IP アドレスを指定します。
    [root@rhel7 ~]# ipa-replica-install /var/lib/ipa/replica-info-rhel7.example.com.gpg --setup-ca --ip-address 192.0.2.1 --setup-dns --forwarder 192.0.2.20
    Directory Manager (existing master) password:
    
    Checking DNS forwarders, please wait ...
    Run connection check to master
    [... output truncated ...]
    Client configuration complete.
    関連項目:
  5. Identity Management サービスが rhel7.example.com で稼働していることを確認します。
    [root@rhel7 ~]# ipactl status
    Directory Service: RUNNING
    [... output truncated ...]
    ipa: INFO: The ipactl command was successful

8.2.4. CA サービスの Red Hat Enterprise Linux 7 サーバーへの移行

作業を開始する前に:
  • rhel6.example.com および rhel7.example.com の CA がいずれもマスターサーバーとして設定されていることを確認します。
    [root@rhel7 ~]$ kinit admin
    [root@rhel7 ~]$ ipa-csreplica-manage list
    rhel6.example.com: master
    rhel7.example.com: master
    レプリカ合意の詳細を表示するには、以下を実行します。
    [root@rhel7 ~]# ipa-csreplica-manage list --verbose rhel7.example.com
    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: 2017-02-13 13:55:13+00:00
rhel6.example.com の元のマスター CA で、CA サブシステム証明書の更新を停止します。
  1. 元の CA 証明書の追跡を無効にします。
    [root@rhel6 ~]# getcert stop-tracking -d /var/lib/pki-ca/alias -n "auditSigningCert cert-pki-ca"
    Request "20201127184547" removed.
    [root@rhel6 ~]# getcert stop-tracking -d /var/lib/pki-ca/alias -n "ocspSigningCert cert-pki-ca"
    Request "20201127184548" removed.
    [root@rhel6 ~]# getcert stop-tracking -d /var/lib/pki-ca/alias -n "subsystemCert cert-pki-ca"
    Request "20201127184549" removed.
    [root@rhel6 ~]# getcert stop-tracking -d /etc/httpd/alias -n ipaCert
    Request "20201127184550" removed.
  2. rhel6.example.com を再設定し、新しいマスター CA から更新された証明書を取得します。
    1. 更新ヘルパースクリプトを certmonger サービスディレクトリーにコピーし、適切なパーミッションを設定します。
      [root@rhel6 ~]# cp /usr/share/ipa/ca_renewal /var/lib/certmonger/cas/
      [root@rhel6 ~]# chmod 0600 /var/lib/certmonger/cas/ca_renewal
    2. SELinux 設定を更新します。
      [root@rhel6 ~]# restorecon /var/lib/certmonger/cas/ca_renewal
    3. certmonger を再起動します。
      [root@rhel6 ~]# service certmonger restart
    4. CA が証明書を取得するようになっているかチェックします。
      [root@rhel6 ~]# getcert list-cas
      ...
      CA 'dogtag-ipa-retrieve-agent-submit':
              is-default: no
              ca-type: EXTERNAL
      	helper-location: /usr/libexec/certmonger/dogtag-ipa-retrieve-agent-submit
    5. CA 証明書データベースの PIN を取得します。
      [root@rhel6 ~]# grep internal= /var/lib/pki-ca/conf/password.conf
    6. 外部更新の証明書 certmonger 追跡を設定します。これには、データベース PIN が必要です。
      [root@rhel6 ~]# getcert start-tracking \
          -c dogtag-ipa-retrieve-agent-submit \
          -d /var/lib/pki-ca/alias \
          -n "auditSigningCert cert-pki-ca" \
          -B /usr/lib64/ipa/certmonger/stop_pkicad \
          -C '/usr/lib64/ipa/certmonger/restart_pkicad \
          "auditSigningCert cert-pki-ca"' \
          -T "auditSigningCert cert-pki-ca" \
          -P database_pin
      New tracking request "20201127184743" added.
      [root@rhel6 ~]# getcert start-tracking \
          -c dogtag-ipa-retrieve-agent-submit \
          -d /var/lib/pki-ca/alias \
          -n "ocspSigningCert cert-pki-ca" \
          -B /usr/lib64/ipa/certmonger/stop_pkicad \
          -C '/usr/lib64/ipa/certmonger/restart_pkicad \
          "ocspSigningCert cert-pki-ca"' \
          -T "ocspSigningCert cert-pki-ca" \
          -P database_pin
      New tracking request "20201127184744" added.
      [root@rhel6 ~]# getcert start-tracking \
          -c dogtag-ipa-retrieve-agent-submit \
          -d /var/lib/pki-ca/alias \
          -n "subsystemCert cert-pki-ca" \
          -B /usr/lib64/ipa/certmonger/stop_pkicad \
          -C '/usr/lib64/ipa/certmonger/restart_pkicad \
          "subsystemCert cert-pki-ca"' \
          -T "subsystemCert cert-pki-ca" \
          -P database_pin
      New tracking request "20201127184745" added.
      [root@rhel6 ~]# getcert start-tracking \
          -c dogtag-ipa-retrieve-agent-submit \
          -d /etc/httpd/alias \
          -n ipaCert \
          -C /usr/lib64/ipa/certmonger/restart_httpd \
          -T ipaCert \
          -p /etc/httpd/alias/pwdfile.txt
      New tracking request "20201127184746" added.
CRL 生成を元の rhel6.example.com CA マスターから rhel7.example.com に移動します。
  1. rhel6.example.com で CRL 生成を停止します。
    1. CA サービスを停止します。
      [root@rhel6 ~]# service pki-cad stop
    2. rhel6.example.com で CRL 生成を無効にします。/var/lib/pki-ca/conf/CS.cfg ファイルを開き、ca.crl.MasterCRL.enableCRLCache および ca.crl.MasterCRL.enableCRLUpdates パラメーターの値を false に設定します。
      ca.crl.MasterCRL.enableCRLCache=false
      ca.crl.MasterCRL.enableCRLUpdates=false
    3. CA サービスを起動します。
      [root@rhel6 ~]# service pki-cad start
  2. rhel6.example.com で、CRL 要求をリダイレクトするように Apache を設定します。
    1. /etc/httpd/conf.d/ipa-pki-proxy.conf ファイルを開いて、RewriteRule エントリーをコメントアウトします。
      RewriteRule ^/ipa/crl/MasterCRL.bin https://rhel6.example.com/ca/ee/ca/getCRL?op=getCRL&crlIssuingPoint=MasterCRL [L,R=301,NC]
      注記
      URL のサーバーのホスト名を置き換えないでください。URL はローカルホスト名を参照する必要があります。
    2. Apache を再起動します。
      [root@rhel6 ~]# service httpd restart
    IdM は、ローカルファイルではなく、ローカル CA から証明書失効リスト (CRL) を取得するようになりました。
  3. rhel7.example.com で、新しい CA マスターとして rhel7.example.com を設定します。
    1. 「証明書更新を処理するサーバーの変更」 の説明に従って、CA サブシステム証明書の更新を処理するように rhel7.example.com を設定します。
    2. 「CRL を生成するサーバーの変更」 で説明されているように、rhel7.example.com を一般的な証明書失効リスト (CRL) に設定します。
関連情報

8.2.5. Red Hat Enterprise Linux 6 サーバーの停止

rhel6.example.com 上の全サービスを停止して、新しい rhel7.example.com サーバーへのドメイン検索を実施します。
[root@rhel6 ~]# 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) で新規サーバーに接続します。

8.2.6. マスター CA サーバーの移行後の次のステップ

トポロジーの各 Red Hat Enterprise Linux 6 サーバーの場合:
  1. rhel7.example.com からレプリカファイルを作成します。
    注記
    Red Hat Enterprise Linux 6 サーバーから Red Hat Enterprise Linux 7 レプリカをインストールすると、Identity Management ドメインのドメインレベルは、自動的に 0 に設定されます。
    Red Hat Enterprise Linux 7.3 では、レプリカのインストールや管理が容易になりました。これらの機能を使用するには、トポロジーはドメインレベル 1 にする必要があります。7章ドメインレベルの表示と引き上げを参照してください。
  2. レプリカファイルを使用して、別の Red Hat Enterprise Linux 7 システムに新しいレプリカをインストールします。
Red Hat Enterprise Linux 6 サーバーの使用を終了するには、以下を実行します。
  • Red Hat Enterprise Linux 7 サーバーで削除コマンドを実行して、トポロジーからサーバーを削除します。
重要
クライアント設定は自動的に更新されません。IDM サーバーの使用を終了し、新しいサーバーを異なる名前で設定した場合は、全体的なクライアント設定を確認する必要があります。特に、以下のファイルを手動で更新する必要があります。
  • /etc/openldap/ldap.conf
  • /etc/ipa/default.conf
  • /etc/sssd/sssd.conf

第9章 Identity Management のバックアップおよび復元

Red Hat Enterprise Linux Identity Management は、たとえばサーバーが正常に動作しなくなった場合やデータの喪失が発生した場合に、IdM システムを手動でバックアップして復元するソリューションを提供します。バックアップ時に、システムは IdM セットアップに関する情報を含むディレクトリーを作成して保存します。復元時に、このバックアップディレクトリーを使用して、元の IdM セットアップを復元できます。
重要
失われたレプリカを残りのレプリカとして再インストールすることで、デプロイメント内の残りのサーバーから IdM サーバーグループの失われた部分を再構築できない場合に限り、本章で説明するバックアップおよび復元手順を使用します。
ナレッジベースソリューションBackup and Restore in IdM/IPAでは、複数のサーバーレプリカを維持して損失を回避する方法を説明します。バックアップバージョンには古い使用できない情報が含まれるため、同じデータを持つ既存のレプリカから再構築することが推奨されます。
バックアップおよび復元が回避できる可能性のある脅威シナリオには、以下が含まれます。
  • マシンでの致命的なハードウェア障害が発生し、マシンはそれ以降機能しなくなる。この場合、以下を実施します。
    1. オペレーティングシステムをゼロから再インストールします。
    2. マシンには、同じホスト名、完全修飾ドメイン名 (FQDN)、および IP アドレスを設定します。
    3. IdM パッケージと、元のシステムに存在していた IdM に関連するその他のオプションパッケージをすべてインストールします。
    4. IdM サーバーの完全バックアップを復元します。
  • 分離されたマシンでのアップグレードに失敗する。オペレーティングシステムは機能し続けますが、IdM データが破損するため、IdM システムを既知の正常な状態に復元したい理由になります。
    重要
    上記の 2 項目など、ハードウェア障害またはアップグレードが失敗した場合は、すべてのレプリカまたは特別なロールを持つレプリカ (唯一の認証局 (CA) など) が失われた場合にのみバックアップから復元します。同じデータを持つレプリカがまだ存在する場合は、失われたレプリカを削除してから残りのレプリカから再構築することが推奨されます。
  • LDAP コンテンツに望ましくない変更 (エントリーが削除された等) が加えられたため、それを元に戻したい。バックアップされた LDAP データを復元すると、IdM システム自体に影響を与えずに LDAP エントリーが以前の状態に戻ります。
復元されたサーバーは、IdM の唯一の情報源になります。他のマスターサーバーは、復元されたサーバーから再度初期化されます。最後のバックアップ後に作成されたデータはすべて失われます。したがって、通常のシステムメンテナンスには、バックアップと復元のソリューションを使用しないでください。可能な場合は、レプリカとして再インストールすることで、常に失われたサーバーを再構築します。
バックアップ機能および復元機能はコマンドラインからのみ管理でき、IdM Web UI では使用できません。

9.1. サーバーのフルバックアップおよびデータのみのバックアップ

IdM には、以下の 2 つのバックアップオプションがあります。
IdM サーバーの完全なバックアップ
サーバーのフルバックアップは、すべての IdM サーバーファイルと LDAP データのバックアップコピーを作成します。これにより、スタンドアロンバックアップが作成されます。IdM は数百のファイルに影響します。バックアッププロセスのコピーするファイルは、ディレクトリー全体と特定のファイルが混在したもので (例: 設定ファイルやログファイル)、IdM に直接関係したり、IdM が依存するさまざまなサービスに関連したりします。サーバーのフルバックアップは raw ファイルのバックアップであるため、これはオフラインで実行されます。サーバーのフルバックアップを実行するスクリプトは、すべての IdM サービスを停止し、バックアッププロセスの安全を確保します。
完全なサーバーバックアップコピーの全リストについては、「バックアップ中にコピーされたディレクトリーおよびファイルのリスト」 を参照してください。
データのみのバックアップ
データのみのバックアップは、LDAP データおよび変更ログのバックアップコピーのみを作成します。このプロセスは IPA-REALM インスタンスをバックアップし、複数のバックエンドのバックアップを作成することも、単一のバックエンドのみをバックアップします。バックエンドには IPA バックエンドと CA Dogtag バックエンドが含まれます。このタイプのバックアップは、LDIF(LDAP データ交換形式) に保存されている LDAP コンテンツのレコードもバックアップします。データのみのバックアップは、オンラインとオフラインの両方で実行できます。
デフォルトでは、IdM は作成したバックアップを /var/lib/ipa/backup/ ディレクトリーに保存します。バックアップを含むサブディレクトリーの命名規則は以下のとおりです。
  • 完全なサーバーバックアップの場合は、GMT のタイムゾーンで ipa-full-YEAR-MM-DD-HH-MM-SS となります。
  • データのみのバックアップの場合は、GMT のタイムゾーンで ipa-data-YEAR-MM-DD-HH-MM-SS となります。

9.1.1. バックアップの作成

完全なサーバーバックアップもデータのみのバックアップも、ipa-backup ユーティリティーを使用して作成されます。これは常に root で実行する必要があります。
サーバーのフルバックアップを作成するには、ipa-backup を実行します。
重要
プロセスをオフラインで実行する必要があるため、サーバーのフルバックアップを実行すると、すべての IdM サービスが停止します。バックアップが完了すると、IdM サービスが再起動します。
データのみのバックアップを作成するには、ipa-backup --data コマンドを実行します。
ipa-backup にいくつかのオプションを追加できます。
  • --online はオンラインバックアップを実行します。このオプションはデータのみのバックアップでのみ利用できます。
  • --logs は、バックアップに IdM サービスログファイルを追加します、
ipa-backup の使用方法は、ipa-backup(1) の man ページを参照してください。
9.1.1.1. バックアップ中ボリューム上に十分な領域がない場合の回避策
本セクションでは、IdM バックアッププロセスに関与するディレクトリーが空き領域が不十分なボリュームに保存されている場合に問題に対応する方法を説明します。
/var/lib/ipa/backup/ が含まれるボリューム上の領域が不十分
空き容量が不足しているボリュームに/var/lib/ipa/backup/ディレクトリーが保存されている場合は、バックアップを作成することはできません。この問題に対処するには、以下の回避策のいずれかを使用します。
  • 別のボリュームにディレクトリーを作成し、/var/lib/ipa/backup/ にリンクします。たとえば、/home が十分な空き領域を持つ別のボリュームに保存されている場合は、次のコマンドを実行します。
    1. /home/idm/backup/ などのディレクトリーを作成します。
      # mkdir -p /home/idm/backup/
    2. 以下のパーミッションをディレクトリーに設定します。
      # chown root:root /home/idm/backup/
      # chmod 700 /home/idm/backup/
    3. /var/lib/ipa/backup/ に既存のバックアップが含まれている場合は、新しいディレクトリーに移動します。
      # mv /var/lib/ipa/backup/* /home/idm/backup/
    4. /var/lib/ipa/backup/ ディレクトリーを削除します。
      # rm -rf /var/lib/ipa/backup/
    5. /var/lib/ipa/backup/ リンクを /home/idm/backup/ ディレクトリーに作成します。
      # ln -s /home/idm/backup/ /var/lib/ipa/backup/
  • 別のボリュームに保存されているディレクトリーを /var/lib/ipa/backup/ にマウントします。たとえば、/home が十分な空き領域がある別のボリュームに保存されている場合は、/home/idm/backup/ を作成し、var/lib/ipa/backup/ にマウントします。
    1. /home/idm/backup/ ディレクトリーを作成します。
      # mkdir -p /home/idm/backup/
    2. 以下のパーミッションをディレクトリーに設定します。
      # chown root:root /home/idm/backup/
      # chmod 700 /home/idm/backup/
    3. /var/lib/ipa/backup/ に既存のバックアップが含まれている場合は、新しいディレクトリーに移動します。
      # mv /var/lib/ipa/backup/* /home/idm/backup/
    4. /home/idm/backup//var/lib/ipa/backup/ にマウントします。
      # mount -o bind /home/idm/backup/ /var/lib/ipa/backup/
    5. システムの起動時に、/home/idm/backup//var/lib/ipa/backup/ に自動的にマウントするには、以下を /etc/fstab ファイルに追加します。
      /home/idm/backup/     /var/lib/ipa/backup/     none     bind     0 0
/tmp が含まれるボリューム上の領域が不十分
/tmp ディレクトリーに十分な領域がないためにバックアップが失敗する場合は、TMPDIR 環境変数を使用して、バックアップ中に作成されるステージファイルの場所を変更します。
# TMPDIR=/path/to/backup ipa-backup
詳細は、ナレッジベースソリューションipa-backup command fails to finishを参照してください。

9.1.2. バックアップの暗号化

GPG(GNU Privacy Guard) 暗号化を使用して IdM バックアップを暗号化できます。
GPG キーを作成するには、以下を実行します。
  1. 鍵の詳細を含む keygen ファイルを作成します。たとえばcat >keygen <<EOFを実行して、コマンドラインからファイルに必要な暗号化の詳細を指定します。
    [root@server ~]# cat >keygen <<EOF
    > %echo Generating a standard key
    > Key-Type: RSA
    > Key-Length:2048
    > Name-Real: IPA Backup
    > Name-Comment: IPA Backup
    > Name-Email: root@example.com
    > Expire-Date: 0
    > %pubring /root/backup.pub
    > %secring /root/backup.sec
    > %commit
    > %echo done
    > EOF
    [root@server ~]#
  2. backup と呼ばれる新しいキーペアを生成し、keygen の内容をコマンドに入力します。以下の例では、パス名 /root/backup.sec および /root/backup.pub でキーペアを生成します。
    [root@server ~]# gpg --batch --gen-key keygen
    [root@server ~]# gpg --no-default-keyring --secret-keyring /root/backup.sec \
    		     --keyring /root/backup.pub --list-secret-keys
GPG で暗号化されたバックアップを作成するには、以下のオプションを指定して生成された バックアップ キーを ipa-backup に渡します。
  • --GPG - 暗号化されたバックアップを実行するために ipa-backup に指示します。
  • --gpg-keyring=GPG_KEYRING: ファイル拡張子なしで GPG キーリングへの完全パスを提供します。
以下に例を示します。
[root@server ~]# ipa-backup --gpg --gpg-keyring=/root/backup
注記
gpg2 が機能するには外部プログラムが必要なため、システムに gpg2 ユーティリティーを使用して GPG キーを生成すると問題が発生する可能性があります。この場合は、コンソールから鍵を純粋に生成するには、キーを生成する前に pinentry-program /usr/bin/pinentry-curses の行を .gnupg/gpg-agent.conf ファイルに追加します。

9.1.3. バックアップ中にコピーされたディレクトリーおよびファイルのリスト

ディレクトリー:
/usr/share/ipa/html
/root/.pki
/etc/pki-ca
/etc/pki/pki-tomcat
/etc/sysconfig/pki
/etc/httpd/alias
/var/lib/pki
/var/lib/pki-ca
/var/lib/ipa/sysrestore
/var/lib/ipa-client/sysrestore
/var/lib/ipa/dnssec
/var/lib/sss/pubconf/krb5.include.d/
/var/lib/authconfig/last
/var/lib/certmonger
/var/lib/ipa
/var/run/dirsrv
/var/lock/dirsrv
ファイル:
/etc/named.conf
/etc/named.keytab
/etc/resolv.conf
/etc/sysconfig/pki-ca
/etc/sysconfig/pki-tomcat
/etc/sysconfig/dirsrv
/etc/sysconfig/ntpd
/etc/sysconfig/krb5kdc
/etc/sysconfig/pki/ca/pki-ca
/etc/sysconfig/ipa-dnskeysyncd
/etc/sysconfig/ipa-ods-exporter
/etc/sysconfig/named
/etc/sysconfig/ods
/etc/sysconfig/authconfig
/etc/ipa/nssdb/pwdfile.txt
/etc/pki/ca-trust/source/ipa.p11-kit
/etc/pki/ca-trust/source/anchors/ipa-ca.crt
/etc/nsswitch.conf
/etc/krb5.keytab
/etc/sssd/sssd.conf
/etc/openldap/ldap.conf
/etc/security/limits.conf
/etc/httpd/conf/password.conf
/etc/httpd/conf/ipa.keytab
/etc/httpd/conf.d/ipa-pki-proxy.conf
/etc/httpd/conf.d/ipa-rewrite.conf
/etc/httpd/conf.d/nss.conf
/etc/httpd/conf.d/ipa.conf
/etc/ssh/sshd_config
/etc/ssh/ssh_config
/etc/krb5.conf
/etc/ipa/ca.crt
/etc/ipa/default.conf
/etc/dirsrv/ds.keytab
/etc/ntp.conf
/etc/samba/smb.conf
/etc/samba/samba.keytab
/root/ca-agent.p12
/root/cacert.p12
/var/kerberos/krb5kdc/kdc.conf
/etc/systemd/system/multi-user.target.wants/ipa.service
/etc/systemd/system/multi-user.target.wants/sssd.service
/etc/systemd/system/multi-user.target.wants/certmonger.service
/etc/systemd/system/pki-tomcatd.target.wants/pki-tomcatd@pki-tomcat.service
/var/run/ipa/services.list
/etc/opendnssec/conf.xml
/etc/opendnssec/kasp.xml
/etc/ipa/dnssec/softhsm2.conf
/etc/ipa/dnssec/softhsm_pin_so
/etc/ipa/dnssec/ipa-ods-exporter.keytab
/etc/ipa/dnssec/ipa-dnskeysyncd.keytab
/etc/idm/nssdb/cert8.db
/etc/idm/nssdb/key3.db
/etc/idm/nssdb/secmod.db
/etc/ipa/nssdb/cert8.db
/etc/ipa/nssdb/key3.db
/etc/ipa/nssdb/secmod.db
ログファイルとディレクトリー:
/var/log/pki-ca
/var/log/pki/
/var/log/dirsrv/slapd-PKI-IPA
/var/log/httpd
/var/log/ipaserver-install.log
/var/log/kadmind.log
/var/log/pki-ca-install.log
/var/log/messages
/var/log/ipaclient-install.log
/var/log/secure
/var/log/ipaserver-uninstall.log
/var/log/pki-ca-uninstall.log
/var/log/ipaclient-uninstall.log
/var/named/data/named.run

9.2. バックアップの復元

ipa-backupを使用して作成されたバックアップのあるディレクトリーがある場合は、IdM サーバーまたは LDAP コンテンツをバックアップが実行されたときの状態に復元できます。バックアップが作成されたホストとは異なるホストでバックアップを復元することはできません。
注記
IdM サーバーをアンインストールしても、このサーバーのバックアップは自動的に削除されません。

9.2.1. サーバーのフルバックアップまたはデータのみのバックアップからの復元

重要
サーバーをアンインストールしてからフルサーバーの復元を行うことが推奨されます。
完全なサーバーおよびデータのみのバックアップは、ipa-restore ユーティリティーを使用して復元します。これは、常に root として実行する必要があります。バックアップをコマンドに渡します。
  • デフォルトの /var/lib/ipa/backup/ ディレクトリーにある場合に、バックアップでディレクトリーの名前のみを渡します。
  • バックアップを含むディレクトリーがデフォルトディレクトリーにない場合は、バックアップへのフルパスを渡します。以下に例を示します。
    [root@server ~]# ipa-restore /path/to/backup
ipa-restore ユーティリティーは、バックアップディレクトリーに含まれるバックアップタイプを自動的に検出し、デフォルトでは同じタイプの復元を実行します。
ipa-restore に以下のオプションを追加できます。
  • --data は、完全なサーバーバックアップからデータのみの復元を実行します。つまり、サーバーのフルバックアップを含むバックアップディレクトリーから LDAP データコンポーネントのみを復元します。
  • --online は、オンラインでデータのみの復元で LDAP データを復元します。
  • --instance は、どの 389 DS インスタンスを復元するかを指定します。Red Hat Enterprise Linux 7 の IdM は IPA-REALM インスタンスのみを使用しますが、たとえば別のインスタンスを持つシステムでバックアップを作成することは可能です。このような場合は、--instance では IPA-REALM のみを復元することができます。以下に例を示します。
    [root@server ~]# ipa-restore --instance=IPA-REALM /path/to/backup
    このオプションは、データのみの復元を実行する場合にのみ使用できます。
  • --backend は、どのバックエンドが復元されるかを指定します。このオプションがないと、ipa-restore は検出するすべてのバックエンドを復元します。可能なバックエンドを定義する引数は userRoot で、IPA データバックエンドを復元し、CA バックエンドを復元する ipaca です。
    このオプションは、データのみの復元を実行する場合にのみ使用できます。
  • --no-logs は、ログファイルを復元せずにバックアップを復元します。
IdM マスターで認証の問題を回避するには、復元後に SSSD キャッシュを消去します。
  1. SSSD サービスを停止します。
    [root@server ~]# systemctl stop sssd
  2. SSSD からキャッシュされたコンテンツをすべて削除します。
    [root@server ~]# find /var/lib/sss/ ! -type d | xargs rm -f
  3. SSSD サービスを起動します。
    [root@server ~]# systemctl start sssd
注記
バックアップからの復元後に、システムを再起動することが推奨されます。
ipa-restore の使用方法は、ipa-restore(1) の man ページを参照してください。

9.2.2. 複数のマスターサーバーでの復元

マルチマスターレプリケーション環境で IdM を復元する方法は、「IdM のバックアップおよびリストア」を参照してください。

9.2.3. 暗号化されたバックアップからの復元

GPG で暗号化されたバックアップから復元する場合は、--gpg-keyring オプションを使用して、秘密鍵と公開鍵への完全パスを指定します。以下に例を示します。
[root@server ~]# ipa-restore --gpg-keyring=/root/backup /path/to/backup

第10章 IdM ユーザーのアクセス制御の定義

アクセス制御は、マシン、サービス、エントリーなどの特定のリソースにアクセスできるユーザーや、実行可能な操作の種類を定義するセキュリティー機能のセットです。Identity Management は複数のアクセス制御機能を提供し、付与されているアクセスの種類と、誰に付与されているかが明らかになります。この一環として、Identity Management は、ドメイン内のリソースへのアクセス制御と、IdM 設定自体へのアクセス制御を区別します。
本章では、IdM サーバーおよび他の IdM ユーザーに対する IdM 内のユーザーに利用可能な異なる内部アクセス制御メカニズムを説明しています。

10.1. IdM エントリーのアクセス制御

アクセス制御は、他のユーザーやオブジェクトに対してユーザーが許可された操作についての権限やパーミッションを定義します。
Identity Management アクセス制御構造は、標準の LDAP アクセス制御に基づいています。IdM サーバー内のアクセスは、その他の IdM エンティティー (Directory Server インスタンスにも LDAP エントリーとして保存されている) へのアクセスが許可されている IdM ユーザー (バックエンド Directory Server インスタンスに保存されている) に基づいています。
アクセス制御指示 (ACI) には、以下の 3 つの部分があります。
アクター
これは、何かを実行するためのパーミッションが付与されているエンティティーです。これはユーザーが誰かを定義し、1 日のある時間帯や特定のマシンに試行を制限するなど、オプションでバインドの試行に対して他の制限を必須とすることが可能なため、LDAP アクセス制御モデルではバインドルールと呼ばれます。
Target
これは、Actor が許可されている操作を実行する対象のエントリーを定義します。
操作タイプ
操作タイプ — 最後の部分は、ユーザーが実行できるアクションの種類を判断します。最も一般的な操作は、追加、削除、書き込み、読み取り、および検索です。Identity Management では、すべてのユーザーが暗示的に ldM ドメイン内のすべてのエントリーに対する読み取りおよび検索権限を付与されています。匿名ユーザーは、sudo ルールやホストベースのアクセス制御など、セキュリティー関連の設定は読み取ることができません。
いかなる操作でもそれが試行されると、IdM クライアントはまずバインド操作の一部としてユーザーの認証情報を送信します。バックエンドの Directory Server はまずユーザー認証情報を、次にユーザーアカウントをチェックして、ユーザーが要求された操作を実行するパーミッションを持っているかどうかを確認します。

10.1.1. Identity Management のアクセス制御メソッド

アクセス制御ルールの実装をシンプルかつ明確にするために、Identity Management はアクセス制御の定義を以下の 3 つのカテゴリーに分けています。
セルフサービスルール
セルフサービスルール。これは、ユーザーが自分のパーソナルエントリーで実行可能な操作を定義します。アクセス制御タイプは、エントリー内での属性への書き込みパーミッションのみを許可します。エントリー自体の追加もしくは削除操作は許可されません。
委譲ルール
委譲ルールでは、特定のユーザーグループが、別のユーザーグループ内のユーザーの特定の属性に対して書き込み (編集) 操作を実行できます。セルフサービスルールのように、この形式のアクセス制御は特定の属性値の編集に制限されており、エントリー全体を追加したり削除する権限や特定されていない属性に対する制御を付与するものではありません。
ロールベースのアクセス制御
ロールベースのアクセス制御では特別のアクセス制御グループが作成され、このグループに IdM ドメイン内での全タイプのエントリーに対するより幅広い権限が付与されます。ロールには編集、追加、および削除の権限が付与されるので、選択された属性だけでなくエントリー全体に対する完全な制御が付与されます。
Identity Management ですでに作成され、利用可能なロールもあります。ホストや自動マウント設定、netgroup、DNS 設定、および IdM 設定など、すべてのタイプのエントリーを特別な方法で管理するために、特別なロールを作成することもできます。

10.2. セルフサービス設定の定義

セルフサービスのアクセス制御ルールでは、エントリーがそれ自体で実行可能な操作を定義します。このルールでは、ユーザー (または他の IdM エンティティー) が自身のパーソナルエントリーで編集可能な属性のみを定義します。

10.2.1. Web UI でのセルフサービスルールの作成

  1. トップメニューの IPA Server タブで、Role-Based Access ControlSelf Service Permissions サブタブを選択します。
  2. セルフサービスのアクセス制御手順のリストの上部にある Add をクリックします。

    図10.1 現在のセルフサービスルールの追加

    現在のセルフサービスルールの追加
  3. ポップアップウィンドウでルール名を入力します。空白を使用することもできます。

    図10.2 セルフサービスルールを追加するためのフォーム

    セルフサービスルールを追加するためのフォーム
  4. この ACI でユーザーによる編集を許可する属性のチェックボックスを選択します。
  5. Add をクリックして新規セルフサービス ACI を保存します。

10.2.2. コマンドライン でのセルフサービスルールの作成

selfservice-add コマンドを使用すると、新しいセルフサービスルールを追加できます。これらの 2 つのオプションが必要です。
  • --permissions: ACI 付与への書き込み、追加、または削除などのパーミッションを設定します。
  • --attrs: この ACI がパーミッションを付与する属性の完全なリストを設定します。
[jsmith@server ~]$ ipa selfservice-add "Users can manage their own name details" --permissions=write --attrs=givenname --attrs=displayname --attrs=title --attrs=initials
-----------------------------------------------------------
Added selfservice "Users can manage their own name details"
-----------------------------------------------------------
    Self-service name: Users can manage their own name details
    Permissions: write
    Attributes: givenname, displayname, title, initials

10.2.3. セルフサービスルールの編集

ウェブ UI のセルフサービスエントリーでは、ACI に含まれている属性のリストのみが編集可能な要素です。チェックボックスは選択または選択解除できます。

図10.3 セルフサービス編集ページ

セルフサービス編集ページ
コマンドラインで、セルフサービスのルールが ipa selfservice-mod コマンドを使用して編集されます。--attrs オプションは、サポートされる属性のリストをすべて上書きするため、属性の完全なリストと新しい属性を常に含めます。
[jsmith@server ~]$ ipa selfservice-mod "Users can manage their own name details" --attrs=givenname --attrs=displayname --attrs=title --attrs=initials --attrs=surname
--------------------------------------------------------------
Modified selfservice "Users can manage their own name details"
--------------------------------------------------------------
Self-service name: Users can manage their own name details
Permissions: write
Attributes: givenname, displayname, title, initials
重要
セルフサービスルールを修正する際は、既存の属性も含め、すべての属性を含めるようにしてください。

10.3. ユーザーへのパーミッションの委任

ユーザーのあるグループが別のユーザーのグループのエントリーを管理するパーミッションを割り当てられるという意味で、委任はロールにとてもよく似ています。ただし、付与される完全なアクセスがエントリー全体に対してではなく、特定のユーザー属性のみに対してであるという意味で、委任される権限はセルフサービスルールにより似ています。また、委任された権限内のグループは、アクセス制御のために特別に作成されたロールではなく、既存の IdM ユーザーグループになります。

10.3.1. Web UI でのユーザーグループへのアクセス委任

  1. トップメニューの IPA Server タブで、Role-Based Access ControlDelegations サブタブを選択します。
  2. 委譲アクセス制御手順のリストの上部にある Add リンクをクリックします。

    図10.4 新規委譲の追加

    新規委譲の追加
  3. 新規委任に名前を付けます。
  4. ユーザーが特定の属性を閲覧する権限を持つ (read) かその属性を追加または変更する権限を持つ (write) かをチェックボックスで選択して、パーミッションを設定します。
    ユーザーによっては情報を閲覧する必要はあるものの、編集可能にすべきでないユーザーもいます。
  5. User group ドロップダウンメニューで、ユーザーグループのユーザーエントリーに パーミッションを付与される グループを選択します。

    図10.5 委譲を追加するためのフォーム

    委譲を追加するためのフォーム
  6. Member user group ドロップダウンメニューで、委譲グループのメンバーが エントリーを編集できる グループを選択します。
  7. 属性ボックスでは、メンバーのユーザーグループがパーミッションを付与される属性を選択します。
  8. Add をクリックして新規委任 ACI を保存します。

10.3.2. コマンドラインでのユーザーグループへのアクセス委任

delegation-add コマンドを使用して、新しい委譲アクセス制御ルールが追加されます。以下の 3 つのオプションが必須になります。
  • --group - ユーザーグループ内のユーザーのエントリーに パーミッションを付与されている グループです。
  • --membergroup - 委任グループのメンバーが エントリーを編集できる グループです。
  • --attrs - メンバーグループのユーザーが表示または編集できる属性です。
以下に例を示します。
$ ipa delegation-add "basic manager attrs" --attrs=manager --attrs=title --attrs=employeetype --attrs=employeenumber --group=engineering_managers --membergroup=engineering
--------------------------------------
Added delegation "basic manager attrs"
--------------------------------------
  Delegation name: basic manager attrs
  Permissions: write
  Attributes: manager, title, employeetype, employeenumber
  Member user group: engineering
  User group: engineering_managers
委任ルールは、delegation-mod コマンドを使用して編集します。--attrs オプションは、サポートされる属性のリストをすべて上書きするため、属性の完全なリストと新しい属性を常に含めます。
[jsmith@server ~]$ ipa delegation-mod "basic manager attrs" --attrs=manager --attrs=title --attrs=employeetype --attrs=employeenumber --attrs=displayname
-----------------------------------------
Modified delegation "basic manager attrs"
-----------------------------------------
  Delegation name: basic manager attrs
  Permissions: write
  Attributes: manager, title, employeetype, employeenumber, displayname
  Member user group: engineering
  User group: engineering_managers
重要
委任ルールを修正する際は、既存の属性も含め、すべての属性を含めるようにしてください。

10.4. ロールベースのアクセス制御の定義

ロールベースのアクセス制御では、セルフサービスおよび委任アクセス制御の場合とは非常に異なる種類の権限をユーザーに付与します。ロールベースのアクセス制御は基本的に管理されており、エントリーを変更する機能を提供します。
ロールベースのアクセス制御には、パーミッション特権、および ロール の 3 つの部分があります。権限は 1 つ以上のパーミッションで設定され、ロールは 1 つ以上の権限で設定されます。
  • パーミッション は、(読み取り、書き込み、追加、または削除) 特定の操作と、これらの操作が適用される ldM LDAP ディレクトリー内のターゲットエントリーを定義します。パーミッションはビルディングブロックで、必要に応じて複数の特権に割り当てることができます。
    IdM パーミッションを使用すると、どのユーザーがどのオブジェクトにアクセスできるか、さらにこのようなオブジェクトの属性にアクセスできるかどうかを制御できます。IdM を使用すると、個々の属性をホワイトリストまたはブラックリストに登録したり、特定の IdM 機能 (ユーザー、グループ、sudo など) の全体の可視性を、すべての匿名ユーザー、すべての認証済みユーザー、または特権ユーザーの特定のグループに変更したりできます。パーミッションに対するこの柔軟なアプローチは、管理者がアクセスが必要な特定のセクションにのみユーザーまたはグループのアクセスを制限し、他のセクションをこれらのユーザーまたはグループに対して完全に非表示にする場合に便利です。
  • 特権 は、ロールに適用できるパーミッションのグループです。例えば、パーミッションは自動マウントの場所の追加、編集、削除を行うために作成できます。そして、そのパーミッションは FTP サーバーの管理に関連する別のパーミッションと組み合わせることができます。これらは、ファイルシステムの管理に関連する単一の特権を作成するために作成できます。
    注記
    Red Hat Identity Management のコンテキストでは、権限とは、パーミッションおよびそれに続いてロールが作成されるアクセス制御の Atomic 単位の非常に特殊な意味を持ちます。通常のユーザーが一時的に追加の特権を取得するという概念としての特権昇格は、Red Hat Identity Management には存在しません。ロールベースアクセス制御 (RBAC) を使用して、権限がユーザーに割り当てられます。アクセス権を付与するロールを持つユーザーと、持たないユーザーがいます。
    ユーザーのほかに、権限はユーザーグループ、ホスト、ホストグループ、およびネットワークサービスにも割り当てられます。これにより、特定のネットワークサービスを使用するホストセットのユーザーセットによって、操作をきめ細かく制御できます。
  • ロールは、ロールに指定したユーザーの権限のリストです。
    重要
    ロールは、許可されたアクションを分類するために使用されます。ロールは、特権昇格されないようにしたり、特権の分離を実装するツールとしては使用しません。
完全に新しいパーミッションを作成したり、既存または新規のパーミッションをベースにして新たな権限を作成したりすることができます。Red Hat Identity Management は、以下の事前定義済みのロールを提供します。
表10.1 Red Hat Identity Management の定義済みロール
ロール 特権 説明
Helpdesk
Modify Users、Reset passwords、Modify Group membership 簡単なユーザー管理タスクを実行します。
IT Security Specialist
Netgroups Administrators、HBAC Administrator、Sudo Administrator ホストベースのアクセス制御、sudo ルールなどのセキュリティーポリシーを管理します。
IT Specialist
Host Administrators、Host Group Administrators、Service Administrators、Automount Administrators ホストの管理を行います
Security Architect
Delegation Administrator、Replication Administrators、Write IPA Configuration、Password Policy Administrator Identity Management 環境の管理、信頼の作成、レプリカ合意を作成します。
User Administrator
User Administrators、Group Administrators、Stage User Administrators ユーザーおよびグループの作成を行います

10.4.1. ロール

10.4.1.1. Web UI でのロールの作成
  1. トップメニューで IPA Server タブを開き、Role Based Access Control サブタブを選択します。
  2. ロールベースのアクセス制御手順のリストの上部にある Add リンクをクリックします。

    図10.6 新規ロールの追加

    新規ロールの追加
  3. ロール名と説明を入力します。

    図10.7 ロールを追加するためのフォーム

    ロールを追加するためのフォーム
  4. Add and Edit ボタンをクリックして新規ロールを保存し、設定ページに移動します。
  5. Users タブの上部で、グループ追加の場合は Users Groups タブで、Add をクリックします。

    図10.8 ユーザーの追加

    ユーザーの追加
  6. 左側のユーザーを選択し、> ボタンを使用して、Prospective 列に移動します。

    図10.9 ユーザーの選択

    ユーザーの選択
  7. Privileges タブの上部にある Add をクリックします。

    図10.10 権限の追加

    権限の追加
  8. 左側の権限を選択し、> ボタンを使用してそれらを Prospective 列に移動します。

    図10.11 権限の選択

    権限の選択
  9. Add ボタンをクリックして保存します。
10.4.1.2. コマンドライン でのロールの作成
  1. 新規ロールを追加します。
    [root@server ~]# kinit admin
    [root@server ~]# ipa role-add --desc="User Administrator" useradmin
      ------------------------
      Added role "useradmin"
      ------------------------
      Role name: useradmin
      Description: User Administrator
  2. 必要な権限をロールに追加します。
    [root@server ~]# ipa role-add-privilege --privileges="User Administrators" useradmin
      Role name: useradmin
      Description: User Administrator
      Privileges: user administrators
      ----------------------------
      Number of privileges added 1
    ----------------------------
    
  3. 必要なグループをロールに追加します。この場合、すでに存在する 1 つのグループ useradmin のみを追加することになります。
    [root@server ~]# ipa role-add-member --groups=useradmins useradmin
      Role name: useradmin
      Description: User Administrator
      Member groups: useradmins
      Privileges: user administrators
      -------------------------
      Number of members added 1
    -------------------------
    

10.4.2. パーミッション

10.4.2.1. Web UI での新規パーミッションの作成
  1. トップメニューで IPA Server タブを開き、Role Based Access Control サブタブを選択します。
  2. Permissions タスクリンクを選択します。

    図10.12 パーミッションタスク

    パーミッションタスク
  3. パーミッションのリストの上部にある Add ボタンをクリックします。

    図10.13 新規パーミッションの追加

    新規パーミッションの追加
  4. 表示される形式で、新しいパーミッションのプロパティーを定義します。

    図10.14 パーミッションを追加するためのフォーム

    パーミッションを追加するためのフォーム
  5. フォームの下にある Add ボタンをクリックして、パーミッションを保存します。
以下のパーミッションプロパティーを指定できます。
  1. 新規パーミッションの名前を入力します。
  2. 適切なバインドルールタイプを選択します。
    • permission はデフォルトのパーミッションタイプで、権限およびロール経由でアクセスを付与します。
    • all は、パーミッションをすべての認証ユーザーに適用することを指定します。
    • anonymous は、認証されていないユーザーを含む、パーミッションがすべてのユーザーに適用されることを指定します。
    注記
    特権には、デフォルト以外のバインドルールタイプが指定されたパーミッションを追加できません。特権に既存のパーミッションは、デフォルト以外のバインドルールタイプには設定できません。
  3. Granted rightsで、パーミッションを付与する権利を選択してください。
  4. パーミッションのターゲットエントリーを識別する方法を定義します。
    • タイプ は、ユーザー、ホスト、またはサービスなどのエントリータイプを指定します。Type 設定の値を選択すると、そのエントリータイプのこの ACI からアクセス可能なすべての属性のリストが Effective 属性 に表示されます。
      Type を定義すると、Subtree および Target DN が事前定義された値のいずれかに設定されます。
    • Subtree はサブツリーエントリーを指定します。このサブツリーエントリーの下にあるすべてのエントリーがターゲットになります。Subtree はワイルドカードや存在しないドメイン名 (DN) を許可しないため、既存のサブツリーエントリーを指定します。以下に例を示します。
      cn=automount,dc=example,dc=com
    • 追加のターゲットフィルター は LDAP フィルターを使用して、パーミッションが適用されるエントリーを特定します。このフィルターには、有効な LDAP フィルターを使用できます。以下に例を示します。
      (!(objectclass=posixgroup))
      IdM は、指定のフィルターの有効性を自動的に確認します。無効なフィルターを入力すると、パーミッションを保存しようとすると、IdM はこれについて警告します。
    • ターゲット DN はドメイン名 (DN) を指定し、ワイルドカードを受け入れます。以下に例を示します。
      uid=*,cn=users,cn=accounts,dc=com
    • グループのメンバー は、指定したグループのメンバーにターゲットフィルターを設定します。
    フィルター設定を入力し、Add をクリックすると、IdM がフィルターを検証します。すべてのパーミッション設定が正しい場合は、IdM により検索が実行されます。パーミッション設定の一部が正しくない場合には、IdM により、どの設定が正しく設定されているかを示すメッセージが表示されます。
  5. Type を設定する場合は、利用可能な ACI 属性のリストから 有効な属性 を選択します。Type を使用しない場合は、有効な属性 フィールドに属性を手動で書き込みます。一度に 1 つの属性を追加します。複数の属性を追加するには、Add をクリックして別の入力フィールドを追加します。
    重要
    パーミッションの属性を設定しないと、デフォルトですべての属性が含まれます。
10.4.2.2. コマンドライン での新規パーミッションの作成
新しいパーミッションを追加するには、ipa permission-add コマンドを実行します。対応するオプションを指定して、パーミッションのプロパティーを指定します。
  • パーミッションの名前を指定します。以下に例を示します。
    [root@server ~]# ipa permission-add "dns admin permission"
  • --bindtype は、バインドルールの種別を指定します。このオプションは、all 引数、anonymous 引数、および permission 引数を受け入れます。以下に例を示します。
    --bindtype=all
    --bindtype を使用しない場合、タイプは自動的にデフォルトの permission 値に設定されます。
    注記
    特権には、デフォルト以外のバインドルールタイプが指定されたパーミッションを追加できません。特権に既存のパーミッションは、デフォルト以外のバインドルールタイプには設定できません。
  • --permissions は、パーミッションが付与する権限をリスト表示します。複数の属性を設定するには、複数の --permissions オプションを使用するか、オプションを中括弧内にコンマ区切りリストでリスト表示します。以下に例を示します。
    --permissions=read --permissions=write
    --permissions={read,write}
  • --attrs は、パーミッションが付与される属性のリストを提供します。複数の属性を設定するには、複数の --attrs オプションを使用するか、オプションを中括弧内にコンマ区切りリストでリスト表示します。以下に例を示します。
    --attrs=description --attrs=automountKey
    --attrs={description,automountKey}
    --attrs で提供される属性が存在し、指定のオブジェクトタイプに許可される属性である必要があります。指定しないと、コマンドがスキーマ構文エラーで失敗します。
  • --type は、ユーザー、ホスト、またはサービスなどのエントリーオブジェクトタイプを定義します。各タイプには、許可された属性の独自のセットがあります。以下に例を示します。
    [root@server ~]# ipa permission-add "manage service" --permissions=all --type=service --attrs=krbprincipalkey --attrs=krbprincipalname --attrs=managedby
  • --subtree はサブツリーエントリーを提供します。フィルターはこのサブツリーエントリーの下にあるすべてのエントリーをターゲットにします。既存のサブツリーエントリーを指定します。--subtree はワイルドカードや存在しないドメイン名 (DN) を受け入れません。ディレクトリーに DN を追加します。
    IdM は簡素化されたフラットディレクトリーツリー構造を使用しているため、--subtree を使用して自動マウントの場所 (他の設定のコンテナーまたは親エントリー) などの一部のエントリーをターゲットにすることができます。以下に例を示します。
    [root@server ~]# ipa permission-add "manage automount locations" --subtree="ldap://ldap.example.com:389/cn=automount,dc=example,dc=com" --permissions=write --attrs=automountmapname --attrs=automountkey --attrs=automountInformation
    --type オプションおよび --subtree オプションは相互に排他的です。
  • --filter は LDAP フィルターを使用して、パーミッションが適用されるエントリーを特定します。IdM は、指定のフィルターの有効性を自動的に確認します。このフィルターには、有効な LDAP フィルターを使用できます。以下に例を示します。
    [root@server ~]# ipa permission-add "manage Windows groups" --filter="(!(objectclass=posixgroup))" --permissions=write --attrs=description
  • --memberof は、グループが存在することを確認した後に、指定したグループのメンバーにターゲットフィルターを設定します。以下に例を示します。
    [root@server ~]# ipa permission-add ManageHost --permissions="write" --subtree=cn=computers,cn=accounts,dc=testrelm,dc=com --attr=nshostlocation --memberof=admins
  • --targetgroup は、グループが存在することを確認した後に、ターゲットを指定されたユーザーグループに設定します。
Web UI で利用可能な Target DN 設定はコマンドラインで利用できません。
注記
パーミッションの変更および削除の詳細は、ipa permission-mod --help コマンドおよび ipa permission-del --help コマンドを実行します。
10.4.2.3. デフォルトの管理パーミッション
管理 パーミッションは、Identity Management で事前にインストールしたパーミッションです。このパーミッションはユーザーが作成した他のパーミッションと同様に機能しますが、以下の相違点があります。
  • 名前、場所、およびターゲット属性を変更することはできません。
  • これらは削除できません。
  • このパーミッションには 3 つの属性セットがあります。
    • デフォルト 属性 (IdM により管理され、ユーザーが変更できない)
    • 含まれる 属性 (ユーザーが追加する属性): 管理パーミッションに含まれる属性を追加するには、ipa permission-mod コマンドで --includedattrs オプションを指定して属性を指定します。
    • 除外する 属性 (ユーザーが削除する属性): 管理パーミッションに除外する属性を追加するには、ipa permission-mod コマンドで --excludedattrs オプションを指定して属性を指定します。
管理パーミッションは、デフォルトおよび包含属性セットに表示されている属性すべてに適用されますが、除外セットに表示されている属性には適用されません。
管理パーミッションの変更時に --attrs オプションを使用する場合は、含まれる属性および除外する属性セットが自動的に調整され、--attrs で指定された属性のみが有効になります。
注記
管理されているパーミッションを削除することはできませんが、そのバインドタイプを permission に設定し、すべての権限から管理パーミッションを削除すると、そのパーミッションを効果的に無効にできます。
管理されたすべてのパーミッションの名前は System: から始まります (例: System: Add Sudo rule または System: Modify Services)。
以前のバージョンの IdM では、デフォルトのパーミッションに異なるスキームを使用していました。たとえば、ユーザーがデフォルトのパーミッションを変更するのを禁止し、ユーザーはパーミションを権限に割り当てることしかできませんでした。これらのデフォルトパーミッションのほとんどは、管理パーミッションに切り替わっていますが、以下のパーミッションは引き続き以前のスキームを使用します。
  • Automember Rebuild メンバーシップタスクの追加
  • レプリカ合意の追加
  • 証明書削除保留
  • CA から証明書のステータス取得
  • DNA 範囲の変更
  • レプリカ合意の修正
  • レプリカ合意の削除
  • 証明書の要求
  • 別のホストからの証明書の要求
  • CA からの証明書の取得
  • 証明書の取り消し
  • IPA 設定の書き込み
Web UI から管理パーミッションを変更しようとすると、変更できない属性が無効になります。

図10.15 無効にされた属性

無効にされた属性
コマンドラインから管理パーミッションを変更しようとした場合、システムは変更できない属性を変更するのを許可しません。たとえば、デフォルトのSystem: Modify Usersパーミッションを変更してグループに適用しようとしても失敗します。
$ ipa permission-mod 'System: Modify Users' --type=group
ipa: ERROR: invalid 'ipapermlocation': not modifiable on managed permissions
ただし、System: Modify Users パーミッションが GECOS 属性に適用されないようにすることはできます。
$ ipa permission-mod 'System: Modify Users' --excludedattrs=gecos
------------------------------------------
Modified permission "System: Modify Users"
10.4.2.4. 以前のバージョンの Identity Management におけるパーミッション
Identity Management の以前のバージョンでは、パーミッションの処理方法が異なりました。以下に例を示します。
  • グローバル IdM ACI は、匿名のユーザー (つまり認証されないユーザー) であっても、サーバーのすべてのユーザーに読み取りアクセスを付与しました。
  • 書き込み、追加、および削除のパーミッションタイプのみが利用可能でした。読み取りパーミッションも利用できましたが、認証されていないユーザーを含むすべてのユーザーにはデフォルトで読み取りアクセスがあるため、実用的値はほとんどありませんでした。
Identity Management の現在のバージョンには、パーミッションを設定するオプションが含まれており、これはより粒度の細かいものになります。
  • グローバル IdM ACI は、認証されていないユーザーに読み取りアクセスを付与しません。
  • たとえば、フィルターとサブツリーの両方を同じパーミッションに追加できるようになりました。
  • 検索および比較権限を追加できます。
パーミッションを処理する新しい方法では、以前のバージョンとの後方互換性を維持しながら、ユーザーまたはグループのアクセス制御に関して IdM 機能が大幅に改善されました。以前のバージョンの IdM からアップグレードすると、すべてのサーバー上のグローバル IdM ACI が削除され、管理パーミッション に置き換えられます。
以前の方法で作成されたパーミッションは、変更する際に、現在のスタイルに自動的に変換されます。それらを変更しようとしないと、以前のタイプのパーミッションは変換されません。パーミッションが現在のスタイルを使用したら、以前のスタイルにダウングレードすることはできません。
注記
以前のバージョンの IdM を実行しているサーバーで、引き続きパーミッションを権限に割り当てることはできます。
ipa permission-show コマンドおよび ipa permission-find コマンドは、現在のパーミッションと以前のスタイルのパーミッションの両方を認識します。これらの両方のコマンドからの出力は、パーミッションを現在のスタイルで表示しますが、パーミッション自体は変更されません。LDAP に変更をコミットせずに、コマンドはメモリー内にのみデータを出力する前にパーミッションエントリーをアップグレードします。
以前の特性を持つパーミッションと現在の特性を持つパーミッションは、どちらもすべてのサーバー (以前のバージョンの IdM を実行するものと、現在の IdM バージョンを実行するもの) に影響します。ただし、以前のバージョンの IdM を実行しているサーバーで、現在のパーミッションでパーミッションを作成または変更することはできません。

10.4.3. 権限

10.4.3.1. Web UI での新規権限の作成
  1. トップメニューで IPA Server タブを開き、Role Based Access Control サブタブを選択します。
  2. Privileges タスクリンクを選択します。
  3. 特権リストの上部にある Add リンクをクリックします。

    図10.17 新しい権限の追加

    新しい権限の追加
  4. 権限の名前と説明を入力します。

    図10.18 権限を追加するためのフォーム

    権限を追加するためのフォーム
  5. Add and Edit をクリックして、権限設定ページに移動し、パーミッションを追加します。
  6. Permissions タブを選択します。
  7. パーミッションリストの上部にある Add をクリックして、パーミッションを権限に追加します。

    図10.19 パーミッションの追加

    パーミッションの追加
  8. 追加するパーミッションの名前の横にあるチェックボックスをクリックし、> ボタンを使用してパーミッションを Prospective 列に移動します。

    図10.20 パーミッションの選択

    パーミッションの選択
  9. Add ボタンをクリックして保存します。
10.4.3.2. コマンドライン での新規権限の作成
権限エントリーは、privilege-add コマンドを使用して作成され、privilege-add-permission コマンドを使用して権限グループに追加されます。
  1. 権限エントリーを作成します。
    [jsmith@server ~]$ ipa privilege-add "managing filesystems" --desc="for filesystems"
  2. 必要なパーミッションを割り当てます。以下に例を示します。
    [jsmith@server ~]$ ipa privilege-add-permission "managing filesystems" --permissions="managing automount" --permissions="managing ftp services"

パート IV. 管理: アイデンティティーの管理

このパートでは、ユーザーアカウント、ホスト、ユーザーグループ、およびホストグループを管理する方法を説明します。さらに、一意の UID 番号および GID 番号の割り当てと表示方法、ユーザーおよびグループスキーマの機能も詳細に説明します。本章では、サービスの管理と、ホストおよびサービスへのアクセスの委譲を説明します。最後の章では、ID 管理 ユーザー向けに アクセス制御 を定義する方法、Kerberosフラグおよびプリンシパルエイリアスを管理する方法、NIS ドメインおよび ネットグループ との統合方法を説明します。

第11章 ユーザーアカウントの管理

本章では、ユーザーアカウントの一般的な管理および設定を説明します。

11.1. ユーザーホームディレクトリーの設定

すべてのユーザーにホームディレクトリーが設定されていることが推奨されます。ユーザーのホームディレクトリー用のデフォルトの場所は /home/ ディレクトリーにあります。たとえば、IdM は、user_login ログインを持つユーザーに /home/user_login にホームディレクトリーが設定されていることを想定しています。
注記
ipa config-mod コマンドを使用すると、ユーザーのホームディレクトリーのデフォルトの想定される場所を変更できます。
IdM は、ユーザーにホームディレクトリーを自動的に作成しません。ただし、ユーザーのログイン時に自動的にホームディレクトリーを作成する PAM ホームディレクトリーモジュールを設定できます。または、NFS 共有および automount ユーティリティーを使用して、ホームディレクトリーを手動で追加できます。

11.1.1. PAM ホームディレクトリーモジュールを使用したホームディレクトリーの自動マウント

サポートされる PAM ホームディレクトリーモジュール
PAM ホームディレクトリーモジュールを設定して、IdM ドメインにログインする際に、ユーザーのホームディレクトリーを自動的に作成するには、以下の PAM モジュールのいずれかを使用します。
  • pam_oddjob_mkhomedir
  • pam_mkhomedir
IdM は最初に pam_oddjob_mkhomedir の使用を試行します。このモジュールがインストールされていない場合は、IdM は代わりに pam_mkhomedir の使用を試行します。
注記
新規ユーザー用のホームディレクトリーの NFS 共有での自動作成はサポートされていません。
PAM ホームディレクトリーモジュールの設定
PAM ホームディレクトリーモジュールを有効にすると、ローカルに影響します。そのため、必要な各クライアントおよびサーバーでモジュールを個別に有効にする必要があります。
サーバーまたはクライアントのインストール時にモジュールを設定するには、マシンのインストール時に ipa-server-install または ipa-client-install ユーティリティーで --mkhomedir オプションを使用します。
すでにインストールされているサーバーまたはクライアントにモジュールを設定するには、authconfig ユーティリティーを使用します。以下に例を示します。
# authconfig --enablemkhomedir --update
authconfig を使用してホームディレクトリーを作成する方法は、System-Level Authentication Guideを参照してください。

11.1.2. ホームディレクトリーの手動マウント

NFS ファイルサーバーを使用して、IdM ドメインのすべてのマシンで利用可能な /home/ ディレクトリーを提供してから、automount ユーティリティーを使用して IdM マシンにディレクトリーをマウントすることができます。
NFS 使用時の潜在的な問題
NFS を使用すると、パフォーマンスやセキュリティーに悪影響を与える可能性があります。たとえば、NFS を使用することで、NFS ユーザーへの root アクセス付与によるセキュリティーの問題、/home ツリー全体を読み込む際のパフォーマンスの問題、ホームディレクトリーにリモートサーバーを使用する際のネットワークパフォーマンスの問題などが発生する可能性があります。
これらの問題の影響を減らすには、以下のガイドラインに従うことを推奨します。
  • automount を使用して、ユーザーがログインした時のみ、ユーザーのホームディレクトリーのみをマウントします。/home/ ツリー全体を読み込む時に使用しないでください。
  • 限定的なパーミッションを割り当てたリモートユーザーを使用してホームディレクトリーを作成し、そのユーザーとして IdM サーバーに共有をマウントします。IdM サーバーは httpd プロセスとして実行されるため、sudo または同様のプログラムを使用して IdM サーバーへの限定的なパーミッションを許可し、NFS サーバーにホームディレクトリーを作成できます。
NFS およびautomountを使用したホームディレクトリーの設定
NFS 共有と automount を使用して、ホームディレクトリーを別の場所から IdM サーバーに手動で追加するには、以下の手順を実施します。
  1. ユーザーディレクトリーマップ用に新しい場所を作成します。
    $ ipa automountlocation-add userdirs
    Location: userdirs
  2. 新しい場所の auto.direct ファイルに直接マッピングを追加します。auto.direct ファイルは、ipa-server-install ユーティリティーが自動作成する 自動マウント のマッピングです。以下の例では、マウントポイントは /share です。
    $ ipa automountkey-add userdirs auto.direct --key=/share --info="-ro,soft, server.example.com:/home/share"
    
    Key: /share
    Mount information: -ro,soft, server.example.com:/home/share
IdM で 自動マウント を使用する方法は、34章Automount の使用 を参照してください。

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

Identity Management は、stageactive、および preserved の 3 つのユーザーアカウントの状態をサポートします。
  • ステージ ユーザーは認証できません。これは初期状態です。アクティブユーザーに必要なユーザーアカウントプロパティーの一部が設定されていない可能性があります。
  • アクティブ ユーザーは認証が可能です。必要なユーザーアカウントプロパティーはすべて、この状態で設定する必要があります。
  • 保存済みユーザーは、以前は アクティブなユーザーでした。非アクティブであると見なされ、IdM に対して認証できません。保存済みユーザーには、アクティブユーザーのときに有効になっていたアカウントプロパティーの大部分が保持されていますが、ユーザーグループからは除外されています。
    注記
    保存済み 状態のユーザーのリストは、以前のユーザーアカウントの履歴を提供します。
ユーザーエントリーは、IdM データベースから完全に削除することもできます。ユーザーエントリーを完全に削除すると、エントリー自体とグループメンバーシップやパスワードなど、そのユーザーの情報をすべて IdM から削除します。ユーザーの外部設定 (システムアカウントやホームディレクトリーなど) は削除されませんが、IdM からはアクセスできなくなります。
重要
削除したユーザーアカウントを復元することはできません。ユーザーアカウントを削除すると、そのアカウントに関連する情報がすべて永続的に失われます。
新規管理ユーザーは、デフォルトのadminユーザーなど、他の管理者のみが作成できます。すべての管理者アカウントを誤って削除した場合は、Directory Manager が、Directory Server に新しい管理者を手動で作成する必要があります。
警告
admin ユーザーを削除しないでください。admin は IdM で必要な事前定義ユーザーであるため、この操作では特定のコマンドで問題が生じます。代替の admin ユーザーを定義して使用する場合は、管理者パーミッションを少なくとも 1 人のユーザーに付与した後に ipa user-disable admin で事前定義された admin ユーザーを無効にします。
ユーザーライフサイクル管理操作
ユーザーのプロビジョニングを管理するために、管理者はユーザーアカウントをある状態から別の状態に移行することができます。新規ユーザーアカウントは、active または stage のいずれかとして追加できますが、preserved としては追加できません。
IdM は、ユーザーのライフサイクル管理に対する以下の操作をサポートします。
stage → active
stage 状態のアカウントを適切にアクティブ化する準備ができると、管理者は active 状態に移行します。
active → preserved
ユーザーが会社を離れると、管理者はアカウントを preserved 状態に移行します。
preserved → active
先ほどのユーザーが会社に再度参加します。管理者は、ユーザーアカウントをpreserved 状態から active 状態に戻して、ユーザーアカウントを復元します。
preserved → stage
先ほどのユーザーは、会社に再び参加する計画です。管理者は、アカウントを preserved 状態から stage 状態に移動して、今後の再アクティブ化に向けてアカウントを準備します。
IdM からアクティブユーザー、ステージユーザー、および保存済みユーザーを完全に削除することもできます。ステージユーザーを preserved 状態に移動することはできず、永続的に削除できるだけです。

図11.1 ユーザーのライフサイクルの操作

ユーザーのライフサイクルの操作

11.2.1. stage または Active ユーザーの追加

Web UI でユーザーの追加
  1. IdentityUsers タブを選択します。
  2. active または stage 状態のユーザーを追加するかどうかに応じて、Active users または Stage users カテゴリーを選択します。

    図11.2 ユーザーカテゴリーの選択

    ユーザーカテゴリーの選択
    アクティブ または ステージユーザーの ライフサイクルの状態についての詳細は、「ユーザーのライフサイクル」 を参照してください。
  3. ユーザーリストの上部にある 追加 をクリックします。

    図11.3 ユーザーの追加

    ユーザーの追加
  4. Add User フォームを入力します。
    ユーザーログインを手動で設定しないと、IdM は指定された名および姓に基づいてログインを自動的に生成することに注意してください。
  5. Add をクリックします。
    または、Add and Add Another をクリックして別のユーザーの追加を開始するか、Add and Edit をクリックして新規ユーザーエントリーの編集を開始します。ユーザーエントリーの編集に関する情報は、「ユーザーの編集」 を参照してください。
コマンドラインからのユーザーの追加
active 状態で新規ユーザーを追加するには、ipa user-add コマンドを使用します。stage 状態で新規ユーザーを追加するには、ipa stageuser-add コマンドを使用します。
注記
アクティブ または ステージユーザーの ライフサイクルの状態についての詳細は、「ユーザーのライフサイクル」 を参照してください。
オプションなしで実行する場合は、ipa user-add および ipa stageuser-add により、必要最小限のユーザー属性の入力が求められ、その他の属性にはデフォルト値が使用されます。または、コマンドに直接、さまざまな属性を指定するオプションを追加することもできます。
インタラクティブセッションでは、オプションを指定せずにコマンドを実行すると、IdM は指定の名および姓に基づいて自動生成されたユーザーログインを提案し、大かっこ ([ ]) に表示します。デフォルトのログインを受け入れるには、Enter を押して確認します。カスタムログインを指定するには、デフォルトのログインを確認せず、代わりにカスタムログインを指定してください。
$ ipa user-add
First name: first_name
Last name: last_name
User login [default_login]: custom_login
ipa user-add および ipa stageuser-add にオプションを追加すると、多くのユーザー属性にカスタム値を定義できます。つまり、対話型セッションよりも多くの情報を指定できます。たとえば、ステージユーザーを追加するには、以下を実行します。
$ ipa stageuser-add stage_user_login --first=first_name --last=last_name --email=email_address
ipa user-add および ipa stageuser-add で使用できるオプションの完全リストは、--help オプションを追加してコマンドを実行します。
11.2.1.1. ユーザー名の要件
IdM は、以下の正規表現で説明できるユーザー名をサポートします。
'(?!^[0-9]+$)^[a-zA-Z0-9_.][a-zA-Z0-9_.-]*[a-zA-Z0-9_.$-]?$'
ユーザー名には、文字、数字、_、-、.、$ のみを含めることができ、少なくとも 1 文字が含まれている必要があります。
注記
ユーザー名の末尾がドル記号 ($) で終わる場合は、Samba 3.x マシンでのサポートが有効になります。
大文字を含むユーザー名を追加すると、IdM が名前を保存する際に自動的に小文字に変換されます。したがって、IdM にログインする場合、ユーザーは常にユーザー名をすべて小文字で入力する必要があります。また、userUser など、大文字と小文字のみが異なるユーザー名を追加することはできません。
ユーザー名のデフォルトの長さは、最大 32 文字です。これを変更するには、ipa config-mod --maxusername コマンドを使用します。たとえば、ユーザー名の最大長を 64 文字にするには、次のコマンドを実行します。
$ ipa config-mod --maxusername=64
  Maximum username length: 64
  ...
11.2.1.2. カスタム UID または GID 番号の定義
カスタムの UID または GID 番号を指定せずに新しいユーザーエントリーを追加すると、IdM は ID 範囲で次に利用可能な ID 番号を自動的に割り当てます。これは、ユーザーの ID 番号が常に一意であることを意味します。ID 範囲の詳細は、14章一意の UID および GID 番号の割り当て を参照してください。
カスタム ID 番号を指定する場合、サーバーはカスタム ID 番号が一意であるかどうかを検証しません。このため、複数のユーザーエントリーに同じ ID 番号が割り当てられる可能性があります。Red Hat は、複数のエントリーに同じ ID 番号を割り当てることがないようにすることを推奨します。

11.2.2. ユーザーのリスト表示およびユーザーの検索

Web UI でのユーザーのリスト表示
  1. IdentityUsers タブを選択します。
  2. Active usersStage users、または Preserved users カテゴリーを選択します。

    図11.4 ユーザーのリスト表示

    ユーザーのリスト表示
Web UI でのユーザーに関する情報の表示
ユーザーに関する詳細情報を表示するには、ユーザーリストでユーザーの名前をクリックします。

図11.5 ユーザー情報の表示

ユーザー情報の表示
コマンドラインからのユーザーのリスト表示
アクティブなユーザーをリスト表示するには、ipa user-find コマンドを実行します。すべてのステージユーザーをリスト表示するには、ipa stageuser-find コマンドを使用します。保存済みユーザーのリストを表示するには、ipa user-find --preserved=true コマンドを実行します。
以下に例を示します。
$ ipa user-find
---------------
23 users matched
---------------
  User login: admin
  Last name: Administrator
  Home directory: /home/admin
  Login shell: /bin/bash
  UID: 1453200000
  GID: 1453200000
  Account disabled: False
  Password: True
  Kerberos keys available: True

  User login: user
...
ipa user-find および ipa stageuser-find にオプションと引数を追加すると、検索条件を定義し、検索結果をフィルタリングできます。たとえば、特定のタイトルが定義されているアクティブユーザーをすべて表示するには、次のコマンドを実行します。
$ ipa user-find --title=user_title
---------------
2 users matched
---------------
  User login: user
...
  Job Title: Title
...

  User login: user2
...
  Job Title: Title
...
同様に、ログインに user が含まれる全ステージユーザーを表示するには、以下を実行します。
$ ipa user-find user
---------------
3 users matched
---------------
User login: user
...

User login: user2
...

User login: user3
...
ipa user-find および ipa stageuser-find で使用できるオプションの完全リストは、--help オプションを追加してコマンドを実行します。
コマンドラインからのユーザーに関する情報の表示
アクティブユーザーまたは保存済みユーザーの情報を表示するには、ipa user-show コマンドを使用します。
$ ipa user-show user_login
  User login: user_login
  First name: first_name
  Last name: last_name
...
ステージユーザーの情報を表示するには、ipa stageuser-show コマンドを使用します。

11.2.3. ユーザーのアクティベート、保存、削除、および復元

本セクションでは、ユーザーライフサイクルの異なる状態間でユーザーアカウントを移動する方法を説明します。IdM のライフサイクルの状態の詳細は、「ユーザーのライフサイクル」 を参照してください。
Web UI でのユーザーのライフサイクルの管理
ステージユーザーをアクティベートするには、以下を実行します。
  • Stage users リストで、アクティブにするユーザーを選択し、Activate をクリックします。

    図11.6 ユーザーのアクティブ化

    ユーザーのアクティブ化
ユーザーを保存するか、削除するには、以下を実行します。
  1. アクティブユーザー または ステージユーザー のリストで、ユーザーを選択します。Delete をクリックします。

    図11.7 ユーザーの削除

    ユーザーの削除
  2. アクティブなユーザーを選択した場合は、delete または preserve を選択します。ステージユーザーを選択している場合は、ユーザーを削除することしかできません。デフォルトの UI オプションは delete です。
    たとえば、アクティブユーザーを保存するには、次のコマンドを実行します。

    図11.8 Web UI での削除モードの選択

    Web UI での削除モードの選択
    確認するには、Delete ボタンをクリックします。
保存済みユーザーを復元するには、以下を実行します。
  • Preserved users リストで、復元するユーザーを選択し、Restore をクリックします。

    図11.9 ユーザーの復元

    ユーザーの復元
注記
ユーザーアカウントを復元しても、そのアカウントの以前の属性がすべて復元されるわけではありません。たとえば、ユーザーのパスワードは復元されず、再度定義する必要があります。
Web UI では、ユーザーを preserved 状態から stage 状態に移行することができないことに注意してください。
コマンドラインからのユーザーのライフサイクルの管理
ステージ から アクティブ に移行してユーザーアカウントをアクティベートするには、ipa stageuser-activate コマンドを使用します。
$ ipa stageuser-activate user_login
-------------------------
Stage user user_login activated
-------------------------
...
ユーザーアカウントを保存または削除するには、ipa user-del コマンドまたは ipa stageuser-del コマンドを使用します。
  • IdM データベースからアクティブなユーザーを永続的に削除するには、オプションを指定せずに ipa user-del を実行します。
    $ ipa user-del user_login
    --------------------
    Deleted user "user3"
    --------------------
    
  • アクティブなユーザーアカウントを保持するには、--preserve オプションを指定して ipa user-del を実行します。
    $ ipa user-del --preserve user_login
    --------------------
    Deleted user "user_login"
    --------------------
    
  • IdM データベースからステージユーザーを永続的に削除するには、ipa stageuser-del を実行します。
    $ ipa stageuser-del user_login
    --------------------------
    Deleted stage user "user_login"
    --------------------------
    
注記
複数のユーザーを削除するときは、--continue オプションを使用して、エラーに関係なくコマンドを続行します。成功および失敗した操作の概要は、コマンドが完了したときに標準出力ストリーム (stdout) に出力されます。
$ ipa user-del --continue user1 user2 user3
--continue を使用しないと、コマンドはエラーが発生するまでユーザーの削除を続行し、停止と終了を行います。
保存済みユーザーアカウントをpreserved から active に移行して保存済みユーザーアカウントを復元するには、ipa user-undel コマンドを使用します。
$ ipa user-undel user_login
------------------------------
Undeleted user account "user_login"
------------------------------
保存済みユーザーアカウントをpreserved から stage に移行して保存済みユーザーアカウントを復元するには、ipa user-stage コマンドを使用します。
$ ipa user-stage user_login
------------------------------
Staged user account "user_login"
------------------------------
注記
ユーザーアカウントを復元しても、そのアカウントの以前の属性がすべて復元されるわけではありません。たとえば、ユーザーのパスワードは復元されず、再度定義する必要があります。
これらのコマンドとそれらが受け入れるオプションの詳細は、-helpオプションを追加して実行してください。

11.3. ユーザーの編集

Web UI でのユーザーの編集
  1. IdentityUsers タブを選択します。
  2. Active usersStage users、または Preserved users カテゴリーを検索し、編集するユーザーを検索します。
  3. 編集するユーザー名をクリックします。

    図11.10 編集するユーザーの選択

    編集するユーザーの選択
  4. 必要に応じてユーザー属性フィールドを編集します。
  5. ページ上部にある Save をクリックします。

    図11.11 変更後のユーザー属性の保存

    変更後のユーザー属性の保存
Web UI でユーザー詳細を更新しても、新しい値は即座に同期されません。新しい値がクライアントシステムで反映されるまで、最長 5 分の時間がかかる可能性があります。
コマンドラインからのユーザーの編集
active または preserved 状態のユーザーを修正するには、ipa user-mod コマンドを使用します。stage 状態のユーザーを変更するには、ipa stageuser-mod コマンドを使用します。
ipa user-mod コマンドおよび ipa stageuser-mod コマンドは、以下のオプションを受け入れます。
  • 変更するユーザーアカウントを特定するユーザーログイン
  • 新しい属性値を指定するオプション
コマンドラインから変更できるユーザーエントリー属性の完全リストは、ipa user-mod および ipa stageuser-mod で使用できるオプションのリストを参照してください。オプションのリストを表示するには、--help オプションを追加してコマンドを実行します。
ipa user-mod または ipa stageuser-mod に属性オプションを追加すると、現在の属性値が上書きされます。たとえば、以下は、ユーザーのタイトルを変更するか、タイトルが指定されていない場合には新しいタイトルを追加します。
$ ipa user-mod user_login --title=new_title
複数の値を使用できる LDAP 属性の場合、IdM でも複数の値を使用できます。たとえば、ユーザーは 2 つのメールアドレスをユーザーアカウントに保存できます。既存の値を上書きせずに別の属性値を追加するには、新しい属性値を指定するオプションと共に--addattr オプションを使用します。たとえば、メールアドレスがすでに指定されているユーザーアカウントに新しいメールアドレスを追加するには、次のコマンドを実行します。
$ ipa user-mod user --addattr=mobile=new_mobile_number
--------------------
Modified user "user"
--------------------
  User login: user
...
  Mobile Telephone Number: mobile_number, new_mobile_number
...
同時に 2 つの属性値を設定するには、--addattr オプションを 2 回使用します。
$ ipa user-mod user --addattr=mobile=mobile_number_1 --addattr=mobile=mobile_number_2
ipa user-mod コマンドでは、属性値を設定する --setattr オプションと、属性値を削除する --delattr オプションも使用できます。これらのオプションは、--addattr の使用と同様の方法で使用されます。詳細は、ipa user-mod --help コマンドの出力を参照してください。
注記
ユーザーの現在のメールアドレスを上書きするには、--email オプションを使用します。ただし、メールアドレスを追加するには、--addattr オプションと共に mail オプションを使用します。
$ ipa user-mod user --email=email@example.com

$ ipa user-mod user --addattr=mail=another_email@example.com

11.4. ユーザーアカウントの有効化、無効化

管理者は、アクティブユーザーのアカウントを無効および有効にすることができます。ユーザーアカウントを無効にすると、アカウントが非アクティブになります。無効にしたユーザーアカウントを使用して認証することはできません。アカウントが無効になったユーザーは IdM にログインできず、Kerberos などの IdM サービスを使用したり、タスクを実行したりすることができません。
無効にしたユーザーアカウントはそのまま IdM に残り、関連する情報は何も変更しません。保存済みユーザーのアカウントとは異なり、無効にしたユーザーアカウントは active 状態のままになります。したがって、ipa user-find コマンドの出力に表示されます。以下に例を示します。
$ ipa user-find
...
  User login: user
  First name: User
  Last name: User
  Home directory: /home/user
  Login shell: /bin/sh
  UID: 1453200009
  GID: 1453200009
  Account disabled: True
  Password: False
  Kerberos keys available: False
...
無効にしたユーザーアカウントは、すべて再度有効にできます。
注記
ユーザーアカウントを無効にした後、既存の接続はユーザーの Kerberos TGT や他のチケットの有効期限が切れるまで有効です。チケットの期限が切れると、ユーザーが更新できなくなります。
Web UI でのユーザーアカウントの有効化および無効化
  1. IdentityUsers タブを選択します。
  2. Active users リストから必要なユーザーを選択し、Disable または Enable をクリックします。

    図11.12 ユーザーアカウントの無効化または有効化

    ユーザーアカウントの無効化または有効化
コマンドラインからのユーザーアカウントの無効化および有効化
ユーザーアカウントを無効にするには、ipa user-disable コマンドを使用します。
$ ipa user-disable user_login
----------------------------
Disabled user account "user_login"
----------------------------
ユーザーアカウントを有効にするには、ipa user-enable コマンドを使用します。
$ ipa user-enable user_login
----------------------------
Enabled user account "user_login"
----------------------------

11.5. 管理者以外のユーザーによるユーザーエントリー管理の許可

デフォルトでは、adminユーザーしかユーザーのライフサイクルを管理したり、ユーザーアカウントを無効化または有効化したりすることができません。別の非管理者ユーザーがこれを実行できるようにするには、新規ロールを作成し、このロールに関連するパーミッションを追加し、管理者以外のユーザーをロールに割り当てます。
デフォルトでは、IdM には、ユーザーアカウントの管理に関する以下の権限が含まれます。
ユーザーの変更およびパスワードのリセット
この権限には、さまざまなユーザー属性を変更するパーミッションが含まれます。
ユーザー管理者
この権限には、アクティブなユーザーの追加、アクティブではないユーザーのアクティブ化、ユーザーの削除、ユーザー属性の変更を行うためのパーミッション、およびその他のパーミッションが含まれます。
ステージユーザーのプロビジョニング
この権限には、ステージユーザーを追加するパーミッションが含まれます。
ステージユーザー管理者
この権限には、ステージユーザーの追加や、ライフサイクル状態間でのユーザーの移動など、多くのライフサイクル操作を実行するパーミッションが含まれます。ただし、ユーザーを active 状態に移動するパーミッションは含まれません。
ロール、パーミッション、および権限の定義に関する情報は、「ロールベースのアクセス制御の定義」 を参照してください。
異なるユーザーが異なるユーザー管理操作を実行することの許可
ユーザーアカウントの管理に関連する異なる権限を異なるユーザーに追加できます。たとえば、従業員のアカウントのエントリーとアクティベーションの権限を分けることができます。
  • あるユーザーを、今後の従業員をステージユーザーとして IdM に追加できるがアクティブ化できないステージユーザー管理者として設定します。
  • 別のユーザーを、入社初日に従業員認証情報が検証された後にステージユーザーをアクティブ化できるセキュリティー管理者 として設定します。
ユーザーが特定のユーザー管理操作を実行できるようにするには、必要な権限で新規ロールを作成し、ユーザーをそのロールに割り当てます。

例11.1 管理者以外のユーザーによるステージユーザー追加の許可

この例は、新規ステージユーザーの追加のみが許可され、他のステージユーザー管理操作を実行できないユーザーを作成する方法を示しています。
  1. admin ユーザーまたはロールベースのアクセス制御を管理できる他のユーザーとしてログインします。
    $ kinit admin
    
  2. ステージユーザーの追加を管理する新しいカスタムロールを作成します。
    1. System Provisioning ロールを作成します。
      $ ipa role-add --desc "Responsible for provisioning stage users" "System Provisioning"
      --------------------------------
      Added role "System Provisioning"
      --------------------------------
      Role name: System Provisioning
      Description: Responsible for provisioning stage users
      
    2. Stage User Provisioning の権限をロールに追加します。この権限により、stage ユーザーを追加することができます。
      $ ipa role-add-privilege "System Provisioning" --privileges="Stage User Provisioning"
      Role name: System Provisioning
      Description: Responsible for provisioning stage users
      Privileges: Stage User Provisioning
      ----------------------------
      Number of privileges added 1
      ----------------------------
      
  3. 管理者以外のユーザーに、stage ユーザーを追加する権限を付与します。
    1. 管理者以外のユーザーが存在しない場合は、新規ユーザーを作成します。この例では、user の名前は stage_user_admin です。
      $ ipa user-add stage_user_admin --password
      First name: first_name
      Last name: last_name
      Password:
      Enter password again to verify:
      ...
      
    2. stage_user_admin ユーザーを システムプロビジョニングロール に割り当てます。
      $ ipa role-add-member "System Provisioning" --users=stage_user_admin
      Role name: System Provisioning
      Description: Responsible for provisioning stage users
      Member users: stage_user_admin
      Privileges: Stage User Provisioning
      -------------------------
      Number of members added 1
      -------------------------
      
    3. System Provisioning ロールが正しく設定されていることを確認するには、ipa role-show コマンドを使用してロール設定を表示します。
      $ ipa role-show "System Provisioning"
      --------------
      1 role matched
      --------------
      Role name: System provisioning
      Description: Responsible for provisioning stage users
      Member users: stage_user_admin
      Privileges: Stage User Provisioning
      ----------------------------
      Number of entries returned 1
      ----------------------------
      
  4. stage_user_admin ユーザーとして新しい stage ユーザーが追加されているかをテストします。
    1. stage_user_admin としてログインします。前の手順の 1 つで新しいユーザーとして stage_user_admin を作成した場合は、IdM は admin が設定した初期パスワードを変更するよう要求します。
      $ kinit stage_user_admin
      Password for stage_user_admin@EXAMPLE.COM:
      Password expired.  You must change it now.
      Enter new password:
      Enter it again:
      
    2. admin の Kerberos チケットが stage_user_admin の Kerberos チケットに置き換えられているようにするには、klist ユーティリティーを使用できます。
      $ klist
      Ticket cache: KEYRING:persistent:0:krb_ccache_xIlCQDW
      Default principal: stage_user_admin@EXAMPLE.COM
      
      Valid starting       Expires              Service principal
      02/25/2016 11:42:20  02/26/2016 11:42:20  krbtgt/EXAMPLE.COM
      
    3. 新規ステージユーザーを追加します。
      $ ipa stageuser-add stage_user
      First name: first_name
      Last name: last_name
      ipa: ERROR: stage_user: stage user not found
      
      注記
      ステージユーザーの追加後に IdM が報告するエラーは想定されたものです。stage_user_admin はステージユーザーの追加のみ許可され、それらのユーザーについての情報を表示できません。したがって、新たに追加した stage_user 設定の概要を表示する代わりに、IdM によりエラーが表示されます。
stage_user_admin ユーザーは、ステージユーザーについての情報を表示できません。したがって、stage_user_admin としてログインしている状態で新規 stage_user ユーザーに関する情報を表示しようとすると、失敗します。
$ ipa stageuser-show stage_user
ipa: ERROR: stage_user: stage user not found
stage_user に関する情報を表示するには、admin としてログインできます。
$ kinit admin
Password for admin@EXAMPLE.COM:
$ ipa stageuser-show stage_user
  User login: stage_user
  First name: Stage
  Last name: User
...

11.6. ユーザーおよびグループへの外部プロビジョニングシステムの使用

Identity Management は、環境の設定をサポートしているため、ID 管理用の外部ソリューションを使用して IdM でユーザーおよびグループ ID をプロビジョニングできます。本セクションでは、このような設定の例を説明します。この例には以下が含まれます。

11.6.1. 外部プロビジョニングシステムが使用するユーザーアカウントの設定

この手順では、外部プロビジョニングシステムが使用する 2 つの IdM ユーザーアカウントを設定する方法を説明します。適切なパスワードポリシーが指定されたグループにアカウントを追加すると、外部プロビジョニングシステムが IdM でユーザーのプロビジョニングを管理できるようになります。
  1. stage ユーザーを追加する権限を持つ provisionator という名前のユーザーを作成します。ユーザーアカウントは、新規ステージユーザーを追加するために外部プロビジョニングシステムによって使用されます。
    1. provisionator ユーザーアカウントを追加します。
      $ ipa user-add provisionator --first=provisioning --last=account --password
    2. provisionator ユーザーに必要な権限を割り当てます。
      stage ユーザーの追加を管理する System Provisioning というカスタムロールを作成します。
      $ ipa role-add --desc "Responsible for provisioning stage users" "System Provisioning"
      Stage User Provisioning の権限をロールに追加します。この特権により、ステージユーザーを追加できます。
      $ ipa role-add-privilege "System Provisioning" --privileges="Stage User Provisioning"
      provisionator ユーザーをロールに追加します。
      $ ipa role-add-member --users=provisionator "System Provisioning"
  2. ユーザーアカウントを管理する権限を持つ activator ユーザーを作成します。ユーザーアカウントは、外部プロビジョニングシステムによって追加されるステージユーザーを自動的にアクティベートするために使用されます。
    1. activator ユーザーアカウントを追加します。
      $ ipa user-add activator --first=activation --last=account --password
    2. activator ユーザーに必要な特権を付与します。
      ユーザーをデフォルトの User Administrator ロールに追加します。
      $ ipa role-add-member --users=activator "User Administrator"
  3. サービスおよびアプリケーションアカウントのユーザーグループを作成します。
    $ ipa group-add service-accounts
  4. グループのパスワードポリシーを更新します。以下のポリシーは、アカウントのパスワードの有効期限やロックアウトを防ぎますが、複雑なパスワードを必要とすることでリスクの可能性を低減します。
    $ ipa pwpolicy-add service-accounts --maxlife=10000 --minlife=0 --history=0 --minclasses=4 --minlength=20 --priority=1 --maxfail=0 --failinterval=1 --lockouttime=0
  5. サービスおよびアプリケーションアカウントのグループにプロビジョニングアカウントおよびアクティベーションアカウントを追加します。
    $ ipa group-add-member service-accounts --users={provisionator,activator}
  6. ユーザーアカウントのパスワードを変更します。
    $ kpasswd provisionator
    $ kpasswd activator
    新しい IdM ユーザーのパスワードはすぐに失効するため、パスワードの変更が必要になります。
関連情報:

11.6.2. ステージユーザーアカウントを自動的にアクティベートするための IdM の設定

この手順では、ステージユーザーをアクティベートするスクリプトを作成する方法を説明します。システムは、指定した間隔でスクリプトを自動的に実行します。これにより、新規ユーザーアカウントが自動的にアクティベートされ、作成直後に使用できます。
重要
この手順では、スクリプトが IdM に追加する前に、新しいユーザーアカウントを検証する必要がないことを前提としています。たとえば、ユーザーが外部プロビジョニングシステムの所有者によってすでに検証されている場合は、検証は必要ありません。
IdM サーバーの 1 つでのみアクティベーションプロセスを有効にするだけで十分です。
  1. アカウントのアクティベーション用に keytab ファイルを生成します。
    # ipa-getkeytab -s example.com -p "activator" -k /etc/krb5.ipa-activation.keytab
    複数の IdM サーバーでアクティベーションプロセスを有効にする場合は、1 つのサーバーだけで keytab ファイルを生成します。次に、keytab ファイルを他のサーバーにコピーします。
  2. 以下の内容を含む /usr/local/sbin/ipa-activate-all スクリプトを作成して全ユーザーをアクティベートします。
    #!/bin/bash
    
    kinit -k -i activator
    
    ipa stageuser-find --all --raw | grep "  uid:" | cut -d ":" -f 2 | while read uid; do ipa stageuser-activate ${uid}; done
  3. ipa-activate-all スクリプトのパーミッションおよび所有権を編集して、実行可能なファイルに変更します。
    # chmod 755 /usr/local/sbin/ipa-activate-all
    # chown root:root /usr/local/sbin/ipa-activate-all
  4. systemd ユニットファイル /etc/systemd/system/ipa-activate-all.service を作成して、以下の内容を追加します。
    [Unit]
    Description=Scan IdM every minute for any stage users that must be activated
    
    [Service]
    Environment=KRB5_CLIENT_KTNAME=/etc/krb5.ipa-activation.keytab
    Environment=KRB5CCNAME=FILE:/tmp/krb5cc_ipa-activate-all
    ExecStart=/usr/local/sbin/ipa-activate-all
  5. systemd タイマー /etc/systemd/system/ipa-activate-all.timer を作成して、以下の内容を追加します。
    [Unit]
    Description=Scan IdM every minute for any stage users that must be activated
    
    [Timer]
    OnBootSec=15min
    OnUnitActiveSec=1min
    
    [Install]
    WantedBy=multi-user.target
  6. ipa-activate-all.timer を有効にします。
    # systemctl enable ipa-activate-all.timer
関連情報:

11.6.3. IdM アイデンティティーを管理するための外部プロビジョニングシステムの LDAP プロバイダーの設定

本セクションでは、さまざまなユーザーおよびグループ管理操作のテンプレートを説明します。テンプレートを使用して、プロビジョニングシステムの LDAP プロバイダーを設定して、IdM ユーザーアカウントを管理できます。たとえば、従業員が退職した後にユーザーアカウントを非アクティブにするようにシステムを設定できます。
LDAP を使用したユーザーアカウントの管理
基盤の Directory Server データベースを編集して、新しいユーザーエントリーの追加、既存のエントリーの変更、ライフサイクルの異なる状態間でのユーザーの移動、またはユーザーの削除を行うことができます。データベースを編集するには、ldapmodify ユーティリティーを使用します。
以下の LDIF 形式のテンプレートは、ldapmodify を使用して変更する属性に関する情報を提供します。詳細な手順例は、例11.2「ldapmodify を使用したステージユーザーの追加」 および 例11.3「ldapmodify でのユーザーの保存」 を参照してください。
新規ステージユーザーの追加
UID と GID が自動的に割り当てられるユーザーの追加
dn: uid=user_login,cn=staged users,cn=accounts,cn=provisioning,dc=example,dc=com
changetype: add
objectClass: top
objectClass: inetorgperson
uid: user_login
sn: surname
givenName: first_name
cn: full_name
UID と GID が静的に割り当てられるユーザーの追加
dn: uid=user_login,cn=staged users,cn=accounts,cn=provisioning,dc=example,dc=com
changetype: add
objectClass: top
objectClass: person
objectClass: inetorgperson
objectClass: organizationalperson
objectClass: posixaccount
uid: user_login
uidNumber: UID_number
gidNumber: GID_number
sn: surname
givenName: first_name
cn: full_name
homeDirectory: /home/user_login
ステージユーザーの追加時に IdM オブジェクトクラスを指定する必要はありません。IdM は、ユーザーのアクティベート後にこれらのクラスを自動的に追加します。
作成したエントリーの識別名 (DN) は uid=user_login で開始する必要があります。
既存ユーザーの変更
ユーザーを変更する前に、ユーザーのログインを検索してユーザーの識別名 (DN) を取得します。以下の例では、user_allowed_to_readユーザーは、ユーザーやグループ情報の読み取りが許可されるユーザーで、password はこのユーザーのパスワードになります。
# ldapsearch -LLL -x -D "uid=user_allowed_to_read,cn=users,cn=accounts,dc=example, dc=com" -w "password" -H ldap://server.example.com -b "cn=users, cn=accounts, dc=example, dc=com" uid=user_login
ユーザーの属性を変更するには、以下を実行します。
dn: distinguished_name
changetype: modify
replace: attribute_to_modify
attribute_to_modify: new_value
ユーザーを無効にするには、以下を実行します。
dn: distinguished_name
changetype: modify
replace: nsAccountLock
nsAccountLock: TRUE
ユーザーを有効にするには、以下を実行します。
dn: distinguished_name
changetype: modify
replace: nsAccountLock
nsAccountLock: FALSE
ユーザーを保存するには、以下を実行します。
dn: distinguished_name
changetype: modrdn
newrdn: uid=user_login
deleteoldrdn: 0
newsuperior: cn=deleted users,cn=accounts,cn=provisioning,dc=example
nssAccountLock 属性の更新は、ステージユーザーおよび保存済みユーザーには影響を与えません。更新操作が正常に完了しても、属性値は nssAccountLock: TRUE のままになります。
新規グループの作成
新規グループを作成するには、以下を実行します。
dn: cn=group_distinguished_name,cn=groups,cn=accounts,dc=example,dc=com
changetype: add
objectClass: top
objectClass: ipaobject
objectClass: ipausergroup
objectClass: groupofnames
objectClass: nestedgroup
objectClass: posixgroup
cn: group_name
gidNumber: GID_number
グループの変更
グループを変更する前に、グループ名を使用して検索してグループの識別名 (DN) を取得します。
# ldapsearch -YGSSAPI  -H ldap://server.example.com -b "cn=groups,cn=accounts,dc=example,dc=com" "cn=group_name"
既存グループを削除するには、以下を実行します。
dn: group_distinguished_name
changetype: delete
グループにメンバーを追加するには、以下を実行します。
dn: group_distinguished_name
changetype: modify
add: member
member: uid=user_login,cn=users,cn=accounts,dc=example,dc=com
グループからメンバーを削除するには、以下を実行します。
dn: distinguished_name
changetype: modify
delete: member
member: uid=user_login,cn=users,cn=accounts,dc=example,dc=com
ステージまたは保存済みユーザーをグループに追加しないでください。更新操作が正常に完了しても、ユーザーはグループのメンバーとしては更新されません。アクティブなユーザーのみがグループに所属できます。

例11.2 ldapmodify を使用したステージユーザーの追加

標準の interorgperson オブジェクトクラスを使用して新規 stageuser ユーザーを追加するには、以下を実行します。
  1. ldapmodify を使用してユーザーを追加します。
    # ldapmodify -Y GSSAPI
    SASL/GSSAPI authentication started
    SASL username: admin@EXAMPLE
    SASL SSF: 56
    SASL data security layer installed.
    dn: uid=stageuser,cn=staged users,cn=accounts,cn=provisioning,dc=example
    changetype: add
    objectClass: top
    objectClass: inetorgperson
    cn: Stage
    sn: User
    
    adding new entry "uid=stageuser,cn=staged users,cn=accounts,cn=provisioning,dc=example"
    
  2. stage エントリーの内容を検証して、プロビジョニングシステムが必要なすべての POSIX 属性を追加し、stage エントリーをアクティブ化する準備ができていることを確認することを検討してください。新規 stage ユーザーの LDAP 属性を表示するには、ipa stageuser-show --all --raw コマンドを実行します。ユーザーは、nsaccountlock 属性により明示的に無効になっていることに注意してください。
    $ ipa stageuser-show stageuser --all --raw
      dn: uid=stageuser,cn=staged users,cn=accounts,cn=provisioning,dc=example
      uid: stageuser
      sn: User
      cn: Stage
      has_password: FALSE
      has_keytab: FALSE
      nsaccountlock: TRUE
      objectClass: top
      objectClass: inetorgperson
      objectClass: organizationalPerson
      objectClass: person
    

例11.3 ldapmodify でのユーザーの保存

LDAP の modrdn 操作を使用して ユーザー を保存するには、以下を実行します。
  1. ldapmodify ユーティリティーを使用してユーザーエントリーを変更します。
    $ ldapmodify -Y GSSAPI
    SASL/GSSAPI authentication started
    SASL username: admin@EXAMPLE
    SASL SSF: 56
    SASL data security layer installed.
    dn: uid=user1,cn=users,cn=accounts,dc=example
    changetype: modrdn
    newrdn: uid=user1
    deleteoldrdn: 0
    newsuperior: cn=deleted users,cn=accounts,cn=provisioning,dc=example
    
    modifying rdn of entry "uid=user1,cn=users,cn=accounts,dc=example"
    
  2. 必要に応じて、保存済みユーザーをリスト表示して、ユーザーが保持されていることを確認します。
    $ ipa user-find --preserved=true
    ---------------
    1 user matched
    ---------------
      User login: user1
      First name: first_name
      Last name: last_name
    ...
    ----------------------------
    Number of entries returned 1
    ----------------------------
    

第12章 ホストの管理

DNS と Kerberos はいずれも、初期クライアント設定の一部として設定されています。DNS と Kerberos は、マシンを IdM ドメイン内に配備し、接続先の IdM サーバーを識別できるようにするサービスなので、この設定が必要になります。初期設定後 IdM には、ドメインサービスの変更や IT 環境の変更など、Kerberos や証明書、および DNS サービスに影響するマシン自体の変更に対応するために DNS と Kerberos サービスの両方を管理するツールがあります。
本章では、クライアントマシンに直接関連する以下の ID サービスの管理方法について説明します。
  • DNS エントリーおよび設定
  • マシン認証
  • (ドメインサービスに影響する) ホスト名の変更

12.1. ホスト、サービス、およびマシン ID と認証

登録プロセスの基本的なロールは、IdM ディレクトリー内でクライアントマシン用の ホスト エントリーを作成することです。このホストエントリーは、他のホストとドメイン内のサービスの関係を確立するために使用されます (1章Red Hat Identity Management の概要を参照)。この関係では、ドメイン内ホストの認可および制御の 委譲 が不可欠な要素です。
ホストエントリーには、IdM 内のクライアントについて以下のような情報のすべてが含まれます。
  • ホストに関連付けられたサービスエントリー
  • ホストおよびサービスプリンシパル
  • アクセス制御ルール
  • 物理的位置やオペレーティングシステムなどのマシンについての情報
ホスト上で実行されるサービスには、IdM ドメインに属するものもあります。Kerberos プリンシパルまたは SSL 証明書のいずれか (またはこれら両方) を保存できるサービスは、IdM サービスとして設定できます。IdM ドメインにサービスを追加すると、そのサービスはドメインから SSL 証明書やキータブを要求することができます。(証明書の公開鍵のみがサービスレコードに保存されます。秘密鍵はサービスのローカルになります。)
IdM ドメインは、共通の ID 情報、共通ポリシー、および共有サービスを使用して、マシン間で共通性を確立します。ドメインのクライアントとしてのドメイン機能に属するマシンです。これは、ドメインが提供するサービスを使用することを意味します。IdM ドメインは、マシン専用の 3 つの主なサービスを提供します。
  • DNS
  • Kerberos
  • 証明書管理
ユーザーと同様に、マシンは IdM によって管理されるアイデンティティーです。クライアントマシンは DNS を使用して IdM サーバー、サービス、およびドメインメンバーを特定します。これは、ユーザー ID のように、IdM サーバーの 389 Directory Server インスタンスに保存されます。マシンはユーザーのように、Kerberos または証明書を使用して、ドメインに対して認証できます。
マシン側からは、これらのドメインサービスにアクセスする以下のようなタスクが実行可能です。
  • DNS ドメインへの参加 (マシン登録)
  • DNS エントリーおよびゾーンの管理
  • マシン認証の管理
IdM での認証には、ユーザーのほかにマシンも含まれます。IdM サーバーがマシンを信頼し、そのマシンにインストールされているクライアントソフトウェアからの IdM 接続を受け入れるには、マシン認証が必要です。クライアントを認証すると、IdM サーバーはそのリクエストに応答できます。IdM は、マシン認証において 3 つのアプローチをサポートします。
  • SSH 鍵。ホストの SSH 公開鍵が作成され、ホストエントリーにアップロードされます。そこから、SSSD (System Security Services Daemon) は Identity Management を ID プロバイダーとして使用し、OpenSSH およびその他のサービスと一緒に機能して、IdM の中央にある公開鍵を参照できます。この操作は、「ホストの公開 SSH 鍵の管理」 に説明があります。
  • キーテーブル (または キータブ。ユーザーパスワードに多少類似する対称キー) およびマシン証明書。Kerberos チケットは Kerberos サービスの一部として生成され、ポリシーはサーバーが定義します。初期の Kerberos チケットの付与、Kerberos 証明書の更新、Kerberos セッションの破棄はすべて IdM サービスによって処理されます。Kerberos の管理は 29章Kerberos ドメインの管理 で説明されています。
  • マシンの証明書。この場合、マシンは IdM サーバーの認証局により発行され、IdM の Directory Server に保存されている SSL 証明書を使用します。次に、証明書はマシンに送信され、サーバーに対する認証時に提示されます。クライアントでは、証明書は certmonger というサービスにより管理されます。

12.2. ホストエントリー設定のプロパティー

ホストエントリーには、ホストに関する情報 (物理的な場所、MAC アドレス、鍵、証明書など、システム設定を除く) を含めることができます。
ホストエントリーを手動で作成する場合は、これらの情報は設定可能です。手動作成でない場合は、ホストをドメインに登録した後に、この情報のほとんどを追加する必要があります。
表12.1 ホスト設定のプロパティー
UI フィールド コマンドラインオプション 説明
説明 --desc=description ホストの説明。
局所性 --locality=locality ホストの地理的な場所。
場所 --location=location データセンターのラックなど、ホストの物理的な場所。
プラットフォーム --platform=string ホストのハードウェアまたはアーキテクチャー。
オペレーティングシステム --os=string ホストのオペレーティングシステムとバージョン。
MAC アドレス --macaddress=address ホストの MAC アドレス。これは多値属性です。MAC アドレスは、NIS プラグインにより、ホスト用の NIS の ethers マップを作成するために使用されます。
SSH 公開鍵 --sshpubkey=string ホストの完全 SSH 公開鍵。これは複数値の属性であるため、複数の鍵を設定できます。
プリンシパル名 (編集不可) --principalname=principal ホストの Kerberos プリンシパル名。-p に別のプリンシパルを明示的に設定しない限り、クライアントのインストール時にホスト名がデフォルトになります。これはコマンドラインツールを使用して変更できますが、UI で変更することはできません。
ワンタイムパスワードの設定 --password=string 一括登録で使用可能なホストのパスワードを設定します。
- --random 一括登録で使用されるランダムなパスワードを生成します。
- --certificate=string ホストの証明書ブロブ。
- --updatedns これにより、IP アドレスが変更した場合に、ホストが DNS エントリーを動的に更新できるかどうかが設定されます。

12.3. ホストエントリーの追加

12.3.1. Web UI でのホストエントリーの追加

  1. Identity タブを開き、サブタブの ホスト を選択します。
  2. ホストリストの上部にある 追加 をクリックします。

    図12.1 ホストエントリーの追加

    ホストエントリーの追加
  3. マシン名を入力し、ドロップダウンリストの設定済みゾーンからドメインを選択します。ホストに静的 IP アドレスが割り当てられている場合は、ホストエントリーにそのアドレスを追加して、DNS エントリーが完全に作成されるようにします。
    必要に応じて、一部のユースケースでホストに値を追加するには、Class フィールドを使用します。この属性に配置されるセマンティクスは、ローカル解釈用です。

    図12.2 ホストウィザードの追加

    ホストウィザードの追加
    「マスター DNS ゾーンの追加および削除」で説明されているように、DNS ゾーンは IdM で作成可能です。IdM サーバーが DNS サーバーを管理しない場合は、通常のテキストフィールドなど、メニューエリアでゾーンを手動で入力できます。
    注記
    ホストが DNS 経由で解決できるかどうかの確認を行わないようにするには、強制 チェックボックスを選択します。
  4. Add and Edit をクリックして、拡張エントリーページに移動し、属性情報をさらに入力します。ホストのハードウェアと物理的な場所に関する情報は、ホストエントリーに追加できます。

    図12.3 拡張されたエントリーページ

    拡張されたエントリーページ

12.3.2. コマンドラインでのホストエントリーの追加

ホストエントリーは、host-add コマンドを使用して作成されます。このコマンドは、ホストエントリーを IdM Directory Server に追加します。host-add の全オプションリストは、ipa host の man ページに記載されています。このコマンドの最も基本的な操作では、クライアントを Kerberos レルムに追加し、IdM LDAP サーバーにエントリーを作成するために、クライアントのホスト名のみが必要となります。
$ ipa host-add client1.example.com
IdM サーバーが DNS を管理するように設定されている場合には、--ip-address および --force オプションを使用して、DNS リソースレコードにホストも追加できます。

例12.1 静的 IP アドレスのホストエントリーの作成

$ ipa host-add --force --ip-address=192.168.166.31 client1.example.com
ホストに静的 IP アドレスがないこと、またはクライアントの設定時に IP アドレスが分からないことはよくあります。たとえば、ラップトップが Identity Management クライアントとして事前設定されている場合がありますが、設定時には IP アドレスがありません。DHCP を使用するホストは、--force を使用して DNS エントリーで設定可能です。これにより、IdM DNS サービスにプレースホルダーエントリーが作成されます。DNS サービスが動的にレコードを更新すると、ホストの現行の IP アドレスが削除され、DNS レコードが更新されます。

例12.2 DHCP でのホストエントリーの作成

$ ipa host-add --force client1.example.com
ホストレコードは、host-del コマンドを使用して削除されます。IdM ドメインが DNS を使用する場合には、--updatedns オプションを使用すると、ホストに関連のあるレコードはすべて DNS から削除されます。
$ ipa host-del --updatedns client1.example.com

12.4. ホストエントリーの無効化と再有効化

アクティブなホストは、ドメイン内の他のサービスやホスト、ユーザーからアクセス可能です。アクティビティーからホストを削除する必要がある場合もあります。ただし、ホストを削除するとエントリーや関連する設定もすべて完全に削除されてしまいます。

12.4.1. ホストエントリーの無効化

ホストを無効にすると、ホストをドメインから永久に削除することなくドメインユーザーがホストにアクセスすることを防ぎます。これには、host-disable コマンドを使用します。
以下に例を示します。
[jsmith@ipaserver ~]$ kinit admin
[jsmith@ipaserver ~]$ ipa host-disable server.example.com
重要
ホストエントリーを無効にすると、そのホストが無効になるだけではありません。そのホストで設定されているすべてのサービスも無効にします。

12.4.2. ホストの再有効化

このセクションでは、無効な IdM ホストを再度有効にする方法を説明します。
ホストを無効にすると、アクティブなキータブが強制的に削除され、設定エントリーを変更せずにホストが IdM ドメインから削除されます。
ホストを再度有効にするには、以下を追加して、ipa-getkeytab コマンドを使用します。
  • キータブを要求する IdM サーバーを指定する -s オプション
  • プリンシパル名を指定する -p オプション
  • キータブを保存するファイルを指定する -k オプション
たとえば、client.example.comserver.example.com から新規ホストキータブを要求し、キータブを /etc/krb5.keytab ファイルに保存するには、次のコマンドを実行します。
$ ipa-getkeytab -s server.example.com -p host/client.example.com -k /etc/krb5.keytab -D "cn=directory manager" -w password
注記
管理者の認証情報を使用して、-D "uid=admin,cn=users,cn=accounts,dc=example,dc=com" を指定することもできます。認証情報は、ホストのキータブの作成を許可されたユーザーに対応することが重要です。
ipa-getkeytab コマンドをアクティブな IdM クライアントまたはサーバーで実行する場合は、ユーザーが、kinit admin などを使用して TGT を取得した場合に、LDAP 認証情報 (-D および -w) を使用せずに実行できます。無効化されたホストでコマンドを直接実行するには、LDAP 認証情報を提供して IdM サーバーに認証します。

12.5. ホストの公開 SSH 鍵の管理

OpenSSH は、公開鍵を使用してホストに対して認証を行います。あるマシンが別のマシンにアクセスを試みてキーのペアを提示します。ホストの初回認証時には、ターゲットマシンの管理者は、この要求を手動で認証する必要があります。次に、マシンはホストの公開鍵を known_hosts ファイルに保存します。リモートのマシンがターゲットマシンにアクセスを再度試みると、ターゲットマシンは known_hosts ファイルをチェックして、認証済みホストに自動的にアクセスを許可します。
このシステムには、以下のような問題があります。
  • known_hosts ファイルは、ホストエントリーをホスト IP アドレス、ホスト名、およびキーの 3 項目で保存します。IP アドレスが変更されたり (仮想環境やデータセンターでは一般的)、キーが更新されたりすると、このファイルはすぐに無効になってしまいます。
  • SSH 鍵は、環境内の全マシンに手動かつ個別に配布する必要があります。
  • 管理者は設定に追加するホストキーを許可する必要がありますが、ホストまたはキー発行者を適切に検証することが困難なことから、セキュリティー問題が発生する可能性があります。
Red Hat Enterprise Linux では、System Security Services Daemon (SSSD) がホストの SSH 鍵をキャッシュして取得するように設定し、アプリケーションやサービスがホストキーを 1 カ所で検索できるようにします。SSSD は Identity Management を ID 情報プロバイダーとして使用できるので、Identity Management をキーの汎用かつ集中化リポジトリーとすることができます。このため管理者は、ホスト SSH 鍵の配布や更新、検証を心配する必要がありません。

12.5.1. SSH 鍵の形式

キーを IdM エントリーにアップロードする場合には、キーの形式は OpenSSH-style key か生の RFC 4253-style blob にすることができます。RFC 4253-style key は、IdM LDAP サーバーにインポートして保存される前に、自動的に OpenSSH-style key に変換されます。
IdM サーバーは、アップロードされたキーブロブから、RSA または DSA キーといったキーのタイプを識別できます。ただし、~/.ssh/known_hosts などのキーファイルでは、サーバーのホスト名および IP アドレス、キーのタイプ、キー自体で、キーのエントリーが識別されます。以下に例を示します。
host.example.com,1.2.3.4 ssh-rsa AAA...ZZZ==
これは、要素の順序が type key== comment のユーザーの公開鍵エントリーとは多少異なります。
"ssh-rsa ABCD1234...== ipaclient.example.com"
キーファイルからの 3 要素はすべて、ホストエントリーにアップロードして表示できます。このような場合には、~/.ssh/known_hosts ファイルからのホスト公開鍵エントリーが、ユーザーキーの形式 type key== comment に一致するように順序を変える必要があります。
ssh-rsa AAA...ZZZ== host.example.com,1.2.3.4
キータイプは公開鍵のコンテンツから自動的に判断されます。個別キーの識別を容易にするコメントはオプションになります。必須要素は、公開鍵ブロブ自体のみとなります。

12.5.2. ipa-client-install および OpenSSH

デフォルトでは、ipa-client-install スクリプトは、IdM クライアントマシンで OpenSSH サーバーおよびクライアントを設定します。また SSSD がホストおよびユーザーキーのキャッシングを実行するように設定します。実質的には、クライアントを設定するだけで、ホストが SSSD、OpenSSH、および Identity Management を使用してキーキャッシングおよび取得に必要な全設定が実行されます。
クライアントインストール時に SSH サービスが有効な場合 (デフォルト)、ssh サービスの初回起動時に RSA キーが作成されます。
注記
ipa-client-install を使用して IdM クライアントとしてマシンを追加すると、クライアントには RSA と DSS の 2 つの SSH 鍵を作成されます。
他にも --ssh-trust-dns というクライアント設定オプションがあり、ipa-client-install コマンドに指定して実行でき、キーのフィンガープリントを格納する IdM DNS レコードを OpenSSH が信頼するように自動設定します。
別の方法として、クライアントのインストール時に --no-sshd オプションを使用して OpenSSH を無効にできます。この設定により、インストールスクリプトで OpenSSH サーバーを設定できなくなります。
別の --no-dns-sshfp というオプションを使用すると、ホストが独自の DNS エントリーで DNS SSHFP レコードを作成できなくなります。このオプションは、--no-sshd オプションと合わせて使用することも、なしでも使用できます。

12.5.3. ホスト SSH 鍵の Web UI でのアップロード

  1. ホストのキーは、~/.ssh/known_hosts から取得できます。以下に例を示します。
    server.example.com,1.2.3.4 ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEApvjBvSFSkTU0WQW4eOweeo0DZZ08F9Ud21xlLy6FOhzwpXFGIyxvXZ52+siHBHbbqGL5+14N7UvElruyslIHx9LYUR/pPKSMXCGyboLy5aTNl5OQ5EHwrhVnFDIKXkvp45945R7SKYCUtRumm0Iw6wq0XD4o+ILeVbV3wmcB1bXs36ZvC/M6riefn9PcJmh6vNCvIsbMY6S+FhkWUTTiOXJjUDYRLlwM273FfWhzHK+SSQXeBp/zIn1gFvJhSZMRi9HZpDoqxLbBB9QIdIw6U4MIjNmKsSI/ASpkFm2GuQ7ZK9KuMItY2AoCuIRmRAdF8iYNHBTXNfFurGogXwRDjQ==
    必要に応じて、ホストキーを生成します。OpenSSH ツールを使用する場合は、空白のパスフレーズを使用し、キーをユーザーの ~/.ssh/ ディレクトリー以外の場所に保存して、既存のキーを上書きしないようにします。
    [jsmith@server ~]$ ssh-keygen -t rsa -C "server.example.com,1.2.3.4"
    Generating public/private rsa key pair.
    Enter file in which to save the key (/home/jsmith/.ssh/id_rsa): /home/jsmith/.ssh/host_keys
    Enter passphrase (empty for no passphrase):
    Enter same passphrase again:
    Your identification has been saved in /home/jsmith/.ssh/host_keys.
    Your public key has been saved in /home/jsmith/.ssh/host_keys.pub.
    The key fingerprint is:
    SHA256:GAUIDVVEgly7rs1lTWP6oguHz8BKvyZkpqCqVSsmi7c server.example.com
    The key's randomart image is:
    +--[ RSA 2048]----+
    |              .. |
    |               .+|
    |          o   .* |
    |         o . .. *|
    |        S + .  o+|
    |         E . .. .|
    |        . = .  o |
    |         o .  ..o|
    |            .....|
    +-----------------+
  2. 公開鍵をキーファイルからコピーします。完全なキーエントリーは、hostname,IP type key== の形式です。key== は必須ですが、エントリー全体を保存できます。エントリーの全要素を使用するには、エントリーを再編成して、順番が type key== [host name,IP] になるように設定します。
    [jsmith@server ~]$ cat /home/jsmith/.ssh/host_keys.pub
    
    ssh-rsa AAAAB3NzaC1yc2E...tJG1PK2Mq++wQ== server.example.com,1.2.3.4
  3. Identity タブを開き、サブタブの ホスト を選択します。
  4. 編集するホスト名をクリックします。

    図12.4 ホストの