Red Hat Training

A Red Hat training course is available for Red Hat Enterprise Linux

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 と 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 ドメインサーバーから解決可能であることを確認する
  1. 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 サーバーが一覧表示されるはずです。
  2. IdM Kerberos レルム名で TXT レコードの DNS クエリーを実行します。取得される値は、IdM インストール時に指定した Kerberos レルムと一致することが期待されます。 
    [root@ipaserver ~]# dig +short -t TXT _kerberos.ipa.example.com.
IPA.EXAMPLE.COM
  3. 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 サーバーから解決可能であることを確認する
  1. AD サーバーでサービスレコードを検索する nslookup.exe ユーティリティーをセットアップします。 
    C:\>nslookup.exe
> set type=SRV
  2. 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 サーバーと同じものが含まれます。
  3. サービスタイプを 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 ドメインサーバーから解決可能であることを確認する で表示される値と同じものが含まれるはずです。
  4. 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 サーバーから解決可能であることを確認する
  1. AD サーバーでサービスレコードを検索する nslookup.exe ユーティリティーをセットアップします。 
    C:\>nslookup.exe
> set type=SRV
  2. 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 サーバーとの通信を可能にするには、以下のポート要件を満たす必要があります。

表5.2 AD 信頼に必要なポート

サービスポートプロトコル
エンドポイント解決ポートマッパー135TCP
NetBIOS-DGM138TCP および UDP
NetBIOS-SSN139TCP および UDP
Microsoft-DS445TCP および UDP
エンドポイントマッパーリスナーの範囲1024-1300TCP
AD グローバルカタログ3268TCP
LDAP389TCP [a] および UDP
[a] TCP ポート 389 は信頼のためには IdM サーバー上で開く必要はありませんが、クライアントが IdM サーバーと通信するために必要になります。

表5.3 信頼内の IdM サーバーに必要なポート

サービスポートプロトコル備考
KerberosLinux ドメイン ID、認証、およびポリシーガイド の 『ポート要件』 を参照してください。
LDAP
DNS

表5.4 AD 信頼内の IdM クライアントに必要なポート

サービスポートプロトコル備考
Kerberos88UDP および TCP
KDC (キー配布センター) プロキシを設定済みの場合は、このポートは必要ありません。その場合、IdM クライアントは Kerberos リクエストを IdM サーバー経由で送信します。

その他のリソース

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 レルム間での信頼関係の作成には以下を実行します。
  1. 「信頼向けに IdM サーバーを準備する」 にあるように、信頼向けに IdM サーバーを準備します。
  2. 「信頼合意の作成」 にあるように、信頼の合意を作成します。
  3. 「Kerberos 設定の確認」 にあるように、Kerberos 設定を確認します。
5.2.2.1.1. 信頼向けに IdM サーバーを準備する
AD との信頼関係向けに IdM サーバーを設定するには、以下の手順に従います。
  1. 必要な IdM、信頼、および Samba パッケージをインストールします。 
    [root@ipaserver ]# yum install ipa-server ipa-server-trust-ad samba-client
  2. IdM サーバーで信頼サービスを有効に設定します。
    1. ipa-adtrust-install ユーティリティーを実行します。このユーティリティーは AD 信頼に必要な DNS サービスレコードを追加します。これらのレコードは、IdM が統合 DNS サーバーでインストールされた場合に自動的に作成されます。
      IdM が統合 DNS なしでインストールされた場合は、ipa-adtrust-install はこの後の手順を進める前に手動で DNS に追加する必要のあるサービスレコード一覧をプリントします。

      重要

      Red Hat では、「DNS 設定の確認」 の説明にあるように、ipa-adtrust-install の実行後は毎回 DNS 設定を確認することを強く推奨します。IdM もしくは AD が統合 DNS サーバーを使用しない場合は特にこれが該当します。
    2. このスクリプトは、古い 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
    3. ディレクトリーの初回作成時には少なくとも 1 人のユーザー (IdM 管理者) が存在します。SID 生成タスクでは既存ユーザー向けに SID を作成し、信頼環境をサポートします。これはリソース集約型タスクです。ユーザー数が多い場合は、これは別個に実行できます。 
      Do you want to run the ipa-sidgen task? [no]: yes
  3. 「DNS およびレルム設定」 にあるように、DNS が正常に設定されていることを確認します。
  4. 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. 信頼合意の作成
  コマンドで Activeipa 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 verified
5.2.2.1.3. Kerberos 設定の確認
Kerberos 設定を確認するには、IdM ユーザーのチケットを取得できるか、また IdM ユーザーがサービスチケットをリクエストできるかをテストします。
双方向の信頼を確認するには、以下を実行します。
  1. IdM ユーザーのチケットをリクエストします。 
    [root@ipaserver ~]# kinit user
  2. IdM ドメイン内のサービスのサービスチケットをリクエストします。 
    [root@ipaserver ~]# kvno -S host ipaserver.example.com
  3. 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 側からの一方向の信頼を確認するには、以下を実行します。
  1. Active Directory ユーザーのチケットをリクエストします。 
    [root@ipaserver ~]# kinit user@AD.DOMAIN
  2. 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.2. 共有シークレットでの双方向の信頼の作成

共有シークレットとは信頼されたピアに対して既知のパスワードで、他のドメインはこれを使ってこの信頼に参加できます。Active Directory 内の双方向の信頼は、共有シークレットで設定できます。AD 内では、共有シークレットは信頼の設定内に 信頼される側のドメインオブジェクト (TDO) として保存されます。
IdM は、AD 管理者認証情報の代わりに共有シークレットを使用した双方向の信頼の作成をサポートしています。この方法で信頼を設定するには、管理者が AD に共有シークレットを作成し、AD 側で信頼を手動で確認する必要があります。

注記

共有シークレットは、双方向の信頼を作成するためにだけ使用できます。一方向の信頼を確立するには、管理者の認証情報を使用します。
Windows Server 2012、2012 R2 または 2016 で、共有シークレットを使用して双方向の信頼を作成するには、以下を行います。
  1. 「信頼向けに IdM サーバーを準備する」 にあるように、信頼向けに IdM サーバーを準備します。
  2. Active Directory Domains and Trusts コンソールで信頼を設定します。具体的には、以下を行います。
    • 新規の信頼を作成します。
    • 信頼に、idm.example.comなどの IdM ドメイン名を指定します。
    • 信頼の forest タイプであることを指定します。
    • 信頼の two-way タイプであることを指定します。
    • forest-wide の認証であることを指定します。
    • Trust Password を設定します。

      注記

      IdM 内で信頼を設定する際には、同じパスワードを使用する必要があります。
    着信の信頼の確認を求められたら、No を選択します。
  3. 「信頼合意の作成」 にあるように、信頼の合意を作成します。ipa trust-add コマンドでは、--type および --trust-secret オプションを使用し、--two-way=True オプションは使用しないでください。例を示します。 
    [root@ipaserver ~]# ipa trust-add --type=ad ad.example.com --trust-secret --two-way=True
Shared secret for the trust:
-------------------------------------------------------
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: Trusting forest
  Trust type: Active Directory domain
  Trust status: Waiting for confirmation by remote side
  4. ipa trust-show コマンドを使用して、IdM サーバー上で信頼関係が確立されてことを確認します。 
    [root@ipaserver ~]# ipa trust-show ad.example.com

  Domain NetBIOS name: AD
  Domain Security Identifier: S-1-5-21-796215754-1239681026-23416912
  Trust direction: Trusting forest
  Trust type: Active Directory domain

    注記

    ipa trust-show コマンドの実行前に、ipa trust-fetch-domains ad_domain コマンドを実行して Common Internet File System (CIFS) チケット保証チケットを取得する必要がある場合があります。
  5. 「Kerberos 設定の確認」 にあるように、Kerberos 設定を確認します。

5.2.2.3. 既存の IdM インスタンス上での信頼の作成

既存の IdM インスタンスで信頼を設定する場合は、IdM サーバーとそのドメイン内のエントリーについての特定のセッティングは設定済みになっています。ただし、Active Directory ドメインの DNS 設定では、Active Directory SID をすべての既存の IdM ユーザーおよびグループに割り当てる設定にする必要があります。
  1. 「信頼向けに IdM サーバーを準備する」 にあるように、信頼向けに IdM サーバーを準備します。
  2. 「信頼合意の作成」 にあるように、信頼の合意を作成します。
  3. 各 IdM ユーザーに SID を生成します。

    注記

    ipa-adtrust-install ユーティリティーを使用した信頼の確立時に SID が生成されている場合は、このステップを実行しないでください。
    1. バックエンドの 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"
    2. このタスクが正常に完了すると、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].
  4. 「Kerberos 設定の確認」 にあるように、Kerberos 設定を確認します。

5.2.2.4. 2 つ目の信頼の追加

1 つ以上の信頼合意が設定されている IdM サーバーに新たな信頼を追加する際は、信頼関連のパッケージのインストールや SID の設定といった一般的な IdM 信頼設定の一部が不要になります。新たな信頼を追加するには、DNS を設定し、信頼合意を確立することのみが必要になります。
  1. 「DNS およびレルム設定」 にあるように、DNS が正常に設定されていることを確認します。
  2. 「信頼合意の作成」 にあるように、信頼の合意を作成します。

5.2.2.5. Web UI 内での信頼の作成

Web UI 内で信頼を作成する前に、信頼用の IdM サーバーを用意します。この信頼設定はコマンドラインから実行すると最も容易で、「信頼向けに IdM サーバーを準備する」 で説明されています。
初期設定が完了したら、信頼合意を IdM web UI で追加します。
  1. IdM web UI を開きます。 
    https://ipaserver.example.com
  2. IPA Server メインタブを開いてから、Trusts サブタブを選択します。
  3. Trusts サブタブで Add をクリックし、新規信頼設定ウィンドウを開きます。
  4. 信頼についての必須情報を入力します。
    1. Domain フィールドに AD ドメイン名を記入します。
    2. 信頼を双方向にするには、Two-way trust チェックボックスを選択します。信頼を一方向にするには、Two-way trust を選択しないでください。
      一方向および双方向の信頼に関する詳細情報は、「一方向および双方向の信頼」 を参照してください。
    3. 別のフォレストにあるドメインへの外部の信頼を確立するには、External Trust チェックボックスを選択します。
      詳細は、「Active Directory への外部の信頼」 を参照してください。
    4. Establish using セクションでは、信頼の確立方法を定義します。
      • AD 管理者のユーザー名とパスワードを使って信頼を確立する場合は、Administrative account を選択して必要な認証情報を入力します。
      • 共有パスワードを使って信頼を確立する場合は、Pre-shared password を選択して信頼パスワードを入力します。
    5. 信頼の ID 設定を定義します。
      • Range type オプションでは、ID 範囲のタイプを選択できます。IdM が自動的に使用する ID 範囲のタイプを検出するようにするには、Detect を選択します。
      • ID 範囲の最初の ID を定義するには、Base ID フィールドを使用します。ID 範囲のサイズを定義するには、Range size フィールドを使用します。これらのオプションを指定しないと、IdM は ID 範囲のデフォルト値を使用します。
      ID 範囲についての詳細は、「ID の範囲」 を参照してください。
    Web UI での信頼の追加

    図5.5 Web UI での信頼の追加

  5. Add をクリックして新規の信頼を保存します。
この後に 「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 認証情報キャッシュは、クライアントプリンシパルを以下の識別子に対して以下の順でサーバープリンシパルに対して一致させるよう試行します。
  1. サービス名
  2. ホスト名
  3. レルム名
クライアントとサーバーのマッピングがホスト名もしくはレルム名をベースとし、認証情報キャッシュのコレクションが使用される場合は、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:0
Default 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.COM
27.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 チケットが削除されます。

注記

Activenet 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 マスターが信頼エージェントとして動作するようにするには、以下の設定を行います。
  1. 信頼コントローラー上で ipa-adtrust-install --add-agents コマンドを実行します。これで対話式の設定セッションになり、エージェント設定に必要な情報の入力が求められます。
    --add-agents オプションについての詳細情報は、ipa-adtrust-install(1) man ページを参照してください。
  2. LDAP サービスを再起動します。
信頼エージェントについての詳細は、「信頼コントローラーおよび信頼エージェント」 を参照してください。