検索

Identity Management ガイド

download PDF
Red Hat Enterprise Linux 6

Linux ベースのインフラストラクチャーの ID および承認ポリシーの管理

概要

ユーザーおよびマシン両方のアイデンティティー管理およびポリシー管理は、多くのエンタープライズ環境おいて中核的な機能となっています。IPA は、ID ドメインを作成する方法を提供し、このドメインにより、マシンはドメインへの登録と、シングルサインオンおよび認証サービスに必要となる ID 情報に即座にアクセスすることができるようになります。また、承認およびアクセスを管理するポリシー設定も可能になります。本書では、サーバーとクライアントの両方など、IPA ドメインのインストール、設定、および管理におけるすべての側面について説明します。このガイドは、IT および システム管理者用です。

第1章 Identity Management の概要

Red Hat Enterprise Linux IdM を使用して、ネイティブの Linux ツールを使用して、ID ストア、集中認証、Kerberos および DNS サービスのドメイン制御、および認可ポリシーを作成します。Identity Management は ID/ポリシー/認証が集約化されたソフトウェアが新たに導入されましたが、Identity Management は Linux/Unix ドメインをサポートする唯一のオプションの 1 つです。
Identity Management は、PAM、LDAP、Kerberos、DNS、NTP、証明書サービスなど、標準定義の一般的なネットワークサービスを統一し、Red Hat Enterprise Linux システムがドメインコントローラーとして機能できるようにします。
Identity Management は、Kerberos や DNS などの一元管理されたサービスを共有するサーバーおよびクライアントが含まれるドメインを定義します。本章では、最初に Identity Management の概要を説明します。本章では、ドメイン内でこれらのサービスがどのように連携し、またサーバーとクライアントがどのようにインタラクションを取るかについても説明します。

1.1. IdM v.LDAP: より集約的なサービスタイプ

最も基本的なレベルでは、Red Hat Identity Management は Linux および Unix マシンのドメインコントローラーを指します。Identity Management は、制御サーバーおよび登録されたクライアントマシンを使用してドメインを定義します。これにより、Linux/Unix 環境でネイティブの Linux アプリケーションやプロトコルを使用して、これまで利用できなかった集中構造が提供されます。

1.1.1. Identity Management の作業定義

セキュリティー情報は通常、ユーザー、マシン、およびサービスの アイデンティティー に関係があります。アイデンティティーの確認が済むと、サービスおよびリソースへのアクセスを制御できます。
IT 管理者は、効率性、リスク管理、管理の容易化ができるように、ID をできる限り一元管理し、認証ポリシーおよび認可ポリシーで I D 管理を統一しようと試みます。これまで、Linux 環境では、この集中管理の確立が非常に困難でした。ドメインを定義するプロトコル (NIS や Kerberos など) には多数ありますが、他にデータ(LDAP など) を保存したり、未だにアクセス権限 (sudo など) を管理したりするアプリケーションもあります 。これらのアプリケーションはいずれも、相互操作ができないだけでなく、異なる管理ツールを使用します。各アプリケーションは別々に、ローカルで管理される必要がありました。アイデンティティーポリシーを一貫性を持って取得するには、手動で設定ファイルをコピーするか、ID およびポリシーを管理するプロプライエタリーアプリケーションの開発を試みる方法しかありません。
Identity Management は、管理のオーバーヘッドを単純化することが目的です。ユーザー、マシン、サービス、およびポリシーはすべて、同じツールを使用して 1 つの場所で設定されます。IdM でドメインが作成されるので、複数のマシンはすべてそのドメインに参加して同じ設定とリソースを使用できます。ユーザーは一度だけサービスにログインするだけで済み、また管理者は単一のユーザーアカウントを管理するだけで済みます。
IdM は以下の 3 点を行います。
  • Linux ベースおよび Linux 制御のドメインを作成する。IdM サーバーおよび IdM クライアントはどちらも Linux または Unix マシンです。IdM は Active Directory ドメインとデータを同期して Windows サーバーとの統合を可能にしますが、Windows マシンの管理ツールではないので Windows クライアントはサポート対象ではありません。Identity Management は、Linux ドメインの管理ツールです。
  • ID 管理と ID ポリシーを一元化する。
  • 既存のネイティブの Linux アプリケーションおよびプロトコル上に構築する。IdM には独自のプロセスと設定がありますが、その基盤となる技術は Linux 管理者から信頼されているだけでなく、Linux システムで十分に確立されています。
このように、Identity Management を使用することで、管理者は新しい作業を行うのではなく、作業内容を改善できるようになります。以下に、いくつか例を示します。
1 つの極端な例として、制御レベルの低い 環境が挙げられます。Little Example Corp. には複数の Linux サーバーと Unix サーバーがありますが、各サーバーは別々に管理されています。パスワードはすべてローカルマシンに保存されるので、集約された ID または認証プロセスはありません。Tim (IT 管理者) は、すべてのマシンでユーザーを管理し、認証ポリシーと承認ポリシーを別々に設定してローカルパスワードを管理する必要があります。IdM を使用すると、作業が整理されます。ユーザー、パスワード、およびポリシーストアを簡単に集約する方法があり、Tim (IT 管理者) は、マシン 1 台 (IdM サーバー) のみで ID を管理して、ユーザーとポリシーを同じように全マシンに適用します。ホストベースのアクセス制御、委譲などのルールを使用すると、ノートパソコンやリモートユーザーに異なるアクセスレベルを設定することもできます。
中間の例として、制御レベルが中規模 の環境が挙げられます。Mid-Example Corp. には Linux および Unix の複数のサーバーがありますが、Bill (IT 管理者) は、マシンの NIS ドメイン、ユーザー用の LDAP ディレクトリー、認証用の Kerberos を作成して、詳細にわたる制御レベルを管理しようとしています。この環境は適切に管理されていますが、異なるツールを使用して各アプリケーションは別々に管理する必要があります。また、インフラストラクチャーに新しいマシンが追加されたり、サービスがオフラインになると必ず、すべてのサービスを手動で更新する必要があります。このような場合に、IdM を使用すると、簡素化されたツールセット 1 つで、さまざまなアプリケーションをすべてシームレスに統合するため、管理のオーバーヘッドが大幅に削減されます。また、ドメイン内のすべてのマシンにシングルサインオンサービスを実装することもできます。
反対の極端な例として、制御のない 環境が挙げられます。Big Example Corp では、システムの大半が Windows ベースで、密接に統合された Active Directory フォレストで管理されています。ただし、開発、実稼働などのチームには、Linux システムや Unix システムが多数あり、これらのシステムは基本的に Windows が制御する環境から除外されます。IdM は、Active Directory フォレストでは利用できないネイティブツールおよびアプリケーションを使用して、Linux/Unix サーバーをネイティブで管理できるようにします。さらに、IdM は Windows に対応しているため、Active Directory と IdM との間でデータを同期し、集中管理されたユーザーストアを確保できます。
IdM は、ID 管理という非常に一般的であり、また非常に特殊な問題に、非常に簡単なソリューションを提供します。

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

Identity Management に最も近いものは、389 Directory Server などの標準 LDAP ディレクトリーですが、実際の機能と、意図する機能 にはいくつかの大きな違いがあります。
まず、ディレクトリーサービスとは何かを理解すると役立ちます。ディレクトリーサービスとは、情報を格納するソフトウェア、ハードウェア、およびプロセスの集合のことです。ディレクトリーサービスは、非常に具体的な情報 (例: ホスト名の情報を格納するためディレクトリーサービス) ですが、汎用ディレクトリーサービスはあらゆる種類の情報を保管して取得できます。389 Directory Server などの LDAP ディレクトリーは汎用ディレクトリーです。ユーザー、マシン、ネットワークエンティティー、物理的設備、ビルのエントリーをサポートする柔軟なスキーマがあり、このスキーマをカスタマイズしてほぼすべてのエントリーを定義できます。389 Directory Server のような LDAP サーバーは、拡張性があるため、他のアプリケーションのデータを格納するバックエンドとして頻繁に使用されます。389 directory Server には情報を格納するだけでなく、整理します。LDAP ディレクトリーは、階層構造 (ディレクトリーツリー) を使用して、エントリーをルートエントリー (サフィックス)、中間エントリーまたはコンテナーエントリー (サブツリーまたはブランチ)、およびリーフエントリー (実際のデータ) に整理します。ディレクトリーツリーには、多くの分岐点を持つ非常に複雑なものと、分岐点が少ない非常に単純な (フラット) ものがあります。
LDAP ディレクトリーの主な機能は汎用性で、さまざまなアプリケーションに適合するようにできます。
一方、ID 管理には非常に特殊な目的があり、非常に特殊なアプリケーションに適合します。これは一般的な LDAP ディレクトリーやバックエンド、ポリシーサーバーではなく、これは汎用性はありません。
Identity Management は、アイデンティティー (ユーザーおよびマシン) および、アイデンティティーとそのインタラクションに関連するポリシーに重点を置いています。IdM は LDAP バックエンドを使用してデータを保管しますが、ID 関連のエントリーの特定セットやその詳細を定義する高度にカスタマイズされた特定のスキーマセットがあります。IdM には、エントリータイプや、その目的に関連のある関係が少ししかないので、比較的フラットで、シンプルなディレクトリーツリーが使用されています。また、ID の管理といった特定の目的でしかデプロイできないので、IdM サーバーのデプロイ方法にはルールや制限があります。
また、IdM には制限があるので、管理作業が大幅に簡素化されます。IT インフラストラクチャー全体で明確にロールが定義されているだけでなく、インストールプロセスはシンプルで、コマンドも統一されています。IdM ドメインは、設定、参加、管理が簡単で、特にエンタープライズ全体でのシングルサインオンなどのアイデンティティー/認証タスクといった機能も、より汎用的なディレクトリーに比べ、IdM では実現しやすくなっています。
表1.1 Identity Management と 389 Directory Server の比較
389 ディレクトリーサーバー ID 管理
使用方法 汎用 単一のドメイン、ID 管理にフォーカス
柔軟性 高度にカスタマイズ可能 ID と認証にフォーカスする際に制限あり
スキーマ デフォルトの LDAP スキーマ ID 管理向けに最適化された特別なスキーマ
ディレクトリーツリー 標準および柔軟な階層 階層が固定されたフラットツリー
認証 LDAP Kerberos または Kerberos および LDAP
Active Directory の同期 双方向 一方向、Active Directory から Identity Management
パスワードポリシー LDAP ベース Kerberos ベース
ユーザーツール Java コンソールおよび標準の LDAP ユーティリティー Web ベースの UI および特別な Python コマンドラインツール
389 Directory Server などの LDAP ディレクトリーは柔軟性と適応性があるので、任意数のアプリケーションのバックエンドとして最適です。LDAP ディレクトリーの主な目的は、データを効率的に保存して取得することです。
IdM は非常に異なる隙間を埋めます。IdM は、1 つのタスクを非常に効果的に実行するように最適化されています。ユーザー情報、認証および認可ポリシー、およびホスト情報などのアクセスに関する情報などを保存します。その唯一の目的は、アイデンティティーを管理することです。

1.2. Linux サービスの統合

Identity Management を使用すると、異種ではあるが関連性のある Linux サービスを単一の管理環境に統合されます。その単一の管理環境から、ホストマシンをそれらのサービスのドメインに配置するシンプルかつ簡単な方法を確立します。
IdM サーバーは、基本的には ID サーバーおよび認証サーバーです。プライマリー IdM サーバーは基本的にドメインコントローラーで、認証に Kerberos サーバーと KDC を使用します。LDAP バックエンドには、ユーザー、クライアントマシン、およびドメイン設定を含むすべてのドメイン情報が含まれます。

図1.1 IdM サーバー: サービスの統合

IdM サーバー: サービスの統合
コア ID/認証機能をサポートをするために、その他のサービスが含まれています。DNS は、マシンの検出や、ドメイン内の他のクライアントへの接続に使用されます。NTP を使用してすべてのドメインクロックを同期し、ログ、証明書、および操作が期待どおりに実行されるようにします。証明書サービスは、Kerberos 対応のサービスに証明書を提供します。これらの追加サービスは、すべて IdM サーバーの制御下で機能します。
IdM サーバーには、IdM 関連の全サービスの管理に使用するツールセットもあります。LDAP サーバー、KDC、DNS 設定を個別に管理するのではなく、ローカルマシン上にある異なるツールを使用する IdM には、単一の管理ツールセット (CLI および Web UI) があり、ドメインを集約的に、まとめて管理できるようにします。

1.2.1. 認証: Kerberos KDC

Kerberos は認証プロトコルです。Kerberos は共通鍵暗号を使用して、ユーザーに対して チケット を生成します。Kerberos 対応のサービスはチケットのキャッシュ (キータブ) を確認して、有効なチケットでユーザーを認証します。
他のマシン上のサービスにアクセスする場合でも、パスワードがネットワークで送信されないので、Kerberos 認証は通常のパスワードベースの認証よりもはるかに安全です。からです。
Identity Management では、Kerberos 管理サーバーが IdM ドメインコントローラーで設定され、すべての Kerberos データが IdM のバックエンド Directory Server に保存されます。Directory Server インスタンスは、Kerberos データのアクセス制御を定義して、有効化します。
注記
IdM Kerberos サーバーは、そのデータすべてが Directory Server インスタンスに保存されるため、Kerberos ツールではなく IdM ツールを使用して管理されます。KDC は Directory Server を認識しないため、Kerberos ツールで KDC を管理しても IdM 設定には影響はありません。

1.2.2. データストレージ: 389 Directory Server

Identity Management には、内部の 389 Directory Server インスタンスが含まれます。IdM にあるすべての Kerberos 情報、ユーザーアカウント、グループ、サービス、ポリシー情報、DNS ゾーン、ホストエントリーなどの情報は、この 389 Directory Server インスタンスに保存されます。
389 Directory Server は マルチマスターレプリケーション をサポートするので、複数のサーバーを設定すると、サーバー間で相互に対話することができます。合意は、初期サーバーと追加の レプリカ の間で自動的に設定されます。

1.2.3. 認証: Dogtag Certificate System

Kerberos は、証明書と、認証のキータブを使用でき、サービスによってはセキュアな通信を行うために証明書が必要です。Identity Management には、サーバーの認証局や Dogtag Certificate System が含まれます。この CA は、IdM ドメイン内のサーバー、レプリカ、ホストおよびサービスに証明書を発行します。
CA は root CA に指定することも、別の外部 CA で定義したポリシー (対象の CA に 従属 させる) を指定することできます。IdM サーバーの設定時に CA が Root CA か従属 CA かが決定されます。

1.2.4. サーバー/クライアントの検出: DNS

Identity Management はドメインを定義します。ドメイン内では、異なるユーザーおよびサービスが含まれる複数のマシンがあり、それぞれ共有リソースにアクセスし、共有の ID、認証、ポリシー設定を使用します。クライアントは、IdM サーバーとして相互に通信できる必要があります。また、Kerberos などのサービスでは、ホスト名により、プリンシパル ID が特定されます。
ホスト名は、ドメインネームサービス (DNS) を使用して IP アドレスに関連付けられます。DNS はホスト名を IP アドレスに、IP アドレスをホスト名にマッピングして、ホストを検索する必要がある場合にクライアントが使用できるリソースを提供します。クライアントが IdM ドメインに登録されると、DNS サービス検出を使用して、ドメイン内の IdM サーバーを特定し、ドメイン内のすべてのサービスおよびクライアントを特定します。
クライアントインストールツールは、サービス検出に IdM ドメインを使用するように、ローカルの System Security Services Daemon (SSSD) を自動的に設定します。SSSD は、すでに DNS を使用して LDAP/TCP サービスおよび Kerberos/UDP サービスを検索するので、クライアントインストールではドメイン名を指定するだけで済みます。SSSD サービス検出については、『Red Hat Enterprise Linux デプロイメントガイド』の「SSSD」の章で説明しています。
サーバーで、インストールスクリプトを使用して、DNS サービス検出クエリーに対応するのはどれかを指定する DNS ファイルを設定します。デフォルトでは、DNS 検出は TCP の LDAP サービスと、UDP および TCP にあるさまざまな Kerberos サービスにクエリーを実行します。作成された DNS ファイルについては、「既存の DNS 設定での IdM および DNS サービス検出の使用」で説明します。
注記
IdM サーバーが DNS サービスをホスト せずに、DNS サービスを使用するように IdM ドメインを設定することは技術的には可能ですが、これは推奨されません。
通常は、DNS サーバーを複数設定し、それぞれが特定のドメイン内のマシンの管理リソースとして機能します。IdM サーバーを DNS サーバーとして指定するのは任意ですが、強く推奨します。IdM サーバーが DNS を管理する場合には、DNS ゾーンと IdM クライアントが密接に統合され、ネイティブの IdM ツールを使用して IdM クライアントと DNS 設定を管理できます。IdM サーバーが DNS サーバーであっても、他の外部 DNS サーバーも使用できます。

1.2.5. 管理: SSSD

SSSD (System Security Services Daemon) は、認証情報をキャッシュするプラットフォームアプリケーションです。システム認証の多くは、ローカルで設定されているので、サービスは、ローカルユーザーストアをチェックして、ユーザーと認証情報を判断する必要があります。SSSD を使用することで、ローカルサービスは SSSD のローカルキャッシュをチェックできます。このキャッシュは、Identity Management を含むさまざまなリモートアイデンティティープロバイダーから取得できます。
SSSD は、ユーザー名とパスワード、Kerberos プリンシパルおよびキータブ、IPA サーバーで定義された sudo ルール、Identity Management ドメインおよびシステムが使用する SSH 鍵をキャッシュできます。SSSD を使用すると、管理者には大きな利点が 2 つあります。全 ID 設定を 1 つのアプリケーション (IdM サーバー) に集約できる点、システムまたは IdM サーバーが利用できなくなった場合に、ローカルシステムに外部情報をキャッシュして、通常の認証操作を続行できる点です。
SSSD は、IdM クライアントのインストールと管理スクリプトによって自動的に設定されるので、ドメイン設定が変更されても、システム設定を手動で更新する必要はありません。
SSSD では、Windows Active Directory と同様に、ユーザー名属性またはユーザープリンシパル名 (UPN) 属性のいずれかでログインできます。
SSSD は、case_sensitive オプションで truefalse、および preserve の値をサポートします。preserve 値が有効にな場合には、入力内容は大文字と小文字に関係なく一致しますが、出力内容は常にサーバーと同じものを使用します。SSSD は、設定された UID フィールドの大文字、小文字設定を保持します。
SSSD は、バックグラウンドでキャッシュされた特定のエントリーを更新でき、バックエンドは常に更新されているため、エントリーが即時に返されます。現在、ユーザー、グループ、および netgroups のエントリーがサポートされています。

1.2.6. 管理: NTP

多くのサービスでは、特定の差異内でサーバーとクライアントが同一のシステムタイムを保持している必要があります。たとえば、Kerberos チケットはタイムスタンプを使用して有効性を判断します。サーバーとクライアントの時間の差異が許可された範囲内から逸脱すると、Kerberos チケットは無効になります。
Network Time Protocol (NTP) を使用して、ネットワーク上でクロックが同期されます。中央サーバーは、信頼できるクロックとして機能し、対象の NTP サーバーを参照するすべてのクライアントが、同じ時刻を使用するように同期します。
IdM サーバーがドメインの NTP サーバーである場合には、他の操作が実行される前に、常に時刻と日付が同期されます。これにより、パスワードの有効期限、チケット、証明書の有効期限、アカウントのロックアウトの設定、エントリー作成日など、日付関連のサービスがすべて想定通りに機能させることができます。
デフォルトでは、IdM サーバーは、ドメインの NTP サーバーとして機能します。他の NTP サーバーは、ホストに使用することもできます。

1.3. サーバーとクライアント間の関係

Identity Management 自体は、ドメイン (設定、ポリシー、およびアイデンティティーストアを共有するマシンのグループ) を定義します。この共有設定により、ドメイン内のマシン (およびユーザー) が相互を認識して共同操作ができるようになります。マシン間の認識機能を使用して、Windows システムと Linux システムの統合などのプラットフォーム間の互換性や、インフラストラクチャー全体のシングルサインオンを有効にできます。

1.3.1. IdM サーバーおよびレプリカの概要

Identity Management は、ユーザーおよびマシン ID およびドメイン全体のポリシーの情報のマスターストアであるサーバーを特定することで機能します。これらのサーバーは、認証局、NTP、Kerberos、SSH、DNS などのドメイン関連のサービスをホストします。このサーバーは、アイデンティティーおよびポリシー情報の中央リポジトリーとしても機能します。
クライアントは、(SSSD および Kerberos を介して) ファイル共有、サービス、リモートマシン、認証などのドメインリソースにアクセスを試みると、IdM サーバーと間接的に対話します。
前述のとおり、IdM サーバーは、多くの関連サービスのコントローラーとなります。これらのサービスの多くが サポート されますが、そのほとんどは 必須 ではありません。たとえば、サーバーに CA、DNS サーバー、または NTP サーバーを追加することも、これらのサービスなしでインストールすることもできます。
IdM サーバーの設定が済むと、その設定をコピーして、別の IdM サーバーのベースとして使用できます。IdM サーバーをコピーすると、そのコピーは レプリカ と呼ばれます。
注記
IdM サーバーと IdM レプリカの実際の相違点は、サーバーが新規インストールされているかどうかだけです。ドメイン設定を定義するので、レプリカは既存のサーバーおよびドメイン設定をもとに作成されます。
インスタンスが設定されると、IdM ドメイン内における機能や動作の面で、サーバーとレプリカは基本的に同じです。
IdM サーバー (およびレプリカ) トポロジーには、柔軟性が十分にあります。たとえば、サーバー A は CA サービスおよび DNS サービスと共にインストールできますが、レプリカ A はサーバー A の設定を基にすることはできますが、DNS や CA サービスをホストできません。レプリカ B は、CA サービスや DNS サービスを使用せずにドメインに追加できます。今後はいつでも、CA または DNS サービスを作成して、レプリカ A またはレプリカ B 上に設定できます。
サーバーとレプリカはいずれも基盤の LDAP ディレクトリーを使用して、ユーザーとホストエントリー、設定データ、ポリシー設定、キータブ、証明書、およびキーを保存します。サーバーおよびレプリカは、マルチマスターのレプリカ合意 によりデータを相互に伝播します。レプリカ合意は、すべての LDAP バックエンドおよび Dogtag Certificate System が使用する LDAP サブツリーに対して設定されます。サーバーとレプリカはいずれもレプリケーショントポロジーではマスター (ピア) です。
IdM ドメイン内のサーバーはすべて LDAP ピアサーバーであるため、レプリケーショントポロジーは 389 Directory Server ドメインのトポロジー制限に準拠する必要があります。つまり、IdM ドメインに 20 台を超えるピアサーバーを存在させることができません。サーバー/レプリケーショントポロジーのプランニングの詳細は、「サーバー/レプリカトポロジーの計画」を参照してください 。

図1.2 サーバーおよびレプリカの対話

サーバーおよびレプリカの対話
ヒント
レプリケーショントポロジーは基本的に IdM サーバーのクラウドを作成します。サーバードメインの利点の 1 つに、DNS の SRV レコードを使用した自動負荷分散が挙げられます。SRV レコードは、サーバーやレプリカの問い合わせの優先順位を設定し、加重を使用して同じ優先順位のサーバー/レプリカ間で負荷が分散されます。サーバーおよびレプリカの DNS エントリーを編集して負荷分散を変更できます。この点については、例17.9「SRV レコード」および「IdM サーバーおよびレプリカの負荷分散の変更」で説明されています。

1.3.2. IdM クライアントの概要

クライアントとは単に、Kerberos および DNS サービス、NTP 設定、および証明書サービスを使用して、IdM ドメイン内で動作するように設定されたマシンのことを指します。クライアントにはデーモンが必要なく、製品をインストールしておく必要がない点が重要な違いです。IdM クライアントにはシステム設定のみが必要で、この設定で、IdM サービスを使用するように指示します。
Red Hat Enterprise Linux システムでは、SSSD (System Security Services Daemon) などの、IdM が使用できるプラットフォームツールが多数あります。IdM サービスと連携する基盤のプラットフォームが使用されている場合には、プラットフォームアプリケーションで IdM が有効になります。特定の PAM モジュールや IdM コマンドラインユーティリティーなどの他のツールは、マシンにインストールされる IdM 固有のパッケージとして Identity Management に同梱されます。これは、Identity Management で使用されるプラットフォームコンポーネントではなく、IdM コンポーネントです。

図1.3 サーバーおよびクライアントの対話

サーバーおよびクライアントの対話
IdM は、クライアントでローカルストレージ (キャッシュ) を使用して、以下のような方法でパフォーマンスを向上します。
  • マシンがオフライン時に IdM 情報を保存します。
  • クライアントが中央サーバーにアクセスできない場合は、通常のタイムアウト期間が過ぎた後も情報をアクティブな状態で保持します。このキャッシュは、マシンをリブートした後も永続されます。
  • サーバーを確認する前にローカルで情報をチェックして、要求のラウンドトリップタイムを短縮します。
情報は、種類 に応じて LDB データベース (LDAP と同様) またはローカルファイルシステム (XML ファイル) のいずれかに保存されます。
  • ユーザー、マシン、およびグループに関する ID 情報は、LDAP ディレクトリーと同じ構文を使用する LDB データベースに保存されます。この ID 情報は、元は IdM サーバーの 389 Directory Server インスタンスに保存されていました。この情報は頻繁に変更、参照されるため、より最新の情報を迅速に呼び出すことが重要ですが、これは、クライアント上の LDB データベースとサーバーの Directory Server を使用することで可能になります。
  • ポリシー情報は ID 情報よりも静的で、SELinux または sudo の設定を追加できます。これらのポリシーはサーバー上でグローバルに設定され、クライアントに伝播されます。クライアントでは、 ポリシー情報は XML ファイルのファイルシステムに保存されるので、どのサービスを管理する場合でも、ダウンロードしてネイティブファイルに変換できます。
IdM サーバーの特定のサービスセットは、IdM クライアントのサービスとモジュールのサブセットと対話します。クライアントとは、IdM ドメインからキータブまたは証明書を取得できるマシン (ホスト) です。

図1.4 IdM サービス間の対話

IdM サービス間の対話
図1.4「IdM サービス間の対話」では、Red Hat Enterprise Linux がネイティブのデーモンを 2 つ使用して IdM サーバーを操作しています。
  • SSSD では、マシンのユーザー認証ができ、ホストベースのアクセス制御ルールを有効にします。
  • certmonger は、クライアント上の証明書を監視、更新します。仮想マシンなどのシステム上のサービス向けに新規の証明書をリクエストできます。
Red Hat Enterprise Linux クライアントがドメインに追加される (登録される) と、SSSD と certmonger は IdM サーバーに接続するように設定され、必要な Kerberos キータブとホストの証明書が作成されます。(ホスト証明書は、Web サーバーなどの他のサービスで使用される可能性はありますが、IdM では直接使用されません。)

パート I. Identity Management のインストール: サーバーおよびサービス

第2章 インストールの前提条件

IdM をインストールする前に、インストール環境が適切に設定されていることを確認してください。また、レルム名や特定のユーザー名およびパスワードなど、インストールおよび設定手順中に、特定の情報を指定する必要があります。本セクションでは、指定する必要のある情報について説明します。

2.1. サポート対象のサーバープラットフォーム

IdM 3.0 へのサポートがあるのは、以下のプラットフォームです。
  • Red Hat Enterprise Linux 6 i386
  • Red Hat Enterprise Linux 6 x86_64

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

証明書のシンプルなホストエントリーと同様に、基本的なユーザーエントリーのサイズは、約 1 KB です。ハードウェアでは、RAM の容量を適切に確保することが最も重要になります。すべてのデプロイメントは、ユーザーおよびグループ数や、保存データの種類により異なりますが、以下のように、使用する RAM 容量を判断する一般的な方法があります。
  • 10,000 ユーザーおよび 100 グループの場合は、最低 2 GB の RAM と 1 GB のスワップ領域を割り当てます。
  • 100,000 ユーザーおよび 50,000 グループの場合は、最低 16GB の RAM と 4GB のスワップ領域を割り当てます。
注記
大規模なデプロイメントでは、データのほとんどがキャッシュに保存されるため、ディスクスペースを増やすよりも RAM を増やす方が効果的です。
IdM サーバーが使用する基本的な Directory Server インスタンスは、パフォーマンスの向上を図るため調整可能です。チューニング情報は、『Directory Server』のドキュメントを参照してください。

2.3. ソフトウェア要件

IdM サーバーに依存するパッケージの大半は、IdM パッケージのインストール時に依存関係としてインストールされます。ただし、IdM パッケージのインストール前に必要なパッケージが複数あります。
  • Kerberos 1.10インストールされていない場合は、依存関係としてインストールされます。
  • DNS の bind および bind-dyndb-ldap パッケージ。すでにインストールされていない場合には bind パッケージは依存関係としてインストールされますが、bind-dyndb-ldap パッケージは先に明示的にインストールする必要があります。先にインストールされていない場合には、DNS サポートありの IdM サーバーを設定しようとすると失敗します。
重要
CVE-2014-3566 のため SSLv3 (Secure Socket Layer version 3) プロトコルは mod_nss モジュールで無効にする必要があります。次の手順に従い、無効になっていることを確認してください。
  1. /etc/httpd/conf.d/nss.conf ファイルを編集し、NSSProtocol パラメーターを TLSv1.0 (後方互換性用) および TLSv1.1 に設定します。
    NSSProtocol TLSv1.0,TLSv1.1
  2. httpd サービスを再起動します。
    # service httpd restart

2.4. システムの要件

ホストシステムに関する一定の前提条件を基に作成された設定スクリプトを使用して、IdM サーバーは設定されています。システムがこの前提条件を満たさないと、サーバーの設定に失敗する可能性があります。

2.4.1. DNS レコード

IdM サーバーおよびレプリカ (サーバーの複製) の療法を設定するには、適切な正引きおよび逆引きの DNS 設定が重要です。DNS は、サーバー間のデータの複製、SSL 証明書でのサーバーの特定、Kerberos チケットなどで使用されます。そのため、サーバーは正引きおよび逆引き両方の DNS 設定で解決できる必要があります。
ホストの DNS 設定は、ifconfigdig を使用して簡単に判断できます。
  1. ホスト名を取得します。
    [root@server ~]# hostname
    server.example.com
  2. IP アドレスを取得します。この例では、196.2.3.4 の IP アドレスが返されました。
    [root@server !]# ifconfig eth0
    eth0      Link encap:Ethernet  HWaddr 52:54:01:4C:E1:2C
              inet addr:196.2.3.4  Bcast:196.9.8.7  Mask:255.255.255.255
              inet6 addr: 2620:52:0:102f:5054:1ff:fe4c:e12c/64 Scope:Global
    	  inet6 addr: fe80::5054:1ff:fe4c:e12c/64 Scope:Link
    ...
  3. dig を使用して、ホスト名のクエリーと、返される IP アドレスのチェックを行い、正引き DNS が適切に設定されていることを確認します。この例では、想定される IP アドレスは 196.2.3.4 です。
    [root@server ~]# dig server.example.com
    ; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.17.rc1.el6 <<>> server.example.com
    ;; global options: +cmd
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 56680
    ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 7, ADDITIONAL: 12
    
    ;; QUESTION SECTION:
    ;server.example.com. IN A
    
    ;; ANSWER SECTION:
    server.example.com. 2946 IN A 196.2.3.4
  4. -t ptr を指定した dig を使用して、アドレスの PTR レコード (逆引きレコード) にクエリーを実行し、 逆引き DNS 設定を確認します。これは、.in-addr.arpa. が追加された、逆順の IP アドレスです。これにより、ホスト名が解決されます (この例では server.example.com.)。
    [root@server ~]# dig -t ptr 4.3.2.196.in-addr.arpa. 
    ; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.17.rc1.el6 <<>> -t ptr 241.40.16.10.in-addr.arpa
    ;; global options: +cmd
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 57899
    ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 7, ADDITIONAL: 10
    
    ;; QUESTION SECTION:
    ;4.3.2.196.in-addr.arpa. IN PTR
    
    ;; ANSWER SECTION:
    4.3.2.196.in-addr.arpa. 21600 IN PTR server.example.com.
DNS レコードは、IdM 証明書で使用されるホスト名を解決する必要があります。
注記
IdM サーバーが独自の DNS サーバーをホストするように設定されている場合には、IdM DNS サービスは全 DNS クエリーを処理します。IdM DNS レコードが優先され、既存の DNS 設定は無視されます。
ドメイン内の全システムは、IdM 管理の DNS サーバーを使用するように設定する必要があります。

2.4.2. ホスト名および IP アドレスの要件

DNS が IdM サーバー内にあるか、外部にあるかに拘らず、サーバーホストには DNS を適切に設定する必要があります。
  • ホスト名は完全修飾ドメイン名である必要があります。例: ipaserver.example.com
    重要
    これは、数字、アルファベット文字、およびハイフン (-) のみが使用された有効な DNS 名でなければなりません。ホスト名にアンダースコアなどの他の文字が含まれていると、DNS が正常に機能しなくなります。
  • ホスト名はすべて小文字である必要があります。
  • サーバーの A レコードを設定し、パブリック IP アドレスを解決する必要があります。
    完全修飾ドメイン名は、ループバックアドレスを解決できません。127.0.0.1 ではなく、マシンの公開 IP アドレスを解決する必要があります。hostname コマンドの出力は、localhost または localhost6 であってはいけません。
    Adn PTR レコードは、サーバーと一致する必要はありません。
  • サーバーのホスト名および IP アドレスは独自の /etc/hosts ファイルに指定する必要があります。IdM サーバーの完全修飾ドメイン名は、hosts ファイルで、エイリアスの にリストする必要があります。
    注記
    ファイルが正しく設定されていない場合には、IdM コマンドラインツールが正しく機能しなくなり、IdM の Web インターフェースが IdM サーバーに接続できない可能性があります。
    また、ホスト名を localhost エントリーに追加することはできません。
    たとえば、以下の例では、ホストの IPv4 および IPv6 の localhost エントリーが (正確に) 表示され、最初のエントリーで IdM サーバーの IP アドレスとホスト名がその後に続いています。
    127.0.0.1	localhost.localdomain	localhost
    ::1		localhost6.localdomain6	localhost6
    192.168.1.1	ipaserver.example.com	ipaserver
    
  • IdM サーバーの管理用に別の DNS ドメインを割り当てることを推奨します。別の DNS ドメインを割り当てることは必須ではありませんが (この IdM ドメインに他のドメインのクライアントを引き続き登録可能)、DNS の管理を行うにあたり便利です。

2.4.3. ディレクトリーサーバー

ホストマシンにインストールされている 389 Directory Server のインスタンスは使用しないでください。

2.4.4. システムファイル

サーバーのスクリプトは、システムファイルを上書きして、IdM ドメインを設定します。システムは、DNS や Kerberos などのサービスのカスタム設定のない、クリーンな状態にしてから、IdM サーバーの設定を行ってください。

2.4.5. システムポート

IdM はサービスとの通信に多くのポートを使用します。IdM を機能させるには、表2.1「IdM ポート」に記載のこれらのポートを解放して利用できるようにする必要があります。別のサービスを使用したり、ファイアウォールでブロックしたりしないようにしてください。これらのポートが利用可能かどうかを確認するには、iptables ユーティリティーで、利用可能なポートを表示するか、nctelnet、または nmap ユーティリティーを使用して、ポートに接続するか、ポートのスキャンを実行します。
ポートを解放するには、以下を実行します。
[root@server ~]# iptables -A INPUT -p tcp --dport 389 -j ACCEPT
iptables(8) man ページには、システムでポートを解放して閉じる方法が詳述されています。
表2.1 IdM ポート
サービス ポート タイプ
HTTP/HTTPS 80、443 TCP
LDAP/LDAPS 389、636 TCP
Kerberos 88、464 TCP および UDP
DNS 53 TCP および UDP
NTP 123 UDP
Dogtag Certificate System - LDAP 7389 TCP

2.4.6. NTP

Network Time Protocol (NTP) は、ネットワーク上にあるシステムの時間を同期します。NTP サーバーは、ネットワーククロックの同期を一元管理します。デフォルトでは、Identity Management はドメインで使用される NTP サーバーをインストールして、IdM ドメイン内の他の Identity Management サーバー、レプリカ、システムおよびサービスのクロックを同期します。
正しく機能させるには、一部のドメインタスク (例: Kerberos チケットのメンテナンスおよびトポロジーにあるサーバーとレプリカ間のデータレプリケーション) に対して、NTP サーバーを実行する必要があります。IdM サーバーが NTP サーバーをホストする必要はありませんが、強く推奨されます。これはデフォルト設定になります。
サーバーが仮想マシンにインストールされている場合は、そのサーバーで NTP サーバーを実行しない でください。IdM の NTP を無効にするには、IdM サーバーの設定時に --no-ntp オプションを使用して、NTP サーバーがインストールされないようにします。

2.4.7. NSCD

IdM デプロイメントで nscd の使用を回避するか、制限することを強く推奨 します。nscd サービスは、サーバーでの負荷を減らしたり、クライアントの応答性を改善したりするのに非常に便利ですが、システムでも SSSD を使用する場合には独自にキャッシュの操作を行うので、問題が生じる可能性があります。
nscd は、getent など、nsswitch でクエリーを実行する全サービスの認証およびアイデンティティー情報をキャッシュします。nscd は、ポジティブキャッシュとネガティブキャッシュの両方を実行するので、特定の IdM ユーザーが存在しないと要求が判断した場合には、ネガティブな応答としてキャッシュします。キャッシュに保存されている値は、サーバーでの変更の有無に拘らず、キャッシュの有効期限が切れるまで保持されます。このようなキャッシュを作成すると、新規ユーザーとメンバーシップが表示されない可能性があり、削除されたユーザーおよびメンバーシップが依然として表示される可能性があります。
SSSD キャッシュとの競合やユーザーのロックアウトを回避するには、nscd を完全に使用しないようにします。または、/etc/nscd.conf ファイルの time-to-live (TTL) のキャッシュの値をリセットして、キャッシュ時間を短縮します。
positive-time-to-live   group           3600
negative-time-to-live   group           60
positive-time-to-live   hosts           3600
negative-time-to-live   hosts           20

2.4.8. ネットワーク

Red Hat Enterprise Linux ではデフォルトのネットワークサービスとして、NetworkManager が使用されます。ただし、NetworkManager は、IdM および KDC で問題を引き起こす可能性があります。network サービスを使用して IdM 環境でのネットワーク要件を管理し、NetworkManager サービスを無効にすることを強く推奨します。
  1. シングルユーザーモードでマシンを起動します。
  2. 起動リストで NetworkManager サービスを無効にし、NetworkManager サービスを停止します。
    [root@server ~]# chkconfig NetworkManager off; service NetworkManager stop
  3. NetworkManagerDispatcher がインストールされている場合には、NetworkManagerDispatcher が停止され、無効になっていることを確認します。
    [root@server ~]# chkconfig NetworkManagerDispatcher off; service NetworkManagerDispatcher stop
  4. 次に、ネットワーク サービスが適切に起動されていることを確認します。
    [root@server ~]# chkconfig network on; service network start
  5. また、静的ネットワークが正しく設定されていることを確認してください。
  6. システムを再起動します。

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

IdM ドメインは、 IdM サーバー (基本的にはドメインコントローラー) によって定義、管理されています。ドメインには、負荷分散とフォールトトレランス向けに、ドメインコントローラーが複数存在する場合があります。これらの追加サーバーは、マスター IdM サーバーの レプリカ と呼ばれます。
IdM サーバーおよびレプリカはいずれも、Red Hat Enterprise Linux システムでのみ動作します。サーバーおよびレプリカの両方に、必要なパッケージをインストールする必要があります。その後に、必要な全サービスを構成する設定スクリプトを使用して IdM サーバーまたはレプリカ自体を設定します。

3.1. IdM サーバーパッケージのインストール

IdM サーバーのみをインストールするには、ipa-server パッケージだけが必要です。IdM サーバーが DNS サーバーも管理する場合は、DNS の設定に追加パッケージが 2 つ必要になります。
これらのパッケージはすべて、次の yum コマンドを使用してインストールできます。
[root@server ~]# yum install ipa-server bind bind-dyndb-ldap
ipa-server をインストールすると、IdM ツールと合わせて、LDAP サービスの 389-ds-base や Keroberos サービスの krb5-server などの依存関係が多数インストールされます。
パッケージのインストール後に、ipa-server-install コマンドを使用してサーバーインスタンスを作成する必要があります。新しいサーバーインスタンスの設定オプションは、「ipa-server-install の概要」に記載されています。

3.2. ipa-server-install の概要

IdM サーバーインスタンスは、ipa-server-install スクリプトを実行して作成されます。このスクリプトは、IdM インスタンスが使用する DNS や Kerberos などのサービスのユーザー定義の設定を指定できます。また、管理者の入力を最小限に抑えられるように時点定義済みの値を指定することもできます。
IdM の設定スクリプトは、IdM ドメインに必要な全サービスの設定などを含めてサーバーインスタンスを作成します。
  • ネットワークタイムデーモン(ntpd)
  • 389 Directory Server インスタンス
  • Kerberos キー配布センター (KDC)
  • Apache (httpd)
  • 更新された SELinux ターゲットポリシー
  • Active Directory WinSync プラグイン
  • 認証局
  • 任意。ドメインネームサービス (DNS) サーバー
IdM 設定プロセスは、管理者が指定する情報が一部の必須の情報だけというように、最小限に抑えることができます。それ以外の多くの IdM サービスは、ユーザー定義設定で非常に具体的に指定されています。この設定は、ipa-server-install スクリプトで引数を使用して指定します。
注記
「システムポート」「Identity Management ファイルおよびログ」で定義されているように、IdM が使用するポート番号とディレクトリーの場所はすべて自動的に定義されます。これらのポートおよびディレクトリーは変更またはカスタマイズ できません
必要情報を入力するようにプロンプトが表示されるようにオプションを指定せずに ipa-server-install は実行できますが、このコマンドには、複数の引数を指定して、設定プロセスを簡単にスクリプト化したり、対話インストールで要求されない追加情報を指定したりできます。
表3.1「ipa-server-install オプション」には、ipa-server-install で使用される共通の引数が記載されています。オプションの完全なリストは ipa-server-install の man ページにあります。ipa-server-install オプションは、必要に応じて異なるサービスをインストールし、設定するために、特定のデプロイメント環境向けカスタマイズできるほど、汎用性が高くなっています。
表3.1 ipa-server-install オプション
引数 説明
-a ipa_admin_password IdM 管理者のパスワードこれは、admin ユーザーが Kerberos レルムに対して認証する場合に使用されます。
--hostname=hostname IdM サーバーマシンの完全修飾ドメイン名。
重要
これは、数字、アルファベット文字、およびハイフン (-) のみが使用された有効な DNS 名でなければなりません。ホスト名にアンダースコアなどの他の文字が含まれていると、DNS が正常に機能しなくなります。
さらに、ホスト名がすべて小文字である必要があります。大文字は使用できません。
-n domain_name IdM ドメインに使用する LDAP サーバードメインの名前。これは、通常 IdM サーバーのホスト名に基づいています。
-p directory_manager_password スーパーユーザーのパスワード (LDAP サービスの cn=Directory Manager)
-P kerberos_master_password KDC 管理者のパスワード。値が指定されていない場合に無作為に生成されます。
-r realm_name IdM ドメイン用に作成する Kerberos のレルム名。
--subject=subject_DN 発行した証明書のサブジェクト DN にベース要素を設定します。デフォルト設定は O=realm です。
--forwarder=forwarder DNS サービスで使用する DNS フォワーダーを指定します。複数のフォワーダーを指定するには、このオプションを複数回使用します。
--no-forwarders フォワーダーではなく DNS サービスを使用するルートサーバーを使用します。
--no-reverse DNS ドメインの設定時に、逆引き DNS ゾーンが作成 されないようにします 。(すでに逆引き DNS ゾーンが設定されている場合は、既存の逆引き DNS ゾーンが使用されます。) このオプションを使用しない場合には、デフォルト値は true になるので、インストールスクリプトで逆引き DNS を設定することを前提としています。
--setup-dns IdM ドメイン内に DNS サービスを設定するように、インストールスクリプトに指示します。統合 DNS サービスの使用は任意であるため、インストールスクリプトでこのオプションが指定されていない場合には、DNS は設定されません。
--idmax=number IdM サーバーで割り当て可能な ID の最大値を設定します。デフォルト値は ID 開始値 + 199999 です。
--idstart=number IdM サーバーで割り当て可能な ID の最小値 (開始値) を設定します。デフォルト値は無作為に選択されます。
--ip-address サーバーの IP アドレスを指定します。このオプションは ipa-server-install に追加すると、ローカルインターフェースに関連付けられた IP アドレスだけを許可します。
IdM サーバーのインストール方法は、ネットワーク環境、組織内のセキュリティー要件、および必要なトポロジーによって異なります。以下の例は、サーバーのインストール時に使用する一般的なオプションを示しています。これらの例は合わせて使用することができます。同じサーバー呼び出しで CA オプション、DNS オプション、および IdM 設定オプションは問題なく使用できます。単に各設定エリアに必要な内容を明確にするために、上記のオプションは個別に呼び出されます。

3.3. 例: 対話的および無人でのスクリプトの実行

3.3.1. 基本的な対話インストール

ipa-server-install スクリプトを実行するだけで、IdM サーバーを設定できます。これにより、スクリプトが対話的に起動し、サーバーの設定に必要な情報の入力を求めるプロンプトが表示されます。ただし、DNS や CA などの詳細な設定はされません。
  1. ipa-server-install スクリプトを実行します。
    [root@server ~]# ipa-server-install
  2. ホスト名を入力します。ホスト名は逆引き DNS を使用して自動的に決定されます。
    Server host name [ipaserver.example.com]:
  3. ドメイン名を入力します。ドメイン名は、ホスト名に基づいて自動的に決定されます。
    Please confirm the domain name [example.com]:
  4. 新しい Kerberos レルム名を入力します。Kerberos レルム名は、通常ドメイン名に基づいています。
    Please provide a realm name [EXAMPLE.COM]:
  5. Directory Server のスーパーユーザー (cn=Directory Manager) のパスワードを入力します。このパスワードには、強度の要件があります。たとえば、パスワードの最小長は 8 文字となっています。
    Directory Manager password:
    Password (confirm):
  6. IdM システムユーザーアカウント (admin) のパスワードを入力します。このユーザーはマシン上に作成されます。
    IPA admin password:
    Password (confirm):
  7. 次に、スクリプトにより、ホスト名、IP アドレス、およびドメイン名がもう一度出力されます。情報が正しいことを確認します。
    The IPA Master Server will be configured with
    Hostname:    ipaserver.example.com
    IP address:  192.168.1.1
    Domain name: example.com
    Realm name: EXAMPLE.COM
    Continue to configure the system with these values? [no]: yes
  8. その後、スクリプトで、IdM に関連付けられたサービスをすべて設定します。その際、タスク数と進捗バーが表示されます。
    Configuring NTP daemon (ntpd) 
    [1/4]: stopping ntpd 
    ...
    Done configuring NTP daemon (ntpd). 
    Configuring directory server (dirsrv): Estimated time 1 minute 
    [1/38]: creating directory server user 
    .... 
    Configuring certificate server (pki-tomcatd): Estimated time 3 minutes 30 seconds 
    [1/20]: creating certificate server user 
    ... 
    Done configuring certificate server (pki-tomcatd). 
    Configuring Kerberos KDC (krb5kdc): Estimated time 30 seconds 
    [1/10]: adding sasl mappings to the directory 
    ... 
    Done configuring Kerberos KDC (krb5kdc). 
    Configuring kadmin 
    [1/2]: starting kadmin 
    [2/2]: configuring kadmin to start on boot 
    Done configuring kadmin. 
    Configuring ipa_memcached 
    [1/2]: starting ipa_memcached 
    [2/2]: configuring ipa_memcached to start on boot 
    Done configuring ipa_memcached. 
    Configuring ipa-otpd 
    [1/2]: starting ipa-otpd 
    [2/2]: configuring ipa-otpd to start on boot 
    Done configuring ipa-otpd. 
    Configuring the web interface (httpd): Estimated time 1 minute 
    [1/15]: disabling mod_ssl in httpd 
    ... 
    Done configuring the web interface (httpd). 
    Applying LDAP updates 
    Restarting the directory server 
    Restarting the KDC 
    Sample zone file for bind has been created in /tmp/sample.zone.pUfcGp.db 
    Restarting the web server 
      
    Setup complete
  9. SSH サービスを再起動して、Kerberos プリンシパルを取得し、ネームサーバースイッチ (NSS) 設定ファイルを更新します。
    [root@server ~]# service sshd restart
  10. admin ユーザーの認証情報を使用して Kerberos レルムに認証を行い、ユーザーが適切に設定され、Kerberos レルムにアクセスできることを確認します。
    [root@server ~]# kinit admin
    Password for admin@EXAMPLE.COM:
  11. ipa user-find のようなコマンドを実行して IdM 設定をテストします。たとえば、以下のようになります。
    [root@server ~]# 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
    ----------------------------

3.3.2. 無人 (非対話型) インストール

「基本的な対話インストール」に記載されえいるように、IdM サーバーの設定に必要なのはわずかな情報だけです。設定スクリプトを使用すると対話モードでこの情報をプロンプトで求めることができますが、設定コマンドを使用してこの情報を指定する無人自動設定も可能です。
  • IdM 管理ユーザーおよび Directory Server のスーパーユーザー (Directory Manager) のパスワード
  • サーバーのホスト名
  • Kerberos レルム名
  • DNS ドメイン名
ipa-server-install-U を指定して上記の情報を渡すことで、ユーザーの操作を必要とせずに強制的に実行できるようになります。

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

[root@server ~]# ipa-server-install -a secret12 --hostname=ipaserver.example.com -r EXAMPLE.COM -p secret12 -n example.com -U
次に、スクリプトにより、指定された値が出力されます。
To accept the default shown in brackets, press the Enter key.

The IPA Master Server will be configured with
Hostname:    ipaserver.example.com
IP address:  192.168.1.1
Domain name: example.com
サーバー名は、英数字、ハイフン (-) のみで構成される、有効な DNS 名でなければなりません。ホスト名にアンダースコアなどの他の文字が含まれていると、DNS が正常に機能しなくなります。さらに、ホスト名がすべて小文字である必要があります。大文字は使用できません。
次に、「基本的な対話インストール」にあるように、スクリプトが実行され、IdM サービスごとに設定が進められます。

3.4. 例: 異なる CA 設定を使用したインストール

Identity Management では、統合された認証局 (CA) を使用して、ドメイン内のユーザーおよびホストが使用する証明書および Keytab を作成します。Identity Management Web UI の LDAP サーバーや Apache サーバーなどの内部ドメインサービスでも、サーバー間でセキュアな接続を確立するにはサーバー証明書が必要になります。
大抵の場合、Dogtag Certificate System CA は、IdM サーバーでインストールされます。この Dogtag Certificate System CA は CA 署名証明書 を使用して、IdM ドメイン内で作成されたすべてのサーバー証明書とユーザー証明書を作成して署名します。CA 証明書自体は、発行元の CA で署名する必要があります。発行元の CA を使用して、Dogtag Certificate System を CA 署名証明書に署名する方法は 2 つあります。
  • Dogtag Certificate System は、独自 の証明書に署名できます。つまり、Dogtag Certificate System インスタンスは ルート CA であることを意味します。ルート CA より上位の CA はないので、ルート CA cna で独自の証明書ポリシーを設定できます。
    これがデフォルト設定になります。
  • Dogtag Certificate System CA は、外部でホストされる CA (例: Verisign) で署名できます。この場合には、外部 CA がルート CA になり、設定された Dogtag Certificate System CA はルート CA の 下位 の証明局になります。つまり、IdM ドメイン内で発行された証明書は、有効期間などの属性に関してルート CA によって設定された制限が適用される可能性があります。
    外部 CA を参照する場合も、引き続き Dogtag Certificate System インスタンスを使用してすべての IdM ドメイン証明書証明書を発行します。唯一の相違点は、初期のドメイン CA 証明書が別の CA によって発行される点です。
他に、CA なしのインストールというオプションがあります。こちらのオプションでは、IdM ドメイン内で使用されているすべての証明書を手動で作成してアップロードし、更新する必要があります。インフラストラクチャー内の他の制限により、さらにメンテナンス負荷がかかる環境もありますが、通常、ほとんどのデプロイメントでは統合 Dogtag Certificate System インスタンス (および certmonger) を使用して IdM ドメイン証明書を管理します。
重要
CA 設定は、ドメインの作成後に変更したり、別の設定に移行したりできません。インストールプロセスの開始前に CA 要件を考慮する必要があります。

3.4.1. 内部ルート CA を使用したインストール

デフォルト設定では、独自のルート CA 証明書に署名する Dogtag Certificate System をインストールします。ipa-server-install コマンドの実行時に追加のパラメーターや設定手順は必要ありません。
[root@server ~]# ipa-server-install
... &< ...

The IPA Master Server will be configured with:
Hostname:      server.example.com
IP address:    10.1.1.1
Domain name:   example.com
Realm name:    EXAMPLE.COM

Continue to configure the system with these values? [no]: yes

The following operations may take some minutes to complete.
Please wait until the prompt is returned.

... &< ...

Configuring directory server for the CA (pkids): Estimated time 30 seconds
  [1/3]: creating directory server user
  [2/3]: creating directory server instance
  [3/3]: restarting directory server
Done configuring directory server for the CA (pkids).
Configuring certificate server (pki-cad): Estimated time 3 minutes 30 seconds
  [1/21]: creating certificate server user
...
Done configuring certificate server (pki-cad).

... &< ...

3.4.2. 外部 CA を使用したインストール

IdM サーバーは、外部 CA 発行の証明書を使用できます。この外部 CA は、企業 CA や、Verisign や Thawte などのサードパーティー CA を利用できます。通常の設定プロセスと同様に、外部 CA は引き続き IdM サーバーの Dogtag Certificate System インスタンスを使用して、クライアント証明書とレプリカ証明書をすべて発行し、初期 CA 証明書は単に別の CA により発行されるだけです。
外部 CA を使用する場合は、生成された証明書要求を外部 CA に送信し、CA 証明書を読み込み、サーバー証明書を発行する手順 2 つを追加で実行して設定を完了する必要があります。
重要
Identity Management サーバー用に生成された CA 署名証明書は、有効な CA 証明書である必要があります。これには、Basic Constraint オプションを CA=TRUE に設定するか、証明書に署名できるように、署名証明書に鍵用途エクステンションを設定する必要があります。
重要
CA 設定は、ドメインの作成後に変更したり、別の設定に移行したりできません。インストールプロセスの開始前に CA 要件を考慮する必要があります。

例3.2 外部 CA の使用

  1. --external-ca オプションを使用して ipa-server-install スクリプトを実行します。
    [root@server ~]# ipa-server-install -a secret12 -r EXAMPLE.COM -P password -p secret12 -n ipaserver.example.com --external-ca
  2. このスクリプトは、通常通りに NTP サービスおよび Directory Server サービスを設定し、
  3. CA の設定を完了して証明書署名要求 (CSR) が置かれている場所 (/root/ipa.csr) に関する情報を返します。この要求は外部 CA に送信する必要があります。
    Configuring certificate server: Estimated time 6 minutes
      [1/4]: creating certificate server user
      [2/4]: creating pki-ca instance
      [3/4]: restarting certificate server
      [4/4]: configuring certificate server instance
    The next step is to get /root/ipa.csr signed by your CA and re-run ipa-server-install.
  4. CA に要求を送信します。このプロセスは、サービスごとに異なります。
    証明書の適切な拡張を要求する必要がある場合があります。Identity Management サーバー用に生成された CA 署名証明書は、有効な CA 証明書である必要があります。これには、基本制約を CA=true に設定するか、証明書に署名できるように、署名証明書に鍵用途エクステンションを設定する必要があります。
  5. 発行した証明書と、発行元 CA の CA 証明書チェーンを取得します。プロセスは証明書サービスによって異なりますが、通常はWeb ページか通知メールにダウンロードリンクがあり、管理者は、必要な証明書すべてをダウンロードできます。CA 証明書のみではなく、CA 用の完全な証明書チェーンを取得してください。
  6. 証明書および CA チェーンファイルの場所と名前を指定して ipa-server-install をもう一度実行します。たとえば、以下のようになります。
    [root@server ~]# ipa-server-install --external_cert_file=/tmp/servercert20110601.p12 --external_ca_file=/tmp/cacert.p12
  7. 「基本的な対話インストール」にあるように、設定プロセスを完了し、すべてが想定通りに機能していることを確認します。

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

非常にまれなケースでは、Identity Management サーバーで証明書サービスをインストールすることができない場合があります。このような場合には、証明書を作成して、個別にインストールしている限り、統合された証明書システムインスタンスなしで Identity Management をインストールできます。
インストールには、3 つの証明書が必要です。
  • LDAP サーバー証明書
  • Apache サーバー証明書
  • LDAP サーバー証明書
この証明書は、インストールプロセスの開始 に、サードパーティーの認証局から要求する必要があります。
Dogtag Certificate System システムインスタンスが統合されていない場合に、証明書の管理方法には重要な制限事項があります。
  • 証明書の追跡に certmonger が使用されないので、有効期限の警告はありません。
  • Identity Management で証明書を更新する方法はありません。
  • 証明書管理ツール (ipa cert-*) は、証明書の表示や管理には使用できません。
  • ホスト証明書とサービス証明書はすべて、手動で要求、生成、アップロードする必要があります。これは、ipa host-add などのホスト管理ツールが機能する仕組みにも影響します。
  • 証明書がエントリーから削除されても、自動的に取り消されません。
重要
CA 設定は、ドメインの作成後に変更したり、別の設定に移行したりできません。インストールプロセスの開始前に CA 要件を考慮する必要があります。

例3.3 CA を使用しない Identity Management のインストール

CA を使用せずにインストールする場合には、必須オプションが 5 つあり、必要な証明書を設定プロセスに直接渡す必要があります。
  • LDAP サーバー証明書
    • --dirsrv_pkcs12 (LDAP サーバー証明書の PKCS#12 証明書ファイルを指定)
    • --dirsrv_pin (PKCS#12 ファイルにアクセスするパスワードを指定)
  • Apache サーバーの証明書
    • --http_pkcs12 (Apache サーバー証明書の PKCS#12 証明書ファイルを指定)
    • --http_pin (PKCS#12 ファイルにアクセスするパスワードを指定)
  • ルート CA 証明書 (Apache および LDAP サーバーの証明書をドメイン全体で信頼できるようにする)
[root@server ~]# ipa-server-install --http_pkcs12 /tmp-http-server.p12 --http_pin secret1 --dirsrv_pkcs12 /tmp/ldap-server.p12 --dirsrv_pin secret2 ...

3.5. 例: IdM ドメイン内での DNS サービスの設定

IdM は、独自の DNS を管理したり、既存の DNS (デフォルト) を使用したりするように設定できます。設定スクリプトを実行するだけでは DNS は設定されません。DNS の設定には --setup-dns オプションが必要です。
警告
DNS レコードは、稼働中の LDAP ディレクトリーサービス、Kerberos、Active Directory 統合など、ほぼすべての IdM ドメイン機能で必須となります。
IdM ドメインで IdM ホストの DNS サーバーを使用しない場合には、細心の注意を払い、テスト済みで、機能する DNS サービスを利用可能であることを確認します。A および PTR レコードを適切に設定していることが重要です。
基本設定と同様に、DNS 設定では、必要な情報の入力をプロンプトで求めるか、自動または無人セットアッププロセスを許可するスクリプトを使用して DNS 情報を指定できます。

3.5.1. DNS に関する注意事項

  • DNS 名の設定時にはワイルドカードを使用できません。明示的な DNS ドメイン名のみがサポートされます。
  • --setup-dns オプションを指定しても、rndc サービスは設定されません。このサービスは、IdM サーバーの設定後に手動で設定する必要があります。

3.5.2. 統合 DNS を使用したインストール

例3.4 対話型の DNS 設定

  1. --setup-dns オプションを使用して ipa-server-install スクリプトを実行します。
    [root@server ~]# ipa-server-install -a secret12 -r EXAMPLE.COM -P password -p secret12 -n ipaserver.example.com --setup-dns
  2. スクリプトを使用すると通常通りにホスト名およびドメイン名を設定します。
  3. 次にスクリプトにより、DNS フォワーダー設定のプロンプトが表示されます。フォワーダーを使用する場合は、yes と入力して DNS サーバーの一覧を指定します。IdM で独自の DNS サービスを管理する場合は、no と入力します。
    Do you want to configure DNS forwarders? [yes]: no
    No DNS forwarders configured
  4. このスクリプトは、NTP、Directory Server、Certificate System、Kerberos、および Apache のサービスを設定します。
  5. 設定の完了前に、逆引き DNS サービスを設定するかどうかをスクリプトによりプロンプトが表示されます。yes を選択した場合は、named サービスが設定されます。
    Do you want to configure the reverse zone? [yes]: yes
    Configuring DNS (named) 
    [1/11]: adding DNS container 
    [2/11]: setting up our zone 
    [3/11]: setting up reverse zone 
    [4/11]: setting up our own record 
    [5/11]: setting up records for other masters 
    [6/11]: setting up CA record 
    [7/11]: setting up kerberos principal 
    [8/11]: setting up named.conf 
    [9/11]: restarting named 
    [10/11]: configuring named to start on boot 
    [11/11]: changing resolv.conf to point to ourselves 
    Done configuring DNS (named). 
    ==============================================================================
    Setup complete
  6. ipa-dns-install コマンド (--setup-dns オプションの指定時にインストールスクリプトで実行) では、システムの rndc サービスは自動的に設定されません。このサービスは、DNS を IdM に設定した後に手動で設定する必要があります。
    1. rndc 設定ファイルとキーを作成します。
      [root@server ~]# /usr/sbin/rndc-confgen -a
      [root@server ~]# /sbin/restorecon /etc/rndc.key
      これには、キーの作成時にユーザーが入力してエントロピーを作成する必要がある場合があります。
    2. rndc キーファイルの所有者と権限を変更します。
      [root@server ~]# chown root:named /etc/rndc.key
      [root@server ~]# chmod 0640 /etc/rndc.key
  7. 「基本的な対話インストール」にあるように、すべてが想定通りに機能していることを確認します。
DNS を IdM で使用する場合は、使用する DNS フォワーダーの情報、逆引き DNS を使用するかどうかの情報の 2 つが必要になります。非対話的なセットアップを実行する場合は、--forwarder または --no-forwarders オプションおよび --no-reverse オプションを使用してこの情報を渡すことができます。

例3.5 非対話的な DNS の設定

IdM サーバーに DNS サーバーとドメインを設定するには、--setup-dns オプションを使用します。追加のフォワーダーを設定するには、--forwarder オプションを使用します。複数のフォワーダーを指定する場合には、複数の --forwarder の呼び出しを使用します。
[root@server ~]# ipa-server-install ... --setup-dns --forwarder=1.2.3.0 --forwarder=1.2.255.0
一部のフォワーダー情報が必要です。IdM DNS サービスで外部フォワーダーを使用しない場合は、この --no-forwarders オプションを使用してルートサーバーのみを使用することを指定します。
このスクリプトでは、逆引き DNS は DNS があることを前提に設定されているので、逆引きDNSを 有効化 するオプションを使用する必要はありません。逆引き DNS を無効にするには、--no-reverse オプションを使用します。逆引き DNS ゾーンがすでに設定されている場合は、この --no-reverse オプションを使用すると既存の逆引き DNS ゾーンが使用されます。
[root@server ~]# ipa-server-install ... --setup-dns --no-reverse
ipa-dns-install コマンド (--setup-dns オプションの指定時にインストールスクリプトで実行) では、システムの rndc サービスは自動的に設定されません。このサービスは、DNS を IdM に設定した後に手動で設定する必要があります。
  1. rndc 設定ファイルとキーを作成します。
    [root@server ~]# /usr/sbin/rndc-confgen -a
    [root@server ~]# /sbin/restorecon /etc/rndc.key
    これには、キーの作成時にユーザーが入力してエントロピーを作成する必要がある場合があります。
  2. rndc キーファイルの所有者と権限を変更します。
    [root@server ~]# chown root:named /etc/rndc.key
    [root@server ~]# chmod 0640 /etc/rndc.key

第4章 IdM レプリカの設定

レプリカは基本的には既存の Identity Management サーバーのクローンで、同一のコア設定を共有します。レプリカのインストールプロセスは主に、既存の必要なサーバー設定をコピーし、その情報に基づいてレプリカをインストールするという 2 つの部分で構成されます。

4.1. サーバー/レプリカトポロジーの計画

IdM ドメインには、以下の 3 種のマシンタイプがあります。
  • サーバー。ドメインの所属メンバーが使用する全サービスを管理します。
  • レプリカ。レプリカは基本的にはサーバーの複製です (一旦複製されるとサーバーと全く同じです)。
  • クライアント。サーバーに設定した Kerberos ドメインに属し、サーバーが発行する証明書およびチケットを受け取り、その他の一元管理サービスを使用して認証および認可を行います。
レプリカは、特定の IdM サーバーのクローンです。サーバーとレプリカは、ユーザー、マシン、証明書、および設定されたポリシーの内部情報が同じです。これらのデータは、レプリケーション と呼ばれるプロセスで、サーバーからレプリカにコピーされます。IdM サーバーが使用する 2 つの Directory Server インスタンス (IdM サーバーが使用する Directory Server インスタンスと、証明書情報を保存する Dogtag Certificate System が使用する Directory Server インスタンス) は、IdM レプリカにより使用される対応のコンシューマー Directory Server インスタンスに複製されます。異なる Directory Server インスタンスは、レプリカ合意 を使用して相互を認識します。初期レプリカ合意は、レプリカの作成時にマスターサーバーとレプリカとの間で作成されます。他のサーバーまたはレプリカに追加で合意を作成するには、ipa-replica-manage コマンドを使用します。

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

サーバーとレプリカの合意
レプリカは、 インストール後はサーバーと機能的に同じになります。
マルチマスターレプリケーションには、ガイドラインがあり、サーバー/レプリカトポロジー全体に制限を指定します。
  • 1 つのサーバー/レプリカには、4 つ以上のレプリカ合意を設定できません。
  • 1 つの Identity Management ドメインには 20 台以上のサーバーとレプリカを使用すべきではありません。
  • すべてのサーバー/レプリカには、別のサーバーに障害が発生した場合に、孤立したサーバーまたはレプリカがないようにするため、最低でも 2 つのレプリカ合意が必要です。
最も耐障害性のあるトポロジーの 1 つとして、サーバー/レプリカのセル設定の作成が挙げられます。この設定では、少数のサーバーがセルにあり、すべてのサーバーには相互にサーバー合意が指定されており (厳密なセル)、そのセルの では、サーバーごとに別のサーバーとレプリカ合意が指定されていて、そのセルと、ドメイン全体にある他のすべてのセルとを疎結合します。

図4.2 トポロジーの例

トポロジーの例
これを簡単に実現するための推奨の方法がいくつかあります。
  • 各メインオフィス、データセンター、地域に、少なくとも 1 つの IdM サーバーを用意します。可能であれは、2 台の IdM サーバーを用意します。
  • 各データセンターに用意するサーバーは 4 台までとします。
  • サーバーやレプリカを使用する代わりに、小規模なオフィスでは、SSSD を使用して認証情報をキャッシュし、データのバックエンドとして、オフサイトの IdM サーバーを使用します。

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

レプリカは、IdM サーバーと機能的に同じであるため、インストール要件、インストールパッケージは同じです。ただし、レプリカも既存サーバーの 複製 であるため、元のサーバー設定をミラーリングする必要があります。
  • そのマシンが「2章インストールの前提条件」に記載の前提条件すべてを満たすようにしてください。
  • レプリカとマスターサーバーは、同じバージョンの IdM を実行している必要があります。
    レプリカは基本的に、既存のサーバー設定を基にしたサーバーの複製です。そのため、サーバーとレプリカ (サーバーの複製) は、設定をサーバーからレプリカに適切にコピーできるように、同じバージョンの Identity Management を実行している必要があります。
    マスターサーバーが Red Hat Enterprise Linux 6 で IdM バージョン 3.0 を稼働している場合は、レプリカも Red Hat Enterprise Linux 6 で稼働し、IdM 3.0 パッケージを使用する必要があります。
    重要
    マスターと違うバージョンを使用するレプリカの作成は サポート対象外です。389 Directory Server インスタンスの設定時に、別のバージョンを使用するレプリカを作成しようとすると失敗します。
  • レプリカをインストールするには、レプリカの設定プロセス時に 表2.1「IdM ポート」に記載されているポートに加え、ポート 22 も解放する必要があります。このポートは、マスターサーバーへの接続に SSH を使用するのに必要です。
    既存の Dogtag Certificate System または Red Hat Certificate System インスタンスがレプリカマシンに存在する場合には、レプリカの設定中および設定後に ポート 7389 を解放しておく必要があります。このポートは、マスター IdM サーバーがレプリカと通信するのに使用されます。
    注記
    ipa-replica-install スクリプトには、必要なポートのステータスを検証する ipa-replica-conncheck ユーティリティーが含まれます。トラブルシューティングの目的で、ipa-replica-conncheck を個別に実行することもできます。ユーティリティーの使用方法は、ipa-replica-conncheck(1) の man ページを参照してください。
  • レプリカはサーバーと同じ CA 設定を使用し、同じルート CA を指定する必要があります。たとえば、サーバーが (Dogtag Certificate System を使用した) 独自のルート CA である場合には、このサーバーはレプリカのルート CA である必要があります。サーバーが外部 CA を使用して証明書を発行した場合には、レプリカでも同じ外部 CA を使用する必要があります。

4.3. レプリカパッケージのインストール

レプリカは (既存サーバーの設定に基づく) IdM サーバーであるため、IdM サーバーパッケージ (ipa-server) からインストールされます。レプリカが DNS サービスもホストする場合は、bind および bind-dyndb-ldap パッケージを含めます。
[root@server ~]# yum install ipa-server bind bind-dyndb-ldap
重要
ipa-server-install スクリプトを 実行しないでください

4.4. レプリカの作成

  1. マスターサーバーで、レプリカ情報ファイル を作成します。このファイルには、マスターサーバーから取得したレルムや設定情報が含まれており、情報はレプリカサーバーの設定に使用します。
    マスター IdM サーバーipa-replica-prepare ユーティリティーを実行します。このユーティリティーには、レプリカ マシンの完全修飾ドメイン名が必要です。
    --ip-address オプションを使用すると、DNS へのレプリカの A および PTR レコードなど、レプリカの DNS エントリーが自動的に作成されます。
    重要
    IdM サーバーが統合 DNS で設定されている場合にのみ --ip-address オプションを渡します。これ以外の場合にこのオプションを渡すと、更新する DNS レコードが存在しないため、DNS レコード操作が失敗して、レプリカ作成も失敗することになります。
    注記
    レプリカの IP アドレスに他のサーバーが到達できないと、ipa-replica-prepare スクリプトは、その IP アドレスの確認や検証を実行しないことに注意してください。
    [root@server ~]# ipa-replica-prepare ipareplica.example.com --ip-address 192.168.1.2 
    
    Directory Manager (existing master) password: 
    Preparing replica for ipareplica.example.com from ipaserver.example.com 
    Creating SSL certificate for the Directory Server 
    Creating SSL certificate for the dogtag Directory Server 
    Saving dogtag Directory Server port 
    Creating SSL certificate for the Web Server 
    Exporting RA certificate 
    Copying additional files 
    Finalizing configuration 
    Packaging replica information into /var/lib/ipa/replica-info-ipareplica.example.com.gpg 
    Adding DNS records for ipareplica.example.com 
    Using reverse zone 1.168.192.in-addr.arpa. 
    The ipa-replica-prepare command was successful
    これは、数字、アルファベット文字、およびハイフン (-) のみが使用された有効な DNS 名でなければなりません。ホスト名にアンダースコアなどの他の文字が含まれていると、DNS が正常に機能しなくなります。さらに、ホスト名がすべて小文字である必要があります。大文字は使用できません。
    各レプリカ情報ファイルは、GPG 暗号化ファイルとして /var/lib/ipa/ ディレクトリーに作成されます。各ファイルには、replica-info-ipareplica.example.com.gpg など、レプリカサーバー向けの名前が付けられます。
    注記
    レプリカ情報ファイルを使用して、複数のレプリカを作成できません。このファイルを使用できるのは、対象として作成された特定のレプリカとマシンだけです。
    警告
    レプリカ情報ファイルには機密情報が含まれています。適切な措置を講じてこの情報を保護してください。
    ipa-replica-prepare の他のオプションは、ipa-replica-prepare(1) の man ページを参照してください。
  2. レプリカ情報ファイルは、レプリカサーバーにコピーします。
    [root@server ~]# scp /var/lib/ipa/replica-info-ipareplica.example.com.gpg root@ipaserver:/var/lib/ipa/
  3. レプリカサーバーで、レプリカのインストールスクリプトを実行し、このレプリカ情報ファイルを参照します。サーバーのインストールスクリプトのように、DNS を設定する方法は他にもあります。さらに、レプリカの CA を設定するオプションがあります。CA はサーバー用にデフォルトでインストールされますが、レプリカでは任意です。
    DNS フォワーダーの情報が必要です。フォワーダーごとに --forwarder オプションを使用して、設定した DNS フォワーダーの一覧を指定するか、--no-forwarders オプションを指定してフォワーダーの設定をスキップできます。
    たとえば、以下のようになります。
    [root@ipareplica ~]# ipa-replica-install --setup-ca --setup-dns --no-forwarders /var/lib/ipa/replica-info-ipareplica.example.com.gpg
    
    Directory Manager (existing master) password:
    
    Warning: Hostname (ipareplica.example.com) not found in DNS
    Run connection check to master
    Check connection from replica to remote master 'ipareplica. example.com':
       Directory Service: Unsecure port (389): OK
       Directory Service: Secure port (636): OK
       Kerberos KDC: TCP (88): OK
       Kerberos Kpasswd: TCP (464): OK
       HTTP Server: Unsecure port (80): OK
       HTTP Server: Secure port (443): OK
    
    The following list of ports use UDP protocol and would need to be
    checked manually:
       Kerberos KDC: UDP (88): SKIPPED
       Kerberos Kpasswd: UDP (464): SKIPPED
    
    Connection from replica to master is OK.
    Start listening on required ports for remote master check
    Get credentials to log in to remote master
    admin@EXAMPLE.COM password:
    
    Execute check on remote master
    admin@example.com's password:
    Check connection from master to remote replica 'ipareplica. example.com':
       Directory Service: Unsecure port (389): OK
       Directory Service: Secure port (636): OK
       Kerberos KDC: TCP (88): OK
       Kerberos KDC: UDP (88): OK
       Kerberos Kpasswd: TCP (464): OK
       Kerberos Kpasswd: UDP (464): OK
       HTTP Server: Unsecure port (80): OK
       HTTP Server: Secure port (443): OK
    
    Connection from master to replica is OK.
    
    Connection check OK
    レプリカのインストールスクリプトは、テストを実行し、インストールされているレプリカファイルが現在のホスト名と一致することを確認します。一致しない場合には、このスクリプトで警告メッセージが表示され、確認するように求められます。これは、ホスト名が一致しなくても問題とならないマルチホームマシンで発生する可能性があります。
    レプリカのインストールスクリプトの他のオプションについては、ipa-replica-install(1) man ページに一覧表示されます。
    注記
    ipa-replica-install で使用できるオプションの 1 つに --ip-address オプションがあります。ipa-replica-install に追加すると、このオプションは、ローカルインターフェースに関連付けられた IP アドレスだけを許可します。
  4. プロンプトが表示されたら、Directory Manager のパスワードを入力します。次に、スクリプトはレプリカ情報ファイルの情報に基づいて Directory Server インスタンスを設定し、複製プロセスを開始し、マスターサーバーからレプリカにデータをコピーします。このプロセスは、初期化 と呼ばれます。
  5. IdM クライアントが新しいサーバーを検出できるように、適切な DNS エントリーが作成されていることを確認します。必須のドメインサービスには、DNS エントリーが必要です。
    • _ldap._tcp
    • _kerberos._tcp
    • _kerberos._udp
    • _kerberos-master._tcp
    • _kerberos-master._udp
    • _ntp._udp
    DNS が有効な状態で最初のサーバーを作成した場合には、適切な DNS エントリーでレプリカが作成されます。以下に例を示します。
    [root@ipareplica ~]# DOMAIN=example.com
    [root@ipareplica ~]# NAMESERVER=ipareplica
    [root@ipareplica ~]# for i in _ldap._tcp _kerberos._tcp _kerberos._udp _kerberos-master._tcp _kerberos-master._udp _ntp._udp; do echo ""; dig @${NAMESERVER} ${i}.${DOMAIN} srv +nocmd +noquestion +nocomments +nostats +noaa +noadditional +noauthority; done | egrep -v "^;" | egrep _
    
    _ldap._tcp.example.com. 86400   IN      SRV     0 100 389 ipaserver1.example.com.
    _ldap._tcp.example.com. 86400   IN      SRV     0 100 389 ipaserver2.example.com.
    _kerberos._tcp.example.com. 86400 IN    SRV     0 100 88  ipaserver1.example.com.
    ...8<...
    DNS を有効にせずに最初の IdM サーバーを作成した場合には、サービスの TCP および UDP エントリー両方など、各 DNS エントリーは手作業で追加してください。以下に例を示します。
    [root@ipareplica ~]# kinit admin
    [root@ipareplica ~]# ipa dnsrecord-add example.com _ldap._tcp --srv-rec="0 100 389 ipareplica.example.com."
  6. 任意。レプリカの DNS サービスを設定します。マスターサーバーが DNS を使用している場合でも、レプリカの DNS サービスは、設定スクリプトでは設定されません。
    ipa-dns-install コマンドを使用して手動で DNS をインストールし、ipa dnsrecord-add コマンドで必要な DNS レコードを追加します。たとえば、以下のようになります。
    [root@ipareplica ~]# ipa-dns-install
    
    [root@ipareplica ~]# ipa dnsrecord-add example.com @ --ns-rec ipareplica.example.com.
    重要
    最後のピリオド (.) を含めてレプリカの完全修飾ドメイン名を使用します。このピリオドを含めない場合には、BIND はホスト名をドメインの相対値として扱います。

4.5. 他のレプリカ作成オプション

レプリカのコア設定の多くは、レルム名やディレクトリー設定など、作成元のサーバー設定と同じです。ただし、設定は同じでなければなりませんが、レプリカでサーバーと同じサービスを管理する必要はありません。これは、主要なサービス (DNS および CA) およびマイナーサービス (NTP および OpenSSH) が該当します。
異なる設定は、ipa-replica-prepare コマンドまたは ipa-replica-install コマンドで定義できます。

4.5.1. 各種 DNS 設定

DNS は、ipa-replica-prepare コマンドを使用して、レプリカ固有の DNS 設定 (IP アドレスと逆引きゾーン) を設定できます。たとえば、以下のようになります。
[root@server ~]# ipa-replica-prepare ipareplica.example.com --ip-address=192.68.0.0 --no-reverse
サーバーでどの DNS サービスもホストしない場合には、レプリカを設定して、Identity Management ドメインの DNS サービスをホストすることができます。サーバーをインストールする場合と同様に、--setup-dns オプションを使用して、正引きゾーンと逆引きゾーンを設定します。たとえば、フォワーダーなしで、既存の逆引きゾーンを使用して、レプリカの DNS サービスを設定するには以下を行います。
[root@server ~]# ipa-replica-install  ipareplica.example.com --setup-dns --no-forwarders --no-reverse --no-host-dns ...
DNS オプションは ipa-replica-prepare および ipa-replica-install の man ページで説明されています。

4.5.2. 各種 CA 設定

レプリカの CA 設定は、サーバーの CA 設定をコピーする必要があります。サーバーが統合 Dogtag Certificate System インスタンスで設定されている場合には (ルート CA か、外部 CA の下位にある認証局であるかに拘らず)、レプリカではサーバー CA に従属する独自の統合 CA を作成するか、または CA を全く指定せずに、すべての要求をサーバーの CA に転送できます。
レプリカに独自の CA がある場合は、この --setup-ca オプションを使用します。残りの設定は、サーバーの設定から取得します。
[root@ipareplica ~]# ipa-replica-install ipareplica.example.com --setup-ca ...
ただし、サーバーが CA なしでインストールされている場合は、新規レプリカインスタンスの証明書を要求する機能など、証明書の操作の転送先がありません。サーバーと同様に、レプリカのインストール前に、レプリカの全証明書の要求および取得を行ってから、証明書をインストールコマンドで送信します。唯一の例外はルート CA 証明書で、これはレプリカ設定の一部としてサーバーから取得します。
[root@ipareplica ~]# ipa-replica-install ipareplica.example.com --dirsrv_pkcs12=/tmp/dirsrv-cert.p12 --dirsrv_pin=secret1 --http_pkcs12=/tmp/http-cert.p12 --http_pin=secret2 ...

4.5.3. さまざまなサービス

デフォルトでサーバーおよりレプリカ両方にインストールされるサポート対象のサービスが 3 つあります (NTP、OpenSS クライアントおよび OpenSSH サーバー)。これらすべてまたは一部をレプリカで無効にすることができます。以下に例を示します。
[root@server ~]# ipa-replica-install ... --no-ntp --no-ssh --no-sshd ...

第5章 IdM クライアントとしてのシステムの設定

クライアント は、Identity Management ドメインに所属するシステムです。多くの場合、クライアントには Red Hat Enterprise Linux システム (IdM には Red Hat Enterprise Linux クライアントを非常にシンプルに設定する特別なツールがあります) を使用しますが、他のオペレーティングシステムを使用するマシンも IdM ドメインに追加できます。
IdM クライアントの重要な仕組みの 1 つとして、システムがドメインの一部であるかどうかを判断できるのは、システム設定 のみ である点が挙げられます。(この設定には Kerberos ドメイン、DNS ドメインに所属する設定や、適切な認証および証明書の設定が含まれます。)
注記
IdM では、クライアントがドメインに参加するために、クライアント上でエージェントやデーモンを実行する必要はありません。ただし、最適な管理オプション、セキュリティー、およびパフォーマンスを実現するには、クライアントで System Security Services Daemon (SSSD) を実行する必要があります。
SSSD の詳細は、SSSD プロジェクトページ にある 『デプロイメントガイド』の「SSSD」の章 を参照してください。
この章では、IdM ドメインに参加するようにシステムを設定する方法を説明します。
注記
クライアントは、少なくとも 1 つの IdM サーバーがインストールされていないと設定できません。

5.1. クライアント設定

Red Hat Enterprise Linux システムでのクライアントの設定がクライアント設定スクリプトを使用する場合でも、手動で行った場合でも、マシンを IdM クライアントに指定する一般的な設定プロセスはほぼ同じですが、プラットフォームにより若干の違いがあります。
  • IdM CA の CA 証明書を取得します。
  • 別の Kerberos 設定を作成して、指定した認証情報をテストします。
    この設定により、IdM クライアントを IdM ドメインに参加させるのに必要な IdM XML-RPC サーバーへの Kerberos 接続が可能になります。この Kerberos 設定は最終的に破棄されます。
    Kerberos 設定では、レルムおよびドメイン情報、デフォルトのチケット属性を指定します。デフォルトでは、オペレーティングシステムから管理インターフェースへの接続を容易に行い、管理操作の監査ができるように転送可能なチケットが設定されています。たとえば、Red Hat Enterprise Linux システムの Kerberos 設定は以下のようになります。
    [libdefaults]
    default_realm = EXAMPLE.COM
    dns_lookup_realm = false
    dns_lookup_kdc = false
    rdns = false
    forwardable = yes
    ticket_lifetime = 24h
    
    [realms]
    EXAMPLE.COM = {
          kdc = server.example.com:88
          admin_server = server.example.com:749
          }
    [domain_realm]
    .example.com = EXAMPLE.COM
    example.com = EXAMPLE.COM
    
  • ipa-join コマンドを実行し、実際の参加させます。
  • ホストサービスのサービスプリンシパルを取得して、/etc/krb5.keytab にインストールします。例: host/ipa.example.com@EXAMPLE.COM
  • certmonger を有効にし、SSL サーバー証明書を取得し、/etc/pki/nssdb に証明書をインストールします。
  • nscd デーモンを無効にします。
  • NSS および PAM 設定ファイルなど、SSSD または LDAP/KRB5 を設定します。
  • OpenSSH サーバーおよびクライアントを設定し、ホストが DNS SSHFP レコードを作成できるようにします。
  • NTP の設定

5.2. システムポート

IdM はサービスとの通信に多くのポートを使用します。IdM クライアントには、IdM サーバーと同じポート (ポート 7389 以外) が必要です。通常のデプロイメントでは大抵の場合、ポート 7389 を開放して利用可能な状態にする必要はありません。
IdM で必要なポートの一覧とそのポートを利用できる状態にする方法については、「システムポート」を参照してください。

5.3. IdM クライアントとしての Linux システムの設定

Red Hat Enterprise Linux クライアントのクライアント設定プロセスを開始する前に、準備する要素が 2 つあります。
  • Kerberos ID (管理ユーザー) を利用できるようにするか、クライアントマシンの登録プロセスを開始する前に、ワンタイムパスワードを使用してクライアントマシンをサーバーのクライアントマシンに手動で追加し、クライアントマシンを Kerberos ドメインに接続する手段を設定する必要があります。
  • DNS レコードにサービスを提供するネットワーク上に Active Directory サーバーがある場合には、Active Directory の DNS レコードが原因で、クライアントによる IdM サーバーアドレスの自動検出ができなくなる可能性があります。ipa-client-install スクリプトでは、IdM に追加されたレコードの代わりに Active Directory の DNS レコードを取得します。
    この場合は、IdM サーバーアドレスを ipa-client-install スクリプトに直接指定する必要があります。

5.3.1. クライアントのインストール (完全な例)

  1. クライアントパッケージをインストールします。このパッケージは、システムをクライアントとして簡単に設定でき、SSSD のインストールや設定も行います。
    通常のユーザーシステムの場合には、ipa-client パッケージのみが必要です。
    [root@client ~]# yum install ipa-client
    管理者マシンには、ipa-admintools パッケージも必要です。
    [root@client ~]# yum install ipa-client ipa-admintools
  2. IdM サーバーを DNS サーバーとして設定し、クライアントと同じドメインに配置した場合には、クライアントの /etc/resolv.conf ファイルにあるネームサーバー一覧の最初のエントリーとして、サーバーの IP アドレスを追加します。
    ヒント
    ドメイン内のマシンがすべて IdM クライアントである場合は、IdM サーバーのアドレスを DHCP 設定に追加します。
  3. クライアントの設定コマンドを実行します。
    [root@client ~]# ipa-client-install --enable-dns-updates
    --enable-dns-updates オプションを使用すると、クライアントマシンの IP アドレスに DNS が更新されます。このオプションは、IdM サーバーが統合 DNS でインストールされている場合か、ネットワーク上の DNS サーバーで GSS-TSIG プロトコルを使用して DNS エントリーを更新できる場合にのみ、使用するようにしてください。
    ipa-client-install のオプションは、ipa-client-install の man ページに一覧表示されています。
  4. プロンプトが表示されたら、IdM DNS ドメインのドメイン名を入力します。
    DNS discovery failed to determine your DNS domain
    Please provide the domain name of your IPA server (ex: example.com): example.com
  5. プロンプトが表示されたら、IdM サーバーの完全修飾ドメイン名を入力します。または、クライアントのインストールスクリプトに --server オプションを使用して、IdM サーバーの完全修飾ドメイン名を指定します。
    DNS discovery failed to find the IPA Server
    Please provide your IPA server name (ex: ipa.example.com): server.example.com
    重要
    これは、数字、アルファベット文字、およびハイフン (-) のみが使用された有効な DNS 名でなければなりません。ホスト名にアンダースコアなどの他の文字が含まれていると、DNS が正常に機能しなくなります。
  6. 次にクライアントのスクリプトは、Kerberos ID を入力するようにプロンプトを表示し、その ID を使用して問い合わせを行い、Kerberos レルムに参加します。これらの認証情報を指定すると、クライアントは IdM Kerberos ドメインに参加して設定を完了できます。
    Continue to configure the system with these values? [no]: y 
    User authorized to enroll computers: admin 
    Synchronizing time with KDC... 
    Password for admin@EXAMPLE.COM: 
    Successfully retrieved CA cert 
    Subject: CN=Certificate Authority,O=EXAMPLE.COM 
    Issuer: CN=Certificate Authority,O=EXAMPLE.COM 
    Valid From: Tue Aug 13 09:29:07 2013 UTC 
    Valid Until: Sat Aug 13 09:29:07 2033 UTC 
    Enrolled in IPA realm EXAMPLE.COM 
    Created /etc/ipa/default.conf 
    New SSSD config will be created 
    Configured /etc/sssd/sssd.conf 
    Configured /etc/krb5.conf for IPA realm EXAMPLE.COM 
    Failed to update DNS records. 
    Adding SSH public key from /etc/ssh/ssh_host_rsa_key.pub 
    Adding SSH public key from /etc/ssh/ssh_host_dsa_key.pub 
    Could not update DNS SSHFP records. 
    SSSD enabled 
    Configured /etc/openldap/ldap.conf 
    NTP enabled 
    Configured /etc/ssh/ssh_config 
    Configured /etc/ssh/sshd_config 
    Client configuration complete.
  7. クライアントが IdM ドメインに正常に接続でき、基本的なタスクを実行できることをテストします。たとえば、IdM ツールを使用して、ユーザーおよびグループ情報を取得できることを確認します。
    [jsmith@client ~]$ id
    [jsmith@client ~]$ getent passwd admin
    [jsmith@client ~]$ getent group admins
  8. NFS サーバーがすでに設定されている場合は、クライアントシステムに NFS を設定して Kerberos と連携させます。
    NFS サーバーは、ドメイン内に設定しておく必要があります。詳細は、「自動マウントの設定」を参照してください。
    ヒント
    NFS の設定時に発生する可能性のあるエラーをトラブルシューティングできるように、/etc/sysconfig/nfs ファイルでデバッグ情報を有効にします。
    RPCGSSDARGS="-vvv"
    RPCSVCGSSDARGS="-vvv"
    1. IdM サーバーで、NFS クライアントの NFS サービスプリンシパルを追加します。
      [root@client ~]# kinit admin
      [root@client ~]# ipa service-add nfs/ipaclient.example.com@EXAMPLE
      注記
      これは、ipa コマンドを使用できるように、ipa-admintools パッケージがインストールされているマシンから実行する必要があります。
    2. IdM サーバーで、NFS サービスプリンシパルの keytab を取得します。
      [root@client ~]# ipa-getkeytab -s server.example.com -p nfs/ipaclient.example.com@EXAMPLE -k /tmp/krb5.keytab
    3. IdM サーバーから IdM クライアントに keytab をコピーします。たとえば、以下のようになります。
      [root@client ~]# scp /tmp/krb5.keytab root@client.example.com:/etc/krb5.keytab
    4. NFS サーバーで /etc/exports ファイルを設定します。
      /ipashare       gss/krb5p(rw,no_root_squash,subtree_check,fsid=0)
    5. マウントポイントを作成します。
      [root@client ~]# mkdir /mnt/ipashare
    6. クライアントで NFS 共有をマウントします。-o sec 設定は、NFS サーバーの /etc/exports ファイルで使用する設定と同じものを使用します。
      [root@client ~]# mount -v -t nfs4 -o sec=krb5p nfs.example.com:/ /mnt/ipashare

5.3.2. その他のクライアントインストールオプションの例

ipa-client-install コマンドには、インフラストラクチャーの要件に応じて、さまざまな方法でのクライアントシステムの設定に使用できる設定オプションが複数あります。

例5.1 DNS 更新の有効化

DHCP 設定によっては、クライアントの IP アドレスは、一定の規則をもとに変更できす。IP アドレスを変更すると、IdM サーバーの DNS レコードと、実際に使用中の IP アドレスとの間に差異が発生して、IdM 内で設定されたポリシーやクライアントとサービス間の通信に影響が及ぶ可能性があります。
--enable-dns-updates オプションでは、クライアントの IP アドレスが変更されるたびに DNS エントリーを更新する System Security Services Daemon (SSSD) を設定します。
[root@client ~]# ipa-client-install --enable-dns-updates

例5.2 ドメイン情報の指定

クライアントインストールコマンドだけを実行すると、スクリプトで、登録する IdM サーバーの名前、DNS ドメイン名、Kerberos レルムおよびプリンシパルなど、必要な IdM ドメイン名が求められます。
上記の基本情報はすべて、インストールコマンドで指定できます (このインストールコマンドは自動インストールに便利です)。
  • --domain: DNS ドメイン名 (DNS サービスをホストするように IdM サーバーが設定されている場合のみ)
  • --server: 登録する IdM サーバー (トポロジー内の任意のサーバーまたはレプリカ)
    これは、数字、アルファベット文字、およびハイフン (-) のみが使用された有効な DNS 名でなければなりません。ホスト名にアンダースコアなどの他の文字が含まれていると、DNS が正常に機能しなくなります。
  • --realm: Kerbero レルム名。オプションで Kerberos プリンシパル名には -p を使用します。
[root@client ~]# ipa-client-install --domain EXAMPLE.COM --server server.example.com --realm EXAMPLE -p host/server.example.com

例5.3 特定の IdM サーバーの設定

IdM サーバートポロジーには、複数のサーバーおよびレプリカが存在する可能性があります。更新やユーザー情報の取得に、クライアントがサーバーに接続する必要がある場合には、(デフォルトでは) サービスを使用してドメイン内をスキャンして利用可能なサーバーとレプリカを検出します。つまり、検出スキャンの結果に応じて、クライアントが実際に接続する先のサーバーは無作為に決定されることになります。
クライアント更新に使用する IdM ドメイン内に、特定のサーバーを設定できます。何らかの理由で、そのサーバーへの接続に失敗した場合には、クライアントはドメイン内の別のサーバーを検出してフェイルオーバーできます。
優先サーバーは、--fixed-primary オプションで設定します。
[root@client ~]# ipa-client-install --fixed-primary server.example.com

例5.4 システム認証ツールの無効化

Red Hat Enterprise Linux は、authconfig ツールを使用してローカルシステムの認証クライアントおよびオプションを設定して更新します。Identity Management は System Security Services Daemon (SSSD) を使用して IdM サーバー設定を保存し、IdM ドメイン内で設定したポリシー情報、ユーザー、パスワード、およびグループを取得します。
authconfig および SSSD を使用してユーザー、グループなどの IdM クライアント設定を管理することを強く推奨します。
管理者がシステム認証設定の動的な変更を無効にする状況があります。このような場合は、IdM が authconfig または SSSD を更新しないように無効にできます。
--noac オプションは、authconfig での変更を防ぎます。--no-sssd オプションでは、IdM が SSSD を使用できないようにします。
[root@client ~]# ipa-client-install --noac --no-sssd
関連のオプションとして --preserve-sssd があります。このオプションでは、クライアントが SSSD 設定ファイルを変更して IdM ドメインを設定できますが、以前の SSSD 設定を保存します。

例5.5 パスワードキャッシングの無効化

SSSD の主な機能の 1 つとして パスワードキャッシュがあります。通常、システムが外部のパスワードストアを使用する場合は、そのパスワードストアにアクセスできなくなると認証に失敗します。ただし、SSSD では認証の試行に成功するとパスワードをキャッシュし、そのパスワードをローカルに保存することができます。これにより、IdM サーバーにアクセスできなくても、ユーザーはドメインサービス (以前はアクセスしたサービス) にログインしてアクセスできるようになります。
セキュリティーレベルの高い環境では、不正アクセスされないように、パスワードのキャッシュを防止する必要がある場合があります。このような場合には、--no-krb5-offline-passwords オプションを使用して、パスワードが SSSD でキャッシュできないようにします。
[root@client ~]# ipa-client-install --no-krb5-offline-passwords

5.4. Linux クライアントの手動設定

ipa-client-install コマンドは、Kerberos、SSSD、PAM、NSS などのサービスを自動的に設定します。ただし、何らかの理由で ipa-client-install コマンドをシステムで使用できない場合は、IdM クライアントエントリーとサービスを手動で設定できます。

5.4.1. IdM クライアントの設定 (全手順)

  1. SSSD がインストールされていない場合はインストールしてください。
  2. 任意。ホストから管理タスクを実行できるように IdM ツールをインストールします。
    [root@client ~]# yum install ipa-admintools
  3. IdM サーバーで、クライアントのホストエントリーを作成します。
    [jsmith@client ~]$ kinit admin
    [jsmith@client ~]$ ipa host-add --force --ip-address=192.168.166.31 ipaclient.example.com
    ホストを手動で作成する方法は、「ホストエントリーを追加する他の例」を参照してください。
  4. IdM サーバーで、クライアントの Keytab を作成します。
    1. IdM 管理者としてログインします。
      [jsmith@client ~]$ kinit admin
    2. サーバーが管理するクライアントホストを設定します。
      [jsmith@client ~]$ ipa host-add-managedby --hosts=server.example.com ipaclient.example.com
    3. クライアントの keytab を生成します。
      [jsmith@client ~]$ ipa-getkeytab -s server.example.com -p host/ipaclient.example.com -k /tmp/ipaclient.keytab
  5. Keytab をクライアントマシンにコピーし、名前を /etc/krb5.keytab に変更します。
    ヒント
    既存の /etc/krb5.keytab を保存する必要がある場合には、ktutil を使用してこの 2 つのファイルを統合できます。
  6. /etc/krb5.keytab ファイルのユーザーパーミッションを正しく設定します。
    [root@client ~]# chown root:root /etc/krb5.keytab 
    [root@client ~]# chmod 0600 /etc/krb5.keytab
  7. /etc/krb5.keytab ファイルの SELinux コンテキストを設定します。
    [root@client ~]# chcon system_u:object_r:krb5_keytab_t:s0 /etc/krb5.keytab
  8. /etc/sssd/sssd.conf ファイルを編集して、SSSD が IdM ドメインを参照するように設定します。
    [root@client ~]# touch /etc/sssd/sssd.conf
    [root@client ~]# vim /etc/sssd/sssd.conf
    
    [sssd]
    config_file_version = 2
    services = nss, pam
    
    domains = example.com
    [nss]
    
    [pam]
    
    [domain/example.com]
    cache_credentials = True
    krb5_store_password_if_offline = True
    ipa_domain = example.com
    id_provider = ipa
    auth_provider = ipa
    access_provider = ipa
    ipa_hostname = ipaclient.example.com
    chpass_provider = ipa
    ipa_server = server.example.com
    ldap_tls_cacert = /etc/ipa/ca.crt
  9. パスワード、グループ、ユーザー、および netgroups に SSSD を使用するように NSS を設定します。
    [root@client ~]# vim /etc/nsswitch.conf
    
    ...
    passwd:     files sss
    shadow:     files sss
    group:      files sss
    ...
    netgroup:   files sss
    ...
  10. /etc/krb5.conf ファイルで、IdM KDC を参照するように設定します。
    [logging]
     default = FILE:/var/log/krb5libs.log
     kdc = FILE:/var/log/krb5kdc.log
     admin_server = FILE:/var/log/kadmind.log
    
    [libdefaults]
     default_realm = EXAMPLE.COM
     dns_lookup_realm = false
     dns_lookup_kdc = false
     rdns = false
     ticket_lifetime = 24h
     forwardable = yes
     allow_weak_crypto = true
    
    [realms]
     EXAMPLE.COM = {
      kdc = server.example.com:88
      admin_server = server.example.com:749
      default_domain = example.com
    }
    
    [domain_realm]
     .example.com = EXAMPLE.COM
     example.com = EXAMPLE.COM
  11. pam_sss.so モジュールを使用するように、/etc/pam.d 設定を更新します。
    • /etc/pam.d/fingerprint-auth の場合:
      ...
      account     [default=bad success=ok user_unknown=ignore] pam_sss.so
      ...
      session     optional      pam_sss.so
    • /etc/pam.d/system-auth の場合:
      ...
      auth        sufficient    pam_sss.so use_first_pass
      ...
      account     [default=bad success=ok user_unknown=ignore] pam_sss.so
      ...
      password    sufficient    pam_sss.so use_authtok
      ...
      session     optional      pam_sss.so
    • /etc/pam.d/password-auth の場合:
      ...
      auth        sufficient    pam_sss.so use_first_pass
      ...
      account     [default=bad success=ok user_unknown=ignore] pam_sss.so
      ...
      password    sufficient    pam_sss.so use_authtok
      ...
      session     optional      pam_sss.so
    • Enrollment_with_Separation_of_Duties /etc/pam.d/smartcard-auth の場合:
      ...
      account     [default=bad success=ok user_unknown=ignore] pam_sss.so
      ...
      session     optional      pam_sss.so
  12. IdM サーバーの CA 証明書をインストールします。
    1. サーバーから証明書を取得します。
      [root@ipaclient ~]# wget -O /etc/ipa/ca.crt http://ipa.example.com/ipa/config/ca.crt
    2. システムの NSS データベースに証明書をインストールします。
      [root@ipaclient ~]# certutil -A -d /etc/pki/nssdb -n "IPA CA" -t CT,C,C -a -i /etc/ipa/ca.crt
  13. IdM にホストのホスト証明書を設定します。
    1. certmonger が実行されていることを確認します。
      [root@ipaclient ~]# service certmonger start
      ヒント
      certmonger サービスがデフォルトで起動するように、chkconfig を設定します。
      [root@ipaclient ~]# chkconfig certmonger on
    2. certmonger を使用し、ipa-getcert コマンドで証明書を作成し、管理します。オプションの詳細は、「certmonger で証明書の要求」を参照してください。
      [root@ipaclient ~]# ipa-getcert request -d /etc/pki/nssdb -n Server-Cert -K HOST/ipaclient.example.com -N 'CN=ipaclient.example.com,O=EXAMPLE.COM'
    クライアントに管理ツールがインストールされていない場合は、IdM サーバーで証明書を生成し、ホストにコピーして、certutil を使用してインストールできます。
  14. Kerberos と連携するように NFS を設定します。
    ヒント
    NFS の設定時に発生する可能性のあるエラーをトラブルシューティングできるように、/etc/sysconfig/nfs ファイルでデバッグ情報を有効にします。
    RPCGSSDARGS="-vvv"
    RPCSVCGSSDARGS="-vvv"
    1. IdM サーバーで、NFS クライアントの NFS サービスプリンシパルを追加します。
      [root@ipaclient ~]# ipa service-add nfs/ipaclient.example.com@EXAMPLE
      注記
      これは、ipa コマンドを使用できるように、ipa-admintools パッケージがインストールされているマシンから実行する必要があります。
    2. IdM サーバーで、NFS サービスプリンシパルの keytab を取得します。
      [root@ipaclient ~]# ipa-getkeytab -s server.example.com -p nfs/ipaclient.example.com@EXAMPLE -k /tmp/krb5.keytab
      注記
      Linux の NFS 実装バージョンによっては、暗号化タイプのサポートが限定されます。Red Hat Enterprise Linux 6 よりも前のバージョンで NFS サーバーをホストしている場合は、サーバーおよびすべてのクライアントの両方で、任意の nfs/<FQDN> サービスキータブをサーバーと全クライアント両方で設定するように、-e des-cbc-crc オプションを指定して ipa-getkeytab コマンドを実行します。これにより、KDC で DES キーのみが生成されるように指示します。
      DES キーを使用する場合、この暗号化タイプに依存するクライアントおよびサーバーではすべて、/etc/krb5.conf ファイルの [libdefaults] セクションで allow_weak_crypto オプションを有効にする必要があります。これらの設定変更を行わない場合には、NFS クライアントとサーバーは相互に認証できず、NFS ファイルシステムのマウントに失敗する可能性があります。クライアントの rpc.gssd とサーバーの rpc.svcgssd デーモンは、DES の暗号化タイプが許可されていないことを示すエラーをログに記録する場合があります。
    3. IdM サーバーから NFS サーバーにキータブをコピーします。たとえば、IdM サーバーと NFS サーバーが異なるマシンにある場合は、以下を実行します。
      [root@ipaclient ~]# scp /tmp/krb5.keytab root@nfs.example.com:/etc/krb5.keytab
    4. IdM サーバーから IdM クライアントにキータブをコピーします。たとえば、以下のようになります。
      [root@ipaclient ~]# scp /tmp/krb5.keytab root@client.example.com:/etc/krb5.keytab
    5. NFS サーバーで /etc/exports ファイルを設定します。
      /ipashare       gss/krb5p(rw,no_root_squash,subtree_check,fsid=0)
    6. クライアントで NFS 共有をマウントします。
      • 共有は必ず、nfs_server:/ /mountpoint と指定します。
      • -o sec 設定は、NFS サーバーの /etc/exports ファイルで使用する設定と同じものを使用します。
      [root@client ~]# mount -v -t nfs4 -o sec=krb5p nfs.example.com:/ /mnt/ipashare

5.4.2. ホストエントリーを追加する他の例

「IdM クライアントの設定 (全手順)」では、IdM クライアントを手動で設定する全手順を説明します。上記の手順の 1 つとして、ホストエントリーの作成が含まれます。ホストの作成の方法及びオプションは複数あります。

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

  1. Identity タブを開き、サブタブの ホスト を選択します。
  2. ホスト一覧の上部にある Add をクリックします。
  3. マシン名を入力し、ドロップダウンリストの設定済みゾーンからドメインを選択します。ホストに静的 IP アドレスが割り当てられている場合は、ホストエントリーにそのアドレスを追加して、DNS エントリーが完全に作成されるようにします。
    「正引き DNS ゾーンの追加」で説明されているように、DNS ゾーンは IdM で作成可能です。IdM サーバーが DNS サーバーを管理しない場合は、通常のテキストフィールドなど、メニューエリアでゾーンを手動で入力できます。
    注記
    ホスト名を解決できない場合でも、Force チェックボックスを選択して、ホストの DNS レコードを追加します。
    これは、DHCP を使用して、静的な IP アドレスがないホストに役に立ちます。これにより、IdM DNS サービスにプレースホルダーエントリーが作成されます。DNS サービスが動的にレコードを更新すると、ホストの現行の IP アドレスが削除され、DNS レコードが更新されます。
  4. Add and Edit をクリックして、拡張エントリーページに移動し、属性情報をさらに入力します。ホストのハードウェアと物理的な場所に関する情報は、ホストエントリーに追加できます。

5.4.2.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 リソースレコードにホストも追加できます。

例5.6 静的 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 レコードが更新されます。

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

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

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

キックスタートで登録すると、プロビジョニング時に新しいシステムが自動的に IdM ドメインに追加されます。
これには、パスワードを事前定義して、IdM サーバーにホストを予め作成しておく必要があります。このパスワードを使用して、認証を行い、登録操作を完了できます。
  1. IdM サーバー上でホストエントリーを作成し、エントリーの一時 Kerberos パスワードを設定します。
    ipa-client-install スクリプトが (対話的に) 通常通りに実行されると、IdM ドメインにアクセスするための認証情報の入力が求められます。ただし、スクリプトが自動的に実行される場合には、既存の IdM ユーザーを使用せずに IdM ドメインにアクセスする方法が必要になります。これは、スクリプトでホストプリンシパルを設定し、IdM ドメインへのアクセス用の Kerberos パスワード (ホストアカウントに設定) を使用して実行します。
    以下に例を示します。
    [jsmith@server ~]$ ipa host-add kickstart-server.example.com --password=secret
    パスワードは、最初の認証試行後に有効期限が切れます。登録が完了すると、ホストはキータブを使用して認証されます。
  2. 他のインストールと共に ipa-client パッケージも追加します。
    %packages
    @ X Window System 
    @ Desktop 
    @ Sound and Video					
    ipa-client
    ...
  3. 登録前に SSH 鍵が生成されるようにするインストール後の指示を作成し、ipa-client-install スクリプトを実行して IdM ドメインサービスへのアクセスおよび設定に必要なすべての情報を渡し、事前設定されたパスワードを指定します。この --unattended オプションを使用して、スクリプトが非対話的に実行されるように指示します。
    %post --log=/root/ks-post.log
    
    # Generate SSH keys to ensure that ipa-client-install uploads them to the IdM server
    /usr/bin/ssh-keygen -q -t rsa -f /etc/ssh/ssh_host_rsa_key -C '' -N ''
    chmod 600 /etc/ssh/ssh_host_rsa_key
    chmod 644 /etc/ssh/ssh_host_rsa_key.pub
    /sbin/restorecon /etc/ssh/ssh_host_rsa_key.pub
    
    /usr/bin/ssh-keygen -q -t rsa1 -f /etc/ssh/ssh_host_key -C '' -N ''
    chmod 600 /etc/ssh/ssh_host_key
    chmod 644 /etc/ssh/ssh_host_key.pub
    /sbin/restorecon /etc/ssh/ssh_host_key.pub
    
    /usr/bin/ssh-keygen -q -t dsa -f /etc/ssh/ssh_host_dsa_key -C '' -N ''
    chmod 600 /etc/ssh/ssh_host_dsa_key
    chmod 644 /etc/ssh/ssh_host_dsa_key.pub
    /sbin/restorecon /etc/ssh/ssh_host_dsa_key.pub
    
    # Get the hostname to set as the host principal	
    /bin/hostname > /tmp/hostname.txt
    
    # Run the client install script
    /usr/sbin/ipa-client-install --domain=EXAMPLEDOMAIN --enable-dns-updates --mkhomedir -w secret --realm=EXAMPLEREALM --server=server.example.com --unattended
    注記
    Red Hat は、キックスタートの登録前に sshd サービスを起動することは推奨していません。登録前に sshd を起動すると、クライアントは自動的に SSH 鍵を生成するので、上記のスクリプトの使用が推奨されます。
  4. キックスタートスクリプトを実行します。

5.6. Two-Administrator 登録の実行

IdM ドメインでマシンをクライアントとして登録する場合は、2 つのプロセスがあります。クライアントにホストエントリーが作成されて (389 Directory Server インスタンスに格納されて) から、クライアントをプロビジョニングするキータブが作成されます。
プロセスは、いずれも ipa-client-install コマンドで自動的に実行されます。この手順は個別に実行することもできます。これにより、管理者は、クライアントを実際に構成する前にマシンと IdM サーバー設定を準備できます。これにより、一括デプロイメントなど、より柔軟な設定シナリオが可能になります。
手動登録を実行すると、ホストエントリーが個別に作成され、クライアントスクリプトの実行時に登録が完了し、必要なキータブが作成されます。
注記
パスワードを設定する方法は 2 つあります。ご自身でパスワードを設定するか、IdM が無作為に生成できます。
グループの管理者によるホストエントリーの 作成 が禁止されている場合があるので、単に ipa-client-install コマンドを実行してホストを作成できない場合があります。ただし、管理者にはホストエントリーの作成 にコマンドを実行する権限がある場合があります。このような場合には、管理者はホストエントリーを手動で作成し、2 番目の管理者が ipa-client-install コマンドを実行して登録を完了できます。
  1. 管理者は、「ホストエントリーを追加する他の例」の説明に従って、ホストエントリーを作成します。
  2. 2 つ目の管理者は、「IdM クライアントとしての Linux システムの設定」の説明のように IdM クライアントパッケージをマシンにインストールします。
  3. 2 つ目の管理者が設定スクリプトを実行すると、ipa-client-install コマンドで Kerberos パスワードとユーザー名 (プリンシパル) を指定する必要があります。たとえば、以下のようになります。
    $ ipa-client-install -w secret -p admin2
  4. キータブは、クライアントマシンが IdM ドメインに接続できないように、サーバーで生成されてクライアントマシンにプロビジョニングされます。このキータブは、所有者が root:root、パーミッションが 0600 として保存します。

5.7. クライアントマシンの手動による設定解除

マシンを IdM ドメインから削除して別のドメインに移動するか、または仮想マシンをコピーする必要がある場合があります。IdM の再設定が必要な各種状況が複数あります。最も簡単な解決策として、クライアントをアンインストールしてから最初から設定することです。クライアントをインストールする場合のように --updatedns オプションを使用して、ドメイン DNS 設定を自動的に更新します。
[root@server ~]# ipa-client-install --uninstall --updatedns
クライアントを直接アンインストールできない場合は、クライアントシステムから IdM 設定を手動で削除できます。
警告
マシンの登録解除後は、元に戻すことはできません。マシンをもう一度登録し直すことしかできません。
  1. クライアントで、メインのキータブから以前のホスト名を削除します。これは、レルムのプリンシパルをすべて削除するか、特定のプリンシパルを削除して実行できます。たとえば、すべてのプリンシパルを削除するには、以下を実行します。
    [jsmith@client ~]$ ipa-rmkeytab -k /etc/krb5.keytab -r EXAMPLE.COM
    特定のプリンシパルを削除するには、以下を実行します。
    [jsmith@client ~]$ ipa-rmkeytab -k /etc/krb5.keytab -p host/server.example.com@EXAMPLE.COM
  2. クライアントシステムで、全証明書の certmonger の追跡を無効にします。各証明書は、個別に追跡から削除する必要があります。
    まず、追跡する全証明書を一覧表示し、各証明書のデータベースとニックネームを取り出します。証明書の数は、ホストに設定されたサービスにより異なります。
    [jsmith@client ~]$ ipa-getcert list
    次に、それぞれの追跡を無効にします。以下に例を示します。
    [jsmith@client ~]$ ipa-getcert stop-tracking -n "Server-Cert" -d /etc/httpd/alias
  3. IdM サーバーで、IdM DNS ドメインから以前ホストを削除します。これはオプションですが、システムに関連付けられた以前の IdM エントリーを消去して後で正しく登録できるようにします。
    [jsmith@server ~]$ kinit admin
    [jsmith@server ~]$ ipa host-del server.example.com
  4. 別の場所に移動した仮想マシンなど、新しい IdM ドメインにシステムを追加し直す必要がある場合には、クライアントシステムで ipa-join コマンドを使用してシステムを再度参加させることができます。
    [jsmith@client ~]$ ipa-join

第6章 Identity Management のアップグレード

Identity Management は通常、システムが新規リリースにアップグレードされるたびに更新されます。アップグレードは透過的であるため、ユーザーや管理者の介入は必要ありません。

6.1. アップグレードの注意事項

重要
CVE-2014-3566 のため SSLv3 (Secure Socket Layer version 3) プロトコルは mod_nss モジュールで無効にする必要があります。次の手順に従い、無効になっていることを確認してください。
  1. /etc/httpd/conf.d/nss.conf ファイルを編集し、NSSProtocol パラメーターを TLSv1.0 (後方互換性用) および TLSv1.1 に設定します。
    NSSProtocol TLSv1.0,TLSv1.1
  2. httpd サービスを再起動します。
    # service httpd restart
  • 更新プロセスでは、全スキーマおよび LDAP 設定、Apache 設定、およびその他のサービス設定が自動的に更新され、IdM 関連のサービスがすべて再起動されます。
  • レプリカの作成時には、ベースとしたマスターと同じバージョンを使用する必要があります。つまり、サーバーのアップグレードプロセス時に、レプリカを以前の Identity Management バージョンで作成しないようにしてください。アップグレードプロセスが完了するまで待ってから、新しいレプリカを作成します。
  • スキーマが変更されると、サーバー間で複製されます。したがって、マスターサーバー 1 台が更新されると、パッケージがまだ更新されていない場合でも、全サーバーおよびレプリカのスキーマが更新されます。これにより、新しいスキーマを使用する新規エントリーを、IdM ドメイン内にある他の全サーバーでそのまま複製できます。
    LDAP のアップグレード操作は、/var/log/ipaupgrade-log のアップグレードログに記録されます。LDAP エラーが発生した場合は、上記のログに記録されます。エラーが解決されると、updater スクリプトを実行して LDAP 更新プロセスを手動で開始できます。
    [root@server ~]# ipa-ldap-updater --upgrade
  • クライアントには、新しいパッケージをインストールする必要はありません。ドメインでのクライアント登録には、Red Hat Enterprise Linux システムの設定に使用するクライアントパッケージによる影響はありません。
  • クライアントパッケージを更新すると、バグ修正を含む certmonger など、他の依存関係が更新される可能性がありますが、IdM ドメインでクライアントの機能や動作を維持するためには必要ありません。

6.2. パッケージのアップグレード

IdM サーバーパッケージは、システムパッケージの更新時に更新されます。
[root@ipaserver ~]# yum update
Identity Management 機能を提供する SSSD などの関連サービスの更新を自動的にプルするので、IdM サーバーパッケージを更新するのが最も簡単な方法です。
特に IdM サーバーパッケージをアップグレードするには、マスターサーバーで yum を実行します。
[root@ipaserver ~]# yum update ipa-server
更新プロセスで全変更を適用するには、数分かかる可能性があります。
注記
すべてのサーバーとレプリカを同じタイミングで更新する必要はありません。IdM サーバーは相互に連携し、データを正しく複製します。以前の IdM サーバーには、新機能が含まれていないだけです。

6.3. チケット委譲のブラウザー設定の削除 (6.2 からのアップグレード)

Kerberos 認証の設定の一環として、プリンシパルには ticket granting ticket (TGT) が割り当てられます。プリンシパルが Kerberos ドメイン内のサービスまたはアプリケーションに接続を試行するたびに、サービスはアクティブな TGT があるかを確認し、そのプリンシパルがサービスにアクセスするために TGT から独自のサービス固有のチケットを要求します。
以前の Identity Management バージョンでは、IdM Web UI (およびその他の Kerberos 対応 Web アプリケーション) へのアクセスに使用する Web ブラウザーを設定するには、TGT 委譲を IdM サーバーに転送する必要がありました。これには、delegation-uris パラメーターを Firefox の about:config 設定に追加する必要がありました。
network.negotiate-auth.delegation-uris .example.com
Red Hat Enterprise Linux 6.3 では、Identity Management はユーザー向けの Kerberos サービスをプロキシー (S4U2Proxy) に使用するため、この追加の委譲手順は必要ありません。

既存の設定済みブラウザーの更新

Identity Management の Web UI を使用するように設定されているブラウザーでは、 delegation-uris 設定は、ipa-server-3.0.0 または ipa-client-3.0.0 にアップグレードしてから消去できます。

delegation-uris 設定の変更後に、ブラウザーを再起動する必要はありません。

新規ブラウザー設定用の configure.jar の更新

ブラウザーの設定は configure.jar ファイルに定義されます。この JAR ファイルはサーバーのインストール時に生成され、IdM の更新時に他のファイルと一緒に更新されません。IdM サーバーをアップグレードしても、設定済みのブラウザーには不必要な delegation-uris パラメーターが設定されたままになります。ただし、configure.jar ファイルは更新できます。

configure.jarpreferences.html ファイルは、delegation-uris パラメーターを設定します。更新した preferences.html ファイルは configure.jar に追加してから、configure.jar を再署名し、IdM サーバーにデプロイし直すことができます。
注記
最初の IdM サーバーの configure.jar ファイルだけを更新します。これは、署名証明書が唯一含まれるマスターサーバーです。次に、更新したファイルを他のサーバーおよびレプリカに伝播します。
  1. 最初の IdM マスターサーバー (最初のインスタンス) でパッケージを更新します。これにより、configure.jar ファイルを含む 3.0 UI パッケージが作成されます。
  2. 既存の configure.jar ファイルをバックアップします。
    [root@ipaserver ~]# mv /usr/share/ipa/html/configure.jar /usr/share/ipa/html/configure.jar.old
  3. 一時作業ディレクトリーを作成します。
    [root@ipaserver ~]# mkdir /tmp/sign
  4. 更新した preferences.html ファイルを作業ディレクトリーにコピーします。
    [root@ipaserver ~]# cp /usr/share/ipa/html/preferences.html /tmp/sign
  5. signtool コマンド (NSS ユーティリティーの 1 つ) を使用して新しい preferences.html ファイルを追加し、configure.jar ファイルを再署名します。
    [root@ipaserver ~]# signtool -d /etc/httpd/alias -k Signing-Cert -Z /usr/share/ipa/html/configure.jar -e ".html" -p `cat /etc/httpd/alias/pwdfile.txt` /tmp/sign
    -e オプションは、ツールに対して、拡張子が .html のファイルのみに署名するように指示します。-Z オプションでは、新しい JAR ファイルを作成します。
  6. 再生成された configure.jar ファイルを、他の全 IdM サーバーおよびレプリカにコピーします。

6.4. IdM サーバーのアップグレード前のテスト (推奨)

実稼働システムをアップグレードする前に、新しいバージョンの Identity Management をテストすると、有益でより安全です。適切なレプリカを作成し、そのシステムでテストすることで、比較的簡単な方法で実行できます。
  1. 4章IdM レプリカの設定」で説明されているように、実稼働サーバーのいずれかを基にレプリカを設定します。この例では、これは Test Replica という名前を使用しています。Test Replica が 実稼働 サーバーおよびドメインに正常に接続できることを確認します。
  2. 実稼働ドメインに Test Replica が正常に追加されたことを確認したら、ネットワークから Test Replica の接続を解除します
  3. 元の IdM サーバーと Test Replica から、Test Replica のレプリカ合意を削除します。
  4. Test Replica をネットワークに再接続します。
  5. yum またはお使いのシステムに適したパッケージの更新ツールを使用して、Test Replica でパッケージをアップグレードします。たとえば、以下のようになります。
    [root@ipareplica ~]# yum update ipa*
  6. Kerberos 認証情報の取得、サーバー UI の表示、コマンドの実行など、Test Replica で一般的な内容をテストします。

第7章 IdM サーバーおよびレプリカのアンインストール

IdM サーバーと IdM レプリカの両方をアンインストールするには、--uninstall オプションを ipa-server-install コマンドに指定します。
[root@ipareplica ~]# ipa-server-install --uninstall

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

Web UI とコマンドラインを使用して Identity Management にアクセスするにはユーザーは必ず、IdM ドメインに対して認証を行います。本章では、Kerberos 認証の処理、Identity Management へのログイン、および一般的な接続の問題のトラブルシューティングを行うための基本的なブラウザーの設定について説明します。

8.1. IdM ドメインの起動と停止

IdM サーバーのインストール時には、Directory Server、認証局、Web サーバー、DNS、NTP、certmonger、および Kerberos (これに限定されない) など、任意の組み合わせでインストールおよび設定できる複数の異なるサービスがあります。
これらのサーバーはすべて、連携して動作します。サービスには依存関係があるため、サービスの起動と停止の順序は重要です。
(LDAP ディレクトリーや Web サーバーなど) 1 つのサービスに変更を加えると、service コマンドを使用してサービスを個別に開始および停止できます。ただし、複数のドメインサービス (または IdM サーバー全体) を再起動する必要がある場合は、ipactl コマンドを使用すると、適切な順番にサービスが開始および停止されます。
特定の IdM サーバーにどのサービスを設定するかは、IdM サーバーのホスト名を基に 389 Directory Server 設定で定義します。[1] 389 Directory Server サービスは、最初に開始し、最後に停止してください。残りの実行順序は、設定されているサービスにより異なります。
ipactl コマンドで、サービスの起動、停止、再起動が可能です。
ipactl start | stop | restart
chkconfig コマンドは、システムの再起動時に自動的に起動するサービスを設定します。ipactl コマンドを使用すると、chkconfig の実行順に個別に設定する必要なく、適切な順序で起動できます。
[root@server ~]# chkconfig ipactl on

8.2. IdM クライアントツールの概要

IdM は、汎用的に適用される認証ソースおよび共通のポリシーを使用して認識済みのサービス、ホストマシン、ユーザーのドメインを作成します。クライアントマシンと IdM ユーザーの視点からすると、初期設定が済むとドメイン自体は非常に透過的になります。ユーザーはすべて Kerberos を使用してドメインにログインするだけです。
ただし、管理者は継続して、IdM の Kerberos ドメインにプリンシパルを追加するタスク、ドメインの対話と統制するドメインポリシーとサーバー設定を設定するタスクの 2 つのタスクを実行する必要があります。Identity Management には、管理者がドメイン、サービス、および IdM エントリーの管理に使用するコマンドラインおよび Web ベースのインターフェースの両方があります。
コマンドラインツールを使用するのがドメイン管理の最も一般的な方法です。Identity Management には、管理者が利用できる幅広いスクリプトとコマンドのセットがあります。ドメインのエントリー管理機能は、1 つのスクリプト (ipa) で実行されます 。このスクリプトは、関連付けられたサブコマンドの親または制御スクリプトです。各サブコマンドは、特定のエントリータイプに関連します。
コマンドラインスクリプトには、以下のような複数の利点があります。
  • スクリプトを使用すると、手動による介入なしに一貫した方法で管理タスクを自動化して実行できます。
  • エントリーには、1 回の手順で設定可能な属性 (または任意の属性のサブセット) を追加できます。Web UI では、エントリーを完全に設定するには、最初にエントリーを作成して次にオプション属性を追加するという 2 つの手順が必要になります。
  • コマンドラインスクリプトでは、別の属性の追加 (UI では対応していない場合あり) や、スキーマが設定されている場合にはエントリーへのカスタム属性の追加にも対応します。

8.2.1. ipa コマンドの構造

基本的には、ipa コマンドは、大きいプラグインコンテナーです。ipa は多くのサブコマンドをサポートします。これらのサブコマンドは、実際には Identity Management で特定のオブジェクトタイプを管理するプラグインです。
最初のタイプのサブコマンドは、オブジェクトタイプ (user、sudo、group、host、dns など) を識別し、2 つ目はそのオブジェクトで実行される操作を特定します。
ipa objectType-operation objectName --option=value
たとえば、ユーザーの追加は、user-add サブコマンドを使用します。
ipa user-add entryName options
関連するサブコマンドは plug-in モジュール にグループ化されます。dnszone-add および dnsrecord-add のような DNS エントリーの管理コマンドはすべて、dns モジュールまたは topic に属します。特定のエリアを管理する全情報、サポート対象の全コマンド、それぞれの例は、対象のトピックのヘルプを表示すると確認できます。
ipa help topic
ヒント
利用可能なトピックをすべて表示するには以下を実行します。
ipa help topics
トピックやコマンドのエリアではすべて、エントリーの管理方法には一貫したパターンがあります。

8.2.1.1. ipa でのエントリーの追加、編集、および削除

新しいエントリーは *-add コマンドを使用して追加します。たとえば、以下のようになります。
$ ipa user-add jsmith
add の操作では、コマンドで通常、必要な設定属性を入力するようにプロンプトを表示し、コマンドラインオプションとして、または --set/addattr オプション (「--setattr、--addattr、および --delattr を使用したエントリー属性の管理」) を使用してその内容を渡します。
$ ipa user-add
First name: John
Last name: Smith
User login [jsmith]: jsmith
--------------------
Added user "jsmith"
--------------------
...
同様に、エントリーは通常 *-mod コマンドを使用して編集します。編集後には、新規または編集した属性がオプションとして一覧表示されます。
$ ipa user-mod jsmith --title="Editor III"
最後に、*-del コマンドおよびエントリー名を使用してエントリーを削除できます。
$ ipa user-del jsmith

8.2.1.2. ipa でのエントリーの検索および表示

*-find コマンドおよび任意の検索条件を使用して、全タイプのエントリーを検索できます。検索条件は、完全に一致する文字列または検索属性値のサブ文字列のいずれかで指定します。たとえば、smith の文字列に完全一致するもの (Smith の sn の値など) と、jsmith のユーザー名や Smithson といった長い名前などの値の一部に一致するものを検索します。
ipa user-find smith
検索はすべて自動的に文字列の部分検索を行うので、ワイルドカードを指定する必要はありません。
検索条件がないと、対象のタイプの全エントリーが表示されます。
検索 (*-find コマンド) 時には、返されるエントリー数 (サイズ制限) および検索時間 (時間制限) など、サーバー設定の一部に制限が課されます。詳細は、「IdM 検索制限の設定」を参照してください。サーバー設定では、検索時のサイズや時間制限に関するグローバル初期設定を指定するものもあります。これらの制限は常に Web UI で適用されますが、*-find コマンドに --sizelimit および --timelimit オプションを指定して上書きできます。たとえば、デフォルトの時間制限が 60 秒で検索にかかる時間が長くなる場合に、時間制限を 120 秒に増やすことができます。
[jsmith@ipaserver ~]$ ipa user-find smith --timelimit=120
エントリータイプの属性すべてを検索できるわけではありません。特定の属性サブセットは検索用に事前定義され、インデックス化されています。(このリストはユーザーおよびグループに対して設定可能ですが、他のタイプのエントリーには対応していません)。
エントリーが返されると、そのエントリーとともに特定のデフォルト属性のみが表示されます。エントリーに現在設定されている属性をすべて返すには、--all オプションを使用します。
特定のエントリーを表示するには、*-show コマンドとエントリー名を使用します。検索と同様に、--all オプションが使用されない限り、エントリーとともに属性のサブセットのみが表示されます。

8.2.1.3. ipa でのグループおよびコンテナーへのメンバーの追加

グループメンバーは、単にエントリーを変更する以外に、別のコマンドを使用して追加、削除します。メンバーコマンドでは基本的に、さまざまな IdM エントリーの間で関係が作成されます。従来の group-member ロールではこれは明確ですが、エントリーが別のエントリーに関連付けられているポリシーエントリー (SELinux ポリシーや sudo ポリシーなど) にも該当します。
最も一般的に、メンバーエントリーの追加のコマンド形式は、*-add-member ですが、このコマンドで *-add-user など、エントリータイプを指定できます。
同様に、メンバーのエントリーは、 (エントリー自体を削除するのではなく) *-remove-member または *-remove-type コマンドを使用して削除します。

8.2.2. ipa コマンドの位置要素

通常、ipa サブコマンドには、修正するエントリー名 (オブジェクト) と、サブコマンドで利用可能なオプションの要素が 2 つだけ含まれます。
ipa command entryName --options=values
ただし、エントリーによっては、エントリー名自体だけでなく、エントリーの も指定する必要があります。たとえば、automount コマンドなどが例として挙げられます。automount (自動マウント) では、新しい鍵またはマップが作成されるたびに場所を含める必要があります。
親エントリー名を最初に、次に子エントリー名を指定します。たとえば、automount (自動マウント) の場合は、最初に場所を、次にマップまたはキーエントリー名を指定します。
ipa command parentEntryName childEntryName --childOptions=childValues

8.2.3. --setattr、--addattr、および --delattr を使用したエントリー属性の管理

Identity Management の全 ID および設定は、標準の Attribute-Value Assertion (AVA) を使用して LDAP エントリーとして格納されます。エントリーが UI または CLI 経由で作成されたかどうかに拘らず、エントリータイプのデフォルトおよびカスタムオブジェクトクラスによって、必要な特定の属性と利用可能な属性があります。
最も一般的な属性では、ipa コマンドは、コマンドライン引数を使用して値を設定します。たとえば、ユーザーにメール属性を追加するには、--mail 引数を使用し、DNS ゾーンの動的更新を有効にするには、zone コマンドに --allow-dynupdate オプションを使用します。また、自動マウントのマッピングのマップキーを指定するには --key オプションを使用します。
ただし、コマンドライン (または UI) オプションのない属性でもエントリーの設定が可能です。基盤となる LDAP スキーマには、許容可能な属性が多数あり、特にユーザーエントリーについては非常にリッチであることが理由の一部となっています。また、Identity Management ではユーザーおよびグループのスキーマ拡張が可能で、これらのカスタムスキーマ要素は必ずしも UI またはコマンドラインツールに反映されているとは限りません。
--setattr および --addattr オプションを使用して、サポート対象の属性をエントリーに追加または編集できます。
重要
追加する属性の値は、変更コマンドや --setattr または --addattr オプションでは検証されません。
いずれのオプションも、形式は以下のとおりです。
--setattr=attribute=value
--setattr オプションは、指定された属性に値を 1 つ設定し、既存の値は複数値の属性であっても上書きされます。
--addattr オプションは、属性に新しい値を追加します。複数値の属性の場合は、既存の値を維持しながら新しい値を追加します。
--setattr オプションと --addattr は、同じコマンド呼び出しで複数回使用できます。たとえば、以下のようになります。
$ ipa user-mod jsmith --addattr=mail=johnnys@me.com --addattr=mail=jsmith@example.com --setattr=description="backup IT manager for the east coast branch"
同様に、属性または特定の属性値は、--delattr オプションを使用してエントリーから削除できます。値が 1 つだけの属性の場合には、属性は削除されます。値が複数ある属性の場合は、指定された値のみが削除されます。以下に例を示します。
$ ipa user-mod jsmith --delattr=mail=johnnys@me.com
注記
属性の追加または編集してから最後に、属性の削除が評価されます。1 回の変更操作で、同じ属性を追加して削除した場合は、何も操作はされません。
$ ipa user-mod jsmith --addattr=mail=johnnys@me.com --delattr=mail=johnnys@me.com

8.2.4. IdM ツールでの特殊文字の使用

IdM コマンドラインツールは、シェルの他のユーティリティーとして実行されます。コマンドに引用符括弧 (> および <)、アンパサンド(&)、アスタリスク(*)、およびパイプ (|) など、特殊文字がある場合には、これらの特殊文字をエスケープする必要があります。エスケープしていない場合には、シェルがエスケープされていない文字を正しく解析できないため、コマンドの実行に失敗します。

8.2.5. 実行前の IdM ドメインへのログイン

IdM コマンド (ipa-server-install などのインストールコマンドを除く) を実行する前に、ユーザーは最初に Kerberos チケットを取得して IdM ドメインに対して認証する必要があります。これには、kinit を使用します。
[jsmith@ipaserver ~]$ kinit admin
「IdM へのログイン」では、他のログインオプションについて説明しています。

8.3. IdM へのログイン

ユーザーは、Kerberos 認証を使用して、コマンドラインツールや Web UI などの IdM サービスに対して認証されます。そのため、Identity Management にログインするには kinit を実行する必要があります。
kinit を実行すると、ユーザーに Kerberos チケット が発行されます。すべてのドメインサービスにアクセスするのに一度だけしかログインする必要がないように、このチケットはいずれかの IdM または Kerberos 対応のサービスにより確認されます。ドメインサービスには、IdM の Web UI、マウントしたファイル共有、wiki、または IdM を ID/認証ストアとして使用するその他のアプリケーションが含まれます。

8.3.1. IdM へのログイン

Identity Management にログインするには、IdM ドメイン内のクライアントで kinit を実行する必要があります。
$ kinit
クライアントが IdM KDC で認証されるように、IdM ドメイン内でクライアントとして設定されたマシンから kinit コマンドを実行する必要があります。
kinit を実行するだけで、現在ログイン中のユーザーアカウントとして IdM にログインできます。IdM Kerberos ドメインに対して正常に認証するには、このユーザーアカウントも IdM ユーザーでなければなりません。たとえば、user としてマシンにログインしている場合は、以下を実行します。
$ kinit
Password for user@EXAMPLE.COM:
注記
SSSD または pam_krb5 が IdM クライアントマシンに設定されている場合には、ユーザーがマシンにログインすると、sudo など認証が必要なマシンサービスに使用できるチケットが作成されます。

8.3.2. IdM ユーザーがシステムユーザーではない場合のログイン

ユーザーのシステムユーザー名は、IdM のユーザー名とは異なります。IdM ユーザー名を指定するか、アカウントを切り替えるには、kinit コマンドを再度実行して、新しいユーザーを指定するだけです。たとえば、以下のようになります。
$ kinit userName 
Password for userName@EXAMPLE.COM:
サーバーの初期設定時に、通常の管理アクティビティーを実行する管理ユーザー admin が作成されます。admin ユーザーとして認証するには、kinit の実行時に、ユーザー名として admin を使用しまます。
$ kinit admin
注記
チケットは、ログインユーザーごとに 1 つだけ保存できます。現在保存されている認証情報は、IdM サービスへのアクセス時に使用される認証情報です。
別のユーザーとして IdM Web UI に接続している場合は、ブラウザーを更新して、新規ユーザーの更新済みの情報を表示します。

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

klist コマンドを使用して、サーバーからの ID および ticket granting ticket (TGT)を検証します。
$ klist
Ticket cache: FILE:/tmp/krb5cc_500
Default principal: ipaUser@EXAMPLE.COM

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

Kerberos 4 ticket cache: /tmp/tkt500
klist: You have no tickets cached
認証済みのユーザーしか、IdM サービスにアクセスできないので、認証されたユーザーを特定することが重要です。kinit の Kerberos クライアントライブラリーには制限があります。その 1 つとして、 kinit を新たに呼び出すと、現在のチケットが上書きされる点が挙げられます。ユーザー A として認証してからユーザー B として認証すると、ユーザー A のチケットが上書きされます。
マシンで複数の認証ユーザーを存在させるには、KRB5CCNAME 環境変数を設定します。この変数は、認証情報のキャッシュを異なるシェルに分離します。

8.3.4. ユーザーの Kerberos チケットのキャッシュ

チケットは、ログインユーザーごとに 1 つだけ保存できます。現在保存されている認証情報は、IdM サービスへのアクセス時に使用される認証情報です。
たとえば admin として認証し、新規ユーザーの追加、パスワードの設定を行い、そのユーザーとして認証を行おうとすると、管理者のチケットがなくなります。
別のシェルに、認証情報キャッシュを分離するには、KRB5CCNAME の特別な環境変数を使用します。

8.4. IdM Web UI の使用

Web UI を使用するには、IdM Kerberos ドメインでユーザーを認証して、このユーザーには有効な Kerberos チケットが必要です。「IdM へのログイン」を参照してください。通常、Web UI には IdM サーバーまたはクライアントマシンからしかアクセスできないので、ユーザーをローカルで認証する必要があります。回避策は 2 つあり、ドメインを使用しないマシンで Kerberos を設定して Kerberos ドメインに接続するか (「別のシステムでのブラウザーの使用」を参照)、パスワードを使用して UI への認証を行います。

8.4.1. Web UI の概要

Web UI には主に 3 つの機能エリアがあります。各機能エリアは、IdM の主要な機能それぞれ (Identity Management、ポリシー管理、ドメイン設定) に対応します。
表8.1 タブごとの設定エリア
メインメニュータブ 設定エリア
アイデンティティー
  • ユーザーエントリー
  • ユーザーグループエントリー
  • ホスト/クライアントエントリー
  • ホストグループエントリー
  • netgroups エントリー
  • ドメインサービスエントリー
  • DNS (設定されている場合)
ポリシー
  • ホストベースのアクセス制御
  • Sudo ルール
  • automount
  • ユーザーパスワードポリシー
  • Kerberos チケットポリシー
IdM サーバー (Identity Management 内のアクセス制御)
  • ロールベースのアクセス制御 (グループメンバーシップに基づくパーミッション)
  • 自己権限
  • 委譲 (他のユーザーに対するユーザーアクセス制御)
全ページの上部にある メインメニュー には、表8.1「タブごとの設定エリア」に記載の機能エリアに対応するタブが 3 つあります。タブを選択すると、各種設定エリアを含むサブメニューがあります。設定エリアによっては複数のエントリーがある場合があります。たとえば、ロールベースのアクセス制御はユーザーロール/グループを定義し、アクセスを付与/拒否 (特権) できるエリア、これらのエリアに付与されるパーミッションを定義します。個別の設定エリアには、主の設定エリアの下に独自のタスクエリアがあります。

図8.1 メインメニュー

メインメニュー

8.4.2. IdM Web UI の表示

「ブラウザーの設定」の記載どおりに、ブラウザーを正しく設定して、ユーザーが UI に接続できるように Kerberos 認証をサポートする必要があります。
Web UI を開くには、以下を実行します。
  1. 「IdM へのログイン」の記載のように、kinit を使用して有効な Kerberos チケットを取得します。
  2. IdM の URL を開きます。完全な URL は https://IPAserver-FQDN/ipa/ui ですが、このサービスにも https://IPAserver-FQDN を開くだけでアクセスできます。たとえば、以下のようになります。
    https://server.example.com
    https://server.example.com/ipa/ui

8.4.3. ブラウザーの設定

Web UI への接続に対応する Web ブラウザーは Firefox バージョン 17 以降および Google Chrome です。ブラウザーの設定に関する詳細は、以下の適切な項を参照してください。

8.4.3.1. Firefox の設定

Firefox では、Kerberos 認証情報を使用して IdM UI に対して認証できますが、IdM ドメインを使用するように Kerberos 交渉を設定する必要があります。初回ログイン時に、Firefox が Kerberos 認証をサポートするように設定されていない場合は、エラーメッセージが表示されます。

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

Kerberos 認証エラーメッセージ
このエラーが表示された場合には、IdM の Web UI で以下の必要な設定を実行してください。
  1. follow these directions リンクをクリックします。
  2. IdM サーバーの CA 証明書のインポートリンクをクリックします。
  3. CA 証明書の Web サイトおよびソフトウェア開発者 (最初と最後) トラストの部分を設定します。
  4. Configure Firefox ボタンをクリックします。クリックすると、Firefox 設定の negotiate オプションすべてが入力され、IdM ドメインの設定に使用されます。
    プロセスが完了すると、Firefox がシングルサインオンの設定を完了した旨の成功表示のポップアップが表示されます。そこから、IdM Web UI にリダイレクトされます。
この手順は手動で行うこともできます。
  1. Firefox を起動します。
  2. アドレスバーに about:config と入力します。
  3. Search フィールドに negotiate と入力して Kerberos 関連のパラメーターをフィルターします。
  4. Red Hat Enterprise Linux で、URI パラメーターのドメイン名を一番前のピリオド (.) も含めて入力し、gsslib パラメーターを true に設定します。
    network.negotiate-auth.trusted-uris  .example.com
    network.negotiate-auth.using-native-gsslib true
    Windows で、信頼できる URI およびライブラリーパスを設定し、認証用の組み込みの Microsoft Kerberos を無効にします。
    network.negotiate-auth.trusted-uris .example.com
    network.auth.use-sspi false 
    network.negotiate-auth.gsslib: C:\Program Files\MIT\Kerberos\bin\gssapi32.dll
    64 ビットシステムでは、ライブラリーは C:\Program Files(x86)\MIT\Kerberos\bin\gssapi32.dll に配置されています。
  5. http://ipaserver.example.com など、IdM サーバーの完全修飾ドメイン名に移動して、Web UI を開きます。Web UI を開き、Kerberos の認証エラーがないことを確認します。
  6. 次に IdM サーバーの CA 証明書を http://ipa.example.com/ipa/config/ca.crt からダウンロードします。
  7. 表示された Downloading Certificate ウィンドウで、最初 (Trust this CA to identify web sites) と 3 番目 (Trust this CA to identify software developers) のチェックボックスを選択します。

8.4.3.2. Chrome の設定

  1. CA 証明書のインポート
    1. http://my.ipa.server/ipa/config/ca.crt から CA 証明書をダウンロードします。ホストが IdM クライアントでもある場合は、/etc/ipa/ca.crt で証明書を確認することができます。
    2. デフォルトでは Chrome の右上隅にある Customize and control Google Chrome のツールチップのメニューボタンをクリックし、Settings をクリックします。
    3. Show advanced settings をクリックして他のオプションを表示し、HTTPS/SSL ヘディングの下にある Manage certificates ボタンをクリックします。
    4. Authorities タブで、下部の インポート ボタンをクリックします。
    5. 最初の手順でダウンロードした CA 証明書ファイルを選択します。
  2. SPNEGO (Simple and Protected GSSAPI Negotiation Mechanism) を有効にして Chrome で Kerberos 認証を使用します。
    1. 以下を実行して、必要なディレクトリーを作成していることを確認します。
      [root@client]# mkdir -p /etc/opt/chrome/policies/managed/
      
    2. 書き込み権限をシステム管理者または root に限定して新しい /etc/opt/chrome/policies/managed/mydomain.json ファイルを作成し、以下の行を追加します。
      { "AuthServerWhitelist": "*.example.com" }
      
      これには以下を実行します。
      [root@server]# echo '{ "AuthServerWhitelist": "*.example.com" }' > /etc/opt/chrome/policies/managed/mydomain.json
      

8.4.4. 別のシステムでのブラウザーの使用

IdM ドメインのメンバーでは ない システムから Identity Management の Web UI に接続できます。このような場合には、kinit を実行する前に外部 (IdM 以外の) マシンで IdM 固有の Kerberos 設定ファイルを指定できます。その後に、IdM サーバードメインに対して認証が可能になります。
これは特に、インフラストラクチャー全体で複数のレルムや重複ドメインがある場合に役立ちます。
  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. 「ブラウザーの設定」のように、外部マシンで Firefox を設定します。

8.4.5. 簡易ユーザー名/パスワード認証情報でのログイン

Kerberos 認証が失敗すると、ブラウザーログインも失敗します。そのため、IdM の Web UI にアクセスができなくなります。UI の簡易認証により、Kerberos サービスに問題がある場合やシステムが IdM ドメイン外にある場合でもログインできるようになります。
Web UI にログインを試行するユーザーの、有効な Kerberos チケットが IdM サーバーで見つからない場合には、エラーメッセージが表示されます。IdM ドメインサービスに対する推奨の接続方法 (UI を含む) は、Kerberos 認証を使用する方法であるため、エラーでは最初に Kerberos 認証情報を更新するか、ブラウザーが Kerberos 認証に対応する設定を行うように指示します。
メッセージの 2 番目の部分で、簡易認証の代わりに使用する手段を提示します。フォームベースの認証 リンクから、ログインページが開きます。

図8.3 IdM フォームベースのログインオプション

IdM フォームベースのログインオプション
次に、設定された IdM ユーザーの UID およびパスワードを指定するだけです。

図8.4 IdM パスワードのプロンプト

IdM パスワードのプロンプト

8.4.6. プロキシーサーバーでの UI の使用

プロキシーサーバーを使用すると、IdM で追加設定なしに Web UI にアクセスできます。
ポート転送は IdM サーバーではサポートされていませんが、IdM ではプロキシーサーバーを使用できるので、OpenSSH と SOCKS オプションでプロキシー転送を使用して、ポート転送に似た操作を設定できます。ただし、IdM でプロキシーサーバーを使用できるので、OpenSSH および SOCKS オプションで、プロキシー転送を使用して、ポート転送に似た操作を設定できます。

8.5. TLS 1.2 環境で実行する IdM サーバーの設定

詳細は、Red Hat ナレッジベースの「 Configuring TLS 1.2 for Identity Management in RHEL 6.9」を参照してください。


[1] ディレクトリールックアップで使用するホスト名は、/etc/ipa/default.conf 設定ファイルで制御できます。

第9章 アイデンティティー: ユーザーおよびユーザーグループの管理

Identity Management のユーザーは、Kerberos 認証を使用してドメイン内のサービスおよびサーバーにアクセスできます。本章では、ユーザー、グループ、パスワードポリシー、および他のユーザー設定に関する一般的な管理タスクについて説明します。

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

IdM ユーザーには、ホームディレクトリーが必要です。ホームディレクトリーが想定される場所にないと、ユーザーはドメインにログインできない可能性があります。システム管理者は IdM 以外でホームディレクトリーを管理できますが、PAM モジュールを使用して、IdM サーバーとクライアントの両方で自動的にホームディレクトリーを作成することもできます。

9.1.1. ホームディレクトリーの概要

IdM は、ユーザー管理の一環として、ユーザーのホームディレクトリーを管理できます。ただし、IdM には、管理対象のホームディレクトリーに対して、特定の定義済みパラメーターがあります。
  • ユーザーのホームディレクトリーに使用するデフォルトの接頭辞は /home です。
  • IdM では、ユーザーのログイン時に、ホームディレクトリーは自動的に作成されません。ホームディレクトリーの自動作成には、pam_oddjob_mkhomedir モジュールまたは pam_mkhomedir モジュールが必要です。このモジュールは、「PAM ホームディレクトリーモジュールの有効化」に記載されているように、クライアントのインストールの一部として、またはインストール後に設定できます。
    IdM のホームディレクトリープロセスでは、まず pam_oddjob_mkhomedir モジュールの使用を試みます。このモジュールでは、ホームディレクトリーの作成に必要なユーザー権限やアクセス権限が少なくて済み、SELinux とスムーズに統合できるようにするためです。このモジュールが利用できない場合には、プロセスは pam_mkhomedir モジュールにフォールバックします。
    注記
    Red Hat Enterprise Linux 5 クライアントでは、クライアントのインストールスクリプトは pam_oddjob_mkhomedir モジュールが利用できる場合でも、pam_mkhomedir モジュールを使用します。Red Hat Enterprise Linux 5 で pam_oddjob_mkhomedir モジュールを使用するには、PAM 設定を手動で編集します。
  • ドメイン内の全マシンが利用できる /home を提供する NFS ファイルサーバーを使用し、IdM サーバーに自動マウントすることができます。
    NFS ユーザーへの root アクセス割り当てに関連するセキュリティーの問題、/home ツリー全体を読み込む際のパフォーマンスの問題、ホームディレクトリーのリモートサーバーを使用する際のネットワークパフォーマンスの問題など、NFS の使用時に問題が発生する可能性があります。Identity Management では NFS の使用に関する一般的なガイドラインがあります。
    • automount を使用して、ユーザーがログインした時のみ、/home ツリー全体を読み込むのではなく、ユーザーのホームディレクトリーのみをマウントします。
    • 限定的なパーミッションを割り当てたリモートユーザーを使用してホームディレクトリーを作成し、そのユーザーとして IdM サーバーに共有をマウントします。IdM サーバーは httpd プロセスとして実行されるので、sudo または同様のプログラムを使用して IdM サーバーへの限定的なパーミッションを許可し、NFS サーバーにホームディレクトリーを作成できます。
    • pam_oddjob_mkhomedir モジュールなどのメカニズムを使用して、そのユーザーとしてホームディレクトリーを作成します。
    ホームディレクトリーに自動マウントを使用する方法は、「ホームディレクトリーを手動でマウントする手順」を参照してください 。
  • ホームディレクトリーの作成に適したディレクトリーとメカニズムがない場合は、ログインできない可能性があります。

9.1.2. PAM ホームディレクトリーモジュールの有効化

ユーザーのログイン時にホームディレクトリーを自動的に作成するには、IdM で pam_oddjob_mkhomedir モジュールまたは pam_mkhomedir モジュールを使用できます。必要なパフォーマンスが少なく、SELinux と適切に連携するので、IdM では pam_oddjob_mkhomedir モジュールの使用が優先されます。このモジュールがインストールされていない場合は、pam_mkhomedir モジュールにフォールバックされます。
注記
IdM では pam_oddjob_mkhomedir モジュールまたは pam_mkhomedir モジュールが必要ではありません。これは、共有ストレージが利用できない場合でも、*_mkhomedir モジュールがホームディレクトリーを作成しようとするためです。このモジュールでホームディレクトリーを作成できない場合は、ユーザーは IdM ドメインにログインできなくなります。
システム管理者は、必要に応じて各クライアントまたはサーバーでこのモジュールをアクティベートする必要があります。
pam_oddjob_mkhomedir (または pam_mkhomedir) モジュールを有効にする方法は 2 つあります。
  • --mkhomedir オプションは ipa-client-install コマンドで使用できます。このオプションはクライアントでは可能ですが、サーバーで設定しても利用できません。
  • システムの authconfig コマンドを使用して、pam_oddjob_mkhomedir モジュールを有効にできます。たとえば、以下のようになります。
    authconfig --enablemkhomedir --update
    このオプションは、インストール後のサーバーマシンとクライアントマシンの両方に使用できます。
注記
Red Hat Enterprise Linux 5 クライアントでは、クライアントのインストールスクリプトは pam_oddjob_mkhomedir モジュールが利用できる場合でも、pam_mkhomedir モジュールを使用します。Red Hat Enterprise Linux 5 で pam_oddjob_mkhomedir モジュールを使用するには、PAM 設定を手動で編集します。

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

PAM モジュールを使用すると、ユーザーのホームディレクトリーを自動作成できますが、この動作は環境によって適していない場合があります。このような場合に、ホームディレクトリーは、NFS 共有および automount を使用して別の場所から IdM サーバーに手動で追加できます。
  1. ユーザーディレクトリーマップ用に新しい場所を作成します。
    [bjensen@server ~]$ ipa automountlocation-add userdirs
    Location: userdirs
  2. 新しい場所の auto.direct ファイルに直接マップを追加します。この例では、マウントポイントは /share です。
    [bjensen@server ~]$ ipa automountkey-add userdirs auto.direct --key=/share --info="-ro,soft, ipaserver.example.com:/home/share"
    
    Key: /share
    Mount information: -ro,soft, ipaserver.example.com:/home/share
IdM で自動マウントの使用は、「18章ポリシー: 自動マウントの使用」で詳細に説明されています。

9.2. ユーザーエントリーの管理

9.2.1. ユーザー名の形式

ユーザー名のデフォルトの長さは 32 文字です。
IdM は、以下の正規表現に基づいて、さまざまなユーザー名形式をサポートします。
[a-zA-Z0-9_.][a-zA-Z0-9_.-]{0,252}[a-zA-Z0-9_.$-]?
ヒント
Samba 3.x マシンがサポートされる場合は、末尾に $ 記号を使用できます。
IdM のユーザー名には、Unix システムでの数字で始まるユーザー名などのシステム制限が適用されます。
注記
ユーザー名の作成時、大文字と小文字は区別されません。つまり、大文字と小文字はどちらでも入力できますが、ユーザー名の保存時には大文字と小文字は無視されます。
ユーザー名は、大文字と小文字が混在して作成された場合でも、すべての小文字になるように自動的に正規化されます。

9.2.2. ユーザーの追加

9.2.2.1. Web UI での操作

  1. Identity タブを開き、サブタブの ユーザー を選択します。
  2. ユーザー一覧上部にある Add をクリックします。
  3. ユーザーの名と姓を入力します。ユーザーログイン (UID) はユーザーのフルネームに基づいて自動的に生成されますが、Optional field リンクをクリックすると手動で設定できます。
    注記
    ユーザー名の作成時には大文字と小文字は区別されませんので、大文字、小文字は無視されます。ユーザー名は、大文字と小文字が混在して作成された場合でも、すべての小文字になるように自動的に正規化されます。
  4. 「Web UI での操作」にあるように、Add and Edit をクリックして、拡張エントリーページに移動し、属性情報をさらに入力します。ユーザーエントリーは、指定のユーザー情報およびユーザーエントリーテンプレートに基づいて、すでに入力されている基本情報で作成されます。

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

user-add コマンドで、新しいユーザーエントリーが追加されます。表9.2「デフォルトの Identity Management ユーザー属性」にリストされている属性は、特定の値でエントリーに追加でき、コマンドは引数なしで実行できます。
[bjensen@server ~]$ ipa user-add [username] [attributes]
引数を使用しない場合には、コマンドにより、必要なユーザーアカウントの情報を求められ、他の属性には、以下に出力されているデフォルト値が使用されます。以下に例を示します。
[bjensen@server ~]$ ipa user-add
First name: John 
Last name: Smith 
User login [jsmith]: jsmith 
-------------------- 
Added user "jsmith" 
-------------------- 
User login: jsmith 
First name: John 
Last name: Smith 
Full name: John Smith 
Display name: John Smith 
Initials: JS 
Home directory: /home/jsmith 
GECOS: John Smith 
Login shell: /bin/sh 
Kerberos principal: jsmith@EXAMPLE.COM 
Email address: jsmith@example.com 
UID: 882600007 
GID: 882600007 
Password: False 
Member of groups: ipausers 
Kerberos keys available: False
任意のユーザー属性をコマンドで指定できます。コマンドで指定すると、任意の属性の値が設定されるか、デフォルト属性のデフォルト値が上書きされます。
[bjensen@server ~]$ ipa user-add jsmith --first=John --last=Smith --manager=bjensen --email=johnls@example.com --homedir=/home/work/johns --password
注記
ユーザー名の作成時には大文字と小文字は区別されませんので、大文字、小文字は無視されます。ユーザー名は、大文字と小文字が混在して作成された場合でも、すべての小文字になるように自動的に正規化されます。
重要
UID または GID の番号を指定せずにユーザーを作成すると、ユーザーアカウントには、サーバーまたはレプリカの範囲で次に利用可能な ID 番号が自動的に割り当てられます。(数値の範囲は「一意の UID および GID 番号の割り当て管理」で詳述されています。) つまり、UID 番号およびプライベートグループ (設定されている場合) には一意の番号が常に割り当てられることになります。
数値がユーザーエントリーに 手動で 割り当てられると、サーバーでは uidNumber が一意であるかどうかは検証されません。ID を重複させることができます。POSIX エントリーでは、想定されている動作 (非推奨) です。
2 つのエントリーに同じ ID 番号が割り当てられている場合に、検索では、対象の ID 番号の最初のエントリーだけが返されます。ただし、他の属性の検索時や、 ipa user-find --all を使用時には、両方のエントリーが返されます。

9.2.3. ユーザーの編集

9.2.3.1. Web UI での操作

  1. Identity タブを開き、サブタブの ユーザー を選択します。
  2. 編集するユーザー名をクリックします。
  3. ユーザー用に編集できる属性には、さまざまなタイプがあります。デフォルト属性はすべて、表9.2「デフォルトの Identity Management ユーザー属性」に記載されています。Identity SettingsAccount Settings エリアの属性のほとんどは、ユーザー情報またはユーザーエントリーのテンプレートを基にデフォルト値が入力されています。
  4. フィールドを編集するか、必要に応じて属性別に Add リンクをクリックし、エントリーで属性を作成します。
  5. 編集が完了したら、ページ上部にある Update リンクをクリックします。

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

user-mod コマンドでは、属性を追加または変更してユーザーアカウントを編集します。基本的には user-mod は (ログイン ID で) ユーザーアカウント、編集する属性、新しい値を指定します。
[bjensen@server ~]$ ipa user-mod loginID --attributeName=newValue
たとえば、ユーザーの役職を Editor II から Editor III に変更するには以下を実行します。
[bjensen@server ~]$ ipa user-mod jsmith --title="Editor III"
Identity Management では複数の値を指定可能な LDAP の属性をもとに、多値 属性を使用できます。たとえば、あるユーザーがメールアドレスを 2 つ (仕事用と個人用) 使用している場合には、いずれも mail 属性に格納されます。多値属性は、--addattr オプションで管理できます。
mail のように、複数の値を属性に指定できる場合には、単純にコマンドラインの引数を使用することで新しい値に上書きされます。これは、--setattr の使用時も同様です。ただし、--addattr を使用すると新しい属性が追加されます。多値属性の場合には、既存の値に新しい値が追加されます。

例9.1 複数のメール属性

最初に、職場のメールアカウントでユーザーを作成します。
[bjensen@server ~]$ ipa user-add jsmith --first=John --last=Smith --email=johnls@example.com
次に、個人メールアカウントを追加します。
[bjensen@server ~]$ ipa user-mod jsmith --addattr=mail=johnnys@me.com
このユーザーに両方のメールアドレスが表示されます。
[bjensen@server ~]$ ipa user-find jsmith --all
--------------
1 user matched
--------------
  dn: uid=jsmith,cn=users,cn=accounts,dc=example,dc=com
  User login: jsmith
  .....
  Email address: jsmith@example.com, jsmith@new.com
同時に 2 つの値を設定するには、--addattr オプションを 2 回使用します。
[bjensen@server ~]$ ipa user-add jsmith --first=John --last=Smith --email=johnls@example.com --addattr=mail=johnnys@me.com --addattr=mail=admin@example.com

9.2.4. ユーザーの削除

ユーザーアカウントを完全に削除すると、ユーザーエントリーとグループメンバーシップやパスワードなど、そのユーザーの情報をすべて IdM から削除します。システムアカウントやホームディレクトリーなどの外部設定は、作成されたサーバーまたはローカルマシンに存在しますが、IdM 経由ではアクセスできません。
ユーザーアカウントを削除すると元に戻せません。情報を復元することはできず、新しいアカウントを作成する必要があります。
注記
すべての管理ユーザーが削除された場合、Directory Manager アカウントを使用して新しい管理ユーザーを作成する必要があります。
または、グループ管理ロールが割り当てられたユーザーでも、新しい管理ユーザーを追加できます。

9.2.4.1. Web UI の使用

  1. Identity タブを開き、サブタブの ユーザー を選択します。
  2. ユーザー名のチェックボックスを選択して削除します。
  3. タスクエリアの上部にある Delete リンクをクリックします。
  4. プロンプトが表示されたら、削除を確定します。

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

ユーザーの削除には user-del コマンドでユーザーを削除し、ユーザーログインを削除します。たとえばユーザーを 1 つだけ削除する場合には以下を実行します。
[bjensen@server ~]$ ipa user-del jsmith
複数のユーザーを削除するには、スペースで区切ってユーザーをリストします。
[bjensen@server ~]$ ipa user-del jsmith bjensen mreynolds cdickens
複数のユーザーを削除するときは、--continue オプションを使用して、エラーに関係なくコマンドを続行します。成功および失敗した操作の概要は、コマンドの完了時に標準出力 (stdout) に出力されます。--continue を使用しない場合には、このコマンドはエラーが発生する まで、操作を続行し、(エラーが発生すると) 操作を終了します。

9.3. ユーザーの公開 SSH 鍵の管理

OpenSSH は、公開鍵と秘密鍵のペア を使用してユーザーを認証します。ユーザーがネットワークリソースにアクセスを試行するときに、このキーペアを提示します。ユーザーの初回認証時には、ターゲットマシンの管理者は、この要求を手動で認証する必要があります。次に、マシンはユーザーの公開鍵を authorized_keys ファイルに保存します。ユーザーがリソースに再度アクセスを試みると、マシンは単に authorized_keys ファイルをチェックして、承認済みのユーザーに自動的にアクセスを許可します。
このシステムには、以下の問題があります。
  • SSH 鍵は、環境内の全マシンに手動かつ個別に配布する必要があります。
  • 管理者は設定に追加するユーザーキーを許可する必要がありますが、ユーザーまたはキー発行者を適切に検証することが困難であるため、セキュリティー問題が発生する可能性があります。
Red Hat Enterprise Linux では、System Security Services Daemon (SSSD) がユーザーの SSH 鍵をキャッシュして取得するように設定し、アプリケーションやサービスがユーザーキーを 1 カ所で検索できるようにします。SSSD は Identity Management を ID 情報プロバイダーとして使用できるので、Identity Management をキーの汎用かつ集中化リポジトリーとすることができます。このため管理者は、ユーザー SSH 鍵の配布や更新、検証を考慮する必要がありません。

9.3.1. SSH 鍵の形式

キーを IdM エントリーにアップロードする場合には、キーの形式は OpenSSH-style key か生の RFC 4253-style blob にすることができます。RFC 4253-style key は、IdM LDAP サーバーにインポートして保存される前に、自動的に OpenSSH-style key に変換されます。
IdM サーバーは、アップロードされたキーブロブから、RSA または DSA キーといったキーのタイプを識別できます。ただし、id_rsa.pub などのキーファイルでは、キーエントリーは先にタイプで、次にキー自体、その後に追加のコメントまたは識別子で識別されます。たとえば、特定のホスト名に関連付けられた RSA 鍵の場合:
"ssh-rsa ABCD1234...== ipaclient.example.com"
キーファイルの 3 要素はすべて、ユーザーエントリーにアップロードして表示できます。または、キーだけをアップロードすることもできます。

9.3.2. ユーザー SSH 鍵の Web UI でのアップロード

  1. ユーザーキーを生成します。たとえば、以下のように OpenSSH ツールを使用します。
    [jsmith@server ~]$ ssh-keygen -t rsa -C jsmith@example.com
    Generating public/private rsa key pair.
    Enter file in which to save the key (/home/jsmith/.ssh/id_rsa):
    Created directory '/home/jsmith/.ssh'.
    Enter passphrase (empty for no passphrase):
    Enter same passphrase again:
    Your identification has been saved in /home/jsmith/.ssh/id_rsa.
    Your public key has been saved in /home/jsmith/.ssh/id_rsa.pub.
    The key fingerprint is:
    a5:fd:ac:d3:9b:39:29:d0:ab:0e:9a:44:d1:78:9c:f2 jsmith@example.com
    The key's randomart image is:
    +--[ RSA 2048]----+
    |                 |
    |     + .         |
    |    + =   .      |
    |     =   +       |
    |    . E S..      |
    |   .    . .o     |
    |    . .  . oo.   |
    |   . o .  +.+o   |
    |    o  .o..o+o   |
    +-----------------+
  2. 公開鍵をキーファイルからコピーします。完全なキーエントリーは type key== comment の形式です。key== は必須ですが、エントリー全体を保存できます。
    [jsmith@server ~]$ cat  /home/jsmith/.ssh/id_rsa.pub
    						
    ssh-rsa AAAAB3NzaC1yc2E...tJG1PK2Mq++wQ== jsmith@example.com
  3. Identity タブを開き、サブタブの ユーザー を選択します。
  4. 編集するユーザー名をクリックします。
  5. Settings タブの Account Settings エリアで SSH public keys: Add リンクをクリックします。
  6. SSH public keys の横にある Add リンクをクリックします。
  7. ユーザーの公開鍵に貼り付けて、Set ボタンをクリックします。
    SSH public keys フィールドに New: key set と表示されるようになります。Show/Set キー のリンクをクリックすると、送信したキーが表示されます。
  8. 複数のキーをアップロードするには、公開鍵リストの下にある Add をクリックして、他のキーをアップロードします。
  9. すべてのキーが送信されたら、ユーザーページ上部の Update ボタンをクリックして変更を保存します。
公開鍵を保存すると、エントリーは鍵フィンガープリント、コメント (存在する場合)、および鍵の種類として表示されます。[2].

図9.1 保存された公開鍵

保存された公開鍵
ユーザーキーをアップロードしたら、Identity Management を ID ドメインの 1 つとして使用するように SSSD を設定し、OpenSSH がユーザーキー管理に SSSD を使用するように設定します。これは、『デプロイメントガイド』で説明されています。

9.3.3. コマンドラインでのユーザーの SSH 鍵のアップロード

--sshpubkey オプションは、64 ビットエンコードの公開鍵をユーザーエントリーにアップロードします。たとえば、以下のようになります。
[jsmith@server ~]$ ipa user-mod jsmith --sshpubkey="ssh-rsa 12345abcde= ipaclient.example.com"
実際のキーでは、キーはこの例よりも長く、通常は末尾が等号 (=) になります。
複数のキーをアップロードするには、--sshpubkey オプション 1 つでコンマ区切りのキー一覧を指定します。
--sshpubkey="12345abcde==,key2==,key3=="
ユーザーキーをアップロードしたら、Identity Management を ID ドメインの 1 つとして使用するように SSSD を設定し、OpenSSH がユーザーキー管理に SSSD を使用するように設定します。これは、『Red Hat Enterprise Linux デプロイメントガイド』で説明しています。

9.3.4. ユーザーキーの削除

  1. Identity タブを開き、サブタブの ユーザー を選択します。
  2. 編集するユーザー名をクリックします。
  3. Settings タブの Account Settings エリアを開きます。
  4. 削除するキーのフィンガープリントの横にある Delete のリンクをクリックします。
  5. 変更を保存するには、ユーザーページの上部にある Update リンクをクリックします。
コマンドラインツールで、すべてのキーを削除することもできます。方法は、--sshpubkey= を空の値に指定して ipa user-mod を実行します。これで、対象ユーザーの公開鍵が すべて 削除されます。たとえば、以下のようになります。
[jsmith@server ~]$ kinit admin
[jsmith@server ~]$ ipa user-mod --sshpubkey= jsmith


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

9.4. パスワードの変更

パスワードの変更操作には、パスワードポリシー (19章ポリシー: パスワードポリシーの定義) や最小限のアクセス制限を適用できます。
  • 管理者権限のない通常ユーザーは、個人パスワードのみを変更でき、すべてのパスワードは IdM パスワードポリシーの制限が適用されます。
    こうすることで、最終的なパスワードのセキュリティーを確保しつつ、管理者は初期パスワードを作成するか、簡単にパスワードをリセットできます。管理者がユーザーに送信したパスワードは一時的なものであるため、セキュリティーリスクはほぼありません。
  • IdM の管理ユーザーとしてパスワードを変更すると、IdM パスワードポリシーは上書きされますが、パスワードの有効期限はすぐに切れます。そのため、ユーザーは次回のログイン時にパスワードを変更する必要があります。同様に、パスワードの変更権限があるユーザーは、パスワードを変更でき、パスワードポリシーは適用されませんが、別のユーザーは次回のログイン時にパスワードをリセットする必要があります。
  • LDAP ツールを使用して LDAP Directory Manager ユーザーとしてパスワードを変更すると、IdM パスワードポリシーがすべて上書きされます。

9.4.1. Web UI での操作

  1. Identity タブを開き、サブタブの ユーザー を選択します。
  2. パスワードをリセットするユーザーの名前をクリックします。すべてのユーザーは自分のパスワードを変更できますが、管理者または、権限を委譲されたユーザーのみが、他のユーザーのパスワードを変更できます。
  3. Account Settings エリアまでスクロールします。
  4. Reset Password のリンクをクリックします。
  5. ポップアップボックスで、新しいパスワードを入力して確認します。

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

パスワード (ユーザーまたは別のユーザー) の変更は、その他のユーザーアカウントの変更と同様に user-mod コマンドを使用します。
[bjensen@ipaserver ~]$ kinit admin
[bjensen@ipaserver ~]$ ipa user-mod jsmith --password

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

ユーザーアカウントは非アクティブにしたり、無効 にしたりできます。無効にしたユーザーは、IdM または IdM 関連サービス (Kerberos など) にログインできないため、タスクを実行できません。ただし、このユーザーアカウントはそのまま Identity Management に残り、関連の情報はすべて変更されません。
注記
既存の接続は、Kerberos TGT およびその他のチケットの有効期限が切れるまで有効です。チケットの期限が切れると、ユーザーはチケットを更新できません。

9.5.1. Web UI での操作

対象のユーザーの横にあるチェックボックスを選択し、リストの上部にある Disable リンクをクリックすることで、全ユーザーリストから複数のユーザーを無効にできます。。

図9.2 ユーザー一覧の上部でのオプションの無効化/有効化

ユーザー一覧の上部でのオプションの無効化/有効化
ユーザーアカウントは、ユーザーの個別エントリーページからも無効にできます。
  1. Identity タブを開き、サブタブの ユーザー を選択します。
  2. ユーザー名をクリックして、非アクティブまたはアクティブにします。
  3. アクションのドロップダウンメニューで、Disable を選択します。
  4. Accept ボタンをクリックします。
ユーザーアカウントが無効になっている場合には、ユーザー一覧のユーザーステータスと、エントリーページのユーザー名の横に、マイナス (-) アイコンで示されます。また、ユーザーの文字は (非アクティブであることを示すため) 黒ではなくグレーになります。

図9.3 ユーザーステータスのアイコンの無効化

ユーザーステータスのアイコンの無効化

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

user-enable および user-disable コマンドを使用してユーザーを有効化/無効化します。ユーザーがログインするだけで実行できます。以下に例を示します。
[bjensen@server ~]$ ipa user-disable jsmith

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

ユーザーのログイン試行時に一定の回数、誤ってパスワードを入力すると、そのユーザーアカウントはロックされます。アカウントをロックするまでの失敗試行回数およびロックアウトの期間は、パスワードポリシー内で定義します (「アカウントロックアウトポリシーの設定」)。
パスワードポリシーでは、リセット期間を暗黙的に定義して、一定期間後にアカウントのロックが解除されるようにできます。ただし、リセット期間が比較的長い場合や、デプロイメントに強力なセキュリティーチェックをしてからアカウントのロックを解除する必要がある場合など、管理者はアカウントのロックを手作業で解除できます。
user-unlock コマンドを使用して、アカウントのロックを解除します。たとえば、以下のようになります。
[bjensen@ipaserver ~]$ kinit admin
[bjensen@ipaserver ~]$ ipa user-unlock jsmith

9.7. スマートカード

パスワードの代わりに、スマートカードに基づいた認証を使用できます。ユーザーの認証情報がスマートカードに格納され、特別なソフトウェアやハードウェアを使用して、その情報にアクセスします。この方法で認証するには、ユーザーはリーダーにスマートカードを設置してから、そのスマートカードの PIN コードを提示する必要があります。
Red Hat Enterprise Linux 6 クライアントは、SSSD が実行されており、Red Hat Enterprise Linux 7.3 以降をベースした Identity Management サーバーに登録されている場合は、ローカルのスマートカード認証を使用できます。

9.7.1. Identity Management でのスマートカードおよびスマートカードリーダーのサポート

お使いのスマートカードが coolkey パッケージでサポートされている場合には、このパッケージのインストール後に、必要な PKCS #11 モジュールがすでに中央の /etc/pki/nssdb/ の NSS データベースに配置されています。
スマートカードに対応していない場合は、以下の手順を実行します。
  1. modutil ユーティリティーを使用して、必要な PKCS #11 モジュールを手動で追加します。たとえば、以下のようになります。
    [root@ipaclient ~]# modutil -dbdir /etc/pki/nssdb/ -add "My PKCS#11 module" -libfile libmypkcs11.so
    ...
    Module "My PKCS#11 Module" added to database.
    modutil の使用方法は、modutil(1) の man ページを参照してください。
  2. NSS データベースに、スマートカードで証明書を検証する必要のある認証局 (CA) の証明書をすべて追加します。たとえば、ca_certificate.pem ファイルの CA 証明書を NSS データベースに追加するには、次のコマンドを実行します。
    [root@ipaclient ~]# certutil -A -d /etc/pki/nssdb/ -n 'CA certificate' -t CT,C,C -a -i ca_certificate.pem
    certutil の使用方法は、certutil(1) の man ページを参照してください。

9.7.2. スマートカードからの証明書のエクスポート

  1. スマートカードをリーダーに挿入します。
  2. 以下のコマンドを実行してスマートカードの証明書を表示します。
    [user@ipaclient ~]$ certutil -L -d /etc/pki/nssdb/ -h all
    Certificate Nickname         Trust Attributes
                                 SSL,S/MIME,JAR/XPI
    
    my_certificate               CT,C,C
    出力で認証に使用する証明書を特定して、そのニックネームをメモします。
  3. 証明書を Base64 形式で user.crt に抽出するには、前のステップのニックネームを使用します。
    [user@ipaclient ~]$ certutil -L -d /etc/pki/nssdb/ -n 'my_certificate' -r | base64 -w 0 > user.crt
    base64 ユーティリティーは、coreutils パッケージに含まれます。

9.7.3. IdM ユーザーのスマートカード証明書の保存

ユーザーのスマートカード証明書を保存するには、Red Hat Enterprise Linux 7 サーバーに証明書を追加します。『『Linux ドメイン ID、認証、およびポリシーガイド』』 の「外部 CA で発行された証明書の管理」を参照してください。

9.7.4. Identity Management クライアントでのスマートカード認証

Red Hat Identity Management (IdM) は、以下のスマートカードベースの認証オプション 2 つに対応しています。
ローカル認証
  • テキストコンソール
  • Gnome Display Manager (GDM) などのグラフィカルコンソール
  • su, または sudo などのローカル認証サービス
ssh でのリモート認証
スマートカードの証明書は、PIN で保護される SSH の秘密鍵と合わせて保存されます。
注記
IdM では、スマートカード認証用に上記のローカル認証サービスと ssh のみをサポートします。FTP などの他のサービスには対応していません。
SSSD ベースのスマートカード認証が設定されていると、ユーザーがログインを試行すると、システムはスマートカードの PIN コードの入力を求めます。入力した PIN が正しく、スマーどカードの証明書が有効で、ログインを試行しているユーザーが所有しており、他の設定可能な条件が満たされている場合には、ユーザーの認証に成功します。

9.7.4.1. IdM クライアントでのスマートカード認証の設定

クライアントでスマートカードを使用して認証できるようにするには、次の手順を実行します。
  1. スマートカードのサポートを有効にするには、SSSD がパスワード、ワンタイムパスワード (OTP)、またはスマートカードの PIN を要求できるようにします。これには、/etc/pam.d/password-auth および /etc/pam.d/system-auth の PAM 設定ファイルの auth の行を変更します。
    1. デフォルトの /etc/pam.d/password-auth で以下の行を削除します。
      auth        required      pam_env.so
      auth        sufficient    pam_unix.so nullok try_first_pass
      auth        requisite     pam_succeed_if.so uid >= 500 quiet
      auth        sufficient    pam_sss.so use_first_pass
      auth        required      pam_deny.so
      
      以下の行に置き換えます。
      auth        required      pam_env.so
      auth        [default=1 success=ok] pam_localuser.so
      auth        [success=done ignore=ignore default=die] pam_unix.so nullok try_first_pass
      auth        requisite     pam_succeed_if.so uid >= 500 quiet
      auth        sufficient    pam_sss.so forward_pass
      auth        required      pam_deny.so
      
    2. 同様に、デフォルトの /etc/pam.d/system-auth で以下の行を削除し ます。
      auth        required      pam_env.so
      auth        sufficient    pam_unix.so nullok try_first_pass
      auth        requisite     pam_succeed_if.so uid >= 500 quiet
      auth        sufficient    pam_sss.so use_first_pass
      auth        required      pam_deny.so
      
      以下の行に置き換えます。
      auth        required      pam_env.so
      auth        [default=1 success=ok] pam_localuser.so
      auth        [success=done ignore=ignore default=die] pam_unix.so nullok try_first_pass
      auth        requisite     pam_succeed_if.so uid >= 500 quiet
      auth        sufficient    pam_sss.so forward_pass
      auth        required      pam_deny.so
      
  2. /etc/sssd/sssd.conf の以下のオプションを true に設定します。
    [pam]
    pam_cert_auth=true
  3. SSSD を再起動します。
    [root@ipaclient ~]# systemctl restart sssd

9.7.4.2. スマートカードを使用した SSH ログイン

スマートカード認証を使用しており、ssh でログインする場合には、スマートカードリーダーモジュールに以下のパスも指定する必要があります。たとえば、以下のようになります。
$ ssh -I /usr/lib/libmypkcs11.so -l user@example.com host.example.com
Enter PIN for 'Smart Card':

9.8. ユーザープライベートグループの管理

Red Hat Enterprise Linux システムでは、ユーザーを作成するたびに、その新規ユーザーが唯一のメンバーとして所属するシークレットユーザーグループが自動的に作成されます。これは、ユーザープライベートグループ です。umask のデフォルト設定では、グループアクセスの制限はなく、ユーザーアクセスだけに制限を課すので、ユーザープライベートグループを使用すると、ファイルおよびディレクトリーのパーミッションの管理が簡単で安全になります。
IdM ドメインに新しいユーザーが作成されると、Red Hat Enterprise Linux の規則に従って、対応するプライベートグループで作成されます。多くの環境では、これはデフォルトで許容範囲内の動作ですが、プライベートグループを必要としないユーザーまたはユーザータイプがある場合や環境にすでに、NIS グループまたは他のシステムグループに GID が割り当てられている場合があります[3]

9.8.1. ユーザープライベートグループの表示

ユーザープライベートグループは 1 ユーザーに固有となっており、システムでのみ使用されます。このグループはプライベートであるため、IdM UI では表示されません。ただし、ユーザー作成時のオプションによっては、全ユーザーにプライベートグループが設定されているわけではないので、IdM ユーザードメイン内で設定されたプライベートグループの一覧を取得すると便利です。プライベートグループは、group-find コマンドに --private オプションを指定して検索および一覧表示できます。たとえば、以下のようになります。
[root@server ~]# ipa group-find --private
---------------
1 group matched
---------------
  Group name: jsmith
  Description: User private group for jsmith
  GID: 1084600001
----------------------------
Number of entries returned 1
----------------------------

9.8.2. 特定ユーザーのプライベートグループの無効化

--noprivate オプションを使用してユーザーが作成されると、プライベートグループの作成を無効にできます。
プライベートグループなしでユーザーを追加する場合に、Linux システムには新しいユーザー用の GID のユーザーが必要である点を注意してください。ただし、デフォルトのユーザーグループ (ipausers) は、POSIX 以外のグループであるため、GID は関連付けられていません。追加操作は失敗しないため、--gid オプションを使用して明示的にユーザー GID を設定するか、GID でグループを作成し、自動メンバールール を使用して (「25章ポリシー: ユーザーおよびホストの自動グループメンバーシップの定義」で説明) そのグループにユーザーを追加する必要があります。
[jsmith@server ~]$ ipa user-add jsmith --first=John --last=Smith --noprivate --gid 10000

9.8.3. グローバルでのプライベートグループの無効化

ユーザープライベートグループは、389 Directory Server の管理対象エントリープラグインにより管理されます。このプラグインを無効にして、全新規ユーザーのプライベートグループの作成を実質的に無効にできます。
これは、ipa-managed-entries コマンドを使用して行います。
  1. ipa-managed-entries コマンドを使用して、利用可能な管理エントリープラグイン定義を一覧表示します。デフォルトでは、新規ユーザー (UPG) に 1 つ、ネットグループに 1 つ (NGP) の合計 2 つあります。
    [root@ipaserver ~]# ipa-managed-entries --list -p DMpassword
    Available Managed Entry Definitions:
    UPG Definition
    NGP Definition
  2. 任意の管理対象エントリープラグインインスタンスを無効にします。以下に例を示します。
    [root@ipaserver ~]# ipa-managed-entries -e "UPG Definition" -p DMpassword disable
    Disabling Plugin
  3. 389 Directory Server を再起動して、新しいプラグイン設定を読み込みます。
    [root@ipaserver ~]# service dirsrv restart
管理対象エントリープラグインインスタンスは、enable オプションを使用して再度有効にできます。


[3] GID/UID 割当範囲の変更に関する情報は、「一意の UID および GID 番号の割り当て管理」を参照してください。

9.9. 一意の UID および GID 番号の割り当て管理

IdM サーバーは、無作為に UID および GID の値を生成し、同時にレプリカが同じ UID または GID 値を生成しないようにする必要があります。1 つの組織に異なる複数のドメインがある場合は、IdM ドメイン全体で UID および GID の数字が一意になる必要があります。

9.9.1. ID 数値の範囲の概要

UID および GID 番号は 範囲 に分けられます。個別のサーバーとレプリカでそれぞれの数的範囲を維持することで、サーバーまたはレプリカで発行された数字が別のサーバーまたはレプリカで発行された数字と重複する可能性を最小限に抑えられます。範囲は、ドメインのバックエンド 389 Directory Server インスタンスの一部として、DNA (Dynamic Numeric Assignment) プラグインを使用してサーバーとレプリカの間で更新および共有されます。同じ範囲がユーザー ID (uidNumber) およびグループ ID (gidNumber) にも使用されます。ユーザーとグループで同じ ID が指定される可能性がありますが、ID は異なる属性に設定されているので、競合はありません。ユーザーとグループの両方に同じ ID 番号を使用することで、管理者はユーザープライベートグループを設定できます。この場合に、各ユーザーに一意のシステムグループが作成され、ユーザーとグループ両方に同じ ID 番号が使用されます。
UID または GID の番号を指定せずに、または対話的にユーザーを作成すると、サーバーまたはレプリカの範囲で次に利用可能な ID 番号で、ユーザーアカウントが作成されます。つまり、UID 番号およびプライベートグループ (設定されている場合) には一意の番号が常に割り当てられることになります。
重要
数値がユーザーエントリーに 手動で 割り当てられると、サーバーでは uidNumber が一意であるかどうかは検証されません。ID を重複させることができます。POSIX エントリーでは、想定されている動作 (非推奨) です。グループエントリーの場合も同様で、重複した gidNumber を手動でエントリーに割り当てることができます。
2 つのエントリーに同じ ID 番号が割り当てられている場合に、検索では、対象の ID 番号の最初のエントリーだけが返されます。ただし、他の属性の検索時や、 ipa user-find --all を使用時には、両方のエントリーが返されます。

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

IdM 管理者はまず、サーバーのインストール時に、--idstart および --idmax オプションを指定して ipa-server-install を使用し、範囲を定義できます。これらのオプションは必須ではないので、インストール時に設定スクリプトで範囲を無作為に割り当てることができます。
最初の IdM サーバーのインストール時に範囲が設定されていないと、20 万の ID 範囲がランダムに選択されます。使用可能な範囲は 1 万個あります。この数からランダムな範囲を選択すると、今後 2 つの別の IdM ドメインがマージされた場合でも競合する可能性が低くなります。
IdM サーバーが 1 台の場合には、範囲内で ID が順番にエントリーに割り当てられます。レプリカの場合には、初期サーバーの ID 範囲は分割され、分散されます。
レプリカのインストール時に、無効な範囲を使用して設定されます。また、有効な範囲を要求可能な場所をレプリカに指示するディレクトリーエントリーもあります (これは複数のレプリカの間で共有されます)。レプリカが起動するか、現在の範囲内に利用可能な ID が 100 未満になると、利用可能なサーバーの 1 つに、新たな範囲を割り当てるように問い合わせできます。特別な拡張操作を使用して、範囲を 2 つに分割し、元のサーバーとレプリカのそれぞれで、利用可能な範囲を半分ずつに割り当てます。

9.9.3. 競合する ID 範囲に関する注記

管理者は、sssd.conf ファイル内の min_id および max_id オプションを使用して ID 番号の範囲を定義できます。デフォルトの min_id 値は 1 です。ただし、Red Hat は、システム用に予約されている UID と GID 番号との競合を避けるため、この値を 1000 に設定することを推奨しています。

9.9.4. 新しい範囲の追加

ドメイン全体の範囲がゼロに近づいてきた場合には、新しい範囲を手動で選択してマスターサーバーの 1 つに割り当てることができます。その後、すべてのレプリカは必要に応じてマスターから ID 範囲を要求します。
範囲を変更するには、389 Directory Server 設定を編集して DNA プラグインインスタンスを変更します。範囲は dnaNextRange パラメーターで定義します。以下に例を示します。
ldapmodify -x -D "cn=Directory Manager" -W -h server.example.com -p 389
Enter LDAP Password: *******
dn: cn=POSIX IDs,cn=Distributed Numeric Assignment Plugin,cn=plugins,cn=config
changetype: modify
add: dnaNextRange
dnaNextRange: 123400000-123500000
注記
このコマンドでは、指定された範囲の値だけを追加し、その範囲内の値が実際に利用できるかどうかは確認しません。このような値を割り当てようとした場合にのみ、このチェックが実行されます。すでに割り当て済みの値をほぼ含む範囲が追加された場合には、システムは、システム全体を循環して、未割り当ての値を検索し、最終的に未割り当ての値が見つからない場合には、失敗します。

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

ユーザーを作成すると、ユーザーに、ユーザー ID 番号とグループ ID 番号が自動的に割り当てられます。
ユーザーが IdM システムまたはサービスにログインすると、そのシステム上の SSSD は、関連付けられた UID/GID 番号でそのユーザー名をキャッシュします。次に、UID 番号がユーザーの ID キーとして使用されます。ユーザー名が同じで UID が異なるユーザーがシステムにログインすると、SSSD は名前が競合する 2 つの異なるユーザーとして処理します。
つまり、SSSD は UID 番号の変化を認識しません。SSSD は、異なる UID が指定された既存ユーザーとしてではなく、別の新規ユーザーとして解釈します。既存のユーザーの UID 番号が変更されると、そのユーザーは SSSD 、関連のサービスやドメインにログインできなくなります。また、これは ID 情報に SSSD を使用するクライアントアプリケーションにも影響があり、競合が発生したユーザーは検索されず、これらのアプリケーションにアクセスできなくなります。
重要
Identity Management または SSSD では、UID/GID の変更に対応していません。
何らかの理由で UID/GID 番号が変更された場合は、そのユーザーが再ログインする前に、ユーザーの SSSD キャッシュを消去する必要があります。以下に例を示します。
[root@server ~]# sss_cache -u jsmith

9.10. ユーザーおよびグループスキーマの管理

ユーザーエントリーは作成時に自動的に特定の LDAP オブジェクトクラスが割り当てられ、これにより特定の属性が利用可能になります。LDAP 属性を使用して、情報がディレクトリーに保存されます。(この詳細は、『『Directory Server Deployment Guide』』および『『Directory Server Schema Reference』』で説明されています。)
表9.1 デフォルトの Identity Management ユーザーオブジェクトクラス
詳細 オブジェクトクラス
IdM オブジェクトクラス
表9.1 デフォルトの Identity Management ユーザーオブジェクトクラス
ipaobject
ipasshuser
人物のオブジェクトクラス
表9.1 デフォルトの Identity Management ユーザーオブジェクトクラス
person
organizationalperson
inetorgperson
inetuser
posixaccount
Kerberos のオブジェクトクラス
表9.1 デフォルトの Identity Management ユーザーオブジェクトクラス
krbprincipalaux
krbticketpolicyaux
Managed エントリー (テンプレート) のオブジェクトクラス mepOriginEntry
ユーザーエントリーには多くの利用可能な属性があります。手動で設定されるものや、特定の値が設定されてない場合はデフォルト値を元に設定されるものもあります。その属性に UI やコマンドライン引数がない場合でも、表9.1「デフォルトの Identity Management ユーザーオブジェクトクラス」 内のオブジェクトクラスで使用できる属性を追加するオプションもあります。また、デフォルトの属性で生成もしくは使用される値は、「デフォルトのユーザーおよびグループ属性の指定」にあるように設定可能です。
表9.2 デフォルトの Identity Management ユーザー属性
UI フィールド コマンドラインオプション 必須、任意またはデフォルト[a]
User login username 必須
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 --password [b] 任意
User ID number[c] --uid デフォルト
Group ID number[c] --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 任意
[a] 必須の属性は、すべてのエントリーで設定する必要があります。オプションの属性は設定が可能で、デフォルトの属性は特定の値を提供しない場合は事前設定の値で自動的に追加されます。
[b] スクリプトは、引数の値を受け付けずに、新たなパスワードを要求します。
[c] UID 番号を指定せずにユーザーを作成すると、ユーザーアカウントには、サーバーまたはレプリカの範囲で次に利用可能な ID 番号が自動的に割り当てられます。(数値の範囲は「一意の UID および GID 番号の割り当て管理」で詳述されています。) つまり、UID 番号およびプライベートグループ (設定されている場合) には一意の番号が常に割り当てられることになります。
数値がユーザーエントリーに 手動で 割り当てられると、サーバーでは uidNumber が一意であるかどうかは検証されません。ID を重複させることができます。POSIX エントリーでは、想定されている動作 (非推奨) です。
2 つのエントリーに同じ ID 番号が割り当てられている場合に、検索では、対象の ID 番号の最初のエントリーだけが返されます。ただし、他の属性の検索時や、 ipa user-find --all を使用時には、両方のエントリーが返されます。

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

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

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

ユーザーおよびグループアカウントは、エントリーに適用する定義済みの LDAP オブジェクトクラスとともに作成されます。オブジェクトクラスに属する属性は、ユーザーエントリーに追加することができます。
標準および IdM 固有の LDAP オブジェクトクラスはほとんどのデプロイメントのシナリオに対応していますが、管理者はカスタマイズ属性を指定したカスタムのオブジェクトクラスを作成することもできます。

9.10.2.1. Web UI での操作

  1. カスタムスキーマ要素をすべて、Identity Management が使用する 389 Directory Server インスタンスに追加します。スキーマ要素の追加については、『Directory Server Administrator's Guide』の「スキーマ」の章で説明します。
  2. IPA Server タブを開きます。
  3. Configuration サブタブを選択します。
  4. User Options エリアまでスクロールします。
  5. ユーザーエリア下部にある Add リンクをクリックして、別のオブジェクトクラスの新規フィールドを追加します。
    重要
    設定の更新時は、常に既存のデフォルトオブジェクトクラスを追加してください。これらを含めないと、現行設定は上書きされます。Identity Management で必須のオブジェクトクラスが含まれないと、これ以降にエントリーの追加を試みるとオブジェクトクラス違反で失敗することになります。
  6. 変更が完了したら、Configuration ページ上部の Update リンクをクリックします。

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

  1. カスタムスキーマ要素をすべて、Identity Management が使用する 389 Directory Server インスタンスに追加します。スキーマ要素の追加については、『Directory Server Administrator's Guide』の「スキーマ」の章で説明します。
  2. エントリーに追加するオブジェクトクラス一覧に新規オブジェクトクラスを追加します。ユーザーのオブジェクトクラスのオプションは --userobjectclasses です。
    重要
    設定の更新時は、常に既存のデフォルトオブジェクトクラスを追加してください。これらを含めないと、現行設定は上書きされます。Identity Management で必須のオブジェクトクラスが含まれないと、これ以降にエントリーの追加を試みるとオブジェクトクラス違反で失敗することになります。
    たとえば、以下のようになります。
    [bjensen@server ~]$ ipa config-mod --userobjectclasses=top,person,organizationalperson,inetorgperson,inetuser,posixaccount, krbprincipalaux,krbticketpolicyaux,ipaobject,ipasshuser,employeeinfo

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

ユーザーエントリーの場合と同様に、管理者はグループエントリーに適用する必要のあるカスタム属性を持つカスタムオブジェクトクラスを指定できます。オブジェクトクラスを IdM サーバー設定に追加すると、これらは自動的に追加されます。

9.10.3.1. Web UI での操作

  1. カスタムスキーマ要素をすべて、Identity Management が使用する 389 Directory Server インスタンスに追加します。スキーマ要素の追加については、『Directory Server Administrator's Guide』の「スキーマ」の章で説明します。
  2. IPA Server タブを開きます。
  3. Configuration サブタブを選択します。
  4. Group Options エリアまでスクロールします。
  5. Add リンクをクリックして、別のオブジェクトクラスの新規フィールドを追加します。
    重要
    設定の更新時は、常に既存のデフォルトオブジェクトクラスを追加してください。これらを含めないと、現行設定は上書きされます。Identity Management で必須のオブジェクトクラスが含まれないと、これ以降にエントリーの追加を試みるとオブジェクトクラス違反で失敗することになります。
  6. 変更が完了したら、Configuration ページ上部の Update リンクをクリックします。

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

  1. カスタムスキーマ要素をすべて、Identity Management が使用する 389 Directory Server インスタンスに追加します。スキーマ要素の追加については、『Directory Server Administrator's Guide』の「スキーマ」の章で説明します。
  2. エントリーに追加するオブジェクトクラス一覧に新規オブジェクトクラスを追加します。グループのオブジェクトクラスのオプションは、--groupobjectclasses です。
    重要
    設定の更新時は、常に既存のデフォルトオブジェクトクラスを追加してください。これらを含めないと、現行設定は上書きされます。Identity Management で必須のオブジェクトクラスが含まれないと、これ以降にエントリーの追加を試みるとオブジェクトクラス違反で失敗することになります。
    たとえば、以下のようになります。
    [bjensen@server ~]$ ipa config-mod --groupobjectclasses=top,groupofnames,nestedgroup,ipausergroup,ipaobject,ipasshuser,employeegroup

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

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

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

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

9.10.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

9.11. ユーザーグループの管理

ユーザーグループは、特にアクセス制御およびパスワードポリシーなどの重要な管理タスクを一元管理する方法の 1 つです。インストール時に、IdM 操作専用のグループが 4 つ作成されます。
  • ipausers。全ユーザーが含まれます。
  • admins。管理ユーザーが含まれます。初期設定されている admin ユーザーはこのグループに属します。
  • trusted admins。Active Directory トラストの管理に使用する管理ユーザーが含まれます。
  • editors。Web UI で作業するユーザー向けの特別なグループです。このグループは、管理ユーザーの全権限がなくても、他のユーザーのエントリーを 編集 できます。
注記
オペレーティングシステムによっては、システムユーザーに割り当て可能なグループの数が限定される場合があります。たとえば、Solaris システムおよび AIX システムでは、各ユーザーに指定できるグループ数は 16 個までとなっています。これは、ネストされたグループを使用しており、ユーザーが自動的に複数のグループに追加される場合に問題になる可能性があります。

9.11.1. IdM のグループの種類

Identity Management のすべてのグループは基本的に 静的 であるため、グループのメンバーは、手作業で明示的にグループに追加されます。IdM では、グループが他のグループに所属する ネストされたグループ を暗黙的に許可します。この場合には、グループに含まれるメンバーはすべて自動的に親グループにも所属します。
自動メンバールールを使用すると、ユーザーエントリーの属性を使用して、ユーザーが属するグループを判断して、新しいユーザーをグループに自動的に追加できます。自動メンバールールは、「25章ポリシー: ユーザーおよびホストの自動グループメンバーシップの定義」で説明されてい ます。
IdM のグループの定義方法はシンプルですが、グループにはさまざまな設定オプションがあり、どのようなメンバーを追加できるかを変更できます。
IdM のグループタイプには、メンバーの追加方法ではなく、メンバーが最初に追加された場所をもとにしているものもあります。
  • 内部グループ (デフォルト): すべてのメンバーが IdM ドメインに所属します。
  • 外部グループ。一部またはすべてのメンバーが IdM ドメイン外の ID ストアに存在します。外部グループには、ローカルシステム、Active Directory ドメイン、またはディレクトリーサービスのいずれかを指定できます。
もう 1 つの違いは、POSIX 属性でグループが作成されるかどうかです。ほとんどの Linux ユーザーには、さまざまな POSIX 属性が必要ですが、Active Directory または Samba と対話するグループは、POSIX 以外でなければなりません。デフォルトでは、IdM は POSIX 以外のグループを作成しますが、POSIX グループを作成する (posixgroup オブジェクトクラスを追加) 明示的なオプションがあります。
グループの作成は簡単なので、作成するグループや、整理する方法を非常に柔軟に決定できます。グループは、部署、物理的な場所などの組織部門や、アクセス制御に関する IdM またはインフラストラクチャーの使用ガイドラインをもとに定義できます。

9.11.2. グループオブジェクトクラス

グループエントリーが作成されると、自動的に特定の LDAP オブジェクトクラスが割り当てられます。(LDAP オブジェクトクラスおよび属性については、『『Directory Server Deployment Guide』』および『『Directory ServerSchema Reference』』を参照してください。) 実際には、グループで重要な属性は名前と説明の 2 つのみです。
表9.4 デフォルトの Identity Management グループオブジェクトクラス
詳細 オブジェクトクラス
IdM オブジェクトクラス
表9.4 デフォルトの Identity Management グループオブジェクトクラス
ipaobject
ipausergroup
nestedgroup
グループオブジェクトクラス groupofnames

9.11.2.1. ユーザーグループの作成

9.11.2.1.1. Web UI の使用
  1. Identity タブを開き、サブタブの User Groups を選択します。
  2. グループ一覧上部にある Add をクリックします。
  3. グループの全情報を入力します。
    • 一意な名前。これは、IdM ドメインのグループに使用される ID で、作成後に変更できません。この名前にはスペースを含めることはできませんが、アンダースコア (_) のような他の区切り文字は使用できます。
    • グループの文字での説明。
    • グループが POSIX グループかどうか。エントリーに Linux 固有の情報を追加します。デフォルトでは、明示的に設定されない限り、すべてのグループは POSIX グループになります。POSIX 以外のグループを作成して、Windows または Samba との相互運用性を確保できます。
    • グループの GID 番号 (任意)。すべての POSIX グループには GID 番号が必要ですが、IdM では GID 番号は自動的に割り当てられます。
      競合のリスクがあるため、GID 番号を設定する必要はありません。GID 番号を手動で指定すると、IdM は指定した GID 番号を上書きしません (一意でない場合でも)。
  4. Add and Edit ボタンをクリックすると、すぐにメンバー選択ページに移動します。
  5. 「Web UI (グループページ) の使用」で説明されているようにメンバーを選択します。
9.11.2.1.2. コマンドラインの使用
新規グループは、group-add コマンドを使用して作成します。(このコマンドではグループだけが追加され、メンバーは別に追加します。)
グループ名とグループの説明の 2 つの属性が常に必要になります。これらの属性が引数として指定されていない場合には、スクリプトでグループ名と説明を入力するように求められます。
[bjensen@server ~]$ ipa group-add groupName --desc="description" [--nonposix]
さらに、他にもう 1 つ --nonposix という設定オプションがあります。(デフォルトでは、グループはすべて POSIX グループとして作成されます。) Samba などの Windows ユーザーおよびグループおよびプログラムとの相互運用性を確保するため、この --nonposix オプションを使用して POSIX 以外のグループを作成できます。このオプションは、スクリプトで posixGroup のオブジェクトクラスがエントリーに追加されないように指示します。
たとえば、以下のようになります。
[bjensen@server ~]$ ipa group-add examplegroup --desc="for examples" --nonposix

----------------------
Added group "examplegroup"
----------------------
  Group name: examplegroup
  Description: for examples
  GID: 855800010
引数を使用しない場合には、このコマンドにより、必要なグループアカウント情報の入力が求められます。
[bjensen@server ~]$ ipa group-add
Group name: engineering
Description: for engineers
-------------------------
Added group "engineering"
-------------------------
  Group name: engineering
  Description: for engineers
  GID: 387115842
重要
GID 番号を指定せずにグループを作成すると、グループエントリーには、サーバーまたはレプリカ範囲で次に利用可能な ID 番号が割り当てられます。(数値の範囲は「一意の UID および GID 番号の割り当て管理」で詳述されています。) つまり、グループには必ず、一意の GID 番号を割り当てられます。
数値がグループエントリーに 手動で 割り当てられると、サーバーでは gidNumber が一意であるかどうかは検証されません。ID を重複させることができます。POSIX エントリーでは、想定されている動作 (非推奨) です。
2 つのエントリーに同じ ID 番号が割り当てられている場合に、検索では、対象の ID 番号の最初のエントリーだけが返されます。ただし、他の属性の検索時や、 ipa group-find --all を使用時には、両方のエントリーが返されます。
注記
グループ名は編集できません。グループ名はプライマリーキーであるため、グループ名の変更は、グループを削除して新しいキーを作成する操作と同じです。

9.11.2.2. グループメンバーの追加

9.11.2.2.1. Web UI (グループページ) の使用
注記
この手順では、グループにユーザーを追加します。ユーザーグループには、他のユーザーグループをメンバーとして追加できます。このようなグループは、ネスト化されます
子グループのメンバーが親グループのメンバーとして表示されるまで、最長で数分かかる場合があります。これは特に、ネストされたグループのメンバーが 500 を超える仮想マシンに該当します。
ネスト化されたグループを作成する場合は、再帰 グループを作成しないようにしてください。たとえば、GroupA が GroupB のメンバーの場合には、GroupB を GroupA のメンバーとして追加しないでください。再帰グループはサポートされておらず、予測不可能な動作を引き起こす可能性があります。
  1. Identity タブを開き、サブタブの User Groups を選択します。
  2. メンバーを追加するグループ名をクリックします。
  3. タスクエリア上部にある Add をクリックします。
  4. 追加するユーザーの名前の横にあるチェックボックスをクリックし、右矢印ボタン (>>) をクリックし、名前を選択項目のボックスに移動します。
  5. 追加 ボタンをクリックします。
グループのメンバーには、ユーザーまたは、他のユーザーグループを指定できます。子グループのメンバーが親グループのメンバーとして表示されるまで、最長で数分かかる場合があります。これは特に、ネストされたグループのメンバーが 500 を超える仮想マシンに該当します。
9.11.2.2.2. Web UI (ユーザーページ) の使用
ユーザーは、ユーザーのページからグループに追加することもできます。
  1. Identity タブを開き、サブタブの ユーザー を選択します。
  2. 編集するユーザー名をクリックします。
  3. ユーザーエントリーページの User Groups タブを開きます。
  4. タスクエリア上部にある Add をクリックします。
  5. 追加するユーザーのグループ名の横にあるチェックボックスをクリックしてから、右矢印ボタン (>>) をクリックしグループを選択項目のボックスに移動します。
  6. 追加 ボタンをクリックします。
9.11.2.2.3. コマンドラインの使用
group-add-member コマンドを使用して、メンバーをグループに追加します。このコマンドは、両方のユーザーと、他のグループをグループメンバーとして追加できます。
group-add-member コマンドの構文では、グループ名と、追加するユーザーのコンマ区切りリストのみが必要になります。
[bjensen@server ~]$ ipa group-add-member groupName [--users=list] [--groups=list]
たとえば、以下は、ユーザー 3 つを engineering グループに追加します。
[bjensen@server ~]$ ipa group-add-member engineering --users=jsmith,bjensen,mreynolds
  Group name: engineering
  Description: for engineers
  GID: 387115842
  Member users: jsmith,bjensen,mreynolds
-------------------------
Number of members added 3
-------------------------
同様に、他のグループをメンバーとして追加して、ネスト化されたグループを作成することもできます。
[bjensen@server ~]$ ipa group-add-member engineering --groups=dev,qe1,dev2
  Group name: engineering
  Description: for engineers
  GID: 387115842
  Member groups: dev,qe1,dev2
  -------------------------
  Number of members added 3
  -------------------------
ネスト化されたグループを表示すると、メンバーはメンバーとして、メンバーグループのメンバーは間接メンバーとして表示されます。以下に例を示します。
[bjensen@server ~]$ ipa group-show examplegroup
  Group name: examplegroup
  Description: for examples
  GID: 93200002
  Member users: jsmith,bjensen,mreynolds
  Member groups: californiausers
  Indirect Member users: sbeckett,acalavicci
子グループのメンバーが親グループのメンバーとして表示されるまで、最長で数分かかる場合があります。これは特に、ネストされたグループのメンバーが 500 を超える仮想マシンに該当します。
注記
ネスト化されたグループを作成する場合は、再帰 グループを作成しないようにしてください。たとえば、GroupA が GroupB のメンバーの場合には、GroupB を GroupA のメンバーとして追加しないでください。再帰グループはサポートされておらず、予測不可能な動作を引き起こす可能性があります。
グループメンバーは、group-remove-member コマンドを使用して削除します。
[bjensen@server ~]$ ipa group-remove-member engineering --users=jsmith

  Group name: engineering
  Description: for engineers
  GID: 855800009
  Member users: bjensen,mreynolds
---------------------------
Number of members removed 1
---------------------------
9.11.2.2.4. グループの直接メンバーおよび間接メンバーの表示
ユーザーグループには、他のユーザーグループをメンバーとして追加できます。これは ネストされたグループ と呼ばれます。つまり、グループにメンバーが 2 種類含まれます。
  • 直接メンバー: グループに明示的に追加されます。
  • 間接メンバー: 別のユーザーグループのメンバーではあるものの、このユーザーグループがこの対象グループのメンバーであるため、このグループのメンバーとなっています。
IdM の Web UI では、グループの直接メンバーおよび間接メンバーを簡単に表示できます。メンバーリストはメンバータイプでフィルタリングされ、メンバーリストの右上隅にある Direct および Indirect ラジオボタンを選択して切り替えることができます。

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

グループの直接および間接メンバー
間接メンバーを追跡できるので、メンバーシップを複製せずに、グループメンバーシップを適切に割り当てやすくなります。

9.11.2.3. ユーザーグループの削除

ユーザーグループが削除されると、グループのみが削除されます。グループメンバー (ネスト化されたグループを含む) のユーザーアカウントには影響はありません。また、対象グループに適用されるアクセス制御の委譲も削除されます。
警告
グループすぐに、完全に削除されます。グループ設定 (委譲など) が必要な場合には、別のグループに割り当てるか、新しいグループを作成する必要があります。
9.11.2.3.1. Web UI の使用
  1. Identity タブを開き、サブタブの User Groups を選択します。
  2. 削除するグループ名の横にあるチェックボックスを選択します。
  3. タスクエリアの上部にある Delete リンクをクリックします。
  4. プロンプトが表示されたら、削除を確定します。
9.11.2.3.2. コマンドラインの使用
group-del コマンドは、指定のグループを削除します。たとえば、以下のようになります。
[bjensen@server ~]$ ipa group-del examplegroup

9.11.3. ユーザーとグループの検索

IdM でのユーザー検索は、単純な文字列 (完全な単語) または部分的な文字列に対して実行できます。「デフォルトのユーザーおよびグループ属性の指定」のように、検索する属性の範囲は、デフォルトの IdM 設定の一部として設定されます。

9.11.3.1. 検索での制限設定

9.11.3.1.1. 検索制限の種類および適用先
検索によっては、多数のエントリーが返される場合があります。すべてのエントリーが返される可能性さえもあります。検索制限では、サーバーが検索に費やす時間と、返されるエントリー数を制限することで、サーバー全体のパフォーマンスが向上します。
検索制限には、検索負荷を低減してサーバーのパフォーマンスを向上させること、返す結果を減らしてユーザビリティーを改善することの 2 つの目的があります。
IdM サーバーでは、検索時にさまざまな制限があります。
  • IdM サーバーの検索制限設定。これは、IdM サーバー自体の設定で、通常のページを表示するために 全 IdM クライアント、IdM CLI ツール、および IdM Web UI からサーバーに送信されるすべてのリクエストに適用されます。
    デフォルトでは、エントリーの上限は 100 件となっています。
  • IdM サーバーの時間制限設定。時間制限は、検索サイズの制限と同様に、IdM サーバーでの検索実行にかける最大時間を設定します。制限に達すると、サーバーは検索を停止し、その時点で返されたすべてのエントリーを返します。
    デフォルトでは、この制限は 2 秒です。
  • ページサイズの制限。厳密には検索制限ではありませんが、ページサイズの制限で、ページごとに返されるエントリーの数を制限します。IdM サーバーは、検索のエントリー上限数を返し、次にそれをソートしてページにエントリーを 20 件表示します。ページ結果を使用することで、結果を分かりやすく、見やすくします。
    この数は全検索に対して 20 件までとハードコード化されています。
  • LDAP 検索の制限 (--pkey オプション)。UI で実行した全検索、--pkey オプションを使用した CLI 検索は、IdM サーバー設定に指定されている検索制限を上書きし、基盤の LDAP ディレクトリーに指定されている検索制限を使用します。
    デフォルトでは、エントリーの上限は 2000 件となっています。この値を変更するには、389 Directory Server 設定を編集します。
9.11.3.1.2. IdM 検索制限の設定
検索制限 は、ユーザーまたはグループエントリーのデータベースのクエリー時に返されるレコード数や費やした時間に上限を設定します。検索制限には、時間制限とサイズ (数値) 制限の 2 つのタイプがあります。
デフォルト設定では、1 回の検索で返されるレコード数は 100 件未満、検査時間は 2 秒となっています。
重要
検索のサイズや時間制限を高く設定しすぎると、IdM サーバーのパフォーマンスにマイナスの影響が出る可能性があります。
9.11.3.1.2.1. Web UI の使用
  1. IPA Server タブを開きます。
  2. Configuration サブタブを選択します。
  3. Search Options 領域までスクロールします。
  4. 検索制限の設定を変更します。
    • 検索サイズ制限: 返される検索結果の最大数を設定します。
    • 検索時間制限: サーバー検索結果を返すまでに費やす最長時間を秒単位で設定します。
    ヒント
    時間制限またはサイズ制限の値を -1 に設定すると、検索に制限がないことを意味します。
  5. 変更が完了したら、Configuration ページ上部の Update リンクをクリックします。
9.11.3.1.2.2. コマンドラインの使用
検索制限は、config-mod コマンドを使用して変更できます。
[bjensen@server ~]$ ipa config-mod --searchtimelimit=5 --searchrecordslimit=500

  Max. username length: 32
  Home directory base: /home
  Default shell: /bin/sh
  Default users group: ipausers
  Default e-mail domain for new users: example.com
  Search time limit: 5
  Search size limit: 50
  User search fields: uid,givenname,sn,telephonenumber,ou,title
  Group search fields: cn,description
  Enable migration mode: FALSE
  Certificate Subject base: O=EXAMPLE.COM
  Password Expiration Notification (days): 4
ヒント
時間制限またはサイズ制限の値を -1 に設定すると、検索に制限がないことを意味します。
9.11.3.1.3. 検索のデフォルトの上書き
サーバー設定では、検索時のサイズや時間制限に関するグローバル初期設定を指定するものもあります。これらの制限は常に Web UI で適用されますが、コマンドラインで *-find コマンドを実行して上書きできます。
--sizelimit および --timelimit オプションは、対象コマンドの実行時にそれぞれ指定して、別のサイズ、時間を設定できます。どのような結果が必要かによって、制限を増やしたり減らしたりできます。
たとえば、デフォルトの時間制限が 60 秒で検索にかかる時間が長くなる場合に、時間制限を 120 秒に増やすことができます。
[jsmith@ipaserver ~]$ ipa user-find smith --timelimit=120

9.11.3.2. 検索属性の設定

ユーザーまたはグループを検索しても、対象属性で該当する属性が自動的にすべて検索されるわけではありません。代わりに、属性の特定のサブセットを検索します。また、そのリストは設定可能です。
ユーザーまたはグループの検索フィールドに属性を追加する場合は、その属性の LDAP ディレクトリーに対応するインデックスがあることを確認してください。検索はインデックスに基づいて実行されます。大半の標準 LDAP 属性にはインデックスがありますが、カスタム属性には、インデックスを作成する必要があります。インデックスの作成については、『Directory Server Administrator's Guide』の「インデックス」 の章で説明されています。
9.11.3.2.1. 検索でチェックされるデフォルトの属性
デフォルトでは、ユーザー検索には 6 つの属性が、グループ検索には 2 つの属性がインデックス化されています。これらについては、表9.5「デフォルトの検索属性」に一覧表示されます。検索属性はすべて、ユーザー/グループ検索の対象となります。
表9.5 デフォルトの検索属性
ユーザー検索の属性
First name Last name
Login ID Job title
Organizational unit Phone number
グループ検索の属性
Name 詳細
「検索属性の設定」および「グループ検索属性の変更」で説明されているように、ユーザーおよびグループの検索の対象となる属性を変更できます。
9.11.3.2.2. ユーザー検索属性の変更
9.11.3.2.2.1. Web UI での操作
  1. IPA Server タブを開きます。
  2. Configuration サブタブを選択します。
  3. User Options エリアまでスクロールします。
  4. 他の検索属性は、User search fields フィールドにコンマ区切りの一覧として追加します。
  5. 変更が完了したら、Configuration ページ上部の Update リンクをクリックします。
9.11.3.2.2.2. コマンドラインでの操作
検索属性を変更するには、--usersearch オプションを使用してユーザー検索の属性を設定します。
[bjensen@server ~]$ ipa config-mod --usersearch=uid,givenname,sn,telephonenumber,ou,title
注記
常に検索属性の完全な一覧を指定してください。設定の引数で指定した値は、以前の設定を上書きます。
9.11.3.2.3. グループ検索属性の変更
ユーザーまたはグループを検索しても、対象属性で該当する属性が自動的にすべて検索されるわけではありません。代わりに、属性の特定のサブセットを検索します。また、そのリストは設定可能です。
ユーザーまたはグループの検索フィールドに属性を追加する場合は、その属性の LDAP ディレクトリーに対応するインデックスがあることを確認してください。検索はインデックスに基づいて実行されます。大半の標準 LDAP 属性にはインデックスがありますが、カスタム属性には、インデックスを作成する必要があります。インデックスの作成については、『Directory Server Administrator's Guide』の「インデックス」 の章で説明されています。
9.11.3.2.3.1. Web UI での操作
  1. IPA Server タブを開きます。
  2. Configuration サブタブを選択します。
  3. Group Options エリアまでスクロールします。
  4. 他の検索属性は、Group search fields フィールドにコンマ区切りの一覧として追加します。
  5. 変更が完了したら、Configuration ページ上部の Update リンクをクリックします。
9.11.3.2.3.2. コマンドラインでの操作
検索属性を変更するには、--groupsearch オプションを使用してグループ検索の属性を設定します。
[bjensen@server ~]$ ipa config-mod --groupsearch=cn,description
注記
常に検索属性の完全な一覧を指定してください。設定の引数で指定した値は、以前の設定を上書きます。
9.11.3.2.4. 検索結果で返される属性の制限
UI に表示されない属性で検索を実行できます。つまり、指定のフィルターと一致しない検索で、エントリーを返すことができます。特に、検索情報が非常に短くして一致率を上げる場合などによく使用されます。

第10章 アイデンティティー: ホストの管理

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

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

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

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

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

10.3. ホストエントリーの無効化および再有効化

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

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

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

10.3.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
アクティブな IdM クライアントまたはサーバーで ipa-getkeytab コマンドを実行すると、LDAP 認証情報 (-D および -w) なしで実行できます。IdM ユーザーは、Kerberos 認証情報を使用してドメインへの認証を行います。無効化されたホストでコマンドを直接実行するには、LDAP 認証情報を指定してから IdM サーバーに認証します。認証情報は、再度有効にするホストまたはサービスに一致する必要があります。

10.4. ホストの公開 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 鍵の配布や更新、検証を心配する必要がありません。

10.4.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
キータイプは公開鍵のコンテンツから自動的に判断されます。個別キーの識別を容易にするコメントはオプションになります。必須要素は、公開鍵ブロブ自体のみとなります。

10.4.2. ipa-client-install および OpenSSH

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

10.4.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:
    4f:61:ee:2c:f7:d7:da:41:17:93:de:1d:19:ac:2e:c8 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 タブを開き、サブタブの ホスト を選択します。
  4. 編集するホスト名をクリックします。
  5. Settings タブの Host Settings エリアで、SSH public keys: Add リンクをクリックします。
  6. UI で新しいリンク (New: key not set Show/Set key) が開きます。Show/Set key リンクをクリックします。
  7. ホストの公開鍵を貼り付けて、Set ボタンをクリックします。
    SSH public keys フィールドに New: key set と表示されるようになります。Show/Set キー のリンクをクリックすると、送信したキーが表示されます。
  8. 複数のキーをアップロードするには、公開鍵リストの下にある Add をクリックして、他のキーをアップロードします。
  9. すべてのキーが送信されたら、ホストページ上部の Update ボタンをクリックして変更を保存します。
公開鍵を保存すると、エントリーは鍵フィンガープリント、コメント (存在する場合)、および鍵の種類として表示されます。[4].

図10.1 保存された公開鍵

保存された公開鍵
ホストキーをアップロードしたら、Identity Management を ID ドメインの 1 つとして使用するよう SSSD を設定し、OpenSSH がホストキー管理に SSSD ツールを使用するよう設定します。
ホストキーをアップロードしたら、Identity Management を ID ドメインの 1 つとして使用するよう SSSD を設定し、OpenSSH がホストキー管理に SSSD ツールを使用するよう設定します。これは、『Red Hat Enterprise Linux デプロイメントガイド』で説明しています。

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

ホスト SSH 鍵は、host-add を使ってホストを作成する時か、エントリーを後で修正する時に、 IdM のホストエントリーに追加されます。
注記
インストールスクリプトで SSH サービスが明示的に無効にされなければ、ipa-client-install コマンドで RSA と DSS ホストキーが作成されます。
  1. --sshpubkey オプションを指定して host-mod コマンドを実行し、64 ビットにエンコードされた公開鍵をホストエントリーにアップロードします。
    ホストキーを追加するとホストの DNS SSHFP エントリーも変更されるので、--updatedns オプションも使ってホストの DNS エントリーも更新します。
    たとえば、以下のようになります。
    [jsmith@server ~]$ ipa host-mod --sshpubkey="ssh-rsa 12345abcde==" --updatedns host1.example.com
    実際のキーでは、キーはこの例よりも長く、通常は末尾が等号 (=) になります。
    複数のキーをアップロードするには、--sshpubkey オプション 1 つでコンマ区切りのキー一覧を指定します。
    --sshpubkey="12345abcde==,key2==,key3=="
    ヒント
    ホストには複数の公開鍵を指定できます。
  2. ホストキーをアップロードしたら、Identity Management を ID ドメインの 1 つとして使用するよう SSSD を設定し、OpenSSH がホストキー管理に SSSD ツールを使用するよう設定します。これは、『Red Hat Enterprise Linux デプロイメントガイド』で説明しています。

10.4.5. ホストキーの削除

ホストキーは、期限が切れるか有効でなくなると、削除できます。
Web UI を使用して個別のホストキーを削除するのが最も簡単な方法です。
  1. Identity タブを開き、サブタブの ホスト を選択します。
  2. 編集するホスト名をクリックします。
  3. Settings タブの Host Settings エリアを開きます。
  4. 削除するキーのフィンガープリントの横にある Delete のリンクをクリックします。
  5. 変更を保存するには、ホストページの上部にある Update リンクをクリックします。
コマンドラインツールで、すべてのキーを削除することもできます。方法は、--sshpubkey= を空の値に指定して ipa host-mod を実行します。これで、対象ホストの公開鍵が すべて 削除されます。また、ホストの DNS エントリーの更新には、--updatedns オプションを使用します。たとえば、以下のようになります。
[jsmith@server ~]$ kinit admin
[jsmith@server ~]$ ipa host-mod --sshpubkey= --updatedns host1.example.com


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

10.5. ホストの Ethers 情報の設定

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

10.6. マシンの名前変更および IdM クライアントオプションの再設定

Kerberos と SSL を正しく操作するには、システムのホスト名が重要になります。Kerberos および SSL のセキュリティーメカニズムはいずれもホスト名に依存し、指定されたホスト間で通信が行われるようにします。仮想マシンまたはクラスター化されたサービスを使用するインフラストラクチャーでは一般的に、システムのコピー、移動、名前変更により、名前が変更されたホストが含まれます。
Red Hat Enterprise Linux には、IdM ホストの名前を簡単に変更するシンプルな名前変更コマンドがありません。IdM ドメインのホストの名前を変更するには、IdM のエントリーの削除、クライアントソフトウェアのアンインストール、ホスト名の変更を行い、新しい名前を使用して再登録する必要があります。さらに、ホストの名前変更を行う上で、サービスプリンシパルを再生成する必要があります。
クライアントを再設定するには、以下を実行します。
  1. マシンで実行されているサービスを特定します。これらのファイルは、マシンの再登録時に作成し直す必要があります。
    # ipa service-find server.example.com
    各ホストには、サービス一覧に表示されないデフォルトのサービスがあります。このサービスは、「ホストサービス」と呼ばれます。ホストサービスのサービスプリンシパルは、host/<hostname> です (例: host/server.example.com)。このプリンシパルは ホストプリンシパル とも呼ばれます。
  2. マシンが所属するすべてのホストグループを特定します。
    [root@client ~]# kinit admin
    [root@client ~]# ipa hostgroup-find server.example.com
  3. 証明書が関連付けられているサービスを特定します。ldapsearch コマンドを使用して、IdM LDAP データベースのエントリーを直接チェックすることでサービスの特定ができます。
    [root@client ~]# ldapsearch -x -b "cn=accounts,dc=example,dc=com" "(&(objectclass=ipaservice)(userCertificate=*))" krbPrincipalName -D "cn=directory manager" -w secret -h ipaserver.example.com -p 389
  4. (ホストプリンシパルに加えて) サービスプリンシパルの場合は、server.example.com にある対応のキータブの場所を判断します。サービスごとにキータブの場所が異なりますが、IdM にはこの情報は保存されません。
    クライアントシステム上の各サービスには ldap/server.example.com@EXAMPLE.COM など、service_name/hostname@REALM の形式で Kerberos プリンシパルが含まれています。
  5. IdM ドメインからクライアントマシンの登録を解除します。
    [root@client ~]# ipa-client-install --uninstall
  6. /etc/krb5.keytab 以外の各キータブについては、古いプリンシパルを削除します。
    [root@client ~]# ipa-rmkeytab -k /path/to/keytab -r EXAMPLE.COM
  7. IdM サーバーで、IdM 管理者としてホストエントリーを削除します。これにより、すべてのサービスが削除され、そのホストに発行されたすべての証明書が無効になります。
    [root@server ~]# kinit admin
    [root@server ~]# ipa host-del server.example.com
    この時点で、ホストは IdM から完全に削除されました。
  8. マシンの名前を変更します。
  9. IdM でシステムを再登録します。
    [root@client ~]# ipa-client-install
    再登録することで、/etc/krb5.keytab に、新規ホスト名でホストプリンシパルが生成されます。
  10. IdM サーバーで、全サービスに対して新しいキータブを追加します。
    [root@server ~]# ipa service-add serviceName/new-hostname
  11. サービスの証明書を生成するには、certmonger または IdM の管理ツールを使用します。
  12. 該当するホストグループにホストを再度追加します。

10.7. ホストグループの管理

ホストグループは、重要な管理タスク (特にアクセス制御) を一元管理する方法の 1 つです。
Identity Management のすべてのグループは基本的に 静的 であるため、グループのメンバーは、手作業で明示的にグループに追加されます。IdM では、グループが他のグループに所属する ネストされたグループ を暗黙的に許可します。この場合には、グループに含まれるメンバーはすべて自動的に親グループにも所属します。
グループの作成は簡単なので、作成するグループや、整理する方法を非常に柔軟に決定できます。グループは、部署、物理的な場所などの組織部門や、アクセス制御に関する IdM またはインフラストラクチャーの使用ガイドラインをもとに定義できます。

10.7.1. ホストグループの作成

10.7.1.1. Web UI でホストグループの作成

  1. Identity タブを開き、サブタブの Host Groups を選択します。
  2. グループ一覧上部にある Add をクリックします。
  3. グループの名前と説明を入力します。
  4. Add and Edit ボタンをクリックすると、すぐにメンバー選択ページに移動します。
  5. 「Web UI でホストグループメンバーの追加」で説明されているようにメンバーを選択します。

10.7.1.2. コマンドラインでのホストグループの作成

新規グループは、hostgroup-add コマンドを使用して作成します。(このコマンドではグループだけが追加され、メンバーは別に追加します。)
グループ名とグループの説明の 2 つの属性が常に必要になります。これらの属性が引数として指定されていない場合には、スクリプトでグループ名と説明を入力するように求められます。
$ ipa hostgroup-add groupName --desc="description"

10.7.2. ホストグループメンバーの追加

10.7.2.1. グループメンバーの表示および変更

グループ設定を使用してメンバーをグループに追加できます。グループ所属可能な全メンバータイプのタブがあり、管理者は一致する全エントリーを選択してメンバーとして追加します。
ただし、独自の設定でエンティティーをグループに追加することもできます。各エントリーにはタブの一覧があり、参加可能なグループタイプが表示されます。対象のタイプの全グループ一覧が表示され、エンティティーを同時に複数のグループに追加できます。

図10.2 メンバー

メンバー

10.7.2.2. Web UI でホストグループメンバーの追加

  1. Identity タブを開き、サブタブの Host Groups を選択します。
  2. メンバーを追加するグループ名をクリックします。
  3. タスクエリア上部にある Add をクリックします。
  4. 追加するホストの名前の横にあるチェックボックスをクリックし、右矢印ボタン (>>) をクリックし、ホストを選択項目のボックスに移動します。
  5. 追加 ボタンをクリックします。

10.7.2.3. コマンドラインでのホストグループメンバーの追加

メンバーは、hostgroup-add-member コマンドを使用して、ホストグループに追加します。このコマンドは、両方のホストと、他のグループをグループメンバーとして追加できます。
hostgroup-add-member コマンドの構文では、追加するグループ名のコンマ区切りの一覧のみが必要になります。
$ ipa hostgroup-add-member groupName [--hosts=list] [--hostgroups=list]
たとえば、以下は、ホスト 3 つを caligroup グループに追加します。
$ ipa hostgroup-add-member caligroup --hosts=ipaserver.example.com,client1.example.com,client2.example.com
  Group name: caligroup
  Description: for machines in california
  GID: 387115842
  Member hosts: ipaserver.example.com,client1.example.com,client2.example.com
-------------------------
Number of members added 3
-------------------------
同様に、他のグループをメンバーとして追加して、ネスト化されたグループを作成することもできます。
$ ipa hostgroup-add-member caligroup --groups=mountainview,sandiego
  Group name: caligroup
  Description: for machines in california
  GID: 387115842
  Member groups: mountainview,sandiego
  -------------------------
  Number of members added 2
  -------------------------

第11章 アイデンティティー: サービスの管理

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

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

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

11.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 引数を指定すると、コンマ区切りの暗号化タイプの一覧をキータブに追加できます。これは、デフォルトの暗号化タイプより優先されます。
    警告
    新たなキーを作成すると、指定されたプリンシパルのシークレットがリセットされます。つまり、そのプリンシパルの他のキータブすべてが無効になります。

11.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 引数を指定すると、コンマ区切りの暗号化タイプの一覧をキータブに追加できます。これは、デフォルトの暗号化タイプより優先されます。
    警告
    ipa-getkeytab コマンドは、指定されたプリンシパルのシークレットをリセットします。つまり、そのプリンシパルの他のキータブすべてが無効になります。

11.2. サービスおよびサービスの証明書の追加

サービスではキータブを使用できますが、サービスによってアクセスするのに証明書が必要な場合があります。このような場合には、サービスはサービスエントリーに含めるように、サービスを追加 (または変更) できます。

11.2.1. Web UI でのサービスおよび証明書の追加

  1. Identity タブを開き、Services サブタブを選択します。
  2. サービス一覧の上部にある Add リンクをクリックします。
  3. ドロップダウンメニューからサービスタイプを選択し、名前を付けます。
  4. サービスが実行される IdM ホストのホスト名を選択します。ホスト名を使用して、完全なサービスプリンシパル名を構成します。
  5. Add and Edit ボタンをクリックして、サービスエントリーページに直接移動します。
  6. ページの下部にある Service Certificate セクションまでスクロールします。
  7. New Certificate ボタンをクリックしてサービス証明書を作成します。

11.2.2. コマンドラインでのサービスおよび証明書の追加

  1. サービスプリンシパルを作成します。サービスは、service/FQDN などの名前で認識されます。
    [jsmith@ipaserver ~]$ kinit admin
    [jsmith@ipaserver ~]$ 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 cert-request --principal=HTTP/web.example.com example.csr
    ヒント
    --add オプションを使用して、証明書の要求時にサービスを自動作成します。
    または、getcert コマンドを使用し、certmonger で証明書を作成して管理します。オプションの詳細は、「certmonger で証明書の要求」を参照してください。
    $ ipa-getcert request -d /etc/httpd/alias -n Server-Cert -K HTTP/client1.example.com -N 'CN=client1.example.com,O=EXAMPLE.COM'

11.3. NSS データベースでの証明書の保存

サービスが証明書を使用する場合には、証明書およびキーは NSS データベースに格納できます (このデータベースはサービス自体や Identity Management で使用できます)。
  1. NSS データベースを作成します。
    $ certutil -N -d /path/to/database/dir
  2. NSS ツール (certutil) を使用して証明書を要求します。
    $ certutil -R -s "CN=client1.example.com,O=EXAMPLE.COM" -d /path/to/database/dir -a > example.csr
IdM ドメインが CA に証明書システムを使用している場合は、サブジェクト名の CN のみが使用されます。自己署名 CA の場合には、サブジェクトを、設定済みの証明書のサブジェクトベースと一致させる必要があります。IdM サーバーは、この値とは異なるサブジェクトベースを使用する要求を拒否します。

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

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

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

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

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

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

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

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

11.6.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
アクティブな IdM クライアントまたはサーバーで ipa-getkeytab コマンドを実行すると、LDAP 認証情報 (-D および -w) なしで実行できます。IdM ユーザーは、Kerberos 認証情報を使用してドメインへの認証を行います。無効化されたホストでコマンドを直接実行するには、LDAP 認証情報を指定して IdM サーバーへの認証を行います。認証情報は、再度有効にするホストまたはサービスに一致する必要があります。

第12章 アイデンティティー: ホストおよびサービスへのアクセス委譲

「サーバーとクライアント間の関係」で説明されているように、IdM ドメイン内で 管理する ということは、キータブおよび、別のサービスまたはホストの証明書を取得できる必要があります。すべてのホストとサービスには managedby エントリーがあり、これにホストやサービスが管理可能なものが記載されています。デフォルトでは、ホストはホスト自体とそのサービスすべてを管理できます。また、適切な委譲更新や、適切な managedby エントリーを指定して、ホストが他のホストや他のホスト上のサービスを管理できるようにすることも可能です。
IdM サービスは、そのサービスへのアクセス許可が付与、もしくは委譲 されている IdM ホストであれば、どのホストからでも管理できます。同様に、ホストにはドメイン内の他のホストへの許可を委譲できます。

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

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

12.1. サービス管理の委譲

service-add-host コマンドを使用してサービスの制御をホストに委譲します。サービスの委譲は、プリンシパルの指定と、ホストの制御指定 (コンマ区切りの一覧) の 2 つの部分で構成されます。
# ipa service-add-host principal --hosts=hostnames
以下に例を示します。
# ipa service-add-host http/web.example.com --hosts=client1.example.com
ホストに権限が委譲されると、ホストプリンシパルを使ってサービスを管理できます。
# kinit -kt /etc/krb5.keytab host/`hostname`
# ipa-getkeytab -s `hostname` -k /tmp/test.keytab -p http/web.example.com
Keytab successfully retrieved and stored in: /tmp/test.keytab
このサービスのチケットを作成するには、委譲された認証局がホストで証明書要求を作成し、cert-request コマンドでサービスエントリーを作成して認証情報を読み込みます。
# ipa cert-request --add --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
  Fingerprint (MD5): c1:46:8b:29:51:a6:4c:11:cd:81:cb:9d:7c:5e:84:d5
  Fingerprint (SHA1):
  01:43:bc:fa:b9:d8:30:35:ee:b6:54:dd:a4:e7:d2:11:b1:9d:bc:38
  Serial number: 1005

12.2. ホスト管理の委譲

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

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

各ホストおよびサービスエントリーには、どのホストがホストやサービスの管理を委譲されているかを示す説明タブがあります。
  1. Identity タブを開き、Hosts または Services サブタブを選択します。
  2. 委譲管理の付与先となる ホストもしくはサービス名をクリックします。
  3. ホストまたはサービスエントリーの右端にある Hosts サブタブをクリックします。このタブでは、選択したホストまたはサービスを 管理できる ホストが表示されます。
  4. 一覧上部にある Add をクリックします。
  5. ホスト/サービスの管理を委譲する先のホスト名の横にあるチェックボックスをクリックします。右矢印 (>>) を クリックし、ホストを選択ボックスに移動します。
  6. Add をクリックして選択ボックスを閉じて、委譲設定を保存します。

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

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

第13章 アイデンティティー: NIS ドメインおよびネットグループとの統合

ネットワーク情報サービス (NIS) は、Unix ネットワーク上の ID および認証を管理する最も一般的な方法の 1 つです。使いやすくシンプルではありますが、セキュリティーリスクがあり、柔軟性に欠けるため、NIS ドメインの管理しにくくなる可能性があります。
ID 管理では、netgroup およびその他の NIS データを IdM ドメインに統合する方法を提供します。IdM ドメインには、NIS 設定に比べ、IdM の強力なセキュリティー構造が組み込まれています。または、管理者が単に、ユーザーとホストの ID を NIS ドメインから IdM ドメインに移行することもできます。

13.1. NIS および Identity Management の概要

ネットワーク情報サービス (NIS) は、ユーザーおよびパスワード、ホストと IP アドレス、POSIX グループなどの認証およびアイデンティティー情報を一元管理します。これは、ID と認証ルックアップだけに焦点を当てていたため、イエローページ (略称 YP) と呼ばれていました。
NIS にはホスト認証のメカニズムがなく、ネットワークに、パスワードハッシュなど、暗号化されていない情報を流すので、NIS は最新のネットワーク環境の多くで安全性が低いとみなされます。管理者には NIS は人気がありませんが、システムクライアントの多くで活発に使用されています。上記のような安全性の低さを回避する方法があります。その方法として、NIS を他のプロトコルと統合して、セキュリティーを強化します。
Identity Management では、NIS オブジェクトは基礎となる LDAP ディレクトリーを使用して IdM に統合されます。LDAP サービス (RFC 2307 で定義) は、NIS オブジェクトのサポートを提供します。Identity Management はこの NIS オブジェクトをカスタマイズして、他のドメイン ID との統合が改善されるようにします。NIS オブジェクトは LDAP サービス内に作成され、nss_ldap や SSSD などのモジュールが、暗号化された LDAP 接続を使用してオブジェクトを取得します。
NIS エンティティーは netgroup に保存されます。netgroup では、標準の UNIX グループでサポートされない、ネスト化 (グループ内のグループ) が可能です。また、netgroup には、Unix グループにないホストをグループ化する方法をあります。
NIS グループは、ユーザーとホストを大規模なドメインのメンバーとして定義することで機能します。netgroup は、3 つの情報 (ホスト、ユーザー、ドメイン) を設定します。これは トリプル と呼ばれます。
host,user,domain
netgroup トリプルは、ユーザーまたはホストをドメインに関連付けますが、ユーザーとホスト間での関連付けはありません。したがって、通常トリプルでは、明確性および管理性を向上するためにホストまたはユーザーを定義します。
host.example.com,,nisdomain.example.com
-,jsmith,nisdomain.example.com
NIS は netgroup データを配信するだけではありません。ユーザーとパスワード、グループ、ネットワークデータ、およびホストに関する情報も保管します。Identity Management は NIS リスナーを使用してパスワード、グループ、および netgroups を IdM エントリーにマッピングできます。
IdM LDAP エントリーでは、netgroup のユーザーは単一のユーザーまたはグループで、いずれも memberUser パラメーターで識別されます。同様に、ホストは単一ホストまたはホストグループのいずれかになります。これらは memberHost 属性で識別されます。
dn: ipaUniqueID=d4453480-cc53-11dd-ad8b-0800200c9a66,cn=ng,cn=accounts,...
objectclass: top
objectclass: ipaAssociation
objectclass: ipaNISNetgroup
ipaUniqueID: d4453480-cc53-11dd-ad8b-0800200c9a66
cn: netgroup1
memberHost: fqdn=host1.example.com,cn=computers,cn=accounts,...
memberHost: cn=VirtGuests,cn=hostgroups,cn=accounts,...
memberUser: cn=jsmith,cn=users,cn=accounts,...
memberUser: cn=bjensen,cn=users,cn=accounts,...
memberUser: cn=Engineering,cn=groups,cn=accounts,...
nisDomainName: nisdomain.example.com
Identity Management では、これらの netgroup エントリーは netgroup-* コマンドを使用して処理され、基本的な LDAP エントリーが表示されます。
# ipa netgroup-show netgroup1
Netgroup name: netgroup1
Description: my netgroup
NIS domain name: nisdomain
Member User: jsmith
Member User: bjensen
Member User: Engineering
Member Host: host1.example.com
Member Host: VirtGuests
Identity Management は、クライアントが NIS netgroup にアクセスしようとすると、LDAP エントリーを従来の NIS マップに変換して NIS プロトコル経由でクライアントに送信するか (NIS プラグインを使用)、または RFC 2307 または RFC 2307bis に準拠する LDAP 形式に変換します。

13.2. Identity Management の NIS ポートの設定

IdM サーバーは、サーバーの起動時に無作為に選択したポートで NIS サービスにバインドします。対象のポート割り当てをポートマッパーに送信し、NIS クライアントが IdM サーバーへの問い合わせ時に使用するポートを認識できるようにします。
管理者は、NIS クライアントのファイアウォールを開放する必要がある場合や、事前にポート番号を把握し、その番号を同じままにする必要のあるサービスが他にある場合があります。この場合には、管理者は使用するポートを指定できます。
注記
NIS プラグイン設定には、1024 未満の利用可能なポート番号を使用できます。
NIS 設定は、Identity Management 内の Directory Server インスタンスの NIS プラグインにあります。ポートを指定するには、以下を実行します。
  1. NIS リスナーと互換性プラグインを有効にします。
    [root@ipaserver ~]# ipa-nis-manage enable
    [root@ipaserver ~]# ipa-compat-manage enable
  2. プラグイン設定を編集し、ポート番号を引数として追加します。たとえば、ポートを 514 に設定するには、以下を実行します。
    [root@ipaserver ~]# ldapmodify -x -D 'cn=directory manager' -w secret
    	
    dn: cn=NIS Server,cn=plugins,cn=config 
    changetype: modify
    add: nsslapd-pluginarg0
    nsslapd-pluginarg0: 514
    
    modifying entry "cn=NIS Server,cn=plugins,cn=config"
  3. Directory Server を再起動して、新しいプラグインの設定を読み込みます。
    [root@ipaserver ~]# service dirsrv restart

13.3. Netgroups の作成

Identity Management のすべての netgroup は基本的に 静的 であるため、グループのメンバーは、手作業で明示的にグループに追加されます。IdM では、グループが他のグループに所属する ネストされたグループ を暗黙的に許可します。この場合には、グループに含まれるメンバーはすべて自動的に親グループにも所属します。
netgroup は、グループ自体の作成、そのグループへのメンバーの追加の 2 つの手順で追加できます。

13.3.1. Netgroup の追加

13.3.1.1. Web UI の使用

  1. Identity タブを開き、Netgroups サブタブを選択します。
  2. netgroups 一覧の上部にある Add をクリックします。
  3. netgroup に一意の名前と説明の両方を入力します。名前と説明の両方が必要です。
    グループ名は、IdM ドメインの netgroup に使用する IDで、作成後に変更できません。この名前にはスペースを含めることはできませんが、アンダースコア (_) のような他の区切り文字は使用できます。
  4. Add and Edit ボタンをクリックすると、すぐに netgroup の編集ページに移動します。
  5. 任意で、netgroup の NIS ドメインを設定します。デフォルトではこれは IdM ドメインですが、変更できます。
    1. Settings タブをクリックします。
    2. NIS domain name フィールドで別の NIS ドメイン名を入力します。
      NIS domain name フィールドでは、netgroup のトリプルに表示されるドメインを設定します。Identity Management リスナーが応答する NIS ドメインには影響は ありません
  6. 「Web UI の使用」にあるように、メンバーを追加します。

13.3.1.2. コマンドラインの使用

新しい netgroups は netgroup-add コマンドを使用して追加されます。これによりグループのみが追加され、メンバーは別に追加されます。グループ名とグループの説明の 2 つの属性が常に必要になります。これらの属性が引数として指定されていない場合には、スクリプトでグループ名と説明を入力するように求められます。また、グループに使用する NIS ドメイン名を設定するオプションもあります。デフォルトは IdM ドメインですが、ネットワーク設定に応じて、別の設定を指定できます。
$ ipa netgroup-add --desc="description"  [--nisdomain=domainName]  groupName
以下に例を示します。
# ipa netgroup-add --desc="my new netgroup" example-netgroup
# ipa netgroup-add-member --hosts=ipa.example.com example-netgroup
# ypcat -d example.com -h ipa.example.com netgroup
(ipa.example.com,-,example.com)
注記
この --nisdomain オプションは、netgroup トリプルに表示されるドメインを設定します。Identity Management リスナーが応答する NIS ドメインには影響は ありません

13.3.2. Netgroup メンバーの追加

注記
netgroup は、ユーザーグループ、ホストグループ、およびその他の netgroup をメンバーとして追加できます。このようなグループは、ネスト化されます
子グループのメンバーが親グループのメンバーとして表示されるまで、最長で数分かかる場合があります。これは特に、ネストされたグループのメンバーが 500 を超える仮想マシンに該当します。
ネスト化されたグループを作成する場合は、再帰 グループを作成しないようにしてください。たとえば、GroupA が GroupB のメンバーの場合には、GroupB を GroupA のメンバーとして追加しないでください。再帰グループはサポートされておらず、予測不可能な動作を引き起こす可能性があります。

13.3.2.1. Web UI の使用

  1. Identity タブを開き、Netgroups サブタブを選択します。
  2. メンバーを追加する netgroup 名をクリックします。
  3. 追加する netgroup メンバータイプのタブを選択します。netgroup は、ユーザー、ユーザーグループ、ホスト、ホストグループ、およびその他の netgroup をメンバーとして指定できます。
  4. タスクエリア上部にある Add をクリックします。
  5. 追加するユーザーの名前の横にあるチェックボックスをクリックし、右矢印ボタン (>>) をクリックし、名前を選択項目のボックスに移動します。
  6. 追加 ボタンをクリックします。

13.3.2.2. コマンドラインの使用

グループが設定されたら、netgroup-add-member コマンドを使用して netgroup メンバーの追加を開始します。ユーザー、グループ、ホスト、ホストグループ、その他の netgroup はすべて netgroup エントリーに追加できます。編集する NIS グループのエントリー名は通常、コマンドの最後にあります。
# ipa netgroup-add-member --users=users --groups=groups --hosts=hosts --hostgroups=hostGroups --netgroups=netgroups  groupName
複数のメンバーを設定するには、オプションを指定してコンマ区切りの一覧を使用します。たとえば、以下は、ユーザー 2 つと、他の構成のホスト 2 つを設定します。
# ipa netgroup-add-member --users=jsmith,bjensen --groups=ITadmin --hosts=host1.example.com,host2.example.com --hostgroups=EngDev --netgroups=nisgroup2 example-group

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

システムで NIS サービスが有効になっていると、IdM サーバーは、NIS ドメインを IdM ドメイン名に設定し、NIS ドメインの passwd、group および netgroup マップとして、IdM ユーザー、グループ、netgroup を追加できます。
自動マウントマップがすでに定義されている場合は、これらのマップを Identity Management の NIS 設定に手動で追加して、NIS クライアントに公開する必要があります。NIS サーバーは、IdM LDAP ディレクトリーの特別なプラグインエントリーで管理されます。これはコンテナーエントリーで、NIS サーバーによって使用される各 NIS ドメインとマップは、そのコンテナーの下にある子エントリーとして設定されます。NIS ドメインエントリーには、NIS ドメイン名、NIS マップ名、NIS マップのコンテンツとして使用するディレクトリーエントリーの検索方法、および NIS マップのキーおよび値として使用する属性が必要です。これら設定のほとんどは、各マップで同じものになります。
IdM サーバーは、IdM ディレクトリーツリーの cn=automount ブランチに、自動マウントの場所別にグループ化された自動マウントマップを保存します。
NIS のドメインおよびマップは、ldapadd などの LDAP ツールを使用してディレクトリーを直接編集して、追加します。たとえば、以下は、default という名前の場所に、nisserver という名前のサーバーに、auto.example という名前で指定した自動マウントマップを追加します。
[root@server ~]# ldapadd -h nisserver.example.com -x -D "cn=Directory Manager" -w secret

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
設定された全マップに対して、同様の追加操作を実行する必要があります。

13.5. NIS から IdM への移行

NIS から Identity Management への直接移行パスはありません。NIS から IdM への移行は手動のプロセスで、IdM への netgroup エントリーの設定、既存データの NIS からのエクスポート、そのデータの IdM へのインポートの 3 つの手順で主に構成されます。IdM 環境の設定方法やデータのエクスポート方法には、複数のオプションがあり、最適なオプションは、データの種類と、利用する全ネットワーク環境によって異なります。

13.5.1. IdM での netgroup エントリーの準備

最初のステップでは、NIS が管理するアイデンティティーの種類を特定します。NIS サーバーは、ユーザーエントリーまたはホストエントリーのいずれかに使用されることが多く、両方に使用されることはなく、データの移行プロセスを簡素化できます。

ユーザーエントリーの場合

NIS のユーザー情報を使用するアプリケーションを判定します。(sudo のような) クライアントには NIS netgroup が必要ですが、多くのクライアントは代わりに Unix グループを使用できます。netgroup が必要ない場合は、IdM で対応するユーザーアカウントを作成し、netgroup を完全に削除するだけです。それ以外の場合は、IdM にユーザーエントリーを作成し、IdM 管理の netgroup を作成し、そのユーザーをメンバーとして追加します。この操作は、「Netgroups の作成」に説明があります。

ホストエントリーの場合

ホストグループが IdM に作成されるたびに、一致するシャドウの NIS グループが自動的に作成されます。これらの netgroup は、ipa-host-net-manage コマンドを使用して管理できます。

直接変換の場合

IdM に、すべての NIS ユーザーおよびホストに、完全に一致するエントリーがある状態で、正確な変換が必要になる場合があります。この場合には、元の NIS 名を使用して各エントリーを作成できます。

  1. netgroup で参照されているユーザーすべてについてエントリーを作成します。
  2. netgroup で参照されているホストすべてについてエントリーを作成します。
  3. 元の netgroup と同じ名前の netgroup を作成します。
  4. ユーザーとホストをこの netgroup の直接のメンバーとして追加します。または、ユーザーとホストを IdM グループまたは他の netgroup に追加し、それらのグループを netgroup に追加します。

13.5.2. Identity Management での NIS リスナーの有効化

IdM Directory Server は、制限ありの NIS サーバーとして機能します。slapi-nis プラグインは、NIS リスナーを設定し、着信 NIS 要求を受信して Directory Server 内の NIS マップを管理します。Identity Management は、以下の 3 つの NIS マップを使用します。
  • passwd
  • group
  • netgroup
IdM を中間 NIS サーバーとして使用すると、NIS のクライアントとデータの移行時に、NIS の要求を妥当に処理できるようになります。
slapi-nis プラグインはデフォルトでは無効になっています。Identity Management の NIS を有効にするには、以下を実行します。
  1. IdM 管理ユーザーとして新しい Kerberos 認証情報を取得します。
    [root@ipaserver ~]# kinit admin
  2. NIS リスナーと互換性プラグインを有効にします。
    [root@ipaserver ~]# ipa-nis-manage enable
    [root@ipaserver ~]# ipa-compat-manage enable
  3. DNS サービスおよび Directory Server サービスを再起動します。
    [root@server ~]# service rpcbind restart
    [root@server ~]# service dirsrv restart

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

NIS には、ユーザー、グループ、DNS およびホスト、netgroups、および自動マウントマップの情報を追加できます。これらのエントリータイプはどれでも IdM サーバーに移行できます。
移行には、ypcat を使用してデータをエクスポートし、その出力をループして、対応の ipa *-add コマンドで IdM エントリーを作成します。これは手動で行うことができますが、スクリプト化するのが最も簡単です。これらの例では、シェルスクリプトを使用します。

13.5.3.1. ユーザーエントリーのインポート

/etc/passwd ファイルには、すべての NIS ユーザー情報が含まれます。これらのエントリーは、NIS エントリーをミラーリングする UID、GID、gecos、shell、ホームディレクトリー、名前属性で IdM ユーザーアカウントを作成するのに使用できます。
たとえば、以下は nis-user.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
これは、特定の NIS ドメインに対して実行できます。
[root@nis-server ~]# kinit admin
[root@nis-server ~]# ./nis-user.sh nisdomain nis-master.example.com
注記
このスクリプトでは、ユーザーパスワードは移行されません。代わりに、一時パスワードが作成され、ユーザーの次回ログイン時に変更するようにプロンプトが表示されます。

13.5.3.2. グループエントリーのインポート

/etc/group ファイルには、全 NIS グループ情報が含まれます。このエントリーは、NIS エントリーをミラーリングする GID、gecos、shell、home ディレクトリー、および name 属性を使用して、IdM ユーザーグループアカウントを作成できます。
たとえば、以下は nis-group.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
これは、特定の NIS ドメインに対して実行できます。
[root@nis-server ~]# kinit admin
[root@nis-server ~]# ./nis-group.sh nisdomain nis-master.example.com

13.5.3.3. ホストエントリーのインポート

/etc/hosts ファイルには、すべての NIS ホスト情報が含まれます。このエントリーを使用して、NIS エントリーをミラーリングする IdM ホストアカウントを作成できます。
たとえば、以下は 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
これは、特定の NIS ドメインに対して実行できます。
[root@nis-server ~]# kinit admin
[root@nis-server ~]# ./nis-hosts.sh nisdomain nis-master.example.com
注記
このスクリプトの例では、エイリアスの使用など、特別なホストシナリオには対応していません。

13.5.3.4. Netgroup エントリーのインポート

/etc/netgroup ファイルには、全 NIS netgroup 情報が含まれます。このエントリーを使用して、NIS エントリーをミラーリングする IdM netgroup アカウントを作成できます。
たとえば、以下は nis-netgroup.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
「NIS および Identity Management の概要」で簡単に説明したように、NIS エントリーはトリプルと呼ばれる 3 つの値セットに存在します。トリプルは host,user,domain ですが、すべてのコンポーネントが必要な訳ではありません。通常、トリプルで、ホストとドメイン、またはユーザーとドメインのみを定義します。このスクリプトの記述の仕方から、ipa netgroup-add-member コマンドは常に、netgroup にホスト、ユーザー、ドメインのトリプルを追加します。
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"
要素が抜けている箇所は、空白として追加されるので、トリプルは正しく移行されます。たとえば、server,,domain のトリプルの場合は、メンバー追加コマンドのオプションは、--hosts=server --users="" --nisdomain=domain です。
これは、NIS ドメインと NIS サーバーを指定して、特定の NIS ドメインに対して実行できます。
[root@nis-server ~]# kinit admin
[root@nis-server ~]# ./nis-hosts.sh nisdomain nis-master.example.com

13.5.3.5. Automount マップのインポート

自動マウントマップは実際には、場所 (親エントリー) と関連のキーおよびマップを定義する入れ子および相互関連のエントリーになります。
NIS および IdM エントリーのデータは同じですが、データの定義方法は異なります。NIS 情報は、エクスポートして、自動マウントの場所と関連マップの LDAP エントリー構築に使用します。次に、マップ用に設定されたすべてのキーのエントリーを作成します。
このスクリプトは、他の NIS 移行スクリプトの例とは異なり、移行する NIS ドメインおよびサーバー以外に自動マウントの場所、マップ名もオプションとして指定できます。
#!/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=nisdomain.example.com+nis-map=$4,cn=NIS Server,cn=plugins,cn=config 
objectClass: extensibleObject 
nis-domain: $3 
nis-map: $4 
nis-base: automountmapname=$4,cn=nis,cn=automount,$basedn 
nis-filter: (objectclass=*) 
nis-key-format: %{automountKey} 
nis-value-format: %{automountInformation}        
EOF 
ldapadd -x -h $3 -D "cn=directory manager" -w secret -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 ドメインに対して実行できます。
[root@nis-server ~]# kinit admin
[root@nis-server ~]# ./nis-hosts.sh location nisdomain nis-master.example.com map

13.5.4. IdM に NIS ユーザー認証の弱度のパスワード暗号化を設定する手順

NIS サーバーは、CRYPT パスワードハッシュを処理できます。既存の NIS サーバーを IdM (およびその基盤となる LDAP データベース) に移行した後も、NIS 対応の CRYPT パスワードを保持する必要がある場合があります。ただし、デフォルトでは LDAP サーバーは CRYPT ハッシュを使用しません。salted SHA (SSHA) または SSHA-256 を使用します。389 Directory Server パスワードのハッシュを変更しない場合には、NIS ユーザーは IdM ドメインに対して認証できず、パスワードが原因で kinit に失敗します。
基礎となる 389 Directory Server がパスワードハッシュとして CRYPT を使用するように設定するには、ldapmodify を使用して passwordStorageScheme 属性を変更します。
[root@server ~]# ldapmodify -D "cn=directory server" -w secret -p 389 -h ipaserver.example.com

dn: cn=config
changetype: modify
replace: passwordStorageScheme
passwordStorageScheme: crypt
注記
パスワードストレージスキームを変更すると、このスキームは新しいパスワードにのみ適用されます。遡って、既存のパスワードに使用する暗号化メソッドは変更されません。
パスワードハッシュに弱度の暗号化が必要な場合には、ユーザーのパスワードに弱度のパスワードハッシュを使用できるように、早い段階で設定を変更することを推奨します。

第14章 アイデンティティー: フォレスト間の信頼との統合 (テクノロジープレビュー)

Kerberos は 信頼 という概念を実装しています。信頼では、Kerberos レルムからのプリンシパルが別の Kerberos レルムのサービスにチケットを要求できます。プリンシパルはこのチケットを使って、別のレルムに属するマシン上のリソースに対して認証を行うことができます。
Kerberos には、レルム間の信頼 と呼ばれる、2 つのレルム間の関係を作成する機能があります。この信頼の一部となっているレルムは、共有のチケットとキーのペアを使用します。1 つのレルムのメンバーが両方のレルムのメンバーとして認識されるようなります。
Active Directory と Identity Management の両方が、Kerberos、LDAP、DNS、証明書サービスなどのさまざまなコアサービスを管理します。このため、Kerberos レルム間の信頼を確立するだけでは、レルムのユーザーが別のレルムにあるリソースにアクセスするには不十分になります。別の通信レベルでのサポートも必要になってきます。このような目的を実現するため、IdM を使用すると、IdM ドメインと AD ドメインの間で フォレスト間の信頼 を設定できます。フォレスト間の信頼は、2 つのフォレスト Root ドメイン間で確立された信頼のことで、異なるフォレストからのユーザーとサービスが通信できるようにします。
注記
複数の AD ドメインは、1 つの Active Directory フォレスト にまとめることができます。このフォレストの root ドメインは、フォレスト内で作成される最初のドメインになります。IdM ドメインは既存の AD フォレストに含めることができないので、常に別個のフォレストとみなされます。

Red Hat Enterprise Linux 6 のフォレスト間の信頼 (テクノロジープレビュー機能)

Red Hat Enterprise Linux 6 では、フォレスト間の信頼機能はテクノロジープレビュー機能 として提供されます。Red Hat は、Red Hat Enterprise Linux 6 IdM クライアントを Red Hat Enterprise Linux 7 IdM サーバーに接続してフォレスト間の信頼機能を確保することを推奨します。信頼は、Red Hat Enterprise Linux 7 を実行するサーバーで完全にサポートされています。Red Hat Enterprise Linux 6 クライアントを Red Hat Enterprise Linux 7 サーバーに接続してフォレスト間の信頼を確立する設定も、完全にサポートされています。このような設定では、クライアント側に最新の Red Hat Enterprise Linux 6 を、サーバー側に最新の Red Hat Enterprise Linux 7 を使用することを推奨します。
Red Hat では、Red Hat Enterprise Linux 6 でのフォレスト間の信頼機能を、テクノロジープレビュー機能からサポート対象機能にアップグレードしていません。特定の AD デプロイメントで、Red Hat Enterprise Linux 6 のフォレスト間の信頼機能が動作しない場合には、最新の Red Hat Enterprise Linux 7 IdM バージョンを使用し、特定の設定で Red Hat Enterprise Linux 7 をアップグレードする必要があるかどうかを確認してください。
Red Hat Enterprise Linux 7 のフォレスト間の信頼の詳細にわたる説明が含まれるドキュメントについては、『Red Hat Enterprise Linux 7 『Windows 統合ガイド』を参照してください。

Red Hat Enterprise Linux 6 のフォレスト間の信頼機能の概要

Red Hat Enterprise Linux 6 のフォレスト間の信頼機能には、以下のような機能が含まれます。
  • 1 つの AD フォレストへの信頼を確立する。
  • 信頼された AD フォレストの rootドメインからユーザーの IdM リソースにアクセスできる。
Red Hat Enterprise Linux 6 のフォレスト間の信頼機能は、以下の機能がありません。
  • ログインシェルまたはホームディレクトリーなど AD ユーザーのデフォルトの属性を一元的に上書きする。これには、Red Hat Enterprise Linux 7 で IdM を使用して ID ビューをデプロイします。
  • レガシークライアントの互換性ツリーを使用して、AD ユーザーおよびグループを公開する。レガシークライアントが AD ユーザーおよびグループにアクセスできるようにするには、Red Hat Enterprise Linux 7 で IdM を使用します。

信頼と同期

信頼と同期は、IdM ドメインと AD ドメイン統合するための、根本的に異なるアプローチです。どちらのアプローチも、AD ドメインのユーザーが透過的に Linux システムおよびサービスにアクセスできるようにすると共に、このようなシステムに関連する Linux システムとポリシーを一元管理できる利点があります。
信頼ベースおよび同期ベースのソリューションの比較については、『Red Hat Enterprise Linux 7 『Windows 統合ガイド』を参照してください。Red Hat Enterprise Linux 6 での同期を使用した AD との統合に関する情報は、「15章アイデンティティー: 同期による Microsoft Active Directory との統合」を参照してください。

第15章 アイデンティティー: 同期による Microsoft Active Directory との統合

Identity Management は有効な 同期機能 を使用して、Active Directory ドメインと、IdM ドメインに格納されているユーザーデータを統合します。パスワードなどの重要なユーザー属性はサービス間で同期されます。
Active Directory と IdM ドメインの同期機能は、IdM サーバーが初回インストール時に継承されます。同期プロセスは、IdM サーバーと Active Directory ドメインコントローラーとの間で 合意 を作成して設定します。
本章では、同期の設定方法、Active Directory と IdM を統合する設定方法、および Active Directory ドメイン内にある Windows システムで IdM ドメインを認識させる設定方法について説明します。

15.1. サポート対象の Windows プラットフォーム

エントリーの同期は、Windows サーバーに接続してそこからディレクトリーデータを取得するのにフックを使用するレプリケーションと同様のプロセスで実行されます。
パスワードの同期は、Windows サーバーにインストールされ、Identity Management サーバーと通信する Windows サービスで実行されます。
次の Windows サーバーでは、エントリーとパスワードの両方の同期がサポートされています。
  • Windows Server 2008 R2
  • Windows Server 2012 R2
パスワード同期サービスで Windows と連携するバージョンは 1.1.5 です。これは、Red Hat Network の Red Hat Directory Server のダウンロードの部分で利用できます。

15.2. Active Directory および Identity Management の概要

IdM ドメイン内では、情報はデータマスター (サーバーとレプリカ) 間で信頼性と予測性のある方法でコピーされ、複数のサーバーとレプリカ間で共有されます。このプロセスを レプリケーション といいます。
同様のプロセスは、IdM ドメインと Microsoft Active Directory ドメイン間でデータを共有するために使用できます。これが 同期 です。
同期は、Active Directory と Identity Management の間で、ユーザーデータをコピーするプロセスのことです。
同期は、IdM サーバーと Active Directory ドメインコントローラー間の 合意 で定義されます。同期合意は、同期可能なユーザーエントリー (同期するサブツリーや、ユーザーエントリーで必須のオブジェクトクラスなど) を特定するのに必要な全情報、アカウント属性の処理方法を定義します。同期合意は、デフォルト値で作成されますが、特定ドメインのニーズに合わせて調整が可能です。2 つのサーバーで同期が行われる場合に、この 2 つのサーバーは ピアと呼ばれます。
同期は通常、双方向 で行われます。情報は、IdM ドメインと Windows ドメイン間で送受信され、このプロセスは IdM サーバーとレプリカが情報を共有する方法によく似ています。同期は、1 方向のみで行われるように設定することもできます。これは 一方向 の同期と呼ばれます。
データの競合が発生しないように、1 つの Identity Management サーバーと 1 つの Active Directory ドメインコントローラーの間で同期が設定されます。Identity Management サーバーは変更を IdM ドメインに伝播し直し、ドメインコントローラーは変更を Windows ドメインに伝播し直します。
IdM 同期には、以下のような主要な機能があります。
  • 同期操作は 5 分ごとに実行されます。
  • 同期が設定できるのは、Active Directory ドメイン 1 つのみとなっています。複数のドメインには対応していません。
  • 同期が設定できるのは、Active Directory ドメイン 1 つ のみとなっています。
  • ユーザー情報のみが同期されます。
  • ユーザー属性とパスワードの両方を同期することができます。
  • 変更は双方向ですが (Active Directory から IdM、IdM から Active Directory の両方)、アカウントの作成または追加は、Active Directory から Identity Management への一方向のみになります。新しいアカウントが Active Directory に作成されると、自動的に IdM に対して同期されます。ただし、ユーザーアカウントを IdM で作成した場合には、同期の前に Active Directory にも作成する必要があります。
  • アカウントロック情報はデフォルトで同期され、1 つのドメインで無効にされているユーザーアカウントは他方のドメインでも無効にされます。
  • パスワードの変更は即時に有効になります。
Active Directory ユーザーが IdM に同期される場合に、特定の属性 (Kerberos および POSIX 属性を含む) では IPA 属性がユーザーエントリーに自動的に追加されます。この属性は、ドメイン内で IdM が使用します。対応する Active Directory ユーザーエントリーには、同期されません。
同期プロセスの一環で、同期データの一部が変更される可能性があります。たとえば、IdM ドメインに同期する場合に、特定の属性を自動的に Active Directory ユーザーアカウントに追加できます。このような属性の変更は、同期合意の一部として定義します。これについては、「「ユーザーアカウント属性の同期動作の変更」」で説明されています。

15.3. 同期された属性の概要

Identity Management は、IdM と Active Directory ユーザーエントリーの間で、ユーザー属性のサブセットを同期します。エントリーに含まれる他の属性は、Identity Management または Active Directory のどちらにある場合でも、同期時に無視されます。
注記
ほとんどの POSIX 属性は同期されません。
Active Directory の LDAP スキーマと、Identity Management で使用される 389 Directory Server の LDAP スキーマ間には、スキーマは大きな異なりますが、属性は同じものが多数あります。このようなの属性は、Active Directory と IdM ユーザーエントリー間で同期されるだけで、属性名や値の形式には変更が加えられません。

Identity Management および Windows サーバーで同一のユーザースキーマ

  • cn[5]
  • physicalDeliveryOfficeName
  • description
  • postOfficeBox
  • destinationIndicator
  • postalAddress
  • facsimileTelephoneNumber
  • postalCode
  • givenname
  • registeredAddress
  • homePhone
  • sn
  • homePostalAddress
  • st
  • initials
  • street
  • l
  • telephoneNumber
  • mail
  • teletexTerminalIdentifier
  • mobile
  • telexNumber
  • o
  • title
  • ou
  • usercertificate
  • pager
  • x121Address
一部の属性には異なる名前が使用されていますが、IdM (389 Directory Server を使用) と Active Directory の間には直接的な対応関係があります。このような属性は、同期プロセスで マッピングされます
表15.1 Identity Management と Active Directory との間でマッピングされるユーザースキーマ
ID 管理 Active Directory
cn[a] name
nsAccountLock userAccountControl
ntUserDomainId sAMAccountName
ntUserHomeDir homeDirectory
ntUserScriptPath scriptPath
ntUserLastLogon lastLogon
ntUserLastLogoff lastLogoff
ntUserAcctExpires accountExpires
ntUserCodePage codePage
ntUserLogonHours logonHours
ntUserMaxStorage maxStorage
ntUserProfile profilePath
ntUserParms userParameters
ntUserWorkstations userWorkstations
[a] Identity Management から Active Directory に同期時には、cn は直接 (cn から cn へ) マッピングされます。Active Directory から同期すると、cn は、Active Directory の name 属性から Identity Management の cn 属性にマッピングされます。

15.3.1. Identity Management と Active Directory との間のユーザースキーマの相違点

属性が Active Directory と IdM の間で正常に同期される場合でも、Active Directory および Identity Management が基となる X.500 オブジェクトクラスを定義する方法には依然として違いがあり場合があります。この定義方法の相違点により、LDAP サービスが違うと、データの処理方法が異なる可能性があります。
このセクションでは、Active Directory および Identity Management のドメイン間で同期可能な属性を処理する方法に、Active Directory と Identity Management ではどのような違いがあるのかを説明します。

15.3.1.1. cn 属性の値

389 Directory Server では、cn 属性に複数の値を設定できますが、Active Directory ではこの属性には単一の値しか設定できせん。Identity Management の cn 属性が同期されると、単一の値のみが Active Directory ピアに送信されます。
これを同期との関連で見ると、cn 値が Active Directory エントリーに追加され、その値が Identity Management の cn の値のいずれでもない場合には、Identity Management のcn 値はすべて単一の Active Directory 値で上書きされます。
もう 1 つの重要な相違点として、Active Directory では cn 属性をその命名属性として使用するのに対し、Identity Management は uid を使用する点があります。つまり、cn 属性が Identity Management で編集する可能性がある場合には、エントリーの名前が完全に (および間違って) 変更されてしまう可能性があります。この cn の変更が Active Directory エントリーに書き込まれると、エントリーの名前が変更され、新しい名前のエントリーで Identity Management に書き込まれます。

15.3.1.2. street および streetAddress の値

Active Directory はユーザーの住所に streetAddress 属性を使用します。これは、389 Directory Server が street 属性を使用する方法に相当します。Active Directory および Identity Management が streetAddress および street 属性を使用する方法には 2 つの重要な相違点があります。
  • 389 Directory Server では、streetAddress は、 street のエイリアスです。Active Directory にも street 属性がありますが、streetAddress のエイリアスではなく、独立した値を保持することができる個別の属性です。
  • Active Directory は streetAddressstreet を単一値の属性として定義しますが、389 Directory Server は RFC 4519 に指定されているように street を複数値の属性として定義します。
389 Directory Server および Active Directory が streetAddress および street 属性を処理する方法が異なるため、Active Directory と Identity Management で address 属性を設定する場合には以下の 2 つのルールに従う必要があります。
  • 同期プロセスは、Active Directory エントリーの streetAddress から Identity Management の street にマッピングされます。競合を回避するために、street 属性は Active Directory では使用しないようにしてください。
  • Identity Management の street 属性値は 1 つだけ、Active Directory に同期されます。streetAddress 属性が Active Directory で変更され、新しい値が Identity Management に存在しない場合には、Identity Management のすべてのstreet 属性値が新しい Active Directory の値に置き換えられます。

15.3.1.3. initials 属性の制約

initials 属性の場合には、Active Directory は最大長 6 文字の制限を課しますが、389 Directory Serve には長さ制限がありません。Identity Management に 7 文字以上の initials 属性が 追加されると、この値は Active Directory エントリーとの同期時にカットされます。

15.3.1.4. surname (sn) 属性の要求

Active Directory では、surname 属性なしで person エントリーを作成できます。ただし、RFC 4519 では、person オブジェクトクラスには surname 属性が必要と定義されていますが、これは、Directory Server で使用される定義です。
Active Directory の person エントリーが surname 属性なしで作成される場合には、このエントリーは、オブジェクトクラス違反で失敗するため、IdM には同期されません。

15.3.2. Active Directory エントリーおよび RFC 2307 属性

Windows は、無作為に選択された一意の セキュリティー ID (SID) を使用してユーザーを特定します。これらの SID はブロックまたは範囲で割り当てられ、Windows ドメインでさまざまなシステムユーザータイプを特定します。Identity Management と Active Directory 間でユーザーの同期を行うと、ユーザーの Windows SID は、Identity Management エントリーで使用される Unix UID にマッピングされます。言い換えると、Windows SID は Windows エントリーで唯一の ID で、対応の UNIX エントリーでは ID としてマッピングに使用されます。
Active Directory ドメインが Unix 形式のアプリケーションまたはドメインと対話すると、Active Directory ドメインは Unix または Unix のサービスを使用して Unix 形式の uidNumber および gidNumber 属性を有効化できます。これにより、Windows ユーザーエントリーは RFC 2307 のこれらの属性の仕様に準拠できます。
ただし、uidNumber および gidNumber 属性は、Identity Management エントリーの uidNumber および gidNumber 属性として実際には使用されません。Identity Management の uidNumbergidNumber 属性は、Windows ユーザーの同期時に生成されます。
注記
Identity Management で定義され、使用される uidNumber および gidNumber 属性は、Active Directory エントリーで定義され、使用される uidNumbergidNumber 属性とは異なり、数字にも関連性はありません。


[5] cn は、他の同期属性とは異なる処理がされます。Identity Management から Active Directory に同期時には、直接 (cn から cn へ) マッピングされます。ただし、Active Directory から Identity Management に同期する場合には、cn は、Windows の name 属性から Identity Management の cn 属性にマッピングされます。

15.4. 同期用の Active Directory の設定

ユーザーアカウントのみの同期が IdM で有効になっているので、必要な操作は同期合意 (「同期合意の作成」) の設定だけです。ただし、Active Directory は、Identity Management サーバーが接続できるように設定する必要があります。

15.4.1. 同期用の Active Directory ユーザーの作成

Windows サーバーでは、IdM サーバーが Active Directory ドメインに接続するために使用するユーザーを作成する必要があります。
Active Directory でのユーザー作成プロセスは、Windows サーバーの文書 ( http://technet.microsoft.com/en-us/library/cc732336.aspx) で説明されています。新規のユーザーアカウントには適切な権限を設定する必要があります。
  • 同期用のユーザーアカウントには、同期先の Active Directory サブツリーに対して ディレクトリーに加えられた変更を複製する 権限を付与します。同期用のユーザーが同期操作を行うには、レプリケーターの権限が必要です。
    レプリケーターの権限は、http://support.microsoft.com/kb/303972 で説明されています。
  • 同期ユーザーを Account Operator および Enterprise Read-only Domain Controller グループのメンバーとして追加します。このユーザーは、全 Domain Admin グループに所属する必要はありません。

15.4.2. Active Directory 認証局の設定

Identity Management サーバーは、セキュアな接続を使用して Active Directory サーバーに接続します。この接続には、Active Directory サーバーで利用可能な CA 証明書または CA 証明書チェーンがあることが条件となります。これらの証明書を Identity Management セキュリティーデータベースにインポートして、Windows サーバーを、信頼されるピアとなるように設定できます。
これは技術的には (Active Directory に対して) 外部の CA で実行できますが、大半のデプロイでは Active Directory で利用可能な証明書サービスを使用する必要があります。
Active Directory での証明書サービスの設定、構成手順は、Microsoft のドキュメント (http://technet.microsoft.com/en-us/library/cc772393(v=WS.10).aspx) に記載されています。

15.5. 同期合意の管理

15.5.1. Active Directory および IdM CA 証明書の信頼

Active Directory と Identity Management の両方で、サーバー認証に証明書が使用されます。Active Directory と IdM SSL サーバーの証明書を相互に信頼させるには、これらの証明書の発行元である CA の CA 証明書を、両サーバーで信頼する必要があります。つまり、Active Directory CA 証明書を IdM データベースにインポートし、IdM CA 証明書を Active Directory データベースにインポートする必要があります。
  1. Active Directory サーバーで、http://ipa.example.com/ipa/config/ca.crt から IdM サーバーの CA 証明書をダウンロードします。
  2. Active Directory 証明書データベースに IdM CA 証明書をインストールします。これは、Microsoft 管理コンソールまたは certutil ユーティリティー を使用して実行できます。以下に例を示します。
    certutil -installcert -v -config "ipaserver.example.com\Example Domain CA" c:\path\to\ca.crt
    詳細は、Active Directory のドキュメントを参照してください。
  3. Active Directory CA 証明書をエクスポートします。
    1. My Network Places で CA の配信ポイントを開きます。
    2. セキュリティー証明書ファイル (.crt ファイル) をダブルクリックして、証明書 ダイアログボックスを表示します。
    3. 詳細 タブで、 ファイルにコピー をクリックして 証明書のエクスポートウィザード を起動します。
    4. 次へ をクリックしてから、Base-64 encoded X.509 (.CER) を選択します。
    5. エクスポートされたファイルに適切なディレクトリーおよびファイル名を指定します。Next をクリックして証明書をエクスポートし、Finish をクリックします。
  4. Active Directory 証明書を IdM サーバーマシンにコピーします。
  5. IdM サーバーの CA 証明書を http://ipa.example.com/ipa/config/ca.crt からダウンロードします。
  6. Active Directory CA 証明書と IdM CA 証明書の両方を /etc/openldap/cacerts/ ディレクトリーにコピーします。
  7. 証明書のハッシュシンボリックリンクを更新します。
    cacertdir_rehash /etc/openldap/cacerts/
  8. /etc/openldap/ldap.conf ファイルを編集して、/etc/openldap/cacerts/ ディレクトリーの証明書を参照および使用するための情報を追加します。
    TLS_CACERTDIR /etc/openldap/cacerts/
    TLS_REQCERT allow

15.5.2. 同期合意の作成

同期合意は、Active Directoryドメインへの 接続 を作成するため、IdM サーバー上では ipa-replica-manage connect コマンドを使用して作成します。同期合意の作成オプションは、表15.2「同期合意のオプション」に記載されています。
  1. Active Directory サーバーと IdM サーバーが、「Active Directory および IdM CA 証明書の信頼」にあるように相互の CA 証明書を信頼していることを確認してください。
  2. IdM サーバー上の既存の Kerberos 資格情報を削除します。
    $ kdestroy
  3. ipa-replica-manage コマンドを使用して Windows 同期合意を作成します。これには、--winsync オプションが必要です。パスワードとユーザーアカウントを同期する場合は、--passsync オプションも使用して、パスワード同期に使用するパスワードを設定します。
    --binddn および --bindpwd オプションを指定すると、IdM が Active Directory サーバーへの接続に使用する Active Directory サーバー上のシステムアカウントにユーザー名およびパスワードを設定します。
    $ ipa-replica-manage connect --winsync 
    	--binddn cn=administrator,cn=users,dc=example,dc=com 
    	--bindpw Windows-secret 
    	--passsync secretpwd 
    	--cacert /etc/openldap/cacerts/windows.cer  
    	adserver.example.com -v
  4. プロンプトが出されたら、Directory Manager のパスワードを入力します。
  5. 任意。「パスワード同期のセットアップ」 に説明されているようにパスワードの同期を設定します。
表15.2 同期合意のオプション
オプション Description
--winsync 同期合意として指定します。
--binddn 同期 ID の完全なユーザーの DN を指定します。これは、IdM LDAP サーバーが Active Directory にバインドするために使用するユーザーの DN です。このユーザーは Active Directory ドメインに存在しており、Active Directory サブツリーに replicator、read、search、write のパーミッションが必要です。
--bindpw 同期ユーザーのパスワードを指定します。
--passsync 同期を行う Windows ユーザーアカウントのパスワードを指定します。
--cacert Active Directory CA 証明書の完全パスおよびファイル名を指定します。この証明書は、「Active Directory および IdM CA 証明書の信頼」にエクスポートされます。
--win-subtree 同期するユーザーが含まれる Windows ディレクトリーサブツリーの DN を指定します。デフォルト値は cn=Users,$SUFFIX です。
AD_server_name Active Directory ドメインコントローラーのホスト名を指定します。

15.5.3. ユーザーアカウント属性の同期動作の変更

同期合意が作成されると、同期プロセスでのユーザーアカウント属性の処理方法に関して特定のデフォルト動作が定義されます。動作のタイプには、ロックアウト属性の処理方法や異なる DN 形式の処理方法などが含まれます。この動作は、同期合意を編集することで変更できます。属性関連のパラメーターの一覧は、表15.3「同期属性の設定」にあります。
同期合意は LDAP サーバーの特殊なプラグインエントリーとして存在し、それぞれの属性動作は LDAP 属性から設定されます。同期の動作を変更するには、ldapmodify コマンドを使用して LDAP サーバーのエントリーを直接変更します。
たとえば、デフォルトで IdM と Active Directory との間のアカウントロックアウト属性が同期されますが、ipaWinSyncAcctDisable 属性を編集すると無効にできます。(この属性を変更すると、Active Directory でアカウントが無効な場合でも、IdM で引き続き有効な状態となり、その逆も同様になります)。
[jsmith@ipaserver ~]$ ldapmodify -x -D "cn=directory manager" -w password

dn: cn=ipa-winsync,cn=plugins,cn=config
changetype: modify
replace: ipaWinSyncAcctDisable
ipaWinSyncAcctDisable: none

modifying entry "cn=ipa-winsync,cn=plugins,cn=config"
表15.3 同期属性の設定
パラメーター 説明 設定可能な値
一般ユーザーアカウントのパラメーター 
ipaWinSyncNewEntryFilter 新規ユーザーエントリーに追加するオブジェクトクラスの一覧を含むエントリーの検索に使用する検索フィルターを設定します。 デフォルトでは (cn=ipaConfig) です。
ipaWinSyncNewUserOCAttr 新規ユーザーエントリーに追加するオブジェクトクラスの一覧が実際に含まれる設定エントリーの属性を設定します。 デフォルトは ipauserobjectclasses です。
ipaWinSyncHomeDirAttr POSIX ホームディレクトリーのデフォルトの場所を含むエントリー内の属性を識別します。 デフォルトは ipaHomesRootDir です。
ipaWinSyncUserAttr Active Directory ユーザーを Active Directory ドメインから同期する時に、特定の値で別の属性を設定してAD ユーザーに追加します。複数値の属性の場合は、属性を複数回設定でき、同期プロセスで、値のすべてがエントリーに追加されます。
注記
エントリーに属性が存在しない場合に属性値のみが設定されます。属性が存在する場合は、Active Directory エントリーの同期時にエントリーの値が使用されます。
ipaWinSyncUserAttr: attributeName attributeValue
ipaWinSyncForceSync 同期できるように、既存の Active Directory ユーザーに一致する既存 IdM ユーザーを自動編集する必要があるかどうかを設定します。IdM ユーザーアカウントに既存の Active Directory の samAccountName と同じ uid パラメーターがある場合に、アカウントはデフォルトでは同期 されません。この属性は、同期サービスに対して、ntUser および ntUserDomainId を IdM ユーザーエントリーに自動的に追加し、同期されるように指示します。 true | false
ユーザーアカウントのロックパラメーター 
ipaWinSyncAcctDisable アカウントロックアウト属性を同期する方法を設定します。有効にするアカウントロックアウト設定を制御できます。たとえば、to_ad は、アカウントロックアウト属性が IdM に設定される場合に、その値が Active Directory に対して同期され、ローカルの Active Directory 値を上書きすることを意味します。デフォルトでは、アカウントロックアウト属性は両ドメインから同期されます。
  • both (デフォルト)
  • to_ad
  • to_ds
  • none
ipaWinSyncInactivatedFilter 非アクティブ化された (無効にされた) ユーザーを保持するために使用されるグループの DN 検索用のフィルターを設定します。これは、ほとんどの実装では変更する必要はありません。 デフォルトは (&(cn=inactivated)(objectclass=groupOfNames)) です。
ipaWinSyncActivatedFilter アクティブなユーザーを保持するために使用されるグループの DN 検索用のフィルターを設定します。これは、ほとんどの実装では変更する必要はありません。 デフォルトは (&(cn=activated)(objectclass=groupOfNames)) です。
グループのパラメーター 
ipaWinSyncDefaultGroupAttr ユーザーのデフォルトグループを確認するために参照する新規ユーザーアカウントの属性を設定します。その後、エントリーのグループ名がユーザーアカウントの gidNumber の検索に使用されます。 デフォルトは ipaDefaultPrimaryGroup です。
ipaWinSyncDefaultGroupFilter 検索フィルターを設定して、グループ名を POSIX の gidNumber にマッピングします。 デフォルトは (&(gidNumber=*)(objectclass=posixGroup)(cn=groupAttr_value)) です。
レルムのパラメーター 
ipaWinSyncRealmAttr レルムエントリーにレルム名を含む属性を設定します。 デフォルトは cn です。
ipaWinSyncRealmFilter IdM レルム名を含むエントリーの検索に使用する検索フィルターを設定します。 デフォルトは (objectclass=krbRealmContainer) です。

15.5.4. 同期された Windows サブツリーの変更

同期合意を作成すると、同期されたユーザーデータベースとして使用する 2 つのサブツリーが自動設定されます。IdM の場合、デフォルトは cn=users,cn=accounts,$SUFFIX となり、Active Directory の場合、デフォルトは CN=Users,$SUFFIX となります。
--win-subtree オプションを使用して同期合意が作成されると、Active Directory サブツリーの値はデフォルト以外の値に設定できます。この合意の作成後に、ldapmodify コマンドを使用し、同期合意エントリー内の nsds7WindowsReplicaSubtree 値を編集して Active Directory サブツリーを変更できます。
  1. ldapsearch を使用して、同期合意の名前を取得します。この検索は、エントリー全体ではなく、dn および nsds7WindowsReplicaSubtree 属性の値のみを返します。
    [jsmith@ipaserver ~]$ ldapsearch -xLLL -D "cn=directory manager" -w password -p 389 -h ipaserver.example.com -b cn=config objectclass=nsdswindowsreplicationagreement dn nsds7WindowsReplicaSubtree
    
    dn: cn=meToWindowsBox.example.com,cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config
    nsds7WindowsReplicaSubtree: cn=users,dc=example,dc=com
    
    ... 8< ...
  2. 同期合意の変更
    [jsmith@ipaserver ~]$ ldapmodify -x -D "cn=directory manager" -W -p 389 -h ipaserver.example.com <<EOF
     dn: cn=meToWindowsBox.example.com,cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config
     changetype: modify
     replace: nsds7WindowsReplicaSubtree
     nsds7WindowsReplicaSubtree: cn=alternateusers,dc=example,dc=com
     EOF
    
     modifying entry "cn=meToWindowsBox.example.com,cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config"
新規のサブツリー設定は即時に有効になります。同期操作が実行中の場合は、現在の操作が完了するとすぐに有効になります。

15.5.5. 一方向同期の設定

デフォルトでは、すべての変更および削除は双方向で行われます。Active Directory の変更が Identity Management に同期され、Identity Management のエントリーへの変更が Active Directory に同期されます。基本的にこれは、同等のマルチマスターの関係で、Active Directory と Identity Management はどちらも同期時は同等のピアであり、データマスターでもあります。
ただし一部のデータ構造または IT デザインでは、一方のドメインのみをデータマスターとし、他方のドメインでは更新を受け入れられるようにする必要があります。この場合には、マルチマスターの関係 (ピアサーバーが同等) からマスター対コンシュマーの関係に同期関係が変更されます。
これには、同期合意に oneWaySync パラメーターを設定します。使用可能な値は、fromWindows (Active Directory から Identity Management への同期) と toWindows (Identity Management から Active Directory の同期) です。
たとえば、Active Directory から Identity Management への変更を同期するには、次のコマンドを実行します。
[jsmith@ipaserver ~]$ ldapmodify -x -D "cn=directory manager" -w password -p 389 -h ipaserver.example.com

dn: cn=windows.example.com,cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config
changetype: modify
add: oneWaySync
oneWaySync: fromWindows
重要
一方向同期を有効にすると、同期されていないサーバーで自動的に変更ができなくなる わけではないため、同期更新間の同期ピア間で不整合が生じる可能性があります。たとえば、一方向同期は Active Directory から Identity Management に送信されるように設定されるので、(基本的には) Active Directory がデータマスターになります。Identity Management でエントリーを変更または削除すると、Identity Management の情報が異なるため、その変更は Active Directory に引き継がれなくなります。次の同期更新時に、編集内容は Directory Server で上書きされ、エントリーを削除していても再び追加されます。

15.5.6. 同期合意の削除

同期を停止するには、同期合意を削除し、IdM と Active Directory サーバーの接続を 切断 します。同期合意の作成とは逆で、同期合意の削除には、ipa-replica-manage disconnect コマンドと Active Directory サーバーのホスト名を使用します。
  1. 同期合意を削除します。
    # ipa-replica-manage disconnect adserver.example.com
  2. IdM サーバーのデータベースから Active Directory CA 証明書を削除します。
    # certutil -D -d /etc/dirsrv/slapd-EXAMPLE.COM/ -n "Imported CA"

15.5.7. Winsync 合意のエラー

Active Directory サーバーに接続できないため、同期合意の作成に失敗します。

同期合意での最も一般的なエラーの 1 つとして、IdM サーバーが Active Directory サーバーに接続できない点が挙げられます。

"Update failed! Status: [81  - LDAP error: Can't contact LDAP server]

これは、合意の作成時に正しくない Active Directory CA 証明書が指定される場合に生じる可能性があります。これにより、IdM LDAP データベース (/etc/dirsrv/slapd-DOMAIN/ ディレクトリー内) に Imported CA という名前で重複した証明書が作成されます。これは、certutil を使用して確認できます。
$ certutil -L -d /etc/dirsrv/slapd-DOMAIN/

Certificate Nickname                                         Trust Attributes
SSL,S/MIME,JAR/XPI

CA certificate                                               CTu,u,Cu
Imported CA                                                  CT,,C
Server-Cert                                                  u,u,u
Imported CA                                                  CT,,C
この問題を解決するには、証明書データベースを削除します。
# certutil -d /etc/dirsrv/slapd-DOMAIN-NAME -D -n "Imported CA"
これにより、LDAP データベースから CA 証明書が削除されます。

エントリーが存在することを示すため、パスワードが同期されていないことを示すエラーがあります。

ユーザーデータベースの一部のエントリーについて、エントリーがすでに存在するためにパスワードはリセットされないという情報のエラーメッセージが表示される可能性があります。

"Windows PassSync entry exists, not resetting password"
これはエラーではありません。このメッセージは、適用除外ユーザー、パスワード同期ユーザーが変更されていない場合に生じます。パスワード同期ユーザーは、ldM でパスワードを変更するためにサービスで使用される操作上のユーザーです。

15.6. パスワード同期の管理

ユーザーエントリーの同期が同期合意と設定されている。ただし、Active Directory と Identity Management の両方のパスワードは保存時にハッシュ化され、ユーザー同期プロセスの一部として復号化できません。ユーザーアカウントの作成またはパスワードの変更時にパスワードを取り込み、同期更新でそのパスワード情報を転送できるようにするには、別のクライアントが Active Directory サーバー上にインストールされる必要があります。
重要
IdM は現在、ユーザーアカウントの初期パスワード同期に対応していないことに注意してください。IdM にパスワードを同期するには、最初にパスワードを手動で変更する必要があります。

15.6.1. パスワード同期のための Windows Server のセットアップ

パスワードの同期には、以下の 2 つの項目が必要です。
  • Active Directory が SSL で実行されている必要があります。
  • パスワード同期サービスは、 Active Directory ドメインコントローラーにインストールする必要があります。
パスワード同期サービスは、パスワードの変更を記録し、セキュアな接続で IdM エントリーに同期します。
ヒント
エンタープライズルートモードで Microsoft Certificate System をインストールします。Active Directory は自動的に登録され、SSL サーバー証明書を取得します。
  1. Active Directory パスワードの複雑さのポリシーが有効になっていることを確認し、パスワード同期サービスを実行します。
    1. コマンドライン secpol.msc から実行します。
    2. セキュリティー設定 を選択します。
    3. アカウントポリシー を開き、パスワードポリシーを開きます。
    4. Password must meet complexity requirements オプションを有効にし、保存します。
  2. SSL がまだ有効になっていない場合は、Active Directory サーバーに SSL を設定します。LDAPS の設定に関する詳細は、http://support.microsoft.com/kb/321051 の Microsoft ナレッジベースを参照してください。
    1. プログラムの 追加/削除Windows コンポーネント セクションに認証局をインストールします。
    2. Enterprise Root CA オプションを選択します。
    3. Active Directory サーバーを再起動します。IIS Web サービスを実行している場合は、http://servername/certsrv を開いて CA 証明書にアクセスできます。
    4. SSL サーバー証明書を使用するように Active Directory サーバーを設定します。
      1. Active Directory の完全修飾ドメイン名を証明書サブジェクトとして使用し 、証明書要求 .inf を作成します。たとえば、以下のようになります。
        ;----------------- request.inf ----------------- 
        
        [Version] 
        
        Signature="$Windows NT$ 
        
        [NewRequest]
        
        Subject = "CN=ad.server.example.com, O=Engineering, L=Raleigh, S=North Carolina, C=US"
        KeySpec = 1 
        KeyLength = 2048 
        Exportable = TRUE 
        MachineKeySet = TRUE 
        SMIME = False 
        PrivateKeyArchive = FALSE 
        UserProtected = FALSE 
        UseExistingKeySet = FALSE 
        ProviderName = "Microsoft RSA SChannel Cryptographic Provider" 
        ProviderType = 12
        RequestType = PKCS10 
        KeyUsage = 0xa0 
        
        [EnhancedKeyUsageExtension] 
        
        OID=1.3.6.1.5.5.7.3.1 
        
        ;-----------------------------------------------
        .inf リクエストファイルの詳細は、http://technet.microsoft.com/en-us/library/cc783835.aspx などの Microsoft ドキュメントを参照してください。
      2. 証明書要求を生成します。
        certreq -new request.inf request.req
      3. Active Directory CA にリクエストを送信します。以下に例を示します。
        certreq -submit request.req certnew.cer
        注記
        コマンドラインツールがエラーメッセージを返す場合は、Web ブラウザーを使用して CA にアクセスし、証明書要求を送信します。IIS が実行されている場合、CA URL は http://servername/certsrv になります。
      4. 証明書要求を受け入れます。以下に例を示します。
        certreq -accept certnew.cer
      5. サーバー証明書が Active Directory サーバーに存在していることを確認します。
        File メニューで Add/Remove をクリックし、CertificatesPersonal>Certificates をクリックします。
      6. Directory Server から Active Directory に CA 証明書をインポートします。Trusted Root CA をクリックし、続いて Import をクリックして Directory Server CA 証明書を参照します。
    5. ドメインコントローラーを再起動します。

15.6.2. パスワード同期のセットアップ

Windows パスワードを同期するために、Active Directory ドメインのすべてのドメインコントローラーにパスワード同期サービスをインストールします。
  1. Active Directory マシンに PassSync.msi ファイルをダウンロードします。
    1. カスタマーポータルにログインします。
    2. Downloads タブをクリックします。
    3. ページの中心の Red Hat Enterprise Linux ダウンロードボタンをクリックします。
    4. Directory Server などの検索用語を使用してダウンロードをフィルタリングし、Red Hat Enterprise Linux バージョンの 1 つを展開します。
    5. Directory Server のリンクをクリックします。
    6. Directory Server ページで、WinSync Installer の適切なバージョンをダウンロードします。これは、パスワード同期 MSI ファイル (RedHat-PassSync-1.1.5-arch.msi) です。
    注記
    Red Hat Enterprise Linux アーキテクチャーに関係なく、32 ビットの Windows サーバー用と 64 ビット用にそれぞれ PassSync パッケージが 2 つあります。Windows プラットフォームに適したパッケージを選択してください。
  2. Password Sync MSI ファイルをダブル