34.8. 信頼の設定
本セクションでは、コマンドラインを使用して、IdM に Identity Management (IdM)/Active Directory (AD) 信頼を設定する方法を説明します。
前提条件
- DNS が正しく設定されている。IdM サーバーおよび AD サーバーはどちらも、相手の名前を解決できる。詳細は 信頼用の DNS およびレルム設定の設定 を参照してください。
- 対応しているバージョンの AD および IdM がデプロイされている。詳細は サポート対象の Windows Server バージョン を参照してください。
- Kerberos チケットを取得している。詳細は、Using kinit to log in to IdM manually を参照してください。
34.8.1. 信頼用の IdM サーバーの準備
AD との信頼を確立する前に、IdM サーバーで ipa-adtrust-install
ユーティリティーを使用して IdM ドメインを準備する必要があります。
ipa-adtrust-install
コマンドを自動的に実行するシステムは、AD 信頼コントローラーになります。ただし、ipa-adtrust-install
は、IdM サーバーで 1 回のみ実行する必要があります。
前提条件
- IdM サーバーがインストールされている。
- パッケージをインストールし、IdM サービスを再起動するには、root 権限が必要です。
手順
必要なパッケージをインストールします。
[root@ipaserver ~]# yum install ipa-server-trust-ad samba-client
IdM 管理ユーザーとして認証します。
[root@ipaserver ~]# kinit admin
ipa-adtrust-install
ユーティリティーを実行します。[root@ipaserver ~]# ipa-adtrust-install
統合 DNS サーバーとともに IdM がインストールされていると、DNS サービスレコードが自動的に作成されます。
IdM が統合 DNS サーバーなしで IdM をインストールすると、
ipa-adtrust-install
は、続行する前に DNS に手動で追加する必要があるサービスレコードのリストを出力します。スクリプトにより、
/etc/samba/smb.conf
がすでに存在し、書き換えられることが求められます。WARNING: The smb.conf already exists. Running ipa-adtrust-install will break your existing Samba configuration. Do you wish to continue? [no]:
yes
このスクリプトは、従来の Linux クライアントが信頼できるユーザーと連携できるようにする互換性プラグインである
slapi-nis
プラグインを設定するように求めるプロンプトを表示します。Do you want to enable support for trusted domains in Schema Compatibility plugin? This will allow clients older than SSSD 1.9 and non-Linux clients to work with trusted users. Enable trusted domains support in slapi-nis? [no]:
yes
プロンプトが表示されたら、IdM ドメインの NetBIOS 名を入力するか、Enter を押して提案された名前を使用します。
Trust is configured but no NetBIOS domain name found, setting it now. Enter the NetBIOS name for the IPA domain. Only up to 15 uppercase ASCII letters, digits and dashes are allowed. Example: EXAMPLE. NetBIOS domain name [IDM]:
SID 生成タスクを実行して、既存ユーザーに SID を作成するように求められます。
Do you want to run the ipa-sidgen task? [no]:
yes
これはリソースを集中的に使用するタスクであるため、ユーザー数が多い場合は別のタイミングで実行できます。
(必要に応じて)
デフォルトでは、Windows Server 2008 以降での動的 RPC ポートの範囲は 49152-65535 として定義されます。ご使用の環境に異なる動的 RPC ポート範囲を定義する必要がある場合は、Samba が異なるポートを使用するように設定し、ファイアウォール設定でそのポートを開くように設定します。以下の例では、ポート範囲を55000-65000
に設定します。[root@ipaserver ~]# net conf setparm global 'rpc server dynamic port range' 55000-65000 [root@ipaserver ~]# firewall-cmd --add-port=55000-65000/tcp [root@ipaserver ~]# firewall-cmd --runtime-to-permanent
信頼の DNS 設定の確認 に従って、DNS が適切に設定されていることを確認します。
重要Red Hat では、IdM または AD が統合 DNS サーバーを使用しない場合に、
ipa-adtrust-install
を実行してから 信頼に対する DNS 設定の確認 に従って DNS 設定を検証することが強く推奨されます。ipa
サービスを再起動します。[root@ipaserver ~]# ipactl restart
smbclient
ユーティリティーを使用して、Samba が IdM からの Kerberos 認証に応答することを確認します。[root@ipaserver ~]#
smbclient -L ipaserver.idm.example.com -U user_name --use-kerberos=required
lp_load_ex: changing to config backend registry Sharename Type Comment --------- ---- ------- IPC$ IPC IPC Service (Samba 4.15.2) ...
34.8.2. コマンドラインで信頼関係の設定
コマンドラインを使用して信頼関係を設定するには、次の手順に従います。Identity Management (IdM) サーバーには、3 種類の信頼関係を設定できます。
- 一方向の信頼 — デフォルトのオプション。一方向の信頼により、Active Directory (AD) ユーザーおよびグループは IdM のリソースにアクセスできますが、その逆はできません。IdM ドメインは AD フォレストを信頼しますが、AD フォレストは IdM ドメインを信頼しません。
双方向の信頼 — 双方向の信頼により、AD ユーザーおよびグループが IdM のリソースにアクセスできるようになります。
信頼境界を使用して Kerberos プロトコルに
S4U2Self
およびS4U2Proxy
の Microsoft 拡張を必要とする、Microsoft SQL Server などのソリューションに、双方向の信頼を設定する必要があります。RHEL IdM ホスト上にあるアプリケーションは、AD ユーザーに関するS4U2Self
またはS4U2Proxy
の情報を Active Directory ドメインコントローラーから要求する場合があり、双方向の信頼でこの機能が提供されます。この双方向の信頼機能では、IdM ユーザーは Windows システムにログインできないだけでなく、IdM の双方向信頼では、AD の一方向信頼ソリューションと比較して、権限が追加でユーザーに付与されるわけではありません。
-
双方向の信頼を作成するには、コマンドに
--two-way=true
オプションを追加します。
-
双方向の信頼を作成するには、コマンドに
外部信頼: 異なるフォレストの IdM と AD ドメインとの間の信頼関係です。フォレストの信頼では常に IdM と Active Directory フォレストのルートドメインとの間で信頼関係を確立する必要がありますが、IdM からフォレスト内の任意のドメインへの外部の信頼関係も確立できます。管理上または組織上の理由で、フォレストの root ドメイン間でフォレストの信頼を確立できない場合に限り、これが推奨されます。
-
外部の信頼を作成するには、コマンドに
--external=true
オプションを追加します。
-
外部の信頼を作成するには、コマンドに
以下の手順では、一方向の信頼関係を作成する方法を示します。
前提条件
- Windows 管理者のユーザー名およびパスワード
- 信頼用の IdM サーバーの準備ができている。
手順
ipa trust-add
コマンドを使用して、AD ドメインと IdM ドメインに信頼関係を作成します。SSSD が SID に基づいて AD ユーザーの UID および GID を自動的に生成できるようにするには、
Active Directory domain
ID 範囲タイプとの信頼関係を作成します。これが最も一般的な設定です。[root@server ~]# ipa trust-add --type=ad ad.example.com --admin <ad_admin_username> --password --range-type=ipa-ad-trust
Active Directory でユーザーに POSIX 属性を設定し (
uidNumber
、gidNumber
など)、SSSD でこの情報を処理する場合は、Active Directory domain with POSIX attributes
ID 範囲タイプとの信頼関係を作成します。[root@server ~]# ipa trust-add --type=ad ad.example.com --admin <ad_admin_username> --password --range-type=ipa-ad-trust-posix
信頼の作成時に ID 範囲タイプを指定しないと、IdM はフォレストルートドメインの AD ドメインコントローラーから詳細を要求することで、適切な範囲タイプを自動的に選択しようとします。IdM が POSIX 属性を検出しない場合、信頼インストールスクリプトは Active Directory domain
ID 範囲を選択します。
IdM がフォレストルートドメインの POSIX 属性を検出すると、信頼インストールスクリプトは、Active Directory domain with POSIX attributes
ID 範囲を選択し、UID および GID が AD に正しく定義されていることを前提とします。POSIX 属性が AD で正しく設定されていない場合は、AD ユーザーを解決できません。
たとえば、IdM システムへのアクセスを必要とするユーザーおよびグループがフォレストルートドメインの一部ではなく、フォレストドメインの子ドメインにある場合は、インストールスクリプトで、子 AD ドメインで定義された POSIX 属性が検出されない場合があります。この場合、Red Hat は、信頼の確立時に POSIX ID 範囲タイプを明示的に選択することを推奨します。
34.8.3. IdM Web UI で信頼関係の設定
IdM Web UI を使用して IdM 側で Identity Management (IdM)/Active Directory (AD) 信頼関係を設定するには、次の手順に従います。
前提条件
- DNS が正しく設定されている。IdM サーバーおよび AD サーバーはどちらも、相手の名前を解決できる。
- 対応しているバージョンの AD および IdM がデプロイされている。
- Kerberos チケットを取得している。
- Web UI で信頼を作成する前に、信頼用の IdM サーバーの準備 に従って、信頼用に IdM サーバーを準備している。
- IdM 管理者としてログインしている。
手順
- 管理者権限で IdM Web UI にログインします。詳細は Web ブラウザーで IdM Web UI へのアクセス を参照してください。
- IdM Web UI で、IPA Server タブをクリックします。
- IPA Server タブで、Trusts タブをクリックします。
ドロップダウンメニューで、Trusts オプションを選択します。
- Add ボタンをクリックします。
- Add Trust ダイアログボックスで、Active Directory ドメインの名前を入力します。
Account フィールドおよび Password フィールドに、Active Directory 管理者の管理者認証情報を追加します。
- (オプション) AD ユーザーおよびグループが IdM のリソースにアクセスできるようにする場合は、Two-way trust を選択します。ただし、IdM の双方向の信頼では、AD の一方向の信頼ソリューションと比較して、ユーザーに追加の権限が付与されません。デフォルトのフォレスト間信頼の SID フィルタリング設定により、両方のソリューションの安全性は同じであると見なされます。
- (オプション) AD フォレストのルートドメインではない AD ドメインで信頼を設定する場合は、External trust を選択します。フォレストの信頼では常に IdM と Active Directory フォレストのルートドメインとの間で信頼関係を確立する必要がありますが、IdM から AD フォレスト内の任意のドメインへの外部の信頼関係も確立できます。
(オプション) デフォルトでは、信頼インストールスクリプトは適切な ID 範囲タイプの検出を試みます。以下のオプションのいずれかを選択して、ID 範囲タイプを明示的に設定することもできます。
-
SSSD が SID に基づいて AD ユーザーの UID および GID を自動的に生成するには、
Active Directory domain
ID 範囲タイプを選択します。これが最も一般的な設定です。 Active Directory でユーザーに POSIX 属性を設定し (
uidNumber
、gidNumber
など)、SSSD がこの情報を処理する必要がある場合は、Active Directory domain with POSIX attributes
ID 範囲タイプを選択します。警告Range type 設定をデフォルトの
Detect
オプションに残すと、IdM はフォレストルートドメインの AD ドメインコントローラーから詳細を要求することで、適切な範囲タイプを自動的に選択しようとします。IdM が POSIX 属性を検出しない場合、信頼インストールスクリプトはActive Directory domain
ID 範囲を選択します。IdM がフォレストルートドメインの POSIX 属性を検出すると、信頼インストールスクリプトは、
Active Directory domain with POSIX attributes
ID 範囲を選択し、UID および GID が AD に正しく定義されていることを前提とします。POSIX 属性が AD で正しく設定されていない場合は、AD ユーザーを解決できません。たとえば、IdM システムへのアクセスを必要とするユーザーおよびグループがフォレストルートドメインの一部ではなく、フォレストドメインの子ドメインにある場合は、インストールスクリプトで、子 AD ドメインで定義された POSIX 属性が検出されない場合があります。この場合、Red Hat は、信頼の確立時に POSIX ID 範囲タイプを明示的に選択することを推奨します。
-
SSSD が SID に基づいて AD ユーザーの UID および GID を自動的に生成するには、
- Add をクリックします。
検証
信頼が IdM サーバーに正常に追加されると、IdM Web UI で緑色のポップアップ画面が表示されます。これは、以下を示しています。
- ドメイン名が存在する。
Windows Server のユーザー名およびパスワードが正しく追加されている。
これで、信頼接続と Kerberos 認証のテストを続行します。
34.8.4. Ansible を使用した信頼関係の設定
Ansible Playbook を使用して Identity Management (IdM) と Active Directory (AD) の間に一方向の信頼協定を設定するには、次の手順に従います。3 種類の信頼関係を設定できます。
- 一方向の信頼 — デフォルトのオプション。一方向の信頼により、Active Directory (AD) ユーザーおよびグループは IdM のリソースにアクセスできますが、その逆はできません。IdM ドメインは AD フォレストを信頼しますが、AD フォレストは IdM ドメインを信頼しません。
双方向の信頼 — 双方向の信頼により、AD ユーザーおよびグループが IdM のリソースにアクセスできるようになります。
信頼境界を使用して Kerberos プロトコルに
S4U2Self
およびS4U2Proxy
の Microsoft 拡張を必要とする、Microsoft SQL Server などのソリューションに、双方向の信頼を設定する必要があります。RHEL IdM ホスト上にあるアプリケーションは、AD ユーザーに関するS4U2Self
またはS4U2Proxy
の情報を Active Directory ドメインコントローラーから要求する場合があり、双方向の信頼でこの機能が提供されます。この双方向の信頼機能では、IdM ユーザーは Windows システムにログインできないだけでなく、IdM の双方向信頼では、AD の一方向信頼ソリューションと比較して、権限が追加でユーザーに付与されるわけではありません。
-
双方向の信頼を作成するには、
two_way: true
の変数を Playbook タスクに追加します。
-
双方向の信頼を作成するには、
外部信頼: 異なるフォレストの IdM と AD ドメインとの間の信頼関係です。フォレストの信頼では常に IdM と Active Directory フォレストのルートドメインとの間で信頼関係を確立する必要がありますが、IdM からフォレスト内の任意のドメインへの外部の信頼関係も確立できます。管理上または組織上の理由で、フォレストの root ドメイン間でフォレストの信頼を確立できない場合に限り、これが推奨されます。
-
外部信頼を作成するには、以下の変数を
external: true
の Playbook タスクに追加します。
-
外部信頼を作成するには、以下の変数を
前提条件
- Windows 管理者のユーザー名およびパスワード
-
IdM
admin
パスワード。 - 信頼用の IdM サーバーの準備ができている。
-
IdM 4.8.7 バージョン以降の IdM を使用している。サーバーにインストールされている IdM のバージョンを表示するには、
ipa --version
を実行します。 次の要件を満たすように Ansible コントロールノードを設定した。
- Ansible バージョン 2.14 以降を使用している。
-
Ansible コントローラーに
ansible-freeipa
パッケージがインストールされている。 - この例では、~/MyPlaybooks/ ディレクトリーに、IdM サーバーの完全修飾ドメイン名 (FQDN) を使用して Ansible インベントリーファイル を作成したことを前提としている。
-
この例では、secret.yml Ansible vault に
ipaadmin_password
が保存されていることを前提としています。
-
ターゲットノード (
ansible-freeipa
モジュールが実行されるノード) が、IdM クライアント、サーバー、またはレプリカとして IdM ドメインに含まれている。
手順
~/MyPlaybooks/ ディレクトリーに移動します。
$ cd ~/MyPlaybooks/
ユースケースに基づいて、以下のいずれかのシナリオを選択します。
SSSD が SID に基づいて AD ユーザーおよびグループの UID および GID を自動的に生成する ID マッピング信頼合意を作成するには、以下の内容で
add-trust.yml
Playbook を作成します。--- - name: Playbook to create a trust hosts: ipaserver vars_files: - /home/user_name/MyPlaybooks/secret.yml tasks: - name: ensure the trust is present ipatrust: ipaadmin_password: "{{ ipaadmin_password }}" realm: ad.example.com admin: Administrator password: secret_password range_type: ipa-ad-trust state: present
上記の例では、以下のようになります。
-
realm
は、AD レルム名文字列を定義します。 -
admin
は AD ドメイン管理者文字列を定義します。 -
Password
は、AD ドメイン管理者のパスワード文字列を定義します。
-
SSSD が AD に保存されている POSIX 属性 (
uidNumber
やgidNumber
など) を処理する POSIX 信頼合意を作成するには、以下の内容でadd-trust.yml
Playbook を作成します。--- - name: Playbook to create a trust hosts: ipaserver vars_files: - /home/user_name/MyPlaybooks/secret.yml tasks: - name: ensure the trust is present ipatrust: ipaadmin_password: "{{ ipaadmin_password }}" realm: ad.example.com admin: Administrator password: secret_password range_type: ipa-ad-trust-posix state: present
フォレストルートドメインの AD ドメインコントローラーからの詳細を要求して、IdM が適切な範囲タイプ
ipa-ad-trust
またはipa-ad-trust-posix
を選択しようとする信頼合意を作成するには、以下の内容を含むadd-trust.yml
Playbook を作成します。--- - name: Playbook to create a trust hosts: ipaserver vars_files: - /home/user_name/MyPlaybooks/secret.yml tasks: - name: ensure the trust is present ipatrust: ipaadmin_password: "{{ ipaadmin_password }}" realm: ad.example.com admin: Administrator password: secret_password state: present
警告信頼の作成時に ID 範囲タイプを指定せず、IdM が AD フォレストルートドメインの POSIX 属性を検出しない場合は、信頼インストールスクリプトで
Active Directory ドメイン
ID 範囲を選択します。IdM がフォレストルートドメインの POSIX 属性を検出すると、信頼インストールスクリプトは、
Active Directory domain with POSIX attributes
ID 範囲を選択し、UID および GID が AD に正しく定義されていることを前提とします。ただし、POSIX 属性が AD で正しく設定されていない場合は、AD ユーザーを解決できません。たとえば、IdM システムへのアクセスを必要とするユーザーおよびグループがフォレストルートドメインの一部ではなく、フォレストドメインの子ドメインにある場合は、インストールスクリプトで、子 AD ドメインで定義された POSIX 属性が検出されない場合があります。この場合、Red Hat は、信頼の確立時に POSIX ID 範囲タイプを明示的に選択することを推奨します。
- ファイルを保存します。
Ansible Playbook を実行します。Playbook ファイル、secret.yml ファイルを保護するパスワードを格納するファイル、およびインベントリーファイルを指定します。
$ ansible-playbook --vault-password-file=password_file -v -i inventory add-trust.yml
関連情報
- /usr/share/doc/ansible-freeipa/README-trust.md
- /usr/share/doc/ansible-freeipa/playbooks/trust
34.8.5. Kerberos 設定の確認
Kerberos 設定を確認するには、Identity Management (IdM) ユーザーのチケットを取得できるかどうか、および IdM ユーザーがサービスチケットを要求できるかどうかを検証します。
手順
Active Directory (AD) ユーザーのチケットを要求します。
[root@ipaserver ~]# kinit user@AD.EXAMPLE.COM
IdM ドメイン内のサービスのサービスチケットを要求します。
[root@server ~]# kvno -S host server.idm.example.com
AD サービスチケットが正常に許可されると、その他の要求されたすべてのチケットと共に記載されたレルム間の TGT (Ticket-Granting Ticket) があります。TGT の名前は、krbtgt/IPA.DOMAIN@AD.DOMAIN です。
[root@server ]# klist Ticket cache: KEYRING:persistent:0:krb_ccache_hRtox00 Default principal: user@AD.EXAMPLE.COM Valid starting Expires Service principal 03.05.2016 18:31:06 04.05.2016 04:31:01 host/server.idm.example.com@IDM.EXAMPLE.COM renew until 04.05.2016 18:31:00 03.05.2016 18:31:06 04.05.2016 04:31:01 krbtgt/IDM.EXAMPLE.COM@AD.EXAMPLE.COM renew until 04.05.2016 18:31:00 03.05.2016 18:31:01 04.05.2016 04:31:01 krbtgt/AD.EXAMPLE.COM@AD.EXAMPLE.COM renew until 04.05.2016 18:31:00
localauth
プラグインは、Kerberos プリンシパルをローカルの System Security Services Daemon (SSSD) ユーザー名にマッピングします。これにより、AD ユーザーは Kerberos 認証を使用し、GSSAPI 認証に対応する Linux サービスに直接アクセスできます。
34.8.6. IdM で信頼設定の確認
信頼を設定する前に、Identity Management (IdM) サーバーおよび Active Directory (AD) サーバーが自身を解決でき、相互に解決できることを確認します。
前提条件
- 管理者権限でログインしている。
手順
UDP サービスレコード上の MS DC Kerberos、および TCP サービスレコード上の LDAP に、DNS クエリーを実行します。
[root@server ~]# dig +short -t SRV _kerberos._udp.dc._msdcs.idm.example.com. 0 100 88 server.idm.example.com. [root@server ~]# dig +short -t SRV _ldap._tcp.dc._msdcs.idm.example.com. 0 100 389 server.idm.example.com.
以下のコマンドは、
ipa-adtrust-install
を実行した IdM サーバーをリスト表示します。ipa-adtrust-install
が IdM サーバーで実行していない場合、通常は最初の信頼関係を確立する前に出力が空になります。TCP サービスレコード上の Kerberos と LDAP で DNS クエリーを実行して、IdM が AD のサービスレコードを解決できることを確認します。
[root@server ~]# dig +short -t SRV _kerberos._tcp.dc._msdcs.ad.example.com. 0 100 88 addc1.ad.example.com. [root@ipaserver ~]# dig +short -t SRV _ldap._tcp.dc._msdcs.ad.example.com. 0 100 389 addc1.ad.example.com.
.
34.8.7. AD で信頼設定の確認
信頼の設定後に、以下を確認します。
- Identity Management (IdM) がホストするサービスが、Active Directory (AD) サーバーから解決できる。
- AD サービスは、AD サーバーで解決できる。
前提条件
- 管理者権限でログインしている。
手順
AD サーバーに、サービスレコードを検索する
nslookup.exe
ユーティリティーを設定します。C:\>nslookup.exe > set type=SRV
UDP サービスレコード上の Kerberos、および TCP サービスレコード上の LDAP に、ドメイン名を入力します。
> _kerberos._udp.idm.example.com. _kerberos._udp.idm.example.com. SRV service location: priority = 0 weight = 100 port = 88 svr hostname = server.idm.example.com > _ldap._tcp.idm.example.com _ldap._tcp.idm.example.com SRV service location: priority = 0 weight = 100 port = 389 svr hostname = server.idm.example.com
サービスの種類を TXT に変更し、IdM Kerberos レルム名で TXT レコードに DNS クエリーを実行します。
C:\>nslookup.exe > set type=TXT > _kerberos.idm.example.com. _kerberos.idm.example.com. text = "IDM.EXAMPLE.COM"
UDP サービスレコード上の MS DC Kerberos、および TCP サービスレコード上の LDAP に、DNS クエリーを実行します。
C:\>nslookup.exe > set type=SRV > _kerberos._udp.dc._msdcs.idm.example.com. _kerberos._udp.dc._msdcs.idm.example.com. SRV service location: priority = 0 weight = 100 port = 88 svr hostname = server.idm.example.com > _ldap._tcp.dc._msdcs.idm.example.com. _ldap._tcp.dc._msdcs.idm.example.com. SRV service location: priority = 0 weight = 100 port = 389 svr hostname = server.idm.example.com
Active Directory は、その他の AD ドメインコントローラーや IdM 信頼コントローラーなど、AD 固有のプロトコル要求に応答できるドメインコントローラーの検出のみを想定します。
ipa-adtrust-install
ツールを使用して、IdM サーバーを信頼コントローラーに昇格し、どのサーバーが信頼コントローラーであるかを確認するには、ipa server-role-find --role 'AD trust controller'
コマンドを使用します。AD サービスが AD サーバーで解決可能であることを検証します。
C:\>nslookup.exe > set type=SRV
UDP サービスレコード上の Kerberos、および TCP サービスレコード上の LDAP に、ドメイン名を入力します。
> _kerberos._udp.dc._msdcs.ad.example.com. _kerberos._udp.dc._msdcs.ad.example.com. SRV service location: priority = 0 weight = 100 port = 88 svr hostname = addc1.ad.example.com > _ldap._tcp.dc._msdcs.ad.example.com. _ldap._tcp.dc._msdcs.ad.example.com. SRV service location: priority = 0 weight = 100 port = 389 svr hostname = addc1.ad.example.com
34.8.8. 信頼エージェントの作成
信頼エージェントは、AD ドメインコントローラーに対して ID ルックアップを実行できる IdM サーバーです。
たとえば、Active Directory と信頼できる IdM サーバーのレプリカを作成する場合は、そのレプリカを信頼エージェントとして設定できます。レプリカには、AD 信頼エージェントロールが自動的にインストールされていません。
前提条件
- IdM は、Active Directory 信頼でインストールされます。
-
sssd-tools
パッケージがインストールされている。
手順
既存の信頼コントローラーで、
ipa-adtrust-install --add-agents
コマンドを実行します。[root@existing_trust_controller]# ipa-adtrust-install --add-agents
このコマンドは、対話型設定セッションを開始し、エージェントの設定に必要な情報の入力を求めます。
信頼エージェントで IdM サービスを再起動します。
[root@new_trust_agent]# ipactl restart
信頼エージェントの SSSD キャッシュからすべてのエントリーを削除します。
[root@new_trust_agent]# sssctl cache-remove
レプリカに AD 信頼エージェントロールがインストールされていることを確認します。
[root@existing_trust_controller]# ipa server-show new_replica.idm.example.com ... Enabled server roles: CA server, NTP server, AD trust agent
関連情報
-
--add-agents
オプションの詳細は、man ページのipa-adtrust-install(1)
を参照してください。 - 信頼エージェントの詳細は、Planning Identity Management の Trust controllers and trust agents を参照してください。
34.8.9. CLI での POSIX ID 範囲の自動プライベートグループマッピングの有効化
デフォルトでは、SSSD は、AD に保存されている POSIX データに依存する POSIX 信頼を確立している場合は、Active Directory(AD) ユーザーのプライベートグループをマッピングしません。AD ユーザーにプライマリーグループが設定されていない場合、IdM はこれを解決できません。
この手順では、コマンドラインで auto_private_groups
SSSD パラメーターに hybrid
オプションを設定して、ID 範囲の自動プライベートグループマッピングを有効にする方法を説明します。これにより、IdM は、AD にプライマリーグループが設定されていない AD ユーザーを解決できます。
前提条件
- IdM 環境と AD 環境との間で、POSIX フォレスト間の信頼が正常に確立されました。
手順
すべての ID 範囲を表示し、変更する AD ID 範囲を書き留めます。
[root@server ~]# ipa idrange-find ---------------- 2 ranges matched ---------------- Range name: IDM.EXAMPLE.COM_id_range First Posix ID of the range: 882200000 Number of IDs in the range: 200000 Range type: local domain range Range name: AD.EXAMPLE.COM_id_range First Posix ID of the range: 1337000000 Number of IDs in the range: 200000 Domain SID of the trusted domain: S-1-5-21-4123312420-990666102-3578675309 Range type: Active Directory trust range with POSIX attributes ---------------------------- Number of entries returned 2 ----------------------------
ipa idrange-mod
コマンドを使用して、AD ID 範囲の自動プライベートグループの動作を調整します。[root@server ~]# ipa idrange-mod --auto-private-groups=hybrid AD.EXAMPLE.COM_id_range
SSSD キャッシュをリセットして、新しい設定を有効にします。
[root@server ~]# sss_cache -E
34.8.10. IdM WebUI での POSIX ID 範囲の自動プライベートグループマッピングの有効化
デフォルトでは、SSSD は、AD に保存されている POSIX データに依存する POSIX 信頼を確立している場合は、Active Directory(AD) ユーザーのプライベートグループをマッピングしません。AD ユーザーにプライマリーグループが設定されていない場合、IdM はこれを解決できません。
この手順では、Identity Management(IdM)WebUI の auto_private_groups
SSSD パラメーター の hybrid
オプションを設定して、ID 範囲の自動プライベートグループマッピングを有効にする方法を説明します。これにより、IdM は、AD にプライマリーグループが設定されていない AD ユーザーを解決できます。
前提条件
- IdM 環境と AD 環境との間で、POSIX フォレスト間の信頼が正常に確立されました。
手順
- ユーザー名とパスワードを使用して IdM Web UI にログインします。
-
IPA Server
ID Ranges タブを開きます。 -
AD.EXAMPLE.COM_id_range
など、変更する ID 範囲を選択します。 Auto private groups ドロップダウンメニューから、
hybrid
オプションを選択します。- Save ボタンをクリックして変更を保存します。