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 が、ID 管理用の別のシステムとプライマリー 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 ドメインと重複できません。プライマリー IdM DNS ドメインには、AD 信頼に対応するのに適切な SRV レコードが必要です。
注記
IdM と Active Directory との間の信頼がある一部の環境では、Active Directory DNS ドメインの一部であるホストに IdM クライアントをインストールできます。ホストは、これにより、Linux に焦点を合わせた IdM の機能の恩恵を受けることができます。これは推奨される設定ではなく、いくつかの制限があります。Red Hat は、Active Directory が所有する DNS ゾーンとは異なる DNS ゾーンに常に IdM クライアントを展開し、IdM ホスト名を介して IdM クライアントにアクセスすることをお勧めします。
$ 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. 「信頼用の IdM サーバーの準備」 で説明されているように、ipa-adtrust-install ユーティリティーの実行後に、UDP サービスレコード上の MS DC Kerberos、および TCP サービスレコード上の LDAP に 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 のサービスレコードを解決できることを確認します。
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. 「信頼用の IdM サーバーの準備」 で説明されているように、ipa-adtrust-install ユーティリティーの実行後に、UDP サービスレコード上の MS DC Kerberos、および TCP サービスレコード上の LDAP に 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. 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
    予期される出力には、IdM が AD のサービスレコードを解決できることを確認します。 で表示されるのと同じ AD サーバーのセットが含まれます。

5.2.1.3. NetBIOS 名

NetBIOS 名は、Active Directory (AD) ドメインを識別するために重要であり、IdM に AD で設定された信頼がある場合は、IdM ドメインとサービスを識別するために重要です。結果として、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 信頼に必要なポート

Service ポート プロトコル
エンドポイント解決ポートマッパー 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 サーバーで必要なポート

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

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

Service ポート プロトコル 備考
Kerberos 88 UDP および TCP
libkrb5 ライブラリーは UDP を使用し、KDC (Kerberos Distribution Center) から送信されるデータが大きすぎると、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 ページを参照してください。

関連情報

  • 必要なポートを開く方法は、『Linux ドメイン ID、認証、およびポリシーガイド』 の ポート要件 を参照してください。

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>[^@\\]+)$))