検証手順

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

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

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

   # Generated by authselect on Tue Sep 11 22:59:06 2018
   # Do not modify this file manually.
   
   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 プロファイルを選択します。以下に例を示します。

   # authselect select sssd

2. 必要な変更で /etc/authselect/user-nsswitch.conf ファイルを編集します。

3. /etc/authselect/user-nsswitch.conf ファイルから変更を適用します。

   # authselect apply-changes

手順

1. authselect create-profile コマンドを使用してカスタムプロファイルを作成します。たとえば、既製の sssd プロファイルに基づく user-profile というカスタムプロファイルを作成し、/etc/nsswitch.conf ファイルで項目を設定するには、以下のコマンドを実行します。

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

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

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

2. /etc/authselect/custom/user-profile/nsswitch.conf ファイルを設定します。

3. authselect select コマンドを実行してカスタムプロファイルを選択し、custom/name_of_the_profile パラメーターを追加します。たとえば、user-profile プロファイルを選択するには、以下のコマンドを実行します。

   # authselect select custom/user-profile

   お使いのマシンで user-profile プロファイルを選択すると、その後 Red Hat が sssd プロファイルを更新した場合に、/etc/nsswitch.conf ファイルに行った更新以外のすべての更新を利用できるようになります。

   例1.1 プロファイルの作成

   次の手順は、sssd プロファイルに基づいてプロファイルを作成する方法を示しています。ここでは、ホスト名に対するローカルの静的テーブルルックアップを、/etc/hosts ファイルでのみ参照し、dns データベースまたは myhostname データベースは参照しません。

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

      hosts:      files

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

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

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

      # authselect select custom/user-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および man ページの update-crypto-policies(8) を参照してください。

手順

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

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

   例4.1 正規表現のグローバルでの定義

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

   以下の glob 表現を使用して、domain\\username または domain@username の形式でユーザー名を定義できます。

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

   例4.2 特定のドメインへの正規表現の定義

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

   以下の glob 表現を使用して、LDAP ドメインの domain\\username または domain@username の形式でユーザー名を定義できます。

   [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 として表示されます。

手順

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

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

   [domain/your-domain-name]
   cache_credentials = true

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

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

      詳細は authselect でユーザー認証の設定 を参照してください。

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

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

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

      [pam]
      offline_credentials_expiration = 3

手順

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

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

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

   [domain/your-domain-name]
   id_provider = ldap
   ldap_uri = _srv_

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

   [domain/your-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._protocol._domain TTL priority weight port host_name

手順

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

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

   [domain/your-domain-name]
   access_provider = simple

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

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

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

      重要

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

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

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

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

      重要

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

      例4.3 特定のユーザーおよびグループへのアクセス許可

      以下の例では、他のユーザーすべてに対して、アクセスを拒否する一方で、user1、user2、および group1 のメンバーにアクセスを許可します。

      [domain/your-domain-name]
      access_provider = simple
      simple_allow_users = user1, user2
      simple_allow_groups = group1

手順

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

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

   • LDAP アクセスプロバイダーの場合は、ldap_access_filter オプションを使用します。詳細は sssd-ldap(5) man ページを参照してください。

   • AD アクセスプロバイダーの場合は、ad_access_filter オプションを使用します。詳細は sssd-ad(5) man ページを参照してください。

     例4.4 特定の AD ユーザーへのアクセス許可

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

     [domain/your-AD-domain-name]
     access provider = ad
     [... file truncated ...]
     ad_access_filter = (&(memberOf=cn=admins,ou=groups,dc=example,dc=com)(unixHomeDirectory=*))

手順

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

   # id username

   username は、ユーザー名に置き換えます。

2. セカンダリーの ユーザー名 を追加します。

   # sss_override user-add username -n secondary-username

   username はユーザー名に、secondary-username は新しい ユーザー名 に置き換えます。

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

   # systemctl restart sssd

手順

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

   # id -u user-name

   user-name は、ユーザー名に置き換えます。

2. ユーザーのアカウントの UID を上書きします。

   # sss_override user-add user-name -u new-UID

   user-name はユーザー名に、new-UID は新しい UID 番号に置き換えます。

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

   # sss_cache --users

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

   # systemctl restart sssd

手順

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

   # id -g user-name

   user-name は、ユーザー名に置き換えます。

2. ユーザーのアカウントの GID を上書きします。

   # sss_override user-add user-name -g new-GID

   user-name はユーザー名に、new-GID は新しい GID 番号に置き換えます。

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

   # sss_cache --users

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

   # systemctl restart sssd

手順

1. ユーザーの現在のホームディレクトリーを表示します。

   # getent passwd user-name
   user-name:x:XXXX:XXXX::/home/home-directory:/bin/bash

   user-name は、ユーザー名に置き換えます。

2. ユーザーのホームディレクトリーを上書きします。

   # sss_override user-add user-name -h new-home-directory

   user-name はユーザー名に、new-home-directory は新しいホームディレクトリーに置き換えます。

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

   # systemctl restart sssd

手順

1. ユーザーの現在のシェルを表示します。

   # getent passwd user-name
   user-name:x:XXXX:XXXX::/home/home-directory:/bin/bash

   user-name は、ユーザー名に置き換えます。

2. ユーザーのシェルを上書きします。

   # sss_override user-add user-name -s new-shell

   user-name はユーザーの名前に、new-shell は新しいシェルに置き換えます。

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

   # systemctl restart sssd

手順

1. sssctl コマンドのヘルプを表示するには、以下のコマンドを実行します。

   [root@client1 ~]# sssctl --help
   ....

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

手順

1. sssctl コマンドのヘルプを表示するには、以下のコマンドを実行します。

   [root@client1 ~]# sssctl --help

2. 特定ドメインのユーザーデータを表示するには、以下を入力します。

   [root@client1 ~]# sssctl domain-status idm.example.com
   Online status: Online
   
   Active servers:
   IPA: server.idm.example.com
   
   Discovered IPA servers:
   - server.idm.example.com

手順

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

   [sssd]
   domains = domain1, domain2, domain3

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

   auth        sufficient    pam_sss.so forward_pass domains=domain1
   account     [default=bad success=ok user_unknown=ignore] pam_sss.so
   password    sufficient    pam_sss.so use_authtok

   この例では、domain1 に対する認証のみを許可します。

手順

1. 現在の認証設定をバックアップします。

   # authselect apply-changes -b --backup=ldap-configuration-backup

2. SSSD パッケージをインストールします。

   # yum install sssd-ldap sssd-ad sssd-client \
                 sssd-common sssd-common-pac \
                 sssd-krb5 sssd-krb5-common

3. nslcd および nscd サービスを停止して無効にします。

   # systemctl stop nslcd nscd
   # systemctl disable nslcd nscd

4. SSSD で認証を設定します:

   # authselect select sssd with-mkhomedir --force

5. SSSD 設定ファイルに必要な所有権と権限を設定します。

   # chown root:root /etc/sssd/sssd.conf
   # chmod 600 /etc/sssd/sssd.conf

6. /etc/sssd/sssd.conf ファイルを開いて編集します。

7. 次の設定を入力し、example.com や dc=example,dc=com などの値をご使用の環境に適した値に置き換えます。

   [sssd]
   config_file_version = 2
   services = nss, pam
   domains = EXAMPLE.COM
   debug_level = 6
   
   [domain/EXAMPLE.COM]
   id_provider = ldap
   auth_provider = ldap
   ldap_uri = ldap://server.example.com/
   ldap_search_base = dc=example,dc=com
   ldap_default_bind_dn = CN=binddn,DC=example,DC=com
   ldap_default_authtok_type = password
   ldap_default_authtok = <bind_account_password>
   cache_credentials = True

   注記

   SSSD 設定で LDAP スキーマを指定する必要がある場合があります。

   ディレクトリーサーバーで RFC-2307bis スキーマを使用している場合は、[domain/EXAMPLE.COM] セクションに次の行を追加します。

   ldap_schema = rfc2307bis

   Microsoft Active Directory サーバーを使用している場合は、[domain/EXAMPLE.COM] セクションに次の行を追加して、LDAP ベースの認証を有効にします。

   ldap_schema = ad

   Kerberos 認証が必要な場合、Red Hat は、SSSD サービスを自動的に設定する realm コマンドを使用して RHEL クライアントを AD ドメインに参加させることをお勧めします。

8. SSSD サービスを有効にして開始します。

   # systemctl enable sssd
   # systemctl start sssd

検証手順

1. LDAP ユーザーに関する情報を取得できることを確認します。

   # id ldapuser
    uid=100424(ldapuser) gid=100424(ldapuser) groups=100424(ldapuser)
   
   # getent passwd ldapuser
   ldapuser:*: 100424: 100424:User, LDAP:/home/ldapuser:/bin/bash

2. LDAP ユーザーとしてログインできることを確認します。

   # ssh -l ldapuser localhost
   ldapuser@localhost's password:
   Last login: Tue Dec 07 19:34:35 2021 from localhost
   -sh-4.2$

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 サービス経由で認証されている例では、pam_sss.so ライブラリーは /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 example.com --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.example.com @<name_server>
   [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.conf 設定ファイルで以下のオプションを設定すると、SSSD サービスが特定のサーバーを使用するように制限できます。

   • 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=<user_name>

   2. LDAP サーバーが server.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=<user_name>

   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=<user_name>

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

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

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

      [user@client ~]$ kinit <user_name>

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

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

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

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

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

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

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

7. ホストで sudo を実行することが許可されている場合は、sssctl ユーティリティーを使用して、ユーザーがログインを許可されていることを確認します。

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

   この手順が失敗した場合は、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/example.com]
   debug_level = 6
   id_provider = ipa
   ...
   
   [sssd]
   debug_level = 6
   services = nss, pam, ifp, ssh, sudo
   domains = example.com
   
   [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 idmuser

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

   [root@server ~]# sssctl logs-remove

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

   [root@server sssd]# date; su idmuser; date
   Mon Mar 29 15:33:48 EDT 2021
   su: user idmuser 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=idmuser@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=idmuser)(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 idmuser; date
         Mon Mar 29 15:33:48 EDT 2021
         id: ‘idmuser’: no such user
         Mon Mar 29 15:33:49 EDT 2021

手順

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

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

   [domain/example.com]
   ipa_server = server.example.com
   ...

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 idmuser

   [root@client ~]# sssctl cache-expire -u idmuser

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

   [root@server ~]# sssctl logs-remove

   [root@server ~]# sssctl logs-remove

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

   [root@client sssd]# date; su idmuser; date
   Mon Mar 29 16:20:13 EDT 2021
   su: user idmuser 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 idmuser; date
          Mon Mar 29 16:20:13 EDT 2021
          su: user idmuser does not exist
          Mon Mar 29 16:20:14 EDT 2021

手順

1. SSSD ログファイルを確認するには、less ユーティリティーを使用してログファイルを開きます。たとえば、/var/log/sssd/sssd_example.com.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 を示しています。

手順

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

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

   図13.1 Firefox の手動設定

   

手順

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

   

2. 左側のウィンドウで、Privacy & Security セクションを選択します。

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

4. View Certificates を選択して、Certificate Manager を開きます。

   

手順

1. Certificate Manager を開きます。

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

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

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

前提条件

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

手順

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

3. 証明書トラスト設定を編集します。

   図13.3 Firefox での証明書トラスト設定の編集

   

前提条件

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

手順

1. Certificate Manager を開きます。

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

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

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

手順

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

   図13.5 メニューから環境設定を選ぶ

   

2. 左側のウィンドウで、Privacy & Security セクションを選択します。

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

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

4. Manage Certificatesを選択して、Certificate Manager を開きます。

   図13.7 証明書マネージャーの起動

   

手順

1. Certificate Manager を開きます。

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

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

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

手順

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

3. 証明書トラスト設定を編集します。

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

   

前提条件

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

手順

1. Certificate Manager を開きます。

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

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

   
3. お使いのコンピューターから必要な証明書を選択します。
4. Certificate Manager を閉じます。

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

   図13.11 メニューからアカウント設定の選択

   

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

   エンドツーエンドの暗号化セクションの選択

   
7. S/MIME で、最初の Select を選択して、メッセージの署名に使用する個人証明書を選択します。

8. S/MIME で、2 番目の Select を選択して、メッセージの暗号化と復号を行う個人証明書を選択します。

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