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

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

IdM はユーザープリンシパル名 (UPN) を使ったログインに対応しています。UPN は認証に使用するユーザー名の代わりとなるもので、username@KERBEROS-REALM という形式になっています。Active Directory フォレストでは、追加の UPN 接尾辞を設定することができます。これらのエンタープライズプリンシパル名は、デフォルトの UPN の代替ログインとして使用できます。
例えば、ある企業で Kerberos レルム AD.EXAMPLE.COM を使っているとすると、ユーザーのデフォルトの UPN は user@ad.example.com になります。しかし、 企業ではユーザーが user@example.com といったメールアドレスを使用してログインできるようにする場合がよくあります。この場合、管理者は追加の UPN 接尾辞 example.com を Active Directory フォレストに追加し、ユーザーアカウントのプロパティーでこの新たな接尾辞を設定します。
信頼された 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 接尾辞は、ipaNTAdditionalSuffixes サブツリー内の複数値の属性 cn=trusted_domain_name,cn=ad,cn=trusts,dc=idm,dc=example,dc=com に保存されます。

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

IdM と Active Directory 間の信頼がある一部の環境では、ユーザーが IdM DNS ドメインからのホスト名を使用して Active Directory クライアントにアクセスする設定が可能な一方、クライアント自体は IdM に参加して Linux にフォーカスした機能の恩恵を受けることができます。

重要

これは推奨される設定ではなく、一定の制限があります。Red Hat では、IdM が所有している DNS ゾーンとは別のゾーンに Active Directory クライアントをデプロイし、IdM ホスト名で IdM クライアントにアクセスすることを常に推奨しています。

5.3.2.1. IdM クライアントへの Kerberos シングルサインオンが不要

IdM DNS ドメインでの Active Directory クライアントの構成では、この 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. Active Directory 設定ファイル内の [domain_realm] セクションで /etc/krb5.conf ドメインの既存のマッピングを見つけます。
    .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-client.ad.example.com に対してのみ、IdM KDC は設定されます。

注記

IdM が所有する DNS ゾーン内にないクライアント上のリソースに対しての認証は、ユーザー名とパスワードを使用する方法のみになります。

SSL 証明書の処理

SSL ベースのサービスは、すべてのシステムホスト名をカバーしている dNSName 拡張子レコードがある証明書を必要とします。これは、オリジナル (A/AAAA) レコードと CNAME レルムの両方が証明書内にある必要があるためです。現時点では、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 Certificate Authority (CA) に対して認証を行います。

5.3.2.2. IdM クライアントへの Kerberos シングルサインオンが必要

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

SSL 証明書の処理

SSL ベースのサービスは、すべてのシステムホスト名をカバーしている dNSName 拡張子レコードがある証明書を必要とします。これは、オリジナル (A/AAAA) レコードと CNAME レルムの両方が証明書内にある必要があるためです。現時点では、IdM は IdM データベース内のホストオブジェクトにのみ証明書を発行します。
シングルサインオンが利用できない設定では、IdM はすでにデータベースに FQDN のホストオブジェクトがあり、certmonger がこの名前の証明書をリクエストできます。
  1. 新規ホストオブジェクトを作成します。
    [root@idm-server.idm.example.com ~]# ipa host-add idm-client.ad.example.com --force
    ホスト名が A/AAAA レコードではなく CNAME であることから、--force オプションを使用します。
  2. IdM DNS ホスト名が Active Directory データベースの IdM ホストエントリーを管理できるようにします。
    [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. IdM ユーザー用の Active Directory グループの作成

ユーザーグループは、アクセス権限、ホストベースのアクセス制御、sudo ルールおよび IdM ユーザーの他の制御を設定するために必要です。これらのグループは、アクセスを制限するだけでなく、IdM ドメインリソースへのアクセスを付与する際のベースになります。
AD ユーザーと AD グループの両方を直接 IdM ユーザーグループに追加することができます。これを行うには、まず AD ユーザーまたはグループを 非 POSIX IdM 外部グループに追加し、その後にローカルの IdM POSIX グループに追加します。すると、POSIX グループを使用して AD ユーザーのユーザーおよびロール管理ができるようになります。この IdM 内の非 POSIX グループの処理についての原則は、「Active Directory ユーザーと Identity Management グループ」 で説明しています。

注記

AD ユーザーグループを IdM 外部グループのメンバーとして追加することもできます。これにより、ユーザーおよびグループ管理を単一の AD レルム内で維持し、Windows ユーザー向けのポリシー定義が容易になる場合があります。
  1. これはオプションです。 IdM レルムで IdM ユーザー管理に使用する AD ドメインのグループを作成または選択します。複数のグループを使用して、 側の異なるグループに追加することができます。
  2. IdM オプションを Active Directory に追加して、--external ユーザー用に ipa group-add ドメインの外部グループを作成します。--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
  3. IdM ポリシーの管理用に新規の IdM POSIX グループを作成するか既存のものを選択します。例えば、新規グループを作成するには、以下を実行します。
    [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 ユーザーまたはグループを外部メンバーとして IdM 外部グループに追加します。AD メンバーは、DOMAIN\group_nameDOMAIN\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 グループを POSIX 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 レルム設定、Active Directory ユーザーへの ID 範囲の割り当てなど多数の分野が関わってきます。

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

ipa-adtrust-install は、IdM ドメインとの信頼作成に必要な Active Directory ドメインのバックグランド情報を自動的に設定します。
グローバル信頼設定には以下の 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 ではこの属性の変更は推奨していません。
  ユーティリティーを実行すると、 Activeipa-adtrust-installDirectory トポロジー内で互換性のある 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 フォレストを信頼するように設定すると、PAC レコードが IdM ユーザーの Kerberos チケットに追加されます。MS-PAC レコードには、IdM が所属するグループのセキュリティー ID (SID) が含まれています。IdM ユーザーのプライマリーグループに SID が割り当てられていないと、Default SMB Groupに定義されたセキュリティー ID の値が使用されます。AD ドメインコントローラーが IdM 信頼コントローラーからユーザー情報を要求する場合も、同じ論理が Samba スイートで適用されます。
Default SMB Group は、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. IdMFallback primary group ドロップダウンリストの全 グループから新規グループを選択します。
    Windows ユーザーのデフォルトグループの設定

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

  4. Save をクリックして新規設定を保存します。

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

信頼が推移的ということは、信頼パスはドメインのチェーンをたどることになります。これについては、「信頼関係のアーキテクチャー」 で詳述してます。
IdM にはフォレスト内の root ドメインとの間に信頼があり、推移性により、そのサブドメインおよび信頼されるドメインはすべてその信頼に暗黙的に組み込まれます。IdM は、Windows ユーザーがフォレスト内の任意の場所から IdM リソースへアクセスを試行する際に、このトポロジーに従います。各ドメインおよびサブドメインは 信頼設定の trust domainIdM になります。各ドメインは、信頼サブツリーのそれぞれのエントリー 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 Domains and 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. DNS レルムの表示および管理

信頼が設定される際に、Active Directory DNS 設定は IdM DNS 設定に追加され、それぞれのレルムは特別な レルムドメイン として追加されます。各ドメインは、cn=Realm Domains,cn=ipa,cn=etc,dc=example,dc=com ディレクトリーの IdM サブツリーに保存されます。
これらのレルムドメインは自動的に追加されるため、通常 DNS ゾーンを追加したり、変更したりする必要はありません。(IdM で設定されるすべての DNS ゾーンの一覧ではなく) 設定されたレルムドメインの一覧は、realmdomains-show コマンドを使用して表示することができます
[root@ipaserver ~]# kinit admin
[root@ipaserver ~]# ipa realmdomains-show
 Domain: ipa.example.org, ipa.example.com, example.com
単一レルムドメインを設定に追加する必要がある場合は、--add-domain オプションを使用して実行できます。
[root@ipaserver ~]# kinit admin
[root@ipaserver ~]# ipa realmdomains-mod --add-domain=ad.example.com
 Domain: ipa.example.org, ipa.example.com, example.com, ad.example.com
単一ドメインは --del-domain オプションを使用して削除することができます。
ドメインの一覧に対して複数の変更が行われる場合、--domain オプションを使用して一覧自体を変更し、置き換えることができます。
[root@ipaserver ~]# ipa realmdomains-mod --domain={ipa.example.org,ad.example.com}

5.3.4.4. 推移的な信頼における UID および GID 番号範囲の追加

信頼を最初に設定する際に作成する ID 範囲は、「ID の範囲」 で説明しています。後で ID 範囲を追加するには、以下のオプションを付けて ipa idrange-add コマンドを実行します。
  • --base-id オプションは POSIX 範囲のベース ID を設定します。これが最初の番号になります。
  • --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. サービスおよびホスト向けの Kerberos フラグ

信頼されるドメイン内のサービスやホストにアクセスするには、Kerberos チケット保証チケット (TGT) に特別なフラグが必要となる場合があります。例えば、シングルサインオンを使用して AD クライアントから IdM (AD) アカウントで Active Directory クライアントにログインする場合は、Kerberos TGT フラグ OK_AS_DELEGATE が必要になります。
Kerberos フラグの設定に関する詳細情報は、Linux ドメイン ID、認証、およびポリシーガイド の 『Kerberos Flags for Services and Hosts』 を参照してください。

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

IdMリソースについては、Active Directory ユーザーがサービスのチケットを要求する場合に IdM はその要求を Active Directory に転送して、ユーザー情報を取得します。ユーザーの Active Directory グループ割り当てに関連付けられたアクセスデータが Active Directory によって送り戻され、Kerberos チケットに組み込まれます。
Active Directory のグループ情報は、Active Directoryprivileged access certificates または MS-PAC と呼ばれる特殊なデータセットとして ユーザーの各 Kerberos チケットの識別子の一覧に保存されます。PAC のグループ情報は Active Directory グループにマップされてから、対応する IdM グループにマップされ、アクセスの判別が行われます。
IdM サービスは、ドメインサービスに対するユーザー認証の初回試行時に、認証リクエストに対して PAC を生成するように設定できます。

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

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

    図5.7 Service Options 領域

  4. PAC を使用するには、MS-PAC チェックボックスを選択します。これで AD サービスで使用可能な証明書が追加されます。チェックボックスが選択されないと、PAC は Kerberos チケットに追加されません。
    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 サービスが使用可能な証明書を追加します。
    Service Settings 領域

    図5.8 Service Settings 領域

    チェックボックスが選択されない場合、PAC は Kerberos チケットに追加されません。

    注記

    PAD チェックボックスは無視して構いません。この機能はまだ IdM では利用可能になっていません。
  4. 変更を保存するには、ページの上部にある Update リンクをクリックします。

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

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

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

5.3.6.2. ログインシェルとホームディレクトリー属性の送信

重要

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

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

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

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

ローカル認証用の localauth Kerberos プラグインは、Kerberos プリンシパルが自動的にローカルの SSSD ユーザー名にマッピングされるようにします。この localauth を使うことで、信頼される AD からの Windows ユーザーは Kerberos を使用したログイン時にパスワードが求められず、パスワードなしで SSH を使用できるようになります。
このプラグインは、複数のレルムや信頼にわたって信頼性のあるマッピングメカニズムを提供します。sssd が Kerberos ライブラリーに接続してプリンシパルを POSIX ID にマッピングする際には、SSSD プラグインは IdM で定義された信頼合意に従ってこれらをマッピングします。

Red Hat Enterprise Linux 7.1 およびそれ以降のシステムにおける AD ユーザーの Kerberos 認証

Red Hat Enterprise Linux 7.1 およびそれ以降のシステムでは、SSSD は localauth Kerberos プラグインを自動設定します。
SSSD は、user@AD.DOMAIN, 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 レルムを名前で識別し、auth_to_local を 2 行追加して Kerberos プリンシパル名マッピングを定義します。
    • 1 つ目のルールでは、異なる Active Directory ユーザー名形式と特定の Active Directory ドメインをマッピングするルールを定義します。
    • 2 つ目では、 DEFAULT の値を標準 Unix ユーザー名に設定します。
    例:
    [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 内のユーザー名と一致していること。例えば、userUser は文字の大きさが異なるので、別のユーザー名とみなされます。
auth_to_local の設定に関する詳細情報は、krb5.conf(5) man ページを参照してください。
.k5login の設定
以下の手順では、システムがローカルユーザー名の Kerberos プリンシパル名を見つける設定を行います。
  1. ユーザーのホームディレクトリーに .k5login ファイルを作成します。
  2. 作成したファイルにユーザーが使用する Kerberos プリンシパルを記載します。
認証しているユーザーが既存 Kerberos チケットのプリンシパルと一致する場合、ユーザーはパスワードを求められることなく、そのチケットを使用してログインできます。
.k5login 設定を使用して Kerberos 認証を設定する場合は、SSH アクセスに使用しするユーザー名は ad_user@ad_domain の形式を取る必要があります。
.k5login ファイルの設定に関する詳細情報は、.k5login(5) man ページを参照してください。
これらのいずれの設定を行うことで、 AD ユーザーが Kerberos を使用してログインできるようになります。

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

既存の web アプリケーションは、信頼される Active Directory および IdM Kerberos レルムを参照する Kerberos 認証を使用するように設定できます。完全な Kerberos 設定ディレクティブについては Configuration page for the mod_auth_kerb module を参照してください。

注記

Apache アプリケーション設定を変更した後に、Apache サービスを再起動します。
[root@ipaserver ~]# systemctl restart httpd.service
たとえば Apache サーバーの場合、Apache サーバーが IdM Kerberos レルムに接続する方法を定義する以下のようなパラメーターがあります。
KrbAuthRealms
KrbAuthRealms オプションはアプリケーションの場所を IdM ドメインの名前に指定します。これは必須です。
Krb5Keytab
Krb5Keytab オプションは IdM サーバーキータブの場所を指定します。これは必須です。
KrbServiceName
KrbServiceName オプションはキータブで使用する Kerberos サービス名を設定します (HTTP)。これは推奨オプションです。
KrbMethodK5Passwd および KrbMethodNegotiate
KrbMethodK5Passwd Kerberos メソッドオプションは、有効なユーザーのパスワードベースの認証を有効にします。KrbMethodNegotiateオプションは、有効な Kerberos チケットが利用可能な場合にシングルサインオン (SSO) を有効にします。
ユーザーが多い場合は、これらのオプションの使用が推奨されます。
KrbLocalUserMapping
KrbLocalUserMapping オプションは、通常の web ログイン (通常はアカウントの UID または共通名) を完全修飾ユーザー名 ( user@REALM.COM 形式) にマップできるようにします。
このオプションの使用は強く推奨されます。ドメイン名/ログイン名のマッピングがないと、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>