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
  • ドメイン機能レベルの範囲 - Windows Server 2008 - Windows Server 2016
以下のオペレーティングシステムは、上記の機能レベルを用いた信頼確立においサポートされ、テストされています。
  • Windows Server 2012 R2
  • Windows Server 2016
以前のバージョンの Windows Server では、信頼確立のサポートはありません。

5.2.1.2. DNS およびレルムの設定

信頼を確立するには、Active Directory と Identity Management には特定の DNS 設定が必要です。
一意のプライマリー DNS ドメイン
各システムには、固有のプライマリー DNS ドメインが設定されている必要があります。以下に例を示します。
  • ad.example.com （AD の場合）および idm.example.com （IdM の場合）
  • example.com （AD の場合）および idm.example.com （IdM の場合）
  • ad.example.com （AD の場合）および example.com （IdM の場合）
    重要
    IdM ドメインが AD ドメインの親ドメインの場合、IdM サーバーは Red Hat Enterprise Linux 7.5 以降で実行する必要があります。
最も便利な管理ソリューションは、各 DNS ドメインが統合 DNS サーバーで管理されている環境ですが、規格に準拠した DNS サーバーも使用できます。
AD または IdM が、プライマリー DNS ドメインを、ID 管理用に別のシステムと共有することはできません。詳細は、『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 ドメインと重複できません。プライマリー IdM DNS ドメインには、AD 信頼に対応するのに適切な 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 レコードを使用せず、信頼の名前接尾辞のルーティング情報を使用するためです。

DNS 設定の確認

信頼を設定する前に、Identity Management サーバーおよび Active Directory サーバーが自身と解決でき、相互に解決できることを確認します。
次のコマンドを実行しても、想定された結果が表示されない場合は、コマンドが実行されたホストで DNS 設定を検査します。ホスト設定が正しい場合は、親から子ドメインに DNS 委譲が正しく設定されていることを確認してください。
AD は DNS ルックアップの結果をキャッシュするため、DNS で加えた変更はすぐに表示されないことがあります。ipconfig /flushdns コマンドを実行して、現在のキャッシュを削除できます。
IdM がホストするサービスが、信頼の確立に使用する IdM ドメインサーバーから解決可能であることを確認します。
  1. UDP サービスレコード上の Kerberos、および TCP サービスレコード上の LDAP に、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 ユーティリティーを実行した後に、UDP サービスレコード上の MS DC Kerberos、および TCP サービスレコード上の LDAP に、DNS 「信頼用の IdM サーバーの準備」。 
    [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 のサービスレコードを解決できることを確認します。
UDP サービスレコード上の Kerberos、および TCP サービスレコード上の LDAP に、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. UDP サービスレコード上の Kerberos、および TCP サービスレコード上の LDAP に、ドメイン名を入力します。 
    > _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 ユーティリティーを実行した後に、UDP サービスレコード上の MS DC Kerberos、および TCP サービスレコード上の LDAP に、DNS 「信頼用の IdM サーバーの準備」。 
    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. 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
    予想される出力には、表示されているものと同じ AD IdM が AD のサービスレコードを解決できることを確認します。。

5.2.1.3. NetBIOS 名

Active Directory(AD)ドメインを識別し、IdM に AD で信頼が設定されている場合には NetBIOS 名は、IdM ドメインおよびサービスの特定用に重要です。したがって、フォレストトラストを確立する AD ドメインで使用される NetBIOS 名とは異なる NetBIOS 名を使用する必要があります。
Active Directory または IdM ドメインの NetBIOS 名は通常、対応する DNS ドメインの左上のコンポーネントです。たとえば、DNS ドメインが ad.example.com の場合、NetBIOS 名は通常 AD になります。
注記
NetBIOS 名は最大 15 文字です。

5.2.1.4. ファイアウォールおよびポート

AD ドメインコントローラーと IdM サーバーとの間の通信を有効にするには、以下のポート要件を満たすようにしてください。

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

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

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

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

表5.4 AD 信頼で IdM クライアントが必要とするポート

サービス ポート プロトコル 注記
Kerberos 88 UDP および TCP
libkrb5 ライブラリーは UDP を使用し、Kerberos Distribution Center(KDC)から送信されるデータが大きすぎると、TCP プロトコルにフォールバックします。Active Directory は、PAC(Privilege Attribute Certificate)を Kerberos チケットに割り当てます。これによりサイズが増大し、TCP プロトコルを使用するには要求されます。要求のフォールバックと再送信を回避するため、デフォルトでは、Red Hat Enterprise Linux 7.4 以降の SSSD はユーザー認証に TCP を使用します。libkrb5 が TCP を使用する前にサイズを設定するには、/etc/krb.5.conf ファイルに udp_preference_limit を設定します。詳細は krb5.conf(5) の man ページを参照してください。

関連情報

5.2.1.5. IPv6 設定

IdM システムでは、カーネル内で IPv6 プロトコルが有効になっている必要があります。IPv6 が無効になっていると、IdM サービスが使用する CLDAP プラグインが初期化に失敗します。

5.2.1.6. クロック設定

Active Directory サーバーおよび IdM サーバーの両方で、クロックが同期されている必要があります。

5.2.1.7. AD での IdM ドメインに対する条件フォワーダーの作成

AD DNS サーバーを準備し、IdM ドメインのクエリーを IdM DNS サーバーに転送します。
  1. Windows AD ドメインコントローラーで、Active Directory(AD) DNS コンソールを開きます。
  2. Conditional Forwarders を右クリックし、New Conditional Forwarder を選択します。
  3. IdM DNS ドメイン名と IdM DNS サーバーの IP アドレスを入力します。
  4. Active Directory で Store this conditional forwarder を選択して、以下のように複製し、環境に一致するレプリケーション設定を選択します。
  5. OK をクリックします。
  6. AD ドメインコントローラー(DC)が IdM ドメインの DNS エントリーを解決できることを確認するには、コマンドプロンプトを開いて以下を入力します。 
    C:\> nslookup server.idm.example.com
    コマンドが IdM サーバーの IP アドレスを返すと、条件付きフォワーダーは正常に機能します。

5.2.1.8. IdM での AD ドメイン用の正引きゾーンの作成

AD ドメインのクエリーを AD DNS サーバーに転送するために、IdM DNS サーバーを準備します。
  1. IdM サーバーで、AD DNS ドメインの正引きゾーンエントリーを作成します。IdM での DNS 『正引きゾーンの作成に関する詳細は、『Linux ドメイン 『ID、認証、およびポリシーガイド』の「正引きゾーンの設定』 」を参照してください』。
  2. AD DNS サーバーが DNSSEC に対応していない場合は、IdM サーバーで DNSSEC 検証を無効にします。
    1. /etc/named.conf ファイルを編集し、dnssec-validation パラメーターを no に設定します。 
      dnssec-validation no;
    2. named-pkcs11 サービスを再起動します。 
      # systemctl restart named-pkcs11
  3. IdM サーバーが AD ドメインの DNS エントリーを解決できることを確認するには、次のコマンドを実行します。 
    # host server.ad.example.com
    コマンドが AD DC の IP アドレスを返すと、正引きゾーンは正常に機能します。

5.2.1.9. サポートされるユーザー名の形式

IdM は、ローカルの SSSD クライアントでユーザー名のマッピングを実行します。SSSD がサポートする信頼されたドメインのユーザーのデフォルトの出力ユーザー名の形式は user_name@domain です。Active Directory では、さまざまな名前形式 （user_name、user_name@DOMAIN_NAME、および DOMAIN_NAME\user_name）がサポートされます。
ユーザーは、ユーザー名(user_name)または完全修飾ユーザー名(user_name@domain_name)のみを使用して、システムに認証できます。
警告
複数のドメインに同じユーザー名が存在する場合には、完全修飾ユーザー名を使用して競合を回避することが推奨されます。
ユーザーがドメインからユーザー名のみを指定する場合、SSSD は /etc/sssd/sssd.conf ファイルと信頼されるドメインに設定されたすべてのドメインのアカウントを検索します。「IdM クライアントでのドメイン解決順序の設定」、SSSD は定義された順序でユーザーを検索します。いずれの場合も、SSSD は最初に見つかったエントリーを使用します。これにより、同じユーザー名が複数のドメインに存在し、見つかった最初のエントリーが予期された場合は、問題が発生するか、混乱が生じる可能性があります。
デフォルトでは、SSSD はユーザー名を常に完全修飾形式で表示します。形式の変更に関する詳細は、「SSSD が表示するユーザー名の形式の変更」。
ユーザー名とユーザー名が属するドメインを特定するには、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 サーバーを設定します。ipa-replica-install --setup-adtrust コマンドを使用してサーバーをインストールした場合は、この手順を省略できます。
    1. ipa-adtrust-install ユーティリティーを実行します。 
      [root@ipaserver ]# ipa-adtrust-install
      このユーティリティーは、AD 信頼に必要な DNS サービスレコードを追加します。このレコードは、IdM が統合 DNS サーバーとともにインストールされている場合に自動的に作成されます。
      統合 DNS サーバーなしで IdM がインストールされていると、ipa-adtrust-install は、続行する前に DNS に手動で追加する必要があるサービスレコードのリストを出力します。
      重要
      Red Hat は、特に IdM または AD が統合 DNS サーバーを使用しない場合に、ipa-adtrust-install 「DNS 設定の確認」 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 サービスを起動します。 
    [root@ipaserver ~]# systemctl start smb
  5. 必要に応じて、システムの起動時に smb サービスが自動的に起動するように設定します。 
    [root@ipaserver ~]# systemctl enable smb
  6. 必要に応じて、smbclient ユーティリティーを使用して、Samba が IdM から Kerberos 認証に応答することを確認します。 
    [root@ipaserver ~]# smbclient -L ipaserver.ipa.example.com -k
lp_load_ex: changing to config backend registry

	Sharename       Type      Comment
	---------       ----      -------
	IPC$            IPC       IPC Service (Samba 4.9.1)
Reconnecting with SMB1 for workgroup listing.

	Server               Comment
	---------            -------

	Workgroup            Master
	---------            -------
5.2.2.1.2. 信頼関係の作成
ipa trust-add コマンドを使用して、Active Directory ドメインと IdM ドメインに信頼関係を作成します。 
# ipa trust-add --type=type ad_domain_name --admin ad_admin_username --password
ipa trust-add コマンドは、デフォルトで一方向の信頼を設定します。RHEL 7 で双方向の信頼を確立することはできません。
外部信頼を確立するには、--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(Ticket-Granting Ticket)があります。TGT の名前は、krbtgt/IN です。 
    [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(Ticket-Granting Ticket)があります。TGT の名前は、krbtgt/IN です。 
    [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 サービスに直接アクセスできます。
注記

5.2.2.2. 共有シークレットを使用した信頼の作成

共有シークレットは、信頼できるピアが認識され、他のドメインを使用して信頼に参加するために使用できるパスワードです。共有の秘密は、Active Directory(AD)内で一方向と双方向の信頼の両方を設定できます。AD では、共有シークレットは、信頼設定内に信頼されるドメインオブジェクト (TDO)として保存されます。
IdM は、AD 管理者認証情報ではなく、共有シークレットを使用した一方向または双方向の信頼の作成をサポートします。このような信頼を設定するには、管理者は AD で共有シークレットを作成し、AD 側で信頼を手動で検証する必要があります。
5.2.2.2.1. 共有シークレットを使用した双方向の信頼の作成
Microsoft Windows Server 2012、2012 R2、または 2016 で共有のシークレットを使用して双方向の信頼を作成するには、以下を行います。
  1. に従って、信頼用に IdM 「信頼用の IdM サーバーの準備」。
  2. IdM および AD ホストが両方のドメインを解決できない DNS サーバーを使用している場合は、DNS ゾーンの転送を設定します。
    1. AD DNS サーバーを準備し、IdM ドメインのクエリーを IdM DNS サーバーに転送します。詳細はを参照してください 「AD での IdM ドメインに対する条件フォワーダーの作成」。
    2. AD ドメインのクエリーを AD DNS サーバーに転送するために、IdM DNS サーバーを準備します。詳細はを参照してください 「IdM での AD ドメイン用の正引きゾーンの作成」。
  3. Active Directory ドメインおよび信頼コンソールで信頼を設定します。特に以下が含まれます。
    • 新しい信頼を作成します。
    • idm.example.com などの IdM ドメイン名を指定します。
    • これは信頼のフォレストタイプです。
    • これが信頼の双方向タイプです。
    • これがフォレスト全体の認証になるように指定します。
    • 信頼パスワードを設定します。
      注記
      IdM で信頼を設定する際に、同じパスワードを使用する必要があります。
    受信信頼を確認するように求められたら、No を選択します。
  4. 「信頼関係の作成」。ipa trust-add コマンドの実行時に、--type オプション、--trust-secret および --two-way=True オプションを使用し、--admin オプションを省略します。以下に例を示します。 
    [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
  5. ドメインの一覧を取得します。 
    [root@ipaserver ~]# ipa trust-fetch-domains ad_domain
  6. IdM サーバーで、ipa trust-show コマンドを使用して信頼関係が確立されていることを確認します。 
    [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
  7. 必要に応じて、信頼されたドメインを検索します。 
    [root@ipaserver ~]# ipa trustdomain-find ad.example.com
Domain name: ad.example.com
Domain NetBIOS name: AD
Domain Security Identifier: S-1-5-21-796215754-1239681026-23416912
Domain enabled: True
  8. の説明に従って、Kerberos 「Kerberos 設定の確認」。
5.2.2.2.2. 共有シークレットを使用した一方向の信頼の作成
Microsoft Windows Server 2012、2012 R2、または 2016 で共有シークレットを使用して一方向の信頼を作成するには、以下を実行します。
  1. に従って、信頼用に IdM 「信頼用の IdM サーバーの準備」。
  2. IdM および AD ホストが両方のドメインを解決できない DNS サーバーを使用している場合は、DNS ゾーンの転送を設定します。
    1. AD DNS サーバーを準備し、IdM ドメインのクエリーを IdM DNS サーバーに転送します。詳細はを参照してください 「AD での IdM ドメインに対する条件フォワーダーの作成」。
    2. AD ドメインのクエリーを AD DNS サーバーに転送するために、IdM DNS サーバーを準備します。詳細はを参照してください 「IdM での AD ドメイン用の正引きゾーンの作成」。
  3. Active Directory ドメインおよび信頼コンソールで信頼を設定します。
    1. ドメイン名を右クリックし、Properties を選択します。
    2. Trusts タブで、New Trust をクリックします。
    3. IdM ドメイン名を入力し、Next をクリックします。
    4. Forest trust を選択し、Next をクリックします。
    5. 一方向： incoming を選択し、Next をクリックします。
    6. このドメインのみを選択し、 次へ をクリックします。
    7. 共有シークレット(trust password) を入力し、Next をクリックします。
    8. 設定を確認し、次へ をクリックします。
    9. システムが受信信頼を確認するかどうかを求められたら、No を選択して、着信トラストを確認せず 、Next をクリックします。
    10. Finish をクリックします。
  4. 信頼関係を作成します。 
    [root@ipaserver ~]# ipa trust-add --type=ad --trust-secret ad.example.com
Shared secret for the trust: 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-1762709870-351891212-3141221786
  Trust direction: Trusting forest
  Trust type: Active Directory domain
  Trust status: Waiting for confirmation by remote side
    AD ドメインおよび Trusts コンソールで設定した共有シークレットを入力します。
  5. Active Directory ドメインおよび信頼コンソールで信頼を検証します。
    1. ドメイン名を右クリックし、Properties を選択します。
    2. Trusts タブで、このドメイン （着信信頼）ペインを信頼するドメインのドメインを選択して 、Properties をクリックします。
    3. Validate ボタンをクリックします。
    4. Yes を選択し、入力信頼を検証し、IdM admin ユーザーの認証情報を入力します。
  6. 信頼されたドメインの一覧を更新します。 
    [root@ipaserver ~]# ipa trust-fetch-domains ad.example.com
----------------------------------------------------------------------------------------
List of trust domains successfully refreshed. Use trustdomain-find command to list them.
----------------------------------------------------------------------------------------
----------------------------
Number of entries returned 0
----------------------------
  7. 信頼されるドメインを一覧表示します。 
    [root@ipaserver ~]# ipa trustdomain-find ad.example.com
  Domain name: ad.example.com
  Domain NetBIOS name: AD
  Domain Security Identifier: S-1-5-21-1762709870-351891212-3141221786
  Domain enabled: True
----------------------------
Number of entries returned 1
----------------------------
  8. 必要に応じて、IdM サーバーが AD ドメインからユーザー情報を取得できることを確認します。 
    [root@ipaserver ~]# getent passwd administrator@ad.example.com
administrator@ad.example.com:*:610600500:610600500:Administrator:/home/ad.example.com/administrator:

5.2.2.3. ID マッピングの確認

ID マッピングを確認するには、以下を実行します。
  1. Windows Active Directory ドメインコントローラー(DC)で以下のコマンドを実行して、最大 ID を表示します。 
    C:\> dcdiag /v /test:ridmanager /s:ad.example.com
...
Available RID Pool for the Domain is 1600 to 1073741823
...
  2. IdM サーバーの ID 範囲を一覧表示します。 
    [root@ipaserver ~]# ipa idrange-find
----------------
1 range matched
----------------
  Range name: AD.EXAMPLE.COM_id_range
  First Posix ID of the range: 610600000
  Number of IDs in the range: 200000
  First RID of the corresponding RID range: 0
  Domain SID of the trusted domain: S-1-5-21-796215754-1239681026-23416912
  Range type: Active Directory domain range
----------------------------
Number of entries returned 1
----------------------------
    後のステップで最初の POSIX ID 値が必要です。
  3. Active Directory DC で、セキュリティー識別子(SID)またはユーザーを表示します。たとえば、管理者の SID を表示するには、次のコマンドを実行します。 
    C:\> wmic useraccount where name="administrator" get sid
S-1-5-21-796215754-1239681026-23416912-500
    SID の最後の部分は、相対識別子(RID)です。次の手順でユーザーの RID が必要です。
    注記
    RID がデフォルトの ID 範囲(200000) よりも大きい場合は、ipa idrange-mod コマンドを使用して範囲を拡張します。以下に例を示します。 
    # ipa idrange-mod --range-size=1000000 AD.EXAMPLE.COM_id_range
  4. IdM サーバーにある同じユーザーのユーザー ID を表示します。 
    [root@ipaserver ~]# id ad\\administrator
uid=610600500(administrator@ad.example.com)...
  5. 最初の POSIX ID 値(610600000)を RID(500)に追加する場合は、IdM サーバー(610600500)で表示されるユーザー ID と一致する必要があります。

5.2.2.4. 既存の 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 操作を実行して、各エントリーに対して新しい 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 タスク）のステータスがゼロ(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.5. 2 番目の信頼の追加

1 つ以上の信頼関係がすでに設定された IdM サーバーに信頼を追加すると、信頼関連のパッケージのインストールや SID の設定など、一般的な IdM 信頼設定が必要になります。信頼を追加するには、DNS を設定し、信頼関係を確立する必要があります。

5.2.2.6. 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. ドメイン フィールドに AD ドメイン名を指定します。
    2. 信頼を双方向として設定する場合は、双方向の信頼 チェックボックスを選択します。信頼を一方向として設定する場合は、双方向の信頼を選択したままにします。
      「1 ウェイヤーと 2 時間の信頼」。
    3. 別のフォレストのドメインへの外部信頼を確立するには、External Trust チェックボックスを選択します。
      「Active Directory への外部の信頼」。
    4. セクションを使用して、Establish を使用して信頼を確立する方法を定義します。
      • AD 管理者のユーザー名とパスワードを使用して信頼を確立するには、Administrative account を選択し、必要な認証情報を指定します。
      • または、共有パスワードと信頼を確立するには、事前共有パスワードを選択し、信頼パスワードを入力します。
    5. 信頼の ID 設定を定義します。
      • Range type オプションでは、ID 範囲タイプを選択できます。IdM が使用する ID 範囲の種類を自動的に検出する場合は、Detect を選択します。
      • ID 範囲の開始 ID を定義するには、Base ID フィールドを使用します。ID 範囲のサイズを定義するには、Range size フィールドを使用します。IdM で ID 範囲のデフォルト値を使用する場合は、このオプションを指定してください。
      ID 「ID 範囲」。

    図5.5 Web UI での信頼の追加

    Web UI での信頼の追加
  5. Add をクリックして新しい信頼を保存します。
続いて、の説明に従って、Kerberos 「Kerberos 設定の確認」。

5.2.3. フォレスト間の信頼のインストール後の考慮事項

5.2.3.1. Active Directory 信頼に関する潜在的な動作の問題

5.2.3.1.1. Active Directory ユーザーおよび IdM の管理
現在、Active Directory(AD)ユーザーおよび管理者は、IdM Web UI にログインした後にのみセルフサービスページを表示できます。AD 管理者は、IdM Web UI の管理者のビューにアクセスできません。『詳細は、Linux_Domain_Identity_Authentication_and_Policy_Guide』 の該当するセクションを参照してください。
また、AD ユーザーは、現在独自の ID オーバーライドを管理できません。IdM ユーザーのみが、ID オーバーライドを追加および管理できます。
5.2.3.1.2. 削除された Active Directory ユーザーの認証
デフォルトでは、すべての IdM クライアントは SSSD サービスを使用してユーザー ID および認証情報をキャッシュします。IdM または AD バックエンドプロバイダーが一時的に利用できなくなると、SSSD により、ローカルシステムで正常にログインしたユーザーのアイデンティティーを参照できます。
SSSD はユーザーのリストをローカルで維持するため、バックエンドで加えられた変更は SSSD をオフラインで実行するクライアントに即座に表示されない可能性があります。このようなクライアントでは、IdM リソースにログインし、ハッシュ化されたパスワードが SSSD キャッシュに保存されているユーザーは、そのユーザーアカウントが AD で削除された場合でも再度ログインできます。
上記の条件が満たされると、ユーザー ID は SSSD にキャッシュされ、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 を使用して IdM リソースに接続する場合は、リソースチケットにプリンシパルが選択されません。IdM プリンシパルはリソースのレルム名と一致するため、IdM プリンシパルが使用されます。
たとえば、AD ユーザーが Administrator で、ドメインが ADEXAMPLE.ADREALM の場合、プリンシパルは ALM になります。 
[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 ユーザーに （adminなどの）Kerberos チケットがある場合は、別の IdM 認証情報キャッシュと、IdM のデフォルトプリンシパルがあります。Active Directory ユーザーが SSH を使用してリソースに接続する場合に、その IdM のデフォルトプリンシパルがホストチケットに選択されます。 
[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 キャッシュから削除します。
注記
Active Directory 信頼を使用するためには、net getlocalsid または net getdomainsid などのコマンドを実行する必要はありません。

ユーザーのグループメンバーシップを検証できません

信頼される特定のユーザーが特定の IdM グループ、外部、または POSIX に関連付けられていることを確認することはできません。

Active Directory ユーザーのリモート Active Directory グループメンバーシップの表示ができません。

重要
IdM サーバーおよびクライアントが Red Hat Enterprise Linux 7.1 以降で実行している場合は、この問題が発生しなくなりました。
id ユーティリティーを使用すると、Linux システムユーザーのローカルグループの関連付けを表示できます。ただし、Samba ツールに表示しても、id は Active Directory ユーザーの Active Directory グループメンバーシップを表示しません。
この問題を回避するには、ssh ユーティリティーを使用して、指定の AD ユーザーとして 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. トラストエージェントの設定

信頼環境に新しいレプリカを設定すると、レプリカには AD 信頼エージェントのロールが自動的にインストールされません。レプリカを信頼エージェントとして設定するには、次のコマンドを実行します。
  1. 既存の信頼コントローラーで、ipa-adtrust-install --add-agents コマンドを実行します。 
    [root@existing_trust_controller]# ipa-adtrust-install --add-agents
    このコマンドはインタラクティブな設定セッションを開始し、エージェントの設定に必要な情報の入力を求めるプロンプトを表示します。
    --add-agents オプションの詳細は、ipa-adtrust-install(1) の man ページを参照してください。
  2. 新しいレプリカで以下を行います。
    1. IdM サービスを再起動します。 
      [root@new_trust_controller]# ipactl restart
    2. SSSD キャッシュからすべてのエントリーを削除します。 
      [root@new_trust_controller]# sssctl cache-remove
      注記
      sssctl コマンドを使用するには、sssd-tools パッケージをインストールする必要があります。
    3. 必要に応じて、レプリカの AD 信頼エージェント ロールがインストールされていることを確認します。 
      [root@new_trust_controller]# ipa server-show new_replica.idm.example.com
...
Enabled server roles: CA server, NTP server, AD trust agent
このページには機械翻訳が使用されている場合があります (詳細はこちら)。