Red Hat Training

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

5.3. フォレスト間の信頼環境の管理および設定

5.3.1. 信頼できるドメイン環境内のユーザープリンシパル名

IdM は、ユーザープリンシパル名(UPN)を使用したログインに対応しています。UPN は、認証に使用するユーザー名の代替で、形式は username@KERBEROS-REALM です。Active Directory フォレストでは、追加の UPN サフィックスを設定できます。このエンタープライズプリンシパル名は、デフォルトの UPN の代替ログインを提供するために使用されます。
たとえば、ある会社が AD.EXAMPLE.COM Kerberos レルムを使用する場合に、ユーザーのデフォルトの UPN は です。ただし、ある企業は、ユーザーが などのメールアドレスを使用してログインできるようにしたいことが多くあります。この場合、管理者は追加の UPN サフィックス example.com を Active Directory フォレストに追加し、ユーザーのアカウントプロパティーに新しい接尾辞を設定します。
UPN サフィックスは、AD フォレストルートで定義された場合に IdM にだけ表示されます。AD 管理者は、Active Directory Domain and Trust ユーティリティーまたは PowerShell コマンドラインツールで UPN を定義できます。
注記
Red Hat は、ユーザーへの UPN サフィックスを設定するには、Active Directory Domain and Trust ユーティリティーなどのエラー検証を実行するツールを使用することを推奨します。
Active Directory ではこのような操作は検証されないため、ldapmodify コマンドを使用してユーザーの userPrincipalName 属性を設定するなど、低レベルの変更で UPN を設定することを推奨します。
信頼された AD フォレストで UPN サフィックスを追加または削除する場合は、IdM マスターで信頼されるフォレストの情報を更新する必要があります。
[root@ipaserver ~]# ipa trust-fetch-domains
Realm-Name: ad.example.com
-------------------------------
No new trust domains were found
-------------------------------
----------------------------
Number of entries returned 0
----------------------------
以下を実行して、別の UPN がフェッチされていることを確認します。
[root@ipaserver ~]# ipa trust-show
Realm-Name: ad.example.com
  Realm-Name: ad.example.com
  Domain NetBIOS name: AD
  Domain Security Identifier: S-1-5-21-796215754-1239681026-23416912
  Trust direction: Two-way trust
  Trust type: Active Directory domain
  UPN suffixes: example.com
ドメインの UPN サフィックスは、cn=trusted_domain_name,cn=ad,cn=trusts,dc=idm,dc=example,dc=com サブツリーの ipaNTAdditionalSuffixes 複数値属性に保存されます

5.3.2. Active Directory DNS ドメインの IdM クライアント

IdM と Active Directory との間の信頼を使用する一部の環境では、Active Directory DNS ドメインのホスト名を使用して IdM クライアントにアクセスするようにユーザーを設定できますが、クライアント自体は IdM に参加して、Linux の中心となる機能を活用できます。
重要
これは推奨される設定ではなく、いくつかの制限があります。Red Hat は、Active Directory が所有し、IdM ホスト名を介して IdM クライアントにアクセスする DNS ゾーンとは異なる DNS ゾーンに IdM クライアントを常にデプロイすることを推奨します。

5.3.2.1. IdM クライアントに Kerberos シングルサインオンは必要ありません。

Active Directory DNS ドメインで設定されている IdM クライアントでは、この IdM ホストのリソースにアクセスするには、パスワード認証のみを使用できます。このシナリオ向けにクライアントを設定するには、以下を行います。
  1. クライアントの System Security Service Daemon(SSSD)が IdM サーバーと通信できるようにするには、IdM クライアントを --domain=IPA_DNS_Domain オプションでインストールします。
    [root@idm-client.ad.example.com ~]# ipa-client-install --domain=idm.example.com
    このオプションは、Active Directory DNS ドメインの SRV レコード自動検出を無効にします。
  2. /etc/krb5.conf 設定ファイルの [domain_realm] セクションで、Active Directory ドメインの既存のマッピングを見つけます。
    .ad.example.com = IDM.EXAMPLE.COM
    ad.example.com = IDM.EXAMPLE.COM
    両方の行を、Active Directory DNS ゾーンの Linux クライアントの完全修飾ドメイン名(FQDN)のマッピングエントリーを、IdM レルムに置き換えます。
    idm-client.ad.example.com = IDM.EXAMPLE.COM
    デフォルトのマッピングを置き換えると、Kerberos が Active Directory ドメインの要求を IdM Kerberos Distribution Center(KDC)に送信できなくなります。代わりに、Kerberos は SRV DNS レコードを介して自動検出を使用し、KDC を見つけます。IdM KDC が設定されているのは、追加されたホスト idm-client.ad.example.com だけです。
注記
IdM が所有する DNS ゾーンには含まれないクライアントのリソースに対する認証は、ユーザー名とパスワードを使用する場合にのみ可能です。

SSL 証明書の処理

SSL ベースのサービスでは、元の(A/AAAA)と CNAME レコードの両方が証明書に含まれる必要があるため、システムホスト名をすべてカバーする dNSName 拡張機能を持つ証明書が必要になります。現在、IdM は、IdM データベースのオブジェクトをホストするオブジェクトにのみ証明書を発行します。
シングルサインオンが利用可能でない説明では、IdM にはデータベースに FQDN のホストオブジェクトがすでにあり、certmonger はこの名前の証明書を要求できます。
[root@idm-client.ad.example.com ~]# ipa-getcert request -r \
      -f /etc/httpd/alias/server.crt \
      -k /etc/httpd/alias/server.key \
      -N CN=ipa-client.ad.example.com \
      -D ipa-client.ad.example.com \
      -K host/idm-client.ad.example.com@IDM.EXAMPLE.COM \
      -U id-kp-serverAuth
certmonger サービスは、/etc/krb5.keytab ファイルに保存されているデフォルトのホスト鍵を使用して、IdM 認証局(CA)に対して認証します。

5.3.2.2. IdM クライアントに Kerberos シングルサインオンが必要である

IdM クライアントのリソースにアクセスするのに Kerberos シングルサインオンが必要な場合、クライアントは idm-client.idm.example.com などの IdM DNS ドメイン内になければなりません。IdM クライアントの A/AAAA レコードを参照する Active Directory DNS ドメインに、CNAME レコード idm-client.ad.example.com を作成する必要があります。
Kerberos ベースのアプリケーションサーバーの場合、MIT Kerberos はアプリケーションのキータブで利用可能なホストベースのプリンシパルの受け入れを可能にする方法をサポートします。Kerberos サーバーのターゲットに使用された Kerberos プリンシパルに対して厳密なチェックを無効にするには、/etc/krb5.conf 設定ファイルの [libdefaults] セクションに以下のオプションを設定します。
ignore_acceptor_hostname = true

SSL 証明書の処理

SSL ベースのサービスでは、元の(A/AAAA)と CNAME レコードの両方が証明書に含まれる必要があるため、システムホスト名をすべてカバーする dNSName 拡張機能を持つ証明書が必要になります。現在、IdM は、IdM データベースのオブジェクトをホストするオブジェクトにのみ証明書を発行します。
シングルサインオンが利用可能でない説明では、IdM にはデータベースに FQDN のホストオブジェクトがすでにあり、certmonger はこの名前の証明書を要求できます。
  1. 新規ホストオブジェクトを作成します。
    [root@idm-server.idm.example.com ~]# ipa host-add idm-client.ad.example.com --force
    ホスト名は CNAME であり、A/AAAA レコードではなく、--force オプションを使用します。
  2. IdM DNS ホスト名が、IdM データベースの Active Directory ホストエントリーを管理できるようにします。
    [root@idm-server.idm.example.com ~]# ipa host-add-managedby idm-client.ad.example.com \
          --hosts=idm-client.idm.example.com
この設定では、IdM クライアントは、Active Directory DNS ドメイン内のホスト名に対して dNSName 拡張レコードが含まれる SSL 証明書を要求できます。
[root@idm-client.idm.example.com ~]# ipa-getcert request -r \
      -f /etc/httpd/alias/server.crt \
      -k /etc/httpd/alias/server.key \
      -N CN=`hostname --fqdn` \
      -D `hostname --fqdn` \
      -D idm-client.ad.example.com \
      -K host/idm-client.idm.example.com@IDM.EXAMPLE.COM \
      -U id-kp-serverAuth

5.3.3. Active Directory ユーザー用の IdM グループの作成

ユーザーグループは、IdM ユーザーに対するアクセスパーミッション、ホストベースのアクセス制御、sudo ルール、その他の制御の設定に必要です。このグループは、IdM ドメインリソースへのアクセスと、アクセスの制限です。
AD ユーザーと AD グループの両方が、IdM ユーザーグループに直接追加できます。これには、最初に AD ユーザーまたはグループを POSIX 以外の IdM の外部グループに追加し、次にローカルの IdM POSIX グループに追加します。その後、POSIX グループは、AD ユーザーのユーザーおよびロール管理に使用できます。IdM で非 POSIX グループを処理する原則は、「Active Directory ユーザーおよび Identity Management グループ」
注記
AD ユーザーグループをメンバーとして IdM 外部グループに追加することもできます。これにより、1 つの AD レルム内でユーザーおよびグループの管理を維持することで、Windows ユーザーのポリシーを定義しやすくなります。
  1. 任意です。IdM レルムで AD ユーザーを管理するのに使用する AD ドメインでグループを作成または選択します。IdM 側では、複数のグループを使用でき、複数のグループを異なるグループに追加できます。
  2. --external オプションを ipa group-add コマンドに追加して、Active Directory ユーザーの IdM ドメインに外部グループを作成します。--external オプションは、このグループに IdM ドメイン外からのメンバーが含まれることを示します。以下に例を示します。
    [root@ipaserver ~]# ipa group-add --desc='AD users external map' ad_users_external --external
    -------------------------------
    Added group "ad_users_external"
    -------------------------------
      Group name: ad_users_external
      Description: AD users external map
    注記
    外部グループはユーザーのプライマリーグループではなく、追加のユーザーグループにリンクする必要があります。Active Directory はグループのメンバーをグループの member 属性に保存し、IdM はこの属性を使用してメンバーを解決します。ただし、Active Directory はユーザーのエントリーにある primaryGroupID 属性にユーザーのプライマリーグループを保存しますが、これは解決されません。
  3. 新しい IdM POSIX グループを作成するか、既存のグループを選択して、IdM ポリシーを管理します。たとえば、新規グループを作成するには、次のコマンドを実行します。
    [root@ipaserver ~]# ipa group-add --desc='AD users' ad_users
    ----------------------
    Added group "ad_users"
    ----------------------
      Group name: ad_users
      Description: AD users
      GID: 129600004
  4. AD ユーザーまたはグループを外部メンバーとして追加します。AD メンバーは、DOMAIN\group_name または DOMAIN\username などの完全修飾名によって識別されます。AD アイデンティティーは、ユーザーまたはグループの Active Directory SID にマッピングされます。
    たとえば、AD グループの場合は、以下のようになります。
    [root@ipaserver ~]# ipa group-add-member ad_users_external --external "AD\Domain Users"
     [member user]:
     [member group]:
      Group name: ad_users_external
      Description: AD users external map
      External member: S-1-5-21-3655990580-1375374850-1633065477-513 SID_DOM_GROUP (2)
    -------------------------
    Number of members added 1
    -------------------------
  5. 外部 IdM グループをメンバーとして追加します。以下に例を示します。
    [root@ipaserver ~]# ipa group-add-member ad_users --groups ad_users_external
      Group name: ad_users
      Description: AD users
      GID: 129600004
      Member groups: ad_users_external
    -------------------------
    Number of members added 1
    -------------------------

5.3.4. 信頼の維持

信頼管理には、グローバル信頼の設定、Kerberos 信頼設定、DNS レルム設定、ID 範囲の割り当てなど、複数のエリアが関係します。

5.3.4.1. グローバル信頼設定の編集

ipa-adtrust-install ユーティリティーは、Active Directory ドメインで信頼の作成に必要な IdM ドメインのバックグラウンド情報を自動的に設定します。
グローバルの信頼設定には、5 つの属性が含まれます。
  • Windows スタイルのセキュリティー ID (SID): 自動生成され、変更できません。
  • ドメイン GUID: 自動生成され、変更できません。
  • Kerberos ドメイン名: IdM 設定から取得され、変更できません。
  • IdM ユーザーを追加するデフォルトのグループ: 変更可能です。
  • NetBIOS 名。この属性を変更することは推奨されません
信頼設定は cn=domain,cn=ad,cn=etc,dc=example,dc=com サブツリーに保存されます。
5.3.4.1.1. NetBIOS 名の変更
重要
ほとんどの場合で NetBIOS 名を変更するには、既存の信頼をすべて再度確立する必要があります。したがって、Red Hat では、属性を変更しないことを推奨します。
ipa-adtrust-install ユーティリティーの実行時に、Active Directory トポロジー内で互換性のある NetBIOS 名が IdM サーバーに対して設定されます。後で変更するには、ipa-adtrust-install を再度実行し、--netbios-name オプションを使用して新しい NetBIOS 名を指定します。
[root@ipaserver ]# ipa-adtrust-install --netbios-name=NEWBIOSNAME
5.3.4.1.2. Windows ユーザーのデフォルトグループの変更
Identity Management が Active Directory フォレストを信頼するように設定されている場合、MS-PAC レコードが IdM ユーザーの Kerberos チケットに追加されます。MS-PAC レコードには、IdM ユーザーが属するグループのセキュリティー識別子(SID)が含まれます。IdM ユーザーのプライマリーグループに SID が割り当てられていない場合、デフォルトの SMB グループに定義されたセキュリティー識別子の値が使用されます。AD ドメインコントローラーが IdM 信頼コントローラーからユーザー情報を要求すると、同じロジックが Samba スイートにより適用されます。
デフォルトの SMB グループは、ipa-adtrust-install ユーティリティーにより自動作成されるフォールバックグループです。デフォルトのグループを削除できませんが、グローバル信頼設定を使用して、IdM ユーザーのプライマリーグループのフォールバックとして使用する別の IdM グループを指定できます。
コマンドラインからデフォルトグループを設定するには、ipa trustconfig-mod コマンドを使用します。
[root@server ~]# kinit admin
[root@server ~]# ipa trustconfig-mod --fallback-primary-group="Example Windows Group"
IdM Web UI からデフォルトグループを設定するには、以下を行います。
  1. IdM Web UI を開きます。
    https://ipaserver.example.com
  2. IPA Server メインタブで Trusts サブタブを選択し、Global Configuration セクションを開きます。
  3. フォールバック プライマリーグループ のドロップダウンリストで、すべての IdM グループから新しいグループを選択します

    図5.6 Windows ユーザーのデフォルトグループの設定

    Windows ユーザーのデフォルトグループの設定
  4. Save をクリックして、新しい設定を保存します。

5.3.4.2. 信頼ドメインの検出、有効化、および無効化

推移的な信頼は、信頼パスがドメインのチェーンに従うことができることを意味します。詳細については、「信頼関係のアーキテクチャー」
IdM にはフォレストのルートドメインとの信頼があり、その結果、同じフォレストからの子ドメインおよびその他のドメインはすべてその信頼に含まれます。IdM は、フォレスト内の IdM リソースへのアクセスを試みる場所から Windows ユーザーとしてトポロジーに従います。各ドメインと子ドメインは、IdM 信頼設定の信頼ドメインです。各ドメインは、信頼サブツリーの独自のエントリー (cn=subdomain,cn=trust_name,cn=ad,cn=trusts,dc=example,dc=com )に保存されます。
信頼の初回セットアップ時に、IdM は完全な Active Directory トポロジーを検出してマッピングしようとします。ただし、場合によっては、 が必要か、そのトポロジーを手動で取得するのが有益です。これは、trust-fetch-domains コマンドで行います。
[root@ipaserver ~]# kinit admin
[root@ipaserver ~]# ipa trust-fetch-domains ad.example.com
--------------------------------------------
List of trust domains successfully refreshed
--------------------------------------------
  Realm name: test.ad.example.com
  Domain NetBIOS name: TEST
  Domain Security Identifier: S-1-5-21-87535643-5658642561-5780864324

  Realm name: users.ad.example.com
  Domain NetBIOS name: USERS
  Domain Security Identifier: S-1-5-21-91314187-2404433721-1858927112

  Realm name: prod.ad.example.com
  Domain NetBIOS name: PROD
  Domain Security Identifier: S-1-5-21-46580863-3346886432-4578854233
----------------------------
Number of entries returned 3
----------------------------
注記
共有シークレットを使用して信頼を追加する場合は、AD フォレストのトポロジーを手動で取得する必要があります。ipa trust-add ad.domain --trust-secret コマンドを実行すると、AD ドメインおよび Trusts ツールのフォレスト信頼プロパティーを使用して、AD 側で着信信頼を検証します。次に、ipa trust-fetch-domains ad.domain コマンドを実行します。IdM は、使用できる信頼に関する情報を受け取ります。
トポロジーが(自動または手動検出)取得されると、そのトポロジーの個々のドメインおよび子ドメインを、IdM 信頼設定内で有効、無効、または削除できます。
たとえば、IdM リソースの使用から特定の子ドメインからユーザーを許可できるようにするには、その信頼ドメインを無効にします。
[root@ipaserver ~]# kinit admin
[root@ipaserver ~]# ipa trustdomain-disable test.ad.example.com
------------------------------------------
Disabled trust domain "test.ad.example.com"
------------------------------------------
trustdomain-enable コマンドを使用して信頼ドメインを再度有効にできます。
ドメインをトポロジーから永続的に削除する必要がある場合は、IdM 信頼設定からドメインを削除できます。
[root@ipaserver ~]# kinit admin
[root@ipaserver ~]# ipa trustdomain-del prod.ad.example.com
-------------------------------------------------------------------
Removed information about the trusted domain " "prod.ad.example.com"
-------------------------------------------------------------------

5.3.4.3. IdM Kerberos レルムに関連付けられたドメインの表示および管理

IdM Kerberos レルムに関連付けられているドメインは、IdM ディレクトリーの cn=Realm ドメイン,cn=ipa,cn=etc,dc=example,dc=com サブツリーに保存されます。ドメインの一覧は、Active Directory との信頼を確立する際に IdM により使用されます。IdM が管理するドメインの全一覧を確認すると、AD ドメインコントローラーは、IdM KDC にルーティングする認証要求を把握できます。realmdomains-show コマンドを使用して、IdM レルムに関連付けられた設定したドメインの一覧を表示できます。
[root@ipaserver ~]# kinit admin
[root@ipaserver ~]# ipa realmdomains-show
Domain: ipa.example.org, ipa.example.com, example.com
統合 DNS のある IdM 設定では、以下を実行します。
  • ipa dnszone-add コマンドを使用して、新しい DNS ゾーンが IdM に追加されると、ドメイン一覧に自動的にドメイン一覧に追加されます。ipa realmdomains-show を実行すると、IdM KDC が制御するドメインの一覧に新しいドメインが表示されます。
    # kinit admin
    # ipa dnszone-add ipa2.example.com
    # ipa realmdomains-show
    Domain: ipa.example.org, ipa.example.com, example.com, ipa2.example.com
    また、IdM Kerberos レルムに関連付けられたドメインの変更およびその他のタイプが自動的に処理されます。
統合 DNS のない IdM 設定では、以下を行います。
  • IdM Kerberos レルムに、DNS ゾーンが追加されると、IdM KDC の制御下にあるドメイン一覧の IdM 一覧に、新しいドメインを手動で追加する必要があります。--add-domain オプションを指定して ipa realmdomains-mod コマンドを使用して、新しいドメインを追加します。
    [root@ipaserver ~]# kinit admin
    [root@ipaserver ~]# ipa realmdomains-mod --add-domain=ipa2.example.com
    Domain: ipa.example.org, ipa.example.com, example.com, ipa2.example.com
    DNS ゾーンが削除された場合は、IdM Kerberos レルムに関連付けられたドメインを手動で削除する必要があります。
    [root@ipaserver ~]# kinit admin
    [root@ipaserver ~]# ipa realmdomains-mod --del-domain=ipa2.example.com
    Domain: ipa.example.org, ipa.example.com, example.com
    ドメインの一覧に変更を加える場合は、リスト自体を変更し、--domain オプションを使用して置き換えることができます
    [root@ipaserver ~]# ipa realmdomains-mod --domain={ipa.example.org,ipa2.example.com}

5.3.4.4. UID および GID 番号の範囲を Transitive Trust に追加する

信頼の初回設定時の時の ID 「ID 範囲」。後で ID 範囲を追加するには、ipa idrange-add コマンドに以下のオプションを使用します。
  • --base-id オプションは、POSIX 範囲のベース ID を設定します(開始数)。
  • --range-size オプションは、IdM が使用する POSIX ID 範囲のサイズを設定します。IdM は、信頼された AD ドメインのユーザーおよびグループの RID を POSIX ID にマッピングします。--range-size オプションは、IdM が作成する ID の最大数を定義します。AD は、作成するユーザーおよびグループごとに新しい RID を使用します。ユーザーまたはグループを削除すると、AD は今後の AD エントリーに RID を再使用しません。したがって、IdM が ID を既存の AD ユーザーおよびグループに割り当てるのに十分な大きさと、今後作成する範囲が必要になります。たとえば、管理者が 20000 の 50000 AD ユーザーを削除し、時間が 10000 個の新しいアカウントを作成する場合は、この範囲は少なくとも 60000 に設定する必要があります。ただし、範囲に十分な予約が含まれることが重要です。大規模な環境では、デフォルトの(200000) の範囲サイズが十分ではないので、--range-size を高い値に設定します。
  • --rid-base オプションは、RID の開始番号(SID 内の右端にある数字)を設定します。この値は、競合を防ぐためにベース ID に追加する範囲を表します。
  • 信頼に対して複数のドメインを設定する可能性があるため、--dom-sid オプションはドメイン SID を設定します。
以下の例では、ベース ID は 1,200,000 で、RID は 1,000 です。結果の ID 番号は 1,201,000 になります。
[root@server ~]$ kinit admin
[root@server ~]$ ipa idrange-add --base-id=1200000 --range-size=200000 --rid-base=0 --dom-sid=S-1-5-21-123-456-789 trusted_dom_range
重要
手動で定義した ID 範囲が、IdM が使用する ID 範囲と重複しないようにします。

5.3.4.5. DNA ID 範囲の手動調整

場合によっては、機能していないレプリカに割り当てられた DNA ID 範囲を回復したり、ID が不足した範囲を拡張するなど、既存レプリカの Distributed Numeric Assignment(DNA)の ID 範囲を手動で調整する必要がある場合があります。
DNA ID 範囲を手動で調整する場合は、新たに調整した範囲が IdM ID 範囲に含まれていることを確認してください。これは、ipa idrange-find コマンドを使用して確認できます。調整した範囲が IdM ID 範囲に含まれていない場合には、コマンドは失敗します。
機能していないレプリカから DNA ID 範囲を復元するには、ipa-replica-manage dnarange-show コマンドを使用して、現在割り当てられている DNA 範囲を表示します。現在割り当てられている on-deck DNA 範囲を表示するには、ipa-replica-manage dnanextrange-show コマンドを使用します。
重要
重複する ID 範囲を作成しません。サーバーまたはレプリカに割り当てる ID 範囲のいずれかが重複すると、2 つの異なるサーバーにより、異なるエントリーに同じ ID 値を割り当てる可能性があります。
指定のサーバーの現在の DNA ID 範囲を定義するには、ipa-replica-manage dnarange-set コマンドを使用します。
# ipa-replica-manage dnarange-set masterA.example.com 1250-1499
指定のサーバーの次の DNA ID 範囲を定義するには、ipa-replica-manage dnanextrange-set コマンドを使用します。
# ipa-replica-manage dnanextrange-set masterB.example.com 1500-5000

5.3.4.6. サービスおよびホストの Kerberos フラグ

信頼ドメインのサービスまたはホストにアクセスするには、Kerberos の TGT(Ticket-granting Ticket)に特別なフラグが必要になる場合があります。たとえば、AD クライアントから Active Directory(AD)アカウントを持つ IdM クライアントへのシングルサインオンでログインする場合は、Kerberos TGT フラグ OK_AS_DELEGATE が必要です。
Kerberos フラグの設定方法に関する詳細は、『Linux ドメイン 『 ID、認証、およびポリシーガイド』の「サービスおよびホストの Kerberos フラグ 」を参照してください』。

5.3.5. サービスの PAC タイプの設定

IdM リソースでは、Active Directory ユーザーがサービスのチケットを要求すると、IdM は要求を Active Directory に転送すると、ユーザー情報を取得します。ユーザーの Active Directory グループ割り当てに関連付けられたアクセスデータには、Active Directory が送り返され、Kerberos チケットに組み込まれます。
Active Directory のグループ情報は、特権アクセス証明書または MS-PAC と呼ばれる特別なデータセットで、Active Directory ユーザーの各 Kerberos チケットのリストに保存されます。PAC のグループ情報は、Active Directory グループにマッピングしてから、対応する IdM グループにマッピングして、アクセスを判断できるようにします。
IdM サービスは、ユーザーがドメインサービスへの認証を初めて試行する際に、認証要求ごとに PAC を生成するように設定できます。

5.3.5.1. デフォルトの PAC タイプの設定

IdM サーバー設定は、サービスにデフォルトで生成される PAC タイプを定義します。グローバル設定は、特定のサービスのローカル設定を変更することで上書きできます。
  1. IPA Server タブを開きます。
  2. Configuration サブタブを選択します。
  3. Service Options エリアまでスクロールします。

    図5.7 サービスオプションエリア

    サービスオプションエリア
  4. PAC を使用するには、AD サービスが使用できる証明書を追加する MS-PAC チェックボックスを選択します。チェックボックスが選択されていない場合は、Kerberos チケットに PAC が追加されません。
    nfs:NONE チェックボックスを選択すると、MS-PAC レコードは NFS サーバーに対して発行されたサービスチケットには追加されません。
    注記
    PAD チェックボックスは無視できます。この機能は、IdM ではまだ利用できません。
  5. 変更を保存するには、ページの上部にある Update リンクをクリックします。

5.3.5.2. サービスの PAC タイプの設定

グローバルポリシーは、そのサービスに明示的に設定されていない場合にサービスに使用する PAC タイプを設定します。ただし、グローバル設定は、ローカルサービス設定で上書きできます。
コマンドラインから PAC 設定を変更するには、ipa service-mod コマンドに --pac-type オプションを指定して使用します。このコマンドの使用方法についての情報は、追加した --help オプションを指定して実行します。
$ ipa service-mod --help
Usage: ipa [global-options] service-mod PRINCIPAL [options]

Modify an existing IPA service.
Options:
-h, --help            show this help message and exit
...
Web UI で PAC 設定を変更するには、以下を実行します。
  1. Identity タブを開き、Services サブタブを選択します
  2. 編集するサービスの名前をクリックします。
  3. Service Settings エリアで Override inherited settings オプションを選択し、MS-PAC を選択して AD サービスが使用できる証明書を追加します。

    図5.8 サービス設定エリア

    サービス設定エリア
    チェックボックスが選択されていない場合は、Kerberos チケットに PAC が追加されません。
    注記
    PAD チェックボックスは無視できます。この機能は、IdM ではまだ利用できません。
  4. 変更を保存するには、ページの上部にある Update リンクをクリックします。

5.3.6. Active Directory で定義された POSIX 属性の使用

5.3.6.1. Active Directory ユーザーの UID および GID 属性の定義

Windows 管理者がユーザーの POSIX UID および GID 属性を手動で定義する場合は、ユーザーの GID で同じ GID を使用して、IdM サーバーに一致するグループを作成します。
グループを作成すると、ユーザーがプライマリーユーザーグループに関連付けられます。そのようなグループが存在しない場合は、IdM サーバーはユーザーが属するすべてのグループを検索できません。

5.3.6.2. ログインシェルおよびホームディレクトリー属性の転送

重要
この機能を活用するには、Red Hat Enterprise Linux 7.1 以降をベースにした IdM サーバーにクライアントを登録しておく必要があります。
SSSD は、IdM との信頼関係の Active Directory サーバーから次の属性値を読み取りできます。
  • AD ユーザーのシェルを指定する loginShell 属性
  • AD ユーザーのホームディレクトリーを指定する unixHomeDirectory 属性
このような属性を使用して、カスタムのシェルまたはホームディレクトリーの値が AD サーバーに定義されていると、カスタムの値が、AD ユーザーの IdM クライアントに表示されます。したがって、AD 側と IdM 側の両方で、同じユーザーシェルが AD ユーザーに表示されます。
AD ユーザーのホームディレクトリーを IdM クライアントに表示するには、IdM サーバーの /etc/sssd/sssd.conf ファイルの [domain] セクションの subdomain_homedir オプションを %o に設定する必要があります。%o の値は、アイデンティティープロバイダーから取得したホームディレクトリーを表します。以下に例を示します。
[domain/example.com]
subdomain_homedir = %o
AD 管理者が AD 側で loginShell または unixHomeDirectory を変更すると、変更が IdM 側で自動的に反映されます。AD サーバーで属性が定義されていない場合は、SSSD はテンプレートのデフォルト値を使用します。このデフォルト値は IdM クライアントに表示されます。

5.3.7. IdM リソースの Active Directory マシンから SSH の使用

信頼を設定すると、Active Directory ユーザーは、SSH およびその AD 認証情報を使用して IdM ホストのマシン、サービス、およびファイルにアクセスできます。

5.3.7.1. キャッシングの考慮事項

IdM クライアントは、ユーザー属性を取得するために Active Directory ドメインコントローラー(DC)に直接接続しません。代わりに、クライアントはこの情報をキャッシュする IdM サーバーに接続します。このため、Active Directory でユーザーを無効にすると、IdM データベースにユーザーの有効期限が切れるまで、SSH キー認証を使用して IdM クライアントを引き続き認証できます。
IdM は、以下の状況でユーザーのレコードを更新します。
  • エントリーは自動的に期限切れになります。
  • sss_cache ユーティリティーを使用して、キャッシュでユーザーのエントリーを手動で失効させます。
    # sss_cache --user user_name
  • ユーザーは、kinit ユーティリティーまたは Web UI を使用して IdM サーバーに対して認証を行います。

5.3.7.2. パスワードなしの SSH の使用

ローカル承認の localauth Kerberos プラグインは、Kerberos プリンシパルがローカルの SSSD ユーザー名に自動的にマップされるようにします。localauth では、信頼できる AD ドメインの Windows ユーザーは、Kerberos を使用してログインする際にパスワードの入力が求められないため、パスワードなしで SSH を使用できます。
プラグインは、複数のレルムまた信頼全体で信頼できるマッピングメカニズムを提供します。sssd が Kerberos ライブラリーに接続し、プリンシパルをローカルの POSIX ID にマップする場合、SSSD プラグインは IdM で定義された信頼関係に従ってマッピングします。
特定の状況では、ユーザーは SSH bastion ホストを使用して他の Red Hat Enterprise Linux マシンにアクセスします。デフォルトでは、Kerberos を使用して bastion ホストで SSH に対して認証する場合に、Kerberos チケットを転送して Kerberos を使用して他の Red Hat Enterprise Linux ホストに対して認証することはできません。このような転送認証を有効にするには、Kerberos フラグ OK_AS_DELEGATE Kerberos フラグを bastions ホストプリンシパルに追加します。
# ipa host-mod bastion_host.idm.example.com --ok-as-delegate=true

Red Hat Enterprise Linux 7.1 以降のシステムでの AD ユーザーの Kerberos 認証

Red Hat Enterprise Linux 7.1 以上のシステムでは、SSSD は localauth Kerberos プラグインを自動的に設定します。
SSSD では、IN、ad.domain\user、および AD\user 形式のユーザー名を使用できます。
注記
localauth を使用するシステムでは、/etc/krb5.conf ファイルで auth_to_local オプションを設定したり、.k5login ファイルの Kerberos プリンシパルを一覧表示したりする必要はありません。localauth プラグインは、パスワードが廃止されず、以前にログイン用に設定を使用しました。

AD ユーザーの Kerberos 認証の手動設定

localauth プラグインが存在しないシステムでは、ユーザーが適切な Kerberos チケットを取得している場合でも、SSH は、Active Directory ドメインユーザーのユーザーパスワードを要求します。
Active Directory ユーザーがこの状況で Kerberos を使用できるようにするには、/etc/krb5.conf ファイルで auth_to_local オプションを設定するか、ユーザーのホームディレクトリーの.k5login ファイルのユーザー Kerberos プリンシパルを一覧表示します。
/etc/krb5.confの設定
以下の手順では、Kerberos 設定でレルムマッピングを設定する方法を説明します。
  1. /etc/krb5.conf ファイルを開きます。
  2. [realms] セクションで、名前で IdM レルムを特定し、2 つの auth_to_local 行を追加します。Kerberos プリンシパル名のマッピングを定義します。
    • 1 つのルールで、異なる Active Directory ユーザー名形式および特定の Active Directory ドメインをマッピングするルールを追加します。
    • 他のルールで、標準の Unix ユーザー名に DEFAULT の値を設定します。
    以下に例を示します。
    [realms]
    IDM = {
    ....
    auth_to_local = RULE:[1:$1@$0](^.*@ADDOMAIN$)s/@ADDOMAIN/@addomain/
    auth_to_local = DEFAULT
    }
  3. KDC サービスを再起動します。
    [root@server ~]# systemctl restart krb5kdc.service
auth_to_local オプションを使用して Kerberos 認証を設定する場合は、SSH アクセスに使用するユーザー名が以下の基準を満たしている必要があることに注意してください。
  • ユーザー名の形式は ad_user@ad_domain である必要があります。
  • ドメイン名は小文字である必要があります。
  • ユーザー名は、Active Directory のユーザー名の場合は一致している必要があります。たとえば、ユーザーおよびユーザー はそれぞれのケースにより異なるユーザーとみなされます
auth_to_local の設定に関する詳細は、krb5.conf(5) の man ページを参照してください。
configuring.k5login
以下の手順では、ローカルユーザー名の Kerberos プリンシパル名を検索するようにシステムを設定します。
  1. ユーザーのホームディレクトリーに.k5login ファイルを作成します。
  2. ファイルのユーザーが使用する Kerberos プリンシパルを一覧表示します。
認証ユーザーが既存の Kerberos チケットのプリンシパルと一致する場合は、ユーザーはチケットを使用してログインでき、パスワードの入力を要求されません。
.k5login 設定を使用して Kerberos 認証を設定する場合には、SSH アクセスに使用するユーザー名には ad_user@ad_domain の形式が必要なことに注意してください。
.k5login ファイルの設定に関する詳細は、.k5login(5) の man ページを参照してください。
この設定手順の 1 つにより、AD ユーザーは Kerberos を使用してログインできます。

5.3.8. Kerberos 対応の Web アプリケーションでの信頼の使用

既存の Web アプリケーションは、信頼された Active Directory および IdM Kerberos レルムを参照する Kerberos 認証を使用するように設定できます。完全な Kerberos 設定ディレクティブは、mod_auth_kerb モジュールの Configuration ページを参照してください
注記
Apache アプリケーション設定を変更したら、Apache サービスを再起動します。
[root@ipaserver ~]# systemctl restart httpd.service
たとえば、Apache サーバーでは、Apache サーバーが IdM Kerberos レルムに接続する方法を定義するオプションは複数あります。
KrbAuthRealms
KrbAuthRealms オプションは、アプリケーションの場所を IdM ドメインの名前を指定します。これは必須です。
Krb5Keytab
Krb5Keytab オプションは、IdM サーバーのキータブの場所を指定します。これは必須です。
KrbServiceName
KrbServiceName オプションは、キータブ(HTTP)に使用される Kerberos サービス名を設定します。これは推奨されています。
KrbMethodK5Passwd および KrbMethodNegotiate
KrbMethodK5Passwd Kerberos メソッドオプションを使用すると、有効なユーザーのパスワードベースの認証を有効にします。有効な Kerberos チケットが利用可能な場合には、KrbMethodNegotiate オプションはシングルサインオン(SSO)を有効にします。
これらのオプションは、多くのユーザーに使いやすくするために推奨されます。
KrbLocalUserMapping
KrbLocalUserMapping オプションは、通常の Web ログイン(通常はアカウントの UID または一般名)を、完全修飾ユーザー名( の形式)にマッピングできるようにします。
このオプションは強く推奨されます。ドメイン名/ログイン名のマッピングがないと、Web ログインがドメインユーザーとは別のユーザーアカウントとして表示されます。つまり、ユーザーは想定されるデータを確認できません。

例5.1 Apache Web アプリケーションの Kerberos 設定

<Location "/mywebapp">
   AuthType Kerberos
   AuthName "IPA Kerberos authentication"
   KrbMethodNegotiate on
   KrbMethodK5Passwd on
   KrbServiceName HTTP
   KrbAuthRealms IDM_DOMAIN
   Krb5Keytab /etc/httpd/conf/ipa.keytab
   KrbLocalUserMapping on
   KrbSaveCredentials off
   Require valid-user
</Location>

5.3.9. Active Directory Kerberos 通信用の Kerberos Distribution Center プロキシーとして IdM サーバーを設定する

特定の状況では、ネットワーク制限またはファイアウォールルールにより、Identity Management(IdM)クライアントが、Active Directory(AD)ドメインコントローラーで Kerberos トラフィックをポート 88 に送信しないようにします。このソリューションは、Identity Management サーバー上に、IdM クライアントから AD にトラフィックをリレーするために、Kerberos プロキシーを設定することです。
  1. IdM クライアントで、/etc/krb5.conf ファイルの [realms] セクションに Active Directory レルムを追加します。kdc およびkpasswd_server パラメーターを、IdM サーバーの完全修飾ドメイン名の後に、/KdcProxy' をポイントするように設定します。
    AD.EXAMPLE.COM = {
    	        kdc = https://server.idm.example.com/KdcProxy
    	        kpasswd_server = https://server.idm.example.com/KdcProxy
    	    }
  2. IdM クライアントで、前の手順で /etc/krb5.conf 仕様を上書きする可能性がある /var/lib/sss/pubconf/kdcinfo.* ファイルの作成を無効にします。/etc/sssd/sssd.conf ファイルを編集し、krb5_use_kdcinfoFalse に設定します。
    [domain/example.com]
    krb5_use_kdcinfo = False
  3. IdM サーバーで、/etc/ipa/kdcproxy/kdcproxy.conf ファイルで use_dns オプションを true に設定し、DNS サービス(SRV)レコードを使用して、AD サーバーと通信できるようにします。
    use_dns = true
    または、DNS SRV レコードを使用しない場合は、/etc/krb5.conf ファイルの [realms] セクションに明示的な AD サーバーを追加します。
    AD.EXAMPLE.COM = {
            kdc = ad-server.ad.example.com
            kpasswd_server = ad-server.ad.example.com
        }
    注記
    Ansible スクリプトなどのスクリプトを実行して、手順 2 および 3 を実行できます。これは、複数のシステムで変更を行ったときに特に便利です。
  4. IdM サーバーで、IPA サービスを再起動します。
    # ipactl restart
  5. 手順が正常に行われたことを確認するには、IdM クライアントで以下を実行します。
    # rm /var/lib/sss/pubconf/kdcinfo*
    # kinit ad_user@AD.EXAMPLE.COM
    Password for ad_user@AD.EXAMPLE.COM:
    # klist
    Ticket cache: KEYRING:persistent:0:0
    Default principal: ad_user@AD.EXAMPLE.COM
    
    Valid starting     Expires            Service principal
    [... output truncated ...]

このページには機械翻訳が使用されている場合があります (詳細はこちら)。