Linux ドメイン ID、認証、およびポリシーガイド
Linux 環境での Red Hat Identity Management の使用
概要
『システムレベルの認証ガイド』 は、ローカルシステム上で認証設定に使用可能な異なるアプリケーションやサービスについて説明しています。これには、 authconfig ユーティリティーや System Security Services Daemon (SSSD) サービス、プラグ可能な認証モジュール (PAM) フレームワーク、Kerberos、certmonger ユーティリティー、アプリケーション用のシングルサインオン (SSO) などがあります。
『Windows 統合ガイド』では、Identity Management を使って Linux ドメインと Microsoft Windows Active Directory (AD) を統合する方法について説明しています。また、直接および間接的 AD 統合の側面、SSSD を使って Commong Internet File System (CIFS) にアクセスする方法、realmd システムなどについて説明しています。
パート I. Red Hat Identity Management の概要
第1章 Red Hat Identity Management について
1.1. Red Hat Identity Management のゴール
- Linux オペレーティングシステム環境の高度な機能
- Linux マシンの大規模なグループの一元化
- Active Directory を使用したネイティブな統合
- IdM は、既存のネイティブ Linux ツールとプロトコルを基礎とします。独自のプロセスと設定がありますが、その基礎となるテクノロジーは Linux システム上で十分に確立されおり、Linux 管理者から信頼されています。
- IdM サーバーとクライアントは、Red Hat Enterprise Linux マシンです。IdM は直接的には Windows クライアントに対応していませんが、Active Directory 環境との統合が可能になっています。
注記
本ガイドでは、Linux 環境における IdM の使用についてのみ説明しています。Active Directory との統合に関する詳細情報は、『Windows 統合ガイド』 を参照してください。Samba スイートを使用すると Linux マシンと Active Directory 環境との統合が可能になります。このスイートについての詳細は、『Windows 統合ガイド』 の Samba、Kerberos、および Winbind の使用の章を参照してください。
1.1.1. IdM による利点
- 複数の Linux サーバーにおけるアイデンティティーおよびポリシーの管理
- IdM なしの場合: 各サーバーが個別に管理されます。パスワードはすべてローカルマシンに保存されます。IT 管理者は各マシン上でユーザーを管理し、個別に認証および承認ポリシーを設定し、ローカルのパスワードを維持します。IdM を使用した場合: IT 管理者は以下が可能になります。
- IdM サーバーという1カ所でアイデンティティーを管理。
- 複数のマシンに同時にポリシーを均一に適用。
- ホストベースのアクセス制御、委任、および他のルールを使用してユーザーに異なるアクセスレベルを設定。
- 権限昇格ルールの一元管理。
- ホームディレクトリーのマウント方法の定義。
- エンタープライズシングルサインオン
- IdM なしの場合: ユーザーはシステムにログインし、サービスやアプリケーションにアクセスする度にパスワードを求められます。これらのパスワードは同じものではない場合もあり、ユーザーは各アプリケーションごとに使用する認証情報を覚えている必要があります。IdM を使用した場合: ユーザーはシステムにログインすると、認証情報を繰り返し聞かれることなく、複数のサービスやアプリケーションにアクセスできます。これにより、以下が可能になります。
- ユーザビリティーの向上
- パスワードを書き留めたり安全でない場所に保存したりするセキュリティーリスクの低減
- ユーザーの生産性向上
- Linux と Windows の混合環境の管理
- IdM なしの場合: Windows システムは Active Directory フォレストで管理されますが、開発、実稼働や他のチームには多くの Linux システムがあり、これらの Linux システムは Active Directory 環境から除外されます。IdM を使用した場合: IT 管理者は以下が可能になります。
- ネイティブの Linux ツールを使った Linux システムの管理
- Linux システムと Windows システムの統合。これにより一元化されたユーザーストアが保持されます。
- Linux ベースを容易に拡大
- Linux と Active Directory マシンを別個に管理し、Linux と Windows 管理者が各自の環境を直接制御できます。
1.1.2. Identity Management と標準 LDAP ディレクトリーの比較
- スキーマ: ユーザー、マシン、ネットワークエンティティー、物理的設備、建物といった非常に幅広いエントリー用にカスタマイズ可能な柔軟性のあるスキーマです。
- 典型的な使用例: インターネット上でサービスを提供するビジネスアプリケーションなど、他のアプリケーションのデータを保存するバックエンドのディレクトリーとして使用。
- スキーマ: ユーザーやマシンの ID のエントリーといった特定の目的に関連するエントリーセットを定義する特定のスキーマです。
- 典型的な使用例: 企業やプロジェクトの境界内におけるアイデンティティーを管理する ID および認証サーバー。
その他のリソース
- 『Red Hat Enterprise Linux Blog』 上での Identity Management or Red Hat Directory Server – Which One Should I Use? ブログ記事。
1.2. Identity Management ドメイン
- IdM サーバー。ドメインコントローラーとして機能します。
- IdM クライアント。これはサーバーに登録されます。
注記
1.2.1. Identity Management サーバー
1.2.1.1. IdM サーバーでホストするサービス
- Kerberos KDC
- IdM は、Kerberos プロトコルを使ってシングルサインオンをサポートします。Kerberos を使用すると、ユーザーは正しいユーザー名とパスワードを 1 回提示するだけで済みます。この後は、システムが認証情報をプロンプトすることなく IdM サービスにアクセスできます。
- Kerberos の機能方法については、システムレベルの認証ガイド を参照してください。
- Kerberos を使用した IdM への認証方法については、「Kerberos を使用した IdM へのログイン」 を参照してください。
- IdM での Kerberos の管理については、28章Kerberos ドメインの管理 を参照してください。
- LDAP ディレクトリーサーバー
- IdM には内部の LDAP ディレクトリーサーバーが含まれており、ここには Kerberos 関連の情報、ユーザーアカウント、ホストエントリー、サービス、ポリシー、DNSなどの全 IdM 情報が保存されます。LDAP ディレクトリーサーバーインスタンスは Red Hat Directory Server と同じテクノロジーをベースとしていますが、IdM 固有のタスクに調整されています。
注記
本ガイドでは、このコンポーネントを Directory Server と呼びます。 - 認証局
- ほとんどのデプロイメントでは、統合済み認証局 (CA) が IdM サーバーとインストールされます。必要な証明書すべてを独自に作成し、提供する場合は、統合 CA なしでサーバーをインストールすることもできます。
- 異なる CA 設定で IdM サーバーをインストールする詳細情報は、「CA 設定の決定」 を参照してください。
注記
本ガイドでは、実装の際にはこのコンポーネントを Certificate System と呼び、実装によるサービスに対応する際には証明局と呼びます。 - ドメインネームシステム (DNS)
- IdM は、動的なサービス発見に DNS を使用します。IdM クライアントインストールユーティリティーは、DNS からの情報を使ってクライアントマシンを自動的に設定することができます。クライアントが IdM ドメインに登録されたら、DNS を使用してドメイン内の IdM サーバーとサービスを検索します。
- サービス検索に関する詳細情報は、システムレベルの認証ガイド を参照してください。
- IdM における DNS の使用と重要な前提条件については、「ホスト名および DNS の設定」 を参照してください。
- 統合 DNS ありまたはなしで IdM サーバーをインストールする詳細情報については、「統合 DNS 使用の判断」 を参照してください。
- ネットワークタイムプロトコルサーバー (NTP)
- 多くのサービスでは、特定の差異内でサーバーとクライアントが同一のシステムタイムを保持している必要があります。たとえば、Kerberos チケットはタイムスタンプを使ってその有効性を判断し、再生攻撃を防ぎます。サーバーとクライアントの時間の差異が許可された範囲内から逸脱すると、Kerberos チケットは無効になります。デフォルトでは、IdM はネットワークタイムプロトコル (NTP) を使ってネットワークからクロックを同期します。NTP を使用すると、中央サーバーが権威クロックとして機能し、クライアントはこのサーバークロックに一致するようそれぞれの時間を同期します。サーバーのインストールプロセス中は、IdM サーバーは IdM ドメイン向けの NTP サーバーとして設定されます。
注記
仮想マシン上にインストールされた IdM サーバーで NTP サーバーを稼働すると、環境によっては時間が正確に同期されない場合があります。この潜在的な問題を避けるには、仮想マシン上にインストールされた IdM サーバーで NTP を実行しないでください。仮想マシン上における NTP サーバーの信頼性については、こちらのナレッジベースソリューションを参照してください。

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

図1.2 IdM サービス間の対話
パート II. Identity Management のインストール
第2章 Identity Management サーバーのインストールとアンインストール
- 必要なパッケージをインストールします。
- 設定スクリプトを使用してマシンを設定します。
2.1. サーバーインストールの前提条件
2.1.1. ハードウェア推奨事項
- 10,000 ユーザーおよび 100 グループには、最低 2GB の RAM と 1GB のスワップスペースを割り当てます。
- 100,000 ユーザーおよび 50,000 グループには、最低 16GB の RAM と 4GB のスワップスペースを割り当てます。
注記
2.1.2. システム要件
/var/lib/ipa/sysrestore/ に作成します。
- 連邦情報処理標準 (FIPS: Federal Information Processing Standard) のサポート
- Red Hat Enterprise Linux 7.4 以降を使用して設定した環境の場合:
- FIPS モードを有効化したシステムで、新規の IdM サーバー、レプリカまたはクライアントを設定できます。インストールスクリプトでは、管理者の介入なしに、自動的に FIPS が有効化されているシステムを検出し、IdM を設定します。オペレーティングシステムで FIPS を有効化するには、『セキュリティーガイド』の「FIPS モードの有効化」を参照してください。
重要
以下の点に注意してください。- FIPS モードを無効にしてインストールした既存の IdM サーバーで FIPS モードを有効にすることはできません。
- FIPS モードが無効になっている既存の IdM サーバーに FIPS サポートを有効にした新規レプリカをインストールすることはできません。
Red Hat Enterprise Linux 7.3 以前を使用して設定した環境の場合:- IdM では、FIPS モードはサポートされません。システム上で FIPS を無効化してから、IdM サーバー、レプリカまたはクライアントをインストールし、インストール後も有効化しないでください。
FIPS モードに関する詳しい情報は『セキュリティーガイド』の「連邦情報処理標準 (FIPS: Federal Information Processing Standard)」を参照してください。 - Name Service Cache Daemon (NSCD) の要件
- Red Hat では、Identity Management マシン上で NSCD を無効にすることを推奨しています。NSCD を無効にできない場合は、代わりに SSSD がキャッシュを行わないマッピングに対して NSCD を有効化するようにしてください。NSCD と SSSD の両サービスはキャッシングを実行するので、これら両方をシステムが同時に使用すると問題が発生します。NSCD と SSSD の競合を避ける方法については、「システムレベルの認証ガイド」を参照してください。
- IPv6 がシステムで有効になっている必要がある
- IdM サーバーをインストールして実行するには、IPv6 がネットワーク上で有効になっている必要があります。Red Hat Enterprise Linux 7 システムではデフォルトで IPv6 が有効になることに留意してください。IPv6 を無効にしている場合は、Red Hat ナレッジベースの Red Hat Enterprise Linux で IPv6 プロトコルを無効または有効にする を参照して有効にします。
2.1.3. ホスト名および DNS の設定
警告
- テスト済みの機能する DNS サービスが利用可能であること。
- サービスが適切に設定されていること。
注記
サーバーのホスト名の検証
server.example.com のように完全修飾ドメイン名である必要があります。使用中のマシンのホスト名を確認するには、hostname ユーティリティーを使用します。
[root@server ~]# hostname server.example.com
hostname の出力は、localhost または localhost6 になってはいけません。
重要
127.0.0.1 に解決してはいけません。
正引きおよび逆引き DNS 設定の確認
- サーバーの IP アドレスを取得します。
ip addr showコマンドは、IPv4 と IPv6 の両方のアドレスを表示します。- IPv4 アドレスは、
inetで始まる行に表示されます。以下の例では、設定済み IPv4 アドレスは192.0.2.1になります。 - IPv6 アドレスは
inet6で始まる行に表示されます。scope globalのある IPv6 のみがこの手順では関連してきます。以下の例では、返される IPv6 アドレスは2001:DB8::1111になります。
[root@server ~]# ip addr show ... 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 link/ether 00:1a:4a:10:4e:33 brd ff:ff:ff:ff:ff:ff inet 192.0.2.1/24 brd 192.0.2.255 scope global dynamic eth0 valid_lft 106694sec preferred_lft 106694sec inet6 2001:DB8::1111/32 scope global dynamic valid_lft 2591521sec preferred_lft 604321sec inet6 fe80::56ee:75ff:fe2b:def6/64 scope link valid_lft forever preferred_lft forever
digユーティリティーにホスト名を加えて、正引き DNS 設定を確認します。dig +short server.example.com Aコマンドを実行します。返される IPv4 アドレスは、ip addr showが返す IP アドレスと一致する必要があります。[root@server ~]# dig +short server.example.com A 192.0.2.1
dig +short server.example.com AAAAコマンドを実行します。コマンドがアドレスを返す場合は、ip addr showが返す IPv6 アドレスと一致する必要があります。[root@server ~]# dig +short server.example.com AAAA 2001:DB8::1111
注記
AAAA レコードの出力が返されない場合でも、設定が間違っているわけではありません。出力がないということは、DNS 内でサーバーマシン向けに IPv6 アドレスが設定されていないというだけのことです。ネットワークで IPv6 プロトコルを使用する予定がない場合は、この状況でもインストールを続行できます。
digユーティリティーに IP アドレスを加えて、逆引き DNS 設定 (PTR レコード) を確認します。dig +short -x IPv4 addressコマンドを実行します。サーバーのホスト名が出力に表示される必要があります。例を示します。[root@server ~]# dig +short -x 192.0.2.1 server.example.com
- 前のステップで
dig +short -x server.example.com AAAAコマンドが IPv6 アドレスを返した場合は、digを使って IPv6 アドレスもクエリします。ここでも、サーバーのホスト名が出力に表示される必要があります。例を示します。[root@server ~]# dig +short -x 2001:DB8::1111 server.example.com
注記
前のステップでdig +short -x server.example.com AAAAコマンドが IPv6 アドレスを返さなかった場合は、AAAA レコードのクエリは何も出力しません。これは正常な動作で、設定が間違っていることを示すものではありません。
前のステップでdig +short server.example.comが IP アドレスを返した場合でも、別のホスト名が表示されたりホスト名が表示されない場合は、逆引き DNS 設定が間違っていることになります。
DNS フォワーダーの標準準拠の確認
$ dig +dnssec @IP_address_of_the_DNS_forwarder . SOA
- status:
NOERROR - flags:
ra - EDNS flags:
do ANSWERセクションにはRRSIGレコードがある必要があります。
/etc/named.conf ファイルで dnssec-enable yes; オプションが設定されている必要があります。
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48655 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; ANSWER SECTION: . 31679 IN SOA a.root-servers.net. nstld.verisign-grs.com. 2015100701 1800 900 604800 86400 . 31679 IN RRSIG SOA 8 0 86400 20151017170000 20151007160000 62530 . GNVz7SQs [...]
/etc/hosts ファイル
重要
/etc/hosts ファイルは手動で変更しないでください。/etc/hosts を変更した場合は、コンテンツが以下のルールに準拠していることを確認してください。
/etc/hosts ファイルが正しく設定されている例です。ホストの IPv4 および IPv6 localhost エントリーが適切に表示され、最初のエントリーで IdM サーバーの IP アドレスとホスト名がその後に続いています。IdM サーバーのホスト名は localhost エントリーに含めることができない点に注意してください。
127.0.0.1 localhost.localdomain localhost ::1 localhost6.localdomain6 localhost6 192.0.2.1 server.example.com server 2001:DB8::1111 server.example.com server
2.1.4. ポート要件
- 必須ポートの一覧は、「必須ポート一覧」 を参照してください。
- 必須ポートに対応している
firewalldサービスの一覧は、「firewalld サービスの一覧」 を参照してください。
必須ポート一覧
表2.1 Identity Management のポート
| サービス | ポート | プロトコル |
|---|---|---|
| HTTP/HTTPS | 80、443 | TCP |
| LDAP/LDAPS | 389、636 | TCP |
| Kerberos | 88、464 | TCP および UDP |
| DNS | 53 | TCP および UDP |
| NTP | 123 | UDP |
注記
- ポート 80 (HTTP) は、オンライン証明書ステータスプロトコル (OCSP) の応答と証明取り消し一覧 (CRL) を提供するために使用されます。これらは両方ともデジタル署名されているので、中間者攻撃に対して安全になっています。
- ポート 389 (LDAP) は暗号化に STARTTLS と GSSAPI を使用します。
firewalld サービスの一覧
表2.2 firewalld サービス
| サービス名 | 詳細参照先 |
|---|---|
freeipa-ldap | /usr/lib/firewalld/services/freeipa-ldap.xml |
freeipa-ldaps | /usr/lib/firewalld/services/freeipa-ldaps.xml |
dns | /usr/lib/firewalld/services/dns.xml |
必須ポートの開放
firewalldサービスが稼働していることを確認します。firewalldが実行中かどうかを確認するには、以下を実行します。# systemctl status firewalld.service
firewalldを起動し、システム起動時に自動的に起動するように設定するには、以下を実行します。# systemctl start firewalld.service # systemctl enable firewalld.service
firewall-cmdユーティリティーを使って必須ポートを開きます。以下のいずれかのオプションを選択します。firewall-cmd --add-portコマンドを使用して個別ポートをファイアウォールに追加します。たとえば、デフォルトゾーンのポートを開くには、以下を実行します。# firewall-cmd --permanent --add-port={80/tcp,443/tcp,list_of_ports}firewall-cmd --add-serviceコマンドを使用してfirewalldサービスをファイアウォールに追加します。たとえば、デフォルトゾーンのポートを開くには、以下を実行します。# firewall-cmd --permanent --add-service={freeipa-ldap,list_of_services}
firewall-cmd設定をリロードして、変更が直ちに反映されるようにします。# firewall-cmd --reload
実稼働環境のシステムでfirewalldを再読み込みすると、DNS 接続がタイムアウトされてしまう可能性があります。『Security Guide』の「コマンドラインインターフェース (CLI) を使ったファイアウォール設定のリロード」も参照してください。必要であれば、タイムアウトのリスクを回避するため、--permanentオプションなしでこのコマンドを再度実行して、実行中のシステムに変更を適用します。- これはオプションです。 ポートが現在使用可能であることを確認するには、
nc、telnet、またはnmapのユーティリティーを使用してポートに接続するか、ポートスキャンを実行します。
2.2. IdM サーバーのインストールに必要なパッケージ
# yum install ipa-server
# yum install ipa-server ipa-server-dns
注記
- Directory Server LDAP サービス向けの 389-ds-base
- Kerberos サービス向けの krb5-server パッケージ
- 各種の IdM 固有ツール
2.3. IdM サーバーのインストール: はじめに
注記
ipa-server-install で IdM のインストールと設定を行います。
ipa-server-install ユーティリティーでは非対話式のインストールモードが提供され、これを使用することで自動かつ無人のサーバー設定が可能になります。詳細は、「非対話式でのサーバーのインストール」 を参照してください。
ipa-server-install は、ログファイルを /var/log/ipaserver-install.log に作成します。インストールが失敗した場合は、このログファイルが問題の特定に役立ちます。
2.3.1. 統合 DNS 使用の判断
- 統合 DNS サービスのある IdM サーバー
- IdM が提供する統合 DNS サーバーは、汎用目的の DNS サーバーとして使用する設計にはなっていません。IdM デプロイメントとメンテナンスに関連する機能のみをサポートしています。高度な DNS 機能のいくつかはサポートされていません。Red Hat では、IdM デプロイメント内で基本的な IdM-統合 DNS の使用を強く推奨しています。IdM サーバーが DNS も管理する場合は、DNS とネイティブの IdM ツールは緊密に統合され、DNS レコード管理の一部の自動化が可能になります。IdM サーバーがマスター DNS サーバーとして使用される場合でも、他の外部の DNS サーバーはスレーブサーバーとして使用することが可能であることに留意してください。たとえば、Active Directory 統合 DNS サーバーのような別の DNS サーバーを自分の環境で既に使用している場合、IdM 統合 DNS に委任できるのは IdM プライマリードメインのみになります。DNS ゾーンを IdM 統合 DNS に移行する必要はありません。統合 DNS のあるサーバーをインストールする方法については、「統合 DNS のあるサーバーのインストール」 を参照してください。
- 統合 DNS サービスのない IdM サーバー
- DNS サービスの提供に外部の DNS サーバーが使用されます。以下の場合は、DNS なしで IdM サーバーをインストールすることを検討してください。
- IdM DNS のスコープ外となる高度な DNS 機能を必要とする場合。
- 外部の DNS サーバーが使用可能となっている確立された DNS インフラストラクチャーがある環境。
統合 DNS のないサーバーをインストールする方法については、「統合 DNS のなしでのサーバーのインストール」 を参照してください。
重要
統合または外部 DNS のメンテナンス要件
- 親ドメインから IdM サーバーへの適切な委任の設定たとえば、IdM ドメイン名が
ipa.example.comだったとすると、example.comドメインからの適切な委任が必要になります。注記
以下のコマンドを使用すると委任を確認できます。# dig @IP_address +norecurse +short ipa.example.com. NS
IP_address は、example.comDNS ドメインを管理するサーバーの IP アドレスです。委任が適切であれば、このコマンドにより DNS サーバーがインストール済みの IdM サーバーが一覧表示されます。
- DNS サーバー上に新規ドメインを手動で作成する。
- 新規ドメインを、IdM インストーラーで生成されたゾーンファイルからのレコードで手動で満たす。
- Active Directory の信頼設定後などのサービス設定の変更後や、レプリカのインストールもしくは削除後にレコードを手動で更新する。
DNS アンプ攻撃の回避
/etc/named.conf ファイルに追加します。例を示します。
acl authorized { 192.0.2.0/24; 198.51.100.0/24; };
options {
allow-query { any; };
allow-recursion { authorized; };
};2.3.2. CA 設定の決定
- 統合 IdM CA のあるサーバー
- これはほとんどのデプロイメントに適切なデフォルトの設定です。Certificate System は CA 署名証明書 を使用して IdM ドメイン内の証明書を作成し、これに署名します。
警告
Red Hat では、複数のサーバーに CA サービスをインストールしておくことを強く推奨しています。CA サービスを含む最初のサーバーのレプリカをインストールする方法についての情報は、「CA を設定したレプリカのインストール」 を参照してください。CA が 1 つのサーバーにしかインストールされていないと、CA サーバーが故障した際に CA 設定が失われて回復できない恐れがあります。詳細については、「失われた CA サーバーの復旧」 を参照してください。CA 署名証明書は、CA 階層の中で最高位の CA である root CA で署名される必要があります。root CA は IdM CA 自体であったり、外部でホストされている CA である場合もあります。- IdM CA を root CA とする
- これがデフォルト設定になります。この設定でサーバーをインストールする方法については、「統合 DNS のあるサーバーのインストール」 と 「統合 DNS のなしでのサーバーのインストール」 を参照してください。
- 外部 CA を root CA とする
- IdM CA は外部 CA の下位となります。ただし、IdM ドメインの証明書はすべて、Certificate System インスタンスが発行します。外部 CA は、企業 CA や、Verisign や Thawte などのサードパーティー CA とすることができます。IdM ドメイン内で発行される証明書は、有効期間など外部 root CA の属性が設定する制限の影響を受ける可能性があります。外部にホストされている root CA のあるサーバーをインストールする方法については、「外部 CA を Root CA としてサーバーをインストールする手順」 を参照してください。
- CA なしのサーバー
- この設定オプションは、インフラストラクチャー内の制限により証明書サービスのあるサーバーをインストールできない場合に適しています。インストール前に以下の証明書をサードパーティー機関にリクエストする必要があります。
- LDAP サーバー証明書および秘密キー
- Apache サーバー証明書および秘密キー
- LDAP および Apache サーバー証明書を発行した CA の完全な CA 証明書チェーン
統合 IdM CA なしで証明書を管理しようとすると、多大なメンテナンス負担になります。たとえば、- 証明書の作成、アップロード、更新プロセスが手動になります。
- 証明書の追跡に
certmongerサービスが使用されません。このため、証明書の有効期限が迫っても警告が出されません。
統合 CA のないサーバーをインストールする方法については、「CA なしでのインストール」 を参照してください。
2.3.3. 統合 DNS のあるサーバーのインストール
注記
- DNS フォワーダー
- 以下の DNS フォワーダー設定がサポートされています。
- 1 つ以上のフォワーダー (非対話式インストールでの
--forwarderオプション) - フォワーダーなし (非対話式インストールでの
--no-forwardersオプション)
ご自分のユースケースに DNS フォワーダーを使用するべきかどうかを判断するには、「DNS 転送の管理」 を参照してください。 - 逆引き DNS ゾーン
- 以下の DNS ゾーン設定がサポートされています。
- IdM DNS 内で作成する必要のある逆引きゾーンの自動検出 (対話式インストールでのデフォルト設定、非対話式インストールでの
--auto-reverseオプション) - 逆引きゾーンを自動検出しない (対話式インストールでの
--no-reverseオプション)
--setup-dns オプションも追加してください。
例2.1 統合 DNS のあるサーバーのインストール
- 統合 DNS のあるサーバー
- IdM CA を root CA とするサーバー。これがデフォルトの CA 設定です。
ipa-server-installユーティリティーを実行します。# ipa-server-install
- このスクリプトは統合 DNS サービスを設定するよう要求するので、
yesと入力します。Do you want to configure integrated DNS (BIND)? [no]:
yes - さらにいくつかの設定プロンプトが出ます。
- 括弧内のデフォルト値を許可するには、Enter を押します。
- デフォルト値とは別の値を使用する場合は、必要な値を入力します。
Server host name [server.example.com]: Please confirm the domain name [example.com]: Please provide a realm name [EXAMPLE.COM]:
警告
Red Hat では、Kerberos レルム名をプライマリー DNS ドメイン名をすべて大文字にしたものにすることを強く推奨しています。たとえば、プライマリー DNS ドメインがipa.example.comの場合、Kerberos レルム名はIPA.EXAMPLE.COMとします。異なる命名規則を使用すると Active Directory 信頼が使用できなくなるほか、その他のマイナス面が発生する可能性があります。 - Directory Server スーパーユーザー、
cn=Directory Manager、およびadminIdM システムユーザーアカウントのパスワードを入力します。Directory Manager password: IPA admin password:
- DNS フォワーダー設定のプロンプトが出されます。
Do you want to configure DNS forwarders? [yes]:
- DNS フォワーダーを設定する場合は、
yesを入力してコマンドラインの指示に従います。インストールプロセスでフォワーダー IP アドレスがインストールされる IdM サーバーの/etc/named.confファイルに追加されます。- 転送ポリシーのデフォルト設定については、ipa-dns-install(1) man ページの
--forward-policyの記述を参照してください。 - 詳細は、「転送ポリシー」も参照してください。
- DNS 転送を使用しない場合は、
noと入力します。
- サーバーと関連する IP アドレスの DNS 逆引き (PTR) レコードを設定する必要性を確認するプロンプトが出されます。
Do you want to search for missing reverse zones? [yes]:
検索を実行して逆引きゾーンが見つかると、PTR レコードの逆引きゾーンを作成するかどうかを聞かれます。Do you want to create reverse zone for IP 192.0.2.1 [yes]: Please specify the reverse zone name [2.0.192.in-addr.arpa.]: Using reverse zone(s) 2.0.192.in-addr.arpa.
注記
逆引きゾーンの管理に IdM を使用することはオプションです。外部 DNS サービスを使用することもできます。 - サーバー設定をする場合は、
yesと入力します。Continue to configure the system with these values? [no]:
yes - これでインストールスクリプトがサーバーを設定します。動作が完了するまで待機します。
- 親ドメインからのDNS 委任を IdM DNS ドメインに追加します。たとえば、IdM DNS ドメインが
ipa.example.comの場合、ネームサーバー (NS) レコードをexample.comの親ドメインに追加します。重要
IdM DNS サーバーがインストールされるたびに毎回このステップを繰り返す必要があります。
- admin の認証情報を使って Kerberos レルムに認証を行います。これで
adminが適切に設定され、Kerberos レルムがアクセス可能であることを確認します。# kinit admin
ipa user-findのようなコマンドを実行します。新規サーバーでは、このコマンドは唯一の設定済みユーザーであるadminをプリントします。# ipa user-find admin -------------- 1 user matched -------------- User login: admin Last name: Administrator Home directory: /home/admin Login shell: /bin/bash UID: 939000000 GID: 939000000 Account disabled: False Password: True Kerberos keys available: True ---------------------------- Number of entries returned 1 ----------------------------
2.3.4. 統合 DNS のなしでのサーバーのインストール
注記
ipa-server-install ユーティリティーを実行します。
例2.2 統合 DNS のなしでのサーバーのインストール
- 統合 DNS のないサーバー
- IdM CA を root CA とするサーバー。これがデフォルトの CA 設定です。
ipa-server-installユーティリティーを実行します。# ipa-server-install
- このスクリプトは統合 DNS サービスを設定するよう要求するので、Enter を押してデフォルトの
noオプションを選択します。Do you want to configure integrated DNS (BIND)? [no]:
- さらにいくつかの設定プロンプトが出ます。
- 括弧内のデフォルト値を許可するには、Enter を押します。
- デフォルト値とは別の値を使用する場合は、必要な値を入力します。
Server host name [server.example.com]: Please confirm the domain name [example.com]: Please provide a realm name [EXAMPLE.COM]:
警告
Red Hat では、Kerberos レルム名をプライマリー DNS ドメイン名をすべて大文字にしたものにすることを強く推奨しています。たとえば、プライマリー DNS ドメインがipa.example.comの場合、Kerberos レルム名はIPA.EXAMPLE.COMとします。異なる命名規則を使用すると Active Directory 信頼が使用できなくなるほか、その他のマイナス面が発生する可能性があります。 - Directory Server スーパーユーザー、
cn=Directory Manager、およびadminIdM システムユーザーアカウントのパスワードを入力します。Directory Manager password: IPA admin password:
- サーバー設定をする場合は、
yesと入力します。Continue to configure the system with these values? [no]:
yes - これでインストールスクリプトがサーバーを設定します。動作が完了するまで待機します。
- 以下の出力例のように、インストールスクリプトでは DNS リソースレコードが含まれるファイルが (
/tmp/ipa.system.records.UFRPto.db) が作成されます。これらのレコードを既存の外部 DNS サーバーに追加します。DNS レコードの更新プロセスは、特定の DNS ソリューションにより異なります。... Restarting the KDC Please add records in this file to your DNS system: /tmp/ipa.system.records.UFRBto.db Restarting the web server ...重要
既存の DNS サーバーに DNS レコードを追加した時点で、サーバーのインストールは完了します。
- admin の認証情報を使って Kerberos レルムに認証を行います。これで
adminが適切に設定され、Kerberos レルムがアクセス可能であることを確認します。# kinit admin
ipa user-findのようなコマンドを実行します。新規サーバーでは、このコマンドは唯一の設定済みユーザーであるadminをプリントします。# ipa user-find admin -------------- 1 user matched -------------- User login: admin Last name: Administrator Home directory: /home/admin Login shell: /bin/bash UID: 939000000 GID: 939000000 Account disabled: False Password: True Kerberos keys available: True ---------------------------- Number of entries returned 1 ----------------------------
2.3.5. 外部 CA を Root CA としてサーバーをインストールする手順
注記
ipa-server-install ユーティリティーで以下のオプションを渡します。
--external-caで外部 CA を使用することを指定します。--external-ca-typeでは、外部 CA のタイプを指定します。詳細については、ipa-server-install(1) man ページを参照してください。
/root/ipa.csr:
...
Configuring certificate server (pki-tomcatd): Estimated time 3 minutes 30 seconds
[1/8]: creating certificate server user
[2/8]: configuring certificate server instance
The next step is to get /root/ipa.csr signed by your CA and re-run /sbin/ipa-server-install as: /sbin/ipa-server-install --external-cert-file=/path/to/signed_certificate --external-cert-file=/path/to/external_ca_certificate/root/ipa.csrにある CSR を外部 CA に提出します。このプロセスは、外部 CA として使用するサービスによって異なります。重要
場合によっては、証明書に適切な拡張子を要求する必要がある場合もあります。Identity Management サーバー用に生成された CA 署名証明書は、有効な CA 証明書である必要があります。つまり、Basic Constraint が CA=true と設定されているか、Key Usage Extension が署名証明書に設定されて、証明書の署名が可能となっている必要があります。- 発行された証明書と Base64 エンコードされたブロブ (PEM ファイルか Windows CA からの Base_64 証明書) で CA を発行するための CA 証明書チェーンを取得します。プロセスは証明書サービスによって異なりますが、通常はウェブページか通知メールにダウンロードリンクがあり、管理者が必要な証明書すべてをダウンロードできるようになっています。
重要
CA 証明書のみではなく、CA 用の完全な証明書チェーンを取得してください。 ipa-server-installを再度実行し、新規に発行された CA 証明書と CA チェーンファイルの場所と名前を指定します。例を示します。# ipa-server-install --external-cert-file=/tmp/servercert20110601.pem --external-cert-file=/tmp/cacert.pem
注記
ipa-server-install --external-ca コマンドは、以下のエラーが出て失敗する場合があります。
ipa : CRITICAL failed to configure ca instance Command '/usr/sbin/pkispawn -s CA -f /tmp/configuration_file' returned non-zero exit status 1 Configuration of CA failed
*_proxy 環境変数が設定されている場合に発生します。この問題の解決策については、「外部 CA インストールの失敗」 を参照してください。
2.3.6. CA なしでのインストール
注記
ipa-server-install ユーティリティーに追加することで必要な証明書を手動で提供する必要があります。この他については、インストール手順のほとんどは 「統合 DNS のあるサーバーのインストール」 または 「統合 DNS のなしでのサーバーのインストール」 の場合と同じになります。
重要
--dirsrv-cert-fileは、LDAP サーバー証明書用の証明書ファイルおよび秘密キーファイルを提供します。--dirsrv-pinでは、--dirsrv-cert-fileで指定されたファイル内の秘密キーにアクセスするためのパスワードを提供します。
--http-cert-fileでは、Apache サーバー証明書用の証明書ファイルおよび秘密鍵ファイルを提供します。--http-pinでは、--http-cert-fileで指定されたファイル内の秘密鍵にアクセスするためのパスワードを提供します。
--dirsrv-cert-fileおよび--http-cert-fileで、完全な CA 証明書チェーンもしくはその一部を備えた証明書ファイルを提供します。これらのオプションは複数回使用することができ、以下を受け付けます。- PEM エンコード化および DER エンコード化された X.509 証明書ファイル
- PKCS#1 および PKCS#8 秘密鍵ファイル
- PKCS#7 証明書チェーンファイル
- PKCS#12 ファイル
--dirsrv-cert-fileと--http-cert-fileを使用して提供されるファイルには、厳密に 1 つのサーバー証明書と 1 つの秘密キーが含まれている必要があります。--dirsrv-cert-fileと--http-cert-fileを使用して提供されるファイルのコンテンツは同一であることがよくあります。- 必要に応じて
--ca-cert-fileを証明書ファイルに追加し、完全な CA 証明書チェーンを完成させます。このオプションは複数回使用することができ、以下を受け付けます。- PEM エンコード化および DER エンコード化された X.509 証明書ファイル
- PKCS#7 証明書チェーンファイル
--ca-cert-fileで提供されるファイルと組み合わせて、--dirsrv-cert-fileと--http-cert-fileで提供されるファイルには、LDAP および Apache サーバー証明書を発行した CA の完全 CA 証明書チェーンが含まれる必要があります。
[root@server ~]# ipa-server-install \
--http-cert-file /tmp/server.crt \
--http-cert-file /tmp/server.key \
--http-pin secret \
--dirsrv-cert-file /tmp/server.crt \
--dirsrv-cert-file /tmp/server.key \
--dirsrv-pin secret \
--ca-cert-file ca.crt--external-ca オプションと互換性がないことに注意してください。
注記
--root-ca-file オプションを使って root CA 証明書の PEM ファイルを指定していました。信頼できる CA は常に DS および HTTP サーバー証明書の発行者なので、これはもう不要になりました。今では IdM は、--dirsrv-cert-file、--http-cert-file、および --ca-cert-file で指定される証明書からの root CA 証明書を自動的に認識します。
2.3.7. 非対話式でのサーバーのインストール
注記
--ds-passwordでは、Directory Server のスーパーユーザーである Directory Manager (DM) のパスワードを指定します。--admin-passwordでは、IdM 管理者であるadminのパスワードを指定します。--realmでは、Kerberos レルム名を指定します。--unattendedを使用すると、インストールプロセスでホスト名とドメイン名のデフォルトオプションを選択することができます。任意で、以下の設定でカスタム値を指定できます。--hostnameでサーバーのホスト名を指定します。--domainでドメイン名を指定します。
警告
ipa.example.com の場合、Kerberos レルム名は IPA.EXAMPLE.COM とします。
ipa-server-install が受け取るオプションの完全なリストを表示するには、ipa-server-install --help コマンドを実行してください。
例2.3 非対話式の基本的なインストール
ipa-server-installユーティリティーを実行して、必要な設定を指定します。たとえば、以下では統合 DNS がなく統合 CA のあるサーバーがインストールされます。# ipa-server-install --realm EXAMPLE.COM --ds-password DM_password --admin-password admin_password --unattended
- これで設定スクリプトがサーバーを設定します。動作が完了するまで待機します。
- 以下の出力例のように、インストールスクリプトでは DNS リソースレコードが含まれるファイルが (
/tmp/ipa.system.records.UFRPto.db) が作成されます。これらのレコードを既存の外部 DNS サーバーに追加します。DNS レコードの更新プロセスは、特定の DNS ソリューションにより異なります。... Restarting the KDC Please add records in this file to your DNS system: /tmp/ipa.system.records.UFRBto.db Restarting the web server ...重要
既存の DNS サーバーに DNS レコードを追加した時点で、サーバーのインストールは完了します。
- admin の認証情報を使って Kerberos レルムに認証を行います。これで
adminが適切に設定され、Kerberos レルムがアクセス可能であることを確認します。# kinit admin
ipa user-findのようなコマンドを実行します。新規サーバーでは、このコマンドは唯一の設定済みユーザーであるadminをプリントします。# ipa user-find admin -------------- 1 user matched -------------- User login: admin Last name: Administrator Home directory: /home/admin Login shell: /bin/bash UID: 939000000 GID: 939000000 Account disabled: False Password: True Kerberos keys available: True ---------------------------- Number of entries returned 1 ----------------------------
2.4. IdM サーバーのアンインストール
注記
0 では、この手順は異なります。「レプリカの削除」を参照してください。
server.example.com のアンインストール手順:
- 別のサーバーで
ipa server-delコマンドを使用して、トポロジーからserver.example.comを削除します。[root@another_server ~]
# ipa server-del server.example.com server.example.comでipa-server-install --uninstallコマンドを使用します。[root@server ~]
# ipa-server-install --uninstallserver.example.comを参照するすべてのネームサーバー (NS) の DNS レコードが DNS ゾーンから削除されていることを確認します。使用する DNS が IdM で管理される統合 DNS か、外部 DNS かに関わらず、確認してください。
2.5. サーバーの名前変更
- 認証局、新たに必要なホスト名または IP アドレスを指定して、サーバーのレプリカを新たに作成します。これについては、4章Identity Management のレプリカのインストールとアンインストールに説明されています。
- 最初の IdM サーバーインスタンスを停止します。
[root@old_server ~]# ipactl stop
- 他のレプリカやクライアントは変わらず動作していることを確認します。
- 「IdM サーバーのアンインストール」で説明されているように、最初の IdM サーバーをアンインストールします。
第3章 Identity Management クライアントのインストールおよびアンインストール
注記
3.1. クライアントインストールの前提条件
- DNS 要件
- 適切な DNS の委譲を使用すること。IdM の DNS 要件に関する詳細は「ホスト名および DNS の設定」を参照してください。クライアント上の
resolv.confファイルを変更しないこと - ポート要件
- IdM クライアントは、複数のポートに接続してサーバーと通信します。これらのポートは、IdM サーバー上で 開放して機能できるようにしておく必要があります。IdM が必要とするポートについての情報は、「ポート要件」を参照してください。クライアント上で、送信方向のポートを開放します。
firewalldなど、送信パケットをフィルタリングしないファイアウォールを使用している場合には、これらのポートはすでに送信方向で利用できる状態です。
- 連邦情報処理標準 (FIPS: Federal Information Processing Standard) のサポート
- Red Hat Enterprise Linux 7.4 以降を使用して設定した環境の場合:
- FIPS モードを有効化したシステムで、新規の IdM サーバー、レプリカまたはクライアントを設定できます。インストールスクリプトでは、管理者の介入なしに、自動的に FIPS が有効化されているシステムを検出し、IdM を設定します。オペレーティングシステムで FIPS を有効化するには、『セキュリティーガイド』の「FIPS モードの有効化」を参照してください。
重要
以下の点に注意してください。- FIPS モードを無効にしてインストールした既存の IdM サーバーで FIPS モードを有効にすることはできません。
- FIPS モードが無効になっている既存の IdM サーバーに FIPS サポートを有効にした新規レプリカをインストールすることはできません。
Red Hat Enterprise Linux 7.3 以前を使用して設定した環境の場合:- IdM では、FIPS モードはサポートされません。システム上で FIPS を無効化してから、IdM サーバー、レプリカまたはクライアントをインストールし、インストール後も有効化しないでください。
FIPS モードに関する詳しい情報は『セキュリティーガイド』の「連邦情報処理標準 (FIPS: Federal Information Processing Standard)」を参照してください。 - Name Service Cache Daemon (NSCD) の要件
- Red Hat では、Identity Management マシン上で NSCD を無効にすることを推奨しています。NSCD を無効にできない場合は、代わりに SSSD がキャッシュを行わないマッピングに対して NSCD を有効化するようにしてください。NSCD と SSSD の両サービスはキャッシングを実行するので、これら両方をシステムが同時に使用すると問題が発生します。NSCD と SSSD の競合を避ける方法については、「システムレベルの認証ガイド」を参照してください。
3.2. クライアントのインストールに必要なパッケージ
# yum install ipa-client
3.3. クライアントのインストール
ipa-client-install ユーティリティーは、IdM クライアントをインストール、設定します。インストールプロセスでは、クライアントの登録に使用可能な認証情報を指定する必要があります。以下の認証方法がサポートされています。
adminなどクライアントの登録を許可するユーザーの認証情報- デフォルトでは
ipa-client-installはこのオプションを使用することが想定されています。例については「クライアントの対話型インストール」を参照してください。ipa-client-installに直接ユーザーの認証情報をわたすには、--principalと--passwordのオプションを使用します。 - サーバー上で無作為に事前に生成されるワンタイムパスワード
- この認証方法を使用するには、
--randomオプションをipa-client-installコマンドに追加します。詳細は例3.1「無作為のパスワードを使用して非対話式にクライアントをインストールする手順」を参照してください。 - 以前の登録からのプリンシパル
ipa-client-install の使用や対応オプションの完全一覧については ipa-client-install(1) の man ページを参照してください。
3.3.1. クライアントの対話型インストール
admin など、ドメインへのクライアントの登録が許可されているユーザーの認証情報を指定します。
ipa-client-installユーティリティーを実行します。以下のいずれかが当てはまる場合、--enable-dns-updatesオプションを追加して、クライアントマシンの IP アドレスで DNS レコードを更新します。- クライアントを登録する IdM サーバーが、統合 DNS とインストールされている場合。
- ネットワーク上の DNS サーバーが、 GSS-TSIG プロトコルによる DNS エントリー更新を受け付ける場合。
--no-krb5-offline-passwordsオプションを追加して、SSSD キャッシュに Kerberos パスワードを保存できないようにします。- このインストールスクリプトでは、必要な設定を自動的に取得するように試みます。
- DNS ゾーンおよび SRV レコードがシステム上で正しく設定されている場合には、スクリプトは自動的に必要な値がすべて検出され、出力されます。
yesと入力して確定します。Client hostname: client.example.com Realm: EXAMPLE.COM DNS Domain: example.com IPA Server: server.example.com BaseDN: dc=example,dc=com Continue to configure the system with these values? [no]:
yes別の値でシステムをインストールするには現在のインストールをキャンセルし、ipa-client-installをもう一度実行して、コマンドラインオプションを使用して必要な値を指定します。詳細は、ipa-client-install(1) の man ページのDNS Autodiscoveryセクションを参照してください。 - スクリプトで自動的に設定が取得されなかった場合には、値を入力するようにプロンプトが表示されます。
重要
完全修飾ドメイン名は有効な DNS 名である必要があります。つまり、許可されるのは数字、アルファベット、ハイフン (-) のみです。ホスト名にアンダースコアのような他の文字があると、DNS エラーが発生します。また、ホスト名はすべて小文字を使用する必要があり、大文字は使用できません。命名プラクティスに関する他の推奨事項については、Red Hat Enterprise Linux セキュリティーガイド を参照してください。
- このスクリプトは、クライアントの登録に使用するユーザー ID の入力を求めるプロンプトを表示します。デフォルトでは、このユーザーは
adminです。User authorized to enroll computers:
adminPassword for admin@EXAMPLE.COM - インストールスクリプトでクライアントが設定されます。動作が完了するまで待機します。
Client configuration complete.
ipa-client-automountユーティリティーを実行します。これで NFS が IdM 向けに自動的に設定されます。詳細は、「NFS の自動設定」 を参照してください。
3.3.2. 非対話式なクライアントのインストール
ipa-client-install ユーティリティーに必要な情報すべて渡します。非対話式のインストールで最小限必要となるオプションは以下のとおりです。
- クライアントの登録に使用する認証情報を指定するオプション。詳細は「クライアントのインストール」を参照してください。
--unattended: ユーザーの確認なしにインストールを実行します。
--hostname: クライアントマシンの静的ホスト名を指定します。重要
完全修飾ドメイン名は有効な DNS 名である必要があります。つまり、許可されるのは数字、アルファベット、ハイフン (-) のみです。ホスト名にアンダースコアのような他の文字があると、DNS エラーが発生します。また、ホスト名はすべて小文字を使用する必要があり、大文字は使用できません。命名プラクティスに関する他の推奨事項については、Red Hat Enterprise Linux セキュリティーガイド を参照してください。--server: クライアントの登録先の IdM サーバーのホスト名を指定します。--domain: クライアントの登録先の IdM サーバーの DNS ドメイン名を指定します。--realm: Kerberos レルム名を指定します。
--enable-dns-updates オプションを追加して、クライアントマシンの IP アドレスで DNS レコードを更新します。
- クライアントを登録する IdM サーバーが、統合 DNS とインストールされている場合。
- ネットワーク上の DNS サーバーが、 GSS-TSIG プロトコルによる DNS エントリー更新を受け付ける場合。
--no-krb5-offline-passwords オプションを追加して、SSSD キャッシュに Kerberos パスワードを保存できないようにします。
ipa-client-install で対応のオプションに関する完全一覧は、ipa-client-install(1) の man ページを参照してください。
例3.1 無作為のパスワードを使用して非対話式にクライアントをインストールする手順
- 既存のサーバー上で:
- 管理者としてログインします。
$ kinit admin
- IdM ホストとして新規マシンを追加します。
--randomオプションを指定してipa host-addコマンドを使用して、無作為のパスワードを生成します。$ ipa host-add client.example.com --random -------------------------------------------------- Added host "client.example.com" -------------------------------------------------- Host name: client.example.com Random password: W5YpARl=7M.n Password: True Keytab: False Managed by: server.example.com
生成パスワードは、IdM ドメインへのマシン登録に使用した後は無効になります。登録が完了すると正しいホストの keytab に置き換えられます。
- クライアントをインストールするマシンで、
ipa-client-installを実行します。以下のオプションを使用します。--password:ipa host-add出力からの無索引パスワードを使用します。注記
パスワードには特殊文字が含まれることが多いので、一重引用符 (') で括るようにしてください。--unattended: ユーザーの確認なしにインストールを実行します。
DNS ゾーンおよび SRV レコードがシステム上で正しく設定されている場合には、スクリプトは自動的に必要な値をすべて検出します。スクリプトが自動的に値を検出できない場合には、コマンドラインオプションを使用して指定してください。例を示します。# ipa-client-install --password 'W5YpARl=7M.n' --domain example.com --server server.example.com --unattended
ipa-client-automountユーティリティーを実行します。これで NFS が IdM 向けに自動的に設定されます。詳細は、「NFS の自動設定」 を参照してください。
3.4. キックスタートを使用した IdM クライアントの設定
3.4.1. IdM サーバーにおけるクライアントのホストエントリーの事前作成
- 管理者としてログインします。
$ kinit admin
- IdM サーバー上でホストエントリーを作成し、エントリーの一時パスワードを設定します。
$ ipa host-add client.example.com --password=secret
キックスタートがこのパスワードを使用して、クライアントのインストール時に認証し、最初の認証試行後に無効にします。クライアントが正常にインストールされたら、keytab を使用して認証が行われます。
3.4.2. クライアント向けのキックスタートファイルの作成
- インストールするパッケージ一覧に含まれる ipa-client パッケージ
%packages @ X Window System @ Desktop @ Sound and Video
ipa-client...詳細は、『インストールガイド』の「パッケージの選択」を参照してください。 - インストール後の手順
- 登録後に SSH 鍵が生成されていることを確認する
- 以下を指定して
ipa-client-installユーティリティーを実行する- IdM ドメインサービスへのアクセスおよび設定に必要な全情報
- 「IdM サーバーにおけるクライアントのホストエントリーの事前作成」の記載どおりに IdM サーバーにクライアントホストを事前に作成する際に設定するパスワード
例を示します。%post --log=/root/ks-post.log # Generate SSH keys to ensure that ipa-client-install uploads them to the IdM server /usr/sbin/sshd-keygen # Run the client install script /usr/sbin/ipa-client-install --hostname=client.example.com --domain=EXAMPLE.COM --enable-dns-updates --mkhomedir -w secret --realm=EXAMPLE.COM --server=server.example.com
非対話式のインストールの場合には、--unattendedオプションも追加します。クライアントのインストールスクリプトがマシンの証明書を要求できるようにするには、以下を行います。--request-certオプションをipa-client-installに追加します。- キックスタートの
chroot環境で、getcertとipa-client-installユーティリティー両方に対して/dev/nullにシステムバスのアドレスを設定します。これには、インストール後の指示ファイルのipa-client-install指示文の前に以下の行を追加します。# env DBUS_SYSTEM_BUS_ADDRESS=unix:path=/dev/null getcert list # env DBUS_SYSTEM_BUS_ADDRESS=unix:path=/dev/null ipa-client-install
注記
Red Hat は、キックスタートの登録前にsshdサービスを起動することは推奨していません。登録前にsshdを開始すると、クライアントは自動的に SSH 鍵を生成するので、上記のスクリプトの使用が推奨されます。詳細は、『インストールガイド』の「インストール後のスクリプト」を参照してください。
3.5. クライアントのインストール後の検討事項
3.5.1. Identity Management の事前設定の削除
ipa-client-install スクリプトは、/etc/openldap/ldap.conf および /etc/sssd/sssd.conf ファイルから、以前の LDAP および SSSD 設定を削除します。これらのファイルの設定を変更すると、スクリプトにより新規クライアントの値が追加されますが、コメントアウトされます。以下に例を示します。
BASE dc=example,dc=com URI ldap://ldap.example.com #URI ldaps://server.example.com # modified by IPA #BASE dc=ipa,dc=example,dc=com # modified by IPA
/etc/openldap/ldap.confおよび/etc/sssd/sssd.confを開きます。- 以前の設定を削除します。
- 新規の Identity Management 設定をアンコメントします。
- システム全体の LDAP 設定に依存するサーバープロセスでは、変更を適用するのに再起動が必要な場合があります。
openldapライブラリーを使用するアプリケーションでは通常、起動時に設定がインポートされます。
3.6. 新規クライアントのテスト
admin ユーザーをチェックするには、以下を実行します。
[user@client ~]$ id admin uid=1254400000(admin) gid=1254400000(admins) groups=1254400000(admins)
3.7. クライアントのアンインストール
ipa-client-install --uninstallコマンドを実行します。# ipa-client-install --uninstall
- サーバーからクライアントホストの DNS エントリーを手動で削除します。「DNS ゾーンからレコードを削除する」 を参照してください。
3.8. クライアントの IdM ドメインへの再登録
- 対話式の場合には管理者の認証情報を使用します。「管理者のアカウントを使用して対話式にクライアントを再登録する方法」を参照してください。
- 非対話式の場合は、以前にバックアップした keytab ファイルを使用します。「クライアントの keytab を使用して非対話式にクライアントを再登録する方法」を参照してください。
注記
ipa-client-install --uninstall の使用) またはホストのエントリーを無効にした場合は (ipa host-disable の使用) 再登録できません。
- 元のホスト証明書を破棄します。
- 新規ホストの証明書を生成します。
- 新規の SSH 鍵を作成します。
- 新規の keytab を生成します。
3.8.1. 管理者のアカウントを使用して対話式にクライアントを再登録する方法
- 同じホスト名のクライアントマシンを再作成します。
- クライアントマシンで
ipa-client-install --force-joinコマンドを実行します。# ipa-client-install --force-join
- このスクリプトは、クライアントの登録に使用するユーザー ID の入力を求めるプロンプトを表示します。デフォルトでは、このユーザーは
adminです。User authorized to enroll computers:
adminPassword for admin@EXAMPLE.COM
3.8.2. クライアントの keytab を使用して非対話式にクライアントを再登録する方法
- 元のクライアントの keytab ファイルを
/tmpまたは/rootディレクトリーなどにバックアップします。 - 同じホスト名のクライアントマシンを再作成します。
- クライアントを再登録して、
--keytabオプションを使用して keytab の場所を指定します。# ipa-client-install --keytab /tmp/krb5.keytab
注記
登録を開始するために認証する場合には、--keytabオプションで指定した keytab のみが使用されます。再登録時には IdM はクライアントの新規 keytab を生成します。
3.9. クライアントマシンの名前変更
警告
現在のサービスや keytab 設定の特定
- マシンで実行されているサービスを特定します。
ipa service-findコマンドを使用して、証明書のあるサービスを特定して出力します。$ ipa service-find client.example.com
- さらに、各ホストには、
ipa service-findの出力に表示されないデフォルトの ホストサービス があります。ホストサービスのサービスプリンシパル (ホストプリンシパル とも呼ばれる) は、host/client.example.comです。
- マシンが所属するすべてのホストグループを特定します。
# ipa hostgroup-find client.example.com
ipa service-find client.example.comで表示されるサービスプリンシパルすべてについて、client.example.comの適切な keytab の場所を特定します。クライアントシステム上の各サービスには、ldap/client.example.com@EXAMPLE.COMといったように service_name/hostname@REALM の形式で Kerberos プリンシパルがあります。
IdM ドメインからのクライアントマシンの削除
- IdM ドメインからクライアントマシンの登録を解除します。「クライアントのアンインストール」を参照してください。
/etc/krb5.keytab以外の特定された各 keytab で、古いプリンシパルを削除します。[root@client ~]# ipa-rmkeytab -k /path/to/keytab -r EXAMPLE.COM
「Keytab の削除」を参照してください。- IdM サーバー上でホストエントリーを削除します。これで全サービスが削除され、そのホスト向けに発行されたすべての証明書が破棄されます。
[root@server ~]# ipa host-del client.example.com
新しいホスト名が指定されたクライアントの再登録
- 必要に応じてマシンの名前を変更します。
- IdM クライアントとしてマシンを再登録します。「クライアントの IdM ドメインへの再登録」を参照してください。
- IdM サーバーで、「現在のサービスや keytab 設定の特定」で特定した各サービスの新規 keytab を追加します。
[root@server ~]# ipa service-add service_name/new_host_name
- 「現在のサービスや keytab 設定の特定」で割り当てた証明書のあるサービスに対して証明書を生成します。方法は以下のとおりです。
- IdM 管理者ツールを使用すること。 24章ユーザー、ホスト、およびサービス向け証明書の管理を参照してください。
certmongerユーティリティーを使用すること。『システムレベルの認証ガイド』 「CERTMONGER を使った作業」 または certmonger(8) の man ページを参照してください。
- 「現在のサービスや keytab 設定の特定」で特定したホストグループにクライアントを再度追加します。「ユーザーまたはホストグループメンバーの追加および削除」を参照してください。
第4章 Identity Management のレプリカのインストールとアンインストール
注記
ipa-backup ユーティリティーがあります。これは、レプリカから IdM デプロイメントを再構築できない場合に主に推奨されるソリューションです。
4.1. IdM レプリカの説明
注記

図4.1 サーバーとレプリカの合意
4.2. レプリカに関するデプロイメントの考慮事項
4.2.1. トポロジーにおけるサーバーサービスのディストリビューション

図4.2 異なるサービスが含まれるレプリカ
レプリカ上の CA サービス
警告
- たとえば、統合された IdM CA がルート証明局としてサーバーに含まれる場合には、レプリカはこの統合された CA をルート証明局としてインストールする必要があります。
- サポートされる CA 設定オプションは「CA 設定の決定」を参照してください。
4.2.2. レプリカトポロジーの推奨事項
- 単一の IdM ドメインでレプリカ 61 個以上設定しない
- Red Hat は、レプリカが最大 60 個含まれる環境のサポートを保証します。
- レプリカごとに 最低で 2 つ、最大 4 つ のレプリカ合意を設定する
- 追加のレプリカ合意を設定すると、最初のレプリカとマスターサーバーの間だけでなく、他のレプリカとの間でも情報が複製されます。
- サーバー A からレプリカ B を作成してから、サーバー A からレプリカ C を作成する場合には、レプリカ B と C は直接連携されていないので、レプリカ B からのデータを先にサーバー A に複製してからレプリカ C に伝搬する必要があります。

図4.3 レプリカ B と C はレプリカ合意で連携されていない
レプリカ B とレプリカ C の間で追加のレプリカ合意を設定すると、データは直接複製され、データの可用性、一貫性、フェールオーバーの耐性、パフォーマンスを向上します。
図4.4 レプリカ B および C がレプリカ合意で連携されている
レプリカ合意の管理に関する詳細は6章レプリケーショントポロジーの管理を参照してください。
レプリカごとにレプリカ合意を 5 つ以上設定する必要はありません。サーバーに設定されるレプリカ合意が増えても、追加で大幅な利点がもたらされるわけではありません。これは、1 台のマスターが一度に更新できるのは、消費者サーバー 1 台のみで、他の合意はその間アイドルかつ待機状態となっているからです。また、レプリカ合意を多く設定しすぎると、全体的なパフォーマンスに悪影響を与える可能性があります。注記
ipa topologysuffix-verifyコマンドは、トポロジーが最も重要な推奨事項に対応しているかどうかをチェックします。詳細は、ipa topologysuffix-verify --helpを実行してください。このコマンドでは、トポロジーのサフィックスを指定する必要があります。詳細は「レプリカ合意、トポロジーサフィックス、およびトポロジーセグメント」を参照してください。

図4.5 トポロジーの例
4.2.2.1. タイトセルトポロジー
- 各セルは タイトセル になります。タイトセルでは、全サーバーに相互のレプリカ合意が設定されています。
- 各サーバーは、セルの 外部 にある別のサーバーとのレプリカ合意があります。これにより、セルはすべてドメイン内の他の全セルと疎結合されるようになります。
- 各メインオフィス、データセンター、地域に、少なくとも 1 つの IdM サーバーを用意します。可能であれは、2 台の IdM サーバーを用意します。
- 各データセンターに用意するサーバーは 4 台までとします。
- 小規模なオフィスでは、レプリカを使用するのではなく、SSSD を使用して認証情報をキャッシュして、データのバックエンドとしてオフサイトの IdM サーバーを使用します。
4.3. レプリカのインストールの前提条件
- レプリカは、IdM と同じか、最新バージョンを実行している必要があります。
- たとえば、マスターサーバーは Red Hat Enterprise Linux 7 で実行されており、IdM 4.4 パッケージを使用する場合には、レプリカは Red Hat Enterprise Linux 7 以降のバージョンで実行し、IdM のバージョン 4.4 以降を使用する必要があります。これにより、サーバーからレプリカに設定が正しくコピーされるようになります。
重要
IdM は、マスターのバージョンより前のバージョンのレプリカ作成をサポートしません。以前のバージョンを使ってレプリカを作成しようとすると、インストールが失敗します。 - レプリカには、追加でポートを解放しておく必要があります。
- 「ポート要件」の説明にある標準の IdM サーバーポート要件に加え、以下も満たす必要があります。
- ドメインレベル 0 では、レプリカ設定プロセス中は TCP ポート 22 を解放した状態にしておいてください。このポートは、マスターサーバーへの接続に SSH を使用するために必要です。
注記
ドメインレベルの詳細は7章ドメインレベルの表示と引き上げを参照してください。 - サーバーの中の 1 台において Red Hat Enterprise Linux 6 を実行し、CA をインストールしている場合には、レプリカの設定時とその後は TCP ポート 7389 も解放するようにしてください。Red Hat Enterprise Linux 7 環境では、ポート 7389 は必要ありません。
firewall-cmdユーティリティーを使用してポートを解放する方法は「ポート要件」を参照してください。
4.4. レプリカのインストールに必要なパッケージ
4.5. レプリカの作成: 概要
ipa-replica-install ユーティリティーを使用して、既存の IdM サーバーから新しいレプリカをインストールします。
注記
- 既存の IdM クライアント。クライアントをレプリカに プロモート してください (「既存のクライアントからレプリカへのプロモート」参照)。
- IdM ドメインに登録されていないマシン (「クライアントでないマシンへのレプリカのインストール」参照)。
ipa-replica-install にオプションを追加することでレプリカをカスタマイズできます (「ユースケースに適したレプリカの設定の際に ipa-replica-install を使用する方法」参照)。
重要
ipa-replica-install を実行してからトラストエージェントとしてレプリカを設定します。『Windows 統合ガイド』の「信頼コントローラーおよび信頼エージェント」を参照してください。
既存のクライアントからレプリカへのプロモート
- 特権ユーザーの認証情報を指定
- デフォルトの特権ユーザーは
adminです。ユーザーの認証情報を提示する方法は複数あります。- IdM がプロンプトで対話式に認証情報を求める方法
注記
これは特権ユーザーの認証情報を指定するデフォルトの方法です。ipa-replica-installの実行時に認証情報が提示されていない場合には、インストールの際に自動的にプロンプトが表示されます。 - クライアントで
ipa-replica-installを実行する前にユーザーとしてログインします。$ kinit admin
- ユーザーのプリンシパル名とパスワードを
ipa-replica-installに直接追加する方法# ipa-replica-install --principal admin --admin-password admin_password
ipaserversホストグループへのクライアントの追加ipaserversのメンバーは、特権ユーザーの認証情報とよく似た特権にマシンを昇格します。ユーザーの認証情報を指定する必要はありません。
クライアントでないマシンへのレプリカのインストール
ipa-replica-install では最初にクライアントとしてマシンを登録してから、レプリカのコンポーネントをインストールします。
- 特権ユーザーの認証情報を指定
- デフォルトの特権ユーザーは
adminです。認証情報を指定するには、プリンシパル名とパスワードをipa-replica-installに直接追加します。# ipa-replica-install --principal admin --admin-password admin_password
- クライアントの任意パスワードの指定
- レプリカをインストールする前にサーバーで無作為のパスワードを生成する必要があります。インストール時にはユーザーの認証情報を指定する必要はありません。
ipa-replica-install に以下のオプションを追加します。
--server: サーバーの完全修飾ドメイン名 (FQDN)--domain: IdM DNS ドメイン
ユースケースに適したレプリカの設定の際に ipa-replica-install を使用する方法
ipa-replica-install を実行すると、基本的なサーバーサービスのみが設定されます。DNS および証明局 (CA) などの追加のサービスをインストールするには ipa-replica-install にオプションを追加します。
警告
- 「CA を設定したレプリカのインストール」:
--setup-caの使用 - 「CA がインストールされていないサーバーからのレプリカのインストール」:
--dirsrv-cert-file、--dirsrv-pin、--http-cert-fileおよび--http-pinの使用
4.5.1. ホストの keytab を使用してレプリカにクライアントをプロモートする方法
- 既存のサーバー上で:
- 管理者としてログインします。
$ kinit admin
- クライアントマシンを
ipaserversのホストグループに追加します。$ ipa hostgroup-add-member ipaservers --hosts client.example.com Host-group: ipaservers Description: IPA server hosts Member hosts: server.example.com, client.example.com ------------------------- Number of members added 1 -------------------------
ipaserversのメンバーは、管理者の認証情報とよく似た特権にマシンを昇格します。
- クライアント上で
ipa-replica-installユーティリティーを実行します。# ipa-replica-install
4.5.2. 無作為のパスワードを使用したレプリカのインストール
- 既存のサーバー上で:
- 管理者としてログインします。
$ kinit admin
- IdM ホストとして新規マシンを追加します。
--randomオプションを指定してipa host-addコマンドを使用して、レプリカのインストールに使用する無作為のワンタイムパスワードを生成します。$ ipa host-add client.example.com --random -------------------------------------------------- Added host "client.example.com" -------------------------------------------------- Host name: client.example.com Random password: W5YpARl=7M.n Password: True Keytab: False Managed by: server.example.com生成パスワードは、IdM ドメインへのマシン登録に使用した後は無効になります。登録が完了すると正しいホストの keytab に置き換えられます。 - マシンを
ipaserversのホストグループに追加します。$ ipa hostgroup-add-member ipaservers --hosts client.example.com Host-group: ipaservers Description: IPA server hosts Member hosts: server.example.com, client.example.com ------------------------- Number of members added 1 -------------------------
ipaserversのメンバーは、必須サーバーサービスの設定に必要な特権にマシンを昇格します。
- レプリカのインストール先のマシンで
ipa-replica-installを実行して、--passwordオプションを使用して無作為パスワードを指定します。特殊文字が含まれることが多いので、一重引用符 (') でパスワードを括るようにしてください。# ipa-replica-install --password 'W5YpARl=7M.n'
4.5.3. DNS ありのレプリカのインストール
- 以下のオプションを指定して
ipa-replica-installを実行します。--setup-dnsは、存在しない場合には DNS ゾーンを作成して、DNS サーバーとしてレプリカを設定します。--forwarderはフォワーダーを指定します。フォワーダーを使用しない場合には--no-forwarderを指定します。フェールオーバーに対応するために複数のフォワーダーを指定するには--forwarderを複数回使用します。
例を示します。# ipa-replica-install --setup-dns --forwarder 192.0.2.1
注記
ipa-replica-installユーティリティーは、--no-reverseまたは--no-host-dnsなど、DNS 設定関連する、その他の複数のオプションに対応します。詳しい情報は ipa-replica-install(1) の man ページを参照してください。 - DNS を有効にして最初のサーバーを作成した場合には、適切な DNS エントリーを使用して自動的にレプリカが作成されます。これらのエントリーにより、IdM クライアントは新規サーバーを検出できるようになります。DNS を有効にせずに最初のサーバーを作成した場合には、手動で DNS レコードを追加します。以下の DNS レコードがドメインサービスに必要です。
_ldap._tcp_kerberos._tcp_kerberos._udp_kerberos-master._tcp_kerberos-master._udp_ntp._udp_kpasswd._tcp_kpasswd._udp
以下の例では、エントリーの存在を確認する方法を説明します。- DOMAIN および NAMESERVER 変数に適切な値を設定します。
# DOMAIN=example.com # NAMESERVER=replica
- 以下のコマンドを使用して、DNS エントリーの有無を確認します。
# for i in _ldap._tcp _kerberos._tcp _kerberos._udp _kerberos-master._tcp _kerberos-master._udp _ntp._udp ; do dig @${NAMESERVER} ${i}.${DOMAIN} srv +nocmd +noquestion +nocomments +nostats +noaa +noadditional +noauthority done | egrep "^_" _ldap._tcp.example.com. 86400 IN SRV 0 100 389 server1.example.com. _ldap._tcp.example.com. 86400 IN SRV 0 100 389 server2.example.com. _kerberos._tcp.example.com. 86400 IN SRV 0 100 88 server1.example.com. ...
- オプションであるが推奨: レプリカが利用できないときのために、バックアップサーバーとして他の DNS サーバーを手動で追加してください。「ネームサーバーの追加設定」を参照してください。これは、新規レプリカが IdM ドメインで最初の DNS サーバーの場合には特に推奨されます。
4.5.4. CA を設定したレプリカのインストール
--setup-caオプションを指定して、ipa-replica-installを実行します。[root@replica ~]# ipa-replica-install --setup-ca
- サーバー上の IdM CA が root CA でも、外部の CA に従属する CA の場合でも、
--setup-caオプションを指定すると、最初のサーバーの設定から CA 設定がコピーされます。注記
サポートされる CA 設定に関する詳細は「CA 設定の決定」を参照してください。
4.5.5. CA がインストールされていないサーバーからのレプリカのインストール
重要
ipa-replica-installを実行して、以下のオプションを追加して必要な証明書ファイルを指定します。--dirsrv-cert-file--dirsrv-pin--http-cert-file--http-pin
これらのオプションを使用して指定するファイルに関する詳細は「CA なしでのインストール」を参照してください。例を示します。[root@replica ~]# ipa-replica-install \ --dirsrv-cert-file /tmp/server.crt \ --dirsrv-cert-file /tmp/server.key \ --dirsrv-pin secret \ --http-cert-file /tmp/server.crt \ --http-cert-file /tmp/server.key \ --http-pin secret注記
--ca-cert-fileオプションを追加しないでください。ipa-replica-installユーティリティーは、マスターサーバーから証明書のこの部分の情報を自動的に取得します。
4.6. 新規レプリカのテスト
- サーバーの 1 つでユーザーを作成します。
[admin@server1 ~]$ ipa user-add test_user --first=Test --last=User
- ユーザーが他のサーバーにも表示されるようにします。
[admin@server2 ~]$ ipa user-show test_user
4.7. レプリカのアンインストール
パート III. サーバーの管理
第5章 IdM サーバーおよびサービスの基本的な管理
5.1. IdM サーバーの起動と停止
ipactl ユーティリティーを使用します。
# ipactl start
# ipactl stop
# ipactl restart
systemctl ユーティリティーを使用してください。たとえば、Directory Server の動作をカスタマイズする際など、systemctl を使用して個別サービスを管理すると便利です。設定を変更すると、Directory Server インスタンスを再起動する必要がありますが、全 IdM サービスを再起動する必要はありません。
重要
ipactl を使用することを推奨しています。IdM サーバーにインストールされているサービス間での依存関係により、サービスを停止、開始する順番は極めて重要です。ipactl ユーティリティーは、サービスが適切な順番に開始、停止されるようにします。
5.2. Kerberos を使用した IdM へのログイン
kinit の使用
kinit ユーティリティーを使用します。
注記
kinit を使用するには、krb5-workstation パッケージをインストールしておく必要があります。
kinit では、ローカルシステムで現在ログイン中のユーザー名を使用して IdM にログインします。たとえば、ローカルシステムに local_user としてログインしている場合に、kinit を実行すると、local_user IdM ユーザーとして認証が試行されます。
[local_user@server ~]$ kinit Password for local_user@EXAMPLE.COM:
注記
kinit ユーティリティーを実行してください。たとえば、admin ユーザーとしてログインするには、以下を実行します。
[local_user@server ~]$ kinit admin Password for admin@EXAMPLE.COM:
Kerberos チケットの自動取得
pam_krb5 の PAM (Pluggable Authentication Module) および SSSD を設定することができます。これにより、ログイン後に kinit を実行する必要がなくなります。
複数の Kerberos チケットの保管
kinit を実行すると必ず、Kerberos は現在保存されているチケットを新しいチケットに置き換えます。たとえば kinit を使用して user_A として認証を行った場合に、user_B に対して認証を行うと user_A のチケットはなくなります。
export KRB5CCNAME=path_to_different_cacheコマンドを使用してからkinitを実行し、チケットを取得します。kinit -c path_to_different_cacheコマンドを実行してから、KRB5CCNAME変数をリセットしてください。
kdestroyコマンドを実行します。unset $KRB5CCNAMEコマンドを使用して、デフォルトの認証キャッシュの場所を復元します。
現在ログインしているユーザーの確認
klist ユーティリティーを使用してキャッシュされたチケットを表示します。以下の例では、キャッシュに user_A のチケットが含まれ、user_A のみが IdM サービスにアクセスできます。
$ klist
Ticket cache: KEYRING:persistent:0:0
Default principal: user_A@EXAMPLE.COM
Valid starting Expires Service principal
11/10/2015 08:35:45 11/10/2015 18:35:45 krbtgt/EXAMPLE.COM@EXAMPLE.COM5.3. IdM コマンドラインユーティリティー
ipa と呼ばれます。ipa スクリプトは、複数のサブコマンドの親スクリプトで、これらのサブコマンドを使用して IdM を管理します。たとえば、ipa user-add コマンドは新規ユーザーを追加します。
$ ipa user-add user_name
注記
ipa サブコマンドの概要のみを説明します。詳しい情報は、各 IdM 管理エリア専用の他のセクションを参照してください。たとえば、ipa サブコマンドを使用したユーザーエントリーの詳しい情報は11章ユーザーアカウントの管理を参照してください。
5.3.1. ipa コマンドのヘルプ
ipa スクリプトでは、サブコマンドの特定のセット (トピック) に関するヘルプを表示できます。利用可能なトピックの一覧を表示するには、ipa help topics コマンドを使用します。
$ ipa help topics automember Auto Membership Rule. automount Automount caacl Manage CA ACL rules. ...
ipa help topic_name コマンドを使用します。たとえば、automember トピックに関する情報を表示するには、以下を実行します。
$ ipa help automember Auto Membership Rule. Bring clarity to the membership of hosts and users by configuring inclusive or exclusive regex patterns, you can automatically assign a new entries into a group or hostgroup based upon attribute information. ... EXAMPLES: Add the initial group or hostgroup: ipa hostgroup-add --desc="Web Servers" webservers ipa group-add --desc="Developers" devel ...
ipa スクリプトは、利用可能な ipa コマンドの一覧も表示できます。これには、ipa help commands コマンドを使用します。
$ ipa help commands automember-add Add an automember rule. automember-add-condition Add conditions to an automember rule. ...
ipa コマンドに関する詳しいヘルプは、以下のようにコマンドに --help オプションを指定します。
$ ipa automember-add --help Usage: ipa [global-options] automember-add AUTOMEMBER-RULE [options] Add an automember rule. Options: -h, --help show this help message and exit --desc=STR A description of this auto member rule ...
ipa ユーティリティーに関する詳しい情報は、ipa(1) の man ページを参照してください。
5.3.2. 値のリストの設定
ipaUserSearchFields: uid,givenname,sn,telephonenumber,ou,title
- 以下のように、同じコマンド呼び出しで複数回、引数を指定します。
$ ipa permission-add --permissions=read --permissions=write --permissions=delete - リストを中括弧で囲みます。これでシェルによる拡張が可能になります。例を示します。
$ ipa permission-add --permissions={read,write,delete}
5.3.3. 特殊文字の使用
ipa コマンドで、山括弧 (< および >)、アンパサンド (&)、アステリスク (*)、パイプ (|) などの特殊文字が含まれるコマンドラインの引数を指定すると、バックスラッシュ (\) を使用してこのような特殊文字をエスケープする必要があります。以下のように、アステリスク (*) をエスケープします。
$ ipa certprofile-show certificate_profile --out=exported\*profile.cfg5.3.4. IdM エントリーの検索
IdM エントリーの表示
ipa *-find コマンドを使用して、特定のタイプの IdM エントリーを検索します。以下に例を示します。
- 全ユーザーを表示します。
$ ipa user-find --------------- 4 users matched --------------- ...
- 指定の属性に
keywordが含まれるユーザーグループを表示するには、以下を実行します。$ ipa group-find keyword ---------------- 2 groups matched ---------------- ...
IdM がユーザーおよびユーザーグループを検索するための属性を設定するには、「ユーザーおよびユーザーグループの検索属性の設定」を参照してください。
$ ipa group-find --user=user_name
$ ipa group-find --no-user=user_name
特定のエントリーの詳細表示
ipa *-show コマンドを使用します。
$ ipa host-show server.example.com Host name: server.example.com Principal name: host/server.example.com@EXAMPLE.COM ...
5.3.4.1. 検索サイズおよび時間制限の調整
ipa user-find などの ipa *-find コマンドを実行時や、Web UI で適切な一覧を表示する際に、全体的なサーバーのパフォーマンスを向上できます。
- クライアント、IdM コマンドラインツール、IdM Web UI からサーバーに送信される要求に対して、返される最大エントリー数を定義します。
- デフォルト値: エントリー数 100 件
- 検索の実行までにサーバーが待機する最大時間を定義します。検索がこの制限に到達したら、サーバーは検索を停止し、停止するまでの期間に検出されたエントリーを返します。
- デフォルト値: 2 秒
-1 に設定されている場合、IdM は検索時に制限を適用しません。
重要
Web UI: 検索サイズおよび時間制限の調整
- → を選択します。
- Search Options エリアに必要な値を設定します。
- ページ上部にある をクリックします。
コマンドライン: 検索サイズおよび時間制限の調整
--searchrecordslimit および --searchtimelimit オプションを指定して、ipa config-mod コマンドを実行します。
$ ipa config-mod --searchrecordslimit=500 --searchtimelimit=5
--sizelimit または --timelimit オプションを指定します。
$ ipa user-find --sizelimit=200 --timelimit=120
5.4. IdM Web UI
ipa コマンドラインユーティリティーにある大半の機能が含まれます。そのため、ユーザーは IdM の管理に UI またはコマンドラインのいずれかを選択できます。
注記
admin ユーザーおよびその他に管理者権限のあるユーザーは、すべての管理タスクを使用できます。通常のユーザーが使用できるのは、自身のユーザーアカウントに関する操作のみに限られます。
5.4.1. サポート対象の Web ブラウザー
- Mozilla Firefox 38 以降
- Google Chrome 46 以降
5.4.2. Web UI へのアクセスおよび認証
5.4.2.1. Web UI へのアクセス
https://server.example.com

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

図5.2 IdM Web UI のレイアウト
5.4.2.3. AD ユーザーとしての IdM Web UI への認証
[admin@server ~]$ ipa idoverrideuser-add 'Default Trust View' ad_user@ad.example.com5.4.3. Kerberos 認証用のブラウザーの設定

図5.3 Kerberos 認証エラーメッセージ
- IdM web UI から自動的に設定。このオプションは、Firefox でのみ利用できます。詳細は「Web UI の Firefox での自動設定」を参照してください。
- IdM クライアントのインストール中にコマンドラインから自動的に設定。このオプションは、Firefox でのみ利用できます。詳細は「コマンドラインからの Firefox 自動設定」を参照してください。
- Firefox オプション設定で手動設定。このオプションは、サポートされているブラウザーすべてで利用できます。詳細は「手動によるブラウザーの設定」を参照してください。
注記
Web UI の Firefox での自動設定
- Web UI のログイン画面でブラウザー設定のリンクをクリックします。

図5.4 Web UI でのブラウザー設定へのリンク
- Firefox の設定リンクを選択して、Firefox 設定ページを開きます。

図5.5 Firefox 設定ページへのリンク
- Firefox 設定ページの手順に従います。
コマンドラインからの Firefox 自動設定
ipa-client-install ユーティリティーで IdM クライアントをインストールする際に --configure-firefox オプションを使用します。
# ipa-client-install --configure-firefox
--configure-firefox オプションは、シングルサインオン (SSO) での Kerberos を有効化するデフォルトの Firefox 設定で、グローバル設定ファイルを作成します。
手動によるブラウザーの設定
- Web UI のログイン画面でブラウザー設定のリンクをクリックします。

図5.6 Web UI でのブラウザー設定へのリンク
- 手動でのブラウザー設定のリンクを選択します。

図5.7 手動設定ページヘのリンク
- ブラウザーの設定の説明を探して、手順に従います。
5.4.4. Web UI への Kerberos 認証用の外部システム設定
- 以下のように、IdM サーバーから外部マシンに
/etc/krb5.confファイルをコピーします。# scp /etc/krb5.conf root@externalmachine.example.com:/etc/krb5_ipa.conf
警告
外部マシンの既存のkrb5.confファイルは上書きしないでください。 - 外部マシン上で、端末のセッションがコピーされた IdM Kerberos 設定ファイルを使用するよう設定します。
$ export KRB5_CONFIG=/etc/krb5_ipa.conf
- 「Kerberos 認証用のブラウザーの設定」で記載されているように、外部マシンのブラウザーを設定します。
kinit ユーティリティーを使用できるようになりました。
5.4.5. Web UI でのプロキシーサーバーおよびポート転送
ssh ユーティリティーに -D オプションを指定して設定できます。-D オプションの使用に関する詳細は、ssh(1) の man ページを参照してください。
第6章 レプリケーショントポロジーの管理
注記
6.1. レプリカ合意、トポロジーサフィックス、およびトポロジーセグメント
レプリカ合意
注記
トポロジーサフィックス
domain および ca の 2 つのタイプのサフィックスをサポートしています。各サフィックスは、別個のバックエンドと別個のレプリカトポロジーを表しています。
domainサフィックス: dc=example,dc=comdomainサフィックスには、ドメイン関連データすべてが含まれます。2 つのレプリカのdomainサフィックス間でレプリカ合意が設定されると、ユーザー、グループ、およびポリシーなどのディレクトリーデータが共有されます。caサフィックス: o=ipacacaサフィックスには、 Certificate System コンポーネント用のデータが含まれます。これは、証明局 (CA) がインストールされているサーバーにのみ存在します。2 つのレプリカのcaサフィックス間でレプリカ合意が設定されると、証明書データが共有されます。

図6.1 トポロジーサフィックス
ipa-replica-install スクリプトが 2 つのサーバー間に初期トポロジーセグメントをセットアップします。
例6.1 トポロジーサフィックスの表示
ipa topologysuffix-find コマンドでトポロジーサフィックスの一覧が表示されます。
$ ipa topologysuffix-find --------------------------- 2 topology suffixes matched --------------------------- Suffix name: ca Managed LDAP suffix DN: o=ipaca Suffix name: domain Managed LDAP suffix DN: dc=example,dc=com ---------------------------- Number of entries returned 2 ----------------------------
トポロジーセグメント

図6.2 トポロジーセグメント
例6.2 トポロジーセグメントの表示
ipa topologysegment-find コマンドで、domain または CA サフィックスに設定されたトポロジーセグメントが表示されます。たとえば、domain サフィックスの場合は以下のようになります。
$ ipa topologysegment-find Suffix name: domain ----------------- 1 segment matched ----------------- Segment name: server1.example.com-to-server2.example.com Left node: server1.example.com Right node: server2.example.com Connectivity: both ---------------------------- Number of entries returned 1 ----------------------------
server1.example.com と server1.example.com の 2 つのサーバー間で複製されます。
ipa topologysegment-show コマンドを使用します。
$ ipa topologysegment-show Suffix name: domain Segment name: server1.example.com-to-server2.example.com Segment name: server1.example.com-to-server2.example.com Left node: server1.example.com Right node: server2.example.com Connectivity: both
6.2. Web UI: トポロジーグラフを使用したレプリカトポロジーの管理
トポロジーグラフへのアクセス
- → → を選択します。
- トポロジーに加えた変更がグラフに反映されていない場合は、 をクリックします。
トポロジービューのカスタマイズ

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

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

図6.5 トポロジーグラフの移動
トポロジーグラフの意味
- トポロジーグラフの推奨例
- 図6.6「トポロジーの推奨例」 は、4 つのサーバーにおけるトポロジーの推奨例を示しています。各サーバーは少なくとも 2 台のサーバーに連結されており、複数のサーバーが CA マスターとなっています。

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

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

図6.9 新セグメントの作成
- Add Topology Segment ウィンドウで をクリックして、新セグメントの属性を確認します。

図6.10 新規セグメント作成後のグラフ
6.2.2. 2 サーバー間のレプリカの削除
- 削除するレプリカ合意を表す矢印をクリックします。矢印がハイライト表示されます。

図6.11 トポロジーセグメントのハイライト表示
- をクリックします。
- Confirmation ウィンドウで をクリックします。

図6.12 トポロジーセグメントの削除
6.3. コマンドライン: ipa topology* コマンドを使用したトポロジーの管理
6.3.1. トポロジー管理コマンドのヘルプ
$ ipa help topology
--help オプションと実行します。
$ ipa topologysuffix-show --help
6.3.2. 2 サーバー間でのレプリカ設定
- 2 サーバー間のトポロジーセグメントを作成するには、
ipa topologysegment-addコマンドを使用します。プロンプトに応じて、以下を提供します。domainまたはcaのトポロジーサフィックス注記
caサフィックス間でセグメントを作成する場合は、両方のサーバーに CA がインストールされている必要があります。「CA の既存の IdM ドメインへのインストール」 を参照してください。- 各サーバーを表す左ノードと右ノード
- オプションで、セグメントのカスタム名
以下に例を示します。$ ipa topologysegment-add Suffix name: domain Left node: server1.example.com Right node: server2.example.com Segment name [server1.example.com-to-server2.example.com]: new_segment --------------------------- Added segment "new_segment" --------------------------- Segment name: new_segment Left node: server1.example.com Right node: server2.example.com Connectivity: both
新規セグメントを追加すると、サーバーがレプリカ合意に参加します。 - オプションで
ipa topologysegment-showコマンドを使用すると、新規セグメントが設定されたことを確認することができます。$ ipa topologysegment-show Suffix name: domain Segment name: new_segment Segment name: new_segment Left node: server1.example.com Right node: server2.example.com Connectivity: both
6.3.3. 2 サーバー間のレプリカの削除
- レプリケーションを停止するには、対応するサーバー間のレプリカセグメントを削除する必要があります。これを実行するには、セグメント名が必要になります。セグメント名が分からない場合は、
ipa topologysegment-findコマンドを実行して全セグメントを表示し、該当するセグメントを見つけます。プロンプトに応じて、domainまたはcaのトポロジーサフィックスを提供します。例を示します。$ ipa topologysegment-find Suffix name: domain ------------------ 8 segments matched ------------------ Segment name: new_segment Left node: server1.example.com Right node: server2.example.com Connectivity: both ... ---------------------------- Number of entries returned 8 ---------------------------- - 2 サーバー間のトポロジーセグメントを削除るには、
ipa topologysegment-delコマンドを使用します。$ ipa topologysegment-del Suffix name: domain Segment name: new_segment ----------------------------- Deleted segment "new_segment" -----------------------------
セグメントを削除すると、レプリカ合意が削除されます。 - オプションで
ipa topologysegment-findコマンドを使用すると、セグメントが削除されたことを確認することができます。$ ipa topologysegment-find Suffix name: domain ------------------ 7 segments matched ------------------ Segment name: server2.example.com-to-server3.example.com Left node: server2.example.com Right node: server3.example.com Connectivity: both ... ---------------------------- Number of entries returned 7 ----------------------------
6.4. トポロジーからサーバーを削除する
- 削除されるサーバーが、トポロジーと他のサーバーを結んでいる唯一のサーバーである場合。この場合に当該サーバーが削除されると、他のサーバーは孤立してしまうため、これは許可されません。
- 削除されるサーバーが最後の CA または DNS サーバーである場合。
$ ipa server-del
Server name: server1.example.com
Removing server1.example.com from replication topology, please wait...
ipa: ERROR: Server removal aborted:
Removal of 'server1.example.com' leads to disconnected topology in suffix 'domain':
Topology does not allow server server2.example.com to replicate with servers:
server3.example.com
server4.example.com
...6.4.1. Web UI: トポロジーからサーバーを削除する
- → → を選択します。
- 削除するサーバー名をクリックします。

図6.13 サーバーの選択
- をクリックします。
6.4.2. コマンドライン: トポロジーからサーバーを削除する
重要
server1.example.com を削除するには、以下を実行します。
- 別のサーバーで
ipa server-delコマンドを実行してserver1.example.comを削除します。このコマンドで、当該サーバーをポイントしているすべてのトポロジーセグメントが削除されます。[user@server2 ~]$ ipa server-del Server name: server1.example.com Removing server1.example.com from replication topology, please wait... ---------------------------------------------------------- Deleted IPA server "server1.example.com" ----------------------------------------------------------
server1.example.comでipa server-install --uninstallコマンドを実行して、マシンからこのサーバーコンポーネントをアンインストールします。[root@server1 ~]# ipa server-install --uninstall
6.5. サーバーロールの管理
6.5.1. サーバーロールの表示
Web UI: サーバーロールの表示
- Role status が absent の場合は、トポロジー内でそのロールを実行しているサーバーがないことを示しています。
- Role status が enabled の場合は、トポロジー内でそのロールを実行しているサーバーが 1 台以上あることを示しています。

図6.14 Web UI でのサーバーロール
コマンドライン: サーバーロールの表示
ipa config-show コマンドを実行すると、すべての CA サーバー、NTP サーバー、および現行の CA 更新マスターが表示されます。
$ ipa config-show ... IPA masters: server1.example.com, server2.example.com, server3.example.com IPA CA servers: server1.example.com, server2.example.com IPA NTP servers: server1.example.com, server2.example.com, server3.example.com IPA CA renewal master: server1.example.com
ipa server-show コマンドを実行すると、特定サーバーで有効になっているロール一覧が表示されます。たとえば、server.example.com で有効になっているロールを表示するには、以下を実行します。
$ ipa server-show
Server name: server.example.com
...
Enabled server roles: CA server, DNS server, NTP server, KRA serveripa server-find --servrole は、特定のサーバーロールが有効になっているサーバーを検索します。たとえば、CA サーバーを検索するには、以下を実行します。
$ ipa server-find --servrole "CA server" --------------------- 2 IPA servers matched --------------------- Server name: server1.example.com ... Server name: server2.example.com ... ---------------------------- Number of entries returned 2 ----------------------------
6.5.2. レプリカのマスター CA サーバーへのプロモート
注記
- レプリカが CA サブシステムの証明書更新を処理するよう設定します。
- ドメインレベル 1 については、「現行 CA 更新マスターの変更」 を参照してください。
- ドメインレベル 0 については、「証明書更新を処理するサーバーの変更」 を参照してください。
- レプリカが CRL を生成するように設定します。「CRL を生成するサーバーの変更」 を参照してください。
- 今までのマスター CA サーバーの使用を停止する前に、新規マスターが正常に機能することを確認します。「新規マスター CA サーバーの設定確認」 を参照してください。
6.5.2.1. 現行 CA 更新マスターの変更
Web UI: 現行 CA 更新マスターの変更
- → を選択します。
- IPA CA renewal master フィールドで、新規 CA 更新マスターを選択します。
コマンドライン: 現行 CA 更新マスターの変更
ipa config-mod --ca-renewal-master-server コマンドを使用します。
$ ipa config-mod --ca-renewal-master-server new_ca_renewal_master.example.com
...
IPA masters: old_ca_renewal_master.example.com, new_ca_renewal_master.example.com
IPA CA servers: old_ca_renewal_master.example.com, new_ca_renewal_master.example.com
IPA NTP servers: old_ca_renewal_master.example.com, new_ca_renewal_master.example.com
IPA CA renewal master: new_ca_renewal_master.example.com6.5.2.2. CRL を生成するサーバーの変更
現行 CRL 生成マスターの特定
/etc/pki/pki-tomcat/ca/CS.cfg ファイルをチェックします。
- CRL 生成マスターで、
ca.crl.MasterCRL.enableCRLUpdatesパラメーターをtrueに設定します。# grep ca.crl.MasterCRL.enableCRLUpdates /etc/pki/pki-tomcat/ca/CS.cfg ca.crl.MasterCRL.enableCRLUpdates=true - CRL 生成クローンでパラメーターを
falseに設定します。
現行 CRL 生成マスターで CRL 生成を停止する
- CA サービスを停止します。
# systemctl stop pki-tomcatd@pki-tomcat.service
- サーバー上での CRL 生成を無効にします。
/etc/pki/pki-tomcat/ca/CS.cfgファイルを開いて、ca.crl.MasterCRL.enableCRLCacheとca.crl.MasterCRL.enableCRLUpdatesのパラメーターの値をfalseに設定します。ca.crl.MasterCRL.enableCRLCache=
falseca.crl.MasterCRL.enableCRLUpdates=false - CA サービスを起動します。
# systemctl start pki-tomcatd@pki-tomcat.service
- CRL リクエストを新規マスターにリダイレクトするように Apache を設定します。
/etc/httpd/conf.d/ipa-pki-proxy.confファイルを開いて、RewriteRule引数をコメント解除します。# Only enable this on servers that are not generating a CRL RewriteRule ^/ipa/crl/MasterCRL.bin https://server.example.com/ca/ee/ca/getCRL?op=getCRL&crlIssuingPoint=MasterCRL [L,R=301,NC]
- Apache を再起動します。
# systemctl restart httpd.service
サーバーが CRL を生成するように設定する
- CA サービスを停止します。
# systemctl stop pki-tomcatd@pki-tomcat.service
- サーバー上での CRL 生成を有効にします。
ca.crl.MasterCRL.enableCRLCacheとca.crl.MasterCRL.enableCRLUpdatesのパラメーターの値をtrueに設定します。ca.crl.MasterCRL.enableCRLCache=true ca.crl.MasterCRL.enableCRLUpdates=true
- CA サービスを起動します。
# systemctl start pki-tomcatd@pki-tomcat.service
- Apache で CRL リクエストのリダイレクトを無効にします。
/etc/httpd/conf.d/ipa-pki-proxy.confファイルを開いて、RewriteRule引数をコメントアウトします。#RewriteRule ^/ipa/crl/MasterCRL.bin https://server.example.com/ca/ee/ca/getCRL?op=getCRL&crlIssuingPoint=MasterCRL [L,R=301,NC]この手順の前までは、全 CRL リクエストは以前の CA マスターにルーティングされていましたが、これでこのサーバーが CRL リクエストに対応するようになりました。 - Apache を再起動します。
# systemctl restart httpd.service
6.5.2.3. 新規マスター CA サーバーの設定確認
/var/lib/ipa/pki-ca/publish/MasterCRL.bin ファイルが新規マスター CA サーバーにあることを確認します。
/etc/pki/pki-tomcat/ca/CS.cfg ファイルで定義されている間隔を基に、ca.crl.MasterCRL.autoUpdateInterval パラメーターを使って生成されます。デフォルト値は、240 分 (4 時間) です。
第7章 ドメインレベルの表示と引き上げ
- ドメインレベル 1
- 利用可能な機能の例
- 簡素化された
ipa-replica-install(「レプリカの作成: 概要」 を参照) - 機能強化されたトポロジー管理 (6章レプリケーショントポロジーの管理 を参照)
重要
ドメインレベル 1 は、Red Hat Enterprise Linux 7.3 の IdM バージョン 4.4 で導入されました。ドメインレベル 1 の機能を使用するには、すべてのレプリカで Red Hat Enterprise Linux 7.3 以降を稼働している必要があります。最初のサーバーに Red Hat Enterprise Linux 7.3 がインストールされると、ドメインレベルは自動的に 1 に設定されます。すべてのサーバーを IdM の以前のバージョンから 4.4 にアップグレードしても、ドメインレベルは自動的に上げられません。ドメインレベル 1 の機能を使用するには、「ドメインレベルの引き上げ」 に記載の手順に従ってドメインレベルを手動で上げる必要があります。 - ドメインレベル 0
- 利用可能な機能の例
ipa-replica-installでは、初期サーバー上でレプリカ情報ファイルを作成し、これをレプリカにコピーするという複雑なプロセスが必要になります (「レプリカの作成」 を参照)。
7.1. 現行ドメインレベルの表示
コマンドライン: 現行ドメインレベルの表示
- 管理者としてログインします。
$ kinit admin
ipa domainlevel-getコマンドを実行します。$ ipa domainlevel-get ----------------------- Current domain level: 0 -----------------------
Web UI: 現行ドメインレベルの表示
7.2. ドメインレベルの引き上げ
重要
0 から 1 に引き上げると、1 から 0 にダウングレードすることはできません。
コマンドライン: ドメインレベルの引き上げ
- 管理者としてログインします。
$ kinit admin
ipa domainlevel-setコマンドを必要なレベルを提供して実行します。$ ipa domainlevel-set 1 ----------------------- Current domain level: 1 -----------------------
Web UI: ドメインレベルの引き上げ
- → を選択します。
- をクリックします。
第8章 Identity Management の更新と移行
8.1. Identity Management の更新
yum ユーティリティーを使用します。
yum は Identity Management サーバーやクライアントをこのバージョンにアップグレードします。
注記
8.1.1. Identity Management 更新 の注意点
- 少なくとも 1 台のサーバーで Identity Management パッケージを更新したら、トポロジーないの他のサーバーでパッケージを更新していなくても、これらのサーバーは更新されたスキーマを受信します。これにより、新スキーマを使用する新規エントリーを他のサーバー間で複製することが可能になります。
- Identity Management パッケージのダウングレードはサポートされていません。
重要
ipa-* パッケージにはyum downgradeコマンドを実行しないでください。 - Red Hat では、次のバージョンへのアップグレードのみを推奨しています。たとえば、Red Hat Enterprise Linux 7.4 用の Identity Management にアップグレードする場合には、Red Hat Enterprise Linux 7.3 用の Identity Management からアップグレードすることを推奨します。それ以前のバージョンからのアップグレードでは、問題が発生する可能性があります。
8.1.2. yum を使った Identity Management パッケージの更新
# yum update ipa-*警告
関連情報
重要
mod_nss モジュールで無効にする必要があります。次の手順に従い、無効になっていることを確認してください。
/etc/httpd/conf.d/nss.confファイルを編集してNSSProtocolパラメーターをTLSv1.0(後方互換用) およびTLSv1.1、TLSv1.2に設定します。NSSProtocol TLSv1.0,TLSv1.1,TLSv1.2
httpdサービスを再起動します。# systemctl restart httpd.service
yum update ipa-* コマンドを起動すると上記の手順が自動的に行われます。
8.2. Red Hat Enterprise Linux 6 からバージョン 7 への Identity Management の移行
- Red Hat Enterprise Linux 6 ベースの証明局 (CA) マスターサーバーの Red Hat Enterprise Linux 7 への移行。
- 新規 Red Hat Enterprise Linux 7 サーバーへの全サービスの移行。これらのサービスには、CRL と証明書の作成、DNS 管理、Kerberos KDC 管理などがあります。
- 元の Red Hat Enterprise Linux 6 CA マスターの停止。
rhel7.example.comは、新規 CA マスターとなる Red Hat Enterprise Linux 7 システムです。rhel6.example.comは、元の Red Hat Enterprise Linux 6 CA マスターです。注記
どの Red Hat Enterprise Linux 6 サーバーがマスター CA サーバーかを特定するには、どのサーバー上でcertmongerサービスがrenew_ca_certコマンドを追跡しているかを判定します。このコマンドをすべての Red Hat Enterprise Linux 6 サーバーで実行します。[root@rhel6 ~]#
getcert list -d /var/lib/pki-ca/alias -n "subsystemCert cert-pki-ca" | grep post-savepost-save command: /usr/lib64/ipa/certmonger/renew_ca_cert "subsystemCert cert-pki-ca"renew_ca_certを実行する post-save アクションは、CA マスターにのみ定義されています。
8.2.1. Identity Management の Red Hat Enterprise Linux 6 から 7 への移行の前提条件
rhel6.example.comシステムを Red Hat Enterprise Linux 6 の最新バージョンに更新します。rhel6.example.comシステムで、ipa-* パッケージをアップグレードします。[root@rhel6 ~]#
yum update ipa-*このステップにより、RHBA-2015:0231-2 アドバイザリーの適用も確認されます。これは、bind-dyndb-ldap パッケージの2.3-6.el6_6バージョンを提供するもので、Red Hat Enterprise Linux 6.6 Extended Update Support (EUS) と利用できます。警告
bind-dyndb-ldap の以前のバージョンを使用すると、Red Hat Enterprise Linux 6.6 DNS サーバーと Red Hat Enterprise Linux 7 DNS サーバー間における DNS 正引きゾーンの動作に一貫性がなくなります。rhel7.example.comシステムに必要なパッケージをインストールしてください。詳細は、「IdM サーバーのインストールに必要なパッケージ」 を参照してください。
8.2.2. Red Hat Enterprise Linux 6 上での Identity Management スキーマの更新
copy-schema-to-ca.py スキーマ更新スクリプトにより、rhel6.example.com での rhel7.example.com レプリカインストールを準備することができます。スキーマの更新は、Identity Management のバージョン 3.1 とそれ以降の間におけるスキーマの変更により必要となります。
copy-schema-to-ca.pyスキーマ更新スクリプトをrhel7.example.comシステムからrhel6.example.comシステムにコピーします。[root@rhel7 ~]#
scp /usr/share/ipa/copy-schema-to-ca.py root@rhel6:/root/- 更新された
copy-schema-to-ca.pyスクリプトをrhel6.example.com上で実行します。[root@rhel6 ~]#
python copy-schema-to-ca.pyipa : INFO Installed /etc/dirsrv/slapd-PKI-IPA//schema/60kerberos.ldif [... output truncated ...] ipa : INFO Schema updated successfully
8.2.3. Red Hat Enterprise Linux 7 レプリカのインストール
rhel6.example.comシステム上で、rhel7.example.comレプリカのインストールに使用するレプリカファイルを作成します。たとえば、rhel7.example.com用のレプリカファイルを作成します。このシステムの IP アドレスは192.0.2.1とします。[root@rhel6 ~]#
ipa-replica-prepare rhel7.example.com --ip-address 192.0.2.1Directory Manager (existing master) password: Preparing replica for rhel7.example.com from rhel6.example.com [... output truncated ...] The ipa-replica-prepare command was successful「レプリカ情報ファイル」 と 「レプリカの作成」 も参照してください。- レプリカ情報ファイルを
rhel6.example.comからrhel7.example.comにコピーします。[root@rhel6 ~]#
scp /var/lib/ipa/replica-info-replica.example.com.gpg root@rhel7:/var/lib/ipa/ - レプリカファイルを使用して
rhel7.example.comレプリカをインストールします。たとえば、この例では以下のオプションを使用しています。--setup-caは、Certificate System コンポーネントを設定します。--setup-dnsと--forwarderは、統合 DNS サーバーとフォワーダーを設定します。--ip-addressは、rhel7.example.comシステムの IP アドレスを指定します。
[root@rhel7 ~]#
ipa-replica-install /var/lib/ipa/replica-info-rhel7.example.com.gpg --setup-ca --ip-address 192.0.2.1 --setup-dns --forwarder 192.0.2.20Directory Manager (existing master) password: Checking DNS forwarders, please wait ... Run connection check to master [... output truncated ...] Client configuration complete.関連項目:- 「レプリカの作成」 では、レプリカ情報ファイルを使用したレプリカ作成について説明しています。
- Identity Management サービスが
rhel7.example.comで稼働していることを確認します。[root@rhel7 ~]#
ipactl statusDirectory Service: RUNNING [... output truncated ...] ipa: INFO: The ipactl command was successful
8.2.4. CA サービスの Red Hat Enterprise Linux 7 サーバーへの移行
rhel6.example.comとrhel7.example.comの両方の CA がマスターサーバーとして設定されていることを確認します。[root@rhel7 ~]$
kinit admin[root@rhel7 ~]$ipa-csreplica-manage listrhel6.example.com: master rhel7.example.com: masterレプリカ合意の詳細を表示するには、以下を実行します。[root@rhel7 ~]#
ipa-csreplica-manage list --verbose rhel7.example.comrhel7.example.com last init status: None last init ended: 1970-01-01 00:00:00+00:00 last update status: Error (0) Replica acquired successfully: Incremental update succeeded last update ended: 2017-02-13 13:55:13+00:00
rhel6.example.com の元のマスター CA で、CA サブシステムの証明書更新を停止します。
- 元の CA 証明書の追跡を無効にします。
[root@rhel6 ~]#
getcert stop-tracking -d /var/lib/pki-ca/alias -n "auditSigningCert cert-pki-ca"Request "20171127184547" removed. [root@rhel6 ~]#getcert stop-tracking -d /var/lib/pki-ca/alias -n "ocspSigningCert cert-pki-ca"Request "20171127184548" removed. [root@rhel6 ~]#getcert stop-tracking -d /var/lib/pki-ca/alias -n "subsystemCert cert-pki-ca"Request "20171127184549" removed. [root@rhel6 ~]#getcert stop-tracking -d /etc/httpd/alias -n ipaCertRequest "20171127184550" removed. rhel6.example.comを再設定して、新規マスター CA から更新された証明書を取得します。certmongerサービスディレクトリーに更新ヘルパースクリプトをコピーに、適切なパーミッションを設定します。[root@rhel6 ~]#
cp /usr/share/ipa/ca_renewal /var/lib/certmonger/cas/[root@rhel6 ~]#chmod 0600 /var/lib/certmonger/cas/ca_renewal- SELinux 設定を更新します。
[root@rhel6 ~]#
restorecon /var/lib/certmonger/cas/ca_renewal certmongerを再起動します。[root@rhel6 ~]#
service certmonger restart- CA が証明書を取得するようになっているかチェックします。
[root@rhel6 ~]#
getcert list-cas... CA 'dogtag-ipa-retrieve-agent-submit': is-default: no ca-type: EXTERNAL helper-location: /usr/libexec/certmonger/dogtag-ipa-retrieve-agent-submit - CA 証明書データベース PIN を取得します。
[root@rhel6 ~]#
grep internal= /var/lib/pki-ca/conf/password.conf certmongerが外部更新用の証明書を追跡するよう設定します。これには、データベース PIN が必要です。[root@rhel6 ~]#
getcert start-tracking \-c dogtag-ipa-retrieve-agent-submit \-d /var/lib/pki-ca/alias \-n "auditSigningCert cert-pki-ca" \-B /usr/lib64/ipa/certmonger/stop_pkicad \-C '/usr/lib64/ipa/certmonger/restart_pkicad \"auditSigningCert cert-pki-ca"' \-T "auditSigningCert cert-pki-ca" \-P database_pinNew tracking request "20171127184743" added. [root@rhel6 ~]#getcert start-tracking \-c dogtag-ipa-retrieve-agent-submit \-d /var/lib/pki-ca/alias \-n "ocspSigningCert cert-pki-ca" \-B /usr/lib64/ipa/certmonger/stop_pkicad \-C '/usr/lib64/ipa/certmonger/restart_pkicad \"ocspSigningCert cert-pki-ca"' \-T "ocspSigningCert cert-pki-ca" \-P database_pinNew tracking request "20171127184744" added. [root@rhel6 ~]#getcert start-tracking \-c dogtag-ipa-retrieve-agent-submit \-d /var/lib/pki-ca/alias \-n "subsystemCert cert-pki-ca" \-B /usr/lib64/ipa/certmonger/stop_pkicad \-C '/usr/lib64/ipa/certmonger/restart_pkicad \"subsystemCert cert-pki-ca"' \-T "subsystemCert cert-pki-ca" \-P database_pinNew tracking request "20171127184745" added. [root@rhel6 ~]#getcert start-tracking \-c dogtag-ipa-retrieve-agent-submit \-d /etc/httpd/alias \-n ipaCert \-C /usr/lib64/ipa/certmonger/restart_httpd \-T ipaCert \-p /etc/httpd/alias/pwdfile.txtNew tracking request "20171127184746" added.
rhel6.example.com CA マスターから rhel7.example.com に移動します。
rhel6.example.comで CRL 生成を停止します。- CA サービスを停止します。
[root@rhel6 ~]#
service pki-cad stop rhel6.example.com上での CRL 生成を無効にします。/var/lib/pki-ca/conf/CS.cfgファイルを開いて、ca.crl.MasterCRL.enableCRLCacheおよびca.crl.MasterCRL.enableCRLUpdatesのパラメーターの値をfalseに設定します。ca.crl.MasterCRL.enableCRLCache=
falseca.crl.MasterCRL.enableCRLUpdates=false- CA サービスを起動します。
[root@rhel6 ~]#
service pki-cad start
rhel6.example.comで、Apache が CRL リクエストを新しいマスターであるrhel7.example.comにリダイレクトするよう設定します。/etc/httpd/conf.d/ipa-pki-proxy.confファイルを開き、RewriteRule引数のコメントを解除します。サーバーホスト名をサーバー URL にあるrhel7.example.comホスト名で置き換えます。RewriteRule ^/ipa/crl/MasterCRL.bin https://rhel7.example.com/ca/ee/ca/getCRL?op=getCRL&crlIssuingPoint=MasterCRL [L,R=301,NC]
- Apache を再起動します。
[root@rhel6 ~]#
service httpd restart
rhel7.example.comでrhel7.example.comを新規 CA マスターとして設定します。- 「証明書更新を処理するサーバーの変更」 にあるように、
rhel7.example.comが CA サブシステムの証明書更新を処理するように設定します。 - 「サーバーが CRL を生成するように設定する」 にあるように、
rhel7.example.comが証明書失効リスト (CRL) を生成するように設定します。
関連情報
- CA サブシステム証明書更新および CRL についての詳細は、「レプリカのマスター CA サーバーへのプロモート」 を参照してください。
8.2.5. Red Hat Enterprise Linux 6 サーバーの停止
rhel6.example.com 上の全サービスを停止して、新規 rhel7.example.com サーバーへのドメイン検索を実施します。
[root@rhel6 ~]# ipactl stop
Stopping CA Service
Stopping pki-ca: [ OK ]
Stopping HTTP Service
Stopping httpd: [ OK ]
Stopping MEMCACHE Service
Stopping ipa_memcached: [ OK ]
Stopping DNS Service
Stopping named: . [ OK ]
Stopping KPASSWD Service
Stopping Kerberos 5 Admin Server: [ OK ]
Stopping KDC Service
Stopping Kerberos 5 KDC: [ OK ]
Stopping Directory Service
Shutting down dirsrv:
EXAMPLE-COM... [ OK ]
PKI-IPA... [ OK ]ipa ユーティリティーを使用すると、 Remote Procedure Call (RPC) で新規サーバーに接続します。
8.2.6. マスター CA サーバー移行後のステップ
rhel7.example.comからレプリカファイルを作成します。注記
Red Hat Enterprise Linux 6 サーバーから Red Hat Enterprise Linux 7 レプリカをインストールした後は、Identity Management ドメインのドメインレベルは自動的に 0 に設定されます。Red Hat Enterprise Linux 7.3 では、レプリカを容易にインストール、管理する方法が導入されています。これらの機能を使用するには、トポロジーのドメインレベルが 1 である必要があります。詳細は 7章ドメインレベルの表示と引き上げ を参照してください。- レプリカファイルを使用して別の Red Hat Enterprise Linux 7 システムに新規レプリカをインストールします。
- Red Hat Enterprise Linux 7 サーバー上で削除コマンドを実行して、トポロジーからサーバーを削除します。
第9章 Identity Management のバックアップと復元
重要
- マシン上で壊滅的なハードウェア障害が発生し、マシンがそれ以上機能しなくなった場合。このような場合には、オペレーティングシステムを最初から再インストールして、同じ完全修飾ドメイン名 (FQDN) とホスト名でマシンを設定し、IdM パッケージと元のシステムにあった IdM に関連するその他すべてのオプションパッケージをインストールして、IdM サーバーの全バックアップを復元します。
- 分離されているマシンでのアップグレードが失敗した場合。オペレーティングシステムは機能しているものの、IdM データが破損しているため、IdM システムを正常起動時構成に戻す場合です。
重要
上記の 2 例のようにハードウェアの障害やアップグレードで失敗した際に、唯一の証明局 (CA) など、特別なロールが割り当てられたレプリカがなくなった場合や、すべてのレプリカがなくなった場合にのみバックアップから復元するようにしてください。同一データを持つ別のレプリカがまだある場合は、失われたレプリカを削除して、残りのレプリカから再構成することが推奨されます。 - エントリーが削除されてしまい、それらを戻す場合など、LDAP コンテナーに望ましくない変更がされた場合。バックアップされた LDAP データを復元すると、IdM システム自体には影響せずに LDAP エントリーを元の状態に戻すことができます。
9.1. 完全なサーバーバックアップおよびデータのみのバックアップ
- 完全な IdM サーバーバックアップ
- 完全なサーバーバックアップでは、スタンドアロンバックアップとなる LDAP データのほかに、すべての IdM サーバーファイルのバックアップコピーが作成されます。IdM は数百のファイルに影響を及ぼします。バックアッププロセスでコピーされるファイルはディレクトリー全体と設定ファイルやログファイルなどの特定ファイルを合わせたもので、IdM に直接関連するものと、IdM が依存する様々なサービスに関連します。完全なサーバーバックアップは生ファイルのバックアップなので、これはオフラインで実行されます。完全なサーバーバックアップを実行するスクリプトは、IdM サービスすべてを停止して、バックアッププロセスの安全な実行を確保します。完全なサーバーバックアップでコピーされるファイルとディレクトリーの全一覧は、「バックアップ中にコピーされるディレクトリーおよびファイル一覧」 を参照してください。
- データのみのバックアップ
- データのみのバックアップでは、LDAP データのバックアップコピーと changelog のみが作成されます。このプロセスでは
IPA-REALMインスタンスのバックアップが作成され、さらに複数または単一のバックエンドをバックアップすることができます。バックエンドには、IPAバックエンドとCA Dogtagバックエンドが含まれます。このタイプのバックエンドは、LDIF (LDAP データ交換形式) で保存されている LDAP コンテンツのレコードもバックアップします。データのみのバックアップは、オフラインでもオンラインでも実行できます。
/var/lib/ipa/backup/ ディレクトリーに保存します。バックアップを含んでいるサブディレクトリーの命名規則は以下のとおりです。
- 完全なサーバーバックアップの場合は、GMT のタイムゾーンで
ipa-full-YEAR-MM-DD-HH-MM-SSとなります。 - データのみのバックアップの場合は、GMT のタイムゾーンで
ipa-data-YEAR-MM-DD-HH-MM-SSとなります。
9.1.1. バックアップの作成
ipa-backup ユーティリティーを使用して作成されます。これは常に root で実行する必要があります。
ipa-backup を実行します。
重要
ipa-backup --data コマンドを実行します。
ipa-backup には以下のオプションを追加することができます。
--onlineは、オンラインでのバックアップを実行します。これはデータ専用のバックアップでのみ利用可能となります。--logsは、バックアップに IdM サービスログファイルを含めます。
ipa-backup の使用に関する詳細情報は、ipa-backup(1) man ページを参照してください。
9.1.2. バックアップの暗号化
- たとえば、
cat >keygen <<EOFを実行して、キーの詳細を含むkeygenファイルを作成します。そして、コマンドラインから必要となる暗号化詳細をファイルに提供します。[root@server ~]# cat >keygen <<EOF > %echo Generating a standard key > Key-Type: RSA > Key-Length:2048 > Name-Real: IPA Backup > Name-Comment: IPA Backup > Name-Email: root@example.com > Expire-Date: 0 > %pubring /root/backup.pub > %secring /root/backup.sec > %commit > %echo done > EOF [root@server ~]#
backupという名前のキーペアを新規生成し、コマンドkeygenのコンテンツを提供します。以下のコマンドでは、/root/backup.secおよび/root/backup.pubというパス名のキーペアが生成されます。[root@server ~]# gpg --batch --gen-key keygen [root@server ~]# gpg --no-default-keyring --secret-keyring /root/backup.sec \ --keyring /root/backup.pub --list-secret-keys
backup キーを ipa-backup に渡します。
--gpgは、ipa-backupに暗号化バックアップを実行するよう指示します。--gpg-keyring=GPG_KEYRINGは、ファイル拡張子なしで GPG keyring への完全パスを提供します。
[root@server ~]# ipa-backup --gpg --gpg-keyring=/root/backup
注記
gpg2 ユーティリティーを使って GPG キーを生成している場合、問題が発生する可能性があります。これは、gpg2 が機能するには外部のプログラムを必要とするためです。この状況でコンソールのみからキーを生成するには、キーの生成前に pinentry-program /usr/bin/pinentry-curses の行を .gnupg/gpg-agent.conf ファイルに追加します。
9.1.3. バックアップ中にコピーされるディレクトリーおよびファイル一覧
/usr/share/ipa/html /root/.pki /etc/pki-ca /etc/pki/pki-tomcat /etc/sysconfig/pki /etc/httpd/alias /var/lib/pki /var/lib/pki-ca /var/lib/ipa/sysrestore /var/lib/ipa-client/sysrestore /var/lib/ipa/dnssec /var/lib/sss/pubconf/krb5.include.d/ /var/lib/authconfig/last /var/lib/certmonger /var/lib/ipa /var/run/dirsrv /var/lock/dirsrv
/etc/named.conf /etc/named.keytab /etc/resolv.conf /etc/sysconfig/pki-ca /etc/sysconfig/pki-tomcat /etc/sysconfig/dirsrv /etc/sysconfig/ntpd /etc/sysconfig/krb5kdc /etc/sysconfig/pki/ca/pki-ca /etc/sysconfig/ipa-dnskeysyncd /etc/sysconfig/ipa-ods-exporter /etc/sysconfig/named /etc/sysconfig/ods /etc/sysconfig/authconfig /etc/ipa/nssdb/pwdfile.txt /etc/pki/ca-trust/source/ipa.p11-kit /etc/pki/ca-trust/source/anchors/ipa-ca.crt /etc/nsswitch.conf /etc/krb5.keytab /etc/sssd/sssd.conf /etc/openldap/ldap.conf /etc/security/limits.conf /etc/httpd/conf/password.conf /etc/httpd/conf/ipa.keytab /etc/httpd/conf.d/ipa-pki-proxy.conf /etc/httpd/conf.d/ipa-rewrite.conf /etc/httpd/conf.d/nss.conf /etc/httpd/conf.d/ipa.conf /etc/ssh/sshd_config /etc/ssh/ssh_config /etc/krb5.conf /etc/ipa/ca.crt /etc/ipa/default.conf /etc/dirsrv/ds.keytab /etc/ntp.conf /etc/samba/smb.conf /etc/samba/samba.keytab /root/ca-agent.p12 /root/cacert.p12 /var/kerberos/krb5kdc/kdc.conf /etc/systemd/system/multi-user.target.wants/ipa.service /etc/systemd/system/multi-user.target.wants/sssd.service /etc/systemd/system/multi-user.target.wants/certmonger.service /etc/systemd/system/pki-tomcatd.target.wants/pki-tomcatd@pki-tomcat.service /var/run/ipa/services.list /etc/opendnssec/conf.xml /etc/opendnssec/kasp.xml /etc/ipa/dnssec/softhsm2.conf /etc/ipa/dnssec/softhsm_pin_so /etc/ipa/dnssec/ipa-ods-exporter.keytab /etc/ipa/dnssec/ipa-dnskeysyncd.keytab /etc/idm/nssdb/cert8.db /etc/idm/nssdb/key3.db /etc/idm/nssdb/secmod.db /etc/ipa/nssdb/cert8.db /etc/ipa/nssdb/key3.db /etc/ipa/nssdb/secmod.db
/var/log/pki-ca /var/log/pki/ /var/log/dirsrv/slapd-PKI-IPA /var/log/httpd /var/log/ipaserver-install.log /var/log/kadmind.log /var/log/pki-ca-install.log /var/log/messages /var/log/ipaclient-install.log /var/log/secure /var/log/ipaserver-uninstall.log /var/log/pki-ca-uninstall.log /var/log/ipaclient-uninstall.log /var/named/data/named.run
9.2. バックアップの復元
ipa-backup を使って作成されたバックアップのディレクトリーがあれば、IdM サーバーまたは LDAP コンテンツをバックアップ実行時の状態に復元することができます。バックアップが作成された元のホストとは異なるホスト上では、バックアップの復元はできません。
注記
9.2.1. 完全なサーバーバックアップまたはデータのみのバックアップからの復元
重要
ipa-restore ユーティリティーを使って復元されます。これは常に root で実行する必要があります。バックアップをコマンドに渡します。
- バックアップがデフォルトの
/var/lib/ipa/backup/ディレクトリーにある場合は、ディレクトリー名のみを渡します。 - バックアップを含んでいるディレクトリーがデフォルト以外の場所にある場合は、完全パスを渡します。例を示します。
[root@server ~]# ipa-restore /path/to/backup
ipa-restore ユーティリティーはディレクトリーに含まれているバックアップのタイプを自動的に検出し、デフォルトで同一タイプの復元を実行します。
ipa-restore には以下のオプションを追加できます。
--dataは、完全なサーバーバックアップからデータのみの復元を実行します。つまり、完全なサーバーバックアップを含むディレクトリーから LDAP データのコンポーネントのみを復元します。--onlineは、データのみの復元で LDAP データをオンラインで復元します。--instanceは、どの 389 DS インスタンスを復元するか指定します。Red Hat Enterprise Linux 7 の IdM はIPA-REALMインスタンスしか使用しませんが、たとえば、別のインスタンスを持つシステム上でバックアップを作成することは可能です。この場合、--instanceを使うと、IPA-REALMの復元のみが許可されます。例を示します。[root@server ~]# ipa-restore --instance=IPA-REALM /path/to/backup
このオプションは、データのみの復元実行時にのみ使用できます。--backendは復元するバックエンドを指定します。このオプションがない場合は、ipa-restoreは発見したすべてのバックエンドを復元します。可能性のあるバックエンドを定義する引数はuserRootでこれは IPA データバックエンドを復元し、ipacaの場合は CA バックエンドを復元します。このオプションは、データのみの復元実行時にのみ使用できます。--no-logsは、ログファイルなしでバックアップを復元します。
- SSSD サービスを停止します。
[root@server ~]# systemctl stop sssd
- SSSD からキャッシュされたコンテンツをすべて削除します。
[root@server ~]# find /var/lib/sss/ ! -type d | xargs rm -f
- SSSD サービスを起動します。
[root@server ~]# systemctl start sssd
注記
ipa-restore 使用に関する詳細情報は、ipa-restore(1) man ページを参照してください。
9.2.2. 複数マスターサーバーでの復元
ipa-replica-manage コマンドを実行し、CA がインストールされているマスター上で ipa-csreplica-manage コマンドを実行します。
[root@server ~]# ipa-replica-manage re-initialize --from=restored_master_FQDN
9.2.3. 暗号化バックアップからの復元
--gpg-keyring オプションを使って秘密鍵および公開鍵への完全パスを提供します。例を示します。
[root@server ~]# ipa-restore --gpg-keyring=/root/backup /path/to/backup
第10章 IdM ユーザーのアクセス制御の定義
10.1. IdM エントリーのアクセス制御
- Actor
- これは、動作のパーミッションを付与されているエンティティーです。これはユーザーが誰かを定義し、1 日のある時間帯や特定のマシンに試行を制限するなど、オプションでバインドの試行に対して他の制限を必須とすることが可能なため、LDAP アクセス制御モデルではバインドルールと呼ばれます。
- Target
- これは、Actor が許可されている操作を実行する対象のエントリーを定義します。
- Operation type
- 最後の部分では、ユーザーが実行を許可されるアクションの種類を決定します。最も一般的な操作は、追加、削除、書き込み、読み取り、および検索です。Identity Management では、すべてのユーザーが暗示的に IdM ドメイン内のすべてのエントリーに対する読み取りおよび検索権限を付与されています。制限されるのは、パスワードや Kerberos キーなどの重要な属性のみです。匿名ユーザーは、
sudoルールやホストベースのアクセス制御など、セキュリティー関連の設定は読み取ることができません。
10.1.1. Identity Management におけるアクセス制御方法
- セルフサービスルール
- これは、ユーザーが自分のパーソナルエントリーで実行可能な操作を定義します。アクセス制御タイプは、エントリー内での属性への書き込みパーミッションのみを許可します。エントリー自体の追加もしくは削除操作は許可されません。
- 委任ルール
- 委任ルールでは、特定のユーザーグループが別のユーザーグループ内のユーザーの特定属性に関して書き込み (編集) 操作を許可されます。セルフサービスルールのように、この形式のアクセス制御は特定の属性値の編集に制限されており、エントリー全体を追加したり削除する権限や特定されていない属性に対する制御を付与するものではありません。
- ロールベースのアクセス制御
- ロールベースのアクセス制御では特別のアクセス制御グループが作成され、このグループに IdM ドメイン内での全タイプのエントリーに対するより幅広い権限が付与されます。ロールには編集、追加、および削除の権限が付与されるので、選択された属性だけでなくエントリー全体に対する完全な制御が付与されます。ロールのなかには既に作成され、Identity Management 内で使用可能なものもあります。ホストや automount 設定、netgroup、DNS 設定、および IdM 設定など、すべてのタイプのエントリーを特別な方法で管理するために、特別なロールを作成することもできます。
10.2. セルフサービス設定の定義
- パーソナルエントリー内の一般的な属性を編集するルール。これには、姓、名、電話番号、および住所などが含まれます。
- パーソナルパスワードを編集するルール。これには 2 つの Samba パスワード、Kerberos パスワード、および一般的なユーザーパスワードが含まれます。
- パーソナル SSH キーを管理するルール。
10.2.1. Web UI でのセルフサービスルールの作成
- トップメニューで IPA Server タブを開き、Self Service Permissions サブタブを選択します。
- セルフサービス ACI リストのトップにある Add をクリックします。

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

図10.2 セルフサービス追加のフォーム
- この ACI でユーザーによる編集を許可する属性のチェックボックスを選択します。
- Add をクリックして新規セルフサービス ACI を保存します。
10.2.2. コマンドライン でのセルフサービスルールの作成
selfservice-add コマンドで追加できます。以下の 2 つのオプションが必須になります。
--permissionsは、ACI が付与する書き込み、追加、または削除などのパーミッションを設定します。--attrsでは、この ACI がパーミッションを付与する属性の完全一覧を提供します。
[jsmith@server ~]$ ipa selfservice-add "Users can manage their own name details" --permissions=write --attrs=givenname --attrs=displayname --attrs=title --attrs=initials
-----------------------------------------------------------
Added selfservice "Users can manage their own name details"
-----------------------------------------------------------
Self-service name: Users can manage their own name details
Permissions: write
Attributes: givenname, displayname, title, initials10.2.3. セルフサービスルールの編集

図10.3 セルフサービス編集ページ
ipa selfservice-mod コマンドでセルフサービスルールを編集します。--attrs オプションはそれまでにサポートされていた属性をすべて上書きするので、新規属性の他に属性の完全一覧を常に含めるようにしてください。
[jsmith@server ~]$ ipa selfservice-mod "Users can manage their own name details" --attrs=givenname --attrs=displayname --attrs=title --attrs=initials --attrs=surname -------------------------------------------------------------- Modified selfservice "Users can manage their own name details" -------------------------------------------------------------- Self-service name: Users can manage their own name details Permissions: write Attributes: givenname, displayname, title, initials
重要
10.3. ユーザーへのパーミッションの委任
10.3.1. Web UI でのユーザーグループへのアクセス委任
- トップメニューで IPA Server タブを開き、Delegations サブタブを選択します。
- 委任 ACI 一覧の上部にある Add をクリックします。

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

図10.5 委任追加のフォーム
- Member user group ドロップダウンメニューで、委任グループのメンバーが編集する対象エントリーの グループを選択します。
- 属性ボックスでは、メンバーのユーザーグループがパーミッションを付与される属性を選択します。
- Add をクリックして新規委任 ACI を保存します。
10.3.2. コマンドラインでのユーザーグループへのアクセス委任
delegation-add コマンドで追加できます。以下の 3 つのオプションが必須になります。
--groupは、ユーザーグループのユーザーエントリーに パーミッションを付与される グループです。--membergroupは、委任グループのメンバーが編集する対象エントリーの グループです。--attrsは、メンバーグループのユーザーが編集を許可される属性です。
$ ipa delegation-add "basic manager attrs" --attrs=manager --attrs=title --attrs=employeetype --attrs=employeenumber --group=engineering_managers --membergroup=engineering -------------------------------------- Added delegation "basic manager attrs" -------------------------------------- Delegation name: basic manager attrs Permissions: write Attributes: manager, title, employeetype, employeenumber Member user group: engineering User group: engineering_managers
delegation-mod コマンドで編集します。--attrs オプションはそれまでにサポートされていた属性をすべて上書きするので、新規属性に加えて属性の完全一覧を常に含めるようにしてください。
[jsmith@server ~]$ ipa delegation-mod "basic manager attrs" --attrs=manager --attrs=title --attrs=employeetype --attrs=employeenumber --attrs=displayname ----------------------------------------- Modified delegation "basic manager attrs" ----------------------------------------- Delegation name: basic manager attrs Permissions: write Attributes: manager, title, employeetype, employeenumber, displayname Member user group: engineering User group: engineering_managers
重要
10.4. ロールベースのアクセス制御の定義
- パーミッション。これは、(読み取り、書き込み、追加、または削除などの) 特定の操作と、これらの操作が適用される IdM LDAP ディレクトリー内のターゲットエントリーを定義します。パーミッションはビルディングブロックで、必要に応じて複数の権限に割り当てることができます。IdM パーミッションを使用すると、どのユーザーがどのオブジェクトにアクセスできるかや、それらのオブジェクトのどの属性にアクセスできるかという制御すら可能になります。IdM を使うと、個別の属性をブラックリスト化したりホワイトリスト化したりすることができるほか、全匿名ユーザー、全認証ユーザー、または権限のあるユーザーの特定グループのみに対するユーザー、グループ、または sudo といった特定の IdM 機能の視認性全体を変更することもできます。パーミッションに対するアプローチがこのように柔軟なことで、たとえば、管理者がユーザーやグループのアクセスをこれらのユーザーやグループが必要とする特定のセクションのみに限定し、他のセクションを完全に見えないようにする場合などに便利になります。
- ロールで利用可能な 権限。権限は、パーミッショングループに必須のものです。パーミッションは、ロールには直接適用されません。パーミッションは権限に追加され、そうすることで権限で完全かつ一貫性のあるアクセス制御ルールが作成されます。たとえば、automount の場所を追加、編集、削除するパーミッションを作成します。そしてそのパーミッションを FTP サービスを管理する別のパーミッションと組み合わせることで、ファイルシステム管理に関連する単一の権限を作成することができます。
- ロール。これは、権限で定義されたアクションの実行が可能な IdM ユーザーのリストになります。
10.4.1. ロール
10.4.1.1. Web UI でのロールの作成
- トップメニューで IPA Server タブを開き、Role Based Access Control サブタブを選択します。
- Role Based ACI 一覧の上部にある Add をクリックします。

図10.6 新規ロールの追加
- ロール名と説明を入力します。

図10.7 ロール追加のフォーム
- をクリックして新規ロールを保存し、設定ページに移動します。
- Users タブの上部で、グループ追加の場合は Users Groups タブで、Add をクリックします。

図10.8 ユーザーの追加
- 左側のユーザーを選択し、右矢印 を使って Prospective コラムに移動させます。

図10.9 ユーザーの選択
- Privileges タブの上部で をクリックします。

図10.10 権限の追加
- 左側の権限を選択し、右矢印 を使って Prospective コラムに移動させます。

図10.11 権限の選択
- をクリックして保存します。
10.4.1.2. コマンドライン でのロールの作成
- 新規ロールを追加します。
[root@server ~]# kinit admin [root@server ~]# ipa role-add --desc="User Administrator" useradmin ------------------------ Added role "useradmin" ------------------------ Role name: useradmin Description: User Administrator
- 必要な権限をロールに追加します。
[root@server ~]# ipa role-add-privilege --privileges="User Administrators" useradmin Role name: useradmin Description: User Administrator Privileges: user administrators ---------------------------- Number of privileges added 1 ----------------------------
- 必要なグループを追加します。このケースでは、既存の単一グループ
useradminを追加しています。[root@server ~]# ipa role-add-member --groups=useradmins useradmin Role name: useradmin Description: User Administrator Member groups: useradmins Privileges: user administrators ------------------------- Number of members added 1 -------------------------
10.4.2. パーミッション
10.4.2.1. Web UI での新規パーミッションの作成
- トップメニューで IPA Server タブを開き、Role Based Access Control サブタブを選択します。
- Permissions タスクリンクを選択します。

図10.12 パーミッションタスク
- パーミッション一覧の上部にある Add をクリックします。

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

図10.14 パーミッション追加のフォーム
- フォームの下にある Add をクリックしてパーミッションを保存します。
- 新規パーミッションの名前を入力します。
- 適切な Bind rule type を選択します。
- permission がデフォルトのパーミッションタイプになります。これでアクセスが権限とロールによって付与されます。
- all を選択すると、パーミッションがすべての認証ユーザーに適用されます。
- anonymous を選択すると、非認証ユーザーを含むすべてのユーザーにパーミッションが適用されます。
注記
デフォルト以外の bind rule type のパーミッションを権限に追加することはできません。また、権限に既にあるパーミッションをデフォルト以外の bind rule type に設定することもできません。 - パーミッションが付与する権限を Granted rights で選択します。
- パーミッションのターゲットエントリーを識別する方法を定義します。
- Type では、ユーザー、ホスト、またはサービスなどのエントリータイプを指定します。Type で値を設定すると、そのエントリータイプの ACI でアクセス可能な全属性が Effective Attributes に表示されます。Type を定義すると、Subtree と Target DN が定義済みのいずれかの値に設定されます。
- Subtree は、サブツリーエントリーを指定します。このサブツリーエントリー以下のすべてのエントリーがターゲットになります。Subtree はワイルドカードや存在しないドメイン名 (DN) を受け付けないので、既存のサブツリーエントリーを提供してください。例を示します。
cn=automount,dc=example,dc=com
- Extra target filter では、LDAP フィルターを使ってパーミッションが適用されるエントリーを特定します。このフィルターは有効な LDAP フィルターであればどれでも構いません。例を示します。
(!(objectclass=posixgroup))
IdM は、提供されたフィルターの有効性を自動的にチェックします。無効なフィルターが入力された場合は、パーミッションを保存使用とすると IdM が警告します。
- Target DN はドメイン名 (DN) を指定し、ワイルドカードを受け付けます。例を示します。
uid=*,cn=users,cn=accounts,dc=com
- Member of group は、特定のグループのメンバーにターゲットフィルターを設定します。
フィルター設定を記入して Add をクリックすると、IdM がフィルターの有効性を確認します。すべてのパーミッション設定が適切であれば、IdM は検索を実行します。設定が適切でない場合、IdM は該当設定についてのメッセージを表示します。 - Type を設定する場合は、Effective attributes で利用可能な ACI 属性一覧から選択します。Type を使用しない場合は、Effective attributes フィールドに手動で属性を追加します。属性は 1 つずつ追加します。複数の属性を追加するには、Add をクリックして別の入力フィールドを追加します。
重要
パーミッションの属性を設定しない場合は、デフォルトで全属性が含まれることになります。
10.4.2.2. コマンドライン での新規パーミッションの作成
ipa permission-add コマンドを発行します。対応するオプションを提供して、パーミッションのプロパティーを指定します。
- プロパティー名を提供します。例を示します。
[root@server ~]# ipa permission-add "dns admin permission"
--bindtypeでは、bind rule type を指定します。このオプションはall、anonymous、およびpermissionの引数を受け付けます。例を示します。--bindtype=all
--bindtypeを使用しない場合は、タイプは自動的にデフォルトのpermissionの値に設定されます。注記
デフォルト以外の bind rule type のパーミッションを権限に追加することはできません。また、権限に既にあるパーミッションをデフォルト以外の bind rule type に設定することもできません。--permissionsには、パーミッションで付与される権限を記載します。複数の属性を設定するには、--permissionsオプションを複数回使用するか、オプションを中括弧内にコンマ区切りの一覧で記載します。例を示します。--permissions=read --permissions=write --permissions={read,write}--attrsには、パーミッションが付与される属性を記載します。複数の属性を設定するには、--attrsオプションを複数回使用するか、オプションを中括弧内にコンマ区切りの一覧で記載します。例を示します。--attrs=description --attrs=automountKey --attrs={description,automountKey}--attrsに提供する属性は既存のもので、該当のオブジェクトタイプに許可されている必要があります。そうでない場合は、コマンドはスキーマ構文エラーで失敗します。--typeでは、ユーザー、ホスト、またはサービスなどのエントリータイプを定義します。各タイプには、許可するされる属性セットがあります。例を示します。[root@server ~]# ipa permission-add "manage service" --permissions=all --type=service --attrs=krbprincipalkey --attrs=krbprincipalname --attrs=managedby
--subtreeでは、サブツリーエントリーを提供します。これでフィルターがこのサブツリーエントリー以下にあるすべてのエントリーをターゲットとします。--subtreeはワイルドカードや存在しないドメイン名 (DN) を受け付けません。ディレクトリー内の DN を使用してください。IdM は簡素化された平坦なディレクトリーツリー構造を使用しているので、--subtreeを使って、automount の場所のような、他の設定のコンテナーや親エントリーである、一定タイプのエントリーをターゲットにすることができます。例を示します。[root@server ~]# ipa permission-add "manage automount locations" --subtree="ldap://ldap.example.com:389/cn=automount,dc=example,dc=com" --permissions=write --attrs=automountmapname --attrs=automountkey --attrs=automountInformation
--typeと--subtreeのオプションは、相互排他的になります。--filterは、パーミッションが適用されるエントリーを特定する LDAP フィルターを使用します。IdM は提供されたフィルターの有効性を自動的にチェックします。このフィルターは有効な LDAP フィルターにします。例を示します。[root@server ~]# ipa permission-add "manage Windows groups" --filter="(!(objectclass=posixgroup))" --permissions=write --attrs=description
--memberofでは、特定のグループが存在することを確認した後、そのグループのメンバーにターゲットフィルターを設定します。例を示します。[root@server ~]# ipa permission-add ManageHost --permissions="write" --subtree=cn=computers,cn=accounts,dc=testrelm,dc=com --attr=nshostlocation --memberof=admins
--targetgroupでは、特定のユーザーグループが存在することを確認した後、そのグループにターゲットを設定します。
注記
ipa permission-mod --help と ipa permission-del --help のコマンドを実行してください。
10.4.2.3. デフォルトの管理パーミッション
- 名前、場所、およびターゲット属性が修正できません。
- 削除することができません。
- 以下の 3 つの属性セットがあります。
- default 属性は IdM が管理し、ユーザーは修正することができません。
- included 属性は、ユーザーが追加する属性です。included 属性を管理パーミッションに追加するには、
ipa permission-modコマンドで--includedattrsオプションを使用して属性を指定します。 - excluded 属性は、ユーザーが削除する属性です。excluded 属性を管理パーミッションに追加するには、
ipa permission-modコマンドで--excludedattrsオプションを使用して属性を指定します。
--attrs オプションを使用すると、included および excluded 属性セットは自動的に調整され、--attrs で提供された属性のみが有効になります。
注記
permission に設定し、該当管理パーミッションを全権限から削除すると、実質的に無効となります。
System: で始まります。たとえば、System: Add Sudo rule や System: Modify Services などです。
- Add Automember Rebuild Membership Task
- Add Replication Agreements
- Certificate Remove Hold
- Get Certificates status from the CA
- Modify DNA Range
- Modify Replication Agreements
- Remove Replication Agreements
- Request Certificate
- Request Certificates from a different host
- Retrieve Certificates from the CA
- Revoke Certificate
- Write IPA Configuration

図10.15 灰色表示となった属性
System: Modify Users パーミッションをグループに適用しようとすると失敗します。
$ ipa permission-mod 'System: Modify Users' --type=group ipa: ERROR: invalid 'ipapermlocation': not modifiable on managed permissions
System: Modify Users パーミッションを GECOS 属性に適用しないようにすることは可能です。
$ ipa permission-mod 'System: Modify Users' --excludedattrs=gecos ------------------------------------------ Modified permission "System: Modify Users"
10.4.2.4. Identity Management の以前のバージョンのパーミッション
- 書き込み、追加、および削除パーミッションタイプのみが利用可能でした。
- パーミッション設定のオプションは詳細設定ができませんでした。たとえば、同一のパーミッションにフィルターとサブツリーの両方を追加することはできませんでした。
- グローバルの IdM ACI は、ログインしていない匿名ユーザーを含めた、サーバーの全ユーザーに読み取りアクセスを付与していました。
注記
ipa permission-show と ipa permission-find のコマンドは、新スタイルと以前のスタイルの両方のパーミッションを認識します。これらコマンドの出力は新スタイルになりますが、パーミッション自体を変更するものではありません。パーミッションエントリーはデータを出力する前にメモリーでのみアップグレードされ、変更は LDAP にコミットされません。
10.4.3. 権限
10.4.3.1. Web UI での新規権限の作成
- トップメニューで IPA Server タブを開き、Role Based Access Control サブタブを選択します。
- Privileges タスクリンクを選択します。

図10.16 権限タスク
- 権限一覧の上部にある Add をクリックします。

図10.17 新規権限の追加
- 権限の名前と説明を入力します。

図10.18 権限追加のフォーム
- をクリックして、権限設定ページに移動し、パーミッションを追加します。
- Permissions タブを選択します。
- 権限に追加するパーミッション一覧のトップにある Add をクリックします。

図10.19 パーミッションの追加
- 追加するパーミッションの名前の横にあるチェックボックスを選択し、右矢印 を使って Prospective コラムに移動させます。

図10.20 パーミッションの選択
- をクリックして保存します。
10.4.3.2. コマンドライン での新規権限の作成
privilege-add コマンドで作成されます。次に、privilege-add-permission コマンドを使ってパーミッションを権限グループに追加します。
- 権限エントリーを作成します。
[jsmith@server ~]$ ipa privilege-add "managing filesystems" --desc="for filesystems"
- 希望するパーミッションを割り当てます。
[jsmith@server ~]$ ipa privilege-add-permission "managing filesystems" --permissions="managing automount" --permissions="managing ftp services"
パート IV. アイデンティティーの管理
第11章 ユーザーアカウントの管理
11.1. ユーザーホームディレクトリーの設定
/home/ ディレクトリーが想定されます。たとえば、IdM では、user_login ログインのユーザーは、/home/user_login にホームディレクトリーを設定する必要があります。
注記
ipa config-mod コマンドを使用してください。
automount ユーティリティーを使用して手動でホームディレクトリーを追加することもできます。
11.1.1. PAM ホームディレクトリーモジュールを使用して自動的にホームディレクトリをマウントする手順
サポートされる PAM ホームディレクトリーモジュール
pam_oddjob_mkhomedirpam_mkhomedir
pam_oddjob_mkhomedir の使用を試行します。このモジュールがインストールされていない場合は、IdM は代わりに pam_mkhomedir の使用を試みます。
PAM ホームディレクトリーモジュールの設定
--mkhomedir オプションを指定して ipa-server-install または ipa-client-install ユーティリティーを実行します。
authconfig ユーティリティを使用します。以下に例を示します。
# authconfig --enablemkhomedir --update
authconfig を使用したホームディレクトリーの作成に関する情報は、「authconfig を使用したカスタムホームディレクトリーの有効化」を参照してください。
11.1.2. ホームディレクトリーを手動でマウントする手順
/home/ ディレクトリーを提供し、automount ユーティリティーで IdM マシンにディレクトリーをマウントするには、NFS ファイルサーバーを使用します。
NFS 使用時に発生する可能性のある問題
/home/ ディレクトリーツリー全体を読み込む際にパフォーマンスの問題が発生したり、ホームディレクトリーにリモートサーバーを使用する際にネットワークパフォーマンスの問題が発生したりする可能性があります。
automountを使用して、ユーザーがログインした時のみ、ユーザーのホームディレクトリーのみをマウントします。これを使用して、/home/ツリー全体を読み込ませないようにしてください。- 限定的なパーミッションを割り当てたリモートユーザーを使用してホームディレクトリーを作成し、このユーザーとして IdM サーバーに共有をマウントします。IdM サーバーは
httpdプロセスとして実行されるので、sudoまたは同様のプログラムを使用して IdM サーバーへの限定的なパーミッションを許可して、NFS サーバーにホームディレクトリーを作成することができます。
NFS および automount を使用したホームディレクトリーの設定
automount を使用して別の場所から IdM サーバーにホームディレクトリーを手動で追加するには以下を実行します。
- ユーザーディレクトリーマップ用に新しい場所を作成します。
$ ipa automountlocation-add userdirs Location: userdirs
- 新たに作成した場所の
auto.directファイルにダイレクトマップを追加します。auto.directファイルは、ipa-server-installユーティリティーで自動的に作成されたautomountマップです。以下の例では、マウントポイントは/shareです。$ ipa automountkey-add userdirs auto.direct --key=/share --info="-ro,soft, server.example.com:/home/share" Key: /share Mount information: -ro,soft, server.example.com:/home/share
automount の使用に関する詳細は 33章Automount の使用 を参照してください。
11.2. ユーザーのライフサイクル
Stageユーザーは認証ができません。これは最初の状態です。アクティブなユーザーが必要とする、ユーザーアカウントのプロパティーの一部は、まだ設定されていません。Activeユーザーは認証が可能です。この状態では、必要とされるユーザーアカウントのプロパティーはすべて設定されています。Preservedユーザーは、過去にactiveであったユーザーです。このユーザーは非アクティブとみなされ、IdM への認証はできません。Preserved ユーザーは、Active ユーザーに設定されたていたアカウントプロパティーの大半が保持されますが、どのユーザーグループにも所属しません。注記
preserved状態のユーザー一覧は、以前のユーザーアカウントの履歴を提供することができます。
重要
admin ユーザーなど、別の管理者でしか作成できません。すべての管理者ユーザーを誤って削除してしまった場合は、Directory Manager が手動で新規の管理者を Directory Server に作成する必要があります。
ユーザーのライフサイクル管理に関する操作
active または stage のいずれかの状態で追加できますが、preserved ではできません。
- stage → active
stageの状態のアカウントが正しくアクティベートされる準備ができると、管理者はactiveの状態に移動します。- active → preserved
- ユーザーが企業を退社した後には、管理者はアカウントを
preservedの状態に移動します。 - preserved → active
- 以前働いていたユーザーが再度企業に復帰した場合に、管理者は、ユーザーアカウントを
preservedからactiveの状態に移動して復帰させます。 - preserved → stage
- 以前のユーザーが企業に復帰する予定の場合に、管理者はアカウントの状態を
preservedからstageに移動して、後ほど再アクティベートできるようにアカウントの準備をします。
preserved の状態に移動できず、完全に削除することしかできない点に注意してください。

図11.1 ユーザーライフサイクルの操作
11.2.1. stage または Active ユーザーの追加
Web UI でのユーザーの追加
- → タブを選択します。
- ユーザーを
activeまたはstageのいずれの状態で追加するかによって、Active users または Stage users カテゴリーを選択します。
図11.2 ユーザーカテゴリーの選択
- ユーザー一覧上部にある Add をクリックします。

図11.3 ユーザーの追加
- Add User のフォームに入力します。ユーザーログインを手動で設定しない場合には IdM は指定の名前に基づいて自動的にログイン ID が生成されます。
- をクリックします。または、 をクリックして、別のユーザーを追加するか、 をクリックして新規ユーザーエントリーの編集を開始します。ユーザーエントリーの編集に関する情報は「ユーザーの編集」を参照してください。
コマンドラインからのユーザーの追加
active の状態の新規ユーザーを追加するには、ipa user-add コマンドを使用します。stage の状態の新規ユーザーを追加するには、ipa stageuser-add コマンドを使用します。
注記
ipa user-add および ipa stageuser-add をオプションなしで実行すると、最小限必要なユーザー属性の入力が求められ、他の属性についてはデフォルト値が使用されます。または、オプションを追加してコマンドに直接さまざまな属性を指定することができます。
$ ipa user-add First name: first_name Last name: last_name User login [default_login]: custom_login
ipa user-add および ipa stageuser-add にオプションを追加すると、多くのユーザー属性にカスタムの値を定義できるようになります。これを使用すると、対話型セッションよりもより多くの情報を指定することができます。たとえば、stage ユーザーを追加するには以下を実行します。
$ ipa stageuser-add stage_user_login --first=first_name --last=last_name --email=email_address
ipa user-add および ipa stageuser-add で利用可能なオプションの完全な一覧については、コマンドに --help オプションを指定して実行します。
11.2.1.1. ユーザー名の要件
[a-zA-Z0-9_.][a-zA-Z0-9_.-]{0,252}[a-zA-Z0-9_.$-]?注記
user と User のように、ユーザー名の違いが大文字と小文字のみのユーザーは追加できません。
ipa config-mod --maxusername コマンドを使用します。たとえば、ユーザー名の最大長を 64 文字に変更するには、以下を実行します。
$ ipa config-mod --maxusername=64 Maximum username length: 64 ...
11.2.1.2. カスタムの UID または GID 番号の定義
11.2.2. ユーザーの一覧表示およびユーザーの検索
Web UI でのユーザーの表示
- → タブを選択します。
- Active users、Stage users または Preserved users カテゴリーを選択します。

図11.4 ユーザーの一覧表示
Web UI でのユーザー情報の表示

図11.5 ユーザー情報の表示
コマンドラインからのユーザーの表示
ipa user-find コマンドを実行します。stage ユーザーをすべてを表示するには、ipa stageuser-find コマンドを使用します。preserved ユーザーを表示するには、ipa user-find --preserved=true コマンドを実行します。
$ ipa user-find --------------- 23 users matched --------------- User login: admin Last name: Administrator Home directory: /home/admin Login shell: /bin/bash UID: 1453200000 GID: 1453200000 Account disabled: False Password: True Kerberos keys available: True User login: user ...
ipa user-find および ipa stageuser-find にオプションおよび引数を追加して、検索条件を定義して検索結果を絞り込むことができます。たとえば、特定のタイトルが定義された active ユーザーをすべてを表示するには、以下を実行します。
$ ipa user-find --title=user_title --------------- 2 users matched --------------- User login: user ... Job Title: Title ... User login: user2 ... Job Title: Title ...
user が含まれる staget ユーザーすべてを表示するには、以下を実行します。
$ ipa user-find user --------------- 3 users matched --------------- User login: user ... User login: user2 ... User login: user3 ...
ipa user-find および ipa stageuser-find で利用可能なオプションの完全な一覧については、コマンドに --help オプションを指定して実行します。
コマンドラインからのユーザー情報の表示
ipa user-show コマンドを使用します。
$ ipa user-show user_login User login: user_login First name: first_name Last name: last_name ...
ipa stageuser-show コマンドを使用します。
11.2.3. ユーザーの有効化、保存、削除、復元
Web UI でのユーザーライフサイクルの管理
- Stage users 一覧で、アクティベートユーザーを選択して をクリックします。

図11.6 ユーザーの有効化
- Active users または Stage users リストで対象のユーザーを選択して をクリックします。

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

図11.8 Web UI での削除モードの選択
ボタンをクリックして確定します。
- Preserved users 一覧で、復元するユーザーを選択し、 をクリックします。

図11.9 ユーザーの復元
注記
preserved から stage の状態に移動できません。
コマンドラインからのユーザーライフサイクルの管理
stage から active に移動してユーザーアカウントをアクティベートするには、ipa stageuser-activate コマンドを使用します。
$ ipa stageuser-activate user_login ------------------------- Stage user user_login activated ------------------------- ...
ipa user-del または ipa stageuser-del コマンドを使用します。
- IdM データベースから active ユーザーを完全に削除するには、オプションの指定なしに
ipa user-delを実行します。$ ipa user-del user_login -------------------- Deleted user "user3" --------------------
- active ユーザーを保存するには、
--preserveオプションを指定してipa user-delを実行します。$ ipa user-del --preserve user_login -------------------- Deleted user "user_login" --------------------
- IdM データベースから stage ユーザーを完全に削除するには
ipa stageuser-delを実行します。$ ipa stageuser-del user_login -------------------------- Deleted stage user "user_login" --------------------------
注記
--continue オプションを使用するとエラーが発生しても強制的にコマンドを続行できます。コマンドの完了時に、操作結果のサマリーが stdout の標準出力ストリームに表示されます。
$ ipa user-del --continue user1 user2 user3
--continue が指定されていない場合には、コマンドはエラーが発生するまでユーザーの削除を続け、エラーが発生すると操作を停止して終了します。
preserved から active に移動して preserved ユーザーアカウントを復元するには、ipa user-undel コマンドを使用します。
$ ipa user-undel user_login ------------------------------ Undeleted user account "user_login" ------------------------------
preserved から stage に移動して preserved ユーザーアカウントを復元するには、ipa user-stage コマンドを使用します。
$ ipa user-stage user_login ------------------------------ Staged user account "user_login" ------------------------------
注記
--help オプションを追加して実行してください。
11.3. ユーザーの編集
Web UI でのユーザーの編集
- → タブを選択します。
- Active users、Stage users または Preserved users カテゴリーを検索して編集するユーザーを特定します。
- 編集するユーザー名をクリックします。

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

図11.11 変更したユーザー属性の保存
コマンドラインからのユーザーの編集
active または preserved の状態のユーザーを変更するには、ipa user-mod コマンドを使用します。stage の状態のユーザーを変更するには、ipa stageuser-mod コマンドを使用します。
ipa user-mod および ipa stageuser-mod コマンドでは、以下のオプションを利用できます。
- 変更するユーザーアカウントを特定するユーザーログイン
- 新規属性の値を指定するオプション
ipa user-mod および ipa stageuser-mod で利用可能なオプション一覧を参照してください。オプション一覧を表示するには、コマンドに --help オプションを追加して実行してください。
ipa user-mod または ipa stageuser-mod に属性オプションを追加するだけで、現在の属性値を上書きします。たとえば、以下を実行するとユーザーのタイトルが変更されるか、ユーザーのタイトルが指定されていない場合には新規タイトルが追加されます。
$ ipa user-mod user_login --title=new_title
--addattr オプションを使用します。たとえば、すでにメールが指定されているユーザーアカウントに新規のメールアドレスを追加するには以下を実行します。
$ ipa user-mod user --addattr=mobile=new_mobile_number
--------------------
Modified user "user"
--------------------
User login: user
...
Mobile Telephone Number: mobile_number, new_mobile_number
...--addattr オプションを 2 度使用します。
$ ipa user-mod user --addattr=mobile=mobile_number_1 --addattr=mobile=mobile_number_2
ipa user-mod コマンドは、属性値の設定に --setattr オプションを、属性値の削除に --delattr オプションを指定することができます。これらのオプションは、--addattr と同じように使用されます。詳細は ipa user-mod --help コマンドの出力を参照してください。
注記
--email オプションを使用しますが、別のメールアドレスを追加するには、--email オプションと --addattr オプションを使用します。
$ ipa user-mod user --email=email@example.com $ ipa user-mod user --addattr=mail=another_email@example.com
11.4. ユーザーアカウントの有効化、無効化
active の状態のまま保持されるので、ipa user-find コマンドを実行すると、出力に表示されます。以下に例を示します。
$ ipa user-find
...
User login: user
First name: User
Last name: User
Home directory: /home/user
Login shell: /bin/sh
UID: 1453200009
GID: 1453200009
Account disabled: True
Password: False
Kerberos keys available: False
...注記
Web UI でのユーザーアカウントの有効化および無効化
- → タブを選択します。
- Active users 一覧から対象のユーザーを選択して、 または をクリックします。

図11.12 ユーザーアカウントの無効化または有効化
コマンドラインからのユーザーアカウントの無効化および有効化
ipa user-disable コマンドを使用します。
$ ipa user-disable user_login ---------------------------- Disabled user account "user_login" ----------------------------
ipa user-enable コマンドを使用します。
$ ipa user-enable user_login ---------------------------- Enabled user account "user_login" ----------------------------
11.5. 管理者以外のユーザーによるユーザーエントリーの管理許可
admin ユーザーのみがユーザーライフサイクルの管理やユーザーアカウントの有効化/無効化が可能です。管理者以外の別ユーザがこの操作をできるようにするには、新規ロールを作成して、このロールに適切なパーミッションを追加し、管理者以外のユーザーにこのロールを割り当てます。
- Modify Users and Reset passwords
- この権限には、さまざまなユーザー属性を変更するパーミッションが含まれます。
- User Administrators
- この権限は、active ユーザーの追加、active 以外のユーザーのアクティベート、ユーザーの削除、ユーザー属性やその他のパーミッションの変更が含まれます。
- Stage User Provisioning
- この権限には、stage ユーザーを追加するパーミッションが含まれます。
- Stage User Administrator
- 以下の権限には、stage ユーザーの追加、ライフサイクルの状態の間におけるユーザーの移動などライフサイクルでの操作を実行するパーミッションが含まれます。ただし、active の状態にユーザーを移動するパーミッションは含まれません。
異なるユーザーに対するさまざまなユーザー管理操作の実行許可
- stage user administrator ユーザーを 1 つ設定する。このユーザーは、IdM に 今後入社する従業員を stage ユーザーとして追加できるが、アクティベートはできません。
- security administrator として別のユーザーを 1 つ設定する。このユーザーは、就業日初日に従業員の認証情報を確認後に、stage ユーザーをアクティベートすることができます。
例11.1 管理者以外のユーザーによる stage ユーザーの追加許可
- ロールベースのアクセス制御を管理可能な
adminユーザーまたは別のユーザーとしてログインします。$ kinit admin
- 新規カスタムロールを作成して、stage ユーザーの追加を管理します。
System Provisioningロールを作成します。$ ipa role-add --desc "Responsible for provisioning stage users" "System Provisioning" -------------------------------- Added role "System Provisioning" -------------------------------- Role name: System Provisioning Description: Responsible for provisioning stage users
Stage User Provisioningの権限をロールに割り当てます。この権限により、stage ユーザーが追加できるようになります。$ ipa role-add-privilege "System Provisioning" --privileges="Stage User Provisioning" Role name: System Provisioning Description: Responsible for provisioning stage users Privileges: Stage User Provisioning ---------------------------- Number of privileges added 1 ----------------------------
- 管理者以外のユーザーに stage ユーザーを追加する権限を割り当てます。
- 管理者以外のユーザーが存在しない場合には、新規ユーザーを作成します。以下の例では
stage_user_adminという名前のユーザーです。$ ipa user-add stage_user_admin --password First name: first_name Last name: last_name Password: Enter password again to verify: ...
stage_user_adminユーザーにSystem Provisioningロールを割り当てます。$ ipa role-add-member "System Provisioning" --users=stage_user_admin Role name: System Provisioning Description: Responsible for provisioning stage users Member users: stage_user_admin Privileges: Stage User Provisioning ------------------------- Number of members added 1 -------------------------
System Provisioningロールが正しく設定されていることを確認するには、ipa role-showコマンドを使用してロールの設定を表示します。$ ipa role-show "System Provisioning" -------------- 1 role matched -------------- Role name: System provisioning Description: Responsible for provisioning stage users Member users: stage_user_admin Privileges: Stage User Provisioning ---------------------------- Number of entries returned 1 ----------------------------
stage_user_adminユーザーとして新しい stage ユーザーが追加されているかをテストします。stage_user_adminとしてログインします。以前の手順で新規ユーザーとしてstage_user_adminを作成した場合は、IdM によりadminが設定した初期パスワードを変更するように求められます。$ kinit stage_user_admin Password for stage_user_admin@EXAMPLE.COM: Password expired. You must change it now. Enter new password: Enter it again:
adminの Kerberos チケットがstage_user_adminの Kerberos チケットに置き換えられていることを確認するにはklistユーティリティーを使用します。$ klist Ticket cache: KEYRING:persistent:0:krb_ccache_xIlCQDW Default principal: stage_user_admin@EXAMPLE.COM Valid starting Expires Service principal 02/25/2016 11:42:20 02/26/2016 11:42:20 krbtgt/EXAMPLE.COM- 新規 stage ユーザーを追加します。
$ ipa stageuser-add stage_user First name: first_name Last name: last_name ipa: ERROR: stage_user: stage user not found
注記
stage ユーザーの追加後に IdM からエラーが報告されるのは想定内です。stage_user_adminは、stage ユーザーの追加のみが可能で、stage ユーザーの情報の表示はできません。そのため、新たに追加されたstage_userの設定サマリーを表示する代わりに、IdM はエラーを表示します。
stage_user_admin ユーザーは、stage ユーザーの情報を表示できません。そのため、stage_user_admin でログインして、新しい stage_user ユーザーに関する情報を表示しようとすると、失敗してしまいます。
$ ipa stageuser-show stage_user ipa: ERROR: stage_user: stage user not found
stage_user に関する情報を表示するには admin でログインしてください。
$ kinit admin Password for admin@EXAMPLE.COM: $ ipa stageuser-show stage_user User login: stage_user First name: Stage Last name: User ...
11.6. ユーザーおよびグループへの外部プロビジョニングシステムの使用
11.6.1. 外部プロビジョニングシステムで使用されるようにユーザーアカウントを設定する手順
- stage ユーザーの追加権限のあるユーザー
provisionatorを作成します。外部プロビジョニングシステムがこのユーザーアカウントを使用して新しい stage ユーザーを追加します。provisionatorユーザーアカウントを追加します。$ ipa user-add provisionator --first=provisioning --last=account --password
provisionatorユーザーに必要な権限を割り当てます。stage ユーザーの追加を管理するSystem Provisioningというカスタムロールを作成します。$ ipa role-add --desc "Responsible for provisioning stage users" "System Provisioning"
Stage User Provisioningの権限をロールに割り当てます。この権限により、stage ユーザーが追加できるようになります。$ ipa role-add-privilege "System Provisioning" --privileges="Stage User Provisioning"
provisionatorユーザーをロールに追加します。$ ipa role-add-member --users=provisionator "System Provisioning"
- ユーザーアカウントの管理権限を持つ
activatorユーザーを作成します。このユーザーアカウントを使用すると、外部プロビジョニングシステムにより追加された stage ユーザーが自動的にアクティベートされます。activatorユーザーアカウントを追加します。$ ipa user-add activator --first=activation --last=account --password
activatorユーザーに必要な権限を割り当てます。デフォルトのUser Administratorロールにこのユーザーを追加します。$ ipa role-add-member --users=activator "User Administrator"
- サービスおよびアプリケーションアカウントのユーザーグループを作成します。
$ ipa group-add service-accounts
- グループのパスワードポリシーを更新します。以下のポリシーは、アカウントのパスワードの期限切れやロックアウトがされないようにしますが、複雑なパスワードを求めることでリスクの可能性を低減します。
$ ipa pwpolicy-add service-accounts --maxlife=10000 --minlife=0 --history=0 --minclasses=4 --minlength=20 --priority=1 --maxfail=0 --failinterval=1 --lockouttime=0
- サービスおよびアプリケーションアカウントのグループにプロビジョニングアカウントとアクティベーションアカウントを追加します。
$ ipa group-add-member service-accounts --users={provisionator,activator} - ユーザーアカウントのパスワードを変更します。
$ kpasswd provisionator $ kpasswd activator
新規の IdM ユーザーのパスワードはすぐに失効するため、パスワードを変更する必要があります。
- 新規ユーザーの追加に関する情報は、「stage または Active ユーザーの追加」を参照してください。
- 他のユーザーアカウントの管理に必要な権限をユーザーに割り当てる方法については 「管理者以外のユーザーによるユーザーエントリーの管理許可」を参照してください。
- IdM パスワードポリシーの管理に関する詳しい情報は27章パスワードポリシーの定義を参照してください。
11.6.2. IdM が自動的に stage ユーザーアカウントをアクティベートするように設定する手順
重要
- アカウントのアクティベート用に keytab ファイルを生成します。
# ipa-getkeytab -s example.com -p "activator" -k /etc/krb5.ipa-activation.keytab
複数の IdM サーバーでアクティベーションプロセスを有効にするには、1 つのサーバーでのみ keytab ファイルを作成し、他のサーバーにその keytab ファイルをコピーします。 - 以下の内容を含む
/usr/local/sbin/ipa-activate-allスクリプトを作成して全ユーザーをアクティベートします。#!/bin/bash kinit -k -i activator ipa stageuser-find --all --raw | grep " uid:" | cut -d ":" -f 2 | while read uid; do ipa stageuser-activate ${uid}; done ipa-activate-allスクリプトのパーミッションと所有者を編集して、実行可能なファイルに変更します。# chmod 755 /usr/local/sbin/ipa-activate-all # chown root:root /usr/local/sbin/ipa-activate-all
systemdのユニットファイルである/etc/systemd/system/ipa-activate-all.serviceを作成して以下の内容を追加します。[Unit] Description=Scan IdM every minute for any stage users that must be activated [Service] Environment=KRB5_CLIENT_KTNAME=/etc/krb5.ipa-activation.keytab Environment=KRB5CCNAME=FILE:/tmp/krb5cc_ipa-activate-all ExecStart=/usr/local/sbin/ipa-activate-all
systemdタイマーである/etc/systemd/system/ipa-activate-all.timerを作成して以下の内容を追加します。[Unit] Description=Scan IdM every minute for any stage users that must be activated [Timer] OnBootSec=15min OnUnitActiveSec=1min [Install] WantedBy=multi-user.target
ipa-activate-all.timerを有効化します。# systemctl enable ipa-activate-all.timer
11.6.3. 外部プロビジョニングシステムの LDAP プロバイダーが IdM のアイデンティティーを管理するように設定する手順
LDAP を使用したユーザーアカウントの管理
ldapmodify ユーティリティーを使用します。
ldapmodify を使用して変更する属性に関する情報が含まれます。例に関する詳しい手順は 例11.2「ldapmodify での stage ユーザーへの追加」 および 例11.3「ldapmodify でのユーザーの保存」を参照してください。
- 新規 stage ユーザーの追加
- UID および GID が自動的に割り当てられたユーザーの追加
dn: uid=user_login,cn=staged users,cn=accounts,cn=provisioning,dc=example,dc=com changetype: add objectClass: top objectClass: inetorgperson uid: user_login sn: surname givenName: first_name cn: full_name
UID および GID が静的に割り当てられたユーザーの追加dn: uid=user_login,cn=staged users,cn=accounts,cn=provisioning,dc=example,dc=com changetype: add objectClass: top objectClass: person objectClass: inetorgperson objectClass: organizationalperson objectClass: posixaccount uid: user_login uidNumber: UID_number gidNumber: GID_number sn: surname givenName: first_name cn: full_name homeDirectory: /home/user_login
stage ユーザーの追加時に IdM オブジェクトクラスを指定する必要はありません。IdM は、ユーザーのアクティベート後に、これらのクラスを自動的に追加します。作成したエントリーの識別名 (DN) はuid=user_loginで開始する必要がある点に注意してください。 - 既存ユーザーの変更
- ユーザーを変更する前に、ユーザーの識別名 (DN) をユーザーのログインで検索して取得します。以下の例では、user_allowed_to_read ユーザーは、ユーザーおよびグループの情報を読み込む権限があり、password はユーザーのパスワードとなっています。
# ldapsearch -LLL -x -D "uid=user_allowed_to_read,cn=users,cn=accounts,dc=example, dc=com" -w "password" -H ldap://server.example.com -b "cn=users, cn=accounts, dc=example, dc=com" uid=user_login
ユーザーの属性を変更する方法:dn: distinguished_name changetype: modify replace: attribute_to_modify attribute_to_modify: new_value
ユーザーを無効化する方法:dn: distinguished_name changetype: modify replace: nsAccountLock nsAccountLock: TRUE
ユーザーを有効化する方法:dn: distinguished_name changetype: modify replace: nsAccountLock nsAccountLock: FALSE
ユーザーを保存する方法:dn: distinguished_name changetype: modrdn newrdn: uid=user_login deleteoldrdn: 0 newsuperior: cn=deleted users,cn=accounts,cn=provisioning,dc=example
nssAccountLock属性を更新しても、stage および preserved ユーザーには影響はありません。更新操作が正常に完了しても、属性の値はnssAccountLock: TRUEのままです。 - 新規グループの作成
- 新規グループの作成方法:
dn: cn=group_distinguished_name,cn=groups,cn=accounts,dc=example,dc=com changetype: add objectClass: top objectClass: ipaobject objectClass: ipausergroup objectClass: groupofnames objectClass: nestedgroup objectClass: posixgroup cn: group_name gidNumber: GID_number
- グループの変更
- グループを変更する前に、グループ名で検索してグループの識別名 (DN) を取得します。
# ldapsearch -YGSSAPI -H ldap://server.example.com -b "cn=groups,cn=accounts,dc=example,dc=com" "cn=group_name"
既存のグループの削除方法:dn: group_distinguished_name changetype: delete
グループにメンバーを追加する方法:dn: group_distinguished_name changetype: modify add: member member: uid=user_login,cn=users,cn=accounts,dc=example,dc=com
グループからメンバーを削除する方法:dn: distinguished_name changetype: modify delete: member member: uid=user_login,cn=users,cn=accounts,dc=example,dc=com
stage または preserved ユーザーをグループには追加しないでください。更新が正常に完了した場合でも、ユーザーはグループのメンバーとして更新されません。active ユーザーだけがグループに所属します。
例11.2 ldapmodify での stage ユーザーへの追加
interorgperson オブジェクトクラスを使用して stageuser ユーザーを追加する方法:
ldapmodifyを使用してユーザーを追加します。# ldapmodify -Y GSSAPI SASL/GSSAPI authentication started SASL username: admin@EXAMPLE SASL SSF: 56 SASL data security layer installed. dn: uid=stageuser,cn=staged users,cn=accounts,cn=provisioning,dc=example changetype: add objectClass: top objectClass: inetorgperson cn: Stage sn: User adding new entry "uid=stageuser,cn=staged users,cn=accounts,cn=provisioning,dc=example"
- ステージエントリーの内容を検証し、必要とされる POSIX 属性がプロビジョニングシステムに追加され、ステージエントリーのアクティベートの準備ができていることを確認します。新規 stage ユーザーの LDAP 属性を表示するには、
ipa stageuser-show --all --rawコマンドを使用します。ユーザーはnsaccountlock属性で明示的に無効化されていることに注意してください。$ ipa stageuser-show stageuser --all --raw dn: uid=stageuser,cn=staged users,cn=accounts,cn=provisioning,dc=example uid: stageuser sn: User cn: Stage has_password: FALSE has_keytab: FALSE nsaccountlock: TRUE objectClass: top objectClass: inetorgperson objectClass: organizationalPerson objectClass: person
例11.3 ldapmodify でのユーザーの保存
modrdn 操作を使用して user を保存する方法:
ldapmodifyユーティリティーを使用してユーザーエントリーを変更します。$ ldapmodify -Y GSSAPI SASL/GSSAPI authentication started SASL username: admin@EXAMPLE SASL SSF: 56 SASL data security layer installed. dn: uid=user1,cn=users,cn=accounts,dc=example changetype: modrdn newrdn: uid=user1 deleteoldrdn: 0 newsuperior: cn=deleted users,cn=accounts,cn=provisioning,dc=example modifying rdn of entry "uid=user1,cn=users,cn=accounts,dc=example"
- オプションで、すべての preserved ユーザーを表示して、このユーザーが保存されたことを確認します。
$ ipa user-find --preserved=true --------------- 1 user matched --------------- User login: user1 First name: first_name Last name: last_name ... ---------------------------- Number of entries returned 1 ----------------------------
第12章 ホストの管理
- DNS エントリーおよび設定
- マシン認証
- (ドメインサービスに影響する) ホスト名の変更
12.1. ホスト、サービス、およびマシン ID と認証
- ホストに関連付けられたサービスエントリー
- ホストおよびサービスプリンシパル
- アクセス制御ルール
- 物理的位置やオペレーティングシステムなどのマシンについての情報
- DNS
- Kerberos
- 証明書管理
- DNS ドメインへの参加 (マシン登録)
- DNS エントリーおよびゾーンの管理
- マシン認証の管理
- SSH 鍵。ホスト用の SSH 公開鍵が作成され、ホストエントリーにアップロードされます。そこから System Security Services Daemon (SSSD) は、IdM を ID プロバイダーとして使用し、OpenSSH や他のサービスと連携して Identity Management に一元化して設置されている公開鍵を参照します。これは 「ホストの公開 SSH キーの管理」 で説明しています。
- キーテーブル (または keytabs。対称キーで、多少ユーザーパスワードに類似) およびマシン証明書。Kerberos チケットは Kerberos サービスの一部として生成され、ポリシーはサーバーが定義します。初期の Kerberos チケットの提供、Kerberos 証明書の更新、Kerberos セッションの破棄はすべて IdM サービスによって処理されます。Kerberos の管理は 28章Kerberos ドメインの管理 で説明されています。
- マシンの証明書。この場合、IdM サーバーの認証局が発行し、IdM の Directory Server に保存されている SSL 証明書をマシンは使用します。証明書はマシンに送信され、サーバーに対して認証する際に提示されます。クライアントでは、証明書は certmonger と呼ばれるサービスが管理します。
12.2. ホストエントリー設定のプロパティー
表12.1 ホスト設定のプロパティー
| UI フィールド | コマンドラインオプション | Description |
|---|---|---|
| Description | --desc=description | ホストの説明。 |
| Locality | --locality=locality | ホストの位置情報 |
| Location | --location=location | データセンターラックなど、ホストの位置情報 |
| Platform | --platform=string | ホストのハードウェアまたはアーキテクチャー |
| Operating system | --os=string | ホストのオペレーティングシステムおよびバージョン |
| MAC address | --macaddress=address | ホストの MAC アドレス。これは複数値の属性です。MAC アドレスは、NIS プラグインがホスト用の NIS ethers マップを作成するために使用します。 |
| SSH public keys | --sshpubkey=string | ホスト用の SSH 公開鍵。これは複数値の属性なので、複数の鍵を設定できます。 |
| Principal name (not editable) | --principalname=principal | ホストの Kerberos プリンシパル名。これは -p オプションで明示的に別のプリンシパルを設定しなければ、クライアントのインストール中にホスト名でデフォルト設定されます。これはコマンドラインツールを使用すると変更可能ですが、UI では変更できません。 |
| Set One-Time Password | --password=string | 一括登録で使用可能なホストのパスワードを設定します。 |
| - | --random | 一括登録で使用されるランダムなパスワードを生成します。 |
| - | --certificate=string | ホストの証明書ブロブ。 |
| - | --updatedns | これは IP アドレス変更時にホストが DNS エントリーを動的に更新できるかどうかを設定します。 |
12.3. ホストエントリーの追加
12.3.1. Web UI でのホストエントリーの追加
- Identity タブを開き、Hosts サブタブを選択します。
- ホスト一覧上部にある をクリックします。

図12.1 ホストエントリーの追加
- マシン名を記入し、ドロップダウンリストの設定済みゾーンからドメインを選択します。ホストに既に静的 IP アドレスが割り当てられている場合は、ホストエントリーにそのアドレスを含めることで DNS エントリーが完全に作成されます。

図12.2 ホスト追加ウィザード
DNS ゾーンは IdM で作成可能で、これは 「Master DNS ゾーンの追加と削除」 で説明しています。IdM サーバーが DNS サーバーを管理しない場合は、ゾーンは通常のテキストフィールドのようにメニューエリアで手動で入力することができます。注記
ホスト名が解決できない場合でも、Force チェックボックスを選択してホスト DNS レコードを追加してください。これは DHCP を使用し、静的 IP アドレスを持たないホストで便利なものです。これにより、IdM DNS サービスにプレースホルダーエントリーが作成されます。DNS サービスが動的にレコードを更新すると、ホストの現行の IP アドレスが削除され、DNS レコードが更新されます。 - Add and Edit をクリックして、拡張エントリーページに移動し、属性情報をさらに入力します。ホストエントリーには、ホストのハードウェアや物理的な場所に関する情報を含めることができます。

図12.3 展開されたエントリーページ
12.3.2. コマンドラインでのホストエントリーの追加
host-add コマンドを使って作成されます。このコマンドは、ホストエントリーを IdM Directory Server に追加します。host-add の全オプションは、ipa host man ページに記載されています。このコマンドの最も基本的な操作では、クライアントを Kerberos レルムに追加し、IdM LDAP サーバーにエントリーを作成するために、クライアントのホスト名のみが必要となります。
$ ipa host-add client1.example.com
--ip-address および --force のオプションを使用してホストを DNS リソースレコードに追加することができます。
例12.1 静的 IP アドレスのホストエントリーの作成
$ ipa host-add --force --ip-address=192.168.166.31 client1.example.com
--force を使用して DNS エントリーを設定することができます。これにより、IdM DNS サービスにプレースホルダーエントリーが作成されます。DNS サービスが動的にレコードを更新すると、ホストの現行の IP アドレスが削除され、DNS レコードが更新されます。
例12.2 DHCP のホストエントリーの作成
$ ipa host-add --force client1.example.com
host-del コマンドを使用するとホストレコードが削除されます。IdM ドメインが DNS を使用している場合は、--updatedns オプションはホスト関連のレコードも DNS から削除します。
$ ipa host-del --updatedns client1.example.com
12.4. ホストエントリーの無効化および再有効化
12.4.1. ホストエントリーの無効化
host-disable コマンドを使用することで実行できます。
[jsmith@ipaserver ~]$ kinit admin [jsmith@ipaserver ~]$ ipa host-disable server.example.com
重要
12.4.2. ホストの再有効化
ipa-getkeytab コマンドを使用するだけです。-s オプションはどの IdM サーバーに keytab を要求するかを設定し、-p はプリンシパル名を提示し、-k では keytab を保存するファイルを提供します。
[jsmith@ipaserver ~]$ ipa-getkeytab -s ipaserver.example.com -p host/server.example.com -k /etc/krb5.keytab -D fqdn=server.example.com,cn=computers,cn=accounts,dc=example,dc=com -w password
ipa-getkeytab コマンドをアクティブな IdM クライアントまたはサーバーで実行する場合は、LDAP 認証情報 (-D および -w) なしで実行可能です。IdM ユーザーは、Kerberos 認証情報を使ってドメインに認証します。無効となっているホスト上で直接コマンドを実行するには、LDAP 認証情報を提供して IdM サーバーに認証を行います。認証情報は、再有効化を行なっているホストまたはサーバーに対応するものにしてください。
12.5. ホストの公開 SSH キーの管理
known_hosts ファイルに保存します。リモートのマシンがターゲットマシンにアクセスを再度試みると、ターゲットマシンは known_hosts ファイルをチェックして、認証済みホストに自動的にアクセスを許可します。
known_hostsファイルは、ホストエントリーをホスト IP アドレス、ホスト名、およびキーという 3 項目で保存します。IP アドレスが変更されたり (仮想環境やデータセンターでは一般的)、キーが更新されたりすると、このファイルはすぐに無効になってしまいます。- SSH キーは、環境内の全マシンに手動かつ個別に配布する必要があります。
- 管理者は設定に追加するホストキーを許可する必要がありますが、ホストまたはキー発行者を適切に検証することが困難なことから、セキュリティー問題が発生する可能性があります。
12.5.1. SSH 鍵の形式
~/.ssh/known_hosts のようなキーファイルでは、キーのエントリーはサーバーのホスト名および IP アドレス、キーのタイプ、最後にキー自体で識別されます。例を示します。
host.example.com,1.2.3.4 ssh-rsa AAA...ZZZ==
"ssh-rsa ABCD1234...== ipaclient.example.com"
~/.ssh/known_hosts ファイルからのホスト公開キーエントリーがユーザーキーの形式 type key== comment に一致するように順序を変える必要があります。
ssh-rsa AAA...ZZZ== host.example.com,1.2.3.4
12.5.2. ipa-client-install および OpenSSH
ipa-client-install スクリプトはデフォルトで、OpenSSH サーバーと IdM クライアントマシン上のクライアントを設定します。また SSSD がホストおよびユーザーキーのキャッシングを実行するように設定します。実質的には、クライアントを設定するだけで、ホストがキーキャッシングおよび取得のために SSSD、OpenSSH、および Identity Management を使用するすべての必須設定が実行されます。
ssh サービスの初回起動時に RSA キーが作成されます。
注記
ipa-client-install を使用して IdM クライアントとしてマシンを追加する場合、クライアントには RSA および DSS という 2 つの SSH キーが作成されます。
ipa-client-install コマンドには --ssh-trust-dns という設定オプションもあり、これを一緒に実行すると、OpenSSH が キーフィンガープリントを保存している IdM DNS レコードを信頼するように自動設定します。
--no-sshd を使ってクライアントインストール時に OpenSSH を無効にすることができます。これにより、インストールスクリプトは OpenSSH サーバーを設定できなくなります。
--no-dns-sshfp というもうひとつのオプションは、ホストが自身の DNS エントリーで DNS SSHFP レコードを作成できないようにします。これは --no-sshd オプションとの併用も可能です。
12.5.3. ホスト SSH 鍵の Web UI でのアップロード
- ホストのキーは、
~/.ssh/known_hostsから取得できます。例を示します。server.example.com,1.2.3.4 ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEApvjBvSFSkTU0WQW4eOweeo0DZZ08F9Ud21xlLy6FOhzwpXFGIyxvXZ52+siHBHbbqGL5+14N7UvElruyslIHx9LYUR/pPKSMXCGyboLy5aTNl5OQ5EHwrhVnFDIKXkvp45945R7SKYCUtRumm0Iw6wq0XD4o+ILeVbV3wmcB1bXs36ZvC/M6riefn9PcJmh6vNCvIsbMY6S+FhkWUTTiOXJjUDYRLlwM273FfWhzHK+SSQXeBp/zIn1gFvJhSZMRi9HZpDoqxLbBB9QIdIw6U4MIjNmKsSI/ASpkFm2GuQ7ZK9KuMItY2AoCuIRmRAdF8iYNHBTXNfFurGogXwRDjQ==
必要に応じて、ホストキーを生成します。OpenSSH ツールを使用の場合は、空白のパスフレーズを使用し、キーをユーザーの~/.ssh/ディレクトリー以外の場所に保存して、既存のキーを上書きしないようにします。[jsmith@server ~]$ ssh-keygen -t rsa -C "server.example.com,1.2.3.4" Generating public/private rsa key pair. Enter file in which to save the key (/home/jsmith/.ssh/id_rsa): /home/jsmith/.ssh/host_keys Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /home/jsmith/.ssh/host_keys. Your public key has been saved in /home/jsmith/.ssh/host_keys.pub. The key fingerprint is: SHA256:GAUIDVVEgly7rs1lTWP6oguHz8BKvyZkpqCqVSsmi7c server.example.com The key's randomart image is: +--[ RSA 2048]----+ | .. | | .+| | o .* | | o . .. *| | S + . o+| | E . .. .| | . = . o | | o . ..o| | .....| +-----------------+
- 公開キーをキーファイルからコピーします。完全なキーエントリーは、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
- Identity タブを開き、Hosts サブタブを選択します。
- 編集するホスト名をクリックします。

図12.4 ホストの一覧
- Settings タブの Host Settings エリアで、SSH public keys の横にある Add をクリックします。

図12.5 SSH キーの追加
- ホストの公開キーを貼り付けて、 をクリックします。

図12.6 SSH キーの設定
これで SSH public keys フィールドに、新しいキーが表示されます。Show/Set key をクリックすると、追加したキーが表示されます。 - 複数のキーをアップロードするには、公開キーリストの下にある Add をクリックして、他のキーをアップロードします。
- すべてのキーが追加されたら、ホストページ上部の Save をクリックして、変更を保存します。
12.5.4. コマンドライン からホストキーを追加する
host-add を使ってホストを作成する際か、エントリーを後で修正する際になります。
注記
ipa-client-install コマンドで RSA と DSS ホストキーが作成されます。
host-modコマンドを--sshpubkeyオプションと実行して、base64 暗号化公開キーをユーザーエントリーにアップロードします。ホストキーを追加するとホストの DNS SSHFP エントリーも変更されるので、--updatednsオプションも使ってホストの DNS エントリーも更新します。例を示します。[jsmith@server ~]$ ipa host-mod --sshpubkey="ssh-rsa RjlzYQo==" --updatedns host1.example.com
キーは通常はイコール記号 (=) で終わりますが、実際にはもっと長いものになります。複数のキーをアップロードするには、複数の--sshpubkeyコマンドラインパラメーターを入力します。--sshpubkey="RjlzYQo==" --sshpubkey="ZEt0TAo=="
注記
ホストは複数の公開キーを持つことが可能です。- ホストキーをアップロードしたら、Identity Management を ID ドメインの 1 つとして使用するよう SSSD を設定し、OpenSSH がホストキー管理に SSSD ツールを使用するよう設定します。これは、the "Configuring Services: OpenSSH and Cached Keys" section in the System-Level Authentication Guide で説明しています。
12.5.5. ホストキーの削除
- Identity タブを開き、Hosts サブタブを選択します。
- 編集するホスト名をクリックします。

図12.7 ホストの一覧
- SSH public keys エリアで、削除するキーの指紋の横にある Delete をクリックします。

図12.8 公開キーの削除
- ホストのページの上部にある Save をクリックして変更を保存します。
ipa host-mod を --sshpubkey= の値を空白にして実行します。これでホストのすべての公開キーが削除されます。また、--updatedns オプションを使うと、ホストの DNS エントリーが更新されます。例を示します。
[jsmith@server ~]$ kinit admin [jsmith@server ~]$ ipa host-mod --sshpubkey= --updatedns host1.example.com
12.6. ホストの ethers 情報の設定
ethers テーブルをホストすることができます。これを使うと、システムのプラットホームやオペレーティングシステム、DNS ドメイン、および MAC アドレスに基づいて DHCP 設定ファイルを管理することができます。これらすべての情報は、IdM のホストエントリーに保存されます。
ou=ethers サブツリーのディレクトリーに含まれる適切な ethers エントリーで作成されます。
cn=server,ou=ethers,dc=example,dc=com
ethers サービスの NIS マップを作成するために使用されます。ethers サービスは、IdM の NIS 互換性プラグインで管理できます。
ethers エントリーの NIS マップを設定するには、以下の手順に従います。
- ホストエントリーに MAC アドレス属性を追加します。例を示します。
[jsmith@server ~]$ kinit admin [jsmith@server ~]$ ipa host-mod --macaddress=12:34:56:78:9A:BC server.example.com
nsswitch.confファイルを開きます。ethersサービスの行を追加し、ルックアップに LDAP を使用するよう設定します。ethers: ldap
ethers情報がクライアントで利用可能かどうかを確認します。[root@server ~]# getent ethers server.example.com
第13章 ユーザーおよびホストグループの管理
13.1. ユーザーおよびホストグループの IdM での機能
13.1.1. ユーザーおよびホストグループとは
13.1.2. サポートされるグループメンバー
- IdM ユーザー
- その他の IdM ユーザーグループ
- IdM 以外に所属する外部ユーザー
- IdM サーバーおよびクライアント
- その他の IdM ホストグループ
13.1.3. グループの直接および間接メンバー
- ユーザー 1 およびユーザー 2 は、グループ A の 直接メンバー です。
- ユーザー 3、ユーザー 4 およびユーザー 5 は、グループ A の 間接メンバー です。

図13.1 グループの直接および間接メンバー
例13.1 グループの直接および間接メンバーの表示
- 以下を追加します。
group_Aのメンバーとしてユーザーを 1 つ追加します。- 別のユーザーを
group_Bのメンバーとして追加します。 group_Aメンバーとしてgroup_Bを追加します。
「ユーザーまたはホストグループメンバーの追加および削除」を参照してください。 - Web UI で、 → を選択します。左側のサイドバーに表示されている各グループタイプから、 を選択し、
group_Aの名前をクリックします。Direct Membership と Indirect Membership を切り替えます。 - コマンドラインを使用する場合は
ipa group-showコマンドを実行します。$ ipa group-show group_A ... Member users: user_1 Member groups: group_B Indirect Member users: user_2
13.1.4. IdM のユーザーグループタイプ
- POSIX グループ (デフォルト)
- POSIX グループは、所属メンバーの POSIX 属性をサポートします。Active Directory と対話するグループは POSIX の属性を使用できない点に注意してください。
- POSIX 以外のグループ
- このタイプのグループメンバーはすべて、IdM ドメインに所属する必要があります。
- 外部グループ
- 外部グループにより、IdM ドメイン以外のアイデンティティーストアに存在するグループメンバーを追加できます。外部ストアは、ローカルシステム、Active Directory ドメイン、ディレクトリーサービスのいずれかを指定できます。
例13.2 異なるタイプのユーザーグループの検索
- 全ユーザーグループを表示するには、
ipa group-findコマンドを実行します。 - また、全 POSIX グループを表示するには、
ipa group-find --posixコマンドを実行します。 - POSIX グループ以外のグループをすべて表示するには
ipa group-find --nonposixコマンドを実行します。 - 全外部グループを表示するには
ipa group-find --externalコマンドを実行します。
13.1.5. デフォルトで作成されるユーザーおよびホストグループ
表13.1 デフォルトで作成されるユーザーおよびホストグループ
| グループ名 | ユーザーまたはホスト | デフォルトのグループメンバー |
|---|---|---|
ipausers | ユーザーグループ | 全 IdM ユーザー |
admins | ユーザーグループ | 管理者権限のあるユーザー。デフォルトでは最初は admin ユーザーです。 |
editors | ユーザーグループ | 管理者ユーザーの権限なしに Web UI で他の IdM ユーザーを編集できるユーザー |
trust admins | ユーザーグループ | Active Directory トラストを管理する権限のあるユーザー |
ipaservers | ホストグループ | 全 IdM サーバーホスト |
admins グループにユーザーを追加するには、ユーザーに管理者権限が割り当てられます。
警告
ipaservers ホストグループにホストを追加するときは注意してください。ipaservers のホストにはすべて、IdM サーバーにプロモートする機能が割り当てられています。
- ユーザープライベートグループは、作成したユーザーと同じ名前が指定されます。
- このユーザーは、ユーザープライベートグループにのみ所属します。
- プライベートグループの GID は、ユーザーの UID と同じです。
例13.3 ユーザープライベートグループの表示
ipa group-find --private コマンドを実行します。
$ ipa group-find --private ---------------- 2 groups matched ---------------- Group name: user1 Description: User private group for user1 GID: 830400006 Group name: user2 Description: User private group for user2 GID: 830400004 ---------------------------- Number of entries returned 2 ----------------------------
13.2. ユーザーまたはホストグループの追加および削除
- Web UI (「Web UI: ユーザーまたはホストグループの追加」を参照してください)
- コマンドライン (「コマンドライン: ユーザーまたはホストグループの追加」を参照してください)
- Web UI (「Web UI: ユーザーまたはホストグループの削除」を参照してください)
- コマンドライン (「コマンドライン: ユーザーまたはホストグループの削除」を参照してください)
Web UI: ユーザーまたはホストグループの追加
- → をクリックして、左のサイドバーで または を選択してください。
- をクリックして、グループの追加を開始します。
- グループの情報を入力します。ユーザーグループタイプの詳細は、「IdM のユーザーグループタイプ」を参照してください。
- をクリックして確定します。
コマンドライン: ユーザーまたはホストグループの追加
- 管理者としてログインします。
$ kinit admin
- ユーザーグループを追加するには
ipa group-addコマンドを実行し、ホストグループを追加するにはipa hostgroup-addコマンドを使用します。$ ipa group-add group_name ----------------------- Added group "group_name" ------------------------
ipa group-add は POSIX ユーザーグループを追加します。異なるグループタイプを指定するには、ipa group-add にオプションを追加します。
- POSIX グループ以外を追加するには
--nonposix - 外部グループを作成するには
--external
Web UI: ユーザーまたはホストグループの削除
- → をクリックして、左のサイドバーで または を選択してください。
- 削除するグループを選択して をクリックします。
コマンドライン: ユーザーまたはホストグループの削除
- 管理者としてログインします。
$ kinit admin
- ユーザーグループを削除するには
ipa group-del group_nameコマンドを、ホストグループを削除するにはipa hostgroup-del group_nameコマンドを実行します。$ ipa group-del group_name -------------------------- Deleted group "group_name" --------------------------
13.3. ユーザーまたはホストグループメンバーの追加および削除
- IdM Web UI (「Web UI: ユーザーまたはホストグループへのメンバーの追加」を参照してください)
- コマンドライン (「コマンドライン: メンバーのユーザーグループへの追加」を参照してください)
重要
- IdM Web UI (「Web UI: ユーザーまたはホストグループからのメンバーの削除」を参照してください)
- コマンドライン (「コマンドライン: ユーザーグループからのメンバーの削除」を参照してください)
Web UI: ユーザーまたはホストグループへのメンバーの追加
- → をクリックして、左のサイドバーで または を選択してください。
- グループ名をクリックします。
- 追加するグループメンバーのタイプを選択します。ユーザーグループの Users、User Groups または External などです。

図13.3 ユーザーグループメンバーの追加
- をクリックします。
- 追加するメンバーを選択し、 をクリックして確定します。
コマンドライン: メンバーのユーザーグループへの追加
- オプション: グループの検索には、
ipa group-findまたはipa hostgroup-findコマンドを使用します。 - ユーザーグループにメンバーを追加するには
ipa group-add-memberコマンドを実行し、ホストグループにメンバーを追加するにはipa hostgroup-add-memberコマンドを使用します。ユーザーグループメンバーを追加する場合は、以下のオプションを使用してメンバーを指定します。--usersを指定して、IdM ユーザーを追加します。DOMAIN\user_nameまたはuser_name@domainの形式で、--externalを指定して IdM ドメイン外に存在するユーザーを追加します。--groupsを指定して IdM ユーザーグループを追加します。
ホストグループメンバーを追加する場合は、以下のオプションを使用してメンバーを指定します。--hostsを指定して IdM ホストを追加します。--groupsを指定して IdM ホストグループを追加します。
たとえば、group_name と呼ばれるグループに、user1、user2 および group1 を追加するには、以下を実行します。$ ipa group-add-member group_name --users=user1 --users=user2 --groups=group1
Web UI: ユーザーまたはホストグループからのメンバーの削除
- → をクリックして、左のサイドバーで または を選択してください。
- グループ名をクリックします。
- 削除するグループメンバーのタイプを選択します。ユーザーグループの Users、User Groups または External などです。

図13.4 ユーザーグループメンバーの削除
- 所定のメンバーの横にあるチェックボックスを選択します。
- をクリックします。
コマンドライン: ユーザーグループからのメンバーの削除
- オプション:
ipa group-showまたはipa hostgroup-showコマンドを使用して、削除するグループが含まれるグループを確定します。 - ユーザーグループメンバーを削除するには、
ipa group-remove-memberコマンドをしようします。ホストグループメンバーを削除するにはipa hostgroup-remove-memberコマンドを使用します。ユーザーグループメンバーを削除する場合は、以下のオプションを使用してメンバーを指定します。--usersを指定して IdM ユーザーを削除します。DOMAIN\user_nameまたはuser_name@domainの形式で、--externalを指定して IdM ドメイン外に存在するユーザーを削除します。--groupsを指定して IdM ユーザーグループを削除します。
ホストグループメンバーを削除する場合は、以下のオプションを使用してメンバーを指定します。--hostsを指定して IdM ホストを削除します。--groupsを指定して IdM ホストグループを削除します。
たとえば、group_name と呼ばれるグループから、user1、user2 および group1 を削除するには、以下を実行します。$ ipa group-remove-member group_name --users=user1 --users=user2 --groups=group1
13.4. ユーザープライベートグループの無効化
注記
13.4.1. ユーザープライベートグループなしでのユーザー作成
--noprivate オプションを ipa user-add コマンドに追加します。正常にコマンドが実行されるように、カスタムのプライベートグループを指定する必要があります。「ユーザープライベートグループを無効にしたユーザーの追加」を参照してください。
13.4.2. 全ユーザーに対してユーザープライベートグループを無効化する方法
- 管理者としてログインします。
$ kinit admin
- IdM は、Directory Server の Managed Entries Plug-in を使用してユーザープライベートグループを管理します。どのようなプラグインがあるかを表示するには以下を実行します。
$ ipa-managed-entries --list
- IdM によりユーザープライベートグループが作成されないようにするには、ユーザープライベートグループを管理するプラグインインスタンスを無効にします。
$ ipa-managed-entries -e "UPG Definition" disable Disabling Plugin
注記
UPG Definitionインスタンスを再度有効にするには、ipa-managed-entries -e "UPG Definition" enableコマンドを使用します。 - Directory Server を再起動して、新しい設定を読み込みます。
# systemctl restart dirsrv.target
13.4.3. ユーザープライベートグループを無効にしたユーザーの追加
- 新規ユーザーの追加時にはカスタムの GID を指定します。GID は、既存のユーザーグループと一致させる必要はありません。たとえば、コマンドラインからユーザーを追加する場合は、
ipa user-addコマンドに--gidオプションを追加します。 - GID がある既存のグループにユーザーを追加するには、automember ルールを使用します。「ユーザーおよびホストの自動グループメンバーシップの定義」を参照してください。
13.5. ユーザーおよびユーザーグループの検索属性の設定
ipa user-find keyword および ipa group-find keyword コマンドを使用して特定のキーワードのエントリーを検索するには、以下のように IdM は特定の属性のみを検索します。
- ユーザーの検索: 姓、名、ユーザー名 (ログイン ID)、役職、組織単位 (UO)、電話番号、UID、メールアドレス
- グループの検索: グループ名、説明
前提条件
Web UI: 検索属性の設定
- → を選択します。
- User Options エリアで、User search fields のユーザー検索属性を設定します。
- Group Options エリアで、Group search fields のグループ検索属性を選択します。
- ページ上部にある をクリックします。
コマンドライン: 検索属性の設定
ipa config-mod コマンドを実行します。
--usersearchは、ユーザーの検索属性の新規リストを定義します。--groupsearchは、グループの検索属性の新規リストを定義します。
$ ipa config-mod --usersearch={uid,givenname,sn,telephonenumber,ou,title}
$ ipa config-mod --groupsearch={cn,description}13.6. ユーザーおよびホストの自動グループメンバーシップの定義
13.6.1. IdM での自動グループメンバーシップの機能方法
13.6.1.1. 自動グループメンバーシップとは
- 従業員のマネージャー、場所またはその他の属性をもとに従業員のユーザーエントリーを複数のグループに分割することができます。
- クラス、場所、またはその他の属性をもとにホストを分割できます。
- 全ユーザーまたは全ホストを単一のグローバグループに追加できます。
13.6.1.2. 自動グループメンバーシップの利点
- グループメンバーシップの手動管理によるオーバーヘッドの削減
- 自動グループメンバーシップでは、管理者はユーザーとホストをグループに手動で割り当てる必要がありません。
- ユーザーおよびホスト管理での一貫性向上
- 自動グループメンバーシップでは、厳密に定義され、自動評価された基準をもとに、ユーザーおよびホストが割り当てられます。
- グループベースの設定管理の容易化
- 様々な設定がグループに定義されており、
sudoルール、automount、またはアクセス制御など、個別のグループメンバーに適用されます。自動グループメンバーを使用する場合には、ユーザーおよびホストは自動的に特定のグループに追加され、グループベースの設定の管理が簡素化されます。
13.6.1.3. Automember ルール
- 包含条件
- ユーザーまたはホストのエントリーが包含ルールを満たす場合には、グループに含まれます。
- 除外の条件
- ユーザーまたはホストのエントリーが除外の条件を満たす場合にはグループに追加 されません。
13.6.2. automember ルールの追加
- IdM web UI を使用する場合は「Web UI: Automember ルールの追加」を参照してください。
- コマンドラインを使用する場合は「コマンドライン: Automember ルールの追加」を参照してください。
- 今後作成されるエントリーはすべて、指定したグループに所属します。エントリーが複数の automember ルールで指定した条件を満たす場合には、該当するすべてのグループに追加されます。
- 既存のエントリーは、指定のグループのメンバーには追加されません。詳しい情報は、「automember ルールの既存のユーザーおよびホストへの適用」を参照してください。
Web UI: Automember ルールの追加
- → → または を選択します。
- をクリックします。
- Automember rule フィールで、ルールを適用するグループを選択します。 をクリックします。
- 包含および除外条件を 1 つ以上定義します。詳細は「Automember ルール」を参照してください。
- Inclusive または Exclusive セクションで をクリックします。
- Attribute フィールドで、必要な属性を選択します。
- Expression フィールドで、正規表現を定義します。
- をクリックします。
たとえば、以下の条件は、ユーザーログインの属性 (uid) のすべての値 (.*) を対象としています。
図13.5 Automember ルール条件の追加
コマンドライン: Automember ルールの追加
ipa automember-addコマンドを使用して、automember ルールを追加します。プロンプトが表示されたら、以下を指定します。- 対象のグループ名と一致する
Automember rule - ルールの対象がユーザーグループか、ホストグループかを指定する
Grouping Type。ユーザーグループを対象とするにはgroup、ホストグループを対象とする場合はhostgroupを入力してください。
たとえばuser_groupという名前のユーザーグループの automember ルールを追加するには以下を実行します。$ ipa automember-addAutomember Rule:user_groupGrouping Type:group-------------------------------- Added automember rule "user_group" -------------------------------- Automember Rule: user_group- 包含および除外条件を 1 つ以上定義します。詳細は「Automember ルール」を参照してください。
- 条件を追加するには
ipa automember-add-conditionコマンドを使用します。プロンプトが表示されたら、以下を指定します。- 対象のグループ名と一致する
Automember rule - フィルターを適用するエントリー属性を指定する
Attribute Key。たとえば、ユーザーのmanagerなどです。 - ルールの対象がユーザーグループか、ホストグループかを指定する
Grouping Type。ユーザーグループを対象とするにはgroup、ホストグループを対象とする場合はhostgroupを入力してください。 - 正規表現として 1 つまたは複数の条件を指定する
Inclusive regexおよびExclusive regex。条件を 1 つだけ指定する場合は、他の条件を指定するようにプロンプトが表示されたら、Enter を押してください。
たとえば、以下の条件は、ユーザーログインの属性 (uid) のすべての値 (.*) を対象としています。$ ipa automember-add-conditionAutomember Rule:user_groupAttribute Key:uidGrouping Type:group[Inclusive Regex]:.*[Exclusive Regex]: ---------------------------------- Added condition(s) to "user_group" ---------------------------------- Automember Rule: user_group Inclusive Regex: uid=.* ---------------------------- Number of conditions added 1 ---------------------------- - 条件を削除するには
ipa automember-remove-conditionコマンドを使用します。
例13.4 コマンドライン: 単一のグループに全エントリーを追加する Automember ルールの作成
cn または fqdn など、全ユーザーまたはホストエントリーが含む属性の包含条件を作成すると、今後作成されるユーザーまたはホストのすべてが単一のグループに追加されるようになります。
all_hosts当名前のホストグループなど、グループを作成します。「ユーザーまたはホストグループの追加および削除」を参照してください。- 以下のように、新規ホストグループの automember ルールを追加します。
$ ipa automember-addAutomember Rule:all_hostsGrouping Type:hostgroup------------------------------------- Added automember rule "all_hosts" ------------------------------------- Automember Rule: all_hosts - 全ホストを対象とする包含条件を追加します。以下の例では、包含条件は
fqdn属性に含まれるホストすべて (.*) を対象としています。$ ipa automember-add-conditionAutomember Rule:all_hostsAttribute Key:fqdnGrouping Type:hostgroup[Inclusive Regex]:.*[Exclusive Regex]: --------------------------------- Added condition(s) to "all_hosts" --------------------------------- Automember Rule: all_hosts Inclusive Regex: fqdn=.* ---------------------------- Number of conditions added 1 ----------------------------
all_hosts グループに所属します。
例13.5 コマンドライン: 同期済みの AD ユーザー用の Automember ルールの作成
ntUser オブジェクトクラスを共有します。objectclass 属性に ntUser が含まれる全ユーザーを対象とする automember の条件を作成すると、今後作成される同期済みの AD ユーザーは AD ユーザーの共通グループに追加されるようになります。
ad_usersなどの AD ユーザーのユーザーグループを作成します。「ユーザーまたはホストグループの追加および削除」を参照してください。- 以下のように、新規ユーザーグループの automember ルールを追加します。
$ ipa automember-addAutomember Rule:ad_usersGrouping Type:group------------------------------------- Added automember rule "ad_users" ------------------------------------- Automember Rule: ad_users - AD ユーザーを絞り込む包含条件を追加します。以下の例では、
objectclass属性にntUserの値が含まれる全ユーザーを対象とします。$ ipa automember-add-conditionAutomember Rule:ad_usersAttribute Key:objectclassGrouping Type:group[Inclusive Regex]:ntUser[Exclusive Regex]: ------------------------------------- Added condition(s) to "ad_users" ------------------------------------- Automember Rule: ad_users Inclusive Regex: objectclass=ntUser ---------------------------- Number of conditions added 1 ----------------------------
ad_users ユーザーグループに所属します。
13.6.3. automember ルールの既存のユーザーおよびホストへの適用
Web UI: 既存のエントリーの自動メンバーシップの再構築
- → または を選択します。
- → をクリックします。

図13.6 全ユーザーまたはホストの自動メンバーシップの再構築
- → または を選択して、必要なユーザーログインまたはホスト名をクリックします。
- → をクリックします。

図13.7 単一のユーザーまたはホストの自動メンバーシップの再構築
コマンドライン: 既存のエントリーの自動メンバーシップの再構築
ipa automember-rebuild --type=group コマンドを使用します。
$ ipa automember-rebuild --type=group
--------------------------------------------------------
Automember rebuild task finished. Processed (9) entries.
--------------------------------------------------------ipa automember-rebuild --type=hostgroup コマンドを使用します。
ipa automember-rebuild --users=user コマンドを使用します。
$ ipa automember-rebuild --users=user1 --users=user2 -------------------------------------------------------- Automember rebuild task finished. Processed (2) entries. --------------------------------------------------------
ipa automember-rebuild --hosts=example.com コマンドを使用します。
13.6.4. デフォルトの Automember グループ設定
ipa automember-default-group-setコマンドを使用して、デフォルトの automember グループを設定します。プロンプトが表示されたら、以下を指定します。- 対象となるグループ名を指定する
Default (fallback) Group - 対象がユーザーグループか、ホストグループかを指定する
Grouping Type。ユーザーグループを対象とするにはgroup、ホストグループを対象とする場合はhostgroupを入力してください。
以下に例を示します。$ ipa automember-default-group-setDefault (fallback) Group:default_user_groupGrouping Type:group--------------------------------------------------- Set default (fallback) group for automember "default_user_group" --------------------------------------------------- Default (fallback) Group: cn=default_user_group,cn=groups,cn=accounts,dc=example,dc=com- グループが正しく設定されていることを確認するには、
ipa automember-default-group-showコマンドを使用します。このコマンドでは、現在のデフォルト automember グループが表示されます。以下に例を示します。$ ipa automember-default-group-showGrouping Type:groupDefault (fallback) Group: cn=default_user_group,cn=groups,cn=accounts,dc=example,dc=com
ipa automember-default-group-remove コマンドを使用します。
第14章 一意の UID および GID 番号の割り当て
14.1. ID の範囲
次の ID 範囲があります。前者の番号を使い果たすと、後者の番号が使用されます。DNA Directory Server プラグインの詳細については、Red Hat Directory Server Deployment Guide を参照してください。
14.2. インストール中の ID 範囲の割り当て
ipa-server-install コマンドはデフォルトでランダムな現行 ID 範囲をインストール先に自動的に割り当てます。設定スクリプトがランダムで、合計 1 万 の範囲から 20 万 ID のある範囲を選択します。このようにランダムな範囲を選択することで、もし 2 つの別個の IdM ドメインを将来マージした場合でも、ID が競合する可能性を大幅に抑えられます。
ipa-server-install コマンドで以下の 2 つのオプションを使用すると、手動で現行 ID 範囲を定義することができます。
--idstartは、UID および GID 番号の最初の値を提供します。デフォルトでは、この値はランダムで選択されます。--idmaxは、UID および GID 番号の最大値を提供します。デフォルトでは、この値は--idstartの最初の値に 199,999 を加えたものになります。
注記
14.3. 現在割り当てられている ID 範囲の表示
ipa-replica-manage dnarange-showは、全サーバーに設定されている現行 ID 範囲、またはサーバーを指定した場合はそのサーバーの現行 ID 範囲を表示します。# ipa-replica-manage dnarange-show masterA.example.com: 1001-1500 masterB.example.com: 1501-2000 masterC.example.com: No range set # ipa-replica-manage dnarange-show masterA.example.com masterA.example.com: 1001-1500
ipa-replica-manage dnanextrange-showは、全サーバーに設定されている次の ID 範囲、またはサーバーを指定した場合はそのサーバーの現行 ID 範囲を表示します。# ipa-replica-manage dnanextrange-show masterA.example.com: 1001-1500 masterB.example.com: No on-deck range set masterC.example.com: No on-deck range set # ipa-replica-manage dnanextrange-show masterA.example.com masterA.example.com: 1001-1500
14.4. レプリカ削除後の ID 範囲の自動拡張
ipa-replica-manage del コマンドを使用すると、そのレプリカに割り当てられていた ID 範囲を取得して、他の利用可能な IdM レプリカに次の範囲として追加することができます。こうすることで、他のレプリカに ID 範囲が継続して利用可能になります。
ipa-replica-manage dnarange-show と ipa-replica-manage dnanextrange-show コマンドを使用すると、他のサーバーに設定されている ID 範囲を確認することができます。これらのコマンドについては、「現在割り当てられている ID 範囲の表示」 で説明しています。
14.5. 手動での ID 範囲の拡張および新規 ID 範囲の割り当て
- 割り当て ID 範囲を使い果たした場合
- レプリカが割り当てられた ID 範囲を使い切ってしまい、他のレプリカの ID 範囲に利用可能な ID がないと、新たな ID のリクエストは失敗します。このような場合には、元のレプリカに割り当てられた ID 範囲を拡張します。これを実行するには、既存の ID 範囲を分割したり、サーバーに設定されていた元の ID 範囲を超える拡張を行ったりします。また、新規の ID 範囲を割り当てることもできます。
注記
新規の ID 範囲を割り当てる場合、サーバーまたはレプリカ上の既存エントリーの UID はそのまま変わりません。現行 ID の範囲を変更しても、IdM は過去に割り当てられた範囲のレコードを維持しているため、これが問題になることはありません。 - レプリカが機能停止した場合
- レプリカが停止して削除する必要がある場合には、ID 範囲は自動的には取得されません。つまり、そのレプリカに割り当てられていた ID 範囲は使用できなくなります。この ID 範囲を回復させて他のレプリカで使用できるようにします。機能停止してしまったサーバーに属していた ID 範囲を回復させて別のサーバーにこれを割り当てるには、まず
ipa-replica-manage dnarange-showコマンドを使用して ID 範囲の値を確認します。このコマンドについては、「現在割り当てられている ID 範囲の表示」 で説明しています。次に、その ID 範囲をサーバーに手動で割り当てます。また、UID や GID の重複を避けるために、回復させた範囲からの ID の値がこれまでにユーザーやグループに割り当てられていなかったことを確認します。これは、既存のユーザーおよびグループの UID と GID をチェックすることでわかります。
ipa-replica-manage dnarange-setを使用すると、指定されたサーバーの現行 ID 範囲を定義できます。# ipa-replica-manage dnarange-set masterA.example.com 1250-1499
ipa-replica-manage dnanextrange-setを使用すると、指定されたサーバーの次の ID 範囲を定義できます。# ipa-replica-manage dnanextrange-set masterB.example.com 1001-5000
重要
0を含む ID 範囲は設定しないでください。SSSD サービスは 0 ID の値を処理しません。
ipa idrange-find コマンドを使用することで実行できます。ipa idrange-find -h コマンドを実行すると ipa idrange-find コマンドのヘルプが表示されます。
14.6. ID の値が一意であることを確認する
- 自動での ID 割り当て
- ユーザーやグループが対話形式で作成される、または手動で指定した ID 番号なしで作成される場合は、サーバーが次に利用可能な ID 番号を ID 範囲からユーザーアカウントに割り当てます。こうすることで、UID や GID は常に一意のものになります。
- 手動での ID 割り当て
- ID をユーザーまたはグループエントリーに手動で割り当てる場合には、サーバーは指定された UID または GID が一意のものであることを検証しません。他のエントリーで使用されている値を選択しても、サーバーは競合していることを警告しません。
ipa user-find --all コマンドを実行すると、両方のエントリーが返されます。
uidNumber および gidNumber という別の属性で設定されるため、この状況では競合は発生しません。
注記
14.7. 変更された UID および GID 番号の修復
sss_cache ユーティリティーを使用します。
[root@server ~]# sss_cache -u user
第15章 ユーザーおよびグループスキーマ
表15.1 デフォルトの Identity Management ユーザーオブジェクトクラス
| オブジェクトクラス | 詳細 |
|---|---|
|
ipaobject
ipasshuser
| IdM オブジェクトクラス |
|
person
organizationalperson
inetorgperson
inetuser
posixAccount
| 人物のオブジェクトクラス |
|
krbprincipalaux
krbticketpolicyaux
| Kerberos のオブジェクトクラス |
| mepOriginEntry | Managed エントリー (テンプレート) のオブジェクトクラス |
表15.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 | --uid | デフォルト |
| Group ID number | --gidnumber | デフォルト |
| Street address | --street | オプション |
| City | --city | オプション |
| State/Province | --state | オプション |
| Zip code | --postalcode | オプション |
| Telephone number | --phone | オプション |
| Mobile telephone number | --mobile | オプション |
| Pager number | --pager | オプション |
| Fax number | --fax | オプション |
| Organizational unit | --orgunit | オプション |
| Job title | --title | オプション |
| Manager | --manager | オプション |
| Car license | --carlicense | オプション |
--noprivate | オプション | |
| SSH Keys | --sshpubkey | オプション |
| Additional attributes | --addattr | オプション |
| Department Number | --departmentnumber | オプション |
| Employee Number | --employeenumber | オプション |
| Employee Type | --employeetype | オプション |
| Preferred Language | --preferredlanguage | オプション |
[a]
必須の属性は、すべてのエントリーで設定する必要があります。オプションの属性は設定が可能で、デフォルトの属性は特定の値を提供しない場合は事前設定の値で自動的に追加されます。
[b]
スクリプトは、引数の値を受け付けずに、新たなパスワードを要求します。
| ||
15.1. デフォルトのユーザーおよびグループスキーマの変更
- すべてのオブジェクトクラスとそれらの指定された属性を LDAP サーバーが認識していること。
- エントリーに設定されたデフォルトの属性はすべて、設定済みのオブジェクトクラスにサポートされていること。
ipaobject オブジェクトクラスが必要です。しかし、ユーザーもしくはグループスキーマが変更されると、このオブジェクトクラスが含まれているかどうかをサーバーは検証しません。このオブジェクトクラスが誤って削除されると、それ以降のエントリー追加操作は失敗することになります。
15.2. カスタムのオブジェクトクラスを新規ユーザーエントリーに適用する
15.2.1. Web UI での操作
- Identity Management が使用する 389 Directory Server インスタンスにカスタムスキーマ要素すべてを追加します。スキーマ要素の追加については、the schema chapter of the Directory Server Administrator's Guide で説明しています。
- IPA Server タブを開きます。
- Configuration サブタブを選択します。
- User Options エリアまでスクロールします。

図15.1 サーバー設定でのユーザーオプション
- ユーザーエリアの下部で Add をクリックして別のオブジェクトクラスの新規フィールドを追加します。
重要
設定を更新する際は、常に既存のデフォルトオブジェクトクラスを含めてください。これらを含めないと、現行設定は上書きされます。Identity Management で必須のオブジェクトクラスが含まれないと、これ以降にエントリーの追加を試みる際にオブジェクトクラス違反で失敗することになります。
図15.2 デフォルトのユーザーオブジェクトクラスの変更
- 変更が完了したら、Configuration ページ上部の Save をクリックします。
15.2.2. コマンドラインでの操作
- Identity Management が使用する 389 Directory Server インスタンスにカスタムスキーマ要素すべてを追加します。スキーマ要素の追加については、the schema chapter of the Directory Server Administrator's Guide で説明しています。
- エントリーに追加するオブジェクトクラス一覧に新規オブジェクトクラスを追加します。ユーザーのオブジェクトクラスのオプションは、
--userobjectclassesです。重要
設定を更新する際は、常に既存のデフォルトオブジェクトクラスを含めてください。これらを含めないと、現行設定は上書きされます。Identity Management で必須のオブジェクトクラスが含まれないと、これ以降にエントリーの追加を試みる際にオブジェクトクラス違反で失敗することになります。オブジェクトクラス一覧には、すべてのオブジェクトを含める必要があります。config-modコマンドで渡す情報は、それ以前の値を上書きします。これを行うには、--userobjectclasses引数で各オブジェクトクラスを指定するか、{attr1,attr2,attr3} のように中括弧内にすべてのオブジェクトクラスをコンマ区切りの一覧で記載します (ただし、スペースはなし)。リストが長くなる場合は特に、複数のオプションよりも中括弧を使用する方が容易です。例を示します。[bjensen@server ~]$ ipa config-mod
--userobjectclasses={top,person,organizationalperson,inetorgperson,inetuser,posixaccount,krbprincipalaux,krbticketpolicyaux,ipaobject,ipasshuser,employeeinfo}
注記
brace expansion 機能を有効にする必要があります。これには、以下のように set コマンドを使用します。
# set -o braceexpand
15.3. カスタムのオブジェクトクラスを新規グループエントリーに適用する
15.3.1. Web UI での操作
- Identity Management が使用する 389 Directory Server インスタンスにカスタムスキーマ要素すべてを追加します。スキーマ要素の追加については、the schema chapter of the Directory Server Administrator's Guide で説明しています。
- IPA Server タブを開きます。
- Configuration サブタブを選択します。
- Group Options エリアまでスクロールします。

図15.3 サーバー設定でのグループオプション
- Add をクリックして別のオブジェクトクラスの新規フィールドを追加します。
重要
設定を更新する際は、常に既存のデフォルトオブジェクトクラスを含めてください。これらを含めないと、現行設定は上書きされます。Identity Management で必須のオブジェクトクラスが含まれないと、これ以降にエントリーの追加を試みる際にオブジェクトクラス違反で失敗することになります。 - 変更が完了したら、Configuration ページ上部の Save をクリックします。
15.3.2. コマンドラインでの操作
- Identity Management が使用する 389 Directory Server インスタンスにカスタムスキーマ要素すべてを追加します。スキーマ要素の追加については、the schema chapter of the Directory Server Administrator's Guide で説明しています。
- エントリーに追加するオブジェクトクラス一覧に新規オブジェクトクラスを追加します。グループのオブジェクトクラスのオプションは、
--groupobjectclassesです。重要
設定を更新する際は、常に既存のデフォルトオブジェクトクラスを含めてください。これらを含めないと、現行設定は上書きされます。Identity Management で必須のオブジェクトクラスが含まれないと、これ以降にエントリーの追加を試みる際にオブジェクトクラス違反で失敗することになります。オブジェクトクラス一覧には、すべてのオブジェクトを含める必要があります。config-modコマンドで渡す情報は、それ以前の値を上書きします。これを行うには、--groupobjectclasses引数で各オブジェクトクラスを指定するか、{attr1,attr2,attr3} のように中括弧内にすべてのオブジェクトクラスをコンマ区切りの一覧で記載します (ただし、スペースはなし)。リストが長くなる場合は特に、複数のオプションよりも中括弧を使用する方が容易です。例を示します。[bjensen@server ~]$ ipa config-mod
--groupobjectclasses={top,groupofnames,nestedgroup,ipausergroup,ipaobject,ipasshuser,employeegroup}
15.4. デフォルトのユーザーおよびグループ属性の指定
cn=ipaconfig,cn=etc,dc=example,dc=com に含まれています。
ipa config-mod コマンドで変更することが可能です。
表15.3 デフォルトのユーザーパラメーター
| フィールド | コマンドラインオプション | 説明 |
|---|---|---|
| Maximum user name length | --maxusername | ユーザー名の最大文字数を設定します。デフォルト値は 32 です。 |
| Root for home directories | --homedirectory | ユーザーのホームディレクトリーに使用するデフォルトのディレクトリーを設定します。デフォルト値は、/home です。 |
| Default shell | --defaultshell | ユーザーに使用するデフォルトのシェルを設定します。デフォルト値は、/bin/sh です。 |
| Default user group | --defaultgroup | 新規作成のアカウントを追加するデフォルトグループを設定します。デフォルト値は ipausers で、これは IdM サーバーのインストールプロセスで自動的に作成されます。 |
| Default e-mail domain | --emaildomain | 新規アカウントに基づいて電子メールアドレスを作成するために使用する電子メールドメインを設定します。デフォルトは IdM サーバードメインです。 |
| Search time limit | --searchtimelimit | サーバー検索結果を返すまでに費やす最長時間を秒単位で設定します。 |
| Search size limit | --searchrecordslimit | 返される検索結果の最大数を設定します。 |
| User search fields | --usersearch | 検索文字列として使用可能なユーザーエントリー内のフィールドを設定します。記載される属性にはインデックスがその属性のために維持されるので、多く設定しすぎるとサーバーのパフォーマンスに影響が出る場合があります。 |
| Group search fields | --groupsearch | 検索文字列として使用可能なグループエントリー内のフィールドを設定します。 |
| Certificate subject base | クライアント証明書用にサブジェクト DN を作成する際に使用するベース DN を設定します。これはサーバーのセットアップ時に設定されます。 | |
| Default user object classes | --userobjectclasses | IdM ユーザーアカウント作成に使用されるオブジェクトクラスを定義します。これは、複数回使用することができます。このリストはコマンド実行時に上書きされるので、オブジェクトクラスの完全一覧を提供する必要があります。 |
| Default group object classes | --groupobjectclasses | IdM グループアカウント作成に使用されるオブジェクトクラスを定義します。これは、複数回使用することができます。このリストはコマンド実行時に上書きされるので、オブジェクトクラスの完全一覧を提供する必要があります。 |
| Password expiration notification | --pwdexpnotify | パスワードの有効期限が切れる何日前にサーバーが通知を送信するかを設定します |
| Password plug-in features | ユーザーが使用可能なパスワードの形式を設定します。 |
15.4.1. Web UI で属性を表示する
- IPA Server タブを開きます。
- Configuration サブタブを選択します。
- 設定エントリーは、全検索の制限、ユーザーテンプレート、およびグループテンプレートの 3 つのセクションで表示されます。

図15.4 検索での制限設定

図15.5 ユーザー属性

図15.6 グループ属性
15.4.2. コマンドラインで属性を表示する
config-show コマンドを使うと、すべての新規ユーザーアカウントに適用される現行設定が表示されます。デフォルトでは、最も一般的な属性のみが表示されます。--all オプションを使うと、完全な設定が表示されます。
[bjensen@server ~]$ kinit admin [bjensen@server ~]$ ipa config-show --all dn: cn=ipaConfig,cn=etc,dc=example,dc=com Maximum username length: 32 Home directory base: /home Default shell: /bin/sh Default users group: ipausers Default e-mail domain: example.com Search time limit: 2 Search size limit: 100 User search fields: uid,givenname,sn,telephonenumber,ou,title Group search fields: cn,description Enable migration mode: FALSE Certificate Subject base: O=EXAMPLE.COM Default group objectclasses: top, groupofnames, nestedgroup, ipausergroup, ipaobject Default user objectclasses: top, person, organizationalperson, inetorgperson, inetuser, posixaccount, krbprincipalaux, krbticketpolicyaux, ipaobject, ipasshuser Password Expiration Notification (days): 4 Password plugin features: AllowNThash SELinux user map order: guest_u:s0$xguest_u:s0$user_u:s0$staff_u:s0-s0:c0.c1023$unconfined_u:s0-s0:c0.c1023 Default SELinux user: unconfined_u:s0-s0:c0.c1023 Default PAC types: MS-PAC, nfs:NONE cn: ipaConfig objectclass: nsContainer, top, ipaGuiConfig, ipaConfigObject
第16章 サービスの管理
- DNS
- Kerberos
- 証明書管理
16.1. サービスエントリーおよび Keytab の追加と編集
/etc/httpd/conf/ipa.keytab に保存します。
注記
ipa.keytab に保存されその keytab ファイルが削除された場合、元のキーも削除されてしまうので、IdM Web UI は機能しなくなります。
ipa-getkeytab を使用する場合は、/etc/krb5.keytab を避けてください。このファイルにはサービス固有の keytab を含めるべきではありません。各サービスは keytab を特定の場所に保存し、そのサービスのみが keytab にアクセスできるようにアクセス権限 (および場合によっては SELinux ルール) を設定します。
16.1.1. Web UI でのサービスと Keytab の追加
- Identity タブを開き、Services サブタブを選択します。
- サービス一覧の上部にある ボタンをクリックします。
- ドロップダウンメニューからサービスタイプを選択し、名前を付けます。
- サービスが実行される IdM ホストのホスト名を選択します。ホスト名を使用して、完全なサービスプリンシパル名を構成します。
- ボタンをクリックして、新しいサービスプリンシパルを保存します。
ipa-getkeytabコマンドを使用して、サービスプリンシパルの新規 keytab を生成、割り当てます。[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引数では、keytab に含める暗号タイプの一覧を提供します。これはデフォルトの暗号化タイプに優先します。エントリーのリストは、同一コマンドでオプションを複数回使用するか、--option={val1,val2,val3} のように中括弧内にオプションをコンマ区切りの一覧で記載します。
警告
新たなキーを作成すると、指定されたプリンシパルの秘密がリセットされます。つまり、そのプリンシパルの他の keytab すべてが無効になります。
16.1.2. コマンドラインでのサービスと Keytab の追加
- サービスプリンシパルを作成します。サービスは、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
ipa-getkeytabコマンドでサービス keytab ファイルを作成します。このコマンドは、IdM ドメイン内のクライアント上で実行します。(実際には、IdM サーバーまたはクライアント上でコマンドを実行して、キーを適切なマシンにコピーすることが可能です。ただし、サービスが作成されるマシン上でこのコマンドを実行することが最もシンプルな方法です。)このコマンドでは、Kerberos サービスプリンシパル (-p)、IdM サーバー名 (-s)、書き込みファイル (-k)、および暗号化方法 (-e) が必要になります。keytab をサービスの適切なディレクトリーにコピーしてください。例を示します。# 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引数では、keytab に含める暗号タイプをコンマ区切りのリストで提供します。これはデフォルトの暗号化タイプに優先します。エントリーのリストは、同一コマンドでオプションを複数回使用するか、--option={val1,val2,val3} のように中括弧内にオプションをコンマ区切りの一覧で記載します。
警告
ipa-getkeytabコマンドは、指定されたプリンシパルの秘密をリセットします。つまり、そのプリンシパルの他の keytab すべてが無効になります。
16.2. クラスタサービスの設定
- クラスタ内の全ホストを IdM ドメインに登録します。
- サービスプリンシパルを作成し、必要な keytab を生成します。
/etc/krb5.keytabにあるホスト keytab を含む、ホスト上のサービスに設定されたすべての keytab を収集します。ktutilコマンドを使って、全 keytab ファイルのコンテンツを含む単一の keytab ファイルを作成します。- 各ファイルで
rktコマンドを使ってそのファイルからキーを読み取ります。 - 新規 keytab ファイルに読み込まれたキーすべてを書き込むには、
wktコマンドを使用します。
- 各ホスト上の keytab ファイルを新たに作成した結合 keytab ファイルで置き換えます。
- この時点で、このクラスター内の各ホストは他のホストに偽装することができます。
- 失敗したサービスを引き継ぐ際にホスト名をリセットしないクラスターメンバーに対応するために、追加の設定が必要になるサービスが複数あります。
sshdでは、/etc/ssh/sshd_config内でGSSAPIStrictAcceptorCheck noと設定します。mod_auth_kerbでは、/etc/httpd/conf.d/auth_kerb.conf内でKrbServiceName Anyと設定します。
注記
16.3. 複数サービスでの同一サービスプリンシパルの使用
ipa-getkeytabコマンドでサービスプリンシパルを取得します。# ipa-getkeytab -s kdc.example.com -p HTTP/server.example.com -k /etc/httpd/conf/krb5.keytab -e aes256-cts
- 複数サーバーまたはサービスに同一ファイルを使用するよう指示するか、必要に応じてそのファイルを個別サーバーにコピーします。
16.4. 複数のサーバー向けの既存の keytab 取得
adminユーザーとして認証を行います。[root@ipaserver ~]# kinit admin
- このホスト名を共有する全 IP アドレスに対して、共通の正引き DNS レコードを追加します。
[root@ipaserver ~]# ipa dnsrecord-add idm.example.com cluster --a-rec={192.0.2.40,192.0.2.41} Record name: cluster A record: 192.0.2.40, 192.0.2.41 - 共通の DNS 名に対して新規ホストエントリーオブジェクトを作成します。
[root@ipaserver ~]# ipa host-add cluster.idm.example.com ------------------------------------ Added host "cluster.idm.example.com" ------------------------------------ Host name: cluster.idm.example.com Principal name: host/cluster.idm.example.com@IDM.EXAMPLE.COM Password: False Keytab: False Managed by: cluster.idm.example.com
- ホストのサービスプリンシパルを追加します。
[root@ipaserver ~]# ipa service-add HTTP/cluster.idm.example.com ------------------------------------------------------------ Added service "HTTP/cluster.idm.example.com@IDM.EXAMPLE.COM" ------------------------------------------------------------ Principal: HTTP/cluster.idm.example.com@IDM.EXAMPLE.COM Managed by: cluster.idm.example.com
- IdM から keytab を取得できるようにサービスにホストを追加します。
[root@ipaserver ~]# ipa service-allow-retrieve-keytab HTTP/cluster.idm.example.com --hosts={node01.idm.example.com,node02.idm.example.com} Principal: HTTP/cluster.idm.example.com@IDM.EXAMPLE.COM Managed by: cluster.idm.example.com Hosts allowed to retrieve keytab: node01.idm.example.com, node02.idm.example.com ------------------------- Number of members added 2 ------------------------- - 新規 keytab 作成パーミッションをホスト 1 台に割り当てます。
[root@ipaserver ~]# ipa service-allow-create-keytab HTTP/cluster.idm.example.com --hosts=node01.idm.example.com Principal: HTTP/cluster.idm.example.com@IDM.EXAMPLE.COM Managed by: cluster.idm.example.com Hosts allowed to retrieve keytab: node01.idm.example.com, node02.idm.example.com Hosts allowed to create keytab: node01.idm.example.com ------------------------- Number of members added 1 -------------------------
- ホストの Kerberos keytab で認証を行います。
# kinit -kt /etc/krb5.keytab
- 適切なパーミッションを割り当てたクライアントで、新規 keytab を生成して、ファイルに保存します。
[root@node01 ~]# ipa-getkeytab -s ipaserver.idm.example.com -p HTTP/cluster.idm.example.com -k /tmp/client.keytab
- このコマンドに
-rオプションを追加して、IdM サーバーから既存の keytab を取得します。[root@node02 ~]# ipa-getkeytab -r -s ipaserver.idm.example.com -p HTTP/cluster.idm.example.com -k /tmp/client.keytab
警告
-rオプションを省略すると、新しい keytab が生成される点に注意してください。これにより、このサービスプリンシパル用に以前に取得した keytab はすべて無効になります。
16.5. サービスエントリーの無効化および再有効化
16.5.1. サービスエントリーの無効化
service-disable コマンドを使用することで実行できます。
[jsmith@ipaserver ~]$ kinit admin [jsmith@ipaserver ~]$ ipa service-disable HTTP/server.example.com
重要
16.5.2. サービスの再有効化
ipa-getkeytab コマンドを使用するだけです。-s オプションはどの IdM サーバーに keytab を要求するかを設定し、-p はプリンシパル名を提示し、-k では keytab を保存するファイルを提供します。
[root@ipaserver ~]# ipa-getkeytab -s ipaserver.example.com -p HTTP/server.example.com -k /etc/httpd/conf/krb5.keytab -e aes256-cts
第17章 ユーザーアクセスのホストおよびサービスへの委任
managedby エントリーがあり、これにホストやサービスが管理可能なものが記載されています。デフォルトでは、ホストはホスト自体とそのサービスすべてを管理できます。また、適切な委任更新や、適切な managedby エントリーの提供により、ホストが他のホストや他のホスト上のサービスを管理可能とすることもできます。

図17.1 ホストおよびサービスの委任
注記
managedBy エントリーで別のホストに権限が委任されている場合に、そのホスト上の全サービスの管理を委任されたわけではありません。委任は個別に行われる必要があります。
17.1. サービス管理の委任
service-add-host コマンドを使用します。サービスの委任は、プリンシパルの特定と制御を行うホストの特定という 2 つの部分で構成されます。
# ipa service-add-host principal --hosts=hostnames
[root@server ~]# ipa service-add-host HTTP/web.example.com --hosts=client1.example.com
[root@server ~]# 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 コマンドを使ってサービスエントリーを作成して証明書情報を読み込みます。
[root@server ~]# 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 Serial number: 1005
ipa cert-request の使用に関する詳しい情報は、「ユーザー、ホスト、またはサービス向けの新規証明書のリクエスト」を参照してください。
17.2. ホスト管理の委任
host-add-managedby コマンドを使用します。これで managedby エントリーが作成されます。managedby エントリーが作成されると、ホストは権限を委任された別のホストの keytab を取得することができます。
- 管理者ユーザーとしてログインします。
[root@server ~]# kinit admin
managedbyエントリーを追加します。たとえば、このコマンドでは、client2 から client1 へ 権限を委任します。[root@server ~]# ipa host-add-managedby client2.example.com --hosts=client1.example.com
- ホスト
client1としてチケットを取得し、client2の keytab を取得します。[root@server ~]# kinit -kt /etc/krb5.keytab host/`hostname` [root@server ~]# ipa-getkeytab -s `hostname` -k /tmp/client2.keytab -p host/client2.example.com Keytab successfully retrieved and stored in: /tmp/client2.keytab
17.3. Web UI を使ったホストまたはサービス管理の委任
- Identity タブを開き、Hosts または Services サブタブを選択します。
- 委任管理を付与する先となるホストもしくはサービス名をクリックします。
- ホスト/サービスエントリーの右端にある Hosts サブタブをクリックします。このタブでは、選択したホスト/サービスを 管理できる ホストが表示されます。

図17.2 ホストのサブタブ
- 一覧上部にある Add をクリックします。
- ホスト/サービスの管理を委任するホスト名の横にあるチェックボックスを選択し、右矢印 をクリックして、そのホスト名を選択ボックスに移動します。

図17.3 ホスト/サービスの委任管理
- をクリックして選択ボックスを閉じ、委任設定を保存します。
17.4. 委任サービスへのアクセス
host で置き換えます。
kinit で -k オプションを使って keytab を読み込み、-t オプションで keytab を指定します。
[root@server ~]# kinit -kt /etc/krb5.keytab host/ipa.example.com@EXAMPLE.COM
[root@server ~]# kinit -kt /etc/httpd/conf/krb5.keytab HTTP/ipa.example.com@EXAMPLE.COM
第18章 ID ビュー
- 環境ごとに異なる属性値を定義する。詳細は 「ホストごとにユーザーアカウントで異なる属性値を定義する」 を参照してください。
- 以前に生成された属性値を異なる値で置き換える。
重要
SSSD パフォーマンスへのマイナス影響の可能性
- ID ビューを使用すると、グループ名が上書きされた場合、SSSD は返されたグループメンバー名リストの各メンバーをチェックする必要があります。
- ID ビューを使用しないと、SSSD はグループオブジェクトのメンバー属性からユーザー名を収集するだけで済みます。
その他のリソース
18.1. ID ビューで上書き可能な属性
- ユーザー属性
- ログイン名 (
uid) - GECOS エントリー (
gecos) - UID 番号 (
uidNumber) - GID 番号 (
gidNumber) - ログインシェル (
loginShell) - ホームディレクトリー (
homeDirectory) - SSH 公開キー (
ipaSshPubkey) - 証明書 (
userCertificate)
- グループ属性
- グループ名 (
cn) - グループ GID 番号 (
gidNumber)
18.2. ID ビューコマンドのヘルプ
$ ipa help idviews
--help オプションを加えて実行します。
$ ipa idview-add --help
18.3. ホストごとにユーザーアカウントで異なる属性値を定義する
host1.example.com という名前のクライアントホスト用に ID ビューを作成する方法について説明します。他のホストにある属性値も上書きする場合には、各ホストごとに 1 つずつ、複数の ID ビューを作成する手順を使用してください。
userは、属性を上書きするユーザーアカウントになります。host1.example.comは、ID ビューを適用するホストになります。
重要
18.3.1. Web UI: 特定ホスト向けの属性値の上書き
admin など必要な権限のあるユーザーとして IdM web UI にログインします。
新規 ID ビューの作成
- Identity タブで ID Views サブタブを選択します。
- をクリックして ID ビューをの名前を記入します。

図18.1 ID ビューの追加
- をクリックして確定します。

図18.2 ID ビュー一覧
ユーザー上書きを ID ビューに追加する
- ID ビュー一覧で、ID ビューの名前をクリックします。

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

図18.4 上書き一覧
上書きする属性の指定
- 属性値を変更する上書きをクリックします。

図18.5 上書きの編集
- 新しい属性値を定義します。たとえば、ユーザーアカウントで使用する SSH 公開キーを上書きするには、以下を実行します。
- をクリックします。

図18.6 SSH 公開キーの追加
- 公開キーに貼り付けます。
注記
IdM へのSSH キーの追加に関する詳細は、「ユーザーの公開 SSH キーの管理」 を参照してください。 - をクリックして上書きを更新します。
ID ビューの特定ホストへの適用
- ID ビュー一覧で、ID ビューの名前をクリックします。

図18.7 ID ビューの編集
- Hosts タブで をクリックします。
host1.example.comホストを選択して、Prospective コラムに移動します。- をクリックします。

図18.8 ID ビューが適用されるホスト一覧
18.3.2. コマンドライン: 特定ホスト向けの属性値の上書き
$ kinit admin
- 新規 ID ビューを作成します。たとえば、
example_for_host1という名前の ID ビューを作成するには、以下を実行します。$ ipa idview-add example_for_host1 --------------------------- Added ID View "example_for_host1" --------------------------- ID View Name: example_for_host1
- ユーザー上書きを
example_for_host1ID ビューに追加します。ipa idoverrideuser-addコマンドでは、ID ビューの名前と上書きするユーザーが必要になります。- 新規の属性値を指定するには、対応するコマンドラインオプションも追加します。利用可能なオプション一覧については、
ipa idoverrideuser-add --helpを実行すると確認できます。たとえば、SSH 公開キーの値を上書きするには、--sshpubkeyオプションを使用します。$ ipa idoverrideuser-add example_for_host1 user --sshpubkey="ssh-rsa AAAAB3NzaC1yrRqFE...gWRL71/miPIZ user@example.com" ----------------------------- Added User ID override "user" ----------------------------- Anchor to override: user SSH public key: ssh-rsa AAAB3NzaC1yrRqFE...gWRL71/miPIZ user@example.com注記
IdM へのSSH キーの追加に関する詳細は、「ユーザーの公開 SSH キーの管理」 を参照してください。 ipa idoverrideuser-add --certificateコマンドは、指定した ID ビュー内のアカウントの既存証明書すべてを置き換えます。新たな証明書を追加するには、代わりにipa idoverrideuser-add-certコマンドを使用します。$ ipa idoverrideuser-add-cert example_for_host1 user --certificate="MIIEATCC..."
ipa idoverrideuser-modコマンドを使用すると、既存のユーザー上書きに新たな属性値を指定することもできます。
example_for_host1をhost1.example.comホストに適用します。$ ipa idview-apply example_for_host1 --hosts=host1.example.com ----------------------------- Applied ID View "example_for_host1" ----------------------------- hosts: host1.example.com --------------------------------------------- Number of hosts the ID View was applied to: 1 ---------------------------------------------
注記
ipa idview-applyコマンドは、--hostgroupsオプションも受け取ります。このオプションは、指定されたホストグループに属するホストに ID ビューを適用しますが、ID ビューをホストグループ自体に関連付けることはしません。代わりに--hostgroupsオプションは指定されたホストグループのメンバーを拡張し、--hostsオプションを個別にメンバーに対して適用します。
第19章 IdM ユーザーのアクセス制御の定義
第20章 Kerberos フラグとプリンシパルエイリアスの管理
20.1. サービスおよびホスト向けの Kerberos フラグ
OK_AS_DELEGATE- 委任用に信頼する Kerberos チケットを指定するには、このフラグを使用します。AD クライアントは、Kerberos チケット上の
OK_AS_DELEGATEフラグをチェックして、ユーザー認証情報を特別のサーバーに転送または委任できるかどうかを判断します。AD はOK_AS_DELEGATEセットのあるサービスまたはホストにのみ、TGT を転送します。このフラグがあると、SSSD は AD ユーザー TGT を IdM クライアントマシン上のデフォルトの Kerberos 認証情報キャッシュに追加することができます。 REQUIRES_PRE_AUTH- 事前に認証されたチケットのみがプリンシパルに認証可能と指定するには、このフラグを使用します。
REQUIRES_PRE_AUTHフラグが設定されている場合は、KDC は新たな認証を必要します。TGT が事前に認証されている場合にのみ、KDC はREQUIRES_PRE_AUTHのあるプリンシパル用の TGT を発行します。REQUIRES_PRE_AUTHを使うと、選択したサービスまたはホストの事前認証を無効にすることができます。こうすると KDC の負荷は下がりますが、長期のキーへのブルートフォース攻撃が成功する確率が少し高くなります。
20.1.1. Web UI で Kerberos フラグを設定する
OK_AS_DELEGATE フラグのみを追加できます。
- Identity メインタブから Services サブタブを選択します。

図20.1 サービス一覧
- フラグを追加するサービスをクリックします。
- Trusted for delegation オプションにチェックを入れます。

図20.2 OK_AS_DELEGATE フラグの追加
20.1.2. コマンドライン で Kerberos フラグを設定する
ipa service-mod コマンドに以下のいずれかのオプションを追加します。
OK_AS_DELEGATEには--ok-as-delegateを追加REQUIRES_PRE_AUTHには--requires-pre-authを追加
1 に設定します。たとえば、OK_AS_DELEGATE フラグを test/ipa.example.com@EXAMPLE.COM プリンシパルに追加するには、以下を実行します。
$ ipa service-mod test/ipa.example.com@EXAMPLE.COM --ok-as-delegate=10 に設定します。たとえば、REQUIRES_PRE_AUTH フラグを test/ipa.example.com@EXAMPLE.COM プリンシパルで無効にするには、以下を実行します。
$ ipa service-mod test/ipa.example.com@EXAMPLE.COM --requires-pre-auth=0OK_AS_DELEGATE が設定されているかどうかを確認するには、kvno ユーティリティーを実行してから、klist -f コマンドを実行します。OK_AS_DELEGATE は、klist -f の出力の O の文字で表されます。
$ kvno test/ipa.example.com@EXAMPLE.COM
$ klist -f
Ticket cache: KEYRING:persistent:0:0
Default principal: admin@EXAMPLE.COM
Valid starting Expires Service principal
02/19/2014 09:59:02 02/20/2014 08:21:33 test/ipa/example.com@EXAMPLE.COM
Flags: FATOkadmin.local ユーティリティーを使用します。現行フラグは、以下のように kadmin.localの出力の Attributes の行に表示されます。
# kadmin.local
kadmin.local: getprinc test/ipa.example.com
Principal: test/ipa.example.com@EXAMPLE.COM
Expiration date: [never]
Last password change: Mon Sep 16 15:44:21 EDT 2013
Password expiration date: [none]
Maximum ticket life: 1 day 00:00:00
Maximum renewable life: 7 days 00:00:00
Last modified: Mon Oct 14 23:42:53 EDT 2013 (admin/admin@EXAMPLE.COM)
Last successful authentication: Wed Mar 11 08:01:03 EDT 2015
Last failed authentication: [never]
Failed password attempts: 0
Number of keys: 6
Key: vno 1, aes256-cts-hmac-sha1-96, no salt
Key: vno 1, aes128-cts-hmac-sha1-96, no salt
Key: vno 1, des3-cbc-sha1, no salt
Key: vno 1, arcfour-hmac, no salt
Key: vno 1, camellia128-cts-cmac, no salt
Key: vno 1, camellia256-cts-cmac, no salt
MKey: vno 1
Attributes: REQUIRES_PRE_AUTH OK_AS_DELEGATE OK_TO_AUTH_AS_DELEGATE
Policy: [none]20.2. ユーザー、ホスト、およびサービス向け Kerberos プリンシパルエイリアスの管理
- user_name@REALM
- host/host_name@REALM
- service_name/host_name@REALM
- ユーザー名を変更したものの、ユーザーが以前のユーザー名と新たなユーザー名の両方を使ってログインする場合。
- IdM Kerberos レルムが E メールのドメインと異なる場合でも、ユーザーが E メールアドレスを使用してログインする必要がある場合。
20.2.1. Kerberos プリンシパルのエイリアス
Kerberos プリンシパルエイリアスの追加
useralias をアカウント user に追加するには、以下を入力します。
[root@ipaserver ~]# ipa user-add-principal user useralias
--------------------------------
Added new aliases to user "user"
--------------------------------
User login: user
Principal alias: user@IDM.EXAMPLE.COM, useralias@IDM.EXAMPLE.COMipa host-add-principal または ipa service-add-principal コマンドを使用します。
-C オプションを kinit コマンドに渡します。
[root@ipaserver ~]# kinit -C useralias Password for user@IDM.EXAMPLE.COM:
Kerberos プリンシパルエイリアスの削除
useralias をアカウント user から削除するには、以下を入力します。
[root@ipaserver ~]# ipa user-remove-principal user useralias -------------------------------- Removed aliases from user "user" -------------------------------- User login: user Principal alias: user@IDM.EXAMPLE.COM
ipa host-remove-principal または ipa service-remove-principal コマンドを使用します。
[root@ipaserver ~]# ipa user-show user User login: user ... Principal name: user@IDM.EXAMPLE.COM ... [root@ipaserver ~]# ipa user-remove-principal user user ipa: ERROR: invalid 'krbprincipalname': at least one value equal to the canonical principal name must be present
20.2.2. Kerberos エンタープライズプリンシパルのエイリアス
注記
\\) を使って @ 記号をエスケープします。これを使用しないとシェルは @ を Kerberos レルム名の一部として解釈し、以下のエラーが表示されます。
ipa: ERROR: The realm for the principal does not match the realm for this IPA server
Kerberos エンタープライズプリンシパルのエイリアスの追加
user@example.com を user アカウントに追加するには、以下を実行します。
[root@ipaserver ~]# ipa user-add-principal user user\\@example.com
--------------------------------
Added new aliases to user "user"
--------------------------------
User login: user
Principal alias: user@IDM.EXAMPLE.COM, user\@example.com@IDM.EXAMPLE.COMipa host-add-principal または ipa service-add-principal コマンドを使用します。
-E オプションを kinit コマンドに渡します。
[root@ipaserver ~]# kinit -E user@example.com Password for user\@example.com@IDM.EXAMPLE.COM:
Kerberos エンタープライズプリンシパルエイリアスの削除
user@example.com をアカウント user から削除するには、以下を入力します。
[root@ipaserver ~]# ipa user-remove-principal user user\\@example.com -------------------------------- Removed aliases from user "user" -------------------------------- User login: user Principal alias: user@IDM.EXAMPLE.COM
ipa host-remove-principal または ipa service-remove-principal コマンドを使用します。
第21章 NIS ドメインおよびネットグループとの統合
21.1. NIS と Identity Management
- ユーザーとパスワード
- ホスト名および IP アドレス
- POSIX グループ
Identity Management での NIS
nss_ldap から取得します。
Identity Management での NIS プラグイン
- NIS サーバープラグイン
- NIS サーバープラグインを使用すると、IdM 統合の LDAP サーバーはクライアント用の NIS サーバーとして機能することができます。この場合、設定に従って Directory Server が動的に NIS マップを生成し、更新します。このプラグインを使用することで、IdM は、NIS プロトコルを NIS サーバーとして使用するクライアントの要求に応えます。詳細情報は、「Identity Management で NIS を有効にする」 を参照してください。
- スキーマ互換性プラグイン
- このプラグインを使用すると、Directory Server バックエンドがディレクトリー情報ツリー (DIT) の一部の保存されているエントリーの別のビューを提供できるようになります。これには、属性値の追加、削除、名前変更や、ツリーの複数のエントリーから属性の値を取得することなどが含まれます。詳細については、
/usr/share/doc/slapi-nis-version/sch-getting-started.txtファイルを参照してください。
21.1.1. Identity Management での NIS Netgroup
- 入れ子グループ (他のグループのメンバーとしてのグループ)
- ホストのグループ化
- 値
- ダッシュ (
-)。これは、有効な値がないことを意味します。 - 値なし。フィールドが空の場合は、ワイルドカードを意味します。
(host.example.com,,nisdomain.example.com) (-,user,nisdomain.example.com)
- 従来の NIS マップ。NIS プラグインを使用して NIS プロトコルによりクライアントにこれを送信します。
- LDAP 形式。これは RFC 2307 または RFC 2307bis 準拠になります。
21.1.1.1. NIS Netgroup エントリーの表示
memberUser 属性に、ホストとホストグループを memberHost に保存します。以下の例では、IdM の Directory Server コンポーネントにある netgroup エントリーを表示しています。
例21.1 Directory Server 内の NIS エントリー
dn: ipaUniqueID=d4453480-cc53-11dd-ad8b-0800200c9a66,cn=ng,cn=alt,... ... cn: netgroup1 memberHost: fqdn=host1.example.com,cn=computers,cn=accounts,... memberHost: cn=VirtGuests,cn=hostgroups,cn=accounts,... memberUser: cn=demo,cn=users,cn=accounts,... memberUser: cn=Engineering,cn=groups,cn=accounts,... nisDomainName: nisdomain.example.com
ipa netgroup-* コマンドを使って netgroup エントリーを管理します。たとえば、netgroup エントリーを表示するには、以下を実行します。
例21.2 Netgroup エントリーの表示
[root@server ~]# ipa netgroup-show netgroup1 Netgroup name: netgroup1 Description: my netgroup NIS domain name: nisdomain.example.com Member Host: VirtGuests Member Host: host1.example.com Member User: demo Member User: Engineering
21.2. Identity Management で NIS を有効にする
- NIS リスナーと互換性プラグインを有効にします。
[root@ipaserver ~]# ipa-nis-manage enable [root@ipaserver ~]# ipa-compat-manage enable
- オプションで、NIS リモートプロシージャーコール (RPC) 用に固定ポートを設定します。NIS の使用時には、クライアントは IdM サーバー上のどのポートを使って接続を確立するかを知る必要があります。IdM はデフォルト設定を使用して、サーバーの起動時に未使用のランダムポートにバインドします。このポートは、クライアントがポート番号のリクエストに使用するポートマッパーサービスに送信されます。ファイアウォール設定を厳密にする場合には、固定ポートを設定出来ます。たとえば、ポートを
514に設定するには、以下を実行します。[root@ipaserver ~]# ldapmodify -x -D 'cn=directory manager' -W dn: cn=NIS Server,cn=plugins,cn=config changetype: modify add: nsslapd-pluginarg0 nsslapd-pluginarg0: 514
注記
この設定には、1024 より下のポート番号で未使用のものを使用できます。 - ポートマッパーサービスを有効にして、起動します。
[root@ipaserver ~]# systemctl enable rpcbind.service [root@ipaserver ~]# systemctl start rpcbind.service
- Directory Server を再起動します。
[root@ipaserver ~]# systemctl restart dirsrv.target
21.3. Netgroups の作成
21.3.1. Netgroup の追加
- IdM Web UI (「Web UI: Netgroup の追加」 を参照)
- コマンドライン (「コマンドライン: Netgroup の追加」 を参照)
Web UI: Netgroup の追加
- → → を選択します。
- Add をクリックします。
- 一意の名前と、オプションで説明を入力します。グループ名は、IdM ドメインの netgroup で使用される識別子です。これは後で変更できません。
- をクリックして変更を保存し、エントリーの編集を開始します。
- デフォルトの NIS ドメインが IdM ドメイン名に設定されます。 オプションで、別の NIS ドメイン名を NIS ドメイン名フィールドに入力することもできます。

図21.1 Netgroup タブ
NIS domain name フィールドでは、netgroup の tripleに表示されるドメインを設定します。これは、Identity Management リスナーが応答する NIS ドメインに影響するものではありません。 - 「Web UI: Netgroup にメンバーを追加する」 にあるように、メンバーを追加します。
- をクリックします。
コマンドライン: Netgroup の追加
ipa netgroup-add コマンドを使って追加します。以下を指定します。
- グループ名
- オプションで説明
- NIS ドメイン名が IdM ドメイン名とは別の場合、これをオプションで追加
注記
--nisdomainオプションでは、netgroup の tripleに表示されるドメインを設定します。これは、Identity Management リスナーが応答する NIS ドメインに影響するものではありません。
[root@server ~]# ipa netgroup-add --desc="Netgroup description" --nisdomain="example.com" example-netgroup
21.3.2. Netgroup にメンバーを追加する
- IdM web UI (「Web UI: Netgroup にメンバーを追加する」 を参照)
- コマンドライン (「コマンドライン: Netgroup にメンバーを追加する」 を参照)
警告
Web UI: Netgroup にメンバーを追加する
- → → を選択します。
- メンバーを追加する netgroup 名をクリックします。
- メンバータイプ横にある をクリックします。
- 追加するメンバーを選択し、 をクリックして確定します。

図21.3 Netgroup タブでのユーザー追加メニュー
- をクリックします。
コマンドライン: Netgroup にメンバーを追加する
ipa netgroup-add-member コマンドでメンバーを追加します。
# ipa netgroup-add-member --users=user_name --groups=group_name --hosts=host_name \
--hostgroups=host_group_name --netgroups=netgroup_name group_nameame[root@server ~]# ipa netgroup-add-member --users={user1;user2,user3} \
--groups={group1,group2} example-group21.4. 自動マウントマップの NIS クライアントへの公開
- NIS ドメイン名
- NIS マップ名
- NIS マップのコンテンツとして使用するためのディレクトリーエントリーの発見方法
- NIS マップのキーおよび値としてどの属性を使用するかについての情報
21.4.1. 自動マウントマップの追加
cn=automount ブランチに保存します。NIS ドメインとマップは LDAP プロトコルを使って追加できます。
example.com ドメイン内の default の場所にある auto.example という自動マウントマップを追加するには、以下を実行します。
[root@server ~]# ldapadd -h server.example.com -x -D "cn=Directory Manager" -W
dn: nis-domain=example.com+nis-map=auto.example,cn=NIS Server,cn=plugins,cn=config
objectClass: extensibleObject
nis-domain: example.com
nis-map: auto.example
nis-filter: (objectclass=automount)
nis-key-format: %{automountKey}
nis-value-format: %{automountInformation}
nis-base: automountmapname=auto.example,cn=default,cn=automount,dc=example,dc=com注記
nis-domain 属性は、自分の NIS ドメイン名に設定します。
nis-base 属性で設定する値は、以下のものに対応する必要があります。
ipa automountmap-*コマンドを使用して設定した既存の自動マウントマップipa automountlocation-*コマンドを使用して設定した既存の自動マウントの場所
[root@server ~]# ypcat -k -d example.com -h server.example.com auto.example
21.5. NIS から IdM への移行
21.5.1. IdM でのネットグループエントリーの準備
- ユーザーエントリー
- NIS が提供しているユーザー情報を使用しているアプリケーションを判定します。
sudoなどのユーティリティーは NIS netgroup を必要としますが、通常の UNIX グループを使用できるものもあります。移行は、以下の手順で実行します。- 対応するユーザーアカウントを IdM に作成します。「ユーザーエントリーの移行」 を参照してください。
- さらに netgroup が必要な場合は、以下を実行します。
- netgroup を追加します。「Netgroup の追加」 を参照してください。
- ユーザーを netgroup に追加します。「Netgroup エントリーの移行」 を参照してください。
- ホストエントリー
- IdM でホストグループを作成すると、対応するシャドウ NIS グループが自動的に作成されます。これらのネットグループは、
ipa netgroup-*コマンドを使って管理します。 - 直接変換の場合
- ユーザーおよびホストエントリーですべて同じ名前を使用する必要がある場合は、IdM 内の同一名を使用してエントリーを作成します。
- netgroup で参照されているユーザーすべてについてエントリーを作成します。
- netgroup で参照されているホストすべてについてエントリーを作成します。
- 元の netgroup と同じ名前の netgroup を作成します。
- ユーザーとホストをこの netgroup の直接のメンバーとして追加します。ユーザーおよびホストがグループまたはホストグループのメンバーである場合は、これらのグループを netgroup に追加します。
21.5.2. Identity Management で NIS リスナーを有効にする
21.5.3. 既存 NIS データのインポートおよびエクスポート
ypcat コマンドを使ってデータをNIS サーバーからエクスポートし、その出力を使用して対応する ipa *-add コマンドでエントリーを IdM にインポートします。
21.5.3.1. ユーザーエントリーの移行
passwd マップには、UID、プライマリーグループ、GECOS、シェル、およびホームディレクトリーなどのユーザー情報が含まれます。このデータを使用して NIS ユーザーアカウントを IdM に移行します。
- オプションで、弱いパスワードのサポートが必要な場合は、「NIS ユーザー認証用に脆弱なパスワードハッシュを有効にする」 を参照してください。
- 以下のコンテンツで
/root/nis-users.shスクリプトを作成します。#!/bin/sh # $1 is the NIS domain, $2 is the NIS master server ypcat -d $1 -h $2 passwd > /dev/shm/nis-map.passwd 2>&1 IFS=$'\n' for line in $(cat /dev/shm/nis-map.passwd) ; do IFS=' ' username=$(echo $line | cut -f1 -d:) # Not collecting encrypted password because we need cleartext password # to create kerberos key uid=$(echo $line | cut -f3 -d:) gid=$(echo $line | cut -f4 -d:) gecos=$(echo $line | cut -f5 -d:) homedir=$(echo $line | cut -f6 -d:) shell=$(echo $line | cut -f7 -d:) # Now create this entry echo passw0rd1 | ipa user-add $username --first=NIS --last=USER \ --password --gidnumber=$gid --uid=$uid --gecos=$gecos --homedir=$homedir \ --shell=$shell ipa user-show $username done
- IdM
adminユーザーとして認証します。[root@nis-server ~]# kinit admin
- 以下のようにスクリプトを実行します。
[root@nis-server ~]# sh /root/nis-users.sh nisdomain nis-master.example.com
注記
このスクリプトはハードコーディングされた値を性、名に使用し、パスワードをpassw0rd1に設定します。ユーザーは次回ログイン時にこのパスワードを変更する必要があります。
21.5.3.2. グループエントリーの移行
group マップには、グループ名、GID、グループメンバーなどのグループ情報が含まれます。このデータを使用して NIS グループを IdM に移行します。
- 以下のコンテンツで
/root/nis-groups.shスクリプトを作成します。#!/bin/sh # $1 is the NIS domain, $2 is the NIS master server ypcat -d $1 -h $2 group > /dev/shm/nis-map.group 2>&1 IFS=$'\n' for line in $(cat /dev/shm/nis-map.group); do IFS=' ' groupname=$(echo $line | cut -f1 -d:) # Not collecting encrypted password because we need cleartext password # to create kerberos key gid=$(echo $line | cut -f3 -d:) members=$(echo $line | cut -f4 -d:) # Now create this entry ipa group-add $groupname --desc=NIS_GROUP_$groupname --gid=$gid if [ -n "$members" ]; then ipa group-add-member $groupname --users={$members} fi ipa group-show $groupname done - IdM
adminユーザーとして認証します。[root@nis-server ~]# kinit admin
- 以下のようにスクリプトを実行します。
[root@nis-server ~]# sh /root/nis-groups.sh nisdomain nis-master.example.com
21.5.3.3. ホストエントリーの移行
hosts マップには、ホスト名や IP アドレスなどのホスト情報が含まれます。このデータを使用して NIS ホストエントリーを IdM に移行します。
- 以下のコンテンツで
/root/nis-hosts.shスクリプトを作成します。#!/bin/sh # $1 is the NIS domain, $2 is the NIS master server ypcat -d $1 -h $2 hosts | egrep -v "localhost|127.0.0.1" > /dev/shm/nis-map.hosts 2>&1 IFS=$'\n' for line in $(cat /dev/shm/nis-map.hosts); do IFS=' ' ipaddress=$(echo $line | awk '{print $1}') hostname=$(echo $line | awk '{print $2}') master=$(ipa env xmlrpc_uri | tr -d '[:space:]' | cut -f3 -d: | cut -f3 -d/) domain=$(ipa env domain | tr -d '[:space:]' | cut -f2 -d:) if [ $(echo $hostname | grep "\." |wc -l) -eq 0 ] ; then hostname=$(echo $hostname.$domain) fi zone=$(echo $hostname | cut -f2- -d.) if [ $(ipa dnszone-show $zone 2>/dev/null | wc -l) -eq 0 ] ; then ipa dnszone-add --name-server=$master --admin-email=root.$master fi ptrzone=$(echo $ipaddress | awk -F. '{print $3 "." $2 "." $1 ".in-addr.arpa."}') if [ $(ipa dnszone-show $ptrzone 2>/dev/null | wc -l) -eq 0 ] ; then ipa dnszone-add $ptrzone --name-server=$master --admin-email=root.$master fi # Now create this entry ipa host-add $hostname --ip-address=$ipaddress ipa host-show $hostname done - IdM
adminユーザーとして認証します。[root@nis-server ~]# kinit admin
- 以下のようにスクリプトを実行します。
[root@nis-server ~]# sh /root/nis-hosts.sh nisdomain nis-master.example.com
注記
このスクリプトでは、エイリアスなどの特定なホスト設定は移行されません。
21.5.3.4. Netgroup エントリーの移行
netgroup マップには、netgroup についての情報が含まれます。このデータを使用して NIS netgroup を IdM に移行します。
- 以下のコンテンツで
/root/nis-netgroups.shスクリプトを作成します。#!/bin/sh # $1 is the NIS domain, $2 is the NIS master server ypcat -k -d $1 -h $2 netgroup > /dev/shm/nis-map.netgroup 2>&1 IFS=$'\n' for line in $(cat /dev/shm/nis-map.netgroup); do IFS=' ' netgroupname=$(echo $line | awk '{print $1}') triples=$(echo $line | sed "s/^$netgroupname //") echo "ipa netgroup-add $netgroupname --desc=NIS_NG_$netgroupname" if [ $(echo $line | grep "(," | wc -l) -gt 0 ]; then echo "ipa netgroup-mod $netgroupname --hostcat=all" fi if [ $(echo $line | grep ",," | wc -l) -gt 0 ]; then echo "ipa netgroup-mod $netgroupname --usercat=all" fi for triple in $triples; do triple=$(echo $triple | sed -e 's/-//g' -e 's/(//' -e 's/)//') if [ $(echo $triple | grep ",.*," | wc -l) -gt 0 ]; then hostname=$(echo $triple | cut -f1 -d,) username=$(echo $triple | cut -f2 -d,) domain=$(echo $triple | cut -f3 -d,) hosts=""; users=""; doms=""; [ -n "$hostname" ] && hosts="--hosts=$hostname" [ -n "$username" ] && users="--users=$username" [ -n "$domain" ] && doms="--nisdomain=$domain" echo "ipa netgroup-add-member $hosts $users $doms" else netgroup=$triple echo "ipa netgroup-add $netgroup --desc=NIS_NG_$netgroup" fi done done - IdM
adminユーザーとして認証します。[root@nis-server ~]# kinit admin
- 以下のようにスクリプトを実行します。
[root@nis-server ~]# sh /root/nis-netgroups.sh nisdomain nis-master.example.com
21.5.3.5. 自動マウントマップの移行
- 以下のコンテンツで
/root/nis-automounts.shスクリプトを作成します。#!/bin/sh # $1 is for the automount entry in ipa ipa automountlocation-add $1 # $2 is the NIS domain, $3 is the NIS master server, $4 is the map name ypcat -k -d $2 -h $3 $4 > /dev/shm/nis-map.$4 2>&1 ipa automountmap-add $1 $4 basedn=$(ipa env basedn | tr -d '[:space:]' | cut -f2 -d:) cat > /tmp/amap.ldif <<EOF dn: nis-domain=$2+nis-map=$4,cn=NIS Server,cn=plugins,cn=config objectClass: extensibleObject nis-domain: $2 nis-map: $4 nis-base: automountmapname=$4,cn=$1,cn=automount,$basedn nis-filter: (objectclass=*) nis-key-format: %{automountKey} nis-value-format: %{automountInformation} EOF ldapadd -x -h $3 -D "cn=Directory Manager" -W -f /tmp/amap.ldif IFS=$'\n' for line in $(cat /dev/shm/nis-map.$4); do IFS=" " key=$(echo "$line" | awk '{print $1}') info=$(echo "$line" | sed -e "s#^$key[ \t]*##") ipa automountkey-add nis $4 --key="$key" --info="$info" doneこのスクリプトでは NIS 自動マウント情報がエクスポートされ、LDAP データ変換形式 (LDIF) の自動マウントの場所と関連マップが生成され、LDIF ファイルが IdM Directory Server にインポートされます。詳細については、「自動マウントマップの NIS クライアントへの公開」 を参照してください。 - IdM
adminユーザーとして認証します。[root@nis-server ~]# kinit admin
- 以下のようにスクリプトを実行します。
[root@nis-server ~]# sh /root/nis-automounts.sh location nisdomain \ nis-master.example.com map_name
21.5.4. NIS ユーザー認証用に脆弱なパスワードハッシュを有効にする
userPassword 属性に保存されているパスワードはソルト付き SHA を使ってハッシュ化されます。お使いの NIS クライアントでパスワード用に脆弱なハッシュ化アルゴリズムが必要な場合は、パスワード保存スキームの設定を更新します。
userPassword 属性に保存されているパスワードにのみ影響があります。Kerberos はこの属性を使用しないので、この設定は Kerberos 暗号化に影響しないことに留意してください。
CRYPT ハッシュ化パスワードを有効にするには、以下を実行します。
[root@server ~]# ldapmodify -D "cn=Directory Manager" -W -p 389 -h ipaserver.example.com -x dn: cn=config changetype: modify replace: passwordStorageScheme passwordStorageScheme: crypt
注記
パート V. 認証メカニズムの管理
第22章 ユーザー認証
注記
22.1. ユーザーパスワード
22.1.1. ユーザーパスワードの変更およびリセット
- IdM パスワードポリシーに対応する必要があります。パスワードポリシーの設定に関する詳細は27章パスワードポリシーの定義を参照してください。
- IdM パスワードポリシーに対応する必要はありません。
- 正しく初回ログインができた時点に失効します。パスワードが失効すると、IdM はユーザーに対して失効したパスワードを直ちに変更するように求めます。この動作を変更するには「次回のログイン時にパスワード変更のプロンプトを表示しないでパスワードのリセットを有効化する方法」を参照してください。
注記
22.1.1.1. Web UI: 個人のパスワードの変更
- 右上隅の → をクリックします。

図22.1 パスワードのリセット
- 新規パスワードを入力します。
22.1.1.2. Web UI: 別ユーザーのパスワードのリセット
- → を選択します。
- 編集するユーザー名をクリックします。
- → をクリックします。

図22.2 パスワードのリセット
- 新規パスワードを入力して をクリックします。

図22.3 新規パスワードの確定
22.1.1.3. コマンドライン: 別のユーザーのパスワード変更またはリセット
ipa user-mod コマンドに --password オプションを追加します。このコマンドにより、新規パスワードを入力するように求められます。
$ ipa user-mod user --password Password: Enter Password again to verify: -------------------- Modified user "user" -------------------- ...
22.1.2. 次回のログイン時にパスワード変更のプロンプトを表示しないでパスワードのリセットを有効化する方法
- パスワードの同期エントリーを編集します (
cn=ipa_pwd_extop,cn=plugins,cn=config)。 passSyncManagersDNs属性で管理ユーザーアカウントを指定します。この属性には、複数の値を指定することができます。
ldapmodifyユーティリティーを使用して admin ユーザーを指定するには以下を実行します。
$ ldapmodify -x -D "cn=Directory Manager" -W -h ldap.example.com -p 389
dn: cn=ipa_pwd_extop,cn=plugins,cn=config
changetype: modify
add: passSyncManagersDNs
passSyncManagersDNs: uid=admin,cn=users,cn=accounts,dc=example,dc=com警告
passSyncManagerDNs に含まれる全ユーザーは以下が可能です。
- すぐ後にパスワードのリセットせずにパスワードの変更操作を実行する
- パスワード強度や履歴の制限を適用しなくていいようにパスワードポリシーを回避する
22.1.3. ログイン失敗後のユーザーアカウントのロック解除
注記
ユーザーアカウントの手動のロック解除
ipa user-unlock コマンドを使用します。
$ ipa user-unlock user ----------------------- Unlocked account "user" -----------------------
22.1.3.1. ユーザーアカウントのステータス確認
ipa user-status コマンドを使用します。表示の回数がログインを試行できる回数を超えると、ユーザーアカウントはロックされます。
$ ipa user-status user
-----------------------
Account disabled: False
-----------------------
Server: example.com
Failed logins: 8
Last successful authentication: 20160229080309Z
Last failed authentication: 20160229080317Z
Time now: 2016-02-29T08:04:46Z
----------------------------
Number of entries returned 1
----------------------------22.2. ワンタイムパスワード
重要
- 従来のパスワードを使用したユーザー認証
- ユーザーは、認識済みの OTP トークンで生成された OTP コードを入力します。
警告
- 最も重要なセキュリティー制限として、システム全体でリプレイアタックの被害を受けやすくなる点です。レプリケーションは非同期で実行されるので、OTP コードはレプリケーション中に再利用でき、ユーザーは同時に 2 台のサーバーにログインできる可能性があります。ただし、包括的な暗号化があると、この脆弱性を悪用するのは困難です。
- OTP 認証をサポートしていないクライアント経由では、ticket-granting ticket (TGT) を取得することができません。これは、
mod_auth_kerbモジュールまたは Generic Security Services API (GSSAPI) を使用した認証などのユースケースに影響する可能性があります。
22.2.1. IdM でのOTP の機能
22.2.1.1. IdM でサポートされる OTP トークン
ソフトウェアおよびハードウェアトークン
ユーザーおよび管理者が管理するトークン
- ユーザー管理のトークン
- ユーザーは、トークの作成、編集、削除など、Identity Management でユーザーが管理するトークンを完全に制御できます。
- 管理者が管理するトークン
- 管理者は、管理者が管理するトークンをユーザーのアカウントに追加し、ユーザーはこれらのトークンへの読み取り専用アクセスが割り当てられます。ユーザーはトークンの管理または変更パーミッションがなく、設定する必要はありません。
サポートされる OTP アルゴリズム
- HMAC ベースのワンタイムパスワード (HOTP) アルゴリズムは、カウンターに基づいています。HMAC は、Hashed Message Authentication Code (ハッシュメッセージ認証コード) を表しています。
- 時間ベースのワンタイムパスワード (TOTP) アルゴリズムは、時間ベースの移動要素をサポートする HOTP の拡張機能です。
22.2.1.2. 利用可能な OTP 認証方法
- 二要素認証 (パスワード + OTP)
- この方法では、ユーザーは常に標準のパスワードと OTP コードを入力するように求められます。
- パスワード
- この方法では、ユーザーは標準のパスワードのみを使用した認証を選択するオプションがあります。
- RADIUS プロキシサーバー認証
- OTP の検証用に RADIUS サーバーを設定する方法は「商用 OTP ソリューションからの移行」を参照してください。
グローバルおよびユーザー固有の認証方法
- デフォルトでは、ユーザー固有の認証方法の設定は、グローバルの設定よりも優先されます。認証方法がユーザーに設定されていない場合には、グローバルに定義された方法が適用されます。
- ユーザー毎の認証方法を無効化することができます。これにより、IdM はユーザー毎の設定を無視して常にグローバルの設定を適用することができます。
複数の認証方法の統合
- 二要素認証およびパスワード認証を設定すると、ユーザーはコマンドラインを使用する場合にはパスワード (1 つ目の要素) を指定する必要がありますが、OTP (2 つ目の要素) はオプションです。
First Factor: Second Factor (optional):
- Web UI ではユーザーは両要素を指定する必要があります。
注記
- Kerberos は常に RADIUS を使用しますが LDAP は RADIUS を使用しません。LDAP が認識するのは、パスワードと二要素認証のオプションのみです。
- 外部の 2 要素認証プロバイダーを使用する場合は、使用しているアプリケーションから Kerberos を使用します。ユーザーがパスワードのみで認証するようにするには、LDAP を使用します。アプリケーションが Apache モジュールと SSSD を活用するようにすることが推奨されます。そうすることで、Kerberos か LDAP のいずれかを設定することができます。
22.2.1.3. GNOME のキーリングサービスサポート
First factor: static_password Second factor: one-time_password
22.2.1.4. OTP でのオフライン認証
First factor: static_password Second factor: one-time_password
First factor のプロンプトで静的なパスワードと OTP を 1 つの文字列として入力できるようにサポートします。ただし、オフラインの OTP 認証とは互換性がない点に注意してください。ユーザーが両要素を単一のプロンプトで入力した場合には、IdM は認証時に常に中央認証サーバに問い合わせる必要があるので、認証時にはシステムがオンラインの状態でなければなりません。
重要
/etc/sssd/sssd.confファイルのcache_credentialsオプションをTrueに設定すると、第一要素のパスワードのキャッシュが有効になります。- 第一要素の静的パスワードが、
/etc/sssd/sssd.confのcache_credentials_minimal_first_factor_lengthオプションで定義されているパスワード長の要件を満たしていること。デフォルトでは、少なくとも 8 文字以上指定する必要があります。オプションに関する情報は、sssd.conf(5) の man ページを参照してください。
/etc/sssd/sssd.conf で krb5_store_password_if_offline オプションが true に設定されている場合でも、その時点で OTP がすでに無効になっている可能性があるので SSSD は Kerberos ticket-granting ticket (TGT) の更新は試行しません。このような状況で TGT を取得するには、両要素を使用して認証する必要があります。
22.2.2. OTP 認証の有効化
- Web UI。「Web UI: OTP 認証の有効化」を参照してください。
- コマンドライン。「コマンドライン: OTP 認証の有効化」を参照してください。
Web UI: OTP 認証の有効化
- → を選択します。
- User Options エリアで、必要な Default user authentication types を選択します。

図22.4 ユーザー認証方法
- → を選択して、編集するユーザーの名前をクリックします。
- Account Settings エリアで、必要な User authentication types を選択します。

図22.5 ユーザー認証方法
コマンドライン: OTP 認証の有効化
ipa config-mod --user-auth-typeコマンドを実行します。たとえば、グローバル認証方法を二要素認証に設定するには以下を実行します。$ ipa config-mod --user-auth-type=otp
--user-auth-typeに入力できる値の一覧については、ipa config-mod --helpコマンドを実行します。- ユーザー別の上書きを無効にする、つまりユーザーの設定がグローバル設定を上書きしないようにするには、
--user-auth-type=disabledオプションも追加します。たとえば、二要素認証にグローバル認証方法を設定してユーザーの上書きを無効にするには以下を設定します。$ ipa config-mod --user-auth-type=otp --user-auth-type=disabled
--user-auth-type=disabledを設定しない場合には、ユーザー毎に設定した認証方法がグローバル設定よりも優先されます。
ipa user-mod --user-auth-typeコマンドを実行します。たとえば、userが二要素認証を使用するように設定するには以下を実行します。$ ipa user-mod user --user-auth-type=otp
--user-auth-type を複数回追加します。たとえば、パスワードとに要素認証を全ユーザーにグローバルに設定するには、以下を実行します。
$ ipa config-mod --user-auth-type=otp --user-auth-type=password
22.2.3. ユーザー管理のソフトウェアトークンの追加
- 標準のパスワードでログインします。
- モバイルデバイスに
FreeOTP Authenticatorアプリケーションがインストールされていることを確認します。FreeOTP Authenticatorのダウンロードについては、FreeOTP source page を参照してください。 - IdM Web UI またはコマンドラインでソフトウェアトークンを作成します。
- Web UI でトークンを作成するには、OTP tokens タブで Add をクリックします。管理者としてログインしている場合は Authentication から OTP Tokens tab タブにアクセスできます。

図22.6 ユーザー用の OTP トークンの追加
- コマンドラインからトークンを作成するには
ipa otptoken-addコマンドを実行します。$ ipa otptoken-add ------------------ Added OTP token "" ------------------ Unique ID: 7060091b-4e40-47fd-8354-cb32fecd548a Type: TOTP ...
ipa otptoken-addに関する情報は、--helpオプションを追加してこのコマンドを実行します。
- Web UI またはコマンドラインに QR コードが表示されます。QR コードを
FreeOTP Authenticatorでスキャンして、モバイルデバイスのトークンを提供します。
22.2.4. ユーザー管理の YubiKey ハードウェアトークンの追加
- 標準のパスワードでログインします。
- YubiKey トークンを挿入します。
ipa otptoken-add-yubikeyコマンドを実行します。- YubiKey に空のスロットがある場合には、コマンドは、その空のスロットを自動的に選択します。
- 空のスロットがない場合には
--slotオプションを使用して手動でスロットを選択する必要があります。以下に例を示します$ ipa otptoken-add-yubikey --slot=2
これは、選択したスロットを上書きする点に注意してください。
22.2.5. 管理者としてユーザー用のトークン追加
- 管理者としてログインしていることを確認します。
- モバイルデバイスに
FreeOTP Authenticatorアプリケーションがインストールされていることを確認します。FreeOTP Authenticatorのダウンロードについては、FreeOTP source page を参照してください。 - IdM Web UI またはコマンドラインでソフトウェアトークンを作成します。
- Web UI でトークンを作成するには、 → を選択して、OTP トークンの一覧の上部にある をクリックします。Add OTP Token フォームで、トークンの所有者を選択します。

図22.7 管理者が管理するソフトウェアトークンの追加
- コマンドラインからトークンを作成するには
--ownerオプションを指定してipa otptoken-addコマンドを実行します。以下に例を示します。$ ipa otptoken-add --owner=user ------------------ Added OTP token "" ------------------ Unique ID: 5303baa8-08f9-464e-a74d-3b38de1c041d Type: TOTP ...
- Web UI またはコマンドラインに QR コードが表示されます。QR コードを
FreeOTP Authenticatorでスキャンして、モバイルデバイスのトークンを提供します。
- 管理者としてログインしていることを確認します。
- YubiKey トークンを挿入します。
--ownerオプションを指定してipa otptoken-add-yubikeyコマンドを実行します。以下に例を示します。$ ipa otptoken-add-yubikey --owner=user
22.2.6. 商用 OTP ソリューションからの移行
注記
- radius のユーザー認証方法が有効になっていることを確認します。「OTP 認証の有効化」を参照してください。
ipa radiusproxy-add proxy_nameコマンドを実行して RADIUS プロキシーを追加します。このコマンドにより、必要な情報を入力するように求められます。ipa user-mod radiususer --radius=proxy_nameコマンドを実行して、追加したプロキシーにユーザーを割り当てます。- 必要に応じて、
ipa user-mod radiususer --radius-username=radius_userを実行し、RADIUS に送信するユーザー名を設定します。
22.2.7. 現在の認証情報の二要素認証へのプロモート
- 画面をロックします。画面ロックのデフォルトのキーボードショートカットは Super key+L です。
- 画面のロックを解除します。認証情報を求められたら、パスワードと OTP の両方を使用します。
22.2.8. OTP トークンの再同期
22.3. ユーザーの認証情報をもとにサービスやホストへのアクセス制限
- 強力な認証方法を必要とする VPN など極めて重要なセキュリティー関連のサービス
- 強度は低いが便利な認証方法を使用できる、ローカルのログインなど重要でないサービス

図22.8 異なる方法を使用した認証例
認証インジケーター
- サービスまたはホストエントリーに含まれるインジケーターは、ユーザーがサービスやホストへのアクセスに使用する認証方法を定義します。
- ユーザーの TGT (Ticket Granting Ticket) に含まれるインジケーターは、チケットの取得に使用した認証方法を表示します。
22.3.1. 特定の認証方法を必要とするホストまたはサービスの設定
- Web UI。「Web UI: 特定の認証方法を必要とするホストまたはサービスの設定」を参照してください。
- コマンドライン。「コマンドライン: 特定の認証方法を必要とするホストまたはサービスの設定」を参照してください。
Web UI: 特定の認証方法を必要とするホストまたはサービスの設定
- → または → を選択します。
- 所定のホストまたはサービスの名前をクリックします。
- Authentication indicators で所定の認証方法を選択します。
- たとえば OTP を選択すると、有効な OTP コードとパスワードを使用したユーザーのみがホストまたはサービスにアクセスができます。
- OTP および RADIUS 両方を選択すると、OTP または RADIUS のいずれかを提示すれば、アクセスが許可されます。
- ページ上部にある をクリックします。
コマンドライン: 特定の認証方法を必要とするホストまたはサービスの設定
- オプション:
ipa host-findまたはipa service-findコマンドを使用して、ホストまたはサービスを特定します。 ipa host-modまたはipa service-modコマンドに--auth-indオプションを指定して実行し、必要な認証インジケーターを追加します。--auth-indで利用できる値の一覧は、ipa host-mod --helpまたはipa service-mod --helpコマンドの出力を参照してください。たとえば、--auth-ind=otpでは、有効な OTP コードとパスワードを使用したユーザーのみがホストまたはサービスへのアクセスが許可されます。$ ipa host-mod server.example.com --auth-ind=otp --------------------------------------------------------- Modified host "server.example.com" --------------------------------------------------------- Host name: server.example.com ... Authentication Indicators: otp ...
OTP と RADIUS の両方のインジケーターを追加した場合には、OTP または RADIUS のいずれかを提示するだけでアクセスが許可されます。
22.4. ユーザーの公開 SSH キーの管理
ssh を使用して Kerberos 認証情報なしに IdM マシンにログインできます。pam_krb5 が正しく設定されているか、SSSD が IdM サーバーの ID プロバイダーとして使用されている場合には、ログイン後に Kerberos ticket-granting ticket (TGT) を受け取ります。詳細は「Kerberos チケットの自動取得」を参照してください。
SSH 鍵の自動キャッシュおよび取得
SSH 鍵の形式要件
id_rsa.pub などの鍵ファイルは、鍵タイプ、鍵、追加のコメントまたは識別子の 3 つの部分で公正されます。以下の例では、鍵のタイプは RSA で、コメントにより鍵と client.example.com ホスト名とを関連付けます。
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDMM4xPu54Kf2dx7C4Ta2F7vnIzuL1i6P21TTKniSkjFuA+r qW06588e7v14Im4VejwnNk352gp49A62qSVOzp8IKA9xdtyRmHYCTUvmkcyspZvFRI713zfRKQVFyJOqHmW/m dCmak7QBxYou2ELSPhH3pe8MYTQIulKDSu5Zbsrqedg1VGkSJxf7mDnCSPNWWzAY9AFB9Lmd2m2xZmNgVAQEQ nZXNMaIlroLD/51rmMSkJGHGb1O68kEq9Z client.example.com
22.4.1. SSH 鍵の生成
ssh-keygen ユーティリティーを使用して SSH 鍵を生成できます。このユーティリティーは、公開鍵の場所に関する情報を表示します。以下に例を示します。
$ ssh-keygen -t rsa -C user@example.com
Generating public/private rsa key pair.
Enter file in which to save the key (/home/user/.ssh/id_rsa):
Created directory '/home/user/.ssh'.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/user/.ssh/id_rsa.
Your public key has been saved in /home/user/.ssh/id_rsa.pub.
The key fingerprint is:
SHA256:GAUIDVVEgly7rs1lTWP6oguHz8BKvyZkpqCqVSsmi7c user@example.com
The key's randomart image is:
+--[ RSA 2048]----+
| |
| + . |
| + = . |
| = + |
| . E S.. |
| . . .o |
| . . . oo. |
| . o . +.+o |
| o .o..o+o |
+-----------------+22.4.2. ユーザーの SSH 鍵のアップロード
22.4.2.1. Web UI: ユーザーの SSH 鍵のアップロード
- → を選択します。
- 編集するユーザー名をクリックします。
- Account Settings エリアの Settings タブで、SSH public keys: Add をクリックしてください。

図22.9 アカウント設定の SSH 公開鍵
- Base 64 でエンコードされた公開鍵の文字列を貼り付け、 をクリックします。

図22.10 公開鍵の貼り付け
- ページ上部の Save をクリックします。
22.4.2.2. コマンドライン: ユーザーの SSH 鍵のアップロード
ipa user-mod コマンドを使用して、--sshpubkey オプションを指定して Base 64 でエンコードされた公開鍵の文字列を渡します。
$ ipa user-mod user --sshpubkey="ssh-rsa AAAAB3Nza...SNc5dv== client.example.com"
--sshpubkey を複数回実行します。たとえば、SSH 鍵を 2 つアップロードするには以下を実行します。
--sshpubkey="AAAAB3Nza...SNc5dv==" --sshpubkey="RjlzYQo...ZEt0TAo="
注記
$ ipa user-mod user --sshpubkey="$(cat ~/.ssh/id_rsa.pub)" --sshpubkey="$(cat ~/.ssh/id_rsa2.pub)"
22.4.3. ユーザーキーの削除
- Web UI を使用する場合は「Web UI: ユーザーの SSH 鍵の削除」を参照してください。
- コマンドラインを使用する場合は「コマンドライン: ユーザーの SSH 鍵の削除」を参照してください。
22.4.3.1. Web UI: ユーザーの SSH 鍵の削除
- → を選択します。
- 編集するユーザー名をクリックします。
- Account Settings エリアの Settings タブで、削除する鍵の横にある Delete をクリックします。

図22.11 ユーザーの SSH 公開鍵の削除
- ページ上部の Save をクリックします。
22.4.3.2. コマンドライン: ユーザーの SSH 鍵の削除
ipa user-mod コマンドに --sshpubkey オプションを追加します。
$ ipa user-mod user --sshpubkey=
--sshpubkey オプションを使用して、保持する鍵を指定します。
22.5. SSSD が OpenSSH サービス用にキャッシュを提供するように設定する方法
22.5.1. SSSD と OpenSSH との連携方法
- OpenSSH は、SSSD を参照してキャッシュされた鍵があるかを確認するように設定されます。
- SSSD は Identity Management (IdM) ドメインを使用し、IdM は公開鍵とホストの情報を保存します。
注記
SSSD のホスト鍵の管理方法
- ホストシステムから公開ホスト鍵を取得します。
/var/lib/sss/pubconf/known_hostsファイルにホスト鍵を保存します。- ホストマシンとの接続を確率します。
SSSD のユーザー鍵の管理方法
- IdM ドメインのユーザーエントリーからユーザーの公開鍵を取得します。
- ユーザー鍵を標準の認証鍵形式でカスタムファイル
.ssh/sss_authorized_keysに保存します。
22.5.2. OpenSSH がホスト鍵に SSSD を使用するように設定する手順
- 必要な設定ファイルを開きます。
- ユーザー固有の設定を変更するには、
~/.ssh/configファイルを開きます。 - システム全体の設定を変更するには
/etc/ssh/sshd_configファイルを開きます。
ProxyCommandオプションを使用して、どのコマンドを使用して SSH クライアント (sss_ssh_knownhostsproxyユーティリティーで必要な引数とホスト名を指定) に接続するかを指定します。sss_ssh_knownhostsproxyの詳細は、sss_ssh_knownhostsproxy(1) の man ページを参照してください。GlobalKnownHostsFileオプションを使用して、SSSD ホストファイル/var/lib/sss/pubconf/known_hostsの場所を指定します。このファイルは、デフォルトの OpenSSHknown_hostsファイルの代わりに使用します。
ProxyCommand /usr/bin/sss_ssh_knownhostsproxy -p %p %h GlobalKnownHostsFile /var/lib/sss/pubconf/known_hosts
22.5.3. ユーザー鍵に SSSD を使用するための OpenSSH 設定
- 必要な設定ファイルを開きます。
- ユーザー固有の設定を変更するには、
~/.ssh/configファイルを開きます。 - システム全体の設定を変更するには
/etc/ssh/sshd_configファイルを開きます。
AuthorizedKeysCommandオプション使用して、ユーザー鍵を取得するために実行するコマンドを指定します。AuthorizedKeysCommandUserオプションを使用して、コマンドを実行するユーザーアカウントを指定します。
user アカウントで sss_ssh_authorizedkeys ユーティリティー実行するように設定します。
AuthorizedKeysCommand /usr/bin/sss_ssh_authorizedkeys AuthorizedKeysCommandUser user
sss_ssh_authorizedkeys の詳細は、sss_ssh_authorizedkeys(1) の man ページを参照してください。
22.6. Identity Management でのスマートカード認証
22.7. ユーザー証明書
第23章 Identity Management でのスマートカード認証
23.1. Identity Management サーバーのスマートカードリンクの管理
- スマートカードから証明書を抽出する必要がある場合は「スマートカードからの証明書のエクスポート」を参照してください。
23.1.1. スマートカードからの証明書のエクスポート
- スマートカードをリーダーに挿入します。
- 以下のコマンドを実行してスマートカードの証明書を表示します。出力で認証に使用する証明書を特定して、そのニックネームをメモします。
$
certutil -L -d /etc/pki/nssdb/ -h allCertificate Nickname Trust Attributes SSL,S/MIME,JAR/XPI my_certificate CT,C,C - 証明書のニックネームを使用してファイルに証明書を抽出します。たとえば、
user.crtという名前のファイルに Base64 形式の証明書を抽出するには以下を実行します。$
certutil -L -d /etc/pki/nssdb/ -n 'my_certificate' -r | base64 -w 0 > user.crtbase64ユーティリティーは coreutils パッケージに含まれます。
23.1.2. ユーザーアカウントのスマートカード証明書へのリンク
- 完全な証明書のブロブを使用する
- Identity Management ユーザーは、「証明書とユーザーアカウントの間のリンク作成」を参照してください。また、「証明書およびユーザーアカウントの間のリンクの削除」を使用してこのリンクを削除してください。
- Active Directory ユーザーは「Active Directory のユーザーアカウントとスマートカードのリンク」を参照してください。
- 証明書マッピングを使用する: 「アイデンティティーマッピングの設定」
23.1.2.1. 証明書とユーザーアカウントの間のリンク作成
コマンドライン: 証明書とユーザーアカウントの間のリンク作成
- Identity Management の管理者としてログインします。
$
kinit admin ipa user-add-certコマンドを使用してユーザーアカウントにスマートカード証明書を追加します。以下の例を示します。$
cat cert.pem | tail -n +2 | head -n -1 | tr -d '\r\n' | ipa user-add-cert idm_user
Web UI: 証明書とユーザーアカウントの間のリンク作成
- → を選択し、対象のユーザーアカウントをクリックします。
- Certificates エントリーの横にある をクリックして証明書を入力します。
- ユーザーアカウントページの上部にある をクリックします。
その他のリソース
- 外部の証明局 (CA) が発行する証明書の追加と削除に関する詳細は、「外部 CA 発行の証明書の管理」を参照します。
23.1.2.2. 証明書およびユーザーアカウントの間のリンクの削除
コマンドライン: 証明書とユーザーアカウントの間のリンク作成
- Identity Management の管理者としてログインします。
$
kinit admin - 必要なユーザーアカウントを検索します。
$
ipa user-show idm_userUser login: idm_user First name: first_name Last name: last_name ... Certificate: MIIC3... - アカウントから証明書を削除します。
$
ipa user-remove-cert idm_user --certificate MIIC3...
Web UI: 証明書とユーザーアカウントの間のリンク削除
- → を選択し、対象のユーザーアカウントをクリックします。
- 削除する証明書の横にある をクリックして、 を選択します。
その他のリソース
23.1.2.3. Active Directory のユーザーアカウントとスマートカードのリンク
コマンドライン: Active Directory のユーザーアカウントとスマートカードのリンク
- Identity Management の管理者としてログインします。
$
kinit admin - ユーザー証明書の環境変数 (
CERT) を作成します。$
CERT=`cat cert.pem | tail -n +2 | head -n -1 | tr -d '\r\n'` - 新規 ID オーバーライドを作成してし、ユーザー証明書を ID ビューに追加します。以下の手順では、Default Trust View を使用しています。
$
ipa idoverrideuser-add 'Default Trust View' ad_user@ad.example.com --certificate $CERT
Web UI: Active Directory のユーザーアカウントとスマートカードのリンク
- → を選択し、必要な ID ビューをクリックします。
- 新規 ID オーバーライドを作成して、ユーザー証明書を ID ビューに追加します。 をクリックして、Add User ID override フォームで必要な情報を入力します。
その他のリソース
- ID ビューの管理に関する詳細は「18章ID ビュー」を参照してください。
- Default Trust View の詳細は「Active Directory 環境での ID ビューの使用」を参照してください。
23.1.2.4. アイデンティティーマッピングの設定
23.1.2.4.1. Identity Management でのアイデンティティーマッピング
- マッピングルール
- マッピングルールは、証明書を 1 つ以上のユーザーアカウントに関連付けます (または マッピングします)。このルールで、対象のユーザーアカウントと証明書を関連付ける LDAP 検索フィルターを定義します。発行した証明局 (CA) が違う証明書には、異なるプロパティーが設定されており、異なるドメインで使用される可能性があります。そのため、Identity Management は条件なしでマッピングルールを適用せず、適切な証明書にのみ適用します。照合ルール を使用して、適切な証明書を定義します。
- 照合ルール
- 照合ルールは、マッピングルールを適用する CA の証明書を選択します。
- ドメイン一覧
- ドメイン一覧は、アイデンティティーマッピングルールを処理する際に Identity Management がユーザーを検索する DNS ドメイン名を指定します。
注記
ドメインが指定されていない場合は、Identity Management により、クライアントが所属するローカルドメインのユーザーのみが検索されます。 - Priority
- 複数のルールが証明書に適用可能な場合には、最も優先順位の高いルールが先に適用され、他のルールはすべて無視されます。
- 数値が低いほど、アイデンティティーマッピングの優先度が高くなります。たとえば、優先度が 1 のルールは、2 のルールより優先順位が高くなります。
- ルールに優先順位の値が定義されていない場合には、優先順位が最も低くなります。
23.1.2.4.2. 証明書のアイデンティティーマッピングルールの作成
コマンドライン: 証明書のアイデンティティーマッピングルールの作成
- 管理者としてログインします。
$
kinit admin ipa certmaprule-addコマンドを使用してルールを作成します。アイデンティティーマッピングルールのコンポーネントを指定するには、以下のオプションを使用します。--mapruleはマッピングルールを定義します。--matchruleは照合ルールを定義します。--domainはユーザーエントリーを検索するドメインを定義します。--priorityはアイデンティティーマッピングルールの優先順位を定義します。
たとえば、マッピングルールと照合ルールのみで構成される単純なアイデンティティーマッピングルールを作成するには以下を実行します。$
ipa certmaprule-add rule_name --matchrule '<ISSUER>CN=Smart Card CA,O=EXAMPLE.ORG' --maprule '(ipacertmapdata=X509:<I>{issuer_dn!nss_x500}<S>{subject_dn!nss_x500})'------------------------------------------------------- Added Certificate Identity Mapping Rule "rule_name" ------------------------------------------------------- Rule name: rule_name Mapping rule: (ipacertmapdata=X509:<I>{issuer_dn!nss_x500}<S>{subject_dn!nss_x500}) Matching rule: <ISSUER>CN=Smart Card CA,O=EXAMPLE.ORG Enabled: TRUEこのルールは、スマートカード証明書の件名や発行者を、ユーザーアカウントのipacertmapdata属性の値とリンクします。
Web UI: 証明書のアイデンティティーマッピングルールの作成
- → を選択します。
- をクリックします。
- ルールのコンポーネントの情報を入力して を追加します。
その他のリソース
- 証明書マッピングおよび照合ルールの構文に関する詳細は sss-certmap(5) man ページを参照してください。
ipa certmaprule-addコマンドの使用方法に関する情報は--helpオプションを指定してコマンドを実行してください。- アイデンティティーマッピングの管理に関する他のコマンドは、
ipa help certmapコマンドを使用します。
23.1.2.4.3. ユーザーアカウントとスマートカード証明書のリンク
ipacertmapdata 属性に証明書の件名と発行者を保存します。
コマンドライン: ユーザーアカウントとスマートカード証明書のリンク
- 証明書にアクセスできる場合には、完全な証明書のブロブを使用します。
$
CERT=`cat cert.pem | tail -n +2| head -n -1 | tr -d '\r\n'`$ipa user-add-certmapdata idm_user --certificate $CERT-------------------------------------------- Added certificate mappings to user "idm_user" -------------------------------------------- User login: idm_user Certificate mapping data: X509:<I>O=EXAMPLE.ORG,CN=Smart Card CA<S>CN=test,O=EXAMPLE.ORG - 証明書にアクセスできるが件名と発行者が分かっている場合には
--subjectおよび--issuerオプションを使用します。$
ipa user-add-certmapdata idm_user --subject "O=EXAMPLE.ORG,CN=test" --issuer "CN=Smart Card CA,O=EXAMPLE.ORG"-------------------------------------------- Added certificate mappings to user "idm_user" -------------------------------------------- User login: idm_user Certificate mapping data: X509:<I>O=EXAMPLE.ORG,CN=Smart Card CA<S>CN=test,O=EXAMPLE.ORG - マッピングの形式に精通している場合には、マッピングデータを直接指定してください。
$
ipa user-add-certmapdata idm_user 'X509:<I>O=EXAMPLE.ORG,CN=Smart Card CA<S>CN=test,O=EXAMPLE.ORG'-------------------------------------------- Added certificate mappings to user "idm_user" -------------------------------------------- User login: idm_user Certificate mapping data: X509:<I>O=EXAMPLE.ORG,CN=Smart Card CA<S>CN=test,O=EXAMPLE.ORG
Web UI: ユーザーアカウントとスマートカード証明書のリンク
- → をクリックして、対象のユーザーログインをクリックします。
- Certificate mapping data エントリーの横にある をクリックします。

図23.1 証明書マッピングデータの追加
- Add Certificate Mapping Data フォームで、必要な情報を入力します。以下のいずれかを指定します。
- Certificate で完全な証明書ブロブを指定します。
- Issuer and subject で件名と発行者を指定します。
- Certificate mapping data でマッピングデータを直接指定します。
その他のリソース
ipa user-add-certmapdataコマンドの詳細は--helpオプションを指定してコマンドを実行してください。
23.1.2.4.4. アイデンティティーマッピングルールの例
例23.1 Identity Management ユーザーの Active Directory の証明書
$ipa certmaprule-add ad_cert_for_ipa_users \--maprule='(ipacertmapdata=X509:<I>{issuer_dn!nss_x500}<S>{subject_dn!nss_x500})' \--matchrule='<ISSUER>CN=AD-ROOT-CA,DC=ad,DC=example,DC=com' \--domain=idm.example.com
例23.2 Active Directory ユーザーの Active Directory 証明書
$ipa certmaprule-add ad_cert_for_ad_users \--maprule='(altSecurityIdentities=X509:<I>{issuer_dn!ad_x500}<S>{subject_dn!ad_x500})' \--matchrule='<ISSUER>CN=AD-ROOT-CA,DC=ad,DC=example,DC=com' \--domain=ad.example.com
例23.3 Identity Management と Active Directory ユーザー両方の Active Directory 証明書
$ipa certmaprule-add ad_cert_for_ipa_and_ad_users \--maprule='(|(ipacertmapdata=X509:<I>{issuer_dn!nss_x500}<S>{subject_dn!nss_x500})(altSecurityIdentities=X509:<I>{issuer_dn!ad_x500}<S>{subject_dn!ad_x500}))' \--matchrule='<ISSUER>CN=AD-ROOT-CA,DC=ad,DC=example,DC=com' \--domain=ad.example.com
--maprule オプションの絞り込み定義には以下の条件が含まれます。
ipacertmapdata=X509:<I>{issuer_dn!nss_x500}<S>{subject_dn!nss_x500}は、スマートカード証明書の件名および発行者と、Identity Management ユーザーアカウントのipacertmapdata属性値をリンクするフィルターです。altSecurityIdentities=X509:<I>{issuer_dn!ad_x500}<S>{subject_dn!ad_x500}は、スマートカード証明書の件名および発行者と Active Directory ユーザーアカウントのaltSecurityIdentities属性値をリンクするフィルターです。
--maprule オプションのフィルター定義では、論理演算子 | (or) が使用できるので、複数の条件を指定できます。今回の場合、このルールは 1 つ以上の条件を満たす全ユーザーアカウントをマッピングします。
例23.4 Identity Management および Active Directory ユーザーの Identity Management 証明書
$ipa certmaprule-add ipa_cert_for_ad_users \--maprule='(|(userCertificate;binary={cert!bin})(ipacertmapdata=X509:<I>{issuer_dn!nss_x500}<S>{subject_dn!nss_x500})(altSecurityIdentities=X509:<I>{issuer_dn!ad_x500}<S>{subject_dn!ad_x500}))' \--matchrule='<ISSUER>CN=Certificate Authority,O=REALM.EXAMPLE.COM' \--domain=idm.example.com --domain=ad.example.com
--maprule オプションの絞り込み定義には以下の条件が含まれます。
userCertificate;binary={cert!bin}は、Identity Management または Active Directory のユーザーエントリー (全証明書を含む) を返すフィルターです。ipacertmapdata=X509:<I>{issuer_dn!nss_x500}<S>{subject_dn!nss_x500}は、スマートカード証明書の件名および発行者と、Identity Management ユーザーアカウントのipacertmapdata属性値をリンクするフィルターです。altSecurityIdentities=X509:<I>{issuer_dn!ad_x500}<S>{subject_dn!ad_x500}は、スマートカード証明書の件名および発行者と Active Directory ユーザーアカウントのaltSecurityIdentities属性値をリンクするフィルターです。
--maprule オプションのフィルター定義では、論理演算子 | (or) が使用できるので、複数の条件を指定できます。今回の場合、このルールは 1 つ以上の条件を満たす全ユーザーアカウントをマッピングします。
23.1.2.4.5. 証明書の発行者を照合ルールに変換する例
例23.5 Identity Management が発行する証明書の発行者の変換
# openssl x509 -in user.crt -noout -issuer
issuer= /O=REALM.EXAMPLE.COM/CN=Certificate Authority'<ISSUER>CN=Certificate Authority,O=REALM.EXAMPLE.COM'
例23.6 メールを含む証明書の発行者の変換
# openssl x509 -in expired_user.pem -noout -issuer
issuer= /C=US/ST=North Carolina/L=Raleigh/O=Red Hat/OU=QE/CN=ExampleCA/emailAddress=admin@example.com'<ISSUER>emailAddress=admin@example.com,CN=ExampleCA,OU=QE,O=Red Hat,L=Raleigh,ST=North Carolina,C=US'
23.1.2.5. その他のリソース
- スマートカードの証明書のリンクを検証するには「指定の証明書と合致するユーザーの検索」を参照してください。
- 証明書のアイデンティティーマッピングに関する詳しい情報は、アップストリームの SSSD ドキュメントの「Matching and Mapping Certificates」を参照してください。
23.1.3. 指定の証明書と合致するユーザーの検索
コマンドライン: 指定の証明書と合致するユーザーの検索
- 管理者としてログインします。
$
kinit admin - ユーザーを検索するには、以下のいずれかを指定します。
- 証明書ファイルの名前:
$
ipa certmap-match cert.pem-------------- 1 user matched -------------- Domain: IDM.EXAMPLE.COM User logins: idm_user ---------------------------- Number of entries returned 1 ---------------------------- - 証明書の内容:
$
ipa certmap-match --certificate="MII...."-------------- 1 user matched -------------- Domain: IDM.EXAMPLE.COM User logins: idm_user ---------------------------- Number of entries returned 1 ----------------------------ユーザーエントリーに完全な証明書のブロブが含まれる場合には、このコマンドは、信頼される Active Directory ドメインでユーザーも返します。$
ipa certmap-match --certificate="MII...."--------------- 2 users matched --------------- Domain: ad.domain.com User logins: ad_user Domain: IDM.EXAMPLE.COM User logins: idm_user ---------------------------- Number of entries returned 2 ----------------------------
Web UI: 指定の証明書と合致するユーザーの検索
- → → をクリックします。
- Certificate フィールドの証明書の内容を入力して をクリックします。Identity Management は、Matched Users に証明書と合致するユーザーを表示します。

図23.2 証明書と合致するユーザーの表示
その他のリソース
- 証明書のアイデンティティーマッピングのコマンドに関する詳細は、
ipa help certmapコマンドを使用します。 ipa certmap-matchコマンドの詳細は--helpオプションを指定してコマンドを実行してください。
23.1.4. その他のリソース
- Red Hat Certificate System のアプリケーション、Enterprise Security Client を使用して個人の証明書やキーを管理する情報は、Certificate System ドキュメントの「Managing Smart Cards with the Enterprise Security Client」を参照してください。
23.2. スマートカードで Identity Management クライアントへ認証する方法
23.2.1. Identity Management クライアントでサポートされるスマートカード認証オプション
- ローカル認証
- ローカル認証には、以下を使用した認証が含まれます。
- テキストコンソール
- Gnome Display Manager (GDM) などのグラフィカルコンソール
suまたはsudoなどのローカル認証サービス
sshでのリモート認証- スマートカードの証明書は、PIN で保護される SSH の秘密鍵と合わせて保存されます。
23.2.2. スマートカード認証に向けた Identity Management の準備
- サーバーで、shell スクリプトを作成してクライアントを設定します。
ipa-advise config-client-for-smart-card-authコマンドを使用して出力をファイルに保存します。#
ipa-advise config-client-for-smart-card-auth > client_smart_card_script.sh- スクリプトファイルを開き、内容を確認します。
chmodユーティリティーを使用して実行パーミッションをファイルに追加します。#
chmod +x client_smart_card_script.sh
- スクリプトをクライアントにコピーして実行します。スマートカード証明書を署名した認証局 (CA) を含む PEM ファイルへのパスを追加します。
#
./client_smart_card_script.sh CA_cert.pem
- Identity Management サーバーで CA 証明書をインストールします。
#
ipa-cacert-manage -n "SmartCard CA" -t CT,C,C install ca.pem#ipa-certupdateすべてのレプリカおよびクライアントでもipa-certupdateを繰り返します。 - HTTP サーバーを再起動します。
#
systemctl restart httpdすべてのレプリカでもsystemctl restart httpdを実行します。
注記
certificate_verification パラメーターで証明書の検証プロセスを調節できます。たとえば、証明書に定義されている Online Certificate Status Protocol (OCSP) サーバーは、クライアントから到達できません。詳しい情報は sssd.conf(5) の man ページを参照してください。
23.2.3. コンソールログインを使用してスマートカードで Identity Management クライアントへ認証する方法
- コマンドラインからログインする場合:
client login: idm_user PIN for PIV Card Holder pin (PIV_II) for user idm_user@idm.example.com:
- Gnome Desktop Manager (GDM) を使用してログインすると、GDM により、所定のユーザー名を選択した後にスマートカードと PIN が求められます。

図23.3 Gnome Desktop Manager でのスマートカードの PIN の入力
AD.EXAMPLE.COM\ad_user または ad_user@AD.EXAMPLE.COM など、NetBIOS ドメイン名を使用する形式でユーザー名を入力します。
23.2.4. SSH を使用してスマートカードで Identity Management クライアントへ認証する方法
ssh ユーティリティーを使用する場合に、スマートカードのレンダリングモジュールへのパスを指定します。以下に例を示します。
$ ssh -I /usr/lib/libmypkcs11.so -l user@example.com host.example.com
Enter PIN for 'Smart Card':23.2.5. その他のリソース
- OpenSSH でのスマートカード認証の詳細は、『セキュリティーガイド』の「OpenSSH に認証情報を提供するスマートカードの使用」を参照してください。
23.3. スマートカードを使用してリモートで Identity Management システムに対する認証を行う方法
ssh ユーティリティーを使用して (Identity Management ドメインに登録されていない) ローカルシステムから (Identity Management ドメインに登録されている) リモートシステムにスマートカードで認証を行うことができます。これにより、選択したロールでリモートシステムを使用できるようになります。
23.3.1. スマートカード認証用のローカルシステムの準備
- opensc パッケージをインストールします。
#
yum install opensc - スマートカードデーモンの
pcscdサービスが起動され、有効であることを確認します。#
systemctl start pcscd.socket pcscd.service#systemctl enable pcscd.socket pcscd.service
- Identity Management サーバーで CA 証明書をインストールします。
#
ipa-cacert-manage -n "SmartCard CA" -t CT,C,C install ca.pem#ipa-certupdateすべてのレプリカおよびクライアントでもipa-certupdateを繰り返します。 - Identity Management サーバーの HTTP サーバーを再起動します。
#
systemctl restart httpdすべてのレプリカでもsystemctl restart httpdを実行します。
23.3.2. スマートカード認証用のリモートの Identity Management システムの準備
- リモートシステム上の
/etc/pki/nssdb/データベースにスマートカード証明局 (CA) の証明書をインストールします。#
certutil -A -d /etc/pki/nssdb/ -n "SmartCard CA" -t CT,C,C -i ca.pem - sssd-dbus パッケージがインストールされていることを確認します。
23.3.3. Active Directory のユーザーエントリーとスマートカード証明書のリンク
23.3.4. ローカルシステムからリモートシステムへの認証
- スマートカードを挿入します。
sshを起動して-Iオプションで PKCS#11 ライブラリーを指定します。- Identity Management ユーザーとして以下を実行します。
$
ssh -I /usr/lib64/opensc-pkcs11.so -l idm_user server.idm.example.comEnter PIN for 'PIV_II (PIV Card Holder pin)': Last login: Thu Apr 6 12:49:32 2017 from 10.36.116.42 - Active Directory ユーザーとして以下を実行します。
$
ssh -I /usr/lib64/opensc-pkcs11.so -l ad_user@ad.example.com server.idm.example.comEnter PIN for 'PIV_II (PIV Card Holder pin)': Last login: Thu Apr 6 12:49:32 2017 from 10.36.116.42
- オプション:
idユーティリティーを使用して所定のユーザーとしてログインしていることを確認します。- Identity Management ユーザーとして以下を実行します。
$
iduid=1928200001(idm_user) gid=1928200001(idm_user) groups=1928200001(idm_user) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 - Active Directory ユーザーとして以下を実行します。
$
iduid=1171201116(ad_user@ad.example.com) gid=1171201116(ad_user@ad.example.com) groups=1171201116(ad_user@ad.example.com),1171200513(domain users@ad.example.com) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
23.3.5. その他のリソース
sshを使用してスマートカードで認証を行うと、リモートシステムの TGT (Ticket Granting Ticket) は取得されません。リモートシステムで TGT を取得するには、管理者はローカルシステムに Kerberos を設定して、Kerberos の委譲を有効化する必要があります。所定の設定例は、「this Kerberos knowledge base entry」を参照してください。- OpenSSH でのスマートカード認証の詳細は、『セキュリティーガイド』の「OpenSSH に認証情報を提供するスマートカードの使用」を参照してください。
23.4. スマートカード認証のユーザー名ヒントのポリシー設定
23.4.1. Identity Management でのユーザー名のヒント
- ユーザー名ヒントポリシーが有効な場合には、ユーザーはユーザー名を求められ、認証に進むことができます。
- ユーザー名品とポリシーが無効な場合には、プロンプトが表示されず、認証に失敗します。

図23.4 Gnome Desktop Manager でのユーザー名のヒント
- Identity Management の Web UI 認証。GUI で
Usernameフィールドが常に表示されるため。 ssh認証。sshは現在のユーザーのログイン名または-lオプションやusername@host形式で指定される名前を使用するため。- コンソールの認証。ログイン名を常に指定するため。
23.4.2. Identity Management でのユーザー名ヒントの有効化
コマンドライン: Identity Management でのユーザー名ヒントの有効化
- Identity Management の管理者としてログインします。
$
kinit adminPassword for admin@IDM.EXAMPLE.COM: --promptusername=Trueオプションを指定してipa certmapconfig-modコマンドを使用して、ユーザー名ヒントを有効にします。$
ipa certmapconfig-mod --promptusername=TRUEPrompt for the username: TRUEユーザー名ヒントを無効にするには--promptusername=Falseオプションを使用します。
Web UI: Identity Management でのユーザー名ヒントの有効化
- → → をクリックします。
- Prompt for the username を選択し、 をクリックします。

図23.5 Web UI でのユーザー名ヒントの有効化
その他のリソース
ipa certmapconfig-modコマンドに関する詳細は、--helpオプションを指定して実行します。
23.5. Identity Management での PKINIT スマートカード認証
23.5.1. PKINIT 認証に向けた Identity Management クライアントの準備
- サーバーで、shell スクリプトを作成してクライアントを設定します。
ipa-advise config-client-for-smart-card-authコマンドを使用して出力をファイルに保存します。#
ipa-advise config-client-for-smart-card-auth > client_smart_card_script.sh- スクリプトファイルを開き、内容を確認します。
chmodユーティリティーを使用して実行パーミッションをファイルに追加します。#
chmod +x client_smart_card_script.sh
- スクリプトをクライアントにコピーして実行します。スマートカード証明書を署名した認証局 (CA) を含む PEM ファイルへのパスを追加します。
# ./client_smart_card_script.sh CA_cert.pem
- krb5-pkinit パッケージがインストールされていることを確認します。
- Identity Management サーバーで CA 証明書をインストールします。
#
ipa-cacert-manage -n "SmartCard CA" -t CT,C,C install ca.pem#ipa-certupdateすべてのレプリカおよびクライアントでもipa-certupdateを繰り返します。 - HTTP サーバーを再起動します。
#
systemctl restart httpdすべてのレプリカでもsystemctl restart httpdを実行します。
注記
certificate_verification パラメーターで証明書の検証プロセスを調節できます。たとえば、証明書に定義されている Online Certificate Status Protocol (OCSP) サーバーは、クライアントから到達できません。詳しい情報は sssd.conf(5) の man ページを参照してください。
23.5.2. Identity Management ユーザー: Identity Management クライアントでの PKINIT を使用した認証
kinit ユーティリティーを使用した認証:
$ kinit -X X509_user_identity='PKCS11:opensc-pkcs11.so' idm_user-X オプションは、事前認証の属性として opensc-pkcs11.so モジュールを指定します。詳しい情報は、kinit(1) の man ページを参照してください。
23.5.3. Active Directory ユーザー: Identity Management クライアントでの PKINIT を使用した認証
前提条件
- Active Directory サーバーが、スマートカード証明書を発行する認証局 (CA) を信頼するように設定します。NTAuth ストアに CA をインポートして (Microsoft サポート を参照)、信頼された CA として CA を追加します。詳細は Active Directory ドキュメントを参照してください。
- スマートカード証明書を発行する CA を信頼するように Kerberos クライアントを設定します。
- Identity Management クライアントで
/etc/krb5.confファイルを開きます。 - ファイルに以下の行を追加します。
[libdefaults] [... file truncated ...] pkinit_eku_checking = kpServerAuth pkinit_kdc_hostname = adserver.ad.domain.com
- ユーザー証明書に、証明書失効リスト (CRL: Certificate Revocation List) の Distribution Point Extension が含まれていない場合には、Active Directory が失効エラーを無視するように設定します。
- 以下の REG 形式の内容をプレーンテキストファイルに保存して、ファイルをダブルクリックして Windows レジストリーにインポートします。
Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Kdc] "UseCachedCRLOnlyAndIgnoreRevocationUnknownErrors"=dword:00000001 [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA\Kerberos\Parameters] "UseCachedCRLOnlyAndIgnoreRevocationUnknownErrors"=dword:00000001
または、regedit.exeアプリケーションを使用して手動で値を設定します。 - Windows システムを再起動して変更を適用します。
手順
kinit ユーティリティーを使用して認証し、ユーザーとドメイン名で Active Directory ユーザーを指定します。
$ kinit -X X509_user_identity='PKCS11:opensc-pkcs11.so' ad_user@ad.domain.com-X オプションは、事前認証の属性として opensc-pkcs11.so モジュールを指定します。詳しい情報は、kinit(1) の man ページを参照してください。
23.6. スマートカードを使用して Identity Management Web UI への認証を行う方法
注記
23.6.1. Web UI でのスマートカード認証に向けた Identity Management サーバーの準備
- Identity Management サーバーで、shell スクリプトを作成してサーバーを設定します。
ipa-advise config-server-for-smart-card-authコマンドを使用して出力をファイルに保存します。#
ipa-advise config-server-for-smart-card-auth > server_smart_card_script.sh- スクリプトファイルを開き、内容を確認します。
chmodユーティリティーを使用して実行パーミッションをファイルに追加します。#
chmod +x server_smart_card_script.sh
- Identity Management ドメインの全サーバー上でスクリプトを実行します。
- sssd-dbus パッケージがインストールされていることを確認します。
- Identity Management サーバーで、CA 証明書を、HTTP サーバーが使用する NSS データベースに追加します。
#
ipa-cacert-manage -n "SmartCard CA" -t CT,C,C install ca.pem#ipa-certupdateすべてのレプリカおよびクライアントでもipa-certupdateを繰り返します。 - HTTP サーバーと Kerberos サーバーを再起動します。
#
systemctl restart httpd#systemctl restart krb5kdcすべてのレプリカでこのコマンドを繰り返し実行します。
23.6.2. スマートカード認証用のブラウザーの準備
- Firefox を起動します。
- スマートカードから証明書が読み取られるように Firefox を設定します。
- → → → → を選択します。

図23.6 Firefox でのセキュリティーデバイスの設定
- をクリックします。Load PKCS#11 Device ウィンドウで以下の情報を入力します。
- Module Name:
OpenSC - Module filename:
/usr/lib64/opensc-pkcs11.so

図23.7 Firefox のデバイスマネージャー
- をクリックして確定してから、再度 をクリックしてデバイスマネージャーを終了します。
23.6.3. Identity Management ユーザーとしてスマートカードを使用して Identity Management Web UI への認証を行う方法
- スマートカードをスマートカードリーダーに挿入します。
- ブラウザーで Identity Management Web UI (
https://ipaserver.example.com/ipa/ui) に移動します。 - スマートカード証明書が単一のユーザーアカウントにリンクされている場合には、Username フィールドには入力しないでください。スマートカード証明書が複数のユーザーアカウントにリンクされている場合には Username フィールドに入力して所定のアカウントにを指定します。
- をクリックします。

図23.8 Identity Management Web UI の
- プロンプトが表示されたらスマートカードの情報を入力します。

図23.9 スマートカード PIN の入力
- 新しいウィンドウが開き、使用する証明書を提示するように求められます。スマートカード証明書を選択します。

図23.10 スマートカード証明書の選択
その他のリソース
- 認証が失敗した場合には、「スマートカード認証の失敗」を参照してください。
23.6.4. その他のリソース
- Identity Management の Web UI の詳細は「IdM Web UI」を参照してください。
23.7. Web アプリケーションと Identity Management のスマートカード認証の統合
23.7.1. スマートカードでの Web アプリケーション認証における前提条件
- Identity Management ドメインのクライアントとしてサーバーを登録します。
- sssd-dbus および mod_lookup_identity パッケージをインストールします。
- Apache に、
mod_nssモジュールを使用して、機能する HTTPS 接続が設定されていることを確認します。
23.7.2. Web アプリケーション向けの Identity Management スマートカード認証の設定
/etc/httpd/conf.d/nss.confファイルのmod_nss設定で TLS ネゴシエーションを有効化します。NSSRenegotiation NSSRequireSafeNegotiation on
- ユーザー証明書を発行する CA が
mod_nss証明書データベースのクライアント証明書向けに信頼されていることを確認します。データベースのデフォルトの場所は/etc/httpd/aliasです。 - Web アプリケーションを追加します。この手順では、ログインページおよび保護エリアだけが含まれる最小限のアプリケーションを例として使用します。
/loginエンドポイントでは、ユーザーはユーザー名のみが指定でき、アプリケーションの保護エリアに送信されます。/appエンドポイントはREMOTE_USER環境変数をチェックします。ログインが成功すると、変数にはログインユーザーの ID が含まれます。ログインに成功しなかった場合には、変数は設定されません。
- ディレクトリーを作成して、グループを
apacheに、モードを最低でも750に設定します。この手順では、/var/www/app/という名前のディレクトリーを使用します。 - ファイルを作成して、グループを
apacheに、モードを最低でも750に設定します。この手順では、/var/www/app/login.pyという名前のファイルを使用します。以下の内容をファイルに保存します。#! /usr/bin/env python def application(environ, start_response): status = '200 OK' response_body = """ <!DOCTYPE html> <html> <head> <title>Login</title> </head> <body> <form action='/app' method='get'> Username: <input type='text' name='username'> <input type='submit' value='Login with certificate'> </form> </body> </html> """ response_headers = [ ('Content-Type', 'text/html'), ('Content-Length', str(len(response_body))) ] start_response(status, response_headers) return [response_body] - ファイルを作成して、グループを
apacheに、モードを最低でも750に設定します。この手順では、/var/www/app/protected.pyという名前のファイルを使用します。以下の内容をファイルに保存します。#! /usr/bin/env python def application(environ, start_response): try: user = environ['REMOTE_USER'] except KeyError: status = '400 Bad Request' response_body = 'Login failed.\n' else: status = '200 OK' response_body = 'Login succeeded. Username: {}\n'.format(user) response_headers = [ ('Content-Type', 'text/plain'), ('Content-Length', str(len(response_body))) ] start_response(status, response_headers) return [response_body] - アプリケーション用の設定ファイルを作成します。この手順では、
/etc/httpd/conf.d/app.confという名前のファイルを使用し、以下のコンテンツを追加します。<IfModule !lookup_identity_module> LoadModule lookup_identity_module modules/mod_lookup_identity.so </IfModule> WSGIScriptAlias /login /var/www/app/login.py WSGIScriptAlias /app /var/www/app/protected.py <Location "/app"> NSSVerifyClient require NSSUserName SSL_CLIENT_CERT LookupUserByCertificate On LookupUserByCertificateParamName "username" </Location>このファイルでは、以下が設定されます。- 最初の部分では、すでに読み込まれていない場合には
mod_lookup_identityを読み込みます。 - 次の部分では
/loginおよび/appエンドポイントを適切な Web Server Gateway Interface (WSGI) スクリプトにマッピングします。 - 最後の部分では、TLS ハンドシェーク時にクライアントの証明書が必要でそれを使用できるように
/appエンドポイントのmod_nssを設定します。さらに、オプションの要求パラメーターusernameがユーザーの ID を検索するように設定します。
第24章 ユーザー、ホスト、およびサービス向け証明書の管理
- 統合 IdM CA
- 統合 CA は、ユーザー、ホスト、およびサービス向けの証明書を作成、取り消し、発行することができます。詳細は 「統合 IdM CA での証明書の管理」 を参照してください。IdM 軽量サブ CA の作成に対応しています。詳細は 「軽量のサブ証明局 (CA)」 を参照してください。
- 外部 CA
- 外部 CA は、統合 IdM CA 以外の CA です。IdM ツールを使ってこの CA が発行した証明書をユーザー、サービス、またはホストに追加したり削除したりします。詳細は 「外部 CA 発行の証明書の管理」 を参照してください。
注記
24.1. 統合 IdM CA での証明書の管理
24.1.1. ユーザー、ホスト、またはサービス向けの新規証明書のリクエスト
- IdM Web UI を使用の場合、「Web UI: 新規証明書のリクエスト」
- コマンドラインを使用の場合、「コマンドライン: 新規証明書のリクエスト」
certutil および openSSL のユーティリティーを使用しています。
重要
Web UI: 新規証明書のリクエスト
- Identity タブを開き、Users、Hosts、または Services のサブタブを選択します。
- 設定を開くユーザー、ホスト、またはサービス名をクリックします。

図24.1 ホストの一覧
- → をクリックします。
- オプションで発行元となる CA とプロファイル ID を選択します。
- 画面の指示に従って
certutilを使用します。 - をクリックします。
コマンドライン: 新規証明書のリクエスト
certutil を使用して新規証明書をリクエストする方法については、「certutil を使用した新規証明書のリクエスト」 を参照してください。openSSL を使用して新規証明書をリクエストし、Kerberos エイリアスがホストまたはサービス証明書を使用できるようにする方法については、「openSSL を使用した新規証明書のリクエスト」 を参照してください。
24.1.1.1. certutil を使用した新規証明書のリクエスト
- 以下のように、新規の一時証明書データベースを作成します。
# certutil -N -d ~/certdb/
- 証明書署名リクエスト (CSR) を作成し、出力をファイルにリダイレクトします。たとえば、4096 ビットの証明書向け CSR を作成して、サブジェクトを CN=server.example.com,O=EXAMPLE.COM に設定するには、以下を実行します。
# certutil -R -d ~/certdb/ -a -g 4096 -s "CN=server.example.com,O=EXAMPLE.COM" -8 server.example.com > certificate_request.csr
- 証明書リクエストをサーバーに送信します。新規発行の証明書に関連付けるための Kerberos プリンシパルを必ず指定してください。
# ipa cert-request certificate_request.csr --principal=host/server.example.com
- 証明書のプロファイル:
caIPAserviceCertカスタムのプロファイルを選択する場合は、--profile-idオプションをipa cert-requestコマンドと使用します。 - 統合 CA:
ipa(IdM root CA)サブ CA を選択する場合は、--caオプションをipa cert-requestコマンドと使用します。
24.1.1.2. openSSL を使用した新規証明書のリクエスト
- Kerberos プリンシパル test/server.example.com 向けに、test1/server.example.com や test2/server.example.com と言ったエイリアスを作成します。詳細は 「Kerberos プリンシパルのエイリアス」 を参照してください。
- CSR で dnsName (server.example.com) および otherName (test2/server.example.com) 向けに subjectAltName を追加します。これを実行するには、
openssl.confファイルを編集して、UPN otherName と subjectAltName を指定する以下の行を含めます。otherName=1.3.6.1.4.1.311.20.2.3;UTF8:test2/server.example.com@EXAMPLE.COM DNS.1 = server.example.com
opensslを使用して証明書リクエストを作成します。openssl req -new -newkey rsa:2048 -keyout test2service.key -sha256 -nodes -out certificate_request.csr -config openssl.conf
24.1.2. 統合 IdM CA での証明書の取り消し
- IdM Web UI を使用の場合、「Web UI: 証明書の取り消し」
- コマンドラインを使用の場合、「コマンドライン: 証明書の取り消し」
表24.1 取り消しの理由
| ID | 理由 | 説明 |
|---|---|---|
| 0 | 原因不明 | |
| 1 | キーのセキュリティー侵害 |
証明書を発行したキーが信頼できません。
考えられる原因: トークンの損失、ファイルへの不適切なアクセス。
|
| 2 | 認証局のセキュリティー侵害 | 証明書を発行した CA が信頼できません。 |
| 3 | 所属の変更 |
考えられる原因:
|
| 4 | 交代 | 現行の証明書が新しい証明書に置き換えられています。 |
| 5 | 運用の停止 | ホストまたはサービスが使用停止になっています。 |
| 6 | 証明書の保留 | 証明書が一時的に取り消されています。証明書は後で復元させることができます。 |
| 8 | CRL から削除 | 証明書が、証明書取り消し一覧 (CRL) に含まれていません。 |
| 9 | 特権の撤回 | ユーザー、ホスト、またはサービスによる証明書の使用が許可されなくなりました。 |
| 10 | 属性証明局 (AA) のセキュリティー侵害 | AA 証明書が信頼できません。 |
Web UI: 証明書の取り消し
- Authentication タブを開き Certificates サブタブを選択します。
- 情報ページを開く証明書のシリアル番号をクリックします。

図24.2 証明書一覧
- → をクリックします。
- 取り消し理由を選択して をクリックします。理由については、表24.1「取り消しの理由」 を参照してください。
コマンドライン: 証明書の取り消し
ipa cert-revoke コマンドで以下を指定します。
- 証明書のシリアル番号
- 取り消し理由を特定する番号。理由については、表24.1「取り消しの理由」 を参照してください。
1032 で、理由が「1: キーのセキュリティー侵害」である場合、以下を実行します。
$ ipa cert-revoke 1032 --revocation-reason=1
24.1.3. 統合 IdM CA での証明書の復元
- IdM Web UI を使用の場合、「Web UI: 証明書の復元」
- コマンドラインを使用の場合、「コマンドライン: 証明書の復元」
Web UI: 証明書の復元
- Authentication タブを開き Certificates サブタブを選択します。
- 情報ページを開く証明書のシリアル番号をクリックします。

図24.3 証明書一覧
- → をクリックします。
コマンドライン: 証明書の復元
ipa cert-remove-hold コマンドで証明書のシリアル番号を指定します。
$ ipa cert-remove-hold 1032
24.2. 外部 CA 発行の証明書の管理
24.2.1. コマンドライン: 外部 CA 発行の証明書の追加および削除
ipa user-add-certipa host-add-certipa service-add-cert
ipa user-remove-certipa host-remove-certipa service-remove-cert
- ユーザー、ホスト、またはサービスの名前
- Base64 でエンコードされた認証情報
$ ipa user-add-cert user --certificate=MIQTPrajQAwg...
注記
user_cert.pem 証明書を user に追加するには、以下を実行します。
$ ipa user-add-cert user --certificate="$(openssl x509 -outform der -in user_cert.pem | base64 -w 0)"
24.2.2. Web UI: 外部 CA 発行の証明書の追加および削除
- Identity タブを開き、Users、Hosts、または Services のサブタブを選択します。
- 設定を開くユーザー、ホスト、またはサービス名をクリックします。
- Certificates エントリーの横にある をクリックします。

図24.4 ユーザーアカウントへの証明書の追加
- Base64 または PEM エンコード形式で証明書をテキストフィールドに貼り付け、 をクリックします。
- ボタンをクリックして、変更を保存します。
- Identity タブを開き、Users、Hosts、または Services のサブタブを選択します。
- 設定を開くユーザー、ホスト、またはサービス名をクリックします。
- 削除する証明書の横にある をクリックして、 を選択します。
- ボタンをクリックして、変更を保存します。
24.3. 証明書の一覧と表示
Web UI での証明書の一覧と表示
- Identity タブを開き、Users、Hosts、または Services のサブタブを選択します。
- 設定を開くユーザー、ホスト、またはサービス名をクリックします。

図24.5 ホストの一覧
- 設定ページでエントリーに割り当てられた証明書がすべて一覧表示されます。また、 をクリックすると特定の証明書が表示されます。
- Authentication タブを開き Certificates サブタブを選択します。
- Certificates セクションに全証明書が一覧表示されます。表示する証明書のシリアル番号をクリックします。

図24.6 証明書一覧
コマンドラインからの証明書の一覧表示
ipa cert-find コマンドを実行します。
$ ipa cert-find ----------------------- 10 certificates matched ----------------------- Serial number (hex): 0x1 Serial number: 1 Status: VALID Subject: CN=Certificate Authority,O=EXAMPLE.COM ... ----------------------------- Number of entries returned 10 -----------------------------
--issuedon-from および --issuedon-to のオプションを使用して開始日と終了日や一定期間を指定します。
ipa cert-find --issuedon-from=2017-01-07 --issuedon-to=2017-02-07
ipa cert-find に --help オプションを付けて実行します。
コマンドラインからの証明書の表示
ipa cert-show コマンドでシリアル番号を指定して実行します。
$ ipa cert-show 132 Serial number: 132 Certificate: MIIDtzCCAp+gAwIBAgIBATANBgkqhkiG9w0BAQsFADBBMR8wHQYDVQQKExZMQUIu ... LxIQjrEFtJmoBGb/TWRlwGEWy1ayr4iTEf1ayZ+RGNylLalEAtk9RLjEjg== Subject: CN=Certificate Authority,O=EXAMPLE.COM Issuer: CN=Certificate Authority,O=EXAMPLE.COM Not Before: Sun Jun 08 05:51:11 2014 UTC Not After: Thu Jun 08 05:51:11 2034 UTC Serial number (hex): 0x132 Serial number: 132
ipa cert-show でエントリーを指定します。たとえば、ユーザーに割り当てられた証明書を表示するには、以下を実行します。
$ ipa user-show user User login: user ... Certificate: MIICfzCCAWcCAQA... ...
--out オプションを ipa cert-show に追加すると、証明書をファイルに保存することもできます。
$ ipa cert-show certificate_serial_number --out=path_to_file
--out オプションではそれらすべてがエクスポートされます。証明書は、PEM オブジェクトとしてエクスポートされます。
24.4. 証明書のプロファイル
- CA が証明書署名リクエスト (CSR) を受け付けられるかどうか。
- 証明書にどの機能と拡張機能を記載するか。
caIPAserviceCert と IECUserRoles の 2 つの証明書プロファイルがあります。これに加えて、カスタムプロファイルをインポートすることもできます。
注記
24.4.1. コマンドラインからの証明書プロファイル管理
certprofile プラグインを使用すると、権限のあるユーザーは IdM 証明書プロファイルのインポート、修正、または削除ができるようになります。このプラグインがサポートするコマンドすべてを表示するには、ipa certprofile コマンドを実行します。
$ ipa certprofile
Manage Certificate Profiles
...
EXAMPLES:
Import a profile that will not store issued certificates:
ipa certprofile-import ShortLivedUserCert \
--file UserCert.profile --desc "User Certificates" \
--store=false
Delete a certificate profile:
ipa certprofile-del ShortLivedUserCert
...certprofile 操作を実行するには、必要なパーミッションがあるユーザーとして操作する必要があります。IdM にはデフォルトで以下の証明書プロファイル関連のパーミッションがあります。
- System: Read Certificate Profiles
- ユーザーが全プロファイル属性を読み込むことを許可します。
- System: Import Certificate Profile
- ユーザーが証明書プロファイルを IdM にインポートすることを許可します。
- System: Delete Certificate Profile
- ユーザーが既存の証明書プロファイルを削除することを許可します。
- System: Modify Certificate Profile
- ユーザーがプロファイル属性を修正し、プロファイルを有効化、無効化することを許可します。
CA Administrator 権限に含まれています。IdM のロールベースのアクセス制御およびパーミッションの管理についての詳細は、「ロールベースのアクセス制御の定義」 を参照してください。
注記
--profile-id オプションを ipa cert-request コマンドに追加して使用するプロファイルを指定することができます。プロファイル ID が指定されない場合は、デフォルトの caIPAserviceCert プロファイルが使用されます。
ipa certprofile コマンドを使用してプロファイルを管理する重要な側面のみを説明しています。このコマンドに関する完全な情報については、以下のように --help オプションを追加して実行してください。
$ ipa certprofile-mod --help Usage: ipa [global-options] certprofile-mod ID [options] Modify Certificate Profile configuration. Options: -h, --help show this help message and exit --desc=STR Brief description of this profile --store=BOOL Whether to store certs issued using this profile ...
証明書プロファイルのインポート
ipa certprofile-import コマンドを使用します。このコマンドをオプションなしで実行すると対話型セッションが開始され、certprofile-import スクリプトが証明書のインポートに必要な情報を要求します。
$ ipa certprofile-import Profile ID: smime Profile description: S/MIME certificates Store issued certificates [True]: TRUE Filename of a raw profile. The XML format is not supported.: smime.cfg ------------------------ Imported profile "smime" ------------------------ Profile ID: smime Profile description: S/MIME certificates Store issued certificates: TRUE
ipa certprofile-import コマンドは以下のようなオプションを取ります。
--file- このオプションは、プロファイル設定を含むファイルを直接
ipa certprofile-importに渡します。$ ipa certprofile-import --file=smime.cfg
--store- このオプションは
Store issued certificates属性を設定します。以下の 2 つの値を受け付けます。True。この場合、発行された証明書がクライアントに配布され、ターゲットの IdM プリンシパルのuserCertificate属性に保存されます。False。この場合、発行された証明書がクライアントに配布されますが、IdM には保存されません。このオプションは、複数の短期証明書を発行する際によく使用されます。
ipa certprofile-import で指定されたプロファイル ID が既に使用されている場合、またはプロファイルコンテンツが正しくない場合は、インポートに失敗します。たとえば、必須の属性がない場合や、提供されたファイルで定義されているプロファイル ID が ipa certprofile-import で指定されたものと一致しない場合は、インポートに失敗します。
ipa certprofile-show コマンドを --out オプションと実行することで、指定された既存のプロファイルがファイルにエクスポートされます。例を示します。
$ ipa certprofile-show caIPAserviceCert --out=file_name
証明書プロファイルの表示
ipa certprofile-find コマンドを使用します。
$ ipa certprofile-find ------------------ 3 profiles matched ------------------ Profile ID: caIPAserviceCert Profile description: Standard profile for network services Store issued certificates: TRUE Profile ID: IECUserRoles ...
ipa certprofile-show コマンドを使用します。
$ ipa certprofile-show profile_ID Profile ID: profile_ID Profile description: S/MIME certificates Store issued certificates: TRUE
証明書プロファイルの修正
ipa certprofile-mod コマンドを使用します。ipa certprofile-mod にコマンドラインオプションで必要な修正を渡します。たとえば、プロファイルの内容を修正し、IdM が発行された証明書を保存するかどうかを変更するには、以下を実行します。
$ ipa certprofile-mod profile_ID --desc="New description" --store=False ------------------------------------ Modified Certificate Profile "profile_ID" ------------------------------------ Profile ID: profile_ID Profile description: New description Store issued certificates: FALSE
--file オプションを使用して更新された設定を含むファイルをインポートします。
$ ipa certprofile-mod profile_ID --file=new_configuration.cfg
証明書プロファイルの削除
ipa certprofile-del コマンドを使用します。
$ ipa certprofile-del profile_ID ----------------------- Deleted profile "profile_ID" -----------------------
24.4.2. Web UI からの証明書プロファイル管理
- Authentication タブを開き Certificates サブタブを選択します。
- Certificate Profiles セクションを開きます。

図24.7 Web UI での証明書プロファイル管理
- プロファイル名をクリックして、プロファイルの設定ページを開きます。
- 開いたページで必要な情報を入力します。
- をクリックして新規設定を保存します。

図24.8 Web UI での証明書プロファイルの修正
Store issued certificates オプションを有効にすると、発行された証明書はクライアントに配布されるほか、ターゲットの IdM プリンシパルの userCertificate 属性に保存されます。このオプションを無効にすると、発行された証明書はクライアントに配布されますが、IdM には保存されません。複数の短期証明書の発行が必要な際には、証明書の保存は無効にされることがよくあります。
- Web UI では証明書プロファイルのインポートができません。証明書をインポートするには、
ipa certprofile-importコマンドを使用します。 - 属性と値のペアを設定、追加、または削除することができません。このペアを修正する場合は、
ipa certprofile-modコマンドを使用します。 - 更新された証明書プロファイルの設定をインポートすることはできません。これを実行するには、
ipa certprofile-mod --file=file_nameコマンドを使用します。
24.4.3. 証明書プロファイルのある IdM サーバーのアップグレード
24.5. 証明局の ACL ルール
- ACL は複数プロファイルへのアクセスを許可します
- ACL では複数のユーザー、サービス、ホスト、ユーザーグループ、およびホストグループに関連付けができます
注記
24.5.1. コマンドラインからの CA ACL 管理
caacl プラグインを使用すると、権限のあるユーザーは指定された CA ACL の追加、表示、修正、または削除ができるようになります。このプラグインがサポートするコマンドすべてを表示するには、ipa caacl コマンドを実行します。
$ ipa caacl
Manage CA ACL rules.
...
EXAMPLES:
Create a CA ACL "test" that grants all users access to the
"UserCert" profile:
ipa caacl-add test --usercat=all
ipa caacl-add-profile test --certprofiles UserCert
Display the properties of a named CA ACL:
ipa caacl-show test
Create a CA ACL to let user "alice" use the "DNP3" profile on "DNP3-CA":
ipa caacl-add alice_dnp3
ipa caacl-add-ca alice_dnp3 --cas DNP3-CA
ipa caacl-add-profile alice_dnp3 --certprofiles DNP3
ipa caacl-add-user alice_dnp3 --user=alice
...caacl 操作を実行するには、必要なパーミッションがあるユーザーとして操作する必要があります。IdM にはデフォルトで以下の CA ACL 関連のパーミッションがあります。
- System: Read CA ACLs
- ユーザーが CA ACL の属性すべてを読み込むことを許可します。
- System: Add CA ACL
- ユーザーが新規 CA ACL を追加することを許可します。
- System: Delete CA ACL
- ユーザーが既存の CA ACL を削除することを許可します。
- System: Modify CA ACL
- ユーザーが CA ACL 属性を修正し、CA ACL を有効化、無効化することを許可します。
- System: Manage CA ACL membership
- ユーザーが CA ACL 内の CA、プロファイル、ユーザー、ホスト、およびサービスメンバーシップを管理することを許可します。
CA Administrator 権限に含まれています。IdM のロールベースのアクセス制御およびパーミッションの管理についての詳細は、「ロールベースのアクセス制御の定義」 を参照してください。
ipa caacl コマンドを使用して CA ACL を管理する重要な側面のみを説明しています。このコマンドに関する完全な情報については、以下のように --help オプションを追加して実行してください。
$ ipa caacl-mod --help Usage: ipa [global-options] caacl-mod NAME [options] Modify a CA ACL. Options: -h, --help show this help message and exit --desc=STR Description --cacat=['all'] CA category the ACL applies to --profilecat=['all'] Profile category the ACL applies to ...
CA ACL の作成
ipa caacl-add コマンドを使用します。このコマンドをオプションなしで実行すると対話型セッションが開始され、ipa caacl-add スクリプトが新規 CA ACL について必要な情報を要求します。
$ ipa caacl-add ACL name: smime_acl ------------------------ Added CA ACL "smime_acl" ------------------------ ACL name: smime_acl Enabled: TRUE
ipa caacl-add で使用可能なオプションのうち重要なものは、CA ACL を CA、証明書プロファイル、ユーザー、ホスト、またはサービスカテゴリーと関連付けるものです。
--cacat--profilecat--usercat--hostcat--servicecat
all の値のみを受け付けます。これは、CA ACL をすべての CA、プロファイル、ユーザー、ホスト、またはサービスと関連付けます。たとえば、CA ACL を全ユーザーおよびユーザーグループと関連付けるには、以下を実行します。
$ ipa caacl-add ca_acl_name --usercat=all
--usercat=all オプションを使った後に、ipa caacl-add-user --users=user_name コマンドでユーザーを CA ACL に追加することはできません。
注記
$ ipa cert-request CSR-FILE --principal user --profile-id profile_id ipa: ERROR Insufficient access: Principal 'user' is not permitted to use CA '.' with profile 'profile_id' for certificate issuance.
all ユーザーカテゴリーに関連付ける必要があります。
CA ACL の表示
ipa caacl-find コマンドを使用します。
$ ipa caacl-find ----------------- 2 CA ACLs matched ----------------- ACL name: hosts_services_caIPAserviceCert Enabled: TRUE ...
ipa caacl-find コマンドでは --cacat、--profilecat、--usercat、--hostcat、および --servicecat のオプションを使用して、これらに対応する CA、証明書プロファイル、ユーザー、ホスト、またはサービスカテゴリーがある CA ACL に検索結果を絞り込むことができます。ただし、IdM ではこれらのオプションで all カテゴリーしか受け付けないことに注意してください。これらのオプションについての詳細は、「CA ACL の作成」 を参照してください。
ipa caacl-show コマンドを実行します。
$ ipa caacl-show ca_acl_name ACL name: ca_acl_name Enabled: TRUE Host category: all ...
CA ACL の修正
ipa caacl-mod コマンドを使用します。ipa caacl-mod にコマンドラインオプションで必要な修正を渡します。たとえば、CA ACL の記述内容を修正し、その CA ACL を全証明書プロファイルに関連付けるには、以下を実行します。
$ ipa caacl-mod ca_acl_name --desc="New description" --profilecat=all --------------------------- Modified CA ACL "ca_acl_name" --------------------------- ACL name: smime_acl Description: New description Enabled: TRUE Profile category: all
ipa caacl-mod コマンドで使用できる重要なオプションは、--cacat、--profilecat、--usercat、--hostcat、および --servicecat です。これらのオプションについての説明は、「CA ACL の作成」 を参照してください。
CA ACL の有効化および無効化
ipa caacl-disable コマンドを使用します。
$ ipa caacl-disable ca_acl_name --------------------------- Disabled CA ACL "ca_acl_name" ---------------------------
ipa caacl-enable コマンドを使用します。
$ ipa caacl-enable ca_acl_name --------------------------- Enabled CA ACL "ca_acl_name" ---------------------------
CA ACL の削除
ipa caacl-del コマンドを使用します。
$ ipa caacl-del ca_acl_name
CA ACL へのエントリー追加と CA ACL からのエントリー削除
ipa caacl-add-* と ipa caacl-remove-* コマンドを使用することで、それぞれ CA ACL に新規エントリーを追加したり、既存のエントリーを削除することができます。
ipa caacl-add-caとipa caacl-remove-ca- CA を追加または削除します。
ipa caacl-add-hostとipa caacl-remove-host- ホストもしくはホストグループを追加または削除します。
ipa caacl-add-profileとipa caacl-remove-profile- プロファイルを追加または削除します。
ipa caacl-add-serviceとipa caacl-remove-service- サービスを追加または削除します。
ipa caacl-add-userとipa caacl-remove-user- ユーザーもしくはグループを追加または削除します。
$ ipa caacl-add-user ca_acl_name --groups=group_name
ipa caacl-add-user --users=user_name コマンドを --usercat=all オプションで指定した CA ACL で実行しようとすると、これは失敗します。
$ ipa caacl-add-user ca_acl_name --users=user_name ipa: ERROR: users cannot be added when user category='all'
注記
$ ipa cert-request CSR-FILE --principal user --profile-id profile_id ipa: ERROR Insufficient access: Principal 'user' is not permitted to use CA '.' with profile 'profile_id' for certificate issuance.
all ユーザーカテゴリーに関連付ける必要があります。
--help を追加して実行してください。
$ ipa caacl-add-user --help
24.5.2. Web UI での CA ACL 管理
- Authentication タブを開き Certificates サブタブを選択します。
- CA ACLs セクションを開きます。

図24.9 Web UI での CA ACL ルールの管理
- CA ACL 名をクリックして、CA ACL の設定ページを開きます。
- 開いたページで必要な情報を入力します。Profiles と Permitted to have certificates issued のセクションでは、CA ACL を証明書プロファイル、ユーザーまたはユーザーグループ、ホストまたはホストグループ、もしくはサービスに関連付けることができます。 ボタンでこれらのオブジェクトを追加するか、Anyone オプションを選択して CA ACL を全ユーザー、ホスト、またはサービスに関連付けます。
- をクリックして新規設定を保存します。

図24.10 Web UI での CA ACL ルールの修正
24.6. IdM CA での証明書プロファイルおよび ACL を使用したユーザー証明書の発行
コマンドラインからのユーザーへの証明書発行
- ユーザー証明書のリクエストを処理する新規のカスタム証明書プロファイルを作成またはインポートします。例を示します。
$ ipa certprofile-import certificate_profile --file=certificate_profile.cfg --store=True
- ユーザーエントリーの証明書のリクエストを許可するために使用される新規の証明局 (CA) ACL を追加します。
$ ipa caacl-add users_certificate_profile --usercat=all
- カスタム証明書プロファイルを CA ACL に追加します。
$ ipa caacl-add-profile users_certificate_profile --certprofiles=certificate_profile
- ユーザー用の証明書リクエストを生成します。以下の例では、OpenSSL を使用します。
$ openssl req -new -newkey rsa:2048 -days 365 -nodes -keyout private.key -out cert.csr -subj '/CN=user'
ipa cert-requestコマンドを実行して、IdM CA がユーザー用の新規証明書を発行するようにします。$ ipa cert-request cert.csr --principal=user --profile-id=certificate_profile
--ca sub-CA_nameオプションを渡すと、root CAipaではなく、sub-CA からの証明書をリクエストすることもできます。
ipa user-show コマンドを実行します。
$ ipa user-show user
User login: user
...
Certificate: MIICfzCCAWcCAQA...
...Web UI でのユーザーへの証明書発行
- ユーザー証明書のリクエストを処理する新規のカスタム証明書プロファイルを作成またはインポートします。プロファイルのインポートは、コマンドラインからしかできません。例を示します。
$ ipa certprofile-import certificate_profile --file=certificate_profile.txt --store=True
証明書プロファイルについての詳細は、「証明書のプロファイル」 を参照してください。 - Web UI の Authentication タブで、CA ACLs セクションを開きます。

図24.11 Web UI での CA ACL ルールの管理
CA ACL リスト上部にある をクリックして、ユーザーエントリー用の証明書リクエストを許可する新規 CA ACL を追加します。- Add CA ACL ウィンドウが開くので、新規 CA ACL についての必要な情報を入力します。

図24.12 新規 CA ACL の追加
をクリックして、CA ACL の設定ページに移動します。 - CA ACL 設定ページで Profiles セクションまでスクロールし、プロファイル一覧上部にある をクリックします。

図24.13 CA ACL への証明書プロファイルの追加
- プロファイルを選択して Prospective コラムに移動し、カスタム証明書プロファイルを CA ACL に追加します。

図24.14 証明書プロファイルの選択
をクリックします。 - Permitted to have certificates issued セクションまでスクロールします。CA ACL をユーザーもしくはユーザーグループに関連付けます。ボタンでユーザーもしくはグループを追加するか、Anyone オプションを選択して CA ACL を全ユーザーに関連付けます。

図24.15 ユーザーの CA ACL への追加
- Permitted to have certificates issued セクションでは、CA ACL を 1 つ以上の CA に関連付けることができます。ボタンで CA を追加するか、Any CA オプションを選択して CA ACL を全 CA に関連付けることができます。

図24.16 CA を CA ACL に追加する
- CA ACL 設定ページ上部にある をクリックして、CA ACL の変更を保存します。
- ユーザー用の新規証明書をリクエストします。
- Identity タブにある Users サブタブで、リクエストする証明書を必要とするユーザーを選択します。ユーザー名をクリックして、ユーザーエントリーの選択ページを開きます。
- 設定ページ上部にある をクリックしてから New Certificate をクリックします。

図24.17 ユーザー用証明書のリクエスト
- 必要な情報を入力します。

図24.18 ユーザー用証明書の発行
最後に をクリックします。
第25章 Vault を使用した認証情報の秘密の保存
- パスワード
- PIN
- プライベート SSH キー
注記
- ユーザーの個人秘密の保存
- 詳細は 「ユーザー個人の秘密の保存」 を参照してください。
- サービスの秘密の保存
- 詳細は 「Vault でのサービスの秘密の保存」 を参照してください。
- 複数ユーザーが使用する共通の秘密の保存
- 詳細は 「複数ユーザー用の共通の秘密の保存」 を参照してください。
25.1. Vault の仕組み
25.1.1. Vault の所有者、メンバー、および管理者
- Vault 所有者
- vault 所有者とは、vault の基本的な管理権限があるユーザーもしくはサービスです。たとえば、vault 所有者は vault プロパティーを変更したり、新規の vault メンバーを追加することができます。各 vault には最低 1 人の所有者が必要ですが、複数の所有者がいても構いません。
- Vault メンバー
- vault メンバーとは、別のユーザーやサービスが作成した vault にアクセスできるユーザーまたはサービスです。
- Vault 管理者
- Vault 管理者にはすべての vault に対する無制限のアクセスがあり、vault の全操作が許可されます。
注記
対称および非対称 vault はパスワードかキーで保護されており、特別なアクセス制御ルールを適用します (「標準、対称、および非対称 Vault」 を参照)。管理者は以下を実行するためにこれらのルールに合致する必要があります。- 対称および非対称 vault にある秘密へのアクセス
- vault パスワードまたはキーの変更もしくはリセット
vault 管理者とは、Vault Administrators権限のあるユーザーのことです。ユーザー権限の定義に関する情報は、「ロールベースのアクセス制御の定義」 を参照してください。
Vault ユーザー
ipa vault-show などのコマンド出力では、ユーザー vaults の Vault user も表示されます。
$ ipa vault-show my_vault
Vault name: my_vault
Type: standard
Owner users: user
Vault user: user25.1.2. 標準、対称、および非対称 Vault
- 標準 vault
- Vault 所有者と vault メンバーは、パスワードやキーなしで秘密をアーカイブおよび取得することができます。
- 対称 vault
- この vault の秘密は、対称キーで保護されます。Vault メンバーと vault 所有者は秘密のアーカイブと取得ができますが、vault パスワードを使用する必要があります。
- 非対称 vault
- この vault の秘密は、非対称キーで保護されます。ユーザーは公開キーを使って秘密をアーカイブし、プライベートキーを使って秘密を取得します。vault メンバーは秘密のアーカイブしかできませんが、vault 所有者はアーカイブと取得の両方ができます。
25.1.4. Vault コンテナー
- ユーザーコンテナー: ユーザーのプライベートコンテナー
- このコンテナーには、特定ユーザーのユーザー vault が保存されます。
- サービスコンテナー: サービスのプライベートコンテナー
- このコンテナーには、特定サービスのサービス vault が保存されます。
- 共有コンテナー
- このコンテナーには、複数のユーザーやサービスが共有可能な vault が保存されます。
25.2. Vault 使用における前提条件
# ipa-kra-install
25.3. Vault コマンドのヘルプ
$ ipa help vault
--help オプションを加えて実行します。
$ ipa vault-add --help
Vault コマンドで vault not found エラーが出て失敗する場合
--userまたは--serviceで、表示する vault の所有者を指定します。$ ipa vault-show user_vault --user user
--sharedは、表示する vault が共有 vault であることを指定します。
--user を追加せずに表示使用とすると、IdM は vault が見つからないと返します。
[admin@server ~]$ ipa vault-show user_vault ipa: ERROR: user_vault: vault not found
25.4. ユーザー個人の秘密の保存
userとは、vault を作成するユーザーです。my_vaultとは、ユーザーの証明書を保存するための vault です。- vault タイプは
standardで、アーカイブ化された証明書にアクセスする際にユーザーは vault パスワードが必要ありません。 secret.txtとは、ユーザーが vault に保存する証明書を格納しているファイルです。secret_exported.txtとは、アーカイブ化された証明書のエクスポート先となるファイルです。
25.4.1. ユーザー個人の秘密のアーカイブ化
userとしてログインします。$ kinit user
ipa vault-addコマンドを使って標準 vault を作成します。$ ipa vault-add my_vault --type standard ---------------------- Added vault "my_vault" ---------------------- Vault name: my_vault Type: standard Owner users: user Vault user: user
ipa vault-archive --inコマンドを使ってsecret.txtファイルを vault にアーカイブします。$ ipa vault-archive my_vault --in secret.txt ----------------------------------- Archived data into vault "my_vault" -----------------------------------
注記
各 Vault が保存できるのは、シークレット 1 つのみです。
25.4.2. ユーザー個人の秘密の取得
userとしてログインします。$ kinit user
ipa vault-retrieve --outコマンドを使って vault のコンテンツを取得し、それをsecret_exported.txtファイルに保存します。$ ipa vault-retrieve my_vault --out secret_exported.txt -------------------------------------- Retrieved data from vault "my_vault" --------------------------------------
25.5. Vault でのサービスの秘密の保存
adminとは、サービスのパスワードを管理する管理者です。http_passwordとは、管理者が作成しユーザーのプライベート vault の名前です。password.txtとは、サービスのパスワードを格納しているファイルです。password_vaultとは、サービス用に作成された vault です。HTTP/server.example.comとは、そのパスワードがアーカイブ化されるサービスです。service-public.pemとは、password_vaultに保存されているパスワードの暗号化に使用するサービスの公開キーです。
25.5.1. サービスのパスワードを保存するユーザー Vault の作成
- 管理者としてログインします。
$ kinit admin
- 標準のユーザー vault を作成します。
$ ipa vault-add http_password --type standard --------------------------- Added vault "http_password" --------------------------- Vault name: http_password Type: standard Owner users: admin Vault user: admin
- サービスパスワードを vault にアーカイブします。
$ ipa vault-archive http_password --in password.txt ---------------------------------------- Archived data into vault "http_password" ----------------------------------------
警告
パスワードを vault にアーカイブした後、システムからpassword.txtを削除します。
25.5.2. ユーザー Vault からサービスインスタンスへのサービスパスワードの提供
- 管理者としてログインします。
$ kinit admin
- サービスインスタンスの公開キーを取得します。たとえば、以下のように
opensslユーティリティーを使用します。service-private.pemプライベートキーを生成します。$ openssl genrsa -out service-private.pem 2048 Generating RSA private key, 2048 bit long modulus .+++ ...........................................+++ e is 65537 (0x10001)
- このプライベートキーを基に、
service-public.pem公開キーを生成します。$ openssl rsa -in service-private.pem -out service-public.pem -pubout writing RSA key
- サービスインスタンスの vault として非対称 vault を作成し、公開キーを提供します。
$ ipa vault-add password_vault --service HTTP/server.example.com --type asymmetric --public-key-file service-public.pem ---------------------------- Added vault "password_vault" ---------------------------- Vault name: password_vault Type: asymmetric Public key: LS0tLS1C...S0tLS0tCg== Owner users: admin Vault service: HTTP/server.example.com@EXAMPLE.COM
vault にアーカイブ化されたパスワードは、キーで保護されます。 - 管理者のプライベート vault からサービスパスワードを取得し、これを新規サービスの vault にアーカイブします。
$ ipa vault-retrieve http_password --out password.txt ----------------------------------------- Retrieved data from vault "http_password" -----------------------------------------$ ipa vault-archive password_vault --service HTTP/server.example.com --in password.txt ----------------------------------- Archived data into vault "password_vault" -----------------------------------これでパスワードは、サービスインスタンスの公開キーで暗号化されます。警告
パスワードを vault にアーカイブした後、システムからpassword.txtを削除します。
25.5.3. サービスインスタンス用のサービスパスワードの取得
- 管理者としてログインします。
$ kinit admin
- サービス用の Kerberos チケットを取得します。
# kinit HTTP/server.example.com -k -t /etc/httpd/conf/ipa.keytab
- サービス vault のパスワードを取得します。
$ ipa vault-retrieve password_vault --service HTTP/server.example.com --private-key-file service-private.pem --out password.txt ------------------------------------ Retrieved data from vault "password_vault" ------------------------------------
25.5.4. サービス Vault のパスワード変更
- 管理者のユーザー vault に新規パスワードをアーカイブします。
$ ipa vault-archive http_password --in new_password.txt ---------------------------------------- Archived data into vault "http_password" ----------------------------------------
これで vault に保存されている現行パスワードが上書きされます。 - セキュリティーが侵害されたインスタンス以外の各サービスインスタンスに新規パスワードを再提供します。
- 管理者の vault から新規パスワードを取得します。
$ ipa vault-retrieve http_password --out password.txt ----------------------------------------- Retrieved data from vault "http_password" -----------------------------------------
- 新規パスワードをサービスインスタンスの vault にアーカイブします。
$ ipa vault-archive password_vault --service HTTP/server.example.com --in password.txt ----------------------------------- Archived data into vault "password_vault" -----------------------------------
警告
パスワードを vault にアーカイブした後、システムからpassword.txtを削除します。
第26章 証明書と認証局の管理
26.1. 軽量のサブ証明局 (CA)
ipa CA が証明書システムのルート CA になります。作成するサブ CA はすべて、このルート CA に従属します。
26.1.1. 軽量のサブ証明局 (CA) の作成
Web UI からのサブ CA の作成
- Authentication タブを開き Certificates サブタブを選択します。
- Certificate Authorities タブを選択します。 をクリックします。
- CA の名前とサブジェクト DN を入力します。

図26.1 CA の追加
サブジェクト DN は、IdM CA インフラストラクチャーで一意でなければなりません。
コマンドラインからのサブ CA の作成
[root@ipaserver ~]# ipa ca-add vpn-ca --subject="CN=VPN,O=IDM.EXAMPLE.COM" ------------------- Created CA "vpn-ca" ------------------- Name: vpn-ca Authority ID: ba83f324-5e50-4114-b109-acca05d6f1dc Subject DN: CN=VPN,O=IDM.EXAMPLE.COM Issuer DN: CN=Certificate Authority,O=IDM.EXAMPLE.COM
- Name
- CA の名前
- 認証局の ID
- CA 用に自動的に作成される個別 ID
- サブジェクト DN
- サブジェクトの識別名 (DN)。IdM CA インフラストラクチャーで一意でなければなりません。
- 発行者 DN
- サブ CA の証明書を発行した親 CA。サブ CA はすべて IdM ルート CA の子として作成されます。
[root@ipaserver ~]# certutil -d /etc/pki/pki-tomcat/alias/ -L
Certificate Nickname Trust Attributes
SSL,S/MIME,JAR/XPI
caSigningCert cert-pki-ca CTu,Cu,Cu
Server-Cert cert-pki-ca u,u,u
auditSigningCert cert-pki-ca u,u,Pu
caSigningCert cert-pki-ca ba83f324-5e50-4114-b109-acca05d6f1dc u,u,u
ocspSigningCert cert-pki-ca u,u,u
subsystemCert cert-pki-ca u,u,u注記
26.1.2. 軽量のサブ CA の削除
Web UI からの サブ CA の削除
- Authentication タブを開き Certificates サブタブを選択します。
- Certificate Authorities を選択します。
- 削除するサブ CA を選択して をクリックします。
- をクリックして確定します。
コマンドラインからのサブ CA の削除
[root@ipaserver ~]# ipa ca-del vpn-ca ------------------- Deleted CA "vpn-ca" -------------------
26.2. 証明書の更新
- 証明書の自動更新は「証明書の自動更新」を参照してください。
- 証明書の手動更新は「手動での CA 証明書の更新」を参照してください。
26.2.1. 証明書の自動更新
certmonger サービスは、期限が切れる 28 日前に、以下の証明書を自動的に更新します。
- ルート CA として IdM CA が発行した CA 証明書
- 内部 IdM サービスが使用する統合 IdM CA により発行されたサブシステムおよびサーバー証明書
certmonger のトラッキング一覧に追加されている必要があります。トラッキング一覧を更新するには、以下を実行します。
[root@ipaserver ~]# ipa-certupdate trying https://idmserver.idm.example.com/ipa/json Forwarding 'schema' to json server 'https://idmserver.idm.example.com/ipa/json' trying https://idmserver.idm.example.com/ipa/json Forwarding 'ca_is_enabled' to json server 'https://idmserver.idm.example.com/ipa/json' Forwarding 'ca_find/1' to json server 'https://idmserver.idm.example.com/ipa/json' Systemwide CA database updated. Systemwide CA database updated. The ipa-certupdate command was successful
注記
certmonger サービスは、外部 CA が署名した証明書を自動的に更新できません。
/var/log/messages ファイルで certmonger のログメッセージを検証します。
- 証明書が更新されたら、
certmongerには更新操作の成功または失敗を示す、以下のようなメッセージが記録されます。Certificate named "NSS Certificate DB" in token "auditSigningCert cert-pki-ca" in database "/var/lib/pki-ca/alias" renew success - 証明書の有効期限が近づくと
certmongerは以下のメッセージをログに記録します。certmonger: Certificate named "NSS Certificate DB" in token "auditSigningCert cert-pki-ca" in database "/var/lib/pki-ca/alias" will not be valid after 20160204065136.
26.2.2. 手動での CA 証明書の更新
ipa-cacert-manage を使用することができます。
- 自己署名の IdM CA 証明書
- 外部署名の IdM CA 証明書
ipa-cacert-manage renew コマンドで更新された証明書は、以前の証明書と同じキーペアおよびサブジェクト名を使用します。証明書を更新しても、証明書のロールオーバーができるように、以前のバージョンは削除されません。
26.2.2.1. 自己署名の IdM CA 証明書の手動更新
ipa-cacert-manage renewコマンドを実行します。証明書へのパスの指定は求められません。- 更新済み証明書が LDAP 証明書ストアと
/etc/pki/pki-tomcat/aliasNSS データベースに現れます。 - 全サーバーおよびクライアントで
ipa-certupdateユーティリティーを実行して、LDAP からの新規証明書に関する情報でクライアントを更新します。全サーバーおよびクライアントで個別にipa-certupdateを実行する必要があります。重要
証明書を手動でインストールした後にipa-certupdateを必ず実行します。実行しない場合には、証明書が他のマシンに配信されません。
certutil ユーティリティーを使用して、データベース内の証明書を表示します。以下に例を示します。
# certutil -L -d /etc/pki/pki-tomcat/alias
26.2.2.2. 外部署名の IdM CA 証明書の手動更新
ipa-cacert-manage renew --external-caコマンドを実行します。- このコマンドでは
/var/lib/ipa/ca.crtCSR ファイルを作成します。CSR を外部 CA に送信して、更新した CA 証明書を発行します。 - もう一度
ipa-cacert-manage renewを実行し、今度は更新した認証局証明書と外部認証局の証明書チェーンファイルを--external-cert-fileオプションを使って指定します。以下に例を示します。# ipa-cacert-manage renew --external-cert-file=/tmp/servercert20110601.pem --external-cert-file=/tmp/cacert.pem
- これで更新した認証局証明書と外部認証局のチェーンが LDAP 証明書ストア内と
/etc/pki/pki-tomcat/alias/NSS データベースに表示されるようになります。 - 全サーバーおよびクライアントで
ipa-certupdateユーティリティーを実行して、LDAP からの新規証明書に関する情報でクライアントを更新します。全サーバーおよびクライアントで個別にipa-certupdateを実行する必要があります。重要
証明書を手動でインストールした後にipa-certupdateを必ず実行します。実行しない場合には、証明書が他のマシンに配信されません。
certutil ユーティリティーを使用して、データベース内の証明書を表示します。以下に例を示します。
# certutil -L -d /etc/pki/pki-tomcat/alias/
26.3. CA 証明書の手動インストール
ipa-cacert-manage install コマンドを使用します。たとえば、このコマンドでは、有効期限に近づくと現在の証明書を変更できるようになります。
ipa-cacert-manage installコマンドを実行して、証明書を含んでいるファイルへのパスを指定します。このコマンドは PEM 形式の証明書ファイルを受け付けます。[root@server ~]# ipa-cacert-manage install /etc/group/cert.pem
これで証明書が LDAP 証明書ストアに置かれました。- 全サーバーおよびクライアントで
ipa-certupdateユーティリティーを実行して、LDAP からの新規証明書に関する情報でクライアントを更新します。全サーバーおよびクライアントで個別にipa-certupdateを実行する必要があります。重要
証明書を手動でインストールした後にipa-certupdateを必ず実行します。実行しない場合には、証明書が他のマシンに配信されません。
ipa-cacert-manage install コマンドは、以下のオプションを取ります。
- -n
- これは証明書のニックネームを提供します。デフォルト値は、証明書のサブジェクト名になります。
- -t
- これは、
certutil形式で証明書の信頼フラグを指定します。デフォルト値は、C,,です。信頼フラグを指定する形式についての情報は、ipa-cacert-manage(1) man ページを参照してください。
26.4. 証明書チェーンの変更
ipa-cacert-manage renew を使用して CA を更新します。
- 自己署名の CA 証明書 → 外部署名の CA 証明書
--external-caオプションをipa-cacert-manage renewコマンドに追加します。これにより、自己署名の CA 証明書を外部署名の CA 証明書に更新します。このオプションを使用したコマンドの詳細は、「手動での CA 証明書の更新」を参照してください。- 外部 CA 証明書 → 自己署名 CA 証明書
--self-signedオプションをipa-cacert-manage renewに追加します。これにより、外部署名の CA 証明書を自己署名の CA 証明書に更新します。
26.5. IdM を有効期限の切れた証明書で起動できるようにする方法
- Apache、Kerberos、DNS および LDAP サービスは継続して機能します。これらのサービスがアクティブな場合は、ユーザーは IdM ドメインにログインできます。
- アクセスに SSL が必要なクライアントサービスが依然として失敗します。たとえば、IdM クライアントで SSSD が必要で、SSSD は IdM に問い合わせるには SSL が必要であるため
sudoに失敗します。
重要
- Apache サーバーの
mod_nssが有効な証明書を強制的に有効化しないように設定します。/etc/httpd/conf.d/nss.confファイルを開きます。NSSEnforceValidCertsパラメーターをoffに設定します。NSSEnforceValidCerts off
- Apache を再起動します。
# systemctl restart httpd.service
- LDAP ディレクトリーサーバーの有効性チェックが無効になっていることを確認します。これには、
nsslapd-validate-cert属性がwarnに設定されていることを確認します。# ldapsearch -h server.example.com -p 389 -D "cn=directory manager" -w secret -LLL -b cn=config -s base "(objectclass=*)" nsslapd-validate-cert dn: cn=config nsslapd-validate-cert: warn
属性がwarnに設定されていない場合には、変更してください。# ldapmodify -D "cn=directory manager" -w secret -p 389 -h server.example.com dn: cn=config changetype: modify replace: nsslapd-validate-cert nsslapd-validate-cert: warn
- ディレクトリーサーバーを再起動します。
# systemctl restart dirsrv.target
26.6. HTTP または LDAP 用のサードパーティー証明書のインストール
- SSL 秘密鍵 (以下の手順の
ssl.key) - SSL 証明書 (以下の手順の
ssl.crt)
前提条件
ssl.crt 証明書は、証明書を読み込むサーバーが認識している CA で署名されている必要があります。そうでない場合には、「CA 証明書の手動インストール」の記載どおりにssl.crt を署名した CA の CA 証明書を IdM にインストールします。
ssl.crt を受け入れます。
サードパーティー証明書のインストール
ipa-server-certinstallユーティリティーを使用して、証明書をインストールします。インストール先を指定します。--httpは Apache Web サーバーに証明書をインストールします。--dirsrvは Directory Server に証明書をインストールします。
たとえば、SSL 証明書を両サーバーにインストールするには以下を実行します。# ipa-server-certinstall --http --dirsrv ssl.key ssl.crt
- サーバーが証明書のインストール先で立ち上がるように起動します。
- Apache Web サーバーの再起動
# systemctl restart httpd.service
- Directory Server の再起動
# systemctl restart dirsrv@REALM.service
- 証明書が正しくインストールされていることを確認するには、証明書のデータベースに証明書が存在していることを確認します。
- Apache 証明書データベースを表示します。
# certutil -L -d /etc/httpd/alias
- Directory Server 証明書データベースを表示します。
# certutil -L -d /etc/dirsrv/slapd-REALM/
26.7. OCSP 応答の設定
http://ca-server.example.com/ca/ocsp で入手できます。クライアントは、この URL に接続して証明書の有効性を確認できます。
注記
26.7.1. CRL 更新間隔の変更
- 認証局サーバーを停止します。
# systemctl stop pki-tomcatd@pki-tomcat.service
/var/lib/pki/pki-tomcat/conf/ca/CS.cfgファイルを開き、ca.crl.MasterCRL.autoUpdateIntervalの値を新しい間隔設定に変更します。たとえば、CRL を 60 分ごとに生成するには以下を実行します。ca.crl.MasterCRL.autoUpdateInterval=60
- CA サーバーを起動します。
# systemctl start pki-tomcatd@pki-tomcat.service
26.8. CA の既存の IdM ドメインへのインストール
注記
- IdM 証明書サーバー
- 以下のコマンドを使用して IdM 証明書サーバーの CA をインストールします。
[root@ipa-server ~] ipa-ca-install
- 全サーバーおよびクライアントで
ipa-certupdateユーティリティーを実行して、LDAP からの新規証明書に関する情報でクライアントを更新します。全サーバーおよびクライアントで個別にipa-certupdateを実行する必要があります。重要
証明書を手動でインストールした後にipa-certupdateを必ず実行します。実行しない場合には、証明書が他のマシンに配信されません。
- 外部 CA
- 外部 CA を後でインストールする際には、複数の手順を踏む必要があります。
- インストールを開始します。
[root@ipa-server ~] ipa-ca-install --external-ca
この手順を終えると、証明書署名要求 (CSR) が保存された旨の情報が表示されます。CSR を外部 CA に送信して、発行した証明書を IdM サーバーにコピーします。 - 証明書と外部 CA への完全なパスを
ipa-ca-installに渡して、インストールを続行します。[root@ipa-server ~]# ipa-ca-install --external-cert-file=/root/master.crt --external-cert-file=/root/ca.crt
- 全サーバーおよびクライアントで
ipa-certupdateユーティリティーを実行して、LDAP からの新規証明書に関する情報でクライアントを更新します。全サーバーおよびクライアントで個別にipa-certupdateを実行する必要があります。重要
証明書を手動でインストールした後にipa-certupdateを必ず実行します。実行しない場合には、証明書が他のマシンに配信されません。
26.9. Web サーバーおよび LDAP サーバーの証明書の置き換え
- 以下を使用して、新しい証明書を要求します。
- 統合 CA: 詳細は「ユーザー、ホスト、またはサービス向けの新規証明書のリクエスト」を参照してください。
- 外部 CA: 秘密鍵と証明書署名要求 (CSR) を生成します。以下の例では、OpenSSL を使用します。
$ openssl req -new -newkey rsa:2048 -days 365 -nodes -keyout new.key -out new.csr -subj '/CN=idmserver.idm.example.com,O=IDM.EXAMPLE.COM'
CSR を外部の CA に送信します。このプロセスは、外部 CA として使用するサービスにより異なります。
- Apache Web サーバーの秘密鍵と証明書を置き換えます。
[root@ipaserver ~]# ipa-server-certinstall -w --pin=password new.key new.crt
- LDAP サーバーの秘密鍵と証明書を置き換えます。
[root@ipaserver ~]# ipa-server-certinstall -d --pin=password new.key new.cert
パート VI. ポリシーの管理
第27章 パスワードポリシーの定義
27.1. パスワードポリシーのその役割
27.2. IdM におけるパスワードポリシー
注記
27.2.1. サポートされるパスワードポリシーの属性
表27.1 パスワードポリシーの属性
| 属性 | 説明 | 例 |
|---|---|---|
| Max lifetime | パスワードのリセットが必要になるまでの、パスワードの最長有効期間を日数単位で設定します。 |
Max lifetime = 90
ユーザーのパスワードは 90 日間有効です。この後は、IdM がパスワード変更をユーザーにプロンプトします。
|
| Min lifetime | 一旦パスワードを変更してから再度変更可能となるまでのパスワードの最小有効期間を時間単位で設定します。 |
Min lifetime = 1
ユーザーは一旦パスワードを変更すると、次に変更可能となるまで少なくとも 1 時間待つ必要があります。
|
| History size |
保存する以前のパスワード数を設定します。ユーザーは、パスワード履歴にあるパスワードは使用できません。
|
History size = 0
ユーザーは以前のいずれのパスワードも使用できます。
|
| Character classes | パスワードで使用する必要のある文字クラスの数。文字クラスとは、以下を指します。
同じ文字を 3 つ以上続けて使用すると、文字クラスの数は 1 つ減ることになります。たとえば、
|
Character classes = 0
デフォルトのクラス数は 0 です。この数字を設定するには、
ipa pwpolicy-mod コマンドを --minclasses オプションと実行します。このコマンドは、必須文字クラス数を 1 に設定します。
$ ipa pwpolicy-mod --minclasses=1本テーブル下の 重要 も参照してください。 |
| Min length | パスワードで使用する最低文字数 |
Min length = 8
8 文字未満のパスワードは使用できません。
|
| Max failures | 実行可能なログインの最大試行回数。失敗回数がこの値を超えた場合には、ユーザーアカウントがロックされます。「ログイン失敗後のユーザーアカウントのロック解除」 も参照してください。 |
Max failures = 6
ユーザーが 7 回連続で間違ったパスワードを入力すると、IdM はこのユーザーアカウントをロックします。
|
| Failure reset interval | 失敗したログイン試行回数を IdM がリセットするまでの時間を秒単位で設定します。 |
Failure reset interval = 60
Max failures で設定した回数のログイン試行に失敗した後に 1 分間以上待機すると、ユーザーはアカウントをロックすることなく再度ログイン試行することができます。
|
| Lockout duration | Max failures で定義された回数のログイン試行に失敗した後、ユーザーアカウントがロックされる時間を秒単位で設定します。「ログイン失敗後のユーザーアカウントのロック解除」 も参照してください。 |
Lockout duration = 600
ユーザーはアカウントがロックされると、10 分間ログインできません。
|
重要
27.2.2. グローバルおよびグループ固有ののパスワードポリシー
- グローバルパスワードポリシー
- 最初の IdM サーバーをインストールすると、自動的にグローバルパスワードポリシーがデフォルト設定で作成されます。グローバルポリシールールは、グループパスワードポリシーがない全ユーザーに適用されます。
- グループパスワードポリシー
- グループパスワードポリシーは、対応するユーザーグループの全メンバーに適用されます。
27.2.3. パスワードポリシーの優先度
0 です。
- 複数のパスワードポリシーがあるユーザーに適用可能な場合、優先度の値が最も低いポリシーが優先されます。他のポリシーで定義されているルールはすべて無視されます。
- 優先度の値が最も低いポリシーは、属性が定義されていないものでも、このポリシーが全パスワードポリシー属性に適用されます。
表27.2 優先度をベースにしたパスワードポリシー属性の適用例
| Max lifetime | Min length | |
|---|---|---|
| グループ A のポリシー (優先度 0) | 60 | 10 |
| グループ B のポリシー (優先度 1) | 90 | 0 (制限なし) |
| ↓ | ↓ | |
| ユーザー (グループ A とグループ B のメンバー) | 60 | 10 |
注記
ipa pwpolicy-show --user=user_name コマンドでは、現在どのポリシーが特定のユーザーに適用されているかを示します。
27.3. 新規パスワードポリシーの追加
- ポリシーの適用先となるユーザーグループ (「グローバルおよびグループ固有ののパスワードポリシー」 を参照)
- 優先度 (「パスワードポリシーの優先度」 を参照)
- web UI の場合は、「Web UI: 新規パスワードポリシーの追加」 を参照してください。
- コマンドラインの場合は、「コマンドライン: 新規パスワードポリシーの追加」 を参照してください。
Web UI: 新規パスワードポリシーの追加
- → を選択します。
- をクリックします。
- ユーザーグループと優先度を定義します。
- をクリックして確定します。
コマンドライン: 新規パスワードポリシーの追加
ipa pwpolicy-addコマンドで、ユーザーグループと優先度を指定します。$
ipa pwpolicy-addGroup:group_namePriority:priority_level- オプションで、
ipa pwpolicy-findコマンドを使用してポリシーが正常に追加されたことを確認できます。$
ipa pwpolicy-find
27.4. パスワードポリシー属性の編集
重要
注記
- web UI の場合は、「Web UI: パスワードポリシーの修正」 を参照してください。
- コマンドラインの場合は、「コマンドライン: パスワードポリシーの修正」 を参照してください。
0 に設定すると、属性の制限がなくなります。たとえば、maximum lifetime を 0 に設定すると、パスワードの有効期限がなくなります。
Web UI: パスワードポリシーの修正
- → を選択します。
- 変更するポリシーを修正します。
- 必要な属性を更新します。利用可能な属性の詳細については、「サポートされるパスワードポリシーの属性」 を参照してください。
- をクリックして変更を保存します。
コマンドライン: パスワードポリシーの修正
ipa pwpolicy-modコマンドを使用してポリシーの属性を変更します。- たとえば、グローバルパスワードポリシーを更新してパスワードの最小限の長さを
10に設定するには、以下を実行します。$
ipa pwpolicy-mod --minlength=10 - グループポリシーを更新するには、グループ名を
ipa pwpolicy-modに追加します。$
ipa pwpolicy-mod group_name --minlength=10
- オプションで、
ipa pwpolicy-showコマンドを使用すると、新規ポリシー設定を確認することができます。- グローバルポリシーを表示するには、以下を実行します。
$
ipa pwpolicy-show - グループポリシーを表示するには、グループ名を
ipa pwpolicy-showに追加します。$
ipa pwpolicy-show group_name
27.5. パスワードの有効期限を変更して即座に反映させる
krbPasswordExpiration の属性値を変更します。単一ユーザーの場合、以下のようにします。
ldapmodifyユーティリティーを使用します。#
ldapmodify -D "cn=Directory Manager" -w secret -h server.example.com -p 389 -vvdn:uid=user_name,cn=users,cn=accounts,dc=example,dc=comchangetype:modifyreplace:krbPasswordExpirationkrbPasswordExpiration:20160203203734ZkrbPasswordExpirationフォーマットは以下のテンプレートに従っています。- 年 (
2016) - 月 (
02) - 日 (
03) - 現在の時刻 (
20:37:34) - タイムゾーン (
Z)
- Ctrl+D を押して変更をサーバーに送信します。
-f オプションを ldapmodify で使用して LDIF ファイルを参照します。
第28章 Kerberos ドメインの管理
重要
kadmin または kadmin.local ユーティリティーを使用しないでください。本ガイドに記載のように、ネイティブの Identity Management コマンドツールを使用してください。
28.1. Kerberos チケットポリシーの管理
28.1.1. グローバルおよびユーザー固有の Kerberos チケットポリシー
- グローバルの Kerberos チケットポリシー
- グローバルポリシーは、Identity Management の Kerberos レルム内で発行された全チケットに適用されます。
- ユーザー固有の Kerberos チケットポリシー
- ユーザー固有のポリシーは、関連付けられたユーザーアカウントに対してのみ適用されます。たとえば、ユーザー固有のチケットポリシーにより、
adminユーザーのチケットの最大有効期間を延長するように定義できます。ユーザー固有のポリシーは、グローバルポリシーよりも優先されます。
28.1.2. グローバルの Kerberos チケットポリシーの設定
- Identity Management の Web UI: 「Web UI: グローバルのKerberos チケットポリシーの設定」を参照してください。
- コマンドライン: 「コマンドライン: グローバルのKerberos チケットポリシーの設定」を参照してください。
表28.1 サポートされる Kerberos チケットポリシーの属性
| 属性 | 説明 | 例 |
|---|---|---|
| Max renew |
Kerberos チケットの有効期限が切れてからチケットを更新できる期間 (秒)。更新期間が過ぎると、ユーザーは
kinit ユーティリティーを使用してログインし、新規チケットを取得する必要があります。
チケットを更新するには
kinit -R コマンドを使用します。
|
Max renew = 604800
チケットの期限が切れると、ユーザーは 7 日以内 (604,800 秒) であればチケットを更新できます。
|
| Max life | Kerberos チケットの有効期間 (秒)。Kerberos チケットが有効な期間。 |
Max life = 86400
チケットは発行されてから 24 時間 (86,400 秒) で期限が切れます。
|
Web UI: グローバルのKerberos チケットポリシーの設定
- → を選択します。
- 必須値を定義します。
- Max renew フィールドで、Kerberos チケットの最大更新期間を入力します。
- Max life フィールドで、Kerberos チケットの最大有効期間を入力します。

図28.1 グローバルの Kerberos チケットポリシーの設定
- をクリックします。
コマンドライン: グローバルのKerberos チケットポリシーの設定
ipa krbtpolicy-modコマンドを使用して、最低でも以下のオプションを 1 つ指定します。--maxrenewは、Kerberos チケットの最大更新期間を定義します。--maxlifeは、Kerberos チケットの最大有効期間を定義します。
たとえば、最大有効期間を変更するには、以下を実行します。$
ipa krbtpolicy-mod --maxlife=80000Max life: 80000 Max renew: 604800
ipa krbtpolicy-resetコマンドを使用します。- オプションで、
ipa krbtpolicy-showコマンドを使用して、現在の設定を確認します。
ipa krbtpolicy-mod および ipa krbtpolicy-reset の詳細は、コマンドの実行時に --help のオプションを指定します。
28.1.3. ユーザー固有の Kerberos チケットポリシーの設定
ipa krbtpolicy-mod user_nameコマンドを使用して、最低でも以下のオプションを 1 つ指定します。--maxrenewは、Kerberos チケットの最大更新期間を定義します。--maxlifeは、Kerberos チケットの最大有効期間を定義します。
属性 1 つのみを定義した場合には、Identity Management は、他の属性にグローバルの Kerberos チケットポリシーを適用します。たとえばadminユーザーの最大有効期間を変更するには、以下を実行します。$
ipa krbtpolicy-mod admin --maxlife=160000Max life: 80000 Max renew: 604800- オプションで、
ipa krbtpolicy-show user_nameコマンドを使用して、特定のユーザーの現在値を表示します。
kinit ユーティリティーの使用時など、次回の Kerberos チケットの要求時に即座にチケットに適用されます。
ipa krbtpolicy-reset user_name コマンドを使用します。このコマンドは、Identity Management がグローバルポリシーの値を適用してからユーザーに定義された値を消去します。
ipa krbtpolicy-mod および ipa krbtpolicy-reset の詳細は、コマンドの実行時に --help のオプションを指定します。
28.2. Kerberos プリンシパルの鍵の変更
- 指定の期間内に発行された keytab をすべて検索します。たとえば、以下のコマンドでは、
ldapsearchユーティリティーを使用して、グリニッジ標準時 (GMT) の 2016 年 1 月 1 日午前 12 時から 12 月 31 日午後 11 時 59 分までに作成された全ホストとサービスプリンシパルを表示します。#
ldapsearch -x -b "cn=computers,cn=accounts,dc=example,dc=com" "(&(krblastpwdchange>=20160101000000)(krblastpwdchange<=20161231235959))" dn krbprincipalname#
ldapsearch -x -b "cn=services,cn=accounts,dc=example,dc=com" "(&(krblastpwdchange>=20160101000000)(krblastpwdchange<=20161231235959))" dn krbprincipalname- 検索ベース (
-b) では、ldapsearchがプリンシパルを検索するサブツリーを定義します。- ホストプリンシパルは、
cn=computers,cn=accounts,dc=example,dc=comサブツリーの配下に保存されます。 - サービスプリンシパルは、
cn=services,cn=accounts,dc=example,dc=comサブツリーの配下に保存されます。
krblastpwdchangeパラメーターは、最終変更日で検索結果を絞り込みます。このパラメーターは、日付には YYYYMMDD の形式、日次には HHMMSS の形式に対応しています (グリニッジ標準時)。dnおよびkrbprincipalname属性を指定すると、検索結果をエントリー名とプリンシパルのみに絞り込みます。
- サービスおよびホストがプリンシパルの鍵の再生成が必要な場合には、
ipa-getkeytabユーティリティーを使用して新規 keytab エントリーを取得します。以下のオプションを渡します。--principal(-p): プリンシパルを指定します。--keytab(-k): 元の keytab の場所を指定します。--server(-s): Identity Management サーバーのホスト名を指定します。
例を示します。- デフォルトの場所である
/etc/krb5.keytabにある keytab のホストプリンシパルの鍵を再生成するには、以下を実行します。#
ipa-getkeytab -p host/client.example.com@EXAMPLE.COM -s server.example.com -k /etc/krb5.keytab - デフォルトの場所である
/etc/httpd/conf/ipa.keytabにある Apache サービスの keytab の鍵を再生成するには以下を実行します。#
ipa-getkeytab -p HTTP/client.example.com@EXAMPLE.COM -s server.example.com -k /etc/httpd/conf/ipa.keytab重要
NFS バージョン 4 などのサービスは、一部の暗号化タイプのみをサポートします。ipa-getkeytabコマンドに適切な引数を渡して keytab を設定します。
- オプション: プリンシパルの鍵が正しく再生成されたことを確認します。
klistユーティリティーを使用して、すべての Kerberos チケットを表示します。たとえば、/etc/krb5.keytabの keytab エントリーを表示するには以下を実行します。#
klist -kt /etc/krb5.keytabKeytab: WRFILE:/etc/krb5.keytab KVNO Timestamp Principal ---- ----------------- -------------------------------------------------------- 1 06/09/16 05:58:47 host/client.example.com@EXAMPLE.COM(aes256-cts-hmac-sha1-96) 2 06/09/16 11:23:01 host/client.example.com@EXAMPLE.COM(aes256-cts-hmac-sha1-96) 1 03/09/16 13:57:16 krbtgt/EXAMPLE.COM@EXAMPLE.COM(aes256-cts-hmac-sha1-96) 1 03/09/16 13:57:16 HTTP/server.example.com@EXAMPLE.COM(aes256-cts-hmac-sha1-96) 1 03/09/16 13:57:16 ldap/server.example.com@EXAMPLE.COM(aes256-cts-hmac-sha1-96)この出力では、client.example.comの keytab エントリーが前の KVNO よりも大きい数値を使用して鍵が再生成されたことを示します。以前の KVNO が付いた元の keytab は、そのままデータベースに残ります。以前の keytab に対して発行されたチケットは機能し続け、KVNO の値が最大の鍵で新規チケットが発行されるため、システム操作の中断を防ぎます。
28.3. keytab の保護
/etc/httpd/conf/ipa.keytab の Apache keytab を保護するには以下を行います。
apacheにファイルの所有者を設定します。#
chown apache /etc/httpd/conf/ipa.keytab- ファイルのパーミッションを
0600に設定します。これは、所有者に読み取り、書き込み、実行の権限を割り当てます。#
chmod 0600 /etc/httpd/conf/ipa.keytab
28.4. Keytab の削除
ipa-rmkeytab ユーティリティーを使用してこれらのオプションを渡します。
--realm(-r): Kerberos レルムを指定します。--keytab(-k): keytab ファイルへのパスを指定します。
# ipa-rmkeytab --realm EXAMPLE.COM --keytab /etc/krb5.keytab--principal (-p) オプションを使用して、サービスプリンシパルを指定します。
# ipa-rmkeytab --principal ldap/client.example.com --keytab /etc/krb5.keytab第29章 sudo の使用
sudo ポリシーを IdM ドメイン全体に予測通りかつ一貫性を持って適用するメカニズムがあります。IdM ドメイン内のシステムはすべて、sudo クライアントとして設定することが可能です。
29.1. Identity Management の sudo ユーティリティー
sudo ユーティリティーを使うと、指定されたユーザーに管理アクセスが与えられます。信頼できるユーザーが sudo を管理コマンドの前に付けると、ユーザー自身の パスワードが要求されます。ユーザーが認証され、コマンドが許可されると、管理コマンドは root ユーザーのように実行されます。sudo についての詳細情報は、『システム管理者のガイド』を参照してください。
29.1.1. sudo 向け Identity Management LDAP スキーマ
sudo エントリー用の特別な LDAP スキーマがあります。これは以下をサポートしています。
- ホストグループおよび netgroup。
sudoがサポートしているのは netgroup のみであることに注意してください。 sudoコマンドグループ。これには複数のコマンドが含まれます。
注記
sudo はホストグループやコマンドグループをサポートしないので、sudo ルールの作成時に IdM は IdM sudo 設定をネイティブの sudo 設定に変換します。たとえば、IdM は各ホストグループに対応するシャドウ netgroup を作成し、これにより IdM 管理者はホストグループを参照する sudo ルールを作成することができます。一方で、ローカルの sudo コマンドは対応する netgroup を使用します。
sudo 情報は、LDAP で匿名で利用可能ではないので、IdM はデフォルトの sudo ユーザーを uid=sudo,cn=sysaccounts,cn=etc,$SUFFIX で定義します。このユーザーは、/etc/sudo-ldap.conf にある LDAP sudo 設定ファイルで変更することが可能です。
29.1.2. NIS ドメイン名要件
sudo が正常に機能するには、NIS ドメイン名を設定する必要があります。sudo の設定には、NIS 形式 netgroup と netgroup 用の NIS ドメイン名が必要になります。ただし、この NIS ドメイン自体が存在する必要はありません。また、NIS サーバーがインストールされている必要もありません。
注記
ipa-client-install ユーティリティーは、デフォルトで NIS ドメイン名を自動的に IdM ドメイン名に設定します。
29.2. Identity Management での sudo ルール
sudo ルールを使用することで、誰が何をどこで、および誰としてという要素を定義できます。
- 誰 は、
sudoを使用できるユーザーです。 - 何 は、
sudoで使用できるコマンドです。 - どこで は、ユーザーが
sudoを使用できるターゲットホストです。 - 誰として は、ユーザーがタスクを実行する上で装うシステムまたはユーザー ID です。
29.2.1. sudo ルールにおける外部ユーザーとホスト
sudo ルールで外部のエンティティーを受け付けます。外部のエンティティーとは、IdM ドメインの一部ではないユーザーやホストなど、IdM ドメイン外で保存されているエンティティーです。
sudo ルールを使って IdM 内の IT グループのメンバーに root アクセスを付与することができます。この場合の root ユーザーは、IdM ドメインで定義されているユーザーではありません。別の例では、ネットワーク上にあるものの IdM ドメインの一部ではない特定ホストへのアクセスを管理者はブロックすることができます。
29.2.2. sudo ルールでのユーザーグループのサポート
sudo を使って、IdM のユーザーグループ全体にアクセスを付与することができます。IdM では、Unix および 非 POSIX グループの両方に対応しています。非 POSIX グループを作成すると、非 POSIX グループ内のユーザーはこのグループから非 POSIX パーミッションを継承するため、アクセス問題が発生する場合があることに注意してください。
29.2.3. sudoersオプションのサポート
sudoers オプションをサポートしています。利用可能な sudoers オプションの全一覧については、sudoers(5) man ページを参照してください。
sudoers オプションで空白や改行を受け付けないことに注意してください。このため、複数のオプションはコンマ区切りリストではなく、個別のコマンドで追加してください。たとえば、sudoers オプション 2 つをコマンドラインから追加するには、以下のようにします。
$ ipa sudorule-add-option sudo_rule_name Sudo Option: first_option $ ipa sudorule-add-option sudo_rule_name Sudo Option: second_option
$ ipa sudorule-add-option sudo_rule_name Sudo Option: env_keep="COLORS DISPLAY EDITOR HOSTNAME HISTSIZE INPUTRC KDEDIR LESSSECURE LS_COLORS MAIL PATH PS1 PS2 XAUTHORITY"
29.3. sudo ポリシーをルックアップする場所の設定
sudo 設定用の中央 IdM データベースは、IdM で定義された sudo ポリシーをグローバルで全ドメインホストに利用可能とします。Red Hat Enterprise Linux 7.1 以降のシステムでは、SSSD を sudo 用のデータプロバイダーとして設定することで、システムが IdM 定義のポリシーを使用するよう、ipa-server-install と ipa-client-install のユーティリティーが自動的に設定します。
sudo ポリシーをルックアップする場所は、/etc/nsswitch.conf ファイルの sudoers の行で定義します。Red Hat Enterprise Linux 7.1 以降で実行している IdM では、 nsswitch.conf でのsudoers のデフォルト設定は以下のようになります。
sudoers: files sss
files オプションは、/etc/sudoers のローカル SSSD 設定ファイルで定義された sudo 設定をシステムが使用することを指定します。sss オプションは、IdM で定義された sudo 設定を使用することを指定します。
29.3.1. ホストが IdM の以前のバージョンの IdM sudo ポリシーを使用する設定
sudo ポリシーを Red Hat Enterprise Linux 7.1 より前のバージョンで稼働する IdM システムに実装するには、ローカルマシンを手動で設定する必要があります。これは SSSD または LDAP を使用することで可能になります。Red Hat では、SSSD ベースの設定を使用することを強く推奨しています。
29.3.1.1. SSSD を使用した sudo ポリシーのホストへの適用
sudo ルールに SSSD を使用する必要があるシステムで、以下のステップを実行します。
sudoersファイルで SSSD をルックアップするようsudoを設定します。# vim /etc/nsswitch.conf sudoers: files sss
filesオプションを残しておくと、sudoは IdM 設定を SSSD でチェックする前にローカル設定をチェックします。sudoを、ローカルの SSSD クライアントが管理するサービス一覧に追加します。# vim /etc/sssd/sssd.conf [sssd] config_file_version = 2 services = nss, pam,
sudodomains = IPADOMAINsudo設定で NIS ドメインの名前を設定します。sudoは NIS スタイルの netgroup を使用するので、sudoが IdMsudo設定で使用されているホストグループを発見できるようにするには、NIS ドメイン名はシステム設定で設定する必要があります。rhel-domainnameサービスが有効になっていない場合はこれを有効にし、NIS ドメイン名が再起動後も維持されるようにします。# systemctl enable rhel-domainname.service
sudoルールで使用する NIS ドメイン名を設定します。# nisdomainname example.com
- NIS ドメイン名が維持されるようにシステム認証設定を設定します。例を示します。
# echo "NISDOMAIN=example.com" >> /etc/sysconfig/network
これで NIS ドメインを使って/etc/sysconfig/networkおよび/etc/yp.confのファイルが更新されます。
- オプションで、SSSD 内のデバッグを有効にして、使用している LDAP 設定を表示することができます。
[domain/IPADOMAIN] debug_level = 6 ....
SSSD が使用する LDAP 検索ベースは、sssd_DOMAINNAME.logのログに記録されます。
29.3.1.2. LDAP を使用して sudo ポリシーをホストに適用する
重要
sudo ポリシーのホストへの適用」 を参照してください。
sudo ポリシー適用に関する情報は、Identity Management Guide for Red Hat Enterprise Linux 6 を参照してください。
29.4. sudo コマンド、コマンドグループ、およびルールの追加
29.4.1. sudo コマンドの追加
Web UI での sudo コマンドの追加
- Policy タブで → をクリックします。
- リスト上部にある をクリックします。
- コマンドについての情報を入力します。コマンド実行可能ファイルへの完全なシステムパスを入力します。

図29.1 新規
sudoコマンドの追加 - をクリックします。別の方法では、 をクリックして、別のユーザーを追加するか、 をクリックして新規エントリーの編集を開始します。
コマンドラインからの sudo コマンドの追加
sudo コマンドを追加するには、ipa sudocmd-add コマンドを使用します。コマンドの実行可能ファイルへの完全なシステムパスを提供します。たとえば、/usr/bin/less コマンドとその説明を追加するには、以下を実行します。
$ ipa sudocmd-add /usr/bin/less --desc="For reading log files" ---------------------------------- Added sudo command "/usr/bin/less" ---------------------------------- sudo Command: /usr/bin/less Description: For reading log files
29.4.2. sudo コマンドグループの追加
Web UI での sudo コマンドグループの追加
- Policy タブで → をクリックします。
- リスト上部にある をクリックします。
- コマンドグループについての情報を入力します。

図29.2 新規
sudoコマンドグループの追加 - をクリックしてコマンドグループを編集します。
- Sudo Commands タブで をクリックして
sudoコマンドをグループに追加します。該当するコマンドを選択し、 ボタンを使って Prospective コラムに移動させます。
図29.3
sudoコマンドグループへのコマンドの追加 - をクリックします。
コマンドラインからの sudo コマンドグループの追加
ipa sudocmdgroup-addコマンドを使ってコマンドグループを作成します。たとえば、filesコマンドを作成してその説明を追加するには、以下を実行します。$ ipa sudocmdgroup-add files --desc="File editing commands" ----------------------------------- Added sudo command group "files" ----------------------------------- sudo Command Group: files Description: File editing commands
ipa sudocmdgroup-add-memberコマンドを使用してグループにsudoコマンドを含めます。「sudoコマンドの追加」 で説明されたように IdM に追加されたコマンドしか含められないことに注意してください。$ ipa sudocmdgroup-add-member files --sudocmds "/usr/bin/vim" sudo Command Group: files Description: File editing commands Member sudo commands: /usr/bin/vim ------------------------- Number of members added 1 -------------------------
29.4.3. sudo ルールの追加
Web UI での sudo ルールの追加
- Policy タブで → をクリックします。
- リスト上部にある をクリックします。
- ルールの名前を入力します。

図29.4 新規
sudoルールの名前入力 - をクリックします。別の方法では、 をクリックして、別のユーザーを追加するか、 をクリックして新規エントリーの編集を開始します。
sudo ルールの編集方法については、「sudo ルールの修正」 を参照してください。
コマンドラインからの sudo ルールの追加
sudo ルールを追加するには、ipa sudorule-add コマンドを使用します。たとえば、files-commands という名前のルールを追加するには、以下を実行します。
$ ipa sudorule-add files-commands -------------------------------- Added Sudo Rule "files-commands" -------------------------------- Rule name: files-commands Enabled: TRUE
ipa sudorule-add コマンドの使用方法とこのコマンドが受け付けるオプションについての詳細は、コマンドに --help オプションを実行すると表示されます。
sudo ルールの編集方法については、「sudo ルールの修正」 を参照してください。
sudo ルールの追加およびコマンドラインからこれを編集する完全な例については、例29.1「コマンドラインからの新規 sudo ルール追加および修正」 を参照してください。
29.5. sudo コマンドとコマンドグループの編集
Web UI での sudo コマンドとコマンドグループの修正
- Policy タブで → または → をクリックします。
- 設定ページを表示するコマンドまたはコマンドグループの名前をクリックします。
- 必要に応じて設定を変更します。ページによっては上部に ボタンがあるものもあります。その場合は、このボタンをクリックして変更を保存します。
コマンドラインからの sudo コマンドとコマンドグループの修正
ipa sudocmd-modipa sudocmdgroup-mod
sudo コマンドまたはコマンドグループの属性を更新します。たとえば、/usr/bin/less コマンドに新たな説明を追加するには、以下を実行します。
$ ipa sudocmd-mod /usr/bin/less --desc="For reading log files" ------------------------------------- Modified Sudo Command "/usr/bin/less" ------------------------------------- Sudo Command: /usr/bin/less Description: For reading log files Sudo Command Groups: files
--help オプションを追加して実行してください。
29.6. sudo ルールの修正
Web UI での sudo ルールの修正
- Policy タブで → をクリックします。
- 設定ページを表示するルールの名前をクリックします。
- 必要に応じて設定を変更します。ページによっては上部に ボタンがあるものもあります。その場合は、このボタンをクリックして変更を保存します。
sudo ルールの設定ページには、以下の設定エリアがあります。
- General エリア
- このエリアでは、ルールの説明と
sudo orderを修正します。sudo orderフィールドには、IdM がルールを評価する順番を整数で入力します。sudo orderの値の最も高いルールが最初に評価されます。 - Options エリア
- このエリアでは、
sudoersオプションをルールに追加します。- オプション一覧の上部にある Add をクリックします。

図29.5
sudoオプションの追加 sudoersオプションを入力します。たとえば、sudoでユーザー認証が要求されないようにするには、!authenticateを追加します。
図29.6
sudoersオプションの追加sudoersオプションの詳細情報については、sudoers(5) man ページを参照してください。- をクリックします。
- Who エリア
- このエリアでは、
sudoルールが適用されるユーザーまたはユーザーグループを選択します。これらのユーザーは、ルールで定義されたようにsudoを使用することができます。すべてのシステムユーザーがルールで定義したようにsudoを使用出来るようにするには、Anyone を選択します。ルールを特定のユーザーまたはグループのみに適用するには、Specified Users and Groups を選択して、以下のステップに従います。- ユーザーまたはユーザーグループ一覧上部にある Add をクリックします。

図29.7
sudoルールへのユーザーの追加 - ルールに追加するユーザーまたはユーザーグループを選択し、 ボタンをクリックして Prospective コラムに移動します。外部ユーザーを追加する場合には External フィールドでユーザーを指定してから ボタンをクリックします。

図29.8
sudoルール向けにユーザーを選択する - をクリックします。
- Access This Host エリア
- このエリアでは、
sudoルールを有効にするホストを選択します。これは、ユーザーにsudoパーミッションが付与されるホストになります。全ホストでルールを有効にするには、Anyone を選択します。ルールを特定のホストまたはホストグループのみに適用するには、Specified Hosts and Groups を選択して、以下のステップに従います。- ホスト一覧の上部にある Add をクリックします。

図29.9
sudoルールへのホストの追加 - ルールに含めるホストまたはホストグループを選択し、 ボタンをクリックして Prospective コラムに移動します。外部ホストを追加する場合には External フィールドでユーザーを指定してから ボタンをクリックします。

図29.10
sudoルール用のホスト選択 - をクリックします。
- Run Commands エリア
- このエリアでは、
sudoルールに含めるコマンドを選択します。特定コマンドの使用をユーザーに許可する、もしくは拒否することを指定できます。ユーザーがsudoですべてのコマンドを使用できるようにするには、Any Command を選択します。ルールを特定のコマンドまたはコマンドグループに関連付けるには、Specified Commands and Groups を選択して、以下のステップに従います。- いずれかの ボタンをクリックして、コマンドまたはコマンドグループを追加します。許可するコマンドまたはコマンドグループを指定するには、Allow エリアを使用します。拒否するコマンドまたはコマンドグループを指定するには Deny エリアを使用します。

図29.11
sudoルールへのコマンドの追加 - ルールに含めるコマンドまたはコマンドグループを選択し、 ボタンをクリックして Prospective コラムに移動させます。

図29.12
sudoルール向けにコマンドを選択する - をクリックします。
- As Whom エリア
- このエリアでは、特定の root 以外のユーザーとして特定コマンドを実行するよう
sudoを設定します。RunAs users のグループを追加すると、そのグループのメンバーの UID がそのコマンドの実行に使用されることに注意してください。また、RunAs group を追加すると、コマンドの実行にそのグループの GID が使用されます。システム上のいずれのユーザーとしてルールを実行できるようにするには、Anyone を選択します。システム上のいずれのグループとしてルールを実行できるようにするには、Any Group を選択します。- ユーザー一覧上部にある Add をクリックします。

図29.13 特定ユーザーとしてコマンドを実行する
sudoルールの設定 - ユーザーまたはグループを選択し、 ボタンをクリックして Prospective コラムに移動させます。外部のエンティティーを追加する場合には External フィールドで指定してから ボタンをクリックします。

図29.14 コマンドのユーザー選択
- をクリックします。
コマンドラインからの sudo ルールの修正
sudo ルールエリアを設定できます。
- 全般的
sudoルールの管理 sudoルールの全般的設定を変更するには、ipa sudorule-modコマンドを使用します。よく使用されるオプションには、以下のものがあります。--descオプションでは、以下のようにsudoルールの説明を変更します。$ ipa sudorule-mod sudo_rule_name --desc="sudo_rule_description"
--orderオプションでは、以下のように指定されたルールの順序を定義します。$ ipa sudorule-mod sudo_rule_name --order=3
- エンティティーのカテゴリーは以下のオプションで指定します:
--usercat(ユーザーカテゴリー)、--hostcat(ホストカテゴリー)、--cmdcat(コマンドカテゴリー)、--runasusercat(run-as ユーザーカテゴリー)、および--runasgroupcat(run-as グループカテゴリー)。これらのオプションではすべてallの値を使用することが可能で、その場合は該当ルールをすべてのユーザー、ホスト、コマンド、run-as ユーザー、もしくは run-as グループに関連付けます。たとえば、sudo_ruleルールで定義したsudoを全ユーザーが使用できるように指定するには、以下を実行します。$ ipa sudorule-mod sudo_rule --usercat=all
ルールが既に特定エンティティーと関連付けられている場合は、この関連付けを解除してからそのエンティティーに対応するallカテゴリーを定義する必要があります。たとえば、sudo_ruleがipa sudorule-add-userコマンドを使用して特定のユーザーと関連付けられている場合は、まずipa sudorule-remove-userコマンドを使ってこのユーザーを削除する必要があります。
ipa sudorule-modで使用可能なオプションの完全一覧と詳細情報については、コマンドに--helpオプションを追加して実行してください。sudoオプションの管理sudoersオプションを追加するには、ipa sudorule-add-optionコマンドを使用します。たとえば、files-commandsルールをベースとしたsudoを使用するユーザーの認証を不要とするには、!authenticateオプションを使用します。$ ipa sudorule-add-option files-commands Sudo Option: !authenticate --------------------------------------------------------- Added option "!authenticate" to Sudo Rule "files-commands" ---------------------------------------------------------
sudoersオプションの詳細情報については、sudoers(5) man ページを参照してください。sudoersオプションを削除するには、以下のようにipa sudorule-remove-optionコマンドを使用します。$ ipa sudorule-remove-option files-commands Sudo Option: authenticate ------------------------------------------------------------- Removed option "authenticate" from Sudo Rule "files-commands" -------------------------------------------------------------
sudo使用のパーミッション付与の管理- 個別ユーザーを指定するには、
--usersオプションをipa sudorule-add-userコマンドで使用します。ユーザーグループを指定するには、--groupsオプションをipa sudorule-add-userに追加します。たとえば、userとuser_groupをfiles-commandsルールに追加するには、以下のコマンドを実行します。$ ipa sudorule-add-user files-commands --users=user --groups=user_group ... ------------------------- Number of members added 2 -------------------------
個別のユーザーもしくはグループを削除するには、以下のようにipa sudorule-remove-userを使用します。$ ipa sudorule-remove-user files-commands [member user]: user [member group]: ... --------------------------- Number of members removed 1 ---------------------------
- ユーザーに
sudoパーミッションを付与する場所の管理 - ホストを指定するには、
--hostsオプションをipa sudorule-add-hostコマンドで使用します。ホストグループを指定するには、--hostgroupsオプションをipa sudorule-add-hostに追加します。たとえば、example.comとhost_groupをfiles-commandsルールに追加するには、以下のコマンドを実行します。$ ipa sudorule-add-host files-commands --hosts=example.com --hostgroups=host_group ... ------------------------- Number of members added 2 -------------------------
ホストまたはホストグループを削除するには、以下のようにipa sudorule-remove-hostコマンドを使用します。$ ipa sudorule-remove-host files-commands [member host]: example.com [member host group]: ... --------------------------- Number of members removed 1 ---------------------------
sudoと使用するコマンドの管理- 特定コマンドの使用をユーザーに許可する、もしくは拒否することを指定できます。許可するコマンドもしくはコマンドグループを指定するには、
--sudocmdsまたは--sudocmdgroupsオプションをipa sudorule-add-allow-commandに追加します。拒否するコマンドもしくはコマンドグループを指定するには、--sudocmdsまたは--sudocmdgroupsオプションをipa sudorule-add-deny-commandコマンドに追加します。たとえば、/usr/bin/lessコマンドとfilesコマンドグループを許可するものとしてfiles-commandsルールに追加するには、以下のコマンドを実行します。$ ipa sudorule-add-allow-command files-commands --sudocmds=/usr/bin/less --sudocmdgroups=files ... ------------------------- Number of members added 2 -------------------------
コマンドまたはコマンドグループをルールから削除するには、以下のようにipa sudorule-remove-allow-commandまたはipa sudorule-remove-deny-commandコマンドを実行します。$ ipa sudorule-remove-allow-command files-commands [member sudo command]: /usr/bin/less [member sudo command group]: ... --------------------------- Number of members removed 1 ---------------------------
--sudocmdsオプションは 「sudoコマンドの追加」 にあるように、IdM に追加されたコマンドしか受け付けないことに注意してください。 sudoコマンドの実行者の ID 管理- 個別ユーザーもしくはグループ内のユーザーの UID をコマンド実行時の ID として使用するには、
--usersまたは--groupsオプションをipa sudorule-add-runasuserコマンドで使用します。ユーザーグループの GID をコマンド実行時の ID として使用するには、ipa sudorule-add-runasgroup --groupsコマンドを使用します。ユーザーやグループを指定しない場合は、sudoコマンドは root として実行されます。たとえば、userの ID を使用してsudoルール内のコマンドを実行するように指定するには、以下を実行します。$ ipa sudorule-add-runasuser files-commands --users=user ... RunAs Users: user ...
ipa sudorule-* コマンドの詳細については、ipa help sudorule コマンドの出力を確認するか、各コマンドに --help オプションを追加して実行します。
例29.1 コマンドラインからの新規 sudo ルール追加および修正
sudo ですべてのコマンドを使用できるようにするには、以下の手順を実行します。
adminユーザーまたはsudoルールの管理を許可されている他のユーザー用に Kerberos チケットを取得します。$ kinit admin Password for admin@EXAMPLE.COM:
- 新規
sudoルールを IdM に追加します。$ ipa sudorule-add new_sudo_rule --desc="Rule for user_group" --------------------------------- Added Sudo Rule "new_sudo_rule" --------------------------------- Rule name: new_sudo_rule Description: Rule for user_group Enabled: TRUE
- who を定義します。
sudoルールの使用が許可されるユーザーのグループを指定します。$ ipa sudorule-add-user new_sudo_rule --groups=user_group Rule name: new_sudo_rule Description: Rule for user_group Enabled: TRUE User Groups: user_group ------------------------- Number of members added 1 -------------------------
- where を定義します。ユーザーに
sudoパーミッションが付与されるホストのグループを指定します。$ ipa sudorule-add-host new_sudo_rule --hostgroups=host_group Rule name: new_sudo_rule Description: Rule for user_group Enabled: TRUE User Groups: user_group Host Groups: host_group ------------------------- Number of members added 1 -------------------------
- what を定義します。どの
sudoコマンドもユーザーが実行することを許可するには、allコマンドカテゴリーをルールに追加します。$ ipa sudorule-mod new_sudo_rule --cmdcat=all ------------------------------ Modified Sudo Rule "new_sudo_rule" ------------------------------ Rule name: new_sudo_rule Description: Rule for user_group Enabled: TRUE Command category: all User Groups: user_group Host Groups: host_group
sudoコマンドを root として実行するには、run-as ユーザーまたはグループを指定しないでください。sudoコマンド使用時にユーザー認証が要求されないようにするには、!authenticatesudoersを追加します。$ ipa sudorule-add-option new_sudo_rule Sudo Option: !authenticate ----------------------------------------------------- Added option "!authenticate" to Sudo Rule "new_sudo_rule" ----------------------------------------------------- Rule name: new_sudo_rule Description: Rule for user_group Enabled: TRUE Command category: all User Groups: user_group Host Groups: host_group Sudo Option: !authenticate
- 新規の
sudoルール設定を表示して、内容を確認します。$ ipa sudorule-show new_sudo_rule Rule name: new_sudo_rule Description: Rule for user_group Enabled: TRUE Command category: all User Groups: user_group Host Groups: host_group Sudo Option: !authenticate
29.7. sudo コマンド、コマンドグループ、およびルールの表示
Web UI での sudo コマンド、コマンドグループおよびルールの表示
- Policy タブで Sudo をクリックし、Sudo Rules、Sudo Commands、または Sudo Command Groups のいずれかを選択します。
- 設定ページを表示するコマンド、コマンドグループまたはルールの名前をクリックします。
コマンドラインからの sudo コマンド、コマンドグループおよびルールの表示
ipa sudocmd-findipa sudocmdgroup-findipa sudorule-find
ipa sudocmd-showipa sudocmdgroup-showipa sudorule-show
/usr/bin/less コマンドの情報を表示するには、以下を実行します。
$ ipa sudocmd-show /usr/bin/less Sudo Command: /usr/bin/less Description: For reading log files. Sudo Command Groups: files
--help オプションを追加して実行してください。
29.8. sudo ルールの有効化および無効化
sudo ルールを無効にすると、これが一時的に非アクティブになります。無効になったルールは IdM から削除されるわけではなく、再度有効にすることができます。
Web UI での sudo ルールの有効化、無効化
- Policy タブで → をクリックします。
- ルールを選択して、 または をクリックします。

図29.15
sudoルールの有効化および無効化
コマンドラインからの sudo ルールの有効化、無効化
ipa sudo-rule-disable コマンドを使用します。
$ ipa sudorule-disable sudo_rule_name ----------------------------------- Disabled Sudo Rule "sudo_rule_name" -----------------------------------
ipa sudorule-enable コマンドを使用します。
$ ipa sudorule-enable sudo_rule_name ----------------------------------- Enabled Sudo Rule "sudo_rule_name" -----------------------------------
29.9. sudo コマンド、コマンドグループ、およびルールの削除
Web UI での sudo コマンド、コマンドグループおよびルールの削除
- Policy タブで Sudo をクリックし、Sudo Rules、Sudo Commands、または Sudo Command Groups のいずれかを選択します。
- 削除するコマンド、コマンドグループまたはルールを選択して をクリックします。

図29.16
sudoコマンドの削除
コマンドラインからの sudo コマンド、コマンドグループおよびルールの削除
ipa sudocmd-delipa sudocmdgroup-delipa sudorule-del
--help オプションを追加して実行してください。
第30章 ホストベースのアクセス制御の設定
30.1. IdM での Host-Based Access Control の機能
- ドメイン内の指定のシステムへのアクセスを、特定のユーザーグループに所属するメンバーに制限すること
- ドメイン内のシステムにアクセスして特定のサービスだけを使用できるようにすること
allow_all という名前のデフォルトの HBAC ルールで設定されています。このルールでは、IdM ドメイン全体にアクセスできます。
HBAC ルールのグループへの適用

図30.1 ホストグループとホストベースのアクセス制御
30.2. IdM ドメインでの Host-based Access Control の設定
重要
カスタムの HBAC ルールを作成する前にallow_allルールを無効化しないでください。作成してしまうと、ユーザーはどのホストにもアクセスできなくなります。
30.2.1. HBAC ルールの作成
- IdM web UI (「Web UI: HBAC ルールの作成」を参照してください)
- コマンドライン (「コマンドライン: HBAC ルールの作成」を参照してください)
Web UI: HBAC ルールの作成
- → → を選択します。
- をクリックして、新規ルールの追加を開始します。
- ルールの名前を入力して をクリックし、HBAC ルールの設定ページに直接移動します。
- Who エリアで対象ユーザーを指定します。
- 特定のユーザーまたはグループのみに HBAC ルールを適用するには、Specified Users and Groups を選択してから、 をクリックしてユーザーまたはグループを追加します。
- 全ユーザーに HBAC ルールを適用するには、Anyone を選択します。

図30.2 HBAC ルールの対象ユーザーの指定
- Accessing エリアで対象ホストを指定します。
- 特定のホストまたはグループのみに HBAC ルールを適用するには、Specified hosts and Groups を選択してから、 をクリックしてホストまたはグループを追加します。
- 全ホストに HBAC ルールを適用するには、Any Host を選択します。
- Via Service エリアでは、対象の HBAC サービスを指定します。
- 特定のサービスまたはグループのみに HBAC ルールを適用するには、Specified Services and Groups を選択してから、 をクリックしてサービスまたはグループを追加します。
- 全サービスに HBAC ルールを適用するには、Any Service を選択します。
注記
デフォルトでは HBAC ルール用に、最も一般的なサービスおよびサービスグループのみが設定されています。- 現在利用可能なサービス一覧を表示するには、 → → を選択します。
- 現在利用可能なサービスグループ一覧を表示するのは → → を選択します。
さらにサービスやサービスグループを追加するには、「カスタムの HBAC サービス用に HBAC サービスエントリーの追加」 および 「HBAC サービスグループの追加」 を参照してください。 - HBAC ルール設定ページで特定の設定を変更すると、ページの上部の ボタンがハイライトされます。ボタンがハイライトされたら、クリックして変更を確定します。
コマンドライン: HBAC ルールの作成
ipa hbacrule-addコマンドを使用して、ルールを追加します。$ ipa hbacrule-addRule name:rule_name--------------------------- Added HBAC rule "rule_name" --------------------------- Rule name: rule_name Enabled: TRUE- 対象のユーザーを指定します。
- 指定のユーザーまたはグループのみに HBAC ルールを適用するには、
ipa hbacrule-add-userコマンドを使用します。たとえば、グループを追加するには以下を実行します。$ ipa hbacrule-add-userRule name:rule_name[member user]: [member group]:group_nameRule name: rule_name Enabled: TRUE User Groups: group_name ------------------------- Number of members added 1 -------------------------複数のユーザーまたはグループを追加するには、--usersおよび--groupsオプションを使用します。$ ipa hbacrule-add-user rule_name --users=user1 --users=user2 --users=user3Rule name: rule_name Enabled: TRUE Users: user1, user2, user3 ------------------------- Number of members added 3 ------------------------- - HBAC ルールを全ユーザーに適用するには、
ipa hbacrule-modコマンドを使用して、allユーザーカテゴリーを指定します。$ ipa hbacrule-mod rule_name --usercat=all------------------------------ Modified HBAC rule "rule_name" ------------------------------ Rule name: rule_name User category: all Enabled: TRUE注記
HBAC ルールが個別ユーザーまたはグループに関連付けられている場合には、ipa hbacrule-mod --usercat=allは失敗します。このような場合には、ipa hbacrule-remove-userコマンドを使用してユーザーとグループを削除します。詳細は、--helpオプションを指定してipa hbacrule-remove-userを実行します。
- 対象のホストを指定します。
- 指定のホストまたはグループのみに HBAC ルールを適用するには、
ipa hbacrule-add-hostコマンドを使用します。たとえば、単一のホストを追加するには、以下を実行します。$ ipa hbacrule-add-hostRule name:rule_name[member host]:host.example.com[member host group]: Rule name: rule_name Enabled: TRUE Hosts: host.example.com ------------------------- Number of members added 1 -------------------------複数のホストまたはグループを追加するには、--hostsおよび--hostgroupsオプションを使用します。$ ipa hbacrule-add-host rule_name --hosts=host1 --hosts=host2 --hosts=host3Rule name: rule_name Enabled: TRUE Hosts: host1, host2, host3 ------------------------- Number of members added 3 ------------------------- - HBAC ルールを全ホストに適用するには、
ipa hbacrule-modコマンドを使用して、allホストカテゴリーを指定します。$ ipa hbacrule-mod rule_name --hostcat=all------------------------------ Modified HBAC rule "rule_name" ------------------------------ Rule name: rule_name Host category: all Enabled: TRUE注記
HBAC ルールが個別ホストまたはグループに関連付けられている場合には、ipa hbacrule-mod --hostcat=allは失敗します。このような場合には、ipa hbacrule-remove-hostコマンドを使用してホストとグループを削除します。詳細は、--helpオプションを指定してipa hbacrule-remove-hostを実行します。
- 対象の HBAC サービスを指定します。
- 指定のサービスまたはグループのみに HBAC ルールを適用するには、
ipa hbacrule-add-serviceコマンドを使用します。たとえば、単一のサービスを追加するには以下を実行します。$ ipa hbacrule-add-serviceRule name:rule_name[member HBAC service]:ftp[member HBAC service group]: Rule name: rule_name Enabled: TRUE Services: ftp ------------------------- Number of members added 1 -------------------------複数のサービスまたはグループを追加するには、--hbacsvcsおよび--hbacsvcgroupsオプションを使用します。$ ipa hbacrule-add-service rule_name --hbacsvcs=su --hbacsvcs=sudoRule name: rule_name Enabled: TRUE Services: su, sudo ------------------------- Number of members added 2 -------------------------注記
最も一般的なサービスおよびサービスグループのみが HBAC ルール用に設定されます。さらに追加するには「カスタムの HBAC サービス用に HBAC サービスエントリーの追加」および「HBAC サービスグループの追加」を参照してください。 - HBAC ルールを全サービスに適用するには、
ipa hbacrule-modコマンドを使用して、allサービスカテゴリーを指定します。$ ipa hbacrule-mod rule_name --servicecat=all------------------------------ Modified HBAC rule "rule_name" ------------------------------ Rule name: rule_name Service category: all Enabled: TRUE注記
HBAC ルールが個別サービスまたはグループに関連付けられている場合には、ipa hbacrule-mod --servicecat=allは失敗します。このような場合には、ipa hbacrule-remove-serviceコマンドを使用してサービスとグループを削除します。詳細は、--helpオプションを指定してipa hbacrule-remove-serviceを実行します。
- オプション: HBAC ルールが正しく追加されたことを確認します。
ipa hbacrule-findコマンドを使用して、HBAC ルールが IdM に追加されたことを確認します。ipa hbacrule-showコマンドを使用して、HBAC ルールのプロパティーを確認します。
詳細は、--helpオプションを指定してコマンドを実行します。
HBAC ルールの例
例30.1 サービスを使用して単一ユーザーに全ホストへのアクセス権を割り当てる手順
admin ユーザーがドメイン内の全システムにアクセスできるようにするには、新規の HBAC ルールを作成して、以下を設定します。
- ユーザーを
adminに設定します。 - ホストを Any host (web UI で) に設定します。または、
ipa hbacrule-add(ルールの追加) またはipa hbacrule-modを指定して--hostcat=allを実行します。 - サービスを Any service (web UI で) に設定します。または、
ipa hbacrule-add(ルールの追加) またはipa hbacrule-modを指定して--servicecat=allを実行します。
例30.2 特定のサービスのみを使用してホストにアクセスする手順
sudo 関連のサービスを使用して、host.example.com という名前のホストにアクセスするには、新規の HBAC ルールを作成して、以下を設定します。
- ユーザーを Anyone (web UI で) に設定します。または、
ipa hbacrule-add(ルールの追加) またはipa hbacrule-modを指定して--usercat=allを実行します。 - ホストを
host.example.comに設定します。 - HBAC サービスグループを
Sudoに設定します。この Sudo はsudoと関連サービスのデフォルトグループです。
30.2.2. HBAC ルールのテスト
重要
- IdM web UI (「Web UI: HBAC ルールのテスト」を参照してください)
- コマンドライン (「コマンドライン: HBAC ルールのテスト」を参照してください)
Web UI: HBAC ルールのテスト
- → → を選択します。
- Who 画面で、ID のテストを実行するユーザーを指定して、 をクリックします。

図30.3 HBAC テスト用の対象ユーザーの指定
- Accessing 画面でユーザーがアクセスを試みるホストを指定して、 をクリックします。
- Via Service 画面で、ユーザーが使用を試みるサービスを指定して、 をクリックします。
- Rules 画面で、テストする HBAC ルールを選択して をクリックします。ルールを選択しない場合には、すべてのルールがテストされます。Include Enabled を選択して、ステータスが
Enabledの全ルールに対してテストを実行します。Include Disabled を選択して、ステータスがDisabledの全ルールにテストを実行します。HBAC ルールの表示やステータスの変更は、 → → を選択します。重要
複数のルールでテストが実行される場合には、選択したルールの 1 つでアクセスが許可されるとテストに成功します。 - Run Test 画面で、 をクリックします。

図30.4 HBAC テストの実行
- テストの結果を確認します。
ACCESS DENIEDが表示されると、テストへのアクセス権が拒否されたことになります。ACCESS GRANTEDが表示されると、ホストへのアクセスが正常に許可されたことになります。

図30.5 HBAC テスト結果の確認
デフォルトでは、IdM はテスト結果を表示する際には、テスト済みの HBAC ルールをすべて表示します。- アクセスを許可するルールを表示するには、Matched を選択してください。
- アクセスを拒否するルールを表示するには、Unmatched を選択してください。
コマンドライン: HBAC ルールのテスト
ipa hbactest コマンドを使用して、最低でも以下を指定します。
- ID のテストを実行するユーザー
- ユーザーがアクセスを試みるホスト
- ユーザーが使用を試みるサービス
$ ipa hbactest
User name: user1
Target host: example.com
Service: sudo
---------------------
Access granted: False
---------------------
Not matched rules: rule1enabled の HBAC ルールすべてでテストを実行します。別の HBAC ルールを指定するには、以下を実行します。
- HBAC ルールを 1 つまたは複数定義するには、
--rulesオプションを使用します。 - ステータスが
disabledの HBAC ルールをすべてテストするには--disabledオプションを使用します。
ipa hbacrule-find コマンドを使用します。
例30.3 コマンドラインからの HBAC ルールのテスト
rule2 という名前の HBAC ルールを使用して、user1 が sudo を使用して example.com にアクセスできないようにします。
$ ipa hbactest --user=user1 --host=example.com --service=sudo --rules=rule1
---------------------
Access granted: False
---------------------
Not matched rules: rule1例30.4 コマンドラインからの複数の HBAC ルールのテスト
$ ipa hbactest --user=user1 --host=example.com --service=sudo --rules=rule1 --rules=rule2
--------------------
Access granted: True
--------------------
Matched rules: rule2
Not matched rules: rule1Matched rulesでは、正常なアクセスを許可するルールを表示します。Not matched rulesはアクセスを拒否するルールを表示します。
30.2.3. HBAC ルールの無効化
注記
allow_all HBAC ルールで上書きされないようにするには allow_all を無効にする必要があります。
- IdM web UI (「Web UI: HBAC ルールの無効化」を参照)
- コマンドライン (「コマンドライン: HBAC ルールの無効化」を参照)
Web UI: HBAC ルールの無効化
- → → を選択します。
- 無効化する HBAC ルールを選択して をクリックします。

図30.6 allow_all の HBAC ルールの無効化
コマンドライン: HBAC ルールの無効化
ipa hbacrule-disable コマンドを使用します。たとえば、allow_all ルールを無効にするには、以下を実行します。
$ ipa hbacrule-disable allow_all
------------------------------
Disabled HBAC rule "allow_all"
------------------------------30.3. カスタムの HBAC サービス用に HBAC サービスエントリーの追加
注記
- IdM web UI (「Web UI: HBAC サービスエントリーの追加」を参照)
- コマンドライン (「コマンドライン: HBAC サービスエントリーの追加」を参照)
Web UI: HBAC サービスエントリーの追加
- → → を選択します。
- をクリックして、HBAC サービスエントリーを追加します。
- サービスの名前を入力して、 をクリックします。
コマンドライン: HBAC サービスエントリーの追加
ipa hbacsvc-add コマンドを使用します。たとえば、tftp サービスのエントリーを追加するには以下を実行します。
$ ipa hbacsvc-add tftp
-------------------------
Added HBAC service "tftp"
-------------------------
Service name: tftp30.4. HBAC サービスグループの追加
- IdM web UI (「Web UI: HBAC サービスグループの追加」を参照)
- コマンドライン (「コマンドライン: HBAC サービスグループの追加」を参照)
Web UI: HBAC サービスグループの追加
- → → を選択します。
- をクリックして、HBAC サービスグループを追加します。
- サービスグループの名前を入力して、 をクリックします。
- サービスグループ設定ページで をクリックして、グループのメンバーとして HBAC サービスを追加します。

図30.7 HBAC サービスグループへの HBAC サービスの追加
コマンドライン: HBAC サービスグループの追加
ipa hbacsvcgroup-addコマンドを使用して HBAC サービスグループを追加します。loginという名前のグループを追加するには以下を実行します。$ ipa hbacsvcgroup-addService group name:login-------------------------------- Added HBAC service group "login" -------------------------------- Service group name: login- グループのメンバーとして HBAC サービスを追加するには
ipa hbacsvcgroup-add-memberコマンドを使用します。たとえば、sshdサービスをloginグループに追加するには、以下を実行します。$ ipa hbacsvcgroup-add-memberService group name:login[member HBAC service]:sshdService group name: login Member HBAC service: sshd ------------------------- Number of members added 1 -------------------------
第31章 SELinux ユーザーマップの定義
31.1. Identity Management、SELinux、およびユーザーのマッピング
注記

図31.1 SELinux マネージャーの SELinux ユーザー
- リモートユーザーは、自身の IdM グループ割り当てに基づいて、適切な SELinux ユーザーコンテキストが提供されます。これにより管理者は、ローカルアカウントを作成したり SELinux を再構築することなく一貫して同じポリシーを同じユーザーに適用することもできるようになります。
- ホストが IT 環境に追加されたり、ユーザーが追加、削除、変更されたりすると、ローカルシステムを編集することなく、SELinux ユーザーは自動的に更新されます。
- SELinux ポリシーは、IdM ホストベースのアクセス制御ルールのようなドメイン全体のセキュリティーポリシーと関連付けて計画することができます。
- 管理者は環境全体にわたる可視性を持ち、SELinux でユーザーやシステムが割り当てられる方法を制御します。
pam_selinux モジュールと機能します。リモートユーザーがマシンにログインを試みると、SSSD はその IdM ID プロバイダーをチェックして、SELinux マップを含むユーザー情報を収集します。すると PAM モジュールはこのユーザーを処理し、適切な SELinux ユーザーコンテキストを割り当てます。
- unconfined_u (IdM ユーザーにデフォルトとして使用)
- guest_u
- xguest_u
- user_u
- staff_u
注記
31.2. SELinux ユーザーマップの順序とデフォルト値の設定
SELinux_username:MLS[:MCS]
注記
31.2.1. Web UI での設定
- トップメニューで IPA Server メインタブをクリックし、Configuration サブタブをクリックします。
- SELINUX OPTIONS まで、サーバー設定エリア一覧でスクロールダウンします。
- SELinux ユーザー設定を行います。編集可能なのは、SELinux ユーザーの優先度リストと、マッピングされていない IdM ユーザーに使用するデフォルト SELinux ユーザーの 2 つのエリアです。SELinux user map order では、ローカルの Linux システムで定義された SELinux ユーザー一覧を提供します。この一覧は、マッピングルールの設定に使用可能です。これは制限の高いものから低いものの順に並んだ優先度の一覧です。各 SELinux ユーザーは、SELinux_user:MLS という形式になります。Default SELinux user フィールドでは、マッピングされていない IdM ユーザーが使用する SELinux ユーザーを設定します。

- ページ上部にある Update をクリックして変更を保存します。
31.2.2. コマンドラインでの設定
[jsmith@server ~]$ ipa config-show ... 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
config-mod コマンドで編集できます。
例31.1 SELinux ユーザーの一覧
--ipaselinuxusermaporder オプションで、SELinux ユーザーの完全一覧を渡します。この一覧では、ユーザーを制限の高い方から低い方の順序で、優先度の順序を設定します。
SELinux_user:MLS:MCS
[jsmith@server ~]$ ipa config-mod --ipaselinuxusermaporder="unconfined_u:s0-s0:c0.c1023$guest_u:s0$xguest_u:s0$user_u:s0-s0:c0.c1023$staff_u:s0-s0:c0.c1023"
注記
例31.2 デフォルトの SELinux ユーザー
unconfined_u です。
--ipaselinuxusermapdefault で変更できます。例を示します。
[jsmith@server ~]$ ipa config-mod --ipaselinuxusermapdefault="guest_u:s0"
31.3. SELinux ユーザーの IdM ユーザーへのマッピング
31.3.1. Web UI での設定
- トップメニューで Policy メインタブをクリックし、SELinux User Maps サブタブをクリックします。
- マッピングのリストで をクリックして新規マップを作成します。

- IdM サーバー設定で表示されるものと全く同一になるようにマップと SELinux ユーザーの名前を入力します。SELinux ユーザーの形式は、SELinux_username:MLS[:MCS] となります。

- をクリックして IdM ユーザー情報を追加します。
- ホストベースのアクセス制御ルールを設定するには、設定の General エリアでドロップダウンメニューからルールを選択します。ホストベースのアクセス制御ルールを使用すると、リモートユーザーがターゲットマシンにアクセスする際に使用するホストでアクセス制御が導入されます。割り当て可能なホストベースのアクセス制御ルールは、1 つのみです。
注記
ホストベースのアクセス制御ルールには、サービスだけでなく、ユーザーとホストも含める必要があります。
別の方法では、Users と Hosts のエリアでスクロールダウンし、Add をクリックしてユーザー、ユーザーグループ、ホスト、もしくはホストグループを SELinux マップに割り当てます。
左側のユーザー (またはホストもしくはグループ) を選択し、右矢印 をクリックして Prospective コラムに移動します。 をクリックして、それらをルールに追加します。
注記
ホストベースのアクセス制御ルールを提供するか、ユーザーおよびホストを手動で設定するかのどちらになります。両方のオプションを同時に使用することはできません。 - 上部の Update をクリックして、SELinux ユーザーマップへの変更を保存します。
31.3.2. コマンドラインでの設定
- SELinux ユーザー (
--selinuxuser) - SELinux ユーザーに関連付けられたユーザーもしくはユーザーグループ (
--usersまたは--groups) - SELinux ユーザーに関連付けられたホストもしくはホストグループ (
--hostsまたは--hostgroups) - 代替方法として、ホストおよびユーザーを指定しているホストベースのアクセス制御ルール (
--hbacrule)
selinuxusermap-add コマンドを使うと、すべての情報があるルールを 1 度で作成できます。selinuxusermap-add-user および selinuxusermap-add-host のコマンドを使用すると、ルール作成後にユーザーとホストをそれぞれ追加できます。
例31.3 新規 SELinux マップの作成
--selinuxuser の値は、IdM サーバー設定で表示される SELinux ユーザー名と全く同一にする必要があります。SELinux ユーザーの形式は、SELinux_username:MLS[:MCS] となります。
[jsmith@server ~]$ ipa selinuxusermap-add --users=jsmith --users=bjensen --users=jrockford --hosts=server.example.com --hosts=test.example.com --selinuxuser="xguest_u:s0" selinux1
例31.4 ホストベースのアクセス制御ルールでの SELinux マップ作成
--hbacrule の値は、マッピングに使用するホストベースのアクセス制御ルールを特定します。ホストベースのアクセス制御ルールを使用すると、リモートユーザーがターゲットマシンにアクセスする際に使用するホストでアクセス制御が導入されます。また、リモートユーザーがターゲットマシンにログインすると、SELinux コンテキストが適用されます。
[jsmith@server ~]$ ipa selinuxusermap-add --hbacrule=webserver --selinuxuser="xguest_u:s0" selinux1
例31.5 ユーザーを SELinuxマッピングに追加する
selinuxusermap-add-user または selinuxusermap-add-host のコマンドを使用します。
[jsmith@server ~]$ ipa selinuxusermap-add-user --users=jsmith selinux1
selinuxusermap-mod コマンドを --hbacrule オプションと使用すると、ホストベースのアクセス制御ルールが追加されるか、既存のものが上書きされます。
例31.6 ユーザーの SELinuxマッピングからの削除
selinuxusermap-remove-host または selinuxusermap-remove-user のコマンドを実行します。例を示します。
[jsmith@server ~]$ ipa selinuxusermap-remove-user --users=jsmith selinux1
パート VII. ネットワークサービスの管理
第32章 DNS の管理
32.1. Identity Management における BIND
注記
chroot 環境内で実行することはできません。
bind-dyndb-ldap プラグインを使って Directory Server と通信します。IdM は BIND 向けに /etc/named.conf ファイル内に dynamic-db 設定セクションを作成します。これは、BIND named-pkcs11 サービス用の bind-dyndb-ldap プラグインを設定するものです。
client1.example.com. ドメイン名には 3 つの A レコードと AAAA レコードが 1 つ含まれています。
dn: idnsname=client1,idnsname=example.com.,cn=dns,dc=idm,dc=example,dc=com objectclass: top objectclass: idnsrecord idnsname: client1 Arecord: 192.0.2.1 Arecord: 192.0.2.2 Arecord: 192.0.2.3 AAAArecord: 2001:DB8::ABCD
重要
32.2. サポートされる DNS ゾーンタイプ
注記
- Master DNS ゾーン
- Master DNS ゾーンには権威 DNS データが含まれており、動的な DNS 更新を受け付けることができます。この動作は、標準の BIND 設定における
type master設定と同等のものです。Master ゾーンは、ipa dnszone-*コマンドを使って管理します。標準の DNS ルールに従い、各 master ゾーンには SOA と NS のレコードを含める必要があります。DNS ゾーンの作成時に IdM は自動的にこれらのレコードを生成しますが、NS レコードは手動で親ゾーンにコピーして適切な委任を作成する必要があります。標準の BIND 動作に従い、master ゾーンに指定された転送設定は、サーバーに権威のない名前にのみ影響します。例32.1 DNS 転送の例
IdM サーバーもtest.example.master ゾーンが含まれているとします。このゾーンには、sub.test.example.名の NS 委任レコードが含まれています。また、test.example.ゾーンでは、192.0.2.254というフォワーダー IP アドレスが設定されています。nonexistent.test.example.という名前をクエリーするクライアントはNXDomainという応答を受け取り、転送は発生しません。これはこの名前に対して IdM サーバーが権威があるためです。一方、sub.test.example.という名前に対するクエリーは、設定された192.0.2.254というフォワーダーに転送されます。これは、IdM サーバーがこの名前に対して権限がないためです。 - 正引き DNS ゾーン
- 正引き DNS ゾーンには権威 DNS データが含まれていません。正引き DNS ゾーンに属する名前へのクエリーはすべて、指定されたフォワーダーに転送されます。この動作は、標準の BIND 設定における
type forward設定と同等のものです。Forward ゾーンは、ipa dnsforwardzone-*コマンドを使って管理します。
32.3. DNS 設定の優先順位
- ゾーン固有の設定
- IdM 内で定義された特定ゾーンに固有の設定レベルが、最も高い優先順位になります。ゾーン固有の設定は、
ipa dnszone-*およびipa dnsforwardzone-*コマンドを使って管理します。 - グローバル DNS 設定
- ゾーン固有の設定が定義されていない場合、IdM は LDAP に保存されているグローバル DNS 設定を使用します。グローバル DNS 設定は、
ipa dnsconfig-*コマンドを使って管理します。グローバル DNS 設定で定義されている設定は、すべての IdM DNS サーバーに適用されます。 /etc/named.confでの設定- 各 IdM DNS サーバーにある
/etc/named.confファイルで定義されている設定は、優先順位が一番低くなります。これは各サーバーに固有のもので、手動で編集する必要があります。/etc/named.confファイルは通常、ローカル DNS キャッシュへの DNS 転送を指定するためにのみ使用されます。他のオプションは、上記のゾーン固有およびグローバル DNS 設定のコマンドを使用して管理します。
32.4. Master DNS ゾーンの管理
32.4.1. Master DNS ゾーンの追加と削除
Web UI での Master DNS ゾーンの追加
- Network Services タブから DNS サブタブを開き、DNS Zones セクションを選択します。

図32.1 Master DNS ゾーンの管理
- 新規の master ゾーンを追加するには、全ゾーン一覧上部にある をクリックします。

図32.2 Master DNS ゾーンの追加
- ゾーン名を入力して をクリックします。

図32.3 新規 Master ゾーンの入力
コマンドラインからの Master DNS ゾーンの追加
ipa dnszone-add コマンドで、新規ゾーンが DNS ドメインに追加されます。新規ゾーンを追加するには、新規サブドメインの名前を指定する必要があります。下記のようにこのコマンドでサブドメイン名を直接渡すことができます。
$ ipa dnszone-add newserver.example.com
ipa dnszone-add で名前を渡さない場合は、スクリプトが自動的にこれを要求します。
ipa dnszone-add コマンドは各種のコマンドラインオプションも受け付けます。オプションの完全一覧を確認するには、ipa dnszone-add --help コマンドを実行してください。
Master DNS ゾーンの削除

図32.4 Master DNS ゾーンの削除
ipa dnszone-del コマンドを実行します。
$ ipa dnszone-del server.example.com
32.4.2. マスター DNS ゾーンの追加設定
DNS ゾーン設定の属性
表32.1 ゾーン属性
| 属性 | コマンドラインオプション | 説明 |
|---|---|---|
| Authoritative name server | --name-server |
マスター DNS ネームサーバーのドメイン名 (SOA MNAME とも呼ぶ) を設定します。
デフォルトでは、各 IdM サーバーが自身を SOA MNAME フィールドに公開します。この結果、
--name-server を使用して LDAP に保存された値は無視されます。
|
| Administrator e-mail address | --admin-email | ゾーン管理者が使用する電子メールアドレスを設定します。デフォルトでは、ホストの root アカウントになります。 |
| SOA serial | --serial | Sets a serial number in the SOA レコードのシリアル番号を設定します。IdM はバージョン番号を自動的に設定し、これはユーザーが編集しないことになっています。 |
| SOA refresh | --refresh | セカンダリー DNS サーバーがプライマリ DNS サーバーから更新を要求するまでの待機時間を秒単位で設定します。 |
| SOA retry | --retry | 失敗したリフレッシュ動作を再試行するまでの待機時間を秒単位で設定します。 |
| SOA expire | --expire | セカンダリー DNS サーバーがリフレッシュ更新を試行して、その動作を停止するまでの時間を秒単位で設定します。 |
| SOA minimum | --minimum | RFC 2308 に従って、ネガティブキャッシュの有効時間 (TTL) の値を秒単位で設定します。 |
| SOA time to live | --ttl | ゾーン apex のレコードの TTL を秒単位で設定します。たとえば、ゾーン example.com では、example.com 名の全レコード (A、NS、または SOA) が設定されますが、test.example.com のような他のドメイン名は影響を受けません。 |
| Default time to live | --default-ttl | 個別の TTL 値が設定されたことのないゾーンの全値について、ネガティブキャッシュの有効時間 (TTL) のデフォルト値を秒単位で設定します。変更を反映するには、全 IdM DNS サーバーで named-pkcs11 サービスを再起動する必要があります。 |
| BIND update policy | --update-policy |
DNS ゾーンでクライアントに許可されるパーミッションを設定します。
更新ポリシーの構文については、Dynamic Update Policies in the 『BIND 9 Administrator Reference Manual』 を参照してください。
|
| Dynamic update | --dynamic-update=TRUE|FALSE | クライアントの DNS レコードへの動的更新を有効にします。
これを false に設定すると、IdM クライアントマシンは IP アドレスの追加や更新ができなくなります。詳細情報は、「動的 DNS 更新の有効化」 を参照してください。
|
| Allow transfer | --allow-transfer=string |
指定されたゾーンの転送が可能な IP アドレスまたはネットワーク名をセミコロン区切りのリストで提供します。
ゾーン転送はデフォルトでは無効になっています。
--allow-transfer のデフォルト値は none です。
|
| Allow query | --allow-query | DNS クエリーの発行が可能な IP アドレスまたはネットワーク名をセミコロン区切りのリストで提供します。 |
| Allow PTR sync | --allow-sync-ptr=1|0 | ゾーンの A または AAAA レコード (正引きレコード) が自動的に PTR (逆引き) レコードと同期されるかどうかを設定します。 |
| Zone forwarders | --forwarder=IP_address | DNS ゾーン向けに特別に設定されたフォワーダーを指定します。これは、IdM ドメインで使用されるグローバルのフォワーダーとは別のものです。
複数のフォワーダーを指定するには、このオプションを複数回使用します。
|
| Forward policy | --forward-policy=none|only|first | 転送ポリシーを指定します。サポートされるポリシーについての情報は、「転送ポリシー」 を参照してください。 |
Web UI でのゾーン設定編集

図32.5 Master DNS ゾーンの管理
- ゾーンの全一覧からゾーン名をクリックして DNS ゾーンページを開きます。

図32.6 マスターゾーンの編集
- Settings をクリックして、ゾーン設定を変更します。

図32.7 マスターゾーン編集ページの Settings タブ
利用可能な設定については、表32.1「ゾーン属性」 を参照してください。 - をクリックして新規設定を保存します。
注記
named-pkcs11 サービスを再起動する必要があります。その他の設定は、即座に有効になります。
コマンドラインでのゾーン設定編集
ipa dnszone-mod コマンドを使用します。利用可能な設定については、表32.1「ゾーン属性」 を参照してください。
ipa dnszone-mod コマンドは属性を追加します。属性がある場合は、指定された値で現行の値を上書きします。
ipa dnszone-mod コマンドおよびそのオプションについての詳細は、ipa dnszone-mod --help コマンドを実行してください。
注記
named-pkcs11 サービスを再起動する必要があります。その他の設定は、即座に有効になります。
32.4.3. ゾーン転送の有効化
重要
UI でのゾーン転送の有効化

図32.8 ゾーン転送の有効化
コマンドラインでのゾーン転送の有効化
--allow-transfer オプションを ipa dnszone-mod コマンドに追加します。以下のように、--allow-transfer を使ってゾーンレコードを転送するネームサーバーの一覧を指定します。
[user@server ~]$ ipa dnszone-mod --allow-transfer=192.0.2.1;198.51.100.1;203.0.113.1 example.com
bind サービス内でゾーン転送を有効にすると、dig ユーティリティーのようなクライアントで IdM DNS ゾーンを名前で転送できるようになります。
[root@server ~]# dig @ipa-server zone_name AXFR
32.4.4. DNS ゾーンへのレコードの追加
- A
- これはホスト名および通常の IPv4 アドレスの基本的なマップです。A レコードのレコード名は、
wwwなどのホスト名です。IP Address の値は、192.0.2.1などの標準的な IPv4 アドレスになります。A レコードに関する詳細情報は、RFC 1035 を参照してください。 - AAAA
- これはホスト名および IPv6 アドレスの基本的なマップです。AAAA レコードのレコード名は、
wwwなどのホスト名です。IP Address の値は、2001:DB8::1111などの 16 進数の標準的な IPv6 アドレスになります。AAAA レコードに関する詳細情報は、RFC 3596 を参照してください。 - SRV
- サービス (SRV) リソースレコードは、サービス名を、その特定サービスを提供するサーバーの DNS 名にマッピングします。たとえば、このタイプのレコードは LDAP ディレクトリーのようなサービスを管理するサーバーに、このサービスをマッピングします。SRV レコードのレコード名は
_service._protocolという形式になり、たとえば_ldap._tcpとなります。SRV レコードの設定オプションには、優先順位、加重、ポート番号、およびターゲットサービスのホスト名などがあります。SRV レコードに関する詳細情報は、RFC 2782 を参照してください。 - PTR
- ポインター (PTR) レコードは、IP アドレスをドメイン名にマッピングする逆引き DNS レコードを追加します。
注記
IPv4 アドレスの逆引き DNS ルックアップはすべて、in-addr.arpa.ドメインで定義される逆引きエントリーを使用します。ヒューマンリーダブルな形式の逆アドレスは、通常の IP とまったく逆のもので、in-addr.arpa.ドメインが最後に付いています。たとえば、ネットワークアドレス192.0.2.0/24の逆引きゾーンは、2.0.192.in-addr.arpaになります。PTR レコードのレコード名は、RFC 1035、RFC 2317、および RFC 3596 に指定されている標準形式である必要があります。ホスト名の値は、レコードを作成するホストの正規のホスト名である必要があります。詳細は 例32.8「PTR レコード」 を参照してください。注記
.ip6.arpa.ドメイン内のゾーンについても、IPv6 アドレスの逆引きゾーンを設定できます。IPv6 逆引きゾーンについての詳細情報は、RFC 3596 を参照してください。
DNS のワイルドカードのサポート
* をワイルドカードとしてサポートします。
例32.2 DNS ワイルドカードの例
- DNS ゾーン example.com で以下を設定します。
- ワイルドカード A レコード
*.example.com mail.example.comの MX レコード。ただし、このホストでは A レコードなしとします。demo.example.comではレコードなしとします。
- 既存および存在しない DNS レコードとタイプをクエリーシマス。以下の結果が返されます。
# host -t MX mail.example.com. mail.example.com mail is handled by 10 server.example.com. # host -t MX demo.example.com. demo.example.com. has no MX record. # host -t A mail.example.com. mail.example.com has no A record # host -t A demo.example.com. random.example.com has address 192.168.1.1
Web UI での DNS リソースレコードの追加
- 「Web UI でのゾーン設定編集」 にあるように DNS ゾーンページを開きます。
- DNS Resource Records セクションで、 をクリックして新規レコードを追加します。

図32.9 新規 DNS リソースレコードの追加
- 作成するレコードタイプを選択し、必要なフィールドに入力します。

図32.10 新規 DNS リソースレコードの定義
- をクリックして新規レコードを保存します。
コマンドラインでの DNS リソースレコードの追加
ipa dnsrecord-add コマンドを以下の構文で使用します。
$ ipa dnsrecord-add zone_name record_name --record_type_option=data
ipa dnsrecord-add オプション」 では、A (IPv4)、AAAA (IPv6)、SRV、および PTR という一般的なリソースレコードのタイプのオプションを示しています。エントリーのリストは、同一コマンドでオプションを複数回使用して設定するか、Bash では --option={val1,val2,val3} のように中括弧内にオプションをコンマ区切りの一覧で記載します。
ipa dnsrecord-add の使用方法および IdM がサポートする DNS レコードタイプについての詳細情報は、ipa dnsrecord-add --help コマンドを実行してください。
表32.2 一般的な ipa dnsrecord-add オプション
| 全般的なレコードのオプション | |
|---|---|
| オプション | 説明 |
--ttl=number | レコードの有効期間を設定します。 |
--structured | raw DNS レコードを解析し、それらを構造化された形式で返します。 |
| "A" レコードのオプション | |
|---|---|
| オプション | 説明 |
--a-rec=ARECORD | A レコードのリストを渡します。 |
--a-ip-address=string | レコードの IP アドレスを渡します。 |
| "AAAA" レコードのオプション | |
|---|---|
| オプション | 説明 |
--aaaa-rec=AAAARECORD | AAAA (IPv6) レコードのリストを渡します。 |
--aaaa-ip-address=string | レコードの IPv6 アドレスを渡します。 |
| "PTR" レコードのオプション | |
|---|---|
| オプション | 説明 |
--ptr-rec=PTRRECORD | PTR レコードのリストを渡します。 |
--ptr-hostname=string | レコードのホスト名を渡します。 |
| "SRV" レコードのオプション | |
|---|---|
| オプション | 説明 |
--srv-rec=SRVRECORD | SRV レコードのリストを渡します。 |
--srv-priority=number | レコードの優先順位を設定します。あるサービスタイプに複数の SRV レコードがある場合もあります。優先順位 (0 - 65535) はレコードの階級を設定し、数字が小さいほど優先順位が高くなります。サービスは、優先順位の最も高いレコードを最初に使用する必要があります。 |
--srv-weight=number | レコードの加重を設定します。これは、SRV レコードの優先順位が同じ場合に順序を判断する際に役立ちます。設定された加重は最大 100 とし、これは特定のレコードが使用される可能性をパーセンテージで示しています。 |
--srv-port=number | ターゲットホスト上のサービスのポートを渡します。 |
--srv-target=string | ターゲットホストのドメイン名を提供します。該当サービスがドメイン内で利用可能でない場合は、単一のピリオド (.) にすることもできます。 |
32.4.5. コマンドラインからの DNS リソースレコードの追加および修正
例32.3 IPv4 レコードの追加
www.example.com が IP アドレス 192.0.2.123 で作成されます。
$ ipa dnsrecord-add example.com www --a-rec 192.0.2.123
例32.4 IPv4 ワイルドカードレコードの追加
192.0.2.123 で作成されます。
$ ipa dnsrecord-add example.com "*" --a-rec 192.0.2.123
例32.5 IPv4 レコードの修正
--a-record です。ただし、A レコード修正時には --a-record オプションはそのレコードの現在の値を指定します。新しい値は --a-ip-address オプションで設定します。
$ ipa dnsrecord-mod example.com www --a-rec 192.0.2.123 --a-ip-address 192.0.2.1
例32.6 IPv6 レコードの追加
www.example.com が IP アドレス 2001:db8::1231:5675 で作成されます。
$ ipa dnsrecord-add example.com www --aaaa-rec 2001:db8::1231:5675
例32.7 SRV レコードの追加
_ldap._tcp が SRV レコードのサービスタイプと接続プロトコルを定義します。--srv-rec オプションで優先順位、加重、ポート、およびターゲットの値を定義します。
[root@server ~]# ipa dnsrecord-add server.example.com _ldap._tcp --srv-rec="0 51 389 server1.example.com." [root@server ~]# ipa dnsrecord-add server.example.com _ldap._tcp --srv-rec="1 49 389 server2.example.com."
51 と 49) では最大 100 が追加され、これは特定のレコードが使用される可能性をパーセンテージで示しています。
例32.8 PTR レコード
ipa dnsrecord-add コマンドで使用されるゾーン名も逆になります。
$ ipa dnsrecord-add reverseNetworkIpAddress hostIpAddress --ptr-rec FQDN
server4.example.com の PTR レコードが追加されます。
$ ipa dnsrecord-add 2.0.192.in-addr.arpa 4 --ptr-rec server4.example.com.
2001:DB8::1111 のホスト server2.example.com の 0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa. IPv6 逆引きゾーンに追加されます。
$ ipa dnsrecord-add 0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa. 1.1.1.0.0.0.0.0.0.0.0.0.0.0.0 --ptr-rec server2.example.com.
32.4.6. DNS ゾーンからレコードを削除する
Web UI によるレコード削除
- 「Web UI でのゾーン設定編集」 にあるように DNS ゾーンページを開きます。
- DNS Resource Records セクションで、リソースレコードの名前をクリックします。

図32.11 DNS リソースレコードの選択
- 削除するレコードタイプの名前にチェックを入れます。

図32.12 DNS リソースレコードの削除
これで選択したレコードタイプのみが削除され、他の設定は有効なままになります。
- 「Web UI でのゾーン設定編集」 にあるように DNS ゾーンページを開きます。
- DNS Resource Records セクションで、削除するリソースレコードの名前の横にあるチェックボックスを選択し、 をクリックします。

図32.13 リソースレコード全体の削除
これでリソースレコード全体が削除されます。
コマンドラインからのレコード削除
ipa dnsrecord-del コマンドに --recordType-rec オプションとレコードの値を渡します。
$ ipa dnsrecord-del example.com www --a-rec 192.0.2.1
ipa dnsrecord-del を実行すると、削除するレコードについての情報が要求されます。このコマンドを --del-all オプションと使用すると、ゾーンの関連する全レコードが削除されることに注意してください。
ipa dnsrecord-del コマンドの使用方法および使用可能なオプションの完全一覧については、ipa dnsrecord-del --help コマンドを実行してください。
32.4.7. ゾーンの有効化および無効化
Web UI でのゾーンの有効化および無効化

図32.14 DNS ゾーンの管理

図32.15 DNS ゾーンの無効化
コマンドラインからの DNS ゾーンの無効化および有効化
ipa dnszone-disable コマンドを実行します。
[user@server ~]$ ipa dnszone-disable zone.example.com ----------------------------------------- Disabled DNS zone "example.com" -----------------------------------------
ipa dnszone-enable コマンドを実行します。
32.5. 動的 DNS 更新の管理
32.5.1. 動的 DNS 更新の有効化
ipa-client-install スクリプトは新規クライアントをポイントする DNS レコードを追加することができません。
注記
- DNS ゾーンで動的更新を許可する設定にする
- ローカルクライアントが動的更新を送信するように設定する
32.5.1.1. DNS ゾーンで動的更新を許可する設定
Web UI での動的 DNS 更新の有効化
- Network Services タブから DNS サブタブを開き、DNS Zones セクションを選択します。

図32.16 DNS ゾーンの管理
- ゾーンの全一覧からゾーン名をクリックして DNS ゾーンページを開きます。

図32.17 マスターゾーンの編集
- Settings をクリックして DNS ゾーン設定タブに切り替えます。

図32.18 マスターゾーン編集ページの Settings タブ
- Dynamic update フィールドまでスクロールして、値を True に設定します。

図32.19 動的 DNS 更新の有効化
- ページ上部にある をクリックして新規設定を保存します。
コマンドラインからの動的 DNS 更新の有効化
ipa dnszone-mod コマンドを --dynamic-update=TRUE オプションと使用します。
[user@server ~]$ ipa dnszone-mod server.example.com --dynamic-update=TRUE
32.5.1.2. クライアントが動的更新を送信する設定
ipa-client-install スクリプトで --enable-dns-updates オプションを使用すると、クライアントがドメインに登録される際に、クライアントが DNS 更新を送信するよう自動的に設定されます。
[root@client ~]# ipa-client-install --enable-dns-updates
- SSSD 設定ファイルを開きます。
[root@server ~]# vim /etc/sssd/sssd.conf
- IdM ドメインのドメインセクションを見つけます。
[domain/ipa.example.com]
- クライアントの動的更新が有効になっていない場合は、
dyndns_updateの値を true にします。dyndns_updates = true
dyndns_ttlパラメーターの値を秒単位で追加または編集します。dyndns_ttl = 2400
32.5.2. A/AAAA と PTR レコードの同期
- 正引きおよび逆引きゾーンの両方が IdM サーバーで管理されていること。
- 両方のゾーンで動的更新が有効になっていること。動的更新の有効化については、「動的 DNS 更新の有効化」 で説明されています。
- PTR 同期が逆引きゾーンではなく、マスターの正引きゾーンで有効になっていること。
- PTR レコードは、要求しているクライアント名が PTR レコード内の名前と一致する場合にのみ、更新されます。
重要
警告
Web UI による PTR レコード同期の設定
- Network Services タブから DNS サブタブを開き、DNS Zones セクションを選択します。

図32.20 DNS ゾーンの管理
- ゾーンの全一覧からゾーン名をクリックして DNS ゾーンページを開きます。

図32.21 DNS ゾーンの編集
- Settings をクリックして DNS ゾーン設定タブに切り替えます。

図32.22 マスターゾーン編集ページの Settings タブ
- Allow PTR sync チェックボックスを選択します。

図32.23 PTR 同期の有効化
- ページ上部にある をクリックして新規設定を保存します。
コマンドラインからの PTR レコード同期の設定
--allow-sync-ptr オプションを 1 に設定します。たとえば、以下のように ipa dnszone-mod コマンドを使って既存のゾーンを編集します。
[user@server ~]$ ipa dnszone-mod --allow-sync-ptr=1 zone.example.com
--allow-sync-ptr のデフォルト値は 0 で、この場合は同期が無効になります。
32.5.3. DNS 動的更新ポリシーの更新
/etc/named.conf ファイル内の update-policy ステートメントと同じ構文になります。動的更新ポリシーについての詳細は、BIND 9 documentation を参照してください。
Web UI による DNS 更新ポリシーの更新
- Network Services タブから DNS サブタブを開き、DNS Zones セクションを選択します。

図32.24 DNS ゾーンの管理
- ゾーンの全一覧からゾーン名をクリックして DNS ゾーンページを開きます。

図32.25 DNS ゾーンの編集
- Settings をクリックして DNS ゾーン設定タブに切り替えます。

図32.26 マスターゾーン編集ページの Settings タブ
- BIND update policy テキストボックス内のセミコロン区切りのリストで、必要な更新ポリシーを設定します。

図32.27 DNS 更新ポリシーの設定
- DNS ゾーンページ上部にある をクリックして新規設定を保存します。
コマンドラインからの DNS 更新ポリシーの更新
--update-policy オプションを使用して、その後のステートメントにアクセス制御ルールを追加します。例を示します。
$ ipa dnszone-mod zone.example.com --update-policy "grant EXAMPLE.COM krb5-self * A; grant EXAMPLE.COM krb5-self * AAAA; grant EXAMPLE.COM krb5-self * SSHFP;"
32.6. DNS 転送の管理
- DNS サーバーが異なるクライアントに異なる応答をする Split DNS 設定または DNS views 設定となっている場合。Split DNS 設定は、いくつかの DNS 名が企業ネットワーク内では利用可能になっているものの、外部からは利用できないという環境でよく使われています。
- インターネット上の DNS へのアクセスをファイアウォールが制限している設定。
- DNS レベルでのフィルタリングやロギングが集中化されている設定。
- ローカル DNS キャッシュへの転送でネットワークトラフィックの最適化を図っている設定。
転送ポリシー
- Forward first (デフォルト)
- DNS クエリーは設定済みフォワーダーに転送されます。サーバーエラーやタイムアウトでクエリーが失敗すると、BIND はインターネット上のサーバーを使用する再帰解決にフォールバックします。forward first はデフォルトのポリシーで、トラフィックを最適化します。
- Forward only
- DNS クエリーは設定済みフォワーダーに転送されます。サーバーエラーやタイムアウトでクエリーが失敗すると、BIND はクライアントにエラーを返します。forward only ポリシーは、split DNS 環境で推奨されます。
- None: 転送の無効化
- DNS クエリーは転送されません。転送の無効化は、グローバルの転送設定でゾーン固有の上書きとしてのみ、役に立ちます。このオプションは、BIND 設定でフォワーダーの空のリストを指定する IdM と同等のものです。
転送は IdM と他の DNS サーバーからのデータを結合しない
例32.9 シナリオ例
test.example. DNS ゾーンに対して権威があります。BIND は、192.0.2.254 IP アドレスの DNS サーバーにクエリーを転送するように設定されています。
nonexistent.test.example. DNS 名 のクエリーを送信すると、BIND は IdM サーバーが test.example. ゾーンに対して権威があることを検出し、192.0.2.254. サーバーにクエリーを転送しません。このため、DNS クライアントは NXDomain の応答を受信し、クエリーされたドメインが存在しないことをユーザーに知らせます。
32.6.1. グローバルフォワーダーの設定
- IdM Web UI での
ipa dnsconfig-modコマンドの使用 - これらのネイティブ IdM ツールを使用した設定は、全 IdM DNS サーバーに即座に適用されます。「DNS 設定の優先順位」 の説明にあるように、グローバル DNS の設定は、
/etc/named.confファイルで定義されたローカル設定よりも優先度が高くなります。 /etc/named.confファイルの編集- 各 IdM DNS 上の
/etc/named.confを手動で編集すると、サーバーごとに異なるグローバルフォワーダーとポリシーを使用できるようになります。/etc/named.confの変更後に BIND サービスを再起動する必要があることに注意してください。
Web UI でのフォワーダーの設定
- Network Services タブをクリックして DNS サブタブを開き、DNS Global Configuration セクションを選択します。
- 新規のグローバルフォワーダーを追加するには、 をクリックして IP アドレスを入力します。新規の転送ポリシーを定義するには、利用可能なポリシー一覧から選択します。

図32.28 Web UI でのグローバル DNS 設定の編集
- をクリックして新規設定を保存します。
コマンドラインからのフォワーダー設定
ipa dnsconfig-mod コマンドを使用します。これは、LDAP データを編集することで DNS グローバル設定を編集します。ipa dnsconfig-mod コマンドおよびそのオプションは、即座に全 IdM DNS サーバーに反映され、ローカル設定を上書きします。
ipa dnsconfig-mod を使います。
[user@server ~]$ ipa dnsconfig-mod --forwarder=192.0.2.254 Global forwarders: 192.0.2.254
32.6.2. 正引きゾーンの設定
重要
/usr/share/doc/bind-version_number/ ディレクトリーにある BIND 9 Administrator Reference Manual、または外部ソース [5]。
Web UI での正引きゾーンの設定

図32.29 DNS 正引きゾーンの管理
コマンドラインからの正引きゾーンの設定
ipa dnsforwardzone-* コマンドを使用します。
注記
ipa dnsforwardzone-* コマンドは、マスターゾーンの管理に使用する ipa dnszone-* コマンドと同様の動作をします。
ipa dnsforwardzone-* コマンドは、--forwarder、--forward-policy、および --name-from-ip などのオプションを受け付けます。利用可能なオプションについての詳細情報は、表32.1「ゾーン属性」 を参照するか、以下のようにコマンドに --help オプションを追加して実行してください。
ipa dnsforwardzone-add --help
- 正引きゾーンの追加
dnsforwardzone-addコマンドを使って新規の正引きゾーンを追加します。転送ポリシーがnoneに設定されている場合を除いて、少なくとも 1 つのフォワーダーを指定する必要があります。[user@server ~]$ ipa dnsforwardzone-add zone.test. --forwarder=172.16.0.1 --forwarder=172.16.0.2 --forward-policy=first Zone name: zone.test. Zone forwarders: 172.16.0.1, 172.16.0.2 Forward policy: first
- 正引きゾーンの修正
dnsforwardzone-modコマンドを使って正引きゾーンを修正します。転送ポリシーがnoneに設定されている場合を除いて、少なくとも 1 つのフォワーダーを指定する必要があります。修正は以下のいずれかの方法で実行できます。[user@server ~]$ ipa dnsforwardzone-mod zone.test. --forwarder=172.16.0.3 Zone name: zone.test. Zone forwarders: 172.16.0.3 Forward policy: first
[user@server ~]$ ipa dnsforwardzone-mod zone.test. --forward-policy=only Zone name: zone.test. Zone forwarders: 172.16.0.3 Forward policy: only
- 正引きゾーンの表示
dnsforwardzone-showコマンドを使用して指定した正引きゾーンの情報を表示します。[user@server ~]$ ipa dnsforwardzone-show zone.test. Zone name: zone.test. Zone forwarders: 172.16.0.5 Forward policy: first
- 正引きゾーンの検索
dnsforwardzone-findコマンドを使用して指定した正引きゾーンを検索します。[user@server ~]$ ipa dnsforwardzone-find zone.test. Zone name: zone.test. Zone forwarders: 172.16.0.3 Forward policy: first ---------------------------- Number of entries returned 1 ----------------------------
- 正引きゾーンの削除
dnsforwardzone-delコマンドを使用して指定した正引きゾーンを削除します。[user@server ~]$ ipa dnsforwardzone-del zone.test. ---------------------------- Deleted forward DNS zone "zone.test." ----------------------------
- 正引きゾーンの有効化および無効化
dnsforwardzone-enableとdnsforwardzone-disableのコマンドを使用して正引きゾーンを有効化および無効化します。正引きゾーンはデフォルトでは有効化されています。[user@server ~]$ ipa dnsforwardzone-enable zone.test. ---------------------------- Enabled forward DNS zone "zone.test." ----------------------------
[user@server ~]$ ipa dnsforwardzone-disable zone.test. ---------------------------- Disabled forward DNS zone "zone.test." ----------------------------
- パーミッションの追加および削除
dnsforwardzone-add-permissionとdnsforwardzone-remove-permissionのコマンドを使用してシステムのパーミッションを追加または削除します。[user@server ~]$ ipa dnsforwardzone-add-permission zone.test. --------------------------------------------------------- Added system permission "Manage DNS zone zone.test." --------------------------------------------------------- Manage DNS zone zone.test.
[user@server ~]$ ipa dnsforwardzone-remove-permission zone.test. --------------------------------------------------------- Removed system permission "Manage DNS zone zone.test." --------------------------------------------------------- Manage DNS zone zone.test.
32.7. 逆引き DNS ゾーンの管理
reverse_ipv4_address.in-addr.arpaまたはreverse_ipv6_address.ip6.arpaという形式のゾーン名。逆引き IP アドレスは、IP アドレスの要素を反転させて作成します。たとえば、IPv4 ネットワークが192.0.2.0/24の場合、逆引きゾーン名は2.0.192.in-addr.arpa.になります (最後のピリオドを含む)。network_ip_address/subnet_mask_bit_countの形式でのネットワークアドレス。ゾーンを IP ネットワークで作成するには、ネットワーク情報をサブネットマスクのビットカウントが付いた (正引きスタイルの) IP アドレスに設定します。ビットカウントは、IPv4 アドレスの場合は 8 の倍数、IPv6 アドレスの場合は 4 の倍数にします。
Web UI での逆引き DNS ゾーンの追加
- Network Services タブから DNS サブタブを開き、DNS Zones セクションを選択します。

図32.30 DNS ゾーンの管理
- 全ゾーン一覧上部にある をクリックします。

図32.31 逆引き DNS ゾーンの追加
- ゾーン名または逆引きゾーン IP ネットワークを入力します。
- たとえば、ゾーン名で逆引き DNS ゾーンを追加するには、以下のようにします。

図32.32 名前での逆引きゾーンの作成
- または、逆引きゾーン IP ネットワークで逆引き DNS ゾーンを追加するには、以下のようにします。

図32.33 IP ネットワークでの逆引きゾーンの作成
Reverse zone IP network フィールドの記入中には無効なネットワークアドレスについての警告が表示されますが、完全なネットワークアドレスが入力されるとこれは表示されなくなります。
- をクリックして新規逆引きゾーンを保存します。
コマンドラインからの逆引き DNS ゾーンの追加
ipa dnszone-add コマンドを実行します。
[user@server]$ ipa dnszone-add 2.0.192.in-addr.arpa.
[user@server ~]$ ipa dnszone-add --name-from-ip=192.0.2.0/24
逆引き DNS ゾーンの他の管理操作
32.8. DNS クエリーポリシーの定義
--allow-query オプションを使用した ipa dnszone-mod コマンドでクエリー発行が許可されるクライアントのリストを設定する際に、設定できます。
[user@server ~]$ ipa dnszone-mod --allow-query=192.0.2.0/24;2001:DB8::/32;203.0.113.1 example.com
--allow-query のデフォルト値は any で、この場合、ゾーンにはどのクライアントもクエリーを実行できます。
32.9. DNS の場所
32.9.1. DNS ベースのサービス検出
LDAP や Kerberos といった特定のサービスを提供するネットワーク内でサーバーの場所を特定するためにクライアントが DNS プロトコル使用するプロセスです。よくあるタイプの操作では、一番近いネットワークインフラストラクチャー内でクライアントが認証サーバーを特定するというものがあります。この場合、より高いスループットが提供される一方でネットワーク遅延は短くなり、総コストも抑えられます。
- クライアントを近くのサーバー名で明示的に設定する必要がない。
- DNS サーバーがポリシーの集中プロバイダーとして使用される。同一の DNS サーバーを使用するクライアントは、サービスプロバイダーについての同じポリシーとその優先順位についてアクセスできるようになります。
例32.10 DNS の場所の個別の結果
$ dig -t SRV +short _kerberos._tcp.idm.example.com 0 100 88 idmserver-01.idm.example.com. 0 100 88 idmserver-02.idm.example.com.
0(優先順位): ターゲットホストの優先順位。値が低いほど、優先順位が高くなります。100(加重): 優先順位が同じエントリーの相対的加重を指定します。詳細は RFC 2782, section 3 を参照してください。88(ポート番号): サービスのポート番号。- サービスを提供しているホストの正規名。
germany という場所にある DNS サーバーにクエリーを行なっています。
例32.11 DNS の場所ベースの結果
$ dig -t SRV +short _kerberos._tcp.idm.example.com _kerberos._tcp.germany._locations.idm.example.com. 0 100 88 idmserver-01.idm.example.com. 50 100 88 idmserver-02.idm.example.com.
idmserver-01.idm.example.com の優先順位の値が最も低いので、これが優先されます。idmserver-02.idm.example.com の優先順位の値は高いので、優先ホストが利用できない場合にのみ、バックアップとして使用されます。
32.9.2. デプロイメントでの DNS の場所についての考慮事項
32.9.2.1. DNS 有効期間 (TTL)
1 day です。
32.9.3. DNS の場所の作成
Web UI での DNS の場所の作成
- IPA Server タブを開いてから、Topology サブタブを選択します。
- ナビゲーションバーで IPA Locations をクリックします。
- 場所一覧上部にある をクリックします。
- 場所の名前を入力します。
- をクリックして場所を保存します。
コマンドラインからの DNS の場所の作成
germany を作成するには、以下を実行します。
[root@server ~]# ipa location-add germany ---------------------------- Added IPA location "germany" ---------------------------- Location name: germany
32.9.4. DNS の場所への IdM サーバーの割り当て
Web UI から IdM サーバーを DNS の場所に割り当てる手順
- IPA Server タブを開いてから、Topology サブタブを選択します。
- ナビゲーションバーで IPA Servers をクリックします。
- IdM サーバー名をクリックします。
- DNS の場所を選択し、オプションでサービスの加重を設定します。

図32.34 DNS の場所へのサーバーの割り当て
- をクリックします。
- 上記のステップで DNS の場所を割り当てたホスト上で
named-pkcs11サービスを再起動します。[root@idmserver-01 ~]# systemctl restart named-pkcs11
コマンドラインから IdM サーバーを DNS の場所に割り当てる手順
- オプション: 設定済み DNS の全場所を一覧表示します。
[root@server ~]# ipa location-find ----------------------- 2 IPA locations matched ----------------------- Location name: australia Location name: germany ----------------------------- Number of entries returned: 2 -----------------------------
- サーバーを DNS の場所に割り当てます。たとえば、
germanyにサーバー idmserver-01.idm.example.com を割り当てるには、以下を実行します。[root@server ~]# ipa server-mod idmserver-01.idm.example.com --location=germany ipa: WARNING: Service named-pkcs11.service requires restart on IPA server idmserver-01.idm.example.com to apply configuration changes. -------------------------------------------------- Modified IPA server "idmserver-01.idm.example.com" -------------------------------------------------- Servername: idmserver-01.idm.example.com Min domain level: 0 Max domain level: 1 Location: germany Enabled server roles: DNS server, NTP server
- 上記のステップで DNS の場所を割り当てたホスト上で
named-pkcs11サービスを再起動します。[root@idmserver-01 ~]# systemctl restart named-pkcs11
32.10. 外部 DNS の使用時に DNS レコードを組織的に更新する手順
- GUI で外部 DNS のレコードを管理する場合は、「GUI: 外部 DNS レコードの更新」
nsupdateユーティリティーを使用して外部 DNS のレコードを管理する場合は、「コマンドライン:nsupdateを使用した外部 DNS レコード更新」
32.10.1. Identity Management での外部 DNS の更新
- レプリカをインストールまたはアンインストールした後
- Identity Management サーバーで CA、DNS、KRA、または Active Directory の信頼をインストールした後
32.10.2. GUI: 外部 DNS レコードの更新
- 更新する必要のあるレコードを表示します。
ipa dns-update-system-records --dry-runコマンドを使用します。$
ipa dns-update-system-records --dry-runIPA DNS records: _kerberos-master._tcp.example.com. 86400 IN SRV 0 100 88 ipa.example.com. _kerberos-master._udp.example.com. 86400 IN SRV 0 100 88 ipa.example.com. [... output truncated ...] - 外部の DNS GUI を使用してレコードを更新します。
32.10.3. コマンドライン: nsupdate を使用した外部 DNS レコード更新
nsupdate 向けに DNS レコードのあるファイルを生成
ipa dns-update-system-records --dry-runコマンドに--outオプションを付けて実行します。このオプションは、生成するファイルのパスを指定します。$
ipa dns-update-system-records --dry-run --out dns_records_file.nsupdateIPA DNS records: _kerberos-master._tcp.example.com. 86400 IN SRV 0 100 88 ipa.example.com. _kerberos-master._udp.example.com. 86400 IN SRV 0 100 88 ipa.example.com. [... output truncated ...]生成されたファイルには、nsupdateユーティリティーで使用可能な形式の必須の DNS レコードが含まれます。- 生成されるレコードは以下に依存します。
- レコードが更新されるゾーンの自動検出
- そのゾーンの権威サーバーの自動検出
通常とは異なる DNS 設定を使用してる場合、またはゾーン委任がない場合は、nsupdateは適切なゾーンやサーバーを検出できないことがあります。その場合は、生成されるファイルの最初に以下のオプションを追加してください。serverで、nsupdateがレコードを送信する権威 DNS サーバーのサーバー名もしくはポートを指定します。zoneで、nsupdateがレコードを見つけるゾーンのゾーン名を指定します。
例:$
cat dns_records_file.nsupdatezone example.com. server 192.0.2.1 ; IPA DNS records update delete _kerberos-master._tcp.example.com. SRV update add _kerberos-master._tcp.example.com. 86400 IN SRV 0 100 88 ipa.example.com. [... output truncated ...]
ネームサーバーへの動的 DNS 更新リクエストの送信
nsupdate を使用してリクエストを送信する際には、以下のメカニズムを使用してリクエストのセキュリティーを確保してください。
- Transaction Signature (TSIG) プロトコル
- TSIG を使用すると、
nsupdateで共有キーを利用することができます。詳細は 手順32.1「TSIG を使用したnsupdateリクエストの送信」 を参照してください。 - GSS algorithm for TSIG (GSS-TSIG)
- GSS-TSIG では、GSS-API インターフェイスを使用して秘密 TSIG キーを取得します。GSS-TSIG は TSIG プロトコルの拡張機能です。詳細は 手順32.2「GSS-TSIG を使用した
nsupdateリクエストの送信」 を参照してください。
手順32.1 TSIG を使用した nsupdate リクエストの送信
- 以下の前提条件を満たしていることを確認します。
- お使いの DNS サーバーが TSIG 向けに設定されている必要があります。サーバー設定の例については、BIND、PowerDNS、Knot DNS 1 + Knot DNS 2 + Knot DNS 3 を参照してください。
- DNS サーバーとそのクライアントの両方に共有キーがある必要があります。
nsupdateを実行し、以下のいずれかのオプションで共有秘密を提供します。-kでは、TSIG 認証キーを提供します。$
nsupdate -k tsig_key.file dns_records_file.nsupdate-yでは、キーの名前と Base64 でエンコードされた共有秘密から署名を生成します。$
nsupdate -y algorithm:keyname:secret dns_records_file.nsupdate
手順32.2 GSS-TSIG を使用した nsupdate リクエストの送信
- 以下の前提条件を満たしていることを確認します。
注記
この手順では、Kerberos V5 プロトコルが GSS-API のテクノロジーとして使用されることを前提としています。 - DNS 更新リクエストを送信するには、レコードの更新が可能なプリンシパルと認証を行い、
nsupdateに-gオプションを追加して実行し、GSS-TSIG モードを有効にします。$
kinit principal_allowed_to_update_records@REALM$nsupdate -g dns_records_file.nsupdate
その他のリソース
32.11. 既存のサーバーへの DNS サービスのインストール
ipa-dns-install ユーティリティーを使用します。
ipa-dns-install を使用して DNS サービスを設定する方法は、ipa-server-install を使用して DNS をインストールする方法とほぼ同じです。「統合 DNS のあるサーバーのインストール」 を参照してください。
ipa-dns-install についての詳細は、ipa-dns-install(1) man ページを参照してください。
32.11.1. ネームサーバーの追加設定
/etc/resolv.conf ファイルの DNS サーバー一覧に追加します。IdM サーバーが利用できなくなった時のために、バックアップサーバーとして他の DNS サーバーを手動で追加することが推奨されます。例を示します。
search example.com ; the IdM server nameserver 192.0.2.1 ; backup DNS servers nameserver 198.51.100.1 nameserver 198.51.100.2
/etc/resolv.conf の設定に関する詳細は、resolv.conf(5) man ページを参照してください。
第33章 Automount の使用
33.1. Automount と IdM
/etc ディレクトリー内の auto.master ファイルです。必要な場合は、複数の auto.master 設定ファイルを別々の場所にあるサーバーに配置することができます。
autofs をサーバー上で設定し、そのサーバーが IdM ドメイン内のクライアントである場合、automount の全設定情報は IdM ディレクトリーに保存されます。マップや場所、キーといった autofs の設定は、別々のテキストファイルではなく、LDAP エントリーとして保存されます。たとえば、デフォルトのマップファイルである auto.master は、以下のように保存されます。
dn: automountmapname=auto.master,cn=default,cn=automount,dc=example,dc=com objectClass: automountMap objectClass: top automountMapName: auto.master
重要
autofs デプロイメントとは機能しますが、autofs 自体を設定するわけではありません。
cn=automount,dc=example,dc=com の下にコンテナーエントリーとして追加され、マップとキーはそれぞれその場所の下に保存されます。
- Locations には、
ipa automountlocation*コマンドを使用します。 - 直接または間接の maps には、
ipa automountmap*コマンドを使用します。 - Keys には、
ipa automountkey*コマンドを使用します。
33.2. Automount の設定
autofs 設定は作成されません。Autofs は、LDAP または SSSD をデータストアとして使用して手動で設定するか、自動で設定することが可能です。
注記
/home ディレクトリーをコマンドラインから正常にマウントできるかテストしてください。NFS が正常に機能しているこを確認すると、後で IdM automount 設定エラーが発生しても解決が容易になります。
33.2.1. NFS の自動設定
autofs は IdM ドメインを NFS ドメインとして使用するよう設定し、autofs サービスを有効にすることができます。
ipa-client-automount ユーティリティーは、/etc/sysconfig/nfs および /etc/idmapd.conf という NFS 設定ファイルを自動設定します。また、SSSD が NFS の認証情報を管理するようにも設定します。ipa-client-automount コマンドをオプションなしで実行すると、DNS 検索スキャンが実行されて利用可能な IdM サーバーを特定し、default という名前のデフォルトの場所を作成します。
[root@ipa-server ~]# ipa-client-automount Searching for IPA server... IPA server: DNS discovery Location: default Continue to configure the system with these values? [no]: yes Configured /etc/nsswitch.conf Configured /etc/sysconfig/nfs Configured /etc/idmapd.conf Started rpcidmapd Started rpcgssd Restarting sssd, waiting for it to become available. Started autofs
[root@server ~]# ipa-client-automount --server=ipaserver.example.com --location=boston
ipa-client-automount ユーティリティーは外部の IdM ストアがアクセス不能になった場合に備えて、SSSD が automount マップをキャッシュするよう設定します。SSSD の設定では、以下の 2 つが実行されます。
- サービスの設定情報が SSSD 設定に追加されます。IdM ドメインエントリーには、autofs プロバイダーとマウントの場所の設定があります。
autofs_provider = ipa ipa_automount_location = default
NFS がサポート対象サービスのリスト (services = nss,pam,autofs...) に追加され、空白の設定エントリー ([autofs]) が提供されます。 - Name Service Switch (NSS) サービス情報が更新され、automount 情報についてまず SSSD がチェックされ、次にローカルファイルがチェックされます。
automount: sss files
ipa-client-automount コマンドを --no-sssd オプションと実行することが可能です。その場合、必須の NFS 設定ファイルはすべて変更されますが、SSSD 設定は変更されません。
[root@server ~]# ipa-client-automount --no-sssd
--no-sssd を使用しないと、ipa-client-automount で更新される設定ファイルは違ったものになります。
/etc/sysconfig/nfsではなく/etc/sysconfig/autofsが更新されます。/etc/autofs_ldap_auth.confを IdM LDAP 設定で設定します。/etc/nsswitch.confが automount マップに LDAP サービスを使用するよう設定されます。
注記
ipa-client-automount コマンドは 1 回しか実行できません。設定にエラーがある場合は、設定ファイルを手動で編集する必要があります。
33.2.2. autofs が SSSD と Identity Management を使用するよう手動で設定する手順
/etc/sysconfig/autofsファイルを編集し、autofs が検索するスキーマ属性を指定します。# # Other common LDAP naming # MAP_OBJECT_CLASS="automountMap" ENTRY_OBJECT_CLASS="automount" MAP_ATTRIBUTE="automountMapName" ENTRY_ATTRIBUTE="automountKey" VALUE_ATTRIBUTE="automountInformation"
- LDAP 設定を指定します。これには 2 通りの方法があります。最も簡単な方法は、automount サービスが LDAP サーバーのその場所を自分で発見するようにすることです。
LDAP_URI="ldap:///dc=example,dc=com"
別の方法では、使用する LDAP サーバーと LDAP 検索のベース DN を明示的に設定します。LDAP_URI="ldap://ipa.example.com" SEARCH_BASE="cn=location,cn=automount,dc=example,dc=com"
注記
/etc/autofs_ldap_auth.confファイルを編集して、autofs が IdM LDAP サーバーを使ったクライアント認識を許可するようにします。authrequiredを yes に変更します。- プリンシパルを NFS クライアントサーバー用 Kerberos ホストプリンシパル host/fqdn@REALM に設定します。プリンシパル名は、GSS クライアント認証の一部として IdM ディレクトリーへの接続に使用されます。
<autofs_ldap_sasl_conf usetls="no" tlsrequired="no" authrequired="yes" authtype="GSSAPI" clientprinc="host/server.example.com@EXAMPLE.COM" />必要な場合は、klist -kを実行して正確なホストプリンシパル情報を取得します。- autofs を、SSSD が管理するサービスとして設定します。
- SSSD 設定ファイルを開きます。
[root@server ~]# vim /etc/sssd/sssd.conf
- autofs サービスを、SSSD が処理するサービス一覧に追加します。
[sssd] services = nss,pam,
autofs - 新規の
[autofs]セクションを作成します。これは空白のままにしても構いません。autofs サービスのデフォルト設定は、ほとんどのインフラストラクチャーで機能します。[nss] [pam] [sudo]
[autofs][ssh] [pac] - オプションとして、autofs エントリーの検索ベースを設定します。デフォルトではこれは LDAP 検索ベースですが、
ldap_autofs_search_baseパラメーターでサブツリーを指定することもできます。[domain/EXAMPLE] ... ldap_search_base = "dc=example,dc=com" ldap_autofs_search_base = "ou=automount,dc=example,dc=com"
- SSSD を再起動します。
[root@server ~]# systemctl restart sssd.service
/etc/nsswitch.confファイルで、SSSD が automount 設定のソースに記載されていることを確認します。automount:
sssfiles- autofs を再起動します。
[root@server ~]# systemctl restart autofs.service
- ユーザーの
/homeディレクトリーを一覧表示して、設定をテストします。[root@server ~]# ls /home/userName
これでリモートのファイルシステムがマウントされない場合は、/var/log/messagesファイルでエラーをチェックします。必要な場合は、/etc/sysconfig/autofsファイルでLOGGINGパラメーターをdebugに設定してデバッグレベルを高めます。
注記
automount -f -dこれで LDAP のアクセスログと automount のログを相互参照することなく、デバッグのログ情報が直接出力されます。
33.2.3. Solaris での Automount の設定
注記
- NFS サーバーが Red Hat Enterprise Linux 上で稼働している場合、Solaris マシン上で NFSv3 が最大のサポートバージョンであることを指定します。
/etc/default/nfsファイルで以下のパラメーターを設定します。NFS_CLIENT_VERSMAX=3
ldapclientコマンドを使って、ホストが LDAP を使用するように設定します。ldapclient -v manual -a authenticationMethod=none -a defaultSearchBase=dc=example,dc=com -a defaultServerList=ipa.example.com -a serviceSearchDescriptor=passwd:cn=users,cn=accounts,dc=example,dc=com -a serviceSearchDescriptor=group:cn=groups,cn=compat,dc=example,dc=com -a serviceSearchDescriptor=auto_master:automountMapName=auto.master,cn=location,cn=automount,dc=example,dc=com?one -a serviceSearchDescriptor=auto_home:automountMapName=auto_home,cn=location,cn=automount,dc=example,dc=com?one -a objectClassMap=shadow:shadowAccount=posixAccount -a searchTimelimit=15 -a bindTimeLimit=5automountを有効にします。# svcadm enable svc:/system/filesystem/autofs
- 設定をテストします。
- LDAP 設定を確認します。
# ldapclient -l auto_master dn: automountkey=/home,automountmapname=auto.master,cn=location,cn=automount,dc=example,dc=com objectClass: automount objectClass: top automountKey: /home automountInformation: auto.home
- ユーザーの
/homeディレクトリーを一覧表示します。# ls /home/userName
33.3. Kerberos 対応の NFS サーバーの設定
注記
33.3.1. Kerberos 対応の NFS サーバーの設定
- IdM ツールを実行する前に Kerberos チケットを取得します。
[jsmith@server ~]$ kinit admin
- NFS ホストマシンが IdM ドメインにクライアントとして追加されていない場合は、ホストエントリーを作成します。「ホストエントリーの追加」 を参照してください。
- IdM ドメインで NFS サービスエントリーを作成します。例を示します。
[jsmith@server ~]$ ipa service-add nfs/nfs-server.example.com
詳細は、「サービスエントリーおよび Keytab の追加と編集」 を参照してください。 ipa-getkeytabコマンドで NFS サーバー用の NFS サービス keytab を作成し、キーをホスト keytab に直接保存します。例を示します。[jsmith@server ~]$ ipa-getkeytab -s ipaserver.example.com -p nfs/nfs-server.example.com -k /etc/krb5.keytab
注記
サービスエントリーをチェックして、NFS サービスが IdM で適切に設定されていることを keytab で確認します。[jsmith@server ~]$ ipa service-show nfs/nfs-server.example.com Principal: NFS/nfs-server.example.com@EXAMPLE.COM Keytab: True
注記
この手順では、ipa-getkeytabが実行可能な Red Hat Enterprise Linux または UNIX システム上で、NFS サーバーが稼働していることを想定しています。NFS サーバーがipa-getkeytabを実行できないシステム上で稼働している場合は、システムツールを使って keytab を作成します。これには、以下の 2 つを実行する必要があります。- キーは
/root(またはそれに相当する) ディレクトリー内で作成する必要があります。
- NFS パッケージをインストールします。
[root@nfs-server ~]# yum install nfs-utils
- weak crypto のサポートを設定します。これは、ドメイン内の いずれかの クライアント (Red Hat Enterprise Linux 5 クライアントのような) が DES といった古い暗号化オプションを使用する場合に、すべての NFS クライアントで必要になります。
krb5.confファイルを編集して、weak crypto を許可します。[root@nfs-server ~]# vim /etc/krb5.conf allow_weak_crypto = true
- IdM サーバーの Kerberos 設定を更新し、DES 暗号化タイプに対応させます。
[jsmith@ipaserver ~]$ ldapmodify -x -D "cn=directory manager" -w password -h ipaserver.example.com -p 389 dn: cn=EXAMPLEREALM,cn=kerberos,dc=example,dc=com changetype: modify add: krbSupportedEncSaltTypes krbSupportedEncSaltTypes: des-cbc-crc:normal - add: krbSupportedEncSaltTypes krbSupportedEncSaltTypes: des-cbc-crc:special - add: krbDefaultEncSaltTypes krbDefaultEncSaltTypes: des-cbc-crc:special
ipa-client-automountコマンドを実行して NFS 設定を設定します。デフォルトでは、/etc/sysconfig/nfsファイル内でセキュアな NFS が有効になり、IdM DNS ドメインを/etc/idmapd.confファイル内のDomainパラメーターに設定します。/etc/exportsファイルを編集して、Kerberos 情報を追加します。/export *(rw,sec=krb5:krb5i:krb5p)
- NFS サーバーと関連サービスを再起動します。
[root@nfs-server ~]# systemctl restart nfs.service [root@nfs-server ~]# systemctl restart nfs-server.service [root@nfs-server ~]# systemctl restart nfs-secure.service [root@nfs-server ~]# systemctl restart nfs-secure-server.service
- 「Kerberos 対応の NFS クライアントの設定」 の説明にしたがって、NFS サーバーを NFS クライアントとして設定します。
33.3.2. Kerberos 対応の NFS クライアントの設定
- IdM ツールを実行する前に Kerberos チケットを取得します。
[jsmith@server ~]$ kinit admin
- NFS クライアントが IdM ドメインにクライアントとして登録されていない場合は、「ホストエントリーの追加」 にあるように必要なホストエントリーを作成します。
ipa-client-automountコマンドを実行して NFS 設定を設定します。デフォルトでは、/etc/sysconfig/nfsファイル内でセキュアな NFS が有効になり、IdM DNS ドメインを/etc/idmapd.confファイル内のDomainパラメーターに設定します。- GSS デーモンを起動します。
[root@nfs-client-server ~]# systemctl start rpc-gssd.service [root@nfs-client-server ~]# systemctl start rpcbind.service [root@nfs-client-server ~]# systemctl start nfs-idmapd.service
- ディレクトリーをマウントします。
[root@nfs-client-server ~]# echo "$NFSSERVER:/this /mnt/this nfs4 sec=krb5i,rw,proto=tcp,port=2049" >>/etc/fstab [root@nfs-client-server ~]# mount -av
- クライアントシステム上の SSSD がホームディレクトリーを管理し、Kerberos チケットを更新するように設定します。
--enablemkhomedirオプションで SSSD を有効にします。[root@nfs-client-server ~]# authconfig --update --enablesssd --enablesssdauth --enablemkhomedir
- OpenSSH クライアントを再起動します。
[root@nfs-client-server ~]# systemctl restart sssh.service
- SSSD 設定ファイルの IdM ドメインセクションを編集し、keytab 更新オプションを設定します。
[root@nfs-client-server ~]# vim /etc/sssd/sssd.conf [domain/EXAMPLE.COM] cache_credentials = True krb5_store_password_if_offline = True ipa_domain = example.com id_provider = ipa auth_provider = ipa ...
krb5_renewable_lifetime = 50dkrb5_renew_interval = 3600 - SSSD を再起動します。
[root@nfs-client-server ~]# systemctl restart sssd.service
33.4. 場所の設定
auto.master に保存されます。また、場所には複数のマップを保存できます。場所のエントリーは、マップエントリーのコンテナーとしてのみ機能します。それ自体は、automount 設定ではありません。
重要
33.4.1. Web UI での場所の設定
- Policy タブをクリックします。
- Automount サブタブをクリックします。
- automount の場所一覧の上部にある Add をクリックします。

- 新しい場所の名前を入力します。

- をクリックして、新規の場所のマップ設定に移動します。「Web UI でのダイレクトマップの設定」 および 「Web UI での間接マップの設定」 にあるように、マップを作成します。
33.4.2. コマンドラインでの場所の設定
automountlocation-add を使用して場所の名前を提供します。
$ ipa automountlocation-add location例を示します。
$ ipa automountlocation-add raleigh ---------------------------------- Added automount location "raleigh" ---------------------------------- Location: raleigh
auto.master および auto.direct という 2 つのマップが自動的に作成されます。auto.master は、当該場所の automount マップすべての root マップです。auto.direct は直接マウント用のデフォルトマップで、/- にマウントされます。
automountlocation-tofiles コマンドを使用します。
$ ipa automountlocation-tofiles raleigh /etc/auto.master: /- /etc/auto.direct --------------------------- /etc/auto.direct:
33.5. マップの設定
注記
重要
33.5.1. ダイレクトマップの設定
--------------------------- /etc/auto.direct: /shared/man server.example.com:/shared/man
33.5.1.1. Web UI でのダイレクトマップの設定
- Policy タブをクリックします。
- Automount サブタブをクリックします。
- マップの追加先となる automount の場所の名前をクリックします。

- Automount Maps タブで Add をクリックして新規マップを作成します。

- ポップアップウィンドウで Direct ラジオボタンを選択し、新規マップの名前を入力します。

- Automount Keys タブで Add をクリックしてマップの新規キーを作成します。

- マウントポイントを入力します。key では、実際のマウントポイントを key の名前で定義します。Info フィールドでは、ディレクトリーのネットワークの場所と、使用する
mountオプションを設定します。
- をクリックして新規キーを保存します。
33.5.1.2. コマンドラインでのダイレクトマップの設定
auto.direct アイテムと共に作成されます。最もシンプルな設定では、automount キーを既存のダイレクトマップエントリーに追加することでダイレクトマップを定義します。異なるダイレクトマップエントリーを作成することも可能です。
auto.direct ファイルに追加します。mount の他のオプションに加えて、--key オプションはマウントポイントを特定し、--info はディレクトリーのネットワークの位置を提供します。
$ ipa automountkey-add raleigh auto.direct --key=/share --info="ro,soft,ipaserver.example.com:/home/share" Key: /share Mount information: ro,soft,ipaserver.example.com:/home/share
ldapclient コマンドで LDAP エントリーを直接追加することで、ダイレクトマップとキーを追加します。
ldapclient -a serviceSearchDescriptor=auto_direct:automountMapName=auto.direct,cn=location,cn=automount,dc=example,dc=com?one
33.5.2. 間接マップの設定
/docs でキーが man の場合、マップは /docs/man となります。
33.5.2.1. Web UI での間接マップの設定
- Policy タブをクリックします。
- Automount サブタブをクリックします。
- マップの追加先となる automount の場所の名前をクリックします。

- Automount Maps タブで Add をクリックして新規マップを作成します。

- ポップアップウィンドウで Indirect ラジオボタンを選択し、以下の必要な間接マップの情報を入力します。

- 新規マップの名前
- マウントポイント。Mount フィールドでは、すべての間接マップキーに使用するベースディレクトリーを設定します。
- オプションで親マップ。デフォルトの親は
auto.masterですが、使用する別のマップがある場合は、Parent Map フィールドでそれを指定できます。
- をクリックして新規キーを保存します。
33.5.2.2. コマンドラインでの間接マップの設定
--------------------------- /etc/auto.share: man ipa.example.com:/docs/man ---------------------------
automountmap-add-indirectコマンドを使って間接マップを作成し、ベースエントリーを設定します。--mountオプションでは、すべての間接マップキーに使用するベースディレクトリーを設定します。デフォルトの親エントリーはauto.masterですが、使用する別のマップがある場合は、--parentmapオプションを使って指定することができます。$ ipa automountmap-add-indirect location mapName --mount=directory [--parentmap=mapName]
例を示します。$ ipa automountmap-add-indirect raleigh auto.share --mount=/share -------------------------------- Added automount map "auto.share" --------------------------------
- マウントする場所の間接キーを追加します。
$ ipa automountkey-add raleigh auto.share --key=docs --info="ipa.example.com:/export/docs" ------------------------- Added automount key "docs" ------------------------- Key: docs Mount information: ipa.example.com:/export/docs
- 設定を確認するために、
automountlocation-tofilesを使って場所のファイル一覧をチェックします。$ ipa automountlocation-tofiles raleigh /etc/auto.master: /- /etc/auto.direct /share /etc/auto.share --------------------------- /etc/auto.direct: --------------------------- /etc/auto.share: man ipa.example.com:/export/docs
ldapclient コマンドで LDAP エントリーを直接追加することで、間接マップを追加します。
ldapclient -a serviceSearchDescriptor=auto_share:automountMapName=auto.share,cn=location,cn=automount,dc=example,dc=com?one
33.5.3. Automount マップのインポート
ipa automountlocation-import location map_file [--continuous]
--continuous オプションを使うと、automountlocation-import コマンドはエラーに遭遇してもマップファイルの最後までインポートを継続します。
$ ipa automountlocation-import raleigh /etc/custom.map
パート VIII. セキュリティーの強化
第34章 Identity Management 向け TLS の設定
重要
34.1. httpd デーモンの設定
/etc/httpd/conf.d/nss.confファイルを開いて、NSSProtocolとNSSCipherSuiteのエントリーで以下の値を設定します。NSSProtocol TLSv1.2 NSSCipherSuite +ecdhe_ecdsa_aes_128_sha,+ecdhe_ecdsa_aes_256_sha,+ecdhe_rsa_aes_128_sha,+ecdhe_rsa_aes_256_sha,+rsa_aes_128_sha,+rsa_aes_256_sha
もしくは、以下のコマンドでこれらの値を設定します。#
sed -i 's/^NSSProtocol .*/NSSProtocol TLSv1.2/' /etc/httpd/conf.d/nss.conf#sed -i 's/^NSSCipherSuite .*/NSSCipherSuite +ecdhe_ecdsa_aes_128_sha,+ecdhe_ecdsa_aes_256_sha,+ecdhe_rsa_aes_128_sha,+ecdhe_rsa_aes_256_sha,+rsa_aes_128_sha,+rsa_aes_256_sha/' /etc/httpd/conf.d/nss.confhttpdデーモンを再起動します。#
systemctl restart httpd
34.2. Directory Server コンポーネントの設定
- DS を停止します。
#
systemctl stop dirsrv@EXAMPLE-COM.service /etc/dirsrv/slapd-EXAMPLE-COM/dse.ldifファイルを開いて、cn=encryption,cn=configエントリーを以下に設定します。sslVersionMin: TLS1.2
- DS を起動します。
#
systemctl start dirsrv@EXAMPLE-COM.service
ldapmodify ユーティリティーを使用して DS を自動設定します。
ldapmodifyを使って設定を変更します。ldapmodify -h localhost -p 389 -D 'cn=directory manager' -W << EOF dn: cn=encryption,cn=config changeType: modify replace: sslVersionMin sslVersionMin: TLS1.2 EOF
- DS を再起動して新しい設定を読み込みます。
#
systemctl restart dirsrv@EXAMPLE-COM.service
34.3. 証明書サーバーコンポーネントの設定
- 証明書サーバー (CS) を手動で設定するには、
/etc/pki/pki-tomcat/server.xmlファイルを開き、sslVersionRangeStreamとsslVersionRangeDatagramのパラメーターをすべて以下の値に設定します。sslVersionRangeStream="tls1_2:tls1_2" sslVersionRangeDatagram="tls1_2:tls1_2"
もしくは、以下のコマンドでこれらの値を設定します。#
sed -i 's/tls1_[01]:tls1_2/tls1_2:tls1_2/g' /etc/pki/pki-tomcat/server.xml - CS を再起動します。
#
systemctl restart pki-tomcatd@pki-tomcat.service
34.4. 結果
第35章 Anonymous バインドの無効化
nsslapd-allow-anonymous-access 属性をリセットすると 389 Directory Server インスタンスで anonymous バインドを無効にすることができます。
nsslapd-allow-anonymous-access属性をrootdseに変更します。$ ldapmodify -x -D "cn=Directory Manager" -W -h server.example.com -p 389 -ZZ Enter LDAP Password: dn: cn=config changetype: modify replace: nsslapd-allow-anonymous-access nsslapd-allow-anonymous-access: rootdse modifying entry "cn=config"
重要
Anonymous アクセスは完全に許可したり (on) ブロックしたり (off) することができます。ただし、anonymous アクセスを完全にブロックすると外部クライアントがサーバー設定をチェックすることもできなくなります。LDAP および web クライアントはドメインクライアントに限られるわけではないため、こうしたクライアントは匿名で接続を行ってルートの DSE ファイルを読み取り接続情報を取得します。rootdseは ディレクトリーデータにはアクセスさせずにルート DSE とサーバー設定へのアクセスを許可します。- 389 Directory Server インスタンスを再起動して新しい設定をロードします。
# systemctl restart dirsrv.target
パート IX. パフォーマンスチューニング
第36章 エントリーの一括プロビジョニングのパフォーマンスチューニング
- Identity Management (IdM) は LDIF ファイルからプロビジョニングされたエントリーを読み込み、対象の IdM LDAP インスタンスにインポートします。
- 管理者は、キャッシュサイズなど特定の属性のカスタム値を設定し、MemberOf および Schema Compatibility プラグインを無効化します。この手順では、MemberOf が無効になったことに対応するため、プロビジョニングされたエントリーで
fixup-memberof.plプラグインを実行します。
一括プロビジョニングの推奨事項と前提条件
- 大量のエントリー (10,000 件以上) をプロビジョニングする場合には、LDAP クライアントが、エントリーのプロビジョニング先のサーバーにアクセスしたり、サーバーの情報に依存したりできないようにします。たとえば、これはサーバーのポート 389 および 636 を無効にするか、Unix ソケットで機能する LDAPI を使用することで実現できます。理由: MemberOf プラグインはサーバー上で無効になっているのでサーバーのメンバーシップの情報は無効です。
- プロビジョニング中に実行しておく必要がないアプリケーションは停止します。理由: これにより、できるだけマシン上のメモリーを開放されます。ファイルシステムのキャッシュが空いたメモリーを使用することで、プロビジョニングのパフォーマンスを向上します。以下の手順にはすでに IdM サービスを停止して、Directory Server (DS) インスタンスのみを再起動する手順が含まれている点に注意してください。
tomcatなどの IdM サービスは大量のメモリーを消費しますが、プロビジョニング中には使用されません。 - 新規インストールされた IdM デプロイメントで、サーバーが 1 台のみ含まれている場合に、この手順を実行してください。プロビジョニングの完了後のみ、レプリカを作成します。理由: プロビジョニングのスループットは、レプリケーションよりもはるかに早いので、デプロイメントに 1 台以上含まれていると、レプリカの情報が大幅に古くなってしまいます。
- プロビジョニングするエントリーが含まれる LDIF ファイルを生成します。たとえば、既存の IdM デプロイメントを移行する場合には、
ldapsearchユーティリティーを使用して全エントリーをエクスポートし、LDIF ファイルを作成します。LDIF 形式の詳細は、『Red Hat Directory Server Administration Guide』の「About the LDIF File Format」を参照してください。
現在の DS チューニングパラメーター値のバックアップ
- DS チューニングパラメーターの現在の値を取得します。
- データベースのキャッシュサイズおよびデータベースのロック
# ldapsearch -D "cn=directory manager" -w secret -b "cn=config,cn=ldbm database,cn=plugins,cn=config" nsslapd-dbcachesize nsslapd-db-locks ... nsslapd-dbcachesize: 10000000 nsslapd-db-locks: 50000 ...
- エントリーのキャッシュサイズと DN キャッシュサイズ
# ldapsearch -D "cn=directory manager" -w secret -b "cn=userRoot,cn=ldbm database,cn=plugins,cn=config" nsslapd-cachememsize nsslapd-dncachememsize ... nsslapd-cachememsize: 10485760 nsslapd-dncachememsize: 10485760 ...
- 取得した値をメモします。プロビジョニングが完了したら、パラメーターをこれらの値にリセットします。
データベース、ドメインエントリー、DN キャッシュサイズの調節
- 必要な値を決定します。推奨の値は通常 200 MB から 500 MB の間となっています。各ユースケースに適した値は、システムで利用できるメモリーにより異なります。
- メモリー 8 GB 以上 → 500 MB
- メモリー 8 GB - 4 GB → 200 MB
- メモリー 4 GB 未満 → 100 MB
- 以下のテンプレートを使用して、決定した値を設定します。
dn: cn=config,cn=ldbm database,cn=plugins,cn=config changetype: modify replace: nsslapd-dbcachesize nsslapd-dbcachesize: db_cache_size_in_bytes
ldapmodifyユーティリティーを使用して LDAP 属性を変更する例は、例36.1「ldapmodifyを使用した LDAP 属性の変更」を参照してください。
例36.1 ldapmodify を使用した LDAP 属性の変更
ldapmodifyコマンドを実行して、属性値を変更するステートメントを追加します。以下に例を示します。# ldapmodify -D "cn=directory manager" -w secret -x dn: cn=config,cn=ldbm database,cn=plugins,cn=config changetype: modify replace: nsslapd-dbcachesize nsslapd-dbcachesize: 200000000
- Ctrl+D を押して、サーバーへの変更を確定、送信します。操作が正常に完了したら、以下のメッセージが表示されます。
modifying entry "cn=config,cn=ldbm database,cn=plugins,cn=config"
- 必要な値を決定します。推奨の値は 100 MB から 400 MB の間となっています。適切な値は、お使いのシステムで利用可能なメモリーにより異なります。
- メモリー 4 GB 以上 → 400 MB
- メモリー 2 GB - 4 GB → 200 MB
- メモリー 2 GB 未満 → 100 MB
大規模な静的グループをプロビジョニングする場合には、エントリーキャッシュに、グループおよびメンバーなど全エントリーが格納できるサイズにすることを推奨します。 - 以下のテンプレートを使用して、決定した値を設定します。
dn: cn=userRoot,cn=ldbm database,cn=plugins,cn=config changetype: modify replace: nsslapd-cachememsize nsslapd-cachememsize: entry_cache_size_in_bytes
- 最適なパフォーマンスを得るには、DN キャッシュに、プロビジョニングしたエントリーの DN すべてを格納できるようにすることを推奨します。ユースケースに適した値を見積もるには以下を行ってください。
- ファイル内の全 DN エントリー数を確認します。DN エントリーは、
dn:で始まる行に含まれます。たとえば、# grep、sed、wcを使用して確認します。# grep '^dn: ' ldif_file | sed 's/^dn: //' | wc -l 92200
- LDIF ファイルに含まれる全 DN エントリーの文字列のサイズを確認します。
# grep '^dn: ' ldif_file | sed 's/^dn: //' | wc -c 9802460
- 平均の DN サイズの取得: ファイル内の全 DN エントリー数で、全 DN エントリーの文字列のサイズを除算します。例: 9,802,460 / 92,200 ≈ 106
- 平均のメモリーサイズの取得: 平均の DN サイズに 2 を乗算した数値に、32 を加算します。例: (106 * 2) + 32 = 244
- 適切な DN のキャッシュサイズを取得: 平均メモリーサイズで LDIF ファイルの DN エントリーの総数を乗算します。例: 244 * 92,200 = 22,496,800
- 以下のテンプレートを使用して、決定した値を設定します。
dn: cn=userRoot,cn=ldbm database,cn=plugins,cn=config changetype: modify Replace: nsslapd-dncachememsize Nsslapd-dncachememsize: dn_cache_size
不必要なサービスの無効化およびデータベースロックの調節
- MemberOf および Schema Compatibility プラグインを無効にします。
dn: cn=MemberOf Plugin,cn=plugins,cn=config changetype: modify replace: nsslapd-pluginEnabled nsslapd-pluginEnabled: off
dn: cn=Schema Compatibility,cn=plugins,cn=config changetype: modify replace: nsslapd-pluginEnabled nsslapd-pluginEnabled: off
MemberOf を無効にすると、プロビジョニングが大幅に加速されます。また、 Schema Compatibility を無効にすると、操作の時間を短縮することができます。ldapmodifyユーティリティーを使用して LDAP 属性を変更する例は、例36.1「ldapmodifyを使用した LDAP 属性の変更」を参照してください。 - トポロジーにレプリカがインストールされていない場合には (「一括プロビジョニングの推奨事項と前提条件」で推奨)、Content Synchronization および Retro Changelog プラグインを無効にします。
dn: cn=Content Synchronization,cn=plugins,cn=config changetype: modify replace: nsslapd-pluginEnabled nsslapd-pluginEnabled: off
dn: cn=Retro Changelog Plugin,cn=plugins,cn=config changetype: modify replace: nsslapd-pluginEnabled nsslapd-pluginEnabled: off
これらのプラグインを無効にすると、プロビジョニングのパフォーマンス向上に役立ちます。 - IdM サーバーを停止します。これにより、DS インスタンスも停止されます。
# ipactl stop
次の手順でデータベースのロックの数を設定するには、DS を停止する必要があります。後で DS を再起動します。 - データベースロックの数を調節します。プロビジョニングのエントリー数の半分が適切な値です。
- 最小値は 10,000 です。
- 最大値は 200,000 です。
DS が停止されたので、/etc/dirsrv/slapd-EXAMPLE-COM/dse.ldifファイルを編集して値を設定する必要があります。dn: cn=config,cn=ldbm database,cn=plugins,cn=config ... nsslapd-db-locks: db_lock_number
IdM は、メンバーシップのコンピューティングの際には、大容量のデータベースページにアクセスします。アクセスするページが多いと、プロビジョニングに必要なロックも増えます。 - DS を起動します。
# systemctl start dirsrv.target
エントリーのインポート
ldapadd ユーティリティーなどを使用します。
# ldapadd -D "binddn" -y password_file -f ldif_file
ldapadd の使用方法については、ldapadd(1) の man ページを参照してください。
無効にしたサービスの再有効化および元の属性値の復元
- MemberOf を有効にします。
dn: cn=MemberOf Plugin,cn=plugins,cn=config changetype: modify replace: nsslapd-pluginEnabled nsslapd-pluginEnabled: on
ldapmodifyユーティリティーを使用して LDAP 属性を変更する例は、例36.1「ldapmodifyを使用した LDAP 属性の変更」を参照してください。 - DS を再起動します。
# systemctl restart dirsrv.target
MemberOf を以前の手順で有効化したので、この時点で DS を再起動する必要があります。 fixup-memberof.plのスクリプトに(objectClass=*)フィルターを使用して実行し、全プロビジョニングエントリーのmemberOf属性を再生成、更新します。以下に例を示します。# fixup-memberof.pl -D "cn=directory manager" -j password_file -Z server_id -b "suffix" -f "(objectClass=*)" -P LDAP
エントリーのインポートの際に、MemberOf プラグインを無効にしたので、fixup-memberof.plを実行する必要があります。スクリプトが正しく完了しないと、プロビジョニングを続行できません。fixup-memberof.plの詳細は、fixup-memberof.pl(8) の man ページを参照してください。- Schema Compatibility プラグインを有効にします。
dn: cn=Schema Compatibility,cn=plugins,cn=config changetype: modify replace: nsslapd-pluginEnabled nsslapd-pluginEnabled: on
- Content Synchronization および Retro Changelog プラグインを「不必要なサービスの無効化およびデータベースロックの調節」で無効にした場合には、有効化しなおしてください。
dn: cn=Content Synchronization,cn=plugins,cn=config changetype: modify replace: nsslapd-pluginEnabled nsslapd-pluginEnabled: on
dn: cn=Retro Changelog Plugin,cn=plugins,cn=config changetype: modify replace: nsslapd-pluginEnabled nsslapd-pluginEnabled: on
- 「現在の DS チューニングパラメーター値のバックアップ」でバックアップしたデータベースキャッシュ、エントリーキャッシュ、DN キャッシュサイズの元の値を復元します。
dn: cn=config,cn=ldbm database,cn=plugins,cn=config changetype: modify replace: nsslapd-dbcachesize nsslapd-dbcachesize: backup_db_cache_size dn: cn=userRoot,cn=ldbm database,cn=plugins,cn=config changetype: modify Replace: nsslapd-dncachememsize Nsslapd-dncachememsize: backup_dn_cache_size - replace: nsslapd-cachememsize nsslapd-cachememsize: backup_entry_cache_size
- DS を停止します。
# systemctl stop dirsrv.target
- 「現在の DS チューニングパラメーター値のバックアップ」でバックアップしたデータベースロックの元の値を復元します。DS が停止されたので、
/etc/dirsrv/slapd-EXAMPLE-COM/dse.ldifファイルを編集して値を設定する必要があります。dn: cn=config,cn=ldbm database,cn=plugins,cn=config ... nsslapd-db-locks: backup_db_lock_number
- IdM サーバーを起動します。
# ipactl start
これにより、DS を含むすべての IdM サービスが起動します。
パート X. 移行
第37章 LDAP ディレクトリーから IdM への移行
37.1. LDAP から IdM への移行に関する概要
37.1.1. クライアント設定のプランニング
重要
37.1.1.1. クライアント初期設定 (移行前)

図37.1 基本的な LDAP ディレクトリーとクライアント設定
/etc/passwd や /etc/shadow に格納されていたかのように見えます。(現実的には ID 検索に LDAP、認証に Kerberos や別の設定を使用している場合などインフラストラクチャーはもう少し複雑になる場合があります。)
37.1.1.2. Red Hat Enterprise Linux クライアント向けの推奨設定
pam_sss と nss_sss) を使用します。このライブラリーによって SSSD と Identity Management の緊密な統合が行われ、Identity Management の認証機能および ID 機能をフル活用することができるようになります。中央サーバーとの接続が失われた場合でもユーザーがログインできるよう ID 情報をキャッシングできる機能など、SSSD には便利な機能が多数搭載されています。こうした便利な機能については 『システムレベルの認証ガイド』 で詳しく説明しています。
pam_ldap と nss_ldap を使用する) とは異なり、SSSD は ドメイン 定義によって ID 情報と認証情報間の関係を確立します。SSSD のドメインは認証、ID 検索、アクセス、パスワード変更の 4 つのバックエンド機能を定義します。この SSSD ドメインを 4 つの機能のうちの 1 つの機能 (またはすべて) の情報を提供する プロバイダー を使用するよう設定します。ID プロバイダーはドメイン設定に必ず必要になります。他の 3 つのプロバイダーはオプションです。認証、アクセス、またはパスワードプロバイダーが定義されていない場合は ID プロバイダーがその機能に使用されます。
注記

図37.2 IdM バックエンドによるクライアントおよび SSSD
ipa-client-install スクリプトにより自動的に SSSD がバックエンドの全 4 サービスに IdM を使用するよう設定されるため、Red Hat Enterprise Linux クライアントはデフォルトで推奨設定にセットアップされます。
注記
ipa-client のバージョンに対応する Red Hat Enterprise Linux 6.1 以降および Red Hat Enterprise Linux 5.7 以降のみになります。これより旧式の Red Hat Enterprise Linux については 「推奨設定以外で対応している設定」 の説明に従って設定を行ってください。
37.1.1.3. 推奨設定以外で対応している設定
nss_ldap を使用) 。また IdM への接続は通常の Kerberos KDC への接続のように設定を行います (pam_krb5 を使用)。

図37.3 LDAP と Kerberos を使用したクライアントと IdM
nss_ldap と pam_krb5 を使用して IdM サーバーに接続するよう設定することができます。共通する構成要素が最低限となるようなメンテナンス環境や IT インフラストラクチャーなどの場合には LDAP を ID と認証の両方に使用する必要があるかもしれません (nss_ldap と pam_ldap)。ただし、クライアントにはできる限り安全な設定を使用するのが一般的にはベストプラクティスです (つまり SSSD と Kerberos または LDAP と Kerberos)。
37.1.2. パスワード移行のプランニング
重要
37.1.2.1. 方法 1: 一時的なパスワードの使用とパスワード変更の強制
37.1.2.2. 方法 2: 移行用 Web ページの使用
https://ipaserver.example.com/ipa/migration
37.1.2.3. 方法 3: SSSD の使用 (推奨)
- ユーザーが SSSD でマシンにログインします。
- SSSD は Kerberos 認証を IdM サーバーに対して試行します。
- ユーザーがシステムに存在していも Kerberos ハッシュがないため key type is not supported エラーで認証に失敗します。
- SSSD は次に安全な接続でプレーンテキストの LDAP バインドを行います。
- IdM によってこのバインド要求が遮断されます。ユーザーが Kerberos プリンシパルは持っているのに Kerberos ハッシュを持っていない場合、IdM ID プロバイダーはハッシュを生成してユーザーのエンティティーに格納します。
- 認証に成功すると SSSD は IdM との接続を切断し Kerberos 認証を再試行します。この場合、エンティティーにハッシュが存在しているため要求は成功します。
37.1.2.4. クリアテキスト LDAP パスワードの移行
注記
37.1.2.5. 要件を満たしていないパスワードの自動リセット
kinit をはじめて IdM ドメインで発行したときに自動的に行われます。
[jsmith@server ~]$ kinit Password for jsmith@EXAMPLE.COM: Password expired. You must change it now. Enter new password: Enter it again:
37.1.3. 移行における考慮事項と要件
37.1.3.1. 移行に対応している LDAP サーバー
ipa migrate-ds が使用されます。このスクリプトは正しく動作するため LDAP ディレクトリーおよび LDAP エントリーに一定の構造を期待します。移行に対応しているのは複数の共通ディレクトリーを含む LDAPv3 準拠のディレクトリーサービスのみになります。
- Sun ONE Directory Server
- Apache Directory Server
- OpenLDAP
注記
37.1.3.2. 移行環境に関する要件
- 1 つの LDAP ディレクトリードメインを 1 つの IdM レルムに移行します。統合はありません。
- ユーザーのパスワードは LDAP ディレクトリー内にハッシュで格納されています。サポートされているハッシュの一覧は、『Red Hat Directory Server 10 Administration Guide』の「Password Policy Attributes」の表 に含まれる
passwordStorageScheme属性を参照してください。 - LDAP ディレクトリーインスタンスは ID 格納および認証方法の両方になります。クライアントのマシンは LDAP サーバーへの接続に
pam_ldapまたはnss_ldapを使用するよう設定します。 - エントリーに使用するのは標準の LDAP スキーマのみです。カスタムオブジェクトクラスまたは属性に含まれるエントリーは Identity Management には移行されません。
37.1.3.3. 移行 — IdM システムの要件
- 4 コア
- 4GB の RAM
- 30GB のディスク領域
- 2MB の SASL バッファー (IdM サーバーのデフォルト)移行で問題が発生いた場合には、バッファーサイズを増やしてください。
[root@ipaserver ~]# ldapmodify -x -D 'cn=directory manager' -w password -h ipaserver.example.com -p 389 dn: cn=config changetype: modify replace: nsslapd-sasl-max-buffer-size nsslapd-sasl-max-buffer-size: 4194304 modifying entry "cn=config"
nsslapd-sasl-max-buffer-sizeの値をバイト単位で設定します。
37.1.3.4. 移行ツール
ipa migrate-ds コマンドを使って移行プロセスを進めます。ipa migrate-ds を使用する場合、--bind-dn オプションで指定されたリモートのシステムユーザーには userPassword 属性に対する読み取りのアクセスを割り当てる必要があります。アクセス権がないとパスワードが移行されません。
37.1.3.5. 移行のパフォーマンス改善
nsslapd-cachememsize属性、エントリーキャッシュに許可するサイズを定義します。キャッシュの合計メモリーサイズの 80% に自動的に設定されるバッファです。大規模なインポート動作の場合にはこのパラメーター (およびメモリーキャッシュ自体) を増やして多数のエントリーまたは大きい属性を持つエントリーをより効率的に処理できるようにします。ldapmodifyを使用して属性を変更する方法は、『Red Hat Directory Server Performance Tuning Guide』の該当のセクション を参照してください。- システムの
ulimit設定オプションでは、システムユーザーに対して許可するプロセス数の最大値を設定します。大規模なデータベースを処理すると上限を超える可能性があります。このような場合には、値を増やしてください。[root@server ~]# ulimit -u 4096
37.1.3.6. 移行順序
- SSSD を導入します。
- クライアントが現在の LDAP サーバーに接続し IdM にフェールオーバーするよう再設定を行います。
- IdM サーバーをインストールします。
- IdM の
ipa migrate-dsスクリプトを使ってユーザーデータの移行を行います。これによりデータが LDAP ディレクトリーからエクスポートされ、IdM スキーマ用にフォーマット化されて IdM にインポートされます。 - LDAP サーバーをオフラインにしてクライアントを透過的に Identity Management にフェールオーバーさせます。
- IdM サーバーをインストールします。
- IdM の
ipa migrate-dsスクリプトを使ってユーザーデータの移行を行います。これによりデータが LDAP ディレクトリーからエクスポートされ、IdM スキーマ用にフォーマット化されて IdM にインポートされます。 - オプションです。SSSD を導入します。
- クライアントが IdM に接続するよう再設定を行います。LDAP サーバーと単純に差し替えることはできません。IdM ディレクトリーツリー — およびユーザーエントリーの DN — は以前のディレクトリーツリーとは異なります。クライアントの再設定は必要ですが、直ちに再設定を行う必要はありません。更新したクライアントは IdM サーバーをポイントし、他のクライアントは旧 LDAP ディレクトリーをポイントするためデータ移植後に適度なテストと移行段階を持たせることができます。
注記
LDAP ディレクトリーと IdM サーバーを長期に渡っては並行稼動させないでください。2 つのサービス間でユーザーデータの整合性が失われる危険を招くことになります。
37.2. ipa migrate-ds の使用例
ipa migrate-ds コマンドで行います。一番単純な例では移行するディレクトリーの LDAP URL を取得し、共通デフォルト設定をもとにデータをエクスポートします。
ipa migrate-ds ldap://ldap.example.com:389
- 移行済みのエントリー
migrate-dsコマンドは、posixAccountおbぬジェクトクラスに必要なgidNumber属性と、personオブジェクトクラスに必要なsn属性を含むアカウントのみを移行します。- プロセスのカスタマイズ
ipa migrate-dsコマンドは、データを特定してエクスポートする方法をカスタマイズすることができます。元のディレクトリーツリーがユニークな構造である場合や、エントリー内のエントリーや属性を除外すべき場合に便利です。詳しい情報は、コマンドに--helpを指定してください。- バインド DN
- デフォルトでは、DN "
cn=Directory Manager" iを使用して、リモートの LDAP ディレクトリーにバインドします。--bind-dnオプションをコマンドに渡して、カスタムのバインド DN を指定します。詳細情報は、「移行ツール」を参照してください。 - ネーミングコンテキストの変更
- Directory Server のネーミングコンテキストが Identity Management で使用するものとは異なる場合には、オブジェクトのベース DNs は変換されます。たとえば、
uid=user,ou=people,dc=ldap,dc=example,dc=comはuid=user,ou=people,dc=idm,dc=example,dc=comに移行します。--base-dnをipa migrate-dsコマンドに渡して、移行用にリモートの LDAP サーバーで使用するベース DN を設定します。
37.2.1. 特定のサブツリーの移行
ou=People サブツリーに配置されグループのエントリーは ou=Groups サブツリーに配置されます。こうしたサブツリーは異なるタイプのディレクトリーデータ用のコンテナーエントリーになります。 migrate-ds に何もオプションを渡さないとユーティリティーは指定 LDAP ディレクトリーでは ou=People と ou=Groups の構造が使用されると仮定します。
--user-container--group-container
注記
>ou=Employees,dc=example,dc=com ディレクトリーツリーは --user-container=ou=Employees を使用して移行できます。
[root@ipaserver ~]# ipa migrate-ds --user-container=ou=employees \
--group-container="ou=employee groups" \
ldap://ldap.example.com:389--scope オプションを ipa migrate-ds コマンドに渡して、スコープを設定します。
onelevel: デフォルト。指定のコンテナーのエントリーのみが移行されます。subtree: 指定のコンテナーおよびすべてのサブコンテナーに含まれるエントリーが移行されます。base: 指定したオブジェクト自体が移行されます。
37.2.2. 特定のエントリーのみを包含および除外
ipa migrate-ds スクリプトは、person オブジェクトクラスで全ユーザーエントリーを、groupOfUniqueNames または groupOfNames オブジェクトクラスで全グループエントリーをインポートします。
fullTimeEmployee オブジェクトクラスの付いたユーザーのみを移行します。
[root@ipaserver ~]# ipa migrate-ds --user-objectclass=fullTimeEmployee ldap://ldap.example.com:389
[root@ipaserver ~]# ipa migrate-ds --group-objectclass=groupOfNames --group-objectclass=groupOfUniqueNames ldap://ldap.example.com:389
[root@ipaserver ~]# ipa migrate-ds --exclude-groups="Golfers Group" --exclude-users=jsmith --exclude-users=bjensen ldap://ldap.example.com:389
uid のパターンに一致するユーザーと、cn 属性に一致するグループに適用されます。
fullTimeEmployee オブジェクトクラスを持つユーザーを移行に含め 3 人のマネージャーは除外する例を以下に示します。
[root@ipaserver ~]# ipa migrate-ds --user-objectclass=fullTimeEmployee --exclude-users=jsmith --exclude-users=bjensen --exclude-users=mreynolds ldap://ldap.example.com:389
37.2.3. エントリー属性の除外
userCertificate 属性を移行する意味はなくなります。
migrate-ds にいくつかのオプションを使って無視させることができます。
--user-ignore-objectclass--user-ignore-attribute--group-ignore-objectclass--group-ignore-attribute
userCertificate 属性と strongAuthenticationUser オブジェクトクラスおよびグループの groupOfCertificates オブジェクトクラスを除外する例を以下に示します。
[root@ipaserver ~]# ipa migrate-ds --user-ignore-attribute=userCertificate --user-ignore-objectclass=strongAuthenticationUser --group-ignore-objectclass=groupOfCertificates ldap://ldap.example.com:389
注記
37.2.4. 使用するスキーマの設定
--schema オプションを ipa migrate-ds コマンドに渡します。
[root@ipaserver ~]# ipa migrate-ds --schema=RFC2307 ldap://ldap.example.com:389
37.3. LDAP サーバーの Identity Management への移行
重要
- カスタム LDAP ディレクトリースキーマなど、IdM サーバーを既存の LDAP ディレクトリーとは別のマシンにインストールします。
注記
IdM では、カスタムユーザーまたはグループスキーマのサポートに限りがあります。オブジェクトの定義に互換性がないので移行中に問題が発生する可能性があります。 - compat プラグインを無効にします。
[root@server ~]# ipa-compat-manage disable
compat ツリーから提供されているデータが移行中に必要な場合には、このステップは省略可能です。 - IdM Directory Server インスタンスを再起動します。
[root@server ~]# systemctl restart dirsrv.target
- IdM サーバーが移行を許可するように設定
[root@server ~]# ipa config-mod --enable-migration=TRUE
- IdM 移行用スクリプト
ipa migrate-dsを実行します。最も基本的な移行の場合、ここで必要となるのは LDAP ディレクトリーインスタンスの LDAP URL のみです。[root@server ~]# ipa migrate-ds ldap://ldap.example.com:389
LDAP URL を渡すだけで共通のデフォルト設定を使用するディレクトリーデータはすべて移行されます。ユーザーやグループのデータは 「ipa migrate-dsの使用例」 で説明しているように他のオプションを指定することで選択的に移行することが可能です。compat プラグインが以前のステップで無効化されている場合には、--with-compatオプションをipa migrate-dsに渡します。情報のエクスポートが完了すると、ネーミングコンテキストが異なる場合には、このスクリプトにより、必要とされる IdM オブジェクトクラスおよび属性がすべて追加され、IdM ディレクトリーツリーと一致するよう DN は属性に変換されます。たとえば、uid=user,ou=people,dc=ldap,dc=example,dc=comはuid=user,ou=people,dc=idm,dc=example,dc=comに移行されます。 - 無効化されている場合には、移行前に compat プラグインを再度有効にします。
[root@server ~]# ipa-compat-manage enable
- IdM Directory Server インスタンスを再起動します。
[root@server ~]# systemctl restart dirsrv.target
- 移行モードを無効にします。
[root@server ]# ipa config-mod --enable-migration=FALSE
- オプションです。 SSSD ではないクライアントが LDAP 認証 (
pam_ldap) ではなく Kerberos 認証 (pam_krb5) を使用するよう再設定します。全ユーザーが移行されるまで PAM_LDAP モジュールを使用し、次に PAM_KRB5 をしようできるようになります。詳しい情報は、『システムレベルの認証ガイド』の適切なセクション を参照してください。 - ハッシュ化された Kerberos パスワードを生成するには、2 種類の方法があります。「パスワード移行のプランニング」に記載されているように、他にユーザーの対話なしにユーザーのパスワードを両方移行します。
- SSSD の使用:
- SSSD をインストールしているクライアントを LDAP バックエンドから IdM バックエンドに移動し、IdM でクライアントとして登録します。これにより必要なキーと証明書がダウンロードされます。Red Hat Enterprise Linux クライアントで、
ipa-client-installコマンドを使用して実行できます。以下に例を示します。[root@server ~]# ipa-client-install --enable-dns-update
- IdM の移行 Web ページの使用
- 以下の移行 Web ページを使用して IdM にログインするように指示を出します。
https://ipaserver.example.com/ipa/migration
- ユーザーの移行プロセスを監視するには、パスワードは持っているが Kerberos プリンシパルキーはまだないユーザーアカウントを表示するよう既存の LDAP ディレクトリーに問い合わせます。
[user@server ~]$ ldapsearch -LL -x -D 'cn=Directory Manager' -w secret -b 'cn=users,cn=accounts,dc=example,dc=com' '(&(!(krbprincipalkey=*))(userpassword=*))' uid
注記
フィルターの前後に単一引用符を付けてシェルで解釈されないようにします。 - クライアントとユーザーすべての移行が完了したら LDAP ディレクトリーを廃止します。
37.4. SSL での移行
- リモートの LDAP サーバーの証明書を発行する CA の証明書を IdM サーバーのファイルに保存します (例:
/etc/ipa/remote.crt)。 - 「LDAP サーバーの Identity Management への移行」に記載の手順に従います。ただし、移行中の暗号化された LDAP 接続の場合には、以下のように URL で
ldapsのプロトコルを使用して、コマンドに--ca-cert-fileオプションを渡します。[root@ipaserver ~]# ipa migrate-ds --ca-cert-file=/etc/ipa/remote.crt ldaps://ldap.example.com:636
付録A トラブルシューティングのガイドライン
注記
A.1. ipa ユーティリティー実行時のエラー
基本的なトラブルシューティング
- コマンドに
--verbose(-v) オプションを追加して、デバッグ情報を表示します。 - コマンドに
-vvオプションを追加して、JSON 応答およびリクエストを表示します。
高度なトラブルシューティング
ipa cert-show コマンドを実行するアーキテクチャー」 では、ユーザーが IdM コマンドラインユーティリティーを使用する際にどのコンポーネントと対話するかを示しています。これらのコンポーネントにクエリーを実行すると、問題の発生場所と原因を判定する助けとなります。
- 以下のユーティリティーを使用します。
hostは、IdM サーバーまたはクライアントの DNS 解決をチェックします。pingは、IdM サーバーが利用可能かどうかをチェックします。iptablesは、IdM サーバーの現行のファイアウォール設定をチェックします。dateは現在の時間をチェックします。ncは、「ポート要件」 にある必須ポートへの接続を試行します。
これらのユーティリティーについての詳細は、各コマンドの man ページを参照してください。 KRB5_TRACE環境変数を/dev/stdoutファイルに設定し、トレースログ出力を/dev/stdoutに送信します。$ KRB5_TRACE=/dev/stdout ipa cert-findKerberos キー配布センター (KDC) のログを/var/log/krb5kdc.logでチェックします。- Apache エラーログをチェックします。
- サーバーのデバッグレベルを有効にします。
/etc/ipa/server.confファイルを開いて、debug=Trueオプションを[global]セクションに追加します。 httpdサービスを再起動します。# systemctl restart httpd.service- 失敗したコマンドを再度実行します。
httpdエラーログをサーバーの/var/log/httpd/error_logでチェックします。
-vvvオプションを追加してコマンドを実行し、HTTP リクエストと応答を表示します。 - Apache アクセスログを
/var/log/httpd/access_logでチェックします。認証システムコンポーネントのログをチェックします。/var/log/pki/pki-ca-spawn.time_of_installation.log/var/log/pki/pki-tomcat/ca/debug/var/log/pki/pki-tomcat/ca/system/var/log/pki/pki-tomcat/ca/selftests.log# journalctl -u pki-tomcatd@pki-tomcat.serviceコマンドを使用してjournalログをレビューします。
- Directory Server アクセスログをチェックします:
/var/log/dirsrv/slapd-IPA-EXAMPLE-COM/access

図A.1 ipa cert-show コマンドを実行するアーキテクチャー
関連情報
- さまざまな Identity Management のログファイルに関する説明は、「Identity Management ログファイルおよびディレクトリー」を参照してください。
A.2. kinit 認証エラー
全般的トラブルシューティング
- IdM クライアント上で、
kinitプロセス空のデバッグメッセージを表示します。$ KRB5_TRACE=/dev/stdout kinit admin - 以下の点を確認します。
- クライアント転送レコードが、サーバーと影響されるクライアントの両方で正常であること。
# host client_fully_qualified_domain_name - サーバー転送レコードが、サーバーと影響されるクライアントの両方で正常であること。
# host server_fully_qualified_domain_name# host server_IP_addresshost server_IP_addressは、以下のように完全修飾ホスト名の最後にピリオドが付いたものを返す必要があります。server.example.com.
- クライアント上の
/etc/hostsファイルをチェックして、以下を確認します。- ファイル内の全サーバーエントリーが正しいこと。
- 全サーバーエントリーで、名前が完全修飾ドメイン名であること。
「/etc/hostsファイル」 も参照してください。 - 「ホスト名および DNS の設定」 にある他の条件も満たしていることを確認します。
- IdM サーバー上で、
krb5kdcとdirsrvのサービスが稼働中であることを確認します。# systemctl status krb5kdc# systemctl status dirsrv.target - Kerberos キー配布センター (KDC) のログを
/var/log/krb5kdc.logでチェックします。 - KDC が
/etc/krb5.confファイル (このファイルは KDC ディレクティブを明示的に設定し、dns_lookup_kdc = false設定を使用します) がハードコーディングされている場合は、各マスターサーバーでipactl statusコマンドを使用します。このコマンドで KDC として一覧表示される各サーバーの IdM サービスのステータスをチェックします。# ipactl statusDirectory Service: RUNNING krb5kdc Service: RUNNING kadmin Service: RUNNING named Service: RUNNING httpd Service: RUNNING ipa-custodia Service: RUNNING ntpd Service: RUNNING pki-tomcatd Service: RUNNING ipa-otpd Service: RUNNING ipa-dnskeysyncd Service: RUNNING ipa: INFO: The ipactl command was successful
Cannot find KDC for realm エラーのトラブルシューティング
kinit 認証で Cannot find KDC for realm "EXAMPLE.COM" while getting initial credentials というエラーが出て失敗する場合は、KDC がサーバーで稼働していないか、クライアントによる DNS の設定が正しくないことを示します。この場合は、以下のステップを実行します。
- DNS 検出が
/etc/krb5.confファイルで有効になっている場合 (dns_lookup_kdc = trueの設定)、digユーティリティーを使用して以下のレコードが解決可能かどうかをチェックします。$ dig -t TXT _kerberos.ipa.example.com$ dig -t SRV _kerberos._udp.ipa.example.com$ dig -t SRV _kerberos._tcp.ipa.example.com以下は、上記のdigコマンドの 1 つが失敗した場合に返す出力の例です。; <<>> DiG 9.11.0-P2-RedHat-9.11.0-6.P2.fc25 <<>> -t SRV _kerberos._tcp.ipa.server.example ;; global options: +cmd ;; connection timed out; no servers could be reached
この出力は、namedサービスがマスターサーバー上で稼働していないことを示します。 - DNS ルックアップが失敗する場合は、「DNS のトラブルシューティング」 にあるステップを試してください。
関連情報
- さまざまな Identity Management のログファイルに関する説明は、「Identity Management ログファイルおよびディレクトリー」を参照してください。
A.3. IdM Web UI での認証エラー
- ユーザーが
kinitユーティリティーを使ってコマンドラインから認証できることを確認します。認証に失敗する場合は、「kinit認証エラー」 を参照してください。 httpdおよびdirsrvサービスが該当サーバー上で稼働していることを確認します。# systemctl status httpd.service# systemctl status dirsrv@IPA-EXAMPLE-COM.service- 関連した SELinux Access Vector Cache (AVC) メッセージが
/var/log/audit/audit.logおよび/var/log/messagesファイルにないことを確認します。AVC メッセージの解決については、Red Hat Knowledgebase の Basic SELinux Troubleshooting in CLI を参照してください。 - 認証を行なっているブラウザーのクッキーが有効になっていることを確認します。
- IdM サーバーと認証を行なっているシステムの時間差が 5 分以内であることを確認します。
- Apache エラーログをチェックします:
/var/log/httpd/error_log - 問題の診断のために、認証プロセスの詳細なロギングを有効にします。Firefox で詳細なロギングを有効にする方法については、『システムレベルの認証ガイド』 の Firefox の Kerberos 設定のトラブルシューティング を参照してください。
/etc/httpd/conf.d/nss.confファイルで、LogLevelの属性をinfoに変更します。- Apache サーバーを再起動します。
# systemctl restart httpd - 証明書を使って再度ログインします。
- Apache エラーログをチェックします:
/var/log/httpd/error_logログにはmod_lookup_identityモジュールが記録したメッセージが表示されます。これには、ログイン試行時にモジュールがユーザーとの一致に成功したかどうかという情報が含まれています。
関連情報
- さまざまな Identity Management のログファイルに関する説明は、「Identity Management ログファイルおよびディレクトリー」を参照してください。
A.4. スマートカード認証の失敗
/etc/sssd/sssd.confファイルを開いてdebug_levelオプションを2に設定します。sssd_pam.logとsssd_EXAMPLE.COM.logファイルをチェックします。これらのファイルにタイムアウトのエラーメッセージがある場合は、「スマートカード認証でタイムアウトエラーメッセージが出て失敗する問題」 を参照してください。
A.5. サービスが起動に失敗する理由の確認
- 起動に失敗しているサービスのログをチェックします。「Identity Management ログファイルおよびディレクトリー」 を参照してください。たとえば、Directory Server のログは
/var/log/dirsrv/slapd-IPA-EXAMPLE-COM/errorsにあります。 - サービスを稼働するサーバーに完全修飾ドメイン名 (FQDN) があることを確認します。「サーバーのホスト名の検証」 を参照してください。
/etc/hostsファイルにサービスを稼働するサーバーのエントリーが含まれている場合は、完全修飾ドメイン名が最初に記載されているかどうかを確認します。「/etc/hostsファイル」 を参照してください。- 「ホスト名および DNS の設定」 にある他の条件も満たしていることを確認します。
- サービスの認証に使用されるキータブにどのキーが含まれているか判定します。たとえば、
dirsrvサービスのチケットは以下のようになります。# klist -kt /etc/dirsrv/ds.keytabKeytab name: FILE:/etc/dirsrv/ds.keytab KVNO Timestamp Principal ---- ------------------- ------------------------------------------------------ 2 01/10/2017 14:54:39 ldap/server.example.com@EXAMPLE.COM 2 01/10/2017 14:54:39 ldap/server.example.com@EXAMPLE.COM [... output truncated ...]- 表示されているプリンシパルがシステムの FQDN に一致していることを確認します。
- 上記の表示されているサービスキータブ内のキーのバージョン (KVNO) がサーバーのキータブにある KVNO と一致していることを確認します。サーバーのキータブを表示するには、以下を実行します。
$ kinit admin$ kvno ldap/server.example.com@EXAMPLE.COM - クライアント上の正引き (A, AAAA, または両方) および逆引きレコードが表示されているシステム名およびサービスプリンシパルと一致することを確認します。
- クライアント上の正引き (A, AAAA, または両方) および逆引きレコードが正しいことを確認します。
- クライアントとサーバーとのシステムの時間差が 5 分以内であることを確認します。
- IdM 管理サーバーの証明書の有効期限が切れると、サービスが起動に失敗することがあります。これが当てはまるかどうかを判定するには、以下を実行します。
getcert listコマンドを使用して、certmongerユーティリティーが追跡している証明書をすべて一覧表示します。- その出力で、IdM 管理証明書である
ldapとhttpdのサーバー証明書を見つけます。 statusとexpiresのフィールドをチェックします。# getcert listNumber of certificates and requests being tracked: 8. [... output truncated ...] Request ID '20170421124617': status: MONITORING stuck: no key pair storage: type=NSSDB,location='/etc/dirsrv/slapd-IPA-EXAMPLE-COM',nickname='Server-Cert',token='NSS Certificate DB',pinfile='/etc/dirsrv/slapd-IPA-EXAMPLE-COM/pwdfile.txt' certificate: type=NSSDB,location='/etc/dirsrv/slapd-IPA-EXAMPLE-COM',nickname='Server-Cert',token='NSS Certificate DB' CA: IPA issuer: CN=Certificate Authority,O=IPA.EXAMPLE.COM subject: CN=ipa.example.com,O=IPA.EXAMPLE.COM expires: 2019-04-22 12:46:17 UTC [... output truncated ...] Request ID '20170421130535': status: MONITORING stuck: no key pair storage: type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' certificate: type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS Certificate DB' CA: IPA issuer: CN=Certificate Authority,O=IPA.EXAMPLE.COM subject: CN=ipa.example.com,O=IPA.EXAMPLE.COM expires: 2019-04-22 13:05:35 UTC [... output truncated ...]
証明書の有効期限が切れていてもサービスを起動する必要がある場合は、「IdM を有効期限の切れた証明書で起動できるようにする方法」 を参照してください。
A.6. DNS のトラブルシューティング
- DNS 問題の多くは間違った設定のために発生するので、「ホスト名および DNS の設定」 にある条件を満たしていることを確認してください。
digユーティリティーを使って DNS サーバーからの応答をチェックします。# dig _ldap._tcp.ipa.example.com. SRV; <<>> DiG 9.9.4-RedHat-9.9.4-48.el7 <<>> _ldap._tcp.ipa.example.com. SRV ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 17851 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 1, ADDITIONAL: 5 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;_ldap._tcp.ipa.example.com. IN SRV ;; ANSWER SECTION: _ldap._tcp.ipa.example.com. 86400 IN SRV 0 100 389 ipaserver.ipa.example.com. ;; AUTHORITY SECTION: ipa.example.com. 86400 IN NS ipaserver.ipa.example.com. ;; ADDITIONAL SECTION: ipaserver.ipa.example.com. 86400 IN A 192.0.21 ipaserver.ipa.example.com 86400 IN AAAA 2001:db8::1host有効期限を使って DNS 名のルックアップを実行します。$ host server.ipa.example.comserver.ipa.example.com. 86400 IN A 192.0.21 server.ipa.example.com 86400 IN AAAA 2001:db8::1ipa dnszone-showコマンドを使って LDAP 内の DNS レコードを確認します。$ ipa dnszone-show zone_name$ ipa dnsrecord-show zone_name record_name_in_the_zoneIdM ツールを使った DNS 管理の詳細については、32章DNS の管理 を参照してください。- BIND を再起動して LDAP との再同期を実行します。
$ systemctl restart named-pkcs11 - 必要な DNS レコード一覧を取得します。
$
ipa dns-update-system-records --dry-rundigユーティリティーを使って表示されているレコードが DNS に存在するかどうかをチェックします。Identity Management DNS を使用している場合は、ipa dns-update-system-recordsコマンドを使って見つからないレコードを更新します。
A.7. レプリケーションのトラブルシューティング
- 「ホスト名および DNS の設定」 にある条件を満たしていることを確認します。
- 両方のサーバーで互いに正引きと逆引き DNS レコードを解決できることを確認します。
[root@server1 ~]#
dig +short server2.example.com A[root@server1 ~]#dig +short server2.example.com AAAA[root@server1 ~]#dig +short -x server2_IPv4_or_IPv6_address[root@server2 ~]#
dig +short server1.example.com A[root@server2 ~]#dig +short server1.example.com AAAA[root@server2 ~]#dig +short -x server1_IPv4_or_IPv6_address - 両サーバー間の時間差が 5 分以内であることを確認します。
- 両サーバーの Directory Server エラーログをチェックします:
/var/log/dirsrv/slapd-SERVER-EXAMPLE-COM/errors - Kerberos 関連のエラーがある場合は、Directory Server keytab が正しいものであることと、それを使ってもう一方のサーバー (この例では
server2) にクエリーできることを確認します。[root@server1 ~]#
kinit -kt /etc/dirsrv/ds.keytab ldap/server1.example.com[root@server1 ~]#klist[root@server1 ~]#ldapsearch -Y GSSAPI -h server1.example.com -b "" -s base[root@server1 ~]#ldapsearch -Y GSSAPI -h server2_FQDN. -b "" -s base
関連情報
- さまざまな Identity Management のログファイルに関する説明は、「Identity Management ログファイルおよびディレクトリー」を参照してください。
付録B トラブルシューティング: 特定問題の解決
- サーバーについては、「Identity Management サーバー」
- レプリカについては、「Identity Management レプリカ」
- クライアントについては、「Identity Management クライアント」
- 認証については、「ログインと認証の問題」
B.1. Identity Management サーバー
B.1.1. 外部 CA インストールの失敗
ipa-server-install --external-ca コマンドを実行すると、以下のエラーが出て失敗します。
ipa : CRITICAL failed to configure ca instance Command '/usr/sbin/pkispawn -s CA -f /tmp/configuration_file' returned non-zero exit status 1 Configuration of CA failed
env|grep proxy コマンドで、以下のような変数が表示されます。
env|grep proxy http_proxy=http://example.com:8080 ftp_proxy=http://example.com:8080 https_proxy=http://example.com:8080
エラー内容:
*_proxy 環境変数がサーバーのインストールを妨げています。
解決方法:
- 以下のシェルスクリプトを使用して
*_proxy環境変数の設定を解除します。# for i in ftp http https; do unset ${i}_proxy; done pkidestroyユーティリティーを実行して、インストールに失敗した CA サブシステムを削除します。# pkidestroy -s CA -i pki-tomcat; rm -rf /var/log/pki/pki-tomcat /etc/sysconfig/pki-tomcat /etc/sysconfig/pki/tomcat/pki-tomcat /var/lib/pki/pki-tomcat /etc/pki/pki-tomcat /root/ipa.csr
- インストールに失敗した IdM サーバーを削除します。
# ipa-server-install --uninstall
ipa-server-install --external-caを再実行します。
B.1.2. named デーモンの起動失敗
named-pkcs11 が起動に失敗します。/var/log/messages ファイルには、named-pkcs11 サービスと ldap.so ライブラリーに関する以下のエラーメッセージが含まれます。
ipaserver named[6886]: failed to dynamically load driver 'ldap.so': libldap-2.4.so.2: cannot open shared object file: No such file or directory
エラー内容:
named-pkcs11 サービスの起動を妨げています。
解決方法:
- bind-chroot パッケージをアンインストールします。
# yum remove bind-chroot
- IdM サーバーを再起動します。
# ipactl restart
B.1.3. IPv6 を無効にしたシステムにおけるサーバーのインストールの失敗
CRITICAL Failed to restart the directory server Command '/bin/systemctl restart dirsrv@EXAMPLE.service' returned non-zero exit status 1
エラー内容:
解決方法:
B.2. Identity Management レプリカ
- Red Hat Directory Server でのレプリカ問題に関する説明については、『Directory Server 『Administration Guide』』の 「Solving Common Replication Conflicts」 セクションを参照してください。
- レプリケーションが機能しているかどうかをテストする方法については、「新規レプリカのテスト」 を参照してください。
- Directory Server
repl-monitorスクリプトはレプリケーションの進捗状況を表示するので、レプリカ問題のトラブルシューティングに役立ちます。このスクリプトについての詳細情報は、『Directory Server 『Administration Guide』』の 「repl-monitor (Monitors Replication Status)」 セクションを参照してください。
B.2.1. AD ユーザーの新規レプリカに対する認証の失敗
エラー内容:
解決方法:
B.2.2. レプリカを起動すると Directory Server ログに SASL、GSS-API、および Kerberos などのエラーが発生する問題
slapd_ldap_sasl_interactive_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: error -2 (Local error) (SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Credentials cache file '/tmp/krb5cc_496' not found)) ...
set_krb5_creds - Could not get initial credentials for principal [ldap/ replica1.example.com] in keytab [WRFILE:/etc/dirsrv/ds.keytab]: -1765328324 (Generic error)
エラー内容:
Replication bind with GSSAPI auth resumed
B.2.3. DNS の正引きレコードが逆引きアドレスと一致しない問題
ipa: DEBUG: approved_usage = SSLServer intended_usage = SSLServer ipa: DEBUG: cert valid True for "CN=replica.example.com,O=EXAMPLE.COM" ipa: DEBUG: handshake complete, peer = 192.0.2.2:9444 Certificate operation cannot be completed: Unable to communicate with CMS (Not Found) ... ipa: DEBUG: Created connection context.ldap2_21534032 ipa: DEBUG: Destroyed connection context.ldap2_21534032 The DNS forward record replica.example.com. does not match the reverse address replica.example.org
エラー内容:
解決方法:
B.2.4. シリアル番号が見つからないエラー
注記
0 に適用可能です。詳細は7章ドメインレベルの表示と引き上げを参照してください。
Certificate operation cannot be completed: EXCEPTION (Certificate serial number 0x2d not found)
エラー内容:
- レプリカ A がホストに証明書を発行します。
- レプリカ A とレプリカ B の間には証明書複製合意がないため、この証明書はレプリカ B に複製されません。
- ユーザーがレプリカ B を使ってホストを管理しようとします。
- レプリカ B が、ホストの証明書シリアル番号を確認できないというエラーを返します。これは、レプリカ B のデータディレクトリーにはホストに関する情報はあるものの、証明書ディレクトリーにはホストの証明書がないためです。
解決方法:
ipa-csreplica-manage connectコマンドを使って、2 つのレプリカ間の証明書サーバー複製を有効にします。command. See 「複製合意の作成と削除」 を参照してください。- 一方のレプリカをもう一方のレプリカから再度初期化して、同期します。「レプリカの再初期化」 を参照してください。
警告
再初期化を行ったレプリカのデータは、もう一方のレプリカのデータで上書きされ、情報が失われる可能性があります。
B.2.5. レプリカ更新ベクター (RUV) 消去のエラー
注記
0 に適用可能です。詳細は7章ドメインレベルの表示と引き上げを参照してください。
- レプリカを削除する際に、「複製合意の削除」 にあるように複製合意を最初に削除しなかったため。
- レプリカの削除時に別のレプリカがオフラインであったため。
エラー内容:
注記
解決方法:
ipa-replica-manage list-ruvコマンドを使って古くなった RUV についての詳細を一覧表示します。レプリカの ID が表示されます。# ipa-replica-manage list-ruv server1.example.com:389: 6 server2.example.com:389: 5 server3.example.com:389: 4 server4.example.com:389: 12
ipa-replica-manage clean-ruv replica_IDコマンドを使って、破損している RUV を消去します。このコマンドは、指定されたレプリカに関連付けられている RUV を消去します。古い RUV のあるレプリカについて、コマンドを繰り返します。# ipa-replica-manage clean-ruv 6 # ipa-replica-manage clean-ruv 5 # ipa-replica-manage clean-ruv 4 # ipa-replica-manage clean-ruv 12
警告
ipa-replica-manage clean-ruvは慎重に使用してください。有効なレプリカ ID でこのコマンドを実行すると、複製データベースにあるそのレプリカに関連する前データが破損することになります。その場合には、「レプリカの再初期化」 にあるように別のレプリカから当該レプリカを再初期化してください。ipa-replica-manage list-ruvを再実行します。- コマンドを実行して破損した RUV が表示されなければ、レコードは正常に消去されています。
- まだ破損した RUV が表示される場合は、以下のタスクを使用して手動でこれを消去します。
dn: cn=clean replica_ID, cn=cleanallruv, cn=tasks, cn=config objectclass: extensibleObject replica-base-dn: dc=example,dc=com replica-id: replica_ID replica-force-cleaning: no cn: clean replica_ID
- お使いのサーバーでアクティブなレプリカの ID を見つけ、そこから破損していない信頼できるレプリカの ID リストを作成します。有効なレプリカの ID を見つけるには、トポロジー内の全ノードに対して以下の LDAP クエリーを実行します。
# ldapsearch -p 389 -h IdM_node -D "cn=directory manager" -W -b "cn=config" "(objectclass=nsds5replica)" nsDS5ReplicaId
- 全サーバーで
ipa-replica-manage list-ruvを実行します。破損していないレプリカの ID リストにないレプリカ ID を書き留めます。 - 破損しているレプリカ ID すべてで
ipa-replica-manage clean-ruv replica_IDを実行します。
B.2.6. 失われた CA サーバーの復旧
注記
0 に適用可能です。詳細は7章ドメインレベルの表示と引き上げを参照してください。
エラー内容:
解決方法:
- CA サーバーをバックアップから復旧します。詳細は 「バックアップの復元」 を参照してください。これで CA サーバーがレプリカで利用可能になります。
- 元のサーバーとレプリカ間の複製合意を削除して、複製の競合を防ぎます。詳細は 「複製合意の作成と削除」 を参照してください。
- CA をレプリカにインストールします。「レプリカのマスター CA サーバーへのプロモート」 を参照してください。
- オリジナルの CA サーバーの使用を停止します。詳細は 「レプリカの削除」 を参照してください。
B.3. Identity Management クライアント
/etc/sssd.confファイルを検証する方法については、『システムレベルの認証ガイド』 を参照してください。
B.3.1. 外部 DNS を使用すると逆引きルックアップをクライアントで解決できない問題
Jun 30 11:11:48 server1 krb5kdc[1279](info): AS_REQ (4 etypes {18 17 16 23}) 192.0.2.1: NEEDED_PREAUTH: admin EXAMPLE COM for krbtgt/EXAMPLE COM EXAMPLE COM, Additional pre-authentication required
Jun 30 11:11:48 server1 krb5kdc[1279](info): AS_REQ (4 etypes {18 17 16 23}) 192.0.2.1: ISSUE: authtime 1309425108, etypes {rep=18 tkt=18 ses=18}, admin EXAMPLE COM for krbtgt/EXAMPLE COM EXAMPLE COM
Jun 30 11:11:49 server1 krb5kdc[1279](info): TGS_REQ (4 etypes {18 17 16 23}) 192.0.2.1: UNKNOWN_SERVER: authtime 0, admin EXAMPLE COM for HTTP/server1.wrong.example.com@EXAMPLE.COM, Server not found in Kerberos databaseエラー内容:
解決方法:
- お使いの DNS 設定を検証し、IdM が使用する DNS ドメインが適切に委任されていることを確認します。詳細は、「ホスト名および DNS の設定」 を参照してください。
- 逆引き (PTR) DNS レコード設定を確認します。詳細は「32章DNS の管理」を参照してください。
B.3.2. クライアントが DNS ゾーンに追加されない問題
ipa-client-install ユーティリティー実行時に、nsupdate ユーティリティーがクライアントを DNS ゾーンに追加することに失敗します。
エラー内容:
解決方法:
- 親ゾーンから IdM への DNS 委任の設定を確認します。詳細は 「ホスト名および DNS の設定」 を参照してください。
- IdM ゾーンでの動的更新が有効になっていることを確認します。詳細は 「動的 DNS 更新の有効化」 を参照してください。
B.3.3. クライアント接続の問題
getent passwd admin コマンドなど) に失敗します。
エラー内容:
解決方法:
/var/log/sssd/ の SSSD ログをチェックします。このディレクトリーには、sssd_example.com.log などの DNS ドメイン用のログファイルが格納されています。
/etc/sssd/sssd.confファイルで、[domain/example.com]セクションを探します。debug_levelオプションを調整して、ログにより多くの情報を記録するようにします。debug_level = 9
sssdサービスを再起動します。# systemctl start sssd
- 再度
sssd_example.com.logをチェックします。ファイルにはより多くのエラーメッセージが含まれているはずです。
B.4. ログインと認証の問題
B.4.1. ipa コマンド実行時の Kerberos GSS の失敗
ipa コマンドを実行しようとすると、以下のような Kerberos エラーが発生します。
ipa: ERROR: Kerberos error: ('Unspecified GSS failure. Minor code may provide more information', 851968)/('Decrypt integrity check failed', -1765328353)エラー内容:
解決方法:
- IdM サーバーの DNS 要件については、「ホスト名および DNS の設定」 を参照してください。
- Active Directory 信頼の DNS 要件については、『Windows 統合ガイド』 の DNS およびレルム設定 を参照してください。
B.4.2. GSS-API 使用時の SSH 接続の失敗
エラー内容:
解決方法:
/etc/ssh/ssh_config ファイル内で GSSAPITrustDNS を no に設定します。逆引き DNS レコードを使用する代わりに、SSH は特定のユーザー名を GSS-API に直接渡します。
B.4.3. OTP トークンが同期されない問題
解決方法:
- IdM web UI では、ログインページの Sync OTP Token をクリックします。

図B.1 OTP トークンの同期
コマンドラインでは、ipa otptoken-syncコマンドを実行します。 - トークンの再同期に必要な情報を提供します。たとえば、IdM は標準パスワードとトークンが生成する 2 つのトークンコードを要求します。
注記
再同期は、パスワードの有効期限が切れていても、実行できます。期限切れのパスワードを使用してトークンを再同期した後に IdM にログインすると、システムがパスワードの変更を要求します。
B.4.4. スマートカード認証でタイムアウトエラーメッセージが出て失敗する問題
sssd_pam.log と sssd_EXAMPLE.COM.log のファイルに以下のようなタイムアウトのエラーメッセージが含まれます。
Wed Jun 14 18:24:03 2017) [sssd[pam]] [child_handler_setup] (0x2000): Setting up signal handler up for pid [12370] (Wed Jun 14 18:24:03 2017) [sssd[pam]] [child_handler_setup] (0x2000): Signal handler set up for pid [12370] (Wed Jun 14 18:24:08 2017) [sssd[pam]] [pam_initgr_cache_remove] (0x2000): [idmeng] removed from PAM initgroup cache (Wed Jun 14 18:24:13 2017) [sssd[pam]] [p11_child_timeout] (0x0020): Timeout reached for p11_child. (Wed Jun 14 18:24:13 2017) [sssd[pam]] [pam_forwarder_cert_cb] (0x0040): get_cert request failed. (Wed Jun 14 18:24:13 2017) [sssd[pam]] [pam_reply] (0x0200): pam_reply called with result [4]: System error.
エラー内容:
解決方法:
/etc/sssd/sssd.conf ファイルに変更を加えます。
[pam]セクションのp11_child_timeoutの値を 60 秒に増やします。[domain/EXAMPLE.COM]セクションのkrb5_auth_timeoutの値を 60 秒に増やします。- 証明書で OCSP を使用している場合は、OCSP サーバーに到達できることを確認します。OCSP サーバーに直接到達できない場合は、プロキシー OCSP サーバー設定で
/etc/sssd/sssd.confに以下のオプションを追加します。certificate_verification = ocsp_default_responder=http://ocsp.proxy.url, ocsp_default_responder_signing_cert=nickname
nickname を、/etc/pki/nssdb/ディレクトリー内の証明書に署名する OCSP のニックネームに置き換えます。これらのオプションの詳細については、sssd.conf(5) man ページを参照してください。
付録C Identity Management ファイルおよびログのリファレンス
C.1. Identity Management 設定ファイルおよびディレクトリー
表C.1 IdM サーバーおよびクライアント設定ファイルとディレクトリー
| ディレクトリーまたはファイル | 詳細 |
|---|---|
/etc/ipa/ | IdM のメインの設定ディレクトリーです。 |
/etc/ipa/default.conf | IdM の主要な設定ファイル。サーバーやクライアントの起動時や、ユーザーが ipa ユーティリティーを使用する際に参照されます。 |
/etc/ipa/server.conf |
オプションの設定ファイルはデフォルトでは存在しません。IdM サーバーが起動時に参照されます。
このファイルが存在する場合は、
/etc/ipa/default.conf よりも優先されます。
|
/etc/ipa/cli.conf |
オプションの設定ファイルはデフォルトでは存在しません。ユーザーが
ipa ユーティリティーを使用する場合に参照されます。
このファイルが存在する場合は、
/etc/ipa/default.conf よりも優先されます。
|
/etc/ipa/ca.crt | IdM サーバーの認証局で発行された認証局証明書です。 |
~/.ipa/ |
ユーザーが IdM コマンドを初回実行時に、ローカルシステムに作成されるユーザー固有の IdM ディレクトリー
ユーザーは、
~./ipa/ に、ユーザー固有の default.conf、server.conf または cli.conf ファイルを作成することで、個別設定のオーバーライドを設定することができます。
|
/etc/sssd/sssd.conf | SSSD が使用する IdM ドメインや IdM サービスの設定 |
/usr/share/sssd/sssd.api.d/sssd-ipa.conf | IdM 関連の SSSD オプションのスキーマおよびその値 |
/etc/gssproxy/ | GSS プロキシープロトコルの設定用のディレクトリー。このディレクトリーには、各 GSS-API サービスのファイルと、一般的な /etc/gssproxy/gssproxy.conf ファイルが含まれます。 |
表C.2 システムサービスファイルとディレクトリー
| ディレクトリーまたはファイル | 詳細 |
|---|---|
/etc/sysconfig/ | systemd 固有のファイル |
表C.3 Web UI ファイルおよびディレクトリー
| ディレクトリーまたはファイル | 詳細 |
|---|---|
/etc/ipa/html/ | IdM web UI が使用する HTML ファイルのシンボリックリンク |
/etc/httpd/conf.d/ipa.conf | web UI アプリケーションの Apache ホストで使用される設定ファイル |
/etc/httpd/conf.d/ipa-rewrite.conf | |
/etc/httpd/conf/ipa.keytab | Web サーバーが使用する keytab ファイル |
/usr/share/ipa/ | web UI で使用される HTML ファイル、スクリプト、およびスタイルシートすべてのディレクトリー |
/usr/share/ipa/ipa.conf | |
/usr/share/ipa/updates/ | IdM の LDAP データ、設定、スキーマの更新が含まれます。 |
/usr/share/ipa/html/ | web UI で使用される HTML ファイル、JavaScript ファイル、およびスタイルシートが含まれます。 |
/usr/share/ipa/migration/ | IdM サーバーを移行モードで実行する際に使用される HTML ページ、スタイルシート、および Python スクリプトが含まれます。 |
/usr/share/ipa/ui/ | IdM 操作を実行するため UI で使用されるスクリプトが含まれます。 |
/etc/httpd/conf.d/ipa-pki-proxy.conf | Web サーバーと証明書システムのブリッジ用の設定 |
表C.4 Kerberos ファイルおよびディレクトリー
| ディレクトリーまたはファイル | 詳細 |
|---|---|
/etc/krb5.conf | Kerberos サービスの設定ファイル |
/var/lib/sss/pubconf/krb5.include.d/ | Kerberos クライアント設定用の IdM 固有のオーバライドが含まれます。 |
表C.5 ディレクトリーサーバーのファイルおよびディレクトリー
| ディレクトリーまたはファイル | 詳細 |
|---|---|
/var/lib/dirsrv/slapd-REALM_NAME/ | IdM サーバーで使用される Directory Server インスタンスに関連するデータベース |
/etc/sysconfig/dirsrv | dirsrv systemd サービスの IdM 固有の設定 |
/etc/dirsrv/slapd-REALM_NAME/ | IdM サーバーで使用される Directory Server インスタンスに関連する設定ファイルおよびスキーマファイル |
表C.6 証明書システムのファイルとディレクトリー
| ディレクトリーまたはファイル | 詳細 |
|---|---|
/etc/pki/pki-tomcat/ca/ | IdM 認証局インスタンスのメインのディレクトリー |
/var/lib/pki/pki-tomcat/conf/ca/CS.cfg | IdM 認証局インスタンスのメインの設定ファイル |
表C.7 キャッシュファイルとディレクトリー
| ディレクトリーまたはファイル | 詳細 |
|---|---|
~/.cache/ipa/ | IdM クライアントのサーバー別の API スキーマが含まれます。IdM は、クライアント上の API スキーマを 1 時間キャッシュします。 |
表C.8 システムのバックアップファイルとディレクトリー
| ディレクトリーまたはファイル | 詳細 |
|---|---|
/var/lib/ipa/sysrestore/ | IdM サーバーのインストール時に再設定されたスクリプトおよびシステムファイルのバックアップが格納されます。NSS、Kerberos (krb5.conf と kdc.conf の両ファイル)、および NTP のオリジナルの .conf ファイルなどが含まれます。 |
/var/lib/ipa-client/sysrestore/ | IdM クライアントのインストール時に再設定されたスクリプトおよびシステムファイルのバックアップが格納されます。一般的には SSSD 認証サービスの sssd.conf ファイルなどが含まれます。 |
C.2. Identity Management ログファイルおよびディレクトリー
表C.9 IdM サーバーおよびクライアントのログファイルおよびディレクトリー
| ディレクトリーまたはファイル | 詳細 |
|---|---|
/var/log/ipaserver-install.log | IdM サーバーのインストールログ |
/var/log/ipareplica-install.log | IdM レプリカのインストールログ |
/var/log/ipaclient-install.log | IdM クライアントのインストールログ |
/var/log/sssd/ | SSSD のログファイル |
~/.ipa/log/cli.log | XML-RPC 呼び出しで返されるエラーと ipa ユーティリティーの応答に関するログファイルです。ツールを実行する システムユーザー のホームディレクトリーに作成されます。IdM のユーザー名とは異なるユーザー名の場合があります。 |
/etc/logrotate.d/ | DNS、SSSD、Apache、Tomcat、および Kerberos のログローテーションのポリシー |
表C.10 Apache サーバーのログファイル
| ディレクトリーまたはファイル | 詳細 |
|---|---|
/var/log/httpd/ | Apache web サーバーのログファイル |
/var/log/httpd/access_log | Apache サーバーの標準アクセスおよびエラーログ。IdM Web UI および XML-RPC コマンドラインのインターフェースが Apache を使用するため、IdM 固有のメッセージが Apache メッセージに合わせて記録されます。 |
/var/log/httpd/error_log | |
| 詳細は、Apache ドキュメントの「Log Files」を参照してください。 | |
表C.11 証明書システムのログファイル
| ディレクトリーまたはファイル | 詳細 |
|---|---|
/var/log/pki/pki-ca-spawn.time_of_installation.log | IdM 認証局のインストールログ |
/var/log/pki/pki-kra-spawn.time_of_installation.log | IdM KRA のインストールログ |
/var/log/pki/pki-tomcat/ | PKI の操作ログ用の最上位ディレクトリー。CA および KRA ログが含まれます。 |
/var/log/pki/pki-tomcat/ca/ | 証明書の操作関連のログを含むディレクトリー。IdM ではサービスプリンシパル、ホスト、および証明書を使用するその他のエンティティーに使用されます。 |
/var/log/pki/pki-tomcat/kra | KRA 関連のログが含まれるディレクトリー |
/var/log/messages | 証明書のエラーメッセージなど、他のシステムメッセージが含まれます。 |
| 詳細は、Red Hat Certificate System『Administration Guide』の「Configuring Subsystem Logs」を参照してください。 | |
表C.12 ディレクトリーサーバーのログファイル
| ディレクトリーまたはファイル | 詳細 |
|---|---|
/var/log/dirsrv/slapd-REALM_NAME/ |
IdM サーバーで使用される Directory Server インスタンスに関連するログファイル。ここに記録される操作データの大半は、サーバーレプリカの対話に関連します。
|
/var/log/dirsrv/slapd-REALM_NAME/access |
ドメイン Directory Server インスタンスに対して試行されたアクセスおよび動作の詳細情報が含まれます。
|
/var/log/dirsrv/slapd-REALM_NAME/errors | |
/var/log/dirsrv/slapd-REALM_NAME/audit | ディレクトリーサーバー設定で監査が有効になっている場合には、ディレクトリーサーバーの操作の監査証跡が含まれます。 |
| 詳細は、Red Hat Directory Server ドキュメントの「Monitoring Server and Database Activity」と「Log File Reference」を参照してください。 | |
表C.13 Kerberos ログファイル
| ディレクトリーまたはファイル | 詳細 |
|---|---|
/var/log/krb5kdc.log | Kerberos KDC サーバーのプライマリーログファイル |
/var/log/kadmind.log | Kerberos 管理サーバーのプライマリーログファイル |
これらのファイルの場所は krb5.conf ファイルで設定します。システムによっては場所が異なる場合があります。 | |
表C.14 DNS ログファイル
| ディレクトリーまたはファイル | 詳細 |
|---|---|
/var/log/messages |
DNS のエラーメッセージなど、他のシステムメッセージが含まれます。
このファイルの DNS ロギングはデフォルトでは有効ではありません。有効化するには、
# /usr/sbin/rndc querylog コマンドを実行し、ロギングを無効化するには、もう一度このコマンドを実行します。
|
その他のリソース
journalctlユーティリティーの使用方法に関する情報は、『システム管理者のガイド』「Journal の使用」を参照してください。systemdのユニットファイルのロギングの出力を表示するにはjournalctlを使用してください。
C.3. IdM ドメインサービスとログローテーション
logrotate サービスを使用するものがあります。
named(DNS)httpd(Apache)tomcatsssdkrb5kdc(Kerberos ドメインコントローラー)
logrotate 設定ファイルは/etc/logrotate.d/ ディレクトリーに格納されます。
例C.1 デフォルトの httpd のログローテーションファイルは /etc/logrotate.d/httpd にあります。
/var/log/httpd/*log {
missingok
notifempty
sharedscripts
delaycompress
postrotate
/sbin/service httpd reload > /dev/null 2>/dev/null || true
endscript
}警告
logrotate ポリシーファイルでは、以前のログと同じ名前、デフォルトの所有者、デフォルトのパーミッションで新しいログファイル作成します。ただし、named および tomcat のファイルでは、特別な create ルールにより、明示的なパーミッション、ユーザー、グループの所有権でこの動作が設定されます。
named および tomcat ログファイルを所有するユーザーとグループまたはパーミッションは変更しないようにしてください。IdM の動作および SELinux 設定の両方に必要な値です。ログローテーションポリシーやファイルの所有権を変更すると IdM ドメインサービスが実行に失敗する可能性があります。
その他のリソース
- Dogtag Certificate System および IdM でバックエンドとして使用される 389 Directory Server インスタンスには独自の内部ログローテーションポリシーがあります。Red Hat Directory Server 『Administration Guide』の「Configuring Log Files」を参照してください。
- ログファイルの圧縮設定やサイズなど、その他に考えられるログローテーションの設定に関する詳細は、『システム管理者のガイド』の「ログローテーション」か、logrotate(8) の man ページを参照してください。
付録D ドメインレベル 0 でのレプリカの管理
0 (7章ドメインレベルの表示と引き上げ を参照) でのレプリカ管理について説明しています。ドメインレベル 1 でのレプリカ管理については、以下のリンクを参照してください。
D.1. レプリカ情報ファイル
ipa-replica-prepare ユーティリティーは、/var/lib/ipa/ ディレクトリー内にレプリカサーバーの名前を付けたレプリカ情報ファイル を作成します。このレプリカ情報ファイルは GPG 暗号化ファイルで、マスターサーバー用のレルムおよび設定情報が含まれています。
ipa-replica-install レプリカ設定スクリプトは、レプリカ情報ファイルに含まれている情報を基に Directory Server インスタンスを設定し、レプリカ初期化 プロセスを開始します。このプロセス中にスクリプトは、マスターサーバーからレプリカにデータをコピーします。レプリカ情報ファイルは、そのファイルが作成された特定マシン上のレプリカのインストールにのみ使用できます。複数マシン上の複数のレプリカ作成には使用できません。
D.2. レプリカの作成
- これらの手順と例は相互排除的なものではなく、CA、DNS、および他のコマンドラインオプションは同時に使うことができます。以下のセクション例は、各設定エリアで必要なものを明確にするために個別に示されています。
ipa-replica-installユーティリティーは多くのオプションを受け付けます。これらの完全一覧については、ipa-replica-install(1) man ページを参照してください。
D.2.1. DNS なしのレプリカのインストール
- マスター IdM サーバー上で、
ipa-replica-prepareユーティリティーを実行して、レプリカの完全修飾ドメイン名 (FQDN) を追加します。レプリカの IP アドレスに他のサーバーが到達できないと、ipa-replica-prepareスクリプトはその IP アドレスの確認や検証を実行しないことに注意してください。重要
完全修飾ドメイン名は有効な DNS 名である必要があります。つまり、許可されるのは数字、アルファベット、ハイフン (-) のみです。ホスト名にアンダースコアのような他の文字があると、DNS エラーが発生します。また、ホスト名はすべて小文字を使用する必要があり、大文字は使用できません。命名プラクティスに関する他の推奨事項については、Red Hat Enterprise Linux セキュリティーガイド を参照してください。マスターサーバーが統合 DNS で設定されている場合は、--ip-addressオプションを使ってレプリカマシンの IP アドレスを指定します。すると、インストールスクリプトはレプリカに逆引きゾーンを設定するかどうかを尋ねます。IdM サーバーが統合 DNS で設定されている場合にのみ、--ip-addressを渡します。これ以外の場合にこのオプションを渡すと、更新する DNS レコードが存在しないため、DNS レコード操作が失敗して、レプリカ作成も失敗することになります。プロンプトが出たら、最初のサーバーの Directory Manager (DM) パスワードを入力します。ipa-replica-prepareの出力では、以下のようにレプリカ情報ファイルの場所が示されます。[root@server ~]# ipa-replica-prepare replica.example.com --ip-address 192.0.2.2 Directory Manager (existing master) password: Do you want to configure the reverse zone? [yes]: no Preparing replica for replica.example.com from server.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-replica.example.com.gpg Adding DNS records for replica.example.com Waiting for replica.example.com. A or AAAA record to be resolvable This can be safely interrupted (Ctrl+C) The ipa-replica-prepare command was successful警告
レプリカ情報ファイルには機密情報が含まれています。適切な措置を講じてこの情報を保護してください。ipa-replica-prepareで使用可能な他のオプションについては、ipa-replica-prepare(1) man ページを参照してください。 - レプリカマシン上で、ipa-server パッケージをインストールします。
[root@replica ~]# yum install ipa-server
- 最初のサーバーからレプリカマシンに、レプリカ情報ファイルをコピーします。
[root@server ~]# scp /var/lib/ipa/replica-info-replica.example.com.gpg root@replica:/var/lib/ipa/
- レプリカマシン上で、
ipa-replica-installユーティリティーを実行してレプリカ情報ファイルの場所を追加し、レプリカ初期化プロセスを開始します。プロンプトが出たら、オリジナルのマスターサーバーの Directory Manager および管理者パスワードを入力し、インストールスクリプトが完了するまで待機します。[root@replica ~]# ipa-replica-install /var/lib/ipa/replica-info-replica.example.com.gpg Directory Manager (existing master) password: Run connection check to master Check connection from replica to remote master 'server.example.com': ... 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@MASTER.EXAMPLE.COM password: Check SSH connection to remote master ... Connection from master to replica is OK. ... Configuring NTP daemon (ntpd) [1/4]: stopping ntpd [2/4]: writing configuration ... Restarting Directory server to apply updates [1/2]: stopping directory server [2/2]: starting directory server Done. Restarting the directory server Restarting the KDC Restarting the web server
注記
インストールされているレプリカファイルが現行のホスト名と一致しない場合は、スクリプトは警告メッセージを表示し、確認を求めます。マルチホームのマシンなどの場合には、ホスト名が一致しない場合でも継続できることがあります。ipa-replica-installで使用可能な他のオプションについては、ipa-replica-prepare(1) man ページを参照してください。ipa-replica-installが受け付けるオプションの 1 つに--ip-addressがあります。これをipa-replica-installに追加する場合は、--ip-addressはローカルインターフェイスに関連付けられた IP アドレスのみを受け付けます。
D.2.2. DNS ありのレプリカのインストール
ipa-replica-install に追加します。
--setup-dns--forwarder
[root@replica ~]# ipa-replica-install /var/lib/ipa/replica-info-replica.example.com.gpg --setup-dns --forwarder 198.51.100.0
ipa-replica-install を実行した後に、DNS エントリーが正常に作成されたことを確認します。またオプションで、別の DNS サーバーをバックアップとして追加することもできます。詳細は、「DNS ありのレプリカのインストール」 を参照してください。
D.2.3. 各種 CA 設定を伴うレプリカのインストール
警告
Certificate System CA がインストールされたサーバーからレプリカをインストールする
--setup-ca オプションを ipa-replica-install ユーティリティーに追加します。この --setup-ca オプションは、CA 設定を初期サーバーの設定からコピーします。
[root@replica ~]# ipa-replica-install /var/lib/ipa/replica-info-replica.example.com.gpg --setup-ca
Certificate System CA がインストールされていないサーバーからレプリカをインストールする
ipa-replica-prepare を実行する際に以下のオプションを追加します。
--dirsrv-cert-file--dirsrv-pin--http-cert-file--http-pin
[root@server ~]# ipa-replica-prepare replica.example.com --dirsrv-cert-file /tmp/server.key --dirsrv-pin secret --http-cert-file /tmp/server.crt --http-cert-file /tmp/server.key --http-pin secret --dirsrv-cert-file /tmp/server.crt
D.2.4. 新たなレプリカ合意の追加
ipa-replica-install を使ってレプリカをインストールすると、初期のレプリカ合意がマスターサーバーとレプリカ間で作成されます。レプリカを他のサーバーや他のレプリカと接続するには、ipa-replica-manage ユーティリティーで新たな合意を追加します。
ipa-csreplica-manage ユーティリティーを使用します。
D.3. レプリカとレプリカ合意の管理
注記
D.3.1. レプリカ合意についての説明
注記
ipa-replica-install スクリプトが 2 つのレプリカ間にセットアップします。最初のレプリカのインストールについては、4章Identity Management のレプリカのインストールとアンインストール を参照してください。
レプリカ合意のタイプ
- ユーザー、グループ、およびポリシーなどのディレクトリーデータを複製するレプリカ合意。これらの合意は、
ipa-replica-manageユーティリティーで管理します。 - 証明書サーバーデータを複製するレプリカ合意。これらの合意は、
ipa-csreplica-manageユーティリティーで管理します。 - Active Directory サーバーとユーザー情報を複製する同期合意。この合意については、本書では説明していません。IdM と Active Directory との同期に関するドキュメントについては、Windows 統合ガイド を参照してください。
ipa-replica-manage と ipa-csreplica-manage では、同じ形式と引数を使用します。以下のセクションでは、これらのユーティリティーを使用して実行するレプリカ管理のうち、特に重要な操作を取り上げます。これらのユーティリティーについての詳細情報は、ipa-replica-manage(1) と ipa-csreplica-manage(1) の man ページを参照してください。
D.3.2. レプリカ合意の一覧表示
ipa-replica-manage list コマンドを使用します。
ipa-replica-manage listを引数なしで実行すると、レプリカトポロジー内の全レプリカが一覧表示されます。出力で、必要なレプリカを見つけます。$ ipa-replica-manage list server1.example.com: master server2.example.com: master server3.example.com: master server4.example.com: master- レプリカのホスト名を
ipa-replica-manage listに追加して実行すると、レプリカ合意が一覧表示されます。$ ipa-replica-manage list server1.example.com server2.example.com: replica server3.example.com: replica
この出力では、server1.example.comが更新を送信する宛先が表示されています。
ipa-csreplica-manage list コマンドを使用します。
D.3.3. 複製合意の作成と削除
レプリカ同意の作成
ipa-replica-manage connect コマンドを使用します。
$ ipa-replica-manage connect server1.example.com server2.example.com
ipa-replica-manage connect で 1 つのサーバーだけを指定知ると、IdM はローカルホストとその指定されたサーバー間のレプリカ合意を作成します。
ipa-csreplica-manage connect コマンドを使用します。
複製合意の削除
ipa-replica-manage disconnect コマンドを使用します。
$ ipa-replica-manage disconnect server1.example.com server4.example.com
ipa-replica-manage disconnect コマンドは、レプリカ合意が削除されるだけです。Identity Management レプリカトポロジー内のサーバーはどちらも残されたままです。すべてのレプリカ合意とレプリカに関するデータを削除するには、ipa-replica-manage del コマンドを使用します。これで Identity Management ドメインからレプリカが完全に削除されます。
$ ipa-replica-manage del server2.example.com
ipa-csreplica-manage disconnect コマンドを使用します。同様に、2 つのサーバー間証明書合意とデータすべてを削除するには、ipa-csreplica-manage del コマンドを使用します。
D.3.4. 手動によるレプリカ更新の開始
ipa-replica-manage force-sync コマンドを使用します。このコマンドを実行するローカルホストは、更新を受け取るレプリカになります。更新の送信先となるレプリカを指定するには、--from オプションを使用します。
$ ipa-replica-manage force-sync --from server1.example.com
ipa-csreplica-manage force-sync コマンドを使用します。
D.3.5. レプリカの再初期化
注記
ipa-replica-manage re-initialize コマンドを使用します。このコマンドを実行するローカルホストは、再初期化されるレプリカになります。データの取得元となるレプリカを指定するには、--from オプションを使用します。
$ ipa-replica-manage re-initialize --from server1.example.com
ipa-csreplica-manage re-initialize コマンドを使用します。
D.3.6. レプリカの削除
- IdM ドメインの全レプリカ合意を一覧表示します。出力にあるレプリカのホスト名を書き留めます。
$ ipa-replica-manage list server1.example.com: master server2.example.com: master server3.example.com: master server4.example.com: master ipa-replica-manage delコマンドを使って当該レプリカ用に設定された全合意とそのレプリカについての全データを削除します。$ ipa-replica-manage del server3.example.com
- レプリカがそれ自体の CA で設定されていた場合は
ipa-csreplica-manage delコマンドも使用して証明書サーバーのレプリカ合意もすべて削除します。$ ipa-csreplica-manage del server3.example.com
注記
このステップは、レプリカ自体が IdM CA で設定されていた場合にのみ必要となります。マスターサーバーまたは他のレプリカのみが CA で設定されていた場合は必要ありません。 - IdM サーバーパッケージをアンインストールします。
$ ipa-server-install --uninstall -U
D.4. レプリカのマスター CA サーバーへのプロモート
- レプリカが CA サブシステムの証明書更新を処理するように設定してください。詳細は、「証明書更新を処理するサーバーの変更」 を参照してください。
- レプリカが CRL を生成するように設定します。「CRL を生成するサーバーの変更」 を参照してください。
D.4.1. 証明書更新を処理するサーバーの変更
- Red Hat Enterprise Linux 7.3 およびそれ以降では、
ipa config-show | grep "CA renewal master"コマンドを使用します。$ ipa config-show | grep "CA renewal master" IPA CA renewal master: server.example.com
- Red Hat Enterprise Linux 7.2 およびそれ以前では、
ldapsearchユーティリティーを使用します。以下の例では、更新マスターはserver.example.comになります。$ ldapsearch -H ldap://$HOSTNAME -D 'cn=Directory Manager' -W -b 'cn=masters,cn=ipa,cn=etc,dc=example,dc=com' '(&(cn=CA)(ipaConfigString=caRenewalMaster))' dn Enter LDAP Password: # extended LDIF # # LDAPv3 # base <cn=masters,cn=ipa,cn=etc,dc=example,dc=com> with scope subtree # filter: (&(cn=CA)(ipaConfigString=caRenewalMaster)) # requesting: dn # # CA, server.example.com, masters, ipa, etc, example.com dn: cn=CA,cn=server.example.com,cn=masters,cn=ipa,cn=etc,dc=example,dc=com # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1
ipa-csreplica-manage ユーティリティーを使用します。
# ipa-csreplica-manage set-renewal-master
付録E 改訂履歴
| 改訂履歴 | |||
|---|---|---|---|
| 改訂 7.0-33.2 | Thu Nov 30 2017 | ||
| |||
| 改訂 7.0-33.1 | Thu Nov 30 2017 | ||
| |||
| 改訂 7.0-33 | Mon Nov 20 2017 | ||
| |||
| 改訂 7.0-32 | Mon Oct 9 2017 | ||
| |||
| 改訂 7.0-31 | Tue Sep 12 2017 | ||
| |||
| 改訂 7.0-30 | Mon Aug 28 2017 | ||
| |||
| 改訂 7.0-29 | Tue Jul 18 2017 | ||
| |||
| 改訂 7.0-28 | Mon Apr 24 2017 | ||
| |||
| 改訂 7.0-27 | Mon Apr 10 2017 | ||
| |||
| 改訂 7.0-26 | Mon Mar 27 2017 | ||
| |||
| 改訂 7.0-25 | Mon Feb 27 2017 | ||
| |||
| 改訂 7.0-24 | Wed Dec 7 2016 | ||
| |||
| 改訂 7.0-23 | Tue Oct 18 2016 | ||
| |||
| 改訂 7.0-22 | Fri Jul 29 2016 | ||
| |||
| 改訂 7.0-21 | Thu Jul 28 2016 | ||
| |||
| 改訂 7.0-19 | Tue Jun 28 2016 | ||
| |||
| 改訂 7.0-18 | Fri Jun 10 2016 | ||
| |||
| 改訂 7.0-17 | Fri May 27 2016 | ||
| |||
| 改訂 7.0-16 | Thu Mar 24 2016 | ||
| |||
| 改訂 7.0-15 | Thu Mar 03 2016 | ||
| |||
| 改訂 7.0-14 | Tue Feb 09 2016 | ||
| |||
| 改訂 7.0-13 | Thu Nov 19 2015 | ||
| |||
| 改訂 7.0-12 | Fri Nov 13 2015 | ||
| |||
| 改訂 7.0-11 | Thu Nov 12 2015 | ||
| |||
| 改訂 7.0-10 | Fri Mar 13 2015 | ||
| |||
| 改訂 7.0-8 | Wed Feb 25 2015 | ||
| |||
| 改訂 7.0-6 | Fri Dec 05 2014 | ||
| |||
| 改訂 7.0-4 | Wed Jun 11 2014 | ||
| |||


