验证步骤

1. 验证 /etc/nsswitch.conf 中是否存在 SSSD 的 sss 条目：

   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 模板和 meta 文件的所有更新都会反映在您的自定义配置集中。

   这个命令会在 /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 配置集意味着，如果以后红帽更新了 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. 它将客户端连接到远程供应商以检索身份和验证信息。
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. 将包含 root CA 签名证书链的 core-dirsrv.ca.pem 文件从颁发 OpenLDAP 服务器的 SSL/TLS 证书的证书颁发机构链复制到 /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

    如需了解更多详细信息，请参阅红帽客户门户网站上的知识库文章 RHEL 8 中的强加密默认值和弱加密算法的弃用 以及 update-crypto-policies(8) 手册页。

流程

1. 打开 /etc/sssd/sssd.conf 文件：

2. 使用 re_expression 选项定义自定义正则表达式。

   例 4.1. 在全局范围内定义正则表达式

   要全局定义所有域的正则表达式，请将 re_expression 添加到 sssd.conf 文件的 [sssd] 部分：

   您可以使用以下全局表达式来定义 domain\\username 或 domain@username 的格式：

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

   例 4.2. 定义特定域的正则表达式

   要单独为特定域定义正则表达式，请将 re_expression 添加到 sssd.conf 文件的对应域部分：

   您可以使用以下全局表达式来定义 LDAP 域的 domain\\username 或 domain@username 格式的用户名：

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

流程

1. 以 root 身份，打开 /etc/sssd/sssd.conf 文件。

2. 要为所有域定义全局扩展，请将 full_name_format 添加到 sssd.conf 的 [sssd] 部分：

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

   在这种情况下，用户名显示为 user@domain.test。

3. 要定义特定域的用户名打印格式，请将 full_name_format 添加到 sssd.conf 的对应域部分。

   • 使用 %2$s\%1$s 为活动目录(AD)域配置扩展：

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

     在本例中，用户名显示为 ad.domain\user。

   • 使用 %3$s\%1$s 为活动目录(AD)域配置扩展：

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

     在这种情况下，如果 Active Directory 域的扁平域名被设置为 AD，则用户名显示为 AD\user。

流程

1. 打开 /etc/sssd/sssd.conf 文件：

2. 在 domain 部分中，添加 cache_credentials = true 设置：

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

3. 可选，但建议：在身份提供程序不可用时为 SSSD 允许离线验证的时间限制：

   1. 配置 PAM 服务以使用 SSSD。

      如需了解更多详细信息，请参阅使用 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) 手册页。

   • 对于 AD 访问提供程序，请使用 ad_access_filter 选项。详情请查看 sssd-ad(5) 手册页。

     例 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. 添加二级 username：

   # sss_override user-add username -n secondary-username

   使用用户的名称替换 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，并使用新的 GID 号替换 new-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. 显示用户当前的 shell：

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

   使用用户名称替换 user-name。

2. 覆盖用户的 shell：

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

   使用用户名替换 user-name，并使用新 shell 替换 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 文件中的 domain 选项中定义 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

   在本例中，您将允许 PAM 服务仅对 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

   如果您使用微软目录服务器服务器，请在 [domain/EXAMPLE.COM] 部分中添加以下行，以启用基于 LDAP 的身份验证：

   ldap_schema = ad

   如果您需要 Kerberos 身份验证，红帽建议使用 realm 命令将 RHEL 客户端加入到 AD 域中，该命令会自动配置 SSSD 服务。

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 服务的条目。
3. libc 库打开 ss_sss 模块。
4. nss_sss 模块检查内存映射缓存以获取用户信息。如果缓存中存在数据，则 ss_sss 模块会返回它。
5. 如果用户信息不在内存映射缓存中，则会将请求传递给 SSSD sssd_nss 响应程序进程。
6. SSSD 服务检查其缓存。如果缓存中存在数据并有效，sssd_nss 响应程序会从缓存中读取数据并将其返回到应用。
7. 如果缓存中没有数据或数据已过期，sssd_nss 响应器将查询相应的后端进程并等待回复。SSSD 服务在 IdM 环境中使用 IPA 后端，通过 sssd.conf 配置文件中的 id_provider=ipa 启用。
8. sssd_be 后端进程连接到 IdM 服务器，并从 IdM LDAP 目录服务器请求信息。
9. IdM 服务器上的 SSSD 后端响应 IdM 客户端上的 SSSD 后端进程。
10. 客户端上的 SSSD 后端将生成的数据存储在 SSSD 缓存中，并提醒已更新缓存的响应程序进程。
11. sssd_nss 前端响应器进程从 SSSD 缓存检索信息。
12. sssd_nss 响应器将用户信息发送到 ss_sss 响应者，以完成请求。
13. libc 库将用户信息返回到请求它的应用程序。

1. IdM 客户端为 AD 用户信息查找其本地 SSSD 缓存。
2. 如果 IdM 客户端没有用户信息，或者信息是 stale，客户端上的 SSSD 服务会联系 IdM 服务器上的 extdom_extop 插件来执行 LDAP 扩展操作并请求信息。
3. IdM 服务器上的 SSSD 服务在其本地缓存中查找 AD 用户信息。
4. 如果 IdM 服务器在其 SSSD 缓存中没有用户信息，或者其信息为过时，它将执行 LDAP 搜索，以从 AD 域控制器请求用户信息。
5. IdM 服务器上的 SSSD 服务从 AD 域控制器接收 AD 用户信息，并将其存储在其缓存中。
6. extdom_extop 插件从 IdM 服务器上的 SSSD 服务接收信息，该服务完成 LDAP 扩展操作。
7. IdM 客户端上的 SSSD 服务从 LDAP 扩展操作接收 AD 用户信息。
8. IdM 客户端将 AD 用户信息存储在其 SSSD 缓存中，并将信息返回给请求它的应用程序。

1. 使用 ssh 命令尝试身份验证会触发 libpam 库。

2. libpam 库引用 /etc/pam.d/ 目录中与请求身份验证尝试的服务对应的 PAM 文件。在本例中，libpam 库涉及通过本地主机上的 SSH 服务进行身份验证，libpam 库检查 /etc/pam.d/system-auth 配置文件并发现 SSSD PAM 的 pam_sss.so 条目：

   auth    sufficient    pam_sss.so

3. 要确定哪些身份验证方法可用，libpam 库会打开 pam_sss 模块，并将 SSS_PAM_PREAUTH 请求发送到 SSSD 服务的 sssd_pam PAM 响应者。
4. 如果配置了智能卡验证，SSSD 服务会生成一个临时 p11_child 进程，以检查智能卡并从中检索证书。
5. 如果为用户配置了智能卡验证，sssd_pam 响应程序会尝试将智能卡中的证书与用户匹配。sssd_pam 响应器还搜索用户所属的组，因为组成员身份可能会影响访问控制。
6. sssd_pam 响应器将 SSS_PAM_PREAUTH 请求发送到 sssd_be 后端响应器，以查看服务器支持的身份验证方法，如密码或双因素身份验证。在 IdM 环境中，SSSD 服务使用 IPA 响应器，默认的身份验证方法是 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 进程生成一个临时 krb5_child 进程来联系 KDC。
13. krb5_child 进程尝试使用用户提供的用户名和密码从 KDC 检索 Kerberos Ticket Granting Ticket (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>

   如果此步骤失败，请检查您的 Dynamic Name Service (DNS) 设置，包括 /etc/resolv.conf 文件。请参阅配置 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 服务器是 IdM 服务器，如 server.example.com，检索主机的 Kerberos 票据，并使用主机 Kerberos 主体进行身份验证数据库搜索：

      [user@client ~]$ kinit -t '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 服务器是 Active Directory (AD) 域控制器 (DC)，如 server.ad.example.com，请检索主机的 Kerberos 票据，并使用主机 Kerberos 主体执行数据库搜索：

      [user@client ~]$ kinit -t '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. （可选）创建一个红帽技术支持问题单，并提供您收集的故障排除信息。

7. 如果您被允许在主机上运行 sudo，请使用 sssctl 工具来验证用户是否被允许登录。

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

   如果这一步失败了，请验证您的授权设置，如 PAM 配置、IdM HBAC 规则和 IdM RBAC 规则：

   1. 确保用户的 UID 等于或大于 UID_MIN，它在 /etc/login.defs 文件中定义。
   2. 查看 /var/log/secure 和 /var/log/messages 日志文件中的授权错误。
   3. 在 SSSD 服务中启用详细的日志记录，收集调试日志，并查看提示性日志以了解问题的来源。
   4. （可选）创建一个红帽技术支持问题单，并提供您收集的故障排除信息。

流程

1. 在文本编辑器中打开 /etc/sssd/sssd.conf 文件。

2. 将 debug_level 选项添加到文件的每个部分，并将 debug 级别设置为您选择的详细程度。

   [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 日志，请降低 debug 级别。

   [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. 创建一个红帽技术支持问题单并提供：

      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 服务器，从而将此测试限制为一个客户端和一个服务器。

   [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 日志来最小化 dataset 故障排除。

   [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 日志，请降低 debug 级别。

   [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. 创建一个红帽技术支持问题单并提供：

       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 日志文件的示例输出显示了两个不同请求的唯一标识符 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. 向下滚动到 Certificates 部分。

4. 单击 View Certificates 来打开 证书管理器。

   

流程

1. 打开 证书管理器 。

2. 选择" Authorities 选项卡，然后单击 Import 。

   图 13.2. 在 Firefox 中导入 CA 证书

   
3. 从您的设备中选择下载的 CA 证书。

先决条件

1. 您已成功导入了证书。

流程

1. 打开 证书管理器 。
2. 在 Authorities 选项卡下，选择合适的证书，然后单击 Edit Trust。

3. 编辑证书信任设置。

   图 13.3. 在 Firefox 中编辑证书信任设置

   

先决条件

1. 您的设备上已存储了一个个人证书。

流程

1. 打开 证书管理器 。

2. 选择 Your Certificates 选项卡，然后单击 Import。

   图 13.4. 在 Firefox 中导入用于身份验证的个人证书

   
3. 从您的计算机上选择合适的证书。

流程

1. 在 Mozilla Thunderbird 中，打开主菜单并选择 Preferences 。

   图 13.5. 从菜单中选择首选项

   

2. 在左侧面板中，选择 Privacy & Security 部分。

   图 13.6. 选择 security 部分

   
3. 向下滚动到 Certificates 部分。

4. 单击 Manage Certificates 来打开 证书管理器。

   图 13.7. 打开证书管理器

   

流程

1. 打开 证书管理器 。

2. 选择" Authorities 选项卡，然后单击 Import 。

   图 13.8. 在 Thunderbird 中导入 CA 证书

   
3. 选择下载的 CA 证书。

流程

1. 打开 证书管理器 。
2. 在 Authorities 选项卡下，选择合适的证书，然后单击 Edit Trust。

3. 编辑证书信任设置。

   图 13.9. 编辑 Thunderbird 中的证书信任设置

   

先决条件

1. 您的设备上已存储了一个个人证书。

流程

1. 打开 证书管理器 。

2. 在 Your Certificates 选项卡下，单击 Import。

   图 13.10. 在 Thunderbird 中导入用于身份验证的个人证书

   
3. 从您的计算机中选择所需的证书。
4. 关闭 证书管理器。

5. 打开主菜单并选择 Account Settings 。

   图 13.11. 从菜单中选择帐户设置

   

6. 在您帐户电子邮件地址的左侧面板中选择 End-To-End Encryption 。

   选择端到端加密部分。

   
7. 在 S/MIME 部分下，单击第一个 Select 按钮，来选择要用于签名消息的个人证书。

8. 在 S/MIME 部分下，单击第二个 Select 按钮，来选择您的个人证书来加密和解密消息。

   选择用于签名和加密/解密的证书。