Identity Management ガイド
Linux ベースのインフラストラクチャーの ID および承認ポリシーの管理
概要
第1章 Identity Management の概要
1.1. IdM v.LDAP: より集約的なサービスタイプ
1.1.1. Identity Management の作業定義
- Linux ベースおよび Linux 制御のドメインを作成する。IdM サーバーおよび IdM クライアントはどちらも Linux または Unix マシンです。IdM は Active Directory ドメインとデータを同期して Windows サーバーとの統合を可能にしますが、Windows マシンの管理ツールではないので Windows クライアントはサポート対象ではありません。Identity Management は、Linux ドメインの管理ツールです。
- ID 管理と ID ポリシーを一元化する。
- 既存のネイティブの Linux アプリケーションおよびプロトコル上に構築する。IdM には独自のプロセスと設定がありますが、その基盤となる技術は Linux 管理者から信頼されているだけでなく、Linux システムで十分に確立されています。
1.1.2. Identity Management と標準 LDAP ディレクトリーの比較
389 ディレクトリーサーバー | ID 管理 | |
---|---|---|
使用方法 | 汎用 | 単一のドメイン、ID 管理にフォーカス |
柔軟性 | 高度にカスタマイズ可能 | ID と認証にフォーカスする際に制限あり |
スキーマ | デフォルトの LDAP スキーマ | ID 管理向けに最適化された特別なスキーマ |
ディレクトリーツリー | 標準および柔軟な階層 | 階層が固定されたフラットツリー |
認証 | LDAP | Kerberos または Kerberos および LDAP |
Active Directory の同期 | 双方向 | 一方向、Active Directory から Identity Management |
パスワードポリシー | LDAP ベース | Kerberos ベース |
ユーザーツール | Java コンソールおよび標準の LDAP ユーティリティー | Web ベースの UI および特別な Python コマンドラインツール |
1.2. Linux サービスの統合
図1.1 IdM サーバー: サービスの統合
1.2.1. 認証: Kerberos KDC
1.2.2. データストレージ: 389 Directory Server
1.2.3. 認証: Dogtag Certificate System
1.2.4. サーバー/クライアントの検出: DNS
1.2.5. 管理: SSSD
case_sensitive
オプションで true
、false
、および preserve
の値をサポートします。preserve
値が有効にな場合には、入力内容は大文字と小文字に関係なく一致しますが、出力内容は常にサーバーと同じものを使用します。SSSD は、設定された UID フィールドの大文字、小文字設定を保持します。
1.2.6. 管理: NTP
1.3. サーバーとクライアント間の関係
1.3.1. IdM サーバーおよびレプリカの概要
図1.2 サーバーおよびレプリカの対話
1.3.2. IdM クライアントの概要
図1.3 サーバーおよびクライアントの対話
- マシンがオフライン時に IdM 情報を保存します。
- クライアントが中央サーバーにアクセスできない場合は、通常のタイムアウト期間が過ぎた後も情報をアクティブな状態で保持します。このキャッシュは、マシンをリブートした後も永続されます。
- サーバーを確認する前にローカルで情報をチェックして、要求のラウンドトリップタイムを短縮します。
- ユーザー、マシン、およびグループに関する ID 情報は、LDAP ディレクトリーと同じ構文を使用する LDB データベースに保存されます。この ID 情報は、元は IdM サーバーの 389 Directory Server インスタンスに保存されていました。この情報は頻繁に変更、参照されるため、より最新の情報を迅速に呼び出すことが重要ですが、これは、クライアント上の LDB データベースとサーバーの Directory Server を使用することで可能になります。
- ポリシー情報は ID 情報よりも静的で、SELinux または sudo の設定を追加できます。これらのポリシーはサーバー上でグローバルに設定され、クライアントに伝播されます。クライアントでは、 ポリシー情報は XML ファイルのファイルシステムに保存されるので、どのサービスを管理する場合でも、ダウンロードしてネイティブファイルに変換できます。
図1.4 IdM サービス間の対話
- SSSD では、マシンのユーザー認証ができ、ホストベースのアクセス制御ルールを有効にします。
certmonger
は、クライアント上の証明書を監視、更新します。仮想マシンなどのシステム上のサービス向けに新規の証明書をリクエストできます。
certmonger
は IdM サーバーに接続するように設定され、必要な Kerberos キータブとホストの証明書が作成されます。(ホスト証明書は、Web サーバーなどの他のサービスで使用される可能性はありますが、IdM では直接使用されません。)
パート I. Identity Management のインストール: サーバーおよびサービス
第2章 インストールの前提条件
2.1. サポート対象のサーバープラットフォーム
- Red Hat Enterprise Linux 6 i386
- Red Hat Enterprise Linux 6 x86_64
2.2. ハードウェア推奨事項
- 10,000 ユーザーおよび 100 グループの場合は、最低 2 GB の RAM と 1 GB のスワップ領域を割り当てます。
- 100,000 ユーザーおよび 50,000 グループの場合は、最低 16GB の RAM と 4GB のスワップ領域を割り当てます。
2.3. ソフトウェア要件
- Kerberos 1.10インストールされていない場合は、依存関係としてインストールされます。
- DNS の bind および bind-dyndb-ldap パッケージ。すでにインストールされていない場合には bind パッケージは依存関係としてインストールされますが、bind-dyndb-ldap パッケージは先に明示的にインストールする必要があります。先にインストールされていない場合には、DNS サポートありの IdM サーバーを設定しようとすると失敗します。
mod_nss
モジュールで無効にする必要があります。次の手順に従い、無効になっていることを確認してください。
/etc/httpd/conf.d/nss.conf
ファイルを編集し、NSSProtocol
パラメーターをTLSv1.0
(後方互換性用) およびTLSv1.1
に設定します。NSSProtocol TLSv1.0,TLSv1.1
httpd
サービスを再起動します。# service httpd restart
2.4. システムの要件
2.4.1. DNS レコード
- ホスト名を取得します。
[root@server ~]# hostname server.example.com
- IP アドレスを取得します。この例では、196.2.3.4 の IP アドレスが返されました。
[root@server !]# ifconfig eth0 eth0 Link encap:Ethernet HWaddr 52:54:01:4C:E1:2C
inet addr:196.2.3.4
Bcast:196.9.8.7 Mask:255.255.255.255 inet6 addr: 2620:52:0:102f:5054:1ff:fe4c:e12c/64 Scope:Global inet6 addr: fe80::5054:1ff:fe4c:e12c/64 Scope:Link ... - dig を使用して、ホスト名のクエリーと、返される IP アドレスのチェックを行い、正引き DNS が適切に設定されていることを確認します。この例では、想定される IP アドレスは 196.2.3.4 です。
[root@server ~]# dig server.example.com ; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.17.rc1.el6 <<>> server.example.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 56680 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 7, ADDITIONAL: 12 ;; QUESTION SECTION:
;server.example.com. IN A
;; ANSWER SECTION:server.example.com. 2946 IN A 196.2.3.4
-t ptr
を指定した dig を使用して、アドレスの PTR レコード (逆引きレコード) にクエリーを実行し、 逆引き DNS 設定を確認します。これは、.in-addr.arpa. が追加された、逆順の IP アドレスです。これにより、ホスト名が解決されます (この例では server.example.com.)。[root@server ~]# dig -t ptr 4.3.2.196.in-addr.arpa. ; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.17.rc1.el6 <<>> -t ptr 241.40.16.10.in-addr.arpa ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 57899 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 7, ADDITIONAL: 10 ;; QUESTION SECTION:
;4.3.2.196.in-addr.arpa. IN PTR
;; ANSWER SECTION:4.3.2.196.in-addr.arpa. 21600 IN PTR server.example.com.
2.4.2. ホスト名および IP アドレスの要件
- ホスト名は完全修飾ドメイン名である必要があります。例:
ipaserver.example.com
重要これは、数字、アルファベット文字、およびハイフン (-) のみが使用された有効な DNS 名でなければなりません。ホスト名にアンダースコアなどの他の文字が含まれていると、DNS が正常に機能しなくなります。 - ホスト名はすべて小文字である必要があります。
- サーバーの A レコードを設定し、パブリック IP アドレスを解決する必要があります。完全修飾ドメイン名は、ループバックアドレスを解決できません。
127.0.0.1
ではなく、マシンの公開 IP アドレスを解決する必要があります。hostname コマンドの出力は、localhost
またはlocalhost6
であってはいけません。Adn PTR レコードは、サーバーと一致する必要はありません。 - サーバーのホスト名および IP アドレスは独自の
/etc/hosts
ファイルに指定する必要があります。IdM サーバーの完全修飾ドメイン名は、hosts
ファイルで、エイリアスの 前 にリストする必要があります。注記ファイルが正しく設定されていない場合には、IdM コマンドラインツールが正しく機能しなくなり、IdM の Web インターフェースが IdM サーバーに接続できない可能性があります。また、ホスト名を localhost エントリーに追加することはできません。たとえば、以下の例では、ホストの IPv4 および IPv6 の localhost エントリーが (正確に) 表示され、最初のエントリーで IdM サーバーの IP アドレスとホスト名がその後に続いています。127.0.0.1 localhost.localdomain localhost ::1 localhost6.localdomain6 localhost6 192.168.1.1 ipaserver.example.com ipaserver
- IdM サーバーの管理用に別の DNS ドメインを割り当てることを推奨します。別の DNS ドメインを割り当てることは必須ではありませんが (この IdM ドメインに他のドメインのクライアントを引き続き登録可能)、DNS の管理を行うにあたり便利です。
2.4.3. ディレクトリーサーバー
2.4.4. システムファイル
2.4.5. システムポート
iptables
ユーティリティーで、利用可能なポートを表示するか、nc
、telnet
、または nmap
ユーティリティーを使用して、ポートに接続するか、ポートのスキャンを実行します。
[root@server ~]# iptables -A INPUT -p tcp --dport 389 -j ACCEPT
サービス | ポート | タイプ |
---|---|---|
HTTP/HTTPS | 80、443 | TCP |
LDAP/LDAPS | 389、636 | TCP |
Kerberos | 88、464 | TCP および UDP |
DNS | 53 | TCP および UDP |
NTP | 123 | UDP |
Dogtag Certificate System - LDAP | 7389 | TCP |
2.4.6. NTP
--no-ntp
オプションを使用して、NTP サーバーがインストールされないようにします。
2.4.7. NSCD
nscd
の使用を回避するか、制限することを強く推奨 します。nscd
サービスは、サーバーでの負荷を減らしたり、クライアントの応答性を改善したりするのに非常に便利ですが、システムでも SSSD を使用する場合には独自にキャッシュの操作を行うので、問題が生じる可能性があります。
nscd
は、getent など、nsswitch でクエリーを実行する全サービスの認証およびアイデンティティー情報をキャッシュします。nscd
は、ポジティブキャッシュとネガティブキャッシュの両方を実行するので、特定の IdM ユーザーが存在しないと要求が判断した場合には、ネガティブな応答としてキャッシュします。キャッシュに保存されている値は、サーバーでの変更の有無に拘らず、キャッシュの有効期限が切れるまで保持されます。このようなキャッシュを作成すると、新規ユーザーとメンバーシップが表示されない可能性があり、削除されたユーザーおよびメンバーシップが依然として表示される可能性があります。
nscd
を完全に使用しないようにします。または、/etc/nscd.conf
ファイルの time-to-live (TTL) のキャッシュの値をリセットして、キャッシュ時間を短縮します。
positive-time-to-live group 3600 negative-time-to-live group 60 positive-time-to-live hosts 3600 negative-time-to-live hosts 20
2.4.8. ネットワーク
- シングルユーザーモードでマシンを起動します。
- 起動リストで NetworkManager サービスを無効にし、NetworkManager サービスを停止します。
[root@server ~]# chkconfig NetworkManager off; service NetworkManager stop
NetworkManagerDispatcher
がインストールされている場合には、NetworkManagerDispatcher が停止され、無効になっていることを確認します。[root@server ~]# chkconfig NetworkManagerDispatcher off; service NetworkManagerDispatcher stop
- 次に、
ネットワーク
サービスが適切に起動されていることを確認します。[root@server ~]# chkconfig network on; service network start
- また、静的ネットワークが正しく設定されていることを確認してください。
- システムを再起動します。
第3章 IdM サーバーのインストール
3.1. IdM サーバーパッケージのインストール
ipa-server
パッケージだけが必要です。IdM サーバーが DNS サーバーも管理する場合は、DNS の設定に追加パッケージが 2 つ必要になります。
[root@server ~]# yum install ipa-server bind bind-dyndb-ldap
ipa-server
をインストールすると、IdM ツールと合わせて、LDAP サービスの 389-ds-base や Keroberos サービスの krb5-server などの依存関係が多数インストールされます。
3.2. ipa-server-install の概要
- ネットワークタイムデーモン(ntpd)
- 389 Directory Server インスタンス
- Kerberos キー配布センター (KDC)
- Apache (httpd)
- 更新された SELinux ターゲットポリシー
- Active Directory WinSync プラグイン
- 認証局
- 任意。ドメインネームサービス (DNS) サーバー
引数 | 説明 |
---|---|
-a ipa_admin_password | IdM 管理者のパスワードこれは、admin ユーザーが Kerberos レルムに対して認証する場合に使用されます。 |
--hostname=hostname | IdM サーバーマシンの完全修飾ドメイン名。
重要
これは、数字、アルファベット文字、およびハイフン (-) のみが使用された有効な DNS 名でなければなりません。ホスト名にアンダースコアなどの他の文字が含まれていると、DNS が正常に機能しなくなります。
さらに、ホスト名がすべて小文字である必要があります。大文字は使用できません。
|
-n domain_name | IdM ドメインに使用する LDAP サーバードメインの名前。これは、通常 IdM サーバーのホスト名に基づいています。 |
-p directory_manager_password | スーパーユーザーのパスワード (LDAP サービスの cn=Directory Manager) |
-P kerberos_master_password | KDC 管理者のパスワード。値が指定されていない場合に無作為に生成されます。 |
-r realm_name | IdM ドメイン用に作成する Kerberos のレルム名。 |
--subject=subject_DN | 発行した証明書のサブジェクト DN にベース要素を設定します。デフォルト設定は O=realm です。 |
--forwarder=forwarder | DNS サービスで使用する DNS フォワーダーを指定します。複数のフォワーダーを指定するには、このオプションを複数回使用します。 |
--no-forwarders | フォワーダーではなく DNS サービスを使用するルートサーバーを使用します。 |
--no-reverse | DNS ドメインの設定時に、逆引き DNS ゾーンが作成 されないようにします 。(すでに逆引き DNS ゾーンが設定されている場合は、既存の逆引き DNS ゾーンが使用されます。) このオプションを使用しない場合には、デフォルト値は true になるので、インストールスクリプトで逆引き DNS を設定することを前提としています。 |
--setup-dns | IdM ドメイン内に DNS サービスを設定するように、インストールスクリプトに指示します。統合 DNS サービスの使用は任意であるため、インストールスクリプトでこのオプションが指定されていない場合には、DNS は設定されません。 |
--idmax=number | IdM サーバーで割り当て可能な ID の最大値を設定します。デフォルト値は ID 開始値 + 199999 です。 |
--idstart=number | IdM サーバーで割り当て可能な ID の最小値 (開始値) を設定します。デフォルト値は無作為に選択されます。 |
--ip-address | サーバーの IP アドレスを指定します。このオプションは ipa-server-install に追加すると、ローカルインターフェースに関連付けられた IP アドレスだけを許可します。 |
3.3. 例: 対話的および無人でのスクリプトの実行
3.3.1. 基本的な対話インストール
- ipa-server-install スクリプトを実行します。
[root@server ~]# ipa-server-install
- ホスト名を入力します。ホスト名は逆引き DNS を使用して自動的に決定されます。
Server host name [ipaserver.example.com]:
- ドメイン名を入力します。ドメイン名は、ホスト名に基づいて自動的に決定されます。
Please confirm the domain name [example.com]:
- 新しい Kerberos レルム名を入力します。Kerberos レルム名は、通常ドメイン名に基づいています。
Please provide a realm name [EXAMPLE.COM]:
- Directory Server のスーパーユーザー (cn=Directory Manager) のパスワードを入力します。このパスワードには、強度の要件があります。たとえば、パスワードの最小長は 8 文字となっています。
Directory Manager password: Password (confirm):
- IdM システムユーザーアカウント (admin) のパスワードを入力します。このユーザーはマシン上に作成されます。
IPA admin password: Password (confirm):
- 次に、スクリプトにより、ホスト名、IP アドレス、およびドメイン名がもう一度出力されます。情報が正しいことを確認します。
The IPA Master Server will be configured with Hostname: ipaserver.example.com IP address: 192.168.1.1 Domain name: example.com Realm name: EXAMPLE.COM Continue to configure the system with these values? [no]: yes
- その後、スクリプトで、IdM に関連付けられたサービスをすべて設定します。その際、タスク数と進捗バーが表示されます。
Configuring NTP daemon (ntpd) [1/4]: stopping ntpd ... Done configuring NTP daemon (ntpd). Configuring directory server (dirsrv): Estimated time 1 minute [1/38]: creating directory server user .... Configuring certificate server (pki-tomcatd): Estimated time 3 minutes 30 seconds [1/20]: creating certificate server user ... Done configuring certificate server (pki-tomcatd). Configuring Kerberos KDC (krb5kdc): Estimated time 30 seconds [1/10]: adding sasl mappings to the directory ... Done configuring Kerberos KDC (krb5kdc). Configuring kadmin [1/2]: starting kadmin [2/2]: configuring kadmin to start on boot Done configuring kadmin. Configuring ipa_memcached [1/2]: starting ipa_memcached [2/2]: configuring ipa_memcached to start on boot Done configuring ipa_memcached. Configuring ipa-otpd [1/2]: starting ipa-otpd [2/2]: configuring ipa-otpd to start on boot Done configuring ipa-otpd. Configuring the web interface (httpd): Estimated time 1 minute [1/15]: disabling mod_ssl in httpd ... Done configuring the web interface (httpd). Applying LDAP updates Restarting the directory server Restarting the KDC Sample zone file for bind has been created in /tmp/sample.zone.pUfcGp.db Restarting the web server Setup complete
SSH
サービスを再起動して、Kerberos プリンシパルを取得し、ネームサーバースイッチ (NSS) 設定ファイルを更新します。[root@server ~]# service sshd restart
- admin ユーザーの認証情報を使用して Kerberos レルムに認証を行い、ユーザーが適切に設定され、Kerberos レルムにアクセスできることを確認します。
[root@server ~]# kinit admin Password for admin@EXAMPLE.COM:
- ipa user-find のようなコマンドを実行して IdM 設定をテストします。たとえば、以下のようになります。
[root@server ~]# ipa user-find admin -------------- 1 user matched -------------- User login: admin Last name: Administrator Home directory: /home/admin Login shell: /bin/bash UID: 939000000 GID: 939000000 Account disabled: False Password: True Kerberos keys available: True ---------------------------- Number of entries returned 1 ----------------------------
3.3.2. 無人 (非対話型) インストール
- IdM 管理ユーザーおよび Directory Server のスーパーユーザー (Directory Manager) のパスワード
- サーバーのホスト名
- Kerberos レルム名
- DNS ドメイン名
-U
を指定して上記の情報を渡すことで、ユーザーの操作を必要とせずに強制的に実行できるようになります。
例3.1 非対話式の基本的なインストール
[root@server ~]# ipa-server-install -a secret12 --hostname=ipaserver.example.com -r EXAMPLE.COM -p secret12 -n example.com -U
To accept the default shown in brackets, press the Enter key. The IPA Master Server will be configured with Hostname: ipaserver.example.com IP address: 192.168.1.1 Domain name: example.com
3.4. 例: 異なる CA 設定を使用したインストール
- Dogtag Certificate System は、独自 の証明書に署名できます。つまり、Dogtag Certificate System インスタンスは ルート CA であることを意味します。ルート CA より上位の CA はないので、ルート CA cna で独自の証明書ポリシーを設定できます。これがデフォルト設定になります。
- Dogtag Certificate System CA は、外部でホストされる CA (例: Verisign) で署名できます。この場合には、外部 CA がルート CA になり、設定された Dogtag Certificate System CA はルート CA の 下位 の証明局になります。つまり、IdM ドメイン内で発行された証明書は、有効期間などの属性に関してルート CA によって設定された制限が適用される可能性があります。外部 CA を参照する場合も、引き続き Dogtag Certificate System インスタンスを使用してすべての IdM ドメイン証明書証明書を発行します。唯一の相違点は、初期のドメイン CA 証明書が別の CA によって発行される点です。
3.4.1. 内部ルート CA を使用したインストール
[root@server ~]# ipa-server-install ... &< ... The IPA Master Server will be configured with: Hostname: server.example.com IP address: 10.1.1.1 Domain name: example.com Realm name: EXAMPLE.COM Continue to configure the system with these values? [no]: yes The following operations may take some minutes to complete. Please wait until the prompt is returned. ... &< ... Configuring directory server for the CA (pkids): Estimated time 30 seconds [1/3]: creating directory server user [2/3]: creating directory server instance [3/3]: restarting directory server Done configuring directory server for the CA (pkids). Configuring certificate server (pki-cad): Estimated time 3 minutes 30 seconds [1/21]: creating certificate server user ... Done configuring certificate server (pki-cad). ... &< ...
3.4.2. 外部 CA を使用したインストール
Basic Constraint
オプションを CA=TRUE
に設定するか、証明書に署名できるように、署名証明書に鍵用途エクステンションを設定する必要があります。
例3.2 外部 CA の使用
--external-ca
オプションを使用して ipa-server-install スクリプトを実行します。[root@server ~]# ipa-server-install -a secret12 -r EXAMPLE.COM -P password -p secret12 -n ipaserver.example.com --external-ca
- このスクリプトは、通常通りに NTP サービスおよび Directory Server サービスを設定し、
- CA の設定を完了して証明書署名要求 (CSR) が置かれている場所 (
/root/ipa.csr
) に関する情報を返します。この要求は外部 CA に送信する必要があります。Configuring certificate server: Estimated time 6 minutes [1/4]: creating certificate server user [2/4]: creating pki-ca instance [3/4]: restarting certificate server [4/4]: configuring certificate server instance The next step is to get /root/ipa.csr signed by your CA and re-run ipa-server-install.
- CA に要求を送信します。このプロセスは、サービスごとに異なります。証明書の適切な拡張を要求する必要がある場合があります。Identity Management サーバー用に生成された CA 署名証明書は、有効な CA 証明書である必要があります。これには、基本制約を CA=true に設定するか、証明書に署名できるように、署名証明書に鍵用途エクステンションを設定する必要があります。
- 発行した証明書と、発行元 CA の CA 証明書チェーンを取得します。プロセスは証明書サービスによって異なりますが、通常はWeb ページか通知メールにダウンロードリンクがあり、管理者は、必要な証明書すべてをダウンロードできます。CA 証明書のみではなく、CA 用の完全な証明書チェーンを取得してください。
- 証明書および CA チェーンファイルの場所と名前を指定して ipa-server-install をもう一度実行します。たとえば、以下のようになります。
[root@server ~]# ipa-server-install --external_cert_file=/tmp/servercert20110601.p12 --external_ca_file=/tmp/cacert.p12
- 「基本的な対話インストール」にあるように、設定プロセスを完了し、すべてが想定通りに機能していることを確認します。
3.4.3. CA なしでのインストール
- LDAP サーバー証明書
- Apache サーバー証明書
- LDAP サーバー証明書
- 証明書の追跡に certmonger が使用されないので、有効期限の警告はありません。
- Identity Management で証明書を更新する方法はありません。
- 証明書管理ツール (ipa cert-*) は、証明書の表示や管理には使用できません。
- ホスト証明書とサービス証明書はすべて、手動で要求、生成、アップロードする必要があります。これは、ipa host-add などのホスト管理ツールが機能する仕組みにも影響します。
- 証明書がエントリーから削除されても、自動的に取り消されません。
例3.3 CA を使用しない Identity Management のインストール
- LDAP サーバー証明書
- --dirsrv_pkcs12 (LDAP サーバー証明書の PKCS#12 証明書ファイルを指定)
- --dirsrv_pin (PKCS#12 ファイルにアクセスするパスワードを指定)
- Apache サーバーの証明書
- --http_pkcs12 (Apache サーバー証明書の PKCS#12 証明書ファイルを指定)
- --http_pin (PKCS#12 ファイルにアクセスするパスワードを指定)
- ルート CA 証明書 (Apache および LDAP サーバーの証明書をドメイン全体で信頼できるようにする)
[root@server ~]# ipa-server-install --http_pkcs12 /tmp-http-server.p12 --http_pin secret1 --dirsrv_pkcs12 /tmp/ldap-server.p12 --dirsrv_pin secret2 ...
3.5. 例: IdM ドメイン内での DNS サービスの設定
--setup-dns
オプションが必要です。
3.5.1. DNS に関する注意事項
- DNS 名の設定時にはワイルドカードを使用できません。明示的な DNS ドメイン名のみがサポートされます。
--setup-dns
オプションを指定しても、rndc サービスは設定されません。このサービスは、IdM サーバーの設定後に手動で設定する必要があります。
3.5.2. 統合 DNS を使用したインストール
例3.4 対話型の DNS 設定
--setup-dns
オプションを使用して ipa-server-install スクリプトを実行します。[root@server ~]# ipa-server-install -a secret12 -r EXAMPLE.COM -P password -p secret12 -n ipaserver.example.com --setup-dns
- スクリプトを使用すると通常通りにホスト名およびドメイン名を設定します。
- 次にスクリプトにより、DNS フォワーダー設定のプロンプトが表示されます。フォワーダーを使用する場合は、yes と入力して DNS サーバーの一覧を指定します。IdM で独自の DNS サービスを管理する場合は、no と入力します。
Do you want to configure DNS forwarders? [yes]: no No DNS forwarders configured
- このスクリプトは、NTP、Directory Server、Certificate System、Kerberos、および Apache のサービスを設定します。
- 設定の完了前に、逆引き DNS サービスを設定するかどうかをスクリプトによりプロンプトが表示されます。yes を選択した場合は、
named
サービスが設定されます。Do you want to configure the reverse zone? [yes]: yes Configuring DNS (named) [1/11]: adding DNS container [2/11]: setting up our zone [3/11]: setting up reverse zone [4/11]: setting up our own record [5/11]: setting up records for other masters [6/11]: setting up CA record [7/11]: setting up kerberos principal [8/11]: setting up named.conf [9/11]: restarting named [10/11]: configuring named to start on boot [11/11]: changing resolv.conf to point to ourselves Done configuring DNS (named). ============================================================================== Setup complete
- ipa-dns-install コマンド (
--setup-dns
オプションの指定時にインストールスクリプトで実行) では、システムの rndc サービスは自動的に設定されません。このサービスは、DNS を IdM に設定した後に手動で設定する必要があります。- rndc 設定ファイルとキーを作成します。
[root@server ~]# /usr/sbin/rndc-confgen -a [root@server ~]# /sbin/restorecon /etc/rndc.key
これには、キーの作成時にユーザーが入力してエントロピーを作成する必要がある場合があります。 - rndc キーファイルの所有者と権限を変更します。
[root@server ~]# chown root:named /etc/rndc.key [root@server ~]# chmod 0640 /etc/rndc.key
- 「基本的な対話インストール」にあるように、すべてが想定通りに機能していることを確認します。
--forwarder
または --no-forwarders
オプションおよび --no-reverse
オプションを使用してこの情報を渡すことができます。
例3.5 非対話的な DNS の設定
--setup-dns
オプションを使用します。追加のフォワーダーを設定するには、--forwarder
オプションを使用します。複数のフォワーダーを指定する場合には、複数の --forwarder
の呼び出しを使用します。
[root@server ~]# ipa-server-install ... --setup-dns --forwarder=1.2.3.0 --forwarder=1.2.255.0
--no-forwarders
オプションを使用してルートサーバーのみを使用することを指定します。
--no-reverse
オプションを使用します。逆引き DNS ゾーンがすでに設定されている場合は、この --no-reverse
オプションを使用すると既存の逆引き DNS ゾーンが使用されます。
[root@server ~]# ipa-server-install ... --setup-dns --no-reverse
--setup-dns
オプションの指定時にインストールスクリプトで実行) では、システムの rndc サービスは自動的に設定されません。このサービスは、DNS を IdM に設定した後に手動で設定する必要があります。
- rndc 設定ファイルとキーを作成します。
[root@server ~]# /usr/sbin/rndc-confgen -a [root@server ~]# /sbin/restorecon /etc/rndc.key
これには、キーの作成時にユーザーが入力してエントロピーを作成する必要がある場合があります。 - rndc キーファイルの所有者と権限を変更します。
[root@server ~]# chown root:named /etc/rndc.key [root@server ~]# chmod 0640 /etc/rndc.key
第4章 IdM レプリカの設定
4.1. サーバー/レプリカトポロジーの計画
- サーバー。ドメインの所属メンバーが使用する全サービスを管理します。
- レプリカ。レプリカは基本的にはサーバーの複製です (一旦複製されるとサーバーと全く同じです)。
- クライアント。サーバーに設定した Kerberos ドメインに属し、サーバーが発行する証明書およびチケットを受け取り、その他の一元管理サービスを使用して認証および認可を行います。
図4.1 サーバーとレプリカの合意
- 1 つのサーバー/レプリカには、4 つ以上のレプリカ合意を設定できません。
- 1 つの Identity Management ドメインには 20 台以上のサーバーとレプリカを使用すべきではありません。
- すべてのサーバー/レプリカには、別のサーバーに障害が発生した場合に、孤立したサーバーまたはレプリカがないようにするため、最低でも 2 つのレプリカ合意が必要です。
図4.2 トポロジーの例
- 各メインオフィス、データセンター、地域に、少なくとも 1 つの IdM サーバーを用意します。可能であれは、2 台の IdM サーバーを用意します。
- 各データセンターに用意するサーバーは 4 台までとします。
- サーバーやレプリカを使用する代わりに、小規模なオフィスでは、SSSD を使用して認証情報をキャッシュし、データのバックエンドとして、オフサイトの IdM サーバーを使用します。
4.2. レプリカサーバーのインストールの前提条件
- そのマシンが「2章インストールの前提条件」に記載の前提条件すべてを満たすようにしてください。
- レプリカとマスターサーバーは、同じバージョンの IdM を実行している必要があります。レプリカは基本的に、既存のサーバー設定を基にしたサーバーの複製です。そのため、サーバーとレプリカ (サーバーの複製) は、設定をサーバーからレプリカに適切にコピーできるように、同じバージョンの Identity Management を実行している必要があります。マスターサーバーが Red Hat Enterprise Linux 6 で IdM バージョン 3.0 を稼働している場合は、レプリカも Red Hat Enterprise Linux 6 で稼働し、IdM 3.0 パッケージを使用する必要があります。重要マスターと違うバージョンを使用するレプリカの作成は サポート対象外です。389 Directory Server インスタンスの設定時に、別のバージョンを使用するレプリカを作成しようとすると失敗します。
- レプリカをインストールするには、レプリカの設定プロセス時に 表2.1「IdM ポート」に記載されているポートに加え、
ポート 22
も解放する必要があります。このポートは、マスターサーバーへの接続に SSH を使用するのに必要です。既存の Dogtag Certificate System または Red Hat Certificate System インスタンスがレプリカマシンに存在する場合には、レプリカの設定中および設定後にポート 7389
を解放しておく必要があります。このポートは、マスター IdM サーバーがレプリカと通信するのに使用されます。注記ipa-replica-install
スクリプトには、必要なポートのステータスを検証するipa-replica-conncheck
ユーティリティーが含まれます。トラブルシューティングの目的で、ipa-replica-conncheck
を個別に実行することもできます。ユーティリティーの使用方法は、ipa-replica-conncheck(1) の man ページを参照してください。 - レプリカはサーバーと同じ CA 設定を使用し、同じルート CA を指定する必要があります。たとえば、サーバーが (Dogtag Certificate System を使用した) 独自のルート CA である場合には、このサーバーはレプリカのルート CA である必要があります。サーバーが外部 CA を使用して証明書を発行した場合には、レプリカでも同じ外部 CA を使用する必要があります。
4.3. レプリカパッケージのインストール
ipa-server
) からインストールされます。レプリカが DNS サービスもホストする場合は、bind
および bind-dyndb-ldap
パッケージを含めます。
[root@server ~]# yum install ipa-server bind bind-dyndb-ldap
4.4. レプリカの作成
- マスターサーバーで、レプリカ情報ファイル を作成します。このファイルには、マスターサーバーから取得したレルムや設定情報が含まれており、情報はレプリカサーバーの設定に使用します。マスター IdM サーバー で
ipa-replica-prepare
ユーティリティーを実行します。このユーティリティーには、レプリカ マシンの完全修飾ドメイン名が必要です。--ip-address
オプションを使用すると、DNS へのレプリカの A および PTR レコードなど、レプリカの DNS エントリーが自動的に作成されます。重要IdM サーバーが統合 DNS で設定されている場合にのみ--ip-address
オプションを渡します。これ以外の場合にこのオプションを渡すと、更新する DNS レコードが存在しないため、DNS レコード操作が失敗して、レプリカ作成も失敗することになります。注記レプリカの IP アドレスに他のサーバーが到達できないと、ipa-replica-prepare
スクリプトは、その IP アドレスの確認や検証を実行しないことに注意してください。[root@server ~]# ipa-replica-prepare ipareplica.example.com --ip-address 192.168.1.2 Directory Manager (existing master) password: Preparing replica for ipareplica.example.com from ipaserver.example.com Creating SSL certificate for the Directory Server Creating SSL certificate for the dogtag Directory Server Saving dogtag Directory Server port Creating SSL certificate for the Web Server Exporting RA certificate Copying additional files Finalizing configuration Packaging replica information into /var/lib/ipa/replica-info-ipareplica.example.com.gpg Adding DNS records for ipareplica.example.com Using reverse zone 1.168.192.in-addr.arpa. The ipa-replica-prepare command was successful
これは、数字、アルファベット文字、およびハイフン (-) のみが使用された有効な DNS 名でなければなりません。ホスト名にアンダースコアなどの他の文字が含まれていると、DNS が正常に機能しなくなります。さらに、ホスト名がすべて小文字である必要があります。大文字は使用できません。各レプリカ情報ファイルは、GPG 暗号化ファイルとして/var/lib/ipa/
ディレクトリーに作成されます。各ファイルには、replica-info-ipareplica.example.com.gpg
など、レプリカサーバー向けの名前が付けられます。注記レプリカ情報ファイルを使用して、複数のレプリカを作成できません。このファイルを使用できるのは、対象として作成された特定のレプリカとマシンだけです。警告レプリカ情報ファイルには機密情報が含まれています。適切な措置を講じてこの情報を保護してください。ipa-replica-prepare の他のオプションは、ipa-replica-prepare(1) の man ページを参照してください。 - レプリカ情報ファイルは、レプリカサーバーにコピーします。
[root@server ~]# scp /var/lib/ipa/replica-info-ipareplica.example.com.gpg root@ipaserver:/var/lib/ipa/
- レプリカサーバーで、レプリカのインストールスクリプトを実行し、このレプリカ情報ファイルを参照します。サーバーのインストールスクリプトのように、DNS を設定する方法は他にもあります。さらに、レプリカの CA を設定するオプションがあります。CA はサーバー用にデフォルトでインストールされますが、レプリカでは任意です。DNS フォワーダーの情報が必要です。フォワーダーごとに
--forwarder
オプションを使用して、設定した DNS フォワーダーの一覧を指定するか、--no-forwarders
オプションを指定してフォワーダーの設定をスキップできます。たとえば、以下のようになります。[root@ipareplica ~]# ipa-replica-install --setup-ca --setup-dns --no-forwarders /var/lib/ipa/replica-info-ipareplica.example.com.gpg Directory Manager (existing master) password: Warning: Hostname (ipareplica.example.com) not found in DNS Run connection check to master Check connection from replica to remote master 'ipareplica. example.com': Directory Service: Unsecure port (389): OK Directory Service: Secure port (636): OK Kerberos KDC: TCP (88): OK Kerberos Kpasswd: TCP (464): OK HTTP Server: Unsecure port (80): OK HTTP Server: Secure port (443): OK The following list of ports use UDP protocol and would need to be checked manually: Kerberos KDC: UDP (88): SKIPPED Kerberos Kpasswd: UDP (464): SKIPPED Connection from replica to master is OK. Start listening on required ports for remote master check Get credentials to log in to remote master admin@EXAMPLE.COM password: Execute check on remote master admin@example.com's password: Check connection from master to remote replica 'ipareplica. example.com': Directory Service: Unsecure port (389): OK Directory Service: Secure port (636): OK Kerberos KDC: TCP (88): OK Kerberos KDC: UDP (88): OK Kerberos Kpasswd: TCP (464): OK Kerberos Kpasswd: UDP (464): OK HTTP Server: Unsecure port (80): OK HTTP Server: Secure port (443): OK Connection from master to replica is OK. Connection check OK
レプリカのインストールスクリプトは、テストを実行し、インストールされているレプリカファイルが現在のホスト名と一致することを確認します。一致しない場合には、このスクリプトで警告メッセージが表示され、確認するように求められます。これは、ホスト名が一致しなくても問題とならないマルチホームマシンで発生する可能性があります。レプリカのインストールスクリプトの他のオプションについては、ipa-replica-install(1) man ページに一覧表示されます。注記ipa-replica-install
で使用できるオプションの 1 つに--ip-address
オプションがあります。ipa-replica-install
に追加すると、このオプションは、ローカルインターフェースに関連付けられた IP アドレスだけを許可します。 - プロンプトが表示されたら、Directory Manager のパスワードを入力します。次に、スクリプトはレプリカ情報ファイルの情報に基づいて Directory Server インスタンスを設定し、複製プロセスを開始し、マスターサーバーからレプリカにデータをコピーします。このプロセスは、初期化 と呼ばれます。
- IdM クライアントが新しいサーバーを検出できるように、適切な DNS エントリーが作成されていることを確認します。必須のドメインサービスには、DNS エントリーが必要です。
- _ldap._tcp
- _kerberos._tcp
- _kerberos._udp
- _kerberos-master._tcp
- _kerberos-master._udp
- _ntp._udp
DNS が有効な状態で最初のサーバーを作成した場合には、適切な DNS エントリーでレプリカが作成されます。以下に例を示します。[root@ipareplica ~]# DOMAIN=example.com [root@ipareplica ~]# NAMESERVER=ipareplica [root@ipareplica ~]# for i in _ldap._tcp _kerberos._tcp _kerberos._udp _kerberos-master._tcp _kerberos-master._udp _ntp._udp; do echo ""; dig @${NAMESERVER} ${i}.${DOMAIN} srv +nocmd +noquestion +nocomments +nostats +noaa +noadditional +noauthority; done | egrep -v "^;" | egrep _ _ldap._tcp.example.com. 86400 IN SRV 0 100 389 ipaserver1.example.com. _ldap._tcp.example.com. 86400 IN SRV 0 100 389 ipaserver2.example.com. _kerberos._tcp.example.com. 86400 IN SRV 0 100 88 ipaserver1.example.com. ...8<...
DNS を有効にせずに最初の IdM サーバーを作成した場合には、サービスの TCP および UDP エントリー両方など、各 DNS エントリーは手作業で追加してください。以下に例を示します。[root@ipareplica ~]# kinit admin [root@ipareplica ~]# ipa dnsrecord-add example.com _ldap._tcp --srv-rec="0 100 389 ipareplica.example.com."
- 任意。レプリカの DNS サービスを設定します。マスターサーバーが DNS を使用している場合でも、レプリカの DNS サービスは、設定スクリプトでは設定されません。ipa-dns-install コマンドを使用して手動で DNS をインストールし、ipa dnsrecord-add コマンドで必要な DNS レコードを追加します。たとえば、以下のようになります。
[root@ipareplica ~]# ipa-dns-install [root@ipareplica ~]# ipa dnsrecord-add example.com @ --ns-rec ipareplica.example.com.
重要最後のピリオド (.) を含めてレプリカの完全修飾ドメイン名を使用します。このピリオドを含めない場合には、BIND はホスト名をドメインの相対値として扱います。
4.5. 他のレプリカ作成オプション
4.5.1. 各種 DNS 設定
[root@server ~]# ipa-replica-prepare ipareplica.example.com --ip-address=192.68.0.0 --no-reverse
--setup-dns
オプションを使用して、正引きゾーンと逆引きゾーンを設定します。たとえば、フォワーダーなしで、既存の逆引きゾーンを使用して、レプリカの DNS サービスを設定するには以下を行います。
[root@server ~]# ipa-replica-install ipareplica.example.com --setup-dns --no-forwarders --no-reverse --no-host-dns ...
4.5.2. 各種 CA 設定
--setup-ca
オプションを使用します。残りの設定は、サーバーの設定から取得します。
[root@ipareplica ~]# ipa-replica-install ipareplica.example.com --setup-ca ...
[root@ipareplica ~]# ipa-replica-install ipareplica.example.com --dirsrv_pkcs12=/tmp/dirsrv-cert.p12 --dirsrv_pin=secret1 --http_pkcs12=/tmp/http-cert.p12 --http_pin=secret2 ...
4.5.3. さまざまなサービス
[root@server ~]# ipa-replica-install ... --no-ntp --no-ssh --no-sshd ...
第5章 IdM クライアントとしてのシステムの設定
5.1. クライアント設定
- IdM CA の CA 証明書を取得します。
- 別の Kerberos 設定を作成して、指定した認証情報をテストします。この設定により、IdM クライアントを IdM ドメインに参加させるのに必要な IdM XML-RPC サーバーへの Kerberos 接続が可能になります。この Kerberos 設定は最終的に破棄されます。Kerberos 設定では、レルムおよびドメイン情報、デフォルトのチケット属性を指定します。デフォルトでは、オペレーティングシステムから管理インターフェースへの接続を容易に行い、管理操作の監査ができるように転送可能なチケットが設定されています。たとえば、Red Hat Enterprise Linux システムの Kerberos 設定は以下のようになります。
[libdefaults] default_realm = EXAMPLE.COM dns_lookup_realm = false dns_lookup_kdc = false rdns = false forwardable = yes ticket_lifetime = 24h [realms] EXAMPLE.COM = { kdc = server.example.com:88 admin_server = server.example.com:749 } [domain_realm] .example.com = EXAMPLE.COM example.com = EXAMPLE.COM
- ipa-join コマンドを実行し、実際の参加させます。
- ホストサービスのサービスプリンシパルを取得して、
/etc/krb5.keytab
にインストールします。例:host/ipa.example.com@EXAMPLE.COM
- certmonger を有効にし、SSL サーバー証明書を取得し、
/etc/pki/nssdb
に証明書をインストールします。 - nscd デーモンを無効にします。
- NSS および PAM 設定ファイルなど、SSSD または LDAP/KRB5 を設定します。
- OpenSSH サーバーおよびクライアントを設定し、ホストが DNS SSHFP レコードを作成できるようにします。
- NTP の設定
5.2. システムポート
5.3. IdM クライアントとしての Linux システムの設定
- Kerberos ID (管理ユーザー) を利用できるようにするか、クライアントマシンの登録プロセスを開始する前に、ワンタイムパスワードを使用してクライアントマシンをサーバーのクライアントマシンに手動で追加し、クライアントマシンを Kerberos ドメインに接続する手段を設定する必要があります。
- DNS レコードにサービスを提供するネットワーク上に Active Directory サーバーがある場合には、Active Directory の DNS レコードが原因で、クライアントによる IdM サーバーアドレスの自動検出ができなくなる可能性があります。ipa-client-install スクリプトでは、IdM に追加されたレコードの代わりに Active Directory の DNS レコードを取得します。この場合は、IdM サーバーアドレスを ipa-client-install スクリプトに直接指定する必要があります。
5.3.1. クライアントのインストール (完全な例)
- クライアントパッケージをインストールします。このパッケージは、システムをクライアントとして簡単に設定でき、SSSD のインストールや設定も行います。通常のユーザーシステムの場合には、
ipa-client
パッケージのみが必要です。[root@client ~]# yum install ipa-client
管理者マシンには、ipa-admintools
パッケージも必要です。[root@client ~]# yum install ipa-client ipa-admintools
- IdM サーバーを DNS サーバーとして設定し、クライアントと同じドメインに配置した場合には、クライアントの
/etc/resolv.conf
ファイルにあるネームサーバー一覧の最初のエントリーとして、サーバーの IP アドレスを追加します。ヒントドメイン内のマシンがすべて IdM クライアントである場合は、IdM サーバーのアドレスを DHCP 設定に追加します。 - クライアントの設定コマンドを実行します。
[root@client ~]# ipa-client-install --enable-dns-updates
--enable-dns-updates
オプションを使用すると、クライアントマシンの IP アドレスに DNS が更新されます。このオプションは、IdM サーバーが統合 DNS でインストールされている場合か、ネットワーク上の DNS サーバーで GSS-TSIG プロトコルを使用して DNS エントリーを更新できる場合にのみ、使用するようにしてください。ipa-client-install のオプションは、ipa-client-install の man ページに一覧表示されています。 - プロンプトが表示されたら、IdM DNS ドメインのドメイン名を入力します。
DNS discovery failed to determine your DNS domain Please provide the domain name of your IPA server (ex: example.com): example.com
- プロンプトが表示されたら、IdM サーバーの完全修飾ドメイン名を入力します。または、クライアントのインストールスクリプトに
--server
オプションを使用して、IdM サーバーの完全修飾ドメイン名を指定します。DNS discovery failed to find the IPA Server Please provide your IPA server name (ex: ipa.example.com): server.example.com
重要これは、数字、アルファベット文字、およびハイフン (-) のみが使用された有効な DNS 名でなければなりません。ホスト名にアンダースコアなどの他の文字が含まれていると、DNS が正常に機能しなくなります。 - 次にクライアントのスクリプトは、Kerberos ID を入力するようにプロンプトを表示し、その ID を使用して問い合わせを行い、Kerberos レルムに参加します。これらの認証情報を指定すると、クライアントは IdM Kerberos ドメインに参加して設定を完了できます。
Continue to configure the system with these values? [no]: y User authorized to enroll computers: admin Synchronizing time with KDC... Password for admin@EXAMPLE.COM: Successfully retrieved CA cert Subject: CN=Certificate Authority,O=EXAMPLE.COM Issuer: CN=Certificate Authority,O=EXAMPLE.COM Valid From: Tue Aug 13 09:29:07 2013 UTC Valid Until: Sat Aug 13 09:29:07 2033 UTC Enrolled in IPA realm EXAMPLE.COM Created /etc/ipa/default.conf New SSSD config will be created Configured /etc/sssd/sssd.conf Configured /etc/krb5.conf for IPA realm EXAMPLE.COM Failed to update DNS records. Adding SSH public key from /etc/ssh/ssh_host_rsa_key.pub Adding SSH public key from /etc/ssh/ssh_host_dsa_key.pub Could not update DNS SSHFP records. SSSD enabled Configured /etc/openldap/ldap.conf NTP enabled Configured /etc/ssh/ssh_config Configured /etc/ssh/sshd_config Client configuration complete.
- クライアントが IdM ドメインに正常に接続でき、基本的なタスクを実行できることをテストします。たとえば、IdM ツールを使用して、ユーザーおよびグループ情報を取得できることを確認します。
[jsmith@client ~]$ id [jsmith@client ~]$ getent passwd admin [jsmith@client ~]$ getent group admins
- NFS サーバーがすでに設定されている場合は、クライアントシステムに NFS を設定して Kerberos と連携させます。NFS サーバーは、ドメイン内に設定しておく必要があります。詳細は、「自動マウントの設定」を参照してください。ヒントNFS の設定時に発生する可能性のあるエラーをトラブルシューティングできるように、
/etc/sysconfig/nfs
ファイルでデバッグ情報を有効にします。RPCGSSDARGS="-vvv" RPCSVCGSSDARGS="-vvv"
- IdM サーバーで、NFS クライアントの NFS サービスプリンシパルを追加します。
[root@client ~]# kinit admin [root@client ~]# ipa service-add nfs/ipaclient.example.com@EXAMPLE
注記これは、ipa コマンドを使用できるように、ipa-admintools パッケージがインストールされているマシンから実行する必要があります。 - IdM サーバーで、NFS サービスプリンシパルの keytab を取得します。
[root@client ~]# ipa-getkeytab -s server.example.com -p nfs/ipaclient.example.com@EXAMPLE -k /tmp/krb5.keytab
- IdM サーバーから IdM クライアントに keytab をコピーします。たとえば、以下のようになります。
[root@client ~]# scp /tmp/krb5.keytab root@client.example.com:/etc/krb5.keytab
- NFS サーバーで
/etc/exports
ファイルを設定します。/ipashare gss/krb5p(rw,no_root_squash,subtree_check,fsid=0)
- マウントポイントを作成します。
[root@client ~]# mkdir /mnt/ipashare
- クライアントで NFS 共有をマウントします。
-o sec
設定は、NFS サーバーの/etc/exports
ファイルで使用する設定と同じものを使用します。[root@client ~]# mount -v -t nfs4 -o sec=krb5p nfs.example.com:/ /mnt/ipashare
5.3.2. その他のクライアントインストールオプションの例
例5.1 DNS 更新の有効化
--enable-dns-updates
オプションでは、クライアントの IP アドレスが変更されるたびに DNS エントリーを更新する System Security Services Daemon (SSSD) を設定します。
[root@client ~]# ipa-client-install --enable-dns-updates
例5.2 ドメイン情報の指定
--domain
: DNS ドメイン名 (DNS サービスをホストするように IdM サーバーが設定されている場合のみ)--server
: 登録する IdM サーバー (トポロジー内の任意のサーバーまたはレプリカ)これは、数字、アルファベット文字、およびハイフン (-) のみが使用された有効な DNS 名でなければなりません。ホスト名にアンダースコアなどの他の文字が含まれていると、DNS が正常に機能しなくなります。--realm
: Kerbero レルム名。オプションで Kerberos プリンシパル名には-p
を使用します。
[root@client ~]# ipa-client-install --domain EXAMPLE.COM --server server.example.com --realm EXAMPLE -p host/server.example.com
例5.3 特定の IdM サーバーの設定
--fixed-primary
オプションで設定します。
[root@client ~]# ipa-client-install --fixed-primary server.example.com
例5.4 システム認証ツールの無効化
--noac
オプションは、authconfig での変更を防ぎます。--no-sssd
オプションでは、IdM が SSSD を使用できないようにします。
[root@client ~]# ipa-client-install --noac --no-sssd
--preserve-sssd
があります。このオプションでは、クライアントが SSSD 設定ファイルを変更して IdM ドメインを設定できますが、以前の SSSD 設定を保存します。
例5.5 パスワードキャッシングの無効化
--no-krb5-offline-passwords
オプションを使用して、パスワードが SSSD でキャッシュできないようにします。
[root@client ~]# ipa-client-install --no-krb5-offline-passwords
5.4. Linux クライアントの手動設定
5.4.1. IdM クライアントの設定 (全手順)
- SSSD がインストールされていない場合はインストールしてください。
- 任意。ホストから管理タスクを実行できるように IdM ツールをインストールします。
[root@client ~]# yum install ipa-admintools
- IdM サーバーで、クライアントのホストエントリーを作成します。
[jsmith@client ~]$ kinit admin [jsmith@client ~]$ ipa host-add --force --ip-address=192.168.166.31 ipaclient.example.com
ホストを手動で作成する方法は、「ホストエントリーを追加する他の例」を参照してください。 - IdM サーバーで、クライアントの Keytab を作成します。
- IdM 管理者としてログインします。
[jsmith@client ~]$ kinit admin
- サーバーが管理するクライアントホストを設定します。
[jsmith@client ~]$ ipa host-add-managedby --hosts=server.example.com ipaclient.example.com
- クライアントの keytab を生成します。
[jsmith@client ~]$ ipa-getkeytab -s server.example.com -p host/ipaclient.example.com -k /tmp/ipaclient.keytab
- Keytab をクライアントマシンにコピーし、名前を
/etc/krb5.keytab
に変更します。ヒント既存の/etc/krb5.keytab
を保存する必要がある場合には、ktutil を使用してこの 2 つのファイルを統合できます。 /etc/krb5.keytab
ファイルのユーザーパーミッションを正しく設定します。[root@client ~]# chown root:root /etc/krb5.keytab [root@client ~]# chmod 0600 /etc/krb5.keytab
/etc/krb5.keytab
ファイルの SELinux コンテキストを設定します。[root@client ~]# chcon system_u:object_r:krb5_keytab_t:s0 /etc/krb5.keytab
/etc/sssd/sssd.conf
ファイルを編集して、SSSD が IdM ドメインを参照するように設定します。[root@client ~]# touch /etc/sssd/sssd.conf [root@client ~]# vim /etc/sssd/sssd.conf [sssd] config_file_version = 2 services = nss, pam domains = example.com [nss] [pam] [domain/example.com] cache_credentials = True krb5_store_password_if_offline = True ipa_domain = example.com id_provider = ipa auth_provider = ipa access_provider = ipa ipa_hostname = ipaclient.example.com chpass_provider = ipa ipa_server = server.example.com ldap_tls_cacert = /etc/ipa/ca.crt
- パスワード、グループ、ユーザー、および netgroups に SSSD を使用するように NSS を設定します。
[root@client ~]# vim /etc/nsswitch.conf ... passwd: files sss shadow: files sss group: files sss ... netgroup: files sss ...
/etc/krb5.conf
ファイルで、IdM KDC を参照するように設定します。[logging] default = FILE:/var/log/krb5libs.log kdc = FILE:/var/log/krb5kdc.log admin_server = FILE:/var/log/kadmind.log [libdefaults] default_realm = EXAMPLE.COM dns_lookup_realm = false dns_lookup_kdc = false rdns = false ticket_lifetime = 24h forwardable = yes allow_weak_crypto = true [realms] EXAMPLE.COM = { kdc = server.example.com:88 admin_server = server.example.com:749 default_domain = example.com } [domain_realm] .example.com = EXAMPLE.COM example.com = EXAMPLE.COM
pam_sss.so
モジュールを使用するように、/etc/pam.d
設定を更新します。/etc/pam.d/fingerprint-auth
の場合:... account [default=bad success=ok user_unknown=ignore] pam_sss.so ... session optional pam_sss.so
/etc/pam.d/system-auth
の場合:... auth sufficient pam_sss.so use_first_pass ... account [default=bad success=ok user_unknown=ignore] pam_sss.so ... password sufficient pam_sss.so use_authtok ... session optional pam_sss.so
/etc/pam.d/password-auth
の場合:... auth sufficient pam_sss.so use_first_pass ... account [default=bad success=ok user_unknown=ignore] pam_sss.so ... password sufficient pam_sss.so use_authtok ... session optional pam_sss.so
- Enrollment_with_Separation_of_Duties
/etc/pam.d/smartcard-auth
の場合:... account [default=bad success=ok user_unknown=ignore] pam_sss.so ... session optional pam_sss.so
- IdM サーバーの CA 証明書をインストールします。
- サーバーから証明書を取得します。
[root@ipaclient ~]# wget -O /etc/ipa/ca.crt http://ipa.example.com/ipa/config/ca.crt
- システムの NSS データベースに証明書をインストールします。
[root@ipaclient ~]# certutil -A -d /etc/pki/nssdb -n "IPA CA" -t CT,C,C -a -i /etc/ipa/ca.crt
- IdM にホストのホスト証明書を設定します。
- certmonger が実行されていることを確認します。
[root@ipaclient ~]# service certmonger start
ヒントcertmonger サービスがデフォルトで起動するように、chkconfig を設定します。[root@ipaclient ~]# chkconfig certmonger on
[root@ipaclient ~]# ipa-getcert request -d /etc/pki/nssdb -n Server-Cert -K HOST/ipaclient.example.com -N 'CN=ipaclient.example.com,O=EXAMPLE.COM'
クライアントに管理ツールがインストールされていない場合は、IdM サーバーで証明書を生成し、ホストにコピーして、certutil を使用してインストールできます。 - Kerberos と連携するように NFS を設定します。ヒントNFS の設定時に発生する可能性のあるエラーをトラブルシューティングできるように、
/etc/sysconfig/nfs
ファイルでデバッグ情報を有効にします。RPCGSSDARGS="-vvv" RPCSVCGSSDARGS="-vvv"
- IdM サーバーで、NFS クライアントの NFS サービスプリンシパルを追加します。
[root@ipaclient ~]# ipa service-add nfs/ipaclient.example.com@EXAMPLE
注記これは、ipa コマンドを使用できるように、ipa-admintools パッケージがインストールされているマシンから実行する必要があります。 - IdM サーバーで、NFS サービスプリンシパルの keytab を取得します。
[root@ipaclient ~]# ipa-getkeytab -s server.example.com -p nfs/ipaclient.example.com@EXAMPLE -k /tmp/krb5.keytab
注記Linux の NFS 実装バージョンによっては、暗号化タイプのサポートが限定されます。Red Hat Enterprise Linux 6 よりも前のバージョンで NFS サーバーをホストしている場合は、サーバーおよびすべてのクライアントの両方で、任意の nfs/<FQDN> サービスキータブをサーバーと全クライアント両方で設定するように、-e des-cbc-crc
オプションを指定して ipa-getkeytab コマンドを実行します。これにより、KDC で DES キーのみが生成されるように指示します。DES キーを使用する場合、この暗号化タイプに依存するクライアントおよびサーバーではすべて、/etc/krb5.conf
ファイルの [libdefaults] セクションでallow_weak_crypto
オプションを有効にする必要があります。これらの設定変更を行わない場合には、NFS クライアントとサーバーは相互に認証できず、NFS ファイルシステムのマウントに失敗する可能性があります。クライアントの rpc.gssd とサーバーの rpc.svcgssd デーモンは、DES の暗号化タイプが許可されていないことを示すエラーをログに記録する場合があります。 - IdM サーバーから NFS サーバーにキータブをコピーします。たとえば、IdM サーバーと NFS サーバーが異なるマシンにある場合は、以下を実行します。
[root@ipaclient ~]# scp /tmp/krb5.keytab root@nfs.example.com:/etc/krb5.keytab
- IdM サーバーから IdM クライアントにキータブをコピーします。たとえば、以下のようになります。
[root@ipaclient ~]# scp /tmp/krb5.keytab root@client.example.com:/etc/krb5.keytab
- NFS サーバーで
/etc/exports
ファイルを設定します。/ipashare gss/krb5p(rw,no_root_squash,subtree_check,fsid=0)
- クライアントで NFS 共有をマウントします。
- 共有は必ず、nfs_server:/ /mountpoint と指定します。
-o sec
設定は、NFS サーバーの/etc/exports
ファイルで使用する設定と同じものを使用します。
[root@client ~]# mount -v -t nfs4 -o sec=krb5p nfs.example.com:/ /mnt/ipashare
5.4.2. ホストエントリーを追加する他の例
5.4.2.1. Web UI でのホストエントリーの追加
- Identity タブを開き、サブタブの ホスト を選択します。
- ホスト一覧の上部にある Add をクリックします。
- マシン名を入力し、ドロップダウンリストの設定済みゾーンからドメインを選択します。ホストに静的 IP アドレスが割り当てられている場合は、ホストエントリーにそのアドレスを追加して、DNS エントリーが完全に作成されるようにします。「正引き DNS ゾーンの追加」で説明されているように、DNS ゾーンは IdM で作成可能です。IdM サーバーが DNS サーバーを管理しない場合は、通常のテキストフィールドなど、メニューエリアでゾーンを手動で入力できます。注記ホスト名を解決できない場合でも、Force チェックボックスを選択して、ホストの DNS レコードを追加します。これは、DHCP を使用して、静的な IP アドレスがないホストに役に立ちます。これにより、IdM DNS サービスにプレースホルダーエントリーが作成されます。DNS サービスが動的にレコードを更新すると、ホストの現行の IP アドレスが削除され、DNS レコードが更新されます。
- Add and Edit をクリックして、拡張エントリーページに移動し、属性情報をさらに入力します。ホストのハードウェアと物理的な場所に関する情報は、ホストエントリーに追加できます。
5.4.2.2. コマンドラインでのホストエントリーの追加
$ ipa host-add client1.example.com
--ip-address
および --force
オプションを使用して、DNS リソースレコードにホストも追加できます。
例5.6 静的 IP アドレスを持つホストエントリーの作成
$ ipa host-add --force --ip-address=192.168.166.31 client1.example.com
--force
を使用して DNS エントリーで設定可能です。これにより、IdM DNS サービスにプレースホルダーエントリーが作成されます。DNS サービスが動的にレコードを更新すると、ホストの現行の IP アドレスが削除され、DNS レコードが更新されます。
例5.7 DHCP でホストエントリーの作成
$ ipa host-add --force client1.example.com
--updatedns
オプションを使用すると、ホストに関連のあるレコードはすべて DNS から削除されます。
$ ipa host-del --updatedns client1.example.com
5.5. キックスタートでの Linux クライアントの設定
- IdM サーバー上でホストエントリーを作成し、エントリーの一時 Kerberos パスワードを設定します。
ipa-client-install
スクリプトが (対話的に) 通常通りに実行されると、IdM ドメインにアクセスするための認証情報の入力が求められます。ただし、スクリプトが自動的に実行される場合には、既存の IdM ユーザーを使用せずに IdM ドメインにアクセスする方法が必要になります。これは、スクリプトでホストプリンシパルを設定し、IdM ドメインへのアクセス用の Kerberos パスワード (ホストアカウントに設定) を使用して実行します。以下に例を示します。[jsmith@server ~]$ ipa host-add kickstart-server.example.com --password=secret
パスワードは、最初の認証試行後に有効期限が切れます。登録が完了すると、ホストはキータブを使用して認証されます。 - 他のインストールと共に ipa-client パッケージも追加します。
%packages @ X Window System @ Desktop @ Sound and Video ipa-client ...
- 登録前に SSH 鍵が生成されるようにするインストール後の指示を作成し、
ipa-client-install
スクリプトを実行して IdM ドメインサービスへのアクセスおよび設定に必要なすべての情報を渡し、事前設定されたパスワードを指定します。この--unattended
オプションを使用して、スクリプトが非対話的に実行されるように指示します。%post --log=/root/ks-post.log # Generate SSH keys to ensure that ipa-client-install uploads them to the IdM server /usr/bin/ssh-keygen -q -t rsa -f /etc/ssh/ssh_host_rsa_key -C '' -N '' chmod 600 /etc/ssh/ssh_host_rsa_key chmod 644 /etc/ssh/ssh_host_rsa_key.pub /sbin/restorecon /etc/ssh/ssh_host_rsa_key.pub /usr/bin/ssh-keygen -q -t rsa1 -f /etc/ssh/ssh_host_key -C '' -N '' chmod 600 /etc/ssh/ssh_host_key chmod 644 /etc/ssh/ssh_host_key.pub /sbin/restorecon /etc/ssh/ssh_host_key.pub /usr/bin/ssh-keygen -q -t dsa -f /etc/ssh/ssh_host_dsa_key -C '' -N '' chmod 600 /etc/ssh/ssh_host_dsa_key chmod 644 /etc/ssh/ssh_host_dsa_key.pub /sbin/restorecon /etc/ssh/ssh_host_dsa_key.pub # Get the hostname to set as the host principal /bin/hostname > /tmp/hostname.txt # Run the client install script /usr/sbin/ipa-client-install --domain=EXAMPLEDOMAIN --enable-dns-updates --mkhomedir -w secret --realm=EXAMPLEREALM --server=server.example.com --unattended
注記Red Hat は、キックスタートの登録前にsshd
サービスを起動することは推奨していません。登録前にsshd
を起動すると、クライアントは自動的に SSH 鍵を生成するので、上記のスクリプトの使用が推奨されます。 - キックスタートスクリプトを実行します。
5.6. Two-Administrator 登録の実行
- 管理者は、「ホストエントリーを追加する他の例」の説明に従って、ホストエントリーを作成します。
- 2 つ目の管理者は、「IdM クライアントとしての Linux システムの設定」の説明のように IdM クライアントパッケージをマシンにインストールします。
- 2 つ目の管理者が設定スクリプトを実行すると、ipa-client-install コマンドで Kerberos パスワードとユーザー名 (プリンシパル) を指定する必要があります。たとえば、以下のようになります。
$ ipa-client-install -w secret -p admin2
- キータブは、クライアントマシンが IdM ドメインに接続できないように、サーバーで生成されてクライアントマシンにプロビジョニングされます。このキータブは、所有者が
root:root
、パーミッションが 0600 として保存します。
5.7. クライアントマシンの手動による設定解除
--updatedns
オプションを使用して、ドメイン DNS 設定を自動的に更新します。
[root@server ~]# ipa-client-install --uninstall --updatedns
- クライアントで、メインのキータブから以前のホスト名を削除します。これは、レルムのプリンシパルをすべて削除するか、特定のプリンシパルを削除して実行できます。たとえば、すべてのプリンシパルを削除するには、以下を実行します。
[jsmith@client ~]$ ipa-rmkeytab -k /etc/krb5.keytab -r EXAMPLE.COM
特定のプリンシパルを削除するには、以下を実行します。[jsmith@client ~]$ ipa-rmkeytab -k /etc/krb5.keytab -p host/server.example.com@EXAMPLE.COM
- クライアントシステムで、全証明書の
certmonger
の追跡を無効にします。各証明書は、個別に追跡から削除する必要があります。まず、追跡する全証明書を一覧表示し、各証明書のデータベースとニックネームを取り出します。証明書の数は、ホストに設定されたサービスにより異なります。[jsmith@client ~]$ ipa-getcert list
次に、それぞれの追跡を無効にします。以下に例を示します。[jsmith@client ~]$ ipa-getcert stop-tracking -n "Server-Cert" -d /etc/httpd/alias
- IdM サーバーで、IdM DNS ドメインから以前ホストを削除します。これはオプションですが、システムに関連付けられた以前の IdM エントリーを消去して後で正しく登録できるようにします。
[jsmith@server ~]$ kinit admin [jsmith@server ~]$ ipa host-del server.example.com
- 別の場所に移動した仮想マシンなど、新しい IdM ドメインにシステムを追加し直す必要がある場合には、クライアントシステムで ipa-join コマンドを使用してシステムを再度参加させることができます。
[jsmith@client ~]$ ipa-join
第6章 Identity Management のアップグレード
6.1. アップグレードの注意事項
mod_nss
モジュールで無効にする必要があります。次の手順に従い、無効になっていることを確認してください。
/etc/httpd/conf.d/nss.conf
ファイルを編集し、NSSProtocol
パラメーターをTLSv1.0
(後方互換性用) およびTLSv1.1
に設定します。NSSProtocol TLSv1.0,TLSv1.1
httpd
サービスを再起動します。# service httpd restart
- 更新プロセスでは、全スキーマおよび LDAP 設定、Apache 設定、およびその他のサービス設定が自動的に更新され、IdM 関連のサービスがすべて再起動されます。
- レプリカの作成時には、ベースとしたマスターと同じバージョンを使用する必要があります。つまり、サーバーのアップグレードプロセス時に、レプリカを以前の Identity Management バージョンで作成しないようにしてください。アップグレードプロセスが完了するまで待ってから、新しいレプリカを作成します。
- スキーマが変更されると、サーバー間で複製されます。したがって、マスターサーバー 1 台が更新されると、パッケージがまだ更新されていない場合でも、全サーバーおよびレプリカのスキーマが更新されます。これにより、新しいスキーマを使用する新規エントリーを、IdM ドメイン内にある他の全サーバーでそのまま複製できます。LDAP のアップグレード操作は、
/var/log/ipaupgrade-log
のアップグレードログに記録されます。LDAP エラーが発生した場合は、上記のログに記録されます。エラーが解決されると、updater スクリプトを実行して LDAP 更新プロセスを手動で開始できます。[root@server ~]# ipa-ldap-updater --upgrade
- クライアントには、新しいパッケージをインストールする必要はありません。ドメインでのクライアント登録には、Red Hat Enterprise Linux システムの設定に使用するクライアントパッケージによる影響はありません。
- クライアントパッケージを更新すると、バグ修正を含む certmonger など、他の依存関係が更新される可能性がありますが、IdM ドメインでクライアントの機能や動作を維持するためには必要ありません。
6.2. パッケージのアップグレード
[root@ipaserver ~]# yum update
[root@ipaserver ~]# yum update ipa-server
6.3. チケット委譲のブラウザー設定の削除 (6.2 からのアップグレード)
network.negotiate-auth.delegation-uris .example.com
既存の設定済みブラウザーの更新
Identity Management の Web UI を使用するように設定されているブラウザーでは、 delegation-uris 設定は、ipa-server-3.0.0
または ipa-client-3.0.0
にアップグレードしてから消去できます。
新規ブラウザー設定用の configure.jar の更新
ブラウザーの設定は configure.jar
ファイルに定義されます。この JAR ファイルはサーバーのインストール時に生成され、IdM の更新時に他のファイルと一緒に更新されません。IdM サーバーをアップグレードしても、設定済みのブラウザーには不必要な delegation-uris パラメーターが設定されたままになります。ただし、configure.jar
ファイルは更新できます。
configure.jar
の preferences.html
ファイルは、delegation-uris パラメーターを設定します。更新した preferences.html
ファイルは configure.jar
に追加してから、configure.jar
を再署名し、IdM サーバーにデプロイし直すことができます。
configure.jar
ファイルだけを更新します。これは、署名証明書が唯一含まれるマスターサーバーです。次に、更新したファイルを他のサーバーおよびレプリカに伝播します。
- 最初の IdM マスターサーバー (最初のインスタンス) でパッケージを更新します。これにより、
configure.jar
ファイルを含む 3.0 UI パッケージが作成されます。 - 既存の
configure.jar
ファイルをバックアップします。[root@ipaserver ~]# mv /usr/share/ipa/html/configure.jar /usr/share/ipa/html/configure.jar.old
- 一時作業ディレクトリーを作成します。
[root@ipaserver ~]# mkdir /tmp/sign
- 更新した
preferences.html
ファイルを作業ディレクトリーにコピーします。[root@ipaserver ~]# cp /usr/share/ipa/html/preferences.html /tmp/sign
- signtool コマンド (NSS ユーティリティーの 1 つ) を使用して新しい
preferences.html
ファイルを追加し、configure.jar
ファイルを再署名します。[root@ipaserver ~]# signtool -d /etc/httpd/alias -k Signing-Cert -Z /usr/share/ipa/html/configure.jar -e ".html" -p `cat /etc/httpd/alias/pwdfile.txt` /tmp/sign
-e
オプションは、ツールに対して、拡張子が.html
のファイルのみに署名するように指示します。-Z
オプションでは、新しい JAR ファイルを作成します。 - 再生成された
configure.jar
ファイルを、他の全 IdM サーバーおよびレプリカにコピーします。
6.4. IdM サーバーのアップグレード前のテスト (推奨)
- 「4章IdM レプリカの設定」で説明されているように、実稼働サーバーのいずれかを基にレプリカを設定します。この例では、これは Test Replica という名前を使用しています。Test Replica が 実稼働 サーバーおよびドメインに正常に接続できることを確認します。
- 実稼働ドメインに Test Replica が正常に追加されたことを確認したら、ネットワークから Test Replica の接続を解除します。
- 元の IdM サーバーと Test Replica から、Test Replica のレプリカ合意を削除します。
- Test Replica をネットワークに再接続します。
- yum またはお使いのシステムに適したパッケージの更新ツールを使用して、Test Replica でパッケージをアップグレードします。たとえば、以下のようになります。
[root@ipareplica ~]# yum update ipa*
- Kerberos 認証情報の取得、サーバー UI の表示、コマンドの実行など、Test Replica で一般的な内容をテストします。
第7章 IdM サーバーおよびレプリカのアンインストール
--uninstall
オプションを ipa-server-install コマンドに指定します。
[root@ipareplica ~]# ipa-server-install --uninstall
第8章 IdM サーバーおよびサービスの基本的な管理
8.1. IdM ドメインの起動と停止
ipactl start | stop | restart
[root@server ~]# chkconfig ipactl on
8.2. IdM クライアントツールの概要
- スクリプトを使用すると、手動による介入なしに一貫した方法で管理タスクを自動化して実行できます。
- エントリーには、1 回の手順で設定可能な属性 (または任意の属性のサブセット) を追加できます。Web UI では、エントリーを完全に設定するには、最初にエントリーを作成して次にオプション属性を追加するという 2 つの手順が必要になります。
- コマンドラインスクリプトでは、別の属性の追加 (UI では対応していない場合あり) や、スキーマが設定されている場合にはエントリーへのカスタム属性の追加にも対応します。
8.2.1. ipa コマンドの構造
ipa objectType-operation objectName --option=value
ipa user-add entryName options
ipa help topic
ipa help topics
8.2.1.1. ipa でのエントリーの追加、編集、および削除
$ ipa user-add jsmith
--set/addattr
オプション (「--setattr、--addattr、および --delattr を使用したエントリー属性の管理」) を使用してその内容を渡します。
$ ipa user-add First name: John Last name: Smith User login [jsmith]: jsmith -------------------- Added user "jsmith" -------------------- ...
$ ipa user-mod jsmith --title="Editor III"
$ ipa user-del jsmith
8.2.1.2. ipa でのエントリーの検索および表示
sn
の値など) と、jsmith のユーザー名や Smithson といった長い名前などの値の一部に一致するものを検索します。
ipa user-find smith
--sizelimit
および --timelimit
オプションを指定して上書きできます。たとえば、デフォルトの時間制限が 60 秒で検索にかかる時間が長くなる場合に、時間制限を 120 秒に増やすことができます。
[jsmith@ipaserver ~]$ ipa user-find smith --timelimit=120
--all
オプションを使用します。
--all
オプションが使用されない限り、エントリーとともに属性のサブセットのみが表示されます。
8.2.1.3. ipa でのグループおよびコンテナーへのメンバーの追加
8.2.2. ipa コマンドの位置要素
ipa command entryName --options=values
ipa command parentEntryName childEntryName --childOptions=childValues
8.2.3. --setattr、--addattr、および --delattr を使用したエントリー属性の管理
--mail
引数を使用し、DNS ゾーンの動的更新を有効にするには、zone コマンドに --allow-dynupdate
オプションを使用します。また、自動マウントのマッピングのマップキーを指定するには --key
オプションを使用します。
--setattr
および --addattr
オプションを使用して、サポート対象の属性をエントリーに追加または編集できます。
--setattr
または --addattr
オプションでは検証されません。
--setattr=attribute=value
--setattr
オプションは、指定された属性に値を 1 つ設定し、既存の値は複数値の属性であっても上書きされます。
--addattr
オプションは、属性に新しい値を追加します。複数値の属性の場合は、既存の値を維持しながら新しい値を追加します。
--setattr
オプションと --addattr
は、同じコマンド呼び出しで複数回使用できます。たとえば、以下のようになります。
$ ipa user-mod jsmith --addattr=mail=johnnys@me.com --addattr=mail=jsmith@example.com --setattr=description="backup IT manager for the east coast branch"
--delattr
オプションを使用してエントリーから削除できます。値が 1 つだけの属性の場合には、属性は削除されます。値が複数ある属性の場合は、指定された値のみが削除されます。以下に例を示します。
$ ipa user-mod jsmith --delattr=mail=johnnys@me.com
$ ipa user-mod jsmith --addattr=mail=johnnys@me.com --delattr=mail=johnnys@me.com
8.2.4. IdM ツールでの特殊文字の使用
8.2.5. 実行前の IdM ドメインへのログイン
[jsmith@ipaserver ~]$ kinit admin
8.3. IdM へのログイン
8.3.1. IdM へのログイン
$ kinit
user
としてマシンにログインしている場合は、以下を実行します。
$ kinit Password for user@EXAMPLE.COM:
pam_krb5
が IdM クライアントマシンに設定されている場合には、ユーザーがマシンにログインすると、sudo など認証が必要なマシンサービスに使用できるチケットが作成されます。
8.3.2. IdM ユーザーがシステムユーザーではない場合のログイン
$ kinit userName Password for userName@EXAMPLE.COM:
admin
が作成されます。admin ユーザーとして認証するには、kinit の実行時に、ユーザー名として admin を使用しまます。
$ kinit admin
8.3.3. 現在ログインしているユーザーの確認
$ klist Ticket cache: FILE:/tmp/krb5cc_500 Default principal: ipaUser@EXAMPLE.COM Valid starting Expires Service principal 11/10/08 15:35:45 11/11/08 15:35:45 krbtgt/EXAMPLE.COM@EXAMPLE.COM Kerberos 4 ticket cache: /tmp/tkt500 klist: You have no tickets cached
KRB5CCNAME
環境変数を設定します。この変数は、認証情報のキャッシュを異なるシェルに分離します。
8.3.4. ユーザーの Kerberos チケットのキャッシュ
KRB5CCNAME
の特別な環境変数を使用します。
8.4. IdM Web UI の使用
8.4.1. Web UI の概要
メインメニュータブ | 設定エリア |
---|---|
アイデンティティー |
|
ポリシー |
|
IdM サーバー (Identity Management 内のアクセス制御) |
|
図8.1 メインメニュー
8.4.2. IdM Web UI の表示
- 「IdM へのログイン」の記載のように、kinit を使用して有効な Kerberos チケットを取得します。
- IdM の URL を開きます。完全な URL は https://IPAserver-FQDN/ipa/ui ですが、このサービスにも https://IPAserver-FQDN を開くだけでアクセスできます。たとえば、以下のようになります。
https://server.example.com https://server.example.com/ipa/ui
8.4.3. ブラウザーの設定
8.4.3.1. Firefox の設定
図8.2 Kerberos 認証エラーメッセージ
- follow these directions リンクをクリックします。
- IdM サーバーの CA 証明書のインポートリンクをクリックします。
- CA 証明書の Web サイトおよびソフトウェア開発者 (最初と最後) トラストの部分を設定します。
- Configure Firefox ボタンをクリックします。クリックすると、Firefox 設定の negotiate オプションすべてが入力され、IdM ドメインの設定に使用されます。プロセスが完了すると、Firefox がシングルサインオンの設定を完了した旨の成功表示のポップアップが表示されます。そこから、IdM Web UI にリダイレクトされます。
- Firefox を起動します。
- アドレスバーに about:config と入力します。
- Search フィールドに negotiate と入力して Kerberos 関連のパラメーターをフィルターします。
- Red Hat Enterprise Linux で、URI パラメーターのドメイン名を一番前のピリオド (.) も含めて入力し、gsslib パラメーターを true に設定します。
network.negotiate-auth.trusted-uris .example.com network.negotiate-auth.using-native-gsslib true
Windows で、信頼できる URI およびライブラリーパスを設定し、認証用の組み込みの Microsoft Kerberos を無効にします。network.negotiate-auth.trusted-uris .example.com network.auth.use-sspi false network.negotiate-auth.gsslib: C:\Program Files\MIT\Kerberos\bin\gssapi32.dll
64 ビットシステムでは、ライブラリーはC:\Program Files(x86)\MIT\Kerberos\bin\gssapi32.dll
に配置されています。 http://ipaserver.example.com
など、IdM サーバーの完全修飾ドメイン名に移動して、Web UI を開きます。Web UI を開き、Kerberos の認証エラーがないことを確認します。- 次に IdM サーバーの CA 証明書を
http://ipa.example.com/ipa/config/ca.crt
からダウンロードします。 - 表示された Downloading Certificate ウィンドウで、最初 (Trust this CA to identify web sites) と 3 番目 (Trust this CA to identify software developers) のチェックボックスを選択します。
8.4.3.2. Chrome の設定
- CA 証明書のインポート
http://my.ipa.server/ipa/config/ca.crt
から CA 証明書をダウンロードします。ホストが IdM クライアントでもある場合は、/etc/ipa/ca.crt
で証明書を確認することができます。- デフォルトでは Chrome の右上隅にある
Customize and control Google Chrome
のツールチップのメニューボタンをクリックし、Settings をクリックします。 - Show advanced settings をクリックして他のオプションを表示し、
HTTPS/SSL
ヘディングの下にある Manage certificates ボタンをクリックします。 - Authorities タブで、下部の インポート ボタンをクリックします。
- 最初の手順でダウンロードした CA 証明書ファイルを選択します。
- SPNEGO (Simple and Protected GSSAPI Negotiation Mechanism) を有効にして Chrome で Kerberos 認証を使用します。
- 以下を実行して、必要なディレクトリーを作成していることを確認します。
[root@client]# mkdir -p /etc/opt/chrome/policies/managed/
- 書き込み権限をシステム管理者または root に限定して新しい
/etc/opt/chrome/policies/managed/mydomain.json
ファイルを作成し、以下の行を追加します。{ "AuthServerWhitelist": "*.example.com" }
これには以下を実行します。[root@server]# echo '{ "AuthServerWhitelist": "*.example.com" }' > /etc/opt/chrome/policies/managed/mydomain.json
8.4.4. 別のシステムでのブラウザーの使用
- IdM サーバーから
/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
- 「ブラウザーの設定」のように、外部マシンで Firefox を設定します。
8.4.5. 簡易ユーザー名/パスワード認証情報でのログイン
図8.3 IdM フォームベースのログインオプション
図8.4 IdM パスワードのプロンプト
8.4.6. プロキシーサーバーでの UI の使用
8.5. TLS 1.2 環境で実行する IdM サーバーの設定
第9章 アイデンティティー: ユーザーおよびユーザーグループの管理
9.1. ユーザーホームディレクトリーの設定
9.1.1. ホームディレクトリーの概要
- ユーザーのホームディレクトリーに使用するデフォルトの接頭辞は
/home
です。 - IdM では、ユーザーのログイン時に、ホームディレクトリーは自動的に作成されません。ホームディレクトリーの自動作成には、
pam_oddjob_mkhomedir
モジュールまたはpam_mkhomedir
モジュールが必要です。このモジュールは、「PAM ホームディレクトリーモジュールの有効化」に記載されているように、クライアントのインストールの一部として、またはインストール後に設定できます。IdM のホームディレクトリープロセスでは、まずpam_oddjob_mkhomedir
モジュールの使用を試みます。このモジュールでは、ホームディレクトリーの作成に必要なユーザー権限やアクセス権限が少なくて済み、SELinux とスムーズに統合できるようにするためです。このモジュールが利用できない場合には、プロセスはpam_mkhomedir
モジュールにフォールバックします。注記Red Hat Enterprise Linux 5 クライアントでは、クライアントのインストールスクリプトはpam_oddjob_mkhomedir
モジュールが利用できる場合でも、pam_mkhomedir
モジュールを使用します。Red Hat Enterprise Linux 5 でpam_oddjob_mkhomedir
モジュールを使用するには、PAM 設定を手動で編集します。 - ドメイン内の全マシンが利用できる
/home
を提供する NFS ファイルサーバーを使用し、IdM サーバーに自動マウントすることができます。NFS ユーザーへの root アクセス割り当てに関連するセキュリティーの問題、/home
ツリー全体を読み込む際のパフォーマンスの問題、ホームディレクトリーのリモートサーバーを使用する際のネットワークパフォーマンスの問題など、NFS の使用時に問題が発生する可能性があります。Identity Management では NFS の使用に関する一般的なガイドラインがあります。- automount を使用して、ユーザーがログインした時のみ、
/home
ツリー全体を読み込むのではなく、ユーザーのホームディレクトリーのみをマウントします。 - 限定的なパーミッションを割り当てたリモートユーザーを使用してホームディレクトリーを作成し、そのユーザーとして IdM サーバーに共有をマウントします。IdM サーバーは httpd プロセスとして実行されるので、sudo または同様のプログラムを使用して IdM サーバーへの限定的なパーミッションを許可し、NFS サーバーにホームディレクトリーを作成できます。
pam_oddjob_mkhomedir
モジュールなどのメカニズムを使用して、そのユーザーとしてホームディレクトリーを作成します。
ホームディレクトリーに自動マウントを使用する方法は、「ホームディレクトリーを手動でマウントする手順」を参照してください 。 - ホームディレクトリーの作成に適したディレクトリーとメカニズムがない場合は、ログインできない可能性があります。
9.1.2. PAM ホームディレクトリーモジュールの有効化
pam_oddjob_mkhomedir
モジュールまたは pam_mkhomedir
モジュールを使用できます。必要なパフォーマンスが少なく、SELinux と適切に連携するので、IdM では pam_oddjob_mkhomedir
モジュールの使用が優先されます。このモジュールがインストールされていない場合は、pam_mkhomedir
モジュールにフォールバックされます。
pam_oddjob_mkhomedir
モジュールまたは pam_mkhomedir
モジュールが必要ではありません。これは、共有ストレージが利用できない場合でも、*_mkhomedir
モジュールがホームディレクトリーを作成しようとするためです。このモジュールでホームディレクトリーを作成できない場合は、ユーザーは IdM ドメインにログインできなくなります。
pam_oddjob_mkhomedir
(または pam_mkhomedir
) モジュールを有効にする方法は 2 つあります。
--mkhomedir
オプションは ipa-client-install コマンドで使用できます。このオプションはクライアントでは可能ですが、サーバーで設定しても利用できません。- システムの authconfig コマンドを使用して、
pam_oddjob_mkhomedir
モジュールを有効にできます。たとえば、以下のようになります。authconfig --enablemkhomedir --update
このオプションは、インストール後のサーバーマシンとクライアントマシンの両方に使用できます。
pam_oddjob_mkhomedir
モジュールが利用できる場合でも、pam_mkhomedir
モジュールを使用します。Red Hat Enterprise Linux 5 で pam_oddjob_mkhomedir
モジュールを使用するには、PAM 設定を手動で編集します。
9.1.3. ホームディレクトリーを手動でマウントする手順
- ユーザーディレクトリーマップ用に新しい場所を作成します。
[bjensen@server ~]$ ipa automountlocation-add userdirs Location: userdirs
- 新しい場所の
auto.direct
ファイルに直接マップを追加します。この例では、マウントポイントは/share
です。[bjensen@server ~]$ ipa automountkey-add userdirs auto.direct --key=/share --info="-ro,soft, ipaserver.example.com:/home/share" Key: /share Mount information: -ro,soft, ipaserver.example.com:/home/share
9.2. ユーザーエントリーの管理
9.2.1. ユーザー名の形式
[a-zA-Z0-9_.][a-zA-Z0-9_.-]{0,252}[a-zA-Z0-9_.$-]?
9.2.2. ユーザーの追加
9.2.2.1. Web UI での操作
- Identity タブを開き、サブタブの ユーザー を選択します。
- ユーザー一覧上部にある Add をクリックします。
- ユーザーの名と姓を入力します。ユーザーログイン (UID) はユーザーのフルネームに基づいて自動的に生成されますが、Optional field リンクをクリックすると手動で設定できます。注記ユーザー名の作成時には大文字と小文字は区別されませんので、大文字、小文字は無視されます。ユーザー名は、大文字と小文字が混在して作成された場合でも、すべての小文字になるように自動的に正規化されます。
- 「Web UI での操作」にあるように、Add and Edit をクリックして、拡張エントリーページに移動し、属性情報をさらに入力します。ユーザーエントリーは、指定のユーザー情報およびユーザーエントリーテンプレートに基づいて、すでに入力されている基本情報で作成されます。
9.2.2.2. コマンドラインでの操作
[bjensen@server ~]$ ipa user-add [username] [attributes]
[bjensen@server ~]$ ipa user-add First name: John Last name: Smith User login [jsmith]: jsmith -------------------- Added user "jsmith" -------------------- User login: jsmith First name: John Last name: Smith Full name: John Smith Display name: John Smith Initials: JS Home directory: /home/jsmith GECOS: John Smith Login shell: /bin/sh Kerberos principal: jsmith@EXAMPLE.COM Email address: jsmith@example.com UID: 882600007 GID: 882600007 Password: False Member of groups: ipausers Kerberos keys available: False
[bjensen@server ~]$ ipa user-add jsmith --first=John --last=Smith --manager=bjensen --email=johnls@example.com --homedir=/home/work/johns --password
uidNumber
が一意であるかどうかは検証されません。ID を重複させることができます。POSIX エントリーでは、想定されている動作 (非推奨) です。
9.2.3. ユーザーの編集
9.2.3.1. Web UI での操作
- Identity タブを開き、サブタブの ユーザー を選択します。
- 編集するユーザー名をクリックします。
- ユーザー用に編集できる属性には、さまざまなタイプがあります。デフォルト属性はすべて、表9.2「デフォルトの Identity Management ユーザー属性」に記載されています。Identity Settings と Account Settings エリアの属性のほとんどは、ユーザー情報またはユーザーエントリーのテンプレートを基にデフォルト値が入力されています。
- フィールドを編集するか、必要に応じて属性別に Add リンクをクリックし、エントリーで属性を作成します。
- 編集が完了したら、ページ上部にある Update リンクをクリックします。
9.2.3.2. コマンドラインでの操作
[bjensen@server ~]$ ipa user-mod loginID --attributeName=newValue
[bjensen@server ~]$ ipa user-mod jsmith --title="Editor III"
--addattr
オプションで管理できます。
--setattr
の使用時も同様です。ただし、--addattr
を使用すると新しい属性が追加されます。多値属性の場合には、既存の値に新しい値が追加されます。
例9.1 複数のメール属性
[bjensen@server ~]$ ipa user-add jsmith --first=John --last=Smith --email=johnls@example.com
[bjensen@server ~]$ ipa user-mod jsmith --addattr=mail=johnnys@me.com
[bjensen@server ~]$ ipa user-find jsmith --all
--------------
1 user matched
--------------
dn: uid=jsmith,cn=users,cn=accounts,dc=example,dc=com
User login: jsmith
.....
Email address: jsmith@example.com, jsmith@new.com
--addattr
オプションを 2 回使用します。
[bjensen@server ~]$ ipa user-add jsmith --first=John --last=Smith --email=johnls@example.com --addattr=mail=johnnys@me.com --addattr=mail=admin@example.com
9.2.4. ユーザーの削除
9.2.4.1. Web UI の使用
- Identity タブを開き、サブタブの ユーザー を選択します。
- ユーザー名のチェックボックスを選択して削除します。
- タスクエリアの上部にある Delete リンクをクリックします。
- プロンプトが表示されたら、削除を確定します。
9.2.4.2. コマンドラインでの操作
[bjensen@server ~]$ ipa user-del jsmith
[bjensen@server ~]$ ipa user-del jsmith bjensen mreynolds cdickens
--continue
オプションを使用して、エラーに関係なくコマンドを続行します。成功および失敗した操作の概要は、コマンドの完了時に標準出力 (stdout) に出力されます。--continue
を使用しない場合には、このコマンドはエラーが発生する まで、操作を続行し、(エラーが発生すると) 操作を終了します。
9.3. ユーザーの公開 SSH 鍵の管理
authorized_keys
ファイルに保存します。ユーザーがリソースに再度アクセスを試みると、マシンは単に authorized_keys
ファイルをチェックして、承認済みのユーザーに自動的にアクセスを許可します。
- SSH 鍵は、環境内の全マシンに手動かつ個別に配布する必要があります。
- 管理者は設定に追加するユーザーキーを許可する必要がありますが、ユーザーまたはキー発行者を適切に検証することが困難であるため、セキュリティー問題が発生する可能性があります。
9.3.1. SSH 鍵の形式
id_rsa.pub
などのキーファイルでは、キーエントリーは先にタイプで、次にキー自体、その後に追加のコメントまたは識別子で識別されます。たとえば、特定のホスト名に関連付けられた RSA 鍵の場合:
"ssh-rsa ABCD1234...== ipaclient.example.com"
9.3.2. ユーザー SSH 鍵の Web UI でのアップロード
- ユーザーキーを生成します。たとえば、以下のように OpenSSH ツールを使用します。
[jsmith@server ~]$ ssh-keygen -t rsa -C jsmith@example.com Generating public/private rsa key pair. Enter file in which to save the key (/home/jsmith/.ssh/id_rsa): Created directory '/home/jsmith/.ssh'. Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /home/jsmith/.ssh/id_rsa. Your public key has been saved in /home/jsmith/.ssh/id_rsa.pub. The key fingerprint is: a5:fd:ac:d3:9b:39:29:d0:ab:0e:9a:44:d1:78:9c:f2 jsmith@example.com The key's randomart image is: +--[ RSA 2048]----+ | | | + . | | + = . | | = + | | . E S.. | | . . .o | | . . . oo. | | . o . +.+o | | o .o..o+o | +-----------------+
- 公開鍵をキーファイルからコピーします。完全なキーエントリーは type key== comment の形式です。key== は必須ですが、エントリー全体を保存できます。
[jsmith@server ~]$ cat /home/jsmith/.ssh/id_rsa.pub ssh-rsa AAAAB3NzaC1yc2E...tJG1PK2Mq++wQ== jsmith@example.com
- Identity タブを開き、サブタブの ユーザー を選択します。
- 編集するユーザー名をクリックします。
- Settings タブの Account Settings エリアで SSH public keys: Add リンクをクリックします。
- SSH public keys の横にある Add リンクをクリックします。
- ユーザーの公開鍵に貼り付けて、ボタンをクリックします。SSH public keys フィールドに New: key set と表示されるようになります。Show/Set キー のリンクをクリックすると、送信したキーが表示されます。
- 複数のキーをアップロードするには、公開鍵リストの下にある Add をクリックして、他のキーをアップロードします。
- すべてのキーが送信されたら、ユーザーページ上部の Update ボタンをクリックして変更を保存します。
図9.1 保存された公開鍵
9.3.3. コマンドラインでのユーザーの SSH 鍵のアップロード
--sshpubkey
オプションは、64 ビットエンコードの公開鍵をユーザーエントリーにアップロードします。たとえば、以下のようになります。
[jsmith@server ~]$ ipa user-mod jsmith --sshpubkey="ssh-rsa 12345abcde= ipaclient.example.com"
--sshpubkey
オプション 1 つでコンマ区切りのキー一覧を指定します。
--sshpubkey="12345abcde==,key2==,key3=="
9.3.4. ユーザーキーの削除
- Identity タブを開き、サブタブの ユーザー を選択します。
- 編集するユーザー名をクリックします。
- Settings タブの Account Settings エリアを開きます。
- 削除するキーのフィンガープリントの横にある Delete のリンクをクリックします。
- 変更を保存するには、ユーザーページの上部にある Update リンクをクリックします。
--sshpubkey=
を空の値に指定して ipa user-mod を実行します。これで、対象ユーザーの公開鍵が すべて 削除されます。たとえば、以下のようになります。
[jsmith@server ~]$ kinit admin [jsmith@server ~]$ ipa user-mod --sshpubkey= jsmith
9.4. パスワードの変更
- 管理者権限のない通常ユーザーは、個人パスワードのみを変更でき、すべてのパスワードは IdM パスワードポリシーの制限が適用されます。こうすることで、最終的なパスワードのセキュリティーを確保しつつ、管理者は初期パスワードを作成するか、簡単にパスワードをリセットできます。管理者がユーザーに送信したパスワードは一時的なものであるため、セキュリティーリスクはほぼありません。
- IdM の管理ユーザーとしてパスワードを変更すると、IdM パスワードポリシーは上書きされますが、パスワードの有効期限はすぐに切れます。そのため、ユーザーは次回のログイン時にパスワードを変更する必要があります。同様に、パスワードの変更権限があるユーザーは、パスワードを変更でき、パスワードポリシーは適用されませんが、別のユーザーは次回のログイン時にパスワードをリセットする必要があります。
- LDAP ツールを使用して LDAP Directory Manager ユーザーとしてパスワードを変更すると、IdM パスワードポリシーがすべて上書きされます。
9.4.1. Web UI での操作
- Identity タブを開き、サブタブの ユーザー を選択します。
- パスワードをリセットするユーザーの名前をクリックします。すべてのユーザーは自分のパスワードを変更できますが、管理者または、権限を委譲されたユーザーのみが、他のユーザーのパスワードを変更できます。
- Account Settings エリアまでスクロールします。
- Reset Password のリンクをクリックします。
- ポップアップボックスで、新しいパスワードを入力して確認します。
9.4.2. コマンドラインでの操作
[bjensen@ipaserver ~]$ kinit admin [bjensen@ipaserver ~]$ ipa user-mod jsmith --password
9.5. ユーザーアカウントの有効化、無効化
9.5.1. Web UI での操作
図9.2 ユーザー一覧の上部でのオプションの無効化/有効化
- Identity タブを開き、サブタブの ユーザー を選択します。
- ユーザー名をクリックして、非アクティブまたはアクティブにします。
- アクションのドロップダウンメニューで、Disable を選択します。
- Accept ボタンをクリックします。
図9.3 ユーザーステータスのアイコンの無効化
9.5.2. コマンドラインでの操作
[bjensen@server ~]$ ipa user-disable jsmith
9.6. ログイン失敗後のユーザーアカウントのロック解除
[bjensen@ipaserver ~]$ kinit admin [bjensen@ipaserver ~]$ ipa user-unlock jsmith
9.7. スマートカード
9.7.1. Identity Management でのスマートカードおよびスマートカードリーダーのサポート
/etc/pki/nssdb/
の NSS データベースに配置されています。
- modutil ユーティリティーを使用して、必要な PKCS #11 モジュールを手動で追加します。たとえば、以下のようになります。
[root@ipaclient ~]# modutil -dbdir /etc/pki/nssdb/ -add "My PKCS#11 module" -libfile libmypkcs11.so ... Module "My PKCS#11 Module" added to database.
modutil の使用方法は、modutil(1) の man ページを参照してください。 - NSS データベースに、スマートカードで証明書を検証する必要のある認証局 (CA) の証明書をすべて追加します。たとえば、
ca_certificate.pem
ファイルの CA 証明書を NSS データベースに追加するには、次のコマンドを実行します。[root@ipaclient ~]# certutil -A -d /etc/pki/nssdb/ -n 'CA certificate' -t CT,C,C -a -i ca_certificate.pem
certutil の使用方法は、certutil(1) の man ページを参照してください。
9.7.2. スマートカードからの証明書のエクスポート
- スマートカードをリーダーに挿入します。
- 以下のコマンドを実行してスマートカードの証明書を表示します。
[user@ipaclient ~]$ certutil -L -d /etc/pki/nssdb/ -h all Certificate Nickname Trust Attributes SSL,S/MIME,JAR/XPI my_certificate CT,C,C
出力で認証に使用する証明書を特定して、そのニックネームをメモします。 - 証明書を Base64 形式で
user.crt
に抽出するには、前のステップのニックネームを使用します。[user@ipaclient ~]$ certutil -L -d /etc/pki/nssdb/ -n 'my_certificate' -r | base64 -w 0 > user.crt
base64
ユーティリティーは、coreutils パッケージに含まれます。
9.7.3. IdM ユーザーのスマートカード証明書の保存
9.7.4. Identity Management クライアントでのスマートカード認証
- ローカル認証
- テキストコンソール
- Gnome Display Manager (GDM) などのグラフィカルコンソール
- su, または sudo などのローカル認証サービス
ssh
でのリモート認証- スマートカードの証明書は、PIN で保護される SSH の秘密鍵と合わせて保存されます。
ssh
のみをサポートします。FTP などの他のサービスには対応していません。
9.7.4.1. IdM クライアントでのスマートカード認証の設定
- スマートカードのサポートを有効にするには、SSSD がパスワード、ワンタイムパスワード (OTP)、またはスマートカードの PIN を要求できるようにします。これには、
/etc/pam.d/password-auth
および/etc/pam.d/system-auth
の PAM 設定ファイルのauth
の行を変更します。- デフォルトの
/etc/pam.d/password-auth
で以下の行を削除します。auth required pam_env.so auth sufficient pam_unix.so nullok try_first_pass auth requisite pam_succeed_if.so uid >= 500 quiet auth sufficient pam_sss.so use_first_pass auth required pam_deny.so
以下の行に置き換えます。auth required pam_env.so auth [default=1 success=ok] pam_localuser.so auth [success=done ignore=ignore default=die] pam_unix.so nullok try_first_pass auth requisite pam_succeed_if.so uid >= 500 quiet auth sufficient pam_sss.so forward_pass auth required pam_deny.so
- 同様に、デフォルトの
/etc/pam.d/system-auth
で以下の行を削除し ます。auth required pam_env.so auth sufficient pam_unix.so nullok try_first_pass auth requisite pam_succeed_if.so uid >= 500 quiet auth sufficient pam_sss.so use_first_pass auth required pam_deny.so
以下の行に置き換えます。auth required pam_env.so auth [default=1 success=ok] pam_localuser.so auth [success=done ignore=ignore default=die] pam_unix.so nullok try_first_pass auth requisite pam_succeed_if.so uid >= 500 quiet auth sufficient pam_sss.so forward_pass auth required pam_deny.so
/etc/sssd/sssd.conf
の以下のオプションをtrue
に設定します。[pam] pam_cert_auth=true
- SSSD を再起動します。
[root@ipaclient ~]# systemctl restart sssd
9.7.4.2. スマートカードを使用した SSH ログイン
$ ssh -I /usr/lib/libmypkcs11.so -l user@example.com host.example.com Enter PIN for 'Smart Card':
9.8. ユーザープライベートグループの管理
9.8.1. ユーザープライベートグループの表示
--private
オプションを指定して検索および一覧表示できます。たとえば、以下のようになります。
[root@server ~]# ipa group-find --private --------------- 1 group matched --------------- Group name: jsmith Description: User private group for jsmith GID: 1084600001 ---------------------------- Number of entries returned 1 ----------------------------
9.8.2. 特定ユーザーのプライベートグループの無効化
--noprivate
オプションを使用してユーザーが作成されると、プライベートグループの作成を無効にできます。
--gid
オプションを使用して明示的にユーザー GID を設定するか、GID でグループを作成し、自動メンバールール を使用して (「25章ポリシー: ユーザーおよびホストの自動グループメンバーシップの定義」で説明) そのグループにユーザーを追加する必要があります。
[jsmith@server ~]$ ipa user-add jsmith --first=John --last=Smith --noprivate
--gid 10000
9.8.3. グローバルでのプライベートグループの無効化
- ipa-managed-entries コマンドを使用して、利用可能な管理エントリープラグイン定義を一覧表示します。デフォルトでは、新規ユーザー (UPG) に 1 つ、ネットグループに 1 つ (NGP) の合計 2 つあります。
[root@ipaserver ~]# ipa-managed-entries --list -p DMpassword Available Managed Entry Definitions: UPG Definition NGP Definition
- 任意の管理対象エントリープラグインインスタンスを無効にします。以下に例を示します。
[root@ipaserver ~]# ipa-managed-entries -e "UPG Definition" -p DMpassword disable Disabling Plugin
- 389 Directory Server を再起動して、新しいプラグイン設定を読み込みます。
[root@ipaserver ~]# service dirsrv restart
9.9. 一意の UID および GID 番号の割り当て管理
9.9.1. ID 数値の範囲の概要
uidNumber
) およびグループ ID (gidNumber
) にも使用されます。ユーザーとグループで同じ ID が指定される可能性がありますが、ID は異なる属性に設定されているので、競合はありません。ユーザーとグループの両方に同じ ID 番号を使用することで、管理者はユーザープライベートグループを設定できます。この場合に、各ユーザーに一意のシステムグループが作成され、ユーザーとグループ両方に同じ ID 番号が使用されます。
uidNumber
が一意であるかどうかは検証されません。ID を重複させることができます。POSIX エントリーでは、想定されている動作 (非推奨) です。グループエントリーの場合も同様で、重複した gidNumber
を手動でエントリーに割り当てることができます。
9.9.2. インストール中の ID 範囲の割り当ての概要
--idstart
および --idmax
オプションを指定して ipa-server-install を使用し、範囲を定義できます。これらのオプションは必須ではないので、インストール時に設定スクリプトで範囲を無作為に割り当てることができます。
9.9.3. 競合する ID 範囲に関する注記
sssd.conf
ファイル内の min_id
および max_id
オプションを使用して ID 番号の範囲を定義できます。デフォルトの min_id
値は 1
です。ただし、Red Hat は、システム用に予約されている UID と GID 番号との競合を避けるため、この値を 1000
に設定することを推奨しています。
9.9.4. 新しい範囲の追加
dnaNextRange
パラメーターで定義します。以下に例を示します。
ldapmodify -x -D "cn=Directory Manager" -W -h server.example.com -p 389 Enter LDAP Password: ******* dn: cn=POSIX IDs,cn=Distributed Numeric Assignment Plugin,cn=plugins,cn=config changetype: modify add: dnaNextRange dnaNextRange: 123400000-123500000
9.9.5. 変更された UID および GID 番号の修復
[root@server ~]# sss_cache -u jsmith
9.10. ユーザーおよびグループスキーマの管理
詳細 | オブジェクトクラス | |||||
---|---|---|---|---|---|---|
IdM オブジェクトクラス |
| |||||
人物のオブジェクトクラス |
| |||||
Kerberos のオブジェクトクラス |
| |||||
Managed エントリー (テンプレート) のオブジェクトクラス | mepOriginEntry |
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 | 任意 | |
Password | --password [b] | 任意 |
User ID number[c] | --uid | デフォルト |
Group ID number[c] | --gidnumber | デフォルト |
Street address | --street | 任意 |
City | --city | 任意 |
State/Province | --state | 任意 |
Zip code | --postalcode | 任意 |
Telephone number | --phone | 任意 |
Mobile telephone number | --mobile | 任意 |
Pager number | --pager | 任意 |
Fax number | --fax | 任意 |
Organizational unit | --orgunit | 任意 |
Job title | --title | 任意 |
Manager | --manager | 任意 |
Car license | --carlicense | 任意 |
--noprivate | 任意 | |
SSH Keys | --sshpubkey | 任意 |
Additional attributes | --addattr | 任意 |
[a]
必須の属性は、すべてのエントリーで設定する必要があります。オプションの属性は設定が可能で、デフォルトの属性は特定の値を提供しない場合は事前設定の値で自動的に追加されます。
[b]
スクリプトは、引数の値を受け付けずに、新たなパスワードを要求します。
[c]
UID 番号を指定せずにユーザーを作成すると、ユーザーアカウントには、サーバーまたはレプリカの範囲で次に利用可能な ID 番号が自動的に割り当てられます。(数値の範囲は「一意の UID および GID 番号の割り当て管理」で詳述されています。) つまり、UID 番号およびプライベートグループ (設定されている場合) には一意の番号が常に割り当てられることになります。
数値がユーザーエントリーに 手動で 割り当てられると、サーバーでは uidNumber が一意であるかどうかは検証されません。ID を重複させることができます。POSIX エントリーでは、想定されている動作 (非推奨) です。
2 つのエントリーに同じ ID 番号が割り当てられている場合に、検索では、対象の ID 番号の最初のエントリーだけが返されます。ただし、他の属性の検索時や、 ipa user-find --all を使用時には、両方のエントリーが返されます。
|
9.10.1. デフォルトのユーザーおよびグループスキーマの変更
- すべてのオブジェクトクラスとそれらの指定された属性を LDAP サーバーが認識していること。
- エントリーに設定されたデフォルトの属性はすべて、設定済みのオブジェクトクラスにサポートされていること。
9.10.2. カスタムのオブジェクトクラスを新規ユーザーエントリーに適用する
9.10.2.1. Web UI での操作
- カスタムスキーマ要素をすべて、Identity Management が使用する 389 Directory Server インスタンスに追加します。スキーマ要素の追加については、『Directory Server Administrator's Guide』の「スキーマ」の章で説明します。
- IPA Server タブを開きます。
- Configuration サブタブを選択します。
- User Options エリアまでスクロールします。
- ユーザーエリア下部にある Add リンクをクリックして、別のオブジェクトクラスの新規フィールドを追加します。重要設定の更新時は、常に既存のデフォルトオブジェクトクラスを追加してください。これらを含めないと、現行設定は上書きされます。Identity Management で必須のオブジェクトクラスが含まれないと、これ以降にエントリーの追加を試みるとオブジェクトクラス違反で失敗することになります。
- 変更が完了したら、Configuration ページ上部の Update リンクをクリックします。
9.10.2.2. コマンドラインでの操作
- カスタムスキーマ要素をすべて、Identity Management が使用する 389 Directory Server インスタンスに追加します。スキーマ要素の追加については、『Directory Server Administrator's Guide』の「スキーマ」の章で説明します。
- エントリーに追加するオブジェクトクラス一覧に新規オブジェクトクラスを追加します。ユーザーのオブジェクトクラスのオプションは
--userobjectclasses
です。重要設定の更新時は、常に既存のデフォルトオブジェクトクラスを追加してください。これらを含めないと、現行設定は上書きされます。Identity Management で必須のオブジェクトクラスが含まれないと、これ以降にエントリーの追加を試みるとオブジェクトクラス違反で失敗することになります。たとえば、以下のようになります。[bjensen@server ~]$ ipa config-mod
--userobjectclasses=
top,person,organizationalperson,inetorgperson,inetuser,posixaccount, krbprincipalaux,krbticketpolicyaux,ipaobject,ipasshuser,employeeinfo
9.10.3. カスタムのオブジェクトクラスを新規グループエントリーに適用する
9.10.3.1. Web UI での操作
- カスタムスキーマ要素をすべて、Identity Management が使用する 389 Directory Server インスタンスに追加します。スキーマ要素の追加については、『Directory Server Administrator's Guide』の「スキーマ」の章で説明します。
- IPA Server タブを開きます。
- Configuration サブタブを選択します。
- Group Options エリアまでスクロールします。
- Add リンクをクリックして、別のオブジェクトクラスの新規フィールドを追加します。重要設定の更新時は、常に既存のデフォルトオブジェクトクラスを追加してください。これらを含めないと、現行設定は上書きされます。Identity Management で必須のオブジェクトクラスが含まれないと、これ以降にエントリーの追加を試みるとオブジェクトクラス違反で失敗することになります。
- 変更が完了したら、Configuration ページ上部の Update リンクをクリックします。
9.10.3.2. コマンドラインでの操作
- カスタムスキーマ要素をすべて、Identity Management が使用する 389 Directory Server インスタンスに追加します。スキーマ要素の追加については、『Directory Server Administrator's Guide』の「スキーマ」の章で説明します。
- エントリーに追加するオブジェクトクラス一覧に新規オブジェクトクラスを追加します。グループのオブジェクトクラスのオプションは、
--groupobjectclasses
です。重要設定の更新時は、常に既存のデフォルトオブジェクトクラスを追加してください。これらを含めないと、現行設定は上書きされます。Identity Management で必須のオブジェクトクラスが含まれないと、これ以降にエントリーの追加を試みるとオブジェクトクラス違反で失敗することになります。たとえば、以下のようになります。[bjensen@server ~]$ ipa config-mod
--groupobjectclasses=
top,groupofnames,nestedgroup,ipausergroup,ipaobject,ipasshuser,employeegroup
9.10.4. デフォルトのユーザーおよびグループ属性の指定
フィールド | コマンドラインオプション | 説明 |
---|---|---|
ユーザー名の最大長 | --maxusername | ユーザー名の最大長を設定します。デフォルト値は 8 文字です。 |
Root for home directories | --homedirectory | ユーザーのホームディレクトリーに使用するデフォルトのディレクトリーを設定します。デフォルト値は /home です。 |
Default shell | --defaultshell | ユーザーに使用するデフォルトのシェルを設定します。デフォルト値は /bin/sh です。 |
Default user group | --defaultgroup | 新規作成のアカウントを追加するデフォルトグループを設定します。デフォルト値は ipausers で、これは IdM サーバーのインストールプロセスで自動的に作成されます。 |
Default e-mail domain | --emaildomain | 新規アカウントに基づいて電子メールアドレスを作成するために使用する電子メールドメインを設定します。デフォルトは IdM サーバードメインです。 |
Search time limit | --searchtimelimit | サーバー検索結果を返すまでに費やす最長時間を秒単位で設定します。 |
Search size limit | --searchrecordslimit | 返される検索結果の最大数を設定します。 |
User search fields | --usersearch | 検索文字列として使用可能なユーザーエントリー内のフィールドを設定します。記載される属性にはインデックスがその属性のために維持されるので、多く設定しすぎるとサーバーのパフォーマンスに影響が出る場合があります。 |
Group search fields | --groupsearch | 検索文字列として使用可能なグループエントリー内のフィールドを設定します。 |
Certificate subject base | クライアント証明書用に発行先 DN を作成する際に使用するベース DN を設定します。これはサーバーのセットアップ時に設定されます。 | |
Default user object classes | --userobjectclasses | IdM ユーザーアカウントの作成に使用するオブジェクトクラスの一覧を設定します。 |
Default group object classes | --groupobjectclasses | IdM グループアカウントの作成に使用するオブジェクトクラスの一覧を設定します。 |
Password expiration notification | --pwdexpnotify | パスワードの有効期限が切れる何日前にサーバーが通知を送信するかを設定します |
Password plug-in features | ユーザーが使用可能なパスワードの形式を設定します。 |
9.10.4.1. Web UI で属性を表示する
- IPA Server タブを開きます。
- Configuration サブタブを選択します。
- 設定エントリーは、全検索の制限、ユーザーテンプレート、およびグループテンプレートの 3 つのセクションで表示されます。
9.10.4.2. コマンドラインでの属性表示
--all
オプションを使用すると設定すべてが表示されます。
[bjensen@server ~]$ kinit admin [bjensen@server ~]$ ipa config-show --all dn: cn=ipaConfig,cn=etc,dc=example,dc=com Maximum username length: 32 Home directory base: /home Default shell: /bin/sh Default users group: ipausers Default e-mail domain: example.com Search time limit: 2 Search size limit: 100 User search fields: uid,givenname,sn,telephonenumber,ou,title Group search fields: cn,description Enable migration mode: FALSE Certificate Subject base: O=EXAMPLE.COM Default group objectclasses: top, groupofnames, nestedgroup, ipausergroup, ipaobject Default user objectclasses: top, person, organizationalperson, inetorgperson, inetuser, posixaccount, krbprincipalaux, krbticketpolicyaux, ipaobject, ipasshuser Password Expiration Notification (days): 4 Password plugin features: AllowNThash SELinux user map order: guest_u:s0$xguest_u:s0$user_u:s0$staff_u:s0-s0:c0.c1023$unconfined_u:s0-s0:c0.c1023 Default SELinux user: unconfined_u:s0-s0:c0.c1023 Default PAC types: MS-PAC, nfs:NONE cn: ipaConfig objectclass: nsContainer, top, ipaGuiConfig, ipaConfigObject
9.11. ユーザーグループの管理
- ipausers。全ユーザーが含まれます。
- admins。管理ユーザーが含まれます。初期設定されている admin ユーザーはこのグループに属します。
- trusted admins。Active Directory トラストの管理に使用する管理ユーザーが含まれます。
- editors。Web UI で作業するユーザー向けの特別なグループです。このグループは、管理ユーザーの全権限がなくても、他のユーザーのエントリーを 編集 できます。
9.11.1. IdM のグループの種類
- 内部グループ (デフォルト): すべてのメンバーが IdM ドメインに所属します。
- 外部グループ。一部またはすべてのメンバーが IdM ドメイン外の ID ストアに存在します。外部グループには、ローカルシステム、Active Directory ドメイン、またはディレクトリーサービスのいずれかを指定できます。
9.11.2. グループオブジェクトクラス
詳細 | オブジェクトクラス | |||
---|---|---|---|---|
IdM オブジェクトクラス |
| |||
グループオブジェクトクラス | groupofnames |
9.11.2.1. ユーザーグループの作成
9.11.2.1.1. Web UI の使用
- Identity タブを開き、サブタブの User Groups を選択します。
- グループ一覧上部にある Add をクリックします。
- グループの全情報を入力します。
- 一意な名前。これは、IdM ドメインのグループに使用される ID で、作成後に変更できません。この名前にはスペースを含めることはできませんが、アンダースコア (_) のような他の区切り文字は使用できます。
- グループの文字での説明。
- グループが POSIX グループかどうか。エントリーに Linux 固有の情報を追加します。デフォルトでは、明示的に設定されない限り、すべてのグループは POSIX グループになります。POSIX 以外のグループを作成して、Windows または Samba との相互運用性を確保できます。
- グループの GID 番号 (任意)。すべての POSIX グループには GID 番号が必要ですが、IdM では GID 番号は自動的に割り当てられます。競合のリスクがあるため、GID 番号を設定する必要はありません。GID 番号を手動で指定すると、IdM は指定した GID 番号を上書きしません (一意でない場合でも)。
- 「Web UI (グループページ) の使用」で説明されているようにメンバーを選択します。
9.11.2.1.2. コマンドラインの使用
[bjensen@server ~]$ ipa group-add groupName --desc="description" [--nonposix]
--nonposix
という設定オプションがあります。(デフォルトでは、グループはすべて POSIX グループとして作成されます。) Samba などの Windows ユーザーおよびグループおよびプログラムとの相互運用性を確保するため、この --nonposix
オプションを使用して POSIX 以外のグループを作成できます。このオプションは、スクリプトで posixGroup のオブジェクトクラスがエントリーに追加されないように指示します。
[bjensen@server ~]$ ipa group-add examplegroup --desc="for examples" --nonposix ---------------------- Added group "examplegroup" ---------------------- Group name: examplegroup Description: for examples GID: 855800010
[bjensen@server ~]$ ipa group-add Group name: engineering Description: for engineers ------------------------- Added group "engineering" ------------------------- Group name: engineering Description: for engineers GID: 387115842
gidNumber
が一意であるかどうかは検証されません。ID を重複させることができます。POSIX エントリーでは、想定されている動作 (非推奨) です。
9.11.2.2. グループメンバーの追加
9.11.2.2.1. Web UI (グループページ) の使用
- Identity タブを開き、サブタブの User Groups を選択します。
- メンバーを追加するグループ名をクリックします。
- タスクエリア上部にある Add をクリックします。
- 追加するユーザーの名前の横にあるチェックボックスをクリックし、右矢印ボタン () をクリックし、名前を選択項目のボックスに移動します。
9.11.2.2.2. Web UI (ユーザーページ) の使用
- Identity タブを開き、サブタブの ユーザー を選択します。
- 編集するユーザー名をクリックします。
- ユーザーエントリーページの User Groups タブを開きます。
- タスクエリア上部にある Add をクリックします。
- 追加するユーザーのグループ名の横にあるチェックボックスをクリックしてから、右矢印ボタン () をクリックしグループを選択項目のボックスに移動します。
9.11.2.2.3. コマンドラインの使用
[bjensen@server ~]$ ipa group-add-member groupName [--users=list] [--groups=list]
[bjensen@server ~]$ ipa group-add-member engineering --users=jsmith,bjensen,mreynolds Group name: engineering Description: for engineers GID: 387115842 Member users: jsmith,bjensen,mreynolds ------------------------- Number of members added 3 -------------------------
[bjensen@server ~]$ ipa group-add-member engineering --groups=dev,qe1,dev2 Group name: engineering Description: for engineers GID: 387115842 Member groups: dev,qe1,dev2 ------------------------- Number of members added 3 -------------------------
[bjensen@server ~]$ ipa group-show examplegroup Group name: examplegroup Description: for examples GID: 93200002 Member users: jsmith,bjensen,mreynolds Member groups: californiausers Indirect Member users: sbeckett,acalavicci
[bjensen@server ~]$ ipa group-remove-member engineering --users=jsmith Group name: engineering Description: for engineers GID: 855800009 Member users: bjensen,mreynolds --------------------------- Number of members removed 1 ---------------------------
9.11.2.2.4. グループの直接メンバーおよび間接メンバーの表示
- 直接メンバー: グループに明示的に追加されます。
- 間接メンバー: 別のユーザーグループのメンバーではあるものの、このユーザーグループがこの対象グループのメンバーであるため、このグループのメンバーとなっています。
図9.4 グループの直接および間接メンバー
9.11.2.3. ユーザーグループの削除
9.11.2.3.1. Web UI の使用
- Identity タブを開き、サブタブの User Groups を選択します。
- 削除するグループ名の横にあるチェックボックスを選択します。
- タスクエリアの上部にある Delete リンクをクリックします。
- プロンプトが表示されたら、削除を確定します。
9.11.2.3.2. コマンドラインの使用
[bjensen@server ~]$ ipa group-del examplegroup
9.11.3. ユーザーとグループの検索
9.11.3.1. 検索での制限設定
9.11.3.1.1. 検索制限の種類および適用先
- IdM サーバーの検索制限設定。これは、IdM サーバー自体の設定で、通常のページを表示するために 全 IdM クライアント、IdM CLI ツール、および IdM Web UI からサーバーに送信されるすべてのリクエストに適用されます。デフォルトでは、エントリーの上限は 100 件となっています。
- IdM サーバーの時間制限設定。時間制限は、検索サイズの制限と同様に、IdM サーバーでの検索実行にかける最大時間を設定します。制限に達すると、サーバーは検索を停止し、その時点で返されたすべてのエントリーを返します。デフォルトでは、この制限は 2 秒です。
- ページサイズの制限。厳密には検索制限ではありませんが、ページサイズの制限で、ページごとに返されるエントリーの数を制限します。IdM サーバーは、検索のエントリー上限数を返し、次にそれをソートしてページにエントリーを 20 件表示します。ページ結果を使用することで、結果を分かりやすく、見やすくします。この数は全検索に対して 20 件までとハードコード化されています。
- LDAP 検索の制限 (--pkey オプション)。UI で実行した全検索、
--pkey
オプションを使用した CLI 検索は、IdM サーバー設定に指定されている検索制限を上書きし、基盤の LDAP ディレクトリーに指定されている検索制限を使用します。デフォルトでは、エントリーの上限は 2000 件となっています。この値を変更するには、389 Directory Server 設定を編集します。
9.11.3.1.2. IdM 検索制限の設定
9.11.3.1.2.1. Web UI の使用
- IPA Server タブを開きます。
- Configuration サブタブを選択します。
- Search Options 領域までスクロールします。
- 検索制限の設定を変更します。
- 検索サイズ制限: 返される検索結果の最大数を設定します。
- 検索時間制限: サーバー検索結果を返すまでに費やす最長時間を秒単位で設定します。
ヒント時間制限またはサイズ制限の値を -1 に設定すると、検索に制限がないことを意味します。 - 変更が完了したら、Configuration ページ上部の Update リンクをクリックします。
9.11.3.1.2.2. コマンドラインの使用
[bjensen@server ~]$ ipa config-mod --searchtimelimit=5 --searchrecordslimit=500 Max. username length: 32 Home directory base: /home Default shell: /bin/sh Default users group: ipausers Default e-mail domain for new users: example.com Search time limit: 5 Search size limit: 50 User search fields: uid,givenname,sn,telephonenumber,ou,title Group search fields: cn,description Enable migration mode: FALSE Certificate Subject base: O=EXAMPLE.COM Password Expiration Notification (days): 4
9.11.3.1.3. 検索のデフォルトの上書き
--sizelimit
および --timelimit
オプションは、対象コマンドの実行時にそれぞれ指定して、別のサイズ、時間を設定できます。どのような結果が必要かによって、制限を増やしたり減らしたりできます。
[jsmith@ipaserver ~]$ ipa user-find smith --timelimit=120
9.11.3.2. 検索属性の設定
9.11.3.2.1. 検索でチェックされるデフォルトの属性
ユーザー検索の属性 | |
First name | Last name |
Login ID | Job title |
Organizational unit | Phone number |
グループ検索の属性 | |
Name | 詳細 |
9.11.3.2.2. ユーザー検索属性の変更
9.11.3.2.2.1. Web UI での操作
- IPA Server タブを開きます。
- Configuration サブタブを選択します。
- User Options エリアまでスクロールします。
- 他の検索属性は、User search fields フィールドにコンマ区切りの一覧として追加します。
- 変更が完了したら、Configuration ページ上部の Update リンクをクリックします。
9.11.3.2.2.2. コマンドラインでの操作
--usersearch
オプションを使用してユーザー検索の属性を設定します。
[bjensen@server ~]$ ipa config-mod --usersearch=uid,givenname,sn,telephonenumber,ou,title
9.11.3.2.3. グループ検索属性の変更
9.11.3.2.3.1. Web UI での操作
- IPA Server タブを開きます。
- Configuration サブタブを選択します。
- Group Options エリアまでスクロールします。
- 他の検索属性は、Group search fields フィールドにコンマ区切りの一覧として追加します。
- 変更が完了したら、Configuration ページ上部の Update リンクをクリックします。
9.11.3.2.3.2. コマンドラインでの操作
--groupsearch
オプションを使用してグループ検索の属性を設定します。
[bjensen@server ~]$ ipa config-mod --groupsearch=cn,description
9.11.3.2.4. 検索結果で返される属性の制限
9.11.3.3. タイプを基にしたグループ検索
--private
オプションを使用すると、プライベートグループだけに検索結果を絞り込みます。
[root@server ~]# ipa group-find --private --------------- 1 group matched --------------- Group name: jsmith Description: User private group for jsmith GID: 1084600001 ---------------------------- Number of entries returned 1 ----------------------------
[root@server ~]# ipa group-find --user=jsmith --------------- 1 group matched --------------- Group name: ipausers Description: Default group for all users Member users: jsmith ---------------------------- Number of entries returned 1 ----------------------------
[root@server ~]# ipa group-find --no-user=jsmith ---------------- 3 groups matched ---------------- Group name: admins Description: Account administrators group GID: 1084600000 Member users: admin Group name: editors Description: Limited admins who can edit other users GID: 1084600002 Group name: trust admins Description: Trusts administrators group Member users: admin ---------------------------- Number of entries returned 3 ----------------------------
オプション | 条件の説明 |
---|---|
--private | プライベートグループのみを表示します。 |
--gid | 指定した GID に完全一致するグループのみを表示します。 |
--group-name | 指定の名前または部分的な名前が含まれるグループのみを表示します。 |
--users、--no-users | メンバーとして指定のユーザーが含まれる (または含まれない) グループのみを表示します。 |
--in-hbacrules、--not-inhbac-rules | 指定のホストベースのアクセス制御ルールに属するグループ (または --not-in オプションの場合はルールに属さないグループ) のみを表示します。指定した sudo ルールおよびロールに属するグループを表示する (またはしない) オプションと似ています。 |
--in-groups、--not-in-groups | 別のグループに属するグループのみを表示します。指定したグループ (または --not-in オプションの場合は属さないグループ) だけを表示します。指定した netgroup に属するグループを表示する (またはしない) オプションと似ています。 |
第10章 アイデンティティー: ホストの管理
- DNS エントリーおよび設定
- マシン認証
- (ドメインサービスに影響する) ホスト名の変更
10.1. ホスト、サービス、およびマシン ID と認証
- ホストに関連付けられたサービスエントリー
- ホストとサービスのプリンシパル
- アクセス制御ルール
- 物理的位置やオペレーティングシステムなどのマシンについての情報
- DNS
- Kerberos
- 証明書管理
- DNS ドメインへの参加 (マシン登録)
- DNS エントリーおよびゾーンの管理
- マシン認証の管理
- SSH 鍵。ホストの SSH 公開キーが作成され、ホストエントリーにアップロードされます。そこから、SSSD (System Security Services Daemon) は Identity Management を ID プロバイダーとして使用し、OpenSSH およびその他のサービスと一緒に機能して、IdM の中央にある公開鍵を参照できます。詳細は、「ホストの公開 SSH 鍵の管理」および『Red Hat Enterprise Linux デプロイメントガイド』を参照してください。
- キーテーブル (または キータブ。ユーザーパスワードに多少類似する対称キー) およびマシン証明書。Kerberos チケットは Kerberos サービスの一部として生成され、ポリシーはサーバーが定義します。初期の Kerberos チケットの付与、Kerberos 証明書の更新、Kerberos セッションの破棄はすべて IdM サービスによって処理されます。Kerberos の管理は 20章ポリシー: Kerberos ドメインの管理 で説明されています。
- 機械の証明書。この場合には、マシンは IdM サーバーの認証局により発行され、IdM の Directory Server に保存される SSL 証明書を使用します。次に、証明書はマシンに送信され、サーバーに対する認証時に提示されます。「付録B certmonger を使った作業」で説明されているように、クライアントでは、証明書は certmonger というサービスが管理します。
10.2. ホストエントリー設定のプロパティー
UI フィールド | コマンドラインオプション | 説明 |
---|---|---|
Description | --desc=description | ホストの説明。 |
Locality | --locality=locality | ホストの位置情報 |
Location | --location=location | データセンターラックなど、ホストの位置情報 |
Platform | --platform=string | ホストのハードウェアまたはアーキテクチャー |
Operating system | --os=string | ホストのオペレーティングシステムおよびバージョン |
MAC アドレス | --macaddress=address | ホストの MAC アドレス。これは多値属性です。MAC アドレスは、NIS プラグインにより、ホスト用の NIS の ethers マップを作成するために使用されます。 |
SSH 公開鍵 | --sshpubkey=string | ホストの完全 SSH 公開鍵。これは複数値の属性であるため、複数の鍵を設定できます。 |
Principal name (編集不可) | --principalname=principal | ホストの Kerberos プリンシパル名。-p に別のプリンシパルを明示的に設定しない限り、クライアントのインストール時にホスト名のデフォルト値に設定されます。これはコマンドラインツールを使用して変更できますが、UI で変更することはできません。 |
Set One-Time Password | --password=string | 一括登録で使用可能なホストのパスワードを設定します。 |
- | --random | 一括登録で使用されるランダムなパスワードを生成します。 |
- | --certificate=string | ホストの証明書ブロブ。 |
- | --updatedns | これは IP アドレス変更時にホストが DNS エントリーを動的に更新できるかどうかを設定する属性切り替え。 |
10.3. ホストエントリーの無効化および再有効化
10.3.1. ホストエントリーの無効化
[jsmith@ipaserver ~]$ kinit admin [jsmith@ipaserver ~]$ ipa host-disable server.example.com
10.3.2. ホストの再有効化
-s
オプションは、キータブを要求する IdM サーバーを、-p
はプリンシパル名を、-k
はキータブを保存するファイルを指定します。
[jsmith@ipaserver ~]$ ipa-getkeytab -s ipaserver.example.com -p host/server.example.com -k /etc/krb5.keytab -D fqdn=server.example.com,cn=computers,cn=accounts,dc=example,dc=com -w password
-D
および -w
) なしで実行できます。IdM ユーザーは、Kerberos 認証情報を使用してドメインへの認証を行います。無効化されたホストでコマンドを直接実行するには、LDAP 認証情報を指定してから IdM サーバーに認証します。認証情報は、再度有効にするホストまたはサービスに一致する必要があります。
10.4. ホストの公開 SSH 鍵の管理
known_hosts
ファイルに保存します。リモートのマシンがターゲットマシンにアクセスを再度試みると、ターゲットマシンは known_hosts
ファイルをチェックして、認証済みホストに自動的にアクセスを許可します。
known_hosts
ファイルは、ホストエントリーをホスト IP アドレス、ホスト名、およびキーの 3 項目で保存します。IP アドレスが変更されたり (仮想環境やデータセンターでは一般的)、キーが更新されたりすると、このファイルはすぐに無効になってしまいます。- SSH 鍵は、環境内の全マシンに手動かつ個別に配布する必要があります。
- 管理者は設定に追加するホストキーを許可する必要がありますが、ホストまたはキー発行者を適切に検証することが困難なことから、セキュリティー問題が発生する可能性があります。
10.4.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
10.4.2. ipa-client-install および OpenSSH
--ssh-trust-dns
というクライアント設定オプションがあり、ipa-client-install コマンドに指定して実行でき、キーのフィンガープリントを格納する IdM DNS レコードを OpenSSH が信頼するように自動設定します。
--no-sshd
オプションを使用して OpenSSH を無効にできます。この設定により、インストールスクリプトで OpenSSH サーバーを設定できなくなります。
--no-dns-sshfp
というオプションを使用すると、ホストが独自の DNS エントリーで DNS SSHFP レコードを作成できなくなります。このオプションは、--no-sshd
オプションと合わせて使用することも、なしでも使用できます。
10.4.3. ホスト SSH 鍵の Web UI でのアップロード
- ホストのキーは、
~/.ssh/known_hosts
から取得できます。たとえば、以下のようになります。server.example.com,1.2.3.4 ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEApvjBvSFSkTU0WQW4eOweeo0DZZ08F9Ud21xlLy6FOhzwpXFGIyxvXZ52+siHBHbbqGL5+14N7UvElruyslIHx9LYUR/pPKSMXCGyboLy5aTNl5OQ5EHwrhVnFDIKXkvp45945R7SKYCUtRumm0Iw6wq0XD4o+ILeVbV3wmcB1bXs36ZvC/M6riefn9PcJmh6vNCvIsbMY6S+FhkWUTTiOXJjUDYRLlwM273FfWhzHK+SSQXeBp/zIn1gFvJhSZMRi9HZpDoqxLbBB9QIdIw6U4MIjNmKsSI/ASpkFm2GuQ7ZK9KuMItY2AoCuIRmRAdF8iYNHBTXNfFurGogXwRDjQ==
必要に応じて、ホストキーを生成します。OpenSSH ツールを使用する場合は、空白のパスフレーズを使用し、キーをユーザーの~/.ssh/
ディレクトリー以外の場所に保存して、既存のキーを上書きしないようにします。[jsmith@server ~]$ ssh-keygen -t rsa -C "server.example.com,1.2.3.4" Generating public/private rsa key pair. Enter file in which to save the key (/home/jsmith/.ssh/id_rsa): /home/jsmith/.ssh/host_keys Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /home/jsmith/.ssh/host_keys. Your public key has been saved in /home/jsmith/.ssh/host_keys.pub. The key fingerprint is: 4f:61:ee:2c:f7:d7:da:41:17:93:de:1d:19:ac:2e:c8 server.example.com The key's randomart image is: +--[ RSA 2048]----+ | .. | | .+| | o .* | | o . .. *| | S + . o+| | E . .. .| | . = . o | | o . ..o| | .....| +-----------------+
- 公開鍵をキーファイルからコピーします。完全なキーエントリーは、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 タブを開き、サブタブの ホスト を選択します。
- 編集するホスト名をクリックします。
- Settings タブの Host Settings エリアで、SSH public keys: Add リンクをクリックします。
- UI で新しいリンク (New: key not set Show/Set key) が開きます。Show/Set key リンクをクリックします。
- ホストの公開鍵を貼り付けて、ボタンをクリックします。SSH public keys フィールドに New: key set と表示されるようになります。Show/Set キー のリンクをクリックすると、送信したキーが表示されます。
- 複数のキーをアップロードするには、公開鍵リストの下にある Add をクリックして、他のキーをアップロードします。
- すべてのキーが送信されたら、ホストページ上部の Update ボタンをクリックして変更を保存します。
図10.1 保存された公開鍵
10.4.4. コマンドラインからのホストキーの追加
ipa-client-install
コマンドで RSA と DSS ホストキーが作成されます。
--sshpubkey
オプションを指定して host-mod コマンドを実行し、64 ビットにエンコードされた公開鍵をホストエントリーにアップロードします。ホストキーを追加するとホストの DNS SSHFP エントリーも変更されるので、--updatedns
オプションも使ってホストの DNS エントリーも更新します。たとえば、以下のようになります。[jsmith@server ~]$ ipa host-mod --sshpubkey="ssh-rsa 12345abcde==" --updatedns host1.example.com
実際のキーでは、キーはこの例よりも長く、通常は末尾が等号 (=) になります。複数のキーをアップロードするには、--sshpubkey
オプション 1 つでコンマ区切りのキー一覧を指定します。--sshpubkey="12345abcde==,key2==,key3=="
ヒントホストには複数の公開鍵を指定できます。- ホストキーをアップロードしたら、Identity Management を ID ドメインの 1 つとして使用するよう SSSD を設定し、OpenSSH がホストキー管理に SSSD ツールを使用するよう設定します。これは、『Red Hat Enterprise Linux デプロイメントガイド』で説明しています。
10.4.5. ホストキーの削除
- Identity タブを開き、サブタブの ホスト を選択します。
- 編集するホスト名をクリックします。
- Settings タブの Host Settings エリアを開きます。
- 削除するキーのフィンガープリントの横にある Delete のリンクをクリックします。
- 変更を保存するには、ホストページの上部にある Update リンクをクリックします。
--sshpubkey=
を空の値に指定して ipa host-mod を実行します。これで、対象ホストの公開鍵が すべて 削除されます。また、ホストの DNS エントリーの更新には、--updatedns
オプションを使用します。たとえば、以下のようになります。
[jsmith@server ~]$ kinit admin [jsmith@server ~]$ ipa host-mod --sshpubkey= --updatedns host1.example.com
10.5. ホストの Ethers 情報の設定
cn=server,ou=ethers,dc=example,dc=com
- ホストエントリーに 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 ~]# getnt ethers server.example.com
10.6. マシンの名前変更および IdM クライアントオプションの再設定
- マシンで実行されているサービスを特定します。これらのファイルは、マシンの再登録時に作成し直す必要があります。
# ipa service-find server.example.com
各ホストには、サービス一覧に表示されないデフォルトのサービスがあります。このサービスは、「ホストサービス」と呼ばれます。ホストサービスのサービスプリンシパルは、host/<hostname>
です (例:host/server.example.com
)。このプリンシパルは ホストプリンシパル とも呼ばれます。 - マシンが所属するすべてのホストグループを特定します。
[root@client ~]# kinit admin [root@client ~]# ipa hostgroup-find server.example.com
- 証明書が関連付けられているサービスを特定します。ldapsearch コマンドを使用して、IdM LDAP データベースのエントリーを直接チェックすることでサービスの特定ができます。
[root@client ~]# ldapsearch -x -b "cn=accounts,dc=example,dc=com" "(&(objectclass=ipaservice)(userCertificate=*))" krbPrincipalName -D "cn=directory manager" -w secret -h ipaserver.example.com -p 389
- (ホストプリンシパルに加えて) サービスプリンシパルの場合は、
server.example.com
にある対応のキータブの場所を判断します。サービスごとにキータブの場所が異なりますが、IdM にはこの情報は保存されません。クライアントシステム上の各サービスにはldap/server.example.com@EXAMPLE.COM
など、service_name/hostname@REALM の形式で Kerberos プリンシパルが含まれています。 - IdM ドメインからクライアントマシンの登録を解除します。
[root@client ~]# ipa-client-install --uninstall
/etc/krb5.keytab
以外の各キータブについては、古いプリンシパルを削除します。[root@client ~]# ipa-rmkeytab -k /path/to/keytab -r EXAMPLE.COM
- IdM サーバーで、IdM 管理者としてホストエントリーを削除します。これにより、すべてのサービスが削除され、そのホストに発行されたすべての証明書が無効になります。
[root@server ~]# kinit admin [root@server ~]# ipa host-del server.example.com
この時点で、ホストは IdM から完全に削除されました。 - マシンの名前を変更します。
- IdM でシステムを再登録します。
[root@client ~]# ipa-client-install
再登録することで、/etc/krb5.keytab
に、新規ホスト名でホストプリンシパルが生成されます。 - IdM サーバーで、全サービスに対して新しいキータブを追加します。
[root@server ~]# ipa service-add serviceName/new-hostname
- サービスの証明書を生成するには、certmonger または IdM の管理ツールを使用します。
- 該当するホストグループにホストを再度追加します。
10.7. ホストグループの管理
10.7.1. ホストグループの作成
10.7.1.1. Web UI でホストグループの作成
- Identity タブを開き、サブタブの Host Groups を選択します。
- グループ一覧上部にある Add をクリックします。
- グループの名前と説明を入力します。
- 「Web UI でホストグループメンバーの追加」で説明されているようにメンバーを選択します。
10.7.1.2. コマンドラインでのホストグループの作成
$ ipa hostgroup-add groupName --desc="description"
10.7.2. ホストグループメンバーの追加
10.7.2.1. グループメンバーの表示および変更
10.7.2.2. Web UI でホストグループメンバーの追加
- Identity タブを開き、サブタブの Host Groups を選択します。
- メンバーを追加するグループ名をクリックします。
- タスクエリア上部にある Add をクリックします。
- 追加するホストの名前の横にあるチェックボックスをクリックし、右矢印ボタン () をクリックし、ホストを選択項目のボックスに移動します。
10.7.2.3. コマンドラインでのホストグループメンバーの追加
$ ipa hostgroup-add-member groupName [--hosts=list] [--hostgroups=list]
$ ipa hostgroup-add-member caligroup --hosts=ipaserver.example.com,client1.example.com,client2.example.com Group name: caligroup Description: for machines in california GID: 387115842 Member hosts: ipaserver.example.com,client1.example.com,client2.example.com ------------------------- Number of members added 3 -------------------------
$ ipa hostgroup-add-member caligroup --groups=mountainview,sandiego Group name: caligroup Description: for machines in california GID: 387115842 Member groups: mountainview,sandiego ------------------------- Number of members added 2 -------------------------
第11章 アイデンティティー: サービスの管理
- DNS
- Kerberos
- 証明書管理
11.1. サービスエントリーおよびキータブの追加と編集
/etc/httpd/conf/ipa.keytab
に HTTP キータブに保存します。
ipa.keytab
に保存され、そのキータブファイルが削除された場合には、元のキーも削除されてしまうので、IdM Web UI は機能しなくなります。
/etc/krb5.keytab
を避けてください。このファイルにはサービス固有のキータブを含めるべきではありません。各サービスはキータブを特定の場所に保存し、そのサービスのみがキータブにアクセスできるようにアクセス権限 (場合によっては追加で SELinux ルール) を設定します。
11.1.1. Web UI でのサービスとキータブの追加
- Identity タブを開き、Services サブタブを選択します。
- サービス一覧の上部にある Add リンクをクリックします。
- ドロップダウンメニューからサービスタイプを選択し、名前を付けます。
- サービスが実行される IdM ホストのホスト名を選択します。ホスト名を使用して、完全なサービスプリンシパル名を構成します。
- Add ボタンをクリックして、新しいサービスプリンシパルを保存します。
- ipa-getkeytab コマンドを使用し、サービスプリンシパルの新規キータブを生成して割り当てます。
[root@ipaserver ~]# # ipa-getkeytab -s ipaserver.example.com -p HTTP/server.example.com -k /etc/httpd/conf/krb5.keytab -e aes256-cts
- レルム名はオプションです。IdM サーバーは、設定される Kerberos レルムを自動的に追加します。別のレルムは指定できません。
- Kerberos と連携させるには、DNS A レコードに対してホスト名を解決する必要があります。
--force
フラグを使用して強制的にプリンシパルを作成することができます。 -e
引数を指定すると、コンマ区切りの暗号化タイプの一覧をキータブに追加できます。これは、デフォルトの暗号化タイプより優先されます。
警告新たなキーを作成すると、指定されたプリンシパルのシークレットがリセットされます。つまり、そのプリンシパルの他のキータブすべてが無効になります。
11.1.2. コマンドラインでのサービスとキータブの追加
- サービスプリンシパルを作成します。サービスは、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 コマンドを使用して、サービスキータブファイルを作成します。このコマンドは、IdM ドメイン内のクライアント上で実行します。(実際には、IdM サーバーまたはクライアント上でコマンドを実行して、キーを適切なマシンにコピーできます。ただし、サービスが作成されるマシン上でこのコマンドを実行することが最もシンプルな方法です。)このコマンドには、Kerberos サービスプリンシパル (
-p
)、IdM サーバー名 (-s
)、書き込みファイル (-k
)、および暗号化方法 (-e
) が必要です。キータブをサービスの適切なディレクトリーにコピーしてください。以下に例を示します。# ipa-getkeytab -s server.example.com -p HTTP/server.example.com -k /etc/httpd/conf/krb5.keytab -e aes256-cts
- レルム名はオプションです。IdM サーバーは、設定される Kerberos レルムを自動的に追加します。別のレルムは指定できません。
- Kerberos と連携させるには、DNS A レコードに対してホスト名を解決する必要があります。
--force
フラグを使用して強制的にプリンシパルを作成することができます。 -e
引数を指定すると、コンマ区切りの暗号化タイプの一覧をキータブに追加できます。これは、デフォルトの暗号化タイプより優先されます。
警告ipa-getkeytab コマンドは、指定されたプリンシパルのシークレットをリセットします。つまり、そのプリンシパルの他のキータブすべてが無効になります。
11.2. サービスおよびサービスの証明書の追加
11.2.1. Web UI でのサービスおよび証明書の追加
- Identity タブを開き、Services サブタブを選択します。
- サービス一覧の上部にある Add リンクをクリックします。
- ドロップダウンメニューからサービスタイプを選択し、名前を付けます。
- サービスが実行される IdM ホストのホスト名を選択します。ホスト名を使用して、完全なサービスプリンシパル名を構成します。
- Add and Edit ボタンをクリックして、サービスエントリーページに直接移動します。
- ページの下部にある Service Certificate セクションまでスクロールします。
- New Certificate ボタンをクリックしてサービス証明書を作成します。
11.2.2. コマンドラインでのサービスおよび証明書の追加
- サービスプリンシパルを作成します。サービスは、service/FQDN などの名前で認識されます。
[jsmith@ipaserver ~]$ kinit admin [jsmith@ipaserver ~]$ ipa service-add serviceName/hostname
以下に例を示します。$ ipa service-add HTTP/server.example.com ------------------------------------------------------- Added service "HTTP/server.example.com@EXAMPLE.COM" ------------------------------------------------------- Principal: HTTP/server.example.com@EXAMPLE.COM Managed by: ipaserver.example.com
- サービスの証明書を作成します。キータブをサービスの適切なディレクトリーにコピーしてください。以下に例を示します。
$ ipa cert-request --principal=HTTP/web.example.com example.csr
ヒント--add
オプションを使用して、証明書の要求時にサービスを自動作成します。$ ipa-getcert request -d /etc/httpd/alias -n Server-Cert -K HTTP/client1.example.com -N 'CN=client1.example.com,O=EXAMPLE.COM'
11.3. NSS データベースでの証明書の保存
- NSS データベースを作成します。
$ certutil -N -d /path/to/database/dir
- NSS ツール (certutil) を使用して証明書を要求します。
$ certutil -R -s "CN=client1.example.com,O=EXAMPLE.COM" -d /path/to/database/dir -a > example.csr
11.4. クラスタサービスの設定
- クラスター内の全ホストを IdM ドメインに登録します。
- サービスプリンシパルを作成し、必要なキータブを生成します。
/etc/krb5.keytab
にあるホストキータブなど、ホスト上のサービスに設定された全キータブを収集します。- ktutil コマンドを使用して、全キータブファイルのコンテンツを含む単一のキータブファイルを作成します。
- 各ファイルで rkt コマンドを使用してそのファイルからキーを読み取ります。
- 新規キータブファイルに読み込まれたキーすべてを書き込むには、wkt コマンドを使用します。
- 各ホスト上のキータブファイルを新たに作成した結合キータブファイルで置き換えます。
- この時点で、このクラスター内の各ホストは他のホストに偽装することができます。
- サービスによっては、追加の設定を行い、障害のあるサービスから引き継いだ時にリセットされないクラスターのメンバーに対応する必要がある場合があります。
sshd
の場合は、/etc/ssh/sshd_config
にGSSAPIStrictAcceptorCheck no
を設定します。mod_auth_kerb
の場合には、/etc/httpd/conf.d/auth_kerb.conf
にKrbServiceName Any
を設定し ます。
11.5. 複数サービスでの同一サービスプリンシパルの使用
- ipa-getkeytab コマンドを使用してサービスプリンシパルを取得します。
# ipa-getkeytab -s kdc.example.com -p HTTP/server.example.com -k /etc/httpd/conf/krb5.keytab -e aes256-cts
- 複数サーバーまたはサービスに同一ファイルを使用するよう指示するか、必要に応じてそのファイルを個別サーバーにコピーします。
11.6. サービスエントリーの無効化および再有効化
11.6.1. サービスエントリーの無効化
[jsmith@ipaserver ~]$ kinit admin $ ipa service-disable http/server.example.com
11.6.2. サービスの再有効化
-s
オプションは、キータブを要求する IdM サーバーを、-p
はプリンシパル名を、-k
はキータブを保存するファイルを指定します。
[root@ipaserver ~]# ipa-getkeytab -s ipaserver.example.com -p HTTP/server.example.com -k /etc/httpd/conf/krb5.keytab -e aes256-cts
-D
および -w
) なしで実行できます。IdM ユーザーは、Kerberos 認証情報を使用してドメインへの認証を行います。無効化されたホストでコマンドを直接実行するには、LDAP 認証情報を指定して IdM サーバーへの認証を行います。認証情報は、再度有効にするホストまたはサービスに一致する必要があります。
第12章 アイデンティティー: ホストおよびサービスへのアクセス委譲
managedby
エントリーがあり、これにホストやサービスが管理可能なものが記載されています。デフォルトでは、ホストはホスト自体とそのサービスすべてを管理できます。また、適切な委譲更新や、適切な managedby
エントリーを指定して、ホストが他のホストや他のホスト上のサービスを管理できるようにすることも可能です。
図12.1 ホストおよびサービスの委譲
12.1. サービス管理の委譲
# ipa service-add-host principal --hosts=hostnames
# ipa service-add-host http/web.example.com --hosts=client1.example.com
# kinit -kt /etc/krb5.keytab host/`hostname` # ipa-getkeytab -s `hostname` -k /tmp/test.keytab -p http/web.example.com Keytab successfully retrieved and stored in: /tmp/test.keytab
# ipa cert-request --add --principal=http/web.example.com web.csr Certificate: MIICETCCAXqgA...[snip] Subject: CN=web.example.com,O=EXAMPLE.COM Issuer: CN=EXAMPLE.COM Certificate Authority Not Before: Tue Feb 08 18:51:51 2011 UTC Not After: Mon Feb 08 18:51:51 2016 UTC Fingerprint (MD5): c1:46:8b:29:51:a6:4c:11:cd:81:cb:9d:7c:5e:84:d5 Fingerprint (SHA1): 01:43:bc:fa:b9:d8:30:35:ee:b6:54:dd:a4:e7:d2:11:b1:9d:bc:38 Serial number: 1005
12.2. ホスト管理の委譲
- 管理者ユーザーとしてログインします。
# kinit admin
managedby
エントリーを追加します。たとえば、以下は権限を client2 から client1 に 委譲します。# ipa host-add-managedby client2.example.com --hosts=client1.example.com
- ホストの
client1
としてチケットを取得してから、client2
のキータブを取得します。# kinit -kt /etc/krb5.keytab host/`hostname` # ipa-getkeytab -s `hostname` -k /tmp/client2.keytab -p host/client2.example.com Keytab successfully retrieved and stored in: /tmp/client2.keytab
12.3. Web UI を使ったホストまたはサービス管理の委譲
- Identity タブを開き、Hosts または Services サブタブを選択します。
- 委譲管理の付与先となる ホストもしくはサービス名をクリックします。
- ホストまたはサービスエントリーの右端にある Hosts サブタブをクリックします。このタブでは、選択したホストまたはサービスを 管理できる ホストが表示されます。
- 一覧上部にある Add をクリックします。
- ホスト/サービスの管理を委譲する先のホスト名の横にあるチェックボックスをクリックします。右矢印 (を クリックし、ホストを選択ボックスに移動します。
12.4. 委譲サービスへのアクセス
host
となります。
-k
オプションを指定してキータブを読み込み、-t
オプションでキータブを指定します。
# kinit -kt /etc/krb5.keytab host/ipa.example.com@EXAMPLE.COM
# kinit -kt /etc/httpd/conf/krb5.keytab http/ipa.example.com@EXAMPLE.COM
第13章 アイデンティティー: NIS ドメインおよびネットグループとの統合
13.1. NIS および Identity Management の概要
nss_ldap
や SSSD などのモジュールが、暗号化された LDAP 接続を使用してオブジェクトを取得します。
host,user,domainnetgroup トリプルは、ユーザーまたはホストをドメインに関連付けますが、ユーザーとホスト間での関連付けはありません。したがって、通常トリプルでは、明確性および管理性を向上するためにホストまたはユーザーを定義します。
host.example.com,,nisdomain.example.com -,jsmith,nisdomain.example.com
memberUser
パラメーターで識別されます。同様に、ホストは単一ホストまたはホストグループのいずれかになります。これらは memberHost
属性で識別されます。
dn: ipaUniqueID=d4453480-cc53-11dd-ad8b-0800200c9a66,cn=ng,cn=accounts,... objectclass: top objectclass: ipaAssociation objectclass: ipaNISNetgroup ipaUniqueID: d4453480-cc53-11dd-ad8b-0800200c9a66 cn: netgroup1 memberHost: fqdn=host1.example.com,cn=computers,cn=accounts,... memberHost: cn=VirtGuests,cn=hostgroups,cn=accounts,... memberUser: cn=jsmith,cn=users,cn=accounts,... memberUser: cn=bjensen,cn=users,cn=accounts,... memberUser: cn=Engineering,cn=groups,cn=accounts,... nisDomainName: nisdomain.example.com
# ipa netgroup-show netgroup1 Netgroup name: netgroup1 Description: my netgroup NIS domain name: nisdomain Member User: jsmith Member User: bjensen Member User: Engineering Member Host: host1.example.com Member Host: VirtGuests
13.2. Identity Management の NIS ポートの設定
- NIS リスナーと互換性プラグインを有効にします。
[root@ipaserver ~]# ipa-nis-manage enable [root@ipaserver ~]# ipa-compat-manage enable
- プラグイン設定を編集し、ポート番号を引数として追加します。たとえば、ポートを 514 に設定するには、以下を実行します。
[root@ipaserver ~]# ldapmodify -x -D 'cn=directory manager' -w secret dn: cn=NIS Server,cn=plugins,cn=config changetype: modify add: nsslapd-pluginarg0 nsslapd-pluginarg0: 514 modifying entry "cn=NIS Server,cn=plugins,cn=config"
- Directory Server を再起動して、新しいプラグインの設定を読み込みます。
[root@ipaserver ~]# service dirsrv restart
13.3. Netgroups の作成
13.3.1. Netgroup の追加
13.3.1.1. Web UI の使用
- Identity タブを開き、Netgroups サブタブを選択します。
- netgroups 一覧の上部にある Add をクリックします。
- netgroup に一意の名前と説明の両方を入力します。名前と説明の両方が必要です。グループ名は、IdM ドメインの netgroup に使用する IDで、作成後に変更できません。この名前にはスペースを含めることはできませんが、アンダースコア (_) のような他の区切り文字は使用できます。
- 任意で、netgroup の NIS ドメインを設定します。デフォルトではこれは IdM ドメインですが、変更できます。
- Settings タブをクリックします。
- NIS domain name フィールドで別の NIS ドメイン名を入力します。NIS domain name フィールドでは、netgroup のトリプルに表示されるドメインを設定します。Identity Management リスナーが応答する NIS ドメインには影響は ありません。
- 「Web UI の使用」にあるように、メンバーを追加します。
13.3.1.2. コマンドラインの使用
$ ipa netgroup-add --desc="description" [--nisdomain=domainName] groupName
# ipa netgroup-add --desc="my new netgroup" example-netgroup # ipa netgroup-add-member --hosts=ipa.example.com example-netgroup # ypcat -d example.com -h ipa.example.com netgroup (ipa.example.com,-,example.com)
--nisdomain
オプションは、netgroup トリプルに表示されるドメインを設定します。Identity Management リスナーが応答する NIS ドメインには影響は ありません。
13.3.2. Netgroup メンバーの追加
13.3.2.1. Web UI の使用
- Identity タブを開き、Netgroups サブタブを選択します。
- メンバーを追加する netgroup 名をクリックします。
- 追加する netgroup メンバータイプのタブを選択します。netgroup は、ユーザー、ユーザーグループ、ホスト、ホストグループ、およびその他の netgroup をメンバーとして指定できます。
- タスクエリア上部にある Add をクリックします。
- 追加するユーザーの名前の横にあるチェックボックスをクリックし、右矢印ボタン () をクリックし、名前を選択項目のボックスに移動します。
13.3.2.2. コマンドラインの使用
# ipa netgroup-add-member --users=users --groups=groups --hosts=hosts --hostgroups=hostGroups --netgroups=netgroups groupName
# ipa netgroup-add-member --users=jsmith,bjensen --groups=ITadmin --hosts=host1.example.com,host2.example.com --hostgroups=EngDev --netgroups=nisgroup2 example-group
13.4. 自動マウントマップの NIS クライアントへの公開
auto.example
という名前で指定した自動マウントマップを追加します。
[root@server ~]# ldapadd -h nisserver.example.com -x -D "cn=Directory Manager" -w secret dn: nis-domain=example.com+nis-map=auto.example,cn=NIS Server,cn=plugins,cn=config objectClass: extensibleObject nis-domain: example.com nis-map: auto.example nis-filter: (objectclass=automount) nis-key-format: %{automountKey} nis-value-format: %{automountInformation} nis-base: automountmapname=auto.example,cn=default,cn=automount,dc=example,dc=com
13.5. NIS から IdM への移行
13.5.1. IdM での netgroup エントリーの準備
ユーザーエントリーの場合
NIS のユーザー情報を使用するアプリケーションを判定します。(sudo のような) クライアントには NIS netgroup が必要ですが、多くのクライアントは代わりに Unix グループを使用できます。netgroup が必要ない場合は、IdM で対応するユーザーアカウントを作成し、netgroup を完全に削除するだけです。それ以外の場合は、IdM にユーザーエントリーを作成し、IdM 管理の netgroup を作成し、そのユーザーをメンバーとして追加します。この操作は、「Netgroups の作成」に説明があります。
ホストエントリーの場合
ホストグループが IdM に作成されるたびに、一致するシャドウの NIS グループが自動的に作成されます。これらの netgroup は、ipa-host-net-manage コマンドを使用して管理できます。
直接変換の場合
IdM に、すべての NIS ユーザーおよびホストに、完全に一致するエントリーがある状態で、正確な変換が必要になる場合があります。この場合には、元の NIS 名を使用して各エントリーを作成できます。
- netgroup で参照されているユーザーすべてについてエントリーを作成します。
- netgroup で参照されているホストすべてについてエントリーを作成します。
- 元の netgroup と同じ名前の netgroup を作成します。
- ユーザーとホストをこの netgroup の直接のメンバーとして追加します。または、ユーザーとホストを IdM グループまたは他の netgroup に追加し、それらのグループを netgroup に追加します。
13.5.2. Identity Management での NIS リスナーの有効化
slapi-nis
プラグインは、NIS リスナーを設定し、着信 NIS 要求を受信して Directory Server 内の NIS マップを管理します。Identity Management は、以下の 3 つの NIS マップを使用します。
- passwd
- group
- netgroup
slapi-nis
プラグインはデフォルトでは無効になっています。Identity Management の NIS を有効にするには、以下を実行します。
- IdM 管理ユーザーとして新しい Kerberos 認証情報を取得します。
[root@ipaserver ~]# kinit admin
- NIS リスナーと互換性プラグインを有効にします。
[root@ipaserver ~]# ipa-nis-manage enable [root@ipaserver ~]# ipa-compat-manage enable
- DNS サービスおよび Directory Server サービスを再起動します。
[root@server ~]# service rpcbind restart [root@server ~]# service dirsrv restart
13.5.3. 既存 NIS データのインポートおよびエクスポート
13.5.3.1. ユーザーエントリーのインポート
nis-user.sh
の例です。
#!/bin/sh # 1 is the nis domain, 2 is the nis master server ypcat -d $1 -h $2 passwd > /dev/shm/nis-map.passwd 2>&1 IFS=$'\n' for line in $(cat /dev/shm/nis-map.passwd); do IFS=' ' username=$(echo $line|cut -f1 -d:) # Not collecting encrypted password because we need cleartext password to create kerberos key uid=$(echo $line|cut -f3 -d:) gid=$(echo $line|cut -f4 -d:) gecos=$(echo $line|cut -f5 -d:) homedir=$(echo $line|cut -f6 -d:) shell=$(echo $line|cut -f7 -d:) # Now create this entry echo passw0rd1|ipa user-add $username --first=NIS --last=USER --password --gidnumber=$gid --uid=$uid --gecos=$gecos --homedir=$homedir --shell=$shell ipa user-show $username done
[root@nis-server ~]# kinit admin [root@nis-server ~]# ./nis-user.sh nisdomain nis-master.example.com
13.5.3.2. グループエントリーのインポート
nis-group.sh
の例です。
#!/bin/sh # 1 is the nis domain, 2 is the nis master server ypcat -d $1 -h $2 group > /dev/shm/nis-map.group 2>&1 IFS=$'\n' for line in $(cat /dev/shm/nis-map.group); do IFS=' ' groupname=$(echo $line|cut -f1 -d:) # Not collecting encrypted password because we need cleartext password to create kerberos key gid=$(echo $line|cut -f3 -d:) members=$(echo $line|cut -f4 -d:) # Now create this entry ipa group-add $groupname --desc=NIS_GROUP_$groupname --gid=$gid if [ -n "$members" ]; then ipa group-add-member $groupname --users=$members fi ipa group-show $groupname done
[root@nis-server ~]# kinit admin [root@nis-server ~]# ./nis-group.sh nisdomain nis-master.example.com
13.5.3.3. ホストエントリーのインポート
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
[root@nis-server ~]# kinit admin [root@nis-server ~]# ./nis-hosts.sh nisdomain nis-master.example.com
13.5.3.4. Netgroup エントリーのインポート
nis-netgroup.sh
の例です。
#!/bin/sh # 1 is the nis domain, 2 is the nis master server ypcat -k -d $1 -h $2 netgroup > /dev/shm/nis-map.netgroup 2>&1 IFS=$'\n' for line in $(cat /dev/shm/nis-map.netgroup); do IFS=' ' netgroupname=$(echo $line|awk '{print $1}') triples=$(echo $line|sed "s/^$netgroupname //") echo "ipa netgroup-add $netgroupname --desc=NIS_NG_$netgroupname" if [ $(echo $line|grep "(,"|wc -l) -gt 0 ]; then echo "ipa netgroup-mod $netgroupname --hostcat=all" fi if [ $(echo $line|grep ",,"|wc -l) -gt 0 ]; then echo "ipa netgroup-mod $netgroupname --usercat=all" fi for triple in $triples; do triple=$(echo $triple|sed -e 's/-//g' -e 's/(//' -e 's/)//') if [ $(echo $triple|grep ",.*,"|wc -l) -gt 0 ]; then hostname=$(echo $triple|cut -f1 -d,) username=$(echo $triple|cut -f2 -d,) domain=$(echo $triple|cut -f3 -d,) hosts=""; users=""; doms=""; [ -n "$hostname" ] && hosts="--hosts=$hostname" [ -n "$username" ] && users="--users=$username" [ -n "$domain" ] && doms="--nisdomain=$domain" echo "ipa netgroup-add-member $hosts $users $doms" else netgroup=$triple echo "ipa netgroup-add $netgroup --desc=NIS_NG_$netgroup" fi done done
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"
[root@nis-server ~]# kinit admin [root@nis-server ~]# ./nis-hosts.sh nisdomain nis-master.example.com
13.5.3.5. Automount マップのインポート
#!/bin/sh # 1 is for the automount entry in ipa ipa automountlocation-add $1 # 2 is the nis domain, 3 is the nis master server, 4 is the map name ypcat -k -d $2 -h $3 $4 > /dev/shm/nis-map.$4 2>&1 ipa automountmap-add $1 $4 basedn=$(ipa env basedn|tr -d '[:space:]'|cut -f2 -d:) cat > /tmp/amap.ldif <<EOF dn: nis-domain=nisdomain.example.com+nis-map=$4,cn=NIS Server,cn=plugins,cn=config objectClass: extensibleObject nis-domain: $3 nis-map: $4 nis-base: automountmapname=$4,cn=nis,cn=automount,$basedn nis-filter: (objectclass=*) nis-key-format: %{automountKey} nis-value-format: %{automountInformation} EOF ldapadd -x -h $3 -D "cn=directory manager" -w secret -f /tmp/amap.ldif IFS=$'\n' for line in $(cat /dev/shm/nis-map.$4); do IFS=" " key=$(echo "$line" | awk '{print $1}') info=$(echo "$line" | sed -e "s#^$key[ \t]*##") ipa automountkey-add nis $4 --key="$key" --info="$info" done
[root@nis-server ~]# kinit admin [root@nis-server ~]# ./nis-hosts.sh location nisdomain nis-master.example.com map
13.5.4. IdM に NIS ユーザー認証の弱度のパスワード暗号化を設定する手順
passwordStorageScheme
属性を変更します。
[root@server ~]# ldapmodify -D "cn=directory server" -w secret -p 389 -h ipaserver.example.com dn: cn=config changetype: modify replace: passwordStorageScheme passwordStorageScheme: crypt
第14章 アイデンティティー: フォレスト間の信頼との統合 (テクノロジープレビュー)
Red Hat Enterprise Linux 6 のフォレスト間の信頼 (テクノロジープレビュー機能)
Red Hat Enterprise Linux 6 のフォレスト間の信頼機能の概要
- 1 つの AD フォレストへの信頼を確立する。
- 信頼された AD フォレストの rootドメインからユーザーの IdM リソースにアクセスできる。
- ログインシェルまたはホームディレクトリーなど AD ユーザーのデフォルトの属性を一元的に上書きする。これには、Red Hat Enterprise Linux 7 で IdM を使用して ID ビューをデプロイします。
- レガシークライアントの互換性ツリーを使用して、AD ユーザーおよびグループを公開する。レガシークライアントが AD ユーザーおよびグループにアクセスできるようにするには、Red Hat Enterprise Linux 7 で IdM を使用します。
信頼と同期
第15章 アイデンティティー: 同期による Microsoft Active Directory との統合
15.1. サポート対象の Windows プラットフォーム
- Windows Server 2008 R2
- Windows Server 2012 R2
15.2. Active Directory および Identity Management の概要
- 同期操作は 5 分ごとに実行されます。
- 同期が設定できるのは、Active Directory ドメイン 1 つのみとなっています。複数のドメインには対応していません。
- 同期が設定できるのは、Active Directory ドメイン 1 つ のみとなっています。
- ユーザー情報のみが同期されます。
- ユーザー属性とパスワードの両方を同期することができます。
- 変更は双方向ですが (Active Directory から IdM、IdM から Active Directory の両方)、アカウントの作成または追加は、Active Directory から Identity Management への一方向のみになります。新しいアカウントが Active Directory に作成されると、自動的に IdM に対して同期されます。ただし、ユーザーアカウントを IdM で作成した場合には、同期の前に Active Directory にも作成する必要があります。
- アカウントロック情報はデフォルトで同期され、1 つのドメインで無効にされているユーザーアカウントは他方のドメインでも無効にされます。
- パスワードの変更は即時に有効になります。
15.3. 同期された属性の概要
Identity Management および Windows サーバーで同一のユーザースキーマ
- cn[5]
- physicalDeliveryOfficeName
- description
- postOfficeBox
- destinationIndicator
- postalAddress
- facsimileTelephoneNumber
- postalCode
- givenname
- registeredAddress
- homePhone
- sn
- homePostalAddress
- st
- initials
- street
- l
- telephoneNumber
- mail
- teletexTerminalIdentifier
- mobile
- telexNumber
- o
- title
- ou
- usercertificate
- pager
- x121Address
ID 管理 | Active Directory |
---|---|
cn[a] | name |
nsAccountLock | userAccountControl |
ntUserDomainId | sAMAccountName |
ntUserHomeDir | homeDirectory |
ntUserScriptPath | scriptPath |
ntUserLastLogon | lastLogon |
ntUserLastLogoff | lastLogoff |
ntUserAcctExpires | accountExpires |
ntUserCodePage | codePage |
ntUserLogonHours | logonHours |
ntUserMaxStorage | maxStorage |
ntUserProfile | profilePath |
ntUserParms | userParameters |
ntUserWorkstations | userWorkstations |
[a]
Identity Management から Active Directory に同期時には、 cn は直接 (cn から cn へ) マッピングされます。Active Directory から同期すると、cn は、Active Directory の name 属性から Identity Management の cn 属性にマッピングされます。
|
15.3.1. Identity Management と Active Directory との間のユーザースキーマの相違点
15.3.1.1. cn 属性の値
cn
属性に複数の値を設定できますが、Active Directory ではこの属性には単一の値しか設定できせん。Identity Management の cn
属性が同期されると、単一の値のみが Active Directory ピアに送信されます。
cn
値が Active Directory エントリーに追加され、その値が Identity Management の cn
の値のいずれでもない場合には、Identity Management のcn
値はすべて単一の Active Directory 値で上書きされます。
cn
属性をその命名属性として使用するのに対し、Identity Management は uid
を使用する点があります。つまり、cn
属性が Identity Management で編集する可能性がある場合には、エントリーの名前が完全に (および間違って) 変更されてしまう可能性があります。この cn
の変更が Active Directory エントリーに書き込まれると、エントリーの名前が変更され、新しい名前のエントリーで Identity Management に書き込まれます。
15.3.1.2. street および streetAddress の値
streetAddress
属性を使用します。これは、389 Directory Server が street
属性を使用する方法に相当します。Active Directory および Identity Management が streetAddress
および street
属性を使用する方法には 2 つの重要な相違点があります。
- 389 Directory Server では、
streetAddress
は、street
のエイリアスです。Active Directory にもstreet
属性がありますが、streetAddress
のエイリアスではなく、独立した値を保持することができる個別の属性です。 - Active Directory は
streetAddress
とstreet
を単一値の属性として定義しますが、389 Directory Server は RFC 4519 に指定されているようにstreet
を複数値の属性として定義します。
streetAddress
および street
属性を処理する方法が異なるため、Active Directory と Identity Management で address 属性を設定する場合には以下の 2 つのルールに従う必要があります。
- 同期プロセスは、Active Directory エントリーの
streetAddress
から Identity Management のstreet
にマッピングされます。競合を回避するために、street
属性は Active Directory では使用しないようにしてください。 - Identity Management の
street
属性値は 1 つだけ、Active Directory に同期されます。streetAddress
属性が Active Directory で変更され、新しい値が Identity Management に存在しない場合には、Identity Management のすべてのstreet
属性値が新しい Active Directory の値に置き換えられます。
15.3.1.3. initials 属性の制約
initials
属性の場合には、Active Directory は最大長 6 文字の制限を課しますが、389 Directory Serve には長さ制限がありません。Identity Management に 7 文字以上の initials
属性が 追加されると、この値は Active Directory エントリーとの同期時にカットされます。
15.3.1.4. surname (sn) 属性の要求
15.3.2. Active Directory エントリーおよび RFC 2307 属性
uidNumber
および gidNumber
属性を有効化できます。これにより、Windows ユーザーエントリーは RFC 2307 のこれらの属性の仕様に準拠できます。
uidNumber
および gidNumber
属性は、Identity Management エントリーの uidNumber
および gidNumber
属性として実際には使用されません。Identity Management の uidNumber
と gidNumber
属性は、Windows ユーザーの同期時に生成されます。
uidNumber
および gidNumber
属性は、Active Directory エントリーで定義され、使用される uidNumber
と gidNumber
属性とは異なり、数字にも関連性はありません。
cn
は、他の同期属性とは異なる処理がされます。Identity Management から Active Directory に同期時には、直接 (cn
から cn
へ) マッピングされます。ただし、Active Directory から Identity Management に同期する場合には、cn
は、Windows の name
属性から Identity Management の cn
属性にマッピングされます。
15.4. 同期用の Active Directory の設定
15.4.1. 同期用の Active Directory ユーザーの作成
- 同期用のユーザーアカウントには、同期先の Active Directory サブツリーに対して ディレクトリーに加えられた変更を複製する 権限を付与します。同期用のユーザーが同期操作を行うには、レプリケーターの権限が必要です。レプリケーターの権限は、http://support.microsoft.com/kb/303972 で説明されています。
- 同期ユーザーを Account Operator および Enterprise Read-only Domain Controller グループのメンバーとして追加します。このユーザーは、全 Domain Admin グループに所属する必要はありません。
15.4.2. Active Directory 認証局の設定
15.5. 同期合意の管理
15.5.1. Active Directory および IdM CA 証明書の信頼
- Active Directory サーバーで、
http://ipa.example.com/ipa/config/ca.crt
から IdM サーバーの CA 証明書をダウンロードします。 - Active Directory 証明書データベースに IdM CA 証明書をインストールします。これは、Microsoft 管理コンソールまたは certutil ユーティリティー を使用して実行できます。以下に例を示します。
certutil -installcert -v -config "ipaserver.example.com\Example Domain CA" c:\path\to\ca.crt
詳細は、Active Directory のドキュメントを参照してください。 - Active Directory CA 証明書をエクスポートします。
- My Network Places で CA の配信ポイントを開きます。
- セキュリティー証明書ファイル (
.crt
ファイル) をダブルクリックして、証明書 ダイアログボックスを表示します。 - 詳細 タブで、 をクリックして 証明書のエクスポートウィザード を起動します。
- Base-64 encoded X.509 (.CER) を選択します。をクリックしてから、
- エクスポートされたファイルに適切なディレクトリーおよびファイル名を指定します。をクリックして証明書をエクスポートし、 をクリックします。
- Active Directory 証明書を IdM サーバーマシンにコピーします。
- IdM サーバーの CA 証明書を
http://ipa.example.com/ipa/config/ca.crt
からダウンロードします。 - Active Directory CA 証明書と IdM CA 証明書の両方を
/etc/openldap/cacerts/
ディレクトリーにコピーします。 - 証明書のハッシュシンボリックリンクを更新します。
cacertdir_rehash /etc/openldap/cacerts/
/etc/openldap/ldap.conf
ファイルを編集して、/etc/openldap/cacerts/
ディレクトリーの証明書を参照および使用するための情報を追加します。TLS_CACERTDIR /etc/openldap/cacerts/ TLS_REQCERT allow
15.5.2. 同期合意の作成
- Active Directory サーバーと IdM サーバーが、「Active Directory および IdM CA 証明書の信頼」にあるように相互の CA 証明書を信頼していることを確認してください。
- IdM サーバー上の既存の Kerberos 資格情報を削除します。
$ kdestroy
- ipa-replica-manage コマンドを使用して Windows 同期合意を作成します。これには、
--winsync
オプションが必要です。パスワードとユーザーアカウントを同期する場合は、--passsync
オプションも使用して、パスワード同期に使用するパスワードを設定します。--binddn
および--bindpwd
オプションを指定すると、IdM が Active Directory サーバーへの接続に使用する Active Directory サーバー上のシステムアカウントにユーザー名およびパスワードを設定します。$ ipa-replica-manage connect --winsync --binddn cn=administrator,cn=users,dc=example,dc=com --bindpw Windows-secret --passsync secretpwd --cacert /etc/openldap/cacerts/windows.cer adserver.example.com -v
- プロンプトが出されたら、Directory Manager のパスワードを入力します。
- 任意。「パスワード同期のセットアップ」 に説明されているようにパスワードの同期を設定します。
オプション | Description |
---|---|
--winsync | 同期合意として指定します。 |
--binddn | 同期 ID の完全なユーザーの DN を指定します。これは、IdM LDAP サーバーが Active Directory にバインドするために使用するユーザーの DN です。このユーザーは Active Directory ドメインに存在しており、Active Directory サブツリーに replicator、read、search、write のパーミッションが必要です。 |
--bindpw | 同期ユーザーのパスワードを指定します。 |
--passsync | 同期を行う Windows ユーザーアカウントのパスワードを指定します。 |
--cacert | Active Directory CA 証明書の完全パスおよびファイル名を指定します。この証明書は、「Active Directory および IdM CA 証明書の信頼」にエクスポートされます。 |
--win-subtree | 同期するユーザーが含まれる Windows ディレクトリーサブツリーの DN を指定します。デフォルト値は cn=Users,$SUFFIX です。 |
AD_server_name | Active Directory ドメインコントローラーのホスト名を指定します。 |
15.5.3. ユーザーアカウント属性の同期動作の変更
ipaWinSyncAcctDisable
属性を編集すると無効にできます。(この属性を変更すると、Active Directory でアカウントが無効な場合でも、IdM で引き続き有効な状態となり、その逆も同様になります)。
[jsmith@ipaserver ~]$ ldapmodify -x -D "cn=directory manager" -w password dn: cn=ipa-winsync,cn=plugins,cn=config changetype: modify replace: ipaWinSyncAcctDisable ipaWinSyncAcctDisable: none modifying entry "cn=ipa-winsync,cn=plugins,cn=config"
パラメーター | 説明 | 設定可能な値 |
---|---|---|
一般ユーザーアカウントのパラメーター | ||
ipaWinSyncNewEntryFilter | 新規ユーザーエントリーに追加するオブジェクトクラスの一覧を含むエントリーの検索に使用する検索フィルターを設定します。 | デフォルトでは (cn=ipaConfig) です。 |
ipaWinSyncNewUserOCAttr | 新規ユーザーエントリーに追加するオブジェクトクラスの一覧が実際に含まれる設定エントリーの属性を設定します。 | デフォルトは ipauserobjectclasses です。 |
ipaWinSyncHomeDirAttr | POSIX ホームディレクトリーのデフォルトの場所を含むエントリー内の属性を識別します。 | デフォルトは ipaHomesRootDir です。 |
ipaWinSyncUserAttr | Active Directory ユーザーを Active Directory ドメインから同期する時に、特定の値で別の属性を設定してAD ユーザーに追加します。複数値の属性の場合は、属性を複数回設定でき、同期プロセスで、値のすべてがエントリーに追加されます。
注記
エントリーに属性が存在しない場合に属性値のみが設定されます。属性が存在する場合は、Active Directory エントリーの同期時にエントリーの値が使用されます。
| ipaWinSyncUserAttr: attributeName attributeValue |
ipaWinSyncForceSync | 同期できるように、既存の Active Directory ユーザーに一致する既存 IdM ユーザーを自動編集する必要があるかどうかを設定します。IdM ユーザーアカウントに既存の Active Directory の samAccountName と同じ uid パラメーターがある場合に、アカウントはデフォルトでは同期 されません。この属性は、同期サービスに対して、ntUser および ntUserDomainId を IdM ユーザーエントリーに自動的に追加し、同期されるように指示します。 | true | false |
ユーザーアカウントのロックパラメーター | ||
ipaWinSyncAcctDisable | アカウントロックアウト属性を同期する方法を設定します。有効にするアカウントロックアウト設定を制御できます。たとえば、to_ad は、アカウントロックアウト属性が IdM に設定される場合に、その値が Active Directory に対して同期され、ローカルの Active Directory 値を上書きすることを意味します。デフォルトでは、アカウントロックアウト属性は両ドメインから同期されます。 |
|
ipaWinSyncInactivatedFilter | 非アクティブ化された (無効にされた) ユーザーを保持するために使用されるグループの DN 検索用のフィルターを設定します。これは、ほとんどの実装では変更する必要はありません。 | デフォルトは (&(cn=inactivated)(objectclass=groupOfNames)) です。 |
ipaWinSyncActivatedFilter | アクティブなユーザーを保持するために使用されるグループの DN 検索用のフィルターを設定します。これは、ほとんどの実装では変更する必要はありません。 | デフォルトは (&(cn=activated)(objectclass=groupOfNames)) です。 |
グループのパラメーター | ||
ipaWinSyncDefaultGroupAttr | ユーザーのデフォルトグループを確認するために参照する新規ユーザーアカウントの属性を設定します。その後、エントリーのグループ名がユーザーアカウントの gidNumber の検索に使用されます。 | デフォルトは ipaDefaultPrimaryGroup です。 |
ipaWinSyncDefaultGroupFilter | 検索フィルターを設定して、グループ名を POSIX の gidNumber にマッピングします。 | デフォルトは (&(gidNumber=*)(objectclass=posixGroup)(cn=groupAttr_value)) です。 |
レルムのパラメーター | ||
ipaWinSyncRealmAttr | レルムエントリーにレルム名を含む属性を設定します。 | デフォルトは cn です。 |
ipaWinSyncRealmFilter | IdM レルム名を含むエントリーの検索に使用する検索フィルターを設定します。 | デフォルトは (objectclass=krbRealmContainer) です。 |
15.5.4. 同期された Windows サブツリーの変更
--win-subtree
オプションを使用して同期合意が作成されると、Active Directory サブツリーの値はデフォルト以外の値に設定できます。この合意の作成後に、ldapmodify コマンドを使用し、同期合意エントリー内の nsds7WindowsReplicaSubtree
値を編集して Active Directory サブツリーを変更できます。
- ldapsearch を使用して、同期合意の名前を取得します。この検索は、エントリー全体ではなく、
dn
およびnsds7WindowsReplicaSubtree
属性の値のみを返します。[jsmith@ipaserver ~]$ ldapsearch -xLLL -D "cn=directory manager" -w password -p 389 -h ipaserver.example.com -b cn=config objectclass=nsdswindowsreplicationagreement dn nsds7WindowsReplicaSubtree dn: cn=meToWindowsBox.example.com,cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config nsds7WindowsReplicaSubtree: cn=users,dc=example,dc=com ... 8< ...
- 同期合意の変更
[jsmith@ipaserver ~]$ ldapmodify -x -D "cn=directory manager" -W -p 389 -h ipaserver.example.com <<EOF dn: cn=meToWindowsBox.example.com,cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config changetype: modify replace: nsds7WindowsReplicaSubtree nsds7WindowsReplicaSubtree: cn=alternateusers,dc=example,dc=com EOF modifying entry "cn=meToWindowsBox.example.com,cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config"
15.5.5. 一方向同期の設定
oneWaySync
パラメーターを設定します。使用可能な値は、fromWindows
(Active Directory から Identity Management への同期) と toWindows
(Identity Management から Active Directory の同期) です。
[jsmith@ipaserver ~]$ ldapmodify -x -D "cn=directory manager" -w password -p 389 -h ipaserver.example.com dn: cn=windows.example.com,cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config changetype: modify add: oneWaySync oneWaySync: fromWindows
15.5.6. 同期合意の削除
- 同期合意を削除します。
# ipa-replica-manage disconnect adserver.example.com
- IdM サーバーのデータベースから Active Directory CA 証明書を削除します。
# certutil -D -d /etc/dirsrv/slapd-EXAMPLE.COM/ -n "Imported CA"
15.5.7. Winsync 合意のエラー
Active Directory サーバーに接続できないため、同期合意の作成に失敗します。
同期合意での最も一般的なエラーの 1 つとして、IdM サーバーが Active Directory サーバーに接続できない点が挙げられます。
"Update failed! Status: [81 - LDAP error: Can't contact LDAP server]
/etc/dirsrv/slapd-DOMAIN/
ディレクトリー内) に Imported CA という名前で重複した証明書が作成されます。これは、certutil を使用して確認できます。
$ certutil -L -d /etc/dirsrv/slapd-DOMAIN/ Certificate Nickname Trust Attributes SSL,S/MIME,JAR/XPI CA certificate CTu,u,Cu Imported CA CT,,C Server-Cert u,u,u Imported CA CT,,C
# certutil -d /etc/dirsrv/slapd-DOMAIN-NAME -D -n "Imported CA"
エントリーが存在することを示すため、パスワードが同期されていないことを示すエラーがあります。
ユーザーデータベースの一部のエントリーについて、エントリーがすでに存在するためにパスワードはリセットされないという情報のエラーメッセージが表示される可能性があります。
"Windows PassSync entry exists, not resetting password"
15.6. パスワード同期の管理
15.6.1. パスワード同期のための Windows Server のセットアップ
- Active Directory が SSL で実行されている必要があります。
- パスワード同期サービスは、各 Active Directory ドメインコントローラーにインストールする必要があります。
- Active Directory パスワードの複雑さのポリシーが有効になっていることを確認し、パスワード同期サービスを実行します。
- コマンドライン
secpol.msc
から実行します。 - Password must meet complexity requirements オプションを有効にし、保存します。
- SSL がまだ有効になっていない場合は、Active Directory サーバーに SSL を設定します。LDAPS の設定に関する詳細は、http://support.microsoft.com/kb/321051 の Microsoft ナレッジベースを参照してください。
- プログラムの 追加/削除 の Windows コンポーネント セクションに認証局をインストールします。
- Enterprise Root CA オプションを選択します。
- Active Directory サーバーを再起動します。IIS Web サービスを実行している場合は、http://servername/certsrv を開いて CA 証明書にアクセスできます。
- SSL サーバー証明書を使用するように Active Directory サーバーを設定します。
- Active Directory の完全修飾ドメイン名を証明書サブジェクトとして使用し 、証明書要求
.inf
を作成します。たとえば、以下のようになります。;----------------- request.inf ----------------- [Version] Signature="$Windows NT$ [NewRequest] Subject = "CN=ad.server.example.com, O=Engineering, L=Raleigh, S=North Carolina, C=US" KeySpec = 1 KeyLength = 2048 Exportable = TRUE MachineKeySet = TRUE SMIME = False PrivateKeyArchive = FALSE UserProtected = FALSE UseExistingKeySet = FALSE ProviderName = "Microsoft RSA SChannel Cryptographic Provider" ProviderType = 12 RequestType = PKCS10 KeyUsage = 0xa0 [EnhancedKeyUsageExtension] OID=1.3.6.1.5.5.7.3.1 ;-----------------------------------------------
.inf
リクエストファイルの詳細は、http://technet.microsoft.com/en-us/library/cc783835.aspx などの Microsoft ドキュメントを参照してください。 - 証明書要求を生成します。
certreq -new request.inf request.req
- Active Directory CA にリクエストを送信します。以下に例を示します。
certreq -submit request.req certnew.cer
注記コマンドラインツールがエラーメッセージを返す場合は、Web ブラウザーを使用して CA にアクセスし、証明書要求を送信します。IIS が実行されている場合、CA URL は http://servername/certsrv になります。 - 証明書要求を受け入れます。以下に例を示します。
certreq -accept certnew.cer
- サーバー証明書が Active Directory サーバーに存在していることを確認します。
- Directory Server から Active Directory に CA 証明書をインポートします。Trusted Root CA をクリックし、続いて Import をクリックして Directory Server CA 証明書を参照します。
- ドメインコントローラーを再起動します。
15.6.2. パスワード同期のセットアップ
- Active Directory マシンに
PassSync.msi
ファイルをダウンロードします。- カスタマーポータルにログインします。
- Downloads タブをクリックします。
- ページの中心の Red Hat Enterprise Linux ダウンロードボタンをクリックします。
- Directory Server などの検索用語を使用してダウンロードをフィルタリングし、Red Hat Enterprise Linux バージョンの 1 つを展開します。
- Directory Server のリンクをクリックします。
- Directory Server ページで、WinSync Installer の適切なバージョンをダウンロードします。これは、パスワード同期 MSI ファイル (
RedHat-PassSync-1.1.5-arch.msi
) です。
注記Red Hat Enterprise Linux アーキテクチャーに関係なく、32 ビットの Windows サーバー用と 64 ビット用にそれぞれ PassSync パッケージが 2 つあります。Windows プラットフォームに適したパッケージを選択してください。 - Password Sync MSI ファイルをダブルクリックしてインストールします。
- パスワード同期セットアップ画面 が表示されます。Next を押して、インストールを開始します。
- IdM サーバーへの接続を確立するための情報を入力します。
- ホスト名およびセキュアなポート番号を含む ldM サーバー接続情報。
- Active Directory が IdM マシンへの接続に使用するシステムユーザーのユーザー名。このアカウントは、同期が IdM サーバーに設定されている場合に自動的に設定されます。デフォルトのアカウントは uid=passsync,cn=sysaccounts,cn=etc,dc=example,dc=com です。
- 同期合意の作成時に
--passsync
オプションに設定されたパスワード。 - IdM サーバーの people サブツリーの検索ベース。Active Directory サーバーは、ldapsearch またはレプリケーション操作と似た IdM サーバーに接続するため、IdM サブツリーでユーザーアカウントを検索する場所を知っている必要があります。ユーザーサブツリーは cn=users,cn=accounts,dc=example,dc=com です。
- 証明書トークンはこの時点では使用されないため、このフィールドは空白にする必要があります。
- IdM サーバーの CA 証明書を Active Directory 証明書ストアにインポートします。
- IdM サーバーの CA 証明書を
http://ipa.example.com/ipa/config/ca.crt
からダウンロードします。 - IdM CA 証明書を Active Directory サーバーにコピーします。
Run as Administrator
を使用してコマンドプロンプトを開きます。- パスワード同期データベースに IdM CA 証明書をインストールします。以下に例を示します。
cd "C:\Program Files\Red Hat Directory Password Synchronization" certutil.exe -d . -A -n "IPASERVER.EXAMPLE.COM IPA CA" -t CT,, -a -i ipaca.crt
cd "C:\Program Files\389 Directory Password Synchronization" certutil.exe -d . -A -n "IPASERVER.EXAMPLE.COM IPA CA" -t CT,, -a -i ipaca.crt
- Windows マシンを再起動して、パスワード同期を開始します。注記Windows マシンは再起動されている必要があります。再起動しないと
PasswordHook.dll
は有効にされず、パスワードの同期は機能しません。
.msi
でインストールされます。
15.6.3. 他のユーザーのパスワードのクリーンな変更を許可する
passSyncManagersDNs
属性は、パスワード変更操作を実行できる管理者アカウントの一覧を表示します。これはパスワードのリセットを必要としません。
passSyncManagersDNs
属性を追加します。この属性は多値です。以下に例を示します。
$ ldapmodify -x -D "cn=Directory Manager" -w secret -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
第16章 ID: ID ビューおよび既存の環境から信頼への移行
- AD ユーザーの POSIX 属性と SSH 鍵を保存する
- AD ユーザーの POSIX 属性、SSH キー、および SSH ログイン情報を定義します。そして、ID ビューサポートのある SSSD を実行しているクライアントに対して AD ユーザーが認証する場合や、AD ユーザーが LDAP 互換ツリー を使用して認証する際に適用されるようにします。これにより、レガシークライアントのユーザーおよびグループデータでシンプルな LDAP ツリーが提供されます。この機能は、同期ベースのソリューションからの移行や、Linux 管理者が AD ユーザーの POSIX 属性を手動で定義したい場合に便利ですが、AD ポリシーはこれを許可しません。
- 同期ベースから信頼ベースの統合への移行
- 以前に使用した UID や他のツールを指定する ID ビューオーバーライドを作成して、同期ベースの環境にあるユーザーの POSIX 属性を設定します。次に、ユーザーを AD に戻します。
- IdM ユーザー POSIX 属性のホストごとのグループのオーバーライドを実行する
- AD との IdM 統合に移行している NIS ベースのインフラストラクチャーでは、一部の NIS ドメインで元の POSIX データが変更されていない状態である必要があります。そうでなければ、企業のポリシーにより、AD に元の POSIX データを直接設定できない場合があります。このような状況では、ID ビューを使用して、Identity Management サーバーで直接 POSIX データを設定できます。
- 環境ごとに異なる POSIX 属性または SSH キーを設定する
- 対応するホストグループに応じて、さまざまな POSIX 属性またはさまざまなユーザー SSH 公開鍵を各種プロダクション環境 (開発、テスト、またはプロダクション) に対して設定します。
16.1. ユーザーオーバーライドおよびグループのオーバーライド
uid
: ユーザーログイン名uidNumber
: ユーザー UID 番号gidNumber
: ユーザーの GID 番号loginShell
: ユーザーログインシェルGECOS
: ユーザー GECOS エントリーhomeDirectory
: ユーザーのホームディレクトリーipaSshPubkey
: ユーザー SSH 公開鍵またはキー
cn
: グループ名gidNumber
: グループの GID 番号
16.2. サーバー側での ID ビューの管理
16.3. クライアント側の ID ビュー
16.4. Synchronization-Based からトラストベースのソリューションへの移行
第17章 アイデンティティー: DNS の管理
17.1. IdM の DNS について
dn: idnsname=client1,idnsname=example.com,cn=dns,dc=example,dc=com idnsname: client1 arecord: 10.0.0.1 arecord: 10.0.0.2 arecord: 10.0.0.3 aaaarecord: fc00::1 objectclass: top objectclass: idnsrecord
/usr/share/ipa/60basev2.ldif
スキーマファイルにあります。[6].
bind-dyndb-ldap
プラグインを使用して Directory Server と通信します。DNS を管理するために Identity Management を設定すると、IdM は BIND サービスの /etc/named.conf
ファイルに dynamic-db 設定セクションを作成します。これにより、BIND (named
) サービスの bind-dyndb-ldap
プラグインが設定されます。
named
サービスに DNS レコードを提供します。設定を変更して、プラグインの動作に合わせて LDAP-BIND の対話を行います。
17.2. 既存の DNS 設定での IdM および DNS サービス検出の使用
Sample zone file for bind has been created in /tmp/sample.zone.F_uMf4.db
例17.1 デフォルトの IdM DNS ファイル
; ldap servers _ldap._tcp IN SRV 0 100 389 ipaserver.example.com. ;kerberos realm _kerberos IN TXT EXAMPLE.COM ; kerberos servers _kerberos._tcp IN SRV 0 100 88 ipaserver.example.com. _kerberos._udp IN SRV 0 100 88 ipaserver.example.com. _kerberos-master._tcp IN SRV 0 100 88 ipaserver.example.com. _kerberos-master._udp IN SRV 0 100 88 ipaserver.example.com. _kpasswd._tcp IN SRV 0 100 464 ipaserver.example.com. _kpasswd._udp IN SRV 0 100 464 ipaserver.example.com.
17.3. DNS に関する注意事項
- DNS 名の設定時にはワイルドカードを使用できません。明示的な DNS ドメイン名のみがサポートされます。
--setup-dns
オプションを指定しても、rndc サービスは設定されません。このサービスは、IdM サーバーの設定後に手動で設定する必要があります。
17.4. インストール後の DNS サービスの追加または更新
--setup-dns
オプションを使用して、IdM サーバーのインストールの一部として設定できます。DNS が設定されていない場合は、ipa-dns-install コマンドを使用して後で設定できます。
[root@server ~]# ipa-dns-install -p secret --ip-address=1.2.34.56 --no-forwarders
-p
では、389 Directory Server の Directory Manager ユーザーのパスワードを指定します。すべての DNS エントリーは LDAP ディレクトリーに格納されるため、このディレクトリーにアクセスして DNS 設定を追加する必要があります。--ip-address
では、マスター DNS サーバーの IP アドレスを取得します。--no-forwarders
は、DNS サービスと使用されるフォワーダーがルートサーバーのみであることを意味します。また、--forwarder
オプションを指定して、使用するフォワード定義します。複数のフォワーダーを指定するには、--forwarder
オプションを複数回指定します。- 逆引き DNS は自動的に設定されます。
--no-reverse
オプションを使用して逆引き DNS を無効にすることができます。既存の逆引き DNS ゾーンが設定されている場合は、この--no-reverse
オプションを指定して、新しい逆引きゾーンを作成するのではなく、既存の逆引きゾーンを使用します。 - IdM サーバーが明示的に無効になっている場合を除き、Directory Server で永続的な検索を開き、新しいゾーンの変更を即座にキャプチャーします。
17.5. rndc サービスの設定
- rndc 設定ファイルとキーを作成します。
[root@server ~]# /usr/sbin/rndc-confgen -a [root@server ~]# /sbin/restorecon /etc/rndc.conf
これには、キーの作成時にユーザーが入力してエントロピーを作成する必要がある場合があります。 - rndc キーファイルの所有者と権限を変更します。
[root@server ~]# chown root:named /etc/rndc.key [root@server ~]# chmod 0640 /etc/rndc.key
17.6. DNS ゾーンエントリーの管理
17.6.1. 正引き DNS ゾーンの追加
17.6.1.1. Web UI での操作
- Identity タブを開き、DNS サブタブを選択します。
- DNS ゾーンの一覧の上部にある Add リンクをクリックします。
- 新しい DNS ゾーンに関する情報を入力します。ゾーン名が必要です。これは実際のドメイン名です。管理者メールおよび権威ネームサーバーに関するその他の情報は任意です。注記管理者にメールがある場合は、at 記号 (@) をピリオド (.) に置き換え、ゾーンファイルとの互換性を維持します。
- 追加および編集 ボタンをクリックして、DNS ゾーンページに直接移動します。Settings タブで、デフォルトのゾーン設定をリセットして、動的バインド (「Web UI での動的 DNS 更新の有効化」) を有効にするか、他のデフォルトレコード情報 (「Web UI でのゾーン設定編集」) を変更できます。DNS Resource Records タブで新しい DNS リソースレコード (「Web UI での DNS リソースレコードの追加」) の追加を開始することもできます。
17.6.1.2. コマンドラインでの操作
$ ipa dnszone-add domainName
- 新しいゾーンを追加します。以下に例を示します。
[root@server ~]# ipa dnszone-add newserver.example.com --admin-email=admin@example.com --minimum=3000 --dynamic-update
- ネームサービスを再読み込みします。
[root@server ~]# rndc reload
ヒントname サービスを再起動せずに新しいリソースレコードを即座に解決できるようにするには、named
サービスを使用した永続的な検索を有効にするか、BIND サービスを設定してゾーンの変更を自動的にポーリングします。「永続検索の無効化」を参照してください。
17.6.2. DNS ゾーンの追加設定の追加
例17.2 DNS ゾーンのデフォルトのエントリー設定
[root@server ~]# ipa dnszone-show server.example.com Zone name: server.example.com Authoritative nameserver: dns.example.com Administrator e-mail address: admin.example.com. SOA serial: 1377691702 SOA refresh: 3600 SOA retry: 900 SOA expire: 1209600 SOA minimum: 3000 Active zone: TRUE Allow query: any; Allow transfer: none;
17.6.2.1. DNS ゾーン設定の属性
属性 | コマンドラインオプション | 説明 |
---|---|---|
ゾーン名 | --name | ゾーンの名前を設定します。 |
権威ネームサーバー | --name-server | DNS ネームサーバーの完全修飾ドメイン名を設定します。 |
管理者の電子メールアドレス | --admin-email | ゾーン管理者が使用する電子メールアドレスを設定します。デフォルトでは、ホストの root アカウントになります。 |
SOA serial | --serial | SOA レコードファイルのバージョン番号を設定します。 |
SOA refresh | --refresh | セカンダリー DNS サーバーがプライマリ DNS サーバーから更新を要求するまでの待機時間を秒単位で設定します。 |
SOA retry | --retry | 失敗したリフレッシュ動作を再試行するまでの待機時間を秒単位で設定します。 |
SOA expire | --expire | セカンダリー DNS サーバーがリフレッシュ更新を試行して、その動作を停止するまでの時間を秒単位で設定します。 |
SOA minimum | --minimum | データがキャッシュに保持される最小時間 (秒単位) を設定します。 |
SOA time to live | --ttl | 情報がデータキャッシュに保持される最大時間 (秒単位) を設定します。 |
SOA クラス | --class | レコードのタイプを設定します。これはほとんどの場合で、インターネットを表します。 |
BIND 更新ポリシー | --update-policy | DNS ゾーンでクライアントに許可されるパーミッションを設定します。 |
Dynamic update | --dynamic-update=TRUE|FALSE | クライアントの DNS レコードへの動的更新を有効にします。
重要
false に設定すると、IdM クライアントマシンは IP アドレスを追加または更新できなくなります。詳細は、「ダイナミック DNS 更新の有効化」を参照してください。
|
ネームサーバー | --ip-address | IP アドレスで DNS ネームサーバーを追加します。 |
Allow transfer | --allow-transfer=string | 指定のゾーンを転送できる IP アドレスまたはネットワーク名のセミコロン区切りの一覧を指定します。 |
Allow query | --allow-query | DNS クエリーを発行できる IP アドレスまたはネットワーク名のセミコロン区切りの一覧を指定します。 |
Allow PTR sync | --allow-sync-ptr=1|0 | ゾーンの A または AAAA レコード (正引きレコード) が自動的に PTR (逆引き) レコードと同期されるかどうかを設定します。 |
Zone forwarders | --forwarder=string | DNS ゾーン向けに特別に設定されたフォワーダーを指定します。これは、IdM ドメインで使用されるグローバルフォワーダーとは別のものです。
複数のフォワーダーに固有の場合は、オプションを複数回使用します。
|
Forward policy | --forward-policy=only|first | ゾーンが DNS ネームサーバー (正引きのみのゾーン) へのリクエストのみを転送するかどうかを設定します。または、最初に DNS レコードをチェックしてから、独自のローカルレコードを確認するかどうかを設定します。 |
17.6.2.2. Web UI でのゾーン設定編集
- Identity タブを開き、DNS サブタブを選択します。
- 編集する DNS ゾーンの名前をクリックします。
- Settings タブを開きます。
- DNS ゾーン設定を変更します。属性の完全なリストは、表17.1「ゾーン属性」に記載されています。変更すべき一般的な属性はいくつかあります。
- 権威ネームサーバー。DNS ネームサーバーの完全修飾ドメイン名です。
- クライアントの DNS レコードへの 動的更新 を有効にするための動的更新。
- SOA 更新。セカンダリー DNS サーバーがプライマリ DNS サーバーから更新を要求するまでの待機時間を秒単位で設定します。
- 設定ページの上部にある Update リンクをクリックします。
17.6.2.3. コマンドラインでのゾーン設定の編集
[jsmith@server ~]$ kinit admin [jsmith@server ~]$ ipa dnszone-mod server.example.com --ttl=1800 Zone name: server.example.com Authoritative nameserver: dns.example.com Administrator e-mail address: admin.example.com. SOA serial: 1377691702 SOA refresh: 3600 SOA retry: 900 SOA expire: 1209600 SOA minimum: 3000 SOA time to live: 1800 Active zone: TRUE Allow query: any; Allow transfer: none;
17.6.3. 逆引き DNS ゾーンの追加
- ゾーン名で、reverse_ip_address.in-addr.arpa. 形式で指定します。
- network_ip_address/subnet_mask_bit_count の形式でのネットワークアドレス。
図17.1 名前での逆引きゾーンの作成
[bjensen@server ~]$ kinit [bjensen@server]$ ipa dnszone-add 206.65.10.in-addr.arpa.
図17.2 IP ネットワークでの逆引きゾーンの作成
[bjensen@server ~]$ kinit [bjensen@server]$ ipa dnszone-add 10.65.206.0/24
17.6.4. ゾーンの有効化と無効化
17.6.4.1. Web UI でのゾーンの無効化
- Identity タブを開き、DNS サブタブを選択します。
- 編集する DNS ゾーンの名前をクリックします。
- Settings タブを開きます。
- Active zone フィールドまでスクロールします。ゾーンを無効にするには、値を Disabled に設定します。
- 設定ページの上部にある Update リンクをクリックします。
17.6.4.2. コマンドラインでのゾーンの無効化
[jsmith@server ~]$ kinit admin [jsmith@server ~]$ ipa dnszone-disable server.example.com ----------------------------------------- Disabled DNS zone "server.example.com" -----------------------------------------
17.6.5. ダイナミック DNS 更新の有効化
17.6.5.1. Web UI での動的 DNS 更新の有効化
- Identity タブを開き、DNS サブタブを選択します。
- 編集する DNS ゾーンの名前をクリックします。
- Settings タブを開きます。
- Dynamic update フィールドまでスクロールして、値を True に設定します。
- 設定ページの上部にある Update リンクをクリックします。
17.6.5.2. コマンドラインでの動的 DNS 更新の有効化
--dynamic-update
オプションを設定します。
$ ipa dnszone-mod server.example.com --dynamic-update=TRUE
17.6.6. フォワーダーおよび Forward ポリシーの設定
- IdM のすべてのゾーンが使用するグローバルフォワーダーの一覧
- ゾーン設定の一部として、1 つの特定ゾーンによって使用されるフォワーダーの一覧
- ゾーンがフォワーダーに要求を送信する方法を定義するポリシー
17.6.6.1. UI でのフォワーダーの設定
- フォワーダーを追加するには、フィールドを入力するか、または Add をクリックして、新しい IP アドレスをフォワーダー一覧に追加します。
- デフォルトでは、ゾーンは、名前解決要求のサービスにのみフォワーダーを使用します。これは 正引きのみのゾーン と呼ばれます。前方のみのゾーンは、独自の名前レコードを確認しません。フォワーダーサーバーレコードのみがチェックされます。設定されたフォワーダーにレコードが存在しない場合は、ゾーンはクライアントに異常な状態を返します。また、ゾーンは最初にフォワーダーレコードを確認し、次に独自のリソースレコードにフォールバックできます。これには、最初 のポリシーがあります。
図17.3 DNS ゾーン設定のフォワーダー
17.6.6.2. コマンドラインでのフォワーダーの設定
例17.3 グローバルフォワーダーの設定
setup-dns
オプションを指定してサーバーをインストールする場合や ipa-dns-install スクリプトが使用される場合に設定されます (任意)。
[jsmith@server ~]$ ipa dnsconfig-mod --forwarder=0.9.8.7 Global forwarders: 0.9.8.7
例17.4 ゾーンフォワーダーの設定
--forwarder
オプションは、ゾーンで使用するフォワーダーの一覧を作成するために複数回使用できます。
[jsmith@server ~]$ ipa dnszone-mod --forwarder=192.0.2.0 --forwarder=198.51.100.0 example.com Zone name: example.com ... Zone forwarders: 192.0.2.0, 198.51.100.0
例17.5 ゾーンのフォワーダーポリシーの設定
--forward-policy
オプションで設定されます。たとえば、以下のようになります。
[jsmith@server ~]$ ipa dnszone-mod --forward-policy=only example.com Zone name: example.com ... Zone forwarders: 1.2.3.4;5.6.7.8 Forward policy: only
17.6.7. ゾーン転送の有効化
17.6.7.1. UI でのゾーン転送の有効化
図17.4 DNS ゾーンの転送設定
17.6.7.2. コマンドラインでゾーンの転送の有効化
--allow-transfer
オプションを使用してゾーンレコードを転送できるネームサーバーの一覧を設定するときに有効化できます。
[jsmith@server ~]$ ipa dnszone-mod --allow-transfer="0.0.0.0;1.2.3.4;5.6.7.8" example-zone
bind
サービスで有効にすると、dig のようなクライアントにより、名前で IdM DNS ゾーンを転送できます。
[root@server ~]# dig @ipa-server zone_name AXFR
17.6.8. DNS クエリーの定義
--allow-query
オプションを使用してクエリーを発行できるクライアントの一覧を設定するときに設定できます。
[jsmith@server ~]$ ipa dnszone-mod --allow-query=0.0.0.0;1.2.3.4;5.6.7.8 example-zone
17.6.9. 前方および逆引きゾーンエントリーの同期
- 正引きおよび逆引きゾーンの両方が IdM サーバーで管理されていること。
- 両方のゾーンで動的更新が有効になっていること。動的更新の有効化については、「ダイナミック DNS 更新の有効化」で説明されています。
- PTR レコードは、要求しているクライアント名が PTR レコード内の名前と一致する場合にのみ、更新されます。
17.6.9.1. UI でのゾーンエントリー同期の設定
図17.5 DNS ゾーンの同期設定
17.6.9.2. コマンドラインでゾーンエントリー同期の設定
--allow-sync-ptr
オプションを 1 に設定して、正引きおよび逆のエントリーを自動的に同期するように設定できます。これは、ゾーンの作成時または編集時に実行できます。
[jsmith@server ~]$ ipa dnszone-mod --allow-sync-ptr=1 example-zone
17.6.10. DNS アクセスポリシーの設定
/etc/named.conf
ファイルに作成されます。これは DNS アクセスルールを定義します。
17.6.10.1. UI での DNS アクセスポリシーの設定
grant|deny zoneName policyName recordName recordType
図17.6 DNS 更新ポリシーの設定
17.6.10.2. コマンドラインで DNS アクセスポリシーの設定
--update-policy
オプションを指定して設定され、その後のステートメントにアクセス制御ルールを使用します。
--update-policy "grant|deny zoneName policyName recordName recordType"
- ZoneName は、ルールを適用する IdM DNS ゾーンです。
- PolicyName は、BIND ルールに使用する名前です。
- recordName は、ルールを適用するリソースレコードを設定します。アスタリスク (*) は自己ルールに使用されます。
- RecordType は、ルールが適用されるレコードタイプです。更新アクセスルールは、同じ DNS ゾーンエントリー内であっても、レコードタイプごとに個別に適用されます。サポートされるレコードタイプの完全リストは、表17.2「DNS レコードタイプ」にあります。
$ ipa dnszone-mod example.com --update-policy="grant EXAMPLE.COM krb5-self * A; grant EXAMPLE.COM krb5-self * AAAA;"
17.7. DNS レコードエントリーの管理
17.7.1. DNS ゾーンへのレコードの追加
A | CERT | KX | NS | SIG |
AAAA | CNAME | LOC | NSEC | SRV |
A6 | DNAME | MX | PTR | SSHFP |
AFSDB | DS | PNATR | RRSIG | TXT |
17.7.1.1. Web UI での DNS リソースレコードの追加
named
サービスを使用した永続的な検索を有効にするか、BIND サービスを設定してゾーンの変更を自動的にポーリングします。「永続検索の無効化」を参照してください。
- Identity タブを開き、DNS サブタブを選択します。
- レコードを追加する DNS ゾーンの名前をクリックします。
- DNS Resource Record タブで、Add リンクをクリックします。
- Record Type ドロップダウンメニューで作成するレコードのタイプを選択します。レコードタイプに応じて、必要なデータは異なります。たとえば、CNAME レコードにはホスト名が必要です。データフィールド名は、どのような情報を提供すべきかを示すために自動的に更新されます。IdM は多くの異なるレコードタイプをサポートしますが、使用されている 4 つの頻繁にレコードタイプが使用されます。
- A.これは、ホスト名および通常の IPv4 アドレスの基本マップです。レコード名 は www などのホスト名です。IP アドレス の値は、192.168.1.2 などの標準の IPv4 アドレスです。A レコードの詳細は RFC 1035 を参照してください。
- AAAA.これは、ホスト名および IPv6 アドレスの基本マップです。レコード名 は www などのホスト名です。IP アドレス の値は、fe80::20c:29ff:fe02:a1b3 などの標準の 16 進数の IPv6 アドレスです。AAAA レコードの詳細は RFC 3596 を参照してください。
- SRV.サービス (SRV) リソースレコードは、サービス名を、その特定サービスを提供するサーバーの DNS 名にマッピングします。レコード名 のフォーマットは _service._protocol です (例: _ldap._tcp)。ターゲットサービスの優先順位、重み、ポート番号、およびホスト名を設定する個々のフィールドがあります。SRV レコードの詳細は、RFC 2782 を参照してください。
- PTR.ポインター (PTR) レコードは、IP アドレスをドメイン名にマッピングする逆引き DNS レコードを追加します。この場合、Record Name はリソースの DNS エントリーのレコード ID 番号で、Hostname の値は、server.example.com. などの端末期間が含まれるホスト名になります。PTR レコードの詳細は RFC 1035 を参照してください。
17.7.1.2. コマンドラインでの DNS リソースレコードの追加
17.7.1.2.1. DNS レコードを追加するコマンドについて
$ ipa dnsrecord-add zoneName recordName --recordType-option=data
全般的なレコードのオプション | |
---|---|
オプション | 説明 |
--ttl=number | レコードの有効期間を設定します。 |
--class=IN | CS | CH | HS | レコードのクラスを設定します。これは通常 IN です (インターネットプロトコルの場合)。 |
--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 | ターゲットホストのドメイン名を提供します。該当サービスがドメイン内で利用可能でない場合は、単一のピリオド (.) にすることもできます。 |
17.7.1.2.2. DNS リソースレコードの追加例
named
サービスを使用した永続的な検索を有効にするか、BIND サービスを設定してゾーンの変更を自動的にポーリングします。「永続検索の無効化」を参照してください。
例17.6 IPv4 レコード
$ ipa dnsrecord-add example.com www --a-rec 10.64.14.165これにより、IP アドレスが 10.64.14.165 のレコード www.example.com が作成されます。
例17.7 IPv4 レコードの変更
--a-record
になります。ただし、A レコードを変更すると、--a-record
オプションは A レコードの 古い 値を表示します。新しい値は、--ip-address
オプションで設定します。
$ ipa dnsrecord-mod example.com www --a-rec 10.1.1.1 --ip-address 10.1.1.2
例17.8 IPv6 レコード
$ ipa dnsrecord-add example.com www --aaaa-rec fe80::20c:29ff:fe02:a1b3これにより、IP アドレス fe80::20c:29ff:fe02:a1b3 のレコード www.example.com が作成されます。AAAA レコードの詳細は RFC 3596 を参照してください。
例17.9 SRV レコード
[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."
例17.10 PTR レコード
in-addr.arpa.
ドメインで定義される逆引きエントリーを使用します。人間が判別可能な形式の逆アドレスは、通常の IP とまったく逆で、in-addr.arpa.
ドメインが最後に付いています。たとえば、ネットワークアドレス 192.0.2.0/24
の逆引きゾーンは、2.0.192.in-addr.arpa
になります。
$ ipa dnsrecord-add reverseZone recordName --ptr-rec FQDN
192.0.1.2
のホスト server2.example.com
の 1.0.192.in-addr.arpa.
逆引きゾーンに逆引き DNS エントリーが追加されます。
$ ipa dnsrecord-add 1.0.192.in-addr.arpa. 2 --ptr-rec server2.example.com.
0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa
に逆引き DNS エントリーを追加します。IP アドレスが 2001:DB8::1111
の server2.example.com
ホストの IPv 6 逆引きゾーン。
$ 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.
17.7.2. DNS ゾーンからレコードを削除する
17.7.2.1. Web UI でレコードの削除
- Identity タブを開き、DNS サブタブを選択します。
- DNS ゾーンの名前をクリックします。
- DNS Resource Record タブで、リソースレコードの名前をクリックします。
- 削除するレコードタイプ名のチェックボックスをクリックし、一覧の上部にあるアクティブな Delete リンクをクリックします。これにより、他の設定をそのまま残すと、そのレコードタイプのみが削除されます。
- Identity タブを開き、DNS サブタブを選択します。
- DNS ゾーンの名前をクリックします。
- DNS Resource Record タブで、削除するリソースレコードの名前でチェックボックスを選択します。これにより、レコード全体が削除されます。
- ゾーンレコードページの上部にある Delete リンクをクリックします。
17.7.2.2. コマンドラインでレコードの削除
--
recordType-rec
) とレコード値を指定するオプションを使用してレコードが削除されます。
$ ipa dnsrecord-del example.com www --a-rec 10.64.14.213
--del-all
オプションを使用して、ゾーンに関連付けられたすべてのレコードを削除します。
17.8. bind-dyndb-ldap プラグインの設定
bind-dyndb-ldap
システムプラグインには、ゾーン用の DNS レコードキャッシュと、成功した DNS 解決の履歴が含まれます。新しい DNS リクエストが存在するたびにディレクトリーサービスのクエリーを実行する必要がなくなるため、キャッシュを維持すると Directory Server でルックアップパフォーマンスが向上します。
例17.11 デフォルトの dynamic-db 設定
dynamic-db "ipa" { library "ldap.so"; arg "uri ldapi://%2fvar%2frun%2fslapd-EXAMPLE.socket"; arg "base cn=dns,dc=example,dc=com"; arg "fake_mname server.example.com."; arg "auth_method sasl"; arg "sasl_mech GSSAPI"; arg "sasl_user DNS/server.example.com"; arg "zone_refresh 0"; arg "psearch yes"; arg "serial_autoincrement 1"; };
arg "argument value";
# rndc reload
パラメーター | 説明 | デフォルト値 |
---|---|---|
cache_ttl | Directory Server の DNS 設定に新しいゾーンがあるかどうかを確認します。 | 120 (秒)。これは bind-dyndb-ldap プラグインで定義されます。 |
zone_refresh | サーバーが新しいゾーンについて Directory Server の DNS 設定を確認する頻度 (秒単位) をチェックします。 | 0 (無効) |
psearch | Directory Server の永続的な検索を有効にし、BIND サービスが新しい DNS ゾーンが追加されると直ちに更新通知を受け取ります。 | yes |
17.8.1. DNS キャッシュ設定の変更
cache_ttl
パラメーターを追加してパフォーマンスを向上させるためにキャッシュ時間を増やすことができます。
dynamic-db "ipa" { ... arg "cache_ttl 1800"; };
17.8.2. 永続検索の無効化
bind-dyndb-ldap
プラグインを介してその情報を受信します。プラグインは、ネームサーバーの起動時に Directory Server で設定および有効化されたゾーンのみを解決します。ネームサービスが再起動すると、プラグインはその設定を再読み込みし、新しいゾーンまたは新しいリソースレコードを特定します。
bind-dyndb-ldap
プラグインは、IdM LDAP ディレクトリーからゾーンおよびリソースレコード情報をプルします。また、プラグインを再起動するだけで、そのディレクトリーから情報をプルできます。bind-dyndb-ldap
プラグインは、Directory Server への永続的な接続を開き、変更を即座にキャッチすることで、ゾーンの変更をアクティブに検索します。
psearch
引数で無効にできます。
dynamic-db "ipa" { ... arg "psearch no"; };
17.9. 再帰クエリーの変更
/etc/named.conf
ファイルに設定します。(これには、DNS が設定され、フォワーダーが設定されている状態で IdM サーバーを設定する必要があります。) つまり、すべてのホストが、設定されたフォワーダーに対して再帰クエリーを発行できることを意味します。
/etc/named.conf
ファイルに自動的に行を追加して、再帰クエリーを許可します。
forward first;
forwarders { 10.16.36.29; };
allow-recursion { any; };
/etc/named.conf
ファイルを開きます。- allow-recursion ステートメントをリセットします。これは、デフォルトで any に設定され、すべてのホストがすべてのフォワーダーに対して名前を解決できるようにします。
forward first; forwarders { 10.16.36.29; };
allow-recursion { any; };
- named サービスを再起動します。
service named restart
17.10. IdM ドメインのホスト名の解決
$ipa dns-resolve server1.example.com
第18章 ポリシー: 自動マウントの使用
18.1. 自動マウントと IdM
/etc/
ディレクトリー内の auto.master
ファイルです。必要に応じて、複数の auto.master
設定ファイルが別々のサーバーの場所にある可能性があります。
auto.master
に保存されます。
dn: automountmapname=auto.master,cn=default,cn=automount,dc=example,dc=com objectClass: automountMap objectClass: top automountMapName: auto.master
- 場所、コマンドの ipa automountlocation* 使用
- ipa automountmap* コマンドを使用したダイレクトマップと間接・直接 マップ の両方
- キー、コマンドの ipa automountkey* 使用
18.2. 自動マウントの設定
/home
ディレクトリーを正常にマウントできることをテストします。NFS が既に正常に機能しているこを確認すると、後で ldM 自動マウント設定エラーが発生しても解決が容易になります。
18.2.1. NFS の自動設定
/etc/sysconfig/nfs
および /etc/idmapd.conf
) を自動的に設定します。また、SSSD が NFS の認証情報を管理するようにも設定します。
[root@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=raleigh
- サービスの設定情報が SSSD 設定に追加されます。IdM ドメインエントリーには、autofs プロバイダーとマウントの場所の設定があります。
autofs_provider = ipa ipa_automount_location = default
NFS は、対応しているサービスのリスト (services = nss,pam,autofs...) に追加され、空の設定エントリー([autofs]) が指定されます。 - Name Service Switch (NSS) サービス情報が更新され、自動マウント情報についてまず SSSD がチェックされ、次にローカルファイルがチェックされます。
automount: sss files
--no-sssd
オプションを使用して ipa-client-automount コマンドを実行できます。これにより、必要なすべての NFS 設定ファイルが変更されますが、SSSD 設定は変更されません。
[root@server ~]# ipa-client-automount --no-sssd
- このコマンドにより、
/etc/sysconfig/nfs
ではなく/etc/sysconfig/autofs
が更新されます。 - このコマンドは、IdM LDAP 設定で
/etc/autofs_ldap_auth.conf
を設定します。 - このコマンドは、自動マウントマップに LDAP サービスを使用するように
/etc/nsswitch.conf
を設定します。
18.2.2. SSSD および Identity Management を使用するように autofs を手動で設定
- autofs が検索するスキーマ属性を指定するには、
/etc/sysconfig/autofs
ファイルを編集します。# # Other common LDAP naming # MAP_OBJECT_CLASS="automountMap" ENTRY_OBJECT_CLASS="automount" MAP_ATTRIBUTE="automountMapName" ENTRY_ATTRIBUTE="automountKey" VALUE_ATTRIBUTE="automountInformation"
- LDAP 設定を指定します。これには 2 通りの方法があります。最も簡単な方法は、自動マウントサービスが 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"
注記 - autofs が IdM LDAP サーバーによるクライアント認証を許可するように
/etc/autofs_ldap_auth.conf
ファイルを編集します。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 ~]# service sssd restart
- SSSD が自動マウント設定のソースとして一覧表示されるように、
/etc/nsswitch.conf
ファイルを確認します。automount:
sss
files - Restart autofs:
[root@server ~]# service autofs restart
- ユーザーの
/home
ディレクトリーを一覧表示して、設定をテストします。[root@server ~]# ls /home/userName
リモートファイルシステムをマウントしない場合は、/var/log/messages
ファイルでエラーを確認します。必要に応じて、LOGGING
パラメーターをdebug
に設定して、/etc/sysconfig/autofs
ファイルのデバッグレベルを増やします。
automount -f -dこれで LDAP のアクセスログと自動マウントのログを相互参照することなく、デバッグのログ情報が直接出力されます。
18.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=5
- 自動マウント を有効にします。
# 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
18.3. Kerberized NFS サーバーの設定
18.3.1. Kerberized NFS サーバーの設定
- IdM ユーティリティを実行する前に、Kerberos チケットを取得します。
[user@server ~]$ kinit admin
- NFS ホストマシンが IdM ドメインにクライアントとして追加されていない場合は、「ホストエントリーを追加する他の例」の説明に従って GUI でホストエントリーを作成するか、以下のようなコマンドを実行します。
[user@server ~]$ ipa host-add --ip-address 192.0.2.10 nfs-server.example.org
- IdM ドメインに NFS サービスエントリーを作成します。以下に例を示します。
[user@server ~]$ ipa service-add nfs/nfs-server.example.com
詳細は「サービスエントリーおよびキータブの追加と編集」を参照してください。 ipa-getkeytab
コマンドを使用して、NFS サーバーの NFS サービスキータブを生成します。NFS サーバーは、IdM ドメインの Red Hat Enterprise Linux マシンまたは別の Unix マシン上にある場合があります。Red Hat Enterprise Linux マシンでは、NFS サーバーマシンで ipa-getkeytab コマンドを実行できます。それ以外の場合は、IdM ドメインの Red Hat Enterprise Linux マシンで ipa-getkeytab コマンドを実行してから、NFS サーバーにコピーする必要があります。ipa-getkeytab コマンドが NFS サーバーで実行されている場合は、キーをホストキータブに直接保存します。たとえば、以下のようになります。[user@server ~]$ ipa-getkeytab -s server.example.com -p nfs/nfs-server.example.com -k /etc/krb5.keytab
Red Hat Enterprise Linux マシンでは、必要なのはそれだけです。別のシステムにコピーするキーを生成する場合は、鍵を生成しますが、その鍵はホストのキータブに保存されません。キーは、NFS サーバーにコピーした後にキーをキータブに個別に追加する必要があります。- キータブを一時ファイルに保存します。以下に例を示します。
[user@server ~]$ ipa-getkeytab -s server.example.com -p nfs/nfs-server.example.com -k /root/nfs-server.keytab
- キータブを NFS サーバーにコピーします。
- ファイルのパーミッションを
0700
に設定します。 - サービスキーをキータブファイルに追加します。
[root@nfs-server ~]# ( echo rkt /root/nfs-server.keytab; echo wkt /etc/krb5.keytab ) | ktutil
注記NFS サービスがキータブで IdM で適切に設定されていることを確認するには、次のコマンドを実行してサービスエントリーを確認します。[user@server ~]$ ipa service-show nfs/ipaclient2.example.com Principal: NFS/ipaclient2.example.com@EXAMPLE.COM Keytab: True
- NFS パッケージをインストールします。以下に例を示します。
[root@nfs-server ~]# yum install nfs-utils
- 弱い暗号化サポートを設定します。ドメインのクライアント (Red Hat Enterprise Linux 5 クライアントなど) が DES などの古い暗号化オプションを使用する場合は、NFS クライアントごとに必要です。
- 以下の行を追加して
krb5.conf
ファイルを編集して、弱い暗号化を有効にします。allow_weak_crypto = true
- IdM サーバーの Kerberos 設定を更新して、DES 暗号化タイプに対応します。
[user@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 が有効になり、/etc/idmapd.conf
ファイルのDomain
パラメーターで IdM DNS ドメインが設定されます。注記サーバーが IdM ドメインのメンバーではない場合は (ipa-client パッケージがインストールされていない)、この手順を手動で行う必要があります。詳細は、ストレージ管理ガイドの NFS 設定セクションを参照してください。 /etc/exports
ファイルを編集し、Kerberos 情報を追加します。/export *(rw,sec=krb5:krb5i:krb5p)
- NFS サーバーおよび関連サービスを再起動します。
[root@nfs-server ~]# service nfs restart [root@nfs-server ~]# service rpcsvcgssd restart
- NFS サーバーを NFS クライアントとして設定する場合は、「Kerberized NFS クライアントの設定」を参照してください。
18.3.2. Kerberized NFS クライアントの設定
- IdM ツールを実行する前に、Kerberos チケットを取得します。
[user@server ~]$ kinit admin
- NFS クライアントが IdM ドメインのクライアントとして登録されていない場合は、「ホストエントリーを追加する他の例」の説明に従って GUI で必要なホストエントリーを設定するか 、以下のようなコマンドを実行します。
[user@server ~]$ ipa host-add --ip-address 192.0.2.20 nfs-client.example.org
- この ipa-getkeytab ユーティリティーを使用して、NFS クライアントの NFS サービスキータブを生成します。NFS クライアントは、IdM ドメインの Red Hat Enterprise Linux マシンまたは別の Unix マシン上にある場合があります。Red Hat Enterprise Linux マシンでは、NFS クライアントマシンで ipa-getkeytab コマンドを実行できます。それ以外の場合は、IdM ドメインの Red Hat Enterprise Linux マシンで ipa-getkeytab コマンドを実行してから、NFS サーバーにコピーする必要があります。ipa-getkeytab コマンドが NFS クライアントで実行している場合は、キーをホストキータブに直接保存します。たとえば、以下のようになります。
[user@server ~]$ ipa-getkeytab -k /etc/krb5.keytab -s ipa-server.example.org -p nfs/nfs-client-server.example.com@EXAMPLE.COM
Red Hat Enterprise Linux マシンでは、必要なのはそれだけです。別のシステムにコピーするキーを生成する場合は、鍵を生成しますが、その鍵はホストのキータブに保存されません。キーは、NFS サーバーにコピーした後にキーをキータブに個別に追加する必要があります。- キータブを一時ファイルに保存します。以下に例を示します。
[user@server ~]$ ipa-getkeytab -s ipa-server.example.org -p host/nfs-client-server.example.com@EXAMPLE.COM -k /root/nfs-client.keytab
- キータブを NFS クライアントにコピーします。
- ファイルのパーミッションを
0700
に設定します。 - サービスキーをキータブファイルに追加します。
[root@nfs-client-server ~]# ( echo rkt /root/nfs-client.keytab; echo wkt /etc/krb5.keytab ) | ktutil
- ipa-client-automount コマンドを実行して、NFS 設定を構成します。デフォルトでは、これにより
/etc/sysconfig/nfs
ファイルでセキュアな NFS が有効になり、/etc/idmapd.conf
ファイルのDomain
パラメーターで IdM DNS ドメインが設定されます。注記クライアントが IdM ドメインのメンバーではない場合は (ipa-client パッケージがインストールされていない)、この手順を手動で行う必要があります。詳細は、ストレージ管理ガイドの NFS 設定セクションを参照してください。 - GSS デーモンを起動します。
[root@nfs-client-server ~]# service rpcgssd start [root@nfs-client-server ~]# service rpcbind start [root@nfs-client-server ~]# service rpcidmapd start
- ディレクトリーをマウントします。
[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
18.4. 場所の設定
auto.master
に保存され、場所は複数のマップを保存できます。また、場所には複数のマップを保存できます。場所のエントリーは、マップエントリーのコンテナーとしてのみ機能します。それ自体は、自動マウント設定ではありません。
18.4.1. Web UI での場所の設定
- Policy タブをクリックします。
- Automount サブタブをクリックします。
- 自動マウントの場所一覧の上部にある Add リンクをクリックします。
- 新しい場所の名前を入力します。
- 「Web UI でのダイレクトマップの設定」および「Web UI での間接マップの設定」にあるように、マップを作成します。をクリックして、新規の場所のマップ設定に移動します。
18.4.2. コマンドラインでの場所の設定
$ ipa automountlocation-add locationたとえば、以下のようになります。
$ ipa automountlocation-add raleigh ---------------------------------- Added automount location "raleigh" ---------------------------------- Location: raleigh
auto.master
および auto.direct
が自動的に作成されます。auto.master
は、その場所のすべての自動マウントマップのルートマップです。auto.direct
は、ダイレクトマウント用のデフォルトのマップで、/-
にマウントされます。
$ ipa automountlocation-tofiles raleigh /etc/auto.master: /- /etc/auto.direct --------------------------- /etc/auto.direct:
18.5. マップの設定
18.5.1. ダイレクトマップの設定
--------------------------- /etc/auto.direct: /shared/man server.example.com:/shared/man
18.5.1.1. Web UI でのダイレクトマップの設定
- Policy タブをクリックします。
- Automount サブタブをクリックします。
- マップの追加先となる automount の場所の名前をクリックします。
- Automount Maps タブで Add をクリックして新規マップを作成します。
- ポップアップウィンドウで Direct ラジオボタンを選択し、新規マップの名前を入力します。
- Automount Keys タブで +Add をクリックしてマップの新規キーを作成します。
- マウントポイントを入力します。key では、実際のマウントポイントを key の名前で定義します。Info フィールドは、ディレクトリーのネットワークの場所と、使用する mount オプションを設定します。
18.5.1.2. コマンドラインでのダイレクトマップの設定
auto.direct
アイテムと共に作成されます。最もシンプルな設定では、automount キーを既存のダイレクトマップエントリーに追加することでダイレクトマップを定義します。異なるダイレクトマップエントリーを作成することも可能です。
auto.direct
ファイルに追加します。--key
オプションはマウントポイントを特定し、--info
がディレクトリーのネットワークの場所と、使用する mount オプションを指定します。たとえば、以下のようになります。
$ 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 -a serviceSearchDescriptor=auto_direct:automountMapName=auto.direct,cn=location,cn=automount,dc=example,dc=com?one
18.5.2. 間接マップの設定
/docs
で、キーが man
の場合は、マップは /docs/man
になります。
18.5.2.1. Web UI での間接マップの設定
- Policy タブをクリックします。
- Automount サブタブをクリックします。
- マップの追加先となる automount の場所の名前をクリックします。
- Automount Maps タブで Add をクリックして新規マップを作成します。
- ポップアップウィンドウで Indirect ラジオボタンを選択し、以下の必要な間接マップの情報を入力します。
- 新規マップの名前
- マウントポイント。Mount フィールドでは、すべての間接マップキーに使用するベースディレクトリーを設定します。
- オプションで親マップ。デフォルトの親は
auto.master
ですが、使用する別のマップがある場合は、Parent Map フィールドでそれを指定できます。
18.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 -a serviceSearchDescriptor=auto_share:automountMapName=auto.share,cn=location,cn=automount,dc=example,dc=com?one
18.5.3. 自動マウントマップのインポート
ipa automountlocation-import location map_file [--continuous]
--continuous
オプションでは、automountlocation-import コマンドに対して、エラーが発生した場合でも、マップファイルを継続するように指示します。
$ ipa automountlocation-import raleigh /etc/custom.map
第19章 ポリシー: パスワードポリシーの定義
19.1. パスワードポリシーとポリシー属性
- 強度または複雑さの要件
- 履歴
- アカウントのロックアウト
設定プロパティー | コマンドラインオプション | 説明 |
---|---|---|
UI と CLI の両方のオプション | ||
パスワードの最小ライフタイム | --minlife | ユーザーがユーザーのパスワードを変更できる前に、ユーザーのパスワードが有効でなけらばならない最低限の時間を時で設定します。これにより、ユーザーがパスワードを変更できず、即座に元の値に変更される可能性があります。デフォルト値は 1 時間です。 |
パスワードの最大有効期間 | --maxlife | ユーザーのパスワードの変更前に有効になる最大期間を日数単位で設定します。デフォルト値は 90 日です。 |
文字クラスの最小数 | --minclasses | 有効とみなされる前にパスワードに存在する必要がある異なるクラス、タイプ、文字の最小値を設定します。たとえば、この値を 3 に設定すると、承認には、パスワードに最低 3 つのカテゴリーからの文字が必要となります。デフォルト値はゼロ (0) で、必要なクラスがないことを意味します。
6 つの文字クラスがあります。
|
パスワードの最小長 | --minlength | パスワードの最小文字数を設定します。デフォルト値は 8 文字です。 |
パスワード履歴 | --history | 保存する以前のパスワードの数と、ユーザーが使用できないパスワード数を設定します。たとえば、これが 10 に設定されている場合は、IdM により、ユーザーは以前の 10 つのパスワードを再利用できなくなります。デフォルト値はゼロ (0) で、パスワード履歴を無効にします。
注記
パスワード履歴がゼロに設定された場合でも、ユーザーは 現在 のパスワードを再利用できます。
|
CLI のみのオプション | ||
優先度 | --priority | 有効なポリシーを決定する優先度を設定します。数値が小さいほど優先度が高くなります。
この優先順位は、UI でポリシーを最初に作成する際に必要ですが、UI でリセットすることはできません。これは CLI を使用してのみリセットできます。
|
連続不具合の最大数 | --maxfail | ユーザーのアカウントがロックされる前に、正しいパスワードを入力する最大失敗数を指定します。 |
失敗間隔 | --failinterval | 障害数がリセットされる期間 (秒単位) を指定します。 |
ロックアウト時間 | --lockouttime | ロックアウトの実施期間 (秒単位) を指定します。 |
19.2. パスワードポリシーの表示
19.2.1. グローバルパスワードポリシーの表示
属性 | 値 |
---|---|
Max lifetime | 90 (日) |
Min lifetime | 1 (時間) |
History size | 0 (未設定) |
Character クラス | 0 (未設定) |
Min length | 8 |
Max failures | 6 |
Failure reset interval | 60 |
Lockout duration | 600 |
19.2.1.1. Web UI の使用
- Policy タブをクリックし、Password Policies サブタブをクリックします。
- UI のすべてのポリシーがグループごとに一覧表示されます。グローバルパスワードポリシーは、global_policy グループによって定義されます。グループリンクをクリックします。
- グローバルポリシーが表示されます。
19.2.1.2. コマンドラインの使用
[root@server ~]# kinit admin [root@server ~]# ipa pwpolicy-show Group: global_policy Max lifetime (days): 90 Min lifetime (hours): 1 History size: 0 Character classes: 0 Min length: 8 Max failures: 6 Failure reset interval: 60 Lockout duration: 600
19.2.2. グループレベルのパスワードポリシーの表示
19.2.2.1. Web UI の使用
- Policy タブをクリックし、Password Policies サブタブをクリックします。
- UI のすべてのポリシーがグループごとに一覧表示されます。ポリシーを割り当てられたグループの名前をクリックします。
- グループポリシーが表示されます。
19.2.2.2. コマンドラインの使用
[root@server ~]# kinit admin [root@server ~]# ipa pwpolicy-show ipausers Group: ipausers Max lifetime (days): 120 Min lifetime (hours): 10 Min length: 10 Priority: 50
19.2.3. ユーザーの有効なパスワードポリシーの表示
[root@server ~]# kinit admin [root@server ~]# ipa pwpolicy-show --user=jsmith Group: global_policy Max lifetime (days): 90 Min lifetime (hours): 1 History size: 0 Character classes: 0 Min length: 8 Max failures: 6 Failure reset interval: 60 Lockout duration: 600
19.3. パスワードポリシーの作成および編集
19.3.1. Web UI でのパスワードポリシーの作成
- Policy タブをクリックし、Password Policies サブタブをクリックします。
- UI のすべてのポリシーがグループごとに一覧表示されます。グローバルパスワードポリシーは、global_policy グループによって定義されます。グループリンクをクリックします。
- 上部の Add リンクをクリックします。
- ポップアップボックスで、パスワードポリシーを作成するグループを選択します。
- ポリシーの優先度を設定します。数値が大きいほど優先度が低くなります。最も優先度ポリシーの番号は最も低くなります。ユーザーに対して有効になっているパスワードポリシーは 1 つだけで、最も優先度が高いポリシーです。注記ポリシーの作成後に優先順位は UI で変更できません。
- ポリシーフィールドを設定します。フィールドを空白のままにすると、属性がパスワードポリシー設定に追加されないことを意味します。
- Max lifetime は、パスワードのリセットが必要になるまでの、パスワードの最長有効期間を日数単位で設定します。
- 最小ライフタイム は、パスワードの変更が許可される前に、パスワードが有効である必要のある最小時間 (時間単位) を設定します。これにより、ユーザーがパスワードをすぐに古いパスワードに戻さなくしたり、パスワード履歴をサイクリングしないようにします。
- 履歴サイズ は、保存する以前のパスワードの数を設定します。ユーザーは、パスワード履歴にあるパスワードを再使用することはできません。
- 文字クラス は、パスワードで使用する必要があるさまざまなカテゴリーの文字 数 を設定します。これは、使用する必要があるクラスを設定しません。パスワードで使用する必要がある異なる (指定されていない) クラスの数を設定します。たとえば、文字クラスには数字、特殊文字、大文字を使用できます。カテゴリーの完全なリストは 表19.1「パスワードポリシー設定」にあります。これは、複雑な要件の設定の一部です。
- 最小長 は、パスワードで必要な文字数を設定します。これは、複雑な要件の設定の一部です。
19.3.2. コマンドラインでのパスワードポリシーの作成
[root@server ~]# kinit admin [root@server ~]# ipa pwpolicy-add groupName --attribute-value
[root@server ~]# kinit admin [root@server ~]# ipa pwpolicy-add exampleGroup --minlife=7 --maxlife=49 --history= --priority=1 Group: exampleGroup Max lifetime (days): 49 Min lifetime (hours): 7 Priority: 1
19.3.3. コマンドラインでパスワードポリシーの編集
[jsmith@ipaserver ~]$ ipa pwpolicy-mod exampleGroup --lockouttime=300 --history=5 --minlength=8
[jsmith@ipaserver ~]$ ipa pwpolicy-mod --lockouttime=300 --history=5 --minlength=8
19.4. パスワード有効期限の制限の管理
- パスワードポリシー (
--maxlife
) で指定される最大有効期間設定 - 指定のユーザーのパスワードが期限切れになる実際の日付 (
krbPasswordExpiration
)
krbPasswordExpiration
属性値をリセットします。これは、ldapmodify を使用してのみ実行できます。単一ユーザーの場合、以下のようにします。
[bjensen@ipaserver ~]$ ldapmodify -D "cn=Directory Manager" -w secret -h ipaserver.example.com -p 389 -vv dn: uid=jsmith,cn=users,cn=accounts,dc=example,dc=com changetype: modify replace: krbpasswordexpiration krbpasswordexpiration: 20140202203734Z -
-f
オプションで LDIF ファイルを ldamodify コマンドで参照して、複数のエントリーを同時に編集できます。
19.5. グループパスワードポリシーの優先順位の変更
--priority
オプションをリセットすると、ポリシーの作成後に変更できます。
[root@server ~]# kinit admin [root@server ~]# ipa pwpolicy-mod examplegroup --priority=10
19.6. アカウントロックアウトポリシーの設定
19.6.1. UI で
- Policy タブをクリックし、Password Policies サブタブをクリックします。
- 編集するポリシーの名前をクリックします。
- アカウントロックアウト属性の値を設定します。アカウントロックアウトポリシーには、以下の 3 つの部分があります。
- アカウントがロックされるまでの失敗したログイン試行回数 (最大失敗)。
- カウンターをリセットする前にログインに失敗した時間 (Failure reset interval)。ミスが生じるため、失敗した試行の数は永久に保持されず、一定時間が経過すると、警告に経過します。これは、特定の時間が経過したときに自然に起こります。これは秒単位です。
- 最大失敗回数 (Lockout duration) に達した後にアカウントがロックされる時間。これは秒単位です。
19.6.2. コマンドラインでの設定
- アカウントがロックされるまでの失敗したログイン試行回数 (
--maxfail
)。 - 最大失敗数に達した後にアカウントがロックされる時間 (
--lockouttime
)。これは秒単位です。 - カウンターをリセットするまでのログイン試行に失敗する時間 (
--failinterval
)。ミスが生じるため、失敗した試行の数は永久に保持されず、一定時間が経過すると、警告に経過します。これは、特定の時間が経過したときに自然に起こります。これは秒単位です。
[jsmith@ipaserver ~]$ kinit admin [jsmith@ipaserver ~]$ ipa pwpolicy-mod examplegroup --maxfail=4 --lockouttime=600 --failinterval=30
19.7. パスワード変更ダイアログの有効化
/etc/ssh/sshd_config
ファイルを開きます。ChallengeResponseAuthentication
をyes
に設定します。
第20章 ポリシー: Kerberos ドメインの管理
20.1. Kerberos について
/etc/krb5.keytab
ファイルに保存されます。このホストプリンシパルはホストレコードに格納されるため、ローカルサービスコマンドをこのプリンシパルと使用できません。これにより、IdM レルムで機能するクライアントが準備されます。
20.1.1. プリンシパル名
identifier@REALM
service/FQDN@REALM
sshd
デーモンはホストサービスプリンシパルを使用します。
/etc/krb5.keytab
に保存されます。
www.example.com CNAME web-01.example.com web-01.example.com A 192.0.2.145
$ ssh www.example.com
20.1.2. キータブの保護について
/etc/httpd/conf/ipa.keytab
) の所有者を apache
に設定し、モードを 0600
に設定します。
20.2. Kerberos チケットポリシーの設定
20.2.1. グローバルチケットポリシーの設定
20.2.1.1. Web UI での操作
- Policy タブをクリックし、Kerberos Ticket Policy サブタブをクリックします。
- チケットライフタイムポリシーを変更します。
- 最大更新 は、チケットの期限が切れた後に更新できる期間を設定します。
- Maximum life は、Kerberos チケットのアクティブな期間 (ライフサイクル) を設定します。
- ポリシーページの上部にある Update リンクをクリックします。
- KDC を再起動します。
# service krb5kdc restart
重要グローバル Kerberos チケットポリシーを変更するには、KDC を再起動して変更を反映する必要があります。
20.2.1.2. コマンドラインでの操作
# ipa krbtpolicy-mod --maxlife=3600 --maxrenew=18000 Max life: 3600 Max renew: 18000
# service krb5kdc restart
20.2.2. ユーザーレベルのチケットポリシーの設定
# ipa krbtpolicy-mod jsmith --maxlife=3600 Max life: 3600
20.3. Kerberos チケットの更新
- 必須の日付の前に発行されたすべてのキータブを見つけます。たとえば、2010 年 1 月 1 日から、2010 年 12 月 31 日の午後 11:59 の間に作成されたプリンシパルを探します。
# ldapsearch -x -b "cn=computers,cn=accounts,dc=example,dc=com" "(&(krblastpwdchange>=20100101000000)(krblastpwdchange<=20101231235959))" dn krbprincipalname # ldapsearch -x -b "cn=services,cn=accounts,dc=example,dc=com" "(&(krblastpwdchange>=20100101000000)(krblastpwdchange<=20101231235959))" dn krbprincipalname
- ホスト (マシン) プリンシパルは cn=computers,cn=accounts,dc=example,dc=com サブツリーに保存されます。
- サービスプリンシパルは cn=services,cn=accounts,dc=example,dc=com サブツリーに保存されます。
- 最終変更日 (
krblastpwdchange
) で絞り込みます。 dn krbprincipalname
属性を指定して、検索結果の情報をエントリー名とプリンシパルにのみ制限します。
日付は、YYYYMMDD 形式で表現され、時刻は HHMMSS 形式 (GMT) で表されます。 - ipa-getkeytab コマンドを使用して、プリンシパルの新しいキータブを取得します。これには、サービスまたはホストの元のキータブの場所 (
-k
)、プリンシパル (-p
)、および IdM サーバーのホスト名 (-s
) が必要です。たとえば、これにより、以下のように/etc/krb5.keytab
のデフォルトのキータブでホストプリンシパルが更新されます。# ipa-getkeytab -p host/client.example.com@EXAMPLE.COM -s ipa.example.com -k /etc/krb5.keytab
これにより、Apache サービスのキータブが、/etc/httpd/conf/ipa.keytab
のデフォルトの場所にあるキータブで更新されます。# ipa-getkeytab -p HTTP/client.example.com@EXAMPLE.COM -s ipa.example.com -k /etc/httpd/conf/ipa.keytab
- すべてのサービスに使用するキータブ ipa-getkeytab を再生成します。
# klist -kt /etc/krb5.keytab Keytab: WRFILE:/etc/krb5.keytab KVNO Timestamp Principal ---- ----------------- -------------------------------------------------------- 1 06/09/10 11:23:01 host/client.example.com@EXAMPLE.COM(aes256-cts-hmac-sha1-96) 2 06/09/11 05:58:47 host/client.example.com@EXAMPLE.COM(aes256-cts-hmac-sha1-96) 1 03/09/11 13:57:16 krbtgt/EXAMPLE.COM@EXAMPLE.COM(aes256-cts-hmac-sha1-96) 1 03/09/11 13:57:16 HTTP/ipa.example.com@EXAMPLE.COM(aes256-cts-hmac-sha1-96) 1 03/09/11 13:57:16 ldap/ipa.example.com@EXAMPLE.COM(aes256-cts-hmac-sha1-96)
20.4. Kerberos パスワードのキャッシュ
/etc/sssd/sssd.conf
ファイルは、IdM ドメインの Kerberos パスワードを保存するように SSSD に指示します。
[domain/example.com] cache_credentials = True ipa_domain = example.com id_provider = ipa auth_provider = ipa access_provider = ipa chpass_provider = ipa ipa_server = _srv_, server.example.com krb5_store_password_if_offline = true
--no-krb5-offline-passwords
オプションを使用してクライアントのインストール時に無効にできます。
/etc/sssd/sssd.conf
ファイルを編集し、krb5_store_password_if_offline
行を削除したり、その値を false に変更したりして無効にすることもできます。
[domain/example.com] ... krb5_store_password_if_offline = false
20.5. キータブの削除
-r
オプションでレルムを指定します。
# ipa-rmkeytab -r EXAMPLE.COM -k /etc/krb5.keytab
-p
オプションを指定してサービスプリンシパルを指定します。
# ipa-rmkeytab -p ldap/client.example.com -k /etc/krb5.keytab
第21章 ポリシー: sudo の使用
21.1. sudo および IPA について
21.1.1. Identity Management の全般的な sudo 設定
/etc/sudoers
使用します。このファイルは、コマンドや sudo アクセスのあるユーザーを定義します。このファイルはマシン間で共有できますが、マシン間で sudo 設定ファイルを分散するネイティブの方法はありません。
- Identity Management スキーマは、sudo netgroups に加え、ホストグループに対応します。一方、sudo は netgroups のみに対応します。Identity Management は、すべてのホストグループに対応するシャドウ netgroup も作成します。これにより、IdM 管理者はホストグループを参照する sudo ルールを作成できますが、ローカルの sudo コマンドは対応する netgroup を使用します。
- Identity Management では、sudo コマンドグループ の概念が導入されました。グループには複数のコマンドが含まれ、コマンドグループは sudo 設定で参照できます。
/etc/sudo-ldap.conf
で設定できるデフォルトの sudo ユーザー uid=sudo,cn=sysaccounts,cn=etc,$SUFFIX
を定義します。
21.1.2. sudo および Netgroups
sudo
ポリシーを使用するようにホストを設定」を参照してください。
21.1.3. サポートされる sudo クライアント
21.2. sudo コマンドおよびコマンドグループの設定
21.2.1. sudo コマンドの追加
21.2.1.1. Web UI を使用した sudo コマンドの追加
- Policy タブをクリックします。
- Sudo サブタブをクリックし、Sudo Commands のリンクを選択します。
- コマンドリストの上部にある Add リンクをクリックします。
- コマンドの完全なシステムパスと名前を入力し、必要に応じて説明を入力します。
- Add and Edit ボタンをクリックして、コマンドの設定ページに即座に移動します。
- Sudo Command Groups タブで、Add ボタンをクリックして sudo コマンドをコマンドグループに追加します。
- 参加するコマンドの groups のチェックボックスをクリックし、右向き矢印ボタンをクリックしてグループを選択ボックスに移動します。
21.2.1.2. コマンドラインでの sudo コマンドの追加
$ ipa sudocmd-add --desc "description" /local/path/to/command
$ ipa sudocmd-add --desc 'For reading log files' '/usr/bin/less' ---------------------------------- Added sudo command "/usr/bin/less" ---------------------------------- sudo Command: /usr/bin/less Description: For reading log files
21.2.2. sudo コマンドグループの追加
21.2.2.1. Web UI を使用した sudo コマンドグループの追加
- Policy タブをクリックします。
- Sudo サブタブをクリックし、Sudo Command Groups のリンクを選択します。
- コマンドグループ一覧の上部にある Add リンクをクリックします。
- 新しいコマンドグループの名前と説明を入力します。
- Add and Edit ボタンをクリックして、グループの設定ページに即座に移動します。
- Sudo Commands タブで Add ボタンをクリックして、グループに sudo コマンドを追加します。
- Sudo Commands タブで Add ボタンをクリックして、グループに sudo コマンドを追加します。
- 追加するコマンドの名前の横にあるチェックボックスをクリックし、右向きの矢印をクリックして選択ボックスに移動します。
21.2.2.2. コマンドラインで sudo コマンドグループの追加
- sudocmdgroup-add コマンドを使用して、コマンドグループを作成します。
$ ipa sudocmdgroup-add --desc 'File editing commands' files ----------------------------------- Added sudo command group "files" ----------------------------------- sudo Command Group: files Description: File editing commands
- sudocmd-add コマンドを使用して、コマンドエントリーを作成します。
$ ipa sudocmd-add --desc 'For editing files' '/usr/bin/vim' ---------------------------------- Added sudo command "/usr/bin/vim" ---------------------------------- sudo Command: /usr/bin/vim Description: For editing files
- sudocmdgroup-add-member コマンドを使用して、完全なディレクトリーの場所を名前として使用し、コマンドをコマンドグループに追加します。
$ ipa sudocmdgroup-add-member --sudocmds '/usr/bin/vim' files sudo Command Group: files Description: File editing commands Member sudo commands: /usr/bin/vim ------------------------- Number of members added 1 -------------------------
21.3. sudo ルールの定義
21.3.1. 外部ユーザーについて
図21.1 外部エンティティー
21.3.2. sudo オプションのフォーマットについて
/etc/sudoers
ファイルの設定と同じ形式は使用できません。特に、Identity Management では、UI または CLI で設定されるかどうかに関係なく、オプションパラメーターには空白文字は使用できません。
/etc/sudoers
ファイルでは、以下のように空白文字が付いたコンマ区切りリストのオプションをリストできます。
mail_badpass, mail_no_host, mail_no_perms, syslog = local2
[jsmith@server ~]$ ipa sudorule-add-option readfilesSudo Option: mail_badpass
----------------------------------------------------- Added option "mail_badpass" to Sudo rule "readfiles" ----------------------------------------------------- [jsmith@server ~]$ ipa sudorule-add-option readfilesSudo Option: syslog=local2
----------------------------------------------------- Added option "syslog=local2" to Sudo rule "readfiles" ----------------------------------------------------- ...
/etc/sudoers
ファイルで無視される改行は、Identity Management 設定では許可されません。
env_keep = "COLORS DISPLAY EDITOR HOSTNAME HISTSIZE INPUTRC KDEDIR LESSSECURE LS_COLORS MAIL PATH PS1 PS2 QTDIR USERNAME LANG LC_ADDRESS LC_CTYPE LC_COLLATE LC_IDENTIFICATION LC_MEASUREMENT LC_MESSAGES LC_MONETARY LC_NAME LC_NUMERIC LC_PAPER LC_TELEPHONE LC_TIME LC_ALL LANGUAGE LINGUAS _XKB_CHARSET XAUTHORITY"
[jsmith@server ~]$ ipa sudorule-add-option readfiles
Sudo Option: env_keep="COLORS DISPLAY EDITOR HOSTNAME HISTSIZE INPUTRC KDEDIR LESSSECURE LS_COLORS MAIL PATH PS1 PS2 ... XAUTHORITY"
sudoers
オプションを指定するには、各オプションを 1 行すべてではなく、個別のオプション設定として設定します。
21.3.3. Web UI での sudo ルールの定義
- Policy タブをクリックします。
- Sudo サブタブをクリックし、Sudo Rules のリンクをクリックします。
- sudo ルールの一覧の上部にある Add リンクをクリックします。
- ルールの名前を入力します。
- Add and Edit ボタンをクリックして、すぐにルールの設定を設定します。ルールには設定エリアが多数あります。最も基本的な要素は、Who、Access This Host、Run Commands で設定されています。もう 1 つ はオプションで、ルールを改良するために使用されます。
- 任意。Options エリアで、sudoers オプションを追加します。オプションの完全なリストは sudoers man ページにあります。注記「sudo オプションのフォーマットについて」で説明されているように、値に空白があるオプションを使用しないでください。1 行にオプションの一覧を追加するのではなく、目的のオプションごとに 1 つのオプション設定を追加します。
- オプション一覧の右側にある + Add リンクをクリックします。
- sudoers オプションを入力します。
- Who エリアで、sudo ルールが適用されるユーザーまたはユーザーグループを選択します。
- ユーザー一覧の右側にある + Add リンクをクリックします。
- ルールに追加するユーザーのチェックボックスをクリックし、右向きの矢印 () をクリックして選択ボックスにユーザーを移動します。
IdM ユーザーと外部システムユーザー (「外部ユーザーについて」) の両方を設定できます。 - Access This Host エリアで、sudo ルールが有効なホストを選択します。
- ホスト一覧の右側にある + Add リンクをクリックします。
- ルールとともに追加するホストのチェックボックスをクリックし、右矢印ボタン () をクリックして、ホストを選択項目のボックスに移動します。
- Run Commands エリアで、sudo ルールに含まれるコマンドを選択します。sudo ルールは、アクセスを許可またはコマンドへのアクセスを拒否します。また、あるコマンドへのアクセスを許可し、別のコマンドへのアクセスを拒否することができます。
- Allow/Deny エリアで、コマンド一覧の右側にある + Add リンクをクリックします。
- ルールとともに追加する、複数のコマンドまたは単一のコマンドまたはグループのチェックボックスをクリックし、右矢印ボタン () をクリックして、コマンドを選択項目のボックスに移動します。
- 任意。sudo ルールを設定して、指定したコマンドを特定の root 以外のユーザーとして実行できます。
- As Whom エリアで、ユーザー一覧の右側にある + Add リンクをクリックします。
- ユーザーのチェックボックスをクリックしてコマンドを実行し、右向きの矢印 () をクリックして選択ボックスにユーザーを移動します。
21.3.4. コマンドラインでの sudo ルールの定義
$ ipa sudorule-add* options ruleName
例21.1 基本的な sudo ルールの作成
[jsmith@server ~]$ kinit admin [jsmith@server ~]$ ipa sudorule-add files-commands ----------------------------------- Added sudo rule "files-commands" ----------------------------------- Rule name: files-commands Enabled: TRUE
--sudocmds
の単一のコマンド、または --sudocmdgroups
を使用したコマンドグループで行うことができます。
[jsmith@server ~]$ ipa sudorule-add-allow-command --sudocmds "/usr/bin/vim" files-commands Rule name: files-commands Enabled: TRUE sudo Commands: /usr/bin/vim ------------------------- Number of members added 1 -------------------------
[jsmith@server ~]$ ipa sudorule-add-host --host server.example.com files-commands Rule name: files-commands Enabled: TRUE Hosts: server.example.com sudo Commands: /usr/bin/vim ------------------------- Number of members added 1 -------------------------
[jsmith@server ~]$ ipa sudorule-add-user --user jsmith files-commands Rule name: files-commands Enabled: TRUE Users: jsmith Hosts: server.example.com sudo Commands: /usr/bin/vim" ------------------------- Number of members added 1 -------------------------
例21.2 コマンドの許可と拒否
[jsmith@server ~]$ kinit admin [jsmith@server ~]$ ipa sudorule-add-allow-command --sudocmds "/usr/bin/less" readfiles [jsmith@server ~]$ ipa sudorule-add-allow-command --sudocmds "/usr/bin/tail" readfiles [jsmith@server ~]$ ipa sudorule-add-deny-command --sudocmds "/usr/bin/vim" readfiles
例21.3 sudoers オプションの使用
[jsmith@server ~]$ kinit admin [jsmith@server ~]$ ipa sudorule-add-option readfiles Sudo Option: !authenticate ----------------------------------------------------- Added option "!authenticate" to Sudo rule "readfiles" -----------------------------------------------------
例21.4 他のユーザーとしての実行
--sudorule-add-runasuser
または --sudorule-add-runasgroup
コマンドを使用してそれぞれユーザーまたはグループが指定されています。
$ ipa sudorule-add-runasuser --users=jsmith readfiles $ ipa sudorule-add-runasgroup --groups=ITadmins readfiles
--runasusercat
または --runasgroupcat
を使用して、すべてのユーザーまたはすべてのグループとして sudo を実行できます。たとえば、以下のようになります。
$ ipa sudorule-mod --runasgroupcat=all ruleName
--sudorule-add-runasuser
および --sudorule-add-runasgroup
コマンドは、特定のユーザー名またはグループ名のみに対応しており、all オプションには対応していません。すべてのユーザーまたはすべてのグループの指定は、sudorule-mod コマンドでオプションとともにのみ使用できます。
例21.5 外部ユーザーの参照
- --externaluser
- --runasexternaluser
$ ipa sudorule-add-user --externaluser=ITAdmin readfiles $ ipa sudorule-add-runasuser --runasexternaluser=root readfiles
コマンド | 説明 |
---|---|
sudorule-add | sudo ルールエントリーを追加します。 |
sudorule-add-user | ユーザーまたはユーザーグループを sudo ルールに追加します。このユーザー (またはグループのすべてのメンバー) は、ルール内のコマンドのいずれかを sudo することができます。 |
sudorule-add-host | ルールのターゲットホストを追加します。これらは、ユーザーに sudo パーミッションが付与されるホストです。 |
sudorule-add-runasgroup | sudo コマンドを実行するには、グループを設定します。これは特定のユーザーである必要があります。すべてのユーザーを指定するには、sudo-rule を使用してルールを変更します。 |
sudorule-add-runasuser | sudo コマンドを実行するには、ユーザーを設定します。これは特定のユーザーである必要があります。すべてのユーザーを指定するには、sudo-rule を使用してルールを変更します。 |
sudorule-add-allow-command | ルールのユーザーが実行に sudo パーミッションを持つコマンドを追加します。 |
sudorule-add-deny-command | ルールのユーザーが、実行する sudo パーミッションを 拒否されたコマンドを追加します。 |
sudorule-add-option | sudo ルールに sudoers フラグを追加します。 |
sudorule-disable | sudo ルールエントリーを一時的に非アクティブにします。 |
sudorule-enable | 以前に一時停止した sudo ルールをアクティベートします。 |
sudorule-del | sudo ルールを完全に削除します。 |
例21.6 コマンドラインからの新規 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
コマンド使用時にユーザー認証が要求されないようにするには、!authenticate
sudoers
を追加します。$ 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
21.3.5. sudo
ルールの一時停止および削除
sudo
ルールは、Web UI またはコマンドラインから一時的に非アクティブ化または完全に削除できます。中断されたルールは、サーバーを再起動しなくても ou=sudoers
compat ツリーから削除されます。
Web UI からの sudo
ルールの一時停止および削除
sudo
ルールの一覧の上部にある または ボタンを使用します。
図21.2 Web UI からの sudo
ルールの一時停止または削除
コマンドラインからの sudo
ルールの一時停止および削除
ipa sudorule-disable files-commands
ipa sudorule-del files-commands
21.4. IdM sudo
ポリシーを使用するようにホストを設定
sudo
ポリシーを実装するのは、IdM でルールを作成するよりも複雑です。これらのルールはすべてのローカルマシンに適用する必要があります。つまり、IdM ドメインの各システムがポリシーに対して IdM を参照するように設定する必要があります。
sudo
ポリシーを適用できます。Red Hat では、SSSD ベースの設定を使用することを強く推奨しています。
21.4.1. SSSD を使用した sudo
ポリシーのホストへの適用
- IdM でホストおよび
sudo
エントリーを設定します。- 「sudo コマンドおよびコマンドグループの設定」の説明に従って、
sudo
コマンドおよびコマンドグループを設定します。 - 「sudo ルールの定義」の説明に従って、
sudo
ルールを設定します。 - 任意。「ホストグループの管理」の説明に従って、ホストグループを設定します。
- 任意。「ユーザーグループの作成」で説明されているようにユーザーグループを作成し、ユーザーを追加します。
sudo
ルールに SSSD を使用するように、IdM ドメインのすべてのシステムを設定します。注記このステップは、Red Hat Enterprise Linux 6.5 以前に基づいたシステムでのみ実行してください。Red Hat Enterprise Linux 6.6 以降では、ipa-client-install
ユーティリティーが SSSD を自動的にsudo
のデータプロバイダーとして設定します。sudoers
ファイルで SSSD をルックアップするようsudo
を設定します。vim /etc/nsswitch.conf sudoers: files sss
このfiles
オプションをそのままにすると、sudo
で、IdM 設定について SSSD を確認する前にローカル設定を確認することができます。sudo
を、ローカルの SSSD クライアントが管理するサービス一覧に追加します。[root@server ~]# vim /etc/sssd/sssd.conf [sssd] config_file_version = 2 services = nss, pam,
sudo
domains = IPADOMAINsudo
設定で NIS ドメインの名前を設定します。sudo
は NIS スタイルの netgroup を使用するので、sudo
が IdMsudo
設定で使用されているホストグループを発見できるようにするには、NIS ドメイン名はシステム設定で設定する必要があります。sudo
ルールで使用する NIS ドメイン名を設定します。[root@server ~]# nisdomainname example.com
- NIS ドメイン名が維持されるようにシステム認証設定を設定します。たとえば、以下のようになります。
[root@server ~]# echo "NISDOMAIN=example.com.com" >> /etc/sysconfig/network
これにより、NIS ドメインを持つ/etc/sysconfig/network
および/etc/yp.conf
ファイルが更新されます。
注記sudo
は NIS 形式のネットグループを使用しますが、NIS サーバーをインストールする必要はありません。netgroups では、NIS ドメインを設定で命名する必要があるため、sudo
では、netgroups に NIS ドメインという名前を付ける必要があります。ただし、NIS ドメインが存在する必要はありません。
- オプションで、SSSD 内のデバッグを有効にして、使用している LDAP 設定を表示することができます。
[domain/IPADOMAIN] debug_level = 6 ....
SSSD が操作に使用する LDAP 検索ベースは、sssd_
DOMAINNAME.log
ファイルに記録されます。
21.4.2. LDAP を使用した sudo
ポリシーのホストへの適用
sudo
ポリシーのホストへの適用」 を参照してください。
- IdM でホストおよび sudo エントリーを設定します。
- 任意。「ホストグループの管理」の説明に従って、ホストグループを設定します。
- 任意。「ユーザーグループの作成」で説明されているようにユーザーグループを作成し、ユーザーを追加します。
- 「sudo コマンドおよびコマンドグループの設定」の説明に従って、
sudo
コマンドおよびコマンドグループを設定します。 - 「sudo ルールの定義」の説明に従って、
sudo
ルールを設定します。
- デフォルトの IdM
sudo
ユーザーのパスワードを設定して、バインド (認証) ユーザーを設定します。ユーザーがサーバーへの認証が可能でなければなりません。sudo
ポリシーでは、匿名アクセスはサポートされません。LDAP ツールを使用して、
を設定します。以下に例を示します。sudo
ユーザーのパスワード uid=sudo,cn=sysaccounts,cn=etc,dc=example,dc=com[jsmith@server ~]$ ldappasswd -Y GSSAPI -S -h ipaserver.example.com uid=sudo,cn=sysaccounts,cn=etc,dc=example,dc=com New password: Re-enter new password: Enter LDAP Password:
- sudo ルールに SSSD を使用するように、IdM ドメインのすべてのシステムを設定します。
sudo
を設定して、sudoers
ファイルの LDAP を検索します。vim /etc/nsswitch.conf sudoers: files ldap
このfiles
オプションをそのままにすると、sudo
は LDAP ベースの IdM 設定を確認する前にローカル設定を確認することができます。/etc/ldap.conf
ファイル内の sudo 操作のデバッグロギングを有効にします。このファイルが存在しない場合は作成できます。vim /etc/ldap.conf sudoers_debug: 1
注記sudoers_debug
パラメーターを追加すると、トラブルシューティングに役立ちます。このパラメーターの有効な値は 0、1、および 2 です。sudo
ドキュメント (http://www.gratisoft.us/sudo/readme_ldap.html) には、プロセスのデバッグに関する詳細情報が記載されています。- NSS/LDAP 設定ファイルを編集し、以下の
sudo
関連の行を/etc/sudo-ldap.conf
ファイルに追加します。binddn uid=sudo,cn=sysaccounts,cn=etc,dc=example,dc=com bindpw sudo_password ssl start_tls tls_cacertfile /etc/ipa/ca.crt tls_checkpeer yes bind_timelimit 5 timelimit 15 uri ldap://ipaserver.example.com ldap://backup.example.com:3890 sudoers_base ou=SUDOers,dc=example,dc=com
複数の LDAP サーバーをスペースで区切って設定できます。その他のオプション (SSL や非標準ポートなど) は LDAP URL と併用できます。sudo
LDAP 設定は sudooers.ldap(8) man ページで説明されています。重要uri
ディレクティブは、IP アドレスではなく、LDAP サーバーの完全修飾ドメイン名を提供する必要があります。それ以外の場合は、sudo
は LDAP サーバーへの接続に失敗します。 - 任意。SSSD でのデバッグを有効にして、使用している LDAP 設定を表示します。
[root@server ~]# vim /etc/sssd/sssd.conf [domain/LDAPDOMAIN] debug_level = 6 ....
SSSD が操作に使用する LDAP 検索ベースは、sssd_
DOMAINNAME.log
ファイルに記録されます。 sudo
設定で NIS ドメインの名前を設定します。sudo
は NIS スタイルの netgroup を使用するので、sudo
が IdMsudo
設定で使用されているホストグループを発見できるようにするには、NIS ドメイン名はシステム設定で設定する必要があります。sudo
ルールで使用する NIS ドメイン名を設定します。[root@server ~]# nisdomainname example.com
- NIS ドメイン名が維持されるようにシステム認証設定を設定します。たとえば、以下のようになります。
[root@server ~]# echo "NISDOMAIN=example.com" >> /etc/sysconfig/network
これにより、NIS ドメインを持つ/etc/sysconfig/network
および/etc/yp.conf
ファイルが更新されます。
注記sudo
は NIS 形式のネットグループを使用しますが、NIS サーバーをインストールする必要はありません。netgroups では、NIS ドメインを設定で命名する必要があるため、sudo
では、netgroups に NIS ドメインという名前を付ける必要があります。ただし、NIS ドメインが存在する必要はありません。
第22章 ポリシー: ホストベースのアクセス制御の設定
22.1. ホストベースのアクセス制御
図22.1 ホストグループとホストベースのアクセス制御
--no_hbac_allow
オプションを指定して ipa-server-install を実行します。
- IdM ドメイン内のホストまたは ターゲットホスト。
- ターゲットホストのサービス複数のサービスを サービスグループ に統合できます。サービスグループは、アクセス制御ルール自体を編集しなくても変更できます。
22.2. サービスおよびサービスグループのホストベースのアクセス制御エントリーの作成
22.2.1. HBAC サービスの追加
22.2.1.1. Web UI での HBAC サービスの追加
- Policy タブをクリックします。
- Host-Based Access Control サブタブをクリックし、HBAC Services のリンクを選択します。
- サービス一覧の上部にある Add リンクをクリックします。
- サービス名と説明を入力します。
- Add ボタンをクリックして新規サービスを保存します。
- サービスグループが存在する場合は、「Web UI でのサービスグループの追加」の説明に従って、サービスを必要なグループに追加します。
22.2.1.2. コマンドラインでサービスの追加
tftp
サービスが追加されます。
# ipa hbacsvc-add --desc="TFTP service" tftp ------------------------- Added HBAC service "tftp" ------------------------- Service name: tftp Description: TFTP service
22.2.2. サービスグループの追加
22.2.2.1. Web UI でのサービスグループの追加
- Policy タブをクリックします。
- Host-Based Access Control サブタブをクリックし、HBAC Services グループリンクを選択します。
- サービスグループ一覧の上部にある Add リンクをクリックします。
- サービスグループ名と説明を入力します。
- Add and Edit ボタンをクリックして、サービスグループの設定ページに即座に移動します。
- HBAC サービス タブの上部にある Add リンクをクリックします。
- 追加するサービスの名前の横にあるチェックボックスをクリックし、右向きの矢印をクリックして選択ボックスに移動します。
22.2.2.2. コマンドラインでサービスグループの追加
[jsmith@server ~]$ kinit admin [jsmith@server ~]$ ipa hbacsvcgroup-add --desc="login services" login -------------------------------- Added HBAC service group "login" -------------------------------- Service group name: login Description: login services [jsmith@server ~]$ ipa hbacsvc-add --desc="SSHD service" sshd ------------------------- Added HBAC service "sshd" ------------------------- Service name: sshd Description: SSHD service [jsmith@server ~]$ ipa hbacsvcgroup-add-member --hbacsvcs=sshd login Service group name: login Description: login services ------------------------- Number of members added 1 -------------------------
SUDO
と、FTP
アクセスを提供するサービスの FTP です。
22.3. ホストベースのアクセス制御ルールの定義
22.3.1. Web UI でのホストベースのアクセス制御ルールの設定
- Policy タブをクリックします。
- Host-Based Access Control サブタブをクリックし、HBAC Rules のリンクを選択します。
- ホストベースのアクセス制御ルール一覧の上部にある Add リンクをクリックします。
- ルールの名前を入力します。
- Add and Edit ボタンをクリックして、すぐにルールの設定を設定します。ルールには設定エリアが多数あります。3 つの基本的な要素は、誰がルールを適用するか、どのホストがアクセスを許可するか (ターゲット)、そして任意で、どのサービスがアクセスできるかです。
- Who エリアで、アクセス制御ルールが適用されるユーザーまたはユーザーグループを選択します。すべての IdM ユーザーにルールを適用する場合は、Anyone ラジオボタンを選択します。ルールを特定のユーザーまたはユーザーグループのセットに適用するには、以下を実行します。
- 指定したユーザーとグループラジオボタンを 選択します。
- ユーザー一覧の右側にある + Add リンクをクリックします。
- ルールに追加するユーザーのチェックボックスをクリックし、右向きの矢印 () をクリックして選択ボックスにユーザーを移動します。
- Accessing エリアで、このアクセス制御ルールでアクセスできるターゲットホストを選択します。すべての IdM ホストにルールを適用する場合は、Any Host ラジオボタンを選択します。特定のホストまたはホストのグループセットにルールを適用するには、次のコマンドを実行します。
- 指定したホストとグループラジオボタンを 選択します。
- ホスト一覧の右側にある + Add リンクをクリックします。
- ルールとともに追加するホストのチェックボックスをクリックし、右矢印ボタン () をクリックして、ホストを選択項目のボックスに移動します。
- Via Service エリアで、ユーザーがターゲットマシンにアクセスできるターゲットホストで特定のサービスを選択します。すべての IdM ホストにルールを適用する場合は、Any Service ラジオボタンを選択します。特定のホストまたはホストのグループセットにルールを適用するには、次のコマンドを実行します。
- 指定したサービスとグループ ラジオボタンを選択します。
- コマンド一覧の右側にある + Add リンクをクリックします。
- ルールとともに追加するサービスまたはグループのチェックボックスをクリックし、右矢印ボタン () をクリックして、サービスを選択項目のボックスに移動します。
22.3.2. コマンドラインでのホストベースのアクセス制御ルールの設定
$ ipa hbacrule-add* options ruleName
--usercat=all
などのカテゴリーオプションを使用します。
例22.1 1 つのホストへのすべてのアクセス権限の付与
$ ipa hbacrule-add --usercat=all allGroup -------------------------- Added HBAC rule "allGroup" -------------------------- Rule name: allGroup User category: all Enabled: TRUE
$ ipa hbacrule-add-host --hosts=server.example.com allGroup Rule name: allGroup User category: all Enabled: TRUE Successful hosts/hostgroups: member host: server.example.com ------------------------- Number of members added 1 -------------------------
例22.2 サービスへの単一ユーザーのコントロールの追加
$ ipa hbacrule-add --hostcat=all sshd-jsmith
$ ipa hbacrule-add-user --users=jsmith sshd-jsmith
$ ipa hbacrule-add-service --hbacsvcs=sshd sshd-jsmith
例22.3 サービスグループのルールへの追加
--hbacsvcgroups
オプションとともにのみ使用されます。
$ ipa hbacrule-add-service --hbacsvcgroups=login loginRule
コマンド | 説明 | 引数 | ソースまたはターゲットエントリー |
---|---|---|---|
hbacrule-add | ホストベースのアクセス制御ルールを新たに追加します。 |
| |
hbacrule-add-host | ターゲットホストをアクセス制御ルールに追加します。ターゲットホストは、ドメイン内 の 他のサーバーおよびユーザーからアクセスできます。 |
| ターゲット |
hbacrule-add-service | ルールにサービスタイプを追加します。 |
| ターゲット |
hbacrule-add-user | アクセス制御ルールにユーザーを追加します。その後、ユーザーはドメイン内の許可されたターゲットホストまたはサービスにアクセスできます。 |
| ソース |
hbacrule-disable | hbacrule-enable | ホストベースのアクセス制御ルールを無効にするか、または有効にします。ルールは、動作を評価する必要がある場合にルールを無効にすることができます (トラブルシューティングまたは新しいルールをテストする場合)。 | RuleName: 無効にまたは有効にするルールです。 |
22.4. ホストベースのアクセス制御ルールのテスト
22.4.1. ホストベースのアクセス制御設定の制限
- 新しいルールは、実装前にテストする必要があります。
- 既存のルールには問題があり、テストツールはどのルールを適切に動作させるかを特定できます。
- 既存のルールのサブセットをテストして、それらの実行内容を確認することができます。
22.4.2. ホストベースのアクセス制御 (CLI ベース) のテストシナリオ
- ユーザーは、そのユーザー (
--user
) のルールパフォーマンスをテストするために操作を実行します。 - ログインクライアント Y (
--service
) の使用 - ホスト Z (
--host
) をターゲットにするには、次のコマンドを実行します。 - テストするルール (
--rules
): これが使用されていない場合は、有効なすべてのルールがテストされます。 - オプション: hbactest は一致するルール、一致しないルール、または無効なルールに関する詳細情報を返します。この詳細なルール出力は
--nodetail
を使用して無効にすることができます。そのため、テストが単に実行され、アクセスが付与されたかどうかを返します。
例22.4 すべてのアクティブなルールのテスト
[jsmith@server ~]$ kinit admin [jsmith@server ~]$ ipa hbactest --user=jsmith --host=target.example.com --service=ssh -------------------- Access granted: True -------------------- Matched rules: allow_all Matched rules: sshd-jsmith Matched rules: web-rules Not matched rules: allGroup
例22.5 特定のルールのテスト
[jsmith@server ~]$ kinit admin [jsmith@server ~]$ ipa hbactest --user=jsmith --host=target.example.com --service=ssh --rules=myrule --------------------- Access granted: True --------------------- notmatched: myrule
例22.6 テスト固有のルールとすべてが有効化
--rules
オプションは、テストする特定のルールを一覧表示します。ただし、ドメインで有効なすべてのルールに対して、指定したルールをテストすると便利です。これは、--enabled
オプションを追加することで実行できます。これには、指定されていない有効なルールと、指定したルールを含みます。
[jsmith@server ~]$ kinit admin [jsmith@server ~]$ ipa hbactest --user=jsmith --host=target.example.com --service=ssh --rules=myrule --enabled -------------------- Access granted: True -------------------- matched: my-second-rule notmatched: my-third-rule matched: myrule matched: allow_all
--disabled
オプションを使用すると、無効 なルールと同様の比較を実行できます。この --rules
オプションを使用すると、指定したルールと、無効なすべてのルールがチェックされます。この --disabled
オプションを使用すると、無効にしたすべてのルールがチェックされます。
22.4.3. UI でのホストベースのアクセス制御ルールのテスト
- ユーザーは、そのユーザー (Who) のルールパフォーマンスをテストするために操作を実行します。
- ホスト Z (アクセス) をターゲットにするには、次のコマンドを実行します。
- ログインクライアント Y (Via Service) の使用
- テストするルール。これが使用されていない場合、有効なすべてのルールはテストされます (Rules) になります。
図22.2 HBAC テストを設定する From タブ
図22.3 HBAC テスト結果
第23章 ポリシー: グループポリシーオブジェクトアクセス制御
23.1. GPO ベースのアクセス制御の設定
/etc/sssd/sssd.conf
ファイルで設定できます。ad_gpo_access_control
オプションは、GPO ベースのアクセス制御を実行するモードを指定します。以下の値を使用できます。
ad_gpo_access_control = permissive
permissive
の場合は、GPO ベースのアクセス制御は評価されますが、強制されません。syslog
メッセージは、アクセスが拒否される度に復元されます。これはデフォルトの設定です。ad_gpo_access_control = enforcing
enforcing
の場合は、GPO ベースのアクセス制御は評価され、強制されます。ad_gpo_access_control = disabled
disabled
の場合は、GPO ベースのアクセス制御は評価も強制もされません。
ad_gpo_access_control
を設定する前に、ad_gpo_access_control
を Permissive モードに設定して、ログを調べることが推奨されます。syslog
メッセージを見直すことで現行の GPO 設定をテスト、調節してからその後で enforcing モードに設定することができます。
sssd.conf
ファイルで指定することができます。
ad_gpo_map_*
オプションとad_gpo_default_right
オプションは、特定の Windows ログイン権限にマッピングされる PAM サービスを設定します。ad_gpo_cache_timeout
オプションでは、後続のアクセス制御リクエストが DC から新たに取得するのではなく、キャッシュに保存されているファイルを再利用可能な間隔を指定します。
第24章 ポリシー: SELinux ユーザーマップの定義
24.1. Identity Management、SELinux、およびユーザーのマッピング
図24.1 SELinux Manager の 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
24.2. SELinux ユーザーマップの順序とデフォルト値の設定
SELinux_username:MLS[:MCS]
24.2.1. Web UI での設定
- トップメニューで IPA Server メインタブをクリックし、Configuration サブタブをクリックします。
- SELINUX OPTIONS まで、サーバー設定エリア一覧でスクロールダウンします。
- SELinux のユーザー設定を設定します。編集できるエリアは、SELinux ユーザーの優先順位付きリストと、マッピングされていない IdM ユーザーに使用するデフォルトの SELinux ユーザーの一覧です。SELinux ユーザーマップの順序 は、ローカルの Linux システムで定義されている SELinux ユーザーの一覧を提供します。これは、マッピングルールの設定に利用できます。これは、優先が低い順です。各 SELinux ユーザーの形式は、SELinux_user:MLS です。Default SELinux user フィールドは、マッピングされていない IdM ユーザーに使用する SELinux ユーザーを設定します。
- 変更を保存するには、ページの上部にある Update リンクをクリックします。
24.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
例24.1 SELinux ユーザーの一覧
--ipaselinuxusermaporder
オプションで渡されます。この一覧は、最も制限のあるユーザーから優先順位を設定します。
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"
例24.2 デフォルトの SELinux ユーザー
unconfined_u
になります。
--ipaselinuxusermapdefault
で変更できます。たとえば、以下のようになります。
[jsmith@server ~]$ ipa config-mod --ipaselinuxusermapdefault="guest_u:s0"
24.3. SELinux ユーザーおよび IdM ユーザーのマッピング
24.3.1. Web UI での設定
- トップメニューで Policy メインタブをクリックし、SELinux User Mappings サブタブをクリックします。
- マッピングのリストでをクリックして新規マップを作成します。
- マップの名前と、IdM サーバー設定に表示されているように SELinux ユーザーを入力します。SELinux ユーザーの形式は、SELinux_username:MLS[:MCS] です。
- ホストベースのアクセス制御ルールを設定するには、設定の General エリアでドロップダウンメニューからルールを選択します。ホストベースのアクセス制御ルールを使用すると、リモートユーザーがターゲットマシンにアクセスする際に使用するホストでアクセス制御が導入されます。割り当て可能なホストベースのアクセス制御ルールは、1 つのみです。注記ホストベースのアクセス制御ルールには、サービスだけでなく、ユーザーとホストも含める必要があります。別の方法では、Users と Hosts のエリアでスクロールダウンし、Add をクリックしてユーザー、ユーザーグループ、ホスト、もしくはホストグループを SELinux マップに割り当てます。左側のユーザー (またはホストもしくはグループ) を選択し、右矢印 Prospective コラムに移動します。 をクリックして、それらをルールに追加します。をクリックして注記ホストベースのアクセス制御ルールを指定するか、ユーザーとホストを手動で設定できます。両方のオプションを同時に使用することはできません。
- 上部の Update リンクをクリックして、SELinux ユーザーマップへの変更を保存します。
24.3.2. コマンドラインでの設定
- SELinux ユーザー (
--selinuxuser
) - SELinux ユーザーに関連付けられたユーザーもしくはユーザーグループ (
--users
または--groups
) - SELinux ユーザーと関連づけられたホストまたはホストグループ (
--hosts
または--hostgroups
) - 代替方法として、ホストおよびユーザーを指定しているホストベースのアクセス制御ルール (
--hbacrule
):
例24.3 新規 SELinux マップの作成
--selinuxuser
値は、IdM サーバー設定に表示されているとおりに SELinux ユーザー名である必要があります。SELinux ユーザーの形式は、SELinux_username:MLS[:MCS] です。
[jsmith@server ~]$ ipa selinuxusermap-add --users=jsmith,bjensen,jrockford --hosts=server.example.com,test.example.com --selinuxuser="xguest_u:s0" selinux1
例24.4 ホストベースのアクセス制御ルールでの SELinux マップ作成
--hbacrule
値は、マッピングに使用するホストベースのアクセス制御ルールを識別します。また、リモートユーザーがターゲットマシンにログインすると、SELinux コンテキストが適用されます。
[jsmith@server ~]$ ipa selinuxusermap-add --hbacrule=webserver --selinuxuser="xguest_u:s0" selinux1
例24.5 ユーザーを SELinuxマッピングに追加する
[jsmith@server ~]$ ipa selinuxusermap-add-user --users=jsmith selinux1
--hbacrule
オプションとともに使用する場合は、ホストベースのアクセス制御ルールを追加するか、以前のアクセス制御ルールを上書きします。
例24.6 ユーザーの SELinuxマッピングからの削除
[jsmith@server ~]$ ipa selinuxusermap-remove-user --users=jsmith selinux1
第25章 ポリシー: ユーザーおよびホストの自動グループメンバーシップの定義
25.1. Automembership について
- すべてのホストまたはすべてのユーザーを単一のグローバルグループに追加します。
- 従業員タイプ、ID 番号、マネージャー、または物理的な場所に基づいて社員を特定のグループに追加します。
- ホストの IP アドレスまたはサブネットに基づいたホストの分割。
- Identity Management で使用されるグループ
- 指定した機能を実行するために、さまざまなタイプのユーザーおよびホストが属する必要のある特定のグループ
- 適切なグループにユーザーおよびホストをフィルターするために使用できる属性の記述
25.2. Automembership Rules (基本手順) の定義
25.2.1. Web UI での操作
- ユーザーグループ (「ユーザーグループの作成」) またはホストグループ (「Web UI でホストグループの作成」) を作成します。
- Policy タブを開き、Automembers サブタブを選択します。
- Automembers エリアの上部で、USER GROUP RULES または HOST GROUP RULES のいずれかを作成する自動グループのタイプを選択します。
- ドロップダウンメニューで、automember ルールを作成するグループを選択します。
- ルールの編集ページで、条件のタイプで + Add をクリックしてエントリーを特定します。
- 検索のベースとして使用する属性を選択し、属性値と一致するために使用する正規表現を設定します。条件は、グループに 含める グループから明示的に 除外 するエントリーを検索します。条件の形式は、Perl と互換性のある正規表現 (PCRE) です。PCRE パターンの詳細は、pcresyntax(3) の man ページを参照してください。注記除外条件は最初に評価され、包含条件よりも優先されます。
- 追加 ボタンをクリックして最後の条件を保存し、ダイアログウィンドウを閉じます。をクリックして別の条件を追加します。1 つのルールに複数の包含および除外条件を指定することができます。すべての条件が設定されている場合は、
25.2.2. CLI からの操作
- グループを automember グループとして対象とするコマンド automember-add
- グループメンバーを識別するための正規表現条件を追加するコマンド automember-add-condition
- ユーザーグループ (「コマンドラインの使用」) またはホストグループ (「コマンドラインでのホストグループの作成」) を作成します。
- グループの automember ルールエントリーを作成します。
--type
を指定して、ターゲットグループがユーザーグループ (group) またはホストグループ (hostgroup) であるかを特定します。このコマンドの形式は以下のとおりです。ipa automember-add --type=group|hostgroup groupName
以下に例を示します。[jsmith@server ~]$ ipa automember-add --type=group exampleGroup
- ルールの条件を作成します。複数のパターンを設定するには、
--inclusive-regex|--exclusive-regex
オプションのパターンのコンマ区切りリストを指定するか、コマンドを複数回実行します。このコマンドの形式は以下のとおりです。ipa automember-add-condition --type=group|hostgroup --key=attribute --inclusive-regex=regex | --exclusive-regex=regex groupName
automember ルールと同様に、条件はグループのタイプ (--type
) とターゲットグループ (groupName) を指定する必要があります。条件は、属性 (キー) と属性値のパターンも指定する必要があります。--key
は、条件の重点となる属性名です。次に、一致する値を識別する正規表現パターンがあります。一致するエントリーは含まれるか (--inclusive-regex
) またはグループから除外 (--exclusive-regex
) されるかのいずれかになります。除外ルールが優先されます。たとえば、Barbara Jensen がマネージャーの社員すべてを含めて、一時社員を除外するには、以下に従います。[jsmith@server ~]$ ipa automember-add-condition --type=group --key=manager --inclusive-regex=^uid=bjensen$ exampleGroup [jsmith@server ~]$ ipa automember-add-condition --type=group --key=employeetype --exclusive-regex=^temp exampleGroup
ヒント正規表現は文字列の任意の部分に一致できます。キャレット (^) を使用すると、開始時に一致する必要があることを意味します。ドル記号 ($) を使用すると、最後に一致する必要があることを意味します。^ および $ でパターンをラップした場合は、文字列全体が一致する必要があります。Perl と互換性のある正規表現 (PCRE) パターンの詳細は、pcresyntax(3) の man ページを参照してください。
[jsmith@server ~]$ ipa automember-remove-condition --key=fqdn --type=hostgroup --inclusive-regex=^web[1-9]+\.example\.com webservers
25.3. Automember グループの使用例
デフォルトグループの作成に関する注意事項
一般的な環境要件の 1 つに、ユーザーまたはホストを追加するデフォルトグループがあります。これには、いくつかの方法があります。
- すべてのエントリーを 1 つのグローバルグループに追加できます。追加先の他のグループに関係なく、すべてのエントリーを単一のグローバルグループに追加できます。
- エントリーは、特定の automember グループに追加できます。新しいエントリーが autogroup に一致しない場合は、デフォルトまたはフォールバックグループに追加されます。
25.3.1. 全ユーザー/ホストルールの設定
cn
または fqdn
など) に含まれる正規表現を使用します。
[jsmith@server ~]$ ipa automember-add-condition --type=hostgroup allhosts --inclusive-regex=.* --key=fqdn -------------------------------- Added condition(s) to "allhosts" -------------------------------- Automember Rule: allhosts Inclusive Regex: fqdn=.* ---------------------------- Number of conditions added 1 ----------------------------
[jsmith@server ~]$ ipa host-add test.example.com ----------------------------- Added host "test.example.com" ----------------------------- Host name: test.example.com Principal name: host/test.example.com@EXAMPLE.COM Password: False Keytab: False Managed by: test.example.com [jsmith@server ~]$ ipa hostgroup-show allhosts Host-group: allhosts Description: Default hostgroup Member hosts: test.example.com
25.3.2. デフォルトの自動メンバーグループの定義
--default-group
) およびグループタイプ (--type
) が設定されますが、一致する条件はありません。定義上、デフォルトのグループメンバーは一致しないエントリーです。
[jsmith@server ~]$ ipa automember-default-group-set --default-group=ipaclients --type=hostgroup [jsmith@server ~]$ ipa automember-default-group-set --default-group=ipausers --type=group
[jsmith@server ~]$ ipa automember-default-group-remove --type=hostgroup
25.3.3. Windows ユーザーによる自動メンバーグループの使用
[jsmith@server ~]$ ipa automember-add --type=group ipausers
[jsmith@server ~]$ ipa automember-add-condition ipausers --key=objectclass --type=group --inclusive-regex=ntUser
第26章 ポリシー: PAM サービスのドメイン制限
pam_ldap
などのレガシー PAM モジュールは、個別の設定ファイルを PAM モジュールのパラメーターとして使用できました。本章では、SSSD に類似した機能を説明します。
- pam_trusted_users (for
sssd.conf
) - このオプションは、SSSD デーモンが信頼する数値の UID またはユーザー名の一覧を受け入れます。デフォルト値は特殊なキーワード
all
ですべてのユーザーが信頼されることを意味します。これは、すべてのユーザーが任意のドメインにアクセスできる現在の動作と並行して行います。 - pam_public_domains (for
sssd.conf
) - このオプションは、信頼できないユーザーであってもアクセス可能な SSSD ドメインのコンマ区切りリストを受け入れます。
all
およびnone
の 2 つの特別なキーワードも使用できます。管理者が信頼できないドメインと信頼されていないドメイン間で区別を開始する場合、信頼できないクライアントがアクセスできるドメインを手動で指定するのに必要な値はnone
です。 - ドメイン (個々の PAM モジュール設定用)
- このオプションは、PAM サービスが認証できるように制限されるドメインの一覧を受け入れます。この設定は
/etc/sssd/sssd.conf
ファイル内のdomains=
オプションと対話します。これは、SSSD がクエリーの順序でドメインの一覧を指定します。PAM モジュール設定はこの一覧に追加できませんが、短いリストを指定して制限できます。
例26.1 PAM モジュール設定のサンプル
/etc/pam.d/
設定行の形式は以下のとおりです。
module-type control-flag module-path arguments
openldap
ドメインのみに制限され、pam_env
モジュールはすべてのユーザーに環境変数を設定/未設定にすることができます。
$ cat /etc/pam.d/sss_test auth required pam_sss.so domains=openldap account required pam_sss.so domains=openldap session required pam_sss.so domains=openldap password required pam_sss.so domains=openldap
/etc/sssd/sssd.conf
のようになります。
[sssd] domains = ipa, openldap # the list can be restricted by specific PAM module configuration [pam] pam_public_domains = ipa # all users are allowed to access the ipa domain pam_trusted_users = root, sss_test # root and sss_test are allowed to run PAM
第27章 設定: IdM ユーザーのアクセス制御の定義
27.1. IdM エントリーのアクセス制御
27.1.1. アクセス制御の概念に関する簡単な概要
- 操作が実行できるユーザー。これは、何かを実行するパーミッションを付与されるエンティティーです。これは、アクターです。これはユーザーが誰か (バインド情報に基づいて) を定義し、1 日のある時間帯や特定のマシンに試行を制限するなど、オプションでバインドの試行に対して他の制限を必須とすることが可能なため、LDAP アクセス制御モデルではバインドルールと呼ばれます。
- アクセス可能なもの。これは、Actor が許可されている操作を実行する対象のエントリーを定義します。これは、アクセス制御ルールの ターゲット です。
- 実行できる操作のタイプ。最後に、ユーザーが実行できるアクションの種類を判断します。最も一般的な操作は、追加、削除、書き込み、読み取り、および検索です。Identity Management では、すべてのユーザーが暗示的に ldM ドメイン内のすべてのエントリーに対する読み取りおよび検索権限を付与されています。制限されるのは、パスワードや Kerberos キーなどの重要な属性のみです。匿名ユーザーは、sudo ルールやホストベースのアクセス制御など、セキュリティー関連の設定は読み取ることができません。付与できる権限は、エントリーの変更に必要な追加、削除、書き込みパーミッションです。
27.1.2. Identity Management のアクセス制御メソッド
- セルフサービスルール。これは、ユーザーが自分のパーソナルエントリーで実行可能な操作を定義します。アクセス制御タイプは、エントリー内での属性への書き込みパーミッションのみを許可します。エントリー自体の追加もしくは削除操作は許可されません。
- 委任ルール。委任ルールでは、特定のユーザーグループが別のユーザーグループ内のユーザーの特定属性に関して書き込み (編集) 操作を許可されます。セルフサービスルールのように、この形式のアクセス制御は特定の属性値の編集に制限されており、エントリー全体を追加したり削除する権限や特定されていない属性に対する制御を付与するものではありません。
- ロールベースのアクセス制御では特別のアクセス制御グループが作成され、このグループに IdM ドメイン内での全タイプのエントリーに対するより幅広い権限が付与されます。ロールには編集、追加、および削除の権限が付与されるので、選択された属性だけでなくエントリー全体に対する完全な制御が付与されます。Identity Management ですでに作成され、利用可能なロールもあります。ホストや自動マウント設定、netgroup、DNS 設定、および IdM 設定など、すべてのタイプのエントリーを特別な方法で管理するために、特別なロールを作成することもできます。
27.2. セルフサービス設定の定義
- 個人エントリーの一般的な属性 (名、姓、電話番号、アドレスなど) を編集するルール。
- 2 つの Samba パスワード、Kerberos パスワード、および一般的なユーザーパスワードなど、個人パスワードを編集するルール。
- 個人 SSH キーを管理するルール。
27.2.1. Web UI でのセルフサービスルールの作成
- トップメニューで IPA Server タブを開き、Self Service Permissions サブタブを選択します。
- セルフサービス ACI の一覧の上部にある Add リンクをクリックします。
- ポップアップウィンドウでルール名を入力します。空白を使用することもできます。
- この ACI でユーザーによる編集を許可する属性のチェックボックスを選択します。
- Add をクリックして新規セルフサービス ACI を保存します。
27.2.2. コマンドライン でのセルフサービスルールの作成
--permissions
、この ACI が付与する属性の完全なリストを付与する --attrs
の 2 つのオプションがあります。
$ ipa selfservice-add "Users can manage their own name details" --permissions=write --attrs=givenname,displayname,title,initials ----------------------------------------------------------- Added selfservice "Users can manage their own name details" ----------------------------------------------------------- Self-service name: Users can manage their own name details Permissions: write Attributes: givenname, displayname, title, initials
27.2.3. セルフサービスルールの編集
図27.1 セルフサービス編集ページ
--attrs
オプションは、サポートされる属性のリストをすべて上書きするため、属性の完全なリストと新しい属性を常に含めます。
$ ipa selfservice-mod "Users can manage their own name details" --attrs=givenname,displayname,title,initials,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
27.3. ユーザーへのパーミッションの委任
27.3.1. Web UI でのユーザーグループへのアクセス委任
- トップメニューで IPA Server タブを開き、Delegations サブタブを選択します。
- 委譲 ACI 一覧の上部にある Add リンクをクリックします。
- 新規委任に名前を付けます。
- ユーザーが特定の属性を閲覧する権限を持つ (read) かその属性を追加または変更する権限を持つ (write) かをチェックボックスで選択して、パーミッションを設定します。ユーザーによっては情報を閲覧する必要はあるものの、編集可能にすべきでないユーザーもいます。
- User group ドロップダウンメニューで、ユーザーグループのユーザーエントリーに パーミッションを付与される グループを選択します。
- Member user group ドロップダウンメニューで、委譲グループのメンバーが エントリーを編集できる グループを選択します。
- 属性ボックスでは、メンバーのユーザーグループがパーミッションを付与される属性を選択します。
- Add をクリックして新規委任 ACI を保存します。
27.3.2. コマンドラインでのユーザーグループへのアクセス委任
--group
- ユーザーグループ内のユーザーのエントリーに パーミッションを付与されている グループです。--membergroup
- 委任グループのメンバーが エントリーを編集できる グループです。--attrs
。メンバーグループのユーザーが編集できる属性です。
$ ipa delegation-add "basic manager attrs" --attrs=manager,title,employeetype,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
--attrs
オプションは、サポートされる属性のリストをすべて上書きするため、属性の完全なリストと新しい属性を常に含めます。
$ ipa delegation-mod "basic manager attrs" --attrs=manager,title,employeetype,employeenumber,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
27.4. ロールベースのアクセス制御の定義
- パーミッション。パーミッションは、(読み取り、書き込み、追加、または削除) 特定の操作と、これらの操作が適用される ldM LDAP ディレクトリー内のターゲットエントリーを定義します。パーミッションはビルディングブロックで、必要に応じて複数の特権に割り当てることができます。
- ロールで利用可能な 特権。特権は基本的にパーミッションのグループです。パーミッションはロールに直接適用されません。権限が特権に追加され、特権によってアクセス制御ルールのセットの一貫性と完全な情報が作成されます。例えば、パーミッションは自動マウントの場所の追加、編集、削除を行うために作成できます。そして、そのパーミッションは FTP サーバーの管理に関連する別のパーミッションと組み合わせることができます。これらは、ファイルシステムの管理に関連する単一の特権を作成するために作成できます。
- ロール。これは、特権に定義されているアクションを実行できる IdM ユーザーの一覧です。
27.4.1. ロールの作成
27.4.1.1. Web UI でのロールの作成
- トップメニューで IPA Server タブを開き、Role Based Access Control サブタブを選択します。
- ロールベースの ACI 一覧の上部にある Add リンクをクリックします。
- ロール名と説明を入力します。
- Users タブの上部で、グループ追加の場合は Users Groups タブで、Add リンクをクリックします。
- 左側のユーザーを選択し、ボタンを使用して、割り当てられたボックスに移動します。
- ロール設定ページで Privileges タブを開きます。
- 特権一覧の上部にある Add リンクをクリックして、新しい権限を追加します。
- 左側の権限を選択し、ボタンを使用して割り当てられたボックスに移動します。
27.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 ----------------------------
- 必要なグループをロールに追加します。この場合、すでに存在する 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 -------------------------
27.4.2. 新規パーミッションの作成
27.4.2.1. Web UI での新規パーミッションの作成
- トップメニューで IPA Server タブを開き、Role Based Access Control サブタブを選択します。
- Permissions タスクリンクを選択します。
- パーミッションの一覧の上部にある Add リンクをクリックします。
- 新規パーミッションの名前を入力します。
- このパーミッションで許可される操作の横にあるチェックボックスを選択します。
- Target ドロップダウンメニューからターゲットエントリーを識別するのに使用する方法を選択します。以下の 4 つの方法があります。
- type は、ユーザー、ホスト、またはサービスといったエントリータイプを検索し、そのエントリータイプに対して可能なすべての属性のリストを提供します。この ACI からアクセス可能な属性が一覧から選択されます。
- Filter は、パーミッションが適用されるエントリーを特定する LDAP フィルターを使用します。
- サブツリー は、指定されたサブツリーエントリーの下にあるすべてのエントリーをターゲットにします。一致するエントリー内のすべての属性を変更できます。
- ターゲットグループ はユーザーグループを指定し、そのグループ内のすべてのユーザーエントリーは ACI 経由で利用できます。一致するエントリー内のすべての属性を変更できます。
- 選択したタイプに応じて、ターゲットエントリーを特定するために必要な情報を入力します。
- Filter、Subtree、および Target group ターゲットの場合は、Add リンクをクリックして、パーミッションに含まれる属性を追加します。1 つの属性が一度に追加されます。複数の属性を追加するには、再度 Add をクリックして別のフィールドを追加します。パーミッションに属性が設定されていない場合、デフォルトではすべての属性が除外されます。
27.4.2.2. コマンドライン での新規パーミッションの作成
--attr
)、許可されるアクション (--permissions
) のリスト、および ACI のターゲットエントリーが必要です。ターゲットエントリーを識別する方法は 4 つあります。
- --type は、ユーザー、ホスト、またはサービスなどのエントリータイプを検索し、そのエントリータイプに使用できるすべての属性の一覧を表示します。
- --filter は、パーミッションが適用されるエントリーを特定する LDAP フィルターを使用します。
- --subtree は、指定のサブツリーエントリーの下にあるすべてのエントリーをターゲットにします。
- --targetgroup はユーザーグループを指定し、そのグループ内のすべてのユーザーエントリーは ACI 経由で利用できます。
例27.1 フィルターを使用したパーミッションの追加
$ ipa permission-add "manage Windows groups" --filter="(!(objectclass=posixgroup))"
--permissions=write --attrs=description
例27.2 サブツリーのパーミッションの追加
$ ipa permission-add "manage automount locations" --subtree="ldap://ldap.example.com:389/cn=automount,dc=example,dc=com"
--permissions=write --attrs=automountmapname,automountkey,automountInformation
例27.3 オブジェクトタイプに基づいたパーミッションの追加
- user
- グループ
- host
- サービス
- hostgroup
- netgroup
- dnsrecord
$ ipa permission-add "manage service" --permissions=all --type=service --attrs=krbprincipalkey,krbprincipalname,managedby
--attrs
) が存在し、指定のオブジェクトタイプの属性を許可する必要があります。そうでない場合、パーミッション操作はスキーマ構文エラーで失敗します。
27.4.3. 新規権限の作成
27.4.3.1. Web UI での新規権限の作成
- トップメニューで IPA Server タブを開き、Role Based Access Control サブタブを選択します。
- Privileges タスクリンクを選択します。
- 特権一覧の上部にある Add リンクをクリックします。
- 権限の名前と説明を入力します。
- Permissions タブを選択します。
- パーミッション一覧の上部にある Add リンクをクリックして、権限を付与します。
- 追加するパーミッションの名前の横にあるチェックボックスをクリックし、右矢印ボタン () をクリックし、パーミッションを選択項目のボックスに移動します。
27.4.3.2. コマンドライン での新規権限の作成
- 権限エントリーを作成します。
$ ipa privilege-add "managing filesystems" --desc="for filesystems"
- 必要なパーミッションを割り当てます。以下に例を示します。
$ ipa privilege-add-permission "managing filesystems" --permissions="managing automount","managing ftp services"
第28章 設定: IdM サーバーおよびレプリカの設定
28.1. Identity Management ファイルおよびログ
28.1.1. IdM サーバー設定ファイルおよびディレクトリーのリファレンス
ディレクトリーまたはファイル | 説明 | ||
---|---|---|---|
サーバー設定 | |||
/etc/ipa/ | メインの IdM 設定ディレクトリー。 | ||
/etc/ipa/default.conf | IdM の主な設定ファイル。 | ||
/etc/ipa/server.conf | IdM のオプション設定ファイルこれはデフォルトでは存在しませんが、IdM サーバーの起動時にカスタム設定を読み込むことができます。 | ||
/etc/ipa/cli.conf | IdM コマンドラインツールのオプション設定ファイル。これはデフォルトでは存在しませんが、ipa の使用時にカスタム設定を適用するために作成できます。 | ||
/etc/ipa/ca.crt | IdM サーバーの CA が発行する CA 証明書。 | ||
~/.ipa/ | ユーザーが IdM コマンドを初めて実行したときに、システムユーザーのホームディレクトリーのローカルシステムに作成された、ユーザー固有の IdM ディレクトリー。 | ||
IdM ログ | |||
~/.ipa/log/cli.log | XML-RPC 呼び出しで返されるエラーと ldM コマンドユーティリティーの応答に関するログファイルです。これは、IdM ユーザーとは異なる名前を持つツールを実行するシステムユーザーのホームディレクトリーに作成されます。 | ||
/var/log/ipaclient-install.log | クライアントサービスのインストールログ。 | ||
/var/log/ipaserver-install.log | IdM サーバーのインストールログ。 | ||
/etc/logrotate.d/ | DNS、SSSD、Apache、Tomcat、および Kerberos のログローテーションのポリシー | ||
システムサービス | |||
/etc/rc.d/init.d/ipa/ | IdM サーバーの init スクリプト。 | ||
Web UI | |||
/etc/ipa/html/ | IdM Web UI が使用する HTML ファイルのメイン設定ディレクトリーにあるシンボリックリンクディレクトリー。 | ||
| web UI アプリケーションの Apache ホストで使用される設定ファイル | ||
/etc/httpd/conf/ipa.keytab | Web UI サービスが使用するキータブファイル。 | ||
/usr/share/ipa/ | Web UI が使用するすべての HTML ファイル、スクリプト、およびスタイルシートのメインディレクトリー。 | ||
| web UI アプリケーションの Apache ホストで使用される設定ファイル | ||
/usr/share/ipa/updates/ | Identity Management の更新されたファイル、スキーマ、およびその他の要素が含まれます。 | ||
/usr/share/ipa/html/ | web UI で使用される HTML ファイル、JavaScript ファイル、およびスタイルシートが含まれます。 | ||
/usr/share/ipa/ipaclient/ | Firefox の自動設定機能にアクセスし、IdM Kerberos レルムで機能するように Firefox ブラウザーを設定するのに使用する JavaScript ファイルが含まれています。 | ||
/usr/share/ipa/migration/ | IdM サーバーを移行モードで実行する際に使用される HTML ページ、スタイルシート、および Python スクリプトが含まれます。 | ||
/usr/share/ipa/ui/ | IdM 操作を実行するために UI が使用するすべてのスクリプトが含まれます。 | ||
/var/log/httpd/ | Apache Web サーバーのログファイル。 | ||
Kerberos | |||
/etc/krb5.conf | Kerberos サービスの設定ファイル | ||
SSSD | |||
/usr/share/sssd/sssd.api.d/sssd-ipa.conf | SSSD が使用する IdM サーバー、IdM Directory Server、およびその他の IdM サービスの特定に使用される設定ファイル。 | ||
/var/log/sssd/ | SSSD のログファイル。 | ||
389 ディレクトリーサーバー | |||
/var/lib/dirsrv/slapd-REALM_NAME/ | IdM サーバーが使用する Directory Server インスタンスに関連付けられたスキーマ、設定、およびデータベースファイルすべて。 | ||
/var/log/dirsrv/slapd-REALM_NAME/ | IdM サーバーが使用する Directory Server インスタンスに関連付けられたログファイル | ||
Dogtag Certificate System | |||
/etc/pki-ca/ | IdM CA インスタンスのメインディレクトリー。 | ||
/var/lib/pki-ca/conf/CS.cfg | IdM CA インスタンスの主な設定ファイル。 | ||
/var/lib/dirsrv/slapd-PKI-IPA/ | IdM CA が使用する Directory Server インスタンスに関連付けられたスキーマ、設定、およびデータベースファイルすべて。 | ||
/var/log/dirsrv/slapd-PKI-IPA/ | IdM CA が使用する Directory Server インスタンスに関連付けられたログファイル | ||
キャッシュファイル | |||
/var/cache/ipa/ | IdM サーバーおよび IdM Kerberos パスワードデーモンのキャッシュファイル。 | ||
システムバックアップ | |||
/var/lib/ipa/sysrestore/ | ldM サーバーのインストール時に再設定されたスクリプトおよびすべてのシステムファイルのバックアップが格納されます。NSS、Kerberos (krb5.conf と kdc.conf の両方)、および NTP の元の .conf ファイルが含まれます。 | ||
/var/lib/ipa-client/sysrestore/ | ldM クライアントのインストール時に再設定されたスクリプトおよびすべてのシステムファイルのバックアップが格納されます。一般的には、これは SSSD 認証サービスの sssd.conf ファイルです。 |
28.1.2. IdM ドメインサービスとログローテーション
- ネームド (DNS)
- httpd (Apache)
- tomcat6
- sssd
- krb5kdc (Kerberos ドメインコントローラー)
例28.1 デフォルトの httpd ログローテーションファイル
[root@server ~]# cat /etc/logrotate.d/httpd /var/log/httpd/*log { missingok notifempty sharedscripts delaycompress postrotate /sbin/service httpd reload > /dev/null 2>/dev/null || true endscript }
create
ルールを設定します。すべてサービスでは、以前のログと同じ名前、デフォルトの所有者、デフォルトのパーミッションで新しいログファイル作成します。named および tomcat6 ログの場合、create は明示的なパーミッションとユーザー/グループの所有権で設定されます。
[root@server ~]# cat /etc/logrotate.d/named /var/named/data/named.run { missingok create 0644 named named postrotate /sbin/service named reload 2> /dev/null > /dev/null || true endscript }
28.1.3. default.conf およびコンテキスト設定ファイル
default.conf
ファイルに保存されます。この設定ファイルは、IdM クライアントおよびサーバーが起動し、ipa コマンドが操作を実行する際に情報を提供するたびに参照されます。
default.conf
ファイルのパラメーターは単なる attribute=value のペアです。属性は大文字と小文字を区別せず、順序を区別しません。
[global] basedn=dc=example,dc=com realm=EXAMPLE.COM domain=example.com xmlrpc_uri=https://server.example.com/ipa/xml ldap_uri=ldapi://%2fvar%2frun%2fslapd-EXAMPLE-COM.socket enable_ra=True ra_plugin=dogtag mode=production
server.conf
および cli.conf
ファイルを別々に作成できます。IdM サーバーは、まず server.conf
および cli.conf
ファイルを確認してから default.conf
ファイルを確認します。
/etc/ipa
ディレクトリー内の設定ファイルは、システムのすべてのユーザーに適用されます。ユーザーは、ローカル IdM ディレクトリー ~/.ipa/
に default.conf
、server.conf
、または cli.conf
ファイルを作成して、個別のオーバーライドを設定できます。このオプションのファイルは、ローカルの IdM サービス default.conf
とマージされ、使用されます。
28.1.4. IdM サーバーログの確認
サービス | ログファイル | 説明 | 追加情報 | ||||
---|---|---|---|---|---|---|---|
IdM サーバー | /var/log/ipaserver-install.log | サーバーインストールログ | |||||
IdM サーバー | ~/.ipa/log/cli.log | コマンドラインツールのログ | |||||
IdM クライアント | /var/log/ipaclient-install.log | クライアントインストールログ | |||||
Apache サーバー |
| これは、Apache サーバーの標準的なアクセスログおよびエラーログです。Web UI と XML-RPC コマンドラインインターフェースは Apache を使用するため、IdM 固有のメッセージは Apache メッセージとともにエラーログに記録されます。 | Apache ログの章 | ||||
Dogtag Certificate System | /var/log/pki-ca-install.log | IdM KRA のインストールログ | |||||
Dogtag Certificate System |
| これらのログは、主に証明書操作に関連します。IdM では、これは証明書を使用するサービスプリンシパル、ホスト、およびその他のエンティティーに使用されます。 | ロギングの章 | ||||
389 ディレクトリーサーバー |
| アクセスログとエラーログには、ドメイン Directory Server インスタンスのアクセスと操作の詳細情報が含まれます。エラーログ設定を変更して、非常に詳細な出力を提供できます。 | アクセスログはバッファーされるため、サーバーはデフォルトでは 30 秒ごとにログでのみ書き込みます。 | ||||
389 ディレクトリーサーバー |
| このディレクトリーサーバーインスタンスは、証明書情報を保存するために IdM CA により使用されます。ここでの操作データの多くは、server-replica の対話に関連します。 | アクセスログはバッファーされるため、サーバーはデフォルトでは 30 秒ごとにログでのみ書き込みます。 | ||||
Kerberos | /var/log/krb5libs.log | これは、Kerberos 接続のプライマリーログファイルです。 | この場所は krb5.conf ファイルで設定されるため、一部のシステムで異なる可能性があります。 | ||||
Kerberos | /var/log/krb5kdc.log | これは、Kerberos KDC サーバーの主なログファイルです。 | この場所は krb5.conf ファイルで設定されるため、一部のシステムで異なる可能性があります。 | ||||
Kerberos | /var/log/kadmind.log | これは、Kerberos 管理システムサーバーの主なログファイルです。 | この場所は krb5.conf ファイルで設定されるため、一部のシステムで異なる可能性があります。 | ||||
DNS | /var/log/messages | DNS エラーメッセージは、他のシステムメッセージに含まれます。 | DNS ロギングはデフォルトでは有効になって いません。DNS ロギングは、以下の querylog コマンドを実行して有効にします。
/usr/sbin/rndc querylogこれにより、システムの /var/log/messages ファイルにログメッセージが書き込まれます。ログを無効にするには、querylog コマンドを実行します。 |
28.1.4.1. サーバーデバッグロギングの有効化
server.conf
ファイルに設定されます。
default.conf
設定ファイルを編集すると、IdM サーバーだけでなく、すべての IdM コンポーネントに影響します。
server.conf
ファイルを編集するか、または作成します。vim server.conf
- debug 行を追加し、その値を true に設定します。
[global] debug=True
- Apache デーモンを再起動して、変更を読み込みます。
service httpd restart
28.1.4.2. コマンドライン操作のデバッグ
-v
オプションを指定してデバッグ情報を返すことができます。たとえば、以下のようになります。
$ ipa -v
user-show admin
ipa: INFO: trying https://ipaserver.example.com/ipa/xml
First name: John
Last name: Smythe
User login [jsmythe]:
ipa: INFO: Forwarding 'user_add' to server u'https://ipaserver.example.com/ipa/xml'
--------------------
Added user "jsmythe"
--------------------
User login: jsmythe
First name: John
Last name: Smythe
Full name: John Smythe
Display name: John Smythe
Initials: JS
Home directory: /home/jsmythe
GECOS field: John Smythe
Login shell: /bin/sh
Kerberos principal: jsmythe@EXAMPLE.COM
UID: 1966800003
GID: 1966800003
Keytab: False
Password: False
-vv
)、XML-RPC 交換を表示します。
$ ipa -vv user-add ipa: INFO: trying https://ipaserver.example.com/ipa/xml First name: Jane Last name: Russell User login [jrussell]: ipa: INFO: Forwarding 'user_add' to server u'https://ipaserver.example.com/ipa/xml' send: u'POST /ipa/xml HTTP/1.0\r\nHost: ipaserver.example.com\r\nAccept-Language: en-us\r\nAuthorization: negotiate YIIFgQYJKoZIhvcSAQICAQBuggVwMIIFbKADAgEFoQMCAQ6iBwMFACAAAACjggGHYYIBgzCCAX+gAwIBBaEZGxdSSFRTLkVORy5CT1MuUkVESEFULkNPTaI5MDegAwIBA6EwMC4bBEhUVFAbJmRlbGwtcGUxODUwLTAxLnJodHMuZW5nLmJvcy5yZWRoYXQuY29to4IBIDCCARygAwIBEqEDAgECooIBDgSCAQpV2YEWv03X+SENdUBfOhMFGc3Fvnd51nELV0rIB1tfGVjpNlkuQxXKSfFKVD3vyAUqkii255T0mnXyTwayE93W1U4sOshetmG50zeU4KDmhuupzQZSCb5xB0KPU4HMDvP1UnDFJUGCk9tcqDJiYE+lJrEcz8H+Vxvvl+nP6yIdUQKqoEuNhJaLWIiT8ieAzk8zvmDlDzpFYtInGWe9D5ko1Bb7Npu0SEpdVJB2gnB5vszCIdLlzHM4JUqX8p21AZV0UYA6QZOWX9OXhqHdElKcuHCN2s9FBRoFYK83gf1voS7xSFlzZaFsEGHNmdA0qXbzREKGqUr8fmWmNvBGpDiR2ILQep09lL56JqSCA8owggPGoAMCARKiggO9BIIDuarbB67zjmBu9Ax2K+0klSD99pNv97h9yxol8c6NGLB4CmE8Mo39rL4MMXHeOS0OCbn+TD97XVGLu+cgkfVcuIG4PMMBoajuSnPmIf7qDvfa8IYDFlDDnRB7I//IXtCc/Z4rBbaxk0SMIRLrsKf5wha7aWtN1JbizBMQw+J0UlN8JjsWxu0Ls75hBtIDbPf3fva3vwBf7kTBChBsheewSAlck9qUglyNxAODgFVvRrXbfkw51Uo++9qHnhh+zFSWepfv7US7RYK0KxOKFd+uauY1ES+xlnMvK18ap2pcy0odBkKu1kwJDND0JXUdSY08MxK2zb/UGWrVEf6GIsBgu122UGiHp6C+0fEu+nRrvtORY65Bgi8E1vm55fbb/9dQWNcQheL9m6QJWPw0rgc+E5SO99ON6x3Vv2+Zk17EmbZXinPd2tDe7fJ9cS9o/z7Qjw8z8vvSzHL4GX7FKi2HJdBST3nEgOC8PqO46UnAJcA8pf1ZkwCK9xDWH+5PSph6WnvpRqugqf/6cq+3jk3MEjCrx+JBJ8QL6AgN3oEB4kvjZpAC+FfTkdX59VLDwfL/r0gMw3ZNk0nLLCLkiiYUMTEHZBzJw9kFbsX3LmS8qQQA6rQ2L782DYisElywfZ/0Sax8JO/G62Zvy7BHy7SQSGIvcdAOafeNyfxaWM1vTpvSh0GrnllYfs3FhZAKnVcLYrlPTapR23uLgRMv+0c9wAbwuUDfKgOOl5vAd1j55VUyapgDEzi/URsLdVdcF4zigt4KrTByCwU2/pI6FmEPqB2tsjM2A8JmqA+9Nt8bjaNdNwCOWE0dF50zeL9P8oodWGkbRZLk4DLIurpCW1d6IyTBhPQ5qZqHJWeoGiFa5y94zBpp27goMPmE0BskXT0JQmveYflOeKEMSzyiWPL2mwi7KEMtfgCpwTIGP2LRE/QxNvPGkwFfO+PDjZGVw+APKkMKqclVXxhtJA/2NmBrO1pZIIJ9R+41sR/QoACcXIUXJnhrTwwR1viKCB5Tec87gN+e0Cf0g+fmZuXNRscwJfhYQJYwJqdYzGtZW+h8jDWqa2EPcDwIQwyFAgXNQ/aMvh1yNTECpLEgrMhYmFAUDLQzI2BDnfbDftIs0rXjSC0oZn/Uaoqdr4F5syOrYAxH47bS6MW8CxyylreH8nT2qQXjenakLFHcNjt4M1nOc/igzNSeZ28qW9WSr4bCdkH+ra3BVpT/AF0WHWkxGF4vWr/iNHCjq8fLF+DsAEx0Zs696Rg0fWZy079A\r\nUser-Agent: xmlrpclib.py/1.0.1 (by www.pythonware.com)\r\nContent-Type: text/xml\r\nContent-Length: 1240\r\n\r\n' send: "<?xml version='1.0' encoding='UTF-8'?>\n<methodCall>\n<methodName>user_add</methodName>\n<params>\n<param>\n<value><array><data>\n<value><string>jrussell</string></value>\n</data></array></value>\n</param>\n<param>\n<value><struct>\n<member>\n<name>all</name>\n<value><boolean>0</boolean></value>\n</member>\n<member>\n<name>displayname</name>\n<value><string>Jane Russell</string></value>\n</member>\n<member>\n<name>cn</name>\n<value><string>Jane Russell</string></value>\n</member>\n<member>\n<name>noprivate</name>\n<value><boolean>0</boolean></value>\n</member>\n<member>\n<name>uidnumber</name>\n<value><int>999</int></value>\n</member>\n<member>\n<name>raw</name>\n<value><boolean>0</boolean></value>\n</member>\n<member>\n<name>version</name>\n<value><string>2.11</string></value>\n</member>\n<member>\n<name>gecos</name>\n<value><string>Jane Russell</string></value>\n</member>\n<member>\n<name>sn</name>\n<value><string>Russell</string></value>\n</member>\n<member>\n<name>krbprincipalname</name>\n<value><string>jrussell@EXAMPLE.COM</string></value>\n</member>\n<member>\n<name>givenname</name>\n<value><string>Jane</string></value>\n</member>\n<member>\n<name>initials</name>\n<value><string>JR</string></value>\n</member>\n</struct></value>\n</param>\n</params>\n</methodCall>\n" reply: 'HTTP/1.1 200 OK\r\n' header: Date: Thu, 15 Sep 2011 00:50:39 GMT header: Server: Apache/2.2.15 (Red Hat) header: WWW-Authenticate: Negotiate YIGZBgkqhkiG9xIBAgICAG+BiTCBhqADAgEFoQMCAQ+iejB4oAMCARKicQRvVl5x6Zt9PbWNzvPEWkdu+3PTCq/ZVKjGHM+1zDBz81GL/f+/Pr75zTuveLYn9de0C3k27vz96fn2HQsy9qVH7sfqn0RWGQWzl+kDkuD6bJ/Dp/mpJvicW5gSkCSH6/UCNuE4I0xqwabLIz8MM/5o header: Connection: close header: Content-Type: text/xml; charset=utf-8 body: "<?xml version='1.0' encoding='UTF-8'?>\n<methodResponse>\n<params>\n<param>\n<value><struct>\n<member>\n<name>result</name>\n<value><struct>\n<member>\n<name>dn</name>\n<value><string>uid=jrussell,cn=users,cn=accounts,dc=example,dc=com</string></value>\n</member>\n<member>\n<name>has_keytab</name>\n<value><boolean>0</boolean></value>\n</member>\n<member>\n<name>displayname</name>\n<value><array><data>\n<value><string>Jane Russell</string></value>\n</data></array></value>\n</member>\n<member>\n<name>uid</name>\n<value><array><data>\n<value><string>jrussell</string></value>\n</data></array></value>\n</member>\n<member>\n<name>objectclass</name>\n<value><array><data>\n<value><string>top</string></value>\n<value><string>person</string></value>\n<value><string>organizationalperson</string></value>\n<value><string>inetorgperson</string></value>\n<value><string>inetuser</string></value>\n<value><string>posixaccount</string></value>\n<value><string>krbprincipalaux</string></value>\n<value><string>krbticketpolicyaux</string></value>\n<" body: 'value><string>ipaobject</string></value>\n</data></array></value>\n</member>\n<member>\n<name>loginshell</name>\n<value><array><data>\n<value><string>/bin/sh</string></value>\n</data></array></value>\n</member>\n<member>\n<name>uidnumber</name>\n<value><array><data>\n<value><string>1966800004</string></value>\n</data></array></value>\n</member>\n<member>\n<name>initials</name>\n<value><array><data>\n<value><string>JR</string></value>\n</data></array></value>\n</member>\n<member>\n<name>gidnumber</name>\n<value><array><data>\n<value><string>1966800004</string></value>\n</data></array></value>\n</member>\n<member>\n<name>gecos</name>\n<value><array><data>\n<value><string>Jane Russell</string></value>\n</data></array></value>\n</member>\n<member>\n<name>sn</name>\n<value><array><data>\n<value><string>Russell</string></value>\n</data></array></value>\n</member>\n<member>\n<name>homedirectory</name>\n<value><array><data>\n<value><string>/home/jrussell</string></value>\n</data></array></value>\n</member>\n<member>\n<name>has_password</name>\n<value><boolean>0</' body: 'boolean></value>\n</member>\n<member>\n<name>krbprincipalname</name>\n<value><array><data>\n<value><string>jrussell@EXAMPLE.COM</string></value>\n</data></array></value>\n</member>\n<member>\n<name>givenname</name>\n<value><array><data>\n<value><string>Jane</string></value>\n</data></array></value>\n</member>\n<member>\n<name>cn</name>\n<value><array><data>\n<value><string>Jane Russell</string></value>\n</data></array></value>\n</member>\n<member>\n<name>ipauniqueid</name>\n<value><array><data>\n<value><string>bba27e6e-df34-11e0-a5f4-001143d2c060</string></value>\n</data></array></value>\n</member>\n</struct></value>\n</member>\n<member>\n<name>value</name>\n<value><string>jrussell</string></value>\n</member>\n<member>\n<name>summary</name>\n<value><string>Added user "jrussell"</string></value>\n</member>\n</struct></value>\n</param>\n</params>\n</methodResponse>\n' --------------------- Added user "jrussell" --------------------- User login: jrussell First name: Jane Last name: Russell Full name: Jane Russell Display name: Jane Russell Initials: JR Home directory: /home/jrussell GECOS field: Jane Russell Login shell: /bin/sh Kerberos principal: jrussell@EXAMPLE.COM UID: 1966800004 GID: 1966800004 Keytab: False Password: False
-v
と -vv
オプションは グローバル オプションであり、ipa の実行時にサブコマンドの前に使用する必要があります。
28.2. 証明書と認証局の管理
28.2.1. 外部 CA が発行する CA 証明書の更新
certmonger
ユーティリティーにより追跡され、有効期限が近いときに自動的に更新されます。
certutil
NSS セキュリティーユーティリティーを使用して行います。[8]
- 証明書を発行した外部 CA は更新を許可する必要があります。
- CA の秘密鍵は変更しないでください。
- 新しい証明書には、元の証明書と同じサブジェクト名を指定する必要があります。
- 外部 CA のコピーが依然としてある可能性があります。
- 最初にインストールした IdM サーバーの
/root/ipa.csr
ファイルで、 - 最初にインストールした IdM サーバーの
/etc/pki-ca/CS.cfg
ファイルのca.signing.certreq セクション
。これは PEM 形式に変換する必要があります。
<REALM> IPA CA
です。ここでは EXAMPLE.COM IPA CA
を使用します。Apache データベースに対してクエリーを実行して、現在のニックネームを見つけるには、以下のコマンドを実行します。
# certutil -L -d /etc/httpd/alias
28.2.1.1. 更新手順
証明書の更新
/root/ipa.crt
ファイルに保存されることを前提とします。また、/root/external-ca.pem
ファイルに PEM 形式の外部 CA 証明書チェーンが含まれていることを前提としています。更新の管理には、指定した IdM CA で更新を行う必要があります。最初にインストールされた IdM サーバーを特定する方法として、subsystem.select
の値が New
であるかどうかを確認することができます。
# grep subsystem.select /etc/pki-ca/CS.cfg
subsystem.select=New
Number of certificates and requests being tracked: 8.
Request ID '20131125153455':
status: MONITORING
stuck: no
key pair storage: type=NSSDB,location='/var/lib/pki-ca/alias',nickname='auditSigningCert cert-pki-ca',token='NSS Certificate DB',pin='455536908955'
certificate: type=NSSDB,location='/var/lib/pki-ca/alias',nickname='auditSigningCert cert-pki-ca',token='NSS Certificate DB'
CA: dogtag-ipa-renew-agent
issuer: CN=Certificate Authority,O=EXAMPLE.COM
subject: CN=CA Audit,O=EXAMPLE.COM
expires: 2015-11-15 15:34:12 UTC
pre-save command: /usr/lib64/ipa/certmonger/stop_pkicad
post-save command: /usr/lib64/ipa/certmonger/renew_ca_cert "auditSigningCert cert-pki-ca"
track: yes
auto-renew: yes
...
最初にインストールした IdM サーバーに新しい CA 証明書をインストールする
- 証明書を更新するには、CA をシャットダウンする必要があります。
# service ipa stop
- CA 証明書の NSS データベースを更新します。
# certutil -A -d /var/lib/pki-ca/alias -n 'caSigningCert cert-pki-ca' -t CT,C,C -a -i /root/ipa.crt
/etc/pki-ca/CS.cfg
のca.signing.cert
の値を置き換えます。これは、証明書の base64 値です。これを取得するには、BEGIN/END ブロックをipa.crt
から削除し、1 つの行に圧縮します。- Apache NSS データベースを更新します。
# certutil -A -d /etc/httpd/alias -n 'EXAMPLE.COM IPA CA' -t CT,C,C -a -i /root/ipa.crt
- LDAP サーバーインスタンスを更新します。
# certutil -A -d /etc/dirsrv/slapd-EXAMPLE-COM -n 'EXAMPLE.COM IPA CA' -t CT,C,C -a -i /root/ipa.crt # certutil -A -d /etc/dirsrv/slapd-PKI-IPA -n 'EXAMPLE.COM IPA CA' -t CT,C,C -a -i /root/ipa.crt
- ファイルシステムの CA 証明書を更新します。
# cp /root/ipa.crt /etc/ipa/ca.crt # cat /root/ipa.crt /root/external-ca.pem >/etc/httpd/alias/cacert.asc # cp /etc/httpd/alias/cacert.asc /usr/share/ipa/html/ca.crt
- 共有システムデータベースを更新します。
# certutil -A -d /etc/pki/nssdb -n 'IPA CA' -t CT,C,C -a -i /root/ipa.crt
- サービスを再起動します。
# service ipa start
- LDAP で CA 証明書を更新します。まず、証明書を DER 形式に変換します。
# openssl x509 -outform DER -in /root/ipa.crt -out /tmp/ipa.der
- 証明書を LDAP に追加します。
# kinit admin # ldapmodify -Y GSSAPI SASL/GSSAPI authentication started SASL username: admin@EXAMPLE.COM SASL SSF: 56 SASL data security layer installed. dn: cn=CAcert,cn=ipa,cn=etc,dc=example,dc=com changetype: modify replace: cacertificate;binary cacertificate;binary:<file:///tmp/ipa.der
CA を使用する他の IdM サーバーに新しい CA 証明書をインストールする
- 更新された証明書をマシンにコピーし、サービスを停止します。ファイルは
/root/ipa.crt
と想定します。# service ipa stop
- Apache NSS データベースを更新します。
# certutil -A -d /var/lib/pki-ca/alias -n 'caSigningCert cert-pki-ca' -t CT,C,C -a -i /root/ipa.crt
/etc/pki-ca/CS.cfg
のca.signing.cert
の値を置き換えます。これは、証明書の base64 値です。これを取得するには、BEGIN/END ブロックをipa.crt
から削除し、1 つの行に圧縮します。- Apache NSS データベースを更新します。
# certutil -A -d /etc/httpd/alias -n 'EXAMPLE.COM IPA CA' -t CT,C,C -a -i /root/ipa.crt
- LDAP サーバーインスタンスを更新します。
# certutil -A -d /etc/dirsrv/slapd-EXAMPLE-COM -n 'EXAMPLE.COM IPA CA' -t CT,C,C -a -i /root/ipa.crt # certutil -A -d /etc/dirsrv/slapd-PKI-IPA -n 'EXAMPLE.COM IPA CA' -t CT,C,C -a -i /root/ipa.crt
- ファイルシステムの CA 証明書を更新します。
# cp /root/ipa.crt /etc/ipa/ca.crt # cat /root/ipa.crt /root/external-ca.pem >/etc/httpd/alias/cacert.asc # cp /etc/httpd/alias/cacert.asc /usr/share/ipa/html/ca.crt
- 共有システムデータベースを更新します。
# certutil -A -d /etc/pki/nssdb -n 'IPA CA' -t CT,C,C -a -i /root/ipa.crt
- サービスを再起動します。
# service ipa start
CA を使用しない他の IdM マスターに新しい CA 証明書をインストールする
- 更新された証明書をマシンにコピーし、サービスを停止します。ファイルは
/root/ipa.crt
と想定します。# service ipa stop
- Apache NSS データベースを更新します。
# certutil -A -d /etc/httpd/alias -n 'EXAMPLE.COM IPA CA' -t CT,C,C -a -i /root/ipa.crt
- LDAP サーバーインスタンスを更新します。
# certutil -A -d /etc/dirsrv/slapd-EXAMPLE-COM -n 'EXAMPLE.COM IPA CA' -t CT,C,C -a -i /root/ipa.crt # certutil -A -d /etc/dirsrv/slapd-PKI-IPA -n 'EXAMPLE.COM IPA CA' -t CT,C,C -a -i /root/ipa.crt
- ファイルシステムの CA 証明書を更新します。
# cp /root/ipa.crt /etc/ipa/ca.crt # cat /root/ipa.crt /root/external-ca.pem >/etc/httpd/alias/cacert.asc # cp /etc/httpd/alias/cacert.asc /usr/share/ipa/html/ca.crt
- 共有システムデータベースを更新します。
# certutil -A -d /etc/pki/nssdb -n 'IPA CA' -t CT,C,C -a -i /root/ipa.crt
- サービスを再起動します。
# service ipa start
すべての IdM クライアントマシンに新しい CA 証明書をインストールする
/tmp/ipa.crt
と想定します。
# certutil -A -d /etc/pki/nssdb -n 'IPA CA' -t CT,C,C -a -i /tmp/ipa.crt # cp /tmp/ipa.crt /etc/ipa/ca.crt
28.2.2. IdM CA が発行する CA 証明書の更新
certmonger
ユーティリティーにより追跡され、有効期限が近いときに自動的に更新されます。
28.2.2.1. 更新手順
IdM CA の署名証明書を更新し、最初にインストールした IdM サーバーに新しい CA 証明書のインストールする
- IPA が停止していることを確認します。
# ipactl status # ipactl stop
- ntpd が実行していないことを確認します。
# service ntpd status # service ntpd stop
- Directory Server を起動し、これが実行していることを確認します。
# service dirsrv start # service dirsrv status
- Dogtag CA を起動し、これが実行されていることを確認します。
# service pki-cad start # service pki-cad status
- dogtag-ipa-renew-agent-submit コマンドを入力して、certmonger ヘルパー経由で Dogtag CA 署名証明書を直接更新します。
# /usr/libexec/certmonger/dogtag-ipa-renew-agent-submit -D 1 -T caCACert | tail -n 1 | xargs /usr/libexec/certmonger/dogtag-ipa-renew-agent-submit -d /etc/httpd/alias -n ipaCert -p /etc/httpd/alias/pwdfile.txt -v -S
- CA 証明書の NSS データベースを更新します。
# certutil -A -d /var/lib/pki-ca/alias -n 'caSigningCert cert-pki-ca' -t CT,C,C -a -i /root/ipa.crt
/etc/pki-ca/CS.cfg
のca.signing.cert
の値を置き換えます。これは、証明書の base64 値です。これを取得するには、BEGIN/END ブロックをipa.crt
から削除し、1 つの行に圧縮します。- Apache NSS データベースを更新します。
# certutil -A -d /etc/httpd/alias -n 'EXAMPLE.COM IPA CA' -t CT,C,C -a -i /root/ipa.crt
- LDAP サーバーインスタンスを更新します。
# certutil -A -d /etc/dirsrv/slapd-EXAMPLE-COM -n 'EXAMPLE.COM IPA CA' -t CT,C,C -a -i /root/ipa.crt # certutil -A -d /etc/dirsrv/slapd-PKI-IPA -n 'EXAMPLE.COM IPA CA' -t CT,C,C -a -i /root/ipa.crt
- ファイルシステムの CA 証明書を更新します。
# cp /root/ipa.crt /etc/ipa/ca.crt # cat /root/ipa.crt /root/external-ca.pem >/etc/httpd/alias/cacert.asc # cp /etc/httpd/alias/cacert.asc /usr/share/ipa/html/ca.crt
- 共有システムデータベースを更新します。
# certutil -A -d /etc/pki/nssdb -n 'IPA CA' -t CT,C,C -a -i /root/ipa.crt
- サービスを再起動します。
# ipactl start
- LDAP で CA 証明書を更新します。まず、証明書を DER 形式に変換します。
# openssl x509 -outform DER -in /root/ipa.crt -out /tmp/ipa.der
- 証明書を LDAP に追加します。
# kinit admin # ldapmodify -Y GSSAPI SASL/GSSAPI authentication started SASL username: admin@EXAMPLE.COM SASL SSF: 56 SASL data security layer installed. dn: cn=CAcert,cn=ipa,cn=etc,dc=example,dc=com changetype: modify replace: cacertificate;binary cacertificate;binary:<file:///tmp/ipa.der
- ipa-getcert list を使用して、certmonger が追跡するすべての要求の一覧を表示します。
# ipa-getcert list
- この出力で、サブシステム証明書のいずれかがすでに期限切れであることが示されたら、それぞれの証明書に対して個別に ipa-getcert resubmit を使用して証明書を更新します。詳細は、ナレッジベースソリューション「Dealing with expiring IDM CA certificates on Red Hat Enterprise Linux 6 and 7」を参照してください。
CA を使用する他の IdM サーバーに新しい CA 証明書をインストールする
- 更新された証明書をマシンにコピーし、サービスを停止します。ファイルは
/root/ipa.crt
と想定します。# service ipa stop
- Apache NSS データベースを更新します。
# certutil -A -d /var/lib/pki-ca/alias -n 'caSigningCert cert-pki-ca' -t CT,C,C -a -i /root/ipa.crt
/etc/pki-ca/CS.cfg
のca.signing.cert
の値を置き換えます。これは、証明書の base64 値です。これを取得するには、BEGIN/END ブロックをipa.crt
から削除し、1 つの行に圧縮します。- Apache NSS データベースを更新します。
# certutil -A -d /etc/httpd/alias -n 'EXAMPLE.COM IPA CA' -t CT,C,C -a -i /root/ipa.crt
- LDAP サーバーインスタンスを更新します。
# certutil -A -d /etc/dirsrv/slapd-EXAMPLE-COM -n 'EXAMPLE.COM IPA CA' -t CT,C,C -a -i /root/ipa.crt # certutil -A -d /etc/dirsrv/slapd-PKI-IPA -n 'EXAMPLE.COM IPA CA' -t CT,C,C -a -i /root/ipa.crt
- ファイルシステムの CA 証明書を更新します。
# cp /root/ipa.crt /etc/ipa/ca.crt # cat /root/ipa.crt /root/external-ca.pem >/etc/httpd/alias/cacert.asc # cp /etc/httpd/alias/cacert.asc /usr/share/ipa/html/ca.crt
- 共有システムデータベースを更新します。
# certutil -A -d /etc/pki/nssdb -n 'IPA CA' -t CT,C,C -a -i /root/ipa.crt
- サービスを再起動します。
# service ipa start
CA を使用しない他の IdM マスターに新しい CA 証明書をインストールする
- 更新された証明書をマシンにコピーし、サービスを停止します。ファイルは
/root/ipa.crt
と想定します。# service ipa stop
- Apache NSS データベースを更新します。
# certutil -A -d /etc/httpd/alias -n 'EXAMPLE.COM IPA CA' -t CT,C,C -a -i /root/ipa.crt
- LDAP サーバーインスタンスを更新します。
# certutil -A -d /etc/dirsrv/slapd-EXAMPLE-COM -n 'EXAMPLE.COM IPA CA' -t CT,C,C -a -i /root/ipa.crt # certutil -A -d /etc/dirsrv/slapd-PKI-IPA -n 'EXAMPLE.COM IPA CA' -t CT,C,C -a -i /root/ipa.crt
- ファイルシステムの CA 証明書を更新します。
# cp /root/ipa.crt /etc/ipa/ca.crt # cat /root/ipa.crt /root/external-ca.pem >/etc/httpd/alias/cacert.asc # cp /etc/httpd/alias/cacert.asc /usr/share/ipa/html/ca.crt
- 共有システムデータベースを更新します。
# certutil -A -d /etc/pki/nssdb -n 'IPA CA' -t CT,C,C -a -i /root/ipa.crt
- サービスを再起動します。
# service ipa start
すべての IdM クライアントマシンに新しい CA 証明書をインストールする
/tmp/ipa.crt
と想定します。
# certutil -A -d /etc/pki/nssdb -n 'IPA CA' -t CT,C,C -a -i /tmp/ipa.crt # cp /tmp/ipa.crt /etc/ipa/ca.crt
28.2.3. 代替認証局の設定
/usr/share/ipa/html/ca.crt
として保存します。これにより、ユーザーはブラウザーの設定時に正しい証明書をダウンロードできます。
- ipa-server-certinstall コマンドを使用して、証明書をインストールします。
# /usr/sbin/ipa-server-certinstall -d /path/to/pkcs12.p12
- Firefox でブラウザーの自動設定を使用し続けるには、
/usr/share/ipa/html/configure.jar
ファイルを再生成します。- ディレクトリーを作成し、そのディレクトリーに新しいセキュリティーデータベースを作成します。
# mkdir /tmp/signdb # certutil -N -d /tmp/signdb
- 署名証明書の PKCS #12 ファイルをそのディレクトリーにインポートします。
# pk12util -i /path/to/pkcs12.p12 -d /tmp/signdb
- 一時的な署名ディレクトリーを作成し、IdM JavaScript ファイルをそのディレクトリーにコピーします。
# mkdir /tmp/sign # cp /usr/share/ipa/html/preferences.html /tmp/sign
- オブジェクト署名証明書を使用して JavaScript ファイルに署名し、
configure.jar
ファイルを再生成します。# signtool -d /tmp/signdb -k Signing_cert_nickname -Z /usr/share/ipa/html/configure.jar -e .html /tmp/sign
28.2.4. CRL を生成するサーバーの変更
/var/lib/pki-ca/conf/CS.cfg
では、CRL 生成が有効にされています。
ca.crl.issuingPointId.enableCRLCache=true ca.crl.issuingPointId.enableCRLUpdates=true ca.listenToCloneModifications=false
ca.crl.issuingPointId.enableCRLUpdates=false
- マスター CA サーバーであるサーバーインスタンスを特定します。CRL の生成 および 更新操作は、いずれも同じ CA サーバーによって処理されます。したがって、マスター CA は、certmonger で追跡されている renew_ca_cert 証明書を利用して識別できます。
[root@server ~]# getcert list -d /var/lib/pki-ca/alias -n "subsystemCert cert-pki-ca" | grep post-save post-save command: /usr/lib64/ipa/certmonger/renew_ca_cert "subsystemCert cert-pki-ca"
- 元のマスター CA で、元の CA 証明書の追跡を無効にします。
[root@server ~]# getcert stop-tracking -d /var/lib/pki-ca/alias -n "auditSigningCert cert-pki-ca" Request "20131127184547" removed. [root@server ~]# getcert stop-tracking -d /var/lib/pki-ca/alias -n "ocspSigningCert cert-pki-ca" Request "20131127184548" removed. [root@server ~]# getcert stop-tracking -d /var/lib/pki-ca/alias -n "subsystemCert cert-pki-ca" Request "20131127184549" removed. [root@server ~]# getcert stop-tracking -d /etc/httpd/alias -n ipaCert Request "20131127184550" removed.
- 元のマスター CA を再設定し、新規マスター CA から更新された証明書を取得します。
- 更新ヘルパーを certmonger ディレクトリーにコピーし、適切なパーミッションを設定します。
[root@server ~]# cp /usr/share/ipa/ca_renewal /var/lib/certmonger/cas/ca_renewal [root@server ~]# chmod 0600 /var/lib/certmonger/cas/ca_renewal
- SELinux 設定を更新します。
[root@server ~]# /sbin/restorecon /var/lib/certmonger/cas/ca_renewal
- certmonger を再起動します。
[root@server ~]# service certmonger restart
- CA が証明書を取得するようになっているかチェックします。これは CA 設定で出力されます。
[root@server ~]# 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@server ~]# grep internal= /var/lib/pki-ca/conf/password.conf
- 外部更新の証明書 certmonger 追跡を設定します。これには、データベース PIN が必要です。
[root@server ~]# getcert start-tracking -c dogtag-ipa-retrieve-agent-submit -d /var/lib/pki-ca/alias -n "auditSigningCert cert-pki-ca" -B /usr/lib64/ipa/certmonger/stop_pkicad -C '/usr/lib64/ipa/certmonger/restart_pkicad "auditSigningCert cert-pki-ca"' -T "auditSigningCert cert-pki-ca" -P database_pin New tracking request "20131127184743" added. [root@server ~]# getcert start-tracking -c dogtag-ipa-retrieve-agent-submit -d /var/lib/pki-ca/alias -n "ocspSigningCert cert-pki-ca" -B /usr/lib64/ipa/certmonger/stop_pkicad -C '/usr/lib64/ipa/certmonger/restart_pkicad "ocspSigningCert cert-pki-ca"' -T "ocspSigningCert cert-pki-ca" -P database_pin New tracking request "20131127184744" added. [root@server ~]# getcert start-tracking -c dogtag-ipa-retrieve-agent-submit -d /var/lib/pki-ca/alias -n "subsystemCert cert-pki-ca" -B /usr/lib64/ipa/certmonger/stop_pkicad -C '/usr/lib64/ipa/certmonger/restart_pkicad "subsystemCert cert-pki-ca"' -T "subsystemCert cert-pki-ca" -P database_pin New tracking request "20131127184745" added. [root@server ~]# getcert start-tracking -c dogtag-ipa-retrieve-agent-submit -d /etc/httpd/alias -n ipaCert -C /usr/lib64/ipa/certmonger/restart_httpd -T ipaCert -p /etc/httpd/alias/pwdfile.txt New tracking request "20131127184746" added.
- 元のマスター CA で CRL 生成を停止します。
- CA サービスを停止します。
[root@server ~]# service pki-cad stop
- CA 設定ファイルを開きます。
[root@server ~]# vim /var/lib/pki-ca/conf/CS.cfg
ca.crl.MasterCRL.enableCRLCache
およびca.crl.MasterCRL.enableCRLUpdates
パラメーターの値を false に変更して CRL 生成を無効にします。ca.crl.MasterCRL.enableCRLCache=false ca.crl.MasterCRL.enableCRLUpdates=false
- CA サービスを起動します。
[root@server ~]# service pki-cad start
- CRL 要求を新規マスターにリダイレクトするように Apache を設定します。
- CA プロキシー設定を開きます。
[root@server ~]# vim /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]
- Apache を再起動します。
[root@server ~]# service httpd restart
- CA の証明書の追跡を停止して、更新設定を変更します。クローンとして、CA はマスターから更新された証明書を取得するよう設定されています。マスター CA として、更新した証明書を発行します。
[root@server ~]# getcert stop-tracking -d /var/lib/pki-ca/alias -n "auditSigningCert cert-pki-ca" Request "20131127163822" removed. [root@server ~]# getcert stop-tracking -d /var/lib/pki-ca/alias -n "ocspSigningCert cert-pki-ca" Request "20131127163823" removed. [root@server ~]# getcert stop-tracking -d /var/lib/pki-ca/alias -n "subsystemCert cert-pki-ca" Request "20131127163824" removed. [root@server ~]# getcert stop-tracking -d /etc/httpd/alias -n ipaCert Request "20131127164042" removed.
- CA 証明書データベースの PIN を取得します。
[root@server ~]# grep internal= /var/lib/pki-ca/conf/password.conf
- 更新エージェントプロファイルを使用して certmonger で追跡される証明書を設定します。
[root@server ~]# getcert start-tracking -c dogtag-ipa-renew-agent -d /var/lib/pki-ca/alias -n "auditSigningCert cert-pki-ca" -B /usr/lib64/ipa/certmonger/stop_pkicad -C '/usr/lib64/ipa/certmonger/renew_ca_cert "auditSigningCert cert-pki-ca"' -P database_pin New tracking request "20131127185430" added. [root@server ~]# getcert start-tracking -c dogtag-ipa-renew-agent -d /var/lib/pki-ca/alias -n "ocspSigningCert cert-pki-ca" -B /usr/lib64/ipa/certmonger/stop_pkicad -C '/usr/lib64/ipa/certmonger/renew_ca_cert "ocspSigningCert cert-pki-ca"' -P database_pin New tracking request "20131127185431" added. [root@server ~]# getcert start-tracking -c dogtag-ipa-renew-agent -d /var/lib/pki-ca/alias -n "subsystemCert cert-pki-ca" -B /usr/lib64/ipa/certmonger/stop_pkicad -C '/usr/lib64/ipa/certmonger/renew_ca_cert "subsystemCert cert-pki-ca"' -P database_pin New tracking request "20131127185432" added. [root@server ~]# getcert start-tracking -c dogtag-ipa-renew-agent -d /etc/httpd/alias -n ipaCert -C /usr/lib64/ipa/certmonger/renew_ra_cert -p /etc/httpd/alias/pwdfile.txt New tracking request "20131127185433" added.
- 新規マスター CA が CRL を生成するように設定します。
- CA サービスを停止します。
[root@server ~]# service pki-cad stop
- CA 設定ファイルを開きます。
[root@server ~]# vim /var/lib/pki-ca/conf/CS.cfg
ca.crl.MasterCRL.enableCRLCache
およびca.crl.MasterCRL.enableCRLUpdates
パラメーターの値を true に変更して、CRL 生成を有効にします。ca.crl.MasterCRL.enableCRLCache=true ca.crl.MasterCRL.enableCRLUpdates=true
- CA サービスを起動します。
[root@server ~]# service pki-cad start
- Apache を設定してリダイレクト CRL 要求を無効にします。クローンとして、すべての CRL 要求は元のマスターにルーティングされました。新規マスターとして、このインスタンスは CRL リクエストに応答します。
- CA プロキシー設定を開きます。
[root@server ~]# vim /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] - Apache を再起動します。
[root@server ~]# service httpd restart
28.2.5. OCSP 応答の設定
http://ipaserver.example.com:9180/ca/ocsp
28.2.5.1. SELinux での OSCP レスポンダーの使用
- SELinux ポリシーを編集して、mod_revocator モジュールを使用して Apache サーバーをポート 9180 に接続できるようにします。
semodule -i revoker.pp
- mod_revocator 接続の SELinux エラーログに基づいてアクセスを許可する新しい SELinux ポリシーを生成します。
audit2allow -a -M revoker
28.2.5.2. CRL 更新間隔の変更
- 認証局サーバーを停止します。
[root@server ~]# service pki-ca stop
CS.cfg
ファイルを開きます。[root@server ~]# vim /var/lib/pki-ca/conf/CS.cfg
ca.crl.MasterCRL.autoUpdateInterval
を新しい間隔設定に変更します。- CA サーバーを再起動します。
[root@server ~]# service pki-ca start
28.2.5.3. OCSP レスポンダーの場所の変更
- 証明書プロファイルを開きます。
[root@server ~]# vim /var/lib/pki-ca/profiles/ca/caIPAserviceCert.cfg
policyset.serverCertSet.9.default.params.crlDistPointsPointName_0
パラメーターを DNS CNAME ホスト名に変更します。- CA サーバーを再起動します。
service pki-ca restart
crlDistPointsPointName_0
パラメーターが同じホスト名に設定されます。
28.3. 匿名バインドの無効化
nsslapd-allow-anonymous-access
属性をリセットすることで、389 Directory Server インスタンスで匿名バインドを無効にすることができます。
nsslapd-allow-anonymous-access
属性を rootdse に変更します。ldapmodify -x -D "cn=Directory Manager" -w secret -h server.example.com -p 389 Enter LDAP Password: dn: cn=config changetype: modify replace: nsslapd-allow-anonymous-access nsslapd-allow-anonymous-access: rootdse
重要Anonymous アクセスは完全に許可したり (on) ブロックしたり (off) することができます。ただし、匿名アクセスを完全にブロックすると外部クライアントがサーバー設定をチェックすることもできなくなります。LDAP および web クライアントはドメインクライアントに限られるわけではないため、こうしたクライアントは匿名で接続を行ってルートの DSE ファイルを読み取り接続情報を取得します。rootdse では、ディレクトリーデータへのアクセスなしで、ルート DSE およびサーバー設定へのアクセスを許可します。- 389 Directory Server インスタンスを再起動して、新しい設定を読み込みます。
service dirsrv restart
28.4. ドメイン DNS 設定の変更
28.4.1. マルチキューサーバーの DNS エントリーの設定
ipaserver IN A 192.168.1.100 ipaserver IN A 192.168.1.101 ipaserver IN A 192.168.1.102
28.4.2. ネームサーバーの追加設定
/etc/resolv.conf
で設定済みのネームサーバーの一覧には、ldM サーバーのみが含まれます。ローカル named サービスがクラッシュした場合、IdM サーバーは実行できず、ドメイン全体の DNS サービスが利用できなくなりました。
/etc/resolv.conf
ファイルに手動で追加する必要があります。
[root@server ~]# vim /etc/resolv.conf search example.com ; the IdM server nameserver 127.0.0.1 ; backup DNS servers nameserver 198.51.100.0 nameserver 192.0.2.0
/etc/resolv.conf
ファイルには、3 つのサーバーのデフォルト制限が設定されています。
/etc/resolv.conf
ファイルの設定に関するその他の情報は resolv.conf
man ページにあります。
28.4.3. IdM サーバーおよびレプリカの負荷分散の変更
$ ipa dnsrecord-add server.example.com _ldap._tcp --srv-rec="0 100 389 server1.example.com." $ ipa dnsrecord-add server.example.com _ldap._tcp --srv-rec="1 100 389 server2.example.com."
28.5. IdM サーバー間のレプリカ合意の管理
図28.1 サーバーとレプリカの合意
28.5.1. レプリカ合意の一覧表示
[root@server ~]# ipa-replica-manage list srv1.example.com srv2.example.com srv3.example.com srv4.example.com
[root@server ~]# ipa-replica-manage list srv1.example.com srv2.example.com srv3.example.com
28.5.2. レプリカ合意の作成と削除
ipa-replica-manage connect server1 server2
[root@server ~]# ipa-replica-manage connect srv2.example.com srv4.example.com
[root@server ~]# ipa-replica-manage connect --cacert=/etc/ipa/ca.crt srv2.example.com srv4.example.com
[root@server ~]# ipa-replica-manage disconnect srv2.example.com srv4.example.com
[root@server ~]# ipa-replica-manage del srv2.example.com
28.5.3. レプリケーションの強制
--from
オプションで指定されます。
[root@server ~]# ipa-replica-manage force-sync --from srv1.example.com
28.5.4. IdM サーバーの初期化
--from
オプションで指定します。
[root@server ~]# ipa-replica-manage re-initialize --from srv1.example.com
28.5.5. レプリケーションの競合の解決
nsds5ReplConflict
属性が割り当てられます。これにより、競合のあるエントリーの検索が容易になります。
ldapsearch -x -D "cn=directory manager" -w password -b "dc=example,dc=com" "nsds5ReplConflict=*" \* nsds5ReplConflict
28.5.5.1. ネーミングの競合の解決
nsuniqueid
属性を命名属性として使用するよう変更されます。以下に例を示します。
nsuniqueid=0a950601-435311e0-86a2f5bd-3cd26022+uid=jsmith,cn=users,cn=accounts,dc=example,dc=com
- 別の naming 属性を使用してエントリーの名前を変更し、古い RDN を維持します。以下に例を示します。
ldapmodify -x -D "cn=directory manager" -w secret -h ipaserver.example.com -p 389 dn: nsuniqueid=66446001-1dd211b2+uid=jsmith,cn=users,cn=accounts,dc=example,dc=com changetype: modrdn newrdn: cn=TempValue deleteoldrdn: 0
- naming 属性の古い RDN 値と競合マーカー属性を削除します。以下に例を示します。
ldapmodify -x -D "cn=directory manager" -w secret -h ipaserver.example.com -p 389 dn: cn=TempValue,cn=users,cn=accounts,dc=example,dc=com changetype: modify delete: uid uid: jsmith - delete: nsds5ReplConflict -
注記一意の識別子属性nsuniqueid
は削除できません。 - エントリーの名前を目的の属性と値のペアに変更します。たとえば、以下のようになります。
ldapmodify -x -D "cn=directory manager" -w secret -h ipaserver.example.com -p 389 dn: cn=TempValue,dc=example,dc=com changetype: modrdn newrdn: uid=jsmith deleteoldrdn: 1
deleteoldrdn
属性の値を 1 に設定して、一時属性と値のペア cn=TempValue を削除します。この属性を保持するには、deleteoldrdn
属性の値を 0 に設定します。
28.5.5.2. 孤立エントリーの競合の解決
- 競合解決手続で、一致する一意の識別子を持つ削除されたエントリーが見つかった場合、glue エントリーは、そのエントリーの再生であり、glue のオブジェクトクラスと
nsds5ReplConflict
の属性が追加されます。このような場合は、glue エントリーを変更して glue オブジェクトクラスとnsds5ReplConflict
属性を削除して、エントリーを通常のエントリーとして維持するか、その子エントリーを削除します。 - サーバーは glue および extensibleObject オブジェクトクラスを使用して最小のエントリーを作成します。
28.6. レプリカの削除
- IdM サーバーで、IdM ツールを実行する前に Kerberos チケットを取得します。
[root@replica ~]# kinit admin
- IdM ドメインに設定されたレプリカ合意の一覧を表示します。
[root@replica ~]# ipa-replica-manage list Directory Manager password: ipaserver.example.com: master ipaserver2.example.com: master replica.example.com: master replica2.example.com: master
- トポロジーからレプリカを削除するには、レプリカと IdM ドメイン内の他のサーバーとの間のすべての合意と、ドメイン設定のレプリカに関するすべてのデータを削除する必要があります。
[root@replica ~]# ipa-replica-manage del replica.example.com
- レプリカが独自の CA で設定されている場合 は、ipa-csreplica-manage コマンドを使用して、レプリカの証明書データベース間のレプリカ合意をすべて削除します。これは、レプリカ自体が Dogtag Certificate System CA で設定されている場合に必要です。マスターサーバーまたは他のレプリカのみが CA で設定されていた場合は必要ありません。
[root@replica ~]# ipa-csreplica-manage del replica.example.com
- レプリカで、レプリカパッケージをアンインストールします。
[root@replica ~]# ipa-server-install --uninstall -U
28.7. サーバーまたはレプリカホストシステムの名前変更
- 新しいホスト名または IP アドレスを使用して、CA を使用して新規レプリカを作成します。この操作は、「4章IdM レプリカの設定」に説明があります。
- 元の IdM サーバーインスタンスを停止します。
[root@oldserver ~]# ipactl stop
- 他のサーバー/レプリケーションおよびクライアントがすべて以前と同じように機能していることを確認します。
- 「7章IdM サーバーおよびレプリカのアンインストール」に従って、IdM サーバーをアンインストールします。
第29章 LDAP ディレクトリーから IdM への移行
29.1. LDAP から IdM への移行の概要
29.1.1. クライアント設定のプランニング
29.1.1.1. クライアント初期設定 (移行前)
図29.1 基本的な LDAP ディレクトリーとクライアント設定
/etc/passwd
または /etc/shadow
にデーが格納されているかのように LDAP ディレクトリーからユーザー情報を取得できます。(現実的には ID 検索に LDAP、認証に Kerberos や別の設定を使用している場合などインフラストラクチャーはもう少し複雑になる場合があります。)
29.1.1.2. Red Hat Enterprise Linux クライアントの推奨設定
pam_sss
および nss_ss
) を使用して、SSSD を Identity Management と密接に統合し、Identity Management の完全な認証およびアイデンティティー機能を利用できます。このライブラリーによって SSSD と ∏ の緊密な統合が行われ、∏ の認証機能および ID 機能をフル活用することができるようになります。中央サーバーとの接続が失われた場合でもユーザーがログインできるよう ID 情報をキャッシングできる機能など、SSSD には便利な機能が多数搭載されています。こうした便利な機能については 『Red Hat Enterprise Linux Deployment Guide』 で詳しく説明しています。
pam_ldap
と nss_ldap
を使用する) とは異なり、SSSD は ドメイン 定義によって ID 情報と認証情報間の関係を確立します。SSSD のドメインは認証、ID 検索、アクセス、パスワード変更の 4 つのバックエンド機能を定義します。この SSSD ドメインを 4 つの機能のうちの 1 つの機能 (またはすべて) の情報を提供する プロバイダー を使用するよう設定します。ID プロバイダーはドメイン設定に必ず必要になります。他の 3 つのプロバイダーはオプションです。認証、アクセス、またはパスワードプロバイダーが定義されていない場合は ID プロバイダーがその機能に使用されます。
図29.2 IdM バックエンドのあるクライアントおよび SSSD
29.1.1.3. 推奨設定以外で対応している設定
nss_ldap
を使用) 。また IdM への接続は通常の Kerberos KDC への接続のように設定を行います (pam_krb5
を使用)。
図29.3 LDAP および Kerberos を使用するクライアントおよび IdM
nss_ldap
および pam_krb5
を使用して IdM サーバーに接続するように設定できます。共通する構成要素が最低限となるようなメンテナンス環境や IT インフラストラクチャーなどの場合には LDAP を ID と認証の両方に使用する必要があるかもしれません (nss_ldap
と pam_ldap
)。ただし、通常、クライアントに可能な最も安全な設定 (SSSD、Kerberos、LDAP、および Kerberos) を使用することが推奨されます。
29.1.2. パスワード移行のプランニング
29.1.2.1. 方法 1: 一時的なパスワードの使用とパスワード変更の強制
29.1.2.2. 方法 2: 移行用 Web ページの使用
https://ipaserver.example.com/ipa/migration
29.1.2.3. 方法 3: SSSD の使用 (推奨)
- ユーザーが SSSD でマシンにログインします。
- SSSD は、IdM サーバーに対して Kerberos 認証の実行を試みます。
- ユーザーがシステムに存在していも Kerberos ハッシュがないため key type is not supported エラーで認証に失敗します。
- SSSD は、セキュアな接続でプレーンテキストの LDAP バインドを実行します。
- IdM はこのバインド要求をインターセプトします。ユーザーが Kerberos プリンシパルは持っているのに Kerberos ハッシュを持っていない場合、IdM ID プロバイダーはハッシュを生成してユーザーのエンティティーに格納します。
- 認証に成功すると SSSD は IdM との接続を切断し Kerberos 認証を再試行します。この場合、エンティティーにハッシュが存在しているため要求は成功します。
29.1.2.4. クリアテキスト LDAP パスワードの移行
29.1.2.5. 要件を満たしていないパスワードの自動リセット
[jsmith@server ~]$ kinit Password for jsmith@EXAMPLE.COM: Password expired. You must change it now. Enter new password: Enter it again:
29.1.3. 移行における考慮事項と要件
29.1.3.1. 移行に対応している LDAP サーバー
- SunONE Directory Server
- Apache Directory Server
- OpenLDAP
29.1.3.2. 移行環境に関する要件
- 1 つの LDAP ディレクトリードメインが、1 つの IdM レルムに移行中です。統合はありません。
- ユーザーパスワードは、IdM Directory Server がサポートする LDAP ディレクトリーのハッシュとして保存されます。
- LDAP ディレクトリーインスタンスは ID 格納および認証方法の両方になります。クライアントマシンは、pam_ldap または nss_ldap を使用して LDAP サーバーに接続するように設定されます。
- エントリーは標準の LDAP スキーマのみを使用します。カスタム属性は Identity Management に移行されません。
29.1.3.3. 移行ツール
29.1.3.4. 移行順序
- 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 つのサービス間でユーザーデータの整合性が失われる危険を招くことになります。
29.2. migrate-ds を使用する例
ipa migrate-ds ldap://ldap.example.com:389
29.2.1. 特定のサブツリーの移行
--user-container
--group-container
[root@ipaserver ~]# ipa migrate-ds --user-container=ou=employees --group-container="ou=employee groups" ldap://ldap.example.com:389
--base-dn
このオプションを使用すると、コンテナーのサブツリーのターゲットを変更することができます。たとえば、以下のようになります。
[root@ipaserver ~]# ipa migrate-ds --user-container=ou=employees --base-dn="ou=people,dc=example,dc=com" ldap://ldap.example.com:389
29.2.2. 特定のエントリーのみを包含または除外
[root@ipaserver ~]# ipa migrate-ds --user-objectclass=fullTimeEmployee ldap://ldap.example.com:389
[root@ipaserver ~]# ipa migrate-ds --group-objectclass=groupOfNames,groupOfUniqueNames ldap://ldap.example.com:389
[root@ipaserver ~]# ipa migrate-ds --exclude-groups="Golfers Group" --exclude-users=jsmith,bjensen ldap://ldap.example.com:389
[root@ipaserver ~]# ipa migrate-ds --user-objectclass=fullTimeEmployee --exclude-users=jsmith,bjensen,mreynolds ldap://ldap.example.com:389
29.2.3. エントリー属性の除外
userCertificate
属性を移行する必要はありません。
--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
29.2.4. 使用するスキーマの設定
[root@ipaserver ~]# ipa migrate-ds --schema=RFC2307 ldap://ldap.example.com:389
29.3. シナリオ 1: 移行の一部として SSSD を使用する
- SSSD を設定します。SSSD を使用すると、必要な Kerberos 鍵とサーバー証明書をクライアントに配信できます。
- すべてのクライアントマシンに SSSD をインストールします。
# yum install sssd
- SSSD で LDAP アイデンティティープロバイダーを、すべての機能 (認証、ID ルックアップ、アクセス、およびパスワードの変更) に既存の Directory Server を使用するように設定します。これにより、すべてのクライアントが既存のディレクトリーサービスで適切に動作するようになります。
- カスタム LDAP ディレクトリースキーマを含む Identity Management のインストール[11]既存の LDAP ディレクトリーとは異なるマシン上にある。
- IdM サーバーが移行を許可できるようにします。
# ipa config-mod --enable-migration=TRUE
- compat プラグインを無効にします。
# ipa-compat-manage disable
- IdM Directory Server インスタンスを再起動します。
# service dirsrv restart
- IdM 移行スクリプト ipa migrate-ds を実行します。最も基本的な移行の場合、ここで必要となるのは LDAP ディレクトリーインスタンスの LDAP URL のみです。
# ipa migrate-ds ldap://ldap.example.com:389
LDAP URL を渡すだけで共通のデフォルト設定を使用するディレクトリーデータはすべて移行されます。ユーザーやグループのデータは 「migrate-ds を使用する例」 で説明しているように他のオプションを指定することで選択的に移行することが可能です。情報のエクスポートが完了すると、このスクリプトにより、必要とされる IdM オブジェクトクラスおよび属性がすべて追加され、IdM ディレクトリーツリーと一致するよう DN は属性に変換されます。 - compat プラグインを再度有効にします。
# ipa-compat-manage enable
- IdM Directory Server インスタンスを再起動します。
# service dirsrv restart
- SSSD が LDAP バックエンドから Identity Management バックエンドにインストールされたクライアントを移行し、クライアントとして IdM として登録します。これにより必要なキーと証明書がダウンロードされます。Red Hat Enterprise Linux クライアントでは、この ipa-client-install コマンドを使用して実行できます。たとえば、以下のようになります。
# ipa-client-install --enable-dns-updates
- ユーザーが SSSD バックエンドおよび Identity Management バックエンドを使用してマシンにログインしている。これにより、ユーザーに必要な Kerberos キーが生成されます。ユーザーの移行プロセスを監視するには、パスワードは持っているが Kerberos プリンシパルキーはまだないユーザーアカウントを表示するよう既存の LDAP ディレクトリーに問い合わせます。
$ ldapsearch -LL -x -D 'cn=Directory Manager' -w secret -b 'ou=people,dc=example,dc=com' '(&(!(krbprincipalkey=*))(userpassword=*))' uid
注記フィルターの前後に引用符を付けてシェルで解釈されないようにします。 - ユーザーが移行したら、必要に応じて SSSD 以外のクライアントが IdM ドメインを使用するように設定します。
- クライアントとユーザーすべての移行が完了したら LDAP ディレクトリーを廃止します。
29.4. シナリオ 2: LDAP サーバーを直接 Identity Management に移行する
- カスタム LDAP ディレクトリースキーマを含む IdM サーバーのインストール[12]既存の LDAP ディレクトリーとは異なるマシン上にある。
- compat プラグインを無効にします。
# ipa-compat-manage disable
- IdM Directory Server インスタンスを再起動します。
# service dirsrv restart
- IdM サーバーが移行を許可できるようにします。
# ipa config-mod --enable-migration=TRUE
- IdM 移行スクリプト ipa migrate-ds を実行します。最も基本的な移行の場合、ここで必要となるのは LDAP ディレクトリーインスタンスの LDAP URL のみです。
# ipa migrate-ds ldap://ldap.example.com:389
LDAP URL を渡すだけで共通のデフォルト設定を使用するディレクトリーデータはすべて移行されます。ユーザーやグループのデータは 「migrate-ds を使用する例」 で説明しているように他のオプションを指定することで選択的に移行することが可能です。情報のエクスポートが完了すると、このスクリプトにより、必要とされる IdM オブジェクトクラスおよび属性がすべて追加され、IdM ディレクトリーツリーと一致するよう DN は属性に変換されます。 - compat プラグインを再度有効にします。
# ipa-compat-manage enable
- IdM Directory Server インスタンスを再起動します。
# service dirsrv restart
- LDAP ディレクトリー、NIS、またはローカルファイルに接続する代わりに、PAM_LDAP および NSS_LDAP を使用して IdM に接続するようにクライアント設定を更新します。
- 任意。SSSD を設定します。SSSD を使用すると、「パスワード移行のプランニング」で説明されているように、ユーザーとの対話なしでユーザーパスワードが移行されます。
- すべてのクライアントマシンに SSSD をインストールします。
# yum install sssd
- 以下のコマンド ipa-client-install を実行して、ID および Kerberos 認証に IdM サーバーを使用するように、SSSD および関連サービスを設定します。
- SSSD がクライアントで利用できない場合は、SSSD クライアントまたは移行 Web ページを使用して IdM にログインするように指示します。どちらの方法でも、ユーザーパスワードが Identity Management に自動的に移行されます。
https://ipaserver.example.com/ipa/migration
- 任意。SSSD ではないクライアントが LDAP 認証 (
pam_ldap
) ではなく Kerberos 認証 (pam_krb5
) を使用するよう再設定します。注記全ユーザーが移行されるまで PAM_LDAP モジュールを使用し、次に PAM_KRB5 をしようできるようになります。 - クライアントとユーザーすべての移行が完了したら LDAP ディレクトリーを廃止します。
付録A Identity Management のトラブルシューティング
A.1. インストールの問題
A.1.1. サーバーのインストール
/var/log/ipaserver-install.log
に存在します。サーバー用の IdM ログと、IdM 関連のサービスの両方が「IdM サーバーログの確認」で説明されています。
A.1.1.1. IPA コマンドの実行時に GSS 障害
ipa: ERROR: Kerberos error: ('Unspecified GSS failure. Minor code may provide more information', 851968)/('Decrypt integrity check failed', -1765328353)
- DNS が正しく設定されていません。
- Active Directory は、IdM サーバーと同じドメインにあります。
A.1.1.2. named デーモンの起動失敗
named
サービスが起動できない場合は、パッケージの競合があることを示すことができます。named サービスおよび ldap.so
ライブラリーに関連するエラーメッセージが /var/log/messages
ファイルでないか確認します。
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
サービスが起動しないことを意味します。この問題を解決するには、bind-chroot パッケージを削除して、IdM サーバーを再起動します。
[root@server ~]# yum remove bind-chroot # ipactl restart
A.1.2. レプリカのインストール
A.1.2.1. 証明書システムのセットアップに失敗しました。
/var/log/pki-ca/debug
を確認して検証できます。これは、特定のエントリーが見つからないことを示すエラーメッセージを表示する可能性があります。たとえば、以下のようになります。
[04/Feb/2016:22:29:03][http-9445-Processor25]: DatabasePanel comparetAndWaitEntries ou=people,o=ipaca not found, let's wait
[root@ipareplica ~]# ipa-server-install --uninstall
A.1.2.2. レプリカの起動時に、389 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)) ...
/tmp/krb5cc_496
の認証情報キャッシュを探しており (496 は 389 Directory Server のユーザー ID)、これを見つけられません。
set_krb5_creds - Could not get initial credentials for principal [ldap/ replica1.example.com] in keytab [WRFILE:/etc/dirsrv/ds.keytab]: -1765328324 (Generic error)
A.1.2.3. DNS の正引きレコードが逆引きアドレスと一致しない問題
ipa: DEBUG: approved_usage = SSLServer intended_usage = SSLServer ipa: DEBUG: cert valid True for "CN=ipa-server2.example.com,O=EXAMPLE.COM" ipa: DEBUG: handshake complete, peer = 192.168.17.37: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 ipa-server2.example.com. does not match the reverse address ipa-server2.example.org
A.1.3. クライアントインストール
/var/log/ipaclient-install.log
にあります。サーバーおよびクライアントと IdM 関連のサービス両方の IdM ログは、「IdM サーバーログの確認」で説明されています。
A.1.3.1. クライアントは、外部 DNS を使用する際に逆引きホスト名を解決できません。
/etc/resolv.conf
ファイルに一覧表示されている場合や、Active Directory などの SRV レコードのあるネットワークに他のリソースがある場合に、逆引き参照に問題が発生することがあります。
Jun 30 11:11:48 server1 krb5kdc[1279](info): AS_REQ (4 etypes {18 17 16 23}) 192.168.60.135: 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.168.60.135: 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.168.60.135: UNKNOWN_SERVER: authtime 0, admin EXAMPLE COM for HTTP/server1.wrong.example.com@EXAMPLE.COM, Server not found in Kerberos database
/etc/resolv.conf
ファイルを編集し、外部 DNS ネームサーバーの参照を削除します。- 各 IdM サーバーに逆引き参照レコードを追加します。
- IdM クライアントまたはドメインにサブネットを付与し、そのサブネットのすべての要求を転送します。
A.1.3.2. クライアントは DNS ゾーンに追加されません。
[jsmith@ipaserver ~]$ kinit admin [jsmith@ipaserver ~]$ ipa dnsrecord-add ipaclient.example.com www --a-rec 1.2.3.4
A.1.4. IdM クライアントのアンインストール
--uninstall
オプションを使用します。
# ipa-client-install --uninstall
A.2. UI 接続の問題
- すべてのブラウザーウィンドウを閉じます。
- ターミナルで、Firefox の新しいログレベルを設定します。
export NSPR_LOG_MODULES=negotiateauth:5 export NSPR_LOG_FILE=/tmp/moz.log
これにより、詳細なロギングが可能になり、すべての情報が/tmp/moz.log
に記録されます。 - 同じターミナルウィンドウからブラウザーを再起動します。
エラーログメッセージ | 説明および修正 |
---|---|
-1208550944[90039d0]: entering nsNegotiateAuth::GetNextToken() -1208550944[90039d0]: gss_init_sec_context() failed: Miscellaneous failure No credentials cache found | Kerberos チケットはありません。kinit を実行します。 |
-1208994096[8d683d8]: entering nsAuthGSSAPI::GetNextToken() -1208994096[8d683d8]: gss_init_sec_context() failed: Miscellaneous failure Server not found in Kerberos database | Kerberos チケットを正常に取得しても、UI に対して認証できない場合に発生する可能性があります。これは、Kerberos 設定に問題があることを示しています。最初に確認する場所は、/etc/krb5.conf ファイルの [domain_realm] セクションです。IdM Kerberos ドメインエントリーが正しく、Firefox ネゴシエーションパラメーターの設定と一致していることを確認します。以下に例を示します。
.example.com = EXAMPLE.COM example.com = EXAMPLE.COM |
ログファイルには含まれません。 | 認証のネゴシエートに必要な HTTP ヘッダーを削除するプロキシーの背後にある可能性があります。代わりに HTTPS を使用してサーバーに接続し、要求を変更せずに渡すことを可能にします。次に、ログファイルを再度確認します。 |
A.3. IdM サーバーの問題
A.3.1. レプリカの起動時に、389 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)) ...
/tmp/krb5cc_496
の認証情報キャッシュを探しており (496 は 389 Directory Server のユーザー ID)、これを見つけられません。
set_krb5_creds - Could not get initial credentials for principal [ldap/ replica1.example.com] in keytab [WRFILE:/etc/dirsrv/ds.keytab]: -1765328324 (Generic error)
A.4. ホストの問題
A.4.1. 証明書が検出されない/識別番号が検出されないエラー
Certificate operation cannot be completed: EXCEPTION (Certificate serial number 0x2d not found)
A.4.2. クライアント接続の問題のデバッグ
/var/log/sssd/
で SSSD ログを確認します。sssd_example.com.log
など、DNS ドメインには、以下のような特定のログファイルがあります。デフォルトのロギングレベルでログに十分な情報がない場合には、ログレベルを増やします。
sssd.conf
ファイルを開きます。vim /etc/sssd/sssd.conf
- [domain/example.com] セクションで、
debug_level
を設定します。debug_level = 9
sssd
デーモンを再起動します。service sssd restart
- デバッグメッセージの
/var/log/sssd/sssd_example.com.log
ファイルを確認します。
A.5. Kerberos エラー
- kinit の問題またはその他の Kerberos サーバーの問題は、
/var/log/krb5kdc.log
の KDC ログインを参照してください。 - IdM 固有のエラーは、
/var/log/httpd/error_log
を参照してください。
A.5.1. GSS-API の使用時に SSH で接続する場合の問題
GSSAPITrustDNS
ディレクティブを追加または編集し、値を no に設定します。
# vim /etc/ssh/ssh_config GSSAPITrustDNS no
A.5.2. キータブの変更後に NFS サーバーへの接続に問題があります。
A.6. SELinux ログインの問題
/etc/selinux/
policy_name/logins/
login にそのユーザーのファイルを作成します。
pam_selinux
モジュールが正しく設定されないことがあります。これは、SELinux 情報を読み取り、ユーザーコンテキストを設定するモジュールです。モジュールがないと、SELinux マップが処理されず、ユーザーはシステムのデフォルトコンテキストを定義します。
付録B certmonger を使った作業
certmonger
デーモンとそのコマンドラインクライアントを使用すると、公開鍵と秘密鍵のペア生成や証明書リクエストの作成、CA に対する署名のリクエスト提出といった処理を簡素化することができます。証明書の管理の一環として、certmonger
デーモンは証明書の有効期限を監視し、期限が切れそうになった証明書を更新することができます。certmonger
が監視する証明書はファイルで追跡しており、このファイルは設定可能なディレクトリー内に保存します。デフォルトの場所は /var/lib/certmonger/requests
です。
B.1. certmonger で証明書の要求
.pem
) または NSS データベース (証明書のニックネームで識別される) でローカルに保存されます。証明書をリクエストする際には、リクエストで証明書の保存場所とニックネームを特定します。たとえば、以下のようになります。
# ipa-getcert request -d /etc/pki/nssdb -n Server-Cert
/etc/pki/nssdb
ファイルはグローバル NSS データベースで、Server-Cert
はこの証明書のニックネームです。証明書のニックネームはこのデータベース内で一意のものである必要があります。
-K
オプションが必要になります。そうでない場合、certmonger は証明書がホスト用であると仮定します。この -N
オプションは、証明書サブジェクト DN を指定し、サブジェクトベース DN が IdM サーバーのベース DN と一致するか、要求が拒否される必要があります。
$ ipa-getcert request -d /etc/httpd/alias -n Server-Cert -K HTTP/client1.example.com -N 'CN=client1.example.com,O=EXAMPLE.COM'
例B.1 サービスにおける certmonger の使用
$ ipa-getcert request -r -f /etc/httpd/conf/ssl.crt/server.crt -k /etc/httpd/conf/ssl.key/server.key -N CN=`hostname --fqdn` -D `hostname` -U id-kp-serverAuth
- この
-r
オプションは、鍵ペアがすでに存在する場合に証明書を自動的に更新します。これは、デフォルトで使用されます。 -f
オプションは、指定したファイルに証明書を保存します。-k
は、鍵を特定ファイルに保存するか、鍵のファイルが存在する場合は、ファイル内の鍵を使用します。-N
オプションはサブジェクト名を指定します。- この
-D
オプションは、DNS ドメイン名を指定します。 - この
-U
オプションは、拡張キー使用フラグを設定します。
B.2. NSS データベースでの証明書の保存
-d
オプションを使用してセキュリティーデータベースの場所と -n
を設定し、データベースの証明書に使用される証明書のニックネームを指定します。これらのオプションは -f
および -k
オプションで指定される PEM ファイルの代わりに使用されます。
# ipa-getcert request -d /export/alias -n ServerCert
...
B.3. certmonger を使った証明書の追跡
-I
オプションは、NSS データベース (-d
および -n
) または PEM ファイル (-f
および -k
) 内のいずれかでキーおよび証明書ファイルへのポインターと共に追跡エントリーを作成します。この -r
オプションは、証明書の更新を certmonger に指示します。
# ipa-getcert start-tracking -I cert1-tracker -d /export/alias -n ServerCert -r
-r
オプションは、例B.1「サービスにおける certmonger の使用」において、request コマンドで渡すことができます。この場合、要求された証明書は certmonger によって自動的に追跡および更新されます。その後、手動で追跡を設定する必要はありません。
索引
シンボル
- アンインストール
- クライアント, IdM クライアントのアンインストール
- クライアント
- アンインストール, IdM クライアントのアンインストール
- トラブルシューティング
- インストール, クライアントインストール
- クライアントのインストール
- OpenSSH の無効化, ipa-client-install および OpenSSH
- サーバー
- レプリケーションの数, IdM サーバーおよびレプリカの概要
- スキーマ
- Identity Management と Active Directory の相違点, Identity Management と Active Directory との間のユーザースキーマの相違点
- cn, cn 属性の値
- initials, initials 属性の制約
- sn, surname (sn) 属性の要求
- street および streetAddress, street および streetAddress の値
- ゾーンレコード, DNS ゾーンへのレコードの追加
- IPv4 の例, DNS リソースレコードの追加例
- IPv6 の例, DNS リソースレコードの追加例
- PTR の例, DNS リソースレコードの追加例
- SRV の例, DNS リソースレコードの追加例
- タイプ, DNS ゾーンへのレコードの追加
- 削除, DNS ゾーンからレコードを削除する
- 追加する形式, DNS レコードを追加するコマンドについて
- チケットポリシー, Kerberos チケットポリシーの設定
- トラブルシューティング
- Kerberos、不明なサーバーエラー, クライアントは、外部 DNS を使用する際に逆引きホスト名を解決できません。
- SELinux, SELinux ログインの問題
- クライアントのインストール, クライアントインストール
- クライアントのホスト名の解決, クライアントは、外部 DNS を使用する際に逆引きホスト名を解決できません。
- パスワードの有効期限, パスワード有効期限の制限の管理
- パスワードポリシー
- 有効期限, パスワード有効期限の制限の管理
- プロキシーサーバー
- UI の場合, プロキシーサーバーでの UI の使用
- ポリシー
- ログローテーション, IdM ドメインサービスとログローテーション
- ポート転送
- UI の場合, プロキシーサーバーでの UI の使用
- ユーザー
- パスワードの有効期限, パスワード有効期限の制限の管理
- 個別の認証情報キャッシュ, ユーザーの Kerberos チケットのキャッシュ
- 多値属性, コマンドラインでの操作
- レプリカ
- レプリケーションの数, IdM サーバーおよびレプリカの概要
- レプリケーション
- サイズ制限, IdM サーバーおよびレプリカの概要
- ログイン
- SELinux の問題, SELinux ログインの問題
- 個別の認証情報キャッシュ, ユーザーの Kerberos チケットのキャッシュ
- ログローテーション
- ポリシー, IdM ドメインサービスとログローテーション
- 命名の競合
- レプリケーション, ネーミングの競合の解決
- 属性
- 多値属性の設定, コマンドラインでの操作
- 証明書
A
- Active Directory
- Identity Management のスキーマの相違点, Identity Management と Active Directory との間のユーザースキーマの相違点
B
- bind
- DNS および LDAP, IdM の DNS について
C
- chkconfig, IdM ドメインの起動と停止
- chkconfig での起動, IdM ドメインの起動と停止
D
- DHCP, コマンドラインでのホストエントリーの追加
- DHCP を使用した
- DNS ホスト, コマンドラインでのホストエントリーの追加
- ホストの
- 無効化, ホストエントリーの無効化および再有効化
- DNS
- bind-dyndb-ldap および Directory Server, IdM の DNS について
- PTR 同期
- ゾーンの無効化, ゾーンの有効化と無効化
- ゾーンの追加, 正引き DNS ゾーンの追加
- ゾーンレコードの追加, DNS ゾーンへのレコードの追加
- 動的更新, ダイナミック DNS 更新の有効化
- DNS ゾーンレコード, DNS ゾーンへのレコードの追加
- IPv4 の例, DNS リソースレコードの追加例
- IPv6 の例, DNS リソースレコードの追加例
- PTR の例, DNS リソースレコードの追加例
- SRV の例, DNS リソースレコードの追加例
- レコードの種類, DNS ゾーンへのレコードの追加
- 削除, DNS ゾーンからレコードを削除する
- 追加する形式, DNS レコードを追加するコマンドについて
K
- Kerberos, Kerberos について
- SSSD パスワードキャッシュ, Kerberos パスワードのキャッシュ
- チケットポリシー, Kerberos チケットポリシーの設定
- グローバル, グローバルチケットポリシーの設定
- ユーザーレベル, ユーザーレベルのチケットポリシーの設定
- 個別の認証情報キャッシュ, ユーザーの Kerberos チケットのキャッシュ
L
- Libree エントリー, 孤立エントリーの競合の解決
- logrotate, IdM ドメインサービスとログローテーション
P
- PTR 同期
R
- reboot, IdM ドメインの起動と停止
S
- SELinux
- ログインの問題, SELinux ログインの問題
- services
- 無効化, サービスエントリーの無効化および再有効化
- SSH
- クライアントのインストール時に無効化, ipa-client-install および OpenSSH
- SSSD
- Kerberos パスワード, Kerberos パスワードのキャッシュ
- キャッシュの無効化, Kerberos パスワードのキャッシュ
W
- Web UI
- プロキシーサーバー, プロキシーサーバーでの UI の使用
- ポート転送, プロキシーサーバーでの UI の使用
付録C 改訂履歴
改訂履歴 | |||
---|---|---|---|
改訂 6.7-4 | Mon Apr 10 2017 | ||
| |||
改訂 6.7-3 | Wed Mar 8 2017 | ||
| |||
改訂 6.7-2 | Wed May 4 2016 | ||
| |||
改訂 6.7-1 | Thu Feb 18 2016 | ||
| |||
改訂 6.7-0 | Tue Jul 14 2015 | ||
| |||
改訂 6.6-2 | Tue Mar 31 2015 | ||
| |||
改訂 6.6-1 | Fri Dec 19 2014 | ||
| |||
改訂 6.6-0 | Fri Oct 10 2014 | ||
| |||
改訂 6.5-5 | July 9, 2014 | ||
| |||
改訂 6.5-4 | February 3, 2014 | ||
| |||
改訂 6.5-1 | November 20, 2013 | ||
| |||
改訂 6.4-3 | August 20, 2013 | ||
| |||
改訂 6.4-1 | March 1, 2013 | ||
| |||
改訂 6.3-1 | October 18, 2012 | ||
| |||
改訂 6.2-8 | December 16, 2011 | ||
| |||
改訂 6.2-7 | December 6, 2011 | ||
|