5.2. フォレスト間の信頼作成

5.2.1. 環境およびマシン要件

信頼関係を設定する前に、Active Directory と Identity Management の両方のサーバー、マシン、および環境が本セクション記載の要件および設定を満たしていることを確認してください。

5.2.1.1. サポートされる Windows プラットフォーム

以下のフォレストやドメイン機能レベルを使用する Active Directory フォレストで、信頼関係を確立することができます。
  • Windows Server 2016Windows Server 2012 R2
  • ドメイン機能レベルの範囲 - 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 の場合は ad.example.com、IdM の場合は idm.example.com
  • AD の場合は example.com、IdM の場合は idm.example.com
  • AD の場合は ad.example.com、IdM の場合は example.com

    重要

    IdM ドメインが AD ドメインの親ドメインである場合、IdM サーバーは Red Hat Enterprise Linux 7.5 以降で実行する必要があります。
最も便利な管理ソリューションは、各 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 名は Active Directory (AD) ドメインを識別するために重要です。IdM の場合は、IdM ドメインおよびサービスを特定するために、AD で構成された信頼があります。そのため、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 信頼に必要なポート

サービスポートプロトコル
エンドポイント解決ポートマッパー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
libkrb5 ライブラリーは UDP を使用し、Kerberos Distribution Center (KDC) から送信されたデータが大きすぎる場合は TCP プロトコルにフォールバックします。Active Directory が Privilege Attribute Certificate (PAC) を Kerberos チケットに割り当てます。これによりサイズが大きくなり、ほとんどの場合は TCP プロトコルを使用する必要があります。フォールバックと要求の再送信を回避するため、デフォルトでは、Red Hat Enterprise Linux 7.4 以降の SSSD は、ユーザー認証に TCP を使用します。libkrb5 が TCP を使用する前にサイズを構成するには、/etc/krb.5.conf ファイルで udp_preference_limit を設定します。詳細は、man ページのkrb5.conf(5)を参照してください。

その他のリソース

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. Store this conditional forwarder in Active Directory, and replicate it as follows を選択し、お使いの環境に一致するレプリケーション設定を選択します。
  5. OK をクリックします。
  6. AD ドメインコントローラー (DC) が IdM ドメインから DNS エントリーを解決できることを確認するには、コマンドプロンプトを開いて次のコマンドを入力します。 
    C:\> nslookup server.idm.example.com
    コマンドにより IdM サーバーの IP アドレスが返されると、条件付きフォワーダーが適切に機能していることになります。

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

IdM DNS サーバーを準備して、AD ドメインのクエリーを AD 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 サーバーとともにインストールされている場合は自動的に作成されます。
      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 サービスを起動します。 
    [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. 信頼合意の作成
  コマンドで 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) 内の一方向および双方向の信頼は、共有シークレットで設定できます。AD 内では、共有シークレットは信頼の設定内に 信頼される側のドメインオブジェクト (TDO) として保存されます。
IdM は、AD 管理者認証情報の代わりに共有シークレットを使用した一方向または双方向の信頼の作成をサポートしています。この方法で信頼を設定するには、管理者が AD に共有シークレットを作成し、AD 側で信頼を手動で確認する必要があります。
5.2.2.2.1. 共有シークレットを使用した双方向の信頼の作成
Windows Server 2012、2012 R2、または 2016 で、共有シークレットを使用して双方向の信頼を作成するには、以下を行います。
  1. 「信頼向けに IdM サーバーを準備する」 にあるように、信頼向けに IdM サーバーを準備します。
  2. IdM および AD ホストが両方のドメインを解決できない DNS サーバーを使用する場合は、DNS ゾーンへの転送を設定します。
    1. IdM ドメインのクエリーを IdM DNS サーバーに転送するために AD DNS サーバーを準備します。詳細は「AD 内の IdM ドメイン用の条件フォワーダーの作成」を参照してください。
    2. AD ドメインのクエリーを AD DNS サーバーに転送するために IdM DNS サーバーを準備します。詳細は、「IdM で AD ドメインへの正引きゾーンの作成」を参照してください。
  3. Active Directory Domains and Trusts コンソールで信頼を設定します。具体的には、以下を行います。
    • 新規の信頼を作成します。
    • 信頼に、idm.example.comなどの IdM ドメイン名を指定します。
    • 信頼の forest タイプであることを指定します。
    • 信頼の two-way タイプであることを指定します。
    • forest-wide の認証であることを指定します。
    • Trust Password を設定します。

      注記

      IdM 内で信頼を設定する際には、同じパスワードを使用する必要があります。
    着信の信頼の確認を求められたら、No を選択します。
  4. 「信頼合意の作成」 にあるように、信頼の合意を作成します。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
  5. ドメインの一覧を取得します。 
    [root@ipaserver ~]# ipa trust-fetch-domains ad_domain
  6. 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
  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. 共有シークレットを使用した一方向の信頼の作成
Windows Server 2012、2012 R2、または 2016 で、共有シークレットを使用して一方向の信頼を作成するには、以下を行います。
  1. 「信頼向けに IdM サーバーを準備する」 にあるように、信頼向けに IdM サーバーを準備します。
  2. IdM および AD ホストが両方のドメインを解決できない DNS サーバーを使用する場合は、DNS ゾーンへの転送を設定します。
    1. IdM ドメインのクエリーを IdM DNS サーバーに転送するために AD DNS サーバーを準備します。詳細は「AD 内の IdM ドメイン用の条件フォワーダーの作成」を参照してください。
    2. AD ドメインのクエリーを AD DNS サーバーに転送するために IdM DNS サーバーを準備します。詳細は、「IdM で AD ドメインへの正引きゾーンの作成」を参照してください。
  3. Active Directory Domains and Trusts コンソールで信頼を設定します。
    1. ドメイン名を右クリックし、Properties を選択します。
    2. Trusts タブで New Trust をクリックします。
    3. IdM ドメイン名を入力し、Next をクリックします。
    4. Forest trust を選択して Next をクリックします。
    5. One-way: incoming を選択し、Next をクリックします。
    6. This domain only を選択し、Next をクリックします。
    7. 共有シークレット (信頼パスワード) を入力して、Next をクリックします。
    8. 設定を確認し、Next をクリックします。
    9. システムが、着信の信頼を確認するかどうかを求められたら、No, do not confirm the incoming trust を選択し、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 ドメインおよび信頼コンソールで設定した共有秘密を入力します。
  5. Active Directory Domains and Trusts コンソールで信頼を検証します。
    1. ドメイン名を右クリックし、Properties を選択します。
    2. Trusts タブの、Domains that trust this domain (incoming trusts) pane でこのドメインを選択し、Properties をクリックします。
    3. Validate ボタンをクリックします。
    4. Yes, validate the incoming trust を選択して、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 で、セキュリティー ID (SID) またはユーザーを表示します。たとえば、administrator の 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 操作を実行して、各エントリーごとに、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.5. 2 つ目の信頼の追加

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

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. 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. 信頼エージェントの設定

信頼環境で新しいレプリカを設定したら、レプリカには自動的に AD 信頼エージェント ロールがインストールされていません。レプリカを信頼エージェントとして設定するには、以下を実行します。
  1. 既存の信頼コントローラーで、ipa-adtrust-install --add-agents コマンドを実行します。 
    [root@existing_trust_controller]# ipa-adtrust-install --add-agents
    このコマンドは、対話型の設定セッションを開始し、エージェントの設定に必要な情報の入力を求めるプロンプトを表示します。
    --add-agents オプションの詳細は、man ページの ipa-adtrust-install(1) を参照してください。
  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
このページには機械翻訳が使用されている場合があります (詳細はこちら)。