第3章 AD への直接接続の管理

本セクションでは、Active Directory への接続を変更および管理する方法を説明します。

前提条件

  • RHEL システムを Active Directory ドメインに接続している。

3.1. デフォルトの Kerberos ホストのキータブの更新間隔を変更

SSSD は、adcli パッケージがインストールされていると、AD 環境で Kerberos ホストキータブファイルを自動的に更新します。デーモンは、マシンアカウントのパスワードが設定されている値よりも古いかどうかを毎日確認し、必要に応じてそのパスワードを更新します。

デフォルトの更新間隔は 30 日です。デフォルトを変更するには、以下の手順に従います。

手順

  1. 以下のパラメーターを /etc/sssd/sssd.conf ファイルの AD プロバイダーに追加します。

    ad_maximum_machine_account_password_age = value_in_days
  2. SSSD を再起動します。

    # systemctl restart sssd
  3. Kerberos ホストのキータブの自動更新を無効にするには、ad_maximum_machine_account_password_age = 0 を設定します。

関連情報

  • man ページの adcli(8)
  • sssd.conf(5) の man ページ

3.2. AD ドメインからの RHEL システムの削除

この手順では、Active Directory (AD) ドメインから RHEL システムを削除する方法を説明します。

手順

  1. realm leave コマンドを使用して、ID ドメインからシステムを削除します。このコマンドは、SSSD およびローカルシステムからドメイン設定を削除します。

    # realm leave ad.example.com
    注記

    クライアントがドメインからいなくなっても、アカウントは AD から削除されず、ローカルクライアントの設定のみが削除されます。AD アカウントを削除する場合は、--remove オプションを指定してコマンドを実行します。ユーザーパスワードの入力が求められ、Active Directory からアカウントを削除する権限が必要になります。

  2. realm leave コマンドに -U オプションを付けて実行し、システムを ID ドメインから削除する別のユーザーを指定します。

    デフォルトでは、realm leave コマンドはデフォルトの管理者として実行されます。AD の場合は、管理者アカウントは Administrator と呼ばれます。ドメインに参加するために別のユーザーを使用していた場合は、そのユーザーとして削除を実行しないといけない場合があります。

    # realm leave [ad.example.com] -U [AD.EXAMPLE.COM\user]'

コマンドは最初に認証情報なしで接続を試みますが、必要に応じてパスワードが要求されます。

検証手順

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

    # 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

関連情報

  • realm(8) の man ページを参照してください。

3.3. SSSD でドメイン解決順序を設定して、AD ユーザーの短縮名を解決する手順

デフォルトでは、ad_username@ad.example.com および group@ad.example.com など完全修飾ユーザー名を指定して、SSSD サービスで AD に接続された RHEL ホスト上にある Active Directory (AD) ユーザーおよびグループを解決する必要があります。

この手順では、SSSD 設定でドメイン解決の順序を設定し、ad_username などの短縮名を使用して AD ユーザーおよびグループを解決できるようにします。この設定例では、以下の順序でユーザーおよびグループを検索します。

  1. Active Directory (AD) 子ドメイン subdomain2.ad.example.com
  2. AD 子ドメイン subdomain1.ad.example.com
  3. AD root ドメイン ad.example.com

前提条件

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

手順

  1. テキストエディターで /etc/sssd/sssd.conf ファイルを開きます。
  2. このファイルの [sssd] セクションに domain_resolution_order オプションを設定します。

    domain_resolution_order = subdomain2.ad.example.com, subdomain1.ad.example.com, ad.example.com
  3. ファイルを保存してから閉じます。
  4. SSSD サービスを再起動して、新しい設定を読み込みます。

    [root@ad-client ~]# systemctl restart sssd

検証手順

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

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

3.4. ドメインユーザーのログインパーミッションの管理

デフォルトでは、ドメイン側のアクセス制御が適用されます。これは、Active Directory (AD) ユーザーのログインポリシーが AD ドメイン自体に定義されることを意味します。クライアント側のアクセス制御を使用できるように、このデフォルトの動作は上書きできます。クライアント側のアクセス制御では、ログインパーミッションはローカルポリシーでのみ定義されます。

ドメインがクライアント側のアクセス制御を適用する場合は、realmd を使用して、そのドメインのユーザーの基本的なアクセスルールである allow または deny を設定できます。

注記

アクセスルールは、システムにあるすべてのサービスへのアクセスを許可または拒否します。特定のシステムリソースまたはドメインに、より具体的なアクセスルールを設定する必要があります。

3.4.1. ドメイン内でユーザーのアクセス権を有効化

本セクションでは、ドメイン内のユーザーのアクセス権を有効にする方法を説明します。

重要

特定のユーザーまたはグループのアクセスのみを許可する方が、一部のユーザーへのアクセスを拒否して、他のすべてのユーザーにアクセスを許可するよりも安全です。したがって、デフォルトで全ユーザーにアクセスを許可し、レルムの許可 -x を使用して特定のユーザーのみを拒否することは推奨されません。Red Hat では、代わりに、すべてのユーザーに対してデフォルトのアクセス禁止ポリシーを維持し、レルム許可を使用して選択したユーザーのアクセスのみを許可することが推奨されます。

前提条件

  • RHEL システムが Active Directory ドメインのメンバーである。

手順

  1. すべてのユーザーにアクセス権を付与します。

    # realm permit --all
  2. 特定のユーザーにアクセス権を付与します。

    $ realm permit aduser01@example.com
    $ realm permit 'AD.EXAMPLE.COM\aduser01'

現在、アクセスを許可できるのはプライマリードメインのユーザーのみで、信頼できるドメインのユーザーには許可できません。これは、ユーザーログインにドメイン名を含める必要があり、SSSD は、現在、realmd に利用可能な子ドメインに関する情報を提供できないためです。

検証手順

  1. SSH を使用して、aduser01@example.com ユーザーとしてサーバーにログインします。

    $ ssh aduser01@example.com@server_name
    [aduser01@example.com@server_name ~]$
  2. ssh コマンドをもう一度使用して、aduser02@example.com ユーザーと同じサーバーにアクセスします。

    $ ssh aduser02@example.com@server_name
    Authentication failed.

aduser02@example.com がシステムへのアクセスを拒否する方法に注目してください。aduser01@example.com ユーザーにのみ、システムにログインするパーミッションを付与しています。指定したログインポリシーが原因で、その Active Directory ドメインの他のユーザーはすべて拒否されます。

注記

sssd.conf ファイルで use_fully_qualified_names を true に設定すると、すべての要求で完全修飾ドメイン名を使用する必要があります。ただし、use_fully_qualified_names を false に設定すると、要求で完全修飾名を使用できますが、出力には簡略化されたバージョンのみが表示されます。

関連情報

  • realm(8) の man ページを参照してください。

3.4.2. ドメイン内でユーザーのアクセス権を拒否

本セクションでは、ドメイン内のすべてのユーザーへのアクセスを拒否する方法を説明します。

重要

特定のユーザーまたはグループのアクセスのみを許可する方が、一部のユーザーへのアクセスを拒否して、他のすべてのユーザーにアクセスを許可するよりも安全です。したがって、デフォルトで全ユーザーにアクセスを許可し、レルムの許可 -x を使用して特定のユーザーのみを拒否することは推奨されません。Red Hat では、代わりに、すべてのユーザーに対してデフォルトのアクセス禁止ポリシーを維持し、レルム許可を使用して選択したユーザーのアクセスのみを許可することが推奨されます。

前提条件

  • RHEL システムが Active Directory ドメインのメンバーである。

手順

  1. ドメイン内のすべてのユーザーへのアクセスを拒否します。

    # realm deny --all

    このコマンドは、realm アカウントがローカルマシンにログインできないようにします。realm permit を使用して、ログインを特定アカウントに制限します。

  2. ドメインユーザーの login-policydeny-any-login に設定されていることを確認します。

    [root@replica1 ~]# realm list
    example.net
      type: kerberos
      realm-name: EXAMPLE.NET
      domain-name: example.net
      configured: kerberos-member
      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
      login-formats: %U@example.net
      login-policy: deny-any-login
  3. -x オプションを使用して特定のユーザーへのアクセスを拒否します。

    $ realm permit -x 'AD.EXAMPLE.COM\aduser02'

検証手順

  • SSH を使用して、aduser01@example.net ユーザーとしてサーバーにログインします。

    $ ssh aduser01@example.net@server_name
    Authentication failed.
注記

sssd.conf ファイルで use_fully_qualified_names を true に設定すると、すべての要求で完全修飾ドメイン名を使用する必要があります。ただし、use_fully_qualified_names を false に設定すると、要求で完全修飾名を使用できますが、出力には簡略化されたバージョンのみが表示されます。

関連情報

  • realm(8) の man ページを参照してください。

3.5. RHEL でのグループポリシーアクセス制御の適用

Group Policy Object (GPO) は、AD 環境のコンピューターおよびユーザーに適用可能な Microsoft Active Directory (AD) に保存されているアクセス制御設定の集合です。管理者は、AD で GPO を指定することで、AD に参加している Windows クライアントと Red Hat Enterprise Linux (RHEL) ホストの両方が許可するログインポリシーを定義できます。

以下のセクションでは、環境で GPO を管理する方法を説明します。

3.5.1. SSSD が GPO アクセス制御ルールを解釈する方法

デフォルトでは、SSSD は Active Directory (AD) ドメインコントローラーからグループポリシーオブジェクト (GPO) を取得し、ユーザーが AD に参加している特定の RHEL ホストにログインできるかどうかを判断します。

SSSD は AD Windows Logon Rights を Pluggable Authentication Module (PAM) サービス名にマッピングし、GNU/Linux 環境でこれらのパーミッションを強制します。

AD 管理者として、セキュリティーフィルターにリストすることで、GPO ルールのスコープを特定のユーザー、グループ、またはホストに制限できます。

3.5.1.1. ホストによるフィルタリングの制限

SSSD の古いバージョンは、AD GPO セキュリティーフィルター内のホストを評価しません。

  • RHEL 8.3.0 以降: SSSD は、セキュリティーフィルター内のユーザー、グループ、およびホストをサポートします。
  • 8.3.0 よりも古い RHEL バージョン: SSSD はホストエントリーを無視し、セキュリティーフィルターでユーザーおよびグループのみをサポートします。
    SSSD が GPO ベースのアクセス制御を特定のホストに適用するようにするには、AD ドメインで新しい組織単位(OU)を作成し、システムを新しい OU に移動してから GPO をこの OU にリンクします。

3.5.1.2. グループ別フィルタリングの制限

SSSD は現在、セキュリティー識別子 (SID) S-1-5-32-544 を持つ Administrators など、Active Directory の組み込みグループをサポートしていません。Red Hat は、RHEL ホストを対象とする AD GPO で AD の組み込みグループを使用することを推奨しています。

関連情報

3.5.2. SSSD がサポートする GPO 設定の一覧

以下の表は、Windows の グループポリシー管理エディター で指定される Active Directory GPO オプションに対応する SSSD オプションを示しています。

表3.1 SSSD が取得した GPO アクセス制御オプション

GPO オプション対応する sssd.conf オプション

ローカルでのログオンの許可
ローカルでのログオンの拒否

ad_gpo_map_interactive

リモートデスクトップサービスを介したログオンの許可
リモートデスクトップサービスを介したログオンの拒否

ad_gpo_map_remote_interactive

ネットワークからこのコンピューターへのアクセス
ネットワークからこのコンピューターへのアクセスを拒否

ad_gpo_map_network

バッチジョブとしてのログオンの許可
バッチジョブとしてのログオンの拒否

ad_gpo_map_batch

サービスとしてのログオンの許可
サービスとしてのログオンの拒否

ad_gpo_map_service

  • GPO オプションにマップする PAM (プラグ可能な認証モジュール) サービスなど、この sssd.conf 設定の詳細は、sssd-ad(5) の man ページを参照してください。

3.5.3. GPO 強制を制御する SSSD オプションの一覧

3.5.3.1. ad_gpo_access_control オプション

/etc/sssd/sssd.conf ファイルに ad_gpo_access_control オプションを設定して、GPO ベースのアクセス制御が動作する 3 種類のモードを選択できます。

表3.2 ad_gpo_access_control の値の表


ad_gpo_access_control の値
動作

enforcing

GPO ベースのアクセス制御ルールが評価され、適用されます。
これは、RHEL 8 ではデフォルトの設定です。

permissive

GPO ベースのアクセス制御ルールは評価されますが、強制されません。syslog メッセージは、アクセスが拒否される度に記録されます。これは、RHEL 7 ではデフォルトの設定です。
このモードは、ユーザーがログインを継続できるように、ポリシーの調整をテストするのに適しています。

disabled

GPO ベースのアクセス制御ルールは、評価も強制もされません。

3.5.3.2. ad_gpo_implicit_deny オプション

ad_gpo_implicit_deny オプションは、デフォルトで False に設定されます。このデフォルトの状態では、適用可能な GPO が見つからない場合にユーザーがアクセスが許可されます。このオプションを True に設定する場合は、GPO ルールを使用したユーザーアクセスを明示的に許可する必要があります。

この機能を使用してセキュリティーを強化することはできますが、アクセスを意図せずに拒否しないように注意してください。Red Hat は、ad_gpo_access_controlpermissive に設定されている間に、この機能をテストすることを推奨します。

以下の表では、AD サーバー側で定義したログイン権限と ad_gpo_implicit_deny の値に基づいてユーザーがアクセスを許可または拒否されるタイミングを表しています。

表3.3 ad_gpo_implicit_denyFalse (デフォルト) に設定されているログイン動作

allow-rulesdeny-rules結果

なし

なし

すべてのユーザーが許可

なし

present

deny-rules でないユーザーのみが許可

present

なし

allow-rules のユーザーのみを許可

あり

あり

allow-rules のユーザーのみが許可されますが、拒否ルールでは許可されません

表3.4 ad_gpo_implicit_denyTrue に設定されているログイン動作

allow-rulesdeny-rules結果

なし

なし

すべてのユーザーを拒否

なし

あり

すべてのユーザーを拒否

あり

なし

allow-rules のユーザーのみを許可

あり

あり

allow-rules のユーザーのみが許可されますが、拒否ルールでは許可されません

関連情報

  • SSSD で GPO 強制モードを変更する手順は、「GPO アクセス制御モードの変更」を参照してください。
  • さまざまな GPO モードの詳細は、sssd-ad(5) man ページの ad_gpo_access_control のエントリーを参照してください。

3.5.4. GPO アクセス制御モードの変更

この手順では、GPO ベースのアクセス制御ルールが Active Directory (AD) 環境に参加している RHEL ホストでどのように評価されるかを変更します。

この例では、テスト目的で GPO 操作モードを Enforcing (デフォルト) から Permissive に変更します。

重要

以下のエラーが表示された場合には、GPO ベースのアクセス制御により Active Directory ユーザーはログインできません。

  • /var/log/secure:

    Oct 31 03:00:13 client1 sshd[124914]: pam_sss(sshd:account): Access denied for user aduser1: 6 (Permission denied)
    Oct 31 03:00:13 client1 sshd[124914]: Failed password for aduser1 from 127.0.0.1 port 60509 ssh2
    Oct 31 03:00:13 client1 sshd[124914]: fatal: Access denied for user aduser1 by PAM account configuration [preauth]
  • /var/log/sssd/sssd__example.com_.log:

    (Sat Oct 31 03:00:13 2020) [sssd[be[example.com]]] [ad_gpo_perform_hbac_processing] (0x0040): GPO access check failed: [1432158236](Host Access Denied)
    (Sat Oct 31 03:00:13 2020) [sssd[be[example.com]]] [ad_gpo_cse_done] (0x0040): HBAC processing failed: [1432158236](Host Access Denied}
    (Sat Oct 31 03:00:13 2020) [sssd[be[example.com]]] [ad_gpo_access_done] (0x0040): GPO-based access control failed.

これが望ましくない動作の場合は、AD で正しい GPO 設定のトラブルシューティング中に、この手順で説明されているように、ad_gpo_access_controlPermissive に設定できます。

前提条件

  • SSSD を使用して RHEL ホストを AD 環境に追加している。
  • /etc/sssd/sssd.conf 設定ファイルの編集には、root 権限が必要になります。

手順

  1. SSSD サービスを停止します。

    [root@server ~]# systemctl stop sssd
  2. テキストエディターで /etc/sssd/sssd.conf ファイルを開きます。
  3. AD ドメインの domain セクションで、ad_gpo_access_controlPermissive に設定します。

    [domain/example.com]
    ad_gpo_access_control=permissive
    ...
  4. /etc/sssd/sssd.conf ファイルを保存します。
  5. SSSD サービスを再起動して、設定の変更を読み込みます。

    [root@server ~]# systemctl restart sssd

関連情報

3.5.5. AD GUI での RHEL ホストの GPO の作成および設定

以下の手順では、RHEL ホストへのログオンアクセスを制御するために、Active Directory (AD) グラフィカルユーザーインターフェース(GUI)で Group Policy Object (GPO) を作成します。

前提条件

  • SSSD を使用して RHEL ホストを AD 環境に追加している。
  • GUI を使用して AD に変更を加えるための AD 管理者権限がある。

手順

  1. Active Directory ユーザーおよびコンピューター 内で、新しい GPO に関連付ける組織単位 (OU) を作成します。

    1. ドメインを右クリックします。
    2. New を選択ます。
    3. Organizational Unit を選択します。
  2. Active Directory に参加しているときに) RHEL ホストを表す Computer オブジェクトの名前をクリックし、新しい OU にドラッグします。独自の OU に RHEL ホストがあると、GPO はこのホストをターゲットとします。
  3. Group Policy Management Editor で、作成した OU の GPO を新規作成します。

    1. Forest を展開します。
    2. Domain を展開します。
    3. ドメインを展開します。
    4. 新しい OU をダブルクリックします。
    5. Create a GPO in this domain を選択します。
  4. Allow SSH access または Allow Console/GUI access など、新規 GPO の名前を指定して OK をクリックします。
  5. 新規 GPO を編集します。

    1. Group Policy Management エディター内で OU を選択します。
    2. 右クリックして Edit を選択します。
    3. User Queuing Assignment を選択します。
    4. Computer Configuration を選択します
    5. Policies を選択します。
    6. Windows Settings を選択します。
    7. セキュリティー設定 を選択します。
    8. Local Policies を選択します。
    9. User Queuing Assignment を選択します。
  6. ログインパーミッションを割り当てます。

    1. Allow log on locally をダブルクリックしてローカルコンソール/GUI アクセスを付与します。
    2. Allow log on through Remote Desktop Services をダブルクリックして、SSH アクセスを付与します。
  7. これらのポリシーのいずれかにアクセスするユーザーをポリシー自体に追加します。

    1. Add User or Group をクリックします。
    2. 空白フィールドにユーザー名を入力します。
    3. OK をクリックします。

関連情報

  • Group Policy Objects の詳細は、Microsoft ドキュメントの「Group Policy Objects」を参照してください。

3.5.6. 関連情報