Show Table of Contents
5.2. フォレスト間の信頼作成
5.2.1. 環境およびマシン要件
信頼関係を設定する前に、Active Directory と Identity Management の両方のサーバー、マシン、および環境が本セクション記載の要件および設定を満たしていることを確認してください。
5.2.1.1. サポートされる Windows プラットフォーム
以下のフォレストやドメイン機能レベルを使用する Active Directory フォレストで、信頼関係を確立することができます。
- フォレスト機能レベルの範囲: Windows Server 2008 - Windows Server 2016 R2
- ドメイン機能レベルの範囲: Windows Server 2008 - Windows Server 2016 R2
以下のオペレーティングシステムは、上記の機能レベルを用いた信頼確立においサポートされ、テストされています。
- Windows Server 2012 R2
- Windows Server 2016
以前のバージョンの Windows Server では、信頼確立のサポートはありません。
5.2.1.2. DNS およびレルム設定
信頼関係を確立するには、Active Directory と Identity Management で以下の特定の DNS 設定が必要になります。
- 一意のプライマリー DNS ドメイン
- 各システムは、一意のプライマリー DNS ドメインを設定する必要があります。例えば、
- AD の場合は
ad.example.com、IdM の場合はidm.example.com - AD の場合は
example.com、IdM の場合はidm.example.com
注記
IdM のexample.comや、AD のad.example.comなど、IdM ドメインが AD ドメインの親ドメインの場合には、バグがあるため (BZ#1421869 で追跡)、IdM は正しく機能しません。最も便利な管理ソリューションは、各 DNS ドメインが統合 DNS サーバーで管理されている環境ですが、標準準拠の DNS サーバーであればいずれのものでも使用できます。AD または IdM では、アイデンティティー管理目的でプライマリー DNS ドメインを別のシステムと共有することはできません。詳細については、 Linux ドメイン ID、認証、およびポリシーガイド のホスト名および DNS 設定要件のセクションを参照してください。 - Kerberos レルム名をプライマリー DNS ドメイン名の大文字バージョンとする
- Kerberos レルム名はプライマリー DNS ドメイン名と同一のものにし、すべて大文字にする必要があります。例えば、AD のドメイン名が
ad.example.com、IdM のドメイン名がidm.example.comである場合、Kerberos レルム名はAD.EXAMPLE.COMおよびIDM.EXAMPLE.COMとします。 - DNS レコードが信頼内の全 DNS ドメインから解決可能であること
- 信頼関係内で関連するすべての DNS ドメインからの DNS レコードをすべてのマシンが解決可能である必要があります。
- IdM DNS を設定する際には、Linux ドメイン ID、認証、およびポリシーガイド の IdM ドメイン内での DNS サービスの設定 および 『DNS 転送の管理』 セクションに記載の指示に従います。
- 統合 DNS なしで IdM を使用している場合は、Linux ドメイン ID、認証、およびポリシーガイド の 『統合 DNS なしでサーバーをインストールする』 セクションにある指示に従ってください。
- IdM と AD DNS ドメイン間で重複しないこと
- IdM に参加したマシンは複数の DNS ドメインに分配することができます。IdM クライアントを含んでいる DNS ドメインは、AD に参加しているマシンを含んでいる DNS ドメインと重複することはできません。AD 信頼をサポートするには、プライマリー IdM DNS ドメインに適切な SRV レコードがある必要があります。
$ ipa dns-update-system-records --dry-runコマンドを実行して、お使いのシステム設定に固有の必須 SRV レコード一覧を取得できます。生成されたリストは、以下のような形式になっています。$ ipa dns-update-system-records --dry-run IPA DNS records: _kerberos-master._tcp.example.com. 86400 IN SRV 0 100 88 server.example.com. _kerberos-master._udp.example.com. 86400 IN SRV 0 100 88 server.example.com. _kerberos._tcp.example.com. 86400 IN SRV 0 100 88 server.example.com. _kerberos._udp.example.com. 86400 IN SRV 0 100 88 server.example.com. _kerberos.example.com. 86400 IN TXT "EXAMPLE.COM" _kpasswd._tcp.example.com. 86400 IN SRV 0 100 464 server.example.com. _kpasswd._udp.example.com. 86400 IN SRV 0 100 464 server.example.com. _ldap._tcp.example.com. 86400 IN SRV 0 100 389 server.example.com. _ntp._udp.example.com. 86400 IN SRV 0 100 123 server.example.com.
同じ IdM レルムの一部である他の DNS ドメインでは、AD への信頼設定時に SRV レコードを設定する必要がありません。これは、AD ドメインコントローラーが KDC の検索に SRV レコードを使用せず、KDC の検索には信頼の名前サフィックスルーティング情報を使用するためです。
DNS 設定の確認
信頼を設定する前に、Identity Management と Active Directory サーバーが自身を解決し、また相互に解決できることを確認します。
以下のコマンドを実行しても期待される結果が表示されない場合は、コマンドが実行されたホストの DNS 設定を調べます。このホスト設定が正しい場合は、親から子ドメインへの DNS 委任が正しく設定されていることを確認します。
AD は DNS 検索の結果をキャッシュするので、DNS 内の変更は直ちには見えない場合があることに注意してください。
ipconfig /flushdns コマンドを実行するとキャッシュが削除できます。
- IdM でホストされているサービスが信頼確立に使用される IdM ドメインサーバーから解決可能であることを確認する
- TCP サービスレコードに対する LDAP と UDP による Kerberos の DNS クエリを実行します。
[root@ipaserver ~]# dig +short -t SRV _kerberos._udp.ipa.example.com. 0 100 88 ipamaster1.ipa.example.com. [root@ipaserver ~]# dig +short -t SRV _ldap._tcp.ipa.example.com. 0 100 389 ipamaster1.ipa.example.com.
このコマンドでは、全 IdM サーバーが一覧表示されるはずです。 - IdM Kerberos レルム名で TXT レコードの DNS クエリーを実行します。取得される値は、IdM インストール時に指定した Kerberos レルムと一致することが期待されます。
[root@ipaserver ~]# dig +short -t TXT _kerberos.ipa.example.com. IPA.EXAMPLE.COM
ipa-adtrust-installにあるように 「信頼向けに IdM サーバーを準備する」 ユーティリティーを実行した後、TCP サービスレコードに対する LDAP と UDP による MS DC Kerberos の DNS クエリを実行します。[root@ipaserver ~]# dig +short -t SRV _kerberos._udp.dc._msdcs.ipa.example.com. 0 100 88 ipamaster1.ipa.example.com. [root@ipaserver ~]# dig +short -t SRV _ldap._tcp.dc._msdcs.ipa.example.com. 0 100 389 ipamaster1.ipa.example.com.
このコマンドでは、ipa-adtrust-installを実行した全 IdM サーバーが一覧表示されるはずです。ipa-adtrust-installを IdM サーバーで実行していない場合は、出力は空白になることに留意してください。最初の信頼関係を確立していない場合は、これはよくあることです。
- IdM が AD のサービスレコードを解決可能であることを確認する
- TCP サービスレコードに対する LDAP と UDP による Kerberos の DNS クエリを実行します。
[root@ipaserver ~]# dig +short -t SRV _kerberos._udp.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.
このコマンドでは、AD ドメインコントローラーの名前が返されるはずです。 - IdM でホストされているサービスが AD サーバーから解決可能であることを確認する
- AD サーバーでサービスレコードを検索する
nslookup.exeユーティリティーをセットアップします。C:\>nslookup.exe > set type=SRV
- TCP サービスレコードに対する LDAP と UDP による Kerberos のドメイン名を入力します。
> _kerberos._udp.ipa.example.com. _kerberos._udp.ipa.example.com. SRV service location: priority = 0 weight = 100 port = 88 svr hostname = ipamaster1.ipa.example.com > _ldap._tcp.ipa.example.com _ldap._tcp.ipa.example.com SRV service location: priority = 0 weight = 100 port = 389 svr hostname = ipamaster1.ipa.example.com予測される出力には IdM でホストされているサービスが信頼確立に使用される IdM ドメインサーバーから解決可能であることを確認する で表示される IdM サーバーと同じものが含まれます。 - サービスタイプを TXT に変更し、IdM Kerberos レルム名を使って TXT レコードの DNS クエリを実行します。
C:\>nslookup.exe > set type=TXT > _kerberos.ipa.example.com. _kerberos.ipa.example.com. text = "IPA.EXAMPLE.COM"出力は IdM でホストされているサービスが信頼確立に使用される IdM ドメインサーバーから解決可能であることを確認する で表示される値と同じものが含まれるはずです。 ipa-adtrust-installにあるように 「信頼向けに IdM サーバーを準備する」 ユーティリティーを実行した後、TCP サービスレコードに対する LDAP と UDP による MS DC Kerberos の DNS クエリを実行します。C:\>nslookup.exe > set type=SRV > _kerberos._udp.dc._msdcs.ipa.example.com. _kerberos._udp.dc._msdcs.ipa.example.com. SRV service location: priority = 0 weight = 100 port = 88 svr hostname = ipamaster1.ipa.example.com > _ldap._tcp.dc._msdcs.ipa.example.com. _ldap._tcp.dc._msdcs.ipa.example.com. SRV service location: priority = 0 weight = 100 port = 389 svr hostname = ipamaster1.ipa.example.comこのコマンドでは、ipa-adtrust-installユーティリティーを実行した全 IdM サーバーが一覧表示されるはずです。ipa-adtrust-installを IdM サーバーで実行していない場合は、出力は空白になることに留意してください。最初の信頼関係を確立していない場合は、これはよくあることです。
- AD サービスが AD サーバーから解決可能であることを確認する
- AD サーバーでサービスレコードを検索する
nslookup.exeユーティリティーをセットアップします。C:\>nslookup.exe > set type=SRV
- TCP サービスレコードに対する LDAP と UDP による Kerberos のドメイン名を入力します。
> _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予測される出力には IdM が AD のサービスレコードを解決可能であることを確認する で表示される AD サーバーと同じものが含まれます。
5.2.1.3. NetBIOS 名
NetBIOS 名は AD ドメインの特定に必須のもので、IdM ドメインが Active Directory DNS のサブドメイン内にある場合は、IdM ドメインとサービスの特定に必須のものです。IdM ドメインと Active Directory ドメインでは、NetBIOS 名は別のものである必要があります。
注記
NetBIOS 名は通常、ドメイン名の左端の要素になります。例えば、ドメイン名が
linux.example.com であれば NetBIOS 名は linux になり、ドメイン名が example.com であれば NetBIOS 名は example になります。
NetBIOS 名は最長 15 文字です。
5.2.1.4. ファイアウォールおよびポート
AD ドメインコントローラーと IdM サーバーとの通信を可能にするには、以下のポート要件を満たす必要があります。
- AD 信頼に必要なポート と AD 信頼内の IdM サーバーに必要なポート を IdM サーバーと全 AD ドメインコントローラーで開きます。これらは、IdM サーバーから AD ドメインコントローラーおよびその逆の両方向で開きます。
- AD 信頼内の IdM クライアントで必要なポート を信頼される AD フォレストの全 AD ドメインコントローラーで開きます。IdM クライアント上では、ポートが発信方向で開いていることを確認します (Linux ドメイン ID、認証、およびポリシーガイド の 『クライアントインストールの前提条件』 を参照してください)。
表5.2 AD 信頼に必要なポート
表5.3 信頼内の IdM サーバーに必要なポート
| サービス | ポート | プロトコル | 備考 |
|---|---|---|---|
| Kerberos | Linux ドメイン ID、認証、およびポリシーガイド の 『ポート要件』 を参照してください。 | ||
| LDAP | |||
| DNS | |||
表5.4 AD 信頼内の IdM クライアントに必要なポート
| サービス | ポート | プロトコル | 備考 |
|---|---|---|---|
| Kerberos | 88 | UDP および TCP |
KDC (キー配布センター) プロキシを設定済みの場合は、このポートは必要ありません。その場合、IdM クライアントは Kerberos リクエストを IdM サーバー経由で送信します。
|
その他のリソース
- 必要なポートを開く方法に関しては、Linux ドメイン ID、認証、およびポリシーガイド の 『ポート要件』 を参照してください。
5.2.1.5. IPv6 設定
IdM システムでは、カーネル内で IPv6 プロトコルが有効になっている必要があります。IPv6 が無効になっていると、IdM サービスが使用する CLDAP プラグインが初期化に失敗します。
5.2.1.6. 時計の設定
Active Directory サーバーと IdM サーバーの両方の時計が同期している必要があります。
5.2.1.7. サポートされるユーザー名の形式
IdM はローカル SSSD クライアント内でユーザー名マッピングを実行します。SSSD がサポートするデフォルトのユーザー名形式は、
name@domain です。Active Directory は username、username@DOMAIN.NAME、および DOMAIN\username といったいくつかの異なる形式をサポートします。
ユーザー名と所属するドメインを特定するために、SSSD は
re_expression オプションで定義される正規表現を使用します。この正規表現は IdM バックエンドおよび AD バックエンドで使用され、上記の形式すべてをサポートします。
re_expression = (((?P<domain>[^\\]+)\\(?P<name>.+$))|((?P<name>[^@]+)@(?P<domain>.+$))|(^(?P<name>[^@\\]+)$))
5.2.2. 信頼の作成
以下のセクションでは、各種の設定シナリオにおける信頼の作成について説明しています。「コマンドラインからの信頼作成」 には、コマンドラインから信頼を設定する完全な手順が含まれています。他のシナリオでは、基本的な設定シナリオとは別のステップを説明し、他のすべてのステップの基本的な手順を紹介しています。
信頼の作成後には 「フォレスト間の信頼のインストール後の検討事項」 を参照してください。
5.2.2.1. コマンドラインからの信頼作成
IdM と Active Directory Kerberos レルム間での信頼関係の作成には以下を実行します。
- 「信頼向けに IdM サーバーを準備する」 にあるように、信頼向けに IdM サーバーを準備します。
- 「信頼合意の作成」 にあるように、信頼の合意を作成します。
- 「Kerberos 設定の確認」 にあるように、Kerberos 設定を確認します。
5.2.2.1.1. 信頼向けに IdM サーバーを準備する
AD との信頼関係向けに IdM サーバーを設定するには、以下の手順に従います。
- 必要な IdM、信頼、および Samba パッケージをインストールします。
[root@ipaserver ]# yum install ipa-server ipa-server-trust-ad samba-client
- IdM サーバーで信頼サービスを有効に設定します。
ipa-adtrust-installユーティリティーを実行します。このユーティリティーは AD 信頼に必要な DNS サービスレコードを追加します。これらのレコードは、IdM が統合 DNS サーバーでインストールされた場合に自動的に作成されます。IdM が統合 DNS なしでインストールされた場合は、ipa-adtrust-installはこの後の手順を進める前に手動で DNS に追加する必要のあるサービスレコード一覧をプリントします。重要
Red Hat では、「DNS 設定の確認」 の説明にあるように、ipa-adtrust-installの実行後は毎回 DNS 設定を確認することを強く推奨します。IdM もしくは AD が統合 DNS サーバーを使用しない場合は特にこれが該当します。- このスクリプトは、古い 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]: y
- ディレクトリーの初回作成時には少なくとも 1 人のユーザー (IdM 管理者) が存在します。SID 生成タスクでは既存ユーザー向けに SID を作成し、信頼環境をサポートします。これはリソース集約型タスクです。ユーザー数が多い場合は、これは別個に実行できます。
Do you want to run the ipa-sidgen task? [no]: yes
- 「DNS およびレルム設定」 にあるように、DNS が正常に設定されていることを確認します。
smbデーモンを起動し、smbclientユーティリティーを使って Samba が IdM 側から Kerberos 認証に応答していることを確認します。[root@ipaserver ~]# systemctl start smb [root@ipaserver ~]# smbclient -L ipaserver.ipa.example.com -k lp_load_ex: changing to config backend registry Domain=[IDM] OS=[Windows 6.1] Server=[Samba 4.2.10] Sharename Type Comment --------- ---- ------- IPC$ IPC IPC Service (Samba 4.2.10) Domain=[IDM] OS=[Windows 6.1] Server=[Samba 4.2.10] Server Comment --------- ------- Workgroup Master --------- -------
5.2.2.1.2. 信頼合意の作成
コマンドで Active
ipa trust-addDirectory ドメインと IdM ドメインの信頼合意を作成します。
# ipa trust-add --type=type ad_domain_name --admin ad_admin_username --password
ipa trust-add は、デフォルトで一方向の信頼を設定します。双方向の信頼を確立するには、--two-way=true オプションを渡します。詳細は、「一方向および双方向の信頼」 を参照してください。
外部の信頼を確立するには、
--external=true オプションを ipa trust-add コマンドに渡します。詳細は、「Active Directory への外部の信頼」 を参照してください。
注記
ipa trust-add コマンドはデフォルトで、サーバーを信頼コントローラーとして設定します。詳細は、「信頼コントローラーおよび信頼エージェント」 を参照してください。
以下の例では、
--two-way=true オプションを使用して双方向の信頼を確認します。
[root@ipaserver ~]# ipa trust-add --type=ad ad.example.com --admin Administrator --password --two-way=true
Active Directory domain administrator's password:
-------------------------------------------------------
Added Active Directory trust for realm "ad.example.com"
-------------------------------------------------------
Realm-Name: ad.example.com
Domain NetBIOS name: AD
Domain Security Identifier: S-1-5-21-796215754-1239681026-23416912
SID blacklist incoming: S-1-5-20, S-1-5-3, S-1-5-2, S-1-5-1, S-1-5-7, S-1-5-6, S-1-5-5, S-1-5-4, S-1-5-9, S-1-5-8, S-1-5-17, S-1-5-16, S-1-5-15, S-1-5-14, S-1-5-13, S-1-5-12, S-1-5-11, S-1-5-10, S-1-3, S-1-2, S-1-1, S-1-0, S-1-5-19,
S-1-5-18
SID blacklist outgoing: S-1-5-20, S-1-5-3, S-1-5-2, S-1-5-1, S-1-5-7, S-1-5-6, S-1-5-5, S-1-5-4, S-1-5-9, S-1-5-8, S-1-5-17, S-1-5-16, S-1-5-15, S-1-5-14, S-1-5-13, S-1-5-12, S-1-5-11, S-1-5-10, S-1-3, S-1-2, S-1-1, S-1-0, S-1-5-19,
S-1-5-18
Trust direction: Two-way trust
Trust type: Active Directory domain
Trust status: Established and verified5.2.2.1.3. Kerberos 設定の確認
Kerberos 設定を確認するには、IdM ユーザーのチケットを取得できるか、また IdM ユーザーがサービスチケットをリクエストできるかをテストします。
双方向の信頼を確認するには、以下を実行します。
- IdM ユーザーのチケットをリクエストします。
[root@ipaserver ~]# kinit user
- IdM ドメイン内のサービスのサービスチケットをリクエストします。
[root@ipaserver ~]# kvno -S host ipaserver.example.com
- AD ドメイン内のサービスのサービスチケットをリクエストします。
[root@ipaserver ~]# kvno -S cifs adserver.example.com
AD サービスチケットが正常に付与されると、レルム間のチケット保証チケット (TGT) にリクエストされた他のチケットすべてが記載されます。この TGT はkrbtgt/AD.DOMAIN@IPA.DOMAINという名前になります。[root@ipaserver ]# klist Ticket cache: FILE:/tmp/krb5cc_0 Default principal: user@IPA.DOMAIN Valid starting Expires Service principal 06/15/12 12:13:04 06/16/12 12:12:55 krbtgt/IPA.DOMAIN@IPA.DOMAIN 06/15/12 12:13:13 06/16/12 12:12:55 host/ipaserver.ipa.example.com@IPA.DOMAIN 06/15/12 12:13:23 06/16/12 12:12:55 krbtgt/AD.DOMAIN@IPA.DOMAIN 06/15/12 12:14:58 06/15/12 22:14:58 cifs/adserver.ad.example.com@AD.DOMAIN
IdM 側からの一方向の信頼を確認するには、以下を実行します。
- Active Directory ユーザーのチケットをリクエストします。
[root@ipaserver ~]# kinit user@AD.DOMAIN
- IdM ドメイン内のサービスのサービスチケットをリクエストします。
[root@ipaserver ~]# kvno -S host ipaserver.example.com
AD サービスチケットが正常に付与されると、レルム間のチケット保証チケット (TGT) にリクエストされた他のチケットすべてが記載されます。この TGT はkrbtgt/IPA.DOMAIN@AD.DOMAINという名前になります。[root@ipaserver ]# klist Ticket cache: KEYRING:persistent:0:krb_ccache_hRtox00 Default principal: user@AD.DOMAIN Valid starting Expires Service principal 03.05.2016 18:31:06 04.05.2016 04:31:01 host/ipaserver.ipa.example.com@IPA.DOMAIN renew until 04.05.2016 18:31:00 03.05.2016 18:31:06 04.05.2016 04:31:01 krbtgt/IPA.DOMAIN@AD.DOMAIN renew until 04.05.2016 18:31:00 03.05.2016 18:31:01 04.05.2016 04:31:01 krbtgt/AD.DOMAIN@AD.DOMAIN renew until 04.05.2016 18:31:00
localauth プラグインが Kerberos プリンシパルをローカルの SSSD ユーザー名にマッピングします。これにより AD ユーザーは Kerberos 認証を使用し、GSSAPI 認証を直接サポートする Linux サービスにアクセスできるようになります。
注記
このプラグインについての詳細は、「パスワードなしでの SSH の使用」 を参照してください。
5.2.2.3. 既存の IdM インスタンス上での信頼の作成
既存の IdM インスタンスで信頼を設定する場合は、IdM サーバーとそのドメイン内のエントリーについての特定のセッティングは設定済みになっています。ただし、Active Directory ドメインの DNS 設定では、Active Directory SID をすべての既存の IdM ユーザーおよびグループに割り当てる設定にする必要があります。
- 「信頼向けに IdM サーバーを準備する」 にあるように、信頼向けに IdM サーバーを準備します。
- 「信頼合意の作成」 にあるように、信頼の合意を作成します。
- 各 IdM ユーザーに SID を生成します。
注記
ipa-adtrust-installユーティリティーを使用した信頼の確立時に SID が生成されている場合は、このステップを実行しないでください。- バックエンドの LDAP ディレクトリーで、
ipa-sidgen-task操作を実行して、各エントリーごとに、SID を含む、新しいipaNTSecurityIdentifier属性を自動的に追加します。[root@ipaserver ]# ldapmodify -x -H ldap://ipaserver.ipa.example.com:389 -D "cn=directory manager" -w password dn: cn=sidgen,cn=ipa-sidgen-task,cn=tasks,cn=config changetype: add objectClass: top objectClass: extensibleObject cn: sidgen nsslapd-basedn: dc=ipadomain,dc=com delay: 0 adding new entry "cn=sidgen,cn=ipa-sidgen-task,cn=tasks,cn=config"
- このタスクが正常に完了すると、SID 生成タスク (
Sidgen task) がステータスゼロ (0) で終了したというメッセージがエラーログに記録されます。[root@ipaserver ]# grep "sidgen_task_thread" /var/log/dirsrv/slapd-IDM-EXAMPLE-COM/errors [20/Jul/2012:18:17:16 +051800] sidgen_task_thread - [file ipa_sidgen_task.c, line 191]: Sidgen task starts ... [20/Jul/2012:18:17:16 +051800] sidgen_task_thread - [file ipa_sidgen_task.c, line 196]: Sidgen task finished [0].
- 「Kerberos 設定の確認」 にあるように、Kerberos 設定を確認します。
5.2.2.4. 2 つ目の信頼の追加
1 つ以上の信頼合意が設定されている IdM サーバーに新たな信頼を追加する際は、信頼関連のパッケージのインストールや SID の設定といった一般的な IdM 信頼設定の一部が不要になります。新たな信頼を追加するには、DNS を設定し、信頼合意を確立することのみが必要になります。
- 「DNS およびレルム設定」 にあるように、DNS が正常に設定されていることを確認します。
- 「信頼合意の作成」 にあるように、信頼の合意を作成します。
5.2.2.5. Web UI 内での信頼の作成
Web UI 内で信頼を作成する前に、信頼用の IdM サーバーを用意します。この信頼設定はコマンドラインから実行すると最も容易で、「信頼向けに IdM サーバーを準備する」 で説明されています。
初期設定が完了したら、信頼合意を IdM web UI で追加します。
- IdM web UI を開きます。
https://ipaserver.example.com
- IPA Server メインタブを開いてから、Trusts サブタブを選択します。
- Trusts サブタブで Add をクリックし、新規信頼設定ウィンドウを開きます。
- 信頼についての必須情報を入力します。
- Domain フィールドに AD ドメイン名を記入します。
- 信頼を双方向にするには、Two-way trust チェックボックスを選択します。信頼を一方向にするには、Two-way trust を選択しないでください。一方向および双方向の信頼に関する詳細情報は、「一方向および双方向の信頼」 を参照してください。
- 別のフォレストにあるドメインへの外部の信頼を確立するには、External Trust チェックボックスを選択します。詳細は、「Active Directory への外部の信頼」 を参照してください。
- Establish using セクションでは、信頼の確立方法を定義します。
- AD 管理者のユーザー名とパスワードを使って信頼を確立する場合は、Administrative account を選択して必要な認証情報を入力します。
- 共有パスワードを使って信頼を確立する場合は、Pre-shared password を選択して信頼パスワードを入力します。
- 信頼の ID 設定を定義します。
- Range type オプションでは、ID 範囲のタイプを選択できます。IdM が自動的に使用する ID 範囲のタイプを検出するようにするには、Detect を選択します。
- ID 範囲の最初の ID を定義するには、Base ID フィールドを使用します。ID 範囲のサイズを定義するには、Range size フィールドを使用します。これらのオプションを指定しないと、IdM は ID 範囲のデフォルト値を使用します。
ID 範囲についての詳細は、「ID の範囲」 を参照してください。

図5.5 Web UI での信頼の追加
- をクリックして新規の信頼を保存します。
この後に 「Kerberos 設定の確認」 にあるように、Kerberos 設定を確認します。
5.2.3. フォレスト間の信頼のインストール後の検討事項
5.2.3.1. Active Directory 信頼における動作の潜在的問題
5.2.3.1.1. Active Directory ユーザーと IdM 管理
現在、IdM Web UI にログイン後は、Active Directory (AD) ユーザーおよび管理者には、セルフサービスページのみが表示されます。AD 管理者は、IdM Web UI の管理者ビューにアクセスできません。詳細は、『Linux ドメインアイデンティティー認証およびポリシーガイド』の対応するセクションを参照してください。
また、AD ユーザーは現時点で自身の ID 上書きを管理することはできません。ID の上書きの追加および管理が可能なのは、IdM ユーザーのみです。
5.2.3.1.2. 削除された Active Directory ユーザーの認証
デフォルトでは、すべての IdM クライアントは SSSD サービスを使用してユーザー ID および資格情報をキャッシュします。IdM または AD バックエンドプロバイダーが一時的に利用できない場合は、SSSD によりローカルシステムはこれまでに正常にログインしたことのあるユーザーの ID を参照することができます。
SSSD はユーザー一覧をローカルで保持するため、バックエンドでなされた変更は SSSD をオフラインで実行するクライアントに直ちには認識されない可能性があります。そのようなクライアントでは、IdM リソースにログインしたことがあるユーザーでハッシュ化されたパスワードが SSSD キャッシュに保存されているユーザーは、AD でユーザーアカウントが削除されていても再度ログインすることができます。
上記の条件が満たされる場合は、ユーザー ID が SSSD にキャッシュされ、AD でユーザーアカウントが削除されても AD ユーザーは IdM リソースにログインできます。この問題は、SSSD がオンラインになり、AD ユーザーログオンを AD ドメインコントローラーに対して確認できるようになるまで続きます。
クライアントシステムが SSSD をオンラインで実行している場合は、ユーザーが提供するパスワードは AD ドメインコントローラーに対して確認されます。これにより、削除された AD ユーザーのログインが許可されなくなります。
5.2.3.1.3. 認証情報キャッシュコレクションおよび Active Directory プリンシパルの選択
Kerberos 認証情報キャッシュは、クライアントプリンシパルを以下の識別子に対して以下の順でサーバープリンシパルに対して一致させるよう試行します。
- サービス名
- ホスト名
- レルム名
クライアントとサーバーのマッピングがホスト名もしくはレルム名をベースとし、認証情報キャッシュのコレクションが使用される場合は、AD ユーザーとしてバインドする際に予期しない動作が発生する場合があります。これは、Active Directory ユーザーのレルム名が IdM システムのレルム名とは異なるためです。
AD ユーザーが
kinit ユーティリティーを使用してチケットを取得し、SSH を使って an IdM リソースに接続すると、プリンシパルはこのリソースチケットに選択されません。an IdM プリンシパルがリソースのレルム名と一致することから、IdM プリンシパルが使用されます。
例えば、AD ユーザーが
Administrator でドメインが ADEXAMPLE.ADREALM の場合、プリンシパルは Administrator@ADEXAMPLE.ADREALM になります。
[root@server ~]# kinit Administrator@ADEXAMPLE.ADREALM Password for Administrator@ADEXAMPLE.ADREALM: [root@server ~]# klist Ticket cache: KEYRING:persistent:0:0 Default principal: Administrator@ADEXAMPLE.ADREALM Valid starting Expires Service principal 27.11.2015 11:25:23 27.11.2015 21:25:23 krbtgt/ADEXAMPLE.ADREALM@ADEXAMPLE.ADREALM renew until 28.11.2015 11:25:16
これは Active Directory チケットキャッシュのデフォルトプリンシパルとして設定されます。ただし、IdM ユーザーが Kerberos チケット (
admin など) も持っている場合、IdM デフォルトプリンシパルと共に別の an IdM 認証情報キャッシュも存在することになります。その IdM デフォルトプリンシパルは、Active Directory ユーザーが SSH を使用してリソースに接続する場合にホストチケットに選択されます。
[root@vm-197 ~]# ssh -l Administrator@adexample.adrealm ipaclient.example.com Administrator@adexample.adrealm@ipaclient.example.com's password: [root@vm-197 ~]# klist -A Ticket cache: KEYRING:persistent:0:0 Default principal: Administrator@ADEXAMPLE.ADREALM Valid starting Expires Service principal 27.11.2015 11:25:23 27.11.2015 21:25:23 krbtgt/ADEXAMPLE.ADREALM@ADEXAMPLE.ADREALM renew until 28.11.2015 11:25:16 Ticket cache: KEYRING:persistent:0:0Default principal: admin@EXAMPLE.COM>>>>> IdM user Valid starting Expires Service principal 27.11.2015 11:25:18 28.11.2015 11:25:16 krbtgt/EXAMPLE.COM@EXAMPLE.COM27.11.2015 11:25:48 28.11.2015 11:25:16 host/ipaclient.example.com@EXAMPLE.COM>>>>> host principal
これは IdM プリンシパルのレルム名が IdM リソースのレルムに一致するために実行されます。
5.2.3.1.4. グループ SID の解決
Kerberos チケットの失効
net getlocalsid または net getdomainsid などの、Samba サービスから SID を取得するためのコマンドを実行すると、Kerberos キャッシュから既存の admin チケットが削除されます。
注記
Active
net getlocalsidDirectory 信頼を使用するために getdomainsid や といったコマンドを実行する必要はありません。
ユーザーのグループメンバーシップを確認できない
特定の信頼されるユーザーが特定の IdM グループ、外部または POSIX グループに関連付けられていることを確認することはできません。
Active Directory ユーザーの (リモート) Active Directory グループメンバーシップを表示できない
重要
IdM サーバーおよびクライアントが Red Hat Enterprise Linux 7.1 またはそれ以降で実行される場合は、この問題は発生しないことに留意してください。
id ユーティリティーを使うと、Linux システムユーザーのローカルグループの関連付けが表示できます。ただし、Samba ツールでは ActiveidDirectory ユーザーの Active Directory グループメンバーシップは表示できますが、 ではこれは表示されません。
この問題を回避するには、
ssh ユーティリティーを使って指定された AD ユーザーとして an IdM クライアントマシンにログインします。この AD ユーザーログインが最初に成功すると、id では AD グループメンバーシップを検出して表示します。
[root@ipaserver ~]# id ADDOMAIN\user uid=1921801107(user@ad.example.com) gid=1921801107(user@ad.example.com) groups=1921801107(user@ad.example.com),129600004(ad_users),1921800513(domain users@ad.example.com)
5.2.3.2. 信頼エージェントの設定
通常の IdM マスターが信頼エージェントとして動作するようにするには、以下の設定を行います。
- 信頼コントローラー上で
ipa-adtrust-install --add-agentsコマンドを実行します。これで対話式の設定セッションになり、エージェント設定に必要な情報の入力が求められます。--add-agentsオプションについての詳細情報は、ipa-adtrust-install(1) man ページを参照してください。 - LDAP サービスを再起動します。
信頼エージェントについての詳細は、「信頼コントローラーおよび信頼エージェント」 を参照してください。

Where did the comment section go?
Red Hat's documentation publication system recently went through an upgrade to enable speedier, more mobile-friendly content. We decided to re-evaluate our commenting platform to ensure that it meets your expectations and serves as an optimal feedback mechanism. During this redesign, we invite your input on providing feedback on Red Hat documentation via the discussion platform.