Red Hat Training

A Red Hat training course is available for Red Hat Enterprise Linux

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

Red Hat Enterprise Linux 7

Linux 環境で Red Hat Identity Management の使用

概要

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

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

システムレベルの認証ガイドでは 、authconfig』ユーティリティー、System Security Services Daemon(SSSD)サービス、プラグ可能な認証モジュール(PAM) フレームワーク、Kerberos、certmongerユーティリティー、およびアプリケーションのシングルサインオン(SSO)を含む、ローカルシステムでの認証の設定に使用できるさまざまなアプリケーションとサービスについて説明しています。

Windows 統合ガイド

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


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

第1章 Red Hat Identity Management の概要

本章では、Red Hat Identity Management の目的を説明します。また、ドメインに含まれるクライアントおよびサーバーマシンを含む、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 統合ガイド』の「 Samba、Kerberos、および Winbind の使用 」を参照してください』。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 を管理するように最適化されています。これにより、一般的な拡張性は制限されますが、よりシンプルな設定、リソース管理の自動化の改善、アイデンティティー管理の効率の向上などの利点があります。

関連情報

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 サービスにアクセスできます。
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 サーバー間の通信を管理します。
ワンタイムパスワード(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 uce は、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 サーバーが利用できなくなったり、クライアントがオフラインになったりした場合に、ローカルシステムが通常の認証操作を継続できるようになります。
SSSD の詳細は、System-Level Authentication Guide を参照してください。SSSD は、Windows Active Directory(AD)にも対応しています。AD で SSSD を使用する方法は、『 Windows 統合ガイド』を参照してください
certmonger
certmonger サービスは、クライアント上の証明書を監視、更新します。このサービスは、システム上のサービスに対して新しい証明書を要求できます。

図1.2 IdM サービス間の対話

IdM サービス間の対話

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

第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(仮想)CPU コア
  • 2 GB RAM
    少ない 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 プロトコルのみを使用する場合は、SSSD(System Security Services Daemon)が 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(Federal Information Processing Standard)モードを有効にして、システムに新しい 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 レルムはインストール後に変更できないことに注意してください。
シングルラベルのドメイン名は使用しないでください 。たとえば、IdM ドメインは、1 つ以上のサブドメインと、トップレベルドメイン(例: example.com または company.example.com )で構成される必要があります。
サーバーホストは、DNS サーバーが IdM 内に統合されているか、または外部でホストされるかに関係なく、DNS を適切に設定する必要があります。
Identity Management では、サービスレコードに別々の DNS ドメインを使用する必要があります。DNS レベルの競合を回避するため、プライマリー IdM DNS ドメインでは、 IdM Kerberos 名の小文字バージョンである DNS ドメインは、他の 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 アドレスを解決する必要があります。
マシンのホスト名を確認するには、hostname ユーティリティーを使用します。
[root@server ~]# hostname
server.example.com
hostname の出力は、localhost または localhost 6 であってはいけません

前方 DNS 設定および逆引き DNS 設定の確認

  1. サーバーの IP アドレスを取得します。ip addr show コマンドは、IPv4 アドレスと IPv6 アドレスの両方を表示します。
    • IPv4 アドレスは、inet で始まる行に表示されます。以下の例では、設定した IPv4 アドレスは 192.0.2.1 です。
    • IPv6 アドレスは、inet6 で始まる行に表示されます。グローバルスコープ を持つ 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 を使用して、IPv6 アドレスのクエリーと、前の手順で dig +short -x server.example.com AAAA コマンドにより 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 の 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 フォワーダーが EDNS0( Extension Mechanisms for DNS )および DNSSEC 標準に準拠していることを確認します。
$ dig +dnssec @IP_address_of_the_DNS_forwarder . SOA
コマンドの出力には、以下の情報が含まれます。
  • 状態: NOERROR
  • flags: 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 を使用してシステムでポートを開く方法は、『 セキュリティーガイド』 または man ページの firewall-cmd(1) を参照してください。
  3. firewall-cmd 設定を再読み込みし、変更が即座に反映されるようにします。
    # firewall-cmd --reload
    実稼働でのシステムで firewalld をリロードすると、DNS 接続がタイムアウトになる可能性があることに注意してください。『セキュリティーガイド』の「コマンドラインインターフェースを使用したファイアウォールのリロード』 も参照してください。必要な場合は、以下の例のように 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. オプション:ポートが使用できることを確認するには、nc ユーティリティー、telnet ユーティリティー、または nmap ユーティリティーを使用して、ポートに接続するか、ポートスキャンを実行します。
注記
さらに、着信および送信トラフィックの両方でネットワークベースのファイアウォールを開く必要があることに注意してください。

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

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

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

注記
以下のセクションのインストール手順と例は相互排他的ではありません。それらを組み合わせて、必要な結果を得ることができます。たとえば、統合 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)を備えたサーバーインストール、または CA を使用せずにサーバーのインストールに対応します。
統合 IdM CA を備えたサーバー
これは、ほとんどのデプロイメントに適したデフォルト設定です。証明書システムは、CA 署名 証明書を使用して、IdM ドメインで証明書を作成して署名します。
警告
Red Hat は、複数のサーバーに CA サービスをインストールすることを強く推奨します。CA サービスを含む初期サーバーのレプリカのインストールは、「CA のあるレプリカのインストール」 を参照してください。
CA を 1 台のサーバーにのみインストールする場合は、CA サーバーが失敗した場合に CA 設定を復元せずに CA 設定が失われるリスクがあります。詳しくは、「Lost 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、および admin IdM システムユーザーアカウントのパスワードを入力します。
    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 の説明を参照してください。
      • 詳細は、「Forward Policies」 も参照してください。
    • 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、および admin IdM システムユーザーアカウントのパスワードを入力します。
    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 を root CA としてチェーンするには、ipa-server-install ユーティリティーを使用してこのオプションを渡します。
  • --external-ca は、外部 CA を使用するように指定します。
  • --external-ca-type は、外部 CA のタイプを指定します。詳細は ipa-server-install(1) の man ページを参照してください。
それ以外の場合は、ほとんどのインストール手順は 「統合 DNS を使用したサーバーのインストール」 または 「統合 DNS を使用しないサーバーのインストール」 と同じです。
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 パラメーター を設定する必要があります。詳細は、RFC 5280の基本的な制約』 のセクションを参照してください。
  2. 発行した証明書と、Base64 エンコードされたブロブ (PEM ファイルか Windows CA からの Base_64 証明書) で CA を発行する CA 証明書チェーンを取得します。繰り返しになりますが、プロセスは各証明書サービスによって異なります。通常は Web ページか通知メールにダウンロードリンクがあり、管理者が必要なすべての証明書をダウンロードできるようになっています。
    重要
    CA 証明書のみではなく、CA 用の完全な証明書チェーンを取得してください。
  3. ipa-server-install を再度実行します。今回は、新たに発行した CA 証明書と CA チェーンファイルの場所と名前を指定します。たとえば、以下のようになります。
    # 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 (ドメイン名)
警告
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)サーバー、または DNSSEC(DNS Security Extensions)サーバーとして機能するサーバーをアンインストールする前に、これらのサービスがドメインの別のサーバーで実行していることを確認してください。
    警告
    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. FIPS 環境にクライアントをインストールするための前提条件

Red Hat Enterprise Linux 7.4 以降を使用して環境を設定する環境では、以下を行います。
  • FIPS(Federal Information Processing Standard)モードを有効にして、システムに新しいクライアントを設定できます。インストールスクリプトは、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 アドレスを解決する必要があります。
  3. スクリプトにより、アイデンティティーがクライアントの登録に使用されるユーザーの入力が求められます。デフォルトでは、これは admin ユーザーになります。
    User authorized to enroll computers: admin
    Password for admin@EXAMPLE.COM
  4. インストールスクリプトにより、クライアントが設定されます。動作が完了するまで待ちます。
    Client configuration complete.
  5. IdM に NFS を自動的に設定する ipa-client-automount ユーティリティーを実行します。詳しくは、「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 アドレスを解決する必要があります。
  • --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. IdM に NFS を自動的に設定する ipa-client-automount ユーティリティーを実行します。詳しくは、「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 環境で、get cert ユーティリティーと 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 鍵を生成しますが、上記のスクリプトの使用が推奨されます。
キックスタートの使用方法は、『 インストールガイド』の「キックスタートインストールの実行」を参照してください』。キックスタートファイルの例は、「 キックスタート設定のサンプル 」を参照してください。

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 サーバーの設定をクローンして作成されます。そのため、サーバーとそのレプリカは同一のコア設定を共有します。レプリカのインストールプロセスでは、既存のサーバー設定をコピーし、その設定に基づいてレプリカをインストールします。
注記
もう 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. Replicas のデプロイメントに関する考慮事項

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

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

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

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

CA Services on Replicas

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

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

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

    図4.3 レプリカ B および C は、レプリカ合意には参加しません。

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

    図4.4 レプリカ B および C はそれぞれ、レプリカ合意に参加しました。

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

図4.5 トポロジーの例

トポロジーの例

4.2.2.1. tight Cell Topology

最も回復性の高いトポロジーの 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 コマンドに渡します。レプリカのインストールに関する詳細は、「レプリカの作成: Introduction」 を参照してください。
または、既存のレプリカの状態を変更することもできます。詳細は 「Demotion and Promotion of Hidden Replicas」 を参照してください。

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. レプリカの作成: Introduction

ipa-replica-install ユーティリティーは、既存の IdM サーバーから新しいレプリカをインストールするために使用されます。Identity Management レプリカは一度に 1 つずつインストールしてください。同時に複数のレプリカをインストールすることはサポートされません。
注記
本章では、Red Hat Enterprise Linux 7.3 で導入された簡素化されたレプリカのインストールについて説明します。この手順を実行するには、ドメインレベル 1 が必要です( 7章ドメインレベルの表示と引き上げを参照)。
ドメインレベル 0 でレプリカをインストールする方法は、付録D ドメインレベル 0 でのレプリカの管理 を参照してください。
新しいレプリカをインストールできます。
このいずれの状況でも、ipa-replica-install にオプションを追加すると、レプリカをカスタマイズできます。「ipa-replica-install を使用したユースケースに対するレプリカの設定」 を参照してください。
レプリカを非表示としてインストールするには、--hidden-replica パラメーターを ipa-replica-install に渡します。非表示のレプリカの詳細は、「非表示のレプリカモード」 を参照してください。
重要
複製している IdM サーバーに Active Directory と信頼がある場合は、ipa-replica-install を実行した後にレプリカを信頼エージェントとして設定します。『 Windows 『統合ガイド』の「』 信頼コントローラーおよび信頼エージェント」を参照してください

既存のクライアントのレプリカへのプロモート

既存のクライアントにレプリカをインストールするには、クライアントのプロモートが許可されていることを確認する必要があります。これを行うには、以下のいずれかを選択します。
特権ユーザーの認証情報を指定します。
デフォルトの特権ユーザーは 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 設定が失われるリスクがあります。詳しくは、「Lost CA サーバーのリカバリー」 を参照してください。
最も注目すべきオプションを持つレプリカをインストールするシナリオの例は、以下を参照してください。
レプリカの設定に使用するオプションの完全リストは、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 統合ガイド』 の「信頼コントローラーと信頼エージェント 」を参照してください』。

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

この手順では、IdM クライアントではないマシンにレプリカをゼロからインストールします。登録を承認するには、クライアント登録に有効なクライアント固有の無作為なパスワードだけが使用されます。
この手順では、管理者または 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 統合ガイド』 の「信頼コントローラーと信頼エージェント 」を参照してください』。

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

この手順は、クライアントと、IdM ドメインに含まれていないマシンにレプリカをインストールするのに機能します。詳しくは、「レプリカの作成: Introduction」 を参照してください。
  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 統合ガイド』 の「信頼コントローラーと信頼エージェント 」を参照してください』。

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

この手順は、クライアントと、IdM ドメインに含まれていないマシンにレプリカをインストールするのに機能します。詳しくは、「レプリカの作成: Introduction」 を参照してください。
  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 統合ガイド』 の「信頼コントローラーと信頼エージェント 」を参照してください』。

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

この手順は、クライアントと、IdM ドメインに含まれていないマシンにレプリカをインストールするのに機能します。詳しくは、「レプリカの作成: Introduction」 を参照してください。
重要
自己署名のサードパーティーサーバー証明書を使用してサーバーまたはレプリカをインストールすることはできません。
  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 統合ガイド』 の「信頼コントローラーと信頼エージェント 」を参照してください』。

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

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

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

「IdM サーバーのアンインストール」 を参照してください。

パート 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 サービスを再起動する必要はありません。
重要
複数の IdM ドメインサービスを再起動するには、Red Hat は、常に 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 チケットの自動取得

pam_krb5 プラグ可能な認証モジュール(PAM)および SSSD は、IdM クライアントマシンのデスクトップ環境へのログインに成功した後に、ユーザーの TGT を自動的に取得するように設定できます。これにより、ログイン後に kinit の実行は必要ありません。
SSSD に IdM が ID および認証プロバイダーとして設定された IdM システムでは、ユーザーが対応する Kerberos プリンシパル名にログインした後に TGT を自動的に取得します。
pam_krb5 の設定に関する詳細は、pam_krb5(8) man ページを参照してください。PAM に関する一般的な情報は、『システムレベルの 認証ガイド』を参照してください

複数の Kerberos チケットの保存

デフォルトでは、Kerberos はログインユーザーごとに 1 つのチケットのみを認証情報キャッシュに保存します。ユーザーが kinit を実行すると、Kerberos は、現在-stored チケットを新しいチケットで上書きします。たとえば、kinit を使用して user_A として認証すると、user_ B として再度認証した後に、user_ A のチケットが失われます。
ユーザーに別の TGT を取得して保存するには、別の認証情報キャッシュを設定します。これにより、以前のキャッシュの内容が上書きされないようにします。これは、以下のいずれかの方法で実行できます。
  • export KRB5CCNAME=path_to_different_cache コマンドを実行してから、kinit を使用してチケットを取得します。
  • kinit -c path_to_different_cache コマンドを実行してから、K RB5CCNAME 変数をリセットします。
デフォルトの認証情報キャッシュに保存された元の TGT を復元するには、以下を行います。
  1. kdestroy コマンドを実行します。
  2. 未設定の $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 コマンドを使用します
$ 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 つの属性の追加を試みます。したがって、属性のリストを変更する場合は、更新された一覧全体を指定する必要があります。
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
    ---------------
      ...
  • 指定された属性に キーワード が含まれるユーザーグループの一覧を表示するには、次のコマンドを実行します。
    $ 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 Administration Guide』を参照してください

5.4. IdM Web UI

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

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 統合ガイド』 の「Active Directory 環境における ID ビューの使用 」を参照してください』。

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

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

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

Kerberos 認証エラーメッセージ
Kerberos 認証用のブラウザーは、以下の 3 つの方法で設定できます。
  • IdM Web UI から自動的に設定します。このオプションは Firefox でのみ利用できます。詳しくは、「Web UI での自動 Firefox 設定」 を参照してください。
  • IdM クライアントのインストール時に自動的にコマンドラインから行います。このオプションは Firefox でのみ利用できます。詳しくは、「コマンドラインからの自動 Firefox 設定」 を参照してください。
  • Firefox 設定を手動で行う。このオプションは、サポートされるすべてのブラウザーで利用できます。詳しくは、「手動のブラウザー設定」 を参照してください。
注記
『System-Level Authentication Guide』には、Firefox の Kerberos 認証に関するトラブルシューティングガイドが含まれています。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 つの異なるサーバーに結合します。
ドメインサフィックス: dc=example,dc=com
ドメイン サフィックスには、ドメイン関連の全データが含まれます。
ドメインサフィックス 間で 2 つのレプリカにレプリカ合意がある場合、ユーザー、グループ、ポリシーなどのディレクトリーデータを共有します。
ca サフィックス: o=ipaca
ca 接尾辞には、Certificate System コンポーネントのデータが含まれます。これは認証局 (CA) がインストールされているサーバーにのみ存在します。
ca サフィックス間で 2 つのレプリカにレプリカ合意がある場合、証明書データを共有します。

図6.1 トポロジーの固定

トポロジーの固定
最初のトポロジーセグメントは、新しいレプリカをインストールするときに ipa-replica-install スクリプトで 2 つのサーバー間で設定されます。

例6.1 Topology Suffixes の表示

ipa topologysuffix-find コマンドは、トポロジーサフィックスの一覧を表示します。
$ ipa topologysuffix-find
---------------------------
2 topology suffixes matched
---------------------------
  Suffix name: ca
  Managed LDAP suffix DN: o=ipaca

  Suffix name: domain
  Managed LDAP suffix DN: dc=example,dc=com
----------------------------
Number of entries returned 2
----------------------------

トポロジーのセグメント

2 つのレプリカのサフィックス間でレプリカ合意がある場合、サフィックスは トポロジーセグメントを形成します。各トポロジーセグメントは、左側のノードと 適切なノード で構成されます。ノードは、レプリカ合意に参加しているサーバーを表します。
IdM のトポロジーセグメントは常に双方向です。各セグメントは、サーバー A からサーバー B、およびサーバー B からサーバー A の 2 つのレプリカ合意を表します。そのため、データは両方の方向でレプリケートされます。

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

トポロジーのセグメント

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

ipa topologysegment-find コマンドは、ドメインまたは CA サフィックスに設定された現在のトポロジーセグメントを表示します。たとえば、ドメインサフィックスの場合は以下のようになります。
$ ipa topologysegment-find
Suffix name: domain
-----------------
1 segment matched
-----------------
  Segment name: server1.example.com-to-server2.example.com
  Left node: server1.example.com
  Right node: server2.example.com
  Connectivity: both
----------------------------
Number of entries returned 1
----------------------------
この例では、ドメイン関連のデータは server1.example.com と server1.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: Topology Graph を使用したレプリケーショントポロジーの管理

Topology グラフへのアクセス

Web UI のトポロジーグラフは、ドメインのサーバー間の関係を表示します。
  1. IPA ServerTopologyGraph を選択します。
  2. グラフに即座に反映されないトポロジーに変更を加える場合は、Refresh をクリックします。

Topology ビューのカスタマイズ

マウスをドラッグすると、個別のトポロジーノードを移動できます。

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

トポロジーグラフノードの移動
wheel を使用して、トポロジーグラフを拡大してズームアウトできます。

図6.4 トポロジーグラフの拡大

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

図6.5 Topology Graph Canvas の移動

Topology Graph Canvas の移動

Topology グラフの解釈

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

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

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

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

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

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

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

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

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

    図6.9 新しいセグメントの作成

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

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

新規セグメントの作成

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

  1. 削除するレプリカ合意を表す矢印をクリックします。矢印を強調表示します。

    図6.11 トポロジーセグメントのハイライト

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

図6.12 トポロジーセグメントの削除

トポロジーセグメントの削除

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

6.3.1. Topology Management コマンドのヘルプの取得

レプリケーショントポロジーの管理に使用するコマンドをすべて表示するには、次のコマンドを実行します。
$ 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. ipa topologysegment-del コマンドを使用して、2 つのサーバーに参加するトポロジーセグメントを削除します。
    $ ipa topologysegment-del
    Suffix name: domain
    Segment name: new_segment
    -----------------------------
    Deleted segment "new_segment"
    -----------------------------
    セグメントを削除すると、レプリカ合意が削除されます。
  3. 任意。ipa topologysegment-find コマンドを使用して、セグメントが一覧表示されていないことを確認します。
    $ ipa topologysegment-find
    Suffix name: domain
    ------------------
    7 segments matched
    ------------------
      Segment name: server2.example.com-to-server3.example.com
      Left node: server2.example.com
      Right node: server3.example.com
      Connectivity: both
    
    ...
    
    ----------------------------
    Number of entries returned 7
    ----------------------------

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. Command Line: Topology からのサーバーの削除

重要
サーバーの削除は元に戻せません。サーバーを削除する場合は、これをトポロジーに導入する唯一の方法は、マシンに新しいレプリカをインストールすることです。
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 ServerTopologyServerRoles 」を参照してください。
  • role status absent は、トポロジーのサーバーがロールを実行しないことを意味します。
  • ロール のステータスは、トポロジー内の 1 つ以上のサーバーがロールを実行していることを意味します。

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

Web UI のサーバーロール

コマンドライン: サーバーロールの表示

ipa config-show コマンドは、すべての CA サーバー、NTP サーバー、および現在の CA Renewal Master を表示します。
$ 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 Renewal Master として実行します。
  1. CA サブシステム証明書の更新を処理するようにレプリカを設定します。
  2. CRL を生成するようにレプリカを設定します。「CRL を生成するサーバーの変更」 を参照してください。
  3. 以前のマスター CA サーバーの使用を停止する前に、新規マスターが適切に機能していることを確認します。「新規マスター CA サーバーが正常に設定されていることの確認」 を参照してください。

6.5.2.1. 現在の CA Renewal Master の変更

Web UI: 現在の CA Renewal Master の変更

  1. IPA ServerConfiguration を選択します。
  2. IPA CA Renewal Master フィールドで、新しい CA Renewal Master を選択します。

コマンドライン: 現在の CA Renewal Master の変更

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. Demotion and Promotion of Hidden Replicas

レプリカのインストール後、レプリカの表示状態を変更できます。
  • 非表示のレプリカに表示可能なレプリカを降格するには、以下を実行します。
    1. レプリカが CA Renewal Master である場合は、サービスを別のレプリカに移動します。詳細は 「現在の CA Renewal Master の変更」 を参照してください。
    2. レプリカの状態 を非表示に 変更します。
      # 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
利用可能な機能の例:
  • ipa-replica-install では、初期サーバーでレプリカ情報ファイルを作成し、レプリカにコピーすることがより複雑なプロセスが必要です( 「レプリカの作成」を参照)。
  • ipa- replica-manage および ipa- csreplica-manage を使用したより複雑なトポロジー管理( 「レプリカとレプリカ合意の管理」を参照)

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

コマンドライン: 現在のドメインレベルの表示

  1. 管理者としてログインします。
    $ kinit admin
  2. ipa domainlevel-get コマンドを実行します。
    $ ipa domainlevel-get
    -----------------------
    Current domain level: 0
    -----------------------

Web UI: 現在のドメインレベルの表示

IPA ServerDomain 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 ServerDomain Level を選択します。
  2. ドメインレベルの設定 をクリックします

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

8.1. Identity Management の更新

yum ユーティリティーを使用して、システムの Identity Management パッケージを更新できます。
さらに、7.3 などの新しい Red Hat Enterprise Linux バージョンが利用可能になると、yum は Identity Management サーバーまたはクライアントをこのバージョンにアップグレードします。
注記
このセクションでは、Red Hat Enterprise Linux 6 から Red Hat Enterprise Linux 7 への Identity Management の移行について説明します。移行する場合は、「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 のため、Secure Socket Layer バージョン 3(SSLv3)プロトコルは mod_nss モジュールで無効にする必要があります。次の手順に従い、無効になっていることを確認してください。
  1. /etc/httpd/conf.d/nss.conf ファイルを編集し、NSSProtocol パラメーターを TLSv1.0 (後方互換性用)、TLS v1.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 システムです。
  • 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 アドバイザリーが適用されており、bind-dyndb-ldap パッケージの 2.3-6.el6_6 バージョンを提供し、Red Hat Enterprise Linux 6.6 Extended Update Support(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 スキーマ更新スクリプトは、rhel 7. 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 システムで、rhel 7.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 6 でセットアップすると、CRITICAL が CA インスタンスエラーの設定 に失敗します。
  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 を生成するサーバーの変更」 で説明されているように、rhel 7.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 ユーティリティーを使用すると、リモートプロシージャコール(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 サーバーのアンインストール」 を参照してください。
重要
クライアント設定は自動的に更新されません。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 つのなど、ハードウェアまたはアップグレードで障害が発生した場合(上記の 2 つなど)は、すべてのレプリカまたは、認証局(CA)のみの特別なロールを持つレプリカが失われた場合のみ、バックアップから復元します。同じデータを持つレプリカが存在する場合は、失われたレプリカを削除して、残りのレプリカから再ビルドすることが推奨されます。
  • LDAP コンテンツに望ましくない変更(エントリーなど)が削除され、元に戻します。バックアップを作成してある LDAP データを復元すると、IdM システム自体に影響を与えずに LDAP エントリーを以前の状態に戻します。
復元されたサーバーは、IdM の唯一の情報ソースになります。他のマスターサーバーは復元されたサーバーから再初期化されます。最後のバックアップ後に作成されたデータはすべて失われます。そのため、通常のシステムメンテナンスにはバックアップおよび復元ソリューションを使用しないでください。可能であれば、レプリカとして再インストールして、失われたサーバーを再構築します。
バックアップおよび復元機能はコマンドラインからのみ管理でき、IdM Web UI では使用できません。

9.1. 完全なサーバーバックアップおよびデータ専用バックアップ

IdM には、以下の 2 つのバックアップオプションがあります。
IdM サーバーの完全バックアップ
サーバーのフルバックアップは、スタンドアロンバックアップを行うすべての IdM サーバーファイルと LDAP データのバックアップコピーを作成します。IdM は、数百のファイルに影響します。バックアッププロセスのコピーは、設定ファイルやログファイルなど、ディレクトリー全体と特定のファイルを混在させ、IdM または別のさまざまなサービスに関連するものです。完全なサーバーバックアップは raw ファイルバックアップであるため、オフラインで実行されます。完全なサーバーバックアップを実行するスクリプトは、すべての IdM サービスを停止し、バックアッププロセスが安全になるようにします。
完全なサーバーバックアップコピーの全一覧については、「バックアップ中のディレクトリーおよびファイルの一覧」 を参照してください。
データのみのバックアップ
データのみのバックアップは、LDAP データと changelog のバックアップコピーのみを作成します。このプロセスは IPA-REALM インスタンスをバックアップし、複数のバックエンドのバックアップを作成することも、単一のバックエンドのみをバックアップします。バックエンドには IPA バックエンドと CA Dogtag バックエンドが含まれます。このタイプのバックアップは、LDIF(LDAP Data Interchange Format)に保存されている LDAP コンテンツのレコードもバックアップします。データのみのバックアップは、オンラインとオフラインの両方で実行できます。
デフォルトでは、IdM は作成したバックアップを /var/lib/ipa/backup/ ディレクトリーに保存します。バックアップを含むサブディレクトリーの命名規則は以下のとおりです。
  • サーバーのフルバックアップの ipa-full-YEAR-MM-DD-HH-MM-SS
  • ipa-data-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. バックアップの暗号化

GNU Privacy Guard(GPG)暗号化を使用して 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
files:
/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 インスタンスに保存されている IdM ユーザー(Directory Server インスタンスにも格納されている)に基づいています。
アクセス制御指示 (ACI) には、以下の 3 つの部分があります。
Actor
これは、何かを実行するパーミッションを付与されるエンティティーです。LDAP アクセス制御モデルでは、これはユーザーが誰かを定義し、特定の時間や特定のマシンへの試行を制限するなど、バインド試行の他の制限をオプションで必要になるため、バインド ルール と呼ばれます。
ターゲット
これは、Actor が許可されている操作を実行する対象のエントリーを定義します。
操作タイプ
操作タイプ: 最後の部分は、ユーザーが実行できるアクションの種類を判断します。最も一般的な操作は、追加、削除、書き込み、読み取り、および検索です。Identity Management では、すべてのユーザーが暗黙的に IdM ドメイン内のすべてのエントリーに対する読み取りおよび検索権限が付与されており、パスワードや Kerberos キーなどの機密属性のみに制限されています。匿名ユーザーは、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. ユーザーグループ のドロップダウンメニューで、ユーザーグループ のユーザーエントリーにパーミッションを付与されるグループを選択します

    図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 つ以上の権限で構成されます。
  • パーミッションは、特定の操作または操作セット(読み取り、書き込み、追加、または削除など)と、操作が適用される IdM LDAP ディレクトリー内のターゲットエントリーを定義します。パーミッションはビルディングブロックで、必要に応じて複数の特権に割り当てることができます。
    IdM 権限を使用すると、どのユーザーがどのオブジェクトにアクセスできるか、さらにはこれらのオブジェクトの属性にアクセスできるかどうかを制御できます。IdM を使用すると、個別の属性をホワイトリストまたはブラックリストに登録したり、ユーザー、グループ、sudo などの特定の IdM 機能全体を、すべての匿名ユーザー、全認証ユーザー、または特定の特権ユーザーのグループへの表示を変更したりできます。パーミッションに柔軟性のあるこのアプローチは、たとえば、管理者に対してユーザーまたはグループのアクセスを制限したい特定のセクションに対してのみアクセスし、その他のセクションをそれらに完全に非表示にしたい場合などに便利です。
  • 特権 は、ロールに適用できるパーミッションのグループです。例えば、パーミッションは自動マウントの場所の追加、編集、削除を行うために作成できます。そして、そのパーミッションは FTP サーバーの管理に関連する別のパーミッションと組み合わせることができます。これらは、ファイルシステムの管理に関連する単一の特権を作成するために作成できます。
    注記
    Red Hat Identity Management のコンテキストでは、パーミッションとロールが作成されるアクセス制御のアトミックユニットという特定の意味があります。通常ユーザーのコンセプトとして、権限の昇格 は一時的に、Red Hat Identity Management に存在しません。特権は、RBAC(Role-Based Access Control)を使用してユーザーに割り当てられます。アクセス権を付与するロールを持っているか、またはそのロールが存在しない。
    ユーザーとは別に、権限はユーザーグループ、ホスト、ホストグループ、およびネットワークサービスにも割り当てられます。これにより、特定のネットワークサービスを介してホストセットのユーザーセットにより、操作をより細かく制御できます。
  • ロールは、ロール に指定したユーザーが所有する特権の一覧です。
    重要
    ロールは、許可されたアクションを分類するために使用されます。ロールは、特権昇格されないようにしたり、特権の分離を実装するツールとしては使用しません。
完全に新しいパーミッションを作成したり、既存または新規のパーミッションをベースにして新たな権限を作成したりすることができます。Red Hat Identity Management は、以下の事前定義済みのロールを提供しています。

表10.1 Red Hat Identity Management で事前定義されたロール

ロール 特権 説明
ヘルプデスク
Modify Users、Reset passwords、Modify Group メンバーシップ 簡単なユーザー管理タスクの実行
IT セキュリティースペシャリスト
Netgroups 管理者、HBAC 管理者、Sudo 管理者 ホストベースのアクセス制御、sudo ルールなどのセキュリティーポリシーの管理
IT スペシャリスト
ホスト管理者、ホストグループ管理者、サービス管理者、自動マウント管理者 ホストの管理を行います。
セキュリティーアーキテクト
委譲管理者、レプリケーション管理者、書き込み IPA 設定、パスワードポリシー管理者 Identity Management 環境の管理、信頼の作成、レプリカ合意の作成
ユーザー管理者
ユーザー管理者、グループ管理者、ステージユーザー管理者 ユーザーおよびグループの作成を行います。

10.4.1. Roles

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. 必要なグループをロールに追加します。この場合、すでに存在する単一のグループ useradmins のみを追加します。
    [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 、ユーザー、ホスト、またはサービスなどのエントリータイプを指定します。Type 設定の値を選択すると、このエントリータイプの ACI でアクセス可能な可能な属性の一覧が Effective Attributes に表示されます。
      Type を定義すると、Subtree および Target DN が事前定義された値のいずれかに設定されます。
    • サブツリー はサブツリーエントリーを指定します。このサブツリーエントリーの下にあるすべてのエントリーが対象になります。Subtree ではワイルドカードや存在しないドメイン名(DN)が許可されないため、既存のサブツリーエントリーを指定します。たとえば、以下のようになります。
      cn=automount,dc=example,dc=com
    • Extra target filter は LDAP フィルターを使用して、パーミッションが適用されるエントリーを特定します。このフィルターには、有効な LDAP フィルターを使用できます。以下に例を示します。
      (!(objectclass=posixgroup))
      IdM は、指定のフィルターの有効性を自動的に確認します。無効なフィルターを入力すると、パーミッションを保存した後に IdM はこの問題について警告します。
    • ターゲット DN はドメイン名(DN)を指定し、ワイルドカードを受け入れます。たとえば、以下のようになります。
      uid=*,cn=users,cn=accounts,dc=com
    • Member of group は、指定したグループのメンバーにターゲットフィルターを設定します。
    フィルター設定を入力し、Add をクリックすると、IdM がフィルターを検証します。すべてのパーミッション設定が正しい場合は、IdM が検索を実行します。パーミッション設定の一部が正しくない場合、IdM は、どの設定が正しく設定されているかを示すメッセージが表示されます。
  5. Type を設定する場合は、利用可能な ACI 属性 の一覧から Effective attributes を選択します。Type を使用しない場合は、Effective attributes フィールドに属性を手動で書き込みます。一度に 1 つの属性を追加します。複数の属性を追加するには、Add をクリックして別の入力フィールドを追加します。
    重要
    パーミッションの属性を設定しない場合、デフォルトですべての属性が含まれます。

10.4.2.2. コマンドライン での新規パーミッションの作成

新しいパーミッションを追加するには、ipa permission-add コマンドを実行します。対応するオプションを指定して、パーミッションのプロパティーを指定します。
  • パーミッションの名前を指定します。たとえば、以下のようになります。
    [root@server ~]# ipa permission-add "dns admin permission"
  • --bindtype は、バインドルールの種別を指定します。このオプションは、all anonymous および permission 引数を受け入れます。たとえば、以下のようになります。
    --bindtype=all
    --bindtype を使用しない場合は、タイプは自動的に デフォルトのパーミッション 値に設定されます。
    注記
    デフォルト以外のバインドルールタイプを持つパーミッションを権限に追加することはできません。また、デフォルト以外のバインドルールタイプに対する特権にあるパーミッションを設定することはできません。
  • --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 で提供された属性のみが有効にされます。
注記
管理パーミッションを削除できませんが、パーミッションにバインド タイプを設定し、全特権から管理パーミッションを削除することを効果的に無効にできます。
管理パーミッションの名前はすべて System: から始まります。たとえば、System : Add Sudo rule または System: Modify Services
以前のバージョンの IdM では、デフォルトパーミッションに異なるスキームを使用していました。たとえば、ユーザーがデフォルトのパーミッションを変更できないようにし、ユーザーは特権にのみ割り当てることができます。これらのデフォルトパーミッションのほとんどは管理パーミッションに切り替わっていますが、以下のパーミッションは引き続き以前のスキームを使用します。
  • Automember Rebuild メンバーシップタスクの追加
  • レプリカ合意の追加
  • 証明書削除保留
  • CA から証明書のステータスを取得します。
  • DNA 範囲の変更
  • レプリカ合意の変更
  • レプリカ合意の削除
  • 要求証明書
  • 別のホストからの証明書の要求
  • CA からの証明書の取得
  • 証明書の取り消し
  • IPA 設定の書き込み
Web UI から管理パーミッションを変更しようとすると、変更できない属性が無効になります。

図10.15 無効化された属性

無効化された属性
コマンドラインから管理パーミッションを変更しようとすると、システムは変更できない属性を変更できません。たとえば、デフォルトのシステム の変更を試みると、グループに適用するユーザー パーミッションの変更に失敗します。
$ ipa permission-mod 'System: Modify Users' --type=group
ipa: ERROR: invalid 'ipapermlocation': not modifiable on managed permissions
ただし、System: 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 は、匿名ユーザー(認証されていないユーザー)であっても、サーバーのすべてのユーザーに読み取りアクセスが付与されます。
  • パーミッションタイプの作成、追加、および削除のみが利用できました。read パーミッションも利用可能ですが、認証されていないものなど、すべてのユーザーが、デフォルトで読み取りアクセスがあったため、実用値はほとんどありません。
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. 管理: アイデンティティーの管理

第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 を使用すると、root で NFS ユーザーへの root アクセスの付与、/home/ ディレクトリーツリー全体の読み込み時のパフォーマンス問題、ホームディレクトリーにリモートサーバーを使用するためのネットワークパフォーマンスの問題が発生する場合があります。
これらの問題の影響を軽減するには、以下のガイドラインに従うことを推奨します。
  • automount を使用して、ユーザーのホームディレクトリーのみをマウントし、ユーザーがログインする場合に限りマウントします。/home/ ツリー全体を読み込む時に使用しないでください。
  • 制限されたパーミッションを持つリモートユーザーを使用してホームディレクトリーを作成し、このユーザーとして IdM サーバーに共有をマウントします。IdM サーバーは httpd プロセスとして実行するため、sudo または同様の プログラムを使用して IdM サーバーへの限定的なアクセスを付与して、NFS サーバーにホームディレクトリーを作成できます。

NFS および 自動マウントを使用したホームディレクトリーの設定

NFS 共有および 自動マウント を使用して、別の場所からホームディレクトリーを手動で追加するには、次のコマンドを実行します。
  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章自動マウントの使用 を参照してください。

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

Identity Management は、stageactive、および preserved の 3 つのユーザーアカウントの状態に対応します。
  • ステージ ユーザーは認証できません。これは初期状態です。アクティブユーザーに必要なユーザーアカウントプロパティーの一部がまだ設定されていない可能性があります。
  • アクティブ ユーザーは認証が可能です。必要なユーザーアカウントプロパティーはすべて、この状態で設定する必要があります。
  • 保存済みユーザー は、以前の アクティブな ユーザーです。IdM への認証は非アクティブであるとみなされており、IdM への認証ができません。保存済みユーザーには、アクティブユーザーのときに有効になっていたアカウントプロパティーの大部分が保持されていますが、ユーザーグループからは除外されています。
    注記
    保存済みユーザー の一覧は、以前のユーザーアカウントの履歴を提供します。
ユーザーエントリーは、IdM データベースから永続的に削除できます。ユーザーエントリーを削除すると、エントリー自体と、グループメンバーシップやパスワードなど、IdM からその情報がすべて削除されます。ユーザーの外部設定 (システムアカウントやホームディレクトリーなど) は削除されませんが、IdM からはアクセスできなくなります。
重要
削除したユーザーアカウントを復元することはできません。ユーザーアカウントを削除すると、そのアカウントに関連するすべての情報は永続的に失われます。
新規管理者ユーザーは、デフォルトの管理ユーザーなど、別の管理者のみが作成できます すべての管理者アカウントを誤って削除した場合には、Directory Manager は、Directory Server に新しい管理者を手動で作成する必要があります。
警告
admin ユーザーを削除しないでください。admin は IdM で必要な事前定義ユーザーであるため、この操作では特定のコマンドで問題が生じます。別の admin ユーザーを定義して使用する場合は、管理者権限を少なくとも 1 つ付与した後に、ipa user-disable admin で事前定義された admin ユーザーを無効にします。

ユーザーライフサイクル管理操作

ユーザーのプロビジョニングを管理するには、管理者はユーザーアカウントをある状態から別の状態に移動できます。新しいユーザーアカウントは、アクティブ または ステージとして追加できますが保存済み ではありません。
IdM は、ユーザーライフサイクル管理の以下の操作をサポートします。
stage → active
ステージ 状態のアカウントを適切にアクティブにできる状態になったら、管理者はこれを active 状態に移動します。
Active → preserved
ユーザーが会社を離れると、管理者はアカウントを preserved の状態にします。
保存済み → アクティブ
以前のユーザーがもう一度会社に参加させます。管理者は、これを preserved 状態から アクティブ 状態に戻すことで、ユーザーアカウントを復元します。
保存済み → ステージ
以前のユーザーは、もう一度会社に参加させる計画があります。管理者は、アカウントを preserved 状態から stage の状態に移行し、後で再アクティブ化するアカウントを準備します。
IdM からアクティブなユーザー、ステージ、および保存済みユーザーを完全に削除することもできます。ステージユーザーを preserved 状態に移行することができないため、完全に削除できる点にご留意ください。

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

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

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

Web UI でユーザーの追加

  1. IdentityUsers タブを選択します。
  2. active または stage の状態のユーザーを追加するかどうかに応じて、アクティブユーザー またはステージユーザー カテゴリーを選択します。

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

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

    図11.3 ユーザーの追加

    ユーザーの追加
  4. Add User フォームを入力します。
    ユーザーログインを手動で設定しないと、IdM は、指定した名および姓に基づいて自動的にログインを生成します。
  5. 追加 をクリックします。
    または、Add and Add Another をクリックして、別のユーザーの追加、または Add および Edit をクリックして、新規ユーザーエントリーの編集を開始します。ユーザーエントリーの編集に関する情報は、「ユーザーの編集」 を参照してください。

コマンドラインでのユーザーの追加

アクティブな状態で 新しいユーザーを追加するには、ipa user-add コマンドを使用します。ステージ 状態で新しいユーザーを追加するには、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 では、ログイン時にユーザーがユーザー名をすべて小文字入力する必要があります。さらに、ユーザー名が、user User などの文字調整でのみ異なるユーザーを追加することはできません。
ユーザー名のデフォルトの長さは、最大 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 ユーザーステージユーザー、 または 保存済みユーザー カテゴリーを選択します。

    図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
...
同様に、ログインにユーザーが含まれる全ステージユーザーを表示するには、以下を実行します
$ 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 でのユーザーのライフサイクルの管理

ステージユーザーをアクティベートするには、以下を実行します。
  • ステージユーザー 一覧で、アクティベートするユーザーを選択し、Activate をクリックします。

    図11.6 ユーザーのアクティベート

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

    図11.7 ユーザーの削除

    ユーザーの削除
  2. アクティブなユーザーを選択した場合は、delete または preserve を選択します。ステージユーザーを選択した場合は、ユーザーの削除のみが可能です。デフォルトの UI オプションは delete です。
    たとえば、アクティブなユーザーを保存するには、以下を実行します。

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

    Web UI での削除モードの選択
    確認するには、Delete ボタンをクリックします。
保存済みユーザーを復元するには、以下を実行します。
  • 保存済みユーザー 一覧で、復元するユーザーを選択し、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. アクティブユーザー、ステージユーザー または 保存済みユーザー カテゴリーを検索し、編集するユーザーを検索します。
  3. 編集するユーザー名をクリックします。

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

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

    図11.11 変更されたユーザー属性の保存

    変更されたユーザー属性の保存
Web UI でユーザーの詳細を更新すると、新しい値はすぐに同期されません。新しい値がクライアントシステムに反映されるまで、約 5 分程度かかる場合があります。

コマンドラインでのユーザーの編集

アクティブ または 保存済み 状態のユーザーを変更するには、ipa user-mod コマンドを使用します。ステージ 状態のユーザーを変更するには、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 に残り、関連する情報は何も変更しません。保存済みユーザーアカウントとは異なり、無効にしたユーザーアカウントは アクティブな状態 のままになります。そのため、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. アクティブユーザー リストから、必要なユーザーまたはユーザーを選択し、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. 管理者以外のユーザーによるユーザーエントリーの管理の許可

デフォルトでは、ユーザーのライフサイクルの管理 とユーザーアカウントの無効化または有効化は、管理ユーザーのみです。別の管理者以外のユーザーがこれを実行できるようにするには、新しいロールを作成し、このロールに関連するパーミッションを追加し、管理者以外のユーザーをロールに割り当てます。
デフォルトでは、IdM にはユーザーアカウントの管理に関する以下の権限が含まれます。
ユーザーの変更およびパスワードのリセット
この権限には、さまざまなユーザー属性を変更する権限が含まれます。
User Administrators
この権限には、アクティブユーザーの追加、アクティブでないユーザーの有効化、ユーザーの削除、ユーザー属性の変更、およびその他のパーミッションの追加、権限が含まれます。
ステージユーザープロビジョニング
この特権には、ステージユーザーを追加するパーミッションが含まれます。
ステージユーザー管理者
この権限には、ステージユーザーの追加やライフサイクル状態間のユーザーの移動など、多数のライフサイクル操作を実行するパーミッションが含まれます。ただし、ユーザーを active 状態に移行するパーミッションは含まれません。
ロール、パーミッション、および権限の定義に関する情報は、「ロールベースのアクセス制御の定義」 を参照してください。

異なるユーザー異なるユーザー管理操作の実行を許可する

ユーザーアカウントの管理に関連する異なる特権は、別のユーザーに追加できます。たとえば、以下のように、従業員アカウントエントリーおよびアクティベーションに特権を分けることができます。
  • ステージユーザー 管理者として 1 人のユーザーを設定します。このユーザーは、ステージユーザーとして IdM に将来の従業員を追加できますが、アクティベートすることはできません。
  • 別のユーザーを セキュリティー管理者として 行うと、従業員の認証情報を最初の日付けで検証したあとにステージユーザーをアクティベートできます。
ユーザーが特定のユーザー管理操作を実行できるようにするには、必要な特権または特権で新しいロールを作成し、そのロールをそのユーザーに割り当てます。

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

この例は、新しいステージユーザーの追加のみを許可するユーザーの作成方法を示していますが、他のステージユーザー管理操作は実行しません。
  1. 管理者ユーザーまたは別の ユーザーとしてログインします
    $ 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 の特権をロールに追加します。この特権により、ステージユーザーを追加できます。
      $ 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. 管理者以外のユーザーに対し、ステージユーザーを追加する権限を付与します。
    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 ユーザーとして新規ステージユーザーの追加をテストします。
    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. ステージユーザーを追加する特権を指定して、ユーザー provisionator を作成します。ユーザーアカウントは、外部プロビジョニングシステムにより、新しいステージユーザーを追加するために使用します。
    1. provisionator ユーザーアカウントを追加します。
      $ ipa user-add provisionator --first=provisioning --last=account --password
    2. provisionator ユーザーに必要な 特権を付与します。
      ステージユーザーの追加を管理する System Provisioning というカスタムロールを作成します。
      $ ipa role-add --desc "Responsible for provisioning stage users" "System Provisioning"
      Stage User Provisioning の特権をロールに追加します。この権限により、stage ユーザーを追加することができます。
      $ 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 でステージユーザーアカウントを自動アクティブ化するように設定する

この手順では、stage ユーザーをアクティベートするスクリプトを作成する方法を説明します。システムは、指定した間隔でスクリプトを自動的に実行します。これにより、新規ユーザーアカウントが自動的にアクティベートされ、作成直後に使用することができます。
重要
この手順では、スクリプトが IdM に追加する前に、新しいユーザーアカウントの検証が不要であることを前提としています。たとえば、ユーザーが外部プロビジョニングシステムの所有者によって検証されている場合、検証は必要ありません。
IdM サーバーの 1 つでのみアクティベーションプロセスを有効にするだけで 十 分です。
  1. アカウントのアクティベーション用に keytab ファイルを生成します。
    # ipa-getkeytab -s example.com -p "activator" -k /etc/krb5.ipa-activation.keytab
    複数の IdM サーバーでアクティベーションプロセスを有効にする場合は、1 つのサーバーで 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 でのユーザーの保存 を参照してください。
新規 stage ユーザーの追加
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
stage ユーザーの追加時に IdM オブジェクトクラスを指定する必要はありません。IdM は、ユーザーのアクティベート後にこれらのクラスを自動的に追加します。
作成したエントリーの識別名(DN)は uid=user_login で開始する必要があることに注意してください。
既存ユーザーの変更
ユーザーの変更前に、ユーザーのログインを検索してユーザーの識別名(DN)を取得します。以下の例では、以下の例の user_allowed_to_read ユーザーはユーザーおよびグループの情報を読み取り、パスワードは このユーザーのパスワードになります。
# 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
stage または保存済みユーザーをグループに追加しないでください。更新操作が正常に完了しても、ユーザーはグループのメンバーとして更新されません。アクティブユーザーのみがグループに所属できます。

例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. ステージエントリーの内容を検証して、プロビジョニングシステムにより、必要なすべての POSIX 属性が追加され、ステージエントリーをアクティベートする準備が整っていることを確認することを検討してください。ipa stageuser-show --all --raw コマンドを使用して、新しいステージユーザーの LDAP 属性を表示します。ユーザーは、ns accountlock 属性で明示的に無効にされていることに注意してください。
    $ 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 サービスに影響するマシン自体の変更に対応するために、これらのサービスの両方を管理するツールがあります。
本章では、クライアントマシンに直接関連する以下の 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 サーバー、サービス、およびドメインメンバーを識別します。これは、ユーザーアイデンティティーと同様に、IdM サーバーの 389 Directory Server インスタンスに保存されます。ユーザーと同様に、マシンは Kerberos または証明書を使用してドメインに対して認証できます。
マシン側からは、これらのドメインサービスにアクセスする以下のようなタスクが実行可能です。
  • DNS ドメインへの参加 (マシン登録)
  • DNS エントリーおよびゾーンの管理
  • マシン認証の管理
IdM での認証には、ユーザーのほかにマシンも含まれます。IdM サーバーがマシンを信頼し、そのマシンにインストールされているクライアントソフトウェアからの IdM 接続を受け入れるには、マシン認証が必要です。クライアントを認証すると、IdM サーバーはそのリクエストに応答できます。IdM は、マシン認証において 3 つのアプローチをサポートします。
  • SSH 鍵。ホストの SSH 公開キーが作成され、ホストエントリーにアップロードされます。そこから、SSSD(System Security Services Daemon)は IdM を ID プロバイダーとして使用し、OpenSSH およびその他のサービスと一緒に機能して、Identity Management の中央にある公開鍵を参照できます。これは、「ホストの公開 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 ゾーンは IdM で作成でき、「マスター DNS ゾーンの追加と削除」 で説明されています。IdM サーバーが DNS サーバーを管理しない場合は、通常のテキストフィールドなど、メニューエリアでゾーンを手動で入力できます。
    注記
    ホストが DNS 経由で解決可能であるかどうかを確認する場合は、Force チェックボックスを選択します。
  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. com の server.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" を指定することもできます。認証情報は、ホストのキータブの作成を許可されたユーザーに対応することが重要です。
アクティブな IdM クライアントまたはサーバーで ipa-getkeytab コマンドを実行すると、ユーザーが kinit admin などを使用して TGT を取得した場合に、LDAP 認証情報(-D および -w)なしで実行できます。無効化されたホストでコマンドを直接実行するには、LDAP 認証情報を提供して IdM サーバーに認証します。

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

OpenSSH は、公開鍵を使ってホストに対して認証を行います。あるマシンが別のマシンにアクセスを試みてキーのペアを提示します。ホストの初回認証時には、ターゲットマシンの管理者は、この要求を手動で認証する必要があります。次に、マシンはホストの公開鍵を known_hosts ファイルに保存します。リモートのマシンがターゲットマシンへのアクセスを再度試みると、ターゲットマシンは単に known_hosts ファイルをチェックして、承認済みのホストにアクセス権を自動的に付与します。
このシステムには、以下のような問題があります。
  • known_hosts ファイルは、ホストエントリーをホスト IP アドレス、ホスト名、およびキーのトリプレットに保存します。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 ファイルのホストの公開鍵エントリーを、ユーザーキーの形式に一致するように変更する必要があります。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. 公開鍵をキーファイルからコピーします。完全なキーエントリーは、ホスト名,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 ホストの一覧

    ホストの一覧
  5. Settings タブの Host Settings エリアで 、SSH 公開鍵 の横にある Add をクリックします。

    図12.5 SSH キーの追加

    SSH キーの追加
  6. ホストの公開鍵に貼り付けて、Set をクリックします。

    図12.6 SSH キーの設定

    SSH キーの設定
    SSH 公開鍵 エリアに、新しい鍵が表示されるようになりました。Show/Set key をクリックすると、提出されたキーが開きます。
  7. 複数のキーをアップロードするには、公開鍵リストの下にある Add をクリックして、他のキーをアップロードします。
  8. すべてのキーが送信されたら、ホストページの上部にある Save をクリックして変更を保存します。
公開鍵を保存すると、エントリーは鍵フィンガープリント、コメント (存在する場合)、および鍵の種類として表示されます。[2].
ホストキーをアップロードしたら、Identity Management を ID ドメインの 1 つとして使用するように SSSD を設定し、OpenSSH がホストキーの管理に SSSD ツールを使用するように設定します。詳細は、『 System-Level Authentication Guide』の「Configuring Services: OpenSSH and Cached Keys」で説明されています

12.5.4. コマンドラインからのホストキーの追加

ホスト SSH 鍵は、host -add を使用してホストを作成する場合、または後でエントリーを変更して、IdM のホストエントリーに追加されます。
注記
インストールスクリプトで SSH サービスが明示的に無効にされていない限り、RSA および DSS ホストキーは ipa-client-install コマンドで作成されます。
  1. --sshpubkey オプションを指定して host-mod コマンドを実行し、base64 でエンコードされた公開鍵をホストエントリーにアップロードします。
    ホストキーを追加すると、ホストの DNS SSHFP エントリーも変更されるので 、--updatedns オプションを使用してホストの DNS エントリーも更新します。
    たとえば、以下のようになります。
    [jsmith@server ~]$ ipa host-mod --sshpubkey="ssh-rsa RjlzYQo==" --updatedns host1.example.com
    実際のキーは通常、等号(=)で終わりますが、今後は続きます。
    複数のキーをアップロードするには、複数の --sshpubkey コマンドラインパラメーターを入力します。
    --sshpubkey="RjlzYQo==" --sshpubkey="ZEt0TAo=="
    注記
    ホストには複数の公開鍵を指定できます。
  2. ホストキーをアップロードしたら、Identity Management を ID ドメインの 1 つとして使用するように SSSD を設定し、OpenSSH がホストキーの管理に SSSD ツールを使用するように設定します。詳細は、『 System-Level Authentication Guide』の「Configuring Services: OpenSSH and Cached Keys」で説明されています

12.5.5. ホストキーの削除

ホストキーは、期限が切れるか有効でなくなると、削除できます。
Web UI を使用して個別のホストキーを削除するのが最も簡単な方法です。
  1. Identity タブを開き、サブタブの ホスト を選択します。
  2. 編集するホスト名をクリックします。

    図12.7 ホストの一覧

    ホストの一覧
  3. SSH 公開鍵 エリアで、キー のフィンガープリントにより Delete をクリックして削除します。

    図12.8 公開鍵の削除

    公開鍵の削除
  4. ホストページの上部にある Save をクリックして、変更を保存します。
コマンドラインツールで、すべてのキーを削除することもできます。これには 、--sshpubkey= を空の値に指定して ipa host-mod を実行します。これにより、ホストの公開鍵 がすべて削除され ます。また 、--updatedns オプションを使用して、ホストの DNS エントリーを更新します。たとえば、以下のようになります。
[jsmith@server ~]$ kinit admin
[jsmith@server ~]$ ipa host-mod --sshpubkey= --updatedns host1.example.com


[2] キータイプがアップロードされたキーに含まれていない場合には、キー自体をもとに自動的に決定されます。

12.6. ホストの ethers 情報の設定

NIS は ethers テーブルをホストでき、そのプラットフォーム、オペレーティングシステム、DNS ドメイン、および MAC アドレスをもとに、システムの DHCP 設定ファイルを管理するのに使用できます。すべての情報は、IdM のホストエントリーに保存されます。
Identity Management では、各システムはディレクトリーに対応する ethers エントリーで ou=ethers サブツリーに作成されます。
cn=server,ou=ethers,dc=example,dc=com
このエントリーは、ether s サービスの NIS マップを作成し、IdM の NIS 互換性プラグインで管理できます。
ethers エントリーの NIS マップを設定するには、以下を行います。
  1. ホストエントリーに MAC アドレス属性を追加します。たとえば、以下のようになります。
    [jsmith@server ~]$ kinit admin
    [jsmith@server ~]$ ipa host-mod --macaddress=12:34:56:78:9A:BC server.example.com
  2. nsswitch.conf ファイルを開きます。
  3. ethers サービスの行を追加し、ルックアップに LDAP を使用するよう設定します。
    ethers: ldap
  4. ethers 情報がクライアントで利用可能かどうかを確認します。
    [root@server ~]# getent ethers server.example.com

第13章 ユーザーおよびグループの管理

13.1. IdM でのユーザーおよびグループの仕組み

13.1.1. ユーザーおよびグループの概要

ユーザーグループは、共通の特権、パスワードポリシーなどの持つユーザーのセットです。
ホストグループは、共通のアクセス制御ルールやその他の特性を持つ IdM ホストセットです。
たとえば、企業の部門、物理的な場所、またはアクセス制御要件に関するグループを定義できます。

13.1.2. サポート対象のグループメンバー

IdM のユーザーグループには以下が含まれます。
  • IdM ユーザー
  • 他の IdM ユーザーグループ
  • 外部ユーザー (IdM の外部に存在するユーザー)
IdM のホストグループには以下が含まれます。
  • IdM サーバーおよびクライアント
  • その他の IdM ホストグループ

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

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

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

直接および間接グループメンバーシップ
ユーザーグループ A にパスワードポリシーを設定すると、ポリシーはユーザーグループ B のすべてのユーザーに適用されます。

例13.1 直接および間接グループメンバーの表示

  1. group_A と group_ B の 2 つのグループを作成します。「ユーザーまたはグループの追加と削除」 を参照してください。
  2. 以下を追加します。
    • group_Aのメンバーとしての 1 ユーザー
    • group_Bのメンバーとしての別のユーザー
    • group_bgroup_Aのメンバーとする
  3. Web UI で、IdentityGroups を選択します。左側のサイドバーに表示されている個々のグループタイプから、User Groups を選択し、group_A の名前をクリックします。直接メンバーシップ と 間接メンバーシップ を切り替えます

    図13.2 グループの直接および間接メンバー

    グループの直接および間接メンバー
  4. コマンドラインからの - ipa group-show コマンドを使用します。
    $ ipa group-show group_A
      ...
      Member users: user_1
      Member groups: group_B
      Indirect Member users: user_2
間接メンバーの一覧には、信頼された Active Directory ドメインの外部ユーザーが含まれません。Active Directory 信頼ユーザーオブジェクトは、IdM 内に LDAP オブジェクトとして存在しないため、IdM インターフェースには表示されません。

13.1.4. IdM のユーザーグループタイプ

POSIX グループ (デフォルト)
POSIX グループは、メンバーの POSIX 属性に対応します。Active Directory と対話するグループは POSIX 属性を使用できないことに注意してください。
非 POSIX グループ
このタイプのグループのグループメンバーはすべて、IdM ドメインに属している必要があります。
外部グループ
外部グループを使用すると、IdM ドメイン外の ID ストアに存在するグループメンバーを追加できます。外部ストアは、ローカルシステム、Active Directory ドメイン、またはディレクトリーサービスになります。
非 POSIX および外部グループは、POSIX 属性に対応していません。たとえば、これらのグループには GID が定義されていません。

例13.2 各種ユーザーグループの検索

  1. ipa group-find コマンドを実行して、すべてのユーザーグループを表示します。
  2. ipa group-find --posix コマンドを実行して、すべての POSIX グループを表示します。
  3. ipa group-find --nonposix コマンドを実行して、POSIX 以外のグループをすべて表示します。
  4. ipa group-find --external コマンドを実行して、すべての外部グループを表示します。

13.1.5. デフォルトで作成されたユーザーおよびグループ

表13.1 デフォルトで作成されたユーザーおよびグループ

グループ名 ユーザーまたはホスト デフォルトのグループメンバー
ipausers ユーザーグループ すべての IdM ユーザー
admins ユーザーグループ 管理権限を持つユーザー (初期のデフォルトの admin ユーザー)
editors ユーザーグループ ユーザーは、管理ユーザーの権限がすべてなくても、Web UI で他の IdM ユーザーを編集できます。
trust admins ユーザーグループ Active Directory 信頼を管理する権限を持つユーザー
ipaservers ホストグループ すべての IdM サーバーホスト
ユーザーグループにユーザーを追加すると、そのグループに関連付けられた特権およびポリシーが適用されます。たとえば、ユーザーを admins グループに追加すると、ユーザーに管理者権限が付与されます。
警告
admins グループを削除しないでください。admins は IdM で必要な事前定義グループであるため、この操作では特定のコマンドで問題が生じます。
警告
ホストを ipaservers ホストグループに追加する場合は注意してください。ipaservers のすべてのホストは、それ自体を IdM サーバーにプロモートできます。
また、IdM で 新しいユーザーが作成されるたびに、IdM は、デフォルトでユーザープライベートグループ を作成します。
  • ユーザープライベートグループは、作成したユーザーと同じ名前を持ちます。
  • ユーザーは、ユーザープライベートグループの唯一のメンバーです。
  • プライベートグループの GID は、ユーザーの UID と一致します。

例13.3 ユーザープライベートグループの表示

ipa group-find --private コマンドを実行して、すべてのユーザープライベートグループを表示します。
$ ipa group-find --private
----------------
2 groups matched
----------------
  Group name: user1
  Description: User private group for user1
  GID: 830400006

  Group name: user2
  Description: User private group for user2
  GID: 830400004
----------------------------
Number of entries returned 2
----------------------------
状況によっては、NIS グループまたは別のシステムグループが、ユーザープライベートグループに割り当てられる GID を既に使用している場合など、ユーザープライベートグループを作成しないようにする方が良い場合があります。「ユーザープライベートグループの無効化」 を参照してください。

13.2. ユーザーまたはグループの追加と削除

グループを追加するには、以下を使用します。
IdM は、ユーザーグループの作成時にカスタム GID を指定できるようにします。これを行う場合は、ID の競合を避けるように注意してください。「その ID の値が一意であることを確認する」 を参照してください。カスタム GID を指定しない場合、IdM は使用可能な ID 範囲から GID を自動的に割り当てます。
グループを削除するには、以下を使用します。
グループを削除しても、IdM からグループメンバーは削除されないことに注意してください。

Web UI: ユーザーまたはグループの追加

  1. IdentityGroups をクリックし、左側のサイドバーで User Groups または Host Groups を選択します。
  2. Add をクリックして、グループの追加を開始します。
  3. グループの情報を入力します。
    ユーザーグループのタイプの詳細は、「IdM のユーザーグループタイプ」 を参照してください。
  4. Add をクリックして確定します。

コマンドライン: ユーザーまたはグループの追加

  1. 管理者としてログインします。
    $ kinit admin
  2. ユーザーグループを追加するには、ipa group-add コマンドを使用します。ホストグループを追加するには、ipa hostgroup-add コマンドを使用します。
    $ ipa group-add group_name
    -----------------------
    Added group "group_name"
    ------------------------
デフォルトでは、ipa group-add は、POSIX ユーザーグループを追加します。別のグループタイプを指定するには、ipa group-add にオプションを追加します。
  • --nonposix は、POSIX 以外のグループを作成します。
  • --external は、外部グループを作成します。
グループタイプの詳細は、「IdM のユーザーグループタイプ」 を参照してください。

Web UI: ユーザーまたはグループの削除

  1. IdentityGroups をクリックし、左側のサイドバーで User Groups または Host Groups を選択します。
  2. 削除するグループを選択し、削除 をクリックします。

コマンドライン: ユーザーまたはグループの削除

  1. 管理者としてログインします。
    $ kinit admin
  2. ユーザーグループを削除するには、ipa group-del group_name コマンドを使用します。ホストグループを削除するには、ipa hostgroup-del group_name コマンドを使用します。
    $ ipa group-del group_name
    --------------------------
    Deleted group "group_name"
    --------------------------

13.3. ユーザーまたはホストグループメンバーの追加と削除

ユーザーグループにメンバーを追加するには、以下を使用できます。
重要
別のユーザーグループをメンバーとして追加する場合は、再帰グループを作成しないでください。たとえば、グループ A がグループ B のメンバーである場合は、グループ B をグループ A のメンバーとして追加しないでください。再帰的なグループにより予期しない動作が発生する可能性があります。
ユーザーグループからメンバーを削除するには、以下を使用できます。
注記
ユーザーまたはグループにメンバーを追加すると、更新が Identity Management 環境のすべてのクライアントに広がるまでに時間がかかる場合があります。これは、特定のホストがユーザー、グループ、またはネットグループを解決するときに、System Security Services Daemon (SSSD)が最初にキャッシュを調べ、サーバーの検索で不足または期限切れのレコードのみを検索するためです。
ホストグループに直ちに適用された変更を表示するには、cache purge ユーティリティー sss_cache を使用して、ホストで SSSD キャッシュを更新します。sss_cache を使用してホストグループの SSSD キャッシュの現在のレコードを無効にすると、SSSD キャッシュがアイデンティティープロバイダーから更新されたレコードを取得するよう強制されるため、変更をすばやく使用できます。
SSSD キャッシュでホストグループエントリーを消去するには、次のコマンドを実行します。
# sss_cache -n host_group_name

Web UI: ユーザーまたはグループへのメンバーの追加

  1. IdentityGroups をクリックし、左側のサイドバーで User Groups または Host Groups を選択します。
  2. グループ名をクリックします。
  3. 追加するグループメンバーのタイプを選択してください。たとえば、ユーザーグループの場合はユーザー ユーザーグループ、または 外部 などです。

    図13.3 ユーザーグループメンバーの追加

    ユーザーグループメンバーの追加
  4. 追加 をクリックします。
  5. 追加するメンバーを選択し、Add をクリックして確定します。

コマンドライン: ユーザーグループへのメンバーの追加

  1. 任意。ipa group-find または ipa hostgroup-find コマンドを使用してグループを検索します。
  2. ユーザーグループにメンバーを追加するには、ipa group-add-member コマンドを使用します。ホストグループにメンバーを追加するには、ipa hostgroup-add-member コマンドを使用します。
    ユーザーグループメンバーを追加する場合は、以下のオプションを使用してメンバーを指定します。
    • --users は、IdM ユーザーを追加します
    • --external は、DOMAIN\user_name または user_name@domain の形式で、IdM ドメイン外に存在するユーザーを追加します。
    • --groups は、IdM ユーザーグループを追加します。
    ホストグループメンバーを追加する場合は、以下のオプションを使用してメンバーを指定します。
    • --hosts は、IdM ホストを追加します
    • --groups は、IdM ホストグループを追加します。

    例13.4 メンバーをユーザーグループに追加するコマンドの例

    user1、user2、および group1group_name という名前のグループに追加するには、次のコマンドを実行します。
    $ ipa group-add-member group_name --users=user1 --users=user2 --groups=group1
    ad_ domain という名前のドメインから group_ name という名前のグループに ad _ user を追加するには、外部ユーザーの指定方法を選択できます。たとえば、以下のようになります。
    $ ipa group-add-member group_name --external='AD_DOMAIN\ad_user'
    $ ipa group-add-member group_name --external='ad_user@AD_DOMAIN'
    $ ipa group-add-member group_name --external='ad_user@AD_DOMAIN.EXAMPLE.COM'
    

Web UI: ユーザーグループからのメンバーの削除

  1. IdentityGroups をクリックし、左側のサイドバーで User Groups または Host Groups を選択します。
  2. グループ名をクリックします。
  3. 削除するグループメンバーのタイプを選択します。たとえば、ユーザーグループの場合はユーザー ユーザーグループ、または 外部 などです。

    図13.4 ユーザーグループメンバーの削除

    ユーザーグループメンバーの削除
  4. 必要なメンバーの横にあるチェックボックスを選択します。
  5. 削除 をクリックします。

コマンドライン: ユーザーグループからのメンバーの削除

  1. 任意。ipa group-show コマンドまたは ipa hostgroup-show コマンドを使用して、削除するメンバーがグループに含まれていることを確認します。
  2. ユーザーグループメンバーを削除するには、ipa group-remove-member コマンドを使用します。ホストグループメンバーを削除するには、ipa hostgroup-remove-member コマンドを使用します。
    ユーザーグループメンバーを削除するには、以下のオプションを使用してメンバーを指定します。
    • --users は、IdM ユーザーを削除します
    • --external は、DOMAIN\user_name または user_name@domain の形式で、IdM ドメイン外に存在するユーザーを削除します。
    • --groups は、IdM ユーザーグループを削除します
    ホストグループメンバーを削除するには、以下のオプションを使用してメンバーを指定します。
    • --hosts は、IdM ホストを削除します
    • --groups は、IdM ホストグループを削除します。
    たとえば、group _name という名前のグループから、user 1user2、および group1 を削除するには、次のコマンドを実行します
    $ ipa group-remove-member group_name --users=user1 --users=user2 --groups=group1

13.4. ユーザープライベートグループの無効化

IdM が新規ユーザーにデフォルトのユーザープライベートグループを作成しないようにするには、以下のいずれかを選択します。
デフォルトのユーザープライベートグループを作成せずに、IdM では、新しいユーザーを追加するときに GID が必要になります。ユーザーの追加が正常に行われたことを確認するには、「ユーザープライベートグループが無効になっています」 を参照してください。
注記
GID の競合によりデフォルトのユーザープライベートグループの作成を無効にする場合は、デフォルトの UID および GID 割り当て範囲を変更することを検討してください。14章一意の UID および GID 番号の割り当て を参照してください。

13.4.1. ユーザープライベートグループのないユーザーの作成

ipa user-add コマンドに --noprivate オプションを追加します。コマンドを正常に実行するには、カスタムのプライベートグループを指定する必要があります。「ユーザープライベートグループが無効になっています」 を参照してください。

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

  1. 管理者としてログインします。
    $ kinit admin
  2. IdM は、Directory Server 管理対象エントリープラグインを使用して、ユーザープライベートグループを管理します。プラグインのインスタンスを一覧表示します。
    $ ipa-managed-entries --list
  3. IdM がユーザープライベートグループを作成しないようにするには、ユーザープライベートグループを管理するプラグインインスタンスを無効にします。
    $ ipa-managed-entries -e "UPG Definition" disable
    Disabling Plugin
    注記
    後で UPG 定義 インスタンスを再度有効にするには、ipa-managed-entries -e "UPG Definition" enable コマンドを使用します。
  4. Directory Server を再起動して、新しい構成を読み込みます。
    # systemctl restart dirsrv.target

13.4.3. ユーザープライベートグループが無効になっています

デフォルトのユーザープライベートグループの作成時に新規ユーザーの追加に成功すると成功させるには、以下のいずれかを選択します。
  • 新しいユーザーを追加するときにカスタムの GID を指定します。GID は、既存のユーザーグループに対応する必要はありません。
    たとえば、コマンドラインからユーザーを追加する場合は 、--gid オプションを ipa user-add コマンドに追加します。
  • automember ルールを使用して、GID を持つ既存のグループにユーザーを追加します。「ユーザーおよびホストの自動グループメンバーシップの定義」 を参照してください。

13.5. ユーザーおよびユーザーグループの検索属性の設定

ipa user-find keywordコマンドおよび ipa group-find キーワード コマンドを使用して指定されたキーワードのエントリーを検索すると、IdM は特定の属性のみを検索します。以下に例を示します。
  • ユーザーの検索: 名、姓、ユーザー名(ログイン ID)、ジョブタイトル、組織単位、電話番号、UID、メールアドレス。
  • グループ検索では、グループ名、description です。
以下の手順では、他の属性を検索するように IdM を設定する方法を説明します。IdM は常にデフォルトの属性を検索することに注意してください。たとえば、ユーザー検索属性の一覧からジョブタイトル属性を削除すると、IdM はユーザータイトルを検索します。

前提条件

新しい属性を追加する前に、対応するインデックスがこの属性の LDAP ディレクトリーに存在することを確認してください。ほとんどの標準 LDAP 属性には LDAP にインデックスがありますが、カスタム属性を追加する場合は、インデックスを手動で作成する必要があります。『 Directory Server Administration Guide』の「Creating Standard Indexes』 」を参照してください

Web UI: 検索属性の設定

  1. IPA ServerConfiguration を選択します。
  2. ユーザーオプション エリアで、ユーザー検索フィールドにユーザー検索属性 を設定します
  3. Group Options エリアで、グループ検索フィールドにグループ検索属性 を設定します
  4. ページ上部の Save をクリックします。

コマンドライン: 検索属性の設定

以下のオプションを指定して ipa config-mod コマンドを使用します。
  • --usersearch は、ユーザーの検索属性の新しいリストを定義します。
  • --groupsearch は、グループの検索属性の新しいリストを定義します。
たとえば、以下のようになります。
$ ipa config-mod --usersearch="uid,givenname,sn,telephonenumber,ou,title"
$ ipa config-mod --groupsearch="cn,description"

13.6. ユーザーおよびホストの自動グループメンバーシップの定義

13.6.1. IdM での自動グループメンバーシップの仕組み

13.6.1.1. 自動グループメンバーシップの概要

自動グループメンバーシップを使用すると、属性に基づいてユーザーとホストをグループに自動的に割り当てることができます。たとえば、以下を行うことができます。
  • 従業員のマネージャー、ロケーション、またはその他の属性に基づいて従業員のユーザーエントリーをグループに分割します。
  • クラス、ロケーション、またはその他の属性に基づいてホストを分割します。
  • 全ユーザーまたは全ホストを 1 つのグローバルグループに追加します。

13.6.1.2. 自動グループメンバーシップの利点

グループメンバーシップを手動で管理するオーバーヘッドを削減
自動グループメンバーシップを使用すると、管理者はユーザーとホストをグループに手動で割り当てなくなりました。
ユーザーおよびホスト管理における一貫性の向上
自動グループメンバーシップを使用すると、ユーザーおよびグループの自動評価基準に基づいて、ユーザーとホストがグループに割り当てられます。
グループベースの設定の容易な管理
さまざまな設定がグループに定義され、sudo ルール、自動マウント、またはアクセス制御などの個別のグループメンバーに適用されます。自動グループメンバーシップを使用すると、ユーザーとホストは指定されたグループに自動的に追加されるため、グループベースの設定の管理が容易になります。

13.6.1.3. automember ルール

自動グループメンバーシップを設定する際に、管理者は automember ルールを定義します。automember ルールは、特定のユーザーまたはグループに適用されます。これには、ユーザーまたはグループに含めるか、除外する必要がある 条件 が含まれます。
包含条件
ユーザーまたはホストのエントリーが包含条件を満たす場合には、グループに含まれます。
除外の条件
ユーザーまたはホストのエントリーが除外条件を満たす場合には、グループに 含まれません
この条件は、Perl 互換正規表現 (PCRE) 形式の正規表現として指定されます。PCRE の詳細は、pcresyntax(3) の man ページを参照してください。
IdM は、包含条件の前に除外条件を評価します。競合が発生した場合は、包含条件よりも除外条件が優先されます。

13.6.2. Automember ルールの追加

以下のコマンドを使用して automember ルールを追加するには、以下を実行します。
automember ルールを追加した後、以下を実行します。
  • 今後作成されるすべてのエントリーは、指定されたグループのメンバーになります。エントリーが複数の automember ルールで指定された条件を満たす場合には、対応するすべてのグループに追加されます。
  • 既存のエントリーは、指定されたグループのメンバー にはなりません。詳細は、「既存のユーザーおよびホストへの Automember ルールの適用」 を参照してください。

Web UI: Automember ルールの追加

  1. IdentityAutomemberUser group rules または Host group rules を選択します。
  2. 追加 をクリックします。
  3. Automember rule フィールドで、ルールを適用するグループを選択します。Add and Edit をクリックします
  4. 1 つ以上の包含および除外条件を定義します。詳しくは、「automember ルール」 を参照してください。
    1. Inclusive セクション または Exclusive セクションで、Add をクリックします。
    2. Attribute フィールドで、必要な属性を選択します。
    3. Expression フィールドに正規表現を定義します。
    4. 追加 をクリックします。
    たとえば、以下の条件は、ユーザーログイン属性(uid )に値(.*)が指定されている全ユーザーを対象にしています

    図13.5 Automember ルール条件の追加

    Automember ルール条件の追加

コマンドライン: Automember ルールの追加

  1. ipa automember-add コマンドを使用して automember ルールを追加します。プロンプトが表示されたら、以下を指定します。
    • automember ルール。ターゲットグループ名に一致する。
    • Grouping Type: ルールがユーザーグループまたはホストグループを対象にするかどうかを指定します。ユーザーグループを対象に設定するには、group と入力します ホストグループを対象に設定するには、hostgroup と入力します
    たとえば、user _group という名前のユーザーグループの automember ルールを追加するには、次のコマンドを実行します。
    $ ipa automember-add
    Automember Rule: user_group
    Grouping Type: group
    --------------------------------
    Added automember rule "user_group"
    --------------------------------
      Automember Rule: user_group
  2. 1 つ以上の包含および除外条件を定義します。詳しくは、「automember ルール」 を参照してください。
    1. 条件を追加するには、ipa automember-add-condition コマンドを使用します。プロンプトが表示されたら、以下を指定します。
      • automember ルール。ターゲットグループ名に一致する。
      • 属性 Key。フィルターが適用されるエントリー属性を指定します。たとえば、ユーザーの manager です。
      • Grouping Type: ルールがユーザーグループまたはホストグループを対象にするかどうかを指定します。ユーザーグループを対象に設定するには、group と入力します ホストグループを対象に設定するには、hostgroup と入力します
      • 包含正規表現 および Exclusive 正規表現。正規表現として複数の条件を指定します。条件を 1 つだけ指定する場合は、他の条件の入力を求められたら Enter を押します。
      たとえば、以下の条件は、ユーザーログイン属性(uid )に値(.*)が指定されている全ユーザーを対象にしています
      $ ipa automember-add-condition
      Automember Rule: user_group
      Attribute Key: uid
      Grouping Type: group
      [Inclusive Regex]: .*
      [Exclusive Regex]:
      ----------------------------------
      Added condition(s) to "user_group"
      ----------------------------------
        Automember Rule: user_group
        Inclusive Regex: uid=.*
      ----------------------------
      Number of conditions added 1
      ----------------------------
    2. 条件を削除するには、ipa automember-remove-condition コマンドを使用します。

例13.5 コマンドライン: 自動メンバールールを作成してすべてのエントリーを 1 つのグループに追加する

cnfqdn などのすべてのユーザーまたはホストエントリーに含まれる属性に包含条件を作成すると、今後作成されるすべてのユーザーまたはホストが単一グループに追加されるようにすることができます。
  1. all_hosts という名前のホストグループなど、グループを作成します。「ユーザーまたはグループの追加と削除」 を参照してください。
  2. 新規ホストグループの automember ルールを追加します。たとえば、以下のようになります。
    $ ipa automember-add
    Automember Rule: all_hosts
    Grouping Type: hostgroup
    -------------------------------------
    Added automember rule "all_hosts"
    -------------------------------------
      Automember Rule: all_hosts
  3. 全ホストをターゲットとする包含条件を追加します。以下の例では、fqdn 属性に 値(.*)を持つホストを包含 してターゲットとします。
    $ ipa automember-add-condition
    Automember Rule: all_hosts
    Attribute Key: fqdn
    Grouping Type: hostgroup
    [Inclusive Regex]: .*
    [Exclusive Regex]:
    ---------------------------------
    Added condition(s) to "all_hosts"
    ---------------------------------
      Automember Rule: all_hosts
      Inclusive Regex: fqdn=.*
    ----------------------------
    Number of conditions added 1
    ----------------------------
今後追加されるすべてのホストは、自動的に all_hosts グループのメンバーになります。

例13.6 コマンドライン: 同期した AD ユーザーを同期する自動メンバールールの作成

Active Directory(AD)から同期した Windows ユーザーは、nt User オブジェクトクラスを共有します。ntUser が指定された全ユーザーを objectclass 属性にターゲットとする automember 条件を作成することで、今後作成されたすべての同期 AD ユーザーが AD ユーザーの共通グループに含まれるようにすることができます。
  1. ad_users などの、AD ユーザーのユーザーグループを作成します。「ユーザーまたはグループの追加と削除」 を参照してください。
  2. 新規ユーザーグループの automember ルールを追加します。たとえば、以下のようになります。
    $ ipa automember-add
    Automember Rule: ad_users
    Grouping Type: group
    -------------------------------------
    Added automember rule "ad_users"
    -------------------------------------
      Automember Rule: ad_users
  3. AD ユーザーをフィルタリングするための包含条件を追加します。以下の例では、包含条件は、objectclass 属性に ntUser 値を持つすべてのユーザーを対象にし ています
    $ ipa automember-add-condition
    Automember Rule: ad_users
    Attribute Key: objectclass
    Grouping Type: group
    [Inclusive Regex]: ntUser
    [Exclusive Regex]:
    -------------------------------------
    Added condition(s) to "ad_users"
    -------------------------------------
      Automember Rule: ad_users
      Inclusive Regex: objectclass=ntUser
    ----------------------------
    Number of conditions added 1
    ----------------------------
今後追加されるすべての AD ユーザーは、自動的に ad_users ユーザーグループのメンバーであることになります。

13.6.3. 既存のユーザーおよびホストへの Automember ルールの適用

automember ルールは、ルールの追加後に作成されたユーザーおよびホストエントリーに自動的に適用されます。ルールは、ルールが追加される前に存在したエントリーには繰り返し適用されません。
ルールを追加する前に存在したエントリーに automember ルールを適用するには、自動メンバーシップを手動で再構築します。自動メンバーシップを再構築すると、既存の automember ルールがすべて再評価され、すべてのエントリーまたは特定のエントリーに適用されます。

Web UI: 既存エントリーの自動メンバーシップを再構築

ユーザーまたは全ホストの自動メンバーシップを再構築するには、次のコマンドを実行します。
  1. IdentityUsers または Hosts を選択します。
  2. ActionsRebuild auto membership をクリックします。

    図13.6 ユーザーまたは全ホストの自動メンバーシップの再構築

    ユーザーまたは全ホストの自動メンバーシップの再構築
単一ユーザーまたはホストに対してのみ自動メンバーシップを再構築するには、以下を実行します。
  1. IdentityUsers または Hosts を選択し、必要なユーザーログインまたはホスト名をクリックします。
  2. ActionsRebuild auto membership をクリックします。

    図13.7 単一ユーザーまたはホストの自動メンバーシップの再構築

    単一ユーザーまたはホストの自動メンバーシップの再構築

Command Line: 既存エントリーの自動メンバーヒントを再構築します。

すべてのユーザーの自動メンバーシップを再構築するには、ipa automember-rebuild --type=group コマンドを使用します。
$ ipa automember-rebuild --type=group
--------------------------------------------------------
Automember rebuild task finished. Processed (9) entries.
--------------------------------------------------------
すべてのユーザーの自動メンバーシップを再構築するには、ipa automember-rebuild --type=hostgroup コマンドを使用します。
指定したユーザーまたはユーザーの自動メンバーシップを再構築するには、ipa automember-rebuild --users=user コマンドを使用します。
$ ipa automember-rebuild --users=user1 --users=user2
--------------------------------------------------------
Automember rebuild task finished. Processed (2) entries.
--------------------------------------------------------
指定したホストの自動メンバーシップを再構築するには、ipa automember-rebuild --hosts=example.com コマンドを使用します。

13.6.4. デフォルトの自動メンバーグループの設定

デフォルトの automember グループが設定されていると、automember ルールに一致しないユーザーまたはホストエントリーは自動的にデフォルトのグループに追加されます。
  1. ipa automember-default-group-set コマンドを使用して、デフォルトの automember グループを設定します。プロンプトが表示されたら、以下を指定します。
    • Default(fallback)Group。ターゲットグループ名を指定します。
    • Grouping Type: ターゲットがユーザーグループか、ホストグループであるかを指定します。ユーザーグループを対象に設定するには、group と入力します ホストグループを対象に設定するには、hostgroup と入力します
    たとえば、以下のようになります。
    $ ipa automember-default-group-set
    Default (fallback) Group: default_user_group
    Grouping Type: group
    ---------------------------------------------------
    Set default (fallback) group for automember "default_user_group"
    ---------------------------------------------------
      Default (fallback) Group: cn=default_user_group,cn=groups,cn=accounts,dc=example,dc=com
  2. グループが正しく設定されていることを確認するには、ipa automember-default-group-show コマンドを使用します。コマンドは、現在のデフォルトの automember グループを表示します。たとえば、以下のようになります。
    $ ipa automember-default-group-show
    Grouping Type: group
      Default (fallback) Group: cn=default_user_group,cn=groups,cn=accounts,dc=example,dc=com
現在のデフォルトの automember グループを削除するには、ipa automember-default-group-remove コマンドを使用します。

第14章 一意の UID および GID 番号の割り当て

IdM サーバーはユーザー ID(UID)とグループ ID(GID)の値を生成し、同時にレプリカが同じ ID を生成しないようにします。1 つの組織が複数の異なるドメインを使用する場合は、IdM ドメイン全体で UID および GID の一意の UID および GID が必要になる可能性があります。

14.1. ID 範囲

UID および GID 番号は ID 範囲 に分類されます。個別のサーバーとレプリカに別々の数値範囲を保持することで、エントリーに対して発行された ID の値が別のサーバーまたはレプリカの別のエントリーで既に使用されている可能性は最小限です。
ドメインのバックエンド 389 Directory Server インスタンスの一部として、DNA(Distributed Numeric Assignment)プラグインにより、範囲がサーバーとレプリカ間で更新され、共有されるようになります。プラグインはすべてのマスターおよびノードで ID 範囲を管理します。すべてのサーバーまたはレプリカには現在の ID 範囲と、現在の範囲がデペット後にサーバーまたはレプリカが使用する 次の ID 範囲があります。DNA Directory Server プラグインの詳細は『 Red Hat Directory Server Deployment Guide』を参照してください

14.2. インストール中の ID 範囲の割り当て中

サーバーのインストール時に、デフォルトで ipa-server-install コマンドは、ランダムの現在の ID 範囲をインストール済みサーバーに自動的に割り当てます。設定スクリプトは、使用可能な合計 1 つの範囲から、200,000 の ID の範囲をランダムに選択します。このようにランダムな範囲を選択すると、今後別の 2 つの IdM ドメインを統合する場合に、ID の競合が発生する可能性を大幅に削減できます。
ただし、ipa-server-install で以下の 2 つのオプションを使用して、サーバーのインストール時に現在の ID 範囲を手動で定義できます。
  • --idstart: UID および GID 番号の開始値を指定します。デフォルトでは、値はランダムに選択されます。
  • --idmax: UID および GID 番号の最大値を指定します。デフォルトでは、この値は --idstart の開始値に 199,999 を加えたものになります。
IdM サーバーが 1 つインストールされていると、新しいユーザーまたはグループのエントリーは、範囲全体からランダムな ID を受け取ります。新しいレプリカをインストールし、レプリカが独自の ID 範囲を要求すると、サーバーの初期 ID 範囲が分割され、サーバーとレプリカの間で分散されます。レプリカは、初期マスターで利用可能な残りの ID 範囲の半分を受け取ります。次に、サーバーとレプリカは、新しいエントリーに対して元の ID 範囲に対応する部分を使用します。また、レプリカに割り当てられた ID 範囲の ID の数が 100 未満の場合には、レプリカは、割り当てられた ID 範囲を使い果たした状態で、他の使用可能なサーバーに問い合わせて、新しい ID 範囲を要求する他の使用可能なサーバーと通信します。
サーバーは、DNA プラグインの初回使用時に ID 範囲を受け取ります。次にサーバーには ID 範囲が定義されていません。たとえば、マスターサーバーからレプリカを作成すると、レプリカはすぐに ID 範囲を受信しません。レプリカは、最初の ID がレプリカで割り当てられる場合にのみ、最初のマスターから ID 範囲を要求します。
注記
レプリカが ID 範囲を要求する前に最初のマスターが機能しなくなると、レプリカは ID 範囲の要求でマスターに問い合わせることができません。レプリカに新しいユーザーを追加しようとすると失敗します。このような状況では、無効になったマスターに割り当てられている ID 範囲を確認 し、ID 範囲を手動でレプリカに割り当てます( 「手動 ID 範囲の拡張および新規 ID 範囲の割り当て」 を参照)。

14.3. 現在割り当てられている ID 範囲の表示

サーバーに設定されている ID 範囲を表示するには、以下のコマンドを使用します。
  • ipa-replica-manage dnarange-show は、すべてのサーバーに設定されている現在の ID 範囲を表示します。サーバーを指定した場合は、指定したサーバー上でのみ表示されます。以下に例を示します。
    # ipa-replica-manage dnarange-show
    masterA.example.com: 1001-1500
    masterB.example.com: 1501-2000
    masterC.example.com: No range set
    
    # ipa-replica-manage dnarange-show masterA.example.com
    masterA.example.com: 1001-1500
  • ipa-replica-manage dnanextrange-show は、すべてのサーバーで現在設定されている次の ID 範囲を表示します。サーバーを指定した場合は、指定したサーバー上でのみ表示されます。以下に例を示します。
    # ipa-replica-manage dnanextrange-show
    masterA.example.com: 1001-1500
    masterB.example.com: No on-deck range set
    masterC.example.com: No on-deck range set
    
    # ipa-replica-manage dnanextrange-show masterA.example.com
     masterA.example.com: 1001-1500
この 2 つのコマンドの詳細は、ipa-replica-manage(1) の man ページを参照してください。

14.4. レプリカの削除後の自動 ID 範囲の拡張

機能しているレプリカを削除する場合、ipa-replica-manage del コマンドは、レプリカに割り当てられた ID 範囲を取得して、次の範囲として利用可能な他の IdM レプリカに追加します。これにより、他のレプリカで ID 範囲が利用可能のままとなります。
レプリカを削除したら、「現在割り当てられている ID 範囲の表示」 に記載されている ipa-replica-manage dnarange- show コマンドおよび ipa-replica- manage dnanextrange -show コマンドを使用して、他のサーバーに設定されている ID 範囲を確認できます。

14.5. 手動 ID 範囲の拡張および新規 ID 範囲の割り当て

特定の状況では、ID 範囲を手動で調整する必要があります。
割り当てられた ID 範囲を使い果たしました。
レプリカに割り当てられた ID 範囲を使い果たし、他のレプリカの ID 範囲でより多くの空き ID が利用できないため、ID の追加要求に失敗しました。レプリカに割り当てられた ID 範囲を拡張する必要があります。これには、既存の ID 範囲を分割するか、またはサーバーの初期設定した ID 範囲を過去に貼り付けてしまう可能性があります。または、新しい ID 範囲を割り当てることもできます。
注記
新しい ID 範囲を割り当てると、サーバーまたはレプリカにすでに既存のエントリーの UID は同じになります。現在の ID 範囲を変更しても、IdM が過去に割り当てられた範囲の記録を保持するため、この問題は問題が発生しません。
レプリカが機能しなくなった
ID 範囲は、レプリカの持続時に自動的に取得されず、削除する必要があるので、以前にレプリカに割り当てられていた ID 範囲が利用できなくなることを意味します。ID 範囲を復旧し、他のレプリカで利用できるようにします。
機能しなくなったサーバーに属する ID 範囲を回復して、別のサーバーに割り当てる場合は、最初に 「現在割り当てられている ID 範囲の表示」 に記載されている ipa-replica-manage dnarange-show コマンドを使用して ID 範囲の値を確認し、その ID 範囲を手動でサーバーに割り当てます。また、UID または GID が重複しないように、回復した範囲からの ID の値がユーザーまたはグループに割り当てられていないことを確認します。存在するユーザーおよびグループの UID および GID を調べることで、これを実行できます。
ID 範囲を手動で定義するには、以下の 2 つのコマンドを使用します。
  • ipa-replica-manage dnarange-set を使用すると、指定したサーバーの現在の ID 範囲を定義できます。
    # ipa-replica-manage dnarange-set masterA.example.com 1250-1499
  • ipa-replica-manage dnanextrange-set を使用すると、指定したサーバーの次の ID 範囲を定義できます。
    # ipa-replica-manage dnanextrange-set masterB.example.com 1001-5000
これらのコマンドの詳細は、ipa-replica-manage(1) の man ページを参照してください。
重要
ID 範囲を重複しないように注意してください。サーバーまたはレプリカに割り当てた ID 範囲のいずれかが重複すると、2 つのサーバーが同じ ID 値を異なるエントリーに割り当てる可能性があります。
UID の値が 1000 以下の ID 範囲は設定しないでください。この値はシステム使用のために予約されています。また、SSSD サービスは ID 値 0 を処理しません。
ID 範囲を手動で拡張する場合は、新たに拡張範囲が IdM ID 範囲に含まれていることを確認してください。これは、ipa idrange-find コマンドを使用して確認できます。ipa idrange-find -h コマンドを実行して、ipa idrange-find の使用方法を表示します。

14.6. その ID の値が一意であることを確認する

UID または GID が競合しないようにすることが推奨されます。UID と GID は常に一意でなければなりません。2 人のユーザーには UID は同じでなく、2 つのグループに同じ GID を含めることはできません。
自動 ID 割り当て
ユーザーまたはグループが対話的または、手動で指定した ID 番号なしで作成されると、サーバーは、ID 範囲からユーザーアカウントに次に利用可能な ID 番号を割り当てます。これにより、UID または GID が常に一意になります。
手動 ID 割り当て
ID をユーザーまたはグループエントリーに手動で割り当てると、サーバーは、指定された UID または GID が一意であることを検証しません。別のエントリーですでに使用されている値を選択した場合、競合は警告されません。
「変更された UID および GID 番号の修復」 で説明されているように、SSSD サービスは同じ ID を持つエントリーを処理しません。2 つのエントリーが同じ ID 番号を共有する場合、この ID の検索は最初のエントリーのみを返します。ただし、他の属性を検索する、または ipa user-find --all コマンドを実行すると、両方のエントリーが返されます。
UID と GID はいずれも、同じ ID 範囲から選択されます。ユーザーおよびグループは同じ ID を指定できます。UID と GID が uidNumbergidNumber の 2 つの異なる属性に設定されているので、この状況では競合は発生しません。
注記
ユーザーおよびグループの両方に同じ ID を設定すると、ユーザープライベートグループを設定できます。このようにユーザー固有のシステムグループを作成するには、そのユーザーとグループに同じ ID 値を設定し、メンバーのみが上記のユーザーになります。

14.7. 変更された UID および GID 番号の修復

ユーザーが IdM システムまたはサービスにログインすると、そのシステム上の SSSD は、ユーザー名をユーザーの UID および GID とともにキャッシュします。SSSD は、UID をユーザーの ID キーとして使用します。同じユーザー名で UID が異なるユーザーがシステムにログインすると、SSSD は 2 つの異なる UID を登録し、名前が競合する 2 つの異なるユーザーが存在することを前提としています。これにより、ユーザーの UID が変更された場合に問題が発生する可能性があります。このような場合、SSSD は、別の UID を持つ同じユーザーと同じユーザーを認識するのではなく、変更した UID を持つユーザーを新規ユーザーと誤って解釈します。既存のユーザーの UID が変更されると、ユーザーは SSSD および関連するサービスおよびドメインにログインできません。これは、ID 情報に SSSD を使用するクライアントアプリケーションにも影響があります。
この問題を回避するには、UID または GID が変更されても SSSD キャッシュをクリアし、ユーザーが再度ログインできるようにします。たとえば、指定されたユーザーの SSSD キャッシュを削除するには、以下のように sss_cache ユーティリティーを使用します。
[root@server ~]# sss_cache -u user

第15章 ユーザーおよびグループスキーマ

ユーザーエントリーは作成時に自動的に特定の LDAP オブジェクトクラスが割り当てられ、これにより特定の属性が利用可能になります。LDAP 属性を使用して、情報がディレクトリーに保存されます。(詳細は、『Directory 『Server Deployment Guide』および『Directory』 『Server Schema Reference』』 で説明されています。)

表15.1 デフォルトの Identity Management ユーザーオブジェクトクラス

オブジェクトクラス 詳細
ipaobject
ipasshuser
IdM オブジェクトクラス
person
organizationalperson
inetorgperson
inetuser
posixAccount
人物のオブジェクトクラス
krbprincipalaux
krbticketpolicyaux
Kerberos のオブジェクトクラス
mepOriginEntry Managed エントリー (テンプレート) のオブジェクトクラス
ユーザーエントリーには多くの利用可能な属性があります。手動で設定されるものや、特定の値が設定されてない場合はデフォルト値を元に設定されるものもあります。その属性に UI やコマンドライン引数がない場合でも、表15.1「デフォルトの Identity Management ユーザーオブジェクトクラス」 のオブジェクトクラスで使用できる属性を追加するオプションもあります。さらに、デフォルトの属性で生成または使用されている値は、「デフォルトのユーザーおよびグループ属性の指定」 のように設定できます。

表15.2 デフォルトの Identity Management ユーザー属性

UI フィールド コマンドラインオプション 必須、任意またはデフォルト[a]
User login username 必須
First name --first 必須
Last name --last 必須
Full name --cn Optional
Display name --displayname Optional
Initials --initials デフォルト
Home directory --homedir デフォルト
GECOS field --gecos デフォルト
Shell --shell デフォルト
Kerberos プリンシパル --principal デフォルト
メールアドレス --email Optional
Password --password[b] 任意
User ID number --uid デフォルト
グループ ID 番号 --gidnumber デフォルト
Street address --street Optional
City --city Optional
State/Province --state Optional
Zip code --postalcode Optional
Telephone number --phone Optional
Mobile telephone number --mobile Optional
Pager number --pager Optional
Fax 番号 --fax Optional
Organizational unit --orgunit Optional
Job title --title Optional
Manager --manager Optional
Car license --carlicense Optional
--noprivate Optional
SSH Keys --sshpubkey Optional
Additional attributes --addattr Optional
部門番号 --departmentnumber Optional
従業員番号 --employeenumber Optional
従業員タイプ --employeetype Optional
言語の設定 --preferredlanguage Optional
[a] 必須の属性は、すべてのエントリーで設定する必要があります。オプションの属性を設定できますが、特定の値が指定されない限り、デフォルトの属性は事前に定義された値で自動的に追加されます。
[b] スクリプトは、引数の値を受け付けずに、新たなパスワードを要求します。

15.1. デフォルトのユーザーおよびグループスキーマの変更

ユーザーおよびグループのエントリーに使用されるオブジェクトクラスおよび属性を追加または変更できます(15章ユーザーおよびグループスキーマ)。
IdM 設定は、オブジェクトクラスが変更されると以下の確認を行います。
  • すべてのオブジェクトクラスとそれらの指定された属性を LDAP サーバーが認識していること。
  • エントリーに設定されたデフォルトの属性はすべて、設定済みのオブジェクトクラスにサポートされていること。
ただし、IdM スキーマの検証には限界があります。最も重要なのは、IdM サーバーは定義済みユーザーもしくはグループオブジェクトクラスに IdM エントリーで必要なオブジェクトクラスすべてが含まれているかどうかを確認しないという点です。たとえば、すべての IdM エントリーには ipaobject オブジェクトクラス が必要です。しかし、ユーザーもしくはグループスキーマが変更されると、このオブジェクトクラスが含まれているかどうかをサーバーは検証しません。このオブジェクトクラスが誤って削除されると、それ以降のエントリー追加操作は失敗することになります。
また、すべてのオブジェクトクラス変更は、漸増的ではなくアトミックです。変更があると毎回、デフォルトのオブジェクトクラス一覧全体を定義する必要があります。たとえば、企業が従業員の誕生日や就業開始日などの情報を保存するためのカスタムのオブジェクトクラスを作成したとします。管理者は単にカスタムのオブジェクトクラスをリストに追加することはできません。新規オブジェクトクラスに加えて 現行のデフォルトのオブジェクトクラス一覧全体を設定する必要があります。設定を更新する際は常に、既存のデフォルトのオブジェクトクラスを含める必要があります。これを含めないと現行設定が上書きされ、パフォーマンスに関する重大な問題が発生することになります。

15.2. カスタムのオブジェクトクラスを新規ユーザーエントリーに適用する

ユーザーおよびグループアカウントは、エントリーに適用された定義済みの LDAP オブジェクトクラスセットで作成されます。オブジェクトクラスに属する属性は、ユーザーエントリーに追加することができます。
標準および IdM 固有の LDAP オブジェクトクラスではほとんどのデプロイメントシナリオに対応していますが、管理者はカスタム属性を使用してカスタムオブジェクトクラスを作成できます。管理者がデフォルトのオブジェクトクラスの一覧を変更した後に、新しいエントリーにはカスタムオブジェクトクラスが含まれますが、古いエントリーは自動的に変更されないことに注意してください。

15.2.1. Web UI での操作

  1. カスタムスキーマ要素をすべて、Identity Management が使用する 389 Directory Server インスタンスに追加します。スキーマ要素の追加については、『 Directory Server Administrator's Guide』の「スキーマ」の章 で説明します。
  2. IPA Server タブを開きます。
  3. Configuration サブタブを選択します。
  4. User Options エリアまでスクロールします。

    図15.1 サーバー設定のユーザーオプション

    サーバー設定のユーザーオプション
  5. ユーザーエリアの下部に、Add をクリックして、別のオブジェクトクラスの新規フィールドを追加します。
    重要
    設定の更新時は、常に既存のデフォルトオブジェクトクラスを追加してください。これらを含めないと、現行設定は上書きされます。Identity Management に必要なオブジェクトクラスが含まれていない場合には、これ以降にエントリーの追加を試みると、オブジェクトクラス違反で失敗します。

    図15.2 デフォルトのユーザーオブジェクトクラスの変更

    デフォルトのユーザーオブジェクトクラスの変更
  6. 変更が完了したら、Configuration ページ上部の Save をクリックします。

15.2.2. コマンドラインでの操作

  1. カスタムスキーマ要素をすべて、Identity Management が使用する 389 Directory Server インスタンスに追加します。スキーマ要素の追加については、『 Directory Server Administrator's Guide』の「スキーマ」の章 で説明します。
  2. エントリーに追加するオブジェクトクラス一覧に新規オブジェクトクラスを追加します。ユーザーのオブジェクトクラスのオプションは --userobjectclasses です。
    重要
    設定の更新時は、常に既存のデフォルトオブジェクトクラスを追加してください。これらを含めないと、現行設定は上書きされます。Identity Management に必要なオブジェクトクラスが含まれていない場合には、これ以降にエントリーの追加を試みると、オブジェクトクラス違反で失敗します。
    すべてのオブジェクトクラスは、オブジェクトクラスの一覧に含める必要があります。config-mod コマンドで渡される情報は、以前の値を上書きします。これは、各オブジェクトクラスに --userobjectclasses 引数を指定するか 、{attr1,attr2,attr3} などのスペースなしで中括弧内ですべてのオブジェクトクラスを一覧表示することで実行できます。特に、長いリストで、複数のオプションよりも中括弧を簡単に使用できます。たとえば、以下のようになります。
    [bjensen@server ~]$ ipa config-mod --userobjectclasses={top,person,organizationalperson,inetorgperson,inetuser,posixaccount,krbprincipalaux,krbticketpolicyaux,ipaobject,ipasshuser,employeeinfo}
注記
中括弧オプションを使用するには 、拡張機能を オンに切り替える必要があります。この機能を有効にするには、set コマンドを使用します。
# set -o braceexpand

15.3. カスタムのオブジェクトクラスを新規グループエントリーに適用する

ユーザーエントリーの場合と同様に、管理者はカスタム属性を使用してカスタムオブジェクトクラスを作成できます。オブジェクトクラスを IdM サーバー設定に追加すると、これらは自動的に追加されます。管理者がデフォルトのオブジェクトクラスの一覧を変更した後に、新しいエントリーにはカスタムオブジェクトクラスが含まれますが、古いエントリーは自動的に変更されないことに注意してください。

15.3.1. Web UI での操作

  1. カスタムスキーマ要素をすべて、Identity Management が使用する 389 Directory Server インスタンスに追加します。スキーマ要素の追加については、『 Directory Server Administrator's Guide』の「スキーマ」の章 で説明します。
  2. IPA Server タブを開きます。
  3. Configuration サブタブを選択します。
  4. Group Options エリアまでスクロールします。

    図15.3 サーバー設定のグループオプション

    サーバー設定のグループオプション
  5. Add をクリックして、別のオブジェクトクラスの新規フィールドを追加します。
    重要
    設定の更新時は、常に既存のデフォルトオブジェクトクラスを追加してください。これらを含めないと、現行設定は上書きされます。Identity Management に必要なオブジェクトクラスが含まれていない場合には、これ以降にエントリーの追加を試みると、オブジェクトクラス違反で失敗します。
  6. 変更が完了したら、Configuration ページ上部の Save をクリックします。

15.3.2. コマンドラインでの操作

  1. カスタムスキーマ要素をすべて、Identity Management が使用する 389 Directory Server インスタンスに追加します。スキーマ要素の追加については、『 Directory Server Administrator's Guide』の「スキーマ」の章 で説明します。
  2. エントリーに追加するオブジェクトクラス一覧に新規オブジェクトクラスを追加します。グループのオブジェクトクラスのオプションは --groupobjectclasses です。
    重要
    設定の更新時は、常に既存のデフォルトオブジェクトクラスを追加してください。これらを含めないと、現行設定は上書きされます。Identity Management に必要なオブジェクトクラスが含まれていない場合には、これ以降にエントリーの追加を試みると、オブジェクトクラス違反で失敗します。
    すべてのオブジェクトクラスは、オブジェクトクラスの一覧に含める必要があります。config-mod コマンドで渡される情報は、以前の値を上書きします。これは、各オブジェクトクラスに --groupobjectclasses 引数を指定するか 、{attr1,attr2,attr3} などのスペースなしで中括弧内ですべてのオブジェクトクラスを一覧表示することで実行できます。特に、長いリストで、複数のオプションよりも中括弧を簡単に使用できます。たとえば、以下のようになります。
    [bjensen@server ~]$ ipa config-mod --groupobjectclasses={top,groupofnames,nestedgroup,ipausergroup,ipaobject,ipasshuser,employeegroup}

15.4. デフォルトのユーザーおよびグループ属性の指定

Identity Management は新規エントリーの作成時にテンプレートを使用します。
ユーザーの場合は、テンプレートは非常に特有です。Identity Management は、IdM ユーザーアカウントの複数のコア属性にデフォルト値を使用します。これらのデフォルトは、ユーザーアカウント属性(ホームディレクトリーの場所など)の実際の値を定義するか、ユーザー名の長さなどの属性値の形式を定義できます。これらの設定は、ユーザーに割り当てられるオブジェクトクラスも定義します。
グループの場合、テンプレートが定義するのは割り当てられたオブジェクトクラスのみです。
このデフォルトの定義はすべて、IdM サーバーの単一の設定エントリー(cn =ipaconfig,cn=etc,dc=example,dc=com)に含まれるものです
この設定は、ipa config-mod コマンドを使用して変更できます。

表15.3 デフォルトのユーザーパラメーター

フィールド コマンドラインオプション 説明
ユーザー名の最大長 --maxusername ユーザー名の最大文字数を設定します。デフォルト値は 32 です。
Root for home directories --homedirectory ユーザーのホームディレクトリーに使用するデフォルトのディレクトリーを設定します。デフォルト値は /home です。
Default shell --defaultshell ユーザーに使用するデフォルトのシェルを設定します。デフォルト値は /bin/sh です。
Default user group --defaultgroup 新規作成のアカウントを追加するデフォルトグループを設定します。デフォルト値は ipausers で、これは IdM サーバーのインストールプロセス時に自動的に作成されます。
Default e-mail domain --emaildomain 新規アカウントに基づいて電子メールアドレスを作成するために使用する電子メールドメインを設定します。デフォルトは IdM サーバードメインです。
Search time limit --searchtimelimit サーバー検索結果を返すまでに費やす最長時間を秒単位で設定します。
Search size limit --searchrecordslimit 返される検索結果の最大数を設定します。
User search fields --usersearch 検索文字列として使用可能なユーザーエントリー内のフィールドを設定します。記載される属性にはインデックスがその属性のために維持されるので、多く設定しすぎるとサーバーのパフォーマンスに影響が出る場合があります。
Group search fields --groupsearch 検索文字列として使用可能なグループエントリー内のフィールドを設定します。
Certificate subject base クライアント証明書用に発行先 DN を作成する際に使用するベース DN を設定します。これはサーバーのセットアップ時に設定されます。
Default user object classes --userobjectclasses IdM ユーザーアカウントの作成に使用するオブジェクトクラスを定義します。これは複数回呼び出すことができます。オブジェクトクラスの一覧は、コマンドの実行時に上書きされるため、指定する必要があります。
Default group object classes --groupobjectclasses IdM グループアカウントの作成に使用するオブジェクトクラスを定義します。これは複数回呼び出すことができます。オブジェクトクラスの一覧は、コマンドの実行時に上書きされるため、指定する必要があります。
Password expiration notification --pwdexpnotify パスワードの有効期限が切れる何日前にサーバーが通知を送信するかを設定します
Password plug-in features ユーザーが使用可能なパスワードの形式を設定します。

15.4.1. Web UI で属性を表示する

  1. IPA Server タブを開きます。
  2. Configuration サブタブを選択します。
  3. 設定エントリーは、全検索の制限、ユーザーテンプレート、およびグループテンプレートの 3 つのセクションで表示されます。

    図15.4 検索での制限設定

    検索での制限設定

    図15.5 user 属性

    user 属性

    図15.6 グループ属性

    グループ属性

15.4.2. コマンドラインでの属性表示

config-show コマンドは、すべての新規ユーザーアカウントに適用される現在の設定を表示します。デフォルトでは、最も一般的な属性のみが表示されます。設定 をすべて表示するには --all オプションを使用します。
[bjensen@server ~]$ kinit admin
[bjensen@server ~]$ ipa config-show --all
dn: cn=ipaConfig,cn=etc,dc=example,dc=com
Maximum username length: 32
Home directory base: /home
Default shell: /bin/sh
Default users group: ipausers
Default e-mail domain: example.com
Search time limit: 2
Search size limit: 100
User search fields: uid,givenname,sn,telephonenumber,ou,title
Group search fields: cn,description
Enable migration mode: FALSE
Certificate Subject base: O=EXAMPLE.COM
Default group objectclasses: top, groupofnames, nestedgroup, ipausergroup, ipaobject
Default user objectclasses: top, person, organizationalperson, inetorgperson, inetuser, posixaccount, krbprincipalaux, krbticketpolicyaux, ipaobject, ipasshuser
Password Expiration Notification (days): 4
Password plugin features: AllowNThash
SELinux user map order: guest_u:s0$xguest_u:s0$user_u:s0$staff_u:s0-s0:c0.c1023$unconfined_u:s0-s0:c0.c1023
Default SELinux user: unconfined_u:s0-s0:c0.c1023
Default PAC types: MS-PAC, nfs:NONE
cn: ipaConfig
objectclass: nsContainer, top, ipaGuiConfig, ipaConfigObject

第16章 サービスの管理

ホスト上で実行されるサービスには、IdM ドメインに属するものもあります。Kerberos プリンシパルまたは SSL 証明書のいずれか (またはこれら両方) を保存できるサービスは、IdM サービスとして設定できます。IdM ドメインにサービスを追加すると、そのサービスはドメインから SSL 証明書やキータブを要求することができます。(証明書の公開鍵のみがサービスレコードに保存されます。秘密鍵はサービスのローカルになります。)
IdM ドメインは、共通の ID 情報、共通ポリシー、および共有サービスを使用して、マシン間で共通性を確立します。ドメインのクライアントとしてのドメイン機能に属するマシンです。これは、ドメインが提供するサービスを使用することを意味します。IdM ドメイン( 1章Red Hat Identity Management の概要で説明されているように)は、マシン専用の 3 つの主なサービスを提供します。
  • DNS
  • Kerberos
  • 証明書管理

16.1. サービスエントリーおよびキータブの追加と編集

ホストエントリーの場合と同様に、ホストのサービスエントリー (およびドメインに属するホスト上のサービス) は手動で IdM ドメインに追加する必要があります。これは 2 段階のプロセスで、最初にサービスエントリーを作成し、次にそのサービスがドメインへのアクセスに使用するキータブを作成します。
デフォルトでは、Identity Management は HTTP キータブを /etc/httpd/conf/ipa.keytab に保存します。
注記
このキータブは、Web UI に使用します。キーが ipa.keytab に保存され、そのキータブファイルを削除すると、元のキーも削除されるため、IdM Web UI は機能しなくなります。
Kerberos に対応させる必要のある各サービスで、同様の場所を指定できます。特定の場所は使用できませんが、ipa-getkeytab を使用する場合は、/etc/krb5.keytab の使用を避ける必要があります。このファイルにはサービス固有のキータブを含めるべきではありません。各サービスはキータブを特定の場所に保存し、そのサービスのみがキータブにアクセスできるようにアクセス権限 (場合によっては追加で SELinux ルール) を設定します。

16.1.1. Web UI でのサービスとキータブの追加

  1. Identity タブを開き、Services サブタブを選択します。
  2. サービス一覧の上部にある Add ボタンをクリックします。
  3. ドロップダウンメニューからサービスタイプを選択し、名前を付けます。
  4. サービスが実行されている IdM ホストのホスト名を選択します。ホスト名を使用して、完全なサービスプリンシパル名を構築します。
  5. Add ボタンをクリックして、新しいサービスプリンシパルを保存します。
  6. ipa-getkeytab コマンドを使用して、サービスプリンシパルに対して新しいキータブを生成し、割り当てます。
    [root@ipaserver ~]# # ipa-getkeytab -s ipaserver.example.com -p HTTP/server.example.com -k /etc/httpd/conf/krb5.keytab -e aes256-cts
    • レルム名はオプションです。IdM サーバーは、設定される Kerberos レルムを自動的に追加します。別のレルムは指定できません。
    • ホスト名は、Kerberos と連携するため、DNS A レコードに対して解決する必要があります。--force フラグを使用して強制的にプリンシパルを作成することができます。
    • -e 引数には、キータブに含める暗号化タイプの一覧を追加できます。これは、デフォルトの暗号化タイプより優先されます。エントリーの一覧は、同じコマンド呼び出しでオプションを複数回使用するか 、--option={val1,val2,val3} などの中括弧内にオプションを一覧表示して設定できます。
    警告
    新たなキーを作成すると、指定されたプリンシパルのシークレットがリセットされます。つまり、そのプリンシパルの他のキータブすべてが無効になります。

16.1.2. コマンドラインでのサービスとキータブの追加

  1. サービスプリンシパルを作成します。サービスは、service/FQDN などの名前で認識されます。
    # ipa service-add serviceName/hostname
    たとえば、以下のようになります。
    $ ipa service-add HTTP/server.example.com
    -------------------------------------------------------
    Added service "HTTP/server.example.com@EXAMPLE.COM"
    -------------------------------------------------------
      Principal: HTTP/server.example.com@EXAMPLE.COM
      Managed by: ipaserver.example.com
    
  2. ipa-getkeytab コマンドを使用して、サービスキータブファイルを作成します。このコマンドは、IdM ドメイン内のクライアント上で実行します。(実際には、IdM サーバーまたはクライアント上でコマンドを実行して、キーを適切なマシンにコピーできます。ただし、サービスが作成されるマシン上でこのコマンドを実行することが最もシンプルな方法です。)
    このコマンドには、Kerberos サービスプリンシパル(-p)、IdM サーバー名(-s)、書き込みするファイル(-k)、および暗号化方法(-e)が必要です。キータブをサービスの適切なディレクトリーにコピーしてください。
    以下に例を示します。
    # ipa-getkeytab -s server.example.com -p HTTP/server.example.com -k /etc/httpd/conf/krb5.keytab -e aes256-cts
    • レルム名はオプションです。IdM サーバーは、設定される Kerberos レルムを自動的に追加します。別のレルムは指定できません。
    • ホスト名は、Kerberos と連携するため、DNS A レコードに対して解決する必要があります。--force フラグを使用して強制的にプリンシパルを作成することができます。
    • -e 引数には、キータブに含める暗号化タイプのコンマ区切りリストを含めることができます。これは、デフォルトの暗号化タイプより優先されます。エントリーの一覧は、同じコマンド呼び出しでオプションを複数回使用するか 、--option={val1,val2,val3} などの中括弧内にオプションを一覧表示して設定できます。
    警告
    ipa-getkeytab コマンドは、指定されたプリンシパルのシークレットをリセットします。つまり、そのプリンシパルの他のキータブすべてが無効になります。

16.2. クラスタサービスの設定

IdM サーバーは、クラスターに対応していません。ただし、Kerberos キーを参加サービスすべてにわたって同期させ、ホスト上で実行中のサービスをクライアントが使用する名前に対応するように設定すると、クラスタサービスを IdM の一部として設定きます。
  1. クラスター内の全ホストを IdM ドメインに登録します。
  2. サービスプリンシパルを作成し、必要なキータブを生成します。
  3. /etc/krb5.keytab のホストキータブなど、ホスト上のサービスに設定されたキータブをすべて収集します。
  4. ktutil コマンドを使用して、すべてのキータブファイルのコンテンツを含む単一のキータブファイルを作成します。
    1. 各ファイルで rkt コマンドを使用して、そのファイルからキーを読み取ります。
    2. wkt コマンドを使用して、新しいキータブファイルに読み込まれたキーをすべて書き込みます。
  5. 各ホスト上のキータブファイルを新たに作成した結合キータブファイルで置き換えます。
  6. この時点で、このクラスター内の各ホストは他のホストに偽装することができます。
  7. サービスによっては、失敗したサービスを使ってホスト名をリセットしないクラスターメンバーに対応するために追加の設定が必要です。
    • sshd の場合は、/etc/ssh/sshd_configGSSAPIStrictAcceptorCheck no を設定します。
    • mod_auth_kerb の場合には/etc/httpd/conf.d/auth_kerb.confKrbServiceName Any を設定します。
注記
SSL サーバーの場合には、クライアントがクラスター化したホストに接続する時に、サーバー証明書の発行先名または代わりの発行先名が正しく表示される必要があります。可能であれば、全ホスト間で秘密キーを共有してください。
各クラスターメンバーに、他のクラスターメンバーすべての名前を含んでいる発行先代替名が含まれている場合、それでクライアントの接続要件が満たされます。

16.3. 複数サービスでの同一サービスプリンシパルの使用

クラスター内では、異なるマシンに分散している複数サービスに同一のサービスプリンシパルを使用することができます。
  1. ipa-getkeytab コマンドを使用してサービスプリンシパルを取得します。
    # ipa-getkeytab -s kdc.example.com -p HTTP/server.example.com -k /etc/httpd/conf/krb5.keytab -e aes256-cts
  2. 複数サーバーまたはサービスに同一ファイルを使用するよう指示するか、必要に応じてそのファイルを個別サーバーにコピーします。

16.4. 複数のサーバーの既存のキータブの取得

クラスター環境など、一部のシナリオでは、異なるマシンによって 1 つの共通ホスト名で表現されるサービスに同じキータブファイルが必要になります。IdM コマンドを使用して、各ホストで同じキータブを取得できます。
一般的なホスト名とサービスプリンシパルを準備するには、IdM サーバーで次のコマンドを実行します。
  1. admin ユーザーとして認証します。
    [root@ipaserver ~]# kinit admin
  2. このホスト名を共有するすべての IP アドレスに共通正引き DNS レコードを追加します。
    [root@ipaserver ~]# ipa dnsrecord-add idm.example.com cluster --a-rec={192.0.2.40,192.0.2.41}
      Record name: cluster
        A record: 192.0.2.40, 192.0.2.41
  3. 共通の DNS 名の新規ホストエントリーオブジェクトを作成します。
    [root@ipaserver ~]# ipa host-add cluster.idm.example.com
    ------------------------------------
    Added host "cluster.idm.example.com"
    ------------------------------------
      Host name: cluster.idm.example.com
      Principal name: host/cluster.idm.example.com@IDM.EXAMPLE.COM
      Password: False
      Keytab: False
      Managed by: cluster.idm.example.com
  4. ホストのサービスプリンシパルを追加します。
    [root@ipaserver ~]# ipa service-add HTTP/cluster.idm.example.com
    ------------------------------------------------------------
    Added service "HTTP/cluster.idm.example.com@IDM.EXAMPLE.COM"
    ------------------------------------------------------------
      Principal: HTTP/cluster.idm.example.com@IDM.EXAMPLE.COM
      Managed by: cluster.idm.example.com
  5. IdM からキータブを取得できるようにするサービスにホストを追加します。
    [root@ipaserver ~]# ipa service-allow-retrieve-keytab HTTP/cluster.idm.example.com --hosts={node01.idm.example.com,node02.idm.example.com}
      Principal: HTTP/cluster.idm.example.com@IDM.EXAMPLE.COM
      Managed by: cluster.idm.example.com
      Hosts allowed to retrieve keytab: node01.idm.example.com, node02.idm.example.com
    -------------------------
    Number of members added 2
    -------------------------
  6. 1 つのホストに新規キータブを作成する権限を付与します。
    [root@ipaserver ~]# ipa service-allow-create-keytab HTTP/cluster.idm.example.com --hosts=node01.idm.example.com
    Principal: HTTP/cluster.idm.example.com@IDM.EXAMPLE.COM
    Managed by: cluster.idm.example.com
    Hosts allowed to retrieve keytab: node01.idm.example.com, node02.idm.example.com
    Hosts allowed to create keytab: node01.idm.example.com
    -------------------------
    Number of members added 1
    -------------------------
クライアントで、以下の手順を実行します。
  1. ホストの Kerberos キータブで認証します。
    # kinit -kt /etc/krb5.keytab
    1. 各パーミッションを付与したクライアントで、新しいキータブを生成し、ファイルに保存します。
      [root@node01 ~]# ipa-getkeytab -s ipaserver.idm.example.com -p HTTP/cluster.idm.example.com -k /tmp/client.keytab
    2. 他のすべてのクライアントで、- r オプションをコマンドに追加して、IdM サーバーから既存のキータブを取得します。
      [root@node02 ~]# ipa-getkeytab -r -s ipaserver.idm.example.com -p HTTP/cluster.idm.example.com -k /tmp/client.keytab
      警告
      -r オプションを省略すると、新しいキータブが生成されることに注意してください。これにより、このサービスプリンシパルについて以前に取得したキータブがすべて無効になります。

16.5. サービスエントリーの無効化および再有効化

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

16.5.1. サービスエントリーの無効化

サービスを無効にすると、ドメインユーザーは、サービスをドメインから完全に削除されない場合にはサービスにアクセスできなくなります。これは、service-disable コマンドを使用して実行できます。
サービスを無効にするには、サービスのプリンシパルを指定します。たとえば、以下のようになります。
[jsmith@ipaserver ~]$ kinit admin
[jsmith@ipaserver ~]$ ipa service-disable HTTP/server.example.com
重要
ホストエントリーを無効にすると、そのホストが無効になるだけではありません。そのホストで設定されているすべてのサービスも無効にします。

16.5.2. サービスの再有効化

サービスを無効にすると、現行のアクティブなキータブを強制終了することになります。キータブを削除すると、設定エントリーに触れることなく IdM ドメインから該当サービスが削除されます。
サービスを再度有効にするには、ipa-getkeytab コマンドを使用します。-s オプションは、キータブを要求する IdM サーバーを設定します。- p はプリンシパル名を指定します。- k はキータブを保存するファイルを提供します。
新規の HTTPキータブを要求する場合は、以下のようになります。
[root@ipaserver ~]# ipa-getkeytab -s ipaserver.example.com -p HTTP/server.example.com -k /etc/httpd/conf/krb5.keytab -e aes256-cts

第17章 ホストとサービスへのアクセス委任

本章のコンテキストで 管理するには、キータブおよび別のホストまたはサービスの証明書を取得できることを意味します。すべてのホストとサービスには managedby エントリーがあり、このエントリーはどのホストまたはサービスが管理できるかを一覧表示します。デフォルトでは、ホストはホスト自体とそのサービスすべてを管理できます。また、適切な委譲を更新したり、適切な managedby エントリーを指定して、ホストが他のホストや他のホスト上のサービスを管理できるようにすることも可能です。
IdM サービスは、そのサービス へのアクセス許可 が付与または委譲されている限り、どの IdM ホストからでも管理できます。同様に、ホストにはドメイン内の他のホストへの許可を委譲できます。

図17.1 ホストおよびサービスの委譲

ホストおよびサービスの委譲
注記
managedBy エントリーを介して別のホストに権限が委譲されている場合、そのホスト上の全サービスの管理を委譲されたわけではありません。委譲は個別に行われる必要があります。

17.1. サービス管理の委譲

service-add-host ユーティリティーを使用してサービスの制御をホストに委譲します。
# ipa service-add-host principal --hosts=hostname
サービスの委譲には、以下の 2 つの部分があります。
  • principal 引数を使用したプリンシパル の指定
  • --hosts オプションを使用して、制御でホストを特定します。
たとえば、以下のようになります。
[root@server ~]# ipa service-add HTTP/web.example.com
[root@server ~]# ipa service-add-host HTTP/web.example.com --hosts=client1.example.com
ホストに権限が委譲されると、ホストプリンシパルを使ってサービスを管理できます。
[root@client1 ~]# kinit -kt /etc/krb5.keytab host/client1.example.com
[root@client1 ~]# ipa-getkeytab -s server.example.com -k /tmp/test.keytab -p HTTP/web.example.com
Keytab successfully retrieved and stored in: /tmp/test.keytab
このサービスのチケットを作成するには、委譲された認証局を持つホストに証明書要求を作成します。
[root@client1]# kinit -kt /etc/krb5.keytab host/client1.example.com
[root@client1]# openssl req -newkey rsa:2048 -subj '/CN=web.example.com/O=EXAMPLE.COM' -keyout /etc/pki/tls/web.key -out /tmp/web.csr -nodes
Generating a 2048 bit RSA private key
.............................................................+++
............................................................................................+++
Writing new private key to '/etc/pki/tls/private/web.key'
cert-request ユーティリティーを使用してサービスエントリーを作成し、証明書情報を読み込みます。
[root@client1]# ipa cert-request --principal=HTTP/web.example.com web.csr
Certificate: MIICETCCAXqgA...[snip]
Subject: CN=web.example.com,O=EXAMPLE.COM
Issuer: CN=EXAMPLE.COM Certificate Authority
Not Before: Tue Feb 08 18:51:51 2011 UTC
Not After: Mon Feb 08 18:51:51 2016 UTC
Serial number: 1005
証明書要求の作成と ipa cert-request の使用方法は、「ユーザー、ホスト、またはサービスの新規証明書の要求」 を参照してください。

17.2. ホスト管理の委譲

ホストには、host-add-managedby ユーティリティーを使用して、他のホストに対する権限が委譲されます。これにより、managedby エントリーが作成されます。managedby エントリーが作成されると、ホストが権限を委譲したホストのキータブを取得できます。
  1. 管理者ユーザーとしてログインします。
    [root@server ~]# kinit admin
  2. managedby エントリーを追加します。たとえば、以下は権限を client2 から client 1 に委譲します。
    [root@server ~]# ipa host-add-managedby client2.example.com --hosts=client1.example.com
  3. ホスト client1 としてチケットを取得します。
    [root@client1 ~]# kinit -kt /etc/krb5.keytab host/client1.example.com
    
  4. client2 の keytab を取得します。
    [root@client1 ~]# ipa-getkeytab -s server.example.com -k /tmp/client2.keytab -p host/client2.example.com
    Keytab successfully retrieved and stored in: /tmp/client2.keytab
    

17.3. Web UI を使ったホストまたはサービス管理の委譲

IdM Web UI の各ホストおよびサービスエントリーには、どのホストがそのホストやサービスの管理を委譲されているかを示す設定タブがあります。
  1. Identity タブを開き、Hosts または Services サブタブを選択します。
  2. 委譲管理の付与先となる ホストもしくはサービス名をクリックします。
  3. ホストまたはサービスエントリーの右端にある Hosts サブタブをクリックします。これは、選択したホストまたは サービスを管理できる ホストを一覧表示するタブです。

    図17.2 ホストのサブタブ

    ホストのサブタブ
  4. 一覧上部にある Add をクリックします。
  5. ホストまたはサービスの管理を委譲するホスト名の横にあるチェックボックスをクリックします。右矢印ボタンをクリックして、> をクリックして選択ボックスにホストを移動します。

    図17.3 ホスト/サービス委譲管理

    ホスト/サービス委譲管理
  6. 追加 ボタンをクリックして選択ボックスを閉じ、委譲設定を保存します。

17.4. 委譲サービスへのアクセス

サービスおよびホストの両方でクライアントに権限が委譲されている場合には、ローカルマシンでそのプリンシパルのキータブを取得できます。サービスの場合には、service/hostname@REALM という形式になります。ホストの場合には、サービスは host です。
kinit-k オプションを使用してキータブを読み込み、- t オプションを使用してキータブを指定します。たとえば、以下のようになります。
ホストにアクセスするには、以下を実行します。
[root@server ~]# kinit -kt /etc/krb5.keytab host/ipa.example.com@EXAMPLE.COM
サービスにアクセスするには以下のコマンドを実行します。
[root@server ~]# kinit -kt /etc/httpd/conf/krb5.keytab HTTP/ipa.example.com@EXAMPLE.COM

第18章 ID ビュー

ID ビューを使用すると、POSIX ユーザーまたはグループ属性に新しい値を指定でき、新しい値が適用されるクライアントホストを 1 つまたは複数定義できます。
たとえば、ID ビューを使用して以下を行うことができます。
重要
ID ビューは、IdM サーバーではなく、IdM クライアントにのみ適用されます。

SSSD パフォーマンスに対する潜在的な影響

ID ビューを適用すると、特定の最適化と ID ビューが同時に実行できないため、SSSD パフォーマンスに悪影響を及ぼす可能性があります。たとえば、ID ビューは、SSSD がサーバー上でグループを検索するプロセスの最適化を防ぎます。
  • ID ビューを使用して、グループ名が上書きされる場合に、SSSD は、グループメンバー名の返された一覧のすべてのメンバーを確認する必要があります。
  • ID ビューがないと、SSSD は、グループオブジェクトのメンバー属性からのみユーザー名を収集します。
このネガティブは、SSSD キャッシュが空であるか、またはキャッシュをクリアした後にほぼ影響します。これにより、すべてのエントリーが無効になります。

関連情報

ID ビューには、Active Directory に関連する環境におけるいくつかのユースケースもあります。詳細は、『 『Windows 統合ガイド』の「 ID ビューおよび既存の環境の信頼への移行 」の章を参照してください』。

18.1. ID ビューが上書きできる属性

ID ビューは、ユーザーおよびグループ ID の上書きで構成されます。上書きにより、新しい属性値を定義します。
ユーザーおよびグループ ID の上書きは、以下の属性の新しい値を定義できます。
ユーザー属性
  • ログイン名 (uid)
  • GECOS エントリー (gecos)
  • UID 番号(uidNumber)
  • GID 番号(gidNumber)
  • ログインシェル(loginShell)
  • ホームディレクトリー(homeDirectory)
  • SSH 公開鍵(ipaSshPubkey)
  • Certificate (userCertificate)
グループ属性
  • グループ名(cn)
  • グループの GID 番号(gidNumber)

18.2. ID ビューのコマンドのヘルプの取得

ID ビューおよび上書きの管理に使用するコマンドをすべて表示するには、次のコマンドを実行します。
$ ipa help idviews
特定のコマンドの詳細なヘルプを表示するには、コマンドに --help オプションを追加します。
$ ipa idview-add --help

18.3. 異なるホストにあるユーザーアカウントの異なる属性値の定義

管理者は、ユーザーアカウントによって使用される属性値を上書きして、これらの ID ビューを別のクライアントホストに適用する ID ビューを複数作成できます。例: 異なるホストで認証する場合に、異なる SSH 公開鍵を使用するようにサービスアカウントが設定されます。
本セクションでは、以下の手順について説明します。
この手順では、host 1.example.com という名前のクライアントホストの ID ビューを作成する方法を説明します。他のホストの属性値を上書きするには、手順を使用して、ホストごとに複数の ID ビューを作成します。
手順では、以下を前提としています。
  • user は、属性を上書きする必要があるユーザーアカウントです
  • host1.example.com は、ID ビューが適用されるホストです。
重要
新しい ID ビューを作成したら、ID ビューが適用されるすべてのクライアントで SSSD を再起動します。
新しい ID ビューが UID または GID を変更した場合は、このクライアントの SSSD キャッシュも消去します。

18.3.1. Web UI: 特定のホストの属性値の上書き

ID ビューを管理するには、最初に IdM 管理者として IdM Web UI にログインします。

新規 ID ビューの作成

  1. Identity タブで、ID Views サブタブを選択します。
  2. Add をクリックして、ID ビューの名前を指定します。

    図18.1 ID ビューの追加

    ID ビューの追加
  3. Add をクリックして確定します。
新しい ID ビューが ID ビューのリストに表示されます。

図18.2 ID ビューの一覧

ID ビューの一覧

ID ビューへのユーザーオーバーライドの追加

  1. ID ビューのリストで、ID ビューの名前をクリックします。

    図18.3 ID ビューの編集

    ID ビューの編集
  2. Users タブで Add をクリックして、ユーザーの上書きを追加します。
  3. 上書きする属性値を持つユーザーアカウントを選択し、Add をクリックします。
ユーザーの上書きが example_for_host1 ID view ページに表示されます。

図18.4 上書きの一覧

上書きの一覧

上書きする属性の指定

  1. 属性値の変更に使用する上書きをクリックします。

    図18.5 上書きの編集

    上書きの編集
  2. 属性の新しい値を定義します。
    たとえば、ユーザーアカウントが使用する SSH 公開鍵を上書きするには、以下を実行します。
    1. SSH public keys: Add をクリックします

      図18.6 SSH 公開鍵の追加

      SSH 公開鍵の追加
    2. 公開鍵に貼り付けます。
    注記
    IdM に SSH キーを追加する方法は、「ユーザーの公開 SSH 鍵の管理」 を参照してください。
  3. Save をクリックして上書きを更新します。

ID ビューの特定ホストへの適用

  1. ID ビューのリストで、ID ビューの名前をクリックします。

    図18.7 ID ビューの編集