RHEL での認証と認可の設定

検証

1. /etc/nsswitch.conf に SSSD の sss エントリーが存在することを確認します。

   passwd:     sss files
   group:      sss files
   netgroup:   sss files
   automount:  sss files
   services:   sss files
   ...

2. /etc/pam.d/system-auth ファイルの pam_sss.so エントリーの内容を確認します。

   # Do not modify this file manually, use authselect instead. Any user changes will be overwritten.
   # You can stop authselect from managing your configuration by calling 'authselect opt-out'.
   # See authselect(8) for more details.
   
   auth        required        pam_env.so
   auth        required        pam_faildelay.so delay=2000000
   auth        [default=1 ignore=ignore success=ok]    pam_succeed_if.so uid >= 1000 quiet
   auth        [default=1 ignore=ignore success=ok]    pam_localuser.so
   auth        sufficient      pam_unix.so nullok try_first_pass
   auth        requisite       pam_succeed_if.so uid >= 1000 quiet_success
   auth        sufficient      pam_sss.so forward_pass
   auth        required        pam_deny.so
   
   account     required        pam_unix.so
   account     sufficient      pam_localuser.so
   ...

手順

1. カスタムプロファイルを作成するために、authselect create-profile コマンドを実行します。<custom_profile> を目的のプロファイル名に置き換えます。たとえば、/etc/nsswitch.conf ファイル内の項目を自分で設定するオプションを使用して、既製の sssd プロファイルに基づいてプロファイルを作成するには、次のコマンドを使用します。

   # authselect create-profile <custom_profile> -b sssd --symlink-meta --symlink-pam
   New profile was created at /etc/authselect/custom/<custom_profile>

   警告

   /etc/authselect/custom/<custom_profile>/{password-auth,system-auth,fingerprint-auth,smartcard-auth,postlogin} を変更する予定の場合は、--symlink-pam オプションを指定せずに上記のコマンドを入力してください。これは、authselect-libs のアップグレード中に変更が確実に維持されるために行います。

   コマンドに --symlink-pam オプションを含めると、PAM テンプレートがコピーではなく元のプロファイルファイルへのシンボリックリンクになります。また、--symlink-meta オプションを含めると、README や REQUIREMENTS などのメタファイルも、コピーではなく元のプロファイルファイルへのシンボリックリンクになります。これにより、元のプロファイル内の PAM テンプレートとメタファイルに対する今後のすべての更新が、カスタムプロファイルにも反映されるようになります。

   このコマンドにより、/etc/authselect/custom/<custom_profile>/ ディレクトリーに /etc/nsswitch.conf ファイルのコピーが作成されます。

2. /etc/authselect/custom/<custom_profile>/nsswitch.conf ファイルを設定します。

3. パラメーターとして custom/<custom_profile> を指定した authselect select コマンドを実行し、カスタムプロファイルを選択します。

   # authselect select custom/<custom_profile>

   お使いのマシン用に <custom_profile> プロファイルを選択すると、後で Red Hat によって sssd プロファイルが更新されたときに、/etc/nsswitch.conf ファイルに加えた更新以外のすべての更新を利用できます。

   sssd プロファイルに基づいてカスタムプロファイルを作成する例:

   sssd プロファイルに基づいてプロファイルを作成できます。このプロファイルでは、dns または myhostname データベース内ではなく、/etc/hosts ファイル内のホスト名のローカル静的テーブル検索のみを参照します。

   1. /etc/nsswitch.conf ファイルで、次の行を編集します。

      hosts:      files

   2. /etc/nsswitch.conf への変更を除外するカスタムプロファイルを sssd に基づいて作成します。

      # authselect create-profile custom-sssd-profile -b sssd --symlink-meta --symlink-pam

   3. プロファイルを選択します。

      # authselect select custom/custom-sssd-profile

   4. オプション: カスタムプロファイルを選択したことにより、以下が実行されたことを確認します。

      • 選択した sssd プロファイルに従って /etc/pam.d/system-auth ファイルが作成された。

      • /etc/nsswitch.conf の設定が変更されていない。

        hosts:      files

        注記

        authselect select sssd を実行すると、対照的に hosts: files dns myhostname という結果になります。

1. クライアントをリモートプロバイダーに接続し、ID 情報および認証情報を取得します。
2. 取得した認証情報を使用して、クライアントにユーザーと認証情報のローカルキャッシュを作成します。

1. プライマリー /etc/sssd/sssd.conf ファイル。
2. /etc/sssd/conf.d/ 内のその他の *.conf ファイル。これらのファイルはアルファベット順に処理されます。

手順

1. 必要なパッケージをインストールします。

   # dnf -y install openldap-clients sssd sssd-ldap oddjob-mkhomedir

2. 認証プロバイダーを sssd に切り替えます。

   # authselect select sssd with-mkhomedir

3. OpenLDAP サーバーの SSL/TLS 証明書を発行した認証局からのルート CA 署名証明書チェーンを含む core-dirsrv.ca.pem ファイルを /etc/openldap/certs フォルダーにコピーします。

   # cp core-dirsrv.ca.pem /etc/openldap/certs

4. LDAP サーバーの URL と接尾辞を /etc/openldap/ldap.conf ファイルに追加します。

   URI ldap://ldap-server.example.com/
   BASE dc=example,dc=com

5. /etc/openldap/ldap.conf ファイルで、/etc/openldap/certs/core-dirsrv.ca.pem を参照する TLS_CACERT パラメーターの行を追加します。

   # When no CA certificates are specified the Shared System Certificates
   # are in use. In order to have these available along with the ones specified
   # by TLS_CACERTDIR one has to include them explicitly:
   TLS_CACERT /etc/openldap/certs/core-dirsrv.ca.pem

6. /etc/sssd/sssd.conf ファイルで、環境の値を ldap_uri パラメーターおよび ldap_search_base パラメーターに追加し、ldap_id_use_start_tls を True に設定します。

   [domain/default]
   id_provider = ldap
   autofs_provider = ldap
   auth_provider = ldap
   chpass_provider = ldap
   ldap_uri = ldap://ldap-server.example.com/
   ldap_search_base = dc=example,dc=com
   ldap_id_use_start_tls = True
   cache_credentials = True
   ldap_tls_cacertdir = /etc/openldap/certs
   ldap_tls_reqcert = allow
   
   [sssd]
   services = nss, pam, autofs
   domains = default
   
   [nss]
   homedir_substring = /home
   …

7. /etc/sssd/sssd.conf で、[domain] セクションの ldap_tls_cacert および ldap_tls_reqcert の値を変更して TLS 認証要件を指定します。

   …
   cache_credentials = True
   ldap_tls_cacert = /etc/openldap/certs/core-dirsrv.ca.pem
   ldap_tls_reqcert = hard
   …

8. /etc/sssd/sssd.conf ファイルの権限を変更します。

   # chmod 600 /etc/sssd/sssd.conf

9. SSSD サービスおよび oddjobd デーモンを再起動して有効にします。

   # systemctl restart sssd oddjobd
   # systemctl enable sssd oddjobd

10. オプション: LDAP サーバーが非推奨の TLS 1.0 または TLS 1.1 プロトコルを使用している場合は、クライアントシステムのシステム全体の暗号化ポリシーを LEGACY レベルに切り替えて、RHEL がこのプロトコルを使用して通信できるようにします。

    # update-crypto-policies --set LEGACY

    詳細は、Red Hat カスタマーポータルのナレッジベース記事 Strong crypto defaults in RHEL 8 and deprecation of weak crypto algorithms、およびシステム上の update-crypto-policies(8) man ページを参照してください。

手順

1. /etc/sssd/sssd.conf ファイルを開きます。

2. re_expression オプションを使用して、カスタムの正規表現を定義します。

   1. すべてのドメインに対して正規表現をグローバルに定義するには、sssd.conf ファイルの [sssd] セクションに re_expression を追加します。

      次の glob 表現を使用して、ユーザー名を <domain>\_<username>_ または <domain>@<user_name> という形式で定義できます。

      [sssd]
      [... file truncated ...]
      re_expression = (?P_<domain>_[\\]*?)\\?(?P_<name>_[\\]+$)

   2. 特定のドメインに個別に正規表現を定義するには、sssd.conf ファイルの対応するドメインセクションに re_expression を追加します。

      次の glob 表現を使用して、LDAP ドメインのユーザー名を <domain>\_<username>_ または <domain>@<user_name> という形式で定義できます。

      [domain/LDAP]
      [... file truncated ...]
      re_expression = (?P_<domain>_[\\]*?)\\?(?P_<name>_[\\]+$)

手順

1. root として /etc/sssd/sssd.conf ファイルを開きます。

2. すべてのドメインに対してグローバルに拡張を定義するには、sssd.conf の [sssd] セクションに full_name_format を追加します。

   [sssd]
   [... file truncated ...]
   full_name_format = %1$s@%2$s

   この場合、ユーザー名は user@domain.test と表示されます。

3. 特定のドメインのユーザー名出力形式を定義するには、sssd.conf の対応するドメインセクションに full_name_format を追加します。

   • %2$s\%1$s を使用して Active Directory (AD) ドメインの拡張を設定するには、以下を実行します。

     [domain/ad.domain]
     [... file truncated ...]
     full_name_format = %2$s\%1$s

     この場合、ユーザー名は ad.domain\user と表示されます。

   • %3$s\%1$s を使用して Active Directory (AD) ドメインの拡張を設定するには、以下を実行します。

     [domain/ad.domain]
     [... file truncated ...]
     full_name_format = %3$s\%1$s

     この場合、Active Directory ドメインのフラットドメイン名が AD に設定されている場合、ユーザー名は AD\user と表示されます。

   注記

   SSSD は、名前の設定で名前のドメインコンポーネントを削除できるため、認証エラーが発生する可能性があります。full_name_format を標準以外の値に設定すると、これを標準形式に変更するように要求する警告が表示されます。

手順

1. /etc/sssd/sssd.conf ファイルを開きます。

2. ドメインセクションで、cache_credentials = true 設定を追加します。

   [domain/<domain_name>]
   cache_credentials = true

3. 推奨 (任意): アイデンティティープロバイダーが利用できない場合に SSSD がオフライン認証を許可する期間の制限を設定します。

   1. SSSD と連携するように PAM サービスを設定します。

   2. offline_credentials_expiration オプションを使用して、時間制限を指定します。

      制限は日単位で設定されることに注意してください。

      たとえば、最終ログインに成功してから 3 日間、オフライン認証を可能にするには、以下を使用します。

      [pam]
      offline_credentials_expiration = 3

手順

1. /etc/sssd/sssd.conf ファイルを開きます。

2. プライマリーサーバーの値を _srv_ に設定します。

   LDAP プロバイダーの場合、プライマリーサーバーは ldap_uri オプションを使用して設定されます。

   [domain/<ldap_domain_name>]
   id_provider = ldap
   ldap_uri = _srv_

3. パスワード変更プロバイダーでサービス検出を有効にするには、サービスタイプを設定します。

   [domain/<ldap_domain_name>]
   id_provider = ldap
   ldap_uri = _srv_
   
   chpass_provider = ldap
   ldap_chpass_dns_service_name = ldap

4. オプション: デフォルトでは、サービス検出はシステムホスト名のドメイン部分をドメイン名として使用します。別の DNS ドメインを使用するには、dns_discovery_domain オプションを使用してドメイン名を指定します。
5. オプション: デフォルトでは、サービス検出は LDAP サービスタイプをスキャンします。別のサービスタイプを使用するには、ldap_dns_service_name オプションを使用してタイプを指定します。
6. オプション: デフォルトでは、SSSD は IPv4 アドレスの検索を試みます。試行に失敗すると、SSSD は IPv6 アドレスの検索を試行します。この動作をカスタマイズするには、lookup_family_order オプションを使用します。

7. サービス検出を使用するすべてのサービスについて、DNS レコードを DNS サーバーに追加します。

   _<service_name>.<protocol>.<domain_name> <TTL> <priority> <weight> <port_number> <hostname>_

手順

1. /etc/sssd/sssd.conf ファイルを開きます。

2. access_provider オプションを simple に設定します。

   [domain/<domain_name>]
   access_provider = simple

3. ユーザーのアクセス制御ルールを定義します。

   1. ユーザーへのアクセスを許可するには、simple_allow_users オプションを使用します。
   2. ユーザーへのアクセスを拒否するには、simple_deny_users オプションを使用します。
   重要

   特定のユーザーへのアクセスを拒否する場合には、他のユーザーすべてにアクセスを自動的に許可します。特定ユーザーにアクセスを許可する方が拒否するよりも安全であると考えられます。

4. グループのアクセス制御ルールを定義します。以下のいずれかを選択します。

   1. グループへのアクセスを許可するには、simple_allow_groups オプションを使用します。

   2. グループへのアクセスを拒否するには、simple_deny_groups オプションを使用します。

      重要

      特定のグループへのアクセスを拒否する場合には、他のグループすべてに、アクセスを自動的に許可します。特定グループにアクセスを許可する方が拒否するよりも安全であると考えられます。

      たとえば、alice、bob、および engineers グループのメンバーにアクセスを許可し、他の全ユーザーのアクセスを拒否することができます。

      [domain/<domain_name>]
      access_provider = simple
      simple_allow_users = alice, bob
      simple_allow_groups = engineers

      重要

      拒否リストを空にすると、すべてのユーザーがアクセスできるようになります。

   注記

   信頼できる AD ユーザーを simple_allow_users リストに追加する場合は、必ず完全修飾ドメイン名 (FQDN) 形式 (例: aduser@ad.example.com) を使用してください。異なるドメインの短縮名は同じである可能性があるため、これによりアクセス制御設定に関する問題が回避されます。

手順

1. /etc/sssd/sssd.conf ファイルを開きます。

2. [domain] セクションで、アクセス制御フィルターを指定します。

   • LDAP の場合は、ldap_access_filter オプションを使用します。

   • AD の場合は、ad_access_filter オプションを使用します。さらに、ad_gpo_access_control オプションを disabled に設定して、GPO ベースのアクセス制御を無効にする必要があります。

     たとえば、admins ユーザーグループに属し、属性セットが unixHomeDirectory の AD ユーザーにのみアクセスを許可するには、以下を使用します。

     [domain/<ad_domain_name>]
     access provider = ad
     [... file truncated ...]
     ad_access_filter = (&(memberOf=cn=admins,ou=groups,dc=example,dc=com)(unixHomeDirectory=*))
     ad_gpo_access_control = disabled

     SSSD は、エントリーの authorizedService または host 属性により結果を確認することもできます。実際、ユーザーエントリーおよび設定に応じて、全オプションの MDASH LDAP フィルター、authorizedService および host の MDASH を評価できます。ldap_access_order パラメーターは、評価すべき順に、使用するアクセスコントロールの手法をすべて表示します。

     [domain/example.com]
     access_provider = ldap
     ldap_access_filter = memberOf=cn=allowedusers,ou=Groups,dc=example,dc=com
     ldap_access_order = filter, host, authorized_service

手順

1. ユーザーの現在の情報を表示します。

   # id <ldap_username>

   <ldap_username> は、ユーザーの LDAP username に置き換えます。以下に例を示します。

   # id sjones
   uid=1001(sjones) gid=6003 groups=6003,10(wheel)

2. ローカルユーザー名を追加します。

   # sss_override user-add <ldap_username> -n <local_username>

   <ldap_username> は、LDAP username に置き換えます。<local_username> は、目的のローカルユーザー名に置き換えます。以下に例を示します。

   # sss_override user-add sjones -n sarah

3. sss_override user-add コマンドを使用して最初のオーバーライドを作成したら、SSSD を再起動して変更を反映します。

   # systemctl restart sssd

手順

1. ユーザーの現在の UID を表示します。

   # id -u <ldap_username>

   <ldap_username> は、ユーザーの LDAP username に置き換えます。以下に例を示します。

   # id -u sarah
   1001

2. ユーザーのアカウントの UID をオーバーライドします。

   # sss_override user-add <ldap_username> -u <local_uid>

   <ldap_username> は、ユーザーの LDAP username に置き換えます。<local_uid> は、新しい UID 番号に置き換えます。以下に例を示します。

   # sss_override user-add sarah -u 6666

3. インメモリーキャッシュを失効させます。

   # sss_cache --users

4. sss_override user-add コマンドを使用して最初のオーバーライドを作成したら、SSSD を再起動して変更を反映します。

   # systemctl restart sssd

手順

1. ユーザーの現在の GID を表示します。

   # id -g <ldap_username>

   <ldap_username> は、ユーザー名に置き換えます。以下に例を示します。

   # id -g sarah
   6003

2. ユーザーのアカウントの GID をオーバーライドします。

   # sss_override user-add <ldap_username> -g <local_gid>

   <ldap_username> は、ユーザー名に置き換えます。<local_gid> は、ローカル GID 番号に置き換えます。以下に例を示します。

   # sss_override user-add sarah -g 6666

3. インメモリーキャッシュを失効させます。

   # sss_cache --users

4. sss_override user-add コマンドを使用して最初のオーバーライドを作成したら、SSSD を再起動して変更を反映します。

   # systemctl restart sssd

手順

1. ローカルに保存れているユーザーの現在のホームディレクトリーを表示します。

   # getent passwd <ldap_username>
   <ldap_username>:x:XXXX:XXXX::/home/<home_directory>:/bin/bash

   <ldap_username> は、ユーザー名に置き換えます。ローカルで表示されるとおりのホームディレクトリーの値が出力に表示されます。この値は LDAP レコードとは異なる場合があります。以下に例を示します。

   # getent passwd sarah
   sarah:x:1001:6003::sarah:/bin/bash

2. ユーザーのホームディレクトリーをオーバーライドします。

   # sss_override user-add <ldap_username> -h <new_home_directory>

   <ldap_username> は、ユーザー名に置き換えます。<new_home_directory> は、新しいホームディレクトリーに置き換えます。以下に例を示します。

   # sss_override user-add sarah -h admin

3. SSSD を再起動して変更を適用します。

   # systemctl restart sssd

手順

1. ローカルに保存されているユーザーの現在のシェルを表示します。

   # getent passwd <ldap_username>
   <ldap_username>:x:XXXX:XXXX::/home/<home_directory>:_<currentshell>_

   <ldap_username> は、ユーザー名に置き換えます。

2. ユーザーのシェルをオーバーライドします。

   # sss_override user-add <ldap_username> -s <new_shell>

   <ldap_username> は、ユーザー名に置き換えます。<new_shell> は、新しいシェルに置き換えます。

3. SSSD を再起動して変更を適用します。

   # systemctl restart sssd

手順

1. オプション: sssctl コマンドのヘルプを表示するには、次のように入力します。

   [user@client1 ~]$ sssctl --help
   ....

2. 利用可能なドメインのリストを表示するには、以下を入力します。

   [root@client1 ~]# sssctl domain-list
   implicit_files
   idm.example.com
   ad.example.com
   sub1.ad.example.com

   リストには、Active Directory と Identity Management との間でフォレスト間の信頼関係にあるドメインが含まれます。

手順

1. オプション: sssctl コマンドのヘルプを表示するには、次のように入力します。

   [user@client1 ~]$ sssctl --help

2. 特定のドメインのユーザーデータを表示するには、次のように入力します。<domain_name> は実際のドメイン名に置き換えます。

   [root@client1 ~]# sssctl domain-status <domain_name>

   ドメイン idm.example.com の出力例

   Online status: Online
   
   Active servers:
   IPA: server.idm.example.com
   
   Discovered IPA servers:
   - server.idm.example.com

   ドメイン idm.example.com はオンラインになり、コマンドを設定したクライアントから表示されます。

   ドメインが利用できないと、結果は以下のようになります。

   [root@client1 ~]# sssctl domain-status <domain_name>
   Unable to get online status

手順

1. 必要なドメインにアクセスするように SSSD を設定します。/etc/sssd/sssd.conf ファイルの domains オプションで、SSSD が認証できるドメインを定義します。

   [sssd]
   domains = <idm.example.com>, <ad.example.com>, <ldap.example.com>

2. PAM 設定ファイルで `domains` オプションを設定して、PAM サービスが認証できるドメインを指定します。以下に例を示します。

   auth        sufficient    pam_sss.so forward_pass domains=<idm.example.com>
   account     [default=bad success=ok user_unknown=ignore] pam_sss.so
   password    sufficient    pam_sss.so use_authtok

   この設定により、PAM サービスの認証先が <idm.example.com> だけに制限されます。

1. getent コマンドは、libc ライブラリーから getpwnam 呼び出しをトリガーします。
2. libc ライブラリーは、/etc/nsswitch.conf 設定ファイルを参照して、どのサービスがユーザー情報を提供するかを確認し、SSSD サービスのエントリー sss を検出します。
3. libc ライブラリーは、nss_sss モジュールを開きます。
4. nss_sss モジュールは、ユーザー情報のメモリーマップキャッシュを確認します。データがキャッシュに存在する場合は、nss_sss モジュールがそれを返します。
5. ユーザー情報が memory-mapped キャッシュにない場合、リクエストは SSSD sssd_nss レスポンダープロセスに渡されます。
6. SSSD サービスはキャッシュをチェックします。データがキャッシュに存在し、有効な場合は、sssd_nss レスポンダーがキャッシュからデータを読み取って、アプリケーションに返します。
7. データがキャッシュにない場合や期限切れである場合、sssd_nss レスポンダーは適切なバックエンドプロセスに対してクエリーを実行し、応答を待機します。SSSD サービスは、sssd.conf 設定ファイルで id_provider=ipa を設定して有効にした、IdM 環境の IPA バックエンドを使用します。
8. sssd_be バックエンドプロセスは IdM サーバーに接続して、IdM LDAP Directory Server から情報を要求します。
9. IdM サーバーの SSSD バックエンドは、IdM クライアントの SSSD バックエンドプロセスに対応します。
10. クライアントの SSSD バックエンドは、生成されるデータを SSSD キャッシュに保存し、キャッシュが更新されたレスポンダープロセスを警告します。
11. sssd_nss フロントエンドレスプロセスが SSSD キャッシュから情報を取得します。
12. sssd_nss レスポンダーは、nss_sss レスポンダーにユーザー情報を送信し、リクエストを完了します。
13. libc ライブラリーは、要求したアプリケーションにユーザー情報を返します。

1. IdM クライアントは、AD ユーザー情報に関するローカルの SSSD キャッシュを検索します。
2. IdM クライアントにユーザー情報がない場合や、情報が古い場合に、クライアントの SSSD サービスが IdM サーバーの extdom_extop プラグインに問い合わせて、LDAP 拡張操作を実行し、情報を要求します。
3. IdM サーバーの SSSD サービスは、ローカルキャッシュで AD ユーザー情報を検索します。
4. IdM サーバーに SSSD キャッシュにユーザー情報がない場合や、その情報が古い場合は、LDAP 検索を実行して、AD ドメインコントローラーからユーザー情報を要求します。
5. IdM サーバーの SSSD サービスは、AD ドメインコントローラーから AD ユーザー情報を受け取り、キャッシュに保存します。
6. extdom_extop プラグインは、LDAP 拡張操作を完了する IdM サーバーの SSSD サービスから情報を受信します。
7. IdM クライアントの SSSD サービスは、LDAP 拡張操作から AD ユーザー情報を受信します。
8. IdM クライアントは、AD ユーザー情報を SSSD キャッシュに保存し、要求したアプリケーションに情報を返します。

1. ssh コマンドで認証を試みると、libpam ライブラリーがトリガーされます。

2. libpam ライブラリーは、認証の試行を要求するサービスに対応する /etc/pam.d/ ディレクトリーの PAM ファイルを参照します。この例では、ローカルホストの SSH サービス経由で認証されている例では、libpam ライブラリーは /etc/pam.d/system-auth 設定ファイルを確認し、SSSD PAM の pam_sss.so エントリーを検出します。

   auth    sufficient    pam_sss.so

3. 利用可能な認証方法を判断するため、libpam ライブラリーは pam_sss モジュールを開き、SSSD サービスの sssd_pam PAM レスポンダーに SSS_PAM_PREAUTH リクエストを送信します。
4. スマートカード認証が設定されていると、SSSD サービスは一時的な p11_child プロセスを生成し、スマートカードを確認し、そこから証明書を取得します。
5. ユーザーにスマートカード認証が設定されていると、sssd_pam レスポンダーは、スマートカードの証明書とユーザーを照合します。sssd_pam レスポンダーは、グループメンバーシップがアクセス制御に影響する可能性があるため、ユーザーが属するグループの検索も実行します。
6. sssd_pam レスポンダーは、SSS_PAM_PREAUTH 要求を sssd_be バックエンドレスに送信し、パスワードや 2 要素認証などのサーバーがサポートする認証方法を表示します。SSSD サービスが IPA レスポンダーを使用する IdM 環境では、デフォルトの認証方法は Kerberos です。この例では、ユーザーは簡単な Kerberos パスワードで認証されます。
7. sssd_be レスポンダーは一時的な krb5_child プロセスを起動します。
8. krb5_child プロセスは、IdM サーバーの KDC に連絡して、利用可能な認証方法を確認します。

9. KDC はリクエストに応答します。

   1. krb5_child プロセスは応答を評価し、結果を sssd_be バックエンドプロセスに送信します。
   2. sssd_be バックエンドプロセスが結果を受け取ります。
   3. sssd_pam レスポンダーは結果を受け取ります。
   4. pam_sss モジュールは結果を受け取ります。
10. ユーザーにパスワード認証が設定されていると、pam_sss モジュールにより、パスワードの入力が求められます。スマートカード認証が設定されていると、pam_sss モジュールにより、スマートカードの PIN の入力が求められます。

11. モジュールがユーザー名とパスワードを使用して SSS_PAM_AUTHENTICATE 要求を送信します。これは次の宛先に送信されます。

    1. sssd_pam レスポンダー。
    2. sssd_be バックエンドプロセス。
12. sssd_be プロセスは、KDC に問い合わせる一時的な krb5_child プロセスを起動します。
13. krb5_child process は、ユーザー名とパスワードを使用して KDC から Kerberos チケット保証チケット (TGT) の取得を試みます。
14. krb5_child プロセスは、認証の試行の結果を受け取ります。

15. krb5_child プロセス:

    1. TGT を認証情報キャッシュに保存します。
    2. sssd_be バックエンドプロセスに認証結果を返します。

16. 認証結果は sssd_be プロセスから以下を行います。

    1. sssd_pam レスポンダー。
    2. pam_sss モジュール。
17. pam_sss モジュールは、その他のアプリケーションが参照できるように、環境変数をユーザーの TGT の場所で設定します。

手順

1. SSSD サービスおよびそのプロセスが実行していることを確認します。

   [root@client ~]# pstree -a | grep sssd
     |-sssd -i --logger=files
     |   |-sssd_be --domain implicit_files --uid 0 --gid 0 --logger=files
     |   |-sssd_be --domain <domain_name> --uid 0 --gid 0 --logger=files
     |   |-sssd_ifp --uid 0 --gid 0 --logger=files
     |   |-sssd_nss --uid 0 --gid 0 --logger=files
     |   |-sssd_pac --uid 0 --gid 0 --logger=files
     |   |-sssd_pam --uid 0 --gid 0 --logger=files
     |   |-sssd_ssh --uid 0 --gid 0 --logger=files
     |   `-sssd_sudo --uid 0 --gid 0 --logger=files
     |-sssd_kcm --uid 0 --gid 0 --logger=files

2. クライアントが IP アドレスを使用してユーザーデータベースサーバーに接続できることを確認します。

   [user@client ~]$ ping <IP_address_of_the_database_server>

   この手順が失敗した場合は、ネットワークとファイアウォール設定が、IdM クライアントとサーバー間の直接通信が許可されていることを確認してください。firewalld の使用と設定 を参照してください。

3. クライアントが、完全修飾ホスト名を使用して IdM LDAP サーバー (IdM ユーザー用) または AD ドメインコントローラー (AD ユーザーの場合) を検出して連絡できることを確認します。

   [user@client ~]$ dig -t SRV ldap._tcp.<domain>@<server_name>
   [user@client ~]$ ping <fully_qualified_host_name_of_the_server>

   この手順が失敗した場合は、/etc/resolv.conf ファイルを含む Dynamic Name Service (DNS) の設定を確認してください。DNS サーバーの順序の設定 を参照してください。

   注記

   デフォルトでは、SSSD サービスは DNS サービス (SRV) レコードを介して LDAP サーバーと AD DC を自動的に検出しようとします。SSSD を特定のサーバーに制限するには、sssd.conf 設定ファイルで次のオプションを使用してサーバーを定義します。

   • ipa_server = <fully_qualified_host_name_of_the_server>
   • ad_server = <fully_qualified_host_name_of_the_server>
   • ldap_uri = <fully_qualified_host_name_of_the_server>

   このオプションを使用する場合は、そのオプションに記載されているサーバーと通信できることを確認します。

4. クライアントが LDAP サーバーに対して認証でき、ldapsearch コマンドでユーザー情報を取得できることを確認します。

   1. LDAP サーバーが server.example.com などの IdM サーバーである場合は、ホストの Kerberos チケットを取得し、ホスト Kerberos プリンシパルで認証されるデータベース検索を実行します。

      [user@client ~]$ kinit -k 'host/client.example.com@EXAMPLE.COM'
      [user@client ~]$ ldapsearch -LLL -Y GSSAPI -h server.example.com -b "dc=example,dc=com" uid=<idm_user>

   2. LDAP サーバーが server.ad.example.com などの Active Directory (AD) Domain Controller (DC) である場合は、ホストの Kerberos チケットを取得し、ホストの Kerberos プリンシパルで認証してデータベース検索を実行します。

      [user@client ~]$ kinit -k 'CLIENT$@AD.EXAMPLE.COM'
      [user@client ~]$ ldapsearch -LLL -Y GSSAPI -h server.ad.example.com -b "dc=example,dc=com" sAMAccountname=<idm_user>

   3. LDAP サーバーがプレーン LDAP サーバーであり、sssd.conf ファイルに ldap_default_bind_dn および ldap_default_authtok オプションを設定した場合は、同じ ldap_default_bind_dn アカウントとして認証されます。

      [user@client ~]$ ldapsearch -xLLL -D "cn=ldap_default_bind_dn_value" -W -h ldapserver.example.com -b "dc=example,dc=com" uid=<idm_user>

   この手順が失敗した場合は、データベース設定で、ホストが LDAP サーバーを検索できることを確認します。

5. SSSD サービスは Kerberos 暗号化を使用するため、ログインできないユーザーとして Kerberos チケットを取得できます。

   1. LDAP サーバーが IdM サーバーの場合:

      [user@client ~]$ kinit <idm_user>

   2. LDAP サーバーデータベースが AD サーバーの場合:

      [user@client ~]$ kinit <ad_user@AD.EXAMPLE.COM>

   この手順が失敗した場合は、Kerberos サーバーが適切に動作し、すべてのサーバーが同期され、ユーザーアカウントがロックされていないことを確認します。

6. コマンドラインに関するユーザー情報を取得できることを確認します。

   [user@client ~]$ getent passwd <idm_user>
   [user@client ~]$ id <idm_user>

   この手順が失敗した場合は、クライアントの SSSD サービスがユーザーデータベースから情報を受信できることを確認します。

   1. /var/log/messages ログファイルのエラーを確認します。
   2. SSSD サービスで詳細なロギングを有効にし、デバッグログを収集して、問題のソースに関するログを確認します。
   3. オプション: Red Hat テクニカルサポートケースを作成し、収集したトラブルシューティング情報を提供します。

7. ホスト上で sudo 権限を持っている場合は、sssctl ユーティリティーを使用して、ユーザーがログインできるかどうかを確認します。

   [user@client ~]$ sudo sssctl user-checks -a auth -s ssh <idm_user>

   この手順が失敗した場合は、PAM 設定、IdM HBAC ルール、IdM RBAC ルールなどの認可設定を確認します。

   1. ユーザーの UID が、/etc/login.defs ファイルで定義されている UID_MIN 以上であることを確認してください。
   2. /var/log/secure ログファイルおよび /var/log/messages ログファイルで認可エラーを確認します。
   3. SSSD サービスで詳細なロギングを有効にし、デバッグログを収集して、問題のソースに関するログを確認します。
   4. オプション: Red Hat テクニカルサポートケースを作成し、収集したトラブルシューティング情報を提供します。

手順

1. テキストエディターで /etc/sssd/sssd.conf ファイルを開きます。

2. debug_level オプションをファイルのすべてのセクションに追加し、デバッグレベルを、選択した詳細に設定します。

   [domain/<domain_name>]
   debug_level = 6
   id_provider = ipa
   ...
   
   [sssd]
   debug_level = 6
   services = nss, pam, ifp, ssh, sudo
   domains = <domain_name>
   
   [nss]
   debug_level = 6
   
   [pam]
   debug_level = 6
   
   [sudo]
   debug_level = 6
   
   [ssh]
   debug_level = 6
   
   [pac]
   debug_level = 6
   
   [ifp]
   debug_level = 6

3. sssd.conf ファイルを保存して閉じます。

4. SSSD サービスを再起動して、新しい設定を読み込みます。

   [root@server ~]# systemctl restart sssd

手順

1. IdM サーバーで詳細な SSSD デバッグロギングを有効にします。

   [root@server ~]# sssctl debug-level 6

2. 認証問題が発生しているユーザーの SSSD キャッシュでオブジェクトを無効にするため、LDAP サーバーを省略し、SSSD がすでにキャッシュされている情報を取得しません。

   [root@server ~]# sssctl cache-expire -u <idm_user>

3. 古い SSSD ログを削除して、トラブルシューティングのデータセットを最小限に抑える。

   [root@server ~]# sssctl logs-remove

4. 認証問題が発生し、試行前後にタイムスタンプを収集する際に、ユーザーが認証問題が発生しようと試みます。これらのタイムスタンプは、データセットのスコープをさらに絞り込むことができます。

   [root@server sssd]# date; su <idm_user>; date
   Mon Mar 29 15:33:48 EDT 2021
   su: user idm_user does not exist
   Mon Mar 29 15:33:49 EDT 2021

5. オプション: 詳細な SSSD ログの収集を継続しない場合は、デバッグレベルを下げます。

   [root@server ~]# sssctl debug-level 2

6. 障害のある要求に関する情報を SSSD ログで確認します。たとえば、/var/log/sssd/sssd_example.com.log ファイルを確認すると、SSSD サービスが cn=accounts,dc=example,dc=com LDAP サブツリーでユーザーを見つけられなかったことを示しています。これは、ユーザーが存在しないか、別の場所に存在することを示しています。

   (Mon Mar 29 15:33:48 2021) [sssd[be[example.com]]] [dp_get_account_info_send] (0x0200): Got request for [0x1][BE_REQ_USER][name=idm_user@example.com]
   ...
   (Mon Mar 29 15:33:48 2021) [sssd[be[example.com]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(&(uid=idm_user)(objectclass=posixAccount)(uid=)(&(uidNumber=)(!(uidNumber=0))))][cn=accounts,dc=example,dc=com].
   (Mon Mar 29 15:33:48 2021) [sssd[be[example.com]]] [sdap_get_generic_op_finished] (0x0400): Search result: Success(0), no errmsg set
   (Mon Mar 29 15:33:48 2021) [sssd[be[example.com]]] [sdap_search_user_process] (0x0400): Search for users, returned 0 results.
   (Mon Mar 29 15:33:48 2021) [sssd[be[example.com]]] [sysdb_search_by_name] (0x0400): No such entry
   (Mon Mar 29 15:33:48 2021) [sssd[be[example.com]]] [sysdb_delete_user] (0x0400): Error: 2 (No such file or directory)
   (Mon Mar 29 15:33:48 2021) [sssd[be[example.com]]] [sysdb_search_by_name] (0x0400): No such entry
   (Mon Mar 29 15:33:49 2021) [sssd[be[example.com]]] [ipa_id_get_account_info_orig_done] (0x0080): Object not found, ending request

7. 認証問題の原因を判断できない場合は、以下を行います。

   1. 最近生成した SSSD ログを収集します。

      [root@server ~]# sssctl logs-fetch sssd-logs-Mar29.tar

   2. Red Hat テクニカルサポートケースを作成し、以下を提供します。

      1. SSSD ログ: sssd-logs-Mar29.tar

      2. ログに対応する要求のタイムスタンプおよびユーザー名を含むコンソールの出力。

         [root@server sssd]# date; id <idm_user>; date
         Mon Mar 29 15:33:48 EDT 2021
         id: 'idm_user': no such user
         Mon Mar 29 15:33:49 EDT 2021

手順

1. クライアントで、テキストエディターで /etc/sssd/sssd.conf ファイルを開きます。

2. クライアントで、ファイルの [domain] セクションに ipa_server オプションを追加し、このオプションを完全修飾ドメイン名 (FQDN) を使用して IdM サーバーに設定します。これにより、IdM クライアントは他の IdM サーバーの自動検出を避け、このテストを 1 つのクライアントおよびサーバー 1 台だけに制限します。

   [domain/<idm_domain_name>]
   ipa_server = <idm_server_fqdn>
   ...

3. クライアントで sssd.conf ファイルを保存して閉じます。

4. クライアントで SSSD サービスを再起動して、設定の変更を読み込みます。

   [root@client ~]# systemctl restart sssd

5. サーバーおよびクライアントで、詳細な SSSD デバッグロギングを有効にします。

   [root@server ~]# sssctl debug-level 6

   [root@client ~]# sssctl debug-level 6

6. サーバーおよびクライアントで、認証問題が発生しているユーザーの SSSD キャッシュの検証オブジェクトでは、LDAP データベースを迂回せず、SSSD がすでにキャッシュされています。

   [root@server ~]# sssctl cache-expire -u <idm_user>

   [root@client ~]# sssctl cache-expire -u <idm_user>

7. サーバーおよびクライアントで、古い SSSD ログを削除して、トラブルシューティングのデータセットを最小限に抑える。

   [root@server ~]# sssctl logs-remove

   [root@server ~]# sssctl logs-remove

8. クライアントで、認証問題が発生し、試行前後にタイムスタンプを収集する際に、ユーザーが認証問題が発生しようと試みます。これらのタイムスタンプは、データセットのスコープをさらに絞り込むことができます。

   [root@client sssd]# date; su <idm_user>; date
   Mon Mar 29 16:20:13 EDT 2021
   su: user idm_user does not exist
   Mon Mar 29 16:20:14 EDT 2021

9. オプション: サーバーおよびクライアントで、詳細な SSSD ログの収集を継続しない場合は、デバッグレベルを下げます。

   [root@server ~]# sssctl debug-level 0

   [root@client ~]# sssctl debug-level 0

10. サーバーおよびクライアントで、失敗した要求に関する情報を SSSD ログを確認します。

    1. クライアントログのクライアントからの要求を確認します。
    2. サーバーログのクライアントからの要求を確認します。
    3. サーバーログでリクエストの結果を確認します。
    4. サーバーからリクエストの結果を受信するクライアントの結果を確認します。

11. 認証問題の原因を判断できない場合は、以下を行います。

    1. IdM サーバーおよび IdM クライアントで最近生成した SSSD ログを収集します。ホスト名またはロールに応じてラベルを付けます。

       [root@server ~]# sssctl logs-fetch sssd-logs-server-Mar29.tar

       [root@client ~]# sssctl logs-fetch sssd-logs-client-Mar29.tar

    2. Red Hat テクニカルサポートケースを作成し、以下を提供します。

       1. SSSD デバッグログ:

          1. サーバーから sssd-logs-server-Mar29.tar
          2. クライアントからの sssd-logs-client-Mar29.tar

       2. ログに対応する要求のタイムスタンプおよびユーザー名を含むコンソールの出力。

          [root@client sssd]# date; su <idm_user>; date
          Mon Mar 29 16:20:13 EDT 2021
          su: user idm_user does not exist
          Mon Mar 29 16:20:14 EDT 2021

手順

1. SSSD のログファイルを確認するために、less ユーティリティーを使用してログファイル /var/log/sssd/sssd_<domain_name>.log を開きます。以下に例を示します。

   [root@server ~]# less /var/log/sssd/sssd_example.com.log

2. SSSD ログでクライアント要求に関する情報を確認します。

   (2021-07-26 18:26:37): [be[testidm.com]] [dp_req_destructor] (0x0400): [RID#3] Number of active DP request: 0
   (2021-07-26 18:26:37): [be[testidm.com]] [dp_req_reply_std] (0x1000): [RID#3] DP Request AccountDomain #3: Returning [Internal Error]: 3,1432158301,GetAccountDomain() not supported
   (2021-07-26 18:26:37): [be[testidm.com]] [dp_attach_req] (0x0400): [RID#4] DP Request Account #4: REQ_TRACE: New request. [sssd.nss CID #1] Flags [0x0001].
   (2021-07-26 18:26:37): [be[testidm.com]] [dp_attach_req] (0x0400): [RID#4] Number of active DP request: 1

   SSSD ログファイルからのこの出力例は、2 つの異なる要求について一意の識別子の RID#3 および RID#4 を示しています。

   ただし、SSSD クライアントインターフェイスへの 1 つのクライアント要求が、バックエンドで複数の要求をトリガーすることが多いため、クライアント要求とバックエンドの要求との間に 1 対 1 の相関関係がなくなります。バックエンド内の複数のリクエストには異なる RID 番号がありますが、最初の各バックエンドリクエストには一意のクライアント ID が含まれているため、管理者は単一のクライアントリクエストに対して複数の RID 番号を追跡できます。

   以下の例は、1 つのクライアントリクエスト [sssd.nss CID #1] と、バックエンドで生成された複数のリクエスト ([RID#5] から [RID#13]) を示しています。

   (2021-10-29 13:24:16): [be[ad.vm]] [dp_attach_req] (0x0400): [RID#5] DP Request [Account #5]: REQ_TRACE: New request. [sssd.nss CID #1] Flags [0x0001].
   (2021-10-29 13:24:16): [be[ad.vm]] [dp_attach_req] (0x0400): [RID#6] DP Request [AccountDomain #6]: REQ_TRACE: New request. [sssd.nss CID #1] Flags [0x0001].
   (2021-10-29 13:24:16): [be[ad.vm]] [dp_attach_req] (0x0400): [RID#7] DP Request [Account #7]: REQ_TRACE: New request. [sssd.nss CID #1] Flags [0x0001].
   (2021-10-29 13:24:17): [be[ad.vm]] [dp_attach_req] (0x0400): [RID#8] DP Request [Initgroups #8]: REQ_TRACE: New request. [sssd.nss CID #1] Flags [0x0001].
   (2021-10-29 13:24:17): [be[ad.vm]] [dp_attach_req] (0x0400): [RID#9] DP Request [Account #9]: REQ_TRACE: New request. [sssd.nss CID #1] Flags [0x0001].
   (2021-10-29 13:24:17): [be[ad.vm]] [dp_attach_req] (0x0400): [RID#10] DP Request [Account #10]: REQ_TRACE: New request. [sssd.nss CID #1] Flags [0x0001].
   (2021-10-29 13:24:17): [be[ad.vm]] [dp_attach_req] (0x0400): [RID#11] DP Request [Account #11]: REQ_TRACE: New request. [sssd.nss CID #1] Flags [0x0001].
   (2021-10-29 13:24:17): [be[ad.vm]] [dp_attach_req] (0x0400): [RID#12] DP Request [Account #12]: REQ_TRACE: New request. [sssd.nss CID #1] Flags [0x0001].
   (2021-10-29 13:24:17): [be[ad.vm]] [dp_attach_req] (0x0400): [RID#13] DP Request [Account #13]: REQ_TRACE: New request. [sssd.nss CID #1] Flags [0x0001].

手順

1. Firefox のアドレスバーに about:config と入力し、現在の設定オプションのリストを表示します。
2. Filter フィールドに negotiate と入力して、オプションのリストを制限します。
3. network.negotiate-auth.trusted-uris エントリーをダブルクリックします。

4. 先行ピリオド (.) を含む、認証に使用するドメイン名を入力します。複数のドメインを追加する場合は、ドメインをコンマ区切りで入力します。

   Firefox の手動設定

   

手順

1. Mozilla Firefox で Firefox メニューを開き、Preferences を選択します。

   

2. 左側のパネルで、Privacy & Security セクションを選択します。

   
3. Certificates までスクロールします。

4. View Certificates をクリックして、Certificate Manager を開きます。

   

手順

1. Certificate Manager を開きます。

2. Authorities タブを選択し、Import をクリックします。

   図13.1 Firefox での CA 証明書のインポート

   
3. デバイスからダウンロードした CA 証明書を選択します。

前提条件

1. 証明書が正常にインポートされました。

手順

1. Certificate Manager を開きます。
2. Authorities タブで、適切な証明書を選択し、Edit Trust をクリックします。

3. 証明書信頼設定を編集します。

   図13.2 Firefox での証明書信頼設定の編集

   

前提条件

1. デバイスに個人証明書が保存されている。

手順

1. Certificate Manager を開きます。

2. Your Certificates タブを選択し、Import をクリックします。

   図13.3 Firefox での認証用個人証明書のインポート

   
3. コンピューターから適切な証明書をインポートします。

手順

1. Thunderbird でメインメニューを開き、Preferences を選択します。

   図13.4 メニューから Preferences を選択する

   

2. 左側のパネルで、Privacy & Security セクションを選択します。

   図13.5 セキュリティーセクションの選択

   
3. Certificates までスクロールします。

4. Manage Certificates をクリックして、Certificate Manager を開きます。

   図13.6 Certificate Manager の起動

   

手順

1. Certificate Manager を開きます。

2. Authorities タブを選択し、Import をクリックします。

   図13.7 Thunderbird で CA 証明書のインポート

   
3. ダウンロードした CA 証明書を選択します。

手順

1. Certificate Manager を開きます。
2. Authorities タブで、適切な証明書を選択し、Edit Trust をクリックします。

3. 証明書信頼設定を編集します。

   図13.8 Thunderbird で証明書の信頼設定の編集

   

前提条件

1. デバイスに個人証明書が保存されている。

手順

1. Certificate Manager を開きます。

2. Your Certificates タブで、Import をクリックします。

   図13.9 Thunderbird での認証用個人証明書のインポート

   
3. 必要な証明書をコンピューターからインポートします。
4. Certificate Manager を閉じます。

5. メインメニューを開き、Account Settings を選択します。

   図13.10 メニューからアカウント設定を選択する

   

6. アカウントのメールアドレスの下の左側のパネルで End-To-End Encryption を選択します。

   End-To-End Encryption セクションの選択

   
7. S/MIME セクションで、1 つ目の Select ボタンをクリックして、メッセージの署名に使用する個人証明書を選択します。

8. S/MIME セクションで、2 つ目の Select ボタンをクリックして、メッセージの暗号化と復号に使用する個人証明書を選択します。

   署名および暗号化/復号に使用する証明書の選択

   
   注記

   有効な証明書をインポートし忘れた場合は、Manage S/MIME certificate オプションを使用すると、Certificate Manager を直接開くことができます。