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 の使用

Marc Muehlfeld

Red Hat Customer Content Services

Filip Hanzelka

Red Hat Customer Content Services

Lucie Maňásková

Red Hat Customer Content Services

Aneta Šteflová Petrová

Red Hat Customer Content Services

Tomáš Čapek

Red Hat Customer Content Services

Ella Deon Ballard

Red Hat Customer Content Services

概要

ユーザーとマシンの両方にとって、ID とポリシーの管理はほとんどの企業環境における中核的な機能です。Identity Management は、ID ドメインを作成する方法を提供し、このドメインにより、マシンはドメインへの登録と、シングルサインオンおよび認証サービスに必要となる ID 情報に即座にアクセスすることができるようになります。また、承認およびアクセスを管理するポリシー設定も可能になります。
Red Hat Enterprise Linux Identity Management に関する他の機能およびサービスについての資料は、本ガイドのほかに以下のガイドがあります。

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

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

パート 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 統合ガイド を参照してください。
    Samba スイートを使用すると Linux マシンと Active Directory 環境との統合が可能になります。このスイートについての詳細は、『Windows 統合ガイド』 の Samba、Kerberos、および Winbind の使用の章を参照してください。サーバーとして Samba を使用する場合は、IdM ドメインへのサーバーの統合、IdM または信頼されている Active Directory に対する Samba サーバーへのユーザーの接続認証には対応していないことに注意してください。

1.1.1. IdM による利点

複数の Linux サーバーにおけるアイデンティティーおよびポリシーの管理
IdM なしの場合: 各サーバーが個別に管理されます。パスワードはすべてローカルマシンに保存されます。IT 管理者は各マシン上でユーザーを管理し、個別に認証および承認ポリシーを設定し、ローカルのパスワードを維持します。
IdM を使用する場合 - IT 管理者は以下が可能になります。
  • 一か所でアイデンティティ-の管理 - 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 および認証サーバー
基礎となるディレクトリーサーバーのテクノロジーは、Red Hat Directory Server と IdM で同じものです。ただし、IdM は ID 管理に最適化されています。これにより全般的な拡張性は制限されますが、シンプルな設定、リソース管理の自動化、ID 管理における効率性の向上などの利点がもたらされます。

関連資料

1.2. Identity Management ドメイン

Identity Management (IdM) ドメインは、同じ設定、ポリシー、および ID ストアを共有するマシンのグループで構成されます。プロパティーを共有することで、ドメイン内のマシンは相互に認識可能となり、共同操作ができるようになります。
IdM の観点からは、ドメインには以下のタイプのマシンが含まれます。
  • IdM サーバー。ドメインコントローラーとして機能します。
  • IdM クライアント。これはサーバーに登録されます。
IdM サーバーは、IdM クライアントとしてサーバー自体に登録されます。サーバーマシンはクライアントと同等の機能を提供します。
IdM は、Red Hat Enterprise Linux マシンを IdM サーバーおよびクライアントとしてサポートします。

注記

本ガイドでは、Linux 環境における IdM の使用について説明しています。Active Directory との統合に関する詳細情報は、Windows 統合ガイド を参照してください。

1.2.1. Identity Management サーバー

IdM サーバーは、ID およびポリシー情報の中央リポジトリーとして機能します。また、ドメインメンバーが使用するサービスもホストします。IdM は、IdM Web UI やコマンドラインユーティリティーなど、IdM 関連サービスをすべて 1 カ所で管理するための管理ツールセットを提供します。
IdM サーバーのインストールについての情報は、2章Identity Management サーバーのインストールとアンインストール を参照してください。
冗長性と負荷分散をサポートするために、ある IdM サーバーからこのサーバーのレプリカと呼ばれる別のサーバーにデータや設定を複製することができます。サーバーやレプリカは、クライアントに異なるサービスを提供するように設定することが可能です。IdM レプリカについての詳細情報は、4章Identity Management のレプリカのインストールとアンインストール を参照してください。

1.2.1.1. IdM サーバーでホストするサービス

以下のサービスのほとんどは、必ずしも IdM サーバー上にインストールする必要はありません。たとえば、認証局 (CA)、DNS サーバー、またはネットワークタイムプロトコル (NTP) サーバーなどのサービスは、IdM ドメイン外の外部サーバーにインストールすることができます。
Kerberos KDC
IdM は、Kerberos プロトコルを使ってシングルサインオンをサポートします。Kerberos を使用すると、ユーザーは正しいユーザー名とパスワードを 1 回提示するだけで済みます。この後は、システムが認証情報をプロンプトすることなく IdM サービスにアクセスできます。
LDAP ディレクトリーサーバー
IdM には内部の LDAP ディレクトリーサーバーが含まれており、ここには Kerberos 関連の情報、ユーザーアカウント、ホストエントリー、サービス、ポリシー、DNSなどの全 IdM 情報が保存されます。
LDAP ディレクトリーサーバーインスタンスは Red Hat Directory Server と同じテクノロジーをベースとしていますが、IdM 固有のタスクに調整されています。

注記

本ガイドでは、このコンポーネントを Directory Server と呼びます。
認証局
ほとんどのデプロイメントでは、統合済み認証局 (CA) が IdM サーバーとインストールされます。必要な証明書すべてを独自に作成し、提供する場合は、統合 CA なしでサーバーをインストールすることもできます。
  • 異なる CA 設定で IdM サーバーをインストールする詳細情報は、「CA 設定の決定」 を参照してください。

注記

本ガイドでは、実装の際にはこのコンポーネントを Certificate System と呼び、実装によるサービスに対応する際には証明局と呼びます。
スタンドアローンの Red Hat 製品 Red Hat Certificate System の詳細は、Product Documentation for Red Hat Certificate System を参照してください。
ドメインネームシステム (DNS)
IdM は、動的なサービス発見に DNS を使用します。IdM クライアントインストールユーティリティーは、DNS からの情報を使ってクライアントマシンを自動的に設定することができます。クライアントが IdM ドメインに登録されたら、DNS を使用してドメイン内の IdM サーバーとサービスを検索します。
ネットワークタイムプロトコルサーバー (NTP)
多くのサービスでは、特定の差異内でサーバーとクライアントが同一のシステムタイムを保持している必要があります。たとえば、Kerberos チケットはタイムスタンプを使ってその有効性を判断し、再生攻撃を防ぎます。サーバーとクライアントの時間の差異が許可された範囲内から逸脱すると、Kerberos チケットは無効になります。
デフォルトでは、IdM はネットワークタイムプロトコル (NTP) を使ってネットワークからクロックを同期します。NTP を使用すると、中央サーバーが権威クロックとして機能し、クライアントはこのサーバークロックに一致するようそれぞれの時間を同期します。サーバーのインストールプロセス中は、IdM サーバーは IdM ドメイン向けの NTP サーバーとして設定されます。

注記

仮想マシン上にインストールされた IdM サーバーで NTP サーバーを稼働すると、環境によっては時間が正確に同期されない場合があります。この潜在的な問題を避けるには、仮想マシン上にインストールされた IdM サーバーで NTP を実行しないでください。仮想マシン上における NTP サーバーの信頼性については、こちらのナレッジベースソリューションを参照してください。
Identity Management サーバーによるサービスの一元管理

図1.1 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
System Security Services Daemon (SSSD) は、認証情報をキャッシュするクライアント側のアプリケーションです。クライアントマシンでの SSSD の使用は必須のクライアント設定を簡素化するので、推奨されます。SSSD は、以下のような機能も提供します。
  • オフラインでのクライアント認証。中央 ID および認証ストアからの認証情報をローカルでキャッシュすることでこれを実現します。
  • 認証プロセスの一貫性の改善。オフライン認証用に中央アカウントとローカルユーザーアカウントの両方を維持する必要がないため。
  • sudo のような他のサービスとの統合。
  • ホストベースのアクセス制御 (HBAC) 承認
SSSD を使用すると、IdM 管理者は IdM サーバーで一括してすべてのアイデンティティー設定を定義できるようになります。IdM サーバーが利用できなくなったりクライアントがオフラインになった場合には、キャッシュによりローカルシステムは通常の認証作業を継続できます。
SSSD についての詳細情報は、システムレベルの認証ガイド を参照してください。SSSD は Windows Active Directory (AD) にも対応しています。AD での SSSD の使用については、Windows 統合ガイド を参照してください。
certmonger
certmonger サービスは、クライアント上の証明書を監視、更新します。これはシステム上のサービス向けに新規の証明書をリクエストすることができます。
certmonger についての詳細情報は、システムレベルの認証ガイド を参照してください。
IdM サービス間の対話

図1.2 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 で 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 Performance Tuning Guide』を参照してください。

2.1.3. システム要件

Identity Management は Red Hat Enterprise Linux 7 でサポートされています。DNS、Kerberos、または Directory Server などのサービスをカスタム設定していない、新規インストール直後のシステムに IdM サーバーをインストールします。

重要

パフォーマンスと安定性の理由から、Red Hat では、IPA; サーバー上にその他のアプリケーションやサービスのインストールを行わないことを推奨しています。例えば、特に LDAP オブジェクトの数が多ければ、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 の競合を避ける方法については、「システムレベルの認証ガイド」を参照してください。
IPv6 がシステムで有効になっている必要がある
IdM サーバーをインストールして実行するには、IPv6 がネットワーク上で有効になっている必要があります。Red Hat Enterprise Linux 7 システムではデフォルトで IPv6 が有効になることに留意してください。
IPv6 を無効にしている場合は、Red Hat ナレッジベースの Red Hat Enterprise Linux で IPv6 プロトコルを無効または有効にする を参照して有効にします。

注記

IPv6 は、カーネルで有効にする必要があり、少なくとも、ループバックインターフェースで有効化する必要があります。

2.1.4. FIPS 環境でのサーバーインストールの前提条件

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

    重要

    以下の点に注意してください。
    • FIPS モードを無効にしてインストールした既存の IdM サーバーで FIPS モードを有効にすることはできません。
    • FIPS モードが無効になっている既存の IdM サーバーに FIPS サポートを有効にした新規レプリカをインストールすることはできません。
Red Hat Enterprise Linux 7.3 以前を使用して設定した環境の場合:
  • IdM は、FIPS モードに対応していません。システム上で FIPS を無効化してから、IdM サーバー、またはレプリカをインストールし、インストール後も有効化しないでください。
FIPS モードに関する詳しい情報は『セキュリティーガイド』の「連邦情報処理標準 (FIPS: Federal Information Processing Standard)」を参照してください。

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

警告

以下の点については、特に注意してください。
  • テスト済みの機能する DNS サービスが利用可能であること。
  • サービスが適切に設定されていること。
この要件は統合 DNS サービスのある IdM サーバーと、DNS なしでインストールされた IdM サーバーの両方に該当します。DNS レコードは、LDAP ディレクトリーサービス、Kerberos、および Active Directory 統合の実行を含むほとんどすべての IdM ドメイン機能において必須のものです。
プライマリー DNS ドメインと Kerberos レルムはインストール後には変更できないことに注意してください。
サーバーのホストは、DNS サーバーが IdM 内で統合されているか外部にホストされているかに関わらず、DNS を適切に設定している必要があります。
Identity Management は、サービスレコードに別の DNS ドメインを使用します。DNS レベルでの競合を避けるために、名前が IdM Kerberos 名の小文字の DNS ドメインプライマリー IdM 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 コマンドラインツールから、IdM がまたは仲介されるサービスを探すとき、/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 所有のドメインの一部でない必要があります。信頼という観点から、この関連は、「レルムドメイン」を使用して管理されます。
クライアント自体が IdM 参加する一方で、Active Directory DNS ドメインからのホスト名を使用してユーザーが IdM クライアントにアクセスできるようにする設定については、『Windows 統合ガイド』 の Active Directory を SSSD のアイデンティティープロバイダーとして使用する を参照してください。

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

ホスト名は server.example.com のように完全修飾ドメイン名である必要があります。使用中のマシンのホスト名を確認するには、hostname ユーティリティーを使用します。
[root@server ~]# hostname
server.example.com
hostname の出力は、localhost または localhost6 になってはいけません。

重要

完全修飾ドメイン名は有効な DNS 名である必要があります。つまり、許可されるのは数字、アルファベット、ハイフン (-) のみです。ホスト名にアンダースコアのような他の文字があると、DNS エラーが発生します。また、ホスト名はすべて小文字を使用する必要があり、大文字は使用できません。
命名プラクティスに関する他の推奨事項については、Red Hat Enterprise Linux セキュリティーガイド を参照してください。
完全修飾ドメイン名は、ループバックアドレスに解決してはいけません。マシンの公開 IP アドレスに解決する必要があり、127.0.0.1 に解決してはいけません。

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

  1. サーバーの IP アドレスを取得します。ip addr show コマンドは、IPv4 と IPv6 の両方のアドレスを表示します。
    • IPv4 アドレスは、inet で始まる行に表示されます。以下の例では、設定済み IPv4 アドレスは 192.0.2.1 になります。
    • IPv6 アドレスは inet6 で始まる行に表示されます。scope global のある IPv6 のみがこの手順では関連してきます。以下の例では、返される IPv6 アドレスは 2001:DB8::1111 になります。
    [root@server ~]# ip addr show
    ...
    2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    	link/ether 00:1a:4a:10:4e:33 brd ff:ff:ff:ff:ff:ff
    	inet 192.0.2.1/24 brd 192.0.2.255 scope global dynamic eth0
    		valid_lft 106694sec preferred_lft 106694sec
    	inet6 2001:DB8::1111/32 scope global dynamic
     		valid_lft 2591521sec preferred_lft 604321sec
    	inet6 fe80::56ee:75ff:fe2b:def6/64 scope link
    	       valid_lft forever preferred_lft forever
  2. dig ユーティリティーにホスト名を加えて、正引き DNS 設定を確認します。
    1. dig +short server.example.com A コマンドを実行します。返される IPv4 アドレスは、ip addr show が返す IP アドレスと一致する必要があります。
      [root@server ~]# dig +short server.example.com A
      192.0.2.1
    2. dig +short server.example.com AAAA コマンドを実行します。コマンドがアドレスを返す場合は、ip addr show が返す IPv6 アドレスと一致する必要があります。
      [root@server ~]# dig +short server.example.com AAAA
      2001:DB8::1111

      注記

      AAAA レコードの出力が返されない場合でも、設定が間違っているわけではありません。出力がないということは、DNS 内でサーバーマシン向けに IPv6 アドレスが設定されていないというだけのことです。ネットワークで IPv6 プロトコルを使用する予定がない場合は、この状況でもインストールを続行できます。
  3. dig ユーティリティーに IP アドレスを加えて、逆引き DNS 設定 (PTR レコード) を確認します。
    1. dig +short -x IPv4 address コマンドを実行します。サーバーのホスト名が出力に表示される必要があります。例を示します。
      [root@server ~]# dig +short -x 192.0.2.1
      server.example.com
    2. 前のステップで dig +short -x server.example.com AAAA コマンドが IPv6 アドレスを返した場合は、dig を使って IPv6 アドレスもクエリします。ここでも、サーバーのホスト名が出力に表示される必要があります。例を示します。
      [root@server ~]# dig +short -x 2001:DB8::1111
      server.example.com

      注記

      前のステップで dig +short -x server.example.com AAAA コマンドが IPv6 アドレスを返さなかった場合は、AAAA レコードのクエリは何も出力しません。これは正常な動作で、設定が間違っていることを示すものではありません。
    前のステップで dig +short server.example.com が IP アドレスを返した場合でも、別のホスト名が表示されたりホスト名が表示されない場合は、逆引き DNS 設定が間違っていることになります。

DNS フォワーダーの標準準拠の確認

統合 DNS で IdM を設定する場合は、DNS Security Extensions (DNSSEC) 記録検証を使用することが推奨されます。その他のサーバーから署名付き D1983NS 記録を検証することで、なりすましアドレスから IdM インストールを保護することができます。ただし、DNSSEC 検証は、IdM を正常にインストールする際に必須となるわけではありません。
IdM インストーラーでは、デフォルトで DNSSEC 記録検証が有効化されます。DNSSEC を適切に設定したフォワーダーが必要です。インストールの際、IdM はグローバルフォワーダーをチェックします。フォワーダーが DNSSEC に対応していない場合、DNSSEC 検証はそのフォワーダーで無効化されます。
IdM DNS サーバーと使用するすべての DNS フォワーダーが Extension Mechanisms for DNS (EDNS0) と DNSSEC 規格に準拠するかどうかを検証するには:
$ dig +dnssec @IP_address_of_the_DNS_forwarder . SOA
コマンドの出力には、以下の情報が含まれます。
  • status: NOERROR
  • flags: ra
  • EDNS flags: do
  • ANSWER セクションには RRSIG レコードがある必要があります。
これらのいずれかがない場合は、使用している DNS フォワーダーのドキュメントをチェックして、EDNS0 と DNSSEC がサポートされかつ有効になっていることを確認してください。BIND サーバーの最新バージョンでは、/etc/named.conf ファイルで dnssec-enable yes; オプションが設定されている必要があります。
出力例は以下のようになります。
;; ->>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/HTTPS80、443TCP
LDAP/LDAPS389、636TCP
Kerberos88、464TCP および UDP
DNS53TCP および UDP
NTP123UDP

注記

IdM がポート 80 および 389 を使用していることについて心配は要りません。
  • ポート 80 (HTTP) は、オンライン証明書ステータスプロトコル (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 を使用してシステム上でポートを開く方法についての詳細は、『セキュリティーガイド』または firewall-cmd(1) man ページを参照してください。
  3. firewall-cmd 設定をリロードして、変更が直ちに反映されるようにします。
    # firewall-cmd --reload
    実稼働環境のシステムで firewalld を再読み込みすると、DNS 接続がタイムアウトされてしまう可能性があります。『Security Guide』の「コマンドラインインターフェース (CLI) を使ったファイアウォール設定のリロード」も参照してください。必要であれば、タイムアウトのリスクを回避し、実行中のシステム上で変更を固定するため、firewall-cmd コマンドの --runtime-to-permanent オプションを指定します。例:
    # firewall-cmd --runtime-to-permanent --add-port={80/tcp,443/tcp,389/tcp,636/tcp,88/tcp,88/udp,464/tcp,464/udp,53/tcp,53/udp,123/udp}
  4. これはオプションです。 ポートが現在使用可能であることを確認するには、nctelnet、または nmap のユーティリティーを使用してポートに接続するか、ポートスキャンを実行します。

注記

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

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

統合 DNS サービスなしでサーバーに必須のパッケージをインストールするには、以下を実行します。
# yum install ipa-server
統合 DNS サービスのあるサーバーに必須のパッケージをインストールするには、以下を実行します。
# yum install ipa-server ipa-server-dns

注記

ご自分のユースケースに DNS が適切かどうかを判断するには、「統合 DNS 使用の判断」 を参照してください。
ipa-server パッケージは自動的に以下のような他の必須のパッケージを依存関係としてインストールします。
  • Directory Server LDAP サービス向けの 389-ds-base
  • Kerberos サービス向けの krb5-server パッケージ
  • 各種の IdM 固有ツール

2.3. IdM サーバーのインストール: はじめに

注記

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

2.3.1. 統合 DNS 使用の判断

IdM は、統合 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 統合 DNS に委任できるのは IdM プライマリードメインのみになります。DNS ゾーンを 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]
承認クライアントのみが再帰クエリーを発行できるようにするには、適切なアクセス制御リスト (ACL) ステートメントをサーバー上の /etc/named.conf ファイルに追加します。例を示します。
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 のあるサーバー
これはほとんどのデプロイメントに適切なデフォルトの設定です。Certificate System は CA 署名証明書 を使用して IdM ドメイン内の証明書を作成し、これに署名します。

警告

Red Hat では、複数のサーバーに CA サービスをインストールしておくことを強く推奨しています。CA サービスを含む最初のサーバーのレプリカをインストールする方法についての情報は、「CA を設定したレプリカのインストール」 を参照してください。
CA が 1 つのサーバーにしかインストールされていないと、CA サーバーが故障した際に CA 設定が失われて回復できない恐れがあります。詳細については、「失われた CA サーバーの復旧」 を参照してください。
証明書を署名する IdM CA は、self-signed とも呼ばれるルート証明書も可能です。または、外部証明書でも署名可能です。
IdM CA を root CA とする
これがデフォルト設定になります。
この設定でサーバーをインストールする方法については、「統合 DNS のあるサーバーのインストール」「統合 DNS のなしでのサーバーのインストール」 を参照してください。
外部 CA を root CA とする
IdM CA は外部 CA の下位となります。ただし、IdM ドメインの証明書はすべて、Certificate System インスタンスが発行します。
外部 CA は、企業 CA や、Verisign や Thawte などのサードパーティー CA を利用できます。外部 CA はルート CA または下位 CA も利用できます。IdM ドメイン内で発行される証明書は、有効期間や発行できる証明書のドメインなど外部ルート証明書または中間証明書の属性が設定する制限の影響を受ける可能性があります。
外部にホストされている root CA のあるサーバーをインストールする方法については、「外部 CA を Root CA としてサーバーをインストールする手順」 を参照してください。
CA なしのサーバー
この設定オプションは、インフラストラクチャー内の制限により証明書サービスのあるサーバーをインストールできない場合に適しています。
インストール前に以下の証明書をサードパーティー機関にリクエストする必要があります。
  • LDAP サーバー証明書および秘密鍵
  • Apache サーバー証明書および秘密鍵
  • LDAP および Apache サーバー証明書を発行した CA の完全な CA 証明書チェーン
統合 IdM CA なしで証明書を管理しようとすると、多大なメンテナンス負担になります。たとえば、
  • 証明書の作成、アップロード、更新プロセスが手動になります。
  • 証明書の追跡に certmonger サービスが使用されません。このため、証明書の有効期限が迫っても警告が出されません。
統合 CA のないサーバーをインストールする方法については、「CA なしでのインストール」 を参照してください。

注記

CA なしで IdM をインストールする場合、CA サービスを後でインストールすることができます。既存の IdM ドメインに CA をインストールするには、「CA の既存の IdM ドメインへのインストール」 を参照してください。

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
よって、 not は、既存の DNS ゾーン、例えば別の DNS サーバーと重複するリバースゾーンを作成します。
非対話式インストールでは、--setup-dns オプションも追加してください。

例2.1 統合 DNS のあるサーバーのインストール

この手順では、以下のサーバーをインストールします。
  • 統合 DNS のあるサーバー
  • IdM CA を root 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 を入力してコマンドラインの指示に従います。
      インストールプロセスでフォワーダー IP アドレスがインストールされる IdM サーバーの /etc/named.conf ファイルに追加されます。
      • 転送ポリシーのデフォルト設定については、ipa-dns-install(1) man ページの --forward-policy の記述を参照してください。
      • 詳細は、「転送ポリシー」も参照してください。
    • DNS 転送を使用しない場合は、no と入力します。
  6. そのサーバーと関連する IP アドレスの DNS 逆引き (PTR) レコードを設定する必要性を確認するプロンプトが出されます。
    Do you want to search for missing reverse zones? [yes]:
    検索を実行して逆引きゾーンが見つかると、PTR レコードの逆引きゾーンを作成するかどうかを尋ねられます。
    Do you want to create reverse zone for IP 192.0.2.1 [yes]:
    Please specify the reverse zone name [2.0.192.in-addr.arpa.]:
    Using reverse zone(s) 2.0.192.in-addr.arpa.

    注記

    逆引きゾーンの管理に IdM を使用することはオプションです。外部 DNS サービスを使用することもできます。
  7. サーバー設定をする場合は、yes と入力します。
    Continue to configure the system with these values? [no]: yes
  8. インストールスクリプトにより、サーバーが設定されます。動作が完了するまで待ちます。
  9. 親ドメインからのDNS 委任を IdM 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 を root 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 を Root CA としてサーバーをインストールする手順

注記

どの DNS または CA 設定がご使用の環境に適切か分からない場合は、「統合 DNS 使用の判断」「CA 設定の決定」 を参照してください。
サーバーをインストールして、root CA として外部 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 証明書である必要があります。つまり、Basic Constraint が CA=true と設定されているか、Key Usage Extension が署名証明書に設定されて、証明書の署名が可能となっている必要があります。
  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 を使用して提供されるファイルには、厳密に 1 つのサーバー証明書と 1 つの秘密鍵が含まれている必要があります。--dirsrv-cert-file--http-cert-file を使用して提供されるファイルのコンテンツは同一であることがよくあります。
  • 必要に応じて 以下のオプションで与えられる、完全な CA 証明書チェーンを完成させる証明書ファイル:
    • --ca-cert-file。オプションを複数回にわたり追加可能
  • 必要に応じて、以下のオプションで与えられる、外部 Kerberos キー配布センター (KDC) PKINIT 証明書を提供するための証明書ファイル:
    • Kerberos KDC SSL 証明書と秘密鍵の --pkinit-cert-file
    • Kerberos KDC 秘密鍵のロックを解除するためのパスワードの --pkinit-pin
    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 オプションを使って root CA 証明書の PEM ファイルを指定していました。信頼できる CA は常に DS および HTTP サーバー証明書の発行者なので、これはもう不要になりました。今では IdM は、--dirsrv-cert-file--http-cert-file、および --ca-cert-file で指定される証明書からの root 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
    ----------------------------

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

注記

ドメインレベル 0 では、この手順は異なります。「レプリカの削除」を参照してください。

前提条件

  • 認証局 (CA)、鍵回復機関 (KRA)、または DNS セキュリティ拡張 (DNSSEC) サーバーとして機能するサーバーをアンインストールする前に、これらのサービスがドメインの別のサーバーで実行していることを確認している。

    警告

    CA、KRA、または DNSSEC サーバーとして機能する唯一のレプリカを削除すると、Identity Management 機能に深刻な不具合が生じる可能性があります。

手順

server.example.com のアンインストール手順:
  1. 別のサーバーで ipa server-del コマンドを使用して、トポロジーから server.example.com を削除します。
    [root@another_server ~]# ipa server-del server.example.com
  2. server.example.comipa-server-install --uninstall コマンドを使用します。
    [root@server ~]# ipa-server-install --uninstall
  3. server.example.com を参照するすべてのネームサーバー (NS) の DNS レコードが DNS ゾーンから削除されていることを確認します。使用する DNS が IdM で管理される統合 DNS か、外部 DNS かに関わらず、確認してください。

2.5. サーバーの名前変更

設定後には、IdM サーバーのホスト名は変更できませんが、別の名前のレプリカでサーバーを置き換えることはできます。
  1. 認証局、新たに必要なホスト名または IP アドレスを指定して、サーバーのレプリカを新たに作成します。これについては、4章Identity Management のレプリカのインストールとアンインストールに説明されています。
  2. 最初の IdM サーバーインスタンスを停止します。
    [root@old_server ~]# ipactl stop
  3. 他のレプリカやクライアントは変わらず動作していることを確認します。
  4. 「IdM サーバーのアンインストール」で説明されているように、最初の IdM サーバーをアンインストールします。


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

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

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

注記

IdM ドメインのクライアントおよびサーバーの詳細は「Identity Management ドメイン」を参照してください。

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

DNS 要件
適切な DNS の委譲を使用すること。IdM の DNS 要件に関する詳細は「ホスト名および DNS の設定」を参照してください。
クライアント上の resolv.conf ファイルを変更しないこと
ポート要件
IdM クライアントは、複数のポートに接続してサービスと通信します。これらのポートは、着信方向の IdM サーバー上で 開放して機能できるようにしておく必要があります。IdM が必要とするポートについての情報は、「ポート要件」を参照してください。
クライアント上で、送信方向のポートを開放します。firewalld など、送信パケットをフィルタリングしないファイアウォールを使用している場合には、これらのポートはすでに送信方向で利用できる状態です。
Name Service Cache Daemon (NSCD) の要件
Red Hat では、Identity Management マシン上で NSCD を無効にすることを推奨しています。NSCD を無効にできない場合は、代わりに SSSD がキャッシュを行わないマッピングに対して NSCD を有効化するようにしてください。
NSCD と SSSD の両サービスはキャッシングを実行するので、これら両方をシステムが同時に使用すると問題が発生します。NSCD と SSSD の競合を避ける方法については、「システムレベルの認証ガイド」を参照してください。

3.1.1. FIPS 環境でのクライアントインストールの前提条件

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

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. スクリプトが一部の設定を自動的に取得できなかった場合は、値を入力するように求められます。

      重要

      完全修飾ドメイン名は有効な DNS 名である必要があります。つまり、許可されるのは数字、アルファベット、ハイフン (-) のみです。ホスト名にアンダースコアのような他の文字があると、DNS エラーが発生します。また、ホスト名はすべて小文字を使用する必要があり、大文字は使用できません。
      命名プラクティスに関する他の推奨事項については、Red Hat Enterprise Linux セキュリティーガイド を参照してください。
  3. このスクリプトは、クライアントの登録に使用するユーザー ID の入力を求めるプロンプトを表示します。デフォルトでは、このユーザーは admin です。
    User authorized to enroll computers: admin
    Password for admin@EXAMPLE.COM
  4. インストールスクリプトにより、クライアントが設定されます。動作が完了するまで待ちます。
    Client configuration complete.
  5. ipa-client-automount ユーティリティーを実行します。これで NFS が IdM 向けに自動的に設定されます。詳細は、「NFS の自動設定」 を参照してください。

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

非対話式のインストールの場合には、コマンドラインオプションを使用して ipa-client-install ユーティリティーに必要な情報すべて渡します。非対話式のインストールで最小限必要となるオプションは以下のとおりです。
  • クライアントの登録に使用する認証情報を指定するオプション。詳細は「クライアントのインストール」を参照してください。
  • --unattended: ユーザーの確認なしにインストールを実行します。
DNS ゾーンおよび SRV レコードがシステム上で正しく設定されている場合には、スクリプトは自動的に必要な値をすべて検出します。スクリプトが自動的に値を検出できない場合には、コマンドラインオプションを使用して指定してください。
  • --hostname: クライアントマシンの静的ホスト名を指定します。

    重要

    完全修飾ドメイン名は有効な DNS 名である必要があります。つまり、許可されるのは数字、アルファベット、ハイフン (-) のみです。ホスト名にアンダースコアのような他の文字があると、DNS エラーが発生します。また、ホスト名はすべて小文字を使用する必要があり、大文字は使用できません。
    命名プラクティスに関する他の推奨事項については、Red Hat Enterprise Linux セキュリティーガイド を参照してください。
  • --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 ホストとして新規マシンを追加します。--random オプションを指定して ipa host-add コマンドを使用して、無作為のパスワードを生成します。
      $ 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 ドメインへのマシン登録に使用した後は無効になります。登録が完了すると正しいホストの keytab に置き換えられます。
  2. クライアントをインストールするマシンで、ipa-client-install を実行します。以下のオプションを使用します。
    • --password: ipa host-add 出力からの無索引パスワードを使用します。

      注記

      パスワードには特殊文字が含まれることが多いので、一重引用符 (') で括るようにしてください。
    • --unattended: ユーザーの確認なしにインストールを実行します。
    DNS ゾーンおよび SRV レコードがシステム上で正しく設定されている場合には、スクリプトは自動的に必要な値をすべて検出します。スクリプトが自動的に値を検出できない場合には、コマンドラインオプションを使用して指定してください。
    以下に例を示します。
    # ipa-client-install --password 'W5YpARl=7M.n' --domain example.com --server server.example.com --unattended
  3. ipa-client-automount ユーティリティーを実行します。これで NFS が IdM 向けに自動的に設定されます。詳細は、「NFS の自動設定」 を参照してください。

3.4. キックスタートを使用した IdM クライアントの設定

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

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

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

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 環境で、getcertipa-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 ドメインへの再登録

クライアントの仮想マシンが破棄され、その keytab がまだある場合には、クライアントを再登録することができます。

注記

ドメインエントリーがアクティブな状態のクライアントは再登録しかできません。クライアントをアンインストールした場合 (ipa-client-install --uninstall の使用) またはホストのエントリーを無効にした場合は (ipa host-disable の使用) 再登録できません。
再登録時には IdM は以下を実行します。
  • 元のホスト証明書を破棄します。
  • 新規ホストの証明書を生成します。
  • 新規の SSH 鍵を作成します。
  • 新規の keytab を生成します。

3.8.1. 管理者のアカウントを使用して対話式にクライアントを再登録する方法

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

3.8.2. クライアントの keytab を使用して非対話式にクライアントを再登録する方法

自動インストールや、その他、管理者パスワードの利用ができない状況では、クライアントの keytab を使用して再登録するのが適切です。
  1. 元のクライアントの keytab ファイルを/tmp または /root ディレクトリーなどにバックアップします。
  2. 同じホスト名のクライアントマシンを再作成します。
  3. クライアントを再登録して、--keytab オプションを使用して keytab の場所を指定します。
    # ipa-client-install --keytab /tmp/krb5.keytab

    注記

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

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

以下のセクションでは、IdM クライアントの名前の変更方法を説明します。使用するプロセスは以下のとおりです。

警告

クライアントの名前は手動で変更します。Red Hat は、ホスト名の変更が絶対に必要な場合以外は推奨していません。

現在のサービスや keytab 設定の特定

現在のクライアントをアンインストールする前に、クライアントの設定をメモします。新しいホスト名のマシンを再登録した後にこの設定を適用します
  1. マシンで実行されているサービスを特定します。
    1. ipa service-find コマンドを使用して、証明書のあるサービスを特定して出力します。
      $ ipa service-find client.example.com
    2. さらに、各ホストには、ipa service-find の出力に表示されないデフォルトの ホストサービス があります。ホストサービスのサービスプリンシパル (ホストプリンシパル とも呼ばれる) は、host/client.example.com です。
  2. マシンが所属するすべてのホストグループを特定します。
    # ipa hostgroup-find client.example.com
  3. ipa service-find client.example.com で表示されるサービスプリンシパルすべてについて、client.example.com の適切な keytab の場所を特定します。
    クライアントシステム上の各サービスには、ldap/client.example.com@EXAMPLE.COM といったように service_name/hostname@REALM の形式で Kerberos プリンシパルがあります。

IdM ドメインからのクライアントマシンの削除

  1. IdM ドメインからクライアントマシンの登録を解除します。「クライアントのアンインストール」を参照してください。
  2. /etc/krb5.keytab 以外の特定された各 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 サーバーで、「現在のサービスや keytab 設定の特定」で特定した各サービスの新規 keytab を追加します。
    [root@server ~]# ipa service-add service_name/new_host_name
  4. 「現在のサービスや keytab 設定の特定」で割り当てた証明書のあるサービスに対して証明書を生成します。方法は以下のとおりです。
  5. 「現在のサービスや keytab 設定の特定」で特定したホストグループにクライアントを再度追加します。「ユーザーまたはホストグループメンバーの追加および削除」を参照してください。

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

レプリカは、既存の Identity Management サーバー設定をクローンして作成します。そのため、サーバーとそのレプリカは全く同じコア設定を共有します。レプリカのインストールプロセスは既存のサーバー設定をコピーして、その設定をベースにレプリカをインストールします。
"Backup and Restore in IdM/IPA" Knowledgebase solution で説明されているように、バックアップソリューションとして複数のサーバーレプリカを維持してデータの損失を回避することが推奨されます。

注記

9章Identity Management のバックアップと復元に記載されているように、別のバックアップソリューションとして ipa-backup ユーティリティーがあります。これは、レプリカから IdM デプロイメントを再構築できない場合に主に推奨されるソリューションです。

4.1. IdM レプリカの説明

レプリカは、最初のマスターサーバーのクローンとして作成されます。レプリカが作成されると、レプリカにはマスターサーバーと全く同じ機能が搭載されます。サーバーと、このサーバーから作成されたレプリカは、ユーザー、マシン、証明書、設定済みのポリシーの同じ内部情報を共有します。

注記

IdM トポロジー内のマシンタイプに関する情報は「Identity Management ドメイン」を参照してください。
レプリケーション とは、レプリカとレプリカの間でデータをコピするプロセスのことです。レプリカ間の情報は、マルチマスターレプリケーション を使用して共有されます。レプリカ合意で参加したレプリカはすべて、更新を受信するため、データのマスターと考えられます。
サーバーとレプリカの合意

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

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

4.2.1. トポロジーにおけるサーバーサービスのディストリビューション

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

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

レプリカ上の CA サービス

CA なしにレプリカを設定する場合は、証明書の操作の要求はすべて、トポロジー内の CA サーバーに転送されます。

警告

Red Hat では、複数のサーバーに CA サービスをインストールしておくことを強く推奨しています。CA サービスを含む最初のサーバーのレプリカをインストールする方法についての情報は、「CA を設定したレプリカのインストール」 を参照してください。
CA が 1 つのサーバーにしかインストールされていないと、CA サーバーが故障した際に CA 設定が失われて回復できない恐れがあります。詳細については、「失われた CA サーバーの復旧」 を参照してください。
レプリカで CA を設定する場合は、設定は最初のサーバーの CA 設定をミラーリングする必要があります。
  • たとえば、統合された IdM CA がルート証明局としてサーバーに含まれる場合には、レプリカはこの統合された CA をルート証明局としてインストールする必要があります。
  • サポートされる CA 設定オプションは「CA 設定の決定」を参照してください。

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

Red Hat は以下のガイドラインに準拠することを推奨します。
単一の IdM ドメインでレプリカ 61 個以上設定しない
Red Hat は、レプリカが最大 60 個含まれる環境のサポートを保証します。
レプリカごとに 最低で 2 つ、最大 4 つ のレプリカ合意を設定する
追加のレプリカ合意を設定すると、初期レプリカとマスターサーバーとの間だけでなく、他のレプリカ間でも情報が複製されます。
  • サーバー A からレプリカ B を作成してから、サーバー A からレプリカ C を作成する場合には、レプリカ B と C は直接連携されていないので、レプリカ B からのデータを先にサーバー A に複製してからレプリカ C に伝搬する必要があります。
    レプリカ B と C はレプリカ合意で連携されていない

    図4.3 レプリカ B と C はレプリカ合意で連携されていない

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

    図4.4 レプリカ B および C がレプリカ合意で連携されている

    レプリカ合意の管理に関する詳細は6章レプリケーショントポロジーの管理を参照してください。
レプリカごとにレプリカ合意を 5 つ以上設定する必要はありません。サーバーに設定されるレプリカ合意が増えても、追加で大幅な利点がもたらされるわけではありません。これは、1 台のマスターが一度に更新できるのは、消費者サーバー 1 台のみで、他の合意はその間アイドルかつ待機状態となっているからです。また、レプリカ合意を多く設定しすぎると、全体的なパフォーマンスに悪影響を与える可能性があります。

注記

ipa topologysuffix-verify コマンドは、トポロジーが最も重要な推奨事項に対応しているかどうかをチェックします。詳細は、ipa topologysuffix-verify --help を実行してください。
このコマンドでは、トポロジーのサフィックスを指定する必要があります。詳細は「レプリカ合意、トポロジーサフィックス、およびトポロジーセグメント」を参照してください。
トポロジーの例

図4.5 トポロジーの例

4.2.2.1. タイトセルトポロジー

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

4.2.3. 隠しレプリカモード

デフォルトでは、新しいレプリカをセットアップすると、インストーラーが自動的にサービス (SRV) リソースが DNS に記録します。これらの記録により、クライアントはレプリカとそのサービスを自動検出できるようになります。隠しレプリカは、実行していて利用できるすべてのサービスを持つ IdM サーバーです。ただし、DNS に SRV 記録は持ちません。また、LDAP サーバーロールは有効化されていません。そのため、クライアントは、これら隠しレプリカの検出にサーバー検出を使用できません。

注記

隠しレプリカ機能は、テクノロジープレビューとして Red Hat Enterprise Linux 7.7 以降で利用できます。そのため、サポートされていません。
隠しレプリカは、クライアントを中断できる専用のサービス用に主に設計されています。例えば、マスターまたはレプリカ上ですべての IdM サービスをシャットダウンするには IdM の完全なバックアップが必要です。隠しレプリカを使用するクライアントは存在しないため、管理者はクライアントに影響を与えることなく、このホスト上でサービスを一時的にシャットダウンすることができます。その他のユースケースには、大量インポートや詳細なクエリーなど、IdM API または LDAP サーバー上の高負荷操作が含まれます。
レプリカを隠しとしてインストールするには、--hidden-replica パラメーターを ipa-replica-install コマンドに渡します。レプリカのインストールの詳細は、「レプリカの作成: 概要」 を参照してください。
また、既存のレプリカの状態を変更することもできます。詳細は、「非表示レプリカの降格と昇格」を参照してください。

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

レプリカのインストール要件は、IdM サーバーのものと同じです。レプリカのマシンが「サーバーインストールの前提条件」に記載の前提条件すべてを満たすようにしてください。
一般的なサーバー要件に加え、以下の条件を満たす必要があります。
レプリカは、IdM と同じか、最新バージョンを実行している必要があります。
たとえば、マスターサーバーは Red Hat Enterprise Linux 7 で実行されており、IdM 4.4 パッケージを使用する場合には、レプリカは Red Hat Enterprise Linux 7 以降のバージョンで実行し、IdM のバージョン 4.4 以降を使用する必要があります。これにより、サーバーからレプリカに設定が正しくコピーされるようになります。

重要

IdM は、マスターのバージョンより前のバージョンのレプリカ作成をサポートしません。以前のバージョンを使ってレプリカを作成しようとすると、インストールが失敗します。
レプリカには、追加でポートを解放しておく必要があります。
「ポート要件」の説明にある標準の IdM サーバーポート要件に加え、以下も満たす必要があります。
  • ドメインレベル 0 では、レプリカ設定プロセス中はマスターサーバーの TCP ポート 22 を解放した状態にしておいてください。このポートは、マスターサーバーへの接続に SSH を使用するために必要です。

    注記

    ドメインレベルの詳細は7章ドメインレベルの表示と引き上げを参照してください。
  • サーバーの中の 1 台において Red Hat Enterprise Linux 6 を実行し、CA をインストールしている場合には、レプリカの設定時とその後は TCP ポート 7389 も解放するようにしてください。Red Hat Enterprise Linux 7 環境では、ポート 7389 は必要ありません。
firewall-cmd ユーティリティーを使用してポートを解放する方法は「ポート要件」を参照してください。

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

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

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

ipa-replica-install ユーティリティは、既存の IdM サーバーから新しいレプリカをインストールするのに使用されます。Identity Management レプリカは 1 度に 1 つのみインストールしてください。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 サーバーの復旧」 を参照してください。
主要なオプションを使用してレプリカをインストールするシナリオ例については、以下を参照してください。
レプリカの設定に使用するオプションの完全な一覧については ipa-replica-install(1) の man ページを参照してください。

4.5.1. ホストの keytab を使用してレプリカにクライアントをプロモートする方法

この手順では、プロモートを許可する独自のホスト keytab を使用して、既存の IdM クライアントをレプリカにプロモートします。
以下の手順では、管理者またはディレクトリーマネージャー (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 クライアントとしてまだ設定されていないマシンを最初からインストールします。登録を認証するには、クライアントの登録 1 回だけ有効な、クライアント固有の無作為パスワードを使用します。
以下の手順では、管理者またはディレクトリーマネージャー (DM) の認証情報を指定する必要はありません。そのため、機密情報がコマンドラインに公開されないので、よりセキュリティーが高くなります。
  1. 既存のサーバー上で:
    1. 管理者としてログインします。
      $ kinit admin
    2. IdM ホストとして新規マシンを追加します。--random オプションを指定して ipa host-add コマンドを使用して、レプリカのインストールに使用する無作為のワンタイムパスワードを生成します。
      $ 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 ドメインへのマシン登録に使用した後は無効になります。登録が完了すると正しいホストの keytab に置き換えられます。
    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 ドメインに含まれないマシンやクライアントにレプリカをインストールする際に使用します。詳細は「レプリカの作成: 概要」を参照してください。
  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. オプションであるが推奨: レプリカが利用できないときのために、バックアップサーバーとして他の DNS サーバーを手動で追加してください。「ネームサーバーの追加設定」を参照してください。これは、新規レプリカが IdM ドメインで最初の DNS サーバーの場合には特に推奨されます。
  4. 必要に応じて、複製する IdM サーバーに Active Directory により信頼されている環境がある場合は、信頼できるエージェントまたは信頼できるコントローラーとしてレプリカを設定します。詳細は、『Windows 統合ガイド』の「信頼コントローラーおよび信頼エージェント」を参照してください。

4.5.4. CA を設定したレプリカのインストール

以下の手順は、まだ IdM ドメインに含まれないマシンやクライアントにレプリカをインストールする際に使用します。詳細は「レプリカの作成: 概要」を参照してください。
  1. --setup-ca オプションを指定して、ipa-replica-install を実行します。
    [root@replica ~]# ipa-replica-install --setup-ca
  2. サーバー上の IdM CA が root CA でも、外部の CA に従属する CA の場合でも、--setup-ca オプションを指定すると、最初のサーバーの設定から CA 設定がコピーされます。

    注記

    サポートされる CA 設定に関する詳細は「CA 設定の決定」を参照してください。
  3. 必要に応じて、複製する IdM サーバーに Active Directory により信頼されている環境がある場合は、信頼できるエージェントまたは信頼できるコントローラーとしてレプリカを設定します。詳細は、『Windows 統合ガイド』の「信頼コントローラーおよび信頼エージェント」を参照してください。

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

以下の手順は、まだ IdM ドメインに含まれないマシンやクライアントにレプリカをインストールする際に使用します。詳細は「レプリカの作成: 概要」を参照してください。

重要

サードパーティーの自己署名サーバー証明書を使用して、サーバーまたはレプリカをインストールできまん。
  1. ipa-replica-install を実行して、以下のオプションを追加して必要な証明書ファイルを指定します。
    • --dirsrv-cert-file
    • --dirsrv-pin
    • --http-cert-file
    • --http-pin
    これらのオプションを使用して指定するファイルに関する詳細は「CA なしでのインストール」を参照してください。
    以下に例を示します。
    [root@replica ~]# ipa-replica-install \
        --dirsrv-cert-file /tmp/server.crt \
        --dirsrv-cert-file /tmp/server.key \
        --dirsrv-pin secret \
        --http-cert-file /tmp/server.crt \
        --http-cert-file /tmp/server.key \
        --http-pin secret

    注記

    --ca-cert-file オプションを追加しないでください。ipa-replica-install ユーティリティーは、マスターサーバーから証明書のこの部分の情報を自動的に取得します。
  2. 必要に応じて、複製する IdM サーバーに Active Directory により信頼されている環境がある場合は、信頼できるエージェントまたは信頼できるコントローラーとしてレプリカを設定します。詳細は、『Windows 統合ガイド』の「信頼コントローラーおよび信頼エージェント」を参照してください。

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

レプリカの作成後に予想通りにレプリカが機能することを確認します。
  1. サーバーの 1 つでユーザーを作成します。
    [admin@server1 ~]$ ipa user-add test_user --first=Test --last=User
  2. ユーザーが他のサーバーにも表示されるようにします。
    [admin@server2 ~]$ ipa user-show test_user

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

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

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

本章では、IdM への認証方法など、IdM サーバーおよびサービスの管理に利用可能な IdM サーバーとサービスIdentity Management コマンドと UI ツールについて説明します。

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

Directory Server、認証局 (CA)、DNS、Kerberos など、複数の異なるサービスが IdM サーバーにインストールされています。インストールされている全サービスと共に、IdM サーバー全体を停止、起動、再起動するには、ipactl ユーティリティーを使用します。
IdM サーバー全体を起動するには、次のコマンドを実行します。
# ipactl start
IdM サーバー全体を停止するには、次のコマンドを実行します。
# ipactl stop
IdM サーバー全体を再起動するには、次のコマンドを実行します。
# ipactl restart
「システム管理者のガイド」に記載されているとおりに、個別のサービスだけを停止、起動、再起動するには systemctl ユーティリティーを使用してください。たとえば、Directory Server の動作をカスタマイズする際など、systemctl を使用して個別サービスを管理すると便利です。設定を変更すると、Directory Server インスタンスを再起動する必要がありますが、全 IdM サービスを再起動する必要はありません。

重要

Red Hat は、複数の IdM ドメインサービスを再起動する際には ipactl を使用することを推奨しています。IdM サーバーにインストールされているサービス間での依存関係により、サービスを停止、開始する順番は極めて重要です。ipactl ユーティリティーは、サービスが適切な順番に開始、停止されるようにします。

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

IdM は、Kerberos プロトコルを使ってシングルサインオンをサポートします。Kerberos を使用すると、ユーザーは正しいユーザー名とパスワードを 1 回提示するだけで済みます。この後は、システムが認証情報をプロンプトすることなく IdM サービスにアクセスできます。
デフォルトでは、IdM ドメインに所属するマシンのみが Kerberos を使用して IdM に認証を行うことができます。ただし、Kerberos 認証が使用できるように、外部システムも設定できます。詳しい情報は「Web UI への Kerberos 認証用の外部システム設定」を参照してください。

kinit の使用

コマンドラインから IdM にログインするには、kinit ユーティリティーを使用します。

注記

kinit を使用するには、krb5-workstation パッケージをインストールしておく必要があります。
ユーザー名を指定せずに実行すると、 kinit では、ローカルシステムで現在ログイン中のユーザー名を使用して IdM にログインします。たとえば、ローカルシステムに local_user としてログインしている場合に、kinit を実行すると、local_user IdM ユーザーとして認証が試行されます。
[local_user@server ~]$ kinit
Password for local_user@EXAMPLE.COM:

注記

ローカルユーザーのユーザー名と IdM のユーザーエントリーが一致しない場合は、認証に失敗します。
別の IdM ユーザーでログインして、必要なユーザー名をパラメーターとして指定して、kinit ユーティリティーを実行してください。たとえば、admin ユーザーとしてログインするには、以下を実行します。
[local_user@server ~]$ kinit admin
Password for admin@EXAMPLE.COM:

Kerberos チケットの自動取得

IdM クライアントマシンのデスクトップ環境に正常にログインした後に、ユーザーの TGT を自動取得するように、pam_krb5 の PAM (Pluggable Authentication Module) および SSSD を設定することができます。これにより、ログイン後に kinit を実行する必要がなくなります。
SSSD に IdM をアイデンティティーおよび認証プロバイダーとして設定した IdM システムで、ユーザーが適切な kerberos プリンシパル名でログインした後に、SSSD は自動的に TGT を取得します。
pam_krb5 の設定に関する情報は、pam_krb5(8) の man ページを参照してください。PAM に関する一般情報は、「システムレベルの認証ガイド」を参照してください。

複数の Kerberos チケットの保管

デフォルトでは Kerberos は認証キャッシュに、ログインユーザー毎にチケット 1 つだけを保存します。ユーザーが kinit を実行すると必ず、Kerberos は現在保存されているチケットを新しいチケットに置き換えます。たとえば kinit を使用して user_A として認証を行った場合に、user_B に対して認証を行うと user_A のチケットはなくなります。
ユーザーの別の TGT を取得および保存するには、以前のキャッシュの内容が上書きされないように異なる認証キャッシュを設定してください。これには、以下のいずれかの方法を利用してください。
  • export KRB5CCNAME=path_to_different_cache コマンドを使用してから kinit を実行し、チケットを取得します。
  • kinit -c path_to_different_cache コマンドを実行してから、KRB5CCNAME 変数をリセットしてください。
デフォルトの認証キャッシュに保存されている元の TGT を復元するには以下を実行します。
  1. kdestroy コマンドを実行します。
  2. unset $KRB5CCNAME コマンドを使用して、デフォルトの認証キャッシュの場所を復元します。

現在ログインしているユーザーの確認

現在認証用に保存/使用されている TGT を確認するには、klist ユーティリティーを使用してキャッシュされたチケットを表示します。以下の例では、キャッシュに user_A のチケットが含まれ、user_A のみが IdM サービスにアクセスできます。
$ klist
Ticket cache: KEYRING:persistent:0:0
Default principal: user_A@EXAMPLE.COM

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

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

IdM の基本的なコマンドラインのスクリプトは、ipa と呼ばれます。ipa スクリプトは、複数のサブコマンドの親スクリプトで、これらのサブコマンドを使用して IdM を管理します。たとえば、ipa user-add コマンドは新規ユーザーを追加します。
$ ipa user-add user_name
コマンドライン管理は、UI での管理に比べて利点がいくつかあります。たとえば、コマンドラインユーティリティーでは、人の介入なしに一貫性を持って管理タスクを自動化し、繰り返し実行することができます。また、コマンドラインでも、Web UI でも実行可能な管理操作がほとんどですが、タスクによってはコマンドラインからしか実行できないものもあります。

注記

以下のセクションでは、ipa サブコマンドの概要のみを説明します。詳しい情報は、各 IdM 管理エリア専用の他のセクションを参照してください。たとえば、ipa サブコマンドを使用したユーザーエントリーの詳しい情報は11章ユーザーアカウントの管理を参照してください。

5.3.1. ipa コマンドのヘルプ

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

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

Auto Membership Rule.

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

...

EXAMPLES:

 Add the initial group or hostgroup:
   ipa hostgroup-add --desc="Web Servers" webservers
   ipa group-add --desc="Developers" devel
...
ipa スクリプトは、利用可能な ipa コマンドの一覧も表示できます。これには、ipa help commands コマンドを使用します。
$ ipa help commands
automember-add                         Add an automember rule.
automember-add-condition               Add conditions to an automember rule.
...
個別の ipa コマンドに関する詳しいヘルプは、以下のようにコマンドに --help オプションを指定します。
$ ipa automember-add --help

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

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

5.3.2. 値のリストの設定

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

5.3.3. 特殊文字の使用

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

5.3.4. IdM エントリーの検索

IdM エントリーの表示

ipa *-find コマンドを使用して、特定のタイプの IdM エントリーを検索します。以下に例を示します。
  • 全ユーザーを表示します。
    $ ipa user-find
    ---------------
    4 users matched
    ---------------
      ...
  • 指定の属性にkeyword が含まれるユーザーグループを表示するには、以下を実行します。
    $ ipa group-find keyword
    ----------------
    2 groups matched
    ----------------
      ...
    IdM がユーザーおよびユーザーグループを検索するための属性を設定するには、「ユーザーおよびユーザーグループの検索属性の設定」を参照してください。
ユーザーグループの検索の際には、特定のユーザーを含むグループに検索結果を絞り込むことも可能です。
$ ipa group-find --user=user_name
また、特定のユーザーを含まないグループを検索することもできます。
$ ipa group-find --no-user=user_name

特定のエントリーの詳細表示

特定の IdM エントリーに関する詳細を表示するには、以下のように ipa *-show コマンドを使用します。
$ 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 をクリックします。

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

全クエリーに対してグローバルに制限を調節するには、--searchrecordslimit および --searchtimelimit オプションを指定して、ipa config-mod コマンドを実行します。
$ ipa config-mod --searchrecordslimit=500 --searchtimelimit=5
コマンドラインから、特定のクエリーに対する制限のみを調節することもできます。これには、以下のようにコマンドに --sizelimit または --timelimit オプションを指定します。
$ ipa user-find --sizelimit=200 --timelimit=120

5.4. IdM Web UI

Identity Management Web UI とは、IdM 管理の Web アプリケーションのことで、ipa コマンドラインユーティリティーにある大半の機能が含まれます。そのため、ユーザーは IdM の管理に UI またはコマンドラインのいずれかを選択できます。

注記

ログイン中のユーザーが利用できる管理操作は、そのユーザーに割り当てられている権限により異なります。admin ユーザーおよびその他に管理者権限のあるユーザーは、すべての管理タスクを使用できます。通常のユーザーが使用できるのは、自身のユーザーアカウントに関する操作のみに限られます。

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

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

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

Web UI には、IdM サーバーおよびクライアントマシンの両方から、さらに IdM ドメイン外のマシンからもアクセスできます。ただし、ドメイン外のマシンから UI にアクセスするには、IdM 以外のシステムで IdM Kerberos ドメインに接続できるように設定しておく必要があります。詳細は、「Web UI への Kerberos 認証用の外部システム設定」を参照してください。

5.4.2.1. Web UI へのアクセス

Web UI をアクセスして、ブラウザーアドレスバーに IdM サーバーの URL を入力します。
https://server.example.com
これで、ブラウザーに Web UI ログイン画面が表示されます。
Web UI ログイン画面

図5.1 Web UI ログイン画面

5.4.2.2. 利用可能なログイン方法

ユーザーは、以下の方法で Web UI に対して認証を行うことができます。
有効な Kerberos チケットの使用
ユーザーが kinit ユーティリティーから TGT を取得して、その TGT が有効な場合には Login ボタンをクリックすることで自動的にユーザーが認証されます。ブラウザーは、Kerberos 認証をサポートするように正しく設定しておく必要がある点にご注意ください。
Kerberos TGT の取得に関する情報は、「Kerberos を使用した IdM へのログイン」を参照してください。ブラウザーの設定に関する情報は、「Kerberos 認証用のブラウザーの設定」を参照してください。
ユーザー名およびパスワードの提示
ユーザー名およびパスワードを使用して認証するには、Web UI のログイン画面でユーザー名とパスワードを入力します。
IdM は、ワンタイムパスワード (OTP) 認証もサポートします。詳しい情報は「ワンタイムパスワード」を参照してください。
スマートカードの使用
ユーザー認証に成功すると、IdM 管理ウィンドウが開きます。
IdM Web UI のレイアウト

図5.2 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 管理者は、各 AD ユーザーの ID オーバーライドを Default Trust View で定義する必要があります。以下に例を示します。
[admin@server ~]$ ipa idoverrideuser-add 'Default Trust View' ad_user@ad.example.com
AD における ID ビューの詳細については、『Windows 統合ガイド』の「Active Directory 環境での ID ビューの使用」を参照してください。

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

Kerberos 認証情報での認証を有効化するには、ブラウザーが Kerberos との交渉をサポートして IdM ドメインにアクセスできるように設定する必要があります。お使いのブラウザーを Kerberos 認証用に適切に設定されていない場合は、IdM Web UI ログイン画面で Login をクリックした後にエラーメッセージが表示されます。
Kerberos 認証エラーメッセージ

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

Kerberos 認証ようにブラウザーを設定する方法には 3 通りあります。

注記

『システムレベルの認証ガイド』には、「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 認証用のブラウザーの設定」で記載されているように、外部マシンのブラウザーを設定します。
外部システムのユーザーは、IdM サーバーに対して kinit ユーティリティーを使用できるようになりました。

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

Web UI へのアクセスにプロキシーサーバーを使用する場合には、IdM での追加設定は必要ありません。
ポート転送は IdM サーバーではサポートされていませんが、IdM ではプロキシーサーバーを使用することができるので、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 サーバー間でレプリカ合意が設定されていると、これらのサーバーのデータは共有されます。
レプリカ合意は常に双方向のものです。1 台目のレプリカから 2 台目のレプリカにデータが複製されるほかに、2 台目のレプリカから 1 台目のレプリカにもデータが複製されます。

注記

詳細については、「IdM レプリカの説明」 を参照してください。

トポロジーサフィックス

トポロジーサフィックス は、複製されたデータを保存します。IdM では、domain および ca の 2 つのタイプのサフィックスをサポートしています。各サフィックスは、別個のバックエンドと別個のレプリカトポロジーを表しています。
レプリカ合意が設定されると、2 台のサーバー上の同じタイプの 2 つのトポロジーサフィックスを結びつけます。
domain サフィックス: dc=example,dc=com
domain サフィックスには、ドメイン関連データすべてが含まれます。
2 つのレプリカの domain サフィックス間でレプリカ合意が設定されると、ユーザー、グループ、およびポリシーなどのディレクトリーデータが共有されます。
ca サフィックス: o=ipaca
ca サフィックスには、 Certificate System コンポーネント用のデータが含まれます。これは、証明局 (CA) がインストールされているサーバーにのみ存在します。
2 つのレプリカの ca サフィックス間でレプリカ合意が設定されると、証明書データが共有されます。
トポロジーサフィックス

図6.1 トポロジーサフィックス

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

例6.1 トポロジーサフィックスの表示

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

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

トポロジーセグメント

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

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

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

ipa topologysegment-find コマンドで、domain または CA サフィックスに設定されたトポロジーセグメントが表示されます。たとえば、domain サフィックスの場合は以下のようになります。
$ ipa topologysegment-find
Suffix name: domain
-----------------
1 segment matched
-----------------
  Segment name: server1.example.com-to-server2.example.com
  Left node: server1.example.com
  Right node: server2.example.com
  Connectivity: both
----------------------------
Number of entries returned 1
----------------------------
この例では、ドメイン関連のデータのみが server1.example.comserver1.example.com の 2 つのサーバー間で複製されます。
特定セグメントの詳細を表示するには、ipa topologysegment-show コマンドを使用します。
$ ipa topologysegment-show
Suffix name: domain
Segment name: server1.example.com-to-server2.example.com
  Segment name: server1.example.com-to-server2.example.com
  Left node: server1.example.com
  Right node: server2.example.com
  Connectivity: both

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

トポロジーグラフへのアクセス

web UI のトポロジーグラフでは、ドメイン内におけるサーバー間の関係が表示できます。
  1. IPA ServerTopologyTopology Graph を選択します。
  2. トポロジーに加えた変更がグラフに反映されていない場合は、Refresh をクリックします。

トポロジービューのカスタマイズ

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

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

マウスホイールを使うと、グラフの拡大、縮小ができます。
トポロジーグラフの拡大

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

マウスの左ボタンを長押しすると、トポロジーグラフ自体を動かすことができます。
トポロジーグラフの移動

図6.5 トポロジーグラフの移動

トポロジーグラフの意味

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

図6.6 トポロジーの推奨例

トポロジーグラフ: 非推奨例
図6.7「非推奨のトポロジー例: 単一障害点」 では、server1 が単一障害点となっています。他のすべてのサーバーはこのサーバーとレプリカ合意を結んでいますが、これ以外には合意が設定されていません。このため、server1 に障害が発生すると、他のサーバーは孤立してしまいます。
このようなトポロジーは作成しないでください。
非推奨のトポロジー例: 単一障害点

図6.7 非推奨のトポロジー例: 単一障害点

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

6.2.1. 2 サーバー間でのレプリカ設定

  1. トポロジーグラフで、ノード上にカーソルを持っていきます。
    Domain または CA オプション

    図6.8 Domain または CA オプション

  2. 作成するトポロジーセグメントのタイプに合わせて、円の domain または ca をクリックします。
  3. カーソルの下に新たなレプリカ合意を表す矢印が表示されます。カーソルを別のサーバーノードに移動して、そこでクリックします。
    新セグメントの作成

    図6.9 新セグメントの作成

  4. Add Topology Segment ウィンドウで Add をクリックして、新セグメントの属性を確認します。
IdM が 2 つのサーバー間に新規トポロジーセグメントを作成し、これらのサーバーはレプリカ合意に参加します。トポロジーグラフに更新されたレプリカトポロジーが表示されます。
新規セグメント作成後のグラフ

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

6.2.2. 2 サーバー間のレプリカの削除

  1. 削除するレプリカ合意を表す矢印をクリックします。矢印がハイライト表示されます。
    トポロジーセグメントのハイライト表示

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

  2. Delete をクリックします。
  3. Confirmation ウィンドウで OK をクリックします。
IdM が 2 つのサーバー間のトポロジーセグメントを削除し、これでサーバーのレプリカ合意も削除されます。トポロジーグラフに更新されたレプリカトポロジーが表示されます。
トポロジーセグメントの削除

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

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

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

レプリカトポロジーの管理に使用する全コマンドを表示するには、以下を実行します。
$ ipa help topology
特定のコマンドに関する詳細のヘルプを表示するには、そのコマンドを --help オプションと実行します。
$ ipa topologysuffix-show --help

6.3.2. 2 サーバー間でのレプリカ設定

  1. 2 サーバー間のトポロジーセグメントを作成するには、ipa topologysegment-add コマンドを使用します。プロンプトに応じて、以下を提供します。
    • domain または ca のトポロジーサフィックス

      注記

      ca サフィックス間でセグメントを作成する場合は、両方のサーバーに CA がインストールされている必要があります。「CA の既存の IdM ドメインへのインストール」 を参照してください。
    • 各サーバーを表す左ノードと右ノード
    • オプションで、セグメントのカスタム名
    以下に例を示します。
    $ ipa topologysegment-add
    Suffix name: domain
    Left node: server1.example.com
    Right node: server2.example.com
    Segment name [server1.example.com-to-server2.example.com]: new_segment
    ---------------------------
    Added segment "new_segment"
    ---------------------------
      Segment name: new_segment
      Left node: server1.example.com
      Right node: server2.example.com
      Connectivity: both
    新規セグメントを追加すると、サーバーがレプリカ合意に参加します。
  2. オプションで ipa topologysegment-show コマンドを使用すると、新規セグメントが設定されたことを確認することができます。
    $ ipa topologysegment-show
    Suffix name: domain
    Segment name: new_segment
      Segment name: new_segment
      Left node: server1.example.com
      Right node: server2.example.com
      Connectivity: both

6.3.3. 2 サーバー間のレプリカの削除

  1. レプリケーションを停止するには、対応するサーバー間のレプリカセグメントを削除する必要があります。これを実行するには、セグメント名が必要になります。
    セグメント名が分からない場合は、ipa topologysegment-find コマンドを実行して全セグメントを表示し、該当するセグメントを見つけます。プロンプトに応じて、domain または ca のトポロジーサフィックスを提供します。例を示します。
    $ ipa topologysegment-find
    Suffix name: domain
    ------------------
    8 segments matched
    ------------------
      Segment name: new_segment
      Left node: server1.example.com
      Right node: server2.example.com
      Connectivity: both
    
    ...
    
    ----------------------------
    Number of entries returned 8
    ----------------------------
  2. 2 サーバー間のトポロジーセグメントを削除るには、ipa topologysegment-del コマンドを使用します。
    $ ipa topologysegment-del
    Suffix name: domain
    Segment name: new_segment
    -----------------------------
    Deleted segment "new_segment"
    -----------------------------
    セグメントを削除すると、レプリカ合意が削除されます。
  3. オプションで ipa topologysegment-find コマンドを使用すると、セグメントが削除されたことを確認することができます。
    $ ipa topologysegment-find
    Suffix name: domain
    ------------------
    7 segments matched
    ------------------
      Segment name: server2.example.com-to-server3.example.com
      Left node: server2.example.com
      Right node: server3.example.com
      Connectivity: both
    
    ...
    
    ----------------------------
    Number of entries returned 7
    ----------------------------

6.4. トポロジーからサーバーを削除する

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

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

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

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

    図6.13 サーバーの選択

  3. Delete Server をクリックします。

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

重要

サーバーを削除すると、元に戻すことはできません。サーバーを削除した後にこれをトポロジーに再度導入する唯一の方法は、マシンに新規レプリカをインストールすることになります。
server1.example.com を削除するには、以下を実行します。
  1. 別のサーバーで ipa server-del コマンドを実行して server1.example.com を削除します。このコマンドで、当該サーバーをポイントしているすべてのトポロジーセグメントが削除されます。
    [user@server2 ~]$ ipa server-del
    Server name: server1.example.com
    Removing server1.example.com from replication topology, please wait...
    ----------------------------------------------------------
    Deleted IPA server "server1.example.com"
    ----------------------------------------------------------
  2. server1.example.comipa server-install --uninstall コマンドを実行して、マシンからこのサーバーコンポーネントをアンインストールします。
    [root@server1 ~]# ipa server-install --uninstall

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

IdM サーバーは、インストールされているサービスを基に、CA サーバー、DNS サーバー、またはキー回復機関 (KRA) サーバーなどの各種の サーバーロール を実行することができます。

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

Web UI: サーバーロールの表示

サポートされるサーバーロールの全一覧を確認するには、IPA ServerTopologyServer Roles をクリックします。
  • Role status が absent の場合は、トポロジー内でそのロールを実行しているサーバーがないことを示しています。
  • Role status が enabled の場合は、トポロジー内でそのロールを実行しているサーバーが 1 台以上あることを示しています。
Web UI でのサーバーロール

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

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

ipa config-show コマンドを実行すると、すべての CA サーバー、NTP サーバー、および現行の CA 更新マスターが表示されます。
$ ipa config-show
  ...
  IPA masters: server1.example.com, server2.example.com, server3.example.com
  IPA CA servers: server1.example.com, server2.example.com
  IPA NTP servers: server1.example.com, server2.example.com, server3.example.com
  IPA CA renewal master: server1.example.com
ipa server-show コマンドを実行すると、特定サーバーで有効になっているロール一覧が表示されます。たとえば、server.example.com で有効になっているロールを表示するには、以下を実行します。
$ ipa server-show
Server name: server.example.com
  ...
  Enabled server roles: CA server, DNS server, NTP server, KRA server
ipa server-find --servrole は、特定のサーバーロールが有効になっているサーバーを検索します。たとえば、CA サーバーを検索するには、以下を実行します。
$ ipa server-find --servrole "CA server"
---------------------
2 IPA servers matched
---------------------
  Server name: server1.example.com
  ...

  Server name: server2.example.com
  ...
----------------------------
Number of entries returned 2
----------------------------

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

注記

本セクションでは、ドメインレベル 1 の CA 更新マスターの変更について説明しています (7章ドメインレベルの表示と引き上げ を参照)。ドメインレベル 0 での CA 更新マスターの変更については、「レプリカのマスター CA サーバーへのプロモート」 を参照してください。
複数のレプリカがあるトポロジーでは、そのうちの 1 つがマスター CA サーバーとして機能し、CA サブシステムの証明書の更新を管理したり、証明書失効リスト (CRL) を生成したりします。デフォルトでは、レプリカを作成する元となる最初のサーバーがマスター CA となります。
マスター CA サーバーをオフラインにする、または使用停止にする場合は、別の CA サーバーをプロモートして、新規 CA 更新マスターとします。
  1. レプリカが CA サブシステムの証明書更新を処理するよう設定します。
  2. レプリカが CRL を生成するように設定します。「CRL を生成するサーバーの変更」 を参照してください。
  3. 今までのマスター CA サーバーの使用を停止する前に、新規マスターが正常に機能することを確認します。「新規マスター CA サーバーの設定確認」 を参照してください。

6.5.2.1. 現行 CA 更新マスターの変更

Web UI: 現行 CA 更新マスターの変更

  1. IPA ServerConfiguration を選択します。
  2. IPA CA renewal master フィールドで、新規 CA 更新マスターを選択します。

コマンドライン: 現行 CA 更新マスターの変更

ipa config-mod --ca-renewal-master-server コマンドを使用します。
$ ipa config-mod --ca-renewal-master-server new_ca_renewal_master.example.com
  ...
  IPA masters: old_ca_renewal_master.example.com, new_ca_renewal_master.example.com
  IPA CA servers: old_ca_renewal_master.example.com, new_ca_renewal_master.example.com
  IPA NTP servers: old_ca_renewal_master.example.com, new_ca_renewal_master.example.com
  IPA CA renewal master: new_ca_renewal_master.example.com
出力で更新が成功したことを確認します。

6.5.2.2. CRL を生成するサーバーの変更

CRL を生成するサーバーを変更するには、現行の CRL 生成マスターでの CRL 生成を停止し、それから他のサーバーで生成を有効にします。

現行 CRL 生成マスターの特定

CA がインストールされている各サーバーで /etc/pki/pki-tomcat/ca/CS.cfg ファイルをチェックします。
  • CRL 生成マスターで、ca.crl.MasterCRL.enableCRLUpdates パラメーターを true に設定します。
    # grep ca.crl.MasterCRL.enableCRLUpdates /etc/pki/pki-tomcat/ca/CS.cfg
    ca.crl.MasterCRL.enableCRLUpdates=true
  • CRL 生成クローンでパラメーターを false に設定します。

現行 CRL 生成マスターで CRL 生成を停止する

  1. CA サービスを停止します。
    # systemctl stop pki-tomcatd@pki-tomcat.service
  2. サーバー上での CRL 生成を無効にします。/etc/pki/pki-tomcat/ca/CS.cfg ファイルを開いて、ca.crl.MasterCRL.enableCRLCacheca.crl.MasterCRL.enableCRLUpdates のパラメーターの値を false に設定します。
    ca.crl.MasterCRL.enableCRLCache=false
    ca.crl.MasterCRL.enableCRLUpdates=false
  3. CA サービスを起動します。
    # systemctl start pki-tomcatd@pki-tomcat.service
  4. CRL リクエストを新規マスターにリダイレクトするように Apache を設定します。/etc/httpd/conf.d/ipa-pki-proxy.conf ファイルを開いて、RewriteRule 引数をコメント解除します。
    # Only enable this on servers that are not generating a CRL
    RewriteRule ^/ipa/crl/MasterCRL.bin https://server.example.com/ca/ee/ca/getCRL?op=getCRL&crlIssuingPoint=MasterCRL [L,R=301,NC]
  5. Apache を再起動します。
    # systemctl restart httpd.service
この手順の前までは、このサーバーは CRL リクエストに対応していましたが、これですべての CRL リクエストが以前の CA マスターにルーティングされます。

サーバーが CRL を生成するように設定する

  1. CA サービスを停止します。
    # systemctl stop pki-tomcatd@pki-tomcat.service
  2. サーバー上での CRL 生成を有効にします。ca.crl.MasterCRL.enableCRLCacheca.crl.MasterCRL.enableCRLUpdates のパラメーターの値を true に設定します。
    ca.crl.MasterCRL.enableCRLCache=true
    ca.crl.MasterCRL.enableCRLUpdates=true
  3. CA サービスを起動します。
    # systemctl start pki-tomcatd@pki-tomcat.service
  4. Apache で CRL リクエストのリダイレクトを無効にします。/etc/httpd/conf.d/ipa-pki-proxy.conf ファイルを開いて、RewriteRule 引数をコメントアウトします。
    #RewriteRule ^/ipa/crl/MasterCRL.bin https://server.example.com/ca/ee/ca/getCRL?op=getCRL&crlIssuingPoint=MasterCRL [L,R=301,NC]
    この手順の前までは、CRL 要求はすべて以前の CA マスターにルーティングされていましたが、これで、このサーバーは CRL 要求に応答します。
  5. Apache を再起動します。
    # systemctl restart httpd.service

6.5.2.3. 新規マスター CA サーバーの設定確認

/var/lib/ipa/pki-ca/publish/MasterCRL.bin ファイルが新規マスター CA サーバーにあることを確認します。
このファイルは、/etc/pki/pki-tomcat/ca/CS.cfg ファイルで定義されている間隔を基に、ca.crl.MasterCRL.autoUpdateInterval パラメーターを使って生成されます。デフォルト値は、240 分 (4 時間) です。

注記

ca.crl.MasterCRL.autoUpdateInterval パラメーターを更新する場合、この変更は、既にスケジュール設定されている次の CRL の更新後に有効になります。
このファイルが存在すれば、新規マスター CA サーバーは正常に設定されているので、以前の CA マスターシステムを安全に閉鎖できます。

6.5.3. 非表示レプリカの降格と昇格

レプリカのインストール後は、レプリカの可視状態を変更できます。
  • 可視レプリカを非表示レプリカに降格するには:
    1. レプリカが CA 更新マスターである場合は、サービスを別のレプリカに移動させます。詳細については、「現行 CA 更新マスターの変更」 を参照してください。
    2. レプリカの状態を hidden に変更します。
      # ipa server-state replica.idm.example.com --state=hidden
  • 非表示レプリカを表示レプリカに昇格するには、次を使用します。
    # ipa server-state replica.idm.example.com --state=enabled

注記

非表示レプリカ機能は、テクノロジープレビューとして Red Hat Enterprise Linux 7.7 以降で利用できます。そのため、サポートされていません。

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

ドメインレベルは、IdM トポロジー内で利用可能な操作と機能を示します。
ドメインレベル 1
利用可能な機能の例

重要

ドメインレベル 1 は、Red Hat Enterprise Linux 7.3 の IdM バージョン 4.4 で導入されました。ドメインレベル 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. Set Domain Level をクリックします。

第8章 Identity Management の更新と移行

8.1. Identity Management の更新

システム上の Identity Management パッケージの更新には、yum ユーティリティーを使用します。
また、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 のため SSLv3 (Secure Socket Layer version 3) プロトコルは mod_nss モジュールで無効にする必要があります。次の手順に従い、無効になっていることを確認してください。
  1. /etc/httpd/conf.d/nss.conf ファイルを編集して NSSProtocol パラメーターを TLSv1.0 (後方互換用) および TLSv1.1TLSv1.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 マスターです。

    注記

    どの Red Hat Enterprise Linux 6 サーバーがマスター CA サーバーかを特定するには、どのサーバー上で 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 を実行する post-save アクションは、CA マスターにのみ定義されています。

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

  • 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 スキーマ更新スクリプトにより、rhel6.example.com での rhel7.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. 更新された copy-schema-to-ca.py スクリプトを rhel6.example.com 上で実行します。
    [root@rhel6 ~]# python copy-schema-to-ca.py
    ipa         : INFO     Installed /etc/dirsrv/slapd-PKI-IPA//schema/60kerberos.ldif
    [... output truncated ...]
    ipa         : INFO     Schema updated successfully
  3. Red Hat Enterprise Linux 7 レプリカに接続する前に、証明局を実行する Red Hat Enterprise Linux 6 の IdM レプリカすべてで手順を繰り返します。

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

  1. rhel6.example.com システム上で、rhel7.example.com レプリカのインストールに使用するレプリカファイルを作成します。たとえば、rhel7.example.com 用のレプリカファイルを作成します。このシステムの IP アドレスは 192.0.2.1 とします。
    [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. Red Hat Enterprise Linux 7.6 以降に、統合 CA で新しいレプリカをインストールする場合は、/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 7.6 上の統合 CA で IdM サーバーを、Red Hat Enterprise Linux 6 を実行しているマスターのレプリカとして設定すると、CRITICAL Failed to configure CA instance エラーで失敗します。
  4. レプリカファイルを使用して rhel7.example.com レプリカをインストールします。たとえば、この例では以下のオプションを使用しています。
    • --setup-ca は、Certificate System コンポーネントを設定します。
    • --setup-dns--forwarder は、統合 DNS サーバーとフォワーダーを設定します。
    • --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.comrhel7.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 "20191127184547" removed.
    [root@rhel6 ~]# getcert stop-tracking -d /var/lib/pki-ca/alias -n "ocspSigningCert cert-pki-ca"
    Request "20191127184548" removed.
    [root@rhel6 ~]# getcert stop-tracking -d /var/lib/pki-ca/alias -n "subsystemCert cert-pki-ca"
    Request "20191127184549" removed.
    [root@rhel6 ~]# getcert stop-tracking -d /etc/httpd/alias -n ipaCert
    Request "20191127184550" 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 "20191127184743" 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 "20191127184744" 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 "20191127184745" 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 "20191127184746" 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 で、Apache が CRL リクエストを新しいマスターである rhel7.example.com にリダイレクトするよう設定します。
    1. /etc/httpd/conf.d/ipa-pki-proxy.conf ファイルを開き、RewriteRule 引数のコメントを解除します。サーバーホスト名をサーバー URL にある rhel7.example.com ホスト名で置き換えます。
      RewriteRule ^/ipa/crl/MasterCRL.bin https://rhel7.example.com/ca/ee/ca/getCRL?op=getCRL&crlIssuingPoint=MasterCRL [L,R=301,NC]
    2. Apache を再起動します。
      [root@rhel6 ~]# service httpd restart
  3. rhel7.example.comrhel7.example.com を新規 CA マスターとして設定します。
    1. 「証明書更新を処理するサーバーの変更」 にあるように、rhel7.example.com が CA サブシステムの証明書更新を処理するように設定します。
    2. 「サーバーが CRL を生成するように設定する」 にあるように、rhel7.example.com が証明書失効リスト (CRL) を生成するように設定します。

関連情報

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

rhel6.example.com 上の全サービスを停止して、新規 rhel7.example.com サーバーへのドメイン検索を実施します。
[root@rhel6 ~]# ipactl stop
Stopping CA Service
Stopping pki-ca:                                           [  OK  ]
Stopping HTTP Service
Stopping httpd:                                            [  OK  ]
Stopping MEMCACHE Service
Stopping ipa_memcached:                                    [  OK  ]
Stopping DNS Service
Stopping named: .                                          [  OK  ]
Stopping KPASSWD Service
Stopping Kerberos 5 Admin Server:                          [  OK  ]
Stopping KDC Service
Stopping Kerberos 5 KDC:                                   [  OK  ]
Stopping Directory Service
Shutting down dirsrv:
    EXAMPLE-COM...                                         [  OK  ]
    PKI-IPA...                                             [  OK  ]
この後に ipa ユーティリティーを使用すると、 Remote Procedure Call (RPC) で新規サーバーに接続します。

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

トポロジー内の各 Red Hat Enterprise Linux 6 サーバーで以下を実行します。
  1. rhel7.example.com からレプリカファイルを作成します。

    注記

    Red Hat Enterprise Linux 6 サーバーから Red Hat Enterprise Linux 7 レプリカをインストールした後は、Identity Management ドメインのドメインレベルは自動的に 0 に設定されます。
    Red Hat Enterprise Linux 7.3 では、レプリカを容易にインストール、管理する方法が導入されています。これらの機能を使用するには、トポロジーのドメインレベルが 1 である必要があります。詳細は 7章ドメインレベルの表示と引き上げ を参照してください。
  2. レプリカファイルを使用して別の Red Hat Enterprise Linux 7 システムに新規レプリカをインストールします。
Red Hat Enterprise Linux 6 サーバーの使用を停止するには、
  • Red Hat Enterprise Linux 7 サーバー上で削除コマンドを実行して、トポロジーからサーバーを削除します。

第9章 Identity Management のバックアップと復元

Red Hat Enterprise Linux Identity Management は、たとえばサーバーが正常に稼働しなくなった場合やデータを損失した場合などのために、IdM システムのバックアップと復元を手動で行うソリューションを提供しています。バックアップ時には、システムは IdM セットアップに関する情報を含むディレクトリを作成して保存します。復元時には、このバックアップディレクトリを使って元の IdM セットアップに戻すことができます。

重要

失われたレプリカを残りのサーバーのレプリカとして再インストールして、デプロイメントの残りのサーバーから IdM サーバーグループの損失部分を再構築できない場合にのみ、本章に記載のバックアップおよび復元の手順を使用するようにしてください。
"Backup and Restore in IdM/IPA" Knowledgebase solution では、複数のサーバーレプリカを維持することで損失を避ける方法について説明しています。既存のレプリカから同一データを使って再構築する方法が望ましいやり方です。バックアップバージョンには通常古い情報が含まれるので、無効になっている可能性があるからです。
バックアップと復元で回避できる脅威のシナリオには、以下のようなものがあります。
  • マシン上で致命的なハードゥエア障害が発生し、マシンが動作しなくなった場合は、次の操作を実行します。
    1. 最初からオペレーティングシステムを再インストールします。
    2. 同じホスト名、完全修飾ドメイン名 (FQDN)、IP アドレスでマシンを設定します。
    3. 元のシステム上に存在していた IdM に関連した IdM パッケージと同様、その他のオプションのパッケージをインストールします。
    4. IdM サーバーの完全なバックアップを復元します。
  • 分離されているマシンでのアップグレードが失敗した場合。オペレーティングシステムは機能しているものの、IdM データが破損しているため、IdM システムを正常起動時構成に戻す場合です。

    重要

    上記の 2 例のようにハードウェアの障害やアップグレードで失敗した際に、唯一の証明局 (CA) など、特別なロールが割り当てられたレプリカがなくなった場合や、すべてのレプリカがなくなった場合にのみバックアップから復元するようにしてください。同一データを持つ別のレプリカがまだある場合は、失われたレプリカを削除して、残りのレプリカから再構成することが推奨されます。
  • エントリーが削除されてしまい、それらを戻す場合など、LDAP コンテナーに望ましくない変更がされた場合。バックアップされた LDAP データを復元すると、IdM システム自体には影響せずに LDAP エントリーを元の状態に戻すことができます。
復元されたサーバーは、IdM の唯一の情報ソースになります。他のマスターサーバーは復元されたサーバーから再度初期化されます。最後のバックアップが実行された後に作成されたデータは失われます。このため、通常のシステムメンテナンスには、バックアップと復元の方法を使用すべきではありません。可能な場合は常に失われたサーバーをレプリカとして再インストールすることで再構成を行ってください。
バックアップおよび復元機能はコマンドラインからのみ操作が可能で、IdM Web UI では操作できません。

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

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

9.1.1. バックアップの作成

完全なサーバーバックアップもデータのみのバックアップも、ipa-backup ユーティリティーを使用して作成されます。これは常に root で実行する必要があります。
完全なサーバーバックアップを作成するには、ipa-backup を実行します。

重要

完全なサーバーバックアップのプロセスはオフラインで実行する必要があるため、すべての IdM サービスが停止されます。バックアップが終了すると、IdM サービスは再開します。
データのみのバックアップを作成するには、ipa-backup --data コマンドを実行します。
ipa-backup には以下のオプションを追加することができます。
  • --online は、オンラインでのバックアップを実行します。これはデータ専用のバックアップでのみ利用可能となります。
  • --logs は、バックアップに IdM サービスログファイルを含めます。
ipa-backup の使用に関する詳細情報は、ipa-backup(1) man ページを参照してください。

9.1.1.1. バックアップ中に関与したボリュームの容量不足の回避策

本項では、IdM バックアッププロセスに関与したディレクトリが、空き容量が不足しているボリュームに保存されている場合の問題の対処方法について説明します。

/var/lib/ipa/backup/ を含むボリューム上の空き容量不足

/var/lib/ipa/backup/ ディレクトリが空き容量が不足しているボリュームに保存され他場合は、バックアップを作成できません。問題に対処するには、以下のいずれかのワークアラウンドをお試しください。
  • 別のボリューム上でディレクトリを作成し、/var/lib/ipa/backup/ にリンクします。例えば、/home が、空き容量が十分にある別のボリュームに保存されている場合:
    1. /home/idm/backup/ などのディレクトリを作成します。
      # mkdir -p /home/idm/backup/
    2. 以下のパーミッションをディレクトリに設定します。
      # chown root:root /home/idm/backup/
      # chmod 700 /home/idm/backup/
    3. /var/lib/ipa/backup/ に既存のバックアップがある場合は、そのバックアップを新しいディレクトリに移動します。
      # mv /var/lib/ipa/backup/* /home/idm/backup/
    4. /var/lib/ipa/backup/ ディレクトリを削除します。
      # rm -rf /var/lib/ipa/backup/
    5. /home/idm/backup/ ディレクトリへの /var/lib/ipa/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. バックアップの暗号化

IdM バックアップは、GNU Privacy Guard (GPG) を使って暗号化することができます。
GPG キーを作成するには、以下を実行します。
  1. たとえば、cat >keygen <<EOF を実行して、キーの詳細を含む keygen ファイルを作成します。そして、コマンドラインから必要となる暗号化詳細をファイルに提供します。
    [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 暗号化されたバックアップを作成するには、以下のオプションを使って生成されたbackup キーを ipa-backup に渡します。
  • --gpg は、ipa-backup に暗号化バックアップを実行するよう指示します。
  • --gpg-keyring=GPG_KEYRING は、ファイル拡張子なしで GPG keyring への完全パスを提供します。
以下に例を示します。
[root@server ~]# ipa-backup --gpg --gpg-keyring=/root/backup

注記

使用中のシステムが gpg2 ユーティリティーを使って GPG キーを生成している場合、問題が発生する可能性があります。これは、gpg2 が機能するには外部のプログラムを必要とするためです。この状況でコンソールのみからキーを生成するには、キーの生成前に pinentry-program /usr/bin/pinentry-curses の行を .gnupg/gpg-agent.conf ファイルに追加します。

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

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

9.2. バックアップの復元

ipa-backup を使って作成されたバックアップのディレクトリがあれば、IdM サーバーまたは LDAP コンテンツをバックアップ実行時の状態に復元することができます。バックアップが作成された元のホストとは異なるホスト上では、バックアップの復元はできません。

注記

IdM サーバーをアンインストールしても、自動的にこのサーバーのバックアップは削除されません。

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

重要

完全なサーバーの復元前にサーバーをアンインストールすることが推奨されます。
完全なサーバーバックアップもデータ専用のバックアップも、ipa-restore ユーティリティーを使って復元されます。これは常に root で実行する必要があります。バックアップをコマンドに渡します。
  • バックアップがデフォルトの /var/lib/ipa/backup/ ディレクトリにある場合は、ディレクトリ名のみを渡します。
  • バックアップを含んでいるディレクトリがデフォルト以外の場所にある場合は、完全パスを渡します。例を示します。
    [root@server ~]# ipa-restore /path/to/backup
ipa-restore ユーティリティーはディレクトリに含まれているバックアップのタイプを自動的に検出し、デフォルトで同一タイプの復元を実行します。
ipa-restore には以下のオプションを追加できます。
  • --data は、完全なサーバーバックアップからデータのみの復元を実行します。つまり、完全なサーバーバックアップを含むディレクトリから LDAP データのコンポーネントのみを復元します。
  • --online は、データのみの復元で LDAP データをオンラインで復元します。
  • --instance は、どの 389 DS インスタンスを復元するか指定します。Red Hat Enterprise Linux 7 の IdM は IPA-REALM インスタンスしか使用しませんが、たとえば、別のインスタンスを持つシステム上でバックアップを作成することは可能です。この場合、--instance を使うと、IPA-REALM の復元のみが許可されます。例を示します。
    [root@server ~]# ipa-restore --instance=IPA-REALM /path/to/backup
    このオプションは、データのみの復元実行時にのみ使用できます。
  • --backend は復元するバックエンドを指定します。このオプションがない場合は、ipa-restore は発見したすべてのバックエンドを復元します。可能性のあるバックエンドを定義する引数は userRoot でこれは IPA データバックエンドを復元し、ipaca の場合は CA バックエンドを復元します。
    このオプションは、データのみの復元実行時にのみ使用できます。
  • --no-logs は、ログファイルなしでバックアップを復元します。
IdM master で認証の問題を回避するには、リストア後に 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. 複数マスターサーバーでの復元

バックアップから復元すると復元されたサーバーが新規のデータマスターとして設定され、他のマスターすべてを再度初期化する必要があります。この初期化を行うには ipa-replica-manage コマンドを実行し、CA がインストールされているマスター上で ipa-csreplica-manage コマンドを実行します。
[root@server ~]# ipa-replica-manage re-initialize --from=restored_master_FQDN
復元時のレプリケーションと他のマシン上での復元に関する情報は、ipa-restore(1) man ページを参照してください。

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

10.1.1. Identity Management におけるアクセス制御方法

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

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

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

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

  1. トップメニューの IPAサーバー タブで、 ロールベースのアドレスコントロールセルフサービスパーミッションサブタブを選択します。
  2. セルフサービスアクセスコントロールの説明のトップリストの追加をクリックします。
    現在のセルフサービスルールの追加

    図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サーバータブで、 ロールベースのアドレスコントロール委任サブタブを選択します。
  2. 委任アクセスコントロール説明のトップリストの追加リンクをクリックします。
    新規委任の追加

    図10.4 新規委任の追加

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

    図10.5 委任追加のフォーム

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

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

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

重要

委任ルールを修正する際は、既存の属性も含め、すべての属性を含めるようにしてください。

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

ロールベースのアクセス制御では、セルフサービスおよび委任アクセス制御の場合とは非常に異なる種類の権限をユーザーに付与します。ロールベースのアクセス制御は基本的には管理業務用で、エントリーの変更を行うことができます。
ロールベースのアクセスコントロールには、パーミッション特権ロールがあります。特権は1 つ以上のパーミッションから成り、ロールは 1 つ以上の特権から成ります。
  • パーミッションは、(読み取り、書き込み、追加、または削除などの) 特定の操作と、これらの操作が適用される IdM LDAP ディレクトリー内のターゲットエントリーを定義します。パーミッションはビルディングブロックで、必要に応じて複数の特権に割り当てることができます。
    IdM パーミッションを使用すると、どのユーザーがどのオブジェクトにアクセスできるかや、それらのオブジェクトのどの属性にアクセスできるかという制御すら可能になります。IdM を使うと、個別の属性をブラックリスト化したりホワイトリスト化したりすることができるほか、全匿名ユーザー、全認証ユーザー、または特権のあるユーザーの特定グループのみに対するユーザー、グループ、または sudo といった特定の IdM 機能の視認性全体を変更することもできます。パーミッションに対するアプローチがこのように柔軟なことで、たとえば、管理者がユーザーやグループのアクセスをこれらのユーザーやグループが必要とする特定のセクションのみに限定し、他のセクションを完全に見えないようにする場合などに便利になります。
  • 特権は、ロールに適用できるパーミッションのグループです。例えば、パーミッションは自動マウントの場所の追加、編集、削除を行うために作成できます。そして、そのパーミッションは FTP サーバーの管理に関連する別のパーミッションと組み合わせることができます。これらは、ファイルシステムの管理に関連する単一の特権を作成するために作成できます。

    注記

    Red Hat Identity Management では、特権は、パーミッションが作成されてからロールが作成されるというアトミックな単位のアクセスコントロールという固有の意味を持ちます。一時的に追加の特権を取得した通常のユーザーというコンセプトとして 特権のエスカレーションは、Red hat Identity Management に存在しません。特権は、ロールベースアクセス制御 (RBAC) を使用してユーザーに割り当てられます。ユーザーはアクセスを付与するロールを持つか、持たないかのいずれかになります。
    ユーザーは別として、特権はユーザーグループ、ホスト、ホストグループ、ネットワークサービスにも割り当てられます。この性質上、特定のネットワークサービスから一連のホスト上の一連のユーザーによる操作の詳細な制御が可能になります。
  • ロールは、ロールに指定されたユーザーが所有する特権のリストです。
完全に新しいパーミッションを作成したり、既存または新規のパーミッションをベースにして新たな権限を作成したりすることができます。Red Hat Identity Management は、以下の範囲の事前に定義したロールを提供します。

表10.1 Red Hat Identity Management で事前に定義されているロール

ロール特権説明
ヘルプデスク
ユーザーの変更とパスワードのリセット、グループメンバーの変更簡単なユーザー管理タスクを行う
IT セキュリティスペシャリスト
ネットグループ管理者、HBAC管理者、sudo 管理者ホストベースのアクセスコントロール、sudo ルールなどのセキュリティポリシーの管理を行う
IT スペシャリスト
ホスト管理者、ホストグループ管理者、サービス管理者、自動マウント管理者ホストの管理を行う
セキュリティアーキテクト
委任管理者、レプリカ管理者、書き込み IAP 設定、パスワードポリシー管理者Identity Management 環境の管理、信頼の作成、レプリカ合意の作成を行う
ユーザー管理
ユーザー管理者、グループ管理者、stage ユーザー管理者ユーザーとグループの作成を行う

10.4.1. ロール

10.4.1.1. Web UI でのロールの作成

  1. トップメニューで IPA Server タブを開き、Role Based Access Control サブタブを選択します。
  2. ロールベースのアクセスコントロール説明のトップリストにある追加リンクをクリックします。
    新規ロールの追加

    図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. パーミッション一覧の上部にある追加をクリックします。
    新規パーミッションの追加

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

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

    図10.14 パーミッション追加のフォーム

  5. フォームの下にある Add をクリックしてパーミッションを保存します。
以下のパーミッションのプロパティーを指定することができます。
  1. 新規パーミッションの名前を入力します。
  2. 適切な Bind rule type を選択します。
    • permission がデフォルトのパーミッションタイプになります。これでアクセスが権限とロールによって付与されます。
    • all を選択すると、パーミッションがすべての認証ユーザーに適用されます。
    • anonymous を選択すると、非認証ユーザーを含むすべてのユーザーにパーミッションが適用されます。

    注記

    デフォルト以外の bind rule type のパーミッションを権限に追加することはできません。また、権限に既にあるパーミッションをデフォルト以外の bind rule type に設定することもできません。
  3. パーミッションが付与する権限を Granted rights で選択します。
  4. パーミッションのターゲットエントリーを識別する方法を定義します。
    • Type では、ユーザー、ホスト、またはサービスなどのエントリータイプを指定します。Type で値を設定すると、そのエントリータイプの ACI でアクセス可能な全属性が Effective Attributes に表示されます。
      Type を定義すると、SubtreeTarget DN が定義済みのいずれかの値に設定されます。
    • Subtree は、サブツリーエントリーを指定します。このサブツリーエントリー以下のすべてのエントリーがターゲットになります。Subtree はワイルドカードや存在しないドメイン名 (DN) を受け付けないので、既存のサブツリーエントリーを提供してください。例を示します。
      cn=automount,dc=example,dc=com
    • Extra target filter では、LDAP フィルターを使ってパーミッションが適用されるエントリーを特定します。このフィルターは有効な LDAP フィルターであればどれでも構いません。例を示します。
      (!(objectclass=posixgroup))
      IdM は、提供されたフィルターの有効性を自動的にチェックします。無効なフィルターが入力された場合は、パーミッションを保存使用とすると IdM が警告します。
    • Target DN はドメイン名 (DN) を指定し、ワイルドカードを受け付けます。例を示します。
      uid=*,cn=users,cn=accounts,dc=com
    • Member of group は、特定のグループのメンバーにターゲットフィルターを設定します。
    フィルター設定を記入して Add をクリックすると、IdM がフィルターの有効性を確認します。すべてのパーミッション設定が適切であれば、IdM は検索を実行します。設定が適切でない場合、IdM は該当設定についてのメッセージを表示します。
  5. Type を設定する場合は、Effective attributes で利用可能な ACI 属性一覧から選択します。Type を使用しない場合は、Effective attributes フィールドに手動で属性を追加します。属性は 1 つずつ追加します。複数の属性を追加するには、Add をクリックして別の入力フィールドを追加します。

    重要

    パーミッションの属性を設定しない場合は、デフォルトで全属性が含まれることになります。

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

新規パーミッションを追加するには、ipa permission-add コマンドを発行します。対応するオプションを提供して、パーミッションのプロパティーを指定します。
  • プロパティー名を提供します。例を示します。
    [root@server ~]# ipa permission-add "dns admin permission"
  • --bindtype では、bind rule type を指定します。このオプションは allanonymous、および permission の引数を受け付けます。例を示します。
    --bindtype=all
    --bindtype を使用しない場合は、タイプは自動的にデフォルトの permission の値に設定されます。

    注記

    デフォルト以外の bind rule type のパーミッションを権限に追加することはできません。また、権限に既にあるパーミッションをデフォルト以外の bind rule type に設定することもできません。
  • --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 を使って、automount の場所のような、他の設定のコンテナーや親エントリーである、一定タイプのエントリーをターゲットにすることができます。例を示します。
    [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 では、特定のユーザーグループが存在することを確認した後、そのグループにターゲットを設定します。
Target DN 設定は Web UI では利用可能ですが、コマンドラインでは使用できません。

注記

パーミッションの修正および削除に関する情報については、ipa permission-mod --helpipa permission-del --help のコマンドを実行してください。

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

管理 (Managed) パーミッションは、Identity Management でインストール済みとして提供されるパーミッションです。これらはユーザーが作成したその他のパーミッションのように動作しますが、以下の点が異なります。
  • 名前、場所、およびターゲット属性が修正できません。
  • 削除することができません。
  • 以下の 3 つの属性セットがあります。
    • default 属性は IdM が管理し、ユーザーは修正することができません。
    • included 属性は、ユーザーが追加する属性です。included 属性を管理パーミッションに追加するには、ipa permission-mod コマンドで --includedattrs オプションを使用して属性を指定します。
    • excluded 属性は、ユーザーが削除する属性です。excluded 属性を管理パーミッションに追加するには、ipa permission-mod コマンドで --excludedattrs オプションを使用して属性を指定します。
管理パーミッションは、default および included 属性セットに表示される全属性に適用されますが、excluded セットの属性には適用されません。
管理パーミッション修正時に--attrs オプションを使用すると、included および excluded 属性セットは自動的に調整され、--attrs で提供された属性のみが有効になります。

注記

管理パーミッションは削除できませんが、その bind type を permission に設定し、該当管理パーミッションを全権限から削除すると、実質的に無効となります。
すべての管理パーミッションの名前は System: で始まります。たとえば、System: Add Sudo ruleSystem: Modify Services などです。
IdM の以前のバージョンでは、デフォルトのパーミッションに異なるスキームを使用しており、ユーザーはデフォルトのパーミッションを修正できず、パーミッションを権限に割り当てることのみが可能でした。これらデフォルトのパーミッションはほとんど管理パーミッションとなっていますが、以下のパーミッションはまだ以前のスキームを使用しています。
  • Add Automember Rebuild Membership Task
  • Add Replication Agreements
  • Certificate Remove Hold
  • Get Certificates status from the CA
  • Modify DNA Range
  • Modify Replication Agreements
  • Remove Replication Agreements
  • Request Certificate
  • Request Certificates from a different host
  • Retrieve Certificates from the CA
  • Revoke Certificate
  • Write IPA Configuration
管理パーミッションを Web UI から修正する場合、修正できない属性が無効化されます。
無効化された属性

図10.15 無効化された属性

コマンドラインから管理パーミッションを修正する場合、修正不可能な属性の変更はシステムで許可されません。たとえば、デフォルトの System: Modify Users パーミッションをグループに適用しようとすると失敗します。
$ ipa permission-mod 'System: Modify Users' --type=group
ipa: ERROR: invalid 'ipapermlocation': not modifiable on managed permissions
ただし、System: Modify Users パーミッションを GECOS 属性に適用しないようにすることは可能です。
$ ipa permission-mod 'System: Modify Users' --excludedattrs=gecos
------------------------------------------
Modified permission "System: Modify Users"

10.4.2.4. Identity Management の以前のバージョンのパーミッション

Identity Management の以前のバージョンでは、パーミッションは別の方法で処理されていました。たとえば、
  • グローバルの IdM ACI は、認証されていない匿名ユーザーを含めた、サーバーの全ユーザーに読み取りアクセスを付与していました。
  • 利用できるパーミッションタイプは書き込み、追加、削除のみでした。読み込みパーミッションも利用できましたが、認証されていないユーザーを含めた全ユーザーがデフォルトで読み込みアクセス権を持っていたため、実用性に欠けていました。
現在のバージョンの Identity Management には、より詳細なパーミッションの設定を行うためのオプションが含まれています。
  • グローバル IdM ACI は、認証されていないユーザーに読み込みアクセスを付与しません。
  • 例えば、フィルターとサブツリーの両方を同じパーミッションで追加できるようになりました。
  • 検索権と比較権を追加することが可能です。
パーミッションの処理方法が新しくなったことで、IdM ではユーザーまたはグループアクセスの制御が大幅に改善しました。一方で、以前のバージョンとの後方互換性も維持しています。IdM の以前のバージョンからアップグレードすると、全サーバー上のグローバルの IdM ACI が削除され、管理パーミッションで置き換えられます。
以前の方法で作成されたパーミッションは、修正時に自動的に現在のスタイルに変換されます。変更しない場合は、以前のタイプのパーミッションは変換されずに残ります。パーミッションは一旦現在のスタイルを使用すると、元のスタイルに戻すことはできません。

注記

IdM の以前のバージョンを実行しているサーバー上でパーミッションを権限に割り当てることは、引き続き可能です。
ipa permission-showipa 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. 権限一覧の上部にある追加をクリックします。
    新規権限の追加

    図10.17 新規権限の追加

  4. 権限の名前と説明を入力します。
    権限追加のフォーム

    図10.18 権限追加のフォーム

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

    図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 ホームディレクトリーモジュール

IdM ドメインにユーザーがログインした時点で自動的にホームディレクトリーが作成されるように、PAM ホームディレクトリーモジュールを設定するには、以下の PAM モジュールの 1 つを使用します。
  • pam_oddjob_mkhomedir
  • pam_mkhomedir
IdM はまず、pam_oddjob_mkhomedir の使用を試行します。このモジュールがインストールされていない場合は、IdM は代わりに pam_mkhomedir の使用を試みます。

注記

NFS 共有での新しいユーザーのホームディレクトリー自動作成には対応していません。

PAM ホームディレクトリーモジュールの設定

PAM ホームディレクトリーを有効化すると、ローカルの環境に影響があります。そのため、各クライアントやサーバーなど、必要とされる場所上で個別にモジュールを有効化する必要があります。
サーバーまたはクライアントのインストール時はにモジュールを設定するには、マシンのインストール時に、--mkhomedir オプションを指定して ipa-server-install または ipa-client-install ユーティリティーを実行します。
すでにインストール済みのサーバーやクライアントでモジュールを設定するには authconfig ユーティリティを使用します。以下に例を示します。
# authconfig --enablemkhomedir --update
authconfig を使用したホームディレクトリーの作成に関する情報は、「authconfig を使用したカスタムホームディレクトリーの有効化」を参照してください。

11.1.2. ホームディレクトリーを手動でマウントする手順

IdM ドメインの全マシンで利用できるように /home/ ディレクトリーを提供し、automount ユーティリティーで IdM マシンにディレクトリーをマウントするには、NFS ファイルサーバーを使用します。

NFS 使用時に発生する可能性のある問題

NFS は、パフォーマンスおよびセキュリティーに悪影響を与える可能性があります。たとえば、NFS では、NFS ユーザーに root のアクセス権限を割り当てるとセキュリティーの脆弱性が発生したり、/home/ ディレクトリーツリー全体を読み込む際にパフォーマンスの問題が発生したり、ホームディレクトリーにリモートサーバーを使用する際にネットワークパフォーマンスの問題が発生したりする可能性があります。
これらの問題の影響を軽減するために、以下のガイドラインに従うことが推奨されます。
  • automount を使用して、ユーザーがログインした時のみ、ユーザーのホームディレクトリーのみをマウントします。これを使用して、/home/ ツリー全体を読み込ませないようにしてください。
  • 限定的なパーミッションを割り当てたリモートユーザーを使用してホームディレクトリーを作成し、このユーザーとして IdM サーバーに共有をマウントします。IdM サーバーは httpd プロセスとして実行されるので、sudo または同様のプログラムを使用して IdM サーバーへの限定的なパーミッションを許可して、NFS サーバーにホームディレクトリーを作成することができます。

NFS および automount を使用したホームディレクトリーの設定

NFS 共有および automount を使用して別の場所から IdM サーバーにホームディレクトリーを手動で追加するには以下を実行します。
  1. ユーザーディレクトリーマップ用に新しい場所を作成します。
    $ ipa automountlocation-add userdirs
    Location: userdirs
  2. 新たに作成した場所の auto.direct ファイルにダイレクトマップを追加します。auto.direct ファイルは、ipa-server-install ユーティリティーで自動的に作成された automount マップです。以下の例では、マウントポイントは /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 での automount の使用に関する詳細は 34章Automount の使用 を参照してください。

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

Identity Management (IdM) では stageactive および preserved の 3 つのユーザーアカウントの状態をサポートします。
  • Stage ユーザーは認証ができません。これは最初の状態です。アクティブなユーザーが必要とする、ユーザーアカウントのプロパティーの一部は、まだ設定されていません。
  • Active ユーザーは認証が可能です。この状態では、必要とされるユーザーアカウントのプロパティーはすべて設定されています。
  • Preserved ユーザーは、過去に active であったユーザーです。このユーザーは非アクティブとみなされ、IdM への認証はできません。Preserved ユーザーは、Active ユーザーに設定されたていたアカウントプロパティーの大半が保持されますが、どのユーザーグループにも所属しません。

    注記

    preserved 状態のユーザー一覧は、以前のユーザーアカウントの履歴を提供することができます。
ユーザーエントリーも IdM データベースから完全に削除することができます。ユーザーエントリーを完全に削除すると、エントリー自体とグループメンバーシップやパスワードなど、そのユーザーの情報をすべて IdM から削除します。システムアカウントやホームディレクトリーなどのユーザーの外部設定は削除されませんが、IdM でアクセスできなくなります。

重要

削除したユーザーアカウントは復元することができます。ユーザーアカウントを削除すると、そのアカウントに関連付けられたすべての情報が完全に失われます。
新規管理者ユーザーは、デフォルトの admin ユーザーなど、別の管理者でしか作成できません。すべての管理者ユーザーを誤って削除してしまった場合は、Directory Manager が手動で新規の管理者を Directory Server に作成する必要があります。

ユーザーのライフサイクル管理に関する操作

ユーザーのプロビジョニングを管理するには、管理者はユーザーアカウントの状態を変更します。新規ユーザーは、active または stage のいずれかの状態で追加できますが、preserved ではできません。
IdM は、ユーザーライフサイクル管理の以下の操作をサポートします。
stage → active
stage の状態のアカウントが正しくアクティベートされる準備ができると、管理者は active の状態に移動します。
active → preserved
ユーザーが企業を退社した後には、管理者はアカウントを preserved の状態に移動します。
preserved → active
以前働いていたユーザーが再度企業に復帰した場合に、管理者は、ユーザーアカウントを preserved から active の状態に移動して復帰させます。
preserved → stage
以前のユーザーが企業に復帰する予定の場合に、管理者はアカウントの状態を preserved から stage に移動して、後ほど再アクティベートできるようにアカウントの準備をします。
IdM から active、stage および preserved ユーザーを完全に削除することもできます。stage ユーザーは preserved の状態に移動できず、完全に削除することしかできない点に注意してください。
ユーザーライフサイクルの操作

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

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

Web UI でのユーザーの追加

  1. IdentityUsers タブを選択します。
  2. ユーザーを active または stage のいずれの状態で追加するかによって、Active users または Stage users カテゴリーを選択します。
    ユーザーカテゴリーの選択

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

    active または stage ユーザーのライフサイクルに関する詳しい情報は、「ユーザーのライフサイクル」を参照してください。
  3. ユーザー一覧上部にある Add をクリックします。
    ユーザーの追加

    図11.3 ユーザーの追加

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

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

active の状態の新規ユーザーを追加するには、ipa user-add コマンドを使用します。stage の状態の新規ユーザーを追加するには、ipa stageuser-add コマンドを使用します。

注記

active または stage ユーザーのライフサイクルに関する詳しい情報は、「ユーザーのライフサイクル」を参照してください。
ipa user-add および ipa stageuser-add をオプションなしで実行すると、最小限必要なユーザー属性の入力が求められ、他の属性についてはデフォルト値が使用されます。または、オプションを追加してコマンドに直接さまざまな属性を指定することができます。
対話型のセッションでは、オプションなしでコマンドを実行すると、IdM は指定したフルネームをもとに自動的にユーザーログインを提案し、カッコ内 ([ ]) に表示します。デフォルトのログイン ID を受け入れるには、Enter を押して確定します。カスタムログインを指定するには、デフォルトを確定せずに、カスタムのログインを指定します。
$ ipa user-add
First name: first_name
Last name: last_name
User login [default_login]: custom_login
ipa user-add および ipa stageuser-add にオプションを追加すると、多くのユーザー属性にカスタムの値を定義できるようになります。これを使用すると、対話型セッションよりもより多くの情報を指定することができます。たとえば、stage ユーザーを追加するには以下を実行します。
$ 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 は、以下の正規表現で記述可能なユーザー名をサポートします。
[a-zA-Z0-9_.][a-zA-Z0-9_.-]{0,252}[a-zA-Z0-9_.$-]?

注記

Samba 3.x マシンのサポートを有効にするために、ユーザー名の最後にドル記号 ($) を指定できるようになっています。
名前に大文字を含むユーザーを追加した場合には、IdM は自動的に小文字に変換して保存します。そのため、IdM はログイン時にユーザー名はすべて小文字で入力する必要があります。さらに、userUser のように、ユーザー名の違いが大文字と小文字のみのユーザーは追加できません。
デフォルトでは、ユーザー名の最大文字数は 32 文字となっています。これを変更するには、ipa config-mod --maxusername コマンドを使用します。たとえば、ユーザー名の最大長を 64 文字に変更するには、以下を実行します。
$ ipa config-mod --maxusername=64
  Maximum username length: 64
  ...

11.2.1.2. カスタムの UID または GID 番号の定義

カスタムの UID または GID 番号を指定せずにユーザーエントリーを追加する場合には、IdM は、ID 範囲内で次に利用可能なID 番号が自動的に割り当てます。つまり、ユーザーには常に一意の ID 番号が指定されることになります。ID 範囲に関する詳しい情報は14章一意の UID および GID 番号の割り当てを参照してください。
カスタム ID 番号を指定すると、カスタム ID 番号が一意であるかどうか、サーバーによる検証はありません。そのため、複数のユーザーエントリーに同じ ID 番号が割り当てられる可能性があります。Red Hat は、複数のエントリーに同じ ID 番号が割り当てられないようにすることを推奨します。

11.2.2. ユーザーの一覧表示およびユーザーの検索

Web UI でのユーザーの表示

  1. IdentityUsers タブを選択します。
  2. Active usersStage users または Preserved users カテゴリーを選択します。
    ユーザーの一覧表示

    図11.4 ユーザーの一覧表示

Web UI でのユーザー情報の表示

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

図11.5 ユーザー情報の表示

コマンドラインからのユーザーの表示

active ユーザーすべてを表示するには、ipa user-find コマンドを実行します。stage ユーザーをすべてを表示するには、ipa stageuser-find コマンドを使用します。preserved ユーザーを表示するには、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 にオプションおよび引数を追加して、検索条件を定義して検索結果を絞り込むことができます。たとえば、特定のタイトルが定義された active ユーザーをすべてを表示するには、以下を実行します。
$ ipa user-find --title=user_title
---------------
2 users matched
---------------
  User login: user
...
  Job Title: Title
...

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

User login: user2
...

User login: user3
...
ipa user-find および ipa stageuser-find で利用可能なオプションの完全な一覧については、コマンドに --help オプションを指定して実行します。

コマンドラインからのユーザー情報の表示

active または preserved ユーザーに関する情報を表示するには ipa user-show コマンドを使用します。
$ ipa user-show user_login
  User login: user_login
  First name: first_name
  Last name: last_name
...
stage ユーザーの情報を表示するには、ipa stageuser-show コマンドを使用します。

11.2.3. ユーザーの有効化、保存、削除、復元

以下のセクションでは、異なるユーザーライフサイクルの状態の間でユーザーのアカウントを移動する方法について説明します。IdM のライフサイクルの状態に関する詳しい情報は、「ユーザーのライフサイクル」を参照してください。

Web UI でのユーザーライフサイクルの管理

stage ユーザーをアクティベートするには、以下を実行してください。
  • Stage users 一覧で、アクティベートユーザーを選択して Activate をクリックします。
    ユーザーの有効化

    図11.6 ユーザーの有効化

ユーザーを保存または削除するには、以下を実行します。
  1. Active users または Stage users リストで対象のユーザーを選択して Delete をクリックします。
    ユーザーの削除

    図11.7 ユーザーの削除

  2. active ユーザーを選択した場合には delete または preserve を選択します。また、stage ユーザーを選択した場合には、そのユーザーは削除しかできません。デフォルトの UI オプションは delete です。
    たとえば、active ユーザーを保存するには、以下を行います。
    Web UI での削除モードの選択

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

    Delete ボタンをクリックして確定します。
preserved ユーザーを復元するには以下を行います。
  • Preserved users 一覧で、復元するユーザーを選択し、Restore をクリックします。
    ユーザーの復元

    図11.9 ユーザーの復元

注記

ユーザーを復元しても、そのアカウントに指定されている以前の属性すべてが復元されるわけではありません。たとえば、ユーザーのパスワードは復元されないので、再度定義する必要があります。
Web UI で、ユーザーを preserved から stage の状態に移動できません。

コマンドラインからのユーザーライフサイクルの管理

stage から active に移動してユーザーアカウントをアクティベートするには、ipa stageuser-activate コマンドを使用します。
$ ipa stageuser-activate user_login
-------------------------
Stage user user_login activated
-------------------------
...
ユーザーアカウントを保存または削除するには ipa user-del または ipa stageuser-del コマンドを使用します。
  • IdM データベースから active ユーザーを完全に削除するには、オプションの指定なしに ipa user-del を実行します。
    $ ipa user-del user_login
    --------------------
    Deleted user "user3"
    --------------------
  • active ユーザーを保存するには、--preserve オプションを指定して ipa user-del を実行します。
    $ ipa user-del --preserve user_login
    --------------------
    Deleted user "user_login"
    --------------------
  • IdM データベースから stage ユーザーを完全に削除するには 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 に移動して preserved ユーザーアカウントを復元するには、ipa user-undel コマンドを使用します。
$ ipa user-undel user_login
------------------------------
Undeleted user account "user_login"
------------------------------
preserved から stage に移動して preserved ユーザーアカウントを復元するには、ipa user-stage コマンドを使用します。
$ ipa user-stage user_login
------------------------------
Staged user account "user_login"
------------------------------

注記

ユーザーアカウントを復元しても、そのアカウントに指定されている以前の属性すべてが復元されるわけではありません。たとえば、ユーザーのパスワードは復元されないので、再度定義する必要があります。
これらのコマンドや対応のオプションに関する情報は、コマンドに --help オプションを追加して実行してください。

11.3. ユーザーの編集

Web UI でのユーザーの編集

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

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

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

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

Web UI でユーザー情報を更新した後は、新しい値はすぐに同期されません。クライアントシステムで新しい値が反映されるまで約 5 分程度かかる可能性があります。

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

active または preserved の状態のユーザーを変更するには、ipa user-mod コマンドを使用します。stage の状態のユーザーを変更するには、ipa stageuser-mod コマンドを使用します。
ipa user-mod および ipa stageuser-mod コマンドでは、以下のオプションを利用できます。
  • 変更するユーザーアカウントを特定するユーザーログイン
  • 新規属性の値を指定するオプション
コマンドラインから変更可能なユーザーエントリーの属性に関する完全一覧は、ipa user-mod および ipa stageuser-mod で利用可能なオプション一覧を参照してください。オプション一覧を表示するには、コマンドに --help オプションを追加して実行してください。
ipa user-mod または ipa stageuser-mod に属性オプションを追加するだけで、現在の属性値を上書きします。たとえば、以下を実行するとユーザーのタイトルが変更されるか、ユーザーのタイトルが指定されていない場合には新規タイトルが追加されます。
$ ipa user-mod user_login --title=new_title
LDAP 属性に複数の値を指定可能な場合は、IdM でも複数の値を指定できます。たとえば、ユーザーアカウントに 2 つの電子メールを保存できます。既存の値を上書きすることなしに別の属性値を追加するには、新規属性値を指定するオプションと --addattr オプションを使用します。たとえば、すでにメールが指定されているユーザーアカウントに新規のメールアドレスを追加するには以下を実行します。
$ ipa user-mod user --addattr=mobile=new_mobile_number
--------------------
Modified user "user"
--------------------
  User login: user
...
  Mobile Telephone Number: mobile_number, new_mobile_number
...
同時に 2 つの属性値を設定するには、--addattr オプションを 2 度使用します。
$ ipa user-mod user --addattr=mobile=mobile_number_1 --addattr=mobile=mobile_number_2
ipa user-mod コマンドは、属性値の設定に --setattr オプションを、属性値の削除に --delattr オプションを指定することができます。これらのオプションは、--addattr と同じように使用されます。詳細は ipa user-mod --help コマンドの出力を参照してください。

注記

ユーザーの現在のメールアドレスを上書きするには --email オプションを使用しますが、別のメールアドレスを追加するには、--email オプションと --addattr オプションを使用します。
$ ipa user-mod user --email=email@example.com

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

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

管理者は、active ユーザーアカウントを無効化および有効化できます。ユーザーアカウントのアクティベートを解除すると、アカウントを無効になり、無効化されたユーザーアカウントを使用して認証できません。無効化されたアカウントを使用するユーザーは、IdM にログインできず、Kerberos などの IdM サービスを使用できずタスクも実行できません。
無効化されたユーザーアカウント自体は、IdM に存在しており、関連の情報はすべて変更されません。preserved ユーザーアカウントとは異なり、無効化されたユーザーアカウントは active の状態のまま保持されるので、ipa user-find コマンドを実行すると、出力に表示されます。以下に例を示します。
$ ipa user-find
...
  User login: user
  First name: User
  Last name: User
  Home directory: /home/user
  Login shell: /bin/sh
  UID: 1453200009
  GID: 1453200009
  Account disabled: True
  Password: False
  Kerberos keys available: False
...
無効化されたユーザーアカウントは再度有効にすることができます。

注記

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

Web UI でのユーザーアカウントの有効化および無効化

  1. IdentityUsers タブを選択します。
  2. Active users 一覧から対象のユーザーを選択して、Disable または Enable をクリックします。
    ユーザーアカウントの無効化または有効化

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

コマンドラインからのユーザーアカウントの無効化および有効化

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

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

デフォルトでは admin ユーザーのみがユーザーライフサイクルの管理やユーザーアカウントの有効化/無効化が可能です。管理者以外の別ユーザがこの操作をできるようにするには、新規ロールを作成して、このロールに適切なパーミッションを追加し、管理者以外のユーザーにこのロールを割り当てます。
デフォルトでは、IdM にはユーザーアカウントの管理に関する以下の権限が含まれます。
Modify Users and Reset passwords
この権限には、さまざまなユーザー属性を変更するパーミッションが含まれます。
User Administrators
この権限は、active ユーザーの追加、active 以外のユーザーのアクティベート、ユーザーの削除、ユーザー属性やその他のパーミッションの変更が含まれます。
Stage User Provisioning
この権限には、stage ユーザーを追加するパーミッションが含まれます。
Stage User Administrator
以下の権限には、stage ユーザーの追加、ライフサイクルの状態の間におけるユーザーの移動などライフサイクルでの操作を実行するパーミッションが含まれます。ただし、active の状態にユーザーを移動するパーミッションは含まれません。
ロール、パーミッション、権限の定義に関する情報は「ロールベースのアクセス制御の定義」を参照してください。

異なるユーザーに対するさまざまなユーザー管理操作の実行許可

ユーザーアカウントの管理に関するさまざまな権限を各種ユーザーに追加することができます。たとえば、以下のように従業員のアカウントエントリーとアクティベーションの権限を区別することができます。
  • stage user administrator ユーザーを 1 つ設定する。このユーザーは、IdM に 今後入社する従業員を stage ユーザーとして追加できるが、アクティベートはできません。
  • security administrator として別のユーザーを 1 つ設定する。このユーザーは、就業日初日に従業員の認証情報を確認後に、stage ユーザーをアクティベートすることができます。
ユーザーが特定のユーザー管理の操作を実行できるようにするには、必要な権限を指定した新規ロールを作成し、そのロールを対象のユーザーに割り当てます。

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

以下の例では、新規の stage ユーザーの追加のみが可能で、他の stage ユーザー管理操作を実行できないユーザーを作成する方法を説明します。
  1. ロールベースのアクセス制御を管理可能な admin ユーザーまたは別のユーザーとしてログインします。
    $ kinit admin
  2. 新規カスタムロールを作成して、stage ユーザーの追加を管理します。
    1. System Provisioning ロールを作成します。
      $ ipa role-add --desc "Responsible for provisioning stage users" "System Provisioning"
      --------------------------------
      Added role "System Provisioning"
      --------------------------------
      Role name: System Provisioning
      Description: Responsible for provisioning stage users
    2. Stage User Provisioning の権限をロールに割り当てます。この権限により、stage ユーザーが追加できるようになります。
      $ ipa role-add-privilege "System Provisioning" --privileges="Stage User Provisioning"
      Role name: System Provisioning
      Description: Responsible for provisioning stage users
      Privileges: Stage User Provisioning
      ----------------------------
      Number of privileges added 1
      ----------------------------
  3. 管理者以外のユーザーに stage ユーザーを追加する権限を割り当てます。
    1. 管理者以外のユーザーが存在しない場合には、新規ユーザーを作成します。以下の例では 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 ユーザーに System Provisioning ロールを割り当てます。
      $ ipa role-add-member "System Provisioning" --users=stage_user_admin
      Role name: System Provisioning
      Description: Responsible for provisioning stage users
      Member users: stage_user_admin
      Privileges: Stage User Provisioning
      -------------------------
      Number of members added 1
      -------------------------
    3. System Provisioning ロールが正しく設定されていることを確認するには、ipa role-show コマンドを使用してロールの設定を表示します。
      $ ipa role-show "System Provisioning"
      --------------
      1 role matched
      --------------
      Role name: System provisioning
      Description: Responsible for provisioning stage users
      Member users: stage_user_admin
      Privileges: Stage User Provisioning
      ----------------------------
      Number of entries returned 1
      ----------------------------
  4. stage_user_admin ユーザーとして新しい stage ユーザーが追加されているかをテストします。
    1. stage_user_admin としてログインします。以前の手順で新規ユーザーとして 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. 新規 stage ユーザーを追加します。
      $ ipa stageuser-add stage_user
      First name: first_name
      Last name: last_name
      ipa: ERROR: stage_user: stage user not found

      注記

      stage ユーザーの追加後に IdM からエラーが報告されるのは想定内です。stage_user_admin は、stage ユーザーの追加のみが可能で、stage ユーザーの情報の表示はできません。そのため、新たに追加された stage_user の設定サマリーを表示する代わりに、IdM はエラーを表示します。
stage_user_admin ユーザーは、stage ユーザーの情報を表示できません。そのため、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 (IdM) は、ID 管理用の外部ソリューションを使用して IdM でユーザーおよびグループ ID がプロビジョニングされるように、お使いの環境を設定するサポートをします。以下のセクションは、このような設定の例について説明します。例には以下が含まれます。

11.6.1. 外部プロビジョニングシステムで使用されるようにユーザーアカウントを設定する手順

以下の手順では、外部プロビジョニングシステムが IdM ユーザーアカウントを使用するように設定する方法を説明します。適切なパスワードポリシーが指定されたグループにアカウントを追加すると、外部プロビジョニングシステムが IdM でユーザーのプロビジョニングを管理できるようになります。
  1. stage ユーザーの追加権限のあるユーザー provisionator を作成します。外部プロビジョニングシステムがこのユーザーアカウントを使用して新しい stage ユーザーを追加します。
    1. provisionator ユーザーアカウントを追加します。
      $ ipa user-add provisionator --first=provisioning --last=account --password
    2. provisionator ユーザーに必要な権限を割り当てます。
      stage ユーザーの追加を管理する System Provisioning というカスタムロールを作成します。
      $ ipa role-add --desc "Responsible for provisioning stage users" "System Provisioning"
      Stage User Provisioning の権限をロールに割り当てます。この権限により、stage ユーザーが追加できるようになります。
      $ ipa role-add-privilege "System Provisioning" --privileges="Stage User Provisioning"
      provisionator ユーザーをロールに追加します。
      $ ipa role-add-member --users=provisionator "System Provisioning"
  2. ユーザーアカウントの管理権限を持つ activator ユーザーを作成します。このユーザーアカウントを使用すると、外部プロビジョニングシステムにより追加された stage ユーザーが自動的にアクティベートされます。
    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 ユーザーアカウントをアクティベートするように設定する手順

以下の手順では、stage ユーザーをアクティベートするスクリプトを作成する方法を説明します。システムは指定した間隔で自動的にスクリプトを実行します。これにより、新規ユーザーアカウントを自動的にアクティベートし、作成後すぐに利用できるようにします。

重要

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

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

以下の章では、さまざまなユーザーおよびグループの管理オプションのテンプレートを紹介します。これらのテンプレートを使用すると、プロビジョニングシステムの LDAP プロバイダーが IdM ユーザーアカウントを管理できるように設定できます。たとえば、従業員が退職した後にユーザーアカウントを無効にするようにシステムを設定することができます。

LDAP を使用したユーザーアカウントの管理

下層の Directory Server データベースを編集して、新規ユーザーエントリーの追加、既存のエントリーの変更、異なるライフサイクルの状態間でのユーザーの移動、ユーザーの削除ができます。データベースを編集するには ldapmodify ユーティリティーを使用します。
以下の LDIF 形式のテンプレートには、ldapmodify を使用して変更する属性に関する情報が含まれます。例に関する詳しい手順は 例11.2「ldapmodify での stage ユーザーへの追加」 および 例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 ユーザーは、ユーザーおよびグループの情報を読み込む権限があり、password はユーザーのパスワードとなっています。
# ldapsearch -LLL -x -D "uid=user_allowed_to_read,cn=users,cn=accounts,dc=example, dc=com" -w "password" -H ldap://server.example.com -b "cn=users, cn=accounts, dc=example, dc=com" uid=user_login
ユーザーの属性を変更する方法:
dn: distinguished_name
changetype: modify
replace: attribute_to_modify
attribute_to_modify: new_value
ユーザーを無効化する方法:
dn: distinguished_name
changetype: modify
replace: nsAccountLock
nsAccountLock: TRUE
ユーザーを有効化する方法:
dn: distinguished_name
changetype: modify
replace: nsAccountLock
nsAccountLock: FALSE
ユーザーを保存する方法:
dn: distinguished_name
changetype: modrdn
newrdn: uid=user_login
deleteoldrdn: 0
newsuperior: cn=deleted users,cn=accounts,cn=provisioning,dc=example
nssAccountLock 属性を更新しても、stage および preserved ユーザーには影響はありません。更新操作が正常に完了しても、属性の値は 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 または preserved ユーザーをグループには追加しないでください。更新が正常に完了した場合でも、ユーザーはグループのメンバーとして更新されません。active ユーザーだけがグループに所属します。

例11.2 ldapmodify での stage ユーザーへの追加

標準の 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 属性がプロビジョニングシステムに追加され、ステージエントリーのアクティベートの準備ができていることを確認します。新規 stage ユーザーの LDAP 属性を表示するには、ipa stageuser-show --all --raw コマンドを使用します。ユーザーは nsaccountlock 属性で明示的に無効化されていることに注意してください。
    $ ipa stageuser-show stageuser --all --raw
      dn: uid=stageuser,cn=staged users,cn=accounts,cn=provisioning,dc=example
      uid: stageuser
      sn: User
      cn: Stage
      has_password: FALSE
      has_keytab: FALSE
      nsaccountlock: TRUE
      objectClass: top
      objectClass: inetorgperson
      objectClass: organizationalPerson
      objectClass: person

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

LDAP modrdn 操作を使用して user を保存する方法:
  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. オプションで、すべての preserved ユーザーを表示して、このユーザーが保存されたことを確認します。
    $ ipa user-find --preserved=true
    ---------------
    1 user matched
    ---------------
      User login: user1
      First name: first_name
      Last name: last_name
    ...
    ----------------------------
    Number of entries returned 1
    ----------------------------

第12章 ホストの管理

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

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

登録プロセスの基本的な役割は、IdM ディレクトリー内でクライアントマシン用の ホスト エントリーを作成することです。このホストエントリーは、他のホストとドメイン内のサービスの関係を確立するために使用されます。この関係は1章Red Hat Identity Management についてで説明しているように、権限と管理をドメイン内のホストへ委任するプロセスの一部です。
ホストエントリーには、IdM 内のクライアントについて以下のような情報のすべてが含まれます。
  • ホストに関連付けられたサービスエントリー
  • ホストおよびサービスプリンシパル
  • アクセス制御ルール
  • 物理的位置やオペレーティングシステムなどのマシンについての情報
ホスト上で実行されるサービスには、IdM ドメインに属するものもあります。Kerberos プリンシパルまたは SSL 証明書のいずれか (またはこれら両方) を保存することができるサービスは、IdM サービスとして設定することができます。IdM ドメインにサービスを追加すると、そのサービスはドメインから SSL 証明書やキータブを要求することができます。(証明書の公開鍵のみがサービスレコードに保存されます。秘密鍵はサービスのローカルになります。)
An IdM ドメインは、共通の ID 情報、ポリシー、共有 サービスで、マシン間に共通性を確立します。あるドメインに所属しているマシンは、そのドメインのクライアントとして機能するので、そのドメインが提供するサービスを使用できます。An IdM ドメインは特に、以下の 3 つの主要サービスをマシンに提供します。
  • DNS
  • Kerberos
  • 証明書管理
マシンはユーザーのように、IdM が管理する ID です。クライアントマシンは DNS を使って IdM サーバー、サービス、およびドメインメンバーを識別します。これらはユーザー ID のように、IdM サーバーの 389 Directory Server インスタンスに保存されます。マシンはユーザーのように、Kerberos または証明書を使って、ドメインに対して認証することができます。
マシン側からは、これらのドメインサービスにアクセスする以下のようなタスクが実行可能です。
  • DNS ドメインへの参加 (マシン登録)
  • DNS エントリーおよびゾーンの管理
  • マシン認証の管理
IdM での認証には、ユーザーのほかにマシンも含まれます。マシン認証は、IdM がマシンを信頼して、そのマシン上にインストールされているクライアントソフトウェアからの IdM 接続を受け付けるために必要なものです。クライアントを認証すると、IdM サーバーはクライアントの要求に対応できるようになります。IdM は、マシン認証で以下の 3 つのアプローチに対応しています。
  • SSH 鍵。ホスト用の SSH 公開鍵が作成され、ホストエントリーにアップロードされます。そこから System Security Services Daemon (SSSD) は、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=localityホストの位置情報
場所--location=locationデータセンターラックなど、ホストの位置情報
Platform--platform=stringホストのハードウェアまたはアーキテクチャー
Operating system--os=stringホストのオペレーティングシステムおよびバージョン
MAC アドレス--macaddress=addressホストの MAC アドレス。これは複数値の属性です。MAC アドレスは、NIS プラグインがホスト用の NIS ethers マップを作成するために使用します。
SSH 公開鍵--sshpubkey=stringホスト用の SSH 公開鍵。これは複数値の属性なので、複数の鍵を設定できます。
Principal name (not editable)--principalname=principalホストの Kerberos プリンシパル名。これは -p オプションで明示的に別のプリンシパルを設定しなければ、クライアントのインストール中にホスト名でデフォルト設定されます。これはコマンドラインツールを使用すると変更可能ですが、UI では変更できません。
Set One-Time Password--password=string一括登録で使用可能なホストのパスワードを設定します。
---random一括登録で使用されるランダムなパスワードを生成します。
---certificate=stringホストの証明書ブロブ。
---updatednsこれは IP アドレス変更時にホストが DNS エントリーを動的に更新できるかどうかを設定します。

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

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

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

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

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

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

    DNS ゾーンは IdM で作成可能で、これは 「Master 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 ドメインから削除することになります。
ホストを再度有効にするには、ipa-getkeytab コマンドを使用するだけです。-s オプションはどの IdM サーバーにキータブを要求するかを設定し、-p はプリンシパル名を提示し、-k ではキータブを保存するファイルを提供します。
新規のホストキータブを要求する場合は、以下のようになります。
[jsmith@ipaserver ~]$  ipa-getkeytab -s ipaserver.example.com -p host/server.example.com -k /etc/krb5.keytab -D fqdn=server.example.com,cn=computers,cn=accounts,dc=example,dc=com -w password
ipa-getkeytab コマンドをアクティブな IdM クライアントまたはサーバーで実行する場合は、LDAP 認証情報 (-D および -w) なしで実行可能です。IdM ユーザーは、Kerberos 認証情報を使ってドメインに認証します。無効となっているホスト上で直接コマンドを実行するには、LDAP 認証情報を提供して IdM サーバーに認証を行います。認証情報は、再有効化を行なっているホストまたはサーバーに対応するものにしてください。

12.5. ホストの公開 SSH キーの管理

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

12.5.1. SSH 鍵の形式

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

12.5.2. ipa-client-install および OpenSSH

ipa-client-install スクリプトはデフォルトで、OpenSSH サーバーと IdM クライアントマシン上のクライアントを設定します。また SSSD がホストおよびユーザーキーのキャッシングを実行するように設定します。実質的には、クライアントを設定するだけで、ホストがキーキャッシングおよび取得のために SSSD、OpenSSH、および Identity Management を使用するすべての必須設定が実行されます。
SSH サービスがクライアントインストール時に有効にされている場合 (これがデフォルト)、ssh サービスの初回起動時に RSA キーが作成されます。

注記

ipa-client-install を使用して IdM クライアントとしてマシンを追加する場合、クライアントには RSA および DSS という 2 つの SSH キーが作成されます。
ipa-client-install コマンドには --ssh-trust-dns という設定オプションもあり、これを一緒に実行すると、OpenSSH が キーフィンガープリントを保存している IdM DNS レコードを信頼するように自動設定します。
別の方法では、--no-sshd を使ってクライアントインストール時に OpenSSH を無効にすることができます。これにより、インストールスクリプトは OpenSSH サーバーを設定できなくなります。
--no-dns-sshfp というもうひとつのオプションは、ホストが自身の DNS エントリーで DNS SSHFP レコードを作成できないようにします。これは --no-sshd オプションとの併用も可能です。

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

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

    図12.4 ホストの一覧

  5. 設定 タブの ホスト設定領域で、SSH公開鍵 の横にある 追加 をクリックします。
    SSH キーの追加

    図12.5 SSH キーの追加

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

    図12.6 SSH キーの設定

    これで SSH 公開鍵 フィールドに、新しいキーが表示されます。Show/Set key をクリックすると、追加したキーが表示されます。
  7. 複数のキーをアップロードするには、公開鍵リストの下にある Add をクリックして、他のキーをアップロードします。
  8. すべてのキーが追加されたら、ホストページ上部の Save をクリックして、変更を保存します。
公開鍵が保存されると、エントリーにはキーの指紋、コメント (ある場合)、キーのタイプが表示されます [2]
ホストキーをアップロードしたら、Identity Management を ID ドメインの 1 つとして使用するよう SSSD を設定し、OpenSSH がホストキー管理に SSSD ツールを使用するよう設定します。これは、the "Configuring Services: OpenSSH and Cached Keys" section in the System-Level Authentication Guide で説明しています。

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

ホスト SSH キーが IdM のホストエントリーに追加されるのは、host-add を使ってホストを作成する際か、エントリーを後で修正する際になります。

注記

インストールスクリプトで SSH サービスが明示的に無効にされなければ、ipa-client-install コマンドで RSA と DSS ホストキーが作成されます。
  1. host-mod コマンドを --sshpubkey オプションと実行して、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 ツールを使用するよう設定します。これは、the "Configuring Services: OpenSSH and Cached Keys" section in the System-Level Authentication Guide で説明しています。

12.5.5. ホストキーの削除

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

    図12.7 ホストの一覧

  3. SSH 公開鍵 エリアで、削除するキーの指紋の横にある Delete をクリックします。
    公開鍵の削除

    図12.8 公開鍵の削除

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

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

NIS は ethers テーブルをホストすることができます。これを使うと、システムのプラットホームやオペレーティングシステム、DNS ドメイン、および MAC アドレスに基づいて DHCP 設定ファイルを管理することができます。これらすべての情報は、IdM のホストエントリーに保存されます。
Identity Management では、各システムは、ou=ethers サブツリーのディレクトリーに含まれる適切な ethers エントリーで作成されます。
cn=server,ou=ethers,dc=example,dc=com
このエントリーは、ethers サービスの NIS マップを作成するために使用されます。ethers サービスは、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


[2] キータイプは、アップロードされたキーに含まれていない場合、キー自体から自動的に判断されます。

第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_Agroup_B の 2 つのグループを作成します。「ユーザーまたはホストグループの追加および削除」を参照してください。
  2. 以下を追加します。
    • group_A のメンバーとしてユーザーを 1 つ追加します。
    • 別のユーザーを group_B のメンバーとして追加します。
    • group_A メンバーとして group_B を追加します。
  3. Web UI で、IdentityGroups を選択します。左側のサイドバーに表示されている各グループタイプから、User Groups を選択し、group_A の名前をクリックします。Direct MembershipIndirect Membership を切り替えます。
    グループの直接および間接メンバー

    図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 ドメイン以外のアイデンティティーストアに存在するグループメンバーを追加できます。外部ストアは、ローカルシステム、Active Directory ドメイン、ディレクトリーサービスのいずれかを指定できます。
POSIX 以外の外部グループは、POSIX 属性をサポートしません。たとえば、これらのグループには、GID は定義されません。

例13.2 異なるタイプのユーザーグループの検索

  1. 全ユーザーグループを表示するには、ipa group-find コマンドを実行します。
  2. また、全 POSIX グループを表示するには、ipa group-find --posix コマンドを実行します。
  3. POSIX グループ以外のグループをすべて表示するには ipa group-find --nonposix コマンドを実行します。
  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 グループにユーザーを追加するには、ユーザーに管理者権限が割り当てられます。

警告

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 にオプションを追加します。
  • POSIX グループ以外を追加するには --nonposix
  • 外部グループを作成するには --external
グループタイプの詳細は、「IdM のユーザーグループタイプ」を参照してください。

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

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

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

  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) が最初にキャッシュを検索し、欠如した記録や期限の切れた記録のみに対してサーバー検索を実行するためです。
ホストグループに適用された変更をすぐに見るには、キャッシュパージユーティリティー sss_cache を使用して、ホストで SSSD キャッシュを更新します。ホストグループの SSSD キャッシュにおいて現在の記録を無効にするために sss_cache を使用すると、SSSD が強制的に、id プロバイダーから更新した記録を取得します。そのため、変更を素早く認識できます。
SSSD キャッシュのホストグループエントリを消去するには:
# sss_cache -n host_group_name

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

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

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

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

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

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

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

    user1user2group1 を、group_name というグループに追加するには:
    $ ipa group-add-member group_name --users=user1 --users=user2 --groups=group1
    ad_userad_domain というドメインから group_name というグループに追加するには、外部ユーザーを指定する方法を選択してください。例:
    $ 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. 削除するグループメンバーのタイプを選択します。ユーザーグループの UsersUser Groups または External などです。
    ユーザーグループメンバーの削除

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

  4. 所定のメンバーの横にあるチェックボックスを選択します。
  5. Delete をクリックします。

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

  1. オプション: ipa group-show または ipa hostgroup-show コマンドを使用して、削除するグループが含まれるグループを確定します。
  2. ユーザーグループメンバーを削除するには、ipa group-remove-member コマンドをしようします。ホストグループメンバーを削除するには ipa hostgroup-remove-member コマンドを使用します。
    ユーザーグループメンバーを削除する場合は、以下のオプションを使用してメンバーを指定します。
    • --users を指定して IdM ユーザーを削除します。
    • DOMAIN\user_name または user_name@domain の形式で、--external を指定して IdM ドメイン外に存在するユーザーを削除します。
    • --groups を指定して IdM ユーザーグループを削除します。
    ホストグループメンバーを削除する場合は、以下のオプションを使用してメンバーを指定します。
    • --hosts を指定して IdM ホストを削除します。
    • --groups を指定して IdM ホストグループを削除します。
    たとえば、group_name と呼ばれるグループから、user1user2 および 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. ユーザープライベートグループなしでのユーザー作成

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

13.4.2. 全ユーザーに対してユーザープライベートグループを無効化する方法

  1. 管理者としてログインします。
    $ kinit admin
  2. IdM は、Directory Server の Managed Entries Plug-in を使用してユーザープライベートグループを管理します。どのようなプラグインがあるかを表示するには以下を実行します。
    $ ipa-managed-entries --list
  3. IdM によりユーザープライベートグループが作成されないようにするには、ユーザープライベートグループを管理するプラグインインスタンスを無効にします。
    $ ipa-managed-entries -e "UPG Definition" disable
    Disabling Plugin

    注記

    UPG Definition インスタンスを再度有効にするには、ipa-managed-entries -e "UPG Definition" enable コマンドを使用します。
  4. Directory Server を再起動して、新しい設定を読み込みます。
    # systemctl restart dirsrv.target

13.4.3. ユーザープライベートグループを無効にしたユーザーの追加

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

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

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

前提条件

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

Web UI: 検索属性の設定

  1. IPA ServerConfiguration を選択します。
  2. User Options エリアで、User search fields のユーザー検索属性を設定します。
  3. Group Options エリアで、Group search fields のグループ検索属性を選択します。
  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. 自動グループメンバーシップとは

自動グループメンバーシップを使用して、属性をもとに自動的にユーザーとホストをグループに割り当てることができます。たとえば、以下が可能です。
  • 従業員のマネージャー、場所またはその他の属性をもとに従業員のユーザーエントリーを複数のグループに分割することができます。
  • クラス、場所、またはその他の属性をもとにホストを分割できます。
  • 全ユーザーまたは全ホストを単一のグローバグループに追加できます。

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

グループメンバーシップの手動管理によるオーバーヘッドの削減
自動グループメンバーシップでは、管理者はユーザーとホストをグループに手動で割り当てる必要がありません。
ユーザーおよびホスト管理での一貫性向上
自動グループメンバーシップでは、厳密に定義され、自動評価された基準をもとに、ユーザーおよびホストが割り当てられます。
グループベースの設定管理の容易化
様々な設定がグループに定義されており、sudo ルール、automount、またはアクセス制御など、個別のグループメンバーに適用されます。自動グループメンバーを使用する場合には、ユーザーおよびホストは自動的に特定のグループに追加され、グループベースの設定の管理が簡素化されます。

13.6.1.3. Automember ルール

自動グループメンバーシップを設定する際には、管理者は automember ルール を定義します。automember ルールは、特定ユーザーまたはホストグループに適用されます。このルールには、ユーザーまたはホストが満たす必要のある 条件 が含まれており、それをもとにグループに追加、グループから除外されます。
包含条件
ユーザーまたはホストのエントリーが包含ルールを満たす場合には、グループに含まれます。
除外の条件
ユーザーまたはホストのエントリーが除外の条件を満たす場合にはグループに追加 されません
これらの条件は、Perl-compatible regular expressions (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. Add をクリックします。
  3. Automember rule フィールで、ルールを適用するグループを選択します。Add and Edit をクリックします。
  4. 包含および除外条件を 1 つ以上定義します。詳細は「Automember ルール」を参照してください。
    1. Inclusive または Exclusive セクションで Add をクリックします。
    2. Attribute フィールドで、必要な属性を選択します。
    3. Expression フィールドで、正規表現を定義します。
    4. Add をクリックします。
    たとえば、以下の条件は、ユーザーログインの属性 (uid) のすべての値 (.*) を対象としています。
    Automember ルール条件の追加

    図13.5 Automember ルール条件の追加

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

  1. ipa automember-add コマンドを使用して、automember ルールを追加します。プロンプトが表示されたら、以下を指定します。
    • 対象のグループ名と一致する Automember rule
    • ルールの対象がユーザーグループか、ホストグループかを指定する 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 rule
      • フィルターを適用するエントリー属性を指定する Attribute Key。たとえば、ユーザーの manager などです。
      • ルールの対象がユーザーグループか、ホストグループかを指定する Grouping Type。ユーザーグループを対象とするには group、ホストグループを対象とする場合は hostgroup を入力してください。
      • 正規表現として 1 つまたは複数の条件を指定する Inclusive regex および Exclusive regex。条件を 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 コマンドライン: 単一のグループに全エントリーを追加する Automember ルールの作成

cn または fqdn など、全ユーザーまたはホストエントリーが含む属性の包含条件を作成すると、今後作成されるユーザーまたはホストのすべてが単一のグループに追加されるようになります。
  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 ユーザー用の Automember ルールの作成

Active Directory (AD) から同期された Windows ユーザーは ntUser オブジェクトクラスを共有します。objectclass 属性に ntUser が含まれる全ユーザーを対象とする 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 単一のユーザーまたはホストの自動メンバーシップの再構築

コマンドライン: 既存のエントリーの自動メンバーシップの再構築

全ユーザーの自動メンバーシップを再構築するには 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 グループを設定すると、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 つの組織に異なる複数のドメインがある場合は、一意の UID および GID の必要性は IdM ドメイン全体に適用されます。

14.1. ID の範囲

UID および GID 番号は ID の範囲 に分けられます。個別のサーバーとレプリカでそれぞれの数的範囲を維持することで、サーバーまたはレプリカがあるエントリーに発行した ID の値が他のサーバーやレプリカが発行したものと重複する可能性が最小限に抑えられます。
Distributed Numeric Assignment (DNA) プラグインはドメイン用バックエンドの 389 Directory Server インスタンスの一部で、これにより範囲がサーバーおよびレプリカ間で更新、共有されます。このプラグインは、全マスターとレプリカの ID 範囲を管理します。各サーバーまたはレプリカには、現行 ID 範囲と新たな 次の ID 範囲があります。前者の番号を使い果たすと、後者の番号が使用されます。DNA Directory Server プラグインの詳細については、Red Hat Directory Server Deployment Guide を参照してください。

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

サーバーのインストール中に、ipa-server-install コマンドはデフォルトでランダムな現行 ID 範囲をインストール先に自動的に割り当てます。設定スクリプトがランダムで、合計 1 万 の範囲から 20 万 ID のある範囲を選択します。このようにランダムな範囲を選択することで、もし 2 つの別個の IdM ドメインを将来マージした場合でも、ID が競合する可能性を大幅に抑えられます。
ただし、サーバーインストール中に ipa-server-install コマンドで以下の 2 つのオプションを使用すると、手動で現行 ID 範囲を定義することができます。
  • --idstart は、UID および GID 番号の最初の値を提供します。デフォルトでは、この値はランダムで選択されます。
  • --idmax は、UID および GID 番号の最大値を提供します。デフォルトでは、この値は --idstart の最初の値に 199,999 を加えたものになります。
単一の IdM サーバーがインストールされている場合、新規ユーザーもしくはグループのエントリーには範囲全体からランダムな ID が割り当てられます。新規レプリカをインストールしてこのレプリカが独自の ID 範囲をリクエストすると、サーバーの元の ID 範囲が分割されて、サーバーとレプリカに分配されます。レプリカには、元のマスターで利用可能な残りの ID 範囲の半分が与えられます。その後は、サーバーとレプリカはそれぞれ、新規エントリーに対して各 ID 範囲を使用します。また、レプリカに割り当てられた ID 範囲の残りの ID が 100 を切ると (つまり、割り当て ID 範囲がなくなりそうになると)、レプリカは他の利用可能なサーバーに連絡して新たな ID 範囲をリクエストします。
サーバーが ID 範囲を受け取るのは、DNA プラグインが最初に使われる時です。それまでは、サーバーには定義された ID 範囲がありません。たとえば、マスターサーバーからレプリカを作成する際には、このレプリカは即座に ID 範囲を受け取るわけではありません。レプリカが元のマスターからの ID 範囲をリクエストするのは、最初の ID がレプリカに割り当てられる直前になります。

注記

レプリカが元のマスターから ID 範囲をリクエストする前にこのマスターが機能停止した場合は、レプリカはマスターに連絡できなくなります。このため、新規ユーザーをレプリカに追加使用とすると、これは失敗します。このような場合には、機能しなくなったマスターに割り当てられた ID 範囲を確認し、そこから手動で ID 範囲をレプリカに割り当てることができます。この方法については 「手動での ID 範囲の拡張および新規 ID 範囲の割り当て」 で説明しています。

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

サーバーに設定されている ID 範囲を表示するには、以下のコマンドを使用します。
  • ipa-replica-manage dnarange-show は、全サーバーに設定されている現行 ID 範囲、またはサーバーを指定した場合はそのサーバーの現行 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 範囲、またはサーバーを指定した場合はそのサーバーの現行 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
これらのコマンドについての詳細は、ipa-replica-manage(1) man ページを参照してください。

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

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

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

場合によっては、手動で ID 範囲を調整する必要があることもあります。
割り当て ID 範囲を使い果たした場合
レプリカが割り当てられた ID 範囲を使い切ってしまい、他のレプリカの ID 範囲に利用可能な ID がないと、新たな ID のリクエストは失敗します。このような場合には、元のレプリカに割り当てられた ID 範囲を拡張します。これを実行するには、既存の ID 範囲を分割したり、サーバーに設定されていた元の ID 範囲を超える拡張を行ったりします。また、新規の ID 範囲を割り当てることもできます。

注記

新規の ID 範囲を割り当てる場合、サーバーまたはレプリカ上の既存エントリーの UID はそのまま変わりません。現行 ID の範囲を変更しても、IdM は過去に割り当てられた範囲のレコードを維持しているため、これが問題になることはありません。
レプリカが機能停止した場合
レプリカが停止して削除する必要がある場合には、ID 範囲は自動的には取得されません。つまり、そのレプリカに割り当てられていた ID 範囲は使用できなくなります。この ID 範囲を回復させて他のレプリカで使用できるようにします。
機能停止してしまったサーバーに属していた ID 範囲を回復させて別のサーバーにこれを割り当てるには、まず ipa-replica-manage dnarange-show コマンドを使用して ID 範囲の値を確認します。このコマンドについては、「現在割り当てられている 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 の値を別のエントリーに割り当てる結果になります。
1000 およびそれ以下の値の UID を含む ID 範囲は設定しないでください。これらの値はシステム用に予約されています。また、0を含む ID 範囲は設定しないでください。SSSD サービスは 0 ID の値を処理しません。
手動で 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 は uidNumber および gidNumber という別の属性で設定されるため、この状況では競合は発生しません。

注記

同一 ID をユーザーとグループに設定すると、ユーザーのプライベートグループを設定できるようになります。この方法でユーザーに一意のシステムグループを作成するには、同一 ID をユーザーとグループに設定し、このグループのメンバーをこのユーザーのみにします。

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

ユーザーが IdM システムやサービスにログインすると、そのシステム上の SSSD はそのユーザー名をユーザーの UID および GID とキャッシュします。SSSD はその UID をユーザー特定のキーとして使用します。同一のユーザー名で別の UID を持つユーザーがシステムにログインしようとすると、SSSD は 2 つの UID を記録し、競合する名前を持つ別の 2 人のユーザーとみなします。この場合、ユーザーの UID が変更されると問題となる可能性があります。この状況では、SSSD は同一ユーザーが別の UID を持っているとは認識せず、変更された UID のユーザーを間違って新規ユーザーとみなします。既存ユーザーの UID が変更されると、ユーザーは SSSD と関連するサービスおよびドメインにログインできなくなります。これは、識別情報に 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 のオブジェクトクラス
mepOriginEntryManaged エントリー (テンプレート) のオブジェクトクラス
ユーザーエントリーには多くの利用可能な属性があります。手動で設定されるものや、特定の値が設定されてない場合はデフォルト値を元に設定されるものもあります。その属性に UI やコマンドライン引数がない場合でも、表15.1「デフォルトの Identity Management ユーザーオブジェクトクラス」 内のオブジェクトクラスで使用できる属性を追加するオプションもあります。また、デフォルトの属性で生成もしくは使用される値は、「デフォルトのユーザーおよびグループ属性の指定」 にあるように設定可能です。

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

UI フィールドコマンドラインオプション必須、オプション、またはデフォルト[a]
User loginusername必須
First name--first必須
Last name--last必須
Full name--cnオプション
Display name--displaynameオプション
Initials--initialsデフォルト
Home directory--homedirデフォルト
GECOS field--gecosデフォルト
Shell--shellデフォルト
Kerberos principal--principalデフォルト
Email address--emailオプション
パスワード--password [b]オプション
User ID number--uidデフォルト
Group ID number--gidnumberデフォルト
Street address--streetオプション
City--cityオプション
State/Province--stateオプション
Zip code--postalcodeオプション
Telephone number--phoneオプション
Mobile telephone number--mobileオプション
Pager number--pagerオプション
Fax number--faxオプション
Organizational unit--orgunitオプション
Job title--titleオプション
Manager--managerオプション
Car license--carlicenseオプション
--noprivateオプション
SSH Keys--sshpubkeyオプション
Additional attributes--addattrオプション
Department Number--departmentnumberオプション
Employee Number--employeenumberオプション
Employee Type--employeetypeオプション
Preferred Language--preferredlanguageオプション
[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 インスタンスにカスタムスキーマ要素すべてを追加します。スキーマ要素の追加については、the schema chapter of the 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 インスタンスにカスタムスキーマ要素すべてを追加します。スキーマ要素の追加については、the schema chapter of the 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}

注記

中括弧オプションを使用するには、brace expansion 機能を有効にする必要があります。これには、以下のように set コマンドを使用します。
# set -o braceexpand

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

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

15.3.1. Web UI での操作

  1. Identity Management が使用する 389 Directory Server インスタンスにカスタムスキーマ要素すべてを追加します。スキーマ要素の追加については、the schema chapter of the 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 インスタンスにカスタムスキーマ要素すべてを追加します。スキーマ要素の追加については、the schema chapter of the 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 デフォルトのユーザーパラメーター

フィールドコマンドラインオプション説明
Maximum user name length--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--userobjectclassesIdM ユーザーアカウント作成に使用されるオブジェクトクラスを定義します。これは、複数回使用することができます。このリストはコマンド実行時に上書きされるので、オブジェクトクラスの完全一覧を提供する必要があります。
Default group object classes--groupobjectclassesIdM グループアカウント作成に使用されるオブジェクトクラスを定義します。これは、複数回使用することができます。このリストはコマンド実行時に上書きされるので、オブジェクトクラスの完全一覧を提供する必要があります。
Password expiration notification--pwdexpnotifyパスワードの有効期限が切れる何日前にサーバーが通知を送信するかを設定します
Password plug-in features ユーザーが使用可能なパスワードの形式を設定します。

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

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

    図15.4 検索での制限設定

    ユーザー属性

    図15.5 ユーザー属性

    グループ属性

    図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 証明書やキータブを要求することができます。(証明書の公開鍵のみがサービスレコードに保存されます。秘密鍵はサービスのローカルになります。)
An IdM ドメインは、共通の ID 情報、ポリシー、共有 サービスで、マシン間に共通性を確立します。あるドメインに所属しているマシンは、そのドメインのクライアントとして機能するので、そのドメインが提供するサービスを使用できます。(1章Red Hat Identity Management について の説明にあるように) An IdM ドメインは特に、以下の 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_config 内で GSSAPIStrictAcceptorCheck no と設定します。
    • mod_auth_kerb では、/etc/httpd/conf.d/auth_kerb.conf 内で KrbServiceName 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. 複数のサーバー向けの既存のキータブ取得

クラスターの環境などのシナリオでは、共通のホスト名を使用するサービスに対して、異なるマシンで同じキータブファイルが必要な場合があります。各ホストで同じキータブを取得するには、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 から client1 権限を委任します。
    [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 のキータブを取得します。
    [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. Add をクリックして選択ボックスを閉じ、委任設定を保存します。

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

サービスおよびホストの両方において、クライアントに権限が委任されている場合、ローカルマシン上でそのプリンシパルのキータブを取得することができます。サービスの場合はservice/hostname@REALM という形式になり、ホストの場合は servicehost で置き換えます。
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 ユーザーもしくはグループ属性の新規の値を指定でき、どのクライアントホストに新たな値を適用するかを定義することができます。
ID ビューを使用すると、以下のようなことが可能になります。

重要

ID ビューが適用できるのは IdM クライアントのみで、IdM サーバーには適用できません。

SSSD パフォーマンスへのマイナス影響の可能性

ID ビューを適用すると、特定の最適化と ID ビューが同時に実行できなくなるので、SSSD パフォーマンスにマイナス影響が出る可能性があります。たとえばID ビューは、SSSD によるサーバー上でグループルックアップのプロセス最適化を妨げます。
  • ID ビューを使用すると、グループ名が上書きされた場合、SSSD は返されたグループメンバー名リストの各メンバーをチェックする必要があります。
  • ID ビューを使用しないと、SSSD はグループオブジェクトのメンバー属性からユーザー名を収集するだけで済みます。
このマイナス影響は、SSSD キャッシュが空であるか、キャッシュをクリアした後 (この場合は全エントリーが無効になります) に顕著になります。

関連資料

ID ビューには、Active Directory が関連する環境でのユースケースもあります。詳細は、『Windows 統合ガイド』 の Active Directory 環境での ID ビューの使用 を参照してください。

18.1. ID ビューで上書き可能な属性

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

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

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

18.3. ホストごとにユーザーアカウントで異なる属性値を定義する

管理者は、ユーザーアカウントで使用される属性値を上書きする複数の ID ビューを作成し、これらの ID ビューを異なるクライアントホストに適用することが可能です。たとえば、サービスアカウントは、異なるホストで認証を行う場合に、異なる SSH 公開鍵を使用するように設定できます。
本セクションでは、以下の手順を説明します。
これらの手順では、host1.example.com という名前のクライアントホスト用に ID ビューを作成する方法について説明します。他のホストにある属性値も上書きする場合には、各ホストごとに 1 つずつ、複数の ID ビューを作成する手順を使用してください。
手順では、以下を前提としています。
  • user は、属性を上書きするユーザーアカウントになります。
  • host1.example.com は、ID ビューを適用するホストになります。

重要

新規 ID ビューを作成したら、ID ビューを適用する全クライアントで SSSD を再起動します。
新規 ID ビューが UID または GID を変更した場合は、クライアントで SSSD キャッシュもクリックしてください。

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

ID ビューを管理する前に、admin など必要な権限のあるユーザーとして IdM web UI にログインします。

新規 ID ビューの作成

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

    図18.1 ID ビューの追加

  3. Add をクリックして確定します。
これで新規 ID ビューが ID ビュー一覧に表示されます。
ID ビュー一覧

図18.2 ID ビュー一覧

ユーザー上書きを ID ビューに追加する

  1. ID ビュー一覧で、ID ビューの名前をクリックします。
    ID ビューの編集

    図18.3 ID ビューの編集

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

図18.4 上書き一覧

上書きする属性の指定

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

    図18.5 上書きの編集

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

      図18.6 SSH 公開鍵の追加

    2. 公開鍵に貼り付けます。

    注記

    IdM へのSSH キーの追加に関する詳細は、「ユーザーの公開 SSH キーの管理」 を参照してください。
  3. Save をクリックして上書きを更新します。

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

  1. ID ビュー一覧で、ID ビューの名前をクリックします。
    ID ビューの編集

    図18.7 ID ビューの編集

  2. Hosts タブで Apply to hosts をクリックします。
  3. host1.example.com ホストを選択して、Prospective コラムに移動します。
  4. Apply をクリックします。
これでこのホストは ID ビューが適用されるホスト一覧に表示されます。
ID ビューが適用されるホスト一覧

図18.8 ID ビューが適用されるホスト一覧

18.3.2. コマンドライン: 特定ホスト向けの属性値の上書き

ID ビューを管理する前に、以下のように必要な特権のあるユーザー用のチケットをリクエストします。
$ kinit admin
  1. 新規 ID ビューを作成します。たとえば、example_for_host1 という名前の ID ビューを作成するには、以下を実行します。
    $ ipa idview-add example_for_host1
    ---------------------------
    Added ID View "example_for_host1"
    ---------------------------
      ID View Name: example_for_host1
  2. ユーザー上書きを example_for_host1 ID ビューに追加します。ipa idoverrideuser-add コマンドでは、ID ビューの名前と上書きするユーザーが必要になります。
    • 新規の属性値を指定するには、対応するコマンドラインオプションも追加します。利用可能なオプション一覧については、ipa idoverrideuser-add --help を実行すると確認できます。たとえば、SSH 公開鍵の値を上書きするには、--sshpubkey オプションを使用します。
      $ ipa idoverrideuser-add example_for_host1 user --sshpubkey="ssh-rsa AAAAB3NzaC1yrRqFE...gWRL71/miPIZ user@example.com"
      -----------------------------
      Added User ID override "user"
      -----------------------------
        Anchor to override: user
        SSH public key: ssh-rsa
                        AAAB3NzaC1yrRqFE...gWRL71/miPIZ
      		  user@example.com

      注記

      IdM へのSSH キーの追加に関する詳細は、「ユーザーの公開 SSH キーの管理」 を参照してください。
    • ipa idoverrideuser-add --certificate コマンドは、指定した ID ビュー内のアカウントの既存証明書すべてを置き換えます。新たな証明書を追加するには、代わりに ipa idoverrideuser-add-cert コマンドを使用します。
      $ ipa idoverrideuser-add-cert example_for_host1 user --certificate="MIIEATCC..."
    • ipa idoverrideuser-mod コマンドを使用すると、既存のユーザー上書きに新たな属性値を指定することもできます。
  3. example_for_host1host1.example.com ホストに適用します。
    $ ipa idview-apply example_for_host1 --hosts=host1.example.com
    -----------------------------
    Applied ID View "example_for_host1"
    -----------------------------
    hosts: host1.example.com
    ---------------------------------------------
    Number of hosts the ID View was applied to: 1
    ---------------------------------------------

    注記

    ipa idview-apply コマンドは、--hostgroups オプションも受け取ります。このオプションは、指定されたホストグループに属するホストに ID ビューを適用しますが、ID ビューをホストグループ自体に関連付けることはしません。代わりに --hostgroups オプションは指定されたホストグループのメンバーを拡張し、--hosts オプションを個別にメンバーに対して適用します。

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

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

第20章 Kerberos フラグとプリンシパルエイリアスの管理

20.1. サービスおよびホスト向けの Kerberos フラグ

Kerberos チケット動作の特定の側面を定義するには、各種 Kerberos フラグを使うことができます。これらのフラグは、サービスとホスト Kerberos プリンシパルに追加することができます。
Identity Management (IdM) のプリンシパルは、以下の Kerberos フラグを受け付けます。
OK_AS_DELEGATE
委任用に信頼する Kerberos チケットを指定するには、このフラグを使用します。
Active Directory (AD) クライアントは、Kerberos チケット上の OK_AS_DELEGATE フラグをチェックして、ユーザー認証情報を特別のサーバーに転送または委任できるかどうかを判断します。AD は OK_AS_DELEGATE セットのあるサービスまたはホストにのみ、Ticket-Granting Ticket (TGT) を転送します。このフラグがあると、システムセキュリティサービスデーモン (SSSD) は AD ユーザー TGT を IdM クライアントマシン上のデフォルトの Kerberos 認証情報キャッシュに追加することができます。
REQUIRES_PRE_AUTH
事前に認証されたチケットのみがプリンシパルに認証可能と指定するには、このフラグを使用します。
REQUIRES_PRE_AUTH フラグが設定されている場合は、キー配布センター (KDC) は新たな認証を必要します。TGT が事前に認証されている場合にのみ、KDC は REQUIRES_PRE_AUTH のあるプリンシパル用の TGT を発行します。
REQUIRES_PRE_AUTH 消去すると、選択したサービスまたはホストの事前認証を無効化できます。この場合、KDC の負荷は下がりますが、長期のキーへのブルートフォース攻撃が成功する確率が少し高くなります。
OK_TO_AUTH_AS_DELEGATE
OK_TO_AUTH_AS_DELEGATE フラグを使用して、サービスがユーザーに代わって Kerberos チケットを取得できることを指定します。これはプロトコルの移行を行うには十分ですが、ユーザーに代わってその他のチケットを取得するには、サービスに、キー配布センター側で OK_AS_DELEGATE フラグと一致するポリシー決定が許可される必要があることに注意してください。

20.1.1. Web UI で Kerberos フラグを設定する

OK_AS_DELEGATEREQUIRES_PRE_AUTH、またはOK_TO_AUTH_AS_DELEGATE をプリンシパルに追加するには:
  1. Identity メインタブから Services サブタブを選択します。
    サービス一覧

    図20.1 サービス一覧

  2. フラグを追加するサービスをクリックします。
  3. 設定するオプションを確認します。例えば、REQUIRES_PRE_AUTH フラグを設定するには、Requires pre-authentication オプションを確認します。
    AREQUIRES_PRE_AUTH フラグの追加

    図20.2 AREQUIRES_PRE_AUTH フラグの追加

    以下の表では、Kerberos フラグと、Web UI で対応する名前が一覧表示されています。

    表20.1 Web UI での Kerberos フラグのマッピング

    Kerberos フラグ名Web UI オプション
    OK_AS_DELEGATE委任用に信頼
    REQUIRES_PRE_AUTH事前認証が必要
    OK_TO_AUTH_AS_DELEGATEユーザーとしての認証に信頼

20.1.2. コマンドラインからの Kerberos フラグの設定と削除

コマンドラインからプリンシパルにグラフを追加または削除するには、ipa service-mod コマンドに以下のいずれかのオプションを追加します。
  • OK_AS_DELEGATE には --ok-as-delegate を追加
  • REQUIRES_PRE_AUTH には --requires-pre-auth を追加
  • OK_TO_AUTH_AS_DELEGATE--ok-to-auth-as-delegate
フラグを追加するには、対応するオプションを 1 に設定します。たとえば、OK_AS_DELEGATE フラグを service/ipa.example.com@EXAMPLE.COM プリンシパルに追加するには、以下を実行します。
$ ipa service-mod service/ipa.example.com@EXAMPLE.COM --ok-as-delegate=1
フラグを削除または無効にするには、対応するオプションを 0 に設定します。たとえば、REQUIRES_PRE_AUTH フラグを test/ipa.example.com@EXAMPLE.COM プリンシパルで無効にするには、以下を実行します。
$ ipa service-mod test/ipa.example.com@EXAMPLE.COM --requires-pre-auth=0

20.1.3. コマンドラインからの Kerberos フラグの表示

OK_AS_DELEGATE が現在プリンシパルに設定されているかどうかを確認するには:
  1. kvno ユーティリティーを実行します。
  2. klist -f コマンドを実行します。
OK_AS_DELEGATE は、klist -f 出力において O 文字として示されています。
$ kvno test/ipa.example.com@EXAMPLE.COM
$ klist -f
Ticket cache: KEYRING:persistent:0:0
Default principal: admin@EXAMPLE.COM

Valid starting		Expires			Service principal
02/19/2014 09:59:02	02/20/2014 08:21:33	test/ipa/example.com@EXAMPLE.COM
    Flags: FATO

表20.2 kerberos フラグの省略

Kerberos フラグ名省略形
OK_AS_DELEGATEO
REQUIRES_PRE_AUTHA
OK_TO_AUTH_AS_DELEGATEF
プリンシパルにどのフラグが設定されているかを調べるには、kadmin.local ユーティリティーを使用します。現行フラグは、以下のように kadmin.localの出力の Attributes の行に表示されます。
# kadmin.local
kadmin.local: getprinc test/ipa.example.com
Principal: test/ipa.example.com@EXAMPLE.COM
Expiration date: [never]
...
Attributes: REQUIRES_PRE_AUTH OK_AS_DELEGATE OK_TO_AUTH_AS_DELEGATE
Policy: [none]

20.2. ユーザー、ホスト、およびサービス向け Kerberos プリンシパルエイリアスの管理

新規のユーザー、ホスト、またはサービスを作成すると、以下のフォーマットで Kerberos プリンシパルが自動的に追加されます。
  • user_name@REALM
  • host/host_name@REALM
  • service_name/host_name@REALM
場合によっては、ユーザー、ホスト、またはサービスがエイリアスを使って Kerberos アプリケーションに認証できるようにすると管理者に有益なこともあります。たとえば、以下のような場合です。
  • ユーザー名を変更したものの、ユーザーが以前のユーザー名と新たなユーザー名の両方を使ってログインする場合。
  • IdM Kerberos レルムが E メールのドメインと異なる場合でも、ユーザーが E メールアドレスを使用してログインする必要がある場合。
ユーザー名を変更した場合は、オブジェクトがエイリアスと以前の正規のプリンシパル名を保持することに注意してください。

20.2.1. Kerberos プリンシパルのエイリアス

Kerberos プリンシパルエイリアスの追加

エイリアス名 useralias をアカウント user に追加するには、以下を入力します。
[root@ipaserver ~]# ipa user-add-principal user useralias
--------------------------------
Added new aliases to user "user"
--------------------------------
         User login: user
    Principal alias: user@IDM.EXAMPLE.COM, useralias@IDM.EXAMPLE.COM
ホストまたはサービスにエイリアスを追加するには、代わりにそれぞれ ipa host-add-principal または ipa service-add-principal コマンドを使用します。
認証にエイリアス名を使用する場合は、-C オプションを kinit コマンドに渡します。
[root@ipaserver ~]# kinit -C useralias
Password for user@IDM.EXAMPLE.COM:

Kerberos プリンシパルエイリアスの削除

エイリアス useralias をアカウント user から削除するには、以下を入力します。
[root@ipaserver ~]# ipa user-remove-principal user useralias
--------------------------------
Removed aliases from user "user"
--------------------------------
  User login: user
  Principal alias: user@IDM.EXAMPLE.COM
ホストまたはサービスからエイリアスを削除するには、代わりにそれぞれ ipa host-remove-principal または ipa service-remove-principal コマンドを使用します。
正規のプリンシパル名は削除できないことに注意してください。
[root@ipaserver ~]# ipa user-show user
  User login: user
  ...
  Principal name: user@IDM.EXAMPLE.COM
  ...

[root@ipaserver ~]# ipa user-remove-principal user user
ipa: ERROR: invalid 'krbprincipalname': at least one value equal to the canonical principal name must be present

20.2.2. Kerberos エンタープライズプリンシパルのエイリアス

エンタープライズプリンシパルエイリアスには、ユーザープリンシパル名 (UPN) サフィックス、NetBIOS 名、または信頼される Active Directory フォレストドメインのドメイン名を除いて、いかなるドメインサフィックスを使用することができます。

注記

エンタープライズプリンシパルエイリアスを追加または削除する際には、2 つのバックスラッシュ (\\) を使って @ 記号をエスケープします。これを使用しないとシェルは @ を Kerberos レルム名の一部として解釈し、以下のエラーが表示されます。
ipa: ERROR: The realm for the principal does not match the realm for this IPA server

Kerberos エンタープライズプリンシパルのエイリアスの追加

エンタープライズプリンシパルエイリアス user@example.comuser アカウントに追加するには、以下を実行します。
[root@ipaserver ~]# ipa user-add-principal user user\\@example.com
--------------------------------
Added new aliases to user "user"
--------------------------------
         User login: user
    Principal alias: user@IDM.EXAMPLE.COM, user\@example.com@IDM.EXAMPLE.COM
ホストまたはサービスにエンタープライズエイリアスを追加するには、代わりにそれぞれ ipa host-add-principal または ipa service-add-principal コマンドを使用します。
認証にエンタープライズプリンシパル名を使用する場合は、-E オプションを kinit コマンドに渡します。
[root@ipaserver ~]# kinit -E user@example.com
Password for user\@example.com@IDM.EXAMPLE.COM:

Kerberos エンタープライズプリンシパルエイリアスの削除

エンタープライズプリンシパルエイリアス user@example.com をアカウント user から削除するには、以下を入力します。
[root@ipaserver ~]# ipa user-remove-principal user user\\@example.com
--------------------------------
Removed aliases from user "user"
--------------------------------
  User login: user
  Principal alias: user@IDM.EXAMPLE.COM
ホストまたはサービスからエイリアスを削除するには、代わりにそれぞれ ipa host-remove-principal または ipa service-remove-principal コマンドを使用します。

第21章 NIS ドメインおよびネットグループとの統合

21.1. NIS と Identity Management

UNIX 環境では、ネットワーク情報サービス (NIS) が ID と認証を集中管理する一般的な方法です。NIS は Yellow Pages (YP) と呼ばれていたこともあり、以下のような認証と ID の情報を集中的に管理します。
  • ユーザーとパスワード
  • ホスト名および IP アドレス
  • POSIX グループ
現代のネットワークでは、NIS はホスト認証を提供せず、ネットワーク上でデータを暗号化せずに送信するため、安全とはみなされていません。この問題を回避するために、NIS は他のプロトコルと統合してセキュリティーを強化することがよくあります。
Identity Management (IdM) を利用すると、NIS サーバープラグインを使って、IdM に完全に移行できないクライアントに接続することができます。IdM は、netgroup と他の NIS データを IdM ドメインに統合します。また、ユーザーおよびホストの ID を NIS ドメインから IdM に移行することも容易になります。

Identity Management での NIS

NIS オブジェクトは、RFC 2307 に従って、Directory Server のバックエンドに統合、保存されます。IdM は NIS オブジェクトを LDAP ディレクトリーに作成し、クライアントは暗号化された LDAP 接続を使用して、これらをたとえば System Security Services Daemon (SSSD) や nss_ldap から取得します。
IdM は、netgroup、アカウント、グループ、ホスト、および他のデータを管理します。IdM は NIS リスナーを使ってパスワード、グループ、および netgroup を IdM エントリーにマッピングします。

Identity Management での NIS プラグイン

NIS のサポートに IdM は以下のプラグインを使用します。これらは、slapi-nis パッケージで提供されます。
NIS サーバープラグイン
NIS サーバープラグインを使用すると、IdM 統合の LDAP サーバーはクライアント用の NIS サーバーとして機能することができます。この場合、設定に従って Directory Server が動的に NIS マップを生成し、更新します。このプラグインを使用することで、IdM は、NIS プロトコルを NIS サーバーとして使用するクライアントの要求に応えます。
詳細情報は、「Identity Management で NIS を有効にする」 を参照してください。
スキーマ互換性プラグイン
このプラグインを使用すると、Directory Server バックエンドがディレクトリー情報ツリー (DIT) の一部の保存されているエントリーの別のビューを提供できるようになります。これには、属性値の追加、削除、名前変更や、ツリーの複数のエントリーから属性の値を取得することなどが含まれます。
詳細については、/usr/share/doc/slapi-nis-version/sch-getting-started.txt ファイルを参照してください。

21.1.1. Identity Management での NIS Netgroup

NIS エンティティーは netgroup に保存出来ます。UNIX グループと比べると、netgroup は以下をサポートします。
  • 入れ子グループ (他のグループのメンバーとしてのグループ)
  • ホストのグループ化
netgroup では、ホスト、ユーザー、およびドメインが定義されます。これら情報のセットは triple と呼ばれ、これらのフィールドには以下が含まれます。
  • ダッシュ (-)。これは、有効な値がないことを意味します。
  • 値なし。フィールドが空の場合は、ワイルドカードを意味します。
(host.example.com,,nisdomain.example.com)
(-,user,nisdomain.example.com)
クライアントが NIS netgroup をリクエストすると、IdM は LDAP エントリーを以下に変換します。
  • 従来の NIS マップ。NIS プラグインを使用して NIS プロトコルによりクライアントにこれを送信します。
  • LDAP 形式。これは RFC 2307 または RFC 2307bis 準拠になります。

21.1.1.1. NIS Netgroup エントリーの表示

IdM はユーザーとグループを memberUser 属性に、ホストとホストグループを memberHost に保存します。以下の例では、IdM の Directory Server コンポーネントにある netgroup エントリーを表示しています。

例21.1 Directory Server 内の NIS エントリー

dn: ipaUniqueID=d4453480-cc53-11dd-ad8b-0800200c9a66,cn=ng,cn=alt,...
...
cn: netgroup1
memberHost: fqdn=host1.example.com,cn=computers,cn=accounts,...
memberHost: cn=VirtGuests,cn=hostgroups,cn=accounts,...
memberUser: cn=demo,cn=users,cn=accounts,...
memberUser: cn=Engineering,cn=groups,cn=accounts,...
nisDomainName: nisdomain.example.com
IdM では、ipa netgroup-* コマンドを使って netgroup エントリーを管理します。たとえば、netgroup エントリーを表示するには、以下を実行します。

例21.2 Netgroup エントリーの表示

[root@server ~]# ipa netgroup-show netgroup1
Netgroup name: netgroup1
Description: my netgroup
NIS domain name: nisdomain.example.com
Member Host: VirtGuests
Member Host: host1.example.com
Member User: demo
Member User: Engineering

21.2. Identity Management で NIS を有効にする

Identity Management で NIS を有効にするには、以下の手順に従います。
  1. NIS リスナーと互換性プラグインを有効にします。
    [root@ipaserver ~]# ipa-nis-manage enable
    [root@ipaserver ~]# ipa-compat-manage enable
  2. オプションで、NIS リモートプロシージャーコール (RPC) 用に固定ポートを設定します。
    NIS の使用時には、クライアントは IdM サーバー上のどのポートを使って接続を確立するかを知る必要があります。IdM はデフォルト設定を使用して、サーバーの起動時に未使用のランダムポートにバインドします。このポートは、クライアントがポート番号のリクエストに使用するポートマッパーサービスに送信されます。
    ファイアウォール設定を厳密にする場合には、固定ポートを設定出来ます。たとえば、ポートを 514 に設定するには、以下を実行します。
    [root@ipaserver ~]# ldapmodify -x -D 'cn=directory manager' -W
    dn: cn=NIS Server,cn=plugins,cn=config
    changetype: modify
    add: nsslapd-pluginarg0
    nsslapd-pluginarg0: 514

    注記

    この設定には、1024 より下のポート番号で未使用のものを使用できます。
  3. ポートマッパーサービスを有効にして、起動します。
    [root@ipaserver ~]# systemctl enable rpcbind.service
    [root@ipaserver ~]# systemctl start rpcbind.service
  4. Directory Server を再起動します。
    [root@ipaserver ~]# systemctl restart dirsrv.target

21.3. Netgroups の作成

21.3.1. Netgroup の追加

Netgroup の追加には、以下のいずれかを使用します。

Web UI: Netgroup の追加

  1. IdentityGroupsNetgroups を選択します。
  2. Add をクリックします。
  3. 一意の名前と、オプションで説明を入力します。グループ名は、IdM ドメインの netgroup で使用される識別子です。これは後で変更できません。
  4. Add and Edit をクリックして変更を保存し、エントリーの編集を開始します。
  5. デフォルトの NIS メインが IdM ドメイン名に設定されます。 オプションで、別の NIS ドメイン名を NIS ドメイン名フィールドに入力することもできます。
    Netgroup タブ

    図21.1 Netgroup タブ

    NIS domain name フィールドでは、netgroup の tripleに表示されるドメインを設定します。これは、Identity Management リスナーが応答する NIS ドメインに影響するものではありません。
  6. 「Web UI: Netgroup にメンバーを追加する」 にあるように、メンバーを追加します。
  7. Save をクリックします。

コマンドライン: Netgroup の追加

新規 netgroup は、ipa netgroup-add コマンドを使って追加します。以下を指定します。
  • グループ名
  • オプションで説明
  • NIS ドメイン名が IdM ドメイン名とは別の場合、これをオプションで追加

    注記

    --nisdomain オプションでは、netgroup の tripleに表示されるドメインを設定します。これは、Identity Management リスナーが応答する NIS ドメインに影響するものではありません。
以下に例を示します。
[root@server ~]# ipa netgroup-add --desc="Netgroup description" --nisdomain="example.com" example-netgroup
netgroup にメンバーを追加する方法については、「コマンドライン: Netgroup にメンバーを追加する」 を参照してください。

21.3.2. Netgroup にメンバーを追加する

ユーザーとホスト以外に、netgroup にはユーザーグループ、ホストグループ、および他の netgroup (入れ子グループ) をメンバーとして含めることができます。グループのサイズによっては、子グループのメンバー用に入れ子グループを作成してからそれが親グループのメンバーとして表示されるまで数分かかる場合があります。
Netgroup にメンバーを追加するには、以下のいずれかを使用します。

警告

入れ子グループを作成する際は、再帰グループを作成しないでください。たとえば、GroupAGroupB のメンバーの場合、GroupBGroupA のメンバーとして追加しないでください。再帰グループはサポートされておらず、予測不可能な動作を引き起こす可能性があります。

Web UI: Netgroup にメンバーを追加する

Web UI で netgroup にメンバーを追加するには、以下の手順に従います。
  1. IdentityGroupsNetgroups を選択します。
  2. メンバーを追加する netgroup 名をクリックします。
  3. メンバータイプ横にある Add をクリックします。
    Netgroup タブのユーザーメニュー

    図21.2 Netgroup タブのユーザーメニュー

  4. 追加するメンバーを選択し、> をクリックして確定します。
    Netgroup タブでのユーザー追加メニュー

    図21.3 Netgroup タブでのユーザー追加メニュー

  5. Add をクリックします。

コマンドライン: Netgroup にメンバーを追加する

netgroup を作成したら、ipa netgroup-add-member コマンドでメンバーを追加します。
# ipa netgroup-add-member --users=user_name --groups=group_name --hosts=host_name \
     --hostgroups=host_group_name --netgroups=netgroup_name group_nameame
複数のメンバーを追加するには、以下のように中括弧内にコンマ区切りリストで記載します。
[root@server ~]# ipa netgroup-add-member --users={user1;user2,user3} \
     --groups={group1,group2} example-group

21.4. 自動マウントマップの NIS クライアントへの公開

自動マウントマップが既に定義されている場合、マップを IdM の NIS 設定に手動で追加する必要があります。こうすることで、マップが NIS クライアントに確実に公開されます。
NIS サーバーは、IdM LDAP ディレクトリー内の特別なプラグインエントリーで管理されます。NIS サーバーが使用する各 NIS ドメインおよびマップは、このコンテナーでサブエントリーとして追加されます。NIS ドメインエントリーには、以下のものが含まれます。
  • NIS ドメイン名
  • NIS マップ名
  • NIS マップのコンテンツとして使用するためのディレクトリーエントリーの発見方法
  • NIS マップのキーおよび値としてどの属性を使用するかについての情報
これら設定のほとんどは、各マップで同じものになります。

21.4.1. 自動マウントマップの追加

IdM は、自動マウントの場所ごとにグループ化された自動マウントマップを IdM ディレクトリーツリーの cn=automount ブランチに保存します。NIS ドメインとマップは LDAP プロトコルを使って追加できます。
たとえば、example.com ドメイン内の default の場所にある auto.example という自動マウントマップを追加するには、以下を実行します。
[root@server ~]# ldapadd -h server.example.com -x -D "cn=Directory Manager" -W

dn: nis-domain=example.com+nis-map=auto.example,cn=NIS Server,cn=plugins,cn=config
objectClass: extensibleObject
nis-domain: example.com
nis-map: auto.example
nis-filter: (objectclass=automount)
nis-key-format: %{automountKey}
nis-value-format: %{automountInformation}
nis-base: automountmapname=auto.example,cn=default,cn=automount,dc=example,dc=com

注記

nis-domain 属性は、自分の NIS ドメイン名に設定します。
nis-base 属性で設定する値は、以下のものに対応する必要があります。
  • ipa automountmap-* コマンドを使用して設定した既存の自動マウントマップ
  • ipa automountlocation-* コマンドを使用して設定した既存の自動マウントの場所
エントリーを設定したら、以下を実行して自動マウントマップを確認します。
[root@server ~]# ypcat -k -d example.com -h server.example.com auto.example

21.5. NIS から IdM への移行

既存の NIS サーバーから Identity Management (IdM) に移行するには、以下のステップを実行します。

21.5.1. IdM でのネットグループエントリーの準備

移行前に、現行の NIS サーバーで管理されている ID を確認します。
ユーザーエントリー
NIS が提供しているユーザー情報を使用しているアプリケーションを判定します。sudo などのユーティリティーは NIS netgroup を必要としますが、通常の UNIX グループを使用できるものもあります。
移行は、以下の手順で実行します。
  1. 対応するユーザーアカウントを IdM に作成します。「ユーザーエントリーの移行」 を参照してください。
  2. さらに netgroup が必要な場合は、以下を実行します。
    1. netgroup を追加します。「Netgroup の追加」 を参照してください。
    2. ユーザーを netgroup に追加します。「Netgroup エントリーの移行」 を参照してください。
ホストエントリー
IdM でホストグループを作成する際、一致するシャドウ NIS グループが自動的に作成されます。これらのシャドウ NIS グループには、ipa netgroup-* コマンドは使用しないでください。ipa netgroup-* は、netgroup-add コマンドで作成した native ネットグループをマージするときにのみ使用してください。
直接変換の場合
ユーザーおよびホストエントリーですべて同じ名前を使用する必要がある場合は、IdM 内の同一名を使用してエントリーを作成します。
  1. netgroup で参照されているユーザーすべてについてエントリーを作成します。
  2. netgroup で参照されているホストすべてについてエントリーを作成します。
  3. 元の netgroup と同じ名前の netgroup を作成します。
  4. ユーザーとホストをこの netgroup の直接のメンバーとして追加します。ユーザーおよびホストがグループまたはホストグループのメンバーである場合は、これらのグループを netgroup に追加します。

21.5.2. Identity Management で NIS リスナーを有効にする

21.5.3. 既存 NIS データのインポートおよびエクスポート

NIS サーバーには、ユーザー、グループ、ホスト、netgroup、および自動マウントマップの情報が含まれます。これらのエントリータイプはいずれも IdM に移行することができます。
以下のセクションでは、ypcat コマンドを使ってデータをNIS サーバーからエクスポートし、その出力を使用して対応する ipa *-add コマンドでエントリーを IdM にインポートします。

21.5.3.1. ユーザーエントリーの移行

NIS passwd マップには、UID、プライマリーグループ、GECOS、シェル、およびホームディレクトリーなどのユーザー情報が含まれます。このデータを使用して NIS ユーザーアカウントを IdM に移行します。
  1. オプションで、弱いパスワードのサポートが必要な場合は、「NIS ユーザー認証用に脆弱なパスワードハッシュを有効にする」 を参照してください。
  2. 以下のコンテンツで /root/nis-users.sh スクリプトを作成します。
    #!/bin/sh
    # $1 is the NIS domain, $2 is the NIS master server
    ypcat -d $1 -h $2 passwd > /dev/shm/nis-map.passwd 2>&1
    
    IFS=$'\n'
    for line in $(cat /dev/shm/nis-map.passwd) ; do
    	IFS=' '
    	username=$(echo $line | cut -f1 -d:)
    	# Not collecting encrypted password because we need cleartext password
    	# to create kerberos key
    	uid=$(echo $line | cut -f3 -d:)
    	gid=$(echo $line | cut -f4 -d:)
    	gecos=$(echo $line | cut -f5 -d:)
    	homedir=$(echo $line | cut -f6 -d:)
    	shell=$(echo $line | cut -f7 -d:)
    
    	# Now create this entry
    	echo passw0rd1 | ipa user-add $username --first=NIS --last=USER \
    	     --password --gidnumber=$gid --uid=$uid --gecos=$gecos --homedir=$homedir \
    	     --shell=$shell
    	ipa user-show $username
    done 
  3. IdM admin ユーザーとして認証します。
    [root@nis-server ~]# kinit admin
  4. 以下のようにスクリプトを実行します。
    [root@nis-server ~]# sh /root/nis-users.sh nisdomain nis-master.example.com

    注記

    このスクリプトはハードコーディングされた値を性、名に使用し、パスワードを passw0rd1 に設定します。ユーザーは次回ログイン時にこのパスワードを変更する必要があります。

21.5.3.2. グループエントリーの移行

NIS group マップには、グループ名、GID、グループメンバーなどのグループ情報が含まれます。このデータを使用して NIS グループを IdM に移行します。
  1. 以下のコンテンツで /root/nis-groups.sh スクリプトを作成します。
    #!/bin/sh
    # $1 is the NIS domain, $2 is the NIS master server
    ypcat -d $1 -h $2 group > /dev/shm/nis-map.group 2>&1
    
    IFS=$'\n'
    for line in $(cat /dev/shm/nis-map.group); do
    	IFS=' '
    	groupname=$(echo $line | cut -f1 -d:)
    	# Not collecting encrypted password because we need cleartext password
    	# to create kerberos key
    	gid=$(echo $line | cut -f3 -d:)
    	members=$(echo $line | cut -f4 -d:)
    
    	# Now create this entry
    	ipa group-add $groupname --desc=NIS_GROUP_$groupname --gid=$gid
    	if [ -n "$members" ]; then
    		ipa group-add-member $groupname --users={$members}
    	fi
    	ipa group-show $groupname
    done 
  2. IdM admin ユーザーとして認証します。
    [root@nis-server ~]# kinit admin
  3. 以下のようにスクリプトを実行します。
    [root@nis-server ~]# sh /root/nis-groups.sh nisdomain nis-master.example.com

21.5.3.3. ホストエントリーの移行

NIS hosts マップには、ホスト名や IP アドレスなどのホスト情報が含まれます。このデータを使用して NIS ホストエントリーを IdM に移行します。
  1. 以下のコンテンツで /root/nis-hosts.sh スクリプトを作成します。
    #!/bin/sh
    # $1 is the NIS domain, $2 is the NIS master server
    ypcat -d $1 -h $2 hosts | egrep -v "localhost|127.0.0.1" > /dev/shm/nis-map.hosts 2>&1
    
    IFS=$'\n'
    for line in $(cat /dev/shm/nis-map.hosts); do
    	IFS=' '
    	ipaddress=$(echo $line | awk '{print $1}')
    	hostname=$(echo $line | awk '{print $2}')
    	master=$(ipa env xmlrpc_uri | tr -d '[:space:]' | cut -f3 -d: | cut -f3 -d/)
    	domain=$(ipa env domain | tr -d '[:space:]' | cut -f2 -d:)
    	if [ $(echo $hostname | grep "\." |wc -l) -eq 0 ] ; then
    		hostname=$(echo $hostname.$domain)
    	fi
    	zone=$(echo $hostname | cut -f2- -d.)
    	if [ $(ipa dnszone-show $zone 2>/dev/null | wc -l) -eq 0 ] ; then
    		ipa dnszone-add --name-server=$master --admin-email=root.$master
    	fi
    	ptrzone=$(echo $ipaddress | awk -F. '{print $3 "." $2 "." $1 ".in-addr.arpa."}')
    	if [ $(ipa dnszone-show $ptrzone 2>/dev/null | wc -l) -eq 0 ] ; then
    		ipa dnszone-add  $ptrzone --name-server=$master --admin-email=root.$master
    	fi
    	# Now create this entry
    	ipa host-add $hostname --ip-address=$ipaddress
    	ipa host-show $hostname
    done
  2. IdM admin ユーザーとして認証します。
    [root@nis-server ~]# kinit admin
  3. 以下のようにスクリプトを実行します。
    [root@nis-server ~]# sh /root/nis-hosts.sh nisdomain nis-master.example.com

    注記

    このスクリプトでは、エイリアスなどの特定なホスト設定は移行されません。

21.5.3.4. Netgroup エントリーの移行

NIS netgroup マップには、netgroup についての情報が含まれます。このデータを使用して NIS netgroup を IdM に移行します。
  1. 以下のコンテンツで /root/nis-netgroups.sh スクリプトを作成します。
    #!/bin/sh
    # $1 is the NIS domain, $2 is the NIS master server
    ypcat -k -d $1 -h $2 netgroup > /dev/shm/nis-map.netgroup 2>&1
    
    IFS=$'\n'
    for line in $(cat /dev/shm/nis-map.netgroup); do
    	IFS=' '
    	netgroupname=$(echo $line | awk '{print $1}')
    	triples=$(echo $line | sed "s/^$netgroupname //")
    	echo "ipa netgroup-add $netgroupname --desc=NIS_NG_$netgroupname"
    	if [ $(echo $line | grep "(," | wc -l) -gt 0 ]; then
    		echo "ipa netgroup-mod $netgroupname --hostcat=all"
    	fi
    	if [ $(echo $line | grep ",," | wc -l) -gt 0 ]; then
    		echo "ipa netgroup-mod $netgroupname --usercat=all"
    	fi
    
    	for triple in $triples; do
    		triple=$(echo $triple | sed -e 's/-//g' -e 's/(//' -e 's/)//')
    		if [ $(echo $triple | grep ",.*," | wc -l) -gt 0 ]; then
    			hostname=$(echo $triple | cut -f1 -d,)
    			username=$(echo $triple | cut -f2 -d,)
    			domain=$(echo $triple | cut -f3 -d,)
    			hosts=""; users=""; doms="";
    			[ -n "$hostname" ] && hosts="--hosts=$hostname"
    			[ -n "$username" ] && users="--users=$username"
    			[ -n "$domain"   ] && doms="--nisdomain=$domain"
    			echo "ipa netgroup-add-member $hosts $users $doms"
    		else
    			netgroup=$triple
    			echo "ipa netgroup-add $netgroup --desc=NIS_NG_$netgroup"
    		fi
    	done
    done
  2. IdM admin ユーザーとして認証します。
    [root@nis-server ~]# kinit admin
  3. 以下のようにスクリプトを実行します。
    [root@nis-server ~]# sh /root/nis-netgroups.sh nisdomain nis-master.example.com

21.5.3.5. 自動マウントマップの移行

自動マウントマップは、場所 (親エントリー) と関連のキーおよびマップを定義する入れ子および相互関連のエントリーになります。以下の手順で NIS 自動マウントマップを IdM に移行します。
  1. 以下のコンテンツで /root/nis-automounts.sh スクリプトを作成します。
    #!/bin/sh
    # $1 is for the automount entry in ipa
    
    ipa automountlocation-add $1
    
    # $2 is the NIS domain, $3 is the NIS master server, $4 is the map name
    ypcat -k -d $2 -h $3 $4 > /dev/shm/nis-map.$4 2>&1
    
    ipa automountmap-add $1 $4
    
    basedn=$(ipa env basedn | tr -d '[:space:]' | cut -f2 -d:)
    cat > /tmp/amap.ldif <<EOF
    dn: nis-domain=$2+nis-map=$4,cn=NIS Server,cn=plugins,cn=config
    objectClass: extensibleObject
    nis-domain: $2
    nis-map: $4
    nis-base: automountmapname=$4,cn=$1,cn=automount,$basedn
    nis-filter: (objectclass=*)
    nis-key-format: %{automountKey}
    nis-value-format: %{automountInformation}
    EOF
    ldapadd -x -h $3 -D "cn=Directory Manager" -W -f /tmp/amap.ldif
    
    IFS=$'\n'
    for line in $(cat /dev/shm/nis-map.$4); do
    	IFS=" "
    	key=$(echo "$line" | awk '{print $1}')
    	info=$(echo "$line" | sed -e "s#^$key[ \t]*##")
    	ipa automountkey-add nis $4 --key="$key" --info="$info"
    done
    このスクリプトでは NIS 自動マウント情報がエクスポートされ、LDAP データ変換形式 (LDIF) の自動マウントの場所と関連マップが生成され、LDIF ファイルが IdM Directory Server にインポートされます。詳細については、「自動マウントマップの NIS クライアントへの公開」 を参照してください。
  2. IdM admin ユーザーとして認証します。
    [root@nis-server ~]# kinit admin
  3. 以下のようにスクリプトを実行します。
    [root@nis-server ~]# sh /root/nis-automounts.sh location nisdomain \
         nis-master.example.com map_name

21.5.4. NIS ユーザー認証用に脆弱なパスワードハッシュを有効にする

Directory Server コンポーネントのデフォルト設定を使用すると、userPassword 属性に保存されているパスワードはソルト付き SHA を使ってハッシュ化されます。お使いの NIS クライアントでパスワード用に脆弱なハッシュ化アルゴリズムが必要な場合は、パスワード保存スキームの設定を更新します。
脆弱なパスワードハッシュ化スキームの有効化は、userPassword 属性に保存されているパスワードにのみ影響があります。Kerberos はこの属性を使用しないので、この設定は Kerberos 暗号化に影響しないことに留意してください。
たとえば、CRYPT ハッシュ化パスワードを有効にするには、以下を実行します。
[root@server ~]# ldapmodify -D "cn=Directory Manager" -W -p 389 -h ipaserver.example.com -x
dn: cn=config
changetype: modify
replace: passwordStorageScheme
passwordStorageScheme: crypt

注記

パスワードハッシュは暗号化解除ができないため、Directory Server は既存のパスワードハッシュを変換しません。サーバーは、ストレージスキームの変更後に設定されたパスワードにのみ、新規パスワードストレージを適用します。

パート V. 認証メカニズムの管理

第22章 ユーザー認証

本章では、ユーザーパスワード、SSH キー、証明書の管理、ワンタイムパスワード (OTP) およびスマートカード認証の設定方法に関する情報など、ユーザー認証のメカニズム管理について説明します。

注記

Kerberos を使用した Identity Management (IdM) へのログインに関するドキュメントは5章IdM サーバーおよびサービスの基本的な管理を参照してください。

22.1. ユーザーパスワード

22.1.1. ユーザーパスワードの変更およびリセット

他のユーザーのパスワードを変更するパーミッションのない通常ユーザーは、自身のパスワードしか変更できません。個人のパスワードは以下のように変更します。
パスワード変更の権限がある管理者およびユーザーは、新規ユーザーの初期パスワードの設定、既存ユーザーのパスワードのリセットが可能です。パスワードは以下のように変更します。

注記

LDAP Directory Manager (DM) ユーザーは、LDAP ツールを使用してユーザーパスワードを変更できます。新しいパスワードは、IdM パスワードポリシーよりも優先されます。DM で設定したパスワードは、初回ログインで失効しません。

22.1.1.1. Web UI: 個人のパスワードの変更

  1. 右上隅の User nameChange password をクリックします。
    パスワードのリセット

    図22.1 パスワードのリセット

  2. 新規パスワードを入力します。

22.1.1.2. Web UI: 別ユーザーのパスワードのリセット

  1. IdentityUsers を選択します。
  2. 編集するユーザー名をクリックします。
  3. ActionsReset password をクリックします。
    パスワードのリセット

    図22.2 パスワードのリセット

  4. 新規パスワードを入力して Reset Password をクリックします。
    新規パスワードの確定

    図22.3 新規パスワードの確定

22.1.1.3. コマンドライン: 別のユーザーのパスワード変更またはリセット

自身のパスワードの変更または、別のユーザーのパスワード変更またはリセットするには、ipa user-mod コマンドに --password オプションを追加します。このコマンドにより、新規パスワードを入力するように求められます。
$ ipa user-mod user --password
Password:
Enter Password again to verify:
--------------------
Modified user "user"
--------------------
...

22.1.2. 次回のログイン時にパスワード変更のプロンプトを表示しないでパスワードのリセットを有効化する方法

デフォルトでは、管理者が別のユーザーのパスワードをリセットすると、ユーザーが初めて正しくログインできた時点でそのパスワードが失効します。詳細は「ユーザーパスワードの変更およびリセット」を参照してください。
管理者が設定したパスワードを初めて使用した時点で失効させないようにするには、ドメイン内の全 Identity Management サーバーで以下の変更を加えます。
  • パスワードの同期エントリーを編集します (cn=ipa_pwd_extop,cn=plugins,cn=config)。
  • passSyncManagersDNs 属性で管理ユーザーアカウントを指定します。この属性には、複数の値を指定することができます。
たとえば、ldapmodifyユーティリティーを使用して admin ユーザーを指定するには以下を実行します。
$ ldapmodify -x -D "cn=Directory Manager" -W -h ldap.example.com -p 389

dn: cn=ipa_pwd_extop,cn=plugins,cn=config
changetype: modify
add: passSyncManagersDNs
passSyncManagersDNs: uid=admin,cn=users,cn=accounts,dc=example,dc=com

警告

これらの追加の権限が必要なユーザーのみを指定します。passSyncManagerDNs に含まれる全ユーザーは以下が可能です。
  • すぐ後にパスワードのリセットせずにパスワードの変更操作を実行する
  • パスワード強度や履歴の制限を適用しなくていいようにパスワードポリシーを回避する

22.1.3. ログイン失敗後のユーザーアカウントのロック解除

ユーザーのログイン時にパスワードを特定の回数間違うと、IdM はそのユーザーがログインできないようにアカウントをロックします。IdM からは、ユーザーアカウントがロックされたことを示す警告メッセージは表示されない点に注意してください。

注記

ログインに失敗できる回数やロックアウトの期間の設定に関する情報は、28章パスワードポリシーの定義を参照してください。
IdM により、指定の期間が経過すると自動的にユーザーアカウントのロックが解除されます。または、管理者が手動でユーザーアカウントのロックを解除してください。

ユーザーアカウントの手動のロック解除

ユーザーアカウントのロックを解除するには ipa user-unlock コマンドを使用します。
$ ipa user-unlock user
-----------------------
Unlocked account "user"
-----------------------
このコマンドを実行すると、ユーザーは再度、ログインできるようになります。

22.1.3.1. ユーザーアカウントのステータス確認

ユーザーのログイン失敗回数を表示するには ipa user-status コマンドを使用します。表示の回数がログインを試行できる回数を超えると、ユーザーアカウントはロックされます。
$ ipa user-status user
-----------------------
Account disabled: False
-----------------------
  Server: example.com
  Failed logins: 8
  Last successful authentication: 20160229080309Z
  Last failed authentication: 20160229080317Z
  Time now: 2016-02-29T08:04:46Z
----------------------------
Number of entries returned 1
----------------------------
デフォルトでは、 Red Hat Enterprise Linux 7.4 以降を実行している IdM は、ユーザーの前回の Kerberos 認証の成功のタイムスタンプを保存しません。この機能を有効にするには、「前回成功した Kerberos 認証を追跡する機能の有効化」を参照してください。

22.2. 前回成功した Kerberos 認証を追跡する機能の有効化

パフォーマンス上の理由から、Red Hat Enterprise Linux 7.4 以降を実行している IdM は、ユーザーの前回成功した Kerberos 認証のタイムスタンプを保存しません。そのため、ipa user-status などの特定のコマンドはタイムスタンプを表示しません。
ユーザーの前回成功した Kerberos 認証の追跡を有効にするには:
  1. 現在有効化しているパスワードプラグイン機能を表示します。
    # ipa config-show | grep "Password plugin features"
      Password plugin features: AllowNThash, KDC:Disable Last Success
    以下の手順では、KDC:Disable Last Success を除き、機能の名前が必要となります。
  2. 各機能の --ipaconfigstring=feature パラメーターを、KDC:Disable Last Success を除く、現在有効化されている ipa config-mod コマンドに渡します。
    # ipa config-mod --ipaconfigstring='AllowNThash'
    このコマンドでは、AllowNThash プラグインのみを有効にします。複数の機能を有効にするには、--ipaconfigstring=feature パラメーターを複数回指定します。例えば、AllowNThashKDC:Disable Lockout 機能を有効にするには:
    # ipa config-mod --ipaconfigstring='AllowNThash' --ipaconfigstring='KDC:Disable Lockout'
  3. IdM を再起動します。
    # ipactl restart

22.3. ワンタイムパスワード

重要

OTP 認証の IdM ソリューションは、Red Hat Enterprise Linux 7.1 以降を稼働するクライアントのみでサポートされます。
ワンタイムパスワード (OTP) は、1 回の認証セッションのみで有効なパスワードです。これは一度使用すると、無効になります。従来の静的なパスワードとは異なり、認証トークンで生成される OTP は常に変更されます。OTP は、二要素認証の一部として使用されます。
  1. 従来のパスワードを使用したユーザー認証
  2. ユーザーは、認識済みの OTP トークンで生成された OTP コードを入力します。
二要素認証は、従来のパスワードだけを使用する認証に比べると安全であると考えられています。ログイン中に、侵入者により OTP が傍受された場合でも、傍受された OTP は、一旦認証に成功すると使用できなくなるので、侵入者が使用する頃にすでに無効になっています。

警告

現在、IdMの OTP サポートに関係のあるセキュリティーとその他の制限は以下の通りです。
  • 最も重要なセキュリティー制限として、システム全体でリプレイアタックの被害を受けやすくなる点です。レプリケーションは非同期で実行されるので、OTP コードはレプリケーション中に再利用でき、ユーザーは同時に 2 台のサーバーにログインできる可能性があります。ただし、包括的な暗号化があると、この脆弱性を悪用するのは困難です。
  • OTP 認証をサポートしていないクライアント経由では、ticket-granting ticket (TGT) を取得することができません。これは、mod_auth_kerb モジュールまたは Generic Security Services API (GSSAPI) を使用した認証などのユースケースに影響する可能性があります。
  • FIPS モードが有効化されていると、IdM ソリューションでパスワード + OTP を使用できません。

22.3.1. IdM でのOTP の機能

22.3.1.1. IdM でサポートされる OTP トークン

ソフトウェアおよびハードウェアトークン

IdM は、ソフトウェアおよびハードウェア両方のトークンをサポートします。

ユーザーおよび管理者が管理するトークン

ユーザーは自身のトークンを、管理者はユーザーの代わりにトークンを管理します。
ユーザー管理のトークン
ユーザーは、トークの作成、編集、削除など、Identity Management でユーザーが管理するトークンを完全に制御できます。
管理者が管理するトークン
管理者は、管理者が管理するトークンをユーザーのアカウントに追加し、ユーザーはこれらのトークンへの読み取り専用アクセスが割り当てられます。ユーザーはトークンの管理または変更パーミッションがなく、設定する必要はありません。
アクティブなトークンが 1 つしかない場合には、削除することも、無効にすることもできない点に注意してください。管理者は、自分のアクティブなトークンが 1 つの場合は削除や無効化はできませんが、別のユーザートークンは、アクティブなトークンが 1 つの場合でも削除または無効化することができます。

サポートされる OTP アルゴリズム

Identity Management には、以下にある、2 つの標準 OTP メカニズムをサポートしています。
  • HMAC ベースのワンタイムパスワード (HOTP) アルゴリズムは、カウンターに基づいています。HMAC は、Hashed Message Authentication Code (ハッシュメッセージ認証コード) を表しています。
  • 時間ベースのワンタイムパスワード (TOTP) アルゴリズムは、時間ベースの移動要素をサポートする HOTP の拡張機能です。

22.3.1.2. 利用可能な OTP 認証方法

OTP 認証を有効化する際に、以下の認証方法から選択できます。
二要素認証 (パスワード + OTP)
この方法では、ユーザーは常に標準のパスワードと OTP コードを入力するように求められます。
パスワード
この方法では、ユーザーは標準のパスワードのみを使用した認証を選択するオプションがあります。
RADIUS プロキシサーバー認証
OTP の検証用に RADIUS サーバーを設定する方法は「商用 OTP ソリューションからの移行」を参照してください。

グローバルおよびユーザー固有の認証方法

グローバルにも、または個別ユーザーにもこれらの認証方法を設定することができます。
  • デフォルトでは、ユーザー固有の認証方法の設定は、グローバルの設定よりも優先されます。認証方法がユーザーに設定されていない場合には、グローバルに定義された方法が適用されます。
  • ユーザー毎の認証方法を無効化することができます。これにより、IdM はユーザー毎の設定を無視して常にグローバルの設定を適用することができます。

複数の認証方法の統合

複数の方法を同時に設定すると、どちらか 1 つが成功すれば認証されます。以下に例を示します。
  • 二要素認証およびパスワード認証を設定すると、ユーザーはコマンドラインを使用する場合にはパスワード (1 つ目の要素) を指定する必要がありますが、OTP (2 つ目の要素) はオプションです。
    First Factor:
    Second Factor (optional):
  • Web UI ではユーザーは両要素を指定する必要があります。

注記

OTP などの特定の認証方法を設定する必要のある個別ホストまたはサービスもあります。一段階要素のみを使用してこのようなホストやサービスに対する認証を試行すると、アクセスが拒否されます。「ユーザーの認証情報をもとにサービスやホストへのアクセス制限」を参照してください。
ただし、RADIUS および他の認証方法が設定されている場合には、例外が少しあります。
  • Kerberos は常に RADIUS を使用しますが LDAP は RADIUS を使用しません。LDAP が認識するのは、パスワードと二要素認証のオプションのみです。
  • 外部の 2 要素認証プロバイダーを使用する場合は、使用しているアプリケーションから Kerberos を使用します。ユーザーがパスワードのみで認証するようにするには、LDAP を使用します。アプリケーションが Apache モジュールと SSSD を活用するようにすることが推奨されます。そうすることで、Kerberos か LDAP のいずれかを設定することができます。

22.3.1.3. GNOME のキーリングサービスサポート

IdM は、OTP 認証と GNOME キーリングサービスを統合します。GNOME キーリング統合では、一段階要素と二段階要素を別に入力する必要があります。
First factor: static_password
Second factor: one-time_password

22.3.1.4. OTP でのオフライン認証

IdM では、オフライン OTP 認証がサポートされますが、オフラインでログインできるようにするには、システムがオンラインの時にユーザーは静的なパスワードと OTP を別に入力して最初の認証を行う必要があります。
First factor: static_password
Second factor: one-time_password
オンラインでのログイン時に両パスワードを個別に入力すると、それ以降のログイン時に中央認証サーバーが利用できない場合でも認証できるようになっています。ユーザーがオフラインで認証を行うと、IdM は第一要素である従来の静的なパスワードだけを求める点に注意してください。
IdM は、First factor のプロンプトで静的なパスワードと OTP を 1 つの文字列として入力できるようにサポートします。ただし、オフラインの OTP 認証とは互換性がない点に注意してください。ユーザーが両要素を単一のプロンプトで入力した場合には、IdM は認証時に常に中央認証サーバに問い合わせる必要があるので、認証時にはシステムがオンラインの状態でなければなりません。

重要

ラップトップなどオフラインで操作するデバイスで OTP 認証を使用する場合は、Red Hat は静的なパスワードと OTP を個別に入力して、オフライン認証を利用可能にすることを推奨します。これを行わないと、システムがオフラインになった後にログインすると IdM により拒否されます。
OTP オフライン認証の恩恵を受けるには、静的と OTP パスワードを個別に入力する以外に、以下の条件も満たすようにしてください。
  • /etc/sssd/sssd.conf ファイルの cache_credentials オプションを True に設定すると、第一要素のパスワードのキャッシュが有効になります。
  • 第一要素の静的パスワードが、/etc/sssd/sssd.confcache_credentials_minimal_first_factor_length オプションで定義されているパスワード長の要件を満たしていること。デフォルトでは、少なくとも 8 文字以上指定する必要があります。オプションに関する情報は、sssd.conf(5) の man ページを参照してください。
/etc/sssd/sssd.confkrb5_store_password_if_offline オプションが true に設定されている場合でも、その時点で OTP がすでに無効になっている可能性があるので SSSD は Kerberos ticket-granting ticket (TGT) の更新は試行しません。このような状況で TGT を取得するには、両要素を使用して認証する必要があります。

22.3.2. FIPS モードで稼働している IdM サーバーで RADIUS プロキシを設定するのに必要な設定

Federal Information Processing Standard (FIPS) モードの OpenSSL では、デフォルトで MD5 ダイジェストアルゴリズムの使用が無効になりました。その結果、RADIUS プロトコルでは、RADIUS クライアントおよび RADIUS サーバーとの間でシークレットを暗号化する MD5 が必要になり、FIPS モードで MD5 が利用できないため、IdM (Identity Management) の RADIUS プロキシサーバーが失敗します。
RADIUS サーバーが、IdM マスターと同じホストで実効しているため、以下の手順を実行して問題を回避し、安全な境界内で MD5 を有効にできます。
  1. /etc/systemd/system/radiusd.service.d/ipa-otp.conf ファイルを作成し、以下の内容を追加します。
    [Service] 
    Environment=OPENSSL_FIPS_NON_APPROVED_MD5_ALLOW=1
  2. systemd 設定を再度読み込みます。
    # systemctl daemon-reload
  3. radiusd サービスを起動します。
    # systemctl start radiusd

22.3.3. 二要素認証の有効化

OTP 関連で利用可能な認証方法に関する詳細は「利用可能な OTP 認証方法」を参照してください。
以下を使用して二要素認証を有効化するには:

Web UI: 二要素認証の有効化

全ユーザーに対してグローバルに認証方法を設定するには、以下を実行します。
  1. IPA ServerConfiguration を選択します。
  2. User Options エリアで、必要な Default user authentication types を選択します。
    ユーザー認証方法

    図22.4 ユーザー認証方法

グローバル設定がユーザー別の設定で上書きされないようにするには、Disable per-user override を選択します。Disable per-user override を選択しない場合には、ユーザー別に設定した認証方法がグローバル設定よりも優先されます。
ユーザーベースで個別に認証方法を設定するには、以下を実行します。
  1. IdentityUsers を選択して、編集するユーザーの名前をクリックします。
  2. Account Settings エリアで、必要な User authentication types を選択します。
    ユーザー認証方法

    図22.5 ユーザー認証方法

コマンドライン: 二要素認証の有効化

全ユーザーに対してグローバルに認証方法を設定するには、以下を実行します。
  1. ipa config-mod --user-auth-type コマンドを実行します。たとえば、グローバル認証方法を二要素認証に設定するには以下を実行します。
    $ ipa config-mod --user-auth-type=otp
    --user-auth-type に入力できる値の一覧については、ipa config-mod --help コマンドを実行します。
  2. ユーザー別の上書きを無効にする、つまりユーザーの設定がグローバル設定を上書きしないようにするには、--user-auth-type=disabled オプションも追加します。たとえば、二要素認証にグローバル認証方法を設定してユーザーの上書きを無効にするには以下を設定します。
    $ ipa config-mod --user-auth-type=otp --user-auth-type=disabled
    --user-auth-type=disabled を設定しない場合には、ユーザー毎に設定した認証方法がグローバル設定よりも優先されます。
指定のユーザーに対して個別に認証方法を設定するには以下を行います。
  • ipa user-mod --user-auth-type コマンドを実行します。たとえば、user が二要素認証を使用するように設定するには以下を実行します。
    $ ipa user-mod user --user-auth-type=otp
複数の認証方法を設定するには、--user-auth-type を複数回追加します。たとえば、パスワードとに要素認証を全ユーザーにグローバルに設定するには、以下を実行します。
$ ipa config-mod --user-auth-type=otp --user-auth-type=password

22.3.4. ユーザー管理のソフトウェアトークンの追加

  1. 標準のパスワードでログインします。
  2. モバイルデバイスに FreeOTP Authenticator アプリケーションがインストールされていることを確認します。FreeOTP Authenticator のダウンロードについては、FreeOTP source page を参照してください。
  3. IdM Web UI またはコマンドラインでソフトウェアトークンを作成します。
    • Web UI でトークンを作成するには、OTP tokens タブで Add をクリックします。管理者としてログインしている場合は Authentication から OTP Tokens tab タブにアクセスできます。
      ユーザー用の OTP トークンの追加

      図22.6 ユーザー用の OTP トークンの追加

    • コマンドラインからトークンを作成するには ipa otptoken-add コマンドを実行します。
      $ ipa otptoken-add
      ------------------
      Added OTP token ""
      ------------------
        Unique ID: 7060091b-4e40-47fd-8354-cb32fecd548a
        Type: TOTP
      ...
      ipa otptoken-add に関する情報は、--help オプションを追加してこのコマンドを実行します。
  4. Web UI またはコマンドラインに QR コードが表示されます。QR コードを FreeOTP Authenticator でスキャンして、モバイルデバイスのトークンを提供します。

22.3.5. ユーザー管理の YubiKey ハードウェアトークンの追加

YubiKey トークなど、プログラム可能なハードウェアトークンは、コマンドラインからのみ追加できます。YubiKey ハードウェアをトークンの所有ユーザーとして追加するには、以下を実行します。
  1. 標準のパスワードでログインします。
  2. YubiKey トークンを挿入します。
  3. ipa otptoken-add-yubikey コマンドを実行します。
    • YubiKey に空のスロットがある場合には、コマンドは、その空のスロットを自動的に選択します。
    • 空のスロットがない場合には --slot オプションを使用して手動でスロットを選択する必要があります。以下に例を示します
      $ ipa otptoken-add-yubikey --slot=2
      これは、選択したスロットを上書きする点に注意してください。

22.3.6. 管理者としてユーザー用のトークン追加

管理者としてソフトウェアトークンを追加するには以下を実行します。
  1. 管理者としてログインしていることを確認します。
  2. モバイルデバイスに FreeOTP Authenticator アプリケーションがインストールされていることを確認します。FreeOTP Authenticator のダウンロードについては、FreeOTP source page を参照してください。
  3. IdM Web UI またはコマンドラインでソフトウェアトークンを作成します。
    • Web UI でトークンを作成するには、AuthenticationOTP Tokens を選択して、OTP トークンの一覧の上部にある Add をクリックします。Add OTP Token フォームで、トークンの所有者を選択します。
      管理者が管理するソフトウェアトークンの追加

      図22.7 管理者が管理するソフトウェアトークンの追加

    • コマンドラインからトークンを作成するには --owner オプションを指定して ipa otptoken-add コマンドを実行します。以下に例を示します。
      $ ipa otptoken-add --owner=user
      ------------------
      Added OTP token ""
      ------------------
        Unique ID: 5303baa8-08f9-464e-a74d-3b38de1c041d
        Type: TOTP
      ...
  4. Web UI またはコマンドラインに QR コードが表示されます。QR コードを FreeOTP Authenticator でスキャンして、モバイルデバイスのトークンを提供します。
管理者として、YubiKey トークンのようなプログラム可能なハードウェアトークンを追加するには、以下の手順に従います。
  1. 管理者としてログインしていることを確認します。
  2. YubiKey トークンを挿入します。
  3. --owner オプションを指定して ipa otptoken-add-yubikey コマンドを実行します。以下に例を示します。
    $ ipa otptoken-add-yubikey --owner=user

22.3.7. 商用 OTP ソリューションからの移行

商用の OTP ソリューションから IdM をネイティブとする OTP ソリューションに、大規模なデプロイメントを移行できるように、IdM では、OTP 確認をサードパーティーの RADIUS サーバーにオフロードする方法をユーザーのサブセットに提供します。管理者は、複数の個別の RADIUS サーバーを含む RADIUS プロキシーのセットを作成します。次にこれらプロキシーセットのひとつをユーザーに割り当てます。ユーザーに RADIUS プロキシーのセットが割り当てられている限り、IdM は他のすべての認識メカニズムを迂回します。

注記

IdM では、サードパーティーシステムでのトークン管理やトークンの同期をサポートしていません。
OTP 確認用の RADIUS サーバーを設定し、ユーザーをプロキシーサーバーに追加するには、以下の手順に従います。
  1. radius ユーザー認証メソッドが有効になっていることを確認します。詳細は 「二要素認証の有効化」を参照してください。
  2. ipa radiusproxy-add proxy_name --secret secret コマンドを実行して RADIUS プロキシーを追加します。このコマンドにより、必要な情報を入力するように求められます。
    RADIUS プロキシの設定には、認証情報をラッピングするためにクライアントとサーバー間で共通のシークレットを使う必要があります。このシークレットは、--secret パラメーターで指定します。
  3. ipa user-mod radiususer --radius=proxy_name コマンドを実行して、追加したプロキシーにユーザーを割り当てます。
  4. 必要に応じて、ipa user-mod radiususer --radius-username=radius_user を実行し、RADIUS に送信するユーザー名を設定します。
これで、ユーザー OTP 認証が、RADIUS プロキシサーバーから処理されるようになります。

注記

FIPS モードを有効にして IdM マスターで RADIUS サーバーを実行するには、「FIPS モードで稼働している IdM サーバーで RADIUS プロキシを設定するのに必要な設定」 で説明している手順を実行します。
ユーザーが IdM ネイティブの OTP システムに移行する準備ができたら、そのユーザーへの RADIUS プロキシーの割り当てを削除します。

22.3.7.1. 低速ネットワークで RADIUS サーバーを実行している際の KDC のタイムアウト値の変更

低速ネットワーク環境で RADIUS プロキシを実行しているなど、特定の状況では、ユーザーによるトークンの入力を待っている際に、接続がタイムアウトするため RADIUS サーバーが応答する前に、IdM KDC が接続を閉じます。
KDC のタイムアウト設定を変更するには:
  1. /var/kerberos/krb5kdc/kdc.conf ファイルの [otp] セクションで timeout パラメーターの値を変更します。たとえば、タイムアウトを 120 秒に設定します。
    [otp]
    DEFAULT = {
      timeout = 120
      ...
    }
  2. krb5kdc サービスを再起動します。
    # systemctl restart krb5kdc

22.3.8. 現在の認証情報の二要素認証へのプロモート

パスワードと二要素認証の両方を設定しているにも関わらず、パスワードでのみ認証を行った場合には、特定のサービスやホストへのアクセスが拒否される可能性があります (「ユーザーの認証情報をもとにサービスやホストへのアクセス制限」 を参照)。このような場合には、もう一度認証を行うことで、一要素から二要素認証にプロモートしてください。
  1. 画面をロックします。画面ロックのデフォルトのキーボードショートカットは Super key+L です。
  2. 画面のロックを解除します。認証情報を求められたら、パスワードと OTP の両方を使用します。

22.3.9. OTP トークンの再同期

22.3.10. 損失した OTP トークンの置き換え

以下の手順では、OTP トークンを失ったユーザーがトークンを置き換える方法を説明しています。
  1. 管理者として、このユーザーのパスワードと OTP 認証を有効にします。
    [admin@server]# ipa user-mod --user-auth-type=password --user-auth-type=otp user_name
  2. これでユーザーは新しいトークンを追加できます。説明で設定した New Token を持つ新しいトークンを追加するには:
    [user@server]# ipa otptoken-add --desc="New Token"
    詳細は、ipa otptoken-add --help パラメーターを追加してコマンドを実行します。
  3. これでユーザーは古いトークンを削除できるようになりました。