RHEL システムと Windows Active Directory を直接統合

• Active Directory
• RHEL の ID 管理 (IdM)
• あらゆる汎用 LDAP または Kerberos サーバー

• フォレスト機能レベルの範囲 - Windows Server 2008 ~ Windows Server 2016
• ドメイン機能レベルの範囲 - Windows Server 2008 ~ Windows Server 2016

• Windows Server 2022 (RHEL 8.7 以降)
• Windows Server 2019
• Windows Server 2016
• Windows Server 2012 R2

• AD との統合オプション: ID マッピングまたは POSIX 属性の使用
• SSSD を使用した AD ドメインの検出および参加
• Active Directory で定義された POSIX 属性を使用した AD への接続

• SSSD を使用したさまざまな AD フォレストでの複数ドメインへの接続

  重要

  システムを AD に参加させる前に、基本的な事前チェック手順: 'adcli'、'realm'、および 'net' コマンドを使用した RHEL による Active Directory への参加 の手順に従って、システムが正しく設定されていることを確認してください。

• アイデンティティープロバイダーがオンラインになるタイミング。
• RHEL システムが再起動したタイミング。

• /etc/sssd/sssd.conf 設定ファイルの dyndns_refresh_interval オプションで指定される間隔。デフォルト値は 86400 秒 (24 時間) です。

  注記

  dyndns_refresh_interval オプションを DHCP リースと同じ間隔に設定すると、IP リースの更新後に DNS レコードを更新できます。

前提条件

• RHEL ホストが SSSD サービスを使用して Active Directory 環境に追加している。
• /etc/sssd/sssd.conf 設定ファイルを編集するには、root パーミッションが必要です。

• SSSD は、AD フォレストのドメインを 1 つだけサポートします。SSSD が複数のフォレストから複数のドメインにアクセスする必要がある場合は、SSSD の代わりに信頼 (推奨) または winbindd サービスで IPA を使用することを検討してください。

• デフォルトでは、SSSD はフォレスト内のすべてのドメインを検出し、信頼されるドメイン内のオブジェクトの要求が到達すると、SSSD はこれを解決しようとします。

  信頼できるドメインに到達できない、または地理的に離れているために遅くなる場合は、/etc/sssd/sssd.conf に ad_enabled_domains パラメーターを設定して、どの信頼ドメインから SSSD がオブジェクトを解決するかを制限できます。

• デフォルトでは、完全修飾ユーザー名を使用して信頼されるドメインのユーザーを解決する必要があります。

• ドメインでのシステム登録の管理
• ローカルシステムリソースへのアクセスが許可されるドメインユーザーの制御

• ネットワーク認証およびドメインメンバーシップの標準的な設定。
• アクセス可能なドメインおよびレルムに関する情報を自動的に検出します。
• ドメインまたはレルムに参加するために高度な設定を必要としません。

• マルチフォレストの AD 設定における Winbind との直接統合は、双方向の信頼が必要になります。
• idmap_ad プラグインがリモートフォレストユーザーを正常に処理するには、リモートフォレストがローカルフォレストを信頼する必要があります。

• フォレスト機能レベルの範囲 - Windows Server 2008 ~ Windows Server 2016
• ドメイン機能レベルの範囲 - Windows Server 2008 ~ Windows Server 2016

• Windows Server 2022 (RHEL 8.7 以降)
• Windows Server 2019
• Windows Server 2016
• Windows Server 2012 R2

• ドメインでのシステム登録の管理
• ローカルシステムリソースへのアクセスが許可されるドメインユーザーの制御

• 中央の ID および認証ソースと対話するための SSSD
• 使用可能な AD ドメインを検出し、基盤となる RHEL システムサービス (この場合は SSSD) を設定して、選択した AD ドメインに接続する realmd

前提条件

• コントロールノードと管理対象ノードの準備が完了している。
• 管理対象ノードで Playbook を実行できるユーザーとしてコントロールノードにログインしている。
• 管理対象ノードへの接続に使用するアカウントに、そのノードに対する sudo 権限がある。

• AD ドメインコントローラー上の次のポートが開いており、RHEL サーバーからアクセスできます。

  表3.1 ad_integration システムロールを使用して Linux システムを AD に直接統合するために必要なポート

  送信元ポート	送信先ポート	プロトコル	サービス
  1024:65535	53	UDP および TCP	DNS
  1024:65535	389	UDP および TCP	LDAP
  1024:65535	636	TCP	LDAPS
  1024:65535	88	UDP および TCP	Kerberos
  1024:65535	464	UDP および TCP	Kerberos のパスワード変更/設定 (kadmin)
  1024:65535	3268	TCP	LDAP グローバルカタログ
  1024:65535	3269	TCP	LDAP グローバルカタログ SSL/TLS
  1024:65535	123	UDP	NTP/Chrony (オプション)
  1024:65535	323	UDP	NTP/Chrony (オプション)

検証

• administrator ユーザーなどの AD ユーザーの詳細を表示します。

  $ getent passwd administrator@ad.example.com
  administrator@ad.example.com:*:1450400500:1450400513:Administrator:/home/administrator@ad.example.com:/bin/bash

前提条件

• System Security Services Daemon (SSSD) または Samba Winbind を使用して、RHEL システムを AD に接続しました。

検証

• ドメインが設定されていないことを確認します。

  # realm discover [ad.example.com]
  ad.example.com
      type: kerberos
      realm-name: EXAMPLE.COM
      domain-name: example.com
      configured: no
      server-software: active-directory
      client-software: sssd
      required-package: oddjob
      required-package: oddjob-mkhomedir
      required-package: sssd
      required-package: adcli
      required-package: samba-common-tools

前提条件

• SSSD サービスを使用して、RHEL ホストを直接 AD に接続している。

検証

• 短縮名だけを使用して、最初のドメインからユーザー情報を取得できることを確認します。

  [root@ad-client ~]# id <user_from_subdomain2>
  uid=1916901142(user_from_subdomain2) gid=1916900513(domain users) groups=1916900513(domain users)

• SSSD が GPO アクセス制御ルールを解釈する方法
• SSSD がサポートする GPO 設定のリスト
• GPO 強制を制御する SSSD オプションのリスト
• GPO アクセス制御モードの変更
• RHEL ホストの GPO の作成と設定

• lab ドメインは、production ドメインのユーザーとホストを信頼します。
• production ドメインは、lab ドメインのユーザーとホストを 信頼しません。

前提条件

• RHEL ホストの以下のポートが開放され、AD ドメインコントローラーからアクセスできることを確認している。

  サービス	ポート	プロトコル
  DNS	53	TCP、UDP
  LDAP	389	TCP、UDP
  LDAPS (オプション)	636	TCP、UDP
  Kerberos	88	TCP、UDP

• production.example.com ドメインに MSA を作成する権限を持つ AD 管理者のパスワードがある。
• adcli コマンドを実行し、/etc/sssd/sssd.conf 設定ファイルを変更するために必要な root 権限がある。
• (任意) klist 診断ユーティリティーを含む krb5-workstation パッケージがインストールされている。

検証

• MSA として Kerberos TGT (Ticket-granting ticket) を取得できることを確認します。

  [root@client ~]# kinit -k -t /etc/krb5.keytab.production.example.com 'CLIENT!S3A$'
  [root@client ~]# klist
  Ticket cache: KCM:0:54655
  Default principal: CLIENT!S3A$@PRODUCTION.EXAMPLE.COM
  
  Valid starting       Expires              Service principal
  11/22/2021 15:48:03  11/23/2021 15:48:03  krbtgt/PRODUCTION.EXAMPLE.COM@PRODUCTION.EXAMPLE.COM

• AD で、Managed Service Accounts Organizational Unit (OU) にホストの MSA があることを確認します。

前提条件

• production.example.com AD ドメインにホストの MSA を作成している。
• (任意) klist 診断ユーティリティーを含む krb5-workstation パッケージがインストールされている。

検証

• Kerberos キータブで、KVNO が増加していることを確認します。

  [root@client ~]# klist -k /etc/krb5.keytab.production.example.com
  Keytab name: FILE:/etc/krb5.keytab.production.example.com
  KVNO Principal
  ---- ------------------------------------------------------------
     3 CLIENT!S3A$@PRODUCTION.EXAMPLE.COM (aes256-cts-hmac-sha1-96)
     3 CLIENT!S3A$@PRODUCTION.EXAMPLE.COM (aes128-cts-hmac-sha1-96)

• 追加のサービスプリンシパル名 (SPN) を持つことはできません。
• デフォルトでは、MSA の Kerberos プリンシパルは、/etc/krb5.keytab.production.example.com のように、<default_keytab_location>.<Active_Directory_domain> という名前の Kerberos キータブに保存されます。

• MSA の名前は 20 文字以内に制限されています。最後の 4 文字は、! の文字を区切り文字として使用して、指定した短いホスト名に追加された、数字と大文字および小文字の ASCII 範囲からの 3 つのランダムな文字の接尾辞です。たとえば、myhost という短い名前のホストは、次の仕様の MSA を受け取ります。

  仕様	値
  共通名 (CN) 属性	myhost!A2c
  NetBIOS 名	myhost!A2c$
  sAMAccountName	myhost!A2c$
  production.example.com AD ドメイン内の Kerberos プリンシパル	myhost!A2c$@PRODUCTION.EXAMPLE.COM